diff --git a/basics/dependencies.mdx b/basics/dependencies.mdx index 1d3bf8f1..79d73e45 100644 --- a/basics/dependencies.mdx +++ b/basics/dependencies.mdx @@ -67,8 +67,7 @@ targets, we’ve made some strides in mitigating the downside by investing in tooling to automatically manage `BUILD` files to avoid burdening developers. Some of these tools, such as `buildifier` and `buildozer`, are available with -Bazel in the [`buildtools` -directory](https://github.com/bazelbuild/buildtools). +Bazel in the [`buildtools` directory](https://github.com/bazelbuild/buildtools). ## Minimizing Module Visibility @@ -108,8 +107,7 @@ transitive dependencies (Figure 1). Suppose target A depends on target B, which depends on a common library target C. Should target A be able to use classes defined in target C? -[![Transitive -dependencies](/images/transitive-dependencies.png)](/images/transitive-dependencies.png) +[![Transitive dependencies](/images/transitive-dependencies.png)](/images/transitive-dependencies.png) **Figure 1**. Transitive dependencies @@ -143,9 +141,7 @@ dependencies and adding them to a `BUILD` files without any developer intervention. But even without such tools, we’ve found the trade-off to be well worth it as the codebase scales: explicitly adding a dependency to `BUILD` file is a one-time cost, but dealing with implicit transitive dependencies can cause -ongoing problems as long as the build target exists. Bazel [enforces strict -transitive -dependencies](https://blog.bazel.build/2017/06/28/sjd-unused_deps.html) +ongoing problems as long as the build target exists. Bazel [enforces strict transitive dependencies](https://blog.bazel.build/2017/06/28/sjd-unused_deps.html) on Java code by default. ### External dependencies @@ -194,8 +190,7 @@ so in theory there’s no reason that different versions of the same external dependency couldn’t both be declared in the build system under different names. That way, each target could choose which version of the dependency it wanted to use. This causes a lot of problems in practice, so Google enforces a strict -[One-Version -Rule](https://opensource.google/docs/thirdparty/oneversion/) for +[One-Version Rule](https://opensource.google/docs/thirdparty/oneversion/) for all third-party dependencies in our codebase. The biggest problem with allowing multiple versions is the diamond dependency @@ -234,8 +229,7 @@ Bazel did not use to automatically download transitive dependencies. It used to employ a `WORKSPACE` file that required all transitive dependencies to be listed, which led to a lot of pain when managing external dependencies. Bazel has since added support for automatic transitive external dependency management -in the form of the `MODULE.bazel` file. See [external dependency -overview](/external/overview) for more details. +in the form of the `MODULE.bazel` file. See [external dependency overview](/external/overview) for more details. Yet again, the choice here is one between convenience and scalability. Small projects might prefer not having to worry about managing transitive dependencies diff --git a/community/images/hermetiq-logo.png b/community/images/hermetiq-logo.png new file mode 100644 index 00000000..90765d96 Binary files /dev/null and b/community/images/hermetiq-logo.png differ diff --git a/community/sig.mdx b/community/sig.mdx index ae5f9189..3b4d6635 100644 --- a/community/sig.mdx +++ b/community/sig.mdx @@ -5,8 +5,7 @@ title: 'Bazel Special Interest Groups' Bazel hosts Special Interest Groups (SIGs) to focus collaboration on particular -areas and to support communication and coordination between [Bazel owners, -maintainers, and contributors](/contribute/policy). This policy +areas and to support communication and coordination between [Bazel owners, maintainers, and contributors](/contribute/policy). This policy applies to [`bazelbuild`](http://github.com/bazelbuild). SIGs do their work in public. The ideal scope for a SIG covers a well-defined diff --git a/community/users.mdx b/community/users.mdx index 25835f3d..227ee4bb 100644 --- a/community/users.mdx +++ b/community/users.mdx @@ -320,11 +320,9 @@ safety systems_. Pigweed is an open-source solution for sustained, robust, and rapid embedded product development for large teams. Pigweed has shipped in millions of devices, including Google's suite of Pixel devices, Nest thermostats, -[satellites](https://www.spinlaunch.com/), and [autonomous aerial -drones](https://www.flyzipline.com/). +[satellites](https://www.spinlaunch.com/), and [autonomous aerial drones](https://www.flyzipline.com/). -Pigweed [uses Bazel as its primary build -system](https://pigweed.dev/seed/0111-build-systems.html). The [Bazel for +Pigweed [uses Bazel as its primary build system](https://pigweed.dev/seed/0111-build-systems.html). The [Bazel for Embedded][pw-bazel-great] blog post discusses why we think it's a great build system for embedded projects! diff --git a/concepts/build-ref.mdx b/concepts/build-ref.mdx index 67c5f1bd..ee67bcc6 100644 --- a/concepts/build-ref.mdx +++ b/concepts/build-ref.mdx @@ -19,8 +19,7 @@ its root; such a boundary marker file could be `MODULE.bazel`, `REPO.bazel`, or in legacy contexts, `WORKSPACE` or `WORKSPACE.bazel`. The repo in which the current Bazel command is being run is called the _main -repo_. Other, (external) repos are defined by _repo rules_; see [external -dependencies overview](/external/overview) for more information. +repo_. Other, (external) repos are defined by _repo rules_; see [external dependencies overview](/external/overview) for more information. ## Workspace {#workspace} @@ -97,5 +96,4 @@ have three properties: the list of packages they contain, their name, and other package groups they include. The only allowed ways to refer to them are from the `visibility` attribute of rules or from the `default_visibility` attribute of the `package` function; they do not generate or consume files. For more -information, refer to the [`package_group` -documentation](/reference/be/functions#package_group). +information, refer to the [`package_group` documentation](/reference/be/functions#package_group). diff --git a/concepts/labels.mdx b/concepts/labels.mdx index aec9adcf..3f14e001 100644 --- a/concepts/labels.mdx +++ b/concepts/labels.mdx @@ -12,8 +12,7 @@ form looks like: ``` The first part of the label is the repository name, `@@myrepo`. The double-`@` -syntax signifies that this is a [*canonical* repo -name](/external/overview#canonical-repo-name), which is unique within +syntax signifies that this is a [*canonical* repo name](/external/overview#canonical-repo-name), which is unique within the workspace. Labels with canonical repo names unambiguously identify a target no matter which context they appear in. diff --git a/concepts/platforms.mdx b/concepts/platforms.mdx index 591ef313..09cede52 100644 --- a/concepts/platforms.mdx +++ b/concepts/platforms.mdx @@ -79,8 +79,7 @@ To test your Android project with platforms, see for support. You can still use platform APIs with Apple builds (for example, when building -with a mixture of Apple rules and pure C++) with [platform -mappings](#platform-mappings). +with a mixture of Apple rules and pure C++) with [platform mappings](#platform-mappings). ### Other languages {#other-languages} @@ -244,8 +243,7 @@ sets `--cpu`, `--crossstool_top`, or other legacy flags, rules that read When migrating your project to platforms, you must either convert changes like `return { "//command_line_option:cpu": "arm" }` to `return { -"//command_line_option:platforms": "//:my_arm_platform" }` or use [platform -mappings](#platform-mappings) to support both styles during migration. +"//command_line_option:platforms": "//:my_arm_platform" }` or use [platform mappings](#platform-mappings) to support both styles during migration. window. ## Migrating your rule set {#migrating-your-rule-set} @@ -364,10 +362,8 @@ attributes declare a language's tools (like `compiler = this information to rules that need to build with these tools. Toolchains declare the `constraint_value`s of machines they can -[target][target_compatible_with Attribute] -(`target_compatible_with = ["@platforms//os:linux"]`) and machines their tools can -[run on][exec_compatible_with Attribute] -(`exec_compatible_with = ["@platforms//os:mac"]`). +[target][target_compatible_with Attribute](`target_compatible_with = ["@platforms//os:linux"]`) and machines their tools can +[run on][exec_compatible_with Attribute](`exec_compatible_with = ["@platforms//os:mac"]`). When building `$ bazel build //:myproject --platforms=//:myplatform`, Bazel automatically selects a toolchain that can run on the build machine and diff --git a/configure/attributes.mdx b/configure/attributes.mdx index 7f4936bb..4f03c453 100644 --- a/configure/attributes.mdx +++ b/configure/attributes.mdx @@ -4,8 +4,7 @@ title: 'Configurable Build Attributes' -**_Configurable attributes_**, commonly known as [`select()`]( -/reference/be/functions#select), is a Bazel feature that lets users toggle the values +**_Configurable attributes_**, commonly known as [`select()`](/reference/be/functions#select), is a Bazel feature that lets users toggle the values of build rule attributes at the command line. This can be used, for example, for a multiplatform library that automatically @@ -409,8 +408,7 @@ sh_library( ) ``` -If you need a `select` to match when multiple conditions match, consider [AND -chaining](#and-chaining). +If you need a `select` to match when multiple conditions match, consider [AND chaining](#and-chaining). ## OR chaining {#or-chaining} diff --git a/configure/integrate-cpp.mdx b/configure/integrate-cpp.mdx index b9ba8840..599fbd8f 100644 --- a/configure/integrate-cpp.mdx +++ b/configure/integrate-cpp.mdx @@ -14,8 +14,7 @@ To depend on a C++ toolchain in your rule, set the `toolchains` parameter to `use_cc_toolchain()`. Then, in the rule implementation, use `find_cpp_toolchain(ctx)` to get the [`CcToolchainInfo`](/rules/lib/providers/CcToolchainInfo). A complete working -example can be found [in the rules_cc -examples](https://github.com/bazelbuild/rules_cc/blob/main/examples/write_cc_toolchain_cpu/write_cc_toolchain_cpu.bzl). +example can be found [in the rules_cc examples](https://github.com/bazelbuild/rules_cc/blob/main/examples/write_cc_toolchain_cpu/write_cc_toolchain_cpu.bzl). ## Generating command lines and environment variables using the C++ toolchain {#generate-command-lines-toolchain} @@ -25,8 +24,7 @@ This is because when writing our own actions, they must behave consistently with the C++ toolchain - for example, passing C++ command line flags to a tool that invokes the C++ compiler behind the scenes. -C++ rules use a special way of constructing command lines based on [feature -configuration](/docs/cc-toolchain-config-reference). To construct a command line, +C++ rules use a special way of constructing command lines based on [feature configuration](/docs/cc-toolchain-config-reference). To construct a command line, you need the following: * `features` and `action_configs` - these come from the `CcToolchainConfigInfo` diff --git a/configure/windows.mdx b/configure/windows.mdx index 46e6073b..573f660d 100644 --- a/configure/windows.mdx +++ b/configure/windows.mdx @@ -162,8 +162,7 @@ To build C++ targets with MSVC, you need: set BAZEL_VC=C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC ``` -* The [Windows - SDK](https://developer.microsoft.com/en-us/windows/downloads/windows-10-sdk). +* The [Windows SDK](https://developer.microsoft.com/en-us/windows/downloads/windows-10-sdk). The Windows SDK contains header files and libraries you need when building Windows applications, including Bazel itself. By default, the latest Windows SDK installed will @@ -182,8 +181,7 @@ To build C++ targets with MSVC, you need: If everything is set up, you can build a C++ target now! -Try building a target from one of our [sample -projects](https://github.com/bazelbuild/bazel/tree/master/examples): +Try building a target from one of our [sample projects](https://github.com/bazelbuild/bazel/tree/master/examples): ``` \ No newline at end of file diff --git a/contribute/images/structured-concurrency.svg b/contribute/images/structured-concurrency.svg new file mode 100644 index 00000000..0258d9a9 --- /dev/null +++ b/contribute/images/structured-concurrency.svg @@ -0,0 +1 @@ + \ No newline at end of file diff --git a/contribute/images/suspend-resume.svg b/contribute/images/suspend-resume.svg new file mode 100644 index 00000000..7de1218f --- /dev/null +++ b/contribute/images/suspend-resume.svg @@ -0,0 +1 @@ + \ No newline at end of file diff --git a/contribute/images/unstructured-concurrency.svg b/contribute/images/unstructured-concurrency.svg new file mode 100644 index 00000000..0951639a --- /dev/null +++ b/contribute/images/unstructured-concurrency.svg @@ -0,0 +1 @@ + \ No newline at end of file diff --git a/contribute/index.mdx b/contribute/index.mdx index da2cd1b1..a0a279a7 100644 --- a/contribute/index.mdx +++ b/contribute/index.mdx @@ -12,8 +12,7 @@ As you use Bazel, you may find things that can be improved. You can help by [reporting issues](http://github.com/bazelbuild/bazel/issues) when: - - Bazel crashes or you encounter a bug that can [only be resolved using `bazel - clean`](/run/build#correct-incremental-rebuilds). + - Bazel crashes or you encounter a bug that can [only be resolved using `bazel clean`](/run/build#correct-incremental-rebuilds). - The documentation is incomplete or unclear. You can also report issues from the page you are viewing by using the "Create issue" link at the top right corner of the page. @@ -23,11 +22,9 @@ when: You can engage with the Bazel community by: - - Answering questions [on Stack Overflow]( - https://stackoverflow.com/questions/tagged/bazel). + - Answering questions [on Stack Overflow](https://stackoverflow.com/questions/tagged/bazel). - Helping other users [on Slack](https://slack.bazel.build). - - Improving documentation or [contributing examples]( - https://github.com/bazelbuild/examples). + - Improving documentation or [contributing examples](https://github.com/bazelbuild/examples). - Sharing your experience or your tips, for example, on a blog or social media. ## Contribute code {#contribute-code} @@ -42,8 +39,7 @@ You can contribute to the Bazel ecosystem by: - Contributing to Bazel-related tools, for example, migration tools. - Improving Bazel integration with other IDEs and tools. -Before making a change, [create a GitHub -issue](http://github.com/bazelbuild/bazel/issues) +Before making a change, [create a GitHub issue](http://github.com/bazelbuild/bazel/issues) or email [bazel-discuss@](mailto:bazel-discuss@googlegroups.com). The most helpful contributions fix bugs or add features (as opposed diff --git a/contribute/maintainers-guide.mdx b/contribute/maintainers-guide.mdx index 28f7c476..a2331742 100644 --- a/contribute/maintainers-guide.mdx +++ b/contribute/maintainers-guide.mdx @@ -6,8 +6,7 @@ title: 'Guide for Bazel Maintainers' This is a guide for the maintainers of the Bazel open source project. -If you are looking to contribute to Bazel, read [Contributing to -Bazel](/contribute) instead. +If you are looking to contribute to Bazel, read [Contributing to Bazel](/contribute) instead. The objectives of this page are to: @@ -39,8 +38,7 @@ repository. 1. A user creates an issue by choosing one of the [issue templates](https://github.com/bazelbuild/bazel/issues/new/choose) - and it enters the pool of [unreviewed open - issues](https://github.com/bazelbuild/bazel/issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aopen+-label%3Auntriaged+-label%3Ap2+-label%3Ap1+-label%3Ap3+-label%3Ap4+-label%3Ateam-Starlark+-label%3Ateam-Rules-CPP+-label%3Ateam-Rules-Java+-label%3Ateam-XProduct+-label%3Ateam-Android+-label%3Ateam-Apple+-label%3Ateam-Configurability++-label%3Ateam-Performance+-label%3Ateam-Rules-Server+-label%3Ateam-Core+-label%3Ateam-Rules-Python+-label%3Ateam-Remote-Exec+-label%3Ateam-Local-Exec+-label%3Ateam-Bazel). + and it enters the pool of [unreviewed open issues](https://github.com/bazelbuild/bazel/issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aopen+-label%3Auntriaged+-label%3Ap2+-label%3Ap1+-label%3Ap3+-label%3Ap4+-label%3Ateam-Starlark+-label%3Ateam-Rules-CPP+-label%3Ateam-Rules-Java+-label%3Ateam-XProduct+-label%3Ateam-Android+-label%3Ateam-Apple+-label%3Ateam-Configurability++-label%3Ateam-Performance+-label%3Ateam-Rules-Server+-label%3Ateam-Core+-label%3Ateam-Rules-Python+-label%3Ateam-Remote-Exec+-label%3Ateam-Local-Exec+-label%3Ateam-Bazel). 1. A member on the Developer Experience (DevEx) subteam rotation reviews the issue. 1. If the issue is **not a bug** or a **feature request**, the DevEx member @@ -60,21 +58,18 @@ repository. 1. After reviewing the issue, the DevEx member decides if the issue requires immediate attention. If it does, they will assign the **P0** [priority](#priority) label and an owner from the list of team leads. -1. The DevEx member assigns the `untriaged` label and exactly one [team - label](#team-labels) for routing. +1. The DevEx member assigns the `untriaged` label and exactly one [team label](#team-labels) for routing. 1. The DevEx member also assigns exactly one `type:` label, such as `type: bug` or `type: feature request`, according to the type of the issue. 1. For platform-specific issues, the DevEx member assigns one `platform:` label, such as `platform:apple` for Mac-specific issues. 1. If the issue is low priority and can be worked on by a new community contributor, the DevEx member assigns the `good first issue` label. -At this stage, the issue enters the pool of [untriaged open -issues](https://github.com/bazelbuild/bazel/issues?q=is%3Aissue+is%3Aopen+label%3Auntriaged). +At this stage, the issue enters the pool of [untriaged open issues](https://github.com/bazelbuild/bazel/issues?q=is%3Aissue+is%3Aopen+label%3Auntriaged). Each Bazel subteam will triage all issues under labels they own, preferably on a weekly basis. The subteam will review and evaluate the issue and provide a -resolution, if possible. If you are an owner of a team label, see [this section -](#label-own) for more information. +resolution, if possible. If you are an owner of a team label, see [this section](#label-own) for more information. When an issue is resolved, it can be closed. @@ -114,8 +109,7 @@ preferably on a weekly basis. issue is either P0 or P1 we assume that is actively worked on. 1. Remove the `untriaged` label. -Note that you need to be in the [bazelbuild -organization](https://github.com/bazelbuild) to be able to add or remove labels. +Note that you need to be in the [bazelbuild organization](https://github.com/bazelbuild) to be able to add or remove labels. ### Pull Requests {#pull-requests} @@ -168,8 +162,7 @@ issues. unusable, or a downed service that severely impacts development of the Bazel project. This includes regressions introduced in a new release that blocks a significant number of users, or an incompatible breaking change that was not - compliant to the [Breaking - Change](https://docs.google.com/document/d/1q5GGRxKrF_mnwtaPKI487P8OdDRh2nN7jX6U-FXnHL0/edit?pli=1#heading=h.ceof6vpkb3ik) + compliant to the [Breaking Change](https://docs.google.com/document/d/1q5GGRxKrF_mnwtaPKI487P8OdDRh2nN7jX6U-FXnHL0/edit?pli=1#heading=h.ceof6vpkb3ik) policy. No practical workaround exists. * [**P1**](https://github.com/bazelbuild/bazel/labels/P1) - Critical defect or feature which should be addressed in the next release, or a serious issue that diff --git a/contribute/naming.mdx b/contribute/naming.mdx index 92eb9354..5c71e429 100644 --- a/contribute/naming.mdx +++ b/contribute/naming.mdx @@ -6,8 +6,7 @@ title: 'Naming a Bazel related project' First, thank you for contributing to the Bazel ecosystem! Please reach out to the Bazel community on the -[bazel-discuss mailing list](https://groups.google.com/forum/#!forum/bazel-discuss -) to share your project and its suggested name. +[bazel-discuss mailing list](https://groups.google.com/forum/#!forum/bazel-discuss) to share your project and its suggested name. If you are building a Bazel related tool or sharing your Skylark rules, we recommend following these guidelines for the name of your project: diff --git a/contribute/patch-acceptance.mdx b/contribute/patch-acceptance.mdx index 867c046f..2fca9f1a 100644 --- a/contribute/patch-acceptance.mdx +++ b/contribute/patch-acceptance.mdx @@ -13,19 +13,16 @@ code base. need a corresponding issue for tracking. 1. If you're proposing significant changes, write a [design document](/contribute/design-documents). -1. Ensure you've signed a [Contributor License - Agreement](https://cla.developers.google.com). +1. Ensure you've signed a [Contributor License Agreement](https://cla.developers.google.com). 1. Prepare a git commit that implements the feature. Don't forget to add tests and update the documentation. If your change has user-visible effects, please [add release notes](/contribute/release-notes). If it is an incompatible change, read the [guide for rolling out breaking changes](/contribute/breaking-changes). 1. Create a pull request on [GitHub](https://github.com/bazelbuild/bazel/pulls). If you're new to GitHub, - read [about pull - requests](https://help.github.com/articles/about-pull-requests/). Note that + read [about pull requests](https://help.github.com/articles/about-pull-requests/). Note that we restrict permissions to create branches on the main Bazel repository, so - you will need to push your commit to [your own fork of the - repository](https://help.github.com/articles/working-with-forks/). + you will need to push your commit to [your own fork of the repository](https://help.github.com/articles/working-with-forks/). 1. A Bazel maintainer should assign you a reviewer within 7 business days (excluding holidays in the USA and Germany). If you aren't assigned a reviewer in that time, you can ping `@bazelbuild/triage` on the PR. diff --git a/contribute/release-notes.mdx b/contribute/release-notes.mdx index 61973e75..fd78602a 100644 --- a/contribute/release-notes.mdx +++ b/contribute/release-notes.mdx @@ -18,8 +18,7 @@ the release announcement. * If the change adds / removes / changes Bazel in a user-visible way, then it may be advantageous to mention it. -If the change is significant, follow the [design document -policy](/contribute/design-documents) first. +If the change is significant, follow the [design document policy](/contribute/design-documents) first. ## Guidelines {#guidelines} @@ -62,10 +61,8 @@ change is about. ## Process {#process} -As part of the [release -process](https://github.com/bazelbuild/continuous-integration/blob/master/docs/release-playbook.md), -we collect the `RELNOTES` tags of every commit. We copy everything in a [Google -Doc](https://docs.google.com/document/d/1wDvulLlj4NAlPZamdlEVFORks3YXJonCjyuQMUQEmB0/edit) +As part of the [release process](https://github.com/bazelbuild/continuous-integration/blob/master/docs/release-playbook.md), +we collect the `RELNOTES` tags of every commit. We copy everything in a [Google Doc](https://docs.google.com/document/d/1wDvulLlj4NAlPZamdlEVFORks3YXJonCjyuQMUQEmB0/edit) where we review, edit, and organize the notes. The release manager sends an email to the @@ -73,6 +70,4 @@ The release manager sends an email to the Bazel contributors are invited to contribute to the document and make sure their changes are correctly reflected in the announcement. -Later, the announcement will be submitted to the [Bazel -blog](https://blog.bazel.build/), using the [bazel-blog -repository](https://github.com/bazelbuild/bazel-blog/tree/master/_posts). +Later, the announcement will be submitted to the [Bazel blog](https://blog.bazel.build/), using the [bazel-blog repository](https://github.com/bazelbuild/bazel-blog/tree/master/_posts). diff --git a/contribute/statemachine-guide.mdx b/contribute/statemachine-guide.mdx index 69f2187e..4db66dfa 100644 --- a/contribute/statemachine-guide.mdx +++ b/contribute/statemachine-guide.mdx @@ -174,8 +174,7 @@ instead, batches[^4] as many lookups as possible before doing so. The value might not be immediately available, for example, requiring a Skyframe restart, so the caller specifies what to do with the resulting value using a callback. -The `StateMachine` processor ([`Driver`s and bridging to -SkyFrame](#drivers-and-bridging)) guarantees that the value is available before +The `StateMachine` processor ([`Driver`s and bridging to SkyFrame](#drivers-and-bridging)) guarantees that the value is available before the next state begins. An example follows. ``` @@ -286,8 +285,7 @@ and solutions to certain control flow problems. ### Sequential states This is the most common and straightforward control flow pattern. An example of -this is shown in [Stateful computations inside -`SkyKeyComputeState`](#stateful-computations). +this is shown in [Stateful computations inside `SkyKeyComputeState`](#stateful-computations). ### Branching @@ -547,8 +545,7 @@ section describes the propagation of data values. ### Implementing `Tasks.lookUp` callbacks -There’s an example of implementing a `Tasks.lookUp` callback in [SkyValue -lookups](#skyvalue-lookups). This section provides rationale and suggests +There’s an example of implementing a `Tasks.lookUp` callback in [SkyValue lookups](#skyvalue-lookups). This section provides rationale and suggests approaches for handling multiple SkyValues. #### `Tasks.lookUp` callbacks {#tasks-lookup-callbacks} @@ -712,8 +709,7 @@ class BarProducer implements StateMachine { Tip: It would be tempting to use the more concise signature void `accept(Bar value)` rather than the stuttery `void acceptBarValue(Bar value)` above. However, `Consumer` is a common overload of `void accept(Bar value)`, -so doing this often leads to violations of the [Overloads: never -split](https://google.github.io/styleguide/javaguide.html#s3.4.2-ordering-class-contents) +so doing this often leads to violations of the [Overloads: never split](https://google.github.io/styleguide/javaguide.html#s3.4.2-ordering-class-contents) style-guide rule. Tip: Using a custom `ResultSink` type instead of a generic one from @@ -776,14 +772,11 @@ pattern after accepting output from either a subtask or SkyValue lookup. Note that the implementation of `acceptBarError` eagerly forwards the result to the `Caller.ResultSink`, as required by [Error bubbling](#error-bubbling). -Alternatives for top-level `StateMachine`s are described in [`Driver`s and -bridging to SkyFunctions](#drivers-and-bridging). +Alternatives for top-level `StateMachine`s are described in [`Driver`s and bridging to SkyFunctions](#drivers-and-bridging). ### Error handling {#error-handling} -There's a couple of examples of error handling already in [`Tasks.lookUp` -callbacks](#tasks-lookup-callbacks) and [Propagating values between -`StateMachines`](#propagating-values). Exceptions, other than +There's a couple of examples of error handling already in [`Tasks.lookUp` callbacks](#tasks-lookup-callbacks) and [Propagating values between `StateMachines`](#propagating-values). Exceptions, other than `InterruptedException` are not thrown, but instead passed around through callbacks as values. Such callbacks often have exclusive-or semantics, with exactly one of a value or error being passed. @@ -1186,8 +1179,7 @@ states. Where it is possible, local stack `step` variables are young generation variables and efficiently GC'd. For `StateMachine` variables, breaking things down into subtasks and following -the recommended pattern for [Propagating values between -`StateMachine`s](#propagating-values) is also helpful. Observe that when +the recommended pattern for [Propagating values between `StateMachine`s](#propagating-values) is also helpful. Observe that when following the pattern, only child `StateMachine`s have references to parent `StateMachine`s and not vice versa. This means that as children complete and update the parents using result callbacks, the children naturally fall out of @@ -1209,8 +1201,7 @@ potentially reflecting local behavior. ### Concurrency tree diagram {#concurrency-tree-diagram} -The following is an alternative view of the diagram in [Structured -concurrency](#structured-concurrency) that better depicts the tree structure. +The following is an alternative view of the diagram in [Structured concurrency](#structured-concurrency) that better depicts the tree structure. The blocks form a small tree. ![Structured Concurrency 3D](/contribute/images/structured-concurrency-3d.svg) diff --git a/docs/android-instrumentation-test.mdx b/docs/android-instrumentation-test.mdx index 82fb7b1e..e7be4e54 100644 --- a/docs/android-instrumentation-test.mdx +++ b/docs/android-instrumentation-test.mdx @@ -4,8 +4,7 @@ title: 'Android Instrumentation Tests' -_If you're new to Bazel, start with the [Building Android with -Bazel](/start/android-app ) tutorial._ +_If you're new to Bazel, start with the [Building Android with Bazel](/start/android-app) tutorial._ ![Running Android instrumentation tests in parallel](/docs/images/android_test.gif "Android instrumentation test") @@ -20,9 +19,7 @@ emulators in a sandbox, ensuring that tests always run from a clean state. Each test gets an isolated emulator instance, allowing tests to run in parallel without passing states between them. -For more information on Android instrumentation tests, check out the [Android -developer -documentation](https://developer.android.com/training/testing/unit-testing/instrumented-unit-tests.html). +For more information on Android instrumentation tests, check out the [Android developer documentation](https://developer.android.com/training/testing/unit-testing/instrumented-unit-tests.html). Please file issues in the [GitHub issue tracker](https://github.com/bazelbuild/bazel/issues). @@ -60,8 +57,7 @@ This results in output similar to the following: release 4.1.0 ``` -- **KVM**. Bazel requires emulators to have [hardware - acceleration](https://developer.android.com/studio/run/emulator-acceleration.html#accel-check) +- **KVM**. Bazel requires emulators to have [hardware acceleration](https://developer.android.com/studio/run/emulator-acceleration.html#accel-check) with KVM on Linux. You can follow these [installation instructions](https://help.ubuntu.com/community/KVM/Installation) for Ubuntu. @@ -176,11 +172,9 @@ The main attributes of the rule `android_instrumentation_test` are: - `target_device`: An `android_device` target. This target describes the specifications of the Android emulator which Bazel uses to create, launch and - run the tests. See the [section on choosing an Android - device](#android-device-target) for more information. + run the tests. See the [section on choosing an Android device](#android-device-target) for more information. -The test app's `AndroidManifest.xml` must include [an `` -tag](https://developer.android.com/studio/test/#configure_instrumentation_manifest_settings). +The test app's `AndroidManifest.xml` must include [an `` tag](https://developer.android.com/studio/test/#configure_instrumentation_manifest_settings). This tag must specify the attributes for the **package of the target app** and the **fully qualified class name of the instrumentation test runner**, `androidx.test.runner.AndroidJUnitRunner`. @@ -217,8 +211,7 @@ repositories: - `@androidsdk`: The Android SDK. Download this through Android Studio. - `@android_test_support`: Hosts the test runner, emulator launcher, and - `android_device` targets. You can find the [latest release - here](https://github.com/android/android-test/releases). + `android_device` targets. You can find the [latest release here](https://github.com/android/android-test/releases). Enable these dependencies by adding the following lines to your `WORKSPACE` file: @@ -244,8 +237,7 @@ android_test_repositories() ## Maven dependencies {#maven-dependencies} -For managing dependencies on Maven artifacts from repositories, such as [Google -Maven](https://maven.google.com) or [Maven Central](https://central.maven.org), +For managing dependencies on Maven artifacts from repositories, such as [Google Maven](https://maven.google.com) or [Maven Central](https://central.maven.org), you should use a Maven resolver, such as [`rules_jvm_external`](https://github.com/bazelbuild/rules_jvm_external). @@ -374,8 +366,7 @@ the device/emulator listed in `adb devices`. ## Sample projects {#sample-projects} -If you are looking for canonical project samples, see the [Android testing -samples](https://github.com/googlesamples/android-testing#experimental-bazel-support) +If you are looking for canonical project samples, see the [Android testing samples](https://github.com/googlesamples/android-testing#experimental-bazel-support) for projects using Espresso and UIAutomator. ## Espresso setup {#espresso-setup} @@ -564,8 +555,7 @@ API_LEVELS = [ ## Known issues {#known-issues} -- [Forked adb server processes are not terminated after - tests](https://github.com/bazelbuild/bazel/issues/4853) +- [Forked adb server processes are not terminated after tests](https://github.com/bazelbuild/bazel/issues/4853) - While APK building works on all platforms (Linux, macOS, Windows), testing only works on Linux. - Even with `--config=local_adb`, users still need to specify diff --git a/docs/android-ndk.mdx b/docs/android-ndk.mdx index 363b3620..abd76409 100644 --- a/docs/android-ndk.mdx +++ b/docs/android-ndk.mdx @@ -4,8 +4,7 @@ title: 'Using the Android Native Development Kit with Bazel' -_If you're new to Bazel, please start with the [Building Android with -Bazel](/start/android-app ) tutorial._ +_If you're new to Bazel, please start with the [Building Android with Bazel](/start/android-app) tutorial._ ## Overview {#overview} @@ -157,8 +156,7 @@ more details. ## Example setup {#example-setup} -This example is available in the [Bazel examples -repository](https://github.com/bazelbuild/examples/tree/master/android/ndk). +This example is available in the [Bazel examples repository](https://github.com/bazelbuild/examples/tree/master/android/ndk). In the `BUILD.bazel` file, three targets are defined with the `android_binary`, `android_library`, and `cc_library` rules. diff --git a/docs/bazel-and-android.mdx b/docs/bazel-and-android.mdx index fcb65e56..d447f3f9 100644 --- a/docs/bazel-and-android.mdx +++ b/docs/bazel-and-android.mdx @@ -12,7 +12,7 @@ Android projects with Bazel. The following resources will help you work with Bazel on Android projects: -* [Tutorial: Building an Android app](/start/android-app ). This +* [Tutorial: Building an Android app](/start/android-app). This tutorial is a good place to start learning about Bazel commands and concepts, and how to build Android apps with Bazel. * [Codelab: Building Android Apps with Bazel](https://developer.android.com/codelabs/bazel-android-intro#0). diff --git a/docs/configurable-attributes.mdx b/docs/configurable-attributes.mdx index 075431b7..8048f3a6 100644 --- a/docs/configurable-attributes.mdx +++ b/docs/configurable-attributes.mdx @@ -4,8 +4,7 @@ title: 'Configurable Build Attributes' -**_Configurable attributes_**, commonly known as [`select()`]( -/reference/be/functions#select), is a Bazel feature that lets users toggle the values +**_Configurable attributes_**, commonly known as [`select()`](/reference/be/functions#select), is a Bazel feature that lets users toggle the values of build rule attributes at the command line. This can be used, for example, for a multiplatform library that automatically @@ -410,8 +409,7 @@ sh_library( ) ``` -If you need a `select` to match when multiple conditions match, consider [AND -chaining](#and-chaining). +If you need a `select` to match when multiple conditions match, consider [AND chaining](#and-chaining). ## OR chaining {#or-chaining} diff --git a/docs/images/a_b_a_c.svg b/docs/images/a_b_a_c.svg new file mode 100644 index 00000000..d38be075 --- /dev/null +++ b/docs/images/a_b_a_c.svg @@ -0,0 +1,42 @@ + + + + + + +G + + + +a + +a + + + +b + +b + + + +a->b + + + + + +c + +c + + + +a->c + + + + + + diff --git a/docs/images/a_b_c.svg b/docs/images/a_b_c.svg new file mode 100644 index 00000000..acd948ab --- /dev/null +++ b/docs/images/a_b_c.svg @@ -0,0 +1,41 @@ + + + + + + +G + + + +a + +a + + + +b + +b + + + +a->b + + + + + +c + +c + + + +b->c + + + + + diff --git a/docs/images/a_b_c_ac.svg b/docs/images/a_b_c_ac.svg new file mode 100644 index 00000000..b099c53e --- /dev/null +++ b/docs/images/a_b_c_ac.svg @@ -0,0 +1,47 @@ + + + + + + +G + + + +a + +a + + + +b + +b + + + +a->b + + + + + +c + +c + + + +a->c + + + + + +b->c + + + + + diff --git a/docs/images/ab_c.svg b/docs/images/ab_c.svg new file mode 100644 index 00000000..bcc4563f --- /dev/null +++ b/docs/images/ab_c.svg @@ -0,0 +1,36 @@ + + + + + + +G + + + +a + +a + + + +b + +b + + + +a->b + + + + + +c + +c + + + + diff --git a/docs/images/allpaths.svg b/docs/images/allpaths.svg new file mode 100644 index 00000000..47d0ee33 --- /dev/null +++ b/docs/images/allpaths.svg @@ -0,0 +1,141 @@ + + + + + + +allpaths + + + +n1 + + + + +n2 + + + + +n1->n2 + + + + + +n3 + + + + +n2->n3 + + + + + +n10 + + + + +n2->n10 + + + + + +n3->n10 + + + + + +n4 + +E + + + +n5 + + + + +n6 + + + + +n5->n6 + + + + + +n6->n4 + + + + + +n9 + + + + +n6->n9 + + + + + +n7 + +S1 + + + +n7->n2 + + + + + +n7->n5 + + + + + +n8 + +S2 + + + +n8->n6 + + + + + +n10->n4 + + + + + +n11 + + + + +n10->n11 + + + + + diff --git a/docs/images/android_instrumentation_test.png b/docs/images/android_instrumentation_test.png new file mode 100644 index 00000000..e4534fbd Binary files /dev/null and b/docs/images/android_instrumentation_test.png differ diff --git a/docs/images/android_ndk.png b/docs/images/android_ndk.png new file mode 100644 index 00000000..76b63cb3 Binary files /dev/null and b/docs/images/android_ndk.png differ diff --git a/docs/images/android_tutorial_app.png b/docs/images/android_tutorial_app.png new file mode 100644 index 00000000..076be5b9 Binary files /dev/null and b/docs/images/android_tutorial_app.png differ diff --git a/docs/images/android_tutorial_before.png b/docs/images/android_tutorial_before.png new file mode 100644 index 00000000..8e41d419 Binary files /dev/null and b/docs/images/android_tutorial_before.png differ diff --git a/docs/images/bep-graph.png b/docs/images/bep-graph.png new file mode 100644 index 00000000..82da6715 Binary files /dev/null and b/docs/images/bep-graph.png differ diff --git a/docs/images/bep-graph.svg b/docs/images/bep-graph.svg new file mode 100644 index 00000000..62b1480f --- /dev/null +++ b/docs/images/bep-graph.svg @@ -0,0 +1,4 @@ + + + + diff --git a/docs/images/cpp-tutorial-stage1.png b/docs/images/cpp-tutorial-stage1.png new file mode 100644 index 00000000..c85fb303 Binary files /dev/null and b/docs/images/cpp-tutorial-stage1.png differ diff --git a/docs/images/cpp-tutorial-stage2.png b/docs/images/cpp-tutorial-stage2.png new file mode 100644 index 00000000..80e202c9 Binary files /dev/null and b/docs/images/cpp-tutorial-stage2.png differ diff --git a/docs/images/cpp-tutorial-stage3.png b/docs/images/cpp-tutorial-stage3.png new file mode 100644 index 00000000..54d82f31 Binary files /dev/null and b/docs/images/cpp-tutorial-stage3.png differ diff --git a/docs/images/deps.svg b/docs/images/deps.svg new file mode 100644 index 00000000..4354222a --- /dev/null +++ b/docs/images/deps.svg @@ -0,0 +1,101 @@ + + + + + + +G1 + + + +r1 + +rule + + + +s1 + +in + + + +r1->s1 + + + + + +s2 + +in + + + +r1->s2 + + + + + +s3 + +in + + + +r1->s3 + + + + + +r2 + +rule + + + +r2->r1 + + + + + +s4 + +in + + + +r2->s4 + + + + + +o1 + +out + + + +o1->r1 + + + + + +o2 + +out + + + +o2->r2 + + + + + diff --git a/docs/images/dyn-trace-alldynamic.png b/docs/images/dyn-trace-alldynamic.png new file mode 100644 index 00000000..fe36b253 Binary files /dev/null and b/docs/images/dyn-trace-alldynamic.png differ diff --git a/docs/images/dyn-trace-javaconly.png b/docs/images/dyn-trace-javaconly.png new file mode 100644 index 00000000..2ae41e52 Binary files /dev/null and b/docs/images/dyn-trace-javaconly.png differ diff --git a/docs/images/e4b-workflow.png b/docs/images/e4b-workflow.png new file mode 100644 index 00000000..412822da Binary files /dev/null and b/docs/images/e4b-workflow.png differ diff --git a/docs/images/e4b-workflow.svg b/docs/images/e4b-workflow.svg new file mode 100644 index 00000000..1de66e02 --- /dev/null +++ b/docs/images/e4b-workflow.svg @@ -0,0 +1,4 @@ + + + + diff --git a/docs/images/error_example_1.png b/docs/images/error_example_1.png new file mode 100644 index 00000000..07ba1358 Binary files /dev/null and b/docs/images/error_example_1.png differ diff --git a/docs/images/error_example_2.png b/docs/images/error_example_2.png new file mode 100644 index 00000000..861171ee Binary files /dev/null and b/docs/images/error_example_2.png differ diff --git a/docs/images/error_example_3.png b/docs/images/error_example_3.png new file mode 100644 index 00000000..dc16eec4 Binary files /dev/null and b/docs/images/error_example_3.png differ diff --git a/docs/images/error_example_4.png b/docs/images/error_example_4.png new file mode 100644 index 00000000..84383e63 Binary files /dev/null and b/docs/images/error_example_4.png differ diff --git a/docs/images/graph_ex_1.svg b/docs/images/graph_ex_1.svg new file mode 100644 index 00000000..dd7427f4 --- /dev/null +++ b/docs/images/graph_ex_1.svg @@ -0,0 +1,131 @@ + + + + + + +mygraph + + + +//net/proto_compiler:protocol-compiler + +//net/proto_compiler:protocol-compiler + + + +//net/proto_compiler:util + +//net/proto_compiler:util + + + +//net/proto_compiler:protocol-compiler->//net/proto_compiler:util + + + + + +//net/proto_compiler:protocol-compiler-lib + +//net/proto_compiler:protocol-compiler-lib + + + +//net/proto_compiler:protocol-compiler->//net/proto_compiler:protocol-compiler-lib + + + + + +//net/proto2/bridge/public:compiler_upgrader + +//net/proto2/bridge/public:compiler_upgrader + + + +//net/proto_compiler:protocol-compiler->//net/proto2/bridge/public:compiler_upgrader + + + + + +//net/proto_compiler:parser + +//net/proto_compiler:parser + + + +//net/proto_compiler:util->//net/proto_compiler:parser + + + + + +//net/proto_compiler:proto-min-lib + +//net/proto_compiler:proto-min-lib + + + +//net/proto_compiler:protocol-compiler-lib->//net/proto_compiler:proto-min-lib + + + + + +//net/proto_compiler:protocol-compiler-lib->//net/proto_compiler:parser + + + + + +//net/proto2/bridge/internal:compiler_upgrader + +//net/proto2/bridge/internal:compiler_upgrader + + + +//net/proto2/bridge/public:compiler_upgrader->//net/proto2/bridge/internal:compiler_upgrader + + + + + +//net/proto_compiler:proto-min-lib->//net/proto_compiler:parser + + + + + +//util/regexp:regexp + +//util/regexp:regexp + + + +//net/proto_compiler:proto-min-lib->//util/regexp:regexp + + + + + +//net/proto_compiler:parser->//util/regexp:regexp + + + + + +//net/proto2/bridge/internal:compiler_upgrader->//net/proto2/bridge/public:compiler_upgrader + + + + + +//net/proto2/bridge/internal:compiler_upgrader->//net/proto_compiler:parser + + + + + diff --git a/docs/images/graph_hello-world.svg b/docs/images/graph_hello-world.svg new file mode 100644 index 00000000..93b61444 --- /dev/null +++ b/docs/images/graph_hello-world.svg @@ -0,0 +1,70 @@ + + + + + + +mygraph + + +//main:hello-world + +//main:hello-world + + +//main:hello-time + +//main:hello-time + + +//main:hello-world->//main:hello-time + + + + +//main:hello-world.cc + +//main:hello-world.cc + + +//main:hello-world->//main:hello-world.cc + + + + +//lib:hello-greet + +//lib:hello-greet + + +//main:hello-world->//lib:hello-greet + + + + +//main:hello-time.cc\n//main:hello-time.h + +//main:hello-time.cc +//main:hello-time.h + + +//main:hello-time->//main:hello-time.cc\n//main:hello-time.h + + + + +//lib:hello-greet.cc\n//lib:hello-greet.h + +//lib:hello-greet.cc +//lib:hello-greet.h + + +//lib:hello-greet->//lib:hello-greet.cc\n//lib:hello-greet.h + + + + + diff --git a/docs/images/json-trace-profile-network-usage.png b/docs/images/json-trace-profile-network-usage.png new file mode 100644 index 00000000..8a7500a6 Binary files /dev/null and b/docs/images/json-trace-profile-network-usage.png differ diff --git a/docs/images/json-trace-profile-system-load-average.png b/docs/images/json-trace-profile-system-load-average.png new file mode 100644 index 00000000..e71b420c Binary files /dev/null and b/docs/images/json-trace-profile-system-load-average.png differ diff --git a/docs/images/json-trace-profile-workers-memory-usage.png b/docs/images/json-trace-profile-workers-memory-usage.png new file mode 100644 index 00000000..806505f0 Binary files /dev/null and b/docs/images/json-trace-profile-workers-memory-usage.png differ diff --git a/docs/images/json-trace-profile.png b/docs/images/json-trace-profile.png new file mode 100644 index 00000000..538382b2 Binary files /dev/null and b/docs/images/json-trace-profile.png differ diff --git a/docs/images/mobile-install-performance.svg b/docs/images/mobile-install-performance.svg new file mode 100644 index 00000000..b139d658 --- /dev/null +++ b/docs/images/mobile-install-performance.svg @@ -0,0 +1,86 @@ + + + + + + + + + + + Build times + + + + + + + adb install + + + + + + + mobile-install + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Google Maps + + + Google+ + + + YouTube + + + 0 + + + 75 + + + 150 + + + 225 + + + 300 + + + + + + Seconds + + + + diff --git a/docs/images/namedsetoffiles-bep-graph.png b/docs/images/namedsetoffiles-bep-graph.png new file mode 100644 index 00000000..ea1e10cc Binary files /dev/null and b/docs/images/namedsetoffiles-bep-graph.png differ diff --git a/docs/images/out-ranked.svg b/docs/images/out-ranked.svg new file mode 100644 index 00000000..07e96804 --- /dev/null +++ b/docs/images/out-ranked.svg @@ -0,0 +1,71 @@ + + + + + + +mygraph + + + +//a:a + +//a:a + + + +//a:a.cc + +//a:a.cc + + + +//a:a->//a:a.cc + + + + + +//b:b + +//b:b + + + +//b:b->//a:a + + + + + +//b:b.cc + +//b:b.cc + + + +//b:b->//b:b.cc + + + + + +//c:c + +//c:c + + + +//c:c->//a:a + + + + + +//c:c->//b:b + + + + + diff --git a/docs/images/rbe-ci-1.png b/docs/images/rbe-ci-1.png new file mode 100644 index 00000000..fbe76a85 Binary files /dev/null and b/docs/images/rbe-ci-1.png differ diff --git a/docs/images/rbe-ci-2.png b/docs/images/rbe-ci-2.png new file mode 100644 index 00000000..07611889 Binary files /dev/null and b/docs/images/rbe-ci-2.png differ diff --git a/docs/images/somepath1.svg b/docs/images/somepath1.svg new file mode 100644 index 00000000..5e5f8812 --- /dev/null +++ b/docs/images/somepath1.svg @@ -0,0 +1,141 @@ + + + + + + +somepath1 + + + +n1 + + + + +n2 + + + + +n1->n2 + + + + + +n3 + + + + +n2->n3 + + + + + +n10 + + + + +n2->n10 + + + + + +n3->n10 + + + + + +n4 + +E + + + +n5 + + + + +n6 + + + + +n5->n6 + + + + + +n6->n4 + + + + + +n9 + + + + +n6->n9 + + + + + +n7 + +S1 + + + +n7->n2 + + + + + +n7->n5 + + + + + +n8 + +S2 + + + +n8->n6 + + + + + +n10->n4 + + + + + +n11 + + + + +n10->n11 + + + + + diff --git a/docs/images/somepath2.svg b/docs/images/somepath2.svg new file mode 100644 index 00000000..911f2c9b --- /dev/null +++ b/docs/images/somepath2.svg @@ -0,0 +1,141 @@ + + + + + + +somepath2 + + + +n1 + + + + +n2 + + + + +n1->n2 + + + + + +n3 + + + + +n2->n3 + + + + + +n10 + + + + +n2->n10 + + + + + +n3->n10 + + + + + +n4 + +E + + + +n5 + + + + +n6 + + + + +n5->n6 + + + + + +n6->n4 + + + + + +n9 + + + + +n6->n9 + + + + + +n7 + +S1 + + + +n7->n2 + + + + + +n7->n5 + + + + + +n8 + +S2 + + + +n8->n6 + + + + + +n10->n4 + + + + + +n11 + + + + +n10->n11 + + + + + diff --git a/docs/images/targets.svg b/docs/images/targets.svg new file mode 100644 index 00000000..82f47e74 --- /dev/null +++ b/docs/images/targets.svg @@ -0,0 +1,113 @@ + + + + + + +G1 + + + +Target + +Target + + + +Rule + +Rule + + + +Target->Rule + + + + + +File + +File + + + +Target->File + + + + + +Package group + +Package group + + + +Target->Package group + + + + + +cc_library + +cc_library + + + +Rule->cc_library + + + + + +java_test + +java_test + + + +Rule->java_test + + + + + +... + +... + + + +Rule->... + + + + + +Source + +Source + + + +File->Source + + + + + +Generated + +Generated + + + +File->Generated + + + + + diff --git a/docs/images/tutorial_java_01.svg b/docs/images/tutorial_java_01.svg new file mode 100644 index 00000000..2fe72f36 --- /dev/null +++ b/docs/images/tutorial_java_01.svg @@ -0,0 +1,29 @@ + + + + + + +mygraph + + +//:ProjectRunner + +//:ProjectRunner + + +//:src/main/java/com/example/Greeting.java\n//:src/main/java/com/example/ProjectRunner.java + +//:src/main/java/com/example/Greeting.java +//:src/main/java/com/example/ProjectRunner.java + + +//:ProjectRunner->//:src/main/java/com/example/Greeting.java\n//:src/main/java/com/example/ProjectRunner.java + + + + + diff --git a/docs/images/tutorial_java_02.svg b/docs/images/tutorial_java_02.svg new file mode 100644 index 00000000..40cbb218 --- /dev/null +++ b/docs/images/tutorial_java_02.svg @@ -0,0 +1,48 @@ + + + + + + +mygraph + + +//:ProjectRunner + +//:ProjectRunner + + +//:greeter + +//:greeter + + +//:ProjectRunner->//:greeter + + + + +//:src/main/java/com/example/ProjectRunner.java + +//:src/main/java/com/example/ProjectRunner.java + + +//:ProjectRunner->//:src/main/java/com/example/ProjectRunner.java + + + + +//:src/main/java/com/example/Greeting.java + +//:src/main/java/com/example/Greeting.java + + +//:greeter->//:src/main/java/com/example/Greeting.java + + + + + diff --git a/docs/images/tutorial_java_03.svg b/docs/images/tutorial_java_03.svg new file mode 100644 index 00000000..7d79041a --- /dev/null +++ b/docs/images/tutorial_java_03.svg @@ -0,0 +1,48 @@ + + + + + + +mygraph + + +//src/main/java/com/example/cmdline:runner + +//src/main/java/com/example/cmdline:runner + + +//src/main/java/com/example/cmdline:Runner.java + +//src/main/java/com/example/cmdline:Runner.java + + +//src/main/java/com/example/cmdline:runner->//src/main/java/com/example/cmdline:Runner.java + + + + +//:greeter + +//:greeter + + +//src/main/java/com/example/cmdline:runner->//:greeter + + + + +//:src/main/java/com/example/Greeting.java + +//:src/main/java/com/example/Greeting.java + + +//:greeter->//:src/main/java/com/example/Greeting.java + + + + + diff --git a/docs/images/workers-clean-chart.png b/docs/images/workers-clean-chart.png new file mode 100644 index 00000000..63526fc1 Binary files /dev/null and b/docs/images/workers-clean-chart.png differ diff --git a/docs/images/workers-incremental-chart.png b/docs/images/workers-incremental-chart.png new file mode 100644 index 00000000..1c62d25c Binary files /dev/null and b/docs/images/workers-incremental-chart.png differ diff --git a/docs/images/ws-diamond.png b/docs/images/ws-diamond.png new file mode 100644 index 00000000..154a7440 Binary files /dev/null and b/docs/images/ws-diamond.png differ diff --git a/docs/images/ws-line.png b/docs/images/ws-line.png new file mode 100644 index 00000000..e8bfe7a1 Binary files /dev/null and b/docs/images/ws-line.png differ diff --git a/docs/images/ws-multiline.png b/docs/images/ws-multiline.png new file mode 100644 index 00000000..f07b43b1 Binary files /dev/null and b/docs/images/ws-multiline.png differ diff --git a/docs/sandboxing.mdx b/docs/sandboxing.mdx index e5d006fe..aaadcd79 100644 --- a/docs/sandboxing.mdx +++ b/docs/sandboxing.mdx @@ -50,7 +50,7 @@ containers on Linux and `sandbox-exec` on macOS, to constrain the action within ## What sandbox strategy to use {#sandboxing-strategies} You can choose which kind of sandboxing to use, if any, with the -[strategy flags](user-manual.html#strategy-options). Using the `sandboxed` +[strategy flags](/docs/user-manual#strategy-options). Using the `sandboxed` strategy makes Bazel pick one of the sandbox implementations listed below, preferring an OS-specific sandbox to the less hermetic generic one. [Persistent workers](/remote/persistent) run in a generic sandbox if you pass diff --git a/docs/user-manual.mdx b/docs/user-manual.mdx index 95e95954..e901366a 100644 --- a/docs/user-manual.mdx +++ b/docs/user-manual.mdx @@ -1147,12 +1147,12 @@ during execution can be examined. This option causes Bazel's execution phase to print the full command line for each command prior to executing it. -
-  >>>>> # //examples/cpp:hello-world [action 'Linking examples/cpp/hello-world']
+```
+  >>>> # //examples/cpp:hello-world [action 'Linking examples/cpp/hello-world']
   (cd /home/johndoe/.cache/bazel/_bazel_johndoe/4c084335afceb392cfbe7c31afee3a9f/bazel && \
     exec env - \
     /usr/bin/gcc -o bazel-out/local-fastbuild/bin/examples/cpp/hello-world -B/usr/bin/ -Wl,-z,relro,-z,now -no-canonical-prefixes -pass-exit-codes -Wl,-S -Wl,@bazel-out/local_linux-fastbuild/bin/examples/cpp/hello-world-2.params)
-
+``` Where possible, commands are printed in a Bourne shell compatible syntax, so that they can be easily copied and pasted to a shell command prompt. diff --git a/extending/auto-exec-groups.mdx b/extending/auto-exec-groups.mdx index 36bcab48..48100b71 100644 --- a/extending/auto-exec-groups.mdx +++ b/extending/auto-exec-groups.mdx @@ -29,9 +29,7 @@ doesn't detect that ([the error](#first-error-message) is raised), you can set If you need to use multiple toolchains on a single execution platform (an action uses executable or tools from two or more toolchains), you need to manually -define [exec_groups][exec_groups] (check -[When should I use a custom exec_group?][multiple_toolchains_exec_groups] -section). +define [exec_groups][exec_groups](check [When should I use a custom exec_group?][multiple_toolchains_exec_groups] section). ## History {#history} @@ -44,8 +42,7 @@ my_rule = rule( ) ``` -Rule `my_rule` registers two toolchain types. This means that the [Toolchain -Resolution](https://bazel.build/extending/toolchains#toolchain-resolution) used +Rule `my_rule` registers two toolchain types. This means that the [Toolchain Resolution](https://bazel.build/extending/toolchains#toolchain-resolution) used to find an execution platform which supports both toolchain types. The selected execution platform was used for each registered action inside the rule, unless specified differently with [exec_groups][exec_groups]. diff --git a/extending/concepts.mdx b/extending/concepts.mdx index 3864fc88..988538fa 100644 --- a/extending/concepts.mdx +++ b/extending/concepts.mdx @@ -22,16 +22,14 @@ Before learning the more advanced concepts, first: ## Macros and rules {#macros-and-rules} A macro is a function that instantiates rules. Macros come in two flavors: -[symbolic macros](/extending/macros) (new in Bazel 8) and [legacy -macros](/extending/legacy-macros). The two flavors of macros are defined +[symbolic macros](/extending/macros) (new in Bazel 8) and [legacy macros](/extending/legacy-macros). The two flavors of macros are defined differently, but behave almost the same from the point of view of a user. A macro is useful when a `BUILD` file is getting too repetitive or too complex, as it lets you reuse some code. The function is evaluated as soon as the `BUILD` file is read. After the evaluation of the `BUILD` file, Bazel has little information about macros. If your macro generates a `genrule`, Bazel will behave *almost* as if you declared that `genrule` in the `BUILD` file. (The one -exception is that targets declared in a symbolic macro have [special visibility -semantics](/extending/macros#visibility): a symbolic macro can hide its internal +exception is that targets declared in a symbolic macro have [special visibility semantics](/extending/macros#visibility): a symbolic macro can hide its internal targets from the rest of the package.) A [rule](/extending/rules) is more powerful than a macro. It can access Bazel @@ -78,8 +76,7 @@ they will not be executed. ## Creating extensions * [Create your first macro](/rules/macro-tutorial) in order to reuse some code. - Then [learn more about macros](/extending/macros) and [using them to create - "custom verbs"](/rules/verbs-tutorial). + Then [learn more about macros](/extending/macros) and [using them to create "custom verbs"](/rules/verbs-tutorial). * [Follow the rules tutorial](/rules/rules-tutorial) to get started with rules. Next, you can read more about the [rules concepts](/extending/rules). @@ -94,8 +91,7 @@ them within reach: ## Going further In addition to [macros](/extending/macros) and [rules](/extending/rules), you -may want to write [aspects](/extending/aspects) and [repository -rules](/external/repo). +may want to write [aspects](/extending/aspects) and [repository rules](/external/repo). * Use [Buildifier](https://github.com/bazelbuild/buildtools) consistently to format and lint your code. diff --git a/extending/config.mdx b/extending/config.mdx index 436397ab..2e1331c0 100644 --- a/extending/config.mdx +++ b/extending/config.mdx @@ -45,6 +45,9 @@ set via [user-defined transitions](#user-defined-transitions). [End to end example](https://github.com/bazelbuild/examples/tree/HEAD/configurations/basic_build_setting) +Note: Before defining your own build setting, check if one of the [predefined +settings](#predefined-settings) is suitable. + #### The `build_setting` `rule()` parameter {#rule-parameter} Build settings are rules like any other rule and are differentiated using the @@ -171,6 +174,22 @@ flavor( ) ``` +#### Scope + +Build settings are by default only applied to the `target` [configuration] +(/extending/rules#configurations), and won't be applied to the `exec` +configuration. To have the build setting applied to both the `target` and `exec` +configurations set the `scope` attribute to `"universal"`. + +```python +# example/BUILD +load("@bazel_skylib//rules:common_settings.bzl", "bool_flag") +bool_flag( + name = "use_this_for_compiler_and_sources", + scope = "universal" +) +``` + ### Predefined settings {#predefined-settings} [End to end example](https://github.com/bazelbuild/examples/tree/HEAD/configurations/use_skylib_build_setting) diff --git a/extending/depsets.mdx b/extending/depsets.mdx index 4e84d3f2..8f0f31b0 100644 --- a/extending/depsets.mdx +++ b/extending/depsets.mdx @@ -113,8 +113,7 @@ need to ensure that if `B` depends on `A`, then `A.o` comes before `B.o` on the linker’s command line. Other tools might have the opposite requirement. Three traversal orders are supported: `postorder`, `preorder`, and -`topological`. The first two work exactly like [tree -traversals](https://en.wikipedia.org/wiki/Tree_traversal#Depth-first_search) +`topological`. The first two work exactly like [tree traversals](https://en.wikipedia.org/wiki/Tree_traversal#Depth-first_search) except that they operate on DAGs and skip already visited nodes. The third order works as a topological sort from root to leaves, essentially the same as preorder except that shared children are listed only after all of their parents. diff --git a/extending/exec-groups.mdx b/extending/exec-groups.mdx index bd2e6db1..68003af0 100644 --- a/extending/exec-groups.mdx +++ b/extending/exec-groups.mdx @@ -72,8 +72,7 @@ test rules. In the rule implementation, you can declare that actions should be run on the execution platform of an execution group. You can do this by using the `exec_group` -param of action generating methods, specifically [`ctx.actions.run`] -(/rules/lib/builtins/actions#run) and +param of action generating methods, specifically [`ctx.actions.run`](/rules/lib/builtins/actions#run) and [`ctx.actions.run_shell`](/rules/lib/builtins/actions#run_shell). ```python diff --git a/extending/legacy-macros.mdx b/extending/legacy-macros.mdx index 6827a07c..564f1211 100644 --- a/extending/legacy-macros.mdx +++ b/extending/legacy-macros.mdx @@ -11,7 +11,7 @@ anymore, and Bazel sees only the concrete set of instantiated rules. ## Why you shouldn't use legacy macros (and should use Symbolic macros instead) {#no-legacy-macros} -Where possible you should use [symbolic macros](macros.md#macros). +Where possible you should use [symbolic macros](/extending/macros#macros). Symbolic macros @@ -20,7 +20,7 @@ Symbolic macros * Take typed attributes, which in turn means automatic label and select conversion. * Are more readable -* Will soon have [lazy evaluation](macros.md#laziness) +* Will soon have [lazy evaluation](/extending/macros#laziness) ## Usage {#usage} @@ -154,7 +154,7 @@ the macro), use the function ## Label resolution in macros {#label-resolution} Since legacy macros are evaluated in the -[loading phase](concepts.md#evaluation-model), label strings such as +[loading phase](/extending/concepts#evaluation-model), label strings such as `"//foo:bar"` that occur in a legacy macro are interpreted relative to the `BUILD` file in which the macro is used rather than relative to the `.bzl` file in which it is defined. This behavior is generally undesirable for macros that diff --git a/extending/macros.mdx b/extending/macros.mdx index 7920d7c6..44b7faae 100644 --- a/extending/macros.mdx +++ b/extending/macros.mdx @@ -12,7 +12,7 @@ Macros are mainly used for encapsulation and code reuse of existing rules and other macros. Macros come in two flavors: symbolic macros, which are described on this page, -and [legacy macros](legacy-macros.md). Where possible, we recommend using +and [legacy macros](/extending/legacy-macros). Where possible, we recommend using symbolic macros for code clarity. Symbolic macros offer typed arguments (string to label conversion, relative to @@ -33,8 +33,7 @@ two required parameters: `attrs` and `implementation`. ### Attributes {#attributes} -`attrs` accepts a dictionary of attribute name to [attribute -types](https://bazel.build/rules/lib/toplevel/attr#members), which represents +`attrs` accepts a dictionary of attribute name to [attribute types](https://bazel.build/rules/lib/toplevel/attr#members), which represents the arguments to the macro. Two common attributes – `name` and `visibility` – are implicitly added to all macros and are not included in the dictionary passed to `attrs`. @@ -68,9 +67,7 @@ To support this pattern, a macro can *inherit attributes* from a rule or another macro by passing the [rule](https://bazel.build/rules/lib/builtins/rule) or [macro symbol](https://bazel.build/rules/lib/builtins/macro) to `macro()`'s `inherit_attrs` argument. (You can also use the special string `"common"` -instead of a rule or macro symbol to inherit the [common attributes defined for -all Starlark build -rules](https://bazel.build/reference/be/common-definitions#common-attributes).) +instead of a rule or macro symbol to inherit the [common attributes defined for all Starlark build rules](https://bazel.build/reference/be/common-definitions#common-attributes).) Only public attributes get inherited, and the attributes in the macro's own `attrs` dictionary override inherited attributes with the same name. You can also *remove* inherited attributes by using `None` as a value in the `attrs` diff --git a/extending/platforms.mdx b/extending/platforms.mdx index 7009de11..f95f5e6a 100644 --- a/extending/platforms.mdx +++ b/extending/platforms.mdx @@ -256,8 +256,7 @@ cc_library( You can use the [`IncompatiblePlatformProvider`](/rules/lib/providers/IncompatiblePlatformProvider) -in `bazel cquery`'s [Starlark output -format](/query/cquery#output-format-definition) to distinguish +in `bazel cquery`'s [Starlark output format](/query/cquery#output-format-definition) to distinguish incompatible targets from compatible ones. This can be used to filter out incompatible targets. The example below will @@ -278,5 +277,4 @@ $ bazel cquery //... --output=starlark --starlark:file=example.cquery ### Known Issues -Incompatible targets [ignore visibility -restrictions](https://github.com/bazelbuild/bazel/issues/16044). +Incompatible targets [ignore visibility restrictions](https://github.com/bazelbuild/bazel/issues/16044). diff --git a/extending/rules.mdx b/extending/rules.mdx index 07515c96..8a4efe20 100644 --- a/extending/rules.mdx +++ b/extending/rules.mdx @@ -451,8 +451,7 @@ def _example_library_impl(ctx): If `DefaultInfo` is not returned by a rule implementation or the `files` parameter is not specified, `DefaultInfo.files` defaults to all -*predeclared outputs* (generally, those created by [output -attributes](#output_attributes)). +*predeclared outputs* (generally, those created by [output attributes](#output_attributes)). Rules that perform actions should provide default outputs, even if those outputs are not expected to be directly used. Actions that are not in the graph of the @@ -543,7 +542,7 @@ provider instances satisfy certain invariants, or to give users a cleaner API fo obtaining an instance. This is done by passing an `init` callback to the -[`provider`](/rules/lib/globals/bzl.html#provider) function. If this callback is given, the +[`provider`](/rules/lib/globals/bzl#provider) function. If this callback is given, the return type of `provider()` changes to be a tuple of two values: the provider symbol that is the ordinary return value when `init` is not used, and a "raw constructor". @@ -995,8 +994,7 @@ By using `configuration_field`, the dependency on the Java LCOV merger tool can be avoided as long as coverage is not requested. When the test is run, it should emit coverage information in the form of one or -more [LCOV files] -(https://manpages.debian.org/unstable/lcov/geninfo.1.en.html#TRACEFILE_FORMAT) +more [LCOV files](https://manpages.debian.org/unstable/lcov/geninfo.1.en.html#TRACEFILE_FORMAT) with unique names into the directory specified by the `COVERAGE_DIR` environment variable. Bazel will then merge these files into a single LCOV file using the `_lcov_merger` tool. If present, it will also collect C/C++ coverage using the diff --git a/extending/toolchains.mdx b/extending/toolchains.mdx index 9534774d..33f8bac9 100644 --- a/extending/toolchains.mdx +++ b/extending/toolchains.mdx @@ -583,8 +583,7 @@ The set of available toolchains, in priority order, is created from 4. Toolchains registered in the "WORKSPACE suffix"; this is only used by certain native rules bundled with the Bazel installation. -**NOTE:** [Pseudo-targets like `:all`, `:*`, and -`/...`](/run/build#specifying-build-targets) are ordered by Bazel's package +**NOTE:** [Pseudo-targets like `:all`, `:*`, and `/...`](/run/build#specifying-build-targets) are ordered by Bazel's package loading mechanism, which uses a lexicographic ordering. The resolution steps are as follows. diff --git a/external/extension.mdx b/external/extension.mdx index 15a1961d..9a8dae94 100644 --- a/external/extension.mdx +++ b/external/extension.mdx @@ -6,8 +6,7 @@ title: 'Module extensions' Module extensions allow users to extend the module system by reading input data from modules across the dependency graph, performing necessary logic to resolve -dependencies, and finally creating repos by calling [repo -rules](/external/repo). These extensions have capabilities similar to repo +dependencies, and finally creating repos by calling [repo rules](/external/repo). These extensions have capabilities similar to repo rules, which enables them to perform file I/O, send network requests, and so on. Among other things, they allow Bazel to interact with other package management systems while also respecting the dependency graph built out of Bazel modules. diff --git a/external/faq.mdx b/external/faq.mdx index 817040a4..7b1a31e8 100644 --- a/external/faq.mdx +++ b/external/faq.mdx @@ -76,7 +76,7 @@ failures provide clear error messages and actionable migration paths. **Legacy documentation:** -The [`compatibility_level`](module.md#compatibility_level) of a Bazel module +The [`compatibility_level`](/external/module#compatibility_level) of a Bazel module should be incremented _in the same commit_ that introduces a backwards incompatible ("breaking") change. @@ -114,7 +114,7 @@ generally interested in, and they can be solved without `load`s: `load`s in MODULE.bazel files, `include` cannot be used in non-root modules. * Users of the old WORKSPACE system might remember declaring a repo, and then immediately `load`ing from that repo to perform complex logic. This - capability has been replaced by [module extensions](extension). + capability has been replaced by [module extensions](/external/extension). ### Can I specify a SemVer range for a `bazel_dep`? {#can-i-specify-a-semver-range-for-a-bazel-dep} @@ -123,20 +123,18 @@ support version ranges (implicitly or explicitly), and this often requires a constraint solver (making the output harder to predict for users) and makes version resolution nonreproducible without a lockfile. -Bazel instead uses [Minimal Version Selection](module#version-selection) like +Bazel instead uses [Minimal Version Selection](/external/module#version-selection) like Go, which in contrast makes the output easy to predict and guarantees reproducibility. This is a tradeoff that matches Bazel's design goals. -Furthermore, Bazel module versions are [a superset of -SemVer](module#version-format), so what makes sense in a strict SemVer +Furthermore, Bazel module versions are [a superset of SemVer](/external/module#version-format), so what makes sense in a strict SemVer environment doesn't always carry over to Bazel module versions. ### Can I automatically get the latest version for a `bazel_dep`? {#can-i-automatically-get-the-latest-version-for-a-bazel-dep} Some users occasionally ask for the ability to specify `bazel_dep(name = "foo", version = "latest")` to automatically get the latest version of a dep. This is -similar to [the question about SemVer -ranges](#can-i-specify-a-semver-range-for-a-bazel-dep), and the answer is also +similar to [the question about SemVer ranges](#can-i-specify-a-semver-range-for-a-bazel-dep), and the answer is also no. The recommended solution here is to have automation take care of this. For @@ -194,8 +192,7 @@ wonder which system is consulted first. The short answer is that MODULE.bazel The long answer is that "which evaluates first" is not the right question to ask; rather, the right question to ask is: in the context of the repo with -[canonical name](overview#canonical-repo-name) `@@foo`, what does the [apparent -repo name](overview#apparent-repo-name) `@bar` resolve to? Alternatively, what +[canonical name](/external/overview#canonical-repo-name) `@@foo`, what does the [apparent repo name](/external/overview#apparent-repo-name) `@bar` resolve to? Alternatively, what is the repo mapping of `@@base`? Labels with apparent repo names (a single leading `@`) can refer to different @@ -204,8 +201,7 @@ things based on the context they're resolved from. When you see a label what the context repo is: for example, if the label is in a BUILD file located in the repo `@@foo`, then the context repo is `@@foo`. -Then, depending on what the context repo is, the ["repository -visibility" table](migration#repository-visibility) in the migration guide can +Then, depending on what the context repo is, the ["repository visibility" table](/external/migration#repository-visibility) in the migration guide can be used to find out which repo an apparent name actually resolves to. * If the context repo is the main repo (`@@`): @@ -257,8 +253,7 @@ as the context repo. Use the `bazel fetch` command to prefetch repos. You can use the `--repo` flag (like `bazel fetch --repo @foo`) to fetch only the repo `@foo` (resolved in the -context of the main repo, see [question -above](#which-is-evaluated-first-module-bazel-or-workspace)), or use a target +context of the main repo, see [question above](#which-is-evaluated-first-module-bazel-or-workspace)), or use a target pattern (like `bazel fetch @foo//:bar`) to fetch all transitive dependencies of `@foo//:bar` (this is equivalent to `bazel build --nobuild @foo//:bar`). @@ -266,7 +261,7 @@ To make sure no fetches happen during a build, use `--nofetch`. More precisely, this makes any attempt to run a non-local repository rule fail. If you want to fetch repos _and_ modify them to test locally, consider using -the [`bazel vendor`](vendor) command. +the [`bazel vendor`](/external/vendor) command. ### How do I insulate my builds from the Internet? {#how-do-i-insulate-my-builds-from-the-internet} @@ -308,21 +303,17 @@ preferring IPv4 if enabled. In some situations, for example when the IPv4 network cannot resolve/reach external addresses, this can cause `Network unreachable` exceptions and build failures. In these cases, you can override Bazel's behavior to prefer IPv6 by using the -[`java.net.preferIPv6Addresses=true` system -property](https://docs.oracle.com/javase/8/docs/api/java/net/doc-files/net-properties.html). +[`java.net.preferIPv6Addresses=true` system property](https://docs.oracle.com/javase/8/docs/api/java/net/doc-files/net-properties.html). Specifically: -* Use `--host_jvm_args=-Djava.net.preferIPv6Addresses=true` [startup - option](/docs/user-manual#startup-options), for example by adding the +* Use `--host_jvm_args=-Djava.net.preferIPv6Addresses=true` [startup option](/docs/user-manual#startup-options), for example by adding the following line in your [`.bazelrc` file](/run/bazelrc): `startup --host_jvm_args=-Djava.net.preferIPv6Addresses=true` * When running Java build targets that need to connect to the internet (such as for integration tests), use the - `--jvmopt=-Djava.net.preferIPv6Addresses=true` [tool - flag](/docs/user-manual#jvmopt). For example, include in your [`.bazelrc` - file](/run/bazelrc): + `--jvmopt=-Djava.net.preferIPv6Addresses=true` [tool flag](/docs/user-manual#jvmopt). For example, include in your [`.bazelrc` file](/run/bazelrc): `build --jvmopt=-Djava.net.preferIPv6Addresses` @@ -330,8 +321,7 @@ Specifically: [`rules_jvm_external`](https://github.com/bazelbuild/rules_jvm_external) for dependency version resolution, also add `-Djava.net.preferIPv6Addresses=true` to the `COURSIER_OPTS` environment - variable to [provide JVM options for - Coursier](https://github.com/bazelbuild/rules_jvm_external#provide-jvm-options-for-coursier-with-coursier_opts). + variable to [provide JVM options for Coursier](https://github.com/bazelbuild/rules_jvm_external#provide-jvm-options-for-coursier-with-coursier_opts). ### Can repo rules be run remotely with remote execution? {#can-repo-rules-be-run-remotely-with-remote-execution} @@ -356,9 +346,7 @@ build rules, which would naturally allow them to be run remotely, but conversely raise new architectural concerns (for example, the `query` commands would potentially need to run actions, complicating their design). -For more previous discussion on this topic, see [A way to support repositories -that need Bazel for being -fetched](https://github.com/bazelbuild/bazel/discussions/20464). +For more previous discussion on this topic, see [A way to support repositories that need Bazel for being fetched](https://github.com/bazelbuild/bazel/discussions/20464). [npm-semver]: https://docs.npmjs.com/about-semantic-versioning [cargo-semver]: https://doc.rust-lang.org/cargo/reference/specifying-dependencies.html#version-requirement-syntax diff --git a/external/images/mod_exampleBefore.svg b/external/images/mod_exampleBefore.svg new file mode 100644 index 00000000..66f01303 --- /dev/null +++ b/external/images/mod_exampleBefore.svg @@ -0,0 +1,175 @@ + + + + + + +mygraph + + + +<root> + +<root> (my_project@1.0) + + + +bazel_skylib@1.1.1 + +bazel_skylib@1.1.1 + + + +<root>->bazel_skylib@1.1.1 + + + + + +bazel_skylib@1.2.0 + +bazel_skylib@1.2.0 + + + +<root>->bazel_skylib@1.2.0 + + + + + +rules_java@5.0.0 + +rules_java@5.0.0 + + + +<root>->rules_java@5.0.0 + + + + + +stardoc@0.5.0 + +stardoc@0.5.0 + + + +<root>->stardoc@0.5.0 + + + + + +platforms@0.0.4 + +platforms@0.0.4 + + + +bazel_skylib@1.1.1->platforms@0.0.4 + + + + + +bazel_skylib@1.2.0->platforms@0.0.4 + + + + + +rules_java@5.0.0->platforms@0.0.4 + + + + + +rules_cc@0.0.1 + +rules_cc@0.0.1 + + + +rules_java@5.0.0->rules_cc@0.0.1 + + + + + +rules_proto@4.0.0 + +rules_proto@4.0.0 + + + +rules_java@5.0.0->rules_proto@4.0.0 + + + + + +bazel_skylib@1.0.3 + +bazel_skylib@1.0.3 + + + +stardoc@0.5.0->bazel_skylib@1.0.3 + + + + + +rules_java@4.0.0 + +rules_java@4.0.0 + + + +stardoc@0.5.0->rules_java@4.0.0 + + + + + +rules_cc@0.0.1->platforms@0.0.4 + + + + + +rules_cc@0.0.1->bazel_skylib@1.0.3 + + + + + +rules_proto@4.0.0->rules_cc@0.0.1 + + + + + +rules_proto@4.0.0->bazel_skylib@1.0.3 + + + + + +bazel_skylib@1.0.3->platforms@0.0.4 + + + + + +rules_java@4.0.0->bazel_skylib@1.0.3 + + + + + \ No newline at end of file diff --git a/external/images/mod_exampleResolved.svg b/external/images/mod_exampleResolved.svg new file mode 100644 index 00000000..224b694c --- /dev/null +++ b/external/images/mod_exampleResolved.svg @@ -0,0 +1,151 @@ + + + + + + +mygraph + + + +<root> + +<root> (my_project@1.0) + + + +bazel_skylib@1.1.1 + +bazel_skylib@1.1.1 + + + +<root>->bazel_skylib@1.1.1 + + + + + +bazel_skylib@1.2.0 + +bazel_skylib@1.2.0 + + + +<root>->bazel_skylib@1.2.0 + + + + + +rules_java@5.0.0 + +rules_java@5.0.0 + + + +<root>->rules_java@5.0.0 + + + + + +stardoc@0.5.0 + +stardoc@0.5.0 + + + +<root>->stardoc@0.5.0 + + + + + +platforms@0.0.4 + +platforms@0.0.4 + + + +bazel_skylib@1.1.1->platforms@0.0.4 + + + + + +bazel_skylib@1.2.0->platforms@0.0.4 + + + + + +rules_java@5.0.0->platforms@0.0.4 + + + + + +rules_cc@0.0.1 + +rules_cc@0.0.1 + + + +rules_java@5.0.0->rules_cc@0.0.1 + + + + + +rules_proto@4.0.0 + +rules_proto@4.0.0 + + + +rules_java@5.0.0->rules_proto@4.0.0 + + + + + +stardoc@0.5.0->bazel_skylib@1.1.1 + + + + + +stardoc@0.5.0->rules_java@5.0.0 + + + + + +rules_cc@0.0.1->bazel_skylib@1.1.1 + + + + + +rules_cc@0.0.1->platforms@0.0.4 + + + + + +rules_proto@4.0.0->bazel_skylib@1.1.1 + + + + + +rules_proto@4.0.0->rules_cc@0.0.1 + + + + + \ No newline at end of file diff --git a/external/migration.mdx b/external/migration.mdx index 38e049fd..c3030533 100644 --- a/external/migration.mdx +++ b/external/migration.mdx @@ -4,15 +4,14 @@ title: 'Bzlmod Migration Guide' -Due to the [shortcomings of -WORKSPACE](/external/overview#workspace-shortcomings), Bzlmod is replacing the +Due to the [shortcomings of WORKSPACE](/external/overview#workspace-shortcomings), Bzlmod is replacing the legacy WORKSPACE system. The WORKSPACE file is already disabled in Bazel 8 (late 2024) and will be removed in Bazel 9 (late 2025). This guide helps you migrate your project to Bzlmod and drop WORKSPACE for managing external dependencies. ## Why migrate to Bzlmod? {#why-migrate-to-bzlmod} -* There are many [advantages](overview#benefits) compared to the legacy +* There are many [advantages](/external/overview#benefits) compared to the legacy WORKSPACE system, which helps to ensure a healthy growth of the Bazel ecosystem. @@ -31,8 +30,7 @@ Recommended migration process: streamline the migration process as much as possible. 2. If there are errors left after using the migration tool, resolve them manually. For understanding the main differences between concepts inside - `WORKSPACE` and `MODULE.bazel` files, check [WORKSPACE versus - Bzlmod](#workspace-vs-bzlmod) section. + `WORKSPACE` and `MODULE.bazel` files, check [WORKSPACE versus Bzlmod](#workspace-vs-bzlmod) section. ## WORKSPACE vs Bzlmod {#workspace-vs-bzlmod} @@ -142,9 +140,7 @@ Bazel module when it also adopts Bzlmod. * **Bzlmod** - With Bzlmod, as long as your dependency is available in [Bazel Central - Registry](https://registry.bazel.build) or your custom [Bazel - registry](/external/registry), you can simply depend on it with a + With Bzlmod, as long as your dependency is available in [Bazel Central Registry](https://registry.bazel.build) or your custom [Bazel registry](/external/registry), you can simply depend on it with a [`bazel_dep`](/rules/lib/globals/module#bazel_dep) directive. ```python @@ -175,8 +171,7 @@ repository. If your dependency is not a Bazel project or not yet available in any Bazel registry, you can introduce it using -[`use_repo_rule`](/external/module#use_repo_rule) or [module -extensions](/external/extension). +[`use_repo_rule`](/external/module#use_repo_rule) or [module extensions](/external/extension). * **WORKSPACE** @@ -617,8 +612,7 @@ flag after fetching all repos needed for a build. ## Manual migration {#manual-migration} This section provides useful information and guidance for your **manual** Bzlmod -migration process. For more automatized migration process, check [recommended -migration process](#how-migrate-to-bzlmod) section. +migration process. For more automatized migration process, check [recommended migration process](#how-migrate-to-bzlmod) section. ### Know your dependencies in WORKSPACE {#know-deps-in-workspace} @@ -632,8 +626,7 @@ macros. Fortunately, the flag [`--experimental_repository_resolved_file`][resolved_file_flag] can help. This flag essentially generates a "lock file" of all fetched external -dependencies in your last Bazel command. You can find more details in this [blog -post](https://blog.bazel.build/2018/07/09/bazel-sync-and-resolved-file.html). +dependencies in your last Bazel command. You can find more details in this [blog post](https://blog.bazel.build/2018/07/09/bazel-sync-and-resolved-file.html). [resolved_file_flag]: /reference/command-line-reference#flag--experimental_repository_resolved_file @@ -674,11 +667,9 @@ You may also know `bazel query` can be used for inspecting repository rules with bazel query --output=build //external: ``` -While it is more convenient and much faster, [bazel query can lie about -external dependency version](https://github.com/bazelbuild/bazel/issues/12947), +While it is more convenient and much faster, [bazel query can lie about external dependency version](https://github.com/bazelbuild/bazel/issues/12947), so be careful using it! Querying and inspecting external -dependencies with Bzlmod is going to achieved by a [new -subcommand](https://github.com/bazelbuild/bazel/issues/15365). +dependencies with Bzlmod is going to achieved by a [new subcommand](https://github.com/bazelbuild/bazel/issues/15365). #### Built-in default dependencies {#builtin-default-deps} @@ -725,8 +716,7 @@ Using the WORKSPACE.bzlmod file can make the migration easier because: #### Repository visibility {#repository-visibility} Bzlmod is able to control which other repositories are visible from a given -repository, check [repository names and strict -deps](/external/module#repository_names_and_strict_deps) for more details. +repository, check [repository names and strict deps](/external/module#repository_names_and_strict_deps) for more details. Here is a summary of repository visibilities from different types of repositories when also taking WORKSPACE into consideration. @@ -739,8 +729,7 @@ repositories when also taking WORKSPACE into consideration. | WORKSPACE Repos | All visible | Not visible | Not visible | All visible | Note: For the root module, if a repository `@foo` is defined in WORKSPACE and -`@foo` is also used as an [apparent repository -name](/external/overview#apparent-repo-name) in MODULE.bazel, then `@foo` +`@foo` is also used as an [apparent repository name](/external/overview#apparent-repo-name) in MODULE.bazel, then `@foo` refers to the one introduced in MODULE.bazel. Note: For a module extension generated repository `@bar`, if `@foo` is used as @@ -785,9 +774,7 @@ the project. Take note of a few things when creating the source archive: GitHub isn't going to guarantee the checksum of source archives generated on demand. In short, URLs in the form of `https://github.com///releases/download/...` is considered stable - while `https://github.com///archive/...` is not. Check [GitHub - Archive Checksum - Outage](https://blog.bazel.build/2023/02/15/github-archive-checksum.html) + while `https://github.com///archive/...` is not. Check [GitHub Archive Checksum Outage](https://blog.bazel.build/2023/02/15/github-archive-checksum.html) for more context. * **Make sure the source tree follows the layout of the original repository.** @@ -816,8 +803,7 @@ Pull Request. [bcr_contrib_guide]: https://github.com/bazelbuild/bazel-central-registry/tree/main/docs#contribute-a-bazel-module -It is **highly recommended** to set up the [Publish to -BCR](https://github.com/bazel-contrib/publish-to-bcr) GitHub App for your +It is **highly recommended** to set up the [Publish to BCR](https://github.com/bazel-contrib/publish-to-bcr) GitHub App for your repository to automate the process of submitting your module to the BCR. ## Best practices {#best-practices} diff --git a/external/migration_tool.mdx b/external/migration_tool.mdx index e9435ced..cf59c153 100644 --- a/external/migration_tool.mdx +++ b/external/migration_tool.mdx @@ -102,8 +102,7 @@ migrate2bzlmod -t <targets> script. * `extension_for_XXX` - A file containing a module extension definition. The migration tool generates these files for dependencies that - are not standard Bazel modules but can be managed using Bzlmod's [module - extensions](/external/extension). + are not standard Bazel modules but can be managed using Bzlmod's [module extensions](/external/extension). ### Flags {#migration-script-flags} @@ -300,8 +299,7 @@ def my_custom_macro(name): The end goal is to have `MODULE.bazel` file and delete the `WORKSPACE` file, without impacting the user experience. -The first step is to follow [How to Use the Migration -Tool](#migration-tool-how-to-use), which mostly is checking the bazel version +The first step is to follow [How to Use the Migration Tool](#migration-tool-how-to-use), which mostly is checking the bazel version (it must be Bazel 7) and adding an alias to the migration script. Then, running `migrate2bzlmod -t=//...` outputs: @@ -634,8 +632,7 @@ may arise during the Bzlmod migration. ### Migration Report Generation {#migration-tool-report-generation} This file is updated with each run of the migration script or it's generated -from scratch if it's the first run or if the [`--i` -flag](#migration-script-flags) is used. The report contains: +from scratch if it's the first run or if the [`--i` flag](#migration-script-flags) is used. The report contains: * Command for local testing. * List of direct dependencies (at least the ones which are directly used in diff --git a/external/mod-command.mdx b/external/mod-command.mdx index 69a3cd8c..9eea1572 100644 --- a/external/mod-command.mdx +++ b/external/mod-command.mdx @@ -64,11 +64,9 @@ The available subcommands and their respective required arguments are: * ``: All present versions of the module ``. -* `@`: The repo with the given [apparent - name](overview#apparent-repo-name) in the context of the `--base_module`. +* `@`: The repo with the given [apparent name](/external/overview#apparent-repo-name) in the context of the `--base_module`. -* `@@`: The repo with the given [canonical - name](overview#canonical-repo-name). +* `@@`: The repo with the given [canonical name](/external/overview#canonical-repo-name). In a context requiring specifying modules, ``s referring to repos that correspond to modules (as opposed to extension-generated repos) can also be @@ -92,8 +90,7 @@ The following options only affect the subcommands that print graphs (`graph`, information about the version resolution of each module. If the module version changed during resolution, show either which version replaced it or what was the original version, the reason it was replaced, and which modules - requested the new version if the reason was [Minimal Version - Selection](module#version-selection). + requested the new version if the reason was [Minimal Version Selection](/external/module#version-selection). * `--include_unused` *default: "false"*: Include in the output graph the modules which were originally present in the dependency graph, but became @@ -213,7 +210,7 @@ use_repo(toolchains, my_jdk="remotejdk17_linux")
- Graph Before Resolution + Graph Before Resolution
Graph Before Resolution
{/* digraph mygraph { @@ -243,7 +240,7 @@ use_repo(toolchains, my_jdk="remotejdk17_linux")
- Graph After Resolution + Graph After Resolution
Graph After Resolution
{/* digraph mygraph { diff --git a/external/module.mdx b/external/module.mdx index e3fe9137..f4fe31a4 100644 --- a/external/module.mdx +++ b/external/module.mdx @@ -56,8 +56,7 @@ Any valid SemVer version is a valid Bazel module version. Additionally, two SemVer versions `a` and `b` compare `a < b` if and only if the same holds when they're compared as Bazel module versions. -Finally, to learn more about module versioning, [see the `MODULE.bazel` -FAQ](faq#module-versioning-best-practices). +Finally, to learn more about module versioning, [see the `MODULE.bazel` FAQ](/external/faq#module-versioning-best-practices). ## Version selection {#version-selection} @@ -111,8 +110,7 @@ serves multiple purposes: version, regardless of which versions of the dependency are requested in the dependency graph. * With the `registry` attribute, you can force this dependency to come from a - specific registry, instead of following the normal [registry - selection](/external/registry#selecting_registries) process. + specific registry, instead of following the normal [registry selection](/external/registry#selecting_registries) process. * With the `patch*` attributes, you can specify a set of patches to apply to the downloaded module. @@ -153,8 +151,7 @@ Bazel supports the following non-registry overrides: Note that setting a version value in the source archive `MODULE.bazel` can have downsides when the module is being overridden with a non-registry override. To -learn more about this [see the `MODULE.bazel` -FAQ](faq#module-versioning-best-practices). +learn more about this [see the `MODULE.bazel` FAQ](/external/faq#module-versioning-best-practices). ## Define repos that don't represent Bazel modules {#use_repo_rule} @@ -162,13 +159,11 @@ With `bazel_dep`, you can define repos that represent other Bazel modules. Sometimes there is a need to define a repo that does _not_ represent a Bazel module; for example, one that contains a plain JSON file to be read as data. -In this case, you could use the [`use_repo_rule` -directive](/rules/lib/globals/module#use_repo_rule) to directly define a repo +In this case, you could use the [`use_repo_rule` directive](/rules/lib/globals/module#use_repo_rule) to directly define a repo by invoking a repo rule. This repo will only be visible to the module it's defined in. -Under the hood, this is implemented using the same mechanism as [module -extensions](/external/extension), which lets you define repos with more +Under the hood, this is implemented using the same mechanism as [module extensions](/external/extension), which lets you define repos with more flexibility. ## Repository names and strict deps diff --git a/external/overview.mdx b/external/overview.mdx index c6a24ec4..ed819f7e 100644 --- a/external/overview.mdx +++ b/external/overview.mdx @@ -15,8 +15,7 @@ concepts in more detail. ## Overview of the system {#overview} -Bazel's external dependency system works on the basis of [*Bazel -modules*](#module), each of which is a versioned Bazel project, and +Bazel's external dependency system works on the basis of [*Bazel modules*](#module), each of which is a versioned Bazel project, and [*repositories*](#repository) (or repos), which are directory trees containing source files. @@ -33,8 +32,7 @@ bazel_dep(name = "platforms", version = "0.0.11") ``` From there, Bazel looks up all transitive dependency modules in a -[*Bazel registry*](registry) — by default, the [Bazel Central -Registry](https://bcr.bazel.build/). The registry provides the +[*Bazel registry*](/external/registry) — by default, the [Bazel Central Registry](https://bcr.bazel.build/). The registry provides the dependencies' `MODULE.bazel` files, which allows Bazel to discover the entire transitive dependency graph before performing version resolution. @@ -44,7 +42,7 @@ Bazel consults the registry again to learn how to define a repo for each module of the time, these are just archives downloaded from the internet and extracted. Modules can also specify customized pieces of data called *tags*, which are -consumed by [*module extensions*](extension) after module resolution +consumed by [*module extensions*](/external/extension) after module resolution to define additional repos. These extensions can perform actions like file I/O and sending network requests. Among other things, they allow Bazel to interact with other package management systems while also respecting the dependency graph @@ -63,12 +61,12 @@ Bazel's external dependency system offers a wide range of benefits. ### Automatic Dependency Resolution {#automatic-dependency-resolution} - **Deterministic Version Resolution**: Bazel adopts the deterministic - [MVS](module#version-selection) version resolution algorithm, + [MVS](/external/module#version-selection) version resolution algorithm, minimizing conflicts and addressing diamond dependency issues. - **Simplified Dependency Management**: `MODULE.bazel` declares only direct dependencies, while transitive dependencies are automatically resolved, providing a clearer overview of the project's dependencies. -- **[Strict Dependency visibility](module#repository_names_and_strict_deps)**: +- **[Strict Dependency visibility](/external/module#repository_names_and_strict_deps)**: Only direct dependencies are visible, ensuring correctness and predictability. @@ -95,19 +93,18 @@ Bazel's external dependency system offers a wide range of benefits. ### Advanced Features {#advanced-features} -- **[Module Extensions](extension)**: The +- **[Module Extensions](/external/extension)**: The [`use_repo_rule`](/rules/lib/globals/module#use_repo_rule) and module extension features allow flexible use of custom repository rules and resolution logic to introduce any non-Bazel dependencies. -- **[`bazel mod` Command](mod-command)**: The sub-command offers +- **[`bazel mod` Command](/external/mod-command)**: The sub-command offers powerful ways to inspect external dependencies. You know exactly how an external dependency is defined and where it comes from. -- **[Vendor Mode](vendor)**: Pre-fetch the exact external dependencies you +- **[Vendor Mode](/external/vendor)**: Pre-fetch the exact external dependencies you need to facilitate offline builds. -- **[Lockfile](lockfile)**: The lockfile improves build reproducibility and +- **[Lockfile](/external/lockfile)**: The lockfile improves build reproducibility and accelerates dependency resolution. -- **(Upcoming) [BCR Provenance - Attestations](https://github.com/bazelbuild/bazel-central-registry/discussions/2721)**: +- **(Upcoming) [BCR Provenance Attestations](https://github.com/bazelbuild/bazel-central-registry/discussions/2721)**: Strengthen supply chain security by ensuring verified provenance of dependencies. @@ -122,7 +119,7 @@ dependencies on other modules. In a local Bazel workspace, a module is represented by a repository. -For more details, see [Bazel modules](module). +For more details, see [Bazel modules](/external/module). ### Repository {#repository} @@ -180,7 +177,7 @@ and extract it", or "fetch a certain Maven artifact and make it available as a `java_import` target", or simply "symlink a local directory". Every repo is **defined** by calling a repo rule with an appropriate number of arguments. -See [Repository rules](repo) for more information about how to write +See [Repository rules](/external/repo) for more information about how to write your own repository rules. The most common repo rules by far are @@ -231,8 +228,7 @@ contain anything to serve as a repo boundary file; however, it can also be used to specify some common attributes for all build targets inside the repo. The syntax of a `REPO.bazel` file is similar to `BUILD` files, except that no -`load` statements are supported. The `repo()` function takes the same arguments as the [`package()` -function](/reference/be/functions#package) in `BUILD` files; whereas `package()` +`load` statements are supported. The `repo()` function takes the same arguments as the [`package()` function](/reference/be/functions#package) in `BUILD` files; whereas `package()` specifies common attributes for all build targets inside the package, `repo()` analogously does so for all build targets inside the repo. @@ -293,7 +289,7 @@ pain points, including: Due to the shortcomings of WORKSPACE, the new module-based system (codenamed "Bzlmod") gradually replaced the legacy WORKSPACE system between Bazel 6 and 9. -Read the [Bzlmod migration guide](migration) on how to migrate +Read the [Bzlmod migration guide](/external/migration) on how to migrate to Bzlmod. ### External links on Bzlmod {#external-links} diff --git a/external/registry.mdx b/external/registry.mdx index 1d441581..2bd0c114 100644 --- a/external/registry.mdx +++ b/external/registry.mdx @@ -21,17 +21,15 @@ An index registry must have the following format: * `/modules`: A directory containing a subdirectory for each module in this registry * `/modules/$MODULE`: A directory containing a subdirectory for each version - of the module named `$MODULE`, as well as the [`metadata.json` - file](#metadata-json) containing metadata for this module. + of the module named `$MODULE`, as well as the [`metadata.json` file](#metadata-json) containing metadata for this module. * `/modules/$MODULE/$VERSION`: A directory containing the following files: * `MODULE.bazel`: The `MODULE.bazel` file of this module version. Note that this is the `MODULE.bazel` file read during Bazel's external dependency resolution, _not_ the one from the source archive (unless - there's a [non-registry - override](/external/module#non-registry_overrides)). Also note that it's + there's a [non-registry override](/external/module#non-registry_overrides)). Also note that it's best to use this file to set the version of a release and avoid doing so in the source archive `MODULE.bazel` file. To learn more about module - versioning, [see the FAQ](faq.md#module-versioning-best-practices). + versioning, [see the FAQ](/external/faq#module-versioning-best-practices). * [`source.json`](#source-json): A JSON file containing information on how to fetch the source of this module version * `patches/`: An optional directory containing patch files, only used when @@ -65,8 +63,7 @@ module, with the following fields: * `versions`: An array of strings, each denoting a version of the module available in this registry. This array should match the children of the module directory. -* `yanked_versions`: A JSON object specifying the [*yanked* - versions](/external/module#yanked_versions) of this module. The keys +* `yanked_versions`: A JSON object specifying the [*yanked* versions](/external/module#yanked_versions) of this module. The keys should be versions to yank, and the values should be descriptions of why the version is yanked, ideally containing a link to more information. diff --git a/external/repo.mdx b/external/repo.mdx index b878f030..958d403e 100644 --- a/external/repo.mdx +++ b/external/repo.mdx @@ -76,8 +76,7 @@ specified. The input parameter `repository_ctx` can be used to access attribute values, and non-hermetic functions (finding a binary, executing a binary, creating a file in -the repository or downloading a file from the Internet). See [the API -docs](/rules/lib/builtins/repository_ctx) for more context. Example: +the repository or downloading a file from the Internet). See [the API docs](/rules/lib/builtins/repository_ctx) for more context. Example: ```python def _impl(repository_ctx): @@ -146,8 +145,7 @@ definition has the `configure` attribute set, use `bazel fetch --force ## Examples -- [C++ auto-configured - toolchain](https://cs.opensource.google/bazel/bazel/+/master:tools/cpp/cc_configure.bzl;drc=644b7d41748e09eff9e47cbab2be2263bb71f29a;l=176): +- [C++ auto-configured toolchain](https://cs.opensource.google/bazel/bazel/+/master:tools/cpp/cc_configure.bzl;drc=644b7d41748e09eff9e47cbab2be2263bb71f29a;l=176): it uses a repo rule to automatically create the C++ configuration files for Bazel by looking for the local C++ compiler, the environment and the flags the C++ compiler supports. diff --git a/external/vendor.mdx b/external/vendor.mdx index 2c850def..ab82c46c 100644 --- a/external/vendor.mdx +++ b/external/vendor.mdx @@ -25,9 +25,7 @@ absolute path. ## Vendor a specific external repository {#vendor-specific-repository} You can use the `vendor` command with the `--repo` flag to specify which repo -to vendor, it accepts both [canonical repo -name](/external/overview#canonical-repo-name) and [apparent repo -name](/external/overview#apparent-repo-name). +to vendor, it accepts both [canonical repo name](/external/overview#canonical-repo-name) and [apparent repo name](/external/overview#apparent-repo-name). For example, running: diff --git a/help.mdx b/help.mdx index 6226c6e5..e6a1d79e 100644 --- a/help.mdx +++ b/help.mdx @@ -51,5 +51,4 @@ what level of support Bazel provides. ## File a bug {#file-bug} -If you encounter a bug or want to request a feature, file a [GitHub -Issue](https://github.com/bazelbuild/bazel/issues). +If you encounter a bug or want to request a feature, file a [GitHub Issue](https://github.com/bazelbuild/bazel/issues). diff --git a/images/about.svg b/images/about.svg new file mode 100644 index 00000000..f927298f --- /dev/null +++ b/images/about.svg @@ -0,0 +1 @@ + \ No newline at end of file diff --git a/images/basics.svg b/images/basics.svg new file mode 100644 index 00000000..013ec519 --- /dev/null +++ b/images/basics.svg @@ -0,0 +1 @@ + \ No newline at end of file diff --git a/images/bazel_hero.svg b/images/bazel_hero.svg new file mode 100644 index 00000000..c48714d0 --- /dev/null +++ b/images/bazel_hero.svg @@ -0,0 +1 @@ + \ No newline at end of file diff --git a/images/community.svg b/images/community.svg new file mode 100644 index 00000000..29f87a76 --- /dev/null +++ b/images/community.svg @@ -0,0 +1 @@ + \ No newline at end of file diff --git a/images/distributed-build-remote-cache.png b/images/distributed-build-remote-cache.png new file mode 100644 index 00000000..99d8a915 Binary files /dev/null and b/images/distributed-build-remote-cache.png differ diff --git a/images/extend.svg b/images/extend.svg new file mode 100644 index 00000000..77b2dd97 --- /dev/null +++ b/images/extend.svg @@ -0,0 +1 @@ + \ No newline at end of file diff --git a/images/guide.svg b/images/guide.svg new file mode 100644 index 00000000..23a5d35a --- /dev/null +++ b/images/guide.svg @@ -0,0 +1 @@ + \ No newline at end of file diff --git a/images/high-level-build-system.png b/images/high-level-build-system.png new file mode 100644 index 00000000..462717fa Binary files /dev/null and b/images/high-level-build-system.png differ diff --git a/images/placeholder.png b/images/placeholder.png new file mode 100644 index 00000000..54f1fa0e Binary files /dev/null and b/images/placeholder.png differ diff --git a/images/reference.svg b/images/reference.svg new file mode 100644 index 00000000..7bbc9bea --- /dev/null +++ b/images/reference.svg @@ -0,0 +1 @@ + \ No newline at end of file diff --git a/images/remote-execution-system.png b/images/remote-execution-system.png new file mode 100644 index 00000000..8152fc0c Binary files /dev/null and b/images/remote-execution-system.png differ diff --git a/images/start.svg b/images/start.svg new file mode 100644 index 00000000..3bcebd7b --- /dev/null +++ b/images/start.svg @@ -0,0 +1 @@ + \ No newline at end of file diff --git a/images/task-dependencies.png b/images/task-dependencies.png new file mode 100644 index 00000000..ae1f9c51 Binary files /dev/null and b/images/task-dependencies.png differ diff --git a/images/test.png b/images/test.png new file mode 100644 index 00000000..243939da Binary files /dev/null and b/images/test.png differ diff --git a/images/transitive-dependencies.png b/images/transitive-dependencies.png new file mode 100644 index 00000000..ec641a08 Binary files /dev/null and b/images/transitive-dependencies.png differ diff --git a/images/trunk-logo-dark.svg b/images/trunk-logo-dark.svg new file mode 100644 index 00000000..f25940af --- /dev/null +++ b/images/trunk-logo-dark.svg @@ -0,0 +1,22 @@ + + + + + + + + + + + + + + + + + + + + + + diff --git a/images/why_faq.svg b/images/why_faq.svg new file mode 100644 index 00000000..afec3f8f --- /dev/null +++ b/images/why_faq.svg @@ -0,0 +1 @@ + \ No newline at end of file diff --git a/images/why_overview.svg b/images/why_overview.svg new file mode 100644 index 00000000..c10c363c --- /dev/null +++ b/images/why_overview.svg @@ -0,0 +1 @@ + \ No newline at end of file diff --git a/images/why_vision.svg b/images/why_vision.svg new file mode 100644 index 00000000..739e415f --- /dev/null +++ b/images/why_vision.svg @@ -0,0 +1 @@ + \ No newline at end of file diff --git a/install/bazelisk.mdx b/install/bazelisk.mdx index 6c0d5cc1..3acb1147 100644 --- a/install/bazelisk.mdx +++ b/install/bazelisk.mdx @@ -18,8 +18,7 @@ For more details, see ## Updating Bazel Bazel has a [backward compatibility policy](/release/backward-compatibility) -(see [guidance for rolling out incompatible -changes](/contribute/breaking-changes) if you +(see [guidance for rolling out incompatible changes](/contribute/breaking-changes) if you are the author of one). That page summarizes best practices on how to test and migrate your project with upcoming incompatible changes and how to provide feedback to the incompatible change authors. diff --git a/install/compile-source.mdx b/install/compile-source.mdx index c2fb5afd..9479e0cb 100644 --- a/install/compile-source.mdx +++ b/install/compile-source.mdx @@ -55,8 +55,7 @@ it by typing `bazel` in a terminal. **Reason**: To build Bazel from a GitHub source tree, you need a pre-existing Bazel binary. You can install one from a package manager or download one from -GitHub. See [Installing Bazel](/install). (Or you can [build from -scratch (bootstrap)](#bootstrap-bazel).) +GitHub. See [Installing Bazel](/install). (Or you can [build from scratch (bootstrap)](#bootstrap-bazel).) **Troubleshooting**: @@ -248,8 +247,7 @@ For instructions for Unix-like systems, see ``` * **The Visual C++ compiler.** Install the Visual C++ compiler either as part - of Visual Studio 2015 or newer, or by installing the latest [Build Tools - for Visual Studio 2017](https://aka.ms/BuildTools). + of Visual Studio 2015 or newer, or by installing the latest [Build Tools for Visual Studio 2017](https://aka.ms/BuildTools). * **JDK.** Version 21 is required. diff --git a/install/ide.mdx b/install/ide.mdx index 22ee969f..d43d0696 100644 --- a/install/ide.mdx +++ b/install/ide.mdx @@ -23,10 +23,8 @@ a discussion on [GitHub](https://github.com/bazelbuild/bazel/discussions). Official Bazel plugins exist for many of the JetBrains-associated IDEs. Full documentation is linked from the listings on the JetBrains Marketplace: -* [IntelliJ - plugin](https://plugins.jetbrains.com/plugin/22977-bazel) -* [Android Studio - plugin](https://plugins.jetbrains.com/plugin/9185-android-studio-with-bazel) +* [IntelliJ plugin](https://plugins.jetbrains.com/plugin/22977-bazel) +* [Android Studio plugin](https://plugins.jetbrains.com/plugin/9185-android-studio-with-bazel) * [CLion plugin](https://plugins.jetbrains.com/plugin/9554-clion-with-bazel) Features: @@ -62,8 +60,7 @@ Features: * Starlark debugger for `.bzl` files during a build (set breakpoints, step through code, inspect variables, and so on) -Find [the plugin on the Visual Studio -marketplace](https://marketplace.visualstudio.com/items?itemName=BazelBuild.vscode-bazel) +Find [the plugin on the Visual Studio marketplace](https://marketplace.visualstudio.com/items?itemName=BazelBuild.vscode-bazel) or the [OpenVSX marketplace](https://open-vsx.org/extension/BazelBuild/vscode-bazel). The plugin is [open source](https://github.com/bazelbuild/vscode-bazel). @@ -84,8 +81,7 @@ See also: [Autocomplete for Source Code](#autocomplete-for-source-code) ### Emacs {#emacs} -See [`bazelbuild/bazel-emacs-mode` on -GitHub](https://github.com/bazelbuild/emacs-bazel-mode) +See [`bazelbuild/bazel-emacs-mode` on GitHub](https://github.com/bazelbuild/emacs-bazel-mode) See also: [Autocomplete for Source Code](#autocomplete-for-source-code) @@ -123,6 +119,5 @@ tool for building Bazel targets when source files change. ## Building your own IDE plugin {#build-own-plugin} -Read the [**IDE support** blog -post](https://blog.bazel.build/2016/06/10/ide-support.html) to learn more about +Read the [**IDE support** blog post](https://blog.bazel.build/2016/06/10/ide-support.html) to learn more about the Bazel APIs to use when building an IDE plugin. diff --git a/install/images/bazelisk.svg b/install/images/bazelisk.svg new file mode 100644 index 00000000..c0ae9f54 --- /dev/null +++ b/install/images/bazelisk.svg @@ -0,0 +1 @@ + \ No newline at end of file diff --git a/install/images/cli.svg b/install/images/cli.svg new file mode 100644 index 00000000..01119280 --- /dev/null +++ b/install/images/cli.svg @@ -0,0 +1 @@ + \ No newline at end of file diff --git a/install/images/docker.svg b/install/images/docker.svg new file mode 100644 index 00000000..21190ce0 --- /dev/null +++ b/install/images/docker.svg @@ -0,0 +1,6 @@ + \ No newline at end of file diff --git a/install/images/github.svg b/install/images/github.svg new file mode 100644 index 00000000..aa05db9c --- /dev/null +++ b/install/images/github.svg @@ -0,0 +1 @@ + \ No newline at end of file diff --git a/install/images/install.svg b/install/images/install.svg new file mode 100644 index 00000000..ae080865 --- /dev/null +++ b/install/images/install.svg @@ -0,0 +1 @@ + \ No newline at end of file diff --git a/install/images/mac.svg b/install/images/mac.svg new file mode 100644 index 00000000..3ee4fe28 --- /dev/null +++ b/install/images/mac.svg @@ -0,0 +1 @@ + \ No newline at end of file diff --git a/install/images/redhat.svg b/install/images/redhat.svg new file mode 100644 index 00000000..078b3387 --- /dev/null +++ b/install/images/redhat.svg @@ -0,0 +1,69 @@ + + + + + + image/svg+xml + + + + + + + + + + + + diff --git a/install/images/suse.png b/install/images/suse.png new file mode 100644 index 00000000..6435b689 Binary files /dev/null and b/install/images/suse.png differ diff --git a/install/images/tune.svg b/install/images/tune.svg new file mode 100644 index 00000000..8d7d63cb --- /dev/null +++ b/install/images/tune.svg @@ -0,0 +1 @@ + \ No newline at end of file diff --git a/install/images/ubuntu.svg b/install/images/ubuntu.svg new file mode 100644 index 00000000..f217bc8d --- /dev/null +++ b/install/images/ubuntu.svg @@ -0,0 +1,8 @@ + + + + + + + + \ No newline at end of file diff --git a/install/images/windows.svg b/install/images/windows.svg new file mode 100644 index 00000000..120b0190 --- /dev/null +++ b/install/images/windows.svg @@ -0,0 +1,5 @@ + + + + + \ No newline at end of file diff --git a/install/index.mdx b/install/index.mdx index dc1e6d28..912ac212 100644 --- a/install/index.mdx +++ b/install/index.mdx @@ -22,7 +22,7 @@ officially support them. Contact the package maintainers for support. * [Fedora](https://copr.fedorainfracloud.org/coprs/lihaohong/bazel) * [FreeBSD](https://www.freshports.org/devel/bazel) * [Homebrew](https://formulae.brew.sh/formula/bazel) -* [mise](install/mise) +* [mise](/install/mise) * [Nixpkgs](https://github.com/NixOS/nixpkgs/blob/master/pkgs/development/tools/build-managers/bazel) * [openSUSE](/install/suse) * [Scoop](https://github.com/scoopinstaller/scoop-main/blob/master/bucket/bazel.json) diff --git a/install/windows.mdx b/install/windows.mdx index 9b0b07de..dc2edb0a 100644 --- a/install/windows.mdx +++ b/install/windows.mdx @@ -34,8 +34,7 @@ To check your Windows version: Alternatively you can: -* [Download the Bazel binary (`bazel-version-windows-x86_64.exe`) from - GitHub](https://github.com/bazelbuild/bazel/releases). +* [Download the Bazel binary (`bazel-version-windows-x86_64.exe`) from GitHub](https://github.com/bazelbuild/bazel/releases). * [Install Bazel from Chocolatey](#chocolately) * [Install Bazel from Scoop](#scoop) * [Build Bazel from source](/install/compile-source) @@ -211,8 +210,7 @@ If that doesn't help: its dependencies, such as the MSYS2 shell. This will not install Visual C++ though. -See [Chocolatey installation and package maintenance -guide](/contribute/windows-chocolatey-maintenance) for more +See [Chocolatey installation and package maintenance guide](/contribute/windows-chocolatey-maintenance) for more information about the Chocolatey package. ### Using Scoop {#scoop} @@ -229,8 +227,7 @@ information about the Chocolatey package. scoop install bazel ``` -See [Scoop installation and package maintenance -guide](/contribute/windows-scoop-maintenance) for more +See [Scoop installation and package maintenance guide](/contribute/windows-scoop-maintenance) for more information about the Scoop package. ### Build from source {#build-from-source} diff --git a/migrate/maven.mdx b/migrate/maven.mdx index ac8a042f..3b564450 100644 --- a/migrate/maven.mdx +++ b/migrate/maven.mdx @@ -19,8 +19,7 @@ directly run by Bazel since there's no Maven compatibility layer. ## Before you begin {#before-you-begin} * [Install Bazel](/install) if it's not yet installed. -* If you're new to Bazel, go through the tutorial [Introduction to Bazel: - Build Java](/start/java) before you start migrating. The tutorial explains +* If you're new to Bazel, go through the tutorial [Introduction to Bazel: Build Java](/start/java) before you start migrating. The tutorial explains Bazel's concepts, structure, and label syntax. ## Differences between Maven and Bazel {#dif-maven-bazel} @@ -44,8 +43,7 @@ The steps below describe how to migrate your project to Bazel: 3. [Create more BUILD files](#3-build) 4. [Build using Bazel](#4-build) -Examples below come from a migration of the [Guava -project](https://github.com/google/guava) from Maven to Bazel. The +Examples below come from a migration of the [Guava project](https://github.com/google/guava) from Maven to Bazel. The Guava project used is release `v31.1`. The examples using Guava do not walk through each step in the migration, but they do show the files and contents that are generated or added manually for the migration. @@ -63,14 +61,12 @@ has no external dependencies, this file can be empty. If your project depends on files or packages that are not in one of the project's directories, specify these external dependencies in the MODULE.bazel file. You can use `rules_jvm_external` to manage dependencies from Maven. For -instructions about using this ruleset, see [the -README](https://github.com/bazelbuild/rules_jvm_external/#rules_jvm_external) +instructions about using this ruleset, see [the README](https://github.com/bazelbuild/rules_jvm_external/#rules_jvm_external) . #### Guava project example: external dependencies {#guava-1} -You can list the external dependencies of the [Guava -project](https://github.com/google/guava) with the +You can list the external dependencies of the [Guava project](https://github.com/google/guava) with the [`rules_jvm_external`](https://github.com/bazelbuild/rules_jvm_external) ruleset. @@ -164,8 +160,7 @@ your build by adding more `BUILD` files with more granular targets. * `resources`: Use globbing to list all resources in your project. * `deps`: You need to determine which external dependencies your project needs. - * Take a look at the [example below of this top-level BUILD - file](#guava-2) from the migration of the Guava project. + * Take a look at the [example below of this top-level BUILD file](#guava-2) from the migration of the Guava project. 3. Now that you have a `BUILD` file at the root of your project, build your project to ensure that it works. On the command line, from your workspace diff --git a/migrate/xcode.mdx b/migrate/xcode.mdx index 84e52f86..5f6a05a2 100644 --- a/migrate/xcode.mdx +++ b/migrate/xcode.mdx @@ -32,8 +32,7 @@ Before you begin, do the following: 1. [Install Bazel](/install) if you have not already done so. -2. If you're not familiar with Bazel and its concepts, complete the [iOS app - tutorial](/start/ios-app)). You should understand the Bazel workspace, +2. If you're not familiar with Bazel and its concepts, complete the [iOS app tutorial](/start/ios-app)). You should understand the Bazel workspace, including the `MODULE.bazel` and `BUILD` files, as well as the concepts of targets, build rules, and Bazel packages. @@ -44,8 +43,7 @@ Before you begin, do the following: Unlike Xcode, Bazel requires you to explicitly declare all dependencies for every target in the `BUILD` file. -For more information on external dependencies, see [Working with external -dependencies](/docs/external). +For more information on external dependencies, see [Working with external dependencies](/docs/external). ## Build or test an Xcode project with Bazel {#build-xcode-project} @@ -84,8 +82,7 @@ Note: Place the project source code within the directory tree containing the To integrate SwiftPM dependencies into the Bazel workspace with [swift_bazel](https://github.com/cgrindel/swift_bazel), you must -convert them into Bazel packages as described in the [following -tutorial](https://chuckgrindel.com/swift-packages-in-bazel-using-swift_bazel/) +convert them into Bazel packages as described in the [following tutorial](https://chuckgrindel.com/swift-packages-in-bazel-using-swift_bazel/) . Note: SwiftPM support is a manual process with many variables. SwiftPM @@ -103,8 +100,7 @@ initial build of the project as follows: * [Step 3b: (Optional) Add the test target(s)](#step-3b-optional-add-the-test-target-s) * [Step 3c: Add the library target(s)](#step-3c-add-the-library-target-s) -**Tip:** To learn more about packages and other Bazel concepts, see [Workspaces, -packages, and targets](/concepts/build-ref). +**Tip:** To learn more about packages and other Bazel concepts, see [Workspaces, packages, and targets](/concepts/build-ref). #### Step 3a: Add the application target {#add-app-target} @@ -132,8 +128,7 @@ In the target, specify the following at the minimum: #### Step 3b: (Optional) Add the test target(s) {#add-test-target} -Bazel's [Apple build -rules](https://github.com/bazelbuild/rules_apple) support running +Bazel's [Apple build rules](https://github.com/bazelbuild/rules_apple) support running unit and UI tests on all Apple platforms. Add test targets as follows: * [`macos_unit_test`](https://github.com/bazelbuild/rules_apple/blob/master/doc/rules-macos.md#macos_unit_test) @@ -181,8 +176,7 @@ all sources and/or headers of a certain type. Use it carefully as it might include files you do not want Bazel to build. You can browse existing examples for various types of applications directly in -the [rules_apple examples -directory](https://github.com/bazelbuild/rules_apple/tree/master/examples/). For +the [rules_apple examples directory](https://github.com/bazelbuild/rules_apple/tree/master/examples/). For example: * [macOS application targets](https://github.com/bazelbuild/rules_apple/tree/master/examples/macos) @@ -191,8 +185,7 @@ example: * [Multi platform applications (macOS, iOS, watchOS, tvOS)](https://github.com/bazelbuild/rules_apple/tree/master/examples/multi_platform) -For more information on build rules, see [Apple Rules for -Bazel](https://github.com/bazelbuild/rules_apple). +For more information on build rules, see [Apple Rules for Bazel](https://github.com/bazelbuild/rules_apple). At this point, it is a good idea to test the build: diff --git a/navigation.json b/navigation.json index 59780a3c..a3d046ca 100644 --- a/navigation.json +++ b/navigation.json @@ -8,6 +8,14 @@ } ] }, + { + "version": "9.1", + "languages": [ + { + "$ref": "./navigation/9.1.en.json" + } + ] + }, { "version": "9.0", "languages": [ diff --git a/navigation/9.1.en.json b/navigation/9.1.en.json new file mode 100644 index 00000000..6b76b109 --- /dev/null +++ b/navigation/9.1.en.json @@ -0,0 +1,276 @@ +{ + "language": "en", + "tabs": [ + { + "tab": "About Bazel", + "groups": [ + { + "group": "Why Bazel?", + "pages": [ + "versions/9.1.0/about/intro", + "versions/9.1.0/about/why", + "versions/9.1.0/about/vision", + "versions/9.1.0/about/faq" + ] + }, + { + "group": "Build system basics", + "pages": [ + "versions/9.1.0/basics/index", + "versions/9.1.0/basics/build-systems", + "versions/9.1.0/basics/task-based-builds", + "versions/9.1.0/basics/artifact-based-builds", + "versions/9.1.0/basics/distributed-builds", + "versions/9.1.0/basics/dependencies", + "versions/9.1.0/basics/hermeticity" + ] + } + ] + }, + { + "tab": "Getting started", + "groups": [ + { + "group": "Install", + "pages": [ + "versions/9.1.0/install/index", + "versions/9.1.0/install/bazelisk", + "versions/9.1.0/install/os-x", + "versions/9.1.0/install/windows", + "versions/9.1.0/install/ubuntu", + "versions/9.1.0/install/suse", + "versions/9.1.0/install/docker-container", + "versions/9.1.0/install/compile-source", + "versions/9.1.0/install/completion", + "versions/9.1.0/install/ide" + ] + }, + { + "group": "First build tutorials", + "pages": [ + "versions/9.1.0/start/cpp", + "versions/9.1.0/start/java", + "versions/9.1.0/start/android-app", + "versions/9.1.0/start/ios-app" + ] + }, + { + "group": "Concepts", + "pages": [ + "versions/9.1.0/concepts/build-ref", + "versions/9.1.0/concepts/labels", + "versions/9.1.0/concepts/build-files", + "versions/9.1.0/concepts/dependencies", + "versions/9.1.0/concepts/visibility", + "versions/9.1.0/concepts/platforms" + ] + } + ] + }, + { + "tab": "User guide", + "groups": [ + { + "group": "Releases", + "pages": [ + "versions/9.1.0/release/index", + "versions/9.1.0/release/rolling", + "versions/9.1.0/release/backward-compatibility", + "versions/9.1.0/release/rule-compatibility" + ] + }, + { + "group": "Basics", + "pages": [ + "versions/9.1.0/build/style-guide", + "versions/9.1.0/build/share-variables", + "versions/9.1.0/community/recommended-rules", + "versions/9.1.0/run/build" + ] + }, + { + "group": "Advanced", + "pages": [ + "versions/9.1.0/configure/attributes", + "versions/9.1.0/configure/integrate-cpp", + "versions/9.1.0/configure/coverage", + "versions/9.1.0/configure/best-practices", + "versions/9.1.0/configure/windows", + "versions/9.1.0/advanced/performance/build-performance-metrics", + "versions/9.1.0/advanced/performance/build-performance-breakdown", + "versions/9.1.0/advanced/performance/json-trace-profile", + "versions/9.1.0/advanced/performance/memory", + "versions/9.1.0/advanced/performance/iteration-speed" + ] + }, + { + "group": "Remote Execution", + "pages": [ + "versions/9.1.0/remote/rbe", + "versions/9.1.0/remote/rules", + "versions/9.1.0/remote/ci", + "versions/9.1.0/remote/dynamic", + "versions/9.1.0/remote/caching", + "versions/9.1.0/remote/sandbox", + "versions/9.1.0/remote/workspace", + "versions/9.1.0/remote/cache-remote", + "versions/9.1.0/remote/cache-local", + "versions/9.1.0/remote/output-directories", + "versions/9.1.0/remote/persistent", + "versions/9.1.0/remote/multiplex", + "versions/9.1.0/remote/creating", + "versions/9.1.0/remote/bep", + "versions/9.1.0/remote/bep-examples", + "versions/9.1.0/remote/bep-glossary" + ] + }, + { + "group": "Tutorials", + "pages": [ + "versions/9.1.0/tutorials/cpp-use-cases", + "versions/9.1.0/tutorials/ccp-toolchain-config", + "versions/9.1.0/tutorials/cpp-dependency", + "versions/9.1.0/tutorials/cpp-labels" + ] + }, + { + "group": "Migrate", + "pages": [ + "versions/9.1.0/migrate/index", + "versions/9.1.0/migrate/maven", + "versions/9.1.0/migrate/xcode" + ] + } + ] + }, + { + "tab": "Reference", + "groups": [ + { + "group": "Build encyclopedia", + "pages": [ + "versions/9.1.0/reference/be/overview", + "versions/9.1.0/reference/be/common-definitions", + "versions/9.1.0/reference/be/make-variables", + "versions/9.1.0/reference/be/functions", + "versions/9.1.0/reference/be/platforms-and-toolchains" + ] + }, + { + "group": "Command line reference", + "pages": [ + "versions/9.1.0/reference/command-line-reference" + ] + }, + { + "group": "Query Language", + "pages": [ + "versions/9.1.0/query/language", + "versions/9.1.0/query/quickstart" + ] + }, + { + "group": "Glossary", + "pages": [ + "versions/9.1.0/reference/glossary" + ] + }, + { + "group": "Flag cheatsheet", + "pages": [ + "versions/9.1.0/reference/flag-cheatsheet" + ] + } + ] + }, + { + "tab": "Extending", + "groups": [ + { + "group": "Concepts", + "pages": [ + "versions/9.1.0/extending/concepts" + ] + }, + { + "group": "Writing rules", + "pages": [ + "versions/9.1.0/rules/rules-tutorial", + "versions/9.1.0/rules/macro-tutorial", + "versions/9.1.0/rules/legacy-macro-tutorial", + "versions/9.1.0/rules/verbs-tutorial", + "versions/9.1.0/rules/language", + "versions/9.1.0/rules/bzl-style", + "versions/9.1.0/rules/challenges", + "versions/9.1.0/rules/windows" + ] + }, + { + "group": "Distributing rules", + "pages": [ + "versions/9.1.0/rules/testing", + "versions/9.1.0/rules/performance", + "versions/9.1.0/rules/deploying" + ] + }, + { + "group": "APIs", + "pages": [ + "versions/9.1.0/rules/lib/overview", + "versions/9.1.0/rules/lib/globals", + "versions/9.1.0/rules/lib/globals/bzl", + "versions/9.1.0/rules/lib/globals/module" + ] + }, + { + "group": "Repo rules", + "pages": [ + "versions/9.1.0/rules/lib/repo/index", + "versions/9.1.0/rules/lib/repo/cache", + "versions/9.1.0/rules/lib/repo/git", + "versions/9.1.0/rules/lib/repo/http", + "versions/9.1.0/rules/lib/repo/local", + "versions/9.1.0/rules/lib/repo/utils" + ] + } + ] + }, + { + "tab": "Community", + "groups": [ + { + "group": "Contributing", + "pages": [ + "versions/9.1.0/contribute/index", + "versions/9.1.0/contribute/policy", + "versions/9.1.0/contribute/patch-acceptance", + "versions/9.1.0/contribute/maintainers-guide", + "versions/9.1.0/contribute/codebase", + "versions/9.1.0/contribute/search", + "versions/9.1.0/contribute/statemachine-guide", + "versions/9.1.0/contribute/docs", + "versions/9.1.0/contribute/docs-style-guide", + "versions/9.1.0/contribute/design-documents", + "versions/9.1.0/contribute/release-notes" + ] + }, + { + "group": "Programs", + "pages": [ + "versions/9.1.0/community/sig", + "versions/9.1.0/community/users", + "versions/9.1.0/community/recommended-rules", + "versions/9.1.0/community/remote-execution-services" + ] + }, + { + "group": "Getting help", + "pages": [ + "versions/9.1.0/help", + "versions/9.1.0/contribute/policy" + ] + } + ] + } + ] +} diff --git a/query/cquery.mdx b/query/cquery.mdx index e734f231..f7195d40 100644 --- a/query/cquery.mdx +++ b/query/cquery.mdx @@ -8,8 +8,7 @@ title: 'Configurable Query (cquery)' [`select()`](/docs/configurable-attributes) and build options' effects on the build graph. -It achieves this by running over the results of Bazel's [analysis -phase](/extending/concepts#evaluation-model), +It achieves this by running over the results of Bazel's [analysis phase](/extending/concepts#evaluation-model), which integrates these effects. `query`, by contrast, runs over the results of Bazel's loading phase, before options are evaluated. @@ -140,8 +139,7 @@ $ bazel cquery //foo --universe_scope=//foo,//genrule_with_foo_as_tool If you want to precisely declare which instance to query over, use the [`config`](#config) function. -See `query`'s [target pattern -documentation](/query/language#target-patterns) for more information on target +See `query`'s [target pattern documentation](/query/language#target-patterns) for more information on target patterns. ## Functions {#functions} @@ -543,8 +541,7 @@ different niches. Consider the following to decide which is right for you: It's therefore prone to picking up results from past queries. For example, `genrule` exerts an exec transition on its `tools` attribute - -that is, it configures its tools in the [exec configuration] -(https://bazel.build/rules/rules#configurations). +that is, it configures its tools in the [exec configuration](https://bazel.build/rules/rules#configurations). You can see the lingering effects of that transition below. diff --git a/query/images/query_graph1.png b/query/images/query_graph1.png new file mode 100644 index 00000000..7bc9a61a Binary files /dev/null and b/query/images/query_graph1.png differ diff --git a/query/images/query_graph2.png b/query/images/query_graph2.png new file mode 100644 index 00000000..a0da22ff Binary files /dev/null and b/query/images/query_graph2.png differ diff --git a/query/images/query_graph3.png b/query/images/query_graph3.png new file mode 100644 index 00000000..4418f193 Binary files /dev/null and b/query/images/query_graph3.png differ diff --git a/query/language.mdx b/query/language.mdx index 53e11e57..ee539b29 100644 --- a/query/language.mdx +++ b/query/language.mdx @@ -1145,8 +1145,7 @@ is being used. ### On the ordering of results {#results-ordering} -Although query expressions always follow the "[law of -conservation of graph order](#graph-order)", _presenting_ the results may be done +Although query expressions always follow the "[law of conservation of graph order](#graph-order)", _presenting_ the results may be done in either a dependency-ordered or unordered manner. This does **not** influence the targets in the result set or how the query is computed. It only affects how the results are printed to stdout. Moreover, nodes that are @@ -1292,8 +1291,7 @@ and `maxrank` output formats print the labels of each target in the resulting graph, but instead of appearing in topological order, they appear in rank order, preceded by their rank number. These are unaffected by the result ordering -`--[no]order_results` flag (see [notes on -the ordering of results](#result-order)). +`--[no]order_results` flag (see [notes on the ordering of results](#result-order)). There are two variants of this format: `minrank` ranks each node by the length of the shortest path from a root node to it. diff --git a/query/quickstart.mdx b/query/quickstart.mdx index eebcec98..d2085b8b 100644 --- a/query/quickstart.mdx +++ b/query/quickstart.mdx @@ -205,7 +205,7 @@ dot -Tpng < graph.in > graph.png ``` If you open up `graph.png`, you should see something like this. The graph below has been simplified to make the essential path details clearer in this guide. -![Diagram showing a relationship from cafe to chef to the dishes: pizza and mac and cheese which diverges into the separate ingredients: cheese, tomatoes, dough, and macaroni.](images/query_graph1.png "Dependency graph") +![Diagram showing a relationship from cafe to chef to the dishes: pizza and mac and cheese which diverges into the separate ingredients: cheese, tomatoes, dough, and macaroni.](/query/images/query_graph1.png "Dependency graph") This helps when you want to see the outputs of the different query functions throughout this guide. @@ -421,7 +421,7 @@ bazel query --noimplicit_deps 'deps(:runner)' --output graph > graph2.in dot -Tpng < graph2.in > graph2.png ``` -[![The same graph as the first one except now there is a spoke stemming from the chef target with smoothie which leads to banana and strawberry](images/query_graph2.png "Updated dependency graph")](images/query_graph2.png) +[![The same graph as the first one except now there is a spoke stemming from the chef target with smoothie which leads to banana and strawberry](/query/images/query_graph2.png "Updated dependency graph")](/query/images/query_graph2.png) Looking at `graph2.png`, you can see that `Smoothie` has no shared dependencies with other dishes but is just another target that the `Chef` relies on. @@ -465,7 +465,7 @@ bazel query "allpaths(//src/main/java/com/example/restaurant/..., //src/main/jav //src/main/java/com/example/restaurant:chef ``` -![Output path of cafe to chef to pizza,mac and cheese to cheese](images/query_graph3.png "Output path for dependency") +![Output path of cafe to chef to pizza,mac and cheese to cheese](/query/images/query_graph3.png "Output path for dependency") The output of `allpaths()` is a little harder to read as it is a flattened list of the dependencies. Visualizing this graph using Graphviz makes the relationship clearer to understand. diff --git a/reference/glossary.mdx b/reference/glossary.mdx index 40065154..7d1e7dd9 100644 --- a/reference/glossary.mdx +++ b/reference/glossary.mdx @@ -24,8 +24,7 @@ An in-memory graph of [actions](#action) and the [artifacts](#artifact) that these actions read and generate. The graph might include artifacts that exist as source files (for example, in the file system) as well as generated intermediate/final artifacts that are not mentioned in `BUILD` files. Produced -during the [analysis phase](#analysis-phase) and used during the [execution -phase](#execution-phase). +during the [analysis phase](#analysis-phase) and used during the [execution phase](#execution-phase). ### Action graph query (aquery) {#action-graph-query} @@ -43,8 +42,7 @@ invalidate individual actions deterministically. ### Analysis phase {#analysis-phase} The second phase of a build. Processes the [target graph](#target-graph) -specified in [`BUILD` files](#build-file) to produce an in-memory [action -graph](#action-graph) that determines the order of actions to run during the +specified in [`BUILD` files](#build-file) to produce an in-memory [action graph](#action-graph) that determines the order of actions to run during the [execution phase](#execution-phase). This is the phase in which rule implementations are evaluated. @@ -92,8 +90,7 @@ attributes available for a given target depend on its rule type. ### .bazelrc {#bazelrc} -Bazel’s configuration file used to change the default values for [startup -flags](#startup-flags) and [command flags](#command-flags), and to define common +Bazel’s configuration file used to change the default values for [startup flags](#startup-flags) and [command flags](#command-flags), and to define common groups of options that can then be set together on the Bazel command line using a `--config` flag. Bazel can combine settings from multiple bazelrc files (systemwide, per-workspace, per-user, or from a custom location), and a @@ -123,8 +120,7 @@ directory. ### .bzl File {#bzl-file} A file that defines rules, [macros](#macro), and constants written in -[Starlark](#starlark). These can then be imported into [`BUILD` -files](#build-file) using the `load()` function. +[Starlark](#starlark). These can then be imported into [`BUILD` files](#build-file) using the `load()` function. ### Build Event Protocol {#build-event-protocol} @@ -146,8 +142,7 @@ arguments>`. A typical example would be `bazel --host_jvm_args=-Xmx512M test ### Build graph {#build-graph} The dependency graph that Bazel constructs and traverses to perform a build. -Includes nodes like [targets](#target), [configured -targets](#configured-target), [actions](#action), and [artifacts](#artifact). A +Includes nodes like [targets](#target), [configured targets](#configured-target), [actions](#action), and [artifacts](#artifact). A build is considered complete when all [artifacts](#artifact) on which a set of requested targets depend are verified as up-to-date. @@ -193,13 +188,10 @@ graphs and restart the [analysis phase](#analysis-phase). Information outside of [rule](#rule) definitions that impacts how rules generate [actions](#action). Every build has at least one configuration specifying the -target platform, action environment variables, and command-line [build -flags](#command-flags). [Transitions](#transition) may create additional +target platform, action environment variables, and command-line [build flags](#command-flags). [Transitions](#transition) may create additional configurations, such as for host tools or cross-compilation. -A configuration is composed of one of more [configuration -fragments](#configuration-fragment), and separately contains all set [Starlark -flags](#starlark-flags). +A configuration is composed of one of more [configuration fragments](#configuration-fragment), and separately contains all set [Starlark flags](#starlark-flags). **See also:** [Configurations](/extending/rules#configurations) @@ -224,8 +216,7 @@ build cacheability. ### Configured query (cquery) {#configured-query} -A [query](#query-concept) tool that queries over [configured -targets](#configured-target) (after the [analysis phase](#analysis-phase) +A [query](#query-concept) tool that queries over [configured targets](#configured-target) (after the [analysis phase](#analysis-phase) completes). This means `select()` and [build flags](#command-flags) (such as `--platforms`) are accurately reflected in the results. @@ -243,8 +234,7 @@ build, it has two configured targets: `` and ``. A build is correct when its output faithfully reflects the state of its transitive inputs. To achieve correct builds, Bazel strives to be -[hermetic](#hermeticity), reproducible, and making [build -analysis](#analysis-phase) and [action execution](#execution-phase) +[hermetic](#hermeticity), reproducible, and making [build analysis](#analysis-phase) and [action execution](#execution-phase) deterministic. ### Dependency {#dependency} @@ -292,8 +282,7 @@ incremental and clean build times. ### Execution phase {#execution-phase} -The third phase of a build. Executes the [actions](#action) in the [action -graph](#action-graph) created during the [analysis phase](#analysis-phase). +The third phase of a build. Executes the [actions](#action) in the [action graph](#action-graph) created during the [analysis phase](#analysis-phase). These actions invoke executables (compilers, scripts) to read and write [artifacts](#artifact). *Spawn strategies* control how these actions are executed: locally, remotely, dynamically, sandboxed, docker, and so on. @@ -354,8 +343,7 @@ syntax may be omitted. The first phase of a build where Bazel executes [`BUILD` files](#build-file) to create [packages](#package). [Macros](#macro) and certain functions like `glob()` are evaluated in this phase. Interleaved with the second phase of the -build, the [analysis phase](#analysis-phase), to build up a [target -graph](#target-graph). +build, the [analysis phase](#analysis-phase), to build up a [target graph](#target-graph). ### Legacy macro {#legacy-macro} @@ -410,8 +398,7 @@ Module metadata is hosted in Bazel registries. ### Module Extension {#module-extension} A piece of logic that can be run to generate [repos](#repository) by reading -inputs from across the [module](#module) dependency graph and invoking [repo -rules](#repository-rule). Module extensions have capabilities similar to repo +inputs from across the [module](#module) dependency graph and invoking [repo rules](#repository-rule). Module extensions have capabilities similar to repo rules, allowing them to access the internet, perform file I/O, and so on. **See also:** [Module extensions](/external/extension) @@ -426,8 +413,7 @@ example, `native.cc_library` or `native.java_library`). User-defined rules ### Output base {#output-base} A [workspace](#workspace)-specific directory to store Bazel output files. Used -to separate outputs from the *workspace*'s source tree (the [main -repo](#repository)). Located in the [output user root](#output-user-root). +to separate outputs from the *workspace*'s source tree (the [main repo](#repository)). Located in the [output user root](#output-user-root). ### Output groups {#output-groups} @@ -490,8 +476,7 @@ query variants: [query](#query-command), [cquery](#configured-query), and ### query (command) {#query-command} -A [query](#query-concept) tool that operates over the build's post-[loading -phase](#loading-phase) [target graph](#target-graph). This is relatively fast, +A [query](#query-concept) tool that operates over the build's post-[loading phase](#loading-phase) [target graph](#target-graph). This is relatively fast, but can't analyze the effects of `select()`, [build flags](#command-flags), [artifacts](#artifact), or build [actions](#action). @@ -510,8 +495,7 @@ repo; multiple such files can coexist in a directory. The *main repo* is the repo in which the current Bazel command is being run. *External repos* are defined by specifying [modules](#module) in `MODULE.bazel` -files, or invoking [repo rules](#repository-rule) in [module -extensions](#module-extension). They can be fetched on demand to a predetermined +files, or invoking [repo rules](#repository-rule) in [module extensions](#module-extension). They can be fetched on demand to a predetermined "magical" location on disk. Each repo has a unique, constant *canonical* name, and potentially different @@ -523,8 +507,7 @@ Each repo has a unique, constant *canonical* name, and potentially different A shared content-addressable cache of files downloaded by Bazel for builds, shareable across [workspaces](#workspace). Enables offline builds after the -initial download. Commonly used to cache files downloaded through [repository -rules](#repository-rule) like `http_archive` and repository rule APIs like +initial download. Commonly used to cache files downloaded through [repository rules](#repository-rule) like `http_archive` and repository rule APIs like `repository_ctx.download`. Files are cached only if their SHA-256 checksums are specified for the download. @@ -561,8 +544,7 @@ Rules are instantiated to produce rule targets in the [loading phase](#loading-phase). In the [analysis phase](#analysis-phase) rule targets communicate information to their downstream dependencies in the form of [providers](#provider), and register [actions](#action) describing how to -generate their output artifacts. These actions are run in the [execution -phase](#execution-phase). +generate their output artifacts. These actions are run in the [execution phase](#execution-phase). Note: Historically the term "rule" has been used to refer to a rule target. This usage was inherited from tools like Make, but causes confusion and should @@ -630,8 +612,7 @@ support the stamp attribute. The extension language for writing [rules](/extending/rules) and [macros](#macro). A restricted subset of Python (syntactically and grammatically) aimed for the -purpose of configuration, and for better performance. Uses the [`.bzl` -file](#bzl-file) extension. [`BUILD` files](#build-file) use an even more +purpose of configuration, and for better performance. Uses the [`.bzl` file](#bzl-file) extension. [`BUILD` files](#build-file) use an even more restricted version of Starlark (such as no `def` function definitions), formerly known as Skylark. @@ -640,8 +621,7 @@ known as Skylark. ### Starlark flags {#starlark-flags} Rules can define [custom flags](/extending/config#user-defined-build-settings), -known as Starlark flags because they are implemented using [Starlark -rules](#starlark-rules). These flags control how the rule behaves at a higher +known as Starlark flags because they are implemented using [Starlark rules](#starlark-rules). These flags control how the rule behaves at a higher level than individual BUILD files. **See also**: [Configurations](/extending/config) @@ -677,8 +657,7 @@ An object that is defined in a [`BUILD` file](#build-file) and identified by a [label](#label). Targets represent the buildable units of a workspace from the perspective of the end user. -A target that is declared by instantiating a [rule](#rule) is called a [rule -target](#rule-target). Depending on the rule, these may be runnable (like +A target that is declared by instantiating a [rule](#rule) is called a [rule target](#rule-target). Depending on the rule, these may be runnable (like `cc_binary`) or testable (like `cc_test`). Rule targets typically depend on other targets via their [attributes](#attribute) (such as `deps`); these dependencies form the basis of the [target graph](#target-graph). @@ -689,15 +668,12 @@ within a `BUILD` file. As a special case, the `BUILD` file of any package is always considered a source file target in that package. Targets are discovered during the [loading phase](#loading-phase). During the -[analysis phase](#analysis-phase), targets are associated with [build -configurations](#configuration) to form [configured -targets](#configured-target). +[analysis phase](#analysis-phase), targets are associated with [build configurations](#configuration) to form [configured targets](#configured-target). ### Target graph {#target-graph} An in-memory graph of [targets](#target) and their dependencies. Produced during -the [loading phase](#loading-phase) and used as an input to the [analysis -phase](#analysis-phase). +the [loading phase](#loading-phase) and used as an input to the [analysis phase](#analysis-phase). ### Target pattern {#target-pattern} @@ -712,8 +688,7 @@ packages recursively from the root of the [workspace](#workspace). Rule [targets](#target) instantiated from test rules, and therefore contains a test executable. A return code of zero from the completion of the executable indicates test success. The exact contract between Bazel and tests (such as test -environment variables, test result collection methods) is specified in the [Test -Encyclopedia](/reference/test-encyclopedia). +environment variables, test result collection methods) is specified in the [Test Encyclopedia](/reference/test-encyclopedia). ### Toolchain {#toolchain} @@ -729,8 +704,7 @@ A build [target](#target) is top-level if it’s requested on the Bazel command line. For example, if `//:foo` depends on `//:bar`, and `bazel build //:foo` is called, then for this build, `//:foo` is top-level, and `//:bar` isn’t top-level, although both targets will need to be built. An important difference -between top-level and non-top-level targets is that [command -flags](#command-flags) set on the Bazel command line (or via +between top-level and non-top-level targets is that [command flags](#command-flags) set on the Bazel command line (or via [.bazelrc](#bazelrc)) will set the [configuration](#configuration) for top-level targets, but might be modified by a [transition](#transition) for non-top-level targets. @@ -765,8 +739,7 @@ or `.bzl` file may load a given `.bzl` file. Without context, usually ### Workspace {#workspace} -The environment shared by all Bazel commands run from the same [main -repository](#repository). +The environment shared by all Bazel commands run from the same [main repository](#repository). Note that historically the concepts of "repository" and "workspace" have been conflated; the term "workspace" has often been used to refer to the main diff --git a/reference/test-encyclopedia.mdx b/reference/test-encyclopedia.mdx index b613577b..eade94bc 100644 --- a/reference/test-encyclopedia.mdx +++ b/reference/test-encyclopedia.mdx @@ -700,8 +700,7 @@ mark it as having failed. The [execution platform](/extending/platforms) for a test action is determined via [toolchain resolution](/extending/toolchains#toolchain-resolution), just -like for any other action. Each test rule has an implicitly defined [ -`test` exec group](/extending/exec-groups#exec-groups-for-native-rules) that, +like for any other action. Each test rule has an implicitly defined [`test` exec group](/extending/exec-groups#exec-groups-for-native-rules) that, unless overridden, has a mandatory toolchain requirement on `@bazel_tools//tools/test:default_test_toolchain_type`. @@ -742,8 +741,7 @@ a default toolchain for it. Some tags in the test rules have a special meaning. See also the -[Bazel Build Encyclopedia on the `tags` attribute] -(/reference/be/common-definitions#common.tags). +[Bazel Build Encyclopedia on the `tags` attribute](/reference/be/common-definitions#common.tags). diff --git a/release/backward-compatibility.mdx b/release/backward-compatibility.mdx index 780e9f71..b838e511 100644 --- a/release/backward-compatibility.mdx +++ b/release/backward-compatibility.mdx @@ -8,11 +8,9 @@ This page provides information about how to handle backward compatibility, including migrating from one release to another and how to communicate incompatible changes. -Bazel is evolving. Minor versions released as part of an [LTS major -version](/release#bazel-versioning) are fully backward-compatible. New major LTS +Bazel is evolving. Minor versions released as part of an [LTS major version](/release#bazel-versioning) are fully backward-compatible. New major LTS releases may contain incompatible changes that require some migration effort. -For more information about Bazel's release model, please check out the [Release -Model](/release) page. +For more information about Bazel's release model, please check out the [Release Model](/release) page. ## Summary {#summary} @@ -61,8 +59,7 @@ available. ## Communicating incompatible changes {#communicating-incompatible-changes} The primary source of information about incompatible changes are GitHub issues -marked with an ["incompatible-change" -label](https://github.com/bazelbuild/bazel/issues?q=label%3Aincompatible-change). +marked with an ["incompatible-change" label](https://github.com/bazelbuild/bazel/issues?q=label%3Aincompatible-change). For every incompatible change, the issue specifies the following: diff --git a/release/index.mdx b/release/index.mdx index 0f68efe0..822c08f5 100644 --- a/release/index.mdx +++ b/release/index.mdx @@ -4,8 +4,7 @@ title: 'Release Model' -As announced in [the original blog -post](https://blog.bazel.build/2020/11/10/long-term-support-release.html), Bazel +As announced in [the original blog post](https://blog.bazel.build/2020/11/10/long-term-support-release.html), Bazel 4.0 and higher versions provides support for two release tracks: rolling releases and long term support (LTS) releases. This page covers the latest information about Bazel's release model. @@ -22,13 +21,11 @@ information about Bazel's release model. | Bazel 5 | Deprecated | [5.4.1](https://github.com/bazelbuild/bazel/releases/tag/5.4.1) | Jan 2025 | | Bazel 4 | Deprecated | [4.2.4](https://github.com/bazelbuild/bazel/releases/tag/4.2.4) | Jan 2024 | -All Bazel LTS releases can be found on the [release -page](https://github.com/bazelbuild/bazel/releases) on GitHub. +All Bazel LTS releases can be found on the [release page](https://github.com/bazelbuild/bazel/releases) on GitHub. ## Release versioning {#bazel-versioning} -Bazel uses a _major.minor.patch_ [Semantic -Versioning](https://semver.org/) scheme. +Bazel uses a _major.minor.patch_ [Semantic Versioning](https://semver.org/) scheme. * A _major release_ contains features that are not backward compatible with the previous release. Each major Bazel version is an LTS release. @@ -71,8 +68,7 @@ Bazel regularly publish releases for two release tracks. release. * Rolling releases can ship incompatible changes. Incompatible flags are recommended for major breaking changes, rolling out incompatible changes - should follow our [backward compatibility - policy](/release/backward-compatibility). + should follow our [backward compatibility policy](/release/backward-compatibility). ### LTS releases {#lts-releases} @@ -88,8 +84,7 @@ Bazel regularly publish releases for two release tracks. * A Bazel LTS release enters the Deprecated stage after being in ​​the Maintenance stage for 2 years. -For planned releases, please check our [release -issues](https://github.com/bazelbuild/bazel/issues?q=is%3Aopen+is%3Aissue+label%3Arelease) +For planned releases, please check our [release issues](https://github.com/bazelbuild/bazel/issues?q=is%3Aopen+is%3Aissue+label%3Arelease) on Github. ## Release procedure & policies {#release-procedure-policies} @@ -152,8 +147,7 @@ For LTS releases, the procedure and policies below are followed: 1. Identify release blockers and fix issues found on the release branch. * The release branch is tested with the same test suite in [postsubmit](https://buildkite.com/bazel/bazel-bazel) and - [downstream test pipeline] - (https://buildkite.com/bazel/bazel-at-head-plus-downstream) + [downstream test pipeline](https://buildkite.com/bazel/bazel-at-head-plus-downstream) on Bazel CI. The Bazel team monitors testing results of the release branch and fixes any regressions found. 1. Create a new release candidate from the release branch when all known @@ -209,5 +203,4 @@ feature. ## Rule compatibility {#rule-compatibility} If you are a rule authors and want to maintain compatibility with different -Bazel versions, please check out the [Rule -Compatibility](/release/rule-compatibility) page. +Bazel versions, please check out the [Rule Compatibility](/release/rule-compatibility) page. diff --git a/release/rule-compatibility.mdx b/release/rule-compatibility.mdx index 2a00588d..78d79dc1 100644 --- a/release/rule-compatibility.mdx +++ b/release/rule-compatibility.mdx @@ -55,18 +55,15 @@ Bazel LTS release. As Bazel rules authors, you can ensure a manageable migration process for users by following these best practices: -1. The rule should follow [Semantic - Versioning](https://semver.org/): minor versions of the same +1. The rule should follow [Semantic Versioning](https://semver.org/): minor versions of the same major version are backward compatible. 1. The rule at HEAD should be compatible with the latest Bazel LTS release. 1. The rule at HEAD should be compatible with Bazel at HEAD. To achieve this, you can * Set up your own CI testing with Bazel at HEAD - * Add your project to [Bazel downstream - testing](https://github.com/bazelbuild/continuous-integration/blob/master/docs/downstream-testing.md); + * Add your project to [Bazel downstream testing](https://github.com/bazelbuild/continuous-integration/blob/master/docs/downstream-testing.md); the Bazel team files issues to your project if breaking changes in Bazel - affect your project, and you must follow our [downstream project - policies](https://github.com/bazelbuild/continuous-integration/blob/master/docs/downstream-testing.md#downstream-project-policies) + affect your project, and you must follow our [downstream project policies](https://github.com/bazelbuild/continuous-integration/blob/master/docs/downstream-testing.md#downstream-project-policies) to address issues timely. 1. The latest major version of the rule must be compatible with the latest Bazel LTS release. diff --git a/remote/bep-glossary.mdx b/remote/bep-glossary.mdx index d40d13f9..80739e51 100644 --- a/remote/bep-glossary.mdx +++ b/remote/bep-glossary.mdx @@ -38,7 +38,7 @@ BEP contains an event like the following: ## ActionExecuted {#actionexecuted} Provides details about the execution of a specific -[Action](/rules/lib/actions) in a build. By default, this event is +[Action](/rules/lib/builtins/actions) in a build. By default, this event is included in the BEP only for failed actions, to support identifying the root cause of build failures. Users may set the `--build_event_publish_all_actions` flag to include all `ActionExecuted` events. @@ -412,5 +412,4 @@ workspace, such as the execution root. ## WorkspaceStatus {#workspacestatus} -A single `WorkspaceStatus` event contains the result of the [workspace status -command](/docs/user-manual#workspace-status). +A single `WorkspaceStatus` event contains the result of the [workspace status command](/docs/user-manual#workspace-status). diff --git a/remote/bep.mdx b/remote/bep.mdx index 2cfa555f..08ac72d2 100644 --- a/remote/bep.mdx +++ b/remote/bep.mdx @@ -4,14 +4,12 @@ title: 'Build Event Protocol' -The [Build Event -Protocol](https://github.com/bazelbuild/bazel/blob/master/src/main/java/com/google/devtools/build/lib/buildeventstream/proto/build_event_stream.proto) +The [Build Event Protocol](https://github.com/bazelbuild/bazel/blob/master/src/main/java/com/google/devtools/build/lib/buildeventstream/proto/build_event_stream.proto) (BEP) allows third-party programs to gain insight into a Bazel invocation. For example, you could use the BEP to gather information for an IDE plugin or a dashboard that displays build results. -The protocol is a set of [protocol -buffer](https://developers.google.com/protocol-buffers/) messages with some +The protocol is a set of [protocol buffer](https://developers.google.com/protocol-buffers/) messages with some semantics defined on top of it. It includes information about build and test results, build progress, the build configuration and much more. The BEP is intended to be consumed programmatically and makes parsing Bazel’s @@ -22,16 +20,13 @@ build event is a protocol buffer message consisting of a build event identifier, a set of child event identifiers, and a payload. * __Build Event Identifier:__ Depending on the kind of build event, it might be -an [opaque -string](https://github.com/bazelbuild/bazel/blob/7.1.0/src/main/java/com/google/devtools/build/lib/buildeventstream/proto/build_event_stream.proto#L131-L140) -or [structured -information](https://github.com/bazelbuild/bazel/blob/7.1.0/src/main/java/com/google/devtools/build/lib/buildeventstream/proto/build_event_stream.proto#L194-L205) +an [opaque string](https://github.com/bazelbuild/bazel/blob/7.1.0/src/main/java/com/google/devtools/build/lib/buildeventstream/proto/build_event_stream.proto#L131-L140) +or [structured information](https://github.com/bazelbuild/bazel/blob/7.1.0/src/main/java/com/google/devtools/build/lib/buildeventstream/proto/build_event_stream.proto#L194-L205) revealing more about the build event. A build event identifier is unique within a build. * __Children:__ A build event may announce other build events, by including -their build event identifiers in its [children -field](https://github.com/bazelbuild/bazel/blob/7.1.0/src/main/java/com/google/devtools/build/lib/buildeventstream/proto/build_event_stream.proto#L1276). +their build event identifiers in its [children field](https://github.com/bazelbuild/bazel/blob/7.1.0/src/main/java/com/google/devtools/build/lib/buildeventstream/proto/build_event_stream.proto#L1276). For example, the `PatternExpanded` build event announces the targets it expands to as children. The protocol guarantees that all events, except for the first event, are announced by a previous event. @@ -93,8 +88,7 @@ human-readable formats, such as text and JSON: ## Build Event Service {#build-event-service} -The [Build Event -Service](https://github.com/googleapis/googleapis/blob/master/google/devtools/build/v1/publish_build_event.proto) +The [Build Event Service](https://github.com/googleapis/googleapis/blob/master/google/devtools/build/v1/publish_build_event.proto) Protocol is a generic [gRPC](https://www.grpc.io) service for publishing build events. The Build Event Service protocol is independent of the BEP and treats BEP events as opaque bytes. Bazel ships with a gRPC client implementation of the Build Event Service protocol that @@ -138,8 +132,7 @@ For a description of each of these flags, see the The BEP typically contains many references to log files (test.log, test.xml, etc. ) stored on the machine where Bazel is running. A remote BES server typically can't access these files as they are on different machines. A way to -work around this issue is to use Bazel with [remote -caching](/remote/caching). +work around this issue is to use Bazel with [remote caching](/remote/caching). Bazel will upload all output files to the remote cache (including files referenced in the BEP) and the BES server can then fetch the referenced files from the cache. diff --git a/remote/cache-local.mdx b/remote/cache-local.mdx index 7cb59a6a..ac81188e 100644 --- a/remote/cache-local.mdx +++ b/remote/cache-local.mdx @@ -20,8 +20,7 @@ execution. However, local execution presents some additional challenges. ## Checking your cache hit rate {#cache-hits} Successful remote cache hits will show up in the status line, similar to -[Cache Hits rate with Remote -Execution](/remote/cache-remote#check-cache-hits). +[Cache Hits rate with Remote Execution](/remote/cache-remote#check-cache-hits). In the standard output of your Bazel run, you will see something like the following: @@ -70,8 +69,7 @@ the steps in this section. message you see does not give you enough information, try adding `--verbose_failures`. -2. Follow the steps from [Troubleshooting cache hits for remote - execution](/remote/cache-remote#troubleshooting_cache_hits) to +2. Follow the steps from [Troubleshooting cache hits for remote execution](/remote/cache-remote#troubleshooting_cache_hits) to ensure that your cache-writing Bazel invocations are able to get cache hits on the same machine and across machines. @@ -85,7 +83,6 @@ the steps in this section. b. Ensure your cache-reading Bazel invocations build the same targets as the cache-writing Bazel invocations. - c. Follow the same steps as to [ensure caching across - machines](/remote/cache-remote#caching-across-machines), + c. Follow the same steps as to [ensure caching across machines](/remote/cache-remote#caching-across-machines), to ensure caching from your cache-writing Bazel invocation to your cache-reading Bazel invocation. diff --git a/remote/caching.mdx b/remote/caching.mdx index 09774d21..97a1ba88 100644 --- a/remote/caching.mdx +++ b/remote/caching.mdx @@ -129,7 +129,7 @@ not provide technical support for bazel-remote. This cache stores contents on disk and also provides garbage collection to enforce an upper storage limit and clean unused artifacts. The cache is -available as a [docker image] and its code is available on +available as a [docker image](https://hub.docker.com/r/buchgr/bazel-remote-cache/) and its code is available on [GitHub](https://github.com/buchgr/bazel-remote/). Both the REST and gRPC remote cache APIs are supported. @@ -316,8 +316,7 @@ or for the age of individual cache entries. Bazel will automatically garbage collect the disk cache while idling between builds; the idle timer can be set with `--experimental_disk_cache_gc_idle_delay` (defaulting to 5 minutes). -As an alternative to automatic garbage collection, we also provide a [tool]( -https://github.com/bazelbuild/bazel/tree/master/src/tools/diskcache) to run a +As an alternative to automatic garbage collection, we also provide a [tool](https://github.com/bazelbuild/bazel/tree/master/src/tools/diskcache) to run a garbage collection on demand. ## Known issues {#known-issues} diff --git a/remote/dynamic.mdx b/remote/dynamic.mdx index e954e0d6..c30afa0b 100644 --- a/remote/dynamic.mdx +++ b/remote/dynamic.mdx @@ -12,8 +12,7 @@ alike. This page describes how to enable, tune, and debug dynamic execution. If you have both local and remote execution set up and are trying to adjust Bazel settings for better performance, this page is for you. If you don't already have -remote execution set up, go to the Bazel [Remote Execution -Overview](/remote/rbe) first. +remote execution set up, go to the Bazel [Remote Execution Overview](/remote/rbe) first. ## Enabling dynamic execution? {#enabling-dynamic-execution} @@ -44,14 +43,12 @@ are likely. The default value is 1000ms, but should be tuned to being just a bit longer than cache hits usually take. The actual time depends both on the remote system and on how long a round-trip takes. Usually, the value will be the same for all users of a given remote system, unless some of them are far enough away -to add roundtrip latency. You can use the [Bazel profiling -features](/rules/performance#performance-profiling) to look at how long typical +to add roundtrip latency. You can use the [Bazel profiling features](/rules/performance#performance-profiling) to look at how long typical cache hits take. Dynamic execution can be used with local sandboxed strategy as well as with [persistent workers](/remote/persistent). Persistent workers will automatically -run with sandboxing when used with dynamic execution, and cannot use [multiplex -workers](/remote/multiplex). On Darwin and Windows systems, the sandboxed +run with sandboxing when used with dynamic execution, and cannot use [multiplex workers](/remote/multiplex). On Darwin and Windows systems, the sandboxed strategy can be slow; you can pass `--reuse_sandbox_directories` to reduce overhead of creating sandboxes on these systems. @@ -67,8 +64,7 @@ entire action fails. This is an intentional choice to prevent differences between local and remote execution from going unnoticed. For more background on how dynamic execution and its locking works, see Julio -Merino's excellent [blog -posts](https://jmmv.dev/series/bazel-dynamic-execution/) +Merino's excellent [blog posts](https://jmmv.dev/series/bazel-dynamic-execution/) ## When should I use dynamic execution? {#when-to-use} diff --git a/remote/output-directories.mdx b/remote/output-directories.mdx index c6683792..36710825 100644 --- a/remote/output-directories.mdx +++ b/remote/output-directories.mdx @@ -27,7 +27,7 @@ The solution that's currently implemented: * Bazel must be invoked from a directory containing a repository boundary file, or a subdirectory thereof. In other words, Bazel must be invoked from inside a - [repository](../external/overview#repository). Otherwise, an error is + [repository](/external/overview#repository). Otherwise, an error is reported. * The _outputRoot_ directory defaults to ~/.cache/bazel on Linux, `~/Library/Caches/bazel` on macOS (when using Bazel 9 and newer), diff --git a/remote/persistent.mdx b/remote/persistent.mdx index 3a7dbee0..c0e7f1da 100644 --- a/remote/persistent.mdx +++ b/remote/persistent.mdx @@ -262,7 +262,6 @@ For more information on persistent workers, see: * [Original persistent workers blog post](https://blog.bazel.build/2015/12/10/java-workers.html) * [Haskell implementation description](https://www.tweag.io/blog/2019-09-25-bazel-ghc-persistent-worker-internship/) * [Blog post by Mike Morearty](https://medium.com/@mmorearty/how-to-create-a-persistent-worker-for-bazel-7738bba2cabb) -* [Front End Development with Bazel: Angular/TypeScript and Persistent Workers - w/ Asana](https://www.youtube.com/watch?v=0pgERydGyqo) +* [Front End Development with Bazel: Angular/TypeScript and Persistent Workers w/ Asana](https://www.youtube.com/watch?v=0pgERydGyqo) * [Bazel strategies explained](https://jmmv.dev/2019/12/bazel-strategies.html) * [Informative worker strategy discussion on the bazel-discuss mailing list](https://groups.google.com/forum/#!msg/bazel-discuss/oAEnuhYOPm8/ol7hf4KWJgAJ) diff --git a/remote/rules.mdx b/remote/rules.mdx index adc445a9..e5da6a8f 100644 --- a/remote/rules.mdx +++ b/remote/rules.mdx @@ -56,8 +56,7 @@ variables that may not be set to equivalent values (or at all) in the remote execution environment. Toolchain rules currently exist for Bazel build and test rules for -[Scala](https://github.com/bazelbuild/rules_scala/blob/master/scala/scala_toolch -ain.bzl), +[Scala](https://github.com/bazelbuild/rules_scala/blob/master/scala/scala_toolch ain.bzl), [Rust](https://github.com/bazelbuild/rules_rust/blob/main/rust/toolchain.bzl), and [Go](https://github.com/bazelbuild/rules_go/blob/master/go/toolchains.rst), and new toolchain rules are under way for other languages and tools such as diff --git a/remote/workspace.mdx b/remote/workspace.mdx index c2581b27..4cba551c 100644 --- a/remote/workspace.mdx +++ b/remote/workspace.mdx @@ -13,8 +13,7 @@ on the host machine. If your workspace rules access information about the host machine for use during execution, your build is likely to break due to incompatibilities between the environments. -As part of [adapting Bazel rules for remote -execution](/remote/rules), you need to find such workspace rules +As part of [adapting Bazel rules for remote execution](/remote/rules), you need to find such workspace rules and fix them. This page describes how to find potentially problematic workspace rules using the workspace log. diff --git a/rules/challenges.mdx b/rules/challenges.mdx index 06727ddb..7169fbc9 100644 --- a/rules/challenges.mdx +++ b/rules/challenges.mdx @@ -210,7 +210,7 @@ Bazel is heavily affected by both of these scenarios, so we introduced a set of custom collection classes that effectively compress the information in memory by avoiding the copy at each step. Almost all of these data structures have set semantics, so we called it -[depset](/rules/lib/depset) +[depset](/rules/lib/builtins/depset) (also known as `NestedSet` in the internal implementation). The majority of changes to reduce Bazel's memory consumption over the past several years were changes to use depsets instead of whatever was previously used. diff --git a/rules/faq.mdx b/rules/faq.mdx index 5321f0b7..d36139e9 100644 --- a/rules/faq.mdx +++ b/rules/faq.mdx @@ -19,7 +19,7 @@ Bazel only executes the actions needed to produce the *requested* output files. * If you want the file to be built automatically whenever your target is mentioned on the command line, add it to your rule's default outputs by - returning a [`DefaultInfo`](lib/globals#DefaultInfo) provider. + returning a [`DefaultInfo`](/rules/lib/globals#DefaultInfo) provider. See the [Rules page](/extending/rules#requesting-output-files) for more information. @@ -37,24 +37,24 @@ correct path. For actions, you declare inputs by passing them to the `ctx.actions.*` function that creates the action. The proper path for the file can be obtained using -[`File.path`](lib/File#path). +[`File.path`](/rules/lib/builtins/File#path). For binaries (the executable outputs run by a `bazel run` or `bazel test` command), you declare inputs by including them in the [runfiles](/extending/rules#runfiles). Instead of using the `path` field, use -[`File.short_path`](lib/File#short_path), which is file's path relative to +[`File.short_path`](/rules/lib/builtins/File#short_path), which is file's path relative to the runfiles directory in which the binary executes. ## How can I control which files are built by `bazel build //pkg:mytarget`? -Use the [`DefaultInfo`](lib/globals#DefaultInfo) provider to +Use the [`DefaultInfo`](/rules/lib/globals#DefaultInfo) provider to [set the default outputs](/extending/rules#requesting-output-files). ## How can I run a program or do file I/O as part of my build? A tool can be declared as a target, just like any other part of your build, and run during the execution phase to help build other targets. To create an action -that runs a tool, use [`ctx.actions.run`](lib/actions#run) and pass in the +that runs a tool, use [`ctx.actions.run`](/rules/lib/builtins/actions#run) and pass in the tool as the `executable` parameter. During the loading and analysis phases, a tool *cannot* run, nor can you perform diff --git a/rules/language.mdx b/rules/language.mdx index a95dd7bf..a29111d8 100644 --- a/rules/language.mdx +++ b/rules/language.mdx @@ -36,14 +36,14 @@ Starlark's semantics can differ from Python, but behavioral differences are rare, except for cases where Starlark raises an error. The following Python types are supported: -* [None](lib/globals#None) -* [bool](lib/bool) -* [dict](lib/dict) -* [tuple](lib/tuple) -* [function](lib/function) -* [int](lib/int) -* [list](lib/list) -* [string](lib/string) +* [None](/rules/lib/globals#None) +* [bool](/rules/lib/core/bool) +* [dict](/rules/lib/core/dict) +* [tuple](/rules/lib/core/tuple) +* [function](/rules/lib/core/function) +* [int](/rules/lib/core/int) +* [list](/rules/lib/core/list) +* [string](/rules/lib/core/string) ## Type annotations {#StarlarkTypes} @@ -62,7 +62,7 @@ with a syntax inspired by [PEP 484](https://peps.python.org/pep-0484/). ## Mutability Starlark favors immutability. Two mutable data structures are available: -[lists](lib/list) and [dicts](lib/dict). Changes to mutable +[lists](/rules/lib/core/list) and [dicts](/rules/lib/core/dict). Changes to mutable data-structures, such as appending a value to a list or deleting an entry in a dictionary are valid only for objects created in the current context. After a context finishes, its values become immutable. @@ -109,10 +109,8 @@ values returned by rules are immutable. `BUILD` files register targets via making calls to rules. `.bzl` files provide definitions for constants, rules, macros, and functions. -[Native functions](/reference/be/functions) and [native rules]( -/reference/be/overview#language-specific-native-rules) are global symbols in -`BUILD` files. `bzl` files need to load them using the [`native` module]( -/rules/lib/toplevel/native). +[Native functions](/reference/be/functions) and [native rules](/reference/be/overview#language-specific-native-rules) are global symbols in +`BUILD` files. `bzl` files need to load them using the [`native` module](/rules/lib/toplevel/native). There are two syntactic restrictions in `BUILD` files: 1) declaring functions is illegal, and 2) `*args` and `**kwargs` arguments are not allowed. @@ -146,7 +144,7 @@ not defined across value types. In short: `5 < 'foo'` will throw an error and error: `{"a": 4, "b": 7, "a": 1}`. * Strings are represented with double-quotes (such as when you call - [repr](lib/globals#repr)). + [repr](/rules/lib/globals#repr)). * Strings aren't iterable. @@ -154,12 +152,12 @@ The following Python features are not supported: * implicit string concatenation (use explicit `+` operator). * Chained comparisons (such as `1 < x < 5`). -* `class` (see [`struct`](lib/struct#struct) function). +* `class` (see [`struct`](/rules/lib/builtins/struct#struct) function). * `import` (see [`load`](/extending/concepts#loading-an-extension) statement). * `while`, `yield`. * float and set types. * generators and generator expressions. * `is` (use `==` instead). -* `try`, `raise`, `except`, `finally` (see [`fail`](lib/globals#fail) for fatal errors). +* `try`, `raise`, `except`, `finally` (see [`fail`](/rules/lib/globals#fail) for fatal errors). * `global`, `nonlocal`. * most builtin functions, most methods. diff --git a/rules/legacy-macro-tutorial.mdx b/rules/legacy-macro-tutorial.mdx index 28b0fca8..991c7809 100644 --- a/rules/legacy-macro-tutorial.mdx +++ b/rules/legacy-macro-tutorial.mdx @@ -5,9 +5,7 @@ title: 'Creating a Legacy Macro' IMPORTANT: This tutorial is for [*legacy macros*](/extending/legacy-macros). If -you only need to support Bazel 8 or newer, we recommend using [symbolic -macros](/extending/macros) instead; take a look at [Creating a Symbolic -Macro](macro-tutorial). +you only need to support Bazel 8 or newer, we recommend using [symbolic macros](/extending/macros) instead; take a look at [Creating a Symbolic Macro](/rules/macro-tutorial). Imagine that you need to run a tool as part of your build. For example, you may want to generate or preprocess a source file, or compress a binary. In this diff --git a/rules/macro-tutorial.mdx b/rules/macro-tutorial.mdx index 2b3d8e4a..b74c34bb 100644 --- a/rules/macro-tutorial.mdx +++ b/rules/macro-tutorial.mdx @@ -7,7 +7,7 @@ title: 'Creating a Symbolic Macro' IMPORTANT: This tutorial is for [*symbolic macros*](/extending/macros) – the new macro system introduced in Bazel 8. If you need to support older Bazel versions, you will want to write a [legacy macro](/extending/legacy-macros) instead; take -a look at [Creating a Legacy Macro](legacy-macro-tutorial). +a look at [Creating a Legacy Macro](/rules/legacy-macro-tutorial). Imagine that you need to run a tool as part of your build. For example, you may want to generate or preprocess a source file, or compress a binary. In this diff --git a/rules/performance.mdx b/rules/performance.mdx index e518273b..2fc3568f 100644 --- a/rules/performance.mdx +++ b/rules/performance.mdx @@ -17,7 +17,7 @@ widespread use. ## Use depsets {#use-depsets} Whenever you are rolling up information from rule dependencies you should use -[depsets](lib/depset). Only use plain lists or dicts to publish information +[depsets](/rules/lib/builtins/depset). Only use plain lists or dicts to publish information local to the current rule. A depset represents information as a nested graph which enables sharing. @@ -75,7 +75,7 @@ See the [depset overview](/extending/depsets) page for more information. ### Avoid calling `depset.to_list()` {#avoid-depset-to-list} You can coerce a depset to a flat list using -[`to_list()`](lib/depset#to_list), but doing so usually results in O(N^2) +[`to_list()`](/rules/lib/builtins/depset#to_list), but doing so usually results in O(N^2) cost. If at all possible, avoid any flattening of depsets except for debugging purposes. @@ -117,7 +117,7 @@ x = depset(transitive = [i.deps for i in inputs]) ## Use ctx.actions.args() for command lines {#ctx-actions-args} -When building command lines you should use [ctx.actions.args()](lib/Args). +When building command lines you should use [ctx.actions.args()](/rules/lib/builtins/Args). This defers expansion of any depsets to the execution phase. Apart from being strictly faster, this will reduce the memory consumption of @@ -128,11 +128,11 @@ Here are some tricks: * Pass depsets and lists directly as arguments, instead of flattening them yourself. They will get expanded by `ctx.actions.args()` for you. If you need any transformations on the depset contents, look at -[ctx.actions.args#add](lib/Args#add) to see if anything fits the bill. +[ctx.actions.args#add](/rules/lib/builtins/Args#add) to see if anything fits the bill. * Are you passing `File#path` as arguments? No need. Any -[File](lib/File) is automatically turned into its -[path](lib/File#path), deferred to expansion time. +[File](/rules/lib/builtins/File) is automatically turned into its +[path](/rules/lib/builtins/File#path), deferred to expansion time. * Avoid constructing strings by concatenating them together. The best string argument is a constant as its memory will be shared between @@ -140,10 +140,10 @@ all instances of your rule. * If the args are too long for the command line an `ctx.actions.args()` object can be conditionally or unconditionally written to a param file using -[`ctx.actions.args#use_param_file`](lib/Args#use_param_file). This is +[`ctx.actions.args#use_param_file`](/rules/lib/builtins/Args#use_param_file). This is done behind the scenes when the action is executed. If you need to explicitly control the params file you can write it manually using -[`ctx.actions.write`](lib/actions#write). +[`ctx.actions.write`](/rules/lib/builtins/actions#write). Example: @@ -178,7 +178,7 @@ def _to_short_path(f): ## Transitive action inputs should be depsets {#transitive-action-inputs} -When building an action using [ctx.actions.run](lib/actions?#run), do not +When building an action using [ctx.actions.run](/rules/lib/builtins/actions#run), do not forget that the `inputs` field accepts a depset. Use this whenever inputs are collected from dependencies transitively. diff --git a/rules/rules-tutorial.mdx b/rules/rules-tutorial.mdx index 56a3ad43..8510a81c 100644 --- a/rules/rules-tutorial.mdx +++ b/rules/rules-tutorial.mdx @@ -33,9 +33,9 @@ foo_binary = rule( ) ``` -When you call the [`rule`](lib/globals/bzl#rule) function, you +When you call the [`rule`](/rules/lib/globals/bzl#rule) function, you must define a callback function. The logic will go there, but you -can leave the function empty for now. The [`ctx`](lib/ctx) argument +can leave the function empty for now. The [`ctx`](/rules/lib/builtins/ctx) argument provides information about the target. You can load the rule and use it from a `BUILD` file. @@ -88,10 +88,10 @@ foo_binary(name = "bin1") foo_binary(name = "bin2") ``` -[`ctx.label`](lib/ctx#label) +[`ctx.label`](/rules/lib/builtins/ctx#label) corresponds to the label of the target being analyzed. The `ctx` object has many useful fields and methods; you can find an exhaustive list in the -[API reference](lib/ctx). +[API reference](/rules/lib/builtins/ctx). Query the code: @@ -147,7 +147,7 @@ bin2 ``` Whenever you declare a file, you have to tell Bazel how to generate it by -creating an action. Use [`ctx.actions.write`](lib/actions#write), +creating an action. Use [`ctx.actions.write`](/rules/lib/builtins/actions#write), to create a file with the given content. ```python @@ -202,7 +202,7 @@ You have successfully generated a file! ## Attributes To make the rule more useful, add new attributes using -[the `attr` module](lib/attr) and update the rule definition. +[the `attr` module](/rules/lib/toplevel/attr) and update the rule definition. Add a string attribute called `username`: @@ -238,22 +238,22 @@ def _foo_binary_impl(ctx): ``` Note that you can make the attribute mandatory or set a default value. Look at -the documentation of [`attr.string`](lib/attr#string). -You may also use other types of attributes, such as [boolean](lib/attr#bool) -or [list of integers](lib/attr#int_list). +the documentation of [`attr.string`](/rules/lib/toplevel/attr#string). +You may also use other types of attributes, such as [boolean](/rules/lib/toplevel/attr#bool) +or [list of integers](/rules/lib/toplevel/attr#int_list). ## Dependencies -Dependency attributes, such as [`attr.label`](lib/attr#label) -and [`attr.label_list`](lib/attr#label_list), +Dependency attributes, such as [`attr.label`](/rules/lib/toplevel/attr#label) +and [`attr.label_list`](/rules/lib/toplevel/attr#label_list), declare a dependency from the target that owns the attribute to the target whose label appears in the attribute's value. This kind of attribute forms the basis of the target graph. In the `BUILD` file, the target label appears as a string object, such as `//pkg:name`. In the implementation function, the target will be accessible as a -[`Target`](lib/Target) object. For example, view the files returned -by the target using [`Target.files`](lib/Target#modules.Target.files). +[`Target`](/rules/lib/builtins/Target) object. For example, view the files returned +by the target using [`Target.files`](/rules/lib/builtins/Target#modules.Target.files). ### Multiple files @@ -296,7 +296,7 @@ implementation function, but this has two problems. First, as the template gets bigger, it becomes more memory efficient to put it in a separate file and avoid constructing large strings during the analysis phase. Second, using a separate file is more convenient for the user. Instead, use -[`ctx.actions.expand_template`](lib/actions#expand_template), +[`ctx.actions.expand_template`](/rules/lib/builtins/actions#expand_template), which performs substitutions on a template file. Create a `template` attribute to declare a dependency on the template diff --git a/rules/testing.mdx b/rules/testing.mdx index 17120dd4..4642c9ea 100644 --- a/rules/testing.mdx +++ b/rules/testing.mdx @@ -237,7 +237,7 @@ def _inspect_actions_test_impl(ctx): ``` Note that `analysistest.target_actions(env)` returns a list of -[`Action`](lib/Action) objects which represent actions registered by the +[`Action`](/rules/lib/builtins/Action) objects which represent actions registered by the target under test. ### Verifying rule behavior under different flags {#verifying-rule-behavior} diff --git a/rules/verbs-tutorial.mdx b/rules/verbs-tutorial.mdx index db7757e1..df2b1fab 100644 --- a/rules/verbs-tutorial.mdx +++ b/rules/verbs-tutorial.mdx @@ -51,8 +51,7 @@ This pattern can also be seen in the Angular project. The produces two targets. The first is a standard `nodejs_test` target which compares some generated output against a "golden" file (that is, a file containing the expected output). This can be built and run with a normal `bazel -test` invocation. In `angular-cli`, you can run [one such -target](https://github.com/angular/angular-cli/blob/e1269cb520871ee29b1a4eec6e6c0e4a94f0b5fc/etc/api/BUILD) +test` invocation. In `angular-cli`, you can run [one such target](https://github.com/angular/angular-cli/blob/e1269cb520871ee29b1a4eec6e6c0e4a94f0b5fc/etc/api/BUILD) with `bazel test //etc/api:angular_devkit_core_api`. Over time, this golden file may need to be updated for legitimate reasons. @@ -161,7 +160,7 @@ an imaginary `bazel publish` command. It's not immediately obvious what the implementation of the `_sphinx_publisher` rule might look like. Often, actions like this write a _launcher_ shell script. This method typically involves using -[`ctx.actions.expand_template`](lib/actions#expand_template) +[`ctx.actions.expand_template`](/rules/lib/builtins/actions#expand_template) to write a very simple shell script, in this case invoking the publisher binary with a path to the output of the primary target. This way, the publisher implementation can remain generic, the `_sphinx_site` rule can just produce diff --git a/run/build.mdx b/run/build.mdx index a8eadc57..2f3e4825 100644 --- a/run/build.mdx +++ b/run/build.mdx @@ -633,8 +633,7 @@ Note: Hermeticity means that the action only uses its declared input files and no other files in the filesystem, and it only produces its declared output files. See [Hermeticity](/basics/hermeticity) for more details. -On some platforms such as [Google Kubernetes -Engine](https://cloud.google.com/kubernetes-engine/) cluster nodes or Debian, +On some platforms such as [Google Kubernetes Engine](https://cloud.google.com/kubernetes-engine/) cluster nodes or Debian, user namespaces are deactivated by default due to security concerns. This can be checked by looking at the file `/proc/sys/kernel/unprivileged_userns_clone`: if it exists and contains a 0, diff --git a/start/android-app.mdx b/start/android-app.mdx index 35da5828..f4ae1830 100644 --- a/start/android-app.mdx +++ b/start/android-app.mdx @@ -40,8 +40,7 @@ In this tutorial you learn how to: Before you begin the tutorial, install the following software: * **Bazel.** To install, follow the [installation instructions](/install). -* **Android Studio.** To install, follow the steps to [download Android - Studio](https://developer.android.com/sdk/index.html). +* **Android Studio.** To install, follow the steps to [download Android Studio](https://developer.android.com/sdk/index.html). Execute the setup wizard to download the SDK and configure your environment. * (Optional) **Git.** Use `git` to download the Android app project. @@ -56,8 +55,7 @@ This app has a single button that prints a greeting when clicked: **Figure 1.** Android app button greeting. -Clone the repository with `git` (or [download the ZIP file -directly](https://github.com/bazelbuild/examples/archive/master.zip)): +Clone the repository with `git` (or [download the ZIP file directly](https://github.com/bazelbuild/examples/archive/master.zip)): ```posix-terminal git clone https://github.com/bazelbuild/examples @@ -108,8 +106,7 @@ A [workspace](/concepts/build-ref#workspace) is a directory that contains the source files for one or more software projects, and has a `MODULE.bazel` file at its root. -The `MODULE.bazel` file may be empty or may contain references to [external -dependencies](/external/overview) required to build your project. +The `MODULE.bazel` file may be empty or may contain references to [external dependencies](/external/overview) required to build your project. First, run the following command to create an empty `MODULE.bazel` file: @@ -160,8 +157,7 @@ environment variable, and automatically detect the highest API level and the latest version of build tools installed within that location. You can set the `ANDROID_HOME` variable to the location of the Android SDK. Find -the path to the installed SDK using Android Studio's [SDK -Manager](https://developer.android.com/studio/intro/update#sdk-manager). +the path to the installed SDK using Android Studio's [SDK Manager](https://developer.android.com/studio/intro/update#sdk-manager). Assuming the SDK is installed to default locations, you can use the following commands to set the `ANDROID_HOME` variable: @@ -184,8 +180,7 @@ them permanent, run the following commands: **Optional:** If you want to compile native code into your Android app, you -also need to download the [Android -NDK](https://developer.android.com/ndk/downloads/index.html) +also need to download the [Android NDK](https://developer.android.com/ndk/downloads/index.html) and use `rules_android_ndk` by adding the following line to your `MODULE.bazel` file: ```python @@ -193,8 +188,7 @@ bazel_dep(name = "rules_android_ndk", version = "0.1.3") ``` -For more information, read [Using the Android Native Development Kit with -Bazel](/docs/android-ndk). +For more information, read [Using the Android Native Development Kit with Bazel](/docs/android-ndk). It's not necessary to set the API levels to the same value for the SDK and NDK. [This page](https://developer.android.com/ndk/guides/stable_apis.html) @@ -236,8 +230,7 @@ files or other dependencies. Bazel provides two build rules, build an Android app. For this tutorial, you'll first use the -`android_library` rule to tell Bazel to build an [Android library -module](http://developer.android.com/tools/projects/index.html#LibraryProjects) +`android_library` rule to tell Bazel to build an [Android library module](http://developer.android.com/tools/projects/index.html#LibraryProjects) from the app source code and resource files. You'll then use the `android_binary` rule to tell Bazel how to build the Android application package. diff --git a/start/cpp.mdx b/start/cpp.mdx index 15cda325..c47d1484 100644 --- a/start/cpp.mdx +++ b/start/cpp.mdx @@ -21,8 +21,7 @@ Estimated completion time: 30 minutes. ### Prerequisites {#prerequisites} Start by [installing Bazel](https://bazel.build/install), if you haven't -already. This tutorial uses Git for source control, so for best results [install -Git](https://git-scm.com/book/en/v2/Getting-Started-Installing-Git) as well. +already. This tutorial uses Git for source control, so for best results [install Git](https://git-scm.com/book/en/v2/Getting-Started-Installing-Git) as well. Next, retrieve the sample project from Bazel's GitHub repository by running the following in your command-line tool of choice: @@ -65,9 +64,7 @@ examples ``` There are three sets of files, each set representing a stage in this tutorial. -In the first stage, you will build a single [target] -(https://bazel.build/reference/glossary#target) residing in a single [package] -(https://bazel.build/reference/glossary#package). In the second stage, you will +In the first stage, you will build a single [target](https://bazel.build/reference/glossary#target) residing in a single [package](https://bazel.build/reference/glossary#package). In the second stage, you will build both a binary and a library from a single package. In the third and final stage, you will build a project with multiple packages and build it with multiple targets. @@ -88,8 +85,7 @@ It also contains these significant files: * The `MODULE.bazel` file, which identifies the directory and its contents as a Bazel workspace and lives at the root of the project's directory structure. It's also where you specify your external dependencies. -* One or more [`BUILD` - files](https://bazel.build/reference/glossary#build-file), which tell Bazel +* One or more [`BUILD` files](https://bazel.build/reference/glossary#build-file), which tell Bazel how to build different parts of the project. A directory within the workspace that contains a `BUILD` file is a [package](https://bazel.build/reference/glossary#package). (More on packages @@ -184,9 +180,7 @@ This results in a printed "`Hello world`" message. Here's the dependency graph of Stage 1: -![Dependency graph for hello-world displays a single target with a single source -file.](/docs/images/cpp-tutorial-stage1.png "Dependency graph for hello-world -displays a single target with a single source file.") +![Dependency graph for hello-world displays a single target with a single source file.](/docs/images/cpp-tutorial-stage1.png "Dependency graph for hello-world displays a single target with a single source file.") ### Summary: stage 1 {#summary-stage-1} @@ -233,8 +227,7 @@ cc_binary( ``` With this `BUILD` file, Bazel first builds the `hello-greet` library (using -Bazel's built-in [`cc_library` -rule](https://bazel.build/reference/be/c-cpp#cc_library)), then the +Bazel's built-in [`cc_library` rule](https://bazel.build/reference/be/c-cpp#cc_library)), then the `hello-world` binary. The `deps` attribute in the `hello-world` target tells Bazel that the `hello-greet` library is required to build the `hello-world` binary. @@ -274,10 +267,7 @@ recompiles that file. Looking at the dependency graph, you can see that `hello-world` depends on an extra input named `hello-greet`: -![Dependency graph for `hello-world` displays dependency changes after -modification to the file.](/docs/images/cpp-tutorial-stage2.png "Dependency -graph for `hello-world` displays dependency changes after modification to the -file.") +![Dependency graph for `hello-world` displays dependency changes after modification to the file.](/docs/images/cpp-tutorial-stage2.png "Dependency graph for `hello-world` displays dependency changes after modification to the file.") ### Summary: stage 2 {#summary-stage-2} @@ -345,11 +335,7 @@ in the `lib` package (hence the target label `//lib:hello-time`) - Bazel knows this through the `deps` attribute. You can see this reflected in the dependency graph: -![Dependency graph for `hello-world` displays how the target in the main package -depends on the target in the `lib` -package.](/docs/images/cpp-tutorial-stage3.png "Dependency graph for -`hello-world` displays how the target in the main package depends on the target -in the `lib` package.") +![Dependency graph for `hello-world` displays how the target in the main package depends on the target in the `lib` package.](/docs/images/cpp-tutorial-stage3.png "Dependency graph for `hello-world` displays how the target in the main package depends on the target in the `lib` package.") For the build to succeed, you make the `//lib:hello-time` target in `lib/BUILD` explicitly visible to targets in `main/BUILD` using the visibility attribute. @@ -397,15 +383,11 @@ Bazel journey. You've now completed your first basic build with Bazel, but this is just the start. Here are some more resources to continue learning with Bazel: -* To keep focusing on C++, read about common [C++ build use - cases](https://bazel.build/tutorials/cpp-use-cases). +* To keep focusing on C++, read about common [C++ build use cases](https://bazel.build/tutorials/cpp-use-cases). * To get started with building other applications with Bazel, see the - tutorials for [Java](https://bazel.build/start/java), [Android - application](https://bazel.build/start/android-app), or [iOS - application](https://bazel.build/start/ios-app). + tutorials for [Java](https://bazel.build/start/java), [Android application](https://bazel.build/start/android-app), or [iOS application](https://bazel.build/start/ios-app). * To learn more about working with local and remote repositories, read about [external dependencies](https://bazel.build/docs/external). -* To learn more about Bazel's other rules, see this [reference - guide](https://bazel.build/rules). +* To learn more about Bazel's other rules, see this [reference guide](https://bazel.build/rules). Happy building! \ No newline at end of file diff --git a/start/go.mdx b/start/go.mdx index 5fb604c8..2ce0159e 100644 --- a/start/go.mdx +++ b/start/go.mdx @@ -34,8 +34,7 @@ You can check if Go is installed by running `go version` in any directory. ### Get the sample project {#get-sample} -The Bazel examples are stored in a Git repository, so you'll need to [install -Git](https://git-scm.com/book/en/v2/Getting-Started-Installing-Git) if you +The Bazel examples are stored in a Git repository, so you'll need to [install Git](https://git-scm.com/book/en/v2/Getting-Started-Installing-Git) if you haven't already. To download the examples repository, run this command: ```posix-terminal @@ -173,10 +172,8 @@ rule. Each rule defines [actions](https://bazel.build/reference/glossary#action) Go compile and link actions that produce an executable output file. Bazel has built-in rules for a few languages like Java and C++. You can find -their [documentation in the Build -Encyclopedia](https://bazel.build/reference/be/overview#rules). You can find -rule sets for many other languages and tools on the [Bazel Central Registry -(BCR)](https://registry.bazel.build/). +their [documentation in the Build Encyclopedia](https://bazel.build/reference/be/overview#rules). You can find +rule sets for many other languages and tools on the [Bazel Central Registry (BCR)](https://registry.bazel.build/). ## Add a library {#add-library} @@ -449,11 +446,9 @@ learned some core Bazel concepts along the way. languages. - For more information on Go, see the [rules_go](https://github.com/bazel-contrib/rules_go) module, especially the - [Core Go - rules](https://github.com/bazel-contrib/rules_go/blob/master/docs/go/core/rules.md) + [Core Go rules](https://github.com/bazel-contrib/rules_go/blob/master/docs/go/core/rules.md) documentation. - To learn more about working with Bazel modules outside your project, see [external dependencies](/docs/external). In particular, for information on how to depend on Go modules and toolchains through Bazel's module system, - see [Go with - bzlmod](https://github.com/bazel-contrib/rules_go/tree/master/docs/go/core/bzlmod.md). + see [Go with bzlmod](https://github.com/bazel-contrib/rules_go/tree/master/docs/go/core/bzlmod.md). diff --git a/start/java.mdx b/start/java.mdx index b892917d..be66ec16 100644 --- a/start/java.mdx +++ b/start/java.mdx @@ -243,8 +243,7 @@ recompiles that file. Looking at the dependency graph, you can see that `ProjectRunner` depends on the same inputs as it did before, but the structure of the build is different: -![Dependency graph of the target 'ProjectRunner' after adding a dependency]( -/docs/images/tutorial_java_02.svg) +![Dependency graph of the target 'ProjectRunner' after adding a dependency](/docs/images/tutorial_java_02.svg) You've now built the project with two targets. The `ProjectRunner` target builds one source files and depends on one other target (`:greeter`), which builds @@ -429,7 +428,7 @@ For more details, see: * The [C++ build tutorial](/start/cpp) to get started with building C++ projects with Bazel. -* The [Android application tutorial](/start/android-app ) and +* The [Android application tutorial](/start/android-app) and [iOS application tutorial](/start/ios-app)) to get started with building mobile applications for Android and iOS with Bazel. diff --git a/tutorials/ccp-toolchain-config.mdx b/tutorials/ccp-toolchain-config.mdx index 205f27f9..a4dd5829 100644 --- a/tutorials/ccp-toolchain-config.mdx +++ b/tutorials/ccp-toolchain-config.mdx @@ -31,8 +31,7 @@ uses `clang version 19`, which you can install on your system. Set up your build environment as follows: -1. If you have not already done so, [download and install Bazel - 7.0.2](https://bazel.build/install) or later. +1. If you have not already done so, [download and install Bazel 7.0.2](https://bazel.build/install) or later. 2. Add an empty `MODULE.bazel` file at the root folder. @@ -456,8 +455,7 @@ The key takeaways are: - You need to specify a matching `platforms` flag in the command line for Bazel to resolve to the toolchain for the same constraint values on the - platform. The documentation holds more [information about language specific - configuration flags](/concepts/platforms). + platform. The documentation holds more [information about language specific configuration flags](/concepts/platforms). - You have to let the toolchain know where the tools live. In this tutorial there is a simplified version where you access the tools from the system. If you are interested in a more self-contained approach, you can read about @@ -470,5 +468,4 @@ The key takeaways are: ## Further reading {#further-reading} -For more details, see [C++ toolchain -configuration](/docs/cc-toolchain-config-reference) +For more details, see [C++ toolchain configuration](/docs/cc-toolchain-config-reference) diff --git a/upstream b/upstream index de0d9098..78a12b5f 160000 --- a/upstream +++ b/upstream @@ -1 +1 @@ -Subproject commit de0d9098f358e8a7db798f4faf471f54b0737dc3 +Subproject commit 78a12b5f17e0947cffd4d2acf851f8aa7f65d84d diff --git a/versions/6.5.0/about/faq.mdx b/versions/6.5.0/about/faq.mdx index 41bf23f0..b05a1c9f 100644 --- a/versions/6.5.0/about/faq.mdx +++ b/versions/6.5.0/about/faq.mdx @@ -3,7 +3,7 @@ title: 'FAQ' --- -If you have questions or need support, see [Getting Help](/help). +If you have questions or need support, see [Getting Help](/versions/6.5.0/help). ## What is Bazel? @@ -13,7 +13,7 @@ Bazel is a tool that automates software builds and tests. Supported build tasks Bazel was designed to fit the way software is developed at Google. It has the following features: -* Multi-language support: Bazel supports [many languages](/reference/be/overview), and can be extended to support arbitrary programming languages. +* Multi-language support: Bazel supports [many languages](/versions/6.5.0/reference/be/overview), and can be extended to support arbitrary programming languages. * High-level build language: Projects are described in the `BUILD` language, a concise text format that describes a project as sets of small interconnected libraries, binaries and tests. In contrast, with tools like Make, you have to describe individual files and compiler invocations. * Multi-platform support: The same tool and the same `BUILD` files can be used to build software for different architectures, and even different platforms. At Google, we use Bazel to build everything from server applications running on systems in our data centers to client apps running on mobile phones. * Reproducibility: In `BUILD` files, each library, test and binary must specify its direct dependencies completely. Bazel uses this dependency information to know what must be rebuilt when you make changes to a source file, and which tasks can run in parallel. This means that all builds are incremental and will always produce the same result. @@ -41,7 +41,7 @@ A long time ago, Google built its software using large, generated Makefiles. The ## Does Bazel require a build cluster? -Bazel runs build operations locally by default. However, Bazel can also connect to a build cluster for even faster builds and tests. See our documentation on [remote execution and caching](/docs/remote-execution) and [remote caching](/docs/remote-caching) for further details. +Bazel runs build operations locally by default. However, Bazel can also connect to a build cluster for even faster builds and tests. See our documentation on [remote execution and caching](/versions/6.5.0/docs/remote-execution) and [remote caching](/versions/6.5.0/docs/remote-caching) for further details. ## How does the Google development process work? @@ -99,7 +99,7 @@ Porting to other UNIX platforms should be relatively easy, as long as a JDK is a The core features (C++, Java, and shell rules) have extensive use inside Google, so they are thoroughly tested and have very little churn. Similarly, we test new versions of Bazel across hundreds of thousands of targets every day to find regressions, and we release new versions multiple times every month. -In short, except for features marked as experimental, Bazel should Just Work. Changes to non-experimental rules will be backward compatible. A more detailed list of feature support statuses can be found in our [support document](/contribute/support). +In short, except for features marked as experimental, Bazel should Just Work. Changes to non-experimental rules will be backward compatible. A more detailed list of feature support statuses can be found in our [support document](/versions/6.5.0/contribute/support). ## How stable is Bazel as a binary? @@ -107,7 +107,7 @@ Inside Google, we make sure that Bazel crashes are very rare. This should also h ## How can I start using Bazel? -See [Getting Started](/start/). +See [Getting Started](/versions/6.5.0/start/). ## Doesn’t Docker solve the reproducibility problems? @@ -138,7 +138,7 @@ For Java and C++ binaries, yes, assuming you do not change the toolchain. If you ## Do you have binary releases? -Yes, you can find the latest [release binaries](https://github.com/bazelbuild/bazel/releases/latest) and review our [release policy](/release/) +Yes, you can find the latest [release binaries](https://github.com/bazelbuild/bazel/releases/latest) and review our [release policy](/versions/6.5.0/release/) ## I use Eclipse/IntelliJ/XCode. How does Bazel interoperate with IDEs? @@ -154,21 +154,21 @@ For other IDEs, check out the [blog post](https://blog.bazel.build/2016/06/10/id Bazel returns a non-zero exit code if the build or test invocation fails, and this should be enough for basic CI integration. Since Bazel does not need clean builds for correctness, the CI system should not be configured to clean before starting a build/test run. -Further details on exit codes are in the [User Manual](/docs/user-manual). +Further details on exit codes are in the [User Manual](/versions/6.5.0/docs/user-manual). ## What future features can we expect in Bazel? -See our [Roadmaps](/community/roadmaps). +See our [Roadmaps](/versions/6.5.0/community/roadmaps). ## Can I use Bazel for my INSERT LANGUAGE HERE project? -Bazel is extensible. Anyone can add support for new languages. Many languages are supported: see the [build encyclopedia](/reference/be/overview) for a list of recommendations and [awesomebazel.com](https://awesomebazel.com/) for a more comprehensive list. +Bazel is extensible. Anyone can add support for new languages. Many languages are supported: see the [build encyclopedia](/versions/6.5.0/reference/be/overview) for a list of recommendations and [awesomebazel.com](https://awesomebazel.com/) for a more comprehensive list. -If you would like to develop extensions or learn how they work, see the documentation for [extending Bazel](/rules/concepts). +If you would like to develop extensions or learn how they work, see the documentation for [extending Bazel](/versions/6.5.0/rules/concepts). ## Can I contribute to the Bazel code base? -See our [contribution guidelines](/contribute/guide). +See our [contribution guidelines](/versions/6.5.0/contribute/guide). ## Why isn’t all development done in the open? diff --git a/versions/6.5.0/about/intro.mdx b/versions/6.5.0/about/intro.mdx index 0ab19277..17ba914f 100644 --- a/versions/6.5.0/about/intro.mdx +++ b/versions/6.5.0/about/intro.mdx @@ -33,7 +33,7 @@ Bazel offers the following advantages: source files. It works with multiple repositories and user bases in the tens of thousands. -* **Bazel is extensible.** Many [languages](/rules) are +* **Bazel is extensible.** Many [languages](/versions/6.5.0/rules) are supported, and you can extend Bazel to support any other language or framework. @@ -41,9 +41,9 @@ Bazel offers the following advantages: To build or test a project with Bazel, you typically do the following: -1. **Set up Bazel.** Download and [install Bazel](/install). +1. **Set up Bazel.** Download and [install Bazel](/versions/6.5.0/install). -2. **Set up a project [workspace](/concepts/build-ref#workspaces)**, which is a +2. **Set up a project [workspace](/versions/6.5.0/concepts/build-ref#workspaces)**, which is a directory where Bazel looks for build inputs and `BUILD` files, and where it stores build outputs. @@ -51,7 +51,7 @@ To build or test a project with Bazel, you typically do the following: build it. You write your `BUILD` file by declaring build targets using - [Starlark](/rules/language), a domain-specific language. (See example + [Starlark](/versions/6.5.0/rules/language), a domain-specific language. (See example [here](https://github.com/bazelbuild/bazel/blob/master/examples/cpp/BUILD).) A build target specifies a set of input artifacts that Bazel will build plus @@ -63,11 +63,11 @@ To build or test a project with Bazel, you typically do the following: covering the most common artifact types in the supported languages on supported platforms. -4. **Run Bazel** from the [command line](/reference/command-line-reference). Bazel +4. **Run Bazel** from the [command line](/versions/6.5.0/reference/command-line-reference). Bazel places your outputs within the workspace. In addition to building, you can also use Bazel to run -[tests](/reference/test-encyclopedia) and [query](/docs/query-how-to) the build +[tests](/versions/6.5.0/reference/test-encyclopedia) and [query](/versions/6.5.0/docs/query-how-to) the build to trace dependencies in your code. ## Bazel build process {#bazel-build-process} @@ -77,8 +77,8 @@ When running a build or a test, Bazel does the following: 1. **Loads** the `BUILD` files relevant to the target. 2. **Analyzes** the inputs and their - [dependencies](/concepts/dependencies), applies the specified build - rules, and produces an [action](/rules/concepts#evaluation-model) + [dependencies](/versions/6.5.0/concepts/dependencies), applies the specified build + rules, and produces an [action](/versions/6.5.0/rules/concepts#evaluation-model) graph. 3. **Executes** the build actions on the inputs until the final build outputs @@ -87,24 +87,24 @@ When running a build or a test, Bazel does the following: Since all previous build work is cached, Bazel can identify and reuse cached artifacts and only rebuild or retest what's changed. To further enforce correctness, you can set up Bazel to run builds and tests -[hermetically](/concepts/hermeticity) through sandboxing, minimizing skew -and maximizing [reproducibility](/docs/build#correct-incremental-rebuilds). +[hermetically](/versions/6.5.0/concepts/hermeticity) through sandboxing, minimizing skew +and maximizing [reproducibility](/versions/6.5.0/docs/build#correct-incremental-rebuilds). ### Action graph {#action-graph} The action graph represents the build artifacts, the relationships between them, and the build actions that Bazel will perform. Thanks to this graph, Bazel can -[track](/docs/build#build-consistency) changes to +[track](/versions/6.5.0/docs/build#build-consistency) changes to file content as well as changes to actions, such as build or test commands, and know what build work has previously been done. The graph also enables you to -easily [trace dependencies](/docs/query-how-to) in your code. +easily [trace dependencies](/versions/6.5.0/docs/query-how-to) in your code. ## Getting started tutorials {#getting-started-tutorials} -To get started with Bazel, see [Getting Started](/start/getting-started) or jump +To get started with Bazel, see [Getting Started](/versions/6.5.0/start/getting-started) or jump directly to the Bazel tutorials: -* [Tutorial: Build a C++ Project](/tutorials/cpp) -* [Tutorial: Build a Java Project](/tutorials/java) -* [Tutorial: Build an Android Application](/tutorials/android-app) -* [Tutorial: Build an iOS Application](/tutorials/ios-app) +* [Tutorial: Build a C++ Project](/versions/6.5.0/tutorials/cpp) +* [Tutorial: Build a Java Project](/versions/6.5.0/tutorials/java) +* [Tutorial: Build an Android Application](/versions/6.5.0/tutorials/android-app) +* [Tutorial: Build an iOS Application](/versions/6.5.0/tutorials/ios-app) diff --git a/versions/6.5.0/about/roadmap.mdx b/versions/6.5.0/about/roadmap.mdx index b7d8ff18..fca6f3bf 100644 --- a/versions/6.5.0/about/roadmap.mdx +++ b/versions/6.5.0/about/roadmap.mdx @@ -13,11 +13,11 @@ To be notified of new features — including updates to this roadmap — join th ## Q4 — Bazel 6.0 Release -Q4 brings Bazel 6.0 — the new [long term support (LTS)](https://bazel.build/release/versioning) version. Bazel 6.0 plans to include new powerful and community-requested features for managing dependencies, developing with Android, and more. +Q4 brings Bazel 6.0 — the new [long term support (LTS)](https://bazel.build/versions/6.5.0/release/versioning) version. Bazel 6.0 plans to include new powerful and community-requested features for managing dependencies, developing with Android, and more. ### Bzlmod: external dependency management system -[Bzlmod](https://bazel.build/external/overview#bzlmod) automatically resolves transitive dependencies, allowing projects to scale while staying fast and resource-efficient. Introduced experimentally in Bazel 5.0, Bzlmod will be generally available and provide a solution for the [diamond dependency problem](https://docs.google.com/document/d/1moQfNcEIttsk6vYanNKIy3ZuK53hQUFq1b1r0rmsYVg/edit#heading=h.lgyp7ubwxmjc). +[Bzlmod](https://bazel.build/versions/6.5.0/external/overview#bzlmod) automatically resolves transitive dependencies, allowing projects to scale while staying fast and resource-efficient. Introduced experimentally in Bazel 5.0, Bzlmod will be generally available and provide a solution for the [diamond dependency problem](https://docs.google.com/document/d/1moQfNcEIttsk6vYanNKIy3ZuK53hQUFq1b1r0rmsYVg/edit#heading=h.lgyp7ubwxmjc). * Bzlmod goes from ‘experimental’ to ‘generally available’ * Includes support for `rules\_jvm\_external`, allowing users to download Maven dependencies for Java projects @@ -39,7 +39,7 @@ Bazel 6.0 will include improved tooling and merged-in community feature contribu ### Optional toolchains -Our Developer Satisfaction survey showed that rule authors want support for further toolchain development. Bazel 6.0 will allow authors to write rules using an [optional, high performance toolchain](https://bazel.build/docs/toolchains#optional-toolchains) when available with a fallback implementation for other platforms. +Our Developer Satisfaction survey showed that rule authors want support for further toolchain development. Bazel 6.0 will allow authors to write rules using an [optional, high performance toolchain](https://bazel.build/versions/6.5.0/docs/toolchains#optional-toolchains) when available with a fallback implementation for other platforms. ### Bazel-JetBrains\* IntelliJ IDEA support diff --git a/versions/6.5.0/about/vision.mdx b/versions/6.5.0/about/vision.mdx index e1ec31b9..2a5bd2a1 100644 --- a/versions/6.5.0/about/vision.mdx +++ b/versions/6.5.0/about/vision.mdx @@ -83,7 +83,7 @@ any language. ["Bazel sandwich"](https://github.com/bazelbuild/bazel-website/blob/master/designs/_posts/2016-08-04-extensibility-for-native-rules.md) principles. 1. The rules need to be **remote-execution ready**. In practice, this means - **configurable using the [toolchains](/docs/toolchains) mechanism**. + **configurable using the [toolchains](/versions/6.5.0/docs/toolchains) mechanism**. 1. The rules (and Bazel) need to interface with a **widely-used IDE** for the language, if there is one. 1. The rules need to have **thorough, usable documentation,** with introductory diff --git a/versions/6.5.0/basics/artifact-based-builds.mdx b/versions/6.5.0/basics/artifact-based-builds.mdx index 85d95652..1b55810e 100644 --- a/versions/6.5.0/basics/artifact-based-builds.mdx +++ b/versions/6.5.0/basics/artifact-based-builds.mdx @@ -170,7 +170,7 @@ at a known location. Just like any other dependency, if the Java compiler changes, every artifact that depends on it is rebuilt. Bazel solves the second part of the problem, platform independence, by setting -[build configurations](/docs/build#build-config-cross-compilation). Rather than +[build configurations](/versions/6.5.0/docs/build#build-config-cross-compilation). Rather than targets depending directly on their tools, they depend on types of configurations: * **Host configuration**: building tools that run during the build @@ -183,7 +183,7 @@ box, but engineers will always want to do more—part of the benefit of task-bas systems is their flexibility in supporting any kind of build process, and it would be better not to give that up in an artifact-based build system. Fortunately, Bazel allows its supported target types to be extended by -[adding custom rules](/rules/rules). +[adding custom rules](/versions/6.5.0/rules/rules). To define a rule in Bazel, the rule author declares the inputs that the rule requires (in the form of attributes passed in the `BUILD` file) and the fixed @@ -210,7 +210,7 @@ those rules without ever having to worry about their implementation. Actions sound like they might run into the same problems as tasks in other systems—isn’t it still possible to write actions that both write to the same file and end up conflicting with one another? Actually, Bazel makes these -conflicts impossible by using _[sandboxing](/docs/sandboxing)_. On supported +conflicts impossible by using _[sandboxing](/versions/6.5.0/docs/sandboxing)_. On supported systems, every action is isolated from every other action via a filesystem sandbox. Effectively, each action can see only a restricted view of the filesystem that includes the inputs it has declared and any outputs it has diff --git a/versions/6.5.0/basics/dependencies.mdx b/versions/6.5.0/basics/dependencies.mdx index 362b9e01..2847904e 100644 --- a/versions/6.5.0/basics/dependencies.mdx +++ b/versions/6.5.0/basics/dependencies.mdx @@ -109,7 +109,7 @@ transitive dependencies (Figure 1). Suppose target A depends on target B, which depends on a common library target C. Should target A be able to use classes defined in target C? -[![Transitive dependencies](/images/transitive-dependencies.png)](/images/transitive-dependencies.png) +[![Transitive dependencies](/versions/6.5.0/images/transitive-dependencies.png)](/versions/6.5.0/images/transitive-dependencies.png) **Figure 1**. Transitive dependencies diff --git a/versions/6.5.0/basics/distributed-builds.mdx b/versions/6.5.0/basics/distributed-builds.mdx index 8977c18c..a0aaa452 100644 --- a/versions/6.5.0/basics/distributed-builds.mdx +++ b/versions/6.5.0/basics/distributed-builds.mdx @@ -20,7 +20,7 @@ we’ve been working toward by defining an artifact-based build system. The simplest type of distributed build is one that only leverages _remote caching_, which is shown in Figure 1. -[![Distributed build with remote caching](/images/distributed-build-remote-cache.png)](/images/distributed-build-remote-cache.png) +[![Distributed build with remote caching](/versions/6.5.0/images/distributed-build-remote-cache.png)](/versions/6.5.0/images/distributed-build-remote-cache.png) **Figure 1**. A distributed build showing remote caching @@ -62,7 +62,7 @@ to perform the entire build locally on your machine. The true goal is to support remote execution, in which the actual work of doing the build can be spread across any number of workers. Figure 2 depicts a remote execution system. -[![Remote execution system](/images/remote-execution-system.png)](/images/remote-execution-system.png) +[![Remote execution system](/versions/6.5.0/images/remote-execution-system.png)](/versions/6.5.0/images/remote-execution-system.png) **Figure 2**. A remote execution system @@ -102,7 +102,7 @@ one. Since 2008, Google has been using a distributed build system that employs both remote caching and remote execution, which is illustrated in Figure 3. -[![High-level build system](/images/high-level-build-system.png)](/images/high-level-build-system.png) +[![High-level build system](/versions/6.5.0/images/high-level-build-system.png)](/versions/6.5.0/images/high-level-build-system.png) **Figure 3**. Google’s distributed build system diff --git a/versions/6.5.0/basics/hermeticity.mdx b/versions/6.5.0/basics/hermeticity.mdx index b2c273a6..4e6b1ef6 100644 --- a/versions/6.5.0/basics/hermeticity.mdx +++ b/versions/6.5.0/basics/hermeticity.mdx @@ -70,18 +70,18 @@ non-hermetic actions. step twice or on different systems, compare a hash of the file contents and get results that differ, the build is not reproducible. * Run steps to - [debug local cache hits](/docs/remote-execution-caching-debug#troubleshooting-cache-hits) + [debug local cache hits](/versions/6.5.0/docs/remote-execution-caching-debug#troubleshooting-cache-hits) from a variety of potential client machines to ensure that you catch any cases of client environment leaking into the actions. * Execute a build within a docker container that contains nothing but the checked-out source tree and explicit list of host tools. Build breakages and error messages will catch implicit system dependencies. * Discover and fix hermeticity problems using - [remote execution rules](/docs/remote-execution-rules#overview). -* Enable strict [sandboxing](/docs/sandboxing) + [remote execution rules](/versions/6.5.0/docs/remote-execution-rules#overview). +* Enable strict [sandboxing](/versions/6.5.0/docs/sandboxing) at the per-action level, since actions in a build can be stateful and affect the build or the output. -* [Workspace rules](/docs/workspace-log) +* [Workspace rules](/versions/6.5.0/docs/workspace-log) allow developers to add dependencies to external workspaces, but they are rich enough to allow arbitrary processing to happen in the process. You can get a log of some potentially non-hermetic actions in Bazel workspace rules by diff --git a/versions/6.5.0/basics/index.mdx b/versions/6.5.0/basics/index.mdx index cb3c89b3..97597734 100644 --- a/versions/6.5.0/basics/index.mdx +++ b/versions/6.5.0/basics/index.mdx @@ -27,30 +27,30 @@ Build Philosophy_ chapter of the Thank you to the original author, Erik Kuefler, for allowing its reuse and modification here! -* **[Why a Build System?](/basics/build-systems)** +* **[Why a Build System?](/versions/6.5.0/basics/build-systems)** If you haven't used a build system before, start here. This page covers why you should use a build system, and why compilers and build scripts aren't the best choice once your organization starts to scale beyond a few developers. -* **[Task-Based Build Systems](/basics/task-based-builds)** +* **[Task-Based Build Systems](/versions/6.5.0/basics/task-based-builds)** This page discusses task-based build systems (such as Make, Maven, and Gradle) and some of their challenges. -* **[Artifact-Based Build Systems](/basics/artifact-based-builds)** +* **[Artifact-Based Build Systems](/versions/6.5.0/basics/artifact-based-builds)** This page discusses artifact-based build systems in response to the pain points of task-based build systems. -* **[Distributed Builds](/basics/distributed-builds)** +* **[Distributed Builds](/versions/6.5.0/basics/distributed-builds)** This page covers distributed builds, or builds that are executed outside of your local machine. This requires more robust infrastructure to share resources and build results (and is where the true wizardry happens!) -* **[Dependency Management](/basics/dependencies)** +* **[Dependency Management](/versions/6.5.0/basics/dependencies)** This page covers some complications of dependencies at a large scale and strategies to counteract those complications. diff --git a/versions/6.5.0/basics/task-based-builds.mdx b/versions/6.5.0/basics/task-based-builds.mdx index 35379ef5..fc5e8676 100644 --- a/versions/6.5.0/basics/task-based-builds.mdx +++ b/versions/6.5.0/basics/task-based-builds.mdx @@ -67,7 +67,7 @@ plug-ins to cover any sort of logic. Each task can also define the tasks it depends on via the depends attribute. These dependencies form an acyclic graph, as seen in Figure 1. -[![Acrylic graph showing dependencies](/images/task-dependencies.png)](/images/task-dependencies.png) +[![Acrylic graph showing dependencies](/versions/6.5.0/images/task-dependencies.png)](/versions/6.5.0/images/task-dependencies.png) Figure 1. An acyclic graph showing dependencies diff --git a/versions/6.5.0/community/images/Bitrise.png b/versions/6.5.0/community/images/Bitrise.png new file mode 100644 index 00000000..07f85f1e Binary files /dev/null and b/versions/6.5.0/community/images/Bitrise.png differ diff --git a/versions/6.5.0/community/images/Gradle.png b/versions/6.5.0/community/images/Gradle.png new file mode 100644 index 00000000..1e5f5eb0 Binary files /dev/null and b/versions/6.5.0/community/images/Gradle.png differ diff --git a/versions/6.5.0/community/images/Linkedin-Logo.png b/versions/6.5.0/community/images/Linkedin-Logo.png new file mode 100644 index 00000000..9dd8715c Binary files /dev/null and b/versions/6.5.0/community/images/Linkedin-Logo.png differ diff --git a/versions/6.5.0/community/images/Lucid_Software-logo.svg b/versions/6.5.0/community/images/Lucid_Software-logo.svg new file mode 100644 index 00000000..6c8591e0 --- /dev/null +++ b/versions/6.5.0/community/images/Lucid_Software-logo.svg @@ -0,0 +1,16 @@ + + + + + + + + + + + + + + + + diff --git a/versions/6.5.0/community/images/acqio_logo.svg b/versions/6.5.0/community/images/acqio_logo.svg new file mode 100644 index 00000000..8fa11bcd --- /dev/null +++ b/versions/6.5.0/community/images/acqio_logo.svg @@ -0,0 +1,60 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/versions/6.5.0/community/images/aspect-logo-2.png b/versions/6.5.0/community/images/aspect-logo-2.png new file mode 100644 index 00000000..dfebc4cb Binary files /dev/null and b/versions/6.5.0/community/images/aspect-logo-2.png differ diff --git a/versions/6.5.0/community/images/bitrise-logo.png b/versions/6.5.0/community/images/bitrise-logo.png new file mode 100644 index 00000000..27037ce6 Binary files /dev/null and b/versions/6.5.0/community/images/bitrise-logo.png differ diff --git a/versions/6.5.0/community/images/buildbuddy-logo.svg b/versions/6.5.0/community/images/buildbuddy-logo.svg new file mode 100644 index 00000000..bdb72dc6 --- /dev/null +++ b/versions/6.5.0/community/images/buildbuddy-logo.svg @@ -0,0 +1,11 @@ + + + + + + + + + + + diff --git a/versions/6.5.0/community/images/buildkite.svg b/versions/6.5.0/community/images/buildkite.svg new file mode 100644 index 00000000..209a4ab1 --- /dev/null +++ b/versions/6.5.0/community/images/buildkite.svg @@ -0,0 +1 @@ + \ No newline at end of file diff --git a/versions/6.5.0/community/images/codethink-logo.svg b/versions/6.5.0/community/images/codethink-logo.svg new file mode 100644 index 00000000..406005d8 --- /dev/null +++ b/versions/6.5.0/community/images/codethink-logo.svg @@ -0,0 +1 @@ + \ No newline at end of file diff --git a/versions/6.5.0/community/images/develocity.png b/versions/6.5.0/community/images/develocity.png new file mode 100644 index 00000000..eb3eb65a Binary files /dev/null and b/versions/6.5.0/community/images/develocity.png differ diff --git a/versions/6.5.0/community/images/dropbox.png b/versions/6.5.0/community/images/dropbox.png new file mode 100644 index 00000000..125476a6 Binary files /dev/null and b/versions/6.5.0/community/images/dropbox.png differ diff --git a/versions/6.5.0/community/images/engflow-logo.svg b/versions/6.5.0/community/images/engflow-logo.svg new file mode 100644 index 00000000..e5f0c343 --- /dev/null +++ b/versions/6.5.0/community/images/engflow-logo.svg @@ -0,0 +1 @@ + \ No newline at end of file diff --git a/versions/6.5.0/community/images/epam-logo.png b/versions/6.5.0/community/images/epam-logo.png new file mode 100644 index 00000000..e6a5674c Binary files /dev/null and b/versions/6.5.0/community/images/epam-logo.png differ diff --git a/versions/6.5.0/community/images/flare-logo.png b/versions/6.5.0/community/images/flare-logo.png new file mode 100644 index 00000000..84cb0e5b Binary files /dev/null and b/versions/6.5.0/community/images/flare-logo.png differ diff --git a/versions/6.5.0/community/images/hermetiq-logo.png b/versions/6.5.0/community/images/hermetiq-logo.png new file mode 100644 index 00000000..90765d96 Binary files /dev/null and b/versions/6.5.0/community/images/hermetiq-logo.png differ diff --git a/versions/6.5.0/community/images/jetbrains.svg b/versions/6.5.0/community/images/jetbrains.svg new file mode 100644 index 00000000..cb3a2a0e --- /dev/null +++ b/versions/6.5.0/community/images/jetbrains.svg @@ -0,0 +1,13 @@ + + + + + + + + + + + + + diff --git a/versions/6.5.0/community/images/liulishuo.png b/versions/6.5.0/community/images/liulishuo.png new file mode 100644 index 00000000..a6758e5c Binary files /dev/null and b/versions/6.5.0/community/images/liulishuo.png differ diff --git a/versions/6.5.0/community/images/nativelink.svg b/versions/6.5.0/community/images/nativelink.svg new file mode 100644 index 00000000..148fcdce --- /dev/null +++ b/versions/6.5.0/community/images/nativelink.svg @@ -0,0 +1,1123 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/versions/6.5.0/community/images/oasis-logo.png b/versions/6.5.0/community/images/oasis-logo.png new file mode 100644 index 00000000..846a9cd5 Binary files /dev/null and b/versions/6.5.0/community/images/oasis-logo.png differ diff --git a/versions/6.5.0/community/images/sumglobal-logo.png b/versions/6.5.0/community/images/sumglobal-logo.png new file mode 100644 index 00000000..6736328d Binary files /dev/null and b/versions/6.5.0/community/images/sumglobal-logo.png differ diff --git a/versions/6.5.0/community/images/trunk-logo-dark.svg b/versions/6.5.0/community/images/trunk-logo-dark.svg new file mode 100644 index 00000000..f25940af --- /dev/null +++ b/versions/6.5.0/community/images/trunk-logo-dark.svg @@ -0,0 +1,22 @@ + + + + + + + + + + + + + + + + + + + + + + diff --git a/versions/6.5.0/community/images/tweag-logo.png b/versions/6.5.0/community/images/tweag-logo.png new file mode 100644 index 00000000..20210ed7 Binary files /dev/null and b/versions/6.5.0/community/images/tweag-logo.png differ diff --git a/versions/6.5.0/community/images/typedb.png b/versions/6.5.0/community/images/typedb.png new file mode 100644 index 00000000..48ce1056 Binary files /dev/null and b/versions/6.5.0/community/images/typedb.png differ diff --git a/versions/6.5.0/community/images/virtuslab.svg b/versions/6.5.0/community/images/virtuslab.svg new file mode 100644 index 00000000..6fba0316 --- /dev/null +++ b/versions/6.5.0/community/images/virtuslab.svg @@ -0,0 +1,20 @@ + + + + + + + + + + + + + + + + + + diff --git a/versions/6.5.0/community/recommended-rules.mdx b/versions/6.5.0/community/recommended-rules.mdx index 30426fa1..6220d1f2 100644 --- a/versions/6.5.0/community/recommended-rules.mdx +++ b/versions/6.5.0/community/recommended-rules.mdx @@ -4,7 +4,7 @@ title: 'Recommended Rules' In the documentation, we provide a list of -[recommended rules](/rules). +[recommended rules](/versions/6.5.0/rules). This is a set of high quality rules, which will provide a good experience to our users. We make a distinction between the supported rules, and the hundreds of @@ -16,7 +16,7 @@ If a ruleset meets the requirements below, a rule maintainer can nominate it to be part of the _recommended rules_ by filing a [GitHub issue](https://github.com/bazelbuild/bazel/). -After a review by the [Bazel core team](/contribute/contribution-policy), it +After a review by the [Bazel core team](/versions/6.5.0/contribute/contribution-policy), it will be recommended on the Bazel website. ## Requirements for the rule maintainers {#requirements-rule-maintainers} @@ -26,7 +26,7 @@ will be recommended on the Bazel website. * The ruleset is well maintained. There must be at least two active maintainers. * The ruleset is well documented, with examples, and easy to use. * The ruleset follows the best practices and is performant (see - [the performance guide](/rules/performance)). + [the performance guide](/versions/6.5.0/rules/performance)). * The ruleset has sufficient test coverage. * The ruleset is tested on [BuildKite](https://github.com/bazelbuild/continuous-integration/blob/master/buildkite/README.md) diff --git a/versions/6.5.0/community/roadmaps-configurability.mdx b/versions/6.5.0/community/roadmaps-configurability.mdx index b2ddeda8..aba34854 100644 --- a/versions/6.5.0/community/roadmaps-configurability.mdx +++ b/versions/6.5.0/community/roadmaps-configurability.mdx @@ -26,8 +26,7 @@ title: 'Bazel Configurability 2021 Roadmap' * Builds scale well, particularly w.r.t graph size and action caching. We also support -[`cquery`](https://bazel.build/versions/6.5.0/docs/cquery), [`Starlark -configuration`](https://bazel.build/rules/config), +[`cquery`](https://bazel.build/versions/6.5.0/docs/cquery), [`Starlark configuration`](https://bazel.build/versions/6.5.0/rules/config), and [`select()`](https://bazel.build/versions/6.5.0/docs/configurable-attributes). @@ -41,15 +40,13 @@ interest of accurate expectations. ### Platforms
-Q3 2021**Android rules use the new [platforms -API](https://bazel.build/concepts/platforms-intro)** +Q3 2021**Android rules use the new [platforms API](https://bazel.build/versions/6.5.0/concepts/platforms-intro)** IN PROGRESS ([#11749](https://github.com/bazelbuild/bazel/issues/11749)) * This is our main priority for the beginning of 2021.
-Q3 2021**Builds support [multiple execution -platforms](https://docs.google.com/document/d/1U9HzdDmtRnm244CaRM6JV-q2408mbNODAMewcGjnnbM/)** +Q3 2021**Builds support [multiple execution platforms](https://docs.google.com/document/d/1U9HzdDmtRnm244CaRM6JV-q2408mbNODAMewcGjnnbM/)** IN PROGRESS ([#11748](https://github.com/bazelbuild/bazel/issues/11748))
diff --git a/versions/6.5.0/community/sig.mdx b/versions/6.5.0/community/sig.mdx index 150fb417..26976f02 100644 --- a/versions/6.5.0/community/sig.mdx +++ b/versions/6.5.0/community/sig.mdx @@ -4,8 +4,7 @@ title: 'Bazel Special Interest Groups' Bazel hosts Special Interest Groups (SIGs) to focus collaboration on particular -areas and to support communication and coordination between [Bazel owners, -maintainers, and contributors](/contribute/contribution-policy). This policy +areas and to support communication and coordination between [Bazel owners, maintainers, and contributors](/versions/6.5.0/contribute/contribution-policy). This policy applies to [`bazelbuild`](http://github.com/bazelbuild). SIGs do their work in public. The ideal scope for a SIG covers a well-defined diff --git a/versions/6.5.0/concepts/build-ref.mdx b/versions/6.5.0/concepts/build-ref.mdx index 3cc6bf3a..5a251fd1 100644 --- a/versions/6.5.0/concepts/build-ref.mdx +++ b/versions/6.5.0/concepts/build-ref.mdx @@ -14,8 +14,7 @@ outputs can be built from the source. A _workspace_ is a directory tree on your filesystem that contains the source files for the software you want to build. Each workspace has a text file named -`WORKSPACE` which may be empty, or may contain references to [external -dependencies](/docs/external) required to build the outputs. +`WORKSPACE` which may be empty, or may contain references to [external dependencies](/versions/6.5.0/docs/external) required to build the outputs. Directories containing a file called `WORKSPACE` are considered the root of a workspace. Therefore, Bazel ignores any directory trees in a workspace rooted at @@ -29,13 +28,9 @@ both files exist, `WORKSPACE.bazel` is used. Code is organized in _repositories_. The directory containing the `WORKSPACE` file is the root of the main repository, also called `@`. Other, (external) repositories are defined in the `WORKSPACE` file using workspace rules, or -generated from modules and extensions in the Bzlmod system. See [external -dependencies overview](/external/overview) for more information. +generated from modules and extensions in the Bzlmod system. See [external dependencies overview](/versions/6.5.0/external/overview) for more information. -The workspace rules bundled with Bazel are documented in the [Workspace -Rules](/reference/be/workspace) section in the [Build -Encyclopedia](/reference/be/overview) and the documentation on [embedded -Starlark repository rules](/rules/lib/repo/index). +The workspace rules bundled with Bazel are documented in the [Workspace Rules](/versions/6.5.0/reference/be/workspace) section in the [Build Encyclopedia](/versions/6.5.0/reference/be/overview) and the documentation on [embedded Starlark repository rules](/versions/6.5.0/rules/lib/repo/index). As external repositories are repositories themselves, they often contain a `WORKSPACE` file as well. However, these additional `WORKSPACE` files are @@ -107,5 +102,4 @@ have three properties: the list of packages they contain, their name, and other package groups they include. The only allowed ways to refer to them are from the `visibility` attribute of rules or from the `default_visibility` attribute of the `package` function; they do not generate or consume files. For more -information, refer to the [`package_group` -documentation](/reference/be/functions#package_group). +information, refer to the [`package_group` documentation](/versions/6.5.0/reference/be/functions#package_group). diff --git a/versions/6.5.0/concepts/platforms.mdx b/versions/6.5.0/concepts/platforms.mdx index 01de1628..0f9d77fc 100644 --- a/versions/6.5.0/concepts/platforms.mdx +++ b/versions/6.5.0/concepts/platforms.mdx @@ -105,7 +105,7 @@ or opt in early depends on your specific value / cost needs: flags on the command line. * Simpler language design. All languages share a common API for defining toolchains, using toolchains, and selecting the right toolchain for a platform. -* Targets can be [skipped](/docs/platforms#skipping-incompatible-targets) in the +* Targets can be [skipped](/versions/6.5.0/docs/platforms#skipping-incompatible-targets) in the build and test phase if they are incompatible with the target platform. ### Costs @@ -157,10 +157,8 @@ attributes declare a language's tools (like `compiler = this information to rules that need to build with these tools. Toolchains declare the `constraint_value`s of machines they can -[target][target_compatible_with Attribute] -(`target_compatible_with = ["@platforms//os:linux"]`) and machines their tools can -[run on][exec_compatible_with Attribute] -(`exec_compatible_with = ["@platforms//os:mac"]`). +[target][target_compatible_with Attribute](`target_compatible_with = ["@platforms//os:linux"]`) and machines their tools can +[run on][exec_compatible_with Attribute](`exec_compatible_with = ["@platforms//os:mac"]`). When building `$ bazel build //:myproject --platforms=//:myplatform`, Bazel automatically selects a toolchain that can run on the build machine and @@ -265,7 +263,7 @@ Bazel's Java rules use platforms. This replaces legacy flags `--java_toolchain`, `--host_java_toolchain`, `--javabase`, and `--host_javabase`. -To learn how to use the configuration flags, see the [Bazel and Java](/docs/bazel-and-java) manual. +To learn how to use the configuration flags, see the [Bazel and Java](/versions/6.5.0/docs/bazel-and-java) manual. For additional information, see the [Design document](https://docs.google.com/document/d/1MVbBxbKVKRJJY7DnkptHpvz7ROhyAYy4a-TZ-n7Q0r4). If you are still using legacy flags, follow the migration process in [Issue #7849](https://github.com/bazelbuild/bazel/issues/7849). @@ -283,8 +281,7 @@ Bazel's Apple rules do not yet support platforms to select Apple toolchains. They also don't support platform-enabled C++ dependencies because they use the legacy `--crosstool_top` to set the C++ toolchain. Until this is migrated, you -can mix Apple projects with platorm-enabled C++ with [platform -mappings](#platform-mappings) +can mix Apple projects with platorm-enabled C++ with [platform mappings](#platform-mappings) ([example](https://github.com/bazelbuild/bazel/issues/8716#issuecomment-516572378)). ### Other languages {#other-languages} @@ -297,7 +294,7 @@ platforms If you're designing rules for a new language, use platforms to select your language's toolchains. See the -[toolchains documentation](/docs/toolchains) for a good walkthrough. +[toolchains documentation](/versions/6.5.0/docs/toolchains) for a good walkthrough. ### `select()` {#select} @@ -345,8 +342,7 @@ sets `--cpu`, `--crossstool_top`, or other legacy flags, rules that read When migrating your project to platforms, you must either convert changes like `return { "//command_line_option:cpu": "arm" }` to `return { -"//command_line_option:platforms": "//:my_arm_platform" }` or use [platform -mappings](#platform-mappings) to support both styles through the migration +"//command_line_option:platforms": "//:my_arm_platform" }` or use [platform mappings](#platform-mappings) to support both styles through the migration window. ## How to use platforms today @@ -359,8 +355,7 @@ If you're a project, language, or toolchain maintainer and your build doesn't use platforms by default, you have three options (besides waiting for the global migration): -1. Flip on the "use platforms" flag for your project's languages ([if they have - one](#status)) and do whatever testing you need to see if the projects you care +1. Flip on the "use platforms" flag for your project's languages ([if they have one](#status)) and do whatever testing you need to see if the projects you care about work. 1. If the projects you care about still depend on legacy flags like `--cpu` and diff --git a/versions/6.5.0/concepts/visibility.mdx b/versions/6.5.0/concepts/visibility.mdx index e0f5a867..2dddfd4c 100644 --- a/versions/6.5.0/concepts/visibility.mdx +++ b/versions/6.5.0/concepts/visibility.mdx @@ -20,18 +20,18 @@ A target `A` is visible to a target `B` if they are in the same package, or if `A` grants visibility to `B`'s package. Thus, packages are the unit of granularity for deciding whether or not to allow access. If `B` depends on `A` but `A` is not visible to `B`, then any attempt to build `B` fails during -[analysis](/reference/glossary#analysis-phase). +[analysis](/versions/6.5.0/reference/glossary#analysis-phase). Note that granting visibility to a package does not by itself grant visibility to its subpackages. For more details on package and subpackages, see -[Concepts and terminology](/concepts/build-ref). +[Concepts and terminology](/versions/6.5.0/concepts/build-ref). For prototyping, you can disable target visibility enforcement by setting the flag `--check_visibility=false`. This should not be done for production usage in submitted code. The primary way to control visibility is with the -[`visibility`](/reference/be/common-definitions#common.visibility) attribute on +[`visibility`](/versions/6.5.0/reference/be/common-definitions#common.visibility) attribute on rule targets. This section describes the format of this attribute, and how to determine a target's visibility. @@ -55,10 +55,10 @@ are just syntactic placeholders that do not correspond to any actual target. direct and indirect subpackages. * `"//some_pkg:my_package_group"`: Grants access to all of the packages that - are part of the given [`package_group`](/reference/be/functions#package_group). + are part of the given [`package_group`](/versions/6.5.0/reference/be/functions#package_group). * Package groups use a - [different syntax](/reference/be/functions#package_group.packages) for + [different syntax](/versions/6.5.0/reference/be/functions#package_group.packages) for specifying packages. Within a package group, the forms `"//foo/bar:__pkg__"` and `"//foo/bar:__subpackages__"` are respectively replaced by `"//foo/bar"` and `"//foo/bar/..."`. Likewise, @@ -86,8 +86,8 @@ A rule target's visibility is: 1. The value of its `visibility` attribute, if set; or else 2. The value of the -[`default_visibility`](/reference/be/functions#package.default_visibility) -argument of the [`package`](/reference/be/functions#package) statement in the +[`default_visibility`](/versions/6.5.0/reference/be/functions#package.default_visibility) +argument of the [`package`](/versions/6.5.0/reference/be/functions#package) statement in the target's `BUILD` file, if such a declaration exists; or else 3. `//visibility:private`. @@ -158,7 +158,7 @@ generates it. ### Source file target visibility {#source-file-target-visibility} You can explicitly set the visibility of a source file target by calling -[`exports_files`](/reference/be/functions#exports_files). When no `visibility` +[`exports_files`](/versions/6.5.0/reference/be/functions#exports_files). When no `visibility` argument is passed to `exports_files`, it makes the visibility public. `exports_files` may not be used to override the visibility of a generated file. @@ -200,8 +200,8 @@ cc_binary( ### Config setting visibility {#config-setting-visibility} Historically, Bazel has not enforced visibility for -[`config_setting`](/reference/be/general#config_setting) targets that are -referenced in the keys of a [`select()`](/reference/be/functions#select). There +[`config_setting`](/versions/6.5.0/reference/be/general#config_setting) targets that are +referenced in the keys of a [`select()`](/versions/6.5.0/reference/be/functions#select). There are two flags to remove this legacy behavior: * [`--incompatible_enforce_config_setting_visibility`](https://github.com/bazelbuild/bazel/issues/12932) @@ -226,7 +226,7 @@ publicly visible. ### Visibility of implicit dependencies {#visibility-implicit-dependencies} -Some rules have [implicit dependencies](/extending/rules#private_attributes_and_implicit_dependencies) — +Some rules have [implicit dependencies](/versions/6.5.0/extending/rules#private_attributes_and_implicit_dependencies) — dependencies that are not spelled out in a `BUILD` file but are inherent to every instance of that rule. For example, a `cc_library` rule might create an implicit dependency from each of its rule targets to an executable target @@ -264,7 +264,7 @@ same workspace, so that modifying the macro breaks other teams' builds. Note that a `.bzl` file may or may not have a corresponding source file target. If it does, there is no guarantee that the load visibility and the target visibility coincide. That is, the same `BUILD` file might be able to load the -`.bzl` file but not list it in the `srcs` of a [`filegroup`](/reference/be/general#filegroup), +`.bzl` file but not list it in the `srcs` of a [`filegroup`](/versions/6.5.0/reference/be/general#filegroup), or vice versa. This can sometimes cause problems for rules that wish to consume `.bzl` files as source code, such as for documentation generation or testing. @@ -277,9 +277,9 @@ Load visibility is available as of Bazel 6.0. ### Declaring load visibility {#declaring-load-visibility} To set the load visibility of a `.bzl` file, call the -[`visibility()`](/rules/lib/globals#visibility) function from within the file. +[`visibility()`](/versions/6.5.0/rules/lib/globals#visibility) function from within the file. The argument to `visibility()` is a list of package specifications, just like -the [`packages`](/reference/be/functions#package_group.packages) attribute of +the [`packages`](/versions/6.5.0/reference/be/functions#package_group.packages) attribute of `package_group`. However, `visibility()` does not accept negative package specifications. @@ -372,7 +372,7 @@ visibilities. It also is more readable when the `clients` list is large. Sometimes a `.bzl` file might need to be visible to an allowlist that is composed of multiple smaller allowlists. This is analogous to how a `package_group` can incorporate other `package_group`s via its -[`includes`](/reference/be/functions#package_group.includes) attribute. +[`includes`](/versions/6.5.0/reference/be/functions#package_group.includes) attribute. Suppose you are deprecating a widely used macro. You want it to be visible only to existing users and to the packages owned by your own team. You might write: diff --git a/versions/6.5.0/configure/attributes.mdx b/versions/6.5.0/configure/attributes.mdx index f3ca7de6..207ea97b 100644 --- a/versions/6.5.0/configure/attributes.mdx +++ b/versions/6.5.0/configure/attributes.mdx @@ -3,8 +3,7 @@ title: 'Configurable Build Attributes' --- -**_Configurable attributes_**, commonly known as [`select()`]( -/reference/be/functions#select), is a Bazel feature that lets users toggle the values +**_Configurable attributes_**, commonly known as [`select()`](/versions/6.5.0/reference/be/functions#select), is a Bazel feature that lets users toggle the values of build rule attributes at the command line. This can be used, for example, for a multiplatform library that automatically @@ -67,7 +66,7 @@ command line. Specifically, `deps` becomes:
`select()` serves as a placeholder for a value that will be chosen based on -*configuration conditions*, which are labels referencing [`config_setting`](/reference/be/general#config_setting) +*configuration conditions*, which are labels referencing [`config_setting`](/versions/6.5.0/reference/be/general#config_setting) targets. By using `select()` in a configurable attribute, the attribute effectively adopts different values when different conditions hold. @@ -84,7 +83,7 @@ While this example uses `deps`, `select()` works just as well on `srcs`, `resources`, `cmd`, and most other attributes. Only a small number of attributes are *non-configurable*, and these are clearly annotated. For example, `config_setting`'s own -[`values`](/reference/be/general#config_setting.values) attribute is non-configurable. +[`values`](/versions/6.5.0/reference/be/general#config_setting.values) attribute is non-configurable. ## `select()` and dependencies {#select-and-dependencies} @@ -92,7 +91,7 @@ Certain attributes change the build parameters for all transitive dependencies under a target. For example, `genrule`'s `tools` changes `--cpu` to the CPU of the machine running Bazel (which, thanks to cross-compilation, may be different than the CPU the target is built for). This is known as a -[configuration transition](/reference/glossary#transition). +[configuration transition](/versions/6.5.0/reference/glossary#transition). Given @@ -145,8 +144,8 @@ build parameters, which include `--cpu=arm`. The `tools` attribute changes ## Configuration conditions {#configuration-conditions} Each key in a configurable attribute is a label reference to a -[`config_setting`](/reference/be/general#config_setting) or -[`constraint_value`](/reference/be/platform#constraint_value). +[`config_setting`](/versions/6.5.0/reference/be/general#config_setting) or +[`constraint_value`](/versions/6.5.0/reference/be/platform#constraint_value). `config_setting` is just a collection of expected command line flag settings. By encapsulating these in a target, it's @@ -158,8 +157,8 @@ easy to maintain "standard" conditions users can reference from multiple places. Flags like `--cpu` are built into Bazel: the build tool natively understands them for all builds in all projects. These are specified with -[`config_setting`](/reference/be/general#config_setting)'s -[`values`](/reference/be/general#config_setting.values) attribute: +[`config_setting`](/versions/6.5.0/reference/be/general#config_setting)'s +[`values`](/versions/6.5.0/reference/be/general#config_setting.values) attribute: ```python config_setting( @@ -183,7 +182,7 @@ is the expected value for that flag. `:meaningful_condition_name` matches if * `values = { "force_pic": "0" }` matches `bazel build --noforce_pic` `config_setting` only supports flags that affect target behavior. For example, -[`--show_progress`](/docs/user-manual#show-progress) isn't allowed because +[`--show_progress`](/versions/6.5.0/docs/user-manual#show-progress) isn't allowed because it only affects how Bazel reports progress to the user. Targets can't use that flag to construct their results. The exact set of supported flags isn't documented. In practice, most flags that "make sense" work. @@ -194,8 +193,8 @@ You can model your own project-specific flags with [Starlark build settings][BuildSettings]. Unlike built-in flags, these are defined as build targets, so Bazel references them with target labels. -These are triggered with [`config_setting`](/reference/be/general#config_setting)'s -[`flag_values`](/reference/be/general#config_setting.flag_values) +These are triggered with [`config_setting`](/versions/6.5.0/reference/be/general#config_setting)'s +[`flag_values`](/versions/6.5.0/reference/be/general#config_setting.flag_values) attribute: ```python @@ -212,12 +211,12 @@ config_setting( Behavior is the same as for [built-in flags](#built-in-flags). See [here](https://github.com/bazelbuild/examples/tree/HEAD/configurations/select_on_build_setting) for a working example. -[`--define`](/reference/command-line-reference#flag--define) +[`--define`](/versions/6.5.0/reference/command-line-reference#flag--define) is an alternative legacy syntax for custom flags (for example `--define foo=bar`). This can be expressed either in the -[values](/reference/be/general#config_setting.values) attribute +[values](/versions/6.5.0/reference/be/general#config_setting.values) attribute (`values = {"define": "foo=bar"}`) or the -[define_values](/reference/be/general#config_setting.define_values) attribute +[define_values](/versions/6.5.0/reference/be/general#config_setting.define_values) attribute (`define_values = {"foo": "bar"}`). `--define` is only supported for backwards compatibility. Prefer Starlark build settings whenever possible. @@ -265,7 +264,7 @@ For even clearer errors, you can set custom messages with `select()`'s While the ability to specify multiple flags on the command line provides flexibility, it can also be burdensome to individually set each one every time you want to build a target. - [Platforms](/docs/platforms) + [Platforms](/versions/6.5.0/docs/platforms) let you consolidate these into simple bundles. ```python @@ -360,7 +359,7 @@ This saves the need for boilerplate `config_setting`s when you only need to check against single values. Platforms are still under development. See the -[documentation](/concepts/platforms-intro) for details. +[documentation](/versions/6.5.0/concepts/platforms-intro) for details. ## Combining `select()`s {#combining-selects} @@ -408,8 +407,7 @@ sh_library( ) ``` -If you need a `select` to match when multiple conditions match, consider [AND -chaining](#and-chaining). +If you need a `select` to match when multiple conditions match, consider [AND chaining](#and-chaining). ## OR chaining {#or-chaining} @@ -565,7 +563,7 @@ Conditions checked: //tools/cc_target_os:android ``` -This can be customized with the [`no_match_error`](/reference/be/functions#select) +This can be customized with the [`no_match_error`](/versions/6.5.0/reference/be/functions#select) attribute: ```python @@ -627,7 +625,7 @@ select({"foo": "val_with_suffix"}, ...) This is for two reasons. First, macros that need to know which path a `select` will choose *cannot work* -because macros are evaluated in Bazel's [loading phase](/docs/build#loading), +because macros are evaluated in Bazel's [loading phase](/versions/6.5.0/docs/build#loading), which occurs before flag values are known. This is a core Bazel design restriction that's unlikely to change any time soon. @@ -637,14 +635,14 @@ this. ## Bazel query and cquery {#query-and-cquery} -Bazel [`query`](/docs/query-how-to) operates over Bazel's -[loading phase](/reference/glossary#loading-phase). +Bazel [`query`](/versions/6.5.0/docs/query-how-to) operates over Bazel's +[loading phase](/versions/6.5.0/reference/glossary#loading-phase). This means it doesn't know what command line flags a target uses since those flags aren't evaluated until later in the build (in the -[analysis phase](/reference/glossary#analysis-phase)). +[analysis phase](/versions/6.5.0/reference/glossary#analysis-phase)). So it can't determine which `select()` branches are chosen. -Bazel [`cquery`](/docs/cquery) operates after Bazel's analysis phase, so it has +Bazel [`cquery`](/versions/6.5.0/docs/cquery) operates after Bazel's analysis phase, so it has all this information and can accurately resolve `select()`s. Consider: @@ -705,7 +703,7 @@ details. The key issue this question usually means is that select() doesn't work in *macros*. These are different than *rules*. See the -documentation on [rules](/rules/rules) and [macros](/rules/macros) +documentation on [rules](/versions/6.5.0/rules/rules) and [macros](/versions/6.5.0/rules/macros) to understand the difference. Here's an end-to-end example: @@ -914,13 +912,13 @@ def selecty_genrule(name, select_cmd): ### Why doesn't select() work with bind()? {#faq-select-bind} -Because [`bind()`](/reference/be/workspace#bind) is a WORKSPACE rule, not a BUILD rule. +Because [`bind()`](/versions/6.5.0/reference/be/workspace#bind) is a WORKSPACE rule, not a BUILD rule. Workspace rules do not have a specific configuration, and aren't evaluated in the same way as BUILD rules. Therefore, a `select()` in a `bind()` can't actually evaluate to any specific branch. -Instead, you should use [`alias()`](/reference/be/general#alias), with a `select()` in +Instead, you should use [`alias()`](/versions/6.5.0/reference/be/general#alias), with a `select()` in the `actual` attribute, to perform this type of run-time determination. This works correctly, since `alias()` is a BUILD rule, and is evaluated with a specific configuration. @@ -958,7 +956,7 @@ located at `@alternative//:ssl`. ### Why doesn't my select() choose what I expect? {#faq-select-choose-condition} If `//myapp:foo` has a `select()` that doesn't choose the condition you expect, -use [cquery](/docs/cquery) and `bazel config` to debug: +use [cquery](/versions/6.5.0/docs/cquery) and `bazel config` to debug: If `//myapp:foo` is the top-level target you're building, run: @@ -999,7 +997,7 @@ Fragment com.google.devtools.build.lib.rules.cpp.CppOptions { Then compare this output against the settings expected by each `config_setting`. `//myapp:foo` may exist in different configurations in the same build. See the -[cquery docs](/docs/cquery) for guidance on using `somepath` to get the right +[cquery docs](/versions/6.5.0/docs/cquery) for guidance on using `somepath` to get the right one. Caution: To prevent restarting the Bazel server, invoke `bazel config` with the diff --git a/versions/6.5.0/configure/best-practices.mdx b/versions/6.5.0/configure/best-practices.mdx index b4cbff71..d108bea1 100644 --- a/versions/6.5.0/configure/best-practices.mdx +++ b/versions/6.5.0/configure/best-practices.mdx @@ -66,7 +66,7 @@ then the `BUILD` files are misleading. ## Using the `.bazelrc` file {#bazelrc-file} For project-specific options, use the configuration file your -`workspace/.bazelrc` (see [bazelrc format](/docs/bazelrc)). +`workspace/.bazelrc` (see [bazelrc format](/versions/6.5.0/docs/bazelrc)). If you want to support per-user options for your project that you **do not** want to check into source control, include the line: diff --git a/versions/6.5.0/configure/coverage.mdx b/versions/6.5.0/configure/coverage.mdx index e16f310f..a0c08771 100644 --- a/versions/6.5.0/configure/coverage.mdx +++ b/versions/6.5.0/configure/coverage.mdx @@ -37,10 +37,10 @@ however the latter can be more difficult for complex projects. "Instrumentation" in this case refers to the coverage tools that are used for a specific target. Bazel allows turning this on for a specific subset of files using the -[`--instrumentation_filter`](/reference/command-line-reference#flag--instrumentation_filter) +[`--instrumentation_filter`](/versions/6.5.0/reference/command-line-reference#flag--instrumentation_filter) flag, which specifies a filter for targets that are tested with the instrumentation enabled. To enable instrumentation for tests, the -[`--instrument_test_targets`](/reference/command-line-reference#flag--instrument_test_targets) +[`--instrument_test_targets`](/versions/6.5.0/reference/command-line-reference#flag--instrument_test_targets) flag is required. By default, bazel tries to match the target package(s), and prints the diff --git a/versions/6.5.0/configure/integrate-cpp.mdx b/versions/6.5.0/configure/integrate-cpp.mdx index 3bb65beb..139c3cb6 100644 --- a/versions/6.5.0/configure/integrate-cpp.mdx +++ b/versions/6.5.0/configure/integrate-cpp.mdx @@ -8,20 +8,20 @@ This page describes how to integrate with C++ rules on various levels. Because of [ongoing migration of C++ rules](https://github.com/bazelbuild/bazel/issues/6516) -to [platforms](/docs/platforms) and -[toolchains](/docs/toolchains), you +to [platforms](/versions/6.5.0/docs/platforms) and +[toolchains](/versions/6.5.0/docs/toolchains), you should use the helper function available at [@bazel_tools//tools/cpp:toolchain_utils.bzl](https://source.bazel.build/bazel/+/main:tools/cpp/toolchain_utils.bzl;l=23), which works both when toolchains are disabled and enabled. To depend on a C++ toolchain in your rule, add a -[`Label`](/rules/lib/attr#label) +[`Label`](/versions/6.5.0/rules/lib/toplevel/attr#label) attribute named `_cc_toolchain` and point it to `@bazel_tools//tools/cpp:current_cc_toolchain` (an instance of `cc_toolchain_alias` rule, that points to the currently selected C++ toolchain). Then, in the rule implementation, use [`find_cpp_toolchain(ctx)`](https://source.bazel.build/bazel/+/main:tools/cpp/toolchain_utils.bzl;l=23) to get the -[`CcToolchainInfo`](/rules/lib/CcToolchainInfo). +[`CcToolchainInfo`](/versions/6.5.0/rules/lib/providers/CcToolchainInfo). A complete working example can be found [in the rules_cc examples](https://github.com/bazelbuild/rules_cc/blob/main/examples/write_cc_toolchain_cpu/write_cc_toolchain_cpu.bzl). @@ -33,20 +33,19 @@ This is because when writing our own actions, they must behave consistently with the C++ toolchain - for example, passing C++ command line flags to a tool that invokes the C++ compiler behind the scenes. -C++ rules use a special way of constructing command lines based on [feature -configuration](/docs/cc-toolchain-config-reference). To construct a command line, +C++ rules use a special way of constructing command lines based on [feature configuration](/versions/6.5.0/docs/cc-toolchain-config-reference). To construct a command line, you need the following: * `features` and `action_configs` - these come from the `CcToolchainConfigInfo` and encapsulated in `CcToolchainInfo` -* `FeatureConfiguration` - returned by [cc_common.configure_features](/rules/lib/cc_common#configure_features) +* `FeatureConfiguration` - returned by [cc_common.configure_features](/versions/6.5.0/rules/lib/toplevel/cc_common#configure_features) * cc toolchain config variables - returned by - [cc_common.create_compile_variables](/rules/lib/cc_common#create_compile_variables) + [cc_common.create_compile_variables](/versions/6.5.0/rules/lib/toplevel/cc_common#create_compile_variables) or - [cc_common.create_link_variables](/rules/lib/cc_common#create_link_variables). + [cc_common.create_link_variables](/versions/6.5.0/rules/lib/toplevel/cc_common#create_link_variables). There still are tool-specific getters, such as -[compiler_executable](/rules/lib/CcToolchainInfo#compiler_executable). +[compiler_executable](/versions/6.5.0/rules/lib/providers/CcToolchainInfo#compiler_executable). Prefer `get_tool_for_action` over these, as tool-specific getters will eventually be removed. @@ -56,10 +55,10 @@ A complete working example can be found ## Implementing Starlark rules that depend on C++ rules and/or that C++ rules can depend on {#implement-starlark-rules} Most C++ rules provide -[`CcInfo`](/rules/lib/CcInfo), -a provider containing [`CompilationContext`](/rules/lib/CompilationContext) +[`CcInfo`](/versions/6.5.0/rules/lib/providers/CcInfo), +a provider containing [`CompilationContext`](/versions/6.5.0/rules/lib/builtins/CompilationContext) and -[`LinkingContext`](/rules/lib/LinkingContext). +[`LinkingContext`](/versions/6.5.0/rules/lib/builtins/LinkingContext). Through these it is possible to access information such as all transitive headers or libraries to link. From `CcInfo` and from the `CcToolchainInfo` custom Starlark rules should be able to get all the information they need. diff --git a/versions/6.5.0/configure/memory.mdx b/versions/6.5.0/configure/memory.mdx index 0d0e1c9d..ba2f8ba4 100644 --- a/versions/6.5.0/configure/memory.mdx +++ b/versions/6.5.0/configure/memory.mdx @@ -7,13 +7,13 @@ This page describes how to use flags to run Bazel with limited RAM. In certain situations, you may want Bazel to use minimal memory. You can set the maximum heap via the startup flag -[`--host_jvm_args`](/docs/user-manual#host-jvm-args), +[`--host_jvm_args`](/versions/6.5.0/docs/user-manual#host-jvm-args), like `--host_jvm_args=-Xmx2g`. However, if your builds are big enough, Bazel may throw an `OutOfMemoryError` (OOM) when it doesn't have enough memory. You can make Bazel use less memory, at the cost of slower incremental builds, by passing the following command flags: -[`--discard_analysis_cache`](/docs/user-manual#discard-analysis-cache), +[`--discard_analysis_cache`](/versions/6.5.0/docs/user-manual#discard-analysis-cache), `--nokeep_state_after_build`, and `--notrack_incremental_state`. These flags will minimize the memory that Bazel uses in a build, at the cost of diff --git a/versions/6.5.0/configure/toolchain-resolution.mdx b/versions/6.5.0/configure/toolchain-resolution.mdx index da4f9226..7d4038c7 100644 --- a/versions/6.5.0/configure/toolchain-resolution.mdx +++ b/versions/6.5.0/configure/toolchain-resolution.mdx @@ -6,7 +6,7 @@ title: 'Toolchain Resolution Implementation Details' **Note:** This section is intended for Bazel developers, and is not needed by rule authors. -Several SkyFunction classes implement the [toolchain resolution](/docs/toolchains) process: +Several SkyFunction classes implement the [toolchain resolution](/versions/6.5.0/docs/toolchains) process: 1. [`RegisteredToolchainsFunction`](https://github.com/bazelbuild/bazel/blob/master/src/main/java/com/google/devtools/build/lib/skyframe/RegisteredToolchainsFunction.java) and [`RegisteredExecutionPlatformsFunction`](https://github.com/bazelbuild/bazel/blob/master/src/main/java/com/google/devtools/build/lib/skyframe/RegisteredExecutionPlatformsFunction.java) @@ -36,7 +36,7 @@ Several SkyFunction classes implement the [toolchain resolution](/docs/toolchain 1. If the execution platform is already set by the toolchain transition, it will be selected first as described below. -As discussed in [Toolchains and Configurations](/docs/toolchains#toolchains_and_configurations), +As discussed in [Toolchains and Configurations](/versions/6.5.0/docs/toolchains#toolchains_and_configurations), the dependency from a target to a toolchain uses a special configuration that forces the execution platform to be the same for both. Despite the name "toolchain transition", this is not implemented as a configuration diff --git a/versions/6.5.0/configure/windows.mdx b/versions/6.5.0/configure/windows.mdx index 002af03d..76619416 100644 --- a/versions/6.5.0/configure/windows.mdx +++ b/versions/6.5.0/configure/windows.mdx @@ -166,8 +166,7 @@ To build C++ targets with MSVC, you need: set BAZEL_VC=C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC ``` -* The [Windows - SDK](https://developer.microsoft.com/en-us/windows/downloads/windows-10-sdk). +* The [Windows SDK](https://developer.microsoft.com/en-us/windows/downloads/windows-10-sdk). The Windows SDK contains header files and libraries you need when building Windows applications, including Bazel itself. By default, the latest Windows SDK installed will @@ -186,8 +185,7 @@ To build C++ targets with MSVC, you need: If everything is set up, you can build a C++ target now! -Try building a target from one of our [sample -projects](https://github.com/bazelbuild/bazel/tree/master/examples): +Try building a target from one of our [sample projects](https://github.com/bazelbuild/bazel/tree/master/examples): 
 
 
-To build and use Dynamically Linked Libraries (DLL files), see [this
-example](https://github.com/bazelbuild/bazel/tree/master/examples/windows/dll).
+To build and use Dynamically Linked Libraries (DLL files), see [this example](https://github.com/bazelbuild/bazel/tree/master/examples/windows/dll).
 
 **Command Line Length Limit**: To prevent the
 [Windows command line length limit issue](https://github.com/bazelbuild/bazel/issues/5163),
@@ -292,8 +289,7 @@ On Windows, Bazel builds two output files for `java_binary` rules:
 *   a `.jar` file
 *   a `.exe` file that can set up the environment for the JVM and run the binary
 
-Try building a target from one of our [sample
-projects](https://github.com/bazelbuild/bazel/tree/master/examples):
+Try building a target from one of our [sample projects](https://github.com/bazelbuild/bazel/tree/master/examples):
 
 
   
   
 
 If you are interested in details about how Bazel builds Python targets on
-Windows, check out this [design
-doc](https://github.com/bazelbuild/bazel-website/blob/master/designs/_posts/2016-09-05-build-python-on-windows.md).
+Windows, check out this [design doc](https://github.com/bazelbuild/bazel-website/blob/master/designs/_posts/2016-09-05-build-python-on-windows.md).
diff --git a/versions/6.5.0/contribute/breaking-changes.mdx b/versions/6.5.0/contribute/breaking-changes.mdx
index eab89264..8c3a889f 100644
--- a/versions/6.5.0/contribute/breaking-changes.mdx
+++ b/versions/6.5.0/contribute/breaking-changes.mdx
@@ -7,11 +7,11 @@ It is inevitable that we will make breaking changes to Bazel. We will have to
 change our designs and fix the things that do not quite work. However, we need
 to make sure that community and Bazel ecosystem can follow along. To that end,
 Bazel project has adopted a
-[backward compatibility policy](/release/backward-compatibility).
+[backward compatibility policy](/versions/6.5.0/release/backward-compatibility).
 This document describes the process for Bazel contributors to make a breaking
 change in Bazel to adhere to this policy.
 
-1. Follow the [design document policy](/contribute/design-documents).
+1. Follow the [design document policy](/versions/6.5.0/contribute/design-documents).
 
 1. [File a GitHub issue.](#github-issue)
 
@@ -66,7 +66,7 @@ should contain the URL of the GitHub issue. As the flag name starts with
 ```
 
 In the commit description, add a brief summary of the flag.
-Also add [`RELNOTES:`](release-notes.md) in the following form:
+Also add [`RELNOTES:`](/versions/6.5.0/contribute/release-notes) in the following form:
 `RELNOTES: --incompatible_name_of_flag has been added. See #xyz for details`
 
 The commit should also update the relevant documentation, so that there is no
diff --git a/versions/6.5.0/contribute/codebase.mdx b/versions/6.5.0/contribute/codebase.mdx
index 0349fbdf..ece14844 100644
--- a/versions/6.5.0/contribute/codebase.mdx
+++ b/versions/6.5.0/contribute/codebase.mdx
@@ -92,7 +92,7 @@ from the client are handled by `GrpcServerImpl.run()`.
 ## Directory layout {#directory-layout}
 
 Bazel creates a somewhat complicated set of directories during a build. A full
-description is available in [Output directory layout](/remote/output-directories).
+description is available in [Output directory layout](/versions/6.5.0/remote/output-directories).
 
 The "workspace" is the source tree Bazel is run in. It usually corresponds to
 something you checked out from source control.
@@ -196,7 +196,7 @@ Bazel learns about option classes in the following ways:
 3.  From `ConfiguredRuleClassProvider` (these are command line options related
     to individual programming languages)
 4.  Starlark rules can also define their own options (see
-    [here](/rules/config))
+    [here](/versions/6.5.0/rules/config))
 
 Each option (excluding Starlark-defined options) is a member variable of a
 `FragmentOptions` subclass that has the `@Option` annotation, which specifies
@@ -363,7 +363,7 @@ to do it for tiny builds, since it can get pretty large.
 Skyframe lives in the `com.google.devtools.build.skyframe` package. The
 similarly-named package `com.google.devtools.build.lib.skyframe` contains the
 implementation of Bazel on top of Skyframe. More information about Skyframe is
-available [here](/reference/skyframe).
+available [here](/versions/6.5.0/reference/skyframe).
 
 To evaluate a given `SkyKey` into a `SkyValue`, Skyframe will invoke the
 `SkyFunction` corresponding to the type of the key. During the function's
@@ -430,10 +430,10 @@ Starlark is used in several contexts, including:
 
 The dialects available for `BUILD` and `.bzl` files are slightly different
 because they express different things. A list of differences is available
-[here](/rules/language#differences-between-build-and-bzl-files).
+[here](/versions/6.5.0/rules/language#differences-between-build-and-bzl-files).
 
 More information about Starlark is available
-[here](/rules/language).
+[here](/versions/6.5.0/rules/language).
 
 ## The loading/analysis phase {#loading-phase}
 
@@ -537,7 +537,7 @@ If a configuration transition results in multiple configurations, it's called a
 _split transition._
 
 Configuration transitions can also be implemented in Starlark (documentation
-[here](/rules/config))
+[here](/versions/6.5.0/rules/config))
 
 ### Transitive info providers {#transitive-info-providers}
 
@@ -636,7 +636,7 @@ necessitates the following additional components:
 
 Aspects are a way to "propagate computation down the dependency graph". They are
 described for users of Bazel
-[here](/rules/aspects). A good
+[here](/versions/6.5.0/rules/aspects). A good
 motivating example is protocol buffers: a `proto_library` rule should not know
 about any particular language, but building the implementation of a protocol
 buffer message (the “basic unit” of protocol buffers) in any programming
@@ -687,7 +687,7 @@ Bazel supports multi-platform builds, that is, builds where there may be
 multiple architectures where build actions run and multiple architectures for
 which code is built. These architectures are referred to as _platforms_ in Bazel
 parlance (full documentation
-[here](/docs/platforms))
+[here](/versions/6.5.0/docs/platforms))
 
 A platform is described by a key-value mapping from _constraint settings_ (such as
 the concept of "CPU architecture") to _constraint values_ (such as a particular CPU
@@ -700,7 +700,7 @@ different compilers; for example, a particular C++ toolchain may run on a
 specific OS and be able to target some other OSes. Bazel must determine the C++
 compiler that is used based on the set execution and target platform
 (documentation for toolchains
-[here](/docs/toolchains)).
+[here](/versions/6.5.0/docs/toolchains)).
 
 In order to do this, toolchains are annotated with the set of execution and
 target platform constraints they support. In order to do this, the definition of
@@ -836,7 +836,7 @@ details.
 
 Bazel supports this by the mechanism called _visibility_: you can declare that a
 particular target can only be depended on using the
-[visibility](/reference/be/common-definitions#common-attributes) attribute. This
+[visibility](/versions/6.5.0/reference/be/common-definitions#common-attributes) attribute. This
 attribute is a little special because, although it holds a list of labels, these
 labels may encode a pattern over package names rather than a pointer to any
 particular target. (Yes, this is a design flaw.)
@@ -1260,7 +1260,7 @@ runs the test in the requested way.
 Tests are run according to an elaborate protocol that uses environment variables
 to tell tests what's expected from them. A detailed description of what Bazel
 expects from tests and what tests can expect from Bazel is available
-[here](/reference/test-encyclopedia). At the
+[here](/versions/6.5.0/reference/test-encyclopedia). At the
 simplest, an exit code of 0 means success, anything else means failure.
 
 In addition to the cache status file, each test process emits a number of other
@@ -1373,7 +1373,7 @@ attribute of the first test that is executed.
 ## The query engine {#query-engine}
 
 Bazel has a
-[little language](/docs/query-how-to)
+[little language](/versions/6.5.0/docs/query-how-to)
 used to ask it various things about various graphs. The following query kinds
 are provided:
 
@@ -1431,7 +1431,7 @@ interested in. For example, the following things are represented as events:
 *   A test was run (`TestAttempt`, `TestSummary`)
 
 Some of these events are represented outside of Bazel in the
-[Build Event Protocol](/remote/bep)
+[Build Event Protocol](/versions/6.5.0/remote/bep)
 (they are `BuildEvent`s). This allows not only `BlazeModule`s, but also things
 outside the Bazel process to observe the build. They are accessible either as a
 file that contains protocol messages or Bazel can connect to a server (called
diff --git a/versions/6.5.0/contribute/design-documents.mdx b/versions/6.5.0/contribute/design-documents.mdx
index 1e3a24d9..7989e74a 100644
--- a/versions/6.5.0/contribute/design-documents.mdx
+++ b/versions/6.5.0/contribute/design-documents.mdx
@@ -26,7 +26,7 @@ Here are some examples of significant changes:
 When you write a design document, you can coordinate with other Bazel developers
 and seek guidance from Bazel's core team. For example, when a proposal adds,
 removes, or modifies any function or object available in BUILD, WORKSPACE, or
-bzl files, add the [Starlark team](maintainers-guide.md) as reviewers.
+bzl files, add the [Starlark team](/versions/6.5.0/contribute/maintainers-guide) as reviewers.
 Design documents are reviewed before submission because:
 
 *   Bazel is a very complex system; seemingly innocuous local changes can have
@@ -138,8 +138,7 @@ A lead reviewer should be a domain expert who is:
 *   Objective and capable of providing constructive feedback
 *   Available for the entire review period to lead the process
 
-Consider checking the contacts for various [team
-labels](/contribute/maintainers-guide#team-labels).
+Consider checking the contacts for various [team labels](/versions/6.5.0/contribute/maintainers-guide#team-labels).
 
 ## Markdown vs Google Docs {#markdown-versus-gdocs}
 
@@ -169,12 +168,10 @@ Markdown for posterity.
 
 ### Using Google Docs {#gdocs}
 
-For consistency, use the [Bazel design doc template](
-https://docs.google.com/document/d/1cE5zrjrR40RXNg64XtRFewSv6FrLV6slGkkqxBumS1w/edit).
+For consistency, use the [Bazel design doc template](https://docs.google.com/document/d/1cE5zrjrR40RXNg64XtRFewSv6FrLV6slGkkqxBumS1w/edit).
 It includes the necessary header and creates visual
 consistency with other Bazel related documents. To do that, click on **File** >
-**Make a copy** or click this link to [make a copy of the design doc
-template](https://docs.google.com/document/d/1cE5zrjrR40RXNg64XtRFewSv6FrLV6slGkkqxBumS1w/copy).
+**Make a copy** or click this link to [make a copy of the design doc template](https://docs.google.com/document/d/1cE5zrjrR40RXNg64XtRFewSv6FrLV6slGkkqxBumS1w/copy).
 
 To make your document readable to the world, click on
 **Share** > **Advanced** > **Change…**, and
diff --git a/versions/6.5.0/contribute/docs-style-guide.mdx b/versions/6.5.0/contribute/docs-style-guide.mdx
index 3ac4d3a0..9e524b0b 100644
--- a/versions/6.5.0/contribute/docs-style-guide.mdx
+++ b/versions/6.5.0/contribute/docs-style-guide.mdx
@@ -53,7 +53,7 @@ This section contains basic writing tips.
 
 -  Keep it consistent. Don't introduce new names for existing concepts. Where
    applicable, use the term defined in the
-   [Glossary](/reference/glossary).
+   [Glossary](/versions/6.5.0/reference/glossary).
 
    -  For example, if you're writing about issuing commands on a
       terminal, don't use both terminal and command line on the page.
diff --git a/versions/6.5.0/contribute/images/structured-concurrency-3d.svg b/versions/6.5.0/contribute/images/structured-concurrency-3d.svg
new file mode 100644
index 00000000..accbb42a
--- /dev/null
+++ b/versions/6.5.0/contribute/images/structured-concurrency-3d.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/6.5.0/contribute/images/structured-concurrency.svg b/versions/6.5.0/contribute/images/structured-concurrency.svg
new file mode 100644
index 00000000..0258d9a9
--- /dev/null
+++ b/versions/6.5.0/contribute/images/structured-concurrency.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/6.5.0/contribute/images/suspend-resume.svg b/versions/6.5.0/contribute/images/suspend-resume.svg
new file mode 100644
index 00000000..7de1218f
--- /dev/null
+++ b/versions/6.5.0/contribute/images/suspend-resume.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/6.5.0/contribute/images/unstructured-concurrency.svg b/versions/6.5.0/contribute/images/unstructured-concurrency.svg
new file mode 100644
index 00000000..0951639a
--- /dev/null
+++ b/versions/6.5.0/contribute/images/unstructured-concurrency.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/6.5.0/contribute/index.mdx b/versions/6.5.0/contribute/index.mdx
index 5ed7e317..cc4f1fc7 100644
--- a/versions/6.5.0/contribute/index.mdx
+++ b/versions/6.5.0/contribute/index.mdx
@@ -11,8 +11,7 @@ As you use Bazel, you may find things that can be improved.
 You can help by [reporting issues](http://github.com/bazelbuild/bazel/issues)
 when:
 
-   - Bazel crashes or you encounter a bug that can [only be resolved using `bazel
-     clean`](/docs/build#correct-incremental-rebuilds).
+   - Bazel crashes or you encounter a bug that can [only be resolved using `bazel clean`](/versions/6.5.0/docs/build#correct-incremental-rebuilds).
    - The documentation is incomplete or unclear. You can also report issues
      from the page you are viewing by using the "Create issue"
      link at the top right corner of the page.
@@ -22,11 +21,9 @@ when:
 
 You can engage with the Bazel community by:
 
-   - Answering questions [on Stack Overflow](
-     https://stackoverflow.com/questions/tagged/bazel).
+   - Answering questions [on Stack Overflow](https://stackoverflow.com/questions/tagged/bazel).
    - Helping other users [on Slack](https://slack.bazel.build).
-   - Improving documentation or [contributing examples](
-     https://github.com/bazelbuild/examples).
+   - Improving documentation or [contributing examples](https://github.com/bazelbuild/examples).
    - Sharing your experience or your tips, for example, on a blog or social media.
 
 ## Contribute code {#contribute-code}
@@ -41,8 +38,7 @@ You can contribute to the Bazel ecosystem by:
    - Contributing to Bazel-related tools, for example, migration tools.
    - Improving Bazel integration with other IDEs and tools.
 
-Before making a change, [create a GitHub
-issue](http://github.com/bazelbuild/bazel/issues)
+Before making a change, [create a GitHub issue](http://github.com/bazelbuild/bazel/issues)
 or email [bazel-dev@](mailto:bazel-dev@googlegroups.com).
 
 The most helpful contributions fix bugs or add features (as opposed
@@ -51,25 +47,25 @@ include tests and documentation, keeping in mind backward-compatibility,
 portability, and the impact on memory usage and performance.
 
 To learn about how to submit a change, see the
-[patch acceptance process](/contribute/patch-acceptance).
+[patch acceptance process](/versions/6.5.0/contribute/patch-acceptance).
 
 ## Bazel's code description {#code-description}
 
-Bazel has a large codebase with code in multiple locations. See the [codebase guide](/contribute/codebase) for more details.
+Bazel has a large codebase with code in multiple locations. See the [codebase guide](/versions/6.5.0/contribute/codebase) for more details.
 
 Bazel is organized as follows:
 
 *  Client code is in `src/main/cpp` and provides the command-line interface.
 *  Protocol buffers are in `src/main/protobuf`.
 *  Server code is in `src/main/java` and `src/test/java`.
-   *  Core code which is mostly composed of [SkyFrame](/reference/skyframe)
+   *  Core code which is mostly composed of [SkyFrame](/versions/6.5.0/reference/skyframe)
       and some utilities.
    *  Built-in rules are in `com.google.devtools.build.lib.rules` and in
      `com.google.devtools.build.lib.bazel.rules`. You might want to read about
-     the [Challenges of Writing Rules](/docs/rule-challenges) first.
+     the [Challenges of Writing Rules](/versions/6.5.0/docs/rule-challenges) first.
 *  Java native interfaces are in `src/main/native`.
 *  Various tooling for language support are described in the list in the
-   [compiling Bazel](/install/compile-source) section.
+   [compiling Bazel](/versions/6.5.0/install/compile-source) section.
 
 
 ### Searching Bazel's source code {#search-code}
@@ -78,4 +74,4 @@ To quickly search through Bazel's source code, use
 [Bazel Code Search](https://source.bazel.build/). You can navigate Bazel's
 repositories, branches, and files. You can also view history, diffs, and blame
 information. To learn more, see the
-[Bazel Code Search User Guide](/contribute/searching-codebase).
+[Bazel Code Search User Guide](/versions/6.5.0/contribute/searching-codebase).
diff --git a/versions/6.5.0/contribute/maintainers-guide.mdx b/versions/6.5.0/contribute/maintainers-guide.mdx
index fc543922..e1eca6b8 100644
--- a/versions/6.5.0/contribute/maintainers-guide.mdx
+++ b/versions/6.5.0/contribute/maintainers-guide.mdx
@@ -5,8 +5,7 @@ title: 'Guide for Bazel Maintainers'
 
 This is a guide for the maintainers of the Bazel open source project.
 
-If you are looking to contribute to Bazel, please read [Contributing to
-Bazel](/contribute) instead.
+If you are looking to contribute to Bazel, please read [Contributing to Bazel](/versions/6.5.0/contribute) instead.
 
 The objectives of this page are to:
 
@@ -15,7 +14,7 @@ The objectives of this page are to:
 1. Set expectations between the community contributors and the project
    maintainers.
 
-Bazel's [core group of contributors](/contribute/contribution-policy) has dedicated
+Bazel's [core group of contributors](/versions/6.5.0/contribute/contribution-policy) has dedicated
 subteams to manage aspects of the open source project. These are:
 
 * **Release Process**: Manage Bazel's release process.
@@ -36,10 +35,8 @@ repository.
 
 ## Lifecycle of an Issue {#lifecycle-issue}
 
-1. A user creates an issue using the [Issue
-   Template](https://github.com/bazelbuild/bazel/blob/master/ISSUE_TEMPLATE.md)
-   and it enters the pool of [unreviewed open
-   issues](https://github.com/bazelbuild/bazel/issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aopen+-label%3Auntriaged+-label%3Ap2+-label%3Ap1+-label%3Ap3+-label%3Ap4+-label%3Ateam-Starlark+-label%3Ateam-Rules-CPP+-label%3Ateam-Rules-Java+-label%3Ateam-XProduct+-label%3Ateam-Android+-label%3Ateam-Apple+-label%3Ateam-Configurability++-label%3Ateam-Performance+-label%3Ateam-Rules-Server+-label%3Ateam-Core+-label%3Ateam-Rules-Python+-label%3Ateam-Remote-Exec+-label%3Ateam-Local-Exec+-label%3Ateam-Bazel).
+1. A user creates an issue using the [Issue Template](https://github.com/bazelbuild/bazel/blob/master/ISSUE_TEMPLATE.md)
+   and it enters the pool of [unreviewed open issues](https://github.com/bazelbuild/bazel/issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aopen+-label%3Auntriaged+-label%3Ap2+-label%3Ap1+-label%3Ap3+-label%3Ap4+-label%3Ateam-Starlark+-label%3Ateam-Rules-CPP+-label%3Ateam-Rules-Java+-label%3Ateam-XProduct+-label%3Ateam-Android+-label%3Ateam-Apple+-label%3Ateam-Configurability++-label%3Ateam-Performance+-label%3Ateam-Rules-Server+-label%3Ateam-Core+-label%3Ateam-Rules-Python+-label%3Ateam-Remote-Exec+-label%3Ateam-Local-Exec+-label%3Ateam-Bazel).
 1. A member on the Developer Experience (DevEx) subteam rotation reviews the
    issue.
    1. If the issue is **not a bug** or a **feature request**, the DevEx member
@@ -53,24 +50,20 @@ repository.
       to the correct repository.
    1. If the issue is vague or has missing information, the DevEx member will
       assign the issue back to the user to request for more information before
-      continuing. This usually occurs when the user does not follow the [Issue
-      Template](https://github.com/bazelbuild/bazel/blob/master/ISSUE_TEMPLATE.md).
+      continuing. This usually occurs when the user does not follow the [Issue Template](https://github.com/bazelbuild/bazel/blob/master/ISSUE_TEMPLATE.md).
 1. After reviewing the issue, the DevEx member decides if the issue requires
    immediate attention. If it does, they will assign the **P0**
    [priority](#priority) label and an owner from the list of team leads.
-1. The DevEx member assigns the `untriaged` label and exactly one [team
-   label](#team-labels) for routing.
+1. The DevEx member assigns the `untriaged` label and exactly one [team label](#team-labels) for routing.
 1. The DevEx member also assigns exactly one `type:` label, such as `type: bug`
    or `type: feature request`, according to the type of the issue.
 1. For platform-specific issues, the DevEx member assigns one `platform:` label,
    such as `platform:apple` for Mac-specific issues.
-At this stage, the issue enters the pool of [untriaged open
-issues](https://github.com/bazelbuild/bazel/issues?q=is%3Aissue+is%3Aopen+label%3Auntriaged).
+At this stage, the issue enters the pool of [untriaged open issues](https://github.com/bazelbuild/bazel/issues?q=is%3Aissue+is%3Aopen+label%3Auntriaged).
 
 Each Bazel subteam will triage all issues under labels they own, preferably on a
 weekly basis. The subteam will review and evaluate the issue and provide a
-resolution, if possible. If you are an owner of a team label, see [this section
-](#label-own) for more information.
+resolution, if possible. If you are an owner of a team label, see [this section](#label-own) for more information.
 
 When an issue is resolved, it can be closed.
 
@@ -110,8 +103,7 @@ preferably on a weekly basis.
      issue is either P0 or P1 we assume that is actively worked on.
 1. Remove the `untriaged` label.
 
-Note that you need to be in the [bazelbuild
-organization](https://github.com/bazelbuild) to be able to add or remove labels.
+Note that you need to be in the [bazelbuild organization](https://github.com/bazelbuild) to be able to add or remove labels.
 
 ### Pull Requests {#pull-requests}
 
@@ -137,8 +129,7 @@ issues.
   unusable, or a downed service that severely impacts development of the Bazel
   project. This includes regressions introduced in a new release that blocks a
   significant number of users, or an incompatible breaking change that was not
-  compliant to the [Breaking
-  Change](https://docs.google.com/document/d/1q5GGRxKrF_mnwtaPKI487P8OdDRh2nN7jX6U-FXnHL0/edit?pli=1#heading=h.ceof6vpkb3ik)
+  compliant to the [Breaking Change](https://docs.google.com/document/d/1q5GGRxKrF_mnwtaPKI487P8OdDRh2nN7jX6U-FXnHL0/edit?pli=1#heading=h.ceof6vpkb3ik)
   policy. No practical workaround exists.
 * [**P1**](https://github.com/bazelbuild/bazel/labels/P1) - Critical defect or
   feature which should be addressed in the next release, or a serious issue that
diff --git a/versions/6.5.0/contribute/naming.mdx b/versions/6.5.0/contribute/naming.mdx
index acb37a2c..da8ff3da 100644
--- a/versions/6.5.0/contribute/naming.mdx
+++ b/versions/6.5.0/contribute/naming.mdx
@@ -5,15 +5,14 @@ title: 'Naming a Bazel related project'
 
 First, thank you for contributing to the Bazel ecosystem! Please reach out to
 the Bazel community on the
-[bazel-discuss mailing list](https://groups.google.com/forum/#!forum/bazel-discuss
-) to share your project and its suggested name.
+[bazel-discuss mailing list](https://groups.google.com/forum/#!forum/bazel-discuss) to share your project and its suggested name.
 
 If you are building a Bazel related tool or sharing your Skylark rules,
 we recommend following these guidelines for the name of your project:
 
 ## Naming Starlark rules {#name-starlark-rules}
 
-See [Deploying new Starlark rules](/rules/deploying)
+See [Deploying new Starlark rules](/versions/6.5.0/rules/deploying)
 in the docs.
 
 ## Naming other Bazel related tools {#name-related-tools}
diff --git a/versions/6.5.0/contribute/patch-acceptance.mdx b/versions/6.5.0/contribute/patch-acceptance.mdx
index ad95245d..d3a4e9fb 100644
--- a/versions/6.5.0/contribute/patch-acceptance.mdx
+++ b/versions/6.5.0/contribute/patch-acceptance.mdx
@@ -6,25 +6,22 @@ title: 'Patch Acceptance Process'
 This page outlines how contributors can propose and make changes to the Bazel
 code base.
 
-1. Read the [Bazel Contribution policy](/contribute/contribution-policy).
+1. Read the [Bazel Contribution policy](/versions/6.5.0/contribute/contribution-policy).
 1. Create a [GitHub issue](https://github.com/bazelbuild/bazel/) to
    discuss your plan and design. Pull requests that change or add behavior
    need a corresponding issue for tracking.
 1. If you're proposing significant changes, write a
-   [design document](/contribute/design-documents).
-1. Ensure you've signed a [Contributor License
-   Agreement](https://cla.developers.google.com).
+   [design document](/versions/6.5.0/contribute/design-documents).
+1. Ensure you've signed a [Contributor License Agreement](https://cla.developers.google.com).
 1. Prepare a git commit that implements the feature. Don't forget to add tests
    and update the documentation. If your change has user-visible effects, please
-   [add release notes](/contribute/release-notes). If it is an incompatible change,
-   read the [guide for rolling out breaking changes](/contribute/breaking-changes).
+   [add release notes](/versions/6.5.0/contribute/release-notes). If it is an incompatible change,
+   read the [guide for rolling out breaking changes](/versions/6.5.0/contribute/breaking-changes).
 1. Create a pull request on
    [GitHub](https://github.com/bazelbuild/bazel/pulls). If you're new to GitHub,
-   read [about pull
-   requests](https://help.github.com/articles/about-pull-requests/). Note that
+   read [about pull requests](https://help.github.com/articles/about-pull-requests/). Note that
    we restrict permissions to create branches on the main Bazel repository, so
-   you will need to push your commit to [your own fork of the
-   repository](https://help.github.com/articles/working-with-forks/).
+   you will need to push your commit to [your own fork of the repository](https://help.github.com/articles/working-with-forks/).
 1. A Bazel maintainer should assign you a reviewer within two business days
    (excluding holidays in the USA and Germany). If you aren't assigned a
    reviewer in that time, you can request one by emailing
diff --git a/versions/6.5.0/contribute/policy.mdx b/versions/6.5.0/contribute/policy.mdx
index 1936c4e1..3fc4a0ba 100644
--- a/versions/6.5.0/contribute/policy.mdx
+++ b/versions/6.5.0/contribute/policy.mdx
@@ -60,7 +60,7 @@ contribution policies for Google-managed and Community-managed areas of code.
     *   Discussed and approved by the Maintainers of the relevant area of code.
         Discussions and approvals happen on GitHub Issues and in GitHub PRs.
         Larger contributions require a
-        [design review](/contribute/design-documents).
+        [design review](/versions/6.5.0/contribute/design-documents).
     *   Added to Bazel's Continuous Integration system if not already present.
     *   Supportable and aligned with Bazel product direction
 *   **Code review**. All changes in all `bazelbuild` repositories require
@@ -74,4 +74,4 @@ contribution policies for Google-managed and Community-managed areas of code.
     documentation updates.
 
 For more details on contributing to Bazel, see our
-[contribution guidelines](/contribute/).
+[contribution guidelines](/versions/6.5.0/contribute/).
diff --git a/versions/6.5.0/contribute/release-notes.mdx b/versions/6.5.0/contribute/release-notes.mdx
index 4d868471..0fbaba8e 100644
--- a/versions/6.5.0/contribute/release-notes.mdx
+++ b/versions/6.5.0/contribute/release-notes.mdx
@@ -17,8 +17,7 @@ the release announcement.
 * If the change adds / removes / changes Bazel in a user-visible way, then it
   may be advantageous to mention it.
 
-If the change is significant, follow the [design document
-policy](/contribute/design-documents) first.
+If the change is significant, follow the [design document policy](/versions/6.5.0/contribute/design-documents) first.
 
 ## Guidelines {#guidelines}
 
@@ -61,10 +60,8 @@ change is about.
 
 ## Process {#process}
 
-As part of the [release
-process](https://github.com/bazelbuild/continuous-integration/blob/master/docs/release-playbook.md),
-we collect the `RELNOTES` tags of every commit. We copy everything in a [Google
-Doc](https://docs.google.com/document/d/1wDvulLlj4NAlPZamdlEVFORks3YXJonCjyuQMUQEmB0/edit)
+As part of the [release process](https://github.com/bazelbuild/continuous-integration/blob/master/docs/release-playbook.md),
+we collect the `RELNOTES` tags of every commit. We copy everything in a [Google Doc](https://docs.google.com/document/d/1wDvulLlj4NAlPZamdlEVFORks3YXJonCjyuQMUQEmB0/edit)
 where we review, edit, and organize the notes.
 
 The release manager sends an email to the
@@ -72,6 +69,4 @@ The release manager sends an email to the
 Bazel contributors are invited to contribute to the document and make sure
 their changes are correctly reflected in the announcement.
 
-Later, the announcement will be submitted to the [Bazel
-blog](https://blog.bazel.build/), using the [bazel-blog
-repository](https://github.com/bazelbuild/bazel-blog/tree/master/_posts).
+Later, the announcement will be submitted to the [Bazel blog](https://blog.bazel.build/), using the [bazel-blog repository](https://github.com/bazelbuild/bazel-blog/tree/master/_posts).
diff --git a/versions/6.5.0/docs/android-build-performance.mdx b/versions/6.5.0/docs/android-build-performance.mdx
index 8dc3c8e6..bb0b6491 100644
--- a/versions/6.5.0/docs/android-build-performance.mdx
+++ b/versions/6.5.0/docs/android-build-performance.mdx
@@ -5,12 +5,12 @@ title: 'Android Build Performance'
 
 This page contains information on optimizing build performance for Android
 apps specifically. For general build performance optimization with Bazel, see
-[Optimizing Performance](/rules/performance).
+[Optimizing Performance](/versions/6.5.0/rules/performance).
 
 ## Recommended flags {#recommended-flags}
 
 The flags are in the
-[`bazelrc` configuration syntax](/docs/bazelrc#bazelrc-syntax-semantics), so
+[`bazelrc` configuration syntax](/versions/6.5.0/docs/bazelrc#bazelrc-syntax-semantics), so
 they can be pasted directly into a `bazelrc` file and invoked with
 `--config=` on the command line.
 
@@ -18,7 +18,7 @@ they can be pasted directly into a `bazelrc` file and invoked with
 
 Bazel writes a JSON trace profile by default to a file called
 `command.profile.gz` in Bazel's output base.
-See the [JSON Profile documentation](/rules/performance#performance-profiling) for
+See the [JSON Profile documentation](/versions/6.5.0/rules/performance#performance-profiling) for
 how to read and interact with the profile.
 
 **Persistent workers for Android build actions**.
diff --git a/versions/6.5.0/docs/android-instrumentation-test.mdx b/versions/6.5.0/docs/android-instrumentation-test.mdx
index 56fa623b..8850f0e1 100644
--- a/versions/6.5.0/docs/android-instrumentation-test.mdx
+++ b/versions/6.5.0/docs/android-instrumentation-test.mdx
@@ -3,14 +3,13 @@ title: 'Android Instrumentation Tests'
 ---
 
 
-_If you're new to Bazel, start with the [Building Android with
-Bazel](/tutorials/android-app) tutorial._
+_If you're new to Bazel, start with the [Building Android with Bazel](/versions/6.5.0/tutorials/android-app) tutorial._
 
-![Running Android instrumentation tests in parallel](/docs/images/android_test.gif "Android instrumentation test")
+![Running Android instrumentation tests in parallel](/versions/6.5.0/docs/images/android_test.gif "Android instrumentation test")
 
 **Figure 1.** Running parallel Android instrumentation tests.
 
-[`android_instrumentation_test`](/reference/be/android#android_instrumentation_test)
+[`android_instrumentation_test`](/versions/6.5.0/reference/be/android#android_instrumentation_test)
 allows developers to test their apps on Android emulators and devices.
 It utilizes real Android framework APIs and the Android Test Library.
 
@@ -19,9 +18,7 @@ emulators in a sandbox, ensuring that tests always run from a clean state. Each
 test gets an isolated emulator instance, allowing tests to run in parallel
 without passing states between them.
 
-For more information on Android instrumentation tests, check out the [Android
-developer
-documentation](https://developer.android.com/training/testing/unit-testing/instrumented-unit-tests.html).
+For more information on Android instrumentation tests, check out the [Android developer documentation](https://developer.android.com/training/testing/unit-testing/instrumented-unit-tests.html).
 
 Please file issues in the [GitHub issue tracker](https://github.com/bazelbuild/bazel/issues).
 
@@ -59,8 +56,7 @@ This results in output similar to the following:
 release 4.1.0
 ```
 
-- **KVM**. Bazel requires emulators to have [hardware
-  acceleration](https://developer.android.com/studio/run/emulator-acceleration.html#accel-check)
+- **KVM**. Bazel requires emulators to have [hardware acceleration](https://developer.android.com/studio/run/emulator-acceleration.html#accel-check)
   with KVM on Linux. You can follow these
   [installation instructions](https://help.ubuntu.com/community/KVM/Installation)
   for Ubuntu.
@@ -110,7 +106,7 @@ sudo apt-get install libc6:i386 libncurses5:i386 libstdc++6:i386 lib32z1 libbz2-
 
 Here is a typical target dependency graph of an `android_instrumentation_test`:
 
-![The target dependency graph on an Android instrumentation test](/docs/images/android_instrumentation_test.png "Target dependency graph")
+![The target dependency graph on an Android instrumentation test](/versions/6.5.0/docs/images/android_instrumentation_test.png "Target dependency graph")
 
 **Figure 2.** Target dependency graph of an `android_instrumentation_test`.
 
@@ -175,11 +171,9 @@ The main attributes of the rule `android_instrumentation_test` are:
 
 - `target_device`: An `android_device` target. This target describes the
   specifications of the Android emulator which Bazel uses to create, launch and
-  run the tests. See the [section on choosing an Android
-  device](#android-device-target) for more information.
+  run the tests. See the [section on choosing an Android device](#android-device-target) for more information.
 
-The test app's `AndroidManifest.xml` must include [an ``
-tag](https://developer.android.com/studio/test/#configure_instrumentation_manifest_settings).
+The test app's `AndroidManifest.xml` must include [an `` tag](https://developer.android.com/studio/test/#configure_instrumentation_manifest_settings).
 This tag must specify the attributes for the **package of the target app** and
 the **fully qualified class name of the instrumentation test runner**,
 `androidx.test.runner.AndroidJUnitRunner`.
@@ -216,8 +210,7 @@ repositories:
 - `@androidsdk`: The Android SDK. Download this through Android Studio.
 
 - `@android_test_support`: Hosts the test runner, emulator launcher, and
-  `android_device` targets. You can find the [latest release
-  here](https://github.com/android/android-test/releases).
+  `android_device` targets. You can find the [latest release here](https://github.com/android/android-test/releases).
 
 Enable these dependencies by adding the following lines to your `WORKSPACE`
 file:
@@ -242,8 +235,7 @@ android_test_repositories()
 
 ## Maven dependencies {#maven-dependencies}
 
-For managing dependencies on Maven artifacts from repositories, such as [Google
-Maven](https://maven.google.com) or [Maven Central](https://central.maven.org),
+For managing dependencies on Maven artifacts from repositories, such as [Google Maven](https://maven.google.com) or [Maven Central](https://central.maven.org),
 you should use a Maven resolver, such as
 [`rules_jvm_external`](https://github.com/bazelbuild/rules_jvm_external).
 
@@ -372,8 +364,7 @@ the device/emulator listed in `adb devices`.
 
 ## Sample projects {#sample-projects}
 
-If you are looking for canonical project samples, see the [Android testing
-samples](https://github.com/googlesamples/android-testing#experimental-bazel-support)
+If you are looking for canonical project samples, see the [Android testing samples](https://github.com/googlesamples/android-testing#experimental-bazel-support)
 for projects using Espresso and UIAutomator.
 
 ## Espresso setup {#espresso-setup}
@@ -562,8 +553,7 @@ API_LEVELS = [
 
 ## Known issues {#known-issues}
 
-- [Forked adb server processes are not terminated after
-  tests](https://github.com/bazelbuild/bazel/issues/4853)
+- [Forked adb server processes are not terminated after tests](https://github.com/bazelbuild/bazel/issues/4853)
 - While APK building works on all platforms (Linux, macOS, Windows), testing
   only works on Linux.
 - Even with `--config=local_adb`, users still need to specify
diff --git a/versions/6.5.0/docs/android-ndk.mdx b/versions/6.5.0/docs/android-ndk.mdx
index 5fa7e2f6..36cc767c 100644
--- a/versions/6.5.0/docs/android-ndk.mdx
+++ b/versions/6.5.0/docs/android-ndk.mdx
@@ -3,8 +3,7 @@ title: 'Using the Android Native Development Kit with Bazel'
 ---
 
 
-_If you're new to Bazel, please start with the [Building Android with
-Bazel](/tutorials/android-app) tutorial._
+_If you're new to Bazel, please start with the [Building Android with Bazel](/versions/6.5.0/tutorials/android-app) tutorial._
 
 ## Overview {#overview}
 
@@ -32,8 +31,7 @@ android_ndk_repository(
 )
 ```
 
-For more information on the `android_ndk_repository` rule, see the [Build
-Encyclopedia entry](/reference/be/android#android_ndk_repository).
+For more information on the `android_ndk_repository` rule, see the [Build Encyclopedia entry](/versions/6.5.0/reference/be/android#android_ndk_repository).
 
 ## Quick start {#quick-start}
 
@@ -68,7 +66,7 @@ android_binary(
 
 This `BUILD` file results in the following target graph:
 
-![Example results](/docs/images/android_ndk.png "Build graph results")
+![Example results](/versions/6.5.0/docs/images/android_ndk.png "Build graph results")
 
 **Figure 1.** Build graph of Android project with cc_library dependencies.
 
@@ -97,13 +95,11 @@ META-INF/MANIFEST.MF
 
 Bazel compiles all of the cc_libraries into a single shared object (`.so`) file,
 targeted for the `armeabi-v7a` ABI by default. To change this or build for
-multiple ABIs at the same time, see the section on [configuring the target
-ABI](#configuring-target-abi).
+multiple ABIs at the same time, see the section on [configuring the target ABI](#configuring-target-abi).
 
 ## Example setup {#example-setup}
 
-This example is available in the [Bazel examples
-repository](https://github.com/bazelbuild/examples/tree/master/android/ndk).
+This example is available in the [Bazel examples repository](https://github.com/bazelbuild/examples/tree/master/android/ndk).
 
 In the `BUILD.bazel` file, three targets are defined with the `android_binary`,
 `android_library`, and `cc_library` rules.
@@ -174,12 +170,10 @@ For r16 and below, the default STL is `gnustl`. For r17 and above, it is
 `libc++`. For convenience, the target `@androidndk//:default_crosstool` is
 aliased to the respective default STLs.
 
-Please note that from r18 onwards, [STLport and gnustl will be
-removed](https://android.googlesource.com/platform/ndk/+/master/docs/Roadmap.md#ndk-r18),
+Please note that from r18 onwards, [STLport and gnustl will be removed](https://android.googlesource.com/platform/ndk/+/master/docs/Roadmap.md#ndk-r18),
 making `libc++` the only STL in the NDK.
 
-See the [NDK
-documentation](https://developer.android.com/ndk/guides/cpp-support)
+See the [NDK documentation](https://developer.android.com/ndk/guides/cpp-support)
 for more information on these STLs.
 
 ## Configuring the target ABI {#configuring-target-abi}
@@ -228,7 +222,7 @@ bazel build //:app --cxxopt=-std=c++11
 ```
 
 Read more about passing compiler and linker flags with `--cxxopt`, `--copt`, and
-`--linkopt` in the [User Manual](/docs/user-manual#cxxopt).
+`--linkopt` in the [User Manual](/versions/6.5.0/docs/user-manual#cxxopt).
 
 Compiler and linker flags can also be specified as attributes in `cc_library`
 using `copts` and `linkopts`. For example:
@@ -245,8 +239,8 @@ cc_library(
 ## Integration with platforms and toolchains
 
 Bazel's configuration model is moving towards
-[platforms](/docs/platforms) and
-[toolchains](/docs/toolchains). If your
+[platforms](/versions/6.5.0/docs/platforms) and
+[toolchains](/versions/6.5.0/docs/toolchains). If your
 build uses the `--platforms` flag to select for the architecture or operating system
 to build for, you will need to pass the `--extra_toolchains` flag to Bazel in
 order to use the NDK.
@@ -320,8 +314,7 @@ an Android-compatible configuration so that the Bazel build *just works* without
 any special flags, except for `--fat_apk_cpu` and `--android_crosstool_top` for
 ABI and STL configuration.
 
-Behind the scenes, this automatic configuration uses Android [configuration
-transitions](/rules/rules#configurations).
+Behind the scenes, this automatic configuration uses Android [configuration transitions](/versions/6.5.0/rules/rules#configurations).
 
 A compatible rule, like `android_binary`, automatically changes the
 configuration of its dependencies to an Android configuration, so only
@@ -386,7 +379,7 @@ With this approach, the entire build tree is affected.
 
 Note: All of the targets on the command line must be compatible with
 building for Android when specifying these flags, which may make it difficult to
-use [Bazel wild-cards](/docs/build#specifying-build-targets) like
+use [Bazel wild-cards](/versions/6.5.0/docs/build#specifying-build-targets) like
 `/...` and `:all`.
 
 These flags can be put into a `bazelrc` config (one for each ABI), in
diff --git a/versions/6.5.0/docs/bazel-and-android.mdx b/versions/6.5.0/docs/bazel-and-android.mdx
index e325386e..5fb6eef4 100644
--- a/versions/6.5.0/docs/bazel-and-android.mdx
+++ b/versions/6.5.0/docs/bazel-and-android.mdx
@@ -11,7 +11,7 @@ Android projects with Bazel.
 
 The following resources will help you work with Bazel on Android projects:
 
-*  [Tutorial: Building an Android app](/tutorials/android-app). This
+*  [Tutorial: Building an Android app](/versions/6.5.0/tutorials/android-app). This
    tutorial is a good place to start learning about Bazel commands and concepts,
    and how to build Android apps with Bazel.
 *  [Codelab: Building Android Apps with Bazel](https://developer.android.com/codelabs/bazel-android-intro#0).
@@ -23,19 +23,19 @@ Bazel has Android rules for building and testing Android apps, integrating with
 the SDK/NDK, and creating emulator images. There are also Bazel plugins for
 Android Studio and IntelliJ.
 
-*  [Android rules](/reference/be/android). The Build Encyclopedia describes the rules
+*  [Android rules](/versions/6.5.0/reference/be/android). The Build Encyclopedia describes the rules
    for building and testing Android apps with Bazel.
-*  [Integration with Android Studio](/install/ide). Bazel is compatible with
+*  [Integration with Android Studio](/versions/6.5.0/install/ide). Bazel is compatible with
    Android Studio using the [Android Studio with Bazel](https://ij.bazel.build/)
    plugin.
-*  [`mobile-install` for Android](/docs/mobile-install). Bazel's `mobile-install`
+*  [`mobile-install` for Android](/versions/6.5.0/docs/mobile-install). Bazel's `mobile-install`
    feature provides automated build-and-deploy functionality for building and
    testing Android apps directly on Android devices and emulators.
-*  [Android instrumentation testing](/docs/android-instrumentation-test) on
+*  [Android instrumentation testing](/versions/6.5.0/docs/android-instrumentation-test) on
    emulators and devices.
-*  [Android NDK integration](/docs/android-ndk). Bazel supports compiling to
+*  [Android NDK integration](/versions/6.5.0/docs/android-ndk). Bazel supports compiling to
    native code through direct NDK integration and the C++ rules.
-*  [Android build performance](/docs/android-build-performance). This page
+*  [Android build performance](/versions/6.5.0/docs/android-build-performance). This page
    provides information on optimizing build performance for Android apps.
 
 ## Further reading {#further-reading}
diff --git a/versions/6.5.0/docs/bazel-and-apple.mdx b/versions/6.5.0/docs/bazel-and-apple.mdx
index fa4a05fb..62fe8dfb 100644
--- a/versions/6.5.0/docs/bazel-and-apple.mdx
+++ b/versions/6.5.0/docs/bazel-and-apple.mdx
@@ -11,17 +11,17 @@ using Bazel to build and test for those platforms.
 
 The following resources will help you work with Bazel on macOS and iOS projects:
 
-*  [Tutorial: Building an iOS app](/tutorials/ios-app)
-*  [Objective-C build rules](/reference/be/objective-c)
+*  [Tutorial: Building an iOS app](/versions/6.5.0/tutorials/ios-app)
+*  [Objective-C build rules](/versions/6.5.0/reference/be/objective-c)
 *  [General Apple rules](https://github.com/bazelbuild/rules_apple)
-*  [Integration with Xcode](/install/ide)
+*  [Integration with Xcode](/versions/6.5.0/install/ide)
 
 ## Migrating to Bazel {#migrating-to-bazel}
 
 If you currently build your macOS and iOS projects with Xcode, follow the steps
 in the migration guide to start building them with Bazel:
 
-*  [Migrating from Xcode to Bazel](/migrate/xcode)
+*  [Migrating from Xcode to Bazel](/versions/6.5.0/migrate/xcode)
 
 ## Apple apps and new rules {#apple-apps-new-rules}
 
@@ -29,25 +29,25 @@ in the migration guide to start building them with Bazel:
 You do not need it when getting started with Bazel.
 
 The following modules, configuration fragments, and providers will help you
-[extend Bazel's capabilities](/rules/concepts)
+[extend Bazel's capabilities](/versions/6.5.0/rules/concepts)
 when building your macOS and iOS projects:
 
 *  Modules:
 
-   *  [`apple_bitcode_mode`](/rules/lib/apple_bitcode_mode)
-   *  [`apple_common`](/rules/lib/apple_common)
-   *  [`apple_platform`](/rules/lib/apple_platform)
-   *  [`apple_platform_type`](/rules/lib/apple_platform_type)
-   *  [`apple_toolchain`](/rules/lib/apple_toolchain)
-   *  [`XcodeVersionConfig`](/rules/lib/XcodeVersionConfig)
+   *  [`apple_bitcode_mode`](/versions/6.5.0/rules/lib/builtins/apple_bitcode_mode)
+   *  [`apple_common`](/versions/6.5.0/rules/lib/toplevel/apple_common)
+   *  [`apple_platform`](/versions/6.5.0/rules/lib/builtins/apple_platform)
+   *  [`apple_platform_type`](/versions/6.5.0/rules/lib/builtins/apple_platform_type)
+   *  [`apple_toolchain`](/versions/6.5.0/rules/lib/builtins/apple_toolchain)
+   *  [`XcodeVersionConfig`](/versions/6.5.0/rules/lib/providers/XcodeVersionConfig)
 
 *  Configuration fragments:
 
-   *  [`apple`](/rules/lib/apple)
+   *  [`apple`](/versions/6.5.0/rules/lib/fragments/apple)
 
 *  Providers:
 
-   *  [`ObjcProvider`](/rules/lib/ObjcProvider)
+   *  [`ObjcProvider`](/versions/6.5.0/rules/lib/providers/ObjcProvider)
 
 ## Xcode selection {#xcode-selection}
 
@@ -59,24 +59,24 @@ the set of available Xcode versions and sets a default version if
 represented in the `--xcode_config` target.
 
 If you do not pass `--xcode_config`, Bazel will use the autogenerated
-[`XcodeVersionConfig`](/rules/lib/XcodeVersionConfig) that represents the
+[`XcodeVersionConfig`](/versions/6.5.0/rules/lib/providers/XcodeVersionConfig) that represents the
 Xcode versions available on your host machine. The default version is
 the newest available Xcode version. This is appropriate for local execution.
 
 If you are performing remote builds, you should set `--xcode_config` to an
-[`xcode_config`](/reference/be/objective-c#xcode_config)
+[`xcode_config`](/versions/6.5.0/reference/be/objective-c#xcode_config)
 target whose `versions` attribute is a list of remotely available
-[`xcode_version`](/reference/be/objective-c#xcode_version)
+[`xcode_version`](/versions/6.5.0/reference/be/objective-c#xcode_version)
 targets, and whose `default` attribute is one of these
-[`xcode_versions`](/reference/be/objective-c#xcode_version).
+[`xcode_versions`](/versions/6.5.0/reference/be/objective-c#xcode_version).
 
 If you are using dynamic execution, you should set `--xcode_config` to an
-[`xcode_config`](/reference/be/objective-c#xcode_config)
+[`xcode_config`](/versions/6.5.0/reference/be/objective-c#xcode_config)
 target whose `remote_versions` attribute is an
-[`available_xcodes`](/reference/be/workspace#available_xcodes)
+[`available_xcodes`](/versions/6.5.0/reference/be/workspace#available_xcodes)
 target containing the remotely available Xcode versions, and whose
 `local_versions` attribute is an
-[`available_xcodes`](/reference/be/workspace#available_xcodes)
+[`available_xcodes`](/versions/6.5.0/reference/be/workspace#available_xcodes)
 target containing the locally available Xcode versions. For `local_versions`,
 you probably want to use the autogenerated
 `@local_config_xcode//:host_available_xcodes`. The default Xcode version is the
diff --git a/versions/6.5.0/docs/bazel-and-cpp.mdx b/versions/6.5.0/docs/bazel-and-cpp.mdx
index 4c93fa8f..555d91a8 100644
--- a/versions/6.5.0/docs/bazel-and-cpp.mdx
+++ b/versions/6.5.0/docs/bazel-and-cpp.mdx
@@ -11,23 +11,23 @@ projects with Bazel.
 
 The following resources will help you work with Bazel on C++ projects:
 
-*  [Tutorial: Building a C++ project](/tutorials/cpp)
-*  [C++ common use cases](/tutorials/cpp-use-cases)
-*  [C/C++ rules](/reference/be/c-cpp)
-*  [C++ toolchain configuration](/docs/cc-toolchain-config-reference)
-*  [Tutorial: Configuring C++ toolchains](/tutorials/cc-toolchain-config)
-*  [Integrating with C++ rules](/docs/integrating-with-rules-cc)
+*  [Tutorial: Building a C++ project](/versions/6.5.0/tutorials/cpp)
+*  [C++ common use cases](/versions/6.5.0/tutorials/cpp-use-cases)
+*  [C/C++ rules](/versions/6.5.0/reference/be/c-cpp)
+*  [C++ toolchain configuration](/versions/6.5.0/docs/cc-toolchain-config-reference)
+*  [Tutorial: Configuring C++ toolchains](/versions/6.5.0/tutorials/cc-toolchain-config)
+*  [Integrating with C++ rules](/versions/6.5.0/docs/integrating-with-rules-cc)
 
 ## Best practices {#best-practices}
 
-In addition to [general Bazel best practices](/docs/best-practices), below are
+In addition to [general Bazel best practices](/versions/6.5.0/docs/best-practices), below are
 best practices specific to C++ projects.
 
 ### BUILD files {#build-files}
 
 Follow the guidelines below when creating your BUILD files:
 
-*  Each `BUILD` file should contain one [`cc_library`](/reference/be/c-cpp#cc_library)
+*  Each `BUILD` file should contain one [`cc_library`](/versions/6.5.0/reference/be/c-cpp#cc_library)
    rule target per compilation unit in the directory.
 
 *  You should granularize your C++ libraries as much as
@@ -73,6 +73,6 @@ Follow these guidelines for include paths:
 
 *  For legacy or `third_party` code that requires includes pointing outside the
    project repository, such as external repository includes requiring a prefix,
-   use the [`include_prefix`](/reference/be/c-cpp#cc_library.include_prefix) and
-   [`strip_include_prefix`](/reference/be/c-cpp#cc_library.strip_include_prefix)
+   use the [`include_prefix`](/versions/6.5.0/reference/be/c-cpp#cc_library.include_prefix) and
+   [`strip_include_prefix`](/versions/6.5.0/reference/be/c-cpp#cc_library.strip_include_prefix)
    arguments on the `cc_library` rule target.
diff --git a/versions/6.5.0/docs/bazel-and-java.mdx b/versions/6.5.0/docs/bazel-and-java.mdx
index 0880d2ca..3191dbc0 100644
--- a/versions/6.5.0/docs/bazel-and-java.mdx
+++ b/versions/6.5.0/docs/bazel-and-java.mdx
@@ -11,15 +11,15 @@ Java projects with Bazel.
 
 The following resources will help you work with Bazel on Java projects:
 
-*   [Tutorial: Building a Java Project](/tutorials/java)
-*   [Java rules](/reference/be/java)
+*   [Tutorial: Building a Java Project](/versions/6.5.0/tutorials/java)
+*   [Java rules](/versions/6.5.0/reference/be/java)
 
 ## Migrating to Bazel {#migrating-to-bazel}
 
 If you currently build your Java projects with Maven, follow the steps in the
 migration guide to start building your Maven projects with Bazel:
 
-*   [Migrating from Maven to Bazel](/migrate/maven)
+*   [Migrating from Maven to Bazel](/versions/6.5.0/migrate/maven)
 
 ## Java versions {#java-versions}
 
@@ -37,7 +37,7 @@ sources in the repository add `build --java_language_version={ver}` to
 `.bazelrc` file, where `{ver}` is for example `11`. Bazel repository owners
 should set this flag so that Bazel and its users can reference the source code's
 Java version number. For more details, see
-[Java language version flag](/docs/user-manual#java-language-version).
+[Java language version flag](/versions/6.5.0/docs/user-manual#java-language-version).
 
 ### Configuring the JVM used to execute and test the code {#config-jvm}
 
@@ -59,7 +59,7 @@ flag. The default value is `local_jdk`.
 To create a hermetic compile, you can use command line flag
 `--java_runtime_version=remotejdk_11`. The code is compiled for, executed, and
 tested on the JVM downloaded from a remote repository. For more details, see
-[Java runtime version flag](/docs/user-manual#java_runtime_version).
+[Java runtime version flag](/versions/6.5.0/docs/user-manual#java_runtime_version).
 
 ### Configuring compilation and execution of build tools in Java {#config-build-tools-java}
 
@@ -84,7 +84,7 @@ For more details, see
 
 ## Best practices {#best-practices}
 
-In addition to [general Bazel best practices](/docs/best-practices), below are
+In addition to [general Bazel best practices](/versions/6.5.0/docs/best-practices), below are
 best practices specific to Java projects.
 
 ### Directory structure {#directory-structure}
@@ -114,7 +114,7 @@ Follow these guidelines when creating your `BUILD` files:
     `BUILD` file. This makes the label of the library shorter, that is use
     `"//package"` instead of `"//package:package"`.
 
-*   The sources should be a non-recursive [`glob`](/reference/be/functions#glob) of
+*   The sources should be a non-recursive [`glob`](/versions/6.5.0/reference/be/functions#glob) of
     all Java files in the directory.
 
 *   Tests should be in a matching directory under `src/test` and depend on this
@@ -126,20 +126,20 @@ Follow these guidelines when creating your `BUILD` files:
 not need it when getting started with Bazel.
 
 The following modules, configuration fragments, and providers will help you
-[extend Bazel's capabilities](/rules/concepts) when building your Java
+[extend Bazel's capabilities](/versions/6.5.0/rules/concepts) when building your Java
 projects:
 
-*   Main Java provider: [`java_common`](/rules/lib/java_common)
-*   Main Java module: [`JavaInfo`](/rules/lib/JavaInfo)
-*   Configuration fragment: [`java`](/rules/lib/java)
+*   Main Java provider: [`java_common`](/versions/6.5.0/rules/lib/toplevel/java_common)
+*   Main Java module: [`JavaInfo`](/versions/6.5.0/rules/lib/providers/JavaInfo)
+*   Configuration fragment: [`java`](/versions/6.5.0/rules/lib/fragments/java)
 *   Other modules:
 
-    *   [`java_annotation_processing`](/rules/lib/java_annotation_processing)
-    *   [`java_compilation_info`](/rules/lib/java_compilation_info)
-    *   [`java_output`](/rules/lib/java_output)
-    *   [`java_output_jars`](/rules/lib/java_output_jars)
-    *   [`JavaRuntimeInfo`](/rules/lib/JavaRuntimeInfo)
-    *   [`JavaToolchainInfo`](/rules/lib/JavaToolchainInfo)
+    *   [`java_annotation_processing`](/versions/6.5.0/rules/lib/builtins/java_annotation_processing)
+    *   [`java_compilation_info`](/versions/6.5.0/rules/lib/providers/java_compilation_info)
+    *   [`java_output`](/versions/6.5.0/rules/lib/providers/java_output)
+    *   [`java_output_jars`](/versions/6.5.0/rules/lib/providers/java_output_jars)
+    *   [`JavaRuntimeInfo`](/versions/6.5.0/rules/lib/providers/JavaRuntimeInfo)
+    *   [`JavaToolchainInfo`](/versions/6.5.0/rules/lib/providers/JavaToolchainInfo)
 
 ## Configuring the Java toolchains {#config-java-toolchains}
 
@@ -233,7 +233,7 @@ The `TestRunner` tool executes JUnit 4 tests in a controlled environment.
 You can reconfigure the compilation by adding `default_java_toolchain` macro to
 a `BUILD` file and registering it either by adding `register_toolchains` rule to
 the `WORKSPACE` file or by using
-[`--extra_toolchains`](/docs/user-manual#extra-toolchains) flag.
+[`--extra_toolchains`](/versions/6.5.0/docs/user-manual#extra-toolchains) flag.
 
 The toolchain is only used when the `source_version` attribute matches the
 value specified by `--java_language_version` flag.
diff --git a/versions/6.5.0/docs/configurable-attributes.mdx b/versions/6.5.0/docs/configurable-attributes.mdx
index f3ca7de6..207ea97b 100644
--- a/versions/6.5.0/docs/configurable-attributes.mdx
+++ b/versions/6.5.0/docs/configurable-attributes.mdx
@@ -3,8 +3,7 @@ title: 'Configurable Build Attributes'
 ---
 
 
-**_Configurable attributes_**, commonly known as [`select()`](
-/reference/be/functions#select), is a Bazel feature that lets users toggle the values
+**_Configurable attributes_**, commonly known as [`select()`](/versions/6.5.0/reference/be/functions#select), is a Bazel feature that lets users toggle the values
 of build rule attributes at the command line.
 
 This can be used, for example, for a multiplatform library that automatically
@@ -67,7 +66,7 @@ command line. Specifically, `deps` becomes:
 
 
 `select()` serves as a placeholder for a value that will be chosen based on
-*configuration conditions*, which are labels referencing [`config_setting`](/reference/be/general#config_setting)
+*configuration conditions*, which are labels referencing [`config_setting`](/versions/6.5.0/reference/be/general#config_setting)
 targets. By using `select()` in a configurable attribute, the attribute
 effectively adopts different values when different conditions hold.
 
@@ -84,7 +83,7 @@ While this example uses `deps`, `select()` works just as well on `srcs`,
 `resources`, `cmd`, and most other attributes. Only a small number of attributes
 are *non-configurable*, and these are clearly annotated. For example,
 `config_setting`'s own
-[`values`](/reference/be/general#config_setting.values) attribute is non-configurable.
+[`values`](/versions/6.5.0/reference/be/general#config_setting.values) attribute is non-configurable.
 
 ## `select()` and dependencies {#select-and-dependencies}
 
@@ -92,7 +91,7 @@ Certain attributes change the build parameters for all transitive dependencies
 under a target. For example, `genrule`'s `tools` changes `--cpu` to the CPU of
 the machine running Bazel (which, thanks to cross-compilation, may be different
 than the CPU the target is built for). This is known as a
-[configuration transition](/reference/glossary#transition).
+[configuration transition](/versions/6.5.0/reference/glossary#transition).
 
 Given
 
@@ -145,8 +144,8 @@ build parameters, which include `--cpu=arm`. The `tools` attribute changes
 ## Configuration conditions {#configuration-conditions}
 
 Each key in a configurable attribute is a label reference to a
-[`config_setting`](/reference/be/general#config_setting) or
-[`constraint_value`](/reference/be/platform#constraint_value).
+[`config_setting`](/versions/6.5.0/reference/be/general#config_setting) or
+[`constraint_value`](/versions/6.5.0/reference/be/platform#constraint_value).
 
 `config_setting` is just a collection of
 expected command line flag settings. By encapsulating these in a target, it's
@@ -158,8 +157,8 @@ easy to maintain "standard" conditions users can reference from multiple places.
 
 Flags like `--cpu` are built into Bazel: the build tool natively understands
 them for all builds in all projects. These are specified with
-[`config_setting`](/reference/be/general#config_setting)'s
-[`values`](/reference/be/general#config_setting.values) attribute:
+[`config_setting`](/versions/6.5.0/reference/be/general#config_setting)'s
+[`values`](/versions/6.5.0/reference/be/general#config_setting.values) attribute:
 
 ```python
 config_setting(
@@ -183,7 +182,7 @@ is the expected value for that flag. `:meaningful_condition_name` matches if
 *  `values = { "force_pic": "0" }` matches `bazel build --noforce_pic`
 
 `config_setting` only supports flags that affect target behavior. For example,
-[`--show_progress`](/docs/user-manual#show-progress) isn't allowed because
+[`--show_progress`](/versions/6.5.0/docs/user-manual#show-progress) isn't allowed because
 it only affects how Bazel reports progress to the user. Targets can't use that
 flag to construct their results. The exact set of supported flags isn't
 documented. In practice, most flags that "make sense" work.
@@ -194,8 +193,8 @@ You can model your own project-specific flags with
 [Starlark build settings][BuildSettings]. Unlike built-in flags, these are
 defined as build targets, so Bazel references them with target labels.
 
-These are triggered with [`config_setting`](/reference/be/general#config_setting)'s
-[`flag_values`](/reference/be/general#config_setting.flag_values)
+These are triggered with [`config_setting`](/versions/6.5.0/reference/be/general#config_setting)'s
+[`flag_values`](/versions/6.5.0/reference/be/general#config_setting.flag_values)
 attribute:
 
 ```python
@@ -212,12 +211,12 @@ config_setting(
 Behavior is the same as for [built-in flags](#built-in-flags). See [here](https://github.com/bazelbuild/examples/tree/HEAD/configurations/select_on_build_setting)
 for a working example.
 
-[`--define`](/reference/command-line-reference#flag--define)
+[`--define`](/versions/6.5.0/reference/command-line-reference#flag--define)
 is an alternative legacy syntax for custom flags (for example
 `--define foo=bar`). This can be expressed either in the
-[values](/reference/be/general#config_setting.values) attribute
+[values](/versions/6.5.0/reference/be/general#config_setting.values) attribute
 (`values = {"define": "foo=bar"}`) or the
-[define_values](/reference/be/general#config_setting.define_values) attribute
+[define_values](/versions/6.5.0/reference/be/general#config_setting.define_values) attribute
 (`define_values = {"foo": "bar"}`). `--define` is only supported for backwards
 compatibility. Prefer Starlark build settings whenever possible.
 
@@ -265,7 +264,7 @@ For even clearer errors, you can set custom messages with `select()`'s
 While the ability to specify multiple flags on the command line provides
 flexibility, it can also be burdensome to individually set each one every time
 you want to build a target.
-   [Platforms](/docs/platforms)
+   [Platforms](/versions/6.5.0/docs/platforms)
 let you consolidate these into simple bundles.
 
 ```python
@@ -360,7 +359,7 @@ This saves the need for boilerplate `config_setting`s when you only need to
 check against single values.
 
 Platforms are still under development. See the
-[documentation](/concepts/platforms-intro) for details.
+[documentation](/versions/6.5.0/concepts/platforms-intro) for details.
 
 ## Combining `select()`s {#combining-selects}
 
@@ -408,8 +407,7 @@ sh_library(
 )
 ```
 
-If you need a `select` to match when multiple conditions match, consider [AND
-chaining](#and-chaining).
+If you need a `select` to match when multiple conditions match, consider [AND chaining](#and-chaining).
 
 ## OR chaining {#or-chaining}
 
@@ -565,7 +563,7 @@ Conditions checked:
   //tools/cc_target_os:android
 ```
 
-This can be customized with the [`no_match_error`](/reference/be/functions#select)
+This can be customized with the [`no_match_error`](/versions/6.5.0/reference/be/functions#select)
 attribute:
 
 ```python
@@ -627,7 +625,7 @@ select({"foo": "val_with_suffix"}, ...)
 This is for two reasons.
 
 First, macros that need to know which path a `select` will choose *cannot work*
-because macros are evaluated in Bazel's [loading phase](/docs/build#loading),
+because macros are evaluated in Bazel's [loading phase](/versions/6.5.0/docs/build#loading),
 which occurs before flag values are known.
 This is a core Bazel design restriction that's unlikely to change any time soon.
 
@@ -637,14 +635,14 @@ this.
 
 ## Bazel query and cquery {#query-and-cquery}
 
-Bazel [`query`](/docs/query-how-to) operates over Bazel's
-[loading phase](/reference/glossary#loading-phase).
+Bazel [`query`](/versions/6.5.0/docs/query-how-to) operates over Bazel's
+[loading phase](/versions/6.5.0/reference/glossary#loading-phase).
 This means it doesn't know what command line flags a target uses since those
 flags aren't evaluated until later in the build (in the
-[analysis phase](/reference/glossary#analysis-phase)).
+[analysis phase](/versions/6.5.0/reference/glossary#analysis-phase)).
 So it can't determine which `select()` branches are chosen.
 
-Bazel [`cquery`](/docs/cquery) operates after Bazel's analysis phase, so it has
+Bazel [`cquery`](/versions/6.5.0/docs/cquery) operates after Bazel's analysis phase, so it has
 all this information and can accurately resolve `select()`s.
 
 Consider:
@@ -705,7 +703,7 @@ details.
 
 The key issue this question usually means is that select() doesn't work in
 *macros*. These are different than *rules*. See the
-documentation on [rules](/rules/rules) and [macros](/rules/macros)
+documentation on [rules](/versions/6.5.0/rules/rules) and [macros](/versions/6.5.0/rules/macros)
 to understand the difference.
 Here's an end-to-end example:
 
@@ -914,13 +912,13 @@ def selecty_genrule(name, select_cmd):
 
 ### Why doesn't select() work with bind()? {#faq-select-bind}
 
-Because [`bind()`](/reference/be/workspace#bind) is a WORKSPACE rule, not a BUILD rule.
+Because [`bind()`](/versions/6.5.0/reference/be/workspace#bind) is a WORKSPACE rule, not a BUILD rule.
 
 Workspace rules do not have a specific configuration, and aren't evaluated in
 the same way as BUILD rules. Therefore, a `select()` in a `bind()` can't
 actually evaluate to any specific branch.
 
-Instead, you should use [`alias()`](/reference/be/general#alias), with a `select()` in
+Instead, you should use [`alias()`](/versions/6.5.0/reference/be/general#alias), with a `select()` in
 the `actual` attribute, to perform this type of run-time determination. This
 works correctly, since `alias()` is a BUILD rule, and is evaluated with a
 specific configuration.
@@ -958,7 +956,7 @@ located at `@alternative//:ssl`.
 ### Why doesn't my select() choose what I expect? {#faq-select-choose-condition}
 
 If `//myapp:foo` has a `select()` that doesn't choose the condition you expect,
-use [cquery](/docs/cquery) and `bazel config` to debug:
+use [cquery](/versions/6.5.0/docs/cquery) and `bazel config` to debug:
 
 If `//myapp:foo` is the top-level target you're building, run:
 
@@ -999,7 +997,7 @@ Fragment com.google.devtools.build.lib.rules.cpp.CppOptions {
 Then compare this output against the settings expected by each `config_setting`.
 
 `//myapp:foo` may exist in different configurations in the same build. See the
-[cquery docs](/docs/cquery) for guidance on using `somepath` to get the right
+[cquery docs](/versions/6.5.0/docs/cquery) for guidance on using `somepath` to get the right
 one.
 
 Caution: To prevent restarting the Bazel server, invoke `bazel config` with the
diff --git a/versions/6.5.0/docs/images/a_b_a_c.svg b/versions/6.5.0/docs/images/a_b_a_c.svg
new file mode 100644
index 00000000..d38be075
--- /dev/null
+++ b/versions/6.5.0/docs/images/a_b_a_c.svg
@@ -0,0 +1,42 @@
+
+
+
+
+
+
+G
+
+
+
+a
+
+a
+
+
+
+b
+
+b
+
+
+
+a->b
+
+
+
+
+
+c
+
+c
+
+
+
+a->c
+
+
+
+
+
+
diff --git a/versions/6.5.0/docs/images/a_b_c.svg b/versions/6.5.0/docs/images/a_b_c.svg
new file mode 100644
index 00000000..acd948ab
--- /dev/null
+++ b/versions/6.5.0/docs/images/a_b_c.svg
@@ -0,0 +1,41 @@
+
+
+
+
+
+
+G
+
+
+
+a
+
+a
+
+
+
+b
+
+b
+
+
+
+a->b
+
+
+
+
+
+c
+
+c
+
+
+
+b->c
+
+
+
+
+
diff --git a/versions/6.5.0/docs/images/a_b_c_ac.svg b/versions/6.5.0/docs/images/a_b_c_ac.svg
new file mode 100644
index 00000000..b099c53e
--- /dev/null
+++ b/versions/6.5.0/docs/images/a_b_c_ac.svg
@@ -0,0 +1,47 @@
+
+
+
+
+
+
+G
+
+
+
+a
+
+a
+
+
+
+b
+
+b
+
+
+
+a->b
+
+
+
+
+
+c
+
+c
+
+
+
+a->c
+
+
+
+
+
+b->c
+
+
+
+
+
diff --git a/versions/6.5.0/docs/images/ab_c.svg b/versions/6.5.0/docs/images/ab_c.svg
new file mode 100644
index 00000000..bcc4563f
--- /dev/null
+++ b/versions/6.5.0/docs/images/ab_c.svg
@@ -0,0 +1,36 @@
+
+
+
+
+
+
+G
+
+
+
+a
+
+a
+
+
+
+b
+
+b
+
+
+
+a->b
+
+
+
+
+
+c
+
+c
+
+
+
+
diff --git a/versions/6.5.0/docs/images/allpaths.svg b/versions/6.5.0/docs/images/allpaths.svg
new file mode 100644
index 00000000..47d0ee33
--- /dev/null
+++ b/versions/6.5.0/docs/images/allpaths.svg
@@ -0,0 +1,141 @@
+
+
+
+
+
+
+allpaths
+
+
+
+n1
+
+
+
+
+n2
+
+
+
+
+n1->n2
+
+
+
+
+
+n3
+
+
+
+
+n2->n3
+
+
+
+
+
+n10
+
+
+
+
+n2->n10
+
+
+
+
+
+n3->n10
+
+
+
+
+
+n4
+
+E
+
+
+
+n5
+
+
+
+
+n6
+
+
+
+
+n5->n6
+
+
+
+
+
+n6->n4
+
+
+
+
+
+n9
+
+
+
+
+n6->n9
+
+
+
+
+
+n7
+
+S1
+
+
+
+n7->n2
+
+
+
+
+
+n7->n5
+
+
+
+
+
+n8
+
+S2
+
+
+
+n8->n6
+
+
+
+
+
+n10->n4
+
+
+
+
+
+n11
+
+
+
+
+n10->n11
+
+
+
+
+
diff --git a/versions/6.5.0/docs/images/android_instrumentation_test.png b/versions/6.5.0/docs/images/android_instrumentation_test.png
new file mode 100644
index 00000000..e4534fbd
Binary files /dev/null and b/versions/6.5.0/docs/images/android_instrumentation_test.png differ
diff --git a/versions/6.5.0/docs/images/android_ndk.png b/versions/6.5.0/docs/images/android_ndk.png
new file mode 100644
index 00000000..76b63cb3
Binary files /dev/null and b/versions/6.5.0/docs/images/android_ndk.png differ
diff --git a/versions/6.5.0/docs/images/android_tutorial_app.png b/versions/6.5.0/docs/images/android_tutorial_app.png
new file mode 100644
index 00000000..076be5b9
Binary files /dev/null and b/versions/6.5.0/docs/images/android_tutorial_app.png differ
diff --git a/versions/6.5.0/docs/images/android_tutorial_before.png b/versions/6.5.0/docs/images/android_tutorial_before.png
new file mode 100644
index 00000000..8e41d419
Binary files /dev/null and b/versions/6.5.0/docs/images/android_tutorial_before.png differ
diff --git a/versions/6.5.0/docs/images/bep-graph.png b/versions/6.5.0/docs/images/bep-graph.png
new file mode 100644
index 00000000..82da6715
Binary files /dev/null and b/versions/6.5.0/docs/images/bep-graph.png differ
diff --git a/versions/6.5.0/docs/images/bep-graph.svg b/versions/6.5.0/docs/images/bep-graph.svg
new file mode 100644
index 00000000..62b1480f
--- /dev/null
+++ b/versions/6.5.0/docs/images/bep-graph.svg
@@ -0,0 +1,4 @@
+
+
+
+
diff --git a/versions/6.5.0/docs/images/cpp-tutorial-stage1.png b/versions/6.5.0/docs/images/cpp-tutorial-stage1.png
new file mode 100644
index 00000000..c85fb303
Binary files /dev/null and b/versions/6.5.0/docs/images/cpp-tutorial-stage1.png differ
diff --git a/versions/6.5.0/docs/images/cpp-tutorial-stage2.png b/versions/6.5.0/docs/images/cpp-tutorial-stage2.png
new file mode 100644
index 00000000..80e202c9
Binary files /dev/null and b/versions/6.5.0/docs/images/cpp-tutorial-stage2.png differ
diff --git a/versions/6.5.0/docs/images/cpp-tutorial-stage3.png b/versions/6.5.0/docs/images/cpp-tutorial-stage3.png
new file mode 100644
index 00000000..54d82f31
Binary files /dev/null and b/versions/6.5.0/docs/images/cpp-tutorial-stage3.png differ
diff --git a/versions/6.5.0/docs/images/deps.svg b/versions/6.5.0/docs/images/deps.svg
new file mode 100644
index 00000000..4354222a
--- /dev/null
+++ b/versions/6.5.0/docs/images/deps.svg
@@ -0,0 +1,101 @@
+
+
+
+
+
+
+G1
+
+
+
+r1
+
+rule
+
+
+
+s1
+
+in
+
+
+
+r1->s1
+
+
+
+
+
+s2
+
+in
+
+
+
+r1->s2
+
+
+
+
+
+s3
+
+in
+
+
+
+r1->s3
+
+
+
+
+
+r2
+
+rule
+
+
+
+r2->r1
+
+
+
+
+
+s4
+
+in
+
+
+
+r2->s4
+
+
+
+
+
+o1
+
+out
+
+
+
+o1->r1
+
+
+
+
+
+o2
+
+out
+
+
+
+o2->r2
+
+
+
+
+
diff --git a/versions/6.5.0/docs/images/dyn-trace-alldynamic.png b/versions/6.5.0/docs/images/dyn-trace-alldynamic.png
new file mode 100644
index 00000000..fe36b253
Binary files /dev/null and b/versions/6.5.0/docs/images/dyn-trace-alldynamic.png differ
diff --git a/versions/6.5.0/docs/images/dyn-trace-javaconly.png b/versions/6.5.0/docs/images/dyn-trace-javaconly.png
new file mode 100644
index 00000000..2ae41e52
Binary files /dev/null and b/versions/6.5.0/docs/images/dyn-trace-javaconly.png differ
diff --git a/versions/6.5.0/docs/images/e4b-workflow.png b/versions/6.5.0/docs/images/e4b-workflow.png
new file mode 100644
index 00000000..412822da
Binary files /dev/null and b/versions/6.5.0/docs/images/e4b-workflow.png differ
diff --git a/versions/6.5.0/docs/images/e4b-workflow.svg b/versions/6.5.0/docs/images/e4b-workflow.svg
new file mode 100644
index 00000000..1de66e02
--- /dev/null
+++ b/versions/6.5.0/docs/images/e4b-workflow.svg
@@ -0,0 +1,4 @@
+
+
+
+
diff --git a/versions/6.5.0/docs/images/error_example_1.png b/versions/6.5.0/docs/images/error_example_1.png
new file mode 100644
index 00000000..07ba1358
Binary files /dev/null and b/versions/6.5.0/docs/images/error_example_1.png differ
diff --git a/versions/6.5.0/docs/images/error_example_2.png b/versions/6.5.0/docs/images/error_example_2.png
new file mode 100644
index 00000000..861171ee
Binary files /dev/null and b/versions/6.5.0/docs/images/error_example_2.png differ
diff --git a/versions/6.5.0/docs/images/error_example_3.png b/versions/6.5.0/docs/images/error_example_3.png
new file mode 100644
index 00000000..dc16eec4
Binary files /dev/null and b/versions/6.5.0/docs/images/error_example_3.png differ
diff --git a/versions/6.5.0/docs/images/error_example_4.png b/versions/6.5.0/docs/images/error_example_4.png
new file mode 100644
index 00000000..84383e63
Binary files /dev/null and b/versions/6.5.0/docs/images/error_example_4.png differ
diff --git a/versions/6.5.0/docs/images/graph_ex_1.svg b/versions/6.5.0/docs/images/graph_ex_1.svg
new file mode 100644
index 00000000..dd7427f4
--- /dev/null
+++ b/versions/6.5.0/docs/images/graph_ex_1.svg
@@ -0,0 +1,131 @@
+
+
+
+
+
+
+mygraph
+
+
+
+//net/proto_compiler:protocol-compiler
+
+//net/proto_compiler:protocol-compiler
+
+
+
+//net/proto_compiler:util
+
+//net/proto_compiler:util
+
+
+
+//net/proto_compiler:protocol-compiler->//net/proto_compiler:util
+
+
+
+
+
+//net/proto_compiler:protocol-compiler-lib
+
+//net/proto_compiler:protocol-compiler-lib
+
+
+
+//net/proto_compiler:protocol-compiler->//net/proto_compiler:protocol-compiler-lib
+
+
+
+
+
+//net/proto2/bridge/public:compiler_upgrader
+
+//net/proto2/bridge/public:compiler_upgrader
+
+
+
+//net/proto_compiler:protocol-compiler->//net/proto2/bridge/public:compiler_upgrader
+
+
+
+
+
+//net/proto_compiler:parser
+
+//net/proto_compiler:parser
+
+
+
+//net/proto_compiler:util->//net/proto_compiler:parser
+
+
+
+
+
+//net/proto_compiler:proto-min-lib
+
+//net/proto_compiler:proto-min-lib
+
+
+
+//net/proto_compiler:protocol-compiler-lib->//net/proto_compiler:proto-min-lib
+
+
+
+
+
+//net/proto_compiler:protocol-compiler-lib->//net/proto_compiler:parser
+
+
+
+
+
+//net/proto2/bridge/internal:compiler_upgrader
+
+//net/proto2/bridge/internal:compiler_upgrader
+
+
+
+//net/proto2/bridge/public:compiler_upgrader->//net/proto2/bridge/internal:compiler_upgrader
+
+
+
+
+
+//net/proto_compiler:proto-min-lib->//net/proto_compiler:parser
+
+
+
+
+
+//util/regexp:regexp
+
+//util/regexp:regexp
+
+
+
+//net/proto_compiler:proto-min-lib->//util/regexp:regexp
+
+
+
+
+
+//net/proto_compiler:parser->//util/regexp:regexp
+
+
+
+
+
+//net/proto2/bridge/internal:compiler_upgrader->//net/proto2/bridge/public:compiler_upgrader
+
+
+
+
+
+//net/proto2/bridge/internal:compiler_upgrader->//net/proto_compiler:parser
+
+
+
+
+
diff --git a/versions/6.5.0/docs/images/graph_hello-world.svg b/versions/6.5.0/docs/images/graph_hello-world.svg
new file mode 100644
index 00000000..93b61444
--- /dev/null
+++ b/versions/6.5.0/docs/images/graph_hello-world.svg
@@ -0,0 +1,70 @@
+
+
+
+
+
+
+mygraph
+
+
+//main:hello-world
+
+//main:hello-world
+
+
+//main:hello-time
+
+//main:hello-time
+
+
+//main:hello-world->//main:hello-time
+
+
+
+
+//main:hello-world.cc
+
+//main:hello-world.cc
+
+
+//main:hello-world->//main:hello-world.cc
+
+
+
+
+//lib:hello-greet
+
+//lib:hello-greet
+
+
+//main:hello-world->//lib:hello-greet
+
+
+
+
+//main:hello-time.cc\n//main:hello-time.h
+
+//main:hello-time.cc
+//main:hello-time.h
+
+
+//main:hello-time->//main:hello-time.cc\n//main:hello-time.h
+
+
+
+
+//lib:hello-greet.cc\n//lib:hello-greet.h
+
+//lib:hello-greet.cc
+//lib:hello-greet.h
+
+
+//lib:hello-greet->//lib:hello-greet.cc\n//lib:hello-greet.h
+
+
+
+
+
diff --git a/versions/6.5.0/docs/images/json-trace-profile-network-usage.png b/versions/6.5.0/docs/images/json-trace-profile-network-usage.png
new file mode 100644
index 00000000..8a7500a6
Binary files /dev/null and b/versions/6.5.0/docs/images/json-trace-profile-network-usage.png differ
diff --git a/versions/6.5.0/docs/images/json-trace-profile-system-load-average.png b/versions/6.5.0/docs/images/json-trace-profile-system-load-average.png
new file mode 100644
index 00000000..e71b420c
Binary files /dev/null and b/versions/6.5.0/docs/images/json-trace-profile-system-load-average.png differ
diff --git a/versions/6.5.0/docs/images/json-trace-profile-workers-memory-usage.png b/versions/6.5.0/docs/images/json-trace-profile-workers-memory-usage.png
new file mode 100644
index 00000000..806505f0
Binary files /dev/null and b/versions/6.5.0/docs/images/json-trace-profile-workers-memory-usage.png differ
diff --git a/versions/6.5.0/docs/images/json-trace-profile.png b/versions/6.5.0/docs/images/json-trace-profile.png
new file mode 100644
index 00000000..538382b2
Binary files /dev/null and b/versions/6.5.0/docs/images/json-trace-profile.png differ
diff --git a/versions/6.5.0/docs/images/mobile-install-performance.svg b/versions/6.5.0/docs/images/mobile-install-performance.svg
new file mode 100644
index 00000000..b139d658
--- /dev/null
+++ b/versions/6.5.0/docs/images/mobile-install-performance.svg
@@ -0,0 +1,86 @@
+
+
+
+  
+    
+      
+    
+  
+  
+  
+    Build times
+  
+  
+    
+    
+      
+      
+        adb install
+      
+      
+    
+    
+      
+      
+        mobile-install
+      
+      
+    
+  
+  
+    
+    
+      
+        
+        
+        
+        
+        
+      
+      
+        
+        
+        
+        
+        
+        
+      
+      
+        
+      
+    
+    
+    
+      
+        Google Maps
+      
+      
+        Google+
+      
+      
+        YouTube
+      
+      
+        0
+      
+      
+        75
+      
+      
+        150
+      
+      
+        225
+      
+      
+        300
+      
+    
+  
+  
+    
+      Seconds
+    
+  
+  
+
diff --git a/versions/6.5.0/docs/images/namedsetoffiles-bep-graph.png b/versions/6.5.0/docs/images/namedsetoffiles-bep-graph.png
new file mode 100644
index 00000000..ea1e10cc
Binary files /dev/null and b/versions/6.5.0/docs/images/namedsetoffiles-bep-graph.png differ
diff --git a/versions/6.5.0/docs/images/out-ranked.svg b/versions/6.5.0/docs/images/out-ranked.svg
new file mode 100644
index 00000000..07e96804
--- /dev/null
+++ b/versions/6.5.0/docs/images/out-ranked.svg
@@ -0,0 +1,71 @@
+
+
+
+
+
+
+mygraph
+
+
+
+//a:a
+
+//a:a
+
+
+
+//a:a.cc
+
+//a:a.cc
+
+
+
+//a:a->//a:a.cc
+
+
+
+
+
+//b:b
+
+//b:b
+
+
+
+//b:b->//a:a
+
+
+
+
+
+//b:b.cc
+
+//b:b.cc
+
+
+
+//b:b->//b:b.cc
+
+
+
+
+
+//c:c
+
+//c:c
+
+
+
+//c:c->//a:a
+
+
+
+
+
+//c:c->//b:b
+
+
+
+
+
diff --git a/versions/6.5.0/docs/images/rbe-ci-1.png b/versions/6.5.0/docs/images/rbe-ci-1.png
new file mode 100644
index 00000000..fbe76a85
Binary files /dev/null and b/versions/6.5.0/docs/images/rbe-ci-1.png differ
diff --git a/versions/6.5.0/docs/images/rbe-ci-2.png b/versions/6.5.0/docs/images/rbe-ci-2.png
new file mode 100644
index 00000000..07611889
Binary files /dev/null and b/versions/6.5.0/docs/images/rbe-ci-2.png differ
diff --git a/versions/6.5.0/docs/images/somepath1.svg b/versions/6.5.0/docs/images/somepath1.svg
new file mode 100644
index 00000000..5e5f8812
--- /dev/null
+++ b/versions/6.5.0/docs/images/somepath1.svg
@@ -0,0 +1,141 @@
+
+
+
+
+
+
+somepath1
+
+
+
+n1
+
+
+
+
+n2
+
+
+
+
+n1->n2
+
+
+
+
+
+n3
+
+
+
+
+n2->n3
+
+
+
+
+
+n10
+
+
+
+
+n2->n10
+
+
+
+
+
+n3->n10
+
+
+
+
+
+n4
+
+E
+
+
+
+n5
+
+
+
+
+n6
+
+
+
+
+n5->n6
+
+
+
+
+
+n6->n4
+
+
+
+
+
+n9
+
+
+
+
+n6->n9
+
+
+
+
+
+n7
+
+S1
+
+
+
+n7->n2
+
+
+
+
+
+n7->n5
+
+
+
+
+
+n8
+
+S2
+
+
+
+n8->n6
+
+
+
+
+
+n10->n4
+
+
+
+
+
+n11
+
+
+
+
+n10->n11
+
+
+
+
+
diff --git a/versions/6.5.0/docs/images/somepath2.svg b/versions/6.5.0/docs/images/somepath2.svg
new file mode 100644
index 00000000..911f2c9b
--- /dev/null
+++ b/versions/6.5.0/docs/images/somepath2.svg
@@ -0,0 +1,141 @@
+
+
+
+
+
+
+somepath2
+
+
+
+n1
+
+
+
+
+n2
+
+
+
+
+n1->n2
+
+
+
+
+
+n3
+
+
+
+
+n2->n3
+
+
+
+
+
+n10
+
+
+
+
+n2->n10
+
+
+
+
+
+n3->n10
+
+
+
+
+
+n4
+
+E
+
+
+
+n5
+
+
+
+
+n6
+
+
+
+
+n5->n6
+
+
+
+
+
+n6->n4
+
+
+
+
+
+n9
+
+
+
+
+n6->n9
+
+
+
+
+
+n7
+
+S1
+
+
+
+n7->n2
+
+
+
+
+
+n7->n5
+
+
+
+
+
+n8
+
+S2
+
+
+
+n8->n6
+
+
+
+
+
+n10->n4
+
+
+
+
+
+n11
+
+
+
+
+n10->n11
+
+
+
+
+
diff --git a/versions/6.5.0/docs/images/targets.svg b/versions/6.5.0/docs/images/targets.svg
new file mode 100644
index 00000000..82f47e74
--- /dev/null
+++ b/versions/6.5.0/docs/images/targets.svg
@@ -0,0 +1,113 @@
+
+
+
+
+
+
+G1
+
+
+
+Target
+
+Target
+
+
+
+Rule
+
+Rule
+
+
+
+Target->Rule
+
+
+
+
+
+File
+
+File
+
+
+
+Target->File
+
+
+
+
+
+Package group
+
+Package group
+
+
+
+Target->Package group
+
+
+
+
+
+cc_library
+
+cc_library
+
+
+
+Rule->cc_library
+
+
+
+
+
+java_test
+
+java_test
+
+
+
+Rule->java_test
+
+
+
+
+
+...
+
+...
+
+
+
+Rule->...
+
+
+
+
+
+Source
+
+Source
+
+
+
+File->Source
+
+
+
+
+
+Generated
+
+Generated
+
+
+
+File->Generated
+
+
+
+
+
diff --git a/versions/6.5.0/docs/images/tutorial_java_01.svg b/versions/6.5.0/docs/images/tutorial_java_01.svg
new file mode 100644
index 00000000..2fe72f36
--- /dev/null
+++ b/versions/6.5.0/docs/images/tutorial_java_01.svg
@@ -0,0 +1,29 @@
+
+
+
+
+
+
+mygraph
+
+
+//:ProjectRunner
+
+//:ProjectRunner
+
+
+//:src/main/java/com/example/Greeting.java\n//:src/main/java/com/example/ProjectRunner.java
+
+//:src/main/java/com/example/Greeting.java
+//:src/main/java/com/example/ProjectRunner.java
+
+
+//:ProjectRunner->//:src/main/java/com/example/Greeting.java\n//:src/main/java/com/example/ProjectRunner.java
+
+
+
+
+
diff --git a/versions/6.5.0/docs/images/tutorial_java_02.svg b/versions/6.5.0/docs/images/tutorial_java_02.svg
new file mode 100644
index 00000000..40cbb218
--- /dev/null
+++ b/versions/6.5.0/docs/images/tutorial_java_02.svg
@@ -0,0 +1,48 @@
+
+
+
+
+
+
+mygraph
+
+
+//:ProjectRunner
+
+//:ProjectRunner
+
+
+//:greeter
+
+//:greeter
+
+
+//:ProjectRunner->//:greeter
+
+
+
+
+//:src/main/java/com/example/ProjectRunner.java
+
+//:src/main/java/com/example/ProjectRunner.java
+
+
+//:ProjectRunner->//:src/main/java/com/example/ProjectRunner.java
+
+
+
+
+//:src/main/java/com/example/Greeting.java
+
+//:src/main/java/com/example/Greeting.java
+
+
+//:greeter->//:src/main/java/com/example/Greeting.java
+
+
+
+
+
diff --git a/versions/6.5.0/docs/images/tutorial_java_03.svg b/versions/6.5.0/docs/images/tutorial_java_03.svg
new file mode 100644
index 00000000..7d79041a
--- /dev/null
+++ b/versions/6.5.0/docs/images/tutorial_java_03.svg
@@ -0,0 +1,48 @@
+
+
+
+
+
+
+mygraph
+
+
+//src/main/java/com/example/cmdline:runner
+
+//src/main/java/com/example/cmdline:runner
+
+
+//src/main/java/com/example/cmdline:Runner.java
+
+//src/main/java/com/example/cmdline:Runner.java
+
+
+//src/main/java/com/example/cmdline:runner->//src/main/java/com/example/cmdline:Runner.java
+
+
+
+
+//:greeter
+
+//:greeter
+
+
+//src/main/java/com/example/cmdline:runner->//:greeter
+
+
+
+
+//:src/main/java/com/example/Greeting.java
+
+//:src/main/java/com/example/Greeting.java
+
+
+//:greeter->//:src/main/java/com/example/Greeting.java
+
+
+
+
+
diff --git a/versions/6.5.0/docs/images/workers-clean-chart.png b/versions/6.5.0/docs/images/workers-clean-chart.png
new file mode 100644
index 00000000..63526fc1
Binary files /dev/null and b/versions/6.5.0/docs/images/workers-clean-chart.png differ
diff --git a/versions/6.5.0/docs/images/workers-incremental-chart.png b/versions/6.5.0/docs/images/workers-incremental-chart.png
new file mode 100644
index 00000000..1c62d25c
Binary files /dev/null and b/versions/6.5.0/docs/images/workers-incremental-chart.png differ
diff --git a/versions/6.5.0/docs/images/ws-diamond.png b/versions/6.5.0/docs/images/ws-diamond.png
new file mode 100644
index 00000000..154a7440
Binary files /dev/null and b/versions/6.5.0/docs/images/ws-diamond.png differ
diff --git a/versions/6.5.0/docs/images/ws-line.png b/versions/6.5.0/docs/images/ws-line.png
new file mode 100644
index 00000000..e8bfe7a1
Binary files /dev/null and b/versions/6.5.0/docs/images/ws-line.png differ
diff --git a/versions/6.5.0/docs/images/ws-multiline.png b/versions/6.5.0/docs/images/ws-multiline.png
new file mode 100644
index 00000000..f07b43b1
Binary files /dev/null and b/versions/6.5.0/docs/images/ws-multiline.png differ
diff --git a/versions/6.5.0/docs/sandboxing.mdx b/versions/6.5.0/docs/sandboxing.mdx
index abbaf3b9..25b63006 100644
--- a/versions/6.5.0/docs/sandboxing.mdx
+++ b/versions/6.5.0/docs/sandboxing.mdx
@@ -49,10 +49,10 @@ containers on Linux and `sandbox-exec` on macOS, to constrain the action within
 ## What sandbox strategy to use {#sandboxing-strategies}
 
 You can choose which kind of sandboxing to use, if any, with the
-[strategy flags](user-manual.html#strategy-options). Using the `sandboxed`
+[strategy flags](/versions/6.5.0/docs/user-manual#strategy-options). Using the `sandboxed`
 strategy makes Bazel pick one of the sandbox implementations listed below,
 preferring an OS-specific sandbox to the less hermetic generic one.
-[Persistent workers](persistent-workers.md) run in a generic sandbox if you pass
+[Persistent workers](/versions/6.5.0/docs/persistent-workers) run in a generic sandbox if you pass
 the `--worker_sandboxing` flag.
 
 The `local` (a.k.a. `standalone`) strategy does not do any kind of sandboxing.
@@ -97,7 +97,7 @@ strategies that Bazel tries to use (for example, `bazel build
 
 Dynamic execution usually requires sandboxing for local execution. To opt out,
 pass the `--experimental_local_lockfree_output` flag. Dynamic execution silently
-sandboxes [persistent workers](persistent-workers.md).
+sandboxes [persistent workers](/versions/6.5.0/docs/persistent-workers).
 
 ## Downsides to sandboxing {#sandboxing_downsides}
 
@@ -108,10 +108,10 @@ sandboxes [persistent workers](persistent-workers.md).
     mitigate the setup and teardown cost.
 
 -   Sandboxing effectively disables any cache the tool may have. You can
-    mitigate this by using [persistent workers](persistent-workers.md), at
+    mitigate this by using [persistent workers](/versions/6.5.0/docs/persistent-workers), at
     the cost of weaker sandbox guarantees.
 
--   [Multiplex workers](multiplex-worker.md) require explicit worker support
+-   [Multiplex workers](/versions/6.5.0/docs/multiplex-worker) require explicit worker support
     to be sandboxed. Workers that do not support multiplex sandboxing run as
     singleplex workers under dynamic execution, which can cost extra memory.
 
diff --git a/versions/6.5.0/docs/user-manual.mdx b/versions/6.5.0/docs/user-manual.mdx
index 8c8b9365..7d4e2f90 100644
--- a/versions/6.5.0/docs/user-manual.mdx
+++ b/versions/6.5.0/docs/user-manual.mdx
@@ -1189,12 +1189,12 @@ during execution can be examined.
 This option causes Bazel's execution phase to print the full command line
 for each command prior to executing it.
 
-
{`
-  >>>>> # //examples/cpp:hello-world [action 'Linking examples/cpp/hello-world']
+```
+  >>>> # //examples/cpp:hello-world [action 'Linking examples/cpp/hello-world']
   (cd /home/johndoe/.cache/bazel/_bazel_johndoe/4c084335afceb392cfbe7c31afee3a9f/bazel && \
     exec env - \
     /usr/bin/gcc -o bazel-out/local-fastbuild/bin/examples/cpp/hello-world -B/usr/bin/ -Wl,-z,relro,-z,now -no-canonical-prefixes -pass-exit-codes -Wl,-S -Wl,@bazel-out/local_linux-fastbuild/bin/examples/cpp/hello-world-2.params)
-`}

+```
 
 Where possible, commands are printed in a Bourne shell compatible syntax,
 so that they can be easily copied and pasted to a shell command prompt.
diff --git a/versions/6.5.0/extending/aspects.mdx b/versions/6.5.0/extending/aspects.mdx
index 4abaa0dc..7b81e8b5 100644
--- a/versions/6.5.0/extending/aspects.mdx
+++ b/versions/6.5.0/extending/aspects.mdx
@@ -40,16 +40,16 @@ java_library(name = 'X', deps = [':Y',':Z'], runtime_deps = [':T'], ...)
 
 This `BUILD` file defines a dependency graph shown in the following figure:
 
-![Build graph](/rules/build-graph.png "Build graph")
+![Build graph](/versions/6.5.0/rules/build-graph.png "Build graph")
 
 **Figure 1.** `BUILD` file dependency graph.
 
 Bazel analyzes this dependency graph by calling an implementation function of
-the corresponding [rule](/rules/rules) (in this case "java_library") for every
+the corresponding [rule](/versions/6.5.0/rules/rules) (in this case "java_library") for every
 target in the above example. Rule implementation functions generate actions that
 build artifacts, such as `.jar` files, and pass information, such as locations
 and names of those artifacts, to the reverse dependencies of those targets in
-[providers](/rules/rules#providers).
+[providers](/versions/6.5.0/rules/rules#providers).
 
 Aspects are similar to rules in that they have an implementation function that
 generates actions and returns providers. However, their power comes from
@@ -63,7 +63,7 @@ attribute (all attributes in A's propagation list).
 Thus a single act of applying aspect A to a target X yields a "shadow graph" of
 the original dependency graph of targets shown in the following figure:
 
-![Build Graph with Aspect](/rules/build-graph-aspects.png "Build graph with aspects")
+![Build Graph with Aspect](/versions/6.5.0/rules/build-graph-aspects.png "Build graph with aspects")
 
 **Figure 2.** Build graph with aspects.
 
@@ -108,7 +108,7 @@ print_aspect = aspect(
 )
 ```
 Aspect definitions are similar to rule definitions, and defined using
-the [`aspect`](/rules/lib/globals#aspect) function.
+the [`aspect`](/versions/6.5.0/rules/lib/globals#aspect) function.
 
 Just like a rule, an aspect has an implementation function which in this case is
 ``_print_aspect_impl``.
@@ -135,15 +135,15 @@ def _print_aspect_impl(target, ctx):
 ```
 
 Aspect implementation functions are similar to the rule implementation
-functions. They return [providers](/rules/rules#providers), can generate
-[actions](/rules/rules#actions), and take two arguments:
+functions. They return [providers](/versions/6.5.0/rules/rules#providers), can generate
+[actions](/versions/6.5.0/rules/rules#actions), and take two arguments:
 
-*  `target`: the [target](/rules/lib/Target) the aspect is being applied to.
-*   `ctx`: [`ctx`](/rules/lib/ctx) object that can be used to access attributes
+*  `target`: the [target](/versions/6.5.0/rules/lib/builtins/Target) the aspect is being applied to.
+*   `ctx`: [`ctx`](/versions/6.5.0/rules/lib/builtins/ctx) object that can be used to access attributes
     and generate outputs and actions.
 
 The implementation function can access the attributes of the target rule via
-[`ctx.rule.attr`](/rules/lib/ctx#rule). It can examine providers that are
+[`ctx.rule.attr`](/versions/6.5.0/rules/lib/builtins/ctx#rule). It can examine providers that are
 provided by the target to which it is applied (via the `target` argument).
 
 Aspects are required to return a list of providers. In this example, the aspect
@@ -152,7 +152,7 @@ does not provide anything, so it returns an empty list.
 ### Invoking the aspect using the command line
 
 The simplest way to apply an aspect is from the command line using the
-[`--aspects`](/reference/command-line-reference#flag--aspects)
+[`--aspects`](/versions/6.5.0/reference/command-line-reference#flag--aspects)
 argument. Assuming the aspect above were defined in a file named `print.bzl`
 this:
 
@@ -326,12 +326,12 @@ implementation of aspect A. The providers that a rule implementation propagates
 are created and frozen before aspects are applied and cannot be modified from an
 aspect. It is an error if a target and an aspect that is applied to it each
 provide a provider with the same type, with the exceptions of
-[`OutputGroupInfo`](/rules/lib/OutputGroupInfo)
+[`OutputGroupInfo`](/versions/6.5.0/rules/lib/providers/OutputGroupInfo)
 (which is merged, so long as the
 rule and aspect specify different output groups) and
-[`InstrumentedFilesInfo`](/rules/lib/InstrumentedFilesInfo)
+[`InstrumentedFilesInfo`](/versions/6.5.0/rules/lib/providers/InstrumentedFilesInfo)
 (which is taken from the aspect). This means that aspect implementations may
-never return [`DefaultInfo`](/rules/lib/DefaultInfo).
+never return [`DefaultInfo`](/versions/6.5.0/rules/lib/providers/DefaultInfo).
 
 The parameters and private attributes are passed in the attributes of the
 ``ctx``. This example references the ``extension`` parameter and determines
diff --git a/versions/6.5.0/extending/concepts.mdx b/versions/6.5.0/extending/concepts.mdx
index 64291720..a681c028 100644
--- a/versions/6.5.0/extending/concepts.mdx
+++ b/versions/6.5.0/extending/concepts.mdx
@@ -8,26 +8,26 @@ This page describes how to extend the BUILD language using macros
 and rules.
 
 Bazel extensions are files ending in `.bzl`. Use a
-[load statement](/concepts/build-files#load) to import a symbol from an extension.
+[load statement](/versions/6.5.0/concepts/build-files#load) to import a symbol from an extension.
 
 Before learning the more advanced concepts, first:
 
-* Read about the [Starlark language](/rules/language), used in both the
+* Read about the [Starlark language](/versions/6.5.0/rules/language), used in both the
   `BUILD` and `.bzl` files.
 
-* Learn how you can [share variables](/rules/tutorial-sharing-variables)
+* Learn how you can [share variables](/versions/6.5.0/rules/tutorial-sharing-variables)
   between two `BUILD` files.
 
 ## Macros and rules {#macros-and-rules}
 
-A [macro](/rules/macros) is a function that instantiates rules. It is useful when a
+A [macro](/versions/6.5.0/rules/macros) is a function that instantiates rules. It is useful when a
 `BUILD` file is getting too repetitive or too complex, as it allows you to reuse
 some code. The function is evaluated as soon as the `BUILD` file is read. After
 the evaluation of the `BUILD` file, Bazel has little information about macros:
 if your macro generates a `genrule`, Bazel will behave as if you wrote the
 `genrule`. As a result, `bazel query` will only list the generated `genrule`.
 
-A [rule](/rules/rules) is more powerful than a macro. It can access Bazel
+A [rule](/versions/6.5.0/rules/rules) is more powerful than a macro. It can access Bazel
 internals and have full control over what is going on. It may for example pass
 information to other rules.
 
@@ -70,34 +70,34 @@ they will not be executed.
 
 ## Creating extensions
 
-* [Create your first macro](/rules/tutorial-creating-a-macro) in order to
-  reuse some code. Then [learn more about macros](/rules/macros) and
-  [using them to create "custom verbs"](/rules/tutorial-custom-verbs).
+* [Create your first macro](/versions/6.5.0/rules/tutorial-creating-a-macro) in order to
+  reuse some code. Then [learn more about macros](/versions/6.5.0/rules/macros) and
+  [using them to create "custom verbs"](/versions/6.5.0/rules/tutorial-custom-verbs).
 
-* [Follow the rules tutorial](/rules/rules-tutorial) to get started with rules.
-  Next, you can read more about the [rules concepts](/rules/rules).
+* [Follow the rules tutorial](/versions/6.5.0/rules/rules-tutorial) to get started with rules.
+  Next, you can read more about the [rules concepts](/versions/6.5.0/rules/rules).
 
 The two links below will be very useful when writing your own extensions. Keep
 them within reach:
 
-* The [API reference](/rules/lib/starlark-overview)
+* The [API reference](/versions/6.5.0/rules/lib/starlark-overview)
 
 * [Examples](https://github.com/bazelbuild/examples/tree/master/rules)
 
 ## Going further
 
-In addition to [macros](/rules/macros) and [rules](/rules/rules), you may want to write
-[aspects](/rules/aspects) and [repository rules](/rules/repository_rules).
+In addition to [macros](/versions/6.5.0/rules/macros) and [rules](/versions/6.5.0/rules/rules), you may want to write
+[aspects](/versions/6.5.0/rules/aspects) and [repository rules](/versions/6.5.0/rules/repository_rules).
 
 * Use [Buildifier](https://github.com/bazelbuild/buildtools)
   consistently to format and lint your code.
 
-* Follow the [`.bzl` style guide](/rules/bzl-style).
+* Follow the [`.bzl` style guide](/versions/6.5.0/rules/bzl-style).
 
-* [Test](/rules/testing) your code.
+* [Test](/versions/6.5.0/rules/testing) your code.
 
 * [Generate documentation](https://skydoc.bazel.build/) to help your users.
 
-* [Optimize the performance](/rules/performance) of your code.
+* [Optimize the performance](/versions/6.5.0/rules/performance) of your code.
 
-* [Deploy](/rules/deploying) your extensions to other people.
+* [Deploy](/versions/6.5.0/rules/deploying) your extensions to other people.
diff --git a/versions/6.5.0/extending/depsets.mdx b/versions/6.5.0/extending/depsets.mdx
index 1454c378..332f30c7 100644
--- a/versions/6.5.0/extending/depsets.mdx
+++ b/versions/6.5.0/extending/depsets.mdx
@@ -3,7 +3,7 @@ title: 'Depsets'
 ---
 
 
-[Depsets](/rules/lib/depset) are a specialized data structure for efficiently
+[Depsets](/versions/6.5.0/rules/lib/builtins/depset) are a specialized data structure for efficiently
 collecting data across a target’s transitive dependencies. They are an essential
 element of rule processing.
 
@@ -33,7 +33,7 @@ previous without having to read or copy them.
 Each node in the DAG holds a list of direct elements and a list of child nodes.
 The contents of the depset are the transitive elements, such as the direct elements
 of all the nodes. A new depset can be created using the
-[depset](/rules/lib/globals#depset) constructor: it accepts a list of direct
+[depset](/versions/6.5.0/rules/lib/globals#depset) constructor: it accepts a list of direct
 elements and another list of child nodes.
 
 ```python
@@ -45,7 +45,7 @@ print(t)    # depset(["d", "e", "a", "b", "c"])
 ```
 
 To retrieve the contents of a depset, use the
-[to_list()](/rules/lib/depset#to_list) method. It returns a list of all transitive
+[to_list()](/versions/6.5.0/rules/lib/builtins/depset#to_list) method. It returns a list of all transitive
 elements, not including duplicates. There is no way to directly inspect the
 precise structure of the DAG, although this structure does affect the order in
 which the elements are returned.
@@ -112,8 +112,7 @@ need to ensure that if `B` depends on `A`, then `A.o` comes before `B.o` on the
 linker’s command line. Other tools might have the opposite requirement.
 
 Three traversal orders are supported: `postorder`, `preorder`, and
-`topological`. The first two work exactly like [tree
-traversals](https://en.wikipedia.org/wiki/Tree_traversal#Depth-first_search)
+`topological`. The first two work exactly like [tree traversals](https://en.wikipedia.org/wiki/Tree_traversal#Depth-first_search)
 except that they operate on DAGs and skip already visited nodes. The third order
 works as a topological sort from root to leaves, essentially the same as
 preorder except that shared children are listed only after all of their parents.
@@ -337,9 +336,9 @@ at the end in a binary rule is fine, since the overall cost is just O(n). It’s
 when many non-terminal targets try to call `to_list()` that quadratic behavior
 occurs.
 
-For more information about using depsets efficiently, see the [performance](/rules/performance) page.
+For more information about using depsets efficiently, see the [performance](/versions/6.5.0/rules/performance) page.
 
 ## API Reference
 
-Please see [here](/rules/lib/depset) for more details.
+Please see [here](/versions/6.5.0/rules/lib/builtins/depset) for more details.
 
diff --git a/versions/6.5.0/extending/exec-groups.mdx b/versions/6.5.0/extending/exec-groups.mdx
index 42fa0416..459b50d5 100644
--- a/versions/6.5.0/extending/exec-groups.mdx
+++ b/versions/6.5.0/extending/exec-groups.mdx
@@ -4,8 +4,8 @@ title: 'Execution Groups'
 
 
 Execution groups allow for multiple execution platforms within a single target.
-Each execution group has its own [toolchain](/docs/toolchains) dependencies and
-performs its own [toolchain resolution](/docs/toolchains#toolchain-resolution).
+Each execution group has its own [toolchain](/versions/6.5.0/docs/toolchains) dependencies and
+performs its own [toolchain resolution](/versions/6.5.0/docs/toolchains#toolchain-resolution).
 
 ## Background {#background}
 
@@ -23,7 +23,7 @@ like linking in C++ builds without over-allocating to less demanding tasks.
 ## Defining execution groups {#defining-exec-groups}
 
 During rule definition, rule authors can
-[declare](/rules/lib/globals#exec_group)
+[declare](/versions/6.5.0/rules/lib/globals#exec_group)
 a set of execution groups. On each execution group, the rule author can specify
 everything needed to select an execution platform for that execution group,
 namely any constraints via `exec_compatible_with` and toolchain types via
@@ -50,9 +50,9 @@ my_rule = rule(
 
 In the code snippet above, you can see that tool dependencies can also specify
 transition for an exec group using the
-[`cfg`](/rules/lib/attr#label)
+[`cfg`](/versions/6.5.0/rules/lib/toplevel/attr#label)
 attribute param and the
-[`config`](/rules/lib/config)
+[`config`](/versions/6.5.0/rules/lib/toplevel/config)
 module. The module exposes an `exec` function which takes a single string
 parameter which is the name of the exec group for which the dependency should be
 built.
@@ -106,9 +106,8 @@ of:
 
 In the rule implementation, you can declare that actions should be run on the
 execution platform of an execution group. You can do this by using the `exec_group`
-param of action generating methods, specifically [`ctx.actions.run`]
-(/rules/lib/actions#run) and
-[`ctx.actions.run_shell`](/rules/lib/actions#run_shell).
+param of action generating methods, specifically [`ctx.actions.run`](/versions/6.5.0/rules/lib/builtins/actions#run) and
+[`ctx.actions.run_shell`](/versions/6.5.0/rules/lib/builtins/actions#run_shell).
 
 ```python
 # foo.bzl
@@ -120,7 +119,7 @@ def _impl(ctx):
   )
 ```
 
-Rule authors will also be able to access the [resolved toolchains](/docs/toolchains#toolchain-resolution)
+Rule authors will also be able to access the [resolved toolchains](/versions/6.5.0/docs/toolchains#toolchain-resolution)
 of execution groups, similarly to how you
 can access the resolved toolchain of a target:
 
@@ -143,7 +142,7 @@ problem.
 ## Using execution groups to set execution properties {#using-exec-groups-for-exec-properties}
 
 Execution groups are integrated with the
-[`exec_properties`](/reference/be/common-definitions#common-attributes)
+[`exec_properties`](/versions/6.5.0/reference/be/common-definitions#common-attributes)
 attribute that exists on every rule and allows the target writer to specify a
 string dict of properties that is then passed to the execution machinery. For
 example, if you wanted to set some property, say memory, for the target and give
diff --git a/versions/6.5.0/extending/macros.mdx b/versions/6.5.0/extending/macros.mdx
index 4a211939..0008015e 100644
--- a/versions/6.5.0/extending/macros.mdx
+++ b/versions/6.5.0/extending/macros.mdx
@@ -140,7 +140,7 @@ Note that `native` can only be used in `.bzl` files, and not in `WORKSPACE` or
 
 ## Label resolution in macros
 
-Since macros are evaluated in the [loading phase](concepts.md#evaluation-model),
+Since macros are evaluated in the [loading phase](/versions/6.5.0/extending/concepts#evaluation-model),
 label strings such as `"//foo:bar"` that occur in a macro are interpreted
 relative to the `BUILD` file in which the macro is used rather than relative to
 the `.bzl` file in which it is defined. This behavior is generally undesirable
@@ -213,8 +213,7 @@ def my_macro(name, deps, visibility=None):
     instantiate rules must have a `name` argument. This argument should not be
     optional (don't give a default value).
 
-*   Public functions should use a docstring following [Python
-    conventions](https://www.python.org/dev/peps/pep-0257/#one-line-docstrings).
+*   Public functions should use a docstring following [Python conventions](https://www.python.org/dev/peps/pep-0257/#one-line-docstrings).
 
 *   In `BUILD` files, the `name` argument of the macros must be a keyword
     argument (not a positional argument).
diff --git a/versions/6.5.0/extending/platforms.mdx b/versions/6.5.0/extending/platforms.mdx
index d1254fec..c29552ba 100644
--- a/versions/6.5.0/extending/platforms.mdx
+++ b/versions/6.5.0/extending/platforms.mdx
@@ -14,10 +14,10 @@ resources that are available in some environment.
 
 Modeling the environment as a platform helps Bazel to automatically select the
 appropriate
-[toolchains](/docs/toolchains)
+[toolchains](/versions/6.5.0/docs/toolchains)
 for build actions. Platforms can also be used in combination with the
-[config_setting](/reference/be/general#config_setting)
-rule to write [configurable attributes](/docs/configurable-attributes).
+[config_setting](/versions/6.5.0/reference/be/general#config_setting)
+rule to write [configurable attributes](/versions/6.5.0/docs/configurable-attributes).
 
 Bazel recognizes three roles that a platform may serve:
 
@@ -42,8 +42,8 @@ Bazel supports the following build scenarios regarding platforms:
 ## Defining constraints and platforms
 
 The space of possible choices for platforms is defined by using the
- [`constraint_setting`](/reference/be/platform#constraint_setting) and
- [`constraint_value`](/reference/be/platform#constraint_value) rules within `BUILD` files. `constraint_setting` creates a new dimension, while
+ [`constraint_setting`](/versions/6.5.0/reference/be/platform#constraint_setting) and
+ [`constraint_value`](/versions/6.5.0/reference/be/platform#constraint_value) rules within `BUILD` files. `constraint_setting` creates a new dimension, while
 `constraint_value` creates a new value for a given dimension; together they
 effectively define an enum and its possible values. For example, the following
 snippet of a `BUILD` file introduces a constraint for the system's glibc version
@@ -68,7 +68,7 @@ workspace. They are referenced by label and subject to the usual visibility
 controls. If visibility allows, you can extend an existing constraint setting by
 defining your own value for it.
 
-The [`platform`](/reference/be/platform#platform) rule introduces a new platform with
+The [`platform`](/versions/6.5.0/reference/be/platform#platform) rule introduces a new platform with
 certain choices of constraint values. The
 following creates a platform named `linux_x86`, and says that it describes any
 environment that runs a Linux operating system on an x86_64 architecture with a
@@ -114,7 +114,7 @@ When building for a specific target platform it is often desirable to skip
 targets that will never work on that platform. For example, your Windows device
 driver is likely going to generate lots of compiler errors when building on a
 Linux machine with `//...`. Use the
-[`target_compatible_with`](/reference/be/common-definitions#common.target_compatible_with)
+[`target_compatible_with`](/versions/6.5.0/reference/be/common-definitions#common.target_compatible_with)
 attribute to tell Bazel what target platform constraints your code has.
 
 The simplest use of this attribute restricts a target to a single platform.
@@ -152,9 +152,9 @@ $ bazel build --platforms=//:myplatform //...
 $ bazel build --platforms=//:myplatform //:all
 ```
 
-Incompatible tests in a [`test_suite`](/reference/be/general#test_suite) are
+Incompatible tests in a [`test_suite`](/versions/6.5.0/reference/be/general#test_suite) are
 similarly skipped if the `test_suite` is specified on the command line with
-[`--expand_test_suites`](/reference/command-line-reference#flag--expand_test_suites).
+[`--expand_test_suites`](/versions/6.5.0/reference/command-line-reference#flag--expand_test_suites).
 In other words, `test_suite` targets on the command line behave like `:all` and
 `...`. Using `--noexpand_test_suites` prevents expansion and causes
 `test_suite` targets with incompatible tests to also be incompatible.
@@ -174,10 +174,10 @@ FAILED: Build did NOT complete successfully
 
 For more flexibility in expressing constraints, use the
 `@platforms//:incompatible`
-[`constraint_value`](/reference/be/platform#constraint_value) that no platform
+[`constraint_value`](/versions/6.5.0/reference/be/platform#constraint_value) that no platform
 satisfies.
 
-Use [`select()`](/reference/be/functions#select) in combination with
+Use [`select()`](/versions/6.5.0/reference/be/functions#select) in combination with
 `@platforms//:incompatible` to express more complicated restrictions. For
 example, use it to implement basic OR logic. The following marks a library
 compatible with macOS and Linux, but no other platforms.
@@ -225,9 +225,8 @@ cc_library(
 ### Detecting incompatible targets using `bazel cquery` {#cquery-incompatible-target-detection}
 
 You can use the
-[`IncompatiblePlatformProvider`](/rules/lib/IncompatiblePlatformProvider)
-in `bazel cquery`'s [Starlark output
-format](/docs/cquery#output-format-definition) to distinguish
+[`IncompatiblePlatformProvider`](/versions/6.5.0/rules/lib/providers/IncompatiblePlatformProvider)
+in `bazel cquery`'s [Starlark output format](/versions/6.5.0/docs/cquery#output-format-definition) to distinguish
 incompatible targets from compatible ones.
 
 This can be used to filter out incompatible targets. The example below will
@@ -248,5 +247,4 @@ $ bazel cquery //... --output=starlark --starlark:file=example.cquery
 
 ### Known Issues
 
-Incompatible targets [ignore visibility
-restrictions](https://github.com/bazelbuild/bazel/issues/16044).
+Incompatible targets [ignore visibility restrictions](https://github.com/bazelbuild/bazel/issues/16044).
diff --git a/versions/6.5.0/extending/repo.mdx b/versions/6.5.0/extending/repo.mdx
index 8b603987..d20e512e 100644
--- a/versions/6.5.0/extending/repo.mdx
+++ b/versions/6.5.0/extending/repo.mdx
@@ -6,7 +6,7 @@ title: 'Repository Rules'
 This page covers how to create repository rules and provides examples for
 more details.
 
-An [external repository](/docs/external) is a rule that can be used only
+An [external repository](/versions/6.5.0/docs/external) is a rule that can be used only
 in the `WORKSPACE` file and enables non-hermetic operation at the loading phase
 of Bazel. Each external repository rule creates its own workspace, with its
 own `BUILD` files and artifacts. They can be used to depend on third-party
@@ -16,7 +16,7 @@ specific to the host Bazel is running on.
 ## Repository rule creation
 
 In a `.bzl` file, use the
-[repository_rule](/rules/lib/globals#repository_rule) function to create a new
+[repository_rule](/versions/6.5.0/rules/lib/globals#repository_rule) function to create a new
 repository rule and store it in a global variable.
 
 A custom repository rule can be used just like a native repository rule. It
@@ -47,9 +47,9 @@ rules). The two implicit attributes are `name` (just like for build rules) and
 `repo_mapping`. The name of a repository rule is accessible with
 `repository_ctx.name`. The meaning of `repo_mapping` is the same as for the
 native repository rules
-[`local_repository`](https://bazel.build/reference/be/workspace#local_repository.repo_mapping)
+[`local_repository`](https://bazel.build/versions/6.5.0/reference/be/workspace#local_repository.repo_mapping)
 and
-[`new_local_repository`](https://bazel.build/reference/be/workspace#new_local_repository.repo_mapping).
+[`new_local_repository`](https://bazel.build/versions/6.5.0/reference/be/workspace#new_local_repository.repo_mapping).
 
 If an attribute name starts with `_` it is private and users cannot set it.
 
@@ -69,7 +69,7 @@ specified.
 The input parameter `repository_ctx` can be used to
 access attribute values, and non-hermetic functions (finding a binary,
 executing a binary, creating a file in the repository or downloading a file
-from the Internet). See [the library](/rules/lib/repository_ctx) for more
+from the Internet). See [the library](/versions/6.5.0/rules/lib/builtins/repository_ctx) for more
 context. Example:
 
 ```python
@@ -103,10 +103,10 @@ dependencies might cause a restart:
 - Declaration of the repository rule in the `WORKSPACE` file.
 - Value of any environment variable declared with the `environ`
 attribute of the
-[`repository_rule`](/rules/lib/globals#repository_rule)
+[`repository_rule`](/versions/6.5.0/rules/lib/globals#repository_rule)
 function. The value of those environment variable can be enforced from
 the command line with the
-[`--action_env`](/reference/command-line-reference#flag--action_env)
+[`--action_env`](/versions/6.5.0/reference/command-line-reference#flag--action_env)
 flag (but this flag will invalidate every action of the build).
 - Content of any file used and referred to by a label (for example,
   `//mypkg:label.txt` not `mypkg/label.txt`).
@@ -122,7 +122,7 @@ external repositories unconditionally by calling `bazel sync`.
 Moreover, some rules inspect the local machine and might become
 outdated if the local machine was upgraded. Here you can ask bazel to
 only refetch those external repositories where the
-[`repository_rule`](/rules/lib/globals#repository_rule)
+[`repository_rule`](/versions/6.5.0/rules/lib/globals#repository_rule)
 definition has the `configure` attribute set, use `bazel sync --configure`.
 
 
diff --git a/versions/6.5.0/extending/rules.mdx b/versions/6.5.0/extending/rules.mdx
index 54f47ef3..54affe1f 100644
--- a/versions/6.5.0/extending/rules.mdx
+++ b/versions/6.5.0/extending/rules.mdx
@@ -22,10 +22,10 @@ inputs to a rule, but also all of the tools and libraries required to execute
 the actions.
 
 Before creating or modifying any rule, ensure you are familiar with Bazel's
-[build phases](/rules/concepts). It is important to understand the three
+[build phases](/versions/6.5.0/rules/concepts). It is important to understand the three
 phases of a build (loading, analysis, and execution). It is also useful to
-learn about [macros](/rules/macros) to understand the difference between rules and
-macros. To get started, first review the [Rules Tutorial](/rules/rules-tutorial).
+learn about [macros](/versions/6.5.0/rules/macros) to understand the difference between rules and
+macros. To get started, first review the [Rules Tutorial](/versions/6.5.0/rules/rules-tutorial).
 Then, use this page as a reference.
 
 A few rules are built into Bazel itself. These *native rules*, such as
@@ -34,21 +34,21 @@ By defining your own rules, you can add similar support for languages and tools
 that Bazel does not support natively.
 
 Bazel provides an extensibility model for writing rules using the
-[Starlark](/rules/language) language. These rules are written in `.bzl` files, which
+[Starlark](/versions/6.5.0/rules/language) language. These rules are written in `.bzl` files, which
 can be loaded directly from `BUILD` files.
 
 When defining your own rule, you get to decide what attributes it supports and
 how it generates its outputs.
 
 The rule's `implementation` function defines its exact behavior during the
-[analysis phase](/rules/concepts#evaluation-model). This function does not run any
+[analysis phase](/versions/6.5.0/rules/concepts#evaluation-model). This function does not run any
 external commands. Rather, it registers [actions](#actions) that will be used
 later during the execution phase to build the rule's outputs, if they are
 needed.
 
 ## Rule creation
 
-In a `.bzl` file, use the [rule](/rules/lib/globals#rule) function to define a new
+In a `.bzl` file, use the [rule](/versions/6.5.0/rules/lib/globals#rule) function to define a new
 rule, and store the result in a global variable. The call to `rule` specifies
 [attributes](#attributes) and an
 [implementation function](#implementation_function):
@@ -63,7 +63,7 @@ example_library = rule(
 )
 ```
 
-This defines a [kind of rule](/reference/query#kind) named `example_library`.
+This defines a [kind of rule](/versions/6.5.0/reference/query#kind) named `example_library`.
 
 The call to `rule` also must specify if the rule creates an
 [executable](#executable-rules) output (with `executable=True`), or specifically
@@ -72,7 +72,7 @@ and the name of the rule must end in `_test`.
 
 ## Target instantiation
 
-Rules can be [loaded](/concepts/build-files#load) and called in `BUILD` files:
+Rules can be [loaded](/versions/6.5.0/concepts/build-files#load) and called in `BUILD` files:
 
 ```python
 load('//some/pkg:rules.bzl', 'example_library')
@@ -89,9 +89,9 @@ a target. This is called *instantiating* the rule. This specifies a name for the
 new target and values for the target's [attributes](#attributes).
 
 Rules can also be called from Starlark functions and loaded in `.bzl` files.
-Starlark functions that call rules are called [Starlark macros](/rules/macros).
+Starlark functions that call rules are called [Starlark macros](/versions/6.5.0/rules/macros).
 Starlark macros must ultimately be called from `BUILD` files, and can only be
-called during the [loading phase](/rules/concepts#evaluation-model), when `BUILD`
+called during the [loading phase](/versions/6.5.0/rules/concepts#evaluation-model), when `BUILD`
 files are evaluated to instantiate targets.
 
 ## Attributes
@@ -101,9 +101,9 @@ target's [implementation](#implementation_function), or they can refer to other
 targets, creating a graph of dependencies.
 
 Rule-specific attributes, such as `srcs` or `deps`, are defined by passing a map
-from attribute names to schemas (created using the [`attr`](/rules/lib/attr)
+from attribute names to schemas (created using the [`attr`](/versions/6.5.0/rules/lib/toplevel/attr)
 module) to the `attrs` parameter of `rule`.
-[Common attributes](/reference/be/common-definitions#common-attributes), such as
+[Common attributes](/versions/6.5.0/reference/be/common-definitions#common-attributes), such as
 `name` and `visibility`, are implicitly added to all rules. Additional
 attributes are implicitly added to
 [executable and test rules](#executable-rules) specifically. Attributes which
@@ -113,7 +113,7 @@ are implicitly added to a rule cannot be included in the dictionary passed to
 ### Dependency attributes
 
 Rules that process source code usually define the following attributes to handle
-various [types of dependencies](/concepts/dependencies#types_of_dependencies):
+various [types of dependencies](/versions/6.5.0/concepts/dependencies#types_of_dependencies):
 
 *   `srcs` specifies source files processed by a target's actions. Often, the
     attribute schema specifies which file extensions are expected for the sort
@@ -142,12 +142,12 @@ example_library = rule(
 
 These are examples of *dependency attributes*. Any attribute that specifies
 an input label (those defined with
-[`attr.label_list`](/rules/lib/attr#label_list),
-[`attr.label`](/rules/lib/attr#label), or
-[`attr.label_keyed_string_dict`](/rules/lib/attr#label_keyed_string_dict))
+[`attr.label_list`](/versions/6.5.0/rules/lib/toplevel/attr#label_list),
+[`attr.label`](/versions/6.5.0/rules/lib/toplevel/attr#label), or
+[`attr.label_keyed_string_dict`](/versions/6.5.0/rules/lib/toplevel/attr#label_keyed_string_dict))
 specifies dependencies of a certain type
 between a target and the targets whose labels (or the corresponding
-[`Label`](/rules/lib/Label) objects) are listed in that attribute when the target
+[`Label`](/versions/6.5.0/rules/lib/builtins/Label) objects) are listed in that attribute when the target
 is defined. The repository, and possibly the path, for these labels is resolved
 relative to the defined target.
 
@@ -213,13 +213,13 @@ label.
 
 Implicit dependencies are generally used for tools that reside in the same
 repository as the rule implementation. If the tool comes from the
-[execution platform](/docs/platforms) or a different repository instead, the
-rule should obtain that tool from a [toolchain](/docs/toolchains).
+[execution platform](/versions/6.5.0/docs/platforms) or a different repository instead, the
+rule should obtain that tool from a [toolchain](/versions/6.5.0/docs/toolchains).
 
 ### Output attributes
 
-*Output attributes*, such as [`attr.output`](/rules/lib/attr#output) and
-[`attr.output_list`](/rules/lib/attr#output_list), declare an output file that the
+*Output attributes*, such as [`attr.output`](/versions/6.5.0/rules/lib/toplevel/attr#output) and
+[`attr.output_list`](/versions/6.5.0/rules/lib/toplevel/attr#output_list), declare an output file that the
 target generates. These differ from dependency attributes in two ways:
 
 *   They define output file targets instead of referring to targets defined
@@ -238,7 +238,7 @@ can be specifically depended upon or
 ## Implementation function
 
 Every rule requires an `implementation` function. These functions are executed
-strictly in the [analysis phase](/rules/concepts#evaluation-model) and transform the
+strictly in the [analysis phase](/versions/6.5.0/rules/concepts#evaluation-model) and transform the
 graph of targets generated in the loading phase into a graph of
 [actions](#actions) to be performed during the execution phase. As such,
 implementation functions can not actually read or write files.
@@ -248,16 +248,16 @@ underscore). Conventionally, they are named the same as their rule, but suffixed
 with `_impl`.
 
 Implementation functions take exactly one parameter: a
-[rule context](/rules/lib/ctx), conventionally named `ctx`. They return a list of
+[rule context](/versions/6.5.0/rules/lib/builtins/ctx), conventionally named `ctx`. They return a list of
 [providers](#providers).
 
 ### Targets
 
-Dependencies are represented at analysis time as [`Target`](/rules/lib/Target)
+Dependencies are represented at analysis time as [`Target`](/versions/6.5.0/rules/lib/builtins/Target)
 objects. These objects contain the [providers](#providers) generated when the
 target's implementation function was executed.
 
-[`ctx.attr`](/rules/lib/ctx#attr) has fields corresponding to the names of each
+[`ctx.attr`](/versions/6.5.0/rules/lib/builtins/ctx#attr) has fields corresponding to the names of each
 dependency attribute, containing `Target` objects representing each direct
 dependency via that attribute. For `label_list` attributes, this is a list of
 `Targets`. For `label` attributes, this is a single `Target` or `None`.
@@ -270,7 +270,7 @@ return [ExampleInfo(headers = depset(...))]
 
 Those can be accessed using index notation (`[]`), with the type of provider as
 a key. These can be [custom providers](#custom_providers) defined in Starlark or
-[providers for native rules](/rules/lib/starlark-provider) available as Starlark
+[providers for native rules](/versions/6.5.0/rules/lib/starlark-provider) available as Starlark
 global variables.
 
 For example, if a rule takes header files via a `hdrs` attribute and provides
@@ -283,7 +283,7 @@ def _example_library_impl(ctx):
     transitive_headers = [hdr[ExampleInfo].headers for hdr in ctx.attr.hdrs]
 ```
 
-For the legacy style in which a [`struct`](/rules/lib/struct) is returned from a
+For the legacy style in which a [`struct`](/versions/6.5.0/rules/lib/builtins/struct) is returned from a
 target's implementation function instead of a list of provider objects:
 
 ```python
@@ -301,10 +301,10 @@ This style is strongly discouraged and rules should be
 
 ### Files
 
-Files are represented by [`File`](/rules/lib/File) objects. Since Bazel does not
+Files are represented by [`File`](/versions/6.5.0/rules/lib/builtins/File) objects. Since Bazel does not
 perform file I/O during the analysis phase, these objects cannot be used to
 directly read or write file content. Rather, they are passed to action-emitting
-functions (see [`ctx.actions`](/rules/lib/actions)) to construct pieces of the
+functions (see [`ctx.actions`](/versions/6.5.0/rules/lib/builtins/actions)) to construct pieces of the
 action graph.
 
 A `File` can either be a source file or a generated file. Each generated file
@@ -312,7 +312,7 @@ must be an output of exactly one action. Source files cannot be the output of
 any action.
 
 For each dependency attribute, the corresponding field of
-[`ctx.files`](/rules/lib/ctx#files) contains a list of the default outputs of all
+[`ctx.files`](/versions/6.5.0/rules/lib/builtins/ctx#files) contains a list of the default outputs of all
 dependencies via that attribute:
 
 ```python
@@ -323,9 +323,9 @@ def _example_library_impl(ctx):
     ...
 ```
 
-[`ctx.file`](/rules/lib/ctx#file) contains a single `File` or `None` for
+[`ctx.file`](/versions/6.5.0/rules/lib/builtins/ctx#file) contains a single `File` or `None` for
 dependency attributes whose specs set `allow_single_file=True`.
-[`ctx.executable`](/rules/lib/ctx#executable) behaves the same as `ctx.file`, but only
+[`ctx.executable`](/versions/6.5.0/rules/lib/builtins/ctx#executable) behaves the same as `ctx.file`, but only
 contains fields for dependency attributes whose specs set `executable=True`.
 
 ### Declaring outputs
@@ -333,10 +333,10 @@ contains fields for dependency attributes whose specs set `executable=True`.
 During the analysis phase, a rule's implementation function can create outputs.
 Since all labels have to be known during the loading phase, these additional
 outputs have no labels. `File` objects for outputs can be created using using
-[`ctx.actions.declare_file`](/rules/lib/actions#declare_file) and
-[`ctx.actions.declare_directory`](/rules/lib/actions#declare_directory). Often,
+[`ctx.actions.declare_file`](/versions/6.5.0/rules/lib/builtins/actions#declare_file) and
+[`ctx.actions.declare_directory`](/versions/6.5.0/rules/lib/builtins/actions#declare_directory). Often,
 the names of outputs are based on the target's name,
-[`ctx.label.name`](/rules/lib/ctx#label):
+[`ctx.label.name`](/versions/6.5.0/rules/lib/builtins/ctx#label):
 
 ```python
 def _example_library_impl(ctx):
@@ -347,7 +347,7 @@ def _example_library_impl(ctx):
 
 For *predeclared outputs*, like those created for
 [output attributes](#output_attributes), `File` objects instead can be retrieved
-from the corresponding fields of [`ctx.outputs`](/rules/lib/ctx#outputs).
+from the corresponding fields of [`ctx.outputs`](/versions/6.5.0/rules/lib/builtins/ctx#outputs).
 
 ### Actions
 
@@ -358,16 +358,16 @@ because an action can depend on the output of another action. For example, in C,
 the linker must be called after the compiler.
 
 General-purpose functions that create actions are defined in
-[`ctx.actions`](/rules/lib/actions):
+[`ctx.actions`](/versions/6.5.0/rules/lib/builtins/actions):
 
-*   [`ctx.actions.run`](/rules/lib/actions#run), to run an executable.
-*   [`ctx.actions.run_shell`](/rules/lib/actions#run_shell), to run a shell
+*   [`ctx.actions.run`](/versions/6.5.0/rules/lib/builtins/actions#run), to run an executable.
+*   [`ctx.actions.run_shell`](/versions/6.5.0/rules/lib/builtins/actions#run_shell), to run a shell
     command.
-*   [`ctx.actions.write`](/rules/lib/actions#write), to write a string to a file.
-*   [`ctx.actions.expand_template`](/rules/lib/actions#expand_template), to
+*   [`ctx.actions.write`](/versions/6.5.0/rules/lib/builtins/actions#write), to write a string to a file.
+*   [`ctx.actions.expand_template`](/versions/6.5.0/rules/lib/builtins/actions#expand_template), to
     generate a file from a template.
 
-[`ctx.actions.args`](/rules/lib/actions#args) can be used to efficiently
+[`ctx.actions.args`](/versions/6.5.0/rules/lib/builtins/actions#args) can be used to efficiently
 accumulate the arguments for actions. It avoids flattening depsets until
 execution time:
 
@@ -398,7 +398,7 @@ def _example_library_impl(ctx):
 
 Actions take a list or depset of input files and generate a (non-empty) list of
 output files. The set of input and output files must be known during the
-[analysis phase](/rules/concepts#evaluation-model). It might depend on the value of
+[analysis phase](/versions/6.5.0/rules/concepts#evaluation-model). It might depend on the value of
 attributes, including providers from dependencies, but it cannot depend on the
 result of the execution. For example, if your action runs the unzip command, you
 must specify which files you expect to be inflated (before running unzip).
@@ -432,13 +432,13 @@ about.
 Since a rule's implementation function can only read providers from the
 instantiated target's immediate dependencies, rules need to forward any
 information from a target's dependencies that needs to be known by a target's
-consumers, generally by accumulating that into a [`depset`](/rules/lib/depset).
+consumers, generally by accumulating that into a [`depset`](/versions/6.5.0/rules/lib/builtins/depset).
 
 A target's providers are specified by a list of `Provider` objects returned by
 the implementation function.
 
 Old implementation functions can also be written in a legacy style where the
-implementation function returns a [`struct`](/rules/lib/struct) instead of list of
+implementation function returns a [`struct`](/versions/6.5.0/rules/lib/builtins/struct) instead of list of
 provider objects. This style is strongly discouraged and rules should be
 [migrated away from it](#migrating_from_legacy_providers).
 
@@ -450,7 +450,7 @@ the target is requested for build at the command line. For example, a
 will be built by the command `bazel build //pkg:foo`.
 
 Default outputs are specified by the `files` parameter of
-[`DefaultInfo`](/rules/lib/DefaultInfo):
+[`DefaultInfo`](/versions/6.5.0/rules/lib/providers/DefaultInfo):
 
 ```python
 def _example_library_impl(ctx):
@@ -463,8 +463,7 @@ def _example_library_impl(ctx):
 
 If `DefaultInfo` is not returned by a rule implementation or the `files`
 parameter is not specified, `DefaultInfo.files` defaults to all
-*predeclared outputs* (generally, those created by [output
-attributes](#output_attributes)).
+*predeclared outputs* (generally, those created by [output attributes](#output_attributes)).
 
 Rules that perform actions should provide default outputs, even if those outputs
 are not expected to be directly used. Actions that are not in the graph of the
@@ -476,18 +475,18 @@ reproduce the failure.
 #### Runfiles
 
 Runfiles are a set of files used by a target at runtime (as opposed to build
-time). During the [execution phase](/rules/concepts#evaluation-model), Bazel creates
+time). During the [execution phase](/versions/6.5.0/rules/concepts#evaluation-model), Bazel creates
 a directory tree containing symlinks pointing to the runfiles. This stages the
 environment for the binary so it can access the runfiles during runtime.
 
 Runfiles can be added manually during rule creation.
-[`runfiles`](/rules/lib/runfiles) objects can be created by the `runfiles` method
-on the rule context, [`ctx.runfiles`](/rules/lib/ctx#runfiles) and passed to the
+[`runfiles`](/versions/6.5.0/rules/lib/builtins/runfiles) objects can be created by the `runfiles` method
+on the rule context, [`ctx.runfiles`](/versions/6.5.0/rules/lib/builtins/ctx#runfiles) and passed to the
 `runfiles` parameter on `DefaultInfo`. The executable output of
 [executable rules](#executable-rules) is implicitly added to the runfiles.
 
 Some rules specify attributes, generally named
-[`data`](/reference/be/common-definitions#common.data), whose outputs are added to
+[`data`](/versions/6.5.0/reference/be/common-definitions#common.data), whose outputs are added to
 a targets' runfiles. Runfiles should also be merged in from `data`, as well as
 from any attributes which might provide code for eventual execution, generally
 `srcs` (which might contain `filegroup` targets with associated `data`) and
@@ -515,7 +514,7 @@ def _example_library_impl(ctx):
 
 #### Custom providers
 
-Providers can be defined using the [`provider`](/rules/lib/globals#provider)
+Providers can be defined using the [`provider`](/versions/6.5.0/rules/lib/globals#provider)
 function to convey rule-specific information:
 
 ```python
@@ -554,7 +553,7 @@ provider instances obey certain invariants, or to give users a cleaner API for
 obtaining an instance.
 
 This is done by passing an `init` callback to the
-[`provider`](/rules/lib/globals.html#provider) function. If this callback is given, the
+[`provider`](/versions/6.5.0/rules/lib/globals#provider) function. If this callback is given, the
 return type of `provider()` changes to be a tuple of two values: the provider
 symbol that is the ordinary return value when `init` is not used, and a "raw
 constructor".
@@ -636,8 +635,8 @@ def make_exampleinfo(...):
 Executable rules define targets that can be invoked by a `bazel run` command.
 Test rules are a special kind of executable rule whose targets can also be
 invoked by a `bazel test` command. Executable and test rules are created by
-setting the respective [`executable`](/rules/lib/globals#rule.executable) or
-[`test`](/rules/lib/globals#rule.test) argument to `True` in the call to `rule`:
+setting the respective [`executable`](/versions/6.5.0/rules/lib/globals#rule.executable) or
+[`test`](/versions/6.5.0/rules/lib/globals#rule.test) argument to `True` in the call to `rule`:
 
 ```python
 example_binary = rule(
@@ -660,7 +659,7 @@ have this suffix.
 Both kinds of rules must produce an executable output file (which may or may not
 be predeclared) that will be invoked by the `run` or `test` commands. To tell
 Bazel which of a rule's outputs to use as this executable, pass it as the
-`executable` argument of a returned [`DefaultInfo`](/rules/lib/DefaultInfo)
+`executable` argument of a returned [`DefaultInfo`](/versions/6.5.0/rules/lib/providers/DefaultInfo)
 provider. That `executable` is added to the default outputs of the rule (so you
 don't need to pass that to both `executable` and `files`). It's also implicitly
 added to the [runfiles](#runfiles):
@@ -676,10 +675,10 @@ def _example_binary_impl(ctx):
 ```
 
 The action that generates this file must set the executable bit on the file. For
-a [`ctx.actions.run`](/rules/lib/actions#run) or
-[`ctx.actions.run_shell`](/rules/lib/actions#run_shell) action this should be done
+a [`ctx.actions.run`](/versions/6.5.0/rules/lib/builtins/actions#run) or
+[`ctx.actions.run_shell`](/versions/6.5.0/rules/lib/builtins/actions#run_shell) action this should be done
 by the underlying tool that is invoked by the action. For a
-[`ctx.actions.write`](/rules/lib/actions#write) action, pass `is_executable=True`.
+[`ctx.actions.write`](/versions/6.5.0/rules/lib/builtins/actions#write) action, pass `is_executable=True`.
 
 As [legacy behavior](#deprecated_predeclared_outputs), executable rules have a
 special `ctx.outputs.executable` predeclared output. This file serves as the
@@ -692,12 +691,12 @@ See examples of an
 and a
 [test rule](https://github.com/bazelbuild/examples/blob/main/rules/test_rule/line_length.bzl).
 
-[Executable rules](/reference/be/common-definitions#common-attributes-binaries) and
-[test rules](/reference/be/common-definitions#common-attributes-tests) have additional
+[Executable rules](/versions/6.5.0/reference/be/common-definitions#common-attributes-binaries) and
+[test rules](/versions/6.5.0/reference/be/common-definitions#common-attributes-tests) have additional
 attributes implicitly defined, in addition to those added for
-[all rules](/reference/be/common-definitions#common-attributes). The defaults of
+[all rules](/versions/6.5.0/reference/be/common-definitions#common-attributes). The defaults of
 implicitly-added attributes cannot be changed, though this can be worked around
-by wrapping a private rule in a [Starlark macro](/rules/macros) which alters the
+by wrapping a private rule in a [Starlark macro](/versions/6.5.0/rules/macros) which alters the
 default:
 
 ```python
@@ -724,7 +723,7 @@ execution_root_relative_path = "%s/%s/%s" % (
 ```
 
 The path to a `File` under the runfiles directory corresponds to
-[`File.short_path`](/rules/lib/File#short_path).
+[`File.short_path`](/versions/6.5.0/rules/lib/builtins/File#short_path).
 
 The binary executed directly by `bazel` is adjacent to the root of the
 `runfiles` directory. However, binaries called *from* the runfiles can't make
@@ -749,14 +748,14 @@ In addition to [default outputs](#default_outputs), any *predeclared output* can
 be explicitly requested on the command line. Rules can specify predeclared
 outputs via [output attributes](#output_attributes). In that case, the user
 explicitly chooses labels for outputs when they instantiate the rule. To obtain
-[`File`](/rules/lib/File) objects for output attributes, use the corresponding
-attribute of [`ctx.outputs`](/rules/lib/ctx#outputs). Rules can
+[`File`](/versions/6.5.0/rules/lib/builtins/File) objects for output attributes, use the corresponding
+attribute of [`ctx.outputs`](/versions/6.5.0/rules/lib/builtins/ctx#outputs). Rules can
 [implicitly define predeclared outputs](#deprecated_predeclared_outputs) based
 on the target name as well, but this feature is deprecated.
 
 In addition to default outputs, there are *output groups*, which are collections
 of output files that may be requested together. These can be requested with
-[`--output_groups`](/reference/command-line-reference#flag--output_groups). For
+[`--output_groups`](/versions/6.5.0/reference/command-line-reference#flag--output_groups). For
 example, if a target `//pkg:mytarget` is of a rule type that has a `debug_files`
 output group, these files can be built by running `bazel build //pkg:mytarget
 --output_groups=debug_files`. Since non-predeclared outputs don't have labels,
@@ -764,7 +763,7 @@ they can only be requested by appearing in the default outputs or an output
 group.
 
 Output groups can be specified with the
-[`OutputGroupInfo`](/rules/lib/OutputGroupInfo) provider. Note that unlike many
+[`OutputGroupInfo`](/versions/6.5.0/rules/lib/providers/OutputGroupInfo) provider. Note that unlike many
 built-in providers, `OutputGroupInfo` can take parameters with arbitrary names
 to define output groups with that name:
 
@@ -784,7 +783,7 @@ def _example_library_impl(ctx):
 ```
 
 Also unlike most providers, `OutputGroupInfo` can be returned by both an
-[aspect](/rules/aspects) and the rule target to which that aspect is applied, as
+[aspect](/versions/6.5.0/rules/aspects) and the rule target to which that aspect is applied, as
 long as they do not define the same output groups. In that case, the resulting
 providers are merged.
 
@@ -797,7 +796,7 @@ of files from a target to the actions of its consumers. Define
 Imagine that you want to build a C++ binary for a different architecture. The
 build can be complex and involve multiple steps. Some of the intermediate
 binaries, like compilers and code generators, have to run on
-[the execution platform](/docs/platforms#overview) (which could be your host,
+[the execution platform](/versions/6.5.0/docs/platforms#overview) (which could be your host,
 or a remote executor). Some binaries like the final output must be built for the
 target architecture.
 
@@ -839,10 +838,10 @@ help rule designers be explicit about their intentions. When `executable=False`,
 which means `cfg` is optional, only set this when it truly helps readability.
 
 You can also use `cfg=my_transition` to use
-[user-defined transitions](/rules/config#user-defined-transitions), which allow
+[user-defined transitions](/versions/6.5.0/rules/config#user-defined-transitions), which allow
 rule authors a great deal of flexibility in changing configurations, with the
 drawback of
-[making the build graph larger and less comprehensible](/rules/config#memory-and-performance-considerations).
+[making the build graph larger and less comprehensible](/versions/6.5.0/rules/config#memory-and-performance-considerations).
 
 **Note**: Historically, Bazel didn't have the concept of execution platforms,
 and instead all build actions were considered to run on the host machine.
@@ -876,7 +875,7 @@ starts with the **current** values of flags, based on the target configuration.
 ### Configuration fragments
 
 Rules may access
-[configuration fragments](/rules/lib/starlark-configuration-fragment) such as
+[configuration fragments](/versions/6.5.0/rules/lib/starlark-configuration-fragment) such as
 `cpp`, `java` and `jvm`. However, all required fragments must be declared in
 order to avoid access errors:
 
@@ -936,18 +935,18 @@ all of its dependencies.
 
 ### Code coverage
 
-When the [`coverage`](/reference/command-line-reference#coverage) command is run,
+When the [`coverage`](/versions/6.5.0/reference/command-line-reference#coverage) command is run,
 the build may need to add coverage instrumentation for certain targets. The
 build also gathers the list of source files that are instrumented. The subset of
 targets that are considered is controlled by the flag
-[`--instrumentation_filter`](/reference/command-line-reference#flag--instrumentation_filter).
+[`--instrumentation_filter`](/versions/6.5.0/reference/command-line-reference#flag--instrumentation_filter).
 Test targets are excluded, unless
-[`--instrument_test_targets`](/reference/command-line-reference#flag--instrument_test_targets)
+[`--instrument_test_targets`](/versions/6.5.0/reference/command-line-reference#flag--instrument_test_targets)
 is specified.
 
 If a rule implementation adds coverage instrumentation at build time, it needs
 to account for that in its implementation function.
-[ctx.coverage_instrumented](/rules/lib/ctx#coverage_instrumented) returns true in
+[ctx.coverage_instrumented](/versions/6.5.0/rules/lib/builtins/ctx#coverage_instrumented) returns true in
 coverage mode if a target's sources should be instrumented:
 
 ```python
@@ -958,7 +957,7 @@ if ctx.coverage_instrumented():
 
 Logic that always needs to be on in coverage mode (whether a target's sources
 specifically are instrumented or not) can be conditioned on
-[ctx.configuration.coverage_enabled](/rules/lib/configuration#coverage_enabled).
+[ctx.configuration.coverage_enabled](/versions/6.5.0/rules/lib/builtins/configuration#coverage_enabled).
 
 If the rule directly includes sources from its dependencies before compilation
 (such as header files), it may also need to turn on compile-time instrumentation if
@@ -975,7 +974,7 @@ if (ctx.configuration.coverage_enabled and
 
 Rules also should provide information about which attributes are relevant for
 coverage with the `InstrumentedFilesInfo` provider, constructed using
-[`coverage_common.instrumented_files_info`](/rules/lib/coverage_common#instrumented_files_info).
+[`coverage_common.instrumented_files_info`](/versions/6.5.0/rules/lib/toplevel/coverage_common#instrumented_files_info).
 The `dependency_attributes` parameter of `instrumented_files_info` should list
 all runtime dependency attributes, including code dependencies like `deps` and
 data dependencies like `data`. The `source_attributes` parameter should list the
@@ -1161,7 +1160,7 @@ flag, which defaults to true.
 
 There are two **deprecated** ways of using predeclared outputs:
 
-*   The [`outputs`](/rules/lib/globals#rule.outputs) parameter of `rule` specifies
+*   The [`outputs`](/versions/6.5.0/rules/lib/globals#rule.outputs) parameter of `rule` specifies
     a mapping between output attribute names and string templates for generating
     predeclared output labels. Prefer using non-predeclared outputs and
     explicitly adding outputs to `DefaultInfo.files`. Use the rule target's
@@ -1177,12 +1176,12 @@ There are two **deprecated** ways of using predeclared outputs:
 
 ### Runfiles features to avoid
 
-[`ctx.runfiles`](/rules/lib/ctx#runfiles) and the [`runfiles`](/rules/lib/runfiles)
+[`ctx.runfiles`](/versions/6.5.0/rules/lib/builtins/ctx#runfiles) and the [`runfiles`](/versions/6.5.0/rules/lib/builtins/runfiles)
 type have a complex set of features, many of which are kept for legacy reasons.
 The following recommendations help reduce complexity:
 
 *   **Avoid** use of the `collect_data` and `collect_default` modes of
-    [`ctx.runfiles`](/rules/lib/ctx#runfiles). These modes implicitly collect
+    [`ctx.runfiles`](/versions/6.5.0/rules/lib/builtins/ctx#runfiles). These modes implicitly collect
     runfiles across certain hardcoded dependency edges in confusing ways.
     Instead, add files using the `files` or `transitive_files` parameters of
     `ctx.runfiles`, or by merging in runfiles from dependencies with
@@ -1195,7 +1194,7 @@ The following recommendations help reduce complexity:
     `data_runfiles`, but not `default_runfiles`. Instead of using
     `data_runfiles`, rules should *both* include default outputs and merge in
     `default_runfiles` from attributes which provide runfiles (often
-    [`data`](/reference/be/common-definitions#common-attributes.data)).
+    [`data`](/versions/6.5.0/reference/be/common-definitions#common-attributes.data)).
 
 *   When retrieving `runfiles` from `DefaultInfo` (generally only for merging
     runfiles between the current rule and its dependencies), use
@@ -1240,14 +1239,14 @@ provider):
 
 *   The fields `files`, `runfiles`, `data_runfiles`, `default_runfiles`, and
     `executable` correspond to the same-named fields of
-    [`DefaultInfo`](/rules/lib/DefaultInfo). It is not allowed to specify any of
+    [`DefaultInfo`](/versions/6.5.0/rules/lib/providers/DefaultInfo). It is not allowed to specify any of
     these fields while also returning a `DefaultInfo` provider.
 
 *   The field `output_groups` takes a struct value and corresponds to an
-    [`OutputGroupInfo`](/rules/lib/OutputGroupInfo).
+    [`OutputGroupInfo`](/versions/6.5.0/rules/lib/providers/OutputGroupInfo).
 
-In [`provides`](/rules/lib/globals#rule.provides) declarations of rules, and in
-[`providers`](/rules/lib/attr#label_list.providers) declarations of dependency
+In [`provides`](/versions/6.5.0/rules/lib/globals#rule.provides) declarations of rules, and in
+[`providers`](/versions/6.5.0/rules/lib/toplevel/attr#label_list.providers) declarations of dependency
 attributes, legacy providers are passed in as strings and modern providers are
 passed in by their `*Info` symbol. Be sure to change from strings to symbols
 when migrating. For complex or large rule sets where it is difficult to update
diff --git a/versions/6.5.0/extending/toolchains.mdx b/versions/6.5.0/extending/toolchains.mdx
index fc033fe8..82fb1a9d 100644
--- a/versions/6.5.0/extending/toolchains.mdx
+++ b/versions/6.5.0/extending/toolchains.mdx
@@ -5,7 +5,7 @@ title: 'Toolchains'
 
 This page describes the toolchain framework, which is a way for rule authors to
 decouple their rule logic from platform-based selection of tools. It is
-recommended to read the [rules](/rules/rules) and [platforms](/docs/platforms)
+recommended to read the [rules](/versions/6.5.0/rules/rules) and [platforms](/versions/6.5.0/docs/platforms)
 pages before continuing. This page covers why toolchains are needed, how to
 define and use them, and how Bazel selects an appropriate toolchain based on
 platform constraints.
@@ -83,7 +83,7 @@ bar_binary(
 ```
 
 You can improve on this solution by using `select` to choose the `compiler`
-[based on the platform](/docs/configurable-attributes):
+[based on the platform](/versions/6.5.0/docs/configurable-attributes):
 
 ```python
 config_setting(
@@ -171,7 +171,7 @@ def _bar_binary_impl(ctx):
 ```
 
 `ctx.toolchains["//bar_tools:toolchain_type"]` returns the
-[`ToolchainInfo` provider](/rules/lib/platform_common#ToolchainInfo)
+[`ToolchainInfo` provider](/versions/6.5.0/rules/lib/toplevel/platform_common#ToolchainInfo)
 of whatever target Bazel resolved the toolchain dependency to. The fields of the
 `ToolchainInfo` object are set by the underlying tool's rule; in the next
 section, this rule is defined such that there is a `barcinfo` field that wraps
@@ -205,7 +205,7 @@ bar_binary = rule(
 When an optional toolchain type cannot be resolved, analysis continues, and the
 result of `ctx.toolchains[""//bar_tools:toolchain_type"]` is `None`.
 
-The [`config_common.toolchain_type`](/rules/lib/config_common#toolchain_type)
+The [`config_common.toolchain_type`](/versions/6.5.0/rules/lib/toplevel/config_common#toolchain_type)
 function defaults to mandatory.
 
 The following forms can be used:
@@ -266,7 +266,7 @@ To define some toolchains for a given toolchain type, you need three things:
    suite for different platforms.
 
 3. For each such target, an associated target of the generic
-  [`toolchain`](/reference/be/platform#toolchain)
+  [`toolchain`](/versions/6.5.0/reference/be/platform#toolchain)
    rule, to provide metadata used by the toolchain framework. This `toolchain`
    target also refers to the `toolchain_type` associated with this toolchain.
    This means that a given `_toolchain` rule could be associated with any
@@ -376,7 +376,7 @@ for a real-world example.
 ### Toolchains and configurations
 
 An important question for rule authors is, when a `bar_toolchain` target is
-analyzed, what [configuration](/reference/glossary#configuration) does it see, and what transitions
+analyzed, what [configuration](/versions/6.5.0/reference/glossary#configuration) does it see, and what transitions
 should be used for dependencies? The example above uses string attributes, but
 what would happen for a more complicated toolchain that depends on other targets
 in the Bazel repository?
@@ -405,7 +405,7 @@ bar_toolchain = rule(
 )
 ```
 
-The use of [`attr.label`](/rules/lib/attr#label) is the same as for a standard rule,
+The use of [`attr.label`](/versions/6.5.0/rules/lib/toplevel/attr#label) is the same as for a standard rule,
 but the meaning of the `cfg` parameter is slightly different.
 
 The dependency from a target (called the "parent") to a toolchain via toolchain
@@ -472,7 +472,7 @@ This will end up building `//bar_tools:barc_linux` but not
 
 ## Toolchain resolution {#toolchain-resolution}
 
-Note: [Some Bazel rules](/concepts/platforms-intro#status) do not yet support
+Note: [Some Bazel rules](/versions/6.5.0/concepts/platforms-intro#status) do not yet support
 toolchain resolution.
 
 For each target that uses toolchains, Bazel's toolchain resolution procedure
@@ -484,14 +484,14 @@ platform for the current target.
 
 The available execution platforms and toolchains are gathered from the
 `WORKSPACE` file via
-[`register_execution_platforms`](/rules/lib/globals#register_execution_platforms)
+[`register_execution_platforms`](/versions/6.5.0/rules/lib/globals#register_execution_platforms)
 and
-[`register_toolchains`](/rules/lib/globals#register_toolchains).
+[`register_toolchains`](/versions/6.5.0/rules/lib/globals#register_toolchains).
 Additional execution platforms and toolchains may also be specified on the
 command line via
-[`--extra_execution_platforms`](/reference/command-line-reference#flag--extra_execution_platforms)
+[`--extra_execution_platforms`](/versions/6.5.0/reference/command-line-reference#flag--extra_execution_platforms)
 and
-[`--extra_toolchains`](/reference/command-line-reference#flag--extra_toolchains).
+[`--extra_toolchains`](/versions/6.5.0/reference/command-line-reference#flag--extra_toolchains).
 The host platform is automatically included as an available execution platform.
 Available platforms and toolchains are tracked as ordered lists for determinism,
 with preference given to earlier items in the list.
@@ -506,9 +506,9 @@ The resolution steps are as follows.
    referenced by the clause, these do not affect matching.
 
 1. If the target being built specifies the
-   [`exec_compatible_with` attribute](/reference/be/common-definitions#common.exec_compatible_with)
+   [`exec_compatible_with` attribute](/versions/6.5.0/reference/be/common-definitions#common.exec_compatible_with)
    (or its rule definition specifies the
-   [`exec_compatible_with` argument](/rules/lib/globals#rule.exec_compatible_with)),
+   [`exec_compatible_with` argument](/versions/6.5.0/rules/lib/globals#rule.exec_compatible_with)),
    the list of available execution platforms is filtered to remove
    any that do not match the execution constraints.
 
@@ -528,7 +528,7 @@ In cases where the same target can be built in multiple configurations (such as
 for different CPUs) within the same build, the resolution procedure is applied
 independently to each version of the target.
 
-If the rule uses [execution groups](/reference/exec-groups), each execution
+If the rule uses [execution groups](/versions/6.5.0/reference/exec-groups), each execution
 group performs toolchain resolution separately, and each has its own execution
 platform and toolchains.
 
@@ -540,8 +540,8 @@ provides verbose output for toolchain types or target names that match the regex
 can use `.*` to output all information. Bazel will output names of toolchains it
 checks and skips during the resolution process.
 
-If you'd like to see which [`cquery`](/docs/cquery) dependencies are from toolchain
-resolution, use `cquery`'s [`--transitions`](/docs/cquery#transitions) flag:
+If you'd like to see which [`cquery`](/versions/6.5.0/docs/cquery) dependencies are from toolchain
+resolution, use `cquery`'s [`--transitions`](/versions/6.5.0/docs/cquery#transitions) flag:
 
 ```
 # Find all direct dependencies of //cc:my_cc_lib. This includes explicitly
diff --git a/versions/6.5.0/external/advanced.mdx b/versions/6.5.0/external/advanced.mdx
index 471c5540..5811cb23 100644
--- a/versions/6.5.0/external/advanced.mdx
+++ b/versions/6.5.0/external/advanced.mdx
@@ -6,10 +6,8 @@ title: 'Advanced topics on external dependencies'
 
 ## Shadowing dependencies in WORKSPACE
 
-Note: This section applies to the [WORKSPACE
-system](/external/overview#workspace-system) only. For
-[Bzlmod](/external/overview#bzlmod), use a [multiple-version
-override](/external/module#multiple-version_override).
+Note: This section applies to the [WORKSPACE system](/versions/6.5.0/external/overview#workspace-system) only. For
+[Bzlmod](/versions/6.5.0/external/overview#bzlmod), use a [multiple-version override](/versions/6.5.0/external/module#multiple-version_override).
 
 Whenever possible, have a single version policy in your project, which is
 required for dependencies that you compile against and end up in your final
@@ -94,7 +92,7 @@ in `myproject/WORKSPACE`.
 
 To override a declared repository with a local repository from the command line,
 use the
-[`--override_repository`](/reference/command-line-reference#flag--override_repository)
+[`--override_repository`](/versions/6.5.0/reference/command-line-reference#flag--override_repository)
 flag. Using this flag changes the contents of external repositories without
 changing your source code.
 
@@ -109,11 +107,11 @@ Use cases include:
     override the network-based repository rules to point to local directories
     instead.
 
-Note: With [Bzlmod](/external/overview#bzlmod), remember to use canonical repo
+Note: With [Bzlmod](/versions/6.5.0/external/overview#bzlmod), remember to use canonical repo
 names here. Alternatively, use the
-[`--override_module`](/reference/command-line-reference#flag--override_module)
+[`--override_module`](/versions/6.5.0/reference/command-line-reference#flag--override_module)
 flag to override a module to a local directory, similar to the
-[`local_path_override`](/rules/lib/globals#local_path_override) directive in
+[`local_path_override`](/versions/6.5.0/rules/lib/globals#local_path_override) directive in
 `MODULE.bazel`.
 
 ## Using proxies
@@ -130,29 +128,24 @@ preferring IPv4 if enabled. In some situations, for example when the IPv4
 network cannot resolve/reach external addresses, this can cause `Network
 unreachable` exceptions and build failures. In these cases, you can override
 Bazel's behavior to prefer IPv6 by using the
-[`java.net.preferIPv6Addresses=true` system
-property](https://docs.oracle.com/javase/8/docs/api/java/net/doc-files/net-properties.html).
+[`java.net.preferIPv6Addresses=true` system property](https://docs.oracle.com/javase/8/docs/api/java/net/doc-files/net-properties.html).
 Specifically:
 
-*   Use `--host_jvm_args=-Djava.net.preferIPv6Addresses=true` [startup
-    option](/docs/user-manual#startup-options), for example by adding the
-    following line in your [`.bazelrc` file](/run/bazelrc):
+*   Use `--host_jvm_args=-Djava.net.preferIPv6Addresses=true` [startup option](/versions/6.5.0/docs/user-manual#startup-options), for example by adding the
+    following line in your [`.bazelrc` file](/versions/6.5.0/run/bazelrc):
 
     `startup --host_jvm_args=-Djava.net.preferIPv6Addresses=true`
 
 *   When running Java build targets that need to connect to the internet (such
     as for integration tests), use the
-    `--jvmopt=-Djava.net.preferIPv6Addresses=true` [tool
-    flag](/docs/user-manual#jvmopt). For example, include in your [`.bazelrc`
-    file](/run/bazelrc):
+    `--jvmopt=-Djava.net.preferIPv6Addresses=true` [tool flag](/versions/6.5.0/docs/user-manual#jvmopt). For example, include in your [`.bazelrc` file](/versions/6.5.0/run/bazelrc):
 
     `build --jvmopt=-Djava.net.preferIPv6Addresses`
 
 *   If you are using [`rules_jvm_external`](https://github.com/bazelbuild/rules_jvm_external)
     for dependency version resolution, also add
     `-Djava.net.preferIPv6Addresses=true` to the `COURSIER_OPTS` environment
-    variable to [provide JVM options for
-    Coursier](https://github.com/bazelbuild/rules_jvm_external#provide-jvm-options-for-coursier-with-coursier_opts).
+    variable to [provide JVM options for Coursier](https://github.com/bazelbuild/rules_jvm_external#provide-jvm-options-for-coursier-with-coursier_opts).
 
 ## Offline builds
 
@@ -164,20 +157,17 @@ the build, use the option `--nofetch`.
 For true offline builds, where a different entity supplies all needed files,
 Bazel supports the option `--distdir`. This flag tells Bazel to look first into
 the directories specified by that option when a repository rule asks Bazel to
-fetch a file with [`ctx.download`](/rules/lib/repository_ctx#download) or
-[`ctx.download_and_extract`](/rules/lib/repository_ctx#download_and_extract). By
+fetch a file with [`ctx.download`](/versions/6.5.0/rules/lib/builtins/repository_ctx#download) or
+[`ctx.download_and_extract`](/versions/6.5.0/rules/lib/builtins/repository_ctx#download_and_extract). By
 providing a hash sum of the file needed, Bazel looks for a file matching the
 basename of the first URL, and uses the local copy if the hash matches.
 
-Bazel itself uses this technique to bootstrap offline from the [distribution
-artifact](https://github.com/bazelbuild/bazel-website/blob/master/designs/_posts/2016-10-11-distribution-artifact.md).
-It does so by [collecting all the needed external
-dependencies](https://github.com/bazelbuild/bazel/blob/5cfa0303d6ac3b5bd031ff60272ce80a704af8c2/WORKSPACE#L116)
+Bazel itself uses this technique to bootstrap offline from the [distribution artifact](https://github.com/bazelbuild/bazel-website/blob/master/designs/_posts/2016-10-11-distribution-artifact.md).
+It does so by [collecting all the needed external dependencies](https://github.com/bazelbuild/bazel/blob/5cfa0303d6ac3b5bd031ff60272ce80a704af8c2/WORKSPACE#L116)
 in an internal
 [`distdir_tar`](https://github.com/bazelbuild/bazel/blob/5cfa0303d6ac3b5bd031ff60272ce80a704af8c2/distdir.bzl#L44).
 
 Bazel allows execution of arbitrary commands in repository rules without knowing
 if they call out to the network, and so cannot enforce fully offline builds. To
 test if a build works correctly offline, manually block off the network (as
-Bazel does in its [bootstrap
-test](https://cs.opensource.google/bazel/bazel/+/master:src/test/shell/bazel/BUILD;l=1073;drc=88c426e73cc0eb0a41c0d7995e36acd94e7c9a48)).
+Bazel does in its [bootstrap test](https://cs.opensource.google/bazel/bazel/+/master:src/test/shell/bazel/BUILD;l=1073;drc=88c426e73cc0eb0a41c0d7995e36acd94e7c9a48)).
diff --git a/versions/6.5.0/external/images/mod_exampleBefore.svg b/versions/6.5.0/external/images/mod_exampleBefore.svg
new file mode 100644
index 00000000..66f01303
--- /dev/null
+++ b/versions/6.5.0/external/images/mod_exampleBefore.svg
@@ -0,0 +1,175 @@
+
+
+
+
+
+
+mygraph
+
+
+
+<root>
+
+<root> (my_project@1.0)
+
+
+
+bazel_skylib@1.1.1
+
+bazel_skylib@1.1.1
+
+
+
+<root>->bazel_skylib@1.1.1
+
+
+
+
+
+bazel_skylib@1.2.0
+
+bazel_skylib@1.2.0
+
+
+
+<root>->bazel_skylib@1.2.0
+
+
+
+
+
+rules_java@5.0.0
+
+rules_java@5.0.0
+
+
+
+<root>->rules_java@5.0.0
+
+
+
+
+
+stardoc@0.5.0
+
+stardoc@0.5.0
+
+
+
+<root>->stardoc@0.5.0
+
+
+
+
+
+platforms@0.0.4
+
+platforms@0.0.4
+
+
+
+bazel_skylib@1.1.1->platforms@0.0.4
+
+
+
+
+
+bazel_skylib@1.2.0->platforms@0.0.4
+
+
+
+
+
+rules_java@5.0.0->platforms@0.0.4
+
+
+
+
+
+rules_cc@0.0.1
+
+rules_cc@0.0.1
+
+
+
+rules_java@5.0.0->rules_cc@0.0.1
+
+
+
+
+
+rules_proto@4.0.0
+
+rules_proto@4.0.0
+
+
+
+rules_java@5.0.0->rules_proto@4.0.0
+
+
+
+
+
+bazel_skylib@1.0.3
+
+bazel_skylib@1.0.3
+
+
+
+stardoc@0.5.0->bazel_skylib@1.0.3
+
+
+
+
+
+rules_java@4.0.0
+
+rules_java@4.0.0
+
+
+
+stardoc@0.5.0->rules_java@4.0.0
+
+
+
+
+
+rules_cc@0.0.1->platforms@0.0.4
+
+
+
+
+
+rules_cc@0.0.1->bazel_skylib@1.0.3
+
+
+
+
+
+rules_proto@4.0.0->rules_cc@0.0.1
+
+
+
+
+
+rules_proto@4.0.0->bazel_skylib@1.0.3
+
+
+
+
+
+bazel_skylib@1.0.3->platforms@0.0.4
+
+
+
+
+
+rules_java@4.0.0->bazel_skylib@1.0.3
+
+
+
+
+
\ No newline at end of file
diff --git a/versions/6.5.0/external/images/mod_exampleResolved.svg b/versions/6.5.0/external/images/mod_exampleResolved.svg
new file mode 100644
index 00000000..224b694c
--- /dev/null
+++ b/versions/6.5.0/external/images/mod_exampleResolved.svg
@@ -0,0 +1,151 @@
+
+
+
+
+
+
+mygraph
+
+
+
+<root>
+
+<root> (my_project@1.0)
+
+
+
+bazel_skylib@1.1.1
+
+bazel_skylib@1.1.1
+
+
+
+<root>->bazel_skylib@1.1.1
+
+
+
+
+
+bazel_skylib@1.2.0
+
+bazel_skylib@1.2.0
+
+
+
+<root>->bazel_skylib@1.2.0
+
+
+
+
+
+rules_java@5.0.0
+
+rules_java@5.0.0
+
+
+
+<root>->rules_java@5.0.0
+
+
+
+
+
+stardoc@0.5.0
+
+stardoc@0.5.0
+
+
+
+<root>->stardoc@0.5.0
+
+
+
+
+
+platforms@0.0.4
+
+platforms@0.0.4
+
+
+
+bazel_skylib@1.1.1->platforms@0.0.4
+
+
+
+
+
+bazel_skylib@1.2.0->platforms@0.0.4
+
+
+
+
+
+rules_java@5.0.0->platforms@0.0.4
+
+
+
+
+
+rules_cc@0.0.1
+
+rules_cc@0.0.1
+
+
+
+rules_java@5.0.0->rules_cc@0.0.1
+
+
+
+
+
+rules_proto@4.0.0
+
+rules_proto@4.0.0
+
+
+
+rules_java@5.0.0->rules_proto@4.0.0
+
+
+
+
+
+stardoc@0.5.0->bazel_skylib@1.1.1
+
+
+
+
+
+stardoc@0.5.0->rules_java@5.0.0
+
+
+
+
+
+rules_cc@0.0.1->bazel_skylib@1.1.1
+
+
+
+
+
+rules_cc@0.0.1->platforms@0.0.4
+
+
+
+
+
+rules_proto@4.0.0->bazel_skylib@1.1.1
+
+
+
+
+
+rules_proto@4.0.0->rules_cc@0.0.1
+
+
+
+
+
\ No newline at end of file
diff --git a/versions/6.5.0/external/lockfile.mdx b/versions/6.5.0/external/lockfile.mdx
index 13ab00b0..c01444e2 100644
--- a/versions/6.5.0/external/lockfile.mdx
+++ b/versions/6.5.0/external/lockfile.mdx
@@ -32,7 +32,7 @@ dependencies.
 ## Lockfile Usage {#lockfile-usage}
 
 The lockfile can be controlled by the flag
-[`--lockfile_mode`](/reference/command-line-reference#flag--lockfile_mode) to
+[`--lockfile_mode`](/versions/6.5.0/reference/command-line-reference#flag--lockfile_mode) to
 customize the behavior of Bazel when the project state differs from the
 lockfile. The available modes are:
 
diff --git a/versions/6.5.0/external/migration.mdx b/versions/6.5.0/external/migration.mdx
index f1e1ca3c..47376b17 100644
--- a/versions/6.5.0/external/migration.mdx
+++ b/versions/6.5.0/external/migration.mdx
@@ -3,8 +3,7 @@
 title: 'Bzlmod Migration Guide'
 ---
 
-Due to the [shortcomings of
-WORKSPACE](/external/overview#workspace-shortcomings), Bzlmod is going to
+Due to the [shortcomings of WORKSPACE](/versions/6.5.0/external/overview#workspace-shortcomings), Bzlmod is going to
 replace the legacy WORKSPACE system in future Bazel releases. This guide helps
 you migrate your project to Bzlmod and drop WORKSPACE for fetching external
 dependencies.
@@ -104,9 +103,7 @@ Bazel module when it also adopts Bzlmod.
 
 *   **Bzlmod**
 
-    With Bzlmod, as long as the your dependency is available in [Bazel Central
-    Registry](https://registry.bazel.build) or your custom [Bazel
-    registry](/external/registry), you can simply depend on it with a
+    With Bzlmod, as long as the your dependency is available in [Bazel Central Registry](https://registry.bazel.build) or your custom [Bazel registry](/versions/6.5.0/external/registry), you can simply depend on it with a
     [`bazel_dep`](/versions/6.5.0/rules/lib/globals/module#bazel_dep) directive.
 
     ```python
@@ -541,8 +538,7 @@ macros.
 Fortunately, the flag
 [`--experimental_repository_resolved_file`][resolved_file_flag]
 can help. This flag essentially generates a "lock file" of all fetched external
-dependencies in your last Bazel command. You can find more details in this [blog
-post](https://blog.bazel.build/2018/07/09/bazel-sync-and-resolved-file.html).
+dependencies in your last Bazel command. You can find more details in this [blog post](https://blog.bazel.build/2018/07/09/bazel-sync-and-resolved-file.html).
 
 [resolved_file_flag]: /reference/command-line-reference#flag--experimental_repository_resolved_file
 
@@ -583,11 +579,9 @@ You may also know `bazel query` can be used for inspecting repository rules with
 bazel query --output=build //external:
 ```
 
-While it is more convenient and much faster, [bazel query can lie about
-external dependency version](https://github.com/bazelbuild/bazel/issues/12947),
+While it is more convenient and much faster, [bazel query can lie about external dependency version](https://github.com/bazelbuild/bazel/issues/12947),
 so be careful using it! Querying and inspecting external
-dependencies with Bzlmod is going to achieved by a [new
-subcommand](https://github.com/bazelbuild/bazel/issues/15365).
+dependencies with Bzlmod is going to achieved by a [new subcommand](https://github.com/bazelbuild/bazel/issues/15365).
 
 #### Built-in default dependencies {#builtin-default-deps}
 
@@ -634,8 +628,7 @@ your workspace root.
 #### Repository visibility {#repository-visibility}
 
 Bzlmod is able to control which other repositories are visible from a given
-repository, check [repository names and strict
-deps](/external/module#repository_names_and_strict_deps) for more details.
+repository, check [repository names and strict deps](/versions/6.5.0/external/module#repository_names_and_strict_deps) for more details.
 
 Here is a summary of repository visibilities from different types of
 repositories when also taking WORKSPACE into consideration.
@@ -648,8 +641,7 @@ repositories when also taking WORKSPACE into consideration.
 | WORKSPACE Repos | All visible | Not visible | Not visible | All visible |
 
 Note: For the root module, if a repository `@foo` is defined in WORKSPACE and
-`@foo` is also used as an [apparent repository
-name](/external/overview#apparent-repo-name) in MODULE.bazel, then `@foo`
+`@foo` is also used as an [apparent repository name](/versions/6.5.0/external/overview#apparent-repo-name) in MODULE.bazel, then `@foo`
 refers to the one introduced in MODULE.bazel.
 
 Note: For a module extension generated repository `@bar`, if `@foo` is used as
@@ -724,9 +716,7 @@ the project. Take note of a few things when creating the source archive:
     GitHub isn't going to guarantee the checksum of source archives generated on
     demand. In short, URLs in the form of
     `https://github.com///releases/download/...` is considered stable
-    while `https://github.com///archive/...` is not. Check [GitHub
-    Archive Checksum
-    Outage](https://blog.bazel.build/2023/02/15/github-archive-checksum.html)
+    while `https://github.com///archive/...` is not. Check [GitHub Archive Checksum Outage](https://blog.bazel.build/2023/02/15/github-archive-checksum.html)
     for more context.
 
 *   **Make sure the source tree follows the layout of the original repository.**
@@ -755,8 +745,7 @@ Pull Request.
 
 [bcr_contrib_guide]: https://github.com/bazelbuild/bazel-central-registry/tree/main/docs#contribute-a-bazel-module
 
-It is **highly recommended** to set up the [Publish to
-BCR](https://github.com/bazel-contrib/publish-to-bcr) GitHub App for your
+It is **highly recommended** to set up the [Publish to BCR](https://github.com/bazel-contrib/publish-to-bcr) GitHub App for your
 repository to automate the process of submitting your module to the BCR.
 
 ## Best practices {#best-practices}
diff --git a/versions/6.5.0/external/mod-command.mdx b/versions/6.5.0/external/mod-command.mdx
index f0950653..9ee5b94f 100644
--- a/versions/6.5.0/external/mod-command.mdx
+++ b/versions/6.5.0/external/mod-command.mdx
@@ -62,11 +62,9 @@ The available subcommands and their respective required arguments are:
 
 *   ``: All present versions of the module ``.
 
-*   `@`: The repo with the given [apparent
-    name](overview#apparent-repo-name) in the context of the `--base_module`.
+*   `@`: The repo with the given [apparent name](/versions/6.5.0/external/overview#apparent-repo-name) in the context of the `--base_module`.
 
-*   `@@`: The repo with the given [canonical
-    name](overview#canonical-repo-name).
+*   `@@`: The repo with the given [canonical name](/versions/6.5.0/external/overview#canonical-repo-name).
 
 In a context requiring specifying modules, ``s referring to repos that
 correspond to modules (as opposed to extension-generated repos) can also be
@@ -88,8 +86,7 @@ The following options only affect the subcommands that print graphs (`graph`,
     information about the version resolution of each module. If the module
     version changed during resolution, show either which version replaced it or
     what was the original version, the reason it was replaced, and which modules
-    requested the new version if the reason was [Minimal Version
-    Selection](module#version-selection).
+    requested the new version if the reason was [Minimal Version Selection](/versions/6.5.0/external/module#version-selection).
 
 *   `--include_unused` *default: "false"*: Include in the output graph the
     modules which were originally present in the dependency graph, but became
@@ -193,7 +190,7 @@ use_repo(toolchains, my_jdk="remotejdk17_linux")
   
     
       

-        Graph Before Resolution
+        Graph Before Resolution
         
Graph Before Resolution

       

 {/* digraph mygraph {
@@ -223,7 +220,7 @@ use_repo(toolchains, my_jdk="remotejdk17_linux")
     
     
       

-        Graph After Resolution
+        Graph After Resolution
        
Graph After Resolution

       

 {/* digraph mygraph {
diff --git a/versions/6.5.0/external/module.mdx b/versions/6.5.0/external/module.mdx
index e9d9492f..cf02b7e8 100644
--- a/versions/6.5.0/external/module.mdx
+++ b/versions/6.5.0/external/module.mdx
@@ -25,7 +25,7 @@ bazel_dep(name = "protobuf", version = "3.19.0")
 
 To perform module resolution, Bazel starts by reading the root module's
 `MODULE.bazel` file, and then repeatedly requests any dependency's
-`MODULE.bazel` file from a [Bazel registry](/external/registry) until it
+`MODULE.bazel` file from a [Bazel registry](/versions/6.5.0/external/registry) until it
 discovers the entire dependency graph.
 
 By default, Bazel then [selects](#version-selection) one version of each module
@@ -85,7 +85,7 @@ The registry can declare certain versions as *yanked* if they should be avoided
 (such as for security vulnerabilities). Bazel throws an error when selecting a
 yanked version of a module. To fix this error, either upgrade to a newer,
 non-yanked version, or use the
-[`--allow_yanked_versions`](/reference/command-line-reference#flag--allow_yanked_versions)
+[`--allow_yanked_versions`](/versions/6.5.0/reference/command-line-reference#flag--allow_yanked_versions)
 flag to explicitly allow the yanked version.
 
 ## Compatibility level
@@ -117,15 +117,14 @@ directly depend on.
 
 ### Single-version override
 
-The [`single_version_override`](/rules/lib/globals#single_version_override)
+The [`single_version_override`](/versions/6.5.0/rules/lib/globals#single_version_override)
 serves multiple purposes:
 
 *   With the `version` attribute, you can pin a dependency to a specific
     version, regardless of which versions of the dependency are requested in the
     dependency graph.
 *   With the `registry` attribute, you can force this dependency to come from a
-    specific registry, instead of following the normal [registry
-    selection](/external/registry#selecting_registries) process.
+    specific registry, instead of following the normal [registry selection](/versions/6.5.0/external/registry#selecting_registries) process.
 *   With the `patch*` attributes, you can specify a set of patches to apply to
     the downloaded module.
 
@@ -133,7 +132,7 @@ These attributes are all optional and can be mixed and matched with each other.
 
 ### Multiple-version override
 
-A [`multiple_version_override`](/rules/lib/globals#multiple_version_override)
+A [`multiple_version_override`](/versions/6.5.0/rules/lib/globals#multiple_version_override)
 can be specified to allow multiple versions of the same module to coexist in the
 resolved dependency graph.
 
@@ -168,24 +167,24 @@ the repo itself.
 
 Bazel supports the following non-registry overrides:
 
-*   [`archive_override`](/rules/lib/globals#archive_override)
-*   [`git_override`](/rules/lib/globals#git_override)
-*   [`local_path_override`](/rules/lib/globals#local_path_override)
+*   [`archive_override`](/versions/6.5.0/rules/lib/globals#archive_override)
+*   [`git_override`](/versions/6.5.0/rules/lib/globals#git_override)
+*   [`local_path_override`](/versions/6.5.0/rules/lib/globals#local_path_override)
 
 ## Repository names and strict deps
 
-The [canonical name](/external/overview#canonical-repo-name) of a repo backing a
+The [canonical name](/versions/6.5.0/external/overview#canonical-repo-name) of a repo backing a
 module is `module_name~version` (for example, `bazel_skylib~1.0.3`). For modules with a
 non-registry override, replace the `version` part
 with the string `override`. Note that the canonical name format is not an API
 you should depend on and is subject to change at any time.
 
-The [apparent name](/external/overview#apparent-repo-name) of a repo backing a
+The [apparent name](/versions/6.5.0/external/overview#apparent-repo-name) of a repo backing a
 module to its direct dependents defaults to its module name, unless the
-`repo_name` attribute of the [`bazel_dep`](/rules/lib/globals#bazel_dep)
+`repo_name` attribute of the [`bazel_dep`](/versions/6.5.0/rules/lib/globals#bazel_dep)
 directive says otherwise. Note that this means a module can only find its direct
 dependencies. This helps prevent accidental breakages due to changes in
 transitive dependencies.
 
-[Module extensions](/external/extension) can also introduce additional repos
+[Module extensions](/versions/6.5.0/external/extension) can also introduce additional repos
 into the visible scope of a module.
diff --git a/versions/6.5.0/external/overview.mdx b/versions/6.5.0/external/overview.mdx
index 22fb154d..ebc60292 100644
--- a/versions/6.5.0/external/overview.mdx
+++ b/versions/6.5.0/external/overview.mdx
@@ -118,8 +118,7 @@ bazel_dep(name = "protobuf", version = "3.19.0")
 ```
 
 A module must only list its direct dependencies, which Bzlmod looks up in a
-[Bazel registry](/versions/6.5.0/external/registry) — by default, the [Bazel Central
-Registry](https://bcr.bazel.build/). The registry provides the
+[Bazel registry](/versions/6.5.0/external/registry) — by default, the [Bazel Central Registry](https://bcr.bazel.build/). The registry provides the
 dependencies' `MODULE.bazel` files, which allows Bazel to discover the entire
 transitive dependency graph before performing version resolution.
 
@@ -189,5 +188,4 @@ many pain points, including:
         `B` and `C`; `B` and `C` both depend on different versions of `D`).
 
 Due to the shortcomings of WORKSPACE, Bzlmod is going to replace the legacy
-WORKSPACE system in future Bazel releases. Please read the [Bzlmod migration
-guide](/external/migration) on how to migrate to Bzlmod.
\ No newline at end of file
+WORKSPACE system in future Bazel releases. Please read the [Bzlmod migration guide](/versions/6.5.0/external/migration) on how to migrate to Bzlmod.
\ No newline at end of file
diff --git a/versions/6.5.0/external/registry.mdx b/versions/6.5.0/external/registry.mdx
index 9ae4e805..80672b6a 100644
--- a/versions/6.5.0/external/registry.mdx
+++ b/versions/6.5.0/external/registry.mdx
@@ -34,8 +34,7 @@ An index registry must follow the format below:
             project
         *   `versions`: A list of all the versions of this module to be found in
             this registry
-        *   `yanked_versions`: A map of [*yanked*
-            versions](/external/module#yanked_versions) of this module. The keys
+        *   `yanked_versions`: A map of [*yanked* versions](/versions/6.5.0/external/module#yanked_versions) of this module. The keys
             should be versions to yank and the values should be descriptions of
             why the version is yanked, ideally containing a link to more
             information
@@ -46,8 +45,7 @@ An index registry must follow the format below:
         *   The default type is "archive", representing an `http_archive` repo,
             with the following fields:
             *   `url`: The URL of the source archive
-            *   `integrity`: The [Subresource
-                Integrity](https://w3c.github.io/webappsec-subresource-integrity/#integrity-metadata-description)
+            *   `integrity`: The [Subresource Integrity](https://w3c.github.io/webappsec-subresource-integrity/#integrity-metadata-description)
                 checksum of the archive
             *   `strip_prefix`: A directory prefix to strip when extracting the
                 source archive
@@ -85,8 +83,7 @@ You can browse its contents using the web frontend at
 https://registry.bazel.build/.
 
 The Bazel community maintains the BCR, and contributors are welcome to submit
-pull requests. See the [BCR contribution
-guidelines](https://github.com/bazelbuild/bazel-central-registry/blob/main/docs/README.md).
+pull requests. See the [BCR contribution guidelines](https://github.com/bazelbuild/bazel-central-registry/blob/main/docs/README.md).
 
 In addition to following the format of a normal index registry, the BCR requires
 a `presubmit.yml` file for each module version
diff --git a/versions/6.5.0/help.mdx b/versions/6.5.0/help.mdx
index 4553b01c..8ea7606f 100644
--- a/versions/6.5.0/help.mdx
+++ b/versions/6.5.0/help.mdx
@@ -37,9 +37,8 @@ If there are no existing answers, you can ask the community by:
 * Emailing the [Bazel developer group](https://groups.google.com/g/bazel-dev)
 * Asking a question on [Stack Overflow](https://stackoverflow.com/questions/tagged/bazel)
 * Chatting with other Bazel contributors on [Slack](https://slack.bazel.build/)
-* Consulting a [Bazel community expert](/community/experts)
+* Consulting a [Bazel community expert](/versions/6.5.0/community/experts)
 
 ## File a bug {#file-bug}
 
-If you encounter a bug or want to request a feature, file a [GitHub
-Issue](https://github.com/bazelbuild/bazel/issues).
+If you encounter a bug or want to request a feature, file a [GitHub Issue](https://github.com/bazelbuild/bazel/issues).
diff --git a/versions/6.5.0/images/about.svg b/versions/6.5.0/images/about.svg
new file mode 100644
index 00000000..f927298f
--- /dev/null
+++ b/versions/6.5.0/images/about.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/6.5.0/images/basics.svg b/versions/6.5.0/images/basics.svg
new file mode 100644
index 00000000..013ec519
--- /dev/null
+++ b/versions/6.5.0/images/basics.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/6.5.0/images/bazel_hero.svg b/versions/6.5.0/images/bazel_hero.svg
new file mode 100644
index 00000000..c48714d0
--- /dev/null
+++ b/versions/6.5.0/images/bazel_hero.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/6.5.0/images/community.svg b/versions/6.5.0/images/community.svg
new file mode 100644
index 00000000..29f87a76
--- /dev/null
+++ b/versions/6.5.0/images/community.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/6.5.0/images/distributed-build-remote-cache.png b/versions/6.5.0/images/distributed-build-remote-cache.png
new file mode 100644
index 00000000..99d8a915
Binary files /dev/null and b/versions/6.5.0/images/distributed-build-remote-cache.png differ
diff --git a/versions/6.5.0/images/essential_guide.svg b/versions/6.5.0/images/essential_guide.svg
new file mode 100644
index 00000000..4ee63ae9
--- /dev/null
+++ b/versions/6.5.0/images/essential_guide.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/6.5.0/images/essential_reference.svg b/versions/6.5.0/images/essential_reference.svg
new file mode 100644
index 00000000..4d29a8d5
--- /dev/null
+++ b/versions/6.5.0/images/essential_reference.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/6.5.0/images/essential_start.svg b/versions/6.5.0/images/essential_start.svg
new file mode 100644
index 00000000..c8f48f84
--- /dev/null
+++ b/versions/6.5.0/images/essential_start.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/6.5.0/images/extend.svg b/versions/6.5.0/images/extend.svg
new file mode 100644
index 00000000..77b2dd97
--- /dev/null
+++ b/versions/6.5.0/images/extend.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/6.5.0/images/guide.svg b/versions/6.5.0/images/guide.svg
new file mode 100644
index 00000000..23a5d35a
--- /dev/null
+++ b/versions/6.5.0/images/guide.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/6.5.0/images/high-level-build-system.png b/versions/6.5.0/images/high-level-build-system.png
new file mode 100644
index 00000000..462717fa
Binary files /dev/null and b/versions/6.5.0/images/high-level-build-system.png differ
diff --git a/versions/6.5.0/images/new_1.svg b/versions/6.5.0/images/new_1.svg
new file mode 100644
index 00000000..c4cd9dfd
--- /dev/null
+++ b/versions/6.5.0/images/new_1.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/6.5.0/images/new_2.svg b/versions/6.5.0/images/new_2.svg
new file mode 100644
index 00000000..c6b7021b
--- /dev/null
+++ b/versions/6.5.0/images/new_2.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/6.5.0/images/new_3.svg b/versions/6.5.0/images/new_3.svg
new file mode 100644
index 00000000..c2afb4ac
--- /dev/null
+++ b/versions/6.5.0/images/new_3.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/6.5.0/images/placeholder.png b/versions/6.5.0/images/placeholder.png
new file mode 100644
index 00000000..54f1fa0e
Binary files /dev/null and b/versions/6.5.0/images/placeholder.png differ
diff --git a/versions/6.5.0/images/reference.svg b/versions/6.5.0/images/reference.svg
new file mode 100644
index 00000000..7bbc9bea
--- /dev/null
+++ b/versions/6.5.0/images/reference.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/6.5.0/images/release_notes.svg b/versions/6.5.0/images/release_notes.svg
new file mode 100644
index 00000000..8a2e8b56
--- /dev/null
+++ b/versions/6.5.0/images/release_notes.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/6.5.0/images/remote-execution-system.png b/versions/6.5.0/images/remote-execution-system.png
new file mode 100644
index 00000000..8152fc0c
Binary files /dev/null and b/versions/6.5.0/images/remote-execution-system.png differ
diff --git a/versions/6.5.0/images/start.svg b/versions/6.5.0/images/start.svg
new file mode 100644
index 00000000..3bcebd7b
--- /dev/null
+++ b/versions/6.5.0/images/start.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/6.5.0/images/task-dependencies.png b/versions/6.5.0/images/task-dependencies.png
new file mode 100644
index 00000000..ae1f9c51
Binary files /dev/null and b/versions/6.5.0/images/task-dependencies.png differ
diff --git a/versions/6.5.0/images/test.png b/versions/6.5.0/images/test.png
new file mode 100644
index 00000000..243939da
Binary files /dev/null and b/versions/6.5.0/images/test.png differ
diff --git a/versions/6.5.0/images/transitive-dependencies.png b/versions/6.5.0/images/transitive-dependencies.png
new file mode 100644
index 00000000..ec641a08
Binary files /dev/null and b/versions/6.5.0/images/transitive-dependencies.png differ
diff --git a/versions/6.5.0/images/trunk-logo-dark.svg b/versions/6.5.0/images/trunk-logo-dark.svg
new file mode 100644
index 00000000..f25940af
--- /dev/null
+++ b/versions/6.5.0/images/trunk-logo-dark.svg
@@ -0,0 +1,22 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/versions/6.5.0/images/why_faq.svg b/versions/6.5.0/images/why_faq.svg
new file mode 100644
index 00000000..afec3f8f
--- /dev/null
+++ b/versions/6.5.0/images/why_faq.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/6.5.0/images/why_overview.svg b/versions/6.5.0/images/why_overview.svg
new file mode 100644
index 00000000..c10c363c
--- /dev/null
+++ b/versions/6.5.0/images/why_overview.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/6.5.0/images/why_vision.svg b/versions/6.5.0/images/why_vision.svg
new file mode 100644
index 00000000..739e415f
--- /dev/null
+++ b/versions/6.5.0/images/why_vision.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/6.5.0/install/bazelisk.mdx b/versions/6.5.0/install/bazelisk.mdx
index a10d4712..87215ce3 100644
--- a/versions/6.5.0/install/bazelisk.mdx
+++ b/versions/6.5.0/install/bazelisk.mdx
@@ -16,9 +16,8 @@ For more details, see
 
 ## Updating Bazel
 
-Bazel has a [backward compatibility policy](/release/backward-compatibility)
-(see [guidance for rolling out incompatible
-changes](/contribute/breaking-changes) if you
+Bazel has a [backward compatibility policy](/versions/6.5.0/release/backward-compatibility)
+(see [guidance for rolling out incompatible changes](/versions/6.5.0/contribute/breaking-changes) if you
 are the author of one). That page summarizes best practices on how to test and
 migrate your project with upcoming incompatible changes and how to provide
 feedback to the incompatible change authors.
diff --git a/versions/6.5.0/install/compile-source.mdx b/versions/6.5.0/install/compile-source.mdx
index 029759f6..791098b8 100644
--- a/versions/6.5.0/install/compile-source.mdx
+++ b/versions/6.5.0/install/compile-source.mdx
@@ -47,8 +47,7 @@ it by typing `bazel` in a terminal.
 
 **Reason**: To build Bazel from a GitHub source tree, you need a pre-existing
 Bazel binary. You can install one from a package manager or download one from
-GitHub. See [Installing Bazel](/install). (Or you can [build from
-scratch (bootstrap)](#bootstrap-bazel).)
+GitHub. See [Installing Bazel](/versions/6.5.0/install). (Or you can [build from scratch (bootstrap)](#bootstrap-bazel).)
 
 **Troubleshooting**:
 
@@ -176,7 +175,7 @@ You can also build Bazel from scratch, without using an existing Bazel binary.
 2.  Unpack the distribution archive somewhere on disk.
 
     You should verify the signature made by Bazel's
-    [release key](https://bazel.build/bazel-release.pub.gpg) 3D5919B448457EE0.
+    [release key](https://bazel.build/versions/6.5.0/bazel-release.pub.gpg) 3D5919B448457EE0.
 
 ### Step 2a: Bootstrap Bazel on Ubuntu Linux, macOS, and other Unix-like systems {#bootstrap-unix-overview}
 
@@ -235,8 +234,7 @@ For instructions for Unix-like systems, see
     ```
 
 *   **The Visual C++ compiler.** Install the Visual C++ compiler either as part
-    of Visual Studio 2015 or newer, or by installing the latest [Build Tools
-    for Visual Studio 2017](https://aka.ms/BuildTools).
+    of Visual Studio 2015 or newer, or by installing the latest [Build Tools for Visual Studio 2017](https://aka.ms/BuildTools).
 
 *   **JDK.** Version 11 is required.
 
diff --git a/versions/6.5.0/install/completion.mdx b/versions/6.5.0/install/completion.mdx
index aec6f9c0..fa5e55c8 100644
--- a/versions/6.5.0/install/completion.mdx
+++ b/versions/6.5.0/install/completion.mdx
@@ -41,7 +41,7 @@ If you installed Bazel:
             source /path/to/bazel-complete.bash
             ```
 
-*   Via [bootstrapping](/install/compile-source), then:
+*   Via [bootstrapping](/versions/6.5.0/install/compile-source), then:
     1.  Build the completion script:
 
         ```
diff --git a/versions/6.5.0/install/ide.mdx b/versions/6.5.0/install/ide.mdx
index 8483c91b..99a3aa7f 100644
--- a/versions/6.5.0/install/ide.mdx
+++ b/versions/6.5.0/install/ide.mdx
@@ -39,10 +39,8 @@ To install, go to the IDE's plugin browser and search for `Bazel`.
 To manually install older versions, download the zip files from JetBrains'
 Plugin Repository and install the zip file from the IDE's plugin browser:
 
-*  [Android Studio
-   plugin](https://plugins.jetbrains.com/plugin/9185-android-studio-with-bazel)
-*  [IntelliJ
-   plugin](https://plugins.jetbrains.com/plugin/8609-intellij-with-bazel)
+*  [Android Studio plugin](https://plugins.jetbrains.com/plugin/9185-android-studio-with-bazel)
+*  [IntelliJ plugin](https://plugins.jetbrains.com/plugin/8609-intellij-with-bazel)
 *  [CLion plugin](https://plugins.jetbrains.com/plugin/9554-clion-with-bazel)
 
 ### Xcode {#xcode}
@@ -61,8 +59,7 @@ Features:
 * Starlark debugger for `.bzl` files during a build (set breakpoints, step
   through code, inspect variables, and so on)
 
-Find [the plugin on the Visual Studio
-marketplace](https://marketplace.visualstudio.com/items?itemName=BazelBuild.vscode-bazel).
+Find [the plugin on the Visual Studio marketplace](https://marketplace.visualstudio.com/items?itemName=BazelBuild.vscode-bazel).
 The plugin is [open source](https://github.com/bazelbuild/vscode-bazel).
 
 See also: [Autocomplete for Source Code](#autocomplete-for-source-code)
@@ -78,8 +75,7 @@ See [`bazelbuild/vim-bazel` on GitHub](https://github.com/bazelbuild/vim-bazel)
 
 ### Emacs {#emacs}
 
-See [`bazelbuild/bazel-emacs-mode` on
-GitHub](https://github.com/bazelbuild/emacs-bazel-mode)
+See [`bazelbuild/bazel-emacs-mode` on GitHub](https://github.com/bazelbuild/emacs-bazel-mode)
 
 ### Visual Studio {#visual-studio}
 
@@ -109,6 +105,5 @@ tool for building Bazel targets when source files change.
 
 ## Building your own IDE plugin {#build-own-plugin}
 
-Read the [**IDE support** blog
-post](https://blog.bazel.build/2016/06/10/ide-support.html) to learn more about
+Read the [**IDE support** blog post](https://blog.bazel.build/2016/06/10/ide-support.html) to learn more about
 the Bazel APIs to use when building an IDE plugin.
diff --git a/versions/6.5.0/install/images/bazelisk.svg b/versions/6.5.0/install/images/bazelisk.svg
new file mode 100644
index 00000000..c0ae9f54
--- /dev/null
+++ b/versions/6.5.0/install/images/bazelisk.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/6.5.0/install/images/cli.svg b/versions/6.5.0/install/images/cli.svg
new file mode 100644
index 00000000..01119280
--- /dev/null
+++ b/versions/6.5.0/install/images/cli.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/6.5.0/install/images/docker.svg b/versions/6.5.0/install/images/docker.svg
new file mode 100644
index 00000000..21190ce0
--- /dev/null
+++ b/versions/6.5.0/install/images/docker.svg
@@ -0,0 +1,6 @@
+
\ No newline at end of file
diff --git a/versions/6.5.0/install/images/github.svg b/versions/6.5.0/install/images/github.svg
new file mode 100644
index 00000000..aa05db9c
--- /dev/null
+++ b/versions/6.5.0/install/images/github.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/6.5.0/install/images/install.svg b/versions/6.5.0/install/images/install.svg
new file mode 100644
index 00000000..ae080865
--- /dev/null
+++ b/versions/6.5.0/install/images/install.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/6.5.0/install/images/mac.svg b/versions/6.5.0/install/images/mac.svg
new file mode 100644
index 00000000..3ee4fe28
--- /dev/null
+++ b/versions/6.5.0/install/images/mac.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/6.5.0/install/images/redhat.svg b/versions/6.5.0/install/images/redhat.svg
new file mode 100644
index 00000000..078b3387
--- /dev/null
+++ b/versions/6.5.0/install/images/redhat.svg
@@ -0,0 +1,69 @@
+
+
+  
+    
+      
+        image/svg+xml
+        
+        
+      
+    
+  
+  
+  
+    
+  
+  
+  
+
diff --git a/versions/6.5.0/install/images/suse.png b/versions/6.5.0/install/images/suse.png
new file mode 100644
index 00000000..6435b689
Binary files /dev/null and b/versions/6.5.0/install/images/suse.png differ
diff --git a/versions/6.5.0/install/images/tune.svg b/versions/6.5.0/install/images/tune.svg
new file mode 100644
index 00000000..8d7d63cb
--- /dev/null
+++ b/versions/6.5.0/install/images/tune.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/6.5.0/install/images/ubuntu.svg b/versions/6.5.0/install/images/ubuntu.svg
new file mode 100644
index 00000000..f217bc8d
--- /dev/null
+++ b/versions/6.5.0/install/images/ubuntu.svg
@@ -0,0 +1,8 @@
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/versions/6.5.0/install/images/windows.svg b/versions/6.5.0/install/images/windows.svg
new file mode 100644
index 00000000..120b0190
--- /dev/null
+++ b/versions/6.5.0/install/images/windows.svg
@@ -0,0 +1,5 @@
+
+
+
+
+
\ No newline at end of file
diff --git a/versions/6.5.0/install/index.mdx b/versions/6.5.0/install/index.mdx
index 0291a0c3..d1ff871f 100644
--- a/versions/6.5.0/install/index.mdx
+++ b/versions/6.5.0/install/index.mdx
@@ -6,7 +6,7 @@ title: 'Installing Bazel'
 This page describes the various platforms supported by Bazel and links
 to the packages for more details.
 
-[Bazelisk](/install/bazelisk) is the recommended way to install Bazel on [Ubuntu Linux](/install/ubuntu), [macOS](/install/os-x), and [Windows](/install/windows).
+[Bazelisk](/versions/6.5.0/install/bazelisk) is the recommended way to install Bazel on [Ubuntu Linux](/versions/6.5.0/install/ubuntu), [macOS](/versions/6.5.0/install/os-x), and [Windows](/versions/6.5.0/install/windows).
 
 ## Community-supported packages {#community-supported-packages}
 
@@ -14,13 +14,13 @@ Bazel community members maintain these packages. The Bazel team doesn't
 officially support them. Contact the package maintainers for support.
 
 *   [Arch Linux](https://www.archlinux.org/packages/community/x86_64/bazel/)
-*   [Fedora 25, 26, 27, 28, and CentOS 7](/install/redhat)
+*   [Fedora 25, 26, 27, 28, and CentOS 7](/versions/6.5.0/install/redhat)
 *   [CentOS 6](https://github.com/sub-mod/bazel-builds)
 *   [FreeBSD](https://www.freshports.org/devel/bazel)
 *   [Gentoo](https://packages.gentoo.org/packages/dev-util/bazel)
 *   [Linuxbrew](https://github.com/Linuxbrew/homebrew-core/blob/master/Formula/bazel.rb)
 *   [Nixpkgs](https://github.com/NixOS/nixpkgs/blob/master/pkgs/development/tools/build-managers/bazel)
-*   [openSUSE](/install/suse)
+*   [openSUSE](/versions/6.5.0/install/suse)
 *   [Parabola](https://www.parabola.nu/packages/?q=bazel)
 *   [Scoop](https://github.com/scoopinstaller/scoop-main/blob/master/bucket/bazel.json)
 *   [Raspberry Pi](https://github.com/koenvervloesem/bazel-on-arm/blob/master/README.md)
@@ -29,4 +29,4 @@ officially support them. Contact the package maintainers for support.
 
 *   [ppc64el](https://oplab9.parqtec.unicamp.br/pub/ppc64el/bazel)
 
-For other platforms, you can try to [compile from source](/install/compile-source).
+For other platforms, you can try to [compile from source](/versions/6.5.0/install/compile-source).
diff --git a/versions/6.5.0/install/os-x.mdx b/versions/6.5.0/install/os-x.mdx
index 101b5cb6..58aee372 100644
--- a/versions/6.5.0/install/os-x.mdx
+++ b/versions/6.5.0/install/os-x.mdx
@@ -7,15 +7,15 @@ This page describes how to install Bazel on macOS and set up your environment.
 
 You can install Bazel on macOS using one of the following methods:
 
-*   *Recommended*: [Use Bazelisk](/install/bazelisk)
+*   *Recommended*: [Use Bazelisk](/versions/6.5.0/install/bazelisk)
 *   [Use the binary installer](#install-with-installer-mac-os-x)
 *   [Use Homebrew](#install-on-mac-os-x-homebrew)
-*   [Compile Bazel from source](/install/compile-source)
+*   [Compile Bazel from source](/versions/6.5.0/install/compile-source)
 
 Bazel comes with two completion scripts. After installing Bazel, you can:
 
-*   Access the [bash completion script](/install/completion#bash)
-*   Install the [zsh completion script](/install/completion#zsh)
+*   Access the [bash completion script](/versions/6.5.0/install/completion#bash)
+*   Install the [zsh completion script](/versions/6.5.0/install/completion#zsh)
 
 
Installing using the binary installer

 
diff --git a/versions/6.5.0/install/redhat.mdx b/versions/6.5.0/install/redhat.mdx
index 269888ae..4ac88841 100644
--- a/versions/6.5.0/install/redhat.mdx
+++ b/versions/6.5.0/install/redhat.mdx
@@ -15,7 +15,7 @@ The commands below must be run either via `sudo` or while logged in as `root`.
 Add `--allowerasing` when installing an upgrade from a previous major
 version of the Bazel package.
 
-[The Bazelisk installer](/install/bazelisk) is an alternative to package installation.
+[The Bazelisk installer](/versions/6.5.0/install/bazelisk) is an alternative to package installation.
 
 ## Installing on Fedora 25+ {#installing-fedora}
 
diff --git a/versions/6.5.0/install/ubuntu.mdx b/versions/6.5.0/install/ubuntu.mdx
index ae60d607..c5b4d3ce 100644
--- a/versions/6.5.0/install/ubuntu.mdx
+++ b/versions/6.5.0/install/ubuntu.mdx
@@ -17,10 +17,10 @@ Bazel should be compatible with other Ubuntu releases and Debian
 
 Install Bazel on Ubuntu using one of the following methods:
 
-*   *Recommended*: [Use Bazelisk](/install/bazelisk)
+*   *Recommended*: [Use Bazelisk](/versions/6.5.0/install/bazelisk)
 *   [Use our custom APT repository](#install-on-ubuntu)
 *   [Use the binary installer](#binary-installer)
-*   [Compile Bazel from source](/install/compile-source)
+*   [Compile Bazel from source](/versions/6.5.0/install/compile-source)
 
 **Note:** For Arm-based systems, the APT repository does not contain an `arm64`
 release, and there is no binary installer available. Either use Bazelisk or
@@ -28,8 +28,8 @@ compile from source.
 
 Bazel comes with two completion scripts. After installing Bazel, you can:
 
-*   Access the [bash completion script](/install/completion#bash)
-*   Install the [zsh completion script](/install/completion#zsh)
+*   Access the [bash completion script](/versions/6.5.0/install/completion#bash)
+*   Install the [zsh completion script](/versions/6.5.0/install/completion#zsh)
 
 ### Step 1: Add Bazel distribution URI as a package source {#add-dis-uri}
 
diff --git a/versions/6.5.0/install/windows.mdx b/versions/6.5.0/install/windows.mdx
index 838ff89c..15a78222 100644
--- a/versions/6.5.0/install/windows.mdx
+++ b/versions/6.5.0/install/windows.mdx
@@ -37,8 +37,7 @@ Also supported:
 
 Alternatively you can:
 
-*   [Download the Bazel binary (`bazel-version-windows-x86_64.exe`) from
- GitHub](https://github.com/bazelbuild/bazel/releases).
+*   [Download the Bazel binary (`bazel-version-windows-x86_64.exe`) from GitHub](https://github.com/bazelbuild/bazel/releases).
 *   [Install Bazel from Chocolatey](#chocolately)
 *   [Install Bazel from Scoop](#scoop)
 *   [Build Bazel from source](/versions/6.5.0/install/compile-source)
@@ -216,8 +215,7 @@ If that doesn't help:
     its dependencies, such as the MSYS2 shell. This will not install Visual C++
     though.
 
-See [Chocolatey installation and package maintenance
-guide](/contribute/windows-chocolatey-maintenance) for more
+See [Chocolatey installation and package maintenance guide](/versions/6.5.0/contribute/windows-chocolatey-maintenance) for more
 information about the Chocolatey package.
 
 ### Using Scoop {#scoop}
@@ -234,8 +232,7 @@ information about the Chocolatey package.
     scoop install bazel
     ```
 
-See [Scoop installation and package maintenance
-guide](/contribute/windows-scoop-maintenance) for more
+See [Scoop installation and package maintenance guide](/versions/6.5.0/contribute/windows-scoop-maintenance) for more
 information about the Scoop package.
 
 ### Build from source {#build-from-source}
diff --git a/versions/6.5.0/migrate/index.mdx b/versions/6.5.0/migrate/index.mdx
index 215de29d..8d1467e0 100644
--- a/versions/6.5.0/migrate/index.mdx
+++ b/versions/6.5.0/migrate/index.mdx
@@ -5,6 +5,6 @@ title: 'Migrating to Bazel'
 
 This page links to migration guides for Bazel.
 
-*  [Maven](/migrate/maven)
-*  [Xcode](/migrate/xcode)
-*  [CocoaPods](/migrate/cocoapods)
+*  [Maven](/versions/6.5.0/migrate/maven)
+*  [Xcode](/versions/6.5.0/migrate/xcode)
+*  [CocoaPods](/versions/6.5.0/migrate/cocoapods)
diff --git a/versions/6.5.0/migrate/maven.mdx b/versions/6.5.0/migrate/maven.mdx
index 53ffd030..8c7762bf 100644
--- a/versions/6.5.0/migrate/maven.mdx
+++ b/versions/6.5.0/migrate/maven.mdx
@@ -20,9 +20,9 @@ directly run by Bazel since there's no Maven compatibility layer.
 
 ## Before you begin {#before-you-begin}
 
-*  [Install Bazel](/install) if it's not yet installed.
+*  [Install Bazel](/versions/6.5.0/install) if it's not yet installed.
 *  If you're new to Bazel, go through the tutorial
-   [Introduction to Bazel: Build Java](/tutorials/java) before you start
+   [Introduction to Bazel: Build Java](/versions/6.5.0/tutorials/java) before you start
    migrating. The tutorial explains Bazel's concepts, structure, and label
    syntax.
 
diff --git a/versions/6.5.0/migrate/xcode.mdx b/versions/6.5.0/migrate/xcode.mdx
index 1a72848f..99cc1a77 100644
--- a/versions/6.5.0/migrate/xcode.mdx
+++ b/versions/6.5.0/migrate/xcode.mdx
@@ -31,10 +31,10 @@ troubleshooting solutions to address common errors.
 
 Before you begin, do the following:
 
-1.  [Install Bazel](/install) if you have not already done so.
+1.  [Install Bazel](/versions/6.5.0/install) if you have not already done so.
 
 2.  If you're not familiar with Bazel and its concepts, complete the
-    [iOS app tutorial](/tutorials/ios-app). You should understand the Bazel
+    [iOS app tutorial](/versions/6.5.0/tutorials/ios-app). You should understand the Bazel
     workspace, including the `WORKSPACE` and `BUILD` files, as well as the
     concepts of targets, build rules, and Bazel packages.
 
@@ -46,7 +46,7 @@ Unlike Xcode, Bazel requires you to explicitly declare all dependencies for
 every target in the `BUILD` file.
 
 For more information on external dependencies, see
-[Working with external dependencies](/docs/external).
+[Working with external dependencies](/versions/6.5.0/docs/external).
 
 ## Build or test an Xcode project with Bazel {#build-xcode-project}
 
@@ -102,7 +102,7 @@ initial build of the project as follows:
 *  [Step 3c: Add the library target(s)](#step-3c-add-the-library-target-s)
 
 **Tip:** To learn more about packages and other Bazel concepts, see
-[Workspaces, packages, and targets](/concepts/build-ref).
+[Workspaces, packages, and targets](/versions/6.5.0/concepts/build-ref).
 
 #### Step 3a: Add the application target {#add-app-target}
 
@@ -157,7 +157,7 @@ simulator, also specify the `ios_application` target name as the value of the
 
 #### Step 3c: Add the library target(s) {#add-library-target}
 
-Add an [`objc_library`](/reference/be/objective-c#objc_library)
+Add an [`objc_library`](/versions/6.5.0/reference/be/objective-c#objc_library)
 target for each Objective-C library and a [`swift_library`](https://github.com/bazelbuild/rules_swift/blob/master/doc/rules.md#swift_library)
 target for each Swift library on which the application and/or tests depend.
 
@@ -173,7 +173,7 @@ Add the library targets as follows:
 
 *   List the headers in the `hdrs` attribute.
 
-Note: You can use the [`glob`](/reference/be/functions#glob)
+Note: You can use the [`glob`](/versions/6.5.0/reference/be/functions#glob)
 function to include all sources and/or headers of a certain type. Use it
 carefully as it might include files you do not want Bazel to build.
 
diff --git a/versions/6.5.0/query/aquery.mdx b/versions/6.5.0/query/aquery.mdx
index 1caf053a..263b939a 100644
--- a/versions/6.5.0/query/aquery.mdx
+++ b/versions/6.5.0/query/aquery.mdx
@@ -42,7 +42,7 @@ The query expression (in quotes) consists of the following:
 
 *   `aquery_function(...)`: functions specific to `aquery`.
     More details [below](#using-aquery-functions).
-*   `function(...)`: the standard [functions](/reference/query#functions)
+*   `function(...)`: the standard [functions](/versions/6.5.0/reference/query#functions)
     as traditional `query`.
 *   `//target` is the label to the interested target.
 
@@ -104,7 +104,7 @@ An example of the syntax error produced:
 ### Build options {#build-options}
 
 `aquery` runs on top of a regular Bazel build and thus inherits the set of
-[options](/reference/command-line-reference#build-options)
+[options](/versions/6.5.0/reference/command-line-reference#build-options)
 available during a build.
 
 ### Aquery options {#aquery-options}
@@ -155,9 +155,9 @@ This flag is only available with `--output=proto` or `--output=textproto`.
 
 ### Querying against the state of Skyframe {#querying-against-skyframe}
 
-[Skyframe](/reference/skyframe) is the evaluation and
+[Skyframe](/versions/6.5.0/reference/skyframe) is the evaluation and
 incrementality model of Bazel. On each instance of Bazel server, Skyframe stores the dependency graph
-constructed from the previous runs of the [Analysis phase](/docs/build#analysis).
+constructed from the previous runs of the [Analysis phase](/versions/6.5.0/docs/build#analysis).
 
 In some cases, it is useful to query the Action Graph on Skyframe.
 An example use case would be:
@@ -269,7 +269,7 @@ to be compared.
 
 ### Aspect-on-aspect {#aspect-on-aspect}
 
-It is possible for [Aspects](/rules/aspects)
+It is possible for [Aspects](/versions/6.5.0/rules/aspects)
 to be applied on top of each other. The aquery output of the action generated by
 these Aspects would then include the _Aspect path_, which is the sequence of
 Aspects applied to the target which generated the action.
@@ -315,12 +315,12 @@ Each `AspectDescriptor` has the following format:
 `AspectClass` could be the name of the Aspect class (for native Aspects) or
 `bzl_file%aspect_name` (for Starlark Aspects). `AspectDescriptor` are
 sorted in topological order of the
-[dependency graph](/rules/aspects#aspect_basics).
+[dependency graph](/versions/6.5.0/rules/aspects#aspect_basics).
 
 ### Linking with the JSON profile {#linking-with-json-profile}
 
 While aquery provides information about the actions being run in a build (why they're being run,
-their inputs/outputs), the [JSON profile](/rules/performance#performance-profiling)
+their inputs/outputs), the [JSON profile](/versions/6.5.0/rules/performance#performance-profiling)
 tells us the timing and duration of their execution.
 It is possible to combine these 2 sets of information via a common denominator: an action's primary output.
 
diff --git a/versions/6.5.0/query/cquery.mdx b/versions/6.5.0/query/cquery.mdx
index 0e33d47b..65ceb2d9 100644
--- a/versions/6.5.0/query/cquery.mdx
+++ b/versions/6.5.0/query/cquery.mdx
@@ -3,12 +3,11 @@ title: 'Configurable Query (cquery)'
 ---
 
 
-`cquery` is a variant of [`query`](/reference/query) that correctly handles
-[`select()`](/docs/configurable-attributes) and build options' effects on the build
+`cquery` is a variant of [`query`](/versions/6.5.0/reference/query) that correctly handles
+[`select()`](/versions/6.5.0/docs/configurable-attributes) and build options' effects on the build
 graph.
 
-It achieves this by running over the results of Bazel's [analysis
-phase](/rules/concepts#evaluation-model),
+It achieves this by running over the results of Bazel's [analysis phase](/versions/6.5.0/rules/concepts#evaluation-model),
 which integrates these effects. `query`, by constrast, runs over the results of
 Bazel's loading phase, before options are evaluated.
 
@@ -59,12 +58,12 @@ $ bazel cquery "deps(//tree:ash)" --define species=excelsior --noimplicit_deps
 ```
 
 Each result includes a [unique identifier](#configurations) `(9f87702)` of
-the [configuration](/reference/glossary#configuration) the
+the [configuration](/versions/6.5.0/reference/glossary#configuration) the
 target is built with.
 
 Since `cquery` runs over the configured target graph. it doesn't have insight
-into artifacts like build actions nor access to `[test_suite](/reference/be/general#test_suite)`
-rules as they are not configured targets. For the former, see `[aquery](/docs/aquery)`.
+into artifacts like build actions nor access to `[test_suite](/versions/6.5.0/reference/be/general#test_suite)`
+rules as they are not configured targets. For the former, see `[aquery](/versions/6.5.0/docs/aquery)`.
 
 ## Basic syntax {#basic-syntax}
 
@@ -76,14 +75,14 @@ The query expression `"function(//target)"` consists of the following:
 
 *   **`function(...)`** is the function to run on the target. `cquery`
     supports most
-    of `query`'s [functions](/reference/query#functions), plus a
+    of `query`'s [functions](/versions/6.5.0/reference/query#functions), plus a
     few new ones.
 *   **`//target`** is the expression fed to the function. In this example, the
     expression is a simple target. But the query language also allows nesting of functions.
-    See the [Query How-To](/query/quickstart) for examples.
+    See the [Query How-To](/versions/6.5.0/query/quickstart) for examples.
 
 
-`cquery` requires a target to run through the [loading and analysis](/rules/concepts#evaluation-model)
+`cquery` requires a target to run through the [loading and analysis](/versions/6.5.0/rules/concepts#evaluation-model)
 phases. Unless otherwise specified, `cquery` parses the target(s) listed in the
 query expression. See [`--universe_scope`](#universe-scope)
 for querying dependencies of top-level build targets.
@@ -125,7 +124,7 @@ configured versions of `//foo`.
 For `cquery`, a target pattern in the query expression evaluates
 to every configured target with a label that matches that pattern. Output is
 deterministic, but `cquery` makes no ordering guarantee beyond the
-[core query ordering contract](/reference/query#graph-order).
+[core query ordering contract](/versions/6.5.0/reference/query#graph-order).
 
 This produces subtler results for query expressions than with `query`.
 For example, the following can produce multiple results:
@@ -143,15 +142,14 @@ $ bazel cquery //foo --universe_scope=//foo,//genrule_with_foo_as_tool
 If you want to precisely declare which instance to query over, use
 the [`config`](#config) function.
 
-See `query`'s [target pattern
-documentation](/reference/query#target-patterns) for more information on target patterns.
+See `query`'s [target pattern documentation](/versions/6.5.0/reference/query#target-patterns) for more information on target patterns.
 
 ## Functions {#functions}
 
-Of the [set of functions](/reference/query#functions "list of query functions")
-supported by `query`, `cquery` supports all but [`visible`](/reference/query#visible),
-[`siblings`](/reference/query#siblings), [`buildfiles`](/reference/query#buildfiles),
-and [`tests`](/reference/query#tests).
+Of the [set of functions](/versions/6.5.0/reference/query#functions "list of query functions")
+supported by `query`, `cquery` supports all but [`visible`](/versions/6.5.0/reference/query#visible),
+[`siblings`](/versions/6.5.0/reference/query#siblings), [`buildfiles`](/versions/6.5.0/reference/query#buildfiles),
+and [`tests`](/versions/6.5.0/reference/query#tests).
 
 `cquery` also introduces the following new functions:
 
@@ -190,14 +188,14 @@ can be found in the specified configuration, the query fails.
 ### Build options {#build-options}
 
 `cquery` runs over a regular Bazel build and thus inherits the set of
-[options](/reference/command-line-reference#build-options) available during a build.
+[options](/versions/6.5.0/reference/command-line-reference#build-options) available during a build.
 
 ###  Using cquery options {#using-cquery-options}
 
 #### `--universe_scope` (comma-separated list) {#universe-scope}
 
 Often, the dependencies of configured targets go through
-[transitions](/rules/rules#configurations),
+[transitions](/versions/6.5.0/rules/rules#configurations),
 which causes their configuration to differ from their dependent. This flag
 allows you to query a target as if it were built as a dependency or a transitive
 dependency of another target. For example:
@@ -217,7 +215,7 @@ cc_library(
 ```
 
 Genrules configure their tools in the
-[host configuration](/rules/rules#configurations)
+[host configuration](/versions/6.5.0/rules/rules#configurations)
 so the following queries would produce the following outputs:
 
 
@@ -268,7 +266,7 @@ toolchains.
 Setting this flag to false filters out all configured targets for which the
 path from the queried target to them crosses a transition between the target
 configuration and the
-[non-target configurations](/rules/rules#configurations).
+[non-target configurations](/versions/6.5.0/rules/rules#configurations).
 If the queried target is in the target configuration, setting `--notool_deps` will
 only return targets that also are in the target configuration. If the queried
 target is in a non-target configuration, setting `--notool_deps` will only return
@@ -277,7 +275,7 @@ of resolved toolchains.
 
 #### `--include_aspects` (boolean, default=True) {#include-aspects}
 
-[Aspects](/rules/aspects) can add
+[Aspects](/versions/6.5.0/rules/aspects) can add
 additional dependencies to a build. By default, `cquery` doesn't follow aspects because
 they make the queryable graph bigger, which uses more memory. But following them produces more
 accurate results.
@@ -300,7 +298,7 @@ There are other options for exposing the results as well.
 --transitions=full
 ```
 
-Configuration [transitions](/rules/rules#configurations)
+Configuration [transitions](/versions/6.5.0/rules/rules#configurations)
 are used to build targets underneath the top level targets in different
 configurations than the top level targets.
 
@@ -338,7 +336,7 @@ By default, cquery results return configuration information as part of each
 configured target. If you'd like to omit this information and get proto output
 that is formatted exactly like query's proto output, set this flag to false.
 
-See [query's proto output documentation](/reference/query#output-formats)
+See [query's proto output documentation](/versions/6.5.0/reference/query#output-formats)
 for more proto output-related options.
 
 Note: While selects are resolved both at the top level of returned
@@ -352,9 +350,9 @@ included as `rule_input` fields.
 ```
 
 This option generates output as a Graphviz-compatible .dot file. See `query`'s
-[graph output documentation](/reference/query#display-result-graph) for details. `cquery`
-also supports [`--graph:node_limit`](/reference/query#graph-nodelimit) and
-[`--graph:factored`](/reference/query#graph-factored).
+[graph output documentation](/versions/6.5.0/reference/query#display-result-graph) for details. `cquery`
+also supports [`--graph:node_limit`](/versions/6.5.0/reference/query#graph-nodelimit) and
+[`--graph:factored`](/versions/6.5.0/reference/query#graph-factored).
 
 ### Files output {#files-output}
 
@@ -366,7 +364,7 @@ This option prints a list of the output files produced by each target matched
 by the query similar to the list printed at the end of a `bazel build`
 invocation. The output contains only the files advertised in the requested
 output groups as determined by the
-[`--output_groups`](/reference/command-line-reference#flag--output_groups) flag.
+[`--output_groups`](/versions/6.5.0/reference/command-line-reference#flag--output_groups) flag.
 It does include source files.
 
 Note: The output of `bazel cquery --output=files //pkg:foo` contains the output
@@ -380,11 +378,11 @@ is not desired, wrap you query in [`config(..., target)`](#config).
 --output=starlark
 ```
 
-This output format calls a [Starlark](/rules/language)
+This output format calls a [Starlark](/versions/6.5.0/rules/language)
 function for each configured target in the query result, and prints the value
 returned by the call. The `--starlark:file` flag specifies the location of a
 Starlark file that defines a function named `format` with a single parameter,
-`target`. This function is called for each [Target](/rules/lib/Target)
+`target`. This function is called for each [Target](/versions/6.5.0/rules/lib/builtins/Target)
 in the query result. Alternatively, for convenience, you may specify just the
 body of a function declared as `def format(target): return expr` by using the
 `--starlark:expr` flag.
@@ -400,7 +398,7 @@ plus a few cquery-specific ones described below, but not (for example) `glob`,
 ##### build_options(target) {#build-options-function}
 
 `build_options(target)` returns a map whose keys are build option identifiers (see
-[Configurations](/rules/config))
+[Configurations](/versions/6.5.0/rules/config))
 and whose values are their Starlark values. Build options whose values are not legal Starlark
 values are omitted from this map.
 
@@ -410,7 +408,7 @@ targets have a null configuration.
 ##### providers(target) {#providers}
 
 `providers(target)` returns a map whose keys are names of
-[providers](/rules/rules#providers)
+[providers](/versions/6.5.0/rules/rules#providers)
 (for example, `"DefaultInfo"`) and whose values are their Starlark values. Providers
 whose values are not legal Starlark values are omitted from this map.
 
@@ -528,7 +526,7 @@ different niches. Consider the following to decide which is right for you:
     evaluates _configured targets_ while `query` only
     evaluates _targets_. This takes more time and uses more memory.
 *   `cquery`'s intepretation of
-    the [query language](/reference/query) introduces ambiguity
+    the [query language](/versions/6.5.0/reference/query) introduces ambiguity
     that `query` avoids. For example,
     if `"//foo"` exists in two configurations, which one
     should `cquery "deps(//foo)"` use?
@@ -549,7 +547,7 @@ must have the same configuration.
 
 While these generally share the top-level "target" configuration,
 rules can change their own configuration with
-[incoming edge transitions](/rules/config#incoming-edge-transitions).
+[incoming edge transitions](/versions/6.5.0/rules/config#incoming-edge-transitions).
 This is where `cquery` falls short.
 
 Workaround: If possible, set `--universe_scope` to a stricter
@@ -568,7 +566,7 @@ configurations is not supported)
 $ bazel cquery 'somepath(//foo, //bar)' --universe_scope=//foo
 ```
 
-**No support for [`--output=xml`](/reference/query#xml).**
+**No support for [`--output=xml`](/versions/6.5.0/reference/query#xml).**
 
 **Non-deterministic output.**
 
@@ -576,7 +574,7 @@ $ bazel cquery 'somepath(//foo, //bar)' --universe_scope=//foo
 previous commands and is therefore prone to picking up results from past
 queries. For example, `genquery` exerts a host transition on
 its `tools` attribute - that is, it configures its tools in the
-[host configuration](/rules/rules#configurations).
+[host configuration](/versions/6.5.0/rules/rules#configurations).
 
 You can see the lingering effects of that transition below.
 
diff --git a/versions/6.5.0/query/images/query_graph1.png b/versions/6.5.0/query/images/query_graph1.png
new file mode 100644
index 00000000..7bc9a61a
Binary files /dev/null and b/versions/6.5.0/query/images/query_graph1.png differ
diff --git a/versions/6.5.0/query/images/query_graph2.png b/versions/6.5.0/query/images/query_graph2.png
new file mode 100644
index 00000000..a0da22ff
Binary files /dev/null and b/versions/6.5.0/query/images/query_graph2.png differ
diff --git a/versions/6.5.0/query/images/query_graph3.png b/versions/6.5.0/query/images/query_graph3.png
new file mode 100644
index 00000000..4418f193
Binary files /dev/null and b/versions/6.5.0/query/images/query_graph3.png differ
diff --git a/versions/6.5.0/query/language.mdx b/versions/6.5.0/query/language.mdx
index 86e3aa20..b2fdbf30 100644
--- a/versions/6.5.0/query/language.mdx
+++ b/versions/6.5.0/query/language.mdx
@@ -1098,8 +1098,7 @@ is being used.
 
 ### On the ordering of results {#results-ordering}
 
-Although query expressions always follow the "[law of
-conservation of graph order](#graph-order)", _presenting_ the results may be done
+Although query expressions always follow the "[law of conservation of graph order](#graph-order)", _presenting_ the results may be done
 in either a dependency-ordered or unordered manner. This does **not**
 influence the targets in the result set or how the query is computed. It only
 affects how the results are printed to stdout. Moreover, nodes that are
@@ -1198,8 +1197,7 @@ and `maxrank` output formats print the labels of each
 target in the resulting graph, but instead of appearing in
 topological order, they appear in rank order, preceded by their
 rank number. These are unaffected by the result ordering
-`--[no]order_results` flag (see [notes on
-the ordering of results](#result-order)).
+`--[no]order_results` flag (see [notes on the ordering of results](#result-order)).
 
 There are two variants of this format: `minrank` ranks
 each node by the length of the shortest path from a root node to it.
diff --git a/versions/6.5.0/reference/glossary.mdx b/versions/6.5.0/reference/glossary.mdx
index 03dd90bc..4c2be822 100644
--- a/versions/6.5.0/reference/glossary.mdx
+++ b/versions/6.5.0/reference/glossary.mdx
@@ -9,7 +9,7 @@ A command to run during the build, for example, a call to a compiler that takes
 Includes metadata like the command line arguments, action key, environment
 variables, and declared input/output artifacts.
 
-**See also:** [Rules documentation](/rules/rules#actions)
+**See also:** [Rules documentation](/versions/6.5.0/rules/rules#actions)
 
 ### Action cache {#action-cache}
 An on-disk cache that stores a mapping of executed [actions](#action) to the
@@ -22,8 +22,7 @@ An in-memory graph of [actions](#action) and the [artifacts](#artifact) that
 these actions read and generate. The graph might include artifacts that exist as
 source files (for example, in the file system) as well as generated
 intermediate/final artifacts that are not mentioned in `BUILD` files. Produced
-during the [analysis phase](#analysis-phase) and used during the [execution
-phase](#execution-phase).
+during the [analysis phase](#analysis-phase) and used during the [execution phase](#execution-phase).
 
 ### Action graph query (aquery) {#action-graph-query}
 A [query](#query-concept) tool that can query over build [actions](#action).
@@ -38,8 +37,7 @@ invalidate individual actions deterministically.
 
 ### Analysis phase {#analysis-phase}
 The second phase of a build. Processes the [target graph](#target-graph)
-specified in [`BUILD` files](#build-file) to produce an in-memory [action
-graph](#action-graph) that determines the order of actions to run during the
+specified in [`BUILD` files](#build-file) to produce an in-memory [action graph](#action-graph) that determines the order of actions to run during the
 [execution phase](#execution-phase). This is the phase in which rule
 implementations are evaluated.
 
@@ -62,7 +60,7 @@ cached and reused between targets requiring the same aspect. Created with the
 `aspect()` Starlark Build API function. Can be used, for example, to generate
 metadata for IDEs, and create actions for linting.
 
-**See also:** [Aspects documentation](/rules/aspects)
+**See also:** [Aspects documentation](/versions/6.5.0/rules/aspects)
 
 ### Aspect-on-aspect {#aspect-on-aspect}
 A composition mechanism whereby aspects can be applied to the results
@@ -71,8 +69,8 @@ IDEs can be applied on top of an aspect that generates `.java` files from a
 proto.
 
 For an aspect `A` to apply on top of aspect `B`, the [providers](#provider) that
-`B` advertises in its [`provides`](/rules/lib/globals#aspect.provides) attribute
-must match what `A` declares it wants in its [`required_aspect_providers`](/rules/lib/globals#aspect.required_aspect_providers)
+`B` advertises in its [`provides`](/versions/6.5.0/rules/lib/globals#aspect.provides) attribute
+must match what `A` declares it wants in its [`required_aspect_providers`](/versions/6.5.0/rules/lib/globals#aspect.required_aspect_providers)
 attribute.
 
 ### Attribute {#attribute}
@@ -82,8 +80,7 @@ target's source files, dependencies, and custom compiler options. The particular
 attributes available for a given target depend on its rule type.
 
 ### .bazelrc {#bazelrc}
-Bazel’s configuration file used to change the default values for [startup
-flags](#startup-flags) and [command flags](#command-flags), and to define common
+Bazel’s configuration file used to change the default values for [startup flags](#startup-flags) and [command flags](#command-flags), and to define common
 groups of options that can then be set together on the Bazel command line using
 a `--config` flag. Bazel can combine settings from multiple bazelrc files
 (systemwide, per-workspace, per-user, or from a custom location), and a
@@ -109,8 +106,7 @@ directory.
 
 ### .bzl File {#bzl-file}
 A file that defines rules, [macros](#macro), and constants written in
-[Starlark](#starlark). These can then be imported into [`BUILD`
-files](#build-file) using the `load()` function.
+[Starlark](#starlark). These can then be imported into [`BUILD` files](#build-file) using the `load()` function.
 
 // TODO: ### Build event protocol
 
@@ -118,8 +114,7 @@ files](#build-file) using the `load()` function.
 
 ### Build graph {#build-graph}
 The dependency graph that Bazel constructs and traverses to perform a build.
-Includes nodes like [targets](#target), [configured
-targets](#configured-target), [actions](#action), and [artifacts](#artifact). A
+Includes nodes like [targets](#target), [configured targets](#configured-target), [actions](#action), and [artifacts](#artifact). A
 build is considered complete when all [artifacts](#artifact) on which a set of
 requested targets depend are verified as up-to-date.
 
@@ -159,11 +154,10 @@ graphs and restart the [analysis phase](#analysis-phase).
 ### Configuration {#configuration}
 Information outside of [rule](#rule) definitions that impacts how rules generate
 [actions](#action). Every build has at least one configuration specifying the
-target platform, action environment variables, and command-line [build
-flags](#command-flags). [Transitions](#transition) may create additional
+target platform, action environment variables, and command-line [build flags](#command-flags). [Transitions](#transition) may create additional
 configurations, such as for host tools or cross-compilation.
 
-**See also:** [Configurations](/rules/rules#configurations)
+**See also:** [Configurations](/versions/6.5.0/rules/rules#configurations)
 
 // TODO: ### Configuration fragment
 
@@ -175,12 +169,11 @@ configuration of `//:c` because changing `--javacopt` unnecessarily breaks C++
 build cacheability.
 
 ### Configured query (cquery) {#configured-query}
-A [query](#query-concept) tool that queries over [configured
-targets](#configured-target) (after the [analysis phase](#analysis-phase)
+A [query](#query-concept) tool that queries over [configured targets](#configured-target) (after the [analysis phase](#analysis-phase)
 completes). This means `select()` and [build flags](#command-flags) (such as
 `--platforms`) are accurately reflected in the results.
 
-**See also:** [cquery documentation](/docs/cquery)
+**See also:** [cquery documentation](/versions/6.5.0/docs/cquery)
 
 ### Configured target {#configured-target}
 The result of evaluating a [target](#target) with a
@@ -192,8 +185,7 @@ build, it has two configured targets: `` and ``.
 ### Correctness {#correctness}
 A build is correct when its output faithfully reflects the state of its
 transitive inputs. To achieve correct builds, Bazel strives to be
-[hermetic](#hermeticity), reproducible, and making [build
-analysis](#analysis-phase) and [action execution](#execution-phase)
+[hermetic](#hermeticity), reproducible, and making [build analysis](#analysis-phase) and [action execution](#execution-phase)
 deterministic.
 
 ### Dependency {#dependency}
@@ -213,7 +205,7 @@ the rule is at the top level of the build graph. Flattening large depsets incurs
 huge memory consumption. Also known as *nested sets* in Bazel's internal
 implementation.
 
-**See also:** [Depset documentation](/rules/depsets)
+**See also:** [Depset documentation](/versions/6.5.0/rules/depsets)
 
 ### Disk cache {#disk-cache}
 A local on-disk blob store for the remote caching feature. Can be used in
@@ -232,8 +224,7 @@ compilation). A dynamic execution strategy can provide the best possible
 incremental and clean build times.
 
 ### Execution phase {#execution-phase}
-The third phase of a build. Executes the [actions](#action) in the [action
-graph](#action-graph) created during the [analysis phase](#analysis-phase).
+The third phase of a build. Executes the [actions](#action) in the [action graph](#action-graph) created during the [analysis phase](#analysis-phase).
 These actions invoke executables (compilers, scripts) to read and write
 [artifacts](#artifact). *Spawn strategies* control how these actions are
 executed: locally, remotely, dynamically, sandboxed, docker, and so on.
@@ -271,18 +262,15 @@ build.
 ### Label {#label}
 An identifier for a [target](#target). A fully-qualified label such as
 `//path/to/package:target` consists of `//` to mark the workspace root
-directory, `path/to/package` as the directory that contains the [`BUILD`
-file](#build-file) declaring the target, and `:target` as the name of the target
+directory, `path/to/package` as the directory that contains the [`BUILD` file](#build-file) declaring the target, and `:target` as the name of the target
 declared in the aforementioned `BUILD` file. May also be prefixed with
 `@my_repository//<..>` to indicate that the target is declared in an ]external
 repository] named `my_repository`.
 
 ### Loading phase {#loading-phase}
-The first phase of a build where Bazel parses `WORKSPACE`, `BUILD`, and [`.bzl`
-files](#bzl-file) to create [packages](#package). [Macros](#macro) and certain
+The first phase of a build where Bazel parses `WORKSPACE`, `BUILD`, and [`.bzl` files](#bzl-file) to create [packages](#package). [Macros](#macro) and certain
 functions like `glob()` are evaluated in this phase. Interleaved with the second
-phase of the build, the [analysis phase](#analysis-phase), to build up a [target
-graph](#target-graph).
+phase of the build, the [analysis phase](#analysis-phase), to build up a [target graph](#target-graph).
 
 ### Macro {#macro}
 A mechanism to compose multiple [rule](#rule) target declarations together under
@@ -290,7 +278,7 @@ a single [Starlark](#starlark) function. Enables reusing common rule declaration
 patterns across `BUILD` files. Expanded to the underlying rule target declarations
 during the [loading phase](#loading-phase).
 
-**See also:** [Macro documentation](/rules/macros)
+**See also:** [Macro documentation](/versions/6.5.0/rules/macros)
 
 ### Mnemonic {#mnemonic}
 A short, human-readable string selected by a rule author to quickly understand
@@ -307,8 +295,7 @@ example, `native.cc_library` or `native.java_library`). User-defined rules
 
 ### Output base {#output-base}
 A [workspace](#workspace)-specific directory to store Bazel output files. Used
-to separate outputs from the *workspace*'s source tree. Located in the [output
-user root](#output-user-root).
+to separate outputs from the *workspace*'s source tree. Located in the [output user root](#output-user-root).
 
 ### Output groups {#output-groups}
 A group of files that is expected to be built when Bazel finishes building a
@@ -354,7 +341,7 @@ Note: The object holding specific data for a given rule target is
 referred to as a "provider instance", although sometimes this is conflated with
 "provider".
 
-**See also:** [Provider documentation](/rules/rules#providers)
+**See also:** [Provider documentation](/versions/6.5.0/rules/rules#providers)
 
 ### Query (concept) {#query-concept}
 The process of analyzing a [build graph](#build-graph) to understand
@@ -363,12 +350,11 @@ query variants: [query](#query-command), [cquery](#configured-query), and
 [aquery](#action-graph-query).
 
 ### query (command) {#query-command}
-A [query](#query-concept) tool that operates over the build's post-[loading
-phase](#loading-phase) [target graph](#target-graph). This is relatively fast,
+A [query](#query-concept) tool that operates over the build's post-[loading phase](#loading-phase) [target graph](#target-graph). This is relatively fast,
 but can't analyze the effects of `select()`, [build flags](#command-flags),
 [artifacts](#artifact), or build [actions](#action).
 
-**See also:** [Query how-to](/docs/query-how-to), [Query reference](/reference/query)
+**See also:** [Query how-to](/versions/6.5.0/docs/query-how-to), [Query reference](/versions/6.5.0/reference/query)
 
 ### Repository cache {#repo-cache}
 A shared content-addressable cache of files downloaded by Bazel for builds,
@@ -399,14 +385,13 @@ Rules are instantiated to produce rule targets in the
 [loading phase](#loading-phase). In the [analysis phase](#analysis-phase) rule
 targets communicate information to their downstream dependencies in the form of
 [providers](#provider), and register [actions](#action) describing how to
-generate their output artifacts. These actions are run in the [execution
-phase](#execution-phase).
+generate their output artifacts. These actions are run in the [execution phase](#execution-phase).
 
 Note: Historically the term "rule" has been used to refer to a rule target.
 This usage was inherited from tools like Make, but causes confusion and should
 be avoided for Bazel.
 
-**See also:** [Rules documentation](/rules/rules)
+**See also:** [Rules documentation](/versions/6.5.0/rules/rules)
 
 ### Rule target {#rule-target}
 A [target](#target) that is an instance of a rule. Contrasts with file targets
@@ -419,7 +404,7 @@ data dependencies of the test. Before the invocation of the executable (during
 bazel test), Bazel prepares the tree of runfiles alongside the test executable
 according to their source directory structure.
 
-**See also:** [Runfiles documentation](/rules/rules#runfiles)
+**See also:** [Runfiles documentation](/versions/6.5.0/rules/rules#runfiles)
 
 ### Sandboxing {#sandboxing}
 A technique to isolate a running [action](#action) inside a restricted and
@@ -430,7 +415,7 @@ support from the operating system. The performance cost depends on the platform.
 On Linux, it's not significant, but on macOS it can make sandboxing unusable.
 
 ### Skyframe {#skyframe}
-[Skyframe](/reference/skyframe) is the core parallel, functional, and incremental evaluation framework of Bazel.
+[Skyframe](/versions/6.5.0/reference/skyframe) is the core parallel, functional, and incremental evaluation framework of Bazel.
 
 // TODO: ### Spawn strategy
 
@@ -438,18 +423,17 @@ On Linux, it's not significant, but on macOS it can make sandboxing unusable.
 A feature to embed additional information into Bazel-built
 [artifacts](#artifact). For example, this can be used for source control, build
 time and other workspace or environment-related information for release builds.
-Enable through the `--workspace_status_command` flag and [rules](/rules/rules) that
+Enable through the `--workspace_status_command` flag and [rules](/versions/6.5.0/rules/rules) that
 support the stamp attribute.
 
 ### Starlark {#starlark}
-The extension language for writing [rules](/rules/rules) and [macros](#macro). A
+The extension language for writing [rules](/versions/6.5.0/rules/rules) and [macros](#macro). A
 restricted subset of Python (syntactically and grammatically) aimed for the
-purpose of configuration, and for better performance. Uses the [`.bzl`
-file](#bzl-file) extension. [`BUILD` files](#build-file) use an even more
+purpose of configuration, and for better performance. Uses the [`.bzl` file](#bzl-file) extension. [`BUILD` files](#build-file) use an even more
 restricted version of Starlark (such as no `def` function definitions), formerly
 known as Skylark.
 
-**See also:** [Starlark language documentation](/rules/language)
+**See also:** [Starlark language documentation](/versions/6.5.0/rules/language)
 
 // TODO: ### Starlark rules
 
@@ -467,8 +451,7 @@ An object that is defined in a [`BUILD` file](#build-file) and identified by a
 [label](#label). Targets represent the buildable units of a workspace from
 the perspective of the end user.
 
-A target that is declared by instantiating a [rule](#rule) is called a [rule
-target](#rule-target). Depending on the rule, these may be runnable (like
+A target that is declared by instantiating a [rule](#rule) is called a [rule target](#rule-target). Depending on the rule, these may be runnable (like
 `cc_binary`) or testable (like `cc_test`). Rule targets typically depend on
 other targets via their [attributes](#attribute) (such as `deps`); these
 dependencies form the basis of the [target graph](#target-graph).
@@ -479,14 +462,11 @@ within a `BUILD` file. As a special case, the `BUILD` file of any package is
 always considered a source file target in that package.
 
 Targets are discovered during the [loading phase](#loading-phase). During the
-[analysis phase](#analysis-phase), targets are associated with [build
-configurations](#configuration) to form [configured
-targets](#configured-target).
+[analysis phase](#analysis-phase), targets are associated with [build configurations](#configuration) to form [configured targets](#configured-target).
 
 ### Target graph {#target-graph}
 An in-memory graph of [targets](#target) and their dependencies. Produced during
-the [loading phase](#loading-phase) and used as an input to the [analysis
-phase](#analysis-phase).
+the [loading phase](#loading-phase) and used as an input to the [analysis phase](#analysis-phase).
 
 ### Target pattern {#target-pattern}
 A way to specify a group of [targets](#target) on the command line. Commonly
@@ -499,8 +479,7 @@ packages recursively from the root of the [workspace](#workspace).
 Rule [targets](#target) instantiated from test rules, and therefore contains a
 test executable. A return code of zero from the completion of the executable
 indicates test success. The exact contract between Bazel and tests (such as test
-environment variables, test result collection methods) is specified in the [Test
-Encyclopedia](/reference/test-encyclopedia).
+environment variables, test result collection methods) is specified in the [Test Encyclopedia](/versions/6.5.0/reference/test-encyclopedia).
 
 ### Toolchain {#toolchain}
 A set of tools to build outputs for a language. Typically, a toolchain includes
@@ -514,8 +493,7 @@ A build [target](#target) is top-level if it’s requested on the Bazel command
 line. For example, if `//:foo` depends on `//:bar`, and `bazel build //:foo` is
 called, then for this build, `//:foo` is top-level, and `//:bar` isn’t
 top-level, although both targets will need to be built. An important difference
-between top-level and non-top-level targets is that [command
-flags](#command-flags) set on the Bazel command line (or via
+between top-level and non-top-level targets is that [command flags](#command-flags) set on the Bazel command line (or via
 [.bazelrc](#bazelrc)) will set the [configuration](#configuration) for top-level
 targets, but might be modified by a [transition](#transition) for non-top-level
 targets.
@@ -529,7 +507,7 @@ the [target graph](#target-graph) is forked with distinct configurations for
 each fork. For example, one can build an Android APK with native binaries
 compiled for ARM and x86 using split transitions in a single build.
 
-**See also:** [User-defined transitions](/rules/config#user-defined-transitions)
+**See also:** [User-defined transitions](/versions/6.5.0/rules/config#user-defined-transitions)
 
 ### Tree artifact {#tree-artifact}
 An [artifact](#artifact) that represents a collection of files. Since these
@@ -543,7 +521,7 @@ upon by other targets; and *load visibility* for controlling whether a `BUILD`
 or `.bzl` file may load a given `.bzl` file. Without context, usually
 "visibility" refers to target visibility.
 
-**See also:** [Visibility documentation](/concepts/visibility)
+**See also:** [Visibility documentation](/versions/6.5.0/concepts/visibility)
 
 ### Workspace {#workspace}
 A directory containing a `WORKSPACE` file and source code for the software you
diff --git a/versions/6.5.0/release/backward-compatibility.mdx b/versions/6.5.0/release/backward-compatibility.mdx
index 712e4f30..eb9834dd 100644
--- a/versions/6.5.0/release/backward-compatibility.mdx
+++ b/versions/6.5.0/release/backward-compatibility.mdx
@@ -8,7 +8,7 @@ including migrating from one release to another and how to communicate
 incompatible changes.
 
 Bazel is evolving. Minor versions released as part of an
-[LTS major version](/release/versioning#lts-releases) are fully backward-compatible.
+[LTS major version](/versions/6.5.0/release/versioning#lts-releases) are fully backward-compatible.
 Changes between major LTS releases may contain incompatible changes that require
 some migration effort. For more information on how the Bazel release cadence
 works, see
@@ -24,8 +24,8 @@ works, see
 
 ## How to follow this policy {#policy}
 
-* [For Bazel users - how to update Bazel](/versions/updating-bazel)
-* [For contributors - best practices for incompatible changes](/contribute/breaking-changes)
+* [For Bazel users - how to update Bazel](/versions/6.5.0/versions/updating-bazel)
+* [For contributors - best practices for incompatible changes](/versions/6.5.0/contribute/breaking-changes)
 * [For release managers - how to update issue labels and release](https://github.com/bazelbuild/continuous-integration/tree/master/docs/release-playbook.%6D%64)
 
 ## What is stable functionality? {#stable-functionality}
diff --git a/versions/6.5.0/release/index.mdx b/versions/6.5.0/release/index.mdx
index f9aec496..e6ade895 100644
--- a/versions/6.5.0/release/index.mdx
+++ b/versions/6.5.0/release/index.mdx
@@ -4,7 +4,7 @@ title: 'Release Policy'
 
 
 Bazel maintains a
-[Long Term Support (LTS)](/release/versioning)
+[Long Term Support (LTS)](/versions/6.5.0/release/versioning)
 release model, where a major version is released every nine months and minor
 versions are released monthly. This page covers the Bazel release policy,
 including the release candidates, timelines, announcements, and testing.
diff --git a/versions/6.5.0/release/versioning.mdx b/versions/6.5.0/release/versioning.mdx
index 37d4d6a0..6ec68611 100644
--- a/versions/6.5.0/release/versioning.mdx
+++ b/versions/6.5.0/release/versioning.mdx
@@ -33,7 +33,7 @@ LTS release to the next, or updating with each minor version release.
 The image shows both rolling and LTS releases, and the expected support for
 each.
 
-![Roadmap](/docs/images/roadmap.png "Roadmap")
+![Roadmap](/versions/6.5.0/docs/images/roadmap.png "Roadmap")
 
 **Figure 1.** Rolling and LTS releases.
 
@@ -89,6 +89,6 @@ details, see the
 ## Updating versions {#updating-versions}
 
 * For more information on updating your Bazel version, see
-  [Updating Bazel](/versions/updating-bazel).
+  [Updating Bazel](/versions/6.5.0/versions/updating-bazel).
 * For more information on contributing updates to new Bazel releases, see
-  [Contributing to Bazel](/contribute).
+  [Contributing to Bazel](/versions/6.5.0/contribute).
diff --git a/versions/6.5.0/remote/bep-examples.mdx b/versions/6.5.0/remote/bep-examples.mdx
index 46f896e9..8da141fb 100644
--- a/versions/6.5.0/remote/bep-examples.mdx
+++ b/versions/6.5.0/remote/bep-examples.mdx
@@ -28,7 +28,7 @@ build events will resemble the graph below. The arrows indicate the
 aforementioned parent and child relationship. Note that some build events and
 most fields have been omitted for brevity.
 
-![bep-graph](/docs/images/bep-graph.png "BEP graph")
+![bep-graph](/versions/6.5.0/docs/images/bep-graph.png "BEP graph")
 
 **Figure 1.** BEP graph.
 
@@ -102,7 +102,7 @@ built.
 ## Aspect Results in BEP {#aspect-results}
 
 Ordinary builds evaluate actions associated with `(target, configuration)`
-pairs. When building with [aspects](/rules/aspects) enabled, Bazel
+pairs. When building with [aspects](/versions/6.5.0/rules/aspects) enabled, Bazel
 additionally evaluates targets associated with `(target, configuration,
 aspect)` triples, for each target affected by a given enabled aspect.
 
@@ -146,14 +146,14 @@ files by target may conflate target outputs with aspect outputs.
 Determining the artifacts produced by a given target (or aspect) is a common
 BEP use-case that can be done efficiently with some preparation. This section
 discusses the recursive, shared structure offered by the `NamedSetOfFiles`
-event, which matches the structure of a Starlark [Depset](/rules/depsets).
+event, which matches the structure of a Starlark [Depset](/versions/6.5.0/rules/depsets).
 
 Consumers must take care to avoid quadratic algorithms when processing
 `NamedSetOfFiles` events because large builds can contain tens of thousands of
 such events, requiring hundreds of millions operations in a traversal with
 quadratic complexity.
 
-![namedsetoffiles-bep-graph](/docs/images/namedsetoffiles-bep-graph.png "NamedSetOfFiles BEP graph")
+![namedsetoffiles-bep-graph](/versions/6.5.0/docs/images/namedsetoffiles-bep-graph.png "NamedSetOfFiles BEP graph")
 
 **Figure 2.** `NamedSetOfFiles` BEP graph.
 
diff --git a/versions/6.5.0/remote/bep-glossary.mdx b/versions/6.5.0/remote/bep-glossary.mdx
index caf317aa..9fe9ee9e 100644
--- a/versions/6.5.0/remote/bep-glossary.mdx
+++ b/versions/6.5.0/remote/bep-glossary.mdx
@@ -38,7 +38,7 @@ BEP contains an event like the following:
 ## ActionExecuted {#actionexecuted}
 
 Provides details about the execution of a specific
-[Action](/rules/lib/actions) in a build. By default, this event is
+[Action](/versions/6.5.0/rules/lib/builtins/actions) in a build. By default, this event is
 included in the BEP only for failed actions, to support identifying the root cause
 of build failures. Users may set the `--build_event_publish_all_actions` flag
 to include all `ActionExecuted` events.
@@ -147,7 +147,7 @@ indicates which representation it conveys; three such events appear in the BEP:
 
 ## Configuration {#configuration}
 
-A `Configuration` event is sent for every [`configuration`](/rules/config)
+A `Configuration` event is sent for every [`configuration`](/versions/6.5.0/rules/config)
 used in the top-level targets in a build. At least one configuration event is
 always be present. The `id` is reused by the `TargetConfigured` and
 `TargetComplete` event IDs and is necessary to disambiguate those events in
@@ -218,17 +218,17 @@ appear in the BEP stream.
 ## NamedSetOfFiles {#namedsetoffiles}
 
 `NamedSetOfFiles` events report a structure matching a
-[`depset`](/rules/depsets) of files produced during command evaluation.
+[`depset`](/versions/6.5.0/rules/depsets) of files produced during command evaluation.
 Transitively included depsets are identified by `NamedSetOfFilesId`.
 
 For more information on interpreting a stream's `NamedSetOfFiles` events, see the
-[BEP examples page](/docs/bep-examples#consuming-namedsetoffiles).
+[BEP examples page](/versions/6.5.0/docs/bep-examples#consuming-namedsetoffiles).
 
 ## OptionsParsed {#optionsparsed}
 
 A single `OptionsParsed` event lists all options applied to the command,
 separating startup options from command options. It also includes the
-[InvocationPolicy](/reference/command-line-reference#flag--invocation_policy), if any.
+[InvocationPolicy](/versions/6.5.0/reference/command-line-reference#flag--invocation_policy), if any.
 
 ```json
 {
@@ -400,7 +400,7 @@ differentiate `FLAKY` tests from `FAILED` tests.
 
 Unlike [CommandLine](#commandline), this event carries the unparsed commandline
 flags in string form as encountered by the build tool after expanding all
-[`.bazelrc`](/docs/bazelrc) files and
+[`.bazelrc`](/versions/6.5.0/docs/bazelrc) files and
 considering the `--config` flag.
 
 The `UnstructuredCommandLine` event may be relied upon to precisely reproduce a
@@ -413,5 +413,4 @@ workspace, such as the execution root.
 
 ## WorkspaceStatus {#workspacestatus}
 
-A single `WorkspaceStatus` event contains the result of the [workspace status
-command](/docs/user-manual#workspace-status).
+A single `WorkspaceStatus` event contains the result of the [workspace status command](/versions/6.5.0/docs/user-manual#workspace-status).
diff --git a/versions/6.5.0/remote/bep.mdx b/versions/6.5.0/remote/bep.mdx
index 1910375b..4fe7698d 100644
--- a/versions/6.5.0/remote/bep.mdx
+++ b/versions/6.5.0/remote/bep.mdx
@@ -4,14 +4,12 @@ title: 'Build Event Protocol'
 
 
 
-The [Build Event
-Protocol](https://github.com/bazelbuild/bazel/blob/master/src/main/java/com/google/devtools/build/lib/buildeventstream/proto/build_event_stream.proto)
+The [Build Event Protocol](https://github.com/bazelbuild/bazel/blob/master/src/main/java/com/google/devtools/build/lib/buildeventstream/proto/build_event_stream.proto)
 (BEP) allows third-party programs to gain insight into a Bazel invocation. For
 example, you could use the BEP to gather information for an IDE
 plugin or a dashboard that displays build results.
 
-The protocol is a set of [protocol
-buffer](https://developers.google.com/protocol-buffers/) messages with some
+The protocol is a set of [protocol buffer](https://developers.google.com/protocol-buffers/) messages with some
 semantics defined on top of it. It includes information about build and test
 results, build progress, the build configuration and much more. The BEP is
 intended to be consumed programmatically and makes parsing Bazel’s
@@ -22,16 +20,13 @@ build event is a protocol buffer message consisting of a build event identifier,
 a set of child event identifiers, and a payload.
 
 *  __Build Event Identifier:__ Depending on the kind of build event, it might be
-an [opaque
-string](https://github.com/bazelbuild/bazel/blob/16a107d/src/main/java/com/google/devtools/build/lib/buildeventstream/proto/build_event_stream.proto#L91)
-or [structured
-information](https://github.com/bazelbuild/bazel/blob/16a107d/src/main/java/com/google/devtools/build/lib/buildeventstream/proto/build_event_stream.proto#L123)
+an [opaque string](https://github.com/bazelbuild/bazel/blob/16a107d/src/main/java/com/google/devtools/build/lib/buildeventstream/proto/build_event_stream.proto#L91)
+or [structured information](https://github.com/bazelbuild/bazel/blob/16a107d/src/main/java/com/google/devtools/build/lib/buildeventstream/proto/build_event_stream.proto#L123)
 revealing more about the build event. A build event identifier is unique within
 a build.
 
 *  __Children:__ A build event may announce other build events, by including
-their build event identifiers in its [children
-field](https://github.com/bazelbuild/bazel/blob/16a107d/src/main/java/com/google/devtools/build/lib/buildeventstream/proto/build_event_stream.proto#L469).
+their build event identifiers in its [children field](https://github.com/bazelbuild/bazel/blob/16a107d/src/main/java/com/google/devtools/build/lib/buildeventstream/proto/build_event_stream.proto#L469).
 For example, the `PatternExpanded` build event announces the targets it expands
 to as children. The protocol guarantees that all events, except for the first
 event, are announced by a previous event.
@@ -53,14 +48,14 @@ network transport, some announced build events may never be posted.
 The event graph's structure reflects the lifecycle of a command. Every BEP
 graph has the following characteristic shape:
 
-1. The root event is always a [`BuildStarted`](/docs/bep-glossary#buildstarted)
+1. The root event is always a [`BuildStarted`](/versions/6.5.0/docs/bep-glossary#buildstarted)
    event. All other events are its descendants.
 1. Immediate children of the BuildStarted event contain metadata about the
    command.
 1. Events containing data produced by the command, such as files built and test
-   results, appear before the [`BuildFinished`](/docs/bep-glossary#buildfinished)
+   results, appear before the [`BuildFinished`](/versions/6.5.0/docs/bep-glossary#buildfinished)
    event.
-1. The [`BuildFinished`](/docs/bep-glossary#buildfinished) event *may* be followed
+1. The [`BuildFinished`](/versions/6.5.0/docs/bep-glossary#buildfinished) event *may* be followed
    by events containing summary information about the build (for example, metric
    or profiling data).
 
@@ -93,8 +88,7 @@ human-readable formats, such as text and JSON:
 
 ## Build Event Service {#build-event-service}
 
-The [Build Event
-Service](https://github.com/googleapis/googleapis/blob/master/google/devtools/build/v1/publish_build_event.proto)
+The [Build Event Service](https://github.com/googleapis/googleapis/blob/master/google/devtools/build/v1/publish_build_event.proto)
 Protocol is a generic [gRPC](https://www.grpc.io) service for publishing build events. The Build Event
 Service protocol is independent of the BEP and treats BEP events as opaque bytes.
 Bazel ships with a gRPC client implementation of the Build Event Service protocol that
@@ -115,7 +109,7 @@ Bazel has several flags related to the Build Event Service protocol, including:
 *  `--project_id`
 
 For a description of each of these flags, see the
-[Command-Line Reference](/reference/command-line-reference).
+[Command-Line Reference](/versions/6.5.0/reference/command-line-reference).
 
 ### Authentication and security {#authentication-security}
 
@@ -132,15 +126,14 @@ authentication and TLS infrastructure.
 *  `--[no]tls_enabled`
 
 For a description of each of these flags, see the
-[Command-Line Reference](/reference/command-line-reference).
+[Command-Line Reference](/versions/6.5.0/reference/command-line-reference).
 
 ### Build Event Service and remote caching {#bes-remote-caching}
 
 The BEP typically contains many references to log files (test.log, test.xml,
 etc. ) stored on the machine where Bazel is running. A remote BES server
 typically can't access these files as they are on different machines. A way to
-work around this issue is to use Bazel with [remote
-caching](/docs/remote-caching).
+work around this issue is to use Bazel with [remote caching](/versions/6.5.0/docs/remote-caching).
 Bazel will upload all output files to the remote cache (including files
 referenced in the BEP) and the BES server can then fetch the referenced files
 from the cache.
diff --git a/versions/6.5.0/remote/cache-local.mdx b/versions/6.5.0/remote/cache-local.mdx
index ad576923..9279d7ce 100644
--- a/versions/6.5.0/remote/cache-local.mdx
+++ b/versions/6.5.0/remote/cache-local.mdx
@@ -12,15 +12,14 @@ that the remote cache is being effectively utilized.
 
 For tips on how to check your cache hit rate and how to compare the execution
 logs between two Bazel invocations, see
-[Debugging Remote Cache Hits for Remote Execution](/docs/remote-execution-caching-debug).
+[Debugging Remote Cache Hits for Remote Execution](/versions/6.5.0/docs/remote-execution-caching-debug).
 Everything presented in that guide also applies to remote caching with local
 execution. However, local execution presents some additional challenges.
 
 ## Checking your cache hit rate {#cache-hits}
 
 Successful remote cache hits will show up in the status line, similar to
-[Cache Hits rate with Remote
-Execution](/docs/remote-execution-caching-debug#check-cache-hits).
+[Cache Hits rate with Remote Execution](/versions/6.5.0/docs/remote-execution-caching-debug#check-cache-hits).
 
 In the standard output of your Bazel run, you will see something like the
 following:
@@ -69,8 +68,7 @@ the steps in this section.
    message you see does not give you enough information, try adding
    `--verbose_failures`.
 
-2. Follow the steps from [Troubleshooting cache hits for remote
-   execution](/docs/remote-execution-caching-debug#troubleshooting_cache_hits) to
+2. Follow the steps from [Troubleshooting cache hits for remote execution](/versions/6.5.0/docs/remote-execution-caching-debug#troubleshooting_cache_hits) to
    ensure that your cache-writing Bazel invocations are able to get cache hits
    on the same machine and across machines.
 
@@ -84,7 +82,6 @@ the steps in this section.
    b. Ensure your cache-reading Bazel invocations build the same targets as the
       cache-writing Bazel invocations.
 
-   c. Follow the same steps as to [ensure caching across
-      machines](/docs/remote-execution-caching-debug#caching-across-machines),
+   c. Follow the same steps as to [ensure caching across machines](/versions/6.5.0/docs/remote-execution-caching-debug#caching-across-machines),
       to ensure caching from your cache-writing Bazel invocation to your
       cache-reading Bazel invocation.
diff --git a/versions/6.5.0/remote/cache-remote.mdx b/versions/6.5.0/remote/cache-remote.mdx
index 3a2819d3..37d31170 100644
--- a/versions/6.5.0/remote/cache-remote.mdx
+++ b/versions/6.5.0/remote/cache-remote.mdx
@@ -95,7 +95,7 @@ If you are not getting the cache hit rate you are expecting, do the following:
 
    If figuring out the actual command line is difficult, use the canonical
    command line from the
-   [Build Event Protocol](/remote/bep)
+   [Build Event Protocol](/versions/6.5.0/remote/bep)
    as follows:
 
    a. Add `--build_event_text_file=/tmp/bep.txt` to your Bazel command to get
@@ -109,7 +109,7 @@ If you are not getting the cache hit rate you are expecting, do the following:
 
    d. If `remote_accept_cached` is `false`, determine where it is being
       set to `false`: either at the command line or in a
-      [bazelrc](/docs/bazelrc#bazelrc-file-locations) file.
+      [bazelrc](/versions/6.5.0/docs/bazelrc#bazelrc-file-locations) file.
 
 ### Ensure caching across machines {#caching-across-machines}
 
diff --git a/versions/6.5.0/remote/caching.mdx b/versions/6.5.0/remote/caching.mdx
index 64611b18..969b8adb 100644
--- a/versions/6.5.0/remote/caching.mdx
+++ b/versions/6.5.0/remote/caching.mdx
@@ -35,7 +35,7 @@ The remote cache stores two types of data:
 
 Note that the remote cache additionally stores the stdout and stderr for every
 action. Inspecting the stdout/stderr of Bazel thus is not a good signal for
-[estimating cache hits](/docs/remote-caching-debug).
+[estimating cache hits](/versions/6.5.0/docs/remote-caching-debug).
 
 ### How a build uses remote caching {#remote-caching}
 
@@ -128,7 +128,7 @@ not provide technical support for bazel-remote.
 
 This cache stores contents on disk and also provides garbage collection
 to enforce an upper storage limit and clean unused artifacts. The cache is
-available as a [docker image] and its code is available on
+available as a [docker image](https://hub.docker.com/r/buchgr/bazel-remote-cache/) and its code is available on
 [GitHub](https://github.com/buchgr/bazel-remote/).
 Both the REST and gRPC remote cache APIs are supported.
 
@@ -346,8 +346,8 @@ and Bazel must rebuild it before using the remote cache.
 * **Faster Bazel builds with remote caching: a benchmark:** Nicolò Valigi wrote a [blog post](https://nicolovaligi.com/faster-bazel-remote-caching-benchmark.html)
 in which he benchmarks remote caching in Bazel.
 
-* [Adapting Rules for Remote Execution](/docs/remote-execution-rules)
-* [Troubleshooting Remote Execution](/docs/remote-execution-sandbox)
+* [Adapting Rules for Remote Execution](/versions/6.5.0/docs/remote-execution-rules)
+* [Troubleshooting Remote Execution](/versions/6.5.0/docs/remote-execution-sandbox)
 * [WebDAV module](https://nginx.org/en/docs/http/ngx_http_dav_module.html)
 * [Docker image](https://hub.docker.com/r/buchgr/bazel-remote-cache/)
 * [bazel-remote](https://github.com/buchgr/bazel-remote/)
diff --git a/versions/6.5.0/remote/creating.mdx b/versions/6.5.0/remote/creating.mdx
index 02fab90c..a550bb05 100644
--- a/versions/6.5.0/remote/creating.mdx
+++ b/versions/6.5.0/remote/creating.mdx
@@ -3,7 +3,7 @@ title: 'Creating Persistent Workers'
 ---
 
 
-[Persistent workers](/docs/persistent-workers) can make your build faster. If
+[Persistent workers](/versions/6.5.0/docs/persistent-workers) can make your build faster. If
 you have repeated actions in your build that have a high startup cost or would
 benefit from cross-action caching, you may want to implement your own persistent
 worker to perform these actions.
@@ -63,7 +63,7 @@ Bazel sets the `verbosity` field to 10, but smaller or larger values can be used
 manually for different amounts of output.
 
 The optional `sandbox_dir` field is used only by workers that support
-[multiplex sandboxing](/docs/multiplex-worker).
+[multiplex sandboxing](/versions/6.5.0/docs/multiplex-worker).
 
 ### Work responses {#work-responses}
 
@@ -235,7 +235,7 @@ ctx.actions.run(
 ```
 
 For another example, see
-[Implementing persistent workers](/docs/persistent-workers#implementation).
+[Implementing persistent workers](/versions/6.5.0/docs/persistent-workers#implementation).
 
 ## Examples {#examples}
 
diff --git a/versions/6.5.0/remote/multiplex.mdx b/versions/6.5.0/remote/multiplex.mdx
index fdd0c365..fcc27795 100644
--- a/versions/6.5.0/remote/multiplex.mdx
+++ b/versions/6.5.0/remote/multiplex.mdx
@@ -75,7 +75,7 @@ globally by passing `--noexperimental_worker_multiplex`.
 
 A ruleset is encouraged to use multiplex workers if possible,  to reduce memory
 pressure and improve performance. However, multiplex workers are not currently
-compatible with [dynamic execution](/docs/dynamic-execution) unless they
+compatible with [dynamic execution](/versions/6.5.0/docs/dynamic-execution) unless they
 implement multiplex sandboxing. Attempting to run non-sandboxed multiplex
 workers with dynamic execution will silently use sandboxed
 singleplex workers instead.
diff --git a/versions/6.5.0/remote/persistent.mdx b/versions/6.5.0/remote/persistent.mdx
index 72dd3bea..243c752d 100644
--- a/versions/6.5.0/remote/persistent.mdx
+++ b/versions/6.5.0/remote/persistent.mdx
@@ -18,7 +18,7 @@ tool, as well as shutting down workers on exit. Each worker instance is assigned
 `/bazel-workers`.
 
 Using persistent workers is an
-[execution strategy](/docs/user-manual#execution-strategy) that decreases
+[execution strategy](/versions/6.5.0/docs/user-manual#execution-strategy) that decreases
 start-up overhead, allows more JIT compilation, and enables caching of for
 example the abstract syntax trees in the action execution. This strategy
 achieves these improvements by sending multiple requests to a long-running
@@ -39,7 +39,7 @@ uses persistent workers by default when executing builds, though remote
 execution takes precedence. For actions that do not support persistent workers,
 Bazel falls back to starting a tool instance for each action. You can explicitly
 set your build to use persistent workers by setting the `worker`
-[strategy](/docs/user-manual#execution-strategy) for the applicable tool
+[strategy](/versions/6.5.0/docs/user-manual#execution-strategy) for the applicable tool
 mnemonics. As a best practice, this example includes specifying `local` as a
 fallback to the `worker` strategy:
 
@@ -58,7 +58,7 @@ environment, you can use the experimental
 [*dynamic* strategy](https://blog.bazel.build/2019/02/01/dynamic-spawn-scheduler.html),
 which races a remote execution and a worker execution. To enable the dynamic
 strategy, pass the
-[--experimental_spawn_scheduler](/reference/command-line-reference#flag--experimental_spawn_scheduler)
+[--experimental_spawn_scheduler](/versions/6.5.0/reference/command-line-reference#flag--experimental_spawn_scheduler)
 flag. This strategy automatically enables workers, so there is no need to
 specify the `worker` strategy, but you can still use `local` or `sandboxed` as
 fallbacks.
@@ -67,7 +67,7 @@ fallbacks.
 
 The default number of worker instances per mnemonic is 4, but can be adjusted
 with the
-[`worker_max_instances`](/reference/command-line-reference#flag--worker_max_instances)
+[`worker_max_instances`](/versions/6.5.0/reference/command-line-reference#flag--worker_max_instances)
 flag. There is a trade-off between making good use of the available CPUs and the
 amount of JIT compilation and cache hits you get. With more workers, more
 targets will pay start-up costs of running non-JITted code and hitting cold
@@ -84,7 +84,7 @@ This graph shows the from-scratch compilation times for Bazel (target
 with 64 GB of RAM. For each worker configuration, five clean builds are run and
 the average of the last four are taken.
 
-![Graph of performance improvements of clean builds](/docs/images/workers-clean-chart.png "Performance improvements of clean builds")
+![Graph of performance improvements of clean builds](/versions/6.5.0/docs/images/workers-clean-chart.png "Performance improvements of clean builds")
 
 **Figure 1.** Graph of performance improvements of clean builds.
 
@@ -104,7 +104,7 @@ after changing an internal string constant in
 gives a 3x speed-up (average of 20 incremental builds with one warmup build
 discarded):
 
-![Graph of performance improvements of incremental builds](/docs/images/workers-incremental-chart.png "Performance improvements of incremental builds")
+![Graph of performance improvements of incremental builds](/versions/6.5.0/docs/images/workers-incremental-chart.png "Performance improvements of incremental builds")
 
 **Figure 2.** Graph of performance improvements of incremental builds.
 
@@ -114,7 +114,7 @@ measured in the above situation when a commonly used constant is changed.
 ## Modifying persistent workers {#options}
 
 You can pass the
-[`--worker_extra_flag`](/reference/command-line-reference#flag--worker_extra_flag)
+[`--worker_extra_flag`](/versions/6.5.0/reference/command-line-reference#flag--worker_extra_flag)
 flag to specify start-up flags to workers, keyed by mnemonic. For instance,
 passing `--worker_extra_flag=javac=--debug` turns on debugging for Javac only.
 Only one worker flag can be set per use of this flag, and only for one mnemonic.
@@ -125,23 +125,23 @@ flags is combined into a `WorkerKey`, and for each `WorkerKey` up to
 action configuration can also specify set-up flags.
 
 You can use the
-[`--high_priority_workers`](/reference/command-line-reference#flag--high_priority_workers)
+[`--high_priority_workers`](/versions/6.5.0/reference/command-line-reference#flag--high_priority_workers)
 flag to specify a mnemonic that should be run in preference to normal-priority
 mnemonics. This can help prioritize actions that are always in the critical
 path. If there are two or more high priority workers executing requests, all
 other workers are prevented from running. This flag can be used multiple times.
 
 Passing the
-[`--worker_sandboxing`](/reference/command-line-reference#flag--worker_sandboxing)
+[`--worker_sandboxing`](/versions/6.5.0/reference/command-line-reference#flag--worker_sandboxing)
 flag makes each worker request use a separate sandbox directory for all its
-inputs. Setting up the [sandbox](/docs/sandboxing) takes some extra time,
+inputs. Setting up the [sandbox](/versions/6.5.0/docs/sandboxing) takes some extra time,
 especially on macOS, but gives a better correctness guarantee.
 
 The
-[`--worker_quit_after_build`](/reference/command-line-reference#flag--worker_quit_after_build)
+[`--worker_quit_after_build`](/versions/6.5.0/reference/command-line-reference#flag--worker_quit_after_build)
 flag is mainly useful for debugging and profiling. This flag forces all workers
 to quit once a build is done. You can also pass
-[`--worker_verbose`](/reference/command-line-reference#flag--worker_verbose) to
+[`--worker_verbose`](/versions/6.5.0/reference/command-line-reference#flag--worker_verbose) to
 get more output about what the workers are doing. This flag is reflected in the
 `verbosity` field in `WorkRequest`, allowing worker implementations to also be
 more verbose.
@@ -154,11 +154,11 @@ than one `WorkerKey` per mnemonic, you may see more than `worker_max_instances`
 log files for a given mnemonic.
 
 For Android builds, see details at the
-[Android Build Performance page](/docs/android-build-performance).
+[Android Build Performance page](/versions/6.5.0/docs/android-build-performance).
 
 ## Implementing persistent workers {#implementation}
 
-See the [creating persistent workers](/docs/creating-workers) page for more
+See the [creating persistent workers](/versions/6.5.0/docs/creating-workers) page for more
 information on how to make a worker.
 
 This example shows a Starlark configuration for a worker that uses JSON:
@@ -222,7 +222,7 @@ be spawned for each value used. This can lead to excessive memory consumption if
 too many variations are used.
 
 Each worker can currently only process one request at a time. The experimental
-[multiplex workers](/docs/multiplex-worker) feature allows using multiple
+[multiplex workers](/versions/6.5.0/docs/multiplex-worker) feature allows using multiple
 threads, if the underlying tool is multithreaded and the wrapper is set up to
 understand this.
 
@@ -238,7 +238,7 @@ might be helpful.
 ## How do workers affect sandboxing? {#sandboxing}
 
 Using the `worker` strategy by default does not run the action in a
-[sandbox](/docs/sandboxing), similar to the `local` strategy. You can set the
+[sandbox](/versions/6.5.0/docs/sandboxing), similar to the `local` strategy. You can set the
 `--worker_sandboxing` flag to run all workers inside sandboxes, making sure each
 execution of the tool only sees the input files it's supposed to have. The tool
 may still leak information between requests internally, for instance through a
@@ -265,7 +265,6 @@ For more information on persistent workers, see:
 *   [Original persistent workers blog post](https://blog.bazel.build/2015/12/10/java-workers.html)
 *   [Haskell implementation description](https://www.tweag.io/blog/2019-09-25-bazel-ghc-persistent-worker-internship/)
 *   [Blog post by Mike Morearty](https://medium.com/@mmorearty/how-to-create-a-persistent-worker-for-bazel-7738bba2cabb)
-*   [Front End Development with Bazel: Angular/TypeScript and Persistent Workers
-    w/ Asana](https://www.youtube.com/watch?v=0pgERydGyqo)
+*   [Front End Development with Bazel: Angular/TypeScript and Persistent Workers w/ Asana](https://www.youtube.com/watch?v=0pgERydGyqo)
 *   [Bazel strategies explained](https://jmmv.dev/2019/12/bazel-strategies.html)
 *   [Informative worker strategy discussion on the bazel-discuss mailing list](https://groups.google.com/forum/#!msg/bazel-discuss/oAEnuhYOPm8/ol7hf4KWJgAJ)
diff --git a/versions/6.5.0/remote/rbe.mdx b/versions/6.5.0/remote/rbe.mdx
index d57ba2d7..5486d22c 100644
--- a/versions/6.5.0/remote/rbe.mdx
+++ b/versions/6.5.0/remote/rbe.mdx
@@ -29,4 +29,4 @@ self-service tools, see
 
 Remote execution of Bazel builds imposes a set of mandatory configuration
 constraints on the build. For more information, see
-[Adapting Bazel Rules for Remote Execution](/docs/remote-execution-rules).
+[Adapting Bazel Rules for Remote Execution](/versions/6.5.0/docs/remote-execution-rules).
diff --git a/versions/6.5.0/remote/rules.mdx b/versions/6.5.0/remote/rules.mdx
index 43460f8d..b1d68d97 100644
--- a/versions/6.5.0/remote/rules.mdx
+++ b/versions/6.5.0/remote/rules.mdx
@@ -55,14 +55,13 @@ variables that may not be set to equivalent values (or at all) in the remote
 execution environment.
 
 Toolchain rules currently exist for Bazel build and test rules for
-[Scala](https://github.com/bazelbuild/rules_scala/blob/master/scala/scala_toolch
-ain.bzl),
+[Scala](https://github.com/bazelbuild/rules_scala/blob/master/scala/scala_toolch ain.bzl),
 [Rust](https://github.com/bazelbuild/rules_rust/blob/main/rust/toolchain.bzl),
 and [Go](https://github.com/bazelbuild/rules_go/blob/master/go/toolchains.rst),
 and new toolchain rules are under way for other languages and tools such as
 [bash](https://docs.google.com/document/d/e/2PACX-1vRCSB_n3vctL6bKiPkIa_RN_ybzoAccSe0ic8mxdFNZGNBJ3QGhcKjsL7YKf-ngVyjRZwCmhi_5KhcX/pub).
 If a toolchain rule does not exist for the tool your rule uses, consider
-[creating a toolchain rule](/docs/toolchains#creating-a-toolchain-rule).
+[creating a toolchain rule](/versions/6.5.0/docs/toolchains#creating-a-toolchain-rule).
 
 ## Managing implicit dependencies {#manage-dependencies}
 
@@ -85,7 +84,7 @@ _foo_ will be lost and the build will fail.
 To help detect and eliminate these dependency problems, Bazel 0.14.1 offers the
 local Docker sandbox, which has the same restrictions for dependencies as remote
 execution. Use the sandbox to prepare your build for remote execution by
-identifying and resolving dependency-related build errors. See [Troubleshooting Bazel Remote Execution with Docker Sandbox](/docs/remote-execution-sandbox)
+identifying and resolving dependency-related build errors. See [Troubleshooting Bazel Remote Execution with Docker Sandbox](/versions/6.5.0/docs/remote-execution-sandbox)
 for more information.
 
 ## Managing platform-dependent binaries {#manage-binaries}
@@ -134,14 +133,14 @@ remote execution:
     build to fail on the remote execution platform as Bazel will not be able to
     locate them. Instead, create symlinks using standard build actions so that
     the symlinked tools and libraries are accessible from Bazel's `runfiles`
-    tree. Do not use [`repository_ctx.symlink`](/rules/lib/repository_ctx#symlink)
+    tree. Do not use [`repository_ctx.symlink`](/versions/6.5.0/rules/lib/builtins/repository_ctx#symlink)
     to symlink target files outside of the external repo directory.
 
 *   **Mutating the host platform.** Avoid creating files outside of the Bazel
     `runfiles` tree, creating environment variables, and similar actions, as
      they may behave unexpectedly on the remote execution platform.
 
-To help find potential non-hermetic behavior you can use [Workspace rules log](/docs/workspace-log).
+To help find potential non-hermetic behavior you can use [Workspace rules log](/versions/6.5.0/docs/workspace-log).
 
 If an external dependency executes specific operations dependent on the host
 platform, you should split those operations between `WORKSPACE` and build
diff --git a/versions/6.5.0/remote/sandbox.mdx b/versions/6.5.0/remote/sandbox.mdx
index e4c6ca27..3533099a 100644
--- a/versions/6.5.0/remote/sandbox.mdx
+++ b/versions/6.5.0/remote/sandbox.mdx
@@ -5,7 +5,7 @@ title: 'Troubleshooting Bazel Remote Execution with Docker Sandbox'
 
 Bazel builds that succeed locally may fail when executed remotely due to
 restrictions and requirements that do not affect local builds. The most common
-causes of such failures are described in [Adapting Bazel Rules for Remote Execution](/docs/remote-execution-rules).
+causes of such failures are described in [Adapting Bazel Rules for Remote Execution](/versions/6.5.0/docs/remote-execution-rules).
 
 This page describes how to identify and resolve the most common issues that
 arise with remote execution using the Docker sandbox feature, which imposes
@@ -95,7 +95,7 @@ machine and is a reliable way to confirm whether your build will succeed when
 executed remotely.
 
 However, with this method, locally installed tools, binaries, and data may leak
-into into your build, especially if it uses [configure-style WORKSPACE rules](/docs/remote-execution-rules#manage-workspace-rules).
+into into your build, especially if it uses [configure-style WORKSPACE rules](/versions/6.5.0/docs/remote-execution-rules#manage-workspace-rules).
 Such leaks will cause problems with remote execution; to detect them, [troubleshoot in a Docker container](#troubleshooting-docker-container)
 in addition to troubleshooting natively.
 
@@ -129,26 +129,26 @@ The following are the most commonly encountered issues and their workarounds.
 
 *  **A file, tool, binary, or resource referenced by the Bazel runfiles tree is
    missing.**. Confirm that all dependencies of the affected targets have been
-   [explicitly declared](/concepts/dependencies). See
-   [Managing implicit dependencies](/docs/remote-execution-rules#manage-dependencies)
+   [explicitly declared](/versions/6.5.0/concepts/dependencies). See
+   [Managing implicit dependencies](/versions/6.5.0/docs/remote-execution-rules#manage-dependencies)
    for more information.
 
 *  **A file, tool, binary, or resource referenced by an absolute path or the `PATH`
    variable is missing.** Confirm that all required tools are installed within
-   the toolchain container and use [toolchain rules](/docs/toolchains) to properly
+   the toolchain container and use [toolchain rules](/versions/6.5.0/docs/toolchains) to properly
    declare dependencies pointing to the missing resource. See
-   [Invoking build tools through toolchain rules](/docs/remote-execution-rules#invoking-build-tools-through-toolchain-rules)
+   [Invoking build tools through toolchain rules](/versions/6.5.0/docs/remote-execution-rules#invoking-build-tools-through-toolchain-rules)
    for more information.
 
 *  **A binary execution fails.** One of the build rules is referencing a binary
    incompatible with the execution environment (the Docker container). See
-   [Managing platform-dependent binaries](/docs/remote-execution-rules#manage-binaries)
+   [Managing platform-dependent binaries](/versions/6.5.0/docs/remote-execution-rules#manage-binaries)
    for more information. If you cannot resolve the issue, contact [bazel-discuss@google.com](mailto:bazel-discuss@google.com)
    for help.
 
 *  **A file from `@local-jdk` is missing or causing errors.** The Java binaries
    on your local machine are leaking into the build while being incompatible with
-   it. Use [`java_toolchain`](/reference/be/java#java_toolchain)
+   it. Use [`java_toolchain`](/versions/6.5.0/reference/be/java#java_toolchain)
    in your rules and targets instead of `@local_jdk`. Contact [bazel-discuss@google.com](mailto:bazel-discuss@google.com) if you need further help.
 
 *  **Other errors.** Contact [bazel-discuss@google.com](mailto:bazel-discuss@google.com) for help.
@@ -253,7 +253,7 @@ You can resolve build failures as follows:
 
 *   If the build fails during the analysis or loading phases, one or more of
     your build rules declared in the WORKSPACE file are not compatible with
-    remote execution. See [Adapting Bazel Rules for Remote Execution](/docs/remote-execution-rules)
+    remote execution. See [Adapting Bazel Rules for Remote Execution](/versions/6.5.0/docs/remote-execution-rules)
     for possible causes and workarounds.
 
 *   If the build fails for any other reason, see the troubleshooting steps in [Step 2: Resolve detected issues](#start-container).
diff --git a/versions/6.5.0/remote/workspace.mdx b/versions/6.5.0/remote/workspace.mdx
index d0c08f3a..5493574f 100644
--- a/versions/6.5.0/remote/workspace.mdx
+++ b/versions/6.5.0/remote/workspace.mdx
@@ -12,20 +12,19 @@ on the host machine. If your workspace rules access information about the
 host machine for use during execution, your build is likely to break due to
 incompatibilities between the environments.
 
-As part of [adapting Bazel rules for remote
-execution](/docs/remote-execution-rules), you need to find such workspace rules
+As part of [adapting Bazel rules for remote execution](/versions/6.5.0/docs/remote-execution-rules), you need to find such workspace rules
 and fix them. This page describes how to find potentially problematic workspace
 rules using the workspace log.
 
 
 ## Finding non-hermetic rules {#nonhermetic-rules}
 
-[Workspace rules](/reference/be/workspace) allow the developer to add dependencies to
+[Workspace rules](/versions/6.5.0/reference/be/workspace) allow the developer to add dependencies to
 external workspaces, but they are rich enough to allow arbitrary processing to
 happen in the process. All related commands are happening locally and can be a
 potential source of non-hermeticity. Usually non-hermetic behavior is
 introduced through
-[`repository_ctx`](/rules/lib/repository_ctx) which allows interacting
+[`repository_ctx`](/versions/6.5.0/rules/lib/builtins/repository_ctx) which allows interacting
 with the host machine.
 
 Starting with Bazel 0.18, you can get a log of some potentially non-hermetic
@@ -96,7 +95,7 @@ To find what was executed during workspace initialization:
 The log consists of
 [WorkspaceEvent](https://source.bazel.build/bazel/+/master:src/main/java/com/google/devtools/build/lib/bazel/debug/workspace_log.proto?q=WorkspaceEvent)
 messages outlining certain potentially non-hermetic actions performed on a
-[`repository_ctx`](/rules/lib/repository_ctx).
+[`repository_ctx`](/versions/6.5.0/rules/lib/builtins/repository_ctx).
 
 The actions that have been highlighted as potentially non-hermetic are as follows:
 
diff --git a/versions/6.5.0/rules/bzl-style.mdx b/versions/6.5.0/rules/bzl-style.mdx
index a13db854..37cb51e9 100644
--- a/versions/6.5.0/rules/bzl-style.mdx
+++ b/versions/6.5.0/rules/bzl-style.mdx
@@ -6,7 +6,7 @@ title: '.bzl style guide'
 This page covers basic style guidelines for Starlark and also includes
 information on macros and rules.
 
-[Starlark](/rules/language) is a
+[Starlark](/versions/6.5.0/rules/language) is a
 language that defines how software is built, and as such it is both a
 programming and a configuration language.
 
@@ -42,7 +42,7 @@ really apply here.
 
 *   Use [Buildifier](https://github.com/bazelbuild/buildtools/tree/master/buildifier#linter)
     as a formatter and linter.
-*   Follow [testing guidelines](/rules/testing).
+*   Follow [testing guidelines](/versions/6.5.0/rules/testing).
 
 ## Style {#style}
 
@@ -54,7 +54,7 @@ In particular, use four rather than two spaces for indentation to follow the
 Python convention.
 
 Since
-[Starlark is not Python](/rules/language#differences-with-python),
+[Starlark is not Python](/versions/6.5.0/rules/language#differences-with-python),
 some aspects of Python style do not apply. For example, PEP 8 advises that
 comparisons to singletons be done with `is`, which is not an operator in
 Starlark.
@@ -167,7 +167,7 @@ goals.
 
 As a rule of thumb, the more macros resemble the rules, the better.
 
-See also [macros](/rules/macros#conventions).
+See also [macros](/versions/6.5.0/rules/macros#conventions).
 
 ## Rules {#rules}
 
@@ -202,9 +202,9 @@ See also [macros](/rules/macros#conventions).
     (named with a leading underscore). A common style is to give the
     implementation function for `myrule` the name `_myrule_impl`.
 *   Pass information between your rules using a well-defined
-    [provider](/rules/rules#providers) interface. Declare and document provider
+    [provider](/versions/6.5.0/rules/rules#providers) interface. Declare and document provider
     fields.
 *   Design your rule with extensibility in mind. Consider that other rules might
     want to interact with your rule, access your providers, and reuse the
     actions you create.
-*   Follow [performance guidelines](/rules/performance) in your rules.
+*   Follow [performance guidelines](/versions/6.5.0/rules/performance) in your rules.
diff --git a/versions/6.5.0/rules/challenges.mdx b/versions/6.5.0/rules/challenges.mdx
index e925d254..8448a9a6 100644
--- a/versions/6.5.0/rules/challenges.mdx
+++ b/versions/6.5.0/rules/challenges.mdx
@@ -34,7 +34,7 @@ like. In the first approximation, this means Bazel needs to know every single
 input that goes into a given build step, such that it can rerun that step if any
 of the inputs change. There are limits to how correct Bazel can get, as it leaks
 some information such as date / time of the build, and ignores certain types of
-changes such as changes to file attributes. [Sandboxing](/docs/sandboxing)
+changes such as changes to file attributes. [Sandboxing](/versions/6.5.0/docs/sandboxing)
 helps ensure correctness by preventing reads to undeclared input files. Besides
 the intrinsic limits of the system, there are a few known correctness issues,
 most of which are related to Fileset or the C++ rules, which are both hard
@@ -127,7 +127,7 @@ rules, which need to declare all input files ahead of time.
 Above, we argued that in order to be correct, Bazel needs to know all the input
 files that go into a build step in order to detect whether that build step is
 still up-to-date. The same is true for package loading and rule analysis, and we
-have designed [Skyframe](/reference/skyframe) to handle this
+have designed [Skyframe](/versions/6.5.0/reference/skyframe) to handle this
 in general. Skyframe is a graph library and evaluation framework that takes a
 goal node (such as 'build //foo with these options'), and breaks it down into
 its constituent parts, which are then evaluated and combined to yield this
@@ -209,7 +209,7 @@ Bazel is heavily affected by both of these scenarios, so we introduced a set of
 custom collection classes that effectively compress the information in memory by
 avoiding the copy at each step. Almost all of these data structures have set
 semantics, so we called it
-[depset](/rules/lib/depset)
+[depset](/versions/6.5.0/rules/lib/builtins/depset)
 (also known as `NestedSet` in the internal implementation). The majority of
 changes to reduce Bazel's memory consumption over the past several years were
 changes to use depsets instead of whatever was previously used.
diff --git a/versions/6.5.0/rules/deploying.mdx b/versions/6.5.0/rules/deploying.mdx
index d21593ad..a80448eb 100644
--- a/versions/6.5.0/rules/deploying.mdx
+++ b/versions/6.5.0/rules/deploying.mdx
@@ -87,8 +87,7 @@ At the top level, there should be a `README` that contains (at least) what
 users will need to copy-paste into their `WORKSPACE` file to use your rule.
 In general, this will be a `http_archive` pointing to your GitHub release and
 a macro call that downloads/configures any tools your rule needs. For example,
-for the [Go
-rules](https://github.com/bazelbuild/rules_go#setup), this
+for the [Go rules](https://github.com/bazelbuild/rules_go#setup), this
 looks like:
 
 ```
@@ -127,7 +126,7 @@ For `rules_mockascript` that means there will be a directory named
 ### Constraints
 
 If your rule defines
-[toolchain](/docs/toolchains) rules,
+[toolchain](/versions/6.5.0/docs/toolchains) rules,
 it's possible that you'll need to define custom `constraint_setting`s and/or
 `constraint_value`s. Put these into a `///constraints` package. Your
 directory structure will look like this:
@@ -147,7 +146,7 @@ for best practices, and to see what constraints are already present, and
 consider contributing your constraints there if they are language independent.
 Be mindful of introducing custom constraints, all users of your rules will
 use them to perform platform specific logic in their `BUILD` files (for example,
-using [selects](/reference/be/functions#select)).
+using [selects](/versions/6.5.0/reference/be/functions#select)).
 With custom constraints, you define a language that the whole Bazel ecosystem
 will speak.
 
@@ -232,8 +231,7 @@ of basic ways that the rules can be used.
 
 ## Testing
 
-Set up Travis as described in their [getting started
-docs](https://docs.travis-ci.com/user/getting-started/). Then add a
+Set up Travis as described in their [getting started docs](https://docs.travis-ci.com/user/getting-started/). Then add a
 `.travis.yml` file to your repository with the following content:
 
 ```
diff --git a/versions/6.5.0/rules/faq.mdx b/versions/6.5.0/rules/faq.mdx
index 8c8e01b0..a5511a5b 100644
--- a/versions/6.5.0/rules/faq.mdx
+++ b/versions/6.5.0/rules/faq.mdx
@@ -18,9 +18,9 @@ Bazel only executes the actions needed to produce the *requested* output files.
 
 * If you want the file to be built automatically whenever your target is
   mentioned on the command line, add it to your rule's default outputs by
-  returning a [`DefaultInfo`](lib/globals#DefaultInfo) provider.
+  returning a [`DefaultInfo`](/versions/6.5.0/rules/lib/globals#DefaultInfo) provider.
 
-See the [Rules page](/rules/rules#requesting-output-files) for more information.
+See the [Rules page](/versions/6.5.0/rules/rules#requesting-output-files) for more information.
 
 ## Why is my implementation function not executed?
 
@@ -36,24 +36,24 @@ correct path.
 
 For actions, you declare inputs by passing them to the `ctx.actions.*` function
 that creates the action. The proper path for the file can be obtained using
-[`File.path`](lib/File#path).
+[`File.path`](/versions/6.5.0/rules/lib/File#path).
 
 For binaries (the executable outputs run by a `bazel run` or `bazel test`
 command), you declare inputs by including them in the
-[runfiles](/rules/rules#runfiles). Instead of using the `path` field, use
-[`File.short_path`](lib/File#short_path), which is file's path relative to
+[runfiles](/versions/6.5.0/rules/rules#runfiles). Instead of using the `path` field, use
+[`File.short_path`](/versions/6.5.0/rules/lib/File#short_path), which is file's path relative to
 the runfiles directory in which the binary executes.
 
 ## How can I control which files are built by `bazel build //pkg:mytarget`?
 
-Use the [`DefaultInfo`](lib/globals#DefaultInfo) provider to
-[set the default outputs](/rules/rules#requesting-output-files).
+Use the [`DefaultInfo`](/versions/6.5.0/rules/lib/globals#DefaultInfo) provider to
+[set the default outputs](/versions/6.5.0/rules/rules#requesting-output-files).
 
 ## How can I run a program or do file I/O as part of my build?
 
 A tool can be declared as a target, just like any other part of your build, and
 run during the execution phase to help build other targets. To create an action
-that runs a tool, use [`ctx.actions.run`](lib/actions#run) and pass in the
+that runs a tool, use [`ctx.actions.run`](/versions/6.5.0/rules/lib/actions#run) and pass in the
 tool as the `executable` parameter.
 
 During the loading and analysis phases, a tool *cannot* run, nor can you perform
diff --git a/versions/6.5.0/rules/index.mdx b/versions/6.5.0/rules/index.mdx
index 426eca70..21d94315 100644
--- a/versions/6.5.0/rules/index.mdx
+++ b/versions/6.5.0/rules/index.mdx
@@ -5,7 +5,7 @@ title: 'Rules'
 
 The Bazel ecosystem has a growing and evolving set of rules to support popular
 languages and packages. Much of Bazel's strength comes from the ability to
-[define new rules](/rules/concepts) that can be used by others.
+[define new rules](/versions/6.5.0/rules/concepts) that can be used by others.
 
 This page describes the recommended, native, and non-native Bazel rules.
 
@@ -13,22 +13,22 @@ This page describes the recommended, native, and non-native Bazel rules.
 
 Here is a selection of recommended rules:
 
-* [Android](/docs/bazel-and-android)
+* [Android](/versions/6.5.0/docs/bazel-and-android)
 * [Boost](https://github.com/nelhage/rules_boost)
-* [C / C++](/docs/bazel-and-cpp)
+* [C / C++](/versions/6.5.0/docs/bazel-and-cpp)
 * [Docker](https://github.com/bazelbuild/rules_docker)
 * [Go](https://github.com/bazelbuild/rules_go)
 * [Haskell](https://github.com/tweag/rules_haskell)
-* [Java](/docs/bazel-and-java)
+* [Java](/versions/6.5.0/docs/bazel-and-java)
 * [JavaScript / NodeJS](https://github.com/bazelbuild/rules_nodejs)
 * [Kubernetes](https://github.com/bazelbuild/rules_k8s)
 * [Maven dependency management](https://github.com/bazelbuild/rules_jvm_external)
-* [Objective C](/docs/bazel-and-apple)
+* [Objective C](/versions/6.5.0/docs/bazel-and-apple)
 * [Package building](https://github.com/bazelbuild/rules_pkg)
 * [Protocol Buffers](https://github.com/bazelbuild/rules_proto#protobuf-rules-for-bazel)
 * [Python](https://github.com/bazelbuild/rules_python)
 * [Scala](https://github.com/bazelbuild/rules_scala)
-* [Shell](/reference/be/shell)
+* [Shell](/versions/6.5.0/reference/be/shell)
 * [Webtesting](https://github.com/bazelbuild/rules_webtesting) (Webdriver)
 
 The repository [Skylib](https://github.com/bazelbuild/bazel-skylib) contains
@@ -36,7 +36,7 @@ additional functions that can be useful when writing new rules and new
 macros.
 
 The rules above were reviewed and follow our
-[requirements for recommended rules](/contribute/recommended-rules).
+[requirements for recommended rules](/versions/6.5.0/contribute/recommended-rules).
 Contact the respective rule set's maintainers regarding issues and feature
 requests.
 
@@ -50,37 +50,37 @@ Native rules are shipped with the Bazel binary, they are always available in
 BUILD files without a `load` statement.
 
 * Extra actions
-  - [`extra_action`](/reference/be/extra-actions#extra_action)
-  - [`action_listener`](/reference/be/extra-actions#action_listener)
+  - [`extra_action`](/versions/6.5.0/reference/be/extra-actions#extra_action)
+  - [`action_listener`](/versions/6.5.0/reference/be/extra-actions#action_listener)
 * General
-  - [`filegroup`](/reference/be/general#filegroup)
-  - [`genquery`](/reference/be/general#genquery)
-  - [`test_suite`](/reference/be/general#test_suite)
-  - [`alias`](/reference/be/general#alias)
-  - [`config_setting`](/reference/be/general#config_setting)
-  - [`genrule`](/reference/be/general#genrule)
+  - [`filegroup`](/versions/6.5.0/reference/be/general#filegroup)
+  - [`genquery`](/versions/6.5.0/reference/be/general#genquery)
+  - [`test_suite`](/versions/6.5.0/reference/be/general#test_suite)
+  - [`alias`](/versions/6.5.0/reference/be/general#alias)
+  - [`config_setting`](/versions/6.5.0/reference/be/general#config_setting)
+  - [`genrule`](/versions/6.5.0/reference/be/general#genrule)
 * Platform
-  - [`constraint_setting`](/reference/be/platform#constraint_setting)
-  - [`constraint_value`](/reference/be/platform#constraint_value)
-  - [`platform`](/reference/be/platform#platform)
-  - [`toolchain`](/reference/be/platform#toolchain)
-  - [`toolchain_type`](/reference/be/platform#toolchain_type)
+  - [`constraint_setting`](/versions/6.5.0/reference/be/platform#constraint_setting)
+  - [`constraint_value`](/versions/6.5.0/reference/be/platform#constraint_value)
+  - [`platform`](/versions/6.5.0/reference/be/platform#platform)
+  - [`toolchain`](/versions/6.5.0/reference/be/platform#toolchain)
+  - [`toolchain_type`](/versions/6.5.0/reference/be/platform#toolchain_type)
 * Workspace
-  - [`bind`](/reference/be/workspace#bind)
-  - [`local_repository`](/reference/be/workspace#local_repository)
-  - [`new_local_repository`](/reference/be/workspace#new_local_repository)
-  - [`xcode_config`](/reference/be/objective-c#xcode_config)
-  - [`xcode_version`](/reference/be/objective-c#xcode_version)
+  - [`bind`](/versions/6.5.0/reference/be/workspace#bind)
+  - [`local_repository`](/versions/6.5.0/reference/be/workspace#local_repository)
+  - [`new_local_repository`](/versions/6.5.0/reference/be/workspace#new_local_repository)
+  - [`xcode_config`](/versions/6.5.0/reference/be/objective-c#xcode_config)
+  - [`xcode_version`](/versions/6.5.0/reference/be/objective-c#xcode_version)
 
 ## Embedded non-native rules {#embedded-rules}
 
-Bazel also embeds additional rules written in [Starlark](/rules/language). Those can be loaded from
+Bazel also embeds additional rules written in [Starlark](/versions/6.5.0/rules/language). Those can be loaded from
 the `@bazel_tools` built-in external repository.
 
 * Repository rules
-  - [`git_repository`](/rules/lib/repo/git#git_repository)
-  - [`new_git_repository`](/rules/lib/repo/git#new_git_repository)
-  - [`http_archive`](/rules/lib/repo/http#http_archive)
-  - [`http_file`](/rules/lib/repo/http#http_archive)
-  - [`http_jar`](/rules/lib/repo/http#http_jar)
-  - [Utility functions on patching](/rules/lib/repo/utils)
+  - [`git_repository`](/versions/6.5.0/rules/lib/repo/git#git_repository)
+  - [`new_git_repository`](/versions/6.5.0/rules/lib/repo/git#new_git_repository)
+  - [`http_archive`](/versions/6.5.0/rules/lib/repo/http#http_archive)
+  - [`http_file`](/versions/6.5.0/rules/lib/repo/http#http_archive)
+  - [`http_jar`](/versions/6.5.0/rules/lib/repo/http#http_jar)
+  - [Utility functions on patching](/versions/6.5.0/rules/lib/repo/utils)
diff --git a/versions/6.5.0/rules/language.mdx b/versions/6.5.0/rules/language.mdx
index e743b54b..1cb502cc 100644
--- a/versions/6.5.0/rules/language.mdx
+++ b/versions/6.5.0/rules/language.mdx
@@ -34,19 +34,19 @@ Starlark's semantics can differ from Python, but behavioral differences are
 rare, except for cases where Starlark raises an error. The following Python
 types are supported:
 
-* [None](lib/globals#None)
-* [bool](lib/bool)
-* [dict](lib/dict)
-* [tuple](lib/globals#tuple)
+* [None](/versions/6.5.0/rules/lib/globals#None)
+* [bool](/versions/6.5.0/rules/lib/bool)
+* [dict](/versions/6.5.0/rules/lib/dict)
+* [tuple](/versions/6.5.0/rules/lib/globals#tuple)
 * function
-* [int](lib/int)
-* [list](lib/list)
-* [string](lib/string)
+* [int](/versions/6.5.0/rules/lib/int)
+* [list](/versions/6.5.0/rules/lib/list)
+* [string](/versions/6.5.0/rules/lib/string)
 
 ## Mutability
 
 Starlark favors immutability. Two mutable data structures are available:
-[lists](lib/list) and [dicts](lib/dict). Changes to mutable
+[lists](/versions/6.5.0/rules/lib/list) and [dicts](/versions/6.5.0/rules/lib/dict). Changes to mutable
 data-structures, such as appending a value to a list or deleting an entry in a
 dictionary are valid only for objects created in the current context. After a
 context finishes, its values become immutable.
@@ -93,10 +93,8 @@ values returned by rules are immutable.
 `BUILD` files register targets via making calls to rules. `.bzl` files provide
 definitions for constants, rules, macros, and functions.
 
-[Native functions](/versions/6.5.0/reference/be/functions) and [native rules](
-/reference/be/overview#language-specific-native-rules) are global symbols in
-`BUILD` files. `bzl` files need to load them using the [`native` module](
-https://bazel.build/rules/lib/native).
+[Native functions](/versions/6.5.0/reference/be/functions) and [native rules](/versions/6.5.0/reference/be/overview#language-specific-native-rules) are global symbols in
+`BUILD` files. `bzl` files need to load them using the [`native` module](https://bazel.build/versions/6.5.0/rules/lib/native).
 
 There are two syntactic restrictions in `BUILD` files: 1) declaring functions is
 illegal, and 2) `*args` and `**kwargs` arguments are not allowed.
@@ -130,7 +128,7 @@ not defined across value types. In short: `5 < 'foo'` will throw an error and
   error: `{"a": 4, "b": 7, "a": 1}`.
 
 * Strings are represented with double-quotes (such as when you call
-  [repr](lib/globals#repr)).
+  [repr](/versions/6.5.0/rules/lib/globals#repr)).
 
 * Strings aren't iterable.
 
@@ -138,12 +136,12 @@ The following Python features are not supported:
 
 * implicit string concatenation (use explicit `+` operator).
 * Chained comparisons (such as `1 < x < 5`).
-* `class` (see [`struct`](lib/struct#struct) function).
-* `import` (see [`load`](concepts#loading-an-extension) statement).
+* `class` (see [`struct`](/versions/6.5.0/rules/lib/struct#struct) function).
+* `import` (see [`load`](/versions/6.5.0/rules/concepts#loading-an-extension) statement).
 * `while`, `yield`.
 * float and set types.
 * generators and generator expressions.
 * `is` (use `==` instead).
-* `try`, `raise`, `except`, `finally` (see [`fail`](lib/globals#fail) for fatal errors).
+* `try`, `raise`, `except`, `finally` (see [`fail`](/versions/6.5.0/rules/lib/globals#fail) for fatal errors).
 * `global`, `nonlocal`.
 * most builtin functions, most methods.
diff --git a/versions/6.5.0/rules/macro-tutorial.mdx b/versions/6.5.0/rules/macro-tutorial.mdx
index b1a84d69..f70e9bf0 100644
--- a/versions/6.5.0/rules/macro-tutorial.mdx
+++ b/versions/6.5.0/rules/macro-tutorial.mdx
@@ -9,7 +9,7 @@ tutorial, you are going to create a macro that resizes an image.
 
 Macros are suitable for simple tasks. If you want to do anything more
 complicated, for example add support for a new programming language, consider
-creating a [rule](/rules/rules). Rules give you more control and flexibility.
+creating a [rule](/versions/6.5.0/rules/rules). Rules give you more control and flexibility.
 
 The easiest way to create a macro that resizes an image is to use a `genrule`:
 
diff --git a/versions/6.5.0/rules/performance.mdx b/versions/6.5.0/rules/performance.mdx
index b2fb8d54..15ddaf52 100644
--- a/versions/6.5.0/rules/performance.mdx
+++ b/versions/6.5.0/rules/performance.mdx
@@ -16,7 +16,7 @@ widespread use.
 ## Use depsets {#use-depsets}
 
 Whenever you are rolling up information from rule dependencies you should use
-[depsets](lib/depset). Only use plain lists or dicts to publish information
+[depsets](/versions/6.5.0/rules/lib/depset). Only use plain lists or dicts to publish information
 local to the current rule.
 
 A depset represents information as a nested graph which enables sharing.
@@ -69,12 +69,12 @@ def _impl(ctx):
   )]
 ```
 
-See the [depset overview](/rules/depsets) page for more information.
+See the [depset overview](/versions/6.5.0/rules/depsets) page for more information.
 
 ### Avoid calling `depset.to_list()` {#avoid-depset-to-list}
 
 You can coerce a depset to a flat list using
-[`to_list()`](lib/depset#to_list), but doing so usually results in O(N^2)
+[`to_list()`](/versions/6.5.0/rules/lib/depset#to_list), but doing so usually results in O(N^2)
 cost. If at all possible, avoid any flattening of depsets except for debugging
 purposes.
 
@@ -116,7 +116,7 @@ x = depset(transitive = [i.deps for i in inputs])
 
 ## Use ctx.actions.args() for command lines {#ctx-actions-args}
 
-When building command lines you should use [ctx.actions.args()](lib/Args).
+When building command lines you should use [ctx.actions.args()](/versions/6.5.0/rules/lib/Args).
 This defers expansion of any depsets to the execution phase.
 
 Apart from being strictly faster, this will reduce the memory consumption of
@@ -127,11 +127,11 @@ Here are some tricks:
 * Pass depsets and lists directly as arguments, instead of flattening them
 yourself. They will get expanded by `ctx.actions.args()` for you.
 If you need any transformations on the depset contents, look at
-[ctx.actions.args#add](lib/Args#add) to see if anything fits the bill.
+[ctx.actions.args#add](/versions/6.5.0/rules/lib/Args#add) to see if anything fits the bill.
 
 * Are you passing `File#path` as arguments? No need. Any
-[File](lib/File) is automatically turned into its
-[path](lib/File#path), deferred to expansion time.
+[File](/versions/6.5.0/rules/lib/File) is automatically turned into its
+[path](/versions/6.5.0/rules/lib/File#path), deferred to expansion time.
 
 * Avoid constructing strings by concatenating them together.
 The best string argument is a constant as its memory will be shared between
@@ -139,10 +139,10 @@ all instances of your rule.
 
 * If the args are too long for the command line an `ctx.actions.args()` object
 can be conditionally or unconditionally written to a param file using
-[`ctx.actions.args#use_param_file`](lib/Args#use_param_file). This is
+[`ctx.actions.args#use_param_file`](/versions/6.5.0/rules/lib/Args#use_param_file). This is
 done behind the scenes when the action is executed. If you need to explicitly
 control the params file you can write it manually using
-[`ctx.actions.write`](lib/actions#write).
+[`ctx.actions.write`](/versions/6.5.0/rules/lib/actions#write).
 
 Example:
 
@@ -177,7 +177,7 @@ def _to_short_path(f):
 
 ## Transitive action inputs should be depsets {#transitive-action-inputs}
 
-When building an action using [ctx.actions.run](lib/actions?#run), do not
+When building an action using [ctx.actions.run](/versions/6.5.0/rules/lib/actions#run), do not
 forget that the `inputs` field accepts a depset. Use this whenever inputs are
 collected from dependencies transitively.
 
@@ -203,7 +203,7 @@ symlink in your workspace directory.
 
 Bazel writes a JSON profile to `command.profile.gz` in the output base by
 default. You can configure the location with the
-[`--profile`](/docs/user-manual#profile) flag, for example
+[`--profile`](/versions/6.5.0/docs/user-manual#profile) flag, for example
 `--profile=/tmp/profile.gz`. Location ending with `.gz` are compressed with
 GZIP.
 
@@ -228,7 +228,7 @@ You can use these keyboard controls to navigate:
 
 Example profile:
 
-![Example profile](/rules/profile.png "Example profile")
+![Example profile](/versions/6.5.0/rules/profile.png "Example profile")
 
 **Figure 1.** Example profile.
 
diff --git a/versions/6.5.0/rules/rules-tutorial.mdx b/versions/6.5.0/rules/rules-tutorial.mdx
index 702acdb6..946683a1 100644
--- a/versions/6.5.0/rules/rules-tutorial.mdx
+++ b/versions/6.5.0/rules/rules-tutorial.mdx
@@ -14,7 +14,7 @@ of Bazel. Bazel augments the core language with numerous build-related functions
 such as `glob`, `genrule`, `java_binary`, and so on.
 
 See the
-[Bazel](/start/getting-started) and [Starlark](/rules/concepts) documentation for
+[Bazel](/versions/6.5.0/start/getting-started) and [Starlark](/versions/6.5.0/rules/concepts) documentation for
 more details, and the
 [Rules SIG template](https://github.com/bazel-contrib/rules-template) as a
 starting point for new rulesets.
@@ -32,9 +32,9 @@ foo_binary = rule(
 )
 ```
 
-When you call the [`rule`](lib/globals#rule) function, you
+When you call the [`rule`](/versions/6.5.0/rules/lib/globals#rule) function, you
 must define a callback function. The logic will go there, but you
-can leave the function empty for now. The [`ctx`](lib/ctx) argument
+can leave the function empty for now. The [`ctx`](/versions/6.5.0/rules/lib/ctx) argument
 provides information about the target.
 
 You can load the rule and use it from a `BUILD` file.
@@ -87,10 +87,10 @@ foo_binary(name = "bin1")
 foo_binary(name = "bin2")
 ```
 
-[`ctx.label`](lib/ctx#label)
+[`ctx.label`](/versions/6.5.0/rules/lib/ctx#label)
 corresponds to the label of the target being analyzed. The `ctx` object has
 many useful fields and methods; you can find an exhaustive list in the
-[API reference](lib/ctx).
+[API reference](/versions/6.5.0/rules/lib/ctx).
 
 Query the code:
 
@@ -111,7 +111,7 @@ Make a few observations:
 * The callback function `_foo_binary_impl` is not called. Bazel query loads
   `BUILD` files, but doesn't analyze targets.
 
-To analyze the targets, use the [`cquery`](/docs/cquery) ("configured
+To analyze the targets, use the [`cquery`](/versions/6.5.0/docs/cquery) ("configured
 query") or the `build` command:
 
 ```
@@ -149,7 +149,7 @@ bin2
 ```
 
 Whenever you declare a file, you have to tell Bazel how to generate it by
-creating an action. Use [`ctx.actions.write`](lib/actions#write),
+creating an action. Use [`ctx.actions.write`](/versions/6.5.0/rules/lib/actions#write),
 to create a file with the given content.
 
 ```python
@@ -204,7 +204,7 @@ You have successfully generated a file!
 ## Attributes
 
 To make the rule more useful, add new attributes using
-[the `attr` module](lib/attr) and update the rule definition.
+[the `attr` module](/versions/6.5.0/rules/lib/attr) and update the rule definition.
 
 Add a string attribute called `username`:
 
@@ -240,22 +240,22 @@ def _foo_binary_impl(ctx):
 ```
 
 Note that you can make the attribute mandatory or set a default value. Look at
-the documentation of [`attr.string`](lib/attr#string).
-You may also use other types of attributes, such as [boolean](lib/attr#bool)
-or [list of integers](lib/attr#int_list).
+the documentation of [`attr.string`](/versions/6.5.0/rules/lib/attr#string).
+You may also use other types of attributes, such as [boolean](/versions/6.5.0/rules/lib/attr#bool)
+or [list of integers](/versions/6.5.0/rules/lib/attr#int_list).
 
 ## Dependencies
 
-Dependency attributes, such as [`attr.label`](lib/attr#label)
-and [`attr.label_list`](lib/attr#label_list),
+Dependency attributes, such as [`attr.label`](/versions/6.5.0/rules/lib/attr#label)
+and [`attr.label_list`](/versions/6.5.0/rules/lib/attr#label_list),
 declare a dependency from the target that owns the attribute to the target whose
 label appears in the attribute's value. This kind of attribute forms the basis
 of the target graph.
 
 In the `BUILD` file, the target label appears as a string object, such as
 `//pkg:name`. In the implementation function, the target will be accessible as a
-[`Target`](lib/Target) object. For example, view the files returned
-by the target using [`Target.files`](lib/Target#modules.Target.files).
+[`Target`](/versions/6.5.0/rules/lib/Target) object. For example, view the files returned
+by the target using [`Target.files`](/versions/6.5.0/rules/lib/Target#modules.Target.files).
 
 ### Multiple files
 
@@ -298,7 +298,7 @@ implementation function, but this has two problems. First, as the template gets
 bigger, it becomes more memory efficient to put it in a separate file and avoid
 constructing large strings during the analysis phase. Second, using a separate
 file is more convenient for the user. Instead, use
-[`ctx.actions.expand_template`](lib/actions#expand_template),
+[`ctx.actions.expand_template`](/versions/6.5.0/rules/lib/actions#expand_template),
 which performs substitutions on a template file.
 
 Create a `template` attribute to declare a dependency on the template
@@ -355,7 +355,7 @@ Attributes that start with an underscore are private and cannot be set in a
 `BUILD` file. The template is now an _implicit dependency_: Every `hello_world`
 target has a dependency on this file. Don't forget to make this file visible
 to other packages by updating the `BUILD` file and using
-[`exports_files`](/reference/be/functions#exports_files):
+[`exports_files`](/versions/6.5.0/reference/be/functions#exports_files):
 
 ```python
 exports_files(["file.cc.tpl"])
@@ -363,7 +363,7 @@ exports_files(["file.cc.tpl"])
 
 ## Going further
 
-*   Take a look at the [reference documentation for rules](rules#contents).
-*   Get familiar with [depsets](depsets).
+*   Take a look at the [reference documentation for rules](/versions/6.5.0/rules/rules#contents).
+*   Get familiar with [depsets](/versions/6.5.0/rules/depsets).
 *   Check out the [examples repository](https://github.com/bazelbuild/examples/tree/master/rules)
     which includes additional examples of rules.
diff --git a/versions/6.5.0/rules/testing.mdx b/versions/6.5.0/rules/testing.mdx
index 9c683986..4ea2d980 100644
--- a/versions/6.5.0/rules/testing.mdx
+++ b/versions/6.5.0/rules/testing.mdx
@@ -24,7 +24,7 @@ Some caveats:
 
 *   It requires a fair amount of boilerplate to set up the rules under test and
     the rules containing test assertions. This boilerplate may seem daunting at
-    first. It helps to [keep in mind](/rules/concepts#evaluation-model) that macros
+    first. It helps to [keep in mind](/versions/6.5.0/rules/concepts#evaluation-model) that macros
     are evaluated and targets generated during the loading phase, while rule
     implementation functions don't run until later, during the analysis phase.
 
@@ -236,7 +236,7 @@ def _inspect_actions_test_impl(ctx):
 ```
 
 Note that `analysistest.target_actions(env)` returns a list of
-[`Action`](lib/Action) objects which represent actions registered by the
+[`Action`](/versions/6.5.0/rules/lib/Action) objects which represent actions registered by the
 target under test.
 
 ### Verifying rule behavior under different flags {#verifying-rule-behavior}
diff --git a/versions/6.5.0/rules/verbs-tutorial.mdx b/versions/6.5.0/rules/verbs-tutorial.mdx
index 37015d42..7e072c2f 100644
--- a/versions/6.5.0/rules/verbs-tutorial.mdx
+++ b/versions/6.5.0/rules/verbs-tutorial.mdx
@@ -50,8 +50,7 @@ This pattern can also be seen in the Angular project. The
 produces two targets. The first is a standard `nodejs_test` target which compares
 some generated output against a "golden" file (that is, a file containing the
 expected output). This can be built and run with a normal `bazel
-test` invocation. In `angular-cli`, you can run [one such
-target](https://github.com/angular/angular-cli/blob/e1269cb520871ee29b1a4eec6e6c0e4a94f0b5fc/etc/api/BUILD)
+test` invocation. In `angular-cli`, you can run [one such target](https://github.com/angular/angular-cli/blob/e1269cb520871ee29b1a4eec6e6c0e4a94f0b5fc/etc/api/BUILD)
 with `bazel test //etc/api:angular_devkit_core_api`.
 
 Over time, this golden file may need to be updated for legitimate reasons.
@@ -68,7 +67,7 @@ learn to recognize it.
 
 ## Adapting your own rules
 
-[Macros](/rules/macros) are the heart of this pattern. Macros are used like
+[Macros](/versions/6.5.0/rules/macros) are the heart of this pattern. Macros are used like
 rules, but they can create several targets. Typically, they will create a
 target with the specified name which performs the primary build action: perhaps
 it builds a normal binary, a Docker image, or an archive of source code. In
@@ -138,7 +137,7 @@ an imaginary `bazel publish` command.
 It's not immediately obvious what the implementation of the `_sphinx_publisher`
 rule might look like. Often, actions like this write a _launcher_ shell script.
 This method typically involves using
-[`ctx.actions.expand_template`](lib/actions#expand_template)
+[`ctx.actions.expand_template`](/versions/6.5.0/rules/lib/actions#expand_template)
 to write a very simple shell script, in this case invoking the publisher binary
 with a path to the output of the primary target. This way, the publisher
 implementation can remain generic, the `_sphinx_site` rule can just produce
diff --git a/versions/6.5.0/run/build.mdx b/versions/6.5.0/run/build.mdx
index 07e85aa3..c4238b7a 100644
--- a/versions/6.5.0/run/build.mdx
+++ b/versions/6.5.0/run/build.mdx
@@ -603,8 +603,7 @@ Note: Hermeticity means that the action only uses its declared input
 files and no other files in the filesystem, and it only produces its declared
 output files. See [Hermeticity](/versions/6.5.0/concepts/hermeticity) for more details.
 
-On some platforms such as [Google Kubernetes
-Engine](https://cloud.google.com/kubernetes-engine/) cluster nodes or Debian,
+On some platforms such as [Google Kubernetes Engine](https://cloud.google.com/kubernetes-engine/) cluster nodes or Debian,
 user namespaces are deactivated by default due to security
 concerns. This can be checked by looking at the file
 `/proc/sys/kernel/unprivileged_userns_clone`: if it exists and contains a 0,
diff --git a/versions/6.5.0/run/client-server.mdx b/versions/6.5.0/run/client-server.mdx
index be1f6009..4364b0e8 100644
--- a/versions/6.5.0/run/client-server.mdx
+++ b/versions/6.5.0/run/client-server.mdx
@@ -40,7 +40,7 @@ ps -e f
 This makes it easier to find out which server process belongs to a given
 workspace. (Beware that with certain other options to `ps`, Bazel server
 processes may be named just `java`.) Bazel servers can be stopped using the
-[shutdown](/docs/user-manual#shutdown) command.
+[shutdown](/versions/6.5.0/docs/user-manual#shutdown) command.
 
 When running `bazel`, the client first checks that the server is the appropriate
 version; if not, the server is stopped and a new one started. This ensures that
diff --git a/versions/6.5.0/run/scripts.mdx b/versions/6.5.0/run/scripts.mdx
index 781654c0..5e5e0c82 100644
--- a/versions/6.5.0/run/scripts.mdx
+++ b/versions/6.5.0/run/scripts.mdx
@@ -29,7 +29,7 @@ commands to complete before it can continue.
 
 ### Notes about server mode {#server-mode}
 
-By default, Bazel uses a long-running [server process](/docs/client-server) as an
+By default, Bazel uses a long-running [server process](/versions/6.5.0/docs/client-server) as an
 optimization. When running Bazel in a script, don't forget to call `shutdown`
 when you're finished with the server, or, specify `--max_idle_secs=5` so that
 idle servers shut themselves down promptly.
@@ -88,7 +88,7 @@ However, all non-zero exit values will always constitute an error.
 
 ### Reading the .bazelrc file {#reading-bazelrc}
 
-By default, Bazel reads the [`.bazelrc` file](/docs/bazelrc) from the base
+By default, Bazel reads the [`.bazelrc` file](/versions/6.5.0/docs/bazelrc) from the base
 workspace directory or the user's home directory. Whether or not this is
 desirable is a choice for your script; if your script needs to be perfectly
 hermetic (such as when doing release builds), you should disable reading the
@@ -122,4 +122,4 @@ these messages.
 
 ## Troubleshooting performance by profiling {#performance-profiling}
 
-See the [Performance Profiling](/rules/performance#performance-profiling) section.
+See the [Performance Profiling](/versions/6.5.0/rules/performance#performance-profiling) section.
diff --git a/versions/6.5.0/start/android-app.mdx b/versions/6.5.0/start/android-app.mdx
index 67ce43ec..c8212069 100644
--- a/versions/6.5.0/start/android-app.mdx
+++ b/versions/6.5.0/start/android-app.mdx
@@ -6,7 +6,7 @@ title: 'Bazel Tutorial: Build an Android App'
 This tutorial covers how to build a simple Android app using Bazel.
 
 Bazel supports building Android apps using the
-[Android rules](/reference/be/android).
+[Android rules](/versions/6.5.0/reference/be/android).
 
 This tutorial is intended for Windows, macOS and Linux users and does not
 require experience with Bazel or Android app development. You do not need to
@@ -18,7 +18,7 @@ In this tutorial you learn how to:
 
 *   Set up your environment by installing Bazel and Android Studio, and
     downloading the sample project.
-*   Set up a Bazel [workspace](/reference/be/workspace) that contains the source code
+*   Set up a Bazel [workspace](/versions/6.5.0/reference/be/workspace) that contains the source code
     for the app and a `WORKSPACE` file that identifies the top level of the
     workspace directory.
 *   Update the `WORKSPACE` file to contain references to the required
@@ -33,9 +33,8 @@ In this tutorial you learn how to:
 
 Before you begin the tutorial, install the following software:
 
-* **Bazel.** To install, follow the [installation instructions](/install).
-* **Android Studio.** To install, follow the steps to [download Android
-  Studio](https://developer.android.com/sdk/index.html).
+* **Bazel.** To install, follow the [installation instructions](/versions/6.5.0/install).
+* **Android Studio.** To install, follow the steps to [download Android Studio](https://developer.android.com/sdk/index.html).
   Execute the setup wizard to download the SDK and configure your environment.
 * (Optional) **Git.** Use `git` to download the Android app project.
 
@@ -46,12 +45,11 @@ For the sample project, use a basic Android app project in
 
 This app has a single button that prints a greeting when clicked:
 
-![Button greeting](/docs/images/android_tutorial_app.png "Tutorial app button greeting")
+![Button greeting](/versions/6.5.0/docs/images/android_tutorial_app.png "Tutorial app button greeting")
 
 **Figure 1.** Android app button greeting.
 
-Clone the repository with `git` (or [download the ZIP file
-directly](https://github.com/bazelbuild/examples/archive/master.zip)):
+Clone the repository with `git` (or [download the ZIP file directly](https://github.com/bazelbuild/examples/archive/master.zip)):
 
 ```posix-terminal
 git clone https://github.com/bazelbuild/examples
@@ -98,12 +96,11 @@ The key files and directories are:
 
 ### Set up the workspace
 
-A [workspace](/concepts/build-ref#workspace) is a directory that contains the
+A [workspace](/versions/6.5.0/concepts/build-ref#workspace) is a directory that contains the
 source files for one or more software projects, and has a `WORKSPACE` file at
 its root.
 
-The `WORKSPACE` file may be empty or may contain references to [external
-dependencies](/docs/external) required to build your project.
+The `WORKSPACE` file may be empty or may contain references to [external dependencies](/versions/6.5.0/docs/external) required to build your project.
 
 First, run the following command to create an empty `WORKSPACE` file:
 
@@ -146,8 +143,7 @@ environment variable, and automatically detect the highest API level and the
 latest version of build tools installed within that location.
 
 You can set the `ANDROID_HOME` variable to the location of the Android SDK. Find
-the path to the installed SDK using Android Studio's [SDK
-Manager](https://developer.android.com/studio/intro/update#sdk-manager).
+the path to the installed SDK using Android Studio's [SDK Manager](https://developer.android.com/studio/intro/update#sdk-manager).
 Assuming the SDK is installed to default locations, you can use the following
 commands to set the `ANDROID_HOME` variable:
 
@@ -196,8 +192,7 @@ android_sdk_repository(
 ```
 
 **Optional:** If you want to compile native code into your Android app, you
-also need to download the [Android
-NDK](https://developer.android.com/ndk/downloads/index.html)
+also need to download the [Android NDK](https://developer.android.com/ndk/downloads/index.html)
 and tell Bazel where to find it by adding the following line to your `WORKSPACE` file:
 
 ```python
@@ -208,8 +203,7 @@ Similar to `android_sdk_repository`, the path to the Android NDK is inferred
 from the `ANDROID_NDK_HOME` environment variable by default. The path can also
 be explicitly specified with a `path` attribute on `android_ndk_repository`.
 
-For more information, read [Using the Android Native Development Kit with
-Bazel](/docs/android-ndk).
+For more information, read [Using the Android Native Development Kit with Bazel](/versions/6.5.0/docs/android-ndk).
 
 `api_level` is the version of the Android API that the SDK and NDK
 target - for example, 23 for Android 6.0 and 25 for Android 7.1. If not
@@ -222,7 +216,7 @@ contains a map from Android releases to NDK-supported API levels.
 
 ### Create a BUILD file
 
-A [`BUILD` file](/concepts/build-files) describes the relationship
+A [`BUILD` file](/versions/6.5.0/concepts/build-files) describes the relationship
 between a set of build outputs, like compiled Android resources from `aapt` or
 class files from `javac`, and their dependencies. These dependencies may be
 source files (Java, C++) in your workspace or other build outputs. `BUILD` files
@@ -230,7 +224,7 @@ are written in a language called **Starlark**.
 
 `BUILD` files are part of a concept in Bazel known as the *package hierarchy*.
 The package hierarchy is a logical structure that overlays the directory
-structure in your workspace. Each [package](/concepts/build-ref#packages) is a
+structure in your workspace. Each [package](/versions/6.5.0/concepts/build-ref#packages) is a
 directory (and its subdirectories) that contains a related set of source files
 and a `BUILD` file. The package also includes any subdirectories, excluding
 those that contain their own `BUILD` file. The *package name* is the path to the
@@ -248,16 +242,15 @@ packages.
 
 A `BUILD` file contains several different types of declarations for Bazel. The
 most important type is the
-[build rule](/concepts/build-files#types-of-build-rules), which tells
+[build rule](/versions/6.5.0/concepts/build-files#types-of-build-rules), which tells
 Bazel how to build an intermediate or final software output from a set of source
 files or other dependencies. Bazel provides two build rules,
-[`android_library`](/reference/be/android#android_library) and
-[`android_binary`](/reference/be/android#android_binary), that you can use to
+[`android_library`](/versions/6.5.0/reference/be/android#android_library) and
+[`android_binary`](/versions/6.5.0/reference/be/android#android_binary), that you can use to
 build an Android app.
 
 For this tutorial, you'll first use the
-`android_library` rule to tell Bazel to build an [Android library
-module](http://developer.android.com/tools/projects/index.html#LibraryProjects)
+`android_library` rule to tell Bazel to build an [Android library module](http://developer.android.com/tools/projects/index.html#LibraryProjects)
 from the app source code and resource files. You'll then use the
 `android_binary` rule to tell Bazel how to build the Android application package.
 
@@ -289,7 +282,7 @@ rule using this name as a dependency in the `android_binary` rule.
 
 #### Add an android_binary rule
 
-The [`android_binary`](/reference/be/android#android_binary) rule builds
+The [`android_binary`](/versions/6.5.0/reference/be/android#android_binary) rule builds
 the Android application package (`.apk` file) for your app.
 
 Create a new `BUILD` file in the `src/main/` directory,
@@ -322,7 +315,7 @@ Try building the app! Run the following command to build the
 bazel build //src/main:app
 ```
 
-The [`build`](/docs/user-manual#build) subcommand instructs Bazel to build the
+The [`build`](/versions/6.5.0/docs/user-manual#build) subcommand instructs Bazel to build the
 target that follows. The target is specified as the name of a build rule inside
 a `BUILD` file, with along with the package path relative to your workspace
 directory. For this example, the target is `app` and the package path is
@@ -330,7 +323,7 @@ directory. For this example, the target is `app` and the package path is
 
 Note that you can sometimes omit the package path or target name, depending on
 your current working directory at the command line and the name of the target.
-For more details about target labels and paths, see [Labels](/concepts/labels).
+For more details about target labels and paths, see [Labels](/versions/6.5.0/concepts/labels).
 
 Bazel will start to build the sample app. During the build process, its output
 will appear similar to the following:
@@ -373,11 +366,9 @@ file:
 ### Run the app
 
 You can now deploy the app to a connected Android device or emulator from the
-command line using the [`bazel
-mobile-install`](/docs/user-manual#mobile-install) command. This command uses
+command line using the [`bazel mobile-install`](/versions/6.5.0/docs/user-manual#mobile-install) command. This command uses
 the Android Debug Bridge (`adb`) to communicate with the device. You must set up
-your device to use `adb` following the instructions in [Android Debug
-Bridge](http://developer.android.com/tools/help/adb.html) before deployment. You
+your device to use `adb` following the instructions in [Android Debug Bridge](http://developer.android.com/tools/help/adb.html) before deployment. You
 can also choose to install the app on the Android emulator included in Android
 Studio. Make sure the emulator is running before executing the command below.
 
@@ -389,14 +380,14 @@ bazel mobile-install //src/main:app
 
 Next, find and launch the "Bazel Tutorial App":
 
-![Bazel tutorial app](/docs/images/android_tutorial_before.png "Bazel tutorial app")
+![Bazel tutorial app](/versions/6.5.0/docs/images/android_tutorial_before.png "Bazel tutorial app")
 
 **Figure 2.** Bazel tutorial app.
 
 **Congratulations! You have just installed your first Bazel-built Android app.**
 
 Note that the `mobile-install` subcommand also supports the
-[`--incremental`](/docs/user-manual#mobile-install) flag that can be used to
+[`--incremental`](/versions/6.5.0/docs/user-manual#mobile-install) flag that can be used to
 deploy only those parts of the app that have changed since the last deployment.
 
 It also supports the `--start_app` flag to start the app immediately upon
@@ -407,13 +398,13 @@ installing it.
 For more details, see these pages:
 
 * Open issues on [GitHub](https://github.com/bazelbuild/bazel/issues)
-* More information on [mobile-install](/docs/mobile-install)
+* More information on [mobile-install](/versions/6.5.0/docs/mobile-install)
 * Integrate external dependencies like AppCompat, Guava and JUnit from Maven
   repositories using [rules_jvm_external](https://github.com/bazelbuild/rules_jvm_external)
 * Run Robolectric tests with the [robolectric-bazel](https://github.com/robolectric/robolectric-bazel)
   integration.
-* Testing your app with [Android instrumentation tests](/docs/android-instrumentation-test)
-* Integrating C and C++ code into your Android app with the [NDK](/docs/android-ndk)
+* Testing your app with [Android instrumentation tests](/versions/6.5.0/docs/android-instrumentation-test)
+* Integrating C and C++ code into your Android app with the [NDK](/versions/6.5.0/docs/android-ndk)
 * See more Bazel example projects of:
   * [a Kotlin app](https://github.com/bazelbuild/rules_jvm_external/tree/master/examples/android_kotlin_app)
   * [Robolectric testing](https://github.com/bazelbuild/rules_jvm_external/tree/master/examples/android_local_test)
diff --git a/versions/6.5.0/start/cpp.mdx b/versions/6.5.0/start/cpp.mdx
index cf3e3ae7..5b5ecdf7 100644
--- a/versions/6.5.0/start/cpp.mdx
+++ b/versions/6.5.0/start/cpp.mdx
@@ -11,7 +11,7 @@ are used in Bazel’s context and walks you through the basics of the Bazel
 workflow. Starting with the tools you need, you will build and run three
 projects with increasing complexity and learn how and why they get more complex.
 
-While Bazel is a [build system](https://bazel.build/basics/build-systems) that
+While Bazel is a [build system](https://bazel.build/versions/6.5.0/basics/build-systems) that
 supports multi-language builds, this tutorial uses a C++ project as an example
 and provides the general guidelines and flow that apply to most languages.
 
@@ -19,7 +19,7 @@ Estimated completion time: 30 minutes.
 
 ### Prerequisites {#prerequisites}
 
-Start by [installing Bazel](https://bazel.build/install), if you haven’t
+Start by [installing Bazel](https://bazel.build/versions/6.5.0/install), if you haven’t
 already. This tutorial uses Git for source control, so for best results
 [install Git](https://git-scm.com/book/en/v2/Getting-Started-Installing-Git) as
 well.
@@ -64,9 +64,7 @@ examples
 ```
 
 There are three sets of files, each set representing a stage in this tutorial.
-In the first stage, you will build a single [target]
-(https://bazel.build/reference/glossary#target) residing in a single [package]
-(https://bazel.build/reference/glossary#package). In the second stage, you will
+In the first stage, you will build a single [target](https://bazel.build/versions/6.5.0/reference/glossary#target) residing in a single [package](https://bazel.build/versions/6.5.0/reference/glossary#package). In the second stage, you will
 you will build both a binary and a library from a single package. In
 the third and final stage, you will build a project with multiple packages and
 build it with multiple targets.
@@ -75,7 +73,7 @@ build it with multiple targets.
 
 By installing Bazel (and Git) and cloning the repository for this tutorial, you
 have laid the foundation for your first build with Bazel. Continue to the next
-section to define some terms and set up your [workspace](https://bazel.build/reference/glossary#workspace).
+section to define some terms and set up your [workspace](https://bazel.build/versions/6.5.0/reference/glossary#workspace).
 
 ## Getting started {#getting-started}
 
@@ -85,13 +83,13 @@ section to define some terms and set up your [workspace](https://bazel.build/ref
 a directory that holds your project's source files and Bazel's build outputs. It
 also contains these significant files:
 
-*   The [`WORKSPACE` file](https://bazel.build/reference/glossary#workspace-file)
+*   The [`WORKSPACE` file](https://bazel.build/versions/6.5.0/reference/glossary#workspace-file)
 , which identifies the directory and its contents as a Bazel workspace and
 lives at the root of the project's directory structure.
-*   One or more [`BUILD` files](https://bazel.build/reference/glossary#build-file)
+*   One or more [`BUILD` files](https://bazel.build/versions/6.5.0/reference/glossary#build-file)
 , which tell Bazel how to build different parts of the project. A
 directory within the workspace that contains a BUILD file is a
-[package](https://bazel.build/reference/glossary#package). (More on packages
+[package](https://bazel.build/versions/6.5.0/reference/glossary#package). (More on packages
 later in this tutorial.)
 
 In future projects, to designate a directory as a Bazel workspace, create an
@@ -101,18 +99,18 @@ a `WORKSPACE` file is already present in each stage.
 **NOTE**: When Bazel builds the project, all inputs must be in
 the same workspace. Files residing in different workspaces are independent of
 one another unless linked. More detailed information about workspace rules can
-be found in [this guide](https://bazel.build/reference/be/workspace).
+be found in [this guide](https://bazel.build/versions/6.5.0/reference/be/workspace).
 
 
 ### Understand the BUILD file {#understand-build}
 
 
 A `BUILD` file contains several different types of instructions for Bazel. Each
-`BUILD` file requires at least one [rule](https://bazel.build/reference/glossary#rule)
+`BUILD` file requires at least one [rule](https://bazel.build/versions/6.5.0/reference/glossary#rule)
 as a set of instructions, which tells Bazel how to build the desired outputs,
 such as executable binaries or libraries. Each instance of a build rule in the
-`BUILD` file is called a [target](https://bazel.build/reference/glossary#target)
-and points to a specific set of source files and [dependencies](https://bazel.build/reference/glossary#dependency).
+`BUILD` file is called a [target](https://bazel.build/versions/6.5.0/reference/glossary#target)
+and points to a specific set of source files and [dependencies](https://bazel.build/versions/6.5.0/reference/glossary#dependency).
 A target can also point to other targets.
 
 Take a look at the `BUILD` file in the `cpp-tutorial/stage1/main` directory:
@@ -125,7 +123,7 @@ cc_binary(
 ```
 
 In our example, the `hello-world` target instantiates Bazel's built-in
-[cc_binary rule](https://bazel.build/reference/be/c-cpp#cc_binary).
+[cc_binary rule](https://bazel.build/versions/6.5.0/reference/be/c-cpp#cc_binary).
 The rule tells Bazel to build a self-contained executable binary from the
 hello-world.cc source file with no dependencies.
 
@@ -190,9 +188,7 @@ This results in a printed “`Hello world`” message.
 
 Here’s the dependency graph of Stage 1:
 
-![Dependency graph for hello-world displays a single target with a single source file.]
-(/docs/images/cpp-tutorial-stage1.png "Dependency graph for hello-world displays
-a single target with a single source file.")
+![Dependency graph for hello-world displays a single target with a single source file.](/versions/6.5.0/docs/images/cpp-tutorial-stage1.png "Dependency graph for hello-world displays a single target with a single source file.")
 
 
 ### Summary: stage 1 {#summary-stage-1}
@@ -240,7 +236,7 @@ cc_binary(
 ```
 
 With this `BUILD` file, Bazel first builds the `hello-greet` library
-(using Bazel's built-in [cc_library rule](https://bazel.build/reference/be/c-cpp#cc_library)),
+(using Bazel's built-in [cc_library rule](https://bazel.build/versions/6.5.0/reference/be/c-cpp#cc_library)),
 then the hello-world binary. The deps attribute in
 the hello-world target tells Bazel that the hello-greet
 library is required to build the hello-world binary.
@@ -279,7 +275,7 @@ that file.
 Looking at the dependency graph, you can see that hello-world depends on the
 same inputs as it did before, but the structure of the build is different:
 
-![Dependency graph for `hello-world` displays structure changes after modification to the file.](/docs/images/cpp-tutorial-stage2.png "Dependency graph for `hello-world` displays structure changes after modification to the file.")
+![Dependency graph for `hello-world` displays structure changes after modification to the file.](/versions/6.5.0/docs/images/cpp-tutorial-stage2.png "Dependency graph for `hello-world` displays structure changes after modification to the file.")
 
 ### Summary: stage 2 {#summary-stage-2}
 
@@ -347,7 +343,7 @@ in the `lib` package (hence the target label `//lib:hello-time`) - Bazel knows
 this through the `deps` attribute. You can see this reflected in the dependency
 graph:
 
-![Dependency graph for `hello-world` displays how the target in the main package depends on the target in the `lib` package.](/docs/images/cpp-tutorial-stage3.png "Dependency graph for `hello-world` displays how the target in the main package depends on the target in the `lib` package.")
+![Dependency graph for `hello-world` displays how the target in the main package depends on the target in the `lib` package.](/versions/6.5.0/docs/images/cpp-tutorial-stage3.png "Dependency graph for `hello-world` displays how the target in the main package depends on the target in the `lib` package.")
 
 For the build to succeed, you make the `//lib:hello-time` target in `lib/BUILD`
 explicitly visible to targets in `main/BUILD` using the visibility attribute.
@@ -395,12 +391,12 @@ Bazel journey.
 You’ve now completed your first basic build with Bazel, but this is just the
 start. Here are some more resources to continue learning with Bazel:
 
-*   To keep focusing on C++, read about common [C++ build use cases](https://bazel.build/tutorials/cpp-use-cases).
+*   To keep focusing on C++, read about common [C++ build use cases](https://bazel.build/versions/6.5.0/tutorials/cpp-use-cases).
 *   To get started with building other applications with Bazel, see the tutorials
-for [Java](https://bazel.build/tutorials/java), [Android application](https://bazel.build/tutorials/android-app),
-or [iOS application](https://bazel.build/tutorials/ios-app).
+for [Java](https://bazel.build/versions/6.5.0/tutorials/java), [Android application](https://bazel.build/versions/6.5.0/tutorials/android-app),
+or [iOS application](https://bazel.build/versions/6.5.0/tutorials/ios-app).
 *   To learn more about working with local and remote repositories, read about
-[external dependencies](https://bazel.build/docs/external).
-*   To learn more about Bazel’s other rules, see this [reference guide](https://bazel.build/rules).
+[external dependencies](https://bazel.build/versions/6.5.0/docs/external).
+*   To learn more about Bazel’s other rules, see this [reference guide](https://bazel.build/versions/6.5.0/rules).
 
 Happy building!
diff --git a/versions/6.5.0/start/ios-app.mdx b/versions/6.5.0/start/ios-app.mdx
index a46b8dc3..3c9c5a34 100644
--- a/versions/6.5.0/start/ios-app.mdx
+++ b/versions/6.5.0/start/ios-app.mdx
@@ -11,7 +11,7 @@ In this tutorial, you learn how to:
 
 *   Set up the environment by installing Bazel and Xcode, and downloading the
     sample project
-*   Set up a Bazel [workspace](/concepts/build-ref#workspace) that contained the source code
+*   Set up a Bazel [workspace](/versions/6.5.0/concepts/build-ref#workspace) that contained the source code
     for the app and a `WORKSPACE` file that identifies the top level of the
     workspace directory
 *   Update the `WORKSPACE` file to contain references to the required
@@ -26,7 +26,7 @@ To get started, install Bazel and Xcode, and get the sample project.
 
 ### Install Bazel
 
-Follow the [installation instructions](/install/) to install Bazel and
+Follow the [installation instructions](/versions/6.5.0/install/) to install Bazel and
 its dependencies.
 
 ### Install Xcode
@@ -58,7 +58,7 @@ tutorial are in `$HOME/examples/tutorial/ios-app`.
 
 ## Set up a workspace
 
-A [workspace](/concepts/build-ref#workspace) is a directory that contains the
+A [workspace](/versions/6.5.0/concepts/build-ref#workspace) is a directory that contains the
 source files for one or more software projects, as well as a `WORKSPACE` file
 and `BUILD` files that contain the instructions that Bazel uses to build
 the software. The workspace may also contain symbolic links to output
@@ -84,7 +84,7 @@ export WORKSPACE=$HOME/examples/tutorial
 
 Every workspace must have a text file named `WORKSPACE` located in the top-level
 workspace directory. This file may be empty or it may contain references
-to [external dependencies](/docs/external) required to build the
+to [external dependencies](/versions/6.5.0/docs/external) required to build the
 software.
 
 For now, you'll create an empty `WORKSPACE` file, which simply serves to
@@ -105,7 +105,7 @@ This creates and opens the empty `WORKSPACE` file.
 To build applications for Apple devices, Bazel needs to pull the latest
 [Apple build rules](https://github.com/bazelbuild/rules_apple)
 from its GitHub repository. To enable this, add the following
-[`git_repository`](/reference/be/workspace#git_repository)
+[`git_repository`](/versions/6.5.0/reference/be/workspace#git_repository)
 rules to your `WORKSPACE` file:
 
 ```python
@@ -177,7 +177,7 @@ rule is built into the Bazel package.
 
 Bazel provides several build rules that you can use to build an app for the
 iOS platform. For this tutorial, you'll first use the
-[`objc_library`](/reference/be/objective-c#objc_library) rule to tell Bazel
+[`objc_library`](/versions/6.5.0/reference/be/objective-c#objc_library) rule to tell Bazel
 how to build a static library from the app source code and Xib files. Then
 you'll use the
 [`ios_application`](https://github.com/bazelbuild/rules_apple/tree/main/doc)
diff --git a/versions/6.5.0/start/java.mdx b/versions/6.5.0/start/java.mdx
index 7864b5f7..493997e7 100644
--- a/versions/6.5.0/start/java.mdx
+++ b/versions/6.5.0/start/java.mdx
@@ -24,7 +24,7 @@ In this tutorial you learn how to:
 
 ### Install Bazel
 
-To prepare for the tutorial, first [Install Bazel](/install) if
+To prepare for the tutorial, first [Install Bazel](/versions/6.5.0/install) if
 you don't have it installed already.
 
 ### Install the JDK
@@ -112,7 +112,7 @@ java_binary(
 ```
 
 In our example, the `ProjectRunner` target instantiates Bazel's built-in
-[`java_binary` rule](/reference/be/java#java_binary). The rule tells Bazel to
+[`java_binary` rule](/versions/6.5.0/reference/be/java#java_binary). The rule tells Bazel to
 build a `.jar` file and a wrapper shell script (both named after the target).
 
 The attributes in the target explicitly state its dependencies and options.
@@ -120,7 +120,7 @@ While the `name` attribute is mandatory, many are optional. For example, in the
 `ProjectRunner` rule target, `name` is the name of the target, `srcs` specifies
 the source files that Bazel uses to build the target, and `main_class` specifies
 the class that contains the main method. (You may have noticed that our example
-uses [glob](/reference/be/functions#glob) to pass a set of source files to Bazel
+uses [glob](/versions/6.5.0/reference/be/functions#glob) to pass a set of source files to Bazel
 instead of listing them one by one.)
 
 ### Build the project
@@ -179,7 +179,7 @@ Then, paste the text into [GraphViz](http://www.webgraphviz.com/).
 As you can see, the project has a single target that build two source files with
 no additional dependencies:
 
-![Dependency graph of the target 'ProjectRunner'](/docs/images/tutorial_java_01.svg)
+![Dependency graph of the target 'ProjectRunner'](/versions/6.5.0/docs/images/tutorial_java_01.svg)
 
 After you set up your workspace, build your project, and examine its
 dependencies, then you can add some complexity.
@@ -242,8 +242,7 @@ recompiles that file.
 Looking at the dependency graph, you can see that `ProjectRunner` depends on the
 same inputs as it did before, but the structure of the build is different:
 
-![Dependency graph of the target 'ProjectRunner' after adding a dependency](
-/docs/images/tutorial_java_02.svg)
+![Dependency graph of the target 'ProjectRunner' after adding a dependency](/versions/6.5.0/docs/images/tutorial_java_02.svg)
 
 You've now built the project with two targets. The `ProjectRunner` target builds
 two source files and depends on one other target (`:greeter`), which builds
@@ -272,7 +271,7 @@ The `runner` target depends on the `greeter` target in the `//` package (hence
 the target label `//:greeter`) - Bazel knows this through the `deps` attribute.
 Take a look at the dependency graph:
 
-![Dependency graph of the target 'runner'](/docs/images/tutorial_java_03.svg)
+![Dependency graph of the target 'runner'](/versions/6.5.0/docs/images/tutorial_java_03.svg)
 
 However, for the build to succeed, you must explicitly give the `runner` target
 in `//src/main/java/com/example/cmdline/BUILD` visibility to targets in
@@ -354,7 +353,7 @@ Let’s now package a Java target for deployment by building the binary with all
 of its runtime dependencies. This lets you run the binary outside of your
 development environment.
 
-As you remember, the [java_binary](/reference/be/java#java_binary) build rule
+As you remember, the [java_binary](/versions/6.5.0/reference/be/java#java_binary) build rule
 produces a `.jar` and a wrapper shell script. Take a look at the contents of
 `runner.jar` using this command:
 
@@ -420,16 +419,16 @@ For more details, see:
 *  [rules_jvm_external](https://github.com/bazelbuild/rules_jvm_external) for
    rules to manage transitive Maven dependencies.
 
-*  [External Dependencies](/docs/external) to learn more about working with
+*  [External Dependencies](/versions/6.5.0/docs/external) to learn more about working with
    local and remote repositories.
 
-*  The [other rules](/rules) to learn more about Bazel.
+*  The [other rules](/versions/6.5.0/rules) to learn more about Bazel.
 
-*  The [C++ build tutorial](/tutorials/cpp) to get started with building
+*  The [C++ build tutorial](/versions/6.5.0/tutorials/cpp) to get started with building
    C++ projects with Bazel.
 
-*  The [Android application tutorial](/tutorials/android-app) and
-   [iOS application tutorial](/tutorials/ios-app) to get started with
+*  The [Android application tutorial](/versions/6.5.0/tutorials/android-app) and
+   [iOS application tutorial](/versions/6.5.0/tutorials/ios-app) to get started with
    building mobile applications for Android and iOS with Bazel.
 
 Happy building!
diff --git a/versions/6.5.0/tutorials/cpp-dependency.mdx b/versions/6.5.0/tutorials/cpp-dependency.mdx
index 6f8300bb..f2e82e47 100644
--- a/versions/6.5.0/tutorials/cpp-dependency.mdx
+++ b/versions/6.5.0/tutorials/cpp-dependency.mdx
@@ -40,7 +40,7 @@ xdot <(bazel query --notool_deps --noimplicit_deps "deps(//main:hello-world)" \
 As you can see, the first stage of the sample project has a single target
 that builds a single source file with no additional dependencies:
 
-![Dependency graph for 'hello-world'](/docs/images/cpp-tutorial-stage1.png "Dependency graph")
+![Dependency graph for 'hello-world'](/versions/6.5.0/docs/images/cpp-tutorial-stage1.png "Dependency graph")
 
 **Figure 1.** Dependency graph for `hello-world` displays a single target with a single
 source file.
diff --git a/versions/6.5.0/tutorials/cpp-use-cases.mdx b/versions/6.5.0/tutorials/cpp-use-cases.mdx
index 22a4b0fe..ca093976 100644
--- a/versions/6.5.0/tutorials/cpp-use-cases.mdx
+++ b/versions/6.5.0/tutorials/cpp-use-cases.mdx
@@ -6,15 +6,15 @@ title: 'Common C++ Build Use Cases'
 Here you will find some of the most common use cases for building C++ projects
 with Bazel. If you have not done so already, get started with building C++
 projects with Bazel by completing the tutorial
-[Introduction to Bazel: Build a C++ Project](/tutorials/cpp).
+[Introduction to Bazel: Build a C++ Project](/versions/6.5.0/tutorials/cpp).
 
 For information on cc_library and hdrs header files, see
-cc_library.
+cc_library.
 
 ## Including multiple files in a target {#multiple-files-target}
 
 You can include multiple files in a single target with
-glob.
+glob.
 For example:
 
 ```python
diff --git a/versions/7.6.1/community/images/Bitrise.png b/versions/7.6.1/community/images/Bitrise.png
new file mode 100644
index 00000000..07f85f1e
Binary files /dev/null and b/versions/7.6.1/community/images/Bitrise.png differ
diff --git a/versions/7.6.1/community/images/Gradle.png b/versions/7.6.1/community/images/Gradle.png
new file mode 100644
index 00000000..1e5f5eb0
Binary files /dev/null and b/versions/7.6.1/community/images/Gradle.png differ
diff --git a/versions/7.6.1/community/images/Linkedin-Logo.png b/versions/7.6.1/community/images/Linkedin-Logo.png
new file mode 100644
index 00000000..9dd8715c
Binary files /dev/null and b/versions/7.6.1/community/images/Linkedin-Logo.png differ
diff --git a/versions/7.6.1/community/images/Lucid_Software-logo.svg b/versions/7.6.1/community/images/Lucid_Software-logo.svg
new file mode 100644
index 00000000..6c8591e0
--- /dev/null
+++ b/versions/7.6.1/community/images/Lucid_Software-logo.svg
@@ -0,0 +1,16 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/versions/7.6.1/community/images/acqio_logo.svg b/versions/7.6.1/community/images/acqio_logo.svg
new file mode 100644
index 00000000..8fa11bcd
--- /dev/null
+++ b/versions/7.6.1/community/images/acqio_logo.svg
@@ -0,0 +1,60 @@
+
+
+
+
+
+	
+		
+			
+				
+					
+					
+					
+					
+					
+				
+				
+					
+						
+							
+								
+							
+						
+					
+				
+				
+					
+						
+							
+								
+							
+						
+					
+				
+			
+		
+	
+
+
diff --git a/versions/7.6.1/community/images/aspect-logo-2.png b/versions/7.6.1/community/images/aspect-logo-2.png
new file mode 100644
index 00000000..dfebc4cb
Binary files /dev/null and b/versions/7.6.1/community/images/aspect-logo-2.png differ
diff --git a/versions/7.6.1/community/images/bitrise-logo.png b/versions/7.6.1/community/images/bitrise-logo.png
new file mode 100644
index 00000000..27037ce6
Binary files /dev/null and b/versions/7.6.1/community/images/bitrise-logo.png differ
diff --git a/versions/7.6.1/community/images/buildbuddy-logo.svg b/versions/7.6.1/community/images/buildbuddy-logo.svg
new file mode 100644
index 00000000..bdb72dc6
--- /dev/null
+++ b/versions/7.6.1/community/images/buildbuddy-logo.svg
@@ -0,0 +1,11 @@
+
+
+
+
+
+
+
+
+
+
+
diff --git a/versions/7.6.1/community/images/buildkite.svg b/versions/7.6.1/community/images/buildkite.svg
new file mode 100644
index 00000000..209a4ab1
--- /dev/null
+++ b/versions/7.6.1/community/images/buildkite.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/7.6.1/community/images/codethink-logo.svg b/versions/7.6.1/community/images/codethink-logo.svg
new file mode 100644
index 00000000..406005d8
--- /dev/null
+++ b/versions/7.6.1/community/images/codethink-logo.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/7.6.1/community/images/develocity.png b/versions/7.6.1/community/images/develocity.png
new file mode 100644
index 00000000..eb3eb65a
Binary files /dev/null and b/versions/7.6.1/community/images/develocity.png differ
diff --git a/versions/7.6.1/community/images/dropbox.png b/versions/7.6.1/community/images/dropbox.png
new file mode 100644
index 00000000..125476a6
Binary files /dev/null and b/versions/7.6.1/community/images/dropbox.png differ
diff --git a/versions/7.6.1/community/images/engflow-logo.svg b/versions/7.6.1/community/images/engflow-logo.svg
new file mode 100644
index 00000000..e5f0c343
--- /dev/null
+++ b/versions/7.6.1/community/images/engflow-logo.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/7.6.1/community/images/epam-logo.png b/versions/7.6.1/community/images/epam-logo.png
new file mode 100644
index 00000000..e6a5674c
Binary files /dev/null and b/versions/7.6.1/community/images/epam-logo.png differ
diff --git a/versions/7.6.1/community/images/flare-logo.png b/versions/7.6.1/community/images/flare-logo.png
new file mode 100644
index 00000000..84cb0e5b
Binary files /dev/null and b/versions/7.6.1/community/images/flare-logo.png differ
diff --git a/versions/7.6.1/community/images/hermetiq-logo.png b/versions/7.6.1/community/images/hermetiq-logo.png
new file mode 100644
index 00000000..90765d96
Binary files /dev/null and b/versions/7.6.1/community/images/hermetiq-logo.png differ
diff --git a/versions/7.6.1/community/images/jetbrains.svg b/versions/7.6.1/community/images/jetbrains.svg
new file mode 100644
index 00000000..cb3a2a0e
--- /dev/null
+++ b/versions/7.6.1/community/images/jetbrains.svg
@@ -0,0 +1,13 @@
+
+  
+    
+      
+      
+      
+    
+  
+  
+  
+  
+  
+
diff --git a/versions/7.6.1/community/images/liulishuo.png b/versions/7.6.1/community/images/liulishuo.png
new file mode 100644
index 00000000..a6758e5c
Binary files /dev/null and b/versions/7.6.1/community/images/liulishuo.png differ
diff --git a/versions/7.6.1/community/images/nativelink.svg b/versions/7.6.1/community/images/nativelink.svg
new file mode 100644
index 00000000..148fcdce
--- /dev/null
+++ b/versions/7.6.1/community/images/nativelink.svg
@@ -0,0 +1,1123 @@
+
+
+  
+    
+    
+      
+      
+    
+    
+      
+      
+    
+    
+    
+      
+      
+    
+    
+      
+      
+      
+      
+      
+      
+      
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+      
+      
+    
+    
+    
+    
+      
+      
+    
+    
+    
+    
+      
+      
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+      
+      
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+      
+      
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+      
+      
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+      
+      
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+      
+      
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+      
+      
+    
+  
+  
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+  
+  
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+  
+
diff --git a/versions/7.6.1/community/images/oasis-logo.png b/versions/7.6.1/community/images/oasis-logo.png
new file mode 100644
index 00000000..846a9cd5
Binary files /dev/null and b/versions/7.6.1/community/images/oasis-logo.png differ
diff --git a/versions/7.6.1/community/images/sumglobal-logo.png b/versions/7.6.1/community/images/sumglobal-logo.png
new file mode 100644
index 00000000..6736328d
Binary files /dev/null and b/versions/7.6.1/community/images/sumglobal-logo.png differ
diff --git a/versions/7.6.1/community/images/trunk-logo-dark.svg b/versions/7.6.1/community/images/trunk-logo-dark.svg
new file mode 100644
index 00000000..f25940af
--- /dev/null
+++ b/versions/7.6.1/community/images/trunk-logo-dark.svg
@@ -0,0 +1,22 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/versions/7.6.1/community/images/tweag-logo.png b/versions/7.6.1/community/images/tweag-logo.png
new file mode 100644
index 00000000..20210ed7
Binary files /dev/null and b/versions/7.6.1/community/images/tweag-logo.png differ
diff --git a/versions/7.6.1/community/images/typedb.png b/versions/7.6.1/community/images/typedb.png
new file mode 100644
index 00000000..48ce1056
Binary files /dev/null and b/versions/7.6.1/community/images/typedb.png differ
diff --git a/versions/7.6.1/community/images/virtuslab.svg b/versions/7.6.1/community/images/virtuslab.svg
new file mode 100644
index 00000000..6fba0316
--- /dev/null
+++ b/versions/7.6.1/community/images/virtuslab.svg
@@ -0,0 +1,20 @@
+
+
+  
+    
+  
+  
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+  
+
diff --git a/versions/7.6.1/community/roadmaps-configurability.mdx b/versions/7.6.1/community/roadmaps-configurability.mdx
index 4352e5c2..bd886573 100644
--- a/versions/7.6.1/community/roadmaps-configurability.mdx
+++ b/versions/7.6.1/community/roadmaps-configurability.mdx
@@ -26,8 +26,7 @@ title: 'Bazel Configurability 2021 Roadmap'
 * Builds scale well, particularly w.r.t graph size and action caching.
 
 We also support
-[`cquery`](https://bazel.build/versions/7.6.1/query/cquery), [`Starlark
-configuration`](https://bazel.build/extending/config),
+[`cquery`](https://bazel.build/versions/7.6.1/query/cquery), [`Starlark configuration`](https://bazel.build/versions/7.6.1/extending/config),
 and
 [`select()`](https://bazel.build/versions/7.6.1/docs/configurable-attributes).
 
@@ -41,15 +40,13 @@ interest of accurate expectations.
 ### Platforms
 
 

-Q3 2021**Android rules use the new [platforms
-API](https://bazel.build/concepts/platforms)**
+Q3 2021**Android rules use the new [platforms API](https://bazel.build/versions/7.6.1/concepts/platforms)**
 IN PROGRESS ([#11749](https://github.com/bazelbuild/bazel/issues/11749))
 
 * This is our main priority for the beginning of 2021.
 
 

-Q3 2021**Builds support [multiple execution
-platforms](https://docs.google.com/document/d/1U9HzdDmtRnm244CaRM6JV-q2408mbNODAMewcGjnnbM/)**
+Q3 2021**Builds support [multiple execution platforms](https://docs.google.com/document/d/1U9HzdDmtRnm244CaRM6JV-q2408mbNODAMewcGjnnbM/)**
 IN PROGRESS ([#11748](https://github.com/bazelbuild/bazel/issues/11748))
 
 

diff --git a/versions/7.6.1/community/sig.mdx b/versions/7.6.1/community/sig.mdx
index 408b363c..0a591bf7 100644
--- a/versions/7.6.1/community/sig.mdx
+++ b/versions/7.6.1/community/sig.mdx
@@ -3,8 +3,7 @@ title: 'Bazel Special Interest Groups'
 ---
 
 Bazel hosts Special Interest Groups (SIGs) to focus collaboration on particular
-areas and to support communication and coordination between [Bazel owners,
-maintainers, and contributors](/versions/7.6.1/contribute/policy). This policy
+areas and to support communication and coordination between [Bazel owners, maintainers, and contributors](/versions/7.6.1/contribute/policy). This policy
 applies to [`bazelbuild`](http://github.com/bazelbuild).
 
 SIGs do their work in public. The ideal scope for a SIG covers a well-defined
diff --git a/versions/7.6.1/concepts/build-ref.mdx b/versions/7.6.1/concepts/build-ref.mdx
index 177b315b..714a69d4 100644
--- a/versions/7.6.1/concepts/build-ref.mdx
+++ b/versions/7.6.1/concepts/build-ref.mdx
@@ -17,8 +17,7 @@ its root; such a boundary marker file could be `MODULE.bazel`, `REPO.bazel`, or
 in legacy contexts, `WORKSPACE` or `WORKSPACE.bazel`.
 
 The repo in which the current Bazel command is being run is called the _main
-repo_. Other, (external) repos are defined by _repo rules_; see [external
-dependencies overview](/versions/7.6.1/external/overview) for more information.
+repo_. Other, (external) repos are defined by _repo rules_; see [external dependencies overview](/versions/7.6.1/external/overview) for more information.
 
 ## Workspace {#workspace}
 
@@ -95,5 +94,4 @@ have three properties: the list of packages they contain, their name, and other
 package groups they include. The only allowed ways to refer to them are from the
 `visibility` attribute of rules or from the `default_visibility` attribute of
 the `package` function; they do not generate or consume files. For more
-information, refer to the [`package_group`
-documentation](/versions/7.6.1/reference/be/functions#package_group).
+information, refer to the [`package_group` documentation](/versions/7.6.1/reference/be/functions#package_group).
diff --git a/versions/7.6.1/concepts/labels.mdx b/versions/7.6.1/concepts/labels.mdx
index 8ed20174..745b2fb0 100644
--- a/versions/7.6.1/concepts/labels.mdx
+++ b/versions/7.6.1/concepts/labels.mdx
@@ -10,8 +10,7 @@ form looks like:
 ```
 
 The first part of the label is the repository name, `@@myrepo`. The double-`@`
-syntax signifies that this is a [*canonical* repo
-name](/versions/7.6.1/external/overview#canonical-repo-name), which is unique within
+syntax signifies that this is a [*canonical* repo name](/versions/7.6.1/external/overview#canonical-repo-name), which is unique within
 the workspace. Labels with canonical repo names unambiguously identify a target
 no matter which context they appear in.
 
diff --git a/versions/7.6.1/concepts/platforms.mdx b/versions/7.6.1/concepts/platforms.mdx
index a9984066..0a9ab872 100644
--- a/versions/7.6.1/concepts/platforms.mdx
+++ b/versions/7.6.1/concepts/platforms.mdx
@@ -77,8 +77,7 @@ To test your Android project with platforms, see
 for support.
 
 You can still use platform APIs with Apple builds (for example, when building
-with a mixture of Apple rules and pure C++) with [platform
-mappings](#platform-mappings).
+with a mixture of Apple rules and pure C++) with [platform mappings](#platform-mappings).
 
 ### Other languages {#other-languages}
 
@@ -241,8 +240,7 @@ sets `--cpu`, `--crossstool_top`, or other legacy flags, rules that read
 
 When migrating your project to platforms, you must either convert changes like
 `return { "//command_line_option:cpu": "arm" }` to `return {
-"//command_line_option:platforms": "//:my_arm_platform" }` or use [platform
-mappings](#platform-mappings) to support both styles during migration.
+"//command_line_option:platforms": "//:my_arm_platform" }` or use [platform mappings](#platform-mappings) to support both styles during migration.
 window.
 
 ## Migrating your rule set {#migrating-your-rule-set}
@@ -361,10 +359,8 @@ attributes declare a language's tools (like `compiler =
 this information to rules that need to build with these tools.
 
 Toolchains declare the `constraint_value`s of machines they can
-[target][target_compatible_with Attribute]
-(`target_compatible_with = ["@platforms//os:linux"]`) and machines their tools can
-[run on][exec_compatible_with Attribute]
-(`exec_compatible_with = ["@platforms//os:mac"]`).
+[target][target_compatible_with Attribute](`target_compatible_with = ["@platforms//os:linux"]`) and machines their tools can
+[run on][exec_compatible_with Attribute](`exec_compatible_with = ["@platforms//os:mac"]`).
 
 When building `$ bazel build //:myproject --platforms=//:myplatform`, Bazel
 automatically selects a toolchain that can run on the build machine and
diff --git a/versions/7.6.1/configure/attributes.mdx b/versions/7.6.1/configure/attributes.mdx
index b61e569f..faa32464 100644
--- a/versions/7.6.1/configure/attributes.mdx
+++ b/versions/7.6.1/configure/attributes.mdx
@@ -2,8 +2,7 @@
 title: 'Configurable Build Attributes'
 ---
 
-**_Configurable attributes_**, commonly known as [`select()`](
-/reference/be/functions#select), is a Bazel feature that lets users toggle the values
+**_Configurable attributes_**, commonly known as [`select()`](/versions/7.6.1/reference/be/functions#select), is a Bazel feature that lets users toggle the values
 of build rule attributes at the command line.
 
 This can be used, for example, for a multiplatform library that automatically
@@ -407,8 +406,7 @@ sh_library(
 )
 ```
 
-If you need a `select` to match when multiple conditions match, consider [AND
-chaining](#and-chaining).
+If you need a `select` to match when multiple conditions match, consider [AND chaining](#and-chaining).
 
 ## OR chaining {#or-chaining}
 
diff --git a/versions/7.6.1/configure/integrate-cpp.mdx b/versions/7.6.1/configure/integrate-cpp.mdx
index 57b72b1c..d53c079f 100644
--- a/versions/7.6.1/configure/integrate-cpp.mdx
+++ b/versions/7.6.1/configure/integrate-cpp.mdx
@@ -33,8 +33,7 @@ This is because when writing our own actions, they must behave
 consistently with the C++ toolchain - for example, passing C++ command line
 flags to a tool that invokes the C++ compiler behind the scenes.
 
-C++ rules use a special way of constructing command lines based on [feature
-configuration](/versions/7.6.1/docs/cc-toolchain-config-reference). To construct a command line,
+C++ rules use a special way of constructing command lines based on [feature configuration](/versions/7.6.1/docs/cc-toolchain-config-reference). To construct a command line,
 you need the following:
 
 * `features` and `action_configs` - these come from the `CcToolchainConfigInfo`
diff --git a/versions/7.6.1/configure/windows.mdx b/versions/7.6.1/configure/windows.mdx
index 78798ef3..aa881ba2 100644
--- a/versions/7.6.1/configure/windows.mdx
+++ b/versions/7.6.1/configure/windows.mdx
@@ -166,8 +166,7 @@ To build C++ targets with MSVC, you need:
         set BAZEL_VC=C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC
         ```
 
-*   The [Windows
-    SDK](https://developer.microsoft.com/en-us/windows/downloads/windows-10-sdk).
+*   The [Windows SDK](https://developer.microsoft.com/en-us/windows/downloads/windows-10-sdk).
 
     The Windows SDK contains header files and libraries you need when building
     Windows applications, including Bazel itself. By default, the latest Windows SDK installed will
@@ -186,8 +185,7 @@ To build C++ targets with MSVC, you need:
 
 If everything is set up, you can build a C++ target now!
 
-Try building a target from one of our [sample
-projects](https://github.com/bazelbuild/bazel/tree/master/examples):
+Try building a target from one of our [sample projects](https://github.com/bazelbuild/bazel/tree/master/examples):
 
 
 
 
-To build and use Dynamically Linked Libraries (DLL files), see [this
-example](https://github.com/bazelbuild/bazel/tree/master/examples/windows/dll).
+To build and use Dynamically Linked Libraries (DLL files), see [this example](https://github.com/bazelbuild/bazel/tree/master/examples/windows/dll).
 
 **Command Line Length Limit**: To prevent the
 [Windows command line length limit issue](https://github.com/bazelbuild/bazel/issues/5163),
@@ -292,8 +289,7 @@ On Windows, Bazel builds two output files for `java_binary` rules:
 *   a `.jar` file
 *   a `.exe` file that can set up the environment for the JVM and run the binary
 
-Try building a target from one of our [sample
-projects](https://github.com/bazelbuild/bazel/tree/master/examples):
+Try building a target from one of our [sample projects](https://github.com/bazelbuild/bazel/tree/master/examples):
 
 
   
   
 
 If you are interested in details about how Bazel builds Python targets on
-Windows, check out this [design
-doc](https://github.com/bazelbuild/bazel-website/blob/master/designs/_posts/2016-09-05-build-python-on-windows.md).
+Windows, check out this [design doc](https://github.com/bazelbuild/bazel-website/blob/master/designs/_posts/2016-09-05-build-python-on-windows.md).
diff --git a/versions/7.6.1/contribute/breaking-changes.mdx b/versions/7.6.1/contribute/breaking-changes.mdx
index c96565bd..60a5b1a0 100644
--- a/versions/7.6.1/contribute/breaking-changes.mdx
+++ b/versions/7.6.1/contribute/breaking-changes.mdx
@@ -67,7 +67,7 @@ should contain the URL of the GitHub issue. As the flag name starts with
 ```
 
 In the commit description, add a brief summary of the flag.
-Also add [`RELNOTES:`](release-notes.md) in the following form:
+Also add [`RELNOTES:`](/versions/7.6.1/contribute/release-notes) in the following form:
 `RELNOTES: --incompatible_name_of_flag has been added. See #xyz for details`
 
 The commit should also update the relevant documentation, so that there is no
diff --git a/versions/7.6.1/contribute/codebase.mdx b/versions/7.6.1/contribute/codebase.mdx
index 0e8b17e0..c763e27e 100644
--- a/versions/7.6.1/contribute/codebase.mdx
+++ b/versions/7.6.1/contribute/codebase.mdx
@@ -227,8 +227,7 @@ repository", the others are called "external repositories".
 A repository is marked by a repo boundary file (`MODULE.bazel`, `REPO.bazel`, or
 in legacy contexts, `WORKSPACE` or `WORKSPACE.bazel`) in its root directory. The
 main repo is the source tree where you're invoking Bazel from. External repos
-are defined in various ways; see [external dependencies
-overview](/versions/7.6.1/external/overview) for more information.
+are defined in various ways; see [external dependencies overview](/versions/7.6.1/external/overview) for more information.
 
 Code of external repositories is symlinked or downloaded under
 `$OUTPUT_BASE/external`.
diff --git a/versions/7.6.1/contribute/design-documents.mdx b/versions/7.6.1/contribute/design-documents.mdx
index b5a3bd2e..5fc06f52 100644
--- a/versions/7.6.1/contribute/design-documents.mdx
+++ b/versions/7.6.1/contribute/design-documents.mdx
@@ -25,7 +25,7 @@ Here are some examples of significant changes:
 When you write a design document, you can coordinate with other Bazel developers
 and seek guidance from Bazel's core team. For example, when a proposal adds,
 removes, or modifies any function or object available in BUILD, WORKSPACE, or
-bzl files, add the [Starlark team](maintainers-guide.md) as reviewers.
+bzl files, add the [Starlark team](/versions/7.6.1/contribute/maintainers-guide) as reviewers.
 Design documents are reviewed before submission because:
 
 *   Bazel is a very complex system; seemingly innocuous local changes can have
@@ -137,8 +137,7 @@ A lead reviewer should be a domain expert who is:
 *   Objective and capable of providing constructive feedback
 *   Available for the entire review period to lead the process
 
-Consider checking the contacts for various [team
-labels](/versions/7.6.1/contribute/maintainers-guide#team-labels).
+Consider checking the contacts for various [team labels](/versions/7.6.1/contribute/maintainers-guide#team-labels).
 
 ## Markdown vs Google Docs {#markdown-versus-gdocs}
 
@@ -168,12 +167,10 @@ Markdown for posterity.
 
 ### Using Google Docs {#gdocs}
 
-For consistency, use the [Bazel design doc template](
-https://docs.google.com/document/d/1cE5zrjrR40RXNg64XtRFewSv6FrLV6slGkkqxBumS1w/edit).
+For consistency, use the [Bazel design doc template](https://docs.google.com/document/d/1cE5zrjrR40RXNg64XtRFewSv6FrLV6slGkkqxBumS1w/edit).
 It includes the necessary header and creates visual
 consistency with other Bazel related documents. To do that, click on **File** >
-**Make a copy** or click this link to [make a copy of the design doc
-template](https://docs.google.com/document/d/1cE5zrjrR40RXNg64XtRFewSv6FrLV6slGkkqxBumS1w/copy).
+**Make a copy** or click this link to [make a copy of the design doc template](https://docs.google.com/document/d/1cE5zrjrR40RXNg64XtRFewSv6FrLV6slGkkqxBumS1w/copy).
 
 To make your document readable to the world, click on
 **Share** > **Advanced** > **Change…**, and
diff --git a/versions/7.6.1/contribute/images/structured-concurrency-3d.svg b/versions/7.6.1/contribute/images/structured-concurrency-3d.svg
new file mode 100644
index 00000000..accbb42a
--- /dev/null
+++ b/versions/7.6.1/contribute/images/structured-concurrency-3d.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/7.6.1/contribute/images/structured-concurrency.svg b/versions/7.6.1/contribute/images/structured-concurrency.svg
new file mode 100644
index 00000000..0258d9a9
--- /dev/null
+++ b/versions/7.6.1/contribute/images/structured-concurrency.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/7.6.1/contribute/images/suspend-resume.svg b/versions/7.6.1/contribute/images/suspend-resume.svg
new file mode 100644
index 00000000..7de1218f
--- /dev/null
+++ b/versions/7.6.1/contribute/images/suspend-resume.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/7.6.1/contribute/images/unstructured-concurrency.svg b/versions/7.6.1/contribute/images/unstructured-concurrency.svg
new file mode 100644
index 00000000..0951639a
--- /dev/null
+++ b/versions/7.6.1/contribute/images/unstructured-concurrency.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/7.6.1/contribute/index.mdx b/versions/7.6.1/contribute/index.mdx
index f38843e9..093895f5 100644
--- a/versions/7.6.1/contribute/index.mdx
+++ b/versions/7.6.1/contribute/index.mdx
@@ -10,8 +10,7 @@ As you use Bazel, you may find things that can be improved.
 You can help by [reporting issues](http://github.com/bazelbuild/bazel/issues)
 when:
 
-   - Bazel crashes or you encounter a bug that can [only be resolved using `bazel
-     clean`](/versions/7.6.1/run/build#correct-incremental-rebuilds).
+   - Bazel crashes or you encounter a bug that can [only be resolved using `bazel clean`](/versions/7.6.1/run/build#correct-incremental-rebuilds).
    - The documentation is incomplete or unclear. You can also report issues
      from the page you are viewing by using the "Create issue"
      link at the top right corner of the page.
@@ -21,11 +20,9 @@ when:
 
 You can engage with the Bazel community by:
 
-   - Answering questions [on Stack Overflow](
-     https://stackoverflow.com/questions/tagged/bazel).
+   - Answering questions [on Stack Overflow](https://stackoverflow.com/questions/tagged/bazel).
    - Helping other users [on Slack](https://slack.bazel.build).
-   - Improving documentation or [contributing examples](
-     https://github.com/bazelbuild/examples).
+   - Improving documentation or [contributing examples](https://github.com/bazelbuild/examples).
    - Sharing your experience or your tips, for example, on a blog or social media.
 
 ## Contribute code {#contribute-code}
@@ -40,8 +37,7 @@ You can contribute to the Bazel ecosystem by:
    - Contributing to Bazel-related tools, for example, migration tools.
    - Improving Bazel integration with other IDEs and tools.
 
-Before making a change, [create a GitHub
-issue](http://github.com/bazelbuild/bazel/issues)
+Before making a change, [create a GitHub issue](http://github.com/bazelbuild/bazel/issues)
 or email [bazel-discuss@](mailto:bazel-discuss@googlegroups.com).
 
 The most helpful contributions fix bugs or add features (as opposed
diff --git a/versions/7.6.1/contribute/maintainers-guide.mdx b/versions/7.6.1/contribute/maintainers-guide.mdx
index 404a17bb..a8e83715 100644
--- a/versions/7.6.1/contribute/maintainers-guide.mdx
+++ b/versions/7.6.1/contribute/maintainers-guide.mdx
@@ -4,8 +4,7 @@ title: 'Guide for Bazel Maintainers'
 
 This is a guide for the maintainers of the Bazel open source project.
 
-If you are looking to contribute to Bazel, please read [Contributing to
-Bazel](/versions/7.6.1/contribute) instead.
+If you are looking to contribute to Bazel, please read [Contributing to Bazel](/versions/7.6.1/contribute) instead.
 
 The objectives of this page are to:
 
@@ -37,8 +36,7 @@ repository.
 
 1. A user creates an issue by choosing one of the
 [issue templates](https://github.com/bazelbuild/bazel/issues/new/choose)
-   and it enters the pool of [unreviewed open
-   issues](https://github.com/bazelbuild/bazel/issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aopen+-label%3Auntriaged+-label%3Ap2+-label%3Ap1+-label%3Ap3+-label%3Ap4+-label%3Ateam-Starlark+-label%3Ateam-Rules-CPP+-label%3Ateam-Rules-Java+-label%3Ateam-XProduct+-label%3Ateam-Android+-label%3Ateam-Apple+-label%3Ateam-Configurability++-label%3Ateam-Performance+-label%3Ateam-Rules-Server+-label%3Ateam-Core+-label%3Ateam-Rules-Python+-label%3Ateam-Remote-Exec+-label%3Ateam-Local-Exec+-label%3Ateam-Bazel).
+   and it enters the pool of [unreviewed open issues](https://github.com/bazelbuild/bazel/issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aopen+-label%3Auntriaged+-label%3Ap2+-label%3Ap1+-label%3Ap3+-label%3Ap4+-label%3Ateam-Starlark+-label%3Ateam-Rules-CPP+-label%3Ateam-Rules-Java+-label%3Ateam-XProduct+-label%3Ateam-Android+-label%3Ateam-Apple+-label%3Ateam-Configurability++-label%3Ateam-Performance+-label%3Ateam-Rules-Server+-label%3Ateam-Core+-label%3Ateam-Rules-Python+-label%3Ateam-Remote-Exec+-label%3Ateam-Local-Exec+-label%3Ateam-Bazel).
 1. A member on the Developer Experience (DevEx) subteam rotation reviews the
    issue.
    1. If the issue is **not a bug** or a **feature request**, the DevEx member
@@ -58,21 +56,18 @@ repository.
 1. After reviewing the issue, the DevEx member decides if the issue requires
    immediate attention. If it does, they will assign the **P0**
    [priority](#priority) label and an owner from the list of team leads.
-1. The DevEx member assigns the `untriaged` label and exactly one [team
-   label](#team-labels) for routing.
+1. The DevEx member assigns the `untriaged` label and exactly one [team label](#team-labels) for routing.
 1. The DevEx member also assigns exactly one `type:` label, such as `type: bug`
    or `type: feature request`, according to the type of the issue.
 1. For platform-specific issues, the DevEx member assigns one `platform:` label,
    such as `platform:apple` for Mac-specific issues.
 1. If the issue is low priority and can be worked on by a new community
    contributor, the DevEx member assigns the `good first issue` label.
-At this stage, the issue enters the pool of [untriaged open
-issues](https://github.com/bazelbuild/bazel/issues?q=is%3Aissue+is%3Aopen+label%3Auntriaged).
+At this stage, the issue enters the pool of [untriaged open issues](https://github.com/bazelbuild/bazel/issues?q=is%3Aissue+is%3Aopen+label%3Auntriaged).
 
 Each Bazel subteam will triage all issues under labels they own, preferably on a
 weekly basis. The subteam will review and evaluate the issue and provide a
-resolution, if possible. If you are an owner of a team label, see [this section
-](#label-own) for more information.
+resolution, if possible. If you are an owner of a team label, see [this section](#label-own) for more information.
 
 When an issue is resolved, it can be closed.
 
@@ -111,8 +106,7 @@ preferably on a weekly basis.
      issue is either P0 or P1 we assume that is actively worked on.
 1. Remove the `untriaged` label.
 
-Note that you need to be in the [bazelbuild
-organization](https://github.com/bazelbuild) to be able to add or remove labels.
+Note that you need to be in the [bazelbuild organization](https://github.com/bazelbuild) to be able to add or remove labels.
 
 ### Pull Requests {#pull-requests}
 
@@ -138,8 +132,7 @@ issues.
   unusable, or a downed service that severely impacts development of the Bazel
   project. This includes regressions introduced in a new release that blocks a
   significant number of users, or an incompatible breaking change that was not
-  compliant to the [Breaking
-  Change](https://docs.google.com/document/d/1q5GGRxKrF_mnwtaPKI487P8OdDRh2nN7jX6U-FXnHL0/edit?pli=1#heading=h.ceof6vpkb3ik)
+  compliant to the [Breaking Change](https://docs.google.com/document/d/1q5GGRxKrF_mnwtaPKI487P8OdDRh2nN7jX6U-FXnHL0/edit?pli=1#heading=h.ceof6vpkb3ik)
   policy. No practical workaround exists.
 * [**P1**](https://github.com/bazelbuild/bazel/labels/P1) - Critical defect or
   feature which should be addressed in the next release, or a serious issue that
diff --git a/versions/7.6.1/contribute/naming.mdx b/versions/7.6.1/contribute/naming.mdx
index 41c7a2ac..37e0c5a7 100644
--- a/versions/7.6.1/contribute/naming.mdx
+++ b/versions/7.6.1/contribute/naming.mdx
@@ -4,8 +4,7 @@ title: 'Naming a Bazel related project'
 
 First, thank you for contributing to the Bazel ecosystem! Please reach out to
 the Bazel community on the
-[bazel-discuss mailing list](https://groups.google.com/forum/#!forum/bazel-discuss
-) to share your project and its suggested name.
+[bazel-discuss mailing list](https://groups.google.com/forum/#!forum/bazel-discuss) to share your project and its suggested name.
 
 If you are building a Bazel related tool or sharing your Skylark rules,
 we recommend following these guidelines for the name of your project:
diff --git a/versions/7.6.1/contribute/patch-acceptance.mdx b/versions/7.6.1/contribute/patch-acceptance.mdx
index 846d42a0..379d6ed7 100644
--- a/versions/7.6.1/contribute/patch-acceptance.mdx
+++ b/versions/7.6.1/contribute/patch-acceptance.mdx
@@ -11,29 +11,24 @@ code base.
    need a corresponding issue for tracking.
 1. If you're proposing significant changes, write a
    [design document](/versions/7.6.1/contribute/design-documents).
-1. Ensure you've signed a [Contributor License
-   Agreement](https://cla.developers.google.com).
+1. Ensure you've signed a [Contributor License Agreement](https://cla.developers.google.com).
 1. Prepare a git commit that implements the feature. Don't forget to add tests
    and update the documentation. If your change has user-visible effects, please
    [add release notes](/versions/7.6.1/contribute/release-notes). If it is an incompatible change,
    read the [guide for rolling out breaking changes](/versions/7.6.1/contribute/breaking-changes).
 1. Create a pull request on
    [GitHub](https://github.com/bazelbuild/bazel/pulls). If you're new to GitHub,
-   read [about pull
-   requests](https://help.github.com/articles/about-pull-requests/). Note that
+   read [about pull requests](https://help.github.com/articles/about-pull-requests/). Note that
    we restrict permissions to create branches on the main Bazel repository, so
-   you will need to push your commit to [your own fork of the
-   repository](https://help.github.com/articles/working-with-forks/).
+   you will need to push your commit to [your own fork of the repository](https://help.github.com/articles/working-with-forks/).
 1. A Bazel maintainer should assign you a reviewer within two business days
    (excluding holidays in the USA and Germany). If you aren't assigned a
    reviewer in that time, you can request one by emailing
-   [bazel-discuss@googlegroups.com]
-   (mailto:bazel-discuss@googlegroups.com).
+   [bazel-discuss@googlegroups.com](mailto:bazel-discuss@googlegroups.com).
 1. Work with the reviewer to complete a code review. For each change, create a
    new commit and push it to make changes to your pull request. If the review
    takes too long (for instance, if the reviewer is unresponsive), send an email to
-   [bazel-discuss@googlegroups.com]
-   (mailto:bazel-discuss@googlegroups.com).
+   [bazel-discuss@googlegroups.com](mailto:bazel-discuss@googlegroups.com).
 1. After your review is complete, a Bazel maintainer applies your patch to
    Google's internal version control system.
 
diff --git a/versions/7.6.1/contribute/release-notes.mdx b/versions/7.6.1/contribute/release-notes.mdx
index 66f937da..16becfea 100644
--- a/versions/7.6.1/contribute/release-notes.mdx
+++ b/versions/7.6.1/contribute/release-notes.mdx
@@ -16,8 +16,7 @@ the release announcement.
 * If the change adds / removes / changes Bazel in a user-visible way, then it
   may be advantageous to mention it.
 
-If the change is significant, follow the [design document
-policy](/versions/7.6.1/contribute/design-documents) first.
+If the change is significant, follow the [design document policy](/versions/7.6.1/contribute/design-documents) first.
 
 ## Guidelines {#guidelines}
 
@@ -60,10 +59,8 @@ change is about.
 
 ## Process {#process}
 
-As part of the [release
-process](https://github.com/bazelbuild/continuous-integration/blob/master/docs/release-playbook.md),
-we collect the `RELNOTES` tags of every commit. We copy everything in a [Google
-Doc](https://docs.google.com/document/d/1wDvulLlj4NAlPZamdlEVFORks3YXJonCjyuQMUQEmB0/edit)
+As part of the [release process](https://github.com/bazelbuild/continuous-integration/blob/master/docs/release-playbook.md),
+we collect the `RELNOTES` tags of every commit. We copy everything in a [Google Doc](https://docs.google.com/document/d/1wDvulLlj4NAlPZamdlEVFORks3YXJonCjyuQMUQEmB0/edit)
 where we review, edit, and organize the notes.
 
 The release manager sends an email to the
@@ -71,6 +68,4 @@ The release manager sends an email to the
 Bazel contributors are invited to contribute to the document and make sure
 their changes are correctly reflected in the announcement.
 
-Later, the announcement will be submitted to the [Bazel
-blog](https://blog.bazel.build/), using the [bazel-blog
-repository](https://github.com/bazelbuild/bazel-blog/tree/master/_posts).
+Later, the announcement will be submitted to the [Bazel blog](https://blog.bazel.build/), using the [bazel-blog repository](https://github.com/bazelbuild/bazel-blog/tree/master/_posts).
diff --git a/versions/7.6.1/contribute/statemachine-guide.mdx b/versions/7.6.1/contribute/statemachine-guide.mdx
index bee1cc38..0657005e 100644
--- a/versions/7.6.1/contribute/statemachine-guide.mdx
+++ b/versions/7.6.1/contribute/statemachine-guide.mdx
@@ -172,8 +172,7 @@ instead, batches[^4] as many lookups as possible before doing so. The value
 might not be immediately available, for example, requiring a Skyframe restart,
 so the caller specifies what to do with the resulting value using a callback.
 
-The `StateMachine` processor ([`Driver`s and bridging to
-SkyFrame](#drivers-and-bridging)) guarantees that the value is available before
+The `StateMachine` processor ([`Driver`s and bridging to SkyFrame](#drivers-and-bridging)) guarantees that the value is available before
 the next state begins. An example follows.
 
 ```
@@ -284,8 +283,7 @@ and solutions to certain control flow problems.
 ### Sequential states
 
 This is the most common and straightforward control flow pattern. An example of
-this is shown in [Stateful computations inside
-`SkyKeyComputeState`](#stateful-computations).
+this is shown in [Stateful computations inside `SkyKeyComputeState`](#stateful-computations).
 
 ### Branching
 
@@ -545,8 +543,7 @@ section describes the propagation of data values.
 
 ### Implementing `Tasks.lookUp` callbacks
 
-There’s an example of implementing a `Tasks.lookUp` callback in [SkyValue
-lookups](#skyvalue-lookups). This section provides rationale and suggests
+There’s an example of implementing a `Tasks.lookUp` callback in [SkyValue lookups](#skyvalue-lookups). This section provides rationale and suggests
 approaches for handling multiple SkyValues.
 
 #### `Tasks.lookUp` callbacks {#tasks-lookup-callbacks}
@@ -710,8 +707,7 @@ class BarProducer implements StateMachine {
 Tip: It would be tempting to use the more concise signature void `accept(Bar
 value)` rather than the stuttery `void acceptBarValue(Bar value)` above.
 However, `Consumer` is a common overload of `void accept(Bar value)`,
-so doing this often leads to violations of the [Overloads: never
-split](https://google.github.io/styleguide/javaguide.html#s3.4.2-ordering-class-contents)
+so doing this often leads to violations of the [Overloads: never split](https://google.github.io/styleguide/javaguide.html#s3.4.2-ordering-class-contents)
 style-guide rule.
 
 Tip: Using a custom `ResultSink` type instead of a generic one from
@@ -774,14 +770,11 @@ pattern after accepting output from either a subtask or SkyValue lookup.
 Note that the implementation of `acceptBarError` eagerly forwards the result to
 the `Caller.ResultSink`, as required by [Error bubbling](#error-bubbling).
 
-Alternatives for top-level `StateMachine`s are described in [`Driver`s and
-bridging to SkyFunctions](#drivers-and-bridging).
+Alternatives for top-level `StateMachine`s are described in [`Driver`s and bridging to SkyFunctions](#drivers-and-bridging).
 
 ### Error handling {#error-handling}
 
-There's a couple of examples of error handling already in [`Tasks.lookUp`
-callbacks](#tasks-lookup-callbacks) and [Propagating values between
-`StateMachines`](#propagating-values). Exceptions, other than
+There's a couple of examples of error handling already in [`Tasks.lookUp` callbacks](#tasks-lookup-callbacks) and [Propagating values between `StateMachines`](#propagating-values). Exceptions, other than
 `InterruptedException` are not thrown, but instead passed around through
 callbacks as values. Such callbacks often have exclusive-or semantics, with
 exactly one of a value or error being passed.
@@ -1184,8 +1177,7 @@ states. Where it is possible, local stack `step` variables are young generation
 variables and efficiently GC'd.
 
 For `StateMachine` variables, breaking things down into subtasks and following
-the recommended pattern for [Propagating values between
-`StateMachine`s](#propagating-values) is also helpful. Observe that when
+the recommended pattern for [Propagating values between `StateMachine`s](#propagating-values) is also helpful. Observe that when
 following the pattern, only child `StateMachine`s have references to parent
 `StateMachine`s and not vice versa. This means that as children complete and
 update the parents using result callbacks, the children naturally fall out of
@@ -1207,8 +1199,7 @@ potentially reflecting local behavior.
 
 ### Concurrency tree diagram {#concurrency-tree-diagram}
 
-The following is an alternative view of the diagram in [Structured
-concurrency](#structured-concurrency) that better depicts the tree structure.
+The following is an alternative view of the diagram in [Structured concurrency](#structured-concurrency) that better depicts the tree structure.
 The blocks form a small tree.
 
 ![Structured Concurrency 3D](/versions/7.6.1/contribute/images/structured-concurrency-3d.svg)
diff --git a/versions/7.6.1/docs/android-instrumentation-test.mdx b/versions/7.6.1/docs/android-instrumentation-test.mdx
index 544ff179..68ba374e 100644
--- a/versions/7.6.1/docs/android-instrumentation-test.mdx
+++ b/versions/7.6.1/docs/android-instrumentation-test.mdx
@@ -2,8 +2,7 @@
 title: 'Android Instrumentation Tests'
 ---
 
-_If you're new to Bazel, start with the [Building Android with
-Bazel](/versions/7.6.1/start/android-app ) tutorial._
+_If you're new to Bazel, start with the [Building Android with Bazel](/versions/7.6.1/start/android-app) tutorial._
 
 ![Running Android instrumentation tests in parallel](/versions/7.6.1/docs/images/android_test.gif "Android instrumentation test")
 
@@ -18,9 +17,7 @@ emulators in a sandbox, ensuring that tests always run from a clean state. Each
 test gets an isolated emulator instance, allowing tests to run in parallel
 without passing states between them.
 
-For more information on Android instrumentation tests, check out the [Android
-developer
-documentation](https://developer.android.com/training/testing/unit-testing/instrumented-unit-tests.html).
+For more information on Android instrumentation tests, check out the [Android developer documentation](https://developer.android.com/training/testing/unit-testing/instrumented-unit-tests.html).
 
 Please file issues in the [GitHub issue tracker](https://github.com/bazelbuild/bazel/issues).
 
@@ -58,8 +55,7 @@ This results in output similar to the following:
 release 4.1.0
 ```
 
-- **KVM**. Bazel requires emulators to have [hardware
-  acceleration](https://developer.android.com/studio/run/emulator-acceleration.html#accel-check)
+- **KVM**. Bazel requires emulators to have [hardware acceleration](https://developer.android.com/studio/run/emulator-acceleration.html#accel-check)
   with KVM on Linux. You can follow these
   [installation instructions](https://help.ubuntu.com/community/KVM/Installation)
   for Ubuntu.
@@ -173,11 +169,9 @@ The main attributes of the rule `android_instrumentation_test` are:
 
 - `target_device`: An `android_device` target. This target describes the
   specifications of the Android emulator which Bazel uses to create, launch and
-  run the tests. See the [section on choosing an Android
-  device](#android-device-target) for more information.
+  run the tests. See the [section on choosing an Android device](#android-device-target) for more information.
 
-The test app's `AndroidManifest.xml` must include [an ``
-tag](https://developer.android.com/studio/test/#configure_instrumentation_manifest_settings).
+The test app's `AndroidManifest.xml` must include [an `` tag](https://developer.android.com/studio/test/#configure_instrumentation_manifest_settings).
 This tag must specify the attributes for the **package of the target app** and
 the **fully qualified class name of the instrumentation test runner**,
 `androidx.test.runner.AndroidJUnitRunner`.
@@ -214,8 +208,7 @@ repositories:
 - `@androidsdk`: The Android SDK. Download this through Android Studio.
 
 - `@android_test_support`: Hosts the test runner, emulator launcher, and
-  `android_device` targets. You can find the [latest release
-  here](https://github.com/android/android-test/releases).
+  `android_device` targets. You can find the [latest release here](https://github.com/android/android-test/releases).
 
 Enable these dependencies by adding the following lines to your `WORKSPACE`
 file:
@@ -240,8 +233,7 @@ android_test_repositories()
 
 ## Maven dependencies {#maven-dependencies}
 
-For managing dependencies on Maven artifacts from repositories, such as [Google
-Maven](https://maven.google.com) or [Maven Central](https://central.maven.org),
+For managing dependencies on Maven artifacts from repositories, such as [Google Maven](https://maven.google.com) or [Maven Central](https://central.maven.org),
 you should use a Maven resolver, such as
 [`rules_jvm_external`](https://github.com/bazelbuild/rules_jvm_external).
 
@@ -370,8 +362,7 @@ the device/emulator listed in `adb devices`.
 
 ## Sample projects {#sample-projects}
 
-If you are looking for canonical project samples, see the [Android testing
-samples](https://github.com/googlesamples/android-testing#experimental-bazel-support)
+If you are looking for canonical project samples, see the [Android testing samples](https://github.com/googlesamples/android-testing#experimental-bazel-support)
 for projects using Espresso and UIAutomator.
 
 ## Espresso setup {#espresso-setup}
@@ -560,8 +551,7 @@ API_LEVELS = [
 
 ## Known issues {#known-issues}
 
-- [Forked adb server processes are not terminated after
-  tests](https://github.com/bazelbuild/bazel/issues/4853)
+- [Forked adb server processes are not terminated after tests](https://github.com/bazelbuild/bazel/issues/4853)
 - While APK building works on all platforms (Linux, macOS, Windows), testing
   only works on Linux.
 - Even with `--config=local_adb`, users still need to specify
diff --git a/versions/7.6.1/docs/android-ndk.mdx b/versions/7.6.1/docs/android-ndk.mdx
index 04e02a37..4775b2ee 100644
--- a/versions/7.6.1/docs/android-ndk.mdx
+++ b/versions/7.6.1/docs/android-ndk.mdx
@@ -2,8 +2,7 @@
 title: 'Using the Android Native Development Kit with Bazel'
 ---
 
-_If you're new to Bazel, please start with the [Building Android with
-Bazel](/versions/7.6.1/start/android-app ) tutorial._
+_If you're new to Bazel, please start with the [Building Android with Bazel](/versions/7.6.1/start/android-app) tutorial._
 
 ## Overview {#overview}
 
@@ -31,8 +30,7 @@ android_ndk_repository(
 )
 ```
 
-For more information about the `android_ndk_repository` rule, see the [Build
-Encyclopedia entry](/versions/7.6.1/reference/be/android#android_ndk_repository).
+For more information about the `android_ndk_repository` rule, see the [Build Encyclopedia entry](/versions/7.6.1/reference/be/android#android_ndk_repository).
 
 If you're using a recent version of the Android NDK (r22 and beyond), use the
 Starlark implementation of `android_ndk_repository`.
@@ -101,13 +99,11 @@ META-INF/MANIFEST.MF
 
 Bazel compiles all of the cc_libraries into a single shared object (`.so`) file,
 targeted for the `armeabi-v7a` ABI by default. To change this or build for
-multiple ABIs at the same time, see the section on [configuring the target
-ABI](#configuring-target-abi).
+multiple ABIs at the same time, see the section on [configuring the target ABI](#configuring-target-abi).
 
 ## Example setup {#example-setup}
 
-This example is available in the [Bazel examples
-repository](https://github.com/bazelbuild/examples/tree/master/android/ndk).
+This example is available in the [Bazel examples repository](https://github.com/bazelbuild/examples/tree/master/android/ndk).
 
 In the `BUILD.bazel` file, three targets are defined with the `android_binary`,
 `android_library`, and `cc_library` rules.
@@ -178,12 +174,10 @@ For r16 and below, the default STL is `gnustl`. For r17 and above, it is
 `libc++`. For convenience, the target `@androidndk//:default_crosstool` is
 aliased to the respective default STLs.
 
-Please note that from r18 onwards, [STLport and gnustl will be
-removed](https://android.googlesource.com/platform/ndk/+/master/docs/Roadmap.md#ndk-r18),
+Please note that from r18 onwards, [STLport and gnustl will be removed](https://android.googlesource.com/platform/ndk/+/master/docs/Roadmap.md#ndk-r18),
 making `libc++` the only STL in the NDK.
 
-See the [NDK
-documentation](https://developer.android.com/ndk/guides/cpp-support)
+See the [NDK documentation](https://developer.android.com/ndk/guides/cpp-support)
 for more information on these STLs.
 
 ## Configuring the target ABI {#configuring-target-abi}
@@ -324,8 +318,7 @@ an Android-compatible configuration so that the Bazel build *just works* without
 any special flags, except for `--fat_apk_cpu` and `--android_crosstool_top` for
 ABI and STL configuration.
 
-Behind the scenes, this automatic configuration uses Android [configuration
-transitions](/versions/7.6.1/extending/rules#configurations).
+Behind the scenes, this automatic configuration uses Android [configuration transitions](/versions/7.6.1/extending/rules#configurations).
 
 A compatible rule, like `android_binary`, automatically changes the
 configuration of its dependencies to an Android configuration, so only
diff --git a/versions/7.6.1/docs/bazel-and-android.mdx b/versions/7.6.1/docs/bazel-and-android.mdx
index af611534..52dba6ba 100644
--- a/versions/7.6.1/docs/bazel-and-android.mdx
+++ b/versions/7.6.1/docs/bazel-and-android.mdx
@@ -10,7 +10,7 @@ Android projects with Bazel.
 
 The following resources will help you work with Bazel on Android projects:
 
-*  [Tutorial: Building an Android app](/versions/7.6.1/start/android-app ). This
+*  [Tutorial: Building an Android app](/versions/7.6.1/start/android-app). This
    tutorial is a good place to start learning about Bazel commands and concepts,
    and how to build Android apps with Bazel.
 *  [Codelab: Building Android Apps with Bazel](https://developer.android.com/codelabs/bazel-android-intro#0).
diff --git a/versions/7.6.1/docs/configurable-attributes.mdx b/versions/7.6.1/docs/configurable-attributes.mdx
index c32f9575..f24dc320 100644
--- a/versions/7.6.1/docs/configurable-attributes.mdx
+++ b/versions/7.6.1/docs/configurable-attributes.mdx
@@ -2,8 +2,7 @@
 title: 'Configurable Build Attributes'
 ---
 
-**_Configurable attributes_**, commonly known as [`select()`](
-/reference/be/functions#select), is a Bazel feature that lets users toggle the values
+**_Configurable attributes_**, commonly known as [`select()`](/versions/7.6.1/reference/be/functions#select), is a Bazel feature that lets users toggle the values
 of build rule attributes at the command line.
 
 This can be used, for example, for a multiplatform library that automatically
@@ -407,8 +406,7 @@ sh_library(
 )
 ```
 
-If you need a `select` to match when multiple conditions match, consider [AND
-chaining](#and-chaining).
+If you need a `select` to match when multiple conditions match, consider [AND chaining](#and-chaining).
 
 ## OR chaining {#or-chaining}
 
diff --git a/versions/7.6.1/docs/images/a_b_a_c.svg b/versions/7.6.1/docs/images/a_b_a_c.svg
new file mode 100644
index 00000000..d38be075
--- /dev/null
+++ b/versions/7.6.1/docs/images/a_b_a_c.svg
@@ -0,0 +1,42 @@
+
+
+
+
+
+
+G
+
+
+
+a
+
+a
+
+
+
+b
+
+b
+
+
+
+a->b
+
+
+
+
+
+c
+
+c
+
+
+
+a->c
+
+
+
+
+
+
diff --git a/versions/7.6.1/docs/images/a_b_c.svg b/versions/7.6.1/docs/images/a_b_c.svg
new file mode 100644
index 00000000..acd948ab
--- /dev/null
+++ b/versions/7.6.1/docs/images/a_b_c.svg
@@ -0,0 +1,41 @@
+
+
+
+
+
+
+G
+
+
+
+a
+
+a
+
+
+
+b
+
+b
+
+
+
+a->b
+
+
+
+
+
+c
+
+c
+
+
+
+b->c
+
+
+
+
+
diff --git a/versions/7.6.1/docs/images/a_b_c_ac.svg b/versions/7.6.1/docs/images/a_b_c_ac.svg
new file mode 100644
index 00000000..b099c53e
--- /dev/null
+++ b/versions/7.6.1/docs/images/a_b_c_ac.svg
@@ -0,0 +1,47 @@
+
+
+
+
+
+
+G
+
+
+
+a
+
+a
+
+
+
+b
+
+b
+
+
+
+a->b
+
+
+
+
+
+c
+
+c
+
+
+
+a->c
+
+
+
+
+
+b->c
+
+
+
+
+
diff --git a/versions/7.6.1/docs/images/ab_c.svg b/versions/7.6.1/docs/images/ab_c.svg
new file mode 100644
index 00000000..bcc4563f
--- /dev/null
+++ b/versions/7.6.1/docs/images/ab_c.svg
@@ -0,0 +1,36 @@
+
+
+
+
+
+
+G
+
+
+
+a
+
+a
+
+
+
+b
+
+b
+
+
+
+a->b
+
+
+
+
+
+c
+
+c
+
+
+
+
diff --git a/versions/7.6.1/docs/images/allpaths.svg b/versions/7.6.1/docs/images/allpaths.svg
new file mode 100644
index 00000000..47d0ee33
--- /dev/null
+++ b/versions/7.6.1/docs/images/allpaths.svg
@@ -0,0 +1,141 @@
+
+
+
+
+
+
+allpaths
+
+
+
+n1
+
+
+
+
+n2
+
+
+
+
+n1->n2
+
+
+
+
+
+n3
+
+
+
+
+n2->n3
+
+
+
+
+
+n10
+
+
+
+
+n2->n10
+
+
+
+
+
+n3->n10
+
+
+
+
+
+n4
+
+E
+
+
+
+n5
+
+
+
+
+n6
+
+
+
+
+n5->n6
+
+
+
+
+
+n6->n4
+
+
+
+
+
+n9
+
+
+
+
+n6->n9
+
+
+
+
+
+n7
+
+S1
+
+
+
+n7->n2
+
+
+
+
+
+n7->n5
+
+
+
+
+
+n8
+
+S2
+
+
+
+n8->n6
+
+
+
+
+
+n10->n4
+
+
+
+
+
+n11
+
+
+
+
+n10->n11
+
+
+
+
+
diff --git a/versions/7.6.1/docs/images/android_instrumentation_test.png b/versions/7.6.1/docs/images/android_instrumentation_test.png
new file mode 100644
index 00000000..e4534fbd
Binary files /dev/null and b/versions/7.6.1/docs/images/android_instrumentation_test.png differ
diff --git a/versions/7.6.1/docs/images/android_ndk.png b/versions/7.6.1/docs/images/android_ndk.png
new file mode 100644
index 00000000..76b63cb3
Binary files /dev/null and b/versions/7.6.1/docs/images/android_ndk.png differ
diff --git a/versions/7.6.1/docs/images/android_tutorial_app.png b/versions/7.6.1/docs/images/android_tutorial_app.png
new file mode 100644
index 00000000..076be5b9
Binary files /dev/null and b/versions/7.6.1/docs/images/android_tutorial_app.png differ
diff --git a/versions/7.6.1/docs/images/android_tutorial_before.png b/versions/7.6.1/docs/images/android_tutorial_before.png
new file mode 100644
index 00000000..8e41d419
Binary files /dev/null and b/versions/7.6.1/docs/images/android_tutorial_before.png differ
diff --git a/versions/7.6.1/docs/images/bep-graph.png b/versions/7.6.1/docs/images/bep-graph.png
new file mode 100644
index 00000000..82da6715
Binary files /dev/null and b/versions/7.6.1/docs/images/bep-graph.png differ
diff --git a/versions/7.6.1/docs/images/bep-graph.svg b/versions/7.6.1/docs/images/bep-graph.svg
new file mode 100644
index 00000000..62b1480f
--- /dev/null
+++ b/versions/7.6.1/docs/images/bep-graph.svg
@@ -0,0 +1,4 @@
+
+
+
+
diff --git a/versions/7.6.1/docs/images/cpp-tutorial-stage1.png b/versions/7.6.1/docs/images/cpp-tutorial-stage1.png
new file mode 100644
index 00000000..c85fb303
Binary files /dev/null and b/versions/7.6.1/docs/images/cpp-tutorial-stage1.png differ
diff --git a/versions/7.6.1/docs/images/cpp-tutorial-stage2.png b/versions/7.6.1/docs/images/cpp-tutorial-stage2.png
new file mode 100644
index 00000000..80e202c9
Binary files /dev/null and b/versions/7.6.1/docs/images/cpp-tutorial-stage2.png differ
diff --git a/versions/7.6.1/docs/images/cpp-tutorial-stage3.png b/versions/7.6.1/docs/images/cpp-tutorial-stage3.png
new file mode 100644
index 00000000..54d82f31
Binary files /dev/null and b/versions/7.6.1/docs/images/cpp-tutorial-stage3.png differ
diff --git a/versions/7.6.1/docs/images/deps.svg b/versions/7.6.1/docs/images/deps.svg
new file mode 100644
index 00000000..4354222a
--- /dev/null
+++ b/versions/7.6.1/docs/images/deps.svg
@@ -0,0 +1,101 @@
+
+
+
+
+
+
+G1
+
+
+
+r1
+
+rule
+
+
+
+s1
+
+in
+
+
+
+r1->s1
+
+
+
+
+
+s2
+
+in
+
+
+
+r1->s2
+
+
+
+
+
+s3
+
+in
+
+
+
+r1->s3
+
+
+
+
+
+r2
+
+rule
+
+
+
+r2->r1
+
+
+
+
+
+s4
+
+in
+
+
+
+r2->s4
+
+
+
+
+
+o1
+
+out
+
+
+
+o1->r1
+
+
+
+
+
+o2
+
+out
+
+
+
+o2->r2
+
+
+
+
+
diff --git a/versions/7.6.1/docs/images/dyn-trace-alldynamic.png b/versions/7.6.1/docs/images/dyn-trace-alldynamic.png
new file mode 100644
index 00000000..fe36b253
Binary files /dev/null and b/versions/7.6.1/docs/images/dyn-trace-alldynamic.png differ
diff --git a/versions/7.6.1/docs/images/dyn-trace-javaconly.png b/versions/7.6.1/docs/images/dyn-trace-javaconly.png
new file mode 100644
index 00000000..2ae41e52
Binary files /dev/null and b/versions/7.6.1/docs/images/dyn-trace-javaconly.png differ
diff --git a/versions/7.6.1/docs/images/e4b-workflow.png b/versions/7.6.1/docs/images/e4b-workflow.png
new file mode 100644
index 00000000..412822da
Binary files /dev/null and b/versions/7.6.1/docs/images/e4b-workflow.png differ
diff --git a/versions/7.6.1/docs/images/e4b-workflow.svg b/versions/7.6.1/docs/images/e4b-workflow.svg
new file mode 100644
index 00000000..1de66e02
--- /dev/null
+++ b/versions/7.6.1/docs/images/e4b-workflow.svg
@@ -0,0 +1,4 @@
+
+
+
+
diff --git a/versions/7.6.1/docs/images/error_example_1.png b/versions/7.6.1/docs/images/error_example_1.png
new file mode 100644
index 00000000..07ba1358
Binary files /dev/null and b/versions/7.6.1/docs/images/error_example_1.png differ
diff --git a/versions/7.6.1/docs/images/error_example_2.png b/versions/7.6.1/docs/images/error_example_2.png
new file mode 100644
index 00000000..861171ee
Binary files /dev/null and b/versions/7.6.1/docs/images/error_example_2.png differ
diff --git a/versions/7.6.1/docs/images/error_example_3.png b/versions/7.6.1/docs/images/error_example_3.png
new file mode 100644
index 00000000..dc16eec4
Binary files /dev/null and b/versions/7.6.1/docs/images/error_example_3.png differ
diff --git a/versions/7.6.1/docs/images/error_example_4.png b/versions/7.6.1/docs/images/error_example_4.png
new file mode 100644
index 00000000..84383e63
Binary files /dev/null and b/versions/7.6.1/docs/images/error_example_4.png differ
diff --git a/versions/7.6.1/docs/images/graph_ex_1.svg b/versions/7.6.1/docs/images/graph_ex_1.svg
new file mode 100644
index 00000000..dd7427f4
--- /dev/null
+++ b/versions/7.6.1/docs/images/graph_ex_1.svg
@@ -0,0 +1,131 @@
+
+
+
+
+
+
+mygraph
+
+
+
+//net/proto_compiler:protocol-compiler
+
+//net/proto_compiler:protocol-compiler
+
+
+
+//net/proto_compiler:util
+
+//net/proto_compiler:util
+
+
+
+//net/proto_compiler:protocol-compiler->//net/proto_compiler:util
+
+
+
+
+
+//net/proto_compiler:protocol-compiler-lib
+
+//net/proto_compiler:protocol-compiler-lib
+
+
+
+//net/proto_compiler:protocol-compiler->//net/proto_compiler:protocol-compiler-lib
+
+
+
+
+
+//net/proto2/bridge/public:compiler_upgrader
+
+//net/proto2/bridge/public:compiler_upgrader
+
+
+
+//net/proto_compiler:protocol-compiler->//net/proto2/bridge/public:compiler_upgrader
+
+
+
+
+
+//net/proto_compiler:parser
+
+//net/proto_compiler:parser
+
+
+
+//net/proto_compiler:util->//net/proto_compiler:parser
+
+
+
+
+
+//net/proto_compiler:proto-min-lib
+
+//net/proto_compiler:proto-min-lib
+
+
+
+//net/proto_compiler:protocol-compiler-lib->//net/proto_compiler:proto-min-lib
+
+
+
+
+
+//net/proto_compiler:protocol-compiler-lib->//net/proto_compiler:parser
+
+
+
+
+
+//net/proto2/bridge/internal:compiler_upgrader
+
+//net/proto2/bridge/internal:compiler_upgrader
+
+
+
+//net/proto2/bridge/public:compiler_upgrader->//net/proto2/bridge/internal:compiler_upgrader
+
+
+
+
+
+//net/proto_compiler:proto-min-lib->//net/proto_compiler:parser
+
+
+
+
+
+//util/regexp:regexp
+
+//util/regexp:regexp
+
+
+
+//net/proto_compiler:proto-min-lib->//util/regexp:regexp
+
+
+
+
+
+//net/proto_compiler:parser->//util/regexp:regexp
+
+
+
+
+
+//net/proto2/bridge/internal:compiler_upgrader->//net/proto2/bridge/public:compiler_upgrader
+
+
+
+
+
+//net/proto2/bridge/internal:compiler_upgrader->//net/proto_compiler:parser
+
+
+
+
+
diff --git a/versions/7.6.1/docs/images/graph_hello-world.svg b/versions/7.6.1/docs/images/graph_hello-world.svg
new file mode 100644
index 00000000..93b61444
--- /dev/null
+++ b/versions/7.6.1/docs/images/graph_hello-world.svg
@@ -0,0 +1,70 @@
+
+
+
+
+
+
+mygraph
+
+
+//main:hello-world
+
+//main:hello-world
+
+
+//main:hello-time
+
+//main:hello-time
+
+
+//main:hello-world->//main:hello-time
+
+
+
+
+//main:hello-world.cc
+
+//main:hello-world.cc
+
+
+//main:hello-world->//main:hello-world.cc
+
+
+
+
+//lib:hello-greet
+
+//lib:hello-greet
+
+
+//main:hello-world->//lib:hello-greet
+
+
+
+
+//main:hello-time.cc\n//main:hello-time.h
+
+//main:hello-time.cc
+//main:hello-time.h
+
+
+//main:hello-time->//main:hello-time.cc\n//main:hello-time.h
+
+
+
+
+//lib:hello-greet.cc\n//lib:hello-greet.h
+
+//lib:hello-greet.cc
+//lib:hello-greet.h
+
+
+//lib:hello-greet->//lib:hello-greet.cc\n//lib:hello-greet.h
+
+
+
+
+
diff --git a/versions/7.6.1/docs/images/json-trace-profile-network-usage.png b/versions/7.6.1/docs/images/json-trace-profile-network-usage.png
new file mode 100644
index 00000000..8a7500a6
Binary files /dev/null and b/versions/7.6.1/docs/images/json-trace-profile-network-usage.png differ
diff --git a/versions/7.6.1/docs/images/json-trace-profile-system-load-average.png b/versions/7.6.1/docs/images/json-trace-profile-system-load-average.png
new file mode 100644
index 00000000..e71b420c
Binary files /dev/null and b/versions/7.6.1/docs/images/json-trace-profile-system-load-average.png differ
diff --git a/versions/7.6.1/docs/images/json-trace-profile-workers-memory-usage.png b/versions/7.6.1/docs/images/json-trace-profile-workers-memory-usage.png
new file mode 100644
index 00000000..806505f0
Binary files /dev/null and b/versions/7.6.1/docs/images/json-trace-profile-workers-memory-usage.png differ
diff --git a/versions/7.6.1/docs/images/json-trace-profile.png b/versions/7.6.1/docs/images/json-trace-profile.png
new file mode 100644
index 00000000..538382b2
Binary files /dev/null and b/versions/7.6.1/docs/images/json-trace-profile.png differ
diff --git a/versions/7.6.1/docs/images/mobile-install-performance.svg b/versions/7.6.1/docs/images/mobile-install-performance.svg
new file mode 100644
index 00000000..b139d658
--- /dev/null
+++ b/versions/7.6.1/docs/images/mobile-install-performance.svg
@@ -0,0 +1,86 @@
+
+
+
+  
+    
+      
+    
+  
+  
+  
+    Build times
+  
+  
+    
+    
+      
+      
+        adb install
+      
+      
+    
+    
+      
+      
+        mobile-install
+      
+      
+    
+  
+  
+    
+    
+      
+        
+        
+        
+        
+        
+      
+      
+        
+        
+        
+        
+        
+        
+      
+      
+        
+      
+    
+    
+    
+      
+        Google Maps
+      
+      
+        Google+
+      
+      
+        YouTube
+      
+      
+        0
+      
+      
+        75
+      
+      
+        150
+      
+      
+        225
+      
+      
+        300
+      
+    
+  
+  
+    
+      Seconds
+    
+  
+  
+
diff --git a/versions/7.6.1/docs/images/namedsetoffiles-bep-graph.png b/versions/7.6.1/docs/images/namedsetoffiles-bep-graph.png
new file mode 100644
index 00000000..ea1e10cc
Binary files /dev/null and b/versions/7.6.1/docs/images/namedsetoffiles-bep-graph.png differ
diff --git a/versions/7.6.1/docs/images/out-ranked.svg b/versions/7.6.1/docs/images/out-ranked.svg
new file mode 100644
index 00000000..07e96804
--- /dev/null
+++ b/versions/7.6.1/docs/images/out-ranked.svg
@@ -0,0 +1,71 @@
+
+
+
+
+
+
+mygraph
+
+
+
+//a:a
+
+//a:a
+
+
+
+//a:a.cc
+
+//a:a.cc
+
+
+
+//a:a->//a:a.cc
+
+
+
+
+
+//b:b
+
+//b:b
+
+
+
+//b:b->//a:a
+
+
+
+
+
+//b:b.cc
+
+//b:b.cc
+
+
+
+//b:b->//b:b.cc
+
+
+
+
+
+//c:c
+
+//c:c
+
+
+
+//c:c->//a:a
+
+
+
+
+
+//c:c->//b:b
+
+
+
+
+
diff --git a/versions/7.6.1/docs/images/rbe-ci-1.png b/versions/7.6.1/docs/images/rbe-ci-1.png
new file mode 100644
index 00000000..fbe76a85
Binary files /dev/null and b/versions/7.6.1/docs/images/rbe-ci-1.png differ
diff --git a/versions/7.6.1/docs/images/rbe-ci-2.png b/versions/7.6.1/docs/images/rbe-ci-2.png
new file mode 100644
index 00000000..07611889
Binary files /dev/null and b/versions/7.6.1/docs/images/rbe-ci-2.png differ
diff --git a/versions/7.6.1/docs/images/somepath1.svg b/versions/7.6.1/docs/images/somepath1.svg
new file mode 100644
index 00000000..5e5f8812
--- /dev/null
+++ b/versions/7.6.1/docs/images/somepath1.svg
@@ -0,0 +1,141 @@
+
+
+
+
+
+
+somepath1
+
+
+
+n1
+
+
+
+
+n2
+
+
+
+
+n1->n2
+
+
+
+
+
+n3
+
+
+
+
+n2->n3
+
+
+
+
+
+n10
+
+
+
+
+n2->n10
+
+
+
+
+
+n3->n10
+
+
+
+
+
+n4
+
+E
+
+
+
+n5
+
+
+
+
+n6
+
+
+
+
+n5->n6
+
+
+
+
+
+n6->n4
+
+
+
+
+
+n9
+
+
+
+
+n6->n9
+
+
+
+
+
+n7
+
+S1
+
+
+
+n7->n2
+
+
+
+
+
+n7->n5
+
+
+
+
+
+n8
+
+S2
+
+
+
+n8->n6
+
+
+
+
+
+n10->n4
+
+
+
+
+
+n11
+
+
+
+
+n10->n11
+
+
+
+
+
diff --git a/versions/7.6.1/docs/images/somepath2.svg b/versions/7.6.1/docs/images/somepath2.svg
new file mode 100644
index 00000000..911f2c9b
--- /dev/null
+++ b/versions/7.6.1/docs/images/somepath2.svg
@@ -0,0 +1,141 @@
+
+
+
+
+
+
+somepath2
+
+
+
+n1
+
+
+
+
+n2
+
+
+
+
+n1->n2
+
+
+
+
+
+n3
+
+
+
+
+n2->n3
+
+
+
+
+
+n10
+
+
+
+
+n2->n10
+
+
+
+
+
+n3->n10
+
+
+
+
+
+n4
+
+E
+
+
+
+n5
+
+
+
+
+n6
+
+
+
+
+n5->n6
+
+
+
+
+
+n6->n4
+
+
+
+
+
+n9
+
+
+
+
+n6->n9
+
+
+
+
+
+n7
+
+S1
+
+
+
+n7->n2
+
+
+
+
+
+n7->n5
+
+
+
+
+
+n8
+
+S2
+
+
+
+n8->n6
+
+
+
+
+
+n10->n4
+
+
+
+
+
+n11
+
+
+
+
+n10->n11
+
+
+
+
+
diff --git a/versions/7.6.1/docs/images/targets.svg b/versions/7.6.1/docs/images/targets.svg
new file mode 100644
index 00000000..82f47e74
--- /dev/null
+++ b/versions/7.6.1/docs/images/targets.svg
@@ -0,0 +1,113 @@
+
+
+
+
+
+
+G1
+
+
+
+Target
+
+Target
+
+
+
+Rule
+
+Rule
+
+
+
+Target->Rule
+
+
+
+
+
+File
+
+File
+
+
+
+Target->File
+
+
+
+
+
+Package group
+
+Package group
+
+
+
+Target->Package group
+
+
+
+
+
+cc_library
+
+cc_library
+
+
+
+Rule->cc_library
+
+
+
+
+
+java_test
+
+java_test
+
+
+
+Rule->java_test
+
+
+
+
+
+...
+
+...
+
+
+
+Rule->...
+
+
+
+
+
+Source
+
+Source
+
+
+
+File->Source
+
+
+
+
+
+Generated
+
+Generated
+
+
+
+File->Generated
+
+
+
+
+
diff --git a/versions/7.6.1/docs/images/tutorial_java_01.svg b/versions/7.6.1/docs/images/tutorial_java_01.svg
new file mode 100644
index 00000000..2fe72f36
--- /dev/null
+++ b/versions/7.6.1/docs/images/tutorial_java_01.svg
@@ -0,0 +1,29 @@
+
+
+
+
+
+
+mygraph
+
+
+//:ProjectRunner
+
+//:ProjectRunner
+
+
+//:src/main/java/com/example/Greeting.java\n//:src/main/java/com/example/ProjectRunner.java
+
+//:src/main/java/com/example/Greeting.java
+//:src/main/java/com/example/ProjectRunner.java
+
+
+//:ProjectRunner->//:src/main/java/com/example/Greeting.java\n//:src/main/java/com/example/ProjectRunner.java
+
+
+
+
+
diff --git a/versions/7.6.1/docs/images/tutorial_java_02.svg b/versions/7.6.1/docs/images/tutorial_java_02.svg
new file mode 100644
index 00000000..40cbb218
--- /dev/null
+++ b/versions/7.6.1/docs/images/tutorial_java_02.svg
@@ -0,0 +1,48 @@
+
+
+
+
+
+
+mygraph
+
+
+//:ProjectRunner
+
+//:ProjectRunner
+
+
+//:greeter
+
+//:greeter
+
+
+//:ProjectRunner->//:greeter
+
+
+
+
+//:src/main/java/com/example/ProjectRunner.java
+
+//:src/main/java/com/example/ProjectRunner.java
+
+
+//:ProjectRunner->//:src/main/java/com/example/ProjectRunner.java
+
+
+
+
+//:src/main/java/com/example/Greeting.java
+
+//:src/main/java/com/example/Greeting.java
+
+
+//:greeter->//:src/main/java/com/example/Greeting.java
+
+
+
+
+
diff --git a/versions/7.6.1/docs/images/tutorial_java_03.svg b/versions/7.6.1/docs/images/tutorial_java_03.svg
new file mode 100644
index 00000000..7d79041a
--- /dev/null
+++ b/versions/7.6.1/docs/images/tutorial_java_03.svg
@@ -0,0 +1,48 @@
+
+
+
+
+
+
+mygraph
+
+
+//src/main/java/com/example/cmdline:runner
+
+//src/main/java/com/example/cmdline:runner
+
+
+//src/main/java/com/example/cmdline:Runner.java
+
+//src/main/java/com/example/cmdline:Runner.java
+
+
+//src/main/java/com/example/cmdline:runner->//src/main/java/com/example/cmdline:Runner.java
+
+
+
+
+//:greeter
+
+//:greeter
+
+
+//src/main/java/com/example/cmdline:runner->//:greeter
+
+
+
+
+//:src/main/java/com/example/Greeting.java
+
+//:src/main/java/com/example/Greeting.java
+
+
+//:greeter->//:src/main/java/com/example/Greeting.java
+
+
+
+
+
diff --git a/versions/7.6.1/docs/images/workers-clean-chart.png b/versions/7.6.1/docs/images/workers-clean-chart.png
new file mode 100644
index 00000000..63526fc1
Binary files /dev/null and b/versions/7.6.1/docs/images/workers-clean-chart.png differ
diff --git a/versions/7.6.1/docs/images/workers-incremental-chart.png b/versions/7.6.1/docs/images/workers-incremental-chart.png
new file mode 100644
index 00000000..1c62d25c
Binary files /dev/null and b/versions/7.6.1/docs/images/workers-incremental-chart.png differ
diff --git a/versions/7.6.1/docs/images/ws-diamond.png b/versions/7.6.1/docs/images/ws-diamond.png
new file mode 100644
index 00000000..154a7440
Binary files /dev/null and b/versions/7.6.1/docs/images/ws-diamond.png differ
diff --git a/versions/7.6.1/docs/images/ws-line.png b/versions/7.6.1/docs/images/ws-line.png
new file mode 100644
index 00000000..e8bfe7a1
Binary files /dev/null and b/versions/7.6.1/docs/images/ws-line.png differ
diff --git a/versions/7.6.1/docs/images/ws-multiline.png b/versions/7.6.1/docs/images/ws-multiline.png
new file mode 100644
index 00000000..f07b43b1
Binary files /dev/null and b/versions/7.6.1/docs/images/ws-multiline.png differ
diff --git a/versions/7.6.1/docs/sandboxing.mdx b/versions/7.6.1/docs/sandboxing.mdx
index 4b48c108..4bf6c378 100644
--- a/versions/7.6.1/docs/sandboxing.mdx
+++ b/versions/7.6.1/docs/sandboxing.mdx
@@ -48,7 +48,7 @@ containers on Linux and `sandbox-exec` on macOS, to constrain the action within
 ## What sandbox strategy to use {#sandboxing-strategies}
 
 You can choose which kind of sandboxing to use, if any, with the
-[strategy flags](user-manual#strategy-options). Using the `sandboxed`
+[strategy flags](/versions/7.6.1/docs/user-manual#strategy-options). Using the `sandboxed`
 strategy makes Bazel pick one of the sandbox implementations listed below,
 preferring an OS-specific sandbox to the less hermetic generic one.
 [Persistent workers](/versions/7.6.1/remote/persistent) run in a generic sandbox if you pass
diff --git a/versions/7.6.1/docs/user-manual.mdx b/versions/7.6.1/docs/user-manual.mdx
index 04a86b67..6ef65616 100644
--- a/versions/7.6.1/docs/user-manual.mdx
+++ b/versions/7.6.1/docs/user-manual.mdx
@@ -1162,12 +1162,12 @@ during execution can be examined.
 This option causes Bazel's execution phase to print the full command line
 for each command prior to executing it.
 
-
-  >>>>> # //examples/cpp:hello-world [action 'Linking examples/cpp/hello-world']
+```
+  >>>> # //examples/cpp:hello-world [action 'Linking examples/cpp/hello-world']
   (cd /home/johndoe/.cache/bazel/_bazel_johndoe/4c084335afceb392cfbe7c31afee3a9f/bazel && \
     exec env - \
     /usr/bin/gcc -o bazel-out/local-fastbuild/bin/examples/cpp/hello-world -B/usr/bin/ -Wl,-z,relro,-z,now -no-canonical-prefixes -pass-exit-codes -Wl,-S -Wl,@bazel-out/local_linux-fastbuild/bin/examples/cpp/hello-world-2.params)
-

+```
 
 Where possible, commands are printed in a Bourne shell compatible syntax,
 so that they can be easily copied and pasted to a shell command prompt.
diff --git a/versions/7.6.1/extending/depsets.mdx b/versions/7.6.1/extending/depsets.mdx
index dab55b2a..0a59c013 100644
--- a/versions/7.6.1/extending/depsets.mdx
+++ b/versions/7.6.1/extending/depsets.mdx
@@ -111,8 +111,7 @@ need to ensure that if `B` depends on `A`, then `A.o` comes before `B.o` on the
 linker’s command line. Other tools might have the opposite requirement.
 
 Three traversal orders are supported: `postorder`, `preorder`, and
-`topological`. The first two work exactly like [tree
-traversals](https://en.wikipedia.org/wiki/Tree_traversal#Depth-first_search)
+`topological`. The first two work exactly like [tree traversals](https://en.wikipedia.org/wiki/Tree_traversal#Depth-first_search)
 except that they operate on DAGs and skip already visited nodes. The third order
 works as a topological sort from root to leaves, essentially the same as
 preorder except that shared children are listed only after all of their parents.
diff --git a/versions/7.6.1/extending/exec-groups.mdx b/versions/7.6.1/extending/exec-groups.mdx
index 7ffb8b2d..f6bdc2ff 100644
--- a/versions/7.6.1/extending/exec-groups.mdx
+++ b/versions/7.6.1/extending/exec-groups.mdx
@@ -63,8 +63,7 @@ test rules.
 
 In the rule implementation, you can declare that actions should be run on the
 execution platform of an execution group. You can do this by using the `exec_group`
-param of action generating methods, specifically [`ctx.actions.run`]
-(/rules/lib/builtins/actions#run) and
+param of action generating methods, specifically [`ctx.actions.run`](/versions/7.6.1/rules/lib/builtins/actions#run) and
 [`ctx.actions.run_shell`](/versions/7.6.1/rules/lib/builtins/actions#run_shell).
 
 ```python
diff --git a/versions/7.6.1/extending/macros.mdx b/versions/7.6.1/extending/macros.mdx
index dbbddf10..dbb36f6d 100644
--- a/versions/7.6.1/extending/macros.mdx
+++ b/versions/7.6.1/extending/macros.mdx
@@ -139,7 +139,7 @@ Note that `native` can only be used in `.bzl` files, and not in `BUILD` files.
 
 ## Label resolution in macros
 
-Since macros are evaluated in the [loading phase](concepts.md#evaluation-model),
+Since macros are evaluated in the [loading phase](/versions/7.6.1/extending/concepts#evaluation-model),
 label strings such as `"//foo:bar"` that occur in a macro are interpreted
 relative to the `BUILD` file in which the macro is used rather than relative to
 the `.bzl` file in which it is defined. This behavior is generally undesirable
@@ -212,8 +212,7 @@ def my_macro(name, deps, visibility=None):
     instantiate rules must have a `name` argument. This argument should not be
     optional (don't give a default value).
 
-*   Public functions should use a docstring following [Python
-    conventions](https://www.python.org/dev/peps/pep-0257/#one-line-docstrings).
+*   Public functions should use a docstring following [Python conventions](https://www.python.org/dev/peps/pep-0257/#one-line-docstrings).
 
 *   In `BUILD` files, the `name` argument of the macros must be a keyword
     argument (not a positional argument).
diff --git a/versions/7.6.1/extending/platforms.mdx b/versions/7.6.1/extending/platforms.mdx
index 63057f12..e92c723c 100644
--- a/versions/7.6.1/extending/platforms.mdx
+++ b/versions/7.6.1/extending/platforms.mdx
@@ -245,8 +245,7 @@ cc_library(
 
 You can use the
 [`IncompatiblePlatformProvider`](/versions/7.6.1/rules/lib/providers/IncompatiblePlatformProvider)
-in `bazel cquery`'s [Starlark output
-format](/versions/7.6.1/query/cquery#output-format-definition) to distinguish
+in `bazel cquery`'s [Starlark output format](/versions/7.6.1/query/cquery#output-format-definition) to distinguish
 incompatible targets from compatible ones.
 
 This can be used to filter out incompatible targets. The example below will
@@ -266,5 +265,4 @@ $ bazel cquery //... --output=starlark --starlark:file=example.cquery
 
 ### Known Issues
 
-Incompatible targets [ignore visibility
-restrictions](https://github.com/bazelbuild/bazel/issues/16044).
+Incompatible targets [ignore visibility restrictions](https://github.com/bazelbuild/bazel/issues/16044).
diff --git a/versions/7.6.1/extending/repo.mdx b/versions/7.6.1/extending/repo.mdx
index 1f091434..73d1b390 100644
--- a/versions/7.6.1/extending/repo.mdx
+++ b/versions/7.6.1/extending/repo.mdx
@@ -74,8 +74,7 @@ specified.
 
 The input parameter `repository_ctx` can be used to access attribute values, and
 non-hermetic functions (finding a binary, executing a binary, creating a file in
-the repository or downloading a file from the Internet). See [the API
-docs](/versions/7.6.1/rules/lib/builtins/repository_ctx) for more context. Example:
+the repository or downloading a file from the Internet). See [the API docs](/versions/7.6.1/rules/lib/builtins/repository_ctx) for more context. Example:
 
 ```python
 def _impl(repository_ctx):
@@ -144,8 +143,7 @@ definition has the `configure` attribute set, use `bazel fetch --force
 
 ## Examples
 
--   [C++ auto-configured
-    toolchain](https://cs.opensource.google/bazel/bazel/+/master:tools/cpp/cc_configure.bzl;drc=644b7d41748e09eff9e47cbab2be2263bb71f29a;l=176):
+-   [C++ auto-configured toolchain](https://cs.opensource.google/bazel/bazel/+/master:tools/cpp/cc_configure.bzl;drc=644b7d41748e09eff9e47cbab2be2263bb71f29a;l=176):
     it uses a repo rule to automatically create the C++ configuration files for
     Bazel by looking for the local C++ compiler, the environment and the flags
     the C++ compiler supports.
diff --git a/versions/7.6.1/extending/rules.mdx b/versions/7.6.1/extending/rules.mdx
index fe64dfb4..31a3ef37 100644
--- a/versions/7.6.1/extending/rules.mdx
+++ b/versions/7.6.1/extending/rules.mdx
@@ -462,8 +462,7 @@ def _example_library_impl(ctx):
 
 If `DefaultInfo` is not returned by a rule implementation or the `files`
 parameter is not specified, `DefaultInfo.files` defaults to all
-*predeclared outputs* (generally, those created by [output
-attributes](#output_attributes)).
+*predeclared outputs* (generally, those created by [output attributes](#output_attributes)).
 
 Rules that perform actions should provide default outputs, even if those outputs
 are not expected to be directly used. Actions that are not in the graph of the
diff --git a/versions/7.6.1/external/advanced.mdx b/versions/7.6.1/external/advanced.mdx
index 5fa44562..a93d379c 100644
--- a/versions/7.6.1/external/advanced.mdx
+++ b/versions/7.6.1/external/advanced.mdx
@@ -4,10 +4,8 @@ title: 'Advanced topics on external dependencies'
 
 ## Shadowing dependencies in WORKSPACE
 
-Note: This section applies to the [WORKSPACE
-system](/versions/7.6.1/external/overview#workspace-system) only. For
-[Bzlmod](/versions/7.6.1/external/overview#bzlmod), use a [multiple-version
-override](/versions/7.6.1/external/module#multiple-version_override).
+Note: This section applies to the [WORKSPACE system](/versions/7.6.1/external/overview#workspace-system) only. For
+[Bzlmod](/versions/7.6.1/external/overview#bzlmod), use a [multiple-version override](/versions/7.6.1/external/module#multiple-version_override).
 
 Whenever possible, have a single version policy in your project, which is
 required for dependencies that you compile against and end up in your final
@@ -128,29 +126,24 @@ preferring IPv4 if enabled. In some situations, for example when the IPv4
 network cannot resolve/reach external addresses, this can cause `Network
 unreachable` exceptions and build failures. In these cases, you can override
 Bazel's behavior to prefer IPv6 by using the
-[`java.net.preferIPv6Addresses=true` system
-property](https://docs.oracle.com/javase/8/docs/api/java/net/doc-files/net-properties.html).
+[`java.net.preferIPv6Addresses=true` system property](https://docs.oracle.com/javase/8/docs/api/java/net/doc-files/net-properties.html).
 Specifically:
 
-*   Use `--host_jvm_args=-Djava.net.preferIPv6Addresses=true` [startup
-    option](/versions/7.6.1/docs/user-manual#startup-options), for example by adding the
+*   Use `--host_jvm_args=-Djava.net.preferIPv6Addresses=true` [startup option](/versions/7.6.1/docs/user-manual#startup-options), for example by adding the
     following line in your [`.bazelrc` file](/versions/7.6.1/run/bazelrc):
 
     `startup --host_jvm_args=-Djava.net.preferIPv6Addresses=true`
 
 *   When running Java build targets that need to connect to the internet (such
     as for integration tests), use the
-    `--jvmopt=-Djava.net.preferIPv6Addresses=true` [tool
-    flag](/versions/7.6.1/docs/user-manual#jvmopt). For example, include in your [`.bazelrc`
-    file](/versions/7.6.1/run/bazelrc):
+    `--jvmopt=-Djava.net.preferIPv6Addresses=true` [tool flag](/versions/7.6.1/docs/user-manual#jvmopt). For example, include in your [`.bazelrc` file](/versions/7.6.1/run/bazelrc):
 
     `build --jvmopt=-Djava.net.preferIPv6Addresses`
 
 *   If you are using [`rules_jvm_external`](https://github.com/bazelbuild/rules_jvm_external)
     for dependency version resolution, also add
     `-Djava.net.preferIPv6Addresses=true` to the `COURSIER_OPTS` environment
-    variable to [provide JVM options for
-    Coursier](https://github.com/bazelbuild/rules_jvm_external#provide-jvm-options-for-coursier-with-coursier_opts).
+    variable to [provide JVM options for Coursier](https://github.com/bazelbuild/rules_jvm_external#provide-jvm-options-for-coursier-with-coursier_opts).
 
 ## Offline builds
 
@@ -167,15 +160,12 @@ fetch a file with [`ctx.download`](/versions/7.6.1/rules/lib/builtins/repository
 providing a hash sum of the file needed, Bazel looks for a file matching the
 basename of the first URL, and uses the local copy if the hash matches.
 
-Bazel itself uses this technique to bootstrap offline from the [distribution
-artifact](https://github.com/bazelbuild/bazel-website/blob/master/designs/_posts/2016-10-11-distribution-artifact.md).
-It does so by [collecting all the needed external
-dependencies](https://github.com/bazelbuild/bazel/blob/5cfa0303d6ac3b5bd031ff60272ce80a704af8c2/WORKSPACE#L116)
+Bazel itself uses this technique to bootstrap offline from the [distribution artifact](https://github.com/bazelbuild/bazel-website/blob/master/designs/_posts/2016-10-11-distribution-artifact.md).
+It does so by [collecting all the needed external dependencies](https://github.com/bazelbuild/bazel/blob/5cfa0303d6ac3b5bd031ff60272ce80a704af8c2/WORKSPACE#L116)
 in an internal
 [`distdir_tar`](https://github.com/bazelbuild/bazel/blob/5cfa0303d6ac3b5bd031ff60272ce80a704af8c2/distdir.bzl#L44).
 
 Bazel allows execution of arbitrary commands in repository rules without knowing
 if they call out to the network, and so cannot enforce fully offline builds. To
 test if a build works correctly offline, manually block off the network (as
-Bazel does in its [bootstrap
-test](https://cs.opensource.google/bazel/bazel/+/master:src/test/shell/bazel/BUILD;l=1073;drc=88c426e73cc0eb0a41c0d7995e36acd94e7c9a48)).
\ No newline at end of file
+Bazel does in its [bootstrap test](https://cs.opensource.google/bazel/bazel/+/master:src/test/shell/bazel/BUILD;l=1073;drc=88c426e73cc0eb0a41c0d7995e36acd94e7c9a48)).
\ No newline at end of file
diff --git a/versions/7.6.1/external/images/mod_exampleBefore.svg b/versions/7.6.1/external/images/mod_exampleBefore.svg
new file mode 100644
index 00000000..66f01303
--- /dev/null
+++ b/versions/7.6.1/external/images/mod_exampleBefore.svg
@@ -0,0 +1,175 @@
+
+
+
+
+
+
+mygraph
+
+
+
+<root>
+
+<root> (my_project@1.0)
+
+
+
+bazel_skylib@1.1.1
+
+bazel_skylib@1.1.1
+
+
+
+<root>->bazel_skylib@1.1.1
+
+
+
+
+
+bazel_skylib@1.2.0
+
+bazel_skylib@1.2.0
+
+
+
+<root>->bazel_skylib@1.2.0
+
+
+
+
+
+rules_java@5.0.0
+
+rules_java@5.0.0
+
+
+
+<root>->rules_java@5.0.0
+
+
+
+
+
+stardoc@0.5.0
+
+stardoc@0.5.0
+
+
+
+<root>->stardoc@0.5.0
+
+
+
+
+
+platforms@0.0.4
+
+platforms@0.0.4
+
+
+
+bazel_skylib@1.1.1->platforms@0.0.4
+
+
+
+
+
+bazel_skylib@1.2.0->platforms@0.0.4
+
+
+
+
+
+rules_java@5.0.0->platforms@0.0.4
+
+
+
+
+
+rules_cc@0.0.1
+
+rules_cc@0.0.1
+
+
+
+rules_java@5.0.0->rules_cc@0.0.1
+
+
+
+
+
+rules_proto@4.0.0
+
+rules_proto@4.0.0
+
+
+
+rules_java@5.0.0->rules_proto@4.0.0
+
+
+
+
+
+bazel_skylib@1.0.3
+
+bazel_skylib@1.0.3
+
+
+
+stardoc@0.5.0->bazel_skylib@1.0.3
+
+
+
+
+
+rules_java@4.0.0
+
+rules_java@4.0.0
+
+
+
+stardoc@0.5.0->rules_java@4.0.0
+
+
+
+
+
+rules_cc@0.0.1->platforms@0.0.4
+
+
+
+
+
+rules_cc@0.0.1->bazel_skylib@1.0.3
+
+
+
+
+
+rules_proto@4.0.0->rules_cc@0.0.1
+
+
+
+
+
+rules_proto@4.0.0->bazel_skylib@1.0.3
+
+
+
+
+
+bazel_skylib@1.0.3->platforms@0.0.4
+
+
+
+
+
+rules_java@4.0.0->bazel_skylib@1.0.3
+
+
+
+
+
\ No newline at end of file
diff --git a/versions/7.6.1/external/images/mod_exampleResolved.svg b/versions/7.6.1/external/images/mod_exampleResolved.svg
new file mode 100644
index 00000000..224b694c
--- /dev/null
+++ b/versions/7.6.1/external/images/mod_exampleResolved.svg
@@ -0,0 +1,151 @@
+
+
+
+
+
+
+mygraph
+
+
+
+<root>
+
+<root> (my_project@1.0)
+
+
+
+bazel_skylib@1.1.1
+
+bazel_skylib@1.1.1
+
+
+
+<root>->bazel_skylib@1.1.1
+
+
+
+
+
+bazel_skylib@1.2.0
+
+bazel_skylib@1.2.0
+
+
+
+<root>->bazel_skylib@1.2.0
+
+
+
+
+
+rules_java@5.0.0
+
+rules_java@5.0.0
+
+
+
+<root>->rules_java@5.0.0
+
+
+
+
+
+stardoc@0.5.0
+
+stardoc@0.5.0
+
+
+
+<root>->stardoc@0.5.0
+
+
+
+
+
+platforms@0.0.4
+
+platforms@0.0.4
+
+
+
+bazel_skylib@1.1.1->platforms@0.0.4
+
+
+
+
+
+bazel_skylib@1.2.0->platforms@0.0.4
+
+
+
+
+
+rules_java@5.0.0->platforms@0.0.4
+
+
+
+
+
+rules_cc@0.0.1
+
+rules_cc@0.0.1
+
+
+
+rules_java@5.0.0->rules_cc@0.0.1
+
+
+
+
+
+rules_proto@4.0.0
+
+rules_proto@4.0.0
+
+
+
+rules_java@5.0.0->rules_proto@4.0.0
+
+
+
+
+
+stardoc@0.5.0->bazel_skylib@1.1.1
+
+
+
+
+
+stardoc@0.5.0->rules_java@5.0.0
+
+
+
+
+
+rules_cc@0.0.1->bazel_skylib@1.1.1
+
+
+
+
+
+rules_cc@0.0.1->platforms@0.0.4
+
+
+
+
+
+rules_proto@4.0.0->bazel_skylib@1.1.1
+
+
+
+
+
+rules_proto@4.0.0->rules_cc@0.0.1
+
+
+
+
+
\ No newline at end of file
diff --git a/versions/7.6.1/external/migration.mdx b/versions/7.6.1/external/migration.mdx
index 6aa95faf..c6c61d66 100644
--- a/versions/7.6.1/external/migration.mdx
+++ b/versions/7.6.1/external/migration.mdx
@@ -2,8 +2,7 @@
 title: 'Bzlmod Migration Guide'
 ---
 
-Due to the [shortcomings of
-WORKSPACE](/versions/7.6.1/external/overview#workspace-shortcomings), Bzlmod is going to
+Due to the [shortcomings of WORKSPACE](/versions/7.6.1/external/overview#workspace-shortcomings), Bzlmod is going to
 replace the legacy WORKSPACE system in future Bazel releases. This guide helps
 you migrate your project to Bzlmod and drop WORKSPACE for fetching external
 dependencies.
@@ -116,9 +115,7 @@ Bazel module when it also adopts Bzlmod.
 
 *   **Bzlmod**
 
-    With Bzlmod, as long as the your dependency is available in [Bazel Central
-    Registry](https://registry.bazel.build) or your custom [Bazel
-    registry](/versions/7.6.1/external/registry), you can simply depend on it with a
+    With Bzlmod, as long as the your dependency is available in [Bazel Central Registry](https://registry.bazel.build) or your custom [Bazel registry](/versions/7.6.1/external/registry), you can simply depend on it with a
     [`bazel_dep`](/versions/7.6.1/rules/lib/globals/module#bazel_dep) directive.
 
     ```python
@@ -149,8 +146,7 @@ repository.
 
 If your dependency is not a Bazel project or not yet available in any Bazel
 registry, you can introduce it using
-[`use_repo_rule`](/versions/7.6.1/external/module#use_repo_rule) or [module
-extensions](/versions/7.6.1/external/extension).
+[`use_repo_rule`](/versions/7.6.1/external/module#use_repo_rule) or [module extensions](/versions/7.6.1/external/extension).
 
 *   **WORKSPACE**
 
@@ -583,8 +579,7 @@ macros.
 Fortunately, the flag
 [`--experimental_repository_resolved_file`][resolved_file_flag]
 can help. This flag essentially generates a "lock file" of all fetched external
-dependencies in your last Bazel command. You can find more details in this [blog
-post](https://blog.bazel.build/2018/07/09/bazel-sync-and-resolved-file.html).
+dependencies in your last Bazel command. You can find more details in this [blog post](https://blog.bazel.build/2018/07/09/bazel-sync-and-resolved-file.html).
 
 [resolved_file_flag]: /reference/command-line-reference#flag--experimental_repository_resolved_file
 
@@ -625,11 +620,9 @@ You may also know `bazel query` can be used for inspecting repository rules with
 bazel query --output=build //external:
 ```
 
-While it is more convenient and much faster, [bazel query can lie about
-external dependency version](https://github.com/bazelbuild/bazel/issues/12947),
+While it is more convenient and much faster, [bazel query can lie about external dependency version](https://github.com/bazelbuild/bazel/issues/12947),
 so be careful using it! Querying and inspecting external
-dependencies with Bzlmod is going to achieved by a [new
-subcommand](https://github.com/bazelbuild/bazel/issues/15365).
+dependencies with Bzlmod is going to achieved by a [new subcommand](https://github.com/bazelbuild/bazel/issues/15365).
 
 #### Built-in default dependencies {#builtin-default-deps}
 
@@ -676,8 +669,7 @@ your workspace root.
 #### Repository visibility {#repository-visibility}
 
 Bzlmod is able to control which other repositories are visible from a given
-repository, check [repository names and strict
-deps](/versions/7.6.1/external/module#repository_names_and_strict_deps) for more details.
+repository, check [repository names and strict deps](/versions/7.6.1/external/module#repository_names_and_strict_deps) for more details.
 
 Here is a summary of repository visibilities from different types of
 repositories when also taking WORKSPACE into consideration.
@@ -690,8 +682,7 @@ repositories when also taking WORKSPACE into consideration.
 | WORKSPACE Repos | All visible | Not visible | Not visible | All visible |
 
 Note: For the root module, if a repository `@foo` is defined in WORKSPACE and
-`@foo` is also used as an [apparent repository
-name](/versions/7.6.1/external/overview#apparent-repo-name) in MODULE.bazel, then `@foo`
+`@foo` is also used as an [apparent repository name](/versions/7.6.1/external/overview#apparent-repo-name) in MODULE.bazel, then `@foo`
 refers to the one introduced in MODULE.bazel.
 
 Note: For a module extension generated repository `@bar`, if `@foo` is used as
@@ -766,9 +757,7 @@ the project. Take note of a few things when creating the source archive:
     GitHub isn't going to guarantee the checksum of source archives generated on
     demand. In short, URLs in the form of
     `https://github.com///releases/download/...` is considered stable
-    while `https://github.com///archive/...` is not. Check [GitHub
-    Archive Checksum
-    Outage](https://blog.bazel.build/2023/02/15/github-archive-checksum.html)
+    while `https://github.com///archive/...` is not. Check [GitHub Archive Checksum Outage](https://blog.bazel.build/2023/02/15/github-archive-checksum.html)
     for more context.
 
 *   **Make sure the source tree follows the layout of the original repository.**
@@ -797,8 +786,7 @@ Pull Request.
 
 [bcr_contrib_guide]: https://github.com/bazelbuild/bazel-central-registry/tree/main/docs#contribute-a-bazel-module
 
-It is **highly recommended** to set up the [Publish to
-BCR](https://github.com/bazel-contrib/publish-to-bcr) GitHub App for your
+It is **highly recommended** to set up the [Publish to BCR](https://github.com/bazel-contrib/publish-to-bcr) GitHub App for your
 repository to automate the process of submitting your module to the BCR.
 
 ## Best practices {#best-practices}
diff --git a/versions/7.6.1/external/mod-command.mdx b/versions/7.6.1/external/mod-command.mdx
index 6d7636ad..5770b764 100644
--- a/versions/7.6.1/external/mod-command.mdx
+++ b/versions/7.6.1/external/mod-command.mdx
@@ -61,11 +61,9 @@ The available subcommands and their respective required arguments are:
 
 *   ``: All present versions of the module ``.
 
-*   `@`: The repo with the given [apparent
-    name](overview#apparent-repo-name) in the context of the `--base_module`.
+*   `@`: The repo with the given [apparent name](/versions/7.6.1/external/overview#apparent-repo-name) in the context of the `--base_module`.
 
-*   `@@`: The repo with the given [canonical
-    name](overview#canonical-repo-name).
+*   `@@`: The repo with the given [canonical name](/versions/7.6.1/external/overview#canonical-repo-name).
 
 In a context requiring specifying modules, ``s referring to repos that
 correspond to modules (as opposed to extension-generated repos) can also be
@@ -87,8 +85,7 @@ The following options only affect the subcommands that print graphs (`graph`,
     information about the version resolution of each module. If the module
     version changed during resolution, show either which version replaced it or
     what was the original version, the reason it was replaced, and which modules
-    requested the new version if the reason was [Minimal Version
-    Selection](module#version-selection).
+    requested the new version if the reason was [Minimal Version Selection](/versions/7.6.1/external/module#version-selection).
 
 *   `--include_unused` *default: "false"*: Include in the output graph the
     modules which were originally present in the dependency graph, but became
@@ -192,7 +189,7 @@ use_repo(toolchains, my_jdk="remotejdk17_linux")
   

     
       

-        Graph Before Resolution
+        Graph Before Resolution
         
Graph Before Resolution

       

 {/* digraph mygraph {
@@ -222,7 +219,7 @@ use_repo(toolchains, my_jdk="remotejdk17_linux")
     		
     
       

-        Graph After Resolution
+        Graph After Resolution
        
Graph After Resolution

       

 {/* digraph mygraph {
diff --git a/versions/7.6.1/external/module.mdx b/versions/7.6.1/external/module.mdx
index 9a48e4db..a59cb0cc 100644
--- a/versions/7.6.1/external/module.mdx
+++ b/versions/7.6.1/external/module.mdx
@@ -122,8 +122,7 @@ serves multiple purposes:
     version, regardless of which versions of the dependency are requested in the
     dependency graph.
 *   With the `registry` attribute, you can force this dependency to come from a
-    specific registry, instead of following the normal [registry
-    selection](/versions/7.6.1/external/registry#selecting_registries) process.
+    specific registry, instead of following the normal [registry selection](/versions/7.6.1/external/registry#selecting_registries) process.
 *   With the `patch*` attributes, you can specify a set of patches to apply to
     the downloaded module.
 
@@ -176,13 +175,11 @@ With `bazel_dep`, you can define repos that represent other Bazel modules.
 Sometimes there is a need to define a repo that does _not_ represent a Bazel
 module; for example, one that contains a plain JSON file to be read as data.
 
-In this case, you could use the [`use_repo_rule`
-directive](/versions/7.6.1/rules/lib/globals/module#use_repo_rule) to directly define a repo
+In this case, you could use the [`use_repo_rule` directive](/versions/7.6.1/rules/lib/globals/module#use_repo_rule) to directly define a repo
 by invoking a repo rule. This repo will only be visible to the module it's
 defined in.
 
-Under the hood, this is implemented using the same mechanism as [module
-extensions](/versions/7.6.1/external/extension), which lets you define repos with more
+Under the hood, this is implemented using the same mechanism as [module extensions](/versions/7.6.1/external/extension), which lets you define repos with more
 flexibility.
 
 ## Repository names and strict deps
diff --git a/versions/7.6.1/external/overview.mdx b/versions/7.6.1/external/overview.mdx
index cca6d04d..29842bfd 100644
--- a/versions/7.6.1/external/overview.mdx
+++ b/versions/7.6.1/external/overview.mdx
@@ -128,8 +128,7 @@ for all build targets inside the repo.
 
 The syntax of a `REPO.bazel` file is similar to `BUILD` files, except that no
 `load` statements are supported, and only a single function, `repo()`, is
-available. `repo()` takes the same arguments as the [`package()`
-function](/versions/7.6.1/reference/be/functions#package) in `BUILD` files; whereas `package()`
+available. `repo()` takes the same arguments as the [`package()` function](/versions/7.6.1/reference/be/functions#package) in `BUILD` files; whereas `package()`
 specifies common attributes for all build targets inside the package, `repo()`
 analogously does so for all build targets inside the repo.
 
@@ -163,8 +162,7 @@ bazel_dep(name = "protobuf", version = "3.19.0")
 ```
 
 A module must only list its direct dependencies, which Bzlmod looks up in a
-[Bazel registry](/versions/7.6.1/external/registry) — by default, the [Bazel Central
-Registry](https://bcr.bazel.build/). The registry provides the
+[Bazel registry](/versions/7.6.1/external/registry) — by default, the [Bazel Central Registry](https://bcr.bazel.build/). The registry provides the
 dependencies' `MODULE.bazel` files, which allows Bazel to discover the entire
 transitive dependency graph before performing version resolution.
 
@@ -235,5 +233,4 @@ many pain points, including:
         `B` and `C`; `B` and `C` both depend on different versions of `D`).
 
 Due to the shortcomings of WORKSPACE, Bzlmod is going to replace the legacy
-WORKSPACE system in future Bazel releases. Please read the [Bzlmod migration
-guide](/versions/7.6.1/external/migration) on how to migrate to Bzlmod.
\ No newline at end of file
+WORKSPACE system in future Bazel releases. Please read the [Bzlmod migration guide](/versions/7.6.1/external/migration) on how to migrate to Bzlmod.
\ No newline at end of file
diff --git a/versions/7.6.1/external/registry.mdx b/versions/7.6.1/external/registry.mdx
index e5f7ae4b..9d8a23f4 100644
--- a/versions/7.6.1/external/registry.mdx
+++ b/versions/7.6.1/external/registry.mdx
@@ -42,8 +42,7 @@ An index registry must follow the format below:
             project
         *   `versions`: A list of all the versions of this module to be found in
             this registry
-        *   `yanked_versions`: A map of [*yanked*
-            versions](/versions/7.6.1/external/module#yanked_versions) of this module. The keys
+        *   `yanked_versions`: A map of [*yanked* versions](/versions/7.6.1/external/module#yanked_versions) of this module. The keys
             should be versions to yank and the values should be descriptions of
             why the version is yanked, ideally containing a link to more
             information
@@ -54,8 +53,7 @@ An index registry must follow the format below:
         *   The default type is "archive", representing an `http_archive` repo,
             with the following fields:
             *   `url`: The URL of the source archive
-            *   `integrity`: The [Subresource
-                Integrity](https://w3c.github.io/webappsec-subresource-integrity/#integrity-metadata-description)
+            *   `integrity`: The [Subresource Integrity](https://w3c.github.io/webappsec-subresource-integrity/#integrity-metadata-description)
                 checksum of the archive
             *   `strip_prefix`: A directory prefix to strip when extracting the
                 source archive
@@ -103,8 +101,7 @@ You can browse its contents using the web frontend at
 https://registry.bazel.build/.
 
 The Bazel community maintains the BCR, and contributors are welcome to submit
-pull requests. See the [BCR contribution
-guidelines](https://github.com/bazelbuild/bazel-central-registry/blob/main/docs/README.md).
+pull requests. See the [BCR contribution guidelines](https://github.com/bazelbuild/bazel-central-registry/blob/main/docs/README.md).
 
 In addition to following the format of a normal index registry, the BCR requires
 a `presubmit.yml` file for each module version
diff --git a/versions/7.6.1/external/vendor.mdx b/versions/7.6.1/external/vendor.mdx
index 820936c7..5717874c 100644
--- a/versions/7.6.1/external/vendor.mdx
+++ b/versions/7.6.1/external/vendor.mdx
@@ -23,9 +23,7 @@ absolute path.
 ## Vendor a specific external repository {#vendor-specific-repository}
 
 You can use the `vendor` command with the `--repo` flag to specify which repo
-to vendor, it accepts both [canonical repo
-name](/versions/7.6.1/external/overview#canonical-repo-name) and [apparent repo
-name](/versions/7.6.1/external/overview#apparent-repo-name).
+to vendor, it accepts both [canonical repo name](/versions/7.6.1/external/overview#canonical-repo-name) and [apparent repo name](/versions/7.6.1/external/overview#apparent-repo-name).
 
 For example, running:
 
diff --git a/versions/7.6.1/help.mdx b/versions/7.6.1/help.mdx
index e60e034a..aa8e9b52 100644
--- a/versions/7.6.1/help.mdx
+++ b/versions/7.6.1/help.mdx
@@ -45,5 +45,4 @@ what level of support Bazel provides.
 
 ## File a bug {#file-bug}
 
-If you encounter a bug or want to request a feature, file a [GitHub
-Issue](https://github.com/bazelbuild/bazel/issues).
+If you encounter a bug or want to request a feature, file a [GitHub Issue](https://github.com/bazelbuild/bazel/issues).
diff --git a/versions/7.6.1/images/about.svg b/versions/7.6.1/images/about.svg
new file mode 100644
index 00000000..f927298f
--- /dev/null
+++ b/versions/7.6.1/images/about.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/7.6.1/images/basics.svg b/versions/7.6.1/images/basics.svg
new file mode 100644
index 00000000..013ec519
--- /dev/null
+++ b/versions/7.6.1/images/basics.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/7.6.1/images/bazel_hero.svg b/versions/7.6.1/images/bazel_hero.svg
new file mode 100644
index 00000000..c48714d0
--- /dev/null
+++ b/versions/7.6.1/images/bazel_hero.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/7.6.1/images/community.svg b/versions/7.6.1/images/community.svg
new file mode 100644
index 00000000..29f87a76
--- /dev/null
+++ b/versions/7.6.1/images/community.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/7.6.1/images/distributed-build-remote-cache.png b/versions/7.6.1/images/distributed-build-remote-cache.png
new file mode 100644
index 00000000..99d8a915
Binary files /dev/null and b/versions/7.6.1/images/distributed-build-remote-cache.png differ
diff --git a/versions/7.6.1/images/essential_guide.svg b/versions/7.6.1/images/essential_guide.svg
new file mode 100644
index 00000000..4ee63ae9
--- /dev/null
+++ b/versions/7.6.1/images/essential_guide.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/7.6.1/images/essential_reference.svg b/versions/7.6.1/images/essential_reference.svg
new file mode 100644
index 00000000..4d29a8d5
--- /dev/null
+++ b/versions/7.6.1/images/essential_reference.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/7.6.1/images/essential_start.svg b/versions/7.6.1/images/essential_start.svg
new file mode 100644
index 00000000..c8f48f84
--- /dev/null
+++ b/versions/7.6.1/images/essential_start.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/7.6.1/images/extend.svg b/versions/7.6.1/images/extend.svg
new file mode 100644
index 00000000..77b2dd97
--- /dev/null
+++ b/versions/7.6.1/images/extend.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/7.6.1/images/guide.svg b/versions/7.6.1/images/guide.svg
new file mode 100644
index 00000000..23a5d35a
--- /dev/null
+++ b/versions/7.6.1/images/guide.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/7.6.1/images/high-level-build-system.png b/versions/7.6.1/images/high-level-build-system.png
new file mode 100644
index 00000000..462717fa
Binary files /dev/null and b/versions/7.6.1/images/high-level-build-system.png differ
diff --git a/versions/7.6.1/images/new_1.svg b/versions/7.6.1/images/new_1.svg
new file mode 100644
index 00000000..c4cd9dfd
--- /dev/null
+++ b/versions/7.6.1/images/new_1.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/7.6.1/images/new_2.svg b/versions/7.6.1/images/new_2.svg
new file mode 100644
index 00000000..c6b7021b
--- /dev/null
+++ b/versions/7.6.1/images/new_2.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/7.6.1/images/new_3.svg b/versions/7.6.1/images/new_3.svg
new file mode 100644
index 00000000..c2afb4ac
--- /dev/null
+++ b/versions/7.6.1/images/new_3.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/7.6.1/images/placeholder.png b/versions/7.6.1/images/placeholder.png
new file mode 100644
index 00000000..54f1fa0e
Binary files /dev/null and b/versions/7.6.1/images/placeholder.png differ
diff --git a/versions/7.6.1/images/reference.svg b/versions/7.6.1/images/reference.svg
new file mode 100644
index 00000000..7bbc9bea
--- /dev/null
+++ b/versions/7.6.1/images/reference.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/7.6.1/images/release_notes.svg b/versions/7.6.1/images/release_notes.svg
new file mode 100644
index 00000000..8a2e8b56
--- /dev/null
+++ b/versions/7.6.1/images/release_notes.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/7.6.1/images/remote-execution-system.png b/versions/7.6.1/images/remote-execution-system.png
new file mode 100644
index 00000000..8152fc0c
Binary files /dev/null and b/versions/7.6.1/images/remote-execution-system.png differ
diff --git a/versions/7.6.1/images/start.svg b/versions/7.6.1/images/start.svg
new file mode 100644
index 00000000..3bcebd7b
--- /dev/null
+++ b/versions/7.6.1/images/start.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/7.6.1/images/task-dependencies.png b/versions/7.6.1/images/task-dependencies.png
new file mode 100644
index 00000000..ae1f9c51
Binary files /dev/null and b/versions/7.6.1/images/task-dependencies.png differ
diff --git a/versions/7.6.1/images/test.png b/versions/7.6.1/images/test.png
new file mode 100644
index 00000000..243939da
Binary files /dev/null and b/versions/7.6.1/images/test.png differ
diff --git a/versions/7.6.1/images/transitive-dependencies.png b/versions/7.6.1/images/transitive-dependencies.png
new file mode 100644
index 00000000..ec641a08
Binary files /dev/null and b/versions/7.6.1/images/transitive-dependencies.png differ
diff --git a/versions/7.6.1/images/trunk-logo-dark.svg b/versions/7.6.1/images/trunk-logo-dark.svg
new file mode 100644
index 00000000..f25940af
--- /dev/null
+++ b/versions/7.6.1/images/trunk-logo-dark.svg
@@ -0,0 +1,22 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/versions/7.6.1/images/why_faq.svg b/versions/7.6.1/images/why_faq.svg
new file mode 100644
index 00000000..afec3f8f
--- /dev/null
+++ b/versions/7.6.1/images/why_faq.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/7.6.1/images/why_overview.svg b/versions/7.6.1/images/why_overview.svg
new file mode 100644
index 00000000..c10c363c
--- /dev/null
+++ b/versions/7.6.1/images/why_overview.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/7.6.1/images/why_vision.svg b/versions/7.6.1/images/why_vision.svg
new file mode 100644
index 00000000..739e415f
--- /dev/null
+++ b/versions/7.6.1/images/why_vision.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/7.6.1/install/bazelisk.mdx b/versions/7.6.1/install/bazelisk.mdx
index 161ddb9e..38bf4c70 100644
--- a/versions/7.6.1/install/bazelisk.mdx
+++ b/versions/7.6.1/install/bazelisk.mdx
@@ -16,8 +16,7 @@ For more details, see
 ## Updating Bazel
 
 Bazel has a [backward compatibility policy](/versions/7.6.1/release/backward-compatibility)
-(see [guidance for rolling out incompatible
-changes](/versions/7.6.1/contribute/breaking-changes) if you
+(see [guidance for rolling out incompatible changes](/versions/7.6.1/contribute/breaking-changes) if you
 are the author of one). That page summarizes best practices on how to test and
 migrate your project with upcoming incompatible changes and how to provide
 feedback to the incompatible change authors.
diff --git a/versions/7.6.1/install/compile-source.mdx b/versions/7.6.1/install/compile-source.mdx
index 43cefc6d..32f0e203 100644
--- a/versions/7.6.1/install/compile-source.mdx
+++ b/versions/7.6.1/install/compile-source.mdx
@@ -45,8 +45,7 @@ it by typing `bazel` in a terminal.
 
 **Reason**: To build Bazel from a GitHub source tree, you need a pre-existing
 Bazel binary. You can install one from a package manager or download one from
-GitHub. See [Installing Bazel](/versions/7.6.1/install). (Or you can [build from
-scratch (bootstrap)](#bootstrap-bazel).)
+GitHub. See [Installing Bazel](/versions/7.6.1/install). (Or you can [build from scratch (bootstrap)](#bootstrap-bazel).)
 
 **Troubleshooting**:
 
@@ -233,8 +232,7 @@ For instructions for Unix-like systems, see
     ```
 
 *   **The Visual C++ compiler.** Install the Visual C++ compiler either as part
-    of Visual Studio 2015 or newer, or by installing the latest [Build Tools
-    for Visual Studio 2017](https://aka.ms/BuildTools).
+    of Visual Studio 2015 or newer, or by installing the latest [Build Tools for Visual Studio 2017](https://aka.ms/BuildTools).
 
 *   **JDK.** Version 21 is required.
 
diff --git a/versions/7.6.1/install/ide.mdx b/versions/7.6.1/install/ide.mdx
index 561d0e02..c42d95e9 100644
--- a/versions/7.6.1/install/ide.mdx
+++ b/versions/7.6.1/install/ide.mdx
@@ -38,10 +38,8 @@ To install, go to the IDE's plugin browser and search for `Bazel`.
 To manually install older versions, download the zip files from JetBrains'
 Plugin Repository and install the zip file from the IDE's plugin browser:
 
-*  [Android Studio
-   plugin](https://plugins.jetbrains.com/plugin/9185-android-studio-with-bazel)
-*  [IntelliJ
-   plugin](https://plugins.jetbrains.com/plugin/8609-intellij-with-bazel)
+*  [Android Studio plugin](https://plugins.jetbrains.com/plugin/9185-android-studio-with-bazel)
+*  [IntelliJ plugin](https://plugins.jetbrains.com/plugin/8609-intellij-with-bazel)
 *  [CLion plugin](https://plugins.jetbrains.com/plugin/9554-clion-with-bazel)
 
 ### Xcode {#xcode}
@@ -61,8 +59,7 @@ Features:
 * Starlark debugger for `.bzl` files during a build (set breakpoints, step
   through code, inspect variables, and so on)
 
-Find [the plugin on the Visual Studio
-marketplace](https://marketplace.visualstudio.com/items?itemName=BazelBuild.vscode-bazel).
+Find [the plugin on the Visual Studio marketplace](https://marketplace.visualstudio.com/items?itemName=BazelBuild.vscode-bazel).
 The plugin is [open source](https://github.com/bazelbuild/vscode-bazel).
 
 See also: [Autocomplete for Source Code](#autocomplete-for-source-code)
@@ -82,8 +79,7 @@ See also: [Autocomplete for Source Code](#autocomplete-for-source-code)
 
 ### Emacs {#emacs}
 
-See [`bazelbuild/bazel-emacs-mode` on
-GitHub](https://github.com/bazelbuild/emacs-bazel-mode)
+See [`bazelbuild/bazel-emacs-mode` on GitHub](https://github.com/bazelbuild/emacs-bazel-mode)
 
 See also: [Autocomplete for Source Code](#autocomplete-for-source-code)
 
@@ -115,6 +111,5 @@ tool for building Bazel targets when source files change.
 
 ## Building your own IDE plugin {#build-own-plugin}
 
-Read the [**IDE support** blog
-post](https://blog.bazel.build/2016/06/10/ide-support.html) to learn more about
+Read the [**IDE support** blog post](https://blog.bazel.build/2016/06/10/ide-support.html) to learn more about
 the Bazel APIs to use when building an IDE plugin.
diff --git a/versions/7.6.1/install/images/bazelisk.svg b/versions/7.6.1/install/images/bazelisk.svg
new file mode 100644
index 00000000..c0ae9f54
--- /dev/null
+++ b/versions/7.6.1/install/images/bazelisk.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/7.6.1/install/images/cli.svg b/versions/7.6.1/install/images/cli.svg
new file mode 100644
index 00000000..01119280
--- /dev/null
+++ b/versions/7.6.1/install/images/cli.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/7.6.1/install/images/docker.svg b/versions/7.6.1/install/images/docker.svg
new file mode 100644
index 00000000..21190ce0
--- /dev/null
+++ b/versions/7.6.1/install/images/docker.svg
@@ -0,0 +1,6 @@
+
\ No newline at end of file
diff --git a/versions/7.6.1/install/images/github.svg b/versions/7.6.1/install/images/github.svg
new file mode 100644
index 00000000..aa05db9c
--- /dev/null
+++ b/versions/7.6.1/install/images/github.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/7.6.1/install/images/install.svg b/versions/7.6.1/install/images/install.svg
new file mode 100644
index 00000000..ae080865
--- /dev/null
+++ b/versions/7.6.1/install/images/install.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/7.6.1/install/images/mac.svg b/versions/7.6.1/install/images/mac.svg
new file mode 100644
index 00000000..3ee4fe28
--- /dev/null
+++ b/versions/7.6.1/install/images/mac.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/7.6.1/install/images/redhat.svg b/versions/7.6.1/install/images/redhat.svg
new file mode 100644
index 00000000..078b3387
--- /dev/null
+++ b/versions/7.6.1/install/images/redhat.svg
@@ -0,0 +1,69 @@
+
+
+  
+    
+      
+        image/svg+xml
+        
+        
+      
+    
+  
+  
+  
+    
+  
+  
+  
+
diff --git a/versions/7.6.1/install/images/suse.png b/versions/7.6.1/install/images/suse.png
new file mode 100644
index 00000000..6435b689
Binary files /dev/null and b/versions/7.6.1/install/images/suse.png differ
diff --git a/versions/7.6.1/install/images/tune.svg b/versions/7.6.1/install/images/tune.svg
new file mode 100644
index 00000000..8d7d63cb
--- /dev/null
+++ b/versions/7.6.1/install/images/tune.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/7.6.1/install/images/ubuntu.svg b/versions/7.6.1/install/images/ubuntu.svg
new file mode 100644
index 00000000..f217bc8d
--- /dev/null
+++ b/versions/7.6.1/install/images/ubuntu.svg
@@ -0,0 +1,8 @@
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/versions/7.6.1/install/images/windows.svg b/versions/7.6.1/install/images/windows.svg
new file mode 100644
index 00000000..120b0190
--- /dev/null
+++ b/versions/7.6.1/install/images/windows.svg
@@ -0,0 +1,5 @@
+
+
+
+
+
\ No newline at end of file
diff --git a/versions/7.6.1/install/windows.mdx b/versions/7.6.1/install/windows.mdx
index aaf8cdea..ba4cfde3 100644
--- a/versions/7.6.1/install/windows.mdx
+++ b/versions/7.6.1/install/windows.mdx
@@ -31,8 +31,7 @@ To check your Windows version:
 
 Alternatively you can:
 
-*   [Download the Bazel binary (`bazel-version-windows-x86_64.exe`) from
- GitHub](https://github.com/bazelbuild/bazel/releases).
+*   [Download the Bazel binary (`bazel-version-windows-x86_64.exe`) from GitHub](https://github.com/bazelbuild/bazel/releases).
 *   [Install Bazel from Chocolatey](#chocolately)
 *   [Install Bazel from Scoop](#scoop)
 *   [Build Bazel from source](/versions/7.6.1/install/compile-source)
@@ -208,8 +207,7 @@ If that doesn't help:
     its dependencies, such as the MSYS2 shell. This will not install Visual C++
     though.
 
-See [Chocolatey installation and package maintenance
-guide](/versions/7.6.1/contribute/windows-chocolatey-maintenance) for more
+See [Chocolatey installation and package maintenance guide](/versions/7.6.1/contribute/windows-chocolatey-maintenance) for more
 information about the Chocolatey package.
 
 ### Using Scoop {#scoop}
@@ -226,8 +224,7 @@ information about the Chocolatey package.
     scoop install bazel
     ```
 
-See [Scoop installation and package maintenance
-guide](/versions/7.6.1/contribute/windows-scoop-maintenance) for more
+See [Scoop installation and package maintenance guide](/versions/7.6.1/contribute/windows-scoop-maintenance) for more
 information about the Scoop package.
 
 ### Build from source {#build-from-source}
diff --git a/versions/7.6.1/query/cquery.mdx b/versions/7.6.1/query/cquery.mdx
index 61996faa..19a445c6 100644
--- a/versions/7.6.1/query/cquery.mdx
+++ b/versions/7.6.1/query/cquery.mdx
@@ -6,8 +6,7 @@ title: ' Configurable Query (cquery)'
 [`select()`](/versions/7.6.1/docs/configurable-attributes) and build options' effects on the build
 graph.
 
-It achieves this by running over the results of Bazel's [analysis
-phase](/versions/7.6.1/extending/concepts#evaluation-model),
+It achieves this by running over the results of Bazel's [analysis phase](/versions/7.6.1/extending/concepts#evaluation-model),
 which integrates these effects. `query`, by contrast, runs over the results of
 Bazel's loading phase, before options are evaluated.
 
@@ -137,8 +136,7 @@ $ bazel cquery //foo --universe_scope=//foo,//genrule_with_foo_as_tool
 If you want to precisely declare which instance to query over, use
 the [`config`](#config) function.
 
-See `query`'s [target pattern
-documentation](/versions/7.6.1/query/language#target-patterns) for more information on target patterns.
+See `query`'s [target pattern documentation](/versions/7.6.1/query/language#target-patterns) for more information on target patterns.
 
 ## Functions {#functions}
 
diff --git a/versions/7.6.1/query/images/query_graph1.png b/versions/7.6.1/query/images/query_graph1.png
new file mode 100644
index 00000000..7bc9a61a
Binary files /dev/null and b/versions/7.6.1/query/images/query_graph1.png differ
diff --git a/versions/7.6.1/query/images/query_graph2.png b/versions/7.6.1/query/images/query_graph2.png
new file mode 100644
index 00000000..a0da22ff
Binary files /dev/null and b/versions/7.6.1/query/images/query_graph2.png differ
diff --git a/versions/7.6.1/query/images/query_graph3.png b/versions/7.6.1/query/images/query_graph3.png
new file mode 100644
index 00000000..4418f193
Binary files /dev/null and b/versions/7.6.1/query/images/query_graph3.png differ
diff --git a/versions/7.6.1/query/language.mdx b/versions/7.6.1/query/language.mdx
index f1ca2e60..db4d586d 100644
--- a/versions/7.6.1/query/language.mdx
+++ b/versions/7.6.1/query/language.mdx
@@ -1100,8 +1100,7 @@ is being used.
 
 ### On the ordering of results {#results-ordering}
 
-Although query expressions always follow the "[law of
-conservation of graph order](#graph-order)", _presenting_ the results may be done
+Although query expressions always follow the "[law of conservation of graph order](#graph-order)", _presenting_ the results may be done
 in either a dependency-ordered or unordered manner. This does **not**
 influence the targets in the result set or how the query is computed. It only
 affects how the results are printed to stdout. Moreover, nodes that are
@@ -1246,8 +1245,7 @@ and `maxrank` output formats print the labels of each
 target in the resulting graph, but instead of appearing in
 topological order, they appear in rank order, preceded by their
 rank number. These are unaffected by the result ordering
-`--[no]order_results` flag (see [notes on
-the ordering of results](#result-order)).
+`--[no]order_results` flag (see [notes on the ordering of results](#result-order)).
 
 There are two variants of this format: `minrank` ranks
 each node by the length of the shortest path from a root node to it.
diff --git a/versions/7.6.1/query/quickstart.mdx b/versions/7.6.1/query/quickstart.mdx
index a2164dd1..efd419c7 100644
--- a/versions/7.6.1/query/quickstart.mdx
+++ b/versions/7.6.1/query/quickstart.mdx
@@ -205,7 +205,7 @@ dot -Tpng < graph.in > graph.png
 ```
 If you open up `graph.png`, you should see something like this. The graph below has been simplified to make the essential path details clearer in this guide.
 
-![Diagram showing a relationship from cafe to chef to the dishes: pizza and mac and cheese which diverges into the separate ingredients: cheese, tomatoes, dough, and macaroni.](images/query_graph1.png "Dependency graph")
+![Diagram showing a relationship from cafe to chef to the dishes: pizza and mac and cheese which diverges into the separate ingredients: cheese, tomatoes, dough, and macaroni.](/versions/7.6.1/query/images/query_graph1.png "Dependency graph")
 
 This helps when you want to see the outputs of the different query functions throughout this guide.
 
@@ -421,7 +421,7 @@ bazel query --noimplicit_deps 'deps(:runner)' --output graph > graph2.in
 dot -Tpng < graph2.in > graph2.png
 ```
 
-[![The same graph as the first one except now there is a spoke stemming from the chef target with smoothie which leads to banana and strawberry](images/query_graph2.png "Updated dependency graph")](images/query_graph2.png)
+[![The same graph as the first one except now there is a spoke stemming from the chef target with smoothie which leads to banana and strawberry](/versions/7.6.1/query/images/query_graph2.png "Updated dependency graph")](/query/images/query_graph2.png)
 
 Looking at `graph2.png`, you can see that `Smoothie` has no shared dependencies with other dishes but is just another target that the `Chef` relies on.
 
@@ -465,7 +465,7 @@ bazel query "allpaths(//src/main/java/com/example/restaurant/..., //src/main/jav
 //src/main/java/com/example/restaurant:chef
 ```
 
-![Output path of cafe to chef to pizza,mac and cheese to cheese](images/query_graph3.png "Output path for dependency")
+![Output path of cafe to chef to pizza,mac and cheese to cheese](/versions/7.6.1/query/images/query_graph3.png "Output path for dependency")
 
 The output of `allpaths()` is a little harder to read as it is a flattened list of the dependencies. Visualizing this graph using Graphviz makes the relationship clearer to understand.
 
diff --git a/versions/7.6.1/reference/be/android.mdx b/versions/7.6.1/reference/be/android.mdx
index 44c3165c..2445b6cd 100644
--- a/versions/7.6.1/reference/be/android.mdx
+++ b/versions/7.6.1/reference/be/android.mdx
@@ -75,7 +75,7 @@ Bazel source tree.
 | `dex_shards` | Integer; default is `1` Number of shards dexing should be decomposed into. This is makes dexing much faster at the expense of app installation and startup time. The larger the binary, the more shards should be used. 25 is a good value to start experimenting with. Note that each shard will result in at least one dex in the final app. For this reason, setting this to more than 1 is not recommended for release binaries. |
 | `dexopts` | List of strings; default is `[]` Additional command-line flags for the dx tool when generating classes.dex. Subject to ["Make variable"](/versions/7.6.1/reference/be/make-variables) substitution and [Bourne shell tokenization](/versions/7.6.1/reference/be/common-definitions#sh-tokenization). |
 | `enable_data_binding` | Boolean; default is `False` If true, this rule processes [data binding](https://developer.android.com/topic/libraries/data-binding/index.html) expressions in layout resources included through the [resource\_files](/versions/7.6.1/reference/be/android#android_binary.resource_files) attribute. Without this setting, data binding expressions produce build failures. To build an Android app with data binding, you must also do the following:  1. Set this attribute for all Android rules that transitively depend on this one.    This is because dependers inherit the rule's data binding expressions through resource    merging. So they also need to build with data binding to parse those expressions.- Add a `deps =` entry for the data binding runtime library to all targets      that set this attribute. The location of this library depends on your depot setup. |
-| `incremental_dexing` | Integer; [nonconfigurable](common-definitions#configurable-attributes); default is `-1` Force the target to be built with or without incremental dexing, overriding defaults and --incremental\_dexing flag. |
+| `incremental_dexing` | Integer; [nonconfigurable](/versions/7.6.1/reference/be/common-definitions#configurable-attributes); default is `-1` Force the target to be built with or without incremental dexing, overriding defaults and --incremental\_dexing flag. |
 | `instruments` | [Label](/versions/7.6.1/concepts/labels); default is `None`  The `android_binary` target to instrument.  If this attribute is set, this `android_binary` will be treated as a test application for instrumentation tests. An `android_instrumentation_test` target can then specify this target in its [test\_app](/versions/7.6.1/reference/be/android#android_instrumentation_test.test_app) attribute. |
 | `javacopts` | List of strings; default is `[]` Extra compiler options for this target. Subject to ["Make variable"](/versions/7.6.1/reference/be/make-variables) substitution and [Bourne shell tokenization](/versions/7.6.1/reference/be/common-definitions#sh-tokenization). These compiler options are passed to javac after the global compiler options. |
 | `key_rotation_min_sdk` | String; default is `""` Sets the minimum Android platform version (API Level) for which an APK's rotated signing key should be used to produce the APK's signature. The original signing key for the APK will be used for all previous platform versions. |
@@ -90,7 +90,7 @@ Bazel source tree.
 | `plugins` | List of [labels](/versions/7.6.1/concepts/labels); default is `[]` Java compiler plugins to run at compile-time. Every `java_plugin` specified in the plugins attribute will be run whenever this target is built. Resources generated by the plugin will be included in the result jar of the target. |
 | `proguard_apply_dictionary` | [Label](/versions/7.6.1/concepts/labels); default is `None` File to be used as a mapping for proguard. A line separated file of "words" to pull from when renaming classes and members during obfuscation. |
 | `proguard_apply_mapping` | [Label](/versions/7.6.1/concepts/labels); default is `None` File to be used as a mapping for proguard. A mapping file generated by `proguard_generate_mapping` to be re-used to apply the same mapping to a new build. |
-| `proguard_generate_mapping` | Boolean; [nonconfigurable](common-definitions#configurable-attributes); default is `False` Whether to generate Proguard mapping file. The mapping file will be generated only if `proguard_specs` is specified. This file will list the mapping between the original and obfuscated class, method, and field names. *WARNING: If this attribute is used, the Proguard specification should contain neither `-dontobfuscate` nor `-printmapping`.* |
+| `proguard_generate_mapping` | Boolean; [nonconfigurable](/versions/7.6.1/reference/be/common-definitions#configurable-attributes); default is `False` Whether to generate Proguard mapping file. The mapping file will be generated only if `proguard_specs` is specified. This file will list the mapping between the original and obfuscated class, method, and field names. *WARNING: If this attribute is used, the Proguard specification should contain neither `-dontobfuscate` nor `-printmapping`.* |
 | `proguard_specs` | List of [labels](/versions/7.6.1/concepts/labels); default is `[]` Files to be used as Proguard specification. This file will describe the set of specifications to be used by Proguard. |
 | `resource_configuration_filters` | List of strings; default is `[]` A list of resource configuration filters, such 'en' that will limit the resources in the apk to only the ones in the 'en' configuration. To enable pseudolocalization, include the `en_XA` and/or `ar_XB` pseudo-locales. |
 | `resource_files` | List of [labels](/versions/7.6.1/concepts/labels); default is `[]` The list of resources to be packaged. This is typically a `glob` of all files under the `res` directory.   Generated files (from genrules) can be referenced by [Label](/versions/7.6.1/concepts/labels) here as well. The only restriction is that the generated outputs must be under the same "`res`" directory as any other resource files that are included. |
@@ -246,7 +246,7 @@ android_library(
 | `exported_plugins` | List of [labels](/versions/7.6.1/concepts/labels); default is `[]` The list of `java_plugin`s (e.g. annotation processors) to export to libraries that directly depend on this library. The specified list of `java_plugin`s will be applied to any library which directly depends on this library, just as if that library had explicitly declared these labels in `plugins`. |
 | `exports` | List of [labels](/versions/7.6.1/concepts/labels); default is `[]` The closure of all rules reached via `exports` attributes are considered direct dependencies of any rule that directly depends on the target with `exports`. The `exports` are not direct deps of the rule they belong to. |
 | `exports_manifest` | Integer; default is `1` Whether to export manifest entries to `android_binary` targets that depend on this target. `uses-permissions` attributes are never exported. |
-| `idl_import_root` | String; default is `""` Package-relative path to the root of the java package tree containing idl sources included in this library. This path will be used as the import root when processing idl sources that depend on this library.  When `idl_import_root` is specified, both `idl_parcelables` and `idl_srcs` must be at the path specified by the java package of the object they represent under `idl_import_root`. When `idl_import_root` is not specified, both `idl_parcelables` and `idl_srcs` must be at the path specified by their package under a Java root.  See [examples](android#android_library_examples.idl_import_root). |
+| `idl_import_root` | String; default is `""` Package-relative path to the root of the java package tree containing idl sources included in this library. This path will be used as the import root when processing idl sources that depend on this library.  When `idl_import_root` is specified, both `idl_parcelables` and `idl_srcs` must be at the path specified by the java package of the object they represent under `idl_import_root`. When `idl_import_root` is not specified, both `idl_parcelables` and `idl_srcs` must be at the path specified by their package under a Java root.  See [examples](/versions/7.6.1/reference/be/android#android_library_examples.idl_import_root). |
 | `idl_parcelables` | List of [labels](/versions/7.6.1/concepts/labels); default is `[]` List of Android IDL definitions to supply as imports. These files will be made available as imports for any `android_library` target that depends on this library, directly or via its transitive closure, but will not be translated to Java or compiled. Only `.aidl` files that correspond directly to `.java` sources in this library should be included (e.g., custom implementations of Parcelable), otherwise `idl_srcs` should be used.  These files must be placed appropriately for the aidl compiler to find them. See [the description of idl\_import\_root](/versions/7.6.1/reference/be/android#android_library.idl_import_root) for information about what this means. |
 | `idl_preprocessed` | List of [labels](/versions/7.6.1/concepts/labels); default is `[]` List of preprocessed Android IDL definitions to supply as imports. These files will be made available as imports for any `android_library` target that depends on this library, directly or via its transitive closure, but will not be translated to Java or compiled. Only preprocessed `.aidl` files that correspond directly to `.java` sources in this library should be included (e.g., custom implementations of Parcelable), otherwise use `idl_srcs` for Android IDL definitions that need to be translated to Java interfaces and use `idl_parcelable` for non-preprocessed AIDL files. |
 | `idl_srcs` | List of [labels](/versions/7.6.1/concepts/labels); default is `[]` List of Android IDL definitions to translate to Java interfaces. After the Java interfaces are generated, they will be compiled together with the contents of `srcs`. These files will be made available as imports for any `android_library` target that depends on this library, directly or via its transitive closure.  These files must be placed appropriately for the aidl compiler to find them. See [the description of idl\_import\_root](/versions/7.6.1/reference/be/android#android_library.idl_import_root) for information about what this means. |
@@ -355,8 +355,7 @@ writing Robolectric tests.
 #### Examples
 
 To use Robolectric with `android_local_test`, add
-[Robolectric's
-repository](https://github.com/robolectric/robolectric-bazel/tree/master/bazel) to your `WORKSPACE` file:
+[Robolectric's repository](https://github.com/robolectric/robolectric-bazel/tree/master/bazel) to your `WORKSPACE` file:
 
 ```
 http_archive(
@@ -406,8 +405,8 @@ android_library(
 | `custom_package` | String; default is `""` Java package in which the R class will be generated. By default the package is inferred from the directory where the BUILD file containing the rule is. If you use this attribute, you will likely need to use `test_class` as well. |
 | `densities` | List of strings; default is `[]` Densities to filter for when building the apk. A corresponding compatible-screens section will also be added to the manifest if it does not already contain a superset StarlarkListing. |
 | `enable_data_binding` | Boolean; default is `False` If true, this rule processes [data binding](https://developer.android.com/topic/libraries/data-binding/index.html) references used in data-binding enabled dependencies used by this test. Without this setting, data-binding dependencies won't have necessary binary-level code generation, and may produce build failures. |
-| `javacopts` | List of strings; default is `[]` Extra compiler options for this library. Subject to ["Make variable"](make-variables) substitution and [Bourne shell tokenization](common-definitions#sh-tokenization). These compiler options are passed to javac after the global compiler options. |
-| `jvm_flags` | List of strings; default is `[]` A list of flags to embed in the wrapper script generated for running this binary. Subject to [$(location)](/versions/7.6.1/reference/be/make-variables#location) and ["Make variable"](make-variables) substitution, and [Bourne shell tokenization](common-definitions#sh-tokenization). The wrapper script for a Java binary includes a CLASSPATH definition (to find all the dependent jars) and invokes the right Java interpreter. The command line generated by the wrapper script includes the name of the main class followed by a `"$@"` so you can pass along other arguments after the classname. However, arguments intended for parsing by the JVM must be specified *before* the classname on the command line. The contents of `jvm_flags` are added to the wrapper script before the classname is listed.  Note that this attribute has *no effect* on `*_deploy.jar` outputs. |
+| `javacopts` | List of strings; default is `[]` Extra compiler options for this library. Subject to ["Make variable"](/versions/7.6.1/reference/be/make-variables) substitution and [Bourne shell tokenization](/versions/7.6.1/reference/be/common-definitions#sh-tokenization). These compiler options are passed to javac after the global compiler options. |
+| `jvm_flags` | List of strings; default is `[]` A list of flags to embed in the wrapper script generated for running this binary. Subject to [$(location)](/versions/7.6.1/reference/be/make-variables#location) and ["Make variable"](/versions/7.6.1/reference/be/make-variables) substitution, and [Bourne shell tokenization](/versions/7.6.1/reference/be/common-definitions#sh-tokenization). The wrapper script for a Java binary includes a CLASSPATH definition (to find all the dependent jars) and invokes the right Java interpreter. The command line generated by the wrapper script includes the name of the main class followed by a `"$@"` so you can pass along other arguments after the classname. However, arguments intended for parsing by the JVM must be specified *before* the classname on the command line. The contents of `jvm_flags` are added to the wrapper script before the classname is listed.  Note that this attribute has *no effect* on `*_deploy.jar` outputs. |
 | `manifest` | [Label](/versions/7.6.1/concepts/labels); default is `None` The name of the Android manifest file, normally `AndroidManifest.xml`. Must be defined if resource\_files or assets are defined or if any of the manifests from the libraries under test have a `minSdkVersion` tag in them. |
 | `manifest_values` | Dictionary: String -> String; default is `{}` A dictionary of values to be overridden in the manifest. Any instance of ${name} in the manifest will be replaced with the value corresponding to name in this dictionary. `applicationId`, `versionCode`, `versionName`, `minSdkVersion`, `targetSdkVersion` and `maxSdkVersion` will also override the corresponding attributes of the manifest and uses-sdk tags. `packageName` will be ignored and will be set from either `applicationId` if specified or the package in the manifest. It is not necessary to have a manifest on the rule in order to use manifest\_values. |
 | `nocompress_extensions` | List of strings; default is `[]` A list of file extensions to leave uncompressed in the resource apk. |
@@ -585,8 +584,8 @@ cc_library(
 | Attributes | |
 | --- | --- |
 | `name` | [Name](/versions/7.6.1/concepts/labels#target-names); required  A unique name for this target. |
-| `api_level` | Integer; [nonconfigurable](common-definitions#configurable-attributes); default is `0` The Android API level to build against. If not specified, the highest API level installed will be used. |
-| `path` | String; [nonconfigurable](common-definitions#configurable-attributes); default is `""` An absolute or relative path to an Android NDK. Either this attribute or the `$ANDROID_NDK_HOME` environment variable must be set. The Android NDK can be downloaded from [the Android developer site](https://developer.android.com/ndk/downloads/index.html). |
+| `api_level` | Integer; [nonconfigurable](/versions/7.6.1/reference/be/common-definitions#configurable-attributes); default is `0` The Android API level to build against. If not specified, the highest API level installed will be used. |
+| `path` | String; [nonconfigurable](/versions/7.6.1/reference/be/common-definitions#configurable-attributes); default is `""` An absolute or relative path to an Android NDK. Either this attribute or the `$ANDROID_NDK_HOME` environment variable must be set. The Android NDK can be downloaded from [the Android developer site](https://developer.android.com/ndk/downloads/index.html). |
 | `repo_mapping` | Dictionary: String -> String; default is `{}` A dictionary from local repository name to global repository name. This allows controls over workspace dependency resolution for dependencies of this repository. For example, an entry `"@foo": "@bar"` declares that, for any time this repository depends on `"@foo"` (such as a dependency on `"@foo//some:target"`), it should actually resolve that dependency within globally-declared `"@bar"` (`"@bar//some:target"`). |
 
 ## android\_sdk\_repository
@@ -657,7 +656,7 @@ android_library(
 | Attributes | |
 | --- | --- |
 | `name` | [Name](/versions/7.6.1/concepts/labels#target-names); required  A unique name for this target. |
-| `api_level` | Integer; [nonconfigurable](common-definitions#configurable-attributes); default is `0` The Android API level to build against by default. If not specified, the highest API level installed will be used. The API level used for a given build can be overridden by the `android_sdk` flag. `android_sdk_repository` creates an `android_sdk` target for each API level installed in the SDK with name `@androidsdk//:sdk-${level}`, whether or not this attribute is specified. For example, to build against a non-default API level: `bazel build --android_sdk=@androidsdk//:sdk-19 //java/com/example:app`. To view all `android_sdk` targets generated by `android_sdk_repository`, you can run `bazel query "kind(android_sdk, @androidsdk//...)"`. |
-| `build_tools_version` | String; [nonconfigurable](common-definitions#configurable-attributes); default is `""` The version of the Android build tools to use from within the Android SDK. If not specified, the latest build tools version installed will be used. Bazel requires build tools version 30.0.0 or later. |
-| `path` | String; [nonconfigurable](common-definitions#configurable-attributes); default is `""` An absolute or relative path to an Android SDK. Either this attribute or the `$ANDROID_HOME` environment variable must be set. The Android SDK can be downloaded from [the Android developer site](https://developer.android.com). |
+| `api_level` | Integer; [nonconfigurable](/versions/7.6.1/reference/be/common-definitions#configurable-attributes); default is `0` The Android API level to build against by default. If not specified, the highest API level installed will be used. The API level used for a given build can be overridden by the `android_sdk` flag. `android_sdk_repository` creates an `android_sdk` target for each API level installed in the SDK with name `@androidsdk//:sdk-${level}`, whether or not this attribute is specified. For example, to build against a non-default API level: `bazel build --android_sdk=@androidsdk//:sdk-19 //java/com/example:app`. To view all `android_sdk` targets generated by `android_sdk_repository`, you can run `bazel query "kind(android_sdk, @androidsdk//...)"`. |
+| `build_tools_version` | String; [nonconfigurable](/versions/7.6.1/reference/be/common-definitions#configurable-attributes); default is `""` The version of the Android build tools to use from within the Android SDK. If not specified, the latest build tools version installed will be used. Bazel requires build tools version 30.0.0 or later. |
+| `path` | String; [nonconfigurable](/versions/7.6.1/reference/be/common-definitions#configurable-attributes); default is `""` An absolute or relative path to an Android SDK. Either this attribute or the `$ANDROID_HOME` environment variable must be set. The Android SDK can be downloaded from [the Android developer site](https://developer.android.com). |
 | `repo_mapping` | Dictionary: String -> String; default is `{}` A dictionary from local repository name to global repository name. This allows controls over workspace dependency resolution for dependencies of this repository. For example, an entry `"@foo": "@bar"` declares that, for any time this repository depends on `"@foo"` (such as a dependency on `"@foo//some:target"`), it should actually resolve that dependency within globally-declared `"@bar"` (`"@bar//some:target"`). |
\ No newline at end of file
diff --git a/versions/7.6.1/reference/be/c-cpp.mdx b/versions/7.6.1/reference/be/c-cpp.mdx
index bdd4d198..337780fd 100644
--- a/versions/7.6.1/reference/be/c-cpp.mdx
+++ b/versions/7.6.1/reference/be/c-cpp.mdx
@@ -49,8 +49,8 @@ cc_binary(name, deps, srcs, data, additional_linker_inputs, args, compatible_wit
 | `defines` | List of strings; default is `[]` List of defines to add to the compile line. Subject to ["Make" variable](/versions/7.6.1/reference/be/make-variables) substitution and [Bourne shell tokenization](/versions/7.6.1/reference/be/common-definitions#sh-tokenization). Each string, which must consist of a single Bourne shell token, is prepended with `-D` and added to the compile command line to this target, as well as to every rule that depends on it. Be very careful, since this may have far-reaching effects. When in doubt, add define values to [`local_defines`](#cc_binary.local_defines) instead. |
 | `includes` | List of strings; default is `[]` List of include dirs to be added to the compile line. Subject to ["Make variable"](/versions/7.6.1/reference/be/make-variables) substitution. Each string is prepended with `-isystem` and added to `COPTS`. Unlike [COPTS](#cc_binary.copts), these flags are added for this rule and every rule that depends on it. (Note: not the rules it depends upon!) Be very careful, since this may have far-reaching effects. When in doubt, add "-I" flags to [COPTS](#cc_binary.copts) instead.  Headers must be added to srcs or hdrs, otherwise they will not be available to dependent rules when compilation is sandboxed (the default). |
 | `link_extra_lib` | [Label](/versions/7.6.1/concepts/labels); default is `"@bazel_tools//tools/cpp:link_extra_lib"` Control linking of extra libraries. By default, C++ binaries are linked against `//tools/cpp:link_extra_lib`, which by default depends on the label flag `//tools/cpp:link_extra_libs`. Without setting the flag, this library is empty by default. Setting the label flag allows linking optional dependencies, such as overrides for weak symbols, interceptors for shared library functions, or special runtime libraries (for malloc replacements, prefer `malloc` or `--custom_malloc`). Setting this attribute to `None` disables this behaviour. |
-| `linkopts` | List of strings; default is `[]` Add these flags to the C++ linker command. Subject to ["Make" variable](make-variables) substitution, [Bourne shell tokenization](common-definitions#sh-tokenization) and [label expansion](common-definitions#label-expansion). Each string in this attribute is added to `LINKOPTS` before linking the binary target. Each element of this list that does not start with `$` or `-` is assumed to be the label of a target in `deps`. The list of files generated by that target is appended to the linker options. An error is reported if the label is invalid, or is not declared in `deps`. |
-| `linkshared` | Boolean; [nonconfigurable](common-definitions#configurable-attributes); default is `False` Create a shared library. To enable this attribute, include `linkshared=True` in your rule. By default this option is off. The presence of this flag means that linking occurs with the `-shared` flag to `gcc`, and the resulting shared library is suitable for loading into for example a Java program. However, for build purposes it will never be linked into the dependent binary, as it is assumed that shared libraries built with a [cc\_binary](#cc_binary) rule are only loaded manually by other programs, so it should not be considered a substitute for the [cc\_library](#cc_library) rule. For sake of scalability we recommend avoiding this approach altogether and simply letting `java_library` depend on `cc_library` rules instead.  If you specify both `linkopts=['-static']` and `linkshared=True`, you get a single completely self-contained unit. If you specify both `linkstatic=True` and `linkshared=True`, you get a single, mostly self-contained unit. |
+| `linkopts` | List of strings; default is `[]` Add these flags to the C++ linker command. Subject to ["Make" variable](/versions/7.6.1/reference/be/make-variables) substitution, [Bourne shell tokenization](/versions/7.6.1/reference/be/common-definitions#sh-tokenization) and [label expansion](/versions/7.6.1/reference/be/common-definitions#label-expansion). Each string in this attribute is added to `LINKOPTS` before linking the binary target. Each element of this list that does not start with `$` or `-` is assumed to be the label of a target in `deps`. The list of files generated by that target is appended to the linker options. An error is reported if the label is invalid, or is not declared in `deps`. |
+| `linkshared` | Boolean; [nonconfigurable](/versions/7.6.1/reference/be/common-definitions#configurable-attributes); default is `False` Create a shared library. To enable this attribute, include `linkshared=True` in your rule. By default this option is off. The presence of this flag means that linking occurs with the `-shared` flag to `gcc`, and the resulting shared library is suitable for loading into for example a Java program. However, for build purposes it will never be linked into the dependent binary, as it is assumed that shared libraries built with a [cc\_binary](#cc_binary) rule are only loaded manually by other programs, so it should not be considered a substitute for the [cc\_library](#cc_library) rule. For sake of scalability we recommend avoiding this approach altogether and simply letting `java_library` depend on `cc_library` rules instead.  If you specify both `linkopts=['-static']` and `linkshared=True`, you get a single completely self-contained unit. If you specify both `linkstatic=True` and `linkshared=True`, you get a single, mostly self-contained unit. |
 | `linkstatic` | Boolean; default is `True` For [`cc_binary`](/versions/7.6.1/reference/be/c-cpp#cc_binary) and [`cc_test`](/versions/7.6.1/reference/be/c-cpp#cc_test): link the binary in static mode. For `cc_library.linkstatic`: see below. By default this option is on for `cc_binary` and off for the rest.  If enabled and this is a binary or test, this option tells the build tool to link in `.a`'s instead of `.so`'s for user libraries whenever possible. Some system libraries may still be linked dynamically, as are libraries for which there is no static library. So the resulting executable will still be dynamically linked, hence only *mostly* static.  There are really three different ways to link an executable:   * STATIC with fully\_static\_link feature, in which everything is linked statically;   e.g. "`gcc -static foo.o libbar.a libbaz.a -lm`".    This mode is enabled by specifying `fully_static_link` in the   [`features`](/versions/7.6.1/reference/be/common-definitions#features) attribute. * STATIC, in which all user libraries are linked statically (if a static   version is available), but where system libraries (excluding C/C++ runtime libraries)   are linked dynamically, e.g. "`gcc foo.o libfoo.a libbaz.a -lm`".    This mode is enabled by specifying `linkstatic=True`. * DYNAMIC, in which all libraries are linked dynamically (if a dynamic version is   available), e.g. "`gcc foo.o libfoo.so libbaz.so -lm`".    This mode is enabled by specifying `linkstatic=False`.   The `linkstatic` attribute has a different meaning if used on a [`cc_library()`](/versions/7.6.1/reference/be/c-cpp#cc_library) rule. For a C++ library, `linkstatic=True` indicates that only static linking is allowed, so no `.so` will be produced. linkstatic=False does not prevent static libraries from being created. The attribute is meant to control the creation of dynamic libraries.  If `linkstatic=False`, then the build tool will create symlinks to depended-upon shared libraries in the `*.runfiles` area. |
 | `local_defines` | List of strings; default is `[]` List of defines to add to the compile line. Subject to ["Make" variable](/versions/7.6.1/reference/be/make-variables) substitution and [Bourne shell tokenization](/versions/7.6.1/reference/be/common-definitions#sh-tokenization). Each string, which must consist of a single Bourne shell token, is prepended with `-D` and added to the compile command line for this target, but not to its dependents. |
 | `malloc` | [Label](/versions/7.6.1/concepts/labels); default is `"@bazel_tools//tools/cpp:malloc"` Override the default dependency on malloc. By default, C++ binaries are linked against `//tools/cpp:malloc`, which is an empty library so the binary ends up using libc malloc. This label must refer to a `cc_library`. If compilation is for a non-C++ rule, this option has no effect. The value of this attribute is ignored if `linkshared=True` is specified. |
@@ -310,7 +310,7 @@ provided by Bazel only support this feature with clang on Unix and macOS.
 | `implementation_deps` | List of [labels](/versions/7.6.1/concepts/labels); default is `[]` The list of other libraries that the library target depends on. Unlike with `deps`, the headers and include paths of these libraries (and all their transitive deps) are only used for compilation of this library, and not libraries that depend on it. Libraries specified with `implementation_deps` are still linked in binary targets that depend on this library. For now usage is limited to cc\_libraries and guarded by the flag `--experimental_cc_implementation_deps`. |
 | `include_prefix` | String; default is `""` The prefix to add to the paths of the headers of this rule. When set, the headers in the `hdrs` attribute of this rule are accessible at is the value of this attribute prepended to their repository-relative path. The prefix in the `strip_include_prefix` attribute is removed before this prefix is added. |
 | `includes` | List of strings; default is `[]` List of include dirs to be added to the compile line. Subject to ["Make variable"](/versions/7.6.1/reference/be/make-variables) substitution. Each string is prepended with `-isystem` and added to `COPTS`. Unlike [COPTS](#cc_binary.copts), these flags are added for this rule and every rule that depends on it. (Note: not the rules it depends upon!) Be very careful, since this may have far-reaching effects. When in doubt, add "-I" flags to [COPTS](#cc_binary.copts) instead.  Headers must be added to srcs or hdrs, otherwise they will not be available to dependent rules when compilation is sandboxed (the default). |
-| `linkopts` | List of strings; default is `[]` Add these flags to the C++ linker command. Subject to ["Make" variable](make-variables) substitution, [Bourne shell tokenization](common-definitions#sh-tokenization) and [label expansion](common-definitions#label-expansion). Each string in this attribute is added to `LINKOPTS` before linking the binary target. Each element of this list that does not start with `$` or `-` is assumed to be the label of a target in `deps`. The list of files generated by that target is appended to the linker options. An error is reported if the label is invalid, or is not declared in `deps`. |
+| `linkopts` | List of strings; default is `[]` Add these flags to the C++ linker command. Subject to ["Make" variable](/versions/7.6.1/reference/be/make-variables) substitution, [Bourne shell tokenization](/versions/7.6.1/reference/be/common-definitions#sh-tokenization) and [label expansion](/versions/7.6.1/reference/be/common-definitions#label-expansion). Each string in this attribute is added to `LINKOPTS` before linking the binary target. Each element of this list that does not start with `$` or `-` is assumed to be the label of a target in `deps`. The list of files generated by that target is appended to the linker options. An error is reported if the label is invalid, or is not declared in `deps`. |
 | `linkstamp` | [Label](/versions/7.6.1/concepts/labels); default is `None` Simultaneously compiles and links the specified C++ source file into the final binary. This trickery is required to introduce timestamp information into binaries; if we compiled the source file to an object file in the usual way, the timestamp would be incorrect. A linkstamp compilation may not include any particular set of compiler flags and so should not depend on any particular header, compiler option, or other build variable. *This option should only be needed in the `base` package.* |
 | `linkstatic` | Boolean; default is `False` For [`cc_binary`](/versions/7.6.1/reference/be/c-cpp#cc_binary) and [`cc_test`](/versions/7.6.1/reference/be/c-cpp#cc_test): link the binary in static mode. For `cc_library.linkstatic`: see below. By default this option is on for `cc_binary` and off for the rest.  If enabled and this is a binary or test, this option tells the build tool to link in `.a`'s instead of `.so`'s for user libraries whenever possible. Some system libraries may still be linked dynamically, as are libraries for which there is no static library. So the resulting executable will still be dynamically linked, hence only *mostly* static.  There are really three different ways to link an executable:   * STATIC with fully\_static\_link feature, in which everything is linked statically;   e.g. "`gcc -static foo.o libbar.a libbaz.a -lm`".    This mode is enabled by specifying `fully_static_link` in the   [`features`](/versions/7.6.1/reference/be/common-definitions#features) attribute. * STATIC, in which all user libraries are linked statically (if a static   version is available), but where system libraries (excluding C/C++ runtime libraries)   are linked dynamically, e.g. "`gcc foo.o libfoo.a libbaz.a -lm`".    This mode is enabled by specifying `linkstatic=True`. * DYNAMIC, in which all libraries are linked dynamically (if a dynamic version is   available), e.g. "`gcc foo.o libfoo.so libbaz.so -lm`".    This mode is enabled by specifying `linkstatic=False`.   The `linkstatic` attribute has a different meaning if used on a [`cc_library()`](/versions/7.6.1/reference/be/c-cpp#cc_library) rule. For a C++ library, `linkstatic=True` indicates that only static linking is allowed, so no `.so` will be produced. linkstatic=False does not prevent static libraries from being created. The attribute is meant to control the creation of dynamic libraries.  If `linkstatic=False`, then the build tool will create symlinks to depended-upon shared libraries in the `*.runfiles` area. |
 | `local_defines` | List of strings; default is `[]` List of defines to add to the compile line. Subject to ["Make" variable](/versions/7.6.1/reference/be/make-variables) substitution and [Bourne shell tokenization](/versions/7.6.1/reference/be/common-definitions#sh-tokenization). Each string, which must consist of a single Bourne shell token, is prepended with `-D` and added to the compile command line for this target, but not to its dependents. |
@@ -329,7 +329,7 @@ cc_proto_library(name, deps, data, compatible_with, deprecation, distribs, exec_
 
 `cc_proto_library` generates C++ code from `.proto` files.
 
-`deps` must point to [`proto_library`](protocol-buffer#proto_library) rules.
+`deps` must point to [`proto_library`](/versions/7.6.1/reference/be/protocol-buffer#proto_library) rules.
 
 Example:
 
@@ -354,7 +354,7 @@ proto_library(
 | Attributes | |
 | --- | --- |
 | `name` | [Name](/versions/7.6.1/concepts/labels#target-names); required  A unique name for this target. |
-| `deps` | List of [labels](/versions/7.6.1/concepts/labels); default is `[]` The list of [`proto_library`](protocol-buffer#proto_library) rules to generate C++ code for. |
+| `deps` | List of [labels](/versions/7.6.1/concepts/labels); default is `[]` The list of [`proto_library`](/versions/7.6.1/reference/be/protocol-buffer#proto_library) rules to generate C++ code for. |
 
 ## cc\_shared\_library
 
@@ -704,7 +704,7 @@ cc_test(name, deps, srcs, data, additional_linker_inputs, args, compatible_with,
 | `defines` | List of strings; default is `[]` List of defines to add to the compile line. Subject to ["Make" variable](/versions/7.6.1/reference/be/make-variables) substitution and [Bourne shell tokenization](/versions/7.6.1/reference/be/common-definitions#sh-tokenization). Each string, which must consist of a single Bourne shell token, is prepended with `-D` and added to the compile command line to this target, as well as to every rule that depends on it. Be very careful, since this may have far-reaching effects. When in doubt, add define values to [`local_defines`](#cc_binary.local_defines) instead. |
 | `includes` | List of strings; default is `[]` List of include dirs to be added to the compile line. Subject to ["Make variable"](/versions/7.6.1/reference/be/make-variables) substitution. Each string is prepended with `-isystem` and added to `COPTS`. Unlike [COPTS](#cc_binary.copts), these flags are added for this rule and every rule that depends on it. (Note: not the rules it depends upon!) Be very careful, since this may have far-reaching effects. When in doubt, add "-I" flags to [COPTS](#cc_binary.copts) instead.  Headers must be added to srcs or hdrs, otherwise they will not be available to dependent rules when compilation is sandboxed (the default). |
 | `link_extra_lib` | [Label](/versions/7.6.1/concepts/labels); default is `"@bazel_tools//tools/cpp:link_extra_lib"` Control linking of extra libraries. By default, C++ binaries are linked against `//tools/cpp:link_extra_lib`, which by default depends on the label flag `//tools/cpp:link_extra_libs`. Without setting the flag, this library is empty by default. Setting the label flag allows linking optional dependencies, such as overrides for weak symbols, interceptors for shared library functions, or special runtime libraries (for malloc replacements, prefer `malloc` or `--custom_malloc`). Setting this attribute to `None` disables this behaviour. |
-| `linkopts` | List of strings; default is `[]` Add these flags to the C++ linker command. Subject to ["Make" variable](make-variables) substitution, [Bourne shell tokenization](common-definitions#sh-tokenization) and [label expansion](common-definitions#label-expansion). Each string in this attribute is added to `LINKOPTS` before linking the binary target. Each element of this list that does not start with `$` or `-` is assumed to be the label of a target in `deps`. The list of files generated by that target is appended to the linker options. An error is reported if the label is invalid, or is not declared in `deps`. |
+| `linkopts` | List of strings; default is `[]` Add these flags to the C++ linker command. Subject to ["Make" variable](/versions/7.6.1/reference/be/make-variables) substitution, [Bourne shell tokenization](/versions/7.6.1/reference/be/common-definitions#sh-tokenization) and [label expansion](/versions/7.6.1/reference/be/common-definitions#label-expansion). Each string in this attribute is added to `LINKOPTS` before linking the binary target. Each element of this list that does not start with `$` or `-` is assumed to be the label of a target in `deps`. The list of files generated by that target is appended to the linker options. An error is reported if the label is invalid, or is not declared in `deps`. |
 | `linkstatic` | Boolean; default is `False` For [`cc_binary`](/versions/7.6.1/reference/be/c-cpp#cc_binary) and [`cc_test`](/versions/7.6.1/reference/be/c-cpp#cc_test): link the binary in static mode. For `cc_library.linkstatic`: see below. By default this option is on for `cc_binary` and off for the rest.  If enabled and this is a binary or test, this option tells the build tool to link in `.a`'s instead of `.so`'s for user libraries whenever possible. Some system libraries may still be linked dynamically, as are libraries for which there is no static library. So the resulting executable will still be dynamically linked, hence only *mostly* static.  There are really three different ways to link an executable:   * STATIC with fully\_static\_link feature, in which everything is linked statically;   e.g. "`gcc -static foo.o libbar.a libbaz.a -lm`".    This mode is enabled by specifying `fully_static_link` in the   [`features`](/versions/7.6.1/reference/be/common-definitions#features) attribute. * STATIC, in which all user libraries are linked statically (if a static   version is available), but where system libraries (excluding C/C++ runtime libraries)   are linked dynamically, e.g. "`gcc foo.o libfoo.a libbaz.a -lm`".    This mode is enabled by specifying `linkstatic=True`. * DYNAMIC, in which all libraries are linked dynamically (if a dynamic version is   available), e.g. "`gcc foo.o libfoo.so libbaz.so -lm`".    This mode is enabled by specifying `linkstatic=False`.   The `linkstatic` attribute has a different meaning if used on a [`cc_library()`](/versions/7.6.1/reference/be/c-cpp#cc_library) rule. For a C++ library, `linkstatic=True` indicates that only static linking is allowed, so no `.so` will be produced. linkstatic=False does not prevent static libraries from being created. The attribute is meant to control the creation of dynamic libraries.  If `linkstatic=False`, then the build tool will create symlinks to depended-upon shared libraries in the `*.runfiles` area. |
 | `local_defines` | List of strings; default is `[]` List of defines to add to the compile line. Subject to ["Make" variable](/versions/7.6.1/reference/be/make-variables) substitution and [Bourne shell tokenization](/versions/7.6.1/reference/be/common-definitions#sh-tokenization). Each string, which must consist of a single Bourne shell token, is prepended with `-D` and added to the compile command line for this target, but not to its dependents. |
 | `malloc` | [Label](/versions/7.6.1/concepts/labels); default is `"@bazel_tools//tools/cpp:malloc"` Override the default dependency on malloc. By default, C++ binaries are linked against `//tools/cpp:malloc`, which is an empty library so the binary ends up using libc malloc. This label must refer to a `cc_library`. If compilation is for a non-C++ rule, this option has no effect. The value of this attribute is ignored if `linkshared=True` is specified. |
@@ -761,7 +761,7 @@ unnecessarily when invoking `bazel build //...`
 | `supports_header_parsing` | Boolean; default is `False` Set to True when cc\_toolchain supports header parsing actions. |
 | `supports_param_files` | Boolean; default is `True` Set to True when cc\_toolchain supports using param files for linking actions. |
 | `toolchain_config` | [Label](/versions/7.6.1/concepts/labels); required The label of the rule providing `cc_toolchain_config_info`. |
-| `toolchain_identifier` | String; [nonconfigurable](common-definitions#configurable-attributes); default is `""` The identifier used to match this cc\_toolchain with the corresponding crosstool\_config.toolchain. Until issue [#5380](https://github.com/bazelbuild/bazel/issues/5380) is fixed this is the recommended way of associating `cc_toolchain` with `CROSSTOOL.toolchain`. It will be replaced by the `toolchain_config` attribute ([#5380](https://github.com/bazelbuild/bazel/issues/5380)). |
+| `toolchain_identifier` | String; [nonconfigurable](/versions/7.6.1/reference/be/common-definitions#configurable-attributes); default is `""` The identifier used to match this cc\_toolchain with the corresponding crosstool\_config.toolchain. Until issue [#5380](https://github.com/bazelbuild/bazel/issues/5380) is fixed this is the recommended way of associating `cc_toolchain` with `CROSSTOOL.toolchain`. It will be replaced by the `toolchain_config` attribute ([#5380](https://github.com/bazelbuild/bazel/issues/5380)). |
 
 ## cc\_toolchain\_suite
 
@@ -787,4 +787,4 @@ See also this
 | Attributes | |
 | --- | --- |
 | `name` | [Name](/versions/7.6.1/concepts/labels#target-names); required  A unique name for this target. |
-| `toolchains` | Dictionary mapping strings to [labels](/versions/7.6.1/concepts/labels); [nonconfigurable](common-definitions#configurable-attributes); required A map from "<cpu>" or "<cpu>|<compiler>" strings to a `cc_toolchain` label. "<cpu>" will be used when only `--cpu` is passed to Bazel, and "<cpu>|<compiler>" will be used when both `--cpu` and `--compiler` are passed to Bazel. Example: ```           cc_toolchain_suite(             name = "toolchain",             toolchains = \{               "piii|gcc": ":my_cc_toolchain_for_piii_using_gcc",               "piii": ":my_cc_toolchain_for_piii_using_default_compiler",             \},           ) ``` |
\ No newline at end of file
+| `toolchains` | Dictionary mapping strings to [labels](/versions/7.6.1/concepts/labels); [nonconfigurable](/versions/7.6.1/reference/be/common-definitions#configurable-attributes); required A map from "<cpu>" or "<cpu>|<compiler>" strings to a `cc_toolchain` label. "<cpu>" will be used when only `--cpu` is passed to Bazel, and "<cpu>|<compiler>" will be used when both `--cpu` and `--compiler` are passed to Bazel. Example: ```           cc_toolchain_suite(             name = "toolchain",             toolchains = \{               "piii|gcc": ":my_cc_toolchain_for_piii_using_gcc",               "piii": ":my_cc_toolchain_for_piii_using_default_compiler",             \},           ) ``` |
\ No newline at end of file
diff --git a/versions/7.6.1/reference/be/common-definitions.mdx b/versions/7.6.1/reference/be/common-definitions.mdx
index 4c5b2bd4..23724280 100644
--- a/versions/7.6.1/reference/be/common-definitions.mdx
+++ b/versions/7.6.1/reference/be/common-definitions.mdx
@@ -75,11 +75,11 @@ rules.
 | `deprecation` | String; [nonconfigurable](#configurable-attributes); default is `None`  An explanatory warning message associated with this target. Typically this is used to notify users that a target has become obsolete, or has become superseded by another rule, is private to a package, or is perhaps considered harmful for some reason. It is a good idea to include some reference (like a webpage, a bug number or example migration CLs) so that one can easily find out what changes are required to avoid the message. If there is a new target that can be used as a drop in replacement, it is a good idea to just migrate all users of the old target.  This attribute has no effect on the way things are built, but it may affect a build tool's diagnostic output. The build tool issues a warning when a rule with a `deprecation` attribute is depended upon by a target in another package.  Intra-package dependencies are exempt from this warning, so that, for example, building the tests of a deprecated rule does not encounter a warning.  If a deprecated target depends on another deprecated target, no warning message is issued.  Once people have stopped using it, the target can be removed. |
 | `distribs` | List of strings; [nonconfigurable](#configurable-attributes); default is `[]`  A list of distribution-method strings to be used for this particular target. This is part of a deprecated licensing API that Bazel no longer uses. Don't use this. |
 | `exec_compatible_with` | List of [labels](/versions/7.6.1/concepts/labels); [nonconfigurable](#configurable-attributes); default is `[]`  A list of `constraint_values` that must be present in the execution platform for this target. This is in addition to any constraints already set by the rule type. Constraints are used to restrict the list of available execution platforms. For more details, see the description of [toolchain resolution](/versions/7.6.1/docs/toolchains#toolchain-resolution). |
-| `exec_properties` | Dictionary of strings; default is `{}`  A dictionary of strings that will be added to the `exec_properties` of a platform selected for this target. See `exec_properties` of the [platform](platform) rule.  If a key is present in both the platform and target-level properties, the value will be taken from the target. |
+| `exec_properties` | Dictionary of strings; default is `{}`  A dictionary of strings that will be added to the `exec_properties` of a platform selected for this target. See `exec_properties` of the [platform](/versions/7.6.1/reference/be/platform) rule.  If a key is present in both the platform and target-level properties, the value will be taken from the target. |
 | `features` | List of *feature* strings; default is `[]`  A feature is string tag that can be enabled or disabled on a target. The meaning of a feature depends on the rule itself.  This `features` attribute is combined with the [package](/versions/7.6.1/reference/be/functions#package) level `features` attribute. For example, if the features ["a", "b"] are enabled on the package level, and a target's `features` attribute contains ["-a", "c"], the features enabled for the rule will be "b" and "c". [See example](https://github.com/bazelbuild/examples/blob/main/rules/features/BUILD). |
 | `restricted_to` | List of [labels](/versions/7.6.1/concepts/labels); [nonconfigurable](#configurable-attributes); default is `[]`  The list of environments this target can be built for, *instead* of default-supported environments.  This is part of Bazel's constraint system. See `compatible_with` for details. |
 | `tags` | List of strings; [nonconfigurable](#configurable-attributes); default is `[]`  *Tags* can be used on any rule. *Tags* on test and `test_suite` rules are useful for categorizing the tests. *Tags* on non-test targets are used to control sandboxed execution of `genrule`s and [Starlark](/versions/7.6.1/rules/concepts) actions, and for parsing by humans and/or external tools.  Bazel modifies the behavior of its sandboxing code if it finds the following keywords in the `tags` attribute of any test or `genrule` target, or the keys of `execution_requirements` for any Starlark action.   * `no-sandbox` keyword results in the action or test never being   sandboxed; it can still be cached or run remotely - use `no-cache`   or `no-remote` to prevent either or both of those. * `no-cache` keyword results in the action or test never being   cached (remotely or locally) * `no-remote-cache` keyword results in the action or test never being   cached remotely (but it may be cached locally; it may also be executed remotely).   Note: for the purposes of this tag, the disk-cache is considered a local cache, whereas   the http and gRPC caches are considered remote.   If a combination of local disk cache and remote cache are used (combined cache),   it's treated as a remote cache and disabled entirely unless `--incompatible_remote_results_ignore_disk`   is set in which case the local components will be used. * `no-remote-exec` keyword results in the action or test never being   executed remotely (but it may be cached remotely). * `no-remote` keyword prevents the action or test from being executed remotely or   cached remotely. This is equivalent to using both   `no-remote-cache` and `no-remote-exec`. * `no-remote-cache-upload` keyword disables upload part of remote caching of a spawn.   it does not disable remote execution. * `local` keyword precludes the action or test from being remotely cached,   remotely executed, or run inside the sandbox.   For genrules and tests, marking the rule with the `local = True`   attribute has the same effect. * `requires-network` keyword allows access to the external   network from inside the sandbox. This tag only has an effect if sandboxing   is enabled. * `block-network` keyword blocks access to the external   network from inside the sandbox. In this case, only communication   with localhost is allowed. This tag only has an effect if sandboxing is   enabled. * `requires-fakeroot` runs the test or action as uid and gid 0 (i.e., the root   user). This is only supported on Linux. This tag takes precedence over the   `--sandbox_fake_username` command-line option.   *Tags* on tests are generally used to annotate a test's role in your debug and release process. Typically, tags are most useful for C++ and Python tests, which lack any runtime annotation ability. The use of tags and size elements gives flexibility in assembling suites of tests based around codebase check-in policy.  Bazel modifies test running behavior if it finds the following keywords in the `tags` attribute of the test rule:   * `exclusive` will force the test to be run in the   "exclusive" mode, ensuring that no other tests are running at the   same time. Such tests will be executed in serial fashion after all build   activity and non-exclusive tests have been completed. Remote execution is   disabled for such tests because Bazel doesn't have control over what's   running on a remote machine. * `exclusive-if-local` will force the test to be run in the   "exclusive" mode if it is executed locally, but will run the test in parallel if it's   executed remotely. * `manual` keyword will exclude the target from expansion of target pattern wildcards   (`...`, `:*`, `:all`, etc.) and `test_suite` rules   which do not list the test explicitly when computing the set of top-level targets to build/run   for the `build`, `test`, and `coverage` commands. It does not   affect target wildcard or test suite expansion in other contexts, including the   `query` command. Note that `manual` does not imply that a target should   not be built/run automatically by continuous build/test systems. For example, it may be   desirable to exclude a target from `bazel test ...` because it requires specific   Bazel flags, but still have it included in properly-configured presubmit or continuous test   runs. * `external` keyword will force test to be unconditionally   executed (regardless of `--cache_test_results`   value).  See [Tag Conventions](/versions/7.6.1/reference/test-encyclopedia#tag-conventions) in the Test Encyclopedia for more conventions on tags attached to test targets. |
-| `target_compatible_with` | List of [labels](/versions/7.6.1/concepts/labels); default is `[]`  A list of `constraint_value`s that must be present in the target platform for this target to be considered *compatible*. This is in addition to any constraints already set by the rule type. If the target platform does not satisfy all listed constraints then the target is considered *incompatible*. Incompatible targets are skipped for building and testing when the target pattern is expanded (e.g. `//...`, `:all`). When explicitly specified on the command line, incompatible targets cause Bazel to print an error and cause a build or test failure.  Targets that transitively depend on incompatible targets are themselves considered incompatible. They are also skipped for building and testing.  An empty list (which is the default) signifies that the target is compatible with all platforms. All rules other than [Workspace Rules](workspace) support this attribute. For some rules this attribute has no effect. For example, specifying `target_compatible_with` for a `cc_toolchain` is not useful. See the [Platforms](/versions/7.6.1/docs/platforms#skipping-incompatible-targets) page for more information about incompatible target skipping. |
+| `target_compatible_with` | List of [labels](/versions/7.6.1/concepts/labels); default is `[]`  A list of `constraint_value`s that must be present in the target platform for this target to be considered *compatible*. This is in addition to any constraints already set by the rule type. If the target platform does not satisfy all listed constraints then the target is considered *incompatible*. Incompatible targets are skipped for building and testing when the target pattern is expanded (e.g. `//...`, `:all`). When explicitly specified on the command line, incompatible targets cause Bazel to print an error and cause a build or test failure.  Targets that transitively depend on incompatible targets are themselves considered incompatible. They are also skipped for building and testing.  An empty list (which is the default) signifies that the target is compatible with all platforms. All rules other than [Workspace Rules](/versions/7.6.1/reference/be/workspace) support this attribute. For some rules this attribute has no effect. For example, specifying `target_compatible_with` for a `cc_toolchain` is not useful. See the [Platforms](/versions/7.6.1/docs/platforms#skipping-incompatible-targets) page for more information about incompatible target skipping. |
 | `testonly` | Boolean; [nonconfigurable](#configurable-attributes); default is `False` except for test and test suite targets  If `True`, only testonly targets (such as tests) can depend on this target.  Equivalently, a rule that is not `testonly` is not allowed to depend on any rule that is `testonly`.  Tests (`*_test` rules) and test suites ([test\_suite](/versions/7.6.1/reference/be/general#test_suite) rules) are `testonly` by default.  This attribute is intended to mean that the target should not be contained in binaries that are released to production.  Because testonly is enforced at build time, not run time, and propagates virally through the dependency tree, it should be applied judiciously. For example, stubs and fakes that are useful for unit tests may also be useful for integration tests involving the same binaries that will be released to production, and therefore should probably not be marked testonly. Conversely, rules that are dangerous to even link in, perhaps because they unconditionally override normal behavior, should definitely be marked testonly. |
 | `toolchains` | List of [labels](/versions/7.6.1/concepts/labels); [nonconfigurable](#configurable-attributes); default is `[]`  The set of targets whose [Make variables](/versions/7.6.1/reference/be/make-variables) this target is allowed to access. These targets are either instances of rules that provide `TemplateVariableInfo` or special targets for toolchain types built into Bazel. These include:  * `@bazel_tools//tools/cpp:current_cc_toolchain`* `@bazel_tools//tools/jdk:current_java_runtime`   Note that this is distinct from the concept of [toolchain resolution](/versions/7.6.1/docs/toolchains#toolchain-resolution) that is used by rule implementations for platform-dependent configuration. You cannot use this attribute to determine which specific `cc_toolchain` or `java_toolchain` a target will use. |
 | `visibility` | List of [labels](/versions/7.6.1/concepts/labels); [nonconfigurable](#configurable-attributes); default is `default_visibility` from [package](/versions/7.6.1/reference/be/functions#package) if specified, or `"//visibility:private"` otherwise  The `visibility` attribute on a target controls whether the target can be used in other packages. See the documentation for [visibility](/versions/7.6.1/concepts/visibility). |
diff --git a/versions/7.6.1/reference/be/functions.mdx b/versions/7.6.1/reference/be/functions.mdx
index 84be7609..2e024ca2 100644
--- a/versions/7.6.1/reference/be/functions.mdx
+++ b/versions/7.6.1/reference/be/functions.mdx
@@ -34,9 +34,9 @@ file, before any rule.
 | --- | --- |
 | `default_applicable_licenses` | Alias for [`default_package_metadata`](#package.default_package_metadata). |
 | `default_visibility` | List of [labels](/versions/7.6.1/concepts/labels); default is `[]`  The default visibility of the rules in this package.  Every rule in this package has the visibility specified in this attribute, unless otherwise specified in the `visibility` attribute of the rule. For detailed information about the syntax of this attribute, see the documentation of [visibility](/versions/7.6.1/concepts/visibility). The package default visibility does not apply to [exports\_files](#exports_files), which is public by default. |
-| `default_deprecation` | String; default is `""`  Sets the default [`deprecation`](common-definitions#common.deprecation) message for all rules in this package. |
+| `default_deprecation` | String; default is `""`  Sets the default [`deprecation`](/versions/7.6.1/reference/be/common-definitions#common.deprecation) message for all rules in this package. |
 | `default_package_metadata` | List of [labels](/versions/7.6.1/concepts/labels); default is `[]`  Sets a default list of metadata targets which apply to all other targets in the package. These are typically targets related to OSS package and license declarations. See [rules\_license](https://github.com/bazelbuild/rules_license) for examples. |
-| `default_testonly` | Boolean; default is `False` except as noted  Sets the default [`testonly`](common-definitions#common.testonly) property for all rules in this package.  In packages under `javatests` the default value is `True`. |
+| `default_testonly` | Boolean; default is `False` except as noted  Sets the default [`testonly`](/versions/7.6.1/reference/be/common-definitions#common.testonly) property for all rules in this package.  In packages under `javatests` the default value is `True`. |
 | `features` | List strings; default is `[]`  Sets various flags that affect the semantics of this BUILD file.  This feature is mainly used by the people working on the build system to tag packages that need some kind of special handling. Do not use this unless explicitly requested by someone working on the build system. |
 
 ### Examples
@@ -66,7 +66,7 @@ visible target can only be referenced within its own package (not subpackages).
 In between these extremes, a target may allow access to its own package plus any
 of the packages described by one or more package groups. For a more detailed
 explanation of the visibility system, see the
-[visibility](common-definitions#common.visibility)
+[visibility](/versions/7.6.1/reference/be/common-definitions#common.visibility)
 attribute.
 
 A given package is considered to be in the group if it either matches the
@@ -159,7 +159,7 @@ visibility declaration can also be specified; in this case, the files will be
 visible to the targets specified. If no visibility is specified, the files
 will be visible to every package, even if a package default visibility was
 specified in the `package`
-function. The [licenses](common-definitions#common.licenses)
+function. The [licenses](/versions/7.6.1/reference/be/common-definitions#common.licenses)
 can also be specified.
 
 ### Example
@@ -250,8 +250,7 @@ There are several important limitations and caveats:
    package called "Foo.java" (which is allowed, though Bazel warns about it),
    then the consumer of the `glob()` will use the "Foo.java" rule
    (its outputs) instead of the "Foo.java" file. See
-   [GitHub
-   issue #10395](https://github.com/bazelbuild/bazel/issues/10395#issuecomment-583714657) for more details.
+   [GitHub issue #10395](https://github.com/bazelbuild/bazel/issues/10395#issuecomment-583714657) for more details.
 3. Globs may match files in subdirectories. And subdirectory names
    may be wildcarded. However...
 4. Labels are not allowed to cross the package boundary and glob does
@@ -397,7 +396,7 @@ select(
 ```
 
 `select()` is the helper function that makes a rule attribute
-[configurable](common-definitions#configurable-attributes).
+[configurable](/versions/7.6.1/reference/be/common-definitions#configurable-attributes).
 It can replace the right-hand side of
 *almost*
 any attribute assignment so its value depends on command-line Bazel flags.
diff --git a/versions/7.6.1/reference/be/general.mdx b/versions/7.6.1/reference/be/general.mdx
index 7164000d..24efb9f2 100644
--- a/versions/7.6.1/reference/be/general.mdx
+++ b/versions/7.6.1/reference/be/general.mdx
@@ -158,9 +158,9 @@ some build targets.
   [here](/versions/7.6.1/reference/be/common-definitions#configurable-attributes) for more discussion.
 * Avoid repeating identical `config_setting` definitions in different packages.
   Instead, reference a common `config_setting` that defined in a canonical package.
-* [`values`](general#config_setting.values),
-  [`define_values`](general#config_setting.define_values), and
-  [`constraint_values`](general#config_setting.constraint_values)
+* [`values`](/versions/7.6.1/reference/be/general#config_setting.values),
+  [`define_values`](/versions/7.6.1/reference/be/general#config_setting.define_values), and
+  [`constraint_values`](/versions/7.6.1/reference/be/general#config_setting.constraint_values)
   can be used in any combination in the same `config_setting` but at least one must
   be set for any given `config_setting`.
 
@@ -169,10 +169,10 @@ some build targets.
 | Attributes | |
 | --- | --- |
 | `name` | [Name](/versions/7.6.1/concepts/labels#target-names); required  A unique name for this target. |
-| `constraint_values` | List of [labels](/versions/7.6.1/concepts/labels); [nonconfigurable](common-definitions#configurable-attributes); default is `[]` The minimum set of `constraint_values` that the target platform must specify in order to match this `config_setting`. (The execution platform is not considered here.) Any additional constraint values that the platform has are ignored. See [Configurable Build Attributes](https://bazel.build/versions/7.6.1/docs/configurable-attributes#platforms) for details. In the case where two `config_setting`s both match in the same `select`, this attribute is not considered for the purpose of determining whether one of the `config_setting`s is a specialization of the other. In other words, one `config_setting` cannot match a platform more strongly than another. |
-| `define_values` | Dictionary: String -> String; [nonconfigurable](common-definitions#configurable-attributes); default is `{}` The same as [`values`](/versions/7.6.1/reference/be/general#config_setting.values) but specifically for the `--define` flag. `--define` is special because its syntax (`--define KEY=VAL`) means `KEY=VAL` is a *value* from a Bazel flag perspective.  That means:  ```             config_setting(                 name = "a_and_b",                 values = {                     "define": "a=1",                     "define": "b=2",                 }) ```   doesn't work because the same key (`define`) appears twice in the dictionary. This attribute solves that problem:  ```             config_setting(                 name = "a_and_b",                 define_values = {                     "a": "1",                     "b": "2",                 }) ```   correctly matches `bazel build //foo --define a=1 --define b=2`. `--define` can still appear in [`values`](/versions/7.6.1/reference/be/general#config_setting.values) with normal flag syntax, and can be mixed freely with this attribute as long as dictionary keys remain distinct. |
-| `flag_values` | Dictionary: [label](/versions/7.6.1/concepts/labels) -> String; [nonconfigurable](common-definitions#configurable-attributes); default is `{}` The same as [`values`](/versions/7.6.1/reference/be/general#config_setting.values) but for [user-defined build flags](https://bazel.build/versions/7.6.1/rules/config#user-defined-build-settings). This is a distinct attribute because user-defined flags are referenced as labels while built-in flags are referenced as arbitrary strings. |
-| `values` | Dictionary: String -> String; [nonconfigurable](common-definitions#configurable-attributes); default is `{}` The set of configuration values that match this rule (expressed as build flags) This rule inherits the configuration of the configured target that references it in a `select` statement. It is considered to "match" a Bazel invocation if, for every entry in the dictionary, its configuration matches the entry's expected value. For example `values = {"compilation_mode": "opt"}` matches the invocations `bazel build --compilation_mode=opt ...` and `bazel build -c opt ...` on target-configured rules.  For convenience's sake, configuration values are specified as build flags (without the preceding `"--"`). But keep in mind that the two are not the same. This is because targets can be built in multiple configurations within the same build. For example, an exec configuration's "cpu" matches the value of `--host_cpu`, not `--cpu`. So different instances of the same `config_setting` may match the same invocation differently depending on the configuration of the rule using them.  If a flag is not explicitly set at the command line, its default value is used. If a key appears multiple times in the dictionary, only the last instance is used. If a key references a flag that can be set multiple times on the command line (e.g. `bazel build --copt=foo --copt=bar --copt=baz ...`), a match occurs if *any* of those settings match. |
+| `constraint_values` | List of [labels](/versions/7.6.1/concepts/labels); [nonconfigurable](/versions/7.6.1/reference/be/common-definitions#configurable-attributes); default is `[]` The minimum set of `constraint_values` that the target platform must specify in order to match this `config_setting`. (The execution platform is not considered here.) Any additional constraint values that the platform has are ignored. See [Configurable Build Attributes](https://bazel.build/versions/7.6.1/docs/configurable-attributes#platforms) for details. In the case where two `config_setting`s both match in the same `select`, this attribute is not considered for the purpose of determining whether one of the `config_setting`s is a specialization of the other. In other words, one `config_setting` cannot match a platform more strongly than another. |
+| `define_values` | Dictionary: String -> String; [nonconfigurable](/versions/7.6.1/reference/be/common-definitions#configurable-attributes); default is `{}` The same as [`values`](/versions/7.6.1/reference/be/general#config_setting.values) but specifically for the `--define` flag. `--define` is special because its syntax (`--define KEY=VAL`) means `KEY=VAL` is a *value* from a Bazel flag perspective.  That means:  ```             config_setting(                 name = "a_and_b",                 values = {                     "define": "a=1",                     "define": "b=2",                 }) ```   doesn't work because the same key (`define`) appears twice in the dictionary. This attribute solves that problem:  ```             config_setting(                 name = "a_and_b",                 define_values = {                     "a": "1",                     "b": "2",                 }) ```   correctly matches `bazel build //foo --define a=1 --define b=2`. `--define` can still appear in [`values`](/versions/7.6.1/reference/be/general#config_setting.values) with normal flag syntax, and can be mixed freely with this attribute as long as dictionary keys remain distinct. |
+| `flag_values` | Dictionary: [label](/versions/7.6.1/concepts/labels) -> String; [nonconfigurable](/versions/7.6.1/reference/be/common-definitions#configurable-attributes); default is `{}` The same as [`values`](/versions/7.6.1/reference/be/general#config_setting.values) but for [user-defined build flags](https://bazel.build/versions/7.6.1/rules/config#user-defined-build-settings). This is a distinct attribute because user-defined flags are referenced as labels while built-in flags are referenced as arbitrary strings. |
+| `values` | Dictionary: String -> String; [nonconfigurable](/versions/7.6.1/reference/be/common-definitions#configurable-attributes); default is `{}` The set of configuration values that match this rule (expressed as build flags) This rule inherits the configuration of the configured target that references it in a `select` statement. It is considered to "match" a Bazel invocation if, for every entry in the dictionary, its configuration matches the entry's expected value. For example `values = {"compilation_mode": "opt"}` matches the invocations `bazel build --compilation_mode=opt ...` and `bazel build -c opt ...` on target-configured rules.  For convenience's sake, configuration values are specified as build flags (without the preceding `"--"`). But keep in mind that the two are not the same. This is because targets can be built in multiple configurations within the same build. For example, an exec configuration's "cpu" matches the value of `--host_cpu`, not `--cpu`. So different instances of the same `config_setting` may match the same invocation differently depending on the configuration of the rule using them.  If a flag is not explicitly set at the command line, its default value is used. If a key appears multiple times in the dictionary, only the last instance is used. If a key references a flag that can be set multiple times on the command line (e.g. `bazel build --copt=foo --copt=bar --copt=baz ...`), a match occurs if *any* of those settings match. |
 
 ## filegroup
 
@@ -452,7 +452,7 @@ genrule(
 | --- | --- |
 | `name` | [Name](/versions/7.6.1/concepts/labels#target-names); required  A unique name for this target.  You may refer to this rule by name in the `srcs` or `deps` section of other `BUILD` rules. If the rule generates source files, you should use the `srcs` attribute. |
 | `srcs` | List of [labels](/versions/7.6.1/concepts/labels); default is `[]` A list of inputs for this rule, such as source files to process. *This attributes is not suitable to list tools executed by the `cmd`; use the [`tools`](/versions/7.6.1/reference/be/general#genrule.tools) attribute for them instead.*  The build system ensures these prerequisites are built before running the genrule command; they are built using the same configuration as the original build request. The names of the files of these prerequisites are available to the command as a space-separated list in `$(SRCS)`; alternatively the path of an individual `srcs` target `//x:y` can be obtained using `$(location //x:y)`, or using `$<` provided it's the only entry in `srcs`. |
-| `outs` | List of [filenames](/versions/7.6.1/concepts/build-ref#filename); [nonconfigurable](common-definitions#configurable-attributes); required A list of files generated by this rule. Output files must not cross package boundaries. Output filenames are interpreted as relative to the package.  If the `executable` flag is set, `outs` must contain exactly one label.  The genrule command is expected to create each output file at a predetermined location. The location is available in `cmd` using [genrule-specific "Make" variables](/versions/7.6.1/reference/be/make-variables#predefined_genrule_variables) (`$@`, `$(OUTS)`, `$(@D)` or `$(RULEDIR)`) or using [`$(location)`](/versions/7.6.1/reference/be/make-variables#predefined_label_variables) substitution. |
+| `outs` | List of [filenames](/versions/7.6.1/concepts/build-ref#filename); [nonconfigurable](/versions/7.6.1/reference/be/common-definitions#configurable-attributes); required A list of files generated by this rule. Output files must not cross package boundaries. Output filenames are interpreted as relative to the package.  If the `executable` flag is set, `outs` must contain exactly one label.  The genrule command is expected to create each output file at a predetermined location. The location is available in `cmd` using [genrule-specific "Make" variables](/versions/7.6.1/reference/be/make-variables#predefined_genrule_variables) (`$@`, `$(OUTS)`, `$(@D)` or `$(RULEDIR)`) or using [`$(location)`](/versions/7.6.1/reference/be/make-variables#predefined_label_variables) substitution. |
 | `cmd` | String; default is `""` The command to run. Subject to [`$(location)`](/versions/7.6.1/reference/be/make-variables#predefined_label_variables) and ["Make" variable](/versions/7.6.1/reference/be/make-variables) substitution.  1. First [`$(location)`](/versions/7.6.1/reference/be/make-variables#predefined_label_variables) substitution is applied, replacing all occurrences of `$(location     label)` and of `$(locations label)` (and similar    constructions using related variables `execpath`, `execpaths`,    `rootpath` and `rootpaths`). 2. Next, ["Make" variables](/versions/7.6.1/reference/be/make-variables) are expanded. Note that    predefined variables `$(JAVA)`, `$(JAVAC)` and    `$(JAVABASE)` expand under the *exec* configuration, so Java invocations    that run as part of a build step can correctly load shared libraries and other    dependencies. 3. Finally, the resulting command is executed using the Bash shell. If its exit code is    non-zero the command is considered to have failed.  This is the fallback of `cmd_bash`, `cmd_ps` and `cmd_bat`, if none of them are applicable. |
 
 If the command line length exceeds the platform limit (64K on Linux/macOS, 8K on Windows),
@@ -463,11 +463,11 @@ applies to all cmd attributes (`cmd`, `cmd_bash`, `cmd_ps`,
 | `cmd_bash` | String; default is `""` The Bash command to run. This attribute has higher priority than `cmd`. The command is expanded and runs in the exact same way as the `cmd` attribute. |
 | `cmd_bat` | String; default is `""` The Batch command to run on Windows. This attribute has higher priority than `cmd` and `cmd_bash`. The command runs in the similar way as the `cmd` attribute, with the following differences:   * This attribute only applies on Windows. * The command runs with `cmd.exe /c` with the following default arguments:   + `/S` - strip first and last quotes and execute everything else as is.   + `/E:ON` - enable extended command set.   + `/V:ON` - enable delayed variable expansion   + `/D` - ignore AutoRun registry entries. * After [$(location)](/versions/7.6.1/reference/be/make-variables#predefined_label_variables) and   ["Make" variable](/versions/7.6.1/reference/be/make-variables) substitution, the paths will be   expanded to Windows style paths (with backslash). |
 | `cmd_ps` | String; default is `""` The Powershell command to run on Windows. This attribute has higher priority than `cmd`, `cmd_bash` and `cmd_bat`. The command runs in the similar way as the `cmd` attribute, with the following differences:   * This attribute only applies on Windows. * The command runs with `powershell.exe /c`.   To make Powershell easier to use and less error-prone, we run the following commands to set up the environment before executing Powershell command in genrule.   * `Set-ExecutionPolicy -Scope CurrentUser RemoteSigned` - allow running   unsigned scripts. * `$errorActionPreference='Stop'` - In case there are multiple commands   separated by `;`, the action exits immediately if a Powershell CmdLet fails,   but this does **NOT** work for external command. * `$PSDefaultParameterValues['*:Encoding'] = 'utf8'` - change the default   encoding from utf-16 to utf-8. |
-| `executable` | Boolean; [nonconfigurable](common-definitions#configurable-attributes); default is `False` Declare output to be executable. Setting this flag to True means the output is an executable file and can be run using the `run` command. The genrule must produce exactly one output in this case. If this attribute is set, `run` will try executing the file regardless of its content.  Declaring data dependencies for the generated executable is not supported. |
+| `executable` | Boolean; [nonconfigurable](/versions/7.6.1/reference/be/common-definitions#configurable-attributes); default is `False` Declare output to be executable. Setting this flag to True means the output is an executable file and can be run using the `run` command. The genrule must produce exactly one output in this case. If this attribute is set, `run` will try executing the file regardless of its content.  Declaring data dependencies for the generated executable is not supported. |
 | `local` | Boolean; default is `False`  If set to True, this option forces this `genrule` to run using the "local" strategy, which means no remote execution, no sandboxing, no persistent workers.  This is equivalent to providing 'local' as a tag (`tags=["local"]`). |
 | `message` | String; default is `""` A progress message. A progress message that will be printed as this build step is executed. By default, the message is "Generating *output*" (or something equally bland) but you may provide a more specific one. Use this attribute instead of `echo` or other print statements in your `cmd` command, as this allows the build tool to control whether such progress messages are printed or not. |
 | `output_licenses` | Licence type; default is `["none"]` See [`common attributes`](/versions/7.6.1/reference/be/common-definitions#binary.output_licenses) |
-| `output_to_bindir` | Boolean; [nonconfigurable](common-definitions#configurable-attributes); default is `False`  If set to True, this option causes output files to be written into the `bin` directory instead of the `genfiles` directory. |
+| `output_to_bindir` | Boolean; [nonconfigurable](/versions/7.6.1/reference/be/common-definitions#configurable-attributes); default is `False`  If set to True, this option causes output files to be written into the `bin` directory instead of the `genfiles` directory. |
 | `tools` | List of [labels](/versions/7.6.1/concepts/labels); default is `[]` A list of *tool* dependencies for this rule. See the definition of [dependencies](/versions/7.6.1/concepts/build-ref#deps) for more information.   The build system ensures these prerequisites are built before running the genrule command; they are built using the [*exec* configuration](/versions/7.6.1/contribute/guide#configurations), since these tools are executed as part of the build. The path of an individual `tools` target `//x:y` can be obtained using `$(location //x:y)`.  Any `*_binary` or tool to be executed by `cmd` must appear in this list, not in `srcs`, to ensure they are built in the correct configuration. |
 
 ## starlark\_doc\_extract
@@ -557,5 +557,5 @@ test_suite(
 | Attributes | |
 | --- | --- |
 | `name` | [Name](/versions/7.6.1/concepts/labels#target-names); required  A unique name for this target. |
-| `tags` | List of strings; [nonconfigurable](common-definitions#configurable-attributes); default is `[]` List of text tags such as "small" or "database" or "-flaky". Tags may be any valid string. Tags which begin with a "-" character are considered negative tags. The preceding "-" character is not considered part of the tag, so a suite tag of "-small" matches a test's "small" size. All other tags are considered positive tags.  Optionally, to make positive tags more explicit, tags may also begin with the "+" character, which will not be evaluated as part of the text of the tag. It merely makes the positive and negative distinction easier to read.  Only test rules that match **all** of the positive tags and **none** of the negative tags will be included in the test suite. Note that this does not mean that error checking for dependencies on tests that are filtered out is skipped; the dependencies on skipped tests still need to be legal (e.g. not blocked by visibility constraints).  The `manual` tag keyword is treated differently than the above by the "test\_suite expansion" performed by the `blaze test` command on invocations involving wildcard [target patterns](https://bazel.build/versions/7.6.1/docs/build#specifying-build-targets). There, `test_suite` targets tagged "manual" are filtered out (and thus not expanded). This behavior is consistent with how `blaze build` and `blaze test` handle wildcard target patterns in general. Note that this is explicitly different from how `blaze query 'tests(E)'` behaves, as suites are always expanded by the `tests` query function, regardless of the `manual` tag.  Note that a test's `size` is considered a tag for the purpose of filtering.  If you need a `test_suite` that contains tests with mutually exclusive tags (e.g. all small and medium tests), you'll have to create three `test_suite` rules: one for all small tests, one for all medium tests, and one that includes the previous two. |
-| `tests` | List of [labels](/versions/7.6.1/concepts/labels); [nonconfigurable](common-definitions#configurable-attributes); default is `[]` A list of test suites and test targets of any language. Any `*_test` is accepted here, independent of the language. No `*_binary` targets are accepted however, even if they happen to run a test. Filtering by the specified `tags` is only done for tests listed directly in this attribute. If this attribute contains `test_suite`s, the tests inside those will not be filtered by this `test_suite` (they are considered to be filtered already).  If the `tests` attribute is unspecified or empty, the rule will default to including all test rules in the current BUILD file that are not tagged as `manual`. These rules are still subject to `tag` filtering. |
\ No newline at end of file
+| `tags` | List of strings; [nonconfigurable](/versions/7.6.1/reference/be/common-definitions#configurable-attributes); default is `[]` List of text tags such as "small" or "database" or "-flaky". Tags may be any valid string. Tags which begin with a "-" character are considered negative tags. The preceding "-" character is not considered part of the tag, so a suite tag of "-small" matches a test's "small" size. All other tags are considered positive tags.  Optionally, to make positive tags more explicit, tags may also begin with the "+" character, which will not be evaluated as part of the text of the tag. It merely makes the positive and negative distinction easier to read.  Only test rules that match **all** of the positive tags and **none** of the negative tags will be included in the test suite. Note that this does not mean that error checking for dependencies on tests that are filtered out is skipped; the dependencies on skipped tests still need to be legal (e.g. not blocked by visibility constraints).  The `manual` tag keyword is treated differently than the above by the "test\_suite expansion" performed by the `blaze test` command on invocations involving wildcard [target patterns](https://bazel.build/versions/7.6.1/docs/build#specifying-build-targets). There, `test_suite` targets tagged "manual" are filtered out (and thus not expanded). This behavior is consistent with how `blaze build` and `blaze test` handle wildcard target patterns in general. Note that this is explicitly different from how `blaze query 'tests(E)'` behaves, as suites are always expanded by the `tests` query function, regardless of the `manual` tag.  Note that a test's `size` is considered a tag for the purpose of filtering.  If you need a `test_suite` that contains tests with mutually exclusive tags (e.g. all small and medium tests), you'll have to create three `test_suite` rules: one for all small tests, one for all medium tests, and one that includes the previous two. |
+| `tests` | List of [labels](/versions/7.6.1/concepts/labels); [nonconfigurable](/versions/7.6.1/reference/be/common-definitions#configurable-attributes); default is `[]` A list of test suites and test targets of any language. Any `*_test` is accepted here, independent of the language. No `*_binary` targets are accepted however, even if they happen to run a test. Filtering by the specified `tags` is only done for tests listed directly in this attribute. If this attribute contains `test_suite`s, the tests inside those will not be filtered by this `test_suite` (they are considered to be filtered already).  If the `tests` attribute is unspecified or empty, the rule will default to including all test rules in the current BUILD file that are not tagged as `manual`. These rules are still subject to `tag` filtering. |
\ No newline at end of file
diff --git a/versions/7.6.1/reference/be/java.mdx b/versions/7.6.1/reference/be/java.mdx
index 89311e5c..95c42503 100644
--- a/versions/7.6.1/reference/be/java.mdx
+++ b/versions/7.6.1/reference/be/java.mdx
@@ -100,15 +100,15 @@ java_binary(
 | Attributes | |
 | --- | --- |
 | `name` | [Name](/versions/7.6.1/concepts/labels#target-names); required  A unique name for this target.  It is good practice to use the name of the source file that is the main entry point of the application (minus the extension). For example, if your entry point is called `Main.java`, then your name could be `Main`. |
-| `deps` | List of [labels](/versions/7.6.1/concepts/labels); default is `[]` The list of other libraries to be linked in to the target. See general comments about `deps` at [Typical attributes defined by most build rules](common-definitions#typical-attributes). |
+| `deps` | List of [labels](/versions/7.6.1/concepts/labels); default is `[]` The list of other libraries to be linked in to the target. See general comments about `deps` at [Typical attributes defined by most build rules](/versions/7.6.1/reference/be/common-definitions#typical-attributes). |
 | `srcs` | List of [labels](/versions/7.6.1/concepts/labels); default is `[]` The list of source files that are processed to create the target. This attribute is almost always required; see exceptions below. Source files of type `.java` are compiled. In case of generated `.java` files it is generally advisable to put the generating rule's name here instead of the name of the file itself. This not only improves readability but makes the rule more resilient to future changes: if the generating rule generates different files in the future, you only need to fix one place: the `outs` of the generating rule. You should not list the generating rule in `deps` because it is a no-op.  Source files of type `.srcjar` are unpacked and compiled. (This is useful if you need to generate a set of `.java` files with a genrule.)  Rules: if the rule (typically `genrule` or `filegroup`) generates any of the files listed above, they will be used the same way as described for source files.  This argument is almost always required, except if a [`main_class`](#java_binary.main_class) attribute specifies a class on the runtime classpath or you specify the `runtime_deps` argument. |
 | `resources` | List of [labels](/versions/7.6.1/concepts/labels); default is `[]` A list of data files to include in a Java jar. If resources are specified, they will be bundled in the jar along with the usual `.class` files produced by compilation. The location of the resources inside of the jar file is determined by the project structure. Bazel first looks for Maven's [standard directory layout](https://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html), (a "src" directory followed by a "resources" directory grandchild). If that is not found, Bazel then looks for the topmost directory named "java" or "javatests" (so, for example, if a resource is at `/x/java/y/java/z`, the path of the resource will be `y/java/z`. This heuristic cannot be overridden, however, the `resource_strip_prefix` attribute can be used to specify a specific alternative directory for resource files.  Resources may be source files or generated files. |
 | `classpath_resources` | List of [labels](/versions/7.6.1/concepts/labels); default is `[]` *DO NOT USE THIS OPTION UNLESS THERE IS NO OTHER WAY)* A list of resources that must be located at the root of the java tree. This attribute's only purpose is to support third-party libraries that require that their resources be found on the classpath as exactly `"myconfig.xml"`. It is only allowed on binaries and not libraries, due to the danger of namespace conflicts. |
-| `create_executable` | Boolean; [nonconfigurable](common-definitions#configurable-attributes); default is `True` Deprecated, use `java_single_jar` instead. |
+| `create_executable` | Boolean; [nonconfigurable](/versions/7.6.1/reference/be/common-definitions#configurable-attributes); default is `True` Deprecated, use `java_single_jar` instead. |
 | `deploy_env` | List of [labels](/versions/7.6.1/concepts/labels); default is `[]` A list of other `java_binary` targets which represent the deployment environment for this binary. Set this attribute when building a plugin which will be loaded by another `java_binary`.  Setting this attribute excludes all dependencies from the runtime classpath (and the deploy jar) of this binary that are shared between this binary and the targets specified in `deploy_env`. |
-| `deploy_manifest_lines` | List of strings; default is `[]` A list of lines to add to the `META-INF/manifest.mf` file generated for the `*_deploy.jar` target. The contents of this attribute are *not* subject to ["Make variable"](make-variables) substitution. |
-| `javacopts` | List of strings; default is `[]` Extra compiler options for this library. Subject to ["Make variable"](make-variables) substitution and [Bourne shell tokenization](common-definitions#sh-tokenization). These compiler options are passed to javac after the global compiler options. |
-| `jvm_flags` | List of strings; default is `[]` A list of flags to embed in the wrapper script generated for running this binary. Subject to [$(location)](/versions/7.6.1/reference/be/make-variables#location) and ["Make variable"](make-variables) substitution, and [Bourne shell tokenization](common-definitions#sh-tokenization). The wrapper script for a Java binary includes a CLASSPATH definition (to find all the dependent jars) and invokes the right Java interpreter. The command line generated by the wrapper script includes the name of the main class followed by a `"$@"` so you can pass along other arguments after the classname. However, arguments intended for parsing by the JVM must be specified *before* the classname on the command line. The contents of `jvm_flags` are added to the wrapper script before the classname is listed.  Note that this attribute has *no effect* on `*_deploy.jar` outputs. |
+| `deploy_manifest_lines` | List of strings; default is `[]` A list of lines to add to the `META-INF/manifest.mf` file generated for the `*_deploy.jar` target. The contents of this attribute are *not* subject to ["Make variable"](/versions/7.6.1/reference/be/make-variables) substitution. |
+| `javacopts` | List of strings; default is `[]` Extra compiler options for this library. Subject to ["Make variable"](/versions/7.6.1/reference/be/make-variables) substitution and [Bourne shell tokenization](/versions/7.6.1/reference/be/common-definitions#sh-tokenization). These compiler options are passed to javac after the global compiler options. |
+| `jvm_flags` | List of strings; default is `[]` A list of flags to embed in the wrapper script generated for running this binary. Subject to [$(location)](/versions/7.6.1/reference/be/make-variables#location) and ["Make variable"](/versions/7.6.1/reference/be/make-variables) substitution, and [Bourne shell tokenization](/versions/7.6.1/reference/be/common-definitions#sh-tokenization). The wrapper script for a Java binary includes a CLASSPATH definition (to find all the dependent jars) and invokes the right Java interpreter. The command line generated by the wrapper script includes the name of the main class followed by a `"$@"` so you can pass along other arguments after the classname. However, arguments intended for parsing by the JVM must be specified *before* the classname on the command line. The contents of `jvm_flags` are added to the wrapper script before the classname is listed.  Note that this attribute has *no effect* on `*_deploy.jar` outputs. |
 | `launcher` | [Label](/versions/7.6.1/concepts/labels); default is `None` Specify a binary that will be used to run your Java program instead of the normal `bin/java` program included with the JDK. The target must be a `cc_binary`. Any `cc_binary` that implements the [Java Invocation API](http://docs.oracle.com/javase/7/docs/technotes/guides/jni/spec/invocation.html) can be specified as a value for this attribute. By default, Bazel will use the normal JDK launcher (bin/java or java.exe).  The related [`--java_launcher`](/versions/7.6.1/docs/user-manual#flag--java_launcher) Bazel flag affects only those `java_binary` and `java_test` targets that have *not* specified a `launcher` attribute.  Note that your native (C++, SWIG, JNI) dependencies will be built differently depending on whether you are using the JDK launcher or another launcher:   * If you are using the normal JDK launcher (the default), native dependencies are   built as a shared library named `{name}_nativedeps.so`, where   `{name}` is the `name` attribute of this java\_binary rule.   Unused code is *not* removed by the linker in this configuration. * If you are using any other launcher, native (C++) dependencies are statically   linked into a binary named `{name}_nativedeps`, where `{name}`   is the `name` attribute of this java\_binary rule. In this case,   the linker will remove any code it thinks is unused from the resulting binary,   which means any C++ code accessed only via JNI may not be linked in unless   that `cc_library` target specifies `alwayslink = 1`.   When using any launcher other than the default JDK launcher, the format of the `*_deploy.jar` output changes. See the main [java\_binary](#java_binary) docs for details. |
 | `main_class` | String; default is `""` Name of class with `main()` method to use as entry point. If a rule uses this option, it does not need a `srcs=[...]` list. Thus, with this attribute one can make an executable from a Java library that already contains one or more `main()` methods. The value of this attribute is a class name, not a source file. The class must be available at runtime: it may be compiled by this rule (from `srcs`) or provided by direct or transitive dependencies (through `runtime_deps` or `deps`). If the class is unavailable, the binary will fail at runtime; there is no build-time check. |
 | `plugins` | List of [labels](/versions/7.6.1/concepts/labels); default is `[]` Java compiler plugins to run at compile-time. Every `java_plugin` specified in this attribute will be run whenever this rule is built. A library may also inherit plugins from dependencies that use `exported_plugins`. Resources generated by the plugin will be included in the resulting jar of this rule. |
@@ -150,7 +150,7 @@ libraries for `java_library` and
 | --- | --- |
 | `name` | [Name](/versions/7.6.1/concepts/labels#target-names); required  A unique name for this target. |
 | `deps` | List of [labels](/versions/7.6.1/concepts/labels); default is `[]` The list of other libraries to be linked in to the target. See [java\_library.deps](/versions/7.6.1/reference/be/java#java_library.deps). |
-| `constraints` | List of strings; [nonconfigurable](common-definitions#configurable-attributes); default is `[]` Extra constraints imposed on this rule as a Java library. |
+| `constraints` | List of strings; [nonconfigurable](/versions/7.6.1/reference/be/common-definitions#configurable-attributes); default is `[]` Extra constraints imposed on this rule as a Java library. |
 | `exports` | List of [labels](/versions/7.6.1/concepts/labels); default is `[]` Targets to make available to users of this rule. See [java\_library.exports](/versions/7.6.1/reference/be/java#java_library.exports). |
 | `jars` | List of [labels](/versions/7.6.1/concepts/labels); required The list of JAR files provided to Java targets that depend on this target. |
 | `neverlink` | Boolean; default is `False` Only use this library for compilation and not at runtime. Useful if the library will be provided by the runtime environment during execution. Examples of libraries like this are IDE APIs for IDE plug-ins or `tools.jar` for anything running on a standard JDK. |
@@ -185,7 +185,7 @@ This rule compiles and links sources into a `.jar` file.
 | `resources` | List of [labels](/versions/7.6.1/concepts/labels); default is `[]` A list of data files to include in a Java jar. If resources are specified, they will be bundled in the jar along with the usual `.class` files produced by compilation. The location of the resources inside of the jar file is determined by the project structure. Bazel first looks for Maven's [standard directory layout](https://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html), (a "src" directory followed by a "resources" directory grandchild). If that is not found, Bazel then looks for the topmost directory named "java" or "javatests" (so, for example, if a resource is at `/x/java/y/java/z`, the path of the resource will be `y/java/z`. This heuristic cannot be overridden, however, the `resource_strip_prefix` attribute can be used to specify a specific alternative directory for resource files.  Resources may be source files or generated files. |
 | `exported_plugins` | List of [labels](/versions/7.6.1/concepts/labels); default is `[]` The list of `java_plugin`s (e.g. annotation processors) to export to libraries that directly depend on this library. The specified list of `java_plugin`s will be applied to any library which directly depends on this library, just as if that library had explicitly declared these labels in `plugins`. |
 | `exports` | List of [labels](/versions/7.6.1/concepts/labels); default is `[]` Exported libraries. Listing rules here will make them available to parent rules, as if the parents explicitly depended on these rules. This is not true for regular (non-exported) `deps`.  Summary: a rule *X* can access the code in *Y* if there exists a dependency path between them that begins with a `deps` edge followed by zero or more `exports` edges. Let's see some examples to illustrate this.  Assume *A* depends on *B* and *B* depends on *C*. In this case C is a *transitive* dependency of A, so changing C's sources and rebuilding A will correctly rebuild everything. However A will not be able to use classes in C. To allow that, either A has to declare C in its `deps`, or B can make it easier for A (and anything that may depend on A) by declaring C in its (B's) `exports` attribute.  The closure of exported libraries is available to all direct parent rules. Take a slightly different example: A depends on B, B depends on C and D, and also exports C but not D. Now A has access to C but not to D. Now, if C and D exported some libraries, C' and D' respectively, A could only access C' but not D'.  Important: an exported rule is not a regular dependency. Sticking to the previous example, if B exports C and wants to also use C, it has to also list it in its own `deps`. |
-| `javacopts` | List of strings; default is `[]` Extra compiler options for this library. Subject to ["Make variable"](make-variables) substitution and [Bourne shell tokenization](common-definitions#sh-tokenization). These compiler options are passed to javac after the global compiler options. |
+| `javacopts` | List of strings; default is `[]` Extra compiler options for this library. Subject to ["Make variable"](/versions/7.6.1/reference/be/make-variables) substitution and [Bourne shell tokenization](/versions/7.6.1/reference/be/common-definitions#sh-tokenization). These compiler options are passed to javac after the global compiler options. |
 | `neverlink` | Boolean; default is `False` Whether this library should only be used for compilation and not at runtime. Useful if the library will be provided by the runtime environment during execution. Examples of such libraries are the IDE APIs for IDE plug-ins or `tools.jar` for anything running on a standard JDK. Note that `neverlink = 1` does not prevent the compiler from inlining material from this library into compilation targets that depend on it, as permitted by the Java Language Specification (e.g., `static final` constants of `String` or of primitive types). The preferred use case is therefore when the runtime library is identical to the compilation library.  If the runtime library differs from the compilation library then you must ensure that it differs only in places that the JLS forbids compilers to inline (and that must hold for all future versions of the JLS). |
 | `plugins` | List of [labels](/versions/7.6.1/concepts/labels); default is `[]` Java compiler plugins to run at compile-time. Every `java_plugin` specified in this attribute will be run whenever this rule is built. A library may also inherit plugins from dependencies that use `exported_plugins`. Resources generated by the plugin will be included in the resulting jar of this rule. |
 | `proguard_specs` | List of [labels](/versions/7.6.1/concepts/labels); default is `[]` Files to be used as Proguard specification. These will describe the set of specifications to be used by Proguard. If specified, they will be added to any `android_binary` target depending on this library. The files included here must only have idempotent rules, namely -dontnote, -dontwarn, assumenosideeffects, and rules that start with -keep. Other options can only appear in `android_binary`'s proguard\_specs, to ensure non-tautological merges. |
@@ -203,7 +203,7 @@ java_lite_proto_library(name, deps, data, compatible_with, deprecation, distribs
 
 `java_lite_proto_library` generates Java code from `.proto` files.
 
-`deps` must point to [`proto_library`](protocol-buffer#proto_library) rules.
+`deps` must point to [`proto_library`](/versions/7.6.1/reference/be/protocol-buffer#proto_library) rules.
 
 Example:
 
@@ -228,7 +228,7 @@ proto_library(
 | Attributes | |
 | --- | --- |
 | `name` | [Name](/versions/7.6.1/concepts/labels#target-names); required  A unique name for this target. |
-| `deps` | List of [labels](/versions/7.6.1/concepts/labels); default is `[]` The list of [`proto_library`](protocol-buffer#proto_library) rules to generate Java code for. |
+| `deps` | List of [labels](/versions/7.6.1/concepts/labels); default is `[]` The list of [`proto_library`](/versions/7.6.1/reference/be/protocol-buffer#proto_library) rules to generate Java code for. |
 
 ## java\_proto\_library
 
@@ -240,7 +240,7 @@ java_proto_library(name, deps, data, compatible_with, deprecation, distribs, exe
 
 `java_proto_library` generates Java code from `.proto` files.
 
-`deps` must point to [`proto_library`](protocol-buffer#proto_library) rules.
+`deps` must point to [`proto_library`](/versions/7.6.1/reference/be/protocol-buffer#proto_library) rules.
 
 Example:
 
@@ -265,7 +265,7 @@ proto_library(
 | Attributes | |
 | --- | --- |
 | `name` | [Name](/versions/7.6.1/concepts/labels#target-names); required  A unique name for this target. |
-| `deps` | List of [labels](/versions/7.6.1/concepts/labels); default is `[]` The list of [`proto_library`](protocol-buffer#proto_library) rules to generate Java code for. |
+| `deps` | List of [labels](/versions/7.6.1/concepts/labels); default is `[]` The list of [`proto_library`](/versions/7.6.1/reference/be/protocol-buffer#proto_library) rules to generate Java code for. |
 
 ## java\_test
 
@@ -287,8 +287,7 @@ test code. The test runner's main method is invoked instead of the main class be
   [java\_binary](#java_binary) for more details.
 
 See the section on [java\_binary()](/versions/7.6.1/reference/be/java#java_binary_args) arguments. This rule also
-supports all [attributes common
-to all test rules (\*\_test)](/versions/7.6.1/reference/be/common-definitions#common-attributes-tests).
+supports all [attributes common to all test rules (\*\_test)](/versions/7.6.1/reference/be/common-definitions#common-attributes-tests).
 
 #### Examples
 
@@ -317,14 +316,14 @@ java_test(
 | Attributes | |
 | --- | --- |
 | `name` | [Name](/versions/7.6.1/concepts/labels#target-names); required  A unique name for this target. |
-| `deps` | List of [labels](/versions/7.6.1/concepts/labels); default is `[]` The list of other libraries to be linked in to the target. See general comments about `deps` at [Typical attributes defined by most build rules](common-definitions#typical-attributes). |
+| `deps` | List of [labels](/versions/7.6.1/concepts/labels); default is `[]` The list of other libraries to be linked in to the target. See general comments about `deps` at [Typical attributes defined by most build rules](/versions/7.6.1/reference/be/common-definitions#typical-attributes). |
 | `srcs` | List of [labels](/versions/7.6.1/concepts/labels); default is `[]` The list of source files that are processed to create the target. This attribute is almost always required; see exceptions below. Source files of type `.java` are compiled. In case of generated `.java` files it is generally advisable to put the generating rule's name here instead of the name of the file itself. This not only improves readability but makes the rule more resilient to future changes: if the generating rule generates different files in the future, you only need to fix one place: the `outs` of the generating rule. You should not list the generating rule in `deps` because it is a no-op.  Source files of type `.srcjar` are unpacked and compiled. (This is useful if you need to generate a set of `.java` files with a genrule.)  Rules: if the rule (typically `genrule` or `filegroup`) generates any of the files listed above, they will be used the same way as described for source files.  This argument is almost always required, except if a [`main_class`](#java_binary.main_class) attribute specifies a class on the runtime classpath or you specify the `runtime_deps` argument. |
 | `resources` | List of [labels](/versions/7.6.1/concepts/labels); default is `[]` A list of data files to include in a Java jar. If resources are specified, they will be bundled in the jar along with the usual `.class` files produced by compilation. The location of the resources inside of the jar file is determined by the project structure. Bazel first looks for Maven's [standard directory layout](https://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html), (a "src" directory followed by a "resources" directory grandchild). If that is not found, Bazel then looks for the topmost directory named "java" or "javatests" (so, for example, if a resource is at `/x/java/y/java/z`, the path of the resource will be `y/java/z`. This heuristic cannot be overridden, however, the `resource_strip_prefix` attribute can be used to specify a specific alternative directory for resource files.  Resources may be source files or generated files. |
 | `classpath_resources` | List of [labels](/versions/7.6.1/concepts/labels); default is `[]` *DO NOT USE THIS OPTION UNLESS THERE IS NO OTHER WAY)* A list of resources that must be located at the root of the java tree. This attribute's only purpose is to support third-party libraries that require that their resources be found on the classpath as exactly `"myconfig.xml"`. It is only allowed on binaries and not libraries, due to the danger of namespace conflicts. |
-| `create_executable` | Boolean; [nonconfigurable](common-definitions#configurable-attributes); default is `True` Deprecated, use `java_single_jar` instead. |
-| `deploy_manifest_lines` | List of strings; default is `[]` A list of lines to add to the `META-INF/manifest.mf` file generated for the `*_deploy.jar` target. The contents of this attribute are *not* subject to ["Make variable"](make-variables) substitution. |
-| `javacopts` | List of strings; default is `[]` Extra compiler options for this library. Subject to ["Make variable"](make-variables) substitution and [Bourne shell tokenization](common-definitions#sh-tokenization). These compiler options are passed to javac after the global compiler options. |
-| `jvm_flags` | List of strings; default is `[]` A list of flags to embed in the wrapper script generated for running this binary. Subject to [$(location)](/versions/7.6.1/reference/be/make-variables#location) and ["Make variable"](make-variables) substitution, and [Bourne shell tokenization](common-definitions#sh-tokenization). The wrapper script for a Java binary includes a CLASSPATH definition (to find all the dependent jars) and invokes the right Java interpreter. The command line generated by the wrapper script includes the name of the main class followed by a `"$@"` so you can pass along other arguments after the classname. However, arguments intended for parsing by the JVM must be specified *before* the classname on the command line. The contents of `jvm_flags` are added to the wrapper script before the classname is listed.  Note that this attribute has *no effect* on `*_deploy.jar` outputs. |
+| `create_executable` | Boolean; [nonconfigurable](/versions/7.6.1/reference/be/common-definitions#configurable-attributes); default is `True` Deprecated, use `java_single_jar` instead. |
+| `deploy_manifest_lines` | List of strings; default is `[]` A list of lines to add to the `META-INF/manifest.mf` file generated for the `*_deploy.jar` target. The contents of this attribute are *not* subject to ["Make variable"](/versions/7.6.1/reference/be/make-variables) substitution. |
+| `javacopts` | List of strings; default is `[]` Extra compiler options for this library. Subject to ["Make variable"](/versions/7.6.1/reference/be/make-variables) substitution and [Bourne shell tokenization](/versions/7.6.1/reference/be/common-definitions#sh-tokenization). These compiler options are passed to javac after the global compiler options. |
+| `jvm_flags` | List of strings; default is `[]` A list of flags to embed in the wrapper script generated for running this binary. Subject to [$(location)](/versions/7.6.1/reference/be/make-variables#location) and ["Make variable"](/versions/7.6.1/reference/be/make-variables) substitution, and [Bourne shell tokenization](/versions/7.6.1/reference/be/common-definitions#sh-tokenization). The wrapper script for a Java binary includes a CLASSPATH definition (to find all the dependent jars) and invokes the right Java interpreter. The command line generated by the wrapper script includes the name of the main class followed by a `"$@"` so you can pass along other arguments after the classname. However, arguments intended for parsing by the JVM must be specified *before* the classname on the command line. The contents of `jvm_flags` are added to the wrapper script before the classname is listed.  Note that this attribute has *no effect* on `*_deploy.jar` outputs. |
 | `launcher` | [Label](/versions/7.6.1/concepts/labels); default is `None` Specify a binary that will be used to run your Java program instead of the normal `bin/java` program included with the JDK. The target must be a `cc_binary`. Any `cc_binary` that implements the [Java Invocation API](http://docs.oracle.com/javase/7/docs/technotes/guides/jni/spec/invocation.html) can be specified as a value for this attribute. By default, Bazel will use the normal JDK launcher (bin/java or java.exe).  The related [`--java_launcher`](/versions/7.6.1/docs/user-manual#flag--java_launcher) Bazel flag affects only those `java_binary` and `java_test` targets that have *not* specified a `launcher` attribute.  Note that your native (C++, SWIG, JNI) dependencies will be built differently depending on whether you are using the JDK launcher or another launcher:   * If you are using the normal JDK launcher (the default), native dependencies are   built as a shared library named `{name}_nativedeps.so`, where   `{name}` is the `name` attribute of this java\_binary rule.   Unused code is *not* removed by the linker in this configuration. * If you are using any other launcher, native (C++) dependencies are statically   linked into a binary named `{name}_nativedeps`, where `{name}`   is the `name` attribute of this java\_binary rule. In this case,   the linker will remove any code it thinks is unused from the resulting binary,   which means any C++ code accessed only via JNI may not be linked in unless   that `cc_library` target specifies `alwayslink = 1`.   When using any launcher other than the default JDK launcher, the format of the `*_deploy.jar` output changes. See the main [java\_binary](#java_binary) docs for details. |
 | `main_class` | String; default is `""` Name of class with `main()` method to use as entry point. If a rule uses this option, it does not need a `srcs=[...]` list. Thus, with this attribute one can make an executable from a Java library that already contains one or more `main()` methods. The value of this attribute is a class name, not a source file. The class must be available at runtime: it may be compiled by this rule (from `srcs`) or provided by direct or transitive dependencies (through `runtime_deps` or `deps`). If the class is unavailable, the binary will fail at runtime; there is no build-time check. |
 | `plugins` | List of [labels](/versions/7.6.1/concepts/labels); default is `[]` Java compiler plugins to run at compile-time. Every `java_plugin` specified in this attribute will be run whenever this rule is built. A library may also inherit plugins from dependencies that use `exported_plugins`. Resources generated by the plugin will be included in the resulting jar of this rule. |
@@ -414,7 +413,7 @@ for the addition of the `processor_class` argument.
 | `data` | List of [labels](/versions/7.6.1/concepts/labels); default is `[]` The list of files needed by this library at runtime. See general comments about `data` at [Typical attributes defined by most build rules](/versions/7.6.1/reference/be/common-definitions#typical-attributes). When building a `java_library`, Bazel doesn't put these files anywhere; if the `data` files are generated files then Bazel generates them. When building a test that depends on this `java_library` Bazel copies or links the `data` files into the runfiles area. |
 | `resources` | List of [labels](/versions/7.6.1/concepts/labels); default is `[]` A list of data files to include in a Java jar. If resources are specified, they will be bundled in the jar along with the usual `.class` files produced by compilation. The location of the resources inside of the jar file is determined by the project structure. Bazel first looks for Maven's [standard directory layout](https://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html), (a "src" directory followed by a "resources" directory grandchild). If that is not found, Bazel then looks for the topmost directory named "java" or "javatests" (so, for example, if a resource is at `/x/java/y/java/z`, the path of the resource will be `y/java/z`. This heuristic cannot be overridden, however, the `resource_strip_prefix` attribute can be used to specify a specific alternative directory for resource files.  Resources may be source files or generated files. |
 | `generates_api` | Boolean; default is `False` This attribute marks annotation processors that generate API code. If a rule uses an API-generating annotation processor, other rules depending on it can refer to the generated code only if their compilation actions are scheduled after the generating rule. This attribute instructs Bazel to introduce scheduling constraints when --java\_header\_compilation is enabled. *WARNING: This attribute affects build performance, use it only if necessary.* |
-| `javacopts` | List of strings; default is `[]` Extra compiler options for this library. Subject to ["Make variable"](make-variables) substitution and [Bourne shell tokenization](common-definitions#sh-tokenization). These compiler options are passed to javac after the global compiler options. |
+| `javacopts` | List of strings; default is `[]` Extra compiler options for this library. Subject to ["Make variable"](/versions/7.6.1/reference/be/make-variables) substitution and [Bourne shell tokenization](/versions/7.6.1/reference/be/common-definitions#sh-tokenization). These compiler options are passed to javac after the global compiler options. |
 | `neverlink` | Boolean; default is `False` Whether this library should only be used for compilation and not at runtime. Useful if the library will be provided by the runtime environment during execution. Examples of such libraries are the IDE APIs for IDE plug-ins or `tools.jar` for anything running on a standard JDK. Note that `neverlink = 1` does not prevent the compiler from inlining material from this library into compilation targets that depend on it, as permitted by the Java Language Specification (e.g., `static final` constants of `String` or of primitive types). The preferred use case is therefore when the runtime library is identical to the compilation library.  If the runtime library differs from the compilation library then you must ensure that it differs only in places that the JLS forbids compilers to inline (and that must hold for all future versions of the JLS). |
 | `output_licenses` | Licence type; default is `["none"]` See [`common attributes`](/versions/7.6.1/reference/be/common-definitions#binary.output_licenses) |
 | `plugins` | List of [labels](/versions/7.6.1/concepts/labels); default is `[]` Java compiler plugins to run at compile-time. Every `java_plugin` specified in this attribute will be run whenever this rule is built. A library may also inherit plugins from dependencies that use `exported_plugins`. Resources generated by the plugin will be included in the resulting jar of this rule. |
diff --git a/versions/7.6.1/reference/be/make-variables.mdx b/versions/7.6.1/reference/be/make-variables.mdx
index 66ee726d..56320a17 100644
--- a/versions/7.6.1/reference/be/make-variables.mdx
+++ b/versions/7.6.1/reference/be/make-variables.mdx
@@ -19,8 +19,7 @@ targets, and *custom* variables, which are defined in dependency targets
 and only available to targets that depend on them.
 
 The reason for the term "Make" is historical: the syntax and semantics of
-these variables were originally intended to match [GNU
-Make](https://www.gnu.org/software/make/manual/html_node/Using-Variables.html).
+these variables were originally intended to match [GNU Make](https://www.gnu.org/software/make/manual/html_node/Using-Variables.html).
 
 ## Use
 
@@ -64,8 +63,7 @@ and look at the top output lines with capital letters.
 **Toolchain option variables**
 
 * `COMPILATION_MODE`:
-  `fastbuild`, `dbg`, or `opt`. ([more
-  details](https://bazel.build/versions/7.6.1/docs/user-manual#flag--compilation_mode))
+  `fastbuild`, `dbg`, or `opt`. ([more details](https://bazel.build/versions/7.6.1/docs/user-manual#flag--compilation_mode))
 
 **Path variables**
 
@@ -302,7 +300,7 @@ rare cases. If you are tempted to use them, please [contact the Bazel devs](http
 
 Rule and [toolchain](/versions/7.6.1/docs/toolchains) writers can define
 completely custom variables by returning a
-[TemplateVariableInfo](/versions/7.6.1/rules/lib/TemplateVariableInfo)
+[TemplateVariableInfo](/versions/7.6.1/rules/lib/providers/TemplateVariableInfo)
 provider. Any rules depending on these through the
 `toolchains` attribute can then read their values:
 
diff --git a/versions/7.6.1/reference/be/objective-c.mdx b/versions/7.6.1/reference/be/objective-c.mdx
index 80fd0435..c6578fc1 100644
--- a/versions/7.6.1/reference/be/objective-c.mdx
+++ b/versions/7.6.1/reference/be/objective-c.mdx
@@ -21,8 +21,7 @@ j2objc_library(name, deps, compatible_with, deprecation, distribs, entry_classes
 
 This rule uses [J2ObjC](https://github.com/google/j2objc) to translate Java source
 files to Objective-C, which then can be used used as dependencies of objc\_library and objc\_binary
-rules. Detailed information about J2ObjC itself can be found at [the
-J2ObjC site](http://j2objc.org)
+rules. Detailed information about J2ObjC itself can be found at [the J2ObjC site](http://j2objc.org)
 
 Custom J2ObjC transpilation flags can be specified using the build flag
 `--j2objc_translation_flags` in the command line.
@@ -125,8 +124,8 @@ This allows selection of an official xcode version from the collectively availab
 | Attributes | |
 | --- | --- |
 | `name` | [Name](/versions/7.6.1/concepts/labels#target-names); required  A unique name for this target. |
-| `default` | [Label](/versions/7.6.1/concepts/labels); [nonconfigurable](common-definitions#configurable-attributes); required The default xcode version for this platform. |
-| `versions` | List of [labels](/versions/7.6.1/concepts/labels); [nonconfigurable](common-definitions#configurable-attributes); default is `[]` The xcode versions that are available on this platform. |
+| `default` | [Label](/versions/7.6.1/concepts/labels); [nonconfigurable](/versions/7.6.1/reference/be/common-definitions#configurable-attributes); required The default xcode version for this platform. |
+| `versions` | List of [labels](/versions/7.6.1/concepts/labels); [nonconfigurable](/versions/7.6.1/reference/be/common-definitions#configurable-attributes); default is `[]` The xcode versions that are available on this platform. |
 
 ## xcode\_config
 
@@ -145,10 +144,10 @@ This allows selection of an official xcode version from a number of registered a
 | Attributes | |
 | --- | --- |
 | `name` | [Name](/versions/7.6.1/concepts/labels#target-names); required  A unique name for this target. |
-| `default` | [Label](/versions/7.6.1/concepts/labels); [nonconfigurable](common-definitions#configurable-attributes); default is `None` The default official version of xcode to use. The version specified by the provided `xcode_version` target is to be used if no `xcode_version` build flag is specified. This is required if any `versions` are set. This may not be set if `remote_versions` or `local_versions` is set. |
-| `local_versions` | [Label](/versions/7.6.1/concepts/labels); [nonconfigurable](common-definitions#configurable-attributes); default is `None` The `xcode_version` targets that are available locally. These are used along with `local_versions` to select a mutually available version. This may not be set if `versions` is set. |
-| `remote_versions` | [Label](/versions/7.6.1/concepts/labels); [nonconfigurable](common-definitions#configurable-attributes); default is `None` The `xcode_version` targets that are available remotely. These are used along with `remote_versions` to select a mutually available version. This may not be set if `versions` is set. |
-| `versions` | List of [labels](/versions/7.6.1/concepts/labels); [nonconfigurable](common-definitions#configurable-attributes); default is `[]` Accepted `xcode_version` targets that may be used. If the value of the `xcode_version` build flag matches one of the aliases or version number of any of the given `xcode_version` targets, the matching target will be used. This may not be set if `remote_versions` or `local_versions` is set. |
+| `default` | [Label](/versions/7.6.1/concepts/labels); [nonconfigurable](/versions/7.6.1/reference/be/common-definitions#configurable-attributes); default is `None` The default official version of xcode to use. The version specified by the provided `xcode_version` target is to be used if no `xcode_version` build flag is specified. This is required if any `versions` are set. This may not be set if `remote_versions` or `local_versions` is set. |
+| `local_versions` | [Label](/versions/7.6.1/concepts/labels); [nonconfigurable](/versions/7.6.1/reference/be/common-definitions#configurable-attributes); default is `None` The `xcode_version` targets that are available locally. These are used along with `local_versions` to select a mutually available version. This may not be set if `versions` is set. |
+| `remote_versions` | [Label](/versions/7.6.1/concepts/labels); [nonconfigurable](/versions/7.6.1/reference/be/common-definitions#configurable-attributes); default is `None` The `xcode_version` targets that are available remotely. These are used along with `remote_versions` to select a mutually available version. This may not be set if `versions` is set. |
+| `versions` | List of [labels](/versions/7.6.1/concepts/labels); [nonconfigurable](/versions/7.6.1/reference/be/common-definitions#configurable-attributes); default is `[]` Accepted `xcode_version` targets that may be used. If the value of the `xcode_version` build flag matches one of the aliases or version number of any of the given `xcode_version` targets, the matching target will be used. This may not be set if `remote_versions` or `local_versions` is set. |
 
 ## xcode\_version
 
@@ -166,9 +165,9 @@ See the `xcode_config` rule.
 | Attributes | |
 | --- | --- |
 | `name` | [Name](/versions/7.6.1/concepts/labels#target-names); required  A unique name for this target. |
-| `default_ios_sdk_version` | String; [nonconfigurable](common-definitions#configurable-attributes); default is `""` The ios sdk version that is used by default when this version of xcode is being used. The `ios_sdk_version` build flag will override the value specified here. |
-| `default_macos_sdk_version` | String; [nonconfigurable](common-definitions#configurable-attributes); default is `""` The macosx sdk version that is used by default when this version of xcode is being used. The `macos_sdk_version` build flag will override the value specified here. |
-| `default_tvos_sdk_version` | String; [nonconfigurable](common-definitions#configurable-attributes); default is `""` The tvos sdk version that is used by default when this version of xcode is being used. The `tvos_sdk_version` build flag will override the value specified here. |
-| `default_visionos_sdk_version` | String; [nonconfigurable](common-definitions#configurable-attributes); default is `""` The visionos sdk version that is used by default when this version of xcode is being used. The `visionos_sdk_version` build flag will override the value specified here. |
-| `default_watchos_sdk_version` | String; [nonconfigurable](common-definitions#configurable-attributes); default is `""` The watchos sdk version that is used by default when this version of xcode is being used. The `watchos_sdk_version` build flag will override the value specified here. |
-| `version` | String; [nonconfigurable](common-definitions#configurable-attributes); required The official version number of a version of Xcode. |
\ No newline at end of file
+| `default_ios_sdk_version` | String; [nonconfigurable](/versions/7.6.1/reference/be/common-definitions#configurable-attributes); default is `""` The ios sdk version that is used by default when this version of xcode is being used. The `ios_sdk_version` build flag will override the value specified here. |
+| `default_macos_sdk_version` | String; [nonconfigurable](/versions/7.6.1/reference/be/common-definitions#configurable-attributes); default is `""` The macosx sdk version that is used by default when this version of xcode is being used. The `macos_sdk_version` build flag will override the value specified here. |
+| `default_tvos_sdk_version` | String; [nonconfigurable](/versions/7.6.1/reference/be/common-definitions#configurable-attributes); default is `""` The tvos sdk version that is used by default when this version of xcode is being used. The `tvos_sdk_version` build flag will override the value specified here. |
+| `default_visionos_sdk_version` | String; [nonconfigurable](/versions/7.6.1/reference/be/common-definitions#configurable-attributes); default is `""` The visionos sdk version that is used by default when this version of xcode is being used. The `visionos_sdk_version` build flag will override the value specified here. |
+| `default_watchos_sdk_version` | String; [nonconfigurable](/versions/7.6.1/reference/be/common-definitions#configurable-attributes); default is `""` The watchos sdk version that is used by default when this version of xcode is being used. The `watchos_sdk_version` build flag will override the value specified here. |
+| `version` | String; [nonconfigurable](/versions/7.6.1/reference/be/common-definitions#configurable-attributes); required The official version number of a version of Xcode. |
\ No newline at end of file
diff --git a/versions/7.6.1/reference/be/overview.mdx b/versions/7.6.1/reference/be/overview.mdx
index e830cbae..f8b02558 100644
--- a/versions/7.6.1/reference/be/overview.mdx
+++ b/versions/7.6.1/reference/be/overview.mdx
@@ -37,19 +37,19 @@ For non-native Starlark rules that ship separately from Bazel, see the list of
 
 | Language | Binary rules | Library rules | Test rules | Other rules |
 | --- | --- | --- | --- | --- |
-| Android | [android\_binary](android#android_binary) | [aar\_import](android#aar_import)   [android\_library](android#android_library) | [android\_instrumentation\_test](android#android_instrumentation_test)   [android\_local\_test](android#android_local_test) | [android\_device](android#android_device)   [android\_ndk\_repository](android#android_ndk_repository)   [android\_sdk\_repository](android#android_sdk_repository) |
-| C / C++ | [cc\_binary](c-cpp#cc_binary) | [cc\_import](c-cpp#cc_import)   [cc\_library](c-cpp#cc_library)   [cc\_proto\_library](c-cpp#cc_proto_library)   [cc\_shared\_library](c-cpp#cc_shared_library)   [cc\_static\_library](c-cpp#cc_static_library)   [fdo\_prefetch\_hints](c-cpp#fdo_prefetch_hints)   [fdo\_profile](c-cpp#fdo_profile)   [memprof\_profile](c-cpp#memprof_profile)   [propeller\_optimize](c-cpp#propeller_optimize) | [cc\_test](c-cpp#cc_test) | [cc\_toolchain](c-cpp#cc_toolchain)   [cc\_toolchain\_suite](c-cpp#cc_toolchain_suite) |
-| Java | [java\_binary](java#java_binary) | [java\_import](java#java_import)   [java\_library](java#java_library)   [java\_lite\_proto\_library](java#java_lite_proto_library)   [java\_proto\_library](java#java_proto_library) | [java\_test](java#java_test) | [java\_package\_configuration](java#java_package_configuration)   [java\_plugin](java#java_plugin)   [java\_runtime](java#java_runtime)   [java\_toolchain](java#java_toolchain) |
-| Objective-C |  | [j2objc\_library](objective-c#j2objc_library)   [objc\_import](objective-c#objc_import)   [objc\_library](objective-c#objc_library) |  | [available\_xcodes](objective-c#available_xcodes)   [xcode\_config](objective-c#xcode_config)   [xcode\_version](objective-c#xcode_version) |
-| Protocol Buffer |  | [proto\_lang\_toolchain](protocol-buffer#proto_lang_toolchain)   [proto\_library](protocol-buffer#proto_library) |  |  |
-| Python | [py\_binary](python#py_binary) | [py\_library](python#py_library) | [py\_test](python#py_test) | [py\_runtime](python#py_runtime) |
-| Shell | [sh\_binary](shell#sh_binary) | [sh\_library](shell#sh_library) | [sh\_test](shell#sh_test) |  |
+| Android | [android\_binary](/versions/7.6.1/reference/be/android#android_binary) | [aar\_import](/versions/7.6.1/reference/be/android#aar_import)   [android\_library](/versions/7.6.1/reference/be/android#android_library) | [android\_instrumentation\_test](/versions/7.6.1/reference/be/android#android_instrumentation_test)   [android\_local\_test](/versions/7.6.1/reference/be/android#android_local_test) | [android\_device](/versions/7.6.1/reference/be/android#android_device)   [android\_ndk\_repository](/versions/7.6.1/reference/be/android#android_ndk_repository)   [android\_sdk\_repository](/versions/7.6.1/reference/be/android#android_sdk_repository) |
+| C / C++ | [cc\_binary](/versions/7.6.1/reference/be/c-cpp#cc_binary) | [cc\_import](/versions/7.6.1/reference/be/c-cpp#cc_import)   [cc\_library](/versions/7.6.1/reference/be/c-cpp#cc_library)   [cc\_proto\_library](/versions/7.6.1/reference/be/c-cpp#cc_proto_library)   [cc\_shared\_library](/versions/7.6.1/reference/be/c-cpp#cc_shared_library)   [cc\_static\_library](/versions/7.6.1/reference/be/c-cpp#cc_static_library)   [fdo\_prefetch\_hints](/versions/7.6.1/reference/be/c-cpp#fdo_prefetch_hints)   [fdo\_profile](/versions/7.6.1/reference/be/c-cpp#fdo_profile)   [memprof\_profile](/versions/7.6.1/reference/be/c-cpp#memprof_profile)   [propeller\_optimize](/versions/7.6.1/reference/be/c-cpp#propeller_optimize) | [cc\_test](/versions/7.6.1/reference/be/c-cpp#cc_test) | [cc\_toolchain](/versions/7.6.1/reference/be/c-cpp#cc_toolchain)   [cc\_toolchain\_suite](/versions/7.6.1/reference/be/c-cpp#cc_toolchain_suite) |
+| Java | [java\_binary](/versions/7.6.1/reference/be/java#java_binary) | [java\_import](/versions/7.6.1/reference/be/java#java_import)   [java\_library](/versions/7.6.1/reference/be/java#java_library)   [java\_lite\_proto\_library](/versions/7.6.1/reference/be/java#java_lite_proto_library)   [java\_proto\_library](/versions/7.6.1/reference/be/java#java_proto_library) | [java\_test](/versions/7.6.1/reference/be/java#java_test) | [java\_package\_configuration](/versions/7.6.1/reference/be/java#java_package_configuration)   [java\_plugin](/versions/7.6.1/reference/be/java#java_plugin)   [java\_runtime](/versions/7.6.1/reference/be/java#java_runtime)   [java\_toolchain](/versions/7.6.1/reference/be/java#java_toolchain) |
+| Objective-C |  | [j2objc\_library](/versions/7.6.1/reference/be/objective-c#j2objc_library)   [objc\_import](/versions/7.6.1/reference/be/objective-c#objc_import)   [objc\_library](/versions/7.6.1/reference/be/objective-c#objc_library) |  | [available\_xcodes](/versions/7.6.1/reference/be/objective-c#available_xcodes)   [xcode\_config](/versions/7.6.1/reference/be/objective-c#xcode_config)   [xcode\_version](/versions/7.6.1/reference/be/objective-c#xcode_version) |
+| Protocol Buffer |  | [proto\_lang\_toolchain](/versions/7.6.1/reference/be/protocol-buffer#proto_lang_toolchain)   [proto\_library](/versions/7.6.1/reference/be/protocol-buffer#proto_library) |  |  |
+| Python | [py\_binary](/versions/7.6.1/reference/be/python#py_binary) | [py\_library](/versions/7.6.1/reference/be/python#py_library) | [py\_test](/versions/7.6.1/reference/be/python#py_test) | [py\_runtime](/versions/7.6.1/reference/be/python#py_runtime) |
+| Shell | [sh\_binary](/versions/7.6.1/reference/be/shell#sh_binary) | [sh\_library](/versions/7.6.1/reference/be/shell#sh_library) | [sh\_test](/versions/7.6.1/reference/be/shell#sh_test) |  |
 
 ### Language-agnostic native rules
 
 | Family | Rules |
 | --- | --- |
-| Extra Actions | * [action\_listener](extra-actions#action_listener)* [extra\_action](extra-actions#extra_action) |
-| General | * [alias](general#alias)* [config\_setting](general#config_setting)* [filegroup](general#filegroup)* [genquery](general#genquery)* [genrule](general#genrule)* [starlark\_doc\_extract](general#starlark_doc_extract)* [test\_suite](general#test_suite) |
-| Platforms and Toolchains | * [constraint\_setting](platforms-and-toolchains#constraint_setting)* [constraint\_value](platforms-and-toolchains#constraint_value)* [platform](platforms-and-toolchains#platform)* [toolchain](platforms-and-toolchains#toolchain)* [toolchain\_type](platforms-and-toolchains#toolchain_type) |
-| Workspace | * [bind](workspace#bind)* [local\_repository](workspace#local_repository)* [new\_local\_repository](workspace#new_local_repository) |
\ No newline at end of file
+| Extra Actions | * [action\_listener](/versions/7.6.1/reference/be/extra-actions#action_listener)* [extra\_action](/versions/7.6.1/reference/be/extra-actions#extra_action) |
+| General | * [alias](/versions/7.6.1/reference/be/general#alias)* [config\_setting](/versions/7.6.1/reference/be/general#config_setting)* [filegroup](/versions/7.6.1/reference/be/general#filegroup)* [genquery](/versions/7.6.1/reference/be/general#genquery)* [genrule](/versions/7.6.1/reference/be/general#genrule)* [starlark\_doc\_extract](/versions/7.6.1/reference/be/general#starlark_doc_extract)* [test\_suite](/versions/7.6.1/reference/be/general#test_suite) |
+| Platforms and Toolchains | * [constraint\_setting](/versions/7.6.1/reference/be/platforms-and-toolchains#constraint_setting)* [constraint\_value](/versions/7.6.1/reference/be/platforms-and-toolchains#constraint_value)* [platform](/versions/7.6.1/reference/be/platforms-and-toolchains#platform)* [toolchain](/versions/7.6.1/reference/be/platforms-and-toolchains#toolchain)* [toolchain\_type](/versions/7.6.1/reference/be/platforms-and-toolchains#toolchain_type) |
+| Workspace | * [bind](/versions/7.6.1/reference/be/workspace#bind)* [local\_repository](/versions/7.6.1/reference/be/workspace#local_repository)* [new\_local\_repository](/versions/7.6.1/reference/be/workspace#new_local_repository) |
\ No newline at end of file
diff --git a/versions/7.6.1/reference/be/platforms-and-toolchains.mdx b/versions/7.6.1/reference/be/platforms-and-toolchains.mdx
index 15e83bda..dc00940b 100644
--- a/versions/7.6.1/reference/be/platforms-and-toolchains.mdx
+++ b/versions/7.6.1/reference/be/platforms-and-toolchains.mdx
@@ -39,7 +39,7 @@ define a platform targeting an obscure cpu architecture.
 | Attributes | |
 | --- | --- |
 | `name` | [Name](/versions/7.6.1/concepts/labels#target-names); required  A unique name for this target. |
-| `default_constraint_value` | [Name](/versions/7.6.1/concepts/labels#target-names); [nonconfigurable](common-definitions#configurable-attributes); default is `None` The label of the default value for this setting, to be used if no value is given. If this attribute is present, the `constraint_value` it points to must be defined in the same package as this `constraint_setting`. If a constraint setting has a default value, then whenever a platform does not include any constraint value for that setting, it is the same as if the platform had specified the default value. Otherwise, if there is no default value, the constraint setting is considered to be unspecified by that platform. In that case, the platform would not match against any constraint list (such as for a `config_setting`) that requires a particular value for that setting. |
+| `default_constraint_value` | [Name](/versions/7.6.1/concepts/labels#target-names); [nonconfigurable](/versions/7.6.1/reference/be/common-definitions#configurable-attributes); default is `None` The label of the default value for this setting, to be used if no value is given. If this attribute is present, the `constraint_value` it points to must be defined in the same package as this `constraint_setting`. If a constraint setting has a default value, then whenever a platform does not include any constraint value for that setting, it is the same as if the platform had specified the default value. Otherwise, if there is no default value, the constraint setting is considered to be unspecified by that platform. In that case, the platform would not match against any constraint list (such as for a `config_setting`) that requires a particular value for that setting. |
 
 ## constraint\_value
 
@@ -73,7 +73,7 @@ Platforms can then declare that they have the `mips` architecture as an alternat
 | Attributes | |
 | --- | --- |
 | `name` | [Name](/versions/7.6.1/concepts/labels#target-names); required  A unique name for this target. |
-| `constraint_setting` | [Label](/versions/7.6.1/concepts/labels); [nonconfigurable](common-definitions#configurable-attributes); required The `constraint_setting` for which this `constraint_value` is a possible choice. |
+| `constraint_setting` | [Label](/versions/7.6.1/concepts/labels); [nonconfigurable](/versions/7.6.1/reference/be/common-definitions#configurable-attributes); required The `constraint_setting` for which this `constraint_value` is a possible choice. |
 
 ## platform
 
@@ -226,10 +226,10 @@ In this example, the child platforms have the following properties:
 | Attributes | |
 | --- | --- |
 | `name` | [Name](/versions/7.6.1/concepts/labels#target-names); required  A unique name for this target. |
-| `constraint_values` | List of [labels](/versions/7.6.1/concepts/labels); [nonconfigurable](common-definitions#configurable-attributes); default is `[]` The combination of constraint choices that this platform comprises. In order for a platform to apply to a given environment, the environment must have at least the values in this list. Each `constraint_value` in this list must be for a different `constraint_setting`. For example, you cannot define a platform that requires the cpu architecture to be both `@platforms//cpu:x86_64` and `@platforms//cpu:arm`. |
-| `exec_properties` | Dictionary: String -> String; [nonconfigurable](common-definitions#configurable-attributes); default is `{}` A map of strings that affect the way actions are executed remotely. Bazel makes no attempt to interpret this, it is treated as opaque data that's forwarded via the Platform field of the [remote execution protocol](https://github.com/bazelbuild/remote-apis). This includes any data from the parent platform's `exec_properties` attributes. If the child and parent platform define the same keys, the child's values are kept. Any keys associated with a value that is an empty string are removed from the dictionary. This attribute is a full replacement for the deprecated `remote_execution_properties`. |
-| `parents` | List of [labels](/versions/7.6.1/concepts/labels); [nonconfigurable](common-definitions#configurable-attributes); default is `[]` The label of a `platform` target that this platform should inherit from. Although the attribute takes a list, there should be no more than one platform present. Any constraint\_settings not set directly on this platform will be found in the parent platform. See the section on [Platform Inheritance](#platform_inheritance) for details. |
-| `remote_execution_properties` | String; [nonconfigurable](common-definitions#configurable-attributes); default is `""` DEPRECATED. Please use exec\_properties attribute instead. A string used to configure a remote execution platform. Actual builds make no attempt to interpret this, it is treated as opaque data that can be used by a specific SpawnRunner. This can include data from the parent platform's "remote\_execution\_properties" attribute, by using the macro "\{PARENT\_REMOTE\_EXECUTION\_PROPERTIES\}". See the section on [Platform Inheritance](#platform_inheritance) for details. |
+| `constraint_values` | List of [labels](/versions/7.6.1/concepts/labels); [nonconfigurable](/versions/7.6.1/reference/be/common-definitions#configurable-attributes); default is `[]` The combination of constraint choices that this platform comprises. In order for a platform to apply to a given environment, the environment must have at least the values in this list. Each `constraint_value` in this list must be for a different `constraint_setting`. For example, you cannot define a platform that requires the cpu architecture to be both `@platforms//cpu:x86_64` and `@platforms//cpu:arm`. |
+| `exec_properties` | Dictionary: String -> String; [nonconfigurable](/versions/7.6.1/reference/be/common-definitions#configurable-attributes); default is `{}` A map of strings that affect the way actions are executed remotely. Bazel makes no attempt to interpret this, it is treated as opaque data that's forwarded via the Platform field of the [remote execution protocol](https://github.com/bazelbuild/remote-apis). This includes any data from the parent platform's `exec_properties` attributes. If the child and parent platform define the same keys, the child's values are kept. Any keys associated with a value that is an empty string are removed from the dictionary. This attribute is a full replacement for the deprecated `remote_execution_properties`. |
+| `parents` | List of [labels](/versions/7.6.1/concepts/labels); [nonconfigurable](/versions/7.6.1/reference/be/common-definitions#configurable-attributes); default is `[]` The label of a `platform` target that this platform should inherit from. Although the attribute takes a list, there should be no more than one platform present. Any constraint\_settings not set directly on this platform will be found in the parent platform. See the section on [Platform Inheritance](#platform_inheritance) for details. |
+| `remote_execution_properties` | String; [nonconfigurable](/versions/7.6.1/reference/be/common-definitions#configurable-attributes); default is `""` DEPRECATED. Please use exec\_properties attribute instead. A string used to configure a remote execution platform. Actual builds make no attempt to interpret this, it is treated as opaque data that can be used by a specific SpawnRunner. This can include data from the parent platform's "remote\_execution\_properties" attribute, by using the macro "\{PARENT\_REMOTE\_EXECUTION\_PROPERTIES\}". See the section on [Platform Inheritance](#platform_inheritance) for details. |
 
 ## toolchain
 
@@ -249,11 +249,11 @@ details.
 | Attributes | |
 | --- | --- |
 | `name` | [Name](/versions/7.6.1/concepts/labels#target-names); required  A unique name for this target. |
-| `exec_compatible_with` | List of [labels](/versions/7.6.1/concepts/labels); [nonconfigurable](common-definitions#configurable-attributes); default is `[]` A list of `constraint_value`s that must be satisfied by an execution platform in order for this toolchain to be selected for a target building on that platform. |
-| `target_compatible_with` | List of [labels](/versions/7.6.1/concepts/labels); [nonconfigurable](common-definitions#configurable-attributes); default is `[]` A list of `constraint_value`s that must be satisfied by the target platform in order for this toolchain to be selected for a target building for that platform. |
+| `exec_compatible_with` | List of [labels](/versions/7.6.1/concepts/labels); [nonconfigurable](/versions/7.6.1/reference/be/common-definitions#configurable-attributes); default is `[]` A list of `constraint_value`s that must be satisfied by an execution platform in order for this toolchain to be selected for a target building on that platform. |
+| `target_compatible_with` | List of [labels](/versions/7.6.1/concepts/labels); [nonconfigurable](/versions/7.6.1/reference/be/common-definitions#configurable-attributes); default is `[]` A list of `constraint_value`s that must be satisfied by the target platform in order for this toolchain to be selected for a target building for that platform. |
 | `target_settings` | List of [labels](/versions/7.6.1/concepts/labels); default is `[]` A list of `config_setting`s that must be satisfied by the target configuration in order for this toolchain to be selected during toolchain resolution. |
 | `toolchain` | [Name](/versions/7.6.1/concepts/labels#target-names); required The target representing the actual tool or tool suite that is made available when this toolchain is selected. |
-| `toolchain_type` | [Label](/versions/7.6.1/concepts/labels); [nonconfigurable](common-definitions#configurable-attributes); required The label of a `toolchain_type` target that represents the role that this toolchain serves. |
+| `toolchain_type` | [Label](/versions/7.6.1/concepts/labels); [nonconfigurable](/versions/7.6.1/reference/be/common-definitions#configurable-attributes); required The label of a `toolchain_type` target that represents the role that this toolchain serves. |
 
 ## toolchain\_type
 
diff --git a/versions/7.6.1/reference/be/python.mdx b/versions/7.6.1/reference/be/python.mdx
index c97028f6..a1643bb0 100644
--- a/versions/7.6.1/reference/be/python.mdx
+++ b/versions/7.6.1/reference/be/python.mdx
@@ -68,7 +68,7 @@ java_library(
 | `imports` | List of strings; default is `[]` List of import directories to be added to the `PYTHONPATH`. Subject to ["Make variable"](/versions/7.6.1/reference/be/make-variables) substitution. These import directories will be added for this rule and all rules that depend on it (note: not the rules this rule depends on. Each directory will be added to `PYTHONPATH` by [`py_binary`](/versions/7.6.1/reference/be/python#py_binary) rules that depend on this rule.  Absolute paths (paths that start with `/`) and paths that references a path above the execution root are not allowed and will result in an error. |
 | `legacy_create_init` | Integer; default is `-1` Whether to implicitly create empty \_\_init\_\_.py files in the runfiles tree. These are created in every directory containing Python source code or shared libraries, and every parent directory of those directories, excluding the repo root directory. The default, auto, means true unless `--incompatible_default_to_explicit_init_py` is used. If false, the user is responsible for creating (possibly empty) \_\_init\_\_.py files and adding them to the `srcs` of Python targets as required. |
 | `main` | [Label](/versions/7.6.1/concepts/labels); default is `None` The name of the source file that is the main entry point of the application. This file must also be listed in `srcs`. If left unspecified, `name` is used instead (see above). If `name` does not match any filename in `srcs`, `main` must be specified. |
-| `python_version` | String; [nonconfigurable](common-definitions#configurable-attributes); default is `"_INTERNAL_SENTINEL"` Whether to build this target (and its transitive `deps`) for Python 2 or Python 3. Valid values are `"PY2"` and `"PY3"` (the default). The Python version is always reset (possibly by default) to whatever version is specified by this attribute, regardless of the version specified on the command line or by other higher targets that depend on this one. If you want to `select()` on the current Python version, you can inspect the value of `@rules_python//python:python_version`. See [here](https://github.com/bazelbuild/rules_python/blob/120590e2f2b66e5590bf4dc8ebef9c5338984775/python/BUILD#L43) for more information. **Bug warning:** This attribute sets the version for which Bazel builds your target, but due to [#4815](https://github.com/bazelbuild/bazel/issues/4815), the resulting stub script may still invoke the wrong interpreter version at runtime. See [this workaround](https://github.com/bazelbuild/bazel/issues/4815#issuecomment-460777113), which involves defining a `py_runtime` target that points to either Python version as needed, and activating this `py_runtime` by setting `--python_top`. |
+| `python_version` | String; [nonconfigurable](/versions/7.6.1/reference/be/common-definitions#configurable-attributes); default is `"_INTERNAL_SENTINEL"` Whether to build this target (and its transitive `deps`) for Python 2 or Python 3. Valid values are `"PY2"` and `"PY3"` (the default). The Python version is always reset (possibly by default) to whatever version is specified by this attribute, regardless of the version specified on the command line or by other higher targets that depend on this one. If you want to `select()` on the current Python version, you can inspect the value of `@rules_python//python:python_version`. See [here](https://github.com/bazelbuild/rules_python/blob/120590e2f2b66e5590bf4dc8ebef9c5338984775/python/BUILD#L43) for more information. **Bug warning:** This attribute sets the version for which Bazel builds your target, but due to [#4815](https://github.com/bazelbuild/bazel/issues/4815), the resulting stub script may still invoke the wrong interpreter version at runtime. See [this workaround](https://github.com/bazelbuild/bazel/issues/4815#issuecomment-460777113), which involves defining a `py_runtime` target that points to either Python version as needed, and activating this `py_runtime` by setting `--python_top`. |
 | `srcs_version` | String; default is `"PY2AND3"` This attribute declares the target's `srcs` to be compatible with either Python 2, Python 3, or both. To actually set the Python runtime version, use the [`python_version`](/versions/7.6.1/reference/be/python#py_binary.python_version) attribute of an executable Python rule (`py_binary` or `py_test`). Allowed values are: `"PY2AND3"`, `"PY2"`, and `"PY3"`. The values `"PY2ONLY"` and `"PY3ONLY"` are also allowed for historic reasons, but they are essentially the same as `"PY2"` and `"PY3"` and should be avoided. Note that only the executable rules (`py_binary` and `py_library`) actually verify the current Python version against the value of this attribute. (This is a feature; since `py_library` does not change the current Python version, if it did the validation, it'd be impossible to build both `PY2ONLY` and `PY3ONLY` libraries in the same invocation.) Furthermore, if there is a version mismatch, the error is only reported in the execution phase. In particular, the error will not appear in a `bazel build --nobuild` invocation.) To get diagnostic information about which dependencies introduce version requirements, you can run the `find_requirements` aspect on your target:  ```           bazel build  \               --aspects=@rules_python//python:defs.bzl%find_requirements \               --output_groups=pyversioninfo ```  This will build a file with the suffix `-pyversioninfo.txt` giving information about why your target requires one Python version or another. Note that it works even if the given target failed to build due to a version conflict. |
 | `stamp` | Integer; default is `-1` Whether to encode build information into the binary. Possible values:  * `stamp = 1`: Always stamp the build information into the binary, even in   [`--nostamp`](/versions/7.6.1/docs/user-manual#flag--stamp) builds. **This   setting should be avoided**, since it potentially kills remote caching for the   binary and any downstream actions that depend on it. * `stamp = 0`: Always replace build information by constant values. This   gives good build result caching. * `stamp = -1`: Embedding of build information is controlled by the   [`--[no]stamp`](/versions/7.6.1/docs/user-manual#flag--stamp) flag.   Stamped binaries are *not* rebuilt unless their dependencies change. |
 
@@ -136,7 +136,7 @@ py_test(
 | `imports` | List of strings; default is `[]` List of import directories to be added to the `PYTHONPATH`. Subject to ["Make variable"](/versions/7.6.1/reference/be/make-variables) substitution. These import directories will be added for this rule and all rules that depend on it (note: not the rules this rule depends on. Each directory will be added to `PYTHONPATH` by [`py_binary`](/versions/7.6.1/reference/be/python#py_binary) rules that depend on this rule.  Absolute paths (paths that start with `/`) and paths that references a path above the execution root are not allowed and will result in an error. |
 | `legacy_create_init` | Integer; default is `-1` Whether to implicitly create empty \_\_init\_\_.py files in the runfiles tree. These are created in every directory containing Python source code or shared libraries, and every parent directory of those directories, excluding the repo root directory. The default, auto, means true unless `--incompatible_default_to_explicit_init_py` is used. If false, the user is responsible for creating (possibly empty) \_\_init\_\_.py files and adding them to the `srcs` of Python targets as required. |
 | `main` | [Label](/versions/7.6.1/concepts/labels); default is `None` The name of the source file that is the main entry point of the application. This file must also be listed in `srcs`. If left unspecified, `name` is used instead (see above). If `name` does not match any filename in `srcs`, `main` must be specified. |
-| `python_version` | String; [nonconfigurable](common-definitions#configurable-attributes); default is `"_INTERNAL_SENTINEL"` Whether to build this target (and its transitive `deps`) for Python 2 or Python 3. Valid values are `"PY2"` and `"PY3"` (the default). The Python version is always reset (possibly by default) to whatever version is specified by this attribute, regardless of the version specified on the command line or by other higher targets that depend on this one. If you want to `select()` on the current Python version, you can inspect the value of `@rules_python//python:python_version`. See [here](https://github.com/bazelbuild/rules_python/blob/120590e2f2b66e5590bf4dc8ebef9c5338984775/python/BUILD#L43) for more information. **Bug warning:** This attribute sets the version for which Bazel builds your target, but due to [#4815](https://github.com/bazelbuild/bazel/issues/4815), the resulting stub script may still invoke the wrong interpreter version at runtime. See [this workaround](https://github.com/bazelbuild/bazel/issues/4815#issuecomment-460777113), which involves defining a `py_runtime` target that points to either Python version as needed, and activating this `py_runtime` by setting `--python_top`. |
+| `python_version` | String; [nonconfigurable](/versions/7.6.1/reference/be/common-definitions#configurable-attributes); default is `"_INTERNAL_SENTINEL"` Whether to build this target (and its transitive `deps`) for Python 2 or Python 3. Valid values are `"PY2"` and `"PY3"` (the default). The Python version is always reset (possibly by default) to whatever version is specified by this attribute, regardless of the version specified on the command line or by other higher targets that depend on this one. If you want to `select()` on the current Python version, you can inspect the value of `@rules_python//python:python_version`. See [here](https://github.com/bazelbuild/rules_python/blob/120590e2f2b66e5590bf4dc8ebef9c5338984775/python/BUILD#L43) for more information. **Bug warning:** This attribute sets the version for which Bazel builds your target, but due to [#4815](https://github.com/bazelbuild/bazel/issues/4815), the resulting stub script may still invoke the wrong interpreter version at runtime. See [this workaround](https://github.com/bazelbuild/bazel/issues/4815#issuecomment-460777113), which involves defining a `py_runtime` target that points to either Python version as needed, and activating this `py_runtime` by setting `--python_top`. |
 | `srcs_version` | String; default is `"PY2AND3"` This attribute declares the target's `srcs` to be compatible with either Python 2, Python 3, or both. To actually set the Python runtime version, use the [`python_version`](/versions/7.6.1/reference/be/python#py_binary.python_version) attribute of an executable Python rule (`py_binary` or `py_test`). Allowed values are: `"PY2AND3"`, `"PY2"`, and `"PY3"`. The values `"PY2ONLY"` and `"PY3ONLY"` are also allowed for historic reasons, but they are essentially the same as `"PY2"` and `"PY3"` and should be avoided. Note that only the executable rules (`py_binary` and `py_library`) actually verify the current Python version against the value of this attribute. (This is a feature; since `py_library` does not change the current Python version, if it did the validation, it'd be impossible to build both `PY2ONLY` and `PY3ONLY` libraries in the same invocation.) Furthermore, if there is a version mismatch, the error is only reported in the execution phase. In particular, the error will not appear in a `bazel build --nobuild` invocation.) To get diagnostic information about which dependencies introduce version requirements, you can run the `find_requirements` aspect on your target:  ```           bazel build  \               --aspects=@rules_python//python:defs.bzl%find_requirements \               --output_groups=pyversioninfo ```  This will build a file with the suffix `-pyversioninfo.txt` giving information about why your target requires one Python version or another. Note that it works even if the given target failed to build due to a version conflict. |
 | `stamp` | Integer; default is `0` See the section on [py\_binary()](/versions/7.6.1/reference/be/python#py_binary_args) arguments, except that the stamp argument is set to 0 by default for tests. |
 
diff --git a/versions/7.6.1/reference/be/workspace.mdx b/versions/7.6.1/reference/be/workspace.mdx
index 356f8044..3078875e 100644
--- a/versions/7.6.1/reference/be/workspace.mdx
+++ b/versions/7.6.1/reference/be/workspace.mdx
@@ -25,8 +25,7 @@ bind(name, actual, compatible_with, deprecation, distribs, features, licenses, r
 
 *Warning: use of `bind()` is not recommended. See "[Consider removing bind](https://github.com/bazelbuild/bazel/issues/1952)" for a long
 discussion of its issues and alternatives. In particular, consider the use of
-[`repo_mapping`
-repository attributes](https://bazel.build/versions/7.6.1/rules/repository_rules#attributes).*
+[`repo_mapping` repository attributes](https://bazel.build/versions/7.6.1/rules/repository_rules#attributes).*
 
 *Warning: `select()` cannot be used in `bind()`. See the [Configurable Attributes FAQ](/versions/7.6.1/docs/configurable-attributes#bind-select) for
 details.*
@@ -114,8 +113,7 @@ local_repository(name, path, repo_mapping)
 ```
 
 Allows targets from a local directory to be bound. This means that the current repository can
-use targets defined in this other directory. See the [bind
-section](/versions/7.6.1/reference/be/workspace#bind_examples) for more details.
+use targets defined in this other directory. See the [bind section](/versions/7.6.1/reference/be/workspace#bind_examples) for more details.
 
 #### Examples
 
diff --git a/versions/7.6.1/reference/command-line-reference.mdx b/versions/7.6.1/reference/command-line-reference.mdx
index b864fa2e..0cf47566 100644
--- a/versions/7.6.1/reference/command-line-reference.mdx
+++ b/versions/7.6.1/reference/command-line-reference.mdx
@@ -429,7 +429,7 @@ This option affects semantics of the Starlark language or the build API accessib
     [`loading_and_analysis`](#effect_tag_LOADING_AND_ANALYSIS), [`experimental`](#metadata_tag_EXPERIMENTAL)
 
 `--[no]experimental_isolated_extension_usages` default: "false"
-:   If true, enables the isolate parameter in the use\_extension function.
+:   If true, enables the isolate parameter in the use\_extension function.
 
     Tags:
     [`loading_and_analysis`](#effect_tag_LOADING_AND_ANALYSIS)
diff --git a/versions/7.6.1/reference/glossary.mdx b/versions/7.6.1/reference/glossary.mdx
index 93fab572..f8c04ab8 100644
--- a/versions/7.6.1/reference/glossary.mdx
+++ b/versions/7.6.1/reference/glossary.mdx
@@ -21,8 +21,7 @@ An in-memory graph of [actions](#action) and the [artifacts](#artifact) that
 these actions read and generate. The graph might include artifacts that exist as
 source files (for example, in the file system) as well as generated
 intermediate/final artifacts that are not mentioned in `BUILD` files. Produced
-during the [analysis phase](#analysis-phase) and used during the [execution
-phase](#execution-phase).
+during the [analysis phase](#analysis-phase) and used during the [execution phase](#execution-phase).
 
 ### Action graph query (aquery) {#action-graph-query}
 A [query](#query-concept) tool that can query over build [actions](#action).
@@ -37,8 +36,7 @@ invalidate individual actions deterministically.
 
 ### Analysis phase {#analysis-phase}
 The second phase of a build. Processes the [target graph](#target-graph)
-specified in [`BUILD` files](#build-file) to produce an in-memory [action
-graph](#action-graph) that determines the order of actions to run during the
+specified in [`BUILD` files](#build-file) to produce an in-memory [action graph](#action-graph) that determines the order of actions to run during the
 [execution phase](#execution-phase). This is the phase in which rule
 implementations are evaluated.
 
@@ -81,8 +79,7 @@ target's source files, dependencies, and custom compiler options. The particular
 attributes available for a given target depend on its rule type.
 
 ### .bazelrc {#bazelrc}
-Bazel’s configuration file used to change the default values for [startup
-flags](#startup-flags) and [command flags](#command-flags), and to define common
+Bazel’s configuration file used to change the default values for [startup flags](#startup-flags) and [command flags](#command-flags), and to define common
 groups of options that can then be set together on the Bazel command line using
 a `--config` flag. Bazel can combine settings from multiple bazelrc files
 (systemwide, per-workspace, per-user, or from a custom location), and a
@@ -108,8 +105,7 @@ directory.
 
 ### .bzl File {#bzl-file}
 A file that defines rules, [macros](#macro), and constants written in
-[Starlark](#starlark). These can then be imported into [`BUILD`
-files](#build-file) using the `load()` function.
+[Starlark](#starlark). These can then be imported into [`BUILD` files](#build-file) using the `load()` function.
 
 {/* TODO: ### Build event protocol */}
 
@@ -117,8 +113,7 @@ files](#build-file) using the `load()` function.
 
 ### Build graph {#build-graph}
 The dependency graph that Bazel constructs and traverses to perform a build.
-Includes nodes like [targets](#target), [configured
-targets](#configured-target), [actions](#action), and [artifacts](#artifact). A
+Includes nodes like [targets](#target), [configured targets](#configured-target), [actions](#action), and [artifacts](#artifact). A
 build is considered complete when all [artifacts](#artifact) on which a set of
 requested targets depend are verified as up-to-date.
 
@@ -158,8 +153,7 @@ graphs and restart the [analysis phase](#analysis-phase).
 ### Configuration {#configuration}
 Information outside of [rule](#rule) definitions that impacts how rules generate
 [actions](#action). Every build has at least one configuration specifying the
-target platform, action environment variables, and command-line [build
-flags](#command-flags). [Transitions](#transition) may create additional
+target platform, action environment variables, and command-line [build flags](#command-flags). [Transitions](#transition) may create additional
 configurations, such as for host tools or cross-compilation.
 
 **See also:** [Configurations](/versions/7.6.1/extending/rules#configurations)
@@ -174,8 +168,7 @@ configuration of `//:c` because changing `--javacopt` unnecessarily breaks C++
 build cacheability.
 
 ### Configured query (cquery) {#configured-query}
-A [query](#query-concept) tool that queries over [configured
-targets](#configured-target) (after the [analysis phase](#analysis-phase)
+A [query](#query-concept) tool that queries over [configured targets](#configured-target) (after the [analysis phase](#analysis-phase)
 completes). This means `select()` and [build flags](#command-flags) (such as
 `--platforms`) are accurately reflected in the results.
 
@@ -191,8 +184,7 @@ build, it has two configured targets: `` and ``.
 ### Correctness {#correctness}
 A build is correct when its output faithfully reflects the state of its
 transitive inputs. To achieve correct builds, Bazel strives to be
-[hermetic](#hermeticity), reproducible, and making [build
-analysis](#analysis-phase) and [action execution](#execution-phase)
+[hermetic](#hermeticity), reproducible, and making [build analysis](#analysis-phase) and [action execution](#execution-phase)
 deterministic.
 
 ### Dependency {#dependency}
@@ -234,8 +226,7 @@ compilation). A dynamic execution strategy can provide the best possible
 incremental and clean build times.
 
 ### Execution phase {#execution-phase}
-The third phase of a build. Executes the [actions](#action) in the [action
-graph](#action-graph) created during the [analysis phase](#analysis-phase).
+The third phase of a build. Executes the [actions](#action) in the [action graph](#action-graph) created during the [analysis phase](#analysis-phase).
 These actions invoke executables (compilers, scripts) to read and write
 [artifacts](#artifact). *Spawn strategies* control how these actions are
 executed: locally, remotely, dynamically, sandboxed, docker, and so on.
@@ -285,8 +276,7 @@ syntax may be omitted.
 The first phase of a build where Bazel executes [`BUILD` files](#build-file) to
 create [packages](#package). [Macros](#macro) and certain functions like
 `glob()` are evaluated in this phase. Interleaved with the second phase of the
-build, the [analysis phase](#analysis-phase), to build up a [target
-graph](#target-graph).
+build, the [analysis phase](#analysis-phase), to build up a [target graph](#target-graph).
 
 ### Macro {#macro}
 A mechanism to compose multiple [rule](#rule) target declarations together under
@@ -321,8 +311,7 @@ Module metadata is hosted in Bazel registries.
 
 ### Module Extension {#module-extension}
 A piece of logic that can be run to generate [repos](#repository) by reading
-inputs from across the [module](#module) dependency graph and invoking [repo
-rules](#repository-rule). Module extensions have capabilities similar to repo
+inputs from across the [module](#module) dependency graph and invoking [repo rules](#repository-rule). Module extensions have capabilities similar to repo
 rules, allowing them to access the internet, perform file I/O, and so on.
 
 **See also:** [Module extensions](/versions/7.6.1/external/extension)
@@ -335,8 +324,7 @@ example, `native.cc_library` or `native.java_library`). User-defined rules
 
 ### Output base {#output-base}
 A [workspace](#workspace)-specific directory to store Bazel output files. Used
-to separate outputs from the *workspace*'s source tree (the [main
-repo](#repository)). Located in the [output user root](#output-user-root).
+to separate outputs from the *workspace*'s source tree (the [main repo](#repository)). Located in the [output user root](#output-user-root).
 
 ### Output groups {#output-groups}
 A group of files that is expected to be built when Bazel finishes building a
@@ -391,8 +379,7 @@ query variants: [query](#query-command), [cquery](#configured-query), and
 [aquery](#action-graph-query).
 
 ### query (command) {#query-command}
-A [query](#query-concept) tool that operates over the build's post-[loading
-phase](#loading-phase) [target graph](#target-graph). This is relatively fast,
+A [query](#query-concept) tool that operates over the build's post-[loading phase](#loading-phase) [target graph](#target-graph). This is relatively fast,
 but can't analyze the effects of `select()`, [build flags](#command-flags),
 [artifacts](#artifact), or build [actions](#action).
 
@@ -410,8 +397,7 @@ repo; multiple such files can coexist in a directory.
 The *main repo* is the repo in which the current Bazel command is being run.
 
 *External repos* are defined by specifying [modules](#module) in `MODULE.bazel`
-files, or invoking [repo rules](#repository-rule) in [module
-extensions](#module-extension). They can be fetched on demand to a predetermined
+files, or invoking [repo rules](#repository-rule) in [module extensions](#module-extension). They can be fetched on demand to a predetermined
 "magical" location on disk.
 
 Each repo has a unique, constant *canonical* name, and potentially different
@@ -422,8 +408,7 @@ Each repo has a unique, constant *canonical* name, and potentially different
 ### Repository cache {#repo-cache}
 A shared content-addressable cache of files downloaded by Bazel for builds,
 shareable across [workspaces](#workspace). Enables offline builds after the
-initial download. Commonly used to cache files downloaded through [repository
-rules](#repository-rule) like `http_archive` and repository rule APIs like
+initial download. Commonly used to cache files downloaded through [repository rules](#repository-rule) like `http_archive` and repository rule APIs like
 `repository_ctx.download`. Files are cached only if their SHA-256 checksums are
 specified for the download.
 
@@ -457,8 +442,7 @@ Rules are instantiated to produce rule targets in the
 [loading phase](#loading-phase). In the [analysis phase](#analysis-phase) rule
 targets communicate information to their downstream dependencies in the form of
 [providers](#provider), and register [actions](#action) describing how to
-generate their output artifacts. These actions are run in the [execution
-phase](#execution-phase).
+generate their output artifacts. These actions are run in the [execution phase](#execution-phase).
 
 Note: Historically the term "rule" has been used to refer to a rule target.
 This usage was inherited from tools like Make, but causes confusion and should
@@ -502,8 +486,7 @@ support the stamp attribute.
 ### Starlark {#starlark}
 The extension language for writing [rules](/versions/7.6.1/extending/rules) and [macros](#macro). A
 restricted subset of Python (syntactically and grammatically) aimed for the
-purpose of configuration, and for better performance. Uses the [`.bzl`
-file](#bzl-file) extension. [`BUILD` files](#build-file) use an even more
+purpose of configuration, and for better performance. Uses the [`.bzl` file](#bzl-file) extension. [`BUILD` files](#build-file) use an even more
 restricted version of Starlark (such as no `def` function definitions), formerly
 known as Skylark.
 
@@ -525,8 +508,7 @@ An object that is defined in a [`BUILD` file](#build-file) and identified by a
 [label](#label). Targets represent the buildable units of a workspace from
 the perspective of the end user.
 
-A target that is declared by instantiating a [rule](#rule) is called a [rule
-target](#rule-target). Depending on the rule, these may be runnable (like
+A target that is declared by instantiating a [rule](#rule) is called a [rule target](#rule-target). Depending on the rule, these may be runnable (like
 `cc_binary`) or testable (like `cc_test`). Rule targets typically depend on
 other targets via their [attributes](#attribute) (such as `deps`); these
 dependencies form the basis of the [target graph](#target-graph).
@@ -537,14 +519,11 @@ within a `BUILD` file. As a special case, the `BUILD` file of any package is
 always considered a source file target in that package.
 
 Targets are discovered during the [loading phase](#loading-phase). During the
-[analysis phase](#analysis-phase), targets are associated with [build
-configurations](#configuration) to form [configured
-targets](#configured-target).
+[analysis phase](#analysis-phase), targets are associated with [build configurations](#configuration) to form [configured targets](#configured-target).
 
 ### Target graph {#target-graph}
 An in-memory graph of [targets](#target) and their dependencies. Produced during
-the [loading phase](#loading-phase) and used as an input to the [analysis
-phase](#analysis-phase).
+the [loading phase](#loading-phase) and used as an input to the [analysis phase](#analysis-phase).
 
 ### Target pattern {#target-pattern}
 A way to specify a group of [targets](#target) on the command line. Commonly
@@ -557,8 +536,7 @@ packages recursively from the root of the [workspace](#workspace).
 Rule [targets](#target) instantiated from test rules, and therefore contains a
 test executable. A return code of zero from the completion of the executable
 indicates test success. The exact contract between Bazel and tests (such as test
-environment variables, test result collection methods) is specified in the [Test
-Encyclopedia](/versions/7.6.1/reference/test-encyclopedia).
+environment variables, test result collection methods) is specified in the [Test Encyclopedia](/versions/7.6.1/reference/test-encyclopedia).
 
 ### Toolchain {#toolchain}
 A set of tools to build outputs for a language. Typically, a toolchain includes
@@ -572,8 +550,7 @@ A build [target](#target) is top-level if it’s requested on the Bazel command
 line. For example, if `//:foo` depends on `//:bar`, and `bazel build //:foo` is
 called, then for this build, `//:foo` is top-level, and `//:bar` isn’t
 top-level, although both targets will need to be built. An important difference
-between top-level and non-top-level targets is that [command
-flags](#command-flags) set on the Bazel command line (or via
+between top-level and non-top-level targets is that [command flags](#command-flags) set on the Bazel command line (or via
 [.bazelrc](#bazelrc)) will set the [configuration](#configuration) for top-level
 targets, but might be modified by a [transition](#transition) for non-top-level
 targets.
@@ -604,8 +581,7 @@ or `.bzl` file may load a given `.bzl` file. Without context, usually
 **See also:** [Visibility documentation](/versions/7.6.1/concepts/visibility)
 
 ### Workspace {#workspace}
-The environment shared by all Bazel commands run from the same [main
-repository](#repository).
+The environment shared by all Bazel commands run from the same [main repository](#repository).
 
 Note that historically the concepts of "repository" and "workspace" have been
 conflated; the term "workspace" has often been used to refer to the main
diff --git a/versions/7.6.1/release/backward-compatibility.mdx b/versions/7.6.1/release/backward-compatibility.mdx
index ae0b831b..bb8183ea 100644
--- a/versions/7.6.1/release/backward-compatibility.mdx
+++ b/versions/7.6.1/release/backward-compatibility.mdx
@@ -6,11 +6,9 @@ This page provides information about how to handle backward compatibility,
 including migrating from one release to another and how to communicate
 incompatible changes.
 
-Bazel is evolving. Minor versions released as part of an [LTS major
-version](/versions/7.6.1/release#bazel-versioning) are fully backward-compatible. New major LTS
+Bazel is evolving. Minor versions released as part of an [LTS major version](/versions/7.6.1/release#bazel-versioning) are fully backward-compatible. New major LTS
 releases may contain incompatible changes that require some migration effort.
-For more information about Bazel's release model, please check out the [Release
-Model](/versions/7.6.1/release) page.
+For more information about Bazel's release model, please check out the [Release Model](/versions/7.6.1/release) page.
 
 ## Summary {#summary}
 
@@ -59,8 +57,7 @@ available.
 ## Communicating incompatible changes {#communicating-incompatible-changes}
 
 The primary source of information about incompatible changes are GitHub issues
-marked with an ["incompatible-change"
-label](https://github.com/bazelbuild/bazel/issues?q=label%3Aincompatible-change).
+marked with an ["incompatible-change" label](https://github.com/bazelbuild/bazel/issues?q=label%3Aincompatible-change).
 
 For every incompatible change, the issue specifies the following:
 
diff --git a/versions/7.6.1/release/index.mdx b/versions/7.6.1/release/index.mdx
index d3dc9925..7abbb747 100644
--- a/versions/7.6.1/release/index.mdx
+++ b/versions/7.6.1/release/index.mdx
@@ -2,16 +2,14 @@
 title: 'Release Model'
 ---
 
-As announced in [the original blog
-post](https://blog.bazel.build/2020/11/10/long-term-support-release.html), Bazel
+As announced in [the original blog post](https://blog.bazel.build/2020/11/10/long-term-support-release.html), Bazel
 4.0 and higher versions provides support for two release tracks: rolling
 releases and long term support (LTS) releases. This page covers the latest
 information about Bazel's release model.
 
 ## Release versioning {#bazel-versioning}
 
-Bazel uses a _major.minor.patch_ [Semantic
-Versioning](https://semver.org/) scheme.
+Bazel uses a _major.minor.patch_ [Semantic Versioning](https://semver.org/) scheme.
 
 *   A _major release_ contains features that are not backward compatible with
     the previous release. Each major Bazel version is an LTS release.
@@ -54,8 +52,7 @@ Bazel regularly publish releases for two release tracks.
     release.
 *   Rolling releases can ship incompatible changes. Incompatible flags are
     recommended for major breaking changes, rolling out incompatible changes
-    should follow our [backward compatibility
-    policy](/versions/7.6.1/release/backward-compatibility).
+    should follow our [backward compatibility policy](/versions/7.6.1/release/backward-compatibility).
 
 ### LTS releases {#lts-releases}
 
@@ -71,8 +68,7 @@ Bazel regularly publish releases for two release tracks.
 *   A Bazel LTS release enters the Deprecated stage after being in ​​the
     Maintenance stage for 2 years.
 
-For planned releases, please check our [release
-issues](https://github.com/bazelbuild/bazel/issues?q=is%3Aopen+is%3Aissue+label%3Arelease)
+For planned releases, please check our [release issues](https://github.com/bazelbuild/bazel/issues?q=is%3Aopen+is%3Aissue+label%3Arelease)
 on Github.
 
 ## Support matrix {#support-matrix}
@@ -84,8 +80,7 @@ on Github.
 | Bazel 5 | Maintenance | [5.4.1](https://github.com/bazelbuild/bazel/releases/tag/5.4.1) | Jan 2025 |
 | Bazel 4 | Maintenance | [4.2.4](https://github.com/bazelbuild/bazel/releases/tag/4.2.4) | Jan 2024 |
 
-All Bazel releases can be found on the [release
-page](https://github.com/bazelbuild/bazel/releases) on GitHub.
+All Bazel releases can be found on the [release page](https://github.com/bazelbuild/bazel/releases) on GitHub.
 
 Note: Bazel version older than Bazel 4 are no longer supported, Bazel users are
 recommended to upgrade to the latest LTS release or use rolling releases if you
@@ -117,8 +112,7 @@ For LTS releases, the procedure and policies below are followed:
 1.  Identify release blockers and fix issues found on the release branch.
     *   The release branch is tested with the same test suite in
         [postsubmit](https://buildkite.com/bazel/bazel-bazel) and
-        [downstream test pipeline]
-        (https://buildkite.com/bazel/bazel-at-head-plus-downstream)
+        [downstream test pipeline](https://buildkite.com/bazel/bazel-at-head-plus-downstream)
         on Bazel CI. The Bazel team monitors testing results of the release
         branch and fixes any regressions found.
 1.  Create a new release candidate from the release branch when all known
@@ -170,5 +164,4 @@ feature.
 ## Rule compatibility {#rule-compatibility}
 
 If you are a rule authors and want to maintain compatibility with different
-Bazel versions, please check out the [Rule
-Compatibility](/versions/7.6.1/release/rule-compatibility) page.
\ No newline at end of file
+Bazel versions, please check out the [Rule Compatibility](/versions/7.6.1/release/rule-compatibility) page.
\ No newline at end of file
diff --git a/versions/7.6.1/release/rule-compatibility.mdx b/versions/7.6.1/release/rule-compatibility.mdx
index f7daa8fe..d34fc01b 100644
--- a/versions/7.6.1/release/rule-compatibility.mdx
+++ b/versions/7.6.1/release/rule-compatibility.mdx
@@ -53,18 +53,15 @@ Bazel LTS release.
 As Bazel rules authors, you can ensure a manageable migration process for users
 by following these best practices:
 
-1.  The rule should follow [Semantic
-    Versioning](https://semver.org/): minor versions of the same
+1.  The rule should follow [Semantic Versioning](https://semver.org/): minor versions of the same
     major version are backward compatible.
 1.  The rule at HEAD should be compatible with the latest Bazel LTS release.
 1.  The rule at HEAD should be compatible with Bazel at HEAD. To achieve this,
     you can
     *   Set up your own CI testing with Bazel at HEAD
-    *   Add your project to [Bazel downstream
-        testing](https://github.com/bazelbuild/continuous-integration/blob/master/docs/downstream-testing.md);
+    *   Add your project to [Bazel downstream testing](https://github.com/bazelbuild/continuous-integration/blob/master/docs/downstream-testing.md);
         the Bazel team files issues to your project if breaking changes in Bazel
-        affect your project, and you must follow our [downstream project
-        policies](https://github.com/bazelbuild/continuous-integration/blob/master/docs/downstream-testing.md#downstream-project-policies)
+        affect your project, and you must follow our [downstream project policies](https://github.com/bazelbuild/continuous-integration/blob/master/docs/downstream-testing.md#downstream-project-policies)
         to address issues timely.
 1.  The latest major version of the rule must be compatible with the latest
     Bazel LTS release.
diff --git a/versions/7.6.1/remote/bep-glossary.mdx b/versions/7.6.1/remote/bep-glossary.mdx
index 128352c1..54f6d407 100644
--- a/versions/7.6.1/remote/bep-glossary.mdx
+++ b/versions/7.6.1/remote/bep-glossary.mdx
@@ -36,7 +36,7 @@ BEP contains an event like the following:
 ## ActionExecuted {#actionexecuted}
 
 Provides details about the execution of a specific
-[Action](/versions/7.6.1/rules/lib/actions) in a build. By default, this event is
+[Action](/versions/7.6.1/rules/lib/builtins/actions) in a build. By default, this event is
 included in the BEP only for failed actions, to support identifying the root cause
 of build failures. Users may set the `--build_event_publish_all_actions` flag
 to include all `ActionExecuted` events.
@@ -411,5 +411,4 @@ workspace, such as the execution root.
 
 ## WorkspaceStatus {#workspacestatus}
 
-A single `WorkspaceStatus` event contains the result of the [workspace status
-command](/versions/7.6.1/docs/user-manual#workspace-status).
+A single `WorkspaceStatus` event contains the result of the [workspace status command](/versions/7.6.1/docs/user-manual#workspace-status).
diff --git a/versions/7.6.1/remote/bep.mdx b/versions/7.6.1/remote/bep.mdx
index 72cae7c3..85ebca18 100644
--- a/versions/7.6.1/remote/bep.mdx
+++ b/versions/7.6.1/remote/bep.mdx
@@ -2,14 +2,12 @@
 title: 'Build Event Protocol'
 ---
 
-The [Build Event
-Protocol](https://github.com/bazelbuild/bazel/blob/master/src/main/java/com/google/devtools/build/lib/buildeventstream/proto/build_event_stream.proto)
+The [Build Event Protocol](https://github.com/bazelbuild/bazel/blob/master/src/main/java/com/google/devtools/build/lib/buildeventstream/proto/build_event_stream.proto)
 (BEP) allows third-party programs to gain insight into a Bazel invocation. For
 example, you could use the BEP to gather information for an IDE
 plugin or a dashboard that displays build results.
 
-The protocol is a set of [protocol
-buffer](https://developers.google.com/protocol-buffers/) messages with some
+The protocol is a set of [protocol buffer](https://developers.google.com/protocol-buffers/) messages with some
 semantics defined on top of it. It includes information about build and test
 results, build progress, the build configuration and much more. The BEP is
 intended to be consumed programmatically and makes parsing Bazel’s
@@ -20,16 +18,13 @@ build event is a protocol buffer message consisting of a build event identifier,
 a set of child event identifiers, and a payload.
 
 *  __Build Event Identifier:__ Depending on the kind of build event, it might be
-an [opaque
-string](https://github.com/bazelbuild/bazel/blob/16a107d/src/main/java/com/google/devtools/build/lib/buildeventstream/proto/build_event_stream.proto#L91)
-or [structured
-information](https://github.com/bazelbuild/bazel/blob/16a107d/src/main/java/com/google/devtools/build/lib/buildeventstream/proto/build_event_stream.proto#L123)
+an [opaque string](https://github.com/bazelbuild/bazel/blob/16a107d/src/main/java/com/google/devtools/build/lib/buildeventstream/proto/build_event_stream.proto#L91)
+or [structured information](https://github.com/bazelbuild/bazel/blob/16a107d/src/main/java/com/google/devtools/build/lib/buildeventstream/proto/build_event_stream.proto#L123)
 revealing more about the build event. A build event identifier is unique within
 a build.
 
 *  __Children:__ A build event may announce other build events, by including
-their build event identifiers in its [children
-field](https://github.com/bazelbuild/bazel/blob/16a107d/src/main/java/com/google/devtools/build/lib/buildeventstream/proto/build_event_stream.proto#L469).
+their build event identifiers in its [children field](https://github.com/bazelbuild/bazel/blob/16a107d/src/main/java/com/google/devtools/build/lib/buildeventstream/proto/build_event_stream.proto#L469).
 For example, the `PatternExpanded` build event announces the targets it expands
 to as children. The protocol guarantees that all events, except for the first
 event, are announced by a previous event.
@@ -91,8 +86,7 @@ human-readable formats, such as text and JSON:
 
 ## Build Event Service {#build-event-service}
 
-The [Build Event
-Service](https://github.com/googleapis/googleapis/blob/master/google/devtools/build/v1/publish_build_event.proto)
+The [Build Event Service](https://github.com/googleapis/googleapis/blob/master/google/devtools/build/v1/publish_build_event.proto)
 Protocol is a generic [gRPC](https://www.grpc.io) service for publishing build events. The Build Event
 Service protocol is independent of the BEP and treats BEP events as opaque bytes.
 Bazel ships with a gRPC client implementation of the Build Event Service protocol that
@@ -137,8 +131,7 @@ For a description of each of these flags, see the
 The BEP typically contains many references to log files (test.log, test.xml,
 etc. ) stored on the machine where Bazel is running. A remote BES server
 typically can't access these files as they are on different machines. A way to
-work around this issue is to use Bazel with [remote
-caching](/versions/7.6.1/remote/caching).
+work around this issue is to use Bazel with [remote caching](/versions/7.6.1/remote/caching).
 Bazel will upload all output files to the remote cache (including files
 referenced in the BEP) and the BES server can then fetch the referenced files
 from the cache.
diff --git a/versions/7.6.1/remote/cache-local.mdx b/versions/7.6.1/remote/cache-local.mdx
index f91577a4..8f08c4dc 100644
--- a/versions/7.6.1/remote/cache-local.mdx
+++ b/versions/7.6.1/remote/cache-local.mdx
@@ -18,8 +18,7 @@ execution. However, local execution presents some additional challenges.
 ## Checking your cache hit rate {#cache-hits}
 
 Successful remote cache hits will show up in the status line, similar to
-[Cache Hits rate with Remote
-Execution](/versions/7.6.1/remote/cache-remote#check-cache-hits).
+[Cache Hits rate with Remote Execution](/versions/7.6.1/remote/cache-remote#check-cache-hits).
 
 In the standard output of your Bazel run, you will see something like the
 following:
@@ -66,8 +65,7 @@ the steps in this section.
    message you see does not give you enough information, try adding
    `--verbose_failures`.
 
-2. Follow the steps from [Troubleshooting cache hits for remote
-   execution](/versions/7.6.1/remote/cache-remote#troubleshooting_cache_hits) to
+2. Follow the steps from [Troubleshooting cache hits for remote execution](/versions/7.6.1/remote/cache-remote#troubleshooting_cache_hits) to
    ensure that your cache-writing Bazel invocations are able to get cache hits
    on the same machine and across machines.
 
@@ -81,7 +79,6 @@ the steps in this section.
    b. Ensure your cache-reading Bazel invocations build the same targets as the
       cache-writing Bazel invocations.
 
-   c. Follow the same steps as to [ensure caching across
-      machines](/versions/7.6.1/remote/cache-remote#caching-across-machines),
+   c. Follow the same steps as to [ensure caching across machines](/versions/7.6.1/remote/cache-remote#caching-across-machines),
       to ensure caching from your cache-writing Bazel invocation to your
       cache-reading Bazel invocation.
diff --git a/versions/7.6.1/remote/caching.mdx b/versions/7.6.1/remote/caching.mdx
index 587c3d9a..6420f773 100644
--- a/versions/7.6.1/remote/caching.mdx
+++ b/versions/7.6.1/remote/caching.mdx
@@ -126,7 +126,7 @@ not provide technical support for bazel-remote.
 
 This cache stores contents on disk and also provides garbage collection
 to enforce an upper storage limit and clean unused artifacts. The cache is
-available as a [docker image] and its code is available on
+available as a [docker image](https://hub.docker.com/r/buchgr/bazel-remote-cache/) and its code is available on
 [GitHub](https://github.com/buchgr/bazel-remote/).
 Both the REST and gRPC remote cache APIs are supported.
 
@@ -308,8 +308,7 @@ or for the age of individual cache entries. Bazel will automatically garbage
 collect the disk cache while idling between builds; the idle timer can be set
 with `--experimental_disk_cache_gc_idle_delay` (defaulting to 5 minutes).
 
-As an alternative to automatic garbage collection, we also provide a [tool](
-https://github.com/bazelbuild/bazel/tree/master/src/tools/diskcache) to run a
+As an alternative to automatic garbage collection, we also provide a [tool](https://github.com/bazelbuild/bazel/tree/master/src/tools/diskcache) to run a
 garbage collection on demand.
 
 ## Known issues {#known-issues}
diff --git a/versions/7.6.1/remote/dynamic.mdx b/versions/7.6.1/remote/dynamic.mdx
index 17990a2e..791684d3 100644
--- a/versions/7.6.1/remote/dynamic.mdx
+++ b/versions/7.6.1/remote/dynamic.mdx
@@ -12,8 +12,7 @@ alike.
 This page describes how to enable, tune, and debug dynamic execution. If you
 have both local and remote execution set up and are trying to adjust Bazel
 settings for better performance, this page is for you. If you don't already have
-remote execution set up, go to the Bazel [Remote Execution
-Overview](/versions/7.6.1/remote/rbe) first.
+remote execution set up, go to the Bazel [Remote Execution Overview](/versions/7.6.1/remote/rbe) first.
 
 ## Enabling dynamic execution? {#enabling-dynamic-execution}
 
@@ -44,14 +43,12 @@ are likely. The default value is 1000ms, but should be tuned to being just a bit
 longer than cache hits usually take. The actual time depends both on the remote
 system and on how long a round-trip takes. Usually, the value will be the same
 for all users of a given remote system, unless some of them are far enough away
-to add roundtrip latency. You can use the [Bazel profiling
-features](/versions/7.6.1/rules/performance#performance-profiling) to look at how long typical
+to add roundtrip latency. You can use the [Bazel profiling features](/versions/7.6.1/rules/performance#performance-profiling) to look at how long typical
 cache hits take.
 
 Dynamic execution can be used with local sandboxed strategy as well as with
 [persistent workers](/versions/7.6.1/remote/persistent). Persistent workers will automatically
-run with sandboxing when used with dynamic execution, and cannot use [multiplex
-workers](/versions/7.6.1/remote/multiplex). On Darwin and Windows systems, the sandboxed
+run with sandboxing when used with dynamic execution, and cannot use [multiplex workers](/versions/7.6.1/remote/multiplex). On Darwin and Windows systems, the sandboxed
 strategy can be slow; you can pass `--reuse_sandbox_directories` to reduce
 overhead of creating sandboxes on these systems.
 
@@ -67,8 +64,7 @@ entire action fails. This is an intentional choice to prevent differences
 between local and remote execution from going unnoticed.
 
 For more background on how dynamic execution and its locking works, see Julio
-Merino's excellent [blog
-posts](https://jmmv.dev/series/bazel-dynamic-execution/)
+Merino's excellent [blog posts](https://jmmv.dev/series/bazel-dynamic-execution/)
 
 ## When should I use dynamic execution? {#when-to-use}
 
diff --git a/versions/7.6.1/remote/output-directories.mdx b/versions/7.6.1/remote/output-directories.mdx
index c3f73834..c244a9b5 100644
--- a/versions/7.6.1/remote/output-directories.mdx
+++ b/versions/7.6.1/remote/output-directories.mdx
@@ -25,7 +25,7 @@ The solution that's currently implemented:
 
 * Bazel must be invoked from a directory containing a repo boundary file, or a
   subdirectory thereof. In other words, Bazel must be invoked from inside a
-  [repository](../external/overview#repository). Otherwise, an error is
+  [repository](/versions/7.6.1/external/overview#repository). Otherwise, an error is
   reported.
 * The _outputRoot_ directory defaults to `${XDG_CACHE_HOME}/bazel` (or
   `~/.cache/bazel`, if the `XDG_CACHE_HOME` environment variable is not set) on
diff --git a/versions/7.6.1/remote/persistent.mdx b/versions/7.6.1/remote/persistent.mdx
index f295cbee..c14d4fa1 100644
--- a/versions/7.6.1/remote/persistent.mdx
+++ b/versions/7.6.1/remote/persistent.mdx
@@ -264,7 +264,6 @@ For more information on persistent workers, see:
 *   [Original persistent workers blog post](https://blog.bazel.build/2015/12/10/java-workers.html)
 *   [Haskell implementation description](https://www.tweag.io/blog/2019-09-25-bazel-ghc-persistent-worker-internship/)
 *   [Blog post by Mike Morearty](https://medium.com/@mmorearty/how-to-create-a-persistent-worker-for-bazel-7738bba2cabb)
-*   [Front End Development with Bazel: Angular/TypeScript and Persistent Workers
-    w/ Asana](https://www.youtube.com/watch?v=0pgERydGyqo)
+*   [Front End Development with Bazel: Angular/TypeScript and Persistent Workers w/ Asana](https://www.youtube.com/watch?v=0pgERydGyqo)
 *   [Bazel strategies explained](https://jmmv.dev/2019/12/bazel-strategies.html)
 *   [Informative worker strategy discussion on the bazel-discuss mailing list](https://groups.google.com/forum/#!msg/bazel-discuss/oAEnuhYOPm8/ol7hf4KWJgAJ)
diff --git a/versions/7.6.1/remote/rules.mdx b/versions/7.6.1/remote/rules.mdx
index b42b1f9e..2ddc704d 100644
--- a/versions/7.6.1/remote/rules.mdx
+++ b/versions/7.6.1/remote/rules.mdx
@@ -54,8 +54,7 @@ variables that may not be set to equivalent values (or at all) in the remote
 execution environment.
 
 Toolchain rules currently exist for Bazel build and test rules for
-[Scala](https://github.com/bazelbuild/rules_scala/blob/master/scala/scala_toolch
-ain.bzl),
+[Scala](https://github.com/bazelbuild/rules_scala/blob/master/scala/scala_toolch ain.bzl),
 [Rust](https://github.com/bazelbuild/rules_rust/blob/main/rust/toolchain.bzl),
 and [Go](https://github.com/bazelbuild/rules_go/blob/master/go/toolchains.rst),
 and new toolchain rules are under way for other languages and tools such as
diff --git a/versions/7.6.1/remote/workspace.mdx b/versions/7.6.1/remote/workspace.mdx
index add704c1..2e6e5c4f 100644
--- a/versions/7.6.1/remote/workspace.mdx
+++ b/versions/7.6.1/remote/workspace.mdx
@@ -11,8 +11,7 @@ on the host machine. If your workspace rules access information about the
 host machine for use during execution, your build is likely to break due to
 incompatibilities between the environments.
 
-As part of [adapting Bazel rules for remote
-execution](/versions/7.6.1/remote/rules), you need to find such workspace rules
+As part of [adapting Bazel rules for remote execution](/versions/7.6.1/remote/rules), you need to find such workspace rules
 and fix them. This page describes how to find potentially problematic workspace
 rules using the workspace log.
 
diff --git a/versions/7.6.1/rules/challenges.mdx b/versions/7.6.1/rules/challenges.mdx
index 353a3052..45bfdc96 100644
--- a/versions/7.6.1/rules/challenges.mdx
+++ b/versions/7.6.1/rules/challenges.mdx
@@ -208,7 +208,7 @@ Bazel is heavily affected by both of these scenarios, so we introduced a set of
 custom collection classes that effectively compress the information in memory by
 avoiding the copy at each step. Almost all of these data structures have set
 semantics, so we called it
-[depset](/versions/7.6.1/rules/lib/depset)
+[depset](/versions/7.6.1/rules/lib/builtins/depset)
 (also known as `NestedSet` in the internal implementation). The majority of
 changes to reduce Bazel's memory consumption over the past several years were
 changes to use depsets instead of whatever was previously used.
diff --git a/versions/7.6.1/rules/deploying.mdx b/versions/7.6.1/rules/deploying.mdx
index b51c6c94..e6395e2e 100644
--- a/versions/7.6.1/rules/deploying.mdx
+++ b/versions/7.6.1/rules/deploying.mdx
@@ -91,8 +91,7 @@ At the top level, there should be a `README` that contains (at least) what
 users will need to copy-paste into their `WORKSPACE` file to use your rule.
 In general, this will be a `http_archive` pointing to your GitHub release and
 a macro call that downloads/configures any tools your rule needs. For example,
-for the [Go
-rules](https://github.com/bazelbuild/rules_go#setup), this
+for the [Go rules](https://github.com/bazelbuild/rules_go#setup), this
 looks like:
 
 ```
diff --git a/versions/7.6.1/rules/faq.mdx b/versions/7.6.1/rules/faq.mdx
index 8231dc42..3b20b4ae 100644
--- a/versions/7.6.1/rules/faq.mdx
+++ b/versions/7.6.1/rules/faq.mdx
@@ -17,7 +17,7 @@ Bazel only executes the actions needed to produce the *requested* output files.
 
 * If you want the file to be built automatically whenever your target is
   mentioned on the command line, add it to your rule's default outputs by
-  returning a [`DefaultInfo`](lib/globals#DefaultInfo) provider.
+  returning a [`DefaultInfo`](/versions/7.6.1/rules/lib/globals#DefaultInfo) provider.
 
 See the [Rules page](/versions/7.6.1/extending/rules#requesting-output-files) for more information.
 
@@ -35,24 +35,24 @@ correct path.
 
 For actions, you declare inputs by passing them to the `ctx.actions.*` function
 that creates the action. The proper path for the file can be obtained using
-[`File.path`](lib/File#path).
+[`File.path`](/versions/7.6.1/rules/lib/builtins/File#path).
 
 For binaries (the executable outputs run by a `bazel run` or `bazel test`
 command), you declare inputs by including them in the
 [runfiles](/versions/7.6.1/extending/rules#runfiles). Instead of using the `path` field, use
-[`File.short_path`](lib/File#short_path), which is file's path relative to
+[`File.short_path`](/versions/7.6.1/rules/lib/builtins/File#short_path), which is file's path relative to
 the runfiles directory in which the binary executes.
 
 ## How can I control which files are built by `bazel build //pkg:mytarget`?
 
-Use the [`DefaultInfo`](lib/globals#DefaultInfo) provider to
+Use the [`DefaultInfo`](/versions/7.6.1/rules/lib/globals#DefaultInfo) provider to
 [set the default outputs](/versions/7.6.1/extending/rules#requesting-output-files).
 
 ## How can I run a program or do file I/O as part of my build?
 
 A tool can be declared as a target, just like any other part of your build, and
 run during the execution phase to help build other targets. To create an action
-that runs a tool, use [`ctx.actions.run`](lib/actions#run) and pass in the
+that runs a tool, use [`ctx.actions.run`](/versions/7.6.1/rules/lib/builtins/actions#run) and pass in the
 tool as the `executable` parameter.
 
 During the loading and analysis phases, a tool *cannot* run, nor can you perform
diff --git a/versions/7.6.1/rules/language.mdx b/versions/7.6.1/rules/language.mdx
index 50be47e6..11e54859 100644
--- a/versions/7.6.1/rules/language.mdx
+++ b/versions/7.6.1/rules/language.mdx
@@ -34,19 +34,19 @@ Starlark's semantics can differ from Python, but behavioral differences are
 rare, except for cases where Starlark raises an error. The following Python
 types are supported:
 
-* [None](lib/globals#None)
-* [bool](lib/bool)
-* [dict](lib/dict)
-* [tuple](lib/tuple)
-* [function](lib/function)
-* [int](lib/int)
-* [list](lib/list)
-* [string](lib/string)
+* [None](/versions/7.6.1/rules/lib/globals#None)
+* [bool](/versions/7.6.1/rules/lib/core/bool)
+* [dict](/versions/7.6.1/rules/lib/core/dict)
+* [tuple](/versions/7.6.1/rules/lib/core/tuple)
+* [function](/versions/7.6.1/rules/lib/core/function)
+* [int](/versions/7.6.1/rules/lib/core/int)
+* [list](/versions/7.6.1/rules/lib/core/list)
+* [string](/versions/7.6.1/rules/lib/core/string)
 
 ## Mutability
 
 Starlark favors immutability. Two mutable data structures are available:
-[lists](lib/list) and [dicts](lib/dict). Changes to mutable
+[lists](/versions/7.6.1/rules/lib/core/list) and [dicts](/versions/7.6.1/rules/lib/core/dict). Changes to mutable
 data-structures, such as appending a value to a list or deleting an entry in a
 dictionary are valid only for objects created in the current context. After a
 context finishes, its values become immutable.
@@ -93,10 +93,8 @@ values returned by rules are immutable.
 `BUILD` files register targets via making calls to rules. `.bzl` files provide
 definitions for constants, rules, macros, and functions.
 
-[Native functions](/versions/7.6.1/reference/be/functions) and [native rules](
-/reference/be/overview#language-specific-native-rules) are global symbols in
-`BUILD` files. `bzl` files need to load them using the [`native` module](
-/rules/lib/toplevel/native).
+[Native functions](/versions/7.6.1/reference/be/functions) and [native rules](/versions/7.6.1/reference/be/overview#language-specific-native-rules) are global symbols in
+`BUILD` files. `bzl` files need to load them using the [`native` module](/versions/7.6.1/rules/lib/toplevel/native).
 
 There are two syntactic restrictions in `BUILD` files: 1) declaring functions is
 illegal, and 2) `*args` and `**kwargs` arguments are not allowed.
@@ -130,7 +128,7 @@ not defined across value types. In short: `5 < 'foo'` will throw an error and
   error: `{"a": 4, "b": 7, "a": 1}`.
 
 * Strings are represented with double-quotes (such as when you call
-  [repr](lib/globals#repr)).
+  [repr](/versions/7.6.1/rules/lib/globals#repr)).
 
 * Strings aren't iterable.
 
@@ -138,12 +136,12 @@ The following Python features are not supported:
 
 * implicit string concatenation (use explicit `+` operator).
 * Chained comparisons (such as `1 < x < 5`).
-* `class` (see [`struct`](lib/struct#struct) function).
+* `class` (see [`struct`](/versions/7.6.1/rules/lib/builtins/struct#struct) function).
 * `import` (see [`load`](/versions/7.6.1/extending/concepts#loading-an-extension) statement).
 * `while`, `yield`.
 * float and set types.
 * generators and generator expressions.
 * `is` (use `==` instead).
-* `try`, `raise`, `except`, `finally` (see [`fail`](lib/globals#fail) for fatal errors).
+* `try`, `raise`, `except`, `finally` (see [`fail`](/versions/7.6.1/rules/lib/globals#fail) for fatal errors).
 * `global`, `nonlocal`.
 * most builtin functions, most methods.
diff --git a/versions/7.6.1/rules/lib/builtins/Action.mdx b/versions/7.6.1/rules/lib/builtins/Action.mdx
index 4df968ad..4034a6b7 100644
--- a/versions/7.6.1/rules/lib/builtins/Action.mdx
+++ b/versions/7.6.1/rules/lib/builtins/Action.mdx
@@ -4,7 +4,7 @@ title: 'Action'
 
 An action created during rule analysis.
 
-This object is visible for the purpose of testing, and may be obtained from an `Actions` provider. It is normally not necessary to access `Action` objects or their fields within a rule's implementation function. You may instead want to see the [Rules page](https://bazel.build/versions/7.6.1/extending/rules#actions) for a general discussion of how to use actions when defining custom rules, or the [API reference](../builtins/actions) for creating actions.
+This object is visible for the purpose of testing, and may be obtained from an `Actions` provider. It is normally not necessary to access `Action` objects or their fields within a rule's implementation function. You may instead want to see the [Rules page](https://bazel.build/versions/7.6.1/extending/rules#actions) for a general discussion of how to use actions when defining custom rules, or the [API reference](/versions/7.6.1/rules/lib/builtins/actions) for creating actions.
 
 Some fields of this object are only applicable for certain kinds of actions. Fields that are inapplicable are set to `None`.
 
@@ -25,7 +25,7 @@ Some fields of this object are only applicable for certain kinds of actions. Fie
 sequence Action.args
 ```
 
-A list of frozen [Args](../builtins/Args) objects containing information about the action arguments. These objects contain accurate argument information, including arguments involving expanded action output directories. However, [Args](../builtins/Args) objects are not readable in the analysis phase. For a less accurate account of arguments which is available in the analysis phase, see [argv](#argv).
+A list of frozen [Args](/versions/7.6.1/rules/lib/builtins/Args) objects containing information about the action arguments. These objects contain accurate argument information, including arguments involving expanded action output directories. However, [Args](/versions/7.6.1/rules/lib/builtins/Args) objects are not readable in the analysis phase. For a less accurate account of arguments which is available in the analysis phase, see [argv](#argv).
 
 Note that some types of actions do not yet support exposure of this field. For such action types, this is `None`.
 May return `None`.
@@ -36,7 +36,7 @@ May return `None`.
 sequence Action.argv
 ```
 
-For actions created by [ctx.actions.run()](../builtins/actions#run) or [ctx.actions.run\_shell()](../builtins/actions#run_shell) an immutable list of the arguments for the command line to be executed. Note that for shell actions the first two arguments will be the shell path and `"-c"`.
+For actions created by [ctx.actions.run()](/versions/7.6.1/rules/lib/builtins/actions#run) or [ctx.actions.run\_shell()](/versions/7.6.1/rules/lib/builtins/actions#run_shell) an immutable list of the arguments for the command line to be executed. Note that for shell actions the first two arguments will be the shell path and `"-c"`.
 May return `None`.
 
 ## content
@@ -45,7 +45,7 @@ May return `None`.
 string Action.content
 ```
 
-For actions created by [ctx.actions.write()](../builtins/actions#write) or [ctx.actions.expand\_template()](../builtins/actions#expand_template), the contents of the file to be written, if those contents can be computed during the analysis phase. The value is `None` if the contents cannot be determined until the execution phase, such as when a directory in an [Args](../builtins/Args) object needs to be expanded.
+For actions created by [ctx.actions.write()](/versions/7.6.1/rules/lib/builtins/actions#write) or [ctx.actions.expand\_template()](/versions/7.6.1/rules/lib/builtins/actions#expand_template), the contents of the file to be written, if those contents can be computed during the analysis phase. The value is `None` if the contents cannot be determined until the execution phase, such as when a directory in an [Args](/versions/7.6.1/rules/lib/builtins/Args) object needs to be expanded.
 May return `None`.
 
 ## env
@@ -86,5 +86,5 @@ A set of the output files of this action.
 dict Action.substitutions
 ```
 
-For actions created by [ctx.actions.expand\_template()](../builtins/actions#expand_template), an immutable dict holding the substitution mapping.
+For actions created by [ctx.actions.expand\_template()](/versions/7.6.1/rules/lib/builtins/actions#expand_template), an immutable dict holding the substitution mapping.
 May return `None`.
\ No newline at end of file
diff --git a/versions/7.6.1/rules/lib/builtins/Args.mdx b/versions/7.6.1/rules/lib/builtins/Args.mdx
index 940dd877..11375496 100644
--- a/versions/7.6.1/rules/lib/builtins/Args.mdx
+++ b/versions/7.6.1/rules/lib/builtins/Args.mdx
@@ -4,15 +4,15 @@ title: 'Args'
 
 An object that encapsulates, in a memory-efficient way, the data needed to build part or all of a command line.
 
-It often happens that an action requires a large command line containing values accumulated from transitive dependencies. For example, a linker command line might list every object file needed by all of the libraries being linked. It is best practice to store such transitive data in [`depset`](../builtins/depset)s, so that they can be shared by multiple targets. However, if the rule author had to convert these depsets into lists of strings in order to construct an action command line, it would defeat this memory-sharing optimization.
+It often happens that an action requires a large command line containing values accumulated from transitive dependencies. For example, a linker command line might list every object file needed by all of the libraries being linked. It is best practice to store such transitive data in [`depset`](/versions/7.6.1/rules/lib/builtins/depset)s, so that they can be shared by multiple targets. However, if the rule author had to convert these depsets into lists of strings in order to construct an action command line, it would defeat this memory-sharing optimization.
 
 For this reason, the action-constructing functions accept `Args` objects in addition to strings. Each `Args` object represents a concatenation of strings and depsets, with optional transformations for manipulating the data. `Args` objects do not process the depsets they encapsulate until the execution phase, when it comes time to calculate the command line. This helps defer any expensive copying until after the analysis phase is complete. See the [Optimizing Performance](https://bazel.build/versions/7.6.1/rules/performance) page for more information.
 
-`Args` are constructed by calling [`ctx.actions.args()`](../builtins/actions#args). They can be passed as the `arguments` parameter of [`ctx.actions.run()`](../builtins/actions#run) or [`ctx.actions.run_shell()`](../builtins/actions#run_shell). Each mutation of an `Args` object appends values to the eventual command line.
+`Args` are constructed by calling [`ctx.actions.args()`](/versions/7.6.1/rules/lib/builtins/actions#args). They can be passed as the `arguments` parameter of [`ctx.actions.run()`](/versions/7.6.1/rules/lib/builtins/actions#run) or [`ctx.actions.run_shell()`](/versions/7.6.1/rules/lib/builtins/actions#run_shell). Each mutation of an `Args` object appends values to the eventual command line.
 
 The `map_each` feature allows you to customize how items are transformed into strings. If you do not provide a `map_each` function, the standard conversion is as follows:
 
-* Values that are already strings are left as-is.* [`File`](../builtins/File) objects are turned into their `File.path` values.* [`Label`](../builtins/Label) objects are turned into a string representation that resolves back to the same object when resolved in the context of the main repository. If possible, the string representation uses the apparent name of a repository in favor of the repository's canonical name, which makes this representation suited for use in BUILD files. While the exact form of the representation is not guaranteed, typical examples are `//foo:bar`, `@repo//foo:bar` and `@@canonical_name~//foo:bar.bzl`.* All other types are turned into strings in an *unspecified* manner. For this reason, you should avoid passing values that are not of string or `File` type to `add()`, and if you pass them to `add_all()` or `add_joined()` then you should provide a `map_each` function.
+* Values that are already strings are left as-is.* [`File`](/versions/7.6.1/rules/lib/builtins/File) objects are turned into their `File.path` values.* [`Label`](/versions/7.6.1/rules/lib/builtins/Label) objects are turned into a string representation that resolves back to the same object when resolved in the context of the main repository. If possible, the string representation uses the apparent name of a repository in favor of the repository's canonical name, which makes this representation suited for use in BUILD files. While the exact form of the representation is not guaranteed, typical examples are `//foo:bar`, `@repo//foo:bar` and `@@canonical_name~//foo:bar.bzl`.* All other types are turned into strings in an *unspecified* manner. For this reason, you should avoid passing values that are not of string or `File` type to `add()`, and if you pass them to `add_all()` or `add_joined()` then you should provide a `map_each` function.
 
 When using string formatting (`format`, `format_each`, and `format_joined` params of the `add*()` methods), the format template is interpreted in the same way as `%`-substitution on strings, except that the template must have exactly one substitution placeholder and it must be `%s`. Literal percents may be escaped as `%%`. Formatting is applied after the value is converted to a string as per the above.
 
@@ -64,7 +64,7 @@ Appends an argument to this command line.
 | --- | --- |
 | `arg_name_or_value` | required  If two positional parameters are passed this is interpreted as the arg name. The arg name is added before the value without any processing. If only one positional parameter is passed, it is interpreted as `value` (see below). |
 | `value` | default is `unbound`  The object to append. It will be converted to a string using the standard conversion mentioned above. Since there is no `map_each` parameter for this function, `value` should be either a string or a `File`. A list, tuple, depset, or directory `File` must be passed to [`add_all()` or [`add_joined()`](#add_joined) instead of this method.](#add_all) |
-| `format` | [string](../core/string); or `None`; default is `None`  A format string pattern, to be applied to the stringified version of `value`. |
+| `format` | [string](/versions/7.6.1/rules/lib/core/string); or `None`; default is `None`  A format string pattern, to be applied to the stringified version of `value`. |
 
 ## add\_all
 
@@ -86,14 +86,14 @@ Note that empty strings are valid arguments that are subject to all these proces
 | Parameter | Description |
 | --- | --- |
 | `arg_name_or_values` | required  If two positional parameters are passed this is interpreted as the arg name. The arg name is added before the `values` as a separate argument without any processing. This arg name will not be added if `omit_if_empty` is true (the default) and no other items are appended (as happens if `values` is empty or all of its items are filtered). If only one positional parameter is passed, it is interpreted as `values` (see below). |
-| `values` | [sequence](../core/list); or [depset](../builtins/depset); default is `unbound`  The list, tuple, or depset whose items will be appended. |
-| `map_each` | callable; or `None`; default is `None`  A function that converts each item to zero or more strings, which may be further processed before appending. If this param is not provided, the standard conversion is used. The function is passed either one or two positional arguments: the item to convert, followed by an optional [`DirectoryExpander`](../builtins/DirectoryExpander). The second argument will be passed only if the supplied function is user-defined (not built-in) and declares more than one parameter. The return value's type depends on how many arguments are to be produced for the item:  * In the common case when each item turns into one string, the function should return that string.* If the item is to be filtered out entirely, the function should return `None`.* If the item turns into multiple strings, the function returns a list of those strings.  Returning a single string or `None` has the same effect as returning a list of length 1 or length 0 respectively. However, it is more efficient and readable to avoid creating a list where it is not needed. Ordinarily, items that are directories are automatically expanded to their contents when `expand_directories=True` is set. However, this will not expand directories contained inside other values -- for instance, when the items are structs that have directories as fields. In this situation, the `DirectoryExpander` argument can be applied to manually obtain the files of a given directory. To avoid unintended retention of large analysis-phase data structures into the execution phase, the `map_each` function must be declared by a top-level `def` statement; it may not be a nested function closure by default. *Warning:* [`print()`](../globals/all#print) statements that are executed during the call to `map_each` will not produce any visible output. |
-| `format_each` | [string](../core/string); or `None`; default is `None`  An optional format string pattern, applied to each string returned by the `map_each` function. The format string must have exactly one '%s' placeholder. |
-| `before_each` | [string](../core/string); or `None`; default is `None`  An optional argument to append before each argument derived from `values` is appended. |
+| `values` | [sequence](/versions/7.6.1/rules/lib/core/list); or [depset](/versions/7.6.1/rules/lib/builtins/depset); default is `unbound`  The list, tuple, or depset whose items will be appended. |
+| `map_each` | callable; or `None`; default is `None`  A function that converts each item to zero or more strings, which may be further processed before appending. If this param is not provided, the standard conversion is used. The function is passed either one or two positional arguments: the item to convert, followed by an optional [`DirectoryExpander`](/versions/7.6.1/rules/lib/builtins/DirectoryExpander). The second argument will be passed only if the supplied function is user-defined (not built-in) and declares more than one parameter. The return value's type depends on how many arguments are to be produced for the item:  * In the common case when each item turns into one string, the function should return that string.* If the item is to be filtered out entirely, the function should return `None`.* If the item turns into multiple strings, the function returns a list of those strings.  Returning a single string or `None` has the same effect as returning a list of length 1 or length 0 respectively. However, it is more efficient and readable to avoid creating a list where it is not needed. Ordinarily, items that are directories are automatically expanded to their contents when `expand_directories=True` is set. However, this will not expand directories contained inside other values -- for instance, when the items are structs that have directories as fields. In this situation, the `DirectoryExpander` argument can be applied to manually obtain the files of a given directory. To avoid unintended retention of large analysis-phase data structures into the execution phase, the `map_each` function must be declared by a top-level `def` statement; it may not be a nested function closure by default. *Warning:* [`print()`](/versions/7.6.1/rules/lib/globals/all#print) statements that are executed during the call to `map_each` will not produce any visible output. |
+| `format_each` | [string](/versions/7.6.1/rules/lib/core/string); or `None`; default is `None`  An optional format string pattern, applied to each string returned by the `map_each` function. The format string must have exactly one '%s' placeholder. |
+| `before_each` | [string](/versions/7.6.1/rules/lib/core/string); or `None`; default is `None`  An optional argument to append before each argument derived from `values` is appended. |
 | `omit_if_empty` | default is `True`  If true, if there are no arguments derived from `values` to be appended, then all further processing is suppressed and the command line will be unchanged. If false, the arg name and `terminate_with`, if provided, will still be appended regardless of whether or not there are other arguments. |
 | `uniquify` | default is `False`  If true, duplicate arguments that are derived from `values` will be omitted. Only the first occurrence of each argument will remain. Usually this feature is not needed because depsets already omit duplicates, but it can be useful if `map_each` emits the same string for multiple items. |
 | `expand_directories` | default is `True`  If true, any directories in `values` will be expanded to a flat list of files. This happens before `map_each` is applied. |
-| `terminate_with` | [string](../core/string); or `None`; default is `None`  An optional argument to append after all other arguments. This argument will not be added if `omit_if_empty` is true (the default) and no other items are appended (as happens if `values` is empty or all of its items are filtered). |
+| `terminate_with` | [string](/versions/7.6.1/rules/lib/core/string); or `None`; default is `None`  An optional argument to append after all other arguments. This argument will not be added if `omit_if_empty` is true (the default) and no other items are appended (as happens if `values` is empty or all of its items are filtered). |
 | `allow_closure` | default is `False`  If true, allows the use of closures in function parameters like `map_each`. Usually this isn't necessary and it risks retaining large analysis-phase data structures into the execution phase. |
 
 ## add\_joined
@@ -113,11 +113,11 @@ If after filtering there are no strings to join into an argument, and if `omit_i
 | Parameter | Description |
 | --- | --- |
 | `arg_name_or_values` | required  If two positional parameters are passed this is interpreted as the arg name. The arg name is added before `values` without any processing. This arg will not be added if `omit_if_empty` is true (the default) and there are no strings derived from `values` to join together (which can happen if `values` is empty or all of its items are filtered). If only one positional parameter is passed, it is interpreted as `values` (see below). |
-| `values` | [sequence](../core/list); or [depset](../builtins/depset); default is `unbound`  The list, tuple, or depset whose items will be joined. |
-| `join_with` | required  A delimiter string used to join together the strings obtained from applying `map_each` and `format_each`, in the same manner as [`string.join()`](../core/string#join). |
+| `values` | [sequence](/versions/7.6.1/rules/lib/core/list); or [depset](/versions/7.6.1/rules/lib/builtins/depset); default is `unbound`  The list, tuple, or depset whose items will be joined. |
+| `join_with` | required  A delimiter string used to join together the strings obtained from applying `map_each` and `format_each`, in the same manner as [`string.join()`](/versions/7.6.1/rules/lib/core/string#join). |
 | `map_each` | callable; or `None`; default is `None`  Same as for [`add_all`](#add_all.map_each). |
-| `format_each` | [string](../core/string); or `None`; default is `None`  Same as for [`add_all`](#add_all.format_each). |
-| `format_joined` | [string](../core/string); or `None`; default is `None`  An optional format string pattern applied to the joined string. The format string must have exactly one '%s' placeholder. |
+| `format_each` | [string](/versions/7.6.1/rules/lib/core/string); or `None`; default is `None`  Same as for [`add_all`](#add_all.format_each). |
+| `format_joined` | [string](/versions/7.6.1/rules/lib/core/string); or `None`; default is `None`  An optional format string pattern applied to the joined string. The format string must have exactly one '%s' placeholder. |
 | `omit_if_empty` | default is `True`  If true, if there are no strings to join together (either because `values` is empty or all its items are filtered), then all further processing is suppressed and the command line will be unchanged. If false, then even if there are no strings to join together, two arguments will be appended: the arg name followed by an empty string (which is the logical join of zero strings). |
 | `uniquify` | default is `False`  Same as for [`add_all`](#add_all.uniquify). |
 | `expand_directories` | default is `True`  Same as for [`add_all`](#add_all.expand_directories). |
diff --git a/versions/7.6.1/rules/lib/builtins/Aspect.mdx b/versions/7.6.1/rules/lib/builtins/Aspect.mdx
index 4e0da533..ba461191 100644
--- a/versions/7.6.1/rules/lib/builtins/Aspect.mdx
+++ b/versions/7.6.1/rules/lib/builtins/Aspect.mdx
@@ -2,4 +2,4 @@
 title: 'Aspect'
 ---
 
-For more information about Aspects, please consult the [documentation of the aspect function](../globals/bzl#aspect) or the [introduction to Aspects](https://bazel.build/versions/7.6.1/rules/aspects).
\ No newline at end of file
+For more information about Aspects, please consult the [documentation of the aspect function](/versions/7.6.1/rules/lib/globals/bzl#aspect) or the [introduction to Aspects](https://bazel.build/versions/7.6.1/rules/aspects).
\ No newline at end of file
diff --git a/versions/7.6.1/rules/lib/builtins/Attribute.mdx b/versions/7.6.1/rules/lib/builtins/Attribute.mdx
index 18486c41..eb4889e2 100644
--- a/versions/7.6.1/rules/lib/builtins/Attribute.mdx
+++ b/versions/7.6.1/rules/lib/builtins/Attribute.mdx
@@ -2,4 +2,4 @@
 title: 'Attribute'
 ---
 
-Representation of a definition of an attribute. Use the [attr](../toplevel/attr) module to create an Attribute. They are only for use with a [rule](../globals/bzl#rule) or an [aspect](../globals/bzl#aspect).
\ No newline at end of file
+Representation of a definition of an attribute. Use the [attr](/versions/7.6.1/rules/lib/toplevel/attr) module to create an Attribute. They are only for use with a [rule](/versions/7.6.1/rules/lib/globals/bzl#rule) or an [aspect](/versions/7.6.1/rules/lib/globals/bzl#aspect).
\ No newline at end of file
diff --git a/versions/7.6.1/rules/lib/builtins/DirectoryExpander.mdx b/versions/7.6.1/rules/lib/builtins/DirectoryExpander.mdx
index 43068d41..185a8b8d 100644
--- a/versions/7.6.1/rules/lib/builtins/DirectoryExpander.mdx
+++ b/versions/7.6.1/rules/lib/builtins/DirectoryExpander.mdx
@@ -2,7 +2,7 @@
 title: 'DirectoryExpander'
 ---
 
-Expands directories created by [`ctx.actions.declare_directory`](../builtins/actions#declare_directory) during the execution phase. This is useful to expand directories in [`map_each`](../builtins/Args#add_all.map_each).
+Expands directories created by [`ctx.actions.declare_directory`](/versions/7.6.1/rules/lib/builtins/actions#declare_directory) during the execution phase. This is useful to expand directories in [`map_each`](/versions/7.6.1/rules/lib/builtins/Args#add_all.map_each).
 
 ## Members
 
diff --git a/versions/7.6.1/rules/lib/builtins/File.mdx b/versions/7.6.1/rules/lib/builtins/File.mdx
index b957a76d..6b16bbd8 100644
--- a/versions/7.6.1/rules/lib/builtins/File.mdx
+++ b/versions/7.6.1/rules/lib/builtins/File.mdx
@@ -4,7 +4,7 @@ title: 'File'
 
 This object is created during the analysis phase to represent a file or directory that will be read or written during the execution phase. It is not an open file handle, and cannot be used to directly read or write file contents. Rather, you use it to construct the action graph in a rule implementation function by passing it to action-creating functions. See the [Rules page](https://bazel.build/versions/7.6.1/extending/rules#files) for more information.
 
-When a `File` is passed to an [`Args`](../builtins/Args) object without using a `map_each` function, it is converted to a string by taking the value of its `path` field.
+When a `File` is passed to an [`Args`](/versions/7.6.1/rules/lib/builtins/Args) object without using a `map_each` function, it is converted to a string by taking the value of its `path` field.
 
 ## Members
 
@@ -74,7 +74,7 @@ May return `None`.
 string File.path
 ```
 
-The execution path of this file, relative to the workspace's execution directory. It consists of two parts, an optional first part called the *root* (see also the [root](../builtins/root) module), and the second part which is the `short_path`. The root may be empty, which it usually is for non-generated files. For generated files it usually contains a configuration-specific path fragment that encodes things like the target CPU architecture that was used while building said file. Use the `short_path` for the path under which the file is mapped if it's in the runfiles of a binary.
+The execution path of this file, relative to the workspace's execution directory. It consists of two parts, an optional first part called the *root* (see also the [root](/versions/7.6.1/rules/lib/builtins/root) module), and the second part which is the `short_path`. The root may be empty, which it usually is for non-generated files. For generated files it usually contains a configuration-specific path fragment that encodes things like the target CPU architecture that was used while building said file. Use the `short_path` for the path under which the file is mapped if it's in the runfiles of a binary.
 
 ## root
 
@@ -98,4 +98,4 @@ The path of this file relative to its root. This excludes the aforementioned *ro
 string File.tree_relative_path
 ```
 
-The path of this file relative to the root of the ancestor's tree, if the ancestor's [is\_directory](#is_directory) field is true. `tree_relative_path` is only available for expanded files of a directory in an action command, i.e. [Args.add\_all()](../builtins/Args#add_all). For other types of files, it is an error to access this field.
\ No newline at end of file
+The path of this file relative to the root of the ancestor's tree, if the ancestor's [is\_directory](#is_directory) field is true. `tree_relative_path` is only available for expanded files of a directory in an action command, i.e. [Args.add\_all()](/versions/7.6.1/rules/lib/builtins/Args#add_all). For other types of files, it is an error to access this field.
\ No newline at end of file
diff --git a/versions/7.6.1/rules/lib/builtins/Label.mdx b/versions/7.6.1/rules/lib/builtins/Label.mdx
index 80a41b63..62355117 100644
--- a/versions/7.6.1/rules/lib/builtins/Label.mdx
+++ b/versions/7.6.1/rules/lib/builtins/Label.mdx
@@ -33,7 +33,7 @@ For macros, a related function, `native.package_relative_label()`, converts the
 
 | Parameter | Description |
 | --- | --- |
-| `input` | [string](../core/string); or [Label](../builtins/Label); required  The input label string or Label object. If a Label object is passed, it's returned as is. |
+| `input` | [string](/versions/7.6.1/rules/lib/core/string); or [Label](/versions/7.6.1/rules/lib/builtins/Label); required  The input label string or Label object. If a Label object is passed, it's returned as is. |
 
 ## name
 
@@ -66,7 +66,7 @@ Label Label.relative(relName)
 ```
 
 **Experimental**. This API is experimental and may change at any time. Please do not depend on it. It may be enabled on an experimental basis by setting `--+incompatible_enable_deprecated_label_apis`
-**Deprecated.** This method behaves surprisingly when used with an argument containing an apparent repo name. Prefer [`Label.same_package_label()`](#local_target_label), [`native.package_relative_label()`](../toplevel/native#package_relative_label), or [`Label()`](#Label) instead.
+**Deprecated.** This method behaves surprisingly when used with an argument containing an apparent repo name. Prefer [`Label.same_package_label()`](#local_target_label), [`native.package_relative_label()`](/versions/7.6.1/rules/lib/toplevel/native#package_relative_label), or [`Label()`](#Label) instead.
 
 Resolves a label that is either absolute (starts with `//`) or relative to the current package. If this label is in a remote repository, the argument will be resolved relative to that repository. If the argument contains a repository name, the current label is ignored and the argument is returned as-is, except that the repository name is rewritten if it is in the current repository mapping. Reserved labels will also be returned as-is.
 For example:
diff --git a/versions/7.6.1/rules/lib/builtins/LateBoundDefault.mdx b/versions/7.6.1/rules/lib/builtins/LateBoundDefault.mdx
index edd0010c..2a444a40 100644
--- a/versions/7.6.1/rules/lib/builtins/LateBoundDefault.mdx
+++ b/versions/7.6.1/rules/lib/builtins/LateBoundDefault.mdx
@@ -4,4 +4,4 @@ title: 'LateBoundDefault'
 
 Represents a late-bound default attribute value of type 'Label'. The value of a LateBoundDefault is only resolvable in the context of a rule implementation function, and depends on the current build configuration. For example, a LateBoundDefault might represent the Label of the java toolchain in the current build configuration.
 
-See [configuration\_field](../globals/bzl#configuration_field) for example usage.
\ No newline at end of file
+See [configuration\_field](/versions/7.6.1/rules/lib/globals/bzl#configuration_field) for example usage.
\ No newline at end of file
diff --git a/versions/7.6.1/rules/lib/builtins/Provider.mdx b/versions/7.6.1/rules/lib/builtins/Provider.mdx
index 54b9cf36..37d837c8 100644
--- a/versions/7.6.1/rules/lib/builtins/Provider.mdx
+++ b/versions/7.6.1/rules/lib/builtins/Provider.mdx
@@ -14,7 +14,7 @@ This value has a dual purpose:
   ```
 
   Note: Some providers, defined internally, do not allow instance creation
-* It is a *key* to access a provider instance on a [Target](../builtins/Target)
+* It is a *key* to access a provider instance on a [Target](/versions/7.6.1/rules/lib/builtins/Target)
 
   ```
   DataInfo = provider()
@@ -22,4 +22,4 @@ This value has a dual purpose:
     ... ctx.attr.dep[DataInfo]
   ```
 
-Create a new `Provider` using the [provider](../globals/bzl#provider) function.
\ No newline at end of file
+Create a new `Provider` using the [provider](/versions/7.6.1/rules/lib/globals/bzl#provider) function.
\ No newline at end of file
diff --git a/versions/7.6.1/rules/lib/builtins/TemplateDict.mdx b/versions/7.6.1/rules/lib/builtins/TemplateDict.mdx
index 96a5f7a6..c954c893 100644
--- a/versions/7.6.1/rules/lib/builtins/TemplateDict.mdx
+++ b/versions/7.6.1/rules/lib/builtins/TemplateDict.mdx
@@ -37,9 +37,9 @@ Add depset of values
 | Parameter | Description |
 | --- | --- |
 | `key` | required  A String key |
-| `values` | [depset](../builtins/depset); required  The depset whose items will be joined. |
-| `join_with` | required  A delimiter string used to join together the strings obtained from applying `map_each`, in the same manner as [`string.join()`](../core/string#join). |
+| `values` | [depset](/versions/7.6.1/rules/lib/builtins/depset); required  The depset whose items will be joined. |
+| `join_with` | required  A delimiter string used to join together the strings obtained from applying `map_each`, in the same manner as [`string.join()`](/versions/7.6.1/rules/lib/core/string#join). |
 | `map_each` | callable; required  A Starlark function accepting a single argument and returning either a string, `None`, or a list of strings. This function is applied to each item of the depset specified in the `values` parameter |
 | `uniquify` | default is `False`  If true, duplicate strings derived from `values` will be omitted. Only the first occurrence of each string will remain. Usually this feature is not needed because depsets already omit duplicates, but it can be useful if `map_each` emits the same string for multiple items. |
-| `format_joined` | [string](../core/string); or `None`; default is `None`  An optional format string pattern applied to the joined string. The format string must have exactly one '%s' placeholder. |
+| `format_joined` | [string](/versions/7.6.1/rules/lib/core/string); or `None`; default is `None`  An optional format string pattern applied to the joined string. The format string must have exactly one '%s' placeholder. |
 | `allow_closure` | default is `False`  If true, allows the use of closures in function parameters like `map_each`. Usually this isn't necessary and it risks retaining large analysis-phase data structures into the execution phase. |
\ No newline at end of file
diff --git a/versions/7.6.1/rules/lib/builtins/actions.mdx b/versions/7.6.1/rules/lib/builtins/actions.mdx
index dcaf34b0..290c280e 100644
--- a/versions/7.6.1/rules/lib/builtins/actions.mdx
+++ b/versions/7.6.1/rules/lib/builtins/actions.mdx
@@ -2,7 +2,7 @@
 title: 'actions'
 ---
 
-Module providing functions to create actions. Access this module using [`ctx.actions`](../builtins/ctx#actions).
+Module providing functions to create actions. Access this module using [`ctx.actions`](/versions/7.6.1/rules/lib/builtins/ctx#actions).
 
 ## Members
 
@@ -32,14 +32,14 @@ Returns an Args object that can be used to build memory-efficient command lines.
 File actions.declare_directory(filename, *, sibling=None)
 ```
 
-Declares that the rule or aspect creates a directory with the given name, in the current package. You must create an action that generates the directory. The contents of the directory are not directly accessible from Starlark, but can be expanded in an action command with [`Args.add_all()`](../builtins/Args#add_all). Only regular files and directories can be in the expanded contents of a declare\_directory.
+Declares that the rule or aspect creates a directory with the given name, in the current package. You must create an action that generates the directory. The contents of the directory are not directly accessible from Starlark, but can be expanded in an action command with [`Args.add_all()`](/versions/7.6.1/rules/lib/builtins/Args#add_all). Only regular files and directories can be in the expanded contents of a declare\_directory.
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
 | `filename` | required  If no 'sibling' provided, path of the new directory, relative to the current package. Otherwise a base name for a file ('sibling' defines a directory). |
-| `sibling` | [File](../builtins/File); or `None`; default is `None`  A file that lives in the same directory as the newly declared directory. The file must be in the current package. |
+| `sibling` | [File](/versions/7.6.1/rules/lib/builtins/File); or `None`; default is `None`  A file that lives in the same directory as the newly declared directory. The file must be in the current package. |
 
 ## declare\_file
 
@@ -51,14 +51,14 @@ Declares that the rule or aspect creates a file with the given filename. If `sib
 
 Remember that in addition to declaring a file, you must separately create an action that emits the file. Creating that action will require passing the returned `File` object to the action's construction function.
 
-Note that [predeclared output files](https://bazel.build/versions/7.6.1/extending/rules#files) do not need to be (and cannot be) declared using this function. You can obtain their `File` objects from [`ctx.outputs`](../builtins/ctx#outputs) instead. [See example of use](https://github.com/bazelbuild/examples/tree/main/rules/computed_dependencies/hash.bzl).
+Note that [predeclared output files](https://bazel.build/versions/7.6.1/extending/rules#files) do not need to be (and cannot be) declared using this function. You can obtain their `File` objects from [`ctx.outputs`](/versions/7.6.1/rules/lib/builtins/ctx#outputs) instead. [See example of use](https://github.com/bazelbuild/examples/tree/main/rules/computed_dependencies/hash.bzl).
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
 | `filename` | required  If no 'sibling' provided, path of the new file, relative to the current package. Otherwise a base name for a file ('sibling' determines a directory). |
-| `sibling` | [File](../builtins/File); or `None`; default is `None`  A file that lives in the same directory as the newly created file. The file must be in the current package. |
+| `sibling` | [File](/versions/7.6.1/rules/lib/builtins/File); or `None`; default is `None`  A file that lives in the same directory as the newly created file. The file must be in the current package. |
 
 ## declare\_symlink
 
@@ -73,7 +73,7 @@ Declares that the rule or aspect creates a symlink with the given name in the cu
 | Parameter | Description |
 | --- | --- |
 | `filename` | required  If no 'sibling' provided, path of the new symlink, relative to the current package. Otherwise a base name for a file ('sibling' defines a directory). |
-| `sibling` | [File](../builtins/File); or `None`; default is `None`  A file that lives in the same directory as the newly declared symlink. |
+| `sibling` | [File](/versions/7.6.1/rules/lib/builtins/File); or `None`; default is `None`  A file that lives in the same directory as the newly declared symlink. |
 
 ## do\_nothing
 
@@ -88,7 +88,7 @@ Creates an empty action that neither executes a command nor produces any output,
 | Parameter | Description |
 | --- | --- |
 | `mnemonic` | required  A one-word description of the action, for example, CppCompile or GoLink. |
-| `inputs` | [sequence](../core/list) of [File](../builtins/File)s; or [depset](../builtins/depset); default is `[]`  List of the input files of the action. |
+| `inputs` | [sequence](/versions/7.6.1/rules/lib/core/list) of [File](/versions/7.6.1/rules/lib/builtins/File)s; or [depset](/versions/7.6.1/rules/lib/builtins/depset); default is `[]`  List of the input files of the action. |
 
 ## expand\_template
 
@@ -106,7 +106,7 @@ Creates a template expansion action. When the action is executed, it will genera
 | `output` | required  The output file, which is a UTF-8 encoded text file. |
 | `substitutions` | default is `{}`  Substitutions to make when expanding the template. |
 | `is_executable` | default is `False`  Whether the output file should be executable. |
-| `computed_substitutions` | [TemplateDict](../builtins/TemplateDict); default is `unbound`  Substitutions to make when expanding the template. |
+| `computed_substitutions` | [TemplateDict](/versions/7.6.1/rules/lib/builtins/TemplateDict); default is `unbound`  Substitutions to make when expanding the template. |
 
 ## run
 
@@ -120,22 +120,22 @@ Creates an action that runs an executable. [See example of use](https://github.c
 
 | Parameter | Description |
 | --- | --- |
-| `outputs` | [sequence](../core/list) of [File](../builtins/File)s; required  List of the output files of the action. |
-| `inputs` | [sequence](../core/list) of [File](../builtins/File)s; or [depset](../builtins/depset); default is `[]`  List or depset of the input files of the action. |
-| `unused_inputs_list` | [File](../builtins/File); or `None`; default is `None`  File containing list of inputs unused by the action. The content of this file (generally one of the outputs of the action) corresponds to the list of input files that were not used during the whole action execution. Any change in those files must not affect in any way the outputs of the action. |
-| `executable` | [File](../builtins/File); or [string](../core/string); or [FilesToRunProvider](../providers/FilesToRunProvider); required  The executable file to be called by the action. |
-| `tools` | [sequence](../core/list); or [depset](../builtins/depset); default is `unbound`  List or depset of any tools needed by the action. Tools are inputs with additional runfiles that are automatically made available to the action. When a list is provided, it can be a heterogenous collection of Files, FilesToRunProvider instances, or depsets of Files. Files which are directly in the list and come from ctx.executable will have their runfiles automatically added. When a depset is provided, it must contain only Files. In both cases, files within depsets are not cross-referenced with ctx.executable for runfiles. |
-| `arguments` | [sequence](../core/list); default is `[]`  Command line arguments of the action. Must be a list of strings or [`actions.args()`](#args) objects. |
-| `mnemonic` | [string](../core/string); or `None`; default is `None`  A one-word description of the action, for example, CppCompile or GoLink. |
-| `progress_message` | [string](../core/string); or `None`; default is `None`  Progress message to show to the user during the build, for example, "Compiling foo.cc to create foo.o". The message may contain `%{label}`, `%{input}`, or `%{output}` patterns, which are substituted with label string, first input, or output's path, respectively. Prefer to use patterns instead of static strings, because the former are more efficient. |
+| `outputs` | [sequence](/versions/7.6.1/rules/lib/core/list) of [File](/versions/7.6.1/rules/lib/builtins/File)s; required  List of the output files of the action. |
+| `inputs` | [sequence](/versions/7.6.1/rules/lib/core/list) of [File](/versions/7.6.1/rules/lib/builtins/File)s; or [depset](/versions/7.6.1/rules/lib/builtins/depset); default is `[]`  List or depset of the input files of the action. |
+| `unused_inputs_list` | [File](/versions/7.6.1/rules/lib/builtins/File); or `None`; default is `None`  File containing list of inputs unused by the action. The content of this file (generally one of the outputs of the action) corresponds to the list of input files that were not used during the whole action execution. Any change in those files must not affect in any way the outputs of the action. |
+| `executable` | [File](/versions/7.6.1/rules/lib/builtins/File); or [string](/versions/7.6.1/rules/lib/core/string); or [FilesToRunProvider](/versions/7.6.1/rules/lib/providers/FilesToRunProvider); required  The executable file to be called by the action. |
+| `tools` | [sequence](/versions/7.6.1/rules/lib/core/list); or [depset](/versions/7.6.1/rules/lib/builtins/depset); default is `unbound`  List or depset of any tools needed by the action. Tools are inputs with additional runfiles that are automatically made available to the action. When a list is provided, it can be a heterogenous collection of Files, FilesToRunProvider instances, or depsets of Files. Files which are directly in the list and come from ctx.executable will have their runfiles automatically added. When a depset is provided, it must contain only Files. In both cases, files within depsets are not cross-referenced with ctx.executable for runfiles. |
+| `arguments` | [sequence](/versions/7.6.1/rules/lib/core/list); default is `[]`  Command line arguments of the action. Must be a list of strings or [`actions.args()`](#args) objects. |
+| `mnemonic` | [string](/versions/7.6.1/rules/lib/core/string); or `None`; default is `None`  A one-word description of the action, for example, CppCompile or GoLink. |
+| `progress_message` | [string](/versions/7.6.1/rules/lib/core/string); or `None`; default is `None`  Progress message to show to the user during the build, for example, "Compiling foo.cc to create foo.o". The message may contain `%{label}`, `%{input}`, or `%{output}` patterns, which are substituted with label string, first input, or output's path, respectively. Prefer to use patterns instead of static strings, because the former are more efficient. |
 | `use_default_shell_env` | default is `False`  Whether the action should use the default shell environment, which consists of a few OS-dependent variables as well as variables set via [`--action_env`](/versions/7.6.1/reference/command-line-reference#flag--action_env). If both `use_default_shell_env` and `env` are set to `True`, values set in `env` will overwrite the default shell environment if [`--incompatible_merge_fixed_and_default_shell_env`](/versions/7.6.1/reference/command-line-reference#flag--incompatible_merge_fixed_and_default_shell_env) is enabled (default). If the flag is not enabled, `env` is ignored. |
-| `env` | [dict](../core/dict); or `None`; default is `None`  Sets the dictionary of environment variables. If both `use_default_shell_env` and `env` are set to `True`, values set in `env` will overwrite the default shell environment if [`--incompatible_merge_fixed_and_default_shell_env`](/versions/7.6.1/reference/command-line-reference#flag--incompatible_merge_fixed_and_default_shell_env) is enabled (default). If the flag is not enabled, `env` is ignored. |
-| `execution_requirements` | [dict](../core/dict); or `None`; default is `None`  Information for scheduling the action. See [tags](/versions/7.6.1/reference/be/common-definitions#common.tags) for useful keys. |
-| `input_manifests` | [sequence](../core/list); or `None`; default is `None`  (Experimental) sets the input runfiles metadata; they are typically generated by resolve\_command. |
-| `exec_group` | [string](../core/string); or `None`; default is `None`  Runs the action on the given exec group's execution platform. If none, uses the target's default execution platform. |
-| `shadowed_action` | [Action](../builtins/Action); default is `None`  Runs the action using the given shadowed action's inputs and environment added to the action's inputs list and environment. The action environment can overwrite any of the shadowed action's environment variables. If none, uses only the action's inputs and given environment. |
+| `env` | [dict](/versions/7.6.1/rules/lib/core/dict); or `None`; default is `None`  Sets the dictionary of environment variables. If both `use_default_shell_env` and `env` are set to `True`, values set in `env` will overwrite the default shell environment if [`--incompatible_merge_fixed_and_default_shell_env`](/versions/7.6.1/reference/command-line-reference#flag--incompatible_merge_fixed_and_default_shell_env) is enabled (default). If the flag is not enabled, `env` is ignored. |
+| `execution_requirements` | [dict](/versions/7.6.1/rules/lib/core/dict); or `None`; default is `None`  Information for scheduling the action. See [tags](/versions/7.6.1/reference/be/common-definitions#common.tags) for useful keys. |
+| `input_manifests` | [sequence](/versions/7.6.1/rules/lib/core/list); or `None`; default is `None`  (Experimental) sets the input runfiles metadata; they are typically generated by resolve\_command. |
+| `exec_group` | [string](/versions/7.6.1/rules/lib/core/string); or `None`; default is `None`  Runs the action on the given exec group's execution platform. If none, uses the target's default execution platform. |
+| `shadowed_action` | [Action](/versions/7.6.1/rules/lib/builtins/Action); default is `None`  Runs the action using the given shadowed action's inputs and environment added to the action's inputs list and environment. The action environment can overwrite any of the shadowed action's environment variables. If none, uses only the action's inputs and given environment. |
 | `resource_set` | callable; or `None`; default is `None`  A callback function that returns a resource set dictionary, used to estimate resource usage at execution time if this action is run locally. The function accepts two positional arguments: a string representing an OS name (e.g. "osx"), and an integer representing the number of inputs to the action. The returned dictionary may contain the following entries, each of which may be a float or an int:  * "cpu": number of CPUs; default 1* "memory": in MB; default 250* "local\_test": number of local tests; default 1   If this parameter is set to `None` , the default values are used. The callback must be top-level (lambda and nested functions aren't allowed). |
-| `toolchain` | [Label](../builtins/Label); or [string](../core/string); or `None`; default is `unbound`  Toolchain type of the executable or tools used in this action. The parameter must be set, so that, the action executes on the correct execution platform.  It's a no-op right now, but we recommend to set it when a toolchain is used, because it will be required in the future Bazel releases.  Note that the rule which creates this action needs to define this toolchain inside its 'rule()' function.  When `toolchain` and `exec\_group` parameters are both set, `exec\_group` will be used. An error is raised in case the `exec\_group` doesn't specify the same. |
+| `toolchain` | [Label](/versions/7.6.1/rules/lib/builtins/Label); or [string](/versions/7.6.1/rules/lib/core/string); or `None`; default is `unbound`  Toolchain type of the executable or tools used in this action. The parameter must be set, so that, the action executes on the correct execution platform.  It's a no-op right now, but we recommend to set it when a toolchain is used, because it will be required in the future Bazel releases.  Note that the rule which creates this action needs to define this toolchain inside its 'rule()' function.  When `toolchain` and `exec\_group` parameters are both set, `exec\_group` will be used. An error is raised in case the `exec\_group` doesn't specify the same. |
 
 ## run\_shell
 
@@ -149,21 +149,21 @@ Creates an action that runs a shell command. [See example of use](https://github
 
 | Parameter | Description |
 | --- | --- |
-| `outputs` | [sequence](../core/list) of [File](../builtins/File)s; required  List of the output files of the action. |
-| `inputs` | [sequence](../core/list) of [File](../builtins/File)s; or [depset](../builtins/depset); default is `[]`  List or depset of the input files of the action. |
-| `tools` | [sequence](../core/list) of [File](../builtins/File)s; or [depset](../builtins/depset); default is `unbound`  List or depset of any tools needed by the action. Tools are inputs with additional runfiles that are automatically made available to the action. The list can contain Files or FilesToRunProvider instances. |
-| `arguments` | [sequence](../core/list); default is `[]`  Command line arguments of the action. Must be a list of strings or [`actions.args()`](#args) objects. Bazel passes the elements in this attribute as arguments to the command.The command can access these arguments using shell variable substitutions such as `$1`, `$2`, etc. Note that since Args objects are flattened before indexing, if there is an Args object of unknown size then all subsequent strings will be at unpredictable indices. It may be useful to use `$@` (to retrieve all arguments) in conjunction with Args objects of indeterminate size. In the case where `command` is a list of strings, this parameter may not be used. |
-| `mnemonic` | [string](../core/string); or `None`; default is `None`  A one-word description of the action, for example, CppCompile or GoLink. |
-| `command` | [string](../core/string); or [sequence](../core/list) of [string](../core/string)s; required  Shell command to execute. This may either be a string (preferred) or a sequence of strings **(deprecated)**. If `command` is a string, then it is executed as if by `sh -c  "" ` -- that is, the elements in `arguments` are made available to the command as `$1`, `$2` (or `%1`, `%2` if using Windows batch), etc. If `arguments` contains any [`actions.args()`](#args) objects, their contents are appended one by one to the command line, so `$`*i* can refer to individual strings within an Args object. Note that if an Args object of unknown size is passed as part of `arguments`, then the strings will be at unknown indices; in this case the `$@` shell substitution (retrieve all arguments) may be useful. **(Deprecated)** If `command` is a sequence of strings, the first item is the executable to run and the remaining items are its arguments. If this form is used, the `arguments` parameter must not be supplied. *Note that this form is deprecated and will soon be removed. It is disabled with `--incompatible\_run\_shell\_command\_string`. Use this flag to verify your code is compatible.*  Bazel uses the same shell to execute the command as it does for genrules. |
-| `progress_message` | [string](../core/string); or `None`; default is `None`  Progress message to show to the user during the build, for example, "Compiling foo.cc to create foo.o". The message may contain `%{label}`, `%{input}`, or `%{output}` patterns, which are substituted with label string, first input, or output's path, respectively. Prefer to use patterns instead of static strings, because the former are more efficient. |
+| `outputs` | [sequence](/versions/7.6.1/rules/lib/core/list) of [File](/versions/7.6.1/rules/lib/builtins/File)s; required  List of the output files of the action. |
+| `inputs` | [sequence](/versions/7.6.1/rules/lib/core/list) of [File](/versions/7.6.1/rules/lib/builtins/File)s; or [depset](/versions/7.6.1/rules/lib/builtins/depset); default is `[]`  List or depset of the input files of the action. |
+| `tools` | [sequence](/versions/7.6.1/rules/lib/core/list) of [File](/versions/7.6.1/rules/lib/builtins/File)s; or [depset](/versions/7.6.1/rules/lib/builtins/depset); default is `unbound`  List or depset of any tools needed by the action. Tools are inputs with additional runfiles that are automatically made available to the action. The list can contain Files or FilesToRunProvider instances. |
+| `arguments` | [sequence](/versions/7.6.1/rules/lib/core/list); default is `[]`  Command line arguments of the action. Must be a list of strings or [`actions.args()`](#args) objects. Bazel passes the elements in this attribute as arguments to the command.The command can access these arguments using shell variable substitutions such as `$1`, `$2`, etc. Note that since Args objects are flattened before indexing, if there is an Args object of unknown size then all subsequent strings will be at unpredictable indices. It may be useful to use `$@` (to retrieve all arguments) in conjunction with Args objects of indeterminate size. In the case where `command` is a list of strings, this parameter may not be used. |
+| `mnemonic` | [string](/versions/7.6.1/rules/lib/core/string); or `None`; default is `None`  A one-word description of the action, for example, CppCompile or GoLink. |
+| `command` | [string](/versions/7.6.1/rules/lib/core/string); or [sequence](/versions/7.6.1/rules/lib/core/list) of [string](/versions/7.6.1/rules/lib/core/string)s; required  Shell command to execute. This may either be a string (preferred) or a sequence of strings **(deprecated)**. If `command` is a string, then it is executed as if by `sh -c  "" ` -- that is, the elements in `arguments` are made available to the command as `$1`, `$2` (or `%1`, `%2` if using Windows batch), etc. If `arguments` contains any [`actions.args()`](#args) objects, their contents are appended one by one to the command line, so `$`*i* can refer to individual strings within an Args object. Note that if an Args object of unknown size is passed as part of `arguments`, then the strings will be at unknown indices; in this case the `$@` shell substitution (retrieve all arguments) may be useful. **(Deprecated)** If `command` is a sequence of strings, the first item is the executable to run and the remaining items are its arguments. If this form is used, the `arguments` parameter must not be supplied. *Note that this form is deprecated and will soon be removed. It is disabled with `--incompatible\_run\_shell\_command\_string`. Use this flag to verify your code is compatible.*  Bazel uses the same shell to execute the command as it does for genrules. |
+| `progress_message` | [string](/versions/7.6.1/rules/lib/core/string); or `None`; default is `None`  Progress message to show to the user during the build, for example, "Compiling foo.cc to create foo.o". The message may contain `%{label}`, `%{input}`, or `%{output}` patterns, which are substituted with label string, first input, or output's path, respectively. Prefer to use patterns instead of static strings, because the former are more efficient. |
 | `use_default_shell_env` | default is `False`  Whether the action should use the default shell environment, which consists of a few OS-dependent variables as well as variables set via [`--action_env`](/versions/7.6.1/reference/command-line-reference#flag--action_env). If both `use_default_shell_env` and `env` are set to `True`, values set in `env` will overwrite the default shell environment if [`--incompatible_merge_fixed_and_default_shell_env`](/versions/7.6.1/reference/command-line-reference#flag--incompatible_merge_fixed_and_default_shell_env) is enabled (default). If the flag is not enabled, `env` is ignored. |
-| `env` | [dict](../core/dict); or `None`; default is `None`  Sets the dictionary of environment variables. If both `use_default_shell_env` and `env` are set to `True`, values set in `env` will overwrite the default shell environment if [`--incompatible_merge_fixed_and_default_shell_env`](/versions/7.6.1/reference/command-line-reference#flag--incompatible_merge_fixed_and_default_shell_env) is enabled (default). If the flag is not enabled, `env` is ignored. |
-| `execution_requirements` | [dict](../core/dict); or `None`; default is `None`  Information for scheduling the action. See [tags](/versions/7.6.1/reference/be/common-definitions#common.tags) for useful keys. |
-| `input_manifests` | [sequence](../core/list); or `None`; default is `None`  (Experimental) sets the input runfiles metadata; they are typically generated by resolve\_command. |
-| `exec_group` | [string](../core/string); or `None`; default is `None`  Runs the action on the given exec group's execution platform. If none, uses the target's default execution platform. |
-| `shadowed_action` | [Action](../builtins/Action); default is `None`  Runs the action using the given shadowed action's discovered inputs added to the action's inputs list. If none, uses only the action's inputs. |
+| `env` | [dict](/versions/7.6.1/rules/lib/core/dict); or `None`; default is `None`  Sets the dictionary of environment variables. If both `use_default_shell_env` and `env` are set to `True`, values set in `env` will overwrite the default shell environment if [`--incompatible_merge_fixed_and_default_shell_env`](/versions/7.6.1/reference/command-line-reference#flag--incompatible_merge_fixed_and_default_shell_env) is enabled (default). If the flag is not enabled, `env` is ignored. |
+| `execution_requirements` | [dict](/versions/7.6.1/rules/lib/core/dict); or `None`; default is `None`  Information for scheduling the action. See [tags](/versions/7.6.1/reference/be/common-definitions#common.tags) for useful keys. |
+| `input_manifests` | [sequence](/versions/7.6.1/rules/lib/core/list); or `None`; default is `None`  (Experimental) sets the input runfiles metadata; they are typically generated by resolve\_command. |
+| `exec_group` | [string](/versions/7.6.1/rules/lib/core/string); or `None`; default is `None`  Runs the action on the given exec group's execution platform. If none, uses the target's default execution platform. |
+| `shadowed_action` | [Action](/versions/7.6.1/rules/lib/builtins/Action); default is `None`  Runs the action using the given shadowed action's discovered inputs added to the action's inputs list. If none, uses only the action's inputs. |
 | `resource_set` | callable; or `None`; default is `None`  A callback function for estimating resource usage if run locally. See[`ctx.actions.run()`](#run.resource_set). |
-| `toolchain` | [Label](../builtins/Label); or [string](../core/string); or `None`; default is `unbound`  Toolchain type of the executable or tools used in this action. The parameter must be set, so that, the action executes on the correct execution platform.  It's a no-op right now, but we recommend to set it when a toolchain is used, because it will be required in the future Bazel releases.  Note that the rule which creates this action needs to define this toolchain inside its 'rule()' function.  When `toolchain` and `exec\_group` parameters are both set, `exec\_group` will be used. An error is raised in case the `exec\_group` doesn't specify the same. toolchain. |
+| `toolchain` | [Label](/versions/7.6.1/rules/lib/builtins/Label); or [string](/versions/7.6.1/rules/lib/core/string); or `None`; default is `unbound`  Toolchain type of the executable or tools used in this action. The parameter must be set, so that, the action executes on the correct execution platform.  It's a no-op right now, but we recommend to set it when a toolchain is used, because it will be required in the future Bazel releases.  Note that the rule which creates this action needs to define this toolchain inside its 'rule()' function.  When `toolchain` and `exec\_group` parameters are both set, `exec\_group` will be used. An error is raised in case the `exec\_group` doesn't specify the same. toolchain. |
 
 ## symlink
 
@@ -184,10 +184,10 @@ Otherwise, when you use `target_path`, declare `output` with [`declare_symlink()
 | Parameter | Description |
 | --- | --- |
 | `output` | required  The output of this action. |
-| `target_file` | [File](../builtins/File); or `None`; default is `None`  The File that the output symlink will point to. |
-| `target_path` | [string](../core/string); or `None`; default is `None`  The exact path that the output symlink will point to. No normalization or other processing is applied. |
+| `target_file` | [File](/versions/7.6.1/rules/lib/builtins/File); or `None`; default is `None`  The File that the output symlink will point to. |
+| `target_path` | [string](/versions/7.6.1/rules/lib/core/string); or `None`; default is `None`  The exact path that the output symlink will point to. No normalization or other processing is applied. |
 | `is_executable` | default is `False`  May only be used with `target_file`, not `target_path`. If true, when the action is executed, the `target_file`'s path is checked to confirm that it is executable, and an error is reported if it is not. Setting `is_executable` to False does not mean the target is not executable, just that no verification is done. This feature does not make sense for `target_path` because dangling symlinks might not exist at build time. |
-| `progress_message` | [string](../core/string); or `None`; default is `None`  Progress message to show to the user during the build. |
+| `progress_message` | [string](/versions/7.6.1/rules/lib/core/string); or `None`; default is `None`  Progress message to show to the user during the build. |
 
 ## template\_dict
 
@@ -210,5 +210,5 @@ Creates a file write action. When the action is executed, it will write the give
 | Parameter | Description |
 | --- | --- |
 | `output` | required  The output file. |
-| `content` | [string](../core/string); or [Args](../builtins/Args); required  the contents of the file. May be a either a string or an [`actions.args()`](#args) object. |
+| `content` | [string](/versions/7.6.1/rules/lib/core/string); or [Args](/versions/7.6.1/rules/lib/builtins/Args); required  the contents of the file. May be a either a string or an [`actions.args()`](#args) object. |
 | `is_executable` | default is `False`  Whether the output file should be executable. |
\ No newline at end of file
diff --git a/versions/7.6.1/rules/lib/builtins/apple_platform.mdx b/versions/7.6.1/rules/lib/builtins/apple_platform.mdx
index 02da3fb7..9fb760b6 100644
--- a/versions/7.6.1/rules/lib/builtins/apple_platform.mdx
+++ b/versions/7.6.1/rules/lib/builtins/apple_platform.mdx
@@ -4,7 +4,7 @@ title: 'apple\_platform'
 
 Corresponds to Xcode's notion of a platform as would be found in `Xcode.app/Contents/Developer/Platforms`. Each platform represents an Apple platform type (such as iOS or tvOS) combined with one or more related CPU architectures. For example, the iOS simulator platform supports `x86_64` and `i386` architectures.
 
-Specific instances of this type can be retrieved from the fields of the [apple\_common.platform](../toplevel/apple_common#platform) struct:
+Specific instances of this type can be retrieved from the fields of the [apple\_common.platform](/versions/7.6.1/rules/lib/toplevel/apple_common#platform) struct:
 
 * `apple_common.platform.ios_device`
 * `apple_common.platform.ios_simulator`
@@ -14,7 +14,7 @@ Specific instances of this type can be retrieved from the fields of the [apple\_
 * `apple_common.platform.watchos_device`
 * `apple_common.platform.watchos_simulator`
 
-More commonly, however, the [apple](../fragments/apple) configuration fragment has fields/methods that allow rules to determine the platform for which a target is being built.
+More commonly, however, the [apple](/versions/7.6.1/rules/lib/fragments/apple) configuration fragment has fields/methods that allow rules to determine the platform for which a target is being built.
 
 Example:
 
diff --git a/versions/7.6.1/rules/lib/builtins/apple_platform_type.mdx b/versions/7.6.1/rules/lib/builtins/apple_platform_type.mdx
index 94c12e7f..a275e394 100644
--- a/versions/7.6.1/rules/lib/builtins/apple_platform_type.mdx
+++ b/versions/7.6.1/rules/lib/builtins/apple_platform_type.mdx
@@ -4,7 +4,7 @@ title: 'apple\_platform\_type'
 
 Describes an Apple "platform type", such as iOS, macOS, tvOS, visionOS, or watchOS. This is distinct from a "platform", which is the platform type combined with one or more CPU architectures.
 
-Specific instances of this type can be retrieved by accessing the fields of the [apple\_common.platform\_type](../toplevel/apple_common#platform_type):
+Specific instances of this type can be retrieved by accessing the fields of the [apple\_common.platform\_type](/versions/7.6.1/rules/lib/toplevel/apple_common#platform_type):
 
 * `apple_common.platform_type.ios`
 * `apple_common.platform_type.macos`
@@ -13,4 +13,4 @@ Specific instances of this type can be retrieved by accessing the fields of the
 
 Likewise, the platform type of an existing platform value can be retrieved using its `platform_type` field.
 
-Platform types can be converted to a lowercase string (e.g., `ios` or `macos`) using the [str](../globals/all#str) function.
\ No newline at end of file
+Platform types can be converted to a lowercase string (e.g., `ios` or `macos`) using the [str](/versions/7.6.1/rules/lib/globals/all#str) function.
\ No newline at end of file
diff --git a/versions/7.6.1/rules/lib/builtins/configuration.mdx b/versions/7.6.1/rules/lib/builtins/configuration.mdx
index b0d4fa47..31b65e94 100644
--- a/versions/7.6.1/rules/lib/builtins/configuration.mdx
+++ b/versions/7.6.1/rules/lib/builtins/configuration.mdx
@@ -17,7 +17,7 @@ This object holds information about the environment in which the build is runnin
 bool configuration.coverage_enabled
 ```
 
-A boolean that tells whether code coverage is enabled for this run. Note that this does not compute whether a specific rule should be instrumented for code coverage data collection. For that, see the [`ctx.coverage_instrumented`](../builtins/ctx#coverage_instrumented) function.
+A boolean that tells whether code coverage is enabled for this run. Note that this does not compute whether a specific rule should be instrumented for code coverage data collection. For that, see the [`ctx.coverage_instrumented`](/versions/7.6.1/rules/lib/builtins/ctx#coverage_instrumented) function.
 
 ## default\_shell\_env
 
diff --git a/versions/7.6.1/rules/lib/builtins/ctx.mdx b/versions/7.6.1/rules/lib/builtins/ctx.mdx
index efff6dc9..9825a5a4 100644
--- a/versions/7.6.1/rules/lib/builtins/ctx.mdx
+++ b/versions/7.6.1/rules/lib/builtins/ctx.mdx
@@ -66,7 +66,7 @@ A list of ids for all aspects applied to the target. Only available in aspect im
 struct ctx.attr
 ```
 
-A struct to access the values of the [attributes](https://bazel.build/versions/7.6.1/extending/rules#attributes). The values are provided by the user (if not, a default value is used). The attributes of the struct and the types of their values correspond to the keys and values of the [`attrs` dict](../globals/bzl#rule.attrs) provided to the [`rule` function](../globals/bzl#rule). [See example of use](https://github.com/bazelbuild/examples/blob/main/rules/attributes/printer.bzl).
+A struct to access the values of the [attributes](https://bazel.build/versions/7.6.1/extending/rules#attributes). The values are provided by the user (if not, a default value is used). The attributes of the struct and the types of their values correspond to the keys and values of the [`attrs` dict](/versions/7.6.1/rules/lib/globals/bzl#rule.attrs) provided to the [`rule` function](/versions/7.6.1/rules/lib/globals/bzl#rule). [See example of use](https://github.com/bazelbuild/examples/blob/main/rules/attributes/printer.bzl).
 
 ## bin\_dir
 
@@ -98,7 +98,7 @@ Value of the build setting represented by the current target. If this isn't the
 configuration ctx.configuration
 ```
 
-The default configuration. See the [configuration](../builtins/configuration) type for more details.
+The default configuration. See the [configuration](/versions/7.6.1/rules/lib/builtins/configuration) type for more details.
 
 ## coverage\_instrumented
 
@@ -106,13 +106,13 @@ The default configuration. See the [configuration](../builtins/configuration) ty
 bool ctx.coverage_instrumented(target=None)
 ```
 
-Returns whether code coverage instrumentation should be generated when performing compilation actions for this rule or, if `target` is provided, the rule specified by that Target. (If a non-rule or a Starlark rule Target is provided, this returns False.) Checks if the sources of the current rule (if no Target is provided) or the sources of Target should be instrumented based on the --instrumentation\_filter and --instrument\_test\_targets config settings. This differs from `coverage_enabled` in the [configuration](../builtins/configuration), which notes whether coverage data collection is enabled for the entire run, but not whether a specific target should be instrumented.
+Returns whether code coverage instrumentation should be generated when performing compilation actions for this rule or, if `target` is provided, the rule specified by that Target. (If a non-rule or a Starlark rule Target is provided, this returns False.) Checks if the sources of the current rule (if no Target is provided) or the sources of Target should be instrumented based on the --instrumentation\_filter and --instrument\_test\_targets config settings. This differs from `coverage_enabled` in the [configuration](/versions/7.6.1/rules/lib/builtins/configuration), which notes whether coverage data collection is enabled for the entire run, but not whether a specific target should be instrumented.
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `target` | [Target](../builtins/Target); or `None`; default is `None`  A Target specifying a rule. If not provided, defaults to the current rule. |
+| `target` | [Target](/versions/7.6.1/rules/lib/builtins/Target); or `None`; default is `None`  A Target specifying a rule. If not provided, defaults to the current rule. |
 
 ## created\_actions
 
@@ -120,7 +120,7 @@ Returns whether code coverage instrumentation should be generated when performin
 StarlarkValue ctx.created_actions()
 ```
 
-For rules with [\_skylark\_testable](../globals/bzl#rule._skylark_testable) set to `True`, this returns an `Actions` provider representing all actions created so far for the current rule. For all other rules, returns `None`. Note that the provider is not updated when subsequent actions are created, so you will have to call this function again if you wish to inspect them.
+For rules with [\_skylark\_testable](/versions/7.6.1/rules/lib/globals/bzl#rule._skylark_testable) set to `True`, this returns an `Actions` provider representing all actions created so far for the current rule. For all other rules, returns `None`. Note that the provider is not updated when subsequent actions are created, so you will have to call this function again if you wish to inspect them.
 
 This is intended to help write tests for rule-implementation helper functions, which may take in a `ctx` object and create actions on it.
 
@@ -146,7 +146,7 @@ A collection of the execution groups available for this rule, indexed by their n
 struct ctx.executable
 ```
 
-A `struct` containing executable files defined in [label type attributes](../toplevel/attr#label) marked as [`executable=True`](../toplevel/attr#label.executable). The struct fields correspond to the attribute names. Each value in the struct is either a [`File`](../builtins/File) or `None`. If an optional attribute is not specified in the rule then the corresponding struct value is `None`. If a label type is not marked as `executable=True`, no corresponding struct field is generated. [See example of use](https://github.com/bazelbuild/examples/blob/main/rules/actions_run/execute.bzl).
+A `struct` containing executable files defined in [label type attributes](/versions/7.6.1/rules/lib/toplevel/attr#label) marked as [`executable=True`](/versions/7.6.1/rules/lib/toplevel/attr#label.executable). The struct fields correspond to the attribute names. Each value in the struct is either a [`File`](/versions/7.6.1/rules/lib/builtins/File) or `None`. If an optional attribute is not specified in the rule then the corresponding struct value is `None`. If a label type is not marked as `executable=True`, no corresponding struct field is generated. [See example of use](https://github.com/bazelbuild/examples/blob/main/rules/actions_run/execute.bzl).
 
 ## expand\_location
 
@@ -165,7 +165,7 @@ This function is useful to let the user specify a command in a BUILD file (like
 | Parameter | Description |
 | --- | --- |
 | `input` | required  String to be expanded. |
-| `targets` | [sequence](../core/list) of [Target](../builtins/Target)s; default is `[]`  List of targets for additional lookup information. |
+| `targets` | [sequence](/versions/7.6.1/rules/lib/core/list) of [Target](/versions/7.6.1/rules/lib/builtins/Target)s; default is `[]`  List of targets for additional lookup information. |
 
 May return `None`.
 
@@ -175,7 +175,7 @@ May return `None`.
 string ctx.expand_make_variables(attribute_name, command, additional_substitutions)
 ```
 
-**Deprecated.** Use [ctx.var](../builtins/ctx#var) to access the variables instead.
+**Deprecated.** Use [ctx.var](/versions/7.6.1/rules/lib/builtins/ctx#var) to access the variables instead.
 Returns a string after expanding all references to "Make variables". The variables must have the following format: `$(VAR_NAME)`. Also, `$$VAR_NAME` expands to `$VAR_NAME`. Examples:
 
 ```
@@ -207,7 +207,7 @@ The set of features that are explicitly enabled by the user for this rule. [See
 struct ctx.file
 ```
 
-A `struct` containing files defined in [label type attributes](../toplevel/attr#label) marked as [`allow_single_file`](../toplevel/attr#label.allow_single_file). The struct fields correspond to the attribute names. The struct value is always a [`File`](../builtins/File) or `None`. If an optional attribute is not specified in the rule then the corresponding struct value is `None`. If a label type is not marked as `allow_single_file`, no corresponding struct field is generated. It is a shortcut for:
+A `struct` containing files defined in [label type attributes](/versions/7.6.1/rules/lib/toplevel/attr#label) marked as [`allow_single_file`](/versions/7.6.1/rules/lib/toplevel/attr#label.allow_single_file). The struct fields correspond to the attribute names. The struct value is always a [`File`](/versions/7.6.1/rules/lib/builtins/File) or `None`. If an optional attribute is not specified in the rule then the corresponding struct value is `None`. If a label type is not marked as `allow_single_file`, no corresponding struct field is generated. It is a shortcut for:
 
 ```
 list(ctx.attr..files)[0]
@@ -221,7 +221,7 @@ In other words, use `file` to access the (singular) [default output](https://baz
 struct ctx.files
 ```
 
-A `struct` containing files defined in [label](../toplevel/attr#label) or [label list](../toplevel/attr#label_list) type attributes. The struct fields correspond to the attribute names. The struct values are `list` of [`File`](../builtins/File)s. It is a shortcut for:
+A `struct` containing files defined in [label](/versions/7.6.1/rules/lib/toplevel/attr#label) or [label list](/versions/7.6.1/rules/lib/toplevel/attr#label_list) type attributes. The struct fields correspond to the attribute names. The struct values are `list` of [`File`](/versions/7.6.1/rules/lib/builtins/File)s. It is a shortcut for:
 
 ```
 [f for t in ctx.attr. for f in t.files]
@@ -267,13 +267,13 @@ The label of the target currently being analyzed.
 structure ctx.outputs
 ```
 
-A pseudo-struct containing all the predeclared output files, represented by [`File`](../builtins/File) objects. See the [Rules page](https://bazel.build/versions/7.6.1/extending/rules#files) for more information and examples.
+A pseudo-struct containing all the predeclared output files, represented by [`File`](/versions/7.6.1/rules/lib/builtins/File) objects. See the [Rules page](https://bazel.build/versions/7.6.1/extending/rules#files) for more information and examples.
 
 This field does not exist on aspect contexts, since aspects do not have predeclared outputs.
 
 The fields of this object are defined as follows. It is an error if two outputs produce the same field name or have the same label.
 
-* If the rule declares an [`outputs`](../globals/bzl#rule.outputs) dict, then for every entry in the dict, there is a field whose name is the key and whose value is the corresponding `File`.* For every attribute of type [`attr.output`](../toplevel/attr#output) that the rule declares, there is a field whose name is the attribute's name. If the target specified a label for that attribute, then the field value is the corresponding `File`; otherwise the field value is `None`.* For every attribute of type [`attr.output_list`](../toplevel/attr#output_list) that the rule declares, there is a field whose name is the attribute's name. The field value is a list of `File` objects corresponding to the labels given for that attribute in the target, or an empty list if the attribute was not specified in the target.* **(Deprecated)** If the rule is marked [`executable`](../globals/bzl#rule.executable) or [`test`](../globals/bzl#rule.test), there is a field named `"executable"`, which is the default executable. It is recommended that instead of using this, you pass another file (either predeclared or not) to the `executable` arg of [`DefaultInfo`](../providers/DefaultInfo).
+* If the rule declares an [`outputs`](/versions/7.6.1/rules/lib/globals/bzl#rule.outputs) dict, then for every entry in the dict, there is a field whose name is the key and whose value is the corresponding `File`.* For every attribute of type [`attr.output`](/versions/7.6.1/rules/lib/toplevel/attr#output) that the rule declares, there is a field whose name is the attribute's name. If the target specified a label for that attribute, then the field value is the corresponding `File`; otherwise the field value is `None`.* For every attribute of type [`attr.output_list`](/versions/7.6.1/rules/lib/toplevel/attr#output_list) that the rule declares, there is a field whose name is the attribute's name. The field value is a list of `File` objects corresponding to the labels given for that attribute in the target, or an empty list if the attribute was not specified in the target.* **(Deprecated)** If the rule is marked [`executable`](/versions/7.6.1/rules/lib/globals/bzl#rule.executable) or [`test`](/versions/7.6.1/rules/lib/globals/bzl#rule.test), there is a field named `"executable"`, which is the default executable. It is recommended that instead of using this, you pass another file (either predeclared or not) to the `executable` arg of [`DefaultInfo`](/versions/7.6.1/rules/lib/providers/DefaultInfo).
 
 ## resolve\_command
 
@@ -289,10 +289,10 @@ tuple ctx.resolve_command(command='', attribute=None, expand_locations=False, ma
 | Parameter | Description |
 | --- | --- |
 | `command` | default is `''`  Command to resolve. |
-| `attribute` | [string](../core/string); or `None`; default is `None`  Name of the associated attribute for which to issue an error, or None. |
+| `attribute` | [string](/versions/7.6.1/rules/lib/core/string); or `None`; default is `None`  Name of the associated attribute for which to issue an error, or None. |
 | `expand_locations` | default is `False`  Shall we expand $(location) variables? See [ctx.expand\_location()](#expand_location) for more details. |
-| `make_variables` | [dict](../core/dict); or `None`; default is `None`  Make variables to expand, or None. |
-| `tools` | [sequence](../core/list) of [Target](../builtins/Target)s; default is `[]`  List of tools (list of targets). |
+| `make_variables` | [dict](/versions/7.6.1/rules/lib/core/dict); or `None`; default is `None`  Make variables to expand, or None. |
+| `tools` | [sequence](/versions/7.6.1/rules/lib/core/list) of [Target](/versions/7.6.1/rules/lib/builtins/Target)s; default is `[]`  List of tools (list of targets). |
 | `label_dict` | default is `{}`  Dictionary of resolved labels and the corresponding list of Files (a dict of Label : list of Files). |
 | `execution_requirements` | default is `{}`  Information for scheduling the action to resolve this command. See [tags](/versions/7.6.1/reference/be/common-definitions#common.tags) for useful keys. |
 
@@ -310,7 +310,7 @@ In contrast to `ctx.resolve_command`, this method does not require that Bash be
 
 | Parameter | Description |
 | --- | --- |
-| `tools` | [sequence](../core/list) of [Target](../builtins/Target)s; default is `[]`  List of tools (list of targets). |
+| `tools` | [sequence](/versions/7.6.1/rules/lib/core/list) of [Target](/versions/7.6.1/rules/lib/builtins/Target)s; default is `[]`  List of tools (list of targets). |
 
 ## rule
 
@@ -332,12 +332,12 @@ Creates a runfiles object.
 
 | Parameter | Description |
 | --- | --- |
-| `files` | [sequence](../core/list) of [File](../builtins/File)s; default is `[]`  The list of files to be added to the runfiles. |
-| `transitive_files` | [depset](../builtins/depset) of [File](../builtins/File)s; or `None`; default is `None`  The (transitive) set of files to be added to the runfiles. The depset should use the `default` order (which, as the name implies, is the default). |
+| `files` | [sequence](/versions/7.6.1/rules/lib/core/list) of [File](/versions/7.6.1/rules/lib/builtins/File)s; default is `[]`  The list of files to be added to the runfiles. |
+| `transitive_files` | [depset](/versions/7.6.1/rules/lib/builtins/depset) of [File](/versions/7.6.1/rules/lib/builtins/File)s; or `None`; default is `None`  The (transitive) set of files to be added to the runfiles. The depset should use the `default` order (which, as the name implies, is the default). |
 | `collect_data` | default is `False`  **Use of this parameter is not recommended. See [runfiles guide](https://bazel.build/versions/7.6.1/extending/rules#runfiles)**. Whether to collect the data runfiles from the dependencies in srcs, data and deps attributes. |
 | `collect_default` | default is `False`  **Use of this parameter is not recommended. See [runfiles guide](https://bazel.build/versions/7.6.1/extending/rules#runfiles)**. Whether to collect the default runfiles from the dependencies in srcs, data and deps attributes. |
-| `symlinks` | [dict](../core/dict); or [depset](../builtins/depset) of [SymlinkEntry](../builtins/SymlinkEntry)s; default is `{}`  Either a SymlinkEntry depset or the map of symlinks to be added to the runfiles. Symlinks are always added under the main workspace's runfiles directory (e.g. `/_main/`, **not** the directory corresponding to the current target's repository. See [Runfiles symlinks](https://bazel.build/versions/7.6.1/extending/rules#runfiles_symlinks) in the rules guide. |
-| `root_symlinks` | [dict](../core/dict); or [depset](../builtins/depset) of [SymlinkEntry](../builtins/SymlinkEntry)s; default is `{}`  Either a SymlinkEntry depset or a map of symlinks to be added to the runfiles. See [Runfiles symlinks](https://bazel.build/versions/7.6.1/extending/rules#runfiles_symlinks) in the rules guide. |
+| `symlinks` | [dict](/versions/7.6.1/rules/lib/core/dict); or [depset](/versions/7.6.1/rules/lib/builtins/depset) of [SymlinkEntry](/versions/7.6.1/rules/lib/builtins/SymlinkEntry)s; default is `{}`  Either a SymlinkEntry depset or the map of symlinks to be added to the runfiles. Symlinks are always added under the main workspace's runfiles directory (e.g. `/_main/`, **not** the directory corresponding to the current target's repository. See [Runfiles symlinks](https://bazel.build/versions/7.6.1/extending/rules#runfiles_symlinks) in the rules guide. |
+| `root_symlinks` | [dict](/versions/7.6.1/rules/lib/core/dict); or [depset](/versions/7.6.1/rules/lib/builtins/depset) of [SymlinkEntry](/versions/7.6.1/rules/lib/builtins/SymlinkEntry)s; default is `{}`  Either a SymlinkEntry depset or a map of symlinks to be added to the runfiles. See [Runfiles symlinks](https://bazel.build/versions/7.6.1/extending/rules#runfiles_symlinks) in the rules guide. |
 
 ## split\_attr
 
diff --git a/versions/7.6.1/rules/lib/builtins/depset.mdx b/versions/7.6.1/rules/lib/builtins/depset.mdx
index 7be6bd88..8be467e9 100644
--- a/versions/7.6.1/rules/lib/builtins/depset.mdx
+++ b/versions/7.6.1/rules/lib/builtins/depset.mdx
@@ -6,7 +6,7 @@ A specialized data structure that supports efficient merge operations and has a
 
 The elements of a depset must be hashable and all of the same type (as defined by the built-in type(x) function), but depsets are not simply hash sets and do not support fast membership tests. If you need a general set datatype, you can simulate one using a dictionary where all keys map to `True`.
 
-Depsets are immutable. They should be created using their [constructor function](../globals/bzl#depset) and merged or augmented with other depsets via the `transitive` argument.
+Depsets are immutable. They should be created using their [constructor function](/versions/7.6.1/rules/lib/globals/bzl#depset) and merged or augmented with other depsets via the `transitive` argument.
 
 The `order` parameter determines the kind of traversal that is done to convert the depset to an iterable. There are four possible values:
 
diff --git a/versions/7.6.1/rules/lib/builtins/fragments.mdx b/versions/7.6.1/rules/lib/builtins/fragments.mdx
index 6e0e1a51..173a8634 100644
--- a/versions/7.6.1/rules/lib/builtins/fragments.mdx
+++ b/versions/7.6.1/rules/lib/builtins/fragments.mdx
@@ -6,4 +6,4 @@ A collection of configuration fragments available in the current rule implementa
 
 Only configuration fragments which are declared in the rule definition may be accessed in this collection.
 
-See the [configuration fragment reference](../fragments) for a list of available fragments and the [rules documentation](https://bazel.build/versions/7.6.1/extending/rules#configuration_fragments) for how to use them.
\ No newline at end of file
+See the [configuration fragment reference](/versions/7.6.1/rules/lib/fragments) for a list of available fragments and the [rules documentation](https://bazel.build/versions/7.6.1/extending/rules#configuration_fragments) for how to use them.
\ No newline at end of file
diff --git a/versions/7.6.1/rules/lib/builtins/module_ctx.mdx b/versions/7.6.1/rules/lib/builtins/module_ctx.mdx
index 66cea6e3..f2560be8 100644
--- a/versions/7.6.1/rules/lib/builtins/module_ctx.mdx
+++ b/versions/7.6.1/rules/lib/builtins/module_ctx.mdx
@@ -35,8 +35,8 @@ Downloads a file to the output path for the provided url and returns a struct co
 
 | Parameter | Description |
 | --- | --- |
-| `url` | [string](../core/string); or Iterable of [string](../core/string)s; required  List of mirror URLs referencing the same file. |
-| `output` | [string](../core/string); or [Label](../builtins/Label); or [path](../builtins/path); default is `''`  path to the output file, relative to the repository directory. |
+| `url` | [string](/versions/7.6.1/rules/lib/core/string); or Iterable of [string](/versions/7.6.1/rules/lib/core/string)s; required  List of mirror URLs referencing the same file. |
+| `output` | [string](/versions/7.6.1/rules/lib/core/string); or [Label](/versions/7.6.1/rules/lib/builtins/Label); or [path](/versions/7.6.1/rules/lib/builtins/path); default is `''`  path to the output file, relative to the repository directory. |
 | `sha256` | default is `''`  The expected SHA-256 hash of the file downloaded. This must match the SHA-256 hash of the file downloaded. It is a security risk to omit the SHA-256 as remote files can change. At best omitting this field will make your build non-hermetic. It is optional to make development easier but should be set before shipping. If provided, the repository cache will first be checked for a file with the given hash; a download will only be attempted if the file was not found in the cache. After a successful download, the file will be added to the cache. |
 | `executable` | default is `False`  Set the executable flag on the created file, false by default. |
 | `allow_fail` | default is `False`  If set, indicate the error in the return value instead of raising an error for failed downloads. |
@@ -58,8 +58,8 @@ Downloads a file to the output path for the provided url, extracts it, and retur
 
 | Parameter | Description |
 | --- | --- |
-| `url` | [string](../core/string); or Iterable of [string](../core/string)s; required  List of mirror URLs referencing the same file. |
-| `output` | [string](../core/string); or [Label](../builtins/Label); or [path](../builtins/path); default is `''`  Path to the directory where the archive will be unpacked, relative to the repository directory. |
+| `url` | [string](/versions/7.6.1/rules/lib/core/string); or Iterable of [string](/versions/7.6.1/rules/lib/core/string)s; required  List of mirror URLs referencing the same file. |
+| `output` | [string](/versions/7.6.1/rules/lib/core/string); or [Label](/versions/7.6.1/rules/lib/builtins/Label); or [path](/versions/7.6.1/rules/lib/builtins/path); default is `''`  Path to the directory where the archive will be unpacked, relative to the repository directory. |
 | `sha256` | default is `''`  The expected SHA-256 hash of the file downloaded. This must match the SHA-256 hash of the file downloaded. It is a security risk to omit the SHA-256 as remote files can change. At best omitting this field will make your build non-hermetic. It is optional to make development easier but should be set before shipping. If provided, the repository cache will first be checked for a file with the given hash; a download will only be attempted if the file was not found in the cache. After a successful download, the file will be added to the cache. |
 | `type` | default is `''`  The archive type of the downloaded file. By default, the archive type is determined from the file extension of the URL. If the file has no extension, you can explicitly specify either "zip", "jar", "war", "aar", "nupkg", "tar", "tar.gz", "tgz", "tar.xz", "txz", ".tar.zst", ".tzst", "tar.bz2", ".tbz", ".ar", or ".deb" here. |
 | `stripPrefix` | default is `''`  A directory prefix to strip from the extracted files. Many archives contain a top-level directory that contains all files in the archive. Instead of needing to specify this prefix over and over in the `build_file`, this field can be used to strip it from extracted files. |
@@ -100,9 +100,9 @@ Constructs an opaque object that can be returned from the module extension's imp
 
 | Parameter | Description |
 | --- | --- |
-| `root_module_direct_deps` | [sequence](../core/list) of [string](../core/string)s; or [string](../core/string); or `None`; default is `None`  The names of the repositories that the extension considers to be direct dependencies of the root module. If the root module imports additional repositories or does not import all of these repositories via [`use_repo`](../globals/module#use_repo), Bazel will print a warning when the extension is evaluated, instructing the user to run `bazel mod tidy` to fix the `use_repo` calls automatically. If one of `root_module_direct_deps` and will print a warning and a fixup command when the extension is evaluated. If one of `root_module_direct_deps` and `root_module_direct_dev_deps` is specified, the other has to be as well. The lists specified by these two parameters must be disjoint. Exactly one of `root_module_direct_deps` and `root_module_direct_dev_deps` can be set to the special value `"all"`, which is treated as if a list with the names of all repositories generated by the extension was specified as the value. |
-| `root_module_direct_dev_deps` | [sequence](../core/list) of [string](../core/string)s; or [string](../core/string); or `None`; default is `None`  The names of the repositories that the extension considers to be direct dev dependencies of the root module. If the root module imports additional repositories or does not import all of these repositories via [`use_repo`](../globals/module#use_repo) on an extension proxy created with `use_extension(..., dev_dependency = True)`, Bazel will print a warning when the extension is evaluated, instructing the user to run `bazel mod tidy` to fix the `use_repo` calls automatically. If one of `root_module_direct_deps` and `root_module_direct_dev_deps` is specified, the other has to be as well. The lists specified by these two parameters must be disjoint. Exactly one of `root_module_direct_deps` and `root_module_direct_dev_deps` can be set to the special value `"all"`, which is treated as if a list with the names of all repositories generated by the extension was specified as the value. |
-| `reproducible` | [bool](../core/bool); default is `False`  States that this module extension ensures complete reproducibility, thereby it should not be stored in the lockfile. |
+| `root_module_direct_deps` | [sequence](/versions/7.6.1/rules/lib/core/list) of [string](/versions/7.6.1/rules/lib/core/string)s; or [string](/versions/7.6.1/rules/lib/core/string); or `None`; default is `None`  The names of the repositories that the extension considers to be direct dependencies of the root module. If the root module imports additional repositories or does not import all of these repositories via [`use_repo`](/versions/7.6.1/rules/lib/globals/module#use_repo), Bazel will print a warning when the extension is evaluated, instructing the user to run `bazel mod tidy` to fix the `use_repo` calls automatically. If one of `root_module_direct_deps` and will print a warning and a fixup command when the extension is evaluated. If one of `root_module_direct_deps` and `root_module_direct_dev_deps` is specified, the other has to be as well. The lists specified by these two parameters must be disjoint. Exactly one of `root_module_direct_deps` and `root_module_direct_dev_deps` can be set to the special value `"all"`, which is treated as if a list with the names of all repositories generated by the extension was specified as the value. |
+| `root_module_direct_dev_deps` | [sequence](/versions/7.6.1/rules/lib/core/list) of [string](/versions/7.6.1/rules/lib/core/string)s; or [string](/versions/7.6.1/rules/lib/core/string); or `None`; default is `None`  The names of the repositories that the extension considers to be direct dev dependencies of the root module. If the root module imports additional repositories or does not import all of these repositories via [`use_repo`](/versions/7.6.1/rules/lib/globals/module#use_repo) on an extension proxy created with `use_extension(..., dev_dependency = True)`, Bazel will print a warning when the extension is evaluated, instructing the user to run `bazel mod tidy` to fix the `use_repo` calls automatically. If one of `root_module_direct_deps` and `root_module_direct_dev_deps` is specified, the other has to be as well. The lists specified by these two parameters must be disjoint. Exactly one of `root_module_direct_deps` and `root_module_direct_dev_deps` can be set to the special value `"all"`, which is treated as if a list with the names of all repositories generated by the extension was specified as the value. |
+| `reproducible` | [bool](/versions/7.6.1/rules/lib/core/bool); default is `False`  States that this module extension ensures complete reproducibility, thereby it should not be stored in the lockfile. |
 
 ## extract
 
@@ -116,8 +116,8 @@ Extract an archive to the repository directory.
 
 | Parameter | Description |
 | --- | --- |
-| `archive` | [string](../core/string); or [Label](../builtins/Label); or [path](../builtins/path); required  path to the archive that will be unpacked, relative to the repository directory. |
-| `output` | [string](../core/string); or [Label](../builtins/Label); or [path](../builtins/path); default is `''`  path to the directory where the archive will be unpacked, relative to the repository directory. |
+| `archive` | [string](/versions/7.6.1/rules/lib/core/string); or [Label](/versions/7.6.1/rules/lib/builtins/Label); or [path](/versions/7.6.1/rules/lib/builtins/path); required  path to the archive that will be unpacked, relative to the repository directory. |
+| `output` | [string](/versions/7.6.1/rules/lib/core/string); or [Label](/versions/7.6.1/rules/lib/builtins/Label); or [path](/versions/7.6.1/rules/lib/builtins/path); default is `''`  path to the directory where the archive will be unpacked, relative to the repository directory. |
 | `stripPrefix` | default is `''`  a directory prefix to strip from the extracted files. Many archives contain a top-level directory that contains all files in the archive. Instead of needing to specify this prefix over and over in the `build_file`, this field can be used to strip it from extracted files. |
 | `rename_files` | default is `{}`  An optional dict specifying files to rename during the extraction. Archive entries with names exactly matching a key will be renamed to the value, prior to any directory prefix adjustment. This can be used to extract archives that contain non-Unicode filenames, or which have files that would extract to the same path on case-insensitive filesystems. |
 | `watch_archive` | default is `'auto'`  whether to [watch](#watch) the archive file. Can be the string 'yes', 'no', or 'auto'. Passing 'yes' is equivalent to immediately invoking the [`watch()`](#watch) method; passing 'no' does not attempt to watch the file; passing 'auto' will only attempt to watch the file when it is legal to do so (see `watch()` docs for more information. |
@@ -134,7 +134,7 @@ Generates a file in the repository directory with the provided content.
 
 | Parameter | Description |
 | --- | --- |
-| `path` | [string](../core/string); or [Label](../builtins/Label); or [path](../builtins/path); required  Path of the file to create, relative to the repository directory. |
+| `path` | [string](/versions/7.6.1/rules/lib/core/string); or [Label](/versions/7.6.1/rules/lib/builtins/Label); or [path](/versions/7.6.1/rules/lib/builtins/path); required  Path of the file to create, relative to the repository directory. |
 | `content` | default is `''`  The content of the file to create, empty by default. |
 | `executable` | default is `True`  Set the executable flag on the created file, true by default. |
 | `legacy_utf8` | default is `True`  Encode file content to UTF-8, true by default. Future versions will change the default and remove this parameter. |
@@ -153,8 +153,8 @@ When building incrementally, any change to the value of the variable named by `n
 
 | Parameter | Description |
 | --- | --- |
-| `name` | [string](../core/string); required  Name of desired environment variable. |
-| `default` | [string](../core/string); or `None`; default is `None`  Default value to return if `name` is not found. |
+| `name` | [string](/versions/7.6.1/rules/lib/core/string); required  Name of desired environment variable. |
+| `default` | [string](/versions/7.6.1/rules/lib/core/string); or `None`; default is `None`  Default value to return if `name` is not found. |
 
 May return `None`.
 
@@ -164,13 +164,13 @@ May return `None`.
 bool module_ctx.is_dev_dependency(tag)
 ```
 
-Returns whether the given tag was specified on the result of a [use\_extension](../globals/module#use_extension) call with `devDependency = True`.
+Returns whether the given tag was specified on the result of a [use\_extension](/versions/7.6.1/rules/lib/globals/module#use_extension) call with `devDependency = True`.
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `tag` | bazel\_module\_tag; required  A tag obtained from [bazel\_module.tags](../builtins/bazel_module#tags). |
+| `tag` | bazel\_module\_tag; required  A tag obtained from [bazel\_module.tags](/versions/7.6.1/rules/lib/builtins/bazel_module#tags). |
 
 ## modules
 
@@ -178,7 +178,7 @@ Returns whether the given tag was specified on the result of a [use\_extension](
 list module_ctx.modules
 ```
 
-A list of all the Bazel modules in the external dependency graph that use this module extension, each of which is a [bazel\_module](../builtins/bazel_module) object that exposes all the tags it specified for this extension. The iteration order of this dictionary is guaranteed to be the same as breadth-first search starting from the root module.
+A list of all the Bazel modules in the external dependency graph that use this module extension, each of which is a [bazel\_module](/versions/7.6.1/rules/lib/builtins/bazel_module) object that exposes all the tags it specified for this extension. The iteration order of this dictionary is guaranteed to be the same as breadth-first search starting from the root module.
 
 ## os
 
@@ -200,7 +200,7 @@ Returns a path from a string, label or path. If the path is relative, it will re
 
 | Parameter | Description |
 | --- | --- |
-| `path` | [string](../core/string); or [Label](../builtins/Label); or [path](../builtins/path); required  `string`, `Label` or `path` from which to create a path from. |
+| `path` | [string](/versions/7.6.1/rules/lib/core/string); or [Label](/versions/7.6.1/rules/lib/builtins/Label); or [path](/versions/7.6.1/rules/lib/builtins/path); required  `string`, `Label` or `path` from which to create a path from. |
 
 ## read
 
@@ -214,7 +214,7 @@ Reads the content of a file on the filesystem.
 
 | Parameter | Description |
 | --- | --- |
-| `path` | [string](../core/string); or [Label](../builtins/Label); or [path](../builtins/path); required  Path of the file to read from. |
+| `path` | [string](/versions/7.6.1/rules/lib/core/string); or [Label](/versions/7.6.1/rules/lib/builtins/Label); or [path](/versions/7.6.1/rules/lib/builtins/path); required  Path of the file to read from. |
 | `watch` | default is `'auto'`  Whether to [watch](#watch) the file. Can be the string 'yes', 'no', or 'auto'. Passing 'yes' is equivalent to immediately invoking the [`watch()`](#watch) method; passing 'no' does not attempt to watch the file; passing 'auto' will only attempt to watch the file when it is legal to do so (see `watch()` docs for more information. |
 
 ## report\_progress
@@ -229,7 +229,7 @@ Updates the progress status for the fetching of this repository or module extens
 
 | Parameter | Description |
 | --- | --- |
-| `status` | [string](../core/string); default is `''`  `string` describing the current status of the fetch progress. |
+| `status` | [string](/versions/7.6.1/rules/lib/core/string); default is `''`  `string` describing the current status of the fetch progress. |
 
 ## root\_module\_has\_non\_dev\_dependency
 
@@ -247,7 +247,7 @@ None module_ctx.watch(path)
 
 Tells Bazel to watch for changes to the given path, whether or not it exists, or whether it's a file or a directory. Any changes to the file or directory will invalidate this repository or module extension, and cause it to be refetched or re-evaluated next time.
 
-"Changes" include changes to the contents of the file (if the path is a file); if the path was a file but is now a directory, or vice versa; and if the path starts or stops existing. Notably, this does *not* include changes to any files under the directory if the path is a directory. For that, use [`path.readdir()`](path#readdir) instead.
+"Changes" include changes to the contents of the file (if the path is a file); if the path was a file but is now a directory, or vice versa; and if the path starts or stops existing. Notably, this does *not* include changes to any files under the directory if the path is a directory. For that, use [`path.readdir()`](/versions/7.6.1/rules/lib/builtins/path#readdir) instead.
 
 Note that attempting to watch paths inside the repo currently being fetched, or inside the working directory of the current module extension, will result in an error. A module extension attempting to watch a path outside the current Bazel workspace will also result in an error.
 
@@ -255,7 +255,7 @@ Note that attempting to watch paths inside the repo currently being fetched, or
 
 | Parameter | Description |
 | --- | --- |
-| `path` | [string](../core/string); or [Label](../builtins/Label); or [path](../builtins/path); required  Path of the file to watch. |
+| `path` | [string](/versions/7.6.1/rules/lib/core/string); or [Label](/versions/7.6.1/rules/lib/builtins/Label); or [path](/versions/7.6.1/rules/lib/builtins/path); required  Path of the file to watch. |
 
 ## which
 
diff --git a/versions/7.6.1/rules/lib/builtins/path.mdx b/versions/7.6.1/rules/lib/builtins/path.mdx
index 8b5ce98a..7eea2599 100644
--- a/versions/7.6.1/rules/lib/builtins/path.mdx
+++ b/versions/7.6.1/rules/lib/builtins/path.mdx
@@ -77,7 +77,7 @@ Returns the list of entries in the directory denoted by this path. Each entry is
 
 | Parameter | Description |
 | --- | --- |
-| `watch` | default is `'auto'`  whether Bazel should watch the list of entries in this directory and refetch the repository or re-evaluate the module extension next time when any changes are detected. Changes to detect include entry creation, deletion, and renaming. Note that this doesn't watch the *contents* of any entries in the directory. Can be the string 'yes', 'no', or 'auto'. If set to 'auto', Bazel will only watch this directory when it is legal to do so (see [`repository_ctx.watch()`](repository_ctx#watch) docs for more information). |
+| `watch` | default is `'auto'`  whether Bazel should watch the list of entries in this directory and refetch the repository or re-evaluate the module extension next time when any changes are detected. Changes to detect include entry creation, deletion, and renaming. Note that this doesn't watch the *contents* of any entries in the directory. Can be the string 'yes', 'no', or 'auto'. If set to 'auto', Bazel will only watch this directory when it is legal to do so (see [`repository_ctx.watch()`](/versions/7.6.1/rules/lib/builtins/repository_ctx#watch) docs for more information). |
 
 ## realpath
 
diff --git a/versions/7.6.1/rules/lib/builtins/repository_ctx.mdx b/versions/7.6.1/rules/lib/builtins/repository_ctx.mdx
index ff190cdb..209f9339 100644
--- a/versions/7.6.1/rules/lib/builtins/repository_ctx.mdx
+++ b/versions/7.6.1/rules/lib/builtins/repository_ctx.mdx
@@ -47,7 +47,7 @@ Deletes a file or a directory. Returns a bool, indicating whether the file or di
 
 | Parameter | Description |
 | --- | --- |
-| `path` | [string](../core/string); or [path](../builtins/path); required  Path of the file to delete, relative to the repository directory, or absolute. Can be a path or a string. |
+| `path` | [string](/versions/7.6.1/rules/lib/core/string); or [path](/versions/7.6.1/rules/lib/builtins/path); required  Path of the file to delete, relative to the repository directory, or absolute. Can be a path or a string. |
 
 ## download
 
@@ -61,8 +61,8 @@ Downloads a file to the output path for the provided url and returns a struct co
 
 | Parameter | Description |
 | --- | --- |
-| `url` | [string](../core/string); or Iterable of [string](../core/string)s; required  List of mirror URLs referencing the same file. |
-| `output` | [string](../core/string); or [Label](../builtins/Label); or [path](../builtins/path); default is `''`  path to the output file, relative to the repository directory. |
+| `url` | [string](/versions/7.6.1/rules/lib/core/string); or Iterable of [string](/versions/7.6.1/rules/lib/core/string)s; required  List of mirror URLs referencing the same file. |
+| `output` | [string](/versions/7.6.1/rules/lib/core/string); or [Label](/versions/7.6.1/rules/lib/builtins/Label); or [path](/versions/7.6.1/rules/lib/builtins/path); default is `''`  path to the output file, relative to the repository directory. |
 | `sha256` | default is `''`  The expected SHA-256 hash of the file downloaded. This must match the SHA-256 hash of the file downloaded. It is a security risk to omit the SHA-256 as remote files can change. At best omitting this field will make your build non-hermetic. It is optional to make development easier but should be set before shipping. If provided, the repository cache will first be checked for a file with the given hash; a download will only be attempted if the file was not found in the cache. After a successful download, the file will be added to the cache. |
 | `executable` | default is `False`  Set the executable flag on the created file, false by default. |
 | `allow_fail` | default is `False`  If set, indicate the error in the return value instead of raising an error for failed downloads. |
@@ -84,8 +84,8 @@ Downloads a file to the output path for the provided url, extracts it, and retur
 
 | Parameter | Description |
 | --- | --- |
-| `url` | [string](../core/string); or Iterable of [string](../core/string)s; required  List of mirror URLs referencing the same file. |
-| `output` | [string](../core/string); or [Label](../builtins/Label); or [path](../builtins/path); default is `''`  Path to the directory where the archive will be unpacked, relative to the repository directory. |
+| `url` | [string](/versions/7.6.1/rules/lib/core/string); or Iterable of [string](/versions/7.6.1/rules/lib/core/string)s; required  List of mirror URLs referencing the same file. |
+| `output` | [string](/versions/7.6.1/rules/lib/core/string); or [Label](/versions/7.6.1/rules/lib/builtins/Label); or [path](/versions/7.6.1/rules/lib/builtins/path); default is `''`  Path to the directory where the archive will be unpacked, relative to the repository directory. |
 | `sha256` | default is `''`  The expected SHA-256 hash of the file downloaded. This must match the SHA-256 hash of the file downloaded. It is a security risk to omit the SHA-256 as remote files can change. At best omitting this field will make your build non-hermetic. It is optional to make development easier but should be set before shipping. If provided, the repository cache will first be checked for a file with the given hash; a download will only be attempted if the file was not found in the cache. After a successful download, the file will be added to the cache. |
 | `type` | default is `''`  The archive type of the downloaded file. By default, the archive type is determined from the file extension of the URL. If the file has no extension, you can explicitly specify either "zip", "jar", "war", "aar", "nupkg", "tar", "tar.gz", "tgz", "tar.xz", "txz", ".tar.zst", ".tzst", "tar.bz2", ".tbz", ".ar", or ".deb" here. |
 | `stripPrefix` | default is `''`  A directory prefix to strip from the extracted files. Many archives contain a top-level directory that contains all files in the archive. Instead of needing to specify this prefix over and over in the `build_file`, this field can be used to strip it from extracted files. |
@@ -126,8 +126,8 @@ Extract an archive to the repository directory.
 
 | Parameter | Description |
 | --- | --- |
-| `archive` | [string](../core/string); or [Label](../builtins/Label); or [path](../builtins/path); required  path to the archive that will be unpacked, relative to the repository directory. |
-| `output` | [string](../core/string); or [Label](../builtins/Label); or [path](../builtins/path); default is `''`  path to the directory where the archive will be unpacked, relative to the repository directory. |
+| `archive` | [string](/versions/7.6.1/rules/lib/core/string); or [Label](/versions/7.6.1/rules/lib/builtins/Label); or [path](/versions/7.6.1/rules/lib/builtins/path); required  path to the archive that will be unpacked, relative to the repository directory. |
+| `output` | [string](/versions/7.6.1/rules/lib/core/string); or [Label](/versions/7.6.1/rules/lib/builtins/Label); or [path](/versions/7.6.1/rules/lib/builtins/path); default is `''`  path to the directory where the archive will be unpacked, relative to the repository directory. |
 | `stripPrefix` | default is `''`  a directory prefix to strip from the extracted files. Many archives contain a top-level directory that contains all files in the archive. Instead of needing to specify this prefix over and over in the `build_file`, this field can be used to strip it from extracted files. |
 | `rename_files` | default is `{}`  An optional dict specifying files to rename during the extraction. Archive entries with names exactly matching a key will be renamed to the value, prior to any directory prefix adjustment. This can be used to extract archives that contain non-Unicode filenames, or which have files that would extract to the same path on case-insensitive filesystems. |
 | `watch_archive` | default is `'auto'`  whether to [watch](#watch) the archive file. Can be the string 'yes', 'no', or 'auto'. Passing 'yes' is equivalent to immediately invoking the [`watch()`](#watch) method; passing 'no' does not attempt to watch the file; passing 'auto' will only attempt to watch the file when it is legal to do so (see `watch()` docs for more information. |
@@ -144,7 +144,7 @@ Generates a file in the repository directory with the provided content.
 
 | Parameter | Description |
 | --- | --- |
-| `path` | [string](../core/string); or [Label](../builtins/Label); or [path](../builtins/path); required  Path of the file to create, relative to the repository directory. |
+| `path` | [string](/versions/7.6.1/rules/lib/core/string); or [Label](/versions/7.6.1/rules/lib/builtins/Label); or [path](/versions/7.6.1/rules/lib/builtins/path); required  Path of the file to create, relative to the repository directory. |
 | `content` | default is `''`  The content of the file to create, empty by default. |
 | `executable` | default is `True`  Set the executable flag on the created file, true by default. |
 | `legacy_utf8` | default is `True`  Encode file content to UTF-8, true by default. Future versions will change the default and remove this parameter. |
@@ -163,8 +163,8 @@ When building incrementally, any change to the value of the variable named by `n
 
 | Parameter | Description |
 | --- | --- |
-| `name` | [string](../core/string); required  Name of desired environment variable. |
-| `default` | [string](../core/string); or `None`; default is `None`  Default value to return if `name` is not found. |
+| `name` | [string](/versions/7.6.1/rules/lib/core/string); required  Name of desired environment variable. |
+| `default` | [string](/versions/7.6.1/rules/lib/core/string); or `None`; default is `None`  Default value to return if `name` is not found. |
 
 May return `None`.
 
@@ -196,7 +196,7 @@ Apply a patch file to the root directory of external repository. The patch file
 
 | Parameter | Description |
 | --- | --- |
-| `patch_file` | [string](../core/string); or [Label](../builtins/Label); or [path](../builtins/path); required  The patch file to apply, it can be label, relative path or absolute path. If it's a relative path, it will resolve to the repository directory. |
+| `patch_file` | [string](/versions/7.6.1/rules/lib/core/string); or [Label](/versions/7.6.1/rules/lib/builtins/Label); or [path](/versions/7.6.1/rules/lib/builtins/path); required  The patch file to apply, it can be label, relative path or absolute path. If it's a relative path, it will resolve to the repository directory. |
 | `strip` | default is `0`  Strip the specified number of leading components from file names. |
 | `watch_patch` | default is `'auto'`  Whether to [watch](#watch) the patch file. Can be the string 'yes', 'no', or 'auto'. Passing 'yes' is equivalent to immediately invoking the [`watch()`](#watch) method; passing 'no' does not attempt to watch the file; passing 'auto' will only attempt to watch the file when it is legal to do so (see `watch()` docs for more information. |
 
@@ -212,7 +212,7 @@ Returns a path from a string, label or path. If the path is relative, it will re
 
 | Parameter | Description |
 | --- | --- |
-| `path` | [string](../core/string); or [Label](../builtins/Label); or [path](../builtins/path); required  `string`, `Label` or `path` from which to create a path from. |
+| `path` | [string](/versions/7.6.1/rules/lib/core/string); or [Label](/versions/7.6.1/rules/lib/builtins/Label); or [path](/versions/7.6.1/rules/lib/builtins/path); required  `string`, `Label` or `path` from which to create a path from. |
 
 ## read
 
@@ -226,7 +226,7 @@ Reads the content of a file on the filesystem.
 
 | Parameter | Description |
 | --- | --- |
-| `path` | [string](../core/string); or [Label](../builtins/Label); or [path](../builtins/path); required  Path of the file to read from. |
+| `path` | [string](/versions/7.6.1/rules/lib/core/string); or [Label](/versions/7.6.1/rules/lib/builtins/Label); or [path](/versions/7.6.1/rules/lib/builtins/path); required  Path of the file to read from. |
 | `watch` | default is `'auto'`  Whether to [watch](#watch) the file. Can be the string 'yes', 'no', or 'auto'. Passing 'yes' is equivalent to immediately invoking the [`watch()`](#watch) method; passing 'no' does not attempt to watch the file; passing 'auto' will only attempt to watch the file when it is legal to do so (see `watch()` docs for more information. |
 
 ## report\_progress
@@ -241,7 +241,7 @@ Updates the progress status for the fetching of this repository or module extens
 
 | Parameter | Description |
 | --- | --- |
-| `status` | [string](../core/string); default is `''`  `string` describing the current status of the fetch progress. |
+| `status` | [string](/versions/7.6.1/rules/lib/core/string); default is `''`  `string` describing the current status of the fetch progress. |
 
 ## symlink
 
@@ -255,8 +255,8 @@ Creates a symlink on the filesystem.
 
 | Parameter | Description |
 | --- | --- |
-| `target` | [string](../core/string); or [Label](../builtins/Label); or [path](../builtins/path); required  The path that the symlink should point to. |
-| `link_name` | [string](../core/string); or [Label](../builtins/Label); or [path](../builtins/path); required  The path of the symlink to create. |
+| `target` | [string](/versions/7.6.1/rules/lib/core/string); or [Label](/versions/7.6.1/rules/lib/builtins/Label); or [path](/versions/7.6.1/rules/lib/builtins/path); required  The path that the symlink should point to. |
+| `link_name` | [string](/versions/7.6.1/rules/lib/core/string); or [Label](/versions/7.6.1/rules/lib/builtins/Label); or [path](/versions/7.6.1/rules/lib/builtins/path); required  The path of the symlink to create. |
 
 ## template
 
@@ -270,8 +270,8 @@ Generates a new file using a `template`. Every occurrence in `template` of a key
 
 | Parameter | Description |
 | --- | --- |
-| `path` | [string](../core/string); or [Label](../builtins/Label); or [path](../builtins/path); required  Path of the file to create, relative to the repository directory. |
-| `template` | [string](../core/string); or [Label](../builtins/Label); or [path](../builtins/path); required  Path to the template file. |
+| `path` | [string](/versions/7.6.1/rules/lib/core/string); or [Label](/versions/7.6.1/rules/lib/builtins/Label); or [path](/versions/7.6.1/rules/lib/builtins/path); required  Path of the file to create, relative to the repository directory. |
+| `template` | [string](/versions/7.6.1/rules/lib/core/string); or [Label](/versions/7.6.1/rules/lib/builtins/Label); or [path](/versions/7.6.1/rules/lib/builtins/path); required  Path to the template file. |
 | `substitutions` | default is `{}`  Substitutions to make when expanding the template. |
 | `executable` | default is `True`  Set the executable flag on the created file, true by default. |
 | `watch_template` | default is `'auto'`  Whether to [watch](#watch) the template file. Can be the string 'yes', 'no', or 'auto'. Passing 'yes' is equivalent to immediately invoking the [`watch()`](#watch) method; passing 'no' does not attempt to watch the file; passing 'auto' will only attempt to watch the file when it is legal to do so (see `watch()` docs for more information. |
@@ -284,7 +284,7 @@ None repository_ctx.watch(path)
 
 Tells Bazel to watch for changes to the given path, whether or not it exists, or whether it's a file or a directory. Any changes to the file or directory will invalidate this repository or module extension, and cause it to be refetched or re-evaluated next time.
 
-"Changes" include changes to the contents of the file (if the path is a file); if the path was a file but is now a directory, or vice versa; and if the path starts or stops existing. Notably, this does *not* include changes to any files under the directory if the path is a directory. For that, use [`path.readdir()`](path#readdir) instead.
+"Changes" include changes to the contents of the file (if the path is a file); if the path was a file but is now a directory, or vice versa; and if the path starts or stops existing. Notably, this does *not* include changes to any files under the directory if the path is a directory. For that, use [`path.readdir()`](/versions/7.6.1/rules/lib/builtins/path#readdir) instead.
 
 Note that attempting to watch paths inside the repo currently being fetched, or inside the working directory of the current module extension, will result in an error. A module extension attempting to watch a path outside the current Bazel workspace will also result in an error.
 
@@ -292,7 +292,7 @@ Note that attempting to watch paths inside the repo currently being fetched, or
 
 | Parameter | Description |
 | --- | --- |
-| `path` | [string](../core/string); or [Label](../builtins/Label); or [path](../builtins/path); required  Path of the file to watch. |
+| `path` | [string](/versions/7.6.1/rules/lib/core/string); or [Label](/versions/7.6.1/rules/lib/builtins/Label); or [path](/versions/7.6.1/rules/lib/builtins/path); required  Path of the file to watch. |
 
 ## watch\_tree
 
@@ -308,7 +308,7 @@ Note that attempting to watch paths inside the repo currently being fetched will
 
 | Parameter | Description |
 | --- | --- |
-| `path` | [string](../core/string); or [Label](../builtins/Label); or [path](../builtins/path); required  Path of the directory tree to watch. |
+| `path` | [string](/versions/7.6.1/rules/lib/core/string); or [Label](/versions/7.6.1/rules/lib/builtins/Label); or [path](/versions/7.6.1/rules/lib/builtins/path); required  Path of the directory tree to watch. |
 
 ## which
 
diff --git a/versions/7.6.1/rules/lib/builtins/rule_attributes.mdx b/versions/7.6.1/rules/lib/builtins/rule_attributes.mdx
index 7eeba4b7..a8cd0a72 100644
--- a/versions/7.6.1/rules/lib/builtins/rule_attributes.mdx
+++ b/versions/7.6.1/rules/lib/builtins/rule_attributes.mdx
@@ -18,7 +18,7 @@ Information about attributes of a rule an aspect is applied to.
 struct rule_attributes.attr
 ```
 
-A struct to access the values of the [attributes](https://bazel.build/versions/7.6.1/extending/rules#attributes). The values are provided by the user (if not, a default value is used). The attributes of the struct and the types of their values correspond to the keys and values of the [`attrs` dict](../globals/bzl#rule.attrs) provided to the [`rule` function](../globals/bzl#rule). [See example of use](https://github.com/bazelbuild/examples/blob/main/rules/attributes/printer.bzl).
+A struct to access the values of the [attributes](https://bazel.build/versions/7.6.1/extending/rules#attributes). The values are provided by the user (if not, a default value is used). The attributes of the struct and the types of their values correspond to the keys and values of the [`attrs` dict](/versions/7.6.1/rules/lib/globals/bzl#rule.attrs) provided to the [`rule` function](/versions/7.6.1/rules/lib/globals/bzl#rule). [See example of use](https://github.com/bazelbuild/examples/blob/main/rules/attributes/printer.bzl).
 
 ## executable
 
@@ -26,7 +26,7 @@ A struct to access the values of the [attributes](https://bazel.build/versions/7
 struct rule_attributes.executable
 ```
 
-A `struct` containing executable files defined in [label type attributes](../toplevel/attr#label) marked as [`executable=True`](../toplevel/attr#label.executable). The struct fields correspond to the attribute names. Each value in the struct is either a [`File`](../builtins/File) or `None`. If an optional attribute is not specified in the rule then the corresponding struct value is `None`. If a label type is not marked as `executable=True`, no corresponding struct field is generated. [See example of use](https://github.com/bazelbuild/examples/blob/main/rules/actions_run/execute.bzl).
+A `struct` containing executable files defined in [label type attributes](/versions/7.6.1/rules/lib/toplevel/attr#label) marked as [`executable=True`](/versions/7.6.1/rules/lib/toplevel/attr#label.executable). The struct fields correspond to the attribute names. Each value in the struct is either a [`File`](/versions/7.6.1/rules/lib/builtins/File) or `None`. If an optional attribute is not specified in the rule then the corresponding struct value is `None`. If a label type is not marked as `executable=True`, no corresponding struct field is generated. [See example of use](https://github.com/bazelbuild/examples/blob/main/rules/actions_run/execute.bzl).
 
 ## file
 
@@ -34,7 +34,7 @@ A `struct` containing executable files defined in [label type attributes](../top
 struct rule_attributes.file
 ```
 
-A `struct` containing files defined in [label type attributes](../toplevel/attr#label) marked as [`allow_single_file`](../toplevel/attr#label.allow_single_file). The struct fields correspond to the attribute names. The struct value is always a [`File`](../builtins/File) or `None`. If an optional attribute is not specified in the rule then the corresponding struct value is `None`. If a label type is not marked as `allow_single_file`, no corresponding struct field is generated. It is a shortcut for:
+A `struct` containing files defined in [label type attributes](/versions/7.6.1/rules/lib/toplevel/attr#label) marked as [`allow_single_file`](/versions/7.6.1/rules/lib/toplevel/attr#label.allow_single_file). The struct fields correspond to the attribute names. The struct value is always a [`File`](/versions/7.6.1/rules/lib/builtins/File) or `None`. If an optional attribute is not specified in the rule then the corresponding struct value is `None`. If a label type is not marked as `allow_single_file`, no corresponding struct field is generated. It is a shortcut for:
 
 ```
 list(ctx.attr..files)[0]
@@ -48,7 +48,7 @@ In other words, use `file` to access the (singular) [default output](https://baz
 struct rule_attributes.files
 ```
 
-A `struct` containing files defined in [label](../toplevel/attr#label) or [label list](../toplevel/attr#label_list) type attributes. The struct fields correspond to the attribute names. The struct values are `list` of [`File`](../builtins/File)s. It is a shortcut for:
+A `struct` containing files defined in [label](/versions/7.6.1/rules/lib/toplevel/attr#label) or [label list](/versions/7.6.1/rules/lib/toplevel/attr#label_list) type attributes. The struct fields correspond to the attribute names. The struct values are `list` of [`File`](/versions/7.6.1/rules/lib/builtins/File)s. It is a shortcut for:
 
 ```
 [f for t in ctx.attr. for f in t.files]
diff --git a/versions/7.6.1/rules/lib/builtins/runfiles.mdx b/versions/7.6.1/rules/lib/builtins/runfiles.mdx
index 56a0719a..18d2628b 100644
--- a/versions/7.6.1/rules/lib/builtins/runfiles.mdx
+++ b/versions/7.6.1/rules/lib/builtins/runfiles.mdx
@@ -2,7 +2,7 @@
 title: 'runfiles'
 ---
 
-A container of information regarding a set of files required at runtime execution. This object should be passed via [DefaultInfo](../providers/DefaultInfo) in order to tell the build system about the runfiles needed by the outputs produced by the rule.
+A container of information regarding a set of files required at runtime execution. This object should be passed via [DefaultInfo](/versions/7.6.1/rules/lib/providers/DefaultInfo) in order to tell the build system about the runfiles needed by the outputs produced by the rule.
 
 See [runfiles guide](https://bazel.build/versions/7.6.1/extending/rules#runfiles) for details.
 
@@ -59,7 +59,7 @@ Returns a new runfiles object that includes all the contents of this one and of
 
 | Parameter | Description |
 | --- | --- |
-| `other` | [sequence](../core/list) of [runfiles](../builtins/runfiles)s; required  The sequence of runfiles objects to merge into this. |
+| `other` | [sequence](/versions/7.6.1/rules/lib/core/list) of [runfiles](/versions/7.6.1/rules/lib/builtins/runfiles)s; required  The sequence of runfiles objects to merge into this. |
 
 ## root\_symlinks
 
diff --git a/versions/7.6.1/rules/lib/builtins/transition.mdx b/versions/7.6.1/rules/lib/builtins/transition.mdx
index f589404e..e4d3b518 100644
--- a/versions/7.6.1/rules/lib/builtins/transition.mdx
+++ b/versions/7.6.1/rules/lib/builtins/transition.mdx
@@ -39,5 +39,5 @@ For more details see [here](https://bazel.build/versions/7.6.1/rules/config#user
 | Parameter | Description |
 | --- | --- |
 | `implementation` | required  The function implementing this transition. This function always has two parameters: `settings` and `attr`. The `settings` param is a dictionary whose set of keys is defined by the inputs parameter. So, for each build setting `--//foo=bar`, if `inputs` contains `//foo`, `settings` will have an entry `settings['//foo']='bar'`. The `attr` param is a reference to `ctx.attr`. This gives the implementation function access to the rule's attributes to make attribute-parameterized transitions possible. This function must return a `dict` from build setting identifier to build setting value; this represents the configuration transition: for each entry in the returned `dict`, the transition updates that setting to the new value. All other settings are unchanged. This function can also return a `list` of `dict`s or a `dict` of `dict`s in the case of a split transition. |
-| `inputs` | [sequence](../core/list) of [string](../core/string)s; required  List of build settings that can be read by this transition. This becomes the key set of the settings parameter of the implementation function parameter. |
-| `outputs` | [sequence](../core/list) of [string](../core/string)s; required  List of build settings that can be written by this transition. This must be a superset of the key set of the dictionary returned by this transition. |
\ No newline at end of file
+| `inputs` | [sequence](/versions/7.6.1/rules/lib/core/list) of [string](/versions/7.6.1/rules/lib/core/string)s; required  List of build settings that can be read by this transition. This becomes the key set of the settings parameter of the implementation function parameter. |
+| `outputs` | [sequence](/versions/7.6.1/rules/lib/core/list) of [string](/versions/7.6.1/rules/lib/core/string)s; required  List of build settings that can be written by this transition. This must be a superset of the key set of the dictionary returned by this transition. |
\ No newline at end of file
diff --git a/versions/7.6.1/rules/lib/core/bool.mdx b/versions/7.6.1/rules/lib/core/bool.mdx
index 52be3664..67190662 100644
--- a/versions/7.6.1/rules/lib/core/bool.mdx
+++ b/versions/7.6.1/rules/lib/core/bool.mdx
@@ -2,4 +2,4 @@
 title: 'bool'
 ---
 
-A type to represent booleans. There are only two possible values: True and False. Any value can be converted to a boolean using the [bool](../globals/all#bool) function.
\ No newline at end of file
+A type to represent booleans. There are only two possible values: True and False. Any value can be converted to a boolean using the [bool](/versions/7.6.1/rules/lib/globals/all#bool) function.
\ No newline at end of file
diff --git a/versions/7.6.1/rules/lib/core/dict.mdx b/versions/7.6.1/rules/lib/core/dict.mdx
index 0fd1c419..3383799e 100644
--- a/versions/7.6.1/rules/lib/core/dict.mdx
+++ b/versions/7.6.1/rules/lib/core/dict.mdx
@@ -22,7 +22,7 @@ There are four ways to construct a dictionary:
      {i: 2*i for i in range(3)}  # {0: 0, 1: 2, 2: 4}
      ```
 
-     - A call to the built-in [dict](../globals/all#dict) function returns a dictionary containing the specified entries, which are inserted in argument order, positional arguments before named. As with comprehensions, duplicate keys are permitted.- The union expression `x | y` yields a new dictionary by combining two existing dictionaries. If the two dictionaries have a key `k` in common, the right hand side dictionary's value of the key (in other words, `y[k]`) wins. The `|=` variant of the union operator modifies a dictionary in-place. Example:
+     - A call to the built-in [dict](/versions/7.6.1/rules/lib/globals/all#dict) function returns a dictionary containing the specified entries, which are inserted in argument order, positional arguments before named. As with comprehensions, duplicate keys are permitted.- The union expression `x | y` yields a new dictionary by combining two existing dictionaries. If the two dictionaries have a key `k` in common, the right hand side dictionary's value of the key (in other words, `y[k]`) wins. The `|=` variant of the union operator modifies a dictionary in-place. Example:
 
          ```
          d = {"foo": "FOO", "bar": "BAR"} | {"foo": "FOO2", "baz": "BAZ"}
diff --git a/versions/7.6.1/rules/lib/core/list.mdx b/versions/7.6.1/rules/lib/core/list.mdx
index a04edd62..4ef7a72b 100644
--- a/versions/7.6.1/rules/lib/core/list.mdx
+++ b/versions/7.6.1/rules/lib/core/list.mdx
@@ -91,8 +91,8 @@ Returns the index in the list of the first item whose value is x. It is an error
 | Parameter | Description |
 | --- | --- |
 | `x` | required |
-| `start` | [int](../core/int); or `None`; default is `None`  The start index of the list portion to inspect. |
-| `end` | [int](../core/int); or `None`; default is `None`  The end index of the list portion to inspect. |
+| `start` | [int](/versions/7.6.1/rules/lib/core/int); or `None`; default is `None`  The start index of the list portion to inspect. |
+| `end` | [int](/versions/7.6.1/rules/lib/core/int); or `None`; default is `None`  The end index of the list portion to inspect. |
 
 ## insert
 
@@ -121,7 +121,7 @@ Removes the item at the given position in the list, and returns it. If no `index
 
 | Parameter | Description |
 | --- | --- |
-| `i` | [int](../core/int); or `None`; default is `-1`  The index of the item. |
+| `i` | [int](/versions/7.6.1/rules/lib/core/int); or `None`; default is `-1`  The index of the item. |
 
 ## remove
 
diff --git a/versions/7.6.1/rules/lib/core/string.mdx b/versions/7.6.1/rules/lib/core/string.mdx
index b9a7508b..72e657b0 100644
--- a/versions/7.6.1/rules/lib/core/string.mdx
+++ b/versions/7.6.1/rules/lib/core/string.mdx
@@ -82,8 +82,8 @@ Returns the number of (non-overlapping) occurrences of substring `sub` in string
 | Parameter | Description |
 | --- | --- |
 | `sub` | required |
-| `start` | [int](../core/int); or `None`; default is `0` |
-| `end` | [int](../core/int); or `None`; default is `None`  optional position before which to restrict to search. |
+| `start` | [int](/versions/7.6.1/rules/lib/core/int); or `None`; default is `0` |
+| `end` | [int](/versions/7.6.1/rules/lib/core/int); or `None`; default is `None`  optional position before which to restrict to search. |
 
 ## elems
 
@@ -105,9 +105,9 @@ Returns True if the string ends with `sub`, otherwise False, optionally restrict
 
 | Parameter | Description |
 | --- | --- |
-| `sub` | [string](../core/string); or [tuple](../core/tuple) of [string](../core/string)s; required  The suffix (or tuple of alternative suffixes) to match. |
-| `start` | [int](../core/int); or `None`; default is `0`  Test beginning at this position. |
-| `end` | [int](../core/int); or `None`; default is `None`  optional position at which to stop comparing. |
+| `sub` | [string](/versions/7.6.1/rules/lib/core/string); or [tuple](/versions/7.6.1/rules/lib/core/tuple) of [string](/versions/7.6.1/rules/lib/core/string)s; required  The suffix (or tuple of alternative suffixes) to match. |
+| `start` | [int](/versions/7.6.1/rules/lib/core/int); or `None`; default is `0`  Test beginning at this position. |
+| `end` | [int](/versions/7.6.1/rules/lib/core/int); or `None`; default is `None`  optional position at which to stop comparing. |
 
 ## find
 
@@ -122,8 +122,8 @@ Returns the first index where `sub` is found, or -1 if no such index exists, opt
 | Parameter | Description |
 | --- | --- |
 | `sub` | required  The substring to find. |
-| `start` | [int](../core/int); or `None`; default is `0`  Restrict to search from this position. |
-| `end` | [int](../core/int); or `None`; default is `None`  optional position before which to restrict to search. |
+| `start` | [int](/versions/7.6.1/rules/lib/core/int); or `None`; default is `0`  Restrict to search from this position. |
+| `end` | [int](/versions/7.6.1/rules/lib/core/int); or `None`; default is `None`  optional position before which to restrict to search. |
 
 ## format
 
@@ -131,7 +131,7 @@ Returns the first index where `sub` is found, or -1 if no such index exists, opt
 string string.format(*args, **kwargs)
 ```
 
-Perform string interpolation. Format strings contain replacement fields surrounded by curly braces `{}`. Anything that is not contained in braces is considered literal text, which is copied unchanged to the output.If you need to include a brace character in the literal text, it can be escaped by doubling: `{{` and `}}`A replacement field can be either a name, a number, or empty. Values are converted to strings using the [str](../globals/all#str) function.
+Perform string interpolation. Format strings contain replacement fields surrounded by curly braces `{}`. Anything that is not contained in braces is considered literal text, which is copied unchanged to the output.If you need to include a brace character in the literal text, it can be escaped by doubling: `{{` and `}}`A replacement field can be either a name, a number, or empty. Values are converted to strings using the [str](/versions/7.6.1/rules/lib/globals/all#str) function.
 
 ```
 # Access in order:
@@ -162,8 +162,8 @@ Returns the first index where `sub` is found, or raises an error if no such inde
 | Parameter | Description |
 | --- | --- |
 | `sub` | required  The substring to find. |
-| `start` | [int](../core/int); or `None`; default is `0`  Restrict to search from this position. |
-| `end` | [int](../core/int); or `None`; default is `None`  optional position before which to restrict to search. |
+| `start` | [int](/versions/7.6.1/rules/lib/core/int); or `None`; default is `0`  Restrict to search from this position. |
+| `end` | [int](/versions/7.6.1/rules/lib/core/int); or `None`; default is `None`  optional position before which to restrict to search. |
 
 ## isalnum
 
@@ -263,7 +263,7 @@ Returns a copy of the string where leading characters that appear in `chars` are
 
 | Parameter | Description |
 | --- | --- |
-| `chars` | [string](../core/string); or `None`; default is `None`  The characters to remove, or all whitespace if None. |
+| `chars` | [string](/versions/7.6.1/rules/lib/core/string); or `None`; default is `None`  The characters to remove, or all whitespace if None. |
 
 ## partition
 
@@ -336,8 +336,8 @@ Returns the last index where `sub` is found, or -1 if no such index exists, opti
 | Parameter | Description |
 | --- | --- |
 | `sub` | required  The substring to find. |
-| `start` | [int](../core/int); or `None`; default is `0`  Restrict to search from this position. |
-| `end` | [int](../core/int); or `None`; default is `None`  optional position before which to restrict to search. |
+| `start` | [int](/versions/7.6.1/rules/lib/core/int); or `None`; default is `0`  Restrict to search from this position. |
+| `end` | [int](/versions/7.6.1/rules/lib/core/int); or `None`; default is `None`  optional position before which to restrict to search. |
 
 ## rindex
 
@@ -352,8 +352,8 @@ Returns the last index where `sub` is found, or raises an error if no such index
 | Parameter | Description |
 | --- | --- |
 | `sub` | required  The substring to find. |
-| `start` | [int](../core/int); or `None`; default is `0`  Restrict to search from this position. |
-| `end` | [int](../core/int); or `None`; default is `None`  optional position before which to restrict to search. |
+| `start` | [int](/versions/7.6.1/rules/lib/core/int); or `None`; default is `0`  Restrict to search from this position. |
+| `end` | [int](/versions/7.6.1/rules/lib/core/int); or `None`; default is `None`  optional position before which to restrict to search. |
 
 ## rpartition
 
@@ -382,7 +382,7 @@ Returns a list of all the words in the string, using `sep` as the separator, opt
 | Parameter | Description |
 | --- | --- |
 | `sep` | required  The string to split on. |
-| `maxsplit` | [int](../core/int); or `None`; default is `None`  The maximum number of splits. |
+| `maxsplit` | [int](/versions/7.6.1/rules/lib/core/int); or `None`; default is `None`  The maximum number of splits. |
 
 ## rstrip
 
@@ -400,7 +400,7 @@ Returns a copy of the string where trailing characters that appear in `chars` ar
 
 | Parameter | Description |
 | --- | --- |
-| `chars` | [string](../core/string); or `None`; default is `None`  The characters to remove, or all whitespace if None. |
+| `chars` | [string](/versions/7.6.1/rules/lib/core/string); or `None`; default is `None`  The characters to remove, or all whitespace if None. |
 
 ## split
 
@@ -415,7 +415,7 @@ Returns a list of all the words in the string, using `sep` as the separator, opt
 | Parameter | Description |
 | --- | --- |
 | `sep` | required  The string to split on. |
-| `maxsplit` | [int](../core/int); or `None`; default is `None`  The maximum number of splits. |
+| `maxsplit` | [int](/versions/7.6.1/rules/lib/core/int); or `None`; default is `None`  The maximum number of splits. |
 
 ## splitlines
 
@@ -443,9 +443,9 @@ Returns True if the string starts with `sub`, otherwise False, optionally restri
 
 | Parameter | Description |
 | --- | --- |
-| `sub` | [string](../core/string); or [tuple](../core/tuple) of [string](../core/string)s; required  The prefix (or tuple of alternative prefixes) to match. |
-| `start` | [int](../core/int); or `None`; default is `0`  Test beginning at this position. |
-| `end` | [int](../core/int); or `None`; default is `None`  Stop comparing at this position. |
+| `sub` | [string](/versions/7.6.1/rules/lib/core/string); or [tuple](/versions/7.6.1/rules/lib/core/tuple) of [string](/versions/7.6.1/rules/lib/core/string)s; required  The prefix (or tuple of alternative prefixes) to match. |
+| `start` | [int](/versions/7.6.1/rules/lib/core/int); or `None`; default is `0`  Test beginning at this position. |
+| `end` | [int](/versions/7.6.1/rules/lib/core/int); or `None`; default is `None`  Stop comparing at this position. |
 
 ## strip
 
@@ -463,7 +463,7 @@ Returns a copy of the string where leading or trailing characters that appear in
 
 | Parameter | Description |
 | --- | --- |
-| `chars` | [string](../core/string); or `None`; default is `None`  The characters to remove, or all whitespace if None. |
+| `chars` | [string](/versions/7.6.1/rules/lib/core/string); or `None`; default is `None`  The characters to remove, or all whitespace if None. |
 
 ## title
 
diff --git a/versions/7.6.1/rules/lib/fragments.mdx b/versions/7.6.1/rules/lib/fragments.mdx
index 364a84d1..81d98778 100644
--- a/versions/7.6.1/rules/lib/fragments.mdx
+++ b/versions/7.6.1/rules/lib/fragments.mdx
@@ -2,7 +2,7 @@
 title: 'Configuration Fragments'
 ---
 
-Configuration fragments give rules access to language-specific parts of [configuration](builtins/configuration).
+Configuration fragments give rules access to language-specific parts of [configuration](/versions/7.6.1/rules/lib/builtins/configuration).
 
 Rule implementations can get them using `ctx.fragments.[fragment name]`
 
diff --git a/versions/7.6.1/rules/lib/fragments/coverage.mdx b/versions/7.6.1/rules/lib/fragments/coverage.mdx
index d3c2b0d9..27034c42 100644
--- a/versions/7.6.1/rules/lib/fragments/coverage.mdx
+++ b/versions/7.6.1/rules/lib/fragments/coverage.mdx
@@ -14,7 +14,7 @@ A configuration fragment representing the coverage configuration.
 Label coverage.output_generator
 ```
 
-Returns the label pointed to by the [`--coverage_output_generator`](https://bazel.build/versions/7.6.1/reference/command-line-reference#flag--coverage_output_generator) option if coverage collection is enabled, otherwise returns `None`. Can be accessed with [`configuration_field`](../globals/bzl#configuration_field):
+Returns the label pointed to by the [`--coverage_output_generator`](https://bazel.build/versions/7.6.1/reference/command-line-reference#flag--coverage_output_generator) option if coverage collection is enabled, otherwise returns `None`. Can be accessed with [`configuration_field`](/versions/7.6.1/rules/lib/globals/bzl#configuration_field):
 
 ```
 attr.label(
diff --git a/versions/7.6.1/rules/lib/fragments/cpp.mdx b/versions/7.6.1/rules/lib/fragments/cpp.mdx
index c29e04a8..4a556701 100644
--- a/versions/7.6.1/rules/lib/fragments/cpp.mdx
+++ b/versions/7.6.1/rules/lib/fragments/cpp.mdx
@@ -55,7 +55,7 @@ The flags passed to Bazel by [`--copt`](/versions/7.6.1/docs/user-manual#flag--c
 Label cpp.custom_malloc
 ```
 
-Returns label pointed to by [`--custom_malloc`](/versions/7.6.1/docs/user-manual#flag--custom_malloc) option. Can be accessed with [`configuration_field`](../globals/bzl#configuration_field):
+Returns label pointed to by [`--custom_malloc`](/versions/7.6.1/docs/user-manual#flag--custom_malloc) option. Can be accessed with [`configuration_field`](/versions/7.6.1/rules/lib/globals/bzl#configuration_field):
 
 ```
 attr.label(
diff --git a/versions/7.6.1/rules/lib/globals/all.mdx b/versions/7.6.1/rules/lib/globals/all.mdx
index 35a9b985..d137c7af 100644
--- a/versions/7.6.1/rules/lib/globals/all.mdx
+++ b/versions/7.6.1/rules/lib/globals/all.mdx
@@ -49,7 +49,7 @@ abs(-2.3) == 2.3
 
 | Parameter | Description |
 | --- | --- |
-| `x` | [int](../core/int); or [float](../core/float); required  A number (int or float) |
+| `x` | [int](/versions/7.6.1/rules/lib/core/int); or [float](/versions/7.6.1/rules/lib/core/float); required  A number (int or float) |
 
 ## all
 
@@ -109,7 +109,7 @@ Constructor for the bool type. It returns `False` if the object is `None`, `Fals
 dict dict(pairs=[], **kwargs)
 ```
 
-Creates a [dictionary](../core/dict) from an optional positional argument and an optional set of keyword arguments. In the case where the same key is given multiple times, the last value will be used. Entries supplied via keyword arguments are considered to come after entries supplied via the positional argument.
+Creates a [dictionary](/versions/7.6.1/rules/lib/core/dict) from an optional positional argument and an optional set of keyword arguments. In the case where the same key is given multiple times, the last value will be used. Entries supplied via keyword arguments are considered to come after entries supplied via the positional argument.
 
 ### Parameters
 
@@ -164,7 +164,7 @@ Causes execution to fail with an error.
 | Parameter | Description |
 | --- | --- |
 | `msg` | default is `None`  Deprecated: use positional arguments instead. This argument acts like an implicit leading positional argument. |
-| `attr` | [string](../core/string); or `None`; default is `None`  Deprecated. Causes an optional prefix containing this string to be added to the error message. |
+| `attr` | [string](/versions/7.6.1/rules/lib/core/string); or `None`; default is `None`  Deprecated. Causes an optional prefix containing this string to be added to the error message. |
 | `sep` | default is `" "`  The separator string between the objects, default is space (" "). |
 | `args` | required  A list of values, formatted with debugPrint (which is equivalent to str by default) and joined with sep (defaults to " "), that appear in the error message. |
 
@@ -393,7 +393,7 @@ range(3, 0, -1) == [3, 2, 1]
 | Parameter | Description |
 | --- | --- |
 | `start_or_stop` | required  Value of the start element if stop is provided, otherwise value of stop and the actual start is 0 |
-| `stop_or_none` | [int](../core/int); or `None`; default is `None`  optional index of the first item *not* to be included in the resulting list; generation of the list stops before `stop` is reached. |
+| `stop_or_none` | [int](/versions/7.6.1/rules/lib/core/int); or `None`; default is `None`  optional index of the first item *not* to be included in the resulting list; generation of the list stops before `stop` is reached. |
 | `step` | default is `1`  The increment (default is 1). It may be negative. |
 
 ## repr
diff --git a/versions/7.6.1/rules/lib/globals/build.mdx b/versions/7.6.1/rules/lib/globals/build.mdx
index 3021c789..c72e6d13 100644
--- a/versions/7.6.1/rules/lib/globals/build.mdx
+++ b/versions/7.6.1/rules/lib/globals/build.mdx
@@ -27,7 +27,7 @@ Methods available in BUILD files. See also the Build Encyclopedia for extra [fun
 depset depset(direct=None, order="default", *, transitive=None)
 ```
 
-Creates a [depset](../builtins/depset). The `direct` parameter is a list of direct elements of the depset, and `transitive` parameter is a list of depsets whose elements become indirect elements of the created depset. The order in which elements are returned when the depset is converted to a list is specified by the `order` parameter. See the [Depsets overview](https://bazel.build/versions/7.6.1/extending/depsets) for more information.
+Creates a [depset](/versions/7.6.1/rules/lib/builtins/depset). The `direct` parameter is a list of direct elements of the depset, and `transitive` parameter is a list of depsets whose elements become indirect elements of the created depset. The order in which elements are returned when the depset is converted to a list is specified by the `order` parameter. See the [Depsets overview](https://bazel.build/versions/7.6.1/extending/depsets) for more information.
 
 All elements (direct and indirect) of a depset must be of the same type, as obtained by the expression `type(x)`.
 
@@ -41,9 +41,9 @@ The order of the created depset should be *compatible* with the order of its `tr
 
 | Parameter | Description |
 | --- | --- |
-| `direct` | [sequence](../core/list); or `None`; default is `None`  A list of *direct* elements of a depset. |
-| `order` | default is `"default"`  The traversal strategy for the new depset. See [here](../builtins/depset) for the possible values. |
-| `transitive` | [sequence](../core/list) of [depset](../builtins/depset)s; or `None`; default is `None`  A list of depsets whose elements will become indirect elements of the depset. |
+| `direct` | [sequence](/versions/7.6.1/rules/lib/core/list); or `None`; default is `None`  A list of *direct* elements of a depset. |
+| `order` | default is `"default"`  The traversal strategy for the new depset. See [here](/versions/7.6.1/rules/lib/builtins/depset) for the possible values. |
+| `transitive` | [sequence](/versions/7.6.1/rules/lib/core/list) of [depset](/versions/7.6.1/rules/lib/builtins/depset)s; or `None`; default is `None`  A list of depsets whose elements will become indirect elements of the depset. |
 
 ## existing\_rule
 
@@ -101,9 +101,9 @@ Specifies a list of files belonging to this package that are exported to other p
 
 | Parameter | Description |
 | --- | --- |
-| `srcs` | [sequence](../core/list) of [string](../core/string)s; required  The list of files to export. |
-| `visibility` | [sequence](../core/list); or `None`; default is `None`  A visibility declaration can to be specified. The files will be visible to the targets specified. If no visibility is specified, the files will be visible to every package. |
-| `licenses` | [sequence](../core/list) of [string](../core/string)s; or `None`; default is `None`  Licenses to be specified. |
+| `srcs` | [sequence](/versions/7.6.1/rules/lib/core/list) of [string](/versions/7.6.1/rules/lib/core/string)s; required  The list of files to export. |
+| `visibility` | [sequence](/versions/7.6.1/rules/lib/core/list); or `None`; default is `None`  A visibility declaration can to be specified. The files will be visible to the targets specified. If no visibility is specified, the files will be visible to every package. |
+| `licenses` | [sequence](/versions/7.6.1/rules/lib/core/list) of [string](/versions/7.6.1/rules/lib/core/string)s; or `None`; default is `None`  Licenses to be specified. |
 
 ## glob
 
@@ -122,8 +122,8 @@ If the `exclude_directories` argument is enabled (set to `1`), files of type dir
 
 | Parameter | Description |
 | --- | --- |
-| `include` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  The list of glob patterns to include. |
-| `exclude` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  The list of glob patterns to exclude. |
+| `include` | [sequence](/versions/7.6.1/rules/lib/core/list) of [string](/versions/7.6.1/rules/lib/core/string)s; default is `[]`  The list of glob patterns to include. |
+| `exclude` | [sequence](/versions/7.6.1/rules/lib/core/list) of [string](/versions/7.6.1/rules/lib/core/string)s; default is `[]`  The list of glob patterns to exclude. |
 | `exclude_directories` | default is `1`  A flag whether to exclude directories or not. |
 | `allow_empty` | default is `unbound`  Whether we allow glob patterns to match nothing. If `allow\_empty` is False, each individual include pattern must match something and also the final result must be non-empty (after the matches of the `exclude` patterns are excluded). |
 
@@ -158,8 +158,8 @@ This function defines a set of packages and assigns a label to the group. The la
 | Parameter | Description |
 | --- | --- |
 | `name` | required  The unique name for this rule. |
-| `packages` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  A complete enumeration of packages in this group. |
-| `includes` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  Other package groups that are included in this one. |
+| `packages` | [sequence](/versions/7.6.1/rules/lib/core/list) of [string](/versions/7.6.1/rules/lib/core/string)s; default is `[]`  A complete enumeration of packages in this group. |
+| `includes` | [sequence](/versions/7.6.1/rules/lib/core/list) of [string](/versions/7.6.1/rules/lib/core/string)s; default is `[]`  Other package groups that are included in this one. |
 
 ## package\_name
 
@@ -175,19 +175,19 @@ The name of the package being evaluated, without the repository name. For exampl
 Label package_relative_label(input)
 ```
 
-Converts the input string into a [Label](../builtins/Label) object, in the context of the package currently being initialized (that is, the `BUILD` file for which the current macro is executing). If the input is already a `Label`, it is returned unchanged.
+Converts the input string into a [Label](/versions/7.6.1/rules/lib/builtins/Label) object, in the context of the package currently being initialized (that is, the `BUILD` file for which the current macro is executing). If the input is already a `Label`, it is returned unchanged.
 
 This function may only be called while evaluating a BUILD file and the macros it directly or indirectly calls; it may not be called in (for instance) a rule implementation function.
 
 The result of this function is the same `Label` value as would be produced by passing the given string to a label-valued attribute of a target declared in the BUILD file.
 
-*Usage note:* The difference between this function and [Label()](../builtins/Label#Label) is that `Label()` uses the context of the package of the `.bzl` file that called it, not the package of the `BUILD` file. Use `Label()` when you need to refer to a fixed target that is hardcoded into the macro, such as a compiler. Use `package_relative_label()` when you need to normalize a label string supplied by the BUILD file to a `Label` object. (There is no way to convert a string to a `Label` in the context of a package other than the BUILD file or the calling .bzl file. For that reason, outer macros should always prefer to pass Label objects to inner macros rather than label strings.)
+*Usage note:* The difference between this function and [Label()](/versions/7.6.1/rules/lib/builtins/Label#Label) is that `Label()` uses the context of the package of the `.bzl` file that called it, not the package of the `BUILD` file. Use `Label()` when you need to refer to a fixed target that is hardcoded into the macro, such as a compiler. Use `package_relative_label()` when you need to normalize a label string supplied by the BUILD file to a `Label` object. (There is no way to convert a string to a `Label` in the context of a package other than the BUILD file or the calling .bzl file. For that reason, outer macros should always prefer to pass Label objects to inner macros rather than label strings.)
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `input` | [string](../core/string); or [Label](../builtins/Label); required  The input label string or Label object. If a Label object is passed, it's returned as is. |
+| `input` | [string](/versions/7.6.1/rules/lib/core/string); or [Label](/versions/7.6.1/rules/lib/builtins/Label); required  The input label string or Label object. If a Label object is passed, it's returned as is. |
 
 ## repo\_name
 
@@ -235,6 +235,6 @@ Returns a new mutable list of every direct subpackage of the current package, re
 
 | Parameter | Description |
 | --- | --- |
-| `include` | [sequence](../core/list) of [string](../core/string)s; required  The list of glob patterns to include in subpackages scan. |
-| `exclude` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  The list of glob patterns to exclude from subpackages scan. |
+| `include` | [sequence](/versions/7.6.1/rules/lib/core/list) of [string](/versions/7.6.1/rules/lib/core/string)s; required  The list of glob patterns to include in subpackages scan. |
+| `exclude` | [sequence](/versions/7.6.1/rules/lib/core/list) of [string](/versions/7.6.1/rules/lib/core/string)s; default is `[]`  The list of glob patterns to exclude from subpackages scan. |
 | `allow_empty` | default is `False`  Whether we fail if the call returns an empty list. By default empty list indicates potential error in BUILD file where the call to subpackages() is superflous. Setting to true allows this function to succeed in that case. |
\ No newline at end of file
diff --git a/versions/7.6.1/rules/lib/globals/bzl.mdx b/versions/7.6.1/rules/lib/globals/bzl.mdx
index a24d807e..1464dba7 100644
--- a/versions/7.6.1/rules/lib/globals/bzl.mdx
+++ b/versions/7.6.1/rules/lib/globals/bzl.mdx
@@ -26,7 +26,7 @@ Global methods available in all .bzl files.
 transition analysis_test_transition(settings)
 ```
 
-Creates a configuration transition to be applied on an analysis-test rule's dependencies. This transition may only be applied on attributes of rules with `analysis_test = True`. Such rules are restricted in capabilities (for example, the size of their dependency tree is limited), so transitions created using this function are limited in potential scope as compared to transitions created using [`transition()`](../builtins/transition).
+Creates a configuration transition to be applied on an analysis-test rule's dependencies. This transition may only be applied on attributes of rules with `analysis_test = True`. Such rules are restricted in capabilities (for example, the size of their dependency tree is limited), so transitions created using this function are limited in potential scope as compared to transitions created using [`transition()`](/versions/7.6.1/rules/lib/builtins/transition).
 
 This function is primarily designed to facilitate the [Analysis Test Framework](https://bazel.build/versions/7.6.1/rules/testing) core library. See its documentation (or its implementation) for best practices.
 
@@ -48,22 +48,22 @@ Creates a new aspect. The result of this function must be stored in a global val
 
 | Parameter | Description |
 | --- | --- |
-| `implementation` | required  A Starlark function that implements this aspect, with exactly two parameters: [Target](../builtins/Target) (the target to which the aspect is applied) and [ctx](../builtins/ctx) (the rule context which the target is created from). Attributes of the target are available via the `ctx.rule` field. This function is evaluated during the analysis phase for each application of an aspect to a target. |
-| `attr_aspects` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  List of attribute names. The aspect propagates along dependencies specified in the attributes of a target with these names. Common values here include `deps` and `exports`. The list can also contain a single string `"*"` to propagate along all dependencies of a target. |
-| `attrs` | [dict](../core/dict); default is `{}`  A dictionary declaring all the attributes of the aspect. It maps from an attribute name to an attribute object, like `attr.label` or `attr.string` (see [attr](../toplevel/attr) module). Aspect attributes are available to implementation function as fields of `ctx` parameter. Implicit attributes starting with `_` must have default values, and have type `label` or `label_list`. Explicit attributes must have type `string`, and must use the `values` restriction. Explicit attributes restrict the aspect to only be used with rules that have attributes of the same name, type, and valid values according to the restriction. |
+| `implementation` | required  A Starlark function that implements this aspect, with exactly two parameters: [Target](/versions/7.6.1/rules/lib/builtins/Target) (the target to which the aspect is applied) and [ctx](/versions/7.6.1/rules/lib/builtins/ctx) (the rule context which the target is created from). Attributes of the target are available via the `ctx.rule` field. This function is evaluated during the analysis phase for each application of an aspect to a target. |
+| `attr_aspects` | [sequence](/versions/7.6.1/rules/lib/core/list) of [string](/versions/7.6.1/rules/lib/core/string)s; default is `[]`  List of attribute names. The aspect propagates along dependencies specified in the attributes of a target with these names. Common values here include `deps` and `exports`. The list can also contain a single string `"*"` to propagate along all dependencies of a target. |
+| `attrs` | [dict](/versions/7.6.1/rules/lib/core/dict); default is `{}`  A dictionary declaring all the attributes of the aspect. It maps from an attribute name to an attribute object, like `attr.label` or `attr.string` (see [attr](/versions/7.6.1/rules/lib/toplevel/attr) module). Aspect attributes are available to implementation function as fields of `ctx` parameter. Implicit attributes starting with `_` must have default values, and have type `label` or `label_list`. Explicit attributes must have type `string`, and must use the `values` restriction. Explicit attributes restrict the aspect to only be used with rules that have attributes of the same name, type, and valid values according to the restriction. |
 | `required_providers` | default is `[]`  This attribute allows the aspect to limit its propagation to only the targets whose rules advertise its required providers. The value must be a list containing either individual providers or lists of providers but not both. For example, `[[FooInfo], [BarInfo], [BazInfo, QuxInfo]]` is a valid value while `[FooInfo, BarInfo, [BazInfo, QuxInfo]]` is not valid. An unnested list of providers will automatically be converted to a list containing one list of providers. That is, `[FooInfo, BarInfo]` will automatically be converted to `[[FooInfo, BarInfo]]`. To make some rule (e.g. `some_rule`) targets visible to an aspect, `some_rule` must advertise all providers from at least one of the required providers lists. For example, if the `required_providers` of an aspect are `[[FooInfo], [BarInfo], [BazInfo, QuxInfo]]`, this aspect can see `some_rule` targets if and only if `some_rule` provides `FooInfo`, *or* `BarInfo`, *or* both `BazInfo` *and* `QuxInfo`. |
 | `required_aspect_providers` | default is `[]`  This attribute allows this aspect to inspect other aspects. The value must be a list containing either individual providers or lists of providers but not both. For example, `[[FooInfo], [BarInfo], [BazInfo, QuxInfo]]` is a valid value while `[FooInfo, BarInfo, [BazInfo, QuxInfo]]` is not valid. An unnested list of providers will automatically be converted to a list containing one list of providers. That is, `[FooInfo, BarInfo]` will automatically be converted to `[[FooInfo, BarInfo]]`. To make another aspect (e.g. `other_aspect`) visible to this aspect, `other_aspect` must provide all providers from at least one of the lists. In the example of `[[FooInfo], [BarInfo], [BazInfo, QuxInfo]]`, this aspect can see `other_aspect` if and only if `other_aspect` provides `FooInfo`, *or* `BarInfo`, *or* both `BazInfo` *and* `QuxInfo`. |
-| `provides` | default is `[]`  A list of providers that the implementation function must return. It is an error if the implementation function omits any of the types of providers listed here from its return value. However, the implementation function may return additional providers not listed here. Each element of the list is an `*Info` object returned by [`provider()`](../globals/bzl#provider), except that a legacy provider is represented by its string name instead.When a target of the rule is used as a dependency for a target that declares a required provider, it is not necessary to specify that provider here. It is enough that the implementation function returns it. However, it is considered best practice to specify it, even though this is not required. The [`required_providers`](../globals/bzl#aspect.required_providers) field of an [aspect](../globals/bzl#aspect) does, however, require that providers are specified here. |
-| `requires` | [sequence](../core/list) of [Aspect](../builtins/Aspect)s; default is `[]`  List of aspects required to be propagated before this aspect. |
-| `fragments` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  List of names of configuration fragments that the aspect requires in target configuration. |
-| `host_fragments` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  List of names of configuration fragments that the aspect requires in host configuration. |
-| `toolchains` | [sequence](../core/list); default is `[]`  If set, the set of toolchains this rule requires. The list can contain String, Label, or StarlarkToolchainTypeApi objects, in any combination. Toolchains will be found by checking the current platform, and provided to the rule implementation via `ctx.toolchain`. |
+| `provides` | default is `[]`  A list of providers that the implementation function must return. It is an error if the implementation function omits any of the types of providers listed here from its return value. However, the implementation function may return additional providers not listed here. Each element of the list is an `*Info` object returned by [`provider()`](/versions/7.6.1/rules/lib/globals/bzl#provider), except that a legacy provider is represented by its string name instead.When a target of the rule is used as a dependency for a target that declares a required provider, it is not necessary to specify that provider here. It is enough that the implementation function returns it. However, it is considered best practice to specify it, even though this is not required. The [`required_providers`](/versions/7.6.1/rules/lib/globals/bzl#aspect.required_providers) field of an [aspect](/versions/7.6.1/rules/lib/globals/bzl#aspect) does, however, require that providers are specified here. |
+| `requires` | [sequence](/versions/7.6.1/rules/lib/core/list) of [Aspect](/versions/7.6.1/rules/lib/builtins/Aspect)s; default is `[]`  List of aspects required to be propagated before this aspect. |
+| `fragments` | [sequence](/versions/7.6.1/rules/lib/core/list) of [string](/versions/7.6.1/rules/lib/core/string)s; default is `[]`  List of names of configuration fragments that the aspect requires in target configuration. |
+| `host_fragments` | [sequence](/versions/7.6.1/rules/lib/core/list) of [string](/versions/7.6.1/rules/lib/core/string)s; default is `[]`  List of names of configuration fragments that the aspect requires in host configuration. |
+| `toolchains` | [sequence](/versions/7.6.1/rules/lib/core/list); default is `[]`  If set, the set of toolchains this rule requires. The list can contain String, Label, or StarlarkToolchainTypeApi objects, in any combination. Toolchains will be found by checking the current platform, and provided to the rule implementation via `ctx.toolchain`. |
 | `incompatible_use_toolchain_transition` | default is `False`  Deprecated, this is no longer in use and should be removed. |
-| `doc` | [string](../core/string); or `None`; default is `None`  A description of the aspect that can be extracted by documentation generating tools. |
+| `doc` | [string](/versions/7.6.1/rules/lib/core/string); or `None`; default is `None`  A description of the aspect that can be extracted by documentation generating tools. |
 | `apply_to_generating_rules` | default is `False`  If true, the aspect will, when applied to an output file, instead apply to the output file's generating rule. For example, suppose an aspect propagates transitively through attribute `deps` and it is applied to target `alpha`. Suppose `alpha` has `deps = [':beta\_output']`, where `beta\_output` is a declared output of a target `beta`. Suppose `beta` has a target `charlie` as one of its `deps`. If `apply\_to\_generating\_rules=True` for the aspect, then the aspect will propagate through `alpha`, `beta`, and `charlie`. If False, then the aspect will propagate only to `alpha`.  False by default. |
-| `exec_compatible_with` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  A list of constraints on the execution platform that apply to all instances of this aspect. |
-| `exec_groups` | [dict](../core/dict); or `None`; default is `None`  Dict of execution group name (string) to [`exec_group`s](../globals/bzl#exec_group). If set, allows aspects to run actions on multiple execution platforms within a single instance. See [execution groups documentation](/versions/7.6.1/reference/exec-groups) for more info. |
-| `subrules` | [sequence](../core/list) of [Subrule](../builtins/Subrule)s; default is `[]`  Experimental: list of subrules used by this aspect. |
+| `exec_compatible_with` | [sequence](/versions/7.6.1/rules/lib/core/list) of [string](/versions/7.6.1/rules/lib/core/string)s; default is `[]`  A list of constraints on the execution platform that apply to all instances of this aspect. |
+| `exec_groups` | [dict](/versions/7.6.1/rules/lib/core/dict); or `None`; default is `None`  Dict of execution group name (string) to [`exec_group`s](/versions/7.6.1/rules/lib/globals/bzl#exec_group). If set, allows aspects to run actions on multiple execution platforms within a single instance. See [execution groups documentation](/versions/7.6.1/reference/exec-groups) for more info. |
+| `subrules` | [sequence](/versions/7.6.1/rules/lib/core/list) of [Subrule](/versions/7.6.1/rules/lib/builtins/Subrule)s; default is `[]`  Experimental: list of subrules used by this aspect. |
 
 ## configuration\_field
 
@@ -71,7 +71,7 @@ Creates a new aspect. The result of this function must be stored in a global val
 LateBoundDefault configuration_field(fragment, name)
 ```
 
-References a late-bound default value for an attribute of type [label](../toplevel/attr#label). A value is 'late-bound' if it requires the configuration to be built before determining the value. Any attribute using this as a value must [be private](https://bazel.build/versions/7.6.1/extending/rules#private-attributes).
+References a late-bound default value for an attribute of type [label](/versions/7.6.1/rules/lib/toplevel/attr#label). A value is 'late-bound' if it requires the configuration to be built before determining the value. Any attribute using this as a value must [be private](https://bazel.build/versions/7.6.1/extending/rules#private-attributes).
 
 Example usage:
 
@@ -102,7 +102,7 @@ Accessing in rule implementation:
 depset depset(direct=None, order="default", *, transitive=None)
 ```
 
-Creates a [depset](../builtins/depset). The `direct` parameter is a list of direct elements of the depset, and `transitive` parameter is a list of depsets whose elements become indirect elements of the created depset. The order in which elements are returned when the depset is converted to a list is specified by the `order` parameter. See the [Depsets overview](https://bazel.build/versions/7.6.1/extending/depsets) for more information.
+Creates a [depset](/versions/7.6.1/rules/lib/builtins/depset). The `direct` parameter is a list of direct elements of the depset, and `transitive` parameter is a list of depsets whose elements become indirect elements of the created depset. The order in which elements are returned when the depset is converted to a list is specified by the `order` parameter. See the [Depsets overview](https://bazel.build/versions/7.6.1/extending/depsets) for more information.
 
 All elements (direct and indirect) of a depset must be of the same type, as obtained by the expression `type(x)`.
 
@@ -116,9 +116,9 @@ The order of the created depset should be *compatible* with the order of its `tr
 
 | Parameter | Description |
 | --- | --- |
-| `direct` | [sequence](../core/list); or `None`; default is `None`  A list of *direct* elements of a depset. |
-| `order` | default is `"default"`  The traversal strategy for the new depset. See [here](../builtins/depset) for the possible values. |
-| `transitive` | [sequence](../core/list) of [depset](../builtins/depset)s; or `None`; default is `None`  A list of depsets whose elements will become indirect elements of the depset. |
+| `direct` | [sequence](/versions/7.6.1/rules/lib/core/list); or `None`; default is `None`  A list of *direct* elements of a depset. |
+| `order` | default is `"default"`  The traversal strategy for the new depset. See [here](/versions/7.6.1/rules/lib/builtins/depset) for the possible values. |
+| `transitive` | [sequence](/versions/7.6.1/rules/lib/core/list) of [depset](/versions/7.6.1/rules/lib/builtins/depset)s; or `None`; default is `None`  A list of depsets whose elements will become indirect elements of the depset. |
 
 ## exec\_group
 
@@ -132,8 +132,8 @@ Creates an [execution group](/versions/7.6.1/reference/exec-groups) which can be
 
 | Parameter | Description |
 | --- | --- |
-| `toolchains` | [sequence](../core/list); default is `[]`  The set of toolchains this execution group requires. The list can contain String, Label, or StarlarkToolchainTypeApi objects, in any combination. |
-| `exec_compatible_with` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  A list of constraints on the execution platform. |
+| `toolchains` | [sequence](/versions/7.6.1/rules/lib/core/list); default is `[]`  The set of toolchains this execution group requires. The list can contain String, Label, or StarlarkToolchainTypeApi objects, in any combination. |
+| `exec_compatible_with` | [sequence](/versions/7.6.1/rules/lib/core/list) of [string](/versions/7.6.1/rules/lib/core/string)s; default is `[]`  A list of constraints on the execution platform. |
 
 ## module\_extension
 
@@ -149,8 +149,8 @@ Creates a new module extension. Store it in a global value, so that it can be ex
 | --- | --- |
 | `implementation` | required  The function that implements this module extension. Must take a single parameter, `module_ctx`. The function is called once at the beginning of a build to determine the set of available repos. |
 | `tag_classes` | default is `{}`  A dictionary to declare all the tag classes used by the extension. It maps from the name of the tag class to a `tag_class` object. |
-| `doc` | [string](../core/string); or `None`; default is `None`  A description of the module extension that can be extracted by documentation generating tools. |
-| `environ` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  Provides a list of environment variable that this module extension depends on. If an environment variable in that list changes, the extension will be re-evaluated. |
+| `doc` | [string](/versions/7.6.1/rules/lib/core/string); or `None`; default is `None`  A description of the module extension that can be extracted by documentation generating tools. |
+| `environ` | [sequence](/versions/7.6.1/rules/lib/core/list) of [string](/versions/7.6.1/rules/lib/core/string)s; default is `[]`  Provides a list of environment variable that this module extension depends on. If an environment variable in that list changes, the extension will be re-evaluated. |
 | `os_dependent` | default is `False`  Indicates whether this extension is OS-dependent or not |
 | `arch_dependent` | default is `False`  Indicates whether this extension is architecture-dependent or not |
 
@@ -175,16 +175,16 @@ def _my_library_impl(ctx):
 
 See [Rules (Providers)](https://bazel.build/versions/7.6.1/extending/rules#providers) for a comprehensive guide on how to use providers.
 
-Returns a [`Provider`](../builtins/Provider) callable value if `init` is not specified.
+Returns a [`Provider`](/versions/7.6.1/rules/lib/builtins/Provider) callable value if `init` is not specified.
 
-If `init` is specified, returns a tuple of 2 elements: a [`Provider`](../builtins/Provider) callable value and a *raw constructor* callable value. See  [Rules (Custom initialization of custom providers)](https://bazel.build/versions/7.6.1/extending/rules#custom_initialization_of_providers) and the discussion of the `init` parameter below for details.
+If `init` is specified, returns a tuple of 2 elements: a [`Provider`](/versions/7.6.1/rules/lib/builtins/Provider) callable value and a *raw constructor* callable value. See  [Rules (Custom initialization of custom providers)](https://bazel.build/versions/7.6.1/extending/rules#custom_initialization_of_providers) and the discussion of the `init` parameter below for details.
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `doc` | [string](../core/string); or `None`; default is `None` |
-| `fields` | [sequence](../core/list) of [string](../core/string)s; or [dict](../core/dict); or `None`; default is `None`  If specified, restricts the set of allowed fields.  Possible values are:  * list of fields:     ```   provider(fields = ['a', 'b'])   ```     * dictionary field name -> documentation:       ```     provider(            fields = { 'a' : 'Documentation for a', 'b' : 'Documentation for b' })     ```  All fields are optional. |
+| `doc` | [string](/versions/7.6.1/rules/lib/core/string); or `None`; default is `None` |
+| `fields` | [sequence](/versions/7.6.1/rules/lib/core/list) of [string](/versions/7.6.1/rules/lib/core/string)s; or [dict](/versions/7.6.1/rules/lib/core/dict); or `None`; default is `None`  If specified, restricts the set of allowed fields.  Possible values are:  * list of fields:     ```   provider(fields = ['a', 'b'])   ```     * dictionary field name -> documentation:       ```     provider(            fields = { 'a' : 'Documentation for a', 'b' : 'Documentation for b' })     ```  All fields are optional. |
 | `init` | callable; or `None`; default is `None` |
 
 ## repository\_rule
@@ -200,12 +200,12 @@ Creates a new repository rule. Store it in a global value, so that it can be loa
 | Parameter | Description |
 | --- | --- |
 | `implementation` | required |
-| `attrs` | [dict](../core/dict); or `None`; default is `None` |
+| `attrs` | [dict](/versions/7.6.1/rules/lib/core/dict); or `None`; default is `None` |
 | `local` | default is `False`  Indicate that this rule fetches everything from the local system and should be reevaluated at every fetch. |
-| `environ` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  **Deprecated**. This parameter has been deprecated. Migrate to `repository_ctx.getenv` instead. Provides a list of environment variable that this repository rule depends on. If an environment variable in that list change, the repository will be refetched. |
+| `environ` | [sequence](/versions/7.6.1/rules/lib/core/list) of [string](/versions/7.6.1/rules/lib/core/string)s; default is `[]`  **Deprecated**. This parameter has been deprecated. Migrate to `repository_ctx.getenv` instead. Provides a list of environment variable that this repository rule depends on. If an environment variable in that list change, the repository will be refetched. |
 | `configure` | default is `False`  Indicate that the repository inspects the system for configuration purpose |
 | `remotable` | default is `False`  **Experimental**. This parameter is experimental and may change at any time. Please do not depend on it. It may be enabled on an experimental basis by setting `---experimental_repo_remote_exec`  Compatible with remote execution |
-| `doc` | [string](../core/string); or `None`; default is `None` |
+| `doc` | [string](/versions/7.6.1/rules/lib/core/string); or `None`; default is `None` |
 
 ## rule
 
@@ -223,28 +223,28 @@ Test rules are required to have a name ending in `_test`, while all other rules
 
 | Parameter | Description |
 | --- | --- |
-| `implementation` | required  the Starlark function implementing this rule, must have exactly one parameter: [ctx](../builtins/ctx). The function is called during the analysis phase for each instance of the rule. It can access the attributes provided by the user. It must create actions to generate all the declared outputs. |
-| `test` | [bool](../core/bool); default is `unbound`  Whether this rule is a test rule, that is, whether it may be the subject of a `blaze test` command. All test rules are automatically considered [executable](#rule.executable); it is unnecessary (and discouraged) to explicitly set `executable = True` for a test rule. The value defaults to `False`. See the  [Rules page](https://bazel.build/versions/7.6.1/extending/rules#executable_rules_and_test_rules) for more information. |
-| `attrs` | [dict](../core/dict); default is `{}`  dictionary to declare all the attributes of the rule. It maps from an attribute name to an attribute object (see [attr](../toplevel/attr) module). Attributes starting with `_` are private, and can be used to add an implicit dependency on a label. The attribute `name` is implicitly added and must not be specified. Attributes `visibility`, `deprecation`, `tags`, `testonly`, and `features` are implicitly added and cannot be overridden. Most rules need only a handful of attributes. To limit memory usage, the rule function imposes a cap on the size of attrs. |
-| `outputs` | [dict](../core/dict); or `None`; or [function](../core/function); default is `None`  **Deprecated**. This parameter is deprecated and will be removed soon. Please do not depend on it. It is *disabled* with `---incompatible_no_rule_outputs_param`. Use this flag to verify your code is compatible with its imminent removal.  This parameter has been deprecated. Migrate rules to use `OutputGroupInfo` or `attr.output` instead. A schema for defining predeclared outputs. Unlike [`output`](../toplevel/attr#output) and [`output_list`](../toplevel/attr#output_list) attributes, the user does not specify the labels for these files. See the [Rules page](https://bazel.build/versions/7.6.1/extending/rules#files) for more on predeclared outputs. The value of this argument is either a dictionary or a callback function that produces a dictionary. The callback works similar to computed dependency attributes: The function's parameter names are matched against the rule's attributes, so for example if you pass `outputs = _my_func` with the definition `def _my_func(srcs, deps): ...`, the function has access to the attributes `srcs` and `deps`. Whether the dictionary is specified directly or via a function, it is interpreted as follows. Each entry in the dictionary creates a predeclared output where the key is an identifier and the value is a string template that determines the output's label. In the rule's implementation function, the identifier becomes the field name used to access the output's [`File`](../builtins/File) in [`ctx.outputs`](../builtins/ctx#outputs). The output's label has the same package as the rule, and the part after the package is produced by substituting each placeholder of the form `"%{ATTR}"` with a string formed from the value of the attribute `ATTR`:  * String-typed attributes are substituted verbatim.* Label-typed attributes become the part of the label after the package, minus the file extension. For example, the label `"//pkg:a/b.c"` becomes `"a/b"`.* Output-typed attributes become the part of the label after the package, including the file extension (for the above example, `"a/b.c"`).* All list-typed attributes (for example, `attr.label_list`) used in placeholders are required to have *exactly one element*. Their conversion is the same as their non-list version (`attr.label`).* Other attribute types may not appear in placeholders.* The special non-attribute placeholders `%{dirname}` and `%{basename}` expand to those parts of the rule's label, excluding its package. For example, in `"//pkg:a/b.c"`, the dirname is `a` and the basename is `b.c`.   In practice, the most common substitution placeholder is `"%{name}"`. For example, for a target named "foo", the outputs dict `{"bin": "%{name}.exe"}` predeclares an output named `foo.exe` that is accessible in the implementation function as `ctx.outputs.bin`. |
-| `executable` | [bool](../core/bool); default is `unbound` |
+| `implementation` | required  the Starlark function implementing this rule, must have exactly one parameter: [ctx](/versions/7.6.1/rules/lib/builtins/ctx). The function is called during the analysis phase for each instance of the rule. It can access the attributes provided by the user. It must create actions to generate all the declared outputs. |
+| `test` | [bool](/versions/7.6.1/rules/lib/core/bool); default is `unbound`  Whether this rule is a test rule, that is, whether it may be the subject of a `blaze test` command. All test rules are automatically considered [executable](#rule.executable); it is unnecessary (and discouraged) to explicitly set `executable = True` for a test rule. The value defaults to `False`. See the  [Rules page](https://bazel.build/versions/7.6.1/extending/rules#executable_rules_and_test_rules) for more information. |
+| `attrs` | [dict](/versions/7.6.1/rules/lib/core/dict); default is `{}`  dictionary to declare all the attributes of the rule. It maps from an attribute name to an attribute object (see [attr](/versions/7.6.1/rules/lib/toplevel/attr) module). Attributes starting with `_` are private, and can be used to add an implicit dependency on a label. The attribute `name` is implicitly added and must not be specified. Attributes `visibility`, `deprecation`, `tags`, `testonly`, and `features` are implicitly added and cannot be overridden. Most rules need only a handful of attributes. To limit memory usage, the rule function imposes a cap on the size of attrs. |
+| `outputs` | [dict](/versions/7.6.1/rules/lib/core/dict); or `None`; or [function](/versions/7.6.1/rules/lib/core/function); default is `None`  **Deprecated**. This parameter is deprecated and will be removed soon. Please do not depend on it. It is *disabled* with `---incompatible_no_rule_outputs_param`. Use this flag to verify your code is compatible with its imminent removal.  This parameter has been deprecated. Migrate rules to use `OutputGroupInfo` or `attr.output` instead. A schema for defining predeclared outputs. Unlike [`output`](/versions/7.6.1/rules/lib/toplevel/attr#output) and [`output_list`](/versions/7.6.1/rules/lib/toplevel/attr#output_list) attributes, the user does not specify the labels for these files. See the [Rules page](https://bazel.build/versions/7.6.1/extending/rules#files) for more on predeclared outputs. The value of this argument is either a dictionary or a callback function that produces a dictionary. The callback works similar to computed dependency attributes: The function's parameter names are matched against the rule's attributes, so for example if you pass `outputs = _my_func` with the definition `def _my_func(srcs, deps): ...`, the function has access to the attributes `srcs` and `deps`. Whether the dictionary is specified directly or via a function, it is interpreted as follows. Each entry in the dictionary creates a predeclared output where the key is an identifier and the value is a string template that determines the output's label. In the rule's implementation function, the identifier becomes the field name used to access the output's [`File`](/versions/7.6.1/rules/lib/builtins/File) in [`ctx.outputs`](/versions/7.6.1/rules/lib/builtins/ctx#outputs). The output's label has the same package as the rule, and the part after the package is produced by substituting each placeholder of the form `"%{ATTR}"` with a string formed from the value of the attribute `ATTR`:  * String-typed attributes are substituted verbatim.* Label-typed attributes become the part of the label after the package, minus the file extension. For example, the label `"//pkg:a/b.c"` becomes `"a/b"`.* Output-typed attributes become the part of the label after the package, including the file extension (for the above example, `"a/b.c"`).* All list-typed attributes (for example, `attr.label_list`) used in placeholders are required to have *exactly one element*. Their conversion is the same as their non-list version (`attr.label`).* Other attribute types may not appear in placeholders.* The special non-attribute placeholders `%{dirname}` and `%{basename}` expand to those parts of the rule's label, excluding its package. For example, in `"//pkg:a/b.c"`, the dirname is `a` and the basename is `b.c`.   In practice, the most common substitution placeholder is `"%{name}"`. For example, for a target named "foo", the outputs dict `{"bin": "%{name}.exe"}` predeclares an output named `foo.exe` that is accessible in the implementation function as `ctx.outputs.bin`. |
+| `executable` | [bool](/versions/7.6.1/rules/lib/core/bool); default is `unbound` |
 | `output_to_genfiles` | default is `False`  If true, the files will be generated in the genfiles directory instead of the bin directory. Unless you need it for compatibility with existing rules (e.g. when generating header files for C++), do not set this flag. |
-| `fragments` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  List of names of configuration fragments that the rule requires in target configuration. |
-| `host_fragments` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  List of names of configuration fragments that the rule requires in host configuration. |
-| `_skylark_testable` | default is `False`  *(Experimental)*  If true, this rule will expose its actions for inspection by rules that depend on it via an `Actions` provider. The provider is also available to the rule itself by calling [ctx.created\_actions()](../builtins/ctx#created_actions).  This should only be used for testing the analysis-time behavior of Starlark rules. This flag may be removed in the future. |
-| `toolchains` | [sequence](../core/list); default is `[]`  If set, the set of toolchains this rule requires. The list can contain String, Label, or StarlarkToolchainTypeApi objects, in any combination. Toolchains will be found by checking the current platform, and provided to the rule implementation via `ctx.toolchain`. |
+| `fragments` | [sequence](/versions/7.6.1/rules/lib/core/list) of [string](/versions/7.6.1/rules/lib/core/string)s; default is `[]`  List of names of configuration fragments that the rule requires in target configuration. |
+| `host_fragments` | [sequence](/versions/7.6.1/rules/lib/core/list) of [string](/versions/7.6.1/rules/lib/core/string)s; default is `[]`  List of names of configuration fragments that the rule requires in host configuration. |
+| `_skylark_testable` | default is `False`  *(Experimental)*  If true, this rule will expose its actions for inspection by rules that depend on it via an `Actions` provider. The provider is also available to the rule itself by calling [ctx.created\_actions()](/versions/7.6.1/rules/lib/builtins/ctx#created_actions).  This should only be used for testing the analysis-time behavior of Starlark rules. This flag may be removed in the future. |
+| `toolchains` | [sequence](/versions/7.6.1/rules/lib/core/list); default is `[]`  If set, the set of toolchains this rule requires. The list can contain String, Label, or StarlarkToolchainTypeApi objects, in any combination. Toolchains will be found by checking the current platform, and provided to the rule implementation via `ctx.toolchain`. |
 | `incompatible_use_toolchain_transition` | default is `False`  Deprecated, this is no longer in use and should be removed. |
-| `doc` | [string](../core/string); or `None`; default is `None`  A description of the rule that can be extracted by documentation generating tools. |
-| `provides` | default is `[]`  A list of providers that the implementation function must return. It is an error if the implementation function omits any of the types of providers listed here from its return value. However, the implementation function may return additional providers not listed here. Each element of the list is an `*Info` object returned by [`provider()`](../globals/bzl#provider), except that a legacy provider is represented by its string name instead.When a target of the rule is used as a dependency for a target that declares a required provider, it is not necessary to specify that provider here. It is enough that the implementation function returns it. However, it is considered best practice to specify it, even though this is not required. The [`required_providers`](../globals/bzl#aspect.required_providers) field of an [aspect](../globals/bzl#aspect) does, however, require that providers are specified here. |
-| `exec_compatible_with` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  A list of constraints on the execution platform that apply to all targets of this rule type. |
-| `analysis_test` | default is `False`  If true, then this rule is treated as an analysis test. Note: Analysis test rules are primarily defined using infrastructure provided in core Starlark libraries. See [Testing](https://bazel.build/versions/7.6.1/rules/testing#testing-rules) for guidance. If a rule is defined as an analysis test rule, it becomes allowed to use configuration transitions defined using [analysis\_test\_transition](#analysis_test_transition) on its attributes, but opts into some restrictions:  * Targets of this rule are limited in the number of transitive dependencies they may have.* The rule is considered a test rule (as if `test=True` were set). This supersedes the value of `test`   * The rule implementation function may not register actions. Instead, it must register a pass/fail result via providing [AnalysisTestResultInfo](../providers/AnalysisTestResultInfo). |
-| `build_setting` | [BuildSetting](../builtins/BuildSetting); or `None`; default is `None`  If set, describes what kind of [`build setting`](/versions/7.6.1/rules/config#user-defined-build-settings) this rule is. See the [`config`](../toplevel/config) module. If this is set, a mandatory attribute named "build\_setting\_default" is automatically added to this rule, with a type corresponding to the value passed in here. |
+| `doc` | [string](/versions/7.6.1/rules/lib/core/string); or `None`; default is `None`  A description of the rule that can be extracted by documentation generating tools. |
+| `provides` | default is `[]`  A list of providers that the implementation function must return. It is an error if the implementation function omits any of the types of providers listed here from its return value. However, the implementation function may return additional providers not listed here. Each element of the list is an `*Info` object returned by [`provider()`](/versions/7.6.1/rules/lib/globals/bzl#provider), except that a legacy provider is represented by its string name instead.When a target of the rule is used as a dependency for a target that declares a required provider, it is not necessary to specify that provider here. It is enough that the implementation function returns it. However, it is considered best practice to specify it, even though this is not required. The [`required_providers`](/versions/7.6.1/rules/lib/globals/bzl#aspect.required_providers) field of an [aspect](/versions/7.6.1/rules/lib/globals/bzl#aspect) does, however, require that providers are specified here. |
+| `exec_compatible_with` | [sequence](/versions/7.6.1/rules/lib/core/list) of [string](/versions/7.6.1/rules/lib/core/string)s; default is `[]`  A list of constraints on the execution platform that apply to all targets of this rule type. |
+| `analysis_test` | default is `False`  If true, then this rule is treated as an analysis test. Note: Analysis test rules are primarily defined using infrastructure provided in core Starlark libraries. See [Testing](https://bazel.build/versions/7.6.1/rules/testing#testing-rules) for guidance. If a rule is defined as an analysis test rule, it becomes allowed to use configuration transitions defined using [analysis\_test\_transition](#analysis_test_transition) on its attributes, but opts into some restrictions:  * Targets of this rule are limited in the number of transitive dependencies they may have.* The rule is considered a test rule (as if `test=True` were set). This supersedes the value of `test`   * The rule implementation function may not register actions. Instead, it must register a pass/fail result via providing [AnalysisTestResultInfo](/versions/7.6.1/rules/lib/providers/AnalysisTestResultInfo). |
+| `build_setting` | [BuildSetting](/versions/7.6.1/rules/lib/builtins/BuildSetting); or `None`; default is `None`  If set, describes what kind of [`build setting`](/versions/7.6.1/rules/config#user-defined-build-settings) this rule is. See the [`config`](/versions/7.6.1/rules/lib/toplevel/config) module. If this is set, a mandatory attribute named "build\_setting\_default" is automatically added to this rule, with a type corresponding to the value passed in here. |
 | `cfg` | default is `None`  If set, points to the configuration transition the rule will apply to its own configuration before analysis. |
-| `exec_groups` | [dict](../core/dict); or `None`; default is `None`  Dict of execution group name (string) to [`exec_group`s](../globals/bzl#exec_group). If set, allows rules to run actions on multiple execution platforms within a single target. See [execution groups documentation](/versions/7.6.1/reference/exec-groups) for more info. |
+| `exec_groups` | [dict](/versions/7.6.1/rules/lib/core/dict); or `None`; default is `None`  Dict of execution group name (string) to [`exec_group`s](/versions/7.6.1/rules/lib/globals/bzl#exec_group). If set, allows rules to run actions on multiple execution platforms within a single target. See [execution groups documentation](/versions/7.6.1/reference/exec-groups) for more info. |
 | `initializer` | default is `None`  Experimental: the Stalark function initializing the attributes of the rule. The function is called at load time for each instance of the rule. It's called with `name` and the values of public attributes defined bythe rule (not with generic attributes, for example `tags`). It has to return a dictionary from the attribute names to the desired values. The attributes that are not returned are unaffected. Returning `None` as value results in using the default value specified in the attribute definition. Initializers are evaluated before the default values specified in an attribute definition. Consequently, if a parameter in the initializer's signature contains a default values, it overwrites the default from the attribute definition (except if returning `None`). Similarly, if a parameter in the initializer's signature doesn't have a default, the parameter will become mandatory. It's a good practice to omit default/mandatory settings on an attribute definition in such cases. It's a good practice to use `**kwargs` for attributes that are not handled. In case of extended rules, all initializers are called proceeding from child to ancestors. Each initializer is passed only the public attributes it knows about. |
 | `parent` | default is `None`  Experimental: the Stalark rule that is extended. When set the public attributes are merged as well as advertised providers. The rule matches `executable` and `test` from the parent. Values of `fragments`, `toolchains`, `exec_compatible_with`, and `exec_groups` are merged. Legacy or deprecated parameters may not be set. Incoming configuration transition `cfg` of parent is applied after thisrule's incoming configuration. |
-| `extendable` | [bool](../core/bool); or [Label](../builtins/Label); or [string](../core/string); or `None`; default is `None`  Experimental: A label of an allowlist defining which rules can extending this rule. It can be set also to True/False to always allow/disallow extending. Bazel defaults to always allowing extensions. |
-| `subrules` | [sequence](../core/list) of [Subrule](../builtins/Subrule)s; default is `[]`  Experimental: List of subrules used by this rule. |
+| `extendable` | [bool](/versions/7.6.1/rules/lib/core/bool); or [Label](/versions/7.6.1/rules/lib/builtins/Label); or [string](/versions/7.6.1/rules/lib/core/string); or `None`; default is `None`  Experimental: A label of an allowlist defining which rules can extending this rule. It can be set also to True/False to always allow/disallow extending. Bazel defaults to always allowing extensions. |
+| `subrules` | [sequence](/versions/7.6.1/rules/lib/core/list) of [Subrule](/versions/7.6.1/rules/lib/builtins/Subrule)s; default is `[]`  Experimental: List of subrules used by this rule. |
 
 ## select
 
@@ -258,7 +258,7 @@ unknown select(x, no_match_error='')
 
 | Parameter | Description |
 | --- | --- |
-| `x` | required  A dict that maps configuration conditions to values. Each key is a [Label](../builtins/Label) or a label string that identifies a config\_setting or constraint\_value instance. See the [documentation on macros](https://bazel.build/versions/7.6.1/rules/macros#label-resolution) for when to use a Label instead of a string. |
+| `x` | required  A dict that maps configuration conditions to values. Each key is a [Label](/versions/7.6.1/rules/lib/builtins/Label) or a label string that identifies a config\_setting or constraint\_value instance. See the [documentation on macros](https://bazel.build/versions/7.6.1/rules/macros#label-resolution) for when to use a Label instead of a string. |
 | `no_match_error` | default is `''`  Optional custom error to report if no condition matches. |
 
 ## subrule
@@ -273,11 +273,11 @@ Constructs a new instance of a subrule. The result of this function must be stor
 
 | Parameter | Description |
 | --- | --- |
-| `implementation` | [function](../core/function); required  The Starlark function implementing this subrule |
-| `attrs` | [dict](../core/dict); default is `{}`  A dictionary to declare all the (private) attributes of the subrule.  Subrules may only have private attributes that are label-typed (i.e. label or label-list). The resolved values corresponding to these labels are automatically passed by Bazel to the subrule's implementation function as named arguments (thus the implementation function is required to accept named parameters matching the attribute names). The types of these values will be:  * `FilesToRunProvider` for label attributes with `executable=True` * `File` for label attributes with `allow_single_file=True` * `Target` for all other label attributes * `[Target]` for all label-list attributes |
-| `toolchains` | [sequence](../core/list); default is `[]`  If set, the set of toolchains this subrule requires. The list can contain String, Label, or StarlarkToolchainTypeApi objects, in any combination. Toolchains will be found by checking the current platform, and provided to the subrule implementation via `ctx.toolchains`. |
-| `fragments` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  List of names of configuration fragments that the subrule requires in target configuration. |
-| `subrules` | [sequence](../core/list) of [Subrule](../builtins/Subrule)s; default is `[]`  List of other subrules needed by this subrule. |
+| `implementation` | [function](/versions/7.6.1/rules/lib/core/function); required  The Starlark function implementing this subrule |
+| `attrs` | [dict](/versions/7.6.1/rules/lib/core/dict); default is `{}`  A dictionary to declare all the (private) attributes of the subrule.  Subrules may only have private attributes that are label-typed (i.e. label or label-list). The resolved values corresponding to these labels are automatically passed by Bazel to the subrule's implementation function as named arguments (thus the implementation function is required to accept named parameters matching the attribute names). The types of these values will be:  * `FilesToRunProvider` for label attributes with `executable=True` * `File` for label attributes with `allow_single_file=True` * `Target` for all other label attributes * `[Target]` for all label-list attributes |
+| `toolchains` | [sequence](/versions/7.6.1/rules/lib/core/list); default is `[]`  If set, the set of toolchains this subrule requires. The list can contain String, Label, or StarlarkToolchainTypeApi objects, in any combination. Toolchains will be found by checking the current platform, and provided to the subrule implementation via `ctx.toolchains`. |
+| `fragments` | [sequence](/versions/7.6.1/rules/lib/core/list) of [string](/versions/7.6.1/rules/lib/core/string)s; default is `[]`  List of names of configuration fragments that the subrule requires in target configuration. |
+| `subrules` | [sequence](/versions/7.6.1/rules/lib/core/list) of [Subrule](/versions/7.6.1/rules/lib/builtins/Subrule)s; default is `[]`  List of other subrules needed by this subrule. |
 
 ## tag\_class
 
@@ -291,8 +291,8 @@ Creates a new tag\_class object, which defines an attribute schema for a class o
 
 | Parameter | Description |
 | --- | --- |
-| `attrs` | default is `{}`  A dictionary to declare all the attributes of this tag class. It maps from an attribute name to an attribute object (see [attr](../toplevel/attr) module). |
-| `doc` | [string](../core/string); or `None`; default is `None`  A description of the tag class that can be extracted by documentation generating tools. |
+| `attrs` | default is `{}`  A dictionary to declare all the attributes of this tag class. It maps from an attribute name to an attribute object (see [attr](/versions/7.6.1/rules/lib/toplevel/attr) module). |
+| `doc` | [string](/versions/7.6.1/rules/lib/core/string); or `None`; default is `None`  A description of the tag class that can be extracted by documentation generating tools. |
 
 ## visibility
 
diff --git a/versions/7.6.1/rules/lib/globals/module.mdx b/versions/7.6.1/rules/lib/globals/module.mdx
index d03c0350..91dbcc00 100644
--- a/versions/7.6.1/rules/lib/globals/module.mdx
+++ b/versions/7.6.1/rules/lib/globals/module.mdx
@@ -35,11 +35,11 @@ Specifies that this dependency should come from an archive file (zip, gzip, etc)
 | Parameter | Description |
 | --- | --- |
 | `module_name` | required  The name of the Bazel module dependency to apply this override to. |
-| `urls` | [string](../core/string); or Iterable of [string](../core/string)s; required  The URLs of the archive; can be http(s):// or file:// URLs. |
+| `urls` | [string](/versions/7.6.1/rules/lib/core/string); or Iterable of [string](/versions/7.6.1/rules/lib/core/string)s; required  The URLs of the archive; can be http(s):// or file:// URLs. |
 | `integrity` | default is `''`  The expected checksum of the archive file, in Subresource Integrity format. |
 | `strip_prefix` | default is `''`  A directory prefix to strip from the extracted files. |
-| `patches` | Iterable of [string](../core/string)s; default is `[]`  A list of labels pointing to patch files to apply for this module. The patch files must exist in the source tree of the top level project. They are applied in the list order. |
-| `patch_cmds` | Iterable of [string](../core/string)s; default is `[]`  Sequence of Bash commands to be applied on Linux/Macos after patches are applied. |
+| `patches` | Iterable of [string](/versions/7.6.1/rules/lib/core/string)s; default is `[]`  A list of labels pointing to patch files to apply for this module. The patch files must exist in the source tree of the top level project. They are applied in the list order. |
+| `patch_cmds` | Iterable of [string](/versions/7.6.1/rules/lib/core/string)s; default is `[]`  Sequence of Bash commands to be applied on Linux/Macos after patches are applied. |
 | `patch_strip` | default is `0`  Same as the --strip argument of Unix patch. |
 
 ## bazel\_dep
@@ -57,7 +57,7 @@ Declares a direct dependency on another Bazel module.
 | `name` | required  The name of the module to be added as a direct dependency. |
 | `version` | default is `''`  The version of the module to be added as a direct dependency. |
 | `max_compatibility_level` | default is `-1`  The maximum `compatibility_level` supported for the module to be added as a direct dependency. The version of the module implies the minimum compatibility\_level supported, as well as the maximum if this attribute is not specified. |
-| `repo_name` | [string](../core/string); or `None`; default is `''`  The name of the external repo representing this dependency. This is by default the name of the module. Can be set to `None` to make this dependency a "*nodep*" dependency: in this case, this `bazel_dep` specification is only honored if the target module already exists in the dependency graph by some other means. |
+| `repo_name` | [string](/versions/7.6.1/rules/lib/core/string); or `None`; default is `''`  The name of the external repo representing this dependency. This is by default the name of the module. Can be set to `None` to make this dependency a "*nodep*" dependency: in this case, this `bazel_dep` specification is only honored if the target module already exists in the dependency graph by some other means. |
 | `dev_dependency` | default is `False`  If true, this dependency will be ignored if the current module is not the root module or `--ignore_dev_dependency` is enabled. |
 
 ## git\_override
@@ -75,8 +75,8 @@ Specifies that a dependency should come from a certain commit of a Git repositor
 | `module_name` | required  The name of the Bazel module dependency to apply this override to. |
 | `remote` | required  The URL of the remote Git repository. |
 | `commit` | default is `''`  The commit that should be checked out. |
-| `patches` | Iterable of [string](../core/string)s; default is `[]`  A list of labels pointing to patch files to apply for this module. The patch files must exist in the source tree of the top level project. They are applied in the list order. |
-| `patch_cmds` | Iterable of [string](../core/string)s; default is `[]`  Sequence of Bash commands to be applied on Linux/Macos after patches are applied. |
+| `patches` | Iterable of [string](/versions/7.6.1/rules/lib/core/string)s; default is `[]`  A list of labels pointing to patch files to apply for this module. The patch files must exist in the source tree of the top level project. They are applied in the list order. |
+| `patch_cmds` | Iterable of [string](/versions/7.6.1/rules/lib/core/string)s; default is `[]`  Sequence of Bash commands to be applied on Linux/Macos after patches are applied. |
 | `patch_strip` | default is `0`  Same as the --strip argument of Unix patch. |
 | `init_submodules` | default is `False`  Whether git submodules in the fetched repo should be recursively initialized. |
 | `strip_prefix` | default is `''`  A directory prefix to strip from the extracted files. This can be used to target a subdirectory of the git repo. Note that the subdirectory must have its own `MODULE.bazel` file with a module name that is the same as the `module\_name` arg passed to this `git\_override`. |
@@ -155,7 +155,7 @@ It should be called at most once, and if called, it must be the very first direc
 | `version` | default is `''`  The version of the module. Can be omitted only if this module is the root module (as in, if it's not going to be depended on by another module). The version must be in a relaxed SemVer format; see [the documentation](/versions/7.6.1/external/module#version_format) for more details. |
 | `compatibility_level` | default is `0`  The compatibility level of the module; this should be changed every time a major incompatible change is introduced. This is essentially the "major version" of the module in terms of SemVer, except that it's not embedded in the version string itself, but exists as a separate field. Modules with different compatibility levels participate in version resolution as if they're modules with different names, but the final dependency graph cannot contain multiple modules with the same name but different compatibility levels (unless `multiple_version_override` is in effect). See [the documentation](/versions/7.6.1/external/module#compatibility_level) for more details. |
 | `repo_name` | default is `''`  The name of the repository representing this module, as seen by the module itself. By default, the name of the repo is the name of the module. This can be specified to ease migration for projects that have been using a repo name for itself that differs from its module name. |
-| `bazel_compatibility` | Iterable of [string](../core/string)s; default is `[]`  A list of bazel versions that allows users to declare which Bazel versions are compatible with this module. It does NOT affect dependency resolution, but bzlmod will use this information to check if your current Bazel version is compatible. The format of this value is a string of some constraint values separated by comma. Three constraints are supported: <=X.X.X: The Bazel version must be equal or older than X.X.X. Used when there is a known incompatible change in a newer version. >=X.X.X: The Bazel version must be equal or newer than X.X.X.Used when you depend on some features that are only available since X.X.X. -X.X.X: The Bazel version X.X.X is not compatible. Used when there is a bug in X.X.X that breaks you, but fixed in later versions. |
+| `bazel_compatibility` | Iterable of [string](/versions/7.6.1/rules/lib/core/string)s; default is `[]`  A list of bazel versions that allows users to declare which Bazel versions are compatible with this module. It does NOT affect dependency resolution, but bzlmod will use this information to check if your current Bazel version is compatible. The format of this value is a string of some constraint values separated by comma. Three constraints are supported: <=X.X.X: The Bazel version must be equal or older than X.X.X. Used when there is a known incompatible change in a newer version. >=X.X.X: The Bazel version must be equal or newer than X.X.X.Used when you depend on some features that are only available since X.X.X. -X.X.X: The Bazel version X.X.X is not compatible. Used when there is a bug in X.X.X that breaks you, but fixed in later versions. |
 
 ## multiple\_version\_override
 
@@ -170,7 +170,7 @@ Specifies that a dependency should still come from a registry, but multiple vers
 | Parameter | Description |
 | --- | --- |
 | `module_name` | required  The name of the Bazel module dependency to apply this override to. |
-| `versions` | Iterable of [string](../core/string)s; required  Explicitly specifies the versions allowed to coexist. These versions must already be present in the dependency graph pre-selection. Dependencies on this module will be "upgraded" to the nearest higher allowed version at the same compatibility level, whereas dependencies that have a higher version than any allowed versions at the same compatibility level will cause an error. |
+| `versions` | Iterable of [string](/versions/7.6.1/rules/lib/core/string)s; required  Explicitly specifies the versions allowed to coexist. These versions must already be present in the dependency graph pre-selection. Dependencies on this module will be "upgraded" to the nearest higher allowed version at the same compatibility level, whereas dependencies that have a higher version than any allowed versions at the same compatibility level will cause an error. |
 | `registry` | default is `''`  Overrides the registry for this module; instead of finding this module from the default list of registries, the given registry should be used. |
 
 ## override\_repo
@@ -206,7 +206,7 @@ Specifies already-defined execution platforms to be registered when this module
 | Parameter | Description |
 | --- | --- |
 | `dev_dependency` | default is `False`  If true, the execution platforms will not be registered if the current module is not the root module or `--ignore\_dev\_dependency` is enabled. |
-| `platform_labels` | [sequence](../core/list) of [string](../core/string)s; required  The labels of the platforms to register. |
+| `platform_labels` | [sequence](/versions/7.6.1/rules/lib/core/list) of [string](/versions/7.6.1/rules/lib/core/string)s; required  The labels of the platforms to register. |
 
 ## register\_toolchains
 
@@ -221,7 +221,7 @@ Specifies already-defined toolchains to be registered when this module is select
 | Parameter | Description |
 | --- | --- |
 | `dev_dependency` | default is `False`  If true, the toolchains will not be registered if the current module is not the root module or `--ignore\_dev\_dependency` is enabled. |
-| `toolchain_labels` | [sequence](../core/list) of [string](../core/string)s; required  The labels of the toolchains to register. Labels can include `:all`, in which case, all toolchain-providing targets in the package will be registered in lexicographical order by name. |
+| `toolchain_labels` | [sequence](/versions/7.6.1/rules/lib/core/list) of [string](/versions/7.6.1/rules/lib/core/string)s; required  The labels of the toolchains to register. Labels can include `:all`, in which case, all toolchain-providing targets in the package will be registered in lexicographical order by name. |
 
 ## single\_version\_override
 
@@ -238,8 +238,8 @@ Specifies that a dependency should still come from a registry, but its version s
 | `module_name` | required  The name of the Bazel module dependency to apply this override to. |
 | `version` | default is `''`  Overrides the declared version of this module in the dependency graph. In other words, this module will be "pinned" to this override version. This attribute can be omitted if all one wants to override is the registry or the patches. |
 | `registry` | default is `''`  Overrides the registry for this module; instead of finding this module from the default list of registries, the given registry should be used. |
-| `patches` | Iterable of [string](../core/string)s; default is `[]`  A list of labels pointing to patch files to apply for this module. The patch files must exist in the source tree of the top level project. They are applied in the list order. If a patch makes changes to the MODULE.bazel file, these changes will only be effective if the patch file is provided by the root module. |
-| `patch_cmds` | Iterable of [string](../core/string)s; default is `[]`  Sequence of Bash commands to be applied on Linux/Macos after patches are applied. Changes to the MODULE.bazel file will not be effective. |
+| `patches` | Iterable of [string](/versions/7.6.1/rules/lib/core/string)s; default is `[]`  A list of labels pointing to patch files to apply for this module. The patch files must exist in the source tree of the top level project. They are applied in the list order. If a patch makes changes to the MODULE.bazel file, these changes will only be effective if the patch file is provided by the root module. |
+| `patch_cmds` | Iterable of [string](/versions/7.6.1/rules/lib/core/string)s; default is `[]`  Sequence of Bash commands to be applied on Linux/Macos after patches are applied. Changes to the MODULE.bazel file will not be effective. |
 | `patch_strip` | default is `0`  Same as the --strip argument of Unix patch. |
 
 ## use\_extension
diff --git a/versions/7.6.1/rules/lib/globals/workspace.mdx b/versions/7.6.1/rules/lib/globals/workspace.mdx
index 68db7e08..48fe0c8d 100644
--- a/versions/7.6.1/rules/lib/globals/workspace.mdx
+++ b/versions/7.6.1/rules/lib/globals/workspace.mdx
@@ -26,7 +26,7 @@ Gives a target an alias in the `//external` package.
 | Parameter | Description |
 | --- | --- |
 | `name` | required  The label under '//external' to serve as the alias name |
-| `actual` | [string](../core/string); or `None`; default is `None`  The real label to be aliased |
+| `actual` | [string](/versions/7.6.1/rules/lib/core/string); or `None`; default is `None`  The real label to be aliased |
 
 ## register\_execution\_platforms
 
@@ -40,7 +40,7 @@ Register an already-defined platform so that Bazel can use it as an [execution p
 
 | Parameter | Description |
 | --- | --- |
-| `platform_labels` | [sequence](../core/list) of [string](../core/string)s; required  The labels of the platforms to register. |
+| `platform_labels` | [sequence](/versions/7.6.1/rules/lib/core/list) of [string](/versions/7.6.1/rules/lib/core/string)s; required  The labels of the platforms to register. |
 
 ## register\_toolchains
 
@@ -54,7 +54,7 @@ Register an already-defined toolchain so that Bazel can use it during [toolchain
 
 | Parameter | Description |
 | --- | --- |
-| `toolchain_labels` | [sequence](../core/list) of [string](../core/string)s; required  The labels of the toolchains to register. Labels can include `:all`, in which case, all toolchain-providing targets in the package will be registered in lexicographical order by name. |
+| `toolchain_labels` | [sequence](/versions/7.6.1/rules/lib/core/list) of [string](/versions/7.6.1/rules/lib/core/string)s; required  The labels of the toolchains to register. Labels can include `:all`, in which case, all toolchain-providing targets in the package will be registered in lexicographical order by name. |
 
 ## workspace
 
diff --git a/versions/7.6.1/rules/lib/providers/AndroidNeverLinkLibrariesProvider.mdx b/versions/7.6.1/rules/lib/providers/AndroidNeverLinkLibrariesProvider.mdx
index ca808cd9..d0033051 100644
--- a/versions/7.6.1/rules/lib/providers/AndroidNeverLinkLibrariesProvider.mdx
+++ b/versions/7.6.1/rules/lib/providers/AndroidNeverLinkLibrariesProvider.mdx
@@ -22,7 +22,7 @@ The `AndroidNeverLinkLibrariesProvider` constructor.
 
 | Parameter | Description |
 | --- | --- |
-| `transitive_neverlink_libraries` | [depset](../builtins/depset) of [File](../builtins/File)s; required  The transitive neverlink libraries |
+| `transitive_neverlink_libraries` | [depset](/versions/7.6.1/rules/lib/builtins/depset) of [File](/versions/7.6.1/rules/lib/builtins/File)s; required  The transitive neverlink libraries |
 
 ## to\_json
 
diff --git a/versions/7.6.1/rules/lib/providers/BaselineProfileProvider.mdx b/versions/7.6.1/rules/lib/providers/BaselineProfileProvider.mdx
index 218f8070..d42a0686 100644
--- a/versions/7.6.1/rules/lib/providers/BaselineProfileProvider.mdx
+++ b/versions/7.6.1/rules/lib/providers/BaselineProfileProvider.mdx
@@ -22,8 +22,8 @@ The `BaselineProfileProvider` constructor.
 
 | Parameter | Description |
 | --- | --- |
-| `files` | [depset](../builtins/depset) of [File](../builtins/File)s; required  Transitive baseline profile files. |
-| `art_profile_zip` | [File](../builtins/File); or `None`; default is `None`  The final ART profile zip to be packaged in the APK. Optional, only used for migration purposes. |
+| `files` | [depset](/versions/7.6.1/rules/lib/builtins/depset) of [File](/versions/7.6.1/rules/lib/builtins/File)s; required  Transitive baseline profile files. |
+| `art_profile_zip` | [File](/versions/7.6.1/rules/lib/builtins/File); or `None`; default is `None`  The final ART profile zip to be packaged in the APK. Optional, only used for migration purposes. |
 
 ## to\_json
 
diff --git a/versions/7.6.1/rules/lib/providers/CcInfo.mdx b/versions/7.6.1/rules/lib/providers/CcInfo.mdx
index 3fc10b7d..8b22b425 100644
--- a/versions/7.6.1/rules/lib/providers/CcInfo.mdx
+++ b/versions/7.6.1/rules/lib/providers/CcInfo.mdx
@@ -24,8 +24,8 @@ The `CcInfo` constructor.
 
 | Parameter | Description |
 | --- | --- |
-| `compilation_context` | [CompilationContext](../builtins/CompilationContext); or `None`; default is `None`  The `CompilationContext`. |
-| `linking_context` | [LinkingContext](../builtins/LinkingContext); or `None`; default is `None`  The `LinkingContext`. |
+| `compilation_context` | [CompilationContext](/versions/7.6.1/rules/lib/builtins/CompilationContext); or `None`; default is `None`  The `CompilationContext`. |
+| `linking_context` | [LinkingContext](/versions/7.6.1/rules/lib/builtins/LinkingContext); or `None`; default is `None`  The `LinkingContext`. |
 | `debug_context` | DebugContext; or `None`; default is `None`  The `DebugContext`. |
 
 ## compilation\_context
diff --git a/versions/7.6.1/rules/lib/providers/DebugPackageInfo.mdx b/versions/7.6.1/rules/lib/providers/DebugPackageInfo.mdx
index 0e37850f..43000ad1 100644
--- a/versions/7.6.1/rules/lib/providers/DebugPackageInfo.mdx
+++ b/versions/7.6.1/rules/lib/providers/DebugPackageInfo.mdx
@@ -27,9 +27,9 @@ The `DebugPackageInfo` constructor.
 | Parameter | Description |
 | --- | --- |
 | `target_label` | required  The label for the \*\_binary target |
-| `stripped_file` | [File](../builtins/File); or `None`; default is `None`  The stripped file (the explicit ".stripped" target) |
+| `stripped_file` | [File](/versions/7.6.1/rules/lib/builtins/File); or `None`; default is `None`  The stripped file (the explicit ".stripped" target) |
 | `unstripped_file` | required  The unstripped file (the default executable target). |
-| `dwp_file` | [File](../builtins/File); or `None`; default is `None`  The .dwp file (for fission builds) or null if --fission=no. |
+| `dwp_file` | [File](/versions/7.6.1/rules/lib/builtins/File); or `None`; default is `None`  The .dwp file (for fission builds) or null if --fission=no. |
 
 ## dwp\_file
 
diff --git a/versions/7.6.1/rules/lib/providers/DefaultInfo.mdx b/versions/7.6.1/rules/lib/providers/DefaultInfo.mdx
index fd7c655c..31f6bc2b 100644
--- a/versions/7.6.1/rules/lib/providers/DefaultInfo.mdx
+++ b/versions/7.6.1/rules/lib/providers/DefaultInfo.mdx
@@ -30,11 +30,11 @@ The `DefaultInfo` constructor.
 
 | Parameter | Description |
 | --- | --- |
-| `files` | [depset](../builtins/depset); or `None`; default is `None`  A [`depset`](../builtins/depset) of [`File`](../builtins/File) objects representing the default outputs to build when this target is specified on the bazel command line. By default it is all predeclared outputs. |
-| `runfiles` | [runfiles](../builtins/runfiles); or `None`; default is `None`  runfiles descriptor describing the files that this target needs when run (via the `run` command or as a tool dependency). |
-| `data_runfiles` | [runfiles](../builtins/runfiles); or `None`; default is `None`  **It is recommended that you avoid using this parameter (see ["runfiles features to avoid"](https://bazel.build/versions/7.6.1/extending/rules#runfiles_features_to_avoid))** runfiles descriptor describing the runfiles this target needs to run when it is a dependency via the `data` attribute. |
-| `default_runfiles` | [runfiles](../builtins/runfiles); or `None`; default is `None`  **It is recommended that you avoid using this parameter (see ["runfiles features to avoid"](https://bazel.build/versions/7.6.1/extending/rules#runfiles_features_to_avoid))** runfiles descriptor describing the runfiles this target needs to run when it is a dependency via any attribute other than the `data` attribute. |
-| `executable` | [File](../builtins/File); or `None`; default is `None`  If this rule is marked [`executable`](../globals/bzl#rule.executable) or [`test`](../globals/bzl#rule.test), this is a [`File`](../builtins/File) object representing the file that should be executed to run the target. By default it is the predeclared output `ctx.outputs.executable`. |
+| `files` | [depset](/versions/7.6.1/rules/lib/builtins/depset); or `None`; default is `None`  A [`depset`](/versions/7.6.1/rules/lib/builtins/depset) of [`File`](/versions/7.6.1/rules/lib/builtins/File) objects representing the default outputs to build when this target is specified on the bazel command line. By default it is all predeclared outputs. |
+| `runfiles` | [runfiles](/versions/7.6.1/rules/lib/builtins/runfiles); or `None`; default is `None`  runfiles descriptor describing the files that this target needs when run (via the `run` command or as a tool dependency). |
+| `data_runfiles` | [runfiles](/versions/7.6.1/rules/lib/builtins/runfiles); or `None`; default is `None`  **It is recommended that you avoid using this parameter (see ["runfiles features to avoid"](https://bazel.build/versions/7.6.1/extending/rules#runfiles_features_to_avoid))** runfiles descriptor describing the runfiles this target needs to run when it is a dependency via the `data` attribute. |
+| `default_runfiles` | [runfiles](/versions/7.6.1/rules/lib/builtins/runfiles); or `None`; default is `None`  **It is recommended that you avoid using this parameter (see ["runfiles features to avoid"](https://bazel.build/versions/7.6.1/extending/rules#runfiles_features_to_avoid))** runfiles descriptor describing the runfiles this target needs to run when it is a dependency via any attribute other than the `data` attribute. |
+| `executable` | [File](/versions/7.6.1/rules/lib/builtins/File); or `None`; default is `None`  If this rule is marked [`executable`](/versions/7.6.1/rules/lib/globals/bzl#rule.executable) or [`test`](/versions/7.6.1/rules/lib/globals/bzl#rule.test), this is a [`File`](/versions/7.6.1/rules/lib/builtins/File) object representing the file that should be executed to run the target. By default it is the predeclared output `ctx.outputs.executable`. |
 
 ## data\_runfiles
 
@@ -60,7 +60,7 @@ May return `None`.
 depset DefaultInfo.files
 ```
 
-A [`depset`](../builtins/depset) of [`File`](../builtins/File) objects representing the default outputs to build when this target is specified on the bazel command line. By default it is all predeclared outputs.
+A [`depset`](/versions/7.6.1/rules/lib/builtins/depset) of [`File`](/versions/7.6.1/rules/lib/builtins/File) objects representing the default outputs to build when this target is specified on the bazel command line. By default it is all predeclared outputs.
 May return `None`.
 
 ## files\_to\_run
@@ -69,7 +69,7 @@ May return `None`.
 FilesToRunProvider DefaultInfo.files_to_run
 ```
 
-A [`FilesToRunProvider`](../providers/FilesToRunProvider) object containing information about the executable and runfiles of the target.
+A [`FilesToRunProvider`](/versions/7.6.1/rules/lib/providers/FilesToRunProvider) object containing information about the executable and runfiles of the target.
 May return `None`.
 
 ## to\_json
diff --git a/versions/7.6.1/rules/lib/providers/ExecutionInfo.mdx b/versions/7.6.1/rules/lib/providers/ExecutionInfo.mdx
index 995804e5..9df23381 100644
--- a/versions/7.6.1/rules/lib/providers/ExecutionInfo.mdx
+++ b/versions/7.6.1/rules/lib/providers/ExecutionInfo.mdx
@@ -24,8 +24,8 @@ Creates an instance.
 
 | Parameter | Description |
 | --- | --- |
-| `requirements` | [dict](../core/dict); default is `{}`  A dict indicating special execution requirements, such as hardware platforms. |
-| `exec_group` | [string](../core/string); default is `'test'`  The name of the exec group that is used to execute the test. |
+| `requirements` | [dict](/versions/7.6.1/rules/lib/core/dict); default is `{}`  A dict indicating special execution requirements, such as hardware platforms. |
+| `exec_group` | [string](/versions/7.6.1/rules/lib/core/string); default is `'test'`  The name of the exec group that is used to execute the test. |
 
 ## exec\_group
 
diff --git a/versions/7.6.1/rules/lib/providers/GeneratedExtensionRegistryProvider.mdx b/versions/7.6.1/rules/lib/providers/GeneratedExtensionRegistryProvider.mdx
index f4be6e55..f4836e38 100644
--- a/versions/7.6.1/rules/lib/providers/GeneratedExtensionRegistryProvider.mdx
+++ b/versions/7.6.1/rules/lib/providers/GeneratedExtensionRegistryProvider.mdx
@@ -26,7 +26,7 @@ The `GeneratedExtensionRegistryProvider` constructor.
 | `isLite` | required  If this registry was generated for lite or full runtime |
 | `classJar` | required  Class jar generated by the registry |
 | `srcJar` | required  Source jar generated by the registry |
-| `inputs` | [depset](../builtins/depset) of [File](../builtins/File)s; required  Proto jars used to generate the registry |
+| `inputs` | [depset](/versions/7.6.1/rules/lib/builtins/depset) of [File](/versions/7.6.1/rules/lib/builtins/File)s; required  Proto jars used to generate the registry |
 
 ## to\_json
 
diff --git a/versions/7.6.1/rules/lib/providers/InstrumentedFilesInfo.mdx b/versions/7.6.1/rules/lib/providers/InstrumentedFilesInfo.mdx
index f285fefd..85f66d9d 100644
--- a/versions/7.6.1/rules/lib/providers/InstrumentedFilesInfo.mdx
+++ b/versions/7.6.1/rules/lib/providers/InstrumentedFilesInfo.mdx
@@ -17,7 +17,7 @@ Contains information about source files and instrumentation metadata files for r
 depset InstrumentedFilesInfo.instrumented_files
 ```
 
-[`depset`](../builtins/depset) of [`File`](../builtins/File) objects representing instrumented source files for this target and its dependencies.
+[`depset`](/versions/7.6.1/rules/lib/builtins/depset) of [`File`](/versions/7.6.1/rules/lib/builtins/File) objects representing instrumented source files for this target and its dependencies.
 
 ## metadata\_files
 
@@ -25,7 +25,7 @@ depset InstrumentedFilesInfo.instrumented_files
 depset InstrumentedFilesInfo.metadata_files
 ```
 
-[`depset`](../builtins/depset) of [`File`](../builtins/File) objects representing coverage metadata files for this target and its dependencies. These files contain additional information required to generate LCOV-format coverage output after the code is executed, e.g. the `.gcno` files generated when `gcc` is run with `-ftest-coverage`.
+[`depset`](/versions/7.6.1/rules/lib/builtins/depset) of [`File`](/versions/7.6.1/rules/lib/builtins/File) objects representing coverage metadata files for this target and its dependencies. These files contain additional information required to generate LCOV-format coverage output after the code is executed, e.g. the `.gcno` files generated when `gcc` is run with `-ftest-coverage`.
 
 ## to\_json
 
diff --git a/versions/7.6.1/rules/lib/providers/PackageSpecificationInfo.mdx b/versions/7.6.1/rules/lib/providers/PackageSpecificationInfo.mdx
index 81cc8393..dc47d983 100644
--- a/versions/7.6.1/rules/lib/providers/PackageSpecificationInfo.mdx
+++ b/versions/7.6.1/rules/lib/providers/PackageSpecificationInfo.mdx
@@ -22,7 +22,7 @@ Checks if a target exists in a package group.
 
 | Parameter | Description |
 | --- | --- |
-| `target` | [Label](../builtins/Label); or [string](../core/string); required  A target which is checked if it exists inside the package group. |
+| `target` | [Label](/versions/7.6.1/rules/lib/builtins/Label); or [string](/versions/7.6.1/rules/lib/core/string); required  A target which is checked if it exists inside the package group. |
 
 ## to\_json
 
diff --git a/versions/7.6.1/rules/lib/providers/ProguardSpecProvider.mdx b/versions/7.6.1/rules/lib/providers/ProguardSpecProvider.mdx
index aaf4489b..25187d38 100644
--- a/versions/7.6.1/rules/lib/providers/ProguardSpecProvider.mdx
+++ b/versions/7.6.1/rules/lib/providers/ProguardSpecProvider.mdx
@@ -22,7 +22,7 @@ The `ProguardSpecProvider` constructor.
 
 | Parameter | Description |
 | --- | --- |
-| `specs` | [depset](../builtins/depset) of [File](../builtins/File)s; required  Transitive proguard specs. |
+| `specs` | [depset](/versions/7.6.1/rules/lib/builtins/depset) of [File](/versions/7.6.1/rules/lib/builtins/File)s; required  Transitive proguard specs. |
 
 ## to\_json
 
diff --git a/versions/7.6.1/rules/lib/providers/PyInfo.mdx b/versions/7.6.1/rules/lib/providers/PyInfo.mdx
index 0be19970..72bc9a14 100644
--- a/versions/7.6.1/rules/lib/providers/PyInfo.mdx
+++ b/versions/7.6.1/rules/lib/providers/PyInfo.mdx
@@ -25,9 +25,9 @@ The `PyInfo` constructor.
 
 | Parameter | Description |
 | --- | --- |
-| `transitive_sources` | [depset](../builtins/depset) of [File](../builtins/File)s; required  The value for the new object's `transitive_sources` field. |
+| `transitive_sources` | [depset](/versions/7.6.1/rules/lib/builtins/depset) of [File](/versions/7.6.1/rules/lib/builtins/File)s; required  The value for the new object's `transitive_sources` field. |
 | `uses_shared_libraries` | default is `False`  The value for the new object's `uses_shared_libraries` field. |
-| `imports` | [depset](../builtins/depset) of [string](../core/string)s; default is `unbound`  The value for the new object's `imports` field. |
+| `imports` | [depset](/versions/7.6.1/rules/lib/builtins/depset) of [string](/versions/7.6.1/rules/lib/core/string)s; default is `unbound`  The value for the new object's `imports` field. |
 | `has_py2_only_sources` | default is `False`  The value for the new object's `has_py2_only_sources` field. |
 | `has_py3_only_sources` | default is `False`  The value for the new object's `has_py3_only_sources` field. |
 
diff --git a/versions/7.6.1/rules/lib/providers/PyRuntimeInfo.mdx b/versions/7.6.1/rules/lib/providers/PyRuntimeInfo.mdx
index a0d58f4c..c39c1670 100644
--- a/versions/7.6.1/rules/lib/providers/PyRuntimeInfo.mdx
+++ b/versions/7.6.1/rules/lib/providers/PyRuntimeInfo.mdx
@@ -30,14 +30,14 @@ The `PyRuntimeInfo` constructor.
 
 | Parameter | Description |
 | --- | --- |
-| `interpreter_path` | [string](../core/string); or `None`; default is `None`  The value for the new object's `interpreter_path` field. Do not give a value for this argument if you pass in `interpreter`. |
-| `interpreter` | [File](../builtins/File); or `None`; default is `None`  The value for the new object's `interpreter` field. Do not give a value for this argument if you pass in `interpreter_path`. |
-| `files` | [depset](../builtins/depset) of [File](../builtins/File)s; or `None`; default is `None`  The value for the new object's `files` field. Do not give a value for this argument if you pass in `interpreter_path`. If `interpreter` is given and this argument is `None`, `files` becomes an empty `depset` instead. |
-| `coverage_tool` | [File](../builtins/File); or `None`; default is `None`  The value for the new object's `coverage_tool` field. |
-| `coverage_files` | [depset](../builtins/depset) of [File](../builtins/File)s; or `None`; default is `None`  The value for the new object's `coverage_files` field. Do not give a value for this argument if you do not also pass in `coverage_tool`. |
+| `interpreter_path` | [string](/versions/7.6.1/rules/lib/core/string); or `None`; default is `None`  The value for the new object's `interpreter_path` field. Do not give a value for this argument if you pass in `interpreter`. |
+| `interpreter` | [File](/versions/7.6.1/rules/lib/builtins/File); or `None`; default is `None`  The value for the new object's `interpreter` field. Do not give a value for this argument if you pass in `interpreter_path`. |
+| `files` | [depset](/versions/7.6.1/rules/lib/builtins/depset) of [File](/versions/7.6.1/rules/lib/builtins/File)s; or `None`; default is `None`  The value for the new object's `files` field. Do not give a value for this argument if you pass in `interpreter_path`. If `interpreter` is given and this argument is `None`, `files` becomes an empty `depset` instead. |
+| `coverage_tool` | [File](/versions/7.6.1/rules/lib/builtins/File); or `None`; default is `None`  The value for the new object's `coverage_tool` field. |
+| `coverage_files` | [depset](/versions/7.6.1/rules/lib/builtins/depset) of [File](/versions/7.6.1/rules/lib/builtins/File)s; or `None`; default is `None`  The value for the new object's `coverage_files` field. Do not give a value for this argument if you do not also pass in `coverage_tool`. |
 | `python_version` | required  The value for the new object's `python_version` field. |
-| `stub_shebang` | [string](../core/string); default is `None`  The value for the new object's `stub_shebang` field. If None or not specified, `#!/usr/bin/env python3` is used. |
-| `bootstrap_template` | [File](../builtins/File); or `None`; default is `None` |
+| `stub_shebang` | [string](/versions/7.6.1/rules/lib/core/string); default is `None`  The value for the new object's `stub_shebang` field. If None or not specified, `#!/usr/bin/env python3` is used. |
+| `bootstrap_template` | [File](/versions/7.6.1/rules/lib/builtins/File); or `None`; default is `None` |
 
 ## bootstrap\_template
 
diff --git a/versions/7.6.1/rules/lib/repo/index.mdx b/versions/7.6.1/rules/lib/repo/index.mdx
index 8b364d2d..d717955c 100644
--- a/versions/7.6.1/rules/lib/repo/index.mdx
+++ b/versions/7.6.1/rules/lib/repo/index.mdx
@@ -2,10 +2,10 @@
 title: 'Repository Rules'
 ---
 
-* [Rules related to git](git)
-* [Rules related to http](http)
-* [Rules related to local directories](local)
+* [Rules related to git](/versions/7.6.1/rules/lib/repo/git)
+* [Rules related to http](/versions/7.6.1/rules/lib/repo/http)
+* [Rules related to local directories](/versions/7.6.1/rules/lib/repo/local)
 
 # Generic functions for repository rule authors
 
-* [Utility functions on patching](utils)
+* [Utility functions on patching](/versions/7.6.1/rules/lib/repo/utils)
diff --git a/versions/7.6.1/rules/lib/toplevel/apple_common.mdx b/versions/7.6.1/rules/lib/toplevel/apple_common.mdx
index 22178396..053714cf 100644
--- a/versions/7.6.1/rules/lib/toplevel/apple_common.mdx
+++ b/versions/7.6.1/rules/lib/toplevel/apple_common.mdx
@@ -30,7 +30,7 @@ Functions for Starlark to access internals of the apple rule implementations.
 dict apple_common.apple_host_system_env(xcode_config)
 ```
 
-Returns a [dict](../core/dict) of environment variables that should be set for actions that need to run build tools on an Apple host system, such as the version of Xcode that should be used. The keys are variable names and the values are their corresponding values.
+Returns a [dict](/versions/7.6.1/rules/lib/core/dict) of environment variables that should be set for actions that need to run build tools on an Apple host system, such as the version of Xcode that should be used. The keys are variable names and the values are their corresponding values.
 
 ### Parameters
 
@@ -97,7 +97,7 @@ p = dep[apple_common.AppleExecutableBinary]
 DottedVersion apple_common.dotted_version(version)
 ```
 
-Creates a new [DottedVersion](../builtins/DottedVersion) instance.
+Creates a new [DottedVersion](/versions/7.6.1/rules/lib/builtins/DottedVersion) instance.
 
 ### Parameters
 
@@ -120,11 +120,11 @@ This API is **highly experimental** and subject to change at any time. Do not de
 | Parameter | Description |
 | --- | --- |
 | `ctx` | required |
-| `avoid_deps` | [sequence](../core/list) of [Target](../builtins/Target)s; or `None`; default is `None` |
-| `extra_linkopts` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  Extra linkopts to be passed to the linker action. |
-| `extra_link_inputs` | [sequence](../core/list) of [File](../builtins/File)s; default is `[]`  Extra files to pass to the linker action. |
-| `extra_requested_features` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  Extra requested features to be passed to the linker action. |
-| `extra_disabled_features` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  Extra disabled features to be passed to the linker action. |
+| `avoid_deps` | [sequence](/versions/7.6.1/rules/lib/core/list) of [Target](/versions/7.6.1/rules/lib/builtins/Target)s; or `None`; default is `None` |
+| `extra_linkopts` | [sequence](/versions/7.6.1/rules/lib/core/list) of [string](/versions/7.6.1/rules/lib/core/string)s; default is `[]`  Extra linkopts to be passed to the linker action. |
+| `extra_link_inputs` | [sequence](/versions/7.6.1/rules/lib/core/list) of [File](/versions/7.6.1/rules/lib/builtins/File)s; default is `[]`  Extra files to pass to the linker action. |
+| `extra_requested_features` | [sequence](/versions/7.6.1/rules/lib/core/list) of [string](/versions/7.6.1/rules/lib/core/string)s; default is `[]`  Extra requested features to be passed to the linker action. |
+| `extra_disabled_features` | [sequence](/versions/7.6.1/rules/lib/core/list) of [string](/versions/7.6.1/rules/lib/core/string)s; default is `[]`  Extra disabled features to be passed to the linker action. |
 | `stamp` | default is `-1`  Whether to include build information in the linked binary. If 1, build information is always included. If 0, build information is always excluded. If -1 (the default), then the behavior is determined by the --[no]stamp flag. This should be set to 0 when generating the executable output for test rules. |
 
 ## link\_multi\_arch\_static\_library
@@ -155,11 +155,11 @@ Creates a new AppleDynamicFramework provider instance.
 
 | Parameter | Description |
 | --- | --- |
-| `binary` | [File](../builtins/File); or `None`; default is `None`  The dylib binary artifact of the dynamic framework. |
+| `binary` | [File](/versions/7.6.1/rules/lib/builtins/File); or `None`; default is `None`  The dylib binary artifact of the dynamic framework. |
 | `cc_info` | default is `None`  A CcInfo which contains information about the transitive dependencies linked into the binary. |
 | `objc` | default is `None`  An ObjcProvider which contains information about the transitive dependencies linked into the binary. |
-| `framework_dirs` | [depset](../builtins/depset) of [string](../core/string)s; or `None`; default is `None`  The framework path names used as link inputs in order to link against the dynamic framework. |
-| `framework_files` | [depset](../builtins/depset) of [File](../builtins/File)s; or `None`; default is `None`  The full set of artifacts that should be included as inputs to link against the dynamic framework |
+| `framework_dirs` | [depset](/versions/7.6.1/rules/lib/builtins/depset) of [string](/versions/7.6.1/rules/lib/core/string)s; or `None`; default is `None`  The framework path names used as link inputs in order to link against the dynamic framework. |
+| `framework_files` | [depset](/versions/7.6.1/rules/lib/builtins/depset) of [File](/versions/7.6.1/rules/lib/builtins/File)s; or `None`; default is `None`  The full set of artifacts that should be included as inputs to link against the dynamic framework |
 
 ## new\_executable\_binary\_provider
 
@@ -173,7 +173,7 @@ Creates a new AppleExecutableBinaryInfo provider instance.
 
 | Parameter | Description |
 | --- | --- |
-| `binary` | [File](../builtins/File); or `None`; default is `None`  The binary artifact of the executable. |
+| `binary` | [File](/versions/7.6.1/rules/lib/builtins/File); or `None`; default is `None`  The binary artifact of the executable. |
 | `cc_info` | default is `None`  A CcInfo which contains information about the transitive dependencies linked into the binary. |
 | `objc` | default is `None`  An ObjcProvider which contains information about the transitive dependencies linked into the binary. |
 
@@ -224,7 +224,7 @@ An enum-like struct that contains the following fields corresponding to Apple pl
 * `watchos_device`
 * `watchos_simulator`
 
-These values can be passed to methods that expect a platform, like [XcodeVersionConfig.sdk\_version\_for\_platform](../providers/XcodeVersionConfig#sdk_version_for_platform).
+These values can be passed to methods that expect a platform, like [XcodeVersionConfig.sdk\_version\_for\_platform](/versions/7.6.1/rules/lib/providers/XcodeVersionConfig#sdk_version_for_platform).
 
 ## platform\_type
 
@@ -240,7 +240,7 @@ An enum-like struct that contains the following fields corresponding to Apple pl
 * `visionos`
 * `watchos`
 
-These values can be passed to methods that expect a platform type, like the 'apple' configuration fragment's [multi\_arch\_platform](../fragments/apple#multi_arch_platform) method.
+These values can be passed to methods that expect a platform type, like the 'apple' configuration fragment's [multi\_arch\_platform](/versions/7.6.1/rules/lib/fragments/apple#multi_arch_platform) method.
 
 Example:
 
diff --git a/versions/7.6.1/rules/lib/toplevel/attr.mdx b/versions/7.6.1/rules/lib/toplevel/attr.mdx
index 8b20a1a1..d5723681 100644
--- a/versions/7.6.1/rules/lib/toplevel/attr.mdx
+++ b/versions/7.6.1/rules/lib/toplevel/attr.mdx
@@ -2,7 +2,7 @@
 title: 'attr'
 ---
 
-This is a top-level module for defining the attribute schemas of a rule or aspect. Each function returns an object representing the schema of a single attribute. These objects are used as the values of the `attrs` dictionary argument of [`rule()`](../globals/bzl#rule) and [`aspect()`](../globals/bzl#aspect).
+This is a top-level module for defining the attribute schemas of a rule or aspect. Each function returns an object representing the schema of a single attribute. These objects are used as the values of the `attrs` dictionary argument of [`rule()`](/versions/7.6.1/rules/lib/globals/bzl#rule) and [`aspect()`](/versions/7.6.1/rules/lib/globals/bzl#aspect).
 
 See the Rules page for more on [defining](https://bazel.build/versions/7.6.1/extending/rules#attributes) and [using](https://bazel.build/versions/7.6.1/extending/rules#implementation_function) attributes.
 
@@ -28,14 +28,14 @@ See the Rules page for more on [defining](https://bazel.build/versions/7.6.1/ext
 Attribute attr.bool(default=False, doc=None, mandatory=False)
 ```
 
-Creates a schema for a boolean attribute. The corresponding [`ctx.attr`](../builtins/ctx#attr) attribute will be of type [`bool`](../core/bool).
+Creates a schema for a boolean attribute. The corresponding [`ctx.attr`](/versions/7.6.1/rules/lib/builtins/ctx#attr) attribute will be of type [`bool`](/versions/7.6.1/rules/lib/core/bool).
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
 | `default` | default is `False`  A default value to use if no value for this attribute is given when instantiating the rule. |
-| `doc` | [string](../core/string); or `None`; default is `None`  A description of the attribute that can be extracted by documentation generating tools. |
+| `doc` | [string](/versions/7.6.1/rules/lib/core/string); or `None`; default is `None`  A description of the attribute that can be extracted by documentation generating tools. |
 | `mandatory` | default is `False`  If true, the value must be specified explicitly (even if it has a `default`). |
 
 ## int
@@ -44,16 +44,16 @@ Creates a schema for a boolean attribute. The corresponding [`ctx.attr`](../buil
 Attribute attr.int(default=0, doc=None, mandatory=False, values=[])
 ```
 
-Creates a schema for an integer attribute. The value must be in the signed 32-bit range. The corresponding [`ctx.attr`](../builtins/ctx#attr) attribute will be of type [`int`](../core/int).
+Creates a schema for an integer attribute. The value must be in the signed 32-bit range. The corresponding [`ctx.attr`](/versions/7.6.1/rules/lib/builtins/ctx#attr) attribute will be of type [`int`](/versions/7.6.1/rules/lib/core/int).
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
 | `default` | default is `0`  A default value to use if no value for this attribute is given when instantiating the rule. |
-| `doc` | [string](../core/string); or `None`; default is `None`  A description of the attribute that can be extracted by documentation generating tools. |
+| `doc` | [string](/versions/7.6.1/rules/lib/core/string); or `None`; default is `None`  A description of the attribute that can be extracted by documentation generating tools. |
 | `mandatory` | default is `False`  If true, the value must be specified explicitly (even if it has a `default`). |
-| `values` | [sequence](../core/list) of [int](../core/int)s; default is `[]`  The list of allowed values for the attribute. An error is raised if any other value is given. |
+| `values` | [sequence](/versions/7.6.1/rules/lib/core/list) of [int](/versions/7.6.1/rules/lib/core/int)s; default is `[]`  The list of allowed values for the attribute. An error is raised if any other value is given. |
 
 ## int\_list
 
@@ -69,8 +69,8 @@ Creates a schema for a list-of-integers attribute. Each element must be in the s
 | --- | --- |
 | `mandatory` | default is `False`  If true, the value must be specified explicitly (even if it has a `default`). |
 | `allow_empty` | default is `True`  True if the attribute can be empty. |
-| `default` | [sequence](../core/list) of [int](../core/int)s; default is `[]`  A default value to use if no value for this attribute is given when instantiating the rule. |
-| `doc` | [string](../core/string); or `None`; default is `None`  A description of the attribute that can be extracted by documentation generating tools. |
+| `default` | [sequence](/versions/7.6.1/rules/lib/core/list) of [int](/versions/7.6.1/rules/lib/core/int)s; default is `[]`  A default value to use if no value for this attribute is given when instantiating the rule. |
+| `doc` | [string](/versions/7.6.1/rules/lib/core/string); or `None`; default is `None`  A description of the attribute that can be extracted by documentation generating tools. |
 
 ## label
 
@@ -80,9 +80,9 @@ Attribute attr.label(default=None, doc=None, executable=False, allow_files=None,
 
 Creates a schema for a label attribute. This is a dependency attribute.
 
-This attribute contains unique [`Label`](../builtins/Label) values. If a string is supplied in place of a `Label`, it will be converted using the [label constructor](../builtins/Label#Label). The relative parts of the label path, including the (possibly renamed) repository, are resolved with respect to the instantiated target's package.
+This attribute contains unique [`Label`](/versions/7.6.1/rules/lib/builtins/Label) values. If a string is supplied in place of a `Label`, it will be converted using the [label constructor](/versions/7.6.1/rules/lib/builtins/Label#Label). The relative parts of the label path, including the (possibly renamed) repository, are resolved with respect to the instantiated target's package.
 
-At analysis time (within the rule's implementation function), when retrieving the attribute value from `ctx.attr`, labels are replaced by the corresponding [`Target`](../builtins/Target)s. This allows you to access the providers of the current target's dependencies.
+At analysis time (within the rule's implementation function), when retrieving the attribute value from `ctx.attr`, labels are replaced by the corresponding [`Target`](/versions/7.6.1/rules/lib/builtins/Target)s. This allows you to access the providers of the current target's dependencies.
 
 In addition to ordinary source files, this kind of attribute is often used to refer to a tool -- for example, a compiler. Such tools are considered to be dependencies, just like source files. To avoid requiring users to specify the tool's label every time they use the rule in their BUILD files, you can hard-code the label of a canonical tool as the `default` value of this attribute. If you also want to prevent users from overriding this default, you can make the attribute private by giving it a name that starts with an underscore. See the [Rules](https://bazel.build/versions/7.6.1/extending/rules#private-attributes) page for more information.
 
@@ -90,17 +90,17 @@ In addition to ordinary source files, this kind of attribute is often used to re
 
 | Parameter | Description |
 | --- | --- |
-| `default` | [Label](../builtins/Label); or [string](../core/string); or [LateBoundDefault](../builtins/LateBoundDefault); or NativeComputedDefault; or [function](../core/function); or `None`; default is `None`  A default value to use if no value for this attribute is given when instantiating the rule.Use a string or the [`Label`](../builtins/Label#Label) function to specify a default value, for example, `attr.label(default = "//a:b")`. |
-| `doc` | [string](../core/string); or `None`; default is `None`  A description of the attribute that can be extracted by documentation generating tools. |
+| `default` | [Label](/versions/7.6.1/rules/lib/builtins/Label); or [string](/versions/7.6.1/rules/lib/core/string); or [LateBoundDefault](/versions/7.6.1/rules/lib/builtins/LateBoundDefault); or NativeComputedDefault; or [function](/versions/7.6.1/rules/lib/core/function); or `None`; default is `None`  A default value to use if no value for this attribute is given when instantiating the rule.Use a string or the [`Label`](/versions/7.6.1/rules/lib/builtins/Label#Label) function to specify a default value, for example, `attr.label(default = "//a:b")`. |
+| `doc` | [string](/versions/7.6.1/rules/lib/core/string); or `None`; default is `None`  A description of the attribute that can be extracted by documentation generating tools. |
 | `executable` | default is `False`  True if the dependency has to be executable. This means the label must refer to an executable file, or to a rule that outputs an executable file. Access the label with `ctx.executable.`. |
-| `allow_files` | [bool](../core/bool); or [sequence](../core/list) of [string](../core/string)s; or `None`; default is `None`  Whether `File` targets are allowed. Can be `True`, `False` (default), or a list of file extensions that are allowed (for example, `[".cc", ".cpp"]`). |
-| `allow_single_file` | default is `None`  This is similar to `allow_files`, with the restriction that the label must correspond to a single [File](../builtins/File). Access it through `ctx.file.`. |
+| `allow_files` | [bool](/versions/7.6.1/rules/lib/core/bool); or [sequence](/versions/7.6.1/rules/lib/core/list) of [string](/versions/7.6.1/rules/lib/core/string)s; or `None`; default is `None`  Whether `File` targets are allowed. Can be `True`, `False` (default), or a list of file extensions that are allowed (for example, `[".cc", ".cpp"]`). |
+| `allow_single_file` | default is `None`  This is similar to `allow_files`, with the restriction that the label must correspond to a single [File](/versions/7.6.1/rules/lib/builtins/File). Access it through `ctx.file.`. |
 | `mandatory` | default is `False`  If true, the value must be specified explicitly (even if it has a `default`). |
-| `providers` | default is `[]`  The providers that must be given by any dependency appearing in this attribute. The format of this argument is a list of lists of providers -- `*Info` objects returned by [`provider()`](../globals/bzl#provider) (or in the case of a legacy provider, its string name). The dependency must return ALL providers mentioned in at least ONE of the inner lists. As a convenience, this argument may also be a single-level list of providers, in which case it is wrapped in an outer list with one element. It is NOT required that the rule of the dependency advertises those providers in its `provides` parameter, however, it is considered best practice. |
-| `allow_rules` | [sequence](../core/list) of [string](../core/string)s; or `None`; default is `None`  Which rule targets (name of the classes) are allowed. This is deprecated (kept only for compatibility), use providers instead. |
+| `providers` | default is `[]`  The providers that must be given by any dependency appearing in this attribute. The format of this argument is a list of lists of providers -- `*Info` objects returned by [`provider()`](/versions/7.6.1/rules/lib/globals/bzl#provider) (or in the case of a legacy provider, its string name). The dependency must return ALL providers mentioned in at least ONE of the inner lists. As a convenience, this argument may also be a single-level list of providers, in which case it is wrapped in an outer list with one element. It is NOT required that the rule of the dependency advertises those providers in its `provides` parameter, however, it is considered best practice. |
+| `allow_rules` | [sequence](/versions/7.6.1/rules/lib/core/list) of [string](/versions/7.6.1/rules/lib/core/string)s; or `None`; default is `None`  Which rule targets (name of the classes) are allowed. This is deprecated (kept only for compatibility), use providers instead. |
 | `cfg` | default is `None`  [Configuration](https://bazel.build/versions/7.6.1/extending/rules#configurations) of the attribute. It can be either `"exec"`, which indicates that the dependency is built for the `execution platform`, or `"target"`, which indicates that the dependency is build for the `target platform`. A typical example of the difference is when building mobile apps, where the `target platform` is `Android` or `iOS` while the `execution platform` is `Linux`, `macOS`, or `Windows`. This parameter is required if `executable` is True to guard against accidentally building host tools in the target configuration. `"target"` has no semantic effect, so don't set it when `executable` is False unless it really helps clarify your intentions. |
-| `aspects` | [sequence](../core/list) of [Aspect](../builtins/Aspect)s; default is `[]`  Aspects that should be applied to the dependency or dependencies specified by this attribute. |
-| `flags` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  Deprecated, will be removed. |
+| `aspects` | [sequence](/versions/7.6.1/rules/lib/core/list) of [Aspect](/versions/7.6.1/rules/lib/builtins/Aspect)s; default is `[]`  Aspects that should be applied to the dependency or dependencies specified by this attribute. |
+| `flags` | [sequence](/versions/7.6.1/rules/lib/core/list) of [string](/versions/7.6.1/rules/lib/core/string)s; default is `[]`  Deprecated, will be removed. |
 
 ## label\_keyed\_string\_dict
 
@@ -110,24 +110,24 @@ Attribute attr.label_keyed_string_dict(allow_empty=True, *, default={}, doc=None
 
 Creates a schema for an attribute holding a dictionary, where the keys are labels and the values are strings. This is a dependency attribute.
 
-This attribute contains unique [`Label`](../builtins/Label) values. If a string is supplied in place of a `Label`, it will be converted using the [label constructor](../builtins/Label#Label). The relative parts of the label path, including the (possibly renamed) repository, are resolved with respect to the instantiated target's package.
+This attribute contains unique [`Label`](/versions/7.6.1/rules/lib/builtins/Label) values. If a string is supplied in place of a `Label`, it will be converted using the [label constructor](/versions/7.6.1/rules/lib/builtins/Label#Label). The relative parts of the label path, including the (possibly renamed) repository, are resolved with respect to the instantiated target's package.
 
-At analysis time (within the rule's implementation function), when retrieving the attribute value from `ctx.attr`, labels are replaced by the corresponding [`Target`](../builtins/Target)s. This allows you to access the providers of the current target's dependencies.
+At analysis time (within the rule's implementation function), when retrieving the attribute value from `ctx.attr`, labels are replaced by the corresponding [`Target`](/versions/7.6.1/rules/lib/builtins/Target)s. This allows you to access the providers of the current target's dependencies.
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
 | `allow_empty` | default is `True`  True if the attribute can be empty. |
-| `default` | [dict](../core/dict); or [function](../core/function); default is `{}`  A default value to use if no value for this attribute is given when instantiating the rule.Use strings or the [`Label`](../builtins/Label#Label) function to specify default values, for example, `attr.label_keyed_string_dict(default = {"//a:b": "value", "//a:c": "string"})`. |
-| `doc` | [string](../core/string); or `None`; default is `None`  A description of the attribute that can be extracted by documentation generating tools. |
-| `allow_files` | [bool](../core/bool); or [sequence](../core/list) of [string](../core/string)s; or `None`; default is `None`  Whether `File` targets are allowed. Can be `True`, `False` (default), or a list of file extensions that are allowed (for example, `[".cc", ".cpp"]`). |
-| `allow_rules` | [sequence](../core/list) of [string](../core/string)s; or `None`; default is `None`  Which rule targets (name of the classes) are allowed. This is deprecated (kept only for compatibility), use providers instead. |
-| `providers` | default is `[]`  The providers that must be given by any dependency appearing in this attribute. The format of this argument is a list of lists of providers -- `*Info` objects returned by [`provider()`](../globals/bzl#provider) (or in the case of a legacy provider, its string name). The dependency must return ALL providers mentioned in at least ONE of the inner lists. As a convenience, this argument may also be a single-level list of providers, in which case it is wrapped in an outer list with one element. It is NOT required that the rule of the dependency advertises those providers in its `provides` parameter, however, it is considered best practice. |
-| `flags` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  Deprecated, will be removed. |
+| `default` | [dict](/versions/7.6.1/rules/lib/core/dict); or [function](/versions/7.6.1/rules/lib/core/function); default is `{}`  A default value to use if no value for this attribute is given when instantiating the rule.Use strings or the [`Label`](/versions/7.6.1/rules/lib/builtins/Label#Label) function to specify default values, for example, `attr.label_keyed_string_dict(default = {"//a:b": "value", "//a:c": "string"})`. |
+| `doc` | [string](/versions/7.6.1/rules/lib/core/string); or `None`; default is `None`  A description of the attribute that can be extracted by documentation generating tools. |
+| `allow_files` | [bool](/versions/7.6.1/rules/lib/core/bool); or [sequence](/versions/7.6.1/rules/lib/core/list) of [string](/versions/7.6.1/rules/lib/core/string)s; or `None`; default is `None`  Whether `File` targets are allowed. Can be `True`, `False` (default), or a list of file extensions that are allowed (for example, `[".cc", ".cpp"]`). |
+| `allow_rules` | [sequence](/versions/7.6.1/rules/lib/core/list) of [string](/versions/7.6.1/rules/lib/core/string)s; or `None`; default is `None`  Which rule targets (name of the classes) are allowed. This is deprecated (kept only for compatibility), use providers instead. |
+| `providers` | default is `[]`  The providers that must be given by any dependency appearing in this attribute. The format of this argument is a list of lists of providers -- `*Info` objects returned by [`provider()`](/versions/7.6.1/rules/lib/globals/bzl#provider) (or in the case of a legacy provider, its string name). The dependency must return ALL providers mentioned in at least ONE of the inner lists. As a convenience, this argument may also be a single-level list of providers, in which case it is wrapped in an outer list with one element. It is NOT required that the rule of the dependency advertises those providers in its `provides` parameter, however, it is considered best practice. |
+| `flags` | [sequence](/versions/7.6.1/rules/lib/core/list) of [string](/versions/7.6.1/rules/lib/core/string)s; default is `[]`  Deprecated, will be removed. |
 | `mandatory` | default is `False`  If true, the value must be specified explicitly (even if it has a `default`). |
 | `cfg` | default is `None`  [Configuration](https://bazel.build/versions/7.6.1/extending/rules#configurations) of the attribute. It can be either `"exec"`, which indicates that the dependency is built for the `execution platform`, or `"target"`, which indicates that the dependency is build for the `target platform`. A typical example of the difference is when building mobile apps, where the `target platform` is `Android` or `iOS` while the `execution platform` is `Linux`, `macOS`, or `Windows`. |
-| `aspects` | [sequence](../core/list) of [Aspect](../builtins/Aspect)s; default is `[]`  Aspects that should be applied to the dependency or dependencies specified by this attribute. |
+| `aspects` | [sequence](/versions/7.6.1/rules/lib/core/list) of [Aspect](/versions/7.6.1/rules/lib/builtins/Aspect)s; default is `[]`  Aspects that should be applied to the dependency or dependencies specified by this attribute. |
 
 ## label\_list
 
@@ -135,26 +135,26 @@ At analysis time (within the rule's implementation function), when retrieving th
 Attribute attr.label_list(allow_empty=True, *, default=[], doc=None, allow_files=None, allow_rules=None, providers=[], flags=[], mandatory=False, cfg=None, aspects=[])
 ```
 
-Creates a schema for a list-of-labels attribute. This is a dependency attribute. The corresponding [`ctx.attr`](../builtins/ctx#attr) attribute will be of type [list](../core/list) of [`Target`s](../builtins/Target).
+Creates a schema for a list-of-labels attribute. This is a dependency attribute. The corresponding [`ctx.attr`](/versions/7.6.1/rules/lib/builtins/ctx#attr) attribute will be of type [list](/versions/7.6.1/rules/lib/core/list) of [`Target`s](/versions/7.6.1/rules/lib/builtins/Target).
 
-This attribute contains unique [`Label`](../builtins/Label) values. If a string is supplied in place of a `Label`, it will be converted using the [label constructor](../builtins/Label#Label). The relative parts of the label path, including the (possibly renamed) repository, are resolved with respect to the instantiated target's package.
+This attribute contains unique [`Label`](/versions/7.6.1/rules/lib/builtins/Label) values. If a string is supplied in place of a `Label`, it will be converted using the [label constructor](/versions/7.6.1/rules/lib/builtins/Label#Label). The relative parts of the label path, including the (possibly renamed) repository, are resolved with respect to the instantiated target's package.
 
-At analysis time (within the rule's implementation function), when retrieving the attribute value from `ctx.attr`, labels are replaced by the corresponding [`Target`](../builtins/Target)s. This allows you to access the providers of the current target's dependencies.
+At analysis time (within the rule's implementation function), when retrieving the attribute value from `ctx.attr`, labels are replaced by the corresponding [`Target`](/versions/7.6.1/rules/lib/builtins/Target)s. This allows you to access the providers of the current target's dependencies.
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
 | `allow_empty` | default is `True`  True if the attribute can be empty. |
-| `default` | [sequence](../core/list) of [Label](../builtins/Label)s; or [function](../core/function); default is `[]`  A default value to use if no value for this attribute is given when instantiating the rule.Use strings or the [`Label`](../builtins/Label#Label) function to specify default values, for example, `attr.label_list(default = ["//a:b", "//a:c"])`. |
-| `doc` | [string](../core/string); or `None`; default is `None`  A description of the attribute that can be extracted by documentation generating tools. |
-| `allow_files` | [bool](../core/bool); or [sequence](../core/list) of [string](../core/string)s; or `None`; default is `None`  Whether `File` targets are allowed. Can be `True`, `False` (default), or a list of file extensions that are allowed (for example, `[".cc", ".cpp"]`). |
-| `allow_rules` | [sequence](../core/list) of [string](../core/string)s; or `None`; default is `None`  Which rule targets (name of the classes) are allowed. This is deprecated (kept only for compatibility), use providers instead. |
-| `providers` | default is `[]`  The providers that must be given by any dependency appearing in this attribute. The format of this argument is a list of lists of providers -- `*Info` objects returned by [`provider()`](../globals/bzl#provider) (or in the case of a legacy provider, its string name). The dependency must return ALL providers mentioned in at least ONE of the inner lists. As a convenience, this argument may also be a single-level list of providers, in which case it is wrapped in an outer list with one element. It is NOT required that the rule of the dependency advertises those providers in its `provides` parameter, however, it is considered best practice. |
-| `flags` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  Deprecated, will be removed. |
+| `default` | [sequence](/versions/7.6.1/rules/lib/core/list) of [Label](/versions/7.6.1/rules/lib/builtins/Label)s; or [function](/versions/7.6.1/rules/lib/core/function); default is `[]`  A default value to use if no value for this attribute is given when instantiating the rule.Use strings or the [`Label`](/versions/7.6.1/rules/lib/builtins/Label#Label) function to specify default values, for example, `attr.label_list(default = ["//a:b", "//a:c"])`. |
+| `doc` | [string](/versions/7.6.1/rules/lib/core/string); or `None`; default is `None`  A description of the attribute that can be extracted by documentation generating tools. |
+| `allow_files` | [bool](/versions/7.6.1/rules/lib/core/bool); or [sequence](/versions/7.6.1/rules/lib/core/list) of [string](/versions/7.6.1/rules/lib/core/string)s; or `None`; default is `None`  Whether `File` targets are allowed. Can be `True`, `False` (default), or a list of file extensions that are allowed (for example, `[".cc", ".cpp"]`). |
+| `allow_rules` | [sequence](/versions/7.6.1/rules/lib/core/list) of [string](/versions/7.6.1/rules/lib/core/string)s; or `None`; default is `None`  Which rule targets (name of the classes) are allowed. This is deprecated (kept only for compatibility), use providers instead. |
+| `providers` | default is `[]`  The providers that must be given by any dependency appearing in this attribute. The format of this argument is a list of lists of providers -- `*Info` objects returned by [`provider()`](/versions/7.6.1/rules/lib/globals/bzl#provider) (or in the case of a legacy provider, its string name). The dependency must return ALL providers mentioned in at least ONE of the inner lists. As a convenience, this argument may also be a single-level list of providers, in which case it is wrapped in an outer list with one element. It is NOT required that the rule of the dependency advertises those providers in its `provides` parameter, however, it is considered best practice. |
+| `flags` | [sequence](/versions/7.6.1/rules/lib/core/list) of [string](/versions/7.6.1/rules/lib/core/string)s; default is `[]`  Deprecated, will be removed. |
 | `mandatory` | default is `False`  If true, the value must be specified explicitly (even if it has a `default`). |
 | `cfg` | default is `None`  [Configuration](https://bazel.build/versions/7.6.1/extending/rules#configurations) of the attribute. It can be either `"exec"`, which indicates that the dependency is built for the `execution platform`, or `"target"`, which indicates that the dependency is build for the `target platform`. A typical example of the difference is when building mobile apps, where the `target platform` is `Android` or `iOS` while the `execution platform` is `Linux`, `macOS`, or `Windows`. |
-| `aspects` | [sequence](../core/list) of [Aspect](../builtins/Aspect)s; default is `[]`  Aspects that should be applied to the dependency or dependencies specified by this attribute. |
+| `aspects` | [sequence](/versions/7.6.1/rules/lib/core/list) of [Aspect](/versions/7.6.1/rules/lib/builtins/Aspect)s; default is `[]`  Aspects that should be applied to the dependency or dependencies specified by this attribute. |
 
 ## output
 
@@ -164,15 +164,15 @@ Attribute attr.output(doc=None, mandatory=False)
 
 Creates a schema for an output (label) attribute.
 
-This attribute contains unique [`Label`](../builtins/Label) values. If a string is supplied in place of a `Label`, it will be converted using the [label constructor](../builtins/Label#Label). The relative parts of the label path, including the (possibly renamed) repository, are resolved with respect to the instantiated target's package.
+This attribute contains unique [`Label`](/versions/7.6.1/rules/lib/builtins/Label) values. If a string is supplied in place of a `Label`, it will be converted using the [label constructor](/versions/7.6.1/rules/lib/builtins/Label#Label). The relative parts of the label path, including the (possibly renamed) repository, are resolved with respect to the instantiated target's package.
 
-At analysis time, the corresponding [`File`](../builtins/File) can be retrieved using [`ctx.outputs`](../builtins/ctx#outputs).
+At analysis time, the corresponding [`File`](/versions/7.6.1/rules/lib/builtins/File) can be retrieved using [`ctx.outputs`](/versions/7.6.1/rules/lib/builtins/ctx#outputs).
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `doc` | [string](../core/string); or `None`; default is `None`  A description of the attribute that can be extracted by documentation generating tools. |
+| `doc` | [string](/versions/7.6.1/rules/lib/core/string); or `None`; default is `None`  A description of the attribute that can be extracted by documentation generating tools. |
 | `mandatory` | default is `False`  If true, the value must be specified explicitly (even if it has a `default`). |
 
 ## output\_list
@@ -183,16 +183,16 @@ Attribute attr.output_list(allow_empty=True, *, doc=None, mandatory=False)
 
 Creates a schema for a list-of-outputs attribute.
 
-This attribute contains unique [`Label`](../builtins/Label) values. If a string is supplied in place of a `Label`, it will be converted using the [label constructor](../builtins/Label#Label). The relative parts of the label path, including the (possibly renamed) repository, are resolved with respect to the instantiated target's package.
+This attribute contains unique [`Label`](/versions/7.6.1/rules/lib/builtins/Label) values. If a string is supplied in place of a `Label`, it will be converted using the [label constructor](/versions/7.6.1/rules/lib/builtins/Label#Label). The relative parts of the label path, including the (possibly renamed) repository, are resolved with respect to the instantiated target's package.
 
-At analysis time, the corresponding [`File`](../builtins/File) can be retrieved using [`ctx.outputs`](../builtins/ctx#outputs).
+At analysis time, the corresponding [`File`](/versions/7.6.1/rules/lib/builtins/File) can be retrieved using [`ctx.outputs`](/versions/7.6.1/rules/lib/builtins/ctx#outputs).
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
 | `allow_empty` | default is `True`  True if the attribute can be empty. |
-| `doc` | [string](../core/string); or `None`; default is `None`  A description of the attribute that can be extracted by documentation generating tools. |
+| `doc` | [string](/versions/7.6.1/rules/lib/core/string); or `None`; default is `None`  A description of the attribute that can be extracted by documentation generating tools. |
 | `mandatory` | default is `False`  If true, the value must be specified explicitly (even if it has a `default`). |
 
 ## string
@@ -201,16 +201,16 @@ At analysis time, the corresponding [`File`](../builtins/File) can be retrieved
 Attribute attr.string(default='', doc=None, mandatory=False, values=[])
 ```
 
-Creates a schema for a [string](../core/string#attr) attribute.
+Creates a schema for a [string](/versions/7.6.1/rules/lib/core/string#attr) attribute.
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `default` | [string](../core/string); or NativeComputedDefault; default is `''`  A default value to use if no value for this attribute is given when instantiating the rule. |
-| `doc` | [string](../core/string); or `None`; default is `None`  A description of the attribute that can be extracted by documentation generating tools. |
+| `default` | [string](/versions/7.6.1/rules/lib/core/string); or NativeComputedDefault; default is `''`  A default value to use if no value for this attribute is given when instantiating the rule. |
+| `doc` | [string](/versions/7.6.1/rules/lib/core/string); or `None`; default is `None`  A description of the attribute that can be extracted by documentation generating tools. |
 | `mandatory` | default is `False`  If true, the value must be specified explicitly (even if it has a `default`). |
-| `values` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  The list of allowed values for the attribute. An error is raised if any other value is given. |
+| `values` | [sequence](/versions/7.6.1/rules/lib/core/list) of [string](/versions/7.6.1/rules/lib/core/string)s; default is `[]`  The list of allowed values for the attribute. An error is raised if any other value is given. |
 
 ## string\_dict
 
@@ -226,7 +226,7 @@ Creates a schema for an attribute holding a dictionary, where the keys and value
 | --- | --- |
 | `allow_empty` | default is `True`  True if the attribute can be empty. |
 | `default` | default is `{}`  A default value to use if no value for this attribute is given when instantiating the rule. |
-| `doc` | [string](../core/string); or `None`; default is `None`  A description of the attribute that can be extracted by documentation generating tools. |
+| `doc` | [string](/versions/7.6.1/rules/lib/core/string); or `None`; default is `None`  A description of the attribute that can be extracted by documentation generating tools. |
 | `mandatory` | default is `False`  If true, the value must be specified explicitly (even if it has a `default`). |
 
 ## string\_keyed\_label\_dict
@@ -237,24 +237,24 @@ Attribute attr.string_keyed_label_dict(allow_empty=True, *, default={}, doc=None
 
 Creates a schema for an attribute whose value is a dictionary where the keys are strings and the values are labels. This is a dependency attribute.
 
-This attribute contains unique [`Label`](../builtins/Label) values. If a string is supplied in place of a `Label`, it will be converted using the [label constructor](../builtins/Label#Label). The relative parts of the label path, including the (possibly renamed) repository, are resolved with respect to the instantiated target's package.
+This attribute contains unique [`Label`](/versions/7.6.1/rules/lib/builtins/Label) values. If a string is supplied in place of a `Label`, it will be converted using the [label constructor](/versions/7.6.1/rules/lib/builtins/Label#Label). The relative parts of the label path, including the (possibly renamed) repository, are resolved with respect to the instantiated target's package.
 
-At analysis time (within the rule's implementation function), when retrieving the attribute value from `ctx.attr`, labels are replaced by the corresponding [`Target`](../builtins/Target)s. This allows you to access the providers of the current target's dependencies.
+At analysis time (within the rule's implementation function), when retrieving the attribute value from `ctx.attr`, labels are replaced by the corresponding [`Target`](/versions/7.6.1/rules/lib/builtins/Target)s. This allows you to access the providers of the current target's dependencies.
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
 | `allow_empty` | default is `True`  True if the attribute can be empty. |
-| `default` | [dict](../core/dict); or [function](../core/function); default is `{}`  A default value to use if no value for this attribute is given when instantiating the rule.Use strings or the [`Label`](../builtins/Label#Label) function to specify default values, for example, `attr.string_keyed_label_dict(default = {"foo": "//a:b", "bar": "//a:c"})`. |
-| `doc` | [string](../core/string); or `None`; default is `None`  A description of the attribute that can be extracted by documentation generating tools. |
-| `allow_files` | [bool](../core/bool); or [sequence](../core/list) of [string](../core/string)s; or `None`; default is `None`  Whether `File` targets are allowed. Can be `True`, `False` (default), or a list of file extensions that are allowed (for example, `[".cc", ".cpp"]`). |
-| `allow_rules` | [sequence](../core/list) of [string](../core/string)s; or `None`; default is `None`  Which rule targets (name of the classes) are allowed. This is deprecated (kept only for compatibility), use providers instead. |
-| `providers` | default is `[]`  The providers that must be given by any dependency appearing in this attribute. The format of this argument is a list of lists of providers -- `*Info` objects returned by [`provider()`](../globals/bzl#provider) (or in the case of a legacy provider, its string name). The dependency must return ALL providers mentioned in at least ONE of the inner lists. As a convenience, this argument may also be a single-level list of providers, in which case it is wrapped in an outer list with one element. It is NOT required that the rule of the dependency advertises those providers in its `provides` parameter, however, it is considered best practice. |
-| `flags` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  Deprecated, will be removed. |
+| `default` | [dict](/versions/7.6.1/rules/lib/core/dict); or [function](/versions/7.6.1/rules/lib/core/function); default is `{}`  A default value to use if no value for this attribute is given when instantiating the rule.Use strings or the [`Label`](/versions/7.6.1/rules/lib/builtins/Label#Label) function to specify default values, for example, `attr.string_keyed_label_dict(default = {"foo": "//a:b", "bar": "//a:c"})`. |
+| `doc` | [string](/versions/7.6.1/rules/lib/core/string); or `None`; default is `None`  A description of the attribute that can be extracted by documentation generating tools. |
+| `allow_files` | [bool](/versions/7.6.1/rules/lib/core/bool); or [sequence](/versions/7.6.1/rules/lib/core/list) of [string](/versions/7.6.1/rules/lib/core/string)s; or `None`; default is `None`  Whether `File` targets are allowed. Can be `True`, `False` (default), or a list of file extensions that are allowed (for example, `[".cc", ".cpp"]`). |
+| `allow_rules` | [sequence](/versions/7.6.1/rules/lib/core/list) of [string](/versions/7.6.1/rules/lib/core/string)s; or `None`; default is `None`  Which rule targets (name of the classes) are allowed. This is deprecated (kept only for compatibility), use providers instead. |
+| `providers` | default is `[]`  The providers that must be given by any dependency appearing in this attribute. The format of this argument is a list of lists of providers -- `*Info` objects returned by [`provider()`](/versions/7.6.1/rules/lib/globals/bzl#provider) (or in the case of a legacy provider, its string name). The dependency must return ALL providers mentioned in at least ONE of the inner lists. As a convenience, this argument may also be a single-level list of providers, in which case it is wrapped in an outer list with one element. It is NOT required that the rule of the dependency advertises those providers in its `provides` parameter, however, it is considered best practice. |
+| `flags` | [sequence](/versions/7.6.1/rules/lib/core/list) of [string](/versions/7.6.1/rules/lib/core/string)s; default is `[]`  Deprecated, will be removed. |
 | `mandatory` | default is `False`  If true, the value must be specified explicitly (even if it has a `default`). |
 | `cfg` | default is `None`  [Configuration](https://bazel.build/versions/7.6.1/extending/rules#configurations) of the attribute. It can be either `"exec"`, which indicates that the dependency is built for the `execution platform`, or `"target"`, which indicates that the dependency is build for the `target platform`. A typical example of the difference is when building mobile apps, where the `target platform` is `Android` or `iOS` while the `execution platform` is `Linux`, `macOS`, or `Windows`. |
-| `aspects` | [sequence](../core/list) of [Aspect](../builtins/Aspect)s; default is `[]`  Aspects that should be applied to the dependency or dependencies specified by this attribute. |
+| `aspects` | [sequence](/versions/7.6.1/rules/lib/core/list) of [Aspect](/versions/7.6.1/rules/lib/builtins/Aspect)s; default is `[]`  Aspects that should be applied to the dependency or dependencies specified by this attribute. |
 
 ## string\_list
 
@@ -270,8 +270,8 @@ Creates a schema for a list-of-strings attribute.
 | --- | --- |
 | `mandatory` | default is `False`  If true, the value must be specified explicitly (even if it has a `default`). |
 | `allow_empty` | default is `True`  True if the attribute can be empty. |
-| `default` | [sequence](../core/list) of [string](../core/string)s; or NativeComputedDefault; default is `[]`  A default value to use if no value for this attribute is given when instantiating the rule. |
-| `doc` | [string](../core/string); or `None`; default is `None`  A description of the attribute that can be extracted by documentation generating tools. |
+| `default` | [sequence](/versions/7.6.1/rules/lib/core/list) of [string](/versions/7.6.1/rules/lib/core/string)s; or NativeComputedDefault; default is `[]`  A default value to use if no value for this attribute is given when instantiating the rule. |
+| `doc` | [string](/versions/7.6.1/rules/lib/core/string); or `None`; default is `None`  A description of the attribute that can be extracted by documentation generating tools. |
 
 ## string\_list\_dict
 
@@ -287,5 +287,5 @@ Creates a schema for an attribute holding a dictionary, where the keys are strin
 | --- | --- |
 | `allow_empty` | default is `True`  True if the attribute can be empty. |
 | `default` | default is `{}`  A default value to use if no value for this attribute is given when instantiating the rule. |
-| `doc` | [string](../core/string); or `None`; default is `None`  A description of the attribute that can be extracted by documentation generating tools. |
+| `doc` | [string](/versions/7.6.1/rules/lib/core/string); or `None`; default is `None`  A description of the attribute that can be extracted by documentation generating tools. |
 | `mandatory` | default is `False`  If true, the value must be specified explicitly (even if it has a `default`). |
\ No newline at end of file
diff --git a/versions/7.6.1/rules/lib/toplevel/cc_common.mdx b/versions/7.6.1/rules/lib/toplevel/cc_common.mdx
index 2f5eff05..27aa2633 100644
--- a/versions/7.6.1/rules/lib/toplevel/cc_common.mdx
+++ b/versions/7.6.1/rules/lib/toplevel/cc_common.mdx
@@ -70,7 +70,7 @@ Should be used for C++ compilation. Returns tuple of (`CompilationContext`, `CcC
 | `srcs` | default is `[]`  The list of source files to be compiled. |
 | `public_hdrs` | default is `[]`  List of headers needed for compilation of srcs and may be included by dependent rules transitively. |
 | `private_hdrs` | default is `[]`  List of headers needed for compilation of srcs and NOT to be included by dependent rules. |
-| `includes` | [sequence](../core/list); or [depset](../builtins/depset); default is `[]`  Search paths for header files referenced both by angle bracket and quotes. Usually passed with -I. Propagated to dependents transitively. |
+| `includes` | [sequence](/versions/7.6.1/rules/lib/core/list); or [depset](/versions/7.6.1/rules/lib/builtins/depset); default is `[]`  Search paths for header files referenced both by angle bracket and quotes. Usually passed with -I. Propagated to dependents transitively. |
 | `quote_includes` | default is `[]`  Search paths for header files referenced by quotes, e.g. #include "foo/bar/header.h". They can be either relative to the exec root or absolute. Usually passed with -iquote. Propagated to dependents transitively. |
 | `system_includes` | default is `[]`  Search paths for header files referenced by angle brackets, e.g. `#include `. They can be either relative to the exec root or absolute. Usually passed with -isystem. Propagated to dependents transitively. |
 | `framework_includes` | default is `[]`  Search paths for header files from Apple frameworks. They can be either relative to the exec root or absolute. Usually passed with -F. Propagated to dependents transitively. |
@@ -99,9 +99,9 @@ Creates a feature\_configuration instance. Requires the cpp configuration fragme
 
 | Parameter | Description |
 | --- | --- |
-| `ctx` | [ctx](../builtins/ctx); or `None`; default is `None`  The rule context. |
+| `ctx` | [ctx](/versions/7.6.1/rules/lib/builtins/ctx); or `None`; default is `None`  The rule context. |
 | `cc_toolchain` | required  cc\_toolchain for which we configure features. |
-| `language` | [string](../core/string); or `None`; default is `None`  The language to configure for: either c++ or objc (default c++) |
+| `language` | [string](/versions/7.6.1/rules/lib/core/string); or `None`; default is `None`  The language to configure for: either c++ or objc (default c++) |
 | `requested_features` | default is `[]`  List of features to be enabled. |
 | `unsupported_features` | default is `[]`  List of features that are unsupported by the current rule. |
 
@@ -123,17 +123,17 @@ Creates a `CcToolchainConfigInfo` provider
 | `artifact_name_patterns` | default is `[]`  The name for an artifact of a given category of input or output artifacts to an action. Arguments:  `category_name`: The category of artifacts that this selection applies to. This field is compared against a list of categories defined in Bazel. Example categories include "linked\_output" or the artifact for this selection. Together with the extension it is used to create an artifact name based on the target name.  `extension`: The extension for creating the artifact for this selection. Together with the prefix it is used to create an artifact name based on the target name. |
 | `cxx_builtin_include_directories` | default is `[]`  Built-in include directories for C++ compilation. These should be the exact paths used by the compiler, and are generally relative to the exec root.  The paths used by the compiler can be determined by 'gcc -E -xc++ - -v'.  We currently use the C++ paths also for C compilation, which is safe as long as there are no name clashes between C++ and C header files.  Relative paths are resolved relative to the configuration file directory.  If the compiler has --sysroot support, then these paths should use %sysroot% rather than the include path, and specify the sysroot attribute in order to give blaze the information necessary to make the correct replacements. |
 | `toolchain_identifier` | required  The unique identifier of the toolchain within the crosstool release. It must be possible to use this as a directory name in a path.  It has to match the following regex: [a-zA-Z\_][\.\- \w]\* |
-| `host_system_name` | [string](../core/string); or `None`; default is `None`  Ignored. |
+| `host_system_name` | [string](/versions/7.6.1/rules/lib/core/string); or `None`; default is `None`  Ignored. |
 | `target_system_name` | required  The GNU System Name. |
 | `target_cpu` | required  The target architecture string. |
 | `target_libc` | required  The libc version string (e.g. "glibc-2.2.2"). |
 | `compiler` | required  The compiler version string (e.g. "gcc-4.1.1"). |
-| `abi_version` | [string](../core/string); or `None`; default is `None`  The abi in use, which is a gcc version. E.g.: "gcc-3.4" |
-| `abi_libc_version` | [string](../core/string); or `None`; default is `None`  The glibc version used by the abi we're using. |
+| `abi_version` | [string](/versions/7.6.1/rules/lib/core/string); or `None`; default is `None`  The abi in use, which is a gcc version. E.g.: "gcc-3.4" |
+| `abi_libc_version` | [string](/versions/7.6.1/rules/lib/core/string); or `None`; default is `None`  The glibc version used by the abi we're using. |
 | `tool_paths` | default is `[]`  Tool locations. Arguments:  `name`: Name of the tool.  `path`: Location of the tool; Can be absolute path (in case of non hermetic toolchain), or path relative to the cc\_toolchain's package. |
 | `make_variables` | default is `[]`  A make variable that is made accessible to rules. |
-| `builtin_sysroot` | [string](../core/string); or `None`; default is `None`  The built-in sysroot. If this attribute is not present, Bazel does not allow using a different sysroot, i.e. through the --grte\_top option. |
-| `cc_target_os` | [string](../core/string); or `None`; default is `None`  Internal purpose only, do not use. |
+| `builtin_sysroot` | [string](/versions/7.6.1/rules/lib/core/string); or `None`; default is `None`  The built-in sysroot. If this attribute is not present, Bazel does not allow using a different sysroot, i.e. through the --grte\_top option. |
+| `cc_target_os` | [string](/versions/7.6.1/rules/lib/core/string); or `None`; default is `None`  Internal purpose only, do not use. |
 
 ## create\_compilation\_context
 
@@ -167,8 +167,8 @@ Create compilation outputs object.
 
 | Parameter | Description |
 | --- | --- |
-| `objects` | [depset](../builtins/depset); or `None`; default is `None`  List of object files. |
-| `pic_objects` | [depset](../builtins/depset); or `None`; default is `None`  List of pic object files. |
+| `objects` | [depset](/versions/7.6.1/rules/lib/builtins/depset); or `None`; default is `None`  List of object files. |
+| `pic_objects` | [depset](/versions/7.6.1/rules/lib/builtins/depset); or `None`; default is `None`  List of pic object files. |
 
 ## create\_compile\_variables
 
@@ -186,18 +186,18 @@ Returns variables used for compilation actions.
 | `feature_configuration` | required  Feature configuration to be queried. |
 | `source_file` | default is `None`  Optional source file for the compilation. Please prefer passing source\_file here over appending it to the end of the command line generated from cc\_common.get\_memory\_inefficient\_command\_line, as then it's in the power of the toolchain author to properly specify and position compiler flags. |
 | `output_file` | default is `None`  Optional output file of the compilation. Please prefer passing output\_file here over appending it to the end of the command line generated from cc\_common.get\_memory\_inefficient\_command\_line, as then it's in the power of the toolchain author to properly specify and position compiler flags. |
-| `user_compile_flags` | [sequence](../core/list) of [string](../core/string)s; or `None`; default is `None`  List of additional compilation flags (copts). |
-| `include_directories` | [depset](../builtins/depset); or `None`; default is `None`  Depset of include directories. |
-| `quote_include_directories` | [depset](../builtins/depset); or `None`; default is `None`  Depset of quote include directories. |
-| `system_include_directories` | [depset](../builtins/depset); or `None`; default is `None`  Depset of system include directories. |
-| `framework_include_directories` | [depset](../builtins/depset); or `None`; default is `None`  Depset of framework include directories. |
-| `preprocessor_defines` | [depset](../builtins/depset); or `None`; default is `None`  Depset of preprocessor defines. |
-| `thinlto_index` | [string](../core/string); or `None`; default is `None`  LTO index file path. |
-| `thinlto_input_bitcode_file` | [string](../core/string); or `None`; default is `None`  Bitcode file that is input to LTO backend. |
-| `thinlto_output_object_file` | [string](../core/string); or `None`; default is `None`  Object file that is output by LTO backend. |
+| `user_compile_flags` | [sequence](/versions/7.6.1/rules/lib/core/list) of [string](/versions/7.6.1/rules/lib/core/string)s; or `None`; default is `None`  List of additional compilation flags (copts). |
+| `include_directories` | [depset](/versions/7.6.1/rules/lib/builtins/depset); or `None`; default is `None`  Depset of include directories. |
+| `quote_include_directories` | [depset](/versions/7.6.1/rules/lib/builtins/depset); or `None`; default is `None`  Depset of quote include directories. |
+| `system_include_directories` | [depset](/versions/7.6.1/rules/lib/builtins/depset); or `None`; default is `None`  Depset of system include directories. |
+| `framework_include_directories` | [depset](/versions/7.6.1/rules/lib/builtins/depset); or `None`; default is `None`  Depset of framework include directories. |
+| `preprocessor_defines` | [depset](/versions/7.6.1/rules/lib/builtins/depset); or `None`; default is `None`  Depset of preprocessor defines. |
+| `thinlto_index` | [string](/versions/7.6.1/rules/lib/core/string); or `None`; default is `None`  LTO index file path. |
+| `thinlto_input_bitcode_file` | [string](/versions/7.6.1/rules/lib/core/string); or `None`; default is `None`  Bitcode file that is input to LTO backend. |
+| `thinlto_output_object_file` | [string](/versions/7.6.1/rules/lib/core/string); or `None`; default is `None`  Object file that is output by LTO backend. |
 | `use_pic` | default is `False`  When true the compilation will generate position independent code. |
 | `add_legacy_cxx_options` | default is `False`  Unused. |
-| `variables_extension` | [dict](../core/dict); default is `unbound`  A dictionary of additional variables used by compile actions. |
+| `variables_extension` | [dict](/versions/7.6.1/rules/lib/core/dict); default is `unbound`  A dictionary of additional variables used by compile actions. |
 
 ## create\_library\_to\_link
 
@@ -214,14 +214,14 @@ Creates `LibraryToLink`
 | `actions` | required  `actions` object. |
 | `feature_configuration` | default is `None`  `feature_configuration` to be queried. |
 | `cc_toolchain` | default is `None`  `CcToolchainInfo` provider to be used. |
-| `static_library` | [File](../builtins/File); or `None`; default is `None`  `File` of static library to be linked. |
-| `pic_static_library` | [File](../builtins/File); or `None`; default is `None`  `File` of pic static library to be linked. |
-| `dynamic_library` | [File](../builtins/File); or `None`; default is `None`  `File` of dynamic library to be linked. Always used for runtime and used for linking if `interface_library` is not passed. |
-| `interface_library` | [File](../builtins/File); or `None`; default is `None`  `File` of interface library to be linked. |
-| `pic_objects` | [sequence](../core/list) of [File](../builtins/File)s; default is `unbound`  Experimental, do not use |
-| `objects` | [sequence](../core/list) of [File](../builtins/File)s; default is `unbound`  Experimental, do not use |
+| `static_library` | [File](/versions/7.6.1/rules/lib/builtins/File); or `None`; default is `None`  `File` of static library to be linked. |
+| `pic_static_library` | [File](/versions/7.6.1/rules/lib/builtins/File); or `None`; default is `None`  `File` of pic static library to be linked. |
+| `dynamic_library` | [File](/versions/7.6.1/rules/lib/builtins/File); or `None`; default is `None`  `File` of dynamic library to be linked. Always used for runtime and used for linking if `interface_library` is not passed. |
+| `interface_library` | [File](/versions/7.6.1/rules/lib/builtins/File); or `None`; default is `None`  `File` of interface library to be linked. |
+| `pic_objects` | [sequence](/versions/7.6.1/rules/lib/core/list) of [File](/versions/7.6.1/rules/lib/builtins/File)s; default is `unbound`  Experimental, do not use |
+| `objects` | [sequence](/versions/7.6.1/rules/lib/core/list) of [File](/versions/7.6.1/rules/lib/builtins/File)s; default is `unbound`  Experimental, do not use |
 | `alwayslink` | default is `False`  Whether to link the static library/objects in the --whole\_archive block. |
-| `dynamic_library_symlink_path` | [string](../core/string); default is `''`  Override the default path of the dynamic library link in the solib directory. Empty string to use the default. |
+| `dynamic_library_symlink_path` | [string](/versions/7.6.1/rules/lib/core/string); default is `''`  Override the default path of the dynamic library link in the solib directory. Empty string to use the default. |
 | `interface_library_symlink_path` | default is `''`  Override the default path of the interface library link in the solib directory. Empty string to use the default. |
 
 ## create\_link\_variables
@@ -238,9 +238,9 @@ Returns link variables used for linking actions.
 | --- | --- |
 | `cc_toolchain` | required  cc\_toolchain for which we are creating build variables. |
 | `feature_configuration` | required  Feature configuration to be queried. |
-| `library_search_directories` | `None`; or [depset](../builtins/depset); default is `None`  Depset of directories where linker will look for libraries at link time. |
-| `runtime_library_search_directories` | `None`; or [depset](../builtins/depset); default is `None`  Depset of directories where loader will look for libraries at runtime. |
-| `user_link_flags` | `None`; or [sequence](../core/list); default is `None`  List of additional link flags (linkopts). |
+| `library_search_directories` | `None`; or [depset](/versions/7.6.1/rules/lib/builtins/depset); default is `None`  Depset of directories where linker will look for libraries at link time. |
+| `runtime_library_search_directories` | `None`; or [depset](/versions/7.6.1/rules/lib/builtins/depset); default is `None`  Depset of directories where loader will look for libraries at runtime. |
+| `user_link_flags` | `None`; or [sequence](/versions/7.6.1/rules/lib/core/list); default is `None`  List of additional link flags (linkopts). |
 | `output_file` | default is `None`  Optional output file path. |
 | `param_file` | default is `None`  Optional param file path. |
 | `def_file` | default is `None`  Optional .def file path. |
@@ -263,9 +263,9 @@ Creates a `LinkerInput`.
 | Parameter | Description |
 | --- | --- |
 | `owner` | required  The label of the target that produced all files used in this input. |
-| `libraries` | `None`; or [depset](../builtins/depset); default is `None`  List of `LibraryToLink`. |
-| `user_link_flags` | `None`; or [depset](../builtins/depset) of [string](../core/string)s; or [sequence](../core/list) of [string](../core/string)s; default is `None`  User link flags passed as strings. Accepts either [String], [[String]] or depset(String). The latter is discouraged as it's only kept for compatibility purposes, the depset is flattened. If you want to propagate user\_link\_flags via unflattened depsets() wrap them in a LinkerInput so that they are not flattened till the end. |
-| `additional_inputs` | `None`; or [depset](../builtins/depset); default is `None`  For additional inputs to the linking action, e.g.: linking scripts. |
+| `libraries` | `None`; or [depset](/versions/7.6.1/rules/lib/builtins/depset); default is `None`  List of `LibraryToLink`. |
+| `user_link_flags` | `None`; or [depset](/versions/7.6.1/rules/lib/builtins/depset) of [string](/versions/7.6.1/rules/lib/core/string)s; or [sequence](/versions/7.6.1/rules/lib/core/list) of [string](/versions/7.6.1/rules/lib/core/string)s; default is `None`  User link flags passed as strings. Accepts either [String], [[String]] or depset(String). The latter is discouraged as it's only kept for compatibility purposes, the depset is flattened. If you want to propagate user\_link\_flags via unflattened depsets() wrap them in a LinkerInput so that they are not flattened till the end. |
+| `additional_inputs` | `None`; or [depset](/versions/7.6.1/rules/lib/builtins/depset); default is `None`  For additional inputs to the linking action, e.g.: linking scripts. |
 
 ## create\_linking\_context
 
@@ -279,10 +279,10 @@ Creates a `LinkingContext`.
 
 | Parameter | Description |
 | --- | --- |
-| `linker_inputs` | `None`; or [depset](../builtins/depset); default is `None`  Depset of `LinkerInput`. |
-| `libraries_to_link` | `None`; or [sequence](../core/list); default is `None`  **Deprecated**. This parameter is deprecated and will be removed soon. Please do not depend on it. It is *disabled* with `--+incompatible_require_linker_input_cc_api`. Use this flag to verify your code is compatible with its imminent removal.  List of `LibraryToLink`. |
-| `user_link_flags` | `None`; or [sequence](../core/list); default is `None` |
-| `additional_inputs` | `None`; or [sequence](../core/list); default is `None` |
+| `linker_inputs` | `None`; or [depset](/versions/7.6.1/rules/lib/builtins/depset); default is `None`  Depset of `LinkerInput`. |
+| `libraries_to_link` | `None`; or [sequence](/versions/7.6.1/rules/lib/core/list); default is `None`  **Deprecated**. This parameter is deprecated and will be removed soon. Please do not depend on it. It is *disabled* with `--+incompatible_require_linker_input_cc_api`. Use this flag to verify your code is compatible with its imminent removal.  List of `LibraryToLink`. |
+| `user_link_flags` | `None`; or [sequence](/versions/7.6.1/rules/lib/core/list); default is `None` |
+| `additional_inputs` | `None`; or [sequence](/versions/7.6.1/rules/lib/core/list); default is `None` |
 
 ## create\_linking\_context\_from\_compilation\_outputs
 
@@ -409,7 +409,7 @@ Should be used for C++ transitive linking.
 | `actions` | required  `actions` object. |
 | `feature_configuration` | required  `feature_configuration` to be queried. |
 | `cc_toolchain` | required  `CcToolchainInfo` provider to be used. |
-| `compilation_outputs` | [CcCompilationOutputs](../builtins/CcCompilationOutputs); or `None`; default is `None`  Compilation outputs containing object files to link. |
+| `compilation_outputs` | [CcCompilationOutputs](/versions/7.6.1/rules/lib/builtins/CcCompilationOutputs); or `None`; default is `None`  Compilation outputs containing object files to link. |
 | `user_link_flags` | default is `[]`  Additional list of linker options. |
 | `linking_contexts` | default is `[]`  Linking contexts from dependencies to be linked into the linking context generated by this rule. |
 | `name` | required  This is used for naming the output artifacts of actions created by this method. |
@@ -417,8 +417,8 @@ Should be used for C++ transitive linking.
 | `output_type` | default is `'executable'`  Can be either 'executable' or 'dynamic\_library'. |
 | `link_deps_statically` | default is `True`  True to link dependencies statically, False dynamically. |
 | `stamp` | default is `0`  Whether to include build information in the linked executable, if output\_type is 'executable'. If 1, build information is always included. If 0 (the default build information is always excluded. If -1, uses the default behavior, which may be overridden by the --[no]stamp flag. This should be unset (or set to 0) when generating the executable output for test rules. |
-| `additional_inputs` | [sequence](../core/list); or [depset](../builtins/depset); default is `[]`  For additional inputs to the linking action, e.g.: linking scripts. |
-| `additional_outputs` | [sequence](../core/list); default is `unbound`  For additional outputs to the linking action, e.g.: map files. |
+| `additional_inputs` | [sequence](/versions/7.6.1/rules/lib/core/list); or [depset](/versions/7.6.1/rules/lib/builtins/depset); default is `[]`  For additional inputs to the linking action, e.g.: linking scripts. |
+| `additional_outputs` | [sequence](/versions/7.6.1/rules/lib/core/list); default is `unbound`  For additional outputs to the linking action, e.g.: map files. |
 
 ## merge\_compilation\_contexts
 
diff --git a/versions/7.6.1/rules/lib/toplevel/config.mdx b/versions/7.6.1/rules/lib/toplevel/config.mdx
index cb118d1f..b7443833 100644
--- a/versions/7.6.1/rules/lib/toplevel/config.mdx
+++ b/versions/7.6.1/rules/lib/toplevel/config.mdx
@@ -48,7 +48,7 @@ Creates an execution transition.
 
 | Parameter | Description |
 | --- | --- |
-| `exec_group` | [string](../core/string); or `None`; default is `None`  The name of the exec group whose execution platform this transition will use. If not provided, this exec transition will use the target's default execution platform. |
+| `exec_group` | [string](/versions/7.6.1/rules/lib/core/string); or `None`; default is `None`  The name of the exec group whose execution platform this transition will use. If not provided, this exec transition will use the target's default execution platform. |
 
 ## int
 
diff --git a/versions/7.6.1/rules/lib/toplevel/config_common.mdx b/versions/7.6.1/rules/lib/toplevel/config_common.mdx
index 9169b17a..2ad65c24 100644
--- a/versions/7.6.1/rules/lib/toplevel/config_common.mdx
+++ b/versions/7.6.1/rules/lib/toplevel/config_common.mdx
@@ -29,5 +29,5 @@ Declare a rule's dependency on a toolchain type.
 
 | Parameter | Description |
 | --- | --- |
-| `name` | [string](../core/string); or [Label](../builtins/Label); required  The toolchain type that is required. |
-| `mandatory` | [bool](../core/bool); default is `True`  Whether the toolchain type is mandatory or optional. |
\ No newline at end of file
+| `name` | [string](/versions/7.6.1/rules/lib/core/string); or [Label](/versions/7.6.1/rules/lib/builtins/Label); required  The toolchain type that is required. |
+| `mandatory` | [bool](/versions/7.6.1/rules/lib/core/bool); default is `True`  Whether the toolchain type is mandatory or optional. |
\ No newline at end of file
diff --git a/versions/7.6.1/rules/lib/toplevel/coverage_common.mdx b/versions/7.6.1/rules/lib/toplevel/coverage_common.mdx
index ab2b343b..46fd21bb 100644
--- a/versions/7.6.1/rules/lib/toplevel/coverage_common.mdx
+++ b/versions/7.6.1/rules/lib/toplevel/coverage_common.mdx
@@ -14,7 +14,7 @@ Helper functions to access coverage-related infrastructure.
 InstrumentedFilesInfo coverage_common.instrumented_files_info(ctx, *, source_attributes=[], dependency_attributes=[], extensions=None, metadata_files=[])
 ```
 
-Creates a new [InstrumentedFilesInfo](../providers/InstrumentedFilesInfo) instance. Use this provider to communicate coverage-related attributes of the current build rule.
+Creates a new [InstrumentedFilesInfo](/versions/7.6.1/rules/lib/providers/InstrumentedFilesInfo) instance. Use this provider to communicate coverage-related attributes of the current build rule.
 
 ### Parameters
 
@@ -23,5 +23,5 @@ Creates a new [InstrumentedFilesInfo](../providers/InstrumentedFilesInfo) instan
 | `ctx` | required  The rule context. |
 | `source_attributes` | default is `[]`  A list of attribute names which contain source files processed by this rule. |
 | `dependency_attributes` | default is `[]`  A list of attribute names which might provide runtime dependencies (either code dependencies or runfiles). |
-| `extensions` | [sequence](../core/list) of [string](../core/string)s; or `None`; default is `None`  File extensions used to filter files from source\_attributes. For example, 'js'. If not provided (or None), then all files from source\_attributes will be added to instrumented files, if an empty list is provided, then no files from source attributes will be added. |
-| `metadata_files` | [sequence](../core/list) of [File](../builtins/File)s; default is `[]`  Additional files required to generate coverage LCOV files after code execution. e.g. .gcno files for C++. |
\ No newline at end of file
+| `extensions` | [sequence](/versions/7.6.1/rules/lib/core/list) of [string](/versions/7.6.1/rules/lib/core/string)s; or `None`; default is `None`  File extensions used to filter files from source\_attributes. For example, 'js'. If not provided (or None), then all files from source\_attributes will be added to instrumented files, if an empty list is provided, then no files from source attributes will be added. |
+| `metadata_files` | [sequence](/versions/7.6.1/rules/lib/core/list) of [File](/versions/7.6.1/rules/lib/builtins/File)s; default is `[]`  Additional files required to generate coverage LCOV files after code execution. e.g. .gcno files for C++. |
\ No newline at end of file
diff --git a/versions/7.6.1/rules/lib/toplevel/java_common.mdx b/versions/7.6.1/rules/lib/toplevel/java_common.mdx
index 062cfd9e..f7444a2d 100644
--- a/versions/7.6.1/rules/lib/toplevel/java_common.mdx
+++ b/versions/7.6.1/rules/lib/toplevel/java_common.mdx
@@ -36,32 +36,32 @@ Compiles Java source files/jars from the implementation of a Starlark rule and r
 | Parameter | Description |
 | --- | --- |
 | `ctx` | required  The rule context. |
-| `source_jars` | [sequence](../core/list) of [File](../builtins/File)s; default is `[]`  A list of the jars to be compiled. At least one of source\_jars or source\_files should be specified. |
-| `source_files` | [sequence](../core/list) of [File](../builtins/File)s; default is `[]`  A list of the Java source files to be compiled. At least one of source\_jars or source\_files should be specified. |
+| `source_jars` | [sequence](/versions/7.6.1/rules/lib/core/list) of [File](/versions/7.6.1/rules/lib/builtins/File)s; default is `[]`  A list of the jars to be compiled. At least one of source\_jars or source\_files should be specified. |
+| `source_files` | [sequence](/versions/7.6.1/rules/lib/core/list) of [File](/versions/7.6.1/rules/lib/builtins/File)s; default is `[]`  A list of the Java source files to be compiled. At least one of source\_jars or source\_files should be specified. |
 | `output` | required |
-| `output_source_jar` | [File](../builtins/File); or `None`; default is `None`  The output source jar. Optional. Defaults to `{output\_jar}-src.jar` if unset. |
-| `javac_opts` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  A list of the desired javac options. Optional. |
-| `deps` | [sequence](../core/list) of [struct](../builtins/struct)s; default is `[]`  A list of dependencies. Optional. |
-| `runtime_deps` | [sequence](../core/list) of [struct](../builtins/struct)s; default is `[]`  A list of runtime dependencies. Optional. |
-| `exports` | [sequence](../core/list) of [struct](../builtins/struct)s; default is `[]`  A list of exports. Optional. |
-| `plugins` | [sequence](../core/list) of [struct](../builtins/struct)s; or [sequence](../core/list) of [struct](../builtins/struct)s; default is `[]`  A list of plugins. Optional. |
-| `exported_plugins` | [sequence](../core/list) of [struct](../builtins/struct)s; or [sequence](../core/list) of [struct](../builtins/struct)s; default is `[]`  A list of exported plugins. Optional. |
-| `native_libraries` | [sequence](../core/list) of [CcInfo](../providers/CcInfo)s; default is `[]`  CC native library dependencies that are needed for this library. |
-| `annotation_processor_additional_inputs` | [sequence](../core/list) of [File](../builtins/File)s; default is `[]`  A list of inputs that the Java compilation action will take in addition to the Java sources for annotation processing. |
-| `annotation_processor_additional_outputs` | [sequence](../core/list) of [File](../builtins/File)s; default is `[]`  A list of outputs that the Java compilation action will output in addition to the class jar from annotation processing. |
+| `output_source_jar` | [File](/versions/7.6.1/rules/lib/builtins/File); or `None`; default is `None`  The output source jar. Optional. Defaults to `{output\_jar}-src.jar` if unset. |
+| `javac_opts` | [sequence](/versions/7.6.1/rules/lib/core/list) of [string](/versions/7.6.1/rules/lib/core/string)s; default is `[]`  A list of the desired javac options. Optional. |
+| `deps` | [sequence](/versions/7.6.1/rules/lib/core/list) of [struct](/versions/7.6.1/rules/lib/builtins/struct)s; default is `[]`  A list of dependencies. Optional. |
+| `runtime_deps` | [sequence](/versions/7.6.1/rules/lib/core/list) of [struct](/versions/7.6.1/rules/lib/builtins/struct)s; default is `[]`  A list of runtime dependencies. Optional. |
+| `exports` | [sequence](/versions/7.6.1/rules/lib/core/list) of [struct](/versions/7.6.1/rules/lib/builtins/struct)s; default is `[]`  A list of exports. Optional. |
+| `plugins` | [sequence](/versions/7.6.1/rules/lib/core/list) of [struct](/versions/7.6.1/rules/lib/builtins/struct)s; or [sequence](/versions/7.6.1/rules/lib/core/list) of [struct](/versions/7.6.1/rules/lib/builtins/struct)s; default is `[]`  A list of plugins. Optional. |
+| `exported_plugins` | [sequence](/versions/7.6.1/rules/lib/core/list) of [struct](/versions/7.6.1/rules/lib/builtins/struct)s; or [sequence](/versions/7.6.1/rules/lib/core/list) of [struct](/versions/7.6.1/rules/lib/builtins/struct)s; default is `[]`  A list of exported plugins. Optional. |
+| `native_libraries` | [sequence](/versions/7.6.1/rules/lib/core/list) of [CcInfo](/versions/7.6.1/rules/lib/providers/CcInfo)s; default is `[]`  CC native library dependencies that are needed for this library. |
+| `annotation_processor_additional_inputs` | [sequence](/versions/7.6.1/rules/lib/core/list) of [File](/versions/7.6.1/rules/lib/builtins/File)s; default is `[]`  A list of inputs that the Java compilation action will take in addition to the Java sources for annotation processing. |
+| `annotation_processor_additional_outputs` | [sequence](/versions/7.6.1/rules/lib/core/list) of [File](/versions/7.6.1/rules/lib/builtins/File)s; default is `[]`  A list of outputs that the Java compilation action will output in addition to the class jar from annotation processing. |
 | `strict_deps` | default is `'ERROR'`  A string that specifies how to handle strict deps. Possible values: 'OFF', 'ERROR', 'WARN' and 'DEFAULT'. For more details see /docs/user-manual#flag--strict\_java\_deps. By default 'ERROR'. |
 | `java_toolchain` | required  A JavaToolchainInfo to be used for this compilation. Mandatory. |
 | `bootclasspath` | default is `None`  A BootClassPathInfo to be used for this compilation. If present, overrides the bootclasspath associated with the provided java\_toolchain. Optional. |
 | `host_javabase` | default is `None`  **Deprecated**. This parameter is deprecated and will be removed soon. Please do not depend on it. It is *disabled* with `--+incompatible_java_common_parameters`. Use this flag to verify your code is compatible with its imminent removal.  Deprecated: You can drop this parameter (host\_javabase is provided with java\_toolchain) |
-| `sourcepath` | [sequence](../core/list) of [File](../builtins/File)s; default is `[]` |
-| `resources` | [sequence](../core/list) of [File](../builtins/File)s; default is `[]` |
-| `resource_jars` | [sequence](../core/list) of [File](../builtins/File)s; default is `[]` |
-| `classpath_resources` | [sequence](../core/list) of [File](../builtins/File)s; default is `[]` |
+| `sourcepath` | [sequence](/versions/7.6.1/rules/lib/core/list) of [File](/versions/7.6.1/rules/lib/builtins/File)s; default is `[]` |
+| `resources` | [sequence](/versions/7.6.1/rules/lib/core/list) of [File](/versions/7.6.1/rules/lib/builtins/File)s; default is `[]` |
+| `resource_jars` | [sequence](/versions/7.6.1/rules/lib/core/list) of [File](/versions/7.6.1/rules/lib/builtins/File)s; default is `[]` |
+| `classpath_resources` | [sequence](/versions/7.6.1/rules/lib/core/list) of [File](/versions/7.6.1/rules/lib/builtins/File)s; default is `[]` |
 | `neverlink` | default is `False` |
 | `enable_annotation_processing` | default is `True`  Disables annotation processing in this compilation, causing any annotation processors provided in plugins or in exported\_plugins of deps to be ignored. |
 | `enable_compile_jar_action` | default is `True`  Enables header compilation or ijar creation. If set to False, it forces use of the full class jar in the compilation classpaths of any dependants. Doing so is intended for use by non-library targets such as binaries that do not have dependants. |
-| `add_exports` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  Allow this library to access the given /. Optional. |
-| `add_opens` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  Allow this library to reflectively access the given /. Optional. |
+| `add_exports` | [sequence](/versions/7.6.1/rules/lib/core/list) of [string](/versions/7.6.1/rules/lib/core/string)s; default is `[]`  Allow this library to access the given /. Optional. |
+| `add_opens` | [sequence](/versions/7.6.1/rules/lib/core/list) of [string](/versions/7.6.1/rules/lib/core/string)s; default is `[]`  Allow this library to reflectively access the given /. Optional. |
 
 ## JavaRuntimeInfo
 
@@ -91,7 +91,7 @@ Merges the given providers into a single JavaInfo.
 
 | Parameter | Description |
 | --- | --- |
-| `providers` | [sequence](../core/list) of [struct](../builtins/struct)s; required  The list of providers to merge. |
+| `providers` | [sequence](/versions/7.6.1/rules/lib/core/list) of [struct](/versions/7.6.1/rules/lib/builtins/struct)s; required  The list of providers to merge. |
 
 ## pack\_sources
 
@@ -110,10 +110,10 @@ Packs sources and source jars into a single source jar file. The return value is
 | Parameter | Description |
 | --- | --- |
 | `actions` | required  ctx.actions |
-| `output_jar` | [File](../builtins/File); or `None`; default is `None`  **Deprecated**. This parameter is deprecated and will be removed soon. Please do not depend on it. It is *disabled* with `--+incompatible_java_common_parameters`. Use this flag to verify your code is compatible with its imminent removal.  Deprecated: The output jar of the rule. Used to name the resulting source jar. The parameter sets output\_source\_jar parameter to `{output\_jar}-src.jar`.Use output\_source\_jar parameter directly instead. |
-| `output_source_jar` | [File](../builtins/File); or `None`; default is `None` |
-| `sources` | [sequence](../core/list) of [File](../builtins/File)s; default is `[]`  A list of Java source files to be packed into the source jar. |
-| `source_jars` | [sequence](../core/list) of [File](../builtins/File)s; default is `[]`  A list of source jars to be packed into the source jar. |
+| `output_jar` | [File](/versions/7.6.1/rules/lib/builtins/File); or `None`; default is `None`  **Deprecated**. This parameter is deprecated and will be removed soon. Please do not depend on it. It is *disabled* with `--+incompatible_java_common_parameters`. Use this flag to verify your code is compatible with its imminent removal.  Deprecated: The output jar of the rule. Used to name the resulting source jar. The parameter sets output\_source\_jar parameter to `{output\_jar}-src.jar`.Use output\_source\_jar parameter directly instead. |
+| `output_source_jar` | [File](/versions/7.6.1/rules/lib/builtins/File); or `None`; default is `None` |
+| `sources` | [sequence](/versions/7.6.1/rules/lib/core/list) of [File](/versions/7.6.1/rules/lib/builtins/File)s; default is `[]`  A list of Java source files to be packed into the source jar. |
+| `source_jars` | [sequence](/versions/7.6.1/rules/lib/core/list) of [File](/versions/7.6.1/rules/lib/builtins/File)s; default is `[]`  A list of source jars to be packed into the source jar. |
 | `java_toolchain` | required  A JavaToolchainInfo to used to find the ijar tool. |
 | `host_javabase` | default is `None`  **Deprecated**. This parameter is deprecated and will be removed soon. Please do not depend on it. It is *disabled* with `--+incompatible_java_common_parameters`. Use this flag to verify your code is compatible with its imminent removal.  Deprecated: You can drop this parameter (host\_javabase is provided with java\_toolchain) |
 
@@ -131,7 +131,7 @@ Runs ijar on a jar, stripping it of its method bodies. This helps reduce rebuild
 | --- | --- |
 | `actions` | required |
 | `jar` | required  The jar to run ijar on. |
-| `target_label` | [Label](../builtins/Label); or `None`; default is `None`  A target label to stamp the jar with. Used for `add_dep` support. Typically, you would pass `ctx.label` to stamp the jar with the current rule's label. |
+| `target_label` | [Label](/versions/7.6.1/rules/lib/builtins/Label); or `None`; default is `None`  A target label to stamp the jar with. Used for `add_dep` support. Typically, you would pass `ctx.label` to stamp the jar with the current rule's label. |
 | `java_toolchain` | required  A JavaToolchainInfo to used to find the ijar tool. |
 
 ## stamp\_jar
diff --git a/versions/7.6.1/rules/lib/toplevel/native.mdx b/versions/7.6.1/rules/lib/toplevel/native.mdx
index d819eec9..7b9092bc 100644
--- a/versions/7.6.1/rules/lib/toplevel/native.mdx
+++ b/versions/7.6.1/rules/lib/toplevel/native.mdx
@@ -76,9 +76,9 @@ Specifies a list of files belonging to this package that are exported to other p
 
 | Parameter | Description |
 | --- | --- |
-| `srcs` | [sequence](../core/list) of [string](../core/string)s; required  The list of files to export. |
-| `visibility` | [sequence](../core/list); or `None`; default is `None`  A visibility declaration can to be specified. The files will be visible to the targets specified. If no visibility is specified, the files will be visible to every package. |
-| `licenses` | [sequence](../core/list) of [string](../core/string)s; or `None`; default is `None`  Licenses to be specified. |
+| `srcs` | [sequence](/versions/7.6.1/rules/lib/core/list) of [string](/versions/7.6.1/rules/lib/core/string)s; required  The list of files to export. |
+| `visibility` | [sequence](/versions/7.6.1/rules/lib/core/list); or `None`; default is `None`  A visibility declaration can to be specified. The files will be visible to the targets specified. If no visibility is specified, the files will be visible to every package. |
+| `licenses` | [sequence](/versions/7.6.1/rules/lib/core/list) of [string](/versions/7.6.1/rules/lib/core/string)s; or `None`; default is `None`  Licenses to be specified. |
 
 ## glob
 
@@ -97,8 +97,8 @@ If the `exclude_directories` argument is enabled (set to `1`), files of type dir
 
 | Parameter | Description |
 | --- | --- |
-| `include` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  The list of glob patterns to include. |
-| `exclude` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  The list of glob patterns to exclude. |
+| `include` | [sequence](/versions/7.6.1/rules/lib/core/list) of [string](/versions/7.6.1/rules/lib/core/string)s; default is `[]`  The list of glob patterns to include. |
+| `exclude` | [sequence](/versions/7.6.1/rules/lib/core/list) of [string](/versions/7.6.1/rules/lib/core/string)s; default is `[]`  The list of glob patterns to exclude. |
 | `exclude_directories` | default is `1`  A flag whether to exclude directories or not. |
 | `allow_empty` | default is `unbound`  Whether we allow glob patterns to match nothing. If `allow\_empty` is False, each individual include pattern must match something and also the final result must be non-empty (after the matches of the `exclude` patterns are excluded). |
 
@@ -133,8 +133,8 @@ This function defines a set of packages and assigns a label to the group. The la
 | Parameter | Description |
 | --- | --- |
 | `name` | required  The unique name for this rule. |
-| `packages` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  A complete enumeration of packages in this group. |
-| `includes` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  Other package groups that are included in this one. |
+| `packages` | [sequence](/versions/7.6.1/rules/lib/core/list) of [string](/versions/7.6.1/rules/lib/core/string)s; default is `[]`  A complete enumeration of packages in this group. |
+| `includes` | [sequence](/versions/7.6.1/rules/lib/core/list) of [string](/versions/7.6.1/rules/lib/core/string)s; default is `[]`  Other package groups that are included in this one. |
 
 ## package\_name
 
@@ -150,19 +150,19 @@ The name of the package being evaluated, without the repository name. For exampl
 Label native.package_relative_label(input)
 ```
 
-Converts the input string into a [Label](../builtins/Label) object, in the context of the package currently being initialized (that is, the `BUILD` file for which the current macro is executing). If the input is already a `Label`, it is returned unchanged.
+Converts the input string into a [Label](/versions/7.6.1/rules/lib/builtins/Label) object, in the context of the package currently being initialized (that is, the `BUILD` file for which the current macro is executing). If the input is already a `Label`, it is returned unchanged.
 
 This function may only be called while evaluating a BUILD file and the macros it directly or indirectly calls; it may not be called in (for instance) a rule implementation function.
 
 The result of this function is the same `Label` value as would be produced by passing the given string to a label-valued attribute of a target declared in the BUILD file.
 
-*Usage note:* The difference between this function and [Label()](../builtins/Label#Label) is that `Label()` uses the context of the package of the `.bzl` file that called it, not the package of the `BUILD` file. Use `Label()` when you need to refer to a fixed target that is hardcoded into the macro, such as a compiler. Use `package_relative_label()` when you need to normalize a label string supplied by the BUILD file to a `Label` object. (There is no way to convert a string to a `Label` in the context of a package other than the BUILD file or the calling .bzl file. For that reason, outer macros should always prefer to pass Label objects to inner macros rather than label strings.)
+*Usage note:* The difference between this function and [Label()](/versions/7.6.1/rules/lib/builtins/Label#Label) is that `Label()` uses the context of the package of the `.bzl` file that called it, not the package of the `BUILD` file. Use `Label()` when you need to refer to a fixed target that is hardcoded into the macro, such as a compiler. Use `package_relative_label()` when you need to normalize a label string supplied by the BUILD file to a `Label` object. (There is no way to convert a string to a `Label` in the context of a package other than the BUILD file or the calling .bzl file. For that reason, outer macros should always prefer to pass Label objects to inner macros rather than label strings.)
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `input` | [string](../core/string); or [Label](../builtins/Label); required  The input label string or Label object. If a Label object is passed, it's returned as is. |
+| `input` | [string](/versions/7.6.1/rules/lib/core/string); or [Label](/versions/7.6.1/rules/lib/builtins/Label); required  The input label string or Label object. If a Label object is passed, it's returned as is. |
 
 ## repo\_name
 
@@ -195,6 +195,6 @@ Returns a new mutable list of every direct subpackage of the current package, re
 
 | Parameter | Description |
 | --- | --- |
-| `include` | [sequence](../core/list) of [string](../core/string)s; required |
-| `exclude` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  The list of glob patterns to exclude from subpackages scan. |
+| `include` | [sequence](/versions/7.6.1/rules/lib/core/list) of [string](/versions/7.6.1/rules/lib/core/string)s; required |
+| `exclude` | [sequence](/versions/7.6.1/rules/lib/core/list) of [string](/versions/7.6.1/rules/lib/core/string)s; default is `[]`  The list of glob patterns to exclude from subpackages scan. |
 | `allow_empty` | default is `False`  Whether we fail if the call returns an empty list. By default empty list indicates potential error in BUILD file where the call to subpackages() is superflous. Setting to true allows this function to succeed in that case. |
\ No newline at end of file
diff --git a/versions/7.6.1/rules/lib/toplevel/platform_common.mdx b/versions/7.6.1/rules/lib/toplevel/platform_common.mdx
index 17edc7c5..3f2a12a1 100644
--- a/versions/7.6.1/rules/lib/toplevel/platform_common.mdx
+++ b/versions/7.6.1/rules/lib/toplevel/platform_common.mdx
@@ -18,7 +18,7 @@ Functions for Starlark to interact with the platform APIs.
 Provider platform_common.ConstraintSettingInfo
 ```
 
-The constructor/key for the [ConstraintSettingInfo](../providers/ConstraintSettingInfo) provider.
+The constructor/key for the [ConstraintSettingInfo](/versions/7.6.1/rules/lib/providers/ConstraintSettingInfo) provider.
 *Note: This API is experimental and may change at any time. It is disabled by default, but may be enabled with `--experimental_platforms_api`*
 
 ## ConstraintValueInfo
@@ -27,7 +27,7 @@ The constructor/key for the [ConstraintSettingInfo](../providers/ConstraintSetti
 Provider platform_common.ConstraintValueInfo
 ```
 
-The constructor/key for the [ConstraintValueInfo](../providers/ConstraintValueInfo) provider.
+The constructor/key for the [ConstraintValueInfo](/versions/7.6.1/rules/lib/providers/ConstraintValueInfo) provider.
 *Note: This API is experimental and may change at any time. It is disabled by default, but may be enabled with `--experimental_platforms_api`*
 
 ## PlatformInfo
@@ -36,7 +36,7 @@ The constructor/key for the [ConstraintValueInfo](../providers/ConstraintValueIn
 Provider platform_common.PlatformInfo
 ```
 
-The constructor/key for the [PlatformInfo](../providers/PlatformInfo) provider.
+The constructor/key for the [PlatformInfo](/versions/7.6.1/rules/lib/providers/PlatformInfo) provider.
 *Note: This API is experimental and may change at any time. It is disabled by default, but may be enabled with `--experimental_platforms_api`*
 
 ## TemplateVariableInfo
@@ -45,7 +45,7 @@ The constructor/key for the [PlatformInfo](../providers/PlatformInfo) provider.
 Provider platform_common.TemplateVariableInfo
 ```
 
-The constructor/key for the [TemplateVariableInfo](../providers/TemplateVariableInfo) provider.
+The constructor/key for the [TemplateVariableInfo](/versions/7.6.1/rules/lib/providers/TemplateVariableInfo) provider.
 
 ## ToolchainInfo
 
@@ -53,4 +53,4 @@ The constructor/key for the [TemplateVariableInfo](../providers/TemplateVariable
 Provider platform_common.ToolchainInfo
 ```
 
-The constructor/key for the [ToolchainInfo](../providers/ToolchainInfo) provider.
\ No newline at end of file
+The constructor/key for the [ToolchainInfo](/versions/7.6.1/rules/lib/providers/ToolchainInfo) provider.
\ No newline at end of file
diff --git a/versions/7.6.1/rules/lib/toplevel/testing.mdx b/versions/7.6.1/rules/lib/toplevel/testing.mdx
index ffd4f89f..d342399d 100644
--- a/versions/7.6.1/rules/lib/toplevel/testing.mdx
+++ b/versions/7.6.1/rules/lib/toplevel/testing.mdx
@@ -25,11 +25,11 @@ The number of transitive dependencies of the test are limited. The limit is cont
 | Parameter | Description |
 | --- | --- |
 | `name` | required  Name of the target. It should be a Starlark identifier, matching pattern '[A-Za-z\_][A-Za-z0-9\_]\*'. |
-| `implementation` | required  The Starlark function implementing this analysis test. It must have exactly one parameter: [ctx](../builtins/ctx). The function is called during the analysis phase. It can access the attributes declared by `attrs` and populated via `attr_values`. The implementation function may not register actions. Instead, it must register a pass/fail result via providing [AnalysisTestResultInfo](../providers/AnalysisTestResultInfo). |
-| `attrs` | [dict](../core/dict); default is `{}`  Dictionary declaring the attributes. See the [rule](../globals/bzl#rule) call. Attributes are allowed to use configuration transitions defined using [analysis\_test\_transition](../globals/bzl#analysis_test_transition). |
-| `fragments` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  List of configuration fragments that are available to the implementation of the analysis test. |
-| `toolchains` | [sequence](../core/list); default is `[]`  The set of toolchains the test requires. See the [rule](../globals/bzl#rule) call. |
-| `attr_values` | [dict](../core/dict) of [string](../core/string)s; default is `{}`  Dictionary of attribute values to pass to the implementation. |
+| `implementation` | required  The Starlark function implementing this analysis test. It must have exactly one parameter: [ctx](/versions/7.6.1/rules/lib/builtins/ctx). The function is called during the analysis phase. It can access the attributes declared by `attrs` and populated via `attr_values`. The implementation function may not register actions. Instead, it must register a pass/fail result via providing [AnalysisTestResultInfo](/versions/7.6.1/rules/lib/providers/AnalysisTestResultInfo). |
+| `attrs` | [dict](/versions/7.6.1/rules/lib/core/dict); default is `{}`  Dictionary declaring the attributes. See the [rule](/versions/7.6.1/rules/lib/globals/bzl#rule) call. Attributes are allowed to use configuration transitions defined using [analysis\_test\_transition](/versions/7.6.1/rules/lib/globals/bzl#analysis_test_transition). |
+| `fragments` | [sequence](/versions/7.6.1/rules/lib/core/list) of [string](/versions/7.6.1/rules/lib/core/string)s; default is `[]`  List of configuration fragments that are available to the implementation of the analysis test. |
+| `toolchains` | [sequence](/versions/7.6.1/rules/lib/core/list); default is `[]`  The set of toolchains the test requires. See the [rule](/versions/7.6.1/rules/lib/globals/bzl#rule) call. |
+| `attr_values` | [dict](/versions/7.6.1/rules/lib/core/dict) of [string](/versions/7.6.1/rules/lib/core/string)s; default is `{}`  Dictionary of attribute values to pass to the implementation. |
 
 ## ExecutionInfo
 
@@ -37,7 +37,7 @@ The number of transitive dependencies of the test are limited. The limit is cont
 ExecutionInfo testing.ExecutionInfo(requirements={}, exec_group='test')
 ```
 
-[testing.ExecutionInfo](../providers/ExecutionInfo) provider key/constructor
+[testing.ExecutionInfo](/versions/7.6.1/rules/lib/providers/ExecutionInfo) provider key/constructor
 
 ## TestEnvironment
 
@@ -52,4 +52,4 @@ RunEnvironmentInfo testing.TestEnvironment(environment, inherited_environment=[]
 | Parameter | Description |
 | --- | --- |
 | `environment` | required  A map of string keys and values that represent environment variables and their values. These will be made available during the test execution. |
-| `inherited_environment` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  A sequence of names of environment variables. These variables are made available during the test execution with their current value taken from the shell environment. If a variable is contained in both `environment` and `inherited_environment`, the value inherited from the shell environment will take precedence if set. |
\ No newline at end of file
+| `inherited_environment` | [sequence](/versions/7.6.1/rules/lib/core/list) of [string](/versions/7.6.1/rules/lib/core/string)s; default is `[]`  A sequence of names of environment variables. These variables are made available during the test execution with their current value taken from the shell environment. If a variable is contained in both `environment` and `inherited_environment`, the value inherited from the shell environment will take precedence if set. |
\ No newline at end of file
diff --git a/versions/7.6.1/rules/performance.mdx b/versions/7.6.1/rules/performance.mdx
index 60c35dcc..10b9ded9 100644
--- a/versions/7.6.1/rules/performance.mdx
+++ b/versions/7.6.1/rules/performance.mdx
@@ -15,7 +15,7 @@ widespread use.
 ## Use depsets {#use-depsets}
 
 Whenever you are rolling up information from rule dependencies you should use
-[depsets](lib/depset). Only use plain lists or dicts to publish information
+[depsets](/versions/7.6.1/rules/lib/builtins/depset). Only use plain lists or dicts to publish information
 local to the current rule.
 
 A depset represents information as a nested graph which enables sharing.
@@ -73,7 +73,7 @@ See the [depset overview](/versions/7.6.1/extending/depsets) page for more infor
 ### Avoid calling `depset.to_list()` {#avoid-depset-to-list}
 
 You can coerce a depset to a flat list using
-[`to_list()`](lib/depset#to_list), but doing so usually results in O(N^2)
+[`to_list()`](/versions/7.6.1/rules/lib/builtins/depset#to_list), but doing so usually results in O(N^2)
 cost. If at all possible, avoid any flattening of depsets except for debugging
 purposes.
 
@@ -115,7 +115,7 @@ x = depset(transitive = [i.deps for i in inputs])
 
 ## Use ctx.actions.args() for command lines {#ctx-actions-args}
 
-When building command lines you should use [ctx.actions.args()](lib/Args).
+When building command lines you should use [ctx.actions.args()](/versions/7.6.1/rules/lib/builtins/Args).
 This defers expansion of any depsets to the execution phase.
 
 Apart from being strictly faster, this will reduce the memory consumption of
@@ -126,11 +126,11 @@ Here are some tricks:
 * Pass depsets and lists directly as arguments, instead of flattening them
 yourself. They will get expanded by `ctx.actions.args()` for you.
 If you need any transformations on the depset contents, look at
-[ctx.actions.args#add](lib/Args#add) to see if anything fits the bill.
+[ctx.actions.args#add](/versions/7.6.1/rules/lib/builtins/Args#add) to see if anything fits the bill.
 
 * Are you passing `File#path` as arguments? No need. Any
-[File](lib/File) is automatically turned into its
-[path](lib/File#path), deferred to expansion time.
+[File](/versions/7.6.1/rules/lib/builtins/File) is automatically turned into its
+[path](/versions/7.6.1/rules/lib/builtins/File#path), deferred to expansion time.
 
 * Avoid constructing strings by concatenating them together.
 The best string argument is a constant as its memory will be shared between
@@ -138,10 +138,10 @@ all instances of your rule.
 
 * If the args are too long for the command line an `ctx.actions.args()` object
 can be conditionally or unconditionally written to a param file using
-[`ctx.actions.args#use_param_file`](lib/Args#use_param_file). This is
+[`ctx.actions.args#use_param_file`](/versions/7.6.1/rules/lib/builtins/Args#use_param_file). This is
 done behind the scenes when the action is executed. If you need to explicitly
 control the params file you can write it manually using
-[`ctx.actions.write`](lib/actions#write).
+[`ctx.actions.write`](/versions/7.6.1/rules/lib/builtins/actions#write).
 
 Example:
 
@@ -176,7 +176,7 @@ def _to_short_path(f):
 
 ## Transitive action inputs should be depsets {#transitive-action-inputs}
 
-When building an action using [ctx.actions.run](lib/actions?#run), do not
+When building an action using [ctx.actions.run](/versions/7.6.1/rules/lib/builtins/actions#run), do not
 forget that the `inputs` field accepts a depset. Use this whenever inputs are
 collected from dependencies transitively.
 
diff --git a/versions/7.6.1/rules/rules-tutorial.mdx b/versions/7.6.1/rules/rules-tutorial.mdx
index c8c69d75..11631f0f 100644
--- a/versions/7.6.1/rules/rules-tutorial.mdx
+++ b/versions/7.6.1/rules/rules-tutorial.mdx
@@ -31,9 +31,9 @@ foo_binary = rule(
 )
 ```
 
-When you call the [`rule`](lib/globals#rule) function, you
+When you call the [`rule`](/versions/7.6.1/rules/lib/globals#rule) function, you
 must define a callback function. The logic will go there, but you
-can leave the function empty for now. The [`ctx`](lib/ctx) argument
+can leave the function empty for now. The [`ctx`](/versions/7.6.1/rules/lib/builtins/ctx) argument
 provides information about the target.
 
 You can load the rule and use it from a `BUILD` file.
@@ -86,10 +86,10 @@ foo_binary(name = "bin1")
 foo_binary(name = "bin2")
 ```
 
-[`ctx.label`](lib/ctx#label)
+[`ctx.label`](/versions/7.6.1/rules/lib/builtins/ctx#label)
 corresponds to the label of the target being analyzed. The `ctx` object has
 many useful fields and methods; you can find an exhaustive list in the
-[API reference](lib/ctx).
+[API reference](/versions/7.6.1/rules/lib/builtins/ctx).
 
 Query the code:
 
@@ -145,7 +145,7 @@ bin2
 ```
 
 Whenever you declare a file, you have to tell Bazel how to generate it by
-creating an action. Use [`ctx.actions.write`](lib/actions#write),
+creating an action. Use [`ctx.actions.write`](/versions/7.6.1/rules/lib/builtins/actions#write),
 to create a file with the given content.
 
 ```python
@@ -200,7 +200,7 @@ You have successfully generated a file!
 ## Attributes
 
 To make the rule more useful, add new attributes using
-[the `attr` module](lib/attr) and update the rule definition.
+[the `attr` module](/versions/7.6.1/rules/lib/toplevel/attr) and update the rule definition.
 
 Add a string attribute called `username`:
 
@@ -236,22 +236,22 @@ def _foo_binary_impl(ctx):
 ```
 
 Note that you can make the attribute mandatory or set a default value. Look at
-the documentation of [`attr.string`](lib/attr#string).
-You may also use other types of attributes, such as [boolean](lib/attr#bool)
-or [list of integers](lib/attr#int_list).
+the documentation of [`attr.string`](/versions/7.6.1/rules/lib/toplevel/attr#string).
+You may also use other types of attributes, such as [boolean](/versions/7.6.1/rules/lib/toplevel/attr#bool)
+or [list of integers](/versions/7.6.1/rules/lib/toplevel/attr#int_list).
 
 ## Dependencies
 
-Dependency attributes, such as [`attr.label`](lib/attr#label)
-and [`attr.label_list`](lib/attr#label_list),
+Dependency attributes, such as [`attr.label`](/versions/7.6.1/rules/lib/toplevel/attr#label)
+and [`attr.label_list`](/versions/7.6.1/rules/lib/toplevel/attr#label_list),
 declare a dependency from the target that owns the attribute to the target whose
 label appears in the attribute's value. This kind of attribute forms the basis
 of the target graph.
 
 In the `BUILD` file, the target label appears as a string object, such as
 `//pkg:name`. In the implementation function, the target will be accessible as a
-[`Target`](lib/Target) object. For example, view the files returned
-by the target using [`Target.files`](lib/Target#modules.Target.files).
+[`Target`](/versions/7.6.1/rules/lib/builtins/Target) object. For example, view the files returned
+by the target using [`Target.files`](/versions/7.6.1/rules/lib/builtins/Target#modules.Target.files).
 
 ### Multiple files
 
@@ -294,7 +294,7 @@ implementation function, but this has two problems. First, as the template gets
 bigger, it becomes more memory efficient to put it in a separate file and avoid
 constructing large strings during the analysis phase. Second, using a separate
 file is more convenient for the user. Instead, use
-[`ctx.actions.expand_template`](lib/actions#expand_template),
+[`ctx.actions.expand_template`](/versions/7.6.1/rules/lib/builtins/actions#expand_template),
 which performs substitutions on a template file.
 
 Create a `template` attribute to declare a dependency on the template
diff --git a/versions/7.6.1/rules/testing.mdx b/versions/7.6.1/rules/testing.mdx
index 2130b4a3..02e2e7e6 100644
--- a/versions/7.6.1/rules/testing.mdx
+++ b/versions/7.6.1/rules/testing.mdx
@@ -234,7 +234,7 @@ def _inspect_actions_test_impl(ctx):
 ```
 
 Note that `analysistest.target_actions(env)` returns a list of
-[`Action`](lib/Action) objects which represent actions registered by the
+[`Action`](/versions/7.6.1/rules/lib/builtins/Action) objects which represent actions registered by the
 target under test.
 
 ### Verifying rule behavior under different flags {#verifying-rule-behavior}
diff --git a/versions/7.6.1/rules/verbs-tutorial.mdx b/versions/7.6.1/rules/verbs-tutorial.mdx
index 9eef6f5d..90585723 100644
--- a/versions/7.6.1/rules/verbs-tutorial.mdx
+++ b/versions/7.6.1/rules/verbs-tutorial.mdx
@@ -49,8 +49,7 @@ This pattern can also be seen in the Angular project. The
 produces two targets. The first is a standard `nodejs_test` target which compares
 some generated output against a "golden" file (that is, a file containing the
 expected output). This can be built and run with a normal `bazel
-test` invocation. In `angular-cli`, you can run [one such
-target](https://github.com/angular/angular-cli/blob/e1269cb520871ee29b1a4eec6e6c0e4a94f0b5fc/etc/api/BUILD)
+test` invocation. In `angular-cli`, you can run [one such target](https://github.com/angular/angular-cli/blob/e1269cb520871ee29b1a4eec6e6c0e4a94f0b5fc/etc/api/BUILD)
 with `bazel test //etc/api:angular_devkit_core_api`.
 
 Over time, this golden file may need to be updated for legitimate reasons.
@@ -137,7 +136,7 @@ an imaginary `bazel publish` command.
 It's not immediately obvious what the implementation of the `_sphinx_publisher`
 rule might look like. Often, actions like this write a _launcher_ shell script.
 This method typically involves using
-[`ctx.actions.expand_template`](lib/actions#expand_template)
+[`ctx.actions.expand_template`](/versions/7.6.1/rules/lib/builtins/actions#expand_template)
 to write a very simple shell script, in this case invoking the publisher binary
 with a path to the output of the primary target. This way, the publisher
 implementation can remain generic, the `_sphinx_site` rule can just produce
diff --git a/versions/7.6.1/run/build.mdx b/versions/7.6.1/run/build.mdx
index 67767890..f4411bd4 100644
--- a/versions/7.6.1/run/build.mdx
+++ b/versions/7.6.1/run/build.mdx
@@ -575,8 +575,7 @@ Note: Hermeticity means that the action only uses its declared input
 files and no other files in the filesystem, and it only produces its declared
 output files. See [Hermeticity](/versions/7.6.1/basics/hermeticity) for more details.
 
-On some platforms such as [Google Kubernetes
-Engine](https://cloud.google.com/kubernetes-engine/) cluster nodes or Debian,
+On some platforms such as [Google Kubernetes Engine](https://cloud.google.com/kubernetes-engine/) cluster nodes or Debian,
 user namespaces are deactivated by default due to security
 concerns. This can be checked by looking at the file
 `/proc/sys/kernel/unprivileged_userns_clone`: if it exists and contains a 0,
diff --git a/versions/7.6.1/start/android-app.mdx b/versions/7.6.1/start/android-app.mdx
index 8957c420..882b36d1 100644
--- a/versions/7.6.1/start/android-app.mdx
+++ b/versions/7.6.1/start/android-app.mdx
@@ -36,8 +36,7 @@ In this tutorial you learn how to:
 Before you begin the tutorial, install the following software:
 
 * **Bazel.** To install, follow the [installation instructions](/versions/7.6.1/install).
-* **Android Studio.** To install, follow the steps to [download Android
-  Studio](https://developer.android.com/sdk/index.html).
+* **Android Studio.** To install, follow the steps to [download Android Studio](https://developer.android.com/sdk/index.html).
   Execute the setup wizard to download the SDK and configure your environment.
 * (Optional) **Git.** Use `git` to download the Android app project.
 
@@ -52,8 +51,7 @@ This app has a single button that prints a greeting when clicked:
 
 **Figure 1.** Android app button greeting.
 
-Clone the repository with `git` (or [download the ZIP file
-directly](https://github.com/bazelbuild/examples/archive/master.zip)):
+Clone the repository with `git` (or [download the ZIP file directly](https://github.com/bazelbuild/examples/archive/master.zip)):
 
 ```posix-terminal
 git clone https://github.com/bazelbuild/examples
@@ -103,8 +101,7 @@ A [workspace](/versions/7.6.1/concepts/build-ref#workspace) is a directory that
 source files for one or more software projects, and has a `WORKSPACE` file at
 its root.
 
-The `WORKSPACE` file may be empty or may contain references to [external
-dependencies](/versions/7.6.1/docs/external) required to build your project.
+The `WORKSPACE` file may be empty or may contain references to [external dependencies](/versions/7.6.1/docs/external) required to build your project.
 
 First, run the following command to create an empty `WORKSPACE` file:
 
@@ -147,8 +144,7 @@ environment variable, and automatically detect the highest API level and the
 latest version of build tools installed within that location.
 
 You can set the `ANDROID_HOME` variable to the location of the Android SDK. Find
-the path to the installed SDK using Android Studio's [SDK
-Manager](https://developer.android.com/studio/intro/update#sdk-manager).
+the path to the installed SDK using Android Studio's [SDK Manager](https://developer.android.com/studio/intro/update#sdk-manager).
 Assuming the SDK is installed to default locations, you can use the following
 commands to set the `ANDROID_HOME` variable:
 
@@ -197,8 +193,7 @@ android_sdk_repository(
 ```
 
 **Optional:** If you want to compile native code into your Android app, you
-also need to download the [Android
-NDK](https://developer.android.com/ndk/downloads/index.html)
+also need to download the [Android NDK](https://developer.android.com/ndk/downloads/index.html)
 and tell Bazel where to find it by adding the following line to your `WORKSPACE` file:
 
 ```python
@@ -209,8 +204,7 @@ Similar to `android_sdk_repository`, the path to the Android NDK is inferred
 from the `ANDROID_NDK_HOME` environment variable by default. The path can also
 be explicitly specified with a `path` attribute on `android_ndk_repository`.
 
-For more information, read [Using the Android Native Development Kit with
-Bazel](/versions/7.6.1/docs/android-ndk).
+For more information, read [Using the Android Native Development Kit with Bazel](/versions/7.6.1/docs/android-ndk).
 
 `api_level` is the version of the Android API that the SDK and NDK
 target - for example, 23 for Android 6.0 and 25 for Android 7.1. If not
@@ -257,8 +251,7 @@ files or other dependencies. Bazel provides two build rules,
 build an Android app.
 
 For this tutorial, you'll first use the
-`android_library` rule to tell Bazel to build an [Android library
-module](http://developer.android.com/tools/projects/index.html#LibraryProjects)
+`android_library` rule to tell Bazel to build an [Android library module](http://developer.android.com/tools/projects/index.html#LibraryProjects)
 from the app source code and resource files. You'll then use the
 `android_binary` rule to tell Bazel how to build the Android application package.
 
@@ -373,11 +366,9 @@ file:
 ### Run the app
 
 You can now deploy the app to a connected Android device or emulator from the
-command line using the [`bazel
-mobile-install`](/versions/7.6.1/docs/user-manual#mobile-install) command. This command uses
+command line using the [`bazel mobile-install`](/versions/7.6.1/docs/user-manual#mobile-install) command. This command uses
 the Android Debug Bridge (`adb`) to communicate with the device. You must set up
-your device to use `adb` following the instructions in [Android Debug
-Bridge](http://developer.android.com/tools/help/adb.html) before deployment. You
+your device to use `adb` following the instructions in [Android Debug Bridge](http://developer.android.com/tools/help/adb.html) before deployment. You
 can also choose to install the app on the Android emulator included in Android
 Studio. Make sure the emulator is running before executing the command below.
 
diff --git a/versions/7.6.1/start/cpp.mdx b/versions/7.6.1/start/cpp.mdx
index 0fcc1258..b7efe4b7 100644
--- a/versions/7.6.1/start/cpp.mdx
+++ b/versions/7.6.1/start/cpp.mdx
@@ -63,9 +63,7 @@ examples
 ```
 
 There are three sets of files, each set representing a stage in this tutorial.
-In the first stage, you will build a single [target]
-(https://bazel.build/reference/glossary#target) residing in a single [package]
-(https://bazel.build/reference/glossary#package). In the second stage, you will
+In the first stage, you will build a single [target](https://bazel.build/versions/7.6.1/reference/glossary#target) residing in a single [package](https://bazel.build/versions/7.6.1/reference/glossary#package). In the second stage, you will
 build both a binary and a library from a single package. In
 the third and final stage, you will build a project with multiple packages and
 build it with multiple targets.
diff --git a/versions/7.6.1/start/java.mdx b/versions/7.6.1/start/java.mdx
index 979b0d45..c269e4e7 100644
--- a/versions/7.6.1/start/java.mdx
+++ b/versions/7.6.1/start/java.mdx
@@ -241,8 +241,7 @@ recompiles that file.
 Looking at the dependency graph, you can see that `ProjectRunner` depends on the
 same inputs as it did before, but the structure of the build is different:
 
-![Dependency graph of the target 'ProjectRunner' after adding a dependency](
-/docs/images/tutorial_java_02.svg)
+![Dependency graph of the target 'ProjectRunner' after adding a dependency](/versions/7.6.1/docs/images/tutorial_java_02.svg)
 
 You've now built the project with two targets. The `ProjectRunner` target builds
 two source files and depends on one other target (`:greeter`), which builds
@@ -426,7 +425,7 @@ For more details, see:
 *  The [C++ build tutorial](/versions/7.6.1/start/cpp) to get started with building
    C++ projects with Bazel.
 
-*  The [Android application tutorial](/versions/7.6.1/start/android-app ) and
+*  The [Android application tutorial](/versions/7.6.1/start/android-app) and
    [iOS application tutorial](/versions/7.6.1/start/ios-app)) to get started with
    building mobile applications for Android and iOS with Bazel.
 
diff --git a/versions/7.7.1/community/images/Bitrise.png b/versions/7.7.1/community/images/Bitrise.png
new file mode 100644
index 00000000..07f85f1e
Binary files /dev/null and b/versions/7.7.1/community/images/Bitrise.png differ
diff --git a/versions/7.7.1/community/images/Gradle.png b/versions/7.7.1/community/images/Gradle.png
new file mode 100644
index 00000000..1e5f5eb0
Binary files /dev/null and b/versions/7.7.1/community/images/Gradle.png differ
diff --git a/versions/7.7.1/community/images/Linkedin-Logo.png b/versions/7.7.1/community/images/Linkedin-Logo.png
new file mode 100644
index 00000000..9dd8715c
Binary files /dev/null and b/versions/7.7.1/community/images/Linkedin-Logo.png differ
diff --git a/versions/7.7.1/community/images/Lucid_Software-logo.svg b/versions/7.7.1/community/images/Lucid_Software-logo.svg
new file mode 100644
index 00000000..6c8591e0
--- /dev/null
+++ b/versions/7.7.1/community/images/Lucid_Software-logo.svg
@@ -0,0 +1,16 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/versions/7.7.1/community/images/acqio_logo.svg b/versions/7.7.1/community/images/acqio_logo.svg
new file mode 100644
index 00000000..8fa11bcd
--- /dev/null
+++ b/versions/7.7.1/community/images/acqio_logo.svg
@@ -0,0 +1,60 @@
+
+
+
+
+
+	
+		
+			
+				
+					
+					
+					
+					
+					
+				
+				
+					
+						
+							
+								
+							
+						
+					
+				
+				
+					
+						
+							
+								
+							
+						
+					
+				
+			
+		
+	
+
+
diff --git a/versions/7.7.1/community/images/aspect-logo-2.png b/versions/7.7.1/community/images/aspect-logo-2.png
new file mode 100644
index 00000000..dfebc4cb
Binary files /dev/null and b/versions/7.7.1/community/images/aspect-logo-2.png differ
diff --git a/versions/7.7.1/community/images/bitrise-logo.png b/versions/7.7.1/community/images/bitrise-logo.png
new file mode 100644
index 00000000..27037ce6
Binary files /dev/null and b/versions/7.7.1/community/images/bitrise-logo.png differ
diff --git a/versions/7.7.1/community/images/buildbuddy-logo.svg b/versions/7.7.1/community/images/buildbuddy-logo.svg
new file mode 100644
index 00000000..bdb72dc6
--- /dev/null
+++ b/versions/7.7.1/community/images/buildbuddy-logo.svg
@@ -0,0 +1,11 @@
+
+
+
+
+
+
+
+
+
+
+
diff --git a/versions/7.7.1/community/images/buildkite.svg b/versions/7.7.1/community/images/buildkite.svg
new file mode 100644
index 00000000..209a4ab1
--- /dev/null
+++ b/versions/7.7.1/community/images/buildkite.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/7.7.1/community/images/codethink-logo.svg b/versions/7.7.1/community/images/codethink-logo.svg
new file mode 100644
index 00000000..406005d8
--- /dev/null
+++ b/versions/7.7.1/community/images/codethink-logo.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/7.7.1/community/images/develocity.png b/versions/7.7.1/community/images/develocity.png
new file mode 100644
index 00000000..eb3eb65a
Binary files /dev/null and b/versions/7.7.1/community/images/develocity.png differ
diff --git a/versions/7.7.1/community/images/dropbox.png b/versions/7.7.1/community/images/dropbox.png
new file mode 100644
index 00000000..125476a6
Binary files /dev/null and b/versions/7.7.1/community/images/dropbox.png differ
diff --git a/versions/7.7.1/community/images/engflow-logo.svg b/versions/7.7.1/community/images/engflow-logo.svg
new file mode 100644
index 00000000..e5f0c343
--- /dev/null
+++ b/versions/7.7.1/community/images/engflow-logo.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/7.7.1/community/images/epam-logo.png b/versions/7.7.1/community/images/epam-logo.png
new file mode 100644
index 00000000..e6a5674c
Binary files /dev/null and b/versions/7.7.1/community/images/epam-logo.png differ
diff --git a/versions/7.7.1/community/images/flare-logo.png b/versions/7.7.1/community/images/flare-logo.png
new file mode 100644
index 00000000..84cb0e5b
Binary files /dev/null and b/versions/7.7.1/community/images/flare-logo.png differ
diff --git a/versions/7.7.1/community/images/hermetiq-logo.png b/versions/7.7.1/community/images/hermetiq-logo.png
new file mode 100644
index 00000000..90765d96
Binary files /dev/null and b/versions/7.7.1/community/images/hermetiq-logo.png differ
diff --git a/versions/7.7.1/community/images/jetbrains.svg b/versions/7.7.1/community/images/jetbrains.svg
new file mode 100644
index 00000000..cb3a2a0e
--- /dev/null
+++ b/versions/7.7.1/community/images/jetbrains.svg
@@ -0,0 +1,13 @@
+
+  
+    
+      
+      
+      
+    
+  
+  
+  
+  
+  
+
diff --git a/versions/7.7.1/community/images/liulishuo.png b/versions/7.7.1/community/images/liulishuo.png
new file mode 100644
index 00000000..a6758e5c
Binary files /dev/null and b/versions/7.7.1/community/images/liulishuo.png differ
diff --git a/versions/7.7.1/community/images/nativelink.svg b/versions/7.7.1/community/images/nativelink.svg
new file mode 100644
index 00000000..148fcdce
--- /dev/null
+++ b/versions/7.7.1/community/images/nativelink.svg
@@ -0,0 +1,1123 @@
+
+
+  
+    
+    
+      
+      
+    
+    
+      
+      
+    
+    
+    
+      
+      
+    
+    
+      
+      
+      
+      
+      
+      
+      
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+      
+      
+    
+    
+    
+    
+      
+      
+    
+    
+    
+    
+      
+      
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+      
+      
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+      
+      
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+      
+      
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+      
+      
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+      
+      
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+      
+      
+    
+  
+  
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+  
+  
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+  
+
diff --git a/versions/7.7.1/community/images/oasis-logo.png b/versions/7.7.1/community/images/oasis-logo.png
new file mode 100644
index 00000000..846a9cd5
Binary files /dev/null and b/versions/7.7.1/community/images/oasis-logo.png differ
diff --git a/versions/7.7.1/community/images/sumglobal-logo.png b/versions/7.7.1/community/images/sumglobal-logo.png
new file mode 100644
index 00000000..6736328d
Binary files /dev/null and b/versions/7.7.1/community/images/sumglobal-logo.png differ
diff --git a/versions/7.7.1/community/images/trunk-logo-dark.svg b/versions/7.7.1/community/images/trunk-logo-dark.svg
new file mode 100644
index 00000000..f25940af
--- /dev/null
+++ b/versions/7.7.1/community/images/trunk-logo-dark.svg
@@ -0,0 +1,22 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/versions/7.7.1/community/images/tweag-logo.png b/versions/7.7.1/community/images/tweag-logo.png
new file mode 100644
index 00000000..20210ed7
Binary files /dev/null and b/versions/7.7.1/community/images/tweag-logo.png differ
diff --git a/versions/7.7.1/community/images/typedb.png b/versions/7.7.1/community/images/typedb.png
new file mode 100644
index 00000000..48ce1056
Binary files /dev/null and b/versions/7.7.1/community/images/typedb.png differ
diff --git a/versions/7.7.1/community/images/virtuslab.svg b/versions/7.7.1/community/images/virtuslab.svg
new file mode 100644
index 00000000..6fba0316
--- /dev/null
+++ b/versions/7.7.1/community/images/virtuslab.svg
@@ -0,0 +1,20 @@
+
+
+  
+    
+  
+  
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+  
+
diff --git a/versions/7.7.1/community/roadmaps-configurability.mdx b/versions/7.7.1/community/roadmaps-configurability.mdx
index 3c06112f..b23bfd97 100644
--- a/versions/7.7.1/community/roadmaps-configurability.mdx
+++ b/versions/7.7.1/community/roadmaps-configurability.mdx
@@ -26,8 +26,7 @@ title: 'Bazel Configurability 2021 Roadmap'
 * Builds scale well, particularly w.r.t graph size and action caching.
 
 We also support
-[`cquery`](https://bazel.build/versions/7.7.1/query/cquery), [`Starlark
-configuration`](https://bazel.build/extending/config),
+[`cquery`](https://bazel.build/versions/7.7.1/query/cquery), [`Starlark configuration`](https://bazel.build/versions/7.7.1/extending/config),
 and
 [`select()`](https://bazel.build/versions/7.7.1/docs/configurable-attributes).
 
@@ -41,15 +40,13 @@ interest of accurate expectations.
 ### Platforms
 
 

-Q3 2021**Android rules use the new [platforms
-API](https://bazel.build/concepts/platforms)**
+Q3 2021**Android rules use the new [platforms API](https://bazel.build/versions/7.7.1/concepts/platforms)**
 IN PROGRESS ([#11749](https://github.com/bazelbuild/bazel/issues/11749))
 
 * This is our main priority for the beginning of 2021.
 
 

-Q3 2021**Builds support [multiple execution
-platforms](https://docs.google.com/document/d/1U9HzdDmtRnm244CaRM6JV-q2408mbNODAMewcGjnnbM/)**
+Q3 2021**Builds support [multiple execution platforms](https://docs.google.com/document/d/1U9HzdDmtRnm244CaRM6JV-q2408mbNODAMewcGjnnbM/)**
 IN PROGRESS ([#11748](https://github.com/bazelbuild/bazel/issues/11748))
 
 

diff --git a/versions/7.7.1/community/sig.mdx b/versions/7.7.1/community/sig.mdx
index 462a8840..91314925 100644
--- a/versions/7.7.1/community/sig.mdx
+++ b/versions/7.7.1/community/sig.mdx
@@ -3,8 +3,7 @@ title: 'Bazel Special Interest Groups'
 ---
 
 Bazel hosts Special Interest Groups (SIGs) to focus collaboration on particular
-areas and to support communication and coordination between [Bazel owners,
-maintainers, and contributors](/versions/7.7.1/contribute/policy). This policy
+areas and to support communication and coordination between [Bazel owners, maintainers, and contributors](/versions/7.7.1/contribute/policy). This policy
 applies to [`bazelbuild`](http://github.com/bazelbuild).
 
 SIGs do their work in public. The ideal scope for a SIG covers a well-defined
diff --git a/versions/7.7.1/concepts/build-ref.mdx b/versions/7.7.1/concepts/build-ref.mdx
index c8d6b6d8..bca6d2a1 100644
--- a/versions/7.7.1/concepts/build-ref.mdx
+++ b/versions/7.7.1/concepts/build-ref.mdx
@@ -17,8 +17,7 @@ its root; such a boundary marker file could be `MODULE.bazel`, `REPO.bazel`, or
 in legacy contexts, `WORKSPACE` or `WORKSPACE.bazel`.
 
 The repo in which the current Bazel command is being run is called the _main
-repo_. Other, (external) repos are defined by _repo rules_; see [external
-dependencies overview](/versions/7.7.1/external/overview) for more information.
+repo_. Other, (external) repos are defined by _repo rules_; see [external dependencies overview](/versions/7.7.1/external/overview) for more information.
 
 ## Workspace {#workspace}
 
@@ -95,5 +94,4 @@ have three properties: the list of packages they contain, their name, and other
 package groups they include. The only allowed ways to refer to them are from the
 `visibility` attribute of rules or from the `default_visibility` attribute of
 the `package` function; they do not generate or consume files. For more
-information, refer to the [`package_group`
-documentation](/versions/7.7.1/reference/be/functions#package_group).
+information, refer to the [`package_group` documentation](/versions/7.7.1/reference/be/functions#package_group).
diff --git a/versions/7.7.1/concepts/labels.mdx b/versions/7.7.1/concepts/labels.mdx
index 9780c61c..3129efb7 100644
--- a/versions/7.7.1/concepts/labels.mdx
+++ b/versions/7.7.1/concepts/labels.mdx
@@ -10,8 +10,7 @@ form looks like:
 ```
 
 The first part of the label is the repository name, `@@myrepo`. The double-`@`
-syntax signifies that this is a [*canonical* repo
-name](/versions/7.7.1/external/overview#canonical-repo-name), which is unique within
+syntax signifies that this is a [*canonical* repo name](/versions/7.7.1/external/overview#canonical-repo-name), which is unique within
 the workspace. Labels with canonical repo names unambiguously identify a target
 no matter which context they appear in.
 
diff --git a/versions/7.7.1/concepts/platforms.mdx b/versions/7.7.1/concepts/platforms.mdx
index c846eab8..b9f348c6 100644
--- a/versions/7.7.1/concepts/platforms.mdx
+++ b/versions/7.7.1/concepts/platforms.mdx
@@ -77,8 +77,7 @@ To test your Android project with platforms, see
 for support.
 
 You can still use platform APIs with Apple builds (for example, when building
-with a mixture of Apple rules and pure C++) with [platform
-mappings](#platform-mappings).
+with a mixture of Apple rules and pure C++) with [platform mappings](#platform-mappings).
 
 ### Other languages {#other-languages}
 
@@ -241,8 +240,7 @@ sets `--cpu`, `--crossstool_top`, or other legacy flags, rules that read
 
 When migrating your project to platforms, you must either convert changes like
 `return { "//command_line_option:cpu": "arm" }` to `return {
-"//command_line_option:platforms": "//:my_arm_platform" }` or use [platform
-mappings](#platform-mappings) to support both styles during migration.
+"//command_line_option:platforms": "//:my_arm_platform" }` or use [platform mappings](#platform-mappings) to support both styles during migration.
 window.
 
 ## Migrating your rule set {#migrating-your-rule-set}
@@ -361,10 +359,8 @@ attributes declare a language's tools (like `compiler =
 this information to rules that need to build with these tools.
 
 Toolchains declare the `constraint_value`s of machines they can
-[target][target_compatible_with Attribute]
-(`target_compatible_with = ["@platforms//os:linux"]`) and machines their tools can
-[run on][exec_compatible_with Attribute]
-(`exec_compatible_with = ["@platforms//os:mac"]`).
+[target][target_compatible_with Attribute](`target_compatible_with = ["@platforms//os:linux"]`) and machines their tools can
+[run on][exec_compatible_with Attribute](`exec_compatible_with = ["@platforms//os:mac"]`).
 
 When building `$ bazel build //:myproject --platforms=//:myplatform`, Bazel
 automatically selects a toolchain that can run on the build machine and
diff --git a/versions/7.7.1/configure/attributes.mdx b/versions/7.7.1/configure/attributes.mdx
index 9678e0d1..57198598 100644
--- a/versions/7.7.1/configure/attributes.mdx
+++ b/versions/7.7.1/configure/attributes.mdx
@@ -2,8 +2,7 @@
 title: 'Configurable Build Attributes'
 ---
 
-**_Configurable attributes_**, commonly known as [`select()`](
-/reference/be/functions#select), is a Bazel feature that lets users toggle the values
+**_Configurable attributes_**, commonly known as [`select()`](/versions/7.7.1/reference/be/functions#select), is a Bazel feature that lets users toggle the values
 of build rule attributes at the command line.
 
 This can be used, for example, for a multiplatform library that automatically
@@ -407,8 +406,7 @@ sh_library(
 )
 ```
 
-If you need a `select` to match when multiple conditions match, consider [AND
-chaining](#and-chaining).
+If you need a `select` to match when multiple conditions match, consider [AND chaining](#and-chaining).
 
 ## OR chaining {#or-chaining}
 
diff --git a/versions/7.7.1/configure/integrate-cpp.mdx b/versions/7.7.1/configure/integrate-cpp.mdx
index bec529c9..f20b55f6 100644
--- a/versions/7.7.1/configure/integrate-cpp.mdx
+++ b/versions/7.7.1/configure/integrate-cpp.mdx
@@ -33,8 +33,7 @@ This is because when writing our own actions, they must behave
 consistently with the C++ toolchain - for example, passing C++ command line
 flags to a tool that invokes the C++ compiler behind the scenes.
 
-C++ rules use a special way of constructing command lines based on [feature
-configuration](/versions/7.7.1/docs/cc-toolchain-config-reference). To construct a command line,
+C++ rules use a special way of constructing command lines based on [feature configuration](/versions/7.7.1/docs/cc-toolchain-config-reference). To construct a command line,
 you need the following:
 
 * `features` and `action_configs` - these come from the `CcToolchainConfigInfo`
diff --git a/versions/7.7.1/configure/windows.mdx b/versions/7.7.1/configure/windows.mdx
index ab04d210..d5b412dc 100644
--- a/versions/7.7.1/configure/windows.mdx
+++ b/versions/7.7.1/configure/windows.mdx
@@ -166,8 +166,7 @@ To build C++ targets with MSVC, you need:
         set BAZEL_VC=C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC
         ```
 
-*   The [Windows
-    SDK](https://developer.microsoft.com/en-us/windows/downloads/windows-10-sdk).
+*   The [Windows SDK](https://developer.microsoft.com/en-us/windows/downloads/windows-10-sdk).
 
     The Windows SDK contains header files and libraries you need when building
     Windows applications, including Bazel itself. By default, the latest Windows SDK installed will
@@ -186,8 +185,7 @@ To build C++ targets with MSVC, you need:
 
 If everything is set up, you can build a C++ target now!
 
-Try building a target from one of our [sample
-projects](https://github.com/bazelbuild/bazel/tree/master/examples):
+Try building a target from one of our [sample projects](https://github.com/bazelbuild/bazel/tree/master/examples):
 
 
 
 
-To build and use Dynamically Linked Libraries (DLL files), see [this
-example](https://github.com/bazelbuild/bazel/tree/master/examples/windows/dll).
+To build and use Dynamically Linked Libraries (DLL files), see [this example](https://github.com/bazelbuild/bazel/tree/master/examples/windows/dll).
 
 **Command Line Length Limit**: To prevent the
 [Windows command line length limit issue](https://github.com/bazelbuild/bazel/issues/5163),
@@ -292,8 +289,7 @@ On Windows, Bazel builds two output files for `java_binary` rules:
 *   a `.jar` file
 *   a `.exe` file that can set up the environment for the JVM and run the binary
 
-Try building a target from one of our [sample
-projects](https://github.com/bazelbuild/bazel/tree/master/examples):
+Try building a target from one of our [sample projects](https://github.com/bazelbuild/bazel/tree/master/examples):
 
 
   
   
 
 If you are interested in details about how Bazel builds Python targets on
-Windows, check out this [design
-doc](https://github.com/bazelbuild/bazel-website/blob/master/designs/_posts/2016-09-05-build-python-on-windows.md).
+Windows, check out this [design doc](https://github.com/bazelbuild/bazel-website/blob/master/designs/_posts/2016-09-05-build-python-on-windows.md).
diff --git a/versions/7.7.1/contribute/breaking-changes.mdx b/versions/7.7.1/contribute/breaking-changes.mdx
index d1885843..372a0d11 100644
--- a/versions/7.7.1/contribute/breaking-changes.mdx
+++ b/versions/7.7.1/contribute/breaking-changes.mdx
@@ -67,7 +67,7 @@ should contain the URL of the GitHub issue. As the flag name starts with
 ```
 
 In the commit description, add a brief summary of the flag.
-Also add [`RELNOTES:`](release-notes.md) in the following form:
+Also add [`RELNOTES:`](/versions/7.7.1/contribute/release-notes) in the following form:
 `RELNOTES: --incompatible_name_of_flag has been added. See #xyz for details`
 
 The commit should also update the relevant documentation, so that there is no
diff --git a/versions/7.7.1/contribute/codebase.mdx b/versions/7.7.1/contribute/codebase.mdx
index a9f17d71..200dde44 100644
--- a/versions/7.7.1/contribute/codebase.mdx
+++ b/versions/7.7.1/contribute/codebase.mdx
@@ -227,8 +227,7 @@ repository", the others are called "external repositories".
 A repository is marked by a repo boundary file (`MODULE.bazel`, `REPO.bazel`, or
 in legacy contexts, `WORKSPACE` or `WORKSPACE.bazel`) in its root directory. The
 main repo is the source tree where you're invoking Bazel from. External repos
-are defined in various ways; see [external dependencies
-overview](/versions/7.7.1/external/overview) for more information.
+are defined in various ways; see [external dependencies overview](/versions/7.7.1/external/overview) for more information.
 
 Code of external repositories is symlinked or downloaded under
 `$OUTPUT_BASE/external`.
diff --git a/versions/7.7.1/contribute/design-documents.mdx b/versions/7.7.1/contribute/design-documents.mdx
index 60f69495..c0732f25 100644
--- a/versions/7.7.1/contribute/design-documents.mdx
+++ b/versions/7.7.1/contribute/design-documents.mdx
@@ -25,7 +25,7 @@ Here are some examples of significant changes:
 When you write a design document, you can coordinate with other Bazel developers
 and seek guidance from Bazel's core team. For example, when a proposal adds,
 removes, or modifies any function or object available in BUILD, WORKSPACE, or
-bzl files, add the [Starlark team](maintainers-guide.md) as reviewers.
+bzl files, add the [Starlark team](/versions/7.7.1/contribute/maintainers-guide) as reviewers.
 Design documents are reviewed before submission because:
 
 *   Bazel is a very complex system; seemingly innocuous local changes can have
@@ -137,8 +137,7 @@ A lead reviewer should be a domain expert who is:
 *   Objective and capable of providing constructive feedback
 *   Available for the entire review period to lead the process
 
-Consider checking the contacts for various [team
-labels](/versions/7.7.1/contribute/maintainers-guide#team-labels).
+Consider checking the contacts for various [team labels](/versions/7.7.1/contribute/maintainers-guide#team-labels).
 
 ## Markdown vs Google Docs {#markdown-versus-gdocs}
 
@@ -168,12 +167,10 @@ Markdown for posterity.
 
 ### Using Google Docs {#gdocs}
 
-For consistency, use the [Bazel design doc template](
-https://docs.google.com/document/d/1cE5zrjrR40RXNg64XtRFewSv6FrLV6slGkkqxBumS1w/edit).
+For consistency, use the [Bazel design doc template](https://docs.google.com/document/d/1cE5zrjrR40RXNg64XtRFewSv6FrLV6slGkkqxBumS1w/edit).
 It includes the necessary header and creates visual
 consistency with other Bazel related documents. To do that, click on **File** >
-**Make a copy** or click this link to [make a copy of the design doc
-template](https://docs.google.com/document/d/1cE5zrjrR40RXNg64XtRFewSv6FrLV6slGkkqxBumS1w/copy).
+**Make a copy** or click this link to [make a copy of the design doc template](https://docs.google.com/document/d/1cE5zrjrR40RXNg64XtRFewSv6FrLV6slGkkqxBumS1w/copy).
 
 To make your document readable to the world, click on
 **Share** > **Advanced** > **Change…**, and
diff --git a/versions/7.7.1/contribute/images/structured-concurrency-3d.svg b/versions/7.7.1/contribute/images/structured-concurrency-3d.svg
new file mode 100644
index 00000000..accbb42a
--- /dev/null
+++ b/versions/7.7.1/contribute/images/structured-concurrency-3d.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/7.7.1/contribute/images/structured-concurrency.svg b/versions/7.7.1/contribute/images/structured-concurrency.svg
new file mode 100644
index 00000000..0258d9a9
--- /dev/null
+++ b/versions/7.7.1/contribute/images/structured-concurrency.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/7.7.1/contribute/images/suspend-resume.svg b/versions/7.7.1/contribute/images/suspend-resume.svg
new file mode 100644
index 00000000..7de1218f
--- /dev/null
+++ b/versions/7.7.1/contribute/images/suspend-resume.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/7.7.1/contribute/images/unstructured-concurrency.svg b/versions/7.7.1/contribute/images/unstructured-concurrency.svg
new file mode 100644
index 00000000..0951639a
--- /dev/null
+++ b/versions/7.7.1/contribute/images/unstructured-concurrency.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/7.7.1/contribute/index.mdx b/versions/7.7.1/contribute/index.mdx
index 2619db31..c7d01b46 100644
--- a/versions/7.7.1/contribute/index.mdx
+++ b/versions/7.7.1/contribute/index.mdx
@@ -10,8 +10,7 @@ As you use Bazel, you may find things that can be improved.
 You can help by [reporting issues](http://github.com/bazelbuild/bazel/issues)
 when:
 
-   - Bazel crashes or you encounter a bug that can [only be resolved using `bazel
-     clean`](/versions/7.7.1/run/build#correct-incremental-rebuilds).
+   - Bazel crashes or you encounter a bug that can [only be resolved using `bazel clean`](/versions/7.7.1/run/build#correct-incremental-rebuilds).
    - The documentation is incomplete or unclear. You can also report issues
      from the page you are viewing by using the "Create issue"
      link at the top right corner of the page.
@@ -21,11 +20,9 @@ when:
 
 You can engage with the Bazel community by:
 
-   - Answering questions [on Stack Overflow](
-     https://stackoverflow.com/questions/tagged/bazel).
+   - Answering questions [on Stack Overflow](https://stackoverflow.com/questions/tagged/bazel).
    - Helping other users [on Slack](https://slack.bazel.build).
-   - Improving documentation or [contributing examples](
-     https://github.com/bazelbuild/examples).
+   - Improving documentation or [contributing examples](https://github.com/bazelbuild/examples).
    - Sharing your experience or your tips, for example, on a blog or social media.
 
 ## Contribute code {#contribute-code}
@@ -40,8 +37,7 @@ You can contribute to the Bazel ecosystem by:
    - Contributing to Bazel-related tools, for example, migration tools.
    - Improving Bazel integration with other IDEs and tools.
 
-Before making a change, [create a GitHub
-issue](http://github.com/bazelbuild/bazel/issues)
+Before making a change, [create a GitHub issue](http://github.com/bazelbuild/bazel/issues)
 or email [bazel-discuss@](mailto:bazel-discuss@googlegroups.com).
 
 The most helpful contributions fix bugs or add features (as opposed
diff --git a/versions/7.7.1/contribute/maintainers-guide.mdx b/versions/7.7.1/contribute/maintainers-guide.mdx
index dbb45ada..516cf0b1 100644
--- a/versions/7.7.1/contribute/maintainers-guide.mdx
+++ b/versions/7.7.1/contribute/maintainers-guide.mdx
@@ -4,8 +4,7 @@ title: 'Guide for Bazel Maintainers'
 
 This is a guide for the maintainers of the Bazel open source project.
 
-If you are looking to contribute to Bazel, please read [Contributing to
-Bazel](/versions/7.7.1/contribute) instead.
+If you are looking to contribute to Bazel, please read [Contributing to Bazel](/versions/7.7.1/contribute) instead.
 
 The objectives of this page are to:
 
@@ -37,8 +36,7 @@ repository.
 
 1. A user creates an issue by choosing one of the
 [issue templates](https://github.com/bazelbuild/bazel/issues/new/choose)
-   and it enters the pool of [unreviewed open
-   issues](https://github.com/bazelbuild/bazel/issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aopen+-label%3Auntriaged+-label%3Ap2+-label%3Ap1+-label%3Ap3+-label%3Ap4+-label%3Ateam-Starlark+-label%3Ateam-Rules-CPP+-label%3Ateam-Rules-Java+-label%3Ateam-XProduct+-label%3Ateam-Android+-label%3Ateam-Apple+-label%3Ateam-Configurability++-label%3Ateam-Performance+-label%3Ateam-Rules-Server+-label%3Ateam-Core+-label%3Ateam-Rules-Python+-label%3Ateam-Remote-Exec+-label%3Ateam-Local-Exec+-label%3Ateam-Bazel).
+   and it enters the pool of [unreviewed open issues](https://github.com/bazelbuild/bazel/issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aopen+-label%3Auntriaged+-label%3Ap2+-label%3Ap1+-label%3Ap3+-label%3Ap4+-label%3Ateam-Starlark+-label%3Ateam-Rules-CPP+-label%3Ateam-Rules-Java+-label%3Ateam-XProduct+-label%3Ateam-Android+-label%3Ateam-Apple+-label%3Ateam-Configurability++-label%3Ateam-Performance+-label%3Ateam-Rules-Server+-label%3Ateam-Core+-label%3Ateam-Rules-Python+-label%3Ateam-Remote-Exec+-label%3Ateam-Local-Exec+-label%3Ateam-Bazel).
 1. A member on the Developer Experience (DevEx) subteam rotation reviews the
    issue.
    1. If the issue is **not a bug** or a **feature request**, the DevEx member
@@ -58,21 +56,18 @@ repository.
 1. After reviewing the issue, the DevEx member decides if the issue requires
    immediate attention. If it does, they will assign the **P0**
    [priority](#priority) label and an owner from the list of team leads.
-1. The DevEx member assigns the `untriaged` label and exactly one [team
-   label](#team-labels) for routing.
+1. The DevEx member assigns the `untriaged` label and exactly one [team label](#team-labels) for routing.
 1. The DevEx member also assigns exactly one `type:` label, such as `type: bug`
    or `type: feature request`, according to the type of the issue.
 1. For platform-specific issues, the DevEx member assigns one `platform:` label,
    such as `platform:apple` for Mac-specific issues.
 1. If the issue is low priority and can be worked on by a new community
    contributor, the DevEx member assigns the `good first issue` label.
-At this stage, the issue enters the pool of [untriaged open
-issues](https://github.com/bazelbuild/bazel/issues?q=is%3Aissue+is%3Aopen+label%3Auntriaged).
+At this stage, the issue enters the pool of [untriaged open issues](https://github.com/bazelbuild/bazel/issues?q=is%3Aissue+is%3Aopen+label%3Auntriaged).
 
 Each Bazel subteam will triage all issues under labels they own, preferably on a
 weekly basis. The subteam will review and evaluate the issue and provide a
-resolution, if possible. If you are an owner of a team label, see [this section
-](#label-own) for more information.
+resolution, if possible. If you are an owner of a team label, see [this section](#label-own) for more information.
 
 When an issue is resolved, it can be closed.
 
@@ -111,8 +106,7 @@ preferably on a weekly basis.
      issue is either P0 or P1 we assume that is actively worked on.
 1. Remove the `untriaged` label.
 
-Note that you need to be in the [bazelbuild
-organization](https://github.com/bazelbuild) to be able to add or remove labels.
+Note that you need to be in the [bazelbuild organization](https://github.com/bazelbuild) to be able to add or remove labels.
 
 ### Pull Requests {#pull-requests}
 
@@ -138,8 +132,7 @@ issues.
   unusable, or a downed service that severely impacts development of the Bazel
   project. This includes regressions introduced in a new release that blocks a
   significant number of users, or an incompatible breaking change that was not
-  compliant to the [Breaking
-  Change](https://docs.google.com/document/d/1q5GGRxKrF_mnwtaPKI487P8OdDRh2nN7jX6U-FXnHL0/edit?pli=1#heading=h.ceof6vpkb3ik)
+  compliant to the [Breaking Change](https://docs.google.com/document/d/1q5GGRxKrF_mnwtaPKI487P8OdDRh2nN7jX6U-FXnHL0/edit?pli=1#heading=h.ceof6vpkb3ik)
   policy. No practical workaround exists.
 * [**P1**](https://github.com/bazelbuild/bazel/labels/P1) - Critical defect or
   feature which should be addressed in the next release, or a serious issue that
diff --git a/versions/7.7.1/contribute/naming.mdx b/versions/7.7.1/contribute/naming.mdx
index 672c7dac..03652c5f 100644
--- a/versions/7.7.1/contribute/naming.mdx
+++ b/versions/7.7.1/contribute/naming.mdx
@@ -4,8 +4,7 @@ title: 'Naming a Bazel related project'
 
 First, thank you for contributing to the Bazel ecosystem! Please reach out to
 the Bazel community on the
-[bazel-discuss mailing list](https://groups.google.com/forum/#!forum/bazel-discuss
-) to share your project and its suggested name.
+[bazel-discuss mailing list](https://groups.google.com/forum/#!forum/bazel-discuss) to share your project and its suggested name.
 
 If you are building a Bazel related tool or sharing your Skylark rules,
 we recommend following these guidelines for the name of your project:
diff --git a/versions/7.7.1/contribute/patch-acceptance.mdx b/versions/7.7.1/contribute/patch-acceptance.mdx
index f78087ca..667f1633 100644
--- a/versions/7.7.1/contribute/patch-acceptance.mdx
+++ b/versions/7.7.1/contribute/patch-acceptance.mdx
@@ -11,29 +11,24 @@ code base.
    need a corresponding issue for tracking.
 1. If you're proposing significant changes, write a
    [design document](/versions/7.7.1/contribute/design-documents).
-1. Ensure you've signed a [Contributor License
-   Agreement](https://cla.developers.google.com).
+1. Ensure you've signed a [Contributor License Agreement](https://cla.developers.google.com).
 1. Prepare a git commit that implements the feature. Don't forget to add tests
    and update the documentation. If your change has user-visible effects, please
    [add release notes](/versions/7.7.1/contribute/release-notes). If it is an incompatible change,
    read the [guide for rolling out breaking changes](/versions/7.7.1/contribute/breaking-changes).
 1. Create a pull request on
    [GitHub](https://github.com/bazelbuild/bazel/pulls). If you're new to GitHub,
-   read [about pull
-   requests](https://help.github.com/articles/about-pull-requests/). Note that
+   read [about pull requests](https://help.github.com/articles/about-pull-requests/). Note that
    we restrict permissions to create branches on the main Bazel repository, so
-   you will need to push your commit to [your own fork of the
-   repository](https://help.github.com/articles/working-with-forks/).
+   you will need to push your commit to [your own fork of the repository](https://help.github.com/articles/working-with-forks/).
 1. A Bazel maintainer should assign you a reviewer within two business days
    (excluding holidays in the USA and Germany). If you aren't assigned a
    reviewer in that time, you can request one by emailing
-   [bazel-discuss@googlegroups.com]
-   (mailto:bazel-discuss@googlegroups.com).
+   [bazel-discuss@googlegroups.com](mailto:bazel-discuss@googlegroups.com).
 1. Work with the reviewer to complete a code review. For each change, create a
    new commit and push it to make changes to your pull request. If the review
    takes too long (for instance, if the reviewer is unresponsive), send an email to
-   [bazel-discuss@googlegroups.com]
-   (mailto:bazel-discuss@googlegroups.com).
+   [bazel-discuss@googlegroups.com](mailto:bazel-discuss@googlegroups.com).
 1. After your review is complete, a Bazel maintainer applies your patch to
    Google's internal version control system.
 
diff --git a/versions/7.7.1/contribute/release-notes.mdx b/versions/7.7.1/contribute/release-notes.mdx
index fc20f422..a1d8b6de 100644
--- a/versions/7.7.1/contribute/release-notes.mdx
+++ b/versions/7.7.1/contribute/release-notes.mdx
@@ -16,8 +16,7 @@ the release announcement.
 * If the change adds / removes / changes Bazel in a user-visible way, then it
   may be advantageous to mention it.
 
-If the change is significant, follow the [design document
-policy](/versions/7.7.1/contribute/design-documents) first.
+If the change is significant, follow the [design document policy](/versions/7.7.1/contribute/design-documents) first.
 
 ## Guidelines {#guidelines}
 
@@ -60,10 +59,8 @@ change is about.
 
 ## Process {#process}
 
-As part of the [release
-process](https://github.com/bazelbuild/continuous-integration/blob/master/docs/release-playbook.md),
-we collect the `RELNOTES` tags of every commit. We copy everything in a [Google
-Doc](https://docs.google.com/document/d/1wDvulLlj4NAlPZamdlEVFORks3YXJonCjyuQMUQEmB0/edit)
+As part of the [release process](https://github.com/bazelbuild/continuous-integration/blob/master/docs/release-playbook.md),
+we collect the `RELNOTES` tags of every commit. We copy everything in a [Google Doc](https://docs.google.com/document/d/1wDvulLlj4NAlPZamdlEVFORks3YXJonCjyuQMUQEmB0/edit)
 where we review, edit, and organize the notes.
 
 The release manager sends an email to the
@@ -71,6 +68,4 @@ The release manager sends an email to the
 Bazel contributors are invited to contribute to the document and make sure
 their changes are correctly reflected in the announcement.
 
-Later, the announcement will be submitted to the [Bazel
-blog](https://blog.bazel.build/), using the [bazel-blog
-repository](https://github.com/bazelbuild/bazel-blog/tree/master/_posts).
+Later, the announcement will be submitted to the [Bazel blog](https://blog.bazel.build/), using the [bazel-blog repository](https://github.com/bazelbuild/bazel-blog/tree/master/_posts).
diff --git a/versions/7.7.1/contribute/statemachine-guide.mdx b/versions/7.7.1/contribute/statemachine-guide.mdx
index b7d2d8b7..7b325891 100644
--- a/versions/7.7.1/contribute/statemachine-guide.mdx
+++ b/versions/7.7.1/contribute/statemachine-guide.mdx
@@ -172,8 +172,7 @@ instead, batches[^4] as many lookups as possible before doing so. The value
 might not be immediately available, for example, requiring a Skyframe restart,
 so the caller specifies what to do with the resulting value using a callback.
 
-The `StateMachine` processor ([`Driver`s and bridging to
-SkyFrame](#drivers-and-bridging)) guarantees that the value is available before
+The `StateMachine` processor ([`Driver`s and bridging to SkyFrame](#drivers-and-bridging)) guarantees that the value is available before
 the next state begins. An example follows.
 
 ```
@@ -284,8 +283,7 @@ and solutions to certain control flow problems.
 ### Sequential states
 
 This is the most common and straightforward control flow pattern. An example of
-this is shown in [Stateful computations inside
-`SkyKeyComputeState`](#stateful-computations).
+this is shown in [Stateful computations inside `SkyKeyComputeState`](#stateful-computations).
 
 ### Branching
 
@@ -545,8 +543,7 @@ section describes the propagation of data values.
 
 ### Implementing `Tasks.lookUp` callbacks
 
-There’s an example of implementing a `Tasks.lookUp` callback in [SkyValue
-lookups](#skyvalue-lookups). This section provides rationale and suggests
+There’s an example of implementing a `Tasks.lookUp` callback in [SkyValue lookups](#skyvalue-lookups). This section provides rationale and suggests
 approaches for handling multiple SkyValues.
 
 #### `Tasks.lookUp` callbacks {#tasks-lookup-callbacks}
@@ -710,8 +707,7 @@ class BarProducer implements StateMachine {
 Tip: It would be tempting to use the more concise signature void `accept(Bar
 value)` rather than the stuttery `void acceptBarValue(Bar value)` above.
 However, `Consumer` is a common overload of `void accept(Bar value)`,
-so doing this often leads to violations of the [Overloads: never
-split](https://google.github.io/styleguide/javaguide.html#s3.4.2-ordering-class-contents)
+so doing this often leads to violations of the [Overloads: never split](https://google.github.io/styleguide/javaguide.html#s3.4.2-ordering-class-contents)
 style-guide rule.
 
 Tip: Using a custom `ResultSink` type instead of a generic one from
@@ -774,14 +770,11 @@ pattern after accepting output from either a subtask or SkyValue lookup.
 Note that the implementation of `acceptBarError` eagerly forwards the result to
 the `Caller.ResultSink`, as required by [Error bubbling](#error-bubbling).
 
-Alternatives for top-level `StateMachine`s are described in [`Driver`s and
-bridging to SkyFunctions](#drivers-and-bridging).
+Alternatives for top-level `StateMachine`s are described in [`Driver`s and bridging to SkyFunctions](#drivers-and-bridging).
 
 ### Error handling {#error-handling}
 
-There's a couple of examples of error handling already in [`Tasks.lookUp`
-callbacks](#tasks-lookup-callbacks) and [Propagating values between
-`StateMachines`](#propagating-values). Exceptions, other than
+There's a couple of examples of error handling already in [`Tasks.lookUp` callbacks](#tasks-lookup-callbacks) and [Propagating values between `StateMachines`](#propagating-values). Exceptions, other than
 `InterruptedException` are not thrown, but instead passed around through
 callbacks as values. Such callbacks often have exclusive-or semantics, with
 exactly one of a value or error being passed.
@@ -1184,8 +1177,7 @@ states. Where it is possible, local stack `step` variables are young generation
 variables and efficiently GC'd.
 
 For `StateMachine` variables, breaking things down into subtasks and following
-the recommended pattern for [Propagating values between
-`StateMachine`s](#propagating-values) is also helpful. Observe that when
+the recommended pattern for [Propagating values between `StateMachine`s](#propagating-values) is also helpful. Observe that when
 following the pattern, only child `StateMachine`s have references to parent
 `StateMachine`s and not vice versa. This means that as children complete and
 update the parents using result callbacks, the children naturally fall out of
@@ -1207,8 +1199,7 @@ potentially reflecting local behavior.
 
 ### Concurrency tree diagram {#concurrency-tree-diagram}
 
-The following is an alternative view of the diagram in [Structured
-concurrency](#structured-concurrency) that better depicts the tree structure.
+The following is an alternative view of the diagram in [Structured concurrency](#structured-concurrency) that better depicts the tree structure.
 The blocks form a small tree.
 
 ![Structured Concurrency 3D](/versions/7.7.1/contribute/images/structured-concurrency-3d.svg)
diff --git a/versions/7.7.1/docs/android-instrumentation-test.mdx b/versions/7.7.1/docs/android-instrumentation-test.mdx
index 9a40baf2..c6d61580 100644
--- a/versions/7.7.1/docs/android-instrumentation-test.mdx
+++ b/versions/7.7.1/docs/android-instrumentation-test.mdx
@@ -2,8 +2,7 @@
 title: 'Android Instrumentation Tests'
 ---
 
-_If you're new to Bazel, start with the [Building Android with
-Bazel](/versions/7.7.1/start/android-app ) tutorial._
+_If you're new to Bazel, start with the [Building Android with Bazel](/versions/7.7.1/start/android-app) tutorial._
 
 ![Running Android instrumentation tests in parallel](/versions/7.7.1/docs/images/android_test.gif "Android instrumentation test")
 
@@ -18,9 +17,7 @@ emulators in a sandbox, ensuring that tests always run from a clean state. Each
 test gets an isolated emulator instance, allowing tests to run in parallel
 without passing states between them.
 
-For more information on Android instrumentation tests, check out the [Android
-developer
-documentation](https://developer.android.com/training/testing/unit-testing/instrumented-unit-tests.html).
+For more information on Android instrumentation tests, check out the [Android developer documentation](https://developer.android.com/training/testing/unit-testing/instrumented-unit-tests.html).
 
 Please file issues in the [GitHub issue tracker](https://github.com/bazelbuild/bazel/issues).
 
@@ -58,8 +55,7 @@ This results in output similar to the following:
 release 4.1.0
 ```
 
-- **KVM**. Bazel requires emulators to have [hardware
-  acceleration](https://developer.android.com/studio/run/emulator-acceleration.html#accel-check)
+- **KVM**. Bazel requires emulators to have [hardware acceleration](https://developer.android.com/studio/run/emulator-acceleration.html#accel-check)
   with KVM on Linux. You can follow these
   [installation instructions](https://help.ubuntu.com/community/KVM/Installation)
   for Ubuntu.
@@ -173,11 +169,9 @@ The main attributes of the rule `android_instrumentation_test` are:
 
 - `target_device`: An `android_device` target. This target describes the
   specifications of the Android emulator which Bazel uses to create, launch and
-  run the tests. See the [section on choosing an Android
-  device](#android-device-target) for more information.
+  run the tests. See the [section on choosing an Android device](#android-device-target) for more information.
 
-The test app's `AndroidManifest.xml` must include [an ``
-tag](https://developer.android.com/studio/test/#configure_instrumentation_manifest_settings).
+The test app's `AndroidManifest.xml` must include [an `` tag](https://developer.android.com/studio/test/#configure_instrumentation_manifest_settings).
 This tag must specify the attributes for the **package of the target app** and
 the **fully qualified class name of the instrumentation test runner**,
 `androidx.test.runner.AndroidJUnitRunner`.
@@ -214,8 +208,7 @@ repositories:
 - `@androidsdk`: The Android SDK. Download this through Android Studio.
 
 - `@android_test_support`: Hosts the test runner, emulator launcher, and
-  `android_device` targets. You can find the [latest release
-  here](https://github.com/android/android-test/releases).
+  `android_device` targets. You can find the [latest release here](https://github.com/android/android-test/releases).
 
 Enable these dependencies by adding the following lines to your `WORKSPACE`
 file:
@@ -240,8 +233,7 @@ android_test_repositories()
 
 ## Maven dependencies {#maven-dependencies}
 
-For managing dependencies on Maven artifacts from repositories, such as [Google
-Maven](https://maven.google.com) or [Maven Central](https://central.maven.org),
+For managing dependencies on Maven artifacts from repositories, such as [Google Maven](https://maven.google.com) or [Maven Central](https://central.maven.org),
 you should use a Maven resolver, such as
 [`rules_jvm_external`](https://github.com/bazelbuild/rules_jvm_external).
 
@@ -370,8 +362,7 @@ the device/emulator listed in `adb devices`.
 
 ## Sample projects {#sample-projects}
 
-If you are looking for canonical project samples, see the [Android testing
-samples](https://github.com/googlesamples/android-testing#experimental-bazel-support)
+If you are looking for canonical project samples, see the [Android testing samples](https://github.com/googlesamples/android-testing#experimental-bazel-support)
 for projects using Espresso and UIAutomator.
 
 ## Espresso setup {#espresso-setup}
@@ -560,8 +551,7 @@ API_LEVELS = [
 
 ## Known issues {#known-issues}
 
-- [Forked adb server processes are not terminated after
-  tests](https://github.com/bazelbuild/bazel/issues/4853)
+- [Forked adb server processes are not terminated after tests](https://github.com/bazelbuild/bazel/issues/4853)
 - While APK building works on all platforms (Linux, macOS, Windows), testing
   only works on Linux.
 - Even with `--config=local_adb`, users still need to specify
diff --git a/versions/7.7.1/docs/android-ndk.mdx b/versions/7.7.1/docs/android-ndk.mdx
index f1c5e54c..cf2a1a70 100644
--- a/versions/7.7.1/docs/android-ndk.mdx
+++ b/versions/7.7.1/docs/android-ndk.mdx
@@ -2,8 +2,7 @@
 title: 'Using the Android Native Development Kit with Bazel'
 ---
 
-_If you're new to Bazel, please start with the [Building Android with
-Bazel](/versions/7.7.1/start/android-app ) tutorial._
+_If you're new to Bazel, please start with the [Building Android with Bazel](/versions/7.7.1/start/android-app) tutorial._
 
 ## Overview {#overview}
 
@@ -31,8 +30,7 @@ android_ndk_repository(
 )
 ```
 
-For more information about the `android_ndk_repository` rule, see the [Build
-Encyclopedia entry](/versions/7.7.1/reference/be/android#android_ndk_repository).
+For more information about the `android_ndk_repository` rule, see the [Build Encyclopedia entry](/versions/7.7.1/reference/be/android#android_ndk_repository).
 
 If you're using a recent version of the Android NDK (r22 and beyond), use the
 Starlark implementation of `android_ndk_repository`.
@@ -101,13 +99,11 @@ META-INF/MANIFEST.MF
 
 Bazel compiles all of the cc_libraries into a single shared object (`.so`) file,
 targeted for the `armeabi-v7a` ABI by default. To change this or build for
-multiple ABIs at the same time, see the section on [configuring the target
-ABI](#configuring-target-abi).
+multiple ABIs at the same time, see the section on [configuring the target ABI](#configuring-target-abi).
 
 ## Example setup {#example-setup}
 
-This example is available in the [Bazel examples
-repository](https://github.com/bazelbuild/examples/tree/master/android/ndk).
+This example is available in the [Bazel examples repository](https://github.com/bazelbuild/examples/tree/master/android/ndk).
 
 In the `BUILD.bazel` file, three targets are defined with the `android_binary`,
 `android_library`, and `cc_library` rules.
@@ -178,12 +174,10 @@ For r16 and below, the default STL is `gnustl`. For r17 and above, it is
 `libc++`. For convenience, the target `@androidndk//:default_crosstool` is
 aliased to the respective default STLs.
 
-Please note that from r18 onwards, [STLport and gnustl will be
-removed](https://android.googlesource.com/platform/ndk/+/master/docs/Roadmap.md#ndk-r18),
+Please note that from r18 onwards, [STLport and gnustl will be removed](https://android.googlesource.com/platform/ndk/+/master/docs/Roadmap.md#ndk-r18),
 making `libc++` the only STL in the NDK.
 
-See the [NDK
-documentation](https://developer.android.com/ndk/guides/cpp-support)
+See the [NDK documentation](https://developer.android.com/ndk/guides/cpp-support)
 for more information on these STLs.
 
 ## Configuring the target ABI {#configuring-target-abi}
@@ -324,8 +318,7 @@ an Android-compatible configuration so that the Bazel build *just works* without
 any special flags, except for `--fat_apk_cpu` and `--android_crosstool_top` for
 ABI and STL configuration.
 
-Behind the scenes, this automatic configuration uses Android [configuration
-transitions](/versions/7.7.1/extending/rules#configurations).
+Behind the scenes, this automatic configuration uses Android [configuration transitions](/versions/7.7.1/extending/rules#configurations).
 
 A compatible rule, like `android_binary`, automatically changes the
 configuration of its dependencies to an Android configuration, so only
diff --git a/versions/7.7.1/docs/bazel-and-android.mdx b/versions/7.7.1/docs/bazel-and-android.mdx
index b22338bf..252312f1 100644
--- a/versions/7.7.1/docs/bazel-and-android.mdx
+++ b/versions/7.7.1/docs/bazel-and-android.mdx
@@ -10,7 +10,7 @@ Android projects with Bazel.
 
 The following resources will help you work with Bazel on Android projects:
 
-*  [Tutorial: Building an Android app](/versions/7.7.1/start/android-app ). This
+*  [Tutorial: Building an Android app](/versions/7.7.1/start/android-app). This
    tutorial is a good place to start learning about Bazel commands and concepts,
    and how to build Android apps with Bazel.
 *  [Codelab: Building Android Apps with Bazel](https://developer.android.com/codelabs/bazel-android-intro#0).
diff --git a/versions/7.7.1/docs/configurable-attributes.mdx b/versions/7.7.1/docs/configurable-attributes.mdx
index 342f6c74..585578aa 100644
--- a/versions/7.7.1/docs/configurable-attributes.mdx
+++ b/versions/7.7.1/docs/configurable-attributes.mdx
@@ -2,8 +2,7 @@
 title: 'Configurable Build Attributes'
 ---
 
-**_Configurable attributes_**, commonly known as [`select()`](
-/reference/be/functions#select), is a Bazel feature that lets users toggle the values
+**_Configurable attributes_**, commonly known as [`select()`](/versions/7.7.1/reference/be/functions#select), is a Bazel feature that lets users toggle the values
 of build rule attributes at the command line.
 
 This can be used, for example, for a multiplatform library that automatically
@@ -407,8 +406,7 @@ sh_library(
 )
 ```
 
-If you need a `select` to match when multiple conditions match, consider [AND
-chaining](#and-chaining).
+If you need a `select` to match when multiple conditions match, consider [AND chaining](#and-chaining).
 
 ## OR chaining {#or-chaining}
 
diff --git a/versions/7.7.1/docs/images/a_b_a_c.svg b/versions/7.7.1/docs/images/a_b_a_c.svg
new file mode 100644
index 00000000..d38be075
--- /dev/null
+++ b/versions/7.7.1/docs/images/a_b_a_c.svg
@@ -0,0 +1,42 @@
+
+
+
+
+
+
+G
+
+
+
+a
+
+a
+
+
+
+b
+
+b
+
+
+
+a->b
+
+
+
+
+
+c
+
+c
+
+
+
+a->c
+
+
+
+
+
+
diff --git a/versions/7.7.1/docs/images/a_b_c.svg b/versions/7.7.1/docs/images/a_b_c.svg
new file mode 100644
index 00000000..acd948ab
--- /dev/null
+++ b/versions/7.7.1/docs/images/a_b_c.svg
@@ -0,0 +1,41 @@
+
+
+
+
+
+
+G
+
+
+
+a
+
+a
+
+
+
+b
+
+b
+
+
+
+a->b
+
+
+
+
+
+c
+
+c
+
+
+
+b->c
+
+
+
+
+
diff --git a/versions/7.7.1/docs/images/a_b_c_ac.svg b/versions/7.7.1/docs/images/a_b_c_ac.svg
new file mode 100644
index 00000000..b099c53e
--- /dev/null
+++ b/versions/7.7.1/docs/images/a_b_c_ac.svg
@@ -0,0 +1,47 @@
+
+
+
+
+
+
+G
+
+
+
+a
+
+a
+
+
+
+b
+
+b
+
+
+
+a->b
+
+
+
+
+
+c
+
+c
+
+
+
+a->c
+
+
+
+
+
+b->c
+
+
+
+
+
diff --git a/versions/7.7.1/docs/images/ab_c.svg b/versions/7.7.1/docs/images/ab_c.svg
new file mode 100644
index 00000000..bcc4563f
--- /dev/null
+++ b/versions/7.7.1/docs/images/ab_c.svg
@@ -0,0 +1,36 @@
+
+
+
+
+
+
+G
+
+
+
+a
+
+a
+
+
+
+b
+
+b
+
+
+
+a->b
+
+
+
+
+
+c
+
+c
+
+
+
+
diff --git a/versions/7.7.1/docs/images/allpaths.svg b/versions/7.7.1/docs/images/allpaths.svg
new file mode 100644
index 00000000..47d0ee33
--- /dev/null
+++ b/versions/7.7.1/docs/images/allpaths.svg
@@ -0,0 +1,141 @@
+
+
+
+
+
+
+allpaths
+
+
+
+n1
+
+
+
+
+n2
+
+
+
+
+n1->n2
+
+
+
+
+
+n3
+
+
+
+
+n2->n3
+
+
+
+
+
+n10
+
+
+
+
+n2->n10
+
+
+
+
+
+n3->n10
+
+
+
+
+
+n4
+
+E
+
+
+
+n5
+
+
+
+
+n6
+
+
+
+
+n5->n6
+
+
+
+
+
+n6->n4
+
+
+
+
+
+n9
+
+
+
+
+n6->n9
+
+
+
+
+
+n7
+
+S1
+
+
+
+n7->n2
+
+
+
+
+
+n7->n5
+
+
+
+
+
+n8
+
+S2
+
+
+
+n8->n6
+
+
+
+
+
+n10->n4
+
+
+
+
+
+n11
+
+
+
+
+n10->n11
+
+
+
+
+
diff --git a/versions/7.7.1/docs/images/android_instrumentation_test.png b/versions/7.7.1/docs/images/android_instrumentation_test.png
new file mode 100644
index 00000000..e4534fbd
Binary files /dev/null and b/versions/7.7.1/docs/images/android_instrumentation_test.png differ
diff --git a/versions/7.7.1/docs/images/android_ndk.png b/versions/7.7.1/docs/images/android_ndk.png
new file mode 100644
index 00000000..76b63cb3
Binary files /dev/null and b/versions/7.7.1/docs/images/android_ndk.png differ
diff --git a/versions/7.7.1/docs/images/android_tutorial_app.png b/versions/7.7.1/docs/images/android_tutorial_app.png
new file mode 100644
index 00000000..076be5b9
Binary files /dev/null and b/versions/7.7.1/docs/images/android_tutorial_app.png differ
diff --git a/versions/7.7.1/docs/images/android_tutorial_before.png b/versions/7.7.1/docs/images/android_tutorial_before.png
new file mode 100644
index 00000000..8e41d419
Binary files /dev/null and b/versions/7.7.1/docs/images/android_tutorial_before.png differ
diff --git a/versions/7.7.1/docs/images/bep-graph.png b/versions/7.7.1/docs/images/bep-graph.png
new file mode 100644
index 00000000..82da6715
Binary files /dev/null and b/versions/7.7.1/docs/images/bep-graph.png differ
diff --git a/versions/7.7.1/docs/images/bep-graph.svg b/versions/7.7.1/docs/images/bep-graph.svg
new file mode 100644
index 00000000..62b1480f
--- /dev/null
+++ b/versions/7.7.1/docs/images/bep-graph.svg
@@ -0,0 +1,4 @@
+
+
+
+
diff --git a/versions/7.7.1/docs/images/cpp-tutorial-stage1.png b/versions/7.7.1/docs/images/cpp-tutorial-stage1.png
new file mode 100644
index 00000000..c85fb303
Binary files /dev/null and b/versions/7.7.1/docs/images/cpp-tutorial-stage1.png differ
diff --git a/versions/7.7.1/docs/images/cpp-tutorial-stage2.png b/versions/7.7.1/docs/images/cpp-tutorial-stage2.png
new file mode 100644
index 00000000..80e202c9
Binary files /dev/null and b/versions/7.7.1/docs/images/cpp-tutorial-stage2.png differ
diff --git a/versions/7.7.1/docs/images/cpp-tutorial-stage3.png b/versions/7.7.1/docs/images/cpp-tutorial-stage3.png
new file mode 100644
index 00000000..54d82f31
Binary files /dev/null and b/versions/7.7.1/docs/images/cpp-tutorial-stage3.png differ
diff --git a/versions/7.7.1/docs/images/deps.svg b/versions/7.7.1/docs/images/deps.svg
new file mode 100644
index 00000000..4354222a
--- /dev/null
+++ b/versions/7.7.1/docs/images/deps.svg
@@ -0,0 +1,101 @@
+
+
+
+
+
+
+G1
+
+
+
+r1
+
+rule
+
+
+
+s1
+
+in
+
+
+
+r1->s1
+
+
+
+
+
+s2
+
+in
+
+
+
+r1->s2
+
+
+
+
+
+s3
+
+in
+
+
+
+r1->s3
+
+
+
+
+
+r2
+
+rule
+
+
+
+r2->r1
+
+
+
+
+
+s4
+
+in
+
+
+
+r2->s4
+
+
+
+
+
+o1
+
+out
+
+
+
+o1->r1
+
+
+
+
+
+o2
+
+out
+
+
+
+o2->r2
+
+
+
+
+
diff --git a/versions/7.7.1/docs/images/dyn-trace-alldynamic.png b/versions/7.7.1/docs/images/dyn-trace-alldynamic.png
new file mode 100644
index 00000000..fe36b253
Binary files /dev/null and b/versions/7.7.1/docs/images/dyn-trace-alldynamic.png differ
diff --git a/versions/7.7.1/docs/images/dyn-trace-javaconly.png b/versions/7.7.1/docs/images/dyn-trace-javaconly.png
new file mode 100644
index 00000000..2ae41e52
Binary files /dev/null and b/versions/7.7.1/docs/images/dyn-trace-javaconly.png differ
diff --git a/versions/7.7.1/docs/images/e4b-workflow.png b/versions/7.7.1/docs/images/e4b-workflow.png
new file mode 100644
index 00000000..412822da
Binary files /dev/null and b/versions/7.7.1/docs/images/e4b-workflow.png differ
diff --git a/versions/7.7.1/docs/images/e4b-workflow.svg b/versions/7.7.1/docs/images/e4b-workflow.svg
new file mode 100644
index 00000000..1de66e02
--- /dev/null
+++ b/versions/7.7.1/docs/images/e4b-workflow.svg
@@ -0,0 +1,4 @@
+
+
+
+
diff --git a/versions/7.7.1/docs/images/error_example_1.png b/versions/7.7.1/docs/images/error_example_1.png
new file mode 100644
index 00000000..07ba1358
Binary files /dev/null and b/versions/7.7.1/docs/images/error_example_1.png differ
diff --git a/versions/7.7.1/docs/images/error_example_2.png b/versions/7.7.1/docs/images/error_example_2.png
new file mode 100644
index 00000000..861171ee
Binary files /dev/null and b/versions/7.7.1/docs/images/error_example_2.png differ
diff --git a/versions/7.7.1/docs/images/error_example_3.png b/versions/7.7.1/docs/images/error_example_3.png
new file mode 100644
index 00000000..dc16eec4
Binary files /dev/null and b/versions/7.7.1/docs/images/error_example_3.png differ
diff --git a/versions/7.7.1/docs/images/error_example_4.png b/versions/7.7.1/docs/images/error_example_4.png
new file mode 100644
index 00000000..84383e63
Binary files /dev/null and b/versions/7.7.1/docs/images/error_example_4.png differ
diff --git a/versions/7.7.1/docs/images/graph_ex_1.svg b/versions/7.7.1/docs/images/graph_ex_1.svg
new file mode 100644
index 00000000..dd7427f4
--- /dev/null
+++ b/versions/7.7.1/docs/images/graph_ex_1.svg
@@ -0,0 +1,131 @@
+
+
+
+
+
+
+mygraph
+
+
+
+//net/proto_compiler:protocol-compiler
+
+//net/proto_compiler:protocol-compiler
+
+
+
+//net/proto_compiler:util
+
+//net/proto_compiler:util
+
+
+
+//net/proto_compiler:protocol-compiler->//net/proto_compiler:util
+
+
+
+
+
+//net/proto_compiler:protocol-compiler-lib
+
+//net/proto_compiler:protocol-compiler-lib
+
+
+
+//net/proto_compiler:protocol-compiler->//net/proto_compiler:protocol-compiler-lib
+
+
+
+
+
+//net/proto2/bridge/public:compiler_upgrader
+
+//net/proto2/bridge/public:compiler_upgrader
+
+
+
+//net/proto_compiler:protocol-compiler->//net/proto2/bridge/public:compiler_upgrader
+
+
+
+
+
+//net/proto_compiler:parser
+
+//net/proto_compiler:parser
+
+
+
+//net/proto_compiler:util->//net/proto_compiler:parser
+
+
+
+
+
+//net/proto_compiler:proto-min-lib
+
+//net/proto_compiler:proto-min-lib
+
+
+
+//net/proto_compiler:protocol-compiler-lib->//net/proto_compiler:proto-min-lib
+
+
+
+
+
+//net/proto_compiler:protocol-compiler-lib->//net/proto_compiler:parser
+
+
+
+
+
+//net/proto2/bridge/internal:compiler_upgrader
+
+//net/proto2/bridge/internal:compiler_upgrader
+
+
+
+//net/proto2/bridge/public:compiler_upgrader->//net/proto2/bridge/internal:compiler_upgrader
+
+
+
+
+
+//net/proto_compiler:proto-min-lib->//net/proto_compiler:parser
+
+
+
+
+
+//util/regexp:regexp
+
+//util/regexp:regexp
+
+
+
+//net/proto_compiler:proto-min-lib->//util/regexp:regexp
+
+
+
+
+
+//net/proto_compiler:parser->//util/regexp:regexp
+
+
+
+
+
+//net/proto2/bridge/internal:compiler_upgrader->//net/proto2/bridge/public:compiler_upgrader
+
+
+
+
+
+//net/proto2/bridge/internal:compiler_upgrader->//net/proto_compiler:parser
+
+
+
+
+
diff --git a/versions/7.7.1/docs/images/graph_hello-world.svg b/versions/7.7.1/docs/images/graph_hello-world.svg
new file mode 100644
index 00000000..93b61444
--- /dev/null
+++ b/versions/7.7.1/docs/images/graph_hello-world.svg
@@ -0,0 +1,70 @@
+
+
+
+
+
+
+mygraph
+
+
+//main:hello-world
+
+//main:hello-world
+
+
+//main:hello-time
+
+//main:hello-time
+
+
+//main:hello-world->//main:hello-time
+
+
+
+
+//main:hello-world.cc
+
+//main:hello-world.cc
+
+
+//main:hello-world->//main:hello-world.cc
+
+
+
+
+//lib:hello-greet
+
+//lib:hello-greet
+
+
+//main:hello-world->//lib:hello-greet
+
+
+
+
+//main:hello-time.cc\n//main:hello-time.h
+
+//main:hello-time.cc
+//main:hello-time.h
+
+
+//main:hello-time->//main:hello-time.cc\n//main:hello-time.h
+
+
+
+
+//lib:hello-greet.cc\n//lib:hello-greet.h
+
+//lib:hello-greet.cc
+//lib:hello-greet.h
+
+
+//lib:hello-greet->//lib:hello-greet.cc\n//lib:hello-greet.h
+
+
+
+
+
diff --git a/versions/7.7.1/docs/images/json-trace-profile-network-usage.png b/versions/7.7.1/docs/images/json-trace-profile-network-usage.png
new file mode 100644
index 00000000..8a7500a6
Binary files /dev/null and b/versions/7.7.1/docs/images/json-trace-profile-network-usage.png differ
diff --git a/versions/7.7.1/docs/images/json-trace-profile-system-load-average.png b/versions/7.7.1/docs/images/json-trace-profile-system-load-average.png
new file mode 100644
index 00000000..e71b420c
Binary files /dev/null and b/versions/7.7.1/docs/images/json-trace-profile-system-load-average.png differ
diff --git a/versions/7.7.1/docs/images/json-trace-profile-workers-memory-usage.png b/versions/7.7.1/docs/images/json-trace-profile-workers-memory-usage.png
new file mode 100644
index 00000000..806505f0
Binary files /dev/null and b/versions/7.7.1/docs/images/json-trace-profile-workers-memory-usage.png differ
diff --git a/versions/7.7.1/docs/images/json-trace-profile.png b/versions/7.7.1/docs/images/json-trace-profile.png
new file mode 100644
index 00000000..538382b2
Binary files /dev/null and b/versions/7.7.1/docs/images/json-trace-profile.png differ
diff --git a/versions/7.7.1/docs/images/mobile-install-performance.svg b/versions/7.7.1/docs/images/mobile-install-performance.svg
new file mode 100644
index 00000000..b139d658
--- /dev/null
+++ b/versions/7.7.1/docs/images/mobile-install-performance.svg
@@ -0,0 +1,86 @@
+
+
+
+  
+    
+      
+    
+  
+  
+  
+    Build times
+  
+  
+    
+    
+      
+      
+        adb install
+      
+      
+    
+    
+      
+      
+        mobile-install
+      
+      
+    
+  
+  
+    
+    
+      
+        
+        
+        
+        
+        
+      
+      
+        
+        
+        
+        
+        
+        
+      
+      
+        
+      
+    
+    
+    
+      
+        Google Maps
+      
+      
+        Google+
+      
+      
+        YouTube
+      
+      
+        0
+      
+      
+        75
+      
+      
+        150
+      
+      
+        225
+      
+      
+        300
+      
+    
+  
+  
+    
+      Seconds
+    
+  
+  
+
diff --git a/versions/7.7.1/docs/images/namedsetoffiles-bep-graph.png b/versions/7.7.1/docs/images/namedsetoffiles-bep-graph.png
new file mode 100644
index 00000000..ea1e10cc
Binary files /dev/null and b/versions/7.7.1/docs/images/namedsetoffiles-bep-graph.png differ
diff --git a/versions/7.7.1/docs/images/out-ranked.svg b/versions/7.7.1/docs/images/out-ranked.svg
new file mode 100644
index 00000000..07e96804
--- /dev/null
+++ b/versions/7.7.1/docs/images/out-ranked.svg
@@ -0,0 +1,71 @@
+
+
+
+
+
+
+mygraph
+
+
+
+//a:a
+
+//a:a
+
+
+
+//a:a.cc
+
+//a:a.cc
+
+
+
+//a:a->//a:a.cc
+
+
+
+
+
+//b:b
+
+//b:b
+
+
+
+//b:b->//a:a
+
+
+
+
+
+//b:b.cc
+
+//b:b.cc
+
+
+
+//b:b->//b:b.cc
+
+
+
+
+
+//c:c
+
+//c:c
+
+
+
+//c:c->//a:a
+
+
+
+
+
+//c:c->//b:b
+
+
+
+
+
diff --git a/versions/7.7.1/docs/images/rbe-ci-1.png b/versions/7.7.1/docs/images/rbe-ci-1.png
new file mode 100644
index 00000000..fbe76a85
Binary files /dev/null and b/versions/7.7.1/docs/images/rbe-ci-1.png differ
diff --git a/versions/7.7.1/docs/images/rbe-ci-2.png b/versions/7.7.1/docs/images/rbe-ci-2.png
new file mode 100644
index 00000000..07611889
Binary files /dev/null and b/versions/7.7.1/docs/images/rbe-ci-2.png differ
diff --git a/versions/7.7.1/docs/images/somepath1.svg b/versions/7.7.1/docs/images/somepath1.svg
new file mode 100644
index 00000000..5e5f8812
--- /dev/null
+++ b/versions/7.7.1/docs/images/somepath1.svg
@@ -0,0 +1,141 @@
+
+
+
+
+
+
+somepath1
+
+
+
+n1
+
+
+
+
+n2
+
+
+
+
+n1->n2
+
+
+
+
+
+n3
+
+
+
+
+n2->n3
+
+
+
+
+
+n10
+
+
+
+
+n2->n10
+
+
+
+
+
+n3->n10
+
+
+
+
+
+n4
+
+E
+
+
+
+n5
+
+
+
+
+n6
+
+
+
+
+n5->n6
+
+
+
+
+
+n6->n4
+
+
+
+
+
+n9
+
+
+
+
+n6->n9
+
+
+
+
+
+n7
+
+S1
+
+
+
+n7->n2
+
+
+
+
+
+n7->n5
+
+
+
+
+
+n8
+
+S2
+
+
+
+n8->n6
+
+
+
+
+
+n10->n4
+
+
+
+
+
+n11
+
+
+
+
+n10->n11
+
+
+
+
+
diff --git a/versions/7.7.1/docs/images/somepath2.svg b/versions/7.7.1/docs/images/somepath2.svg
new file mode 100644
index 00000000..911f2c9b
--- /dev/null
+++ b/versions/7.7.1/docs/images/somepath2.svg
@@ -0,0 +1,141 @@
+
+
+
+
+
+
+somepath2
+
+
+
+n1
+
+
+
+
+n2
+
+
+
+
+n1->n2
+
+
+
+
+
+n3
+
+
+
+
+n2->n3
+
+
+
+
+
+n10
+
+
+
+
+n2->n10
+
+
+
+
+
+n3->n10
+
+
+
+
+
+n4
+
+E
+
+
+
+n5
+
+
+
+
+n6
+
+
+
+
+n5->n6
+
+
+
+
+
+n6->n4
+
+
+
+
+
+n9
+
+
+
+
+n6->n9
+
+
+
+
+
+n7
+
+S1
+
+
+
+n7->n2
+
+
+
+
+
+n7->n5
+
+
+
+
+
+n8
+
+S2
+
+
+
+n8->n6
+
+
+
+
+
+n10->n4
+
+
+
+
+
+n11
+
+
+
+
+n10->n11
+
+
+
+
+
diff --git a/versions/7.7.1/docs/images/targets.svg b/versions/7.7.1/docs/images/targets.svg
new file mode 100644
index 00000000..82f47e74
--- /dev/null
+++ b/versions/7.7.1/docs/images/targets.svg
@@ -0,0 +1,113 @@
+
+
+
+
+
+
+G1
+
+
+
+Target
+
+Target
+
+
+
+Rule
+
+Rule
+
+
+
+Target->Rule
+
+
+
+
+
+File
+
+File
+
+
+
+Target->File
+
+
+
+
+
+Package group
+
+Package group
+
+
+
+Target->Package group
+
+
+
+
+
+cc_library
+
+cc_library
+
+
+
+Rule->cc_library
+
+
+
+
+
+java_test
+
+java_test
+
+
+
+Rule->java_test
+
+
+
+
+
+...
+
+...
+
+
+
+Rule->...
+
+
+
+
+
+Source
+
+Source
+
+
+
+File->Source
+
+
+
+
+
+Generated
+
+Generated
+
+
+
+File->Generated
+
+
+
+
+
diff --git a/versions/7.7.1/docs/images/tutorial_java_01.svg b/versions/7.7.1/docs/images/tutorial_java_01.svg
new file mode 100644
index 00000000..2fe72f36
--- /dev/null
+++ b/versions/7.7.1/docs/images/tutorial_java_01.svg
@@ -0,0 +1,29 @@
+
+
+
+
+
+
+mygraph
+
+
+//:ProjectRunner
+
+//:ProjectRunner
+
+
+//:src/main/java/com/example/Greeting.java\n//:src/main/java/com/example/ProjectRunner.java
+
+//:src/main/java/com/example/Greeting.java
+//:src/main/java/com/example/ProjectRunner.java
+
+
+//:ProjectRunner->//:src/main/java/com/example/Greeting.java\n//:src/main/java/com/example/ProjectRunner.java
+
+
+
+
+
diff --git a/versions/7.7.1/docs/images/tutorial_java_02.svg b/versions/7.7.1/docs/images/tutorial_java_02.svg
new file mode 100644
index 00000000..40cbb218
--- /dev/null
+++ b/versions/7.7.1/docs/images/tutorial_java_02.svg
@@ -0,0 +1,48 @@
+
+
+
+
+
+
+mygraph
+
+
+//:ProjectRunner
+
+//:ProjectRunner
+
+
+//:greeter
+
+//:greeter
+
+
+//:ProjectRunner->//:greeter
+
+
+
+
+//:src/main/java/com/example/ProjectRunner.java
+
+//:src/main/java/com/example/ProjectRunner.java
+
+
+//:ProjectRunner->//:src/main/java/com/example/ProjectRunner.java
+
+
+
+
+//:src/main/java/com/example/Greeting.java
+
+//:src/main/java/com/example/Greeting.java
+
+
+//:greeter->//:src/main/java/com/example/Greeting.java
+
+
+
+
+
diff --git a/versions/7.7.1/docs/images/tutorial_java_03.svg b/versions/7.7.1/docs/images/tutorial_java_03.svg
new file mode 100644
index 00000000..7d79041a
--- /dev/null
+++ b/versions/7.7.1/docs/images/tutorial_java_03.svg
@@ -0,0 +1,48 @@
+
+
+
+
+
+
+mygraph
+
+
+//src/main/java/com/example/cmdline:runner
+
+//src/main/java/com/example/cmdline:runner
+
+
+//src/main/java/com/example/cmdline:Runner.java
+
+//src/main/java/com/example/cmdline:Runner.java
+
+
+//src/main/java/com/example/cmdline:runner->//src/main/java/com/example/cmdline:Runner.java
+
+
+
+
+//:greeter
+
+//:greeter
+
+
+//src/main/java/com/example/cmdline:runner->//:greeter
+
+
+
+
+//:src/main/java/com/example/Greeting.java
+
+//:src/main/java/com/example/Greeting.java
+
+
+//:greeter->//:src/main/java/com/example/Greeting.java
+
+
+
+
+
diff --git a/versions/7.7.1/docs/images/workers-clean-chart.png b/versions/7.7.1/docs/images/workers-clean-chart.png
new file mode 100644
index 00000000..63526fc1
Binary files /dev/null and b/versions/7.7.1/docs/images/workers-clean-chart.png differ
diff --git a/versions/7.7.1/docs/images/workers-incremental-chart.png b/versions/7.7.1/docs/images/workers-incremental-chart.png
new file mode 100644
index 00000000..1c62d25c
Binary files /dev/null and b/versions/7.7.1/docs/images/workers-incremental-chart.png differ
diff --git a/versions/7.7.1/docs/images/ws-diamond.png b/versions/7.7.1/docs/images/ws-diamond.png
new file mode 100644
index 00000000..154a7440
Binary files /dev/null and b/versions/7.7.1/docs/images/ws-diamond.png differ
diff --git a/versions/7.7.1/docs/images/ws-line.png b/versions/7.7.1/docs/images/ws-line.png
new file mode 100644
index 00000000..e8bfe7a1
Binary files /dev/null and b/versions/7.7.1/docs/images/ws-line.png differ
diff --git a/versions/7.7.1/docs/images/ws-multiline.png b/versions/7.7.1/docs/images/ws-multiline.png
new file mode 100644
index 00000000..f07b43b1
Binary files /dev/null and b/versions/7.7.1/docs/images/ws-multiline.png differ
diff --git a/versions/7.7.1/docs/sandboxing.mdx b/versions/7.7.1/docs/sandboxing.mdx
index 9f0dd42a..e14c4221 100644
--- a/versions/7.7.1/docs/sandboxing.mdx
+++ b/versions/7.7.1/docs/sandboxing.mdx
@@ -48,7 +48,7 @@ containers on Linux and `sandbox-exec` on macOS, to constrain the action within
 ## What sandbox strategy to use {#sandboxing-strategies}
 
 You can choose which kind of sandboxing to use, if any, with the
-[strategy flags](user-manual#strategy-options). Using the `sandboxed`
+[strategy flags](/versions/7.7.1/docs/user-manual#strategy-options). Using the `sandboxed`
 strategy makes Bazel pick one of the sandbox implementations listed below,
 preferring an OS-specific sandbox to the less hermetic generic one.
 [Persistent workers](/versions/7.7.1/remote/persistent) run in a generic sandbox if you pass
diff --git a/versions/7.7.1/docs/user-manual.mdx b/versions/7.7.1/docs/user-manual.mdx
index a748373b..32eab18c 100644
--- a/versions/7.7.1/docs/user-manual.mdx
+++ b/versions/7.7.1/docs/user-manual.mdx
@@ -1167,7 +1167,7 @@ This option causes Bazel's execution phase to print the full command line
 for each command prior to executing it.
 
 ```
-  >>>>> # //examples/cpp:hello-world [action 'Linking examples/cpp/hello-world']
+  >>>> # //examples/cpp:hello-world [action 'Linking examples/cpp/hello-world']
   (cd /home/johndoe/.cache/bazel/_bazel_johndoe/4c084335afceb392cfbe7c31afee3a9f/bazel && \
     exec env - \
     /usr/bin/gcc -o bazel-out/local-fastbuild/bin/examples/cpp/hello-world -B/usr/bin/ -Wl,-z,relro,-z,now -no-canonical-prefixes -pass-exit-codes -Wl,-S -Wl,@bazel-out/local_linux-fastbuild/bin/examples/cpp/hello-world-2.params)
diff --git a/versions/7.7.1/extending/depsets.mdx b/versions/7.7.1/extending/depsets.mdx
index a64fcf24..c9f14ca0 100644
--- a/versions/7.7.1/extending/depsets.mdx
+++ b/versions/7.7.1/extending/depsets.mdx
@@ -111,8 +111,7 @@ need to ensure that if `B` depends on `A`, then `A.o` comes before `B.o` on the
 linker’s command line. Other tools might have the opposite requirement.
 
 Three traversal orders are supported: `postorder`, `preorder`, and
-`topological`. The first two work exactly like [tree
-traversals](https://en.wikipedia.org/wiki/Tree_traversal#Depth-first_search)
+`topological`. The first two work exactly like [tree traversals](https://en.wikipedia.org/wiki/Tree_traversal#Depth-first_search)
 except that they operate on DAGs and skip already visited nodes. The third order
 works as a topological sort from root to leaves, essentially the same as
 preorder except that shared children are listed only after all of their parents.
diff --git a/versions/7.7.1/extending/exec-groups.mdx b/versions/7.7.1/extending/exec-groups.mdx
index 22808d61..a2d07e82 100644
--- a/versions/7.7.1/extending/exec-groups.mdx
+++ b/versions/7.7.1/extending/exec-groups.mdx
@@ -63,8 +63,7 @@ test rules.
 
 In the rule implementation, you can declare that actions should be run on the
 execution platform of an execution group. You can do this by using the `exec_group`
-param of action generating methods, specifically [`ctx.actions.run`]
-(/rules/lib/builtins/actions#run) and
+param of action generating methods, specifically [`ctx.actions.run`](/versions/7.7.1/rules/lib/builtins/actions#run) and
 [`ctx.actions.run_shell`](/versions/7.7.1/rules/lib/builtins/actions#run_shell).
 
 ```python
diff --git a/versions/7.7.1/extending/macros.mdx b/versions/7.7.1/extending/macros.mdx
index d35987d2..79be8d63 100644
--- a/versions/7.7.1/extending/macros.mdx
+++ b/versions/7.7.1/extending/macros.mdx
@@ -139,7 +139,7 @@ Note that `native` can only be used in `.bzl` files, and not in `BUILD` files.
 
 ## Label resolution in macros
 
-Since macros are evaluated in the [loading phase](concepts.md#evaluation-model),
+Since macros are evaluated in the [loading phase](/versions/7.7.1/extending/concepts#evaluation-model),
 label strings such as `"//foo:bar"` that occur in a macro are interpreted
 relative to the `BUILD` file in which the macro is used rather than relative to
 the `.bzl` file in which it is defined. This behavior is generally undesirable
@@ -212,8 +212,7 @@ def my_macro(name, deps, visibility=None):
     instantiate rules must have a `name` argument. This argument should not be
     optional (don't give a default value).
 
-*   Public functions should use a docstring following [Python
-    conventions](https://www.python.org/dev/peps/pep-0257/#one-line-docstrings).
+*   Public functions should use a docstring following [Python conventions](https://www.python.org/dev/peps/pep-0257/#one-line-docstrings).
 
 *   In `BUILD` files, the `name` argument of the macros must be a keyword
     argument (not a positional argument).
diff --git a/versions/7.7.1/extending/platforms.mdx b/versions/7.7.1/extending/platforms.mdx
index bdddc9a5..a16a241d 100644
--- a/versions/7.7.1/extending/platforms.mdx
+++ b/versions/7.7.1/extending/platforms.mdx
@@ -245,8 +245,7 @@ cc_library(
 
 You can use the
 [`IncompatiblePlatformProvider`](/versions/7.7.1/rules/lib/providers/IncompatiblePlatformProvider)
-in `bazel cquery`'s [Starlark output
-format](/versions/7.7.1/query/cquery#output-format-definition) to distinguish
+in `bazel cquery`'s [Starlark output format](/versions/7.7.1/query/cquery#output-format-definition) to distinguish
 incompatible targets from compatible ones.
 
 This can be used to filter out incompatible targets. The example below will
@@ -266,5 +265,4 @@ $ bazel cquery //... --output=starlark --starlark:file=example.cquery
 
 ### Known Issues
 
-Incompatible targets [ignore visibility
-restrictions](https://github.com/bazelbuild/bazel/issues/16044).
+Incompatible targets [ignore visibility restrictions](https://github.com/bazelbuild/bazel/issues/16044).
diff --git a/versions/7.7.1/extending/repo.mdx b/versions/7.7.1/extending/repo.mdx
index 8e879276..6296d90c 100644
--- a/versions/7.7.1/extending/repo.mdx
+++ b/versions/7.7.1/extending/repo.mdx
@@ -74,8 +74,7 @@ specified.
 
 The input parameter `repository_ctx` can be used to access attribute values, and
 non-hermetic functions (finding a binary, executing a binary, creating a file in
-the repository or downloading a file from the Internet). See [the API
-docs](/versions/7.7.1/rules/lib/builtins/repository_ctx) for more context. Example:
+the repository or downloading a file from the Internet). See [the API docs](/versions/7.7.1/rules/lib/builtins/repository_ctx) for more context. Example:
 
 ```python
 def _impl(repository_ctx):
@@ -144,8 +143,7 @@ definition has the `configure` attribute set, use `bazel fetch --force
 
 ## Examples
 
--   [C++ auto-configured
-    toolchain](https://cs.opensource.google/bazel/bazel/+/master:tools/cpp/cc_configure.bzl;drc=644b7d41748e09eff9e47cbab2be2263bb71f29a;l=176):
+-   [C++ auto-configured toolchain](https://cs.opensource.google/bazel/bazel/+/master:tools/cpp/cc_configure.bzl;drc=644b7d41748e09eff9e47cbab2be2263bb71f29a;l=176):
     it uses a repo rule to automatically create the C++ configuration files for
     Bazel by looking for the local C++ compiler, the environment and the flags
     the C++ compiler supports.
diff --git a/versions/7.7.1/extending/rules.mdx b/versions/7.7.1/extending/rules.mdx
index 3f298134..d8643b76 100644
--- a/versions/7.7.1/extending/rules.mdx
+++ b/versions/7.7.1/extending/rules.mdx
@@ -462,8 +462,7 @@ def _example_library_impl(ctx):
 
 If `DefaultInfo` is not returned by a rule implementation or the `files`
 parameter is not specified, `DefaultInfo.files` defaults to all
-*predeclared outputs* (generally, those created by [output
-attributes](#output_attributes)).
+*predeclared outputs* (generally, those created by [output attributes](#output_attributes)).
 
 Rules that perform actions should provide default outputs, even if those outputs
 are not expected to be directly used. Actions that are not in the graph of the
diff --git a/versions/7.7.1/external/advanced.mdx b/versions/7.7.1/external/advanced.mdx
index 1806c7b0..407e8059 100644
--- a/versions/7.7.1/external/advanced.mdx
+++ b/versions/7.7.1/external/advanced.mdx
@@ -4,10 +4,8 @@ title: 'Advanced topics on external dependencies'
 
 ## Shadowing dependencies in WORKSPACE
 
-Note: This section applies to the [WORKSPACE
-system](/versions/7.7.1/external/overview#workspace-system) only. For
-[Bzlmod](/versions/7.7.1/external/overview#bzlmod), use a [multiple-version
-override](/versions/7.7.1/external/module#multiple-version_override).
+Note: This section applies to the [WORKSPACE system](/versions/7.7.1/external/overview#workspace-system) only. For
+[Bzlmod](/versions/7.7.1/external/overview#bzlmod), use a [multiple-version override](/versions/7.7.1/external/module#multiple-version_override).
 
 Whenever possible, have a single version policy in your project, which is
 required for dependencies that you compile against and end up in your final
@@ -128,29 +126,24 @@ preferring IPv4 if enabled. In some situations, for example when the IPv4
 network cannot resolve/reach external addresses, this can cause `Network
 unreachable` exceptions and build failures. In these cases, you can override
 Bazel's behavior to prefer IPv6 by using the
-[`java.net.preferIPv6Addresses=true` system
-property](https://docs.oracle.com/javase/8/docs/api/java/net/doc-files/net-properties.html).
+[`java.net.preferIPv6Addresses=true` system property](https://docs.oracle.com/javase/8/docs/api/java/net/doc-files/net-properties.html).
 Specifically:
 
-*   Use `--host_jvm_args=-Djava.net.preferIPv6Addresses=true` [startup
-    option](/versions/7.7.1/docs/user-manual#startup-options), for example by adding the
+*   Use `--host_jvm_args=-Djava.net.preferIPv6Addresses=true` [startup option](/versions/7.7.1/docs/user-manual#startup-options), for example by adding the
     following line in your [`.bazelrc` file](/versions/7.7.1/run/bazelrc):
 
     `startup --host_jvm_args=-Djava.net.preferIPv6Addresses=true`
 
 *   When running Java build targets that need to connect to the internet (such
     as for integration tests), use the
-    `--jvmopt=-Djava.net.preferIPv6Addresses=true` [tool
-    flag](/versions/7.7.1/docs/user-manual#jvmopt). For example, include in your [`.bazelrc`
-    file](/versions/7.7.1/run/bazelrc):
+    `--jvmopt=-Djava.net.preferIPv6Addresses=true` [tool flag](/versions/7.7.1/docs/user-manual#jvmopt). For example, include in your [`.bazelrc` file](/versions/7.7.1/run/bazelrc):
 
     `build --jvmopt=-Djava.net.preferIPv6Addresses`
 
 *   If you are using [`rules_jvm_external`](https://github.com/bazelbuild/rules_jvm_external)
     for dependency version resolution, also add
     `-Djava.net.preferIPv6Addresses=true` to the `COURSIER_OPTS` environment
-    variable to [provide JVM options for
-    Coursier](https://github.com/bazelbuild/rules_jvm_external#provide-jvm-options-for-coursier-with-coursier_opts).
+    variable to [provide JVM options for Coursier](https://github.com/bazelbuild/rules_jvm_external#provide-jvm-options-for-coursier-with-coursier_opts).
 
 ## Offline builds
 
@@ -167,15 +160,12 @@ fetch a file with [`ctx.download`](/versions/7.7.1/rules/lib/builtins/repository
 providing a hash sum of the file needed, Bazel looks for a file matching the
 basename of the first URL, and uses the local copy if the hash matches.
 
-Bazel itself uses this technique to bootstrap offline from the [distribution
-artifact](https://github.com/bazelbuild/bazel-website/blob/master/designs/_posts/2016-10-11-distribution-artifact.md).
-It does so by [collecting all the needed external
-dependencies](https://github.com/bazelbuild/bazel/blob/5cfa0303d6ac3b5bd031ff60272ce80a704af8c2/WORKSPACE#L116)
+Bazel itself uses this technique to bootstrap offline from the [distribution artifact](https://github.com/bazelbuild/bazel-website/blob/master/designs/_posts/2016-10-11-distribution-artifact.md).
+It does so by [collecting all the needed external dependencies](https://github.com/bazelbuild/bazel/blob/5cfa0303d6ac3b5bd031ff60272ce80a704af8c2/WORKSPACE#L116)
 in an internal
 [`distdir_tar`](https://github.com/bazelbuild/bazel/blob/5cfa0303d6ac3b5bd031ff60272ce80a704af8c2/distdir.bzl#L44).
 
 Bazel allows execution of arbitrary commands in repository rules without knowing
 if they call out to the network, and so cannot enforce fully offline builds. To
 test if a build works correctly offline, manually block off the network (as
-Bazel does in its [bootstrap
-test](https://cs.opensource.google/bazel/bazel/+/master:src/test/shell/bazel/BUILD;l=1073;drc=88c426e73cc0eb0a41c0d7995e36acd94e7c9a48)).
\ No newline at end of file
+Bazel does in its [bootstrap test](https://cs.opensource.google/bazel/bazel/+/master:src/test/shell/bazel/BUILD;l=1073;drc=88c426e73cc0eb0a41c0d7995e36acd94e7c9a48)).
\ No newline at end of file
diff --git a/versions/7.7.1/external/images/mod_exampleBefore.svg b/versions/7.7.1/external/images/mod_exampleBefore.svg
new file mode 100644
index 00000000..66f01303
--- /dev/null
+++ b/versions/7.7.1/external/images/mod_exampleBefore.svg
@@ -0,0 +1,175 @@
+
+
+
+
+
+
+mygraph
+
+
+
+<root>
+
+<root> (my_project@1.0)
+
+
+
+bazel_skylib@1.1.1
+
+bazel_skylib@1.1.1
+
+
+
+<root>->bazel_skylib@1.1.1
+
+
+
+
+
+bazel_skylib@1.2.0
+
+bazel_skylib@1.2.0
+
+
+
+<root>->bazel_skylib@1.2.0
+
+
+
+
+
+rules_java@5.0.0
+
+rules_java@5.0.0
+
+
+
+<root>->rules_java@5.0.0
+
+
+
+
+
+stardoc@0.5.0
+
+stardoc@0.5.0
+
+
+
+<root>->stardoc@0.5.0
+
+
+
+
+
+platforms@0.0.4
+
+platforms@0.0.4
+
+
+
+bazel_skylib@1.1.1->platforms@0.0.4
+
+
+
+
+
+bazel_skylib@1.2.0->platforms@0.0.4
+
+
+
+
+
+rules_java@5.0.0->platforms@0.0.4
+
+
+
+
+
+rules_cc@0.0.1
+
+rules_cc@0.0.1
+
+
+
+rules_java@5.0.0->rules_cc@0.0.1
+
+
+
+
+
+rules_proto@4.0.0
+
+rules_proto@4.0.0
+
+
+
+rules_java@5.0.0->rules_proto@4.0.0
+
+
+
+
+
+bazel_skylib@1.0.3
+
+bazel_skylib@1.0.3
+
+
+
+stardoc@0.5.0->bazel_skylib@1.0.3
+
+
+
+
+
+rules_java@4.0.0
+
+rules_java@4.0.0
+
+
+
+stardoc@0.5.0->rules_java@4.0.0
+
+
+
+
+
+rules_cc@0.0.1->platforms@0.0.4
+
+
+
+
+
+rules_cc@0.0.1->bazel_skylib@1.0.3
+
+
+
+
+
+rules_proto@4.0.0->rules_cc@0.0.1
+
+
+
+
+
+rules_proto@4.0.0->bazel_skylib@1.0.3
+
+
+
+
+
+bazel_skylib@1.0.3->platforms@0.0.4
+
+
+
+
+
+rules_java@4.0.0->bazel_skylib@1.0.3
+
+
+
+
+
\ No newline at end of file
diff --git a/versions/7.7.1/external/images/mod_exampleResolved.svg b/versions/7.7.1/external/images/mod_exampleResolved.svg
new file mode 100644
index 00000000..224b694c
--- /dev/null
+++ b/versions/7.7.1/external/images/mod_exampleResolved.svg
@@ -0,0 +1,151 @@
+
+
+
+
+
+
+mygraph
+
+
+
+<root>
+
+<root> (my_project@1.0)
+
+
+
+bazel_skylib@1.1.1
+
+bazel_skylib@1.1.1
+
+
+
+<root>->bazel_skylib@1.1.1
+
+
+
+
+
+bazel_skylib@1.2.0
+
+bazel_skylib@1.2.0
+
+
+
+<root>->bazel_skylib@1.2.0
+
+
+
+
+
+rules_java@5.0.0
+
+rules_java@5.0.0
+
+
+
+<root>->rules_java@5.0.0
+
+
+
+
+
+stardoc@0.5.0
+
+stardoc@0.5.0
+
+
+
+<root>->stardoc@0.5.0
+
+
+
+
+
+platforms@0.0.4
+
+platforms@0.0.4
+
+
+
+bazel_skylib@1.1.1->platforms@0.0.4
+
+
+
+
+
+bazel_skylib@1.2.0->platforms@0.0.4
+
+
+
+
+
+rules_java@5.0.0->platforms@0.0.4
+
+
+
+
+
+rules_cc@0.0.1
+
+rules_cc@0.0.1
+
+
+
+rules_java@5.0.0->rules_cc@0.0.1
+
+
+
+
+
+rules_proto@4.0.0
+
+rules_proto@4.0.0
+
+
+
+rules_java@5.0.0->rules_proto@4.0.0
+
+
+
+
+
+stardoc@0.5.0->bazel_skylib@1.1.1
+
+
+
+
+
+stardoc@0.5.0->rules_java@5.0.0
+
+
+
+
+
+rules_cc@0.0.1->bazel_skylib@1.1.1
+
+
+
+
+
+rules_cc@0.0.1->platforms@0.0.4
+
+
+
+
+
+rules_proto@4.0.0->bazel_skylib@1.1.1
+
+
+
+
+
+rules_proto@4.0.0->rules_cc@0.0.1
+
+
+
+
+
\ No newline at end of file
diff --git a/versions/7.7.1/external/migration.mdx b/versions/7.7.1/external/migration.mdx
index 9aa7e447..25fb84da 100644
--- a/versions/7.7.1/external/migration.mdx
+++ b/versions/7.7.1/external/migration.mdx
@@ -2,8 +2,7 @@
 title: 'Bzlmod Migration Guide'
 ---
 
-Due to the [shortcomings of
-WORKSPACE](/versions/7.7.1/external/overview#workspace-shortcomings), Bzlmod is going to
+Due to the [shortcomings of WORKSPACE](/versions/7.7.1/external/overview#workspace-shortcomings), Bzlmod is going to
 replace the legacy WORKSPACE system in future Bazel releases. This guide helps
 you migrate your project to Bzlmod and drop WORKSPACE for fetching external
 dependencies.
@@ -116,9 +115,7 @@ Bazel module when it also adopts Bzlmod.
 
 *   **Bzlmod**
 
-    With Bzlmod, as long as the your dependency is available in [Bazel Central
-    Registry](https://registry.bazel.build) or your custom [Bazel
-    registry](/versions/7.7.1/external/registry), you can simply depend on it with a
+    With Bzlmod, as long as the your dependency is available in [Bazel Central Registry](https://registry.bazel.build) or your custom [Bazel registry](/versions/7.7.1/external/registry), you can simply depend on it with a
     [`bazel_dep`](/versions/7.7.1/rules/lib/globals/module#bazel_dep) directive.
 
     ```python
@@ -149,8 +146,7 @@ repository.
 
 If your dependency is not a Bazel project or not yet available in any Bazel
 registry, you can introduce it using
-[`use_repo_rule`](/versions/7.7.1/external/module#use_repo_rule) or [module
-extensions](/versions/7.7.1/external/extension).
+[`use_repo_rule`](/versions/7.7.1/external/module#use_repo_rule) or [module extensions](/versions/7.7.1/external/extension).
 
 *   **WORKSPACE**
 
@@ -583,8 +579,7 @@ macros.
 Fortunately, the flag
 [`--experimental_repository_resolved_file`][resolved_file_flag]
 can help. This flag essentially generates a "lock file" of all fetched external
-dependencies in your last Bazel command. You can find more details in this [blog
-post](https://blog.bazel.build/2018/07/09/bazel-sync-and-resolved-file.html).
+dependencies in your last Bazel command. You can find more details in this [blog post](https://blog.bazel.build/2018/07/09/bazel-sync-and-resolved-file.html).
 
 [resolved_file_flag]: /reference/command-line-reference#flag--experimental_repository_resolved_file
 
@@ -625,11 +620,9 @@ You may also know `bazel query` can be used for inspecting repository rules with
 bazel query --output=build //external:
 ```
 
-While it is more convenient and much faster, [bazel query can lie about
-external dependency version](https://github.com/bazelbuild/bazel/issues/12947),
+While it is more convenient and much faster, [bazel query can lie about external dependency version](https://github.com/bazelbuild/bazel/issues/12947),
 so be careful using it! Querying and inspecting external
-dependencies with Bzlmod is going to achieved by a [new
-subcommand](https://github.com/bazelbuild/bazel/issues/15365).
+dependencies with Bzlmod is going to achieved by a [new subcommand](https://github.com/bazelbuild/bazel/issues/15365).
 
 #### Built-in default dependencies {#builtin-default-deps}
 
@@ -676,8 +669,7 @@ your workspace root.
 #### Repository visibility {#repository-visibility}
 
 Bzlmod is able to control which other repositories are visible from a given
-repository, check [repository names and strict
-deps](/versions/7.7.1/external/module#repository_names_and_strict_deps) for more details.
+repository, check [repository names and strict deps](/versions/7.7.1/external/module#repository_names_and_strict_deps) for more details.
 
 Here is a summary of repository visibilities from different types of
 repositories when also taking WORKSPACE into consideration.
@@ -690,8 +682,7 @@ repositories when also taking WORKSPACE into consideration.
 | WORKSPACE Repos | All visible | Not visible | Not visible | All visible |
 
 Note: For the root module, if a repository `@foo` is defined in WORKSPACE and
-`@foo` is also used as an [apparent repository
-name](/versions/7.7.1/external/overview#apparent-repo-name) in MODULE.bazel, then `@foo`
+`@foo` is also used as an [apparent repository name](/versions/7.7.1/external/overview#apparent-repo-name) in MODULE.bazel, then `@foo`
 refers to the one introduced in MODULE.bazel.
 
 Note: For a module extension generated repository `@bar`, if `@foo` is used as
@@ -766,9 +757,7 @@ the project. Take note of a few things when creating the source archive:
     GitHub isn't going to guarantee the checksum of source archives generated on
     demand. In short, URLs in the form of
     `https://github.com///releases/download/...` is considered stable
-    while `https://github.com///archive/...` is not. Check [GitHub
-    Archive Checksum
-    Outage](https://blog.bazel.build/2023/02/15/github-archive-checksum.html)
+    while `https://github.com///archive/...` is not. Check [GitHub Archive Checksum Outage](https://blog.bazel.build/2023/02/15/github-archive-checksum.html)
     for more context.
 
 *   **Make sure the source tree follows the layout of the original repository.**
@@ -797,8 +786,7 @@ Pull Request.
 
 [bcr_contrib_guide]: https://github.com/bazelbuild/bazel-central-registry/tree/main/docs#contribute-a-bazel-module
 
-It is **highly recommended** to set up the [Publish to
-BCR](https://github.com/bazel-contrib/publish-to-bcr) GitHub App for your
+It is **highly recommended** to set up the [Publish to BCR](https://github.com/bazel-contrib/publish-to-bcr) GitHub App for your
 repository to automate the process of submitting your module to the BCR.
 
 ## Best practices {#best-practices}
diff --git a/versions/7.7.1/external/mod-command.mdx b/versions/7.7.1/external/mod-command.mdx
index 7a2a9cce..8d7e65dc 100644
--- a/versions/7.7.1/external/mod-command.mdx
+++ b/versions/7.7.1/external/mod-command.mdx
@@ -62,11 +62,9 @@ The available subcommands and their respective required arguments are:
 
 *   ``: All present versions of the module ``.
 
-*   `@`: The repo with the given [apparent
-    name](overview#apparent-repo-name) in the context of the `--base_module`.
+*   `@`: The repo with the given [apparent name](/versions/7.7.1/external/overview#apparent-repo-name) in the context of the `--base_module`.
 
-*   `@@`: The repo with the given [canonical
-    name](overview#canonical-repo-name).
+*   `@@`: The repo with the given [canonical name](/versions/7.7.1/external/overview#canonical-repo-name).
 
 In a context requiring specifying modules, ``s referring to repos that
 correspond to modules (as opposed to extension-generated repos) can also be
@@ -88,8 +86,7 @@ The following options only affect the subcommands that print graphs (`graph`,
     information about the version resolution of each module. If the module
     version changed during resolution, show either which version replaced it or
     what was the original version, the reason it was replaced, and which modules
-    requested the new version if the reason was [Minimal Version
-    Selection](module#version-selection).
+    requested the new version if the reason was [Minimal Version Selection](/versions/7.7.1/external/module#version-selection).
 
 *   `--include_unused` *default: "false"*: Include in the output graph the
     modules which were originally present in the dependency graph, but became
@@ -193,7 +190,7 @@ use_repo(toolchains, my_jdk="remotejdk17_linux")
   

     
       

-        Graph Before Resolution
+        Graph Before Resolution
         
Graph Before Resolution

       

 {/* digraph mygraph {
@@ -223,7 +220,7 @@ use_repo(toolchains, my_jdk="remotejdk17_linux")
     		
     
       

-        Graph After Resolution
+        Graph After Resolution
        
Graph After Resolution

       

 {/* digraph mygraph {
diff --git a/versions/7.7.1/external/module.mdx b/versions/7.7.1/external/module.mdx
index 8737fd70..62e7515d 100644
--- a/versions/7.7.1/external/module.mdx
+++ b/versions/7.7.1/external/module.mdx
@@ -122,8 +122,7 @@ serves multiple purposes:
     version, regardless of which versions of the dependency are requested in the
     dependency graph.
 *   With the `registry` attribute, you can force this dependency to come from a
-    specific registry, instead of following the normal [registry
-    selection](/versions/7.7.1/external/registry#selecting_registries) process.
+    specific registry, instead of following the normal [registry selection](/versions/7.7.1/external/registry#selecting_registries) process.
 *   With the `patch*` attributes, you can specify a set of patches to apply to
     the downloaded module.
 
@@ -176,13 +175,11 @@ With `bazel_dep`, you can define repos that represent other Bazel modules.
 Sometimes there is a need to define a repo that does _not_ represent a Bazel
 module; for example, one that contains a plain JSON file to be read as data.
 
-In this case, you could use the [`use_repo_rule`
-directive](/versions/7.7.1/rules/lib/globals/module#use_repo_rule) to directly define a repo
+In this case, you could use the [`use_repo_rule` directive](/versions/7.7.1/rules/lib/globals/module#use_repo_rule) to directly define a repo
 by invoking a repo rule. This repo will only be visible to the module it's
 defined in.
 
-Under the hood, this is implemented using the same mechanism as [module
-extensions](/versions/7.7.1/external/extension), which lets you define repos with more
+Under the hood, this is implemented using the same mechanism as [module extensions](/versions/7.7.1/external/extension), which lets you define repos with more
 flexibility.
 
 ## Repository names and strict deps
diff --git a/versions/7.7.1/external/overview.mdx b/versions/7.7.1/external/overview.mdx
index b04f978c..ee2ccc02 100644
--- a/versions/7.7.1/external/overview.mdx
+++ b/versions/7.7.1/external/overview.mdx
@@ -128,8 +128,7 @@ for all build targets inside the repo.
 
 The syntax of a `REPO.bazel` file is similar to `BUILD` files, except that no
 `load` statements are supported, and only a single function, `repo()`, is
-available. `repo()` takes the same arguments as the [`package()`
-function](/versions/7.7.1/reference/be/functions#package) in `BUILD` files; whereas `package()`
+available. `repo()` takes the same arguments as the [`package()` function](/versions/7.7.1/reference/be/functions#package) in `BUILD` files; whereas `package()`
 specifies common attributes for all build targets inside the package, `repo()`
 analogously does so for all build targets inside the repo.
 
@@ -163,8 +162,7 @@ bazel_dep(name = "protobuf", version = "3.19.0")
 ```
 
 A module must only list its direct dependencies, which Bzlmod looks up in a
-[Bazel registry](/versions/7.7.1/external/registry) — by default, the [Bazel Central
-Registry](https://bcr.bazel.build/). The registry provides the
+[Bazel registry](/versions/7.7.1/external/registry) — by default, the [Bazel Central Registry](https://bcr.bazel.build/). The registry provides the
 dependencies' `MODULE.bazel` files, which allows Bazel to discover the entire
 transitive dependency graph before performing version resolution.
 
@@ -235,5 +233,4 @@ many pain points, including:
         `B` and `C`; `B` and `C` both depend on different versions of `D`).
 
 Due to the shortcomings of WORKSPACE, Bzlmod is going to replace the legacy
-WORKSPACE system in future Bazel releases. Please read the [Bzlmod migration
-guide](/versions/7.7.1/external/migration) on how to migrate to Bzlmod.
\ No newline at end of file
+WORKSPACE system in future Bazel releases. Please read the [Bzlmod migration guide](/versions/7.7.1/external/migration) on how to migrate to Bzlmod.
\ No newline at end of file
diff --git a/versions/7.7.1/external/registry.mdx b/versions/7.7.1/external/registry.mdx
index 57b6ac6a..adc77646 100644
--- a/versions/7.7.1/external/registry.mdx
+++ b/versions/7.7.1/external/registry.mdx
@@ -42,8 +42,7 @@ An index registry must follow the format below:
             project
         *   `versions`: A list of all the versions of this module to be found in
             this registry
-        *   `yanked_versions`: A map of [*yanked*
-            versions](/versions/7.7.1/external/module#yanked_versions) of this module. The keys
+        *   `yanked_versions`: A map of [*yanked* versions](/versions/7.7.1/external/module#yanked_versions) of this module. The keys
             should be versions to yank and the values should be descriptions of
             why the version is yanked, ideally containing a link to more
             information
@@ -54,8 +53,7 @@ An index registry must follow the format below:
         *   The default type is "archive", representing an `http_archive` repo,
             with the following fields:
             *   `url`: The URL of the source archive
-            *   `integrity`: The [Subresource
-                Integrity](https://w3c.github.io/webappsec-subresource-integrity/#integrity-metadata-description)
+            *   `integrity`: The [Subresource Integrity](https://w3c.github.io/webappsec-subresource-integrity/#integrity-metadata-description)
                 checksum of the archive
             *   `strip_prefix`: A directory prefix to strip when extracting the
                 source archive
@@ -102,8 +100,7 @@ module, with the following fields:
 *   `versions`: An array of strings, each denoting a version of the module
     available in this registry. This array should match the children of the
     module directory.
-*   `yanked_versions`: A JSON object specifying the [*yanked*
-    versions](/versions/7.7.1/external/module#yanked_versions) of this module. The keys
+*   `yanked_versions`: A JSON object specifying the [*yanked* versions](/versions/7.7.1/external/module#yanked_versions) of this module. The keys
     should be versions to yank, and the values should be descriptions of
     why the version is yanked, ideally containing a link to more
     information.
@@ -171,8 +168,7 @@ You can browse its contents using the web frontend at
 https://registry.bazel.build/.
 
 The Bazel community maintains the BCR, and contributors are welcome to submit
-pull requests. See the [BCR contribution
-guidelines](https://github.com/bazelbuild/bazel-central-registry/blob/main/docs/README.md).
+pull requests. See the [BCR contribution guidelines](https://github.com/bazelbuild/bazel-central-registry/blob/main/docs/README.md).
 
 In addition to following the format of a normal index registry, the BCR requires
 a `presubmit.yml` file for each module version
diff --git a/versions/7.7.1/external/vendor.mdx b/versions/7.7.1/external/vendor.mdx
index 6efd16fe..89ed0877 100644
--- a/versions/7.7.1/external/vendor.mdx
+++ b/versions/7.7.1/external/vendor.mdx
@@ -23,9 +23,7 @@ absolute path.
 ## Vendor a specific external repository {#vendor-specific-repository}
 
 You can use the `vendor` command with the `--repo` flag to specify which repo
-to vendor, it accepts both [canonical repo
-name](/versions/7.7.1/external/overview#canonical-repo-name) and [apparent repo
-name](/versions/7.7.1/external/overview#apparent-repo-name).
+to vendor, it accepts both [canonical repo name](/versions/7.7.1/external/overview#canonical-repo-name) and [apparent repo name](/versions/7.7.1/external/overview#apparent-repo-name).
 
 For example, running:
 
diff --git a/versions/7.7.1/help.mdx b/versions/7.7.1/help.mdx
index 909c1074..47ae2300 100644
--- a/versions/7.7.1/help.mdx
+++ b/versions/7.7.1/help.mdx
@@ -45,5 +45,4 @@ what level of support Bazel provides.
 
 ## File a bug {#file-bug}
 
-If you encounter a bug or want to request a feature, file a [GitHub
-Issue](https://github.com/bazelbuild/bazel/issues).
+If you encounter a bug or want to request a feature, file a [GitHub Issue](https://github.com/bazelbuild/bazel/issues).
diff --git a/versions/7.7.1/images/about.svg b/versions/7.7.1/images/about.svg
new file mode 100644
index 00000000..f927298f
--- /dev/null
+++ b/versions/7.7.1/images/about.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/7.7.1/images/basics.svg b/versions/7.7.1/images/basics.svg
new file mode 100644
index 00000000..013ec519
--- /dev/null
+++ b/versions/7.7.1/images/basics.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/7.7.1/images/bazel_hero.svg b/versions/7.7.1/images/bazel_hero.svg
new file mode 100644
index 00000000..c48714d0
--- /dev/null
+++ b/versions/7.7.1/images/bazel_hero.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/7.7.1/images/community.svg b/versions/7.7.1/images/community.svg
new file mode 100644
index 00000000..29f87a76
--- /dev/null
+++ b/versions/7.7.1/images/community.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/7.7.1/images/distributed-build-remote-cache.png b/versions/7.7.1/images/distributed-build-remote-cache.png
new file mode 100644
index 00000000..99d8a915
Binary files /dev/null and b/versions/7.7.1/images/distributed-build-remote-cache.png differ
diff --git a/versions/7.7.1/images/essential_guide.svg b/versions/7.7.1/images/essential_guide.svg
new file mode 100644
index 00000000..4ee63ae9
--- /dev/null
+++ b/versions/7.7.1/images/essential_guide.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/7.7.1/images/essential_reference.svg b/versions/7.7.1/images/essential_reference.svg
new file mode 100644
index 00000000..4d29a8d5
--- /dev/null
+++ b/versions/7.7.1/images/essential_reference.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/7.7.1/images/essential_start.svg b/versions/7.7.1/images/essential_start.svg
new file mode 100644
index 00000000..c8f48f84
--- /dev/null
+++ b/versions/7.7.1/images/essential_start.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/7.7.1/images/extend.svg b/versions/7.7.1/images/extend.svg
new file mode 100644
index 00000000..77b2dd97
--- /dev/null
+++ b/versions/7.7.1/images/extend.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/7.7.1/images/guide.svg b/versions/7.7.1/images/guide.svg
new file mode 100644
index 00000000..23a5d35a
--- /dev/null
+++ b/versions/7.7.1/images/guide.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/7.7.1/images/high-level-build-system.png b/versions/7.7.1/images/high-level-build-system.png
new file mode 100644
index 00000000..462717fa
Binary files /dev/null and b/versions/7.7.1/images/high-level-build-system.png differ
diff --git a/versions/7.7.1/images/new_1.svg b/versions/7.7.1/images/new_1.svg
new file mode 100644
index 00000000..c4cd9dfd
--- /dev/null
+++ b/versions/7.7.1/images/new_1.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/7.7.1/images/new_2.svg b/versions/7.7.1/images/new_2.svg
new file mode 100644
index 00000000..c6b7021b
--- /dev/null
+++ b/versions/7.7.1/images/new_2.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/7.7.1/images/new_3.svg b/versions/7.7.1/images/new_3.svg
new file mode 100644
index 00000000..c2afb4ac
--- /dev/null
+++ b/versions/7.7.1/images/new_3.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/7.7.1/images/placeholder.png b/versions/7.7.1/images/placeholder.png
new file mode 100644
index 00000000..54f1fa0e
Binary files /dev/null and b/versions/7.7.1/images/placeholder.png differ
diff --git a/versions/7.7.1/images/reference.svg b/versions/7.7.1/images/reference.svg
new file mode 100644
index 00000000..7bbc9bea
--- /dev/null
+++ b/versions/7.7.1/images/reference.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/7.7.1/images/release_notes.svg b/versions/7.7.1/images/release_notes.svg
new file mode 100644
index 00000000..8a2e8b56
--- /dev/null
+++ b/versions/7.7.1/images/release_notes.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/7.7.1/images/remote-execution-system.png b/versions/7.7.1/images/remote-execution-system.png
new file mode 100644
index 00000000..8152fc0c
Binary files /dev/null and b/versions/7.7.1/images/remote-execution-system.png differ
diff --git a/versions/7.7.1/images/start.svg b/versions/7.7.1/images/start.svg
new file mode 100644
index 00000000..3bcebd7b
--- /dev/null
+++ b/versions/7.7.1/images/start.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/7.7.1/images/task-dependencies.png b/versions/7.7.1/images/task-dependencies.png
new file mode 100644
index 00000000..ae1f9c51
Binary files /dev/null and b/versions/7.7.1/images/task-dependencies.png differ
diff --git a/versions/7.7.1/images/test.png b/versions/7.7.1/images/test.png
new file mode 100644
index 00000000..243939da
Binary files /dev/null and b/versions/7.7.1/images/test.png differ
diff --git a/versions/7.7.1/images/transitive-dependencies.png b/versions/7.7.1/images/transitive-dependencies.png
new file mode 100644
index 00000000..ec641a08
Binary files /dev/null and b/versions/7.7.1/images/transitive-dependencies.png differ
diff --git a/versions/7.7.1/images/trunk-logo-dark.svg b/versions/7.7.1/images/trunk-logo-dark.svg
new file mode 100644
index 00000000..f25940af
--- /dev/null
+++ b/versions/7.7.1/images/trunk-logo-dark.svg
@@ -0,0 +1,22 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/versions/7.7.1/images/why_faq.svg b/versions/7.7.1/images/why_faq.svg
new file mode 100644
index 00000000..afec3f8f
--- /dev/null
+++ b/versions/7.7.1/images/why_faq.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/7.7.1/images/why_overview.svg b/versions/7.7.1/images/why_overview.svg
new file mode 100644
index 00000000..c10c363c
--- /dev/null
+++ b/versions/7.7.1/images/why_overview.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/7.7.1/images/why_vision.svg b/versions/7.7.1/images/why_vision.svg
new file mode 100644
index 00000000..739e415f
--- /dev/null
+++ b/versions/7.7.1/images/why_vision.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/7.7.1/install/bazelisk.mdx b/versions/7.7.1/install/bazelisk.mdx
index e9c3aaec..5ab2f98c 100644
--- a/versions/7.7.1/install/bazelisk.mdx
+++ b/versions/7.7.1/install/bazelisk.mdx
@@ -16,8 +16,7 @@ For more details, see
 ## Updating Bazel
 
 Bazel has a [backward compatibility policy](/versions/7.7.1/release/backward-compatibility)
-(see [guidance for rolling out incompatible
-changes](/versions/7.7.1/contribute/breaking-changes) if you
+(see [guidance for rolling out incompatible changes](/versions/7.7.1/contribute/breaking-changes) if you
 are the author of one). That page summarizes best practices on how to test and
 migrate your project with upcoming incompatible changes and how to provide
 feedback to the incompatible change authors.
diff --git a/versions/7.7.1/install/compile-source.mdx b/versions/7.7.1/install/compile-source.mdx
index 4dcb89fb..061badda 100644
--- a/versions/7.7.1/install/compile-source.mdx
+++ b/versions/7.7.1/install/compile-source.mdx
@@ -45,8 +45,7 @@ it by typing `bazel` in a terminal.
 
 **Reason**: To build Bazel from a GitHub source tree, you need a pre-existing
 Bazel binary. You can install one from a package manager or download one from
-GitHub. See [Installing Bazel](/versions/7.7.1/install). (Or you can [build from
-scratch (bootstrap)](#bootstrap-bazel).)
+GitHub. See [Installing Bazel](/versions/7.7.1/install). (Or you can [build from scratch (bootstrap)](#bootstrap-bazel).)
 
 **Troubleshooting**:
 
@@ -233,8 +232,7 @@ For instructions for Unix-like systems, see
     ```
 
 *   **The Visual C++ compiler.** Install the Visual C++ compiler either as part
-    of Visual Studio 2015 or newer, or by installing the latest [Build Tools
-    for Visual Studio 2017](https://aka.ms/BuildTools).
+    of Visual Studio 2015 or newer, or by installing the latest [Build Tools for Visual Studio 2017](https://aka.ms/BuildTools).
 
 *   **JDK.** Version 21 is required.
 
diff --git a/versions/7.7.1/install/ide.mdx b/versions/7.7.1/install/ide.mdx
index 561d0e02..c42d95e9 100644
--- a/versions/7.7.1/install/ide.mdx
+++ b/versions/7.7.1/install/ide.mdx
@@ -38,10 +38,8 @@ To install, go to the IDE's plugin browser and search for `Bazel`.
 To manually install older versions, download the zip files from JetBrains'
 Plugin Repository and install the zip file from the IDE's plugin browser:
 
-*  [Android Studio
-   plugin](https://plugins.jetbrains.com/plugin/9185-android-studio-with-bazel)
-*  [IntelliJ
-   plugin](https://plugins.jetbrains.com/plugin/8609-intellij-with-bazel)
+*  [Android Studio plugin](https://plugins.jetbrains.com/plugin/9185-android-studio-with-bazel)
+*  [IntelliJ plugin](https://plugins.jetbrains.com/plugin/8609-intellij-with-bazel)
 *  [CLion plugin](https://plugins.jetbrains.com/plugin/9554-clion-with-bazel)
 
 ### Xcode {#xcode}
@@ -61,8 +59,7 @@ Features:
 * Starlark debugger for `.bzl` files during a build (set breakpoints, step
   through code, inspect variables, and so on)
 
-Find [the plugin on the Visual Studio
-marketplace](https://marketplace.visualstudio.com/items?itemName=BazelBuild.vscode-bazel).
+Find [the plugin on the Visual Studio marketplace](https://marketplace.visualstudio.com/items?itemName=BazelBuild.vscode-bazel).
 The plugin is [open source](https://github.com/bazelbuild/vscode-bazel).
 
 See also: [Autocomplete for Source Code](#autocomplete-for-source-code)
@@ -82,8 +79,7 @@ See also: [Autocomplete for Source Code](#autocomplete-for-source-code)
 
 ### Emacs {#emacs}
 
-See [`bazelbuild/bazel-emacs-mode` on
-GitHub](https://github.com/bazelbuild/emacs-bazel-mode)
+See [`bazelbuild/bazel-emacs-mode` on GitHub](https://github.com/bazelbuild/emacs-bazel-mode)
 
 See also: [Autocomplete for Source Code](#autocomplete-for-source-code)
 
@@ -115,6 +111,5 @@ tool for building Bazel targets when source files change.
 
 ## Building your own IDE plugin {#build-own-plugin}
 
-Read the [**IDE support** blog
-post](https://blog.bazel.build/2016/06/10/ide-support.html) to learn more about
+Read the [**IDE support** blog post](https://blog.bazel.build/2016/06/10/ide-support.html) to learn more about
 the Bazel APIs to use when building an IDE plugin.
diff --git a/versions/7.7.1/install/images/bazelisk.svg b/versions/7.7.1/install/images/bazelisk.svg
new file mode 100644
index 00000000..c0ae9f54
--- /dev/null
+++ b/versions/7.7.1/install/images/bazelisk.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/7.7.1/install/images/cli.svg b/versions/7.7.1/install/images/cli.svg
new file mode 100644
index 00000000..01119280
--- /dev/null
+++ b/versions/7.7.1/install/images/cli.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/7.7.1/install/images/docker.svg b/versions/7.7.1/install/images/docker.svg
new file mode 100644
index 00000000..21190ce0
--- /dev/null
+++ b/versions/7.7.1/install/images/docker.svg
@@ -0,0 +1,6 @@
+
\ No newline at end of file
diff --git a/versions/7.7.1/install/images/github.svg b/versions/7.7.1/install/images/github.svg
new file mode 100644
index 00000000..aa05db9c
--- /dev/null
+++ b/versions/7.7.1/install/images/github.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/7.7.1/install/images/install.svg b/versions/7.7.1/install/images/install.svg
new file mode 100644
index 00000000..ae080865
--- /dev/null
+++ b/versions/7.7.1/install/images/install.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/7.7.1/install/images/mac.svg b/versions/7.7.1/install/images/mac.svg
new file mode 100644
index 00000000..3ee4fe28
--- /dev/null
+++ b/versions/7.7.1/install/images/mac.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/7.7.1/install/images/redhat.svg b/versions/7.7.1/install/images/redhat.svg
new file mode 100644
index 00000000..078b3387
--- /dev/null
+++ b/versions/7.7.1/install/images/redhat.svg
@@ -0,0 +1,69 @@
+
+
+  
+    
+      
+        image/svg+xml
+        
+        
+      
+    
+  
+  
+  
+    
+  
+  
+  
+
diff --git a/versions/7.7.1/install/images/suse.png b/versions/7.7.1/install/images/suse.png
new file mode 100644
index 00000000..6435b689
Binary files /dev/null and b/versions/7.7.1/install/images/suse.png differ
diff --git a/versions/7.7.1/install/images/tune.svg b/versions/7.7.1/install/images/tune.svg
new file mode 100644
index 00000000..8d7d63cb
--- /dev/null
+++ b/versions/7.7.1/install/images/tune.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/7.7.1/install/images/ubuntu.svg b/versions/7.7.1/install/images/ubuntu.svg
new file mode 100644
index 00000000..f217bc8d
--- /dev/null
+++ b/versions/7.7.1/install/images/ubuntu.svg
@@ -0,0 +1,8 @@
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/versions/7.7.1/install/images/windows.svg b/versions/7.7.1/install/images/windows.svg
new file mode 100644
index 00000000..120b0190
--- /dev/null
+++ b/versions/7.7.1/install/images/windows.svg
@@ -0,0 +1,5 @@
+
+
+
+
+
\ No newline at end of file
diff --git a/versions/7.7.1/install/windows.mdx b/versions/7.7.1/install/windows.mdx
index 65b93501..51143ce4 100644
--- a/versions/7.7.1/install/windows.mdx
+++ b/versions/7.7.1/install/windows.mdx
@@ -31,8 +31,7 @@ To check your Windows version:
 
 Alternatively you can:
 
-*   [Download the Bazel binary (`bazel-version-windows-x86_64.exe`) from
- GitHub](https://github.com/bazelbuild/bazel/releases).
+*   [Download the Bazel binary (`bazel-version-windows-x86_64.exe`) from GitHub](https://github.com/bazelbuild/bazel/releases).
 *   [Install Bazel from Chocolatey](#chocolately)
 *   [Install Bazel from Scoop](#scoop)
 *   [Build Bazel from source](/versions/7.7.1/install/compile-source)
@@ -208,8 +207,7 @@ If that doesn't help:
     its dependencies, such as the MSYS2 shell. This will not install Visual C++
     though.
 
-See [Chocolatey installation and package maintenance
-guide](/versions/7.7.1/contribute/windows-chocolatey-maintenance) for more
+See [Chocolatey installation and package maintenance guide](/versions/7.7.1/contribute/windows-chocolatey-maintenance) for more
 information about the Chocolatey package.
 
 ### Using Scoop {#scoop}
@@ -226,8 +224,7 @@ information about the Chocolatey package.
     scoop install bazel
     ```
 
-See [Scoop installation and package maintenance
-guide](/versions/7.7.1/contribute/windows-scoop-maintenance) for more
+See [Scoop installation and package maintenance guide](/versions/7.7.1/contribute/windows-scoop-maintenance) for more
 information about the Scoop package.
 
 ### Build from source {#build-from-source}
diff --git a/versions/7.7.1/query/cquery.mdx b/versions/7.7.1/query/cquery.mdx
index 58d4be98..28a72c23 100644
--- a/versions/7.7.1/query/cquery.mdx
+++ b/versions/7.7.1/query/cquery.mdx
@@ -6,8 +6,7 @@ title: ' Configurable Query (cquery)'
 [`select()`](/versions/7.7.1/docs/configurable-attributes) and build options' effects on the build
 graph.
 
-It achieves this by running over the results of Bazel's [analysis
-phase](/versions/7.7.1/extending/concepts#evaluation-model),
+It achieves this by running over the results of Bazel's [analysis phase](/versions/7.7.1/extending/concepts#evaluation-model),
 which integrates these effects. `query`, by contrast, runs over the results of
 Bazel's loading phase, before options are evaluated.
 
@@ -137,8 +136,7 @@ $ bazel cquery //foo --universe_scope=//foo,//genrule_with_foo_as_tool
 If you want to precisely declare which instance to query over, use
 the [`config`](#config) function.
 
-See `query`'s [target pattern
-documentation](/versions/7.7.1/query/language#target-patterns) for more information on target patterns.
+See `query`'s [target pattern documentation](/versions/7.7.1/query/language#target-patterns) for more information on target patterns.
 
 ## Functions {#functions}
 
diff --git a/versions/7.7.1/query/images/query_graph1.png b/versions/7.7.1/query/images/query_graph1.png
new file mode 100644
index 00000000..7bc9a61a
Binary files /dev/null and b/versions/7.7.1/query/images/query_graph1.png differ
diff --git a/versions/7.7.1/query/images/query_graph2.png b/versions/7.7.1/query/images/query_graph2.png
new file mode 100644
index 00000000..a0da22ff
Binary files /dev/null and b/versions/7.7.1/query/images/query_graph2.png differ
diff --git a/versions/7.7.1/query/images/query_graph3.png b/versions/7.7.1/query/images/query_graph3.png
new file mode 100644
index 00000000..4418f193
Binary files /dev/null and b/versions/7.7.1/query/images/query_graph3.png differ
diff --git a/versions/7.7.1/query/language.mdx b/versions/7.7.1/query/language.mdx
index 91c2be1f..979961fd 100644
--- a/versions/7.7.1/query/language.mdx
+++ b/versions/7.7.1/query/language.mdx
@@ -1100,8 +1100,7 @@ is being used.
 
 ### On the ordering of results {#results-ordering}
 
-Although query expressions always follow the "[law of
-conservation of graph order](#graph-order)", _presenting_ the results may be done
+Although query expressions always follow the "[law of conservation of graph order](#graph-order)", _presenting_ the results may be done
 in either a dependency-ordered or unordered manner. This does **not**
 influence the targets in the result set or how the query is computed. It only
 affects how the results are printed to stdout. Moreover, nodes that are
@@ -1246,8 +1245,7 @@ and `maxrank` output formats print the labels of each
 target in the resulting graph, but instead of appearing in
 topological order, they appear in rank order, preceded by their
 rank number. These are unaffected by the result ordering
-`--[no]order_results` flag (see [notes on
-the ordering of results](#result-order)).
+`--[no]order_results` flag (see [notes on the ordering of results](#result-order)).
 
 There are two variants of this format: `minrank` ranks
 each node by the length of the shortest path from a root node to it.
diff --git a/versions/7.7.1/query/quickstart.mdx b/versions/7.7.1/query/quickstart.mdx
index 4e60b5f5..1702b377 100644
--- a/versions/7.7.1/query/quickstart.mdx
+++ b/versions/7.7.1/query/quickstart.mdx
@@ -205,7 +205,7 @@ dot -Tpng < graph.in > graph.png
 ```
 If you open up `graph.png`, you should see something like this. The graph below has been simplified to make the essential path details clearer in this guide.
 
-![Diagram showing a relationship from cafe to chef to the dishes: pizza and mac and cheese which diverges into the separate ingredients: cheese, tomatoes, dough, and macaroni.](images/query_graph1.png "Dependency graph")
+![Diagram showing a relationship from cafe to chef to the dishes: pizza and mac and cheese which diverges into the separate ingredients: cheese, tomatoes, dough, and macaroni.](/versions/7.7.1/query/images/query_graph1.png "Dependency graph")
 
 This helps when you want to see the outputs of the different query functions throughout this guide.
 
@@ -421,7 +421,7 @@ bazel query --noimplicit_deps 'deps(:runner)' --output graph > graph2.in
 dot -Tpng < graph2.in > graph2.png
 ```
 
-[![The same graph as the first one except now there is a spoke stemming from the chef target with smoothie which leads to banana and strawberry](images/query_graph2.png "Updated dependency graph")](images/query_graph2.png)
+[![The same graph as the first one except now there is a spoke stemming from the chef target with smoothie which leads to banana and strawberry](/versions/7.7.1/query/images/query_graph2.png "Updated dependency graph")](/query/images/query_graph2.png)
 
 Looking at `graph2.png`, you can see that `Smoothie` has no shared dependencies with other dishes but is just another target that the `Chef` relies on.
 
@@ -465,7 +465,7 @@ bazel query "allpaths(//src/main/java/com/example/restaurant/..., //src/main/jav
 //src/main/java/com/example/restaurant:chef
 ```
 
-![Output path of cafe to chef to pizza,mac and cheese to cheese](images/query_graph3.png "Output path for dependency")
+![Output path of cafe to chef to pizza,mac and cheese to cheese](/versions/7.7.1/query/images/query_graph3.png "Output path for dependency")
 
 The output of `allpaths()` is a little harder to read as it is a flattened list of the dependencies. Visualizing this graph using Graphviz makes the relationship clearer to understand.
 
diff --git a/versions/7.7.1/reference/be/android.mdx b/versions/7.7.1/reference/be/android.mdx
index be748def..4a726e35 100644
--- a/versions/7.7.1/reference/be/android.mdx
+++ b/versions/7.7.1/reference/be/android.mdx
@@ -75,7 +75,7 @@ Bazel source tree.
 | `dex_shards` | Integer; default is `1` Number of shards dexing should be decomposed into. This is makes dexing much faster at the expense of app installation and startup time. The larger the binary, the more shards should be used. 25 is a good value to start experimenting with. Note that each shard will result in at least one dex in the final app. For this reason, setting this to more than 1 is not recommended for release binaries. |
 | `dexopts` | List of strings; default is `[]` Additional command-line flags for the dx tool when generating classes.dex. Subject to ["Make variable"](/versions/7.7.1/reference/be/make-variables) substitution and [Bourne shell tokenization](/versions/7.7.1/reference/be/common-definitions#sh-tokenization). |
 | `enable_data_binding` | Boolean; default is `False` If true, this rule processes [data binding](https://developer.android.com/topic/libraries/data-binding/index.html) expressions in layout resources included through the [resource\_files](/versions/7.7.1/reference/be/android#android_binary.resource_files) attribute. Without this setting, data binding expressions produce build failures. To build an Android app with data binding, you must also do the following:  1. Set this attribute for all Android rules that transitively depend on this one.    This is because dependers inherit the rule's data binding expressions through resource    merging. So they also need to build with data binding to parse those expressions.- Add a `deps =` entry for the data binding runtime library to all targets      that set this attribute. The location of this library depends on your depot setup. |
-| `incremental_dexing` | Integer; [nonconfigurable](common-definitions#configurable-attributes); default is `-1` Force the target to be built with or without incremental dexing, overriding defaults and --incremental\_dexing flag. |
+| `incremental_dexing` | Integer; [nonconfigurable](/versions/7.7.1/reference/be/common-definitions#configurable-attributes); default is `-1` Force the target to be built with or without incremental dexing, overriding defaults and --incremental\_dexing flag. |
 | `instruments` | [Label](/versions/7.7.1/concepts/labels); default is `None`  The `android_binary` target to instrument.  If this attribute is set, this `android_binary` will be treated as a test application for instrumentation tests. An `android_instrumentation_test` target can then specify this target in its [test\_app](/versions/7.7.1/reference/be/android#android_instrumentation_test.test_app) attribute. |
 | `javacopts` | List of strings; default is `[]` Extra compiler options for this target. Subject to ["Make variable"](/versions/7.7.1/reference/be/make-variables) substitution and [Bourne shell tokenization](/versions/7.7.1/reference/be/common-definitions#sh-tokenization). These compiler options are passed to javac after the global compiler options. |
 | `key_rotation_min_sdk` | String; default is `""` Sets the minimum Android platform version (API Level) for which an APK's rotated signing key should be used to produce the APK's signature. The original signing key for the APK will be used for all previous platform versions. |
@@ -90,7 +90,7 @@ Bazel source tree.
 | `plugins` | List of [labels](/versions/7.7.1/concepts/labels); default is `[]` Java compiler plugins to run at compile-time. Every `java_plugin` specified in the plugins attribute will be run whenever this target is built. Resources generated by the plugin will be included in the result jar of the target. |
 | `proguard_apply_dictionary` | [Label](/versions/7.7.1/concepts/labels); default is `None` File to be used as a mapping for proguard. A line separated file of "words" to pull from when renaming classes and members during obfuscation. |
 | `proguard_apply_mapping` | [Label](/versions/7.7.1/concepts/labels); default is `None` File to be used as a mapping for proguard. A mapping file generated by `proguard_generate_mapping` to be re-used to apply the same mapping to a new build. |
-| `proguard_generate_mapping` | Boolean; [nonconfigurable](common-definitions#configurable-attributes); default is `False` Whether to generate Proguard mapping file. The mapping file will be generated only if `proguard_specs` is specified. This file will list the mapping between the original and obfuscated class, method, and field names. *WARNING: If this attribute is used, the Proguard specification should contain neither `-dontobfuscate` nor `-printmapping`.* |
+| `proguard_generate_mapping` | Boolean; [nonconfigurable](/versions/7.7.1/reference/be/common-definitions#configurable-attributes); default is `False` Whether to generate Proguard mapping file. The mapping file will be generated only if `proguard_specs` is specified. This file will list the mapping between the original and obfuscated class, method, and field names. *WARNING: If this attribute is used, the Proguard specification should contain neither `-dontobfuscate` nor `-printmapping`.* |
 | `proguard_specs` | List of [labels](/versions/7.7.1/concepts/labels); default is `[]` Files to be used as Proguard specification. This file will describe the set of specifications to be used by Proguard. |
 | `resource_configuration_filters` | List of strings; default is `[]` A list of resource configuration filters, such 'en' that will limit the resources in the apk to only the ones in the 'en' configuration. To enable pseudolocalization, include the `en_XA` and/or `ar_XB` pseudo-locales. |
 | `resource_files` | List of [labels](/versions/7.7.1/concepts/labels); default is `[]` The list of resources to be packaged. This is typically a `glob` of all files under the `res` directory.   Generated files (from genrules) can be referenced by [Label](/versions/7.7.1/concepts/labels) here as well. The only restriction is that the generated outputs must be under the same "`res`" directory as any other resource files that are included. |
@@ -246,7 +246,7 @@ android_library(
 | `exported_plugins` | List of [labels](/versions/7.7.1/concepts/labels); default is `[]` The list of `java_plugin`s (e.g. annotation processors) to export to libraries that directly depend on this library. The specified list of `java_plugin`s will be applied to any library which directly depends on this library, just as if that library had explicitly declared these labels in `plugins`. |
 | `exports` | List of [labels](/versions/7.7.1/concepts/labels); default is `[]` The closure of all rules reached via `exports` attributes are considered direct dependencies of any rule that directly depends on the target with `exports`. The `exports` are not direct deps of the rule they belong to. |
 | `exports_manifest` | Integer; default is `1` Whether to export manifest entries to `android_binary` targets that depend on this target. `uses-permissions` attributes are never exported. |
-| `idl_import_root` | String; default is `""` Package-relative path to the root of the java package tree containing idl sources included in this library. This path will be used as the import root when processing idl sources that depend on this library.  When `idl_import_root` is specified, both `idl_parcelables` and `idl_srcs` must be at the path specified by the java package of the object they represent under `idl_import_root`. When `idl_import_root` is not specified, both `idl_parcelables` and `idl_srcs` must be at the path specified by their package under a Java root.  See [examples](android#android_library_examples.idl_import_root). |
+| `idl_import_root` | String; default is `""` Package-relative path to the root of the java package tree containing idl sources included in this library. This path will be used as the import root when processing idl sources that depend on this library.  When `idl_import_root` is specified, both `idl_parcelables` and `idl_srcs` must be at the path specified by the java package of the object they represent under `idl_import_root`. When `idl_import_root` is not specified, both `idl_parcelables` and `idl_srcs` must be at the path specified by their package under a Java root.  See [examples](/versions/7.7.1/reference/be/android#android_library_examples.idl_import_root). |
 | `idl_parcelables` | List of [labels](/versions/7.7.1/concepts/labels); default is `[]` List of Android IDL definitions to supply as imports. These files will be made available as imports for any `android_library` target that depends on this library, directly or via its transitive closure, but will not be translated to Java or compiled. Only `.aidl` files that correspond directly to `.java` sources in this library should be included (e.g., custom implementations of Parcelable), otherwise `idl_srcs` should be used.  These files must be placed appropriately for the aidl compiler to find them. See [the description of idl\_import\_root](/versions/7.7.1/reference/be/android#android_library.idl_import_root) for information about what this means. |
 | `idl_preprocessed` | List of [labels](/versions/7.7.1/concepts/labels); default is `[]` List of preprocessed Android IDL definitions to supply as imports. These files will be made available as imports for any `android_library` target that depends on this library, directly or via its transitive closure, but will not be translated to Java or compiled. Only preprocessed `.aidl` files that correspond directly to `.java` sources in this library should be included (e.g., custom implementations of Parcelable), otherwise use `idl_srcs` for Android IDL definitions that need to be translated to Java interfaces and use `idl_parcelable` for non-preprocessed AIDL files. |
 | `idl_srcs` | List of [labels](/versions/7.7.1/concepts/labels); default is `[]` List of Android IDL definitions to translate to Java interfaces. After the Java interfaces are generated, they will be compiled together with the contents of `srcs`. These files will be made available as imports for any `android_library` target that depends on this library, directly or via its transitive closure.  These files must be placed appropriately for the aidl compiler to find them. See [the description of idl\_import\_root](/versions/7.7.1/reference/be/android#android_library.idl_import_root) for information about what this means. |
@@ -355,8 +355,7 @@ writing Robolectric tests.
 #### Examples
 
 To use Robolectric with `android_local_test`, add
-[Robolectric's
-repository](https://github.com/robolectric/robolectric-bazel/tree/master/bazel) to your `WORKSPACE` file:
+[Robolectric's repository](https://github.com/robolectric/robolectric-bazel/tree/master/bazel) to your `WORKSPACE` file:
 
 ```
 http_archive(
@@ -406,8 +405,8 @@ android_library(
 | `custom_package` | String; default is `""` Java package in which the R class will be generated. By default the package is inferred from the directory where the BUILD file containing the rule is. If you use this attribute, you will likely need to use `test_class` as well. |
 | `densities` | List of strings; default is `[]` Densities to filter for when building the apk. A corresponding compatible-screens section will also be added to the manifest if it does not already contain a superset StarlarkListing. |
 | `enable_data_binding` | Boolean; default is `False` If true, this rule processes [data binding](https://developer.android.com/topic/libraries/data-binding/index.html) references used in data-binding enabled dependencies used by this test. Without this setting, data-binding dependencies won't have necessary binary-level code generation, and may produce build failures. |
-| `javacopts` | List of strings; default is `[]` Extra compiler options for this library. Subject to ["Make variable"](make-variables) substitution and [Bourne shell tokenization](common-definitions#sh-tokenization). These compiler options are passed to javac after the global compiler options. |
-| `jvm_flags` | List of strings; default is `[]` A list of flags to embed in the wrapper script generated for running this binary. Subject to [$(location)](/versions/7.7.1/reference/be/make-variables#location) and ["Make variable"](make-variables) substitution, and [Bourne shell tokenization](common-definitions#sh-tokenization). The wrapper script for a Java binary includes a CLASSPATH definition (to find all the dependent jars) and invokes the right Java interpreter. The command line generated by the wrapper script includes the name of the main class followed by a `"$@"` so you can pass along other arguments after the classname. However, arguments intended for parsing by the JVM must be specified *before* the classname on the command line. The contents of `jvm_flags` are added to the wrapper script before the classname is listed.  Note that this attribute has *no effect* on `*_deploy.jar` outputs. |
+| `javacopts` | List of strings; default is `[]` Extra compiler options for this library. Subject to ["Make variable"](/versions/7.7.1/reference/be/make-variables) substitution and [Bourne shell tokenization](/versions/7.7.1/reference/be/common-definitions#sh-tokenization). These compiler options are passed to javac after the global compiler options. |
+| `jvm_flags` | List of strings; default is `[]` A list of flags to embed in the wrapper script generated for running this binary. Subject to [$(location)](/versions/7.7.1/reference/be/make-variables#location) and ["Make variable"](/versions/7.7.1/reference/be/make-variables) substitution, and [Bourne shell tokenization](/versions/7.7.1/reference/be/common-definitions#sh-tokenization). The wrapper script for a Java binary includes a CLASSPATH definition (to find all the dependent jars) and invokes the right Java interpreter. The command line generated by the wrapper script includes the name of the main class followed by a `"$@"` so you can pass along other arguments after the classname. However, arguments intended for parsing by the JVM must be specified *before* the classname on the command line. The contents of `jvm_flags` are added to the wrapper script before the classname is listed.  Note that this attribute has *no effect* on `*_deploy.jar` outputs. |
 | `manifest` | [Label](/versions/7.7.1/concepts/labels); default is `None` The name of the Android manifest file, normally `AndroidManifest.xml`. Must be defined if resource\_files or assets are defined or if any of the manifests from the libraries under test have a `minSdkVersion` tag in them. |
 | `manifest_values` | Dictionary: String -> String; default is `{}` A dictionary of values to be overridden in the manifest. Any instance of ${name} in the manifest will be replaced with the value corresponding to name in this dictionary. `applicationId`, `versionCode`, `versionName`, `minSdkVersion`, `targetSdkVersion` and `maxSdkVersion` will also override the corresponding attributes of the manifest and uses-sdk tags. `packageName` will be ignored and will be set from either `applicationId` if specified or the package in the manifest. It is not necessary to have a manifest on the rule in order to use manifest\_values. |
 | `nocompress_extensions` | List of strings; default is `[]` A list of file extensions to leave uncompressed in the resource apk. |
@@ -585,8 +584,8 @@ cc_library(
 | Attributes | |
 | --- | --- |
 | `name` | [Name](/versions/7.7.1/concepts/labels#target-names); required  A unique name for this target. |
-| `api_level` | Integer; [nonconfigurable](common-definitions#configurable-attributes); default is `0` The Android API level to build against. If not specified, the highest API level installed will be used. |
-| `path` | String; [nonconfigurable](common-definitions#configurable-attributes); default is `""` An absolute or relative path to an Android NDK. Either this attribute or the `$ANDROID_NDK_HOME` environment variable must be set. The Android NDK can be downloaded from [the Android developer site](https://developer.android.com/ndk/downloads/index.html). |
+| `api_level` | Integer; [nonconfigurable](/versions/7.7.1/reference/be/common-definitions#configurable-attributes); default is `0` The Android API level to build against. If not specified, the highest API level installed will be used. |
+| `path` | String; [nonconfigurable](/versions/7.7.1/reference/be/common-definitions#configurable-attributes); default is `""` An absolute or relative path to an Android NDK. Either this attribute or the `$ANDROID_NDK_HOME` environment variable must be set. The Android NDK can be downloaded from [the Android developer site](https://developer.android.com/ndk/downloads/index.html). |
 | `repo_mapping` | Dictionary: String -> String; default is `{}` A dictionary from local repository name to global repository name. This allows controls over workspace dependency resolution for dependencies of this repository. For example, an entry `"@foo": "@bar"` declares that, for any time this repository depends on `"@foo"` (such as a dependency on `"@foo//some:target"`), it should actually resolve that dependency within globally-declared `"@bar"` (`"@bar//some:target"`). |
 
 ## android\_sdk\_repository
@@ -657,7 +656,7 @@ android_library(
 | Attributes | |
 | --- | --- |
 | `name` | [Name](/versions/7.7.1/concepts/labels#target-names); required  A unique name for this target. |
-| `api_level` | Integer; [nonconfigurable](common-definitions#configurable-attributes); default is `0` The Android API level to build against by default. If not specified, the highest API level installed will be used. The API level used for a given build can be overridden by the `android_sdk` flag. `android_sdk_repository` creates an `android_sdk` target for each API level installed in the SDK with name `@androidsdk//:sdk-${level}`, whether or not this attribute is specified. For example, to build against a non-default API level: `bazel build --android_sdk=@androidsdk//:sdk-19 //java/com/example:app`. To view all `android_sdk` targets generated by `android_sdk_repository`, you can run `bazel query "kind(android_sdk, @androidsdk//...)"`. |
-| `build_tools_version` | String; [nonconfigurable](common-definitions#configurable-attributes); default is `""` The version of the Android build tools to use from within the Android SDK. If not specified, the latest build tools version installed will be used. Bazel requires build tools version 30.0.0 or later. |
-| `path` | String; [nonconfigurable](common-definitions#configurable-attributes); default is `""` An absolute or relative path to an Android SDK. Either this attribute or the `$ANDROID_HOME` environment variable must be set. The Android SDK can be downloaded from [the Android developer site](https://developer.android.com). |
+| `api_level` | Integer; [nonconfigurable](/versions/7.7.1/reference/be/common-definitions#configurable-attributes); default is `0` The Android API level to build against by default. If not specified, the highest API level installed will be used. The API level used for a given build can be overridden by the `android_sdk` flag. `android_sdk_repository` creates an `android_sdk` target for each API level installed in the SDK with name `@androidsdk//:sdk-${level}`, whether or not this attribute is specified. For example, to build against a non-default API level: `bazel build --android_sdk=@androidsdk//:sdk-19 //java/com/example:app`. To view all `android_sdk` targets generated by `android_sdk_repository`, you can run `bazel query "kind(android_sdk, @androidsdk//...)"`. |
+| `build_tools_version` | String; [nonconfigurable](/versions/7.7.1/reference/be/common-definitions#configurable-attributes); default is `""` The version of the Android build tools to use from within the Android SDK. If not specified, the latest build tools version installed will be used. Bazel requires build tools version 30.0.0 or later. |
+| `path` | String; [nonconfigurable](/versions/7.7.1/reference/be/common-definitions#configurable-attributes); default is `""` An absolute or relative path to an Android SDK. Either this attribute or the `$ANDROID_HOME` environment variable must be set. The Android SDK can be downloaded from [the Android developer site](https://developer.android.com). |
 | `repo_mapping` | Dictionary: String -> String; default is `{}` A dictionary from local repository name to global repository name. This allows controls over workspace dependency resolution for dependencies of this repository. For example, an entry `"@foo": "@bar"` declares that, for any time this repository depends on `"@foo"` (such as a dependency on `"@foo//some:target"`), it should actually resolve that dependency within globally-declared `"@bar"` (`"@bar//some:target"`). |
\ No newline at end of file
diff --git a/versions/7.7.1/reference/be/c-cpp.mdx b/versions/7.7.1/reference/be/c-cpp.mdx
index 38f32a20..948a6a79 100644
--- a/versions/7.7.1/reference/be/c-cpp.mdx
+++ b/versions/7.7.1/reference/be/c-cpp.mdx
@@ -49,8 +49,8 @@ cc_binary(name, deps, srcs, data, additional_linker_inputs, args, compatible_wit
 | `defines` | List of strings; default is `[]` List of defines to add to the compile line. Subject to ["Make" variable](/versions/7.7.1/reference/be/make-variables) substitution and [Bourne shell tokenization](/versions/7.7.1/reference/be/common-definitions#sh-tokenization). Each string, which must consist of a single Bourne shell token, is prepended with `-D` and added to the compile command line to this target, as well as to every rule that depends on it. Be very careful, since this may have far-reaching effects. When in doubt, add define values to [`local_defines`](#cc_binary.local_defines) instead. |
 | `includes` | List of strings; default is `[]` List of include dirs to be added to the compile line. Subject to ["Make variable"](/versions/7.7.1/reference/be/make-variables) substitution. Each string is prepended with `-isystem` and added to `COPTS`. Unlike [COPTS](#cc_binary.copts), these flags are added for this rule and every rule that depends on it. (Note: not the rules it depends upon!) Be very careful, since this may have far-reaching effects. When in doubt, add "-I" flags to [COPTS](#cc_binary.copts) instead.  Headers must be added to srcs or hdrs, otherwise they will not be available to dependent rules when compilation is sandboxed (the default). |
 | `link_extra_lib` | [Label](/versions/7.7.1/concepts/labels); default is `"@bazel_tools//tools/cpp:link_extra_lib"` Control linking of extra libraries. By default, C++ binaries are linked against `//tools/cpp:link_extra_lib`, which by default depends on the label flag `//tools/cpp:link_extra_libs`. Without setting the flag, this library is empty by default. Setting the label flag allows linking optional dependencies, such as overrides for weak symbols, interceptors for shared library functions, or special runtime libraries (for malloc replacements, prefer `malloc` or `--custom_malloc`). Setting this attribute to `None` disables this behaviour. |
-| `linkopts` | List of strings; default is `[]` Add these flags to the C++ linker command. Subject to ["Make" variable](make-variables) substitution, [Bourne shell tokenization](common-definitions#sh-tokenization) and [label expansion](common-definitions#label-expansion). Each string in this attribute is added to `LINKOPTS` before linking the binary target. Each element of this list that does not start with `$` or `-` is assumed to be the label of a target in `deps`. The list of files generated by that target is appended to the linker options. An error is reported if the label is invalid, or is not declared in `deps`. |
-| `linkshared` | Boolean; [nonconfigurable](common-definitions#configurable-attributes); default is `False` Create a shared library. To enable this attribute, include `linkshared=True` in your rule. By default this option is off. The presence of this flag means that linking occurs with the `-shared` flag to `gcc`, and the resulting shared library is suitable for loading into for example a Java program. However, for build purposes it will never be linked into the dependent binary, as it is assumed that shared libraries built with a [cc\_binary](#cc_binary) rule are only loaded manually by other programs, so it should not be considered a substitute for the [cc\_library](#cc_library) rule. For sake of scalability we recommend avoiding this approach altogether and simply letting `java_library` depend on `cc_library` rules instead.  If you specify both `linkopts=['-static']` and `linkshared=True`, you get a single completely self-contained unit. If you specify both `linkstatic=True` and `linkshared=True`, you get a single, mostly self-contained unit. |
+| `linkopts` | List of strings; default is `[]` Add these flags to the C++ linker command. Subject to ["Make" variable](/versions/7.7.1/reference/be/make-variables) substitution, [Bourne shell tokenization](/versions/7.7.1/reference/be/common-definitions#sh-tokenization) and [label expansion](/versions/7.7.1/reference/be/common-definitions#label-expansion). Each string in this attribute is added to `LINKOPTS` before linking the binary target. Each element of this list that does not start with `$` or `-` is assumed to be the label of a target in `deps`. The list of files generated by that target is appended to the linker options. An error is reported if the label is invalid, or is not declared in `deps`. |
+| `linkshared` | Boolean; [nonconfigurable](/versions/7.7.1/reference/be/common-definitions#configurable-attributes); default is `False` Create a shared library. To enable this attribute, include `linkshared=True` in your rule. By default this option is off. The presence of this flag means that linking occurs with the `-shared` flag to `gcc`, and the resulting shared library is suitable for loading into for example a Java program. However, for build purposes it will never be linked into the dependent binary, as it is assumed that shared libraries built with a [cc\_binary](#cc_binary) rule are only loaded manually by other programs, so it should not be considered a substitute for the [cc\_library](#cc_library) rule. For sake of scalability we recommend avoiding this approach altogether and simply letting `java_library` depend on `cc_library` rules instead.  If you specify both `linkopts=['-static']` and `linkshared=True`, you get a single completely self-contained unit. If you specify both `linkstatic=True` and `linkshared=True`, you get a single, mostly self-contained unit. |
 | `linkstatic` | Boolean; default is `True` For [`cc_binary`](/versions/7.7.1/reference/be/c-cpp#cc_binary) and [`cc_test`](/versions/7.7.1/reference/be/c-cpp#cc_test): link the binary in static mode. For `cc_library.linkstatic`: see below. By default this option is on for `cc_binary` and off for the rest.  If enabled and this is a binary or test, this option tells the build tool to link in `.a`'s instead of `.so`'s for user libraries whenever possible. Some system libraries may still be linked dynamically, as are libraries for which there is no static library. So the resulting executable will still be dynamically linked, hence only *mostly* static.  There are really three different ways to link an executable:   * STATIC with fully\_static\_link feature, in which everything is linked statically;   e.g. "`gcc -static foo.o libbar.a libbaz.a -lm`".    This mode is enabled by specifying `fully_static_link` in the   [`features`](/versions/7.7.1/reference/be/common-definitions#features) attribute. * STATIC, in which all user libraries are linked statically (if a static   version is available), but where system libraries (excluding C/C++ runtime libraries)   are linked dynamically, e.g. "`gcc foo.o libfoo.a libbaz.a -lm`".    This mode is enabled by specifying `linkstatic=True`. * DYNAMIC, in which all libraries are linked dynamically (if a dynamic version is   available), e.g. "`gcc foo.o libfoo.so libbaz.so -lm`".    This mode is enabled by specifying `linkstatic=False`.   The `linkstatic` attribute has a different meaning if used on a [`cc_library()`](/versions/7.7.1/reference/be/c-cpp#cc_library) rule. For a C++ library, `linkstatic=True` indicates that only static linking is allowed, so no `.so` will be produced. linkstatic=False does not prevent static libraries from being created. The attribute is meant to control the creation of dynamic libraries.  If `linkstatic=False`, then the build tool will create symlinks to depended-upon shared libraries in the `*.runfiles` area. |
 | `local_defines` | List of strings; default is `[]` List of defines to add to the compile line. Subject to ["Make" variable](/versions/7.7.1/reference/be/make-variables) substitution and [Bourne shell tokenization](/versions/7.7.1/reference/be/common-definitions#sh-tokenization). Each string, which must consist of a single Bourne shell token, is prepended with `-D` and added to the compile command line for this target, but not to its dependents. |
 | `malloc` | [Label](/versions/7.7.1/concepts/labels); default is `"@bazel_tools//tools/cpp:malloc"` Override the default dependency on malloc. By default, C++ binaries are linked against `//tools/cpp:malloc`, which is an empty library so the binary ends up using libc malloc. This label must refer to a `cc_library`. If compilation is for a non-C++ rule, this option has no effect. The value of this attribute is ignored if `linkshared=True` is specified. |
@@ -310,7 +310,7 @@ provided by Bazel only support this feature with clang on Unix and macOS.
 | `implementation_deps` | List of [labels](/versions/7.7.1/concepts/labels); default is `[]` The list of other libraries that the library target depends on. Unlike with `deps`, the headers and include paths of these libraries (and all their transitive deps) are only used for compilation of this library, and not libraries that depend on it. Libraries specified with `implementation_deps` are still linked in binary targets that depend on this library. For now usage is limited to cc\_libraries and guarded by the flag `--experimental_cc_implementation_deps`. |
 | `include_prefix` | String; default is `""` The prefix to add to the paths of the headers of this rule. When set, the headers in the `hdrs` attribute of this rule are accessible at is the value of this attribute prepended to their repository-relative path. The prefix in the `strip_include_prefix` attribute is removed before this prefix is added. |
 | `includes` | List of strings; default is `[]` List of include dirs to be added to the compile line. Subject to ["Make variable"](/versions/7.7.1/reference/be/make-variables) substitution. Each string is prepended with `-isystem` and added to `COPTS`. Unlike [COPTS](#cc_binary.copts), these flags are added for this rule and every rule that depends on it. (Note: not the rules it depends upon!) Be very careful, since this may have far-reaching effects. When in doubt, add "-I" flags to [COPTS](#cc_binary.copts) instead.  Headers must be added to srcs or hdrs, otherwise they will not be available to dependent rules when compilation is sandboxed (the default). |
-| `linkopts` | List of strings; default is `[]` Add these flags to the C++ linker command. Subject to ["Make" variable](make-variables) substitution, [Bourne shell tokenization](common-definitions#sh-tokenization) and [label expansion](common-definitions#label-expansion). Each string in this attribute is added to `LINKOPTS` before linking the binary target. Each element of this list that does not start with `$` or `-` is assumed to be the label of a target in `deps`. The list of files generated by that target is appended to the linker options. An error is reported if the label is invalid, or is not declared in `deps`. |
+| `linkopts` | List of strings; default is `[]` Add these flags to the C++ linker command. Subject to ["Make" variable](/versions/7.7.1/reference/be/make-variables) substitution, [Bourne shell tokenization](/versions/7.7.1/reference/be/common-definitions#sh-tokenization) and [label expansion](/versions/7.7.1/reference/be/common-definitions#label-expansion). Each string in this attribute is added to `LINKOPTS` before linking the binary target. Each element of this list that does not start with `$` or `-` is assumed to be the label of a target in `deps`. The list of files generated by that target is appended to the linker options. An error is reported if the label is invalid, or is not declared in `deps`. |
 | `linkstamp` | [Label](/versions/7.7.1/concepts/labels); default is `None` Simultaneously compiles and links the specified C++ source file into the final binary. This trickery is required to introduce timestamp information into binaries; if we compiled the source file to an object file in the usual way, the timestamp would be incorrect. A linkstamp compilation may not include any particular set of compiler flags and so should not depend on any particular header, compiler option, or other build variable. *This option should only be needed in the `base` package.* |
 | `linkstatic` | Boolean; default is `False` For [`cc_binary`](/versions/7.7.1/reference/be/c-cpp#cc_binary) and [`cc_test`](/versions/7.7.1/reference/be/c-cpp#cc_test): link the binary in static mode. For `cc_library.linkstatic`: see below. By default this option is on for `cc_binary` and off for the rest.  If enabled and this is a binary or test, this option tells the build tool to link in `.a`'s instead of `.so`'s for user libraries whenever possible. Some system libraries may still be linked dynamically, as are libraries for which there is no static library. So the resulting executable will still be dynamically linked, hence only *mostly* static.  There are really three different ways to link an executable:   * STATIC with fully\_static\_link feature, in which everything is linked statically;   e.g. "`gcc -static foo.o libbar.a libbaz.a -lm`".    This mode is enabled by specifying `fully_static_link` in the   [`features`](/versions/7.7.1/reference/be/common-definitions#features) attribute. * STATIC, in which all user libraries are linked statically (if a static   version is available), but where system libraries (excluding C/C++ runtime libraries)   are linked dynamically, e.g. "`gcc foo.o libfoo.a libbaz.a -lm`".    This mode is enabled by specifying `linkstatic=True`. * DYNAMIC, in which all libraries are linked dynamically (if a dynamic version is   available), e.g. "`gcc foo.o libfoo.so libbaz.so -lm`".    This mode is enabled by specifying `linkstatic=False`.   The `linkstatic` attribute has a different meaning if used on a [`cc_library()`](/versions/7.7.1/reference/be/c-cpp#cc_library) rule. For a C++ library, `linkstatic=True` indicates that only static linking is allowed, so no `.so` will be produced. linkstatic=False does not prevent static libraries from being created. The attribute is meant to control the creation of dynamic libraries.  If `linkstatic=False`, then the build tool will create symlinks to depended-upon shared libraries in the `*.runfiles` area. |
 | `local_defines` | List of strings; default is `[]` List of defines to add to the compile line. Subject to ["Make" variable](/versions/7.7.1/reference/be/make-variables) substitution and [Bourne shell tokenization](/versions/7.7.1/reference/be/common-definitions#sh-tokenization). Each string, which must consist of a single Bourne shell token, is prepended with `-D` and added to the compile command line for this target, but not to its dependents. |
@@ -329,7 +329,7 @@ cc_proto_library(name, deps, data, compatible_with, deprecation, distribs, exec_
 
 `cc_proto_library` generates C++ code from `.proto` files.
 
-`deps` must point to [`proto_library`](protocol-buffer#proto_library) rules.
+`deps` must point to [`proto_library`](/versions/7.7.1/reference/be/protocol-buffer#proto_library) rules.
 
 Example:
 
@@ -354,7 +354,7 @@ proto_library(
 | Attributes | |
 | --- | --- |
 | `name` | [Name](/versions/7.7.1/concepts/labels#target-names); required  A unique name for this target. |
-| `deps` | List of [labels](/versions/7.7.1/concepts/labels); default is `[]` The list of [`proto_library`](protocol-buffer#proto_library) rules to generate C++ code for. |
+| `deps` | List of [labels](/versions/7.7.1/concepts/labels); default is `[]` The list of [`proto_library`](/versions/7.7.1/reference/be/protocol-buffer#proto_library) rules to generate C++ code for. |
 
 ## cc\_shared\_library
 
@@ -704,7 +704,7 @@ cc_test(name, deps, srcs, data, additional_linker_inputs, args, compatible_with,
 | `defines` | List of strings; default is `[]` List of defines to add to the compile line. Subject to ["Make" variable](/versions/7.7.1/reference/be/make-variables) substitution and [Bourne shell tokenization](/versions/7.7.1/reference/be/common-definitions#sh-tokenization). Each string, which must consist of a single Bourne shell token, is prepended with `-D` and added to the compile command line to this target, as well as to every rule that depends on it. Be very careful, since this may have far-reaching effects. When in doubt, add define values to [`local_defines`](#cc_binary.local_defines) instead. |
 | `includes` | List of strings; default is `[]` List of include dirs to be added to the compile line. Subject to ["Make variable"](/versions/7.7.1/reference/be/make-variables) substitution. Each string is prepended with `-isystem` and added to `COPTS`. Unlike [COPTS](#cc_binary.copts), these flags are added for this rule and every rule that depends on it. (Note: not the rules it depends upon!) Be very careful, since this may have far-reaching effects. When in doubt, add "-I" flags to [COPTS](#cc_binary.copts) instead.  Headers must be added to srcs or hdrs, otherwise they will not be available to dependent rules when compilation is sandboxed (the default). |
 | `link_extra_lib` | [Label](/versions/7.7.1/concepts/labels); default is `"@bazel_tools//tools/cpp:link_extra_lib"` Control linking of extra libraries. By default, C++ binaries are linked against `//tools/cpp:link_extra_lib`, which by default depends on the label flag `//tools/cpp:link_extra_libs`. Without setting the flag, this library is empty by default. Setting the label flag allows linking optional dependencies, such as overrides for weak symbols, interceptors for shared library functions, or special runtime libraries (for malloc replacements, prefer `malloc` or `--custom_malloc`). Setting this attribute to `None` disables this behaviour. |
-| `linkopts` | List of strings; default is `[]` Add these flags to the C++ linker command. Subject to ["Make" variable](make-variables) substitution, [Bourne shell tokenization](common-definitions#sh-tokenization) and [label expansion](common-definitions#label-expansion). Each string in this attribute is added to `LINKOPTS` before linking the binary target. Each element of this list that does not start with `$` or `-` is assumed to be the label of a target in `deps`. The list of files generated by that target is appended to the linker options. An error is reported if the label is invalid, or is not declared in `deps`. |
+| `linkopts` | List of strings; default is `[]` Add these flags to the C++ linker command. Subject to ["Make" variable](/versions/7.7.1/reference/be/make-variables) substitution, [Bourne shell tokenization](/versions/7.7.1/reference/be/common-definitions#sh-tokenization) and [label expansion](/versions/7.7.1/reference/be/common-definitions#label-expansion). Each string in this attribute is added to `LINKOPTS` before linking the binary target. Each element of this list that does not start with `$` or `-` is assumed to be the label of a target in `deps`. The list of files generated by that target is appended to the linker options. An error is reported if the label is invalid, or is not declared in `deps`. |
 | `linkstatic` | Boolean; default is `False` For [`cc_binary`](/versions/7.7.1/reference/be/c-cpp#cc_binary) and [`cc_test`](/versions/7.7.1/reference/be/c-cpp#cc_test): link the binary in static mode. For `cc_library.linkstatic`: see below. By default this option is on for `cc_binary` and off for the rest.  If enabled and this is a binary or test, this option tells the build tool to link in `.a`'s instead of `.so`'s for user libraries whenever possible. Some system libraries may still be linked dynamically, as are libraries for which there is no static library. So the resulting executable will still be dynamically linked, hence only *mostly* static.  There are really three different ways to link an executable:   * STATIC with fully\_static\_link feature, in which everything is linked statically;   e.g. "`gcc -static foo.o libbar.a libbaz.a -lm`".    This mode is enabled by specifying `fully_static_link` in the   [`features`](/versions/7.7.1/reference/be/common-definitions#features) attribute. * STATIC, in which all user libraries are linked statically (if a static   version is available), but where system libraries (excluding C/C++ runtime libraries)   are linked dynamically, e.g. "`gcc foo.o libfoo.a libbaz.a -lm`".    This mode is enabled by specifying `linkstatic=True`. * DYNAMIC, in which all libraries are linked dynamically (if a dynamic version is   available), e.g. "`gcc foo.o libfoo.so libbaz.so -lm`".    This mode is enabled by specifying `linkstatic=False`.   The `linkstatic` attribute has a different meaning if used on a [`cc_library()`](/versions/7.7.1/reference/be/c-cpp#cc_library) rule. For a C++ library, `linkstatic=True` indicates that only static linking is allowed, so no `.so` will be produced. linkstatic=False does not prevent static libraries from being created. The attribute is meant to control the creation of dynamic libraries.  If `linkstatic=False`, then the build tool will create symlinks to depended-upon shared libraries in the `*.runfiles` area. |
 | `local_defines` | List of strings; default is `[]` List of defines to add to the compile line. Subject to ["Make" variable](/versions/7.7.1/reference/be/make-variables) substitution and [Bourne shell tokenization](/versions/7.7.1/reference/be/common-definitions#sh-tokenization). Each string, which must consist of a single Bourne shell token, is prepended with `-D` and added to the compile command line for this target, but not to its dependents. |
 | `malloc` | [Label](/versions/7.7.1/concepts/labels); default is `"@bazel_tools//tools/cpp:malloc"` Override the default dependency on malloc. By default, C++ binaries are linked against `//tools/cpp:malloc`, which is an empty library so the binary ends up using libc malloc. This label must refer to a `cc_library`. If compilation is for a non-C++ rule, this option has no effect. The value of this attribute is ignored if `linkshared=True` is specified. |
@@ -761,7 +761,7 @@ unnecessarily when invoking `bazel build //...`
 | `supports_header_parsing` | Boolean; default is `False` Set to True when cc\_toolchain supports header parsing actions. |
 | `supports_param_files` | Boolean; default is `True` Set to True when cc\_toolchain supports using param files for linking actions. |
 | `toolchain_config` | [Label](/versions/7.7.1/concepts/labels); required The label of the rule providing `cc_toolchain_config_info`. |
-| `toolchain_identifier` | String; [nonconfigurable](common-definitions#configurable-attributes); default is `""` The identifier used to match this cc\_toolchain with the corresponding crosstool\_config.toolchain. Until issue [#5380](https://github.com/bazelbuild/bazel/issues/5380) is fixed this is the recommended way of associating `cc_toolchain` with `CROSSTOOL.toolchain`. It will be replaced by the `toolchain_config` attribute ([#5380](https://github.com/bazelbuild/bazel/issues/5380)). |
+| `toolchain_identifier` | String; [nonconfigurable](/versions/7.7.1/reference/be/common-definitions#configurable-attributes); default is `""` The identifier used to match this cc\_toolchain with the corresponding crosstool\_config.toolchain. Until issue [#5380](https://github.com/bazelbuild/bazel/issues/5380) is fixed this is the recommended way of associating `cc_toolchain` with `CROSSTOOL.toolchain`. It will be replaced by the `toolchain_config` attribute ([#5380](https://github.com/bazelbuild/bazel/issues/5380)). |
 
 ## cc\_toolchain\_suite
 
@@ -787,4 +787,4 @@ See also this
 | Attributes | |
 | --- | --- |
 | `name` | [Name](/versions/7.7.1/concepts/labels#target-names); required  A unique name for this target. |
-| `toolchains` | Dictionary mapping strings to [labels](/versions/7.7.1/concepts/labels); [nonconfigurable](common-definitions#configurable-attributes); required A map from "<cpu>" or "<cpu>|<compiler>" strings to a `cc_toolchain` label. "<cpu>" will be used when only `--cpu` is passed to Bazel, and "<cpu>|<compiler>" will be used when both `--cpu` and `--compiler` are passed to Bazel. Example: ```           cc_toolchain_suite(             name = "toolchain",             toolchains = \{               "piii|gcc": ":my_cc_toolchain_for_piii_using_gcc",               "piii": ":my_cc_toolchain_for_piii_using_default_compiler",             \},           ) ``` |
\ No newline at end of file
+| `toolchains` | Dictionary mapping strings to [labels](/versions/7.7.1/concepts/labels); [nonconfigurable](/versions/7.7.1/reference/be/common-definitions#configurable-attributes); required A map from "<cpu>" or "<cpu>|<compiler>" strings to a `cc_toolchain` label. "<cpu>" will be used when only `--cpu` is passed to Bazel, and "<cpu>|<compiler>" will be used when both `--cpu` and `--compiler` are passed to Bazel. Example: ```           cc_toolchain_suite(             name = "toolchain",             toolchains = \{               "piii|gcc": ":my_cc_toolchain_for_piii_using_gcc",               "piii": ":my_cc_toolchain_for_piii_using_default_compiler",             \},           ) ``` |
\ No newline at end of file
diff --git a/versions/7.7.1/reference/be/common-definitions.mdx b/versions/7.7.1/reference/be/common-definitions.mdx
index e88ad678..bd450dcb 100644
--- a/versions/7.7.1/reference/be/common-definitions.mdx
+++ b/versions/7.7.1/reference/be/common-definitions.mdx
@@ -75,11 +75,11 @@ rules.
 | `deprecation` | String; [nonconfigurable](#configurable-attributes); default is `None`  An explanatory warning message associated with this target. Typically this is used to notify users that a target has become obsolete, or has become superseded by another rule, is private to a package, or is perhaps considered harmful for some reason. It is a good idea to include some reference (like a webpage, a bug number or example migration CLs) so that one can easily find out what changes are required to avoid the message. If there is a new target that can be used as a drop in replacement, it is a good idea to just migrate all users of the old target.  This attribute has no effect on the way things are built, but it may affect a build tool's diagnostic output. The build tool issues a warning when a rule with a `deprecation` attribute is depended upon by a target in another package.  Intra-package dependencies are exempt from this warning, so that, for example, building the tests of a deprecated rule does not encounter a warning.  If a deprecated target depends on another deprecated target, no warning message is issued.  Once people have stopped using it, the target can be removed. |
 | `distribs` | List of strings; [nonconfigurable](#configurable-attributes); default is `[]`  A list of distribution-method strings to be used for this particular target. This is part of a deprecated licensing API that Bazel no longer uses. Don't use this. |
 | `exec_compatible_with` | List of [labels](/versions/7.7.1/concepts/labels); [nonconfigurable](#configurable-attributes); default is `[]`  A list of `constraint_values` that must be present in the execution platform for this target. This is in addition to any constraints already set by the rule type. Constraints are used to restrict the list of available execution platforms. For more details, see the description of [toolchain resolution](/versions/7.7.1/docs/toolchains#toolchain-resolution). |
-| `exec_properties` | Dictionary of strings; default is `{}`  A dictionary of strings that will be added to the `exec_properties` of a platform selected for this target. See `exec_properties` of the [platform](platform) rule.  If a key is present in both the platform and target-level properties, the value will be taken from the target. |
+| `exec_properties` | Dictionary of strings; default is `{}`  A dictionary of strings that will be added to the `exec_properties` of a platform selected for this target. See `exec_properties` of the [platform](/versions/7.7.1/reference/be/platform) rule.  If a key is present in both the platform and target-level properties, the value will be taken from the target. |
 | `features` | List of *feature* strings; default is `[]`  A feature is string tag that can be enabled or disabled on a target. The meaning of a feature depends on the rule itself.  This `features` attribute is combined with the [package](/versions/7.7.1/reference/be/functions#package) level `features` attribute. For example, if the features ["a", "b"] are enabled on the package level, and a target's `features` attribute contains ["-a", "c"], the features enabled for the rule will be "b" and "c". [See example](https://github.com/bazelbuild/examples/blob/main/rules/features/BUILD). |
 | `restricted_to` | List of [labels](/versions/7.7.1/concepts/labels); [nonconfigurable](#configurable-attributes); default is `[]`  The list of environments this target can be built for, *instead* of default-supported environments.  This is part of Bazel's constraint system. See `compatible_with` for details. |
 | `tags` | List of strings; [nonconfigurable](#configurable-attributes); default is `[]`  *Tags* can be used on any rule. *Tags* on test and `test_suite` rules are useful for categorizing the tests. *Tags* on non-test targets are used to control sandboxed execution of `genrule`s and [Starlark](/versions/7.7.1/rules/concepts) actions, and for parsing by humans and/or external tools.  Bazel modifies the behavior of its sandboxing code if it finds the following keywords in the `tags` attribute of any test or `genrule` target, or the keys of `execution_requirements` for any Starlark action.   * `no-sandbox` keyword results in the action or test never being   sandboxed; it can still be cached or run remotely - use `no-cache`   or `no-remote` to prevent either or both of those. * `no-cache` keyword results in the action or test never being   cached (remotely or locally) * `no-remote-cache` keyword results in the action or test never being   cached remotely (but it may be cached locally; it may also be executed remotely).   Note: for the purposes of this tag, the disk-cache is considered a local cache, whereas   the http and gRPC caches are considered remote.   If a combination of local disk cache and remote cache are used (combined cache),   it's treated as a remote cache and disabled entirely unless `--incompatible_remote_results_ignore_disk`   is set in which case the local components will be used. * `no-remote-exec` keyword results in the action or test never being   executed remotely (but it may be cached remotely). * `no-remote` keyword prevents the action or test from being executed remotely or   cached remotely. This is equivalent to using both   `no-remote-cache` and `no-remote-exec`. * `no-remote-cache-upload` keyword disables upload part of remote caching of a spawn.   it does not disable remote execution. * `local` keyword precludes the action or test from being remotely cached,   remotely executed, or run inside the sandbox.   For genrules and tests, marking the rule with the `local = True`   attribute has the same effect. * `requires-network` keyword allows access to the external   network from inside the sandbox. This tag only has an effect if sandboxing   is enabled. * `block-network` keyword blocks access to the external   network from inside the sandbox. In this case, only communication   with localhost is allowed. This tag only has an effect if sandboxing is   enabled. * `requires-fakeroot` runs the test or action as uid and gid 0 (i.e., the root   user). This is only supported on Linux. This tag takes precedence over the   `--sandbox_fake_username` command-line option.   *Tags* on tests are generally used to annotate a test's role in your debug and release process. Typically, tags are most useful for C++ and Python tests, which lack any runtime annotation ability. The use of tags and size elements gives flexibility in assembling suites of tests based around codebase check-in policy.  Bazel modifies test running behavior if it finds the following keywords in the `tags` attribute of the test rule:   * `exclusive` will force the test to be run in the   "exclusive" mode, ensuring that no other tests are running at the   same time. Such tests will be executed in serial fashion after all build   activity and non-exclusive tests have been completed. Remote execution is   disabled for such tests because Bazel doesn't have control over what's   running on a remote machine. * `exclusive-if-local` will force the test to be run in the   "exclusive" mode if it is executed locally, but will run the test in parallel if it's   executed remotely. * `manual` keyword will exclude the target from expansion of target pattern wildcards   (`...`, `:*`, `:all`, etc.) and `test_suite` rules   which do not list the test explicitly when computing the set of top-level targets to build/run   for the `build`, `test`, and `coverage` commands. It does not   affect target wildcard or test suite expansion in other contexts, including the   `query` command. Note that `manual` does not imply that a target should   not be built/run automatically by continuous build/test systems. For example, it may be   desirable to exclude a target from `bazel test ...` because it requires specific   Bazel flags, but still have it included in properly-configured presubmit or continuous test   runs. * `external` keyword will force test to be unconditionally   executed (regardless of `--cache_test_results`   value).  See [Tag Conventions](/versions/7.7.1/reference/test-encyclopedia#tag-conventions) in the Test Encyclopedia for more conventions on tags attached to test targets. |
-| `target_compatible_with` | List of [labels](/versions/7.7.1/concepts/labels); default is `[]`  A list of `constraint_value`s that must be present in the target platform for this target to be considered *compatible*. This is in addition to any constraints already set by the rule type. If the target platform does not satisfy all listed constraints then the target is considered *incompatible*. Incompatible targets are skipped for building and testing when the target pattern is expanded (e.g. `//...`, `:all`). When explicitly specified on the command line, incompatible targets cause Bazel to print an error and cause a build or test failure.  Targets that transitively depend on incompatible targets are themselves considered incompatible. They are also skipped for building and testing.  An empty list (which is the default) signifies that the target is compatible with all platforms. All rules other than [Workspace Rules](workspace) support this attribute. For some rules this attribute has no effect. For example, specifying `target_compatible_with` for a `cc_toolchain` is not useful. See the [Platforms](/versions/7.7.1/docs/platforms#skipping-incompatible-targets) page for more information about incompatible target skipping. |
+| `target_compatible_with` | List of [labels](/versions/7.7.1/concepts/labels); default is `[]`  A list of `constraint_value`s that must be present in the target platform for this target to be considered *compatible*. This is in addition to any constraints already set by the rule type. If the target platform does not satisfy all listed constraints then the target is considered *incompatible*. Incompatible targets are skipped for building and testing when the target pattern is expanded (e.g. `//...`, `:all`). When explicitly specified on the command line, incompatible targets cause Bazel to print an error and cause a build or test failure.  Targets that transitively depend on incompatible targets are themselves considered incompatible. They are also skipped for building and testing.  An empty list (which is the default) signifies that the target is compatible with all platforms. All rules other than [Workspace Rules](/versions/7.7.1/reference/be/workspace) support this attribute. For some rules this attribute has no effect. For example, specifying `target_compatible_with` for a `cc_toolchain` is not useful. See the [Platforms](/versions/7.7.1/docs/platforms#skipping-incompatible-targets) page for more information about incompatible target skipping. |
 | `testonly` | Boolean; [nonconfigurable](#configurable-attributes); default is `False` except for test and test suite targets  If `True`, only testonly targets (such as tests) can depend on this target.  Equivalently, a rule that is not `testonly` is not allowed to depend on any rule that is `testonly`.  Tests (`*_test` rules) and test suites ([test\_suite](/versions/7.7.1/reference/be/general#test_suite) rules) are `testonly` by default.  This attribute is intended to mean that the target should not be contained in binaries that are released to production.  Because testonly is enforced at build time, not run time, and propagates virally through the dependency tree, it should be applied judiciously. For example, stubs and fakes that are useful for unit tests may also be useful for integration tests involving the same binaries that will be released to production, and therefore should probably not be marked testonly. Conversely, rules that are dangerous to even link in, perhaps because they unconditionally override normal behavior, should definitely be marked testonly. |
 | `toolchains` | List of [labels](/versions/7.7.1/concepts/labels); [nonconfigurable](#configurable-attributes); default is `[]`  The set of targets whose [Make variables](/versions/7.7.1/reference/be/make-variables) this target is allowed to access. These targets are either instances of rules that provide `TemplateVariableInfo` or special targets for toolchain types built into Bazel. These include:  * `@bazel_tools//tools/cpp:current_cc_toolchain`* `@bazel_tools//tools/jdk:current_java_runtime`   Note that this is distinct from the concept of [toolchain resolution](/versions/7.7.1/docs/toolchains#toolchain-resolution) that is used by rule implementations for platform-dependent configuration. You cannot use this attribute to determine which specific `cc_toolchain` or `java_toolchain` a target will use. |
 | `visibility` | List of [labels](/versions/7.7.1/concepts/labels); [nonconfigurable](#configurable-attributes); default is `default_visibility` from [package](/versions/7.7.1/reference/be/functions#package) if specified, or `"//visibility:private"` otherwise  The `visibility` attribute on a target controls whether the target can be used in other packages. See the documentation for [visibility](/versions/7.7.1/concepts/visibility). |
diff --git a/versions/7.7.1/reference/be/functions.mdx b/versions/7.7.1/reference/be/functions.mdx
index cee5bdd0..9a92d819 100644
--- a/versions/7.7.1/reference/be/functions.mdx
+++ b/versions/7.7.1/reference/be/functions.mdx
@@ -34,9 +34,9 @@ file, before any rule.
 | --- | --- |
 | `default_applicable_licenses` | Alias for [`default_package_metadata`](#package.default_package_metadata). |
 | `default_visibility` | List of [labels](/versions/7.7.1/concepts/labels); default is `[]`  The default visibility of the rules in this package.  Every rule in this package has the visibility specified in this attribute, unless otherwise specified in the `visibility` attribute of the rule. For detailed information about the syntax of this attribute, see the documentation of [visibility](/versions/7.7.1/concepts/visibility). The package default visibility does not apply to [exports\_files](#exports_files), which is public by default. |
-| `default_deprecation` | String; default is `""`  Sets the default [`deprecation`](common-definitions#common.deprecation) message for all rules in this package. |
+| `default_deprecation` | String; default is `""`  Sets the default [`deprecation`](/versions/7.7.1/reference/be/common-definitions#common.deprecation) message for all rules in this package. |
 | `default_package_metadata` | List of [labels](/versions/7.7.1/concepts/labels); default is `[]`  Sets a default list of metadata targets which apply to all other targets in the package. These are typically targets related to OSS package and license declarations. See [rules\_license](https://github.com/bazelbuild/rules_license) for examples. |
-| `default_testonly` | Boolean; default is `False` except as noted  Sets the default [`testonly`](common-definitions#common.testonly) property for all rules in this package.  In packages under `javatests` the default value is `True`. |
+| `default_testonly` | Boolean; default is `False` except as noted  Sets the default [`testonly`](/versions/7.7.1/reference/be/common-definitions#common.testonly) property for all rules in this package.  In packages under `javatests` the default value is `True`. |
 | `features` | List strings; default is `[]`  Sets various flags that affect the semantics of this BUILD file.  This feature is mainly used by the people working on the build system to tag packages that need some kind of special handling. Do not use this unless explicitly requested by someone working on the build system. |
 
 ### Examples
@@ -66,7 +66,7 @@ visible target can only be referenced within its own package (not subpackages).
 In between these extremes, a target may allow access to its own package plus any
 of the packages described by one or more package groups. For a more detailed
 explanation of the visibility system, see the
-[visibility](common-definitions#common.visibility)
+[visibility](/versions/7.7.1/reference/be/common-definitions#common.visibility)
 attribute.
 
 A given package is considered to be in the group if it either matches the
@@ -159,7 +159,7 @@ visibility declaration can also be specified; in this case, the files will be
 visible to the targets specified. If no visibility is specified, the files
 will be visible to every package, even if a package default visibility was
 specified in the `package`
-function. The [licenses](common-definitions#common.licenses)
+function. The [licenses](/versions/7.7.1/reference/be/common-definitions#common.licenses)
 can also be specified.
 
 ### Example
@@ -250,8 +250,7 @@ There are several important limitations and caveats:
    package called "Foo.java" (which is allowed, though Bazel warns about it),
    then the consumer of the `glob()` will use the "Foo.java" rule
    (its outputs) instead of the "Foo.java" file. See
-   [GitHub
-   issue #10395](https://github.com/bazelbuild/bazel/issues/10395#issuecomment-583714657) for more details.
+   [GitHub issue #10395](https://github.com/bazelbuild/bazel/issues/10395#issuecomment-583714657) for more details.
 3. Globs may match files in subdirectories. And subdirectory names
    may be wildcarded. However...
 4. Labels are not allowed to cross the package boundary and glob does
@@ -397,7 +396,7 @@ select(
 ```
 
 `select()` is the helper function that makes a rule attribute
-[configurable](common-definitions#configurable-attributes).
+[configurable](/versions/7.7.1/reference/be/common-definitions#configurable-attributes).
 It can replace the right-hand side of
 *almost*
 any attribute assignment so its value depends on command-line Bazel flags.
diff --git a/versions/7.7.1/reference/be/general.mdx b/versions/7.7.1/reference/be/general.mdx
index e50dd903..83aeea10 100644
--- a/versions/7.7.1/reference/be/general.mdx
+++ b/versions/7.7.1/reference/be/general.mdx
@@ -158,9 +158,9 @@ some build targets.
   [here](/versions/7.7.1/reference/be/common-definitions#configurable-attributes) for more discussion.
 * Avoid repeating identical `config_setting` definitions in different packages.
   Instead, reference a common `config_setting` that defined in a canonical package.
-* [`values`](general#config_setting.values),
-  [`define_values`](general#config_setting.define_values), and
-  [`constraint_values`](general#config_setting.constraint_values)
+* [`values`](/versions/7.7.1/reference/be/general#config_setting.values),
+  [`define_values`](/versions/7.7.1/reference/be/general#config_setting.define_values), and
+  [`constraint_values`](/versions/7.7.1/reference/be/general#config_setting.constraint_values)
   can be used in any combination in the same `config_setting` but at least one must
   be set for any given `config_setting`.
 
@@ -169,10 +169,10 @@ some build targets.
 | Attributes | |
 | --- | --- |
 | `name` | [Name](/versions/7.7.1/concepts/labels#target-names); required  A unique name for this target. |
-| `constraint_values` | List of [labels](/versions/7.7.1/concepts/labels); [nonconfigurable](common-definitions#configurable-attributes); default is `[]` The minimum set of `constraint_values` that the target platform must specify in order to match this `config_setting`. (The execution platform is not considered here.) Any additional constraint values that the platform has are ignored. See [Configurable Build Attributes](https://bazel.build/versions/7.7.1/docs/configurable-attributes#platforms) for details. In the case where two `config_setting`s both match in the same `select`, this attribute is not considered for the purpose of determining whether one of the `config_setting`s is a specialization of the other. In other words, one `config_setting` cannot match a platform more strongly than another. |
-| `define_values` | Dictionary: String -> String; [nonconfigurable](common-definitions#configurable-attributes); default is `{}` The same as [`values`](/versions/7.7.1/reference/be/general#config_setting.values) but specifically for the `--define` flag. `--define` is special because its syntax (`--define KEY=VAL`) means `KEY=VAL` is a *value* from a Bazel flag perspective.  That means:  ```             config_setting(                 name = "a_and_b",                 values = {                     "define": "a=1",                     "define": "b=2",                 }) ```   doesn't work because the same key (`define`) appears twice in the dictionary. This attribute solves that problem:  ```             config_setting(                 name = "a_and_b",                 define_values = {                     "a": "1",                     "b": "2",                 }) ```   correctly matches `bazel build //foo --define a=1 --define b=2`. `--define` can still appear in [`values`](/versions/7.7.1/reference/be/general#config_setting.values) with normal flag syntax, and can be mixed freely with this attribute as long as dictionary keys remain distinct. |
-| `flag_values` | Dictionary: [label](/versions/7.7.1/concepts/labels) -> String; [nonconfigurable](common-definitions#configurable-attributes); default is `{}` The same as [`values`](/versions/7.7.1/reference/be/general#config_setting.values) but for [user-defined build flags](https://bazel.build/versions/7.7.1/rules/config#user-defined-build-settings). This is a distinct attribute because user-defined flags are referenced as labels while built-in flags are referenced as arbitrary strings. |
-| `values` | Dictionary: String -> String; [nonconfigurable](common-definitions#configurable-attributes); default is `{}` The set of configuration values that match this rule (expressed as build flags) This rule inherits the configuration of the configured target that references it in a `select` statement. It is considered to "match" a Bazel invocation if, for every entry in the dictionary, its configuration matches the entry's expected value. For example `values = {"compilation_mode": "opt"}` matches the invocations `bazel build --compilation_mode=opt ...` and `bazel build -c opt ...` on target-configured rules.  For convenience's sake, configuration values are specified as build flags (without the preceding `"--"`). But keep in mind that the two are not the same. This is because targets can be built in multiple configurations within the same build. For example, an exec configuration's "cpu" matches the value of `--host_cpu`, not `--cpu`. So different instances of the same `config_setting` may match the same invocation differently depending on the configuration of the rule using them.  If a flag is not explicitly set at the command line, its default value is used. If a key appears multiple times in the dictionary, only the last instance is used. If a key references a flag that can be set multiple times on the command line (e.g. `bazel build --copt=foo --copt=bar --copt=baz ...`), a match occurs if *any* of those settings match. |
+| `constraint_values` | List of [labels](/versions/7.7.1/concepts/labels); [nonconfigurable](/versions/7.7.1/reference/be/common-definitions#configurable-attributes); default is `[]` The minimum set of `constraint_values` that the target platform must specify in order to match this `config_setting`. (The execution platform is not considered here.) Any additional constraint values that the platform has are ignored. See [Configurable Build Attributes](https://bazel.build/versions/7.7.1/docs/configurable-attributes#platforms) for details. In the case where two `config_setting`s both match in the same `select`, this attribute is not considered for the purpose of determining whether one of the `config_setting`s is a specialization of the other. In other words, one `config_setting` cannot match a platform more strongly than another. |
+| `define_values` | Dictionary: String -> String; [nonconfigurable](/versions/7.7.1/reference/be/common-definitions#configurable-attributes); default is `{}` The same as [`values`](/versions/7.7.1/reference/be/general#config_setting.values) but specifically for the `--define` flag. `--define` is special because its syntax (`--define KEY=VAL`) means `KEY=VAL` is a *value* from a Bazel flag perspective.  That means:  ```             config_setting(                 name = "a_and_b",                 values = {                     "define": "a=1",                     "define": "b=2",                 }) ```   doesn't work because the same key (`define`) appears twice in the dictionary. This attribute solves that problem:  ```             config_setting(                 name = "a_and_b",                 define_values = {                     "a": "1",                     "b": "2",                 }) ```   correctly matches `bazel build //foo --define a=1 --define b=2`. `--define` can still appear in [`values`](/versions/7.7.1/reference/be/general#config_setting.values) with normal flag syntax, and can be mixed freely with this attribute as long as dictionary keys remain distinct. |
+| `flag_values` | Dictionary: [label](/versions/7.7.1/concepts/labels) -> String; [nonconfigurable](/versions/7.7.1/reference/be/common-definitions#configurable-attributes); default is `{}` The same as [`values`](/versions/7.7.1/reference/be/general#config_setting.values) but for [user-defined build flags](https://bazel.build/versions/7.7.1/rules/config#user-defined-build-settings). This is a distinct attribute because user-defined flags are referenced as labels while built-in flags are referenced as arbitrary strings. |
+| `values` | Dictionary: String -> String; [nonconfigurable](/versions/7.7.1/reference/be/common-definitions#configurable-attributes); default is `{}` The set of configuration values that match this rule (expressed as build flags) This rule inherits the configuration of the configured target that references it in a `select` statement. It is considered to "match" a Bazel invocation if, for every entry in the dictionary, its configuration matches the entry's expected value. For example `values = {"compilation_mode": "opt"}` matches the invocations `bazel build --compilation_mode=opt ...` and `bazel build -c opt ...` on target-configured rules.  For convenience's sake, configuration values are specified as build flags (without the preceding `"--"`). But keep in mind that the two are not the same. This is because targets can be built in multiple configurations within the same build. For example, an exec configuration's "cpu" matches the value of `--host_cpu`, not `--cpu`. So different instances of the same `config_setting` may match the same invocation differently depending on the configuration of the rule using them.  If a flag is not explicitly set at the command line, its default value is used. If a key appears multiple times in the dictionary, only the last instance is used. If a key references a flag that can be set multiple times on the command line (e.g. `bazel build --copt=foo --copt=bar --copt=baz ...`), a match occurs if *any* of those settings match. |
 
 ## filegroup
 
@@ -452,7 +452,7 @@ genrule(
 | --- | --- |
 | `name` | [Name](/versions/7.7.1/concepts/labels#target-names); required  A unique name for this target.  You may refer to this rule by name in the `srcs` or `deps` section of other `BUILD` rules. If the rule generates source files, you should use the `srcs` attribute. |
 | `srcs` | List of [labels](/versions/7.7.1/concepts/labels); default is `[]` A list of inputs for this rule, such as source files to process. *This attributes is not suitable to list tools executed by the `cmd`; use the [`tools`](/versions/7.7.1/reference/be/general#genrule.tools) attribute for them instead.*  The build system ensures these prerequisites are built before running the genrule command; they are built using the same configuration as the original build request. The names of the files of these prerequisites are available to the command as a space-separated list in `$(SRCS)`; alternatively the path of an individual `srcs` target `//x:y` can be obtained using `$(location //x:y)`, or using `$<` provided it's the only entry in `srcs`. |
-| `outs` | List of [filenames](/versions/7.7.1/concepts/build-ref#filename); [nonconfigurable](common-definitions#configurable-attributes); required A list of files generated by this rule. Output files must not cross package boundaries. Output filenames are interpreted as relative to the package.  If the `executable` flag is set, `outs` must contain exactly one label.  The genrule command is expected to create each output file at a predetermined location. The location is available in `cmd` using [genrule-specific "Make" variables](/versions/7.7.1/reference/be/make-variables#predefined_genrule_variables) (`$@`, `$(OUTS)`, `$(@D)` or `$(RULEDIR)`) or using [`$(location)`](/versions/7.7.1/reference/be/make-variables#predefined_label_variables) substitution. |
+| `outs` | List of [filenames](/versions/7.7.1/concepts/build-ref#filename); [nonconfigurable](/versions/7.7.1/reference/be/common-definitions#configurable-attributes); required A list of files generated by this rule. Output files must not cross package boundaries. Output filenames are interpreted as relative to the package.  If the `executable` flag is set, `outs` must contain exactly one label.  The genrule command is expected to create each output file at a predetermined location. The location is available in `cmd` using [genrule-specific "Make" variables](/versions/7.7.1/reference/be/make-variables#predefined_genrule_variables) (`$@`, `$(OUTS)`, `$(@D)` or `$(RULEDIR)`) or using [`$(location)`](/versions/7.7.1/reference/be/make-variables#predefined_label_variables) substitution. |
 | `cmd` | String; default is `""` The command to run. Subject to [`$(location)`](/versions/7.7.1/reference/be/make-variables#predefined_label_variables) and ["Make" variable](/versions/7.7.1/reference/be/make-variables) substitution.  1. First [`$(location)`](/versions/7.7.1/reference/be/make-variables#predefined_label_variables) substitution is applied, replacing all occurrences of `$(location     label)` and of `$(locations label)` (and similar    constructions using related variables `execpath`, `execpaths`,    `rootpath` and `rootpaths`). 2. Next, ["Make" variables](/versions/7.7.1/reference/be/make-variables) are expanded. Note that    predefined variables `$(JAVA)`, `$(JAVAC)` and    `$(JAVABASE)` expand under the *exec* configuration, so Java invocations    that run as part of a build step can correctly load shared libraries and other    dependencies. 3. Finally, the resulting command is executed using the Bash shell. If its exit code is    non-zero the command is considered to have failed.  This is the fallback of `cmd_bash`, `cmd_ps` and `cmd_bat`, if none of them are applicable. |
 
 If the command line length exceeds the platform limit (64K on Linux/macOS, 8K on Windows),
@@ -463,11 +463,11 @@ applies to all cmd attributes (`cmd`, `cmd_bash`, `cmd_ps`,
 | `cmd_bash` | String; default is `""` The Bash command to run. This attribute has higher priority than `cmd`. The command is expanded and runs in the exact same way as the `cmd` attribute. |
 | `cmd_bat` | String; default is `""` The Batch command to run on Windows. This attribute has higher priority than `cmd` and `cmd_bash`. The command runs in the similar way as the `cmd` attribute, with the following differences:   * This attribute only applies on Windows. * The command runs with `cmd.exe /c` with the following default arguments:   + `/S` - strip first and last quotes and execute everything else as is.   + `/E:ON` - enable extended command set.   + `/V:ON` - enable delayed variable expansion   + `/D` - ignore AutoRun registry entries. * After [$(location)](/versions/7.7.1/reference/be/make-variables#predefined_label_variables) and   ["Make" variable](/versions/7.7.1/reference/be/make-variables) substitution, the paths will be   expanded to Windows style paths (with backslash). |
 | `cmd_ps` | String; default is `""` The Powershell command to run on Windows. This attribute has higher priority than `cmd`, `cmd_bash` and `cmd_bat`. The command runs in the similar way as the `cmd` attribute, with the following differences:   * This attribute only applies on Windows. * The command runs with `powershell.exe /c`.   To make Powershell easier to use and less error-prone, we run the following commands to set up the environment before executing Powershell command in genrule.   * `Set-ExecutionPolicy -Scope CurrentUser RemoteSigned` - allow running   unsigned scripts. * `$errorActionPreference='Stop'` - In case there are multiple commands   separated by `;`, the action exits immediately if a Powershell CmdLet fails,   but this does **NOT** work for external command. * `$PSDefaultParameterValues['*:Encoding'] = 'utf8'` - change the default   encoding from utf-16 to utf-8. |
-| `executable` | Boolean; [nonconfigurable](common-definitions#configurable-attributes); default is `False` Declare output to be executable. Setting this flag to True means the output is an executable file and can be run using the `run` command. The genrule must produce exactly one output in this case. If this attribute is set, `run` will try executing the file regardless of its content.  Declaring data dependencies for the generated executable is not supported. |
+| `executable` | Boolean; [nonconfigurable](/versions/7.7.1/reference/be/common-definitions#configurable-attributes); default is `False` Declare output to be executable. Setting this flag to True means the output is an executable file and can be run using the `run` command. The genrule must produce exactly one output in this case. If this attribute is set, `run` will try executing the file regardless of its content.  Declaring data dependencies for the generated executable is not supported. |
 | `local` | Boolean; default is `False`  If set to True, this option forces this `genrule` to run using the "local" strategy, which means no remote execution, no sandboxing, no persistent workers.  This is equivalent to providing 'local' as a tag (`tags=["local"]`). |
 | `message` | String; default is `""` A progress message. A progress message that will be printed as this build step is executed. By default, the message is "Generating *output*" (or something equally bland) but you may provide a more specific one. Use this attribute instead of `echo` or other print statements in your `cmd` command, as this allows the build tool to control whether such progress messages are printed or not. |
 | `output_licenses` | Licence type; default is `["none"]` See [`common attributes`](/versions/7.7.1/reference/be/common-definitions#binary.output_licenses) |
-| `output_to_bindir` | Boolean; [nonconfigurable](common-definitions#configurable-attributes); default is `False`  If set to True, this option causes output files to be written into the `bin` directory instead of the `genfiles` directory. |
+| `output_to_bindir` | Boolean; [nonconfigurable](/versions/7.7.1/reference/be/common-definitions#configurable-attributes); default is `False`  If set to True, this option causes output files to be written into the `bin` directory instead of the `genfiles` directory. |
 | `tools` | List of [labels](/versions/7.7.1/concepts/labels); default is `[]` A list of *tool* dependencies for this rule. See the definition of [dependencies](/versions/7.7.1/concepts/build-ref#deps) for more information.   The build system ensures these prerequisites are built before running the genrule command; they are built using the [*exec* configuration](/versions/7.7.1/contribute/guide#configurations), since these tools are executed as part of the build. The path of an individual `tools` target `//x:y` can be obtained using `$(location //x:y)`.  Any `*_binary` or tool to be executed by `cmd` must appear in this list, not in `srcs`, to ensure they are built in the correct configuration. |
 
 ## starlark\_doc\_extract
@@ -557,5 +557,5 @@ test_suite(
 | Attributes | |
 | --- | --- |
 | `name` | [Name](/versions/7.7.1/concepts/labels#target-names); required  A unique name for this target. |
-| `tags` | List of strings; [nonconfigurable](common-definitions#configurable-attributes); default is `[]` List of text tags such as "small" or "database" or "-flaky". Tags may be any valid string. Tags which begin with a "-" character are considered negative tags. The preceding "-" character is not considered part of the tag, so a suite tag of "-small" matches a test's "small" size. All other tags are considered positive tags.  Optionally, to make positive tags more explicit, tags may also begin with the "+" character, which will not be evaluated as part of the text of the tag. It merely makes the positive and negative distinction easier to read.  Only test rules that match **all** of the positive tags and **none** of the negative tags will be included in the test suite. Note that this does not mean that error checking for dependencies on tests that are filtered out is skipped; the dependencies on skipped tests still need to be legal (e.g. not blocked by visibility constraints).  The `manual` tag keyword is treated differently than the above by the "test\_suite expansion" performed by the `blaze test` command on invocations involving wildcard [target patterns](https://bazel.build/versions/7.7.1/docs/build#specifying-build-targets). There, `test_suite` targets tagged "manual" are filtered out (and thus not expanded). This behavior is consistent with how `blaze build` and `blaze test` handle wildcard target patterns in general. Note that this is explicitly different from how `blaze query 'tests(E)'` behaves, as suites are always expanded by the `tests` query function, regardless of the `manual` tag.  Note that a test's `size` is considered a tag for the purpose of filtering.  If you need a `test_suite` that contains tests with mutually exclusive tags (e.g. all small and medium tests), you'll have to create three `test_suite` rules: one for all small tests, one for all medium tests, and one that includes the previous two. |
-| `tests` | List of [labels](/versions/7.7.1/concepts/labels); [nonconfigurable](common-definitions#configurable-attributes); default is `[]` A list of test suites and test targets of any language. Any `*_test` is accepted here, independent of the language. No `*_binary` targets are accepted however, even if they happen to run a test. Filtering by the specified `tags` is only done for tests listed directly in this attribute. If this attribute contains `test_suite`s, the tests inside those will not be filtered by this `test_suite` (they are considered to be filtered already).  If the `tests` attribute is unspecified or empty, the rule will default to including all test rules in the current BUILD file that are not tagged as `manual`. These rules are still subject to `tag` filtering. |
\ No newline at end of file
+| `tags` | List of strings; [nonconfigurable](/versions/7.7.1/reference/be/common-definitions#configurable-attributes); default is `[]` List of text tags such as "small" or "database" or "-flaky". Tags may be any valid string. Tags which begin with a "-" character are considered negative tags. The preceding "-" character is not considered part of the tag, so a suite tag of "-small" matches a test's "small" size. All other tags are considered positive tags.  Optionally, to make positive tags more explicit, tags may also begin with the "+" character, which will not be evaluated as part of the text of the tag. It merely makes the positive and negative distinction easier to read.  Only test rules that match **all** of the positive tags and **none** of the negative tags will be included in the test suite. Note that this does not mean that error checking for dependencies on tests that are filtered out is skipped; the dependencies on skipped tests still need to be legal (e.g. not blocked by visibility constraints).  The `manual` tag keyword is treated differently than the above by the "test\_suite expansion" performed by the `blaze test` command on invocations involving wildcard [target patterns](https://bazel.build/versions/7.7.1/docs/build#specifying-build-targets). There, `test_suite` targets tagged "manual" are filtered out (and thus not expanded). This behavior is consistent with how `blaze build` and `blaze test` handle wildcard target patterns in general. Note that this is explicitly different from how `blaze query 'tests(E)'` behaves, as suites are always expanded by the `tests` query function, regardless of the `manual` tag.  Note that a test's `size` is considered a tag for the purpose of filtering.  If you need a `test_suite` that contains tests with mutually exclusive tags (e.g. all small and medium tests), you'll have to create three `test_suite` rules: one for all small tests, one for all medium tests, and one that includes the previous two. |
+| `tests` | List of [labels](/versions/7.7.1/concepts/labels); [nonconfigurable](/versions/7.7.1/reference/be/common-definitions#configurable-attributes); default is `[]` A list of test suites and test targets of any language. Any `*_test` is accepted here, independent of the language. No `*_binary` targets are accepted however, even if they happen to run a test. Filtering by the specified `tags` is only done for tests listed directly in this attribute. If this attribute contains `test_suite`s, the tests inside those will not be filtered by this `test_suite` (they are considered to be filtered already).  If the `tests` attribute is unspecified or empty, the rule will default to including all test rules in the current BUILD file that are not tagged as `manual`. These rules are still subject to `tag` filtering. |
\ No newline at end of file
diff --git a/versions/7.7.1/reference/be/java.mdx b/versions/7.7.1/reference/be/java.mdx
index 612d546b..6fcf0562 100644
--- a/versions/7.7.1/reference/be/java.mdx
+++ b/versions/7.7.1/reference/be/java.mdx
@@ -100,15 +100,15 @@ java_binary(
 | Attributes | |
 | --- | --- |
 | `name` | [Name](/versions/7.7.1/concepts/labels#target-names); required  A unique name for this target.  It is good practice to use the name of the source file that is the main entry point of the application (minus the extension). For example, if your entry point is called `Main.java`, then your name could be `Main`. |
-| `deps` | List of [labels](/versions/7.7.1/concepts/labels); default is `[]` The list of other libraries to be linked in to the target. See general comments about `deps` at [Typical attributes defined by most build rules](common-definitions#typical-attributes). |
+| `deps` | List of [labels](/versions/7.7.1/concepts/labels); default is `[]` The list of other libraries to be linked in to the target. See general comments about `deps` at [Typical attributes defined by most build rules](/versions/7.7.1/reference/be/common-definitions#typical-attributes). |
 | `srcs` | List of [labels](/versions/7.7.1/concepts/labels); default is `[]` The list of source files that are processed to create the target. This attribute is almost always required; see exceptions below. Source files of type `.java` are compiled. In case of generated `.java` files it is generally advisable to put the generating rule's name here instead of the name of the file itself. This not only improves readability but makes the rule more resilient to future changes: if the generating rule generates different files in the future, you only need to fix one place: the `outs` of the generating rule. You should not list the generating rule in `deps` because it is a no-op.  Source files of type `.srcjar` are unpacked and compiled. (This is useful if you need to generate a set of `.java` files with a genrule.)  Rules: if the rule (typically `genrule` or `filegroup`) generates any of the files listed above, they will be used the same way as described for source files.  This argument is almost always required, except if a [`main_class`](#java_binary.main_class) attribute specifies a class on the runtime classpath or you specify the `runtime_deps` argument. |
 | `resources` | List of [labels](/versions/7.7.1/concepts/labels); default is `[]` A list of data files to include in a Java jar. If resources are specified, they will be bundled in the jar along with the usual `.class` files produced by compilation. The location of the resources inside of the jar file is determined by the project structure. Bazel first looks for Maven's [standard directory layout](https://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html), (a "src" directory followed by a "resources" directory grandchild). If that is not found, Bazel then looks for the topmost directory named "java" or "javatests" (so, for example, if a resource is at `/x/java/y/java/z`, the path of the resource will be `y/java/z`. This heuristic cannot be overridden, however, the `resource_strip_prefix` attribute can be used to specify a specific alternative directory for resource files.  Resources may be source files or generated files. |
 | `classpath_resources` | List of [labels](/versions/7.7.1/concepts/labels); default is `[]` *DO NOT USE THIS OPTION UNLESS THERE IS NO OTHER WAY)* A list of resources that must be located at the root of the java tree. This attribute's only purpose is to support third-party libraries that require that their resources be found on the classpath as exactly `"myconfig.xml"`. It is only allowed on binaries and not libraries, due to the danger of namespace conflicts. |
-| `create_executable` | Boolean; [nonconfigurable](common-definitions#configurable-attributes); default is `True` Deprecated, use `java_single_jar` instead. |
+| `create_executable` | Boolean; [nonconfigurable](/versions/7.7.1/reference/be/common-definitions#configurable-attributes); default is `True` Deprecated, use `java_single_jar` instead. |
 | `deploy_env` | List of [labels](/versions/7.7.1/concepts/labels); default is `[]` A list of other `java_binary` targets which represent the deployment environment for this binary. Set this attribute when building a plugin which will be loaded by another `java_binary`.  Setting this attribute excludes all dependencies from the runtime classpath (and the deploy jar) of this binary that are shared between this binary and the targets specified in `deploy_env`. |
-| `deploy_manifest_lines` | List of strings; default is `[]` A list of lines to add to the `META-INF/manifest.mf` file generated for the `*_deploy.jar` target. The contents of this attribute are *not* subject to ["Make variable"](make-variables) substitution. |
-| `javacopts` | List of strings; default is `[]` Extra compiler options for this library. Subject to ["Make variable"](make-variables) substitution and [Bourne shell tokenization](common-definitions#sh-tokenization). These compiler options are passed to javac after the global compiler options. |
-| `jvm_flags` | List of strings; default is `[]` A list of flags to embed in the wrapper script generated for running this binary. Subject to [$(location)](/versions/7.7.1/reference/be/make-variables#location) and ["Make variable"](make-variables) substitution, and [Bourne shell tokenization](common-definitions#sh-tokenization). The wrapper script for a Java binary includes a CLASSPATH definition (to find all the dependent jars) and invokes the right Java interpreter. The command line generated by the wrapper script includes the name of the main class followed by a `"$@"` so you can pass along other arguments after the classname. However, arguments intended for parsing by the JVM must be specified *before* the classname on the command line. The contents of `jvm_flags` are added to the wrapper script before the classname is listed.  Note that this attribute has *no effect* on `*_deploy.jar` outputs. |
+| `deploy_manifest_lines` | List of strings; default is `[]` A list of lines to add to the `META-INF/manifest.mf` file generated for the `*_deploy.jar` target. The contents of this attribute are *not* subject to ["Make variable"](/versions/7.7.1/reference/be/make-variables) substitution. |
+| `javacopts` | List of strings; default is `[]` Extra compiler options for this library. Subject to ["Make variable"](/versions/7.7.1/reference/be/make-variables) substitution and [Bourne shell tokenization](/versions/7.7.1/reference/be/common-definitions#sh-tokenization). These compiler options are passed to javac after the global compiler options. |
+| `jvm_flags` | List of strings; default is `[]` A list of flags to embed in the wrapper script generated for running this binary. Subject to [$(location)](/versions/7.7.1/reference/be/make-variables#location) and ["Make variable"](/versions/7.7.1/reference/be/make-variables) substitution, and [Bourne shell tokenization](/versions/7.7.1/reference/be/common-definitions#sh-tokenization). The wrapper script for a Java binary includes a CLASSPATH definition (to find all the dependent jars) and invokes the right Java interpreter. The command line generated by the wrapper script includes the name of the main class followed by a `"$@"` so you can pass along other arguments after the classname. However, arguments intended for parsing by the JVM must be specified *before* the classname on the command line. The contents of `jvm_flags` are added to the wrapper script before the classname is listed.  Note that this attribute has *no effect* on `*_deploy.jar` outputs. |
 | `launcher` | [Label](/versions/7.7.1/concepts/labels); default is `None` Specify a binary that will be used to run your Java program instead of the normal `bin/java` program included with the JDK. The target must be a `cc_binary`. Any `cc_binary` that implements the [Java Invocation API](http://docs.oracle.com/javase/7/docs/technotes/guides/jni/spec/invocation.html) can be specified as a value for this attribute. By default, Bazel will use the normal JDK launcher (bin/java or java.exe).  The related [`--java_launcher`](/versions/7.7.1/docs/user-manual#flag--java_launcher) Bazel flag affects only those `java_binary` and `java_test` targets that have *not* specified a `launcher` attribute.  Note that your native (C++, SWIG, JNI) dependencies will be built differently depending on whether you are using the JDK launcher or another launcher:   * If you are using the normal JDK launcher (the default), native dependencies are   built as a shared library named `{name}_nativedeps.so`, where   `{name}` is the `name` attribute of this java\_binary rule.   Unused code is *not* removed by the linker in this configuration. * If you are using any other launcher, native (C++) dependencies are statically   linked into a binary named `{name}_nativedeps`, where `{name}`   is the `name` attribute of this java\_binary rule. In this case,   the linker will remove any code it thinks is unused from the resulting binary,   which means any C++ code accessed only via JNI may not be linked in unless   that `cc_library` target specifies `alwayslink = 1`.   When using any launcher other than the default JDK launcher, the format of the `*_deploy.jar` output changes. See the main [java\_binary](#java_binary) docs for details. |
 | `main_class` | String; default is `""` Name of class with `main()` method to use as entry point. If a rule uses this option, it does not need a `srcs=[...]` list. Thus, with this attribute one can make an executable from a Java library that already contains one or more `main()` methods. The value of this attribute is a class name, not a source file. The class must be available at runtime: it may be compiled by this rule (from `srcs`) or provided by direct or transitive dependencies (through `runtime_deps` or `deps`). If the class is unavailable, the binary will fail at runtime; there is no build-time check. |
 | `plugins` | List of [labels](/versions/7.7.1/concepts/labels); default is `[]` Java compiler plugins to run at compile-time. Every `java_plugin` specified in this attribute will be run whenever this rule is built. A library may also inherit plugins from dependencies that use `exported_plugins`. Resources generated by the plugin will be included in the resulting jar of this rule. |
@@ -150,7 +150,7 @@ libraries for `java_library` and
 | --- | --- |
 | `name` | [Name](/versions/7.7.1/concepts/labels#target-names); required  A unique name for this target. |
 | `deps` | List of [labels](/versions/7.7.1/concepts/labels); default is `[]` The list of other libraries to be linked in to the target. See [java\_library.deps](/versions/7.7.1/reference/be/java#java_library.deps). |
-| `constraints` | List of strings; [nonconfigurable](common-definitions#configurable-attributes); default is `[]` Extra constraints imposed on this rule as a Java library. |
+| `constraints` | List of strings; [nonconfigurable](/versions/7.7.1/reference/be/common-definitions#configurable-attributes); default is `[]` Extra constraints imposed on this rule as a Java library. |
 | `exports` | List of [labels](/versions/7.7.1/concepts/labels); default is `[]` Targets to make available to users of this rule. See [java\_library.exports](/versions/7.7.1/reference/be/java#java_library.exports). |
 | `jars` | List of [labels](/versions/7.7.1/concepts/labels); required The list of JAR files provided to Java targets that depend on this target. |
 | `neverlink` | Boolean; default is `False` Only use this library for compilation and not at runtime. Useful if the library will be provided by the runtime environment during execution. Examples of libraries like this are IDE APIs for IDE plug-ins or `tools.jar` for anything running on a standard JDK. |
@@ -185,7 +185,7 @@ This rule compiles and links sources into a `.jar` file.
 | `resources` | List of [labels](/versions/7.7.1/concepts/labels); default is `[]` A list of data files to include in a Java jar. If resources are specified, they will be bundled in the jar along with the usual `.class` files produced by compilation. The location of the resources inside of the jar file is determined by the project structure. Bazel first looks for Maven's [standard directory layout](https://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html), (a "src" directory followed by a "resources" directory grandchild). If that is not found, Bazel then looks for the topmost directory named "java" or "javatests" (so, for example, if a resource is at `/x/java/y/java/z`, the path of the resource will be `y/java/z`. This heuristic cannot be overridden, however, the `resource_strip_prefix` attribute can be used to specify a specific alternative directory for resource files.  Resources may be source files or generated files. |
 | `exported_plugins` | List of [labels](/versions/7.7.1/concepts/labels); default is `[]` The list of `java_plugin`s (e.g. annotation processors) to export to libraries that directly depend on this library. The specified list of `java_plugin`s will be applied to any library which directly depends on this library, just as if that library had explicitly declared these labels in `plugins`. |
 | `exports` | List of [labels](/versions/7.7.1/concepts/labels); default is `[]` Exported libraries. Listing rules here will make them available to parent rules, as if the parents explicitly depended on these rules. This is not true for regular (non-exported) `deps`.  Summary: a rule *X* can access the code in *Y* if there exists a dependency path between them that begins with a `deps` edge followed by zero or more `exports` edges. Let's see some examples to illustrate this.  Assume *A* depends on *B* and *B* depends on *C*. In this case C is a *transitive* dependency of A, so changing C's sources and rebuilding A will correctly rebuild everything. However A will not be able to use classes in C. To allow that, either A has to declare C in its `deps`, or B can make it easier for A (and anything that may depend on A) by declaring C in its (B's) `exports` attribute.  The closure of exported libraries is available to all direct parent rules. Take a slightly different example: A depends on B, B depends on C and D, and also exports C but not D. Now A has access to C but not to D. Now, if C and D exported some libraries, C' and D' respectively, A could only access C' but not D'.  Important: an exported rule is not a regular dependency. Sticking to the previous example, if B exports C and wants to also use C, it has to also list it in its own `deps`. |
-| `javacopts` | List of strings; default is `[]` Extra compiler options for this library. Subject to ["Make variable"](make-variables) substitution and [Bourne shell tokenization](common-definitions#sh-tokenization). These compiler options are passed to javac after the global compiler options. |
+| `javacopts` | List of strings; default is `[]` Extra compiler options for this library. Subject to ["Make variable"](/versions/7.7.1/reference/be/make-variables) substitution and [Bourne shell tokenization](/versions/7.7.1/reference/be/common-definitions#sh-tokenization). These compiler options are passed to javac after the global compiler options. |
 | `neverlink` | Boolean; default is `False` Whether this library should only be used for compilation and not at runtime. Useful if the library will be provided by the runtime environment during execution. Examples of such libraries are the IDE APIs for IDE plug-ins or `tools.jar` for anything running on a standard JDK. Note that `neverlink = 1` does not prevent the compiler from inlining material from this library into compilation targets that depend on it, as permitted by the Java Language Specification (e.g., `static final` constants of `String` or of primitive types). The preferred use case is therefore when the runtime library is identical to the compilation library.  If the runtime library differs from the compilation library then you must ensure that it differs only in places that the JLS forbids compilers to inline (and that must hold for all future versions of the JLS). |
 | `plugins` | List of [labels](/versions/7.7.1/concepts/labels); default is `[]` Java compiler plugins to run at compile-time. Every `java_plugin` specified in this attribute will be run whenever this rule is built. A library may also inherit plugins from dependencies that use `exported_plugins`. Resources generated by the plugin will be included in the resulting jar of this rule. |
 | `proguard_specs` | List of [labels](/versions/7.7.1/concepts/labels); default is `[]` Files to be used as Proguard specification. These will describe the set of specifications to be used by Proguard. If specified, they will be added to any `android_binary` target depending on this library. The files included here must only have idempotent rules, namely -dontnote, -dontwarn, assumenosideeffects, and rules that start with -keep. Other options can only appear in `android_binary`'s proguard\_specs, to ensure non-tautological merges. |
@@ -203,7 +203,7 @@ java_lite_proto_library(name, deps, data, compatible_with, deprecation, distribs
 
 `java_lite_proto_library` generates Java code from `.proto` files.
 
-`deps` must point to [`proto_library`](protocol-buffer#proto_library) rules.
+`deps` must point to [`proto_library`](/versions/7.7.1/reference/be/protocol-buffer#proto_library) rules.
 
 Example:
 
@@ -228,7 +228,7 @@ proto_library(
 | Attributes | |
 | --- | --- |
 | `name` | [Name](/versions/7.7.1/concepts/labels#target-names); required  A unique name for this target. |
-| `deps` | List of [labels](/versions/7.7.1/concepts/labels); default is `[]` The list of [`proto_library`](protocol-buffer#proto_library) rules to generate Java code for. |
+| `deps` | List of [labels](/versions/7.7.1/concepts/labels); default is `[]` The list of [`proto_library`](/versions/7.7.1/reference/be/protocol-buffer#proto_library) rules to generate Java code for. |
 
 ## java\_proto\_library
 
@@ -240,7 +240,7 @@ java_proto_library(name, deps, data, compatible_with, deprecation, distribs, exe
 
 `java_proto_library` generates Java code from `.proto` files.
 
-`deps` must point to [`proto_library`](protocol-buffer#proto_library) rules.
+`deps` must point to [`proto_library`](/versions/7.7.1/reference/be/protocol-buffer#proto_library) rules.
 
 Example:
 
@@ -265,7 +265,7 @@ proto_library(
 | Attributes | |
 | --- | --- |
 | `name` | [Name](/versions/7.7.1/concepts/labels#target-names); required  A unique name for this target. |
-| `deps` | List of [labels](/versions/7.7.1/concepts/labels); default is `[]` The list of [`proto_library`](protocol-buffer#proto_library) rules to generate Java code for. |
+| `deps` | List of [labels](/versions/7.7.1/concepts/labels); default is `[]` The list of [`proto_library`](/versions/7.7.1/reference/be/protocol-buffer#proto_library) rules to generate Java code for. |
 
 ## java\_test
 
@@ -287,8 +287,7 @@ test code. The test runner's main method is invoked instead of the main class be
   [java\_binary](#java_binary) for more details.
 
 See the section on [java\_binary()](/versions/7.7.1/reference/be/java#java_binary_args) arguments. This rule also
-supports all [attributes common
-to all test rules (\*\_test)](/versions/7.7.1/reference/be/common-definitions#common-attributes-tests).
+supports all [attributes common to all test rules (\*\_test)](/versions/7.7.1/reference/be/common-definitions#common-attributes-tests).
 
 #### Examples
 
@@ -317,14 +316,14 @@ java_test(
 | Attributes | |
 | --- | --- |
 | `name` | [Name](/versions/7.7.1/concepts/labels#target-names); required  A unique name for this target. |
-| `deps` | List of [labels](/versions/7.7.1/concepts/labels); default is `[]` The list of other libraries to be linked in to the target. See general comments about `deps` at [Typical attributes defined by most build rules](common-definitions#typical-attributes). |
+| `deps` | List of [labels](/versions/7.7.1/concepts/labels); default is `[]` The list of other libraries to be linked in to the target. See general comments about `deps` at [Typical attributes defined by most build rules](/versions/7.7.1/reference/be/common-definitions#typical-attributes). |
 | `srcs` | List of [labels](/versions/7.7.1/concepts/labels); default is `[]` The list of source files that are processed to create the target. This attribute is almost always required; see exceptions below. Source files of type `.java` are compiled. In case of generated `.java` files it is generally advisable to put the generating rule's name here instead of the name of the file itself. This not only improves readability but makes the rule more resilient to future changes: if the generating rule generates different files in the future, you only need to fix one place: the `outs` of the generating rule. You should not list the generating rule in `deps` because it is a no-op.  Source files of type `.srcjar` are unpacked and compiled. (This is useful if you need to generate a set of `.java` files with a genrule.)  Rules: if the rule (typically `genrule` or `filegroup`) generates any of the files listed above, they will be used the same way as described for source files.  This argument is almost always required, except if a [`main_class`](#java_binary.main_class) attribute specifies a class on the runtime classpath or you specify the `runtime_deps` argument. |
 | `resources` | List of [labels](/versions/7.7.1/concepts/labels); default is `[]` A list of data files to include in a Java jar. If resources are specified, they will be bundled in the jar along with the usual `.class` files produced by compilation. The location of the resources inside of the jar file is determined by the project structure. Bazel first looks for Maven's [standard directory layout](https://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html), (a "src" directory followed by a "resources" directory grandchild). If that is not found, Bazel then looks for the topmost directory named "java" or "javatests" (so, for example, if a resource is at `/x/java/y/java/z`, the path of the resource will be `y/java/z`. This heuristic cannot be overridden, however, the `resource_strip_prefix` attribute can be used to specify a specific alternative directory for resource files.  Resources may be source files or generated files. |
 | `classpath_resources` | List of [labels](/versions/7.7.1/concepts/labels); default is `[]` *DO NOT USE THIS OPTION UNLESS THERE IS NO OTHER WAY)* A list of resources that must be located at the root of the java tree. This attribute's only purpose is to support third-party libraries that require that their resources be found on the classpath as exactly `"myconfig.xml"`. It is only allowed on binaries and not libraries, due to the danger of namespace conflicts. |
-| `create_executable` | Boolean; [nonconfigurable](common-definitions#configurable-attributes); default is `True` Deprecated, use `java_single_jar` instead. |
-| `deploy_manifest_lines` | List of strings; default is `[]` A list of lines to add to the `META-INF/manifest.mf` file generated for the `*_deploy.jar` target. The contents of this attribute are *not* subject to ["Make variable"](make-variables) substitution. |
-| `javacopts` | List of strings; default is `[]` Extra compiler options for this library. Subject to ["Make variable"](make-variables) substitution and [Bourne shell tokenization](common-definitions#sh-tokenization). These compiler options are passed to javac after the global compiler options. |
-| `jvm_flags` | List of strings; default is `[]` A list of flags to embed in the wrapper script generated for running this binary. Subject to [$(location)](/versions/7.7.1/reference/be/make-variables#location) and ["Make variable"](make-variables) substitution, and [Bourne shell tokenization](common-definitions#sh-tokenization). The wrapper script for a Java binary includes a CLASSPATH definition (to find all the dependent jars) and invokes the right Java interpreter. The command line generated by the wrapper script includes the name of the main class followed by a `"$@"` so you can pass along other arguments after the classname. However, arguments intended for parsing by the JVM must be specified *before* the classname on the command line. The contents of `jvm_flags` are added to the wrapper script before the classname is listed.  Note that this attribute has *no effect* on `*_deploy.jar` outputs. |
+| `create_executable` | Boolean; [nonconfigurable](/versions/7.7.1/reference/be/common-definitions#configurable-attributes); default is `True` Deprecated, use `java_single_jar` instead. |
+| `deploy_manifest_lines` | List of strings; default is `[]` A list of lines to add to the `META-INF/manifest.mf` file generated for the `*_deploy.jar` target. The contents of this attribute are *not* subject to ["Make variable"](/versions/7.7.1/reference/be/make-variables) substitution. |
+| `javacopts` | List of strings; default is `[]` Extra compiler options for this library. Subject to ["Make variable"](/versions/7.7.1/reference/be/make-variables) substitution and [Bourne shell tokenization](/versions/7.7.1/reference/be/common-definitions#sh-tokenization). These compiler options are passed to javac after the global compiler options. |
+| `jvm_flags` | List of strings; default is `[]` A list of flags to embed in the wrapper script generated for running this binary. Subject to [$(location)](/versions/7.7.1/reference/be/make-variables#location) and ["Make variable"](/versions/7.7.1/reference/be/make-variables) substitution, and [Bourne shell tokenization](/versions/7.7.1/reference/be/common-definitions#sh-tokenization). The wrapper script for a Java binary includes a CLASSPATH definition (to find all the dependent jars) and invokes the right Java interpreter. The command line generated by the wrapper script includes the name of the main class followed by a `"$@"` so you can pass along other arguments after the classname. However, arguments intended for parsing by the JVM must be specified *before* the classname on the command line. The contents of `jvm_flags` are added to the wrapper script before the classname is listed.  Note that this attribute has *no effect* on `*_deploy.jar` outputs. |
 | `launcher` | [Label](/versions/7.7.1/concepts/labels); default is `None` Specify a binary that will be used to run your Java program instead of the normal `bin/java` program included with the JDK. The target must be a `cc_binary`. Any `cc_binary` that implements the [Java Invocation API](http://docs.oracle.com/javase/7/docs/technotes/guides/jni/spec/invocation.html) can be specified as a value for this attribute. By default, Bazel will use the normal JDK launcher (bin/java or java.exe).  The related [`--java_launcher`](/versions/7.7.1/docs/user-manual#flag--java_launcher) Bazel flag affects only those `java_binary` and `java_test` targets that have *not* specified a `launcher` attribute.  Note that your native (C++, SWIG, JNI) dependencies will be built differently depending on whether you are using the JDK launcher or another launcher:   * If you are using the normal JDK launcher (the default), native dependencies are   built as a shared library named `{name}_nativedeps.so`, where   `{name}` is the `name` attribute of this java\_binary rule.   Unused code is *not* removed by the linker in this configuration. * If you are using any other launcher, native (C++) dependencies are statically   linked into a binary named `{name}_nativedeps`, where `{name}`   is the `name` attribute of this java\_binary rule. In this case,   the linker will remove any code it thinks is unused from the resulting binary,   which means any C++ code accessed only via JNI may not be linked in unless   that `cc_library` target specifies `alwayslink = 1`.   When using any launcher other than the default JDK launcher, the format of the `*_deploy.jar` output changes. See the main [java\_binary](#java_binary) docs for details. |
 | `main_class` | String; default is `""` Name of class with `main()` method to use as entry point. If a rule uses this option, it does not need a `srcs=[...]` list. Thus, with this attribute one can make an executable from a Java library that already contains one or more `main()` methods. The value of this attribute is a class name, not a source file. The class must be available at runtime: it may be compiled by this rule (from `srcs`) or provided by direct or transitive dependencies (through `runtime_deps` or `deps`). If the class is unavailable, the binary will fail at runtime; there is no build-time check. |
 | `plugins` | List of [labels](/versions/7.7.1/concepts/labels); default is `[]` Java compiler plugins to run at compile-time. Every `java_plugin` specified in this attribute will be run whenever this rule is built. A library may also inherit plugins from dependencies that use `exported_plugins`. Resources generated by the plugin will be included in the resulting jar of this rule. |
@@ -414,7 +413,7 @@ for the addition of the `processor_class` argument.
 | `data` | List of [labels](/versions/7.7.1/concepts/labels); default is `[]` The list of files needed by this library at runtime. See general comments about `data` at [Typical attributes defined by most build rules](/versions/7.7.1/reference/be/common-definitions#typical-attributes). When building a `java_library`, Bazel doesn't put these files anywhere; if the `data` files are generated files then Bazel generates them. When building a test that depends on this `java_library` Bazel copies or links the `data` files into the runfiles area. |
 | `resources` | List of [labels](/versions/7.7.1/concepts/labels); default is `[]` A list of data files to include in a Java jar. If resources are specified, they will be bundled in the jar along with the usual `.class` files produced by compilation. The location of the resources inside of the jar file is determined by the project structure. Bazel first looks for Maven's [standard directory layout](https://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html), (a "src" directory followed by a "resources" directory grandchild). If that is not found, Bazel then looks for the topmost directory named "java" or "javatests" (so, for example, if a resource is at `/x/java/y/java/z`, the path of the resource will be `y/java/z`. This heuristic cannot be overridden, however, the `resource_strip_prefix` attribute can be used to specify a specific alternative directory for resource files.  Resources may be source files or generated files. |
 | `generates_api` | Boolean; default is `False` This attribute marks annotation processors that generate API code. If a rule uses an API-generating annotation processor, other rules depending on it can refer to the generated code only if their compilation actions are scheduled after the generating rule. This attribute instructs Bazel to introduce scheduling constraints when --java\_header\_compilation is enabled. *WARNING: This attribute affects build performance, use it only if necessary.* |
-| `javacopts` | List of strings; default is `[]` Extra compiler options for this library. Subject to ["Make variable"](make-variables) substitution and [Bourne shell tokenization](common-definitions#sh-tokenization). These compiler options are passed to javac after the global compiler options. |
+| `javacopts` | List of strings; default is `[]` Extra compiler options for this library. Subject to ["Make variable"](/versions/7.7.1/reference/be/make-variables) substitution and [Bourne shell tokenization](/versions/7.7.1/reference/be/common-definitions#sh-tokenization). These compiler options are passed to javac after the global compiler options. |
 | `neverlink` | Boolean; default is `False` Whether this library should only be used for compilation and not at runtime. Useful if the library will be provided by the runtime environment during execution. Examples of such libraries are the IDE APIs for IDE plug-ins or `tools.jar` for anything running on a standard JDK. Note that `neverlink = 1` does not prevent the compiler from inlining material from this library into compilation targets that depend on it, as permitted by the Java Language Specification (e.g., `static final` constants of `String` or of primitive types). The preferred use case is therefore when the runtime library is identical to the compilation library.  If the runtime library differs from the compilation library then you must ensure that it differs only in places that the JLS forbids compilers to inline (and that must hold for all future versions of the JLS). |
 | `output_licenses` | Licence type; default is `["none"]` See [`common attributes`](/versions/7.7.1/reference/be/common-definitions#binary.output_licenses) |
 | `plugins` | List of [labels](/versions/7.7.1/concepts/labels); default is `[]` Java compiler plugins to run at compile-time. Every `java_plugin` specified in this attribute will be run whenever this rule is built. A library may also inherit plugins from dependencies that use `exported_plugins`. Resources generated by the plugin will be included in the resulting jar of this rule. |
diff --git a/versions/7.7.1/reference/be/make-variables.mdx b/versions/7.7.1/reference/be/make-variables.mdx
index 3a021a01..375443c5 100644
--- a/versions/7.7.1/reference/be/make-variables.mdx
+++ b/versions/7.7.1/reference/be/make-variables.mdx
@@ -19,8 +19,7 @@ targets, and *custom* variables, which are defined in dependency targets
 and only available to targets that depend on them.
 
 The reason for the term "Make" is historical: the syntax and semantics of
-these variables were originally intended to match [GNU
-Make](https://www.gnu.org/software/make/manual/html_node/Using-Variables.html).
+these variables were originally intended to match [GNU Make](https://www.gnu.org/software/make/manual/html_node/Using-Variables.html).
 
 ## Use
 
@@ -64,8 +63,7 @@ and look at the top output lines with capital letters.
 **Toolchain option variables**
 
 * `COMPILATION_MODE`:
-  `fastbuild`, `dbg`, or `opt`. ([more
-  details](https://bazel.build/versions/7.7.1/docs/user-manual#flag--compilation_mode))
+  `fastbuild`, `dbg`, or `opt`. ([more details](https://bazel.build/versions/7.7.1/docs/user-manual#flag--compilation_mode))
 
 **Path variables**
 
@@ -302,7 +300,7 @@ rare cases. If you are tempted to use them, please [contact the Bazel devs](http
 
 Rule and [toolchain](/versions/7.7.1/docs/toolchains) writers can define
 completely custom variables by returning a
-[TemplateVariableInfo](/versions/7.7.1/rules/lib/TemplateVariableInfo)
+[TemplateVariableInfo](/versions/7.7.1/rules/lib/providers/TemplateVariableInfo)
 provider. Any rules depending on these through the
 `toolchains` attribute can then read their values:
 
diff --git a/versions/7.7.1/reference/be/objective-c.mdx b/versions/7.7.1/reference/be/objective-c.mdx
index a1ba1263..49220ee9 100644
--- a/versions/7.7.1/reference/be/objective-c.mdx
+++ b/versions/7.7.1/reference/be/objective-c.mdx
@@ -21,8 +21,7 @@ j2objc_library(name, deps, compatible_with, deprecation, distribs, entry_classes
 
 This rule uses [J2ObjC](https://github.com/google/j2objc) to translate Java source
 files to Objective-C, which then can be used used as dependencies of objc\_library and objc\_binary
-rules. Detailed information about J2ObjC itself can be found at [the
-J2ObjC site](http://j2objc.org)
+rules. Detailed information about J2ObjC itself can be found at [the J2ObjC site](http://j2objc.org)
 
 Custom J2ObjC transpilation flags can be specified using the build flag
 `--j2objc_translation_flags` in the command line.
@@ -125,8 +124,8 @@ This allows selection of an official xcode version from the collectively availab
 | Attributes | |
 | --- | --- |
 | `name` | [Name](/versions/7.7.1/concepts/labels#target-names); required  A unique name for this target. |
-| `default` | [Label](/versions/7.7.1/concepts/labels); [nonconfigurable](common-definitions#configurable-attributes); required The default xcode version for this platform. |
-| `versions` | List of [labels](/versions/7.7.1/concepts/labels); [nonconfigurable](common-definitions#configurable-attributes); default is `[]` The xcode versions that are available on this platform. |
+| `default` | [Label](/versions/7.7.1/concepts/labels); [nonconfigurable](/versions/7.7.1/reference/be/common-definitions#configurable-attributes); required The default xcode version for this platform. |
+| `versions` | List of [labels](/versions/7.7.1/concepts/labels); [nonconfigurable](/versions/7.7.1/reference/be/common-definitions#configurable-attributes); default is `[]` The xcode versions that are available on this platform. |
 
 ## xcode\_config
 
@@ -145,10 +144,10 @@ This allows selection of an official xcode version from a number of registered a
 | Attributes | |
 | --- | --- |
 | `name` | [Name](/versions/7.7.1/concepts/labels#target-names); required  A unique name for this target. |
-| `default` | [Label](/versions/7.7.1/concepts/labels); [nonconfigurable](common-definitions#configurable-attributes); default is `None` The default official version of xcode to use. The version specified by the provided `xcode_version` target is to be used if no `xcode_version` build flag is specified. This is required if any `versions` are set. This may not be set if `remote_versions` or `local_versions` is set. |
-| `local_versions` | [Label](/versions/7.7.1/concepts/labels); [nonconfigurable](common-definitions#configurable-attributes); default is `None` The `xcode_version` targets that are available locally. These are used along with `local_versions` to select a mutually available version. This may not be set if `versions` is set. |
-| `remote_versions` | [Label](/versions/7.7.1/concepts/labels); [nonconfigurable](common-definitions#configurable-attributes); default is `None` The `xcode_version` targets that are available remotely. These are used along with `remote_versions` to select a mutually available version. This may not be set if `versions` is set. |
-| `versions` | List of [labels](/versions/7.7.1/concepts/labels); [nonconfigurable](common-definitions#configurable-attributes); default is `[]` Accepted `xcode_version` targets that may be used. If the value of the `xcode_version` build flag matches one of the aliases or version number of any of the given `xcode_version` targets, the matching target will be used. This may not be set if `remote_versions` or `local_versions` is set. |
+| `default` | [Label](/versions/7.7.1/concepts/labels); [nonconfigurable](/versions/7.7.1/reference/be/common-definitions#configurable-attributes); default is `None` The default official version of xcode to use. The version specified by the provided `xcode_version` target is to be used if no `xcode_version` build flag is specified. This is required if any `versions` are set. This may not be set if `remote_versions` or `local_versions` is set. |
+| `local_versions` | [Label](/versions/7.7.1/concepts/labels); [nonconfigurable](/versions/7.7.1/reference/be/common-definitions#configurable-attributes); default is `None` The `xcode_version` targets that are available locally. These are used along with `local_versions` to select a mutually available version. This may not be set if `versions` is set. |
+| `remote_versions` | [Label](/versions/7.7.1/concepts/labels); [nonconfigurable](/versions/7.7.1/reference/be/common-definitions#configurable-attributes); default is `None` The `xcode_version` targets that are available remotely. These are used along with `remote_versions` to select a mutually available version. This may not be set if `versions` is set. |
+| `versions` | List of [labels](/versions/7.7.1/concepts/labels); [nonconfigurable](/versions/7.7.1/reference/be/common-definitions#configurable-attributes); default is `[]` Accepted `xcode_version` targets that may be used. If the value of the `xcode_version` build flag matches one of the aliases or version number of any of the given `xcode_version` targets, the matching target will be used. This may not be set if `remote_versions` or `local_versions` is set. |
 
 ## xcode\_version
 
@@ -166,9 +165,9 @@ See the `xcode_config` rule.
 | Attributes | |
 | --- | --- |
 | `name` | [Name](/versions/7.7.1/concepts/labels#target-names); required  A unique name for this target. |
-| `default_ios_sdk_version` | String; [nonconfigurable](common-definitions#configurable-attributes); default is `""` The ios sdk version that is used by default when this version of xcode is being used. The `ios_sdk_version` build flag will override the value specified here. |
-| `default_macos_sdk_version` | String; [nonconfigurable](common-definitions#configurable-attributes); default is `""` The macosx sdk version that is used by default when this version of xcode is being used. The `macos_sdk_version` build flag will override the value specified here. |
-| `default_tvos_sdk_version` | String; [nonconfigurable](common-definitions#configurable-attributes); default is `""` The tvos sdk version that is used by default when this version of xcode is being used. The `tvos_sdk_version` build flag will override the value specified here. |
-| `default_visionos_sdk_version` | String; [nonconfigurable](common-definitions#configurable-attributes); default is `""` The visionos sdk version that is used by default when this version of xcode is being used. The `visionos_sdk_version` build flag will override the value specified here. |
-| `default_watchos_sdk_version` | String; [nonconfigurable](common-definitions#configurable-attributes); default is `""` The watchos sdk version that is used by default when this version of xcode is being used. The `watchos_sdk_version` build flag will override the value specified here. |
-| `version` | String; [nonconfigurable](common-definitions#configurable-attributes); required The official version number of a version of Xcode. |
\ No newline at end of file
+| `default_ios_sdk_version` | String; [nonconfigurable](/versions/7.7.1/reference/be/common-definitions#configurable-attributes); default is `""` The ios sdk version that is used by default when this version of xcode is being used. The `ios_sdk_version` build flag will override the value specified here. |
+| `default_macos_sdk_version` | String; [nonconfigurable](/versions/7.7.1/reference/be/common-definitions#configurable-attributes); default is `""` The macosx sdk version that is used by default when this version of xcode is being used. The `macos_sdk_version` build flag will override the value specified here. |
+| `default_tvos_sdk_version` | String; [nonconfigurable](/versions/7.7.1/reference/be/common-definitions#configurable-attributes); default is `""` The tvos sdk version that is used by default when this version of xcode is being used. The `tvos_sdk_version` build flag will override the value specified here. |
+| `default_visionos_sdk_version` | String; [nonconfigurable](/versions/7.7.1/reference/be/common-definitions#configurable-attributes); default is `""` The visionos sdk version that is used by default when this version of xcode is being used. The `visionos_sdk_version` build flag will override the value specified here. |
+| `default_watchos_sdk_version` | String; [nonconfigurable](/versions/7.7.1/reference/be/common-definitions#configurable-attributes); default is `""` The watchos sdk version that is used by default when this version of xcode is being used. The `watchos_sdk_version` build flag will override the value specified here. |
+| `version` | String; [nonconfigurable](/versions/7.7.1/reference/be/common-definitions#configurable-attributes); required The official version number of a version of Xcode. |
\ No newline at end of file
diff --git a/versions/7.7.1/reference/be/overview.mdx b/versions/7.7.1/reference/be/overview.mdx
index 1cd77867..7b31ca57 100644
--- a/versions/7.7.1/reference/be/overview.mdx
+++ b/versions/7.7.1/reference/be/overview.mdx
@@ -37,19 +37,19 @@ For non-native Starlark rules that ship separately from Bazel, see the list of
 
 | Language | Binary rules | Library rules | Test rules | Other rules |
 | --- | --- | --- | --- | --- |
-| Android | [android\_binary](android#android_binary) | [aar\_import](android#aar_import)   [android\_library](android#android_library) | [android\_instrumentation\_test](android#android_instrumentation_test)   [android\_local\_test](android#android_local_test) | [android\_device](android#android_device)   [android\_ndk\_repository](android#android_ndk_repository)   [android\_sdk\_repository](android#android_sdk_repository) |
-| C / C++ | [cc\_binary](c-cpp#cc_binary) | [cc\_import](c-cpp#cc_import)   [cc\_library](c-cpp#cc_library)   [cc\_proto\_library](c-cpp#cc_proto_library)   [cc\_shared\_library](c-cpp#cc_shared_library)   [cc\_static\_library](c-cpp#cc_static_library)   [fdo\_prefetch\_hints](c-cpp#fdo_prefetch_hints)   [fdo\_profile](c-cpp#fdo_profile)   [memprof\_profile](c-cpp#memprof_profile)   [propeller\_optimize](c-cpp#propeller_optimize) | [cc\_test](c-cpp#cc_test) | [cc\_toolchain](c-cpp#cc_toolchain)   [cc\_toolchain\_suite](c-cpp#cc_toolchain_suite) |
-| Java | [java\_binary](java#java_binary) | [java\_import](java#java_import)   [java\_library](java#java_library)   [java\_lite\_proto\_library](java#java_lite_proto_library)   [java\_proto\_library](java#java_proto_library) | [java\_test](java#java_test) | [java\_package\_configuration](java#java_package_configuration)   [java\_plugin](java#java_plugin)   [java\_runtime](java#java_runtime)   [java\_toolchain](java#java_toolchain) |
-| Objective-C |  | [j2objc\_library](objective-c#j2objc_library)   [objc\_import](objective-c#objc_import)   [objc\_library](objective-c#objc_library) |  | [available\_xcodes](objective-c#available_xcodes)   [xcode\_config](objective-c#xcode_config)   [xcode\_version](objective-c#xcode_version) |
-| Protocol Buffer |  | [proto\_lang\_toolchain](protocol-buffer#proto_lang_toolchain)   [proto\_library](protocol-buffer#proto_library) |  |  |
-| Python | [py\_binary](python#py_binary) | [py\_library](python#py_library) | [py\_test](python#py_test) | [py\_runtime](python#py_runtime) |
-| Shell | [sh\_binary](shell#sh_binary) | [sh\_library](shell#sh_library) | [sh\_test](shell#sh_test) |  |
+| Android | [android\_binary](/versions/7.7.1/reference/be/android#android_binary) | [aar\_import](/versions/7.7.1/reference/be/android#aar_import)   [android\_library](/versions/7.7.1/reference/be/android#android_library) | [android\_instrumentation\_test](/versions/7.7.1/reference/be/android#android_instrumentation_test)   [android\_local\_test](/versions/7.7.1/reference/be/android#android_local_test) | [android\_device](/versions/7.7.1/reference/be/android#android_device)   [android\_ndk\_repository](/versions/7.7.1/reference/be/android#android_ndk_repository)   [android\_sdk\_repository](/versions/7.7.1/reference/be/android#android_sdk_repository) |
+| C / C++ | [cc\_binary](/versions/7.7.1/reference/be/c-cpp#cc_binary) | [cc\_import](/versions/7.7.1/reference/be/c-cpp#cc_import)   [cc\_library](/versions/7.7.1/reference/be/c-cpp#cc_library)   [cc\_proto\_library](/versions/7.7.1/reference/be/c-cpp#cc_proto_library)   [cc\_shared\_library](/versions/7.7.1/reference/be/c-cpp#cc_shared_library)   [cc\_static\_library](/versions/7.7.1/reference/be/c-cpp#cc_static_library)   [fdo\_prefetch\_hints](/versions/7.7.1/reference/be/c-cpp#fdo_prefetch_hints)   [fdo\_profile](/versions/7.7.1/reference/be/c-cpp#fdo_profile)   [memprof\_profile](/versions/7.7.1/reference/be/c-cpp#memprof_profile)   [propeller\_optimize](/versions/7.7.1/reference/be/c-cpp#propeller_optimize) | [cc\_test](/versions/7.7.1/reference/be/c-cpp#cc_test) | [cc\_toolchain](/versions/7.7.1/reference/be/c-cpp#cc_toolchain)   [cc\_toolchain\_suite](/versions/7.7.1/reference/be/c-cpp#cc_toolchain_suite) |
+| Java | [java\_binary](/versions/7.7.1/reference/be/java#java_binary) | [java\_import](/versions/7.7.1/reference/be/java#java_import)   [java\_library](/versions/7.7.1/reference/be/java#java_library)   [java\_lite\_proto\_library](/versions/7.7.1/reference/be/java#java_lite_proto_library)   [java\_proto\_library](/versions/7.7.1/reference/be/java#java_proto_library) | [java\_test](/versions/7.7.1/reference/be/java#java_test) | [java\_package\_configuration](/versions/7.7.1/reference/be/java#java_package_configuration)   [java\_plugin](/versions/7.7.1/reference/be/java#java_plugin)   [java\_runtime](/versions/7.7.1/reference/be/java#java_runtime)   [java\_toolchain](/versions/7.7.1/reference/be/java#java_toolchain) |
+| Objective-C |  | [j2objc\_library](/versions/7.7.1/reference/be/objective-c#j2objc_library)   [objc\_import](/versions/7.7.1/reference/be/objective-c#objc_import)   [objc\_library](/versions/7.7.1/reference/be/objective-c#objc_library) |  | [available\_xcodes](/versions/7.7.1/reference/be/objective-c#available_xcodes)   [xcode\_config](/versions/7.7.1/reference/be/objective-c#xcode_config)   [xcode\_version](/versions/7.7.1/reference/be/objective-c#xcode_version) |
+| Protocol Buffer |  | [proto\_lang\_toolchain](/versions/7.7.1/reference/be/protocol-buffer#proto_lang_toolchain)   [proto\_library](/versions/7.7.1/reference/be/protocol-buffer#proto_library) |  |  |
+| Python | [py\_binary](/versions/7.7.1/reference/be/python#py_binary) | [py\_library](/versions/7.7.1/reference/be/python#py_library) | [py\_test](/versions/7.7.1/reference/be/python#py_test) | [py\_runtime](/versions/7.7.1/reference/be/python#py_runtime) |
+| Shell | [sh\_binary](/versions/7.7.1/reference/be/shell#sh_binary) | [sh\_library](/versions/7.7.1/reference/be/shell#sh_library) | [sh\_test](/versions/7.7.1/reference/be/shell#sh_test) |  |
 
 ### Language-agnostic native rules
 
 | Family | Rules |
 | --- | --- |
-| Extra Actions | * [action\_listener](extra-actions#action_listener)* [extra\_action](extra-actions#extra_action) |
-| General | * [alias](general#alias)* [config\_setting](general#config_setting)* [filegroup](general#filegroup)* [genquery](general#genquery)* [genrule](general#genrule)* [starlark\_doc\_extract](general#starlark_doc_extract)* [test\_suite](general#test_suite) |
-| Platforms and Toolchains | * [constraint\_setting](platforms-and-toolchains#constraint_setting)* [constraint\_value](platforms-and-toolchains#constraint_value)* [platform](platforms-and-toolchains#platform)* [toolchain](platforms-and-toolchains#toolchain)* [toolchain\_type](platforms-and-toolchains#toolchain_type) |
-| Workspace | * [bind](workspace#bind)* [local\_repository](workspace#local_repository)* [new\_local\_repository](workspace#new_local_repository) |
\ No newline at end of file
+| Extra Actions | * [action\_listener](/versions/7.7.1/reference/be/extra-actions#action_listener)* [extra\_action](/versions/7.7.1/reference/be/extra-actions#extra_action) |
+| General | * [alias](/versions/7.7.1/reference/be/general#alias)* [config\_setting](/versions/7.7.1/reference/be/general#config_setting)* [filegroup](/versions/7.7.1/reference/be/general#filegroup)* [genquery](/versions/7.7.1/reference/be/general#genquery)* [genrule](/versions/7.7.1/reference/be/general#genrule)* [starlark\_doc\_extract](/versions/7.7.1/reference/be/general#starlark_doc_extract)* [test\_suite](/versions/7.7.1/reference/be/general#test_suite) |
+| Platforms and Toolchains | * [constraint\_setting](/versions/7.7.1/reference/be/platforms-and-toolchains#constraint_setting)* [constraint\_value](/versions/7.7.1/reference/be/platforms-and-toolchains#constraint_value)* [platform](/versions/7.7.1/reference/be/platforms-and-toolchains#platform)* [toolchain](/versions/7.7.1/reference/be/platforms-and-toolchains#toolchain)* [toolchain\_type](/versions/7.7.1/reference/be/platforms-and-toolchains#toolchain_type) |
+| Workspace | * [bind](/versions/7.7.1/reference/be/workspace#bind)* [local\_repository](/versions/7.7.1/reference/be/workspace#local_repository)* [new\_local\_repository](/versions/7.7.1/reference/be/workspace#new_local_repository) |
\ No newline at end of file
diff --git a/versions/7.7.1/reference/be/platforms-and-toolchains.mdx b/versions/7.7.1/reference/be/platforms-and-toolchains.mdx
index be773040..0789a0c0 100644
--- a/versions/7.7.1/reference/be/platforms-and-toolchains.mdx
+++ b/versions/7.7.1/reference/be/platforms-and-toolchains.mdx
@@ -39,7 +39,7 @@ define a platform targeting an obscure cpu architecture.
 | Attributes | |
 | --- | --- |
 | `name` | [Name](/versions/7.7.1/concepts/labels#target-names); required  A unique name for this target. |
-| `default_constraint_value` | [Name](/versions/7.7.1/concepts/labels#target-names); [nonconfigurable](common-definitions#configurable-attributes); default is `None` The label of the default value for this setting, to be used if no value is given. If this attribute is present, the `constraint_value` it points to must be defined in the same package as this `constraint_setting`. If a constraint setting has a default value, then whenever a platform does not include any constraint value for that setting, it is the same as if the platform had specified the default value. Otherwise, if there is no default value, the constraint setting is considered to be unspecified by that platform. In that case, the platform would not match against any constraint list (such as for a `config_setting`) that requires a particular value for that setting. |
+| `default_constraint_value` | [Name](/versions/7.7.1/concepts/labels#target-names); [nonconfigurable](/versions/7.7.1/reference/be/common-definitions#configurable-attributes); default is `None` The label of the default value for this setting, to be used if no value is given. If this attribute is present, the `constraint_value` it points to must be defined in the same package as this `constraint_setting`. If a constraint setting has a default value, then whenever a platform does not include any constraint value for that setting, it is the same as if the platform had specified the default value. Otherwise, if there is no default value, the constraint setting is considered to be unspecified by that platform. In that case, the platform would not match against any constraint list (such as for a `config_setting`) that requires a particular value for that setting. |
 
 ## constraint\_value
 
@@ -73,7 +73,7 @@ Platforms can then declare that they have the `mips` architecture as an alternat
 | Attributes | |
 | --- | --- |
 | `name` | [Name](/versions/7.7.1/concepts/labels#target-names); required  A unique name for this target. |
-| `constraint_setting` | [Label](/versions/7.7.1/concepts/labels); [nonconfigurable](common-definitions#configurable-attributes); required The `constraint_setting` for which this `constraint_value` is a possible choice. |
+| `constraint_setting` | [Label](/versions/7.7.1/concepts/labels); [nonconfigurable](/versions/7.7.1/reference/be/common-definitions#configurable-attributes); required The `constraint_setting` for which this `constraint_value` is a possible choice. |
 
 ## platform
 
@@ -226,10 +226,10 @@ In this example, the child platforms have the following properties:
 | Attributes | |
 | --- | --- |
 | `name` | [Name](/versions/7.7.1/concepts/labels#target-names); required  A unique name for this target. |
-| `constraint_values` | List of [labels](/versions/7.7.1/concepts/labels); [nonconfigurable](common-definitions#configurable-attributes); default is `[]` The combination of constraint choices that this platform comprises. In order for a platform to apply to a given environment, the environment must have at least the values in this list. Each `constraint_value` in this list must be for a different `constraint_setting`. For example, you cannot define a platform that requires the cpu architecture to be both `@platforms//cpu:x86_64` and `@platforms//cpu:arm`. |
-| `exec_properties` | Dictionary: String -> String; [nonconfigurable](common-definitions#configurable-attributes); default is `{}` A map of strings that affect the way actions are executed remotely. Bazel makes no attempt to interpret this, it is treated as opaque data that's forwarded via the Platform field of the [remote execution protocol](https://github.com/bazelbuild/remote-apis). This includes any data from the parent platform's `exec_properties` attributes. If the child and parent platform define the same keys, the child's values are kept. Any keys associated with a value that is an empty string are removed from the dictionary. This attribute is a full replacement for the deprecated `remote_execution_properties`. |
-| `parents` | List of [labels](/versions/7.7.1/concepts/labels); [nonconfigurable](common-definitions#configurable-attributes); default is `[]` The label of a `platform` target that this platform should inherit from. Although the attribute takes a list, there should be no more than one platform present. Any constraint\_settings not set directly on this platform will be found in the parent platform. See the section on [Platform Inheritance](#platform_inheritance) for details. |
-| `remote_execution_properties` | String; [nonconfigurable](common-definitions#configurable-attributes); default is `""` DEPRECATED. Please use exec\_properties attribute instead. A string used to configure a remote execution platform. Actual builds make no attempt to interpret this, it is treated as opaque data that can be used by a specific SpawnRunner. This can include data from the parent platform's "remote\_execution\_properties" attribute, by using the macro "\{PARENT\_REMOTE\_EXECUTION\_PROPERTIES\}". See the section on [Platform Inheritance](#platform_inheritance) for details. |
+| `constraint_values` | List of [labels](/versions/7.7.1/concepts/labels); [nonconfigurable](/versions/7.7.1/reference/be/common-definitions#configurable-attributes); default is `[]` The combination of constraint choices that this platform comprises. In order for a platform to apply to a given environment, the environment must have at least the values in this list. Each `constraint_value` in this list must be for a different `constraint_setting`. For example, you cannot define a platform that requires the cpu architecture to be both `@platforms//cpu:x86_64` and `@platforms//cpu:arm`. |
+| `exec_properties` | Dictionary: String -> String; [nonconfigurable](/versions/7.7.1/reference/be/common-definitions#configurable-attributes); default is `{}` A map of strings that affect the way actions are executed remotely. Bazel makes no attempt to interpret this, it is treated as opaque data that's forwarded via the Platform field of the [remote execution protocol](https://github.com/bazelbuild/remote-apis). This includes any data from the parent platform's `exec_properties` attributes. If the child and parent platform define the same keys, the child's values are kept. Any keys associated with a value that is an empty string are removed from the dictionary. This attribute is a full replacement for the deprecated `remote_execution_properties`. |
+| `parents` | List of [labels](/versions/7.7.1/concepts/labels); [nonconfigurable](/versions/7.7.1/reference/be/common-definitions#configurable-attributes); default is `[]` The label of a `platform` target that this platform should inherit from. Although the attribute takes a list, there should be no more than one platform present. Any constraint\_settings not set directly on this platform will be found in the parent platform. See the section on [Platform Inheritance](#platform_inheritance) for details. |
+| `remote_execution_properties` | String; [nonconfigurable](/versions/7.7.1/reference/be/common-definitions#configurable-attributes); default is `""` DEPRECATED. Please use exec\_properties attribute instead. A string used to configure a remote execution platform. Actual builds make no attempt to interpret this, it is treated as opaque data that can be used by a specific SpawnRunner. This can include data from the parent platform's "remote\_execution\_properties" attribute, by using the macro "\{PARENT\_REMOTE\_EXECUTION\_PROPERTIES\}". See the section on [Platform Inheritance](#platform_inheritance) for details. |
 
 ## toolchain
 
@@ -249,11 +249,11 @@ details.
 | Attributes | |
 | --- | --- |
 | `name` | [Name](/versions/7.7.1/concepts/labels#target-names); required  A unique name for this target. |
-| `exec_compatible_with` | List of [labels](/versions/7.7.1/concepts/labels); [nonconfigurable](common-definitions#configurable-attributes); default is `[]` A list of `constraint_value`s that must be satisfied by an execution platform in order for this toolchain to be selected for a target building on that platform. |
-| `target_compatible_with` | List of [labels](/versions/7.7.1/concepts/labels); [nonconfigurable](common-definitions#configurable-attributes); default is `[]` A list of `constraint_value`s that must be satisfied by the target platform in order for this toolchain to be selected for a target building for that platform. |
+| `exec_compatible_with` | List of [labels](/versions/7.7.1/concepts/labels); [nonconfigurable](/versions/7.7.1/reference/be/common-definitions#configurable-attributes); default is `[]` A list of `constraint_value`s that must be satisfied by an execution platform in order for this toolchain to be selected for a target building on that platform. |
+| `target_compatible_with` | List of [labels](/versions/7.7.1/concepts/labels); [nonconfigurable](/versions/7.7.1/reference/be/common-definitions#configurable-attributes); default is `[]` A list of `constraint_value`s that must be satisfied by the target platform in order for this toolchain to be selected for a target building for that platform. |
 | `target_settings` | List of [labels](/versions/7.7.1/concepts/labels); default is `[]` A list of `config_setting`s that must be satisfied by the target configuration in order for this toolchain to be selected during toolchain resolution. |
 | `toolchain` | [Name](/versions/7.7.1/concepts/labels#target-names); required The target representing the actual tool or tool suite that is made available when this toolchain is selected. |
-| `toolchain_type` | [Label](/versions/7.7.1/concepts/labels); [nonconfigurable](common-definitions#configurable-attributes); required The label of a `toolchain_type` target that represents the role that this toolchain serves. |
+| `toolchain_type` | [Label](/versions/7.7.1/concepts/labels); [nonconfigurable](/versions/7.7.1/reference/be/common-definitions#configurable-attributes); required The label of a `toolchain_type` target that represents the role that this toolchain serves. |
 
 ## toolchain\_type
 
diff --git a/versions/7.7.1/reference/be/python.mdx b/versions/7.7.1/reference/be/python.mdx
index 68b366d5..41810844 100644
--- a/versions/7.7.1/reference/be/python.mdx
+++ b/versions/7.7.1/reference/be/python.mdx
@@ -68,7 +68,7 @@ java_library(
 | `imports` | List of strings; default is `[]` List of import directories to be added to the `PYTHONPATH`. Subject to ["Make variable"](/versions/7.7.1/reference/be/make-variables) substitution. These import directories will be added for this rule and all rules that depend on it (note: not the rules this rule depends on. Each directory will be added to `PYTHONPATH` by [`py_binary`](/versions/7.7.1/reference/be/python#py_binary) rules that depend on this rule.  Absolute paths (paths that start with `/`) and paths that references a path above the execution root are not allowed and will result in an error. |
 | `legacy_create_init` | Integer; default is `-1` Whether to implicitly create empty \_\_init\_\_.py files in the runfiles tree. These are created in every directory containing Python source code or shared libraries, and every parent directory of those directories, excluding the repo root directory. The default, auto, means true unless `--incompatible_default_to_explicit_init_py` is used. If false, the user is responsible for creating (possibly empty) \_\_init\_\_.py files and adding them to the `srcs` of Python targets as required. |
 | `main` | [Label](/versions/7.7.1/concepts/labels); default is `None` The name of the source file that is the main entry point of the application. This file must also be listed in `srcs`. If left unspecified, `name` is used instead (see above). If `name` does not match any filename in `srcs`, `main` must be specified. |
-| `python_version` | String; [nonconfigurable](common-definitions#configurable-attributes); default is `"_INTERNAL_SENTINEL"` Whether to build this target (and its transitive `deps`) for Python 2 or Python 3. Valid values are `"PY2"` and `"PY3"` (the default). The Python version is always reset (possibly by default) to whatever version is specified by this attribute, regardless of the version specified on the command line or by other higher targets that depend on this one. If you want to `select()` on the current Python version, you can inspect the value of `@rules_python//python:python_version`. See [here](https://github.com/bazelbuild/rules_python/blob/120590e2f2b66e5590bf4dc8ebef9c5338984775/python/BUILD#L43) for more information. **Bug warning:** This attribute sets the version for which Bazel builds your target, but due to [#4815](https://github.com/bazelbuild/bazel/issues/4815), the resulting stub script may still invoke the wrong interpreter version at runtime. See [this workaround](https://github.com/bazelbuild/bazel/issues/4815#issuecomment-460777113), which involves defining a `py_runtime` target that points to either Python version as needed, and activating this `py_runtime` by setting `--python_top`. |
+| `python_version` | String; [nonconfigurable](/versions/7.7.1/reference/be/common-definitions#configurable-attributes); default is `"_INTERNAL_SENTINEL"` Whether to build this target (and its transitive `deps`) for Python 2 or Python 3. Valid values are `"PY2"` and `"PY3"` (the default). The Python version is always reset (possibly by default) to whatever version is specified by this attribute, regardless of the version specified on the command line or by other higher targets that depend on this one. If you want to `select()` on the current Python version, you can inspect the value of `@rules_python//python:python_version`. See [here](https://github.com/bazelbuild/rules_python/blob/120590e2f2b66e5590bf4dc8ebef9c5338984775/python/BUILD#L43) for more information. **Bug warning:** This attribute sets the version for which Bazel builds your target, but due to [#4815](https://github.com/bazelbuild/bazel/issues/4815), the resulting stub script may still invoke the wrong interpreter version at runtime. See [this workaround](https://github.com/bazelbuild/bazel/issues/4815#issuecomment-460777113), which involves defining a `py_runtime` target that points to either Python version as needed, and activating this `py_runtime` by setting `--python_top`. |
 | `srcs_version` | String; default is `"PY2AND3"` This attribute declares the target's `srcs` to be compatible with either Python 2, Python 3, or both. To actually set the Python runtime version, use the [`python_version`](/versions/7.7.1/reference/be/python#py_binary.python_version) attribute of an executable Python rule (`py_binary` or `py_test`). Allowed values are: `"PY2AND3"`, `"PY2"`, and `"PY3"`. The values `"PY2ONLY"` and `"PY3ONLY"` are also allowed for historic reasons, but they are essentially the same as `"PY2"` and `"PY3"` and should be avoided. Note that only the executable rules (`py_binary` and `py_library`) actually verify the current Python version against the value of this attribute. (This is a feature; since `py_library` does not change the current Python version, if it did the validation, it'd be impossible to build both `PY2ONLY` and `PY3ONLY` libraries in the same invocation.) Furthermore, if there is a version mismatch, the error is only reported in the execution phase. In particular, the error will not appear in a `bazel build --nobuild` invocation.) To get diagnostic information about which dependencies introduce version requirements, you can run the `find_requirements` aspect on your target:  ```           bazel build  \               --aspects=@rules_python//python:defs.bzl%find_requirements \               --output_groups=pyversioninfo ```  This will build a file with the suffix `-pyversioninfo.txt` giving information about why your target requires one Python version or another. Note that it works even if the given target failed to build due to a version conflict. |
 | `stamp` | Integer; default is `-1` Whether to encode build information into the binary. Possible values:  * `stamp = 1`: Always stamp the build information into the binary, even in   [`--nostamp`](/versions/7.7.1/docs/user-manual#flag--stamp) builds. **This   setting should be avoided**, since it potentially kills remote caching for the   binary and any downstream actions that depend on it. * `stamp = 0`: Always replace build information by constant values. This   gives good build result caching. * `stamp = -1`: Embedding of build information is controlled by the   [`--[no]stamp`](/versions/7.7.1/docs/user-manual#flag--stamp) flag.   Stamped binaries are *not* rebuilt unless their dependencies change. |
 
@@ -136,7 +136,7 @@ py_test(
 | `imports` | List of strings; default is `[]` List of import directories to be added to the `PYTHONPATH`. Subject to ["Make variable"](/versions/7.7.1/reference/be/make-variables) substitution. These import directories will be added for this rule and all rules that depend on it (note: not the rules this rule depends on. Each directory will be added to `PYTHONPATH` by [`py_binary`](/versions/7.7.1/reference/be/python#py_binary) rules that depend on this rule.  Absolute paths (paths that start with `/`) and paths that references a path above the execution root are not allowed and will result in an error. |
 | `legacy_create_init` | Integer; default is `-1` Whether to implicitly create empty \_\_init\_\_.py files in the runfiles tree. These are created in every directory containing Python source code or shared libraries, and every parent directory of those directories, excluding the repo root directory. The default, auto, means true unless `--incompatible_default_to_explicit_init_py` is used. If false, the user is responsible for creating (possibly empty) \_\_init\_\_.py files and adding them to the `srcs` of Python targets as required. |
 | `main` | [Label](/versions/7.7.1/concepts/labels); default is `None` The name of the source file that is the main entry point of the application. This file must also be listed in `srcs`. If left unspecified, `name` is used instead (see above). If `name` does not match any filename in `srcs`, `main` must be specified. |
-| `python_version` | String; [nonconfigurable](common-definitions#configurable-attributes); default is `"_INTERNAL_SENTINEL"` Whether to build this target (and its transitive `deps`) for Python 2 or Python 3. Valid values are `"PY2"` and `"PY3"` (the default). The Python version is always reset (possibly by default) to whatever version is specified by this attribute, regardless of the version specified on the command line or by other higher targets that depend on this one. If you want to `select()` on the current Python version, you can inspect the value of `@rules_python//python:python_version`. See [here](https://github.com/bazelbuild/rules_python/blob/120590e2f2b66e5590bf4dc8ebef9c5338984775/python/BUILD#L43) for more information. **Bug warning:** This attribute sets the version for which Bazel builds your target, but due to [#4815](https://github.com/bazelbuild/bazel/issues/4815), the resulting stub script may still invoke the wrong interpreter version at runtime. See [this workaround](https://github.com/bazelbuild/bazel/issues/4815#issuecomment-460777113), which involves defining a `py_runtime` target that points to either Python version as needed, and activating this `py_runtime` by setting `--python_top`. |
+| `python_version` | String; [nonconfigurable](/versions/7.7.1/reference/be/common-definitions#configurable-attributes); default is `"_INTERNAL_SENTINEL"` Whether to build this target (and its transitive `deps`) for Python 2 or Python 3. Valid values are `"PY2"` and `"PY3"` (the default). The Python version is always reset (possibly by default) to whatever version is specified by this attribute, regardless of the version specified on the command line or by other higher targets that depend on this one. If you want to `select()` on the current Python version, you can inspect the value of `@rules_python//python:python_version`. See [here](https://github.com/bazelbuild/rules_python/blob/120590e2f2b66e5590bf4dc8ebef9c5338984775/python/BUILD#L43) for more information. **Bug warning:** This attribute sets the version for which Bazel builds your target, but due to [#4815](https://github.com/bazelbuild/bazel/issues/4815), the resulting stub script may still invoke the wrong interpreter version at runtime. See [this workaround](https://github.com/bazelbuild/bazel/issues/4815#issuecomment-460777113), which involves defining a `py_runtime` target that points to either Python version as needed, and activating this `py_runtime` by setting `--python_top`. |
 | `srcs_version` | String; default is `"PY2AND3"` This attribute declares the target's `srcs` to be compatible with either Python 2, Python 3, or both. To actually set the Python runtime version, use the [`python_version`](/versions/7.7.1/reference/be/python#py_binary.python_version) attribute of an executable Python rule (`py_binary` or `py_test`). Allowed values are: `"PY2AND3"`, `"PY2"`, and `"PY3"`. The values `"PY2ONLY"` and `"PY3ONLY"` are also allowed for historic reasons, but they are essentially the same as `"PY2"` and `"PY3"` and should be avoided. Note that only the executable rules (`py_binary` and `py_library`) actually verify the current Python version against the value of this attribute. (This is a feature; since `py_library` does not change the current Python version, if it did the validation, it'd be impossible to build both `PY2ONLY` and `PY3ONLY` libraries in the same invocation.) Furthermore, if there is a version mismatch, the error is only reported in the execution phase. In particular, the error will not appear in a `bazel build --nobuild` invocation.) To get diagnostic information about which dependencies introduce version requirements, you can run the `find_requirements` aspect on your target:  ```           bazel build  \               --aspects=@rules_python//python:defs.bzl%find_requirements \               --output_groups=pyversioninfo ```  This will build a file with the suffix `-pyversioninfo.txt` giving information about why your target requires one Python version or another. Note that it works even if the given target failed to build due to a version conflict. |
 | `stamp` | Integer; default is `0` See the section on [py\_binary()](/versions/7.7.1/reference/be/python#py_binary_args) arguments, except that the stamp argument is set to 0 by default for tests. |
 
diff --git a/versions/7.7.1/reference/be/workspace.mdx b/versions/7.7.1/reference/be/workspace.mdx
index 0a2eb48e..7134279b 100644
--- a/versions/7.7.1/reference/be/workspace.mdx
+++ b/versions/7.7.1/reference/be/workspace.mdx
@@ -25,8 +25,7 @@ bind(name, actual, compatible_with, deprecation, distribs, features, licenses, r
 
 *Warning: use of `bind()` is not recommended. See "[Consider removing bind](https://github.com/bazelbuild/bazel/issues/1952)" for a long
 discussion of its issues and alternatives. In particular, consider the use of
-[`repo_mapping`
-repository attributes](https://bazel.build/versions/7.7.1/rules/repository_rules#attributes).*
+[`repo_mapping` repository attributes](https://bazel.build/versions/7.7.1/rules/repository_rules#attributes).*
 
 *Warning: `select()` cannot be used in `bind()`. See the [Configurable Attributes FAQ](/versions/7.7.1/docs/configurable-attributes#bind-select) for
 details.*
@@ -114,8 +113,7 @@ local_repository(name, path, repo_mapping)
 ```
 
 Allows targets from a local directory to be bound. This means that the current repository can
-use targets defined in this other directory. See the [bind
-section](/versions/7.7.1/reference/be/workspace#bind_examples) for more details.
+use targets defined in this other directory. See the [bind section](/versions/7.7.1/reference/be/workspace#bind_examples) for more details.
 
 #### Examples
 
diff --git a/versions/7.7.1/reference/command-line-reference.mdx b/versions/7.7.1/reference/command-line-reference.mdx
index e7014649..e8fdaaef 100644
--- a/versions/7.7.1/reference/command-line-reference.mdx
+++ b/versions/7.7.1/reference/command-line-reference.mdx
@@ -429,7 +429,7 @@ This option affects semantics of the Starlark language or the build API accessib
     [`loading_and_analysis`](#effect_tag_LOADING_AND_ANALYSIS), [`experimental`](#metadata_tag_EXPERIMENTAL)
 
 `--[no]experimental_isolated_extension_usages` default: "false"
-:   If true, enables the isolate parameter in the use\_extension function.
+:   If true, enables the isolate parameter in the use\_extension function.
 
     Tags:
     [`loading_and_analysis`](#effect_tag_LOADING_AND_ANALYSIS)
diff --git a/versions/7.7.1/reference/glossary.mdx b/versions/7.7.1/reference/glossary.mdx
index 2ea19b3a..8a607d09 100644
--- a/versions/7.7.1/reference/glossary.mdx
+++ b/versions/7.7.1/reference/glossary.mdx
@@ -21,8 +21,7 @@ An in-memory graph of [actions](#action) and the [artifacts](#artifact) that
 these actions read and generate. The graph might include artifacts that exist as
 source files (for example, in the file system) as well as generated
 intermediate/final artifacts that are not mentioned in `BUILD` files. Produced
-during the [analysis phase](#analysis-phase) and used during the [execution
-phase](#execution-phase).
+during the [analysis phase](#analysis-phase) and used during the [execution phase](#execution-phase).
 
 ### Action graph query (aquery) {#action-graph-query}
 A [query](#query-concept) tool that can query over build [actions](#action).
@@ -37,8 +36,7 @@ invalidate individual actions deterministically.
 
 ### Analysis phase {#analysis-phase}
 The second phase of a build. Processes the [target graph](#target-graph)
-specified in [`BUILD` files](#build-file) to produce an in-memory [action
-graph](#action-graph) that determines the order of actions to run during the
+specified in [`BUILD` files](#build-file) to produce an in-memory [action graph](#action-graph) that determines the order of actions to run during the
 [execution phase](#execution-phase). This is the phase in which rule
 implementations are evaluated.
 
@@ -81,8 +79,7 @@ target's source files, dependencies, and custom compiler options. The particular
 attributes available for a given target depend on its rule type.
 
 ### .bazelrc {#bazelrc}
-Bazel’s configuration file used to change the default values for [startup
-flags](#startup-flags) and [command flags](#command-flags), and to define common
+Bazel’s configuration file used to change the default values for [startup flags](#startup-flags) and [command flags](#command-flags), and to define common
 groups of options that can then be set together on the Bazel command line using
 a `--config` flag. Bazel can combine settings from multiple bazelrc files
 (systemwide, per-workspace, per-user, or from a custom location), and a
@@ -108,8 +105,7 @@ directory.
 
 ### .bzl File {#bzl-file}
 A file that defines rules, [macros](#macro), and constants written in
-[Starlark](#starlark). These can then be imported into [`BUILD`
-files](#build-file) using the `load()` function.
+[Starlark](#starlark). These can then be imported into [`BUILD` files](#build-file) using the `load()` function.
 
 {/* TODO: ### Build event protocol */}
 
@@ -117,8 +113,7 @@ files](#build-file) using the `load()` function.
 
 ### Build graph {#build-graph}
 The dependency graph that Bazel constructs and traverses to perform a build.
-Includes nodes like [targets](#target), [configured
-targets](#configured-target), [actions](#action), and [artifacts](#artifact). A
+Includes nodes like [targets](#target), [configured targets](#configured-target), [actions](#action), and [artifacts](#artifact). A
 build is considered complete when all [artifacts](#artifact) on which a set of
 requested targets depend are verified as up-to-date.
 
@@ -158,8 +153,7 @@ graphs and restart the [analysis phase](#analysis-phase).
 ### Configuration {#configuration}
 Information outside of [rule](#rule) definitions that impacts how rules generate
 [actions](#action). Every build has at least one configuration specifying the
-target platform, action environment variables, and command-line [build
-flags](#command-flags). [Transitions](#transition) may create additional
+target platform, action environment variables, and command-line [build flags](#command-flags). [Transitions](#transition) may create additional
 configurations, such as for host tools or cross-compilation.
 
 **See also:** [Configurations](/versions/7.7.1/extending/rules#configurations)
@@ -174,8 +168,7 @@ configuration of `//:c` because changing `--javacopt` unnecessarily breaks C++
 build cacheability.
 
 ### Configured query (cquery) {#configured-query}
-A [query](#query-concept) tool that queries over [configured
-targets](#configured-target) (after the [analysis phase](#analysis-phase)
+A [query](#query-concept) tool that queries over [configured targets](#configured-target) (after the [analysis phase](#analysis-phase)
 completes). This means `select()` and [build flags](#command-flags) (such as
 `--platforms`) are accurately reflected in the results.
 
@@ -191,8 +184,7 @@ build, it has two configured targets: `` and ``.
 ### Correctness {#correctness}
 A build is correct when its output faithfully reflects the state of its
 transitive inputs. To achieve correct builds, Bazel strives to be
-[hermetic](#hermeticity), reproducible, and making [build
-analysis](#analysis-phase) and [action execution](#execution-phase)
+[hermetic](#hermeticity), reproducible, and making [build analysis](#analysis-phase) and [action execution](#execution-phase)
 deterministic.
 
 ### Dependency {#dependency}
@@ -234,8 +226,7 @@ compilation). A dynamic execution strategy can provide the best possible
 incremental and clean build times.
 
 ### Execution phase {#execution-phase}
-The third phase of a build. Executes the [actions](#action) in the [action
-graph](#action-graph) created during the [analysis phase](#analysis-phase).
+The third phase of a build. Executes the [actions](#action) in the [action graph](#action-graph) created during the [analysis phase](#analysis-phase).
 These actions invoke executables (compilers, scripts) to read and write
 [artifacts](#artifact). *Spawn strategies* control how these actions are
 executed: locally, remotely, dynamically, sandboxed, docker, and so on.
@@ -285,8 +276,7 @@ syntax may be omitted.
 The first phase of a build where Bazel executes [`BUILD` files](#build-file) to
 create [packages](#package). [Macros](#macro) and certain functions like
 `glob()` are evaluated in this phase. Interleaved with the second phase of the
-build, the [analysis phase](#analysis-phase), to build up a [target
-graph](#target-graph).
+build, the [analysis phase](#analysis-phase), to build up a [target graph](#target-graph).
 
 ### Macro {#macro}
 A mechanism to compose multiple [rule](#rule) target declarations together under
@@ -321,8 +311,7 @@ Module metadata is hosted in Bazel registries.
 
 ### Module Extension {#module-extension}
 A piece of logic that can be run to generate [repos](#repository) by reading
-inputs from across the [module](#module) dependency graph and invoking [repo
-rules](#repository-rule). Module extensions have capabilities similar to repo
+inputs from across the [module](#module) dependency graph and invoking [repo rules](#repository-rule). Module extensions have capabilities similar to repo
 rules, allowing them to access the internet, perform file I/O, and so on.
 
 **See also:** [Module extensions](/versions/7.7.1/external/extension)
@@ -335,8 +324,7 @@ example, `native.cc_library` or `native.java_library`). User-defined rules
 
 ### Output base {#output-base}
 A [workspace](#workspace)-specific directory to store Bazel output files. Used
-to separate outputs from the *workspace*'s source tree (the [main
-repo](#repository)). Located in the [output user root](#output-user-root).
+to separate outputs from the *workspace*'s source tree (the [main repo](#repository)). Located in the [output user root](#output-user-root).
 
 ### Output groups {#output-groups}
 A group of files that is expected to be built when Bazel finishes building a
@@ -391,8 +379,7 @@ query variants: [query](#query-command), [cquery](#configured-query), and
 [aquery](#action-graph-query).
 
 ### query (command) {#query-command}
-A [query](#query-concept) tool that operates over the build's post-[loading
-phase](#loading-phase) [target graph](#target-graph). This is relatively fast,
+A [query](#query-concept) tool that operates over the build's post-[loading phase](#loading-phase) [target graph](#target-graph). This is relatively fast,
 but can't analyze the effects of `select()`, [build flags](#command-flags),
 [artifacts](#artifact), or build [actions](#action).
 
@@ -410,8 +397,7 @@ repo; multiple such files can coexist in a directory.
 The *main repo* is the repo in which the current Bazel command is being run.
 
 *External repos* are defined by specifying [modules](#module) in `MODULE.bazel`
-files, or invoking [repo rules](#repository-rule) in [module
-extensions](#module-extension). They can be fetched on demand to a predetermined
+files, or invoking [repo rules](#repository-rule) in [module extensions](#module-extension). They can be fetched on demand to a predetermined
 "magical" location on disk.
 
 Each repo has a unique, constant *canonical* name, and potentially different
@@ -422,8 +408,7 @@ Each repo has a unique, constant *canonical* name, and potentially different
 ### Repository cache {#repo-cache}
 A shared content-addressable cache of files downloaded by Bazel for builds,
 shareable across [workspaces](#workspace). Enables offline builds after the
-initial download. Commonly used to cache files downloaded through [repository
-rules](#repository-rule) like `http_archive` and repository rule APIs like
+initial download. Commonly used to cache files downloaded through [repository rules](#repository-rule) like `http_archive` and repository rule APIs like
 `repository_ctx.download`. Files are cached only if their SHA-256 checksums are
 specified for the download.
 
@@ -457,8 +442,7 @@ Rules are instantiated to produce rule targets in the
 [loading phase](#loading-phase). In the [analysis phase](#analysis-phase) rule
 targets communicate information to their downstream dependencies in the form of
 [providers](#provider), and register [actions](#action) describing how to
-generate their output artifacts. These actions are run in the [execution
-phase](#execution-phase).
+generate their output artifacts. These actions are run in the [execution phase](#execution-phase).
 
 Note: Historically the term "rule" has been used to refer to a rule target.
 This usage was inherited from tools like Make, but causes confusion and should
@@ -502,8 +486,7 @@ support the stamp attribute.
 ### Starlark {#starlark}
 The extension language for writing [rules](/versions/7.7.1/extending/rules) and [macros](#macro). A
 restricted subset of Python (syntactically and grammatically) aimed for the
-purpose of configuration, and for better performance. Uses the [`.bzl`
-file](#bzl-file) extension. [`BUILD` files](#build-file) use an even more
+purpose of configuration, and for better performance. Uses the [`.bzl` file](#bzl-file) extension. [`BUILD` files](#build-file) use an even more
 restricted version of Starlark (such as no `def` function definitions), formerly
 known as Skylark.
 
@@ -525,8 +508,7 @@ An object that is defined in a [`BUILD` file](#build-file) and identified by a
 [label](#label). Targets represent the buildable units of a workspace from
 the perspective of the end user.
 
-A target that is declared by instantiating a [rule](#rule) is called a [rule
-target](#rule-target). Depending on the rule, these may be runnable (like
+A target that is declared by instantiating a [rule](#rule) is called a [rule target](#rule-target). Depending on the rule, these may be runnable (like
 `cc_binary`) or testable (like `cc_test`). Rule targets typically depend on
 other targets via their [attributes](#attribute) (such as `deps`); these
 dependencies form the basis of the [target graph](#target-graph).
@@ -537,14 +519,11 @@ within a `BUILD` file. As a special case, the `BUILD` file of any package is
 always considered a source file target in that package.
 
 Targets are discovered during the [loading phase](#loading-phase). During the
-[analysis phase](#analysis-phase), targets are associated with [build
-configurations](#configuration) to form [configured
-targets](#configured-target).
+[analysis phase](#analysis-phase), targets are associated with [build configurations](#configuration) to form [configured targets](#configured-target).
 
 ### Target graph {#target-graph}
 An in-memory graph of [targets](#target) and their dependencies. Produced during
-the [loading phase](#loading-phase) and used as an input to the [analysis
-phase](#analysis-phase).
+the [loading phase](#loading-phase) and used as an input to the [analysis phase](#analysis-phase).
 
 ### Target pattern {#target-pattern}
 A way to specify a group of [targets](#target) on the command line. Commonly
@@ -557,8 +536,7 @@ packages recursively from the root of the [workspace](#workspace).
 Rule [targets](#target) instantiated from test rules, and therefore contains a
 test executable. A return code of zero from the completion of the executable
 indicates test success. The exact contract between Bazel and tests (such as test
-environment variables, test result collection methods) is specified in the [Test
-Encyclopedia](/versions/7.7.1/reference/test-encyclopedia).
+environment variables, test result collection methods) is specified in the [Test Encyclopedia](/versions/7.7.1/reference/test-encyclopedia).
 
 ### Toolchain {#toolchain}
 A set of tools to build outputs for a language. Typically, a toolchain includes
@@ -572,8 +550,7 @@ A build [target](#target) is top-level if it’s requested on the Bazel command
 line. For example, if `//:foo` depends on `//:bar`, and `bazel build //:foo` is
 called, then for this build, `//:foo` is top-level, and `//:bar` isn’t
 top-level, although both targets will need to be built. An important difference
-between top-level and non-top-level targets is that [command
-flags](#command-flags) set on the Bazel command line (or via
+between top-level and non-top-level targets is that [command flags](#command-flags) set on the Bazel command line (or via
 [.bazelrc](#bazelrc)) will set the [configuration](#configuration) for top-level
 targets, but might be modified by a [transition](#transition) for non-top-level
 targets.
@@ -604,8 +581,7 @@ or `.bzl` file may load a given `.bzl` file. Without context, usually
 **See also:** [Visibility documentation](/versions/7.7.1/concepts/visibility)
 
 ### Workspace {#workspace}
-The environment shared by all Bazel commands run from the same [main
-repository](#repository).
+The environment shared by all Bazel commands run from the same [main repository](#repository).
 
 Note that historically the concepts of "repository" and "workspace" have been
 conflated; the term "workspace" has often been used to refer to the main
diff --git a/versions/7.7.1/release/backward-compatibility.mdx b/versions/7.7.1/release/backward-compatibility.mdx
index 6a92d718..d5a2024a 100644
--- a/versions/7.7.1/release/backward-compatibility.mdx
+++ b/versions/7.7.1/release/backward-compatibility.mdx
@@ -6,11 +6,9 @@ This page provides information about how to handle backward compatibility,
 including migrating from one release to another and how to communicate
 incompatible changes.
 
-Bazel is evolving. Minor versions released as part of an [LTS major
-version](/versions/7.7.1/release#bazel-versioning) are fully backward-compatible. New major LTS
+Bazel is evolving. Minor versions released as part of an [LTS major version](/versions/7.7.1/release#bazel-versioning) are fully backward-compatible. New major LTS
 releases may contain incompatible changes that require some migration effort.
-For more information about Bazel's release model, please check out the [Release
-Model](/versions/7.7.1/release) page.
+For more information about Bazel's release model, please check out the [Release Model](/versions/7.7.1/release) page.
 
 ## Summary {#summary}
 
@@ -59,8 +57,7 @@ available.
 ## Communicating incompatible changes {#communicating-incompatible-changes}
 
 The primary source of information about incompatible changes are GitHub issues
-marked with an ["incompatible-change"
-label](https://github.com/bazelbuild/bazel/issues?q=label%3Aincompatible-change).
+marked with an ["incompatible-change" label](https://github.com/bazelbuild/bazel/issues?q=label%3Aincompatible-change).
 
 For every incompatible change, the issue specifies the following:
 
diff --git a/versions/7.7.1/release/index.mdx b/versions/7.7.1/release/index.mdx
index 0b924197..f07c1475 100644
--- a/versions/7.7.1/release/index.mdx
+++ b/versions/7.7.1/release/index.mdx
@@ -2,16 +2,14 @@
 title: 'Release Model'
 ---
 
-As announced in [the original blog
-post](https://blog.bazel.build/2020/11/10/long-term-support-release.html), Bazel
+As announced in [the original blog post](https://blog.bazel.build/2020/11/10/long-term-support-release.html), Bazel
 4.0 and higher versions provides support for two release tracks: rolling
 releases and long term support (LTS) releases. This page covers the latest
 information about Bazel's release model.
 
 ## Release versioning {#bazel-versioning}
 
-Bazel uses a _major.minor.patch_ [Semantic
-Versioning](https://semver.org/) scheme.
+Bazel uses a _major.minor.patch_ [Semantic Versioning](https://semver.org/) scheme.
 
 *   A _major release_ contains features that are not backward compatible with
     the previous release. Each major Bazel version is an LTS release.
@@ -54,8 +52,7 @@ Bazel regularly publish releases for two release tracks.
     release.
 *   Rolling releases can ship incompatible changes. Incompatible flags are
     recommended for major breaking changes, rolling out incompatible changes
-    should follow our [backward compatibility
-    policy](/versions/7.7.1/release/backward-compatibility).
+    should follow our [backward compatibility policy](/versions/7.7.1/release/backward-compatibility).
 
 ### LTS releases {#lts-releases}
 
@@ -71,8 +68,7 @@ Bazel regularly publish releases for two release tracks.
 *   A Bazel LTS release enters the Deprecated stage after being in ​​the
     Maintenance stage for 2 years.
 
-For planned releases, please check our [release
-issues](https://github.com/bazelbuild/bazel/issues?q=is%3Aopen+is%3Aissue+label%3Arelease)
+For planned releases, please check our [release issues](https://github.com/bazelbuild/bazel/issues?q=is%3Aopen+is%3Aissue+label%3Arelease)
 on Github.
 
 ## Support matrix {#support-matrix}
@@ -84,8 +80,7 @@ on Github.
 | Bazel 5 | Maintenance | [5.4.1](https://github.com/bazelbuild/bazel/releases/tag/5.4.1) | Jan 2025 |
 | Bazel 4 | Maintenance | [4.2.4](https://github.com/bazelbuild/bazel/releases/tag/4.2.4) | Jan 2024 |
 
-All Bazel releases can be found on the [release
-page](https://github.com/bazelbuild/bazel/releases) on GitHub.
+All Bazel releases can be found on the [release page](https://github.com/bazelbuild/bazel/releases) on GitHub.
 
 Note: Bazel version older than Bazel 4 are no longer supported, Bazel users are
 recommended to upgrade to the latest LTS release or use rolling releases if you
@@ -117,8 +112,7 @@ For LTS releases, the procedure and policies below are followed:
 1.  Identify release blockers and fix issues found on the release branch.
     *   The release branch is tested with the same test suite in
         [postsubmit](https://buildkite.com/bazel/bazel-bazel) and
-        [downstream test pipeline]
-        (https://buildkite.com/bazel/bazel-at-head-plus-downstream)
+        [downstream test pipeline](https://buildkite.com/bazel/bazel-at-head-plus-downstream)
         on Bazel CI. The Bazel team monitors testing results of the release
         branch and fixes any regressions found.
 1.  Create a new release candidate from the release branch when all known
@@ -170,5 +164,4 @@ feature.
 ## Rule compatibility {#rule-compatibility}
 
 If you are a rule authors and want to maintain compatibility with different
-Bazel versions, please check out the [Rule
-Compatibility](/versions/7.7.1/release/rule-compatibility) page.
\ No newline at end of file
+Bazel versions, please check out the [Rule Compatibility](/versions/7.7.1/release/rule-compatibility) page.
\ No newline at end of file
diff --git a/versions/7.7.1/release/rule-compatibility.mdx b/versions/7.7.1/release/rule-compatibility.mdx
index c9ee8aef..91a192d5 100644
--- a/versions/7.7.1/release/rule-compatibility.mdx
+++ b/versions/7.7.1/release/rule-compatibility.mdx
@@ -53,18 +53,15 @@ Bazel LTS release.
 As Bazel rules authors, you can ensure a manageable migration process for users
 by following these best practices:
 
-1.  The rule should follow [Semantic
-    Versioning](https://semver.org/): minor versions of the same
+1.  The rule should follow [Semantic Versioning](https://semver.org/): minor versions of the same
     major version are backward compatible.
 1.  The rule at HEAD should be compatible with the latest Bazel LTS release.
 1.  The rule at HEAD should be compatible with Bazel at HEAD. To achieve this,
     you can
     *   Set up your own CI testing with Bazel at HEAD
-    *   Add your project to [Bazel downstream
-        testing](https://github.com/bazelbuild/continuous-integration/blob/master/docs/downstream-testing.md);
+    *   Add your project to [Bazel downstream testing](https://github.com/bazelbuild/continuous-integration/blob/master/docs/downstream-testing.md);
         the Bazel team files issues to your project if breaking changes in Bazel
-        affect your project, and you must follow our [downstream project
-        policies](https://github.com/bazelbuild/continuous-integration/blob/master/docs/downstream-testing.md#downstream-project-policies)
+        affect your project, and you must follow our [downstream project policies](https://github.com/bazelbuild/continuous-integration/blob/master/docs/downstream-testing.md#downstream-project-policies)
         to address issues timely.
 1.  The latest major version of the rule must be compatible with the latest
     Bazel LTS release.
diff --git a/versions/7.7.1/remote/bep-glossary.mdx b/versions/7.7.1/remote/bep-glossary.mdx
index 1b3a10f9..0b6f138b 100644
--- a/versions/7.7.1/remote/bep-glossary.mdx
+++ b/versions/7.7.1/remote/bep-glossary.mdx
@@ -36,7 +36,7 @@ BEP contains an event like the following:
 ## ActionExecuted {#actionexecuted}
 
 Provides details about the execution of a specific
-[Action](/versions/7.7.1/rules/lib/actions) in a build. By default, this event is
+[Action](/versions/7.7.1/rules/lib/builtins/actions) in a build. By default, this event is
 included in the BEP only for failed actions, to support identifying the root cause
 of build failures. Users may set the `--build_event_publish_all_actions` flag
 to include all `ActionExecuted` events.
@@ -411,5 +411,4 @@ workspace, such as the execution root.
 
 ## WorkspaceStatus {#workspacestatus}
 
-A single `WorkspaceStatus` event contains the result of the [workspace status
-command](/versions/7.7.1/docs/user-manual#workspace-status).
+A single `WorkspaceStatus` event contains the result of the [workspace status command](/versions/7.7.1/docs/user-manual#workspace-status).
diff --git a/versions/7.7.1/remote/bep.mdx b/versions/7.7.1/remote/bep.mdx
index a76b0949..641b2e7f 100644
--- a/versions/7.7.1/remote/bep.mdx
+++ b/versions/7.7.1/remote/bep.mdx
@@ -2,14 +2,12 @@
 title: 'Build Event Protocol'
 ---
 
-The [Build Event
-Protocol](https://github.com/bazelbuild/bazel/blob/master/src/main/java/com/google/devtools/build/lib/buildeventstream/proto/build_event_stream.proto)
+The [Build Event Protocol](https://github.com/bazelbuild/bazel/blob/master/src/main/java/com/google/devtools/build/lib/buildeventstream/proto/build_event_stream.proto)
 (BEP) allows third-party programs to gain insight into a Bazel invocation. For
 example, you could use the BEP to gather information for an IDE
 plugin or a dashboard that displays build results.
 
-The protocol is a set of [protocol
-buffer](https://developers.google.com/protocol-buffers/) messages with some
+The protocol is a set of [protocol buffer](https://developers.google.com/protocol-buffers/) messages with some
 semantics defined on top of it. It includes information about build and test
 results, build progress, the build configuration and much more. The BEP is
 intended to be consumed programmatically and makes parsing Bazel’s
@@ -20,16 +18,13 @@ build event is a protocol buffer message consisting of a build event identifier,
 a set of child event identifiers, and a payload.
 
 *  __Build Event Identifier:__ Depending on the kind of build event, it might be
-an [opaque
-string](https://github.com/bazelbuild/bazel/blob/16a107d/src/main/java/com/google/devtools/build/lib/buildeventstream/proto/build_event_stream.proto#L91)
-or [structured
-information](https://github.com/bazelbuild/bazel/blob/16a107d/src/main/java/com/google/devtools/build/lib/buildeventstream/proto/build_event_stream.proto#L123)
+an [opaque string](https://github.com/bazelbuild/bazel/blob/16a107d/src/main/java/com/google/devtools/build/lib/buildeventstream/proto/build_event_stream.proto#L91)
+or [structured information](https://github.com/bazelbuild/bazel/blob/16a107d/src/main/java/com/google/devtools/build/lib/buildeventstream/proto/build_event_stream.proto#L123)
 revealing more about the build event. A build event identifier is unique within
 a build.
 
 *  __Children:__ A build event may announce other build events, by including
-their build event identifiers in its [children
-field](https://github.com/bazelbuild/bazel/blob/16a107d/src/main/java/com/google/devtools/build/lib/buildeventstream/proto/build_event_stream.proto#L469).
+their build event identifiers in its [children field](https://github.com/bazelbuild/bazel/blob/16a107d/src/main/java/com/google/devtools/build/lib/buildeventstream/proto/build_event_stream.proto#L469).
 For example, the `PatternExpanded` build event announces the targets it expands
 to as children. The protocol guarantees that all events, except for the first
 event, are announced by a previous event.
@@ -91,8 +86,7 @@ human-readable formats, such as text and JSON:
 
 ## Build Event Service {#build-event-service}
 
-The [Build Event
-Service](https://github.com/googleapis/googleapis/blob/master/google/devtools/build/v1/publish_build_event.proto)
+The [Build Event Service](https://github.com/googleapis/googleapis/blob/master/google/devtools/build/v1/publish_build_event.proto)
 Protocol is a generic [gRPC](https://www.grpc.io) service for publishing build events. The Build Event
 Service protocol is independent of the BEP and treats BEP events as opaque bytes.
 Bazel ships with a gRPC client implementation of the Build Event Service protocol that
@@ -137,8 +131,7 @@ For a description of each of these flags, see the
 The BEP typically contains many references to log files (test.log, test.xml,
 etc. ) stored on the machine where Bazel is running. A remote BES server
 typically can't access these files as they are on different machines. A way to
-work around this issue is to use Bazel with [remote
-caching](/versions/7.7.1/remote/caching).
+work around this issue is to use Bazel with [remote caching](/versions/7.7.1/remote/caching).
 Bazel will upload all output files to the remote cache (including files
 referenced in the BEP) and the BES server can then fetch the referenced files
 from the cache.
diff --git a/versions/7.7.1/remote/cache-local.mdx b/versions/7.7.1/remote/cache-local.mdx
index fedb8871..7332f9dd 100644
--- a/versions/7.7.1/remote/cache-local.mdx
+++ b/versions/7.7.1/remote/cache-local.mdx
@@ -18,8 +18,7 @@ execution. However, local execution presents some additional challenges.
 ## Checking your cache hit rate {#cache-hits}
 
 Successful remote cache hits will show up in the status line, similar to
-[Cache Hits rate with Remote
-Execution](/versions/7.7.1/remote/cache-remote#check-cache-hits).
+[Cache Hits rate with Remote Execution](/versions/7.7.1/remote/cache-remote#check-cache-hits).
 
 In the standard output of your Bazel run, you will see something like the
 following:
@@ -66,8 +65,7 @@ the steps in this section.
    message you see does not give you enough information, try adding
    `--verbose_failures`.
 
-2. Follow the steps from [Troubleshooting cache hits for remote
-   execution](/versions/7.7.1/remote/cache-remote#troubleshooting_cache_hits) to
+2. Follow the steps from [Troubleshooting cache hits for remote execution](/versions/7.7.1/remote/cache-remote#troubleshooting_cache_hits) to
    ensure that your cache-writing Bazel invocations are able to get cache hits
    on the same machine and across machines.
 
@@ -81,7 +79,6 @@ the steps in this section.
    b. Ensure your cache-reading Bazel invocations build the same targets as the
       cache-writing Bazel invocations.
 
-   c. Follow the same steps as to [ensure caching across
-      machines](/versions/7.7.1/remote/cache-remote#caching-across-machines),
+   c. Follow the same steps as to [ensure caching across machines](/versions/7.7.1/remote/cache-remote#caching-across-machines),
       to ensure caching from your cache-writing Bazel invocation to your
       cache-reading Bazel invocation.
diff --git a/versions/7.7.1/remote/caching.mdx b/versions/7.7.1/remote/caching.mdx
index 5a52f250..0951cb7a 100644
--- a/versions/7.7.1/remote/caching.mdx
+++ b/versions/7.7.1/remote/caching.mdx
@@ -126,7 +126,7 @@ not provide technical support for bazel-remote.
 
 This cache stores contents on disk and also provides garbage collection
 to enforce an upper storage limit and clean unused artifacts. The cache is
-available as a [docker image] and its code is available on
+available as a [docker image](https://hub.docker.com/r/buchgr/bazel-remote-cache/) and its code is available on
 [GitHub](https://github.com/buchgr/bazel-remote/).
 Both the REST and gRPC remote cache APIs are supported.
 
@@ -308,8 +308,7 @@ or for the age of individual cache entries. Bazel will automatically garbage
 collect the disk cache while idling between builds; the idle timer can be set
 with `--experimental_disk_cache_gc_idle_delay` (defaulting to 5 minutes).
 
-As an alternative to automatic garbage collection, we also provide a [tool](
-https://github.com/bazelbuild/bazel/tree/master/src/tools/diskcache) to run a
+As an alternative to automatic garbage collection, we also provide a [tool](https://github.com/bazelbuild/bazel/tree/master/src/tools/diskcache) to run a
 garbage collection on demand.
 
 ## Known issues {#known-issues}
diff --git a/versions/7.7.1/remote/dynamic.mdx b/versions/7.7.1/remote/dynamic.mdx
index 74e224f2..7500c537 100644
--- a/versions/7.7.1/remote/dynamic.mdx
+++ b/versions/7.7.1/remote/dynamic.mdx
@@ -12,8 +12,7 @@ alike.
 This page describes how to enable, tune, and debug dynamic execution. If you
 have both local and remote execution set up and are trying to adjust Bazel
 settings for better performance, this page is for you. If you don't already have
-remote execution set up, go to the Bazel [Remote Execution
-Overview](/versions/7.7.1/remote/rbe) first.
+remote execution set up, go to the Bazel [Remote Execution Overview](/versions/7.7.1/remote/rbe) first.
 
 ## Enabling dynamic execution? {#enabling-dynamic-execution}
 
@@ -44,14 +43,12 @@ are likely. The default value is 1000ms, but should be tuned to being just a bit
 longer than cache hits usually take. The actual time depends both on the remote
 system and on how long a round-trip takes. Usually, the value will be the same
 for all users of a given remote system, unless some of them are far enough away
-to add roundtrip latency. You can use the [Bazel profiling
-features](/versions/7.7.1/rules/performance#performance-profiling) to look at how long typical
+to add roundtrip latency. You can use the [Bazel profiling features](/versions/7.7.1/rules/performance#performance-profiling) to look at how long typical
 cache hits take.
 
 Dynamic execution can be used with local sandboxed strategy as well as with
 [persistent workers](/versions/7.7.1/remote/persistent). Persistent workers will automatically
-run with sandboxing when used with dynamic execution, and cannot use [multiplex
-workers](/versions/7.7.1/remote/multiplex). On Darwin and Windows systems, the sandboxed
+run with sandboxing when used with dynamic execution, and cannot use [multiplex workers](/versions/7.7.1/remote/multiplex). On Darwin and Windows systems, the sandboxed
 strategy can be slow; you can pass `--reuse_sandbox_directories` to reduce
 overhead of creating sandboxes on these systems.
 
@@ -67,8 +64,7 @@ entire action fails. This is an intentional choice to prevent differences
 between local and remote execution from going unnoticed.
 
 For more background on how dynamic execution and its locking works, see Julio
-Merino's excellent [blog
-posts](https://jmmv.dev/series/bazel-dynamic-execution/)
+Merino's excellent [blog posts](https://jmmv.dev/series/bazel-dynamic-execution/)
 
 ## When should I use dynamic execution? {#when-to-use}
 
diff --git a/versions/7.7.1/remote/output-directories.mdx b/versions/7.7.1/remote/output-directories.mdx
index ab014ed2..7f4389fd 100644
--- a/versions/7.7.1/remote/output-directories.mdx
+++ b/versions/7.7.1/remote/output-directories.mdx
@@ -25,7 +25,7 @@ The solution that's currently implemented:
 
 * Bazel must be invoked from a directory containing a repo boundary file, or a
   subdirectory thereof. In other words, Bazel must be invoked from inside a
-  [repository](../external/overview#repository). Otherwise, an error is
+  [repository](/versions/7.7.1/external/overview#repository). Otherwise, an error is
   reported.
 * The _outputRoot_ directory defaults to `${XDG_CACHE_HOME}/bazel` (or
   `~/.cache/bazel`, if the `XDG_CACHE_HOME` environment variable is not set) on
diff --git a/versions/7.7.1/remote/persistent.mdx b/versions/7.7.1/remote/persistent.mdx
index e2a12ab7..eb9a580c 100644
--- a/versions/7.7.1/remote/persistent.mdx
+++ b/versions/7.7.1/remote/persistent.mdx
@@ -264,7 +264,6 @@ For more information on persistent workers, see:
 *   [Original persistent workers blog post](https://blog.bazel.build/2015/12/10/java-workers.html)
 *   [Haskell implementation description](https://www.tweag.io/blog/2019-09-25-bazel-ghc-persistent-worker-internship/)
 *   [Blog post by Mike Morearty](https://medium.com/@mmorearty/how-to-create-a-persistent-worker-for-bazel-7738bba2cabb)
-*   [Front End Development with Bazel: Angular/TypeScript and Persistent Workers
-    w/ Asana](https://www.youtube.com/watch?v=0pgERydGyqo)
+*   [Front End Development with Bazel: Angular/TypeScript and Persistent Workers w/ Asana](https://www.youtube.com/watch?v=0pgERydGyqo)
 *   [Bazel strategies explained](https://jmmv.dev/2019/12/bazel-strategies.html)
 *   [Informative worker strategy discussion on the bazel-discuss mailing list](https://groups.google.com/forum/#!msg/bazel-discuss/oAEnuhYOPm8/ol7hf4KWJgAJ)
diff --git a/versions/7.7.1/remote/rules.mdx b/versions/7.7.1/remote/rules.mdx
index c065ebaa..e4377311 100644
--- a/versions/7.7.1/remote/rules.mdx
+++ b/versions/7.7.1/remote/rules.mdx
@@ -54,8 +54,7 @@ variables that may not be set to equivalent values (or at all) in the remote
 execution environment.
 
 Toolchain rules currently exist for Bazel build and test rules for
-[Scala](https://github.com/bazelbuild/rules_scala/blob/master/scala/scala_toolch
-ain.bzl),
+[Scala](https://github.com/bazelbuild/rules_scala/blob/master/scala/scala_toolch ain.bzl),
 [Rust](https://github.com/bazelbuild/rules_rust/blob/main/rust/toolchain.bzl),
 and [Go](https://github.com/bazelbuild/rules_go/blob/master/go/toolchains.rst),
 and new toolchain rules are under way for other languages and tools such as
diff --git a/versions/7.7.1/remote/workspace.mdx b/versions/7.7.1/remote/workspace.mdx
index 87007e39..4d7649f7 100644
--- a/versions/7.7.1/remote/workspace.mdx
+++ b/versions/7.7.1/remote/workspace.mdx
@@ -11,8 +11,7 @@ on the host machine. If your workspace rules access information about the
 host machine for use during execution, your build is likely to break due to
 incompatibilities between the environments.
 
-As part of [adapting Bazel rules for remote
-execution](/versions/7.7.1/remote/rules), you need to find such workspace rules
+As part of [adapting Bazel rules for remote execution](/versions/7.7.1/remote/rules), you need to find such workspace rules
 and fix them. This page describes how to find potentially problematic workspace
 rules using the workspace log.
 
diff --git a/versions/7.7.1/rules/challenges.mdx b/versions/7.7.1/rules/challenges.mdx
index 2a4ccdb1..883741a3 100644
--- a/versions/7.7.1/rules/challenges.mdx
+++ b/versions/7.7.1/rules/challenges.mdx
@@ -208,7 +208,7 @@ Bazel is heavily affected by both of these scenarios, so we introduced a set of
 custom collection classes that effectively compress the information in memory by
 avoiding the copy at each step. Almost all of these data structures have set
 semantics, so we called it
-[depset](/versions/7.7.1/rules/lib/depset)
+[depset](/versions/7.7.1/rules/lib/builtins/depset)
 (also known as `NestedSet` in the internal implementation). The majority of
 changes to reduce Bazel's memory consumption over the past several years were
 changes to use depsets instead of whatever was previously used.
diff --git a/versions/7.7.1/rules/deploying.mdx b/versions/7.7.1/rules/deploying.mdx
index b572e5a9..d98f7012 100644
--- a/versions/7.7.1/rules/deploying.mdx
+++ b/versions/7.7.1/rules/deploying.mdx
@@ -91,8 +91,7 @@ At the top level, there should be a `README` that contains (at least) what
 users will need to copy-paste into their `WORKSPACE` file to use your rule.
 In general, this will be a `http_archive` pointing to your GitHub release and
 a macro call that downloads/configures any tools your rule needs. For example,
-for the [Go
-rules](https://github.com/bazelbuild/rules_go#setup), this
+for the [Go rules](https://github.com/bazelbuild/rules_go#setup), this
 looks like:
 
 ```
diff --git a/versions/7.7.1/rules/faq.mdx b/versions/7.7.1/rules/faq.mdx
index 43d4afe6..64bffa3d 100644
--- a/versions/7.7.1/rules/faq.mdx
+++ b/versions/7.7.1/rules/faq.mdx
@@ -17,7 +17,7 @@ Bazel only executes the actions needed to produce the *requested* output files.
 
 * If you want the file to be built automatically whenever your target is
   mentioned on the command line, add it to your rule's default outputs by
-  returning a [`DefaultInfo`](lib/globals#DefaultInfo) provider.
+  returning a [`DefaultInfo`](/versions/7.7.1/rules/lib/globals#DefaultInfo) provider.
 
 See the [Rules page](/versions/7.7.1/extending/rules#requesting-output-files) for more information.
 
@@ -35,24 +35,24 @@ correct path.
 
 For actions, you declare inputs by passing them to the `ctx.actions.*` function
 that creates the action. The proper path for the file can be obtained using
-[`File.path`](lib/File#path).
+[`File.path`](/versions/7.7.1/rules/lib/builtins/File#path).
 
 For binaries (the executable outputs run by a `bazel run` or `bazel test`
 command), you declare inputs by including them in the
 [runfiles](/versions/7.7.1/extending/rules#runfiles). Instead of using the `path` field, use
-[`File.short_path`](lib/File#short_path), which is file's path relative to
+[`File.short_path`](/versions/7.7.1/rules/lib/builtins/File#short_path), which is file's path relative to
 the runfiles directory in which the binary executes.
 
 ## How can I control which files are built by `bazel build //pkg:mytarget`?
 
-Use the [`DefaultInfo`](lib/globals#DefaultInfo) provider to
+Use the [`DefaultInfo`](/versions/7.7.1/rules/lib/globals#DefaultInfo) provider to
 [set the default outputs](/versions/7.7.1/extending/rules#requesting-output-files).
 
 ## How can I run a program or do file I/O as part of my build?
 
 A tool can be declared as a target, just like any other part of your build, and
 run during the execution phase to help build other targets. To create an action
-that runs a tool, use [`ctx.actions.run`](lib/actions#run) and pass in the
+that runs a tool, use [`ctx.actions.run`](/versions/7.7.1/rules/lib/builtins/actions#run) and pass in the
 tool as the `executable` parameter.
 
 During the loading and analysis phases, a tool *cannot* run, nor can you perform
diff --git a/versions/7.7.1/rules/language.mdx b/versions/7.7.1/rules/language.mdx
index 67be0486..199e7d21 100644
--- a/versions/7.7.1/rules/language.mdx
+++ b/versions/7.7.1/rules/language.mdx
@@ -34,19 +34,19 @@ Starlark's semantics can differ from Python, but behavioral differences are
 rare, except for cases where Starlark raises an error. The following Python
 types are supported:
 
-* [None](lib/globals#None)
-* [bool](lib/bool)
-* [dict](lib/dict)
-* [tuple](lib/tuple)
-* [function](lib/function)
-* [int](lib/int)
-* [list](lib/list)
-* [string](lib/string)
+* [None](/versions/7.7.1/rules/lib/globals#None)
+* [bool](/versions/7.7.1/rules/lib/core/bool)
+* [dict](/versions/7.7.1/rules/lib/core/dict)
+* [tuple](/versions/7.7.1/rules/lib/core/tuple)
+* [function](/versions/7.7.1/rules/lib/core/function)
+* [int](/versions/7.7.1/rules/lib/core/int)
+* [list](/versions/7.7.1/rules/lib/core/list)
+* [string](/versions/7.7.1/rules/lib/core/string)
 
 ## Mutability
 
 Starlark favors immutability. Two mutable data structures are available:
-[lists](lib/list) and [dicts](lib/dict). Changes to mutable
+[lists](/versions/7.7.1/rules/lib/core/list) and [dicts](/versions/7.7.1/rules/lib/core/dict). Changes to mutable
 data-structures, such as appending a value to a list or deleting an entry in a
 dictionary are valid only for objects created in the current context. After a
 context finishes, its values become immutable.
@@ -93,10 +93,8 @@ values returned by rules are immutable.
 `BUILD` files register targets via making calls to rules. `.bzl` files provide
 definitions for constants, rules, macros, and functions.
 
-[Native functions](/versions/7.7.1/reference/be/functions) and [native rules](
-/reference/be/overview#language-specific-native-rules) are global symbols in
-`BUILD` files. `bzl` files need to load them using the [`native` module](
-/rules/lib/toplevel/native).
+[Native functions](/versions/7.7.1/reference/be/functions) and [native rules](/versions/7.7.1/reference/be/overview#language-specific-native-rules) are global symbols in
+`BUILD` files. `bzl` files need to load them using the [`native` module](/versions/7.7.1/rules/lib/toplevel/native).
 
 There are two syntactic restrictions in `BUILD` files: 1) declaring functions is
 illegal, and 2) `*args` and `**kwargs` arguments are not allowed.
@@ -130,7 +128,7 @@ not defined across value types. In short: `5 < 'foo'` will throw an error and
   error: `{"a": 4, "b": 7, "a": 1}`.
 
 * Strings are represented with double-quotes (such as when you call
-  [repr](lib/globals#repr)).
+  [repr](/versions/7.7.1/rules/lib/globals#repr)).
 
 * Strings aren't iterable.
 
@@ -138,12 +136,12 @@ The following Python features are not supported:
 
 * implicit string concatenation (use explicit `+` operator).
 * Chained comparisons (such as `1 < x < 5`).
-* `class` (see [`struct`](lib/struct#struct) function).
+* `class` (see [`struct`](/versions/7.7.1/rules/lib/builtins/struct#struct) function).
 * `import` (see [`load`](/versions/7.7.1/extending/concepts#loading-an-extension) statement).
 * `while`, `yield`.
 * float and set types.
 * generators and generator expressions.
 * `is` (use `==` instead).
-* `try`, `raise`, `except`, `finally` (see [`fail`](lib/globals#fail) for fatal errors).
+* `try`, `raise`, `except`, `finally` (see [`fail`](/versions/7.7.1/rules/lib/globals#fail) for fatal errors).
 * `global`, `nonlocal`.
 * most builtin functions, most methods.
diff --git a/versions/7.7.1/rules/lib/builtins/Action.mdx b/versions/7.7.1/rules/lib/builtins/Action.mdx
index 8555c2f5..c745c19b 100644
--- a/versions/7.7.1/rules/lib/builtins/Action.mdx
+++ b/versions/7.7.1/rules/lib/builtins/Action.mdx
@@ -4,7 +4,7 @@ title: 'Action'
 
 An action created during rule analysis.
 
-This object is visible for the purpose of testing, and may be obtained from an `Actions` provider. It is normally not necessary to access `Action` objects or their fields within a rule's implementation function. You may instead want to see the [Rules page](https://bazel.build/versions/7.7.1/extending/rules#actions) for a general discussion of how to use actions when defining custom rules, or the [API reference](../builtins/actions) for creating actions.
+This object is visible for the purpose of testing, and may be obtained from an `Actions` provider. It is normally not necessary to access `Action` objects or their fields within a rule's implementation function. You may instead want to see the [Rules page](https://bazel.build/versions/7.7.1/extending/rules#actions) for a general discussion of how to use actions when defining custom rules, or the [API reference](/versions/7.7.1/rules/lib/builtins/actions) for creating actions.
 
 Some fields of this object are only applicable for certain kinds of actions. Fields that are inapplicable are set to `None`.
 
@@ -25,7 +25,7 @@ Some fields of this object are only applicable for certain kinds of actions. Fie
 sequence Action.args
 ```
 
-A list of frozen [Args](../builtins/Args) objects containing information about the action arguments. These objects contain accurate argument information, including arguments involving expanded action output directories. However, [Args](../builtins/Args) objects are not readable in the analysis phase. For a less accurate account of arguments which is available in the analysis phase, see [argv](#argv).
+A list of frozen [Args](/versions/7.7.1/rules/lib/builtins/Args) objects containing information about the action arguments. These objects contain accurate argument information, including arguments involving expanded action output directories. However, [Args](/versions/7.7.1/rules/lib/builtins/Args) objects are not readable in the analysis phase. For a less accurate account of arguments which is available in the analysis phase, see [argv](#argv).
 
 Note that some types of actions do not yet support exposure of this field. For such action types, this is `None`.
 May return `None`.
@@ -36,7 +36,7 @@ May return `None`.
 sequence Action.argv
 ```
 
-For actions created by [ctx.actions.run()](../builtins/actions#run) or [ctx.actions.run\_shell()](../builtins/actions#run_shell) an immutable list of the arguments for the command line to be executed. Note that for shell actions the first two arguments will be the shell path and `"-c"`.
+For actions created by [ctx.actions.run()](/versions/7.7.1/rules/lib/builtins/actions#run) or [ctx.actions.run\_shell()](/versions/7.7.1/rules/lib/builtins/actions#run_shell) an immutable list of the arguments for the command line to be executed. Note that for shell actions the first two arguments will be the shell path and `"-c"`.
 May return `None`.
 
 ## content
@@ -45,7 +45,7 @@ May return `None`.
 string Action.content
 ```
 
-For actions created by [ctx.actions.write()](../builtins/actions#write) or [ctx.actions.expand\_template()](../builtins/actions#expand_template), the contents of the file to be written, if those contents can be computed during the analysis phase. The value is `None` if the contents cannot be determined until the execution phase, such as when a directory in an [Args](../builtins/Args) object needs to be expanded.
+For actions created by [ctx.actions.write()](/versions/7.7.1/rules/lib/builtins/actions#write) or [ctx.actions.expand\_template()](/versions/7.7.1/rules/lib/builtins/actions#expand_template), the contents of the file to be written, if those contents can be computed during the analysis phase. The value is `None` if the contents cannot be determined until the execution phase, such as when a directory in an [Args](/versions/7.7.1/rules/lib/builtins/Args) object needs to be expanded.
 May return `None`.
 
 ## env
@@ -86,5 +86,5 @@ A set of the output files of this action.
 dict Action.substitutions
 ```
 
-For actions created by [ctx.actions.expand\_template()](../builtins/actions#expand_template), an immutable dict holding the substitution mapping.
+For actions created by [ctx.actions.expand\_template()](/versions/7.7.1/rules/lib/builtins/actions#expand_template), an immutable dict holding the substitution mapping.
 May return `None`.
\ No newline at end of file
diff --git a/versions/7.7.1/rules/lib/builtins/Args.mdx b/versions/7.7.1/rules/lib/builtins/Args.mdx
index 79a18228..bda9cdb4 100644
--- a/versions/7.7.1/rules/lib/builtins/Args.mdx
+++ b/versions/7.7.1/rules/lib/builtins/Args.mdx
@@ -4,15 +4,15 @@ title: 'Args'
 
 An object that encapsulates, in a memory-efficient way, the data needed to build part or all of a command line.
 
-It often happens that an action requires a large command line containing values accumulated from transitive dependencies. For example, a linker command line might list every object file needed by all of the libraries being linked. It is best practice to store such transitive data in [`depset`](../builtins/depset)s, so that they can be shared by multiple targets. However, if the rule author had to convert these depsets into lists of strings in order to construct an action command line, it would defeat this memory-sharing optimization.
+It often happens that an action requires a large command line containing values accumulated from transitive dependencies. For example, a linker command line might list every object file needed by all of the libraries being linked. It is best practice to store such transitive data in [`depset`](/versions/7.7.1/rules/lib/builtins/depset)s, so that they can be shared by multiple targets. However, if the rule author had to convert these depsets into lists of strings in order to construct an action command line, it would defeat this memory-sharing optimization.
 
 For this reason, the action-constructing functions accept `Args` objects in addition to strings. Each `Args` object represents a concatenation of strings and depsets, with optional transformations for manipulating the data. `Args` objects do not process the depsets they encapsulate until the execution phase, when it comes time to calculate the command line. This helps defer any expensive copying until after the analysis phase is complete. See the [Optimizing Performance](https://bazel.build/versions/7.7.1/rules/performance) page for more information.
 
-`Args` are constructed by calling [`ctx.actions.args()`](../builtins/actions#args). They can be passed as the `arguments` parameter of [`ctx.actions.run()`](../builtins/actions#run) or [`ctx.actions.run_shell()`](../builtins/actions#run_shell). Each mutation of an `Args` object appends values to the eventual command line.
+`Args` are constructed by calling [`ctx.actions.args()`](/versions/7.7.1/rules/lib/builtins/actions#args). They can be passed as the `arguments` parameter of [`ctx.actions.run()`](/versions/7.7.1/rules/lib/builtins/actions#run) or [`ctx.actions.run_shell()`](/versions/7.7.1/rules/lib/builtins/actions#run_shell). Each mutation of an `Args` object appends values to the eventual command line.
 
 The `map_each` feature allows you to customize how items are transformed into strings. If you do not provide a `map_each` function, the standard conversion is as follows:
 
-* Values that are already strings are left as-is.* [`File`](../builtins/File) objects are turned into their `File.path` values.* [`Label`](../builtins/Label) objects are turned into a string representation that resolves back to the same object when resolved in the context of the main repository. If possible, the string representation uses the apparent name of a repository in favor of the repository's canonical name, which makes this representation suited for use in BUILD files. While the exact form of the representation is not guaranteed, typical examples are `//foo:bar`, `@repo//foo:bar` and `@@canonical_name~//foo:bar.bzl`.* All other types are turned into strings in an *unspecified* manner. For this reason, you should avoid passing values that are not of string or `File` type to `add()`, and if you pass them to `add_all()` or `add_joined()` then you should provide a `map_each` function.
+* Values that are already strings are left as-is.* [`File`](/versions/7.7.1/rules/lib/builtins/File) objects are turned into their `File.path` values.* [`Label`](/versions/7.7.1/rules/lib/builtins/Label) objects are turned into a string representation that resolves back to the same object when resolved in the context of the main repository. If possible, the string representation uses the apparent name of a repository in favor of the repository's canonical name, which makes this representation suited for use in BUILD files. While the exact form of the representation is not guaranteed, typical examples are `//foo:bar`, `@repo//foo:bar` and `@@canonical_name~//foo:bar.bzl`.* All other types are turned into strings in an *unspecified* manner. For this reason, you should avoid passing values that are not of string or `File` type to `add()`, and if you pass them to `add_all()` or `add_joined()` then you should provide a `map_each` function.
 
 When using string formatting (`format`, `format_each`, and `format_joined` params of the `add*()` methods), the format template is interpreted in the same way as `%`-substitution on strings, except that the template must have exactly one substitution placeholder and it must be `%s`. Literal percents may be escaped as `%%`. Formatting is applied after the value is converted to a string as per the above.
 
@@ -64,7 +64,7 @@ Appends an argument to this command line.
 | --- | --- |
 | `arg_name_or_value` | required  If two positional parameters are passed this is interpreted as the arg name. The arg name is added before the value without any processing. If only one positional parameter is passed, it is interpreted as `value` (see below). |
 | `value` | default is `unbound`  The object to append. It will be converted to a string using the standard conversion mentioned above. Since there is no `map_each` parameter for this function, `value` should be either a string or a `File`. A list, tuple, depset, or directory `File` must be passed to [`add_all()` or [`add_joined()`](#add_joined) instead of this method.](#add_all) |
-| `format` | [string](../core/string); or `None`; default is `None`  A format string pattern, to be applied to the stringified version of `value`. |
+| `format` | [string](/versions/7.7.1/rules/lib/core/string); or `None`; default is `None`  A format string pattern, to be applied to the stringified version of `value`. |
 
 ## add\_all
 
@@ -86,14 +86,14 @@ Note that empty strings are valid arguments that are subject to all these proces
 | Parameter | Description |
 | --- | --- |
 | `arg_name_or_values` | required  If two positional parameters are passed this is interpreted as the arg name. The arg name is added before the `values` as a separate argument without any processing. This arg name will not be added if `omit_if_empty` is true (the default) and no other items are appended (as happens if `values` is empty or all of its items are filtered). If only one positional parameter is passed, it is interpreted as `values` (see below). |
-| `values` | [sequence](../core/list); or [depset](../builtins/depset); default is `unbound`  The list, tuple, or depset whose items will be appended. |
-| `map_each` | callable; or `None`; default is `None`  A function that converts each item to zero or more strings, which may be further processed before appending. If this param is not provided, the standard conversion is used. The function is passed either one or two positional arguments: the item to convert, followed by an optional [`DirectoryExpander`](../builtins/DirectoryExpander). The second argument will be passed only if the supplied function is user-defined (not built-in) and declares more than one parameter. The return value's type depends on how many arguments are to be produced for the item:  * In the common case when each item turns into one string, the function should return that string.* If the item is to be filtered out entirely, the function should return `None`.* If the item turns into multiple strings, the function returns a list of those strings.  Returning a single string or `None` has the same effect as returning a list of length 1 or length 0 respectively. However, it is more efficient and readable to avoid creating a list where it is not needed. Ordinarily, items that are directories are automatically expanded to their contents when `expand_directories=True` is set. However, this will not expand directories contained inside other values -- for instance, when the items are structs that have directories as fields. In this situation, the `DirectoryExpander` argument can be applied to manually obtain the files of a given directory. To avoid unintended retention of large analysis-phase data structures into the execution phase, the `map_each` function must be declared by a top-level `def` statement; it may not be a nested function closure by default. *Warning:* [`print()`](../globals/all#print) statements that are executed during the call to `map_each` will not produce any visible output. |
-| `format_each` | [string](../core/string); or `None`; default is `None`  An optional format string pattern, applied to each string returned by the `map_each` function. The format string must have exactly one '%s' placeholder. |
-| `before_each` | [string](../core/string); or `None`; default is `None`  An optional argument to append before each argument derived from `values` is appended. |
+| `values` | [sequence](/versions/7.7.1/rules/lib/core/list); or [depset](/versions/7.7.1/rules/lib/builtins/depset); default is `unbound`  The list, tuple, or depset whose items will be appended. |
+| `map_each` | callable; or `None`; default is `None`  A function that converts each item to zero or more strings, which may be further processed before appending. If this param is not provided, the standard conversion is used. The function is passed either one or two positional arguments: the item to convert, followed by an optional [`DirectoryExpander`](/versions/7.7.1/rules/lib/builtins/DirectoryExpander). The second argument will be passed only if the supplied function is user-defined (not built-in) and declares more than one parameter. The return value's type depends on how many arguments are to be produced for the item:  * In the common case when each item turns into one string, the function should return that string.* If the item is to be filtered out entirely, the function should return `None`.* If the item turns into multiple strings, the function returns a list of those strings.  Returning a single string or `None` has the same effect as returning a list of length 1 or length 0 respectively. However, it is more efficient and readable to avoid creating a list where it is not needed. Ordinarily, items that are directories are automatically expanded to their contents when `expand_directories=True` is set. However, this will not expand directories contained inside other values -- for instance, when the items are structs that have directories as fields. In this situation, the `DirectoryExpander` argument can be applied to manually obtain the files of a given directory. To avoid unintended retention of large analysis-phase data structures into the execution phase, the `map_each` function must be declared by a top-level `def` statement; it may not be a nested function closure by default. *Warning:* [`print()`](/versions/7.7.1/rules/lib/globals/all#print) statements that are executed during the call to `map_each` will not produce any visible output. |
+| `format_each` | [string](/versions/7.7.1/rules/lib/core/string); or `None`; default is `None`  An optional format string pattern, applied to each string returned by the `map_each` function. The format string must have exactly one '%s' placeholder. |
+| `before_each` | [string](/versions/7.7.1/rules/lib/core/string); or `None`; default is `None`  An optional argument to append before each argument derived from `values` is appended. |
 | `omit_if_empty` | default is `True`  If true, if there are no arguments derived from `values` to be appended, then all further processing is suppressed and the command line will be unchanged. If false, the arg name and `terminate_with`, if provided, will still be appended regardless of whether or not there are other arguments. |
 | `uniquify` | default is `False`  If true, duplicate arguments that are derived from `values` will be omitted. Only the first occurrence of each argument will remain. Usually this feature is not needed because depsets already omit duplicates, but it can be useful if `map_each` emits the same string for multiple items. |
 | `expand_directories` | default is `True`  If true, any directories in `values` will be expanded to a flat list of files. This happens before `map_each` is applied. |
-| `terminate_with` | [string](../core/string); or `None`; default is `None`  An optional argument to append after all other arguments. This argument will not be added if `omit_if_empty` is true (the default) and no other items are appended (as happens if `values` is empty or all of its items are filtered). |
+| `terminate_with` | [string](/versions/7.7.1/rules/lib/core/string); or `None`; default is `None`  An optional argument to append after all other arguments. This argument will not be added if `omit_if_empty` is true (the default) and no other items are appended (as happens if `values` is empty or all of its items are filtered). |
 | `allow_closure` | default is `False`  If true, allows the use of closures in function parameters like `map_each`. Usually this isn't necessary and it risks retaining large analysis-phase data structures into the execution phase. |
 
 ## add\_joined
@@ -113,11 +113,11 @@ If after filtering there are no strings to join into an argument, and if `omit_i
 | Parameter | Description |
 | --- | --- |
 | `arg_name_or_values` | required  If two positional parameters are passed this is interpreted as the arg name. The arg name is added before `values` without any processing. This arg will not be added if `omit_if_empty` is true (the default) and there are no strings derived from `values` to join together (which can happen if `values` is empty or all of its items are filtered). If only one positional parameter is passed, it is interpreted as `values` (see below). |
-| `values` | [sequence](../core/list); or [depset](../builtins/depset); default is `unbound`  The list, tuple, or depset whose items will be joined. |
-| `join_with` | required  A delimiter string used to join together the strings obtained from applying `map_each` and `format_each`, in the same manner as [`string.join()`](../core/string#join). |
+| `values` | [sequence](/versions/7.7.1/rules/lib/core/list); or [depset](/versions/7.7.1/rules/lib/builtins/depset); default is `unbound`  The list, tuple, or depset whose items will be joined. |
+| `join_with` | required  A delimiter string used to join together the strings obtained from applying `map_each` and `format_each`, in the same manner as [`string.join()`](/versions/7.7.1/rules/lib/core/string#join). |
 | `map_each` | callable; or `None`; default is `None`  Same as for [`add_all`](#add_all.map_each). |
-| `format_each` | [string](../core/string); or `None`; default is `None`  Same as for [`add_all`](#add_all.format_each). |
-| `format_joined` | [string](../core/string); or `None`; default is `None`  An optional format string pattern applied to the joined string. The format string must have exactly one '%s' placeholder. |
+| `format_each` | [string](/versions/7.7.1/rules/lib/core/string); or `None`; default is `None`  Same as for [`add_all`](#add_all.format_each). |
+| `format_joined` | [string](/versions/7.7.1/rules/lib/core/string); or `None`; default is `None`  An optional format string pattern applied to the joined string. The format string must have exactly one '%s' placeholder. |
 | `omit_if_empty` | default is `True`  If true, if there are no strings to join together (either because `values` is empty or all its items are filtered), then all further processing is suppressed and the command line will be unchanged. If false, then even if there are no strings to join together, two arguments will be appended: the arg name followed by an empty string (which is the logical join of zero strings). |
 | `uniquify` | default is `False`  Same as for [`add_all`](#add_all.uniquify). |
 | `expand_directories` | default is `True`  Same as for [`add_all`](#add_all.expand_directories). |
diff --git a/versions/7.7.1/rules/lib/builtins/Aspect.mdx b/versions/7.7.1/rules/lib/builtins/Aspect.mdx
index b2871aec..bda09dd6 100644
--- a/versions/7.7.1/rules/lib/builtins/Aspect.mdx
+++ b/versions/7.7.1/rules/lib/builtins/Aspect.mdx
@@ -2,4 +2,4 @@
 title: 'Aspect'
 ---
 
-For more information about Aspects, please consult the [documentation of the aspect function](../globals/bzl#aspect) or the [introduction to Aspects](https://bazel.build/versions/7.7.1/rules/aspects).
\ No newline at end of file
+For more information about Aspects, please consult the [documentation of the aspect function](/versions/7.7.1/rules/lib/globals/bzl#aspect) or the [introduction to Aspects](https://bazel.build/versions/7.7.1/rules/aspects).
\ No newline at end of file
diff --git a/versions/7.7.1/rules/lib/builtins/Attribute.mdx b/versions/7.7.1/rules/lib/builtins/Attribute.mdx
index 18486c41..c44de641 100644
--- a/versions/7.7.1/rules/lib/builtins/Attribute.mdx
+++ b/versions/7.7.1/rules/lib/builtins/Attribute.mdx
@@ -2,4 +2,4 @@
 title: 'Attribute'
 ---
 
-Representation of a definition of an attribute. Use the [attr](../toplevel/attr) module to create an Attribute. They are only for use with a [rule](../globals/bzl#rule) or an [aspect](../globals/bzl#aspect).
\ No newline at end of file
+Representation of a definition of an attribute. Use the [attr](/versions/7.7.1/rules/lib/toplevel/attr) module to create an Attribute. They are only for use with a [rule](/versions/7.7.1/rules/lib/globals/bzl#rule) or an [aspect](/versions/7.7.1/rules/lib/globals/bzl#aspect).
\ No newline at end of file
diff --git a/versions/7.7.1/rules/lib/builtins/DirectoryExpander.mdx b/versions/7.7.1/rules/lib/builtins/DirectoryExpander.mdx
index 43068d41..93881f4d 100644
--- a/versions/7.7.1/rules/lib/builtins/DirectoryExpander.mdx
+++ b/versions/7.7.1/rules/lib/builtins/DirectoryExpander.mdx
@@ -2,7 +2,7 @@
 title: 'DirectoryExpander'
 ---
 
-Expands directories created by [`ctx.actions.declare_directory`](../builtins/actions#declare_directory) during the execution phase. This is useful to expand directories in [`map_each`](../builtins/Args#add_all.map_each).
+Expands directories created by [`ctx.actions.declare_directory`](/versions/7.7.1/rules/lib/builtins/actions#declare_directory) during the execution phase. This is useful to expand directories in [`map_each`](/versions/7.7.1/rules/lib/builtins/Args#add_all.map_each).
 
 ## Members
 
diff --git a/versions/7.7.1/rules/lib/builtins/File.mdx b/versions/7.7.1/rules/lib/builtins/File.mdx
index fd5bd93b..637074f4 100644
--- a/versions/7.7.1/rules/lib/builtins/File.mdx
+++ b/versions/7.7.1/rules/lib/builtins/File.mdx
@@ -4,7 +4,7 @@ title: 'File'
 
 This object is created during the analysis phase to represent a file or directory that will be read or written during the execution phase. It is not an open file handle, and cannot be used to directly read or write file contents. Rather, you use it to construct the action graph in a rule implementation function by passing it to action-creating functions. See the [Rules page](https://bazel.build/versions/7.7.1/extending/rules#files) for more information.
 
-When a `File` is passed to an [`Args`](../builtins/Args) object without using a `map_each` function, it is converted to a string by taking the value of its `path` field.
+When a `File` is passed to an [`Args`](/versions/7.7.1/rules/lib/builtins/Args) object without using a `map_each` function, it is converted to a string by taking the value of its `path` field.
 
 ## Members
 
@@ -74,7 +74,7 @@ May return `None`.
 string File.path
 ```
 
-The execution path of this file, relative to the workspace's execution directory. It consists of two parts, an optional first part called the *root* (see also the [root](../builtins/root) module), and the second part which is the `short_path`. The root may be empty, which it usually is for non-generated files. For generated files it usually contains a configuration-specific path fragment that encodes things like the target CPU architecture that was used while building said file. Use the `short_path` for the path under which the file is mapped if it's in the runfiles of a binary.
+The execution path of this file, relative to the workspace's execution directory. It consists of two parts, an optional first part called the *root* (see also the [root](/versions/7.7.1/rules/lib/builtins/root) module), and the second part which is the `short_path`. The root may be empty, which it usually is for non-generated files. For generated files it usually contains a configuration-specific path fragment that encodes things like the target CPU architecture that was used while building said file. Use the `short_path` for the path under which the file is mapped if it's in the runfiles of a binary.
 
 ## root
 
@@ -98,4 +98,4 @@ The path of this file relative to its root. This excludes the aforementioned *ro
 string File.tree_relative_path
 ```
 
-The path of this file relative to the root of the ancestor's tree, if the ancestor's [is\_directory](#is_directory) field is true. `tree_relative_path` is only available for expanded files of a directory in an action command, i.e. [Args.add\_all()](../builtins/Args#add_all). For other types of files, it is an error to access this field.
\ No newline at end of file
+The path of this file relative to the root of the ancestor's tree, if the ancestor's [is\_directory](#is_directory) field is true. `tree_relative_path` is only available for expanded files of a directory in an action command, i.e. [Args.add\_all()](/versions/7.7.1/rules/lib/builtins/Args#add_all). For other types of files, it is an error to access this field.
\ No newline at end of file
diff --git a/versions/7.7.1/rules/lib/builtins/Label.mdx b/versions/7.7.1/rules/lib/builtins/Label.mdx
index 3652e0a3..4ea18d33 100644
--- a/versions/7.7.1/rules/lib/builtins/Label.mdx
+++ b/versions/7.7.1/rules/lib/builtins/Label.mdx
@@ -33,7 +33,7 @@ For macros, a related function, `native.package_relative_label()`, converts the
 
 | Parameter | Description |
 | --- | --- |
-| `input` | [string](../core/string); or [Label](../builtins/Label); required  The input label string or Label object. If a Label object is passed, it's returned as is. |
+| `input` | [string](/versions/7.7.1/rules/lib/core/string); or [Label](/versions/7.7.1/rules/lib/builtins/Label); required  The input label string or Label object. If a Label object is passed, it's returned as is. |
 
 ## name
 
@@ -66,7 +66,7 @@ Label Label.relative(relName)
 ```
 
 **Experimental**. This API is experimental and may change at any time. Please do not depend on it. It may be enabled on an experimental basis by setting `--+incompatible_enable_deprecated_label_apis`
-**Deprecated.** This method behaves surprisingly when used with an argument containing an apparent repo name. Prefer [`Label.same_package_label()`](#local_target_label), [`native.package_relative_label()`](../toplevel/native#package_relative_label), or [`Label()`](#Label) instead.
+**Deprecated.** This method behaves surprisingly when used with an argument containing an apparent repo name. Prefer [`Label.same_package_label()`](#local_target_label), [`native.package_relative_label()`](/versions/7.7.1/rules/lib/toplevel/native#package_relative_label), or [`Label()`](#Label) instead.
 
 Resolves a label that is either absolute (starts with `//`) or relative to the current package. If this label is in a remote repository, the argument will be resolved relative to that repository. If the argument contains a repository name, the current label is ignored and the argument is returned as-is, except that the repository name is rewritten if it is in the current repository mapping. Reserved labels will also be returned as-is.
 For example:
diff --git a/versions/7.7.1/rules/lib/builtins/LateBoundDefault.mdx b/versions/7.7.1/rules/lib/builtins/LateBoundDefault.mdx
index edd0010c..49311607 100644
--- a/versions/7.7.1/rules/lib/builtins/LateBoundDefault.mdx
+++ b/versions/7.7.1/rules/lib/builtins/LateBoundDefault.mdx
@@ -4,4 +4,4 @@ title: 'LateBoundDefault'
 
 Represents a late-bound default attribute value of type 'Label'. The value of a LateBoundDefault is only resolvable in the context of a rule implementation function, and depends on the current build configuration. For example, a LateBoundDefault might represent the Label of the java toolchain in the current build configuration.
 
-See [configuration\_field](../globals/bzl#configuration_field) for example usage.
\ No newline at end of file
+See [configuration\_field](/versions/7.7.1/rules/lib/globals/bzl#configuration_field) for example usage.
\ No newline at end of file
diff --git a/versions/7.7.1/rules/lib/builtins/Provider.mdx b/versions/7.7.1/rules/lib/builtins/Provider.mdx
index 54b9cf36..d7039471 100644
--- a/versions/7.7.1/rules/lib/builtins/Provider.mdx
+++ b/versions/7.7.1/rules/lib/builtins/Provider.mdx
@@ -14,7 +14,7 @@ This value has a dual purpose:
   ```
 
   Note: Some providers, defined internally, do not allow instance creation
-* It is a *key* to access a provider instance on a [Target](../builtins/Target)
+* It is a *key* to access a provider instance on a [Target](/versions/7.7.1/rules/lib/builtins/Target)
 
   ```
   DataInfo = provider()
@@ -22,4 +22,4 @@ This value has a dual purpose:
     ... ctx.attr.dep[DataInfo]
   ```
 
-Create a new `Provider` using the [provider](../globals/bzl#provider) function.
\ No newline at end of file
+Create a new `Provider` using the [provider](/versions/7.7.1/rules/lib/globals/bzl#provider) function.
\ No newline at end of file
diff --git a/versions/7.7.1/rules/lib/builtins/TemplateDict.mdx b/versions/7.7.1/rules/lib/builtins/TemplateDict.mdx
index 96a5f7a6..6016da19 100644
--- a/versions/7.7.1/rules/lib/builtins/TemplateDict.mdx
+++ b/versions/7.7.1/rules/lib/builtins/TemplateDict.mdx
@@ -37,9 +37,9 @@ Add depset of values
 | Parameter | Description |
 | --- | --- |
 | `key` | required  A String key |
-| `values` | [depset](../builtins/depset); required  The depset whose items will be joined. |
-| `join_with` | required  A delimiter string used to join together the strings obtained from applying `map_each`, in the same manner as [`string.join()`](../core/string#join). |
+| `values` | [depset](/versions/7.7.1/rules/lib/builtins/depset); required  The depset whose items will be joined. |
+| `join_with` | required  A delimiter string used to join together the strings obtained from applying `map_each`, in the same manner as [`string.join()`](/versions/7.7.1/rules/lib/core/string#join). |
 | `map_each` | callable; required  A Starlark function accepting a single argument and returning either a string, `None`, or a list of strings. This function is applied to each item of the depset specified in the `values` parameter |
 | `uniquify` | default is `False`  If true, duplicate strings derived from `values` will be omitted. Only the first occurrence of each string will remain. Usually this feature is not needed because depsets already omit duplicates, but it can be useful if `map_each` emits the same string for multiple items. |
-| `format_joined` | [string](../core/string); or `None`; default is `None`  An optional format string pattern applied to the joined string. The format string must have exactly one '%s' placeholder. |
+| `format_joined` | [string](/versions/7.7.1/rules/lib/core/string); or `None`; default is `None`  An optional format string pattern applied to the joined string. The format string must have exactly one '%s' placeholder. |
 | `allow_closure` | default is `False`  If true, allows the use of closures in function parameters like `map_each`. Usually this isn't necessary and it risks retaining large analysis-phase data structures into the execution phase. |
\ No newline at end of file
diff --git a/versions/7.7.1/rules/lib/builtins/actions.mdx b/versions/7.7.1/rules/lib/builtins/actions.mdx
index 089e437c..7b2d548d 100644
--- a/versions/7.7.1/rules/lib/builtins/actions.mdx
+++ b/versions/7.7.1/rules/lib/builtins/actions.mdx
@@ -2,7 +2,7 @@
 title: 'actions'
 ---
 
-Module providing functions to create actions. Access this module using [`ctx.actions`](../builtins/ctx#actions).
+Module providing functions to create actions. Access this module using [`ctx.actions`](/versions/7.7.1/rules/lib/builtins/ctx#actions).
 
 ## Members
 
@@ -32,14 +32,14 @@ Returns an Args object that can be used to build memory-efficient command lines.
 File actions.declare_directory(filename, *, sibling=None)
 ```
 
-Declares that the rule or aspect creates a directory with the given name, in the current package. You must create an action that generates the directory. The contents of the directory are not directly accessible from Starlark, but can be expanded in an action command with [`Args.add_all()`](../builtins/Args#add_all). Only regular files and directories can be in the expanded contents of a declare\_directory.
+Declares that the rule or aspect creates a directory with the given name, in the current package. You must create an action that generates the directory. The contents of the directory are not directly accessible from Starlark, but can be expanded in an action command with [`Args.add_all()`](/versions/7.7.1/rules/lib/builtins/Args#add_all). Only regular files and directories can be in the expanded contents of a declare\_directory.
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
 | `filename` | required  If no 'sibling' provided, path of the new directory, relative to the current package. Otherwise a base name for a file ('sibling' defines a directory). |
-| `sibling` | [File](../builtins/File); or `None`; default is `None`  A file that lives in the same directory as the newly declared directory. The file must be in the current package. |
+| `sibling` | [File](/versions/7.7.1/rules/lib/builtins/File); or `None`; default is `None`  A file that lives in the same directory as the newly declared directory. The file must be in the current package. |
 
 ## declare\_file
 
@@ -51,14 +51,14 @@ Declares that the rule or aspect creates a file with the given filename. If `sib
 
 Remember that in addition to declaring a file, you must separately create an action that emits the file. Creating that action will require passing the returned `File` object to the action's construction function.
 
-Note that [predeclared output files](https://bazel.build/versions/7.7.1/extending/rules#files) do not need to be (and cannot be) declared using this function. You can obtain their `File` objects from [`ctx.outputs`](../builtins/ctx#outputs) instead. [See example of use](https://github.com/bazelbuild/examples/tree/main/rules/computed_dependencies/hash.bzl).
+Note that [predeclared output files](https://bazel.build/versions/7.7.1/extending/rules#files) do not need to be (and cannot be) declared using this function. You can obtain their `File` objects from [`ctx.outputs`](/versions/7.7.1/rules/lib/builtins/ctx#outputs) instead. [See example of use](https://github.com/bazelbuild/examples/tree/main/rules/computed_dependencies/hash.bzl).
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
 | `filename` | required  If no 'sibling' provided, path of the new file, relative to the current package. Otherwise a base name for a file ('sibling' determines a directory). |
-| `sibling` | [File](../builtins/File); or `None`; default is `None`  A file that lives in the same directory as the newly created file. The file must be in the current package. |
+| `sibling` | [File](/versions/7.7.1/rules/lib/builtins/File); or `None`; default is `None`  A file that lives in the same directory as the newly created file. The file must be in the current package. |
 
 ## declare\_symlink
 
@@ -73,7 +73,7 @@ Declares that the rule or aspect creates a symlink with the given name in the cu
 | Parameter | Description |
 | --- | --- |
 | `filename` | required  If no 'sibling' provided, path of the new symlink, relative to the current package. Otherwise a base name for a file ('sibling' defines a directory). |
-| `sibling` | [File](../builtins/File); or `None`; default is `None`  A file that lives in the same directory as the newly declared symlink. |
+| `sibling` | [File](/versions/7.7.1/rules/lib/builtins/File); or `None`; default is `None`  A file that lives in the same directory as the newly declared symlink. |
 
 ## do\_nothing
 
@@ -88,7 +88,7 @@ Creates an empty action that neither executes a command nor produces any output,
 | Parameter | Description |
 | --- | --- |
 | `mnemonic` | required  A one-word description of the action, for example, CppCompile or GoLink. |
-| `inputs` | [sequence](../core/list) of [File](../builtins/File)s; or [depset](../builtins/depset); default is `[]`  List of the input files of the action. |
+| `inputs` | [sequence](/versions/7.7.1/rules/lib/core/list) of [File](/versions/7.7.1/rules/lib/builtins/File)s; or [depset](/versions/7.7.1/rules/lib/builtins/depset); default is `[]`  List of the input files of the action. |
 
 ## expand\_template
 
@@ -106,7 +106,7 @@ Creates a template expansion action. When the action is executed, it will genera
 | `output` | required  The output file, which is a UTF-8 encoded text file. |
 | `substitutions` | default is `{}`  Substitutions to make when expanding the template. |
 | `is_executable` | default is `False`  Whether the output file should be executable. |
-| `computed_substitutions` | [TemplateDict](../builtins/TemplateDict); default is `unbound`  Substitutions to make when expanding the template. |
+| `computed_substitutions` | [TemplateDict](/versions/7.7.1/rules/lib/builtins/TemplateDict); default is `unbound`  Substitutions to make when expanding the template. |
 
 ## run
 
@@ -120,22 +120,22 @@ Creates an action that runs an executable. [See example of use](https://github.c
 
 | Parameter | Description |
 | --- | --- |
-| `outputs` | [sequence](../core/list) of [File](../builtins/File)s; required  List of the output files of the action. |
-| `inputs` | [sequence](../core/list) of [File](../builtins/File)s; or [depset](../builtins/depset); default is `[]`  List or depset of the input files of the action. |
-| `unused_inputs_list` | [File](../builtins/File); or `None`; default is `None`  File containing list of inputs unused by the action. The content of this file (generally one of the outputs of the action) corresponds to the list of input files that were not used during the whole action execution. Any change in those files must not affect in any way the outputs of the action. |
-| `executable` | [File](../builtins/File); or [string](../core/string); or [FilesToRunProvider](../providers/FilesToRunProvider); required  The executable file to be called by the action. |
-| `tools` | [sequence](../core/list); or [depset](../builtins/depset); default is `unbound`  List or depset of any tools needed by the action. Tools are inputs with additional runfiles that are automatically made available to the action. When a list is provided, it can be a heterogenous collection of Files, FilesToRunProvider instances, or depsets of Files. Files which are directly in the list and come from ctx.executable will have their runfiles automatically added. When a depset is provided, it must contain only Files. In both cases, files within depsets are not cross-referenced with ctx.executable for runfiles. |
-| `arguments` | [sequence](../core/list); default is `[]`  Command line arguments of the action. Must be a list of strings or [`actions.args()`](#args) objects. |
-| `mnemonic` | [string](../core/string); or `None`; default is `None`  A one-word description of the action, for example, CppCompile or GoLink. |
-| `progress_message` | [string](../core/string); or `None`; default is `None`  Progress message to show to the user during the build, for example, "Compiling foo.cc to create foo.o". The message may contain `%{label}`, `%{input}`, or `%{output}` patterns, which are substituted with label string, first input, or output's path, respectively. Prefer to use patterns instead of static strings, because the former are more efficient. |
+| `outputs` | [sequence](/versions/7.7.1/rules/lib/core/list) of [File](/versions/7.7.1/rules/lib/builtins/File)s; required  List of the output files of the action. |
+| `inputs` | [sequence](/versions/7.7.1/rules/lib/core/list) of [File](/versions/7.7.1/rules/lib/builtins/File)s; or [depset](/versions/7.7.1/rules/lib/builtins/depset); default is `[]`  List or depset of the input files of the action. |
+| `unused_inputs_list` | [File](/versions/7.7.1/rules/lib/builtins/File); or `None`; default is `None`  File containing list of inputs unused by the action. The content of this file (generally one of the outputs of the action) corresponds to the list of input files that were not used during the whole action execution. Any change in those files must not affect in any way the outputs of the action. |
+| `executable` | [File](/versions/7.7.1/rules/lib/builtins/File); or [string](/versions/7.7.1/rules/lib/core/string); or [FilesToRunProvider](/versions/7.7.1/rules/lib/providers/FilesToRunProvider); required  The executable file to be called by the action. |
+| `tools` | [sequence](/versions/7.7.1/rules/lib/core/list); or [depset](/versions/7.7.1/rules/lib/builtins/depset); default is `unbound`  List or depset of any tools needed by the action. Tools are inputs with additional runfiles that are automatically made available to the action. When a list is provided, it can be a heterogenous collection of Files, FilesToRunProvider instances, or depsets of Files. Files which are directly in the list and come from ctx.executable will have their runfiles automatically added. When a depset is provided, it must contain only Files. In both cases, files within depsets are not cross-referenced with ctx.executable for runfiles. |
+| `arguments` | [sequence](/versions/7.7.1/rules/lib/core/list); default is `[]`  Command line arguments of the action. Must be a list of strings or [`actions.args()`](#args) objects. |
+| `mnemonic` | [string](/versions/7.7.1/rules/lib/core/string); or `None`; default is `None`  A one-word description of the action, for example, CppCompile or GoLink. |
+| `progress_message` | [string](/versions/7.7.1/rules/lib/core/string); or `None`; default is `None`  Progress message to show to the user during the build, for example, "Compiling foo.cc to create foo.o". The message may contain `%{label}`, `%{input}`, or `%{output}` patterns, which are substituted with label string, first input, or output's path, respectively. Prefer to use patterns instead of static strings, because the former are more efficient. |
 | `use_default_shell_env` | default is `False`  Whether the action should use the default shell environment, which consists of a few OS-dependent variables as well as variables set via [`--action_env`](/versions/7.7.1/reference/command-line-reference#flag--action_env). If both `use_default_shell_env` and `env` are set to `True`, values set in `env` will overwrite the default shell environment if [`--incompatible_merge_fixed_and_default_shell_env`](/versions/7.7.1/reference/command-line-reference#flag--incompatible_merge_fixed_and_default_shell_env) is enabled (default). If the flag is not enabled, `env` is ignored. |
-| `env` | [dict](../core/dict); or `None`; default is `None`  Sets the dictionary of environment variables. If both `use_default_shell_env` and `env` are set to `True`, values set in `env` will overwrite the default shell environment if [`--incompatible_merge_fixed_and_default_shell_env`](/versions/7.7.1/reference/command-line-reference#flag--incompatible_merge_fixed_and_default_shell_env) is enabled (default). If the flag is not enabled, `env` is ignored. |
-| `execution_requirements` | [dict](../core/dict); or `None`; default is `None`  Information for scheduling the action. See [tags](/versions/7.7.1/reference/be/common-definitions#common.tags) for useful keys. |
-| `input_manifests` | [sequence](../core/list); or `None`; default is `None`  (Experimental) sets the input runfiles metadata; they are typically generated by resolve\_command. |
-| `exec_group` | [string](../core/string); or `None`; default is `None`  Runs the action on the given exec group's execution platform. If none, uses the target's default execution platform. |
-| `shadowed_action` | [Action](../builtins/Action); default is `None`  Runs the action using the given shadowed action's inputs and environment added to the action's inputs list and environment. The action environment can overwrite any of the shadowed action's environment variables. If none, uses only the action's inputs and given environment. |
+| `env` | [dict](/versions/7.7.1/rules/lib/core/dict); or `None`; default is `None`  Sets the dictionary of environment variables. If both `use_default_shell_env` and `env` are set to `True`, values set in `env` will overwrite the default shell environment if [`--incompatible_merge_fixed_and_default_shell_env`](/versions/7.7.1/reference/command-line-reference#flag--incompatible_merge_fixed_and_default_shell_env) is enabled (default). If the flag is not enabled, `env` is ignored. |
+| `execution_requirements` | [dict](/versions/7.7.1/rules/lib/core/dict); or `None`; default is `None`  Information for scheduling the action. See [tags](/versions/7.7.1/reference/be/common-definitions#common.tags) for useful keys. |
+| `input_manifests` | [sequence](/versions/7.7.1/rules/lib/core/list); or `None`; default is `None`  (Experimental) sets the input runfiles metadata; they are typically generated by resolve\_command. |
+| `exec_group` | [string](/versions/7.7.1/rules/lib/core/string); or `None`; default is `None`  Runs the action on the given exec group's execution platform. If none, uses the target's default execution platform. |
+| `shadowed_action` | [Action](/versions/7.7.1/rules/lib/builtins/Action); default is `None`  Runs the action using the given shadowed action's inputs and environment added to the action's inputs list and environment. The action environment can overwrite any of the shadowed action's environment variables. If none, uses only the action's inputs and given environment. |
 | `resource_set` | callable; or `None`; default is `None`  A callback function that returns a resource set dictionary, used to estimate resource usage at execution time if this action is run locally. The function accepts two positional arguments: a string representing an OS name (e.g. "osx"), and an integer representing the number of inputs to the action. The returned dictionary may contain the following entries, each of which may be a float or an int:  * "cpu": number of CPUs; default 1* "memory": in MB; default 250* "local\_test": number of local tests; default 1   If this parameter is set to `None` , the default values are used. The callback must be top-level (lambda and nested functions aren't allowed). |
-| `toolchain` | [Label](../builtins/Label); or [string](../core/string); or `None`; default is `unbound`  Toolchain type of the executable or tools used in this action. The parameter must be set, so that, the action executes on the correct execution platform.  It's a no-op right now, but we recommend to set it when a toolchain is used, because it will be required in the future Bazel releases.  Note that the rule which creates this action needs to define this toolchain inside its 'rule()' function.  When `toolchain` and `exec\_group` parameters are both set, `exec\_group` will be used. An error is raised in case the `exec\_group` doesn't specify the same. |
+| `toolchain` | [Label](/versions/7.7.1/rules/lib/builtins/Label); or [string](/versions/7.7.1/rules/lib/core/string); or `None`; default is `unbound`  Toolchain type of the executable or tools used in this action. The parameter must be set, so that, the action executes on the correct execution platform.  It's a no-op right now, but we recommend to set it when a toolchain is used, because it will be required in the future Bazel releases.  Note that the rule which creates this action needs to define this toolchain inside its 'rule()' function.  When `toolchain` and `exec\_group` parameters are both set, `exec\_group` will be used. An error is raised in case the `exec\_group` doesn't specify the same. |
 
 ## run\_shell
 
@@ -149,21 +149,21 @@ Creates an action that runs a shell command. [See example of use](https://github
 
 | Parameter | Description |
 | --- | --- |
-| `outputs` | [sequence](../core/list) of [File](../builtins/File)s; required  List of the output files of the action. |
-| `inputs` | [sequence](../core/list) of [File](../builtins/File)s; or [depset](../builtins/depset); default is `[]`  List or depset of the input files of the action. |
-| `tools` | [sequence](../core/list) of [File](../builtins/File)s; or [depset](../builtins/depset); default is `unbound`  List or depset of any tools needed by the action. Tools are inputs with additional runfiles that are automatically made available to the action. The list can contain Files or FilesToRunProvider instances. |
-| `arguments` | [sequence](../core/list); default is `[]`  Command line arguments of the action. Must be a list of strings or [`actions.args()`](#args) objects. Bazel passes the elements in this attribute as arguments to the command.The command can access these arguments using shell variable substitutions such as `$1`, `$2`, etc. Note that since Args objects are flattened before indexing, if there is an Args object of unknown size then all subsequent strings will be at unpredictable indices. It may be useful to use `$@` (to retrieve all arguments) in conjunction with Args objects of indeterminate size. In the case where `command` is a list of strings, this parameter may not be used. |
-| `mnemonic` | [string](../core/string); or `None`; default is `None`  A one-word description of the action, for example, CppCompile or GoLink. |
-| `command` | [string](../core/string); or [sequence](../core/list) of [string](../core/string)s; required  Shell command to execute. This may either be a string (preferred) or a sequence of strings **(deprecated)**. If `command` is a string, then it is executed as if by `sh -c  "" ` -- that is, the elements in `arguments` are made available to the command as `$1`, `$2` (or `%1`, `%2` if using Windows batch), etc. If `arguments` contains any [`actions.args()`](#args) objects, their contents are appended one by one to the command line, so `$`*i* can refer to individual strings within an Args object. Note that if an Args object of unknown size is passed as part of `arguments`, then the strings will be at unknown indices; in this case the `$@` shell substitution (retrieve all arguments) may be useful. **(Deprecated)** If `command` is a sequence of strings, the first item is the executable to run and the remaining items are its arguments. If this form is used, the `arguments` parameter must not be supplied. *Note that this form is deprecated and will soon be removed. It is disabled with `--incompatible\_run\_shell\_command\_string`. Use this flag to verify your code is compatible.*  Bazel uses the same shell to execute the command as it does for genrules. |
-| `progress_message` | [string](../core/string); or `None`; default is `None`  Progress message to show to the user during the build, for example, "Compiling foo.cc to create foo.o". The message may contain `%{label}`, `%{input}`, or `%{output}` patterns, which are substituted with label string, first input, or output's path, respectively. Prefer to use patterns instead of static strings, because the former are more efficient. |
+| `outputs` | [sequence](/versions/7.7.1/rules/lib/core/list) of [File](/versions/7.7.1/rules/lib/builtins/File)s; required  List of the output files of the action. |
+| `inputs` | [sequence](/versions/7.7.1/rules/lib/core/list) of [File](/versions/7.7.1/rules/lib/builtins/File)s; or [depset](/versions/7.7.1/rules/lib/builtins/depset); default is `[]`  List or depset of the input files of the action. |
+| `tools` | [sequence](/versions/7.7.1/rules/lib/core/list) of [File](/versions/7.7.1/rules/lib/builtins/File)s; or [depset](/versions/7.7.1/rules/lib/builtins/depset); default is `unbound`  List or depset of any tools needed by the action. Tools are inputs with additional runfiles that are automatically made available to the action. The list can contain Files or FilesToRunProvider instances. |
+| `arguments` | [sequence](/versions/7.7.1/rules/lib/core/list); default is `[]`  Command line arguments of the action. Must be a list of strings or [`actions.args()`](#args) objects. Bazel passes the elements in this attribute as arguments to the command.The command can access these arguments using shell variable substitutions such as `$1`, `$2`, etc. Note that since Args objects are flattened before indexing, if there is an Args object of unknown size then all subsequent strings will be at unpredictable indices. It may be useful to use `$@` (to retrieve all arguments) in conjunction with Args objects of indeterminate size. In the case where `command` is a list of strings, this parameter may not be used. |
+| `mnemonic` | [string](/versions/7.7.1/rules/lib/core/string); or `None`; default is `None`  A one-word description of the action, for example, CppCompile or GoLink. |
+| `command` | [string](/versions/7.7.1/rules/lib/core/string); or [sequence](/versions/7.7.1/rules/lib/core/list) of [string](/versions/7.7.1/rules/lib/core/string)s; required  Shell command to execute. This may either be a string (preferred) or a sequence of strings **(deprecated)**. If `command` is a string, then it is executed as if by `sh -c  "" ` -- that is, the elements in `arguments` are made available to the command as `$1`, `$2` (or `%1`, `%2` if using Windows batch), etc. If `arguments` contains any [`actions.args()`](#args) objects, their contents are appended one by one to the command line, so `$`*i* can refer to individual strings within an Args object. Note that if an Args object of unknown size is passed as part of `arguments`, then the strings will be at unknown indices; in this case the `$@` shell substitution (retrieve all arguments) may be useful. **(Deprecated)** If `command` is a sequence of strings, the first item is the executable to run and the remaining items are its arguments. If this form is used, the `arguments` parameter must not be supplied. *Note that this form is deprecated and will soon be removed. It is disabled with `--incompatible\_run\_shell\_command\_string`. Use this flag to verify your code is compatible.*  Bazel uses the same shell to execute the command as it does for genrules. |
+| `progress_message` | [string](/versions/7.7.1/rules/lib/core/string); or `None`; default is `None`  Progress message to show to the user during the build, for example, "Compiling foo.cc to create foo.o". The message may contain `%{label}`, `%{input}`, or `%{output}` patterns, which are substituted with label string, first input, or output's path, respectively. Prefer to use patterns instead of static strings, because the former are more efficient. |
 | `use_default_shell_env` | default is `False`  Whether the action should use the default shell environment, which consists of a few OS-dependent variables as well as variables set via [`--action_env`](/versions/7.7.1/reference/command-line-reference#flag--action_env). If both `use_default_shell_env` and `env` are set to `True`, values set in `env` will overwrite the default shell environment if [`--incompatible_merge_fixed_and_default_shell_env`](/versions/7.7.1/reference/command-line-reference#flag--incompatible_merge_fixed_and_default_shell_env) is enabled (default). If the flag is not enabled, `env` is ignored. |
-| `env` | [dict](../core/dict); or `None`; default is `None`  Sets the dictionary of environment variables. If both `use_default_shell_env` and `env` are set to `True`, values set in `env` will overwrite the default shell environment if [`--incompatible_merge_fixed_and_default_shell_env`](/versions/7.7.1/reference/command-line-reference#flag--incompatible_merge_fixed_and_default_shell_env) is enabled (default). If the flag is not enabled, `env` is ignored. |
-| `execution_requirements` | [dict](../core/dict); or `None`; default is `None`  Information for scheduling the action. See [tags](/versions/7.7.1/reference/be/common-definitions#common.tags) for useful keys. |
-| `input_manifests` | [sequence](../core/list); or `None`; default is `None`  (Experimental) sets the input runfiles metadata; they are typically generated by resolve\_command. |
-| `exec_group` | [string](../core/string); or `None`; default is `None`  Runs the action on the given exec group's execution platform. If none, uses the target's default execution platform. |
-| `shadowed_action` | [Action](../builtins/Action); default is `None`  Runs the action using the given shadowed action's discovered inputs added to the action's inputs list. If none, uses only the action's inputs. |
+| `env` | [dict](/versions/7.7.1/rules/lib/core/dict); or `None`; default is `None`  Sets the dictionary of environment variables. If both `use_default_shell_env` and `env` are set to `True`, values set in `env` will overwrite the default shell environment if [`--incompatible_merge_fixed_and_default_shell_env`](/versions/7.7.1/reference/command-line-reference#flag--incompatible_merge_fixed_and_default_shell_env) is enabled (default). If the flag is not enabled, `env` is ignored. |
+| `execution_requirements` | [dict](/versions/7.7.1/rules/lib/core/dict); or `None`; default is `None`  Information for scheduling the action. See [tags](/versions/7.7.1/reference/be/common-definitions#common.tags) for useful keys. |
+| `input_manifests` | [sequence](/versions/7.7.1/rules/lib/core/list); or `None`; default is `None`  (Experimental) sets the input runfiles metadata; they are typically generated by resolve\_command. |
+| `exec_group` | [string](/versions/7.7.1/rules/lib/core/string); or `None`; default is `None`  Runs the action on the given exec group's execution platform. If none, uses the target's default execution platform. |
+| `shadowed_action` | [Action](/versions/7.7.1/rules/lib/builtins/Action); default is `None`  Runs the action using the given shadowed action's discovered inputs added to the action's inputs list. If none, uses only the action's inputs. |
 | `resource_set` | callable; or `None`; default is `None`  A callback function for estimating resource usage if run locally. See[`ctx.actions.run()`](#run.resource_set). |
-| `toolchain` | [Label](../builtins/Label); or [string](../core/string); or `None`; default is `unbound`  Toolchain type of the executable or tools used in this action. The parameter must be set, so that, the action executes on the correct execution platform.  It's a no-op right now, but we recommend to set it when a toolchain is used, because it will be required in the future Bazel releases.  Note that the rule which creates this action needs to define this toolchain inside its 'rule()' function.  When `toolchain` and `exec\_group` parameters are both set, `exec\_group` will be used. An error is raised in case the `exec\_group` doesn't specify the same. toolchain. |
+| `toolchain` | [Label](/versions/7.7.1/rules/lib/builtins/Label); or [string](/versions/7.7.1/rules/lib/core/string); or `None`; default is `unbound`  Toolchain type of the executable or tools used in this action. The parameter must be set, so that, the action executes on the correct execution platform.  It's a no-op right now, but we recommend to set it when a toolchain is used, because it will be required in the future Bazel releases.  Note that the rule which creates this action needs to define this toolchain inside its 'rule()' function.  When `toolchain` and `exec\_group` parameters are both set, `exec\_group` will be used. An error is raised in case the `exec\_group` doesn't specify the same. toolchain. |
 
 ## symlink
 
@@ -184,10 +184,10 @@ Otherwise, when you use `target_path`, declare `output` with [`declare_symlink()
 | Parameter | Description |
 | --- | --- |
 | `output` | required  The output of this action. |
-| `target_file` | [File](../builtins/File); or `None`; default is `None`  The File that the output symlink will point to. |
-| `target_path` | [string](../core/string); or `None`; default is `None`  The exact path that the output symlink will point to. No normalization or other processing is applied. |
+| `target_file` | [File](/versions/7.7.1/rules/lib/builtins/File); or `None`; default is `None`  The File that the output symlink will point to. |
+| `target_path` | [string](/versions/7.7.1/rules/lib/core/string); or `None`; default is `None`  The exact path that the output symlink will point to. No normalization or other processing is applied. |
 | `is_executable` | default is `False`  May only be used with `target_file`, not `target_path`. If true, when the action is executed, the `target_file`'s path is checked to confirm that it is executable, and an error is reported if it is not. Setting `is_executable` to False does not mean the target is not executable, just that no verification is done. This feature does not make sense for `target_path` because dangling symlinks might not exist at build time. |
-| `progress_message` | [string](../core/string); or `None`; default is `None`  Progress message to show to the user during the build. |
+| `progress_message` | [string](/versions/7.7.1/rules/lib/core/string); or `None`; default is `None`  Progress message to show to the user during the build. |
 
 ## template\_dict
 
@@ -210,5 +210,5 @@ Creates a file write action. When the action is executed, it will write the give
 | Parameter | Description |
 | --- | --- |
 | `output` | required  The output file. |
-| `content` | [string](../core/string); or [Args](../builtins/Args); required  the contents of the file. May be a either a string or an [`actions.args()`](#args) object. |
+| `content` | [string](/versions/7.7.1/rules/lib/core/string); or [Args](/versions/7.7.1/rules/lib/builtins/Args); required  the contents of the file. May be a either a string or an [`actions.args()`](#args) object. |
 | `is_executable` | default is `False`  Whether the output file should be executable. |
\ No newline at end of file
diff --git a/versions/7.7.1/rules/lib/builtins/apple_platform.mdx b/versions/7.7.1/rules/lib/builtins/apple_platform.mdx
index 02da3fb7..b9c2559b 100644
--- a/versions/7.7.1/rules/lib/builtins/apple_platform.mdx
+++ b/versions/7.7.1/rules/lib/builtins/apple_platform.mdx
@@ -4,7 +4,7 @@ title: 'apple\_platform'
 
 Corresponds to Xcode's notion of a platform as would be found in `Xcode.app/Contents/Developer/Platforms`. Each platform represents an Apple platform type (such as iOS or tvOS) combined with one or more related CPU architectures. For example, the iOS simulator platform supports `x86_64` and `i386` architectures.
 
-Specific instances of this type can be retrieved from the fields of the [apple\_common.platform](../toplevel/apple_common#platform) struct:
+Specific instances of this type can be retrieved from the fields of the [apple\_common.platform](/versions/7.7.1/rules/lib/toplevel/apple_common#platform) struct:
 
 * `apple_common.platform.ios_device`
 * `apple_common.platform.ios_simulator`
@@ -14,7 +14,7 @@ Specific instances of this type can be retrieved from the fields of the [apple\_
 * `apple_common.platform.watchos_device`
 * `apple_common.platform.watchos_simulator`
 
-More commonly, however, the [apple](../fragments/apple) configuration fragment has fields/methods that allow rules to determine the platform for which a target is being built.
+More commonly, however, the [apple](/versions/7.7.1/rules/lib/fragments/apple) configuration fragment has fields/methods that allow rules to determine the platform for which a target is being built.
 
 Example:
 
diff --git a/versions/7.7.1/rules/lib/builtins/apple_platform_type.mdx b/versions/7.7.1/rules/lib/builtins/apple_platform_type.mdx
index 94c12e7f..b25eb05d 100644
--- a/versions/7.7.1/rules/lib/builtins/apple_platform_type.mdx
+++ b/versions/7.7.1/rules/lib/builtins/apple_platform_type.mdx
@@ -4,7 +4,7 @@ title: 'apple\_platform\_type'
 
 Describes an Apple "platform type", such as iOS, macOS, tvOS, visionOS, or watchOS. This is distinct from a "platform", which is the platform type combined with one or more CPU architectures.
 
-Specific instances of this type can be retrieved by accessing the fields of the [apple\_common.platform\_type](../toplevel/apple_common#platform_type):
+Specific instances of this type can be retrieved by accessing the fields of the [apple\_common.platform\_type](/versions/7.7.1/rules/lib/toplevel/apple_common#platform_type):
 
 * `apple_common.platform_type.ios`
 * `apple_common.platform_type.macos`
@@ -13,4 +13,4 @@ Specific instances of this type can be retrieved by accessing the fields of the
 
 Likewise, the platform type of an existing platform value can be retrieved using its `platform_type` field.
 
-Platform types can be converted to a lowercase string (e.g., `ios` or `macos`) using the [str](../globals/all#str) function.
\ No newline at end of file
+Platform types can be converted to a lowercase string (e.g., `ios` or `macos`) using the [str](/versions/7.7.1/rules/lib/globals/all#str) function.
\ No newline at end of file
diff --git a/versions/7.7.1/rules/lib/builtins/configuration.mdx b/versions/7.7.1/rules/lib/builtins/configuration.mdx
index 644d5fe7..5553a4cd 100644
--- a/versions/7.7.1/rules/lib/builtins/configuration.mdx
+++ b/versions/7.7.1/rules/lib/builtins/configuration.mdx
@@ -18,7 +18,7 @@ This object holds information about the environment in which the build is runnin
 bool configuration.coverage_enabled
 ```
 
-A boolean that tells whether code coverage is enabled for this run. Note that this does not compute whether a specific rule should be instrumented for code coverage data collection. For that, see the [`ctx.coverage_instrumented`](../builtins/ctx#coverage_instrumented) function.
+A boolean that tells whether code coverage is enabled for this run. Note that this does not compute whether a specific rule should be instrumented for code coverage data collection. For that, see the [`ctx.coverage_instrumented`](/versions/7.7.1/rules/lib/builtins/ctx#coverage_instrumented) function.
 
 ## default\_shell\_env
 
diff --git a/versions/7.7.1/rules/lib/builtins/ctx.mdx b/versions/7.7.1/rules/lib/builtins/ctx.mdx
index f702fffe..f60c364e 100644
--- a/versions/7.7.1/rules/lib/builtins/ctx.mdx
+++ b/versions/7.7.1/rules/lib/builtins/ctx.mdx
@@ -66,7 +66,7 @@ A list of ids for all aspects applied to the target. Only available in aspect im
 struct ctx.attr
 ```
 
-A struct to access the values of the [attributes](https://bazel.build/versions/7.7.1/extending/rules#attributes). The values are provided by the user (if not, a default value is used). The attributes of the struct and the types of their values correspond to the keys and values of the [`attrs` dict](../globals/bzl#rule.attrs) provided to the [`rule` function](../globals/bzl#rule). [See example of use](https://github.com/bazelbuild/examples/blob/main/rules/attributes/printer.bzl).
+A struct to access the values of the [attributes](https://bazel.build/versions/7.7.1/extending/rules#attributes). The values are provided by the user (if not, a default value is used). The attributes of the struct and the types of their values correspond to the keys and values of the [`attrs` dict](/versions/7.7.1/rules/lib/globals/bzl#rule.attrs) provided to the [`rule` function](/versions/7.7.1/rules/lib/globals/bzl#rule). [See example of use](https://github.com/bazelbuild/examples/blob/main/rules/attributes/printer.bzl).
 
 ## bin\_dir
 
@@ -98,7 +98,7 @@ Value of the build setting represented by the current target. If this isn't the
 configuration ctx.configuration
 ```
 
-The default configuration. See the [configuration](../builtins/configuration) type for more details.
+The default configuration. See the [configuration](/versions/7.7.1/rules/lib/builtins/configuration) type for more details.
 
 ## coverage\_instrumented
 
@@ -106,13 +106,13 @@ The default configuration. See the [configuration](../builtins/configuration) ty
 bool ctx.coverage_instrumented(target=None)
 ```
 
-Returns whether code coverage instrumentation should be generated when performing compilation actions for this rule or, if `target` is provided, the rule specified by that Target. (If a non-rule or a Starlark rule Target is provided, this returns False.) Checks if the sources of the current rule (if no Target is provided) or the sources of Target should be instrumented based on the --instrumentation\_filter and --instrument\_test\_targets config settings. This differs from `coverage_enabled` in the [configuration](../builtins/configuration), which notes whether coverage data collection is enabled for the entire run, but not whether a specific target should be instrumented.
+Returns whether code coverage instrumentation should be generated when performing compilation actions for this rule or, if `target` is provided, the rule specified by that Target. (If a non-rule or a Starlark rule Target is provided, this returns False.) Checks if the sources of the current rule (if no Target is provided) or the sources of Target should be instrumented based on the --instrumentation\_filter and --instrument\_test\_targets config settings. This differs from `coverage_enabled` in the [configuration](/versions/7.7.1/rules/lib/builtins/configuration), which notes whether coverage data collection is enabled for the entire run, but not whether a specific target should be instrumented.
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `target` | [Target](../builtins/Target); or `None`; default is `None`  A Target specifying a rule. If not provided, defaults to the current rule. |
+| `target` | [Target](/versions/7.7.1/rules/lib/builtins/Target); or `None`; default is `None`  A Target specifying a rule. If not provided, defaults to the current rule. |
 
 ## created\_actions
 
@@ -120,7 +120,7 @@ Returns whether code coverage instrumentation should be generated when performin
 StarlarkValue ctx.created_actions()
 ```
 
-For rules with [\_skylark\_testable](../globals/bzl#rule._skylark_testable) set to `True`, this returns an `Actions` provider representing all actions created so far for the current rule. For all other rules, returns `None`. Note that the provider is not updated when subsequent actions are created, so you will have to call this function again if you wish to inspect them.
+For rules with [\_skylark\_testable](/versions/7.7.1/rules/lib/globals/bzl#rule._skylark_testable) set to `True`, this returns an `Actions` provider representing all actions created so far for the current rule. For all other rules, returns `None`. Note that the provider is not updated when subsequent actions are created, so you will have to call this function again if you wish to inspect them.
 
 This is intended to help write tests for rule-implementation helper functions, which may take in a `ctx` object and create actions on it.
 
@@ -146,7 +146,7 @@ A collection of the execution groups available for this rule, indexed by their n
 struct ctx.executable
 ```
 
-A `struct` containing executable files defined in [label type attributes](../toplevel/attr#label) marked as [`executable=True`](../toplevel/attr#label.executable). The struct fields correspond to the attribute names. Each value in the struct is either a [`File`](../builtins/File) or `None`. If an optional attribute is not specified in the rule then the corresponding struct value is `None`. If a label type is not marked as `executable=True`, no corresponding struct field is generated. [See example of use](https://github.com/bazelbuild/examples/blob/main/rules/actions_run/execute.bzl).
+A `struct` containing executable files defined in [label type attributes](/versions/7.7.1/rules/lib/toplevel/attr#label) marked as [`executable=True`](/versions/7.7.1/rules/lib/toplevel/attr#label.executable). The struct fields correspond to the attribute names. Each value in the struct is either a [`File`](/versions/7.7.1/rules/lib/builtins/File) or `None`. If an optional attribute is not specified in the rule then the corresponding struct value is `None`. If a label type is not marked as `executable=True`, no corresponding struct field is generated. [See example of use](https://github.com/bazelbuild/examples/blob/main/rules/actions_run/execute.bzl).
 
 ## expand\_location
 
@@ -165,7 +165,7 @@ This function is useful to let the user specify a command in a BUILD file (like
 | Parameter | Description |
 | --- | --- |
 | `input` | required  String to be expanded. |
-| `targets` | [sequence](../core/list) of [Target](../builtins/Target)s; default is `[]`  List of targets for additional lookup information. |
+| `targets` | [sequence](/versions/7.7.1/rules/lib/core/list) of [Target](/versions/7.7.1/rules/lib/builtins/Target)s; default is `[]`  List of targets for additional lookup information. |
 
 May return `None`.
 
@@ -175,7 +175,7 @@ May return `None`.
 string ctx.expand_make_variables(attribute_name, command, additional_substitutions)
 ```
 
-**Deprecated.** Use [ctx.var](../builtins/ctx#var) to access the variables instead.
+**Deprecated.** Use [ctx.var](/versions/7.7.1/rules/lib/builtins/ctx#var) to access the variables instead.
 Returns a string after expanding all references to "Make variables". The variables must have the following format: `$(VAR_NAME)`. Also, `$$VAR_NAME` expands to `$VAR_NAME`. Examples:
 
 ```
@@ -207,7 +207,7 @@ The set of features that are explicitly enabled by the user for this rule. [See
 struct ctx.file
 ```
 
-A `struct` containing files defined in [label type attributes](../toplevel/attr#label) marked as [`allow_single_file`](../toplevel/attr#label.allow_single_file). The struct fields correspond to the attribute names. The struct value is always a [`File`](../builtins/File) or `None`. If an optional attribute is not specified in the rule then the corresponding struct value is `None`. If a label type is not marked as `allow_single_file`, no corresponding struct field is generated. It is a shortcut for:
+A `struct` containing files defined in [label type attributes](/versions/7.7.1/rules/lib/toplevel/attr#label) marked as [`allow_single_file`](/versions/7.7.1/rules/lib/toplevel/attr#label.allow_single_file). The struct fields correspond to the attribute names. The struct value is always a [`File`](/versions/7.7.1/rules/lib/builtins/File) or `None`. If an optional attribute is not specified in the rule then the corresponding struct value is `None`. If a label type is not marked as `allow_single_file`, no corresponding struct field is generated. It is a shortcut for:
 
 ```
 list(ctx.attr..files)[0]
@@ -221,7 +221,7 @@ In other words, use `file` to access the (singular) [default output](https://baz
 struct ctx.files
 ```
 
-A `struct` containing files defined in [label](../toplevel/attr#label) or [label list](../toplevel/attr#label_list) type attributes. The struct fields correspond to the attribute names. The struct values are `list` of [`File`](../builtins/File)s. It is a shortcut for:
+A `struct` containing files defined in [label](/versions/7.7.1/rules/lib/toplevel/attr#label) or [label list](/versions/7.7.1/rules/lib/toplevel/attr#label_list) type attributes. The struct fields correspond to the attribute names. The struct values are `list` of [`File`](/versions/7.7.1/rules/lib/builtins/File)s. It is a shortcut for:
 
 ```
 [f for t in ctx.attr. for f in t.files]
@@ -267,13 +267,13 @@ The label of the target currently being analyzed.
 structure ctx.outputs
 ```
 
-A pseudo-struct containing all the predeclared output files, represented by [`File`](../builtins/File) objects. See the [Rules page](https://bazel.build/versions/7.7.1/extending/rules#files) for more information and examples.
+A pseudo-struct containing all the predeclared output files, represented by [`File`](/versions/7.7.1/rules/lib/builtins/File) objects. See the [Rules page](https://bazel.build/versions/7.7.1/extending/rules#files) for more information and examples.
 
 This field does not exist on aspect contexts, since aspects do not have predeclared outputs.
 
 The fields of this object are defined as follows. It is an error if two outputs produce the same field name or have the same label.
 
-* If the rule declares an [`outputs`](../globals/bzl#rule.outputs) dict, then for every entry in the dict, there is a field whose name is the key and whose value is the corresponding `File`.* For every attribute of type [`attr.output`](../toplevel/attr#output) that the rule declares, there is a field whose name is the attribute's name. If the target specified a label for that attribute, then the field value is the corresponding `File`; otherwise the field value is `None`.* For every attribute of type [`attr.output_list`](../toplevel/attr#output_list) that the rule declares, there is a field whose name is the attribute's name. The field value is a list of `File` objects corresponding to the labels given for that attribute in the target, or an empty list if the attribute was not specified in the target.* **(Deprecated)** If the rule is marked [`executable`](../globals/bzl#rule.executable) or [`test`](../globals/bzl#rule.test), there is a field named `"executable"`, which is the default executable. It is recommended that instead of using this, you pass another file (either predeclared or not) to the `executable` arg of [`DefaultInfo`](../providers/DefaultInfo).
+* If the rule declares an [`outputs`](/versions/7.7.1/rules/lib/globals/bzl#rule.outputs) dict, then for every entry in the dict, there is a field whose name is the key and whose value is the corresponding `File`.* For every attribute of type [`attr.output`](/versions/7.7.1/rules/lib/toplevel/attr#output) that the rule declares, there is a field whose name is the attribute's name. If the target specified a label for that attribute, then the field value is the corresponding `File`; otherwise the field value is `None`.* For every attribute of type [`attr.output_list`](/versions/7.7.1/rules/lib/toplevel/attr#output_list) that the rule declares, there is a field whose name is the attribute's name. The field value is a list of `File` objects corresponding to the labels given for that attribute in the target, or an empty list if the attribute was not specified in the target.* **(Deprecated)** If the rule is marked [`executable`](/versions/7.7.1/rules/lib/globals/bzl#rule.executable) or [`test`](/versions/7.7.1/rules/lib/globals/bzl#rule.test), there is a field named `"executable"`, which is the default executable. It is recommended that instead of using this, you pass another file (either predeclared or not) to the `executable` arg of [`DefaultInfo`](/versions/7.7.1/rules/lib/providers/DefaultInfo).
 
 ## resolve\_command
 
@@ -289,10 +289,10 @@ tuple ctx.resolve_command(command='', attribute=None, expand_locations=False, ma
 | Parameter | Description |
 | --- | --- |
 | `command` | default is `''`  Command to resolve. |
-| `attribute` | [string](../core/string); or `None`; default is `None`  Name of the associated attribute for which to issue an error, or None. |
+| `attribute` | [string](/versions/7.7.1/rules/lib/core/string); or `None`; default is `None`  Name of the associated attribute for which to issue an error, or None. |
 | `expand_locations` | default is `False`  Shall we expand $(location) variables? See [ctx.expand\_location()](#expand_location) for more details. |
-| `make_variables` | [dict](../core/dict); or `None`; default is `None`  Make variables to expand, or None. |
-| `tools` | [sequence](../core/list) of [Target](../builtins/Target)s; default is `[]`  List of tools (list of targets). |
+| `make_variables` | [dict](/versions/7.7.1/rules/lib/core/dict); or `None`; default is `None`  Make variables to expand, or None. |
+| `tools` | [sequence](/versions/7.7.1/rules/lib/core/list) of [Target](/versions/7.7.1/rules/lib/builtins/Target)s; default is `[]`  List of tools (list of targets). |
 | `label_dict` | default is `{}`  Dictionary of resolved labels and the corresponding list of Files (a dict of Label : list of Files). |
 | `execution_requirements` | default is `{}`  Information for scheduling the action to resolve this command. See [tags](/versions/7.7.1/reference/be/common-definitions#common.tags) for useful keys. |
 
@@ -310,7 +310,7 @@ In contrast to `ctx.resolve_command`, this method does not require that Bash be
 
 | Parameter | Description |
 | --- | --- |
-| `tools` | [sequence](../core/list) of [Target](../builtins/Target)s; default is `[]`  List of tools (list of targets). |
+| `tools` | [sequence](/versions/7.7.1/rules/lib/core/list) of [Target](/versions/7.7.1/rules/lib/builtins/Target)s; default is `[]`  List of tools (list of targets). |
 
 ## rule
 
@@ -332,12 +332,12 @@ Creates a runfiles object.
 
 | Parameter | Description |
 | --- | --- |
-| `files` | [sequence](../core/list) of [File](../builtins/File)s; default is `[]`  The list of files to be added to the runfiles. |
-| `transitive_files` | [depset](../builtins/depset) of [File](../builtins/File)s; or `None`; default is `None`  The (transitive) set of files to be added to the runfiles. The depset should use the `default` order (which, as the name implies, is the default). |
+| `files` | [sequence](/versions/7.7.1/rules/lib/core/list) of [File](/versions/7.7.1/rules/lib/builtins/File)s; default is `[]`  The list of files to be added to the runfiles. |
+| `transitive_files` | [depset](/versions/7.7.1/rules/lib/builtins/depset) of [File](/versions/7.7.1/rules/lib/builtins/File)s; or `None`; default is `None`  The (transitive) set of files to be added to the runfiles. The depset should use the `default` order (which, as the name implies, is the default). |
 | `collect_data` | default is `False`  **Use of this parameter is not recommended. See [runfiles guide](https://bazel.build/versions/7.7.1/extending/rules#runfiles)**. Whether to collect the data runfiles from the dependencies in srcs, data and deps attributes. |
 | `collect_default` | default is `False`  **Use of this parameter is not recommended. See [runfiles guide](https://bazel.build/versions/7.7.1/extending/rules#runfiles)**. Whether to collect the default runfiles from the dependencies in srcs, data and deps attributes. |
-| `symlinks` | [dict](../core/dict); or [depset](../builtins/depset) of [SymlinkEntry](../builtins/SymlinkEntry)s; default is `{}`  Either a SymlinkEntry depset or the map of symlinks to be added to the runfiles. Symlinks are always added under the main workspace's runfiles directory (e.g. `/_main/`, **not** the directory corresponding to the current target's repository. See [Runfiles symlinks](https://bazel.build/versions/7.7.1/extending/rules#runfiles_symlinks) in the rules guide. |
-| `root_symlinks` | [dict](../core/dict); or [depset](../builtins/depset) of [SymlinkEntry](../builtins/SymlinkEntry)s; default is `{}`  Either a SymlinkEntry depset or a map of symlinks to be added to the runfiles. See [Runfiles symlinks](https://bazel.build/versions/7.7.1/extending/rules#runfiles_symlinks) in the rules guide. |
+| `symlinks` | [dict](/versions/7.7.1/rules/lib/core/dict); or [depset](/versions/7.7.1/rules/lib/builtins/depset) of [SymlinkEntry](/versions/7.7.1/rules/lib/builtins/SymlinkEntry)s; default is `{}`  Either a SymlinkEntry depset or the map of symlinks to be added to the runfiles. Symlinks are always added under the main workspace's runfiles directory (e.g. `/_main/`, **not** the directory corresponding to the current target's repository. See [Runfiles symlinks](https://bazel.build/versions/7.7.1/extending/rules#runfiles_symlinks) in the rules guide. |
+| `root_symlinks` | [dict](/versions/7.7.1/rules/lib/core/dict); or [depset](/versions/7.7.1/rules/lib/builtins/depset) of [SymlinkEntry](/versions/7.7.1/rules/lib/builtins/SymlinkEntry)s; default is `{}`  Either a SymlinkEntry depset or a map of symlinks to be added to the runfiles. See [Runfiles symlinks](https://bazel.build/versions/7.7.1/extending/rules#runfiles_symlinks) in the rules guide. |
 
 ## split\_attr
 
diff --git a/versions/7.7.1/rules/lib/builtins/depset.mdx b/versions/7.7.1/rules/lib/builtins/depset.mdx
index 6cbfbd6a..6bad2327 100644
--- a/versions/7.7.1/rules/lib/builtins/depset.mdx
+++ b/versions/7.7.1/rules/lib/builtins/depset.mdx
@@ -6,7 +6,7 @@ A specialized data structure that supports efficient merge operations and has a
 
 The elements of a depset must be hashable and all of the same type (as defined by the built-in type(x) function), but depsets are not simply hash sets and do not support fast membership tests. If you need a general set datatype, you can simulate one using a dictionary where all keys map to `True`.
 
-Depsets are immutable. They should be created using their [constructor function](../globals/bzl#depset) and merged or augmented with other depsets via the `transitive` argument.
+Depsets are immutable. They should be created using their [constructor function](/versions/7.7.1/rules/lib/globals/bzl#depset) and merged or augmented with other depsets via the `transitive` argument.
 
 The `order` parameter determines the kind of traversal that is done to convert the depset to an iterable. There are four possible values:
 
diff --git a/versions/7.7.1/rules/lib/builtins/fragments.mdx b/versions/7.7.1/rules/lib/builtins/fragments.mdx
index 6e5b7289..a117ff81 100644
--- a/versions/7.7.1/rules/lib/builtins/fragments.mdx
+++ b/versions/7.7.1/rules/lib/builtins/fragments.mdx
@@ -6,4 +6,4 @@ A collection of configuration fragments available in the current rule implementa
 
 Only configuration fragments which are declared in the rule definition may be accessed in this collection.
 
-See the [configuration fragment reference](../fragments) for a list of available fragments and the [rules documentation](https://bazel.build/versions/7.7.1/extending/rules#configuration_fragments) for how to use them.
\ No newline at end of file
+See the [configuration fragment reference](/versions/7.7.1/rules/lib/fragments) for a list of available fragments and the [rules documentation](https://bazel.build/versions/7.7.1/extending/rules#configuration_fragments) for how to use them.
\ No newline at end of file
diff --git a/versions/7.7.1/rules/lib/builtins/module_ctx.mdx b/versions/7.7.1/rules/lib/builtins/module_ctx.mdx
index d66f8b74..d9f8c44d 100644
--- a/versions/7.7.1/rules/lib/builtins/module_ctx.mdx
+++ b/versions/7.7.1/rules/lib/builtins/module_ctx.mdx
@@ -35,8 +35,8 @@ Downloads a file to the output path for the provided url and returns a struct co
 
 | Parameter | Description |
 | --- | --- |
-| `url` | [string](../core/string); or Iterable of [string](../core/string)s; required  List of mirror URLs referencing the same file. |
-| `output` | [string](../core/string); or [Label](../builtins/Label); or [path](../builtins/path); default is `''`  path to the output file, relative to the repository directory. |
+| `url` | [string](/versions/7.7.1/rules/lib/core/string); or Iterable of [string](/versions/7.7.1/rules/lib/core/string)s; required  List of mirror URLs referencing the same file. |
+| `output` | [string](/versions/7.7.1/rules/lib/core/string); or [Label](/versions/7.7.1/rules/lib/builtins/Label); or [path](/versions/7.7.1/rules/lib/builtins/path); default is `''`  path to the output file, relative to the repository directory. |
 | `sha256` | default is `''`  The expected SHA-256 hash of the file downloaded. This must match the SHA-256 hash of the file downloaded. It is a security risk to omit the SHA-256 as remote files can change. At best omitting this field will make your build non-hermetic. It is optional to make development easier but should be set before shipping. If provided, the repository cache will first be checked for a file with the given hash; a download will only be attempted if the file was not found in the cache. After a successful download, the file will be added to the cache. |
 | `executable` | default is `False`  Set the executable flag on the created file, false by default. |
 | `allow_fail` | default is `False`  If set, indicate the error in the return value instead of raising an error for failed downloads. |
@@ -58,8 +58,8 @@ Downloads a file to the output path for the provided url, extracts it, and retur
 
 | Parameter | Description |
 | --- | --- |
-| `url` | [string](../core/string); or Iterable of [string](../core/string)s; required  List of mirror URLs referencing the same file. |
-| `output` | [string](../core/string); or [Label](../builtins/Label); or [path](../builtins/path); default is `''`  Path to the directory where the archive will be unpacked, relative to the repository directory. |
+| `url` | [string](/versions/7.7.1/rules/lib/core/string); or Iterable of [string](/versions/7.7.1/rules/lib/core/string)s; required  List of mirror URLs referencing the same file. |
+| `output` | [string](/versions/7.7.1/rules/lib/core/string); or [Label](/versions/7.7.1/rules/lib/builtins/Label); or [path](/versions/7.7.1/rules/lib/builtins/path); default is `''`  Path to the directory where the archive will be unpacked, relative to the repository directory. |
 | `sha256` | default is `''`  The expected SHA-256 hash of the file downloaded. This must match the SHA-256 hash of the file downloaded. It is a security risk to omit the SHA-256 as remote files can change. At best omitting this field will make your build non-hermetic. It is optional to make development easier but should be set before shipping. If provided, the repository cache will first be checked for a file with the given hash; a download will only be attempted if the file was not found in the cache. After a successful download, the file will be added to the cache. |
 | `type` | default is `''`  The archive type of the downloaded file. By default, the archive type is determined from the file extension of the URL. If the file has no extension, you can explicitly specify either "zip", "jar", "war", "aar", "nupkg", "tar", "tar.gz", "tgz", "tar.xz", "txz", ".tar.zst", ".tzst", "tar.bz2", ".tbz", ".ar", or ".deb" here. |
 | `stripPrefix` | default is `''`  A directory prefix to strip from the extracted files. Many archives contain a top-level directory that contains all files in the archive. Instead of needing to specify this prefix over and over in the `build_file`, this field can be used to strip it from extracted files. |
@@ -100,9 +100,9 @@ Constructs an opaque object that can be returned from the module extension's imp
 
 | Parameter | Description |
 | --- | --- |
-| `root_module_direct_deps` | [sequence](../core/list) of [string](../core/string)s; or [string](../core/string); or `None`; default is `None`  The names of the repositories that the extension considers to be direct dependencies of the root module. If the root module imports additional repositories or does not import all of these repositories via [`use_repo`](../globals/module#use_repo), Bazel will print a warning when the extension is evaluated, instructing the user to run `bazel mod tidy` to fix the `use_repo` calls automatically. If one of `root_module_direct_deps` and will print a warning and a fixup command when the extension is evaluated. If one of `root_module_direct_deps` and `root_module_direct_dev_deps` is specified, the other has to be as well. The lists specified by these two parameters must be disjoint. Exactly one of `root_module_direct_deps` and `root_module_direct_dev_deps` can be set to the special value `"all"`, which is treated as if a list with the names of all repositories generated by the extension was specified as the value. |
-| `root_module_direct_dev_deps` | [sequence](../core/list) of [string](../core/string)s; or [string](../core/string); or `None`; default is `None`  The names of the repositories that the extension considers to be direct dev dependencies of the root module. If the root module imports additional repositories or does not import all of these repositories via [`use_repo`](../globals/module#use_repo) on an extension proxy created with `use_extension(..., dev_dependency = True)`, Bazel will print a warning when the extension is evaluated, instructing the user to run `bazel mod tidy` to fix the `use_repo` calls automatically. If one of `root_module_direct_deps` and `root_module_direct_dev_deps` is specified, the other has to be as well. The lists specified by these two parameters must be disjoint. Exactly one of `root_module_direct_deps` and `root_module_direct_dev_deps` can be set to the special value `"all"`, which is treated as if a list with the names of all repositories generated by the extension was specified as the value. |
-| `reproducible` | [bool](../core/bool); default is `False`  States that this module extension ensures complete reproducibility, thereby it should not be stored in the lockfile. |
+| `root_module_direct_deps` | [sequence](/versions/7.7.1/rules/lib/core/list) of [string](/versions/7.7.1/rules/lib/core/string)s; or [string](/versions/7.7.1/rules/lib/core/string); or `None`; default is `None`  The names of the repositories that the extension considers to be direct dependencies of the root module. If the root module imports additional repositories or does not import all of these repositories via [`use_repo`](/versions/7.7.1/rules/lib/globals/module#use_repo), Bazel will print a warning when the extension is evaluated, instructing the user to run `bazel mod tidy` to fix the `use_repo` calls automatically. If one of `root_module_direct_deps` and will print a warning and a fixup command when the extension is evaluated. If one of `root_module_direct_deps` and `root_module_direct_dev_deps` is specified, the other has to be as well. The lists specified by these two parameters must be disjoint. Exactly one of `root_module_direct_deps` and `root_module_direct_dev_deps` can be set to the special value `"all"`, which is treated as if a list with the names of all repositories generated by the extension was specified as the value. |
+| `root_module_direct_dev_deps` | [sequence](/versions/7.7.1/rules/lib/core/list) of [string](/versions/7.7.1/rules/lib/core/string)s; or [string](/versions/7.7.1/rules/lib/core/string); or `None`; default is `None`  The names of the repositories that the extension considers to be direct dev dependencies of the root module. If the root module imports additional repositories or does not import all of these repositories via [`use_repo`](/versions/7.7.1/rules/lib/globals/module#use_repo) on an extension proxy created with `use_extension(..., dev_dependency = True)`, Bazel will print a warning when the extension is evaluated, instructing the user to run `bazel mod tidy` to fix the `use_repo` calls automatically. If one of `root_module_direct_deps` and `root_module_direct_dev_deps` is specified, the other has to be as well. The lists specified by these two parameters must be disjoint. Exactly one of `root_module_direct_deps` and `root_module_direct_dev_deps` can be set to the special value `"all"`, which is treated as if a list with the names of all repositories generated by the extension was specified as the value. |
+| `reproducible` | [bool](/versions/7.7.1/rules/lib/core/bool); default is `False`  States that this module extension ensures complete reproducibility, thereby it should not be stored in the lockfile. |
 
 ## extract
 
@@ -116,8 +116,8 @@ Extract an archive to the repository directory.
 
 | Parameter | Description |
 | --- | --- |
-| `archive` | [string](../core/string); or [Label](../builtins/Label); or [path](../builtins/path); required  path to the archive that will be unpacked, relative to the repository directory. |
-| `output` | [string](../core/string); or [Label](../builtins/Label); or [path](../builtins/path); default is `''`  path to the directory where the archive will be unpacked, relative to the repository directory. |
+| `archive` | [string](/versions/7.7.1/rules/lib/core/string); or [Label](/versions/7.7.1/rules/lib/builtins/Label); or [path](/versions/7.7.1/rules/lib/builtins/path); required  path to the archive that will be unpacked, relative to the repository directory. |
+| `output` | [string](/versions/7.7.1/rules/lib/core/string); or [Label](/versions/7.7.1/rules/lib/builtins/Label); or [path](/versions/7.7.1/rules/lib/builtins/path); default is `''`  path to the directory where the archive will be unpacked, relative to the repository directory. |
 | `stripPrefix` | default is `''`  a directory prefix to strip from the extracted files. Many archives contain a top-level directory that contains all files in the archive. Instead of needing to specify this prefix over and over in the `build_file`, this field can be used to strip it from extracted files. |
 | `rename_files` | default is `{}`  An optional dict specifying files to rename during the extraction. Archive entries with names exactly matching a key will be renamed to the value, prior to any directory prefix adjustment. This can be used to extract archives that contain non-Unicode filenames, or which have files that would extract to the same path on case-insensitive filesystems. |
 | `watch_archive` | default is `'auto'`  whether to [watch](#watch) the archive file. Can be the string 'yes', 'no', or 'auto'. Passing 'yes' is equivalent to immediately invoking the [`watch()`](#watch) method; passing 'no' does not attempt to watch the file; passing 'auto' will only attempt to watch the file when it is legal to do so (see `watch()` docs for more information. |
@@ -134,7 +134,7 @@ Generates a file in the repository directory with the provided content.
 
 | Parameter | Description |
 | --- | --- |
-| `path` | [string](../core/string); or [Label](../builtins/Label); or [path](../builtins/path); required  Path of the file to create, relative to the repository directory. |
+| `path` | [string](/versions/7.7.1/rules/lib/core/string); or [Label](/versions/7.7.1/rules/lib/builtins/Label); or [path](/versions/7.7.1/rules/lib/builtins/path); required  Path of the file to create, relative to the repository directory. |
 | `content` | default is `''`  The content of the file to create, empty by default. |
 | `executable` | default is `True`  Set the executable flag on the created file, true by default. |
 | `legacy_utf8` | default is `True`  Encode file content to UTF-8, true by default. Future versions will change the default and remove this parameter. |
@@ -153,8 +153,8 @@ When building incrementally, any change to the value of the variable named by `n
 
 | Parameter | Description |
 | --- | --- |
-| `name` | [string](../core/string); required  Name of desired environment variable. |
-| `default` | [string](../core/string); or `None`; default is `None`  Default value to return if `name` is not found. |
+| `name` | [string](/versions/7.7.1/rules/lib/core/string); required  Name of desired environment variable. |
+| `default` | [string](/versions/7.7.1/rules/lib/core/string); or `None`; default is `None`  Default value to return if `name` is not found. |
 
 May return `None`.
 
@@ -164,13 +164,13 @@ May return `None`.
 bool module_ctx.is_dev_dependency(tag)
 ```
 
-Returns whether the given tag was specified on the result of a [use\_extension](../globals/module#use_extension) call with `devDependency = True`.
+Returns whether the given tag was specified on the result of a [use\_extension](/versions/7.7.1/rules/lib/globals/module#use_extension) call with `devDependency = True`.
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `tag` | bazel\_module\_tag; required  A tag obtained from [bazel\_module.tags](../builtins/bazel_module#tags). |
+| `tag` | bazel\_module\_tag; required  A tag obtained from [bazel\_module.tags](/versions/7.7.1/rules/lib/builtins/bazel_module#tags). |
 
 ## modules
 
@@ -178,7 +178,7 @@ Returns whether the given tag was specified on the result of a [use\_extension](
 list module_ctx.modules
 ```
 
-A list of all the Bazel modules in the external dependency graph that use this module extension, each of which is a [bazel\_module](../builtins/bazel_module) object that exposes all the tags it specified for this extension. The iteration order of this dictionary is guaranteed to be the same as breadth-first search starting from the root module.
+A list of all the Bazel modules in the external dependency graph that use this module extension, each of which is a [bazel\_module](/versions/7.7.1/rules/lib/builtins/bazel_module) object that exposes all the tags it specified for this extension. The iteration order of this dictionary is guaranteed to be the same as breadth-first search starting from the root module.
 
 ## os
 
@@ -200,7 +200,7 @@ Returns a path from a string, label or path. If the path is relative, it will re
 
 | Parameter | Description |
 | --- | --- |
-| `path` | [string](../core/string); or [Label](../builtins/Label); or [path](../builtins/path); required  `string`, `Label` or `path` from which to create a path from. |
+| `path` | [string](/versions/7.7.1/rules/lib/core/string); or [Label](/versions/7.7.1/rules/lib/builtins/Label); or [path](/versions/7.7.1/rules/lib/builtins/path); required  `string`, `Label` or `path` from which to create a path from. |
 
 ## read
 
@@ -214,7 +214,7 @@ Reads the content of a file on the filesystem.
 
 | Parameter | Description |
 | --- | --- |
-| `path` | [string](../core/string); or [Label](../builtins/Label); or [path](../builtins/path); required  Path of the file to read from. |
+| `path` | [string](/versions/7.7.1/rules/lib/core/string); or [Label](/versions/7.7.1/rules/lib/builtins/Label); or [path](/versions/7.7.1/rules/lib/builtins/path); required  Path of the file to read from. |
 | `watch` | default is `'auto'`  Whether to [watch](#watch) the file. Can be the string 'yes', 'no', or 'auto'. Passing 'yes' is equivalent to immediately invoking the [`watch()`](#watch) method; passing 'no' does not attempt to watch the file; passing 'auto' will only attempt to watch the file when it is legal to do so (see `watch()` docs for more information. |
 
 ## report\_progress
@@ -229,7 +229,7 @@ Updates the progress status for the fetching of this repository or module extens
 
 | Parameter | Description |
 | --- | --- |
-| `status` | [string](../core/string); default is `''`  `string` describing the current status of the fetch progress. |
+| `status` | [string](/versions/7.7.1/rules/lib/core/string); default is `''`  `string` describing the current status of the fetch progress. |
 
 ## root\_module\_has\_non\_dev\_dependency
 
@@ -247,7 +247,7 @@ None module_ctx.watch(path)
 
 Tells Bazel to watch for changes to the given path, whether or not it exists, or whether it's a file or a directory. Any changes to the file or directory will invalidate this repository or module extension, and cause it to be refetched or re-evaluated next time.
 
-"Changes" include changes to the contents of the file (if the path is a file); if the path was a file but is now a directory, or vice versa; and if the path starts or stops existing. Notably, this does *not* include changes to any files under the directory if the path is a directory. For that, use [`path.readdir()`](path#readdir) instead.
+"Changes" include changes to the contents of the file (if the path is a file); if the path was a file but is now a directory, or vice versa; and if the path starts or stops existing. Notably, this does *not* include changes to any files under the directory if the path is a directory. For that, use [`path.readdir()`](/versions/7.7.1/rules/lib/builtins/path#readdir) instead.
 
 Note that attempting to watch paths inside the repo currently being fetched, or inside the working directory of the current module extension, will result in an error. A module extension attempting to watch a path outside the current Bazel workspace will also result in an error.
 
@@ -255,7 +255,7 @@ Note that attempting to watch paths inside the repo currently being fetched, or
 
 | Parameter | Description |
 | --- | --- |
-| `path` | [string](../core/string); or [Label](../builtins/Label); or [path](../builtins/path); required  Path of the file to watch. |
+| `path` | [string](/versions/7.7.1/rules/lib/core/string); or [Label](/versions/7.7.1/rules/lib/builtins/Label); or [path](/versions/7.7.1/rules/lib/builtins/path); required  Path of the file to watch. |
 
 ## which
 
diff --git a/versions/7.7.1/rules/lib/builtins/path.mdx b/versions/7.7.1/rules/lib/builtins/path.mdx
index 8b5ce98a..7fe09937 100644
--- a/versions/7.7.1/rules/lib/builtins/path.mdx
+++ b/versions/7.7.1/rules/lib/builtins/path.mdx
@@ -77,7 +77,7 @@ Returns the list of entries in the directory denoted by this path. Each entry is
 
 | Parameter | Description |
 | --- | --- |
-| `watch` | default is `'auto'`  whether Bazel should watch the list of entries in this directory and refetch the repository or re-evaluate the module extension next time when any changes are detected. Changes to detect include entry creation, deletion, and renaming. Note that this doesn't watch the *contents* of any entries in the directory. Can be the string 'yes', 'no', or 'auto'. If set to 'auto', Bazel will only watch this directory when it is legal to do so (see [`repository_ctx.watch()`](repository_ctx#watch) docs for more information). |
+| `watch` | default is `'auto'`  whether Bazel should watch the list of entries in this directory and refetch the repository or re-evaluate the module extension next time when any changes are detected. Changes to detect include entry creation, deletion, and renaming. Note that this doesn't watch the *contents* of any entries in the directory. Can be the string 'yes', 'no', or 'auto'. If set to 'auto', Bazel will only watch this directory when it is legal to do so (see [`repository_ctx.watch()`](/versions/7.7.1/rules/lib/builtins/repository_ctx#watch) docs for more information). |
 
 ## realpath
 
diff --git a/versions/7.7.1/rules/lib/builtins/repository_ctx.mdx b/versions/7.7.1/rules/lib/builtins/repository_ctx.mdx
index 91df4512..abde5a6a 100644
--- a/versions/7.7.1/rules/lib/builtins/repository_ctx.mdx
+++ b/versions/7.7.1/rules/lib/builtins/repository_ctx.mdx
@@ -48,7 +48,7 @@ Deletes a file or a directory. Returns a bool, indicating whether the file or di
 
 | Parameter | Description |
 | --- | --- |
-| `path` | [string](../core/string); or [path](../builtins/path); required  Path of the file to delete, relative to the repository directory, or absolute. Can be a path or a string. |
+| `path` | [string](/versions/7.7.1/rules/lib/core/string); or [path](/versions/7.7.1/rules/lib/builtins/path); required  Path of the file to delete, relative to the repository directory, or absolute. Can be a path or a string. |
 
 ## download
 
@@ -62,8 +62,8 @@ Downloads a file to the output path for the provided url and returns a struct co
 
 | Parameter | Description |
 | --- | --- |
-| `url` | [string](../core/string); or Iterable of [string](../core/string)s; required  List of mirror URLs referencing the same file. |
-| `output` | [string](../core/string); or [Label](../builtins/Label); or [path](../builtins/path); default is `''`  path to the output file, relative to the repository directory. |
+| `url` | [string](/versions/7.7.1/rules/lib/core/string); or Iterable of [string](/versions/7.7.1/rules/lib/core/string)s; required  List of mirror URLs referencing the same file. |
+| `output` | [string](/versions/7.7.1/rules/lib/core/string); or [Label](/versions/7.7.1/rules/lib/builtins/Label); or [path](/versions/7.7.1/rules/lib/builtins/path); default is `''`  path to the output file, relative to the repository directory. |
 | `sha256` | default is `''`  The expected SHA-256 hash of the file downloaded. This must match the SHA-256 hash of the file downloaded. It is a security risk to omit the SHA-256 as remote files can change. At best omitting this field will make your build non-hermetic. It is optional to make development easier but should be set before shipping. If provided, the repository cache will first be checked for a file with the given hash; a download will only be attempted if the file was not found in the cache. After a successful download, the file will be added to the cache. |
 | `executable` | default is `False`  Set the executable flag on the created file, false by default. |
 | `allow_fail` | default is `False`  If set, indicate the error in the return value instead of raising an error for failed downloads. |
@@ -85,8 +85,8 @@ Downloads a file to the output path for the provided url, extracts it, and retur
 
 | Parameter | Description |
 | --- | --- |
-| `url` | [string](../core/string); or Iterable of [string](../core/string)s; required  List of mirror URLs referencing the same file. |
-| `output` | [string](../core/string); or [Label](../builtins/Label); or [path](../builtins/path); default is `''`  Path to the directory where the archive will be unpacked, relative to the repository directory. |
+| `url` | [string](/versions/7.7.1/rules/lib/core/string); or Iterable of [string](/versions/7.7.1/rules/lib/core/string)s; required  List of mirror URLs referencing the same file. |
+| `output` | [string](/versions/7.7.1/rules/lib/core/string); or [Label](/versions/7.7.1/rules/lib/builtins/Label); or [path](/versions/7.7.1/rules/lib/builtins/path); default is `''`  Path to the directory where the archive will be unpacked, relative to the repository directory. |
 | `sha256` | default is `''`  The expected SHA-256 hash of the file downloaded. This must match the SHA-256 hash of the file downloaded. It is a security risk to omit the SHA-256 as remote files can change. At best omitting this field will make your build non-hermetic. It is optional to make development easier but should be set before shipping. If provided, the repository cache will first be checked for a file with the given hash; a download will only be attempted if the file was not found in the cache. After a successful download, the file will be added to the cache. |
 | `type` | default is `''`  The archive type of the downloaded file. By default, the archive type is determined from the file extension of the URL. If the file has no extension, you can explicitly specify either "zip", "jar", "war", "aar", "nupkg", "tar", "tar.gz", "tgz", "tar.xz", "txz", ".tar.zst", ".tzst", "tar.bz2", ".tbz", ".ar", or ".deb" here. |
 | `stripPrefix` | default is `''`  A directory prefix to strip from the extracted files. Many archives contain a top-level directory that contains all files in the archive. Instead of needing to specify this prefix over and over in the `build_file`, this field can be used to strip it from extracted files. |
@@ -127,8 +127,8 @@ Extract an archive to the repository directory.
 
 | Parameter | Description |
 | --- | --- |
-| `archive` | [string](../core/string); or [Label](../builtins/Label); or [path](../builtins/path); required  path to the archive that will be unpacked, relative to the repository directory. |
-| `output` | [string](../core/string); or [Label](../builtins/Label); or [path](../builtins/path); default is `''`  path to the directory where the archive will be unpacked, relative to the repository directory. |
+| `archive` | [string](/versions/7.7.1/rules/lib/core/string); or [Label](/versions/7.7.1/rules/lib/builtins/Label); or [path](/versions/7.7.1/rules/lib/builtins/path); required  path to the archive that will be unpacked, relative to the repository directory. |
+| `output` | [string](/versions/7.7.1/rules/lib/core/string); or [Label](/versions/7.7.1/rules/lib/builtins/Label); or [path](/versions/7.7.1/rules/lib/builtins/path); default is `''`  path to the directory where the archive will be unpacked, relative to the repository directory. |
 | `stripPrefix` | default is `''`  a directory prefix to strip from the extracted files. Many archives contain a top-level directory that contains all files in the archive. Instead of needing to specify this prefix over and over in the `build_file`, this field can be used to strip it from extracted files. |
 | `rename_files` | default is `{}`  An optional dict specifying files to rename during the extraction. Archive entries with names exactly matching a key will be renamed to the value, prior to any directory prefix adjustment. This can be used to extract archives that contain non-Unicode filenames, or which have files that would extract to the same path on case-insensitive filesystems. |
 | `watch_archive` | default is `'auto'`  whether to [watch](#watch) the archive file. Can be the string 'yes', 'no', or 'auto'. Passing 'yes' is equivalent to immediately invoking the [`watch()`](#watch) method; passing 'no' does not attempt to watch the file; passing 'auto' will only attempt to watch the file when it is legal to do so (see `watch()` docs for more information. |
@@ -145,7 +145,7 @@ Generates a file in the repository directory with the provided content.
 
 | Parameter | Description |
 | --- | --- |
-| `path` | [string](../core/string); or [Label](../builtins/Label); or [path](../builtins/path); required  Path of the file to create, relative to the repository directory. |
+| `path` | [string](/versions/7.7.1/rules/lib/core/string); or [Label](/versions/7.7.1/rules/lib/builtins/Label); or [path](/versions/7.7.1/rules/lib/builtins/path); required  Path of the file to create, relative to the repository directory. |
 | `content` | default is `''`  The content of the file to create, empty by default. |
 | `executable` | default is `True`  Set the executable flag on the created file, true by default. |
 | `legacy_utf8` | default is `True`  Encode file content to UTF-8, true by default. Future versions will change the default and remove this parameter. |
@@ -164,8 +164,8 @@ When building incrementally, any change to the value of the variable named by `n
 
 | Parameter | Description |
 | --- | --- |
-| `name` | [string](../core/string); required  Name of desired environment variable. |
-| `default` | [string](../core/string); or `None`; default is `None`  Default value to return if `name` is not found. |
+| `name` | [string](/versions/7.7.1/rules/lib/core/string); required  Name of desired environment variable. |
+| `default` | [string](/versions/7.7.1/rules/lib/core/string); or `None`; default is `None`  Default value to return if `name` is not found. |
 
 May return `None`.
 
@@ -205,7 +205,7 @@ Apply a patch file to the root directory of external repository. The patch file
 
 | Parameter | Description |
 | --- | --- |
-| `patch_file` | [string](../core/string); or [Label](../builtins/Label); or [path](../builtins/path); required  The patch file to apply, it can be label, relative path or absolute path. If it's a relative path, it will resolve to the repository directory. |
+| `patch_file` | [string](/versions/7.7.1/rules/lib/core/string); or [Label](/versions/7.7.1/rules/lib/builtins/Label); or [path](/versions/7.7.1/rules/lib/builtins/path); required  The patch file to apply, it can be label, relative path or absolute path. If it's a relative path, it will resolve to the repository directory. |
 | `strip` | default is `0`  Strip the specified number of leading components from file names. |
 | `watch_patch` | default is `'auto'`  Whether to [watch](#watch) the patch file. Can be the string 'yes', 'no', or 'auto'. Passing 'yes' is equivalent to immediately invoking the [`watch()`](#watch) method; passing 'no' does not attempt to watch the file; passing 'auto' will only attempt to watch the file when it is legal to do so (see `watch()` docs for more information. |
 
@@ -221,7 +221,7 @@ Returns a path from a string, label or path. If the path is relative, it will re
 
 | Parameter | Description |
 | --- | --- |
-| `path` | [string](../core/string); or [Label](../builtins/Label); or [path](../builtins/path); required  `string`, `Label` or `path` from which to create a path from. |
+| `path` | [string](/versions/7.7.1/rules/lib/core/string); or [Label](/versions/7.7.1/rules/lib/builtins/Label); or [path](/versions/7.7.1/rules/lib/builtins/path); required  `string`, `Label` or `path` from which to create a path from. |
 
 ## read
 
@@ -235,7 +235,7 @@ Reads the content of a file on the filesystem.
 
 | Parameter | Description |
 | --- | --- |
-| `path` | [string](../core/string); or [Label](../builtins/Label); or [path](../builtins/path); required  Path of the file to read from. |
+| `path` | [string](/versions/7.7.1/rules/lib/core/string); or [Label](/versions/7.7.1/rules/lib/builtins/Label); or [path](/versions/7.7.1/rules/lib/builtins/path); required  Path of the file to read from. |
 | `watch` | default is `'auto'`  Whether to [watch](#watch) the file. Can be the string 'yes', 'no', or 'auto'. Passing 'yes' is equivalent to immediately invoking the [`watch()`](#watch) method; passing 'no' does not attempt to watch the file; passing 'auto' will only attempt to watch the file when it is legal to do so (see `watch()` docs for more information. |
 
 ## report\_progress
@@ -250,7 +250,7 @@ Updates the progress status for the fetching of this repository or module extens
 
 | Parameter | Description |
 | --- | --- |
-| `status` | [string](../core/string); default is `''`  `string` describing the current status of the fetch progress. |
+| `status` | [string](/versions/7.7.1/rules/lib/core/string); default is `''`  `string` describing the current status of the fetch progress. |
 
 ## symlink
 
@@ -264,8 +264,8 @@ Creates a symlink on the filesystem.
 
 | Parameter | Description |
 | --- | --- |
-| `target` | [string](../core/string); or [Label](../builtins/Label); or [path](../builtins/path); required  The path that the symlink should point to. |
-| `link_name` | [string](../core/string); or [Label](../builtins/Label); or [path](../builtins/path); required  The path of the symlink to create. |
+| `target` | [string](/versions/7.7.1/rules/lib/core/string); or [Label](/versions/7.7.1/rules/lib/builtins/Label); or [path](/versions/7.7.1/rules/lib/builtins/path); required  The path that the symlink should point to. |
+| `link_name` | [string](/versions/7.7.1/rules/lib/core/string); or [Label](/versions/7.7.1/rules/lib/builtins/Label); or [path](/versions/7.7.1/rules/lib/builtins/path); required  The path of the symlink to create. |
 
 ## template
 
@@ -279,8 +279,8 @@ Generates a new file using a `template`. Every occurrence in `template` of a key
 
 | Parameter | Description |
 | --- | --- |
-| `path` | [string](../core/string); or [Label](../builtins/Label); or [path](../builtins/path); required  Path of the file to create, relative to the repository directory. |
-| `template` | [string](../core/string); or [Label](../builtins/Label); or [path](../builtins/path); required  Path to the template file. |
+| `path` | [string](/versions/7.7.1/rules/lib/core/string); or [Label](/versions/7.7.1/rules/lib/builtins/Label); or [path](/versions/7.7.1/rules/lib/builtins/path); required  Path of the file to create, relative to the repository directory. |
+| `template` | [string](/versions/7.7.1/rules/lib/core/string); or [Label](/versions/7.7.1/rules/lib/builtins/Label); or [path](/versions/7.7.1/rules/lib/builtins/path); required  Path to the template file. |
 | `substitutions` | default is `{}`  Substitutions to make when expanding the template. |
 | `executable` | default is `True`  Set the executable flag on the created file, true by default. |
 | `watch_template` | default is `'auto'`  Whether to [watch](#watch) the template file. Can be the string 'yes', 'no', or 'auto'. Passing 'yes' is equivalent to immediately invoking the [`watch()`](#watch) method; passing 'no' does not attempt to watch the file; passing 'auto' will only attempt to watch the file when it is legal to do so (see `watch()` docs for more information. |
@@ -293,7 +293,7 @@ None repository_ctx.watch(path)
 
 Tells Bazel to watch for changes to the given path, whether or not it exists, or whether it's a file or a directory. Any changes to the file or directory will invalidate this repository or module extension, and cause it to be refetched or re-evaluated next time.
 
-"Changes" include changes to the contents of the file (if the path is a file); if the path was a file but is now a directory, or vice versa; and if the path starts or stops existing. Notably, this does *not* include changes to any files under the directory if the path is a directory. For that, use [`path.readdir()`](path#readdir) instead.
+"Changes" include changes to the contents of the file (if the path is a file); if the path was a file but is now a directory, or vice versa; and if the path starts or stops existing. Notably, this does *not* include changes to any files under the directory if the path is a directory. For that, use [`path.readdir()`](/versions/7.7.1/rules/lib/builtins/path#readdir) instead.
 
 Note that attempting to watch paths inside the repo currently being fetched, or inside the working directory of the current module extension, will result in an error. A module extension attempting to watch a path outside the current Bazel workspace will also result in an error.
 
@@ -301,7 +301,7 @@ Note that attempting to watch paths inside the repo currently being fetched, or
 
 | Parameter | Description |
 | --- | --- |
-| `path` | [string](../core/string); or [Label](../builtins/Label); or [path](../builtins/path); required  Path of the file to watch. |
+| `path` | [string](/versions/7.7.1/rules/lib/core/string); or [Label](/versions/7.7.1/rules/lib/builtins/Label); or [path](/versions/7.7.1/rules/lib/builtins/path); required  Path of the file to watch. |
 
 ## watch\_tree
 
@@ -317,7 +317,7 @@ Note that attempting to watch paths inside the repo currently being fetched will
 
 | Parameter | Description |
 | --- | --- |
-| `path` | [string](../core/string); or [Label](../builtins/Label); or [path](../builtins/path); required  Path of the directory tree to watch. |
+| `path` | [string](/versions/7.7.1/rules/lib/core/string); or [Label](/versions/7.7.1/rules/lib/builtins/Label); or [path](/versions/7.7.1/rules/lib/builtins/path); required  Path of the directory tree to watch. |
 
 ## which
 
diff --git a/versions/7.7.1/rules/lib/builtins/rule_attributes.mdx b/versions/7.7.1/rules/lib/builtins/rule_attributes.mdx
index 3b9236b7..8d3a1ff1 100644
--- a/versions/7.7.1/rules/lib/builtins/rule_attributes.mdx
+++ b/versions/7.7.1/rules/lib/builtins/rule_attributes.mdx
@@ -18,7 +18,7 @@ Information about attributes of a rule an aspect is applied to.
 struct rule_attributes.attr
 ```
 
-A struct to access the values of the [attributes](https://bazel.build/versions/7.7.1/extending/rules#attributes). The values are provided by the user (if not, a default value is used). The attributes of the struct and the types of their values correspond to the keys and values of the [`attrs` dict](../globals/bzl#rule.attrs) provided to the [`rule` function](../globals/bzl#rule). [See example of use](https://github.com/bazelbuild/examples/blob/main/rules/attributes/printer.bzl).
+A struct to access the values of the [attributes](https://bazel.build/versions/7.7.1/extending/rules#attributes). The values are provided by the user (if not, a default value is used). The attributes of the struct and the types of their values correspond to the keys and values of the [`attrs` dict](/versions/7.7.1/rules/lib/globals/bzl#rule.attrs) provided to the [`rule` function](/versions/7.7.1/rules/lib/globals/bzl#rule). [See example of use](https://github.com/bazelbuild/examples/blob/main/rules/attributes/printer.bzl).
 
 ## executable
 
@@ -26,7 +26,7 @@ A struct to access the values of the [attributes](https://bazel.build/versions/7
 struct rule_attributes.executable
 ```
 
-A `struct` containing executable files defined in [label type attributes](../toplevel/attr#label) marked as [`executable=True`](../toplevel/attr#label.executable). The struct fields correspond to the attribute names. Each value in the struct is either a [`File`](../builtins/File) or `None`. If an optional attribute is not specified in the rule then the corresponding struct value is `None`. If a label type is not marked as `executable=True`, no corresponding struct field is generated. [See example of use](https://github.com/bazelbuild/examples/blob/main/rules/actions_run/execute.bzl).
+A `struct` containing executable files defined in [label type attributes](/versions/7.7.1/rules/lib/toplevel/attr#label) marked as [`executable=True`](/versions/7.7.1/rules/lib/toplevel/attr#label.executable). The struct fields correspond to the attribute names. Each value in the struct is either a [`File`](/versions/7.7.1/rules/lib/builtins/File) or `None`. If an optional attribute is not specified in the rule then the corresponding struct value is `None`. If a label type is not marked as `executable=True`, no corresponding struct field is generated. [See example of use](https://github.com/bazelbuild/examples/blob/main/rules/actions_run/execute.bzl).
 
 ## file
 
@@ -34,7 +34,7 @@ A `struct` containing executable files defined in [label type attributes](../top
 struct rule_attributes.file
 ```
 
-A `struct` containing files defined in [label type attributes](../toplevel/attr#label) marked as [`allow_single_file`](../toplevel/attr#label.allow_single_file). The struct fields correspond to the attribute names. The struct value is always a [`File`](../builtins/File) or `None`. If an optional attribute is not specified in the rule then the corresponding struct value is `None`. If a label type is not marked as `allow_single_file`, no corresponding struct field is generated. It is a shortcut for:
+A `struct` containing files defined in [label type attributes](/versions/7.7.1/rules/lib/toplevel/attr#label) marked as [`allow_single_file`](/versions/7.7.1/rules/lib/toplevel/attr#label.allow_single_file). The struct fields correspond to the attribute names. The struct value is always a [`File`](/versions/7.7.1/rules/lib/builtins/File) or `None`. If an optional attribute is not specified in the rule then the corresponding struct value is `None`. If a label type is not marked as `allow_single_file`, no corresponding struct field is generated. It is a shortcut for:
 
 ```
 list(ctx.attr..files)[0]
@@ -48,7 +48,7 @@ In other words, use `file` to access the (singular) [default output](https://baz
 struct rule_attributes.files
 ```
 
-A `struct` containing files defined in [label](../toplevel/attr#label) or [label list](../toplevel/attr#label_list) type attributes. The struct fields correspond to the attribute names. The struct values are `list` of [`File`](../builtins/File)s. It is a shortcut for:
+A `struct` containing files defined in [label](/versions/7.7.1/rules/lib/toplevel/attr#label) or [label list](/versions/7.7.1/rules/lib/toplevel/attr#label_list) type attributes. The struct fields correspond to the attribute names. The struct values are `list` of [`File`](/versions/7.7.1/rules/lib/builtins/File)s. It is a shortcut for:
 
 ```
 [f for t in ctx.attr. for f in t.files]
diff --git a/versions/7.7.1/rules/lib/builtins/runfiles.mdx b/versions/7.7.1/rules/lib/builtins/runfiles.mdx
index 86b6e46f..c1139150 100644
--- a/versions/7.7.1/rules/lib/builtins/runfiles.mdx
+++ b/versions/7.7.1/rules/lib/builtins/runfiles.mdx
@@ -2,7 +2,7 @@
 title: 'runfiles'
 ---
 
-A container of information regarding a set of files required at runtime execution. This object should be passed via [DefaultInfo](../providers/DefaultInfo) in order to tell the build system about the runfiles needed by the outputs produced by the rule.
+A container of information regarding a set of files required at runtime execution. This object should be passed via [DefaultInfo](/versions/7.7.1/rules/lib/providers/DefaultInfo) in order to tell the build system about the runfiles needed by the outputs produced by the rule.
 
 See [runfiles guide](https://bazel.build/versions/7.7.1/extending/rules#runfiles) for details.
 
@@ -59,7 +59,7 @@ Returns a new runfiles object that includes all the contents of this one and of
 
 | Parameter | Description |
 | --- | --- |
-| `other` | [sequence](../core/list) of [runfiles](../builtins/runfiles)s; required  The sequence of runfiles objects to merge into this. |
+| `other` | [sequence](/versions/7.7.1/rules/lib/core/list) of [runfiles](/versions/7.7.1/rules/lib/builtins/runfiles)s; required  The sequence of runfiles objects to merge into this. |
 
 ## root\_symlinks
 
diff --git a/versions/7.7.1/rules/lib/builtins/transition.mdx b/versions/7.7.1/rules/lib/builtins/transition.mdx
index e1386adc..84b604bd 100644
--- a/versions/7.7.1/rules/lib/builtins/transition.mdx
+++ b/versions/7.7.1/rules/lib/builtins/transition.mdx
@@ -39,5 +39,5 @@ For more details see [here](https://bazel.build/versions/7.7.1/rules/config#user
 | Parameter | Description |
 | --- | --- |
 | `implementation` | required  The function implementing this transition. This function always has two parameters: `settings` and `attr`. The `settings` param is a dictionary whose set of keys is defined by the inputs parameter. So, for each build setting `--//foo=bar`, if `inputs` contains `//foo`, `settings` will have an entry `settings['//foo']='bar'`. The `attr` param is a reference to `ctx.attr`. This gives the implementation function access to the rule's attributes to make attribute-parameterized transitions possible. This function must return a `dict` from build setting identifier to build setting value; this represents the configuration transition: for each entry in the returned `dict`, the transition updates that setting to the new value. All other settings are unchanged. This function can also return a `list` of `dict`s or a `dict` of `dict`s in the case of a split transition. |
-| `inputs` | [sequence](../core/list) of [string](../core/string)s; required  List of build settings that can be read by this transition. This becomes the key set of the settings parameter of the implementation function parameter. |
-| `outputs` | [sequence](../core/list) of [string](../core/string)s; required  List of build settings that can be written by this transition. This must be a superset of the key set of the dictionary returned by this transition. |
\ No newline at end of file
+| `inputs` | [sequence](/versions/7.7.1/rules/lib/core/list) of [string](/versions/7.7.1/rules/lib/core/string)s; required  List of build settings that can be read by this transition. This becomes the key set of the settings parameter of the implementation function parameter. |
+| `outputs` | [sequence](/versions/7.7.1/rules/lib/core/list) of [string](/versions/7.7.1/rules/lib/core/string)s; required  List of build settings that can be written by this transition. This must be a superset of the key set of the dictionary returned by this transition. |
\ No newline at end of file
diff --git a/versions/7.7.1/rules/lib/core/bool.mdx b/versions/7.7.1/rules/lib/core/bool.mdx
index 52be3664..e679feae 100644
--- a/versions/7.7.1/rules/lib/core/bool.mdx
+++ b/versions/7.7.1/rules/lib/core/bool.mdx
@@ -2,4 +2,4 @@
 title: 'bool'
 ---
 
-A type to represent booleans. There are only two possible values: True and False. Any value can be converted to a boolean using the [bool](../globals/all#bool) function.
\ No newline at end of file
+A type to represent booleans. There are only two possible values: True and False. Any value can be converted to a boolean using the [bool](/versions/7.7.1/rules/lib/globals/all#bool) function.
\ No newline at end of file
diff --git a/versions/7.7.1/rules/lib/core/dict.mdx b/versions/7.7.1/rules/lib/core/dict.mdx
index 0fd1c419..cdf26d80 100644
--- a/versions/7.7.1/rules/lib/core/dict.mdx
+++ b/versions/7.7.1/rules/lib/core/dict.mdx
@@ -22,7 +22,7 @@ There are four ways to construct a dictionary:
      {i: 2*i for i in range(3)}  # {0: 0, 1: 2, 2: 4}
      ```
 
-     - A call to the built-in [dict](../globals/all#dict) function returns a dictionary containing the specified entries, which are inserted in argument order, positional arguments before named. As with comprehensions, duplicate keys are permitted.- The union expression `x | y` yields a new dictionary by combining two existing dictionaries. If the two dictionaries have a key `k` in common, the right hand side dictionary's value of the key (in other words, `y[k]`) wins. The `|=` variant of the union operator modifies a dictionary in-place. Example:
+     - A call to the built-in [dict](/versions/7.7.1/rules/lib/globals/all#dict) function returns a dictionary containing the specified entries, which are inserted in argument order, positional arguments before named. As with comprehensions, duplicate keys are permitted.- The union expression `x | y` yields a new dictionary by combining two existing dictionaries. If the two dictionaries have a key `k` in common, the right hand side dictionary's value of the key (in other words, `y[k]`) wins. The `|=` variant of the union operator modifies a dictionary in-place. Example:
 
          ```
          d = {"foo": "FOO", "bar": "BAR"} | {"foo": "FOO2", "baz": "BAZ"}
diff --git a/versions/7.7.1/rules/lib/core/list.mdx b/versions/7.7.1/rules/lib/core/list.mdx
index a04edd62..9f941d75 100644
--- a/versions/7.7.1/rules/lib/core/list.mdx
+++ b/versions/7.7.1/rules/lib/core/list.mdx
@@ -91,8 +91,8 @@ Returns the index in the list of the first item whose value is x. It is an error
 | Parameter | Description |
 | --- | --- |
 | `x` | required |
-| `start` | [int](../core/int); or `None`; default is `None`  The start index of the list portion to inspect. |
-| `end` | [int](../core/int); or `None`; default is `None`  The end index of the list portion to inspect. |
+| `start` | [int](/versions/7.7.1/rules/lib/core/int); or `None`; default is `None`  The start index of the list portion to inspect. |
+| `end` | [int](/versions/7.7.1/rules/lib/core/int); or `None`; default is `None`  The end index of the list portion to inspect. |
 
 ## insert
 
@@ -121,7 +121,7 @@ Removes the item at the given position in the list, and returns it. If no `index
 
 | Parameter | Description |
 | --- | --- |
-| `i` | [int](../core/int); or `None`; default is `-1`  The index of the item. |
+| `i` | [int](/versions/7.7.1/rules/lib/core/int); or `None`; default is `-1`  The index of the item. |
 
 ## remove
 
diff --git a/versions/7.7.1/rules/lib/core/string.mdx b/versions/7.7.1/rules/lib/core/string.mdx
index b9a7508b..fbd46233 100644
--- a/versions/7.7.1/rules/lib/core/string.mdx
+++ b/versions/7.7.1/rules/lib/core/string.mdx
@@ -82,8 +82,8 @@ Returns the number of (non-overlapping) occurrences of substring `sub` in string
 | Parameter | Description |
 | --- | --- |
 | `sub` | required |
-| `start` | [int](../core/int); or `None`; default is `0` |
-| `end` | [int](../core/int); or `None`; default is `None`  optional position before which to restrict to search. |
+| `start` | [int](/versions/7.7.1/rules/lib/core/int); or `None`; default is `0` |
+| `end` | [int](/versions/7.7.1/rules/lib/core/int); or `None`; default is `None`  optional position before which to restrict to search. |
 
 ## elems
 
@@ -105,9 +105,9 @@ Returns True if the string ends with `sub`, otherwise False, optionally restrict
 
 | Parameter | Description |
 | --- | --- |
-| `sub` | [string](../core/string); or [tuple](../core/tuple) of [string](../core/string)s; required  The suffix (or tuple of alternative suffixes) to match. |
-| `start` | [int](../core/int); or `None`; default is `0`  Test beginning at this position. |
-| `end` | [int](../core/int); or `None`; default is `None`  optional position at which to stop comparing. |
+| `sub` | [string](/versions/7.7.1/rules/lib/core/string); or [tuple](/versions/7.7.1/rules/lib/core/tuple) of [string](/versions/7.7.1/rules/lib/core/string)s; required  The suffix (or tuple of alternative suffixes) to match. |
+| `start` | [int](/versions/7.7.1/rules/lib/core/int); or `None`; default is `0`  Test beginning at this position. |
+| `end` | [int](/versions/7.7.1/rules/lib/core/int); or `None`; default is `None`  optional position at which to stop comparing. |
 
 ## find
 
@@ -122,8 +122,8 @@ Returns the first index where `sub` is found, or -1 if no such index exists, opt
 | Parameter | Description |
 | --- | --- |
 | `sub` | required  The substring to find. |
-| `start` | [int](../core/int); or `None`; default is `0`  Restrict to search from this position. |
-| `end` | [int](../core/int); or `None`; default is `None`  optional position before which to restrict to search. |
+| `start` | [int](/versions/7.7.1/rules/lib/core/int); or `None`; default is `0`  Restrict to search from this position. |
+| `end` | [int](/versions/7.7.1/rules/lib/core/int); or `None`; default is `None`  optional position before which to restrict to search. |
 
 ## format
 
@@ -131,7 +131,7 @@ Returns the first index where `sub` is found, or -1 if no such index exists, opt
 string string.format(*args, **kwargs)
 ```
 
-Perform string interpolation. Format strings contain replacement fields surrounded by curly braces `{}`. Anything that is not contained in braces is considered literal text, which is copied unchanged to the output.If you need to include a brace character in the literal text, it can be escaped by doubling: `{{` and `}}`A replacement field can be either a name, a number, or empty. Values are converted to strings using the [str](../globals/all#str) function.
+Perform string interpolation. Format strings contain replacement fields surrounded by curly braces `{}`. Anything that is not contained in braces is considered literal text, which is copied unchanged to the output.If you need to include a brace character in the literal text, it can be escaped by doubling: `{{` and `}}`A replacement field can be either a name, a number, or empty. Values are converted to strings using the [str](/versions/7.7.1/rules/lib/globals/all#str) function.
 
 ```
 # Access in order:
@@ -162,8 +162,8 @@ Returns the first index where `sub` is found, or raises an error if no such inde
 | Parameter | Description |
 | --- | --- |
 | `sub` | required  The substring to find. |
-| `start` | [int](../core/int); or `None`; default is `0`  Restrict to search from this position. |
-| `end` | [int](../core/int); or `None`; default is `None`  optional position before which to restrict to search. |
+| `start` | [int](/versions/7.7.1/rules/lib/core/int); or `None`; default is `0`  Restrict to search from this position. |
+| `end` | [int](/versions/7.7.1/rules/lib/core/int); or `None`; default is `None`  optional position before which to restrict to search. |
 
 ## isalnum
 
@@ -263,7 +263,7 @@ Returns a copy of the string where leading characters that appear in `chars` are
 
 | Parameter | Description |
 | --- | --- |
-| `chars` | [string](../core/string); or `None`; default is `None`  The characters to remove, or all whitespace if None. |
+| `chars` | [string](/versions/7.7.1/rules/lib/core/string); or `None`; default is `None`  The characters to remove, or all whitespace if None. |
 
 ## partition
 
@@ -336,8 +336,8 @@ Returns the last index where `sub` is found, or -1 if no such index exists, opti
 | Parameter | Description |
 | --- | --- |
 | `sub` | required  The substring to find. |
-| `start` | [int](../core/int); or `None`; default is `0`  Restrict to search from this position. |
-| `end` | [int](../core/int); or `None`; default is `None`  optional position before which to restrict to search. |
+| `start` | [int](/versions/7.7.1/rules/lib/core/int); or `None`; default is `0`  Restrict to search from this position. |
+| `end` | [int](/versions/7.7.1/rules/lib/core/int); or `None`; default is `None`  optional position before which to restrict to search. |
 
 ## rindex
 
@@ -352,8 +352,8 @@ Returns the last index where `sub` is found, or raises an error if no such index
 | Parameter | Description |
 | --- | --- |
 | `sub` | required  The substring to find. |
-| `start` | [int](../core/int); or `None`; default is `0`  Restrict to search from this position. |
-| `end` | [int](../core/int); or `None`; default is `None`  optional position before which to restrict to search. |
+| `start` | [int](/versions/7.7.1/rules/lib/core/int); or `None`; default is `0`  Restrict to search from this position. |
+| `end` | [int](/versions/7.7.1/rules/lib/core/int); or `None`; default is `None`  optional position before which to restrict to search. |
 
 ## rpartition
 
@@ -382,7 +382,7 @@ Returns a list of all the words in the string, using `sep` as the separator, opt
 | Parameter | Description |
 | --- | --- |
 | `sep` | required  The string to split on. |
-| `maxsplit` | [int](../core/int); or `None`; default is `None`  The maximum number of splits. |
+| `maxsplit` | [int](/versions/7.7.1/rules/lib/core/int); or `None`; default is `None`  The maximum number of splits. |
 
 ## rstrip
 
@@ -400,7 +400,7 @@ Returns a copy of the string where trailing characters that appear in `chars` ar
 
 | Parameter | Description |
 | --- | --- |
-| `chars` | [string](../core/string); or `None`; default is `None`  The characters to remove, or all whitespace if None. |
+| `chars` | [string](/versions/7.7.1/rules/lib/core/string); or `None`; default is `None`  The characters to remove, or all whitespace if None. |
 
 ## split
 
@@ -415,7 +415,7 @@ Returns a list of all the words in the string, using `sep` as the separator, opt
 | Parameter | Description |
 | --- | --- |
 | `sep` | required  The string to split on. |
-| `maxsplit` | [int](../core/int); or `None`; default is `None`  The maximum number of splits. |
+| `maxsplit` | [int](/versions/7.7.1/rules/lib/core/int); or `None`; default is `None`  The maximum number of splits. |
 
 ## splitlines
 
@@ -443,9 +443,9 @@ Returns True if the string starts with `sub`, otherwise False, optionally restri
 
 | Parameter | Description |
 | --- | --- |
-| `sub` | [string](../core/string); or [tuple](../core/tuple) of [string](../core/string)s; required  The prefix (or tuple of alternative prefixes) to match. |
-| `start` | [int](../core/int); or `None`; default is `0`  Test beginning at this position. |
-| `end` | [int](../core/int); or `None`; default is `None`  Stop comparing at this position. |
+| `sub` | [string](/versions/7.7.1/rules/lib/core/string); or [tuple](/versions/7.7.1/rules/lib/core/tuple) of [string](/versions/7.7.1/rules/lib/core/string)s; required  The prefix (or tuple of alternative prefixes) to match. |
+| `start` | [int](/versions/7.7.1/rules/lib/core/int); or `None`; default is `0`  Test beginning at this position. |
+| `end` | [int](/versions/7.7.1/rules/lib/core/int); or `None`; default is `None`  Stop comparing at this position. |
 
 ## strip
 
@@ -463,7 +463,7 @@ Returns a copy of the string where leading or trailing characters that appear in
 
 | Parameter | Description |
 | --- | --- |
-| `chars` | [string](../core/string); or `None`; default is `None`  The characters to remove, or all whitespace if None. |
+| `chars` | [string](/versions/7.7.1/rules/lib/core/string); or `None`; default is `None`  The characters to remove, or all whitespace if None. |
 
 ## title
 
diff --git a/versions/7.7.1/rules/lib/fragments.mdx b/versions/7.7.1/rules/lib/fragments.mdx
index 2f786bc4..da46b61d 100644
--- a/versions/7.7.1/rules/lib/fragments.mdx
+++ b/versions/7.7.1/rules/lib/fragments.mdx
@@ -2,7 +2,7 @@
 title: 'Configuration Fragments'
 ---
 
-Configuration fragments give rules access to language-specific parts of [configuration](builtins/configuration).
+Configuration fragments give rules access to language-specific parts of [configuration](/versions/7.7.1/rules/lib/builtins/configuration).
 
 Rule implementations can get them using `ctx.fragments.[fragment name]`
 
diff --git a/versions/7.7.1/rules/lib/fragments/coverage.mdx b/versions/7.7.1/rules/lib/fragments/coverage.mdx
index 45e1217d..fbaab22f 100644
--- a/versions/7.7.1/rules/lib/fragments/coverage.mdx
+++ b/versions/7.7.1/rules/lib/fragments/coverage.mdx
@@ -14,7 +14,7 @@ A configuration fragment representing the coverage configuration.
 Label coverage.output_generator
 ```
 
-Returns the label pointed to by the [`--coverage_output_generator`](https://bazel.build/versions/7.7.1/reference/command-line-reference#flag--coverage_output_generator) option if coverage collection is enabled, otherwise returns `None`. Can be accessed with [`configuration_field`](../globals/bzl#configuration_field):
+Returns the label pointed to by the [`--coverage_output_generator`](https://bazel.build/versions/7.7.1/reference/command-line-reference#flag--coverage_output_generator) option if coverage collection is enabled, otherwise returns `None`. Can be accessed with [`configuration_field`](/versions/7.7.1/rules/lib/globals/bzl#configuration_field):
 
 ```
 attr.label(
diff --git a/versions/7.7.1/rules/lib/fragments/cpp.mdx b/versions/7.7.1/rules/lib/fragments/cpp.mdx
index d5cf0a60..c7b9a085 100644
--- a/versions/7.7.1/rules/lib/fragments/cpp.mdx
+++ b/versions/7.7.1/rules/lib/fragments/cpp.mdx
@@ -55,7 +55,7 @@ The flags passed to Bazel by [`--copt`](/versions/7.7.1/docs/user-manual#flag--c
 Label cpp.custom_malloc
 ```
 
-Returns label pointed to by [`--custom_malloc`](/versions/7.7.1/docs/user-manual#flag--custom_malloc) option. Can be accessed with [`configuration_field`](../globals/bzl#configuration_field):
+Returns label pointed to by [`--custom_malloc`](/versions/7.7.1/docs/user-manual#flag--custom_malloc) option. Can be accessed with [`configuration_field`](/versions/7.7.1/rules/lib/globals/bzl#configuration_field):
 
 ```
 attr.label(
diff --git a/versions/7.7.1/rules/lib/globals/all.mdx b/versions/7.7.1/rules/lib/globals/all.mdx
index 35a9b985..a7b3634d 100644
--- a/versions/7.7.1/rules/lib/globals/all.mdx
+++ b/versions/7.7.1/rules/lib/globals/all.mdx
@@ -49,7 +49,7 @@ abs(-2.3) == 2.3
 
 | Parameter | Description |
 | --- | --- |
-| `x` | [int](../core/int); or [float](../core/float); required  A number (int or float) |
+| `x` | [int](/versions/7.7.1/rules/lib/core/int); or [float](/versions/7.7.1/rules/lib/core/float); required  A number (int or float) |
 
 ## all
 
@@ -109,7 +109,7 @@ Constructor for the bool type. It returns `False` if the object is `None`, `Fals
 dict dict(pairs=[], **kwargs)
 ```
 
-Creates a [dictionary](../core/dict) from an optional positional argument and an optional set of keyword arguments. In the case where the same key is given multiple times, the last value will be used. Entries supplied via keyword arguments are considered to come after entries supplied via the positional argument.
+Creates a [dictionary](/versions/7.7.1/rules/lib/core/dict) from an optional positional argument and an optional set of keyword arguments. In the case where the same key is given multiple times, the last value will be used. Entries supplied via keyword arguments are considered to come after entries supplied via the positional argument.
 
 ### Parameters
 
@@ -164,7 +164,7 @@ Causes execution to fail with an error.
 | Parameter | Description |
 | --- | --- |
 | `msg` | default is `None`  Deprecated: use positional arguments instead. This argument acts like an implicit leading positional argument. |
-| `attr` | [string](../core/string); or `None`; default is `None`  Deprecated. Causes an optional prefix containing this string to be added to the error message. |
+| `attr` | [string](/versions/7.7.1/rules/lib/core/string); or `None`; default is `None`  Deprecated. Causes an optional prefix containing this string to be added to the error message. |
 | `sep` | default is `" "`  The separator string between the objects, default is space (" "). |
 | `args` | required  A list of values, formatted with debugPrint (which is equivalent to str by default) and joined with sep (defaults to " "), that appear in the error message. |
 
@@ -393,7 +393,7 @@ range(3, 0, -1) == [3, 2, 1]
 | Parameter | Description |
 | --- | --- |
 | `start_or_stop` | required  Value of the start element if stop is provided, otherwise value of stop and the actual start is 0 |
-| `stop_or_none` | [int](../core/int); or `None`; default is `None`  optional index of the first item *not* to be included in the resulting list; generation of the list stops before `stop` is reached. |
+| `stop_or_none` | [int](/versions/7.7.1/rules/lib/core/int); or `None`; default is `None`  optional index of the first item *not* to be included in the resulting list; generation of the list stops before `stop` is reached. |
 | `step` | default is `1`  The increment (default is 1). It may be negative. |
 
 ## repr
diff --git a/versions/7.7.1/rules/lib/globals/build.mdx b/versions/7.7.1/rules/lib/globals/build.mdx
index 5e4c60ee..22c989be 100644
--- a/versions/7.7.1/rules/lib/globals/build.mdx
+++ b/versions/7.7.1/rules/lib/globals/build.mdx
@@ -27,7 +27,7 @@ Methods available in BUILD files. See also the Build Encyclopedia for extra [fun
 depset depset(direct=None, order="default", *, transitive=None)
 ```
 
-Creates a [depset](../builtins/depset). The `direct` parameter is a list of direct elements of the depset, and `transitive` parameter is a list of depsets whose elements become indirect elements of the created depset. The order in which elements are returned when the depset is converted to a list is specified by the `order` parameter. See the [Depsets overview](https://bazel.build/versions/7.7.1/extending/depsets) for more information.
+Creates a [depset](/versions/7.7.1/rules/lib/builtins/depset). The `direct` parameter is a list of direct elements of the depset, and `transitive` parameter is a list of depsets whose elements become indirect elements of the created depset. The order in which elements are returned when the depset is converted to a list is specified by the `order` parameter. See the [Depsets overview](https://bazel.build/versions/7.7.1/extending/depsets) for more information.
 
 All elements (direct and indirect) of a depset must be of the same type, as obtained by the expression `type(x)`.
 
@@ -41,9 +41,9 @@ The order of the created depset should be *compatible* with the order of its `tr
 
 | Parameter | Description |
 | --- | --- |
-| `direct` | [sequence](../core/list); or `None`; default is `None`  A list of *direct* elements of a depset. |
-| `order` | default is `"default"`  The traversal strategy for the new depset. See [here](../builtins/depset) for the possible values. |
-| `transitive` | [sequence](../core/list) of [depset](../builtins/depset)s; or `None`; default is `None`  A list of depsets whose elements will become indirect elements of the depset. |
+| `direct` | [sequence](/versions/7.7.1/rules/lib/core/list); or `None`; default is `None`  A list of *direct* elements of a depset. |
+| `order` | default is `"default"`  The traversal strategy for the new depset. See [here](/versions/7.7.1/rules/lib/builtins/depset) for the possible values. |
+| `transitive` | [sequence](/versions/7.7.1/rules/lib/core/list) of [depset](/versions/7.7.1/rules/lib/builtins/depset)s; or `None`; default is `None`  A list of depsets whose elements will become indirect elements of the depset. |
 
 ## existing\_rule
 
@@ -101,9 +101,9 @@ Specifies a list of files belonging to this package that are exported to other p
 
 | Parameter | Description |
 | --- | --- |
-| `srcs` | [sequence](../core/list) of [string](../core/string)s; required  The list of files to export. |
-| `visibility` | [sequence](../core/list); or `None`; default is `None`  A visibility declaration can to be specified. The files will be visible to the targets specified. If no visibility is specified, the files will be visible to every package. |
-| `licenses` | [sequence](../core/list) of [string](../core/string)s; or `None`; default is `None`  Licenses to be specified. |
+| `srcs` | [sequence](/versions/7.7.1/rules/lib/core/list) of [string](/versions/7.7.1/rules/lib/core/string)s; required  The list of files to export. |
+| `visibility` | [sequence](/versions/7.7.1/rules/lib/core/list); or `None`; default is `None`  A visibility declaration can to be specified. The files will be visible to the targets specified. If no visibility is specified, the files will be visible to every package. |
+| `licenses` | [sequence](/versions/7.7.1/rules/lib/core/list) of [string](/versions/7.7.1/rules/lib/core/string)s; or `None`; default is `None`  Licenses to be specified. |
 
 ## glob
 
@@ -122,8 +122,8 @@ If the `exclude_directories` argument is enabled (set to `1`), files of type dir
 
 | Parameter | Description |
 | --- | --- |
-| `include` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  The list of glob patterns to include. |
-| `exclude` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  The list of glob patterns to exclude. |
+| `include` | [sequence](/versions/7.7.1/rules/lib/core/list) of [string](/versions/7.7.1/rules/lib/core/string)s; default is `[]`  The list of glob patterns to include. |
+| `exclude` | [sequence](/versions/7.7.1/rules/lib/core/list) of [string](/versions/7.7.1/rules/lib/core/string)s; default is `[]`  The list of glob patterns to exclude. |
 | `exclude_directories` | default is `1`  A flag whether to exclude directories or not. |
 | `allow_empty` | default is `unbound`  Whether we allow glob patterns to match nothing. If `allow\_empty` is False, each individual include pattern must match something and also the final result must be non-empty (after the matches of the `exclude` patterns are excluded). |
 
@@ -158,8 +158,8 @@ This function defines a set of packages and assigns a label to the group. The la
 | Parameter | Description |
 | --- | --- |
 | `name` | required  The unique name for this rule. |
-| `packages` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  A complete enumeration of packages in this group. |
-| `includes` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  Other package groups that are included in this one. |
+| `packages` | [sequence](/versions/7.7.1/rules/lib/core/list) of [string](/versions/7.7.1/rules/lib/core/string)s; default is `[]`  A complete enumeration of packages in this group. |
+| `includes` | [sequence](/versions/7.7.1/rules/lib/core/list) of [string](/versions/7.7.1/rules/lib/core/string)s; default is `[]`  Other package groups that are included in this one. |
 
 ## package\_name
 
@@ -175,19 +175,19 @@ The name of the package being evaluated, without the repository name. For exampl
 Label package_relative_label(input)
 ```
 
-Converts the input string into a [Label](../builtins/Label) object, in the context of the package currently being initialized (that is, the `BUILD` file for which the current macro is executing). If the input is already a `Label`, it is returned unchanged.
+Converts the input string into a [Label](/versions/7.7.1/rules/lib/builtins/Label) object, in the context of the package currently being initialized (that is, the `BUILD` file for which the current macro is executing). If the input is already a `Label`, it is returned unchanged.
 
 This function may only be called while evaluating a BUILD file and the macros it directly or indirectly calls; it may not be called in (for instance) a rule implementation function.
 
 The result of this function is the same `Label` value as would be produced by passing the given string to a label-valued attribute of a target declared in the BUILD file.
 
-*Usage note:* The difference between this function and [Label()](../builtins/Label#Label) is that `Label()` uses the context of the package of the `.bzl` file that called it, not the package of the `BUILD` file. Use `Label()` when you need to refer to a fixed target that is hardcoded into the macro, such as a compiler. Use `package_relative_label()` when you need to normalize a label string supplied by the BUILD file to a `Label` object. (There is no way to convert a string to a `Label` in the context of a package other than the BUILD file or the calling .bzl file. For that reason, outer macros should always prefer to pass Label objects to inner macros rather than label strings.)
+*Usage note:* The difference between this function and [Label()](/versions/7.7.1/rules/lib/builtins/Label#Label) is that `Label()` uses the context of the package of the `.bzl` file that called it, not the package of the `BUILD` file. Use `Label()` when you need to refer to a fixed target that is hardcoded into the macro, such as a compiler. Use `package_relative_label()` when you need to normalize a label string supplied by the BUILD file to a `Label` object. (There is no way to convert a string to a `Label` in the context of a package other than the BUILD file or the calling .bzl file. For that reason, outer macros should always prefer to pass Label objects to inner macros rather than label strings.)
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `input` | [string](../core/string); or [Label](../builtins/Label); required  The input label string or Label object. If a Label object is passed, it's returned as is. |
+| `input` | [string](/versions/7.7.1/rules/lib/core/string); or [Label](/versions/7.7.1/rules/lib/builtins/Label); required  The input label string or Label object. If a Label object is passed, it's returned as is. |
 
 ## repo\_name
 
@@ -235,6 +235,6 @@ Returns a new mutable list of every direct subpackage of the current package, re
 
 | Parameter | Description |
 | --- | --- |
-| `include` | [sequence](../core/list) of [string](../core/string)s; required  The list of glob patterns to include in subpackages scan. |
-| `exclude` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  The list of glob patterns to exclude from subpackages scan. |
+| `include` | [sequence](/versions/7.7.1/rules/lib/core/list) of [string](/versions/7.7.1/rules/lib/core/string)s; required  The list of glob patterns to include in subpackages scan. |
+| `exclude` | [sequence](/versions/7.7.1/rules/lib/core/list) of [string](/versions/7.7.1/rules/lib/core/string)s; default is `[]`  The list of glob patterns to exclude from subpackages scan. |
 | `allow_empty` | default is `False`  Whether we fail if the call returns an empty list. By default empty list indicates potential error in BUILD file where the call to subpackages() is superflous. Setting to true allows this function to succeed in that case. |
\ No newline at end of file
diff --git a/versions/7.7.1/rules/lib/globals/bzl.mdx b/versions/7.7.1/rules/lib/globals/bzl.mdx
index 9dc39fbc..792dfba1 100644
--- a/versions/7.7.1/rules/lib/globals/bzl.mdx
+++ b/versions/7.7.1/rules/lib/globals/bzl.mdx
@@ -26,7 +26,7 @@ Global methods available in all .bzl files.
 transition analysis_test_transition(settings)
 ```
 
-Creates a configuration transition to be applied on an analysis-test rule's dependencies. This transition may only be applied on attributes of rules with `analysis_test = True`. Such rules are restricted in capabilities (for example, the size of their dependency tree is limited), so transitions created using this function are limited in potential scope as compared to transitions created using [`transition()`](../builtins/transition).
+Creates a configuration transition to be applied on an analysis-test rule's dependencies. This transition may only be applied on attributes of rules with `analysis_test = True`. Such rules are restricted in capabilities (for example, the size of their dependency tree is limited), so transitions created using this function are limited in potential scope as compared to transitions created using [`transition()`](/versions/7.7.1/rules/lib/builtins/transition).
 
 This function is primarily designed to facilitate the [Analysis Test Framework](https://bazel.build/versions/7.7.1/rules/testing) core library. See its documentation (or its implementation) for best practices.
 
@@ -48,22 +48,22 @@ Creates a new aspect. The result of this function must be stored in a global val
 
 | Parameter | Description |
 | --- | --- |
-| `implementation` | required  A Starlark function that implements this aspect, with exactly two parameters: [Target](../builtins/Target) (the target to which the aspect is applied) and [ctx](../builtins/ctx) (the rule context which the target is created from). Attributes of the target are available via the `ctx.rule` field. This function is evaluated during the analysis phase for each application of an aspect to a target. |
-| `attr_aspects` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  List of attribute names. The aspect propagates along dependencies specified in the attributes of a target with these names. Common values here include `deps` and `exports`. The list can also contain a single string `"*"` to propagate along all dependencies of a target. |
-| `attrs` | [dict](../core/dict); default is `{}`  A dictionary declaring all the attributes of the aspect. It maps from an attribute name to an attribute object, like `attr.label` or `attr.string` (see [attr](../toplevel/attr) module). Aspect attributes are available to implementation function as fields of `ctx` parameter. Implicit attributes starting with `_` must have default values, and have type `label` or `label_list`. Explicit attributes must have type `string`, and must use the `values` restriction. Explicit attributes restrict the aspect to only be used with rules that have attributes of the same name, type, and valid values according to the restriction. |
+| `implementation` | required  A Starlark function that implements this aspect, with exactly two parameters: [Target](/versions/7.7.1/rules/lib/builtins/Target) (the target to which the aspect is applied) and [ctx](/versions/7.7.1/rules/lib/builtins/ctx) (the rule context which the target is created from). Attributes of the target are available via the `ctx.rule` field. This function is evaluated during the analysis phase for each application of an aspect to a target. |
+| `attr_aspects` | [sequence](/versions/7.7.1/rules/lib/core/list) of [string](/versions/7.7.1/rules/lib/core/string)s; default is `[]`  List of attribute names. The aspect propagates along dependencies specified in the attributes of a target with these names. Common values here include `deps` and `exports`. The list can also contain a single string `"*"` to propagate along all dependencies of a target. |
+| `attrs` | [dict](/versions/7.7.1/rules/lib/core/dict); default is `{}`  A dictionary declaring all the attributes of the aspect. It maps from an attribute name to an attribute object, like `attr.label` or `attr.string` (see [attr](/versions/7.7.1/rules/lib/toplevel/attr) module). Aspect attributes are available to implementation function as fields of `ctx` parameter. Implicit attributes starting with `_` must have default values, and have type `label` or `label_list`. Explicit attributes must have type `string`, and must use the `values` restriction. Explicit attributes restrict the aspect to only be used with rules that have attributes of the same name, type, and valid values according to the restriction. |
 | `required_providers` | default is `[]`  This attribute allows the aspect to limit its propagation to only the targets whose rules advertise its required providers. The value must be a list containing either individual providers or lists of providers but not both. For example, `[[FooInfo], [BarInfo], [BazInfo, QuxInfo]]` is a valid value while `[FooInfo, BarInfo, [BazInfo, QuxInfo]]` is not valid. An unnested list of providers will automatically be converted to a list containing one list of providers. That is, `[FooInfo, BarInfo]` will automatically be converted to `[[FooInfo, BarInfo]]`. To make some rule (e.g. `some_rule`) targets visible to an aspect, `some_rule` must advertise all providers from at least one of the required providers lists. For example, if the `required_providers` of an aspect are `[[FooInfo], [BarInfo], [BazInfo, QuxInfo]]`, this aspect can see `some_rule` targets if and only if `some_rule` provides `FooInfo`, *or* `BarInfo`, *or* both `BazInfo` *and* `QuxInfo`. |
 | `required_aspect_providers` | default is `[]`  This attribute allows this aspect to inspect other aspects. The value must be a list containing either individual providers or lists of providers but not both. For example, `[[FooInfo], [BarInfo], [BazInfo, QuxInfo]]` is a valid value while `[FooInfo, BarInfo, [BazInfo, QuxInfo]]` is not valid. An unnested list of providers will automatically be converted to a list containing one list of providers. That is, `[FooInfo, BarInfo]` will automatically be converted to `[[FooInfo, BarInfo]]`. To make another aspect (e.g. `other_aspect`) visible to this aspect, `other_aspect` must provide all providers from at least one of the lists. In the example of `[[FooInfo], [BarInfo], [BazInfo, QuxInfo]]`, this aspect can see `other_aspect` if and only if `other_aspect` provides `FooInfo`, *or* `BarInfo`, *or* both `BazInfo` *and* `QuxInfo`. |
-| `provides` | default is `[]`  A list of providers that the implementation function must return. It is an error if the implementation function omits any of the types of providers listed here from its return value. However, the implementation function may return additional providers not listed here. Each element of the list is an `*Info` object returned by [`provider()`](../globals/bzl#provider), except that a legacy provider is represented by its string name instead.When a target of the rule is used as a dependency for a target that declares a required provider, it is not necessary to specify that provider here. It is enough that the implementation function returns it. However, it is considered best practice to specify it, even though this is not required. The [`required_providers`](../globals/bzl#aspect.required_providers) field of an [aspect](../globals/bzl#aspect) does, however, require that providers are specified here. |
-| `requires` | [sequence](../core/list) of [Aspect](../builtins/Aspect)s; default is `[]`  List of aspects required to be propagated before this aspect. |
-| `fragments` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  List of names of configuration fragments that the aspect requires in target configuration. |
-| `host_fragments` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  List of names of configuration fragments that the aspect requires in host configuration. |
-| `toolchains` | [sequence](../core/list); default is `[]`  If set, the set of toolchains this rule requires. The list can contain String, Label, or StarlarkToolchainTypeApi objects, in any combination. Toolchains will be found by checking the current platform, and provided to the rule implementation via `ctx.toolchain`. |
+| `provides` | default is `[]`  A list of providers that the implementation function must return. It is an error if the implementation function omits any of the types of providers listed here from its return value. However, the implementation function may return additional providers not listed here. Each element of the list is an `*Info` object returned by [`provider()`](/versions/7.7.1/rules/lib/globals/bzl#provider), except that a legacy provider is represented by its string name instead.When a target of the rule is used as a dependency for a target that declares a required provider, it is not necessary to specify that provider here. It is enough that the implementation function returns it. However, it is considered best practice to specify it, even though this is not required. The [`required_providers`](/versions/7.7.1/rules/lib/globals/bzl#aspect.required_providers) field of an [aspect](/versions/7.7.1/rules/lib/globals/bzl#aspect) does, however, require that providers are specified here. |
+| `requires` | [sequence](/versions/7.7.1/rules/lib/core/list) of [Aspect](/versions/7.7.1/rules/lib/builtins/Aspect)s; default is `[]`  List of aspects required to be propagated before this aspect. |
+| `fragments` | [sequence](/versions/7.7.1/rules/lib/core/list) of [string](/versions/7.7.1/rules/lib/core/string)s; default is `[]`  List of names of configuration fragments that the aspect requires in target configuration. |
+| `host_fragments` | [sequence](/versions/7.7.1/rules/lib/core/list) of [string](/versions/7.7.1/rules/lib/core/string)s; default is `[]`  List of names of configuration fragments that the aspect requires in host configuration. |
+| `toolchains` | [sequence](/versions/7.7.1/rules/lib/core/list); default is `[]`  If set, the set of toolchains this rule requires. The list can contain String, Label, or StarlarkToolchainTypeApi objects, in any combination. Toolchains will be found by checking the current platform, and provided to the rule implementation via `ctx.toolchain`. |
 | `incompatible_use_toolchain_transition` | default is `False`  Deprecated, this is no longer in use and should be removed. |
-| `doc` | [string](../core/string); or `None`; default is `None`  A description of the aspect that can be extracted by documentation generating tools. |
+| `doc` | [string](/versions/7.7.1/rules/lib/core/string); or `None`; default is `None`  A description of the aspect that can be extracted by documentation generating tools. |
 | `apply_to_generating_rules` | default is `False`  If true, the aspect will, when applied to an output file, instead apply to the output file's generating rule. For example, suppose an aspect propagates transitively through attribute `deps` and it is applied to target `alpha`. Suppose `alpha` has `deps = [':beta\_output']`, where `beta\_output` is a declared output of a target `beta`. Suppose `beta` has a target `charlie` as one of its `deps`. If `apply\_to\_generating\_rules=True` for the aspect, then the aspect will propagate through `alpha`, `beta`, and `charlie`. If False, then the aspect will propagate only to `alpha`.  False by default. |
-| `exec_compatible_with` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  A list of constraints on the execution platform that apply to all instances of this aspect. |
-| `exec_groups` | [dict](../core/dict); or `None`; default is `None`  Dict of execution group name (string) to [`exec_group`s](../globals/bzl#exec_group). If set, allows aspects to run actions on multiple execution platforms within a single instance. See [execution groups documentation](/versions/7.7.1/reference/exec-groups) for more info. |
-| `subrules` | [sequence](../core/list) of [Subrule](../builtins/Subrule)s; default is `[]`  Experimental: list of subrules used by this aspect. |
+| `exec_compatible_with` | [sequence](/versions/7.7.1/rules/lib/core/list) of [string](/versions/7.7.1/rules/lib/core/string)s; default is `[]`  A list of constraints on the execution platform that apply to all instances of this aspect. |
+| `exec_groups` | [dict](/versions/7.7.1/rules/lib/core/dict); or `None`; default is `None`  Dict of execution group name (string) to [`exec_group`s](/versions/7.7.1/rules/lib/globals/bzl#exec_group). If set, allows aspects to run actions on multiple execution platforms within a single instance. See [execution groups documentation](/versions/7.7.1/reference/exec-groups) for more info. |
+| `subrules` | [sequence](/versions/7.7.1/rules/lib/core/list) of [Subrule](/versions/7.7.1/rules/lib/builtins/Subrule)s; default is `[]`  Experimental: list of subrules used by this aspect. |
 
 ## configuration\_field
 
@@ -71,7 +71,7 @@ Creates a new aspect. The result of this function must be stored in a global val
 LateBoundDefault configuration_field(fragment, name)
 ```
 
-References a late-bound default value for an attribute of type [label](../toplevel/attr#label). A value is 'late-bound' if it requires the configuration to be built before determining the value. Any attribute using this as a value must [be private](https://bazel.build/versions/7.7.1/extending/rules#private-attributes).
+References a late-bound default value for an attribute of type [label](/versions/7.7.1/rules/lib/toplevel/attr#label). A value is 'late-bound' if it requires the configuration to be built before determining the value. Any attribute using this as a value must [be private](https://bazel.build/versions/7.7.1/extending/rules#private-attributes).
 
 Example usage:
 
@@ -102,7 +102,7 @@ Accessing in rule implementation:
 depset depset(direct=None, order="default", *, transitive=None)
 ```
 
-Creates a [depset](../builtins/depset). The `direct` parameter is a list of direct elements of the depset, and `transitive` parameter is a list of depsets whose elements become indirect elements of the created depset. The order in which elements are returned when the depset is converted to a list is specified by the `order` parameter. See the [Depsets overview](https://bazel.build/versions/7.7.1/extending/depsets) for more information.
+Creates a [depset](/versions/7.7.1/rules/lib/builtins/depset). The `direct` parameter is a list of direct elements of the depset, and `transitive` parameter is a list of depsets whose elements become indirect elements of the created depset. The order in which elements are returned when the depset is converted to a list is specified by the `order` parameter. See the [Depsets overview](https://bazel.build/versions/7.7.1/extending/depsets) for more information.
 
 All elements (direct and indirect) of a depset must be of the same type, as obtained by the expression `type(x)`.
 
@@ -116,9 +116,9 @@ The order of the created depset should be *compatible* with the order of its `tr
 
 | Parameter | Description |
 | --- | --- |
-| `direct` | [sequence](../core/list); or `None`; default is `None`  A list of *direct* elements of a depset. |
-| `order` | default is `"default"`  The traversal strategy for the new depset. See [here](../builtins/depset) for the possible values. |
-| `transitive` | [sequence](../core/list) of [depset](../builtins/depset)s; or `None`; default is `None`  A list of depsets whose elements will become indirect elements of the depset. |
+| `direct` | [sequence](/versions/7.7.1/rules/lib/core/list); or `None`; default is `None`  A list of *direct* elements of a depset. |
+| `order` | default is `"default"`  The traversal strategy for the new depset. See [here](/versions/7.7.1/rules/lib/builtins/depset) for the possible values. |
+| `transitive` | [sequence](/versions/7.7.1/rules/lib/core/list) of [depset](/versions/7.7.1/rules/lib/builtins/depset)s; or `None`; default is `None`  A list of depsets whose elements will become indirect elements of the depset. |
 
 ## exec\_group
 
@@ -132,8 +132,8 @@ Creates an [execution group](/versions/7.7.1/reference/exec-groups) which can be
 
 | Parameter | Description |
 | --- | --- |
-| `toolchains` | [sequence](../core/list); default is `[]`  The set of toolchains this execution group requires. The list can contain String, Label, or StarlarkToolchainTypeApi objects, in any combination. |
-| `exec_compatible_with` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  A list of constraints on the execution platform. |
+| `toolchains` | [sequence](/versions/7.7.1/rules/lib/core/list); default is `[]`  The set of toolchains this execution group requires. The list can contain String, Label, or StarlarkToolchainTypeApi objects, in any combination. |
+| `exec_compatible_with` | [sequence](/versions/7.7.1/rules/lib/core/list) of [string](/versions/7.7.1/rules/lib/core/string)s; default is `[]`  A list of constraints on the execution platform. |
 
 ## module\_extension
 
@@ -149,8 +149,8 @@ Creates a new module extension. Store it in a global value, so that it can be ex
 | --- | --- |
 | `implementation` | required  The function that implements this module extension. Must take a single parameter, `module_ctx`. The function is called once at the beginning of a build to determine the set of available repos. |
 | `tag_classes` | default is `{}`  A dictionary to declare all the tag classes used by the extension. It maps from the name of the tag class to a `tag_class` object. |
-| `doc` | [string](../core/string); or `None`; default is `None`  A description of the module extension that can be extracted by documentation generating tools. |
-| `environ` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  Provides a list of environment variable that this module extension depends on. If an environment variable in that list changes, the extension will be re-evaluated. |
+| `doc` | [string](/versions/7.7.1/rules/lib/core/string); or `None`; default is `None`  A description of the module extension that can be extracted by documentation generating tools. |
+| `environ` | [sequence](/versions/7.7.1/rules/lib/core/list) of [string](/versions/7.7.1/rules/lib/core/string)s; default is `[]`  Provides a list of environment variable that this module extension depends on. If an environment variable in that list changes, the extension will be re-evaluated. |
 | `os_dependent` | default is `False`  Indicates whether this extension is OS-dependent or not |
 | `arch_dependent` | default is `False`  Indicates whether this extension is architecture-dependent or not |
 
@@ -175,16 +175,16 @@ def _my_library_impl(ctx):
 
 See [Rules (Providers)](https://bazel.build/versions/7.7.1/extending/rules#providers) for a comprehensive guide on how to use providers.
 
-Returns a [`Provider`](../builtins/Provider) callable value if `init` is not specified.
+Returns a [`Provider`](/versions/7.7.1/rules/lib/builtins/Provider) callable value if `init` is not specified.
 
-If `init` is specified, returns a tuple of 2 elements: a [`Provider`](../builtins/Provider) callable value and a *raw constructor* callable value. See  [Rules (Custom initialization of custom providers)](https://bazel.build/versions/7.7.1/extending/rules#custom_initialization_of_providers) and the discussion of the `init` parameter below for details.
+If `init` is specified, returns a tuple of 2 elements: a [`Provider`](/versions/7.7.1/rules/lib/builtins/Provider) callable value and a *raw constructor* callable value. See  [Rules (Custom initialization of custom providers)](https://bazel.build/versions/7.7.1/extending/rules#custom_initialization_of_providers) and the discussion of the `init` parameter below for details.
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `doc` | [string](../core/string); or `None`; default is `None` |
-| `fields` | [sequence](../core/list) of [string](../core/string)s; or [dict](../core/dict); or `None`; default is `None`  If specified, restricts the set of allowed fields.  Possible values are:  * list of fields:     ```   provider(fields = ['a', 'b'])   ```     * dictionary field name -> documentation:       ```     provider(            fields = { 'a' : 'Documentation for a', 'b' : 'Documentation for b' })     ```  All fields are optional. |
+| `doc` | [string](/versions/7.7.1/rules/lib/core/string); or `None`; default is `None` |
+| `fields` | [sequence](/versions/7.7.1/rules/lib/core/list) of [string](/versions/7.7.1/rules/lib/core/string)s; or [dict](/versions/7.7.1/rules/lib/core/dict); or `None`; default is `None`  If specified, restricts the set of allowed fields.  Possible values are:  * list of fields:     ```   provider(fields = ['a', 'b'])   ```     * dictionary field name -> documentation:       ```     provider(            fields = { 'a' : 'Documentation for a', 'b' : 'Documentation for b' })     ```  All fields are optional. |
 | `init` | callable; or `None`; default is `None` |
 
 ## repository\_rule
@@ -200,12 +200,12 @@ Creates a new repository rule. Store it in a global value, so that it can be loa
 | Parameter | Description |
 | --- | --- |
 | `implementation` | required |
-| `attrs` | [dict](../core/dict); or `None`; default is `None` |
+| `attrs` | [dict](/versions/7.7.1/rules/lib/core/dict); or `None`; default is `None` |
 | `local` | default is `False`  Indicate that this rule fetches everything from the local system and should be reevaluated at every fetch. |
-| `environ` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  **Deprecated**. This parameter has been deprecated. Migrate to `repository_ctx.getenv` instead. Provides a list of environment variable that this repository rule depends on. If an environment variable in that list change, the repository will be refetched. |
+| `environ` | [sequence](/versions/7.7.1/rules/lib/core/list) of [string](/versions/7.7.1/rules/lib/core/string)s; default is `[]`  **Deprecated**. This parameter has been deprecated. Migrate to `repository_ctx.getenv` instead. Provides a list of environment variable that this repository rule depends on. If an environment variable in that list change, the repository will be refetched. |
 | `configure` | default is `False`  Indicate that the repository inspects the system for configuration purpose |
 | `remotable` | default is `False`  **Experimental**. This parameter is experimental and may change at any time. Please do not depend on it. It may be enabled on an experimental basis by setting `---experimental_repo_remote_exec`  Compatible with remote execution |
-| `doc` | [string](../core/string); or `None`; default is `None` |
+| `doc` | [string](/versions/7.7.1/rules/lib/core/string); or `None`; default is `None` |
 
 ## rule
 
@@ -223,28 +223,28 @@ Test rules are required to have a name ending in `_test`, while all other rules
 
 | Parameter | Description |
 | --- | --- |
-| `implementation` | required  the Starlark function implementing this rule, must have exactly one parameter: [ctx](../builtins/ctx). The function is called during the analysis phase for each instance of the rule. It can access the attributes provided by the user. It must create actions to generate all the declared outputs. |
-| `test` | [bool](../core/bool); default is `unbound`  Whether this rule is a test rule, that is, whether it may be the subject of a `blaze test` command. All test rules are automatically considered [executable](#rule.executable); it is unnecessary (and discouraged) to explicitly set `executable = True` for a test rule. The value defaults to `False`. See the  [Rules page](https://bazel.build/versions/7.7.1/extending/rules#executable_rules_and_test_rules) for more information. |
-| `attrs` | [dict](../core/dict); default is `{}`  dictionary to declare all the attributes of the rule. It maps from an attribute name to an attribute object (see [attr](../toplevel/attr) module). Attributes starting with `_` are private, and can be used to add an implicit dependency on a label. The attribute `name` is implicitly added and must not be specified. Attributes `visibility`, `deprecation`, `tags`, `testonly`, and `features` are implicitly added and cannot be overridden. Most rules need only a handful of attributes. To limit memory usage, the rule function imposes a cap on the size of attrs. |
-| `outputs` | [dict](../core/dict); or `None`; or [function](../core/function); default is `None`  **Deprecated**. This parameter is deprecated and will be removed soon. Please do not depend on it. It is *disabled* with `---incompatible_no_rule_outputs_param`. Use this flag to verify your code is compatible with its imminent removal.  This parameter has been deprecated. Migrate rules to use `OutputGroupInfo` or `attr.output` instead. A schema for defining predeclared outputs. Unlike [`output`](../toplevel/attr#output) and [`output_list`](../toplevel/attr#output_list) attributes, the user does not specify the labels for these files. See the [Rules page](https://bazel.build/versions/7.7.1/extending/rules#files) for more on predeclared outputs. The value of this argument is either a dictionary or a callback function that produces a dictionary. The callback works similar to computed dependency attributes: The function's parameter names are matched against the rule's attributes, so for example if you pass `outputs = _my_func` with the definition `def _my_func(srcs, deps): ...`, the function has access to the attributes `srcs` and `deps`. Whether the dictionary is specified directly or via a function, it is interpreted as follows. Each entry in the dictionary creates a predeclared output where the key is an identifier and the value is a string template that determines the output's label. In the rule's implementation function, the identifier becomes the field name used to access the output's [`File`](../builtins/File) in [`ctx.outputs`](../builtins/ctx#outputs). The output's label has the same package as the rule, and the part after the package is produced by substituting each placeholder of the form `"%{ATTR}"` with a string formed from the value of the attribute `ATTR`:  * String-typed attributes are substituted verbatim.* Label-typed attributes become the part of the label after the package, minus the file extension. For example, the label `"//pkg:a/b.c"` becomes `"a/b"`.* Output-typed attributes become the part of the label after the package, including the file extension (for the above example, `"a/b.c"`).* All list-typed attributes (for example, `attr.label_list`) used in placeholders are required to have *exactly one element*. Their conversion is the same as their non-list version (`attr.label`).* Other attribute types may not appear in placeholders.* The special non-attribute placeholders `%{dirname}` and `%{basename}` expand to those parts of the rule's label, excluding its package. For example, in `"//pkg:a/b.c"`, the dirname is `a` and the basename is `b.c`.   In practice, the most common substitution placeholder is `"%{name}"`. For example, for a target named "foo", the outputs dict `{"bin": "%{name}.exe"}` predeclares an output named `foo.exe` that is accessible in the implementation function as `ctx.outputs.bin`. |
-| `executable` | [bool](../core/bool); default is `unbound` |
+| `implementation` | required  the Starlark function implementing this rule, must have exactly one parameter: [ctx](/versions/7.7.1/rules/lib/builtins/ctx). The function is called during the analysis phase for each instance of the rule. It can access the attributes provided by the user. It must create actions to generate all the declared outputs. |
+| `test` | [bool](/versions/7.7.1/rules/lib/core/bool); default is `unbound`  Whether this rule is a test rule, that is, whether it may be the subject of a `blaze test` command. All test rules are automatically considered [executable](#rule.executable); it is unnecessary (and discouraged) to explicitly set `executable = True` for a test rule. The value defaults to `False`. See the  [Rules page](https://bazel.build/versions/7.7.1/extending/rules#executable_rules_and_test_rules) for more information. |
+| `attrs` | [dict](/versions/7.7.1/rules/lib/core/dict); default is `{}`  dictionary to declare all the attributes of the rule. It maps from an attribute name to an attribute object (see [attr](/versions/7.7.1/rules/lib/toplevel/attr) module). Attributes starting with `_` are private, and can be used to add an implicit dependency on a label. The attribute `name` is implicitly added and must not be specified. Attributes `visibility`, `deprecation`, `tags`, `testonly`, and `features` are implicitly added and cannot be overridden. Most rules need only a handful of attributes. To limit memory usage, the rule function imposes a cap on the size of attrs. |
+| `outputs` | [dict](/versions/7.7.1/rules/lib/core/dict); or `None`; or [function](/versions/7.7.1/rules/lib/core/function); default is `None`  **Deprecated**. This parameter is deprecated and will be removed soon. Please do not depend on it. It is *disabled* with `---incompatible_no_rule_outputs_param`. Use this flag to verify your code is compatible with its imminent removal.  This parameter has been deprecated. Migrate rules to use `OutputGroupInfo` or `attr.output` instead. A schema for defining predeclared outputs. Unlike [`output`](/versions/7.7.1/rules/lib/toplevel/attr#output) and [`output_list`](/versions/7.7.1/rules/lib/toplevel/attr#output_list) attributes, the user does not specify the labels for these files. See the [Rules page](https://bazel.build/versions/7.7.1/extending/rules#files) for more on predeclared outputs. The value of this argument is either a dictionary or a callback function that produces a dictionary. The callback works similar to computed dependency attributes: The function's parameter names are matched against the rule's attributes, so for example if you pass `outputs = _my_func` with the definition `def _my_func(srcs, deps): ...`, the function has access to the attributes `srcs` and `deps`. Whether the dictionary is specified directly or via a function, it is interpreted as follows. Each entry in the dictionary creates a predeclared output where the key is an identifier and the value is a string template that determines the output's label. In the rule's implementation function, the identifier becomes the field name used to access the output's [`File`](/versions/7.7.1/rules/lib/builtins/File) in [`ctx.outputs`](/versions/7.7.1/rules/lib/builtins/ctx#outputs). The output's label has the same package as the rule, and the part after the package is produced by substituting each placeholder of the form `"%{ATTR}"` with a string formed from the value of the attribute `ATTR`:  * String-typed attributes are substituted verbatim.* Label-typed attributes become the part of the label after the package, minus the file extension. For example, the label `"//pkg:a/b.c"` becomes `"a/b"`.* Output-typed attributes become the part of the label after the package, including the file extension (for the above example, `"a/b.c"`).* All list-typed attributes (for example, `attr.label_list`) used in placeholders are required to have *exactly one element*. Their conversion is the same as their non-list version (`attr.label`).* Other attribute types may not appear in placeholders.* The special non-attribute placeholders `%{dirname}` and `%{basename}` expand to those parts of the rule's label, excluding its package. For example, in `"//pkg:a/b.c"`, the dirname is `a` and the basename is `b.c`.   In practice, the most common substitution placeholder is `"%{name}"`. For example, for a target named "foo", the outputs dict `{"bin": "%{name}.exe"}` predeclares an output named `foo.exe` that is accessible in the implementation function as `ctx.outputs.bin`. |
+| `executable` | [bool](/versions/7.7.1/rules/lib/core/bool); default is `unbound` |
 | `output_to_genfiles` | default is `False`  If true, the files will be generated in the genfiles directory instead of the bin directory. Unless you need it for compatibility with existing rules (e.g. when generating header files for C++), do not set this flag. |
-| `fragments` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  List of names of configuration fragments that the rule requires in target configuration. |
-| `host_fragments` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  List of names of configuration fragments that the rule requires in host configuration. |
-| `_skylark_testable` | default is `False`  *(Experimental)*  If true, this rule will expose its actions for inspection by rules that depend on it via an `Actions` provider. The provider is also available to the rule itself by calling [ctx.created\_actions()](../builtins/ctx#created_actions).  This should only be used for testing the analysis-time behavior of Starlark rules. This flag may be removed in the future. |
-| `toolchains` | [sequence](../core/list); default is `[]`  If set, the set of toolchains this rule requires. The list can contain String, Label, or StarlarkToolchainTypeApi objects, in any combination. Toolchains will be found by checking the current platform, and provided to the rule implementation via `ctx.toolchain`. |
+| `fragments` | [sequence](/versions/7.7.1/rules/lib/core/list) of [string](/versions/7.7.1/rules/lib/core/string)s; default is `[]`  List of names of configuration fragments that the rule requires in target configuration. |
+| `host_fragments` | [sequence](/versions/7.7.1/rules/lib/core/list) of [string](/versions/7.7.1/rules/lib/core/string)s; default is `[]`  List of names of configuration fragments that the rule requires in host configuration. |
+| `_skylark_testable` | default is `False`  *(Experimental)*  If true, this rule will expose its actions for inspection by rules that depend on it via an `Actions` provider. The provider is also available to the rule itself by calling [ctx.created\_actions()](/versions/7.7.1/rules/lib/builtins/ctx#created_actions).  This should only be used for testing the analysis-time behavior of Starlark rules. This flag may be removed in the future. |
+| `toolchains` | [sequence](/versions/7.7.1/rules/lib/core/list); default is `[]`  If set, the set of toolchains this rule requires. The list can contain String, Label, or StarlarkToolchainTypeApi objects, in any combination. Toolchains will be found by checking the current platform, and provided to the rule implementation via `ctx.toolchain`. |
 | `incompatible_use_toolchain_transition` | default is `False`  Deprecated, this is no longer in use and should be removed. |
-| `doc` | [string](../core/string); or `None`; default is `None`  A description of the rule that can be extracted by documentation generating tools. |
-| `provides` | default is `[]`  A list of providers that the implementation function must return. It is an error if the implementation function omits any of the types of providers listed here from its return value. However, the implementation function may return additional providers not listed here. Each element of the list is an `*Info` object returned by [`provider()`](../globals/bzl#provider), except that a legacy provider is represented by its string name instead.When a target of the rule is used as a dependency for a target that declares a required provider, it is not necessary to specify that provider here. It is enough that the implementation function returns it. However, it is considered best practice to specify it, even though this is not required. The [`required_providers`](../globals/bzl#aspect.required_providers) field of an [aspect](../globals/bzl#aspect) does, however, require that providers are specified here. |
-| `exec_compatible_with` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  A list of constraints on the execution platform that apply to all targets of this rule type. |
-| `analysis_test` | default is `False`  If true, then this rule is treated as an analysis test. Note: Analysis test rules are primarily defined using infrastructure provided in core Starlark libraries. See [Testing](https://bazel.build/versions/7.7.1/rules/testing#testing-rules) for guidance. If a rule is defined as an analysis test rule, it becomes allowed to use configuration transitions defined using [analysis\_test\_transition](#analysis_test_transition) on its attributes, but opts into some restrictions:  * Targets of this rule are limited in the number of transitive dependencies they may have.* The rule is considered a test rule (as if `test=True` were set). This supersedes the value of `test`   * The rule implementation function may not register actions. Instead, it must register a pass/fail result via providing [AnalysisTestResultInfo](../providers/AnalysisTestResultInfo). |
-| `build_setting` | [BuildSetting](../builtins/BuildSetting); or `None`; default is `None`  If set, describes what kind of [`build setting`](/versions/7.7.1/rules/config#user-defined-build-settings) this rule is. See the [`config`](../toplevel/config) module. If this is set, a mandatory attribute named "build\_setting\_default" is automatically added to this rule, with a type corresponding to the value passed in here. |
+| `doc` | [string](/versions/7.7.1/rules/lib/core/string); or `None`; default is `None`  A description of the rule that can be extracted by documentation generating tools. |
+| `provides` | default is `[]`  A list of providers that the implementation function must return. It is an error if the implementation function omits any of the types of providers listed here from its return value. However, the implementation function may return additional providers not listed here. Each element of the list is an `*Info` object returned by [`provider()`](/versions/7.7.1/rules/lib/globals/bzl#provider), except that a legacy provider is represented by its string name instead.When a target of the rule is used as a dependency for a target that declares a required provider, it is not necessary to specify that provider here. It is enough that the implementation function returns it. However, it is considered best practice to specify it, even though this is not required. The [`required_providers`](/versions/7.7.1/rules/lib/globals/bzl#aspect.required_providers) field of an [aspect](/versions/7.7.1/rules/lib/globals/bzl#aspect) does, however, require that providers are specified here. |
+| `exec_compatible_with` | [sequence](/versions/7.7.1/rules/lib/core/list) of [string](/versions/7.7.1/rules/lib/core/string)s; default is `[]`  A list of constraints on the execution platform that apply to all targets of this rule type. |
+| `analysis_test` | default is `False`  If true, then this rule is treated as an analysis test. Note: Analysis test rules are primarily defined using infrastructure provided in core Starlark libraries. See [Testing](https://bazel.build/versions/7.7.1/rules/testing#testing-rules) for guidance. If a rule is defined as an analysis test rule, it becomes allowed to use configuration transitions defined using [analysis\_test\_transition](#analysis_test_transition) on its attributes, but opts into some restrictions:  * Targets of this rule are limited in the number of transitive dependencies they may have.* The rule is considered a test rule (as if `test=True` were set). This supersedes the value of `test`   * The rule implementation function may not register actions. Instead, it must register a pass/fail result via providing [AnalysisTestResultInfo](/versions/7.7.1/rules/lib/providers/AnalysisTestResultInfo). |
+| `build_setting` | [BuildSetting](/versions/7.7.1/rules/lib/builtins/BuildSetting); or `None`; default is `None`  If set, describes what kind of [`build setting`](/versions/7.7.1/rules/config#user-defined-build-settings) this rule is. See the [`config`](/versions/7.7.1/rules/lib/toplevel/config) module. If this is set, a mandatory attribute named "build\_setting\_default" is automatically added to this rule, with a type corresponding to the value passed in here. |
 | `cfg` | default is `None`  If set, points to the configuration transition the rule will apply to its own configuration before analysis. |
-| `exec_groups` | [dict](../core/dict); or `None`; default is `None`  Dict of execution group name (string) to [`exec_group`s](../globals/bzl#exec_group). If set, allows rules to run actions on multiple execution platforms within a single target. See [execution groups documentation](/versions/7.7.1/reference/exec-groups) for more info. |
+| `exec_groups` | [dict](/versions/7.7.1/rules/lib/core/dict); or `None`; default is `None`  Dict of execution group name (string) to [`exec_group`s](/versions/7.7.1/rules/lib/globals/bzl#exec_group). If set, allows rules to run actions on multiple execution platforms within a single target. See [execution groups documentation](/versions/7.7.1/reference/exec-groups) for more info. |
 | `initializer` | default is `None`  Experimental: the Stalark function initializing the attributes of the rule. The function is called at load time for each instance of the rule. It's called with `name` and the values of public attributes defined bythe rule (not with generic attributes, for example `tags`). It has to return a dictionary from the attribute names to the desired values. The attributes that are not returned are unaffected. Returning `None` as value results in using the default value specified in the attribute definition. Initializers are evaluated before the default values specified in an attribute definition. Consequently, if a parameter in the initializer's signature contains a default values, it overwrites the default from the attribute definition (except if returning `None`). Similarly, if a parameter in the initializer's signature doesn't have a default, the parameter will become mandatory. It's a good practice to omit default/mandatory settings on an attribute definition in such cases. It's a good practice to use `**kwargs` for attributes that are not handled. In case of extended rules, all initializers are called proceeding from child to ancestors. Each initializer is passed only the public attributes it knows about. |
 | `parent` | default is `None`  Experimental: the Stalark rule that is extended. When set the public attributes are merged as well as advertised providers. The rule matches `executable` and `test` from the parent. Values of `fragments`, `toolchains`, `exec_compatible_with`, and `exec_groups` are merged. Legacy or deprecated parameters may not be set. Incoming configuration transition `cfg` of parent is applied after thisrule's incoming configuration. |
-| `extendable` | [bool](../core/bool); or [Label](../builtins/Label); or [string](../core/string); or `None`; default is `None`  Experimental: A label of an allowlist defining which rules can extending this rule. It can be set also to True/False to always allow/disallow extending. Bazel defaults to always allowing extensions. |
-| `subrules` | [sequence](../core/list) of [Subrule](../builtins/Subrule)s; default is `[]`  Experimental: List of subrules used by this rule. |
+| `extendable` | [bool](/versions/7.7.1/rules/lib/core/bool); or [Label](/versions/7.7.1/rules/lib/builtins/Label); or [string](/versions/7.7.1/rules/lib/core/string); or `None`; default is `None`  Experimental: A label of an allowlist defining which rules can extending this rule. It can be set also to True/False to always allow/disallow extending. Bazel defaults to always allowing extensions. |
+| `subrules` | [sequence](/versions/7.7.1/rules/lib/core/list) of [Subrule](/versions/7.7.1/rules/lib/builtins/Subrule)s; default is `[]`  Experimental: List of subrules used by this rule. |
 
 ## select
 
@@ -258,7 +258,7 @@ unknown select(x, no_match_error='')
 
 | Parameter | Description |
 | --- | --- |
-| `x` | required  A dict that maps configuration conditions to values. Each key is a [Label](../builtins/Label) or a label string that identifies a config\_setting or constraint\_value instance. See the [documentation on macros](https://bazel.build/versions/7.7.1/rules/macros#label-resolution) for when to use a Label instead of a string. |
+| `x` | required  A dict that maps configuration conditions to values. Each key is a [Label](/versions/7.7.1/rules/lib/builtins/Label) or a label string that identifies a config\_setting or constraint\_value instance. See the [documentation on macros](https://bazel.build/versions/7.7.1/rules/macros#label-resolution) for when to use a Label instead of a string. |
 | `no_match_error` | default is `''`  Optional custom error to report if no condition matches. |
 
 ## subrule
@@ -273,11 +273,11 @@ Constructs a new instance of a subrule. The result of this function must be stor
 
 | Parameter | Description |
 | --- | --- |
-| `implementation` | [function](../core/function); required  The Starlark function implementing this subrule |
-| `attrs` | [dict](../core/dict); default is `{}`  A dictionary to declare all the (private) attributes of the subrule.  Subrules may only have private attributes that are label-typed (i.e. label or label-list). The resolved values corresponding to these labels are automatically passed by Bazel to the subrule's implementation function as named arguments (thus the implementation function is required to accept named parameters matching the attribute names). The types of these values will be:  * `FilesToRunProvider` for label attributes with `executable=True` * `File` for label attributes with `allow_single_file=True` * `Target` for all other label attributes * `[Target]` for all label-list attributes |
-| `toolchains` | [sequence](../core/list); default is `[]`  If set, the set of toolchains this subrule requires. The list can contain String, Label, or StarlarkToolchainTypeApi objects, in any combination. Toolchains will be found by checking the current platform, and provided to the subrule implementation via `ctx.toolchains`. |
-| `fragments` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  List of names of configuration fragments that the subrule requires in target configuration. |
-| `subrules` | [sequence](../core/list) of [Subrule](../builtins/Subrule)s; default is `[]`  List of other subrules needed by this subrule. |
+| `implementation` | [function](/versions/7.7.1/rules/lib/core/function); required  The Starlark function implementing this subrule |
+| `attrs` | [dict](/versions/7.7.1/rules/lib/core/dict); default is `{}`  A dictionary to declare all the (private) attributes of the subrule.  Subrules may only have private attributes that are label-typed (i.e. label or label-list). The resolved values corresponding to these labels are automatically passed by Bazel to the subrule's implementation function as named arguments (thus the implementation function is required to accept named parameters matching the attribute names). The types of these values will be:  * `FilesToRunProvider` for label attributes with `executable=True` * `File` for label attributes with `allow_single_file=True` * `Target` for all other label attributes * `[Target]` for all label-list attributes |
+| `toolchains` | [sequence](/versions/7.7.1/rules/lib/core/list); default is `[]`  If set, the set of toolchains this subrule requires. The list can contain String, Label, or StarlarkToolchainTypeApi objects, in any combination. Toolchains will be found by checking the current platform, and provided to the subrule implementation via `ctx.toolchains`. |
+| `fragments` | [sequence](/versions/7.7.1/rules/lib/core/list) of [string](/versions/7.7.1/rules/lib/core/string)s; default is `[]`  List of names of configuration fragments that the subrule requires in target configuration. |
+| `subrules` | [sequence](/versions/7.7.1/rules/lib/core/list) of [Subrule](/versions/7.7.1/rules/lib/builtins/Subrule)s; default is `[]`  List of other subrules needed by this subrule. |
 
 ## tag\_class
 
@@ -291,8 +291,8 @@ Creates a new tag\_class object, which defines an attribute schema for a class o
 
 | Parameter | Description |
 | --- | --- |
-| `attrs` | default is `{}`  A dictionary to declare all the attributes of this tag class. It maps from an attribute name to an attribute object (see [attr](../toplevel/attr) module). |
-| `doc` | [string](../core/string); or `None`; default is `None`  A description of the tag class that can be extracted by documentation generating tools. |
+| `attrs` | default is `{}`  A dictionary to declare all the attributes of this tag class. It maps from an attribute name to an attribute object (see [attr](/versions/7.7.1/rules/lib/toplevel/attr) module). |
+| `doc` | [string](/versions/7.7.1/rules/lib/core/string); or `None`; default is `None`  A description of the tag class that can be extracted by documentation generating tools. |
 
 ## visibility
 
diff --git a/versions/7.7.1/rules/lib/globals/module.mdx b/versions/7.7.1/rules/lib/globals/module.mdx
index 6011e3f6..263fb237 100644
--- a/versions/7.7.1/rules/lib/globals/module.mdx
+++ b/versions/7.7.1/rules/lib/globals/module.mdx
@@ -36,11 +36,11 @@ Specifies that this dependency should come from an archive file (zip, gzip, etc)
 | Parameter | Description |
 | --- | --- |
 | `module_name` | required  The name of the Bazel module dependency to apply this override to. |
-| `urls` | [string](../core/string); or Iterable of [string](../core/string)s; required  The URLs of the archive; can be http(s):// or file:// URLs. |
+| `urls` | [string](/versions/7.7.1/rules/lib/core/string); or Iterable of [string](/versions/7.7.1/rules/lib/core/string)s; required  The URLs of the archive; can be http(s):// or file:// URLs. |
 | `integrity` | default is `''`  The expected checksum of the archive file, in Subresource Integrity format. |
 | `strip_prefix` | default is `''`  A directory prefix to strip from the extracted files. |
-| `patches` | Iterable of [string](../core/string)s; default is `[]`  A list of labels pointing to patch files to apply for this module. The patch files must exist in the source tree of the top level project. They are applied in the list order. |
-| `patch_cmds` | Iterable of [string](../core/string)s; default is `[]`  Sequence of Bash commands to be applied on Linux/Macos after patches are applied. |
+| `patches` | Iterable of [string](/versions/7.7.1/rules/lib/core/string)s; default is `[]`  A list of labels pointing to patch files to apply for this module. The patch files must exist in the source tree of the top level project. They are applied in the list order. |
+| `patch_cmds` | Iterable of [string](/versions/7.7.1/rules/lib/core/string)s; default is `[]`  Sequence of Bash commands to be applied on Linux/Macos after patches are applied. |
 | `patch_strip` | default is `0`  Same as the --strip argument of Unix patch. |
 
 ## bazel\_dep
@@ -58,7 +58,7 @@ Declares a direct dependency on another Bazel module.
 | `name` | required  The name of the module to be added as a direct dependency. |
 | `version` | default is `''`  The version of the module to be added as a direct dependency. |
 | `max_compatibility_level` | default is `-1`  The maximum `compatibility_level` supported for the module to be added as a direct dependency. The version of the module implies the minimum compatibility\_level supported, as well as the maximum if this attribute is not specified. |
-| `repo_name` | [string](../core/string); or `None`; default is `''`  The name of the external repo representing this dependency. This is by default the name of the module. Can be set to `None` to make this dependency a "*nodep*" dependency: in this case, this `bazel_dep` specification is only honored if the target module already exists in the dependency graph by some other means. |
+| `repo_name` | [string](/versions/7.7.1/rules/lib/core/string); or `None`; default is `''`  The name of the external repo representing this dependency. This is by default the name of the module. Can be set to `None` to make this dependency a "*nodep*" dependency: in this case, this `bazel_dep` specification is only honored if the target module already exists in the dependency graph by some other means. |
 | `dev_dependency` | default is `False`  If true, this dependency will be ignored if the current module is not the root module or `--ignore_dev_dependency` is enabled. |
 
 ## flag\_alias
@@ -91,8 +91,8 @@ Specifies that a dependency should come from a certain commit of a Git repositor
 | `module_name` | required  The name of the Bazel module dependency to apply this override to. |
 | `remote` | required  The URL of the remote Git repository. |
 | `commit` | default is `''`  The commit that should be checked out. |
-| `patches` | Iterable of [string](../core/string)s; default is `[]`  A list of labels pointing to patch files to apply for this module. The patch files must exist in the source tree of the top level project. They are applied in the list order. |
-| `patch_cmds` | Iterable of [string](../core/string)s; default is `[]`  Sequence of Bash commands to be applied on Linux/Macos after patches are applied. |
+| `patches` | Iterable of [string](/versions/7.7.1/rules/lib/core/string)s; default is `[]`  A list of labels pointing to patch files to apply for this module. The patch files must exist in the source tree of the top level project. They are applied in the list order. |
+| `patch_cmds` | Iterable of [string](/versions/7.7.1/rules/lib/core/string)s; default is `[]`  Sequence of Bash commands to be applied on Linux/Macos after patches are applied. |
 | `patch_strip` | default is `0`  Same as the --strip argument of Unix patch. |
 | `init_submodules` | default is `False`  Whether git submodules in the fetched repo should be recursively initialized. |
 | `strip_prefix` | default is `''`  A directory prefix to strip from the extracted files. This can be used to target a subdirectory of the git repo. Note that the subdirectory must have its own `MODULE.bazel` file with a module name that is the same as the `module\_name` arg passed to this `git\_override`. |
@@ -171,7 +171,7 @@ It should be called at most once, and if called, it must be the very first direc
 | `version` | default is `''`  The version of the module. Can be omitted only if this module is the root module (as in, if it's not going to be depended on by another module). The version must be in a relaxed SemVer format; see [the documentation](/versions/7.7.1/external/module#version_format) for more details. |
 | `compatibility_level` | default is `0`  The compatibility level of the module; this should be changed every time a major incompatible change is introduced. This is essentially the "major version" of the module in terms of SemVer, except that it's not embedded in the version string itself, but exists as a separate field. Modules with different compatibility levels participate in version resolution as if they're modules with different names, but the final dependency graph cannot contain multiple modules with the same name but different compatibility levels (unless `multiple_version_override` is in effect). See [the documentation](/versions/7.7.1/external/module#compatibility_level) for more details. |
 | `repo_name` | default is `''`  The name of the repository representing this module, as seen by the module itself. By default, the name of the repo is the name of the module. This can be specified to ease migration for projects that have been using a repo name for itself that differs from its module name. |
-| `bazel_compatibility` | Iterable of [string](../core/string)s; default is `[]`  A list of bazel versions that allows users to declare which Bazel versions are compatible with this module. It does NOT affect dependency resolution, but bzlmod will use this information to check if your current Bazel version is compatible. The format of this value is a string of some constraint values separated by comma. Three constraints are supported: <=X.X.X: The Bazel version must be equal or older than X.X.X. Used when there is a known incompatible change in a newer version. >=X.X.X: The Bazel version must be equal or newer than X.X.X.Used when you depend on some features that are only available since X.X.X. -X.X.X: The Bazel version X.X.X is not compatible. Used when there is a bug in X.X.X that breaks you, but fixed in later versions. |
+| `bazel_compatibility` | Iterable of [string](/versions/7.7.1/rules/lib/core/string)s; default is `[]`  A list of bazel versions that allows users to declare which Bazel versions are compatible with this module. It does NOT affect dependency resolution, but bzlmod will use this information to check if your current Bazel version is compatible. The format of this value is a string of some constraint values separated by comma. Three constraints are supported: <=X.X.X: The Bazel version must be equal or older than X.X.X. Used when there is a known incompatible change in a newer version. >=X.X.X: The Bazel version must be equal or newer than X.X.X.Used when you depend on some features that are only available since X.X.X. -X.X.X: The Bazel version X.X.X is not compatible. Used when there is a bug in X.X.X that breaks you, but fixed in later versions. |
 
 ## multiple\_version\_override
 
@@ -186,7 +186,7 @@ Specifies that a dependency should still come from a registry, but multiple vers
 | Parameter | Description |
 | --- | --- |
 | `module_name` | required  The name of the Bazel module dependency to apply this override to. |
-| `versions` | Iterable of [string](../core/string)s; required  Explicitly specifies the versions allowed to coexist. These versions must already be present in the dependency graph pre-selection. Dependencies on this module will be "upgraded" to the nearest higher allowed version at the same compatibility level, whereas dependencies that have a higher version than any allowed versions at the same compatibility level will cause an error. |
+| `versions` | Iterable of [string](/versions/7.7.1/rules/lib/core/string)s; required  Explicitly specifies the versions allowed to coexist. These versions must already be present in the dependency graph pre-selection. Dependencies on this module will be "upgraded" to the nearest higher allowed version at the same compatibility level, whereas dependencies that have a higher version than any allowed versions at the same compatibility level will cause an error. |
 | `registry` | default is `''`  Overrides the registry for this module; instead of finding this module from the default list of registries, the given registry should be used. |
 
 ## override\_repo
@@ -222,7 +222,7 @@ Specifies already-defined execution platforms to be registered when this module
 | Parameter | Description |
 | --- | --- |
 | `dev_dependency` | default is `False`  If true, the execution platforms will not be registered if the current module is not the root module or `--ignore\_dev\_dependency` is enabled. |
-| `platform_labels` | [sequence](../core/list) of [string](../core/string)s; required  The labels of the platforms to register. |
+| `platform_labels` | [sequence](/versions/7.7.1/rules/lib/core/list) of [string](/versions/7.7.1/rules/lib/core/string)s; required  The labels of the platforms to register. |
 
 ## register\_toolchains
 
@@ -237,7 +237,7 @@ Specifies already-defined toolchains to be registered when this module is select
 | Parameter | Description |
 | --- | --- |
 | `dev_dependency` | default is `False`  If true, the toolchains will not be registered if the current module is not the root module or `--ignore\_dev\_dependency` is enabled. |
-| `toolchain_labels` | [sequence](../core/list) of [string](../core/string)s; required  The labels of the toolchains to register. Labels can include `:all`, in which case, all toolchain-providing targets in the package will be registered in lexicographical order by name. |
+| `toolchain_labels` | [sequence](/versions/7.7.1/rules/lib/core/list) of [string](/versions/7.7.1/rules/lib/core/string)s; required  The labels of the toolchains to register. Labels can include `:all`, in which case, all toolchain-providing targets in the package will be registered in lexicographical order by name. |
 
 ## single\_version\_override
 
@@ -254,8 +254,8 @@ Specifies that a dependency should still come from a registry, but its version s
 | `module_name` | required  The name of the Bazel module dependency to apply this override to. |
 | `version` | default is `''`  Overrides the declared version of this module in the dependency graph. In other words, this module will be "pinned" to this override version. This attribute can be omitted if all one wants to override is the registry or the patches. |
 | `registry` | default is `''`  Overrides the registry for this module; instead of finding this module from the default list of registries, the given registry should be used. |
-| `patches` | Iterable of [string](../core/string)s; default is `[]`  A list of labels pointing to patch files to apply for this module. The patch files must exist in the source tree of the top level project. They are applied in the list order. If a patch makes changes to the MODULE.bazel file, these changes will only be effective if the patch file is provided by the root module. |
-| `patch_cmds` | Iterable of [string](../core/string)s; default is `[]`  Sequence of Bash commands to be applied on Linux/Macos after patches are applied. Changes to the MODULE.bazel file will not be effective. |
+| `patches` | Iterable of [string](/versions/7.7.1/rules/lib/core/string)s; default is `[]`  A list of labels pointing to patch files to apply for this module. The patch files must exist in the source tree of the top level project. They are applied in the list order. If a patch makes changes to the MODULE.bazel file, these changes will only be effective if the patch file is provided by the root module. |
+| `patch_cmds` | Iterable of [string](/versions/7.7.1/rules/lib/core/string)s; default is `[]`  Sequence of Bash commands to be applied on Linux/Macos after patches are applied. Changes to the MODULE.bazel file will not be effective. |
 | `patch_strip` | default is `0`  Same as the --strip argument of Unix patch. |
 
 ## use\_extension
diff --git a/versions/7.7.1/rules/lib/globals/workspace.mdx b/versions/7.7.1/rules/lib/globals/workspace.mdx
index e7d9348a..67f7f9ec 100644
--- a/versions/7.7.1/rules/lib/globals/workspace.mdx
+++ b/versions/7.7.1/rules/lib/globals/workspace.mdx
@@ -26,7 +26,7 @@ Gives a target an alias in the `//external` package.
 | Parameter | Description |
 | --- | --- |
 | `name` | required  The label under '//external' to serve as the alias name |
-| `actual` | [string](../core/string); or `None`; default is `None`  The real label to be aliased |
+| `actual` | [string](/versions/7.7.1/rules/lib/core/string); or `None`; default is `None`  The real label to be aliased |
 
 ## register\_execution\_platforms
 
@@ -40,7 +40,7 @@ Register an already-defined platform so that Bazel can use it as an [execution p
 
 | Parameter | Description |
 | --- | --- |
-| `platform_labels` | [sequence](../core/list) of [string](../core/string)s; required  The labels of the platforms to register. |
+| `platform_labels` | [sequence](/versions/7.7.1/rules/lib/core/list) of [string](/versions/7.7.1/rules/lib/core/string)s; required  The labels of the platforms to register. |
 
 ## register\_toolchains
 
@@ -54,7 +54,7 @@ Register an already-defined toolchain so that Bazel can use it during [toolchain
 
 | Parameter | Description |
 | --- | --- |
-| `toolchain_labels` | [sequence](../core/list) of [string](../core/string)s; required  The labels of the toolchains to register. Labels can include `:all`, in which case, all toolchain-providing targets in the package will be registered in lexicographical order by name. |
+| `toolchain_labels` | [sequence](/versions/7.7.1/rules/lib/core/list) of [string](/versions/7.7.1/rules/lib/core/string)s; required  The labels of the toolchains to register. Labels can include `:all`, in which case, all toolchain-providing targets in the package will be registered in lexicographical order by name. |
 
 ## workspace
 
diff --git a/versions/7.7.1/rules/lib/providers/AndroidNeverLinkLibrariesProvider.mdx b/versions/7.7.1/rules/lib/providers/AndroidNeverLinkLibrariesProvider.mdx
index ca808cd9..d6e76280 100644
--- a/versions/7.7.1/rules/lib/providers/AndroidNeverLinkLibrariesProvider.mdx
+++ b/versions/7.7.1/rules/lib/providers/AndroidNeverLinkLibrariesProvider.mdx
@@ -22,7 +22,7 @@ The `AndroidNeverLinkLibrariesProvider` constructor.
 
 | Parameter | Description |
 | --- | --- |
-| `transitive_neverlink_libraries` | [depset](../builtins/depset) of [File](../builtins/File)s; required  The transitive neverlink libraries |
+| `transitive_neverlink_libraries` | [depset](/versions/7.7.1/rules/lib/builtins/depset) of [File](/versions/7.7.1/rules/lib/builtins/File)s; required  The transitive neverlink libraries |
 
 ## to\_json
 
diff --git a/versions/7.7.1/rules/lib/providers/BaselineProfileProvider.mdx b/versions/7.7.1/rules/lib/providers/BaselineProfileProvider.mdx
index 218f8070..36051413 100644
--- a/versions/7.7.1/rules/lib/providers/BaselineProfileProvider.mdx
+++ b/versions/7.7.1/rules/lib/providers/BaselineProfileProvider.mdx
@@ -22,8 +22,8 @@ The `BaselineProfileProvider` constructor.
 
 | Parameter | Description |
 | --- | --- |
-| `files` | [depset](../builtins/depset) of [File](../builtins/File)s; required  Transitive baseline profile files. |
-| `art_profile_zip` | [File](../builtins/File); or `None`; default is `None`  The final ART profile zip to be packaged in the APK. Optional, only used for migration purposes. |
+| `files` | [depset](/versions/7.7.1/rules/lib/builtins/depset) of [File](/versions/7.7.1/rules/lib/builtins/File)s; required  Transitive baseline profile files. |
+| `art_profile_zip` | [File](/versions/7.7.1/rules/lib/builtins/File); or `None`; default is `None`  The final ART profile zip to be packaged in the APK. Optional, only used for migration purposes. |
 
 ## to\_json
 
diff --git a/versions/7.7.1/rules/lib/providers/CcInfo.mdx b/versions/7.7.1/rules/lib/providers/CcInfo.mdx
index 3fc10b7d..35026c38 100644
--- a/versions/7.7.1/rules/lib/providers/CcInfo.mdx
+++ b/versions/7.7.1/rules/lib/providers/CcInfo.mdx
@@ -24,8 +24,8 @@ The `CcInfo` constructor.
 
 | Parameter | Description |
 | --- | --- |
-| `compilation_context` | [CompilationContext](../builtins/CompilationContext); or `None`; default is `None`  The `CompilationContext`. |
-| `linking_context` | [LinkingContext](../builtins/LinkingContext); or `None`; default is `None`  The `LinkingContext`. |
+| `compilation_context` | [CompilationContext](/versions/7.7.1/rules/lib/builtins/CompilationContext); or `None`; default is `None`  The `CompilationContext`. |
+| `linking_context` | [LinkingContext](/versions/7.7.1/rules/lib/builtins/LinkingContext); or `None`; default is `None`  The `LinkingContext`. |
 | `debug_context` | DebugContext; or `None`; default is `None`  The `DebugContext`. |
 
 ## compilation\_context
diff --git a/versions/7.7.1/rules/lib/providers/DebugPackageInfo.mdx b/versions/7.7.1/rules/lib/providers/DebugPackageInfo.mdx
index 0e37850f..17723a63 100644
--- a/versions/7.7.1/rules/lib/providers/DebugPackageInfo.mdx
+++ b/versions/7.7.1/rules/lib/providers/DebugPackageInfo.mdx
@@ -27,9 +27,9 @@ The `DebugPackageInfo` constructor.
 | Parameter | Description |
 | --- | --- |
 | `target_label` | required  The label for the \*\_binary target |
-| `stripped_file` | [File](../builtins/File); or `None`; default is `None`  The stripped file (the explicit ".stripped" target) |
+| `stripped_file` | [File](/versions/7.7.1/rules/lib/builtins/File); or `None`; default is `None`  The stripped file (the explicit ".stripped" target) |
 | `unstripped_file` | required  The unstripped file (the default executable target). |
-| `dwp_file` | [File](../builtins/File); or `None`; default is `None`  The .dwp file (for fission builds) or null if --fission=no. |
+| `dwp_file` | [File](/versions/7.7.1/rules/lib/builtins/File); or `None`; default is `None`  The .dwp file (for fission builds) or null if --fission=no. |
 
 ## dwp\_file
 
diff --git a/versions/7.7.1/rules/lib/providers/DefaultInfo.mdx b/versions/7.7.1/rules/lib/providers/DefaultInfo.mdx
index 19d748c0..bacdc76c 100644
--- a/versions/7.7.1/rules/lib/providers/DefaultInfo.mdx
+++ b/versions/7.7.1/rules/lib/providers/DefaultInfo.mdx
@@ -30,11 +30,11 @@ The `DefaultInfo` constructor.
 
 | Parameter | Description |
 | --- | --- |
-| `files` | [depset](../builtins/depset); or `None`; default is `None`  A [`depset`](../builtins/depset) of [`File`](../builtins/File) objects representing the default outputs to build when this target is specified on the bazel command line. By default it is all predeclared outputs. |
-| `runfiles` | [runfiles](../builtins/runfiles); or `None`; default is `None`  runfiles descriptor describing the files that this target needs when run (via the `run` command or as a tool dependency). |
-| `data_runfiles` | [runfiles](../builtins/runfiles); or `None`; default is `None`  **It is recommended that you avoid using this parameter (see ["runfiles features to avoid"](https://bazel.build/versions/7.7.1/extending/rules#runfiles_features_to_avoid))** runfiles descriptor describing the runfiles this target needs to run when it is a dependency via the `data` attribute. |
-| `default_runfiles` | [runfiles](../builtins/runfiles); or `None`; default is `None`  **It is recommended that you avoid using this parameter (see ["runfiles features to avoid"](https://bazel.build/versions/7.7.1/extending/rules#runfiles_features_to_avoid))** runfiles descriptor describing the runfiles this target needs to run when it is a dependency via any attribute other than the `data` attribute. |
-| `executable` | [File](../builtins/File); or `None`; default is `None`  If this rule is marked [`executable`](../globals/bzl#rule.executable) or [`test`](../globals/bzl#rule.test), this is a [`File`](../builtins/File) object representing the file that should be executed to run the target. By default it is the predeclared output `ctx.outputs.executable`. |
+| `files` | [depset](/versions/7.7.1/rules/lib/builtins/depset); or `None`; default is `None`  A [`depset`](/versions/7.7.1/rules/lib/builtins/depset) of [`File`](/versions/7.7.1/rules/lib/builtins/File) objects representing the default outputs to build when this target is specified on the bazel command line. By default it is all predeclared outputs. |
+| `runfiles` | [runfiles](/versions/7.7.1/rules/lib/builtins/runfiles); or `None`; default is `None`  runfiles descriptor describing the files that this target needs when run (via the `run` command or as a tool dependency). |
+| `data_runfiles` | [runfiles](/versions/7.7.1/rules/lib/builtins/runfiles); or `None`; default is `None`  **It is recommended that you avoid using this parameter (see ["runfiles features to avoid"](https://bazel.build/versions/7.7.1/extending/rules#runfiles_features_to_avoid))** runfiles descriptor describing the runfiles this target needs to run when it is a dependency via the `data` attribute. |
+| `default_runfiles` | [runfiles](/versions/7.7.1/rules/lib/builtins/runfiles); or `None`; default is `None`  **It is recommended that you avoid using this parameter (see ["runfiles features to avoid"](https://bazel.build/versions/7.7.1/extending/rules#runfiles_features_to_avoid))** runfiles descriptor describing the runfiles this target needs to run when it is a dependency via any attribute other than the `data` attribute. |
+| `executable` | [File](/versions/7.7.1/rules/lib/builtins/File); or `None`; default is `None`  If this rule is marked [`executable`](/versions/7.7.1/rules/lib/globals/bzl#rule.executable) or [`test`](/versions/7.7.1/rules/lib/globals/bzl#rule.test), this is a [`File`](/versions/7.7.1/rules/lib/builtins/File) object representing the file that should be executed to run the target. By default it is the predeclared output `ctx.outputs.executable`. |
 
 ## data\_runfiles
 
@@ -60,7 +60,7 @@ May return `None`.
 depset DefaultInfo.files
 ```
 
-A [`depset`](../builtins/depset) of [`File`](../builtins/File) objects representing the default outputs to build when this target is specified on the bazel command line. By default it is all predeclared outputs.
+A [`depset`](/versions/7.7.1/rules/lib/builtins/depset) of [`File`](/versions/7.7.1/rules/lib/builtins/File) objects representing the default outputs to build when this target is specified on the bazel command line. By default it is all predeclared outputs.
 May return `None`.
 
 ## files\_to\_run
@@ -69,7 +69,7 @@ May return `None`.
 FilesToRunProvider DefaultInfo.files_to_run
 ```
 
-A [`FilesToRunProvider`](../providers/FilesToRunProvider) object containing information about the executable and runfiles of the target.
+A [`FilesToRunProvider`](/versions/7.7.1/rules/lib/providers/FilesToRunProvider) object containing information about the executable and runfiles of the target.
 May return `None`.
 
 ## to\_json
diff --git a/versions/7.7.1/rules/lib/providers/ExecutionInfo.mdx b/versions/7.7.1/rules/lib/providers/ExecutionInfo.mdx
index 995804e5..1257d767 100644
--- a/versions/7.7.1/rules/lib/providers/ExecutionInfo.mdx
+++ b/versions/7.7.1/rules/lib/providers/ExecutionInfo.mdx
@@ -24,8 +24,8 @@ Creates an instance.
 
 | Parameter | Description |
 | --- | --- |
-| `requirements` | [dict](../core/dict); default is `{}`  A dict indicating special execution requirements, such as hardware platforms. |
-| `exec_group` | [string](../core/string); default is `'test'`  The name of the exec group that is used to execute the test. |
+| `requirements` | [dict](/versions/7.7.1/rules/lib/core/dict); default is `{}`  A dict indicating special execution requirements, such as hardware platforms. |
+| `exec_group` | [string](/versions/7.7.1/rules/lib/core/string); default is `'test'`  The name of the exec group that is used to execute the test. |
 
 ## exec\_group
 
diff --git a/versions/7.7.1/rules/lib/providers/GeneratedExtensionRegistryProvider.mdx b/versions/7.7.1/rules/lib/providers/GeneratedExtensionRegistryProvider.mdx
index f4be6e55..0d66fb2e 100644
--- a/versions/7.7.1/rules/lib/providers/GeneratedExtensionRegistryProvider.mdx
+++ b/versions/7.7.1/rules/lib/providers/GeneratedExtensionRegistryProvider.mdx
@@ -26,7 +26,7 @@ The `GeneratedExtensionRegistryProvider` constructor.
 | `isLite` | required  If this registry was generated for lite or full runtime |
 | `classJar` | required  Class jar generated by the registry |
 | `srcJar` | required  Source jar generated by the registry |
-| `inputs` | [depset](../builtins/depset) of [File](../builtins/File)s; required  Proto jars used to generate the registry |
+| `inputs` | [depset](/versions/7.7.1/rules/lib/builtins/depset) of [File](/versions/7.7.1/rules/lib/builtins/File)s; required  Proto jars used to generate the registry |
 
 ## to\_json
 
diff --git a/versions/7.7.1/rules/lib/providers/InstrumentedFilesInfo.mdx b/versions/7.7.1/rules/lib/providers/InstrumentedFilesInfo.mdx
index b200e9e8..d2fb1097 100644
--- a/versions/7.7.1/rules/lib/providers/InstrumentedFilesInfo.mdx
+++ b/versions/7.7.1/rules/lib/providers/InstrumentedFilesInfo.mdx
@@ -17,7 +17,7 @@ Contains information about source files and instrumentation metadata files for r
 depset InstrumentedFilesInfo.instrumented_files
 ```
 
-[`depset`](../builtins/depset) of [`File`](../builtins/File) objects representing instrumented source files for this target and its dependencies.
+[`depset`](/versions/7.7.1/rules/lib/builtins/depset) of [`File`](/versions/7.7.1/rules/lib/builtins/File) objects representing instrumented source files for this target and its dependencies.
 
 ## metadata\_files
 
@@ -25,7 +25,7 @@ depset InstrumentedFilesInfo.instrumented_files
 depset InstrumentedFilesInfo.metadata_files
 ```
 
-[`depset`](../builtins/depset) of [`File`](../builtins/File) objects representing coverage metadata files for this target and its dependencies. These files contain additional information required to generate LCOV-format coverage output after the code is executed, e.g. the `.gcno` files generated when `gcc` is run with `-ftest-coverage`.
+[`depset`](/versions/7.7.1/rules/lib/builtins/depset) of [`File`](/versions/7.7.1/rules/lib/builtins/File) objects representing coverage metadata files for this target and its dependencies. These files contain additional information required to generate LCOV-format coverage output after the code is executed, e.g. the `.gcno` files generated when `gcc` is run with `-ftest-coverage`.
 
 ## to\_json
 
diff --git a/versions/7.7.1/rules/lib/providers/PackageSpecificationInfo.mdx b/versions/7.7.1/rules/lib/providers/PackageSpecificationInfo.mdx
index 81cc8393..442b0eea 100644
--- a/versions/7.7.1/rules/lib/providers/PackageSpecificationInfo.mdx
+++ b/versions/7.7.1/rules/lib/providers/PackageSpecificationInfo.mdx
@@ -22,7 +22,7 @@ Checks if a target exists in a package group.
 
 | Parameter | Description |
 | --- | --- |
-| `target` | [Label](../builtins/Label); or [string](../core/string); required  A target which is checked if it exists inside the package group. |
+| `target` | [Label](/versions/7.7.1/rules/lib/builtins/Label); or [string](/versions/7.7.1/rules/lib/core/string); required  A target which is checked if it exists inside the package group. |
 
 ## to\_json
 
diff --git a/versions/7.7.1/rules/lib/providers/ProguardSpecProvider.mdx b/versions/7.7.1/rules/lib/providers/ProguardSpecProvider.mdx
index aaf4489b..f4bc78a4 100644
--- a/versions/7.7.1/rules/lib/providers/ProguardSpecProvider.mdx
+++ b/versions/7.7.1/rules/lib/providers/ProguardSpecProvider.mdx
@@ -22,7 +22,7 @@ The `ProguardSpecProvider` constructor.
 
 | Parameter | Description |
 | --- | --- |
-| `specs` | [depset](../builtins/depset) of [File](../builtins/File)s; required  Transitive proguard specs. |
+| `specs` | [depset](/versions/7.7.1/rules/lib/builtins/depset) of [File](/versions/7.7.1/rules/lib/builtins/File)s; required  Transitive proguard specs. |
 
 ## to\_json
 
diff --git a/versions/7.7.1/rules/lib/providers/PyInfo.mdx b/versions/7.7.1/rules/lib/providers/PyInfo.mdx
index 0be19970..d32d240a 100644
--- a/versions/7.7.1/rules/lib/providers/PyInfo.mdx
+++ b/versions/7.7.1/rules/lib/providers/PyInfo.mdx
@@ -25,9 +25,9 @@ The `PyInfo` constructor.
 
 | Parameter | Description |
 | --- | --- |
-| `transitive_sources` | [depset](../builtins/depset) of [File](../builtins/File)s; required  The value for the new object's `transitive_sources` field. |
+| `transitive_sources` | [depset](/versions/7.7.1/rules/lib/builtins/depset) of [File](/versions/7.7.1/rules/lib/builtins/File)s; required  The value for the new object's `transitive_sources` field. |
 | `uses_shared_libraries` | default is `False`  The value for the new object's `uses_shared_libraries` field. |
-| `imports` | [depset](../builtins/depset) of [string](../core/string)s; default is `unbound`  The value for the new object's `imports` field. |
+| `imports` | [depset](/versions/7.7.1/rules/lib/builtins/depset) of [string](/versions/7.7.1/rules/lib/core/string)s; default is `unbound`  The value for the new object's `imports` field. |
 | `has_py2_only_sources` | default is `False`  The value for the new object's `has_py2_only_sources` field. |
 | `has_py3_only_sources` | default is `False`  The value for the new object's `has_py3_only_sources` field. |
 
diff --git a/versions/7.7.1/rules/lib/providers/PyRuntimeInfo.mdx b/versions/7.7.1/rules/lib/providers/PyRuntimeInfo.mdx
index a0d58f4c..f4888a5a 100644
--- a/versions/7.7.1/rules/lib/providers/PyRuntimeInfo.mdx
+++ b/versions/7.7.1/rules/lib/providers/PyRuntimeInfo.mdx
@@ -30,14 +30,14 @@ The `PyRuntimeInfo` constructor.
 
 | Parameter | Description |
 | --- | --- |
-| `interpreter_path` | [string](../core/string); or `None`; default is `None`  The value for the new object's `interpreter_path` field. Do not give a value for this argument if you pass in `interpreter`. |
-| `interpreter` | [File](../builtins/File); or `None`; default is `None`  The value for the new object's `interpreter` field. Do not give a value for this argument if you pass in `interpreter_path`. |
-| `files` | [depset](../builtins/depset) of [File](../builtins/File)s; or `None`; default is `None`  The value for the new object's `files` field. Do not give a value for this argument if you pass in `interpreter_path`. If `interpreter` is given and this argument is `None`, `files` becomes an empty `depset` instead. |
-| `coverage_tool` | [File](../builtins/File); or `None`; default is `None`  The value for the new object's `coverage_tool` field. |
-| `coverage_files` | [depset](../builtins/depset) of [File](../builtins/File)s; or `None`; default is `None`  The value for the new object's `coverage_files` field. Do not give a value for this argument if you do not also pass in `coverage_tool`. |
+| `interpreter_path` | [string](/versions/7.7.1/rules/lib/core/string); or `None`; default is `None`  The value for the new object's `interpreter_path` field. Do not give a value for this argument if you pass in `interpreter`. |
+| `interpreter` | [File](/versions/7.7.1/rules/lib/builtins/File); or `None`; default is `None`  The value for the new object's `interpreter` field. Do not give a value for this argument if you pass in `interpreter_path`. |
+| `files` | [depset](/versions/7.7.1/rules/lib/builtins/depset) of [File](/versions/7.7.1/rules/lib/builtins/File)s; or `None`; default is `None`  The value for the new object's `files` field. Do not give a value for this argument if you pass in `interpreter_path`. If `interpreter` is given and this argument is `None`, `files` becomes an empty `depset` instead. |
+| `coverage_tool` | [File](/versions/7.7.1/rules/lib/builtins/File); or `None`; default is `None`  The value for the new object's `coverage_tool` field. |
+| `coverage_files` | [depset](/versions/7.7.1/rules/lib/builtins/depset) of [File](/versions/7.7.1/rules/lib/builtins/File)s; or `None`; default is `None`  The value for the new object's `coverage_files` field. Do not give a value for this argument if you do not also pass in `coverage_tool`. |
 | `python_version` | required  The value for the new object's `python_version` field. |
-| `stub_shebang` | [string](../core/string); default is `None`  The value for the new object's `stub_shebang` field. If None or not specified, `#!/usr/bin/env python3` is used. |
-| `bootstrap_template` | [File](../builtins/File); or `None`; default is `None` |
+| `stub_shebang` | [string](/versions/7.7.1/rules/lib/core/string); default is `None`  The value for the new object's `stub_shebang` field. If None or not specified, `#!/usr/bin/env python3` is used. |
+| `bootstrap_template` | [File](/versions/7.7.1/rules/lib/builtins/File); or `None`; default is `None` |
 
 ## bootstrap\_template
 
diff --git a/versions/7.7.1/rules/lib/repo/index.mdx b/versions/7.7.1/rules/lib/repo/index.mdx
index 8b364d2d..52aa6e51 100644
--- a/versions/7.7.1/rules/lib/repo/index.mdx
+++ b/versions/7.7.1/rules/lib/repo/index.mdx
@@ -2,10 +2,10 @@
 title: 'Repository Rules'
 ---
 
-* [Rules related to git](git)
-* [Rules related to http](http)
-* [Rules related to local directories](local)
+* [Rules related to git](/versions/7.7.1/rules/lib/repo/git)
+* [Rules related to http](/versions/7.7.1/rules/lib/repo/http)
+* [Rules related to local directories](/versions/7.7.1/rules/lib/repo/local)
 
 # Generic functions for repository rule authors
 
-* [Utility functions on patching](utils)
+* [Utility functions on patching](/versions/7.7.1/rules/lib/repo/utils)
diff --git a/versions/7.7.1/rules/lib/toplevel/apple_common.mdx b/versions/7.7.1/rules/lib/toplevel/apple_common.mdx
index 22178396..9974ccf5 100644
--- a/versions/7.7.1/rules/lib/toplevel/apple_common.mdx
+++ b/versions/7.7.1/rules/lib/toplevel/apple_common.mdx
@@ -30,7 +30,7 @@ Functions for Starlark to access internals of the apple rule implementations.
 dict apple_common.apple_host_system_env(xcode_config)
 ```
 
-Returns a [dict](../core/dict) of environment variables that should be set for actions that need to run build tools on an Apple host system, such as the version of Xcode that should be used. The keys are variable names and the values are their corresponding values.
+Returns a [dict](/versions/7.7.1/rules/lib/core/dict) of environment variables that should be set for actions that need to run build tools on an Apple host system, such as the version of Xcode that should be used. The keys are variable names and the values are their corresponding values.
 
 ### Parameters
 
@@ -97,7 +97,7 @@ p = dep[apple_common.AppleExecutableBinary]
 DottedVersion apple_common.dotted_version(version)
 ```
 
-Creates a new [DottedVersion](../builtins/DottedVersion) instance.
+Creates a new [DottedVersion](/versions/7.7.1/rules/lib/builtins/DottedVersion) instance.
 
 ### Parameters
 
@@ -120,11 +120,11 @@ This API is **highly experimental** and subject to change at any time. Do not de
 | Parameter | Description |
 | --- | --- |
 | `ctx` | required |
-| `avoid_deps` | [sequence](../core/list) of [Target](../builtins/Target)s; or `None`; default is `None` |
-| `extra_linkopts` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  Extra linkopts to be passed to the linker action. |
-| `extra_link_inputs` | [sequence](../core/list) of [File](../builtins/File)s; default is `[]`  Extra files to pass to the linker action. |
-| `extra_requested_features` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  Extra requested features to be passed to the linker action. |
-| `extra_disabled_features` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  Extra disabled features to be passed to the linker action. |
+| `avoid_deps` | [sequence](/versions/7.7.1/rules/lib/core/list) of [Target](/versions/7.7.1/rules/lib/builtins/Target)s; or `None`; default is `None` |
+| `extra_linkopts` | [sequence](/versions/7.7.1/rules/lib/core/list) of [string](/versions/7.7.1/rules/lib/core/string)s; default is `[]`  Extra linkopts to be passed to the linker action. |
+| `extra_link_inputs` | [sequence](/versions/7.7.1/rules/lib/core/list) of [File](/versions/7.7.1/rules/lib/builtins/File)s; default is `[]`  Extra files to pass to the linker action. |
+| `extra_requested_features` | [sequence](/versions/7.7.1/rules/lib/core/list) of [string](/versions/7.7.1/rules/lib/core/string)s; default is `[]`  Extra requested features to be passed to the linker action. |
+| `extra_disabled_features` | [sequence](/versions/7.7.1/rules/lib/core/list) of [string](/versions/7.7.1/rules/lib/core/string)s; default is `[]`  Extra disabled features to be passed to the linker action. |
 | `stamp` | default is `-1`  Whether to include build information in the linked binary. If 1, build information is always included. If 0, build information is always excluded. If -1 (the default), then the behavior is determined by the --[no]stamp flag. This should be set to 0 when generating the executable output for test rules. |
 
 ## link\_multi\_arch\_static\_library
@@ -155,11 +155,11 @@ Creates a new AppleDynamicFramework provider instance.
 
 | Parameter | Description |
 | --- | --- |
-| `binary` | [File](../builtins/File); or `None`; default is `None`  The dylib binary artifact of the dynamic framework. |
+| `binary` | [File](/versions/7.7.1/rules/lib/builtins/File); or `None`; default is `None`  The dylib binary artifact of the dynamic framework. |
 | `cc_info` | default is `None`  A CcInfo which contains information about the transitive dependencies linked into the binary. |
 | `objc` | default is `None`  An ObjcProvider which contains information about the transitive dependencies linked into the binary. |
-| `framework_dirs` | [depset](../builtins/depset) of [string](../core/string)s; or `None`; default is `None`  The framework path names used as link inputs in order to link against the dynamic framework. |
-| `framework_files` | [depset](../builtins/depset) of [File](../builtins/File)s; or `None`; default is `None`  The full set of artifacts that should be included as inputs to link against the dynamic framework |
+| `framework_dirs` | [depset](/versions/7.7.1/rules/lib/builtins/depset) of [string](/versions/7.7.1/rules/lib/core/string)s; or `None`; default is `None`  The framework path names used as link inputs in order to link against the dynamic framework. |
+| `framework_files` | [depset](/versions/7.7.1/rules/lib/builtins/depset) of [File](/versions/7.7.1/rules/lib/builtins/File)s; or `None`; default is `None`  The full set of artifacts that should be included as inputs to link against the dynamic framework |
 
 ## new\_executable\_binary\_provider
 
@@ -173,7 +173,7 @@ Creates a new AppleExecutableBinaryInfo provider instance.
 
 | Parameter | Description |
 | --- | --- |
-| `binary` | [File](../builtins/File); or `None`; default is `None`  The binary artifact of the executable. |
+| `binary` | [File](/versions/7.7.1/rules/lib/builtins/File); or `None`; default is `None`  The binary artifact of the executable. |
 | `cc_info` | default is `None`  A CcInfo which contains information about the transitive dependencies linked into the binary. |
 | `objc` | default is `None`  An ObjcProvider which contains information about the transitive dependencies linked into the binary. |
 
@@ -224,7 +224,7 @@ An enum-like struct that contains the following fields corresponding to Apple pl
 * `watchos_device`
 * `watchos_simulator`
 
-These values can be passed to methods that expect a platform, like [XcodeVersionConfig.sdk\_version\_for\_platform](../providers/XcodeVersionConfig#sdk_version_for_platform).
+These values can be passed to methods that expect a platform, like [XcodeVersionConfig.sdk\_version\_for\_platform](/versions/7.7.1/rules/lib/providers/XcodeVersionConfig#sdk_version_for_platform).
 
 ## platform\_type
 
@@ -240,7 +240,7 @@ An enum-like struct that contains the following fields corresponding to Apple pl
 * `visionos`
 * `watchos`
 
-These values can be passed to methods that expect a platform type, like the 'apple' configuration fragment's [multi\_arch\_platform](../fragments/apple#multi_arch_platform) method.
+These values can be passed to methods that expect a platform type, like the 'apple' configuration fragment's [multi\_arch\_platform](/versions/7.7.1/rules/lib/fragments/apple#multi_arch_platform) method.
 
 Example:
 
diff --git a/versions/7.7.1/rules/lib/toplevel/attr.mdx b/versions/7.7.1/rules/lib/toplevel/attr.mdx
index c64cff98..0a5faf98 100644
--- a/versions/7.7.1/rules/lib/toplevel/attr.mdx
+++ b/versions/7.7.1/rules/lib/toplevel/attr.mdx
@@ -2,7 +2,7 @@
 title: 'attr'
 ---
 
-This is a top-level module for defining the attribute schemas of a rule or aspect. Each function returns an object representing the schema of a single attribute. These objects are used as the values of the `attrs` dictionary argument of [`rule()`](../globals/bzl#rule) and [`aspect()`](../globals/bzl#aspect).
+This is a top-level module for defining the attribute schemas of a rule or aspect. Each function returns an object representing the schema of a single attribute. These objects are used as the values of the `attrs` dictionary argument of [`rule()`](/versions/7.7.1/rules/lib/globals/bzl#rule) and [`aspect()`](/versions/7.7.1/rules/lib/globals/bzl#aspect).
 
 See the Rules page for more on [defining](https://bazel.build/versions/7.7.1/extending/rules#attributes) and [using](https://bazel.build/versions/7.7.1/extending/rules#implementation_function) attributes.
 
@@ -28,14 +28,14 @@ See the Rules page for more on [defining](https://bazel.build/versions/7.7.1/ext
 Attribute attr.bool(default=False, doc=None, mandatory=False)
 ```
 
-Creates a schema for a boolean attribute. The corresponding [`ctx.attr`](../builtins/ctx#attr) attribute will be of type [`bool`](../core/bool).
+Creates a schema for a boolean attribute. The corresponding [`ctx.attr`](/versions/7.7.1/rules/lib/builtins/ctx#attr) attribute will be of type [`bool`](/versions/7.7.1/rules/lib/core/bool).
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
 | `default` | default is `False`  A default value to use if no value for this attribute is given when instantiating the rule. |
-| `doc` | [string](../core/string); or `None`; default is `None`  A description of the attribute that can be extracted by documentation generating tools. |
+| `doc` | [string](/versions/7.7.1/rules/lib/core/string); or `None`; default is `None`  A description of the attribute that can be extracted by documentation generating tools. |
 | `mandatory` | default is `False`  If true, the value must be specified explicitly (even if it has a `default`). |
 
 ## int
@@ -44,16 +44,16 @@ Creates a schema for a boolean attribute. The corresponding [`ctx.attr`](../buil
 Attribute attr.int(default=0, doc=None, mandatory=False, values=[])
 ```
 
-Creates a schema for an integer attribute. The value must be in the signed 32-bit range. The corresponding [`ctx.attr`](../builtins/ctx#attr) attribute will be of type [`int`](../core/int).
+Creates a schema for an integer attribute. The value must be in the signed 32-bit range. The corresponding [`ctx.attr`](/versions/7.7.1/rules/lib/builtins/ctx#attr) attribute will be of type [`int`](/versions/7.7.1/rules/lib/core/int).
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
 | `default` | default is `0`  A default value to use if no value for this attribute is given when instantiating the rule. |
-| `doc` | [string](../core/string); or `None`; default is `None`  A description of the attribute that can be extracted by documentation generating tools. |
+| `doc` | [string](/versions/7.7.1/rules/lib/core/string); or `None`; default is `None`  A description of the attribute that can be extracted by documentation generating tools. |
 | `mandatory` | default is `False`  If true, the value must be specified explicitly (even if it has a `default`). |
-| `values` | [sequence](../core/list) of [int](../core/int)s; default is `[]`  The list of allowed values for the attribute. An error is raised if any other value is given. |
+| `values` | [sequence](/versions/7.7.1/rules/lib/core/list) of [int](/versions/7.7.1/rules/lib/core/int)s; default is `[]`  The list of allowed values for the attribute. An error is raised if any other value is given. |
 
 ## int\_list
 
@@ -69,8 +69,8 @@ Creates a schema for a list-of-integers attribute. Each element must be in the s
 | --- | --- |
 | `mandatory` | default is `False`  If true, the value must be specified explicitly (even if it has a `default`). |
 | `allow_empty` | default is `True`  True if the attribute can be empty. |
-| `default` | [sequence](../core/list) of [int](../core/int)s; default is `[]`  A default value to use if no value for this attribute is given when instantiating the rule. |
-| `doc` | [string](../core/string); or `None`; default is `None`  A description of the attribute that can be extracted by documentation generating tools. |
+| `default` | [sequence](/versions/7.7.1/rules/lib/core/list) of [int](/versions/7.7.1/rules/lib/core/int)s; default is `[]`  A default value to use if no value for this attribute is given when instantiating the rule. |
+| `doc` | [string](/versions/7.7.1/rules/lib/core/string); or `None`; default is `None`  A description of the attribute that can be extracted by documentation generating tools. |
 
 ## label
 
@@ -80,9 +80,9 @@ Attribute attr.label(default=None, doc=None, executable=False, allow_files=None,
 
 Creates a schema for a label attribute. This is a dependency attribute.
 
-This attribute contains unique [`Label`](../builtins/Label) values. If a string is supplied in place of a `Label`, it will be converted using the [label constructor](../builtins/Label#Label). The relative parts of the label path, including the (possibly renamed) repository, are resolved with respect to the instantiated target's package.
+This attribute contains unique [`Label`](/versions/7.7.1/rules/lib/builtins/Label) values. If a string is supplied in place of a `Label`, it will be converted using the [label constructor](/versions/7.7.1/rules/lib/builtins/Label#Label). The relative parts of the label path, including the (possibly renamed) repository, are resolved with respect to the instantiated target's package.
 
-At analysis time (within the rule's implementation function), when retrieving the attribute value from `ctx.attr`, labels are replaced by the corresponding [`Target`](../builtins/Target)s. This allows you to access the providers of the current target's dependencies.
+At analysis time (within the rule's implementation function), when retrieving the attribute value from `ctx.attr`, labels are replaced by the corresponding [`Target`](/versions/7.7.1/rules/lib/builtins/Target)s. This allows you to access the providers of the current target's dependencies.
 
 In addition to ordinary source files, this kind of attribute is often used to refer to a tool -- for example, a compiler. Such tools are considered to be dependencies, just like source files. To avoid requiring users to specify the tool's label every time they use the rule in their BUILD files, you can hard-code the label of a canonical tool as the `default` value of this attribute. If you also want to prevent users from overriding this default, you can make the attribute private by giving it a name that starts with an underscore. See the [Rules](https://bazel.build/versions/7.7.1/extending/rules#private-attributes) page for more information.
 
@@ -90,17 +90,17 @@ In addition to ordinary source files, this kind of attribute is often used to re
 
 | Parameter | Description |
 | --- | --- |
-| `default` | [Label](../builtins/Label); or [string](../core/string); or [LateBoundDefault](../builtins/LateBoundDefault); or NativeComputedDefault; or [function](../core/function); or `None`; default is `None`  A default value to use if no value for this attribute is given when instantiating the rule.Use a string or the [`Label`](../builtins/Label#Label) function to specify a default value, for example, `attr.label(default = "//a:b")`. |
-| `doc` | [string](../core/string); or `None`; default is `None`  A description of the attribute that can be extracted by documentation generating tools. |
+| `default` | [Label](/versions/7.7.1/rules/lib/builtins/Label); or [string](/versions/7.7.1/rules/lib/core/string); or [LateBoundDefault](/versions/7.7.1/rules/lib/builtins/LateBoundDefault); or NativeComputedDefault; or [function](/versions/7.7.1/rules/lib/core/function); or `None`; default is `None`  A default value to use if no value for this attribute is given when instantiating the rule.Use a string or the [`Label`](/versions/7.7.1/rules/lib/builtins/Label#Label) function to specify a default value, for example, `attr.label(default = "//a:b")`. |
+| `doc` | [string](/versions/7.7.1/rules/lib/core/string); or `None`; default is `None`  A description of the attribute that can be extracted by documentation generating tools. |
 | `executable` | default is `False`  True if the dependency has to be executable. This means the label must refer to an executable file, or to a rule that outputs an executable file. Access the label with `ctx.executable.`. |
-| `allow_files` | [bool](../core/bool); or [sequence](../core/list) of [string](../core/string)s; or `None`; default is `None`  Whether `File` targets are allowed. Can be `True`, `False` (default), or a list of file extensions that are allowed (for example, `[".cc", ".cpp"]`). |
-| `allow_single_file` | default is `None`  This is similar to `allow_files`, with the restriction that the label must correspond to a single [File](../builtins/File). Access it through `ctx.file.`. |
+| `allow_files` | [bool](/versions/7.7.1/rules/lib/core/bool); or [sequence](/versions/7.7.1/rules/lib/core/list) of [string](/versions/7.7.1/rules/lib/core/string)s; or `None`; default is `None`  Whether `File` targets are allowed. Can be `True`, `False` (default), or a list of file extensions that are allowed (for example, `[".cc", ".cpp"]`). |
+| `allow_single_file` | default is `None`  This is similar to `allow_files`, with the restriction that the label must correspond to a single [File](/versions/7.7.1/rules/lib/builtins/File). Access it through `ctx.file.`. |
 | `mandatory` | default is `False`  If true, the value must be specified explicitly (even if it has a `default`). |
-| `providers` | default is `[]`  The providers that must be given by any dependency appearing in this attribute. The format of this argument is a list of lists of providers -- `*Info` objects returned by [`provider()`](../globals/bzl#provider) (or in the case of a legacy provider, its string name). The dependency must return ALL providers mentioned in at least ONE of the inner lists. As a convenience, this argument may also be a single-level list of providers, in which case it is wrapped in an outer list with one element. It is NOT required that the rule of the dependency advertises those providers in its `provides` parameter, however, it is considered best practice. |
-| `allow_rules` | [sequence](../core/list) of [string](../core/string)s; or `None`; default is `None`  Which rule targets (name of the classes) are allowed. This is deprecated (kept only for compatibility), use providers instead. |
+| `providers` | default is `[]`  The providers that must be given by any dependency appearing in this attribute. The format of this argument is a list of lists of providers -- `*Info` objects returned by [`provider()`](/versions/7.7.1/rules/lib/globals/bzl#provider) (or in the case of a legacy provider, its string name). The dependency must return ALL providers mentioned in at least ONE of the inner lists. As a convenience, this argument may also be a single-level list of providers, in which case it is wrapped in an outer list with one element. It is NOT required that the rule of the dependency advertises those providers in its `provides` parameter, however, it is considered best practice. |
+| `allow_rules` | [sequence](/versions/7.7.1/rules/lib/core/list) of [string](/versions/7.7.1/rules/lib/core/string)s; or `None`; default is `None`  Which rule targets (name of the classes) are allowed. This is deprecated (kept only for compatibility), use providers instead. |
 | `cfg` | default is `None`  [Configuration](https://bazel.build/versions/7.7.1/extending/rules#configurations) of the attribute. It can be either `"exec"`, which indicates that the dependency is built for the `execution platform`, or `"target"`, which indicates that the dependency is build for the `target platform`. A typical example of the difference is when building mobile apps, where the `target platform` is `Android` or `iOS` while the `execution platform` is `Linux`, `macOS`, or `Windows`. This parameter is required if `executable` is True to guard against accidentally building host tools in the target configuration. `"target"` has no semantic effect, so don't set it when `executable` is False unless it really helps clarify your intentions. |
-| `aspects` | [sequence](../core/list) of [Aspect](../builtins/Aspect)s; default is `[]`  Aspects that should be applied to the dependency or dependencies specified by this attribute. |
-| `flags` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  Deprecated, will be removed. |
+| `aspects` | [sequence](/versions/7.7.1/rules/lib/core/list) of [Aspect](/versions/7.7.1/rules/lib/builtins/Aspect)s; default is `[]`  Aspects that should be applied to the dependency or dependencies specified by this attribute. |
+| `flags` | [sequence](/versions/7.7.1/rules/lib/core/list) of [string](/versions/7.7.1/rules/lib/core/string)s; default is `[]`  Deprecated, will be removed. |
 
 ## label\_keyed\_string\_dict
 
@@ -110,24 +110,24 @@ Attribute attr.label_keyed_string_dict(allow_empty=True, *, default={}, doc=None
 
 Creates a schema for an attribute holding a dictionary, where the keys are labels and the values are strings. This is a dependency attribute.
 
-This attribute contains unique [`Label`](../builtins/Label) values. If a string is supplied in place of a `Label`, it will be converted using the [label constructor](../builtins/Label#Label). The relative parts of the label path, including the (possibly renamed) repository, are resolved with respect to the instantiated target's package.
+This attribute contains unique [`Label`](/versions/7.7.1/rules/lib/builtins/Label) values. If a string is supplied in place of a `Label`, it will be converted using the [label constructor](/versions/7.7.1/rules/lib/builtins/Label#Label). The relative parts of the label path, including the (possibly renamed) repository, are resolved with respect to the instantiated target's package.
 
-At analysis time (within the rule's implementation function), when retrieving the attribute value from `ctx.attr`, labels are replaced by the corresponding [`Target`](../builtins/Target)s. This allows you to access the providers of the current target's dependencies.
+At analysis time (within the rule's implementation function), when retrieving the attribute value from `ctx.attr`, labels are replaced by the corresponding [`Target`](/versions/7.7.1/rules/lib/builtins/Target)s. This allows you to access the providers of the current target's dependencies.
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
 | `allow_empty` | default is `True`  True if the attribute can be empty. |
-| `default` | [dict](../core/dict); or [function](../core/function); default is `{}`  A default value to use if no value for this attribute is given when instantiating the rule.Use strings or the [`Label`](../builtins/Label#Label) function to specify default values, for example, `attr.label_keyed_string_dict(default = {"//a:b": "value", "//a:c": "string"})`. |
-| `doc` | [string](../core/string); or `None`; default is `None`  A description of the attribute that can be extracted by documentation generating tools. |
-| `allow_files` | [bool](../core/bool); or [sequence](../core/list) of [string](../core/string)s; or `None`; default is `None`  Whether `File` targets are allowed. Can be `True`, `False` (default), or a list of file extensions that are allowed (for example, `[".cc", ".cpp"]`). |
-| `allow_rules` | [sequence](../core/list) of [string](../core/string)s; or `None`; default is `None`  Which rule targets (name of the classes) are allowed. This is deprecated (kept only for compatibility), use providers instead. |
-| `providers` | default is `[]`  The providers that must be given by any dependency appearing in this attribute. The format of this argument is a list of lists of providers -- `*Info` objects returned by [`provider()`](../globals/bzl#provider) (or in the case of a legacy provider, its string name). The dependency must return ALL providers mentioned in at least ONE of the inner lists. As a convenience, this argument may also be a single-level list of providers, in which case it is wrapped in an outer list with one element. It is NOT required that the rule of the dependency advertises those providers in its `provides` parameter, however, it is considered best practice. |
-| `flags` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  Deprecated, will be removed. |
+| `default` | [dict](/versions/7.7.1/rules/lib/core/dict); or [function](/versions/7.7.1/rules/lib/core/function); default is `{}`  A default value to use if no value for this attribute is given when instantiating the rule.Use strings or the [`Label`](/versions/7.7.1/rules/lib/builtins/Label#Label) function to specify default values, for example, `attr.label_keyed_string_dict(default = {"//a:b": "value", "//a:c": "string"})`. |
+| `doc` | [string](/versions/7.7.1/rules/lib/core/string); or `None`; default is `None`  A description of the attribute that can be extracted by documentation generating tools. |
+| `allow_files` | [bool](/versions/7.7.1/rules/lib/core/bool); or [sequence](/versions/7.7.1/rules/lib/core/list) of [string](/versions/7.7.1/rules/lib/core/string)s; or `None`; default is `None`  Whether `File` targets are allowed. Can be `True`, `False` (default), or a list of file extensions that are allowed (for example, `[".cc", ".cpp"]`). |
+| `allow_rules` | [sequence](/versions/7.7.1/rules/lib/core/list) of [string](/versions/7.7.1/rules/lib/core/string)s; or `None`; default is `None`  Which rule targets (name of the classes) are allowed. This is deprecated (kept only for compatibility), use providers instead. |
+| `providers` | default is `[]`  The providers that must be given by any dependency appearing in this attribute. The format of this argument is a list of lists of providers -- `*Info` objects returned by [`provider()`](/versions/7.7.1/rules/lib/globals/bzl#provider) (or in the case of a legacy provider, its string name). The dependency must return ALL providers mentioned in at least ONE of the inner lists. As a convenience, this argument may also be a single-level list of providers, in which case it is wrapped in an outer list with one element. It is NOT required that the rule of the dependency advertises those providers in its `provides` parameter, however, it is considered best practice. |
+| `flags` | [sequence](/versions/7.7.1/rules/lib/core/list) of [string](/versions/7.7.1/rules/lib/core/string)s; default is `[]`  Deprecated, will be removed. |
 | `mandatory` | default is `False`  If true, the value must be specified explicitly (even if it has a `default`). |
 | `cfg` | default is `None`  [Configuration](https://bazel.build/versions/7.7.1/extending/rules#configurations) of the attribute. It can be either `"exec"`, which indicates that the dependency is built for the `execution platform`, or `"target"`, which indicates that the dependency is build for the `target platform`. A typical example of the difference is when building mobile apps, where the `target platform` is `Android` or `iOS` while the `execution platform` is `Linux`, `macOS`, or `Windows`. |
-| `aspects` | [sequence](../core/list) of [Aspect](../builtins/Aspect)s; default is `[]`  Aspects that should be applied to the dependency or dependencies specified by this attribute. |
+| `aspects` | [sequence](/versions/7.7.1/rules/lib/core/list) of [Aspect](/versions/7.7.1/rules/lib/builtins/Aspect)s; default is `[]`  Aspects that should be applied to the dependency or dependencies specified by this attribute. |
 
 ## label\_list
 
@@ -135,26 +135,26 @@ At analysis time (within the rule's implementation function), when retrieving th
 Attribute attr.label_list(allow_empty=True, *, default=[], doc=None, allow_files=None, allow_rules=None, providers=[], flags=[], mandatory=False, cfg=None, aspects=[])
 ```
 
-Creates a schema for a list-of-labels attribute. This is a dependency attribute. The corresponding [`ctx.attr`](../builtins/ctx#attr) attribute will be of type [list](../core/list) of [`Target`s](../builtins/Target).
+Creates a schema for a list-of-labels attribute. This is a dependency attribute. The corresponding [`ctx.attr`](/versions/7.7.1/rules/lib/builtins/ctx#attr) attribute will be of type [list](/versions/7.7.1/rules/lib/core/list) of [`Target`s](/versions/7.7.1/rules/lib/builtins/Target).
 
-This attribute contains unique [`Label`](../builtins/Label) values. If a string is supplied in place of a `Label`, it will be converted using the [label constructor](../builtins/Label#Label). The relative parts of the label path, including the (possibly renamed) repository, are resolved with respect to the instantiated target's package.
+This attribute contains unique [`Label`](/versions/7.7.1/rules/lib/builtins/Label) values. If a string is supplied in place of a `Label`, it will be converted using the [label constructor](/versions/7.7.1/rules/lib/builtins/Label#Label). The relative parts of the label path, including the (possibly renamed) repository, are resolved with respect to the instantiated target's package.
 
-At analysis time (within the rule's implementation function), when retrieving the attribute value from `ctx.attr`, labels are replaced by the corresponding [`Target`](../builtins/Target)s. This allows you to access the providers of the current target's dependencies.
+At analysis time (within the rule's implementation function), when retrieving the attribute value from `ctx.attr`, labels are replaced by the corresponding [`Target`](/versions/7.7.1/rules/lib/builtins/Target)s. This allows you to access the providers of the current target's dependencies.
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
 | `allow_empty` | default is `True`  True if the attribute can be empty. |
-| `default` | [sequence](../core/list) of [Label](../builtins/Label)s; or [function](../core/function); default is `[]`  A default value to use if no value for this attribute is given when instantiating the rule.Use strings or the [`Label`](../builtins/Label#Label) function to specify default values, for example, `attr.label_list(default = ["//a:b", "//a:c"])`. |
-| `doc` | [string](../core/string); or `None`; default is `None`  A description of the attribute that can be extracted by documentation generating tools. |
-| `allow_files` | [bool](../core/bool); or [sequence](../core/list) of [string](../core/string)s; or `None`; default is `None`  Whether `File` targets are allowed. Can be `True`, `False` (default), or a list of file extensions that are allowed (for example, `[".cc", ".cpp"]`). |
-| `allow_rules` | [sequence](../core/list) of [string](../core/string)s; or `None`; default is `None`  Which rule targets (name of the classes) are allowed. This is deprecated (kept only for compatibility), use providers instead. |
-| `providers` | default is `[]`  The providers that must be given by any dependency appearing in this attribute. The format of this argument is a list of lists of providers -- `*Info` objects returned by [`provider()`](../globals/bzl#provider) (or in the case of a legacy provider, its string name). The dependency must return ALL providers mentioned in at least ONE of the inner lists. As a convenience, this argument may also be a single-level list of providers, in which case it is wrapped in an outer list with one element. It is NOT required that the rule of the dependency advertises those providers in its `provides` parameter, however, it is considered best practice. |
-| `flags` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  Deprecated, will be removed. |
+| `default` | [sequence](/versions/7.7.1/rules/lib/core/list) of [Label](/versions/7.7.1/rules/lib/builtins/Label)s; or [function](/versions/7.7.1/rules/lib/core/function); default is `[]`  A default value to use if no value for this attribute is given when instantiating the rule.Use strings or the [`Label`](/versions/7.7.1/rules/lib/builtins/Label#Label) function to specify default values, for example, `attr.label_list(default = ["//a:b", "//a:c"])`. |
+| `doc` | [string](/versions/7.7.1/rules/lib/core/string); or `None`; default is `None`  A description of the attribute that can be extracted by documentation generating tools. |
+| `allow_files` | [bool](/versions/7.7.1/rules/lib/core/bool); or [sequence](/versions/7.7.1/rules/lib/core/list) of [string](/versions/7.7.1/rules/lib/core/string)s; or `None`; default is `None`  Whether `File` targets are allowed. Can be `True`, `False` (default), or a list of file extensions that are allowed (for example, `[".cc", ".cpp"]`). |
+| `allow_rules` | [sequence](/versions/7.7.1/rules/lib/core/list) of [string](/versions/7.7.1/rules/lib/core/string)s; or `None`; default is `None`  Which rule targets (name of the classes) are allowed. This is deprecated (kept only for compatibility), use providers instead. |
+| `providers` | default is `[]`  The providers that must be given by any dependency appearing in this attribute. The format of this argument is a list of lists of providers -- `*Info` objects returned by [`provider()`](/versions/7.7.1/rules/lib/globals/bzl#provider) (or in the case of a legacy provider, its string name). The dependency must return ALL providers mentioned in at least ONE of the inner lists. As a convenience, this argument may also be a single-level list of providers, in which case it is wrapped in an outer list with one element. It is NOT required that the rule of the dependency advertises those providers in its `provides` parameter, however, it is considered best practice. |
+| `flags` | [sequence](/versions/7.7.1/rules/lib/core/list) of [string](/versions/7.7.1/rules/lib/core/string)s; default is `[]`  Deprecated, will be removed. |
 | `mandatory` | default is `False`  If true, the value must be specified explicitly (even if it has a `default`). |
 | `cfg` | default is `None`  [Configuration](https://bazel.build/versions/7.7.1/extending/rules#configurations) of the attribute. It can be either `"exec"`, which indicates that the dependency is built for the `execution platform`, or `"target"`, which indicates that the dependency is build for the `target platform`. A typical example of the difference is when building mobile apps, where the `target platform` is `Android` or `iOS` while the `execution platform` is `Linux`, `macOS`, or `Windows`. |
-| `aspects` | [sequence](../core/list) of [Aspect](../builtins/Aspect)s; default is `[]`  Aspects that should be applied to the dependency or dependencies specified by this attribute. |
+| `aspects` | [sequence](/versions/7.7.1/rules/lib/core/list) of [Aspect](/versions/7.7.1/rules/lib/builtins/Aspect)s; default is `[]`  Aspects that should be applied to the dependency or dependencies specified by this attribute. |
 
 ## output
 
@@ -164,15 +164,15 @@ Attribute attr.output(doc=None, mandatory=False)
 
 Creates a schema for an output (label) attribute.
 
-This attribute contains unique [`Label`](../builtins/Label) values. If a string is supplied in place of a `Label`, it will be converted using the [label constructor](../builtins/Label#Label). The relative parts of the label path, including the (possibly renamed) repository, are resolved with respect to the instantiated target's package.
+This attribute contains unique [`Label`](/versions/7.7.1/rules/lib/builtins/Label) values. If a string is supplied in place of a `Label`, it will be converted using the [label constructor](/versions/7.7.1/rules/lib/builtins/Label#Label). The relative parts of the label path, including the (possibly renamed) repository, are resolved with respect to the instantiated target's package.
 
-At analysis time, the corresponding [`File`](../builtins/File) can be retrieved using [`ctx.outputs`](../builtins/ctx#outputs).
+At analysis time, the corresponding [`File`](/versions/7.7.1/rules/lib/builtins/File) can be retrieved using [`ctx.outputs`](/versions/7.7.1/rules/lib/builtins/ctx#outputs).
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `doc` | [string](../core/string); or `None`; default is `None`  A description of the attribute that can be extracted by documentation generating tools. |
+| `doc` | [string](/versions/7.7.1/rules/lib/core/string); or `None`; default is `None`  A description of the attribute that can be extracted by documentation generating tools. |
 | `mandatory` | default is `False`  If true, the value must be specified explicitly (even if it has a `default`). |
 
 ## output\_list
@@ -183,16 +183,16 @@ Attribute attr.output_list(allow_empty=True, *, doc=None, mandatory=False)
 
 Creates a schema for a list-of-outputs attribute.
 
-This attribute contains unique [`Label`](../builtins/Label) values. If a string is supplied in place of a `Label`, it will be converted using the [label constructor](../builtins/Label#Label). The relative parts of the label path, including the (possibly renamed) repository, are resolved with respect to the instantiated target's package.
+This attribute contains unique [`Label`](/versions/7.7.1/rules/lib/builtins/Label) values. If a string is supplied in place of a `Label`, it will be converted using the [label constructor](/versions/7.7.1/rules/lib/builtins/Label#Label). The relative parts of the label path, including the (possibly renamed) repository, are resolved with respect to the instantiated target's package.
 
-At analysis time, the corresponding [`File`](../builtins/File) can be retrieved using [`ctx.outputs`](../builtins/ctx#outputs).
+At analysis time, the corresponding [`File`](/versions/7.7.1/rules/lib/builtins/File) can be retrieved using [`ctx.outputs`](/versions/7.7.1/rules/lib/builtins/ctx#outputs).
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
 | `allow_empty` | default is `True`  True if the attribute can be empty. |
-| `doc` | [string](../core/string); or `None`; default is `None`  A description of the attribute that can be extracted by documentation generating tools. |
+| `doc` | [string](/versions/7.7.1/rules/lib/core/string); or `None`; default is `None`  A description of the attribute that can be extracted by documentation generating tools. |
 | `mandatory` | default is `False`  If true, the value must be specified explicitly (even if it has a `default`). |
 
 ## string
@@ -201,16 +201,16 @@ At analysis time, the corresponding [`File`](../builtins/File) can be retrieved
 Attribute attr.string(default='', doc=None, mandatory=False, values=[])
 ```
 
-Creates a schema for a [string](../core/string#attr) attribute.
+Creates a schema for a [string](/versions/7.7.1/rules/lib/core/string#attr) attribute.
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `default` | [string](../core/string); or NativeComputedDefault; default is `''`  A default value to use if no value for this attribute is given when instantiating the rule. |
-| `doc` | [string](../core/string); or `None`; default is `None`  A description of the attribute that can be extracted by documentation generating tools. |
+| `default` | [string](/versions/7.7.1/rules/lib/core/string); or NativeComputedDefault; default is `''`  A default value to use if no value for this attribute is given when instantiating the rule. |
+| `doc` | [string](/versions/7.7.1/rules/lib/core/string); or `None`; default is `None`  A description of the attribute that can be extracted by documentation generating tools. |
 | `mandatory` | default is `False`  If true, the value must be specified explicitly (even if it has a `default`). |
-| `values` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  The list of allowed values for the attribute. An error is raised if any other value is given. |
+| `values` | [sequence](/versions/7.7.1/rules/lib/core/list) of [string](/versions/7.7.1/rules/lib/core/string)s; default is `[]`  The list of allowed values for the attribute. An error is raised if any other value is given. |
 
 ## string\_dict
 
@@ -226,7 +226,7 @@ Creates a schema for an attribute holding a dictionary, where the keys and value
 | --- | --- |
 | `allow_empty` | default is `True`  True if the attribute can be empty. |
 | `default` | default is `{}`  A default value to use if no value for this attribute is given when instantiating the rule. |
-| `doc` | [string](../core/string); or `None`; default is `None`  A description of the attribute that can be extracted by documentation generating tools. |
+| `doc` | [string](/versions/7.7.1/rules/lib/core/string); or `None`; default is `None`  A description of the attribute that can be extracted by documentation generating tools. |
 | `mandatory` | default is `False`  If true, the value must be specified explicitly (even if it has a `default`). |
 
 ## string\_keyed\_label\_dict
@@ -237,24 +237,24 @@ Attribute attr.string_keyed_label_dict(allow_empty=True, *, default={}, doc=None
 
 Creates a schema for an attribute whose value is a dictionary where the keys are strings and the values are labels. This is a dependency attribute.
 
-This attribute contains unique [`Label`](../builtins/Label) values. If a string is supplied in place of a `Label`, it will be converted using the [label constructor](../builtins/Label#Label). The relative parts of the label path, including the (possibly renamed) repository, are resolved with respect to the instantiated target's package.
+This attribute contains unique [`Label`](/versions/7.7.1/rules/lib/builtins/Label) values. If a string is supplied in place of a `Label`, it will be converted using the [label constructor](/versions/7.7.1/rules/lib/builtins/Label#Label). The relative parts of the label path, including the (possibly renamed) repository, are resolved with respect to the instantiated target's package.
 
-At analysis time (within the rule's implementation function), when retrieving the attribute value from `ctx.attr`, labels are replaced by the corresponding [`Target`](../builtins/Target)s. This allows you to access the providers of the current target's dependencies.
+At analysis time (within the rule's implementation function), when retrieving the attribute value from `ctx.attr`, labels are replaced by the corresponding [`Target`](/versions/7.7.1/rules/lib/builtins/Target)s. This allows you to access the providers of the current target's dependencies.
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
 | `allow_empty` | default is `True`  True if the attribute can be empty. |
-| `default` | [dict](../core/dict); or [function](../core/function); default is `{}`  A default value to use if no value for this attribute is given when instantiating the rule.Use strings or the [`Label`](../builtins/Label#Label) function to specify default values, for example, `attr.string_keyed_label_dict(default = {"foo": "//a:b", "bar": "//a:c"})`. |
-| `doc` | [string](../core/string); or `None`; default is `None`  A description of the attribute that can be extracted by documentation generating tools. |
-| `allow_files` | [bool](../core/bool); or [sequence](../core/list) of [string](../core/string)s; or `None`; default is `None`  Whether `File` targets are allowed. Can be `True`, `False` (default), or a list of file extensions that are allowed (for example, `[".cc", ".cpp"]`). |
-| `allow_rules` | [sequence](../core/list) of [string](../core/string)s; or `None`; default is `None`  Which rule targets (name of the classes) are allowed. This is deprecated (kept only for compatibility), use providers instead. |
-| `providers` | default is `[]`  The providers that must be given by any dependency appearing in this attribute. The format of this argument is a list of lists of providers -- `*Info` objects returned by [`provider()`](../globals/bzl#provider) (or in the case of a legacy provider, its string name). The dependency must return ALL providers mentioned in at least ONE of the inner lists. As a convenience, this argument may also be a single-level list of providers, in which case it is wrapped in an outer list with one element. It is NOT required that the rule of the dependency advertises those providers in its `provides` parameter, however, it is considered best practice. |
-| `flags` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  Deprecated, will be removed. |
+| `default` | [dict](/versions/7.7.1/rules/lib/core/dict); or [function](/versions/7.7.1/rules/lib/core/function); default is `{}`  A default value to use if no value for this attribute is given when instantiating the rule.Use strings or the [`Label`](/versions/7.7.1/rules/lib/builtins/Label#Label) function to specify default values, for example, `attr.string_keyed_label_dict(default = {"foo": "//a:b", "bar": "//a:c"})`. |
+| `doc` | [string](/versions/7.7.1/rules/lib/core/string); or `None`; default is `None`  A description of the attribute that can be extracted by documentation generating tools. |
+| `allow_files` | [bool](/versions/7.7.1/rules/lib/core/bool); or [sequence](/versions/7.7.1/rules/lib/core/list) of [string](/versions/7.7.1/rules/lib/core/string)s; or `None`; default is `None`  Whether `File` targets are allowed. Can be `True`, `False` (default), or a list of file extensions that are allowed (for example, `[".cc", ".cpp"]`). |
+| `allow_rules` | [sequence](/versions/7.7.1/rules/lib/core/list) of [string](/versions/7.7.1/rules/lib/core/string)s; or `None`; default is `None`  Which rule targets (name of the classes) are allowed. This is deprecated (kept only for compatibility), use providers instead. |
+| `providers` | default is `[]`  The providers that must be given by any dependency appearing in this attribute. The format of this argument is a list of lists of providers -- `*Info` objects returned by [`provider()`](/versions/7.7.1/rules/lib/globals/bzl#provider) (or in the case of a legacy provider, its string name). The dependency must return ALL providers mentioned in at least ONE of the inner lists. As a convenience, this argument may also be a single-level list of providers, in which case it is wrapped in an outer list with one element. It is NOT required that the rule of the dependency advertises those providers in its `provides` parameter, however, it is considered best practice. |
+| `flags` | [sequence](/versions/7.7.1/rules/lib/core/list) of [string](/versions/7.7.1/rules/lib/core/string)s; default is `[]`  Deprecated, will be removed. |
 | `mandatory` | default is `False`  If true, the value must be specified explicitly (even if it has a `default`). |
 | `cfg` | default is `None`  [Configuration](https://bazel.build/versions/7.7.1/extending/rules#configurations) of the attribute. It can be either `"exec"`, which indicates that the dependency is built for the `execution platform`, or `"target"`, which indicates that the dependency is build for the `target platform`. A typical example of the difference is when building mobile apps, where the `target platform` is `Android` or `iOS` while the `execution platform` is `Linux`, `macOS`, or `Windows`. |
-| `aspects` | [sequence](../core/list) of [Aspect](../builtins/Aspect)s; default is `[]`  Aspects that should be applied to the dependency or dependencies specified by this attribute. |
+| `aspects` | [sequence](/versions/7.7.1/rules/lib/core/list) of [Aspect](/versions/7.7.1/rules/lib/builtins/Aspect)s; default is `[]`  Aspects that should be applied to the dependency or dependencies specified by this attribute. |
 
 ## string\_list
 
@@ -270,8 +270,8 @@ Creates a schema for a list-of-strings attribute.
 | --- | --- |
 | `mandatory` | default is `False`  If true, the value must be specified explicitly (even if it has a `default`). |
 | `allow_empty` | default is `True`  True if the attribute can be empty. |
-| `default` | [sequence](../core/list) of [string](../core/string)s; or NativeComputedDefault; default is `[]`  A default value to use if no value for this attribute is given when instantiating the rule. |
-| `doc` | [string](../core/string); or `None`; default is `None`  A description of the attribute that can be extracted by documentation generating tools. |
+| `default` | [sequence](/versions/7.7.1/rules/lib/core/list) of [string](/versions/7.7.1/rules/lib/core/string)s; or NativeComputedDefault; default is `[]`  A default value to use if no value for this attribute is given when instantiating the rule. |
+| `doc` | [string](/versions/7.7.1/rules/lib/core/string); or `None`; default is `None`  A description of the attribute that can be extracted by documentation generating tools. |
 
 ## string\_list\_dict
 
@@ -287,5 +287,5 @@ Creates a schema for an attribute holding a dictionary, where the keys are strin
 | --- | --- |
 | `allow_empty` | default is `True`  True if the attribute can be empty. |
 | `default` | default is `{}`  A default value to use if no value for this attribute is given when instantiating the rule. |
-| `doc` | [string](../core/string); or `None`; default is `None`  A description of the attribute that can be extracted by documentation generating tools. |
+| `doc` | [string](/versions/7.7.1/rules/lib/core/string); or `None`; default is `None`  A description of the attribute that can be extracted by documentation generating tools. |
 | `mandatory` | default is `False`  If true, the value must be specified explicitly (even if it has a `default`). |
\ No newline at end of file
diff --git a/versions/7.7.1/rules/lib/toplevel/cc_common.mdx b/versions/7.7.1/rules/lib/toplevel/cc_common.mdx
index f572700e..2ac7489b 100644
--- a/versions/7.7.1/rules/lib/toplevel/cc_common.mdx
+++ b/versions/7.7.1/rules/lib/toplevel/cc_common.mdx
@@ -70,7 +70,7 @@ Should be used for C++ compilation. Returns tuple of (`CompilationContext`, `CcC
 | `srcs` | default is `[]`  The list of source files to be compiled. |
 | `public_hdrs` | default is `[]`  List of headers needed for compilation of srcs and may be included by dependent rules transitively. |
 | `private_hdrs` | default is `[]`  List of headers needed for compilation of srcs and NOT to be included by dependent rules. |
-| `includes` | [sequence](../core/list); or [depset](../builtins/depset); default is `[]`  Search paths for header files referenced both by angle bracket and quotes. Usually passed with -I. Propagated to dependents transitively. |
+| `includes` | [sequence](/versions/7.7.1/rules/lib/core/list); or [depset](/versions/7.7.1/rules/lib/builtins/depset); default is `[]`  Search paths for header files referenced both by angle bracket and quotes. Usually passed with -I. Propagated to dependents transitively. |
 | `quote_includes` | default is `[]`  Search paths for header files referenced by quotes, e.g. #include "foo/bar/header.h". They can be either relative to the exec root or absolute. Usually passed with -iquote. Propagated to dependents transitively. |
 | `system_includes` | default is `[]`  Search paths for header files referenced by angle brackets, e.g. #include <foo/bar/header.h>. They can be either relative to the exec root or absolute. Usually passed with -isystem. Propagated to dependents transitively. |
 | `framework_includes` | default is `[]`  Search paths for header files from Apple frameworks. They can be either relative to the exec root or absolute. Usually passed with -F. Propagated to dependents transitively. |
@@ -99,9 +99,9 @@ Creates a feature\_configuration instance. Requires the cpp configuration fragme
 
 | Parameter | Description |
 | --- | --- |
-| `ctx` | [ctx](../builtins/ctx); or `None`; default is `None`  The rule context. |
+| `ctx` | [ctx](/versions/7.7.1/rules/lib/builtins/ctx); or `None`; default is `None`  The rule context. |
 | `cc_toolchain` | required  cc\_toolchain for which we configure features. |
-| `language` | [string](../core/string); or `None`; default is `None`  The language to configure for: either c++ or objc (default c++) |
+| `language` | [string](/versions/7.7.1/rules/lib/core/string); or `None`; default is `None`  The language to configure for: either c++ or objc (default c++) |
 | `requested_features` | default is `[]`  List of features to be enabled. |
 | `unsupported_features` | default is `[]`  List of features that are unsupported by the current rule. |
 
@@ -123,17 +123,17 @@ Creates a `CcToolchainConfigInfo` provider
 | `artifact_name_patterns` | default is `[]`  The name for an artifact of a given category of input or output artifacts to an action. Arguments:  `category_name`: The category of artifacts that this selection applies to. This field is compared against a list of categories defined in Bazel. Example categories include "linked\_output" or the artifact for this selection. Together with the extension it is used to create an artifact name based on the target name.  `extension`: The extension for creating the artifact for this selection. Together with the prefix it is used to create an artifact name based on the target name. |
 | `cxx_builtin_include_directories` | default is `[]`  Built-in include directories for C++ compilation. These should be the exact paths used by the compiler, and are generally relative to the exec root.  The paths used by the compiler can be determined by 'gcc -E -xc++ - -v'.  We currently use the C++ paths also for C compilation, which is safe as long as there are no name clashes between C++ and C header files.  Relative paths are resolved relative to the configuration file directory.  If the compiler has --sysroot support, then these paths should use %sysroot% rather than the include path, and specify the sysroot attribute in order to give blaze the information necessary to make the correct replacements. |
 | `toolchain_identifier` | required  The unique identifier of the toolchain within the crosstool release. It must be possible to use this as a directory name in a path.  It has to match the following regex: [a-zA-Z\_][\.\- \w]\* |
-| `host_system_name` | [string](../core/string); or `None`; default is `None`  Ignored. |
+| `host_system_name` | [string](/versions/7.7.1/rules/lib/core/string); or `None`; default is `None`  Ignored. |
 | `target_system_name` | required  The GNU System Name. |
 | `target_cpu` | required  The target architecture string. |
 | `target_libc` | required  The libc version string (e.g. "glibc-2.2.2"). |
 | `compiler` | required  The compiler version string (e.g. "gcc-4.1.1"). |
-| `abi_version` | [string](../core/string); or `None`; default is `None`  The abi in use, which is a gcc version. E.g.: "gcc-3.4" |
-| `abi_libc_version` | [string](../core/string); or `None`; default is `None`  The glibc version used by the abi we're using. |
+| `abi_version` | [string](/versions/7.7.1/rules/lib/core/string); or `None`; default is `None`  The abi in use, which is a gcc version. E.g.: "gcc-3.4" |
+| `abi_libc_version` | [string](/versions/7.7.1/rules/lib/core/string); or `None`; default is `None`  The glibc version used by the abi we're using. |
 | `tool_paths` | default is `[]`  Tool locations. Arguments:  `name`: Name of the tool.  `path`: Location of the tool; Can be absolute path (in case of non hermetic toolchain), or path relative to the cc\_toolchain's package. |
 | `make_variables` | default is `[]`  A make variable that is made accessible to rules. |
-| `builtin_sysroot` | [string](../core/string); or `None`; default is `None`  The built-in sysroot. If this attribute is not present, Bazel does not allow using a different sysroot, i.e. through the --grte\_top option. |
-| `cc_target_os` | [string](../core/string); or `None`; default is `None`  Internal purpose only, do not use. |
+| `builtin_sysroot` | [string](/versions/7.7.1/rules/lib/core/string); or `None`; default is `None`  The built-in sysroot. If this attribute is not present, Bazel does not allow using a different sysroot, i.e. through the --grte\_top option. |
+| `cc_target_os` | [string](/versions/7.7.1/rules/lib/core/string); or `None`; default is `None`  Internal purpose only, do not use. |
 
 ## create\_compilation\_context
 
@@ -167,8 +167,8 @@ Create compilation outputs object.
 
 | Parameter | Description |
 | --- | --- |
-| `objects` | [depset](../builtins/depset); or `None`; default is `None`  List of object files. |
-| `pic_objects` | [depset](../builtins/depset); or `None`; default is `None`  List of pic object files. |
+| `objects` | [depset](/versions/7.7.1/rules/lib/builtins/depset); or `None`; default is `None`  List of object files. |
+| `pic_objects` | [depset](/versions/7.7.1/rules/lib/builtins/depset); or `None`; default is `None`  List of pic object files. |
 
 ## create\_compile\_variables
 
@@ -186,18 +186,18 @@ Returns variables used for compilation actions.
 | `feature_configuration` | required  Feature configuration to be queried. |
 | `source_file` | default is `None`  Optional source file for the compilation. Please prefer passing source\_file here over appending it to the end of the command line generated from cc\_common.get\_memory\_inefficient\_command\_line, as then it's in the power of the toolchain author to properly specify and position compiler flags. |
 | `output_file` | default is `None`  Optional output file of the compilation. Please prefer passing output\_file here over appending it to the end of the command line generated from cc\_common.get\_memory\_inefficient\_command\_line, as then it's in the power of the toolchain author to properly specify and position compiler flags. |
-| `user_compile_flags` | [sequence](../core/list) of [string](../core/string)s; or `None`; default is `None`  List of additional compilation flags (copts). |
-| `include_directories` | [depset](../builtins/depset); or `None`; default is `None`  Depset of include directories. |
-| `quote_include_directories` | [depset](../builtins/depset); or `None`; default is `None`  Depset of quote include directories. |
-| `system_include_directories` | [depset](../builtins/depset); or `None`; default is `None`  Depset of system include directories. |
-| `framework_include_directories` | [depset](../builtins/depset); or `None`; default is `None`  Depset of framework include directories. |
-| `preprocessor_defines` | [depset](../builtins/depset); or `None`; default is `None`  Depset of preprocessor defines. |
-| `thinlto_index` | [string](../core/string); or `None`; default is `None`  LTO index file path. |
-| `thinlto_input_bitcode_file` | [string](../core/string); or `None`; default is `None`  Bitcode file that is input to LTO backend. |
-| `thinlto_output_object_file` | [string](../core/string); or `None`; default is `None`  Object file that is output by LTO backend. |
+| `user_compile_flags` | [sequence](/versions/7.7.1/rules/lib/core/list) of [string](/versions/7.7.1/rules/lib/core/string)s; or `None`; default is `None`  List of additional compilation flags (copts). |
+| `include_directories` | [depset](/versions/7.7.1/rules/lib/builtins/depset); or `None`; default is `None`  Depset of include directories. |
+| `quote_include_directories` | [depset](/versions/7.7.1/rules/lib/builtins/depset); or `None`; default is `None`  Depset of quote include directories. |
+| `system_include_directories` | [depset](/versions/7.7.1/rules/lib/builtins/depset); or `None`; default is `None`  Depset of system include directories. |
+| `framework_include_directories` | [depset](/versions/7.7.1/rules/lib/builtins/depset); or `None`; default is `None`  Depset of framework include directories. |
+| `preprocessor_defines` | [depset](/versions/7.7.1/rules/lib/builtins/depset); or `None`; default is `None`  Depset of preprocessor defines. |
+| `thinlto_index` | [string](/versions/7.7.1/rules/lib/core/string); or `None`; default is `None`  LTO index file path. |
+| `thinlto_input_bitcode_file` | [string](/versions/7.7.1/rules/lib/core/string); or `None`; default is `None`  Bitcode file that is input to LTO backend. |
+| `thinlto_output_object_file` | [string](/versions/7.7.1/rules/lib/core/string); or `None`; default is `None`  Object file that is output by LTO backend. |
 | `use_pic` | default is `False`  When true the compilation will generate position independent code. |
 | `add_legacy_cxx_options` | default is `False`  Unused. |
-| `variables_extension` | [dict](../core/dict); default is `unbound`  A dictionary of additional variables used by compile actions. |
+| `variables_extension` | [dict](/versions/7.7.1/rules/lib/core/dict); default is `unbound`  A dictionary of additional variables used by compile actions. |
 
 ## create\_library\_to\_link
 
@@ -214,14 +214,14 @@ Creates `LibraryToLink`
 | `actions` | required  `actions` object. |
 | `feature_configuration` | default is `None`  `feature_configuration` to be queried. |
 | `cc_toolchain` | default is `None`  `CcToolchainInfo` provider to be used. |
-| `static_library` | [File](../builtins/File); or `None`; default is `None`  `File` of static library to be linked. |
-| `pic_static_library` | [File](../builtins/File); or `None`; default is `None`  `File` of pic static library to be linked. |
-| `dynamic_library` | [File](../builtins/File); or `None`; default is `None`  `File` of dynamic library to be linked. Always used for runtime and used for linking if `interface_library` is not passed. |
-| `interface_library` | [File](../builtins/File); or `None`; default is `None`  `File` of interface library to be linked. |
-| `pic_objects` | [sequence](../core/list) of [File](../builtins/File)s; default is `unbound`  Experimental, do not use |
-| `objects` | [sequence](../core/list) of [File](../builtins/File)s; default is `unbound`  Experimental, do not use |
+| `static_library` | [File](/versions/7.7.1/rules/lib/builtins/File); or `None`; default is `None`  `File` of static library to be linked. |
+| `pic_static_library` | [File](/versions/7.7.1/rules/lib/builtins/File); or `None`; default is `None`  `File` of pic static library to be linked. |
+| `dynamic_library` | [File](/versions/7.7.1/rules/lib/builtins/File); or `None`; default is `None`  `File` of dynamic library to be linked. Always used for runtime and used for linking if `interface_library` is not passed. |
+| `interface_library` | [File](/versions/7.7.1/rules/lib/builtins/File); or `None`; default is `None`  `File` of interface library to be linked. |
+| `pic_objects` | [sequence](/versions/7.7.1/rules/lib/core/list) of [File](/versions/7.7.1/rules/lib/builtins/File)s; default is `unbound`  Experimental, do not use |
+| `objects` | [sequence](/versions/7.7.1/rules/lib/core/list) of [File](/versions/7.7.1/rules/lib/builtins/File)s; default is `unbound`  Experimental, do not use |
 | `alwayslink` | default is `False`  Whether to link the static library/objects in the --whole\_archive block. |
-| `dynamic_library_symlink_path` | [string](../core/string); default is `''`  Override the default path of the dynamic library link in the solib directory. Empty string to use the default. |
+| `dynamic_library_symlink_path` | [string](/versions/7.7.1/rules/lib/core/string); default is `''`  Override the default path of the dynamic library link in the solib directory. Empty string to use the default. |
 | `interface_library_symlink_path` | default is `''`  Override the default path of the interface library link in the solib directory. Empty string to use the default. |
 
 ## create\_link\_variables
@@ -238,9 +238,9 @@ Returns link variables used for linking actions.
 | --- | --- |
 | `cc_toolchain` | required  cc\_toolchain for which we are creating build variables. |
 | `feature_configuration` | required  Feature configuration to be queried. |
-| `library_search_directories` | `None`; or [depset](../builtins/depset); default is `None`  Depset of directories where linker will look for libraries at link time. |
-| `runtime_library_search_directories` | `None`; or [depset](../builtins/depset); default is `None`  Depset of directories where loader will look for libraries at runtime. |
-| `user_link_flags` | `None`; or [sequence](../core/list); default is `None`  List of additional link flags (linkopts). |
+| `library_search_directories` | `None`; or [depset](/versions/7.7.1/rules/lib/builtins/depset); default is `None`  Depset of directories where linker will look for libraries at link time. |
+| `runtime_library_search_directories` | `None`; or [depset](/versions/7.7.1/rules/lib/builtins/depset); default is `None`  Depset of directories where loader will look for libraries at runtime. |
+| `user_link_flags` | `None`; or [sequence](/versions/7.7.1/rules/lib/core/list); default is `None`  List of additional link flags (linkopts). |
 | `output_file` | default is `None`  Optional output file path. |
 | `param_file` | default is `None`  Optional param file path. |
 | `def_file` | default is `None`  Optional .def file path. |
@@ -263,9 +263,9 @@ Creates a `LinkerInput`.
 | Parameter | Description |
 | --- | --- |
 | `owner` | required  The label of the target that produced all files used in this input. |
-| `libraries` | `None`; or [depset](../builtins/depset); default is `None`  List of `LibraryToLink`. |
-| `user_link_flags` | `None`; or [depset](../builtins/depset) of [string](../core/string)s; or [sequence](../core/list) of [string](../core/string)s; default is `None`  User link flags passed as strings. Accepts either [String], [[String]] or depset(String). The latter is discouraged as it's only kept for compatibility purposes, the depset is flattened. If you want to propagate user\_link\_flags via unflattened depsets() wrap them in a LinkerInput so that they are not flattened till the end. |
-| `additional_inputs` | `None`; or [depset](../builtins/depset); default is `None`  For additional inputs to the linking action, e.g.: linking scripts. |
+| `libraries` | `None`; or [depset](/versions/7.7.1/rules/lib/builtins/depset); default is `None`  List of `LibraryToLink`. |
+| `user_link_flags` | `None`; or [depset](/versions/7.7.1/rules/lib/builtins/depset) of [string](/versions/7.7.1/rules/lib/core/string)s; or [sequence](/versions/7.7.1/rules/lib/core/list) of [string](/versions/7.7.1/rules/lib/core/string)s; default is `None`  User link flags passed as strings. Accepts either [String], [[String]] or depset(String). The latter is discouraged as it's only kept for compatibility purposes, the depset is flattened. If you want to propagate user\_link\_flags via unflattened depsets() wrap them in a LinkerInput so that they are not flattened till the end. |
+| `additional_inputs` | `None`; or [depset](/versions/7.7.1/rules/lib/builtins/depset); default is `None`  For additional inputs to the linking action, e.g.: linking scripts. |
 
 ## create\_linking\_context
 
@@ -279,10 +279,10 @@ Creates a `LinkingContext`.
 
 | Parameter | Description |
 | --- | --- |
-| `linker_inputs` | `None`; or [depset](../builtins/depset); default is `None`  Depset of `LinkerInput`. |
-| `libraries_to_link` | `None`; or [sequence](../core/list); default is `None`  **Deprecated**. This parameter is deprecated and will be removed soon. Please do not depend on it. It is *disabled* with `--+incompatible_require_linker_input_cc_api`. Use this flag to verify your code is compatible with its imminent removal.  List of `LibraryToLink`. |
-| `user_link_flags` | `None`; or [sequence](../core/list); default is `None` |
-| `additional_inputs` | `None`; or [sequence](../core/list); default is `None` |
+| `linker_inputs` | `None`; or [depset](/versions/7.7.1/rules/lib/builtins/depset); default is `None`  Depset of `LinkerInput`. |
+| `libraries_to_link` | `None`; or [sequence](/versions/7.7.1/rules/lib/core/list); default is `None`  **Deprecated**. This parameter is deprecated and will be removed soon. Please do not depend on it. It is *disabled* with `--+incompatible_require_linker_input_cc_api`. Use this flag to verify your code is compatible with its imminent removal.  List of `LibraryToLink`. |
+| `user_link_flags` | `None`; or [sequence](/versions/7.7.1/rules/lib/core/list); default is `None` |
+| `additional_inputs` | `None`; or [sequence](/versions/7.7.1/rules/lib/core/list); default is `None` |
 
 ## create\_linking\_context\_from\_compilation\_outputs
 
@@ -409,7 +409,7 @@ Should be used for C++ transitive linking.
 | `actions` | required  `actions` object. |
 | `feature_configuration` | required  `feature_configuration` to be queried. |
 | `cc_toolchain` | required  `CcToolchainInfo` provider to be used. |
-| `compilation_outputs` | [CcCompilationOutputs](../builtins/CcCompilationOutputs); or `None`; default is `None`  Compilation outputs containing object files to link. |
+| `compilation_outputs` | [CcCompilationOutputs](/versions/7.7.1/rules/lib/builtins/CcCompilationOutputs); or `None`; default is `None`  Compilation outputs containing object files to link. |
 | `user_link_flags` | default is `[]`  Additional list of linker options. |
 | `linking_contexts` | default is `[]`  Linking contexts from dependencies to be linked into the linking context generated by this rule. |
 | `name` | required  This is used for naming the output artifacts of actions created by this method. |
@@ -417,8 +417,8 @@ Should be used for C++ transitive linking.
 | `output_type` | default is `'executable'`  Can be either 'executable' or 'dynamic\_library'. |
 | `link_deps_statically` | default is `True`  True to link dependencies statically, False dynamically. |
 | `stamp` | default is `0`  Whether to include build information in the linked executable, if output\_type is 'executable'. If 1, build information is always included. If 0 (the default build information is always excluded. If -1, uses the default behavior, which may be overridden by the --[no]stamp flag. This should be unset (or set to 0) when generating the executable output for test rules. |
-| `additional_inputs` | [sequence](../core/list); or [depset](../builtins/depset); default is `[]`  For additional inputs to the linking action, e.g.: linking scripts. |
-| `additional_outputs` | [sequence](../core/list); default is `unbound`  For additional outputs to the linking action, e.g.: map files. |
+| `additional_inputs` | [sequence](/versions/7.7.1/rules/lib/core/list); or [depset](/versions/7.7.1/rules/lib/builtins/depset); default is `[]`  For additional inputs to the linking action, e.g.: linking scripts. |
+| `additional_outputs` | [sequence](/versions/7.7.1/rules/lib/core/list); default is `unbound`  For additional outputs to the linking action, e.g.: map files. |
 
 ## merge\_compilation\_contexts
 
diff --git a/versions/7.7.1/rules/lib/toplevel/config.mdx b/versions/7.7.1/rules/lib/toplevel/config.mdx
index cb118d1f..11ed3ef2 100644
--- a/versions/7.7.1/rules/lib/toplevel/config.mdx
+++ b/versions/7.7.1/rules/lib/toplevel/config.mdx
@@ -48,7 +48,7 @@ Creates an execution transition.
 
 | Parameter | Description |
 | --- | --- |
-| `exec_group` | [string](../core/string); or `None`; default is `None`  The name of the exec group whose execution platform this transition will use. If not provided, this exec transition will use the target's default execution platform. |
+| `exec_group` | [string](/versions/7.7.1/rules/lib/core/string); or `None`; default is `None`  The name of the exec group whose execution platform this transition will use. If not provided, this exec transition will use the target's default execution platform. |
 
 ## int
 
diff --git a/versions/7.7.1/rules/lib/toplevel/config_common.mdx b/versions/7.7.1/rules/lib/toplevel/config_common.mdx
index 9169b17a..d8714372 100644
--- a/versions/7.7.1/rules/lib/toplevel/config_common.mdx
+++ b/versions/7.7.1/rules/lib/toplevel/config_common.mdx
@@ -29,5 +29,5 @@ Declare a rule's dependency on a toolchain type.
 
 | Parameter | Description |
 | --- | --- |
-| `name` | [string](../core/string); or [Label](../builtins/Label); required  The toolchain type that is required. |
-| `mandatory` | [bool](../core/bool); default is `True`  Whether the toolchain type is mandatory or optional. |
\ No newline at end of file
+| `name` | [string](/versions/7.7.1/rules/lib/core/string); or [Label](/versions/7.7.1/rules/lib/builtins/Label); required  The toolchain type that is required. |
+| `mandatory` | [bool](/versions/7.7.1/rules/lib/core/bool); default is `True`  Whether the toolchain type is mandatory or optional. |
\ No newline at end of file
diff --git a/versions/7.7.1/rules/lib/toplevel/coverage_common.mdx b/versions/7.7.1/rules/lib/toplevel/coverage_common.mdx
index ab2b343b..b7d4cbd9 100644
--- a/versions/7.7.1/rules/lib/toplevel/coverage_common.mdx
+++ b/versions/7.7.1/rules/lib/toplevel/coverage_common.mdx
@@ -14,7 +14,7 @@ Helper functions to access coverage-related infrastructure.
 InstrumentedFilesInfo coverage_common.instrumented_files_info(ctx, *, source_attributes=[], dependency_attributes=[], extensions=None, metadata_files=[])
 ```
 
-Creates a new [InstrumentedFilesInfo](../providers/InstrumentedFilesInfo) instance. Use this provider to communicate coverage-related attributes of the current build rule.
+Creates a new [InstrumentedFilesInfo](/versions/7.7.1/rules/lib/providers/InstrumentedFilesInfo) instance. Use this provider to communicate coverage-related attributes of the current build rule.
 
 ### Parameters
 
@@ -23,5 +23,5 @@ Creates a new [InstrumentedFilesInfo](../providers/InstrumentedFilesInfo) instan
 | `ctx` | required  The rule context. |
 | `source_attributes` | default is `[]`  A list of attribute names which contain source files processed by this rule. |
 | `dependency_attributes` | default is `[]`  A list of attribute names which might provide runtime dependencies (either code dependencies or runfiles). |
-| `extensions` | [sequence](../core/list) of [string](../core/string)s; or `None`; default is `None`  File extensions used to filter files from source\_attributes. For example, 'js'. If not provided (or None), then all files from source\_attributes will be added to instrumented files, if an empty list is provided, then no files from source attributes will be added. |
-| `metadata_files` | [sequence](../core/list) of [File](../builtins/File)s; default is `[]`  Additional files required to generate coverage LCOV files after code execution. e.g. .gcno files for C++. |
\ No newline at end of file
+| `extensions` | [sequence](/versions/7.7.1/rules/lib/core/list) of [string](/versions/7.7.1/rules/lib/core/string)s; or `None`; default is `None`  File extensions used to filter files from source\_attributes. For example, 'js'. If not provided (or None), then all files from source\_attributes will be added to instrumented files, if an empty list is provided, then no files from source attributes will be added. |
+| `metadata_files` | [sequence](/versions/7.7.1/rules/lib/core/list) of [File](/versions/7.7.1/rules/lib/builtins/File)s; default is `[]`  Additional files required to generate coverage LCOV files after code execution. e.g. .gcno files for C++. |
\ No newline at end of file
diff --git a/versions/7.7.1/rules/lib/toplevel/java_common.mdx b/versions/7.7.1/rules/lib/toplevel/java_common.mdx
index 062cfd9e..cffa60e9 100644
--- a/versions/7.7.1/rules/lib/toplevel/java_common.mdx
+++ b/versions/7.7.1/rules/lib/toplevel/java_common.mdx
@@ -36,32 +36,32 @@ Compiles Java source files/jars from the implementation of a Starlark rule and r
 | Parameter | Description |
 | --- | --- |
 | `ctx` | required  The rule context. |
-| `source_jars` | [sequence](../core/list) of [File](../builtins/File)s; default is `[]`  A list of the jars to be compiled. At least one of source\_jars or source\_files should be specified. |
-| `source_files` | [sequence](../core/list) of [File](../builtins/File)s; default is `[]`  A list of the Java source files to be compiled. At least one of source\_jars or source\_files should be specified. |
+| `source_jars` | [sequence](/versions/7.7.1/rules/lib/core/list) of [File](/versions/7.7.1/rules/lib/builtins/File)s; default is `[]`  A list of the jars to be compiled. At least one of source\_jars or source\_files should be specified. |
+| `source_files` | [sequence](/versions/7.7.1/rules/lib/core/list) of [File](/versions/7.7.1/rules/lib/builtins/File)s; default is `[]`  A list of the Java source files to be compiled. At least one of source\_jars or source\_files should be specified. |
 | `output` | required |
-| `output_source_jar` | [File](../builtins/File); or `None`; default is `None`  The output source jar. Optional. Defaults to `{output\_jar}-src.jar` if unset. |
-| `javac_opts` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  A list of the desired javac options. Optional. |
-| `deps` | [sequence](../core/list) of [struct](../builtins/struct)s; default is `[]`  A list of dependencies. Optional. |
-| `runtime_deps` | [sequence](../core/list) of [struct](../builtins/struct)s; default is `[]`  A list of runtime dependencies. Optional. |
-| `exports` | [sequence](../core/list) of [struct](../builtins/struct)s; default is `[]`  A list of exports. Optional. |
-| `plugins` | [sequence](../core/list) of [struct](../builtins/struct)s; or [sequence](../core/list) of [struct](../builtins/struct)s; default is `[]`  A list of plugins. Optional. |
-| `exported_plugins` | [sequence](../core/list) of [struct](../builtins/struct)s; or [sequence](../core/list) of [struct](../builtins/struct)s; default is `[]`  A list of exported plugins. Optional. |
-| `native_libraries` | [sequence](../core/list) of [CcInfo](../providers/CcInfo)s; default is `[]`  CC native library dependencies that are needed for this library. |
-| `annotation_processor_additional_inputs` | [sequence](../core/list) of [File](../builtins/File)s; default is `[]`  A list of inputs that the Java compilation action will take in addition to the Java sources for annotation processing. |
-| `annotation_processor_additional_outputs` | [sequence](../core/list) of [File](../builtins/File)s; default is `[]`  A list of outputs that the Java compilation action will output in addition to the class jar from annotation processing. |
+| `output_source_jar` | [File](/versions/7.7.1/rules/lib/builtins/File); or `None`; default is `None`  The output source jar. Optional. Defaults to `{output\_jar}-src.jar` if unset. |
+| `javac_opts` | [sequence](/versions/7.7.1/rules/lib/core/list) of [string](/versions/7.7.1/rules/lib/core/string)s; default is `[]`  A list of the desired javac options. Optional. |
+| `deps` | [sequence](/versions/7.7.1/rules/lib/core/list) of [struct](/versions/7.7.1/rules/lib/builtins/struct)s; default is `[]`  A list of dependencies. Optional. |
+| `runtime_deps` | [sequence](/versions/7.7.1/rules/lib/core/list) of [struct](/versions/7.7.1/rules/lib/builtins/struct)s; default is `[]`  A list of runtime dependencies. Optional. |
+| `exports` | [sequence](/versions/7.7.1/rules/lib/core/list) of [struct](/versions/7.7.1/rules/lib/builtins/struct)s; default is `[]`  A list of exports. Optional. |
+| `plugins` | [sequence](/versions/7.7.1/rules/lib/core/list) of [struct](/versions/7.7.1/rules/lib/builtins/struct)s; or [sequence](/versions/7.7.1/rules/lib/core/list) of [struct](/versions/7.7.1/rules/lib/builtins/struct)s; default is `[]`  A list of plugins. Optional. |
+| `exported_plugins` | [sequence](/versions/7.7.1/rules/lib/core/list) of [struct](/versions/7.7.1/rules/lib/builtins/struct)s; or [sequence](/versions/7.7.1/rules/lib/core/list) of [struct](/versions/7.7.1/rules/lib/builtins/struct)s; default is `[]`  A list of exported plugins. Optional. |
+| `native_libraries` | [sequence](/versions/7.7.1/rules/lib/core/list) of [CcInfo](/versions/7.7.1/rules/lib/providers/CcInfo)s; default is `[]`  CC native library dependencies that are needed for this library. |
+| `annotation_processor_additional_inputs` | [sequence](/versions/7.7.1/rules/lib/core/list) of [File](/versions/7.7.1/rules/lib/builtins/File)s; default is `[]`  A list of inputs that the Java compilation action will take in addition to the Java sources for annotation processing. |
+| `annotation_processor_additional_outputs` | [sequence](/versions/7.7.1/rules/lib/core/list) of [File](/versions/7.7.1/rules/lib/builtins/File)s; default is `[]`  A list of outputs that the Java compilation action will output in addition to the class jar from annotation processing. |
 | `strict_deps` | default is `'ERROR'`  A string that specifies how to handle strict deps. Possible values: 'OFF', 'ERROR', 'WARN' and 'DEFAULT'. For more details see /docs/user-manual#flag--strict\_java\_deps. By default 'ERROR'. |
 | `java_toolchain` | required  A JavaToolchainInfo to be used for this compilation. Mandatory. |
 | `bootclasspath` | default is `None`  A BootClassPathInfo to be used for this compilation. If present, overrides the bootclasspath associated with the provided java\_toolchain. Optional. |
 | `host_javabase` | default is `None`  **Deprecated**. This parameter is deprecated and will be removed soon. Please do not depend on it. It is *disabled* with `--+incompatible_java_common_parameters`. Use this flag to verify your code is compatible with its imminent removal.  Deprecated: You can drop this parameter (host\_javabase is provided with java\_toolchain) |
-| `sourcepath` | [sequence](../core/list) of [File](../builtins/File)s; default is `[]` |
-| `resources` | [sequence](../core/list) of [File](../builtins/File)s; default is `[]` |
-| `resource_jars` | [sequence](../core/list) of [File](../builtins/File)s; default is `[]` |
-| `classpath_resources` | [sequence](../core/list) of [File](../builtins/File)s; default is `[]` |
+| `sourcepath` | [sequence](/versions/7.7.1/rules/lib/core/list) of [File](/versions/7.7.1/rules/lib/builtins/File)s; default is `[]` |
+| `resources` | [sequence](/versions/7.7.1/rules/lib/core/list) of [File](/versions/7.7.1/rules/lib/builtins/File)s; default is `[]` |
+| `resource_jars` | [sequence](/versions/7.7.1/rules/lib/core/list) of [File](/versions/7.7.1/rules/lib/builtins/File)s; default is `[]` |
+| `classpath_resources` | [sequence](/versions/7.7.1/rules/lib/core/list) of [File](/versions/7.7.1/rules/lib/builtins/File)s; default is `[]` |
 | `neverlink` | default is `False` |
 | `enable_annotation_processing` | default is `True`  Disables annotation processing in this compilation, causing any annotation processors provided in plugins or in exported\_plugins of deps to be ignored. |
 | `enable_compile_jar_action` | default is `True`  Enables header compilation or ijar creation. If set to False, it forces use of the full class jar in the compilation classpaths of any dependants. Doing so is intended for use by non-library targets such as binaries that do not have dependants. |
-| `add_exports` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  Allow this library to access the given /. Optional. |
-| `add_opens` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  Allow this library to reflectively access the given /. Optional. |
+| `add_exports` | [sequence](/versions/7.7.1/rules/lib/core/list) of [string](/versions/7.7.1/rules/lib/core/string)s; default is `[]`  Allow this library to access the given /. Optional. |
+| `add_opens` | [sequence](/versions/7.7.1/rules/lib/core/list) of [string](/versions/7.7.1/rules/lib/core/string)s; default is `[]`  Allow this library to reflectively access the given /. Optional. |
 
 ## JavaRuntimeInfo
 
@@ -91,7 +91,7 @@ Merges the given providers into a single JavaInfo.
 
 | Parameter | Description |
 | --- | --- |
-| `providers` | [sequence](../core/list) of [struct](../builtins/struct)s; required  The list of providers to merge. |
+| `providers` | [sequence](/versions/7.7.1/rules/lib/core/list) of [struct](/versions/7.7.1/rules/lib/builtins/struct)s; required  The list of providers to merge. |
 
 ## pack\_sources
 
@@ -110,10 +110,10 @@ Packs sources and source jars into a single source jar file. The return value is
 | Parameter | Description |
 | --- | --- |
 | `actions` | required  ctx.actions |
-| `output_jar` | [File](../builtins/File); or `None`; default is `None`  **Deprecated**. This parameter is deprecated and will be removed soon. Please do not depend on it. It is *disabled* with `--+incompatible_java_common_parameters`. Use this flag to verify your code is compatible with its imminent removal.  Deprecated: The output jar of the rule. Used to name the resulting source jar. The parameter sets output\_source\_jar parameter to `{output\_jar}-src.jar`.Use output\_source\_jar parameter directly instead. |
-| `output_source_jar` | [File](../builtins/File); or `None`; default is `None` |
-| `sources` | [sequence](../core/list) of [File](../builtins/File)s; default is `[]`  A list of Java source files to be packed into the source jar. |
-| `source_jars` | [sequence](../core/list) of [File](../builtins/File)s; default is `[]`  A list of source jars to be packed into the source jar. |
+| `output_jar` | [File](/versions/7.7.1/rules/lib/builtins/File); or `None`; default is `None`  **Deprecated**. This parameter is deprecated and will be removed soon. Please do not depend on it. It is *disabled* with `--+incompatible_java_common_parameters`. Use this flag to verify your code is compatible with its imminent removal.  Deprecated: The output jar of the rule. Used to name the resulting source jar. The parameter sets output\_source\_jar parameter to `{output\_jar}-src.jar`.Use output\_source\_jar parameter directly instead. |
+| `output_source_jar` | [File](/versions/7.7.1/rules/lib/builtins/File); or `None`; default is `None` |
+| `sources` | [sequence](/versions/7.7.1/rules/lib/core/list) of [File](/versions/7.7.1/rules/lib/builtins/File)s; default is `[]`  A list of Java source files to be packed into the source jar. |
+| `source_jars` | [sequence](/versions/7.7.1/rules/lib/core/list) of [File](/versions/7.7.1/rules/lib/builtins/File)s; default is `[]`  A list of source jars to be packed into the source jar. |
 | `java_toolchain` | required  A JavaToolchainInfo to used to find the ijar tool. |
 | `host_javabase` | default is `None`  **Deprecated**. This parameter is deprecated and will be removed soon. Please do not depend on it. It is *disabled* with `--+incompatible_java_common_parameters`. Use this flag to verify your code is compatible with its imminent removal.  Deprecated: You can drop this parameter (host\_javabase is provided with java\_toolchain) |
 
@@ -131,7 +131,7 @@ Runs ijar on a jar, stripping it of its method bodies. This helps reduce rebuild
 | --- | --- |
 | `actions` | required |
 | `jar` | required  The jar to run ijar on. |
-| `target_label` | [Label](../builtins/Label); or `None`; default is `None`  A target label to stamp the jar with. Used for `add_dep` support. Typically, you would pass `ctx.label` to stamp the jar with the current rule's label. |
+| `target_label` | [Label](/versions/7.7.1/rules/lib/builtins/Label); or `None`; default is `None`  A target label to stamp the jar with. Used for `add_dep` support. Typically, you would pass `ctx.label` to stamp the jar with the current rule's label. |
 | `java_toolchain` | required  A JavaToolchainInfo to used to find the ijar tool. |
 
 ## stamp\_jar
diff --git a/versions/7.7.1/rules/lib/toplevel/native.mdx b/versions/7.7.1/rules/lib/toplevel/native.mdx
index d819eec9..fb3b070a 100644
--- a/versions/7.7.1/rules/lib/toplevel/native.mdx
+++ b/versions/7.7.1/rules/lib/toplevel/native.mdx
@@ -76,9 +76,9 @@ Specifies a list of files belonging to this package that are exported to other p
 
 | Parameter | Description |
 | --- | --- |
-| `srcs` | [sequence](../core/list) of [string](../core/string)s; required  The list of files to export. |
-| `visibility` | [sequence](../core/list); or `None`; default is `None`  A visibility declaration can to be specified. The files will be visible to the targets specified. If no visibility is specified, the files will be visible to every package. |
-| `licenses` | [sequence](../core/list) of [string](../core/string)s; or `None`; default is `None`  Licenses to be specified. |
+| `srcs` | [sequence](/versions/7.7.1/rules/lib/core/list) of [string](/versions/7.7.1/rules/lib/core/string)s; required  The list of files to export. |
+| `visibility` | [sequence](/versions/7.7.1/rules/lib/core/list); or `None`; default is `None`  A visibility declaration can to be specified. The files will be visible to the targets specified. If no visibility is specified, the files will be visible to every package. |
+| `licenses` | [sequence](/versions/7.7.1/rules/lib/core/list) of [string](/versions/7.7.1/rules/lib/core/string)s; or `None`; default is `None`  Licenses to be specified. |
 
 ## glob
 
@@ -97,8 +97,8 @@ If the `exclude_directories` argument is enabled (set to `1`), files of type dir
 
 | Parameter | Description |
 | --- | --- |
-| `include` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  The list of glob patterns to include. |
-| `exclude` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  The list of glob patterns to exclude. |
+| `include` | [sequence](/versions/7.7.1/rules/lib/core/list) of [string](/versions/7.7.1/rules/lib/core/string)s; default is `[]`  The list of glob patterns to include. |
+| `exclude` | [sequence](/versions/7.7.1/rules/lib/core/list) of [string](/versions/7.7.1/rules/lib/core/string)s; default is `[]`  The list of glob patterns to exclude. |
 | `exclude_directories` | default is `1`  A flag whether to exclude directories or not. |
 | `allow_empty` | default is `unbound`  Whether we allow glob patterns to match nothing. If `allow\_empty` is False, each individual include pattern must match something and also the final result must be non-empty (after the matches of the `exclude` patterns are excluded). |
 
@@ -133,8 +133,8 @@ This function defines a set of packages and assigns a label to the group. The la
 | Parameter | Description |
 | --- | --- |
 | `name` | required  The unique name for this rule. |
-| `packages` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  A complete enumeration of packages in this group. |
-| `includes` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  Other package groups that are included in this one. |
+| `packages` | [sequence](/versions/7.7.1/rules/lib/core/list) of [string](/versions/7.7.1/rules/lib/core/string)s; default is `[]`  A complete enumeration of packages in this group. |
+| `includes` | [sequence](/versions/7.7.1/rules/lib/core/list) of [string](/versions/7.7.1/rules/lib/core/string)s; default is `[]`  Other package groups that are included in this one. |
 
 ## package\_name
 
@@ -150,19 +150,19 @@ The name of the package being evaluated, without the repository name. For exampl
 Label native.package_relative_label(input)
 ```
 
-Converts the input string into a [Label](../builtins/Label) object, in the context of the package currently being initialized (that is, the `BUILD` file for which the current macro is executing). If the input is already a `Label`, it is returned unchanged.
+Converts the input string into a [Label](/versions/7.7.1/rules/lib/builtins/Label) object, in the context of the package currently being initialized (that is, the `BUILD` file for which the current macro is executing). If the input is already a `Label`, it is returned unchanged.
 
 This function may only be called while evaluating a BUILD file and the macros it directly or indirectly calls; it may not be called in (for instance) a rule implementation function.
 
 The result of this function is the same `Label` value as would be produced by passing the given string to a label-valued attribute of a target declared in the BUILD file.
 
-*Usage note:* The difference between this function and [Label()](../builtins/Label#Label) is that `Label()` uses the context of the package of the `.bzl` file that called it, not the package of the `BUILD` file. Use `Label()` when you need to refer to a fixed target that is hardcoded into the macro, such as a compiler. Use `package_relative_label()` when you need to normalize a label string supplied by the BUILD file to a `Label` object. (There is no way to convert a string to a `Label` in the context of a package other than the BUILD file or the calling .bzl file. For that reason, outer macros should always prefer to pass Label objects to inner macros rather than label strings.)
+*Usage note:* The difference between this function and [Label()](/versions/7.7.1/rules/lib/builtins/Label#Label) is that `Label()` uses the context of the package of the `.bzl` file that called it, not the package of the `BUILD` file. Use `Label()` when you need to refer to a fixed target that is hardcoded into the macro, such as a compiler. Use `package_relative_label()` when you need to normalize a label string supplied by the BUILD file to a `Label` object. (There is no way to convert a string to a `Label` in the context of a package other than the BUILD file or the calling .bzl file. For that reason, outer macros should always prefer to pass Label objects to inner macros rather than label strings.)
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `input` | [string](../core/string); or [Label](../builtins/Label); required  The input label string or Label object. If a Label object is passed, it's returned as is. |
+| `input` | [string](/versions/7.7.1/rules/lib/core/string); or [Label](/versions/7.7.1/rules/lib/builtins/Label); required  The input label string or Label object. If a Label object is passed, it's returned as is. |
 
 ## repo\_name
 
@@ -195,6 +195,6 @@ Returns a new mutable list of every direct subpackage of the current package, re
 
 | Parameter | Description |
 | --- | --- |
-| `include` | [sequence](../core/list) of [string](../core/string)s; required |
-| `exclude` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  The list of glob patterns to exclude from subpackages scan. |
+| `include` | [sequence](/versions/7.7.1/rules/lib/core/list) of [string](/versions/7.7.1/rules/lib/core/string)s; required |
+| `exclude` | [sequence](/versions/7.7.1/rules/lib/core/list) of [string](/versions/7.7.1/rules/lib/core/string)s; default is `[]`  The list of glob patterns to exclude from subpackages scan. |
 | `allow_empty` | default is `False`  Whether we fail if the call returns an empty list. By default empty list indicates potential error in BUILD file where the call to subpackages() is superflous. Setting to true allows this function to succeed in that case. |
\ No newline at end of file
diff --git a/versions/7.7.1/rules/lib/toplevel/platform_common.mdx b/versions/7.7.1/rules/lib/toplevel/platform_common.mdx
index 17edc7c5..7ba1c091 100644
--- a/versions/7.7.1/rules/lib/toplevel/platform_common.mdx
+++ b/versions/7.7.1/rules/lib/toplevel/platform_common.mdx
@@ -18,7 +18,7 @@ Functions for Starlark to interact with the platform APIs.
 Provider platform_common.ConstraintSettingInfo
 ```
 
-The constructor/key for the [ConstraintSettingInfo](../providers/ConstraintSettingInfo) provider.
+The constructor/key for the [ConstraintSettingInfo](/versions/7.7.1/rules/lib/providers/ConstraintSettingInfo) provider.
 *Note: This API is experimental and may change at any time. It is disabled by default, but may be enabled with `--experimental_platforms_api`*
 
 ## ConstraintValueInfo
@@ -27,7 +27,7 @@ The constructor/key for the [ConstraintSettingInfo](../providers/ConstraintSetti
 Provider platform_common.ConstraintValueInfo
 ```
 
-The constructor/key for the [ConstraintValueInfo](../providers/ConstraintValueInfo) provider.
+The constructor/key for the [ConstraintValueInfo](/versions/7.7.1/rules/lib/providers/ConstraintValueInfo) provider.
 *Note: This API is experimental and may change at any time. It is disabled by default, but may be enabled with `--experimental_platforms_api`*
 
 ## PlatformInfo
@@ -36,7 +36,7 @@ The constructor/key for the [ConstraintValueInfo](../providers/ConstraintValueIn
 Provider platform_common.PlatformInfo
 ```
 
-The constructor/key for the [PlatformInfo](../providers/PlatformInfo) provider.
+The constructor/key for the [PlatformInfo](/versions/7.7.1/rules/lib/providers/PlatformInfo) provider.
 *Note: This API is experimental and may change at any time. It is disabled by default, but may be enabled with `--experimental_platforms_api`*
 
 ## TemplateVariableInfo
@@ -45,7 +45,7 @@ The constructor/key for the [PlatformInfo](../providers/PlatformInfo) provider.
 Provider platform_common.TemplateVariableInfo
 ```
 
-The constructor/key for the [TemplateVariableInfo](../providers/TemplateVariableInfo) provider.
+The constructor/key for the [TemplateVariableInfo](/versions/7.7.1/rules/lib/providers/TemplateVariableInfo) provider.
 
 ## ToolchainInfo
 
@@ -53,4 +53,4 @@ The constructor/key for the [TemplateVariableInfo](../providers/TemplateVariable
 Provider platform_common.ToolchainInfo
 ```
 
-The constructor/key for the [ToolchainInfo](../providers/ToolchainInfo) provider.
\ No newline at end of file
+The constructor/key for the [ToolchainInfo](/versions/7.7.1/rules/lib/providers/ToolchainInfo) provider.
\ No newline at end of file
diff --git a/versions/7.7.1/rules/lib/toplevel/testing.mdx b/versions/7.7.1/rules/lib/toplevel/testing.mdx
index ffd4f89f..83883fa5 100644
--- a/versions/7.7.1/rules/lib/toplevel/testing.mdx
+++ b/versions/7.7.1/rules/lib/toplevel/testing.mdx
@@ -25,11 +25,11 @@ The number of transitive dependencies of the test are limited. The limit is cont
 | Parameter | Description |
 | --- | --- |
 | `name` | required  Name of the target. It should be a Starlark identifier, matching pattern '[A-Za-z\_][A-Za-z0-9\_]\*'. |
-| `implementation` | required  The Starlark function implementing this analysis test. It must have exactly one parameter: [ctx](../builtins/ctx). The function is called during the analysis phase. It can access the attributes declared by `attrs` and populated via `attr_values`. The implementation function may not register actions. Instead, it must register a pass/fail result via providing [AnalysisTestResultInfo](../providers/AnalysisTestResultInfo). |
-| `attrs` | [dict](../core/dict); default is `{}`  Dictionary declaring the attributes. See the [rule](../globals/bzl#rule) call. Attributes are allowed to use configuration transitions defined using [analysis\_test\_transition](../globals/bzl#analysis_test_transition). |
-| `fragments` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  List of configuration fragments that are available to the implementation of the analysis test. |
-| `toolchains` | [sequence](../core/list); default is `[]`  The set of toolchains the test requires. See the [rule](../globals/bzl#rule) call. |
-| `attr_values` | [dict](../core/dict) of [string](../core/string)s; default is `{}`  Dictionary of attribute values to pass to the implementation. |
+| `implementation` | required  The Starlark function implementing this analysis test. It must have exactly one parameter: [ctx](/versions/7.7.1/rules/lib/builtins/ctx). The function is called during the analysis phase. It can access the attributes declared by `attrs` and populated via `attr_values`. The implementation function may not register actions. Instead, it must register a pass/fail result via providing [AnalysisTestResultInfo](/versions/7.7.1/rules/lib/providers/AnalysisTestResultInfo). |
+| `attrs` | [dict](/versions/7.7.1/rules/lib/core/dict); default is `{}`  Dictionary declaring the attributes. See the [rule](/versions/7.7.1/rules/lib/globals/bzl#rule) call. Attributes are allowed to use configuration transitions defined using [analysis\_test\_transition](/versions/7.7.1/rules/lib/globals/bzl#analysis_test_transition). |
+| `fragments` | [sequence](/versions/7.7.1/rules/lib/core/list) of [string](/versions/7.7.1/rules/lib/core/string)s; default is `[]`  List of configuration fragments that are available to the implementation of the analysis test. |
+| `toolchains` | [sequence](/versions/7.7.1/rules/lib/core/list); default is `[]`  The set of toolchains the test requires. See the [rule](/versions/7.7.1/rules/lib/globals/bzl#rule) call. |
+| `attr_values` | [dict](/versions/7.7.1/rules/lib/core/dict) of [string](/versions/7.7.1/rules/lib/core/string)s; default is `{}`  Dictionary of attribute values to pass to the implementation. |
 
 ## ExecutionInfo
 
@@ -37,7 +37,7 @@ The number of transitive dependencies of the test are limited. The limit is cont
 ExecutionInfo testing.ExecutionInfo(requirements={}, exec_group='test')
 ```
 
-[testing.ExecutionInfo](../providers/ExecutionInfo) provider key/constructor
+[testing.ExecutionInfo](/versions/7.7.1/rules/lib/providers/ExecutionInfo) provider key/constructor
 
 ## TestEnvironment
 
@@ -52,4 +52,4 @@ RunEnvironmentInfo testing.TestEnvironment(environment, inherited_environment=[]
 | Parameter | Description |
 | --- | --- |
 | `environment` | required  A map of string keys and values that represent environment variables and their values. These will be made available during the test execution. |
-| `inherited_environment` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  A sequence of names of environment variables. These variables are made available during the test execution with their current value taken from the shell environment. If a variable is contained in both `environment` and `inherited_environment`, the value inherited from the shell environment will take precedence if set. |
\ No newline at end of file
+| `inherited_environment` | [sequence](/versions/7.7.1/rules/lib/core/list) of [string](/versions/7.7.1/rules/lib/core/string)s; default is `[]`  A sequence of names of environment variables. These variables are made available during the test execution with their current value taken from the shell environment. If a variable is contained in both `environment` and `inherited_environment`, the value inherited from the shell environment will take precedence if set. |
\ No newline at end of file
diff --git a/versions/7.7.1/rules/performance.mdx b/versions/7.7.1/rules/performance.mdx
index 853c7d95..227df92d 100644
--- a/versions/7.7.1/rules/performance.mdx
+++ b/versions/7.7.1/rules/performance.mdx
@@ -15,7 +15,7 @@ widespread use.
 ## Use depsets {#use-depsets}
 
 Whenever you are rolling up information from rule dependencies you should use
-[depsets](lib/depset). Only use plain lists or dicts to publish information
+[depsets](/versions/7.7.1/rules/lib/builtins/depset). Only use plain lists or dicts to publish information
 local to the current rule.
 
 A depset represents information as a nested graph which enables sharing.
@@ -73,7 +73,7 @@ See the [depset overview](/versions/7.7.1/extending/depsets) page for more infor
 ### Avoid calling `depset.to_list()` {#avoid-depset-to-list}
 
 You can coerce a depset to a flat list using
-[`to_list()`](lib/depset#to_list), but doing so usually results in O(N^2)
+[`to_list()`](/versions/7.7.1/rules/lib/builtins/depset#to_list), but doing so usually results in O(N^2)
 cost. If at all possible, avoid any flattening of depsets except for debugging
 purposes.
 
@@ -115,7 +115,7 @@ x = depset(transitive = [i.deps for i in inputs])
 
 ## Use ctx.actions.args() for command lines {#ctx-actions-args}
 
-When building command lines you should use [ctx.actions.args()](lib/Args).
+When building command lines you should use [ctx.actions.args()](/versions/7.7.1/rules/lib/builtins/Args).
 This defers expansion of any depsets to the execution phase.
 
 Apart from being strictly faster, this will reduce the memory consumption of
@@ -126,11 +126,11 @@ Here are some tricks:
 * Pass depsets and lists directly as arguments, instead of flattening them
 yourself. They will get expanded by `ctx.actions.args()` for you.
 If you need any transformations on the depset contents, look at
-[ctx.actions.args#add](lib/Args#add) to see if anything fits the bill.
+[ctx.actions.args#add](/versions/7.7.1/rules/lib/builtins/Args#add) to see if anything fits the bill.
 
 * Are you passing `File#path` as arguments? No need. Any
-[File](lib/File) is automatically turned into its
-[path](lib/File#path), deferred to expansion time.
+[File](/versions/7.7.1/rules/lib/builtins/File) is automatically turned into its
+[path](/versions/7.7.1/rules/lib/builtins/File#path), deferred to expansion time.
 
 * Avoid constructing strings by concatenating them together.
 The best string argument is a constant as its memory will be shared between
@@ -138,10 +138,10 @@ all instances of your rule.
 
 * If the args are too long for the command line an `ctx.actions.args()` object
 can be conditionally or unconditionally written to a param file using
-[`ctx.actions.args#use_param_file`](lib/Args#use_param_file). This is
+[`ctx.actions.args#use_param_file`](/versions/7.7.1/rules/lib/builtins/Args#use_param_file). This is
 done behind the scenes when the action is executed. If you need to explicitly
 control the params file you can write it manually using
-[`ctx.actions.write`](lib/actions#write).
+[`ctx.actions.write`](/versions/7.7.1/rules/lib/builtins/actions#write).
 
 Example:
 
@@ -176,7 +176,7 @@ def _to_short_path(f):
 
 ## Transitive action inputs should be depsets {#transitive-action-inputs}
 
-When building an action using [ctx.actions.run](lib/actions?#run), do not
+When building an action using [ctx.actions.run](/versions/7.7.1/rules/lib/builtins/actions#run), do not
 forget that the `inputs` field accepts a depset. Use this whenever inputs are
 collected from dependencies transitively.
 
diff --git a/versions/7.7.1/rules/rules-tutorial.mdx b/versions/7.7.1/rules/rules-tutorial.mdx
index 8566a066..01292fb5 100644
--- a/versions/7.7.1/rules/rules-tutorial.mdx
+++ b/versions/7.7.1/rules/rules-tutorial.mdx
@@ -31,9 +31,9 @@ foo_binary = rule(
 )
 ```
 
-When you call the [`rule`](lib/globals#rule) function, you
+When you call the [`rule`](/versions/7.7.1/rules/lib/globals#rule) function, you
 must define a callback function. The logic will go there, but you
-can leave the function empty for now. The [`ctx`](lib/ctx) argument
+can leave the function empty for now. The [`ctx`](/versions/7.7.1/rules/lib/builtins/ctx) argument
 provides information about the target.
 
 You can load the rule and use it from a `BUILD` file.
@@ -86,10 +86,10 @@ foo_binary(name = "bin1")
 foo_binary(name = "bin2")
 ```
 
-[`ctx.label`](lib/ctx#label)
+[`ctx.label`](/versions/7.7.1/rules/lib/builtins/ctx#label)
 corresponds to the label of the target being analyzed. The `ctx` object has
 many useful fields and methods; you can find an exhaustive list in the
-[API reference](lib/ctx).
+[API reference](/versions/7.7.1/rules/lib/builtins/ctx).
 
 Query the code:
 
@@ -145,7 +145,7 @@ bin2
 ```
 
 Whenever you declare a file, you have to tell Bazel how to generate it by
-creating an action. Use [`ctx.actions.write`](lib/actions#write),
+creating an action. Use [`ctx.actions.write`](/versions/7.7.1/rules/lib/builtins/actions#write),
 to create a file with the given content.
 
 ```python
@@ -200,7 +200,7 @@ You have successfully generated a file!
 ## Attributes
 
 To make the rule more useful, add new attributes using
-[the `attr` module](lib/attr) and update the rule definition.
+[the `attr` module](/versions/7.7.1/rules/lib/toplevel/attr) and update the rule definition.
 
 Add a string attribute called `username`:
 
@@ -236,22 +236,22 @@ def _foo_binary_impl(ctx):
 ```
 
 Note that you can make the attribute mandatory or set a default value. Look at
-the documentation of [`attr.string`](lib/attr#string).
-You may also use other types of attributes, such as [boolean](lib/attr#bool)
-or [list of integers](lib/attr#int_list).
+the documentation of [`attr.string`](/versions/7.7.1/rules/lib/toplevel/attr#string).
+You may also use other types of attributes, such as [boolean](/versions/7.7.1/rules/lib/toplevel/attr#bool)
+or [list of integers](/versions/7.7.1/rules/lib/toplevel/attr#int_list).
 
 ## Dependencies
 
-Dependency attributes, such as [`attr.label`](lib/attr#label)
-and [`attr.label_list`](lib/attr#label_list),
+Dependency attributes, such as [`attr.label`](/versions/7.7.1/rules/lib/toplevel/attr#label)
+and [`attr.label_list`](/versions/7.7.1/rules/lib/toplevel/attr#label_list),
 declare a dependency from the target that owns the attribute to the target whose
 label appears in the attribute's value. This kind of attribute forms the basis
 of the target graph.
 
 In the `BUILD` file, the target label appears as a string object, such as
 `//pkg:name`. In the implementation function, the target will be accessible as a
-[`Target`](lib/Target) object. For example, view the files returned
-by the target using [`Target.files`](lib/Target#modules.Target.files).
+[`Target`](/versions/7.7.1/rules/lib/builtins/Target) object. For example, view the files returned
+by the target using [`Target.files`](/versions/7.7.1/rules/lib/builtins/Target#modules.Target.files).
 
 ### Multiple files
 
@@ -294,7 +294,7 @@ implementation function, but this has two problems. First, as the template gets
 bigger, it becomes more memory efficient to put it in a separate file and avoid
 constructing large strings during the analysis phase. Second, using a separate
 file is more convenient for the user. Instead, use
-[`ctx.actions.expand_template`](lib/actions#expand_template),
+[`ctx.actions.expand_template`](/versions/7.7.1/rules/lib/builtins/actions#expand_template),
 which performs substitutions on a template file.
 
 Create a `template` attribute to declare a dependency on the template
diff --git a/versions/7.7.1/rules/testing.mdx b/versions/7.7.1/rules/testing.mdx
index 86f645ea..5e77fa34 100644
--- a/versions/7.7.1/rules/testing.mdx
+++ b/versions/7.7.1/rules/testing.mdx
@@ -234,7 +234,7 @@ def _inspect_actions_test_impl(ctx):
 ```
 
 Note that `analysistest.target_actions(env)` returns a list of
-[`Action`](lib/Action) objects which represent actions registered by the
+[`Action`](/versions/7.7.1/rules/lib/builtins/Action) objects which represent actions registered by the
 target under test.
 
 ### Verifying rule behavior under different flags {#verifying-rule-behavior}
diff --git a/versions/7.7.1/rules/verbs-tutorial.mdx b/versions/7.7.1/rules/verbs-tutorial.mdx
index 7999f2c0..4083e4c5 100644
--- a/versions/7.7.1/rules/verbs-tutorial.mdx
+++ b/versions/7.7.1/rules/verbs-tutorial.mdx
@@ -49,8 +49,7 @@ This pattern can also be seen in the Angular project. The
 produces two targets. The first is a standard `nodejs_test` target which compares
 some generated output against a "golden" file (that is, a file containing the
 expected output). This can be built and run with a normal `bazel
-test` invocation. In `angular-cli`, you can run [one such
-target](https://github.com/angular/angular-cli/blob/e1269cb520871ee29b1a4eec6e6c0e4a94f0b5fc/etc/api/BUILD)
+test` invocation. In `angular-cli`, you can run [one such target](https://github.com/angular/angular-cli/blob/e1269cb520871ee29b1a4eec6e6c0e4a94f0b5fc/etc/api/BUILD)
 with `bazel test //etc/api:angular_devkit_core_api`.
 
 Over time, this golden file may need to be updated for legitimate reasons.
@@ -137,7 +136,7 @@ an imaginary `bazel publish` command.
 It's not immediately obvious what the implementation of the `_sphinx_publisher`
 rule might look like. Often, actions like this write a _launcher_ shell script.
 This method typically involves using
-[`ctx.actions.expand_template`](lib/actions#expand_template)
+[`ctx.actions.expand_template`](/versions/7.7.1/rules/lib/builtins/actions#expand_template)
 to write a very simple shell script, in this case invoking the publisher binary
 with a path to the output of the primary target. This way, the publisher
 implementation can remain generic, the `_sphinx_site` rule can just produce
diff --git a/versions/7.7.1/run/build.mdx b/versions/7.7.1/run/build.mdx
index 035ed129..7262b72b 100644
--- a/versions/7.7.1/run/build.mdx
+++ b/versions/7.7.1/run/build.mdx
@@ -575,8 +575,7 @@ Note: Hermeticity means that the action only uses its declared input
 files and no other files in the filesystem, and it only produces its declared
 output files. See [Hermeticity](/versions/7.7.1/basics/hermeticity) for more details.
 
-On some platforms such as [Google Kubernetes
-Engine](https://cloud.google.com/kubernetes-engine/) cluster nodes or Debian,
+On some platforms such as [Google Kubernetes Engine](https://cloud.google.com/kubernetes-engine/) cluster nodes or Debian,
 user namespaces are deactivated by default due to security
 concerns. This can be checked by looking at the file
 `/proc/sys/kernel/unprivileged_userns_clone`: if it exists and contains a 0,
diff --git a/versions/7.7.1/start/android-app.mdx b/versions/7.7.1/start/android-app.mdx
index dcbb7809..85e6fa41 100644
--- a/versions/7.7.1/start/android-app.mdx
+++ b/versions/7.7.1/start/android-app.mdx
@@ -36,8 +36,7 @@ In this tutorial you learn how to:
 Before you begin the tutorial, install the following software:
 
 * **Bazel.** To install, follow the [installation instructions](/versions/7.7.1/install).
-* **Android Studio.** To install, follow the steps to [download Android
-  Studio](https://developer.android.com/sdk/index.html).
+* **Android Studio.** To install, follow the steps to [download Android Studio](https://developer.android.com/sdk/index.html).
   Execute the setup wizard to download the SDK and configure your environment.
 * (Optional) **Git.** Use `git` to download the Android app project.
 
@@ -52,8 +51,7 @@ This app has a single button that prints a greeting when clicked:
 
 **Figure 1.** Android app button greeting.
 
-Clone the repository with `git` (or [download the ZIP file
-directly](https://github.com/bazelbuild/examples/archive/master.zip)):
+Clone the repository with `git` (or [download the ZIP file directly](https://github.com/bazelbuild/examples/archive/master.zip)):
 
 ```posix-terminal
 git clone https://github.com/bazelbuild/examples
@@ -103,8 +101,7 @@ A [workspace](/versions/7.7.1/concepts/build-ref#workspace) is a directory that
 source files for one or more software projects, and has a `WORKSPACE` file at
 its root.
 
-The `WORKSPACE` file may be empty or may contain references to [external
-dependencies](/versions/7.7.1/docs/external) required to build your project.
+The `WORKSPACE` file may be empty or may contain references to [external dependencies](/versions/7.7.1/docs/external) required to build your project.
 
 First, run the following command to create an empty `WORKSPACE` file:
 
@@ -147,8 +144,7 @@ environment variable, and automatically detect the highest API level and the
 latest version of build tools installed within that location.
 
 You can set the `ANDROID_HOME` variable to the location of the Android SDK. Find
-the path to the installed SDK using Android Studio's [SDK
-Manager](https://developer.android.com/studio/intro/update#sdk-manager).
+the path to the installed SDK using Android Studio's [SDK Manager](https://developer.android.com/studio/intro/update#sdk-manager).
 Assuming the SDK is installed to default locations, you can use the following
 commands to set the `ANDROID_HOME` variable:
 
@@ -197,8 +193,7 @@ android_sdk_repository(
 ```
 
 **Optional:** If you want to compile native code into your Android app, you
-also need to download the [Android
-NDK](https://developer.android.com/ndk/downloads/index.html)
+also need to download the [Android NDK](https://developer.android.com/ndk/downloads/index.html)
 and tell Bazel where to find it by adding the following line to your `WORKSPACE` file:
 
 ```python
@@ -209,8 +204,7 @@ Similar to `android_sdk_repository`, the path to the Android NDK is inferred
 from the `ANDROID_NDK_HOME` environment variable by default. The path can also
 be explicitly specified with a `path` attribute on `android_ndk_repository`.
 
-For more information, read [Using the Android Native Development Kit with
-Bazel](/versions/7.7.1/docs/android-ndk).
+For more information, read [Using the Android Native Development Kit with Bazel](/versions/7.7.1/docs/android-ndk).
 
 `api_level` is the version of the Android API that the SDK and NDK
 target - for example, 23 for Android 6.0 and 25 for Android 7.1. If not
@@ -257,8 +251,7 @@ files or other dependencies. Bazel provides two build rules,
 build an Android app.
 
 For this tutorial, you'll first use the
-`android_library` rule to tell Bazel to build an [Android library
-module](http://developer.android.com/tools/projects/index.html#LibraryProjects)
+`android_library` rule to tell Bazel to build an [Android library module](http://developer.android.com/tools/projects/index.html#LibraryProjects)
 from the app source code and resource files. You'll then use the
 `android_binary` rule to tell Bazel how to build the Android application package.
 
@@ -373,11 +366,9 @@ file:
 ### Run the app
 
 You can now deploy the app to a connected Android device or emulator from the
-command line using the [`bazel
-mobile-install`](/versions/7.7.1/docs/user-manual#mobile-install) command. This command uses
+command line using the [`bazel mobile-install`](/versions/7.7.1/docs/user-manual#mobile-install) command. This command uses
 the Android Debug Bridge (`adb`) to communicate with the device. You must set up
-your device to use `adb` following the instructions in [Android Debug
-Bridge](http://developer.android.com/tools/help/adb.html) before deployment. You
+your device to use `adb` following the instructions in [Android Debug Bridge](http://developer.android.com/tools/help/adb.html) before deployment. You
 can also choose to install the app on the Android emulator included in Android
 Studio. Make sure the emulator is running before executing the command below.
 
diff --git a/versions/7.7.1/start/cpp.mdx b/versions/7.7.1/start/cpp.mdx
index ebb86951..679f96ff 100644
--- a/versions/7.7.1/start/cpp.mdx
+++ b/versions/7.7.1/start/cpp.mdx
@@ -63,9 +63,7 @@ examples
 ```
 
 There are three sets of files, each set representing a stage in this tutorial.
-In the first stage, you will build a single [target]
-(https://bazel.build/reference/glossary#target) residing in a single [package]
-(https://bazel.build/reference/glossary#package). In the second stage, you will
+In the first stage, you will build a single [target](https://bazel.build/versions/7.7.1/reference/glossary#target) residing in a single [package](https://bazel.build/versions/7.7.1/reference/glossary#package). In the second stage, you will
 build both a binary and a library from a single package. In
 the third and final stage, you will build a project with multiple packages and
 build it with multiple targets.
diff --git a/versions/7.7.1/start/java.mdx b/versions/7.7.1/start/java.mdx
index eb5bec3c..99ced97f 100644
--- a/versions/7.7.1/start/java.mdx
+++ b/versions/7.7.1/start/java.mdx
@@ -241,8 +241,7 @@ recompiles that file.
 Looking at the dependency graph, you can see that `ProjectRunner` depends on the
 same inputs as it did before, but the structure of the build is different:
 
-![Dependency graph of the target 'ProjectRunner' after adding a dependency](
-/docs/images/tutorial_java_02.svg)
+![Dependency graph of the target 'ProjectRunner' after adding a dependency](/versions/7.7.1/docs/images/tutorial_java_02.svg)
 
 You've now built the project with two targets. The `ProjectRunner` target builds
 two source files and depends on one other target (`:greeter`), which builds
@@ -426,7 +425,7 @@ For more details, see:
 *  The [C++ build tutorial](/versions/7.7.1/start/cpp) to get started with building
    C++ projects with Bazel.
 
-*  The [Android application tutorial](/versions/7.7.1/start/android-app ) and
+*  The [Android application tutorial](/versions/7.7.1/start/android-app) and
    [iOS application tutorial](/versions/7.7.1/start/ios-app)) to get started with
    building mobile applications for Android and iOS with Bazel.
 
diff --git a/versions/8.0.1/about/roadmap.mdx b/versions/8.0.1/about/roadmap.mdx
index 4812b752..905de980 100644
--- a/versions/8.0.1/about/roadmap.mdx
+++ b/versions/8.0.1/about/roadmap.mdx
@@ -13,8 +13,7 @@ projects.
 
 ## Bazel 8.0 Release
 
-We plan to bring Bazel 8.0 [long term support
-(LTS)](https://bazel.build/release/versioning) to you in late 2024.
+We plan to bring Bazel 8.0 [long term support (LTS)](https://bazel.build/versions/8.0.1/release/versioning) to you in late 2024.
 The following features are planned to be implemented.
 
 ### Bzlmod: external dependency management system
@@ -29,8 +28,7 @@ support will be removed. Starting with Bazel 7.1, you can set
 `--noenable_workspace` to opt into the new behavior.
 
 Bazel 8.0 will contain a number of enhancements to
-[Bazel's external dependency management]
-(https://docs.google.com/document/d/1moQfNcEIttsk6vYanNKIy3ZuK53hQUFq1b1r0rmsYVg/edit#heading=h.lgyp7ubwxmjc)
+[Bazel's external dependency management](https://docs.google.com/document/d/1moQfNcEIttsk6vYanNKIy3ZuK53hQUFq1b1r0rmsYVg/edit#heading=h.lgyp7ubwxmjc)
 functionality, including:
 
 *   The new flag `--enable_workspace` can be set to `false` to completely
diff --git a/versions/8.0.1/basics/dependencies.mdx b/versions/8.0.1/basics/dependencies.mdx
index 326b6850..e8a300fa 100644
--- a/versions/8.0.1/basics/dependencies.mdx
+++ b/versions/8.0.1/basics/dependencies.mdx
@@ -65,8 +65,7 @@ targets, we’ve made some strides in mitigating the downside by investing in
 tooling to automatically manage `BUILD` files to avoid burdening developers.
 
 Some of these tools, such as `buildifier` and `buildozer`, are available with
-Bazel in the [`buildtools`
-directory](https://github.com/bazelbuild/buildtools).
+Bazel in the [`buildtools` directory](https://github.com/bazelbuild/buildtools).
 
 ## Minimizing Module Visibility
 
@@ -106,8 +105,7 @@ transitive dependencies (Figure 1). Suppose target A depends on target B, which
 depends on a common library target C. Should target A be able to use classes
 defined in target C?
 
-[![Transitive
-dependencies](/versions/8.0.1/images/transitive-dependencies.png)](/versions/8.0.1/images/transitive-dependencies.png)
+[![Transitive dependencies](/versions/8.0.1/images/transitive-dependencies.png)](/versions/8.0.1/images/transitive-dependencies.png)
 
 **Figure 1**. Transitive dependencies
 
@@ -141,9 +139,7 @@ dependencies and adding them to a `BUILD` files without any developer
 intervention. But even without such tools, we’ve found the trade-off to be well
 worth it as the codebase scales: explicitly adding a dependency to `BUILD` file
 is a one-time cost, but dealing with implicit transitive dependencies can cause
-ongoing problems as long as the build target exists. Bazel [enforces strict
-transitive
-dependencies](https://blog.bazel.build/2017/06/28/sjd-unused_deps.html)
+ongoing problems as long as the build target exists. Bazel [enforces strict transitive dependencies](https://blog.bazel.build/2017/06/28/sjd-unused_deps.html)
 on Java code by default.
 
 ### External dependencies
@@ -192,8 +188,7 @@ so in theory there’s no reason that different versions of the same external
 dependency couldn’t both be declared in the build system under different names.
 That way, each target could choose which version of the dependency it wanted to
 use. This causes a lot of problems in practice, so Google enforces a strict
-[One-Version
-Rule](https://opensource.google/docs/thirdparty/oneversion/) for
+[One-Version Rule](https://opensource.google/docs/thirdparty/oneversion/) for
 all third-party dependencies in our codebase.
 
 The biggest problem with allowing multiple versions is the diamond dependency
@@ -232,8 +227,7 @@ Bazel did not use to automatically download transitive dependencies. It used to
 employ a `WORKSPACE` file that required all transitive dependencies to be
 listed, which led to a lot of pain when managing external dependencies. Bazel
 has since added support for automatic transitive external dependency management
-in the form of the `MODULE.bazel` file. See [external dependency
-overview](/versions/8.0.1/external/overview) for more details.
+in the form of the `MODULE.bazel` file. See [external dependency overview](/versions/8.0.1/external/overview) for more details.
 
 Yet again, the choice here is one between convenience and scalability. Small
 projects might prefer not having to worry about managing transitive dependencies
diff --git a/versions/8.0.1/community/images/Bitrise.png b/versions/8.0.1/community/images/Bitrise.png
new file mode 100644
index 00000000..07f85f1e
Binary files /dev/null and b/versions/8.0.1/community/images/Bitrise.png differ
diff --git a/versions/8.0.1/community/images/Gradle.png b/versions/8.0.1/community/images/Gradle.png
new file mode 100644
index 00000000..1e5f5eb0
Binary files /dev/null and b/versions/8.0.1/community/images/Gradle.png differ
diff --git a/versions/8.0.1/community/images/Linkedin-Logo.png b/versions/8.0.1/community/images/Linkedin-Logo.png
new file mode 100644
index 00000000..9dd8715c
Binary files /dev/null and b/versions/8.0.1/community/images/Linkedin-Logo.png differ
diff --git a/versions/8.0.1/community/images/Lucid_Software-logo.svg b/versions/8.0.1/community/images/Lucid_Software-logo.svg
new file mode 100644
index 00000000..6c8591e0
--- /dev/null
+++ b/versions/8.0.1/community/images/Lucid_Software-logo.svg
@@ -0,0 +1,16 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/versions/8.0.1/community/images/acqio_logo.svg b/versions/8.0.1/community/images/acqio_logo.svg
new file mode 100644
index 00000000..8fa11bcd
--- /dev/null
+++ b/versions/8.0.1/community/images/acqio_logo.svg
@@ -0,0 +1,60 @@
+
+
+
+
+
+	
+		
+			
+				
+					
+					
+					
+					
+					
+				
+				
+					
+						
+							
+								
+							
+						
+					
+				
+				
+					
+						
+							
+								
+							
+						
+					
+				
+			
+		
+	
+
+
diff --git a/versions/8.0.1/community/images/aspect-logo-2.png b/versions/8.0.1/community/images/aspect-logo-2.png
new file mode 100644
index 00000000..dfebc4cb
Binary files /dev/null and b/versions/8.0.1/community/images/aspect-logo-2.png differ
diff --git a/versions/8.0.1/community/images/bitrise-logo.png b/versions/8.0.1/community/images/bitrise-logo.png
new file mode 100644
index 00000000..27037ce6
Binary files /dev/null and b/versions/8.0.1/community/images/bitrise-logo.png differ
diff --git a/versions/8.0.1/community/images/buildbuddy-logo.svg b/versions/8.0.1/community/images/buildbuddy-logo.svg
new file mode 100644
index 00000000..bdb72dc6
--- /dev/null
+++ b/versions/8.0.1/community/images/buildbuddy-logo.svg
@@ -0,0 +1,11 @@
+
+
+
+
+
+
+
+
+
+
+
diff --git a/versions/8.0.1/community/images/buildkite.svg b/versions/8.0.1/community/images/buildkite.svg
new file mode 100644
index 00000000..209a4ab1
--- /dev/null
+++ b/versions/8.0.1/community/images/buildkite.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/8.0.1/community/images/codethink-logo.svg b/versions/8.0.1/community/images/codethink-logo.svg
new file mode 100644
index 00000000..406005d8
--- /dev/null
+++ b/versions/8.0.1/community/images/codethink-logo.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/8.0.1/community/images/develocity.png b/versions/8.0.1/community/images/develocity.png
new file mode 100644
index 00000000..eb3eb65a
Binary files /dev/null and b/versions/8.0.1/community/images/develocity.png differ
diff --git a/versions/8.0.1/community/images/dropbox.png b/versions/8.0.1/community/images/dropbox.png
new file mode 100644
index 00000000..125476a6
Binary files /dev/null and b/versions/8.0.1/community/images/dropbox.png differ
diff --git a/versions/8.0.1/community/images/engflow-logo.svg b/versions/8.0.1/community/images/engflow-logo.svg
new file mode 100644
index 00000000..e5f0c343
--- /dev/null
+++ b/versions/8.0.1/community/images/engflow-logo.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/8.0.1/community/images/epam-logo.png b/versions/8.0.1/community/images/epam-logo.png
new file mode 100644
index 00000000..e6a5674c
Binary files /dev/null and b/versions/8.0.1/community/images/epam-logo.png differ
diff --git a/versions/8.0.1/community/images/flare-logo.png b/versions/8.0.1/community/images/flare-logo.png
new file mode 100644
index 00000000..84cb0e5b
Binary files /dev/null and b/versions/8.0.1/community/images/flare-logo.png differ
diff --git a/versions/8.0.1/community/images/hermetiq-logo.png b/versions/8.0.1/community/images/hermetiq-logo.png
new file mode 100644
index 00000000..90765d96
Binary files /dev/null and b/versions/8.0.1/community/images/hermetiq-logo.png differ
diff --git a/versions/8.0.1/community/images/jetbrains.svg b/versions/8.0.1/community/images/jetbrains.svg
new file mode 100644
index 00000000..cb3a2a0e
--- /dev/null
+++ b/versions/8.0.1/community/images/jetbrains.svg
@@ -0,0 +1,13 @@
+
+  
+    
+      
+      
+      
+    
+  
+  
+  
+  
+  
+
diff --git a/versions/8.0.1/community/images/liulishuo.png b/versions/8.0.1/community/images/liulishuo.png
new file mode 100644
index 00000000..a6758e5c
Binary files /dev/null and b/versions/8.0.1/community/images/liulishuo.png differ
diff --git a/versions/8.0.1/community/images/nativelink.svg b/versions/8.0.1/community/images/nativelink.svg
new file mode 100644
index 00000000..148fcdce
--- /dev/null
+++ b/versions/8.0.1/community/images/nativelink.svg
@@ -0,0 +1,1123 @@
+
+
+  
+    
+    
+      
+      
+    
+    
+      
+      
+    
+    
+    
+      
+      
+    
+    
+      
+      
+      
+      
+      
+      
+      
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+      
+      
+    
+    
+    
+    
+      
+      
+    
+    
+    
+    
+      
+      
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+      
+      
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+      
+      
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+      
+      
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+      
+      
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+      
+      
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+      
+      
+    
+  
+  
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+  
+  
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+  
+
diff --git a/versions/8.0.1/community/images/oasis-logo.png b/versions/8.0.1/community/images/oasis-logo.png
new file mode 100644
index 00000000..846a9cd5
Binary files /dev/null and b/versions/8.0.1/community/images/oasis-logo.png differ
diff --git a/versions/8.0.1/community/images/sumglobal-logo.png b/versions/8.0.1/community/images/sumglobal-logo.png
new file mode 100644
index 00000000..6736328d
Binary files /dev/null and b/versions/8.0.1/community/images/sumglobal-logo.png differ
diff --git a/versions/8.0.1/community/images/trunk-logo-dark.svg b/versions/8.0.1/community/images/trunk-logo-dark.svg
new file mode 100644
index 00000000..f25940af
--- /dev/null
+++ b/versions/8.0.1/community/images/trunk-logo-dark.svg
@@ -0,0 +1,22 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/versions/8.0.1/community/images/tweag-logo.png b/versions/8.0.1/community/images/tweag-logo.png
new file mode 100644
index 00000000..20210ed7
Binary files /dev/null and b/versions/8.0.1/community/images/tweag-logo.png differ
diff --git a/versions/8.0.1/community/images/typedb.png b/versions/8.0.1/community/images/typedb.png
new file mode 100644
index 00000000..48ce1056
Binary files /dev/null and b/versions/8.0.1/community/images/typedb.png differ
diff --git a/versions/8.0.1/community/images/virtuslab.svg b/versions/8.0.1/community/images/virtuslab.svg
new file mode 100644
index 00000000..6fba0316
--- /dev/null
+++ b/versions/8.0.1/community/images/virtuslab.svg
@@ -0,0 +1,20 @@
+
+
+  
+    
+  
+  
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+  
+
diff --git a/versions/8.0.1/community/roadmaps-configurability.mdx b/versions/8.0.1/community/roadmaps-configurability.mdx
index d922c632..d9560adb 100644
--- a/versions/8.0.1/community/roadmaps-configurability.mdx
+++ b/versions/8.0.1/community/roadmaps-configurability.mdx
@@ -26,8 +26,7 @@ title: 'Bazel Configurability 2021 Roadmap'
 * Builds scale well, particularly w.r.t graph size and action caching.
 
 We also support
-[`cquery`](https://bazel.build/versions/8.0.1/query/cquery), [`Starlark
-configuration`](https://bazel.build/extending/config),
+[`cquery`](https://bazel.build/versions/8.0.1/query/cquery), [`Starlark configuration`](https://bazel.build/versions/8.0.1/extending/config),
 and
 [`select()`](https://bazel.build/versions/8.0.1/docs/configurable-attributes).
 
@@ -41,15 +40,13 @@ interest of accurate expectations.
 ### Platforms
 
 

-Q3 2021**Android rules use the new [platforms
-API](https://bazel.build/concepts/platforms)**
+Q3 2021**Android rules use the new [platforms API](https://bazel.build/versions/8.0.1/concepts/platforms)**
 IN PROGRESS ([#11749](https://github.com/bazelbuild/bazel/issues/11749))
 
 * This is our main priority for the beginning of 2021.
 
 

-Q3 2021**Builds support [multiple execution
-platforms](https://docs.google.com/document/d/1U9HzdDmtRnm244CaRM6JV-q2408mbNODAMewcGjnnbM/)**
+Q3 2021**Builds support [multiple execution platforms](https://docs.google.com/document/d/1U9HzdDmtRnm244CaRM6JV-q2408mbNODAMewcGjnnbM/)**
 IN PROGRESS ([#11748](https://github.com/bazelbuild/bazel/issues/11748))
 
 

diff --git a/versions/8.0.1/community/sig.mdx b/versions/8.0.1/community/sig.mdx
index 407873a6..29461bd0 100644
--- a/versions/8.0.1/community/sig.mdx
+++ b/versions/8.0.1/community/sig.mdx
@@ -3,8 +3,7 @@ title: 'Bazel Special Interest Groups'
 ---
 
 Bazel hosts Special Interest Groups (SIGs) to focus collaboration on particular
-areas and to support communication and coordination between [Bazel owners,
-maintainers, and contributors](/versions/8.0.1/contribute/policy). This policy
+areas and to support communication and coordination between [Bazel owners, maintainers, and contributors](/versions/8.0.1/contribute/policy). This policy
 applies to [`bazelbuild`](http://github.com/bazelbuild).
 
 SIGs do their work in public. The ideal scope for a SIG covers a well-defined
diff --git a/versions/8.0.1/community/users.mdx b/versions/8.0.1/community/users.mdx
index 217a8d40..07ccc98e 100644
--- a/versions/8.0.1/community/users.mdx
+++ b/versions/8.0.1/community/users.mdx
@@ -304,11 +304,9 @@ safety systems_.
 Pigweed is an open-source solution for sustained, robust, and rapid embedded
 product development for large teams. Pigweed has shipped in millions of
 devices, including Google's suite of Pixel devices, Nest thermostats,
-[satellites](https://www.spinlaunch.com/), and [autonomous aerial
-drones](https://www.flyzipline.com/).
+[satellites](https://www.spinlaunch.com/), and [autonomous aerial drones](https://www.flyzipline.com/).
 
-Pigweed [uses Bazel as its primary build
-system](https://pigweed.dev/seed/0111-build-systems.html). The [Bazel for
+Pigweed [uses Bazel as its primary build system](https://pigweed.dev/seed/0111-build-systems.html). The [Bazel for
 Embedded][pw-bazel-great] blog post discusses why we think it's a great build
 system for embedded projects!
 
diff --git a/versions/8.0.1/concepts/build-ref.mdx b/versions/8.0.1/concepts/build-ref.mdx
index fdcaa2fe..918243bb 100644
--- a/versions/8.0.1/concepts/build-ref.mdx
+++ b/versions/8.0.1/concepts/build-ref.mdx
@@ -17,8 +17,7 @@ its root; such a boundary marker file could be `MODULE.bazel`, `REPO.bazel`, or
 in legacy contexts, `WORKSPACE` or `WORKSPACE.bazel`.
 
 The repo in which the current Bazel command is being run is called the _main
-repo_. Other, (external) repos are defined by _repo rules_; see [external
-dependencies overview](/versions/8.0.1/external/overview) for more information.
+repo_. Other, (external) repos are defined by _repo rules_; see [external dependencies overview](/versions/8.0.1/external/overview) for more information.
 
 ## Workspace {#workspace}
 
@@ -95,5 +94,4 @@ have three properties: the list of packages they contain, their name, and other
 package groups they include. The only allowed ways to refer to them are from the
 `visibility` attribute of rules or from the `default_visibility` attribute of
 the `package` function; they do not generate or consume files. For more
-information, refer to the [`package_group`
-documentation](/versions/8.0.1/reference/be/functions#package_group).
+information, refer to the [`package_group` documentation](/versions/8.0.1/reference/be/functions#package_group).
diff --git a/versions/8.0.1/concepts/labels.mdx b/versions/8.0.1/concepts/labels.mdx
index d62146ab..75958364 100644
--- a/versions/8.0.1/concepts/labels.mdx
+++ b/versions/8.0.1/concepts/labels.mdx
@@ -10,8 +10,7 @@ form looks like:
 ```
 
 The first part of the label is the repository name, `@@myrepo`. The double-`@`
-syntax signifies that this is a [*canonical* repo
-name](/versions/8.0.1/external/overview#canonical-repo-name), which is unique within
+syntax signifies that this is a [*canonical* repo name](/versions/8.0.1/external/overview#canonical-repo-name), which is unique within
 the workspace. Labels with canonical repo names unambiguously identify a target
 no matter which context they appear in.
 
diff --git a/versions/8.0.1/concepts/platforms.mdx b/versions/8.0.1/concepts/platforms.mdx
index 89fc8929..df6a6cf7 100644
--- a/versions/8.0.1/concepts/platforms.mdx
+++ b/versions/8.0.1/concepts/platforms.mdx
@@ -77,8 +77,7 @@ To test your Android project with platforms, see
 for support.
 
 You can still use platform APIs with Apple builds (for example, when building
-with a mixture of Apple rules and pure C++) with [platform
-mappings](#platform-mappings).
+with a mixture of Apple rules and pure C++) with [platform mappings](#platform-mappings).
 
 ### Other languages {#other-languages}
 
@@ -241,8 +240,7 @@ sets `--cpu`, `--crossstool_top`, or other legacy flags, rules that read
 
 When migrating your project to platforms, you must either convert changes like
 `return { "//command_line_option:cpu": "arm" }` to `return {
-"//command_line_option:platforms": "//:my_arm_platform" }` or use [platform
-mappings](#platform-mappings) to support both styles during migration.
+"//command_line_option:platforms": "//:my_arm_platform" }` or use [platform mappings](#platform-mappings) to support both styles during migration.
 window.
 
 ## Migrating your rule set {#migrating-your-rule-set}
@@ -361,10 +359,8 @@ attributes declare a language's tools (like `compiler =
 this information to rules that need to build with these tools.
 
 Toolchains declare the `constraint_value`s of machines they can
-[target][target_compatible_with Attribute]
-(`target_compatible_with = ["@platforms//os:linux"]`) and machines their tools can
-[run on][exec_compatible_with Attribute]
-(`exec_compatible_with = ["@platforms//os:mac"]`).
+[target][target_compatible_with Attribute](`target_compatible_with = ["@platforms//os:linux"]`) and machines their tools can
+[run on][exec_compatible_with Attribute](`exec_compatible_with = ["@platforms//os:mac"]`).
 
 When building `$ bazel build //:myproject --platforms=//:myplatform`, Bazel
 automatically selects a toolchain that can run on the build machine and
diff --git a/versions/8.0.1/configure/attributes.mdx b/versions/8.0.1/configure/attributes.mdx
index 75c15e29..0e15e5fa 100644
--- a/versions/8.0.1/configure/attributes.mdx
+++ b/versions/8.0.1/configure/attributes.mdx
@@ -2,8 +2,7 @@
 title: 'Configurable Build Attributes'
 ---
 
-**_Configurable attributes_**, commonly known as [`select()`](
-/reference/be/functions#select), is a Bazel feature that lets users toggle the values
+**_Configurable attributes_**, commonly known as [`select()`](/versions/8.0.1/reference/be/functions#select), is a Bazel feature that lets users toggle the values
 of build rule attributes at the command line.
 
 This can be used, for example, for a multiplatform library that automatically
@@ -407,8 +406,7 @@ sh_library(
 )
 ```
 
-If you need a `select` to match when multiple conditions match, consider [AND
-chaining](#and-chaining).
+If you need a `select` to match when multiple conditions match, consider [AND chaining](#and-chaining).
 
 ## OR chaining {#or-chaining}
 
diff --git a/versions/8.0.1/configure/integrate-cpp.mdx b/versions/8.0.1/configure/integrate-cpp.mdx
index e03a0207..8d87da31 100644
--- a/versions/8.0.1/configure/integrate-cpp.mdx
+++ b/versions/8.0.1/configure/integrate-cpp.mdx
@@ -33,8 +33,7 @@ This is because when writing our own actions, they must behave
 consistently with the C++ toolchain - for example, passing C++ command line
 flags to a tool that invokes the C++ compiler behind the scenes.
 
-C++ rules use a special way of constructing command lines based on [feature
-configuration](/versions/8.0.1/docs/cc-toolchain-config-reference). To construct a command line,
+C++ rules use a special way of constructing command lines based on [feature configuration](/versions/8.0.1/docs/cc-toolchain-config-reference). To construct a command line,
 you need the following:
 
 * `features` and `action_configs` - these come from the `CcToolchainConfigInfo`
diff --git a/versions/8.0.1/configure/windows.mdx b/versions/8.0.1/configure/windows.mdx
index 7637f93e..098fbcc5 100644
--- a/versions/8.0.1/configure/windows.mdx
+++ b/versions/8.0.1/configure/windows.mdx
@@ -166,8 +166,7 @@ To build C++ targets with MSVC, you need:
         set BAZEL_VC=C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC
         ```
 
-*   The [Windows
-    SDK](https://developer.microsoft.com/en-us/windows/downloads/windows-10-sdk).
+*   The [Windows SDK](https://developer.microsoft.com/en-us/windows/downloads/windows-10-sdk).
 
     The Windows SDK contains header files and libraries you need when building
     Windows applications, including Bazel itself. By default, the latest Windows SDK installed will
@@ -186,8 +185,7 @@ To build C++ targets with MSVC, you need:
 
 If everything is set up, you can build a C++ target now!
 
-Try building a target from one of our [sample
-projects](https://github.com/bazelbuild/bazel/tree/master/examples):
+Try building a target from one of our [sample projects](https://github.com/bazelbuild/bazel/tree/master/examples):
 
 
 
 
-To build and use Dynamically Linked Libraries (DLL files), see [this
-example](https://github.com/bazelbuild/bazel/tree/master/examples/windows/dll).
+To build and use Dynamically Linked Libraries (DLL files), see [this example](https://github.com/bazelbuild/bazel/tree/master/examples/windows/dll).
 
 **Command Line Length Limit**: To prevent the
 [Windows command line length limit issue](https://github.com/bazelbuild/bazel/issues/5163),
@@ -292,8 +289,7 @@ On Windows, Bazel builds two output files for `java_binary` rules:
 *   a `.jar` file
 *   a `.exe` file that can set up the environment for the JVM and run the binary
 
-Try building a target from one of our [sample
-projects](https://github.com/bazelbuild/bazel/tree/master/examples):
+Try building a target from one of our [sample projects](https://github.com/bazelbuild/bazel/tree/master/examples):
 
 
   bazel build //examples/java-native/src/main/java/com/example/myproject:hello-world
@@ -315,8 +311,7 @@ On Windows, Bazel builds two output files for `py_binary` rules:
 You can either run the executable file (it has a `.exe` extension) or you can run
 Python with the self-extracting zip file as the argument.
 
-Try building a target from one of our [sample
-projects](https://github.com/bazelbuild/bazel/tree/master/examples):
+Try building a target from one of our [sample projects](https://github.com/bazelbuild/bazel/tree/master/examples):
 
 
   
 
 If you are interested in details about how Bazel builds Python targets on
-Windows, check out this [design
-doc](https://github.com/bazelbuild/bazel-website/blob/master/designs/_posts/2016-09-05-build-python-on-windows.md).
+Windows, check out this [design doc](https://github.com/bazelbuild/bazel-website/blob/master/designs/_posts/2016-09-05-build-python-on-windows.md).
diff --git a/versions/8.0.1/contribute/breaking-changes.mdx b/versions/8.0.1/contribute/breaking-changes.mdx
index 80d89f14..04b190ac 100644
--- a/versions/8.0.1/contribute/breaking-changes.mdx
+++ b/versions/8.0.1/contribute/breaking-changes.mdx
@@ -67,7 +67,7 @@ should contain the URL of the GitHub issue. As the flag name starts with
 ```
 
 In the commit description, add a brief summary of the flag.
-Also add [`RELNOTES:`](release-notes.md) in the following form:
+Also add [`RELNOTES:`](/versions/8.0.1/contribute/release-notes) in the following form:
 `RELNOTES: --incompatible_name_of_flag has been added. See #xyz for details`
 
 The commit should also update the relevant documentation, so that there is no
diff --git a/versions/8.0.1/contribute/codebase.mdx b/versions/8.0.1/contribute/codebase.mdx
index 463bd7da..84fa45f1 100644
--- a/versions/8.0.1/contribute/codebase.mdx
+++ b/versions/8.0.1/contribute/codebase.mdx
@@ -227,8 +227,7 @@ repository", the others are called "external repositories".
 A repository is marked by a repo boundary file (`MODULE.bazel`, `REPO.bazel`, or
 in legacy contexts, `WORKSPACE` or `WORKSPACE.bazel`) in its root directory. The
 main repo is the source tree where you're invoking Bazel from. External repos
-are defined in various ways; see [external dependencies
-overview](/versions/8.0.1/external/overview) for more information.
+are defined in various ways; see [external dependencies overview](/versions/8.0.1/external/overview) for more information.
 
 Code of external repositories is symlinked or downloaded under
 `$OUTPUT_BASE/external`.
diff --git a/versions/8.0.1/contribute/design-documents.mdx b/versions/8.0.1/contribute/design-documents.mdx
index 66371e47..2b736334 100644
--- a/versions/8.0.1/contribute/design-documents.mdx
+++ b/versions/8.0.1/contribute/design-documents.mdx
@@ -25,7 +25,7 @@ Here are some examples of significant changes:
 When you write a design document, you can coordinate with other Bazel developers
 and seek guidance from Bazel's core team. For example, when a proposal adds,
 removes, or modifies any function or object available in BUILD, MODULE.bazel, or
-bzl files, add the [Starlark team](maintainers-guide.md) as reviewers.
+bzl files, add the [Starlark team](/versions/8.0.1/contribute/maintainers-guide) as reviewers.
 Design documents are reviewed before submission because:
 
 *   Bazel is a very complex system; seemingly innocuous local changes can have
@@ -137,8 +137,7 @@ A lead reviewer should be a domain expert who is:
 *   Objective and capable of providing constructive feedback
 *   Available for the entire review period to lead the process
 
-Consider checking the contacts for various [team
-labels](/versions/8.0.1/contribute/maintainers-guide#team-labels).
+Consider checking the contacts for various [team labels](/versions/8.0.1/contribute/maintainers-guide#team-labels).
 
 ## Markdown vs Google Docs {#markdown-versus-gdocs}
 
@@ -168,12 +167,10 @@ Markdown for posterity.
 
 ### Using Google Docs {#gdocs}
 
-For consistency, use the [Bazel design doc template](
-https://docs.google.com/document/d/1cE5zrjrR40RXNg64XtRFewSv6FrLV6slGkkqxBumS1w/edit).
+For consistency, use the [Bazel design doc template](https://docs.google.com/document/d/1cE5zrjrR40RXNg64XtRFewSv6FrLV6slGkkqxBumS1w/edit).
 It includes the necessary header and creates visual
 consistency with other Bazel related documents. To do that, click on **File** >
-**Make a copy** or click this link to [make a copy of the design doc
-template](https://docs.google.com/document/d/1cE5zrjrR40RXNg64XtRFewSv6FrLV6slGkkqxBumS1w/copy).
+**Make a copy** or click this link to [make a copy of the design doc template](https://docs.google.com/document/d/1cE5zrjrR40RXNg64XtRFewSv6FrLV6slGkkqxBumS1w/copy).
 
 To make your document readable to the world, click on
 **Share** > **Advanced** > **Change…**, and
diff --git a/versions/8.0.1/contribute/images/structured-concurrency-3d.svg b/versions/8.0.1/contribute/images/structured-concurrency-3d.svg
new file mode 100644
index 00000000..accbb42a
--- /dev/null
+++ b/versions/8.0.1/contribute/images/structured-concurrency-3d.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/8.0.1/contribute/images/structured-concurrency.svg b/versions/8.0.1/contribute/images/structured-concurrency.svg
new file mode 100644
index 00000000..0258d9a9
--- /dev/null
+++ b/versions/8.0.1/contribute/images/structured-concurrency.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/8.0.1/contribute/images/suspend-resume.svg b/versions/8.0.1/contribute/images/suspend-resume.svg
new file mode 100644
index 00000000..7de1218f
--- /dev/null
+++ b/versions/8.0.1/contribute/images/suspend-resume.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/8.0.1/contribute/images/unstructured-concurrency.svg b/versions/8.0.1/contribute/images/unstructured-concurrency.svg
new file mode 100644
index 00000000..0951639a
--- /dev/null
+++ b/versions/8.0.1/contribute/images/unstructured-concurrency.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/8.0.1/contribute/index.mdx b/versions/8.0.1/contribute/index.mdx
index 20acafc1..20ae49bc 100644
--- a/versions/8.0.1/contribute/index.mdx
+++ b/versions/8.0.1/contribute/index.mdx
@@ -10,8 +10,7 @@ As you use Bazel, you may find things that can be improved.
 You can help by [reporting issues](http://github.com/bazelbuild/bazel/issues)
 when:
 
-   - Bazel crashes or you encounter a bug that can [only be resolved using `bazel
-     clean`](/versions/8.0.1/run/build#correct-incremental-rebuilds).
+   - Bazel crashes or you encounter a bug that can [only be resolved using `bazel clean`](/versions/8.0.1/run/build#correct-incremental-rebuilds).
    - The documentation is incomplete or unclear. You can also report issues
      from the page you are viewing by using the "Create issue"
      link at the top right corner of the page.
@@ -21,11 +20,9 @@ when:
 
 You can engage with the Bazel community by:
 
-   - Answering questions [on Stack Overflow](
-     https://stackoverflow.com/questions/tagged/bazel).
+   - Answering questions [on Stack Overflow](https://stackoverflow.com/questions/tagged/bazel).
    - Helping other users [on Slack](https://slack.bazel.build).
-   - Improving documentation or [contributing examples](
-     https://github.com/bazelbuild/examples).
+   - Improving documentation or [contributing examples](https://github.com/bazelbuild/examples).
    - Sharing your experience or your tips, for example, on a blog or social media.
 
 ## Contribute code {#contribute-code}
@@ -40,8 +37,7 @@ You can contribute to the Bazel ecosystem by:
    - Contributing to Bazel-related tools, for example, migration tools.
    - Improving Bazel integration with other IDEs and tools.
 
-Before making a change, [create a GitHub
-issue](http://github.com/bazelbuild/bazel/issues)
+Before making a change, [create a GitHub issue](http://github.com/bazelbuild/bazel/issues)
 or email [bazel-discuss@](mailto:bazel-discuss@googlegroups.com).
 
 The most helpful contributions fix bugs or add features (as opposed
diff --git a/versions/8.0.1/contribute/maintainers-guide.mdx b/versions/8.0.1/contribute/maintainers-guide.mdx
index a5cc4f29..8a4a5c1b 100644
--- a/versions/8.0.1/contribute/maintainers-guide.mdx
+++ b/versions/8.0.1/contribute/maintainers-guide.mdx
@@ -4,8 +4,7 @@ title: 'Guide for Bazel Maintainers'
 
 This is a guide for the maintainers of the Bazel open source project.
 
-If you are looking to contribute to Bazel, please read [Contributing to
-Bazel](/versions/8.0.1/contribute) instead.
+If you are looking to contribute to Bazel, please read [Contributing to Bazel](/versions/8.0.1/contribute) instead.
 
 The objectives of this page are to:
 
@@ -37,8 +36,7 @@ repository.
 
 1. A user creates an issue by choosing one of the
 [issue templates](https://github.com/bazelbuild/bazel/issues/new/choose)
-   and it enters the pool of [unreviewed open
-   issues](https://github.com/bazelbuild/bazel/issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aopen+-label%3Auntriaged+-label%3Ap2+-label%3Ap1+-label%3Ap3+-label%3Ap4+-label%3Ateam-Starlark+-label%3Ateam-Rules-CPP+-label%3Ateam-Rules-Java+-label%3Ateam-XProduct+-label%3Ateam-Android+-label%3Ateam-Apple+-label%3Ateam-Configurability++-label%3Ateam-Performance+-label%3Ateam-Rules-Server+-label%3Ateam-Core+-label%3Ateam-Rules-Python+-label%3Ateam-Remote-Exec+-label%3Ateam-Local-Exec+-label%3Ateam-Bazel).
+   and it enters the pool of [unreviewed open issues](https://github.com/bazelbuild/bazel/issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aopen+-label%3Auntriaged+-label%3Ap2+-label%3Ap1+-label%3Ap3+-label%3Ap4+-label%3Ateam-Starlark+-label%3Ateam-Rules-CPP+-label%3Ateam-Rules-Java+-label%3Ateam-XProduct+-label%3Ateam-Android+-label%3Ateam-Apple+-label%3Ateam-Configurability++-label%3Ateam-Performance+-label%3Ateam-Rules-Server+-label%3Ateam-Core+-label%3Ateam-Rules-Python+-label%3Ateam-Remote-Exec+-label%3Ateam-Local-Exec+-label%3Ateam-Bazel).
 1. A member on the Developer Experience (DevEx) subteam rotation reviews the
    issue.
    1. If the issue is **not a bug** or a **feature request**, the DevEx member
@@ -58,21 +56,18 @@ repository.
 1. After reviewing the issue, the DevEx member decides if the issue requires
    immediate attention. If it does, they will assign the **P0**
    [priority](#priority) label and an owner from the list of team leads.
-1. The DevEx member assigns the `untriaged` label and exactly one [team
-   label](#team-labels) for routing.
+1. The DevEx member assigns the `untriaged` label and exactly one [team label](#team-labels) for routing.
 1. The DevEx member also assigns exactly one `type:` label, such as `type: bug`
    or `type: feature request`, according to the type of the issue.
 1. For platform-specific issues, the DevEx member assigns one `platform:` label,
    such as `platform:apple` for Mac-specific issues.
 1. If the issue is low priority and can be worked on by a new community
    contributor, the DevEx member assigns the `good first issue` label.
-At this stage, the issue enters the pool of [untriaged open
-issues](https://github.com/bazelbuild/bazel/issues?q=is%3Aissue+is%3Aopen+label%3Auntriaged).
+At this stage, the issue enters the pool of [untriaged open issues](https://github.com/bazelbuild/bazel/issues?q=is%3Aissue+is%3Aopen+label%3Auntriaged).
 
 Each Bazel subteam will triage all issues under labels they own, preferably on a
 weekly basis. The subteam will review and evaluate the issue and provide a
-resolution, if possible. If you are an owner of a team label, see [this section
-](#label-own) for more information.
+resolution, if possible. If you are an owner of a team label, see [this section](#label-own) for more information.
 
 When an issue is resolved, it can be closed.
 
@@ -111,8 +106,7 @@ preferably on a weekly basis.
      issue is either P0 or P1 we assume that is actively worked on.
 1. Remove the `untriaged` label.
 
-Note that you need to be in the [bazelbuild
-organization](https://github.com/bazelbuild) to be able to add or remove labels.
+Note that you need to be in the [bazelbuild organization](https://github.com/bazelbuild) to be able to add or remove labels.
 
 ### Pull Requests {#pull-requests}
 
@@ -138,8 +132,7 @@ issues.
   unusable, or a downed service that severely impacts development of the Bazel
   project. This includes regressions introduced in a new release that blocks a
   significant number of users, or an incompatible breaking change that was not
-  compliant to the [Breaking
-  Change](https://docs.google.com/document/d/1q5GGRxKrF_mnwtaPKI487P8OdDRh2nN7jX6U-FXnHL0/edit?pli=1#heading=h.ceof6vpkb3ik)
+  compliant to the [Breaking Change](https://docs.google.com/document/d/1q5GGRxKrF_mnwtaPKI487P8OdDRh2nN7jX6U-FXnHL0/edit?pli=1#heading=h.ceof6vpkb3ik)
   policy. No practical workaround exists.
 * [**P1**](https://github.com/bazelbuild/bazel/labels/P1) - Critical defect or
   feature which should be addressed in the next release, or a serious issue that
diff --git a/versions/8.0.1/contribute/naming.mdx b/versions/8.0.1/contribute/naming.mdx
index 61b3dcb6..c1e87ad9 100644
--- a/versions/8.0.1/contribute/naming.mdx
+++ b/versions/8.0.1/contribute/naming.mdx
@@ -4,8 +4,7 @@ title: 'Naming a Bazel related project'
 
 First, thank you for contributing to the Bazel ecosystem! Please reach out to
 the Bazel community on the
-[bazel-discuss mailing list](https://groups.google.com/forum/#!forum/bazel-discuss
-) to share your project and its suggested name.
+[bazel-discuss mailing list](https://groups.google.com/forum/#!forum/bazel-discuss) to share your project and its suggested name.
 
 If you are building a Bazel related tool or sharing your Skylark rules,
 we recommend following these guidelines for the name of your project:
diff --git a/versions/8.0.1/contribute/patch-acceptance.mdx b/versions/8.0.1/contribute/patch-acceptance.mdx
index 10efe92f..74253795 100644
--- a/versions/8.0.1/contribute/patch-acceptance.mdx
+++ b/versions/8.0.1/contribute/patch-acceptance.mdx
@@ -11,29 +11,24 @@ code base.
    need a corresponding issue for tracking.
 1. If you're proposing significant changes, write a
    [design document](/versions/8.0.1/contribute/design-documents).
-1. Ensure you've signed a [Contributor License
-   Agreement](https://cla.developers.google.com).
+1. Ensure you've signed a [Contributor License Agreement](https://cla.developers.google.com).
 1. Prepare a git commit that implements the feature. Don't forget to add tests
    and update the documentation. If your change has user-visible effects, please
    [add release notes](/versions/8.0.1/contribute/release-notes). If it is an incompatible change,
    read the [guide for rolling out breaking changes](/versions/8.0.1/contribute/breaking-changes).
 1. Create a pull request on
    [GitHub](https://github.com/bazelbuild/bazel/pulls). If you're new to GitHub,
-   read [about pull
-   requests](https://help.github.com/articles/about-pull-requests/). Note that
+   read [about pull requests](https://help.github.com/articles/about-pull-requests/). Note that
    we restrict permissions to create branches on the main Bazel repository, so
-   you will need to push your commit to [your own fork of the
-   repository](https://help.github.com/articles/working-with-forks/).
+   you will need to push your commit to [your own fork of the repository](https://help.github.com/articles/working-with-forks/).
 1. A Bazel maintainer should assign you a reviewer within two business days
    (excluding holidays in the USA and Germany). If you aren't assigned a
    reviewer in that time, you can request one by emailing
-   [bazel-discuss@googlegroups.com]
-   (mailto:bazel-discuss@googlegroups.com).
+   [bazel-discuss@googlegroups.com](mailto:bazel-discuss@googlegroups.com).
 1. Work with the reviewer to complete a code review. For each change, create a
    new commit and push it to make changes to your pull request. If the review
    takes too long (for instance, if the reviewer is unresponsive), send an email to
-   [bazel-discuss@googlegroups.com]
-   (mailto:bazel-discuss@googlegroups.com).
+   [bazel-discuss@googlegroups.com](mailto:bazel-discuss@googlegroups.com).
 1. After your review is complete, a Bazel maintainer applies your patch to
    Google's internal version control system.
 
diff --git a/versions/8.0.1/contribute/release-notes.mdx b/versions/8.0.1/contribute/release-notes.mdx
index e29106e5..1f782fcd 100644
--- a/versions/8.0.1/contribute/release-notes.mdx
+++ b/versions/8.0.1/contribute/release-notes.mdx
@@ -16,8 +16,7 @@ the release announcement.
 * If the change adds / removes / changes Bazel in a user-visible way, then it
   may be advantageous to mention it.
 
-If the change is significant, follow the [design document
-policy](/versions/8.0.1/contribute/design-documents) first.
+If the change is significant, follow the [design document policy](/versions/8.0.1/contribute/design-documents) first.
 
 ## Guidelines {#guidelines}
 
@@ -60,10 +59,8 @@ change is about.
 
 ## Process {#process}
 
-As part of the [release
-process](https://github.com/bazelbuild/continuous-integration/blob/master/docs/release-playbook.md),
-we collect the `RELNOTES` tags of every commit. We copy everything in a [Google
-Doc](https://docs.google.com/document/d/1wDvulLlj4NAlPZamdlEVFORks3YXJonCjyuQMUQEmB0/edit)
+As part of the [release process](https://github.com/bazelbuild/continuous-integration/blob/master/docs/release-playbook.md),
+we collect the `RELNOTES` tags of every commit. We copy everything in a [Google Doc](https://docs.google.com/document/d/1wDvulLlj4NAlPZamdlEVFORks3YXJonCjyuQMUQEmB0/edit)
 where we review, edit, and organize the notes.
 
 The release manager sends an email to the
@@ -71,6 +68,4 @@ The release manager sends an email to the
 Bazel contributors are invited to contribute to the document and make sure
 their changes are correctly reflected in the announcement.
 
-Later, the announcement will be submitted to the [Bazel
-blog](https://blog.bazel.build/), using the [bazel-blog
-repository](https://github.com/bazelbuild/bazel-blog/tree/master/_posts).
+Later, the announcement will be submitted to the [Bazel blog](https://blog.bazel.build/), using the [bazel-blog repository](https://github.com/bazelbuild/bazel-blog/tree/master/_posts).
diff --git a/versions/8.0.1/contribute/statemachine-guide.mdx b/versions/8.0.1/contribute/statemachine-guide.mdx
index 47a5e081..ba9e86c1 100644
--- a/versions/8.0.1/contribute/statemachine-guide.mdx
+++ b/versions/8.0.1/contribute/statemachine-guide.mdx
@@ -172,8 +172,7 @@ instead, batches[^4] as many lookups as possible before doing so. The value
 might not be immediately available, for example, requiring a Skyframe restart,
 so the caller specifies what to do with the resulting value using a callback.
 
-The `StateMachine` processor ([`Driver`s and bridging to
-SkyFrame](#drivers-and-bridging)) guarantees that the value is available before
+The `StateMachine` processor ([`Driver`s and bridging to SkyFrame](#drivers-and-bridging)) guarantees that the value is available before
 the next state begins. An example follows.
 
 ```
@@ -284,8 +283,7 @@ and solutions to certain control flow problems.
 ### Sequential states
 
 This is the most common and straightforward control flow pattern. An example of
-this is shown in [Stateful computations inside
-`SkyKeyComputeState`](#stateful-computations).
+this is shown in [Stateful computations inside `SkyKeyComputeState`](#stateful-computations).
 
 ### Branching
 
@@ -545,8 +543,7 @@ section describes the propagation of data values.
 
 ### Implementing `Tasks.lookUp` callbacks
 
-There’s an example of implementing a `Tasks.lookUp` callback in [SkyValue
-lookups](#skyvalue-lookups). This section provides rationale and suggests
+There’s an example of implementing a `Tasks.lookUp` callback in [SkyValue lookups](#skyvalue-lookups). This section provides rationale and suggests
 approaches for handling multiple SkyValues.
 
 #### `Tasks.lookUp` callbacks {#tasks-lookup-callbacks}
@@ -710,8 +707,7 @@ class BarProducer implements StateMachine {
 Tip: It would be tempting to use the more concise signature void `accept(Bar
 value)` rather than the stuttery `void acceptBarValue(Bar value)` above.
 However, `Consumer` is a common overload of `void accept(Bar value)`,
-so doing this often leads to violations of the [Overloads: never
-split](https://google.github.io/styleguide/javaguide.html#s3.4.2-ordering-class-contents)
+so doing this often leads to violations of the [Overloads: never split](https://google.github.io/styleguide/javaguide.html#s3.4.2-ordering-class-contents)
 style-guide rule.
 
 Tip: Using a custom `ResultSink` type instead of a generic one from
@@ -774,14 +770,11 @@ pattern after accepting output from either a subtask or SkyValue lookup.
 Note that the implementation of `acceptBarError` eagerly forwards the result to
 the `Caller.ResultSink`, as required by [Error bubbling](#error-bubbling).
 
-Alternatives for top-level `StateMachine`s are described in [`Driver`s and
-bridging to SkyFunctions](#drivers-and-bridging).
+Alternatives for top-level `StateMachine`s are described in [`Driver`s and bridging to SkyFunctions](#drivers-and-bridging).
 
 ### Error handling {#error-handling}
 
-There's a couple of examples of error handling already in [`Tasks.lookUp`
-callbacks](#tasks-lookup-callbacks) and [Propagating values between
-`StateMachines`](#propagating-values). Exceptions, other than
+There's a couple of examples of error handling already in [`Tasks.lookUp` callbacks](#tasks-lookup-callbacks) and [Propagating values between `StateMachines`](#propagating-values). Exceptions, other than
 `InterruptedException` are not thrown, but instead passed around through
 callbacks as values. Such callbacks often have exclusive-or semantics, with
 exactly one of a value or error being passed.
@@ -1184,8 +1177,7 @@ states. Where it is possible, local stack `step` variables are young generation
 variables and efficiently GC'd.
 
 For `StateMachine` variables, breaking things down into subtasks and following
-the recommended pattern for [Propagating values between
-`StateMachine`s](#propagating-values) is also helpful. Observe that when
+the recommended pattern for [Propagating values between `StateMachine`s](#propagating-values) is also helpful. Observe that when
 following the pattern, only child `StateMachine`s have references to parent
 `StateMachine`s and not vice versa. This means that as children complete and
 update the parents using result callbacks, the children naturally fall out of
@@ -1207,8 +1199,7 @@ potentially reflecting local behavior.
 
 ### Concurrency tree diagram {#concurrency-tree-diagram}
 
-The following is an alternative view of the diagram in [Structured
-concurrency](#structured-concurrency) that better depicts the tree structure.
+The following is an alternative view of the diagram in [Structured concurrency](#structured-concurrency) that better depicts the tree structure.
 The blocks form a small tree.
 
 ![Structured Concurrency 3D](/versions/8.0.1/contribute/images/structured-concurrency-3d.svg)
diff --git a/versions/8.0.1/docs/android-instrumentation-test.mdx b/versions/8.0.1/docs/android-instrumentation-test.mdx
index 07975fd6..bd620635 100644
--- a/versions/8.0.1/docs/android-instrumentation-test.mdx
+++ b/versions/8.0.1/docs/android-instrumentation-test.mdx
@@ -2,8 +2,7 @@
 title: 'Android Instrumentation Tests'
 ---
 
-_If you're new to Bazel, start with the [Building Android with
-Bazel](/versions/8.0.1/start/android-app ) tutorial._
+_If you're new to Bazel, start with the [Building Android with Bazel](/versions/8.0.1/start/android-app) tutorial._
 
 ![Running Android instrumentation tests in parallel](/versions/8.0.1/docs/images/android_test.gif "Android instrumentation test")
 
@@ -18,9 +17,7 @@ emulators in a sandbox, ensuring that tests always run from a clean state. Each
 test gets an isolated emulator instance, allowing tests to run in parallel
 without passing states between them.
 
-For more information on Android instrumentation tests, check out the [Android
-developer
-documentation](https://developer.android.com/training/testing/unit-testing/instrumented-unit-tests.html).
+For more information on Android instrumentation tests, check out the [Android developer documentation](https://developer.android.com/training/testing/unit-testing/instrumented-unit-tests.html).
 
 Please file issues in the [GitHub issue tracker](https://github.com/bazelbuild/bazel/issues).
 
@@ -58,8 +55,7 @@ This results in output similar to the following:
 release 4.1.0
 ```
 
-- **KVM**. Bazel requires emulators to have [hardware
-  acceleration](https://developer.android.com/studio/run/emulator-acceleration.html#accel-check)
+- **KVM**. Bazel requires emulators to have [hardware acceleration](https://developer.android.com/studio/run/emulator-acceleration.html#accel-check)
   with KVM on Linux. You can follow these
   [installation instructions](https://help.ubuntu.com/community/KVM/Installation)
   for Ubuntu.
@@ -173,11 +169,9 @@ The main attributes of the rule `android_instrumentation_test` are:
 
 - `target_device`: An `android_device` target. This target describes the
   specifications of the Android emulator which Bazel uses to create, launch and
-  run the tests. See the [section on choosing an Android
-  device](#android-device-target) for more information.
+  run the tests. See the [section on choosing an Android device](#android-device-target) for more information.
 
-The test app's `AndroidManifest.xml` must include [an ``
-tag](https://developer.android.com/studio/test/#configure_instrumentation_manifest_settings).
+The test app's `AndroidManifest.xml` must include [an `` tag](https://developer.android.com/studio/test/#configure_instrumentation_manifest_settings).
 This tag must specify the attributes for the **package of the target app** and
 the **fully qualified class name of the instrumentation test runner**,
 `androidx.test.runner.AndroidJUnitRunner`.
@@ -214,8 +208,7 @@ repositories:
 - `@androidsdk`: The Android SDK. Download this through Android Studio.
 
 - `@android_test_support`: Hosts the test runner, emulator launcher, and
-  `android_device` targets. You can find the [latest release
-  here](https://github.com/android/android-test/releases).
+  `android_device` targets. You can find the [latest release here](https://github.com/android/android-test/releases).
 
 Enable these dependencies by adding the following lines to your `WORKSPACE`
 file:
@@ -240,8 +233,7 @@ android_test_repositories()
 
 ## Maven dependencies {#maven-dependencies}
 
-For managing dependencies on Maven artifacts from repositories, such as [Google
-Maven](https://maven.google.com) or [Maven Central](https://central.maven.org),
+For managing dependencies on Maven artifacts from repositories, such as [Google Maven](https://maven.google.com) or [Maven Central](https://central.maven.org),
 you should use a Maven resolver, such as
 [`rules_jvm_external`](https://github.com/bazelbuild/rules_jvm_external).
 
@@ -370,8 +362,7 @@ the device/emulator listed in `adb devices`.
 
 ## Sample projects {#sample-projects}
 
-If you are looking for canonical project samples, see the [Android testing
-samples](https://github.com/googlesamples/android-testing#experimental-bazel-support)
+If you are looking for canonical project samples, see the [Android testing samples](https://github.com/googlesamples/android-testing#experimental-bazel-support)
 for projects using Espresso and UIAutomator.
 
 ## Espresso setup {#espresso-setup}
@@ -560,8 +551,7 @@ API_LEVELS = [
 
 ## Known issues {#known-issues}
 
-- [Forked adb server processes are not terminated after
-  tests](https://github.com/bazelbuild/bazel/issues/4853)
+- [Forked adb server processes are not terminated after tests](https://github.com/bazelbuild/bazel/issues/4853)
 - While APK building works on all platforms (Linux, macOS, Windows), testing
   only works on Linux.
 - Even with `--config=local_adb`, users still need to specify
diff --git a/versions/8.0.1/docs/android-ndk.mdx b/versions/8.0.1/docs/android-ndk.mdx
index cd3af2d5..f05a2451 100644
--- a/versions/8.0.1/docs/android-ndk.mdx
+++ b/versions/8.0.1/docs/android-ndk.mdx
@@ -2,8 +2,7 @@
 title: 'Using the Android Native Development Kit with Bazel'
 ---
 
-_If you're new to Bazel, please start with the [Building Android with
-Bazel](/versions/8.0.1/start/android-app ) tutorial._
+_If you're new to Bazel, please start with the [Building Android with Bazel](/versions/8.0.1/start/android-app) tutorial._
 
 ## Overview {#overview}
 
@@ -31,8 +30,7 @@ android_ndk_repository(
 )
 ```
 
-For more information about the `android_ndk_repository` rule, see the [Build
-Encyclopedia entry](/versions/8.0.1/reference/be/android#android_ndk_repository).
+For more information about the `android_ndk_repository` rule, see the [Build Encyclopedia entry](/versions/8.0.1/reference/be/android#android_ndk_repository).
 
 If you're using a recent version of the Android NDK (r22 and beyond), use the
 Starlark implementation of `android_ndk_repository`.
@@ -101,13 +99,11 @@ META-INF/MANIFEST.MF
 
 Bazel compiles all of the cc_libraries into a single shared object (`.so`) file,
 targeted for the `armeabi-v7a` ABI by default. To change this or build for
-multiple ABIs at the same time, see the section on [configuring the target
-ABI](#configuring-target-abi).
+multiple ABIs at the same time, see the section on [configuring the target ABI](#configuring-target-abi).
 
 ## Example setup {#example-setup}
 
-This example is available in the [Bazel examples
-repository](https://github.com/bazelbuild/examples/tree/master/android/ndk).
+This example is available in the [Bazel examples repository](https://github.com/bazelbuild/examples/tree/master/android/ndk).
 
 In the `BUILD.bazel` file, three targets are defined with the `android_binary`,
 `android_library`, and `cc_library` rules.
diff --git a/versions/8.0.1/docs/bazel-and-android.mdx b/versions/8.0.1/docs/bazel-and-android.mdx
index 45ca8500..db5f7513 100644
--- a/versions/8.0.1/docs/bazel-and-android.mdx
+++ b/versions/8.0.1/docs/bazel-and-android.mdx
@@ -10,7 +10,7 @@ Android projects with Bazel.
 
 The following resources will help you work with Bazel on Android projects:
 
-*  [Tutorial: Building an Android app](/versions/8.0.1/start/android-app ). This
+*  [Tutorial: Building an Android app](/versions/8.0.1/start/android-app). This
    tutorial is a good place to start learning about Bazel commands and concepts,
    and how to build Android apps with Bazel.
 *  [Codelab: Building Android Apps with Bazel](https://developer.android.com/codelabs/bazel-android-intro#0).
diff --git a/versions/8.0.1/docs/configurable-attributes.mdx b/versions/8.0.1/docs/configurable-attributes.mdx
index 2dd09964..a13cd763 100644
--- a/versions/8.0.1/docs/configurable-attributes.mdx
+++ b/versions/8.0.1/docs/configurable-attributes.mdx
@@ -2,8 +2,7 @@
 title: 'Configurable Build Attributes'
 ---
 
-**_Configurable attributes_**, commonly known as [`select()`](
-/reference/be/functions#select), is a Bazel feature that lets users toggle the values
+**_Configurable attributes_**, commonly known as [`select()`](/versions/8.0.1/reference/be/functions#select), is a Bazel feature that lets users toggle the values
 of build rule attributes at the command line.
 
 This can be used, for example, for a multiplatform library that automatically
@@ -407,8 +406,7 @@ sh_library(
 )
 ```
 
-If you need a `select` to match when multiple conditions match, consider [AND
-chaining](#and-chaining).
+If you need a `select` to match when multiple conditions match, consider [AND chaining](#and-chaining).
 
 ## OR chaining {#or-chaining}
 
diff --git a/versions/8.0.1/docs/images/a_b_a_c.svg b/versions/8.0.1/docs/images/a_b_a_c.svg
new file mode 100644
index 00000000..d38be075
--- /dev/null
+++ b/versions/8.0.1/docs/images/a_b_a_c.svg
@@ -0,0 +1,42 @@
+
+
+
+
+
+
+G
+
+
+
+a
+
+a
+
+
+
+b
+
+b
+
+
+
+a->b
+
+
+
+
+
+c
+
+c
+
+
+
+a->c
+
+
+
+
+
+
diff --git a/versions/8.0.1/docs/images/a_b_c.svg b/versions/8.0.1/docs/images/a_b_c.svg
new file mode 100644
index 00000000..acd948ab
--- /dev/null
+++ b/versions/8.0.1/docs/images/a_b_c.svg
@@ -0,0 +1,41 @@
+
+
+
+
+
+
+G
+
+
+
+a
+
+a
+
+
+
+b
+
+b
+
+
+
+a->b
+
+
+
+
+
+c
+
+c
+
+
+
+b->c
+
+
+
+
+
diff --git a/versions/8.0.1/docs/images/a_b_c_ac.svg b/versions/8.0.1/docs/images/a_b_c_ac.svg
new file mode 100644
index 00000000..b099c53e
--- /dev/null
+++ b/versions/8.0.1/docs/images/a_b_c_ac.svg
@@ -0,0 +1,47 @@
+
+
+
+
+
+
+G
+
+
+
+a
+
+a
+
+
+
+b
+
+b
+
+
+
+a->b
+
+
+
+
+
+c
+
+c
+
+
+
+a->c
+
+
+
+
+
+b->c
+
+
+
+
+
diff --git a/versions/8.0.1/docs/images/ab_c.svg b/versions/8.0.1/docs/images/ab_c.svg
new file mode 100644
index 00000000..bcc4563f
--- /dev/null
+++ b/versions/8.0.1/docs/images/ab_c.svg
@@ -0,0 +1,36 @@
+
+
+
+
+
+
+G
+
+
+
+a
+
+a
+
+
+
+b
+
+b
+
+
+
+a->b
+
+
+
+
+
+c
+
+c
+
+
+
+
diff --git a/versions/8.0.1/docs/images/allpaths.svg b/versions/8.0.1/docs/images/allpaths.svg
new file mode 100644
index 00000000..47d0ee33
--- /dev/null
+++ b/versions/8.0.1/docs/images/allpaths.svg
@@ -0,0 +1,141 @@
+
+
+
+
+
+
+allpaths
+
+
+
+n1
+
+
+
+
+n2
+
+
+
+
+n1->n2
+
+
+
+
+
+n3
+
+
+
+
+n2->n3
+
+
+
+
+
+n10
+
+
+
+
+n2->n10
+
+
+
+
+
+n3->n10
+
+
+
+
+
+n4
+
+E
+
+
+
+n5
+
+
+
+
+n6
+
+
+
+
+n5->n6
+
+
+
+
+
+n6->n4
+
+
+
+
+
+n9
+
+
+
+
+n6->n9
+
+
+
+
+
+n7
+
+S1
+
+
+
+n7->n2
+
+
+
+
+
+n7->n5
+
+
+
+
+
+n8
+
+S2
+
+
+
+n8->n6
+
+
+
+
+
+n10->n4
+
+
+
+
+
+n11
+
+
+
+
+n10->n11
+
+
+
+
+
diff --git a/versions/8.0.1/docs/images/android_instrumentation_test.png b/versions/8.0.1/docs/images/android_instrumentation_test.png
new file mode 100644
index 00000000..e4534fbd
Binary files /dev/null and b/versions/8.0.1/docs/images/android_instrumentation_test.png differ
diff --git a/versions/8.0.1/docs/images/android_ndk.png b/versions/8.0.1/docs/images/android_ndk.png
new file mode 100644
index 00000000..76b63cb3
Binary files /dev/null and b/versions/8.0.1/docs/images/android_ndk.png differ
diff --git a/versions/8.0.1/docs/images/android_tutorial_app.png b/versions/8.0.1/docs/images/android_tutorial_app.png
new file mode 100644
index 00000000..076be5b9
Binary files /dev/null and b/versions/8.0.1/docs/images/android_tutorial_app.png differ
diff --git a/versions/8.0.1/docs/images/android_tutorial_before.png b/versions/8.0.1/docs/images/android_tutorial_before.png
new file mode 100644
index 00000000..8e41d419
Binary files /dev/null and b/versions/8.0.1/docs/images/android_tutorial_before.png differ
diff --git a/versions/8.0.1/docs/images/bep-graph.png b/versions/8.0.1/docs/images/bep-graph.png
new file mode 100644
index 00000000..82da6715
Binary files /dev/null and b/versions/8.0.1/docs/images/bep-graph.png differ
diff --git a/versions/8.0.1/docs/images/bep-graph.svg b/versions/8.0.1/docs/images/bep-graph.svg
new file mode 100644
index 00000000..62b1480f
--- /dev/null
+++ b/versions/8.0.1/docs/images/bep-graph.svg
@@ -0,0 +1,4 @@
+
+
+
+
diff --git a/versions/8.0.1/docs/images/cpp-tutorial-stage1.png b/versions/8.0.1/docs/images/cpp-tutorial-stage1.png
new file mode 100644
index 00000000..c85fb303
Binary files /dev/null and b/versions/8.0.1/docs/images/cpp-tutorial-stage1.png differ
diff --git a/versions/8.0.1/docs/images/cpp-tutorial-stage2.png b/versions/8.0.1/docs/images/cpp-tutorial-stage2.png
new file mode 100644
index 00000000..80e202c9
Binary files /dev/null and b/versions/8.0.1/docs/images/cpp-tutorial-stage2.png differ
diff --git a/versions/8.0.1/docs/images/cpp-tutorial-stage3.png b/versions/8.0.1/docs/images/cpp-tutorial-stage3.png
new file mode 100644
index 00000000..54d82f31
Binary files /dev/null and b/versions/8.0.1/docs/images/cpp-tutorial-stage3.png differ
diff --git a/versions/8.0.1/docs/images/deps.svg b/versions/8.0.1/docs/images/deps.svg
new file mode 100644
index 00000000..4354222a
--- /dev/null
+++ b/versions/8.0.1/docs/images/deps.svg
@@ -0,0 +1,101 @@
+
+
+
+
+
+
+G1
+
+
+
+r1
+
+rule
+
+
+
+s1
+
+in
+
+
+
+r1->s1
+
+
+
+
+
+s2
+
+in
+
+
+
+r1->s2
+
+
+
+
+
+s3
+
+in
+
+
+
+r1->s3
+
+
+
+
+
+r2
+
+rule
+
+
+
+r2->r1
+
+
+
+
+
+s4
+
+in
+
+
+
+r2->s4
+
+
+
+
+
+o1
+
+out
+
+
+
+o1->r1
+
+
+
+
+
+o2
+
+out
+
+
+
+o2->r2
+
+
+
+
+
diff --git a/versions/8.0.1/docs/images/dyn-trace-alldynamic.png b/versions/8.0.1/docs/images/dyn-trace-alldynamic.png
new file mode 100644
index 00000000..fe36b253
Binary files /dev/null and b/versions/8.0.1/docs/images/dyn-trace-alldynamic.png differ
diff --git a/versions/8.0.1/docs/images/dyn-trace-javaconly.png b/versions/8.0.1/docs/images/dyn-trace-javaconly.png
new file mode 100644
index 00000000..2ae41e52
Binary files /dev/null and b/versions/8.0.1/docs/images/dyn-trace-javaconly.png differ
diff --git a/versions/8.0.1/docs/images/e4b-workflow.png b/versions/8.0.1/docs/images/e4b-workflow.png
new file mode 100644
index 00000000..412822da
Binary files /dev/null and b/versions/8.0.1/docs/images/e4b-workflow.png differ
diff --git a/versions/8.0.1/docs/images/e4b-workflow.svg b/versions/8.0.1/docs/images/e4b-workflow.svg
new file mode 100644
index 00000000..1de66e02
--- /dev/null
+++ b/versions/8.0.1/docs/images/e4b-workflow.svg
@@ -0,0 +1,4 @@
+
+
+
+
diff --git a/versions/8.0.1/docs/images/error_example_1.png b/versions/8.0.1/docs/images/error_example_1.png
new file mode 100644
index 00000000..07ba1358
Binary files /dev/null and b/versions/8.0.1/docs/images/error_example_1.png differ
diff --git a/versions/8.0.1/docs/images/error_example_2.png b/versions/8.0.1/docs/images/error_example_2.png
new file mode 100644
index 00000000..861171ee
Binary files /dev/null and b/versions/8.0.1/docs/images/error_example_2.png differ
diff --git a/versions/8.0.1/docs/images/error_example_3.png b/versions/8.0.1/docs/images/error_example_3.png
new file mode 100644
index 00000000..dc16eec4
Binary files /dev/null and b/versions/8.0.1/docs/images/error_example_3.png differ
diff --git a/versions/8.0.1/docs/images/error_example_4.png b/versions/8.0.1/docs/images/error_example_4.png
new file mode 100644
index 00000000..84383e63
Binary files /dev/null and b/versions/8.0.1/docs/images/error_example_4.png differ
diff --git a/versions/8.0.1/docs/images/graph_ex_1.svg b/versions/8.0.1/docs/images/graph_ex_1.svg
new file mode 100644
index 00000000..dd7427f4
--- /dev/null
+++ b/versions/8.0.1/docs/images/graph_ex_1.svg
@@ -0,0 +1,131 @@
+
+
+
+
+
+
+mygraph
+
+
+
+//net/proto_compiler:protocol-compiler
+
+//net/proto_compiler:protocol-compiler
+
+
+
+//net/proto_compiler:util
+
+//net/proto_compiler:util
+
+
+
+//net/proto_compiler:protocol-compiler->//net/proto_compiler:util
+
+
+
+
+
+//net/proto_compiler:protocol-compiler-lib
+
+//net/proto_compiler:protocol-compiler-lib
+
+
+
+//net/proto_compiler:protocol-compiler->//net/proto_compiler:protocol-compiler-lib
+
+
+
+
+
+//net/proto2/bridge/public:compiler_upgrader
+
+//net/proto2/bridge/public:compiler_upgrader
+
+
+
+//net/proto_compiler:protocol-compiler->//net/proto2/bridge/public:compiler_upgrader
+
+
+
+
+
+//net/proto_compiler:parser
+
+//net/proto_compiler:parser
+
+
+
+//net/proto_compiler:util->//net/proto_compiler:parser
+
+
+
+
+
+//net/proto_compiler:proto-min-lib
+
+//net/proto_compiler:proto-min-lib
+
+
+
+//net/proto_compiler:protocol-compiler-lib->//net/proto_compiler:proto-min-lib
+
+
+
+
+
+//net/proto_compiler:protocol-compiler-lib->//net/proto_compiler:parser
+
+
+
+
+
+//net/proto2/bridge/internal:compiler_upgrader
+
+//net/proto2/bridge/internal:compiler_upgrader
+
+
+
+//net/proto2/bridge/public:compiler_upgrader->//net/proto2/bridge/internal:compiler_upgrader
+
+
+
+
+
+//net/proto_compiler:proto-min-lib->//net/proto_compiler:parser
+
+
+
+
+
+//util/regexp:regexp
+
+//util/regexp:regexp
+
+
+
+//net/proto_compiler:proto-min-lib->//util/regexp:regexp
+
+
+
+
+
+//net/proto_compiler:parser->//util/regexp:regexp
+
+
+
+
+
+//net/proto2/bridge/internal:compiler_upgrader->//net/proto2/bridge/public:compiler_upgrader
+
+
+
+
+
+//net/proto2/bridge/internal:compiler_upgrader->//net/proto_compiler:parser
+
+
+
+
+
diff --git a/versions/8.0.1/docs/images/graph_hello-world.svg b/versions/8.0.1/docs/images/graph_hello-world.svg
new file mode 100644
index 00000000..93b61444
--- /dev/null
+++ b/versions/8.0.1/docs/images/graph_hello-world.svg
@@ -0,0 +1,70 @@
+
+
+
+
+
+
+mygraph
+
+
+//main:hello-world
+
+//main:hello-world
+
+
+//main:hello-time
+
+//main:hello-time
+
+
+//main:hello-world->//main:hello-time
+
+
+
+
+//main:hello-world.cc
+
+//main:hello-world.cc
+
+
+//main:hello-world->//main:hello-world.cc
+
+
+
+
+//lib:hello-greet
+
+//lib:hello-greet
+
+
+//main:hello-world->//lib:hello-greet
+
+
+
+
+//main:hello-time.cc\n//main:hello-time.h
+
+//main:hello-time.cc
+//main:hello-time.h
+
+
+//main:hello-time->//main:hello-time.cc\n//main:hello-time.h
+
+
+
+
+//lib:hello-greet.cc\n//lib:hello-greet.h
+
+//lib:hello-greet.cc
+//lib:hello-greet.h
+
+
+//lib:hello-greet->//lib:hello-greet.cc\n//lib:hello-greet.h
+
+
+
+
+
diff --git a/versions/8.0.1/docs/images/json-trace-profile-network-usage.png b/versions/8.0.1/docs/images/json-trace-profile-network-usage.png
new file mode 100644
index 00000000..8a7500a6
Binary files /dev/null and b/versions/8.0.1/docs/images/json-trace-profile-network-usage.png differ
diff --git a/versions/8.0.1/docs/images/json-trace-profile-system-load-average.png b/versions/8.0.1/docs/images/json-trace-profile-system-load-average.png
new file mode 100644
index 00000000..e71b420c
Binary files /dev/null and b/versions/8.0.1/docs/images/json-trace-profile-system-load-average.png differ
diff --git a/versions/8.0.1/docs/images/json-trace-profile-workers-memory-usage.png b/versions/8.0.1/docs/images/json-trace-profile-workers-memory-usage.png
new file mode 100644
index 00000000..806505f0
Binary files /dev/null and b/versions/8.0.1/docs/images/json-trace-profile-workers-memory-usage.png differ
diff --git a/versions/8.0.1/docs/images/json-trace-profile.png b/versions/8.0.1/docs/images/json-trace-profile.png
new file mode 100644
index 00000000..538382b2
Binary files /dev/null and b/versions/8.0.1/docs/images/json-trace-profile.png differ
diff --git a/versions/8.0.1/docs/images/mobile-install-performance.svg b/versions/8.0.1/docs/images/mobile-install-performance.svg
new file mode 100644
index 00000000..b139d658
--- /dev/null
+++ b/versions/8.0.1/docs/images/mobile-install-performance.svg
@@ -0,0 +1,86 @@
+
+
+
+  
+    
+      
+    
+  
+  
+  
+    Build times
+  
+  
+    
+    
+      
+      
+        adb install
+      
+      
+    
+    
+      
+      
+        mobile-install
+      
+      
+    
+  
+  
+    
+    
+      
+        
+        
+        
+        
+        
+      
+      
+        
+        
+        
+        
+        
+        
+      
+      
+        
+      
+    
+    
+    
+      
+        Google Maps
+      
+      
+        Google+
+      
+      
+        YouTube
+      
+      
+        0
+      
+      
+        75
+      
+      
+        150
+      
+      
+        225
+      
+      
+        300
+      
+    
+  
+  
+    
+      Seconds
+    
+  
+  
+
diff --git a/versions/8.0.1/docs/images/namedsetoffiles-bep-graph.png b/versions/8.0.1/docs/images/namedsetoffiles-bep-graph.png
new file mode 100644
index 00000000..ea1e10cc
Binary files /dev/null and b/versions/8.0.1/docs/images/namedsetoffiles-bep-graph.png differ
diff --git a/versions/8.0.1/docs/images/out-ranked.svg b/versions/8.0.1/docs/images/out-ranked.svg
new file mode 100644
index 00000000..07e96804
--- /dev/null
+++ b/versions/8.0.1/docs/images/out-ranked.svg
@@ -0,0 +1,71 @@
+
+
+
+
+
+
+mygraph
+
+
+
+//a:a
+
+//a:a
+
+
+
+//a:a.cc
+
+//a:a.cc
+
+
+
+//a:a->//a:a.cc
+
+
+
+
+
+//b:b
+
+//b:b
+
+
+
+//b:b->//a:a
+
+
+
+
+
+//b:b.cc
+
+//b:b.cc
+
+
+
+//b:b->//b:b.cc
+
+
+
+
+
+//c:c
+
+//c:c
+
+
+
+//c:c->//a:a
+
+
+
+
+
+//c:c->//b:b
+
+
+
+
+
diff --git a/versions/8.0.1/docs/images/rbe-ci-1.png b/versions/8.0.1/docs/images/rbe-ci-1.png
new file mode 100644
index 00000000..fbe76a85
Binary files /dev/null and b/versions/8.0.1/docs/images/rbe-ci-1.png differ
diff --git a/versions/8.0.1/docs/images/rbe-ci-2.png b/versions/8.0.1/docs/images/rbe-ci-2.png
new file mode 100644
index 00000000..07611889
Binary files /dev/null and b/versions/8.0.1/docs/images/rbe-ci-2.png differ
diff --git a/versions/8.0.1/docs/images/somepath1.svg b/versions/8.0.1/docs/images/somepath1.svg
new file mode 100644
index 00000000..5e5f8812
--- /dev/null
+++ b/versions/8.0.1/docs/images/somepath1.svg
@@ -0,0 +1,141 @@
+
+
+
+
+
+
+somepath1
+
+
+
+n1
+
+
+
+
+n2
+
+
+
+
+n1->n2
+
+
+
+
+
+n3
+
+
+
+
+n2->n3
+
+
+
+
+
+n10
+
+
+
+
+n2->n10
+
+
+
+
+
+n3->n10
+
+
+
+
+
+n4
+
+E
+
+
+
+n5
+
+
+
+
+n6
+
+
+
+
+n5->n6
+
+
+
+
+
+n6->n4
+
+
+
+
+
+n9
+
+
+
+
+n6->n9
+
+
+
+
+
+n7
+
+S1
+
+
+
+n7->n2
+
+
+
+
+
+n7->n5
+
+
+
+
+
+n8
+
+S2
+
+
+
+n8->n6
+
+
+
+
+
+n10->n4
+
+
+
+
+
+n11
+
+
+
+
+n10->n11
+
+
+
+
+
diff --git a/versions/8.0.1/docs/images/somepath2.svg b/versions/8.0.1/docs/images/somepath2.svg
new file mode 100644
index 00000000..911f2c9b
--- /dev/null
+++ b/versions/8.0.1/docs/images/somepath2.svg
@@ -0,0 +1,141 @@
+
+
+
+
+
+
+somepath2
+
+
+
+n1
+
+
+
+
+n2
+
+
+
+
+n1->n2
+
+
+
+
+
+n3
+
+
+
+
+n2->n3
+
+
+
+
+
+n10
+
+
+
+
+n2->n10
+
+
+
+
+
+n3->n10
+
+
+
+
+
+n4
+
+E
+
+
+
+n5
+
+
+
+
+n6
+
+
+
+
+n5->n6
+
+
+
+
+
+n6->n4
+
+
+
+
+
+n9
+
+
+
+
+n6->n9
+
+
+
+
+
+n7
+
+S1
+
+
+
+n7->n2
+
+
+
+
+
+n7->n5
+
+
+
+
+
+n8
+
+S2
+
+
+
+n8->n6
+
+
+
+
+
+n10->n4
+
+
+
+
+
+n11
+
+
+
+
+n10->n11
+
+
+
+
+
diff --git a/versions/8.0.1/docs/images/targets.svg b/versions/8.0.1/docs/images/targets.svg
new file mode 100644
index 00000000..82f47e74
--- /dev/null
+++ b/versions/8.0.1/docs/images/targets.svg
@@ -0,0 +1,113 @@
+
+
+
+
+
+
+G1
+
+
+
+Target
+
+Target
+
+
+
+Rule
+
+Rule
+
+
+
+Target->Rule
+
+
+
+
+
+File
+
+File
+
+
+
+Target->File
+
+
+
+
+
+Package group
+
+Package group
+
+
+
+Target->Package group
+
+
+
+
+
+cc_library
+
+cc_library
+
+
+
+Rule->cc_library
+
+
+
+
+
+java_test
+
+java_test
+
+
+
+Rule->java_test
+
+
+
+
+
+...
+
+...
+
+
+
+Rule->...
+
+
+
+
+
+Source
+
+Source
+
+
+
+File->Source
+
+
+
+
+
+Generated
+
+Generated
+
+
+
+File->Generated
+
+
+
+
+
diff --git a/versions/8.0.1/docs/images/tutorial_java_01.svg b/versions/8.0.1/docs/images/tutorial_java_01.svg
new file mode 100644
index 00000000..2fe72f36
--- /dev/null
+++ b/versions/8.0.1/docs/images/tutorial_java_01.svg
@@ -0,0 +1,29 @@
+
+
+
+
+
+
+mygraph
+
+
+//:ProjectRunner
+
+//:ProjectRunner
+
+
+//:src/main/java/com/example/Greeting.java\n//:src/main/java/com/example/ProjectRunner.java
+
+//:src/main/java/com/example/Greeting.java
+//:src/main/java/com/example/ProjectRunner.java
+
+
+//:ProjectRunner->//:src/main/java/com/example/Greeting.java\n//:src/main/java/com/example/ProjectRunner.java
+
+
+
+
+
diff --git a/versions/8.0.1/docs/images/tutorial_java_02.svg b/versions/8.0.1/docs/images/tutorial_java_02.svg
new file mode 100644
index 00000000..40cbb218
--- /dev/null
+++ b/versions/8.0.1/docs/images/tutorial_java_02.svg
@@ -0,0 +1,48 @@
+
+
+
+
+
+
+mygraph
+
+
+//:ProjectRunner
+
+//:ProjectRunner
+
+
+//:greeter
+
+//:greeter
+
+
+//:ProjectRunner->//:greeter
+
+
+
+
+//:src/main/java/com/example/ProjectRunner.java
+
+//:src/main/java/com/example/ProjectRunner.java
+
+
+//:ProjectRunner->//:src/main/java/com/example/ProjectRunner.java
+
+
+
+
+//:src/main/java/com/example/Greeting.java
+
+//:src/main/java/com/example/Greeting.java
+
+
+//:greeter->//:src/main/java/com/example/Greeting.java
+
+
+
+
+
diff --git a/versions/8.0.1/docs/images/tutorial_java_03.svg b/versions/8.0.1/docs/images/tutorial_java_03.svg
new file mode 100644
index 00000000..7d79041a
--- /dev/null
+++ b/versions/8.0.1/docs/images/tutorial_java_03.svg
@@ -0,0 +1,48 @@
+
+
+
+
+
+
+mygraph
+
+
+//src/main/java/com/example/cmdline:runner
+
+//src/main/java/com/example/cmdline:runner
+
+
+//src/main/java/com/example/cmdline:Runner.java
+
+//src/main/java/com/example/cmdline:Runner.java
+
+
+//src/main/java/com/example/cmdline:runner->//src/main/java/com/example/cmdline:Runner.java
+
+
+
+
+//:greeter
+
+//:greeter
+
+
+//src/main/java/com/example/cmdline:runner->//:greeter
+
+
+
+
+//:src/main/java/com/example/Greeting.java
+
+//:src/main/java/com/example/Greeting.java
+
+
+//:greeter->//:src/main/java/com/example/Greeting.java
+
+
+
+
+
diff --git a/versions/8.0.1/docs/images/workers-clean-chart.png b/versions/8.0.1/docs/images/workers-clean-chart.png
new file mode 100644
index 00000000..63526fc1
Binary files /dev/null and b/versions/8.0.1/docs/images/workers-clean-chart.png differ
diff --git a/versions/8.0.1/docs/images/workers-incremental-chart.png b/versions/8.0.1/docs/images/workers-incremental-chart.png
new file mode 100644
index 00000000..1c62d25c
Binary files /dev/null and b/versions/8.0.1/docs/images/workers-incremental-chart.png differ
diff --git a/versions/8.0.1/docs/images/ws-diamond.png b/versions/8.0.1/docs/images/ws-diamond.png
new file mode 100644
index 00000000..154a7440
Binary files /dev/null and b/versions/8.0.1/docs/images/ws-diamond.png differ
diff --git a/versions/8.0.1/docs/images/ws-line.png b/versions/8.0.1/docs/images/ws-line.png
new file mode 100644
index 00000000..e8bfe7a1
Binary files /dev/null and b/versions/8.0.1/docs/images/ws-line.png differ
diff --git a/versions/8.0.1/docs/images/ws-multiline.png b/versions/8.0.1/docs/images/ws-multiline.png
new file mode 100644
index 00000000..f07b43b1
Binary files /dev/null and b/versions/8.0.1/docs/images/ws-multiline.png differ
diff --git a/versions/8.0.1/docs/sandboxing.mdx b/versions/8.0.1/docs/sandboxing.mdx
index 0c5b59a3..60cfbac7 100644
--- a/versions/8.0.1/docs/sandboxing.mdx
+++ b/versions/8.0.1/docs/sandboxing.mdx
@@ -48,7 +48,7 @@ containers on Linux and `sandbox-exec` on macOS, to constrain the action within
 ## What sandbox strategy to use {#sandboxing-strategies}
 
 You can choose which kind of sandboxing to use, if any, with the
-[strategy flags](user-manual#strategy-options). Using the `sandboxed`
+[strategy flags](/versions/8.0.1/docs/user-manual#strategy-options). Using the `sandboxed`
 strategy makes Bazel pick one of the sandbox implementations listed below,
 preferring an OS-specific sandbox to the less hermetic generic one.
 [Persistent workers](/versions/8.0.1/remote/persistent) run in a generic sandbox if you pass
diff --git a/versions/8.0.1/docs/user-manual.mdx b/versions/8.0.1/docs/user-manual.mdx
index 4a6b407b..10bd498e 100644
--- a/versions/8.0.1/docs/user-manual.mdx
+++ b/versions/8.0.1/docs/user-manual.mdx
@@ -1143,12 +1143,12 @@ during execution can be examined.
 This option causes Bazel's execution phase to print the full command line
 for each command prior to executing it.
 
-
-  >>>>> # //examples/cpp:hello-world [action 'Linking examples/cpp/hello-world']
+```
+  >>>> # //examples/cpp:hello-world [action 'Linking examples/cpp/hello-world']
   (cd /home/johndoe/.cache/bazel/_bazel_johndoe/4c084335afceb392cfbe7c31afee3a9f/bazel && \
     exec env - \
     /usr/bin/gcc -o bazel-out/local-fastbuild/bin/examples/cpp/hello-world -B/usr/bin/ -Wl,-z,relro,-z,now -no-canonical-prefixes -pass-exit-codes -Wl,-S -Wl,@bazel-out/local_linux-fastbuild/bin/examples/cpp/hello-world-2.params)
-

+```
 
 Where possible, commands are printed in a Bourne shell compatible syntax,
 so that they can be easily copied and pasted to a shell command prompt.
diff --git a/versions/8.0.1/extending/auto-exec-groups.mdx b/versions/8.0.1/extending/auto-exec-groups.mdx
index 9c3d0d33..043291ec 100644
--- a/versions/8.0.1/extending/auto-exec-groups.mdx
+++ b/versions/8.0.1/extending/auto-exec-groups.mdx
@@ -27,9 +27,7 @@ doesn't detect that ([the error](#first-error-message) is raised), you can set
 
 If you need to use multiple toolchains on a single execution platform (an action
 uses executable or tools from two or more toolchains), you need to manually
-define [exec_groups][exec_groups] (check
-[When should I use a custom exec_group?][multiple_toolchains_exec_groups]
-section).
+define [exec_groups][exec_groups](check [When should I use a custom exec_group?][multiple_toolchains_exec_groups] section).
 
 ## History {#history}
 
@@ -42,8 +40,7 @@ my_rule = rule(
 )
 ```
 
-Rule `my_rule` registers two toolchain types. This means that the [Toolchain
-Resolution](https://bazel.build/extending/toolchains#toolchain-resolution) used
+Rule `my_rule` registers two toolchain types. This means that the [Toolchain Resolution](https://bazel.build/versions/8.0.1/extending/toolchains#toolchain-resolution) used
 to find an execution platform which supports both toolchain types. The selected
 execution platform was used for each registered action inside the rule, unless
 specified differently with [exec_groups][exec_groups].
diff --git a/versions/8.0.1/extending/concepts.mdx b/versions/8.0.1/extending/concepts.mdx
index 908ba37e..ae782bc1 100644
--- a/versions/8.0.1/extending/concepts.mdx
+++ b/versions/8.0.1/extending/concepts.mdx
@@ -20,16 +20,14 @@ Before learning the more advanced concepts, first:
 ## Macros and rules {#macros-and-rules}
 
 A macro is a function that instantiates rules. Macros come in two flavors:
-[symbolic macros](/versions/8.0.1/extending/macros) (new in Bazel 8) and [legacy
-macros](/versions/8.0.1/extending/legacy-macros). The two flavors of macros are defined
+[symbolic macros](/versions/8.0.1/extending/macros) (new in Bazel 8) and [legacy macros](/versions/8.0.1/extending/legacy-macros). The two flavors of macros are defined
 differently, but behave almost the same from the point of view of a user. A
 macro is useful when a `BUILD` file is getting too repetitive or too complex, as
 it lets you reuse some code. The function is evaluated as soon as the `BUILD`
 file is read. After the evaluation of the `BUILD` file, Bazel has little
 information about macros. If your macro generates a `genrule`, Bazel will
 behave *almost* as if you declared that `genrule` in the `BUILD` file. (The one
-exception is that targets declared in a symbolic macro have [special visibility
-semantics](/versions/8.0.1/extending/macros#visibility): a symbolic macro can hide its internal
+exception is that targets declared in a symbolic macro have [special visibility semantics](/versions/8.0.1/extending/macros#visibility): a symbolic macro can hide its internal
 targets from the rest of the package.)
 
 A [rule](/versions/8.0.1/extending/rules) is more powerful than a macro. It can access Bazel
@@ -76,8 +74,7 @@ they will not be executed.
 ## Creating extensions
 
 * [Create your first macro](/versions/8.0.1/rules/macro-tutorial) in order to reuse some code.
-  Then [learn more about macros](/versions/8.0.1/extending/macros) and [using them to create
-  "custom verbs"](/versions/8.0.1/rules/verbs-tutorial).
+  Then [learn more about macros](/versions/8.0.1/extending/macros) and [using them to create "custom verbs"](/versions/8.0.1/rules/verbs-tutorial).
 
 * [Follow the rules tutorial](/versions/8.0.1/rules/rules-tutorial) to get started with rules.
   Next, you can read more about the [rules concepts](/versions/8.0.1/extending/rules).
@@ -92,8 +89,7 @@ them within reach:
 ## Going further
 
 In addition to [macros](/versions/8.0.1/extending/macros) and [rules](/versions/8.0.1/extending/rules), you
-may want to write [aspects](/versions/8.0.1/extending/aspects) and [repository
-rules](/versions/8.0.1/extending/repo).
+may want to write [aspects](/versions/8.0.1/extending/aspects) and [repository rules](/versions/8.0.1/extending/repo).
 
 * Use [Buildifier](https://github.com/bazelbuild/buildtools)
   consistently to format and lint your code.
diff --git a/versions/8.0.1/extending/depsets.mdx b/versions/8.0.1/extending/depsets.mdx
index 0e66a853..0df2765f 100644
--- a/versions/8.0.1/extending/depsets.mdx
+++ b/versions/8.0.1/extending/depsets.mdx
@@ -111,8 +111,7 @@ need to ensure that if `B` depends on `A`, then `A.o` comes before `B.o` on the
 linker’s command line. Other tools might have the opposite requirement.
 
 Three traversal orders are supported: `postorder`, `preorder`, and
-`topological`. The first two work exactly like [tree
-traversals](https://en.wikipedia.org/wiki/Tree_traversal#Depth-first_search)
+`topological`. The first two work exactly like [tree traversals](https://en.wikipedia.org/wiki/Tree_traversal#Depth-first_search)
 except that they operate on DAGs and skip already visited nodes. The third order
 works as a topological sort from root to leaves, essentially the same as
 preorder except that shared children are listed only after all of their parents.
diff --git a/versions/8.0.1/extending/exec-groups.mdx b/versions/8.0.1/extending/exec-groups.mdx
index ac4b4de3..cff4296e 100644
--- a/versions/8.0.1/extending/exec-groups.mdx
+++ b/versions/8.0.1/extending/exec-groups.mdx
@@ -63,8 +63,7 @@ test rules.
 
 In the rule implementation, you can declare that actions should be run on the
 execution platform of an execution group. You can do this by using the `exec_group`
-param of action generating methods, specifically [`ctx.actions.run`]
-(/rules/lib/builtins/actions#run) and
+param of action generating methods, specifically [`ctx.actions.run`](/versions/8.0.1/rules/lib/builtins/actions#run) and
 [`ctx.actions.run_shell`](/versions/8.0.1/rules/lib/builtins/actions#run_shell).
 
 ```python
diff --git a/versions/8.0.1/extending/legacy-macros.mdx b/versions/8.0.1/extending/legacy-macros.mdx
index 84d0daa5..763f34f8 100644
--- a/versions/8.0.1/extending/legacy-macros.mdx
+++ b/versions/8.0.1/extending/legacy-macros.mdx
@@ -9,7 +9,7 @@ anymore, and Bazel sees only the concrete set of instantiated rules.
 
 ## Why you shouldn't use legacy macros (and should use Symbolic macros instead) {#no-legacy-macros}
 
-Where possible you should use [symbolic macros](macros.md#macros).
+Where possible you should use [symbolic macros](/versions/8.0.1/extending/macros#macros).
 
 Symbolic macros
 
@@ -18,7 +18,7 @@ Symbolic macros
 *   Take typed attributes, which in turn means automatic label and select
     conversion.
 *   Are more readable
-*   Will soon have [lazy evaluation](macros.md/laziness)
+*   Will soon have [lazy evaluation](/versions/8.0.1/extending/macros#laziness)
 
 ## Usage {#usage}
 
@@ -152,7 +152,7 @@ the macro), use the function
 ## Label resolution in macros {#label-resolution}
 
 Since legacy macros are evaluated in the
-[loading phase](concepts.md#evaluation-model), label strings such as
+[loading phase](/versions/8.0.1/extending/concepts#evaluation-model), label strings such as
 `"//foo:bar"` that occur in a legacy macro are interpreted relative to the
 `BUILD` file in which the macro is used rather than relative to the `.bzl` file
 in which it is defined. This behavior is generally undesirable for macros that
diff --git a/versions/8.0.1/extending/macros.mdx b/versions/8.0.1/extending/macros.mdx
index 03f49d16..87c6183e 100644
--- a/versions/8.0.1/extending/macros.mdx
+++ b/versions/8.0.1/extending/macros.mdx
@@ -10,7 +10,7 @@ Macros are mainly used for encapsulation and code reuse of existing rules and
 other macros.
 
 Macros come in two flavors: symbolic macros, which are described on this page,
-and [legacy macros](legacy-macros.md). Where possible, we recommend using
+and [legacy macros](/versions/8.0.1/extending/legacy-macros). Where possible, we recommend using
 symbolic macros for code clarity.
 
 Symbolic macros offer typed arguments (string to label conversion, relative to
@@ -31,8 +31,7 @@ two required parameters: `attrs` and `implementation`.
 
 ### Attributes {#attributes}
 
-`attrs` accepts a dictionary of attribute name to [attribute
-types](https://bazel.build/rules/lib/toplevel/attr#members), which represents
+`attrs` accepts a dictionary of attribute name to [attribute types](https://bazel.build/versions/8.0.1/rules/lib/toplevel/attr#members), which represents
 the arguments to the macro. Two common attributes – `name` and `visibility` –
 are implicitly added to all macros and are not included in the dictionary passed
 to `attrs`.
@@ -66,9 +65,7 @@ To support this pattern, a macro can *inherit attributes* from a rule or another
 macro by passing the [rule](https://bazel.build/versions/8.0.1/rules/lib/builtins/rule) or
 [macro symbol](https://bazel.build/versions/8.0.1/rules/lib/builtins/macro) to `macro()`'s
 `inherit_attrs` argument. (You can also use the special string `"common"`
-instead of a rule or macro symbol to inherit the [common attributes defined for
-all Starlark build
-rules](https://bazel.build/reference/be/common-definitions#common-attributes).)
+instead of a rule or macro symbol to inherit the [common attributes defined for all Starlark build rules](https://bazel.build/versions/8.0.1/reference/be/common-definitions#common-attributes).)
 Only public attributes get inherited, and the attributes in the macro's own
 `attrs` dictionary override inherited attributes with the same name. You can
 also *remove* inherited attributes by using `None` as a value in the `attrs`
diff --git a/versions/8.0.1/extending/platforms.mdx b/versions/8.0.1/extending/platforms.mdx
index 94df0b11..c3ca08b3 100644
--- a/versions/8.0.1/extending/platforms.mdx
+++ b/versions/8.0.1/extending/platforms.mdx
@@ -245,8 +245,7 @@ cc_library(
 
 You can use the
 [`IncompatiblePlatformProvider`](/versions/8.0.1/rules/lib/providers/IncompatiblePlatformProvider)
-in `bazel cquery`'s [Starlark output
-format](/versions/8.0.1/query/cquery#output-format-definition) to distinguish
+in `bazel cquery`'s [Starlark output format](/versions/8.0.1/query/cquery#output-format-definition) to distinguish
 incompatible targets from compatible ones.
 
 This can be used to filter out incompatible targets. The example below will
@@ -266,5 +265,4 @@ $ bazel cquery //... --output=starlark --starlark:file=example.cquery
 
 ### Known Issues
 
-Incompatible targets [ignore visibility
-restrictions](https://github.com/bazelbuild/bazel/issues/16044).
+Incompatible targets [ignore visibility restrictions](https://github.com/bazelbuild/bazel/issues/16044).
diff --git a/versions/8.0.1/extending/repo.mdx b/versions/8.0.1/extending/repo.mdx
index d463fd7d..4f0523b4 100644
--- a/versions/8.0.1/extending/repo.mdx
+++ b/versions/8.0.1/extending/repo.mdx
@@ -74,8 +74,7 @@ specified.
 
 The input parameter `repository_ctx` can be used to access attribute values, and
 non-hermetic functions (finding a binary, executing a binary, creating a file in
-the repository or downloading a file from the Internet). See [the API
-docs](/versions/8.0.1/rules/lib/builtins/repository_ctx) for more context. Example:
+the repository or downloading a file from the Internet). See [the API docs](/versions/8.0.1/rules/lib/builtins/repository_ctx) for more context. Example:
 
 ```python
 def _impl(repository_ctx):
@@ -144,8 +143,7 @@ definition has the `configure` attribute set, use `bazel fetch --force
 
 ## Examples
 
--   [C++ auto-configured
-    toolchain](https://cs.opensource.google/bazel/bazel/+/master:tools/cpp/cc_configure.bzl;drc=644b7d41748e09eff9e47cbab2be2263bb71f29a;l=176):
+-   [C++ auto-configured toolchain](https://cs.opensource.google/bazel/bazel/+/master:tools/cpp/cc_configure.bzl;drc=644b7d41748e09eff9e47cbab2be2263bb71f29a;l=176):
     it uses a repo rule to automatically create the C++ configuration files for
     Bazel by looking for the local C++ compiler, the environment and the flags
     the C++ compiler supports.
diff --git a/versions/8.0.1/extending/rules.mdx b/versions/8.0.1/extending/rules.mdx
index 0cc97712..7db43643 100644
--- a/versions/8.0.1/extending/rules.mdx
+++ b/versions/8.0.1/extending/rules.mdx
@@ -449,8 +449,7 @@ def _example_library_impl(ctx):
 
 If `DefaultInfo` is not returned by a rule implementation or the `files`
 parameter is not specified, `DefaultInfo.files` defaults to all
-*predeclared outputs* (generally, those created by [output
-attributes](#output_attributes)).
+*predeclared outputs* (generally, those created by [output attributes](#output_attributes)).
 
 Rules that perform actions should provide default outputs, even if those outputs
 are not expected to be directly used. Actions that are not in the graph of the
diff --git a/versions/8.0.1/extending/toolchains.mdx b/versions/8.0.1/extending/toolchains.mdx
index 36fa1b9e..22c11e93 100644
--- a/versions/8.0.1/extending/toolchains.mdx
+++ b/versions/8.0.1/extending/toolchains.mdx
@@ -523,8 +523,7 @@ The set of available toolchains, in priority order, is created from
   4. Toolchains registered in the "WORKSPACE suffix"; this is only used by
      certain native rules bundled with the Bazel installation.
 
-**NOTE:** [Pseudo-targets like `:all`, `:*`, and
-`/...`](/versions/8.0.1/run/build#specifying-build-targets) are ordered by Bazel's package
+**NOTE:** [Pseudo-targets like `:all`, `:*`, and `/...`](/versions/8.0.1/run/build#specifying-build-targets) are ordered by Bazel's package
 loading mechanism, which uses a lexicographic ordering.
 
 The resolution steps are as follows.
diff --git a/versions/8.0.1/external/advanced.mdx b/versions/8.0.1/external/advanced.mdx
index b835ba5c..1410cd66 100644
--- a/versions/8.0.1/external/advanced.mdx
+++ b/versions/8.0.1/external/advanced.mdx
@@ -4,10 +4,8 @@ title: 'Advanced topics on external dependencies'
 
 ## Shadowing dependencies in WORKSPACE
 
-Note: This section applies to the [WORKSPACE
-system](/versions/8.0.1/external/overview#workspace-system) only. For
-[Bzlmod](/versions/8.0.1/external/overview#bzlmod), use a [multiple-version
-override](/versions/8.0.1/external/module#multiple-version_override).
+Note: This section applies to the [WORKSPACE system](/versions/8.0.1/external/overview#workspace-system) only. For
+[Bzlmod](/versions/8.0.1/external/overview#bzlmod), use a [multiple-version override](/versions/8.0.1/external/module#multiple-version_override).
 
 Whenever possible, have a single version policy in your project, which is
 required for dependencies that you compile against and end up in your final
@@ -128,29 +126,24 @@ preferring IPv4 if enabled. In some situations, for example when the IPv4
 network cannot resolve/reach external addresses, this can cause `Network
 unreachable` exceptions and build failures. In these cases, you can override
 Bazel's behavior to prefer IPv6 by using the
-[`java.net.preferIPv6Addresses=true` system
-property](https://docs.oracle.com/javase/8/docs/api/java/net/doc-files/net-properties.html).
+[`java.net.preferIPv6Addresses=true` system property](https://docs.oracle.com/javase/8/docs/api/java/net/doc-files/net-properties.html).
 Specifically:
 
-*   Use `--host_jvm_args=-Djava.net.preferIPv6Addresses=true` [startup
-    option](/versions/8.0.1/docs/user-manual#startup-options), for example by adding the
+*   Use `--host_jvm_args=-Djava.net.preferIPv6Addresses=true` [startup option](/versions/8.0.1/docs/user-manual#startup-options), for example by adding the
     following line in your [`.bazelrc` file](/versions/8.0.1/run/bazelrc):
 
     `startup --host_jvm_args=-Djava.net.preferIPv6Addresses=true`
 
 *   When running Java build targets that need to connect to the internet (such
     as for integration tests), use the
-    `--jvmopt=-Djava.net.preferIPv6Addresses=true` [tool
-    flag](/versions/8.0.1/docs/user-manual#jvmopt). For example, include in your [`.bazelrc`
-    file](/versions/8.0.1/run/bazelrc):
+    `--jvmopt=-Djava.net.preferIPv6Addresses=true` [tool flag](/versions/8.0.1/docs/user-manual#jvmopt). For example, include in your [`.bazelrc` file](/versions/8.0.1/run/bazelrc):
 
     `build --jvmopt=-Djava.net.preferIPv6Addresses`
 
 *   If you are using [`rules_jvm_external`](https://github.com/bazelbuild/rules_jvm_external)
     for dependency version resolution, also add
     `-Djava.net.preferIPv6Addresses=true` to the `COURSIER_OPTS` environment
-    variable to [provide JVM options for
-    Coursier](https://github.com/bazelbuild/rules_jvm_external#provide-jvm-options-for-coursier-with-coursier_opts).
+    variable to [provide JVM options for Coursier](https://github.com/bazelbuild/rules_jvm_external#provide-jvm-options-for-coursier-with-coursier_opts).
 
 ## Offline builds
 
@@ -167,15 +160,12 @@ fetch a file with [`ctx.download`](/versions/8.0.1/rules/lib/builtins/repository
 providing a hash sum of the file needed, Bazel looks for a file matching the
 basename of the first URL, and uses the local copy if the hash matches.
 
-Bazel itself uses this technique to bootstrap offline from the [distribution
-artifact](https://github.com/bazelbuild/bazel-website/blob/master/designs/_posts/2016-10-11-distribution-artifact.md).
-It does so by [collecting all the needed external
-dependencies](https://github.com/bazelbuild/bazel/blob/5cfa0303d6ac3b5bd031ff60272ce80a704af8c2/WORKSPACE#L116)
+Bazel itself uses this technique to bootstrap offline from the [distribution artifact](https://github.com/bazelbuild/bazel-website/blob/master/designs/_posts/2016-10-11-distribution-artifact.md).
+It does so by [collecting all the needed external dependencies](https://github.com/bazelbuild/bazel/blob/5cfa0303d6ac3b5bd031ff60272ce80a704af8c2/WORKSPACE#L116)
 in an internal
 [`distdir_tar`](https://github.com/bazelbuild/bazel/blob/5cfa0303d6ac3b5bd031ff60272ce80a704af8c2/distdir.bzl#L44).
 
 Bazel allows execution of arbitrary commands in repository rules without knowing
 if they call out to the network, and so cannot enforce fully offline builds. To
 test if a build works correctly offline, manually block off the network (as
-Bazel does in its [bootstrap
-test](https://cs.opensource.google/bazel/bazel/+/master:src/test/shell/bazel/BUILD;l=1073;drc=88c426e73cc0eb0a41c0d7995e36acd94e7c9a48)).
\ No newline at end of file
+Bazel does in its [bootstrap test](https://cs.opensource.google/bazel/bazel/+/master:src/test/shell/bazel/BUILD;l=1073;drc=88c426e73cc0eb0a41c0d7995e36acd94e7c9a48)).
\ No newline at end of file
diff --git a/versions/8.0.1/external/images/mod_exampleBefore.svg b/versions/8.0.1/external/images/mod_exampleBefore.svg
new file mode 100644
index 00000000..66f01303
--- /dev/null
+++ b/versions/8.0.1/external/images/mod_exampleBefore.svg
@@ -0,0 +1,175 @@
+
+
+
+
+
+
+mygraph
+
+
+
+<root>
+
+<root> (my_project@1.0)
+
+
+
+bazel_skylib@1.1.1
+
+bazel_skylib@1.1.1
+
+
+
+<root>->bazel_skylib@1.1.1
+
+
+
+
+
+bazel_skylib@1.2.0
+
+bazel_skylib@1.2.0
+
+
+
+<root>->bazel_skylib@1.2.0
+
+
+
+
+
+rules_java@5.0.0
+
+rules_java@5.0.0
+
+
+
+<root>->rules_java@5.0.0
+
+
+
+
+
+stardoc@0.5.0
+
+stardoc@0.5.0
+
+
+
+<root>->stardoc@0.5.0
+
+
+
+
+
+platforms@0.0.4
+
+platforms@0.0.4
+
+
+
+bazel_skylib@1.1.1->platforms@0.0.4
+
+
+
+
+
+bazel_skylib@1.2.0->platforms@0.0.4
+
+
+
+
+
+rules_java@5.0.0->platforms@0.0.4
+
+
+
+
+
+rules_cc@0.0.1
+
+rules_cc@0.0.1
+
+
+
+rules_java@5.0.0->rules_cc@0.0.1
+
+
+
+
+
+rules_proto@4.0.0
+
+rules_proto@4.0.0
+
+
+
+rules_java@5.0.0->rules_proto@4.0.0
+
+
+
+
+
+bazel_skylib@1.0.3
+
+bazel_skylib@1.0.3
+
+
+
+stardoc@0.5.0->bazel_skylib@1.0.3
+
+
+
+
+
+rules_java@4.0.0
+
+rules_java@4.0.0
+
+
+
+stardoc@0.5.0->rules_java@4.0.0
+
+
+
+
+
+rules_cc@0.0.1->platforms@0.0.4
+
+
+
+
+
+rules_cc@0.0.1->bazel_skylib@1.0.3
+
+
+
+
+
+rules_proto@4.0.0->rules_cc@0.0.1
+
+
+
+
+
+rules_proto@4.0.0->bazel_skylib@1.0.3
+
+
+
+
+
+bazel_skylib@1.0.3->platforms@0.0.4
+
+
+
+
+
+rules_java@4.0.0->bazel_skylib@1.0.3
+
+
+
+
+
\ No newline at end of file
diff --git a/versions/8.0.1/external/images/mod_exampleResolved.svg b/versions/8.0.1/external/images/mod_exampleResolved.svg
new file mode 100644
index 00000000..224b694c
--- /dev/null
+++ b/versions/8.0.1/external/images/mod_exampleResolved.svg
@@ -0,0 +1,151 @@
+
+
+
+
+
+
+mygraph
+
+
+
+<root>
+
+<root> (my_project@1.0)
+
+
+
+bazel_skylib@1.1.1
+
+bazel_skylib@1.1.1
+
+
+
+<root>->bazel_skylib@1.1.1
+
+
+
+
+
+bazel_skylib@1.2.0
+
+bazel_skylib@1.2.0
+
+
+
+<root>->bazel_skylib@1.2.0
+
+
+
+
+
+rules_java@5.0.0
+
+rules_java@5.0.0
+
+
+
+<root>->rules_java@5.0.0
+
+
+
+
+
+stardoc@0.5.0
+
+stardoc@0.5.0
+
+
+
+<root>->stardoc@0.5.0
+
+
+
+
+
+platforms@0.0.4
+
+platforms@0.0.4
+
+
+
+bazel_skylib@1.1.1->platforms@0.0.4
+
+
+
+
+
+bazel_skylib@1.2.0->platforms@0.0.4
+
+
+
+
+
+rules_java@5.0.0->platforms@0.0.4
+
+
+
+
+
+rules_cc@0.0.1
+
+rules_cc@0.0.1
+
+
+
+rules_java@5.0.0->rules_cc@0.0.1
+
+
+
+
+
+rules_proto@4.0.0
+
+rules_proto@4.0.0
+
+
+
+rules_java@5.0.0->rules_proto@4.0.0
+
+
+
+
+
+stardoc@0.5.0->bazel_skylib@1.1.1
+
+
+
+
+
+stardoc@0.5.0->rules_java@5.0.0
+
+
+
+
+
+rules_cc@0.0.1->bazel_skylib@1.1.1
+
+
+
+
+
+rules_cc@0.0.1->platforms@0.0.4
+
+
+
+
+
+rules_proto@4.0.0->bazel_skylib@1.1.1
+
+
+
+
+
+rules_proto@4.0.0->rules_cc@0.0.1
+
+
+
+
+
\ No newline at end of file
diff --git a/versions/8.0.1/external/migration.mdx b/versions/8.0.1/external/migration.mdx
index 0ecd64cc..f639978b 100644
--- a/versions/8.0.1/external/migration.mdx
+++ b/versions/8.0.1/external/migration.mdx
@@ -2,8 +2,7 @@
 title: 'Bzlmod Migration Guide'
 ---
 
-Due to the [shortcomings of
-WORKSPACE](/versions/8.0.1/external/overview#workspace-shortcomings), Bzlmod is going to
+Due to the [shortcomings of WORKSPACE](/versions/8.0.1/external/overview#workspace-shortcomings), Bzlmod is going to
 replace the legacy WORKSPACE system. The WORKSPACE file will be disabled by
 default in Bazel 8 (late 2024) and will be removed in Bazel 9 (late 2025).
 This guide helps you migrate your project to Bzlmod and drop WORKSPACE for
@@ -117,9 +116,7 @@ Bazel module when it also adopts Bzlmod.
 
 *   **Bzlmod**
 
-    With Bzlmod, as long as the your dependency is available in [Bazel Central
-    Registry](https://registry.bazel.build) or your custom [Bazel
-    registry](/versions/8.0.1/external/registry), you can simply depend on it with a
+    With Bzlmod, as long as the your dependency is available in [Bazel Central Registry](https://registry.bazel.build) or your custom [Bazel registry](/versions/8.0.1/external/registry), you can simply depend on it with a
     [`bazel_dep`](/versions/8.0.1/rules/lib/globals/module#bazel_dep) directive.
 
     ```python
@@ -150,8 +147,7 @@ repository.
 
 If your dependency is not a Bazel project or not yet available in any Bazel
 registry, you can introduce it using
-[`use_repo_rule`](/versions/8.0.1/external/module#use_repo_rule) or [module
-extensions](/versions/8.0.1/external/extension).
+[`use_repo_rule`](/versions/8.0.1/external/module#use_repo_rule) or [module extensions](/versions/8.0.1/external/extension).
 
 *   **WORKSPACE**
 
@@ -604,8 +600,7 @@ macros.
 Fortunately, the flag
 [`--experimental_repository_resolved_file`][resolved_file_flag]
 can help. This flag essentially generates a "lock file" of all fetched external
-dependencies in your last Bazel command. You can find more details in this [blog
-post](https://blog.bazel.build/2018/07/09/bazel-sync-and-resolved-file.html).
+dependencies in your last Bazel command. You can find more details in this [blog post](https://blog.bazel.build/2018/07/09/bazel-sync-and-resolved-file.html).
 
 [resolved_file_flag]: /reference/command-line-reference#flag--experimental_repository_resolved_file
 
@@ -646,11 +641,9 @@ You may also know `bazel query` can be used for inspecting repository rules with
 bazel query --output=build //external:
 ```
 
-While it is more convenient and much faster, [bazel query can lie about
-external dependency version](https://github.com/bazelbuild/bazel/issues/12947),
+While it is more convenient and much faster, [bazel query can lie about external dependency version](https://github.com/bazelbuild/bazel/issues/12947),
 so be careful using it! Querying and inspecting external
-dependencies with Bzlmod is going to achieved by a [new
-subcommand](https://github.com/bazelbuild/bazel/issues/15365).
+dependencies with Bzlmod is going to achieved by a [new subcommand](https://github.com/bazelbuild/bazel/issues/15365).
 
 #### Built-in default dependencies {#builtin-default-deps}
 
@@ -697,8 +690,7 @@ Using the WORKSPACE.bzlmod file can make the migration easier because:
 #### Repository visibility {#repository-visibility}
 
 Bzlmod is able to control which other repositories are visible from a given
-repository, check [repository names and strict
-deps](/versions/8.0.1/external/module#repository_names_and_strict_deps) for more details.
+repository, check [repository names and strict deps](/versions/8.0.1/external/module#repository_names_and_strict_deps) for more details.
 
 Here is a summary of repository visibilities from different types of
 repositories when also taking WORKSPACE into consideration.
@@ -711,8 +703,7 @@ repositories when also taking WORKSPACE into consideration.
 | WORKSPACE Repos | All visible | Not visible | Not visible | All visible |
 
 Note: For the root module, if a repository `@foo` is defined in WORKSPACE and
-`@foo` is also used as an [apparent repository
-name](/versions/8.0.1/external/overview#apparent-repo-name) in MODULE.bazel, then `@foo`
+`@foo` is also used as an [apparent repository name](/versions/8.0.1/external/overview#apparent-repo-name) in MODULE.bazel, then `@foo`
 refers to the one introduced in MODULE.bazel.
 
 Note: For a module extension generated repository `@bar`, if `@foo` is used as
@@ -787,9 +778,7 @@ the project. Take note of a few things when creating the source archive:
     GitHub isn't going to guarantee the checksum of source archives generated on
     demand. In short, URLs in the form of
     `https://github.com///releases/download/...` is considered stable
-    while `https://github.com///archive/...` is not. Check [GitHub
-    Archive Checksum
-    Outage](https://blog.bazel.build/2023/02/15/github-archive-checksum.html)
+    while `https://github.com///archive/...` is not. Check [GitHub Archive Checksum Outage](https://blog.bazel.build/2023/02/15/github-archive-checksum.html)
     for more context.
 
 *   **Make sure the source tree follows the layout of the original repository.**
@@ -818,8 +807,7 @@ Pull Request.
 
 [bcr_contrib_guide]: https://github.com/bazelbuild/bazel-central-registry/tree/main/docs#contribute-a-bazel-module
 
-It is **highly recommended** to set up the [Publish to
-BCR](https://github.com/bazel-contrib/publish-to-bcr) GitHub App for your
+It is **highly recommended** to set up the [Publish to BCR](https://github.com/bazel-contrib/publish-to-bcr) GitHub App for your
 repository to automate the process of submitting your module to the BCR.
 
 ## Best practices {#best-practices}
diff --git a/versions/8.0.1/external/mod-command.mdx b/versions/8.0.1/external/mod-command.mdx
index e49acc52..2d0b7978 100644
--- a/versions/8.0.1/external/mod-command.mdx
+++ b/versions/8.0.1/external/mod-command.mdx
@@ -61,11 +61,9 @@ The available subcommands and their respective required arguments are:
 
 *   ``: All present versions of the module ``.
 
-*   `@`: The repo with the given [apparent
-    name](overview#apparent-repo-name) in the context of the `--base_module`.
+*   `@`: The repo with the given [apparent name](/versions/8.0.1/external/overview#apparent-repo-name) in the context of the `--base_module`.
 
-*   `@@`: The repo with the given [canonical
-    name](overview#canonical-repo-name).
+*   `@@`: The repo with the given [canonical name](/versions/8.0.1/external/overview#canonical-repo-name).
 
 In a context requiring specifying modules, ``s referring to repos that
 correspond to modules (as opposed to extension-generated repos) can also be
@@ -87,8 +85,7 @@ The following options only affect the subcommands that print graphs (`graph`,
     information about the version resolution of each module. If the module
     version changed during resolution, show either which version replaced it or
     what was the original version, the reason it was replaced, and which modules
-    requested the new version if the reason was [Minimal Version
-    Selection](module#version-selection).
+    requested the new version if the reason was [Minimal Version Selection](/versions/8.0.1/external/module#version-selection).
 
 *   `--include_unused` *default: "false"*: Include in the output graph the
     modules which were originally present in the dependency graph, but became
@@ -192,7 +189,7 @@ use_repo(toolchains, my_jdk="remotejdk17_linux")
   

     
       

-        Graph Before Resolution
+        Graph Before Resolution
         
Graph Before Resolution

       

 {/* digraph mygraph {
@@ -222,7 +219,7 @@ use_repo(toolchains, my_jdk="remotejdk17_linux")
     		
     
       

-        Graph After Resolution
+        Graph After Resolution
        
Graph After Resolution

       

 {/* digraph mygraph {
diff --git a/versions/8.0.1/external/module.mdx b/versions/8.0.1/external/module.mdx
index 51ed23dd..6ef3dded 100644
--- a/versions/8.0.1/external/module.mdx
+++ b/versions/8.0.1/external/module.mdx
@@ -122,8 +122,7 @@ serves multiple purposes:
     version, regardless of which versions of the dependency are requested in the
     dependency graph.
 *   With the `registry` attribute, you can force this dependency to come from a
-    specific registry, instead of following the normal [registry
-    selection](/versions/8.0.1/external/registry#selecting_registries) process.
+    specific registry, instead of following the normal [registry selection](/versions/8.0.1/external/registry#selecting_registries) process.
 *   With the `patch*` attributes, you can specify a set of patches to apply to
     the downloaded module.
 
@@ -176,13 +175,11 @@ With `bazel_dep`, you can define repos that represent other Bazel modules.
 Sometimes there is a need to define a repo that does _not_ represent a Bazel
 module; for example, one that contains a plain JSON file to be read as data.
 
-In this case, you could use the [`use_repo_rule`
-directive](/versions/8.0.1/rules/lib/globals/module#use_repo_rule) to directly define a repo
+In this case, you could use the [`use_repo_rule` directive](/versions/8.0.1/rules/lib/globals/module#use_repo_rule) to directly define a repo
 by invoking a repo rule. This repo will only be visible to the module it's
 defined in.
 
-Under the hood, this is implemented using the same mechanism as [module
-extensions](/versions/8.0.1/external/extension), which lets you define repos with more
+Under the hood, this is implemented using the same mechanism as [module extensions](/versions/8.0.1/external/extension), which lets you define repos with more
 flexibility.
 
 ## Repository names and strict deps
diff --git a/versions/8.0.1/external/overview.mdx b/versions/8.0.1/external/overview.mdx
index 8b1ed1b1..72dd86ad 100644
--- a/versions/8.0.1/external/overview.mdx
+++ b/versions/8.0.1/external/overview.mdx
@@ -128,8 +128,7 @@ for all build targets inside the repo.
 
 The syntax of a `REPO.bazel` file is similar to `BUILD` files, except that no
 `load` statements are supported, and only a single function, `repo()`, is
-available. `repo()` takes the same arguments as the [`package()`
-function](/versions/8.0.1/reference/be/functions#package) in `BUILD` files; whereas `package()`
+available. `repo()` takes the same arguments as the [`package()` function](/versions/8.0.1/reference/be/functions#package) in `BUILD` files; whereas `package()`
 specifies common attributes for all build targets inside the package, `repo()`
 analogously does so for all build targets inside the repo.
 
@@ -163,8 +162,7 @@ bazel_dep(name = "protobuf", version = "3.19.0")
 ```
 
 A module must only list its direct dependencies, which Bzlmod looks up in a
-[Bazel registry](/versions/8.0.1/external/registry) — by default, the [Bazel Central
-Registry](https://bcr.bazel.build/). The registry provides the
+[Bazel registry](/versions/8.0.1/external/registry) — by default, the [Bazel Central Registry](https://bcr.bazel.build/). The registry provides the
 dependencies' `MODULE.bazel` files, which allows Bazel to discover the entire
 transitive dependency graph before performing version resolution.
 
@@ -235,5 +233,4 @@ many pain points, including:
         `B` and `C`; `B` and `C` both depend on different versions of `D`).
 
 Due to the shortcomings of WORKSPACE, Bzlmod is going to replace the legacy
-WORKSPACE system in future Bazel releases. Please read the [Bzlmod migration
-guide](/versions/8.0.1/external/migration) on how to migrate to Bzlmod.
+WORKSPACE system in future Bazel releases. Please read the [Bzlmod migration guide](/versions/8.0.1/external/migration) on how to migrate to Bzlmod.
diff --git a/versions/8.0.1/external/registry.mdx b/versions/8.0.1/external/registry.mdx
index 44c8d937..77e07df3 100644
--- a/versions/8.0.1/external/registry.mdx
+++ b/versions/8.0.1/external/registry.mdx
@@ -42,8 +42,7 @@ An index registry must follow the format below:
             project
         *   `versions`: A list of all the versions of this module to be found in
             this registry
-        *   `yanked_versions`: A map of [*yanked*
-            versions](/versions/8.0.1/external/module#yanked_versions) of this module. The keys
+        *   `yanked_versions`: A map of [*yanked* versions](/versions/8.0.1/external/module#yanked_versions) of this module. The keys
             should be versions to yank and the values should be descriptions of
             why the version is yanked, ideally containing a link to more
             information
@@ -54,8 +53,7 @@ An index registry must follow the format below:
         *   The default type is "archive", representing an `http_archive` repo,
             with the following fields:
             *   `url`: The URL of the source archive
-            *   `integrity`: The [Subresource
-                Integrity](https://w3c.github.io/webappsec-subresource-integrity/#integrity-metadata-description)
+            *   `integrity`: The [Subresource Integrity](https://w3c.github.io/webappsec-subresource-integrity/#integrity-metadata-description)
                 checksum of the archive
             *   `strip_prefix`: A directory prefix to strip when extracting the
                 source archive
@@ -103,8 +101,7 @@ You can browse its contents using the web frontend at
 https://registry.bazel.build/.
 
 The Bazel community maintains the BCR, and contributors are welcome to submit
-pull requests. See the [BCR contribution
-guidelines](https://github.com/bazelbuild/bazel-central-registry/blob/main/docs/README.md).
+pull requests. See the [BCR contribution guidelines](https://github.com/bazelbuild/bazel-central-registry/blob/main/docs/README.md).
 
 In addition to following the format of a normal index registry, the BCR requires
 a `presubmit.yml` file for each module version
diff --git a/versions/8.0.1/external/vendor.mdx b/versions/8.0.1/external/vendor.mdx
index d011936a..8c9df7ce 100644
--- a/versions/8.0.1/external/vendor.mdx
+++ b/versions/8.0.1/external/vendor.mdx
@@ -23,9 +23,7 @@ absolute path.
 ## Vendor a specific external repository {#vendor-specific-repository}
 
 You can use the `vendor` command with the `--repo` flag to specify which repo
-to vendor, it accepts both [canonical repo
-name](/versions/8.0.1/external/overview#canonical-repo-name) and [apparent repo
-name](/versions/8.0.1/external/overview#apparent-repo-name).
+to vendor, it accepts both [canonical repo name](/versions/8.0.1/external/overview#canonical-repo-name) and [apparent repo name](/versions/8.0.1/external/overview#apparent-repo-name).
 
 For example, running:
 
diff --git a/versions/8.0.1/help.mdx b/versions/8.0.1/help.mdx
index f9e0dfda..459d6077 100644
--- a/versions/8.0.1/help.mdx
+++ b/versions/8.0.1/help.mdx
@@ -46,5 +46,4 @@ what level of support Bazel provides.
 
 ## File a bug {#file-bug}
 
-If you encounter a bug or want to request a feature, file a [GitHub
-Issue](https://github.com/bazelbuild/bazel/issues).
+If you encounter a bug or want to request a feature, file a [GitHub Issue](https://github.com/bazelbuild/bazel/issues).
diff --git a/versions/8.0.1/images/about.svg b/versions/8.0.1/images/about.svg
new file mode 100644
index 00000000..f927298f
--- /dev/null
+++ b/versions/8.0.1/images/about.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/8.0.1/images/basics.svg b/versions/8.0.1/images/basics.svg
new file mode 100644
index 00000000..013ec519
--- /dev/null
+++ b/versions/8.0.1/images/basics.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/8.0.1/images/bazel_hero.svg b/versions/8.0.1/images/bazel_hero.svg
new file mode 100644
index 00000000..c48714d0
--- /dev/null
+++ b/versions/8.0.1/images/bazel_hero.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/8.0.1/images/community.svg b/versions/8.0.1/images/community.svg
new file mode 100644
index 00000000..29f87a76
--- /dev/null
+++ b/versions/8.0.1/images/community.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/8.0.1/images/distributed-build-remote-cache.png b/versions/8.0.1/images/distributed-build-remote-cache.png
new file mode 100644
index 00000000..99d8a915
Binary files /dev/null and b/versions/8.0.1/images/distributed-build-remote-cache.png differ
diff --git a/versions/8.0.1/images/essential_guide.svg b/versions/8.0.1/images/essential_guide.svg
new file mode 100644
index 00000000..4ee63ae9
--- /dev/null
+++ b/versions/8.0.1/images/essential_guide.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/8.0.1/images/essential_reference.svg b/versions/8.0.1/images/essential_reference.svg
new file mode 100644
index 00000000..4d29a8d5
--- /dev/null
+++ b/versions/8.0.1/images/essential_reference.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/8.0.1/images/essential_start.svg b/versions/8.0.1/images/essential_start.svg
new file mode 100644
index 00000000..c8f48f84
--- /dev/null
+++ b/versions/8.0.1/images/essential_start.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/8.0.1/images/extend.svg b/versions/8.0.1/images/extend.svg
new file mode 100644
index 00000000..77b2dd97
--- /dev/null
+++ b/versions/8.0.1/images/extend.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/8.0.1/images/guide.svg b/versions/8.0.1/images/guide.svg
new file mode 100644
index 00000000..23a5d35a
--- /dev/null
+++ b/versions/8.0.1/images/guide.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/8.0.1/images/high-level-build-system.png b/versions/8.0.1/images/high-level-build-system.png
new file mode 100644
index 00000000..462717fa
Binary files /dev/null and b/versions/8.0.1/images/high-level-build-system.png differ
diff --git a/versions/8.0.1/images/new_1.svg b/versions/8.0.1/images/new_1.svg
new file mode 100644
index 00000000..c4cd9dfd
--- /dev/null
+++ b/versions/8.0.1/images/new_1.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/8.0.1/images/new_2.svg b/versions/8.0.1/images/new_2.svg
new file mode 100644
index 00000000..c6b7021b
--- /dev/null
+++ b/versions/8.0.1/images/new_2.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/8.0.1/images/new_3.svg b/versions/8.0.1/images/new_3.svg
new file mode 100644
index 00000000..c2afb4ac
--- /dev/null
+++ b/versions/8.0.1/images/new_3.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/8.0.1/images/placeholder.png b/versions/8.0.1/images/placeholder.png
new file mode 100644
index 00000000..54f1fa0e
Binary files /dev/null and b/versions/8.0.1/images/placeholder.png differ
diff --git a/versions/8.0.1/images/reference.svg b/versions/8.0.1/images/reference.svg
new file mode 100644
index 00000000..7bbc9bea
--- /dev/null
+++ b/versions/8.0.1/images/reference.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/8.0.1/images/release_notes.svg b/versions/8.0.1/images/release_notes.svg
new file mode 100644
index 00000000..8a2e8b56
--- /dev/null
+++ b/versions/8.0.1/images/release_notes.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/8.0.1/images/remote-execution-system.png b/versions/8.0.1/images/remote-execution-system.png
new file mode 100644
index 00000000..8152fc0c
Binary files /dev/null and b/versions/8.0.1/images/remote-execution-system.png differ
diff --git a/versions/8.0.1/images/start.svg b/versions/8.0.1/images/start.svg
new file mode 100644
index 00000000..3bcebd7b
--- /dev/null
+++ b/versions/8.0.1/images/start.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/8.0.1/images/task-dependencies.png b/versions/8.0.1/images/task-dependencies.png
new file mode 100644
index 00000000..ae1f9c51
Binary files /dev/null and b/versions/8.0.1/images/task-dependencies.png differ
diff --git a/versions/8.0.1/images/test.png b/versions/8.0.1/images/test.png
new file mode 100644
index 00000000..243939da
Binary files /dev/null and b/versions/8.0.1/images/test.png differ
diff --git a/versions/8.0.1/images/transitive-dependencies.png b/versions/8.0.1/images/transitive-dependencies.png
new file mode 100644
index 00000000..ec641a08
Binary files /dev/null and b/versions/8.0.1/images/transitive-dependencies.png differ
diff --git a/versions/8.0.1/images/trunk-logo-dark.svg b/versions/8.0.1/images/trunk-logo-dark.svg
new file mode 100644
index 00000000..f25940af
--- /dev/null
+++ b/versions/8.0.1/images/trunk-logo-dark.svg
@@ -0,0 +1,22 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/versions/8.0.1/images/why_faq.svg b/versions/8.0.1/images/why_faq.svg
new file mode 100644
index 00000000..afec3f8f
--- /dev/null
+++ b/versions/8.0.1/images/why_faq.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/8.0.1/images/why_overview.svg b/versions/8.0.1/images/why_overview.svg
new file mode 100644
index 00000000..c10c363c
--- /dev/null
+++ b/versions/8.0.1/images/why_overview.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/8.0.1/images/why_vision.svg b/versions/8.0.1/images/why_vision.svg
new file mode 100644
index 00000000..739e415f
--- /dev/null
+++ b/versions/8.0.1/images/why_vision.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/8.0.1/install/bazelisk.mdx b/versions/8.0.1/install/bazelisk.mdx
index c5afdcbd..abc502ee 100644
--- a/versions/8.0.1/install/bazelisk.mdx
+++ b/versions/8.0.1/install/bazelisk.mdx
@@ -16,8 +16,7 @@ For more details, see
 ## Updating Bazel
 
 Bazel has a [backward compatibility policy](/versions/8.0.1/release/backward-compatibility)
-(see [guidance for rolling out incompatible
-changes](/versions/8.0.1/contribute/breaking-changes) if you
+(see [guidance for rolling out incompatible changes](/versions/8.0.1/contribute/breaking-changes) if you
 are the author of one). That page summarizes best practices on how to test and
 migrate your project with upcoming incompatible changes and how to provide
 feedback to the incompatible change authors.
diff --git a/versions/8.0.1/install/compile-source.mdx b/versions/8.0.1/install/compile-source.mdx
index 842ce4ad..2135a70e 100644
--- a/versions/8.0.1/install/compile-source.mdx
+++ b/versions/8.0.1/install/compile-source.mdx
@@ -45,8 +45,7 @@ it by typing `bazel` in a terminal.
 
 **Reason**: To build Bazel from a GitHub source tree, you need a pre-existing
 Bazel binary. You can install one from a package manager or download one from
-GitHub. See [Installing Bazel](/versions/8.0.1/install). (Or you can [build from
-scratch (bootstrap)](#bootstrap-bazel).)
+GitHub. See [Installing Bazel](/versions/8.0.1/install). (Or you can [build from scratch (bootstrap)](#bootstrap-bazel).)
 
 **Troubleshooting**:
 
@@ -239,8 +238,7 @@ For instructions for Unix-like systems, see
     ```
 
 *   **The Visual C++ compiler.** Install the Visual C++ compiler either as part
-    of Visual Studio 2015 or newer, or by installing the latest [Build Tools
-    for Visual Studio 2017](https://aka.ms/BuildTools).
+    of Visual Studio 2015 or newer, or by installing the latest [Build Tools for Visual Studio 2017](https://aka.ms/BuildTools).
 
 *   **JDK.** Version 21 is required.
 
diff --git a/versions/8.0.1/install/ide.mdx b/versions/8.0.1/install/ide.mdx
index 561d0e02..c42d95e9 100644
--- a/versions/8.0.1/install/ide.mdx
+++ b/versions/8.0.1/install/ide.mdx
@@ -38,10 +38,8 @@ To install, go to the IDE's plugin browser and search for `Bazel`.
 To manually install older versions, download the zip files from JetBrains'
 Plugin Repository and install the zip file from the IDE's plugin browser:
 
-*  [Android Studio
-   plugin](https://plugins.jetbrains.com/plugin/9185-android-studio-with-bazel)
-*  [IntelliJ
-   plugin](https://plugins.jetbrains.com/plugin/8609-intellij-with-bazel)
+*  [Android Studio plugin](https://plugins.jetbrains.com/plugin/9185-android-studio-with-bazel)
+*  [IntelliJ plugin](https://plugins.jetbrains.com/plugin/8609-intellij-with-bazel)
 *  [CLion plugin](https://plugins.jetbrains.com/plugin/9554-clion-with-bazel)
 
 ### Xcode {#xcode}
@@ -61,8 +59,7 @@ Features:
 * Starlark debugger for `.bzl` files during a build (set breakpoints, step
   through code, inspect variables, and so on)
 
-Find [the plugin on the Visual Studio
-marketplace](https://marketplace.visualstudio.com/items?itemName=BazelBuild.vscode-bazel).
+Find [the plugin on the Visual Studio marketplace](https://marketplace.visualstudio.com/items?itemName=BazelBuild.vscode-bazel).
 The plugin is [open source](https://github.com/bazelbuild/vscode-bazel).
 
 See also: [Autocomplete for Source Code](#autocomplete-for-source-code)
@@ -82,8 +79,7 @@ See also: [Autocomplete for Source Code](#autocomplete-for-source-code)
 
 ### Emacs {#emacs}
 
-See [`bazelbuild/bazel-emacs-mode` on
-GitHub](https://github.com/bazelbuild/emacs-bazel-mode)
+See [`bazelbuild/bazel-emacs-mode` on GitHub](https://github.com/bazelbuild/emacs-bazel-mode)
 
 See also: [Autocomplete for Source Code](#autocomplete-for-source-code)
 
@@ -115,6 +111,5 @@ tool for building Bazel targets when source files change.
 
 ## Building your own IDE plugin {#build-own-plugin}
 
-Read the [**IDE support** blog
-post](https://blog.bazel.build/2016/06/10/ide-support.html) to learn more about
+Read the [**IDE support** blog post](https://blog.bazel.build/2016/06/10/ide-support.html) to learn more about
 the Bazel APIs to use when building an IDE plugin.
diff --git a/versions/8.0.1/install/images/bazelisk.svg b/versions/8.0.1/install/images/bazelisk.svg
new file mode 100644
index 00000000..c0ae9f54
--- /dev/null
+++ b/versions/8.0.1/install/images/bazelisk.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/8.0.1/install/images/cli.svg b/versions/8.0.1/install/images/cli.svg
new file mode 100644
index 00000000..01119280
--- /dev/null
+++ b/versions/8.0.1/install/images/cli.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/8.0.1/install/images/docker.svg b/versions/8.0.1/install/images/docker.svg
new file mode 100644
index 00000000..21190ce0
--- /dev/null
+++ b/versions/8.0.1/install/images/docker.svg
@@ -0,0 +1,6 @@
+
\ No newline at end of file
diff --git a/versions/8.0.1/install/images/github.svg b/versions/8.0.1/install/images/github.svg
new file mode 100644
index 00000000..aa05db9c
--- /dev/null
+++ b/versions/8.0.1/install/images/github.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/8.0.1/install/images/install.svg b/versions/8.0.1/install/images/install.svg
new file mode 100644
index 00000000..ae080865
--- /dev/null
+++ b/versions/8.0.1/install/images/install.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/8.0.1/install/images/mac.svg b/versions/8.0.1/install/images/mac.svg
new file mode 100644
index 00000000..3ee4fe28
--- /dev/null
+++ b/versions/8.0.1/install/images/mac.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/8.0.1/install/images/redhat.svg b/versions/8.0.1/install/images/redhat.svg
new file mode 100644
index 00000000..078b3387
--- /dev/null
+++ b/versions/8.0.1/install/images/redhat.svg
@@ -0,0 +1,69 @@
+
+
+  
+    
+      
+        image/svg+xml
+        
+        
+      
+    
+  
+  
+  
+    
+  
+  
+  
+
diff --git a/versions/8.0.1/install/images/suse.png b/versions/8.0.1/install/images/suse.png
new file mode 100644
index 00000000..6435b689
Binary files /dev/null and b/versions/8.0.1/install/images/suse.png differ
diff --git a/versions/8.0.1/install/images/tune.svg b/versions/8.0.1/install/images/tune.svg
new file mode 100644
index 00000000..8d7d63cb
--- /dev/null
+++ b/versions/8.0.1/install/images/tune.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/8.0.1/install/images/ubuntu.svg b/versions/8.0.1/install/images/ubuntu.svg
new file mode 100644
index 00000000..f217bc8d
--- /dev/null
+++ b/versions/8.0.1/install/images/ubuntu.svg
@@ -0,0 +1,8 @@
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/versions/8.0.1/install/images/windows.svg b/versions/8.0.1/install/images/windows.svg
new file mode 100644
index 00000000..120b0190
--- /dev/null
+++ b/versions/8.0.1/install/images/windows.svg
@@ -0,0 +1,5 @@
+
+
+
+
+
\ No newline at end of file
diff --git a/versions/8.0.1/install/windows.mdx b/versions/8.0.1/install/windows.mdx
index ea3e5a6d..873ecbfc 100644
--- a/versions/8.0.1/install/windows.mdx
+++ b/versions/8.0.1/install/windows.mdx
@@ -31,8 +31,7 @@ To check your Windows version:
 
 Alternatively you can:
 
-*   [Download the Bazel binary (`bazel-version-windows-x86_64.exe`) from
- GitHub](https://github.com/bazelbuild/bazel/releases).
+*   [Download the Bazel binary (`bazel-version-windows-x86_64.exe`) from GitHub](https://github.com/bazelbuild/bazel/releases).
 *   [Install Bazel from Chocolatey](#chocolately)
 *   [Install Bazel from Scoop](#scoop)
 *   [Build Bazel from source](/versions/8.0.1/install/compile-source)
@@ -208,8 +207,7 @@ If that doesn't help:
     its dependencies, such as the MSYS2 shell. This will not install Visual C++
     though.
 
-See [Chocolatey installation and package maintenance
-guide](/versions/8.0.1/contribute/windows-chocolatey-maintenance) for more
+See [Chocolatey installation and package maintenance guide](/versions/8.0.1/contribute/windows-chocolatey-maintenance) for more
 information about the Chocolatey package.
 
 ### Using Scoop {#scoop}
@@ -226,8 +224,7 @@ information about the Chocolatey package.
     scoop install bazel
     ```
 
-See [Scoop installation and package maintenance
-guide](/versions/8.0.1/contribute/windows-scoop-maintenance) for more
+See [Scoop installation and package maintenance guide](/versions/8.0.1/contribute/windows-scoop-maintenance) for more
 information about the Scoop package.
 
 ### Build from source {#build-from-source}
diff --git a/versions/8.0.1/migrate/maven.mdx b/versions/8.0.1/migrate/maven.mdx
index b4417dd3..6a9ee09c 100644
--- a/versions/8.0.1/migrate/maven.mdx
+++ b/versions/8.0.1/migrate/maven.mdx
@@ -19,8 +19,7 @@ directly run by Bazel since there's no Maven compatibility layer.
 ## Before you begin {#before-you-begin}
 
 *   [Install Bazel](/versions/8.0.1/install) if it's not yet installed.
-*   If you're new to Bazel, go through the tutorial [Introduction to Bazel:
-    Build Java](/versions/8.0.1/start/java) before you start migrating. The tutorial explains
+*   If you're new to Bazel, go through the tutorial [Introduction to Bazel: Build Java](/versions/8.0.1/start/java) before you start migrating. The tutorial explains
     Bazel's concepts, structure, and label syntax.
 
 ## Differences between Maven and Bazel {#dif-maven-bazel}
@@ -44,8 +43,7 @@ The steps below describe how to migrate your project to Bazel:
 3.  [Create more BUILD files](#3-build)
 4.  [Build using Bazel](#4-build)
 
-Examples below come from a migration of the [Guava
-project](https://github.com/google/guava) from Maven to Bazel. The
+Examples below come from a migration of the [Guava project](https://github.com/google/guava) from Maven to Bazel. The
 Guava project used is release `v31.1`. The examples using Guava do not walk
 through each step in the migration, but they do show the files and contents that
 are generated or added manually for the migration.
@@ -63,14 +61,12 @@ has no external dependencies, this file can be empty.
 If your project depends on files or packages that are not in one of the
 project's directories, specify these external dependencies in the MODULE.bazel
 file. You can use `rules_jvm_external` to manage dependencies from Maven. For
-instructions about using this ruleset, see [the
-README](https://github.com/bazelbuild/rules_jvm_external/#rules_jvm_external)
+instructions about using this ruleset, see [the README](https://github.com/bazelbuild/rules_jvm_external/#rules_jvm_external)
 .
 
 #### Guava project example: external dependencies {#guava-1}
 
-You can list the external dependencies of the [Guava
-project](https://github.com/google/guava) with the
+You can list the external dependencies of the [Guava project](https://github.com/google/guava) with the
 [`rules_jvm_external`](https://github.com/bazelbuild/rules_jvm_external)
 ruleset.
 
@@ -164,8 +160,7 @@ your build by adding more `BUILD` files with more granular targets.
             *   `resources`: Use globbing to list all resources in your project.
             *   `deps`: You need to determine which external dependencies your
                 project needs.
-        *   Take a look at the [example below of this top-level BUILD
-            file](#guava-2) from the migration of the Guava project.
+        *   Take a look at the [example below of this top-level BUILD file](#guava-2) from the migration of the Guava project.
 
 3.  Now that you have a `BUILD` file at the root of your project, build your
     project to ensure that it works. On the command line, from your workspace
diff --git a/versions/8.0.1/migrate/xcode.mdx b/versions/8.0.1/migrate/xcode.mdx
index 874a5f25..c3f3df17 100644
--- a/versions/8.0.1/migrate/xcode.mdx
+++ b/versions/8.0.1/migrate/xcode.mdx
@@ -32,8 +32,7 @@ Before you begin, do the following:
 
 1.  [Install Bazel](/versions/8.0.1/install) if you have not already done so.
 
-2.  If you're not familiar with Bazel and its concepts, complete the [iOS app
-    tutorial](/versions/8.0.1/start/ios-app)). You should understand the Bazel workspace,
+2.  If you're not familiar with Bazel and its concepts, complete the [iOS app tutorial](/versions/8.0.1/start/ios-app)). You should understand the Bazel workspace,
     including the `MODULE.bazel` and `BUILD` files, as well as the concepts of
     targets, build rules, and Bazel packages.
 
@@ -44,8 +43,7 @@ Before you begin, do the following:
 Unlike Xcode, Bazel requires you to explicitly declare all dependencies for
 every target in the `BUILD` file.
 
-For more information on external dependencies, see [Working with external
-dependencies](/versions/8.0.1/docs/external).
+For more information on external dependencies, see [Working with external dependencies](/versions/8.0.1/docs/external).
 
 ## Build or test an Xcode project with Bazel {#build-xcode-project}
 
@@ -84,8 +82,7 @@ Note: Place the project source code within the directory tree containing the
 
 To integrate SwiftPM dependencies into the Bazel workspace with
 [swift_bazel](https://github.com/cgrindel/swift_bazel), you must
-convert them into Bazel packages as described in the [following
-tutorial](https://chuckgrindel.com/swift-packages-in-bazel-using-swift_bazel/)
+convert them into Bazel packages as described in the [following tutorial](https://chuckgrindel.com/swift-packages-in-bazel-using-swift_bazel/)
 .
 
 Note: SwiftPM support is a manual process with many variables. SwiftPM
@@ -103,8 +100,7 @@ initial build of the project as follows:
 *   [Step 3b: (Optional) Add the test target(s)](#step-3b-optional-add-the-test-target-s)
 *   [Step 3c: Add the library target(s)](#step-3c-add-the-library-target-s)
 
-**Tip:** To learn more about packages and other Bazel concepts, see [Workspaces,
-packages, and targets](/versions/8.0.1/concepts/build-ref).
+**Tip:** To learn more about packages and other Bazel concepts, see [Workspaces, packages, and targets](/versions/8.0.1/concepts/build-ref).
 
 #### Step 3a: Add the application target {#add-app-target}
 
@@ -132,8 +128,7 @@ In the target, specify the following at the minimum:
 
 #### Step 3b: (Optional) Add the test target(s) {#add-test-target}
 
-Bazel's [Apple build
-rules](https://github.com/bazelbuild/rules_apple) support running
+Bazel's [Apple build rules](https://github.com/bazelbuild/rules_apple) support running
 unit and UI tests on all Apple platforms. Add test targets as follows:
 
 *   [`macos_unit_test`](https://github.com/bazelbuild/rules_apple/blob/master/doc/rules-macos.md#macos_unit_test)
@@ -181,8 +176,7 @@ all sources and/or headers of a certain type. Use it carefully as it might
 include files you do not want Bazel to build.
 
 You can browse existing examples for various types of applications directly in
-the [rules_apple examples
-directory](https://github.com/bazelbuild/rules_apple/tree/master/examples/). For
+the [rules_apple examples directory](https://github.com/bazelbuild/rules_apple/tree/master/examples/). For
 example:
 
 *   [macOS application targets](https://github.com/bazelbuild/rules_apple/tree/master/examples/macos)
@@ -191,8 +185,7 @@ example:
 
 *   [Multi platform applications (macOS, iOS, watchOS, tvOS)](https://github.com/bazelbuild/rules_apple/tree/master/examples/multi_platform)
 
-For more information on build rules, see [Apple Rules for
-Bazel](https://github.com/bazelbuild/rules_apple).
+For more information on build rules, see [Apple Rules for Bazel](https://github.com/bazelbuild/rules_apple).
 
 At this point, it is a good idea to test the build:
 
diff --git a/versions/8.0.1/query/cquery.mdx b/versions/8.0.1/query/cquery.mdx
index 71356dd4..494f4116 100644
--- a/versions/8.0.1/query/cquery.mdx
+++ b/versions/8.0.1/query/cquery.mdx
@@ -6,8 +6,7 @@ title: ' Configurable Query (cquery)'
 [`select()`](/versions/8.0.1/docs/configurable-attributes) and build options' effects on the build
 graph.
 
-It achieves this by running over the results of Bazel's [analysis
-phase](/versions/8.0.1/extending/concepts#evaluation-model),
+It achieves this by running over the results of Bazel's [analysis phase](/versions/8.0.1/extending/concepts#evaluation-model),
 which integrates these effects. `query`, by contrast, runs over the results of
 Bazel's loading phase, before options are evaluated.
 
@@ -137,8 +136,7 @@ $ bazel cquery //foo --universe_scope=//foo,//genrule_with_foo_as_tool
 If you want to precisely declare which instance to query over, use
 the [`config`](#config) function.
 
-See `query`'s [target pattern
-documentation](/versions/8.0.1/query/language#target-patterns) for more information on target patterns.
+See `query`'s [target pattern documentation](/versions/8.0.1/query/language#target-patterns) for more information on target patterns.
 
 ## Functions {#functions}
 
diff --git a/versions/8.0.1/query/images/query_graph1.png b/versions/8.0.1/query/images/query_graph1.png
new file mode 100644
index 00000000..7bc9a61a
Binary files /dev/null and b/versions/8.0.1/query/images/query_graph1.png differ
diff --git a/versions/8.0.1/query/images/query_graph2.png b/versions/8.0.1/query/images/query_graph2.png
new file mode 100644
index 00000000..a0da22ff
Binary files /dev/null and b/versions/8.0.1/query/images/query_graph2.png differ
diff --git a/versions/8.0.1/query/images/query_graph3.png b/versions/8.0.1/query/images/query_graph3.png
new file mode 100644
index 00000000..4418f193
Binary files /dev/null and b/versions/8.0.1/query/images/query_graph3.png differ
diff --git a/versions/8.0.1/query/language.mdx b/versions/8.0.1/query/language.mdx
index 0de68754..f45b6c88 100644
--- a/versions/8.0.1/query/language.mdx
+++ b/versions/8.0.1/query/language.mdx
@@ -1105,8 +1105,7 @@ is being used.
 
 ### On the ordering of results {#results-ordering}
 
-Although query expressions always follow the "[law of
-conservation of graph order](#graph-order)", _presenting_ the results may be done
+Although query expressions always follow the "[law of conservation of graph order](#graph-order)", _presenting_ the results may be done
 in either a dependency-ordered or unordered manner. This does **not**
 influence the targets in the result set or how the query is computed. It only
 affects how the results are printed to stdout. Moreover, nodes that are
@@ -1252,8 +1251,7 @@ and `maxrank` output formats print the labels of each
 target in the resulting graph, but instead of appearing in
 topological order, they appear in rank order, preceded by their
 rank number. These are unaffected by the result ordering
-`--[no]order_results` flag (see [notes on
-the ordering of results](#result-order)).
+`--[no]order_results` flag (see [notes on the ordering of results](#result-order)).
 
 There are two variants of this format: `minrank` ranks
 each node by the length of the shortest path from a root node to it.
diff --git a/versions/8.0.1/query/quickstart.mdx b/versions/8.0.1/query/quickstart.mdx
index 6c8c3090..b8aaf910 100644
--- a/versions/8.0.1/query/quickstart.mdx
+++ b/versions/8.0.1/query/quickstart.mdx
@@ -205,7 +205,7 @@ dot -Tpng < graph.in > graph.png
 ```
 If you open up `graph.png`, you should see something like this. The graph below has been simplified to make the essential path details clearer in this guide.
 
-![Diagram showing a relationship from cafe to chef to the dishes: pizza and mac and cheese which diverges into the separate ingredients: cheese, tomatoes, dough, and macaroni.](images/query_graph1.png "Dependency graph")
+![Diagram showing a relationship from cafe to chef to the dishes: pizza and mac and cheese which diverges into the separate ingredients: cheese, tomatoes, dough, and macaroni.](/versions/8.0.1/query/images/query_graph1.png "Dependency graph")
 
 This helps when you want to see the outputs of the different query functions throughout this guide.
 
@@ -421,7 +421,7 @@ bazel query --noimplicit_deps 'deps(:runner)' --output graph > graph2.in
 dot -Tpng < graph2.in > graph2.png
 ```
 
-[![The same graph as the first one except now there is a spoke stemming from the chef target with smoothie which leads to banana and strawberry](images/query_graph2.png "Updated dependency graph")](images/query_graph2.png)
+[![The same graph as the first one except now there is a spoke stemming from the chef target with smoothie which leads to banana and strawberry](/versions/8.0.1/query/images/query_graph2.png "Updated dependency graph")](/query/images/query_graph2.png)
 
 Looking at `graph2.png`, you can see that `Smoothie` has no shared dependencies with other dishes but is just another target that the `Chef` relies on.
 
@@ -465,7 +465,7 @@ bazel query "allpaths(//src/main/java/com/example/restaurant/..., //src/main/jav
 //src/main/java/com/example/restaurant:chef
 ```
 
-![Output path of cafe to chef to pizza,mac and cheese to cheese](images/query_graph3.png "Output path for dependency")
+![Output path of cafe to chef to pizza,mac and cheese to cheese](/versions/8.0.1/query/images/query_graph3.png "Output path for dependency")
 
 The output of `allpaths()` is a little harder to read as it is a flattened list of the dependencies. Visualizing this graph using Graphviz makes the relationship clearer to understand.
 
diff --git a/versions/8.0.1/reference/be/common-definitions.mdx b/versions/8.0.1/reference/be/common-definitions.mdx
index a60cd9bd..1f551397 100644
--- a/versions/8.0.1/reference/be/common-definitions.mdx
+++ b/versions/8.0.1/reference/be/common-definitions.mdx
@@ -75,11 +75,11 @@ rules.
 | `deprecation` | String; [nonconfigurable](#configurable-attributes); default is `None`  An explanatory warning message associated with this target. Typically this is used to notify users that a target has become obsolete, or has become superseded by another rule, is private to a package, or is perhaps considered harmful for some reason. It is a good idea to include some reference (like a webpage, a bug number or example migration CLs) so that one can easily find out what changes are required to avoid the message. If there is a new target that can be used as a drop in replacement, it is a good idea to just migrate all users of the old target.  This attribute has no effect on the way things are built, but it may affect a build tool's diagnostic output. The build tool issues a warning when a rule with a `deprecation` attribute is depended upon by a target in another package.  Intra-package dependencies are exempt from this warning, so that, for example, building the tests of a deprecated rule does not encounter a warning.  If a deprecated target depends on another deprecated target, no warning message is issued.  Once people have stopped using it, the target can be removed. |
 | `distribs` | List of strings; [nonconfigurable](#configurable-attributes); default is `[]`  A list of distribution-method strings to be used for this particular target. This is part of a deprecated licensing API that Bazel no longer uses. Don't use this. |
 | `exec_compatible_with` | List of [labels](/versions/8.0.1/concepts/labels); [nonconfigurable](#configurable-attributes); default is `[]`  A list of `constraint_values` that must be present in the execution platform for this target. This is in addition to any constraints already set by the rule type. Constraints are used to restrict the list of available execution platforms. For more details, see the description of [toolchain resolution](/versions/8.0.1/docs/toolchains#toolchain-resolution). |
-| `exec_properties` | Dictionary of strings; default is `{}`  A dictionary of strings that will be added to the `exec_properties` of a platform selected for this target. See `exec_properties` of the [platform](platforms-and-toolchains#platform) rule.  If a key is present in both the platform and target-level properties, the value will be taken from the target. |
+| `exec_properties` | Dictionary of strings; default is `{}`  A dictionary of strings that will be added to the `exec_properties` of a platform selected for this target. See `exec_properties` of the [platform](/versions/8.0.1/reference/be/platforms-and-toolchains#platform) rule.  If a key is present in both the platform and target-level properties, the value will be taken from the target. |
 | `features` | List of *feature* strings; default is `[]`  A feature is string tag that can be enabled or disabled on a target. The meaning of a feature depends on the rule itself.  This `features` attribute is combined with the [package](/versions/8.0.1/reference/be/functions#package) level `features` attribute. For example, if the features ["a", "b"] are enabled on the package level, and a target's `features` attribute contains ["-a", "c"], the features enabled for the rule will be "b" and "c". [See example](https://github.com/bazelbuild/examples/blob/main/rules/features/BUILD). |
 | `restricted_to` | List of [labels](/versions/8.0.1/concepts/labels); [nonconfigurable](#configurable-attributes); default is `[]`  The list of environments this target can be built for, *instead* of default-supported environments.  This is part of Bazel's constraint system. See `compatible_with` for details. |
 | `tags` | List of strings; [nonconfigurable](#configurable-attributes); default is `[]`  *Tags* can be used on any rule. *Tags* on test and `test_suite` rules are useful for categorizing the tests. *Tags* on non-test targets are used to control sandboxed execution of `genrule`s and [Starlark](/versions/8.0.1/rules/concepts) actions, and for parsing by humans and/or external tools.  Bazel modifies the behavior of its sandboxing code if it finds the following keywords in the `tags` attribute of any test or `genrule` target, or the keys of `execution_requirements` for any Starlark action.   * `no-sandbox` keyword results in the action or test never being   sandboxed; it can still be cached or run remotely - use `no-cache`   or `no-remote` to prevent either or both of those. * `no-cache` keyword results in the action or test never being   cached (locally or remotely). Note: for the purposes of this tag, the disk cache   is considered a local cache, whereas the HTTP and gRPC caches are considered   remote. Other caches, such as Skyframe or the persistent action cache, are not   affected. * `no-remote-cache` keyword results in the action or test never being   cached remotely (but it may be cached locally; it may also be executed remotely).   Note: for the purposes of this tag, the disk cache is considered a local cache,   whereas the HTTP and gRPC caches are considered remote. Other caches, such as   Skyframe or the persistent action cache, are not affected.   If a combination of local disk cache and remote cache are used (combined cache),   it's treated as a remote cache and disabled entirely unless `--incompatible_remote_results_ignore_disk`   is set in which case the local components will be used. * `no-remote-exec` keyword results in the action or test never being   executed remotely (but it may be cached remotely). * `no-remote` keyword prevents the action or test from being executed remotely or   cached remotely. This is equivalent to using both   `no-remote-cache` and `no-remote-exec`. * `no-remote-cache-upload` keyword disables upload part of remote caching of a spawn.   it does not disable remote execution. * `local` keyword precludes the action or test from being remotely cached,   remotely executed, or run inside the sandbox.   For genrules and tests, marking the rule with the `local = True`   attribute has the same effect. * `requires-network` keyword allows access to the external   network from inside the sandbox. This tag only has an effect if sandboxing   is enabled. * `block-network` keyword blocks access to the external   network from inside the sandbox. In this case, only communication   with localhost is allowed. This tag only has an effect if sandboxing is   enabled. * `requires-fakeroot` runs the test or action as uid and gid 0 (i.e., the root   user). This is only supported on Linux. This tag takes precedence over the   `--sandbox_fake_username` command-line option.   *Tags* on tests are generally used to annotate a test's role in your debug and release process. Typically, tags are most useful for C++ and Python tests, which lack any runtime annotation ability. The use of tags and size elements gives flexibility in assembling suites of tests based around codebase check-in policy.  Bazel modifies test running behavior if it finds the following keywords in the `tags` attribute of the test rule:   * `exclusive` will force the test to be run in the   "exclusive" mode, ensuring that no other tests are running at the   same time. Such tests will be executed in serial fashion after all build   activity and non-exclusive tests have been completed. Remote execution is   disabled for such tests because Bazel doesn't have control over what's   running on a remote machine. * `exclusive-if-local` will force the test to be run in the   "exclusive" mode if it is executed locally, but will run the test in parallel if it's   executed remotely. * `manual` keyword will exclude the target from expansion of target pattern wildcards   (`...`, `:*`, `:all`, etc.) and `test_suite` rules   which do not list the test explicitly when computing the set of top-level targets to build/run   for the `build`, `test`, and `coverage` commands. It does not   affect target wildcard or test suite expansion in other contexts, including the   `query` command. Note that `manual` does not imply that a target should   not be built/run automatically by continuous build/test systems. For example, it may be   desirable to exclude a target from `bazel test ...` because it requires specific   Bazel flags, but still have it included in properly-configured presubmit or continuous test   runs. * `external` keyword will force test to be unconditionally   executed (regardless of `--cache_test_results`   value).  See [Tag Conventions](/versions/8.0.1/reference/test-encyclopedia#tag-conventions) in the Test Encyclopedia for more conventions on tags attached to test targets. |
-| `target_compatible_with` | List of [labels](/versions/8.0.1/concepts/labels); default is `[]`  A list of `constraint_value`s that must be present in the target platform for this target to be considered *compatible*. This is in addition to any constraints already set by the rule type. If the target platform does not satisfy all listed constraints then the target is considered *incompatible*. Incompatible targets are skipped for building and testing when the target pattern is expanded (e.g. `//...`, `:all`). When explicitly specified on the command line, incompatible targets cause Bazel to print an error and cause a build or test failure.  Targets that transitively depend on incompatible targets are themselves considered incompatible. They are also skipped for building and testing.  An empty list (which is the default) signifies that the target is compatible with all platforms. All rules other than [Workspace Rules](workspace) support this attribute. For some rules this attribute has no effect. For example, specifying `target_compatible_with` for a `cc_toolchain` is not useful. See the [Platforms](/versions/8.0.1/docs/platforms#skipping-incompatible-targets) page for more information about incompatible target skipping. |
+| `target_compatible_with` | List of [labels](/versions/8.0.1/concepts/labels); default is `[]`  A list of `constraint_value`s that must be present in the target platform for this target to be considered *compatible*. This is in addition to any constraints already set by the rule type. If the target platform does not satisfy all listed constraints then the target is considered *incompatible*. Incompatible targets are skipped for building and testing when the target pattern is expanded (e.g. `//...`, `:all`). When explicitly specified on the command line, incompatible targets cause Bazel to print an error and cause a build or test failure.  Targets that transitively depend on incompatible targets are themselves considered incompatible. They are also skipped for building and testing.  An empty list (which is the default) signifies that the target is compatible with all platforms. All rules other than [Workspace Rules](/versions/8.0.1/reference/be/workspace) support this attribute. For some rules this attribute has no effect. For example, specifying `target_compatible_with` for a `cc_toolchain` is not useful. See the [Platforms](/versions/8.0.1/docs/platforms#skipping-incompatible-targets) page for more information about incompatible target skipping. |
 | `testonly` | Boolean; [nonconfigurable](#configurable-attributes); default is `False` except for test and test suite targets  If `True`, only testonly targets (such as tests) can depend on this target.  Equivalently, a rule that is not `testonly` is not allowed to depend on any rule that is `testonly`.  Tests (`*_test` rules) and test suites ([test\_suite](/versions/8.0.1/reference/be/general#test_suite) rules) are `testonly` by default.  This attribute is intended to mean that the target should not be contained in binaries that are released to production.  Because testonly is enforced at build time, not run time, and propagates virally through the dependency tree, it should be applied judiciously. For example, stubs and fakes that are useful for unit tests may also be useful for integration tests involving the same binaries that will be released to production, and therefore should probably not be marked testonly. Conversely, rules that are dangerous to even link in, perhaps because they unconditionally override normal behavior, should definitely be marked testonly. |
 | `toolchains` | List of [labels](/versions/8.0.1/concepts/labels); [nonconfigurable](#configurable-attributes); default is `[]`  The set of targets whose [Make variables](/versions/8.0.1/reference/be/make-variables) this target is allowed to access. These targets are either instances of rules that provide `TemplateVariableInfo` or special targets for toolchain types built into Bazel. These include:  * `@bazel_tools//tools/cpp:current_cc_toolchain`* `@rules_java//toolchains:current_java_runtime`   Note that this is distinct from the concept of [toolchain resolution](/versions/8.0.1/docs/toolchains#toolchain-resolution) that is used by rule implementations for platform-dependent configuration. You cannot use this attribute to determine which specific `cc_toolchain` or `java_toolchain` a target will use. |
 | `visibility` | List of [labels](/versions/8.0.1/concepts/labels); [nonconfigurable](#configurable-attributes); default varies  The `visibility` attribute controls whether the target can be depended on by targets in other locations. See the documentation for [visibility](/versions/8.0.1/concepts/visibility).  For targets declared directly in a BUILD file or in legacy macros called from a BUILD file, the default value is the package's `default_visibility` if specified, or else `["//visibility:private"]`. For targets declared in one or more symbolic macros, the default value is always just `["//visibility:private"]` (which makes it useable only within the package containing the macro's code). |
diff --git a/versions/8.0.1/reference/be/functions.mdx b/versions/8.0.1/reference/be/functions.mdx
index b75d7656..472cc284 100644
--- a/versions/8.0.1/reference/be/functions.mdx
+++ b/versions/8.0.1/reference/be/functions.mdx
@@ -34,9 +34,9 @@ file, before any rule.
 | --- | --- |
 | `default_applicable_licenses` | Alias for [`default_package_metadata`](#package.default_package_metadata). |
 | `default_visibility` | List of [labels](/versions/8.0.1/concepts/labels); default is `[]`  The default visibility of the top-level rule targets and symbolic macros in this package — that is, the targets and symbolic macros that are not themselves declared inside a symbolic macro. This attribute is ignored if the target or macro specifies a `visibility` value.  For detailed information about the syntax of this attribute, see the documentation of [visibility](/versions/8.0.1/concepts/visibility). The package default visibility does not apply to [exports\_files](#exports_files), which is public by default. |
-| `default_deprecation` | String; default is `""`  Sets the default [`deprecation`](common-definitions#common.deprecation) message for all rules in this package. |
+| `default_deprecation` | String; default is `""`  Sets the default [`deprecation`](/versions/8.0.1/reference/be/common-definitions#common.deprecation) message for all rules in this package. |
 | `default_package_metadata` | List of [labels](/versions/8.0.1/concepts/labels); default is `[]`  Sets a default list of metadata targets which apply to all other targets in the package. These are typically targets related to OSS package and license declarations. See [rules\_license](https://github.com/bazelbuild/rules_license) for examples. |
-| `default_testonly` | Boolean; default is `False` except as noted  Sets the default [`testonly`](common-definitions#common.testonly) property for all rules in this package.  In packages under `javatests` the default value is `True`. |
+| `default_testonly` | Boolean; default is `False` except as noted  Sets the default [`testonly`](/versions/8.0.1/reference/be/common-definitions#common.testonly) property for all rules in this package.  In packages under `javatests` the default value is `True`. |
 | `features` | List strings; default is `[]`  Sets various flags that affect the semantics of this BUILD file.  This feature is mainly used by the people working on the build system to tag packages that need some kind of special handling. Do not use this unless explicitly requested by someone working on the build system. |
 
 ### Examples
@@ -66,7 +66,7 @@ visible target can only be referenced within its own package (not subpackages).
 In between these extremes, a target may allow access to its own package plus any
 of the packages described by one or more package groups. For a more detailed
 explanation of the visibility system, see the
-[visibility](common-definitions#common.visibility)
+[visibility](/versions/8.0.1/reference/be/common-definitions#common.visibility)
 attribute.
 
 A given package is considered to be in the group if it either matches the
@@ -159,7 +159,7 @@ visibility declaration can also be specified; in this case, the files will be
 visible to the targets specified. If no visibility is specified, the files
 will be visible to every package, even if a package default visibility was
 specified in the `package`
-function. The [licenses](common-definitions#common.licenses)
+function. The [licenses](/versions/8.0.1/reference/be/common-definitions#common.licenses)
 can also be specified.
 
 ### Example
@@ -262,8 +262,7 @@ There are several important limitations and caveats:
    package called "Foo.java" (which is allowed, though Bazel warns about it),
    then the consumer of the `glob()` will use the "Foo.java" rule
    (its outputs) instead of the "Foo.java" file. See
-   [GitHub
-   issue #10395](https://github.com/bazelbuild/bazel/issues/10395#issuecomment-583714657) for more details.
+   [GitHub issue #10395](https://github.com/bazelbuild/bazel/issues/10395#issuecomment-583714657) for more details.
 3. Globs may match files in subdirectories. And subdirectory names
    may be wildcarded. However...
 4. Labels are not allowed to cross the package boundary and glob does
@@ -409,7 +408,7 @@ select(
 ```
 
 `select()` is the helper function that makes a rule attribute
-[configurable](common-definitions#configurable-attributes).
+[configurable](/versions/8.0.1/reference/be/common-definitions#configurable-attributes).
 It can replace the right-hand side of
 *almost*
 any attribute assignment so its value depends on command-line Bazel flags.
diff --git a/versions/8.0.1/reference/be/general.mdx b/versions/8.0.1/reference/be/general.mdx
index 866bd21c..356f8a65 100644
--- a/versions/8.0.1/reference/be/general.mdx
+++ b/versions/8.0.1/reference/be/general.mdx
@@ -158,9 +158,9 @@ some build targets.
   [here](/versions/8.0.1/reference/be/common-definitions#configurable-attributes) for more discussion.
 * Avoid repeating identical `config_setting` definitions in different packages.
   Instead, reference a common `config_setting` that defined in a canonical package.
-* [`values`](general#config_setting.values),
-  [`define_values`](general#config_setting.define_values), and
-  [`constraint_values`](general#config_setting.constraint_values)
+* [`values`](/versions/8.0.1/reference/be/general#config_setting.values),
+  [`define_values`](/versions/8.0.1/reference/be/general#config_setting.define_values), and
+  [`constraint_values`](/versions/8.0.1/reference/be/general#config_setting.constraint_values)
   can be used in any combination in the same `config_setting` but at least one must
   be set for any given `config_setting`.
 
@@ -169,10 +169,10 @@ some build targets.
 | Attributes | |
 | --- | --- |
 | `name` | [Name](/versions/8.0.1/concepts/labels#target-names); required  A unique name for this target. |
-| `constraint_values` | List of [labels](/versions/8.0.1/concepts/labels); [nonconfigurable](common-definitions#configurable-attributes); default is `[]` The minimum set of `constraint_values` that the target platform must specify in order to match this `config_setting`. (The execution platform is not considered here.) Any additional constraint values that the platform has are ignored. See [Configurable Build Attributes](https://bazel.build/versions/8.0.1/docs/configurable-attributes#platforms) for details. If two `config_setting`s match in the same `select` and one has all the same flags and `constraint_setting`s as the other plus additional ones, the one with more settings is chosen. This is known as "specialization". For example, a `config_setting` matching `x86` and `Linux` specializes a `config_setting` matching `x86`. If two `config_setting`s match and both have `constraint_value`s not present in the other, this is an error. |
-| `define_values` | Dictionary: String -> String; [nonconfigurable](common-definitions#configurable-attributes); default is `{}` The same as [`values`](/versions/8.0.1/reference/be/general#config_setting.values) but specifically for the `--define` flag. `--define` is special because its syntax (`--define KEY=VAL`) means `KEY=VAL` is a *value* from a Bazel flag perspective.  That means:  ```             config_setting(                 name = "a_and_b",                 values = {                     "define": "a=1",                     "define": "b=2",                 }) ```   doesn't work because the same key (`define`) appears twice in the dictionary. This attribute solves that problem:  ```             config_setting(                 name = "a_and_b",                 define_values = {                     "a": "1",                     "b": "2",                 }) ```   correctly matches `bazel build //foo --define a=1 --define b=2`. `--define` can still appear in [`values`](/versions/8.0.1/reference/be/general#config_setting.values) with normal flag syntax, and can be mixed freely with this attribute as long as dictionary keys remain distinct. |
-| `flag_values` | Dictionary: [label](/versions/8.0.1/concepts/labels) -> String; [nonconfigurable](common-definitions#configurable-attributes); default is `{}` The same as [`values`](/versions/8.0.1/reference/be/general#config_setting.values) but for [user-defined build flags](https://bazel.build/versions/8.0.1/rules/config#user-defined-build-settings). This is a distinct attribute because user-defined flags are referenced as labels while built-in flags are referenced as arbitrary strings. |
-| `values` | Dictionary: String -> String; [nonconfigurable](common-definitions#configurable-attributes); default is `{}` The set of configuration values that match this rule (expressed as build flags) This rule inherits the configuration of the configured target that references it in a `select` statement. It is considered to "match" a Bazel invocation if, for every entry in the dictionary, its configuration matches the entry's expected value. For example `values = {"compilation_mode": "opt"}` matches the invocations `bazel build --compilation_mode=opt ...` and `bazel build -c opt ...` on target-configured rules.  For convenience's sake, configuration values are specified as build flags (without the preceding `"--"`). But keep in mind that the two are not the same. This is because targets can be built in multiple configurations within the same build. For example, an exec configuration's "cpu" matches the value of `--host_cpu`, not `--cpu`. So different instances of the same `config_setting` may match the same invocation differently depending on the configuration of the rule using them.  If a flag is not explicitly set at the command line, its default value is used. If a key appears multiple times in the dictionary, only the last instance is used. If a key references a flag that can be set multiple times on the command line (e.g. `bazel build --copt=foo --copt=bar --copt=baz ...`), a match occurs if *any* of those settings match. |
+| `constraint_values` | List of [labels](/versions/8.0.1/concepts/labels); [nonconfigurable](/versions/8.0.1/reference/be/common-definitions#configurable-attributes); default is `[]` The minimum set of `constraint_values` that the target platform must specify in order to match this `config_setting`. (The execution platform is not considered here.) Any additional constraint values that the platform has are ignored. See [Configurable Build Attributes](https://bazel.build/versions/8.0.1/docs/configurable-attributes#platforms) for details. If two `config_setting`s match in the same `select` and one has all the same flags and `constraint_setting`s as the other plus additional ones, the one with more settings is chosen. This is known as "specialization". For example, a `config_setting` matching `x86` and `Linux` specializes a `config_setting` matching `x86`. If two `config_setting`s match and both have `constraint_value`s not present in the other, this is an error. |
+| `define_values` | Dictionary: String -> String; [nonconfigurable](/versions/8.0.1/reference/be/common-definitions#configurable-attributes); default is `{}` The same as [`values`](/versions/8.0.1/reference/be/general#config_setting.values) but specifically for the `--define` flag. `--define` is special because its syntax (`--define KEY=VAL`) means `KEY=VAL` is a *value* from a Bazel flag perspective.  That means:  ```             config_setting(                 name = "a_and_b",                 values = {                     "define": "a=1",                     "define": "b=2",                 }) ```   doesn't work because the same key (`define`) appears twice in the dictionary. This attribute solves that problem:  ```             config_setting(                 name = "a_and_b",                 define_values = {                     "a": "1",                     "b": "2",                 }) ```   correctly matches `bazel build //foo --define a=1 --define b=2`. `--define` can still appear in [`values`](/versions/8.0.1/reference/be/general#config_setting.values) with normal flag syntax, and can be mixed freely with this attribute as long as dictionary keys remain distinct. |
+| `flag_values` | Dictionary: [label](/versions/8.0.1/concepts/labels) -> String; [nonconfigurable](/versions/8.0.1/reference/be/common-definitions#configurable-attributes); default is `{}` The same as [`values`](/versions/8.0.1/reference/be/general#config_setting.values) but for [user-defined build flags](https://bazel.build/versions/8.0.1/rules/config#user-defined-build-settings). This is a distinct attribute because user-defined flags are referenced as labels while built-in flags are referenced as arbitrary strings. |
+| `values` | Dictionary: String -> String; [nonconfigurable](/versions/8.0.1/reference/be/common-definitions#configurable-attributes); default is `{}` The set of configuration values that match this rule (expressed as build flags) This rule inherits the configuration of the configured target that references it in a `select` statement. It is considered to "match" a Bazel invocation if, for every entry in the dictionary, its configuration matches the entry's expected value. For example `values = {"compilation_mode": "opt"}` matches the invocations `bazel build --compilation_mode=opt ...` and `bazel build -c opt ...` on target-configured rules.  For convenience's sake, configuration values are specified as build flags (without the preceding `"--"`). But keep in mind that the two are not the same. This is because targets can be built in multiple configurations within the same build. For example, an exec configuration's "cpu" matches the value of `--host_cpu`, not `--cpu`. So different instances of the same `config_setting` may match the same invocation differently depending on the configuration of the rule using them.  If a flag is not explicitly set at the command line, its default value is used. If a key appears multiple times in the dictionary, only the last instance is used. If a key references a flag that can be set multiple times on the command line (e.g. `bazel build --copt=foo --copt=bar --copt=baz ...`), a match occurs if *any* of those settings match. |
 
 ## filegroup
 
@@ -466,7 +466,7 @@ genrule(
 | --- | --- |
 | `name` | [Name](/versions/8.0.1/concepts/labels#target-names); required  A unique name for this target.  You may refer to this rule by name in the `srcs` or `deps` section of other `BUILD` rules. If the rule generates source files, you should use the `srcs` attribute. |
 | `srcs` | List of [labels](/versions/8.0.1/concepts/labels); default is `[]` A list of inputs for this rule, such as source files to process. *This attributes is not suitable to list tools executed by the `cmd`; use the [`tools`](/versions/8.0.1/reference/be/general#genrule.tools) attribute for them instead.*  The build system ensures these prerequisites are built before running the genrule command; they are built using the same configuration as the original build request. The names of the files of these prerequisites are available to the command as a space-separated list in `$(SRCS)`; alternatively the path of an individual `srcs` target `//x:y` can be obtained using `$(location //x:y)`, or using `$<` provided it's the only entry in `srcs`. |
-| `outs` | List of [filenames](/versions/8.0.1/concepts/build-ref#filename); [nonconfigurable](common-definitions#configurable-attributes); required A list of files generated by this rule. Output files must not cross package boundaries. Output filenames are interpreted as relative to the package.  If the `executable` flag is set, `outs` must contain exactly one label.  The genrule command is expected to create each output file at a predetermined location. The location is available in `cmd` using [genrule-specific "Make" variables](/versions/8.0.1/reference/be/make-variables#predefined_genrule_variables) (`$@`, `$(OUTS)`, `$(@D)` or `$(RULEDIR)`) or using [`$(location)`](/versions/8.0.1/reference/be/make-variables#predefined_label_variables) substitution. |
+| `outs` | List of [filenames](/versions/8.0.1/concepts/build-ref#filename); [nonconfigurable](/versions/8.0.1/reference/be/common-definitions#configurable-attributes); required A list of files generated by this rule. Output files must not cross package boundaries. Output filenames are interpreted as relative to the package.  If the `executable` flag is set, `outs` must contain exactly one label.  The genrule command is expected to create each output file at a predetermined location. The location is available in `cmd` using [genrule-specific "Make" variables](/versions/8.0.1/reference/be/make-variables#predefined_genrule_variables) (`$@`, `$(OUTS)`, `$(@D)` or `$(RULEDIR)`) or using [`$(location)`](/versions/8.0.1/reference/be/make-variables#predefined_label_variables) substitution. |
 | `cmd` | String; default is `""` The command to run. Subject to [`$(location)`](/versions/8.0.1/reference/be/make-variables#predefined_label_variables) and ["Make" variable](/versions/8.0.1/reference/be/make-variables) substitution.  1. First [`$(location)`](/versions/8.0.1/reference/be/make-variables#predefined_label_variables) substitution is applied, replacing all occurrences of `$(location     label)` and of `$(locations label)` (and similar    constructions using related variables `execpath`, `execpaths`,    `rootpath` and `rootpaths`). 2. Next, ["Make" variables](/versions/8.0.1/reference/be/make-variables) are expanded. Note that    predefined variables `$(JAVA)`, `$(JAVAC)` and    `$(JAVABASE)` expand under the *exec* configuration, so Java invocations    that run as part of a build step can correctly load shared libraries and other    dependencies. 3. Finally, the resulting command is executed using the Bash shell. If its exit code is    non-zero the command is considered to have failed.  This is the fallback of `cmd_bash`, `cmd_ps` and `cmd_bat`, if none of them are applicable. |
 
 If the command line length exceeds the platform limit (64K on Linux/macOS, 8K on Windows),
@@ -477,11 +477,11 @@ applies to all cmd attributes (`cmd`, `cmd_bash`, `cmd_ps`,
 | `cmd_bash` | String; default is `""` The Bash command to run. This attribute has higher priority than `cmd`. The command is expanded and runs in the exact same way as the `cmd` attribute. |
 | `cmd_bat` | String; default is `""` The Batch command to run on Windows. This attribute has higher priority than `cmd` and `cmd_bash`. The command runs in the similar way as the `cmd` attribute, with the following differences:   * This attribute only applies on Windows. * The command runs with `cmd.exe /c` with the following default arguments:   + `/S` - strip first and last quotes and execute everything else as is.   + `/E:ON` - enable extended command set.   + `/V:ON` - enable delayed variable expansion   + `/D` - ignore AutoRun registry entries. * After [$(location)](/versions/8.0.1/reference/be/make-variables#predefined_label_variables) and   ["Make" variable](/versions/8.0.1/reference/be/make-variables) substitution, the paths will be   expanded to Windows style paths (with backslash). |
 | `cmd_ps` | String; default is `""` The Powershell command to run on Windows. This attribute has higher priority than `cmd`, `cmd_bash` and `cmd_bat`. The command runs in the similar way as the `cmd` attribute, with the following differences:   * This attribute only applies on Windows. * The command runs with `powershell.exe /c`.   To make Powershell easier to use and less error-prone, we run the following commands to set up the environment before executing Powershell command in genrule.   * `Set-ExecutionPolicy -Scope CurrentUser RemoteSigned` - allow running   unsigned scripts. * `$errorActionPreference='Stop'` - In case there are multiple commands   separated by `;`, the action exits immediately if a Powershell CmdLet fails,   but this does **NOT** work for external command. * `$PSDefaultParameterValues['*:Encoding'] = 'utf8'` - change the default   encoding from utf-16 to utf-8. |
-| `executable` | Boolean; [nonconfigurable](common-definitions#configurable-attributes); default is `False` Declare output to be executable. Setting this flag to True means the output is an executable file and can be run using the `run` command. The genrule must produce exactly one output in this case. If this attribute is set, `run` will try executing the file regardless of its content.  Declaring data dependencies for the generated executable is not supported. |
+| `executable` | Boolean; [nonconfigurable](/versions/8.0.1/reference/be/common-definitions#configurable-attributes); default is `False` Declare output to be executable. Setting this flag to True means the output is an executable file and can be run using the `run` command. The genrule must produce exactly one output in this case. If this attribute is set, `run` will try executing the file regardless of its content.  Declaring data dependencies for the generated executable is not supported. |
 | `local` | Boolean; default is `False`  If set to True, this option forces this `genrule` to run using the "local" strategy, which means no remote execution, no sandboxing, no persistent workers.  This is equivalent to providing 'local' as a tag (`tags=["local"]`). |
 | `message` | String; default is `""` A progress message. A progress message that will be printed as this build step is executed. By default, the message is "Generating *output*" (or something equally bland) but you may provide a more specific one. Use this attribute instead of `echo` or other print statements in your `cmd` command, as this allows the build tool to control whether such progress messages are printed or not. |
 | `output_licenses` | Licence type; default is `["none"]` See [`common attributes`](/versions/8.0.1/reference/be/common-definitions#binary.output_licenses) |
-| `output_to_bindir` | Boolean; [nonconfigurable](common-definitions#configurable-attributes); default is `False`  If set to True, this option causes output files to be written into the `bin` directory instead of the `genfiles` directory. |
+| `output_to_bindir` | Boolean; [nonconfigurable](/versions/8.0.1/reference/be/common-definitions#configurable-attributes); default is `False`  If set to True, this option causes output files to be written into the `bin` directory instead of the `genfiles` directory. |
 | `tools` | List of [labels](/versions/8.0.1/concepts/labels); default is `[]` A list of *tool* dependencies for this rule. See the definition of [dependencies](/versions/8.0.1/concepts/build-ref#deps) for more information.   The build system ensures these prerequisites are built before running the genrule command; they are built using the [*exec* configuration](/versions/8.0.1/contribute/guide#configurations), since these tools are executed as part of the build. The path of an individual `tools` target `//x:y` can be obtained using `$(location //x:y)`.  Any `*_binary` or tool to be executed by `cmd` must appear in this list, not in `srcs`, to ensure they are built in the correct configuration. |
 
 ## starlark\_doc\_extract
@@ -571,5 +571,5 @@ test_suite(
 | Attributes | |
 | --- | --- |
 | `name` | [Name](/versions/8.0.1/concepts/labels#target-names); required  A unique name for this target. |
-| `tags` | List of strings; [nonconfigurable](common-definitions#configurable-attributes); default is `[]` List of text tags such as "small" or "database" or "-flaky". Tags may be any valid string. Tags which begin with a "-" character are considered negative tags. The preceding "-" character is not considered part of the tag, so a suite tag of "-small" matches a test's "small" size. All other tags are considered positive tags.  Optionally, to make positive tags more explicit, tags may also begin with the "+" character, which will not be evaluated as part of the text of the tag. It merely makes the positive and negative distinction easier to read.  Only test rules that match **all** of the positive tags and **none** of the negative tags will be included in the test suite. Note that this does not mean that error checking for dependencies on tests that are filtered out is skipped; the dependencies on skipped tests still need to be legal (e.g. not blocked by visibility constraints).  The `manual` tag keyword is treated differently than the above by the "test\_suite expansion" performed by the `bazel test` command on invocations involving wildcard [target patterns](https://bazel.build/versions/8.0.1/docs/build#specifying-build-targets). There, `test_suite` targets tagged "manual" are filtered out (and thus not expanded). This behavior is consistent with how `bazel build` and `bazel test` handle wildcard target patterns in general. Note that this is explicitly different from how `bazel query 'tests(E)'` behaves, as suites are always expanded by the `tests` query function, regardless of the `manual` tag.  Note that a test's `size` is considered a tag for the purpose of filtering.  If you need a `test_suite` that contains tests with mutually exclusive tags (e.g. all small and medium tests), you'll have to create three `test_suite` rules: one for all small tests, one for all medium tests, and one that includes the previous two. |
-| `tests` | List of [labels](/versions/8.0.1/concepts/labels); [nonconfigurable](common-definitions#configurable-attributes); default is `[]` A list of test suites and test targets of any language. Any `*_test` is accepted here, independent of the language. No `*_binary` targets are accepted however, even if they happen to run a test. Filtering by the specified `tags` is only done for tests listed directly in this attribute. If this attribute contains `test_suite`s, the tests inside those will not be filtered by this `test_suite` (they are considered to be filtered already).  If the `tests` attribute is unspecified or empty, the rule will default to including all test rules in the current BUILD file that are not tagged as `manual`. These rules are still subject to `tag` filtering. |
\ No newline at end of file
+| `tags` | List of strings; [nonconfigurable](/versions/8.0.1/reference/be/common-definitions#configurable-attributes); default is `[]` List of text tags such as "small" or "database" or "-flaky". Tags may be any valid string. Tags which begin with a "-" character are considered negative tags. The preceding "-" character is not considered part of the tag, so a suite tag of "-small" matches a test's "small" size. All other tags are considered positive tags.  Optionally, to make positive tags more explicit, tags may also begin with the "+" character, which will not be evaluated as part of the text of the tag. It merely makes the positive and negative distinction easier to read.  Only test rules that match **all** of the positive tags and **none** of the negative tags will be included in the test suite. Note that this does not mean that error checking for dependencies on tests that are filtered out is skipped; the dependencies on skipped tests still need to be legal (e.g. not blocked by visibility constraints).  The `manual` tag keyword is treated differently than the above by the "test\_suite expansion" performed by the `bazel test` command on invocations involving wildcard [target patterns](https://bazel.build/versions/8.0.1/docs/build#specifying-build-targets). There, `test_suite` targets tagged "manual" are filtered out (and thus not expanded). This behavior is consistent with how `bazel build` and `bazel test` handle wildcard target patterns in general. Note that this is explicitly different from how `bazel query 'tests(E)'` behaves, as suites are always expanded by the `tests` query function, regardless of the `manual` tag.  Note that a test's `size` is considered a tag for the purpose of filtering.  If you need a `test_suite` that contains tests with mutually exclusive tags (e.g. all small and medium tests), you'll have to create three `test_suite` rules: one for all small tests, one for all medium tests, and one that includes the previous two. |
+| `tests` | List of [labels](/versions/8.0.1/concepts/labels); [nonconfigurable](/versions/8.0.1/reference/be/common-definitions#configurable-attributes); default is `[]` A list of test suites and test targets of any language. Any `*_test` is accepted here, independent of the language. No `*_binary` targets are accepted however, even if they happen to run a test. Filtering by the specified `tags` is only done for tests listed directly in this attribute. If this attribute contains `test_suite`s, the tests inside those will not be filtered by this `test_suite` (they are considered to be filtered already).  If the `tests` attribute is unspecified or empty, the rule will default to including all test rules in the current BUILD file that are not tagged as `manual`. These rules are still subject to `tag` filtering. |
\ No newline at end of file
diff --git a/versions/8.0.1/reference/be/java.mdx b/versions/8.0.1/reference/be/java.mdx
index 99d9f962..9b7c7ab1 100644
--- a/versions/8.0.1/reference/be/java.mdx
+++ b/versions/8.0.1/reference/be/java.mdx
@@ -15,7 +15,7 @@ title: 'Java Rules'
 
 ## java\_binary
 
-[View rule sourceopen\_in\_new](@rules_java//java/bazel/rules/bazel_java_binary.bzl)
+[View rule sourceopen\_in\_new](/versions/8.0.1/reference/be/@rules_java//java/bazel/rules/bazel_java_binary.bzl)
 
 ```
 java_binary(name, deps, srcs, data, resources, add_exports, add_opens, args, bootclasspath, classpath_resources, compatible_with, create_executable, deploy_env, deploy_manifest_lines, deprecation, distribs, env, exec_compatible_with, exec_properties, features, javacopts, jvm_flags, launcher, licenses, main_class, neverlink, output_licenses, plugins, resource_strip_prefix, restricted_to, runtime_deps, stamp, tags, target_compatible_with, testonly, toolchains, use_launcher, use_testrunner, visibility)
@@ -102,7 +102,7 @@ java_binary(
 | Attributes | |
 | --- | --- |
 | `name` | [Name](/versions/8.0.1/concepts/labels#target-names); required  A unique name for this target. |
-| `deps` | List of [labels](/versions/8.0.1/concepts/labels); default is `[]` The list of other libraries to be linked in to the target. See general comments about `deps` at [Typical attributes defined by most build rules](common-definitions#typical-attributes). |
+| `deps` | List of [labels](/versions/8.0.1/concepts/labels); default is `[]` The list of other libraries to be linked in to the target. See general comments about `deps` at [Typical attributes defined by most build rules](/versions/8.0.1/reference/be/common-definitions#typical-attributes). |
 | `srcs` | List of [labels](/versions/8.0.1/concepts/labels); default is `[]` The list of source files that are processed to create the target. This attribute is almost always required; see exceptions below. Source files of type `.java` are compiled. In case of generated `.java` files it is generally advisable to put the generating rule's name here instead of the name of the file itself. This not only improves readability but makes the rule more resilient to future changes: if the generating rule generates different files in the future, you only need to fix one place: the `outs` of the generating rule. You should not list the generating rule in `deps` because it is a no-op.  Source files of type `.srcjar` are unpacked and compiled. (This is useful if you need to generate a set of `.java` files with a genrule.)  Rules: if the rule (typically `genrule` or `filegroup`) generates any of the files listed above, they will be used the same way as described for source files.  This argument is almost always required, except if a [`main_class`](#java_binary.main_class) attribute specifies a class on the runtime classpath or you specify the `runtime_deps` argument. |
 | `data` | List of [labels](/versions/8.0.1/concepts/labels); default is `[]` The list of files needed by this library at runtime. See general comments about `data` at [Typical attributes defined by most build rules](/versions/8.0.1/reference/be/common-definitions#typical-attributes). |
 | `resources` | List of [labels](/versions/8.0.1/concepts/labels); default is `[]` A list of data files to include in a Java jar. Resources may be source files or generated files.  If resources are specified, they will be bundled in the jar along with the usual `.class` files produced by compilation. The location of the resources inside of the jar file is determined by the project structure. Bazel first looks for Maven's [standard directory layout](https://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html), (a "src" directory followed by a "resources" directory grandchild). If that is not found, Bazel then looks for the topmost directory named "java" or "javatests" (so, for example, if a resource is at `/x/java/y/java/z`, the path of the resource will be `y/java/z`. This heuristic cannot be overridden, however, the `resource_strip_prefix` attribute can be used to specify a specific alternative directory for resource files. |
@@ -112,9 +112,9 @@ java_binary(
 | `classpath_resources` | List of [labels](/versions/8.0.1/concepts/labels); default is `[]` *DO NOT USE THIS OPTION UNLESS THERE IS NO OTHER WAY)* A list of resources that must be located at the root of the java tree. This attribute's only purpose is to support third-party libraries that require that their resources be found on the classpath as exactly `"myconfig.xml"`. It is only allowed on binaries and not libraries, due to the danger of namespace conflicts. |
 | `create_executable` | Boolean; default is `True` Deprecated, use `java_single_jar` instead. |
 | `deploy_env` | List of [labels](/versions/8.0.1/concepts/labels); default is `[]` A list of other `java_binary` targets which represent the deployment environment for this binary. Set this attribute when building a plugin which will be loaded by another `java_binary`.  Setting this attribute excludes all dependencies from the runtime classpath (and the deploy jar) of this binary that are shared between this binary and the targets specified in `deploy_env`. |
-| `deploy_manifest_lines` | List of strings; default is `[]` A list of lines to add to the `META-INF/manifest.mf` file generated for the `*_deploy.jar` target. The contents of this attribute are *not* subject to ["Make variable"](make-variables) substitution. |
-| `javacopts` | List of strings; default is `[]` Extra compiler options for this binary. Subject to ["Make variable"](make-variables) substitution and [Bourne shell tokenization](common-definitions#sh-tokenization). These compiler options are passed to javac after the global compiler options. |
-| `jvm_flags` | List of strings; default is `[]` A list of flags to embed in the wrapper script generated for running this binary. Subject to [$(location)](/versions/8.0.1/reference/be/make-variables#location) and ["Make variable"](make-variables) substitution, and [Bourne shell tokenization](common-definitions#sh-tokenization). The wrapper script for a Java binary includes a CLASSPATH definition (to find all the dependent jars) and invokes the right Java interpreter. The command line generated by the wrapper script includes the name of the main class followed by a `"$@"` so you can pass along other arguments after the classname. However, arguments intended for parsing by the JVM must be specified *before* the classname on the command line. The contents of `jvm_flags` are added to the wrapper script before the classname is listed.  Note that this attribute has *no effect* on `*_deploy.jar` outputs. |
+| `deploy_manifest_lines` | List of strings; default is `[]` A list of lines to add to the `META-INF/manifest.mf` file generated for the `*_deploy.jar` target. The contents of this attribute are *not* subject to ["Make variable"](/versions/8.0.1/reference/be/make-variables) substitution. |
+| `javacopts` | List of strings; default is `[]` Extra compiler options for this binary. Subject to ["Make variable"](/versions/8.0.1/reference/be/make-variables) substitution and [Bourne shell tokenization](/versions/8.0.1/reference/be/common-definitions#sh-tokenization). These compiler options are passed to javac after the global compiler options. |
+| `jvm_flags` | List of strings; default is `[]` A list of flags to embed in the wrapper script generated for running this binary. Subject to [$(location)](/versions/8.0.1/reference/be/make-variables#location) and ["Make variable"](/versions/8.0.1/reference/be/make-variables) substitution, and [Bourne shell tokenization](/versions/8.0.1/reference/be/common-definitions#sh-tokenization). The wrapper script for a Java binary includes a CLASSPATH definition (to find all the dependent jars) and invokes the right Java interpreter. The command line generated by the wrapper script includes the name of the main class followed by a `"$@"` so you can pass along other arguments after the classname. However, arguments intended for parsing by the JVM must be specified *before* the classname on the command line. The contents of `jvm_flags` are added to the wrapper script before the classname is listed.  Note that this attribute has *no effect* on `*_deploy.jar` outputs. |
 | `launcher` | [Label](/versions/8.0.1/concepts/labels); default is `None` Specify a binary that will be used to run your Java program instead of the normal `bin/java` program included with the JDK. The target must be a `cc_binary`. Any `cc_binary` that implements the [Java Invocation API](http://docs.oracle.com/javase/7/docs/technotes/guides/jni/spec/invocation.html) can be specified as a value for this attribute. By default, Bazel will use the normal JDK launcher (bin/java or java.exe).  The related [`--java_launcher`](/versions/8.0.1/docs/user-manual#flag--java_launcher) Bazel flag affects only those `java_binary` and `java_test` targets that have *not* specified a `launcher` attribute.  Note that your native (C++, SWIG, JNI) dependencies will be built differently depending on whether you are using the JDK launcher or another launcher:   * If you are using the normal JDK launcher (the default), native dependencies are   built as a shared library named `{name}_nativedeps.so`, where   `{name}` is the `name` attribute of this java\_binary rule.   Unused code is *not* removed by the linker in this configuration. * If you are using any other launcher, native (C++) dependencies are statically   linked into a binary named `{name}_nativedeps`, where `{name}`   is the `name` attribute of this java\_binary rule. In this case,   the linker will remove any code it thinks is unused from the resulting binary,   which means any C++ code accessed only via JNI may not be linked in unless   that `cc_library` target specifies `alwayslink = True`.   When using any launcher other than the default JDK launcher, the format of the `*_deploy.jar` output changes. See the main [java\_binary](#java_binary) docs for details. |
 | `main_class` | String; default is `""` Name of class with `main()` method to use as entry point. If a rule uses this option, it does not need a `srcs=[...]` list. Thus, with this attribute one can make an executable from a Java library that already contains one or more `main()` methods. The value of this attribute is a class name, not a source file. The class must be available at runtime: it may be compiled by this rule (from `srcs`) or provided by direct or transitive dependencies (through `runtime_deps` or `deps`). If the class is unavailable, the binary will fail at runtime; there is no build-time check. |
 | `neverlink` | Boolean; default is `False` |
@@ -127,7 +127,7 @@ java_binary(
 
 ## java\_import
 
-[View rule sourceopen\_in\_new](@rules_java//java/bazel/rules/bazel_java_import.bzl)
+[View rule sourceopen\_in\_new](/versions/8.0.1/reference/be/@rules_java//java/bazel/rules/bazel_java_import.bzl)
 
 ```
 java_import(name, deps, data, add_exports, add_opens, compatible_with, constraints, deprecation, distribs, exec_compatible_with, exec_properties, exports, features, jars, licenses, neverlink, proguard_specs, restricted_to, runtime_deps, srcjar, tags, target_compatible_with, testonly, toolchains, visibility)
@@ -169,7 +169,7 @@ libraries for `java_library` and
 
 ## java\_library
 
-[View rule sourceopen\_in\_new](@rules_java//java/bazel/rules/bazel_java_library.bzl)
+[View rule sourceopen\_in\_new](/versions/8.0.1/reference/be/@rules_java//java/bazel/rules/bazel_java_library.bzl)
 
 ```
 java_library(name, deps, srcs, data, resources, add_exports, add_opens, bootclasspath, compatible_with, deprecation, distribs, exec_compatible_with, exec_properties, exported_plugins, exports, features, javabuilder_jvm_flags, javacopts, licenses, neverlink, plugins, proguard_specs, resource_strip_prefix, restricted_to, runtime_deps, tags, target_compatible_with, testonly, toolchains, visibility)
@@ -198,7 +198,7 @@ This rule compiles and links sources into a `.jar` file.
 | `exported_plugins` | List of [labels](/versions/8.0.1/concepts/labels); default is `[]` The list of `java_plugin`s (e.g. annotation processors) to export to libraries that directly depend on this library. The specified list of `java_plugin`s will be applied to any library which directly depends on this library, just as if that library had explicitly declared these labels in `plugins`. |
 | `exports` | List of [labels](/versions/8.0.1/concepts/labels); default is `[]` Exported libraries. Listing rules here will make them available to parent rules, as if the parents explicitly depended on these rules. This is not true for regular (non-exported) `deps`.  Summary: a rule *X* can access the code in *Y* if there exists a dependency path between them that begins with a `deps` edge followed by zero or more `exports` edges. Let's see some examples to illustrate this.  Assume *A* depends on *B* and *B* depends on *C*. In this case C is a *transitive* dependency of A, so changing C's sources and rebuilding A will correctly rebuild everything. However A will not be able to use classes in C. To allow that, either A has to declare C in its `deps`, or B can make it easier for A (and anything that may depend on A) by declaring C in its (B's) `exports` attribute.  The closure of exported libraries is available to all direct parent rules. Take a slightly different example: A depends on B, B depends on C and D, and also exports C but not D. Now A has access to C but not to D. Now, if C and D exported some libraries, C' and D' respectively, A could only access C' but not D'.  Important: an exported rule is not a regular dependency. Sticking to the previous example, if B exports C and wants to also use C, it has to also list it in its own `deps`. |
 | `javabuilder_jvm_flags` | List of strings; default is `[]` Restricted API, do not use! |
-| `javacopts` | List of strings; default is `[]` Extra compiler options for this library. Subject to ["Make variable"](make-variables) substitution and [Bourne shell tokenization](common-definitions#sh-tokenization). These compiler options are passed to javac after the global compiler options. |
+| `javacopts` | List of strings; default is `[]` Extra compiler options for this library. Subject to ["Make variable"](/versions/8.0.1/reference/be/make-variables) substitution and [Bourne shell tokenization](/versions/8.0.1/reference/be/common-definitions#sh-tokenization). These compiler options are passed to javac after the global compiler options. |
 | `neverlink` | Boolean; default is `False` Whether this library should only be used for compilation and not at runtime. Useful if the library will be provided by the runtime environment during execution. Examples of such libraries are the IDE APIs for IDE plug-ins or `tools.jar` for anything running on a standard JDK. Note that `neverlink = True` does not prevent the compiler from inlining material from this library into compilation targets that depend on it, as permitted by the Java Language Specification (e.g., `static final` constants of `String` or of primitive types). The preferred use case is therefore when the runtime library is identical to the compilation library.  If the runtime library differs from the compilation library then you must ensure that it differs only in places that the JLS forbids compilers to inline (and that must hold for all future versions of the JLS). |
 | `plugins` | List of [labels](/versions/8.0.1/concepts/labels); default is `[]` Java compiler plugins to run at compile-time. Every `java_plugin` specified in this attribute will be run whenever this rule is built. A library may also inherit plugins from dependencies that use `exported_plugins`. Resources generated by the plugin will be included in the resulting jar of this rule. |
 | `proguard_specs` | List of [labels](/versions/8.0.1/concepts/labels); default is `[]` Files to be used as Proguard specification. These will describe the set of specifications to be used by Proguard. If specified, they will be added to any `android_binary` target depending on this library. The files included here must only have idempotent rules, namely -dontnote, -dontwarn, assumenosideeffects, and rules that start with -keep. Other options can only appear in `android_binary`'s proguard\_specs, to ensure non-tautological merges. |
@@ -207,7 +207,7 @@ This rule compiles and links sources into a `.jar` file.
 
 ## java\_test
 
-[View rule sourceopen\_in\_new](@rules_java//java/bazel/rules/bazel_java_test.bzl)
+[View rule sourceopen\_in\_new](/versions/8.0.1/reference/be/@rules_java//java/bazel/rules/bazel_java_test.bzl)
 
 ```
 java_test(name, deps, srcs, data, resources, add_exports, add_opens, args, bootclasspath, classpath_resources, compatible_with, create_executable, deploy_manifest_lines, deprecation, distribs, env, env_inherit, exec_compatible_with, exec_properties, features, flaky, javacopts, jvm_flags, launcher, licenses, local, main_class, neverlink, plugins, resource_strip_prefix, restricted_to, runtime_deps, shard_count, size, stamp, tags, target_compatible_with, test_class, testonly, timeout, toolchains, use_launcher, use_testrunner, visibility)
@@ -225,8 +225,7 @@ test code. The test runner's main method is invoked instead of the main class be
   [java\_binary](#java_binary) for more details.
 
 See the section on `java_binary()` arguments. This rule also
-supports all [attributes common
-to all test rules (\*\_test)](https://bazel.build/versions/8.0.1/reference/be/common-definitions#common-attributes-tests).
+supports all [attributes common to all test rules (\*\_test)](https://bazel.build/versions/8.0.1/reference/be/common-definitions#common-attributes-tests).
 
 #### Examples
 
@@ -255,7 +254,7 @@ java_test(
 | Attributes | |
 | --- | --- |
 | `name` | [Name](/versions/8.0.1/concepts/labels#target-names); required  A unique name for this target. |
-| `deps` | List of [labels](/versions/8.0.1/concepts/labels); default is `[]` The list of other libraries to be linked in to the target. See general comments about `deps` at [Typical attributes defined by most build rules](common-definitions#typical-attributes). |
+| `deps` | List of [labels](/versions/8.0.1/concepts/labels); default is `[]` The list of other libraries to be linked in to the target. See general comments about `deps` at [Typical attributes defined by most build rules](/versions/8.0.1/reference/be/common-definitions#typical-attributes). |
 | `srcs` | List of [labels](/versions/8.0.1/concepts/labels); default is `[]` The list of source files that are processed to create the target. This attribute is almost always required; see exceptions below. Source files of type `.java` are compiled. In case of generated `.java` files it is generally advisable to put the generating rule's name here instead of the name of the file itself. This not only improves readability but makes the rule more resilient to future changes: if the generating rule generates different files in the future, you only need to fix one place: the `outs` of the generating rule. You should not list the generating rule in `deps` because it is a no-op.  Source files of type `.srcjar` are unpacked and compiled. (This is useful if you need to generate a set of `.java` files with a genrule.)  Rules: if the rule (typically `genrule` or `filegroup`) generates any of the files listed above, they will be used the same way as described for source files.  This argument is almost always required, except if a [`main_class`](#java_binary.main_class) attribute specifies a class on the runtime classpath or you specify the `runtime_deps` argument. |
 | `data` | List of [labels](/versions/8.0.1/concepts/labels); default is `[]` The list of files needed by this library at runtime. See general comments about `data` at [Typical attributes defined by most build rules](/versions/8.0.1/reference/be/common-definitions#typical-attributes). |
 | `resources` | List of [labels](/versions/8.0.1/concepts/labels); default is `[]` A list of data files to include in a Java jar. Resources may be source files or generated files.  If resources are specified, they will be bundled in the jar along with the usual `.class` files produced by compilation. The location of the resources inside of the jar file is determined by the project structure. Bazel first looks for Maven's [standard directory layout](https://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html), (a "src" directory followed by a "resources" directory grandchild). If that is not found, Bazel then looks for the topmost directory named "java" or "javatests" (so, for example, if a resource is at `/x/java/y/java/z`, the path of the resource will be `y/java/z`. This heuristic cannot be overridden, however, the `resource_strip_prefix` attribute can be used to specify a specific alternative directory for resource files. |
@@ -264,9 +263,9 @@ java_test(
 | `bootclasspath` | [Label](/versions/8.0.1/concepts/labels); default is `None` Restricted API, do not use! |
 | `classpath_resources` | List of [labels](/versions/8.0.1/concepts/labels); default is `[]` *DO NOT USE THIS OPTION UNLESS THERE IS NO OTHER WAY)* A list of resources that must be located at the root of the java tree. This attribute's only purpose is to support third-party libraries that require that their resources be found on the classpath as exactly `"myconfig.xml"`. It is only allowed on binaries and not libraries, due to the danger of namespace conflicts. |
 | `create_executable` | Boolean; default is `True` Deprecated, use `java_single_jar` instead. |
-| `deploy_manifest_lines` | List of strings; default is `[]` A list of lines to add to the `META-INF/manifest.mf` file generated for the `*_deploy.jar` target. The contents of this attribute are *not* subject to ["Make variable"](make-variables) substitution. |
-| `javacopts` | List of strings; default is `[]` Extra compiler options for this binary. Subject to ["Make variable"](make-variables) substitution and [Bourne shell tokenization](common-definitions#sh-tokenization). These compiler options are passed to javac after the global compiler options. |
-| `jvm_flags` | List of strings; default is `[]` A list of flags to embed in the wrapper script generated for running this binary. Subject to [$(location)](/versions/8.0.1/reference/be/make-variables#location) and ["Make variable"](make-variables) substitution, and [Bourne shell tokenization](common-definitions#sh-tokenization). The wrapper script for a Java binary includes a CLASSPATH definition (to find all the dependent jars) and invokes the right Java interpreter. The command line generated by the wrapper script includes the name of the main class followed by a `"$@"` so you can pass along other arguments after the classname. However, arguments intended for parsing by the JVM must be specified *before* the classname on the command line. The contents of `jvm_flags` are added to the wrapper script before the classname is listed.  Note that this attribute has *no effect* on `*_deploy.jar` outputs. |
+| `deploy_manifest_lines` | List of strings; default is `[]` A list of lines to add to the `META-INF/manifest.mf` file generated for the `*_deploy.jar` target. The contents of this attribute are *not* subject to ["Make variable"](/versions/8.0.1/reference/be/make-variables) substitution. |
+| `javacopts` | List of strings; default is `[]` Extra compiler options for this binary. Subject to ["Make variable"](/versions/8.0.1/reference/be/make-variables) substitution and [Bourne shell tokenization](/versions/8.0.1/reference/be/common-definitions#sh-tokenization). These compiler options are passed to javac after the global compiler options. |
+| `jvm_flags` | List of strings; default is `[]` A list of flags to embed in the wrapper script generated for running this binary. Subject to [$(location)](/versions/8.0.1/reference/be/make-variables#location) and ["Make variable"](/versions/8.0.1/reference/be/make-variables) substitution, and [Bourne shell tokenization](/versions/8.0.1/reference/be/common-definitions#sh-tokenization). The wrapper script for a Java binary includes a CLASSPATH definition (to find all the dependent jars) and invokes the right Java interpreter. The command line generated by the wrapper script includes the name of the main class followed by a `"$@"` so you can pass along other arguments after the classname. However, arguments intended for parsing by the JVM must be specified *before* the classname on the command line. The contents of `jvm_flags` are added to the wrapper script before the classname is listed.  Note that this attribute has *no effect* on `*_deploy.jar` outputs. |
 | `launcher` | [Label](/versions/8.0.1/concepts/labels); default is `None` Specify a binary that will be used to run your Java program instead of the normal `bin/java` program included with the JDK. The target must be a `cc_binary`. Any `cc_binary` that implements the [Java Invocation API](http://docs.oracle.com/javase/7/docs/technotes/guides/jni/spec/invocation.html) can be specified as a value for this attribute. By default, Bazel will use the normal JDK launcher (bin/java or java.exe).  The related [`--java_launcher`](/versions/8.0.1/docs/user-manual#flag--java_launcher) Bazel flag affects only those `java_binary` and `java_test` targets that have *not* specified a `launcher` attribute.  Note that your native (C++, SWIG, JNI) dependencies will be built differently depending on whether you are using the JDK launcher or another launcher:   * If you are using the normal JDK launcher (the default), native dependencies are   built as a shared library named `{name}_nativedeps.so`, where   `{name}` is the `name` attribute of this java\_binary rule.   Unused code is *not* removed by the linker in this configuration. * If you are using any other launcher, native (C++) dependencies are statically   linked into a binary named `{name}_nativedeps`, where `{name}`   is the `name` attribute of this java\_binary rule. In this case,   the linker will remove any code it thinks is unused from the resulting binary,   which means any C++ code accessed only via JNI may not be linked in unless   that `cc_library` target specifies `alwayslink = True`.   When using any launcher other than the default JDK launcher, the format of the `*_deploy.jar` output changes. See the main [java\_binary](#java_binary) docs for details. |
 | `main_class` | String; default is `""` Name of class with `main()` method to use as entry point. If a rule uses this option, it does not need a `srcs=[...]` list. Thus, with this attribute one can make an executable from a Java library that already contains one or more `main()` methods. The value of this attribute is a class name, not a source file. The class must be available at runtime: it may be compiled by this rule (from `srcs`) or provided by direct or transitive dependencies (through `runtime_deps` or `deps`). If the class is unavailable, the binary will fail at runtime; there is no build-time check. |
 | `neverlink` | Boolean; default is `False` |
@@ -280,7 +279,7 @@ java_test(
 
 ## java\_package\_configuration
 
-[View rule sourceopen\_in\_new](@rules_java//java/common/rules/java_package_configuration.bzl)
+[View rule sourceopen\_in\_new](/versions/8.0.1/reference/be/@rules_java//java/common/rules/java_package_configuration.bzl)
 
 ```
 java_package_configuration(name, data, compatible_with, deprecation, distribs, exec_compatible_with, exec_properties, features, javacopts, output_licenses, packages, restricted_to, system, tags, target_compatible_with, testonly, toolchains, visibility)
@@ -328,7 +327,7 @@ java_toolchain(
 
 ## java\_plugin
 
-[View rule sourceopen\_in\_new](@rules_java//java/bazel/rules/bazel_java_plugin.bzl)
+[View rule sourceopen\_in\_new](/versions/8.0.1/reference/be/@rules_java//java/bazel/rules/bazel_java_plugin.bzl)
 
 ```
 java_plugin(name, deps, srcs, data, resources, add_exports, add_opens, bootclasspath, compatible_with, deprecation, distribs, exec_compatible_with, exec_properties, features, generates_api, javabuilder_jvm_flags, javacopts, licenses, neverlink, output_licenses, plugins, processor_class, proguard_specs, resource_strip_prefix, restricted_to, tags, target_compatible_with, testonly, toolchains, visibility)
@@ -362,7 +361,7 @@ for the addition of the `processor_class` argument.
 | `bootclasspath` | [Label](/versions/8.0.1/concepts/labels); default is `None` Restricted API, do not use! |
 | `generates_api` | Boolean; default is `False` This attribute marks annotation processors that generate API code. If a rule uses an API-generating annotation processor, other rules depending on it can refer to the generated code only if their compilation actions are scheduled after the generating rule. This attribute instructs Bazel to introduce scheduling constraints when --java\_header\_compilation is enabled. *WARNING: This attribute affects build performance, use it only if necessary.* |
 | `javabuilder_jvm_flags` | List of strings; default is `[]` Restricted API, do not use! |
-| `javacopts` | List of strings; default is `[]` Extra compiler options for this library. Subject to ["Make variable"](make-variables) substitution and [Bourne shell tokenization](common-definitions#sh-tokenization). These compiler options are passed to javac after the global compiler options. |
+| `javacopts` | List of strings; default is `[]` Extra compiler options for this library. Subject to ["Make variable"](/versions/8.0.1/reference/be/make-variables) substitution and [Bourne shell tokenization](/versions/8.0.1/reference/be/common-definitions#sh-tokenization). These compiler options are passed to javac after the global compiler options. |
 | `neverlink` | Boolean; default is `False` Whether this library should only be used for compilation and not at runtime. Useful if the library will be provided by the runtime environment during execution. Examples of such libraries are the IDE APIs for IDE plug-ins or `tools.jar` for anything running on a standard JDK. Note that `neverlink = True` does not prevent the compiler from inlining material from this library into compilation targets that depend on it, as permitted by the Java Language Specification (e.g., `static final` constants of `String` or of primitive types). The preferred use case is therefore when the runtime library is identical to the compilation library.  If the runtime library differs from the compilation library then you must ensure that it differs only in places that the JLS forbids compilers to inline (and that must hold for all future versions of the JLS). |
 | `output_licenses` | List of strings; default is `[]` |
 | `plugins` | List of [labels](/versions/8.0.1/concepts/labels); default is `[]` Java compiler plugins to run at compile-time. Every `java_plugin` specified in this attribute will be run whenever this rule is built. A library may also inherit plugins from dependencies that use `exported_plugins`. Resources generated by the plugin will be included in the resulting jar of this rule. |
@@ -372,7 +371,7 @@ for the addition of the `processor_class` argument.
 
 ## java\_runtime
 
-[View rule sourceopen\_in\_new](@rules_java//java/common/rules/java_runtime.bzl)
+[View rule sourceopen\_in\_new](/versions/8.0.1/reference/be/@rules_java//java/common/rules/java_runtime.bzl)
 
 ```
 java_runtime(name, srcs, compatible_with, default_cds, deprecation, distribs, exec_compatible_with, exec_properties, features, hermetic_srcs, hermetic_static_libs, java, java_home, lib_ct_sym, lib_modules, output_licenses, restricted_to, tags, target_compatible_with, testonly, toolchains, version, visibility)
@@ -408,7 +407,7 @@ java_runtime(
 
 ## java\_toolchain
 
-[View rule sourceopen\_in\_new](@rules_java//java/common/rules/java_toolchain.bzl)
+[View rule sourceopen\_in\_new](/versions/8.0.1/reference/be/@rules_java//java/common/rules/java_toolchain.bzl)
 
 ```
 java_toolchain(name, android_lint_data, android_lint_jvm_opts, android_lint_opts, android_lint_package_configuration, android_lint_runner, bootclasspath, compatible_javacopts, compatible_with, deprecation, deps_checker, distribs, exec_compatible_with, exec_properties, features, forcibly_disable_header_compilation, genclass, header_compiler, header_compiler_builtin_processors, header_compiler_direct, ijar, jacocorunner, java_runtime, javabuilder, javabuilder_data, javabuilder_jvm_opts, javac_supports_multiplex_workers, javac_supports_worker_cancellation, javac_supports_worker_multiplex_sandboxing, javac_supports_workers, javacopts, jspecify_implicit_deps, jspecify_javacopts, jspecify_packages, jspecify_processor, jspecify_processor_class, jspecify_stubs, jvm_opts, licenses, misc, oneversion, oneversion_allowlist, oneversion_allowlist_for_tests, oneversion_whitelist, package_configuration, proguard_allowlister, reduced_classpath_incompatible_processors, restricted_to, singlejar, source_version, tags, target_compatible_with, target_version, testonly, timezone_data, toolchains, tools, turbine_data, turbine_jvm_opts, visibility, xlint)
diff --git a/versions/8.0.1/reference/be/make-variables.mdx b/versions/8.0.1/reference/be/make-variables.mdx
index 99155f9f..d283105c 100644
--- a/versions/8.0.1/reference/be/make-variables.mdx
+++ b/versions/8.0.1/reference/be/make-variables.mdx
@@ -19,8 +19,7 @@ targets, and *custom* variables, which are defined in dependency targets
 and only available to targets that depend on them.
 
 The reason for the term "Make" is historical: the syntax and semantics of
-these variables were originally intended to match [GNU
-Make](https://www.gnu.org/software/make/manual/html_node/Using-Variables.html).
+these variables were originally intended to match [GNU Make](https://www.gnu.org/software/make/manual/html_node/Using-Variables.html).
 
 ## Use
 
@@ -64,8 +63,7 @@ and look at the top output lines with capital letters.
 **Toolchain option variables**
 
 * `COMPILATION_MODE`:
-  `fastbuild`, `dbg`, or `opt`. ([more
-  details](https://bazel.build/versions/8.0.1/docs/user-manual#flag--compilation_mode))
+  `fastbuild`, `dbg`, or `opt`. ([more details](https://bazel.build/versions/8.0.1/docs/user-manual#flag--compilation_mode))
 
 **Path variables**
 
@@ -304,7 +302,7 @@ rare cases. If you are tempted to use them, please [contact the Bazel devs](http
 
 Rule and [toolchain](/versions/8.0.1/docs/toolchains) writers can define
 completely custom variables by returning a
-[TemplateVariableInfo](/versions/8.0.1/rules/lib/TemplateVariableInfo)
+[TemplateVariableInfo](/versions/8.0.1/rules/lib/providers/TemplateVariableInfo)
 provider. Any rules depending on these through the
 `toolchains` attribute can then read their values:
 
diff --git a/versions/8.0.1/reference/be/overview.mdx b/versions/8.0.1/reference/be/overview.mdx
index db9f12b8..78651993 100644
--- a/versions/8.0.1/reference/be/overview.mdx
+++ b/versions/8.0.1/reference/be/overview.mdx
@@ -37,18 +37,18 @@ For non-native Starlark rules that ship separately from Bazel, see the list of
 
 | Language | Binary rules | Library rules | Test rules | Other rules |
 | --- | --- | --- | --- | --- |
-| C / C++ | [cc\_binary](c-cpp#cc_binary) | [cc\_import](c-cpp#cc_import)   [cc\_library](c-cpp#cc_library)   [cc\_shared\_library](c-cpp#cc_shared_library)   [cc\_static\_library](c-cpp#cc_static_library) |  | [cc\_toolchain\_suite](c-cpp#cc_toolchain_suite) |
-| Java | [java\_binary](java#java_binary) | [java\_import](java#java_import)   [java\_library](java#java_library) | [java\_test](java#java_test) | [java\_package\_configuration](java#java_package_configuration)   [java\_plugin](java#java_plugin)   [java\_runtime](java#java_runtime)   [java\_toolchain](java#java_toolchain) |
-| Objective-C |  | [objc\_import](objective-c#objc_import)   [objc\_library](objective-c#objc_library) |  |  |
-| Protocol Buffer |  | [cc\_proto\_library](protocol-buffer#cc_proto_library)   [java\_lite\_proto\_library](protocol-buffer#java_lite_proto_library)   [java\_proto\_library](protocol-buffer#java_proto_library)   [proto\_library](protocol-buffer#proto_library)   [py\_proto\_library](protocol-buffer#py_proto_library) |  | [proto\_lang\_toolchain](protocol-buffer#proto_lang_toolchain)   [proto\_toolchain](protocol-buffer#proto_toolchain) |
-| Python | [py\_binary](python#py_binary) | [py\_library](python#py_library) | [py\_test](python#py_test) | [py\_runtime](python#py_runtime) |
-| Shell | [sh\_binary](shell#sh_binary) | [sh\_library](shell#sh_library) | [sh\_test](shell#sh_test) |  |
+| C / C++ | [cc\_binary](/versions/8.0.1/reference/be/c-cpp#cc_binary) | [cc\_import](/versions/8.0.1/reference/be/c-cpp#cc_import)   [cc\_library](/versions/8.0.1/reference/be/c-cpp#cc_library)   [cc\_shared\_library](/versions/8.0.1/reference/be/c-cpp#cc_shared_library)   [cc\_static\_library](/versions/8.0.1/reference/be/c-cpp#cc_static_library) |  | [cc\_toolchain\_suite](/versions/8.0.1/reference/be/c-cpp#cc_toolchain_suite) |
+| Java | [java\_binary](/versions/8.0.1/reference/be/java#java_binary) | [java\_import](/versions/8.0.1/reference/be/java#java_import)   [java\_library](/versions/8.0.1/reference/be/java#java_library) | [java\_test](/versions/8.0.1/reference/be/java#java_test) | [java\_package\_configuration](/versions/8.0.1/reference/be/java#java_package_configuration)   [java\_plugin](/versions/8.0.1/reference/be/java#java_plugin)   [java\_runtime](/versions/8.0.1/reference/be/java#java_runtime)   [java\_toolchain](/versions/8.0.1/reference/be/java#java_toolchain) |
+| Objective-C |  | [objc\_import](/versions/8.0.1/reference/be/objective-c#objc_import)   [objc\_library](/versions/8.0.1/reference/be/objective-c#objc_library) |  |  |
+| Protocol Buffer |  | [cc\_proto\_library](/versions/8.0.1/reference/be/protocol-buffer#cc_proto_library)   [java\_lite\_proto\_library](/versions/8.0.1/reference/be/protocol-buffer#java_lite_proto_library)   [java\_proto\_library](/versions/8.0.1/reference/be/protocol-buffer#java_proto_library)   [proto\_library](/versions/8.0.1/reference/be/protocol-buffer#proto_library)   [py\_proto\_library](/versions/8.0.1/reference/be/protocol-buffer#py_proto_library) |  | [proto\_lang\_toolchain](/versions/8.0.1/reference/be/protocol-buffer#proto_lang_toolchain)   [proto\_toolchain](/versions/8.0.1/reference/be/protocol-buffer#proto_toolchain) |
+| Python | [py\_binary](/versions/8.0.1/reference/be/python#py_binary) | [py\_library](/versions/8.0.1/reference/be/python#py_library) | [py\_test](/versions/8.0.1/reference/be/python#py_test) | [py\_runtime](/versions/8.0.1/reference/be/python#py_runtime) |
+| Shell | [sh\_binary](/versions/8.0.1/reference/be/shell#sh_binary) | [sh\_library](/versions/8.0.1/reference/be/shell#sh_library) | [sh\_test](/versions/8.0.1/reference/be/shell#sh_test) |  |
 
 ### Language-agnostic native rules
 
 | Family | Rules |
 | --- | --- |
-| Extra Actions | * [action\_listener](extra-actions#action_listener)* [extra\_action](extra-actions#extra_action) |
-| General | * [alias](general#alias)* [config\_setting](general#config_setting)* [filegroup](general#filegroup)* [genquery](general#genquery)* [genrule](general#genrule)* [starlark\_doc\_extract](general#starlark_doc_extract)* [test\_suite](general#test_suite) |
-| Platforms and Toolchains | * [constraint\_setting](platforms-and-toolchains#constraint_setting)* [constraint\_value](platforms-and-toolchains#constraint_value)* [platform](platforms-and-toolchains#platform)* [toolchain](platforms-and-toolchains#toolchain)* [toolchain\_type](platforms-and-toolchains#toolchain_type) |
-| Workspace | * [bind](workspace#bind)* [local\_repository](workspace#local_repository)* [new\_local\_repository](workspace#new_local_repository) |
\ No newline at end of file
+| Extra Actions | * [action\_listener](/versions/8.0.1/reference/be/extra-actions#action_listener)* [extra\_action](/versions/8.0.1/reference/be/extra-actions#extra_action) |
+| General | * [alias](/versions/8.0.1/reference/be/general#alias)* [config\_setting](/versions/8.0.1/reference/be/general#config_setting)* [filegroup](/versions/8.0.1/reference/be/general#filegroup)* [genquery](/versions/8.0.1/reference/be/general#genquery)* [genrule](/versions/8.0.1/reference/be/general#genrule)* [starlark\_doc\_extract](/versions/8.0.1/reference/be/general#starlark_doc_extract)* [test\_suite](/versions/8.0.1/reference/be/general#test_suite) |
+| Platforms and Toolchains | * [constraint\_setting](/versions/8.0.1/reference/be/platforms-and-toolchains#constraint_setting)* [constraint\_value](/versions/8.0.1/reference/be/platforms-and-toolchains#constraint_value)* [platform](/versions/8.0.1/reference/be/platforms-and-toolchains#platform)* [toolchain](/versions/8.0.1/reference/be/platforms-and-toolchains#toolchain)* [toolchain\_type](/versions/8.0.1/reference/be/platforms-and-toolchains#toolchain_type) |
+| Workspace | * [bind](/versions/8.0.1/reference/be/workspace#bind)* [local\_repository](/versions/8.0.1/reference/be/workspace#local_repository)* [new\_local\_repository](/versions/8.0.1/reference/be/workspace#new_local_repository) |
\ No newline at end of file
diff --git a/versions/8.0.1/reference/be/platforms-and-toolchains.mdx b/versions/8.0.1/reference/be/platforms-and-toolchains.mdx
index 1fcbbbbc..1986d853 100644
--- a/versions/8.0.1/reference/be/platforms-and-toolchains.mdx
+++ b/versions/8.0.1/reference/be/platforms-and-toolchains.mdx
@@ -39,7 +39,7 @@ define a platform targeting an obscure cpu architecture.
 | Attributes | |
 | --- | --- |
 | `name` | [Name](/versions/8.0.1/concepts/labels#target-names); required  A unique name for this target. |
-| `default_constraint_value` | [Name](/versions/8.0.1/concepts/labels#target-names); [nonconfigurable](common-definitions#configurable-attributes); default is `None` The label of the default value for this setting, to be used if no value is given. If this attribute is present, the `constraint_value` it points to must be defined in the same package as this `constraint_setting`. If a constraint setting has a default value, then whenever a platform does not include any constraint value for that setting, it is the same as if the platform had specified the default value. Otherwise, if there is no default value, the constraint setting is considered to be unspecified by that platform. In that case, the platform would not match against any constraint list (such as for a `config_setting`) that requires a particular value for that setting. |
+| `default_constraint_value` | [Name](/versions/8.0.1/concepts/labels#target-names); [nonconfigurable](/versions/8.0.1/reference/be/common-definitions#configurable-attributes); default is `None` The label of the default value for this setting, to be used if no value is given. If this attribute is present, the `constraint_value` it points to must be defined in the same package as this `constraint_setting`. If a constraint setting has a default value, then whenever a platform does not include any constraint value for that setting, it is the same as if the platform had specified the default value. Otherwise, if there is no default value, the constraint setting is considered to be unspecified by that platform. In that case, the platform would not match against any constraint list (such as for a `config_setting`) that requires a particular value for that setting. |
 
 ## constraint\_value
 
@@ -73,7 +73,7 @@ Platforms can then declare that they have the `mips` architecture as an alternat
 | Attributes | |
 | --- | --- |
 | `name` | [Name](/versions/8.0.1/concepts/labels#target-names); required  A unique name for this target. |
-| `constraint_setting` | [Label](/versions/8.0.1/concepts/labels); [nonconfigurable](common-definitions#configurable-attributes); required The `constraint_setting` for which this `constraint_value` is a possible choice. |
+| `constraint_setting` | [Label](/versions/8.0.1/concepts/labels); [nonconfigurable](/versions/8.0.1/reference/be/common-definitions#configurable-attributes); required The `constraint_setting` for which this `constraint_value` is a possible choice. |
 
 ## platform
 
@@ -278,11 +278,11 @@ In this example, the child platforms have the following properties:
 | Attributes | |
 | --- | --- |
 | `name` | [Name](/versions/8.0.1/concepts/labels#target-names); required  A unique name for this target. |
-| `constraint_values` | List of [labels](/versions/8.0.1/concepts/labels); [nonconfigurable](common-definitions#configurable-attributes); default is `[]` The combination of constraint choices that this platform comprises. In order for a platform to apply to a given environment, the environment must have at least the values in this list. Each `constraint_value` in this list must be for a different `constraint_setting`. For example, you cannot define a platform that requires the cpu architecture to be both `@platforms//cpu:x86_64` and `@platforms//cpu:arm`. |
-| `exec_properties` | Dictionary: String -> String; [nonconfigurable](common-definitions#configurable-attributes); default is `{}` A map of strings that affect the way actions are executed remotely. Bazel makes no attempt to interpret this, it is treated as opaque data that's forwarded via the Platform field of the [remote execution protocol](https://github.com/bazelbuild/remote-apis). This includes any data from the parent platform's `exec_properties` attributes. If the child and parent platform define the same keys, the child's values are kept. Any keys associated with a value that is an empty string are removed from the dictionary. This attribute is a full replacement for the deprecated `remote_execution_properties`. |
-| `flags` | List of strings; [nonconfigurable](common-definitions#configurable-attributes); default is `[]` A list of flags that will be enabled when this platform is used as the target platform in a configuration. Only flags that can be set in transitions are allowed to be used. |
-| `parents` | List of [labels](/versions/8.0.1/concepts/labels); [nonconfigurable](common-definitions#configurable-attributes); default is `[]` The label of a `platform` target that this platform should inherit from. Although the attribute takes a list, there should be no more than one platform present. Any constraint\_settings not set directly on this platform will be found in the parent platform. See the section on [Platform Inheritance](#platform_inheritance) for details. |
-| `remote_execution_properties` | String; [nonconfigurable](common-definitions#configurable-attributes); default is `""` DEPRECATED. Please use exec\_properties attribute instead. A string used to configure a remote execution platform. Actual builds make no attempt to interpret this, it is treated as opaque data that can be used by a specific SpawnRunner. This can include data from the parent platform's "remote\_execution\_properties" attribute, by using the macro "\{PARENT\_REMOTE\_EXECUTION\_PROPERTIES\}". See the section on [Platform Inheritance](#platform_inheritance) for details. |
+| `constraint_values` | List of [labels](/versions/8.0.1/concepts/labels); [nonconfigurable](/versions/8.0.1/reference/be/common-definitions#configurable-attributes); default is `[]` The combination of constraint choices that this platform comprises. In order for a platform to apply to a given environment, the environment must have at least the values in this list. Each `constraint_value` in this list must be for a different `constraint_setting`. For example, you cannot define a platform that requires the cpu architecture to be both `@platforms//cpu:x86_64` and `@platforms//cpu:arm`. |
+| `exec_properties` | Dictionary: String -> String; [nonconfigurable](/versions/8.0.1/reference/be/common-definitions#configurable-attributes); default is `{}` A map of strings that affect the way actions are executed remotely. Bazel makes no attempt to interpret this, it is treated as opaque data that's forwarded via the Platform field of the [remote execution protocol](https://github.com/bazelbuild/remote-apis). This includes any data from the parent platform's `exec_properties` attributes. If the child and parent platform define the same keys, the child's values are kept. Any keys associated with a value that is an empty string are removed from the dictionary. This attribute is a full replacement for the deprecated `remote_execution_properties`. |
+| `flags` | List of strings; [nonconfigurable](/versions/8.0.1/reference/be/common-definitions#configurable-attributes); default is `[]` A list of flags that will be enabled when this platform is used as the target platform in a configuration. Only flags that can be set in transitions are allowed to be used. |
+| `parents` | List of [labels](/versions/8.0.1/concepts/labels); [nonconfigurable](/versions/8.0.1/reference/be/common-definitions#configurable-attributes); default is `[]` The label of a `platform` target that this platform should inherit from. Although the attribute takes a list, there should be no more than one platform present. Any constraint\_settings not set directly on this platform will be found in the parent platform. See the section on [Platform Inheritance](#platform_inheritance) for details. |
+| `remote_execution_properties` | String; [nonconfigurable](/versions/8.0.1/reference/be/common-definitions#configurable-attributes); default is `""` DEPRECATED. Please use exec\_properties attribute instead. A string used to configure a remote execution platform. Actual builds make no attempt to interpret this, it is treated as opaque data that can be used by a specific SpawnRunner. This can include data from the parent platform's "remote\_execution\_properties" attribute, by using the macro "\{PARENT\_REMOTE\_EXECUTION\_PROPERTIES\}". See the section on [Platform Inheritance](#platform_inheritance) for details. |
 | `required_settings` | List of [labels](/versions/8.0.1/concepts/labels); default is `[]` A list of `config_setting`s that must be satisfied by the target configuration in order for this platform to be used as an execution platform during toolchain resolution. Required settings are not inherited from parent platforms. |
 
 ## toolchain
@@ -303,11 +303,11 @@ details.
 | Attributes | |
 | --- | --- |
 | `name` | [Name](/versions/8.0.1/concepts/labels#target-names); required  A unique name for this target. |
-| `exec_compatible_with` | List of [labels](/versions/8.0.1/concepts/labels); [nonconfigurable](common-definitions#configurable-attributes); default is `[]` A list of `constraint_value`s that must be satisfied by an execution platform in order for this toolchain to be selected for a target building on that platform. |
-| `target_compatible_with` | List of [labels](/versions/8.0.1/concepts/labels); [nonconfigurable](common-definitions#configurable-attributes); default is `[]` A list of `constraint_value`s that must be satisfied by the target platform in order for this toolchain to be selected for a target building for that platform. |
+| `exec_compatible_with` | List of [labels](/versions/8.0.1/concepts/labels); [nonconfigurable](/versions/8.0.1/reference/be/common-definitions#configurable-attributes); default is `[]` A list of `constraint_value`s that must be satisfied by an execution platform in order for this toolchain to be selected for a target building on that platform. |
+| `target_compatible_with` | List of [labels](/versions/8.0.1/concepts/labels); [nonconfigurable](/versions/8.0.1/reference/be/common-definitions#configurable-attributes); default is `[]` A list of `constraint_value`s that must be satisfied by the target platform in order for this toolchain to be selected for a target building for that platform. |
 | `target_settings` | List of [labels](/versions/8.0.1/concepts/labels); default is `[]` A list of `config_setting`s that must be satisfied by the target configuration in order for this toolchain to be selected during toolchain resolution. |
 | `toolchain` | [Name](/versions/8.0.1/concepts/labels#target-names); required The target representing the actual tool or tool suite that is made available when this toolchain is selected. |
-| `toolchain_type` | [Label](/versions/8.0.1/concepts/labels); [nonconfigurable](common-definitions#configurable-attributes); required The label of a `toolchain_type` target that represents the role that this toolchain serves. |
+| `toolchain_type` | [Label](/versions/8.0.1/concepts/labels); [nonconfigurable](/versions/8.0.1/reference/be/common-definitions#configurable-attributes); required The label of a `toolchain_type` target that represents the role that this toolchain serves. |
 
 ## toolchain\_type
 
diff --git a/versions/8.0.1/reference/be/protocol-buffer.mdx b/versions/8.0.1/reference/be/protocol-buffer.mdx
index e4ae218a..a405dfc0 100644
--- a/versions/8.0.1/reference/be/protocol-buffer.mdx
+++ b/versions/8.0.1/reference/be/protocol-buffer.mdx
@@ -22,7 +22,7 @@ cc_proto_library(name, deps, compatible_with, deprecation, distribs, exec_compat
 
 `cc_proto_library` generates C++ code from `.proto` files.
 
-`deps` must point to [`proto_library`](protocol-buffer#proto_library) rules.
+`deps` must point to [`proto_library`](/versions/8.0.1/reference/be/protocol-buffer#proto_library) rules.
 
 Example:
 
@@ -47,7 +47,7 @@ proto_library(
 | Attributes | |
 | --- | --- |
 | `name` | [Name](/versions/8.0.1/concepts/labels#target-names); required  A unique name for this target. |
-| `deps` | List of [labels](/versions/8.0.1/concepts/labels); default is `[]` The list of [`proto_library`](protocol-buffer#proto_library) rules to generate C++ code for. |
+| `deps` | List of [labels](/versions/8.0.1/concepts/labels); default is `[]` The list of [`proto_library`](/versions/8.0.1/reference/be/protocol-buffer#proto_library) rules to generate C++ code for. |
 
 ## java\_lite\_proto\_library
 
@@ -59,7 +59,7 @@ java_lite_proto_library(name, deps, compatible_with, deprecation, distribs, exec
 
 `java_lite_proto_library` generates Java code from `.proto` files.
 
-`deps` must point to [`proto_library`](protocol-buffer#proto_library) rules.
+`deps` must point to [`proto_library`](/versions/8.0.1/reference/be/protocol-buffer#proto_library) rules.
 
 Example:
 
@@ -84,7 +84,7 @@ proto_library(
 | Attributes | |
 | --- | --- |
 | `name` | [Name](/versions/8.0.1/concepts/labels#target-names); required  A unique name for this target. |
-| `deps` | List of [labels](/versions/8.0.1/concepts/labels); default is `[]` The list of [`proto_library`](protocol-buffer#proto_library) rules to generate Java code for. |
+| `deps` | List of [labels](/versions/8.0.1/concepts/labels); default is `[]` The list of [`proto_library`](/versions/8.0.1/reference/be/protocol-buffer#proto_library) rules to generate Java code for. |
 
 ## java\_proto\_library
 
@@ -96,7 +96,7 @@ java_proto_library(name, deps, compatible_with, deprecation, distribs, exec_comp
 
 `java_proto_library` generates Java code from `.proto` files.
 
-`deps` must point to [`proto_library`](protocol-buffer#proto_library) rules.
+`deps` must point to [`proto_library`](/versions/8.0.1/reference/be/protocol-buffer#proto_library) rules.
 
 Example:
 
@@ -121,7 +121,7 @@ proto_library(
 | Attributes | |
 | --- | --- |
 | `name` | [Name](/versions/8.0.1/concepts/labels#target-names); required  A unique name for this target. |
-| `deps` | List of [labels](/versions/8.0.1/concepts/labels); default is `[]` The list of [`proto_library`](protocol-buffer#proto_library) rules to generate Java code for. |
+| `deps` | List of [labels](/versions/8.0.1/concepts/labels); default is `[]` The list of [`proto_library`](/versions/8.0.1/reference/be/protocol-buffer#proto_library) rules to generate Java code for. |
 
 ## proto\_library
 
diff --git a/versions/8.0.1/reference/be/python.mdx b/versions/8.0.1/reference/be/python.mdx
index 5f4a0d13..5073e557 100644
--- a/versions/8.0.1/reference/be/python.mdx
+++ b/versions/8.0.1/reference/be/python.mdx
@@ -22,13 +22,13 @@ py_binary(name, deps, srcs, data, args, compatible_with, deprecation, distribs,
 | Attributes | |
 | --- | --- |
 | `name` | [Name](/versions/8.0.1/concepts/labels#target-names); required  A unique name for this target. |
-| `deps` | List of [labels](/versions/8.0.1/concepts/labels); default is `[]` List of additional libraries to be linked in to the target. See comments about the [`deps` attribute typically defined by rules](https://bazel.build/reference/be/common-definitions#typical-attributes). These are typically `py\_library` rules. Targets that only provide data files used at runtime belong in the `data` attribute. |
+| `deps` | List of [labels](/versions/8.0.1/concepts/labels); default is `[]` List of additional libraries to be linked in to the target. See comments about the [`deps` attribute typically defined by rules](https://bazel.build/versions/8.0.1/reference/be/common-definitions#typical-attributes). These are typically `py\_library` rules. Targets that only provide data files used at runtime belong in the `data` attribute. |
 | `srcs` | List of [labels](/versions/8.0.1/concepts/labels); required The list of Python source files that are processed to create the target. This includes all your checked-in code and may include generated source files. The `.py` files belong in `srcs` and library targets belong in `deps`. Other binary files that may be needed at run time belong in `data`. |
-| `data` | List of [labels](/versions/8.0.1/concepts/labels); default is `[]` The list of files need by this library at runtime. See comments about the [`data` attribute typically defined by rules](https://bazel.build/reference/be/common-definitions#typical-attributes). There is no `py\_embed\_data` like there is `cc\_embed\_data` and `go\_embed\_data`. This is because Python has a concept of runtime resources. |
+| `data` | List of [labels](/versions/8.0.1/concepts/labels); default is `[]` The list of files need by this library at runtime. See comments about the [`data` attribute typically defined by rules](https://bazel.build/versions/8.0.1/reference/be/common-definitions#typical-attributes). There is no `py\_embed\_data` like there is `cc\_embed\_data` and `go\_embed\_data`. This is because Python has a concept of runtime resources. |
 | `imports` | List of strings; default is `[]` List of import directories to be added to the PYTHONPATH. Subject to "Make variable" substitution. These import directories will be added for this rule and all rules that depend on it (note: not the rules this rule depends on. Each directory will be added to `PYTHONPATH` by `py\_binary` rules that depend on this rule. The strings are repo-runfiles-root relative, Absolute paths (paths that start with `/`) and paths that references a path above the execution root are not allowed and will result in an error. |
 | `legacy_create_init` | Integer; default is `-1` Whether to implicitly create empty `\_\_init\_\_.py` files in the runfiles tree. These are created in every directory containing Python source code or shared libraries, and every parent directory of those directories, excluding the repo root directory. The default, `-1` (auto), means true unless `--incompatible\_default\_to\_explicit\_init\_py` is used. If false, the user is responsible for creating (possibly empty) `\_\_init\_\_.py` files and adding them to the `srcs` of Python targets as required. |
 | `main` | [Label](/versions/8.0.1/concepts/labels); default is `None` Optional; the name of the source file that is the main entry point of the application. This file must also be listed in `srcs`. If left unspecified, `name`, with `.py` appended, is used instead. If `name` does not match any filename in `srcs`, `main` must be specified. |
-| `precompile` | String; default is `"inherit"` Whether py source files \*\*for this target\*\* should be precompiled. Values: \* `inherit`: Allow the downstream binary decide if precompiled files are used. \* `enabled`: Compile Python source files at build time. \* `disabled`: Don't compile Python source files at build time. :::{seealso} \* The {flag}`--precompile` flag, which can override this attribute in some cases and will affect all targets when building. \* The {obj}`pyc\_collection` attribute for transitively enabling precompiling on a per-target basis. \* The [Precompiling](precompiling) docs for a guide about using precompiling. ::: |
+| `precompile` | String; default is `"inherit"` Whether py source files \*\*for this target\*\* should be precompiled. Values: \* `inherit`: Allow the downstream binary decide if precompiled files are used. \* `enabled`: Compile Python source files at build time. \* `disabled`: Don't compile Python source files at build time. :::{seealso} \* The {flag}`--precompile` flag, which can override this attribute in some cases and will affect all targets when building. \* The {obj}`pyc\_collection` attribute for transitively enabling precompiling on a per-target basis. \* The [Precompiling](/versions/8.0.1/reference/be/precompiling) docs for a guide about using precompiling. ::: |
 | `precompile_invalidation_mode` | String; default is `"auto"` How precompiled files should be verified to be up-to-date with their associated source files. Possible values are: \* `auto`: The effective value will be automatically determined by other build settings. \* `checked\_hash`: Use the pyc file if the hash of the source file matches the hash recorded in the pyc file. This is most useful when working with code that you may modify. \* `unchecked\_hash`: Always use the pyc file; don't check the pyc's hash against the source file. This is most useful when the code won't be modified. For more information on pyc invalidation modes, see https://docs.python.org/3/library/py\_compile.html#py\_compile.PycInvalidationMode |
 | `precompile_optimize_level` | Integer; default is `0` The optimization level for precompiled files. For more information about optimization levels, see the `compile()` function's `optimize` arg docs at https://docs.python.org/3/library/functions.html#compile NOTE: The value `-1` means "current interpreter", which will be the interpreter used \_at build time when pycs are generated\_, not the interpreter used at runtime when the code actually runs. |
 | `precompile_source_retention` | String; default is `"inherit"` Determines, when a source file is compiled, if the source file is kept in the resulting output or not. Valid values are: \* `inherit`: Inherit the value from the {flag}`--precompile\_source\_retention` flag. \* `keep\_source`: Include the original Python source. \* `omit\_source`: Don't include the original py source. |
@@ -61,11 +61,11 @@ Source files are no longer added to the runfiles directly.
 | Attributes | |
 | --- | --- |
 | `name` | [Name](/versions/8.0.1/concepts/labels#target-names); required  A unique name for this target. |
-| `deps` | List of [labels](/versions/8.0.1/concepts/labels); default is `[]` List of additional libraries to be linked in to the target. See comments about the [`deps` attribute typically defined by rules](https://bazel.build/reference/be/common-definitions#typical-attributes). These are typically `py\_library` rules. Targets that only provide data files used at runtime belong in the `data` attribute. |
+| `deps` | List of [labels](/versions/8.0.1/concepts/labels); default is `[]` List of additional libraries to be linked in to the target. See comments about the [`deps` attribute typically defined by rules](https://bazel.build/versions/8.0.1/reference/be/common-definitions#typical-attributes). These are typically `py\_library` rules. Targets that only provide data files used at runtime belong in the `data` attribute. |
 | `srcs` | List of [labels](/versions/8.0.1/concepts/labels); default is `[]` The list of Python source files that are processed to create the target. This includes all your checked-in code and may include generated source files. The `.py` files belong in `srcs` and library targets belong in `deps`. Other binary files that may be needed at run time belong in `data`. |
-| `data` | List of [labels](/versions/8.0.1/concepts/labels); default is `[]` The list of files need by this library at runtime. See comments about the [`data` attribute typically defined by rules](https://bazel.build/reference/be/common-definitions#typical-attributes). There is no `py\_embed\_data` like there is `cc\_embed\_data` and `go\_embed\_data`. This is because Python has a concept of runtime resources. |
+| `data` | List of [labels](/versions/8.0.1/concepts/labels); default is `[]` The list of files need by this library at runtime. See comments about the [`data` attribute typically defined by rules](https://bazel.build/versions/8.0.1/reference/be/common-definitions#typical-attributes). There is no `py\_embed\_data` like there is `cc\_embed\_data` and `go\_embed\_data`. This is because Python has a concept of runtime resources. |
 | `imports` | List of strings; default is `[]` List of import directories to be added to the PYTHONPATH. Subject to "Make variable" substitution. These import directories will be added for this rule and all rules that depend on it (note: not the rules this rule depends on. Each directory will be added to `PYTHONPATH` by `py\_binary` rules that depend on this rule. The strings are repo-runfiles-root relative, Absolute paths (paths that start with `/`) and paths that references a path above the execution root are not allowed and will result in an error. |
-| `precompile` | String; default is `"inherit"` Whether py source files \*\*for this target\*\* should be precompiled. Values: \* `inherit`: Allow the downstream binary decide if precompiled files are used. \* `enabled`: Compile Python source files at build time. \* `disabled`: Don't compile Python source files at build time. :::{seealso} \* The {flag}`--precompile` flag, which can override this attribute in some cases and will affect all targets when building. \* The {obj}`pyc\_collection` attribute for transitively enabling precompiling on a per-target basis. \* The [Precompiling](precompiling) docs for a guide about using precompiling. ::: |
+| `precompile` | String; default is `"inherit"` Whether py source files \*\*for this target\*\* should be precompiled. Values: \* `inherit`: Allow the downstream binary decide if precompiled files are used. \* `enabled`: Compile Python source files at build time. \* `disabled`: Don't compile Python source files at build time. :::{seealso} \* The {flag}`--precompile` flag, which can override this attribute in some cases and will affect all targets when building. \* The {obj}`pyc\_collection` attribute for transitively enabling precompiling on a per-target basis. \* The [Precompiling](/versions/8.0.1/reference/be/precompiling) docs for a guide about using precompiling. ::: |
 | `precompile_invalidation_mode` | String; default is `"auto"` How precompiled files should be verified to be up-to-date with their associated source files. Possible values are: \* `auto`: The effective value will be automatically determined by other build settings. \* `checked\_hash`: Use the pyc file if the hash of the source file matches the hash recorded in the pyc file. This is most useful when working with code that you may modify. \* `unchecked\_hash`: Always use the pyc file; don't check the pyc's hash against the source file. This is most useful when the code won't be modified. For more information on pyc invalidation modes, see https://docs.python.org/3/library/py\_compile.html#py\_compile.PycInvalidationMode |
 | `precompile_optimize_level` | Integer; default is `0` The optimization level for precompiled files. For more information about optimization levels, see the `compile()` function's `optimize` arg docs at https://docs.python.org/3/library/functions.html#compile NOTE: The value `-1` means "current interpreter", which will be the interpreter used \_at build time when pycs are generated\_, not the interpreter used at runtime when the code actually runs. |
 | `precompile_source_retention` | String; default is `"inherit"` Determines, when a source file is compiled, if the source file is kept in the resulting output or not. Valid values are: \* `inherit`: Inherit the value from the {flag}`--precompile\_source\_retention` flag. \* `keep\_source`: Include the original Python source. \* `omit\_source`: Don't include the original py source. |
@@ -84,13 +84,13 @@ py_test(name, deps, srcs, data, args, compatible_with, deprecation, distribs, en
 | Attributes | |
 | --- | --- |
 | `name` | [Name](/versions/8.0.1/concepts/labels#target-names); required  A unique name for this target. |
-| `deps` | List of [labels](/versions/8.0.1/concepts/labels); default is `[]` List of additional libraries to be linked in to the target. See comments about the [`deps` attribute typically defined by rules](https://bazel.build/reference/be/common-definitions#typical-attributes). These are typically `py\_library` rules. Targets that only provide data files used at runtime belong in the `data` attribute. |
+| `deps` | List of [labels](/versions/8.0.1/concepts/labels); default is `[]` List of additional libraries to be linked in to the target. See comments about the [`deps` attribute typically defined by rules](https://bazel.build/versions/8.0.1/reference/be/common-definitions#typical-attributes). These are typically `py\_library` rules. Targets that only provide data files used at runtime belong in the `data` attribute. |
 | `srcs` | List of [labels](/versions/8.0.1/concepts/labels); required The list of Python source files that are processed to create the target. This includes all your checked-in code and may include generated source files. The `.py` files belong in `srcs` and library targets belong in `deps`. Other binary files that may be needed at run time belong in `data`. |
-| `data` | List of [labels](/versions/8.0.1/concepts/labels); default is `[]` The list of files need by this library at runtime. See comments about the [`data` attribute typically defined by rules](https://bazel.build/reference/be/common-definitions#typical-attributes). There is no `py\_embed\_data` like there is `cc\_embed\_data` and `go\_embed\_data`. This is because Python has a concept of runtime resources. |
+| `data` | List of [labels](/versions/8.0.1/concepts/labels); default is `[]` The list of files need by this library at runtime. See comments about the [`data` attribute typically defined by rules](https://bazel.build/versions/8.0.1/reference/be/common-definitions#typical-attributes). There is no `py\_embed\_data` like there is `cc\_embed\_data` and `go\_embed\_data`. This is because Python has a concept of runtime resources. |
 | `imports` | List of strings; default is `[]` List of import directories to be added to the PYTHONPATH. Subject to "Make variable" substitution. These import directories will be added for this rule and all rules that depend on it (note: not the rules this rule depends on. Each directory will be added to `PYTHONPATH` by `py\_binary` rules that depend on this rule. The strings are repo-runfiles-root relative, Absolute paths (paths that start with `/`) and paths that references a path above the execution root are not allowed and will result in an error. |
 | `legacy_create_init` | Integer; default is `-1` Whether to implicitly create empty `\_\_init\_\_.py` files in the runfiles tree. These are created in every directory containing Python source code or shared libraries, and every parent directory of those directories, excluding the repo root directory. The default, `-1` (auto), means true unless `--incompatible\_default\_to\_explicit\_init\_py` is used. If false, the user is responsible for creating (possibly empty) `\_\_init\_\_.py` files and adding them to the `srcs` of Python targets as required. |
 | `main` | [Label](/versions/8.0.1/concepts/labels); default is `None` Optional; the name of the source file that is the main entry point of the application. This file must also be listed in `srcs`. If left unspecified, `name`, with `.py` appended, is used instead. If `name` does not match any filename in `srcs`, `main` must be specified. |
-| `precompile` | String; default is `"inherit"` Whether py source files \*\*for this target\*\* should be precompiled. Values: \* `inherit`: Allow the downstream binary decide if precompiled files are used. \* `enabled`: Compile Python source files at build time. \* `disabled`: Don't compile Python source files at build time. :::{seealso} \* The {flag}`--precompile` flag, which can override this attribute in some cases and will affect all targets when building. \* The {obj}`pyc\_collection` attribute for transitively enabling precompiling on a per-target basis. \* The [Precompiling](precompiling) docs for a guide about using precompiling. ::: |
+| `precompile` | String; default is `"inherit"` Whether py source files \*\*for this target\*\* should be precompiled. Values: \* `inherit`: Allow the downstream binary decide if precompiled files are used. \* `enabled`: Compile Python source files at build time. \* `disabled`: Don't compile Python source files at build time. :::{seealso} \* The {flag}`--precompile` flag, which can override this attribute in some cases and will affect all targets when building. \* The {obj}`pyc\_collection` attribute for transitively enabling precompiling on a per-target basis. \* The [Precompiling](/versions/8.0.1/reference/be/precompiling) docs for a guide about using precompiling. ::: |
 | `precompile_invalidation_mode` | String; default is `"auto"` How precompiled files should be verified to be up-to-date with their associated source files. Possible values are: \* `auto`: The effective value will be automatically determined by other build settings. \* `checked\_hash`: Use the pyc file if the hash of the source file matches the hash recorded in the pyc file. This is most useful when working with code that you may modify. \* `unchecked\_hash`: Always use the pyc file; don't check the pyc's hash against the source file. This is most useful when the code won't be modified. For more information on pyc invalidation modes, see https://docs.python.org/3/library/py\_compile.html#py\_compile.PycInvalidationMode |
 | `precompile_optimize_level` | Integer; default is `0` The optimization level for precompiled files. For more information about optimization levels, see the `compile()` function's `optimize` arg docs at https://docs.python.org/3/library/functions.html#compile NOTE: The value `-1` means "current interpreter", which will be the interpreter used \_at build time when pycs are generated\_, not the interpreter used at runtime when the code actually runs. |
 | `precompile_source_retention` | String; default is `"inherit"` Determines, when a source file is compiled, if the source file is kept in the resulting output or not. Valid values are: \* `inherit`: Inherit the value from the {flag}`--precompile\_source\_retention` flag. \* `keep\_source`: Include the original Python source. \* `omit\_source`: Don't include the original py source. |
diff --git a/versions/8.0.1/reference/be/workspace.mdx b/versions/8.0.1/reference/be/workspace.mdx
index 36f47e32..8b2a736b 100644
--- a/versions/8.0.1/reference/be/workspace.mdx
+++ b/versions/8.0.1/reference/be/workspace.mdx
@@ -25,8 +25,7 @@ bind(name, actual, compatible_with, deprecation, distribs, features, licenses, r
 
 *Warning: use of `bind()` is not recommended. See "[Consider removing bind](https://github.com/bazelbuild/bazel/issues/1952)" for a long
 discussion of its issues and alternatives. In particular, consider the use of
-[`repo_mapping`
-repository attributes](https://bazel.build/versions/8.0.1/rules/repository_rules#attributes).*
+[`repo_mapping` repository attributes](https://bazel.build/versions/8.0.1/rules/repository_rules#attributes).*
 
 *Warning: `select()` cannot be used in `bind()`. See the [Configurable Attributes FAQ](/versions/8.0.1/docs/configurable-attributes#bind-select) for
 details.*
@@ -114,8 +113,7 @@ local_repository(name, path, repo_mapping)
 ```
 
 Allows targets from a local directory to be bound. This means that the current repository can
-use targets defined in this other directory. See the [bind
-section](/versions/8.0.1/reference/be/workspace#bind_examples) for more details.
+use targets defined in this other directory. See the [bind section](/versions/8.0.1/reference/be/workspace#bind_examples) for more details.
 
 #### Examples
 
diff --git a/versions/8.0.1/reference/command-line-reference.mdx b/versions/8.0.1/reference/command-line-reference.mdx
index b6697d7f..7f4c3e28 100644
--- a/versions/8.0.1/reference/command-line-reference.mdx
+++ b/versions/8.0.1/reference/command-line-reference.mdx
@@ -486,7 +486,7 @@ This option affects semantics of the Starlark language or the build API accessib
     [`loading_and_analysis`](#effect_tag_LOADING_AND_ANALYSIS), [`experimental`](#metadata_tag_EXPERIMENTAL)
 
 `--[no]experimental_isolated_extension_usages` default: "false"
-:   If true, enables the isolate parameter in the use\_extension function.
+:   If true, enables the isolate parameter in the use\_extension function.
 
     Tags:
     [`loading_and_analysis`](#effect_tag_LOADING_AND_ANALYSIS)
diff --git a/versions/8.0.1/reference/glossary.mdx b/versions/8.0.1/reference/glossary.mdx
index 12d5dc1d..51e4a0ad 100644
--- a/versions/8.0.1/reference/glossary.mdx
+++ b/versions/8.0.1/reference/glossary.mdx
@@ -21,8 +21,7 @@ An in-memory graph of [actions](#action) and the [artifacts](#artifact) that
 these actions read and generate. The graph might include artifacts that exist as
 source files (for example, in the file system) as well as generated
 intermediate/final artifacts that are not mentioned in `BUILD` files. Produced
-during the [analysis phase](#analysis-phase) and used during the [execution
-phase](#execution-phase).
+during the [analysis phase](#analysis-phase) and used during the [execution phase](#execution-phase).
 
 ### Action graph query (aquery) {#action-graph-query}
 A [query](#query-concept) tool that can query over build [actions](#action).
@@ -37,8 +36,7 @@ invalidate individual actions deterministically.
 
 ### Analysis phase {#analysis-phase}
 The second phase of a build. Processes the [target graph](#target-graph)
-specified in [`BUILD` files](#build-file) to produce an in-memory [action
-graph](#action-graph) that determines the order of actions to run during the
+specified in [`BUILD` files](#build-file) to produce an in-memory [action graph](#action-graph) that determines the order of actions to run during the
 [execution phase](#execution-phase). This is the phase in which rule
 implementations are evaluated.
 
@@ -81,8 +79,7 @@ target's source files, dependencies, and custom compiler options. The particular
 attributes available for a given target depend on its rule type.
 
 ### .bazelrc {#bazelrc}
-Bazel’s configuration file used to change the default values for [startup
-flags](#startup-flags) and [command flags](#command-flags), and to define common
+Bazel’s configuration file used to change the default values for [startup flags](#startup-flags) and [command flags](#command-flags), and to define common
 groups of options that can then be set together on the Bazel command line using
 a `--config` flag. Bazel can combine settings from multiple bazelrc files
 (systemwide, per-workspace, per-user, or from a custom location), and a
@@ -108,8 +105,7 @@ directory.
 
 ### .bzl File {#bzl-file}
 A file that defines rules, [macros](#macro), and constants written in
-[Starlark](#starlark). These can then be imported into [`BUILD`
-files](#build-file) using the `load()` function.
+[Starlark](#starlark). These can then be imported into [`BUILD` files](#build-file) using the `load()` function.
 
 {/* TODO: ### Build event protocol */}
 
@@ -117,8 +113,7 @@ files](#build-file) using the `load()` function.
 
 ### Build graph {#build-graph}
 The dependency graph that Bazel constructs and traverses to perform a build.
-Includes nodes like [targets](#target), [configured
-targets](#configured-target), [actions](#action), and [artifacts](#artifact). A
+Includes nodes like [targets](#target), [configured targets](#configured-target), [actions](#action), and [artifacts](#artifact). A
 build is considered complete when all [artifacts](#artifact) on which a set of
 requested targets depend are verified as up-to-date.
 
@@ -158,8 +153,7 @@ graphs and restart the [analysis phase](#analysis-phase).
 ### Configuration {#configuration}
 Information outside of [rule](#rule) definitions that impacts how rules generate
 [actions](#action). Every build has at least one configuration specifying the
-target platform, action environment variables, and command-line [build
-flags](#command-flags). [Transitions](#transition) may create additional
+target platform, action environment variables, and command-line [build flags](#command-flags). [Transitions](#transition) may create additional
 configurations, such as for host tools or cross-compilation.
 
 **See also:** [Configurations](/versions/8.0.1/extending/rules#configurations)
@@ -174,8 +168,7 @@ configuration of `//:c` because changing `--javacopt` unnecessarily breaks C++
 build cacheability.
 
 ### Configured query (cquery) {#configured-query}
-A [query](#query-concept) tool that queries over [configured
-targets](#configured-target) (after the [analysis phase](#analysis-phase)
+A [query](#query-concept) tool that queries over [configured targets](#configured-target) (after the [analysis phase](#analysis-phase)
 completes). This means `select()` and [build flags](#command-flags) (such as
 `--platforms`) are accurately reflected in the results.
 
@@ -191,8 +184,7 @@ build, it has two configured targets: `` and ``.
 ### Correctness {#correctness}
 A build is correct when its output faithfully reflects the state of its
 transitive inputs. To achieve correct builds, Bazel strives to be
-[hermetic](#hermeticity), reproducible, and making [build
-analysis](#analysis-phase) and [action execution](#execution-phase)
+[hermetic](#hermeticity), reproducible, and making [build analysis](#analysis-phase) and [action execution](#execution-phase)
 deterministic.
 
 ### Dependency {#dependency}
@@ -234,8 +226,7 @@ compilation). A dynamic execution strategy can provide the best possible
 incremental and clean build times.
 
 ### Execution phase {#execution-phase}
-The third phase of a build. Executes the [actions](#action) in the [action
-graph](#action-graph) created during the [analysis phase](#analysis-phase).
+The third phase of a build. Executes the [actions](#action) in the [action graph](#action-graph) created during the [analysis phase](#analysis-phase).
 These actions invoke executables (compilers, scripts) to read and write
 [artifacts](#artifact). *Spawn strategies* control how these actions are
 executed: locally, remotely, dynamically, sandboxed, docker, and so on.
@@ -285,8 +276,7 @@ syntax may be omitted.
 The first phase of a build where Bazel executes [`BUILD` files](#build-file) to
 create [packages](#package). [Macros](#macro) and certain functions like
 `glob()` are evaluated in this phase. Interleaved with the second phase of the
-build, the [analysis phase](#analysis-phase), to build up a [target
-graph](#target-graph).
+build, the [analysis phase](#analysis-phase), to build up a [target graph](#target-graph).
 
 ### Legacy macro {#legacy-macro}
 A flavor of [macro](#macro) which is declared as an ordinary
@@ -336,8 +326,7 @@ Module metadata is hosted in Bazel registries.
 
 ### Module Extension {#module-extension}
 A piece of logic that can be run to generate [repos](#repository) by reading
-inputs from across the [module](#module) dependency graph and invoking [repo
-rules](#repository-rule). Module extensions have capabilities similar to repo
+inputs from across the [module](#module) dependency graph and invoking [repo rules](#repository-rule). Module extensions have capabilities similar to repo
 rules, allowing them to access the internet, perform file I/O, and so on.
 
 **See also:** [Module extensions](/versions/8.0.1/external/extension)
@@ -350,8 +339,7 @@ example, `native.cc_library` or `native.java_library`). User-defined rules
 
 ### Output base {#output-base}
 A [workspace](#workspace)-specific directory to store Bazel output files. Used
-to separate outputs from the *workspace*'s source tree (the [main
-repo](#repository)). Located in the [output user root](#output-user-root).
+to separate outputs from the *workspace*'s source tree (the [main repo](#repository)). Located in the [output user root](#output-user-root).
 
 ### Output groups {#output-groups}
 A group of files that is expected to be built when Bazel finishes building a
@@ -406,8 +394,7 @@ query variants: [query](#query-command), [cquery](#configured-query), and
 [aquery](#action-graph-query).
 
 ### query (command) {#query-command}
-A [query](#query-concept) tool that operates over the build's post-[loading
-phase](#loading-phase) [target graph](#target-graph). This is relatively fast,
+A [query](#query-concept) tool that operates over the build's post-[loading phase](#loading-phase) [target graph](#target-graph). This is relatively fast,
 but can't analyze the effects of `select()`, [build flags](#command-flags),
 [artifacts](#artifact), or build [actions](#action).
 
@@ -425,8 +412,7 @@ repo; multiple such files can coexist in a directory.
 The *main repo* is the repo in which the current Bazel command is being run.
 
 *External repos* are defined by specifying [modules](#module) in `MODULE.bazel`
-files, or invoking [repo rules](#repository-rule) in [module
-extensions](#module-extension). They can be fetched on demand to a predetermined
+files, or invoking [repo rules](#repository-rule) in [module extensions](#module-extension). They can be fetched on demand to a predetermined
 "magical" location on disk.
 
 Each repo has a unique, constant *canonical* name, and potentially different
@@ -437,8 +423,7 @@ Each repo has a unique, constant *canonical* name, and potentially different
 ### Repository cache {#repo-cache}
 A shared content-addressable cache of files downloaded by Bazel for builds,
 shareable across [workspaces](#workspace). Enables offline builds after the
-initial download. Commonly used to cache files downloaded through [repository
-rules](#repository-rule) like `http_archive` and repository rule APIs like
+initial download. Commonly used to cache files downloaded through [repository rules](#repository-rule) like `http_archive` and repository rule APIs like
 `repository_ctx.download`. Files are cached only if their SHA-256 checksums are
 specified for the download.
 
@@ -472,8 +457,7 @@ Rules are instantiated to produce rule targets in the
 [loading phase](#loading-phase). In the [analysis phase](#analysis-phase) rule
 targets communicate information to their downstream dependencies in the form of
 [providers](#provider), and register [actions](#action) describing how to
-generate their output artifacts. These actions are run in the [execution
-phase](#execution-phase).
+generate their output artifacts. These actions are run in the [execution phase](#execution-phase).
 
 Note: Historically the term "rule" has been used to refer to a rule target.
 This usage was inherited from tools like Make, but causes confusion and should
@@ -517,8 +501,7 @@ support the stamp attribute.
 ### Starlark {#starlark}
 The extension language for writing [rules](/versions/8.0.1/extending/rules) and [macros](#macro). A
 restricted subset of Python (syntactically and grammatically) aimed for the
-purpose of configuration, and for better performance. Uses the [`.bzl`
-file](#bzl-file) extension. [`BUILD` files](#build-file) use an even more
+purpose of configuration, and for better performance. Uses the [`.bzl` file](#bzl-file) extension. [`BUILD` files](#build-file) use an even more
 restricted version of Starlark (such as no `def` function definitions), formerly
 known as Skylark.
 
@@ -549,8 +532,7 @@ An object that is defined in a [`BUILD` file](#build-file) and identified by a
 [label](#label). Targets represent the buildable units of a workspace from
 the perspective of the end user.
 
-A target that is declared by instantiating a [rule](#rule) is called a [rule
-target](#rule-target). Depending on the rule, these may be runnable (like
+A target that is declared by instantiating a [rule](#rule) is called a [rule target](#rule-target). Depending on the rule, these may be runnable (like
 `cc_binary`) or testable (like `cc_test`). Rule targets typically depend on
 other targets via their [attributes](#attribute) (such as `deps`); these
 dependencies form the basis of the [target graph](#target-graph).
@@ -561,14 +543,11 @@ within a `BUILD` file. As a special case, the `BUILD` file of any package is
 always considered a source file target in that package.
 
 Targets are discovered during the [loading phase](#loading-phase). During the
-[analysis phase](#analysis-phase), targets are associated with [build
-configurations](#configuration) to form [configured
-targets](#configured-target).
+[analysis phase](#analysis-phase), targets are associated with [build configurations](#configuration) to form [configured targets](#configured-target).
 
 ### Target graph {#target-graph}
 An in-memory graph of [targets](#target) and their dependencies. Produced during
-the [loading phase](#loading-phase) and used as an input to the [analysis
-phase](#analysis-phase).
+the [loading phase](#loading-phase) and used as an input to the [analysis phase](#analysis-phase).
 
 ### Target pattern {#target-pattern}
 A way to specify a group of [targets](#target) on the command line. Commonly
@@ -581,8 +560,7 @@ packages recursively from the root of the [workspace](#workspace).
 Rule [targets](#target) instantiated from test rules, and therefore contains a
 test executable. A return code of zero from the completion of the executable
 indicates test success. The exact contract between Bazel and tests (such as test
-environment variables, test result collection methods) is specified in the [Test
-Encyclopedia](/versions/8.0.1/reference/test-encyclopedia).
+environment variables, test result collection methods) is specified in the [Test Encyclopedia](/versions/8.0.1/reference/test-encyclopedia).
 
 ### Toolchain {#toolchain}
 A set of tools to build outputs for a language. Typically, a toolchain includes
@@ -596,8 +574,7 @@ A build [target](#target) is top-level if it’s requested on the Bazel command
 line. For example, if `//:foo` depends on `//:bar`, and `bazel build //:foo` is
 called, then for this build, `//:foo` is top-level, and `//:bar` isn’t
 top-level, although both targets will need to be built. An important difference
-between top-level and non-top-level targets is that [command
-flags](#command-flags) set on the Bazel command line (or via
+between top-level and non-top-level targets is that [command flags](#command-flags) set on the Bazel command line (or via
 [.bazelrc](#bazelrc)) will set the [configuration](#configuration) for top-level
 targets, but might be modified by a [transition](#transition) for non-top-level
 targets.
@@ -628,8 +605,7 @@ or `.bzl` file may load a given `.bzl` file. Without context, usually
 **See also:** [Visibility documentation](/versions/8.0.1/concepts/visibility)
 
 ### Workspace {#workspace}
-The environment shared by all Bazel commands run from the same [main
-repository](#repository).
+The environment shared by all Bazel commands run from the same [main repository](#repository).
 
 Note that historically the concepts of "repository" and "workspace" have been
 conflated; the term "workspace" has often been used to refer to the main
diff --git a/versions/8.0.1/release/backward-compatibility.mdx b/versions/8.0.1/release/backward-compatibility.mdx
index 56e33225..e78cdb85 100644
--- a/versions/8.0.1/release/backward-compatibility.mdx
+++ b/versions/8.0.1/release/backward-compatibility.mdx
@@ -6,11 +6,9 @@ This page provides information about how to handle backward compatibility,
 including migrating from one release to another and how to communicate
 incompatible changes.
 
-Bazel is evolving. Minor versions released as part of an [LTS major
-version](/versions/8.0.1/release#bazel-versioning) are fully backward-compatible. New major LTS
+Bazel is evolving. Minor versions released as part of an [LTS major version](/versions/8.0.1/release#bazel-versioning) are fully backward-compatible. New major LTS
 releases may contain incompatible changes that require some migration effort.
-For more information about Bazel's release model, please check out the [Release
-Model](/versions/8.0.1/release) page.
+For more information about Bazel's release model, please check out the [Release Model](/versions/8.0.1/release) page.
 
 ## Summary {#summary}
 
@@ -59,8 +57,7 @@ available.
 ## Communicating incompatible changes {#communicating-incompatible-changes}
 
 The primary source of information about incompatible changes are GitHub issues
-marked with an ["incompatible-change"
-label](https://github.com/bazelbuild/bazel/issues?q=label%3Aincompatible-change).
+marked with an ["incompatible-change" label](https://github.com/bazelbuild/bazel/issues?q=label%3Aincompatible-change).
 
 For every incompatible change, the issue specifies the following:
 
diff --git a/versions/8.0.1/release/index.mdx b/versions/8.0.1/release/index.mdx
index 9d1f03ca..c2fc734a 100644
--- a/versions/8.0.1/release/index.mdx
+++ b/versions/8.0.1/release/index.mdx
@@ -2,8 +2,7 @@
 title: 'Release Model'
 ---
 
-As announced in [the original blog
-post](https://blog.bazel.build/2020/11/10/long-term-support-release.html), Bazel
+As announced in [the original blog post](https://blog.bazel.build/2020/11/10/long-term-support-release.html), Bazel
 4.0 and higher versions provides support for two release tracks: rolling
 releases and long term support (LTS) releases. This page covers the latest
 information about Bazel's release model.
@@ -18,8 +17,7 @@ information about Bazel's release model.
 | Bazel 5 | Maintenance | [5.4.1](https://github.com/bazelbuild/bazel/releases/tag/5.4.1) | Jan 2025 |
 | Bazel 4 | Deprecated | [4.2.4](https://github.com/bazelbuild/bazel/releases/tag/4.2.4) | Jan 2024 |
 
-All Bazel LTS releases can be found on the [release
-page](https://github.com/bazelbuild/bazel/releases) on GitHub.
+All Bazel LTS releases can be found on the [release page](https://github.com/bazelbuild/bazel/releases) on GitHub.
 
 Note: Bazel version older than Bazel 5 are no longer supported, Bazel users are
 recommended to upgrade to the latest LTS release or use rolling releases if you
@@ -27,8 +25,7 @@ want to keep up with the latest changes at HEAD.
 
 ## Release versioning {#bazel-versioning}
 
-Bazel uses a _major.minor.patch_ [Semantic
-Versioning](https://semver.org/) scheme.
+Bazel uses a _major.minor.patch_ [Semantic Versioning](https://semver.org/) scheme.
 
 *   A _major release_ contains features that are not backward compatible with
     the previous release. Each major Bazel version is an LTS release.
@@ -71,8 +68,7 @@ Bazel regularly publish releases for two release tracks.
     release.
 *   Rolling releases can ship incompatible changes. Incompatible flags are
     recommended for major breaking changes, rolling out incompatible changes
-    should follow our [backward compatibility
-    policy](/versions/8.0.1/release/backward-compatibility).
+    should follow our [backward compatibility policy](/versions/8.0.1/release/backward-compatibility).
 
 ### LTS releases {#lts-releases}
 
@@ -88,8 +84,7 @@ Bazel regularly publish releases for two release tracks.
 *   A Bazel LTS release enters the Deprecated stage after being in ​​the
     Maintenance stage for 2 years.
 
-For planned releases, please check our [release
-issues](https://github.com/bazelbuild/bazel/issues?q=is%3Aopen+is%3Aissue+label%3Arelease)
+For planned releases, please check our [release issues](https://github.com/bazelbuild/bazel/issues?q=is%3Aopen+is%3Aissue+label%3Arelease)
 on Github.
 
 ## Release procedure & policies {#release-procedure-policies}
@@ -152,8 +147,7 @@ For LTS releases, the procedure and policies below are followed:
 1.  Identify release blockers and fix issues found on the release branch.
     *   The release branch is tested with the same test suite in
         [postsubmit](https://buildkite.com/bazel/bazel-bazel) and
-        [downstream test pipeline]
-        (https://buildkite.com/bazel/bazel-at-head-plus-downstream)
+        [downstream test pipeline](https://buildkite.com/bazel/bazel-at-head-plus-downstream)
         on Bazel CI. The Bazel team monitors testing results of the release
         branch and fixes any regressions found.
 1.  Create a new release candidate from the release branch when all known
@@ -209,5 +203,4 @@ feature.
 ## Rule compatibility {#rule-compatibility}
 
 If you are a rule authors and want to maintain compatibility with different
-Bazel versions, please check out the [Rule
-Compatibility](/versions/8.0.1/release/rule-compatibility) page.
+Bazel versions, please check out the [Rule Compatibility](/versions/8.0.1/release/rule-compatibility) page.
diff --git a/versions/8.0.1/release/rule-compatibility.mdx b/versions/8.0.1/release/rule-compatibility.mdx
index 8f6f4697..1661988a 100644
--- a/versions/8.0.1/release/rule-compatibility.mdx
+++ b/versions/8.0.1/release/rule-compatibility.mdx
@@ -53,18 +53,15 @@ Bazel LTS release.
 As Bazel rules authors, you can ensure a manageable migration process for users
 by following these best practices:
 
-1.  The rule should follow [Semantic
-    Versioning](https://semver.org/): minor versions of the same
+1.  The rule should follow [Semantic Versioning](https://semver.org/): minor versions of the same
     major version are backward compatible.
 1.  The rule at HEAD should be compatible with the latest Bazel LTS release.
 1.  The rule at HEAD should be compatible with Bazel at HEAD. To achieve this,
     you can
     *   Set up your own CI testing with Bazel at HEAD
-    *   Add your project to [Bazel downstream
-        testing](https://github.com/bazelbuild/continuous-integration/blob/master/docs/downstream-testing.md);
+    *   Add your project to [Bazel downstream testing](https://github.com/bazelbuild/continuous-integration/blob/master/docs/downstream-testing.md);
         the Bazel team files issues to your project if breaking changes in Bazel
-        affect your project, and you must follow our [downstream project
-        policies](https://github.com/bazelbuild/continuous-integration/blob/master/docs/downstream-testing.md#downstream-project-policies)
+        affect your project, and you must follow our [downstream project policies](https://github.com/bazelbuild/continuous-integration/blob/master/docs/downstream-testing.md#downstream-project-policies)
         to address issues timely.
 1.  The latest major version of the rule must be compatible with the latest
     Bazel LTS release.
diff --git a/versions/8.0.1/remote/bep-glossary.mdx b/versions/8.0.1/remote/bep-glossary.mdx
index cc43f478..4dfbc224 100644
--- a/versions/8.0.1/remote/bep-glossary.mdx
+++ b/versions/8.0.1/remote/bep-glossary.mdx
@@ -36,7 +36,7 @@ BEP contains an event like the following:
 ## ActionExecuted {#actionexecuted}
 
 Provides details about the execution of a specific
-[Action](/versions/8.0.1/rules/lib/actions) in a build. By default, this event is
+[Action](/versions/8.0.1/rules/lib/builtins/actions) in a build. By default, this event is
 included in the BEP only for failed actions, to support identifying the root cause
 of build failures. Users may set the `--build_event_publish_all_actions` flag
 to include all `ActionExecuted` events.
@@ -410,5 +410,4 @@ workspace, such as the execution root.
 
 ## WorkspaceStatus {#workspacestatus}
 
-A single `WorkspaceStatus` event contains the result of the [workspace status
-command](/versions/8.0.1/docs/user-manual#workspace-status).
+A single `WorkspaceStatus` event contains the result of the [workspace status command](/versions/8.0.1/docs/user-manual#workspace-status).
diff --git a/versions/8.0.1/remote/bep.mdx b/versions/8.0.1/remote/bep.mdx
index 4026dc45..f2f9b3ae 100644
--- a/versions/8.0.1/remote/bep.mdx
+++ b/versions/8.0.1/remote/bep.mdx
@@ -2,14 +2,12 @@
 title: 'Build Event Protocol'
 ---
 
-The [Build Event
-Protocol](https://github.com/bazelbuild/bazel/blob/master/src/main/java/com/google/devtools/build/lib/buildeventstream/proto/build_event_stream.proto)
+The [Build Event Protocol](https://github.com/bazelbuild/bazel/blob/master/src/main/java/com/google/devtools/build/lib/buildeventstream/proto/build_event_stream.proto)
 (BEP) allows third-party programs to gain insight into a Bazel invocation. For
 example, you could use the BEP to gather information for an IDE
 plugin or a dashboard that displays build results.
 
-The protocol is a set of [protocol
-buffer](https://developers.google.com/protocol-buffers/) messages with some
+The protocol is a set of [protocol buffer](https://developers.google.com/protocol-buffers/) messages with some
 semantics defined on top of it. It includes information about build and test
 results, build progress, the build configuration and much more. The BEP is
 intended to be consumed programmatically and makes parsing Bazel’s
@@ -20,16 +18,13 @@ build event is a protocol buffer message consisting of a build event identifier,
 a set of child event identifiers, and a payload.
 
 *  __Build Event Identifier:__ Depending on the kind of build event, it might be
-an [opaque
-string](https://github.com/bazelbuild/bazel/blob/7.1.0/src/main/java/com/google/devtools/build/lib/buildeventstream/proto/build_event_stream.proto#L131-L140)
-or [structured
-information](https://github.com/bazelbuild/bazel/blob/7.1.0/src/main/java/com/google/devtools/build/lib/buildeventstream/proto/build_event_stream.proto#L194-L205)
+an [opaque string](https://github.com/bazelbuild/bazel/blob/7.1.0/src/main/java/com/google/devtools/build/lib/buildeventstream/proto/build_event_stream.proto#L131-L140)
+or [structured information](https://github.com/bazelbuild/bazel/blob/7.1.0/src/main/java/com/google/devtools/build/lib/buildeventstream/proto/build_event_stream.proto#L194-L205)
 revealing more about the build event. A build event identifier is unique within
 a build.
 
 *  __Children:__ A build event may announce other build events, by including
-their build event identifiers in its [children
-field](https://github.com/bazelbuild/bazel/blob/7.1.0/src/main/java/com/google/devtools/build/lib/buildeventstream/proto/build_event_stream.proto#L1276).
+their build event identifiers in its [children field](https://github.com/bazelbuild/bazel/blob/7.1.0/src/main/java/com/google/devtools/build/lib/buildeventstream/proto/build_event_stream.proto#L1276).
 For example, the `PatternExpanded` build event announces the targets it expands
 to as children. The protocol guarantees that all events, except for the first
 event, are announced by a previous event.
@@ -91,8 +86,7 @@ human-readable formats, such as text and JSON:
 
 ## Build Event Service {#build-event-service}
 
-The [Build Event
-Service](https://github.com/googleapis/googleapis/blob/master/google/devtools/build/v1/publish_build_event.proto)
+The [Build Event Service](https://github.com/googleapis/googleapis/blob/master/google/devtools/build/v1/publish_build_event.proto)
 Protocol is a generic [gRPC](https://www.grpc.io) service for publishing build events. The Build Event
 Service protocol is independent of the BEP and treats BEP events as opaque bytes.
 Bazel ships with a gRPC client implementation of the Build Event Service protocol that
@@ -136,8 +130,7 @@ For a description of each of these flags, see the
 The BEP typically contains many references to log files (test.log, test.xml,
 etc. ) stored on the machine where Bazel is running. A remote BES server
 typically can't access these files as they are on different machines. A way to
-work around this issue is to use Bazel with [remote
-caching](/versions/8.0.1/remote/caching).
+work around this issue is to use Bazel with [remote caching](/versions/8.0.1/remote/caching).
 Bazel will upload all output files to the remote cache (including files
 referenced in the BEP) and the BES server can then fetch the referenced files
 from the cache.
diff --git a/versions/8.0.1/remote/cache-local.mdx b/versions/8.0.1/remote/cache-local.mdx
index 97780758..f5843de0 100644
--- a/versions/8.0.1/remote/cache-local.mdx
+++ b/versions/8.0.1/remote/cache-local.mdx
@@ -18,8 +18,7 @@ execution. However, local execution presents some additional challenges.
 ## Checking your cache hit rate {#cache-hits}
 
 Successful remote cache hits will show up in the status line, similar to
-[Cache Hits rate with Remote
-Execution](/versions/8.0.1/remote/cache-remote#check-cache-hits).
+[Cache Hits rate with Remote Execution](/versions/8.0.1/remote/cache-remote#check-cache-hits).
 
 In the standard output of your Bazel run, you will see something like the
 following:
@@ -66,8 +65,7 @@ the steps in this section.
    message you see does not give you enough information, try adding
    `--verbose_failures`.
 
-2. Follow the steps from [Troubleshooting cache hits for remote
-   execution](/versions/8.0.1/remote/cache-remote#troubleshooting_cache_hits) to
+2. Follow the steps from [Troubleshooting cache hits for remote execution](/versions/8.0.1/remote/cache-remote#troubleshooting_cache_hits) to
    ensure that your cache-writing Bazel invocations are able to get cache hits
    on the same machine and across machines.
 
@@ -81,7 +79,6 @@ the steps in this section.
    b. Ensure your cache-reading Bazel invocations build the same targets as the
       cache-writing Bazel invocations.
 
-   c. Follow the same steps as to [ensure caching across
-      machines](/versions/8.0.1/remote/cache-remote#caching-across-machines),
+   c. Follow the same steps as to [ensure caching across machines](/versions/8.0.1/remote/cache-remote#caching-across-machines),
       to ensure caching from your cache-writing Bazel invocation to your
       cache-reading Bazel invocation.
diff --git a/versions/8.0.1/remote/caching.mdx b/versions/8.0.1/remote/caching.mdx
index 5785ff88..e70ab98b 100644
--- a/versions/8.0.1/remote/caching.mdx
+++ b/versions/8.0.1/remote/caching.mdx
@@ -126,7 +126,7 @@ not provide technical support for bazel-remote.
 
 This cache stores contents on disk and also provides garbage collection
 to enforce an upper storage limit and clean unused artifacts. The cache is
-available as a [docker image] and its code is available on
+available as a [docker image](https://hub.docker.com/r/buchgr/bazel-remote-cache/) and its code is available on
 [GitHub](https://github.com/buchgr/bazel-remote/).
 Both the REST and gRPC remote cache APIs are supported.
 
@@ -308,8 +308,7 @@ or for the age of individual cache entries. Bazel will automatically garbage
 collect the disk cache while idling between builds; the idle timer can be set
 with `--experimental_disk_cache_gc_idle_delay` (defaulting to 5 minutes).
 
-As an alternative to automatic garbage collection, we also provide a [tool](
-https://github.com/bazelbuild/bazel/tree/master/src/tools/diskcache) to run a
+As an alternative to automatic garbage collection, we also provide a [tool](https://github.com/bazelbuild/bazel/tree/master/src/tools/diskcache) to run a
 garbage collection on demand.
 
 ## Known issues {#known-issues}
diff --git a/versions/8.0.1/remote/dynamic.mdx b/versions/8.0.1/remote/dynamic.mdx
index 20a1ed50..7c3b6124 100644
--- a/versions/8.0.1/remote/dynamic.mdx
+++ b/versions/8.0.1/remote/dynamic.mdx
@@ -12,8 +12,7 @@ alike.
 This page describes how to enable, tune, and debug dynamic execution. If you
 have both local and remote execution set up and are trying to adjust Bazel
 settings for better performance, this page is for you. If you don't already have
-remote execution set up, go to the Bazel [Remote Execution
-Overview](/versions/8.0.1/remote/rbe) first.
+remote execution set up, go to the Bazel [Remote Execution Overview](/versions/8.0.1/remote/rbe) first.
 
 ## Enabling dynamic execution? {#enabling-dynamic-execution}
 
@@ -44,14 +43,12 @@ are likely. The default value is 1000ms, but should be tuned to being just a bit
 longer than cache hits usually take. The actual time depends both on the remote
 system and on how long a round-trip takes. Usually, the value will be the same
 for all users of a given remote system, unless some of them are far enough away
-to add roundtrip latency. You can use the [Bazel profiling
-features](/versions/8.0.1/rules/performance#performance-profiling) to look at how long typical
+to add roundtrip latency. You can use the [Bazel profiling features](/versions/8.0.1/rules/performance#performance-profiling) to look at how long typical
 cache hits take.
 
 Dynamic execution can be used with local sandboxed strategy as well as with
 [persistent workers](/versions/8.0.1/remote/persistent). Persistent workers will automatically
-run with sandboxing when used with dynamic execution, and cannot use [multiplex
-workers](/versions/8.0.1/remote/multiplex). On Darwin and Windows systems, the sandboxed
+run with sandboxing when used with dynamic execution, and cannot use [multiplex workers](/versions/8.0.1/remote/multiplex). On Darwin and Windows systems, the sandboxed
 strategy can be slow; you can pass `--reuse_sandbox_directories` to reduce
 overhead of creating sandboxes on these systems.
 
@@ -67,8 +64,7 @@ entire action fails. This is an intentional choice to prevent differences
 between local and remote execution from going unnoticed.
 
 For more background on how dynamic execution and its locking works, see Julio
-Merino's excellent [blog
-posts](https://jmmv.dev/series/bazel-dynamic-execution/)
+Merino's excellent [blog posts](https://jmmv.dev/series/bazel-dynamic-execution/)
 
 ## When should I use dynamic execution? {#when-to-use}
 
diff --git a/versions/8.0.1/remote/output-directories.mdx b/versions/8.0.1/remote/output-directories.mdx
index 5035e823..5fee5672 100644
--- a/versions/8.0.1/remote/output-directories.mdx
+++ b/versions/8.0.1/remote/output-directories.mdx
@@ -25,7 +25,7 @@ The solution that's currently implemented:
 
 * Bazel must be invoked from a directory containing a repo boundary file, or a
   subdirectory thereof. In other words, Bazel must be invoked from inside a
-  [repository](../external/overview#repository). Otherwise, an error is
+  [repository](/versions/8.0.1/external/overview#repository). Otherwise, an error is
   reported.
 * The _outputRoot_ directory defaults to `${XDG_CACHE_HOME}/bazel` (or
   `~/.cache/bazel`, if the `XDG_CACHE_HOME` environment variable is not set) on
diff --git a/versions/8.0.1/remote/persistent.mdx b/versions/8.0.1/remote/persistent.mdx
index aa160ffc..f442f6ea 100644
--- a/versions/8.0.1/remote/persistent.mdx
+++ b/versions/8.0.1/remote/persistent.mdx
@@ -257,7 +257,6 @@ For more information on persistent workers, see:
 *   [Original persistent workers blog post](https://blog.bazel.build/2015/12/10/java-workers.html)
 *   [Haskell implementation description](https://www.tweag.io/blog/2019-09-25-bazel-ghc-persistent-worker-internship/)
 *   [Blog post by Mike Morearty](https://medium.com/@mmorearty/how-to-create-a-persistent-worker-for-bazel-7738bba2cabb)
-*   [Front End Development with Bazel: Angular/TypeScript and Persistent Workers
-    w/ Asana](https://www.youtube.com/watch?v=0pgERydGyqo)
+*   [Front End Development with Bazel: Angular/TypeScript and Persistent Workers w/ Asana](https://www.youtube.com/watch?v=0pgERydGyqo)
 *   [Bazel strategies explained](https://jmmv.dev/2019/12/bazel-strategies.html)
 *   [Informative worker strategy discussion on the bazel-discuss mailing list](https://groups.google.com/forum/#!msg/bazel-discuss/oAEnuhYOPm8/ol7hf4KWJgAJ)
diff --git a/versions/8.0.1/remote/rules.mdx b/versions/8.0.1/remote/rules.mdx
index 487edffa..b51b074c 100644
--- a/versions/8.0.1/remote/rules.mdx
+++ b/versions/8.0.1/remote/rules.mdx
@@ -54,8 +54,7 @@ variables that may not be set to equivalent values (or at all) in the remote
 execution environment.
 
 Toolchain rules currently exist for Bazel build and test rules for
-[Scala](https://github.com/bazelbuild/rules_scala/blob/master/scala/scala_toolch
-ain.bzl),
+[Scala](https://github.com/bazelbuild/rules_scala/blob/master/scala/scala_toolch ain.bzl),
 [Rust](https://github.com/bazelbuild/rules_rust/blob/main/rust/toolchain.bzl),
 and [Go](https://github.com/bazelbuild/rules_go/blob/master/go/toolchains.rst),
 and new toolchain rules are under way for other languages and tools such as
diff --git a/versions/8.0.1/remote/workspace.mdx b/versions/8.0.1/remote/workspace.mdx
index bde18bfc..a9d39143 100644
--- a/versions/8.0.1/remote/workspace.mdx
+++ b/versions/8.0.1/remote/workspace.mdx
@@ -11,8 +11,7 @@ on the host machine. If your workspace rules access information about the
 host machine for use during execution, your build is likely to break due to
 incompatibilities between the environments.
 
-As part of [adapting Bazel rules for remote
-execution](/versions/8.0.1/remote/rules), you need to find such workspace rules
+As part of [adapting Bazel rules for remote execution](/versions/8.0.1/remote/rules), you need to find such workspace rules
 and fix them. This page describes how to find potentially problematic workspace
 rules using the workspace log.
 
diff --git a/versions/8.0.1/rules/challenges.mdx b/versions/8.0.1/rules/challenges.mdx
index 5a851741..61cd08b4 100644
--- a/versions/8.0.1/rules/challenges.mdx
+++ b/versions/8.0.1/rules/challenges.mdx
@@ -208,7 +208,7 @@ Bazel is heavily affected by both of these scenarios, so we introduced a set of
 custom collection classes that effectively compress the information in memory by
 avoiding the copy at each step. Almost all of these data structures have set
 semantics, so we called it
-[depset](/versions/8.0.1/rules/lib/depset)
+[depset](/versions/8.0.1/rules/lib/builtins/depset)
 (also known as `NestedSet` in the internal implementation). The majority of
 changes to reduce Bazel's memory consumption over the past several years were
 changes to use depsets instead of whatever was previously used.
diff --git a/versions/8.0.1/rules/faq.mdx b/versions/8.0.1/rules/faq.mdx
index 84da9eee..200e0fb3 100644
--- a/versions/8.0.1/rules/faq.mdx
+++ b/versions/8.0.1/rules/faq.mdx
@@ -17,7 +17,7 @@ Bazel only executes the actions needed to produce the *requested* output files.
 
 * If you want the file to be built automatically whenever your target is
   mentioned on the command line, add it to your rule's default outputs by
-  returning a [`DefaultInfo`](lib/globals#DefaultInfo) provider.
+  returning a [`DefaultInfo`](/versions/8.0.1/rules/lib/globals#DefaultInfo) provider.
 
 See the [Rules page](/versions/8.0.1/extending/rules#requesting-output-files) for more information.
 
@@ -35,24 +35,24 @@ correct path.
 
 For actions, you declare inputs by passing them to the `ctx.actions.*` function
 that creates the action. The proper path for the file can be obtained using
-[`File.path`](lib/File#path).
+[`File.path`](/versions/8.0.1/rules/lib/builtins/File#path).
 
 For binaries (the executable outputs run by a `bazel run` or `bazel test`
 command), you declare inputs by including them in the
 [runfiles](/versions/8.0.1/extending/rules#runfiles). Instead of using the `path` field, use
-[`File.short_path`](lib/File#short_path), which is file's path relative to
+[`File.short_path`](/versions/8.0.1/rules/lib/builtins/File#short_path), which is file's path relative to
 the runfiles directory in which the binary executes.
 
 ## How can I control which files are built by `bazel build //pkg:mytarget`?
 
-Use the [`DefaultInfo`](lib/globals#DefaultInfo) provider to
+Use the [`DefaultInfo`](/versions/8.0.1/rules/lib/globals#DefaultInfo) provider to
 [set the default outputs](/versions/8.0.1/extending/rules#requesting-output-files).
 
 ## How can I run a program or do file I/O as part of my build?
 
 A tool can be declared as a target, just like any other part of your build, and
 run during the execution phase to help build other targets. To create an action
-that runs a tool, use [`ctx.actions.run`](lib/actions#run) and pass in the
+that runs a tool, use [`ctx.actions.run`](/versions/8.0.1/rules/lib/builtins/actions#run) and pass in the
 tool as the `executable` parameter.
 
 During the loading and analysis phases, a tool *cannot* run, nor can you perform
diff --git a/versions/8.0.1/rules/language.mdx b/versions/8.0.1/rules/language.mdx
index 80ad775e..7a021800 100644
--- a/versions/8.0.1/rules/language.mdx
+++ b/versions/8.0.1/rules/language.mdx
@@ -34,19 +34,19 @@ Starlark's semantics can differ from Python, but behavioral differences are
 rare, except for cases where Starlark raises an error. The following Python
 types are supported:
 
-* [None](lib/globals#None)
-* [bool](lib/bool)
-* [dict](lib/dict)
-* [tuple](lib/tuple)
-* [function](lib/function)
-* [int](lib/int)
-* [list](lib/list)
-* [string](lib/string)
+* [None](/versions/8.0.1/rules/lib/globals#None)
+* [bool](/versions/8.0.1/rules/lib/core/bool)
+* [dict](/versions/8.0.1/rules/lib/core/dict)
+* [tuple](/versions/8.0.1/rules/lib/core/tuple)
+* [function](/versions/8.0.1/rules/lib/core/function)
+* [int](/versions/8.0.1/rules/lib/core/int)
+* [list](/versions/8.0.1/rules/lib/core/list)
+* [string](/versions/8.0.1/rules/lib/core/string)
 
 ## Mutability
 
 Starlark favors immutability. Two mutable data structures are available:
-[lists](lib/list) and [dicts](lib/dict). Changes to mutable
+[lists](/versions/8.0.1/rules/lib/core/list) and [dicts](/versions/8.0.1/rules/lib/core/dict). Changes to mutable
 data-structures, such as appending a value to a list or deleting an entry in a
 dictionary are valid only for objects created in the current context. After a
 context finishes, its values become immutable.
@@ -93,10 +93,8 @@ values returned by rules are immutable.
 `BUILD` files register targets via making calls to rules. `.bzl` files provide
 definitions for constants, rules, macros, and functions.
 
-[Native functions](/versions/8.0.1/reference/be/functions) and [native rules](
-/reference/be/overview#language-specific-native-rules) are global symbols in
-`BUILD` files. `bzl` files need to load them using the [`native` module](
-/rules/lib/toplevel/native).
+[Native functions](/versions/8.0.1/reference/be/functions) and [native rules](/versions/8.0.1/reference/be/overview#language-specific-native-rules) are global symbols in
+`BUILD` files. `bzl` files need to load them using the [`native` module](/versions/8.0.1/rules/lib/toplevel/native).
 
 There are two syntactic restrictions in `BUILD` files: 1) declaring functions is
 illegal, and 2) `*args` and `**kwargs` arguments are not allowed.
@@ -130,7 +128,7 @@ not defined across value types. In short: `5 < 'foo'` will throw an error and
   error: `{"a": 4, "b": 7, "a": 1}`.
 
 * Strings are represented with double-quotes (such as when you call
-  [repr](lib/globals#repr)).
+  [repr](/versions/8.0.1/rules/lib/globals#repr)).
 
 * Strings aren't iterable.
 
@@ -138,12 +136,12 @@ The following Python features are not supported:
 
 * implicit string concatenation (use explicit `+` operator).
 * Chained comparisons (such as `1 < x < 5`).
-* `class` (see [`struct`](lib/struct#struct) function).
+* `class` (see [`struct`](/versions/8.0.1/rules/lib/builtins/struct#struct) function).
 * `import` (see [`load`](/versions/8.0.1/extending/concepts#loading-an-extension) statement).
 * `while`, `yield`.
 * float and set types.
 * generators and generator expressions.
 * `is` (use `==` instead).
-* `try`, `raise`, `except`, `finally` (see [`fail`](lib/globals#fail) for fatal errors).
+* `try`, `raise`, `except`, `finally` (see [`fail`](/versions/8.0.1/rules/lib/globals#fail) for fatal errors).
 * `global`, `nonlocal`.
 * most builtin functions, most methods.
diff --git a/versions/8.0.1/rules/legacy-macro-tutorial.mdx b/versions/8.0.1/rules/legacy-macro-tutorial.mdx
index 307a3092..1f058aa5 100644
--- a/versions/8.0.1/rules/legacy-macro-tutorial.mdx
+++ b/versions/8.0.1/rules/legacy-macro-tutorial.mdx
@@ -3,9 +3,7 @@ title: 'Creating a Legacy Macro'
 ---
 
 IMPORTANT: This tutorial is for [*legacy macros*](/versions/8.0.1/extending/legacy-macros). If
-you only need to support Bazel 8 or newer, we recommend using [symbolic
-macros](/versions/8.0.1/extending/macros) instead; take a look at [Creating a Symbolic
-Macro](../macro-tutorial).
+you only need to support Bazel 8 or newer, we recommend using [symbolic macros](/versions/8.0.1/extending/macros) instead; take a look at [Creating a Symbolic Macro](/versions/8.0.1/rules/macro-tutorial).
 
 Imagine that you need to run a tool as part of your build. For example, you
 may want to generate or preprocess a source file, or compress a binary. In this
diff --git a/versions/8.0.1/rules/lib/builtins/Action.mdx b/versions/8.0.1/rules/lib/builtins/Action.mdx
index eb868b1c..c8e4d10b 100644
--- a/versions/8.0.1/rules/lib/builtins/Action.mdx
+++ b/versions/8.0.1/rules/lib/builtins/Action.mdx
@@ -4,7 +4,7 @@ title: 'Action'
 
 An action created during rule analysis.
 
-This object is visible for the purpose of testing, and may be obtained from an `Actions` provider. It is normally not necessary to access `Action` objects or their fields within a rule's implementation function. You may instead want to see the [Rules page](https://bazel.build/versions/8.0.1/extending/rules#actions) for a general discussion of how to use actions when defining custom rules, or the [API reference](../builtins/actions) for creating actions.
+This object is visible for the purpose of testing, and may be obtained from an `Actions` provider. It is normally not necessary to access `Action` objects or their fields within a rule's implementation function. You may instead want to see the [Rules page](https://bazel.build/versions/8.0.1/extending/rules#actions) for a general discussion of how to use actions when defining custom rules, or the [API reference](/versions/8.0.1/rules/lib/builtins/actions) for creating actions.
 
 Some fields of this object are only applicable for certain kinds of actions. Fields that are inapplicable are set to `None`.
 
@@ -25,7 +25,7 @@ Some fields of this object are only applicable for certain kinds of actions. Fie
 sequence Action.args
 ```
 
-A list of frozen [Args](../builtins/Args) objects containing information about the action arguments. These objects contain accurate argument information, including arguments involving expanded action output directories. However, [Args](../builtins/Args) objects are not readable in the analysis phase. For a less accurate account of arguments which is available in the analysis phase, see [argv](#argv).
+A list of frozen [Args](/versions/8.0.1/rules/lib/builtins/Args) objects containing information about the action arguments. These objects contain accurate argument information, including arguments involving expanded action output directories. However, [Args](/versions/8.0.1/rules/lib/builtins/Args) objects are not readable in the analysis phase. For a less accurate account of arguments which is available in the analysis phase, see [argv](#argv).
 
 Note that some types of actions do not yet support exposure of this field. For such action types, this is `None`.
 May return `None`.
@@ -36,7 +36,7 @@ May return `None`.
 sequence Action.argv
 ```
 
-For actions created by [ctx.actions.run()](../builtins/actions#run) or [ctx.actions.run\_shell()](../builtins/actions#run_shell) an immutable list of the arguments for the command line to be executed. Note that for shell actions the first two arguments will be the shell path and `"-c"`.
+For actions created by [ctx.actions.run()](/versions/8.0.1/rules/lib/builtins/actions#run) or [ctx.actions.run\_shell()](/versions/8.0.1/rules/lib/builtins/actions#run_shell) an immutable list of the arguments for the command line to be executed. Note that for shell actions the first two arguments will be the shell path and `"-c"`.
 May return `None`.
 
 ## content
@@ -45,7 +45,7 @@ May return `None`.
 string Action.content
 ```
 
-For actions created by [ctx.actions.write()](../builtins/actions#write) or [ctx.actions.expand\_template()](../builtins/actions#expand_template), the contents of the file to be written, if those contents can be computed during the analysis phase. The value is `None` if the contents cannot be determined until the execution phase, such as when a directory in an [Args](../builtins/Args) object needs to be expanded.
+For actions created by [ctx.actions.write()](/versions/8.0.1/rules/lib/builtins/actions#write) or [ctx.actions.expand\_template()](/versions/8.0.1/rules/lib/builtins/actions#expand_template), the contents of the file to be written, if those contents can be computed during the analysis phase. The value is `None` if the contents cannot be determined until the execution phase, such as when a directory in an [Args](/versions/8.0.1/rules/lib/builtins/Args) object needs to be expanded.
 May return `None`.
 
 ## env
@@ -86,5 +86,5 @@ A set of the output files of this action.
 dict Action.substitutions
 ```
 
-For actions created by [ctx.actions.expand\_template()](../builtins/actions#expand_template), an immutable dict holding the substitution mapping.
+For actions created by [ctx.actions.expand\_template()](/versions/8.0.1/rules/lib/builtins/actions#expand_template), an immutable dict holding the substitution mapping.
 May return `None`.
\ No newline at end of file
diff --git a/versions/8.0.1/rules/lib/builtins/Args.mdx b/versions/8.0.1/rules/lib/builtins/Args.mdx
index 34c9ff30..c6808447 100644
--- a/versions/8.0.1/rules/lib/builtins/Args.mdx
+++ b/versions/8.0.1/rules/lib/builtins/Args.mdx
@@ -4,15 +4,15 @@ title: 'Args'
 
 An object that encapsulates, in a memory-efficient way, the data needed to build part or all of a command line.
 
-It often happens that an action requires a large command line containing values accumulated from transitive dependencies. For example, a linker command line might list every object file needed by all of the libraries being linked. It is best practice to store such transitive data in [`depset`](../builtins/depset)s, so that they can be shared by multiple targets. However, if the rule author had to convert these depsets into lists of strings in order to construct an action command line, it would defeat this memory-sharing optimization.
+It often happens that an action requires a large command line containing values accumulated from transitive dependencies. For example, a linker command line might list every object file needed by all of the libraries being linked. It is best practice to store such transitive data in [`depset`](/versions/8.0.1/rules/lib/builtins/depset)s, so that they can be shared by multiple targets. However, if the rule author had to convert these depsets into lists of strings in order to construct an action command line, it would defeat this memory-sharing optimization.
 
 For this reason, the action-constructing functions accept `Args` objects in addition to strings. Each `Args` object represents a concatenation of strings and depsets, with optional transformations for manipulating the data. `Args` objects do not process the depsets they encapsulate until the execution phase, when it comes time to calculate the command line. This helps defer any expensive copying until after the analysis phase is complete. See the [Optimizing Performance](https://bazel.build/versions/8.0.1/rules/performance) page for more information.
 
-`Args` are constructed by calling [`ctx.actions.args()`](../builtins/actions#args). They can be passed as the `arguments` parameter of [`ctx.actions.run()`](../builtins/actions#run) or [`ctx.actions.run_shell()`](../builtins/actions#run_shell). Each mutation of an `Args` object appends values to the eventual command line.
+`Args` are constructed by calling [`ctx.actions.args()`](/versions/8.0.1/rules/lib/builtins/actions#args). They can be passed as the `arguments` parameter of [`ctx.actions.run()`](/versions/8.0.1/rules/lib/builtins/actions#run) or [`ctx.actions.run_shell()`](/versions/8.0.1/rules/lib/builtins/actions#run_shell). Each mutation of an `Args` object appends values to the eventual command line.
 
 The `map_each` feature allows you to customize how items are transformed into strings. If you do not provide a `map_each` function, the standard conversion is as follows:
 
-* Values that are already strings are left as-is.* [`File`](../builtins/File) objects are turned into their `File.path` values.* [`Label`](../builtins/Label) objects are turned into a string representation that resolves back to the same object when resolved in the context of the main repository. If possible, the string representation uses the apparent name of a repository in favor of the repository's canonical name, which makes this representation suited for use in BUILD files. While the exact form of the representation is not guaranteed, typical examples are `//foo:bar`, `@repo//foo:bar` and `@@canonical_name+//foo:bar.bzl`.* All other types are turned into strings in an *unspecified* manner. For this reason, you should avoid passing values that are not of string or `File` type to `add()`, and if you pass them to `add_all()` or `add_joined()` then you should provide a `map_each` function.
+* Values that are already strings are left as-is.* [`File`](/versions/8.0.1/rules/lib/builtins/File) objects are turned into their `File.path` values.* [`Label`](/versions/8.0.1/rules/lib/builtins/Label) objects are turned into a string representation that resolves back to the same object when resolved in the context of the main repository. If possible, the string representation uses the apparent name of a repository in favor of the repository's canonical name, which makes this representation suited for use in BUILD files. While the exact form of the representation is not guaranteed, typical examples are `//foo:bar`, `@repo//foo:bar` and `@@canonical_name+//foo:bar.bzl`.* All other types are turned into strings in an *unspecified* manner. For this reason, you should avoid passing values that are not of string or `File` type to `add()`, and if you pass them to `add_all()` or `add_joined()` then you should provide a `map_each` function.
 
 When using string formatting (`format`, `format_each`, and `format_joined` params of the `add*()` methods), the format template is interpreted in the same way as `%`-substitution on strings, except that the template must have exactly one substitution placeholder and it must be `%s`. Literal percents may be escaped as `%%`. Formatting is applied after the value is converted to a string as per the above.
 
@@ -64,7 +64,7 @@ Appends an argument to this command line.
 | --- | --- |
 | `arg_name_or_value` | required  If two positional parameters are passed this is interpreted as the arg name. The arg name is added before the value without any processing. If only one positional parameter is passed, it is interpreted as `value` (see below). |
 | `value` | default is `unbound`  The object to append. It will be converted to a string using the standard conversion mentioned above. Since there is no `map_each` parameter for this function, `value` should be either a string or a `File`. A list, tuple, depset, or directory `File` must be passed to [`add_all()` or [`add_joined()`](#add_joined) instead of this method.](#add_all) |
-| `format` | [string](../core/string); or `None`; default is `None`  A format string pattern, to be applied to the stringified version of `value`. |
+| `format` | [string](/versions/8.0.1/rules/lib/core/string); or `None`; default is `None`  A format string pattern, to be applied to the stringified version of `value`. |
 
 ## add\_all
 
@@ -86,15 +86,15 @@ Note that empty strings are valid arguments that are subject to all these proces
 | Parameter | Description |
 | --- | --- |
 | `arg_name_or_values` | required  If two positional parameters are passed this is interpreted as the arg name. The arg name is added before the `values` as a separate argument without any processing. This arg name will not be added if `omit_if_empty` is true (the default) and no other items are appended (as happens if `values` is empty or all of its items are filtered). If only one positional parameter is passed, it is interpreted as `values` (see below). |
-| `values` | [sequence](../core/list); or [depset](../builtins/depset); default is `unbound`  The list, tuple, or depset whose items will be appended. |
-| `map_each` | callable; or `None`; default is `None`  A function that converts each item to zero or more strings, which may be further processed before appending. If this param is not provided, the standard conversion is used. The function is passed either one or two positional arguments: the item to convert, followed by an optional [`DirectoryExpander`](../builtins/DirectoryExpander). The second argument will be passed only if the supplied function is user-defined (not built-in) and declares more than one parameter. The return value's type depends on how many arguments are to be produced for the item:  * In the common case when each item turns into one string, the function should return that string.* If the item is to be filtered out entirely, the function should return `None`.* If the item turns into multiple strings, the function returns a list of those strings.  Returning a single string or `None` has the same effect as returning a list of length 1 or length 0 respectively. However, it is more efficient and readable to avoid creating a list where it is not needed. Ordinarily, items that are directories are automatically expanded to their contents when `expand_directories=True` is set. However, this will not expand directories contained inside other values -- for instance, when the items are structs that have directories as fields. In this situation, the `DirectoryExpander` argument can be applied to manually obtain the files of a given directory. To avoid unintended retention of large analysis-phase data structures into the execution phase, the `map_each` function must be declared by a top-level `def` statement; it may not be a nested function closure by default. *Warning:* [`print()`](../globals/all#print) statements that are executed during the call to `map_each` will not produce any visible output. |
-| `format_each` | [string](../core/string); or `None`; default is `None`  An optional format string pattern, applied to each string returned by the `map_each` function. The format string must have exactly one '%s' placeholder. |
-| `before_each` | [string](../core/string); or `None`; default is `None`  An optional argument to append before each argument derived from `values` is appended. |
-| `omit_if_empty` | [bool](../core/bool); default is `True`  If true, if there are no arguments derived from `values` to be appended, then all further processing is suppressed and the command line will be unchanged. If false, the arg name and `terminate_with`, if provided, will still be appended regardless of whether or not there are other arguments. |
-| `uniquify` | [bool](../core/bool); default is `False`  If true, duplicate arguments that are derived from `values` will be omitted. Only the first occurrence of each argument will remain. Usually this feature is not needed because depsets already omit duplicates, but it can be useful if `map_each` emits the same string for multiple items. |
-| `expand_directories` | [bool](../core/bool); default is `True`  If true, any directories in `values` will be expanded to a flat list of files. This happens before `map_each` is applied. |
-| `terminate_with` | [string](../core/string); or `None`; default is `None`  An optional argument to append after all other arguments. This argument will not be added if `omit_if_empty` is true (the default) and no other items are appended (as happens if `values` is empty or all of its items are filtered). |
-| `allow_closure` | [bool](../core/bool); default is `False`  If true, allows the use of closures in function parameters like `map_each`. Usually this isn't necessary and it risks retaining large analysis-phase data structures into the execution phase. |
+| `values` | [sequence](/versions/8.0.1/rules/lib/core/list); or [depset](/versions/8.0.1/rules/lib/builtins/depset); default is `unbound`  The list, tuple, or depset whose items will be appended. |
+| `map_each` | callable; or `None`; default is `None`  A function that converts each item to zero or more strings, which may be further processed before appending. If this param is not provided, the standard conversion is used. The function is passed either one or two positional arguments: the item to convert, followed by an optional [`DirectoryExpander`](/versions/8.0.1/rules/lib/builtins/DirectoryExpander). The second argument will be passed only if the supplied function is user-defined (not built-in) and declares more than one parameter. The return value's type depends on how many arguments are to be produced for the item:  * In the common case when each item turns into one string, the function should return that string.* If the item is to be filtered out entirely, the function should return `None`.* If the item turns into multiple strings, the function returns a list of those strings.  Returning a single string or `None` has the same effect as returning a list of length 1 or length 0 respectively. However, it is more efficient and readable to avoid creating a list where it is not needed. Ordinarily, items that are directories are automatically expanded to their contents when `expand_directories=True` is set. However, this will not expand directories contained inside other values -- for instance, when the items are structs that have directories as fields. In this situation, the `DirectoryExpander` argument can be applied to manually obtain the files of a given directory. To avoid unintended retention of large analysis-phase data structures into the execution phase, the `map_each` function must be declared by a top-level `def` statement; it may not be a nested function closure by default. *Warning:* [`print()`](/versions/8.0.1/rules/lib/globals/all#print) statements that are executed during the call to `map_each` will not produce any visible output. |
+| `format_each` | [string](/versions/8.0.1/rules/lib/core/string); or `None`; default is `None`  An optional format string pattern, applied to each string returned by the `map_each` function. The format string must have exactly one '%s' placeholder. |
+| `before_each` | [string](/versions/8.0.1/rules/lib/core/string); or `None`; default is `None`  An optional argument to append before each argument derived from `values` is appended. |
+| `omit_if_empty` | [bool](/versions/8.0.1/rules/lib/core/bool); default is `True`  If true, if there are no arguments derived from `values` to be appended, then all further processing is suppressed and the command line will be unchanged. If false, the arg name and `terminate_with`, if provided, will still be appended regardless of whether or not there are other arguments. |
+| `uniquify` | [bool](/versions/8.0.1/rules/lib/core/bool); default is `False`  If true, duplicate arguments that are derived from `values` will be omitted. Only the first occurrence of each argument will remain. Usually this feature is not needed because depsets already omit duplicates, but it can be useful if `map_each` emits the same string for multiple items. |
+| `expand_directories` | [bool](/versions/8.0.1/rules/lib/core/bool); default is `True`  If true, any directories in `values` will be expanded to a flat list of files. This happens before `map_each` is applied. |
+| `terminate_with` | [string](/versions/8.0.1/rules/lib/core/string); or `None`; default is `None`  An optional argument to append after all other arguments. This argument will not be added if `omit_if_empty` is true (the default) and no other items are appended (as happens if `values` is empty or all of its items are filtered). |
+| `allow_closure` | [bool](/versions/8.0.1/rules/lib/core/bool); default is `False`  If true, allows the use of closures in function parameters like `map_each`. Usually this isn't necessary and it risks retaining large analysis-phase data structures into the execution phase. |
 
 ## add\_joined
 
@@ -113,15 +113,15 @@ If after filtering there are no strings to join into an argument, and if `omit_i
 | Parameter | Description |
 | --- | --- |
 | `arg_name_or_values` | required  If two positional parameters are passed this is interpreted as the arg name. The arg name is added before `values` without any processing. This arg will not be added if `omit_if_empty` is true (the default) and there are no strings derived from `values` to join together (which can happen if `values` is empty or all of its items are filtered). If only one positional parameter is passed, it is interpreted as `values` (see below). |
-| `values` | [sequence](../core/list); or [depset](../builtins/depset); default is `unbound`  The list, tuple, or depset whose items will be joined. |
-| `join_with` | [string](../core/string); required  A delimiter string used to join together the strings obtained from applying `map_each` and `format_each`, in the same manner as [`string.join()`](../core/string#join). |
+| `values` | [sequence](/versions/8.0.1/rules/lib/core/list); or [depset](/versions/8.0.1/rules/lib/builtins/depset); default is `unbound`  The list, tuple, or depset whose items will be joined. |
+| `join_with` | [string](/versions/8.0.1/rules/lib/core/string); required  A delimiter string used to join together the strings obtained from applying `map_each` and `format_each`, in the same manner as [`string.join()`](/versions/8.0.1/rules/lib/core/string#join). |
 | `map_each` | callable; or `None`; default is `None`  Same as for [`add_all`](#add_all.map_each). |
-| `format_each` | [string](../core/string); or `None`; default is `None`  Same as for [`add_all`](#add_all.format_each). |
-| `format_joined` | [string](../core/string); or `None`; default is `None`  An optional format string pattern applied to the joined string. The format string must have exactly one '%s' placeholder. |
-| `omit_if_empty` | [bool](../core/bool); default is `True`  If true, if there are no strings to join together (either because `values` is empty or all its items are filtered), then all further processing is suppressed and the command line will be unchanged. If false, then even if there are no strings to join together, two arguments will be appended: the arg name followed by an empty string (which is the logical join of zero strings). |
-| `uniquify` | [bool](../core/bool); default is `False`  Same as for [`add_all`](#add_all.uniquify). |
-| `expand_directories` | [bool](../core/bool); default is `True`  Same as for [`add_all`](#add_all.expand_directories). |
-| `allow_closure` | [bool](../core/bool); default is `False`  Same as for [`add_all`](#add_all.allow_closure). |
+| `format_each` | [string](/versions/8.0.1/rules/lib/core/string); or `None`; default is `None`  Same as for [`add_all`](#add_all.format_each). |
+| `format_joined` | [string](/versions/8.0.1/rules/lib/core/string); or `None`; default is `None`  An optional format string pattern applied to the joined string. The format string must have exactly one '%s' placeholder. |
+| `omit_if_empty` | [bool](/versions/8.0.1/rules/lib/core/bool); default is `True`  If true, if there are no strings to join together (either because `values` is empty or all its items are filtered), then all further processing is suppressed and the command line will be unchanged. If false, then even if there are no strings to join together, two arguments will be appended: the arg name followed by an empty string (which is the logical join of zero strings). |
+| `uniquify` | [bool](/versions/8.0.1/rules/lib/core/bool); default is `False`  Same as for [`add_all`](#add_all.uniquify). |
+| `expand_directories` | [bool](/versions/8.0.1/rules/lib/core/bool); default is `True`  Same as for [`add_all`](#add_all.expand_directories). |
+| `allow_closure` | [bool](/versions/8.0.1/rules/lib/core/bool); default is `False`  Same as for [`add_all`](#add_all.allow_closure). |
 
 ## set\_param\_file\_format
 
@@ -135,7 +135,7 @@ Sets the format of the param file, if one is used
 
 | Parameter | Description |
 | --- | --- |
-| `format` | [string](../core/string); required  Must be one of:  * "multiline": Each item (argument name or value) is written verbatim to the param file with a newline character following it. * "shell": Same as "multiline", but the items are shell-quoted * "flag\_per\_line": Same as "multiline", but (1) only flags (beginning with '--') are written to the param file, and (2) the values of the flags, if any, are written on the same line with a '=' separator. This is the format expected by the Abseil flags library.   The format defaults to "shell" if not called. |
+| `format` | [string](/versions/8.0.1/rules/lib/core/string); required  Must be one of:  * "multiline": Each item (argument name or value) is written verbatim to the param file with a newline character following it. * "shell": Same as "multiline", but the items are shell-quoted * "flag\_per\_line": Same as "multiline", but (1) only flags (beginning with '--') are written to the param file, and (2) the values of the flags, if any, are written on the same line with a '=' separator. This is the format expected by the Abseil flags library.   The format defaults to "shell" if not called. |
 
 ## use\_param\_file
 
@@ -151,5 +151,5 @@ Bazel may choose to elide writing the params file to the output tree during exec
 
 | Parameter | Description |
 | --- | --- |
-| `param_file_arg` | [string](../core/string); required  A format string with a single "%s". If the args are spilled to a params file then they are replaced with an argument consisting of this string formatted with the path of the params file. For example, if the args are spilled to a params file "params.txt", then specifying "--file=%s" would cause the action command line to contain "--file=params.txt". |
-| `use_always` | [bool](../core/bool); default is `False`  Whether to always spill the args to a params file. If false, bazel will decide whether the arguments need to be spilled based on your system and arg length. |
\ No newline at end of file
+| `param_file_arg` | [string](/versions/8.0.1/rules/lib/core/string); required  A format string with a single "%s". If the args are spilled to a params file then they are replaced with an argument consisting of this string formatted with the path of the params file. For example, if the args are spilled to a params file "params.txt", then specifying "--file=%s" would cause the action command line to contain "--file=params.txt". |
+| `use_always` | [bool](/versions/8.0.1/rules/lib/core/bool); default is `False`  Whether to always spill the args to a params file. If false, bazel will decide whether the arguments need to be spilled based on your system and arg length. |
\ No newline at end of file
diff --git a/versions/8.0.1/rules/lib/builtins/Aspect.mdx b/versions/8.0.1/rules/lib/builtins/Aspect.mdx
index 8b5d5a51..4e68fe3f 100644
--- a/versions/8.0.1/rules/lib/builtins/Aspect.mdx
+++ b/versions/8.0.1/rules/lib/builtins/Aspect.mdx
@@ -3,4 +3,4 @@ title: 'Aspect'
 ---
 
 For more information about Aspects, please consult the
-[documentation of the aspect function](../globals/bzl#aspect) or the [introduction to Aspects](https://bazel.build/versions/8.0.1/rules/aspects).
\ No newline at end of file
+[documentation of the aspect function](/versions/8.0.1/rules/lib/globals/bzl#aspect) or the [introduction to Aspects](https://bazel.build/versions/8.0.1/rules/aspects).
\ No newline at end of file
diff --git a/versions/8.0.1/rules/lib/builtins/Attribute.mdx b/versions/8.0.1/rules/lib/builtins/Attribute.mdx
index 18486c41..2aba527a 100644
--- a/versions/8.0.1/rules/lib/builtins/Attribute.mdx
+++ b/versions/8.0.1/rules/lib/builtins/Attribute.mdx
@@ -2,4 +2,4 @@
 title: 'Attribute'
 ---
 
-Representation of a definition of an attribute. Use the [attr](../toplevel/attr) module to create an Attribute. They are only for use with a [rule](../globals/bzl#rule) or an [aspect](../globals/bzl#aspect).
\ No newline at end of file
+Representation of a definition of an attribute. Use the [attr](/versions/8.0.1/rules/lib/toplevel/attr) module to create an Attribute. They are only for use with a [rule](/versions/8.0.1/rules/lib/globals/bzl#rule) or an [aspect](/versions/8.0.1/rules/lib/globals/bzl#aspect).
\ No newline at end of file
diff --git a/versions/8.0.1/rules/lib/builtins/DirectoryExpander.mdx b/versions/8.0.1/rules/lib/builtins/DirectoryExpander.mdx
index 8bf9ae69..6f34d4f2 100644
--- a/versions/8.0.1/rules/lib/builtins/DirectoryExpander.mdx
+++ b/versions/8.0.1/rules/lib/builtins/DirectoryExpander.mdx
@@ -2,7 +2,7 @@
 title: 'DirectoryExpander'
 ---
 
-Expands directories created by [`ctx.actions.declare_directory`](../builtins/actions#declare_directory) during the execution phase. This is useful to expand directories in [`map_each`](../builtins/Args#add_all.map_each).
+Expands directories created by [`ctx.actions.declare_directory`](/versions/8.0.1/rules/lib/builtins/actions#declare_directory) during the execution phase. This is useful to expand directories in [`map_each`](/versions/8.0.1/rules/lib/builtins/Args#add_all.map_each).
 
 ## Members
 
@@ -20,4 +20,4 @@ If the given `File` is a directory, this returns a list of `File`s recursively u
 
 | Parameter | Description |
 | --- | --- |
-| `file` | [File](../builtins/File); required  The directory or file to expand. |
\ No newline at end of file
+| `file` | [File](/versions/8.0.1/rules/lib/builtins/File); required  The directory or file to expand. |
\ No newline at end of file
diff --git a/versions/8.0.1/rules/lib/builtins/DottedVersion.mdx b/versions/8.0.1/rules/lib/builtins/DottedVersion.mdx
index f17cea85..35d43a5f 100644
--- a/versions/8.0.1/rules/lib/builtins/DottedVersion.mdx
+++ b/versions/8.0.1/rules/lib/builtins/DottedVersion.mdx
@@ -20,4 +20,4 @@ Compares based on most significant (first) not-matching version component. So, f
 
 | Parameter | Description |
 | --- | --- |
-| `other` | [DottedVersion](../builtins/DottedVersion); required  The other dotted version. |
\ No newline at end of file
+| `other` | [DottedVersion](/versions/8.0.1/rules/lib/builtins/DottedVersion); required  The other dotted version. |
\ No newline at end of file
diff --git a/versions/8.0.1/rules/lib/builtins/File.mdx b/versions/8.0.1/rules/lib/builtins/File.mdx
index 88a8642f..794d1f32 100644
--- a/versions/8.0.1/rules/lib/builtins/File.mdx
+++ b/versions/8.0.1/rules/lib/builtins/File.mdx
@@ -4,7 +4,7 @@ title: 'File'
 
 This object is created during the analysis phase to represent a file or directory that will be read or written during the execution phase. It is not an open file handle, and cannot be used to directly read or write file contents. Rather, you use it to construct the action graph in a rule implementation function by passing it to action-creating functions. See the [Rules page](https://bazel.build/versions/8.0.1/extending/rules#files) for more information.
 
-When a `File` is passed to an [`Args`](../builtins/Args) object without using a `map_each` function, it is converted to a string by taking the value of its `path` field.
+When a `File` is passed to an [`Args`](/versions/8.0.1/rules/lib/builtins/Args) object without using a `map_each` function, it is converted to a string by taking the value of its `path` field.
 
 ## Members
 
@@ -83,7 +83,7 @@ May return `None`.
 string File.path
 ```
 
-The execution path of this file, relative to the workspace's execution directory. It consists of two parts, an optional first part called the *root* (see also the [root](../builtins/root) module), and the second part which is the `short_path`. The root may be empty, which it usually is for non-generated files. For generated files it usually contains a configuration-specific path fragment that encodes things like the target CPU architecture that was used while building said file. Use the `short_path` for the path under which the file is mapped if it's in the runfiles of a binary.
+The execution path of this file, relative to the workspace's execution directory. It consists of two parts, an optional first part called the *root* (see also the [root](/versions/8.0.1/rules/lib/builtins/root) module), and the second part which is the `short_path`. The root may be empty, which it usually is for non-generated files. For generated files it usually contains a configuration-specific path fragment that encodes things like the target CPU architecture that was used while building said file. Use the `short_path` for the path under which the file is mapped if it's in the runfiles of a binary.
 
 ## root
 
@@ -107,4 +107,4 @@ The path of this file relative to its root. This excludes the aforementioned *ro
 string File.tree_relative_path
 ```
 
-The path of this file relative to the root of the ancestor's tree, if the ancestor's [is\_directory](#is_directory) field is true. `tree_relative_path` is only available for expanded files of a directory in an action command, i.e. [Args.add\_all()](../builtins/Args#add_all). For other types of files, it is an error to access this field.
\ No newline at end of file
+The path of this file relative to the root of the ancestor's tree, if the ancestor's [is\_directory](#is_directory) field is true. `tree_relative_path` is only available for expanded files of a directory in an action command, i.e. [Args.add\_all()](/versions/8.0.1/rules/lib/builtins/Args#add_all). For other types of files, it is an error to access this field.
\ No newline at end of file
diff --git a/versions/8.0.1/rules/lib/builtins/Label.mdx b/versions/8.0.1/rules/lib/builtins/Label.mdx
index 557dd05d..78afb05c 100644
--- a/versions/8.0.1/rules/lib/builtins/Label.mdx
+++ b/versions/8.0.1/rules/lib/builtins/Label.mdx
@@ -33,7 +33,7 @@ For macros, a related function, `native.package_relative_label()`, converts the
 
 | Parameter | Description |
 | --- | --- |
-| `input` | [string](../core/string); or [Label](../builtins/Label); required  The input label string or Label object. If a Label object is passed, it's returned as is. |
+| `input` | [string](/versions/8.0.1/rules/lib/core/string); or [Label](/versions/8.0.1/rules/lib/builtins/Label); required  The input label string or Label object. If a Label object is passed, it's returned as is. |
 
 ## name
 
@@ -66,7 +66,7 @@ Label Label.relative(relName)
 ```
 
 **Experimental**. This API is experimental and may change at any time. Please do not depend on it. It may be enabled on an experimental basis by setting `--+incompatible_enable_deprecated_label_apis`
-**Deprecated.** This method behaves surprisingly when used with an argument containing an apparent repo name. Prefer [`Label.same_package_label()`](#same_package_label), [`native.package_relative_label()`](../toplevel/native#package_relative_label), or [`Label()`](#Label) instead.
+**Deprecated.** This method behaves surprisingly when used with an argument containing an apparent repo name. Prefer [`Label.same_package_label()`](#same_package_label), [`native.package_relative_label()`](/versions/8.0.1/rules/lib/toplevel/native#package_relative_label), or [`Label()`](#Label) instead.
 
 Resolves a label that is either absolute (starts with `//`) or relative to the current package. If this label is in a remote repository, the argument will be resolved relative to that repository. If the argument contains a repository name, the current label is ignored and the argument is returned as-is, except that the repository name is rewritten if it is in the current repository mapping. Reserved labels will also be returned as-is.
 For example:
@@ -89,7 +89,7 @@ Label("@repo//foo/bar:baz").relative("@other//wiz:quux") == Label("@remapped//wi
 
 | Parameter | Description |
 | --- | --- |
-| `relName` | [string](../core/string); required |
+| `relName` | [string](/versions/8.0.1/rules/lib/core/string); required |
 
 ## repo\_name
 
@@ -115,7 +115,7 @@ Creates a label in the same package as this label with the given target name.
 
 | Parameter | Description |
 | --- | --- |
-| `target_name` | [string](../core/string); required |
+| `target_name` | [string](/versions/8.0.1/rules/lib/core/string); required |
 
 ## workspace\_name
 
diff --git a/versions/8.0.1/rules/lib/builtins/LateBoundDefault.mdx b/versions/8.0.1/rules/lib/builtins/LateBoundDefault.mdx
index edd0010c..6f7a081a 100644
--- a/versions/8.0.1/rules/lib/builtins/LateBoundDefault.mdx
+++ b/versions/8.0.1/rules/lib/builtins/LateBoundDefault.mdx
@@ -4,4 +4,4 @@ title: 'LateBoundDefault'
 
 Represents a late-bound default attribute value of type 'Label'. The value of a LateBoundDefault is only resolvable in the context of a rule implementation function, and depends on the current build configuration. For example, a LateBoundDefault might represent the Label of the java toolchain in the current build configuration.
 
-See [configuration\_field](../globals/bzl#configuration_field) for example usage.
\ No newline at end of file
+See [configuration\_field](/versions/8.0.1/rules/lib/globals/bzl#configuration_field) for example usage.
\ No newline at end of file
diff --git a/versions/8.0.1/rules/lib/builtins/Provider.mdx b/versions/8.0.1/rules/lib/builtins/Provider.mdx
index 54b9cf36..ed7d81df 100644
--- a/versions/8.0.1/rules/lib/builtins/Provider.mdx
+++ b/versions/8.0.1/rules/lib/builtins/Provider.mdx
@@ -14,7 +14,7 @@ This value has a dual purpose:
   ```
 
   Note: Some providers, defined internally, do not allow instance creation
-* It is a *key* to access a provider instance on a [Target](../builtins/Target)
+* It is a *key* to access a provider instance on a [Target](/versions/8.0.1/rules/lib/builtins/Target)
 
   ```
   DataInfo = provider()
@@ -22,4 +22,4 @@ This value has a dual purpose:
     ... ctx.attr.dep[DataInfo]
   ```
 
-Create a new `Provider` using the [provider](../globals/bzl#provider) function.
\ No newline at end of file
+Create a new `Provider` using the [provider](/versions/8.0.1/rules/lib/globals/bzl#provider) function.
\ No newline at end of file
diff --git a/versions/8.0.1/rules/lib/builtins/TemplateDict.mdx b/versions/8.0.1/rules/lib/builtins/TemplateDict.mdx
index 5f18fd44..ba3a7fc9 100644
--- a/versions/8.0.1/rules/lib/builtins/TemplateDict.mdx
+++ b/versions/8.0.1/rules/lib/builtins/TemplateDict.mdx
@@ -21,8 +21,8 @@ Add a String value
 
 | Parameter | Description |
 | --- | --- |
-| `key` | [string](../core/string); required  A String key |
-| `value` | [string](../core/string); required  A String value |
+| `key` | [string](/versions/8.0.1/rules/lib/core/string); required  A String key |
+| `value` | [string](/versions/8.0.1/rules/lib/core/string); required  A String value |
 
 ## add\_joined
 
@@ -36,10 +36,10 @@ Add depset of values
 
 | Parameter | Description |
 | --- | --- |
-| `key` | [string](../core/string); required  A String key |
-| `values` | [depset](../builtins/depset); required  The depset whose items will be joined. |
-| `join_with` | [string](../core/string); required  A delimiter string used to join together the strings obtained from applying `map_each`, in the same manner as [`string.join()`](../core/string#join). |
+| `key` | [string](/versions/8.0.1/rules/lib/core/string); required  A String key |
+| `values` | [depset](/versions/8.0.1/rules/lib/builtins/depset); required  The depset whose items will be joined. |
+| `join_with` | [string](/versions/8.0.1/rules/lib/core/string); required  A delimiter string used to join together the strings obtained from applying `map_each`, in the same manner as [`string.join()`](/versions/8.0.1/rules/lib/core/string#join). |
 | `map_each` | callable; required  A Starlark function accepting a single argument and returning either a string, `None`, or a list of strings. This function is applied to each item of the depset specified in the `values` parameter |
-| `uniquify` | [bool](../core/bool); default is `False`  If true, duplicate strings derived from `values` will be omitted. Only the first occurrence of each string will remain. Usually this feature is not needed because depsets already omit duplicates, but it can be useful if `map_each` emits the same string for multiple items. |
-| `format_joined` | [string](../core/string); or `None`; default is `None`  An optional format string pattern applied to the joined string. The format string must have exactly one '%s' placeholder. |
-| `allow_closure` | [bool](../core/bool); default is `False`  If true, allows the use of closures in function parameters like `map_each`. Usually this isn't necessary and it risks retaining large analysis-phase data structures into the execution phase. |
\ No newline at end of file
+| `uniquify` | [bool](/versions/8.0.1/rules/lib/core/bool); default is `False`  If true, duplicate strings derived from `values` will be omitted. Only the first occurrence of each string will remain. Usually this feature is not needed because depsets already omit duplicates, but it can be useful if `map_each` emits the same string for multiple items. |
+| `format_joined` | [string](/versions/8.0.1/rules/lib/core/string); or `None`; default is `None`  An optional format string pattern applied to the joined string. The format string must have exactly one '%s' placeholder. |
+| `allow_closure` | [bool](/versions/8.0.1/rules/lib/core/bool); default is `False`  If true, allows the use of closures in function parameters like `map_each`. Usually this isn't necessary and it risks retaining large analysis-phase data structures into the execution phase. |
\ No newline at end of file
diff --git a/versions/8.0.1/rules/lib/builtins/actions.mdx b/versions/8.0.1/rules/lib/builtins/actions.mdx
index 7dca4462..ef72a54c 100644
--- a/versions/8.0.1/rules/lib/builtins/actions.mdx
+++ b/versions/8.0.1/rules/lib/builtins/actions.mdx
@@ -2,7 +2,7 @@
 title: 'actions'
 ---
 
-Module providing functions to create actions. Access this module using [`ctx.actions`](../builtins/ctx#actions).
+Module providing functions to create actions. Access this module using [`ctx.actions`](/versions/8.0.1/rules/lib/builtins/ctx#actions).
 
 ## Members
 
@@ -32,14 +32,14 @@ Returns an Args object that can be used to build memory-efficient command lines.
 File actions.declare_directory(filename, *, sibling=None)
 ```
 
-Declares that the rule or aspect creates a directory with the given name, in the current package. You must create an action that generates the directory. The contents of the directory are not directly accessible from Starlark, but can be expanded in an action command with [`Args.add_all()`](../builtins/Args#add_all). Only regular files and directories can be in the expanded contents of a declare\_directory.
+Declares that the rule or aspect creates a directory with the given name, in the current package. You must create an action that generates the directory. The contents of the directory are not directly accessible from Starlark, but can be expanded in an action command with [`Args.add_all()`](/versions/8.0.1/rules/lib/builtins/Args#add_all). Only regular files and directories can be in the expanded contents of a declare\_directory.
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `filename` | [string](../core/string); required  If no 'sibling' provided, path of the new directory, relative to the current package. Otherwise a base name for a file ('sibling' defines a directory). |
-| `sibling` | [File](../builtins/File); or `None`; default is `None`  A file that lives in the same directory as the newly declared directory. The file must be in the current package. |
+| `filename` | [string](/versions/8.0.1/rules/lib/core/string); required  If no 'sibling' provided, path of the new directory, relative to the current package. Otherwise a base name for a file ('sibling' defines a directory). |
+| `sibling` | [File](/versions/8.0.1/rules/lib/builtins/File); or `None`; default is `None`  A file that lives in the same directory as the newly declared directory. The file must be in the current package. |
 
 ## declare\_file
 
@@ -51,14 +51,14 @@ Declares that the rule or aspect creates a file with the given filename. If `sib
 
 Remember that in addition to declaring a file, you must separately create an action that emits the file. Creating that action will require passing the returned `File` object to the action's construction function.
 
-Note that [predeclared output files](https://bazel.build/versions/8.0.1/extending/rules#files) do not need to be (and cannot be) declared using this function. You can obtain their `File` objects from [`ctx.outputs`](../builtins/ctx#outputs) instead. [See example of use](https://github.com/bazelbuild/examples/tree/main/rules/computed_dependencies/hash.bzl).
+Note that [predeclared output files](https://bazel.build/versions/8.0.1/extending/rules#files) do not need to be (and cannot be) declared using this function. You can obtain their `File` objects from [`ctx.outputs`](/versions/8.0.1/rules/lib/builtins/ctx#outputs) instead. [See example of use](https://github.com/bazelbuild/examples/tree/main/rules/computed_dependencies/hash.bzl).
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `filename` | [string](../core/string); required  If no 'sibling' provided, path of the new file, relative to the current package. Otherwise a base name for a file ('sibling' determines a directory). |
-| `sibling` | [File](../builtins/File); or `None`; default is `None`  A file that lives in the same directory as the newly created file. The file must be in the current package. |
+| `filename` | [string](/versions/8.0.1/rules/lib/core/string); required  If no 'sibling' provided, path of the new file, relative to the current package. Otherwise a base name for a file ('sibling' determines a directory). |
+| `sibling` | [File](/versions/8.0.1/rules/lib/builtins/File); or `None`; default is `None`  A file that lives in the same directory as the newly created file. The file must be in the current package. |
 
 ## declare\_symlink
 
@@ -72,8 +72,8 @@ Declares that the rule or aspect creates a symlink with the given name in the cu
 
 | Parameter | Description |
 | --- | --- |
-| `filename` | [string](../core/string); required  If no 'sibling' provided, path of the new symlink, relative to the current package. Otherwise a base name for a file ('sibling' defines a directory). |
-| `sibling` | [File](../builtins/File); or `None`; default is `None`  A file that lives in the same directory as the newly declared symlink. |
+| `filename` | [string](/versions/8.0.1/rules/lib/core/string); required  If no 'sibling' provided, path of the new symlink, relative to the current package. Otherwise a base name for a file ('sibling' defines a directory). |
+| `sibling` | [File](/versions/8.0.1/rules/lib/builtins/File); or `None`; default is `None`  A file that lives in the same directory as the newly declared symlink. |
 
 ## do\_nothing
 
@@ -87,8 +87,8 @@ Creates an empty action that neither executes a command nor produces any output,
 
 | Parameter | Description |
 | --- | --- |
-| `mnemonic` | [string](../core/string); required  A one-word description of the action, for example, CppCompile or GoLink. |
-| `inputs` | [sequence](../core/list) of [File](../builtins/File)s; or [depset](../builtins/depset); default is `[]`  List of the input files of the action. |
+| `mnemonic` | [string](/versions/8.0.1/rules/lib/core/string); required  A one-word description of the action, for example, CppCompile or GoLink. |
+| `inputs` | [sequence](/versions/8.0.1/rules/lib/core/list) of [File](/versions/8.0.1/rules/lib/builtins/File)s; or [depset](/versions/8.0.1/rules/lib/builtins/depset); default is `[]`  List of the input files of the action. |
 
 ## expand\_template
 
@@ -102,11 +102,11 @@ Creates a template expansion action. When the action is executed, it will genera
 
 | Parameter | Description |
 | --- | --- |
-| `template` | [File](../builtins/File); required  The template file, which is a UTF-8 encoded text file. |
-| `output` | [File](../builtins/File); required  The output file, which is a UTF-8 encoded text file. |
-| `substitutions` | [dict](../core/dict); default is `{}`  Substitutions to make when expanding the template. |
-| `is_executable` | [bool](../core/bool); default is `False`  Whether the output file should be executable. |
-| `computed_substitutions` | [TemplateDict](../builtins/TemplateDict); default is `unbound`  Substitutions to make when expanding the template. |
+| `template` | [File](/versions/8.0.1/rules/lib/builtins/File); required  The template file, which is a UTF-8 encoded text file. |
+| `output` | [File](/versions/8.0.1/rules/lib/builtins/File); required  The output file, which is a UTF-8 encoded text file. |
+| `substitutions` | [dict](/versions/8.0.1/rules/lib/core/dict); default is `{}`  Substitutions to make when expanding the template. |
+| `is_executable` | [bool](/versions/8.0.1/rules/lib/core/bool); default is `False`  Whether the output file should be executable. |
+| `computed_substitutions` | [TemplateDict](/versions/8.0.1/rules/lib/builtins/TemplateDict); default is `unbound`  Substitutions to make when expanding the template. |
 
 ## run
 
@@ -120,22 +120,22 @@ Creates an action that runs an executable. [See example of use](https://github.c
 
 | Parameter | Description |
 | --- | --- |
-| `outputs` | [sequence](../core/list) of [File](../builtins/File)s; required  List of the output files of the action. |
-| `inputs` | [sequence](../core/list) of [File](../builtins/File)s; or [depset](../builtins/depset); default is `[]`  List or depset of the input files of the action. |
-| `unused_inputs_list` | [File](../builtins/File); or `None`; default is `None`  File containing list of inputs unused by the action. The content of this file (generally one of the outputs of the action) corresponds to the list of input files that were not used during the whole action execution. Any change in those files must not affect in any way the outputs of the action. |
-| `executable` | [File](../builtins/File); or [string](../core/string); or [FilesToRunProvider](../providers/FilesToRunProvider); required  The executable file to be called by the action. |
-| `tools` | [sequence](../core/list); or [depset](../builtins/depset); default is `unbound`  List or depset of any tools needed by the action. Tools are inputs with additional runfiles that are automatically made available to the action. When a list is provided, it can be a heterogenous collection of Files, FilesToRunProvider instances, or depsets of Files. Files which are directly in the list and come from ctx.executable will have their runfiles automatically added. When a depset is provided, it must contain only Files. In both cases, files within depsets are not cross-referenced with ctx.executable for runfiles. |
-| `arguments` | [sequence](../core/list); default is `[]`  Command line arguments of the action. Must be a list of strings or [`actions.args()`](#args) objects. |
-| `mnemonic` | [string](../core/string); or `None`; default is `None`  A one-word description of the action, for example, CppCompile or GoLink. |
-| `progress_message` | [string](../core/string); or `None`; default is `None`  Progress message to show to the user during the build, for example, "Compiling foo.cc to create foo.o". The message may contain `%{label}`, `%{input}`, or `%{output}` patterns, which are substituted with label string, first input, or output's path, respectively. Prefer to use patterns instead of static strings, because the former are more efficient. |
-| `use_default_shell_env` | [bool](../core/bool); default is `False`  Whether the action should use the default shell environment, which consists of a few OS-dependent variables as well as variables set via [`--action_env`](/versions/8.0.1/reference/command-line-reference#flag--action_env). If both `use_default_shell_env` and `env` are set to `True`, values set in `env` will overwrite the default shell environment if [`--incompatible_merge_fixed_and_default_shell_env`](/versions/8.0.1/reference/command-line-reference#flag--incompatible_merge_fixed_and_default_shell_env) is enabled (default). If the flag is not enabled, `env` is ignored. |
-| `env` | [dict](../core/dict); or `None`; default is `None`  Sets the dictionary of environment variables. If both `use_default_shell_env` and `env` are set to `True`, values set in `env` will overwrite the default shell environment if [`--incompatible_merge_fixed_and_default_shell_env`](/versions/8.0.1/reference/command-line-reference#flag--incompatible_merge_fixed_and_default_shell_env) is enabled (default). If the flag is not enabled, `env` is ignored. |
-| `execution_requirements` | [dict](../core/dict); or `None`; default is `None`  Information for scheduling the action. See [tags](/versions/8.0.1/reference/be/common-definitions#common.tags) for useful keys. |
-| `input_manifests` | [sequence](../core/list); or `None`; default is `None`  Legacy argument. Ignored. |
-| `exec_group` | [string](../core/string); or `None`; default is `None`  Runs the action on the given exec group's execution platform. If none, uses the target's default execution platform. |
-| `shadowed_action` | [Action](../builtins/Action); default is `None`  Runs the action using the given shadowed action's inputs and environment added to the action's inputs list and environment. The action environment can overwrite any of the shadowed action's environment variables. If none, uses only the action's inputs and given environment. |
+| `outputs` | [sequence](/versions/8.0.1/rules/lib/core/list) of [File](/versions/8.0.1/rules/lib/builtins/File)s; required  List of the output files of the action. |
+| `inputs` | [sequence](/versions/8.0.1/rules/lib/core/list) of [File](/versions/8.0.1/rules/lib/builtins/File)s; or [depset](/versions/8.0.1/rules/lib/builtins/depset); default is `[]`  List or depset of the input files of the action. |
+| `unused_inputs_list` | [File](/versions/8.0.1/rules/lib/builtins/File); or `None`; default is `None`  File containing list of inputs unused by the action. The content of this file (generally one of the outputs of the action) corresponds to the list of input files that were not used during the whole action execution. Any change in those files must not affect in any way the outputs of the action. |
+| `executable` | [File](/versions/8.0.1/rules/lib/builtins/File); or [string](/versions/8.0.1/rules/lib/core/string); or [FilesToRunProvider](/versions/8.0.1/rules/lib/providers/FilesToRunProvider); required  The executable file to be called by the action. |
+| `tools` | [sequence](/versions/8.0.1/rules/lib/core/list); or [depset](/versions/8.0.1/rules/lib/builtins/depset); default is `unbound`  List or depset of any tools needed by the action. Tools are inputs with additional runfiles that are automatically made available to the action. When a list is provided, it can be a heterogenous collection of Files, FilesToRunProvider instances, or depsets of Files. Files which are directly in the list and come from ctx.executable will have their runfiles automatically added. When a depset is provided, it must contain only Files. In both cases, files within depsets are not cross-referenced with ctx.executable for runfiles. |
+| `arguments` | [sequence](/versions/8.0.1/rules/lib/core/list); default is `[]`  Command line arguments of the action. Must be a list of strings or [`actions.args()`](#args) objects. |
+| `mnemonic` | [string](/versions/8.0.1/rules/lib/core/string); or `None`; default is `None`  A one-word description of the action, for example, CppCompile or GoLink. |
+| `progress_message` | [string](/versions/8.0.1/rules/lib/core/string); or `None`; default is `None`  Progress message to show to the user during the build, for example, "Compiling foo.cc to create foo.o". The message may contain `%{label}`, `%{input}`, or `%{output}` patterns, which are substituted with label string, first input, or output's path, respectively. Prefer to use patterns instead of static strings, because the former are more efficient. |
+| `use_default_shell_env` | [bool](/versions/8.0.1/rules/lib/core/bool); default is `False`  Whether the action should use the default shell environment, which consists of a few OS-dependent variables as well as variables set via [`--action_env`](/versions/8.0.1/reference/command-line-reference#flag--action_env). If both `use_default_shell_env` and `env` are set to `True`, values set in `env` will overwrite the default shell environment if [`--incompatible_merge_fixed_and_default_shell_env`](/versions/8.0.1/reference/command-line-reference#flag--incompatible_merge_fixed_and_default_shell_env) is enabled (default). If the flag is not enabled, `env` is ignored. |
+| `env` | [dict](/versions/8.0.1/rules/lib/core/dict); or `None`; default is `None`  Sets the dictionary of environment variables. If both `use_default_shell_env` and `env` are set to `True`, values set in `env` will overwrite the default shell environment if [`--incompatible_merge_fixed_and_default_shell_env`](/versions/8.0.1/reference/command-line-reference#flag--incompatible_merge_fixed_and_default_shell_env) is enabled (default). If the flag is not enabled, `env` is ignored. |
+| `execution_requirements` | [dict](/versions/8.0.1/rules/lib/core/dict); or `None`; default is `None`  Information for scheduling the action. See [tags](/versions/8.0.1/reference/be/common-definitions#common.tags) for useful keys. |
+| `input_manifests` | [sequence](/versions/8.0.1/rules/lib/core/list); or `None`; default is `None`  Legacy argument. Ignored. |
+| `exec_group` | [string](/versions/8.0.1/rules/lib/core/string); or `None`; default is `None`  Runs the action on the given exec group's execution platform. If none, uses the target's default execution platform. |
+| `shadowed_action` | [Action](/versions/8.0.1/rules/lib/builtins/Action); default is `None`  Runs the action using the given shadowed action's inputs and environment added to the action's inputs list and environment. The action environment can overwrite any of the shadowed action's environment variables. If none, uses only the action's inputs and given environment. |
 | `resource_set` | callable; or `None`; default is `None`  A callback function that returns a resource set dictionary, used to estimate resource usage at execution time if this action is run locally. The function accepts two positional arguments: a string representing an OS name (e.g. "osx"), and an integer representing the number of inputs to the action. The returned dictionary may contain the following entries, each of which may be a float or an int:  * "cpu": number of CPUs; default 1* "memory": in MB; default 250* "local\_test": number of local tests; default 1   If this parameter is set to `None` or if `--experimental_action_resource_set` is false, the default values are used. The callback must be top-level (lambda and nested functions aren't allowed). |
-| `toolchain` | [Label](../builtins/Label); or [string](../core/string); or `None`; default is `unbound`  Toolchain type of the executable or tools used in this action.  If executable and tools are not coming from a toolchain, set this parameter to `None`.  If executable and tools are coming from a toolchain, toolchain type must be set so that the action executes on the correct execution platform.  Note that the rule which creates this action needs to define this toolchain inside its 'rule()' function.  When `toolchain` and `exec\_group` parameters are both set, `exec\_group` will be used. An error is raised in case the `exec\_group` doesn't specify the same toolchain. |
+| `toolchain` | [Label](/versions/8.0.1/rules/lib/builtins/Label); or [string](/versions/8.0.1/rules/lib/core/string); or `None`; default is `unbound`  Toolchain type of the executable or tools used in this action.  If executable and tools are not coming from a toolchain, set this parameter to `None`.  If executable and tools are coming from a toolchain, toolchain type must be set so that the action executes on the correct execution platform.  Note that the rule which creates this action needs to define this toolchain inside its 'rule()' function.  When `toolchain` and `exec\_group` parameters are both set, `exec\_group` will be used. An error is raised in case the `exec\_group` doesn't specify the same toolchain. |
 
 ## run\_shell
 
@@ -149,21 +149,21 @@ Creates an action that runs a shell command. [See example of use](https://github
 
 | Parameter | Description |
 | --- | --- |
-| `outputs` | [sequence](../core/list) of [File](../builtins/File)s; required  List of the output files of the action. |
-| `inputs` | [sequence](../core/list) of [File](../builtins/File)s; or [depset](../builtins/depset); default is `[]`  List or depset of the input files of the action. |
-| `tools` | [sequence](../core/list) of [File](../builtins/File)s; or [depset](../builtins/depset); default is `unbound`  List or depset of any tools needed by the action. Tools are inputs with additional runfiles that are automatically made available to the action. The list can contain Files or FilesToRunProvider instances. |
-| `arguments` | [sequence](../core/list); default is `[]`  Command line arguments of the action. Must be a list of strings or [`actions.args()`](#args) objects. Bazel passes the elements in this attribute as arguments to the command.The command can access these arguments using shell variable substitutions such as `$1`, `$2`, etc. Note that since Args objects are flattened before indexing, if there is an Args object of unknown size then all subsequent strings will be at unpredictable indices. It may be useful to use `$@` (to retrieve all arguments) in conjunction with Args objects of indeterminate size. In the case where `command` is a list of strings, this parameter may not be used. |
-| `mnemonic` | [string](../core/string); or `None`; default is `None`  A one-word description of the action, for example, CppCompile or GoLink. |
-| `command` | [string](../core/string); or [sequence](../core/list) of [string](../core/string)s; required  Shell command to execute. This may either be a string (preferred) or a sequence of strings **(deprecated)**. If `command` is a string, then it is executed as if by `sh -c  "" ` -- that is, the elements in `arguments` are made available to the command as `$1`, `$2` (or `%1`, `%2` if using Windows batch), etc. If `arguments` contains any [`actions.args()`](#args) objects, their contents are appended one by one to the command line, so `$`*i* can refer to individual strings within an Args object. Note that if an Args object of unknown size is passed as part of `arguments`, then the strings will be at unknown indices; in this case the `$@` shell substitution (retrieve all arguments) may be useful. **(Deprecated)** If `command` is a sequence of strings, the first item is the executable to run and the remaining items are its arguments. If this form is used, the `arguments` parameter must not be supplied. *Note that this form is deprecated and will soon be removed. It is disabled with `--incompatible\_run\_shell\_command\_string`. Use this flag to verify your code is compatible.*  Bazel uses the same shell to execute the command as it does for genrules. |
-| `progress_message` | [string](../core/string); or `None`; default is `None`  Progress message to show to the user during the build, for example, "Compiling foo.cc to create foo.o". The message may contain `%{label}`, `%{input}`, or `%{output}` patterns, which are substituted with label string, first input, or output's path, respectively. Prefer to use patterns instead of static strings, because the former are more efficient. |
-| `use_default_shell_env` | [bool](../core/bool); default is `False`  Whether the action should use the default shell environment, which consists of a few OS-dependent variables as well as variables set via [`--action_env`](/versions/8.0.1/reference/command-line-reference#flag--action_env). If both `use_default_shell_env` and `env` are set to `True`, values set in `env` will overwrite the default shell environment if [`--incompatible_merge_fixed_and_default_shell_env`](/versions/8.0.1/reference/command-line-reference#flag--incompatible_merge_fixed_and_default_shell_env) is enabled (default). If the flag is not enabled, `env` is ignored. |
-| `env` | [dict](../core/dict); or `None`; default is `None`  Sets the dictionary of environment variables. If both `use_default_shell_env` and `env` are set to `True`, values set in `env` will overwrite the default shell environment if [`--incompatible_merge_fixed_and_default_shell_env`](/versions/8.0.1/reference/command-line-reference#flag--incompatible_merge_fixed_and_default_shell_env) is enabled (default). If the flag is not enabled, `env` is ignored. |
-| `execution_requirements` | [dict](../core/dict); or `None`; default is `None`  Information for scheduling the action. See [tags](/versions/8.0.1/reference/be/common-definitions#common.tags) for useful keys. |
-| `input_manifests` | [sequence](../core/list); or `None`; default is `None`  Legacy argument. Ignored. |
-| `exec_group` | [string](../core/string); or `None`; default is `None`  Runs the action on the given exec group's execution platform. If none, uses the target's default execution platform. |
-| `shadowed_action` | [Action](../builtins/Action); default is `None`  Runs the action using the given shadowed action's discovered inputs added to the action's inputs list. If none, uses only the action's inputs. |
+| `outputs` | [sequence](/versions/8.0.1/rules/lib/core/list) of [File](/versions/8.0.1/rules/lib/builtins/File)s; required  List of the output files of the action. |
+| `inputs` | [sequence](/versions/8.0.1/rules/lib/core/list) of [File](/versions/8.0.1/rules/lib/builtins/File)s; or [depset](/versions/8.0.1/rules/lib/builtins/depset); default is `[]`  List or depset of the input files of the action. |
+| `tools` | [sequence](/versions/8.0.1/rules/lib/core/list) of [File](/versions/8.0.1/rules/lib/builtins/File)s; or [depset](/versions/8.0.1/rules/lib/builtins/depset); default is `unbound`  List or depset of any tools needed by the action. Tools are inputs with additional runfiles that are automatically made available to the action. The list can contain Files or FilesToRunProvider instances. |
+| `arguments` | [sequence](/versions/8.0.1/rules/lib/core/list); default is `[]`  Command line arguments of the action. Must be a list of strings or [`actions.args()`](#args) objects. Bazel passes the elements in this attribute as arguments to the command.The command can access these arguments using shell variable substitutions such as `$1`, `$2`, etc. Note that since Args objects are flattened before indexing, if there is an Args object of unknown size then all subsequent strings will be at unpredictable indices. It may be useful to use `$@` (to retrieve all arguments) in conjunction with Args objects of indeterminate size. In the case where `command` is a list of strings, this parameter may not be used. |
+| `mnemonic` | [string](/versions/8.0.1/rules/lib/core/string); or `None`; default is `None`  A one-word description of the action, for example, CppCompile or GoLink. |
+| `command` | [string](/versions/8.0.1/rules/lib/core/string); or [sequence](/versions/8.0.1/rules/lib/core/list) of [string](/versions/8.0.1/rules/lib/core/string)s; required  Shell command to execute. This may either be a string (preferred) or a sequence of strings **(deprecated)**. If `command` is a string, then it is executed as if by `sh -c  "" ` -- that is, the elements in `arguments` are made available to the command as `$1`, `$2` (or `%1`, `%2` if using Windows batch), etc. If `arguments` contains any [`actions.args()`](#args) objects, their contents are appended one by one to the command line, so `$`*i* can refer to individual strings within an Args object. Note that if an Args object of unknown size is passed as part of `arguments`, then the strings will be at unknown indices; in this case the `$@` shell substitution (retrieve all arguments) may be useful. **(Deprecated)** If `command` is a sequence of strings, the first item is the executable to run and the remaining items are its arguments. If this form is used, the `arguments` parameter must not be supplied. *Note that this form is deprecated and will soon be removed. It is disabled with `--incompatible\_run\_shell\_command\_string`. Use this flag to verify your code is compatible.*  Bazel uses the same shell to execute the command as it does for genrules. |
+| `progress_message` | [string](/versions/8.0.1/rules/lib/core/string); or `None`; default is `None`  Progress message to show to the user during the build, for example, "Compiling foo.cc to create foo.o". The message may contain `%{label}`, `%{input}`, or `%{output}` patterns, which are substituted with label string, first input, or output's path, respectively. Prefer to use patterns instead of static strings, because the former are more efficient. |
+| `use_default_shell_env` | [bool](/versions/8.0.1/rules/lib/core/bool); default is `False`  Whether the action should use the default shell environment, which consists of a few OS-dependent variables as well as variables set via [`--action_env`](/versions/8.0.1/reference/command-line-reference#flag--action_env). If both `use_default_shell_env` and `env` are set to `True`, values set in `env` will overwrite the default shell environment if [`--incompatible_merge_fixed_and_default_shell_env`](/versions/8.0.1/reference/command-line-reference#flag--incompatible_merge_fixed_and_default_shell_env) is enabled (default). If the flag is not enabled, `env` is ignored. |
+| `env` | [dict](/versions/8.0.1/rules/lib/core/dict); or `None`; default is `None`  Sets the dictionary of environment variables. If both `use_default_shell_env` and `env` are set to `True`, values set in `env` will overwrite the default shell environment if [`--incompatible_merge_fixed_and_default_shell_env`](/versions/8.0.1/reference/command-line-reference#flag--incompatible_merge_fixed_and_default_shell_env) is enabled (default). If the flag is not enabled, `env` is ignored. |
+| `execution_requirements` | [dict](/versions/8.0.1/rules/lib/core/dict); or `None`; default is `None`  Information for scheduling the action. See [tags](/versions/8.0.1/reference/be/common-definitions#common.tags) for useful keys. |
+| `input_manifests` | [sequence](/versions/8.0.1/rules/lib/core/list); or `None`; default is `None`  Legacy argument. Ignored. |
+| `exec_group` | [string](/versions/8.0.1/rules/lib/core/string); or `None`; default is `None`  Runs the action on the given exec group's execution platform. If none, uses the target's default execution platform. |
+| `shadowed_action` | [Action](/versions/8.0.1/rules/lib/builtins/Action); default is `None`  Runs the action using the given shadowed action's discovered inputs added to the action's inputs list. If none, uses only the action's inputs. |
 | `resource_set` | callable; or `None`; default is `None`  A callback function for estimating resource usage if run locally. See[`ctx.actions.run()`](#run.resource_set). |
-| `toolchain` | [Label](../builtins/Label); or [string](../core/string); or `None`; default is `unbound`  Toolchain type of the executable or tools used in this action.  If executable and tools are not coming from a toolchain, set this parameter to `None`.  If executable and tools are coming from a toolchain, toolchain type must be set so that the action executes on the correct execution platform.  Note that the rule which creates this action needs to define this toolchain inside its 'rule()' function.  When `toolchain` and `exec\_group` parameters are both set, `exec\_group` will be used. An error is raised in case the `exec\_group` doesn't specify the same toolchain. |
+| `toolchain` | [Label](/versions/8.0.1/rules/lib/builtins/Label); or [string](/versions/8.0.1/rules/lib/core/string); or `None`; default is `unbound`  Toolchain type of the executable or tools used in this action.  If executable and tools are not coming from a toolchain, set this parameter to `None`.  If executable and tools are coming from a toolchain, toolchain type must be set so that the action executes on the correct execution platform.  Note that the rule which creates this action needs to define this toolchain inside its 'rule()' function.  When `toolchain` and `exec\_group` parameters are both set, `exec\_group` will be used. An error is raised in case the `exec\_group` doesn't specify the same toolchain. |
 
 ## symlink
 
@@ -183,11 +183,11 @@ Otherwise, when you use `target_path`, declare `output` with [`declare_symlink()
 
 | Parameter | Description |
 | --- | --- |
-| `output` | [File](../builtins/File); required  The output of this action. |
-| `target_file` | [File](../builtins/File); or `None`; default is `None`  The File that the output symlink will point to. |
-| `target_path` | [string](../core/string); or `None`; default is `None`  The exact path that the output symlink will point to. No normalization or other processing is applied. |
-| `is_executable` | [bool](../core/bool); default is `False`  May only be used with `target_file`, not `target_path`. If true, when the action is executed, the `target_file`'s path is checked to confirm that it is executable, and an error is reported if it is not. Setting `is_executable` to False does not mean the target is not executable, just that no verification is done. This feature does not make sense for `target_path` because dangling symlinks might not exist at build time. |
-| `progress_message` | [string](../core/string); or `None`; default is `None`  Progress message to show to the user during the build. |
+| `output` | [File](/versions/8.0.1/rules/lib/builtins/File); required  The output of this action. |
+| `target_file` | [File](/versions/8.0.1/rules/lib/builtins/File); or `None`; default is `None`  The File that the output symlink will point to. |
+| `target_path` | [string](/versions/8.0.1/rules/lib/core/string); or `None`; default is `None`  The exact path that the output symlink will point to. No normalization or other processing is applied. |
+| `is_executable` | [bool](/versions/8.0.1/rules/lib/core/bool); default is `False`  May only be used with `target_file`, not `target_path`. If true, when the action is executed, the `target_file`'s path is checked to confirm that it is executable, and an error is reported if it is not. Setting `is_executable` to False does not mean the target is not executable, just that no verification is done. This feature does not make sense for `target_path` because dangling symlinks might not exist at build time. |
+| `progress_message` | [string](/versions/8.0.1/rules/lib/core/string); or `None`; default is `None`  Progress message to show to the user during the build. |
 
 ## template\_dict
 
@@ -209,6 +209,6 @@ Creates a file write action. When the action is executed, it will write the give
 
 | Parameter | Description |
 | --- | --- |
-| `output` | [File](../builtins/File); required  The output file. |
-| `content` | [string](../core/string); or [Args](../builtins/Args); required  the contents of the file. May be a either a string or an [`actions.args()`](#args) object. |
-| `is_executable` | [bool](../core/bool); default is `False`  Whether the output file should be executable. |
\ No newline at end of file
+| `output` | [File](/versions/8.0.1/rules/lib/builtins/File); required  The output file. |
+| `content` | [string](/versions/8.0.1/rules/lib/core/string); or [Args](/versions/8.0.1/rules/lib/builtins/Args); required  the contents of the file. May be a either a string or an [`actions.args()`](#args) object. |
+| `is_executable` | [bool](/versions/8.0.1/rules/lib/core/bool); default is `False`  Whether the output file should be executable. |
\ No newline at end of file
diff --git a/versions/8.0.1/rules/lib/builtins/apple_platform.mdx b/versions/8.0.1/rules/lib/builtins/apple_platform.mdx
index ba2fc42e..2613449e 100644
--- a/versions/8.0.1/rules/lib/builtins/apple_platform.mdx
+++ b/versions/8.0.1/rules/lib/builtins/apple_platform.mdx
@@ -4,7 +4,7 @@ title: 'apple\_platform'
 
 Corresponds to Xcode's notion of a platform as would be found in `Xcode.app/Contents/Developer/Platforms`. Each platform represents an Apple platform type (such as iOS or tvOS) combined with one or more related CPU architectures. For example, the iOS simulator platform supports `x86_64` and `i386` architectures.
 
-Specific instances of this type can be retrieved from the fields of the [apple\_common.platform](../toplevel/apple_common#platform) struct:
+Specific instances of this type can be retrieved from the fields of the [apple\_common.platform](/versions/8.0.1/rules/lib/toplevel/apple_common#platform) struct:
 
 * `apple_common.platform.ios_device`
 * `apple_common.platform.ios_simulator`
@@ -14,7 +14,7 @@ Specific instances of this type can be retrieved from the fields of the [apple\_
 * `apple_common.platform.watchos_device`
 * `apple_common.platform.watchos_simulator`
 
-More commonly, however, the [apple](../fragments/apple) configuration fragment has fields/methods that allow rules to determine the platform for which a target is being built.
+More commonly, however, the [apple](/versions/8.0.1/rules/lib/fragments/apple) configuration fragment has fields/methods that allow rules to determine the platform for which a target is being built.
 
 Example:
 
diff --git a/versions/8.0.1/rules/lib/builtins/configuration.mdx b/versions/8.0.1/rules/lib/builtins/configuration.mdx
index c7134150..c25c9861 100644
--- a/versions/8.0.1/rules/lib/builtins/configuration.mdx
+++ b/versions/8.0.1/rules/lib/builtins/configuration.mdx
@@ -17,7 +17,7 @@ This object holds information about the environment in which the build is runnin
 bool configuration.coverage_enabled
 ```
 
-A boolean that tells whether code coverage is enabled for this run. Note that this does not compute whether a specific rule should be instrumented for code coverage data collection. For that, see the [`ctx.coverage_instrumented`](../builtins/ctx#coverage_instrumented) function.
+A boolean that tells whether code coverage is enabled for this run. Note that this does not compute whether a specific rule should be instrumented for code coverage data collection. For that, see the [`ctx.coverage_instrumented`](/versions/8.0.1/rules/lib/builtins/ctx#coverage_instrumented) function.
 
 ## default\_shell\_env
 
diff --git a/versions/8.0.1/rules/lib/builtins/ctx.mdx b/versions/8.0.1/rules/lib/builtins/ctx.mdx
index 92e9c65f..0030ada4 100644
--- a/versions/8.0.1/rules/lib/builtins/ctx.mdx
+++ b/versions/8.0.1/rules/lib/builtins/ctx.mdx
@@ -66,7 +66,7 @@ A list of ids for all aspects applied to the target. Only available in aspect im
 struct ctx.attr
 ```
 
-A struct to access the values of the [attributes](https://bazel.build/versions/8.0.1/extending/rules#attributes). The values are provided by the user (if not, a default value is used). The attributes of the struct and the types of their values correspond to the keys and values of the [`attrs` dict](../globals/bzl#rule.attrs) provided to the [`rule` function](../globals/bzl#rule). [See example of use](https://github.com/bazelbuild/examples/blob/main/rules/attributes/printer.bzl).
+A struct to access the values of the [attributes](https://bazel.build/versions/8.0.1/extending/rules#attributes). The values are provided by the user (if not, a default value is used). The attributes of the struct and the types of their values correspond to the keys and values of the [`attrs` dict](/versions/8.0.1/rules/lib/globals/bzl#rule.attrs) provided to the [`rule` function](/versions/8.0.1/rules/lib/globals/bzl#rule). [See example of use](https://github.com/bazelbuild/examples/blob/main/rules/attributes/printer.bzl).
 
 ## bin\_dir
 
@@ -98,7 +98,7 @@ Value of the build setting represented by the current target. If this isn't the
 configuration ctx.configuration
 ```
 
-The default configuration. See the [configuration](../builtins/configuration) type for more details.
+The default configuration. See the [configuration](/versions/8.0.1/rules/lib/builtins/configuration) type for more details.
 
 ## coverage\_instrumented
 
@@ -106,13 +106,13 @@ The default configuration. See the [configuration](../builtins/configuration) ty
 bool ctx.coverage_instrumented(target=None)
 ```
 
-Returns whether code coverage instrumentation should be generated when performing compilation actions for this rule or, if `target` is provided, the rule specified by that Target. (If a non-rule or a Starlark rule Target is provided, this returns False.) Checks if the sources of the current rule (if no Target is provided) or the sources of Target should be instrumented based on the --instrumentation\_filter and --instrument\_test\_targets config settings. This differs from `coverage_enabled` in the [configuration](../builtins/configuration), which notes whether coverage data collection is enabled for the entire run, but not whether a specific target should be instrumented.
+Returns whether code coverage instrumentation should be generated when performing compilation actions for this rule or, if `target` is provided, the rule specified by that Target. (If a non-rule or a Starlark rule Target is provided, this returns False.) Checks if the sources of the current rule (if no Target is provided) or the sources of Target should be instrumented based on the --instrumentation\_filter and --instrument\_test\_targets config settings. This differs from `coverage_enabled` in the [configuration](/versions/8.0.1/rules/lib/builtins/configuration), which notes whether coverage data collection is enabled for the entire run, but not whether a specific target should be instrumented.
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `target` | [Target](../builtins/Target); or `None`; default is `None`  A Target specifying a rule. If not provided, defaults to the current rule. |
+| `target` | [Target](/versions/8.0.1/rules/lib/builtins/Target); or `None`; default is `None`  A Target specifying a rule. If not provided, defaults to the current rule. |
 
 ## created\_actions
 
@@ -120,7 +120,7 @@ Returns whether code coverage instrumentation should be generated when performin
 StarlarkValue ctx.created_actions()
 ```
 
-For rules with [\_skylark\_testable](../globals/bzl#rule._skylark_testable) set to `True`, this returns an `Actions` provider representing all actions created so far for the current rule. For all other rules, returns `None`. Note that the provider is not updated when subsequent actions are created, so you will have to call this function again if you wish to inspect them.
+For rules with [\_skylark\_testable](/versions/8.0.1/rules/lib/globals/bzl#rule._skylark_testable) set to `True`, this returns an `Actions` provider representing all actions created so far for the current rule. For all other rules, returns `None`. Note that the provider is not updated when subsequent actions are created, so you will have to call this function again if you wish to inspect them.
 
 This is intended to help write tests for rule-implementation helper functions, which may take in a `ctx` object and create actions on it.
 
@@ -146,7 +146,7 @@ A collection of the execution groups available for this rule, indexed by their n
 struct ctx.executable
 ```
 
-A `struct` containing executable files defined in [label type attributes](../toplevel/attr#label) marked as [`executable=True`](../toplevel/attr#label.executable). The struct fields correspond to the attribute names. Each value in the struct is either a [`File`](../builtins/File) or `None`. If an optional attribute is not specified in the rule then the corresponding struct value is `None`. If a label type is not marked as `executable=True`, no corresponding struct field is generated. [See example of use](https://github.com/bazelbuild/examples/blob/main/rules/actions_run/execute.bzl).
+A `struct` containing executable files defined in [label type attributes](/versions/8.0.1/rules/lib/toplevel/attr#label) marked as [`executable=True`](/versions/8.0.1/rules/lib/toplevel/attr#label.executable). The struct fields correspond to the attribute names. Each value in the struct is either a [`File`](/versions/8.0.1/rules/lib/builtins/File) or `None`. If an optional attribute is not specified in the rule then the corresponding struct value is `None`. If a label type is not marked as `executable=True`, no corresponding struct field is generated. [See example of use](https://github.com/bazelbuild/examples/blob/main/rules/actions_run/execute.bzl).
 
 ## expand\_location
 
@@ -164,8 +164,8 @@ This function is useful to let the user specify a command in a BUILD file (like
 
 | Parameter | Description |
 | --- | --- |
-| `input` | [string](../core/string); required  String to be expanded. |
-| `targets` | [sequence](../core/list) of [Target](../builtins/Target)s; default is `[]`  List of targets for additional lookup information. These are expanded as follows: A target with a single file in `DefaultInfo.files` expands to that file. Other targets expand to their `DefaultInfo.executable` file if set and if `--incompatible_locations_prefers_executable` is enabled, otherwise they expand to `DefaultInfo.files`. |
+| `input` | [string](/versions/8.0.1/rules/lib/core/string); required  String to be expanded. |
+| `targets` | [sequence](/versions/8.0.1/rules/lib/core/list) of [Target](/versions/8.0.1/rules/lib/builtins/Target)s; default is `[]`  List of targets for additional lookup information. These are expanded as follows: A target with a single file in `DefaultInfo.files` expands to that file. Other targets expand to their `DefaultInfo.executable` file if set and if `--incompatible_locations_prefers_executable` is enabled, otherwise they expand to `DefaultInfo.files`. |
 
 May return `None`.
 
@@ -175,7 +175,7 @@ May return `None`.
 string ctx.expand_make_variables(attribute_name, command, additional_substitutions)
 ```
 
-**Deprecated.** Use [ctx.var](../builtins/ctx#var) to access the variables instead.
+**Deprecated.** Use [ctx.var](/versions/8.0.1/rules/lib/builtins/ctx#var) to access the variables instead.
 Returns a string after expanding all references to "Make variables". The variables must have the following format: `$(VAR_NAME)`. Also, `$$VAR_NAME` expands to `$VAR_NAME`. Examples:
 
 ```
@@ -189,9 +189,9 @@ Additional variables may come from other places, such as configurations. Note th
 
 | Parameter | Description |
 | --- | --- |
-| `attribute_name` | [string](../core/string); required |
-| `command` | [string](../core/string); required  The expression to expand. It can contain references to "Make variables". |
-| `additional_substitutions` | [dict](../core/dict); required  Additional substitutions to make beyond the default make variables. |
+| `attribute_name` | [string](/versions/8.0.1/rules/lib/core/string); required |
+| `command` | [string](/versions/8.0.1/rules/lib/core/string); required  The expression to expand. It can contain references to "Make variables". |
+| `additional_substitutions` | [dict](/versions/8.0.1/rules/lib/core/dict); required  Additional substitutions to make beyond the default make variables. |
 
 ## features
 
@@ -207,7 +207,7 @@ The set of features that are explicitly enabled by the user for this rule. [See
 struct ctx.file
 ```
 
-A `struct` containing files defined in [label type attributes](../toplevel/attr#label) marked as [`allow_single_file`](../toplevel/attr#label.allow_single_file). The struct fields correspond to the attribute names. The struct value is always a [`File`](../builtins/File) or `None`. If an optional attribute is not specified in the rule then the corresponding struct value is `None`. If a label type is not marked as `allow_single_file`, no corresponding struct field is generated. It is a shortcut for:
+A `struct` containing files defined in [label type attributes](/versions/8.0.1/rules/lib/toplevel/attr#label) marked as [`allow_single_file`](/versions/8.0.1/rules/lib/toplevel/attr#label.allow_single_file). The struct fields correspond to the attribute names. The struct value is always a [`File`](/versions/8.0.1/rules/lib/builtins/File) or `None`. If an optional attribute is not specified in the rule then the corresponding struct value is `None`. If a label type is not marked as `allow_single_file`, no corresponding struct field is generated. It is a shortcut for:
 
 ```
 list(ctx.attr..files)[0]
@@ -221,7 +221,7 @@ In other words, use `file` to access the (singular) [default output](https://baz
 struct ctx.files
 ```
 
-A `struct` containing files defined in [label](../toplevel/attr#label) or [label list](../toplevel/attr#label_list) type attributes. The struct fields correspond to the attribute names. The struct values are `list` of [`File`](../builtins/File)s. It is a shortcut for:
+A `struct` containing files defined in [label](/versions/8.0.1/rules/lib/toplevel/attr#label) or [label list](/versions/8.0.1/rules/lib/toplevel/attr#label_list) type attributes. The struct fields correspond to the attribute names. The struct values are `list` of [`File`](/versions/8.0.1/rules/lib/builtins/File)s. It is a shortcut for:
 
 ```
 [f for t in ctx.attr. for f in t.files]
@@ -267,13 +267,13 @@ The label of the target currently being analyzed.
 structure ctx.outputs
 ```
 
-A pseudo-struct containing all the predeclared output files, represented by [`File`](../builtins/File) objects. See the [Rules page](https://bazel.build/versions/8.0.1/extending/rules#files) for more information and examples.
+A pseudo-struct containing all the predeclared output files, represented by [`File`](/versions/8.0.1/rules/lib/builtins/File) objects. See the [Rules page](https://bazel.build/versions/8.0.1/extending/rules#files) for more information and examples.
 
 This field does not exist on aspect contexts, since aspects do not have predeclared outputs.
 
 The fields of this object are defined as follows. It is an error if two outputs produce the same field name or have the same label.
 
-* If the rule declares an [`outputs`](../globals/bzl#rule.outputs) dict, then for every entry in the dict, there is a field whose name is the key and whose value is the corresponding `File`.* For every attribute of type [`attr.output`](../toplevel/attr#output) that the rule declares, there is a field whose name is the attribute's name. If the target specified a label for that attribute, then the field value is the corresponding `File`; otherwise the field value is `None`.* For every attribute of type [`attr.output_list`](../toplevel/attr#output_list) that the rule declares, there is a field whose name is the attribute's name. The field value is a list of `File` objects corresponding to the labels given for that attribute in the target, or an empty list if the attribute was not specified in the target.* **(Deprecated)** If the rule is marked [`executable`](../globals/bzl#rule.executable) or [`test`](../globals/bzl#rule.test), there is a field named `"executable"`, which is the default executable. It is recommended that instead of using this, you pass another file (either predeclared or not) to the `executable` arg of [`DefaultInfo`](../providers/DefaultInfo).
+* If the rule declares an [`outputs`](/versions/8.0.1/rules/lib/globals/bzl#rule.outputs) dict, then for every entry in the dict, there is a field whose name is the key and whose value is the corresponding `File`.* For every attribute of type [`attr.output`](/versions/8.0.1/rules/lib/toplevel/attr#output) that the rule declares, there is a field whose name is the attribute's name. If the target specified a label for that attribute, then the field value is the corresponding `File`; otherwise the field value is `None`.* For every attribute of type [`attr.output_list`](/versions/8.0.1/rules/lib/toplevel/attr#output_list) that the rule declares, there is a field whose name is the attribute's name. The field value is a list of `File` objects corresponding to the labels given for that attribute in the target, or an empty list if the attribute was not specified in the target.* **(Deprecated)** If the rule is marked [`executable`](/versions/8.0.1/rules/lib/globals/bzl#rule.executable) or [`test`](/versions/8.0.1/rules/lib/globals/bzl#rule.test), there is a field named `"executable"`, which is the default executable. It is recommended that instead of using this, you pass another file (either predeclared or not) to the `executable` arg of [`DefaultInfo`](/versions/8.0.1/rules/lib/providers/DefaultInfo).
 
 ## resolve\_command
 
@@ -288,13 +288,13 @@ tuple ctx.resolve_command(command='', attribute=None, expand_locations=False, ma
 
 | Parameter | Description |
 | --- | --- |
-| `command` | [string](../core/string); default is `''`  Command to resolve. |
-| `attribute` | [string](../core/string); or `None`; default is `None`  Name of the associated attribute for which to issue an error, or None. |
-| `expand_locations` | [bool](../core/bool); default is `False`  Shall we expand $(location) variables? See [ctx.expand\_location()](#expand_location) for more details. |
-| `make_variables` | [dict](../core/dict); or `None`; default is `None`  Make variables to expand, or None. |
-| `tools` | [sequence](../core/list) of [Target](../builtins/Target)s; default is `[]`  List of tools (list of targets). |
-| `label_dict` | [dict](../core/dict); default is `{}`  Dictionary of resolved labels and the corresponding list of Files (a dict of Label : list of Files). |
-| `execution_requirements` | [dict](../core/dict); default is `{}`  Information for scheduling the action to resolve this command. See [tags](/versions/8.0.1/reference/be/common-definitions#common.tags) for useful keys. |
+| `command` | [string](/versions/8.0.1/rules/lib/core/string); default is `''`  Command to resolve. |
+| `attribute` | [string](/versions/8.0.1/rules/lib/core/string); or `None`; default is `None`  Name of the associated attribute for which to issue an error, or None. |
+| `expand_locations` | [bool](/versions/8.0.1/rules/lib/core/bool); default is `False`  Shall we expand $(location) variables? See [ctx.expand\_location()](#expand_location) for more details. |
+| `make_variables` | [dict](/versions/8.0.1/rules/lib/core/dict); or `None`; default is `None`  Make variables to expand, or None. |
+| `tools` | [sequence](/versions/8.0.1/rules/lib/core/list) of [Target](/versions/8.0.1/rules/lib/builtins/Target)s; default is `[]`  List of tools (list of targets). |
+| `label_dict` | [dict](/versions/8.0.1/rules/lib/core/dict); default is `{}`  Dictionary of resolved labels and the corresponding list of Files (a dict of Label : list of Files). |
+| `execution_requirements` | [dict](/versions/8.0.1/rules/lib/core/dict); default is `{}`  Information for scheduling the action to resolve this command. See [tags](/versions/8.0.1/reference/be/common-definitions#common.tags) for useful keys. |
 
 ## resolve\_tools
 
@@ -310,7 +310,7 @@ In contrast to `ctx.resolve_command`, this method does not require that Bash be
 
 | Parameter | Description |
 | --- | --- |
-| `tools` | [sequence](../core/list) of [Target](../builtins/Target)s; default is `[]`  List of tools (list of targets). |
+| `tools` | [sequence](/versions/8.0.1/rules/lib/core/list) of [Target](/versions/8.0.1/rules/lib/builtins/Target)s; default is `[]`  List of tools (list of targets). |
 
 ## rule
 
@@ -332,12 +332,12 @@ Creates a runfiles object.
 
 | Parameter | Description |
 | --- | --- |
-| `files` | [sequence](../core/list) of [File](../builtins/File)s; default is `[]`  The list of files to be added to the runfiles. |
-| `transitive_files` | [depset](../builtins/depset) of [File](../builtins/File)s; or `None`; default is `None`  The (transitive) set of files to be added to the runfiles. The depset should use the `default` order (which, as the name implies, is the default). |
-| `collect_data` | [bool](../core/bool); default is `False`  **Use of this parameter is not recommended. See [runfiles guide](https://bazel.build/versions/8.0.1/extending/rules#runfiles)**. Whether to collect the data runfiles from the dependencies in srcs, data and deps attributes. |
-| `collect_default` | [bool](../core/bool); default is `False`  **Use of this parameter is not recommended. See [runfiles guide](https://bazel.build/versions/8.0.1/extending/rules#runfiles)**. Whether to collect the default runfiles from the dependencies in srcs, data and deps attributes. |
-| `symlinks` | [dict](../core/dict); or [depset](../builtins/depset) of [SymlinkEntry](../builtins/SymlinkEntry)s; default is `{}`  Either a SymlinkEntry depset or the map of symlinks to be added to the runfiles. Symlinks are always added under the main workspace's runfiles directory (e.g. `/_main/`, **not** the directory corresponding to the current target's repository. See [Runfiles symlinks](https://bazel.build/versions/8.0.1/extending/rules#runfiles_symlinks) in the rules guide. |
-| `root_symlinks` | [dict](../core/dict); or [depset](../builtins/depset) of [SymlinkEntry](../builtins/SymlinkEntry)s; default is `{}`  Either a SymlinkEntry depset or a map of symlinks to be added to the runfiles. See [Runfiles symlinks](https://bazel.build/versions/8.0.1/extending/rules#runfiles_symlinks) in the rules guide. |
+| `files` | [sequence](/versions/8.0.1/rules/lib/core/list) of [File](/versions/8.0.1/rules/lib/builtins/File)s; default is `[]`  The list of files to be added to the runfiles. |
+| `transitive_files` | [depset](/versions/8.0.1/rules/lib/builtins/depset) of [File](/versions/8.0.1/rules/lib/builtins/File)s; or `None`; default is `None`  The (transitive) set of files to be added to the runfiles. The depset should use the `default` order (which, as the name implies, is the default). |
+| `collect_data` | [bool](/versions/8.0.1/rules/lib/core/bool); default is `False`  **Use of this parameter is not recommended. See [runfiles guide](https://bazel.build/versions/8.0.1/extending/rules#runfiles)**. Whether to collect the data runfiles from the dependencies in srcs, data and deps attributes. |
+| `collect_default` | [bool](/versions/8.0.1/rules/lib/core/bool); default is `False`  **Use of this parameter is not recommended. See [runfiles guide](https://bazel.build/versions/8.0.1/extending/rules#runfiles)**. Whether to collect the default runfiles from the dependencies in srcs, data and deps attributes. |
+| `symlinks` | [dict](/versions/8.0.1/rules/lib/core/dict); or [depset](/versions/8.0.1/rules/lib/builtins/depset) of [SymlinkEntry](/versions/8.0.1/rules/lib/builtins/SymlinkEntry)s; default is `{}`  Either a SymlinkEntry depset or the map of symlinks to be added to the runfiles. Symlinks are always added under the main workspace's runfiles directory (e.g. `/_main/`, **not** the directory corresponding to the current target's repository. See [Runfiles symlinks](https://bazel.build/versions/8.0.1/extending/rules#runfiles_symlinks) in the rules guide. |
+| `root_symlinks` | [dict](/versions/8.0.1/rules/lib/core/dict); or [depset](/versions/8.0.1/rules/lib/builtins/depset) of [SymlinkEntry](/versions/8.0.1/rules/lib/builtins/SymlinkEntry)s; default is `{}`  Either a SymlinkEntry depset or a map of symlinks to be added to the runfiles. See [Runfiles symlinks](https://bazel.build/versions/8.0.1/extending/rules#runfiles_symlinks) in the rules guide. |
 
 ## split\_attr
 
@@ -367,7 +367,7 @@ Returns true if the given constraint value is part of the current target platfor
 
 | Parameter | Description |
 | --- | --- |
-| `constraintValue` | [ConstraintValueInfo](../providers/ConstraintValueInfo); required  The constraint value to check the target platform against. |
+| `constraintValue` | [ConstraintValueInfo](/versions/8.0.1/rules/lib/providers/ConstraintValueInfo); required  The constraint value to check the target platform against. |
 
 ## toolchains
 
diff --git a/versions/8.0.1/rules/lib/builtins/depset.mdx b/versions/8.0.1/rules/lib/builtins/depset.mdx
index c498c753..d6e28cae 100644
--- a/versions/8.0.1/rules/lib/builtins/depset.mdx
+++ b/versions/8.0.1/rules/lib/builtins/depset.mdx
@@ -6,7 +6,7 @@ A specialized data structure that supports efficient merge operations and has a
 
 The elements of a depset must be hashable and all of the same type (as defined by the built-in type(x) function), but depsets are not simply hash sets and do not support fast membership tests. If you need a general set datatype, you can simulate one using a dictionary where all keys map to `True`.
 
-Depsets are immutable. They should be created using their [constructor function](../globals/bzl#depset) and merged or augmented with other depsets via the `transitive` argument.
+Depsets are immutable. They should be created using their [constructor function](/versions/8.0.1/rules/lib/globals/bzl#depset) and merged or augmented with other depsets via the `transitive` argument.
 
 The `order` parameter determines the kind of traversal that is done to convert the depset to an iterable. There are four possible values:
 
diff --git a/versions/8.0.1/rules/lib/builtins/fragments.mdx b/versions/8.0.1/rules/lib/builtins/fragments.mdx
index 75c41d66..33a2fcaf 100644
--- a/versions/8.0.1/rules/lib/builtins/fragments.mdx
+++ b/versions/8.0.1/rules/lib/builtins/fragments.mdx
@@ -6,4 +6,4 @@ A collection of configuration fragments available in the current rule implementa
 
 Only configuration fragments which are declared in the rule definition may be accessed in this collection.
 
-See the [configuration fragment reference](../fragments) for a list of available fragments and the [rules documentation](https://bazel.build/versions/8.0.1/extending/rules#configuration_fragments) for how to use them.
\ No newline at end of file
+See the [configuration fragment reference](/versions/8.0.1/rules/lib/fragments) for a list of available fragments and the [rules documentation](https://bazel.build/versions/8.0.1/extending/rules#configuration_fragments) for how to use them.
\ No newline at end of file
diff --git a/versions/8.0.1/rules/lib/builtins/macro.mdx b/versions/8.0.1/rules/lib/builtins/macro.mdx
index 5fe46fb4..8d8a3e1e 100644
--- a/versions/8.0.1/rules/lib/builtins/macro.mdx
+++ b/versions/8.0.1/rules/lib/builtins/macro.mdx
@@ -3,7 +3,7 @@ title: 'macro'
 ---
 
 A callable Starlark value representing a symbolic macro; in other words, the return value of
-[`macro()`](../globals/bzl#macro). Invoking this value during package
+[`macro()`](/versions/8.0.1/rules/lib/globals/bzl#macro). Invoking this value during package
 construction time will instantiate the macro, and cause the macro's implementation function to be
 evaluated (in a separate context, different from the context in which the macro value was invoked),
 in most cases causing targets to be added to the package's target set. For more information, see
diff --git a/versions/8.0.1/rules/lib/builtins/module_ctx.mdx b/versions/8.0.1/rules/lib/builtins/module_ctx.mdx
index c8510bef..1fca83d1 100644
--- a/versions/8.0.1/rules/lib/builtins/module_ctx.mdx
+++ b/versions/8.0.1/rules/lib/builtins/module_ctx.mdx
@@ -35,16 +35,16 @@ Downloads a file to the output path for the provided url and returns a struct co
 
 | Parameter | Description |
 | --- | --- |
-| `url` | [string](../core/string); or Iterable of [string](../core/string)s; required  List of mirror URLs referencing the same file. |
-| `output` | [string](../core/string); or [Label](../builtins/Label); or [path](../builtins/path); default is `''`  path to the output file, relative to the repository directory. |
-| `sha256` | [string](../core/string); default is `''`  The expected SHA-256 hash of the file downloaded. This must match the SHA-256 hash of the file downloaded. It is a security risk to omit the SHA-256 as remote files can change. At best omitting this field will make your build non-hermetic. It is optional to make development easier but should be set before shipping. If provided, the repository cache will first be checked for a file with the given hash; a download will only be attempted if the file was not found in the cache. After a successful download, the file will be added to the cache. |
-| `executable` | [bool](../core/bool); default is `False`  Set the executable flag on the created file, false by default. |
-| `allow_fail` | [bool](../core/bool); default is `False`  If set, indicate the error in the return value instead of raising an error for failed downloads. |
-| `canonical_id` | [string](../core/string); default is `''`  If set, restrict cache hits to those cases where the file was added to the cache with the same canonical id. By default caching uses the checksum (`sha256` or `integrity`). |
-| `auth` | [dict](../core/dict); default is `{}`  An optional dict specifying authentication information for some of the URLs. |
-| `headers` | [dict](../core/dict); default is `{}`  An optional dict specifying http headers for all URLs. |
-| `integrity` | [string](../core/string); default is `''`  Expected checksum of the file downloaded, in Subresource Integrity format. This must match the checksum of the file downloaded. It is a security risk to omit the checksum as remote files can change. At best omitting this field will make your build non-hermetic. It is optional to make development easier but should be set before shipping. If provided, the repository cache will first be checked for a file with the given checksum; a download will only be attempted if the file was not found in the cache. After a successful download, the file will be added to the cache. |
-| `block` | [bool](../core/bool); default is `True`  If set to false, the call returns immediately and instead of the regular return value, it returns a token with one single method, wait(), which blocks until the download is finished and returns the usual return value or throws as usual. |
+| `url` | [string](/versions/8.0.1/rules/lib/core/string); or Iterable of [string](/versions/8.0.1/rules/lib/core/string)s; required  List of mirror URLs referencing the same file. |
+| `output` | [string](/versions/8.0.1/rules/lib/core/string); or [Label](/versions/8.0.1/rules/lib/builtins/Label); or [path](/versions/8.0.1/rules/lib/builtins/path); default is `''`  path to the output file, relative to the repository directory. |
+| `sha256` | [string](/versions/8.0.1/rules/lib/core/string); default is `''`  The expected SHA-256 hash of the file downloaded. This must match the SHA-256 hash of the file downloaded. It is a security risk to omit the SHA-256 as remote files can change. At best omitting this field will make your build non-hermetic. It is optional to make development easier but should be set before shipping. If provided, the repository cache will first be checked for a file with the given hash; a download will only be attempted if the file was not found in the cache. After a successful download, the file will be added to the cache. |
+| `executable` | [bool](/versions/8.0.1/rules/lib/core/bool); default is `False`  Set the executable flag on the created file, false by default. |
+| `allow_fail` | [bool](/versions/8.0.1/rules/lib/core/bool); default is `False`  If set, indicate the error in the return value instead of raising an error for failed downloads. |
+| `canonical_id` | [string](/versions/8.0.1/rules/lib/core/string); default is `''`  If set, restrict cache hits to those cases where the file was added to the cache with the same canonical id. By default caching uses the checksum (`sha256` or `integrity`). |
+| `auth` | [dict](/versions/8.0.1/rules/lib/core/dict); default is `{}`  An optional dict specifying authentication information for some of the URLs. |
+| `headers` | [dict](/versions/8.0.1/rules/lib/core/dict); default is `{}`  An optional dict specifying http headers for all URLs. |
+| `integrity` | [string](/versions/8.0.1/rules/lib/core/string); default is `''`  Expected checksum of the file downloaded, in Subresource Integrity format. This must match the checksum of the file downloaded. It is a security risk to omit the checksum as remote files can change. At best omitting this field will make your build non-hermetic. It is optional to make development easier but should be set before shipping. If provided, the repository cache will first be checked for a file with the given checksum; a download will only be attempted if the file was not found in the cache. After a successful download, the file will be added to the cache. |
+| `block` | [bool](/versions/8.0.1/rules/lib/core/bool); default is `True`  If set to false, the call returns immediately and instead of the regular return value, it returns a token with one single method, wait(), which blocks until the download is finished and returns the usual return value or throws as usual. |
 
 ## download\_and\_extract
 
@@ -58,17 +58,17 @@ Downloads a file to the output path for the provided url, extracts it, and retur
 
 | Parameter | Description |
 | --- | --- |
-| `url` | [string](../core/string); or Iterable of [string](../core/string)s; required  List of mirror URLs referencing the same file. |
-| `output` | [string](../core/string); or [Label](../builtins/Label); or [path](../builtins/path); default is `''`  Path to the directory where the archive will be unpacked, relative to the repository directory. |
-| `sha256` | [string](../core/string); default is `''`  The expected SHA-256 hash of the file downloaded. This must match the SHA-256 hash of the file downloaded. It is a security risk to omit the SHA-256 as remote files can change. At best omitting this field will make your build non-hermetic. It is optional to make development easier but should be set before shipping. If provided, the repository cache will first be checked for a file with the given hash; a download will only be attempted if the file was not found in the cache. After a successful download, the file will be added to the cache. |
-| `type` | [string](../core/string); default is `''`  The archive type of the downloaded file. By default, the archive type is determined from the file extension of the URL. If the file has no extension, you can explicitly specify either "zip", "jar", "war", "aar", "nupkg", "tar", "tar.gz", "tgz", "tar.xz", "txz", ".tar.zst", ".tzst", "tar.bz2", ".tbz", ".ar", or ".deb" here. |
-| `strip_prefix` | [string](../core/string); default is `''`  A directory prefix to strip from the extracted files. Many archives contain a top-level directory that contains all files in the archive. Instead of needing to specify this prefix over and over in the `build_file`, this field can be used to strip it from extracted files. For compatibility, this parameter may also be used under the deprecated name `stripPrefix`. |
-| `allow_fail` | [bool](../core/bool); default is `False`  If set, indicate the error in the return value instead of raising an error for failed downloads. |
-| `canonical_id` | [string](../core/string); default is `''`  If set, restrict cache hits to those cases where the file was added to the cache with the same canonical id. By default caching uses the checksum" (`sha256` or `integrity`). |
-| `auth` | [dict](../core/dict); default is `{}`  An optional dict specifying authentication information for some of the URLs. |
-| `headers` | [dict](../core/dict); default is `{}`  An optional dict specifying http headers for all URLs. |
-| `integrity` | [string](../core/string); default is `''`  Expected checksum of the file downloaded, in Subresource Integrity format. This must match the checksum of the file downloaded. It is a security risk to omit the checksum as remote files can change. At best omitting this field will make your build non-hermetic. It is optional to make development easier but should be set before shipping. If provided, the repository cache will first be checked for a file with the given checksum; a download will only be attempted if the file was not found in the cache. After a successful download, the file will be added to the cache. |
-| `rename_files` | [dict](../core/dict); default is `{}`  An optional dict specifying files to rename during the extraction. Archive entries with names exactly matching a key will be renamed to the value, prior to any directory prefix adjustment. This can be used to extract archives that contain non-Unicode filenames, or which have files that would extract to the same path on case-insensitive filesystems. |
+| `url` | [string](/versions/8.0.1/rules/lib/core/string); or Iterable of [string](/versions/8.0.1/rules/lib/core/string)s; required  List of mirror URLs referencing the same file. |
+| `output` | [string](/versions/8.0.1/rules/lib/core/string); or [Label](/versions/8.0.1/rules/lib/builtins/Label); or [path](/versions/8.0.1/rules/lib/builtins/path); default is `''`  Path to the directory where the archive will be unpacked, relative to the repository directory. |
+| `sha256` | [string](/versions/8.0.1/rules/lib/core/string); default is `''`  The expected SHA-256 hash of the file downloaded. This must match the SHA-256 hash of the file downloaded. It is a security risk to omit the SHA-256 as remote files can change. At best omitting this field will make your build non-hermetic. It is optional to make development easier but should be set before shipping. If provided, the repository cache will first be checked for a file with the given hash; a download will only be attempted if the file was not found in the cache. After a successful download, the file will be added to the cache. |
+| `type` | [string](/versions/8.0.1/rules/lib/core/string); default is `''`  The archive type of the downloaded file. By default, the archive type is determined from the file extension of the URL. If the file has no extension, you can explicitly specify either "zip", "jar", "war", "aar", "nupkg", "tar", "tar.gz", "tgz", "tar.xz", "txz", ".tar.zst", ".tzst", "tar.bz2", ".tbz", ".ar", or ".deb" here. |
+| `strip_prefix` | [string](/versions/8.0.1/rules/lib/core/string); default is `''`  A directory prefix to strip from the extracted files. Many archives contain a top-level directory that contains all files in the archive. Instead of needing to specify this prefix over and over in the `build_file`, this field can be used to strip it from extracted files. For compatibility, this parameter may also be used under the deprecated name `stripPrefix`. |
+| `allow_fail` | [bool](/versions/8.0.1/rules/lib/core/bool); default is `False`  If set, indicate the error in the return value instead of raising an error for failed downloads. |
+| `canonical_id` | [string](/versions/8.0.1/rules/lib/core/string); default is `''`  If set, restrict cache hits to those cases where the file was added to the cache with the same canonical id. By default caching uses the checksum" (`sha256` or `integrity`). |
+| `auth` | [dict](/versions/8.0.1/rules/lib/core/dict); default is `{}`  An optional dict specifying authentication information for some of the URLs. |
+| `headers` | [dict](/versions/8.0.1/rules/lib/core/dict); default is `{}`  An optional dict specifying http headers for all URLs. |
+| `integrity` | [string](/versions/8.0.1/rules/lib/core/string); default is `''`  Expected checksum of the file downloaded, in Subresource Integrity format. This must match the checksum of the file downloaded. It is a security risk to omit the checksum as remote files can change. At best omitting this field will make your build non-hermetic. It is optional to make development easier but should be set before shipping. If provided, the repository cache will first be checked for a file with the given checksum; a download will only be attempted if the file was not found in the cache. After a successful download, the file will be added to the cache. |
+| `rename_files` | [dict](/versions/8.0.1/rules/lib/core/dict); default is `{}`  An optional dict specifying files to rename during the extraction. Archive entries with names exactly matching a key will be renamed to the value, prior to any directory prefix adjustment. This can be used to extract archives that contain non-Unicode filenames, or which have files that would extract to the same path on case-insensitive filesystems. |
 
 ## execute
 
@@ -82,11 +82,11 @@ Executes the command given by the list of arguments. The execution time of the c
 
 | Parameter | Description |
 | --- | --- |
-| `arguments` | [sequence](../core/list); required  List of arguments, the first element should be the path to the program to execute. |
-| `timeout` | [int](../core/int); default is `600`  Maximum duration of the command in seconds (default is 600 seconds). |
-| `environment` | [dict](../core/dict); default is `{}`  Force some environment variables to be set to be passed to the process. The value can be `None` to remove the environment variable. |
-| `quiet` | [bool](../core/bool); default is `True`  If stdout and stderr should be printed to the terminal. |
-| `working_directory` | [string](../core/string); default is `""`  Working directory for command execution. Can be relative to the repository root or absolute. The default is the repository root. |
+| `arguments` | [sequence](/versions/8.0.1/rules/lib/core/list); required  List of arguments, the first element should be the path to the program to execute. |
+| `timeout` | [int](/versions/8.0.1/rules/lib/core/int); default is `600`  Maximum duration of the command in seconds (default is 600 seconds). |
+| `environment` | [dict](/versions/8.0.1/rules/lib/core/dict); default is `{}`  Force some environment variables to be set to be passed to the process. The value can be `None` to remove the environment variable. |
+| `quiet` | [bool](/versions/8.0.1/rules/lib/core/bool); default is `True`  If stdout and stderr should be printed to the terminal. |
+| `working_directory` | [string](/versions/8.0.1/rules/lib/core/string); default is `""`  Working directory for command execution. Can be relative to the repository root or absolute. The default is the repository root. |
 
 ## extension\_metadata
 
@@ -100,9 +100,9 @@ Constructs an opaque object that can be returned from the module extension's imp
 
 | Parameter | Description |
 | --- | --- |
-| `root_module_direct_deps` | [sequence](../core/list) of [string](../core/string)s; or [string](../core/string); or `None`; default is `None`  The names of the repositories that the extension considers to be direct dependencies of the root module. If the root module imports additional repositories or does not import all of these repositories via [`use_repo`](../globals/module#use_repo), Bazel will print a warning when the extension is evaluated, instructing the user to run `bazel mod tidy` to fix the `use_repo` calls automatically. If one of `root_module_direct_deps` and will print a warning and a fixup command when the extension is evaluated. If one of `root_module_direct_deps` and `root_module_direct_dev_deps` is specified, the other has to be as well. The lists specified by these two parameters must be disjoint. Exactly one of `root_module_direct_deps` and `root_module_direct_dev_deps` can be set to the special value `"all"`, which is treated as if a list with the names of all repositories generated by the extension was specified as the value. |
-| `root_module_direct_dev_deps` | [sequence](../core/list) of [string](../core/string)s; or [string](../core/string); or `None`; default is `None`  The names of the repositories that the extension considers to be direct dev dependencies of the root module. If the root module imports additional repositories or does not import all of these repositories via [`use_repo`](../globals/module#use_repo) on an extension proxy created with `use_extension(..., dev_dependency = True)`, Bazel will print a warning when the extension is evaluated, instructing the user to run `bazel mod tidy` to fix the `use_repo` calls automatically. If one of `root_module_direct_deps` and `root_module_direct_dev_deps` is specified, the other has to be as well. The lists specified by these two parameters must be disjoint. Exactly one of `root_module_direct_deps` and `root_module_direct_dev_deps` can be set to the special value `"all"`, which is treated as if a list with the names of all repositories generated by the extension was specified as the value. |
-| `reproducible` | [bool](../core/bool); default is `False`  States that this module extension ensures complete reproducibility, thereby it should not be stored in the lockfile. |
+| `root_module_direct_deps` | [sequence](/versions/8.0.1/rules/lib/core/list) of [string](/versions/8.0.1/rules/lib/core/string)s; or [string](/versions/8.0.1/rules/lib/core/string); or `None`; default is `None`  The names of the repositories that the extension considers to be direct dependencies of the root module. If the root module imports additional repositories or does not import all of these repositories via [`use_repo`](/versions/8.0.1/rules/lib/globals/module#use_repo), Bazel will print a warning when the extension is evaluated, instructing the user to run `bazel mod tidy` to fix the `use_repo` calls automatically. If one of `root_module_direct_deps` and will print a warning and a fixup command when the extension is evaluated. If one of `root_module_direct_deps` and `root_module_direct_dev_deps` is specified, the other has to be as well. The lists specified by these two parameters must be disjoint. Exactly one of `root_module_direct_deps` and `root_module_direct_dev_deps` can be set to the special value `"all"`, which is treated as if a list with the names of all repositories generated by the extension was specified as the value. |
+| `root_module_direct_dev_deps` | [sequence](/versions/8.0.1/rules/lib/core/list) of [string](/versions/8.0.1/rules/lib/core/string)s; or [string](/versions/8.0.1/rules/lib/core/string); or `None`; default is `None`  The names of the repositories that the extension considers to be direct dev dependencies of the root module. If the root module imports additional repositories or does not import all of these repositories via [`use_repo`](/versions/8.0.1/rules/lib/globals/module#use_repo) on an extension proxy created with `use_extension(..., dev_dependency = True)`, Bazel will print a warning when the extension is evaluated, instructing the user to run `bazel mod tidy` to fix the `use_repo` calls automatically. If one of `root_module_direct_deps` and `root_module_direct_dev_deps` is specified, the other has to be as well. The lists specified by these two parameters must be disjoint. Exactly one of `root_module_direct_deps` and `root_module_direct_dev_deps` can be set to the special value `"all"`, which is treated as if a list with the names of all repositories generated by the extension was specified as the value. |
+| `reproducible` | [bool](/versions/8.0.1/rules/lib/core/bool); default is `False`  States that this module extension ensures complete reproducibility, thereby it should not be stored in the lockfile. |
 
 ## extract
 
@@ -116,11 +116,11 @@ Extract an archive to the repository directory.
 
 | Parameter | Description |
 | --- | --- |
-| `archive` | [string](../core/string); or [Label](../builtins/Label); or [path](../builtins/path); required  path to the archive that will be unpacked, relative to the repository directory. |
-| `output` | [string](../core/string); or [Label](../builtins/Label); or [path](../builtins/path); default is `''`  path to the directory where the archive will be unpacked, relative to the repository directory. |
-| `strip_prefix` | [string](../core/string); default is `''`  a directory prefix to strip from the extracted files. Many archives contain a top-level directory that contains all files in the archive. Instead of needing to specify this prefix over and over in the `build_file`, this field can be used to strip it from extracted files. For compatibility, this parameter may also be used under the deprecated name `stripPrefix`. |
-| `rename_files` | [dict](../core/dict); default is `{}`  An optional dict specifying files to rename during the extraction. Archive entries with names exactly matching a key will be renamed to the value, prior to any directory prefix adjustment. This can be used to extract archives that contain non-Unicode filenames, or which have files that would extract to the same path on case-insensitive filesystems. |
-| `watch_archive` | [string](../core/string); default is `'auto'`  whether to [watch](#watch) the archive file. Can be the string 'yes', 'no', or 'auto'. Passing 'yes' is equivalent to immediately invoking the [`watch()`](#watch) method; passing 'no' does not attempt to watch the file; passing 'auto' will only attempt to watch the file when it is legal to do so (see `watch()` docs for more information. |
+| `archive` | [string](/versions/8.0.1/rules/lib/core/string); or [Label](/versions/8.0.1/rules/lib/builtins/Label); or [path](/versions/8.0.1/rules/lib/builtins/path); required  path to the archive that will be unpacked, relative to the repository directory. |
+| `output` | [string](/versions/8.0.1/rules/lib/core/string); or [Label](/versions/8.0.1/rules/lib/builtins/Label); or [path](/versions/8.0.1/rules/lib/builtins/path); default is `''`  path to the directory where the archive will be unpacked, relative to the repository directory. |
+| `strip_prefix` | [string](/versions/8.0.1/rules/lib/core/string); default is `''`  a directory prefix to strip from the extracted files. Many archives contain a top-level directory that contains all files in the archive. Instead of needing to specify this prefix over and over in the `build_file`, this field can be used to strip it from extracted files. For compatibility, this parameter may also be used under the deprecated name `stripPrefix`. |
+| `rename_files` | [dict](/versions/8.0.1/rules/lib/core/dict); default is `{}`  An optional dict specifying files to rename during the extraction. Archive entries with names exactly matching a key will be renamed to the value, prior to any directory prefix adjustment. This can be used to extract archives that contain non-Unicode filenames, or which have files that would extract to the same path on case-insensitive filesystems. |
+| `watch_archive` | [string](/versions/8.0.1/rules/lib/core/string); default is `'auto'`  whether to [watch](#watch) the archive file. Can be the string 'yes', 'no', or 'auto'. Passing 'yes' is equivalent to immediately invoking the [`watch()`](#watch) method; passing 'no' does not attempt to watch the file; passing 'auto' will only attempt to watch the file when it is legal to do so (see `watch()` docs for more information. |
 
 ## file
 
@@ -134,10 +134,10 @@ Generates a file in the repository directory with the provided content.
 
 | Parameter | Description |
 | --- | --- |
-| `path` | [string](../core/string); or [Label](../builtins/Label); or [path](../builtins/path); required  Path of the file to create, relative to the repository directory. |
-| `content` | [string](../core/string); default is `''`  The content of the file to create, empty by default. |
-| `executable` | [bool](../core/bool); default is `True`  Set the executable flag on the created file, true by default. |
-| `legacy_utf8` | [bool](../core/bool); default is `False`  No-op. This parameter is deprecated and will be removed in a future version of Bazel. |
+| `path` | [string](/versions/8.0.1/rules/lib/core/string); or [Label](/versions/8.0.1/rules/lib/builtins/Label); or [path](/versions/8.0.1/rules/lib/builtins/path); required  Path of the file to create, relative to the repository directory. |
+| `content` | [string](/versions/8.0.1/rules/lib/core/string); default is `''`  The content of the file to create, empty by default. |
+| `executable` | [bool](/versions/8.0.1/rules/lib/core/bool); default is `True`  Set the executable flag on the created file, true by default. |
+| `legacy_utf8` | [bool](/versions/8.0.1/rules/lib/core/bool); default is `False`  No-op. This parameter is deprecated and will be removed in a future version of Bazel. |
 
 ## getenv
 
@@ -153,8 +153,8 @@ When building incrementally, any change to the value of the variable named by `n
 
 | Parameter | Description |
 | --- | --- |
-| `name` | [string](../core/string); required  Name of desired environment variable. |
-| `default` | [string](../core/string); or `None`; default is `None`  Default value to return if `name` is not found. |
+| `name` | [string](/versions/8.0.1/rules/lib/core/string); required  Name of desired environment variable. |
+| `default` | [string](/versions/8.0.1/rules/lib/core/string); or `None`; default is `None`  Default value to return if `name` is not found. |
 
 May return `None`.
 
@@ -164,13 +164,13 @@ May return `None`.
 bool module_ctx.is_dev_dependency(tag)
 ```
 
-Returns whether the given tag was specified on the result of a [use\_extension](../globals/module#use_extension) call with `devDependency = True`.
+Returns whether the given tag was specified on the result of a [use\_extension](/versions/8.0.1/rules/lib/globals/module#use_extension) call with `devDependency = True`.
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `tag` | bazel\_module\_tag; required  A tag obtained from [bazel\_module.tags](../builtins/bazel_module#tags). |
+| `tag` | bazel\_module\_tag; required  A tag obtained from [bazel\_module.tags](/versions/8.0.1/rules/lib/builtins/bazel_module#tags). |
 
 ## modules
 
@@ -178,7 +178,7 @@ Returns whether the given tag was specified on the result of a [use\_extension](
 list module_ctx.modules
 ```
 
-A list of all the Bazel modules in the external dependency graph that use this module extension, each of which is a [bazel\_module](../builtins/bazel_module) object that exposes all the tags it specified for this extension. The iteration order of this dictionary is guaranteed to be the same as breadth-first search starting from the root module.
+A list of all the Bazel modules in the external dependency graph that use this module extension, each of which is a [bazel\_module](/versions/8.0.1/rules/lib/builtins/bazel_module) object that exposes all the tags it specified for this extension. The iteration order of this dictionary is guaranteed to be the same as breadth-first search starting from the root module.
 
 ## os
 
@@ -200,7 +200,7 @@ Returns a path from a string, label or path. If the path is relative, it will re
 
 | Parameter | Description |
 | --- | --- |
-| `path` | [string](../core/string); or [Label](../builtins/Label); or [path](../builtins/path); required  `string`, `Label` or `path` from which to create a path from. |
+| `path` | [string](/versions/8.0.1/rules/lib/core/string); or [Label](/versions/8.0.1/rules/lib/builtins/Label); or [path](/versions/8.0.1/rules/lib/builtins/path); required  `string`, `Label` or `path` from which to create a path from. |
 
 ## read
 
@@ -214,8 +214,8 @@ Reads the content of a file on the filesystem.
 
 | Parameter | Description |
 | --- | --- |
-| `path` | [string](../core/string); or [Label](../builtins/Label); or [path](../builtins/path); required  Path of the file to read from. |
-| `watch` | [string](../core/string); default is `'auto'`  Whether to [watch](#watch) the file. Can be the string 'yes', 'no', or 'auto'. Passing 'yes' is equivalent to immediately invoking the [`watch()`](#watch) method; passing 'no' does not attempt to watch the file; passing 'auto' will only attempt to watch the file when it is legal to do so (see `watch()` docs for more information. |
+| `path` | [string](/versions/8.0.1/rules/lib/core/string); or [Label](/versions/8.0.1/rules/lib/builtins/Label); or [path](/versions/8.0.1/rules/lib/builtins/path); required  Path of the file to read from. |
+| `watch` | [string](/versions/8.0.1/rules/lib/core/string); default is `'auto'`  Whether to [watch](#watch) the file. Can be the string 'yes', 'no', or 'auto'. Passing 'yes' is equivalent to immediately invoking the [`watch()`](#watch) method; passing 'no' does not attempt to watch the file; passing 'auto' will only attempt to watch the file when it is legal to do so (see `watch()` docs for more information. |
 
 ## report\_progress
 
@@ -229,7 +229,7 @@ Updates the progress status for the fetching of this repository or module extens
 
 | Parameter | Description |
 | --- | --- |
-| `status` | [string](../core/string); default is `''`  `string` describing the current status of the fetch progress. |
+| `status` | [string](/versions/8.0.1/rules/lib/core/string); default is `''`  `string` describing the current status of the fetch progress. |
 
 ## root\_module\_has\_non\_dev\_dependency
 
@@ -247,7 +247,7 @@ None module_ctx.watch(path)
 
 Tells Bazel to watch for changes to the given path, whether or not it exists, or whether it's a file or a directory. Any changes to the file or directory will invalidate this repository or module extension, and cause it to be refetched or re-evaluated next time.
 
-"Changes" include changes to the contents of the file (if the path is a file); if the path was a file but is now a directory, or vice versa; and if the path starts or stops existing. Notably, this does *not* include changes to any files under the directory if the path is a directory. For that, use [`path.readdir()`](path#readdir) instead.
+"Changes" include changes to the contents of the file (if the path is a file); if the path was a file but is now a directory, or vice versa; and if the path starts or stops existing. Notably, this does *not* include changes to any files under the directory if the path is a directory. For that, use [`path.readdir()`](/versions/8.0.1/rules/lib/builtins/path#readdir) instead.
 
 Note that attempting to watch paths inside the repo currently being fetched, or inside the working directory of the current module extension, will result in an error. A module extension attempting to watch a path outside the current Bazel workspace will also result in an error.
 
@@ -255,7 +255,7 @@ Note that attempting to watch paths inside the repo currently being fetched, or
 
 | Parameter | Description |
 | --- | --- |
-| `path` | [string](../core/string); or [Label](../builtins/Label); or [path](../builtins/path); required  Path of the file to watch. |
+| `path` | [string](/versions/8.0.1/rules/lib/core/string); or [Label](/versions/8.0.1/rules/lib/builtins/Label); or [path](/versions/8.0.1/rules/lib/builtins/path); required  Path of the file to watch. |
 
 ## which
 
@@ -269,6 +269,6 @@ Returns the `path` of the corresponding program or `None` if there is no such pr
 
 | Parameter | Description |
 | --- | --- |
-| `program` | [string](../core/string); required  Program to find in the path. |
+| `program` | [string](/versions/8.0.1/rules/lib/core/string); required  Program to find in the path. |
 
 May return `None`.
\ No newline at end of file
diff --git a/versions/8.0.1/rules/lib/builtins/path.mdx b/versions/8.0.1/rules/lib/builtins/path.mdx
index d200110e..e13362a1 100644
--- a/versions/8.0.1/rules/lib/builtins/path.mdx
+++ b/versions/8.0.1/rules/lib/builtins/path.mdx
@@ -77,7 +77,7 @@ Returns the list of entries in the directory denoted by this path. Each entry is
 
 | Parameter | Description |
 | --- | --- |
-| `watch` | [string](../core/string); default is `'auto'`  whether Bazel should watch the list of entries in this directory and refetch the repository or re-evaluate the module extension next time when any changes are detected. Changes to detect include entry creation, deletion, and renaming. Note that this doesn't watch the *contents* of any entries in the directory. Can be the string 'yes', 'no', or 'auto'. If set to 'auto', Bazel will only watch this directory when it is legal to do so (see [`repository_ctx.watch()`](repository_ctx#watch) docs for more information). |
+| `watch` | [string](/versions/8.0.1/rules/lib/core/string); default is `'auto'`  whether Bazel should watch the list of entries in this directory and refetch the repository or re-evaluate the module extension next time when any changes are detected. Changes to detect include entry creation, deletion, and renaming. Note that this doesn't watch the *contents* of any entries in the directory. Can be the string 'yes', 'no', or 'auto'. If set to 'auto', Bazel will only watch this directory when it is legal to do so (see [`repository_ctx.watch()`](/versions/8.0.1/rules/lib/builtins/repository_ctx#watch) docs for more information). |
 
 ## realpath
 
diff --git a/versions/8.0.1/rules/lib/builtins/repository_ctx.mdx b/versions/8.0.1/rules/lib/builtins/repository_ctx.mdx
index 17584ab3..2f814a15 100644
--- a/versions/8.0.1/rules/lib/builtins/repository_ctx.mdx
+++ b/versions/8.0.1/rules/lib/builtins/repository_ctx.mdx
@@ -48,7 +48,7 @@ Deletes a file or a directory. Returns a bool, indicating whether the file or di
 
 | Parameter | Description |
 | --- | --- |
-| `path` | [string](../core/string); or [path](../builtins/path); required  Path of the file to delete, relative to the repository directory, or absolute. Can be a path or a string. |
+| `path` | [string](/versions/8.0.1/rules/lib/core/string); or [path](/versions/8.0.1/rules/lib/builtins/path); required  Path of the file to delete, relative to the repository directory, or absolute. Can be a path or a string. |
 
 ## download
 
@@ -62,16 +62,16 @@ Downloads a file to the output path for the provided url and returns a struct co
 
 | Parameter | Description |
 | --- | --- |
-| `url` | [string](../core/string); or Iterable of [string](../core/string)s; required  List of mirror URLs referencing the same file. |
-| `output` | [string](../core/string); or [Label](../builtins/Label); or [path](../builtins/path); default is `''`  path to the output file, relative to the repository directory. |
-| `sha256` | [string](../core/string); default is `''`  The expected SHA-256 hash of the file downloaded. This must match the SHA-256 hash of the file downloaded. It is a security risk to omit the SHA-256 as remote files can change. At best omitting this field will make your build non-hermetic. It is optional to make development easier but should be set before shipping. If provided, the repository cache will first be checked for a file with the given hash; a download will only be attempted if the file was not found in the cache. After a successful download, the file will be added to the cache. |
-| `executable` | [bool](../core/bool); default is `False`  Set the executable flag on the created file, false by default. |
-| `allow_fail` | [bool](../core/bool); default is `False`  If set, indicate the error in the return value instead of raising an error for failed downloads. |
-| `canonical_id` | [string](../core/string); default is `''`  If set, restrict cache hits to those cases where the file was added to the cache with the same canonical id. By default caching uses the checksum (`sha256` or `integrity`). |
-| `auth` | [dict](../core/dict); default is `{}`  An optional dict specifying authentication information for some of the URLs. |
-| `headers` | [dict](../core/dict); default is `{}`  An optional dict specifying http headers for all URLs. |
-| `integrity` | [string](../core/string); default is `''`  Expected checksum of the file downloaded, in Subresource Integrity format. This must match the checksum of the file downloaded. It is a security risk to omit the checksum as remote files can change. At best omitting this field will make your build non-hermetic. It is optional to make development easier but should be set before shipping. If provided, the repository cache will first be checked for a file with the given checksum; a download will only be attempted if the file was not found in the cache. After a successful download, the file will be added to the cache. |
-| `block` | [bool](../core/bool); default is `True`  If set to false, the call returns immediately and instead of the regular return value, it returns a token with one single method, wait(), which blocks until the download is finished and returns the usual return value or throws as usual. |
+| `url` | [string](/versions/8.0.1/rules/lib/core/string); or Iterable of [string](/versions/8.0.1/rules/lib/core/string)s; required  List of mirror URLs referencing the same file. |
+| `output` | [string](/versions/8.0.1/rules/lib/core/string); or [Label](/versions/8.0.1/rules/lib/builtins/Label); or [path](/versions/8.0.1/rules/lib/builtins/path); default is `''`  path to the output file, relative to the repository directory. |
+| `sha256` | [string](/versions/8.0.1/rules/lib/core/string); default is `''`  The expected SHA-256 hash of the file downloaded. This must match the SHA-256 hash of the file downloaded. It is a security risk to omit the SHA-256 as remote files can change. At best omitting this field will make your build non-hermetic. It is optional to make development easier but should be set before shipping. If provided, the repository cache will first be checked for a file with the given hash; a download will only be attempted if the file was not found in the cache. After a successful download, the file will be added to the cache. |
+| `executable` | [bool](/versions/8.0.1/rules/lib/core/bool); default is `False`  Set the executable flag on the created file, false by default. |
+| `allow_fail` | [bool](/versions/8.0.1/rules/lib/core/bool); default is `False`  If set, indicate the error in the return value instead of raising an error for failed downloads. |
+| `canonical_id` | [string](/versions/8.0.1/rules/lib/core/string); default is `''`  If set, restrict cache hits to those cases where the file was added to the cache with the same canonical id. By default caching uses the checksum (`sha256` or `integrity`). |
+| `auth` | [dict](/versions/8.0.1/rules/lib/core/dict); default is `{}`  An optional dict specifying authentication information for some of the URLs. |
+| `headers` | [dict](/versions/8.0.1/rules/lib/core/dict); default is `{}`  An optional dict specifying http headers for all URLs. |
+| `integrity` | [string](/versions/8.0.1/rules/lib/core/string); default is `''`  Expected checksum of the file downloaded, in Subresource Integrity format. This must match the checksum of the file downloaded. It is a security risk to omit the checksum as remote files can change. At best omitting this field will make your build non-hermetic. It is optional to make development easier but should be set before shipping. If provided, the repository cache will first be checked for a file with the given checksum; a download will only be attempted if the file was not found in the cache. After a successful download, the file will be added to the cache. |
+| `block` | [bool](/versions/8.0.1/rules/lib/core/bool); default is `True`  If set to false, the call returns immediately and instead of the regular return value, it returns a token with one single method, wait(), which blocks until the download is finished and returns the usual return value or throws as usual. |
 
 ## download\_and\_extract
 
@@ -85,17 +85,17 @@ Downloads a file to the output path for the provided url, extracts it, and retur
 
 | Parameter | Description |
 | --- | --- |
-| `url` | [string](../core/string); or Iterable of [string](../core/string)s; required  List of mirror URLs referencing the same file. |
-| `output` | [string](../core/string); or [Label](../builtins/Label); or [path](../builtins/path); default is `''`  Path to the directory where the archive will be unpacked, relative to the repository directory. |
-| `sha256` | [string](../core/string); default is `''`  The expected SHA-256 hash of the file downloaded. This must match the SHA-256 hash of the file downloaded. It is a security risk to omit the SHA-256 as remote files can change. At best omitting this field will make your build non-hermetic. It is optional to make development easier but should be set before shipping. If provided, the repository cache will first be checked for a file with the given hash; a download will only be attempted if the file was not found in the cache. After a successful download, the file will be added to the cache. |
-| `type` | [string](../core/string); default is `''`  The archive type of the downloaded file. By default, the archive type is determined from the file extension of the URL. If the file has no extension, you can explicitly specify either "zip", "jar", "war", "aar", "nupkg", "tar", "tar.gz", "tgz", "tar.xz", "txz", ".tar.zst", ".tzst", "tar.bz2", ".tbz", ".ar", or ".deb" here. |
-| `strip_prefix` | [string](../core/string); default is `''`  A directory prefix to strip from the extracted files. Many archives contain a top-level directory that contains all files in the archive. Instead of needing to specify this prefix over and over in the `build_file`, this field can be used to strip it from extracted files. For compatibility, this parameter may also be used under the deprecated name `stripPrefix`. |
-| `allow_fail` | [bool](../core/bool); default is `False`  If set, indicate the error in the return value instead of raising an error for failed downloads. |
-| `canonical_id` | [string](../core/string); default is `''`  If set, restrict cache hits to those cases where the file was added to the cache with the same canonical id. By default caching uses the checksum" (`sha256` or `integrity`). |
-| `auth` | [dict](../core/dict); default is `{}`  An optional dict specifying authentication information for some of the URLs. |
-| `headers` | [dict](../core/dict); default is `{}`  An optional dict specifying http headers for all URLs. |
-| `integrity` | [string](../core/string); default is `''`  Expected checksum of the file downloaded, in Subresource Integrity format. This must match the checksum of the file downloaded. It is a security risk to omit the checksum as remote files can change. At best omitting this field will make your build non-hermetic. It is optional to make development easier but should be set before shipping. If provided, the repository cache will first be checked for a file with the given checksum; a download will only be attempted if the file was not found in the cache. After a successful download, the file will be added to the cache. |
-| `rename_files` | [dict](../core/dict); default is `{}`  An optional dict specifying files to rename during the extraction. Archive entries with names exactly matching a key will be renamed to the value, prior to any directory prefix adjustment. This can be used to extract archives that contain non-Unicode filenames, or which have files that would extract to the same path on case-insensitive filesystems. |
+| `url` | [string](/versions/8.0.1/rules/lib/core/string); or Iterable of [string](/versions/8.0.1/rules/lib/core/string)s; required  List of mirror URLs referencing the same file. |
+| `output` | [string](/versions/8.0.1/rules/lib/core/string); or [Label](/versions/8.0.1/rules/lib/builtins/Label); or [path](/versions/8.0.1/rules/lib/builtins/path); default is `''`  Path to the directory where the archive will be unpacked, relative to the repository directory. |
+| `sha256` | [string](/versions/8.0.1/rules/lib/core/string); default is `''`  The expected SHA-256 hash of the file downloaded. This must match the SHA-256 hash of the file downloaded. It is a security risk to omit the SHA-256 as remote files can change. At best omitting this field will make your build non-hermetic. It is optional to make development easier but should be set before shipping. If provided, the repository cache will first be checked for a file with the given hash; a download will only be attempted if the file was not found in the cache. After a successful download, the file will be added to the cache. |
+| `type` | [string](/versions/8.0.1/rules/lib/core/string); default is `''`  The archive type of the downloaded file. By default, the archive type is determined from the file extension of the URL. If the file has no extension, you can explicitly specify either "zip", "jar", "war", "aar", "nupkg", "tar", "tar.gz", "tgz", "tar.xz", "txz", ".tar.zst", ".tzst", "tar.bz2", ".tbz", ".ar", or ".deb" here. |
+| `strip_prefix` | [string](/versions/8.0.1/rules/lib/core/string); default is `''`  A directory prefix to strip from the extracted files. Many archives contain a top-level directory that contains all files in the archive. Instead of needing to specify this prefix over and over in the `build_file`, this field can be used to strip it from extracted files. For compatibility, this parameter may also be used under the deprecated name `stripPrefix`. |
+| `allow_fail` | [bool](/versions/8.0.1/rules/lib/core/bool); default is `False`  If set, indicate the error in the return value instead of raising an error for failed downloads. |
+| `canonical_id` | [string](/versions/8.0.1/rules/lib/core/string); default is `''`  If set, restrict cache hits to those cases where the file was added to the cache with the same canonical id. By default caching uses the checksum" (`sha256` or `integrity`). |
+| `auth` | [dict](/versions/8.0.1/rules/lib/core/dict); default is `{}`  An optional dict specifying authentication information for some of the URLs. |
+| `headers` | [dict](/versions/8.0.1/rules/lib/core/dict); default is `{}`  An optional dict specifying http headers for all URLs. |
+| `integrity` | [string](/versions/8.0.1/rules/lib/core/string); default is `''`  Expected checksum of the file downloaded, in Subresource Integrity format. This must match the checksum of the file downloaded. It is a security risk to omit the checksum as remote files can change. At best omitting this field will make your build non-hermetic. It is optional to make development easier but should be set before shipping. If provided, the repository cache will first be checked for a file with the given checksum; a download will only be attempted if the file was not found in the cache. After a successful download, the file will be added to the cache. |
+| `rename_files` | [dict](/versions/8.0.1/rules/lib/core/dict); default is `{}`  An optional dict specifying files to rename during the extraction. Archive entries with names exactly matching a key will be renamed to the value, prior to any directory prefix adjustment. This can be used to extract archives that contain non-Unicode filenames, or which have files that would extract to the same path on case-insensitive filesystems. |
 
 ## execute
 
@@ -109,11 +109,11 @@ Executes the command given by the list of arguments. The execution time of the c
 
 | Parameter | Description |
 | --- | --- |
-| `arguments` | [sequence](../core/list); required  List of arguments, the first element should be the path to the program to execute. |
-| `timeout` | [int](../core/int); default is `600`  Maximum duration of the command in seconds (default is 600 seconds). |
-| `environment` | [dict](../core/dict); default is `{}`  Force some environment variables to be set to be passed to the process. The value can be `None` to remove the environment variable. |
-| `quiet` | [bool](../core/bool); default is `True`  If stdout and stderr should be printed to the terminal. |
-| `working_directory` | [string](../core/string); default is `""`  Working directory for command execution. Can be relative to the repository root or absolute. The default is the repository root. |
+| `arguments` | [sequence](/versions/8.0.1/rules/lib/core/list); required  List of arguments, the first element should be the path to the program to execute. |
+| `timeout` | [int](/versions/8.0.1/rules/lib/core/int); default is `600`  Maximum duration of the command in seconds (default is 600 seconds). |
+| `environment` | [dict](/versions/8.0.1/rules/lib/core/dict); default is `{}`  Force some environment variables to be set to be passed to the process. The value can be `None` to remove the environment variable. |
+| `quiet` | [bool](/versions/8.0.1/rules/lib/core/bool); default is `True`  If stdout and stderr should be printed to the terminal. |
+| `working_directory` | [string](/versions/8.0.1/rules/lib/core/string); default is `""`  Working directory for command execution. Can be relative to the repository root or absolute. The default is the repository root. |
 
 ## extract
 
@@ -127,11 +127,11 @@ Extract an archive to the repository directory.
 
 | Parameter | Description |
 | --- | --- |
-| `archive` | [string](../core/string); or [Label](../builtins/Label); or [path](../builtins/path); required  path to the archive that will be unpacked, relative to the repository directory. |
-| `output` | [string](../core/string); or [Label](../builtins/Label); or [path](../builtins/path); default is `''`  path to the directory where the archive will be unpacked, relative to the repository directory. |
-| `strip_prefix` | [string](../core/string); default is `''`  a directory prefix to strip from the extracted files. Many archives contain a top-level directory that contains all files in the archive. Instead of needing to specify this prefix over and over in the `build_file`, this field can be used to strip it from extracted files. For compatibility, this parameter may also be used under the deprecated name `stripPrefix`. |
-| `rename_files` | [dict](../core/dict); default is `{}`  An optional dict specifying files to rename during the extraction. Archive entries with names exactly matching a key will be renamed to the value, prior to any directory prefix adjustment. This can be used to extract archives that contain non-Unicode filenames, or which have files that would extract to the same path on case-insensitive filesystems. |
-| `watch_archive` | [string](../core/string); default is `'auto'`  whether to [watch](#watch) the archive file. Can be the string 'yes', 'no', or 'auto'. Passing 'yes' is equivalent to immediately invoking the [`watch()`](#watch) method; passing 'no' does not attempt to watch the file; passing 'auto' will only attempt to watch the file when it is legal to do so (see `watch()` docs for more information. |
+| `archive` | [string](/versions/8.0.1/rules/lib/core/string); or [Label](/versions/8.0.1/rules/lib/builtins/Label); or [path](/versions/8.0.1/rules/lib/builtins/path); required  path to the archive that will be unpacked, relative to the repository directory. |
+| `output` | [string](/versions/8.0.1/rules/lib/core/string); or [Label](/versions/8.0.1/rules/lib/builtins/Label); or [path](/versions/8.0.1/rules/lib/builtins/path); default is `''`  path to the directory where the archive will be unpacked, relative to the repository directory. |
+| `strip_prefix` | [string](/versions/8.0.1/rules/lib/core/string); default is `''`  a directory prefix to strip from the extracted files. Many archives contain a top-level directory that contains all files in the archive. Instead of needing to specify this prefix over and over in the `build_file`, this field can be used to strip it from extracted files. For compatibility, this parameter may also be used under the deprecated name `stripPrefix`. |
+| `rename_files` | [dict](/versions/8.0.1/rules/lib/core/dict); default is `{}`  An optional dict specifying files to rename during the extraction. Archive entries with names exactly matching a key will be renamed to the value, prior to any directory prefix adjustment. This can be used to extract archives that contain non-Unicode filenames, or which have files that would extract to the same path on case-insensitive filesystems. |
+| `watch_archive` | [string](/versions/8.0.1/rules/lib/core/string); default is `'auto'`  whether to [watch](#watch) the archive file. Can be the string 'yes', 'no', or 'auto'. Passing 'yes' is equivalent to immediately invoking the [`watch()`](#watch) method; passing 'no' does not attempt to watch the file; passing 'auto' will only attempt to watch the file when it is legal to do so (see `watch()` docs for more information. |
 
 ## file
 
@@ -145,10 +145,10 @@ Generates a file in the repository directory with the provided content.
 
 | Parameter | Description |
 | --- | --- |
-| `path` | [string](../core/string); or [Label](../builtins/Label); or [path](../builtins/path); required  Path of the file to create, relative to the repository directory. |
-| `content` | [string](../core/string); default is `''`  The content of the file to create, empty by default. |
-| `executable` | [bool](../core/bool); default is `True`  Set the executable flag on the created file, true by default. |
-| `legacy_utf8` | [bool](../core/bool); default is `False`  No-op. This parameter is deprecated and will be removed in a future version of Bazel. |
+| `path` | [string](/versions/8.0.1/rules/lib/core/string); or [Label](/versions/8.0.1/rules/lib/builtins/Label); or [path](/versions/8.0.1/rules/lib/builtins/path); required  Path of the file to create, relative to the repository directory. |
+| `content` | [string](/versions/8.0.1/rules/lib/core/string); default is `''`  The content of the file to create, empty by default. |
+| `executable` | [bool](/versions/8.0.1/rules/lib/core/bool); default is `True`  Set the executable flag on the created file, true by default. |
+| `legacy_utf8` | [bool](/versions/8.0.1/rules/lib/core/bool); default is `False`  No-op. This parameter is deprecated and will be removed in a future version of Bazel. |
 
 ## getenv
 
@@ -164,8 +164,8 @@ When building incrementally, any change to the value of the variable named by `n
 
 | Parameter | Description |
 | --- | --- |
-| `name` | [string](../core/string); required  Name of desired environment variable. |
-| `default` | [string](../core/string); or `None`; default is `None`  Default value to return if `name` is not found. |
+| `name` | [string](/versions/8.0.1/rules/lib/core/string); required  Name of desired environment variable. |
+| `default` | [string](/versions/8.0.1/rules/lib/core/string); or `None`; default is `None`  Default value to return if `name` is not found. |
 
 May return `None`.
 
@@ -197,9 +197,9 @@ Apply a patch file to the root directory of external repository. The patch file
 
 | Parameter | Description |
 | --- | --- |
-| `patch_file` | [string](../core/string); or [Label](../builtins/Label); or [path](../builtins/path); required  The patch file to apply, it can be label, relative path or absolute path. If it's a relative path, it will resolve to the repository directory. |
-| `strip` | [int](../core/int); default is `0`  Strip the specified number of leading components from file names. |
-| `watch_patch` | [string](../core/string); default is `'auto'`  Whether to [watch](#watch) the patch file. Can be the string 'yes', 'no', or 'auto'. Passing 'yes' is equivalent to immediately invoking the [`watch()`](#watch) method; passing 'no' does not attempt to watch the file; passing 'auto' will only attempt to watch the file when it is legal to do so (see `watch()` docs for more information. |
+| `patch_file` | [string](/versions/8.0.1/rules/lib/core/string); or [Label](/versions/8.0.1/rules/lib/builtins/Label); or [path](/versions/8.0.1/rules/lib/builtins/path); required  The patch file to apply, it can be label, relative path or absolute path. If it's a relative path, it will resolve to the repository directory. |
+| `strip` | [int](/versions/8.0.1/rules/lib/core/int); default is `0`  Strip the specified number of leading components from file names. |
+| `watch_patch` | [string](/versions/8.0.1/rules/lib/core/string); default is `'auto'`  Whether to [watch](#watch) the patch file. Can be the string 'yes', 'no', or 'auto'. Passing 'yes' is equivalent to immediately invoking the [`watch()`](#watch) method; passing 'no' does not attempt to watch the file; passing 'auto' will only attempt to watch the file when it is legal to do so (see `watch()` docs for more information. |
 
 ## path
 
@@ -213,7 +213,7 @@ Returns a path from a string, label or path. If the path is relative, it will re
 
 | Parameter | Description |
 | --- | --- |
-| `path` | [string](../core/string); or [Label](../builtins/Label); or [path](../builtins/path); required  `string`, `Label` or `path` from which to create a path from. |
+| `path` | [string](/versions/8.0.1/rules/lib/core/string); or [Label](/versions/8.0.1/rules/lib/builtins/Label); or [path](/versions/8.0.1/rules/lib/builtins/path); required  `string`, `Label` or `path` from which to create a path from. |
 
 ## read
 
@@ -227,8 +227,8 @@ Reads the content of a file on the filesystem.
 
 | Parameter | Description |
 | --- | --- |
-| `path` | [string](../core/string); or [Label](../builtins/Label); or [path](../builtins/path); required  Path of the file to read from. |
-| `watch` | [string](../core/string); default is `'auto'`  Whether to [watch](#watch) the file. Can be the string 'yes', 'no', or 'auto'. Passing 'yes' is equivalent to immediately invoking the [`watch()`](#watch) method; passing 'no' does not attempt to watch the file; passing 'auto' will only attempt to watch the file when it is legal to do so (see `watch()` docs for more information. |
+| `path` | [string](/versions/8.0.1/rules/lib/core/string); or [Label](/versions/8.0.1/rules/lib/builtins/Label); or [path](/versions/8.0.1/rules/lib/builtins/path); required  Path of the file to read from. |
+| `watch` | [string](/versions/8.0.1/rules/lib/core/string); default is `'auto'`  Whether to [watch](#watch) the file. Can be the string 'yes', 'no', or 'auto'. Passing 'yes' is equivalent to immediately invoking the [`watch()`](#watch) method; passing 'no' does not attempt to watch the file; passing 'auto' will only attempt to watch the file when it is legal to do so (see `watch()` docs for more information. |
 
 ## rename
 
@@ -243,8 +243,8 @@ already exists. Both paths must be located within the repository.
 
 | Parameter | Description |
 | --- | --- |
-| `src` | [string](../core/string); or [Label](../builtins/Label); or [path](../builtins/path); required  The path of the existing file or directory to rename, relative to the repository directory. |
-| `dst` | [string](../core/string); or [Label](../builtins/Label); or [path](../builtins/path); required  The new name to which the file or directory will be renamed to, relative to the repository directory. |
+| `src` | [string](/versions/8.0.1/rules/lib/core/string); or [Label](/versions/8.0.1/rules/lib/builtins/Label); or [path](/versions/8.0.1/rules/lib/builtins/path); required  The path of the existing file or directory to rename, relative to the repository directory. |
+| `dst` | [string](/versions/8.0.1/rules/lib/core/string); or [Label](/versions/8.0.1/rules/lib/builtins/Label); or [path](/versions/8.0.1/rules/lib/builtins/path); required  The new name to which the file or directory will be renamed to, relative to the repository directory. |
 
 ## report\_progress
 
@@ -258,7 +258,7 @@ Updates the progress status for the fetching of this repository or module extens
 
 | Parameter | Description |
 | --- | --- |
-| `status` | [string](../core/string); default is `''`  `string` describing the current status of the fetch progress. |
+| `status` | [string](/versions/8.0.1/rules/lib/core/string); default is `''`  `string` describing the current status of the fetch progress. |
 
 ## symlink
 
@@ -272,8 +272,8 @@ Creates a symlink on the filesystem.
 
 | Parameter | Description |
 | --- | --- |
-| `target` | [string](../core/string); or [Label](../builtins/Label); or [path](../builtins/path); required  The path that the symlink should point to. |
-| `link_name` | [string](../core/string); or [Label](../builtins/Label); or [path](../builtins/path); required  The path of the symlink to create. |
+| `target` | [string](/versions/8.0.1/rules/lib/core/string); or [Label](/versions/8.0.1/rules/lib/builtins/Label); or [path](/versions/8.0.1/rules/lib/builtins/path); required  The path that the symlink should point to. |
+| `link_name` | [string](/versions/8.0.1/rules/lib/core/string); or [Label](/versions/8.0.1/rules/lib/builtins/Label); or [path](/versions/8.0.1/rules/lib/builtins/path); required  The path of the symlink to create. |
 
 ## template
 
@@ -287,11 +287,11 @@ Generates a new file using a `template`. Every occurrence in `template` of a key
 
 | Parameter | Description |
 | --- | --- |
-| `path` | [string](../core/string); or [Label](../builtins/Label); or [path](../builtins/path); required  Path of the file to create, relative to the repository directory. |
-| `template` | [string](../core/string); or [Label](../builtins/Label); or [path](../builtins/path); required  Path to the template file. |
-| `substitutions` | [dict](../core/dict); default is `{}`  Substitutions to make when expanding the template. |
-| `executable` | [bool](../core/bool); default is `True`  Set the executable flag on the created file, true by default. |
-| `watch_template` | [string](../core/string); default is `'auto'`  Whether to [watch](#watch) the template file. Can be the string 'yes', 'no', or 'auto'. Passing 'yes' is equivalent to immediately invoking the [`watch()`](#watch) method; passing 'no' does not attempt to watch the file; passing 'auto' will only attempt to watch the file when it is legal to do so (see `watch()` docs for more information. |
+| `path` | [string](/versions/8.0.1/rules/lib/core/string); or [Label](/versions/8.0.1/rules/lib/builtins/Label); or [path](/versions/8.0.1/rules/lib/builtins/path); required  Path of the file to create, relative to the repository directory. |
+| `template` | [string](/versions/8.0.1/rules/lib/core/string); or [Label](/versions/8.0.1/rules/lib/builtins/Label); or [path](/versions/8.0.1/rules/lib/builtins/path); required  Path to the template file. |
+| `substitutions` | [dict](/versions/8.0.1/rules/lib/core/dict); default is `{}`  Substitutions to make when expanding the template. |
+| `executable` | [bool](/versions/8.0.1/rules/lib/core/bool); default is `True`  Set the executable flag on the created file, true by default. |
+| `watch_template` | [string](/versions/8.0.1/rules/lib/core/string); default is `'auto'`  Whether to [watch](#watch) the template file. Can be the string 'yes', 'no', or 'auto'. Passing 'yes' is equivalent to immediately invoking the [`watch()`](#watch) method; passing 'no' does not attempt to watch the file; passing 'auto' will only attempt to watch the file when it is legal to do so (see `watch()` docs for more information. |
 
 ## watch
 
@@ -301,7 +301,7 @@ None repository_ctx.watch(path)
 
 Tells Bazel to watch for changes to the given path, whether or not it exists, or whether it's a file or a directory. Any changes to the file or directory will invalidate this repository or module extension, and cause it to be refetched or re-evaluated next time.
 
-"Changes" include changes to the contents of the file (if the path is a file); if the path was a file but is now a directory, or vice versa; and if the path starts or stops existing. Notably, this does *not* include changes to any files under the directory if the path is a directory. For that, use [`path.readdir()`](path#readdir) instead.
+"Changes" include changes to the contents of the file (if the path is a file); if the path was a file but is now a directory, or vice versa; and if the path starts or stops existing. Notably, this does *not* include changes to any files under the directory if the path is a directory. For that, use [`path.readdir()`](/versions/8.0.1/rules/lib/builtins/path#readdir) instead.
 
 Note that attempting to watch paths inside the repo currently being fetched, or inside the working directory of the current module extension, will result in an error. A module extension attempting to watch a path outside the current Bazel workspace will also result in an error.
 
@@ -309,7 +309,7 @@ Note that attempting to watch paths inside the repo currently being fetched, or
 
 | Parameter | Description |
 | --- | --- |
-| `path` | [string](../core/string); or [Label](../builtins/Label); or [path](../builtins/path); required  Path of the file to watch. |
+| `path` | [string](/versions/8.0.1/rules/lib/core/string); or [Label](/versions/8.0.1/rules/lib/builtins/Label); or [path](/versions/8.0.1/rules/lib/builtins/path); required  Path of the file to watch. |
 
 ## watch\_tree
 
@@ -325,7 +325,7 @@ Note that attempting to watch paths inside the repo currently being fetched will
 
 | Parameter | Description |
 | --- | --- |
-| `path` | [string](../core/string); or [Label](../builtins/Label); or [path](../builtins/path); required  Path of the directory tree to watch. |
+| `path` | [string](/versions/8.0.1/rules/lib/core/string); or [Label](/versions/8.0.1/rules/lib/builtins/Label); or [path](/versions/8.0.1/rules/lib/builtins/path); required  Path of the directory tree to watch. |
 
 ## which
 
@@ -339,7 +339,7 @@ Returns the `path` of the corresponding program or `None` if there is no such pr
 
 | Parameter | Description |
 | --- | --- |
-| `program` | [string](../core/string); required  Program to find in the path. |
+| `program` | [string](/versions/8.0.1/rules/lib/core/string); required  Program to find in the path. |
 
 May return `None`.
 
diff --git a/versions/8.0.1/rules/lib/builtins/repository_rule.mdx b/versions/8.0.1/rules/lib/builtins/repository_rule.mdx
index ef5dac59..07c48b4a 100644
--- a/versions/8.0.1/rules/lib/builtins/repository_rule.mdx
+++ b/versions/8.0.1/rules/lib/builtins/repository_rule.mdx
@@ -2,4 +2,4 @@
 title: 'repository\_rule'
 ---
 
-A callable value that may be invoked during evaluation of the WORKSPACE file or within the implementation function of a module extension to instantiate and return a repository rule. Created by [`repository_rule()`](../globals/bzl#repository_rule).
\ No newline at end of file
+A callable value that may be invoked during evaluation of the WORKSPACE file or within the implementation function of a module extension to instantiate and return a repository rule. Created by [`repository_rule()`](/versions/8.0.1/rules/lib/globals/bzl#repository_rule).
\ No newline at end of file
diff --git a/versions/8.0.1/rules/lib/builtins/rule.mdx b/versions/8.0.1/rules/lib/builtins/rule.mdx
index 04aeb226..aa2dbb68 100644
--- a/versions/8.0.1/rules/lib/builtins/rule.mdx
+++ b/versions/8.0.1/rules/lib/builtins/rule.mdx
@@ -3,7 +3,7 @@ title: 'rule'
 ---
 
 A callable value representing the type of a native or Starlark rule (created by
-[`rule()`](../globals/bzl#rule)). Calling the value during
+[`rule()`](/versions/8.0.1/rules/lib/globals/bzl#rule)). Calling the value during
 evaluation of a package's BUILD file creates an instance of the rule and adds it to the
 package's target set. For more information, visit this page about
 [Rules](https://bazel.build/versions/8.0.1/extending/rules).
\ No newline at end of file
diff --git a/versions/8.0.1/rules/lib/builtins/rule_attributes.mdx b/versions/8.0.1/rules/lib/builtins/rule_attributes.mdx
index 98fea764..d1afba1c 100644
--- a/versions/8.0.1/rules/lib/builtins/rule_attributes.mdx
+++ b/versions/8.0.1/rules/lib/builtins/rule_attributes.mdx
@@ -20,7 +20,7 @@ Information about attributes of a rule an aspect is applied to.
 struct rule_attributes.attr
 ```
 
-A struct to access the values of the [attributes](https://bazel.build/versions/8.0.1/extending/rules#attributes). The values are provided by the user (if not, a default value is used). The attributes of the struct and the types of their values correspond to the keys and values of the [`attrs` dict](../globals/bzl#rule.attrs) provided to the [`rule` function](../globals/bzl#rule). [See example of use](https://github.com/bazelbuild/examples/blob/main/rules/attributes/printer.bzl).
+A struct to access the values of the [attributes](https://bazel.build/versions/8.0.1/extending/rules#attributes). The values are provided by the user (if not, a default value is used). The attributes of the struct and the types of their values correspond to the keys and values of the [`attrs` dict](/versions/8.0.1/rules/lib/globals/bzl#rule.attrs) provided to the [`rule` function](/versions/8.0.1/rules/lib/globals/bzl#rule). [See example of use](https://github.com/bazelbuild/examples/blob/main/rules/attributes/printer.bzl).
 
 ## exec\_groups
 
@@ -36,7 +36,7 @@ A collection of the execution groups available for the rule the aspect is applie
 struct rule_attributes.executable
 ```
 
-A `struct` containing executable files defined in [label type attributes](../toplevel/attr#label) marked as [`executable=True`](../toplevel/attr#label.executable). The struct fields correspond to the attribute names. Each value in the struct is either a [`File`](../builtins/File) or `None`. If an optional attribute is not specified in the rule then the corresponding struct value is `None`. If a label type is not marked as `executable=True`, no corresponding struct field is generated. [See example of use](https://github.com/bazelbuild/examples/blob/main/rules/actions_run/execute.bzl).
+A `struct` containing executable files defined in [label type attributes](/versions/8.0.1/rules/lib/toplevel/attr#label) marked as [`executable=True`](/versions/8.0.1/rules/lib/toplevel/attr#label.executable). The struct fields correspond to the attribute names. Each value in the struct is either a [`File`](/versions/8.0.1/rules/lib/builtins/File) or `None`. If an optional attribute is not specified in the rule then the corresponding struct value is `None`. If a label type is not marked as `executable=True`, no corresponding struct field is generated. [See example of use](https://github.com/bazelbuild/examples/blob/main/rules/actions_run/execute.bzl).
 
 ## file
 
@@ -44,7 +44,7 @@ A `struct` containing executable files defined in [label type attributes](../top
 struct rule_attributes.file
 ```
 
-A `struct` containing files defined in [label type attributes](../toplevel/attr#label) marked as [`allow_single_file`](../toplevel/attr#label.allow_single_file). The struct fields correspond to the attribute names. The struct value is always a [`File`](../builtins/File) or `None`. If an optional attribute is not specified in the rule then the corresponding struct value is `None`. If a label type is not marked as `allow_single_file`, no corresponding struct field is generated. It is a shortcut for:
+A `struct` containing files defined in [label type attributes](/versions/8.0.1/rules/lib/toplevel/attr#label) marked as [`allow_single_file`](/versions/8.0.1/rules/lib/toplevel/attr#label.allow_single_file). The struct fields correspond to the attribute names. The struct value is always a [`File`](/versions/8.0.1/rules/lib/builtins/File) or `None`. If an optional attribute is not specified in the rule then the corresponding struct value is `None`. If a label type is not marked as `allow_single_file`, no corresponding struct field is generated. It is a shortcut for:
 
 ```
 list(ctx.attr..files)[0]
@@ -58,7 +58,7 @@ In other words, use `file` to access the (singular) [default output](https://baz
 struct rule_attributes.files
 ```
 
-A `struct` containing files defined in [label](../toplevel/attr#label) or [label list](../toplevel/attr#label_list) type attributes. The struct fields correspond to the attribute names. The struct values are `list` of [`File`](../builtins/File)s. It is a shortcut for:
+A `struct` containing files defined in [label](/versions/8.0.1/rules/lib/toplevel/attr#label) or [label list](/versions/8.0.1/rules/lib/toplevel/attr#label_list) type attributes. The struct fields correspond to the attribute names. The struct values are `list` of [`File`](/versions/8.0.1/rules/lib/builtins/File)s. It is a shortcut for:
 
 ```
 [f for t in ctx.attr. for f in t.files]
diff --git a/versions/8.0.1/rules/lib/builtins/runfiles.mdx b/versions/8.0.1/rules/lib/builtins/runfiles.mdx
index 4d127195..a0aa85e6 100644
--- a/versions/8.0.1/rules/lib/builtins/runfiles.mdx
+++ b/versions/8.0.1/rules/lib/builtins/runfiles.mdx
@@ -2,7 +2,7 @@
 title: 'runfiles'
 ---
 
-A container of information regarding a set of files required at runtime execution. This object should be passed via [DefaultInfo](../providers/DefaultInfo) in order to tell the build system about the runfiles needed by the outputs produced by the rule.
+A container of information regarding a set of files required at runtime execution. This object should be passed via [DefaultInfo](/versions/8.0.1/rules/lib/providers/DefaultInfo) in order to tell the build system about the runfiles needed by the outputs produced by the rule.
 
 See [runfiles guide](https://bazel.build/versions/8.0.1/extending/rules#runfiles) for details.
 
@@ -45,7 +45,7 @@ Returns a new runfiles object that includes all the contents of this one and the
 
 | Parameter | Description |
 | --- | --- |
-| `other` | [runfiles](../builtins/runfiles); required  The runfiles object to merge into this. |
+| `other` | [runfiles](/versions/8.0.1/rules/lib/builtins/runfiles); required  The runfiles object to merge into this. |
 
 ## merge\_all
 
@@ -59,7 +59,7 @@ Returns a new runfiles object that includes all the contents of this one and of
 
 | Parameter | Description |
 | --- | --- |
-| `other` | [sequence](../core/list) of [runfiles](../builtins/runfiles)s; required  The sequence of runfiles objects to merge into this. |
+| `other` | [sequence](/versions/8.0.1/rules/lib/core/list) of [runfiles](/versions/8.0.1/rules/lib/builtins/runfiles)s; required  The sequence of runfiles objects to merge into this. |
 
 ## root\_symlinks
 
diff --git a/versions/8.0.1/rules/lib/builtins/tag_class.mdx b/versions/8.0.1/rules/lib/builtins/tag_class.mdx
index 7d4349d0..cb04e1e7 100644
--- a/versions/8.0.1/rules/lib/builtins/tag_class.mdx
+++ b/versions/8.0.1/rules/lib/builtins/tag_class.mdx
@@ -2,4 +2,4 @@
 title: 'tag\_class'
 ---
 
-Defines a schema of attributes for a tag, created by [`tag_class()`](../globals/bzl#tag_class).
\ No newline at end of file
+Defines a schema of attributes for a tag, created by [`tag_class()`](/versions/8.0.1/rules/lib/globals/bzl#tag_class).
\ No newline at end of file
diff --git a/versions/8.0.1/rules/lib/builtins/transition.mdx b/versions/8.0.1/rules/lib/builtins/transition.mdx
index 9488abb2..e4743a77 100644
--- a/versions/8.0.1/rules/lib/builtins/transition.mdx
+++ b/versions/8.0.1/rules/lib/builtins/transition.mdx
@@ -39,5 +39,5 @@ For more details see [here](https://bazel.build/versions/8.0.1/rules/config#user
 | Parameter | Description |
 | --- | --- |
 | `implementation` | callable; required  The function implementing this transition. This function always has two parameters: `settings` and `attr`. The `settings` param is a dictionary whose set of keys is defined by the inputs parameter. So, for each build setting `--//foo=bar`, if `inputs` contains `//foo`, `settings` will have an entry `settings['//foo']='bar'`. The `attr` param is a reference to `ctx.attr`. This gives the implementation function access to the rule's attributes to make attribute-parameterized transitions possible. This function must return a `dict` from build setting identifier to build setting value; this represents the configuration transition: for each entry in the returned `dict`, the transition updates that setting to the new value. All other settings are unchanged. This function can also return a `list` of `dict`s or a `dict` of `dict`s in the case of a split transition. |
-| `inputs` | [sequence](../core/list) of [string](../core/string)s; required  List of build settings that can be read by this transition. This becomes the key set of the settings parameter of the implementation function parameter. |
-| `outputs` | [sequence](../core/list) of [string](../core/string)s; required  List of build settings that can be written by this transition. This must be a superset of the key set of the dictionary returned by this transition. |
\ No newline at end of file
+| `inputs` | [sequence](/versions/8.0.1/rules/lib/core/list) of [string](/versions/8.0.1/rules/lib/core/string)s; required  List of build settings that can be read by this transition. This becomes the key set of the settings parameter of the implementation function parameter. |
+| `outputs` | [sequence](/versions/8.0.1/rules/lib/core/list) of [string](/versions/8.0.1/rules/lib/core/string)s; required  List of build settings that can be written by this transition. This must be a superset of the key set of the dictionary returned by this transition. |
\ No newline at end of file
diff --git a/versions/8.0.1/rules/lib/core/bool.mdx b/versions/8.0.1/rules/lib/core/bool.mdx
index 52be3664..21a262c0 100644
--- a/versions/8.0.1/rules/lib/core/bool.mdx
+++ b/versions/8.0.1/rules/lib/core/bool.mdx
@@ -2,4 +2,4 @@
 title: 'bool'
 ---
 
-A type to represent booleans. There are only two possible values: True and False. Any value can be converted to a boolean using the [bool](../globals/all#bool) function.
\ No newline at end of file
+A type to represent booleans. There are only two possible values: True and False. Any value can be converted to a boolean using the [bool](/versions/8.0.1/rules/lib/globals/all#bool) function.
\ No newline at end of file
diff --git a/versions/8.0.1/rules/lib/core/dict.mdx b/versions/8.0.1/rules/lib/core/dict.mdx
index 9005668c..f3796e46 100644
--- a/versions/8.0.1/rules/lib/core/dict.mdx
+++ b/versions/8.0.1/rules/lib/core/dict.mdx
@@ -22,7 +22,7 @@ There are four ways to construct a dictionary:
      {i: 2*i for i in range(3)}  # {0: 0, 1: 2, 2: 4}
      ```
 
-     - A call to the built-in [dict](../globals/all#dict) function returns a dictionary containing the specified entries, which are inserted in argument order, positional arguments before named. As with comprehensions, duplicate keys are permitted.- The union expression `x | y` yields a new dictionary by combining two existing dictionaries. If the two dictionaries have a key `k` in common, the right hand side dictionary's value of the key (in other words, `y[k]`) wins. The `|=` variant of the union operator modifies a dictionary in-place. Example:
+     - A call to the built-in [dict](/versions/8.0.1/rules/lib/globals/all#dict) function returns a dictionary containing the specified entries, which are inserted in argument order, positional arguments before named. As with comprehensions, duplicate keys are permitted.- The union expression `x | y` yields a new dictionary by combining two existing dictionaries. If the two dictionaries have a key `k` in common, the right hand side dictionary's value of the key (in other words, `y[k]`) wins. The `|=` variant of the union operator modifies a dictionary in-place. Example:
 
          ```
          d = {"foo": "FOO", "bar": "BAR"} | {"foo": "FOO2", "baz": "BAZ"}
diff --git a/versions/8.0.1/rules/lib/core/json.mdx b/versions/8.0.1/rules/lib/core/json.mdx
index 0bb00e3e..c628e2a7 100644
--- a/versions/8.0.1/rules/lib/core/json.mdx
+++ b/versions/8.0.1/rules/lib/core/json.mdx
@@ -29,7 +29,7 @@ If `x` is not a valid JSON encoding and the optional `default` parameter is *not
 
 | Parameter | Description |
 | --- | --- |
-| `x` | [string](../core/string); required  JSON string to decode. |
+| `x` | [string](/versions/8.0.1/rules/lib/core/string); required  JSON string to decode. |
 | `default` | default is `unbound`  If specified, the value to return when `x` cannot be decoded. |
 
 ## encode
@@ -64,8 +64,8 @@ The encode\_indent function is equivalent to `json.indent(json.encode(x), ...)`.
 | Parameter | Description |
 | --- | --- |
 | `x` | required |
-| `prefix` | [string](../core/string); default is `''` |
-| `indent` | [string](../core/string); default is `'\t'` |
+| `prefix` | [string](/versions/8.0.1/rules/lib/core/string); default is `''` |
+| `indent` | [string](/versions/8.0.1/rules/lib/core/string); default is `'\t'` |
 
 ## indent
 
@@ -84,6 +84,6 @@ If the input is not valid, the function may fail or return invalid output.
 
 | Parameter | Description |
 | --- | --- |
-| `s` | [string](../core/string); required |
-| `prefix` | [string](../core/string); default is `''` |
-| `indent` | [string](../core/string); default is `'\t'` |
\ No newline at end of file
+| `s` | [string](/versions/8.0.1/rules/lib/core/string); required |
+| `prefix` | [string](/versions/8.0.1/rules/lib/core/string); default is `''` |
+| `indent` | [string](/versions/8.0.1/rules/lib/core/string); default is `'\t'` |
\ No newline at end of file
diff --git a/versions/8.0.1/rules/lib/core/list.mdx b/versions/8.0.1/rules/lib/core/list.mdx
index c19e9780..761fa8e8 100644
--- a/versions/8.0.1/rules/lib/core/list.mdx
+++ b/versions/8.0.1/rules/lib/core/list.mdx
@@ -91,8 +91,8 @@ Returns the index in the list of the first item whose value is x. It is an error
 | Parameter | Description |
 | --- | --- |
 | `x` | required |
-| `start` | [int](../core/int); or `None`; default is `None`  The start index of the list portion to inspect. |
-| `end` | [int](../core/int); or `None`; default is `None`  The end index of the list portion to inspect. |
+| `start` | [int](/versions/8.0.1/rules/lib/core/int); or `None`; default is `None`  The start index of the list portion to inspect. |
+| `end` | [int](/versions/8.0.1/rules/lib/core/int); or `None`; default is `None`  The end index of the list portion to inspect. |
 
 ## insert
 
@@ -106,7 +106,7 @@ Inserts an item at a given position.
 
 | Parameter | Description |
 | --- | --- |
-| `index` | [int](../core/int); required  The index of the given position. |
+| `index` | [int](/versions/8.0.1/rules/lib/core/int); required  The index of the given position. |
 | `item` | required  The item. |
 
 ## pop
@@ -121,7 +121,7 @@ Removes the item at the given position in the list, and returns it. If no `index
 
 | Parameter | Description |
 | --- | --- |
-| `i` | [int](../core/int); or `None`; default is `-1`  The index of the item. |
+| `i` | [int](/versions/8.0.1/rules/lib/core/int); or `None`; default is `-1`  The index of the item. |
 
 ## remove
 
diff --git a/versions/8.0.1/rules/lib/core/string.mdx b/versions/8.0.1/rules/lib/core/string.mdx
index 1673c6e4..5bf0620f 100644
--- a/versions/8.0.1/rules/lib/core/string.mdx
+++ b/versions/8.0.1/rules/lib/core/string.mdx
@@ -81,9 +81,9 @@ Returns the number of (non-overlapping) occurrences of substring `sub` in string
 
 | Parameter | Description |
 | --- | --- |
-| `sub` | [string](../core/string); required |
-| `start` | [int](../core/int); or `None`; default is `0` |
-| `end` | [int](../core/int); or `None`; default is `None`  optional position before which to restrict to search. |
+| `sub` | [string](/versions/8.0.1/rules/lib/core/string); required |
+| `start` | [int](/versions/8.0.1/rules/lib/core/int); or `None`; default is `0` |
+| `end` | [int](/versions/8.0.1/rules/lib/core/int); or `None`; default is `None`  optional position before which to restrict to search. |
 
 ## elems
 
@@ -105,9 +105,9 @@ Returns True if the string ends with `sub`, otherwise False, optionally restrict
 
 | Parameter | Description |
 | --- | --- |
-| `sub` | [string](../core/string); or [tuple](../core/tuple) of [string](../core/string)s; required  The suffix (or tuple of alternative suffixes) to match. |
-| `start` | [int](../core/int); or `None`; default is `0`  Test beginning at this position. |
-| `end` | [int](../core/int); or `None`; default is `None`  optional position at which to stop comparing. |
+| `sub` | [string](/versions/8.0.1/rules/lib/core/string); or [tuple](/versions/8.0.1/rules/lib/core/tuple) of [string](/versions/8.0.1/rules/lib/core/string)s; required  The suffix (or tuple of alternative suffixes) to match. |
+| `start` | [int](/versions/8.0.1/rules/lib/core/int); or `None`; default is `0`  Test beginning at this position. |
+| `end` | [int](/versions/8.0.1/rules/lib/core/int); or `None`; default is `None`  optional position at which to stop comparing. |
 
 ## find
 
@@ -121,9 +121,9 @@ Returns the first index where `sub` is found, or -1 if no such index exists, opt
 
 | Parameter | Description |
 | --- | --- |
-| `sub` | [string](../core/string); required  The substring to find. |
-| `start` | [int](../core/int); or `None`; default is `0`  Restrict to search from this position. |
-| `end` | [int](../core/int); or `None`; default is `None`  optional position before which to restrict to search. |
+| `sub` | [string](/versions/8.0.1/rules/lib/core/string); required  The substring to find. |
+| `start` | [int](/versions/8.0.1/rules/lib/core/int); or `None`; default is `0`  Restrict to search from this position. |
+| `end` | [int](/versions/8.0.1/rules/lib/core/int); or `None`; default is `None`  optional position before which to restrict to search. |
 
 ## format
 
@@ -131,7 +131,7 @@ Returns the first index where `sub` is found, or -1 if no such index exists, opt
 string string.format(*args, **kwargs)
 ```
 
-Perform string interpolation. Format strings contain replacement fields surrounded by curly braces `{}`. Anything that is not contained in braces is considered literal text, which is copied unchanged to the output.If you need to include a brace character in the literal text, it can be escaped by doubling: `{{` and `}}`A replacement field can be either a name, a number, or empty. Values are converted to strings using the [str](../globals/all#str) function.
+Perform string interpolation. Format strings contain replacement fields surrounded by curly braces `{}`. Anything that is not contained in braces is considered literal text, which is copied unchanged to the output.If you need to include a brace character in the literal text, it can be escaped by doubling: `{{` and `}}`A replacement field can be either a name, a number, or empty. Values are converted to strings using the [str](/versions/8.0.1/rules/lib/globals/all#str) function.
 
 ```
 # Access in order:
@@ -161,9 +161,9 @@ Returns the first index where `sub` is found, or raises an error if no such inde
 
 | Parameter | Description |
 | --- | --- |
-| `sub` | [string](../core/string); required  The substring to find. |
-| `start` | [int](../core/int); or `None`; default is `0`  Restrict to search from this position. |
-| `end` | [int](../core/int); or `None`; default is `None`  optional position before which to restrict to search. |
+| `sub` | [string](/versions/8.0.1/rules/lib/core/string); required  The substring to find. |
+| `start` | [int](/versions/8.0.1/rules/lib/core/int); or `None`; default is `0`  Restrict to search from this position. |
+| `end` | [int](/versions/8.0.1/rules/lib/core/int); or `None`; default is `None`  optional position before which to restrict to search. |
 
 ## isalnum
 
@@ -263,7 +263,7 @@ Returns a copy of the string where leading characters that appear in `chars` are
 
 | Parameter | Description |
 | --- | --- |
-| `chars` | [string](../core/string); or `None`; default is `None`  The characters to remove, or all whitespace if None. |
+| `chars` | [string](/versions/8.0.1/rules/lib/core/string); or `None`; default is `None`  The characters to remove, or all whitespace if None. |
 
 ## partition
 
@@ -277,7 +277,7 @@ Splits the input string at the first occurrence of the separator `sep` and retur
 
 | Parameter | Description |
 | --- | --- |
-| `sep` | [string](../core/string); required  The string to split on. |
+| `sep` | [string](/versions/8.0.1/rules/lib/core/string); required  The string to split on. |
 
 ## removeprefix
 
@@ -291,7 +291,7 @@ If the string starts with `prefix`, returns a new string with the prefix removed
 
 | Parameter | Description |
 | --- | --- |
-| `prefix` | [string](../core/string); required  The prefix to remove if present. |
+| `prefix` | [string](/versions/8.0.1/rules/lib/core/string); required  The prefix to remove if present. |
 
 ## removesuffix
 
@@ -305,7 +305,7 @@ If the string ends with `suffix`, returns a new string with the suffix removed.
 
 | Parameter | Description |
 | --- | --- |
-| `suffix` | [string](../core/string); required  The suffix to remove if present. |
+| `suffix` | [string](/versions/8.0.1/rules/lib/core/string); required  The suffix to remove if present. |
 
 ## replace
 
@@ -319,9 +319,9 @@ Returns a copy of the string in which the occurrences of `old` have been replace
 
 | Parameter | Description |
 | --- | --- |
-| `old` | [string](../core/string); required  The string to be replaced. |
-| `new` | [string](../core/string); required  The string to replace with. |
-| `count` | [int](../core/int); default is `-1`  The maximum number of replacements. If omitted, or if the value is negative, there is no limit. |
+| `old` | [string](/versions/8.0.1/rules/lib/core/string); required  The string to be replaced. |
+| `new` | [string](/versions/8.0.1/rules/lib/core/string); required  The string to replace with. |
+| `count` | [int](/versions/8.0.1/rules/lib/core/int); default is `-1`  The maximum number of replacements. If omitted, or if the value is negative, there is no limit. |
 
 ## rfind
 
@@ -335,9 +335,9 @@ Returns the last index where `sub` is found, or -1 if no such index exists, opti
 
 | Parameter | Description |
 | --- | --- |
-| `sub` | [string](../core/string); required  The substring to find. |
-| `start` | [int](../core/int); or `None`; default is `0`  Restrict to search from this position. |
-| `end` | [int](../core/int); or `None`; default is `None`  optional position before which to restrict to search. |
+| `sub` | [string](/versions/8.0.1/rules/lib/core/string); required  The substring to find. |
+| `start` | [int](/versions/8.0.1/rules/lib/core/int); or `None`; default is `0`  Restrict to search from this position. |
+| `end` | [int](/versions/8.0.1/rules/lib/core/int); or `None`; default is `None`  optional position before which to restrict to search. |
 
 ## rindex
 
@@ -351,9 +351,9 @@ Returns the last index where `sub` is found, or raises an error if no such index
 
 | Parameter | Description |
 | --- | --- |
-| `sub` | [string](../core/string); required  The substring to find. |
-| `start` | [int](../core/int); or `None`; default is `0`  Restrict to search from this position. |
-| `end` | [int](../core/int); or `None`; default is `None`  optional position before which to restrict to search. |
+| `sub` | [string](/versions/8.0.1/rules/lib/core/string); required  The substring to find. |
+| `start` | [int](/versions/8.0.1/rules/lib/core/int); or `None`; default is `0`  Restrict to search from this position. |
+| `end` | [int](/versions/8.0.1/rules/lib/core/int); or `None`; default is `None`  optional position before which to restrict to search. |
 
 ## rpartition
 
@@ -367,7 +367,7 @@ Splits the input string at the last occurrence of the separator `sep` and return
 
 | Parameter | Description |
 | --- | --- |
-| `sep` | [string](../core/string); required  The string to split on. |
+| `sep` | [string](/versions/8.0.1/rules/lib/core/string); required  The string to split on. |
 
 ## rsplit
 
@@ -381,8 +381,8 @@ Returns a list of all the words in the string, using `sep` as the separator, opt
 
 | Parameter | Description |
 | --- | --- |
-| `sep` | [string](../core/string); required  The string to split on. |
-| `maxsplit` | [int](../core/int); or `None`; default is `None`  The maximum number of splits. |
+| `sep` | [string](/versions/8.0.1/rules/lib/core/string); required  The string to split on. |
+| `maxsplit` | [int](/versions/8.0.1/rules/lib/core/int); or `None`; default is `None`  The maximum number of splits. |
 
 ## rstrip
 
@@ -400,7 +400,7 @@ Returns a copy of the string where trailing characters that appear in `chars` ar
 
 | Parameter | Description |
 | --- | --- |
-| `chars` | [string](../core/string); or `None`; default is `None`  The characters to remove, or all whitespace if None. |
+| `chars` | [string](/versions/8.0.1/rules/lib/core/string); or `None`; default is `None`  The characters to remove, or all whitespace if None. |
 
 ## split
 
@@ -414,8 +414,8 @@ Returns a list of all the words in the string, using `sep` as the separator, opt
 
 | Parameter | Description |
 | --- | --- |
-| `sep` | [string](../core/string); required  The string to split on. |
-| `maxsplit` | [int](../core/int); or `None`; default is `None`  The maximum number of splits. |
+| `sep` | [string](/versions/8.0.1/rules/lib/core/string); required  The string to split on. |
+| `maxsplit` | [int](/versions/8.0.1/rules/lib/core/int); or `None`; default is `None`  The maximum number of splits. |
 
 ## splitlines
 
@@ -429,7 +429,7 @@ Splits the string at line boundaries ('\n', '\r\n', '\r') and returns the result
 
 | Parameter | Description |
 | --- | --- |
-| `keepends` | [bool](../core/bool); default is `False`  Whether the line breaks should be included in the resulting list. |
+| `keepends` | [bool](/versions/8.0.1/rules/lib/core/bool); default is `False`  Whether the line breaks should be included in the resulting list. |
 
 ## startswith
 
@@ -443,9 +443,9 @@ Returns True if the string starts with `sub`, otherwise False, optionally restri
 
 | Parameter | Description |
 | --- | --- |
-| `sub` | [string](../core/string); or [tuple](../core/tuple) of [string](../core/string)s; required  The prefix (or tuple of alternative prefixes) to match. |
-| `start` | [int](../core/int); or `None`; default is `0`  Test beginning at this position. |
-| `end` | [int](../core/int); or `None`; default is `None`  Stop comparing at this position. |
+| `sub` | [string](/versions/8.0.1/rules/lib/core/string); or [tuple](/versions/8.0.1/rules/lib/core/tuple) of [string](/versions/8.0.1/rules/lib/core/string)s; required  The prefix (or tuple of alternative prefixes) to match. |
+| `start` | [int](/versions/8.0.1/rules/lib/core/int); or `None`; default is `0`  Test beginning at this position. |
+| `end` | [int](/versions/8.0.1/rules/lib/core/int); or `None`; default is `None`  Stop comparing at this position. |
 
 ## strip
 
@@ -463,7 +463,7 @@ Returns a copy of the string where leading or trailing characters that appear in
 
 | Parameter | Description |
 | --- | --- |
-| `chars` | [string](../core/string); or `None`; default is `None`  The characters to remove, or all whitespace if None. |
+| `chars` | [string](/versions/8.0.1/rules/lib/core/string); or `None`; default is `None`  The characters to remove, or all whitespace if None. |
 
 ## title
 
diff --git a/versions/8.0.1/rules/lib/fragments.mdx b/versions/8.0.1/rules/lib/fragments.mdx
index c18aa18f..4432e548 100644
--- a/versions/8.0.1/rules/lib/fragments.mdx
+++ b/versions/8.0.1/rules/lib/fragments.mdx
@@ -2,7 +2,7 @@
 title: 'Configuration Fragments'
 ---
 
-Configuration fragments give rules access to language-specific parts of [configuration](builtins/configuration).
+Configuration fragments give rules access to language-specific parts of [configuration](/versions/8.0.1/rules/lib/builtins/configuration).
 
 Rule implementations can get them using `ctx.fragments.[fragment name]`
 
diff --git a/versions/8.0.1/rules/lib/fragments/apple.mdx b/versions/8.0.1/rules/lib/fragments/apple.mdx
index f7e8daff..b9041cd6 100644
--- a/versions/8.0.1/rules/lib/fragments/apple.mdx
+++ b/versions/8.0.1/rules/lib/fragments/apple.mdx
@@ -22,7 +22,7 @@ The platform of the current configuration for the given platform type. This shou
 
 | Parameter | Description |
 | --- | --- |
-| `platform_type` | [string](../core/string); required  The apple platform type. |
+| `platform_type` | [string](/versions/8.0.1/rules/lib/core/string); required  The apple platform type. |
 
 ## single\_arch\_cpu
 
diff --git a/versions/8.0.1/rules/lib/fragments/coverage.mdx b/versions/8.0.1/rules/lib/fragments/coverage.mdx
index b5888b0a..c94b369a 100644
--- a/versions/8.0.1/rules/lib/fragments/coverage.mdx
+++ b/versions/8.0.1/rules/lib/fragments/coverage.mdx
@@ -14,7 +14,7 @@ A configuration fragment representing the coverage configuration.
 Label coverage.output_generator
 ```
 
-Returns the label pointed to by the [`--coverage_output_generator`](https://bazel.build/versions/8.0.1/reference/command-line-reference#flag--coverage_output_generator) option if coverage collection is enabled, otherwise returns `None`. Can be accessed with [`configuration_field`](../globals/bzl#configuration_field):
+Returns the label pointed to by the [`--coverage_output_generator`](https://bazel.build/versions/8.0.1/reference/command-line-reference#flag--coverage_output_generator) option if coverage collection is enabled, otherwise returns `None`. Can be accessed with [`configuration_field`](/versions/8.0.1/rules/lib/globals/bzl#configuration_field):
 
 ```
 attr.label(
diff --git a/versions/8.0.1/rules/lib/fragments/cpp.mdx b/versions/8.0.1/rules/lib/fragments/cpp.mdx
index 581822e6..202c80e1 100644
--- a/versions/8.0.1/rules/lib/fragments/cpp.mdx
+++ b/versions/8.0.1/rules/lib/fragments/cpp.mdx
@@ -46,7 +46,7 @@ The flags passed to Bazel by [`--copt`](/versions/8.0.1/docs/user-manual#flag--c
 Label cpp.custom_malloc
 ```
 
-Returns label pointed to by [`--custom_malloc`](/versions/8.0.1/docs/user-manual#flag--custom_malloc) option. Can be accessed with [`configuration_field`](../globals/bzl#configuration_field):
+Returns label pointed to by [`--custom_malloc`](/versions/8.0.1/docs/user-manual#flag--custom_malloc) option. Can be accessed with [`configuration_field`](/versions/8.0.1/rules/lib/globals/bzl#configuration_field):
 
 ```
 attr.label(
diff --git a/versions/8.0.1/rules/lib/globals/all.mdx b/versions/8.0.1/rules/lib/globals/all.mdx
index bff0c96e..d2aa9702 100644
--- a/versions/8.0.1/rules/lib/globals/all.mdx
+++ b/versions/8.0.1/rules/lib/globals/all.mdx
@@ -49,7 +49,7 @@ abs(-2.3) == 2.3
 
 | Parameter | Description |
 | --- | --- |
-| `x` | [int](../core/int); or [float](../core/float); required  A number (int or float) |
+| `x` | [int](/versions/8.0.1/rules/lib/core/int); or [float](/versions/8.0.1/rules/lib/core/float); required  A number (int or float) |
 
 ## all
 
@@ -109,7 +109,7 @@ Constructor for the bool type. It returns `False` if the object is `None`, `Fals
 dict dict(pairs=[], **kwargs)
 ```
 
-Creates a [dictionary](../core/dict) from an optional positional argument and an optional set of keyword arguments. In the case where the same key is given multiple times, the last value will be used. Entries supplied via keyword arguments are considered to come after entries supplied via the positional argument.
+Creates a [dictionary](/versions/8.0.1/rules/lib/core/dict) from an optional positional argument and an optional set of keyword arguments. In the case where the same key is given multiple times, the last value will be used. Entries supplied via keyword arguments are considered to come after entries supplied via the positional argument.
 
 ### Parameters
 
@@ -149,7 +149,7 @@ enumerate([24, 21, 84]) == [(0, 24), (1, 21), (2, 84)]
 | Parameter | Description |
 | --- | --- |
 | `list` | required  input sequence. |
-| `start` | [int](../core/int); default is `0`  start index. |
+| `start` | [int](/versions/8.0.1/rules/lib/core/int); default is `0`  start index. |
 
 ## fail
 
@@ -164,8 +164,8 @@ Causes execution to fail with an error.
 | Parameter | Description |
 | --- | --- |
 | `msg` | default is `None`  Deprecated: use positional arguments instead. This argument acts like an implicit leading positional argument. |
-| `attr` | [string](../core/string); or `None`; default is `None`  Deprecated. Causes an optional prefix containing this string to be added to the error message. |
-| `sep` | [string](../core/string); default is `" "`  The separator string between the objects, default is space (" "). |
+| `attr` | [string](/versions/8.0.1/rules/lib/core/string); or `None`; default is `None`  Deprecated. Causes an optional prefix containing this string to be added to the error message. |
+| `sep` | [string](/versions/8.0.1/rules/lib/core/string); default is `" "`  The separator string between the objects, default is space (" "). |
 | `args` | required  A list of values, formatted with debugPrint (which is equivalent to str by default) and joined with sep (defaults to " "), that appear in the error message. |
 
 ## float
@@ -204,7 +204,7 @@ getattr(ctx.attr, "myattr", "mydefault")
 | Parameter | Description |
 | --- | --- |
 | `x` | required  The struct whose attribute is accessed. |
-| `name` | [string](../core/string); required  The name of the struct attribute. |
+| `name` | [string](/versions/8.0.1/rules/lib/core/string); required  The name of the struct attribute. |
 | `default` | default is `unbound`  The default value to return in case the struct doesn't have an attribute of the given name. |
 
 ## hasattr
@@ -224,7 +224,7 @@ hasattr(ctx.attr, "myattr")
 | Parameter | Description |
 | --- | --- |
 | `x` | required |
-| `name` | [string](../core/string); required  The name of the attribute. |
+| `name` | [string](/versions/8.0.1/rules/lib/core/string); required  The name of the attribute. |
 
 ## hash
 
@@ -244,7 +244,7 @@ Hashing of values besides strings is not currently supported.
 
 | Parameter | Description |
 | --- | --- |
-| `value` | [string](../core/string); required  String value to hash. |
+| `value` | [string](/versions/8.0.1/rules/lib/core/string); required  String value to hash. |
 
 ## int
 
@@ -371,7 +371,7 @@ Using `print` in production code is discouraged due to the spam it creates for u
 
 | Parameter | Description |
 | --- | --- |
-| `sep` | [string](../core/string); default is `" "`  The separator string between the objects, default is space (" "). |
+| `sep` | [string](/versions/8.0.1/rules/lib/core/string); default is `" "`  The separator string between the objects, default is space (" "). |
 | `args` | required  The objects to print. |
 
 ## range
@@ -392,9 +392,9 @@ range(3, 0, -1) == [3, 2, 1]
 
 | Parameter | Description |
 | --- | --- |
-| `start_or_stop` | [int](../core/int); required  Value of the start element if stop is provided, otherwise value of stop and the actual start is 0 |
-| `stop_or_none` | [int](../core/int); or `None`; default is `None`  optional index of the first item *not* to be included in the resulting list; generation of the list stops before `stop` is reached. |
-| `step` | [int](../core/int); default is `1`  The increment (default is 1). It may be negative. |
+| `start_or_stop` | [int](/versions/8.0.1/rules/lib/core/int); required  Value of the start element if stop is provided, otherwise value of stop and the actual start is 0 |
+| `stop_or_none` | [int](/versions/8.0.1/rules/lib/core/int); or `None`; default is `None`  optional index of the first item *not* to be included in the resulting list; generation of the list stops before `stop` is reached. |
+| `step` | [int](/versions/8.0.1/rules/lib/core/int); default is `1`  The increment (default is 1). It may be negative. |
 
 ## repr
 
@@ -453,7 +453,7 @@ sorted(["two", "three", "four"], key = len) == ["two", "four", "three"]  # sort
 | --- | --- |
 | `iterable` | iterable; required  The iterable sequence to sort. |
 | `key` | callable; or `None`; default is `None`  An optional function applied to each element before comparison. |
-| `reverse` | [bool](../core/bool); default is `False`  Return results in descending order. |
+| `reverse` | [bool](/versions/8.0.1/rules/lib/core/bool); default is `False`  Return results in descending order. |
 
 ## str
 
diff --git a/versions/8.0.1/rules/lib/globals/build.mdx b/versions/8.0.1/rules/lib/globals/build.mdx
index 1822936b..619c22f9 100644
--- a/versions/8.0.1/rules/lib/globals/build.mdx
+++ b/versions/8.0.1/rules/lib/globals/build.mdx
@@ -28,7 +28,7 @@ Methods available in BUILD files. See also the Build Encyclopedia for extra [fun
 depset depset(direct=None, order="default", *, transitive=None)
 ```
 
-Creates a [depset](../builtins/depset). The `direct` parameter is a list of direct elements of the depset, and `transitive` parameter is a list of depsets whose elements become indirect elements of the created depset. The order in which elements are returned when the depset is converted to a list is specified by the `order` parameter. See the [Depsets overview](https://bazel.build/versions/8.0.1/extending/depsets) for more information.
+Creates a [depset](/versions/8.0.1/rules/lib/builtins/depset). The `direct` parameter is a list of direct elements of the depset, and `transitive` parameter is a list of depsets whose elements become indirect elements of the created depset. The order in which elements are returned when the depset is converted to a list is specified by the `order` parameter. See the [Depsets overview](https://bazel.build/versions/8.0.1/extending/depsets) for more information.
 
 All elements (direct and indirect) of a depset must be of the same type, as obtained by the expression `type(x)`.
 
@@ -42,9 +42,9 @@ The order of the created depset should be *compatible* with the order of its `tr
 
 | Parameter | Description |
 | --- | --- |
-| `direct` | [sequence](../core/list); or `None`; default is `None`  A list of *direct* elements of a depset. |
-| `order` | [string](../core/string); default is `"default"`  The traversal strategy for the new depset. See [here](../builtins/depset) for the possible values. |
-| `transitive` | [sequence](../core/list) of [depset](../builtins/depset)s; or `None`; default is `None`  A list of depsets whose elements will become indirect elements of the depset. |
+| `direct` | [sequence](/versions/8.0.1/rules/lib/core/list); or `None`; default is `None`  A list of *direct* elements of a depset. |
+| `order` | [string](/versions/8.0.1/rules/lib/core/string); default is `"default"`  The traversal strategy for the new depset. See [here](/versions/8.0.1/rules/lib/builtins/depset) for the possible values. |
+| `transitive` | [sequence](/versions/8.0.1/rules/lib/core/list) of [depset](/versions/8.0.1/rules/lib/builtins/depset)s; or `None`; default is `None`  A list of depsets whose elements will become indirect elements of the depset. |
 
 ## existing\_rule
 
@@ -72,7 +72,7 @@ If possible, avoid using this function. It makes BUILD files brittle and order-d
 
 | Parameter | Description |
 | --- | --- |
-| `name` | [string](../core/string); required  The name of the target. |
+| `name` | [string](/versions/8.0.1/rules/lib/core/string); required  The name of the target. |
 
 ## existing\_rules
 
@@ -98,9 +98,9 @@ Specifies a list of files belonging to this package that are exported to other p
 
 | Parameter | Description |
 | --- | --- |
-| `srcs` | [sequence](../core/list) of [string](../core/string)s; required  The list of files to export. |
-| `visibility` | [sequence](../core/list); or `None`; default is `None`  A visibility declaration can to be specified. The files will be visible to the targets specified. If no visibility is specified, the files will be visible to every package. |
-| `licenses` | [sequence](../core/list) of [string](../core/string)s; or `None`; default is `None`  Licenses to be specified. |
+| `srcs` | [sequence](/versions/8.0.1/rules/lib/core/list) of [string](/versions/8.0.1/rules/lib/core/string)s; required  The list of files to export. |
+| `visibility` | [sequence](/versions/8.0.1/rules/lib/core/list); or `None`; default is `None`  A visibility declaration can to be specified. The files will be visible to the targets specified. If no visibility is specified, the files will be visible to every package. |
+| `licenses` | [sequence](/versions/8.0.1/rules/lib/core/list) of [string](/versions/8.0.1/rules/lib/core/string)s; or `None`; default is `None`  Licenses to be specified. |
 
 ## glob
 
@@ -119,9 +119,9 @@ If the `exclude_directories` argument is enabled (set to `1`), files of type dir
 
 | Parameter | Description |
 | --- | --- |
-| `include` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  The list of glob patterns to include. |
-| `exclude` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  The list of glob patterns to exclude. |
-| `exclude_directories` | [int](../core/int); default is `1`  A flag whether to exclude directories or not. |
+| `include` | [sequence](/versions/8.0.1/rules/lib/core/list) of [string](/versions/8.0.1/rules/lib/core/string)s; default is `[]`  The list of glob patterns to include. |
+| `exclude` | [sequence](/versions/8.0.1/rules/lib/core/list) of [string](/versions/8.0.1/rules/lib/core/string)s; default is `[]`  The list of glob patterns to exclude. |
+| `exclude_directories` | [int](/versions/8.0.1/rules/lib/core/int); default is `1`  A flag whether to exclude directories or not. |
 | `allow_empty` | default is `unbound`  Whether we allow glob patterns to match nothing. If `allow\_empty` is False, each individual include pattern must match something and also the final result must be non-empty (after the matches of the `exclude` patterns are excluded). |
 
 ## module\_name
@@ -168,9 +168,9 @@ This function defines a set of packages and assigns a label to the group. The la
 
 | Parameter | Description |
 | --- | --- |
-| `name` | [string](../core/string); required  The unique name for this rule. |
-| `packages` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  A complete enumeration of packages in this group. |
-| `includes` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  Other package groups that are included in this one. |
+| `name` | [string](/versions/8.0.1/rules/lib/core/string); required  The unique name for this rule. |
+| `packages` | [sequence](/versions/8.0.1/rules/lib/core/list) of [string](/versions/8.0.1/rules/lib/core/string)s; default is `[]`  A complete enumeration of packages in this group. |
+| `includes` | [sequence](/versions/8.0.1/rules/lib/core/list) of [string](/versions/8.0.1/rules/lib/core/string)s; default is `[]`  Other package groups that are included in this one. |
 
 ## package\_name
 
@@ -186,19 +186,19 @@ The name of the package being evaluated, without the repository name. For exampl
 Label package_relative_label(input)
 ```
 
-Converts the input string into a [Label](../builtins/Label) object, in the context of the package currently being initialized (that is, the `BUILD` file for which the current macro is executing). If the input is already a `Label`, it is returned unchanged.
+Converts the input string into a [Label](/versions/8.0.1/rules/lib/builtins/Label) object, in the context of the package currently being initialized (that is, the `BUILD` file for which the current macro is executing). If the input is already a `Label`, it is returned unchanged.
 
 This function may only be called while evaluating a BUILD file and the macros it directly or indirectly calls; it may not be called in (for instance) a rule implementation function.
 
 The result of this function is the same `Label` value as would be produced by passing the given string to a label-valued attribute of a target declared in the BUILD file.
 
-*Usage note:* The difference between this function and [Label()](../builtins/Label#Label) is that `Label()` uses the context of the package of the `.bzl` file that called it, not the package of the `BUILD` file. Use `Label()` when you need to refer to a fixed target that is hardcoded into the macro, such as a compiler. Use `package_relative_label()` when you need to normalize a label string supplied by the BUILD file to a `Label` object. (There is no way to convert a string to a `Label` in the context of a package other than the BUILD file or the calling .bzl file. For that reason, outer macros should always prefer to pass Label objects to inner macros rather than label strings.)
+*Usage note:* The difference between this function and [Label()](/versions/8.0.1/rules/lib/builtins/Label#Label) is that `Label()` uses the context of the package of the `.bzl` file that called it, not the package of the `BUILD` file. Use `Label()` when you need to refer to a fixed target that is hardcoded into the macro, such as a compiler. Use `package_relative_label()` when you need to normalize a label string supplied by the BUILD file to a `Label` object. (There is no way to convert a string to a `Label` in the context of a package other than the BUILD file or the calling .bzl file. For that reason, outer macros should always prefer to pass Label objects to inner macros rather than label strings.)
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `input` | [string](../core/string); or [Label](../builtins/Label); required  The input label string or Label object. If a Label object is passed, it's returned as is. |
+| `input` | [string](/versions/8.0.1/rules/lib/core/string); or [Label](/versions/8.0.1/rules/lib/builtins/Label); required  The input label string or Label object. If a Label object is passed, it's returned as is. |
 
 ## repo\_name
 
@@ -231,8 +231,8 @@ unknown select(x, no_match_error='')
 
 | Parameter | Description |
 | --- | --- |
-| `x` | [dict](../core/dict); required |
-| `no_match_error` | [string](../core/string); default is `''`  Optional custom error to report if no condition matches. |
+| `x` | [dict](/versions/8.0.1/rules/lib/core/dict); required |
+| `no_match_error` | [string](/versions/8.0.1/rules/lib/core/string); default is `''`  Optional custom error to report if no condition matches. |
 
 ## subpackages
 
@@ -246,6 +246,6 @@ Returns a new mutable list of every direct subpackage of the current package, re
 
 | Parameter | Description |
 | --- | --- |
-| `include` | [sequence](../core/list) of [string](../core/string)s; required  The list of glob patterns to include in subpackages scan. |
-| `exclude` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  The list of glob patterns to exclude from subpackages scan. |
-| `allow_empty` | [bool](../core/bool); default is `False`  Whether we fail if the call returns an empty list. By default empty list indicates potential error in BUILD file where the call to subpackages() is superflous. Setting to true allows this function to succeed in that case. |*
\ No newline at end of file
+| `include` | [sequence](/versions/8.0.1/rules/lib/core/list) of [string](/versions/8.0.1/rules/lib/core/string)s; required  The list of glob patterns to include in subpackages scan. |
+| `exclude` | [sequence](/versions/8.0.1/rules/lib/core/list) of [string](/versions/8.0.1/rules/lib/core/string)s; default is `[]`  The list of glob patterns to exclude from subpackages scan. |
+| `allow_empty` | [bool](/versions/8.0.1/rules/lib/core/bool); default is `False`  Whether we fail if the call returns an empty list. By default empty list indicates potential error in BUILD file where the call to subpackages() is superflous. Setting to true allows this function to succeed in that case. |*
\ No newline at end of file
diff --git a/versions/8.0.1/rules/lib/globals/bzl.mdx b/versions/8.0.1/rules/lib/globals/bzl.mdx
index 1153c6f8..d259495e 100644
--- a/versions/8.0.1/rules/lib/globals/bzl.mdx
+++ b/versions/8.0.1/rules/lib/globals/bzl.mdx
@@ -28,7 +28,7 @@ Global methods available in all .bzl files.
 transition analysis_test_transition(settings)
 ```
 
-Creates a configuration transition to be applied on an analysis-test rule's dependencies. This transition may only be applied on attributes of rules with `analysis_test = True`. Such rules are restricted in capabilities (for example, the size of their dependency tree is limited), so transitions created using this function are limited in potential scope as compared to transitions created using [`transition()`](../builtins/transition).
+Creates a configuration transition to be applied on an analysis-test rule's dependencies. This transition may only be applied on attributes of rules with `analysis_test = True`. Such rules are restricted in capabilities (for example, the size of their dependency tree is limited), so transitions created using this function are limited in potential scope as compared to transitions created using [`transition()`](/versions/8.0.1/rules/lib/builtins/transition).
 
 This function is primarily designed to facilitate the [Analysis Test Framework](https://bazel.build/versions/8.0.1/rules/testing) core library. See its documentation (or its implementation) for best practices.
 
@@ -36,7 +36,7 @@ This function is primarily designed to facilitate the [Analysis Test Framework](
 
 | Parameter | Description |
 | --- | --- |
-| `settings` | [dict](../core/dict); required  A dictionary containing information about configuration settings which should be set by this configuration transition. Keys are build setting labels and values are their new post-transition values. All other settings are unchanged. Use this to declare specific configuration settings that an analysis test requires to be set in order to pass. |
+| `settings` | [dict](/versions/8.0.1/rules/lib/core/dict); required  A dictionary containing information about configuration settings which should be set by this configuration transition. Keys are build setting labels and values are their new post-transition values. All other settings are unchanged. Use this to declare specific configuration settings that an analysis test requires to be set in order to pass. |
 
 ## aspect
 
@@ -50,23 +50,23 @@ Creates a new aspect. The result of this function must be stored in a global val
 
 | Parameter | Description |
 | --- | --- |
-| `implementation` | [function](../core/function); required  A Starlark function that implements this aspect, with exactly two parameters: [Target](../builtins/Target) (the target to which the aspect is applied) and [ctx](../builtins/ctx) (the rule context which the target is created from). Attributes of the target are available via the `ctx.rule` field. This function is evaluated during the analysis phase for each application of an aspect to a target. |
-| `attr_aspects` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  List of attribute names. The aspect propagates along dependencies specified in the attributes of a target with these names. Common values here include `deps` and `exports`. The list can also contain a single string `"*"` to propagate along all dependencies of a target. |
-| `toolchains_aspects` | [sequence](../core/list); default is `[]`  List of toolchain types. The aspect propagates to target toolchains which match these toolchain types. |
-| `attrs` | [dict](../core/dict); default is `{}`  A dictionary declaring all the attributes of the aspect. It maps from an attribute name to an attribute object, like `attr.label` or `attr.string` (see [`attr`](../toplevel/attr) module). Aspect attributes are available to implementation function as fields of `ctx` parameter. Implicit attributes starting with `_` must have default values, and have type `label` or `label_list`.  Explicit attributes must have type `string`, and must use the `values` restriction. Explicit attributes restrict the aspect to only be used with rules that have attributes of the same name, type, and valid values according to the restriction.  Declared attributes will convert `None` to the default value. |
-| `required_providers` | [sequence](../core/list); default is `[]`  This attribute allows the aspect to limit its propagation to only the targets whose rules advertise its required providers. The value must be a list containing either individual providers or lists of providers but not both. For example, `[[FooInfo], [BarInfo], [BazInfo, QuxInfo]]` is a valid value while `[FooInfo, BarInfo, [BazInfo, QuxInfo]]` is not valid. An unnested list of providers will automatically be converted to a list containing one list of providers. That is, `[FooInfo, BarInfo]` will automatically be converted to `[[FooInfo, BarInfo]]`. To make some rule (e.g. `some_rule`) targets visible to an aspect, `some_rule` must advertise all providers from at least one of the required providers lists. For example, if the `required_providers` of an aspect are `[[FooInfo], [BarInfo], [BazInfo, QuxInfo]]`, this aspect can see `some_rule` targets if and only if `some_rule` provides `FooInfo`, *or* `BarInfo`, *or* both `BazInfo` *and* `QuxInfo`. |
-| `required_aspect_providers` | [sequence](../core/list); default is `[]`  This attribute allows this aspect to inspect other aspects. The value must be a list containing either individual providers or lists of providers but not both. For example, `[[FooInfo], [BarInfo], [BazInfo, QuxInfo]]` is a valid value while `[FooInfo, BarInfo, [BazInfo, QuxInfo]]` is not valid. An unnested list of providers will automatically be converted to a list containing one list of providers. That is, `[FooInfo, BarInfo]` will automatically be converted to `[[FooInfo, BarInfo]]`. To make another aspect (e.g. `other_aspect`) visible to this aspect, `other_aspect` must provide all providers from at least one of the lists. In the example of `[[FooInfo], [BarInfo], [BazInfo, QuxInfo]]`, this aspect can see `other_aspect` if and only if `other_aspect` provides `FooInfo`, *or* `BarInfo`, *or* both `BazInfo` *and* `QuxInfo`. |
-| `provides` | [sequence](../core/list); default is `[]`  A list of providers that the implementation function must return. It is an error if the implementation function omits any of the types of providers listed here from its return value. However, the implementation function may return additional providers not listed here. Each element of the list is an `*Info` object returned by [`provider()`](../globals/bzl#provider), except that a legacy provider is represented by its string name instead.When a target of the rule is used as a dependency for a target that declares a required provider, it is not necessary to specify that provider here. It is enough that the implementation function returns it. However, it is considered best practice to specify it, even though this is not required. The [`required_providers`](../globals/bzl#aspect.required_providers) field of an [aspect](../globals/bzl#aspect) does, however, require that providers are specified here. |
-| `requires` | [sequence](../core/list) of [Aspect](../builtins/Aspect)s; default is `[]`  List of aspects required to be propagated before this aspect. |
-| `fragments` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  List of names of configuration fragments that the aspect requires in target configuration. |
-| `host_fragments` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  List of names of configuration fragments that the aspect requires in host configuration. |
-| `toolchains` | [sequence](../core/list); default is `[]`  If set, the set of toolchains this aspect requires. The list can contain String, Label, or StarlarkToolchainTypeApi objects, in any combination. Toolchains will be found by checking the current platform, and provided to the aspect implementation via `ctx.toolchain`. |
-| `incompatible_use_toolchain_transition` | [bool](../core/bool); default is `False`  Deprecated, this is no longer in use and should be removed. |
-| `doc` | [string](../core/string); or `None`; default is `None`  A description of the aspect that can be extracted by documentation generating tools. |
-| `apply_to_generating_rules` | [bool](../core/bool); default is `False`  If true, the aspect will, when applied to an output file, instead apply to the output file's generating rule. For example, suppose an aspect propagates transitively through attribute `deps` and it is applied to target `alpha`. Suppose `alpha` has `deps = [':beta\_output']`, where `beta\_output` is a declared output of a target `beta`. Suppose `beta` has a target `charlie` as one of its `deps`. If `apply\_to\_generating\_rules=True` for the aspect, then the aspect will propagate through `alpha`, `beta`, and `charlie`. If False, then the aspect will propagate only to `alpha`.  False by default. |
-| `exec_compatible_with` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  A list of constraints on the execution platform that apply to all instances of this aspect. |
-| `exec_groups` | [dict](../core/dict); or `None`; default is `None`  Dict of execution group name (string) to [`exec_group`s](../globals/bzl#exec_group). If set, allows aspects to run actions on multiple execution platforms within a single instance. See [execution groups documentation](/versions/8.0.1/reference/exec-groups) for more info. |
-| `subrules` | [sequence](../core/list) of [Subrule](../builtins/Subrule)s; default is `[]`  Experimental: list of subrules used by this aspect. |
+| `implementation` | [function](/versions/8.0.1/rules/lib/core/function); required  A Starlark function that implements this aspect, with exactly two parameters: [Target](/versions/8.0.1/rules/lib/builtins/Target) (the target to which the aspect is applied) and [ctx](/versions/8.0.1/rules/lib/builtins/ctx) (the rule context which the target is created from). Attributes of the target are available via the `ctx.rule` field. This function is evaluated during the analysis phase for each application of an aspect to a target. |
+| `attr_aspects` | [sequence](/versions/8.0.1/rules/lib/core/list) of [string](/versions/8.0.1/rules/lib/core/string)s; default is `[]`  List of attribute names. The aspect propagates along dependencies specified in the attributes of a target with these names. Common values here include `deps` and `exports`. The list can also contain a single string `"*"` to propagate along all dependencies of a target. |
+| `toolchains_aspects` | [sequence](/versions/8.0.1/rules/lib/core/list); default is `[]`  List of toolchain types. The aspect propagates to target toolchains which match these toolchain types. |
+| `attrs` | [dict](/versions/8.0.1/rules/lib/core/dict); default is `{}`  A dictionary declaring all the attributes of the aspect. It maps from an attribute name to an attribute object, like `attr.label` or `attr.string` (see [`attr`](/versions/8.0.1/rules/lib/toplevel/attr) module). Aspect attributes are available to implementation function as fields of `ctx` parameter. Implicit attributes starting with `_` must have default values, and have type `label` or `label_list`.  Explicit attributes must have type `string`, and must use the `values` restriction. Explicit attributes restrict the aspect to only be used with rules that have attributes of the same name, type, and valid values according to the restriction.  Declared attributes will convert `None` to the default value. |
+| `required_providers` | [sequence](/versions/8.0.1/rules/lib/core/list); default is `[]`  This attribute allows the aspect to limit its propagation to only the targets whose rules advertise its required providers. The value must be a list containing either individual providers or lists of providers but not both. For example, `[[FooInfo], [BarInfo], [BazInfo, QuxInfo]]` is a valid value while `[FooInfo, BarInfo, [BazInfo, QuxInfo]]` is not valid. An unnested list of providers will automatically be converted to a list containing one list of providers. That is, `[FooInfo, BarInfo]` will automatically be converted to `[[FooInfo, BarInfo]]`. To make some rule (e.g. `some_rule`) targets visible to an aspect, `some_rule` must advertise all providers from at least one of the required providers lists. For example, if the `required_providers` of an aspect are `[[FooInfo], [BarInfo], [BazInfo, QuxInfo]]`, this aspect can see `some_rule` targets if and only if `some_rule` provides `FooInfo`, *or* `BarInfo`, *or* both `BazInfo` *and* `QuxInfo`. |
+| `required_aspect_providers` | [sequence](/versions/8.0.1/rules/lib/core/list); default is `[]`  This attribute allows this aspect to inspect other aspects. The value must be a list containing either individual providers or lists of providers but not both. For example, `[[FooInfo], [BarInfo], [BazInfo, QuxInfo]]` is a valid value while `[FooInfo, BarInfo, [BazInfo, QuxInfo]]` is not valid. An unnested list of providers will automatically be converted to a list containing one list of providers. That is, `[FooInfo, BarInfo]` will automatically be converted to `[[FooInfo, BarInfo]]`. To make another aspect (e.g. `other_aspect`) visible to this aspect, `other_aspect` must provide all providers from at least one of the lists. In the example of `[[FooInfo], [BarInfo], [BazInfo, QuxInfo]]`, this aspect can see `other_aspect` if and only if `other_aspect` provides `FooInfo`, *or* `BarInfo`, *or* both `BazInfo` *and* `QuxInfo`. |
+| `provides` | [sequence](/versions/8.0.1/rules/lib/core/list); default is `[]`  A list of providers that the implementation function must return. It is an error if the implementation function omits any of the types of providers listed here from its return value. However, the implementation function may return additional providers not listed here. Each element of the list is an `*Info` object returned by [`provider()`](/versions/8.0.1/rules/lib/globals/bzl#provider), except that a legacy provider is represented by its string name instead.When a target of the rule is used as a dependency for a target that declares a required provider, it is not necessary to specify that provider here. It is enough that the implementation function returns it. However, it is considered best practice to specify it, even though this is not required. The [`required_providers`](/versions/8.0.1/rules/lib/globals/bzl#aspect.required_providers) field of an [aspect](/versions/8.0.1/rules/lib/globals/bzl#aspect) does, however, require that providers are specified here. |
+| `requires` | [sequence](/versions/8.0.1/rules/lib/core/list) of [Aspect](/versions/8.0.1/rules/lib/builtins/Aspect)s; default is `[]`  List of aspects required to be propagated before this aspect. |
+| `fragments` | [sequence](/versions/8.0.1/rules/lib/core/list) of [string](/versions/8.0.1/rules/lib/core/string)s; default is `[]`  List of names of configuration fragments that the aspect requires in target configuration. |
+| `host_fragments` | [sequence](/versions/8.0.1/rules/lib/core/list) of [string](/versions/8.0.1/rules/lib/core/string)s; default is `[]`  List of names of configuration fragments that the aspect requires in host configuration. |
+| `toolchains` | [sequence](/versions/8.0.1/rules/lib/core/list); default is `[]`  If set, the set of toolchains this aspect requires. The list can contain String, Label, or StarlarkToolchainTypeApi objects, in any combination. Toolchains will be found by checking the current platform, and provided to the aspect implementation via `ctx.toolchain`. |
+| `incompatible_use_toolchain_transition` | [bool](/versions/8.0.1/rules/lib/core/bool); default is `False`  Deprecated, this is no longer in use and should be removed. |
+| `doc` | [string](/versions/8.0.1/rules/lib/core/string); or `None`; default is `None`  A description of the aspect that can be extracted by documentation generating tools. |
+| `apply_to_generating_rules` | [bool](/versions/8.0.1/rules/lib/core/bool); default is `False`  If true, the aspect will, when applied to an output file, instead apply to the output file's generating rule. For example, suppose an aspect propagates transitively through attribute `deps` and it is applied to target `alpha`. Suppose `alpha` has `deps = [':beta\_output']`, where `beta\_output` is a declared output of a target `beta`. Suppose `beta` has a target `charlie` as one of its `deps`. If `apply\_to\_generating\_rules=True` for the aspect, then the aspect will propagate through `alpha`, `beta`, and `charlie`. If False, then the aspect will propagate only to `alpha`.  False by default. |
+| `exec_compatible_with` | [sequence](/versions/8.0.1/rules/lib/core/list) of [string](/versions/8.0.1/rules/lib/core/string)s; default is `[]`  A list of constraints on the execution platform that apply to all instances of this aspect. |
+| `exec_groups` | [dict](/versions/8.0.1/rules/lib/core/dict); or `None`; default is `None`  Dict of execution group name (string) to [`exec_group`s](/versions/8.0.1/rules/lib/globals/bzl#exec_group). If set, allows aspects to run actions on multiple execution platforms within a single instance. See [execution groups documentation](/versions/8.0.1/reference/exec-groups) for more info. |
+| `subrules` | [sequence](/versions/8.0.1/rules/lib/core/list) of [Subrule](/versions/8.0.1/rules/lib/builtins/Subrule)s; default is `[]`  Experimental: list of subrules used by this aspect. |
 
 ## configuration\_field
 
@@ -74,7 +74,7 @@ Creates a new aspect. The result of this function must be stored in a global val
 LateBoundDefault configuration_field(fragment, name)
 ```
 
-References a late-bound default value for an attribute of type [label](../toplevel/attr#label). A value is 'late-bound' if it requires the configuration to be built before determining the value. Any attribute using this as a value must [be private](https://bazel.build/versions/8.0.1/extending/rules#private-attributes).
+References a late-bound default value for an attribute of type [label](/versions/8.0.1/rules/lib/toplevel/attr#label). A value is 'late-bound' if it requires the configuration to be built before determining the value. Any attribute using this as a value must [be private](https://bazel.build/versions/8.0.1/extending/rules#private-attributes).
 
 Example usage:
 
@@ -96,8 +96,8 @@ Accessing in rule implementation:
 
 | Parameter | Description |
 | --- | --- |
-| `fragment` | [string](../core/string); required |
-| `name` | [string](../core/string); required |
+| `fragment` | [string](/versions/8.0.1/rules/lib/core/string); required |
+| `name` | [string](/versions/8.0.1/rules/lib/core/string); required |
 
 ## depset
 
@@ -105,7 +105,7 @@ Accessing in rule implementation:
 depset depset(direct=None, order="default", *, transitive=None)
 ```
 
-Creates a [depset](../builtins/depset). The `direct` parameter is a list of direct elements of the depset, and `transitive` parameter is a list of depsets whose elements become indirect elements of the created depset. The order in which elements are returned when the depset is converted to a list is specified by the `order` parameter. See the [Depsets overview](https://bazel.build/versions/8.0.1/extending/depsets) for more information.
+Creates a [depset](/versions/8.0.1/rules/lib/builtins/depset). The `direct` parameter is a list of direct elements of the depset, and `transitive` parameter is a list of depsets whose elements become indirect elements of the created depset. The order in which elements are returned when the depset is converted to a list is specified by the `order` parameter. See the [Depsets overview](https://bazel.build/versions/8.0.1/extending/depsets) for more information.
 
 All elements (direct and indirect) of a depset must be of the same type, as obtained by the expression `type(x)`.
 
@@ -119,9 +119,9 @@ The order of the created depset should be *compatible* with the order of its `tr
 
 | Parameter | Description |
 | --- | --- |
-| `direct` | [sequence](../core/list); or `None`; default is `None`  A list of *direct* elements of a depset. |
-| `order` | [string](../core/string); default is `"default"`  The traversal strategy for the new depset. See [here](../builtins/depset) for the possible values. |
-| `transitive` | [sequence](../core/list) of [depset](../builtins/depset)s; or `None`; default is `None`  A list of depsets whose elements will become indirect elements of the depset. |
+| `direct` | [sequence](/versions/8.0.1/rules/lib/core/list); or `None`; default is `None`  A list of *direct* elements of a depset. |
+| `order` | [string](/versions/8.0.1/rules/lib/core/string); default is `"default"`  The traversal strategy for the new depset. See [here](/versions/8.0.1/rules/lib/builtins/depset) for the possible values. |
+| `transitive` | [sequence](/versions/8.0.1/rules/lib/core/list) of [depset](/versions/8.0.1/rules/lib/builtins/depset)s; or `None`; default is `None`  A list of depsets whose elements will become indirect elements of the depset. |
 
 ## exec\_group
 
@@ -135,8 +135,8 @@ Creates an [execution group](/versions/8.0.1/reference/exec-groups) which can be
 
 | Parameter | Description |
 | --- | --- |
-| `toolchains` | [sequence](../core/list); default is `[]`  The set of toolchains this execution group requires. The list can contain String, Label, or StarlarkToolchainTypeApi objects, in any combination. |
-| `exec_compatible_with` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  A list of constraints on the execution platform. |
+| `toolchains` | [sequence](/versions/8.0.1/rules/lib/core/list); default is `[]`  The set of toolchains this execution group requires. The list can contain String, Label, or StarlarkToolchainTypeApi objects, in any combination. |
+| `exec_compatible_with` | [sequence](/versions/8.0.1/rules/lib/core/list) of [string](/versions/8.0.1/rules/lib/core/string)s; default is `[]`  A list of constraints on the execution platform. |
 
 ## exec\_transition
 
@@ -144,15 +144,15 @@ Creates an [execution group](/versions/8.0.1/reference/exec-groups) which can be
 transition exec_transition(implementation, inputs, outputs)
 ```
 
-A specialized version of [`transition()`](../builtins/transition) used to define the exec transition. See its documentation (or its implementation) for best practices. Only usable from the Bazel builtins.
+A specialized version of [`transition()`](/versions/8.0.1/rules/lib/builtins/transition) used to define the exec transition. See its documentation (or its implementation) for best practices. Only usable from the Bazel builtins.
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
 | `implementation` | callable; required |
-| `inputs` | [sequence](../core/list) of [string](../core/string)s; required |
-| `outputs` | [sequence](../core/list) of [string](../core/string)s; required |
+| `inputs` | [sequence](/versions/8.0.1/rules/lib/core/list) of [string](/versions/8.0.1/rules/lib/core/string)s; required |
+| `outputs` | [sequence](/versions/8.0.1/rules/lib/core/list) of [string](/versions/8.0.1/rules/lib/core/string)s; required |
 
 ## macro
 
@@ -173,11 +173,11 @@ macros.
 
 | Parameter | Description |
 | --- | --- |
-| `implementation` | [function](../core/function); required  The Starlark function implementing this macro. The values of the macro's attributes are passed to the implementation function as keyword arguments. The implementation function must have at least two named parameters, `name` and `visibility`, and if the macro inherits attributes (see `inherit_attrs` below), it must have a `**kwargs` residual keyword parameter. By convention, the implementation function should have a named parameter for any attribute that the macro needs to examine, modify, or pass to non-"main" targets, while the "bulk" inherited attributes which will be passed to the "main" target unchanged are passed as `**kwargs`. The implementation function must not return a value. Instead, the implementation function *declares targets* by calling rule or macro symbols. The name of any target or inner symbolic macro declared by a symbolic macro (including by any Starlark function that the macro's implementation function transitively calls) must either equal `name` (this is referred to as the "main" target) or start with `name`, followed by a separator chracter (`"_"`, `"-"`, or `"."`) and a string suffix. (Targets violating this naming scheme are allowed to be declared, but cannot be built, configured, or depended upon.) By default, targets declared by a symbolic macro (including by any Starlark function that the macro's implementation function transitively calls) are visible only in the package containing the .bzl file defining the macro. To declare targets visible externally, *including to the caller of the symbolic macro*, the implementation function must set `visibility` appropriately – typically, by passing `visibility = visibility` to the rule or macro symbol being called. The following APIs are unavailable within a macro implementation function and any Starlark function it transitively calls:  * [`package()`, `licenses()`* `environment_group()`* [`native.glob()`](../toplevel/native#glob) – instead, you may pass       a glob into the macro via a label list attribute* [`native.subpackages()`](../toplevel/native#subpackages)* (allowed in rule finalizers only, see `finalizer` below)           [`native.existing_rules()`](../toplevel/native#existing_rules),           [`native.existing_rule()`](../toplevel/native#existing_rule)* (for `WORKSPACE` threads)             [`workspace()`](../globals/workspace#workspace),             [`register_toolchains()`](../globals/workspace#register_toolchains),             [`bind()`](../globals/workspace#bind), [`register_execution_platforms()`](../globals/workspace#register_execution_platforms), [repository rule instantiation](/versions/8.0.1/reference/be/functions#package) |
-| `attrs` | [dict](../core/dict); default is `{}`  A dictionary of the attributes this macro supports, analogous to [rule.attrs](#rule.attrs). Keys are attribute names, and values are either attribute objects like `attr.label_list(...)` (see the [attr](../toplevel/attr) module), or `None`. A `None` entry means that the macro does not have an attribute by that name, even if it would have otherwise inherited one via `inherit_attrs` (see below). The special `name` attribute is predeclared and must not be included in the dictionary. The `visibility` attribute name is reserved and must not be included in the dictionary. Attributes whose names start with `_` are private -- they cannot be passed at the call site of the rule. Such attributes can be assigned a default value (as in `attr.label(default="//pkg:foo")`) to create an implicit dependency on a label. To limit memory usage, there is a cap on the number of attributes that may be declared. |
-| `inherit_attrs` | [rule](../builtins/rule); or [macro](../builtins/macro); or [string](../core/string); or `None`; default is `None`  A rule symbol, macro symbol, or the name of a built-in common attribute list (see below) from which the macro should inherit attributes. If `inherit_attrs` is set to the string `"common"`, the macro will inherit [common rule attribute definitions](/versions/8.0.1/reference/be/common-definitions#common-attributes) used by all Starlark rules. Note that if the return value of `rule()` or `macro()` was not assigned to a global variable in a .bzl file, then such a value has not been registered as a rule or macro symbol, and therefore cannot be used for `inherit_attrs`. The inheritance mechanism works as follows:   1. The special `name` and `visibility` attributes are never inherited;- Hidden attributes (ones whose name starts with `"_"`) are never inherited;- Attributes whose names are already defined in the `attrs` dictionary are never        inherited (the entry in `attrs` takes precedence; note that an entry may be set to        `None` to ensure that no attribute by that name gets defined on the macro);- All other attributes are inherited from the rule or macro and effectively merged into the          `attrs` dict.   When a non-mandatory attribute is inherited, the default value of the attribute is overridden to be `None`, regardless of what it was specified in the original rule or macro. This ensures that when the macro forwards the attribute's value to an instance of the wrapped rule or macro – such as by passing in the unmodified `**kwargs` – a value that was absent from the outer macro's call will also be absent in the inner rule or macro's call (since passing `None` to an attribute is treated the same as omitting the attribute). This is important because omitting an attribute has subtly different semantics from passing its apparent default value. In particular, omitted attributes are not shown in some `bazel query` output formats, and computed defaults only execute when the value is omitted. If the macro needs to examine or modify an inherited attribute – for example, to add a value to an inherited `tags` attribute – you must make sure to handle the `None` case in the macro's implementation function. For example, the following macro inherits all attributes from `native.cc_library`, except for `cxxopts` (which is removed from the attribute list) and `copts` (which is given a new definition). It also takes care to checks for the default `None` value of the inherited `tags` attribute before appending an additional tag.  ``` def _my_cc_library_impl(name, visibility, tags, **kwargs):     # Append a tag; tags attr was inherited from native.cc_library, and     # therefore is None unless explicitly set by the caller of my_cc_library()     my_tags = (tags or []) + ["my_custom_tag"]     native.cc_library(         name = name,         visibility = visibility,         tags = my_tags,         **kwargs     )  my_cc_library = macro(     implementation = _my_cc_library_impl,     inherit_attrs = native.cc_library,     attrs = {         "cxxopts": None,         "copts": attr.string_list(default = ["-D_FOO"]),     }, ) ```   If `inherit_attrs` is set, the macro's implementation function *must* have a `**kwargs` residual keyword parameter. By convention, a macro should pass inherited, non-overridden attributes unchanged to the "main" rule or macro symbol which the macro is wrapping. Typically, most inherited attributes will not have a parameter in the implementation function's parameter list, and will simply be passed via `**kwargs`. It can be convenient for the implementation function to have explicit parameters for some inherited attributes (most commonly, `tags` and `testonly`) if the macro needs to pass those attributes to both "main" and non-"main" targets – but if the macro also needs to examine or manipulate those attributes, you must take care to handle the `None` default value of non-mandatory inherited attributes. |
-| `finalizer` | [bool](../core/bool); default is `False`  Whether this macro is a rule finalizer, which is a macro that, regardless of its position in a `BUILD` file, is evaluated at the end of package loading, after all non-finalizer targets have been defined. Unlike ordinary symbolic macros, rule finalizers may call [`native.existing_rule()`](../toplevel/native#existing_rule) and [`native.existing_rules()`](../toplevel/native#existing_rules) to query the set of *non-finalizer* rule targets defined in the current package. Note that `native.existing_rule()` and `native.existing_rules()` cannot access the targets defined by any rule finalizer, including this one. |
-| `doc` | [string](../core/string); or `None`; default is `None`  A description of the macro that can be extracted by documentation generating tools. |
+| `implementation` | [function](/versions/8.0.1/rules/lib/core/function); required  The Starlark function implementing this macro. The values of the macro's attributes are passed to the implementation function as keyword arguments. The implementation function must have at least two named parameters, `name` and `visibility`, and if the macro inherits attributes (see `inherit_attrs` below), it must have a `**kwargs` residual keyword parameter. By convention, the implementation function should have a named parameter for any attribute that the macro needs to examine, modify, or pass to non-"main" targets, while the "bulk" inherited attributes which will be passed to the "main" target unchanged are passed as `**kwargs`. The implementation function must not return a value. Instead, the implementation function *declares targets* by calling rule or macro symbols. The name of any target or inner symbolic macro declared by a symbolic macro (including by any Starlark function that the macro's implementation function transitively calls) must either equal `name` (this is referred to as the "main" target) or start with `name`, followed by a separator chracter (`"_"`, `"-"`, or `"."`) and a string suffix. (Targets violating this naming scheme are allowed to be declared, but cannot be built, configured, or depended upon.) By default, targets declared by a symbolic macro (including by any Starlark function that the macro's implementation function transitively calls) are visible only in the package containing the .bzl file defining the macro. To declare targets visible externally, *including to the caller of the symbolic macro*, the implementation function must set `visibility` appropriately – typically, by passing `visibility = visibility` to the rule or macro symbol being called. The following APIs are unavailable within a macro implementation function and any Starlark function it transitively calls:  * [`package()`, `licenses()`* `environment_group()`* [`native.glob()`](/versions/8.0.1/rules/lib/toplevel/native#glob) – instead, you may pass       a glob into the macro via a label list attribute* [`native.subpackages()`](/versions/8.0.1/rules/lib/toplevel/native#subpackages)* (allowed in rule finalizers only, see `finalizer` below)           [`native.existing_rules()`](/versions/8.0.1/rules/lib/toplevel/native#existing_rules),           [`native.existing_rule()`](/versions/8.0.1/rules/lib/toplevel/native#existing_rule)* (for `WORKSPACE` threads)             [`workspace()`](/versions/8.0.1/rules/lib/globals/workspace#workspace),             [`register_toolchains()`](/versions/8.0.1/rules/lib/globals/workspace#register_toolchains),             [`bind()`](/versions/8.0.1/rules/lib/globals/workspace#bind), [`register_execution_platforms()`](/versions/8.0.1/rules/lib/globals/workspace#register_execution_platforms), [repository rule instantiation](/versions/8.0.1/reference/be/functions#package) |
+| `attrs` | [dict](/versions/8.0.1/rules/lib/core/dict); default is `{}`  A dictionary of the attributes this macro supports, analogous to [rule.attrs](#rule.attrs). Keys are attribute names, and values are either attribute objects like `attr.label_list(...)` (see the [attr](/versions/8.0.1/rules/lib/toplevel/attr) module), or `None`. A `None` entry means that the macro does not have an attribute by that name, even if it would have otherwise inherited one via `inherit_attrs` (see below). The special `name` attribute is predeclared and must not be included in the dictionary. The `visibility` attribute name is reserved and must not be included in the dictionary. Attributes whose names start with `_` are private -- they cannot be passed at the call site of the rule. Such attributes can be assigned a default value (as in `attr.label(default="//pkg:foo")`) to create an implicit dependency on a label. To limit memory usage, there is a cap on the number of attributes that may be declared. |
+| `inherit_attrs` | [rule](/versions/8.0.1/rules/lib/builtins/rule); or [macro](/versions/8.0.1/rules/lib/builtins/macro); or [string](/versions/8.0.1/rules/lib/core/string); or `None`; default is `None`  A rule symbol, macro symbol, or the name of a built-in common attribute list (see below) from which the macro should inherit attributes. If `inherit_attrs` is set to the string `"common"`, the macro will inherit [common rule attribute definitions](/versions/8.0.1/reference/be/common-definitions#common-attributes) used by all Starlark rules. Note that if the return value of `rule()` or `macro()` was not assigned to a global variable in a .bzl file, then such a value has not been registered as a rule or macro symbol, and therefore cannot be used for `inherit_attrs`. The inheritance mechanism works as follows:   1. The special `name` and `visibility` attributes are never inherited;- Hidden attributes (ones whose name starts with `"_"`) are never inherited;- Attributes whose names are already defined in the `attrs` dictionary are never        inherited (the entry in `attrs` takes precedence; note that an entry may be set to        `None` to ensure that no attribute by that name gets defined on the macro);- All other attributes are inherited from the rule or macro and effectively merged into the          `attrs` dict.   When a non-mandatory attribute is inherited, the default value of the attribute is overridden to be `None`, regardless of what it was specified in the original rule or macro. This ensures that when the macro forwards the attribute's value to an instance of the wrapped rule or macro – such as by passing in the unmodified `**kwargs` – a value that was absent from the outer macro's call will also be absent in the inner rule or macro's call (since passing `None` to an attribute is treated the same as omitting the attribute). This is important because omitting an attribute has subtly different semantics from passing its apparent default value. In particular, omitted attributes are not shown in some `bazel query` output formats, and computed defaults only execute when the value is omitted. If the macro needs to examine or modify an inherited attribute – for example, to add a value to an inherited `tags` attribute – you must make sure to handle the `None` case in the macro's implementation function. For example, the following macro inherits all attributes from `native.cc_library`, except for `cxxopts` (which is removed from the attribute list) and `copts` (which is given a new definition). It also takes care to checks for the default `None` value of the inherited `tags` attribute before appending an additional tag.  ``` def _my_cc_library_impl(name, visibility, tags, **kwargs):     # Append a tag; tags attr was inherited from native.cc_library, and     # therefore is None unless explicitly set by the caller of my_cc_library()     my_tags = (tags or []) + ["my_custom_tag"]     native.cc_library(         name = name,         visibility = visibility,         tags = my_tags,         **kwargs     )  my_cc_library = macro(     implementation = _my_cc_library_impl,     inherit_attrs = native.cc_library,     attrs = {         "cxxopts": None,         "copts": attr.string_list(default = ["-D_FOO"]),     }, ) ```   If `inherit_attrs` is set, the macro's implementation function *must* have a `**kwargs` residual keyword parameter. By convention, a macro should pass inherited, non-overridden attributes unchanged to the "main" rule or macro symbol which the macro is wrapping. Typically, most inherited attributes will not have a parameter in the implementation function's parameter list, and will simply be passed via `**kwargs`. It can be convenient for the implementation function to have explicit parameters for some inherited attributes (most commonly, `tags` and `testonly`) if the macro needs to pass those attributes to both "main" and non-"main" targets – but if the macro also needs to examine or manipulate those attributes, you must take care to handle the `None` default value of non-mandatory inherited attributes. |
+| `finalizer` | [bool](/versions/8.0.1/rules/lib/core/bool); default is `False`  Whether this macro is a rule finalizer, which is a macro that, regardless of its position in a `BUILD` file, is evaluated at the end of package loading, after all non-finalizer targets have been defined. Unlike ordinary symbolic macros, rule finalizers may call [`native.existing_rule()`](/versions/8.0.1/rules/lib/toplevel/native#existing_rule) and [`native.existing_rules()`](/versions/8.0.1/rules/lib/toplevel/native#existing_rules) to query the set of *non-finalizer* rule targets defined in the current package. Note that `native.existing_rule()` and `native.existing_rules()` cannot access the targets defined by any rule finalizer, including this one. |
+| `doc` | [string](/versions/8.0.1/rules/lib/core/string); or `None`; default is `None`  A description of the macro that can be extracted by documentation generating tools. |
 
 ## module\_extension
 
@@ -192,11 +192,11 @@ Creates a new module extension. Store it in a global value, so that it can be ex
 | Parameter | Description |
 | --- | --- |
 | `implementation` | callable; required  The function that implements this module extension. Must take a single parameter, `module_ctx`. The function is called once at the beginning of a build to determine the set of available repos. |
-| `tag_classes` | [dict](../core/dict); default is `{}`  A dictionary to declare all the tag classes used by the extension. It maps from the name of the tag class to a `tag_class` object. |
-| `doc` | [string](../core/string); or `None`; default is `None`  A description of the module extension that can be extracted by documentation generating tools. |
-| `environ` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  Provides a list of environment variable that this module extension depends on. If an environment variable in that list changes, the extension will be re-evaluated. |
-| `os_dependent` | [bool](../core/bool); default is `False`  Indicates whether this extension is OS-dependent or not |
-| `arch_dependent` | [bool](../core/bool); default is `False`  Indicates whether this extension is architecture-dependent or not |
+| `tag_classes` | [dict](/versions/8.0.1/rules/lib/core/dict); default is `{}`  A dictionary to declare all the tag classes used by the extension. It maps from the name of the tag class to a `tag_class` object. |
+| `doc` | [string](/versions/8.0.1/rules/lib/core/string); or `None`; default is `None`  A description of the module extension that can be extracted by documentation generating tools. |
+| `environ` | [sequence](/versions/8.0.1/rules/lib/core/list) of [string](/versions/8.0.1/rules/lib/core/string)s; default is `[]`  Provides a list of environment variable that this module extension depends on. If an environment variable in that list changes, the extension will be re-evaluated. |
+| `os_dependent` | [bool](/versions/8.0.1/rules/lib/core/bool); default is `False`  Indicates whether this extension is OS-dependent or not |
+| `arch_dependent` | [bool](/versions/8.0.1/rules/lib/core/bool); default is `False`  Indicates whether this extension is architecture-dependent or not |
 
 ## provider
 
@@ -219,16 +219,16 @@ def _my_library_impl(ctx):
 
 See [Rules (Providers)](https://bazel.build/versions/8.0.1/extending/rules#providers) for a comprehensive guide on how to use providers.
 
-Returns a [`Provider`](../builtins/Provider) callable value if `init` is not specified.
+Returns a [`Provider`](/versions/8.0.1/rules/lib/builtins/Provider) callable value if `init` is not specified.
 
-If `init` is specified, returns a tuple of 2 elements: a [`Provider`](../builtins/Provider) callable value and a *raw constructor* callable value. See  [Rules (Custom initialization of custom providers)](https://bazel.build/versions/8.0.1/extending/rules#custom_initialization_of_providers) and the discussion of the `init` parameter below for details.
+If `init` is specified, returns a tuple of 2 elements: a [`Provider`](/versions/8.0.1/rules/lib/builtins/Provider) callable value and a *raw constructor* callable value. See  [Rules (Custom initialization of custom providers)](https://bazel.build/versions/8.0.1/extending/rules#custom_initialization_of_providers) and the discussion of the `init` parameter below for details.
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `doc` | [string](../core/string); or `None`; default is `None` |
-| `fields` | [sequence](../core/list) of [string](../core/string)s; or [dict](../core/dict); or `None`; default is `None`  If specified, restricts the set of allowed fields.  Possible values are:  * list of fields:     ```   provider(fields = ['a', 'b'])   ```     * dictionary field name -> documentation:       ```     provider(            fields = { 'a' : 'Documentation for a', 'b' : 'Documentation for b' })     ```  All fields are optional. |
+| `doc` | [string](/versions/8.0.1/rules/lib/core/string); or `None`; default is `None` |
+| `fields` | [sequence](/versions/8.0.1/rules/lib/core/list) of [string](/versions/8.0.1/rules/lib/core/string)s; or [dict](/versions/8.0.1/rules/lib/core/dict); or `None`; default is `None`  If specified, restricts the set of allowed fields.  Possible values are:  * list of fields:     ```   provider(fields = ['a', 'b'])   ```     * dictionary field name -> documentation:       ```     provider(            fields = { 'a' : 'Documentation for a', 'b' : 'Documentation for b' })     ```  All fields are optional. |
 | `init` | callable; or `None`; default is `None` |
 
 ## repository\_rule
@@ -237,19 +237,19 @@ If `init` is specified, returns a tuple of 2 elements: a [`Provider`](../builtin
 callable repository_rule(implementation, *, attrs=None, local=False, environ=[], configure=False, remotable=False, doc=None)
 ```
 
-Creates a new repository rule. Store it in a global value, so that it can be loaded and called from a [`module_extension()`](#module_extension) implementation function, or used by [`use_repo_rule()`](../globals/module#use_repo_rule).
+Creates a new repository rule. Store it in a global value, so that it can be loaded and called from a [`module_extension()`](#module_extension) implementation function, or used by [`use_repo_rule()`](/versions/8.0.1/rules/lib/globals/module#use_repo_rule).
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
 | `implementation` | callable; required |
-| `attrs` | [dict](../core/dict); or `None`; default is `None` |
-| `local` | [bool](../core/bool); default is `False`  Indicate that this rule fetches everything from the local system and should be reevaluated at every fetch. |
-| `environ` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  **Deprecated**. This parameter has been deprecated. Migrate to `repository_ctx.getenv` instead. Provides a list of environment variable that this repository rule depends on. If an environment variable in that list change, the repository will be refetched. |
-| `configure` | [bool](../core/bool); default is `False`  Indicate that the repository inspects the system for configuration purpose |
-| `remotable` | [bool](../core/bool); default is `False`  **Experimental**. This parameter is experimental and may change at any time. Please do not depend on it. It may be enabled on an experimental basis by setting `--experimental_repo_remote_exec`  Compatible with remote execution |
-| `doc` | [string](../core/string); or `None`; default is `None` |
+| `attrs` | [dict](/versions/8.0.1/rules/lib/core/dict); or `None`; default is `None` |
+| `local` | [bool](/versions/8.0.1/rules/lib/core/bool); default is `False`  Indicate that this rule fetches everything from the local system and should be reevaluated at every fetch. |
+| `environ` | [sequence](/versions/8.0.1/rules/lib/core/list) of [string](/versions/8.0.1/rules/lib/core/string)s; default is `[]`  **Deprecated**. This parameter has been deprecated. Migrate to `repository_ctx.getenv` instead. Provides a list of environment variable that this repository rule depends on. If an environment variable in that list change, the repository will be refetched. |
+| `configure` | [bool](/versions/8.0.1/rules/lib/core/bool); default is `False`  Indicate that the repository inspects the system for configuration purpose |
+| `remotable` | [bool](/versions/8.0.1/rules/lib/core/bool); default is `False`  **Experimental**. This parameter is experimental and may change at any time. Please do not depend on it. It may be enabled on an experimental basis by setting `--experimental_repo_remote_exec`  Compatible with remote execution |
+| `doc` | [string](/versions/8.0.1/rules/lib/core/string); or `None`; default is `None` |
 
 ## rule
 
@@ -267,29 +267,29 @@ Test rules are required to have a name ending in `_test`, while all other rules
 
 | Parameter | Description |
 | --- | --- |
-| `implementation` | [function](../core/function); required  the Starlark function implementing this rule, must have exactly one parameter: [ctx](../builtins/ctx). The function is called during the analysis phase for each instance of the rule. It can access the attributes provided by the user. It must create actions to generate all the declared outputs. |
-| `test` | [bool](../core/bool); default is `unbound`  Whether this rule is a test rule, that is, whether it may be the subject of a `blaze test` command. All test rules are automatically considered [executable](#rule.executable); it is unnecessary (and discouraged) to explicitly set `executable = True` for a test rule. The value defaults to `False`. See the  [Rules page](https://bazel.build/versions/8.0.1/extending/rules#executable_rules_and_test_rules) for more information. |
-| `attrs` | [dict](../core/dict); default is `{}`  A dictionary to declare all the attributes of the rule. It maps from an attribute name to an attribute object (see [`attr`](../toplevel/attr) module). Attributes starting with `_` are private, and can be used to add an implicit dependency on a label. The attribute `name` is implicitly added and must not be specified. Attributes `visibility`, `deprecation`, `tags`, `testonly`, and `features` are implicitly added and cannot be overridden. Most rules need only a handful of attributes. To limit memory usage, there is a cap on the number of attributes that may be declared. Declared attributes will convert `None` to the default value. |
-| `outputs` | [dict](../core/dict); or `None`; or [function](../core/function); default is `None`  **Deprecated**. This parameter is deprecated and will be removed soon. Please do not depend on it. It is *disabled* with `--incompatible_no_rule_outputs_param`. Use this flag to verify your code is compatible with its imminent removal.  This parameter has been deprecated. Migrate rules to use `OutputGroupInfo` or `attr.output` instead. A schema for defining predeclared outputs. Unlike [`output`](../toplevel/attr#output) and [`output_list`](../toplevel/attr#output_list) attributes, the user does not specify the labels for these files. See the [Rules page](https://bazel.build/versions/8.0.1/extending/rules#files) for more on predeclared outputs. The value of this argument is either a dictionary or a callback function that produces a dictionary. The callback works similar to computed dependency attributes: The function's parameter names are matched against the rule's attributes, so for example if you pass `outputs = _my_func` with the definition `def _my_func(srcs, deps): ...`, the function has access to the attributes `srcs` and `deps`. Whether the dictionary is specified directly or via a function, it is interpreted as follows. Each entry in the dictionary creates a predeclared output where the key is an identifier and the value is a string template that determines the output's label. In the rule's implementation function, the identifier becomes the field name used to access the output's [`File`](../builtins/File) in [`ctx.outputs`](../builtins/ctx#outputs). The output's label has the same package as the rule, and the part after the package is produced by substituting each placeholder of the form `"%{ATTR}"` with a string formed from the value of the attribute `ATTR`:  * String-typed attributes are substituted verbatim.* Label-typed attributes become the part of the label after the package, minus the file extension. For example, the label `"//pkg:a/b.c"` becomes `"a/b"`.* Output-typed attributes become the part of the label after the package, including the file extension (for the above example, `"a/b.c"`).* All list-typed attributes (for example, `attr.label_list`) used in placeholders are required to have *exactly one element*. Their conversion is the same as their non-list version (`attr.label`).* Other attribute types may not appear in placeholders.* The special non-attribute placeholders `%{dirname}` and `%{basename}` expand to those parts of the rule's label, excluding its package. For example, in `"//pkg:a/b.c"`, the dirname is `a` and the basename is `b.c`.   In practice, the most common substitution placeholder is `"%{name}"`. For example, for a target named "foo", the outputs dict `{"bin": "%{name}.exe"}` predeclares an output named `foo.exe` that is accessible in the implementation function as `ctx.outputs.bin`. |
-| `executable` | [bool](../core/bool); default is `unbound` |
-| `output_to_genfiles` | [bool](../core/bool); default is `False`  If true, the files will be generated in the genfiles directory instead of the bin directory. Unless you need it for compatibility with existing rules (e.g. when generating header files for C++), do not set this flag. |
-| `fragments` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  List of names of configuration fragments that the rule requires in target configuration. |
-| `host_fragments` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  List of names of configuration fragments that the rule requires in host configuration. |
-| `_skylark_testable` | [bool](../core/bool); default is `False`  *(Experimental)*  If true, this rule will expose its actions for inspection by rules that depend on it via an `Actions` provider. The provider is also available to the rule itself by calling [ctx.created\_actions()](../builtins/ctx#created_actions).  This should only be used for testing the analysis-time behavior of Starlark rules. This flag may be removed in the future. |
-| `toolchains` | [sequence](../core/list); default is `[]`  If set, the set of toolchains this rule requires. The list can contain String, Label, or StarlarkToolchainTypeApi objects, in any combination. Toolchains will be found by checking the current platform, and provided to the rule implementation via `ctx.toolchain`. |
-| `incompatible_use_toolchain_transition` | [bool](../core/bool); default is `False`  Deprecated, this is no longer in use and should be removed. |
-| `doc` | [string](../core/string); or `None`; default is `None`  A description of the rule that can be extracted by documentation generating tools. |
-| `provides` | [sequence](../core/list); default is `[]`  A list of providers that the implementation function must return. It is an error if the implementation function omits any of the types of providers listed here from its return value. However, the implementation function may return additional providers not listed here. Each element of the list is an `*Info` object returned by [`provider()`](../globals/bzl#provider), except that a legacy provider is represented by its string name instead.When a target of the rule is used as a dependency for a target that declares a required provider, it is not necessary to specify that provider here. It is enough that the implementation function returns it. However, it is considered best practice to specify it, even though this is not required. The [`required_providers`](../globals/bzl#aspect.required_providers) field of an [aspect](../globals/bzl#aspect) does, however, require that providers are specified here. |
-| `dependency_resolution_rule` | [bool](../core/bool); default is `False`  If set, the rule can be a dependency through attributes also marked as available in materializers. Every attribute of rules with this flag set must be marked as available in materializers also. This is so that rules so marked cannot depend on rules that are not so marked. |
-| `exec_compatible_with` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  A list of constraints on the execution platform that apply to all targets of this rule type. |
-| `analysis_test` | [bool](../core/bool); default is `False`  If true, then this rule is treated as an analysis test. Note: Analysis test rules are primarily defined using infrastructure provided in core Starlark libraries. See [Testing](https://bazel.build/versions/8.0.1/rules/testing#testing-rules) for guidance. If a rule is defined as an analysis test rule, it becomes allowed to use configuration transitions defined using [analysis\_test\_transition](#analysis_test_transition) on its attributes, but opts into some restrictions:  * Targets of this rule are limited in the number of transitive dependencies they may have.* The rule is considered a test rule (as if `test=True` were set). This supersedes the value of `test`   * The rule implementation function may not register actions. Instead, it must register a pass/fail result via providing [AnalysisTestResultInfo](../providers/AnalysisTestResultInfo). |
-| `build_setting` | [BuildSetting](../builtins/BuildSetting); or `None`; default is `None`  If set, describes what kind of [`build setting`](/versions/8.0.1/rules/config#user-defined-build-settings) this rule is. See the [`config`](../toplevel/config) module. If this is set, a mandatory attribute named "build\_setting\_default" is automatically added to this rule, with a type corresponding to the value passed in here. |
+| `implementation` | [function](/versions/8.0.1/rules/lib/core/function); required  the Starlark function implementing this rule, must have exactly one parameter: [ctx](/versions/8.0.1/rules/lib/builtins/ctx). The function is called during the analysis phase for each instance of the rule. It can access the attributes provided by the user. It must create actions to generate all the declared outputs. |
+| `test` | [bool](/versions/8.0.1/rules/lib/core/bool); default is `unbound`  Whether this rule is a test rule, that is, whether it may be the subject of a `blaze test` command. All test rules are automatically considered [executable](#rule.executable); it is unnecessary (and discouraged) to explicitly set `executable = True` for a test rule. The value defaults to `False`. See the  [Rules page](https://bazel.build/versions/8.0.1/extending/rules#executable_rules_and_test_rules) for more information. |
+| `attrs` | [dict](/versions/8.0.1/rules/lib/core/dict); default is `{}`  A dictionary to declare all the attributes of the rule. It maps from an attribute name to an attribute object (see [`attr`](/versions/8.0.1/rules/lib/toplevel/attr) module). Attributes starting with `_` are private, and can be used to add an implicit dependency on a label. The attribute `name` is implicitly added and must not be specified. Attributes `visibility`, `deprecation`, `tags`, `testonly`, and `features` are implicitly added and cannot be overridden. Most rules need only a handful of attributes. To limit memory usage, there is a cap on the number of attributes that may be declared. Declared attributes will convert `None` to the default value. |
+| `outputs` | [dict](/versions/8.0.1/rules/lib/core/dict); or `None`; or [function](/versions/8.0.1/rules/lib/core/function); default is `None`  **Deprecated**. This parameter is deprecated and will be removed soon. Please do not depend on it. It is *disabled* with `--incompatible_no_rule_outputs_param`. Use this flag to verify your code is compatible with its imminent removal.  This parameter has been deprecated. Migrate rules to use `OutputGroupInfo` or `attr.output` instead. A schema for defining predeclared outputs. Unlike [`output`](/versions/8.0.1/rules/lib/toplevel/attr#output) and [`output_list`](/versions/8.0.1/rules/lib/toplevel/attr#output_list) attributes, the user does not specify the labels for these files. See the [Rules page](https://bazel.build/versions/8.0.1/extending/rules#files) for more on predeclared outputs. The value of this argument is either a dictionary or a callback function that produces a dictionary. The callback works similar to computed dependency attributes: The function's parameter names are matched against the rule's attributes, so for example if you pass `outputs = _my_func` with the definition `def _my_func(srcs, deps): ...`, the function has access to the attributes `srcs` and `deps`. Whether the dictionary is specified directly or via a function, it is interpreted as follows. Each entry in the dictionary creates a predeclared output where the key is an identifier and the value is a string template that determines the output's label. In the rule's implementation function, the identifier becomes the field name used to access the output's [`File`](/versions/8.0.1/rules/lib/builtins/File) in [`ctx.outputs`](/versions/8.0.1/rules/lib/builtins/ctx#outputs). The output's label has the same package as the rule, and the part after the package is produced by substituting each placeholder of the form `"%{ATTR}"` with a string formed from the value of the attribute `ATTR`:  * String-typed attributes are substituted verbatim.* Label-typed attributes become the part of the label after the package, minus the file extension. For example, the label `"//pkg:a/b.c"` becomes `"a/b"`.* Output-typed attributes become the part of the label after the package, including the file extension (for the above example, `"a/b.c"`).* All list-typed attributes (for example, `attr.label_list`) used in placeholders are required to have *exactly one element*. Their conversion is the same as their non-list version (`attr.label`).* Other attribute types may not appear in placeholders.* The special non-attribute placeholders `%{dirname}` and `%{basename}` expand to those parts of the rule's label, excluding its package. For example, in `"//pkg:a/b.c"`, the dirname is `a` and the basename is `b.c`.   In practice, the most common substitution placeholder is `"%{name}"`. For example, for a target named "foo", the outputs dict `{"bin": "%{name}.exe"}` predeclares an output named `foo.exe` that is accessible in the implementation function as `ctx.outputs.bin`. |
+| `executable` | [bool](/versions/8.0.1/rules/lib/core/bool); default is `unbound` |
+| `output_to_genfiles` | [bool](/versions/8.0.1/rules/lib/core/bool); default is `False`  If true, the files will be generated in the genfiles directory instead of the bin directory. Unless you need it for compatibility with existing rules (e.g. when generating header files for C++), do not set this flag. |
+| `fragments` | [sequence](/versions/8.0.1/rules/lib/core/list) of [string](/versions/8.0.1/rules/lib/core/string)s; default is `[]`  List of names of configuration fragments that the rule requires in target configuration. |
+| `host_fragments` | [sequence](/versions/8.0.1/rules/lib/core/list) of [string](/versions/8.0.1/rules/lib/core/string)s; default is `[]`  List of names of configuration fragments that the rule requires in host configuration. |
+| `_skylark_testable` | [bool](/versions/8.0.1/rules/lib/core/bool); default is `False`  *(Experimental)*  If true, this rule will expose its actions for inspection by rules that depend on it via an `Actions` provider. The provider is also available to the rule itself by calling [ctx.created\_actions()](/versions/8.0.1/rules/lib/builtins/ctx#created_actions).  This should only be used for testing the analysis-time behavior of Starlark rules. This flag may be removed in the future. |
+| `toolchains` | [sequence](/versions/8.0.1/rules/lib/core/list); default is `[]`  If set, the set of toolchains this rule requires. The list can contain String, Label, or StarlarkToolchainTypeApi objects, in any combination. Toolchains will be found by checking the current platform, and provided to the rule implementation via `ctx.toolchain`. |
+| `incompatible_use_toolchain_transition` | [bool](/versions/8.0.1/rules/lib/core/bool); default is `False`  Deprecated, this is no longer in use and should be removed. |
+| `doc` | [string](/versions/8.0.1/rules/lib/core/string); or `None`; default is `None`  A description of the rule that can be extracted by documentation generating tools. |
+| `provides` | [sequence](/versions/8.0.1/rules/lib/core/list); default is `[]`  A list of providers that the implementation function must return. It is an error if the implementation function omits any of the types of providers listed here from its return value. However, the implementation function may return additional providers not listed here. Each element of the list is an `*Info` object returned by [`provider()`](/versions/8.0.1/rules/lib/globals/bzl#provider), except that a legacy provider is represented by its string name instead.When a target of the rule is used as a dependency for a target that declares a required provider, it is not necessary to specify that provider here. It is enough that the implementation function returns it. However, it is considered best practice to specify it, even though this is not required. The [`required_providers`](/versions/8.0.1/rules/lib/globals/bzl#aspect.required_providers) field of an [aspect](/versions/8.0.1/rules/lib/globals/bzl#aspect) does, however, require that providers are specified here. |
+| `dependency_resolution_rule` | [bool](/versions/8.0.1/rules/lib/core/bool); default is `False`  If set, the rule can be a dependency through attributes also marked as available in materializers. Every attribute of rules with this flag set must be marked as available in materializers also. This is so that rules so marked cannot depend on rules that are not so marked. |
+| `exec_compatible_with` | [sequence](/versions/8.0.1/rules/lib/core/list) of [string](/versions/8.0.1/rules/lib/core/string)s; default is `[]`  A list of constraints on the execution platform that apply to all targets of this rule type. |
+| `analysis_test` | [bool](/versions/8.0.1/rules/lib/core/bool); default is `False`  If true, then this rule is treated as an analysis test. Note: Analysis test rules are primarily defined using infrastructure provided in core Starlark libraries. See [Testing](https://bazel.build/versions/8.0.1/rules/testing#testing-rules) for guidance. If a rule is defined as an analysis test rule, it becomes allowed to use configuration transitions defined using [analysis\_test\_transition](#analysis_test_transition) on its attributes, but opts into some restrictions:  * Targets of this rule are limited in the number of transitive dependencies they may have.* The rule is considered a test rule (as if `test=True` were set). This supersedes the value of `test`   * The rule implementation function may not register actions. Instead, it must register a pass/fail result via providing [AnalysisTestResultInfo](/versions/8.0.1/rules/lib/providers/AnalysisTestResultInfo). |
+| `build_setting` | [BuildSetting](/versions/8.0.1/rules/lib/builtins/BuildSetting); or `None`; default is `None`  If set, describes what kind of [`build setting`](/versions/8.0.1/rules/config#user-defined-build-settings) this rule is. See the [`config`](/versions/8.0.1/rules/lib/toplevel/config) module. If this is set, a mandatory attribute named "build\_setting\_default" is automatically added to this rule, with a type corresponding to the value passed in here. |
 | `cfg` | default is `None`  If set, points to the configuration transition the rule will apply to its own configuration before analysis. |
-| `exec_groups` | [dict](../core/dict); or `None`; default is `None`  Dict of execution group name (string) to [`exec_group`s](../globals/bzl#exec_group). If set, allows rules to run actions on multiple execution platforms within a single target. See [execution groups documentation](/versions/8.0.1/reference/exec-groups) for more info. |
+| `exec_groups` | [dict](/versions/8.0.1/rules/lib/core/dict); or `None`; default is `None`  Dict of execution group name (string) to [`exec_group`s](/versions/8.0.1/rules/lib/globals/bzl#exec_group). If set, allows rules to run actions on multiple execution platforms within a single target. See [execution groups documentation](/versions/8.0.1/reference/exec-groups) for more info. |
 | `initializer` | default is `None`  Experimental: the Stalark function initializing the attributes of the rule. The function is called at load time for each instance of the rule. It's called with `name` and the values of public attributes defined by the rule (not with generic attributes, for example `tags`). It has to return a dictionary from the attribute names to the desired values. The attributes that are not returned are unaffected. Returning `None` as value results in using the default value specified in the attribute definition. Initializers are evaluated before the default values specified in an attribute definition. Consequently, if a parameter in the initializer's signature contains a default values, it overwrites the default from the attribute definition (except if returning `None`). Similarly, if a parameter in the initializer's signature doesn't have a default, the parameter will become mandatory. It's a good practice to omit default/mandatory settings on an attribute definition in such cases. It's a good practice to use `**kwargs` for attributes that are not handled. In case of extended rules, all initializers are called proceeding from child to ancestors. Each initializer is passed only the public attributes it knows about. |
 | `parent` | default is `None`  Experimental: the Stalark rule that is extended. When set the public attributes are merged as well as advertised providers. The rule matches `executable` and `test` from the parent. Values of `fragments`, `toolchains`, `exec_compatible_with`, and `exec_groups` are merged. Legacy or deprecated parameters may not be set. Incoming configuration transition `cfg` of parent is applied after thisrule's incoming configuration. |
-| `extendable` | [bool](../core/bool); or [Label](../builtins/Label); or [string](../core/string); or `None`; default is `None`  Experimental: A label of an allowlist defining which rules can extending this rule. It can be set also to True/False to always allow/disallow extending. Bazel defaults to always allowing extensions. |
-| `subrules` | [sequence](../core/list) of [Subrule](../builtins/Subrule)s; default is `[]`  Experimental: List of subrules used by this rule. |
+| `extendable` | [bool](/versions/8.0.1/rules/lib/core/bool); or [Label](/versions/8.0.1/rules/lib/builtins/Label); or [string](/versions/8.0.1/rules/lib/core/string); or `None`; default is `None`  Experimental: A label of an allowlist defining which rules can extending this rule. It can be set also to True/False to always allow/disallow extending. Bazel defaults to always allowing extensions. |
+| `subrules` | [sequence](/versions/8.0.1/rules/lib/core/list) of [Subrule](/versions/8.0.1/rules/lib/builtins/Subrule)s; default is `[]`  Experimental: List of subrules used by this rule. |
 
 ## select
 
@@ -303,8 +303,8 @@ unknown select(x, no_match_error='')
 
 | Parameter | Description |
 | --- | --- |
-| `x` | [dict](../core/dict); required  A dict that maps configuration conditions to values. Each key is a [Label](../builtins/Label) or a label string that identifies a config\_setting or constraint\_value instance. See the [documentation on macros](https://bazel.build/versions/8.0.1/rules/macros#label-resolution) for when to use a Label instead of a string. |
-| `no_match_error` | [string](../core/string); default is `''`  Optional custom error to report if no condition matches. |
+| `x` | [dict](/versions/8.0.1/rules/lib/core/dict); required  A dict that maps configuration conditions to values. Each key is a [Label](/versions/8.0.1/rules/lib/builtins/Label) or a label string that identifies a config\_setting or constraint\_value instance. See the [documentation on macros](https://bazel.build/versions/8.0.1/rules/macros#label-resolution) for when to use a Label instead of a string. |
+| `no_match_error` | [string](/versions/8.0.1/rules/lib/core/string); default is `''`  Optional custom error to report if no condition matches. |
 
 ## subrule
 
@@ -318,11 +318,11 @@ Constructs a new instance of a subrule. The result of this function must be stor
 
 | Parameter | Description |
 | --- | --- |
-| `implementation` | [function](../core/function); required  The Starlark function implementing this subrule |
-| `attrs` | [dict](../core/dict); default is `{}`  A dictionary to declare all the (private) attributes of the subrule.  Subrules may only have private attributes that are label-typed (i.e. label or label-list). The resolved values corresponding to these labels are automatically passed by Bazel to the subrule's implementation function as named arguments (thus the implementation function is required to accept named parameters matching the attribute names). The types of these values will be:  * `FilesToRunProvider` for label attributes with `executable=True` * `File` for label attributes with `allow_single_file=True` * `Target` for all other label attributes * `[Target]` for all label-list attributes |
-| `toolchains` | [sequence](../core/list); default is `[]`  If set, the set of toolchains this subrule requires. The list can contain String, Label, or StarlarkToolchainTypeApi objects, in any combination. Toolchains will be found by checking the current platform, and provided to the subrule implementation via `ctx.toolchains`. Note that AEGs need to be enabled on the consuming rule(s) if this parameter is set. In case you haven't migrated to AEGs yet, see https://bazel.build/extending/auto-exec-groups#migration-aegs. |
-| `fragments` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  List of names of configuration fragments that the subrule requires in target configuration. |
-| `subrules` | [sequence](../core/list) of [Subrule](../builtins/Subrule)s; default is `[]`  List of other subrules needed by this subrule. |
+| `implementation` | [function](/versions/8.0.1/rules/lib/core/function); required  The Starlark function implementing this subrule |
+| `attrs` | [dict](/versions/8.0.1/rules/lib/core/dict); default is `{}`  A dictionary to declare all the (private) attributes of the subrule.  Subrules may only have private attributes that are label-typed (i.e. label or label-list). The resolved values corresponding to these labels are automatically passed by Bazel to the subrule's implementation function as named arguments (thus the implementation function is required to accept named parameters matching the attribute names). The types of these values will be:  * `FilesToRunProvider` for label attributes with `executable=True` * `File` for label attributes with `allow_single_file=True` * `Target` for all other label attributes * `[Target]` for all label-list attributes |
+| `toolchains` | [sequence](/versions/8.0.1/rules/lib/core/list); default is `[]`  If set, the set of toolchains this subrule requires. The list can contain String, Label, or StarlarkToolchainTypeApi objects, in any combination. Toolchains will be found by checking the current platform, and provided to the subrule implementation via `ctx.toolchains`. Note that AEGs need to be enabled on the consuming rule(s) if this parameter is set. In case you haven't migrated to AEGs yet, see https://bazel.build/extending/auto-exec-groups#migration-aegs. |
+| `fragments` | [sequence](/versions/8.0.1/rules/lib/core/list) of [string](/versions/8.0.1/rules/lib/core/string)s; default is `[]`  List of names of configuration fragments that the subrule requires in target configuration. |
+| `subrules` | [sequence](/versions/8.0.1/rules/lib/core/list) of [Subrule](/versions/8.0.1/rules/lib/builtins/Subrule)s; default is `[]`  List of other subrules needed by this subrule. |
 
 ## tag\_class
 
@@ -336,8 +336,8 @@ Creates a new tag\_class object, which defines an attribute schema for a class o
 
 | Parameter | Description |
 | --- | --- |
-| `attrs` | [dict](../core/dict); default is `{}`  A dictionary to declare all the attributes of this tag class. It maps from an attribute name to an attribute object (see [attr](../toplevel/attr) module). Note that unlike [`rule()`](../globals/bzl#rule), [`aspect()`](../globals/bzl#aspect) and [`repository_rule()`](../globals/bzl#repository_rule), declared attributes will not convert `None` to the default value. For the default to be used, the attribute must be omitted entirely by the caller. |
-| `doc` | [string](../core/string); or `None`; default is `None`  A description of the tag class that can be extracted by documentation generating tools. |
+| `attrs` | [dict](/versions/8.0.1/rules/lib/core/dict); default is `{}`  A dictionary to declare all the attributes of this tag class. It maps from an attribute name to an attribute object (see [attr](/versions/8.0.1/rules/lib/toplevel/attr) module). Note that unlike [`rule()`](/versions/8.0.1/rules/lib/globals/bzl#rule), [`aspect()`](/versions/8.0.1/rules/lib/globals/bzl#aspect) and [`repository_rule()`](/versions/8.0.1/rules/lib/globals/bzl#repository_rule), declared attributes will not convert `None` to the default value. For the default to be used, the attribute must be omitted entirely by the caller. |
+| `doc` | [string](/versions/8.0.1/rules/lib/core/string); or `None`; default is `None`  A description of the tag class that can be extracted by documentation generating tools. |
 
 ## visibility
 
diff --git a/versions/8.0.1/rules/lib/globals/module.mdx b/versions/8.0.1/rules/lib/globals/module.mdx
index cab08232..ea769d19 100644
--- a/versions/8.0.1/rules/lib/globals/module.mdx
+++ b/versions/8.0.1/rules/lib/globals/module.mdx
@@ -30,7 +30,7 @@ None archive_override(module_name, **kwargs)
 
 Specifies that this dependency should come from an archive file (zip, gzip, etc) at a
 certain location, instead of from a registry. Effectively, this dependency will be
-backed by an [`http_archive`](../repo/http#http_archive) rule.
+backed by an [`http_archive`](/versions/8.0.1/rules/lib/repo/http#http_archive) rule.
 
 This directive only takes effect in the root module; in other words, if a module is
 used as a dependency by others, its own overrides are ignored.
@@ -39,7 +39,7 @@ used as a dependency by others, its own overrides are ignored.
 
 | Parameter | Description |
 | --- | --- |
-| `module_name` | [string](../core/string); required  The name of the Bazel module dependency to apply this override to. |
+| `module_name` | [string](/versions/8.0.1/rules/lib/core/string); required  The name of the Bazel module dependency to apply this override to. |
 | `kwargs` | required  All other arguments are forwarded to the underlying `http_archive` repo rule. Note that the `name` attribute shouldn't be specified; use `module_name` instead. |
 
 ## bazel\_dep
@@ -54,11 +54,11 @@ Declares a direct dependency on another Bazel module.
 
 | Parameter | Description |
 | --- | --- |
-| `name` | [string](../core/string); required  The name of the module to be added as a direct dependency. |
-| `version` | [string](../core/string); default is `''`  The version of the module to be added as a direct dependency. |
-| `max_compatibility_level` | [int](../core/int); default is `-1`  The maximum `compatibility_level` supported for the module to be added as a direct dependency. The version of the module implies the minimum compatibility\_level supported, as well as the maximum if this attribute is not specified. |
-| `repo_name` | [string](../core/string); default is `''`  The name of the external repo representing this dependency. This is by default the name of the module. |
-| `dev_dependency` | [bool](../core/bool); default is `False`  If true, this dependency will be ignored if the current module is not the root module or `--ignore\_dev\_dependency` is enabled. |
+| `name` | [string](/versions/8.0.1/rules/lib/core/string); required  The name of the module to be added as a direct dependency. |
+| `version` | [string](/versions/8.0.1/rules/lib/core/string); default is `''`  The version of the module to be added as a direct dependency. |
+| `max_compatibility_level` | [int](/versions/8.0.1/rules/lib/core/int); default is `-1`  The maximum `compatibility_level` supported for the module to be added as a direct dependency. The version of the module implies the minimum compatibility\_level supported, as well as the maximum if this attribute is not specified. |
+| `repo_name` | [string](/versions/8.0.1/rules/lib/core/string); default is `''`  The name of the external repo representing this dependency. This is by default the name of the module. |
+| `dev_dependency` | [bool](/versions/8.0.1/rules/lib/core/bool); default is `False`  If true, this dependency will be ignored if the current module is not the root module or `--ignore\_dev\_dependency` is enabled. |
 
 ## git\_override
 
@@ -68,7 +68,7 @@ None git_override(module_name, **kwargs)
 
 Specifies that this dependency should come from a certain commit in a Git repository,
 instead of from a registry. Effectively, this dependency will be backed by a
-[`git_repository`](../repo/git#git_repository) rule.
+[`git_repository`](/versions/8.0.1/rules/lib/repo/git#git_repository) rule.
 
 This directive only takes effect in the root module; in other words, if a module is
 used as a dependency by others, its own overrides are ignored.
@@ -77,7 +77,7 @@ used as a dependency by others, its own overrides are ignored.
 
 | Parameter | Description |
 | --- | --- |
-| `module_name` | [string](../core/string); required  The name of the Bazel module dependency to apply this override to. |
+| `module_name` | [string](/versions/8.0.1/rules/lib/core/string); required  The name of the Bazel module dependency to apply this override to. |
 | `kwargs` | required  All other arguments are forwarded to the underlying `git_repository` repo rule. Note that the `name` attribute shouldn't be specified; use `module_name` instead. |
 
 ## include
@@ -98,7 +98,7 @@ Only files in the main repo may be included.
 
 | Parameter | Description |
 | --- | --- |
-| `label` | [string](../core/string); required  The label pointing to the file to include. The label must point to a file in the main repo; in other words, it **must **start with double slashes (`//`).**** |
+| `label` | [string](/versions/8.0.1/rules/lib/core/string); required  The label pointing to the file to include. The label must point to a file in the main repo; in other words, it **must **start with double slashes (`//`).**** |
 
 ## inject\_repo
 
@@ -138,8 +138,8 @@ used as a dependency by others, its own overrides are ignored.
 
 | Parameter | Description |
 | --- | --- |
-| `module_name` | [string](../core/string); required  The name of the Bazel module dependency to apply this override to. |
-| `path` | [string](../core/string); required  The path to the directory where this module is. |
+| `module_name` | [string](/versions/8.0.1/rules/lib/core/string); required  The name of the Bazel module dependency to apply this override to. |
+| `path` | [string](/versions/8.0.1/rules/lib/core/string); required  The path to the directory where this module is. |
 
 ## module
 
@@ -155,11 +155,11 @@ It should be called at most once, and if called, it must be the very first direc
 
 | Parameter | Description |
 | --- | --- |
-| `name` | [string](../core/string); default is `''`  The name of the module. Can be omitted only if this module is the root module (as in, if it's not going to be depended on by another module). A valid module name must: 1) only contain lowercase letters (a-z), digits (0-9), dots (.), hyphens (-), and underscores (\_); 2) begin with a lowercase letter; 3) end with a lowercase letter or digit. |
-| `version` | [string](../core/string); default is `''`  The version of the module. Can be omitted only if this module is the root module (as in, if it's not going to be depended on by another module). The version must be in a relaxed SemVer format; see [the documentation](/versions/8.0.1/external/module#version_format) for more details. |
-| `compatibility_level` | [int](../core/int); default is `0`  The compatibility level of the module; this should be changed every time a major incompatible change is introduced. This is essentially the "major version" of the module in terms of SemVer, except that it's not embedded in the version string itself, but exists as a separate field. Modules with different compatibility levels participate in version resolution as if they're modules with different names, but the final dependency graph cannot contain multiple modules with the same name but different compatibility levels (unless `multiple_version_override` is in effect). See [the documentation](/versions/8.0.1/external/module#compatibility_level) for more details. |
-| `repo_name` | [string](../core/string); default is `''`  The name of the repository representing this module, as seen by the module itself. By default, the name of the repo is the name of the module. This can be specified to ease migration for projects that have been using a repo name for itself that differs from its module name. |
-| `bazel_compatibility` | Iterable of [string](../core/string)s; default is `[]`  A list of bazel versions that allows users to declare which Bazel versions are compatible with this module. It does NOT affect dependency resolution, but bzlmod will use this information to check if your current Bazel version is compatible. The format of this value is a string of some constraint values separated by comma. Three constraints are supported: <=X.X.X: The Bazel version must be equal or older than X.X.X. Used when there is a known incompatible change in a newer version. >=X.X.X: The Bazel version must be equal or newer than X.X.X.Used when you depend on some features that are only available since X.X.X. -X.X.X: The Bazel version X.X.X is not compatible. Used when there is a bug in X.X.X that breaks you, but fixed in later versions. |
+| `name` | [string](/versions/8.0.1/rules/lib/core/string); default is `''`  The name of the module. Can be omitted only if this module is the root module (as in, if it's not going to be depended on by another module). A valid module name must: 1) only contain lowercase letters (a-z), digits (0-9), dots (.), hyphens (-), and underscores (\_); 2) begin with a lowercase letter; 3) end with a lowercase letter or digit. |
+| `version` | [string](/versions/8.0.1/rules/lib/core/string); default is `''`  The version of the module. Can be omitted only if this module is the root module (as in, if it's not going to be depended on by another module). The version must be in a relaxed SemVer format; see [the documentation](/versions/8.0.1/external/module#version_format) for more details. |
+| `compatibility_level` | [int](/versions/8.0.1/rules/lib/core/int); default is `0`  The compatibility level of the module; this should be changed every time a major incompatible change is introduced. This is essentially the "major version" of the module in terms of SemVer, except that it's not embedded in the version string itself, but exists as a separate field. Modules with different compatibility levels participate in version resolution as if they're modules with different names, but the final dependency graph cannot contain multiple modules with the same name but different compatibility levels (unless `multiple_version_override` is in effect). See [the documentation](/versions/8.0.1/external/module#compatibility_level) for more details. |
+| `repo_name` | [string](/versions/8.0.1/rules/lib/core/string); default is `''`  The name of the repository representing this module, as seen by the module itself. By default, the name of the repo is the name of the module. This can be specified to ease migration for projects that have been using a repo name for itself that differs from its module name. |
+| `bazel_compatibility` | Iterable of [string](/versions/8.0.1/rules/lib/core/string)s; default is `[]`  A list of bazel versions that allows users to declare which Bazel versions are compatible with this module. It does NOT affect dependency resolution, but bzlmod will use this information to check if your current Bazel version is compatible. The format of this value is a string of some constraint values separated by comma. Three constraints are supported: <=X.X.X: The Bazel version must be equal or older than X.X.X. Used when there is a known incompatible change in a newer version. >=X.X.X: The Bazel version must be equal or newer than X.X.X.Used when you depend on some features that are only available since X.X.X. -X.X.X: The Bazel version X.X.X is not compatible. Used when there is a bug in X.X.X that breaks you, but fixed in later versions. |
 
 ## multiple\_version\_override
 
@@ -173,9 +173,9 @@ Specifies that a dependency should still come from a registry, but multiple vers
 
 | Parameter | Description |
 | --- | --- |
-| `module_name` | [string](../core/string); required  The name of the Bazel module dependency to apply this override to. |
-| `versions` | Iterable of [string](../core/string)s; required  Explicitly specifies the versions allowed to coexist. These versions must already be present in the dependency graph pre-selection. Dependencies on this module will be "upgraded" to the nearest higher allowed version at the same compatibility level, whereas dependencies that have a higher version than any allowed versions at the same compatibility level will cause an error. |
-| `registry` | [string](../core/string); default is `''`  Overrides the registry for this module; instead of finding this module from the default list of registries, the given registry should be used. |
+| `module_name` | [string](/versions/8.0.1/rules/lib/core/string); required  The name of the Bazel module dependency to apply this override to. |
+| `versions` | Iterable of [string](/versions/8.0.1/rules/lib/core/string)s; required  Explicitly specifies the versions allowed to coexist. These versions must already be present in the dependency graph pre-selection. Dependencies on this module will be "upgraded" to the nearest higher allowed version at the same compatibility level, whereas dependencies that have a higher version than any allowed versions at the same compatibility level will cause an error. |
+| `registry` | [string](/versions/8.0.1/rules/lib/core/string); default is `''`  Overrides the registry for this module; instead of finding this module from the default list of registries, the given registry should be used. |
 
 ## override\_repo
 
@@ -209,8 +209,8 @@ Specifies already-defined execution platforms to be registered when this module
 
 | Parameter | Description |
 | --- | --- |
-| `dev_dependency` | [bool](../core/bool); default is `False`  If true, the execution platforms will not be registered if the current module is not the root module or `--ignore\_dev\_dependency` is enabled. |
-| `platform_labels` | [sequence](../core/list) of [string](../core/string)s; required  The target patterns to register. |
+| `dev_dependency` | [bool](/versions/8.0.1/rules/lib/core/bool); default is `False`  If true, the execution platforms will not be registered if the current module is not the root module or `--ignore\_dev\_dependency` is enabled. |
+| `platform_labels` | [sequence](/versions/8.0.1/rules/lib/core/list) of [string](/versions/8.0.1/rules/lib/core/string)s; required  The target patterns to register. |
 
 ## register\_toolchains
 
@@ -224,8 +224,8 @@ Specifies already-defined toolchains to be registered when this module is select
 
 | Parameter | Description |
 | --- | --- |
-| `dev_dependency` | [bool](../core/bool); default is `False`  If true, the toolchains will not be registered if the current module is not the root module or `--ignore\_dev\_dependency` is enabled. |
-| `toolchain_labels` | [sequence](../core/list) of [string](../core/string)s; required  The target patterns to register. |
+| `dev_dependency` | [bool](/versions/8.0.1/rules/lib/core/bool); default is `False`  If true, the toolchains will not be registered if the current module is not the root module or `--ignore\_dev\_dependency` is enabled. |
+| `toolchain_labels` | [sequence](/versions/8.0.1/rules/lib/core/list) of [string](/versions/8.0.1/rules/lib/core/string)s; required  The target patterns to register. |
 
 ## single\_version\_override
 
@@ -239,12 +239,12 @@ Specifies that a dependency should still come from a registry, but its version s
 
 | Parameter | Description |
 | --- | --- |
-| `module_name` | [string](../core/string); required  The name of the Bazel module dependency to apply this override to. |
-| `version` | [string](../core/string); default is `''`  Overrides the declared version of this module in the dependency graph. In other words, this module will be "pinned" to this override version. This attribute can be omitted if all one wants to override is the registry or the patches. |
-| `registry` | [string](../core/string); default is `''`  Overrides the registry for this module; instead of finding this module from the default list of registries, the given registry should be used. |
-| `patches` | Iterable of [string](../core/string)s; default is `[]`  A list of labels pointing to patch files to apply for this module. The patch files must exist in the source tree of the top level project. They are applied in the list order. If a patch makes changes to the MODULE.bazel file, these changes will only be effective if the patch file is provided by the root module. |
-| `patch_cmds` | Iterable of [string](../core/string)s; default is `[]`  Sequence of Bash commands to be applied on Linux/Macos after patches are applied. Changes to the MODULE.bazel file will not be effective. |
-| `patch_strip` | [int](../core/int); default is `0`  Same as the --strip argument of Unix patch. |
+| `module_name` | [string](/versions/8.0.1/rules/lib/core/string); required  The name of the Bazel module dependency to apply this override to. |
+| `version` | [string](/versions/8.0.1/rules/lib/core/string); default is `''`  Overrides the declared version of this module in the dependency graph. In other words, this module will be "pinned" to this override version. This attribute can be omitted if all one wants to override is the registry or the patches. |
+| `registry` | [string](/versions/8.0.1/rules/lib/core/string); default is `''`  Overrides the registry for this module; instead of finding this module from the default list of registries, the given registry should be used. |
+| `patches` | Iterable of [string](/versions/8.0.1/rules/lib/core/string)s; default is `[]`  A list of labels pointing to patch files to apply for this module. The patch files must exist in the source tree of the top level project. They are applied in the list order. If a patch makes changes to the MODULE.bazel file, these changes will only be effective if the patch file is provided by the root module. |
+| `patch_cmds` | Iterable of [string](/versions/8.0.1/rules/lib/core/string)s; default is `[]`  Sequence of Bash commands to be applied on Linux/Macos after patches are applied. Changes to the MODULE.bazel file will not be effective. |
+| `patch_strip` | [int](/versions/8.0.1/rules/lib/core/int); default is `0`  Same as the --strip argument of Unix patch. |
 
 ## use\_extension
 
@@ -258,10 +258,10 @@ Returns a proxy object representing a module extension; its methods can be invok
 
 | Parameter | Description |
 | --- | --- |
-| `extension_bzl_file` | [string](../core/string); required  A label to the Starlark file defining the module extension. |
-| `extension_name` | [string](../core/string); required  The name of the module extension to use. A symbol with this name must be exported by the Starlark file. |
-| `dev_dependency` | [bool](../core/bool); default is `False`  If true, this usage of the module extension will be ignored if the current module is not the root module or `--ignore\_dev\_dependency` is enabled. |
-| `isolate` | [bool](../core/bool); default is `False`  **Experimental**. This parameter is experimental and may change at any time. Please do not depend on it. It may be enabled on an experimental basis by setting `--experimental_isolated_extension_usages`  If true, this usage of the module extension will be isolated from all other usages, both in this and other modules. Tags created for this usage do not affect other usages and the repositories generated by the extension for this usage will be distinct from all other repositories generated by the extension. This parameter is currently experimental and only available with the flag `--experimental_isolated_extension_usages`. |
+| `extension_bzl_file` | [string](/versions/8.0.1/rules/lib/core/string); required  A label to the Starlark file defining the module extension. |
+| `extension_name` | [string](/versions/8.0.1/rules/lib/core/string); required  The name of the module extension to use. A symbol with this name must be exported by the Starlark file. |
+| `dev_dependency` | [bool](/versions/8.0.1/rules/lib/core/bool); default is `False`  If true, this usage of the module extension will be ignored if the current module is not the root module or `--ignore\_dev\_dependency` is enabled. |
+| `isolate` | [bool](/versions/8.0.1/rules/lib/core/bool); default is `False`  **Experimental**. This parameter is experimental and may change at any time. Please do not depend on it. It may be enabled on an experimental basis by setting `--experimental_isolated_extension_usages`  If true, this usage of the module extension will be isolated from all other usages, both in this and other modules. Tags created for this usage do not affect other usages and the repositories generated by the extension for this usage will be distinct from all other repositories generated by the extension. This parameter is currently experimental and only available with the flag `--experimental_isolated_extension_usages`. |
 
 ## use\_repo
 
@@ -291,5 +291,5 @@ Returns a proxy value that can be directly invoked in the MODULE.bazel file as a
 
 | Parameter | Description |
 | --- | --- |
-| `repo_rule_bzl_file` | [string](../core/string); required  A label to the Starlark file defining the repo rule. |
-| `repo_rule_name` | [string](../core/string); required  The name of the repo rule to use. A symbol with this name must be exported by the Starlark file. |
\ No newline at end of file
+| `repo_rule_bzl_file` | [string](/versions/8.0.1/rules/lib/core/string); required  A label to the Starlark file defining the repo rule. |
+| `repo_rule_name` | [string](/versions/8.0.1/rules/lib/core/string); required  The name of the repo rule to use. A symbol with this name must be exported by the Starlark file. |
\ No newline at end of file
diff --git a/versions/8.0.1/rules/lib/globals/repo.mdx b/versions/8.0.1/rules/lib/globals/repo.mdx
index f560705e..1507cff0 100644
--- a/versions/8.0.1/rules/lib/globals/repo.mdx
+++ b/versions/8.0.1/rules/lib/globals/repo.mdx
@@ -23,7 +23,7 @@ This function takes a list of strings and a directory is ignored if any of the g
 
 | Parameter | Description |
 | --- | --- |
-| `dirs` | [sequence](../core/list) of [string](../core/string)s; required |
+| `dirs` | [sequence](/versions/8.0.1/rules/lib/core/list) of [string](/versions/8.0.1/rules/lib/core/string)s; required |
 
 ## repo
 
diff --git a/versions/8.0.1/rules/lib/globals/workspace.mdx b/versions/8.0.1/rules/lib/globals/workspace.mdx
index 5794d2ce..0dd5f933 100644
--- a/versions/8.0.1/rules/lib/globals/workspace.mdx
+++ b/versions/8.0.1/rules/lib/globals/workspace.mdx
@@ -25,8 +25,8 @@ Gives a target an alias in the `//external` package.
 
 | Parameter | Description |
 | --- | --- |
-| `name` | [string](../core/string); required  The label under '//external' to serve as the alias name |
-| `actual` | [string](../core/string); or `None`; default is `None`  The real label to be aliased |
+| `name` | [string](/versions/8.0.1/rules/lib/core/string); required  The label under '//external' to serve as the alias name |
+| `actual` | [string](/versions/8.0.1/rules/lib/core/string); or `None`; default is `None`  The real label to be aliased |
 
 ## register\_execution\_platforms
 
@@ -40,7 +40,7 @@ Specifies already-defined execution platforms to be registered. Should be absolu
 
 | Parameter | Description |
 | --- | --- |
-| `platform_labels` | [sequence](../core/list) of [string](../core/string)s; required  The target patterns to register. |
+| `platform_labels` | [sequence](/versions/8.0.1/rules/lib/core/list) of [string](/versions/8.0.1/rules/lib/core/string)s; required  The target patterns to register. |
 
 ## register\_toolchains
 
@@ -54,7 +54,7 @@ Specifies already-defined toolchains to be registered. Should be absolute [targe
 
 | Parameter | Description |
 | --- | --- |
-| `toolchain_labels` | [sequence](../core/list) of [string](../core/string)s; required  The target patterns to register. |
+| `toolchain_labels` | [sequence](/versions/8.0.1/rules/lib/core/list) of [string](/versions/8.0.1/rules/lib/core/string)s; required  The target patterns to register. |
 
 ## workspace
 
@@ -74,4 +74,4 @@ This name is used for the directory that the repository's runfiles are stored in
 
 | Parameter | Description |
 | --- | --- |
-| `name` | [string](../core/string); required  the name of the workspace. Names must start with a letter and can only contain letters, numbers, underscores, dashes, and dots. |
\ No newline at end of file
+| `name` | [string](/versions/8.0.1/rules/lib/core/string); required  the name of the workspace. Names must start with a letter and can only contain letters, numbers, underscores, dashes, and dots. |
\ No newline at end of file
diff --git a/versions/8.0.1/rules/lib/providers/AnalysisTestResultInfo.mdx b/versions/8.0.1/rules/lib/providers/AnalysisTestResultInfo.mdx
index 1edabb04..f070647c 100644
--- a/versions/8.0.1/rules/lib/providers/AnalysisTestResultInfo.mdx
+++ b/versions/8.0.1/rules/lib/providers/AnalysisTestResultInfo.mdx
@@ -22,8 +22,8 @@ The `AnalysisTestResultInfo` constructor.
 
 | Parameter | Description |
 | --- | --- |
-| `success` | [bool](../core/bool); required  If true, then the analysis-phase test represented by this target should pass. If false, the test should fail. |
-| `message` | [string](../core/string); required  A descriptive message containing information about the test and its success/failure. |
+| `success` | [bool](/versions/8.0.1/rules/lib/core/bool); required  If true, then the analysis-phase test represented by this target should pass. If false, the test should fail. |
+| `message` | [string](/versions/8.0.1/rules/lib/core/string); required  A descriptive message containing information about the test and its success/failure. |
 
 ## message
 
diff --git a/versions/8.0.1/rules/lib/providers/CcInfo.mdx b/versions/8.0.1/rules/lib/providers/CcInfo.mdx
index f3c0d961..a4c13b8c 100644
--- a/versions/8.0.1/rules/lib/providers/CcInfo.mdx
+++ b/versions/8.0.1/rules/lib/providers/CcInfo.mdx
@@ -22,8 +22,8 @@ The `CcInfo` constructor.
 
 | Parameter | Description |
 | --- | --- |
-| `compilation_context` | [CompilationContext](../builtins/CompilationContext); or `None`; default is `None`  The `CompilationContext`. |
-| `linking_context` | [LinkingContext](../builtins/LinkingContext); or `None`; default is `None`  The `LinkingContext`. |
+| `compilation_context` | [CompilationContext](/versions/8.0.1/rules/lib/builtins/CompilationContext); or `None`; default is `None`  The `CompilationContext`. |
+| `linking_context` | [LinkingContext](/versions/8.0.1/rules/lib/builtins/LinkingContext); or `None`; default is `None`  The `LinkingContext`. |
 | `debug_context` | DebugContext; or `None`; default is `None`  The `DebugContext`. |
 
 ## compilation\_context
diff --git a/versions/8.0.1/rules/lib/providers/DebugPackageInfo.mdx b/versions/8.0.1/rules/lib/providers/DebugPackageInfo.mdx
index 296778f2..8f13de9f 100644
--- a/versions/8.0.1/rules/lib/providers/DebugPackageInfo.mdx
+++ b/versions/8.0.1/rules/lib/providers/DebugPackageInfo.mdx
@@ -24,10 +24,10 @@ The `DebugPackageInfo` constructor.
 
 | Parameter | Description |
 | --- | --- |
-| `target_label` | [Label](../builtins/Label); required  The label for the \*\_binary target |
-| `stripped_file` | [File](../builtins/File); or `None`; default is `None`  The stripped file (the explicit ".stripped" target) |
-| `unstripped_file` | [File](../builtins/File); required  The unstripped file (the default executable target). |
-| `dwp_file` | [File](../builtins/File); or `None`; default is `None`  The .dwp file (for fission builds) or null if --fission=no. |
+| `target_label` | [Label](/versions/8.0.1/rules/lib/builtins/Label); required  The label for the \*\_binary target |
+| `stripped_file` | [File](/versions/8.0.1/rules/lib/builtins/File); or `None`; default is `None`  The stripped file (the explicit ".stripped" target) |
+| `unstripped_file` | [File](/versions/8.0.1/rules/lib/builtins/File); required  The unstripped file (the default executable target). |
+| `dwp_file` | [File](/versions/8.0.1/rules/lib/builtins/File); or `None`; default is `None`  The .dwp file (for fission builds) or null if --fission=no. |
 
 ## dwp\_file
 
diff --git a/versions/8.0.1/rules/lib/providers/DefaultInfo.mdx b/versions/8.0.1/rules/lib/providers/DefaultInfo.mdx
index 0af85d64..5efb37cc 100644
--- a/versions/8.0.1/rules/lib/providers/DefaultInfo.mdx
+++ b/versions/8.0.1/rules/lib/providers/DefaultInfo.mdx
@@ -28,11 +28,11 @@ The `DefaultInfo` constructor.
 
 | Parameter | Description |
 | --- | --- |
-| `files` | [depset](../builtins/depset); or `None`; default is `None`  A [`depset`](../builtins/depset) of [`File`](../builtins/File) objects representing the default outputs to build when this target is specified on the bazel command line. By default it is all predeclared outputs. |
-| `runfiles` | [runfiles](../builtins/runfiles); or `None`; default is `None`  runfiles descriptor describing the files that this target needs when run (via the `run` command or as a tool dependency). |
-| `data_runfiles` | [runfiles](../builtins/runfiles); or `None`; default is `None`  **It is recommended that you avoid using this parameter (see ["runfiles features to avoid"](https://bazel.build/versions/8.0.1/extending/rules#runfiles_features_to_avoid))** runfiles descriptor describing the runfiles this target needs to run when it is a dependency via the `data` attribute. |
-| `default_runfiles` | [runfiles](../builtins/runfiles); or `None`; default is `None`  **It is recommended that you avoid using this parameter (see ["runfiles features to avoid"](https://bazel.build/versions/8.0.1/extending/rules#runfiles_features_to_avoid))** runfiles descriptor describing the runfiles this target needs to run when it is a dependency via any attribute other than the `data` attribute. |
-| `executable` | [File](../builtins/File); or `None`; default is `None`  If this rule is marked [`executable`](../globals/bzl#rule.executable) or [`test`](../globals/bzl#rule.test), this is a [`File`](../builtins/File) object representing the file that should be executed to run the target. By default it is the predeclared output `ctx.outputs.executable` but it is recommended to pass another file (either predeclared or not) explicitly. |
+| `files` | [depset](/versions/8.0.1/rules/lib/builtins/depset); or `None`; default is `None`  A [`depset`](/versions/8.0.1/rules/lib/builtins/depset) of [`File`](/versions/8.0.1/rules/lib/builtins/File) objects representing the default outputs to build when this target is specified on the bazel command line. By default it is all predeclared outputs. |
+| `runfiles` | [runfiles](/versions/8.0.1/rules/lib/builtins/runfiles); or `None`; default is `None`  runfiles descriptor describing the files that this target needs when run (via the `run` command or as a tool dependency). |
+| `data_runfiles` | [runfiles](/versions/8.0.1/rules/lib/builtins/runfiles); or `None`; default is `None`  **It is recommended that you avoid using this parameter (see ["runfiles features to avoid"](https://bazel.build/versions/8.0.1/extending/rules#runfiles_features_to_avoid))** runfiles descriptor describing the runfiles this target needs to run when it is a dependency via the `data` attribute. |
+| `default_runfiles` | [runfiles](/versions/8.0.1/rules/lib/builtins/runfiles); or `None`; default is `None`  **It is recommended that you avoid using this parameter (see ["runfiles features to avoid"](https://bazel.build/versions/8.0.1/extending/rules#runfiles_features_to_avoid))** runfiles descriptor describing the runfiles this target needs to run when it is a dependency via any attribute other than the `data` attribute. |
+| `executable` | [File](/versions/8.0.1/rules/lib/builtins/File); or `None`; default is `None`  If this rule is marked [`executable`](/versions/8.0.1/rules/lib/globals/bzl#rule.executable) or [`test`](/versions/8.0.1/rules/lib/globals/bzl#rule.test), this is a [`File`](/versions/8.0.1/rules/lib/builtins/File) object representing the file that should be executed to run the target. By default it is the predeclared output `ctx.outputs.executable` but it is recommended to pass another file (either predeclared or not) explicitly. |
 
 ## data\_runfiles
 
@@ -58,7 +58,7 @@ May return `None`.
 depset DefaultInfo.files
 ```
 
-A [`depset`](../builtins/depset) of [`File`](../builtins/File) objects representing the default outputs to build when this target is specified on the bazel command line. By default it is all predeclared outputs.
+A [`depset`](/versions/8.0.1/rules/lib/builtins/depset) of [`File`](/versions/8.0.1/rules/lib/builtins/File) objects representing the default outputs to build when this target is specified on the bazel command line. By default it is all predeclared outputs.
 May return `None`.
 
 ## files\_to\_run
@@ -67,5 +67,5 @@ May return `None`.
 FilesToRunProvider DefaultInfo.files_to_run
 ```
 
-A [`FilesToRunProvider`](../providers/FilesToRunProvider) object containing information about the executable and runfiles of the target.
+A [`FilesToRunProvider`](/versions/8.0.1/rules/lib/providers/FilesToRunProvider) object containing information about the executable and runfiles of the target.
 May return `None`.
\ No newline at end of file
diff --git a/versions/8.0.1/rules/lib/providers/ExecutionInfo.mdx b/versions/8.0.1/rules/lib/providers/ExecutionInfo.mdx
index d351095e..f5bc2cce 100644
--- a/versions/8.0.1/rules/lib/providers/ExecutionInfo.mdx
+++ b/versions/8.0.1/rules/lib/providers/ExecutionInfo.mdx
@@ -22,8 +22,8 @@ Creates an instance.
 
 | Parameter | Description |
 | --- | --- |
-| `requirements` | [dict](../core/dict); default is `{}`  A dict indicating special execution requirements, such as hardware platforms. |
-| `exec_group` | [string](../core/string); default is `'test'`  The name of the exec group that is used to execute the test. |
+| `requirements` | [dict](/versions/8.0.1/rules/lib/core/dict); default is `{}`  A dict indicating special execution requirements, such as hardware platforms. |
+| `exec_group` | [string](/versions/8.0.1/rules/lib/core/string); default is `'test'`  The name of the exec group that is used to execute the test. |
 
 ## exec\_group
 
diff --git a/versions/8.0.1/rules/lib/providers/FeatureFlagInfo.mdx b/versions/8.0.1/rules/lib/providers/FeatureFlagInfo.mdx
index ebade07a..e91683a9 100644
--- a/versions/8.0.1/rules/lib/providers/FeatureFlagInfo.mdx
+++ b/versions/8.0.1/rules/lib/providers/FeatureFlagInfo.mdx
@@ -31,7 +31,7 @@ The value of the flag in the configuration used by the flag rule.
 
 | Parameter | Description |
 | --- | --- |
-| `value` | [string](../core/string); required  String, the value to check for validity for this flag. |
+| `value` | [string](/versions/8.0.1/rules/lib/core/string); required  String, the value to check for validity for this flag. |
 
 ## value
 
diff --git a/versions/8.0.1/rules/lib/providers/InstrumentedFilesInfo.mdx b/versions/8.0.1/rules/lib/providers/InstrumentedFilesInfo.mdx
index 4e997f28..f17d05c2 100644
--- a/versions/8.0.1/rules/lib/providers/InstrumentedFilesInfo.mdx
+++ b/versions/8.0.1/rules/lib/providers/InstrumentedFilesInfo.mdx
@@ -15,7 +15,7 @@ Contains information about source files and instrumentation metadata files for r
 depset InstrumentedFilesInfo.instrumented_files
 ```
 
-[`depset`](../builtins/depset) of [`File`](../builtins/File) objects representing instrumented source files for this target and its dependencies.
+[`depset`](/versions/8.0.1/rules/lib/builtins/depset) of [`File`](/versions/8.0.1/rules/lib/builtins/File) objects representing instrumented source files for this target and its dependencies.
 
 ## metadata\_files
 
@@ -23,4 +23,4 @@ depset InstrumentedFilesInfo.instrumented_files
 depset InstrumentedFilesInfo.metadata_files
 ```
 
-[`depset`](../builtins/depset) of [`File`](../builtins/File) objects representing coverage metadata files for this target and its dependencies. These files contain additional information required to generate LCOV-format coverage output after the code is executed, e.g. the `.gcno` files generated when `gcc` is run with `-ftest-coverage`.
\ No newline at end of file
+[`depset`](/versions/8.0.1/rules/lib/builtins/depset) of [`File`](/versions/8.0.1/rules/lib/builtins/File) objects representing coverage metadata files for this target and its dependencies. These files contain additional information required to generate LCOV-format coverage output after the code is executed, e.g. the `.gcno` files generated when `gcc` is run with `-ftest-coverage`.
\ No newline at end of file
diff --git a/versions/8.0.1/rules/lib/providers/PackageSpecificationInfo.mdx b/versions/8.0.1/rules/lib/providers/PackageSpecificationInfo.mdx
index 242a43e6..9e59e65d 100644
--- a/versions/8.0.1/rules/lib/providers/PackageSpecificationInfo.mdx
+++ b/versions/8.0.1/rules/lib/providers/PackageSpecificationInfo.mdx
@@ -20,4 +20,4 @@ Checks if a target exists in a package group.
 
 | Parameter | Description |
 | --- | --- |
-| `target` | [Label](../builtins/Label); or [string](../core/string); required  A target which is checked if it exists inside the package group. |
\ No newline at end of file
+| `target` | [Label](/versions/8.0.1/rules/lib/builtins/Label); or [string](/versions/8.0.1/rules/lib/core/string); required  A target which is checked if it exists inside the package group. |
\ No newline at end of file
diff --git a/versions/8.0.1/rules/lib/providers/ProguardSpecProvider.mdx b/versions/8.0.1/rules/lib/providers/ProguardSpecProvider.mdx
index b7a337c2..61697dbc 100644
--- a/versions/8.0.1/rules/lib/providers/ProguardSpecProvider.mdx
+++ b/versions/8.0.1/rules/lib/providers/ProguardSpecProvider.mdx
@@ -20,4 +20,4 @@ The `ProguardSpecProvider` constructor.
 
 | Parameter | Description |
 | --- | --- |
-| `specs` | [depset](../builtins/depset) of [File](../builtins/File)s; required  Transitive proguard specs. |
\ No newline at end of file
+| `specs` | [depset](/versions/8.0.1/rules/lib/builtins/depset) of [File](/versions/8.0.1/rules/lib/builtins/File)s; required  Transitive proguard specs. |
\ No newline at end of file
diff --git a/versions/8.0.1/rules/lib/repo/index.mdx b/versions/8.0.1/rules/lib/repo/index.mdx
index 8b364d2d..ea3aaf29 100644
--- a/versions/8.0.1/rules/lib/repo/index.mdx
+++ b/versions/8.0.1/rules/lib/repo/index.mdx
@@ -2,10 +2,10 @@
 title: 'Repository Rules'
 ---
 
-* [Rules related to git](git)
-* [Rules related to http](http)
-* [Rules related to local directories](local)
+* [Rules related to git](/versions/8.0.1/rules/lib/repo/git)
+* [Rules related to http](/versions/8.0.1/rules/lib/repo/http)
+* [Rules related to local directories](/versions/8.0.1/rules/lib/repo/local)
 
 # Generic functions for repository rule authors
 
-* [Utility functions on patching](utils)
+* [Utility functions on patching](/versions/8.0.1/rules/lib/repo/utils)
diff --git a/versions/8.0.1/rules/lib/toplevel/apple_common.mdx b/versions/8.0.1/rules/lib/toplevel/apple_common.mdx
index d26f9c22..73a04503 100644
--- a/versions/8.0.1/rules/lib/toplevel/apple_common.mdx
+++ b/versions/8.0.1/rules/lib/toplevel/apple_common.mdx
@@ -21,7 +21,7 @@ Functions for Starlark to access internals of the apple rule implementations.
 dict apple_common.apple_host_system_env(xcode_config)
 ```
 
-Returns a [dict](../core/dict) of environment variables that should be set for actions that need to run build tools on an Apple host system, such as the version of Xcode that should be used. The keys are variable names and the values are their corresponding values.
+Returns a [dict](/versions/8.0.1/rules/lib/core/dict) of environment variables that should be set for actions that need to run build tools on an Apple host system, such as the version of Xcode that should be used. The keys are variable names and the values are their corresponding values.
 
 ### Parameters
 
@@ -43,13 +43,13 @@ Utilities for resolving items from the apple toolchain.
 DottedVersion apple_common.dotted_version(version)
 ```
 
-Creates a new [DottedVersion](../builtins/DottedVersion) instance.
+Creates a new [DottedVersion](/versions/8.0.1/rules/lib/builtins/DottedVersion) instance.
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `version` | [string](../core/string); required  The string representation of the DottedVersion. |
+| `version` | [string](/versions/8.0.1/rules/lib/core/string); required  The string representation of the DottedVersion. |
 
 ## platform
 
@@ -69,7 +69,7 @@ An enum-like struct that contains the following fields corresponding to Apple pl
 * `watchos_device`
 * `watchos_simulator`
 
-These values can be passed to methods that expect a platform, like [XcodeVersionConfig.sdk\_version\_for\_platform](../providers/XcodeVersionConfig#sdk_version_for_platform).
+These values can be passed to methods that expect a platform, like [XcodeVersionConfig.sdk\_version\_for\_platform](/versions/8.0.1/rules/lib/providers/XcodeVersionConfig#sdk_version_for_platform).
 
 ## platform\_type
 
@@ -85,7 +85,7 @@ An enum-like struct that contains the following fields corresponding to Apple pl
 * `visionos`
 * `watchos`
 
-These values can be passed to methods that expect a platform type, like the 'apple' configuration fragment's [multi\_arch\_platform](../fragments/apple#multi_arch_platform) method.
+These values can be passed to methods that expect a platform type, like the 'apple' configuration fragment's [multi\_arch\_platform](/versions/8.0.1/rules/lib/fragments/apple#multi_arch_platform) method.
 
 Example:
 
diff --git a/versions/8.0.1/rules/lib/toplevel/attr.mdx b/versions/8.0.1/rules/lib/toplevel/attr.mdx
index c62a9fef..52ce5bff 100644
--- a/versions/8.0.1/rules/lib/toplevel/attr.mdx
+++ b/versions/8.0.1/rules/lib/toplevel/attr.mdx
@@ -2,7 +2,7 @@
 title: 'attr'
 ---
 
-This is a top-level module for defining the attribute schemas of a rule or aspect. Each function returns an object representing the schema of a single attribute. These objects are used as the values of the `attrs` dictionary argument of [`rule()`](../globals/bzl#rule), [`aspect()`](../globals/bzl#aspect), [`repository_rule()`](../globals/bzl#repository_rule) and [`tag_class()`](../globals/bzl#tag_class).
+This is a top-level module for defining the attribute schemas of a rule or aspect. Each function returns an object representing the schema of a single attribute. These objects are used as the values of the `attrs` dictionary argument of [`rule()`](/versions/8.0.1/rules/lib/globals/bzl#rule), [`aspect()`](/versions/8.0.1/rules/lib/globals/bzl#aspect), [`repository_rule()`](/versions/8.0.1/rules/lib/globals/bzl#repository_rule) and [`tag_class()`](/versions/8.0.1/rules/lib/globals/bzl#tag_class).
 
 See the Rules page for more on [defining](https://bazel.build/versions/8.0.1/extending/rules#attributes)
 and [using](https://bazel.build/versions/8.0.1/extending/rules#implementation_function) attributes.
@@ -29,16 +29,16 @@ and [using](https://bazel.build/versions/8.0.1/extending/rules#implementation_fu
 Attribute attr.bool(configurable=unbound, default=False, doc=None, mandatory=False)
 ```
 
-Creates a schema for a boolean attribute. The corresponding [`ctx.attr`](../builtins/ctx#attr) attribute will be of type [`bool`](../core/bool).
+Creates a schema for a boolean attribute. The corresponding [`ctx.attr`](/versions/8.0.1/rules/lib/builtins/ctx#attr) attribute will be of type [`bool`](/versions/8.0.1/rules/lib/core/bool).
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `configurable` | [bool](../core/bool); or unbound; default is `unbound`  This argument can only be specified for an attribute of a symbolic macro. If `configurable` is explicitly set to `False`, the symbolic macro attribute is non-configurable - in other words, it cannot take a `select()` value. If the `configurable` is either unbound or explicitly set to `True`, the attribute is configurable and can take a `select()` value. For an attribute of a rule or aspect, `configurable` must be left unbound. Most Starlark rule attributes are always configurable, with the exception of `attr.output()`, `attr.output_list()`, and `attr.license()` rule attributes, which are always non-configurable. |
-| `default` | [bool](../core/bool); default is `False`  A default value to use if no value for this attribute is given when instantiating the rule. |
-| `doc` | [string](../core/string); or `None`; default is `None`  A description of the attribute that can be extracted by documentation generating tools. |
-| `mandatory` | [bool](../core/bool); default is `False`  If true, the value must be specified explicitly (even if it has a `default`). |
+| `configurable` | [bool](/versions/8.0.1/rules/lib/core/bool); or unbound; default is `unbound`  This argument can only be specified for an attribute of a symbolic macro. If `configurable` is explicitly set to `False`, the symbolic macro attribute is non-configurable - in other words, it cannot take a `select()` value. If the `configurable` is either unbound or explicitly set to `True`, the attribute is configurable and can take a `select()` value. For an attribute of a rule or aspect, `configurable` must be left unbound. Most Starlark rule attributes are always configurable, with the exception of `attr.output()`, `attr.output_list()`, and `attr.license()` rule attributes, which are always non-configurable. |
+| `default` | [bool](/versions/8.0.1/rules/lib/core/bool); default is `False`  A default value to use if no value for this attribute is given when instantiating the rule. |
+| `doc` | [string](/versions/8.0.1/rules/lib/core/string); or `None`; default is `None`  A description of the attribute that can be extracted by documentation generating tools. |
+| `mandatory` | [bool](/versions/8.0.1/rules/lib/core/bool); default is `False`  If true, the value must be specified explicitly (even if it has a `default`). |
 
 ## int
 
@@ -46,17 +46,17 @@ Creates a schema for a boolean attribute. The corresponding [`ctx.attr`](../buil
 Attribute attr.int(configurable=unbound, default=0, doc=None, mandatory=False, values=[])
 ```
 
-Creates a schema for an integer attribute. The value must be in the signed 32-bit range. The corresponding [`ctx.attr`](../builtins/ctx#attr) attribute will be of type [`int`](../core/int).
+Creates a schema for an integer attribute. The value must be in the signed 32-bit range. The corresponding [`ctx.attr`](/versions/8.0.1/rules/lib/builtins/ctx#attr) attribute will be of type [`int`](/versions/8.0.1/rules/lib/core/int).
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `configurable` | [bool](../core/bool); or unbound; default is `unbound`  This argument can only be specified for an attribute of a symbolic macro. If `configurable` is explicitly set to `False`, the symbolic macro attribute is non-configurable - in other words, it cannot take a `select()` value. If the `configurable` is either unbound or explicitly set to `True`, the attribute is configurable and can take a `select()` value. For an attribute of a rule or aspect, `configurable` must be left unbound. Most Starlark rule attributes are always configurable, with the exception of `attr.output()`, `attr.output_list()`, and `attr.license()` rule attributes, which are always non-configurable. |
-| `default` | [int](../core/int); default is `0`  A default value to use if no value for this attribute is given when instantiating the rule. |
-| `doc` | [string](../core/string); or `None`; default is `None`  A description of the attribute that can be extracted by documentation generating tools. |
-| `mandatory` | [bool](../core/bool); default is `False`  If true, the value must be specified explicitly (even if it has a `default`). |
-| `values` | [sequence](../core/list) of [int](../core/int)s; default is `[]`  The list of allowed values for the attribute. An error is raised if any other value is given. |
+| `configurable` | [bool](/versions/8.0.1/rules/lib/core/bool); or unbound; default is `unbound`  This argument can only be specified for an attribute of a symbolic macro. If `configurable` is explicitly set to `False`, the symbolic macro attribute is non-configurable - in other words, it cannot take a `select()` value. If the `configurable` is either unbound or explicitly set to `True`, the attribute is configurable and can take a `select()` value. For an attribute of a rule or aspect, `configurable` must be left unbound. Most Starlark rule attributes are always configurable, with the exception of `attr.output()`, `attr.output_list()`, and `attr.license()` rule attributes, which are always non-configurable. |
+| `default` | [int](/versions/8.0.1/rules/lib/core/int); default is `0`  A default value to use if no value for this attribute is given when instantiating the rule. |
+| `doc` | [string](/versions/8.0.1/rules/lib/core/string); or `None`; default is `None`  A description of the attribute that can be extracted by documentation generating tools. |
+| `mandatory` | [bool](/versions/8.0.1/rules/lib/core/bool); default is `False`  If true, the value must be specified explicitly (even if it has a `default`). |
+| `values` | [sequence](/versions/8.0.1/rules/lib/core/list) of [int](/versions/8.0.1/rules/lib/core/int)s; default is `[]`  The list of allowed values for the attribute. An error is raised if any other value is given. |
 
 ## int\_list
 
@@ -70,11 +70,11 @@ Creates a schema for a list-of-integers attribute. Each element must be in the s
 
 | Parameter | Description |
 | --- | --- |
-| `mandatory` | [bool](../core/bool); default is `False`  If true, the value must be specified explicitly (even if it has a `default`). |
-| `allow_empty` | [bool](../core/bool); default is `True`  True if the attribute can be empty. |
-| `configurable` | [bool](../core/bool); or unbound; default is `unbound`  This argument can only be specified for an attribute of a symbolic macro. If `configurable` is explicitly set to `False`, the symbolic macro attribute is non-configurable - in other words, it cannot take a `select()` value. If the `configurable` is either unbound or explicitly set to `True`, the attribute is configurable and can take a `select()` value. For an attribute of a rule or aspect, `configurable` must be left unbound. Most Starlark rule attributes are always configurable, with the exception of `attr.output()`, `attr.output_list()`, and `attr.license()` rule attributes, which are always non-configurable. |
-| `default` | [sequence](../core/list) of [int](../core/int)s; default is `[]`  A default value to use if no value for this attribute is given when instantiating the rule. |
-| `doc` | [string](../core/string); or `None`; default is `None`  A description of the attribute that can be extracted by documentation generating tools. |
+| `mandatory` | [bool](/versions/8.0.1/rules/lib/core/bool); default is `False`  If true, the value must be specified explicitly (even if it has a `default`). |
+| `allow_empty` | [bool](/versions/8.0.1/rules/lib/core/bool); default is `True`  True if the attribute can be empty. |
+| `configurable` | [bool](/versions/8.0.1/rules/lib/core/bool); or unbound; default is `unbound`  This argument can only be specified for an attribute of a symbolic macro. If `configurable` is explicitly set to `False`, the symbolic macro attribute is non-configurable - in other words, it cannot take a `select()` value. If the `configurable` is either unbound or explicitly set to `True`, the attribute is configurable and can take a `select()` value. For an attribute of a rule or aspect, `configurable` must be left unbound. Most Starlark rule attributes are always configurable, with the exception of `attr.output()`, `attr.output_list()`, and `attr.license()` rule attributes, which are always non-configurable. |
+| `default` | [sequence](/versions/8.0.1/rules/lib/core/list) of [int](/versions/8.0.1/rules/lib/core/int)s; default is `[]`  A default value to use if no value for this attribute is given when instantiating the rule. |
+| `doc` | [string](/versions/8.0.1/rules/lib/core/string); or `None`; default is `None`  A description of the attribute that can be extracted by documentation generating tools. |
 
 ## label
 
@@ -84,9 +84,9 @@ Attribute attr.label(configurable=unbound, default=None, materializer=None, doc=
 
 Creates a schema for a label attribute. This is a dependency attribute.
 
-This attribute contains unique [`Label`](../builtins/Label) values. If a string is supplied in place of a `Label`, it will be converted using the [label constructor](../builtins/Label#Label). The relative parts of the label path, including the (possibly renamed) repository, are resolved with respect to the instantiated target's package.
+This attribute contains unique [`Label`](/versions/8.0.1/rules/lib/builtins/Label) values. If a string is supplied in place of a `Label`, it will be converted using the [label constructor](/versions/8.0.1/rules/lib/builtins/Label#Label). The relative parts of the label path, including the (possibly renamed) repository, are resolved with respect to the instantiated target's package.
 
-At analysis time (within the rule's implementation function), when retrieving the attribute value from `ctx.attr`, labels are replaced by the corresponding [`Target`](../builtins/Target)s. This allows you to access the providers of the current target's dependencies.
+At analysis time (within the rule's implementation function), when retrieving the attribute value from `ctx.attr`, labels are replaced by the corresponding [`Target`](/versions/8.0.1/rules/lib/builtins/Target)s. This allows you to access the providers of the current target's dependencies.
 
 In addition to ordinary source files, this kind of attribute is often used to refer to a tool -- for example, a compiler. Such tools are considered to be dependencies, just like source files. To avoid requiring users to specify the tool's label every time they use the rule in their BUILD files, you can hard-code the label of a canonical tool as the `default` value of this attribute. If you also want to prevent users from overriding this default, you can make the attribute private by giving it a name that starts with an underscore. See the [Rules](https://bazel.build/versions/8.0.1/extending/rules#private-attributes) page for more information.
 
@@ -94,21 +94,21 @@ In addition to ordinary source files, this kind of attribute is often used to re
 
 | Parameter | Description |
 | --- | --- |
-| `configurable` | [bool](../core/bool); or unbound; default is `unbound`  This argument can only be specified for an attribute of a symbolic macro. If `configurable` is explicitly set to `False`, the symbolic macro attribute is non-configurable - in other words, it cannot take a `select()` value. If the `configurable` is either unbound or explicitly set to `True`, the attribute is configurable and can take a `select()` value. For an attribute of a rule or aspect, `configurable` must be left unbound. Most Starlark rule attributes are always configurable, with the exception of `attr.output()`, `attr.output_list()`, and `attr.license()` rule attributes, which are always non-configurable. |
-| `default` | [Label](../builtins/Label); or [string](../core/string); or [LateBoundDefault](../builtins/LateBoundDefault); or NativeComputedDefault; or [function](../core/function); or `None`; default is `None`  A default value to use if no value for this attribute is given when instantiating the rule.Use a string or the [`Label`](../builtins/Label#Label) function to specify a default value, for example, `attr.label(default = "//a:b")`. |
-| `materializer` | [function](../core/function); default is `None`  **Experimental**. This parameter is experimental and may change at any time. Please do not depend on it. It may be enabled on an experimental basis by setting `--experimental_dormant_deps`  If set, the attribute materializes dormant dependencies from the transitive closure. The value of this parameter must be a functon that gets access to the values of the attributes of the rule that either are not dependencies or are marked as available for dependency resolution. It must return either a dormant dependency or a list of them depending on the type of the attribute |
-| `doc` | [string](../core/string); or `None`; default is `None` |
-| `executable` | [bool](../core/bool); default is `False`  True if the dependency has to be executable. This means the label must refer to an executable file, or to a rule that outputs an executable file. Access the label with `ctx.executable.`. |
-| `allow_files` | [bool](../core/bool); or [sequence](../core/list) of [string](../core/string)s; or `None`; default is `None`  Whether `File` targets are allowed. Can be `True`, `False` (default), or a list of file extensions that are allowed (for example, `[".cc", ".cpp"]`). |
-| `allow_single_file` | default is `None`  This is similar to `allow_files`, with the restriction that the label must correspond to a single [File](../builtins/File). Access it through `ctx.file.`. |
-| `mandatory` | [bool](../core/bool); default is `False`  If true, the value must be specified explicitly (even if it has a `default`). |
-| `skip_validations` | [bool](../core/bool); default is `False`  If true, validation actions of transitive dependencies from this attribute will not run. This is a temporary mitigation and WILL be removed in the future. |
-| `providers` | [sequence](../core/list); default is `[]`  The providers that must be given by any dependency appearing in this attribute. The format of this argument is a list of lists of providers -- `*Info` objects returned by [`provider()`](../globals/bzl#provider) (or in the case of a legacy provider, its string name). The dependency must return ALL providers mentioned in at least ONE of the inner lists. As a convenience, this argument may also be a single-level list of providers, in which case it is wrapped in an outer list with one element. It is NOT required that the rule of the dependency advertises those providers in its `provides` parameter, however, it is considered best practice. |
+| `configurable` | [bool](/versions/8.0.1/rules/lib/core/bool); or unbound; default is `unbound`  This argument can only be specified for an attribute of a symbolic macro. If `configurable` is explicitly set to `False`, the symbolic macro attribute is non-configurable - in other words, it cannot take a `select()` value. If the `configurable` is either unbound or explicitly set to `True`, the attribute is configurable and can take a `select()` value. For an attribute of a rule or aspect, `configurable` must be left unbound. Most Starlark rule attributes are always configurable, with the exception of `attr.output()`, `attr.output_list()`, and `attr.license()` rule attributes, which are always non-configurable. |
+| `default` | [Label](/versions/8.0.1/rules/lib/builtins/Label); or [string](/versions/8.0.1/rules/lib/core/string); or [LateBoundDefault](/versions/8.0.1/rules/lib/builtins/LateBoundDefault); or NativeComputedDefault; or [function](/versions/8.0.1/rules/lib/core/function); or `None`; default is `None`  A default value to use if no value for this attribute is given when instantiating the rule.Use a string or the [`Label`](/versions/8.0.1/rules/lib/builtins/Label#Label) function to specify a default value, for example, `attr.label(default = "//a:b")`. |
+| `materializer` | [function](/versions/8.0.1/rules/lib/core/function); default is `None`  **Experimental**. This parameter is experimental and may change at any time. Please do not depend on it. It may be enabled on an experimental basis by setting `--experimental_dormant_deps`  If set, the attribute materializes dormant dependencies from the transitive closure. The value of this parameter must be a functon that gets access to the values of the attributes of the rule that either are not dependencies or are marked as available for dependency resolution. It must return either a dormant dependency or a list of them depending on the type of the attribute |
+| `doc` | [string](/versions/8.0.1/rules/lib/core/string); or `None`; default is `None` |
+| `executable` | [bool](/versions/8.0.1/rules/lib/core/bool); default is `False`  True if the dependency has to be executable. This means the label must refer to an executable file, or to a rule that outputs an executable file. Access the label with `ctx.executable.`. |
+| `allow_files` | [bool](/versions/8.0.1/rules/lib/core/bool); or [sequence](/versions/8.0.1/rules/lib/core/list) of [string](/versions/8.0.1/rules/lib/core/string)s; or `None`; default is `None`  Whether `File` targets are allowed. Can be `True`, `False` (default), or a list of file extensions that are allowed (for example, `[".cc", ".cpp"]`). |
+| `allow_single_file` | default is `None`  This is similar to `allow_files`, with the restriction that the label must correspond to a single [File](/versions/8.0.1/rules/lib/builtins/File). Access it through `ctx.file.`. |
+| `mandatory` | [bool](/versions/8.0.1/rules/lib/core/bool); default is `False`  If true, the value must be specified explicitly (even if it has a `default`). |
+| `skip_validations` | [bool](/versions/8.0.1/rules/lib/core/bool); default is `False`  If true, validation actions of transitive dependencies from this attribute will not run. This is a temporary mitigation and WILL be removed in the future. |
+| `providers` | [sequence](/versions/8.0.1/rules/lib/core/list); default is `[]`  The providers that must be given by any dependency appearing in this attribute. The format of this argument is a list of lists of providers -- `*Info` objects returned by [`provider()`](/versions/8.0.1/rules/lib/globals/bzl#provider) (or in the case of a legacy provider, its string name). The dependency must return ALL providers mentioned in at least ONE of the inner lists. As a convenience, this argument may also be a single-level list of providers, in which case it is wrapped in an outer list with one element. It is NOT required that the rule of the dependency advertises those providers in its `provides` parameter, however, it is considered best practice. |
 | `for_dependency_resolution` | default is `unbound`  If this is set, the attribute is available for materializers. Only rules marked with the flag of the same name are allowed to be referenced through such attributes. |
-| `allow_rules` | [sequence](../core/list) of [string](../core/string)s; or `None`; default is `None`  Which rule targets (name of the classes) are allowed. This is deprecated (kept only for compatibility), use providers instead. |
+| `allow_rules` | [sequence](/versions/8.0.1/rules/lib/core/list) of [string](/versions/8.0.1/rules/lib/core/string)s; or `None`; default is `None`  Which rule targets (name of the classes) are allowed. This is deprecated (kept only for compatibility), use providers instead. |
 | `cfg` | default is `None`  [Configuration](https://bazel.build/versions/8.0.1/extending/rules#configurations) of the attribute. It can be either `"exec"`, which indicates that the dependency is built for the `execution platform`, or `"target"`, which indicates that the dependency is build for the `target platform`. A typical example of the difference is when building mobile apps, where the `target platform` is `Android` or `iOS` while the `execution platform` is `Linux`, `macOS`, or `Windows`. This parameter is required if `executable` is True to guard against accidentally building host tools in the target configuration. `"target"` has no semantic effect, so don't set it when `executable` is False unless it really helps clarify your intentions. |
-| `aspects` | [sequence](../core/list) of [Aspect](../builtins/Aspect)s; default is `[]`  Aspects that should be applied to the dependency or dependencies specified by this attribute. |
-| `flags` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  Deprecated, will be removed. |
+| `aspects` | [sequence](/versions/8.0.1/rules/lib/core/list) of [Aspect](/versions/8.0.1/rules/lib/builtins/Aspect)s; default is `[]`  Aspects that should be applied to the dependency or dependencies specified by this attribute. |
+| `flags` | [sequence](/versions/8.0.1/rules/lib/core/list) of [string](/versions/8.0.1/rules/lib/core/string)s; default is `[]`  Deprecated, will be removed. |
 
 ## label\_keyed\_string\_dict
 
@@ -118,26 +118,26 @@ Attribute attr.label_keyed_string_dict(allow_empty=True, *, configurable=unbound
 
 Creates a schema for an attribute holding a dictionary, where the keys are labels and the values are strings. This is a dependency attribute.
 
-This attribute contains unique [`Label`](../builtins/Label) values. If a string is supplied in place of a `Label`, it will be converted using the [label constructor](../builtins/Label#Label). The relative parts of the label path, including the (possibly renamed) repository, are resolved with respect to the instantiated target's package.
+This attribute contains unique [`Label`](/versions/8.0.1/rules/lib/builtins/Label) values. If a string is supplied in place of a `Label`, it will be converted using the [label constructor](/versions/8.0.1/rules/lib/builtins/Label#Label). The relative parts of the label path, including the (possibly renamed) repository, are resolved with respect to the instantiated target's package.
 
-At analysis time (within the rule's implementation function), when retrieving the attribute value from `ctx.attr`, labels are replaced by the corresponding [`Target`](../builtins/Target)s. This allows you to access the providers of the current target's dependencies.
+At analysis time (within the rule's implementation function), when retrieving the attribute value from `ctx.attr`, labels are replaced by the corresponding [`Target`](/versions/8.0.1/rules/lib/builtins/Target)s. This allows you to access the providers of the current target's dependencies.
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `allow_empty` | [bool](../core/bool); default is `True`  True if the attribute can be empty. |
-| `configurable` | [bool](../core/bool); or unbound; default is `unbound`  This argument can only be specified for an attribute of a symbolic macro. If `configurable` is explicitly set to `False`, the symbolic macro attribute is non-configurable - in other words, it cannot take a `select()` value. If the `configurable` is either unbound or explicitly set to `True`, the attribute is configurable and can take a `select()` value. For an attribute of a rule or aspect, `configurable` must be left unbound. Most Starlark rule attributes are always configurable, with the exception of `attr.output()`, `attr.output_list()`, and `attr.license()` rule attributes, which are always non-configurable. |
-| `default` | [dict](../core/dict); or [function](../core/function); default is `{}`  A default value to use if no value for this attribute is given when instantiating the rule.Use strings or the [`Label`](../builtins/Label#Label) function to specify default values, for example, `attr.label_keyed_string_dict(default = {"//a:b": "value", "//a:c": "string"})`. |
-| `doc` | [string](../core/string); or `None`; default is `None`  A description of the attribute that can be extracted by documentation generating tools. |
-| `allow_files` | [bool](../core/bool); or [sequence](../core/list) of [string](../core/string)s; or `None`; default is `None`  Whether `File` targets are allowed. Can be `True`, `False` (default), or a list of file extensions that are allowed (for example, `[".cc", ".cpp"]`). |
-| `allow_rules` | [sequence](../core/list) of [string](../core/string)s; or `None`; default is `None`  Which rule targets (name of the classes) are allowed. This is deprecated (kept only for compatibility), use providers instead. |
-| `providers` | [sequence](../core/list); default is `[]`  The providers that must be given by any dependency appearing in this attribute. The format of this argument is a list of lists of providers -- `*Info` objects returned by [`provider()`](../globals/bzl#provider) (or in the case of a legacy provider, its string name). The dependency must return ALL providers mentioned in at least ONE of the inner lists. As a convenience, this argument may also be a single-level list of providers, in which case it is wrapped in an outer list with one element. It is NOT required that the rule of the dependency advertises those providers in its `provides` parameter, however, it is considered best practice. |
+| `allow_empty` | [bool](/versions/8.0.1/rules/lib/core/bool); default is `True`  True if the attribute can be empty. |
+| `configurable` | [bool](/versions/8.0.1/rules/lib/core/bool); or unbound; default is `unbound`  This argument can only be specified for an attribute of a symbolic macro. If `configurable` is explicitly set to `False`, the symbolic macro attribute is non-configurable - in other words, it cannot take a `select()` value. If the `configurable` is either unbound or explicitly set to `True`, the attribute is configurable and can take a `select()` value. For an attribute of a rule or aspect, `configurable` must be left unbound. Most Starlark rule attributes are always configurable, with the exception of `attr.output()`, `attr.output_list()`, and `attr.license()` rule attributes, which are always non-configurable. |
+| `default` | [dict](/versions/8.0.1/rules/lib/core/dict); or [function](/versions/8.0.1/rules/lib/core/function); default is `{}`  A default value to use if no value for this attribute is given when instantiating the rule.Use strings or the [`Label`](/versions/8.0.1/rules/lib/builtins/Label#Label) function to specify default values, for example, `attr.label_keyed_string_dict(default = {"//a:b": "value", "//a:c": "string"})`. |
+| `doc` | [string](/versions/8.0.1/rules/lib/core/string); or `None`; default is `None`  A description of the attribute that can be extracted by documentation generating tools. |
+| `allow_files` | [bool](/versions/8.0.1/rules/lib/core/bool); or [sequence](/versions/8.0.1/rules/lib/core/list) of [string](/versions/8.0.1/rules/lib/core/string)s; or `None`; default is `None`  Whether `File` targets are allowed. Can be `True`, `False` (default), or a list of file extensions that are allowed (for example, `[".cc", ".cpp"]`). |
+| `allow_rules` | [sequence](/versions/8.0.1/rules/lib/core/list) of [string](/versions/8.0.1/rules/lib/core/string)s; or `None`; default is `None`  Which rule targets (name of the classes) are allowed. This is deprecated (kept only for compatibility), use providers instead. |
+| `providers` | [sequence](/versions/8.0.1/rules/lib/core/list); default is `[]`  The providers that must be given by any dependency appearing in this attribute. The format of this argument is a list of lists of providers -- `*Info` objects returned by [`provider()`](/versions/8.0.1/rules/lib/globals/bzl#provider) (or in the case of a legacy provider, its string name). The dependency must return ALL providers mentioned in at least ONE of the inner lists. As a convenience, this argument may also be a single-level list of providers, in which case it is wrapped in an outer list with one element. It is NOT required that the rule of the dependency advertises those providers in its `provides` parameter, however, it is considered best practice. |
 | `for_dependency_resolution` | default is `unbound`  If this is set, the attribute is available for materializers. Only rules marked with the flag of the same name are allowed to be referenced through such attributes. |
-| `flags` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  Deprecated, will be removed. |
-| `mandatory` | [bool](../core/bool); default is `False`  If true, the value must be specified explicitly (even if it has a `default`). |
+| `flags` | [sequence](/versions/8.0.1/rules/lib/core/list) of [string](/versions/8.0.1/rules/lib/core/string)s; default is `[]`  Deprecated, will be removed. |
+| `mandatory` | [bool](/versions/8.0.1/rules/lib/core/bool); default is `False`  If true, the value must be specified explicitly (even if it has a `default`). |
 | `cfg` | default is `None`  [Configuration](https://bazel.build/versions/8.0.1/extending/rules#configurations) of the attribute. It can be either `"exec"`, which indicates that the dependency is built for the `execution platform`, or `"target"`, which indicates that the dependency is build for the `target platform`. A typical example of the difference is when building mobile apps, where the `target platform` is `Android` or `iOS` while the `execution platform` is `Linux`, `macOS`, or `Windows`. |
-| `aspects` | [sequence](../core/list) of [Aspect](../builtins/Aspect)s; default is `[]`  Aspects that should be applied to the dependency or dependencies specified by this attribute. |
+| `aspects` | [sequence](/versions/8.0.1/rules/lib/core/list) of [Aspect](/versions/8.0.1/rules/lib/builtins/Aspect)s; default is `[]`  Aspects that should be applied to the dependency or dependencies specified by this attribute. |
 
 ## label\_list
 
@@ -145,30 +145,30 @@ At analysis time (within the rule's implementation function), when retrieving th
 Attribute attr.label_list(allow_empty=True, *, configurable=unbound, default=[], materializer=None, doc=None, allow_files=None, allow_rules=None, providers=[], for_dependency_resolution=unbound, flags=[], mandatory=False, skip_validations=False, cfg=None, aspects=[])
 ```
 
-Creates a schema for a list-of-labels attribute. This is a dependency attribute. The corresponding [`ctx.attr`](../builtins/ctx#attr) attribute will be of type [list](../core/list) of [`Target`s](../builtins/Target).
+Creates a schema for a list-of-labels attribute. This is a dependency attribute. The corresponding [`ctx.attr`](/versions/8.0.1/rules/lib/builtins/ctx#attr) attribute will be of type [list](/versions/8.0.1/rules/lib/core/list) of [`Target`s](/versions/8.0.1/rules/lib/builtins/Target).
 
-This attribute contains unique [`Label`](../builtins/Label) values. If a string is supplied in place of a `Label`, it will be converted using the [label constructor](../builtins/Label#Label). The relative parts of the label path, including the (possibly renamed) repository, are resolved with respect to the instantiated target's package.
+This attribute contains unique [`Label`](/versions/8.0.1/rules/lib/builtins/Label) values. If a string is supplied in place of a `Label`, it will be converted using the [label constructor](/versions/8.0.1/rules/lib/builtins/Label#Label). The relative parts of the label path, including the (possibly renamed) repository, are resolved with respect to the instantiated target's package.
 
-At analysis time (within the rule's implementation function), when retrieving the attribute value from `ctx.attr`, labels are replaced by the corresponding [`Target`](../builtins/Target)s. This allows you to access the providers of the current target's dependencies.
+At analysis time (within the rule's implementation function), when retrieving the attribute value from `ctx.attr`, labels are replaced by the corresponding [`Target`](/versions/8.0.1/rules/lib/builtins/Target)s. This allows you to access the providers of the current target's dependencies.
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `allow_empty` | [bool](../core/bool); default is `True`  True if the attribute can be empty. |
-| `configurable` | [bool](../core/bool); or unbound; default is `unbound`  This argument can only be specified for an attribute of a symbolic macro. If `configurable` is explicitly set to `False`, the symbolic macro attribute is non-configurable - in other words, it cannot take a `select()` value. If the `configurable` is either unbound or explicitly set to `True`, the attribute is configurable and can take a `select()` value. For an attribute of a rule or aspect, `configurable` must be left unbound. Most Starlark rule attributes are always configurable, with the exception of `attr.output()`, `attr.output_list()`, and `attr.license()` rule attributes, which are always non-configurable. |
-| `default` | [sequence](../core/list) of [Label](../builtins/Label)s; or [function](../core/function); default is `[]`  A default value to use if no value for this attribute is given when instantiating the rule.Use strings or the [`Label`](../builtins/Label#Label) function to specify default values, for example, `attr.label_list(default = ["//a:b", "//a:c"])`. |
-| `materializer` | [function](../core/function); default is `None`  **Experimental**. This parameter is experimental and may change at any time. Please do not depend on it. It may be enabled on an experimental basis by setting `--experimental_dormant_deps`  If set, the attribute materializes dormant dependencies from the transitive closure. The value of this parameter must be a functon that gets access to the values of the attributes of the rule that either are not dependencies or are marked as available for dependency resolution. It must return either a dormant dependency or a list of them depending on the type of the attribute |
-| `doc` | [string](../core/string); or `None`; default is `None` |
-| `allow_files` | [bool](../core/bool); or [sequence](../core/list) of [string](../core/string)s; or `None`; default is `None`  Whether `File` targets are allowed. Can be `True`, `False` (default), or a list of file extensions that are allowed (for example, `[".cc", ".cpp"]`). |
-| `allow_rules` | [sequence](../core/list) of [string](../core/string)s; or `None`; default is `None`  Which rule targets (name of the classes) are allowed. This is deprecated (kept only for compatibility), use providers instead. |
-| `providers` | [sequence](../core/list); default is `[]`  The providers that must be given by any dependency appearing in this attribute. The format of this argument is a list of lists of providers -- `*Info` objects returned by [`provider()`](../globals/bzl#provider) (or in the case of a legacy provider, its string name). The dependency must return ALL providers mentioned in at least ONE of the inner lists. As a convenience, this argument may also be a single-level list of providers, in which case it is wrapped in an outer list with one element. It is NOT required that the rule of the dependency advertises those providers in its `provides` parameter, however, it is considered best practice. |
+| `allow_empty` | [bool](/versions/8.0.1/rules/lib/core/bool); default is `True`  True if the attribute can be empty. |
+| `configurable` | [bool](/versions/8.0.1/rules/lib/core/bool); or unbound; default is `unbound`  This argument can only be specified for an attribute of a symbolic macro. If `configurable` is explicitly set to `False`, the symbolic macro attribute is non-configurable - in other words, it cannot take a `select()` value. If the `configurable` is either unbound or explicitly set to `True`, the attribute is configurable and can take a `select()` value. For an attribute of a rule or aspect, `configurable` must be left unbound. Most Starlark rule attributes are always configurable, with the exception of `attr.output()`, `attr.output_list()`, and `attr.license()` rule attributes, which are always non-configurable. |
+| `default` | [sequence](/versions/8.0.1/rules/lib/core/list) of [Label](/versions/8.0.1/rules/lib/builtins/Label)s; or [function](/versions/8.0.1/rules/lib/core/function); default is `[]`  A default value to use if no value for this attribute is given when instantiating the rule.Use strings or the [`Label`](/versions/8.0.1/rules/lib/builtins/Label#Label) function to specify default values, for example, `attr.label_list(default = ["//a:b", "//a:c"])`. |
+| `materializer` | [function](/versions/8.0.1/rules/lib/core/function); default is `None`  **Experimental**. This parameter is experimental and may change at any time. Please do not depend on it. It may be enabled on an experimental basis by setting `--experimental_dormant_deps`  If set, the attribute materializes dormant dependencies from the transitive closure. The value of this parameter must be a functon that gets access to the values of the attributes of the rule that either are not dependencies or are marked as available for dependency resolution. It must return either a dormant dependency or a list of them depending on the type of the attribute |
+| `doc` | [string](/versions/8.0.1/rules/lib/core/string); or `None`; default is `None` |
+| `allow_files` | [bool](/versions/8.0.1/rules/lib/core/bool); or [sequence](/versions/8.0.1/rules/lib/core/list) of [string](/versions/8.0.1/rules/lib/core/string)s; or `None`; default is `None`  Whether `File` targets are allowed. Can be `True`, `False` (default), or a list of file extensions that are allowed (for example, `[".cc", ".cpp"]`). |
+| `allow_rules` | [sequence](/versions/8.0.1/rules/lib/core/list) of [string](/versions/8.0.1/rules/lib/core/string)s; or `None`; default is `None`  Which rule targets (name of the classes) are allowed. This is deprecated (kept only for compatibility), use providers instead. |
+| `providers` | [sequence](/versions/8.0.1/rules/lib/core/list); default is `[]`  The providers that must be given by any dependency appearing in this attribute. The format of this argument is a list of lists of providers -- `*Info` objects returned by [`provider()`](/versions/8.0.1/rules/lib/globals/bzl#provider) (or in the case of a legacy provider, its string name). The dependency must return ALL providers mentioned in at least ONE of the inner lists. As a convenience, this argument may also be a single-level list of providers, in which case it is wrapped in an outer list with one element. It is NOT required that the rule of the dependency advertises those providers in its `provides` parameter, however, it is considered best practice. |
 | `for_dependency_resolution` | default is `unbound`  If this is set, the attribute is available for materializers. Only rules marked with the flag of the same name are allowed to be referenced through such attributes. |
-| `flags` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  Deprecated, will be removed. |
-| `mandatory` | [bool](../core/bool); default is `False`  If true, the value must be specified explicitly (even if it has a `default`). |
-| `skip_validations` | [bool](../core/bool); default is `False`  If true, validation actions of transitive dependencies from this attribute will not run. This is a temporary mitigation and WILL be removed in the future. |
+| `flags` | [sequence](/versions/8.0.1/rules/lib/core/list) of [string](/versions/8.0.1/rules/lib/core/string)s; default is `[]`  Deprecated, will be removed. |
+| `mandatory` | [bool](/versions/8.0.1/rules/lib/core/bool); default is `False`  If true, the value must be specified explicitly (even if it has a `default`). |
+| `skip_validations` | [bool](/versions/8.0.1/rules/lib/core/bool); default is `False`  If true, validation actions of transitive dependencies from this attribute will not run. This is a temporary mitigation and WILL be removed in the future. |
 | `cfg` | default is `None`  [Configuration](https://bazel.build/versions/8.0.1/extending/rules#configurations) of the attribute. It can be either `"exec"`, which indicates that the dependency is built for the `execution platform`, or `"target"`, which indicates that the dependency is build for the `target platform`. A typical example of the difference is when building mobile apps, where the `target platform` is `Android` or `iOS` while the `execution platform` is `Linux`, `macOS`, or `Windows`. |
-| `aspects` | [sequence](../core/list) of [Aspect](../builtins/Aspect)s; default is `[]`  Aspects that should be applied to the dependency or dependencies specified by this attribute. |
+| `aspects` | [sequence](/versions/8.0.1/rules/lib/core/list) of [Aspect](/versions/8.0.1/rules/lib/builtins/Aspect)s; default is `[]`  Aspects that should be applied to the dependency or dependencies specified by this attribute. |
 
 ## output
 
@@ -178,16 +178,16 @@ Attribute attr.output(doc=None, mandatory=False)
 
 Creates a schema for an output (label) attribute.
 
-This attribute contains unique [`Label`](../builtins/Label) values. If a string is supplied in place of a `Label`, it will be converted using the [label constructor](../builtins/Label#Label). The relative parts of the label path, including the (possibly renamed) repository, are resolved with respect to the instantiated target's package.
+This attribute contains unique [`Label`](/versions/8.0.1/rules/lib/builtins/Label) values. If a string is supplied in place of a `Label`, it will be converted using the [label constructor](/versions/8.0.1/rules/lib/builtins/Label#Label). The relative parts of the label path, including the (possibly renamed) repository, are resolved with respect to the instantiated target's package.
 
-At analysis time, the corresponding [`File`](../builtins/File) can be retrieved using [`ctx.outputs`](../builtins/ctx#outputs).
+At analysis time, the corresponding [`File`](/versions/8.0.1/rules/lib/builtins/File) can be retrieved using [`ctx.outputs`](/versions/8.0.1/rules/lib/builtins/ctx#outputs).
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `doc` | [string](../core/string); or `None`; default is `None`  A description of the attribute that can be extracted by documentation generating tools. |
-| `mandatory` | [bool](../core/bool); default is `False`  If true, the value must be specified explicitly (even if it has a `default`). |
+| `doc` | [string](/versions/8.0.1/rules/lib/core/string); or `None`; default is `None`  A description of the attribute that can be extracted by documentation generating tools. |
+| `mandatory` | [bool](/versions/8.0.1/rules/lib/core/bool); default is `False`  If true, the value must be specified explicitly (even if it has a `default`). |
 
 ## output\_list
 
@@ -197,17 +197,17 @@ Attribute attr.output_list(allow_empty=True, *, doc=None, mandatory=False)
 
 Creates a schema for a list-of-outputs attribute.
 
-This attribute contains unique [`Label`](../builtins/Label) values. If a string is supplied in place of a `Label`, it will be converted using the [label constructor](../builtins/Label#Label). The relative parts of the label path, including the (possibly renamed) repository, are resolved with respect to the instantiated target's package.
+This attribute contains unique [`Label`](/versions/8.0.1/rules/lib/builtins/Label) values. If a string is supplied in place of a `Label`, it will be converted using the [label constructor](/versions/8.0.1/rules/lib/builtins/Label#Label). The relative parts of the label path, including the (possibly renamed) repository, are resolved with respect to the instantiated target's package.
 
-At analysis time, the corresponding [`File`](../builtins/File) can be retrieved using [`ctx.outputs`](../builtins/ctx#outputs).
+At analysis time, the corresponding [`File`](/versions/8.0.1/rules/lib/builtins/File) can be retrieved using [`ctx.outputs`](/versions/8.0.1/rules/lib/builtins/ctx#outputs).
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `allow_empty` | [bool](../core/bool); default is `True`  True if the attribute can be empty. |
-| `doc` | [string](../core/string); or `None`; default is `None`  A description of the attribute that can be extracted by documentation generating tools. |
-| `mandatory` | [bool](../core/bool); default is `False`  If true, the value must be specified explicitly (even if it has a `default`). |
+| `allow_empty` | [bool](/versions/8.0.1/rules/lib/core/bool); default is `True`  True if the attribute can be empty. |
+| `doc` | [string](/versions/8.0.1/rules/lib/core/string); or `None`; default is `None`  A description of the attribute that can be extracted by documentation generating tools. |
+| `mandatory` | [bool](/versions/8.0.1/rules/lib/core/bool); default is `False`  If true, the value must be specified explicitly (even if it has a `default`). |
 
 ## string
 
@@ -215,17 +215,17 @@ At analysis time, the corresponding [`File`](../builtins/File) can be retrieved
 Attribute attr.string(configurable=unbound, default='', doc=None, mandatory=False, values=[])
 ```
 
-Creates a schema for a [string](../core/string#attr) attribute.
+Creates a schema for a [string](/versions/8.0.1/rules/lib/core/string#attr) attribute.
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `configurable` | [bool](../core/bool); or unbound; default is `unbound`  This argument can only be specified for an attribute of a symbolic macro. If `configurable` is explicitly set to `False`, the symbolic macro attribute is non-configurable - in other words, it cannot take a `select()` value. If the `configurable` is either unbound or explicitly set to `True`, the attribute is configurable and can take a `select()` value. For an attribute of a rule or aspect, `configurable` must be left unbound. Most Starlark rule attributes are always configurable, with the exception of `attr.output()`, `attr.output_list()`, and `attr.license()` rule attributes, which are always non-configurable. |
-| `default` | [string](../core/string); or NativeComputedDefault; default is `''`  A default value to use if no value for this attribute is given when instantiating the rule. |
-| `doc` | [string](../core/string); or `None`; default is `None`  A description of the attribute that can be extracted by documentation generating tools. |
-| `mandatory` | [bool](../core/bool); default is `False`  If true, the value must be specified explicitly (even if it has a `default`). |
-| `values` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  The list of allowed values for the attribute. An error is raised if any other value is given. |
+| `configurable` | [bool](/versions/8.0.1/rules/lib/core/bool); or unbound; default is `unbound`  This argument can only be specified for an attribute of a symbolic macro. If `configurable` is explicitly set to `False`, the symbolic macro attribute is non-configurable - in other words, it cannot take a `select()` value. If the `configurable` is either unbound or explicitly set to `True`, the attribute is configurable and can take a `select()` value. For an attribute of a rule or aspect, `configurable` must be left unbound. Most Starlark rule attributes are always configurable, with the exception of `attr.output()`, `attr.output_list()`, and `attr.license()` rule attributes, which are always non-configurable. |
+| `default` | [string](/versions/8.0.1/rules/lib/core/string); or NativeComputedDefault; default is `''`  A default value to use if no value for this attribute is given when instantiating the rule. |
+| `doc` | [string](/versions/8.0.1/rules/lib/core/string); or `None`; default is `None`  A description of the attribute that can be extracted by documentation generating tools. |
+| `mandatory` | [bool](/versions/8.0.1/rules/lib/core/bool); default is `False`  If true, the value must be specified explicitly (even if it has a `default`). |
+| `values` | [sequence](/versions/8.0.1/rules/lib/core/list) of [string](/versions/8.0.1/rules/lib/core/string)s; default is `[]`  The list of allowed values for the attribute. An error is raised if any other value is given. |
 
 ## string\_dict
 
@@ -239,11 +239,11 @@ Creates a schema for an attribute holding a dictionary, where the keys and value
 
 | Parameter | Description |
 | --- | --- |
-| `allow_empty` | [bool](../core/bool); default is `True`  True if the attribute can be empty. |
-| `configurable` | [bool](../core/bool); or unbound; default is `unbound`  This argument can only be specified for an attribute of a symbolic macro. If `configurable` is explicitly set to `False`, the symbolic macro attribute is non-configurable - in other words, it cannot take a `select()` value. If the `configurable` is either unbound or explicitly set to `True`, the attribute is configurable and can take a `select()` value. For an attribute of a rule or aspect, `configurable` must be left unbound. Most Starlark rule attributes are always configurable, with the exception of `attr.output()`, `attr.output_list()`, and `attr.license()` rule attributes, which are always non-configurable. |
-| `default` | [dict](../core/dict); default is `{}`  A default value to use if no value for this attribute is given when instantiating the rule. |
-| `doc` | [string](../core/string); or `None`; default is `None`  A description of the attribute that can be extracted by documentation generating tools. |
-| `mandatory` | [bool](../core/bool); default is `False`  If true, the value must be specified explicitly (even if it has a `default`). |
+| `allow_empty` | [bool](/versions/8.0.1/rules/lib/core/bool); default is `True`  True if the attribute can be empty. |
+| `configurable` | [bool](/versions/8.0.1/rules/lib/core/bool); or unbound; default is `unbound`  This argument can only be specified for an attribute of a symbolic macro. If `configurable` is explicitly set to `False`, the symbolic macro attribute is non-configurable - in other words, it cannot take a `select()` value. If the `configurable` is either unbound or explicitly set to `True`, the attribute is configurable and can take a `select()` value. For an attribute of a rule or aspect, `configurable` must be left unbound. Most Starlark rule attributes are always configurable, with the exception of `attr.output()`, `attr.output_list()`, and `attr.license()` rule attributes, which are always non-configurable. |
+| `default` | [dict](/versions/8.0.1/rules/lib/core/dict); default is `{}`  A default value to use if no value for this attribute is given when instantiating the rule. |
+| `doc` | [string](/versions/8.0.1/rules/lib/core/string); or `None`; default is `None`  A description of the attribute that can be extracted by documentation generating tools. |
+| `mandatory` | [bool](/versions/8.0.1/rules/lib/core/bool); default is `False`  If true, the value must be specified explicitly (even if it has a `default`). |
 
 ## string\_keyed\_label\_dict
 
@@ -253,26 +253,26 @@ Attribute attr.string_keyed_label_dict(allow_empty=True, *, configurable=unbound
 
 Creates a schema for an attribute whose value is a dictionary where the keys are strings and the values are labels. This is a dependency attribute.
 
-This attribute contains unique [`Label`](../builtins/Label) values. If a string is supplied in place of a `Label`, it will be converted using the [label constructor](../builtins/Label#Label). The relative parts of the label path, including the (possibly renamed) repository, are resolved with respect to the instantiated target's package.
+This attribute contains unique [`Label`](/versions/8.0.1/rules/lib/builtins/Label) values. If a string is supplied in place of a `Label`, it will be converted using the [label constructor](/versions/8.0.1/rules/lib/builtins/Label#Label). The relative parts of the label path, including the (possibly renamed) repository, are resolved with respect to the instantiated target's package.
 
-At analysis time (within the rule's implementation function), when retrieving the attribute value from `ctx.attr`, labels are replaced by the corresponding [`Target`](../builtins/Target)s. This allows you to access the providers of the current target's dependencies.
+At analysis time (within the rule's implementation function), when retrieving the attribute value from `ctx.attr`, labels are replaced by the corresponding [`Target`](/versions/8.0.1/rules/lib/builtins/Target)s. This allows you to access the providers of the current target's dependencies.
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `allow_empty` | [bool](../core/bool); default is `True`  True if the attribute can be empty. |
-| `configurable` | [bool](../core/bool); or unbound; default is `unbound`  This argument can only be specified for an attribute of a symbolic macro. If `configurable` is explicitly set to `False`, the symbolic macro attribute is non-configurable - in other words, it cannot take a `select()` value. If the `configurable` is either unbound or explicitly set to `True`, the attribute is configurable and can take a `select()` value. For an attribute of a rule or aspect, `configurable` must be left unbound. Most Starlark rule attributes are always configurable, with the exception of `attr.output()`, `attr.output_list()`, and `attr.license()` rule attributes, which are always non-configurable. |
-| `default` | [dict](../core/dict); or [function](../core/function); default is `{}`  A default value to use if no value for this attribute is given when instantiating the rule.Use strings or the [`Label`](../builtins/Label#Label) function to specify default values, for example, `attr.string_keyed_label_dict(default = {"foo": "//a:b", "bar": "//a:c"})`. |
-| `doc` | [string](../core/string); or `None`; default is `None`  A description of the attribute that can be extracted by documentation generating tools. |
-| `allow_files` | [bool](../core/bool); or [sequence](../core/list) of [string](../core/string)s; or `None`; default is `None`  Whether `File` targets are allowed. Can be `True`, `False` (default), or a list of file extensions that are allowed (for example, `[".cc", ".cpp"]`). |
-| `allow_rules` | [sequence](../core/list) of [string](../core/string)s; or `None`; default is `None`  Which rule targets (name of the classes) are allowed. This is deprecated (kept only for compatibility), use providers instead. |
-| `providers` | [sequence](../core/list); default is `[]`  The providers that must be given by any dependency appearing in this attribute. The format of this argument is a list of lists of providers -- `*Info` objects returned by [`provider()`](../globals/bzl#provider) (or in the case of a legacy provider, its string name). The dependency must return ALL providers mentioned in at least ONE of the inner lists. As a convenience, this argument may also be a single-level list of providers, in which case it is wrapped in an outer list with one element. It is NOT required that the rule of the dependency advertises those providers in its `provides` parameter, however, it is considered best practice. |
+| `allow_empty` | [bool](/versions/8.0.1/rules/lib/core/bool); default is `True`  True if the attribute can be empty. |
+| `configurable` | [bool](/versions/8.0.1/rules/lib/core/bool); or unbound; default is `unbound`  This argument can only be specified for an attribute of a symbolic macro. If `configurable` is explicitly set to `False`, the symbolic macro attribute is non-configurable - in other words, it cannot take a `select()` value. If the `configurable` is either unbound or explicitly set to `True`, the attribute is configurable and can take a `select()` value. For an attribute of a rule or aspect, `configurable` must be left unbound. Most Starlark rule attributes are always configurable, with the exception of `attr.output()`, `attr.output_list()`, and `attr.license()` rule attributes, which are always non-configurable. |
+| `default` | [dict](/versions/8.0.1/rules/lib/core/dict); or [function](/versions/8.0.1/rules/lib/core/function); default is `{}`  A default value to use if no value for this attribute is given when instantiating the rule.Use strings or the [`Label`](/versions/8.0.1/rules/lib/builtins/Label#Label) function to specify default values, for example, `attr.string_keyed_label_dict(default = {"foo": "//a:b", "bar": "//a:c"})`. |
+| `doc` | [string](/versions/8.0.1/rules/lib/core/string); or `None`; default is `None`  A description of the attribute that can be extracted by documentation generating tools. |
+| `allow_files` | [bool](/versions/8.0.1/rules/lib/core/bool); or [sequence](/versions/8.0.1/rules/lib/core/list) of [string](/versions/8.0.1/rules/lib/core/string)s; or `None`; default is `None`  Whether `File` targets are allowed. Can be `True`, `False` (default), or a list of file extensions that are allowed (for example, `[".cc", ".cpp"]`). |
+| `allow_rules` | [sequence](/versions/8.0.1/rules/lib/core/list) of [string](/versions/8.0.1/rules/lib/core/string)s; or `None`; default is `None`  Which rule targets (name of the classes) are allowed. This is deprecated (kept only for compatibility), use providers instead. |
+| `providers` | [sequence](/versions/8.0.1/rules/lib/core/list); default is `[]`  The providers that must be given by any dependency appearing in this attribute. The format of this argument is a list of lists of providers -- `*Info` objects returned by [`provider()`](/versions/8.0.1/rules/lib/globals/bzl#provider) (or in the case of a legacy provider, its string name). The dependency must return ALL providers mentioned in at least ONE of the inner lists. As a convenience, this argument may also be a single-level list of providers, in which case it is wrapped in an outer list with one element. It is NOT required that the rule of the dependency advertises those providers in its `provides` parameter, however, it is considered best practice. |
 | `for_dependency_resolution` | default is `unbound`  If this is set, the attribute is available for materializers. Only rules marked with the flag of the same name are allowed to be referenced through such attributes. |
-| `flags` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  Deprecated, will be removed. |
-| `mandatory` | [bool](../core/bool); default is `False`  If true, the value must be specified explicitly (even if it has a `default`). |
+| `flags` | [sequence](/versions/8.0.1/rules/lib/core/list) of [string](/versions/8.0.1/rules/lib/core/string)s; default is `[]`  Deprecated, will be removed. |
+| `mandatory` | [bool](/versions/8.0.1/rules/lib/core/bool); default is `False`  If true, the value must be specified explicitly (even if it has a `default`). |
 | `cfg` | default is `None`  [Configuration](https://bazel.build/versions/8.0.1/extending/rules#configurations) of the attribute. It can be either `"exec"`, which indicates that the dependency is built for the `execution platform`, or `"target"`, which indicates that the dependency is build for the `target platform`. A typical example of the difference is when building mobile apps, where the `target platform` is `Android` or `iOS` while the `execution platform` is `Linux`, `macOS`, or `Windows`. |
-| `aspects` | [sequence](../core/list) of [Aspect](../builtins/Aspect)s; default is `[]`  Aspects that should be applied to the dependency or dependencies specified by this attribute. |
+| `aspects` | [sequence](/versions/8.0.1/rules/lib/core/list) of [Aspect](/versions/8.0.1/rules/lib/builtins/Aspect)s; default is `[]`  Aspects that should be applied to the dependency or dependencies specified by this attribute. |
 
 ## string\_list
 
@@ -286,11 +286,11 @@ Creates a schema for a list-of-strings attribute.
 
 | Parameter | Description |
 | --- | --- |
-| `mandatory` | [bool](../core/bool); default is `False`  If true, the value must be specified explicitly (even if it has a `default`). |
-| `allow_empty` | [bool](../core/bool); default is `True`  True if the attribute can be empty. |
-| `configurable` | [bool](../core/bool); or unbound; default is `unbound`  This argument can only be specified for an attribute of a symbolic macro. If `configurable` is explicitly set to `False`, the symbolic macro attribute is non-configurable - in other words, it cannot take a `select()` value. If the `configurable` is either unbound or explicitly set to `True`, the attribute is configurable and can take a `select()` value. For an attribute of a rule or aspect, `configurable` must be left unbound. Most Starlark rule attributes are always configurable, with the exception of `attr.output()`, `attr.output_list()`, and `attr.license()` rule attributes, which are always non-configurable. |
-| `default` | [sequence](../core/list) of [string](../core/string)s; or NativeComputedDefault; default is `[]`  A default value to use if no value for this attribute is given when instantiating the rule. |
-| `doc` | [string](../core/string); or `None`; default is `None`  A description of the attribute that can be extracted by documentation generating tools. |
+| `mandatory` | [bool](/versions/8.0.1/rules/lib/core/bool); default is `False`  If true, the value must be specified explicitly (even if it has a `default`). |
+| `allow_empty` | [bool](/versions/8.0.1/rules/lib/core/bool); default is `True`  True if the attribute can be empty. |
+| `configurable` | [bool](/versions/8.0.1/rules/lib/core/bool); or unbound; default is `unbound`  This argument can only be specified for an attribute of a symbolic macro. If `configurable` is explicitly set to `False`, the symbolic macro attribute is non-configurable - in other words, it cannot take a `select()` value. If the `configurable` is either unbound or explicitly set to `True`, the attribute is configurable and can take a `select()` value. For an attribute of a rule or aspect, `configurable` must be left unbound. Most Starlark rule attributes are always configurable, with the exception of `attr.output()`, `attr.output_list()`, and `attr.license()` rule attributes, which are always non-configurable. |
+| `default` | [sequence](/versions/8.0.1/rules/lib/core/list) of [string](/versions/8.0.1/rules/lib/core/string)s; or NativeComputedDefault; default is `[]`  A default value to use if no value for this attribute is given when instantiating the rule. |
+| `doc` | [string](/versions/8.0.1/rules/lib/core/string); or `None`; default is `None`  A description of the attribute that can be extracted by documentation generating tools. |
 
 ## string\_list\_dict
 
@@ -304,8 +304,8 @@ Creates a schema for an attribute holding a dictionary, where the keys are strin
 
 | Parameter | Description |
 | --- | --- |
-| `allow_empty` | [bool](../core/bool); default is `True`  True if the attribute can be empty. |
-| `configurable` | [bool](../core/bool); or unbound; default is `unbound`  This argument can only be specified for an attribute of a symbolic macro. If `configurable` is explicitly set to `False`, the symbolic macro attribute is non-configurable - in other words, it cannot take a `select()` value. If the `configurable` is either unbound or explicitly set to `True`, the attribute is configurable and can take a `select()` value. For an attribute of a rule or aspect, `configurable` must be left unbound. Most Starlark rule attributes are always configurable, with the exception of `attr.output()`, `attr.output_list()`, and `attr.license()` rule attributes, which are always non-configurable. |
-| `default` | [dict](../core/dict); default is `{}`  A default value to use if no value for this attribute is given when instantiating the rule. |
-| `doc` | [string](../core/string); or `None`; default is `None`  A description of the attribute that can be extracted by documentation generating tools. |
-| `mandatory` | [bool](../core/bool); default is `False`  If true, the value must be specified explicitly (even if it has a `default`). |
\ No newline at end of file
+| `allow_empty` | [bool](/versions/8.0.1/rules/lib/core/bool); default is `True`  True if the attribute can be empty. |
+| `configurable` | [bool](/versions/8.0.1/rules/lib/core/bool); or unbound; default is `unbound`  This argument can only be specified for an attribute of a symbolic macro. If `configurable` is explicitly set to `False`, the symbolic macro attribute is non-configurable - in other words, it cannot take a `select()` value. If the `configurable` is either unbound or explicitly set to `True`, the attribute is configurable and can take a `select()` value. For an attribute of a rule or aspect, `configurable` must be left unbound. Most Starlark rule attributes are always configurable, with the exception of `attr.output()`, `attr.output_list()`, and `attr.license()` rule attributes, which are always non-configurable. |
+| `default` | [dict](/versions/8.0.1/rules/lib/core/dict); default is `{}`  A default value to use if no value for this attribute is given when instantiating the rule. |
+| `doc` | [string](/versions/8.0.1/rules/lib/core/string); or `None`; default is `None`  A description of the attribute that can be extracted by documentation generating tools. |
+| `mandatory` | [bool](/versions/8.0.1/rules/lib/core/bool); default is `False`  If true, the value must be specified explicitly (even if it has a `default`). |
\ No newline at end of file
diff --git a/versions/8.0.1/rules/lib/toplevel/cc_common.mdx b/versions/8.0.1/rules/lib/toplevel/cc_common.mdx
index cb3f3d24..6c67a6d2 100644
--- a/versions/8.0.1/rules/lib/toplevel/cc_common.mdx
+++ b/versions/8.0.1/rules/lib/toplevel/cc_common.mdx
@@ -42,8 +42,8 @@ Returns True if given action\_config is enabled in the feature configuration.
 
 | Parameter | Description |
 | --- | --- |
-| `feature_configuration` | [FeatureConfiguration](../builtins/FeatureConfiguration); required  Feature configuration to be queried. |
-| `action_name` | [string](../core/string); required  Name of the action\_config. |
+| `feature_configuration` | [FeatureConfiguration](/versions/8.0.1/rules/lib/builtins/FeatureConfiguration); required  Feature configuration to be queried. |
+| `action_name` | [string](/versions/8.0.1/rules/lib/core/string); required  Name of the action\_config. |
 
 ## CcToolchainInfo
 
@@ -65,29 +65,29 @@ Should be used for C++ compilation. Returns tuple of (`CompilationContext`, `CcC
 
 | Parameter | Description |
 | --- | --- |
-| `actions` | [actions](../builtins/actions); required  `actions` object. |
-| `feature_configuration` | [FeatureConfiguration](../builtins/FeatureConfiguration); required  `feature_configuration` to be queried. |
+| `actions` | [actions](/versions/8.0.1/rules/lib/builtins/actions); required  `actions` object. |
+| `feature_configuration` | [FeatureConfiguration](/versions/8.0.1/rules/lib/builtins/FeatureConfiguration); required  `feature_configuration` to be queried. |
 | `cc_toolchain` | Info; required  `CcToolchainInfo` provider to be used. |
-| `srcs` | [sequence](../core/list); default is `[]`  The list of source files to be compiled. |
-| `public_hdrs` | [sequence](../core/list); default is `[]`  List of headers needed for compilation of srcs and may be included by dependent rules transitively. |
-| `private_hdrs` | [sequence](../core/list); default is `[]`  List of headers needed for compilation of srcs and NOT to be included by dependent rules. |
-| `includes` | [sequence](../core/list); or [depset](../builtins/depset); default is `[]`  Search paths for header files referenced both by angle bracket and quotes. Usually passed with -I. Propagated to dependents transitively. |
-| `quote_includes` | [sequence](../core/list); default is `[]`  Search paths for header files referenced by quotes, e.g. #include "foo/bar/header.h". They can be either relative to the exec root or absolute. Usually passed with -iquote. Propagated to dependents transitively. |
-| `system_includes` | [sequence](../core/list); default is `[]`  Search paths for header files referenced by angle brackets, e.g. #include <foo/bar/header.h>. They can be either relative to the exec root or absolute. Usually passed with -isystem. Propagated to dependents transitively. |
-| `framework_includes` | [sequence](../core/list); default is `[]`  Search paths for header files from Apple frameworks. They can be either relative to the exec root or absolute. Usually passed with -F. Propagated to dependents transitively. |
-| `defines` | [sequence](../core/list); default is `[]`  Set of defines needed to compile this target. Each define is a string. Propagated to dependents transitively. |
-| `local_defines` | [sequence](../core/list); default is `[]`  Set of defines needed to compile this target. Each define is a string. Not propagated to dependents transitively. |
-| `include_prefix` | [string](../core/string); default is `''`  The prefix to add to the paths of the headers of this rule. When set, the headers in the hdrs attribute of this rule are accessible at is the value of this attribute prepended to their repository-relative path. The prefix in the strip\_include\_prefix attribute is removed before this prefix is added. |
-| `strip_include_prefix` | [string](../core/string); default is `''`  The prefix to strip from the paths of the headers of this rule. When set, the headers in the hdrs attribute of this rule are accessible at their path with this prefix cut off. If it's a relative path, it's taken as a package-relative one. If it's an absolute one, it's understood as a repository-relative path. The prefix in the include\_prefix attribute is added after this prefix is stripped. |
-| `user_compile_flags` | [sequence](../core/list); default is `[]`  Additional list of compilation options. |
-| `conly_flags` | [sequence](../core/list); default is `[]`  Additional list of compilation options for C compiles. |
-| `cxx_flags` | [sequence](../core/list); default is `[]`  Additional list of compilation options for C++ compiles. |
-| `compilation_contexts` | [sequence](../core/list); default is `[]`  Headers from dependencies used for compilation. |
-| `name` | [string](../core/string); required  This is used for naming the output artifacts of actions created by this method. See also the `main\_output` arg. |
-| `disallow_pic_outputs` | [bool](../core/bool); default is `False`  Whether PIC outputs should be created. |
-| `disallow_nopic_outputs` | [bool](../core/bool); default is `False`  Whether NOPIC outputs should be created. |
-| `additional_inputs` | [sequence](../core/list); default is `[]`  List of additional files needed for compilation of srcs |
-| `module_interfaces` | [sequence](../core/list); default is `unbound`  The list of module interfaces source files to be compiled. Note: this is an experimental feature, only enabled with --experimental\_cpp\_modules |
+| `srcs` | [sequence](/versions/8.0.1/rules/lib/core/list); default is `[]`  The list of source files to be compiled. |
+| `public_hdrs` | [sequence](/versions/8.0.1/rules/lib/core/list); default is `[]`  List of headers needed for compilation of srcs and may be included by dependent rules transitively. |
+| `private_hdrs` | [sequence](/versions/8.0.1/rules/lib/core/list); default is `[]`  List of headers needed for compilation of srcs and NOT to be included by dependent rules. |
+| `includes` | [sequence](/versions/8.0.1/rules/lib/core/list); or [depset](/versions/8.0.1/rules/lib/builtins/depset); default is `[]`  Search paths for header files referenced both by angle bracket and quotes. Usually passed with -I. Propagated to dependents transitively. |
+| `quote_includes` | [sequence](/versions/8.0.1/rules/lib/core/list); default is `[]`  Search paths for header files referenced by quotes, e.g. #include "foo/bar/header.h". They can be either relative to the exec root or absolute. Usually passed with -iquote. Propagated to dependents transitively. |
+| `system_includes` | [sequence](/versions/8.0.1/rules/lib/core/list); default is `[]`  Search paths for header files referenced by angle brackets, e.g. #include <foo/bar/header.h>. They can be either relative to the exec root or absolute. Usually passed with -isystem. Propagated to dependents transitively. |
+| `framework_includes` | [sequence](/versions/8.0.1/rules/lib/core/list); default is `[]`  Search paths for header files from Apple frameworks. They can be either relative to the exec root or absolute. Usually passed with -F. Propagated to dependents transitively. |
+| `defines` | [sequence](/versions/8.0.1/rules/lib/core/list); default is `[]`  Set of defines needed to compile this target. Each define is a string. Propagated to dependents transitively. |
+| `local_defines` | [sequence](/versions/8.0.1/rules/lib/core/list); default is `[]`  Set of defines needed to compile this target. Each define is a string. Not propagated to dependents transitively. |
+| `include_prefix` | [string](/versions/8.0.1/rules/lib/core/string); default is `''`  The prefix to add to the paths of the headers of this rule. When set, the headers in the hdrs attribute of this rule are accessible at is the value of this attribute prepended to their repository-relative path. The prefix in the strip\_include\_prefix attribute is removed before this prefix is added. |
+| `strip_include_prefix` | [string](/versions/8.0.1/rules/lib/core/string); default is `''`  The prefix to strip from the paths of the headers of this rule. When set, the headers in the hdrs attribute of this rule are accessible at their path with this prefix cut off. If it's a relative path, it's taken as a package-relative one. If it's an absolute one, it's understood as a repository-relative path. The prefix in the include\_prefix attribute is added after this prefix is stripped. |
+| `user_compile_flags` | [sequence](/versions/8.0.1/rules/lib/core/list); default is `[]`  Additional list of compilation options. |
+| `conly_flags` | [sequence](/versions/8.0.1/rules/lib/core/list); default is `[]`  Additional list of compilation options for C compiles. |
+| `cxx_flags` | [sequence](/versions/8.0.1/rules/lib/core/list); default is `[]`  Additional list of compilation options for C++ compiles. |
+| `compilation_contexts` | [sequence](/versions/8.0.1/rules/lib/core/list); default is `[]`  Headers from dependencies used for compilation. |
+| `name` | [string](/versions/8.0.1/rules/lib/core/string); required  This is used for naming the output artifacts of actions created by this method. See also the `main\_output` arg. |
+| `disallow_pic_outputs` | [bool](/versions/8.0.1/rules/lib/core/bool); default is `False`  Whether PIC outputs should be created. |
+| `disallow_nopic_outputs` | [bool](/versions/8.0.1/rules/lib/core/bool); default is `False`  Whether NOPIC outputs should be created. |
+| `additional_inputs` | [sequence](/versions/8.0.1/rules/lib/core/list); default is `[]`  List of additional files needed for compilation of srcs |
+| `module_interfaces` | [sequence](/versions/8.0.1/rules/lib/core/list); default is `unbound`  The list of module interfaces source files to be compiled. Note: this is an experimental feature, only enabled with --experimental\_cpp\_modules |
 
 ## configure\_features
 
@@ -101,11 +101,11 @@ Creates a feature\_configuration instance. Requires the cpp configuration fragme
 
 | Parameter | Description |
 | --- | --- |
-| `ctx` | [ctx](../builtins/ctx); or `None`; default is `None`  The rule context. |
+| `ctx` | [ctx](/versions/8.0.1/rules/lib/builtins/ctx); or `None`; default is `None`  The rule context. |
 | `cc_toolchain` | Info; required  cc\_toolchain for which we configure features. |
-| `language` | [string](../core/string); or `None`; default is `None`  The language to configure for: either c++ or objc (default c++) |
-| `requested_features` | [sequence](../core/list); default is `[]`  List of features to be enabled. |
-| `unsupported_features` | [sequence](../core/list); default is `[]`  List of features that are unsupported by the current rule. |
+| `language` | [string](/versions/8.0.1/rules/lib/core/string); or `None`; default is `None`  The language to configure for: either c++ or objc (default c++) |
+| `requested_features` | [sequence](/versions/8.0.1/rules/lib/core/list); default is `[]`  List of features to be enabled. |
+| `unsupported_features` | [sequence](/versions/8.0.1/rules/lib/core/list); default is `[]`  List of features that are unsupported by the current rule. |
 
 ## create\_cc\_toolchain\_config\_info
 
@@ -119,22 +119,22 @@ Creates a `CcToolchainConfigInfo` provider
 
 | Parameter | Description |
 | --- | --- |
-| `ctx` | [ctx](../builtins/ctx); required  The rule context. |
-| `features` | [sequence](../core/list); default is `[]`  Contains all flag specifications for one feature. Arguments:  `name`: The feature's name. It is possible to introduce a feature without a change to Bazel by adding a 'feature' section to the toolchain and adding the corresponding string as feature in the `BUILD` file.  `enabled`: If 'True', this feature is enabled unless a rule type explicitly marks it as unsupported.  `flag_sets`: A FlagSet list. If the given feature is enabled, the flag sets will be applied for the actions are specified for.  `env_sets`: an EnvSet list. If the given feature is enabled, the env sets will be applied for the actions they are specified for.  `requires`: A list of feature sets defining when this feature is supported by the toolchain. The feature is supported if any of the feature sets fully apply, that is, when all features of a feature set are enabled. If `requires` is omitted, the feature is supported independently of which other features are enabled. Use this for example to filter flags depending on the build mode enabled (opt / fastbuild / dbg).  `implies`: A string list of features or action configs that are automatically enabled when this feature is enabled. If any of the implied features or action configs cannot be enabled, this feature will (silently) not be enabled either.  `provides`: A list of names this feature conflicts with. A feature cannot be enabled if:- `provides` contains the name of a different feature or action config that we want to enable.- `provides` contains the same value as a 'provides' in a different feature or action config that we want to enable. Use this in order to ensure that incompatible features cannot be accidentally activated at the same time, leading to hard to diagnose compiler errors. |
-| `action_configs` | [sequence](../core/list); default is `[]`  An action config corresponds to a Bazel action, and allows selection of a tool based on activated features. Action config activation occurs by the same semantics as features: a feature can 'require' or 'imply' an action config in the same way that it would another feature. Arguments:  `action_name`: The name of the Bazel action that this config applies to, e.g. 'c-compile' or 'c-module-compile'.  `enabled`: If 'True', this action is enabled unless a rule type explicitly marks it as unsupported.  `tools`: The tool applied to the action will be the first tool with a feature set that matches the feature configuration. An error will be thrown if no tool matches a provided feature configuration - for that reason, it's a good idea to provide a default tool with an empty feature set.  `flag_sets`: If the given action config is enabled, the flag sets will be applied to the corresponding action.  `implies`: A list of features or action configs that are automatically enabled when this action config is enabled. If any of the implied features or action configs cannot be enabled, this action config will (silently) not be enabled either. |
-| `artifact_name_patterns` | [sequence](../core/list); default is `[]`  The name for an artifact of a given category of input or output artifacts to an action. Arguments:  `category_name`: The category of artifacts that this selection applies to. This field is compared against a list of categories defined in Bazel. Example categories include "linked\_output" or the artifact for this selection. Together with the extension it is used to create an artifact name based on the target name.  `extension`: The extension for creating the artifact for this selection. Together with the prefix it is used to create an artifact name based on the target name. |
-| `cxx_builtin_include_directories` | [sequence](../core/list); default is `[]`  Built-in include directories for C++ compilation. These should be the exact paths used by the compiler, and are generally relative to the exec root.  The paths used by the compiler can be determined by 'gcc -E -xc++ - -v'.  We currently use the C++ paths also for C compilation, which is safe as long as there are no name clashes between C++ and C header files.  Relative paths are resolved relative to the configuration file directory.  If the compiler has --sysroot support, then these paths should use %sysroot% rather than the include path, and specify the sysroot attribute in order to give blaze the information necessary to make the correct replacements. |
-| `toolchain_identifier` | [string](../core/string); required  The unique identifier of the toolchain within the crosstool release. It must be possible to use this as a directory name in a path.  It has to match the following regex: [a-zA-Z\_][\.\- \w]\* |
-| `host_system_name` | [string](../core/string); or `None`; default is `None`  Ignored. |
-| `target_system_name` | [string](../core/string); or `None`; default is `None`  Deprecated. The GNU System Name. The string is exposed to CcToolchainInfo.target\_gnu\_system\_name. |
-| `target_cpu` | [string](../core/string); or `None`; default is `None`  Deprecated: Use cpu based constraints instead. If the string is "k8", `target\_cpu` will be omitted from the filename of raw FDO profile data. |
-| `target_libc` | [string](../core/string); or `None`; default is `None`  Deprecated: Use OS based constraints instead. The libc version string (e.g. "glibc-2.2.2"). If the string is "macosx", platform is assumed to be MacOS. Otherwise, Linux. The string is exposed to CcToolchainInfo.libc. |
-| `compiler` | [string](../core/string); required  The compiler string (e.g. "gcc"). The current toolchain's compiler is exposed to `@bazel\_tools//tools/cpp:compiler (compiler\_flag)` as a flag value. Targets that require compiler-specific flags can use the config\_settings in https://github.com/bazelbuild/rules\_cc/blob/main/cc/compiler/BUILD in select() statements or create custom config\_setting if the existing settings don't suffice. |
-| `abi_version` | [string](../core/string); or `None`; default is `None`  The abi in use, which is a gcc version. E.g.: "gcc-3.4". The string is set to C++ toolchain variable ABI. |
-| `abi_libc_version` | [string](../core/string); or `None`; default is `None`  The glibc version used by the abi we're using. The string is set to C++ toolchain variable ABI\_LIBC\_VERSION. |
-| `tool_paths` | [sequence](../core/list); default is `[]`  Tool locations. Arguments:  `name`: Name of the tool.  `path`: Location of the tool; Can be absolute path (in case of non hermetic toolchain), or path relative to the cc\_toolchain's package. |
-| `make_variables` | [sequence](../core/list); default is `[]`  A make variable that is made accessible to rules. |
-| `builtin_sysroot` | [string](../core/string); or `None`; default is `None`  The built-in sysroot. If this attribute is not present, Bazel does not allow using a different sysroot, i.e. through the --grte\_top option. |
+| `ctx` | [ctx](/versions/8.0.1/rules/lib/builtins/ctx); required  The rule context. |
+| `features` | [sequence](/versions/8.0.1/rules/lib/core/list); default is `[]`  Contains all flag specifications for one feature. Arguments:  `name`: The feature's name. It is possible to introduce a feature without a change to Bazel by adding a 'feature' section to the toolchain and adding the corresponding string as feature in the `BUILD` file.  `enabled`: If 'True', this feature is enabled unless a rule type explicitly marks it as unsupported.  `flag_sets`: A FlagSet list. If the given feature is enabled, the flag sets will be applied for the actions are specified for.  `env_sets`: an EnvSet list. If the given feature is enabled, the env sets will be applied for the actions they are specified for.  `requires`: A list of feature sets defining when this feature is supported by the toolchain. The feature is supported if any of the feature sets fully apply, that is, when all features of a feature set are enabled. If `requires` is omitted, the feature is supported independently of which other features are enabled. Use this for example to filter flags depending on the build mode enabled (opt / fastbuild / dbg).  `implies`: A string list of features or action configs that are automatically enabled when this feature is enabled. If any of the implied features or action configs cannot be enabled, this feature will (silently) not be enabled either.  `provides`: A list of names this feature conflicts with. A feature cannot be enabled if:- `provides` contains the name of a different feature or action config that we want to enable.- `provides` contains the same value as a 'provides' in a different feature or action config that we want to enable. Use this in order to ensure that incompatible features cannot be accidentally activated at the same time, leading to hard to diagnose compiler errors. |
+| `action_configs` | [sequence](/versions/8.0.1/rules/lib/core/list); default is `[]`  An action config corresponds to a Bazel action, and allows selection of a tool based on activated features. Action config activation occurs by the same semantics as features: a feature can 'require' or 'imply' an action config in the same way that it would another feature. Arguments:  `action_name`: The name of the Bazel action that this config applies to, e.g. 'c-compile' or 'c-module-compile'.  `enabled`: If 'True', this action is enabled unless a rule type explicitly marks it as unsupported.  `tools`: The tool applied to the action will be the first tool with a feature set that matches the feature configuration. An error will be thrown if no tool matches a provided feature configuration - for that reason, it's a good idea to provide a default tool with an empty feature set.  `flag_sets`: If the given action config is enabled, the flag sets will be applied to the corresponding action.  `implies`: A list of features or action configs that are automatically enabled when this action config is enabled. If any of the implied features or action configs cannot be enabled, this action config will (silently) not be enabled either. |
+| `artifact_name_patterns` | [sequence](/versions/8.0.1/rules/lib/core/list); default is `[]`  The name for an artifact of a given category of input or output artifacts to an action. Arguments:  `category_name`: The category of artifacts that this selection applies to. This field is compared against a list of categories defined in Bazel. Example categories include "linked\_output" or the artifact for this selection. Together with the extension it is used to create an artifact name based on the target name.  `extension`: The extension for creating the artifact for this selection. Together with the prefix it is used to create an artifact name based on the target name. |
+| `cxx_builtin_include_directories` | [sequence](/versions/8.0.1/rules/lib/core/list); default is `[]`  Built-in include directories for C++ compilation. These should be the exact paths used by the compiler, and are generally relative to the exec root.  The paths used by the compiler can be determined by 'gcc -E -xc++ - -v'.  We currently use the C++ paths also for C compilation, which is safe as long as there are no name clashes between C++ and C header files.  Relative paths are resolved relative to the configuration file directory.  If the compiler has --sysroot support, then these paths should use %sysroot% rather than the include path, and specify the sysroot attribute in order to give blaze the information necessary to make the correct replacements. |
+| `toolchain_identifier` | [string](/versions/8.0.1/rules/lib/core/string); required  The unique identifier of the toolchain within the crosstool release. It must be possible to use this as a directory name in a path.  It has to match the following regex: [a-zA-Z\_][\.\- \w]\* |
+| `host_system_name` | [string](/versions/8.0.1/rules/lib/core/string); or `None`; default is `None`  Ignored. |
+| `target_system_name` | [string](/versions/8.0.1/rules/lib/core/string); or `None`; default is `None`  Deprecated. The GNU System Name. The string is exposed to CcToolchainInfo.target\_gnu\_system\_name. |
+| `target_cpu` | [string](/versions/8.0.1/rules/lib/core/string); or `None`; default is `None`  Deprecated: Use cpu based constraints instead. If the string is "k8", `target\_cpu` will be omitted from the filename of raw FDO profile data. |
+| `target_libc` | [string](/versions/8.0.1/rules/lib/core/string); or `None`; default is `None`  Deprecated: Use OS based constraints instead. The libc version string (e.g. "glibc-2.2.2"). If the string is "macosx", platform is assumed to be MacOS. Otherwise, Linux. The string is exposed to CcToolchainInfo.libc. |
+| `compiler` | [string](/versions/8.0.1/rules/lib/core/string); required  The compiler string (e.g. "gcc"). The current toolchain's compiler is exposed to `@bazel\_tools//tools/cpp:compiler (compiler\_flag)` as a flag value. Targets that require compiler-specific flags can use the config\_settings in https://github.com/bazelbuild/rules\_cc/blob/main/cc/compiler/BUILD in select() statements or create custom config\_setting if the existing settings don't suffice. |
+| `abi_version` | [string](/versions/8.0.1/rules/lib/core/string); or `None`; default is `None`  The abi in use, which is a gcc version. E.g.: "gcc-3.4". The string is set to C++ toolchain variable ABI. |
+| `abi_libc_version` | [string](/versions/8.0.1/rules/lib/core/string); or `None`; default is `None`  The glibc version used by the abi we're using. The string is set to C++ toolchain variable ABI\_LIBC\_VERSION. |
+| `tool_paths` | [sequence](/versions/8.0.1/rules/lib/core/list); default is `[]`  Tool locations. Arguments:  `name`: Name of the tool.  `path`: Location of the tool; Can be absolute path (in case of non hermetic toolchain), or path relative to the cc\_toolchain's package. |
+| `make_variables` | [sequence](/versions/8.0.1/rules/lib/core/list); default is `[]`  A make variable that is made accessible to rules. |
+| `builtin_sysroot` | [string](/versions/8.0.1/rules/lib/core/string); or `None`; default is `None`  The built-in sysroot. If this attribute is not present, Bazel does not allow using a different sysroot, i.e. through the --grte\_top option. |
 
 ## create\_compilation\_context
 
@@ -168,8 +168,8 @@ Create compilation outputs object.
 
 | Parameter | Description |
 | --- | --- |
-| `objects` | [depset](../builtins/depset); or `None`; default is `None`  List of object files. |
-| `pic_objects` | [depset](../builtins/depset); or `None`; default is `None`  List of pic object files. |
+| `objects` | [depset](/versions/8.0.1/rules/lib/builtins/depset); or `None`; default is `None`  List of object files. |
+| `pic_objects` | [depset](/versions/8.0.1/rules/lib/builtins/depset); or `None`; default is `None`  List of pic object files. |
 
 ## create\_compile\_variables
 
@@ -184,21 +184,21 @@ Returns variables used for compilation actions.
 | Parameter | Description |
 | --- | --- |
 | `cc_toolchain` | Info; required  cc\_toolchain for which we are creating build variables. |
-| `feature_configuration` | [FeatureConfiguration](../builtins/FeatureConfiguration); required  Feature configuration to be queried. |
+| `feature_configuration` | [FeatureConfiguration](/versions/8.0.1/rules/lib/builtins/FeatureConfiguration); required  Feature configuration to be queried. |
 | `source_file` | default is `None`  Optional source file for the compilation. Please prefer passing source\_file here over appending it to the end of the command line generated from cc\_common.get\_memory\_inefficient\_command\_line, as then it's in the power of the toolchain author to properly specify and position compiler flags. |
 | `output_file` | default is `None`  Optional output file of the compilation. Please prefer passing output\_file here over appending it to the end of the command line generated from cc\_common.get\_memory\_inefficient\_command\_line, as then it's in the power of the toolchain author to properly specify and position compiler flags. |
-| `user_compile_flags` | [sequence](../core/list) of [string](../core/string)s; or `None`; default is `None`  List of additional compilation flags (copts). |
-| `include_directories` | [depset](../builtins/depset); or `None`; default is `None`  Depset of include directories. |
-| `quote_include_directories` | [depset](../builtins/depset); or `None`; default is `None`  Depset of quote include directories. |
-| `system_include_directories` | [depset](../builtins/depset); or `None`; default is `None`  Depset of system include directories. |
-| `framework_include_directories` | [depset](../builtins/depset); or `None`; default is `None`  Depset of framework include directories. |
-| `preprocessor_defines` | [depset](../builtins/depset); or `None`; default is `None`  Depset of preprocessor defines. |
-| `thinlto_index` | [string](../core/string); or `None`; default is `None`  LTO index file path. |
-| `thinlto_input_bitcode_file` | [string](../core/string); or `None`; default is `None`  Bitcode file that is input to LTO backend. |
-| `thinlto_output_object_file` | [string](../core/string); or `None`; default is `None`  Object file that is output by LTO backend. |
-| `use_pic` | [bool](../core/bool); default is `False`  When true the compilation will generate position independent code. |
-| `add_legacy_cxx_options` | [bool](../core/bool); default is `False`  Unused. |
-| `variables_extension` | [dict](../core/dict); default is `unbound`  A dictionary of additional variables used by compile actions. |
+| `user_compile_flags` | [sequence](/versions/8.0.1/rules/lib/core/list) of [string](/versions/8.0.1/rules/lib/core/string)s; or `None`; default is `None`  List of additional compilation flags (copts). |
+| `include_directories` | [depset](/versions/8.0.1/rules/lib/builtins/depset); or `None`; default is `None`  Depset of include directories. |
+| `quote_include_directories` | [depset](/versions/8.0.1/rules/lib/builtins/depset); or `None`; default is `None`  Depset of quote include directories. |
+| `system_include_directories` | [depset](/versions/8.0.1/rules/lib/builtins/depset); or `None`; default is `None`  Depset of system include directories. |
+| `framework_include_directories` | [depset](/versions/8.0.1/rules/lib/builtins/depset); or `None`; default is `None`  Depset of framework include directories. |
+| `preprocessor_defines` | [depset](/versions/8.0.1/rules/lib/builtins/depset); or `None`; default is `None`  Depset of preprocessor defines. |
+| `thinlto_index` | [string](/versions/8.0.1/rules/lib/core/string); or `None`; default is `None`  LTO index file path. |
+| `thinlto_input_bitcode_file` | [string](/versions/8.0.1/rules/lib/core/string); or `None`; default is `None`  Bitcode file that is input to LTO backend. |
+| `thinlto_output_object_file` | [string](/versions/8.0.1/rules/lib/core/string); or `None`; default is `None`  Object file that is output by LTO backend. |
+| `use_pic` | [bool](/versions/8.0.1/rules/lib/core/bool); default is `False`  When true the compilation will generate position independent code. |
+| `add_legacy_cxx_options` | [bool](/versions/8.0.1/rules/lib/core/bool); default is `False`  Unused. |
+| `variables_extension` | [dict](/versions/8.0.1/rules/lib/core/dict); default is `unbound`  A dictionary of additional variables used by compile actions. |
 
 ## create\_library\_to\_link
 
@@ -215,15 +215,15 @@ Creates `LibraryToLink`
 | `actions` | required  `actions` object. |
 | `feature_configuration` | default is `None`  `feature_configuration` to be queried. |
 | `cc_toolchain` | default is `None`  `CcToolchainInfo` provider to be used. |
-| `static_library` | [File](../builtins/File); or `None`; default is `None`  `File` of static library to be linked. |
-| `pic_static_library` | [File](../builtins/File); or `None`; default is `None`  `File` of pic static library to be linked. |
-| `dynamic_library` | [File](../builtins/File); or `None`; default is `None`  `File` of dynamic library to be linked. Always used for runtime and used for linking if `interface_library` is not passed. |
-| `interface_library` | [File](../builtins/File); or `None`; default is `None`  `File` of interface library to be linked. |
-| `pic_objects` | [sequence](../core/list) of [File](../builtins/File)s; default is `unbound`  Experimental, do not use |
-| `objects` | [sequence](../core/list) of [File](../builtins/File)s; default is `unbound`  Experimental, do not use |
-| `alwayslink` | [bool](../core/bool); default is `False`  Whether to link the static library/objects in the --whole\_archive block. |
-| `dynamic_library_symlink_path` | [string](../core/string); default is `''`  Override the default path of the dynamic library link in the solib directory. Empty string to use the default. |
-| `interface_library_symlink_path` | [string](../core/string); default is `''`  Override the default path of the interface library link in the solib directory. Empty string to use the default. |
+| `static_library` | [File](/versions/8.0.1/rules/lib/builtins/File); or `None`; default is `None`  `File` of static library to be linked. |
+| `pic_static_library` | [File](/versions/8.0.1/rules/lib/builtins/File); or `None`; default is `None`  `File` of pic static library to be linked. |
+| `dynamic_library` | [File](/versions/8.0.1/rules/lib/builtins/File); or `None`; default is `None`  `File` of dynamic library to be linked. Always used for runtime and used for linking if `interface_library` is not passed. |
+| `interface_library` | [File](/versions/8.0.1/rules/lib/builtins/File); or `None`; default is `None`  `File` of interface library to be linked. |
+| `pic_objects` | [sequence](/versions/8.0.1/rules/lib/core/list) of [File](/versions/8.0.1/rules/lib/builtins/File)s; default is `unbound`  Experimental, do not use |
+| `objects` | [sequence](/versions/8.0.1/rules/lib/core/list) of [File](/versions/8.0.1/rules/lib/builtins/File)s; default is `unbound`  Experimental, do not use |
+| `alwayslink` | [bool](/versions/8.0.1/rules/lib/core/bool); default is `False`  Whether to link the static library/objects in the --whole\_archive block. |
+| `dynamic_library_symlink_path` | [string](/versions/8.0.1/rules/lib/core/string); default is `''`  Override the default path of the dynamic library link in the solib directory. Empty string to use the default. |
+| `interface_library_symlink_path` | [string](/versions/8.0.1/rules/lib/core/string); default is `''`  Override the default path of the interface library link in the solib directory. Empty string to use the default. |
 
 ## create\_link\_variables
 
@@ -238,17 +238,17 @@ Returns link variables used for linking actions.
 | Parameter | Description |
 | --- | --- |
 | `cc_toolchain` | Info; required  cc\_toolchain for which we are creating build variables. |
-| `feature_configuration` | [FeatureConfiguration](../builtins/FeatureConfiguration); required  Feature configuration to be queried. |
-| `library_search_directories` | [depset](../builtins/depset); default is `[]`  Depset of directories where linker will look for libraries at link time. |
-| `runtime_library_search_directories` | [depset](../builtins/depset); default is `[]`  Depset of directories where loader will look for libraries at runtime. |
-| `user_link_flags` | [sequence](../core/list); default is `[]`  List of additional link flags (linkopts). |
+| `feature_configuration` | [FeatureConfiguration](/versions/8.0.1/rules/lib/builtins/FeatureConfiguration); required  Feature configuration to be queried. |
+| `library_search_directories` | [depset](/versions/8.0.1/rules/lib/builtins/depset); default is `[]`  Depset of directories where linker will look for libraries at link time. |
+| `runtime_library_search_directories` | [depset](/versions/8.0.1/rules/lib/builtins/depset); default is `[]`  Depset of directories where loader will look for libraries at runtime. |
+| `user_link_flags` | [sequence](/versions/8.0.1/rules/lib/core/list); default is `[]`  List of additional link flags (linkopts). |
 | `output_file` | default is `None`  Optional output file path. |
 | `param_file` | default is `None`  Optional param file path. |
-| `is_using_linker` | [bool](../core/bool); default is `True`  True when using linker, False when archiver. Caller is responsible for keeping this in sync with action name used (is\_using\_linker = True for linking executable or dynamic library, is\_using\_linker = False for archiving static library). |
-| `is_linking_dynamic_library` | [bool](../core/bool); default is `False`  True when creating dynamic library, False when executable or static library. Caller is responsible for keeping this in sync with action name used. This field will be removed once b/65151735 is fixed. |
-| `must_keep_debug` | [bool](../core/bool); default is `True`  When set to False, bazel will expose 'strip\_debug\_symbols' variable, which is usually used to use the linker to strip debug symbols from the output file. |
-| `use_test_only_flags` | [bool](../core/bool); default is `False`  When set to true, 'is\_cc\_test' variable will be set. |
-| `is_static_linking_mode` | [bool](../core/bool); default is `True`  Unused. |
+| `is_using_linker` | [bool](/versions/8.0.1/rules/lib/core/bool); default is `True`  True when using linker, False when archiver. Caller is responsible for keeping this in sync with action name used (is\_using\_linker = True for linking executable or dynamic library, is\_using\_linker = False for archiving static library). |
+| `is_linking_dynamic_library` | [bool](/versions/8.0.1/rules/lib/core/bool); default is `False`  True when creating dynamic library, False when executable or static library. Caller is responsible for keeping this in sync with action name used. This field will be removed once b/65151735 is fixed. |
+| `must_keep_debug` | [bool](/versions/8.0.1/rules/lib/core/bool); default is `True`  When set to False, bazel will expose 'strip\_debug\_symbols' variable, which is usually used to use the linker to strip debug symbols from the output file. |
+| `use_test_only_flags` | [bool](/versions/8.0.1/rules/lib/core/bool); default is `False`  When set to true, 'is\_cc\_test' variable will be set. |
+| `is_static_linking_mode` | [bool](/versions/8.0.1/rules/lib/core/bool); default is `True`  Unused. |
 
 ## create\_linker\_input
 
@@ -262,10 +262,10 @@ Creates a `LinkerInput`.
 
 | Parameter | Description |
 | --- | --- |
-| `owner` | [Label](../builtins/Label); required  The label of the target that produced all files used in this input. |
-| `libraries` | `None`; or [depset](../builtins/depset); default is `None`  List of `LibraryToLink`. |
-| `user_link_flags` | `None`; or [depset](../builtins/depset) of [string](../core/string)s; or [sequence](../core/list) of [string](../core/string)s; default is `None`  User link flags passed as strings. Accepts either [String], [[String]] or depset(String). The latter is discouraged as it's only kept for compatibility purposes, the depset is flattened. If you want to propagate user\_link\_flags via unflattened depsets() wrap them in a LinkerInput so that they are not flattened till the end. |
-| `additional_inputs` | `None`; or [depset](../builtins/depset); default is `None`  For additional inputs to the linking action, e.g.: linking scripts. |
+| `owner` | [Label](/versions/8.0.1/rules/lib/builtins/Label); required  The label of the target that produced all files used in this input. |
+| `libraries` | `None`; or [depset](/versions/8.0.1/rules/lib/builtins/depset); default is `None`  List of `LibraryToLink`. |
+| `user_link_flags` | `None`; or [depset](/versions/8.0.1/rules/lib/builtins/depset) of [string](/versions/8.0.1/rules/lib/core/string)s; or [sequence](/versions/8.0.1/rules/lib/core/list) of [string](/versions/8.0.1/rules/lib/core/string)s; default is `None`  User link flags passed as strings. Accepts either [String], [[String]] or depset(String). The latter is discouraged as it's only kept for compatibility purposes, the depset is flattened. If you want to propagate user\_link\_flags via unflattened depsets() wrap them in a LinkerInput so that they are not flattened till the end. |
+| `additional_inputs` | `None`; or [depset](/versions/8.0.1/rules/lib/builtins/depset); default is `None`  For additional inputs to the linking action, e.g.: linking scripts. |
 
 ## create\_linking\_context
 
@@ -279,10 +279,10 @@ Creates a `LinkingContext`.
 
 | Parameter | Description |
 | --- | --- |
-| `linker_inputs` | `None`; or [depset](../builtins/depset); default is `None`  Depset of `LinkerInput`. |
-| `libraries_to_link` | `None`; or [sequence](../core/list); default is `None`  **Deprecated**. This parameter is deprecated and will be removed soon. Please do not depend on it. It is *disabled* with `--incompatible_require_linker_input_cc_api`. Use this flag to verify your code is compatible with its imminent removal.  List of `LibraryToLink`. |
-| `user_link_flags` | `None`; or [sequence](../core/list); default is `None` |
-| `additional_inputs` | `None`; or [sequence](../core/list); default is `None` |
+| `linker_inputs` | `None`; or [depset](/versions/8.0.1/rules/lib/builtins/depset); default is `None`  Depset of `LinkerInput`. |
+| `libraries_to_link` | `None`; or [sequence](/versions/8.0.1/rules/lib/core/list); default is `None`  **Deprecated**. This parameter is deprecated and will be removed soon. Please do not depend on it. It is *disabled* with `--incompatible_require_linker_input_cc_api`. Use this flag to verify your code is compatible with its imminent removal.  List of `LibraryToLink`. |
+| `user_link_flags` | `None`; or [sequence](/versions/8.0.1/rules/lib/core/list); default is `None` |
+| `additional_inputs` | `None`; or [sequence](/versions/8.0.1/rules/lib/core/list); default is `None` |
 
 ## create\_linking\_context\_from\_compilation\_outputs
 
@@ -296,19 +296,19 @@ Should be used for creating library rules that can propagate information downstr
 
 | Parameter | Description |
 | --- | --- |
-| `actions` | [actions](../builtins/actions); required |
-| `name` | [string](../core/string); required  This is used for naming the output artifacts of actions created by this method. |
-| `feature_configuration` | [FeatureConfiguration](../builtins/FeatureConfiguration); required  `feature_configuration` to be queried. |
+| `actions` | [actions](/versions/8.0.1/rules/lib/builtins/actions); required |
+| `name` | [string](/versions/8.0.1/rules/lib/core/string); required  This is used for naming the output artifacts of actions created by this method. |
+| `feature_configuration` | [FeatureConfiguration](/versions/8.0.1/rules/lib/builtins/FeatureConfiguration); required  `feature_configuration` to be queried. |
 | `cc_toolchain` | Info; required  `CcToolchainInfo` provider to be used. |
-| `language` | [string](../core/string); default is `'c++'`  Only C++ supported for now. Do not use this parameter. |
-| `disallow_static_libraries` | [bool](../core/bool); default is `False`  Whether static libraries should be created. |
-| `disallow_dynamic_library` | [bool](../core/bool); default is `False`  Whether a dynamic library should be created. |
-| `compilation_outputs` | [CcCompilationOutputs](../builtins/CcCompilationOutputs); required  Compilation outputs containing object files to link. |
-| `linking_contexts` | [sequence](../core/list); default is `[]`  Libraries from dependencies. These libraries will be linked into the output artifact of the link() call, be it a binary or a library. |
-| `user_link_flags` | [sequence](../core/list); default is `[]`  Additional list of linking options. |
-| `alwayslink` | [bool](../core/bool); default is `False`  Whether this library should always be linked. |
-| `additional_inputs` | [sequence](../core/list); default is `[]`  For additional inputs to the linking action, e.g.: linking scripts. |
-| `variables_extension` | [dict](../core/dict); default is `unbound`  Additional variables to pass to the toolchain configuration when creating link command line. |
+| `language` | [string](/versions/8.0.1/rules/lib/core/string); default is `'c++'`  Only C++ supported for now. Do not use this parameter. |
+| `disallow_static_libraries` | [bool](/versions/8.0.1/rules/lib/core/bool); default is `False`  Whether static libraries should be created. |
+| `disallow_dynamic_library` | [bool](/versions/8.0.1/rules/lib/core/bool); default is `False`  Whether a dynamic library should be created. |
+| `compilation_outputs` | [CcCompilationOutputs](/versions/8.0.1/rules/lib/builtins/CcCompilationOutputs); required  Compilation outputs containing object files to link. |
+| `linking_contexts` | [sequence](/versions/8.0.1/rules/lib/core/list); default is `[]`  Libraries from dependencies. These libraries will be linked into the output artifact of the link() call, be it a binary or a library. |
+| `user_link_flags` | [sequence](/versions/8.0.1/rules/lib/core/list); default is `[]`  Additional list of linking options. |
+| `alwayslink` | [bool](/versions/8.0.1/rules/lib/core/bool); default is `False`  Whether this library should always be linked. |
+| `additional_inputs` | [sequence](/versions/8.0.1/rules/lib/core/list); default is `[]`  For additional inputs to the linking action, e.g.: linking scripts. |
+| `variables_extension` | [dict](/versions/8.0.1/rules/lib/core/dict); default is `unbound`  Additional variables to pass to the toolchain configuration when creating link command line. |
 
 ## create\_lto\_compilation\_context
 
@@ -322,7 +322,7 @@ Create LTO compilation context
 
 | Parameter | Description |
 | --- | --- |
-| `objects` | [dict](../core/dict); default is `{}`  map of full object to index object |
+| `objects` | [dict](/versions/8.0.1/rules/lib/core/dict); default is `{}`  map of full object to index object |
 
 ## do\_not\_use\_tools\_cpp\_compiler\_present
 
@@ -344,8 +344,8 @@ Returns environment variables to be set for given action.
 
 | Parameter | Description |
 | --- | --- |
-| `feature_configuration` | [FeatureConfiguration](../builtins/FeatureConfiguration); required  Feature configuration to be queried. |
-| `action_name` | [string](../core/string); required  Name of the action. Has to be one of the names in @bazel\_tools//tools/build\_defs/cc:action\_names.bzl (https://github.com/bazelbuild/bazel/blob/master/tools/build\_defs/cc/action\_names.bzl) |
+| `feature_configuration` | [FeatureConfiguration](/versions/8.0.1/rules/lib/builtins/FeatureConfiguration); required  Feature configuration to be queried. |
+| `action_name` | [string](/versions/8.0.1/rules/lib/core/string); required  Name of the action. Has to be one of the names in @bazel\_tools//tools/build\_defs/cc:action\_names.bzl (https://github.com/bazelbuild/bazel/blob/master/tools/build\_defs/cc/action\_names.bzl) |
 | `variables` | Variables; required  Build variables to be used for template expansion. |
 
 ## get\_execution\_requirements
@@ -360,8 +360,8 @@ Returns execution requirements for given action.
 
 | Parameter | Description |
 | --- | --- |
-| `feature_configuration` | [FeatureConfiguration](../builtins/FeatureConfiguration); required  Feature configuration to be queried. |
-| `action_name` | [string](../core/string); required  Name of the action. Has to be one of the names in @bazel\_tools//tools/build\_defs/cc:action\_names.bzl (https://github.com/bazelbuild/bazel/blob/master/tools/build\_defs/cc/action\_names.bzl) |
+| `feature_configuration` | [FeatureConfiguration](/versions/8.0.1/rules/lib/builtins/FeatureConfiguration); required  Feature configuration to be queried. |
+| `action_name` | [string](/versions/8.0.1/rules/lib/core/string); required  Name of the action. Has to be one of the names in @bazel\_tools//tools/build\_defs/cc:action\_names.bzl (https://github.com/bazelbuild/bazel/blob/master/tools/build\_defs/cc/action\_names.bzl) |
 
 ## get\_memory\_inefficient\_command\_line
 
@@ -375,8 +375,8 @@ Returns flattened command line flags for given action, using given variables for
 
 | Parameter | Description |
 | --- | --- |
-| `feature_configuration` | [FeatureConfiguration](../builtins/FeatureConfiguration); required  Feature configuration to be queried. |
-| `action_name` | [string](../core/string); required  Name of the action. Has to be one of the names in @bazel\_tools//tools/build\_defs/cc:action\_names.bzl (https://github.com/bazelbuild/bazel/blob/master/tools/build\_defs/cc/action\_names.bzl) |
+| `feature_configuration` | [FeatureConfiguration](/versions/8.0.1/rules/lib/builtins/FeatureConfiguration); required  Feature configuration to be queried. |
+| `action_name` | [string](/versions/8.0.1/rules/lib/core/string); required  Name of the action. Has to be one of the names in @bazel\_tools//tools/build\_defs/cc:action\_names.bzl (https://github.com/bazelbuild/bazel/blob/master/tools/build\_defs/cc/action\_names.bzl) |
 | `variables` | Variables; required  Build variables to be used for template expansions. |
 
 ## get\_tool\_for\_action
@@ -391,8 +391,8 @@ Returns tool path for given action.
 
 | Parameter | Description |
 | --- | --- |
-| `feature_configuration` | [FeatureConfiguration](../builtins/FeatureConfiguration); required  Feature configuration to be queried. |
-| `action_name` | [string](../core/string); required  Name of the action. Has to be one of the names in @bazel\_tools//tools/build\_defs/cc:action\_names.bzl (https://github.com/bazelbuild/bazel/blob/master/tools/build\_defs/cc/action\_names.bzl) |
+| `feature_configuration` | [FeatureConfiguration](/versions/8.0.1/rules/lib/builtins/FeatureConfiguration); required  Feature configuration to be queried. |
+| `action_name` | [string](/versions/8.0.1/rules/lib/core/string); required  Name of the action. Has to be one of the names in @bazel\_tools//tools/build\_defs/cc:action\_names.bzl (https://github.com/bazelbuild/bazel/blob/master/tools/build\_defs/cc/action\_names.bzl) |
 
 ## is\_enabled
 
@@ -406,8 +406,8 @@ Returns True if given feature is enabled in the feature configuration.
 
 | Parameter | Description |
 | --- | --- |
-| `feature_configuration` | [FeatureConfiguration](../builtins/FeatureConfiguration); required  Feature configuration to be queried. |
-| `feature_name` | [string](../core/string); required  Name of the feature. |
+| `feature_configuration` | [FeatureConfiguration](/versions/8.0.1/rules/lib/builtins/FeatureConfiguration); required  Feature configuration to be queried. |
+| `feature_name` | [string](/versions/8.0.1/rules/lib/core/string); required  Name of the feature. |
 
 ## link
 
@@ -421,20 +421,20 @@ Should be used for C++ transitive linking.
 
 | Parameter | Description |
 | --- | --- |
-| `actions` | [actions](../builtins/actions); required  `actions` object. |
-| `name` | [string](../core/string); required  This is used for naming the output artifacts of actions created by this method. |
-| `feature_configuration` | [FeatureConfiguration](../builtins/FeatureConfiguration); required  `feature_configuration` to be queried. |
+| `actions` | [actions](/versions/8.0.1/rules/lib/builtins/actions); required  `actions` object. |
+| `name` | [string](/versions/8.0.1/rules/lib/core/string); required  This is used for naming the output artifacts of actions created by this method. |
+| `feature_configuration` | [FeatureConfiguration](/versions/8.0.1/rules/lib/builtins/FeatureConfiguration); required  `feature_configuration` to be queried. |
 | `cc_toolchain` | Info; required  `CcToolchainInfo` provider to be used. |
-| `language` | [string](../core/string); default is `'c++'`  Only C++ supported for now. Do not use this parameter. |
-| `output_type` | [string](../core/string); default is `'executable'`  Can be either 'executable' or 'dynamic\_library'. |
-| `link_deps_statically` | [bool](../core/bool); default is `True`  True to link dependencies statically, False dynamically. |
-| `compilation_outputs` | [CcCompilationOutputs](../builtins/CcCompilationOutputs); or `None`; default is `None`  Compilation outputs containing object files to link. |
-| `linking_contexts` | [sequence](../core/list); default is `[]`  Linking contexts from dependencies to be linked into the linking context generated by this rule. |
-| `user_link_flags` | [sequence](../core/list); default is `[]`  Additional list of linker options. |
-| `stamp` | [int](../core/int); default is `0`  Whether to include build information in the linked executable, if output\_type is 'executable'. If 1, build information is always included. If 0 (the default build information is always excluded. If -1, uses the default behavior, which may be overridden by the --[no]stamp flag. This should be unset (or set to 0) when generating the executable output for test rules. |
-| `additional_inputs` | [sequence](../core/list); or [depset](../builtins/depset); default is `[]`  For additional inputs to the linking action, e.g.: linking scripts. |
-| `additional_outputs` | [sequence](../core/list); default is `[]`  For additional outputs to the linking action, e.g.: map files. |
-| `variables_extension` | [dict](../core/dict); default is `{}`  Additional variables to pass to the toolchain configuration when create link command line. |
+| `language` | [string](/versions/8.0.1/rules/lib/core/string); default is `'c++'`  Only C++ supported for now. Do not use this parameter. |
+| `output_type` | [string](/versions/8.0.1/rules/lib/core/string); default is `'executable'`  Can be either 'executable' or 'dynamic\_library'. |
+| `link_deps_statically` | [bool](/versions/8.0.1/rules/lib/core/bool); default is `True`  True to link dependencies statically, False dynamically. |
+| `compilation_outputs` | [CcCompilationOutputs](/versions/8.0.1/rules/lib/builtins/CcCompilationOutputs); or `None`; default is `None`  Compilation outputs containing object files to link. |
+| `linking_contexts` | [sequence](/versions/8.0.1/rules/lib/core/list); default is `[]`  Linking contexts from dependencies to be linked into the linking context generated by this rule. |
+| `user_link_flags` | [sequence](/versions/8.0.1/rules/lib/core/list); default is `[]`  Additional list of linker options. |
+| `stamp` | [int](/versions/8.0.1/rules/lib/core/int); default is `0`  Whether to include build information in the linked executable, if output\_type is 'executable'. If 1, build information is always included. If 0 (the default build information is always excluded. If -1, uses the default behavior, which may be overridden by the --[no]stamp flag. This should be unset (or set to 0) when generating the executable output for test rules. |
+| `additional_inputs` | [sequence](/versions/8.0.1/rules/lib/core/list); or [depset](/versions/8.0.1/rules/lib/builtins/depset); default is `[]`  For additional inputs to the linking action, e.g.: linking scripts. |
+| `additional_outputs` | [sequence](/versions/8.0.1/rules/lib/core/list); default is `[]`  For additional outputs to the linking action, e.g.: map files. |
+| `variables_extension` | [dict](/versions/8.0.1/rules/lib/core/dict); default is `{}`  Additional variables to pass to the toolchain configuration when create link command line. |
 
 ## merge\_compilation\_contexts
 
@@ -448,7 +448,7 @@ Merges multiple `CompilationContexts`s into one.
 
 | Parameter | Description |
 | --- | --- |
-| `compilation_contexts` | [sequence](../core/list); default is `[]`  List of `CompilationContexts`s to be merged. The headers of each context will be exported by the direct fields in the returned provider. |
+| `compilation_contexts` | [sequence](/versions/8.0.1/rules/lib/core/list); default is `[]`  List of `CompilationContexts`s to be merged. The headers of each context will be exported by the direct fields in the returned provider. |
 
 ## merge\_compilation\_outputs
 
@@ -462,4 +462,4 @@ Merge compilation outputs.
 
 | Parameter | Description |
 | --- | --- |
-| `compilation_outputs` | [sequence](../core/list); default is `[]` |
\ No newline at end of file
+| `compilation_outputs` | [sequence](/versions/8.0.1/rules/lib/core/list); default is `[]` |
\ No newline at end of file
diff --git a/versions/8.0.1/rules/lib/toplevel/config.mdx b/versions/8.0.1/rules/lib/toplevel/config.mdx
index 4b60c243..cb8926e4 100644
--- a/versions/8.0.1/rules/lib/toplevel/config.mdx
+++ b/versions/8.0.1/rules/lib/toplevel/config.mdx
@@ -36,7 +36,7 @@ A bool-typed build setting
 
 | Parameter | Description |
 | --- | --- |
-| `flag` | [bool](../core/bool); default is `False` |
+| `flag` | [bool](/versions/8.0.1/rules/lib/core/bool); default is `False` |
 
 ## exec
 
@@ -50,7 +50,7 @@ Creates an execution transition.
 
 | Parameter | Description |
 | --- | --- |
-| `exec_group` | [string](../core/string); or `None`; default is `None`  The name of the exec group whose execution platform this transition will use. If not provided, this exec transition will use the target's default execution platform. |
+| `exec_group` | [string](/versions/8.0.1/rules/lib/core/string); or `None`; default is `None`  The name of the exec group whose execution platform this transition will use. If not provided, this exec transition will use the target's default execution platform. |
 
 ## int
 
@@ -64,7 +64,7 @@ An integer-typed build setting
 
 | Parameter | Description |
 | --- | --- |
-| `flag` | [bool](../core/bool); default is `False`  Whether or not this build setting is callable on the command line. |
+| `flag` | [bool](/versions/8.0.1/rules/lib/core/bool); default is `False`  Whether or not this build setting is callable on the command line. |
 
 ## none
 
@@ -86,8 +86,8 @@ A string-typed build setting
 
 | Parameter | Description |
 | --- | --- |
-| `flag` | [bool](../core/bool); default is `False`  Whether or not this build setting is callable on the command line. |
-| `allow_multiple` | [bool](../core/bool); default is `False`  Deprecated, use a `string_list` setting with `repeatable = True` instead. If set, this flag is allowed to be set multiple times on the command line. The Value of the flag as accessed in transitions and build setting implementation function will be a list of strings. Insertion order and repeated values are both maintained. This list can be post-processed in the build setting implementation function if different behavior is desired. |
+| `flag` | [bool](/versions/8.0.1/rules/lib/core/bool); default is `False`  Whether or not this build setting is callable on the command line. |
+| `allow_multiple` | [bool](/versions/8.0.1/rules/lib/core/bool); default is `False`  Deprecated, use a `string_list` setting with `repeatable = True` instead. If set, this flag is allowed to be set multiple times on the command line. The Value of the flag as accessed in transitions and build setting implementation function will be a list of strings. Insertion order and repeated values are both maintained. This list can be post-processed in the build setting implementation function if different behavior is desired. |
 
 ## string\_list
 
@@ -101,8 +101,8 @@ A string list-typed build setting. On the command line pass a list using comma-s
 
 | Parameter | Description |
 | --- | --- |
-| `flag` | [bool](../core/bool); default is `False`  Whether or not this build setting is callable on the command line. |
-| `repeatable` | [bool](../core/bool); default is `False`  If set, instead of expecting a comma-separated value, this flag is allowed to be set multiple times on the command line with each individual value treated as a single string to add to the list value. Insertion order and repeated values are both maintained. This list can be post-processed in the build setting implementation function if different behavior is desired. |
+| `flag` | [bool](/versions/8.0.1/rules/lib/core/bool); default is `False`  Whether or not this build setting is callable on the command line. |
+| `repeatable` | [bool](/versions/8.0.1/rules/lib/core/bool); default is `False`  If set, instead of expecting a comma-separated value, this flag is allowed to be set multiple times on the command line with each individual value treated as a single string to add to the list value. Insertion order and repeated values are both maintained. This list can be post-processed in the build setting implementation function if different behavior is desired. |
 
 ## target
 
diff --git a/versions/8.0.1/rules/lib/toplevel/config_common.mdx b/versions/8.0.1/rules/lib/toplevel/config_common.mdx
index 9169b17a..7cf4cb65 100644
--- a/versions/8.0.1/rules/lib/toplevel/config_common.mdx
+++ b/versions/8.0.1/rules/lib/toplevel/config_common.mdx
@@ -29,5 +29,5 @@ Declare a rule's dependency on a toolchain type.
 
 | Parameter | Description |
 | --- | --- |
-| `name` | [string](../core/string); or [Label](../builtins/Label); required  The toolchain type that is required. |
-| `mandatory` | [bool](../core/bool); default is `True`  Whether the toolchain type is mandatory or optional. |
\ No newline at end of file
+| `name` | [string](/versions/8.0.1/rules/lib/core/string); or [Label](/versions/8.0.1/rules/lib/builtins/Label); required  The toolchain type that is required. |
+| `mandatory` | [bool](/versions/8.0.1/rules/lib/core/bool); default is `True`  Whether the toolchain type is mandatory or optional. |
\ No newline at end of file
diff --git a/versions/8.0.1/rules/lib/toplevel/coverage_common.mdx b/versions/8.0.1/rules/lib/toplevel/coverage_common.mdx
index e93e1226..31280397 100644
--- a/versions/8.0.1/rules/lib/toplevel/coverage_common.mdx
+++ b/versions/8.0.1/rules/lib/toplevel/coverage_common.mdx
@@ -14,14 +14,14 @@ Helper functions to access coverage-related infrastructure.
 InstrumentedFilesInfo coverage_common.instrumented_files_info(ctx, *, source_attributes=[], dependency_attributes=[], extensions=None, metadata_files=[])
 ```
 
-Creates a new [InstrumentedFilesInfo](../providers/InstrumentedFilesInfo) instance. Use this provider to communicate coverage-related attributes of the current build rule.
+Creates a new [InstrumentedFilesInfo](/versions/8.0.1/rules/lib/providers/InstrumentedFilesInfo) instance. Use this provider to communicate coverage-related attributes of the current build rule.
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `ctx` | [ctx](../builtins/ctx); required  The rule context. |
-| `source_attributes` | [sequence](../core/list); default is `[]`  A list of attribute names which contain source files processed by this rule. |
-| `dependency_attributes` | [sequence](../core/list); default is `[]`  A list of attribute names which might provide runtime dependencies (either code dependencies or runfiles). |
-| `extensions` | [sequence](../core/list) of [string](../core/string)s; or `None`; default is `None`  File extensions used to filter files from source\_attributes. For example, 'js'. If not provided (or None), then all files from source\_attributes will be added to instrumented files, if an empty list is provided, then no files from source attributes will be added. |
-| `metadata_files` | [sequence](../core/list) of [File](../builtins/File)s; default is `[]`  Additional files required to generate coverage LCOV files after code execution. e.g. .gcno files for C++. |
\ No newline at end of file
+| `ctx` | [ctx](/versions/8.0.1/rules/lib/builtins/ctx); required  The rule context. |
+| `source_attributes` | [sequence](/versions/8.0.1/rules/lib/core/list); default is `[]`  A list of attribute names which contain source files processed by this rule. |
+| `dependency_attributes` | [sequence](/versions/8.0.1/rules/lib/core/list); default is `[]`  A list of attribute names which might provide runtime dependencies (either code dependencies or runfiles). |
+| `extensions` | [sequence](/versions/8.0.1/rules/lib/core/list) of [string](/versions/8.0.1/rules/lib/core/string)s; or `None`; default is `None`  File extensions used to filter files from source\_attributes. For example, 'js'. If not provided (or None), then all files from source\_attributes will be added to instrumented files, if an empty list is provided, then no files from source attributes will be added. |
+| `metadata_files` | [sequence](/versions/8.0.1/rules/lib/core/list) of [File](/versions/8.0.1/rules/lib/builtins/File)s; default is `[]`  Additional files required to generate coverage LCOV files after code execution. e.g. .gcno files for C++. |
\ No newline at end of file
diff --git a/versions/8.0.1/rules/lib/toplevel/java_common.mdx b/versions/8.0.1/rules/lib/toplevel/java_common.mdx
index 06fed050..2782ac99 100644
--- a/versions/8.0.1/rules/lib/toplevel/java_common.mdx
+++ b/versions/8.0.1/rules/lib/toplevel/java_common.mdx
@@ -35,33 +35,33 @@ Compiles Java source files/jars from the implementation of a Starlark rule and r
 
 | Parameter | Description |
 | --- | --- |
-| `ctx` | [ctx](../builtins/ctx); required  The rule context. |
-| `source_jars` | [sequence](../core/list) of [File](../builtins/File)s; default is `[]`  A list of the jars to be compiled. At least one of source\_jars or source\_files should be specified. |
-| `source_files` | [sequence](../core/list) of [File](../builtins/File)s; default is `[]`  A list of the Java source files to be compiled. At least one of source\_jars or source\_files should be specified. |
-| `output` | [File](../builtins/File); required |
-| `output_source_jar` | [File](../builtins/File); or `None`; default is `None`  The output source jar. Defaults to `{output\_jar}-src.jar` if unset. |
-| `javac_opts` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  A list of the desired javac options. |
-| `deps` | [sequence](../core/list) of [struct](../builtins/struct)s; default is `[]`  A list of dependencies. |
-| `runtime_deps` | [sequence](../core/list) of [struct](../builtins/struct)s; default is `[]`  A list of runtime dependencies. |
-| `exports` | [sequence](../core/list) of [struct](../builtins/struct)s; default is `[]`  A list of exports. |
-| `plugins` | [sequence](../core/list) of [struct](../builtins/struct)s; or [sequence](../core/list) of [struct](../builtins/struct)s; default is `[]`  A list of plugins. |
-| `exported_plugins` | [sequence](../core/list) of [struct](../builtins/struct)s; or [sequence](../core/list) of [struct](../builtins/struct)s; default is `[]`  A list of exported plugins. |
-| `native_libraries` | [sequence](../core/list) of [CcInfo](../providers/CcInfo)s; default is `[]`  CC native library dependencies that are needed for this library. |
-| `annotation_processor_additional_inputs` | [sequence](../core/list) of [File](../builtins/File)s; default is `[]`  A list of inputs that the Java compilation action will take in addition to the Java sources for annotation processing. |
-| `annotation_processor_additional_outputs` | [sequence](../core/list) of [File](../builtins/File)s; default is `[]`  A list of outputs that the Java compilation action will output in addition to the class jar from annotation processing. |
-| `strict_deps` | [string](../core/string); default is `'ERROR'`  A string that specifies how to handle strict deps. Possible values: 'OFF', 'ERROR', 'WARN' and 'DEFAULT'. For more details see [`--strict_java_deps flag`](/versions/8.0.1/docs/user-manual#flag--strict_java_deps). By default 'ERROR'. |
+| `ctx` | [ctx](/versions/8.0.1/rules/lib/builtins/ctx); required  The rule context. |
+| `source_jars` | [sequence](/versions/8.0.1/rules/lib/core/list) of [File](/versions/8.0.1/rules/lib/builtins/File)s; default is `[]`  A list of the jars to be compiled. At least one of source\_jars or source\_files should be specified. |
+| `source_files` | [sequence](/versions/8.0.1/rules/lib/core/list) of [File](/versions/8.0.1/rules/lib/builtins/File)s; default is `[]`  A list of the Java source files to be compiled. At least one of source\_jars or source\_files should be specified. |
+| `output` | [File](/versions/8.0.1/rules/lib/builtins/File); required |
+| `output_source_jar` | [File](/versions/8.0.1/rules/lib/builtins/File); or `None`; default is `None`  The output source jar. Defaults to `{output\_jar}-src.jar` if unset. |
+| `javac_opts` | [sequence](/versions/8.0.1/rules/lib/core/list) of [string](/versions/8.0.1/rules/lib/core/string)s; default is `[]`  A list of the desired javac options. |
+| `deps` | [sequence](/versions/8.0.1/rules/lib/core/list) of [struct](/versions/8.0.1/rules/lib/builtins/struct)s; default is `[]`  A list of dependencies. |
+| `runtime_deps` | [sequence](/versions/8.0.1/rules/lib/core/list) of [struct](/versions/8.0.1/rules/lib/builtins/struct)s; default is `[]`  A list of runtime dependencies. |
+| `exports` | [sequence](/versions/8.0.1/rules/lib/core/list) of [struct](/versions/8.0.1/rules/lib/builtins/struct)s; default is `[]`  A list of exports. |
+| `plugins` | [sequence](/versions/8.0.1/rules/lib/core/list) of [struct](/versions/8.0.1/rules/lib/builtins/struct)s; or [sequence](/versions/8.0.1/rules/lib/core/list) of [struct](/versions/8.0.1/rules/lib/builtins/struct)s; default is `[]`  A list of plugins. |
+| `exported_plugins` | [sequence](/versions/8.0.1/rules/lib/core/list) of [struct](/versions/8.0.1/rules/lib/builtins/struct)s; or [sequence](/versions/8.0.1/rules/lib/core/list) of [struct](/versions/8.0.1/rules/lib/builtins/struct)s; default is `[]`  A list of exported plugins. |
+| `native_libraries` | [sequence](/versions/8.0.1/rules/lib/core/list) of [CcInfo](/versions/8.0.1/rules/lib/providers/CcInfo)s; default is `[]`  CC native library dependencies that are needed for this library. |
+| `annotation_processor_additional_inputs` | [sequence](/versions/8.0.1/rules/lib/core/list) of [File](/versions/8.0.1/rules/lib/builtins/File)s; default is `[]`  A list of inputs that the Java compilation action will take in addition to the Java sources for annotation processing. |
+| `annotation_processor_additional_outputs` | [sequence](/versions/8.0.1/rules/lib/core/list) of [File](/versions/8.0.1/rules/lib/builtins/File)s; default is `[]`  A list of outputs that the Java compilation action will output in addition to the class jar from annotation processing. |
+| `strict_deps` | [string](/versions/8.0.1/rules/lib/core/string); default is `'ERROR'`  A string that specifies how to handle strict deps. Possible values: 'OFF', 'ERROR', 'WARN' and 'DEFAULT'. For more details see [`--strict_java_deps flag`](/versions/8.0.1/docs/user-manual#flag--strict_java_deps). By default 'ERROR'. |
 | `java_toolchain` | Info; required  A JavaToolchainInfo to be used for this compilation. Mandatory. |
 | `bootclasspath` | default is `None`  A BootClassPathInfo to be used for this compilation. If present, overrides the bootclasspath associated with the provided java\_toolchain. |
 | `host_javabase` | default is `None`  **Deprecated**. This parameter is deprecated and will be removed soon. Please do not depend on it. It is *disabled* with `--incompatible_java_common_parameters`. Use this flag to verify your code is compatible with its imminent removal.  Deprecated: You can drop this parameter (host\_javabase is provided with java\_toolchain) |
-| `sourcepath` | [sequence](../core/list) of [File](../builtins/File)s; default is `[]` |
-| `resources` | [sequence](../core/list) of [File](../builtins/File)s; default is `[]` |
-| `resource_jars` | [sequence](../core/list) of [File](../builtins/File)s; default is `[]` |
-| `classpath_resources` | [sequence](../core/list) of [File](../builtins/File)s; default is `[]` |
-| `neverlink` | [bool](../core/bool); default is `False` |
-| `enable_annotation_processing` | [bool](../core/bool); default is `True`  Disables annotation processing in this compilation, causing any annotation processors provided in plugins or in exported\_plugins of deps to be ignored. |
-| `enable_compile_jar_action` | [bool](../core/bool); default is `True`  Enables header compilation or ijar creation. If set to False, it forces use of the full class jar in the compilation classpaths of any dependants. Doing so is intended for use by non-library targets such as binaries that do not have dependants. |
-| `add_exports` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  Allow this library to access the given /. |
-| `add_opens` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  Allow this library to reflectively access the given /. |
+| `sourcepath` | [sequence](/versions/8.0.1/rules/lib/core/list) of [File](/versions/8.0.1/rules/lib/builtins/File)s; default is `[]` |
+| `resources` | [sequence](/versions/8.0.1/rules/lib/core/list) of [File](/versions/8.0.1/rules/lib/builtins/File)s; default is `[]` |
+| `resource_jars` | [sequence](/versions/8.0.1/rules/lib/core/list) of [File](/versions/8.0.1/rules/lib/builtins/File)s; default is `[]` |
+| `classpath_resources` | [sequence](/versions/8.0.1/rules/lib/core/list) of [File](/versions/8.0.1/rules/lib/builtins/File)s; default is `[]` |
+| `neverlink` | [bool](/versions/8.0.1/rules/lib/core/bool); default is `False` |
+| `enable_annotation_processing` | [bool](/versions/8.0.1/rules/lib/core/bool); default is `True`  Disables annotation processing in this compilation, causing any annotation processors provided in plugins or in exported\_plugins of deps to be ignored. |
+| `enable_compile_jar_action` | [bool](/versions/8.0.1/rules/lib/core/bool); default is `True`  Enables header compilation or ijar creation. If set to False, it forces use of the full class jar in the compilation classpaths of any dependants. Doing so is intended for use by non-library targets such as binaries that do not have dependants. |
+| `add_exports` | [sequence](/versions/8.0.1/rules/lib/core/list) of [string](/versions/8.0.1/rules/lib/core/string)s; default is `[]`  Allow this library to access the given /. |
+| `add_opens` | [sequence](/versions/8.0.1/rules/lib/core/list) of [string](/versions/8.0.1/rules/lib/core/string)s; default is `[]`  Allow this library to reflectively access the given /. |
 
 ## JavaRuntimeInfo
 
@@ -91,7 +91,7 @@ Merges the given providers into a single JavaInfo.
 
 | Parameter | Description |
 | --- | --- |
-| `providers` | [sequence](../core/list) of [struct](../builtins/struct)s; required  The list of providers to merge. |
+| `providers` | [sequence](/versions/8.0.1/rules/lib/core/list) of [struct](/versions/8.0.1/rules/lib/builtins/struct)s; required  The list of providers to merge. |
 
 ## pack\_sources
 
@@ -109,11 +109,11 @@ Packs sources and source jars into a single source jar file. The return value is
 
 | Parameter | Description |
 | --- | --- |
-| `actions` | [actions](../builtins/actions); required  ctx.actions |
-| `output_jar` | [File](../builtins/File); or `None`; default is `None`  **Deprecated**. This parameter is deprecated and will be removed soon. Please do not depend on it. It is *disabled* with `--incompatible_java_common_parameters`. Use this flag to verify your code is compatible with its imminent removal.  Deprecated: The output jar of the rule. Used to name the resulting source jar. The parameter sets output\_source\_jar parameter to `{output\_jar}-src.jar`.Use output\_source\_jar parameter directly instead. |
-| `output_source_jar` | [File](../builtins/File); or `None`; default is `None` |
-| `sources` | [sequence](../core/list) of [File](../builtins/File)s; default is `[]`  A list of Java source files to be packed into the source jar. |
-| `source_jars` | [sequence](../core/list) of [File](../builtins/File)s; default is `[]`  A list of source jars to be packed into the source jar. |
+| `actions` | [actions](/versions/8.0.1/rules/lib/builtins/actions); required  ctx.actions |
+| `output_jar` | [File](/versions/8.0.1/rules/lib/builtins/File); or `None`; default is `None`  **Deprecated**. This parameter is deprecated and will be removed soon. Please do not depend on it. It is *disabled* with `--incompatible_java_common_parameters`. Use this flag to verify your code is compatible with its imminent removal.  Deprecated: The output jar of the rule. Used to name the resulting source jar. The parameter sets output\_source\_jar parameter to `{output\_jar}-src.jar`.Use output\_source\_jar parameter directly instead. |
+| `output_source_jar` | [File](/versions/8.0.1/rules/lib/builtins/File); or `None`; default is `None` |
+| `sources` | [sequence](/versions/8.0.1/rules/lib/core/list) of [File](/versions/8.0.1/rules/lib/builtins/File)s; default is `[]`  A list of Java source files to be packed into the source jar. |
+| `source_jars` | [sequence](/versions/8.0.1/rules/lib/core/list) of [File](/versions/8.0.1/rules/lib/builtins/File)s; default is `[]`  A list of source jars to be packed into the source jar. |
 | `java_toolchain` | Info; required  A JavaToolchainInfo to used to find the ijar tool. |
 | `host_javabase` | default is `None`  **Deprecated**. This parameter is deprecated and will be removed soon. Please do not depend on it. It is *disabled* with `--incompatible_java_common_parameters`. Use this flag to verify your code is compatible with its imminent removal.  Deprecated: You can drop this parameter (host\_javabase is provided with java\_toolchain) |
 
@@ -129,9 +129,9 @@ Runs ijar on a jar, stripping it of its method bodies. This helps reduce rebuild
 
 | Parameter | Description |
 | --- | --- |
-| `actions` | [actions](../builtins/actions); required |
-| `jar` | [File](../builtins/File); required  The jar to run ijar on. |
-| `target_label` | [Label](../builtins/Label); or `None`; default is `None`  A target label to stamp the jar with. Used for `add_dep` support. Typically, you would pass `ctx.label` to stamp the jar with the current rule's label. |
+| `actions` | [actions](/versions/8.0.1/rules/lib/builtins/actions); required |
+| `jar` | [File](/versions/8.0.1/rules/lib/builtins/File); required  The jar to run ijar on. |
+| `target_label` | [Label](/versions/8.0.1/rules/lib/builtins/Label); or `None`; default is `None`  A target label to stamp the jar with. Used for `add_dep` support. Typically, you would pass `ctx.label` to stamp the jar with the current rule's label. |
 | `java_toolchain` | Info; required  A JavaToolchainInfo to used to find the ijar tool. |
 
 ## stamp\_jar
@@ -146,7 +146,7 @@ Stamps a jar with a target label for `add_dep` support. The return value is typi
 
 | Parameter | Description |
 | --- | --- |
-| `actions` | [actions](../builtins/actions); required  ctx.actions |
-| `jar` | [File](../builtins/File); required  The jar to run stamp\_jar on. |
-| `target_label` | [Label](../builtins/Label); required  A target label to stamp the jar with. Used for `add_dep` support. Typically, you would pass `ctx.label` to stamp the jar with the current rule's label. |
+| `actions` | [actions](/versions/8.0.1/rules/lib/builtins/actions); required  ctx.actions |
+| `jar` | [File](/versions/8.0.1/rules/lib/builtins/File); required  The jar to run stamp\_jar on. |
+| `target_label` | [Label](/versions/8.0.1/rules/lib/builtins/Label); required  A target label to stamp the jar with. Used for `add_dep` support. Typically, you would pass `ctx.label` to stamp the jar with the current rule's label. |
 | `java_toolchain` | Info; required  A JavaToolchainInfo to used to find the stamp\_jar tool. |
\ No newline at end of file
diff --git a/versions/8.0.1/rules/lib/toplevel/native.mdx b/versions/8.0.1/rules/lib/toplevel/native.mdx
index 204fb814..534449e1 100644
--- a/versions/8.0.1/rules/lib/toplevel/native.mdx
+++ b/versions/8.0.1/rules/lib/toplevel/native.mdx
@@ -46,7 +46,7 @@ If possible, avoid using this function. It makes BUILD files brittle and order-d
 
 | Parameter | Description |
 | --- | --- |
-| `name` | [string](../core/string); required |
+| `name` | [string](/versions/8.0.1/rules/lib/core/string); required |
 
 ## existing\_rules
 
@@ -72,9 +72,9 @@ Specifies a list of files belonging to this package that are exported to other p
 
 | Parameter | Description |
 | --- | --- |
-| `srcs` | [sequence](../core/list) of [string](../core/string)s; required  The list of files to export. |
-| `visibility` | [sequence](../core/list); or `None`; default is `None`  A visibility declaration can to be specified. The files will be visible to the targets specified. If no visibility is specified, the files will be visible to every package. |
-| `licenses` | [sequence](../core/list) of [string](../core/string)s; or `None`; default is `None`  Licenses to be specified. |
+| `srcs` | [sequence](/versions/8.0.1/rules/lib/core/list) of [string](/versions/8.0.1/rules/lib/core/string)s; required  The list of files to export. |
+| `visibility` | [sequence](/versions/8.0.1/rules/lib/core/list); or `None`; default is `None`  A visibility declaration can to be specified. The files will be visible to the targets specified. If no visibility is specified, the files will be visible to every package. |
+| `licenses` | [sequence](/versions/8.0.1/rules/lib/core/list) of [string](/versions/8.0.1/rules/lib/core/string)s; or `None`; default is `None`  Licenses to be specified. |
 
 ## glob
 
@@ -93,9 +93,9 @@ If the `exclude_directories` argument is enabled (set to `1`), files of type dir
 
 | Parameter | Description |
 | --- | --- |
-| `include` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  The list of glob patterns to include. |
-| `exclude` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  The list of glob patterns to exclude. |
-| `exclude_directories` | [int](../core/int); default is `1`  A flag whether to exclude directories or not. |
+| `include` | [sequence](/versions/8.0.1/rules/lib/core/list) of [string](/versions/8.0.1/rules/lib/core/string)s; default is `[]`  The list of glob patterns to include. |
+| `exclude` | [sequence](/versions/8.0.1/rules/lib/core/list) of [string](/versions/8.0.1/rules/lib/core/string)s; default is `[]`  The list of glob patterns to exclude. |
+| `exclude_directories` | [int](/versions/8.0.1/rules/lib/core/int); default is `1`  A flag whether to exclude directories or not. |
 | `allow_empty` | default is `unbound`  Whether we allow glob patterns to match nothing. If `allow\_empty` is False, each individual include pattern must match something and also the final result must be non-empty (after the matches of the `exclude` patterns are excluded). |
 
 ## module\_name
@@ -128,9 +128,9 @@ This function defines a set of packages and assigns a label to the group. The la
 
 | Parameter | Description |
 | --- | --- |
-| `name` | [string](../core/string); required  The unique name for this rule. |
-| `packages` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  A complete enumeration of packages in this group. |
-| `includes` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  Other package groups that are included in this one. |
+| `name` | [string](/versions/8.0.1/rules/lib/core/string); required  The unique name for this rule. |
+| `packages` | [sequence](/versions/8.0.1/rules/lib/core/list) of [string](/versions/8.0.1/rules/lib/core/string)s; default is `[]`  A complete enumeration of packages in this group. |
+| `includes` | [sequence](/versions/8.0.1/rules/lib/core/list) of [string](/versions/8.0.1/rules/lib/core/string)s; default is `[]`  Other package groups that are included in this one. |
 
 ## package\_name
 
@@ -146,19 +146,19 @@ The name of the package being evaluated, without the repository name. For exampl
 Label native.package_relative_label(input)
 ```
 
-Converts the input string into a [Label](../builtins/Label) object, in the context of the package currently being initialized (that is, the `BUILD` file for which the current macro is executing). If the input is already a `Label`, it is returned unchanged.
+Converts the input string into a [Label](/versions/8.0.1/rules/lib/builtins/Label) object, in the context of the package currently being initialized (that is, the `BUILD` file for which the current macro is executing). If the input is already a `Label`, it is returned unchanged.
 
 This function may only be called while evaluating a BUILD file and the macros it directly or indirectly calls; it may not be called in (for instance) a rule implementation function.
 
 The result of this function is the same `Label` value as would be produced by passing the given string to a label-valued attribute of a target declared in the BUILD file.
 
-*Usage note:* The difference between this function and [Label()](../builtins/Label#Label) is that `Label()` uses the context of the package of the `.bzl` file that called it, not the package of the `BUILD` file. Use `Label()` when you need to refer to a fixed target that is hardcoded into the macro, such as a compiler. Use `package_relative_label()` when you need to normalize a label string supplied by the BUILD file to a `Label` object. (There is no way to convert a string to a `Label` in the context of a package other than the BUILD file or the calling .bzl file. For that reason, outer macros should always prefer to pass Label objects to inner macros rather than label strings.)
+*Usage note:* The difference between this function and [Label()](/versions/8.0.1/rules/lib/builtins/Label#Label) is that `Label()` uses the context of the package of the `.bzl` file that called it, not the package of the `BUILD` file. Use `Label()` when you need to refer to a fixed target that is hardcoded into the macro, such as a compiler. Use `package_relative_label()` when you need to normalize a label string supplied by the BUILD file to a `Label` object. (There is no way to convert a string to a `Label` in the context of a package other than the BUILD file or the calling .bzl file. For that reason, outer macros should always prefer to pass Label objects to inner macros rather than label strings.)
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `input` | [string](../core/string); or [Label](../builtins/Label); required  The input label string or Label object. If a Label object is passed, it's returned as is. |
+| `input` | [string](/versions/8.0.1/rules/lib/core/string); or [Label](/versions/8.0.1/rules/lib/builtins/Label); required  The input label string or Label object. If a Label object is passed, it's returned as is. |
 
 ## repo\_name
 
@@ -191,6 +191,6 @@ Returns a new mutable list of every direct subpackage of the current package, re
 
 | Parameter | Description |
 | --- | --- |
-| `include` | [sequence](../core/list) of [string](../core/string)s; required |
-| `exclude` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  The list of glob patterns to exclude from subpackages scan. |
-| `allow_empty` | [bool](../core/bool); default is `False`  Whether we fail if the call returns an empty list. By default empty list indicates potential error in BUILD file where the call to subpackages() is superflous. Setting to true allows this function to succeed in that case. |*
\ No newline at end of file
+| `include` | [sequence](/versions/8.0.1/rules/lib/core/list) of [string](/versions/8.0.1/rules/lib/core/string)s; required |
+| `exclude` | [sequence](/versions/8.0.1/rules/lib/core/list) of [string](/versions/8.0.1/rules/lib/core/string)s; default is `[]`  The list of glob patterns to exclude from subpackages scan. |
+| `allow_empty` | [bool](/versions/8.0.1/rules/lib/core/bool); default is `False`  Whether we fail if the call returns an empty list. By default empty list indicates potential error in BUILD file where the call to subpackages() is superflous. Setting to true allows this function to succeed in that case. |*
\ No newline at end of file
diff --git a/versions/8.0.1/rules/lib/toplevel/platform_common.mdx b/versions/8.0.1/rules/lib/toplevel/platform_common.mdx
index 17edc7c5..4f9c9a07 100644
--- a/versions/8.0.1/rules/lib/toplevel/platform_common.mdx
+++ b/versions/8.0.1/rules/lib/toplevel/platform_common.mdx
@@ -18,7 +18,7 @@ Functions for Starlark to interact with the platform APIs.
 Provider platform_common.ConstraintSettingInfo
 ```
 
-The constructor/key for the [ConstraintSettingInfo](../providers/ConstraintSettingInfo) provider.
+The constructor/key for the [ConstraintSettingInfo](/versions/8.0.1/rules/lib/providers/ConstraintSettingInfo) provider.
 *Note: This API is experimental and may change at any time. It is disabled by default, but may be enabled with `--experimental_platforms_api`*
 
 ## ConstraintValueInfo
@@ -27,7 +27,7 @@ The constructor/key for the [ConstraintSettingInfo](../providers/ConstraintSetti
 Provider platform_common.ConstraintValueInfo
 ```
 
-The constructor/key for the [ConstraintValueInfo](../providers/ConstraintValueInfo) provider.
+The constructor/key for the [ConstraintValueInfo](/versions/8.0.1/rules/lib/providers/ConstraintValueInfo) provider.
 *Note: This API is experimental and may change at any time. It is disabled by default, but may be enabled with `--experimental_platforms_api`*
 
 ## PlatformInfo
@@ -36,7 +36,7 @@ The constructor/key for the [ConstraintValueInfo](../providers/ConstraintValueIn
 Provider platform_common.PlatformInfo
 ```
 
-The constructor/key for the [PlatformInfo](../providers/PlatformInfo) provider.
+The constructor/key for the [PlatformInfo](/versions/8.0.1/rules/lib/providers/PlatformInfo) provider.
 *Note: This API is experimental and may change at any time. It is disabled by default, but may be enabled with `--experimental_platforms_api`*
 
 ## TemplateVariableInfo
@@ -45,7 +45,7 @@ The constructor/key for the [PlatformInfo](../providers/PlatformInfo) provider.
 Provider platform_common.TemplateVariableInfo
 ```
 
-The constructor/key for the [TemplateVariableInfo](../providers/TemplateVariableInfo) provider.
+The constructor/key for the [TemplateVariableInfo](/versions/8.0.1/rules/lib/providers/TemplateVariableInfo) provider.
 
 ## ToolchainInfo
 
@@ -53,4 +53,4 @@ The constructor/key for the [TemplateVariableInfo](../providers/TemplateVariable
 Provider platform_common.ToolchainInfo
 ```
 
-The constructor/key for the [ToolchainInfo](../providers/ToolchainInfo) provider.
\ No newline at end of file
+The constructor/key for the [ToolchainInfo](/versions/8.0.1/rules/lib/providers/ToolchainInfo) provider.
\ No newline at end of file
diff --git a/versions/8.0.1/rules/lib/toplevel/testing.mdx b/versions/8.0.1/rules/lib/toplevel/testing.mdx
index 5489113c..c414aa8f 100644
--- a/versions/8.0.1/rules/lib/toplevel/testing.mdx
+++ b/versions/8.0.1/rules/lib/toplevel/testing.mdx
@@ -24,12 +24,12 @@ The number of transitive dependencies of the test are limited. The limit is cont
 
 | Parameter | Description |
 | --- | --- |
-| `name` | [string](../core/string); required  Name of the target. It should be a Starlark identifier, matching pattern '[A-Za-z\_][A-Za-z0-9\_]\*'. |
-| `implementation` | [function](../core/function); required  The Starlark function implementing this analysis test. It must have exactly one parameter: [ctx](../builtins/ctx). The function is called during the analysis phase. It can access the attributes declared by `attrs` and populated via `attr_values`. The implementation function may not register actions. Instead, it must register a pass/fail result via providing [AnalysisTestResultInfo](../providers/AnalysisTestResultInfo). |
-| `attrs` | [dict](../core/dict); default is `{}`  Dictionary declaring the attributes. See the [rule](../globals/bzl#rule) call. Attributes are allowed to use configuration transitions defined using [analysis\_test\_transition](../globals/bzl#analysis_test_transition). |
-| `fragments` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  List of configuration fragments that are available to the implementation of the analysis test. |
-| `toolchains` | [sequence](../core/list); default is `[]`  The set of toolchains the test requires. See the [rule](../globals/bzl#rule) call. |
-| `attr_values` | [dict](../core/dict) of [string](../core/string)s; default is `{}`  Dictionary of attribute values to pass to the implementation. |
+| `name` | [string](/versions/8.0.1/rules/lib/core/string); required  Name of the target. It should be a Starlark identifier, matching pattern '[A-Za-z\_][A-Za-z0-9\_]\*'. |
+| `implementation` | [function](/versions/8.0.1/rules/lib/core/function); required  The Starlark function implementing this analysis test. It must have exactly one parameter: [ctx](/versions/8.0.1/rules/lib/builtins/ctx). The function is called during the analysis phase. It can access the attributes declared by `attrs` and populated via `attr_values`. The implementation function may not register actions. Instead, it must register a pass/fail result via providing [AnalysisTestResultInfo](/versions/8.0.1/rules/lib/providers/AnalysisTestResultInfo). |
+| `attrs` | [dict](/versions/8.0.1/rules/lib/core/dict); default is `{}`  Dictionary declaring the attributes. See the [rule](/versions/8.0.1/rules/lib/globals/bzl#rule) call. Attributes are allowed to use configuration transitions defined using [analysis\_test\_transition](/versions/8.0.1/rules/lib/globals/bzl#analysis_test_transition). |
+| `fragments` | [sequence](/versions/8.0.1/rules/lib/core/list) of [string](/versions/8.0.1/rules/lib/core/string)s; default is `[]`  List of configuration fragments that are available to the implementation of the analysis test. |
+| `toolchains` | [sequence](/versions/8.0.1/rules/lib/core/list); default is `[]`  The set of toolchains the test requires. See the [rule](/versions/8.0.1/rules/lib/globals/bzl#rule) call. |
+| `attr_values` | [dict](/versions/8.0.1/rules/lib/core/dict) of [string](/versions/8.0.1/rules/lib/core/string)s; default is `{}`  Dictionary of attribute values to pass to the implementation. |
 
 ## ExecutionInfo
 
@@ -37,7 +37,7 @@ The number of transitive dependencies of the test are limited. The limit is cont
 ExecutionInfo testing.ExecutionInfo
 ```
 
-[testing.ExecutionInfo](../providers/ExecutionInfo) provider key/constructor
+[testing.ExecutionInfo](/versions/8.0.1/rules/lib/providers/ExecutionInfo) provider key/constructor
 
 ## TestEnvironment
 
@@ -51,5 +51,5 @@ RunEnvironmentInfo testing.TestEnvironment(environment, inherited_environment=[]
 
 | Parameter | Description |
 | --- | --- |
-| `environment` | [dict](../core/dict); required  A map of string keys and values that represent environment variables and their values. These will be made available during the test execution. |
-| `inherited_environment` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  A sequence of names of environment variables. These variables are made available during the test execution with their current value taken from the shell environment. If a variable is contained in both `environment` and `inherited_environment`, the value inherited from the shell environment will take precedence if set. |
\ No newline at end of file
+| `environment` | [dict](/versions/8.0.1/rules/lib/core/dict); required  A map of string keys and values that represent environment variables and their values. These will be made available during the test execution. |
+| `inherited_environment` | [sequence](/versions/8.0.1/rules/lib/core/list) of [string](/versions/8.0.1/rules/lib/core/string)s; default is `[]`  A sequence of names of environment variables. These variables are made available during the test execution with their current value taken from the shell environment. If a variable is contained in both `environment` and `inherited_environment`, the value inherited from the shell environment will take precedence if set. |
\ No newline at end of file
diff --git a/versions/8.0.1/rules/macro-tutorial.mdx b/versions/8.0.1/rules/macro-tutorial.mdx
index da235b49..92133387 100644
--- a/versions/8.0.1/rules/macro-tutorial.mdx
+++ b/versions/8.0.1/rules/macro-tutorial.mdx
@@ -5,7 +5,7 @@ title: 'Creating a Symbolic Macro'
 IMPORTANT: This tutorial is for [*symbolic macros*](/versions/8.0.1/extending/macros) – the new
 macro system introduced in Bazel 8. If you need to support older Bazel versions,
 you will want to write a [legacy macro](/versions/8.0.1/extending/legacy-macros) instead; take
-a look at [Creating a Legacy Macro](../legacy-macro-tutorial).
+a look at [Creating a Legacy Macro](/versions/8.0.1/rules/legacy-macro-tutorial).
 
 Imagine that you need to run a tool as part of your build. For example, you
 may want to generate or preprocess a source file, or compress a binary. In this
diff --git a/versions/8.0.1/rules/performance.mdx b/versions/8.0.1/rules/performance.mdx
index 3e77e72a..97c9ded6 100644
--- a/versions/8.0.1/rules/performance.mdx
+++ b/versions/8.0.1/rules/performance.mdx
@@ -15,7 +15,7 @@ widespread use.
 ## Use depsets {#use-depsets}
 
 Whenever you are rolling up information from rule dependencies you should use
-[depsets](lib/depset). Only use plain lists or dicts to publish information
+[depsets](/versions/8.0.1/rules/lib/builtins/depset). Only use plain lists or dicts to publish information
 local to the current rule.
 
 A depset represents information as a nested graph which enables sharing.
@@ -73,7 +73,7 @@ See the [depset overview](/versions/8.0.1/extending/depsets) page for more infor
 ### Avoid calling `depset.to_list()` {#avoid-depset-to-list}
 
 You can coerce a depset to a flat list using
-[`to_list()`](lib/depset#to_list), but doing so usually results in O(N^2)
+[`to_list()`](/versions/8.0.1/rules/lib/builtins/depset#to_list), but doing so usually results in O(N^2)
 cost. If at all possible, avoid any flattening of depsets except for debugging
 purposes.
 
@@ -115,7 +115,7 @@ x = depset(transitive = [i.deps for i in inputs])
 
 ## Use ctx.actions.args() for command lines {#ctx-actions-args}
 
-When building command lines you should use [ctx.actions.args()](lib/Args).
+When building command lines you should use [ctx.actions.args()](/versions/8.0.1/rules/lib/builtins/Args).
 This defers expansion of any depsets to the execution phase.
 
 Apart from being strictly faster, this will reduce the memory consumption of
@@ -126,11 +126,11 @@ Here are some tricks:
 * Pass depsets and lists directly as arguments, instead of flattening them
 yourself. They will get expanded by `ctx.actions.args()` for you.
 If you need any transformations on the depset contents, look at
-[ctx.actions.args#add](lib/Args#add) to see if anything fits the bill.
+[ctx.actions.args#add](/versions/8.0.1/rules/lib/builtins/Args#add) to see if anything fits the bill.
 
 * Are you passing `File#path` as arguments? No need. Any
-[File](lib/File) is automatically turned into its
-[path](lib/File#path), deferred to expansion time.
+[File](/versions/8.0.1/rules/lib/builtins/File) is automatically turned into its
+[path](/versions/8.0.1/rules/lib/builtins/File#path), deferred to expansion time.
 
 * Avoid constructing strings by concatenating them together.
 The best string argument is a constant as its memory will be shared between
@@ -138,10 +138,10 @@ all instances of your rule.
 
 * If the args are too long for the command line an `ctx.actions.args()` object
 can be conditionally or unconditionally written to a param file using
-[`ctx.actions.args#use_param_file`](lib/Args#use_param_file). This is
+[`ctx.actions.args#use_param_file`](/versions/8.0.1/rules/lib/builtins/Args#use_param_file). This is
 done behind the scenes when the action is executed. If you need to explicitly
 control the params file you can write it manually using
-[`ctx.actions.write`](lib/actions#write).
+[`ctx.actions.write`](/versions/8.0.1/rules/lib/builtins/actions#write).
 
 Example:
 
@@ -176,7 +176,7 @@ def _to_short_path(f):
 
 ## Transitive action inputs should be depsets {#transitive-action-inputs}
 
-When building an action using [ctx.actions.run](lib/actions?#run), do not
+When building an action using [ctx.actions.run](/versions/8.0.1/rules/lib/builtins/actions#run), do not
 forget that the `inputs` field accepts a depset. Use this whenever inputs are
 collected from dependencies transitively.
 
diff --git a/versions/8.0.1/rules/rules-tutorial.mdx b/versions/8.0.1/rules/rules-tutorial.mdx
index 0f3624be..1f3b3c25 100644
--- a/versions/8.0.1/rules/rules-tutorial.mdx
+++ b/versions/8.0.1/rules/rules-tutorial.mdx
@@ -31,9 +31,9 @@ foo_binary = rule(
 )
 ```
 
-When you call the [`rule`](lib/globals#rule) function, you
+When you call the [`rule`](/versions/8.0.1/rules/lib/globals#rule) function, you
 must define a callback function. The logic will go there, but you
-can leave the function empty for now. The [`ctx`](lib/ctx) argument
+can leave the function empty for now. The [`ctx`](/versions/8.0.1/rules/lib/builtins/ctx) argument
 provides information about the target.
 
 You can load the rule and use it from a `BUILD` file.
@@ -86,10 +86,10 @@ foo_binary(name = "bin1")
 foo_binary(name = "bin2")
 ```
 
-[`ctx.label`](lib/ctx#label)
+[`ctx.label`](/versions/8.0.1/rules/lib/builtins/ctx#label)
 corresponds to the label of the target being analyzed. The `ctx` object has
 many useful fields and methods; you can find an exhaustive list in the
-[API reference](lib/ctx).
+[API reference](/versions/8.0.1/rules/lib/builtins/ctx).
 
 Query the code:
 
@@ -145,7 +145,7 @@ bin2
 ```
 
 Whenever you declare a file, you have to tell Bazel how to generate it by
-creating an action. Use [`ctx.actions.write`](lib/actions#write),
+creating an action. Use [`ctx.actions.write`](/versions/8.0.1/rules/lib/builtins/actions#write),
 to create a file with the given content.
 
 ```python
@@ -200,7 +200,7 @@ You have successfully generated a file!
 ## Attributes
 
 To make the rule more useful, add new attributes using
-[the `attr` module](lib/attr) and update the rule definition.
+[the `attr` module](/versions/8.0.1/rules/lib/toplevel/attr) and update the rule definition.
 
 Add a string attribute called `username`:
 
@@ -236,22 +236,22 @@ def _foo_binary_impl(ctx):
 ```
 
 Note that you can make the attribute mandatory or set a default value. Look at
-the documentation of [`attr.string`](lib/attr#string).
-You may also use other types of attributes, such as [boolean](lib/attr#bool)
-or [list of integers](lib/attr#int_list).
+the documentation of [`attr.string`](/versions/8.0.1/rules/lib/toplevel/attr#string).
+You may also use other types of attributes, such as [boolean](/versions/8.0.1/rules/lib/toplevel/attr#bool)
+or [list of integers](/versions/8.0.1/rules/lib/toplevel/attr#int_list).
 
 ## Dependencies
 
-Dependency attributes, such as [`attr.label`](lib/attr#label)
-and [`attr.label_list`](lib/attr#label_list),
+Dependency attributes, such as [`attr.label`](/versions/8.0.1/rules/lib/toplevel/attr#label)
+and [`attr.label_list`](/versions/8.0.1/rules/lib/toplevel/attr#label_list),
 declare a dependency from the target that owns the attribute to the target whose
 label appears in the attribute's value. This kind of attribute forms the basis
 of the target graph.
 
 In the `BUILD` file, the target label appears as a string object, such as
 `//pkg:name`. In the implementation function, the target will be accessible as a
-[`Target`](lib/Target) object. For example, view the files returned
-by the target using [`Target.files`](lib/Target#modules.Target.files).
+[`Target`](/versions/8.0.1/rules/lib/builtins/Target) object. For example, view the files returned
+by the target using [`Target.files`](/versions/8.0.1/rules/lib/builtins/Target#modules.Target.files).
 
 ### Multiple files
 
@@ -294,7 +294,7 @@ implementation function, but this has two problems. First, as the template gets
 bigger, it becomes more memory efficient to put it in a separate file and avoid
 constructing large strings during the analysis phase. Second, using a separate
 file is more convenient for the user. Instead, use
-[`ctx.actions.expand_template`](lib/actions#expand_template),
+[`ctx.actions.expand_template`](/versions/8.0.1/rules/lib/builtins/actions#expand_template),
 which performs substitutions on a template file.
 
 Create a `template` attribute to declare a dependency on the template
diff --git a/versions/8.0.1/rules/testing.mdx b/versions/8.0.1/rules/testing.mdx
index 8845e7a0..83df4340 100644
--- a/versions/8.0.1/rules/testing.mdx
+++ b/versions/8.0.1/rules/testing.mdx
@@ -234,7 +234,7 @@ def _inspect_actions_test_impl(ctx):
 ```
 
 Note that `analysistest.target_actions(env)` returns a list of
-[`Action`](lib/Action) objects which represent actions registered by the
+[`Action`](/versions/8.0.1/rules/lib/builtins/Action) objects which represent actions registered by the
 target under test.
 
 ### Verifying rule behavior under different flags {#verifying-rule-behavior}
diff --git a/versions/8.0.1/rules/verbs-tutorial.mdx b/versions/8.0.1/rules/verbs-tutorial.mdx
index 61c48e6f..967f8c8c 100644
--- a/versions/8.0.1/rules/verbs-tutorial.mdx
+++ b/versions/8.0.1/rules/verbs-tutorial.mdx
@@ -49,8 +49,7 @@ This pattern can also be seen in the Angular project. The
 produces two targets. The first is a standard `nodejs_test` target which compares
 some generated output against a "golden" file (that is, a file containing the
 expected output). This can be built and run with a normal `bazel
-test` invocation. In `angular-cli`, you can run [one such
-target](https://github.com/angular/angular-cli/blob/e1269cb520871ee29b1a4eec6e6c0e4a94f0b5fc/etc/api/BUILD)
+test` invocation. In `angular-cli`, you can run [one such target](https://github.com/angular/angular-cli/blob/e1269cb520871ee29b1a4eec6e6c0e4a94f0b5fc/etc/api/BUILD)
 with `bazel test //etc/api:angular_devkit_core_api`.
 
 Over time, this golden file may need to be updated for legitimate reasons.
@@ -159,7 +158,7 @@ an imaginary `bazel publish` command.
 It's not immediately obvious what the implementation of the `_sphinx_publisher`
 rule might look like. Often, actions like this write a _launcher_ shell script.
 This method typically involves using
-[`ctx.actions.expand_template`](lib/actions#expand_template)
+[`ctx.actions.expand_template`](/versions/8.0.1/rules/lib/builtins/actions#expand_template)
 to write a very simple shell script, in this case invoking the publisher binary
 with a path to the output of the primary target. This way, the publisher
 implementation can remain generic, the `_sphinx_site` rule can just produce
diff --git a/versions/8.0.1/run/build.mdx b/versions/8.0.1/run/build.mdx
index 1560fdfd..b55157b1 100644
--- a/versions/8.0.1/run/build.mdx
+++ b/versions/8.0.1/run/build.mdx
@@ -633,8 +633,7 @@ Note: Hermeticity means that the action only uses its declared input
 files and no other files in the filesystem, and it only produces its declared
 output files. See [Hermeticity](/versions/8.0.1/basics/hermeticity) for more details.
 
-On some platforms such as [Google Kubernetes
-Engine](https://cloud.google.com/kubernetes-engine/) cluster nodes or Debian,
+On some platforms such as [Google Kubernetes Engine](https://cloud.google.com/kubernetes-engine/) cluster nodes or Debian,
 user namespaces are deactivated by default due to security
 concerns. This can be checked by looking at the file
 `/proc/sys/kernel/unprivileged_userns_clone`: if it exists and contains a 0,
diff --git a/versions/8.0.1/start/android-app.mdx b/versions/8.0.1/start/android-app.mdx
index 28af56ff..287dfe04 100644
--- a/versions/8.0.1/start/android-app.mdx
+++ b/versions/8.0.1/start/android-app.mdx
@@ -36,8 +36,7 @@ In this tutorial you learn how to:
 Before you begin the tutorial, install the following software:
 
 * **Bazel.** To install, follow the [installation instructions](/versions/8.0.1/install).
-* **Android Studio.** To install, follow the steps to [download Android
-  Studio](https://developer.android.com/sdk/index.html).
+* **Android Studio.** To install, follow the steps to [download Android Studio](https://developer.android.com/sdk/index.html).
   Execute the setup wizard to download the SDK and configure your environment.
 * (Optional) **Git.** Use `git` to download the Android app project.
 
@@ -52,8 +51,7 @@ This app has a single button that prints a greeting when clicked:
 
 **Figure 1.** Android app button greeting.
 
-Clone the repository with `git` (or [download the ZIP file
-directly](https://github.com/bazelbuild/examples/archive/master.zip)):
+Clone the repository with `git` (or [download the ZIP file directly](https://github.com/bazelbuild/examples/archive/master.zip)):
 
 ```posix-terminal
 git clone https://github.com/bazelbuild/examples
@@ -103,8 +101,7 @@ A [workspace](/versions/8.0.1/concepts/build-ref#workspace) is a directory that
 source files for one or more software projects, and has a `MODULE.bazel` file at
 its root.
 
-The `MODULE.bazel` file may be empty or may contain references to [external
-dependencies](/versions/8.0.1/external/overview) required to build your project.
+The `MODULE.bazel` file may be empty or may contain references to [external dependencies](/versions/8.0.1/external/overview) required to build your project.
 
 First, run the following command to create an empty `MODULE.bazel` file:
 
@@ -147,8 +144,7 @@ environment variable, and automatically detect the highest API level and the
 latest version of build tools installed within that location.
 
 You can set the `ANDROID_HOME` variable to the location of the Android SDK. Find
-the path to the installed SDK using Android Studio's [SDK
-Manager](https://developer.android.com/studio/intro/update#sdk-manager).
+the path to the installed SDK using Android Studio's [SDK Manager](https://developer.android.com/studio/intro/update#sdk-manager).
 Assuming the SDK is installed to default locations, you can use the following
 commands to set the `ANDROID_HOME` variable:
 
@@ -170,16 +166,14 @@ them permanent, run the following commands:
 | Windows (PowerShell)     | `[System.Environment]::SetEnvironmentVariable('ANDROID_HOME', "$env:LOCALAPPDATA\Android\Sdk", [System.EnvironmentVariableTarget]::User)` |
 
 **Optional:** If you want to compile native code into your Android app, you
-also need to download the [Android
-NDK](https://developer.android.com/ndk/downloads/index.html)
+also need to download the [Android NDK](https://developer.android.com/ndk/downloads/index.html)
 and use `rules_android_ndk` by adding the following line to your `MODULE.bazel` file:
 
 ```python
 bazel_dep(name = "rules_android_ndk", version = "0.1.2")
 ```
 
-For more information, read [Using the Android Native Development Kit with
-Bazel](/versions/8.0.1/docs/android-ndk).
+For more information, read [Using the Android Native Development Kit with Bazel](/versions/8.0.1/docs/android-ndk).
 
 It's not necessary to set the API levels to the same value for the SDK and NDK.
 [This page](https://developer.android.com/ndk/guides/stable_apis.html)
@@ -221,8 +215,7 @@ files or other dependencies. Bazel provides two build rules,
 build an Android app.
 
 For this tutorial, you'll first use the
-`android_library` rule to tell Bazel to build an [Android library
-module](http://developer.android.com/tools/projects/index.html#LibraryProjects)
+`android_library` rule to tell Bazel to build an [Android library module](http://developer.android.com/tools/projects/index.html#LibraryProjects)
 from the app source code and resource files. You'll then use the
 `android_binary` rule to tell Bazel how to build the Android application package.
 
@@ -337,11 +330,9 @@ file:
 ### Run the app
 
 You can now deploy the app to a connected Android device or emulator from the
-command line using the [`bazel
-mobile-install`](/versions/8.0.1/docs/user-manual#mobile-install) command. This command uses
+command line using the [`bazel mobile-install`](/versions/8.0.1/docs/user-manual#mobile-install) command. This command uses
 the Android Debug Bridge (`adb`) to communicate with the device. You must set up
-your device to use `adb` following the instructions in [Android Debug
-Bridge](http://developer.android.com/tools/help/adb.html) before deployment. You
+your device to use `adb` following the instructions in [Android Debug Bridge](http://developer.android.com/tools/help/adb.html) before deployment. You
 can also choose to install the app on the Android emulator included in Android
 Studio. Make sure the emulator is running before executing the command below.
 
diff --git a/versions/8.0.1/start/cpp.mdx b/versions/8.0.1/start/cpp.mdx
index 0ab301dc..52a6590e 100644
--- a/versions/8.0.1/start/cpp.mdx
+++ b/versions/8.0.1/start/cpp.mdx
@@ -19,8 +19,7 @@ Estimated completion time: 30 minutes.
 ### Prerequisites {#prerequisites}
 
 Start by [installing Bazel](https://bazel.build/versions/8.0.1/install), if you haven't
-already. This tutorial uses Git for source control, so for best results [install
-Git](https://git-scm.com/book/en/v2/Getting-Started-Installing-Git) as well.
+already. This tutorial uses Git for source control, so for best results [install Git](https://git-scm.com/book/en/v2/Getting-Started-Installing-Git) as well.
 
 Next, retrieve the sample project from Bazel's GitHub repository by running the
 following in your command-line tool of choice:
@@ -63,9 +62,7 @@ examples
 ```
 
 There are three sets of files, each set representing a stage in this tutorial.
-In the first stage, you will build a single [target]
-(https://bazel.build/reference/glossary#target) residing in a single [package]
-(https://bazel.build/reference/glossary#package). In the second stage, you will
+In the first stage, you will build a single [target](https://bazel.build/versions/8.0.1/reference/glossary#target) residing in a single [package](https://bazel.build/versions/8.0.1/reference/glossary#package). In the second stage, you will
 build both a binary and a library from a single package. In the third and final
 stage, you will build a project with multiple packages and build it with
 multiple targets.
@@ -86,8 +83,7 @@ It also contains these significant files:
 *   The `MODULE.bazel` file, which identifies the directory and its contents as
     a Bazel workspace and lives at the root of the project's directory
     structure. It's also where you specify your external dependencies.
-*   One or more [`BUILD`
-    files](https://bazel.build/reference/glossary#build-file), which tell Bazel
+*   One or more [`BUILD` files](https://bazel.build/versions/8.0.1/reference/glossary#build-file), which tell Bazel
     how to build different parts of the project. A directory within the
     workspace that contains a `BUILD` file is a
     [package](https://bazel.build/versions/8.0.1/reference/glossary#package). (More on packages
@@ -182,9 +178,7 @@ This results in a printed "`Hello world`" message.
 
 Here's the dependency graph of Stage 1:
 
-![Dependency graph for hello-world displays a single target with a single source
-file.](/versions/8.0.1/docs/images/cpp-tutorial-stage1.png "Dependency graph for hello-world
-displays a single target with a single source file.")
+![Dependency graph for hello-world displays a single target with a single source file.](/versions/8.0.1/docs/images/cpp-tutorial-stage1.png "Dependency graph for hello-world displays a single target with a single source file.")
 
 ### Summary: stage 1 {#summary-stage-1}
 
@@ -231,8 +225,7 @@ cc_binary(
 ```
 
 With this `BUILD` file, Bazel first builds the `hello-greet` library (using
-Bazel's built-in [`cc_library`
-rule](https://bazel.build/reference/be/c-cpp#cc_library)), then the
+Bazel's built-in [`cc_library` rule](https://bazel.build/versions/8.0.1/reference/be/c-cpp#cc_library)), then the
 `hello-world` binary. The `deps` attribute in the `hello-world` target tells
 Bazel that the `hello-greet` library is required to build the `hello-world`
 binary.
@@ -272,10 +265,7 @@ recompiles that file.
 Looking at the dependency graph, you can see that `hello-world` depends on an
 extra input named `hello-greet`:
 
-![Dependency graph for `hello-world` displays dependency changes after
-modification to the file.](/versions/8.0.1/docs/images/cpp-tutorial-stage2.png "Dependency
-graph for `hello-world` displays dependency changes after modification to the
-file.")
+![Dependency graph for `hello-world` displays dependency changes after modification to the file.](/versions/8.0.1/docs/images/cpp-tutorial-stage2.png "Dependency graph for `hello-world` displays dependency changes after modification to the file.")
 
 ### Summary: stage 2 {#summary-stage-2}
 
@@ -343,11 +333,7 @@ in the `lib` package (hence the target label `//lib:hello-time`) - Bazel knows
 this through the `deps` attribute. You can see this reflected in the dependency
 graph:
 
-![Dependency graph for `hello-world` displays how the target in the main package
-depends on the target in the `lib`
-package.](/versions/8.0.1/docs/images/cpp-tutorial-stage3.png "Dependency graph for
-`hello-world` displays how the target in the main package depends on the target
-in the `lib` package.")
+![Dependency graph for `hello-world` displays how the target in the main package depends on the target in the `lib` package.](/versions/8.0.1/docs/images/cpp-tutorial-stage3.png "Dependency graph for `hello-world` displays how the target in the main package depends on the target in the `lib` package.")
 
 For the build to succeed, you make the `//lib:hello-time` target in `lib/BUILD`
 explicitly visible to targets in `main/BUILD` using the visibility attribute.
@@ -395,15 +381,11 @@ Bazel journey.
 You've now completed your first basic build with Bazel, but this is just the
 start. Here are some more resources to continue learning with Bazel:
 
-*   To keep focusing on C++, read about common [C++ build use
-    cases](https://bazel.build/tutorials/cpp-use-cases).
+*   To keep focusing on C++, read about common [C++ build use cases](https://bazel.build/versions/8.0.1/tutorials/cpp-use-cases).
 *   To get started with building other applications with Bazel, see the
-    tutorials for [Java](https://bazel.build/versions/8.0.1/start/java), [Android
-    application](https://bazel.build/start/android-app), or [iOS
-    application](https://bazel.build/start/ios-app).
+    tutorials for [Java](https://bazel.build/versions/8.0.1/start/java), [Android application](https://bazel.build/versions/8.0.1/start/android-app), or [iOS application](https://bazel.build/versions/8.0.1/start/ios-app).
 *   To learn more about working with local and remote repositories, read about
     [external dependencies](https://bazel.build/versions/8.0.1/docs/external).
-*   To learn more about Bazel's other rules, see this [reference
-    guide](https://bazel.build/rules).
+*   To learn more about Bazel's other rules, see this [reference guide](https://bazel.build/versions/8.0.1/rules).
 
 Happy building!
\ No newline at end of file
diff --git a/versions/8.0.1/start/java.mdx b/versions/8.0.1/start/java.mdx
index f7fb9b1e..25baeaf3 100644
--- a/versions/8.0.1/start/java.mdx
+++ b/versions/8.0.1/start/java.mdx
@@ -241,8 +241,7 @@ recompiles that file.
 Looking at the dependency graph, you can see that `ProjectRunner` depends on the
 same inputs as it did before, but the structure of the build is different:
 
-![Dependency graph of the target 'ProjectRunner' after adding a dependency](
-/docs/images/tutorial_java_02.svg)
+![Dependency graph of the target 'ProjectRunner' after adding a dependency](/versions/8.0.1/docs/images/tutorial_java_02.svg)
 
 You've now built the project with two targets. The `ProjectRunner` target builds
 one source files and depends on one other target (`:greeter`), which builds
@@ -426,7 +425,7 @@ For more details, see:
 *  The [C++ build tutorial](/versions/8.0.1/start/cpp) to get started with building
    C++ projects with Bazel.
 
-*  The [Android application tutorial](/versions/8.0.1/start/android-app ) and
+*  The [Android application tutorial](/versions/8.0.1/start/android-app) and
    [iOS application tutorial](/versions/8.0.1/start/ios-app)) to get started with
    building mobile applications for Android and iOS with Bazel.
 
diff --git a/versions/8.0.1/tutorials/ccp-toolchain-config.mdx b/versions/8.0.1/tutorials/ccp-toolchain-config.mdx
index af41a10e..da192870 100644
--- a/versions/8.0.1/tutorials/ccp-toolchain-config.mdx
+++ b/versions/8.0.1/tutorials/ccp-toolchain-config.mdx
@@ -29,8 +29,7 @@ uses `clang version 16`, which you can install on your system.
 
 Set up your build environment as follows:
 
-1.  If you have not already done so, [download and install Bazel
-    7.0.2](https://bazel.build/install) or later.
+1.  If you have not already done so, [download and install Bazel 7.0.2](https://bazel.build/versions/8.0.1/install) or later.
 
 2.  Add an empty `MODULE.bazel` file at the root folder.
 
@@ -450,8 +449,7 @@ The key takeaways are:
 
 -   You need to specify a matching `platforms` flag in the command line for
     Bazel to resolve to the toolchain for the same constraint values on the
-    platform. The documentation holds more [information about language specific
-    configuration flags](/versions/8.0.1/concepts/platforms).
+    platform. The documentation holds more [information about language specific configuration flags](/versions/8.0.1/concepts/platforms).
 -   You have to let the toolchain know where the tools live. In this tutorial
     there is a simplified version where you access the tools from the system. If
     you are interested in a more self-contained approach, you can read about
@@ -464,5 +462,4 @@ The key takeaways are:
 
 ## Further reading {#further-reading}
 
-For more details, see [C++ toolchain
-configuration](/versions/8.0.1/docs/cc-toolchain-config-reference)
\ No newline at end of file
+For more details, see [C++ toolchain configuration](/versions/8.0.1/docs/cc-toolchain-config-reference)
\ No newline at end of file
diff --git a/versions/8.1.1/about/roadmap.mdx b/versions/8.1.1/about/roadmap.mdx
index d450c534..7c97c4e7 100644
--- a/versions/8.1.1/about/roadmap.mdx
+++ b/versions/8.1.1/about/roadmap.mdx
@@ -13,8 +13,7 @@ projects.
 
 ## Bazel 8.0 Release
 
-We plan to bring Bazel 8.0 [long term support
-(LTS)](https://bazel.build/release/versioning) to you in late 2024.
+We plan to bring Bazel 8.0 [long term support (LTS)](https://bazel.build/versions/8.1.1/release/versioning) to you in late 2024.
 The following features are planned to be implemented.
 
 ### Bzlmod: external dependency management system
@@ -29,8 +28,7 @@ support will be removed. Starting with Bazel 7.1, you can set
 `--noenable_workspace` to opt into the new behavior.
 
 Bazel 8.0 will contain a number of enhancements to
-[Bazel's external dependency management]
-(https://docs.google.com/document/d/1moQfNcEIttsk6vYanNKIy3ZuK53hQUFq1b1r0rmsYVg/edit#heading=h.lgyp7ubwxmjc)
+[Bazel's external dependency management](https://docs.google.com/document/d/1moQfNcEIttsk6vYanNKIy3ZuK53hQUFq1b1r0rmsYVg/edit#heading=h.lgyp7ubwxmjc)
 functionality, including:
 
 *   The new flag `--enable_workspace` can be set to `false` to completely
diff --git a/versions/8.1.1/basics/dependencies.mdx b/versions/8.1.1/basics/dependencies.mdx
index f8732fd3..58b13cd7 100644
--- a/versions/8.1.1/basics/dependencies.mdx
+++ b/versions/8.1.1/basics/dependencies.mdx
@@ -65,8 +65,7 @@ targets, we’ve made some strides in mitigating the downside by investing in
 tooling to automatically manage `BUILD` files to avoid burdening developers.
 
 Some of these tools, such as `buildifier` and `buildozer`, are available with
-Bazel in the [`buildtools`
-directory](https://github.com/bazelbuild/buildtools).
+Bazel in the [`buildtools` directory](https://github.com/bazelbuild/buildtools).
 
 ## Minimizing Module Visibility
 
@@ -106,8 +105,7 @@ transitive dependencies (Figure 1). Suppose target A depends on target B, which
 depends on a common library target C. Should target A be able to use classes
 defined in target C?
 
-[![Transitive
-dependencies](/versions/8.1.1/images/transitive-dependencies.png)](/versions/8.1.1/images/transitive-dependencies.png)
+[![Transitive dependencies](/versions/8.1.1/images/transitive-dependencies.png)](/versions/8.1.1/images/transitive-dependencies.png)
 
 **Figure 1**. Transitive dependencies
 
@@ -141,9 +139,7 @@ dependencies and adding them to a `BUILD` files without any developer
 intervention. But even without such tools, we’ve found the trade-off to be well
 worth it as the codebase scales: explicitly adding a dependency to `BUILD` file
 is a one-time cost, but dealing with implicit transitive dependencies can cause
-ongoing problems as long as the build target exists. Bazel [enforces strict
-transitive
-dependencies](https://blog.bazel.build/2017/06/28/sjd-unused_deps.html)
+ongoing problems as long as the build target exists. Bazel [enforces strict transitive dependencies](https://blog.bazel.build/2017/06/28/sjd-unused_deps.html)
 on Java code by default.
 
 ### External dependencies
@@ -192,8 +188,7 @@ so in theory there’s no reason that different versions of the same external
 dependency couldn’t both be declared in the build system under different names.
 That way, each target could choose which version of the dependency it wanted to
 use. This causes a lot of problems in practice, so Google enforces a strict
-[One-Version
-Rule](https://opensource.google/docs/thirdparty/oneversion/) for
+[One-Version Rule](https://opensource.google/docs/thirdparty/oneversion/) for
 all third-party dependencies in our codebase.
 
 The biggest problem with allowing multiple versions is the diamond dependency
@@ -232,8 +227,7 @@ Bazel did not use to automatically download transitive dependencies. It used to
 employ a `WORKSPACE` file that required all transitive dependencies to be
 listed, which led to a lot of pain when managing external dependencies. Bazel
 has since added support for automatic transitive external dependency management
-in the form of the `MODULE.bazel` file. See [external dependency
-overview](/versions/8.1.1/external/overview) for more details.
+in the form of the `MODULE.bazel` file. See [external dependency overview](/versions/8.1.1/external/overview) for more details.
 
 Yet again, the choice here is one between convenience and scalability. Small
 projects might prefer not having to worry about managing transitive dependencies
diff --git a/versions/8.1.1/community/images/Bitrise.png b/versions/8.1.1/community/images/Bitrise.png
new file mode 100644
index 00000000..07f85f1e
Binary files /dev/null and b/versions/8.1.1/community/images/Bitrise.png differ
diff --git a/versions/8.1.1/community/images/Gradle.png b/versions/8.1.1/community/images/Gradle.png
new file mode 100644
index 00000000..1e5f5eb0
Binary files /dev/null and b/versions/8.1.1/community/images/Gradle.png differ
diff --git a/versions/8.1.1/community/images/Linkedin-Logo.png b/versions/8.1.1/community/images/Linkedin-Logo.png
new file mode 100644
index 00000000..9dd8715c
Binary files /dev/null and b/versions/8.1.1/community/images/Linkedin-Logo.png differ
diff --git a/versions/8.1.1/community/images/Lucid_Software-logo.svg b/versions/8.1.1/community/images/Lucid_Software-logo.svg
new file mode 100644
index 00000000..6c8591e0
--- /dev/null
+++ b/versions/8.1.1/community/images/Lucid_Software-logo.svg
@@ -0,0 +1,16 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/versions/8.1.1/community/images/acqio_logo.svg b/versions/8.1.1/community/images/acqio_logo.svg
new file mode 100644
index 00000000..8fa11bcd
--- /dev/null
+++ b/versions/8.1.1/community/images/acqio_logo.svg
@@ -0,0 +1,60 @@
+
+
+
+
+
+	
+		
+			
+				
+					
+					
+					
+					
+					
+				
+				
+					
+						
+							
+								
+							
+						
+					
+				
+				
+					
+						
+							
+								
+							
+						
+					
+				
+			
+		
+	
+
+
diff --git a/versions/8.1.1/community/images/aspect-logo-2.png b/versions/8.1.1/community/images/aspect-logo-2.png
new file mode 100644
index 00000000..dfebc4cb
Binary files /dev/null and b/versions/8.1.1/community/images/aspect-logo-2.png differ
diff --git a/versions/8.1.1/community/images/bitrise-logo.png b/versions/8.1.1/community/images/bitrise-logo.png
new file mode 100644
index 00000000..27037ce6
Binary files /dev/null and b/versions/8.1.1/community/images/bitrise-logo.png differ
diff --git a/versions/8.1.1/community/images/buildbuddy-logo.svg b/versions/8.1.1/community/images/buildbuddy-logo.svg
new file mode 100644
index 00000000..bdb72dc6
--- /dev/null
+++ b/versions/8.1.1/community/images/buildbuddy-logo.svg
@@ -0,0 +1,11 @@
+
+
+
+
+
+
+
+
+
+
+
diff --git a/versions/8.1.1/community/images/buildkite.svg b/versions/8.1.1/community/images/buildkite.svg
new file mode 100644
index 00000000..209a4ab1
--- /dev/null
+++ b/versions/8.1.1/community/images/buildkite.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/8.1.1/community/images/codethink-logo.svg b/versions/8.1.1/community/images/codethink-logo.svg
new file mode 100644
index 00000000..406005d8
--- /dev/null
+++ b/versions/8.1.1/community/images/codethink-logo.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/8.1.1/community/images/develocity.png b/versions/8.1.1/community/images/develocity.png
new file mode 100644
index 00000000..eb3eb65a
Binary files /dev/null and b/versions/8.1.1/community/images/develocity.png differ
diff --git a/versions/8.1.1/community/images/dropbox.png b/versions/8.1.1/community/images/dropbox.png
new file mode 100644
index 00000000..125476a6
Binary files /dev/null and b/versions/8.1.1/community/images/dropbox.png differ
diff --git a/versions/8.1.1/community/images/engflow-logo.svg b/versions/8.1.1/community/images/engflow-logo.svg
new file mode 100644
index 00000000..e5f0c343
--- /dev/null
+++ b/versions/8.1.1/community/images/engflow-logo.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/8.1.1/community/images/epam-logo.png b/versions/8.1.1/community/images/epam-logo.png
new file mode 100644
index 00000000..e6a5674c
Binary files /dev/null and b/versions/8.1.1/community/images/epam-logo.png differ
diff --git a/versions/8.1.1/community/images/flare-logo.png b/versions/8.1.1/community/images/flare-logo.png
new file mode 100644
index 00000000..84cb0e5b
Binary files /dev/null and b/versions/8.1.1/community/images/flare-logo.png differ
diff --git a/versions/8.1.1/community/images/hermetiq-logo.png b/versions/8.1.1/community/images/hermetiq-logo.png
new file mode 100644
index 00000000..90765d96
Binary files /dev/null and b/versions/8.1.1/community/images/hermetiq-logo.png differ
diff --git a/versions/8.1.1/community/images/jetbrains.svg b/versions/8.1.1/community/images/jetbrains.svg
new file mode 100644
index 00000000..cb3a2a0e
--- /dev/null
+++ b/versions/8.1.1/community/images/jetbrains.svg
@@ -0,0 +1,13 @@
+
+  
+    
+      
+      
+      
+    
+  
+  
+  
+  
+  
+
diff --git a/versions/8.1.1/community/images/liulishuo.png b/versions/8.1.1/community/images/liulishuo.png
new file mode 100644
index 00000000..a6758e5c
Binary files /dev/null and b/versions/8.1.1/community/images/liulishuo.png differ
diff --git a/versions/8.1.1/community/images/nativelink.svg b/versions/8.1.1/community/images/nativelink.svg
new file mode 100644
index 00000000..148fcdce
--- /dev/null
+++ b/versions/8.1.1/community/images/nativelink.svg
@@ -0,0 +1,1123 @@
+
+
+  
+    
+    
+      
+      
+    
+    
+      
+      
+    
+    
+    
+      
+      
+    
+    
+      
+      
+      
+      
+      
+      
+      
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+      
+      
+    
+    
+    
+    
+      
+      
+    
+    
+    
+    
+      
+      
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+      
+      
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+      
+      
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+      
+      
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+      
+      
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+      
+      
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+      
+      
+    
+  
+  
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+  
+  
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+  
+
diff --git a/versions/8.1.1/community/images/oasis-logo.png b/versions/8.1.1/community/images/oasis-logo.png
new file mode 100644
index 00000000..846a9cd5
Binary files /dev/null and b/versions/8.1.1/community/images/oasis-logo.png differ
diff --git a/versions/8.1.1/community/images/sumglobal-logo.png b/versions/8.1.1/community/images/sumglobal-logo.png
new file mode 100644
index 00000000..6736328d
Binary files /dev/null and b/versions/8.1.1/community/images/sumglobal-logo.png differ
diff --git a/versions/8.1.1/community/images/trunk-logo-dark.svg b/versions/8.1.1/community/images/trunk-logo-dark.svg
new file mode 100644
index 00000000..f25940af
--- /dev/null
+++ b/versions/8.1.1/community/images/trunk-logo-dark.svg
@@ -0,0 +1,22 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/versions/8.1.1/community/images/tweag-logo.png b/versions/8.1.1/community/images/tweag-logo.png
new file mode 100644
index 00000000..20210ed7
Binary files /dev/null and b/versions/8.1.1/community/images/tweag-logo.png differ
diff --git a/versions/8.1.1/community/images/typedb.png b/versions/8.1.1/community/images/typedb.png
new file mode 100644
index 00000000..48ce1056
Binary files /dev/null and b/versions/8.1.1/community/images/typedb.png differ
diff --git a/versions/8.1.1/community/images/virtuslab.svg b/versions/8.1.1/community/images/virtuslab.svg
new file mode 100644
index 00000000..6fba0316
--- /dev/null
+++ b/versions/8.1.1/community/images/virtuslab.svg
@@ -0,0 +1,20 @@
+
+
+  
+    
+  
+  
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+  
+
diff --git a/versions/8.1.1/community/roadmaps-configurability.mdx b/versions/8.1.1/community/roadmaps-configurability.mdx
index 3741bee7..07138794 100644
--- a/versions/8.1.1/community/roadmaps-configurability.mdx
+++ b/versions/8.1.1/community/roadmaps-configurability.mdx
@@ -26,8 +26,7 @@ title: 'Bazel Configurability 2021 Roadmap'
 * Builds scale well, particularly w.r.t graph size and action caching.
 
 We also support
-[`cquery`](https://bazel.build/versions/8.1.1/query/cquery), [`Starlark
-configuration`](https://bazel.build/extending/config),
+[`cquery`](https://bazel.build/versions/8.1.1/query/cquery), [`Starlark configuration`](https://bazel.build/versions/8.1.1/extending/config),
 and
 [`select()`](https://bazel.build/versions/8.1.1/docs/configurable-attributes).
 
@@ -41,15 +40,13 @@ interest of accurate expectations.
 ### Platforms
 
 

-Q3 2021**Android rules use the new [platforms
-API](https://bazel.build/concepts/platforms)**
+Q3 2021**Android rules use the new [platforms API](https://bazel.build/versions/8.1.1/concepts/platforms)**
 IN PROGRESS ([#11749](https://github.com/bazelbuild/bazel/issues/11749))
 
 * This is our main priority for the beginning of 2021.
 
 

-Q3 2021**Builds support [multiple execution
-platforms](https://docs.google.com/document/d/1U9HzdDmtRnm244CaRM6JV-q2408mbNODAMewcGjnnbM/)**
+Q3 2021**Builds support [multiple execution platforms](https://docs.google.com/document/d/1U9HzdDmtRnm244CaRM6JV-q2408mbNODAMewcGjnnbM/)**
 IN PROGRESS ([#11748](https://github.com/bazelbuild/bazel/issues/11748))
 
 

diff --git a/versions/8.1.1/community/sig.mdx b/versions/8.1.1/community/sig.mdx
index 2d2f6177..af2b7696 100644
--- a/versions/8.1.1/community/sig.mdx
+++ b/versions/8.1.1/community/sig.mdx
@@ -3,8 +3,7 @@ title: 'Bazel Special Interest Groups'
 ---
 
 Bazel hosts Special Interest Groups (SIGs) to focus collaboration on particular
-areas and to support communication and coordination between [Bazel owners,
-maintainers, and contributors](/versions/8.1.1/contribute/policy). This policy
+areas and to support communication and coordination between [Bazel owners, maintainers, and contributors](/versions/8.1.1/contribute/policy). This policy
 applies to [`bazelbuild`](http://github.com/bazelbuild).
 
 SIGs do their work in public. The ideal scope for a SIG covers a well-defined
diff --git a/versions/8.1.1/community/users.mdx b/versions/8.1.1/community/users.mdx
index 09f92077..1058cb32 100644
--- a/versions/8.1.1/community/users.mdx
+++ b/versions/8.1.1/community/users.mdx
@@ -304,11 +304,9 @@ safety systems_.
 Pigweed is an open-source solution for sustained, robust, and rapid embedded
 product development for large teams. Pigweed has shipped in millions of
 devices, including Google's suite of Pixel devices, Nest thermostats,
-[satellites](https://www.spinlaunch.com/), and [autonomous aerial
-drones](https://www.flyzipline.com/).
+[satellites](https://www.spinlaunch.com/), and [autonomous aerial drones](https://www.flyzipline.com/).
 
-Pigweed [uses Bazel as its primary build
-system](https://pigweed.dev/seed/0111-build-systems.html). The [Bazel for
+Pigweed [uses Bazel as its primary build system](https://pigweed.dev/seed/0111-build-systems.html). The [Bazel for
 Embedded][pw-bazel-great] blog post discusses why we think it's a great build
 system for embedded projects!
 
diff --git a/versions/8.1.1/concepts/build-ref.mdx b/versions/8.1.1/concepts/build-ref.mdx
index 0625e6f9..a439f196 100644
--- a/versions/8.1.1/concepts/build-ref.mdx
+++ b/versions/8.1.1/concepts/build-ref.mdx
@@ -17,8 +17,7 @@ its root; such a boundary marker file could be `MODULE.bazel`, `REPO.bazel`, or
 in legacy contexts, `WORKSPACE` or `WORKSPACE.bazel`.
 
 The repo in which the current Bazel command is being run is called the _main
-repo_. Other, (external) repos are defined by _repo rules_; see [external
-dependencies overview](/versions/8.1.1/external/overview) for more information.
+repo_. Other, (external) repos are defined by _repo rules_; see [external dependencies overview](/versions/8.1.1/external/overview) for more information.
 
 ## Workspace {#workspace}
 
@@ -95,5 +94,4 @@ have three properties: the list of packages they contain, their name, and other
 package groups they include. The only allowed ways to refer to them are from the
 `visibility` attribute of rules or from the `default_visibility` attribute of
 the `package` function; they do not generate or consume files. For more
-information, refer to the [`package_group`
-documentation](/versions/8.1.1/reference/be/functions#package_group).
+information, refer to the [`package_group` documentation](/versions/8.1.1/reference/be/functions#package_group).
diff --git a/versions/8.1.1/concepts/labels.mdx b/versions/8.1.1/concepts/labels.mdx
index 066aa383..fdb18ced 100644
--- a/versions/8.1.1/concepts/labels.mdx
+++ b/versions/8.1.1/concepts/labels.mdx
@@ -10,8 +10,7 @@ form looks like:
 ```
 
 The first part of the label is the repository name, `@@myrepo`. The double-`@`
-syntax signifies that this is a [*canonical* repo
-name](/versions/8.1.1/external/overview#canonical-repo-name), which is unique within
+syntax signifies that this is a [*canonical* repo name](/versions/8.1.1/external/overview#canonical-repo-name), which is unique within
 the workspace. Labels with canonical repo names unambiguously identify a target
 no matter which context they appear in.
 
diff --git a/versions/8.1.1/concepts/platforms.mdx b/versions/8.1.1/concepts/platforms.mdx
index 2f5df03b..de76dc02 100644
--- a/versions/8.1.1/concepts/platforms.mdx
+++ b/versions/8.1.1/concepts/platforms.mdx
@@ -77,8 +77,7 @@ To test your Android project with platforms, see
 for support.
 
 You can still use platform APIs with Apple builds (for example, when building
-with a mixture of Apple rules and pure C++) with [platform
-mappings](#platform-mappings).
+with a mixture of Apple rules and pure C++) with [platform mappings](#platform-mappings).
 
 ### Other languages {#other-languages}
 
@@ -241,8 +240,7 @@ sets `--cpu`, `--crossstool_top`, or other legacy flags, rules that read
 
 When migrating your project to platforms, you must either convert changes like
 `return { "//command_line_option:cpu": "arm" }` to `return {
-"//command_line_option:platforms": "//:my_arm_platform" }` or use [platform
-mappings](#platform-mappings) to support both styles during migration.
+"//command_line_option:platforms": "//:my_arm_platform" }` or use [platform mappings](#platform-mappings) to support both styles during migration.
 window.
 
 ## Migrating your rule set {#migrating-your-rule-set}
@@ -361,10 +359,8 @@ attributes declare a language's tools (like `compiler =
 this information to rules that need to build with these tools.
 
 Toolchains declare the `constraint_value`s of machines they can
-[target][target_compatible_with Attribute]
-(`target_compatible_with = ["@platforms//os:linux"]`) and machines their tools can
-[run on][exec_compatible_with Attribute]
-(`exec_compatible_with = ["@platforms//os:mac"]`).
+[target][target_compatible_with Attribute](`target_compatible_with = ["@platforms//os:linux"]`) and machines their tools can
+[run on][exec_compatible_with Attribute](`exec_compatible_with = ["@platforms//os:mac"]`).
 
 When building `$ bazel build //:myproject --platforms=//:myplatform`, Bazel
 automatically selects a toolchain that can run on the build machine and
diff --git a/versions/8.1.1/configure/attributes.mdx b/versions/8.1.1/configure/attributes.mdx
index efb5e4a7..9d99de1c 100644
--- a/versions/8.1.1/configure/attributes.mdx
+++ b/versions/8.1.1/configure/attributes.mdx
@@ -2,8 +2,7 @@
 title: 'Configurable Build Attributes'
 ---
 
-**_Configurable attributes_**, commonly known as [`select()`](
-/reference/be/functions#select), is a Bazel feature that lets users toggle the values
+**_Configurable attributes_**, commonly known as [`select()`](/versions/8.1.1/reference/be/functions#select), is a Bazel feature that lets users toggle the values
 of build rule attributes at the command line.
 
 This can be used, for example, for a multiplatform library that automatically
@@ -407,8 +406,7 @@ sh_library(
 )
 ```
 
-If you need a `select` to match when multiple conditions match, consider [AND
-chaining](#and-chaining).
+If you need a `select` to match when multiple conditions match, consider [AND chaining](#and-chaining).
 
 ## OR chaining {#or-chaining}
 
diff --git a/versions/8.1.1/configure/integrate-cpp.mdx b/versions/8.1.1/configure/integrate-cpp.mdx
index 750595c2..e657d9c5 100644
--- a/versions/8.1.1/configure/integrate-cpp.mdx
+++ b/versions/8.1.1/configure/integrate-cpp.mdx
@@ -33,8 +33,7 @@ This is because when writing our own actions, they must behave
 consistently with the C++ toolchain - for example, passing C++ command line
 flags to a tool that invokes the C++ compiler behind the scenes.
 
-C++ rules use a special way of constructing command lines based on [feature
-configuration](/versions/8.1.1/docs/cc-toolchain-config-reference). To construct a command line,
+C++ rules use a special way of constructing command lines based on [feature configuration](/versions/8.1.1/docs/cc-toolchain-config-reference). To construct a command line,
 you need the following:
 
 * `features` and `action_configs` - these come from the `CcToolchainConfigInfo`
diff --git a/versions/8.1.1/configure/windows.mdx b/versions/8.1.1/configure/windows.mdx
index e5b752c9..9e2abbda 100644
--- a/versions/8.1.1/configure/windows.mdx
+++ b/versions/8.1.1/configure/windows.mdx
@@ -166,8 +166,7 @@ To build C++ targets with MSVC, you need:
         set BAZEL_VC=C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC
         ```
 
-*   The [Windows
-    SDK](https://developer.microsoft.com/en-us/windows/downloads/windows-10-sdk).
+*   The [Windows SDK](https://developer.microsoft.com/en-us/windows/downloads/windows-10-sdk).
 
     The Windows SDK contains header files and libraries you need when building
     Windows applications, including Bazel itself. By default, the latest Windows SDK installed will
@@ -186,8 +185,7 @@ To build C++ targets with MSVC, you need:
 
 If everything is set up, you can build a C++ target now!
 
-Try building a target from one of our [sample
-projects](https://github.com/bazelbuild/bazel/tree/master/examples):
+Try building a target from one of our [sample projects](https://github.com/bazelbuild/bazel/tree/master/examples):
 
 
 
 
-To build and use Dynamically Linked Libraries (DLL files), see [this
-example](https://github.com/bazelbuild/bazel/tree/master/examples/windows/dll).
+To build and use Dynamically Linked Libraries (DLL files), see [this example](https://github.com/bazelbuild/bazel/tree/master/examples/windows/dll).
 
 **Command Line Length Limit**: To prevent the
 [Windows command line length limit issue](https://github.com/bazelbuild/bazel/issues/5163),
@@ -292,8 +289,7 @@ On Windows, Bazel builds two output files for `java_binary` rules:
 *   a `.jar` file
 *   a `.exe` file that can set up the environment for the JVM and run the binary
 
-Try building a target from one of our [sample
-projects](https://github.com/bazelbuild/bazel/tree/master/examples):
+Try building a target from one of our [sample projects](https://github.com/bazelbuild/bazel/tree/master/examples):
 
 
   
   
 
 If you are interested in details about how Bazel builds Python targets on
-Windows, check out this [design
-doc](https://github.com/bazelbuild/bazel-website/blob/master/designs/_posts/2016-09-05-build-python-on-windows.md).
+Windows, check out this [design doc](https://github.com/bazelbuild/bazel-website/blob/master/designs/_posts/2016-09-05-build-python-on-windows.md).
diff --git a/versions/8.1.1/contribute/breaking-changes.mdx b/versions/8.1.1/contribute/breaking-changes.mdx
index a05da3c9..bcd3811c 100644
--- a/versions/8.1.1/contribute/breaking-changes.mdx
+++ b/versions/8.1.1/contribute/breaking-changes.mdx
@@ -67,7 +67,7 @@ should contain the URL of the GitHub issue. As the flag name starts with
 ```
 
 In the commit description, add a brief summary of the flag.
-Also add [`RELNOTES:`](release-notes.md) in the following form:
+Also add [`RELNOTES:`](/versions/8.1.1/contribute/release-notes) in the following form:
 `RELNOTES: --incompatible_name_of_flag has been added. See #xyz for details`
 
 The commit should also update the relevant documentation, so that there is no
diff --git a/versions/8.1.1/contribute/codebase.mdx b/versions/8.1.1/contribute/codebase.mdx
index 4ad7007f..6fbd3522 100644
--- a/versions/8.1.1/contribute/codebase.mdx
+++ b/versions/8.1.1/contribute/codebase.mdx
@@ -227,8 +227,7 @@ repository", the others are called "external repositories".
 A repository is marked by a repo boundary file (`MODULE.bazel`, `REPO.bazel`, or
 in legacy contexts, `WORKSPACE` or `WORKSPACE.bazel`) in its root directory. The
 main repo is the source tree where you're invoking Bazel from. External repos
-are defined in various ways; see [external dependencies
-overview](/versions/8.1.1/external/overview) for more information.
+are defined in various ways; see [external dependencies overview](/versions/8.1.1/external/overview) for more information.
 
 Code of external repositories is symlinked or downloaded under
 `$OUTPUT_BASE/external`.
diff --git a/versions/8.1.1/contribute/design-documents.mdx b/versions/8.1.1/contribute/design-documents.mdx
index b28cef5f..c7c0dae8 100644
--- a/versions/8.1.1/contribute/design-documents.mdx
+++ b/versions/8.1.1/contribute/design-documents.mdx
@@ -25,7 +25,7 @@ Here are some examples of significant changes:
 When you write a design document, you can coordinate with other Bazel developers
 and seek guidance from Bazel's core team. For example, when a proposal adds,
 removes, or modifies any function or object available in BUILD, MODULE.bazel, or
-bzl files, add the [Starlark team](maintainers-guide.md) as reviewers.
+bzl files, add the [Starlark team](/versions/8.1.1/contribute/maintainers-guide) as reviewers.
 Design documents are reviewed before submission because:
 
 *   Bazel is a very complex system; seemingly innocuous local changes can have
@@ -137,8 +137,7 @@ A lead reviewer should be a domain expert who is:
 *   Objective and capable of providing constructive feedback
 *   Available for the entire review period to lead the process
 
-Consider checking the contacts for various [team
-labels](/versions/8.1.1/contribute/maintainers-guide#team-labels).
+Consider checking the contacts for various [team labels](/versions/8.1.1/contribute/maintainers-guide#team-labels).
 
 ## Markdown vs Google Docs {#markdown-versus-gdocs}
 
@@ -168,12 +167,10 @@ Markdown for posterity.
 
 ### Using Google Docs {#gdocs}
 
-For consistency, use the [Bazel design doc template](
-https://docs.google.com/document/d/1cE5zrjrR40RXNg64XtRFewSv6FrLV6slGkkqxBumS1w/edit).
+For consistency, use the [Bazel design doc template](https://docs.google.com/document/d/1cE5zrjrR40RXNg64XtRFewSv6FrLV6slGkkqxBumS1w/edit).
 It includes the necessary header and creates visual
 consistency with other Bazel related documents. To do that, click on **File** >
-**Make a copy** or click this link to [make a copy of the design doc
-template](https://docs.google.com/document/d/1cE5zrjrR40RXNg64XtRFewSv6FrLV6slGkkqxBumS1w/copy).
+**Make a copy** or click this link to [make a copy of the design doc template](https://docs.google.com/document/d/1cE5zrjrR40RXNg64XtRFewSv6FrLV6slGkkqxBumS1w/copy).
 
 To make your document readable to the world, click on
 **Share** > **Advanced** > **Change…**, and
diff --git a/versions/8.1.1/contribute/images/structured-concurrency-3d.svg b/versions/8.1.1/contribute/images/structured-concurrency-3d.svg
new file mode 100644
index 00000000..accbb42a
--- /dev/null
+++ b/versions/8.1.1/contribute/images/structured-concurrency-3d.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/8.1.1/contribute/images/structured-concurrency.svg b/versions/8.1.1/contribute/images/structured-concurrency.svg
new file mode 100644
index 00000000..0258d9a9
--- /dev/null
+++ b/versions/8.1.1/contribute/images/structured-concurrency.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/8.1.1/contribute/images/suspend-resume.svg b/versions/8.1.1/contribute/images/suspend-resume.svg
new file mode 100644
index 00000000..7de1218f
--- /dev/null
+++ b/versions/8.1.1/contribute/images/suspend-resume.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/8.1.1/contribute/images/unstructured-concurrency.svg b/versions/8.1.1/contribute/images/unstructured-concurrency.svg
new file mode 100644
index 00000000..0951639a
--- /dev/null
+++ b/versions/8.1.1/contribute/images/unstructured-concurrency.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/8.1.1/contribute/index.mdx b/versions/8.1.1/contribute/index.mdx
index f8c284ef..3bc09a11 100644
--- a/versions/8.1.1/contribute/index.mdx
+++ b/versions/8.1.1/contribute/index.mdx
@@ -10,8 +10,7 @@ As you use Bazel, you may find things that can be improved.
 You can help by [reporting issues](http://github.com/bazelbuild/bazel/issues)
 when:
 
-   - Bazel crashes or you encounter a bug that can [only be resolved using `bazel
-     clean`](/versions/8.1.1/run/build#correct-incremental-rebuilds).
+   - Bazel crashes or you encounter a bug that can [only be resolved using `bazel clean`](/versions/8.1.1/run/build#correct-incremental-rebuilds).
    - The documentation is incomplete or unclear. You can also report issues
      from the page you are viewing by using the "Create issue"
      link at the top right corner of the page.
@@ -21,11 +20,9 @@ when:
 
 You can engage with the Bazel community by:
 
-   - Answering questions [on Stack Overflow](
-     https://stackoverflow.com/questions/tagged/bazel).
+   - Answering questions [on Stack Overflow](https://stackoverflow.com/questions/tagged/bazel).
    - Helping other users [on Slack](https://slack.bazel.build).
-   - Improving documentation or [contributing examples](
-     https://github.com/bazelbuild/examples).
+   - Improving documentation or [contributing examples](https://github.com/bazelbuild/examples).
    - Sharing your experience or your tips, for example, on a blog or social media.
 
 ## Contribute code {#contribute-code}
@@ -40,8 +37,7 @@ You can contribute to the Bazel ecosystem by:
    - Contributing to Bazel-related tools, for example, migration tools.
    - Improving Bazel integration with other IDEs and tools.
 
-Before making a change, [create a GitHub
-issue](http://github.com/bazelbuild/bazel/issues)
+Before making a change, [create a GitHub issue](http://github.com/bazelbuild/bazel/issues)
 or email [bazel-discuss@](mailto:bazel-discuss@googlegroups.com).
 
 The most helpful contributions fix bugs or add features (as opposed
diff --git a/versions/8.1.1/contribute/maintainers-guide.mdx b/versions/8.1.1/contribute/maintainers-guide.mdx
index 185df6db..065b7b7d 100644
--- a/versions/8.1.1/contribute/maintainers-guide.mdx
+++ b/versions/8.1.1/contribute/maintainers-guide.mdx
@@ -4,8 +4,7 @@ title: 'Guide for Bazel Maintainers'
 
 This is a guide for the maintainers of the Bazel open source project.
 
-If you are looking to contribute to Bazel, please read [Contributing to
-Bazel](/versions/8.1.1/contribute) instead.
+If you are looking to contribute to Bazel, please read [Contributing to Bazel](/versions/8.1.1/contribute) instead.
 
 The objectives of this page are to:
 
@@ -37,8 +36,7 @@ repository.
 
 1. A user creates an issue by choosing one of the
 [issue templates](https://github.com/bazelbuild/bazel/issues/new/choose)
-   and it enters the pool of [unreviewed open
-   issues](https://github.com/bazelbuild/bazel/issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aopen+-label%3Auntriaged+-label%3Ap2+-label%3Ap1+-label%3Ap3+-label%3Ap4+-label%3Ateam-Starlark+-label%3Ateam-Rules-CPP+-label%3Ateam-Rules-Java+-label%3Ateam-XProduct+-label%3Ateam-Android+-label%3Ateam-Apple+-label%3Ateam-Configurability++-label%3Ateam-Performance+-label%3Ateam-Rules-Server+-label%3Ateam-Core+-label%3Ateam-Rules-Python+-label%3Ateam-Remote-Exec+-label%3Ateam-Local-Exec+-label%3Ateam-Bazel).
+   and it enters the pool of [unreviewed open issues](https://github.com/bazelbuild/bazel/issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aopen+-label%3Auntriaged+-label%3Ap2+-label%3Ap1+-label%3Ap3+-label%3Ap4+-label%3Ateam-Starlark+-label%3Ateam-Rules-CPP+-label%3Ateam-Rules-Java+-label%3Ateam-XProduct+-label%3Ateam-Android+-label%3Ateam-Apple+-label%3Ateam-Configurability++-label%3Ateam-Performance+-label%3Ateam-Rules-Server+-label%3Ateam-Core+-label%3Ateam-Rules-Python+-label%3Ateam-Remote-Exec+-label%3Ateam-Local-Exec+-label%3Ateam-Bazel).
 1. A member on the Developer Experience (DevEx) subteam rotation reviews the
    issue.
    1. If the issue is **not a bug** or a **feature request**, the DevEx member
@@ -58,21 +56,18 @@ repository.
 1. After reviewing the issue, the DevEx member decides if the issue requires
    immediate attention. If it does, they will assign the **P0**
    [priority](#priority) label and an owner from the list of team leads.
-1. The DevEx member assigns the `untriaged` label and exactly one [team
-   label](#team-labels) for routing.
+1. The DevEx member assigns the `untriaged` label and exactly one [team label](#team-labels) for routing.
 1. The DevEx member also assigns exactly one `type:` label, such as `type: bug`
    or `type: feature request`, according to the type of the issue.
 1. For platform-specific issues, the DevEx member assigns one `platform:` label,
    such as `platform:apple` for Mac-specific issues.
 1. If the issue is low priority and can be worked on by a new community
    contributor, the DevEx member assigns the `good first issue` label.
-At this stage, the issue enters the pool of [untriaged open
-issues](https://github.com/bazelbuild/bazel/issues?q=is%3Aissue+is%3Aopen+label%3Auntriaged).
+At this stage, the issue enters the pool of [untriaged open issues](https://github.com/bazelbuild/bazel/issues?q=is%3Aissue+is%3Aopen+label%3Auntriaged).
 
 Each Bazel subteam will triage all issues under labels they own, preferably on a
 weekly basis. The subteam will review and evaluate the issue and provide a
-resolution, if possible. If you are an owner of a team label, see [this section
-](#label-own) for more information.
+resolution, if possible. If you are an owner of a team label, see [this section](#label-own) for more information.
 
 When an issue is resolved, it can be closed.
 
@@ -111,8 +106,7 @@ preferably on a weekly basis.
      issue is either P0 or P1 we assume that is actively worked on.
 1. Remove the `untriaged` label.
 
-Note that you need to be in the [bazelbuild
-organization](https://github.com/bazelbuild) to be able to add or remove labels.
+Note that you need to be in the [bazelbuild organization](https://github.com/bazelbuild) to be able to add or remove labels.
 
 ### Pull Requests {#pull-requests}
 
@@ -138,8 +132,7 @@ issues.
   unusable, or a downed service that severely impacts development of the Bazel
   project. This includes regressions introduced in a new release that blocks a
   significant number of users, or an incompatible breaking change that was not
-  compliant to the [Breaking
-  Change](https://docs.google.com/document/d/1q5GGRxKrF_mnwtaPKI487P8OdDRh2nN7jX6U-FXnHL0/edit?pli=1#heading=h.ceof6vpkb3ik)
+  compliant to the [Breaking Change](https://docs.google.com/document/d/1q5GGRxKrF_mnwtaPKI487P8OdDRh2nN7jX6U-FXnHL0/edit?pli=1#heading=h.ceof6vpkb3ik)
   policy. No practical workaround exists.
 * [**P1**](https://github.com/bazelbuild/bazel/labels/P1) - Critical defect or
   feature which should be addressed in the next release, or a serious issue that
diff --git a/versions/8.1.1/contribute/naming.mdx b/versions/8.1.1/contribute/naming.mdx
index 05f58bdd..17cb32b7 100644
--- a/versions/8.1.1/contribute/naming.mdx
+++ b/versions/8.1.1/contribute/naming.mdx
@@ -4,8 +4,7 @@ title: 'Naming a Bazel related project'
 
 First, thank you for contributing to the Bazel ecosystem! Please reach out to
 the Bazel community on the
-[bazel-discuss mailing list](https://groups.google.com/forum/#!forum/bazel-discuss
-) to share your project and its suggested name.
+[bazel-discuss mailing list](https://groups.google.com/forum/#!forum/bazel-discuss) to share your project and its suggested name.
 
 If you are building a Bazel related tool or sharing your Skylark rules,
 we recommend following these guidelines for the name of your project:
diff --git a/versions/8.1.1/contribute/patch-acceptance.mdx b/versions/8.1.1/contribute/patch-acceptance.mdx
index c0d30b9e..70e89081 100644
--- a/versions/8.1.1/contribute/patch-acceptance.mdx
+++ b/versions/8.1.1/contribute/patch-acceptance.mdx
@@ -11,29 +11,24 @@ code base.
    need a corresponding issue for tracking.
 1. If you're proposing significant changes, write a
    [design document](/versions/8.1.1/contribute/design-documents).
-1. Ensure you've signed a [Contributor License
-   Agreement](https://cla.developers.google.com).
+1. Ensure you've signed a [Contributor License Agreement](https://cla.developers.google.com).
 1. Prepare a git commit that implements the feature. Don't forget to add tests
    and update the documentation. If your change has user-visible effects, please
    [add release notes](/versions/8.1.1/contribute/release-notes). If it is an incompatible change,
    read the [guide for rolling out breaking changes](/versions/8.1.1/contribute/breaking-changes).
 1. Create a pull request on
    [GitHub](https://github.com/bazelbuild/bazel/pulls). If you're new to GitHub,
-   read [about pull
-   requests](https://help.github.com/articles/about-pull-requests/). Note that
+   read [about pull requests](https://help.github.com/articles/about-pull-requests/). Note that
    we restrict permissions to create branches on the main Bazel repository, so
-   you will need to push your commit to [your own fork of the
-   repository](https://help.github.com/articles/working-with-forks/).
+   you will need to push your commit to [your own fork of the repository](https://help.github.com/articles/working-with-forks/).
 1. A Bazel maintainer should assign you a reviewer within two business days
    (excluding holidays in the USA and Germany). If you aren't assigned a
    reviewer in that time, you can request one by emailing
-   [bazel-discuss@googlegroups.com]
-   (mailto:bazel-discuss@googlegroups.com).
+   [bazel-discuss@googlegroups.com](mailto:bazel-discuss@googlegroups.com).
 1. Work with the reviewer to complete a code review. For each change, create a
    new commit and push it to make changes to your pull request. If the review
    takes too long (for instance, if the reviewer is unresponsive), send an email to
-   [bazel-discuss@googlegroups.com]
-   (mailto:bazel-discuss@googlegroups.com).
+   [bazel-discuss@googlegroups.com](mailto:bazel-discuss@googlegroups.com).
 1. After your review is complete, a Bazel maintainer applies your patch to
    Google's internal version control system.
 
diff --git a/versions/8.1.1/contribute/release-notes.mdx b/versions/8.1.1/contribute/release-notes.mdx
index 023722d5..05588efa 100644
--- a/versions/8.1.1/contribute/release-notes.mdx
+++ b/versions/8.1.1/contribute/release-notes.mdx
@@ -16,8 +16,7 @@ the release announcement.
 * If the change adds / removes / changes Bazel in a user-visible way, then it
   may be advantageous to mention it.
 
-If the change is significant, follow the [design document
-policy](/versions/8.1.1/contribute/design-documents) first.
+If the change is significant, follow the [design document policy](/versions/8.1.1/contribute/design-documents) first.
 
 ## Guidelines {#guidelines}
 
@@ -60,10 +59,8 @@ change is about.
 
 ## Process {#process}
 
-As part of the [release
-process](https://github.com/bazelbuild/continuous-integration/blob/master/docs/release-playbook.md),
-we collect the `RELNOTES` tags of every commit. We copy everything in a [Google
-Doc](https://docs.google.com/document/d/1wDvulLlj4NAlPZamdlEVFORks3YXJonCjyuQMUQEmB0/edit)
+As part of the [release process](https://github.com/bazelbuild/continuous-integration/blob/master/docs/release-playbook.md),
+we collect the `RELNOTES` tags of every commit. We copy everything in a [Google Doc](https://docs.google.com/document/d/1wDvulLlj4NAlPZamdlEVFORks3YXJonCjyuQMUQEmB0/edit)
 where we review, edit, and organize the notes.
 
 The release manager sends an email to the
@@ -71,6 +68,4 @@ The release manager sends an email to the
 Bazel contributors are invited to contribute to the document and make sure
 their changes are correctly reflected in the announcement.
 
-Later, the announcement will be submitted to the [Bazel
-blog](https://blog.bazel.build/), using the [bazel-blog
-repository](https://github.com/bazelbuild/bazel-blog/tree/master/_posts).
+Later, the announcement will be submitted to the [Bazel blog](https://blog.bazel.build/), using the [bazel-blog repository](https://github.com/bazelbuild/bazel-blog/tree/master/_posts).
diff --git a/versions/8.1.1/contribute/statemachine-guide.mdx b/versions/8.1.1/contribute/statemachine-guide.mdx
index cb9ece5c..86b15b74 100644
--- a/versions/8.1.1/contribute/statemachine-guide.mdx
+++ b/versions/8.1.1/contribute/statemachine-guide.mdx
@@ -172,8 +172,7 @@ instead, batches[^4] as many lookups as possible before doing so. The value
 might not be immediately available, for example, requiring a Skyframe restart,
 so the caller specifies what to do with the resulting value using a callback.
 
-The `StateMachine` processor ([`Driver`s and bridging to
-SkyFrame](#drivers-and-bridging)) guarantees that the value is available before
+The `StateMachine` processor ([`Driver`s and bridging to SkyFrame](#drivers-and-bridging)) guarantees that the value is available before
 the next state begins. An example follows.
 
 ```
@@ -284,8 +283,7 @@ and solutions to certain control flow problems.
 ### Sequential states
 
 This is the most common and straightforward control flow pattern. An example of
-this is shown in [Stateful computations inside
-`SkyKeyComputeState`](#stateful-computations).
+this is shown in [Stateful computations inside `SkyKeyComputeState`](#stateful-computations).
 
 ### Branching
 
@@ -545,8 +543,7 @@ section describes the propagation of data values.
 
 ### Implementing `Tasks.lookUp` callbacks
 
-There’s an example of implementing a `Tasks.lookUp` callback in [SkyValue
-lookups](#skyvalue-lookups). This section provides rationale and suggests
+There’s an example of implementing a `Tasks.lookUp` callback in [SkyValue lookups](#skyvalue-lookups). This section provides rationale and suggests
 approaches for handling multiple SkyValues.
 
 #### `Tasks.lookUp` callbacks {#tasks-lookup-callbacks}
@@ -710,8 +707,7 @@ class BarProducer implements StateMachine {
 Tip: It would be tempting to use the more concise signature void `accept(Bar
 value)` rather than the stuttery `void acceptBarValue(Bar value)` above.
 However, `Consumer` is a common overload of `void accept(Bar value)`,
-so doing this often leads to violations of the [Overloads: never
-split](https://google.github.io/styleguide/javaguide.html#s3.4.2-ordering-class-contents)
+so doing this often leads to violations of the [Overloads: never split](https://google.github.io/styleguide/javaguide.html#s3.4.2-ordering-class-contents)
 style-guide rule.
 
 Tip: Using a custom `ResultSink` type instead of a generic one from
@@ -774,14 +770,11 @@ pattern after accepting output from either a subtask or SkyValue lookup.
 Note that the implementation of `acceptBarError` eagerly forwards the result to
 the `Caller.ResultSink`, as required by [Error bubbling](#error-bubbling).
 
-Alternatives for top-level `StateMachine`s are described in [`Driver`s and
-bridging to SkyFunctions](#drivers-and-bridging).
+Alternatives for top-level `StateMachine`s are described in [`Driver`s and bridging to SkyFunctions](#drivers-and-bridging).
 
 ### Error handling {#error-handling}
 
-There's a couple of examples of error handling already in [`Tasks.lookUp`
-callbacks](#tasks-lookup-callbacks) and [Propagating values between
-`StateMachines`](#propagating-values). Exceptions, other than
+There's a couple of examples of error handling already in [`Tasks.lookUp` callbacks](#tasks-lookup-callbacks) and [Propagating values between `StateMachines`](#propagating-values). Exceptions, other than
 `InterruptedException` are not thrown, but instead passed around through
 callbacks as values. Such callbacks often have exclusive-or semantics, with
 exactly one of a value or error being passed.
@@ -1184,8 +1177,7 @@ states. Where it is possible, local stack `step` variables are young generation
 variables and efficiently GC'd.
 
 For `StateMachine` variables, breaking things down into subtasks and following
-the recommended pattern for [Propagating values between
-`StateMachine`s](#propagating-values) is also helpful. Observe that when
+the recommended pattern for [Propagating values between `StateMachine`s](#propagating-values) is also helpful. Observe that when
 following the pattern, only child `StateMachine`s have references to parent
 `StateMachine`s and not vice versa. This means that as children complete and
 update the parents using result callbacks, the children naturally fall out of
@@ -1207,8 +1199,7 @@ potentially reflecting local behavior.
 
 ### Concurrency tree diagram {#concurrency-tree-diagram}
 
-The following is an alternative view of the diagram in [Structured
-concurrency](#structured-concurrency) that better depicts the tree structure.
+The following is an alternative view of the diagram in [Structured concurrency](#structured-concurrency) that better depicts the tree structure.
 The blocks form a small tree.
 
 ![Structured Concurrency 3D](/versions/8.1.1/contribute/images/structured-concurrency-3d.svg)
diff --git a/versions/8.1.1/docs/android-instrumentation-test.mdx b/versions/8.1.1/docs/android-instrumentation-test.mdx
index 69b85830..01ea958b 100644
--- a/versions/8.1.1/docs/android-instrumentation-test.mdx
+++ b/versions/8.1.1/docs/android-instrumentation-test.mdx
@@ -2,8 +2,7 @@
 title: 'Android Instrumentation Tests'
 ---
 
-_If you're new to Bazel, start with the [Building Android with
-Bazel](/versions/8.1.1/start/android-app ) tutorial._
+_If you're new to Bazel, start with the [Building Android with Bazel](/versions/8.1.1/start/android-app) tutorial._
 
 ![Running Android instrumentation tests in parallel](/versions/8.1.1/docs/images/android_test.gif "Android instrumentation test")
 
@@ -18,9 +17,7 @@ emulators in a sandbox, ensuring that tests always run from a clean state. Each
 test gets an isolated emulator instance, allowing tests to run in parallel
 without passing states between them.
 
-For more information on Android instrumentation tests, check out the [Android
-developer
-documentation](https://developer.android.com/training/testing/unit-testing/instrumented-unit-tests.html).
+For more information on Android instrumentation tests, check out the [Android developer documentation](https://developer.android.com/training/testing/unit-testing/instrumented-unit-tests.html).
 
 Please file issues in the [GitHub issue tracker](https://github.com/bazelbuild/bazel/issues).
 
@@ -58,8 +55,7 @@ This results in output similar to the following:
 release 4.1.0
 ```
 
-- **KVM**. Bazel requires emulators to have [hardware
-  acceleration](https://developer.android.com/studio/run/emulator-acceleration.html#accel-check)
+- **KVM**. Bazel requires emulators to have [hardware acceleration](https://developer.android.com/studio/run/emulator-acceleration.html#accel-check)
   with KVM on Linux. You can follow these
   [installation instructions](https://help.ubuntu.com/community/KVM/Installation)
   for Ubuntu.
@@ -173,11 +169,9 @@ The main attributes of the rule `android_instrumentation_test` are:
 
 - `target_device`: An `android_device` target. This target describes the
   specifications of the Android emulator which Bazel uses to create, launch and
-  run the tests. See the [section on choosing an Android
-  device](#android-device-target) for more information.
+  run the tests. See the [section on choosing an Android device](#android-device-target) for more information.
 
-The test app's `AndroidManifest.xml` must include [an ``
-tag](https://developer.android.com/studio/test/#configure_instrumentation_manifest_settings).
+The test app's `AndroidManifest.xml` must include [an `` tag](https://developer.android.com/studio/test/#configure_instrumentation_manifest_settings).
 This tag must specify the attributes for the **package of the target app** and
 the **fully qualified class name of the instrumentation test runner**,
 `androidx.test.runner.AndroidJUnitRunner`.
@@ -214,8 +208,7 @@ repositories:
 - `@androidsdk`: The Android SDK. Download this through Android Studio.
 
 - `@android_test_support`: Hosts the test runner, emulator launcher, and
-  `android_device` targets. You can find the [latest release
-  here](https://github.com/android/android-test/releases).
+  `android_device` targets. You can find the [latest release here](https://github.com/android/android-test/releases).
 
 Enable these dependencies by adding the following lines to your `WORKSPACE`
 file:
@@ -240,8 +233,7 @@ android_test_repositories()
 
 ## Maven dependencies {#maven-dependencies}
 
-For managing dependencies on Maven artifacts from repositories, such as [Google
-Maven](https://maven.google.com) or [Maven Central](https://central.maven.org),
+For managing dependencies on Maven artifacts from repositories, such as [Google Maven](https://maven.google.com) or [Maven Central](https://central.maven.org),
 you should use a Maven resolver, such as
 [`rules_jvm_external`](https://github.com/bazelbuild/rules_jvm_external).
 
@@ -370,8 +362,7 @@ the device/emulator listed in `adb devices`.
 
 ## Sample projects {#sample-projects}
 
-If you are looking for canonical project samples, see the [Android testing
-samples](https://github.com/googlesamples/android-testing#experimental-bazel-support)
+If you are looking for canonical project samples, see the [Android testing samples](https://github.com/googlesamples/android-testing#experimental-bazel-support)
 for projects using Espresso and UIAutomator.
 
 ## Espresso setup {#espresso-setup}
@@ -560,8 +551,7 @@ API_LEVELS = [
 
 ## Known issues {#known-issues}
 
-- [Forked adb server processes are not terminated after
-  tests](https://github.com/bazelbuild/bazel/issues/4853)
+- [Forked adb server processes are not terminated after tests](https://github.com/bazelbuild/bazel/issues/4853)
 - While APK building works on all platforms (Linux, macOS, Windows), testing
   only works on Linux.
 - Even with `--config=local_adb`, users still need to specify
diff --git a/versions/8.1.1/docs/android-ndk.mdx b/versions/8.1.1/docs/android-ndk.mdx
index 34e253e4..286e336a 100644
--- a/versions/8.1.1/docs/android-ndk.mdx
+++ b/versions/8.1.1/docs/android-ndk.mdx
@@ -2,8 +2,7 @@
 title: 'Using the Android Native Development Kit with Bazel'
 ---
 
-_If you're new to Bazel, please start with the [Building Android with
-Bazel](/versions/8.1.1/start/android-app ) tutorial._
+_If you're new to Bazel, please start with the [Building Android with Bazel](/versions/8.1.1/start/android-app) tutorial._
 
 ## Overview {#overview}
 
@@ -31,8 +30,7 @@ android_ndk_repository(
 )
 ```
 
-For more information about the `android_ndk_repository` rule, see the [Build
-Encyclopedia entry](/versions/8.1.1/reference/be/android#android_ndk_repository).
+For more information about the `android_ndk_repository` rule, see the [Build Encyclopedia entry](/versions/8.1.1/reference/be/android#android_ndk_repository).
 
 If you're using a recent version of the Android NDK (r22 and beyond), use the
 Starlark implementation of `android_ndk_repository`.
@@ -101,13 +99,11 @@ META-INF/MANIFEST.MF
 
 Bazel compiles all of the cc_libraries into a single shared object (`.so`) file,
 targeted for the `armeabi-v7a` ABI by default. To change this or build for
-multiple ABIs at the same time, see the section on [configuring the target
-ABI](#configuring-target-abi).
+multiple ABIs at the same time, see the section on [configuring the target ABI](#configuring-target-abi).
 
 ## Example setup {#example-setup}
 
-This example is available in the [Bazel examples
-repository](https://github.com/bazelbuild/examples/tree/master/android/ndk).
+This example is available in the [Bazel examples repository](https://github.com/bazelbuild/examples/tree/master/android/ndk).
 
 In the `BUILD.bazel` file, three targets are defined with the `android_binary`,
 `android_library`, and `cc_library` rules.
diff --git a/versions/8.1.1/docs/bazel-and-android.mdx b/versions/8.1.1/docs/bazel-and-android.mdx
index 8cfc2581..350a0aa2 100644
--- a/versions/8.1.1/docs/bazel-and-android.mdx
+++ b/versions/8.1.1/docs/bazel-and-android.mdx
@@ -10,7 +10,7 @@ Android projects with Bazel.
 
 The following resources will help you work with Bazel on Android projects:
 
-*  [Tutorial: Building an Android app](/versions/8.1.1/start/android-app ). This
+*  [Tutorial: Building an Android app](/versions/8.1.1/start/android-app). This
    tutorial is a good place to start learning about Bazel commands and concepts,
    and how to build Android apps with Bazel.
 *  [Codelab: Building Android Apps with Bazel](https://developer.android.com/codelabs/bazel-android-intro#0).
diff --git a/versions/8.1.1/docs/configurable-attributes.mdx b/versions/8.1.1/docs/configurable-attributes.mdx
index 2e98a39d..9e4a30a3 100644
--- a/versions/8.1.1/docs/configurable-attributes.mdx
+++ b/versions/8.1.1/docs/configurable-attributes.mdx
@@ -2,8 +2,7 @@
 title: 'Configurable Build Attributes'
 ---
 
-**_Configurable attributes_**, commonly known as [`select()`](
-/reference/be/functions#select), is a Bazel feature that lets users toggle the values
+**_Configurable attributes_**, commonly known as [`select()`](/versions/8.1.1/reference/be/functions#select), is a Bazel feature that lets users toggle the values
 of build rule attributes at the command line.
 
 This can be used, for example, for a multiplatform library that automatically
@@ -407,8 +406,7 @@ sh_library(
 )
 ```
 
-If you need a `select` to match when multiple conditions match, consider [AND
-chaining](#and-chaining).
+If you need a `select` to match when multiple conditions match, consider [AND chaining](#and-chaining).
 
 ## OR chaining {#or-chaining}
 
diff --git a/versions/8.1.1/docs/images/a_b_a_c.svg b/versions/8.1.1/docs/images/a_b_a_c.svg
new file mode 100644
index 00000000..d38be075
--- /dev/null
+++ b/versions/8.1.1/docs/images/a_b_a_c.svg
@@ -0,0 +1,42 @@
+
+
+
+
+
+
+G
+
+
+
+a
+
+a
+
+
+
+b
+
+b
+
+
+
+a->b
+
+
+
+
+
+c
+
+c
+
+
+
+a->c
+
+
+
+
+
+
diff --git a/versions/8.1.1/docs/images/a_b_c.svg b/versions/8.1.1/docs/images/a_b_c.svg
new file mode 100644
index 00000000..acd948ab
--- /dev/null
+++ b/versions/8.1.1/docs/images/a_b_c.svg
@@ -0,0 +1,41 @@
+
+
+
+
+
+
+G
+
+
+
+a
+
+a
+
+
+
+b
+
+b
+
+
+
+a->b
+
+
+
+
+
+c
+
+c
+
+
+
+b->c
+
+
+
+
+
diff --git a/versions/8.1.1/docs/images/a_b_c_ac.svg b/versions/8.1.1/docs/images/a_b_c_ac.svg
new file mode 100644
index 00000000..b099c53e
--- /dev/null
+++ b/versions/8.1.1/docs/images/a_b_c_ac.svg
@@ -0,0 +1,47 @@
+
+
+
+
+
+
+G
+
+
+
+a
+
+a
+
+
+
+b
+
+b
+
+
+
+a->b
+
+
+
+
+
+c
+
+c
+
+
+
+a->c
+
+
+
+
+
+b->c
+
+
+
+
+
diff --git a/versions/8.1.1/docs/images/ab_c.svg b/versions/8.1.1/docs/images/ab_c.svg
new file mode 100644
index 00000000..bcc4563f
--- /dev/null
+++ b/versions/8.1.1/docs/images/ab_c.svg
@@ -0,0 +1,36 @@
+
+
+
+
+
+
+G
+
+
+
+a
+
+a
+
+
+
+b
+
+b
+
+
+
+a->b
+
+
+
+
+
+c
+
+c
+
+
+
+
diff --git a/versions/8.1.1/docs/images/allpaths.svg b/versions/8.1.1/docs/images/allpaths.svg
new file mode 100644
index 00000000..47d0ee33
--- /dev/null
+++ b/versions/8.1.1/docs/images/allpaths.svg
@@ -0,0 +1,141 @@
+
+
+
+
+
+
+allpaths
+
+
+
+n1
+
+
+
+
+n2
+
+
+
+
+n1->n2
+
+
+
+
+
+n3
+
+
+
+
+n2->n3
+
+
+
+
+
+n10
+
+
+
+
+n2->n10
+
+
+
+
+
+n3->n10
+
+
+
+
+
+n4
+
+E
+
+
+
+n5
+
+
+
+
+n6
+
+
+
+
+n5->n6
+
+
+
+
+
+n6->n4
+
+
+
+
+
+n9
+
+
+
+
+n6->n9
+
+
+
+
+
+n7
+
+S1
+
+
+
+n7->n2
+
+
+
+
+
+n7->n5
+
+
+
+
+
+n8
+
+S2
+
+
+
+n8->n6
+
+
+
+
+
+n10->n4
+
+
+
+
+
+n11
+
+
+
+
+n10->n11
+
+
+
+
+
diff --git a/versions/8.1.1/docs/images/android_instrumentation_test.png b/versions/8.1.1/docs/images/android_instrumentation_test.png
new file mode 100644
index 00000000..e4534fbd
Binary files /dev/null and b/versions/8.1.1/docs/images/android_instrumentation_test.png differ
diff --git a/versions/8.1.1/docs/images/android_ndk.png b/versions/8.1.1/docs/images/android_ndk.png
new file mode 100644
index 00000000..76b63cb3
Binary files /dev/null and b/versions/8.1.1/docs/images/android_ndk.png differ
diff --git a/versions/8.1.1/docs/images/android_tutorial_app.png b/versions/8.1.1/docs/images/android_tutorial_app.png
new file mode 100644
index 00000000..076be5b9
Binary files /dev/null and b/versions/8.1.1/docs/images/android_tutorial_app.png differ
diff --git a/versions/8.1.1/docs/images/android_tutorial_before.png b/versions/8.1.1/docs/images/android_tutorial_before.png
new file mode 100644
index 00000000..8e41d419
Binary files /dev/null and b/versions/8.1.1/docs/images/android_tutorial_before.png differ
diff --git a/versions/8.1.1/docs/images/bep-graph.png b/versions/8.1.1/docs/images/bep-graph.png
new file mode 100644
index 00000000..82da6715
Binary files /dev/null and b/versions/8.1.1/docs/images/bep-graph.png differ
diff --git a/versions/8.1.1/docs/images/bep-graph.svg b/versions/8.1.1/docs/images/bep-graph.svg
new file mode 100644
index 00000000..62b1480f
--- /dev/null
+++ b/versions/8.1.1/docs/images/bep-graph.svg
@@ -0,0 +1,4 @@
+
+
+
+
diff --git a/versions/8.1.1/docs/images/cpp-tutorial-stage1.png b/versions/8.1.1/docs/images/cpp-tutorial-stage1.png
new file mode 100644
index 00000000..c85fb303
Binary files /dev/null and b/versions/8.1.1/docs/images/cpp-tutorial-stage1.png differ
diff --git a/versions/8.1.1/docs/images/cpp-tutorial-stage2.png b/versions/8.1.1/docs/images/cpp-tutorial-stage2.png
new file mode 100644
index 00000000..80e202c9
Binary files /dev/null and b/versions/8.1.1/docs/images/cpp-tutorial-stage2.png differ
diff --git a/versions/8.1.1/docs/images/cpp-tutorial-stage3.png b/versions/8.1.1/docs/images/cpp-tutorial-stage3.png
new file mode 100644
index 00000000..54d82f31
Binary files /dev/null and b/versions/8.1.1/docs/images/cpp-tutorial-stage3.png differ
diff --git a/versions/8.1.1/docs/images/deps.svg b/versions/8.1.1/docs/images/deps.svg
new file mode 100644
index 00000000..4354222a
--- /dev/null
+++ b/versions/8.1.1/docs/images/deps.svg
@@ -0,0 +1,101 @@
+
+
+
+
+
+
+G1
+
+
+
+r1
+
+rule
+
+
+
+s1
+
+in
+
+
+
+r1->s1
+
+
+
+
+
+s2
+
+in
+
+
+
+r1->s2
+
+
+
+
+
+s3
+
+in
+
+
+
+r1->s3
+
+
+
+
+
+r2
+
+rule
+
+
+
+r2->r1
+
+
+
+
+
+s4
+
+in
+
+
+
+r2->s4
+
+
+
+
+
+o1
+
+out
+
+
+
+o1->r1
+
+
+
+
+
+o2
+
+out
+
+
+
+o2->r2
+
+
+
+
+
diff --git a/versions/8.1.1/docs/images/dyn-trace-alldynamic.png b/versions/8.1.1/docs/images/dyn-trace-alldynamic.png
new file mode 100644
index 00000000..fe36b253
Binary files /dev/null and b/versions/8.1.1/docs/images/dyn-trace-alldynamic.png differ
diff --git a/versions/8.1.1/docs/images/dyn-trace-javaconly.png b/versions/8.1.1/docs/images/dyn-trace-javaconly.png
new file mode 100644
index 00000000..2ae41e52
Binary files /dev/null and b/versions/8.1.1/docs/images/dyn-trace-javaconly.png differ
diff --git a/versions/8.1.1/docs/images/e4b-workflow.png b/versions/8.1.1/docs/images/e4b-workflow.png
new file mode 100644
index 00000000..412822da
Binary files /dev/null and b/versions/8.1.1/docs/images/e4b-workflow.png differ
diff --git a/versions/8.1.1/docs/images/e4b-workflow.svg b/versions/8.1.1/docs/images/e4b-workflow.svg
new file mode 100644
index 00000000..1de66e02
--- /dev/null
+++ b/versions/8.1.1/docs/images/e4b-workflow.svg
@@ -0,0 +1,4 @@
+
+
+
+
diff --git a/versions/8.1.1/docs/images/error_example_1.png b/versions/8.1.1/docs/images/error_example_1.png
new file mode 100644
index 00000000..07ba1358
Binary files /dev/null and b/versions/8.1.1/docs/images/error_example_1.png differ
diff --git a/versions/8.1.1/docs/images/error_example_2.png b/versions/8.1.1/docs/images/error_example_2.png
new file mode 100644
index 00000000..861171ee
Binary files /dev/null and b/versions/8.1.1/docs/images/error_example_2.png differ
diff --git a/versions/8.1.1/docs/images/error_example_3.png b/versions/8.1.1/docs/images/error_example_3.png
new file mode 100644
index 00000000..dc16eec4
Binary files /dev/null and b/versions/8.1.1/docs/images/error_example_3.png differ
diff --git a/versions/8.1.1/docs/images/error_example_4.png b/versions/8.1.1/docs/images/error_example_4.png
new file mode 100644
index 00000000..84383e63
Binary files /dev/null and b/versions/8.1.1/docs/images/error_example_4.png differ
diff --git a/versions/8.1.1/docs/images/graph_ex_1.svg b/versions/8.1.1/docs/images/graph_ex_1.svg
new file mode 100644
index 00000000..dd7427f4
--- /dev/null
+++ b/versions/8.1.1/docs/images/graph_ex_1.svg
@@ -0,0 +1,131 @@
+
+
+
+
+
+
+mygraph
+
+
+
+//net/proto_compiler:protocol-compiler
+
+//net/proto_compiler:protocol-compiler
+
+
+
+//net/proto_compiler:util
+
+//net/proto_compiler:util
+
+
+
+//net/proto_compiler:protocol-compiler->//net/proto_compiler:util
+
+
+
+
+
+//net/proto_compiler:protocol-compiler-lib
+
+//net/proto_compiler:protocol-compiler-lib
+
+
+
+//net/proto_compiler:protocol-compiler->//net/proto_compiler:protocol-compiler-lib
+
+
+
+
+
+//net/proto2/bridge/public:compiler_upgrader
+
+//net/proto2/bridge/public:compiler_upgrader
+
+
+
+//net/proto_compiler:protocol-compiler->//net/proto2/bridge/public:compiler_upgrader
+
+
+
+
+
+//net/proto_compiler:parser
+
+//net/proto_compiler:parser
+
+
+
+//net/proto_compiler:util->//net/proto_compiler:parser
+
+
+
+
+
+//net/proto_compiler:proto-min-lib
+
+//net/proto_compiler:proto-min-lib
+
+
+
+//net/proto_compiler:protocol-compiler-lib->//net/proto_compiler:proto-min-lib
+
+
+
+
+
+//net/proto_compiler:protocol-compiler-lib->//net/proto_compiler:parser
+
+
+
+
+
+//net/proto2/bridge/internal:compiler_upgrader
+
+//net/proto2/bridge/internal:compiler_upgrader
+
+
+
+//net/proto2/bridge/public:compiler_upgrader->//net/proto2/bridge/internal:compiler_upgrader
+
+
+
+
+
+//net/proto_compiler:proto-min-lib->//net/proto_compiler:parser
+
+
+
+
+
+//util/regexp:regexp
+
+//util/regexp:regexp
+
+
+
+//net/proto_compiler:proto-min-lib->//util/regexp:regexp
+
+
+
+
+
+//net/proto_compiler:parser->//util/regexp:regexp
+
+
+
+
+
+//net/proto2/bridge/internal:compiler_upgrader->//net/proto2/bridge/public:compiler_upgrader
+
+
+
+
+
+//net/proto2/bridge/internal:compiler_upgrader->//net/proto_compiler:parser
+
+
+
+
+
diff --git a/versions/8.1.1/docs/images/graph_hello-world.svg b/versions/8.1.1/docs/images/graph_hello-world.svg
new file mode 100644
index 00000000..93b61444
--- /dev/null
+++ b/versions/8.1.1/docs/images/graph_hello-world.svg
@@ -0,0 +1,70 @@
+
+
+
+
+
+
+mygraph
+
+
+//main:hello-world
+
+//main:hello-world
+
+
+//main:hello-time
+
+//main:hello-time
+
+
+//main:hello-world->//main:hello-time
+
+
+
+
+//main:hello-world.cc
+
+//main:hello-world.cc
+
+
+//main:hello-world->//main:hello-world.cc
+
+
+
+
+//lib:hello-greet
+
+//lib:hello-greet
+
+
+//main:hello-world->//lib:hello-greet
+
+
+
+
+//main:hello-time.cc\n//main:hello-time.h
+
+//main:hello-time.cc
+//main:hello-time.h
+
+
+//main:hello-time->//main:hello-time.cc\n//main:hello-time.h
+
+
+
+
+//lib:hello-greet.cc\n//lib:hello-greet.h
+
+//lib:hello-greet.cc
+//lib:hello-greet.h
+
+
+//lib:hello-greet->//lib:hello-greet.cc\n//lib:hello-greet.h
+
+
+
+
+
diff --git a/versions/8.1.1/docs/images/json-trace-profile-network-usage.png b/versions/8.1.1/docs/images/json-trace-profile-network-usage.png
new file mode 100644
index 00000000..8a7500a6
Binary files /dev/null and b/versions/8.1.1/docs/images/json-trace-profile-network-usage.png differ
diff --git a/versions/8.1.1/docs/images/json-trace-profile-system-load-average.png b/versions/8.1.1/docs/images/json-trace-profile-system-load-average.png
new file mode 100644
index 00000000..e71b420c
Binary files /dev/null and b/versions/8.1.1/docs/images/json-trace-profile-system-load-average.png differ
diff --git a/versions/8.1.1/docs/images/json-trace-profile-workers-memory-usage.png b/versions/8.1.1/docs/images/json-trace-profile-workers-memory-usage.png
new file mode 100644
index 00000000..806505f0
Binary files /dev/null and b/versions/8.1.1/docs/images/json-trace-profile-workers-memory-usage.png differ
diff --git a/versions/8.1.1/docs/images/json-trace-profile.png b/versions/8.1.1/docs/images/json-trace-profile.png
new file mode 100644
index 00000000..538382b2
Binary files /dev/null and b/versions/8.1.1/docs/images/json-trace-profile.png differ
diff --git a/versions/8.1.1/docs/images/mobile-install-performance.svg b/versions/8.1.1/docs/images/mobile-install-performance.svg
new file mode 100644
index 00000000..b139d658
--- /dev/null
+++ b/versions/8.1.1/docs/images/mobile-install-performance.svg
@@ -0,0 +1,86 @@
+
+
+
+  
+    
+      
+    
+  
+  
+  
+    Build times
+  
+  
+    
+    
+      
+      
+        adb install
+      
+      
+    
+    
+      
+      
+        mobile-install
+      
+      
+    
+  
+  
+    
+    
+      
+        
+        
+        
+        
+        
+      
+      
+        
+        
+        
+        
+        
+        
+      
+      
+        
+      
+    
+    
+    
+      
+        Google Maps
+      
+      
+        Google+
+      
+      
+        YouTube
+      
+      
+        0
+      
+      
+        75
+      
+      
+        150
+      
+      
+        225
+      
+      
+        300
+      
+    
+  
+  
+    
+      Seconds
+    
+  
+  
+
diff --git a/versions/8.1.1/docs/images/namedsetoffiles-bep-graph.png b/versions/8.1.1/docs/images/namedsetoffiles-bep-graph.png
new file mode 100644
index 00000000..ea1e10cc
Binary files /dev/null and b/versions/8.1.1/docs/images/namedsetoffiles-bep-graph.png differ
diff --git a/versions/8.1.1/docs/images/out-ranked.svg b/versions/8.1.1/docs/images/out-ranked.svg
new file mode 100644
index 00000000..07e96804
--- /dev/null
+++ b/versions/8.1.1/docs/images/out-ranked.svg
@@ -0,0 +1,71 @@
+
+
+
+
+
+
+mygraph
+
+
+
+//a:a
+
+//a:a
+
+
+
+//a:a.cc
+
+//a:a.cc
+
+
+
+//a:a->//a:a.cc
+
+
+
+
+
+//b:b
+
+//b:b
+
+
+
+//b:b->//a:a
+
+
+
+
+
+//b:b.cc
+
+//b:b.cc
+
+
+
+//b:b->//b:b.cc
+
+
+
+
+
+//c:c
+
+//c:c
+
+
+
+//c:c->//a:a
+
+
+
+
+
+//c:c->//b:b
+
+
+
+
+
diff --git a/versions/8.1.1/docs/images/rbe-ci-1.png b/versions/8.1.1/docs/images/rbe-ci-1.png
new file mode 100644
index 00000000..fbe76a85
Binary files /dev/null and b/versions/8.1.1/docs/images/rbe-ci-1.png differ
diff --git a/versions/8.1.1/docs/images/rbe-ci-2.png b/versions/8.1.1/docs/images/rbe-ci-2.png
new file mode 100644
index 00000000..07611889
Binary files /dev/null and b/versions/8.1.1/docs/images/rbe-ci-2.png differ
diff --git a/versions/8.1.1/docs/images/somepath1.svg b/versions/8.1.1/docs/images/somepath1.svg
new file mode 100644
index 00000000..5e5f8812
--- /dev/null
+++ b/versions/8.1.1/docs/images/somepath1.svg
@@ -0,0 +1,141 @@
+
+
+
+
+
+
+somepath1
+
+
+
+n1
+
+
+
+
+n2
+
+
+
+
+n1->n2
+
+
+
+
+
+n3
+
+
+
+
+n2->n3
+
+
+
+
+
+n10
+
+
+
+
+n2->n10
+
+
+
+
+
+n3->n10
+
+
+
+
+
+n4
+
+E
+
+
+
+n5
+
+
+
+
+n6
+
+
+
+
+n5->n6
+
+
+
+
+
+n6->n4
+
+
+
+
+
+n9
+
+
+
+
+n6->n9
+
+
+
+
+
+n7
+
+S1
+
+
+
+n7->n2
+
+
+
+
+
+n7->n5
+
+
+
+
+
+n8
+
+S2
+
+
+
+n8->n6
+
+
+
+
+
+n10->n4
+
+
+
+
+
+n11
+
+
+
+
+n10->n11
+
+
+
+
+
diff --git a/versions/8.1.1/docs/images/somepath2.svg b/versions/8.1.1/docs/images/somepath2.svg
new file mode 100644
index 00000000..911f2c9b
--- /dev/null
+++ b/versions/8.1.1/docs/images/somepath2.svg
@@ -0,0 +1,141 @@
+
+
+
+
+
+
+somepath2
+
+
+
+n1
+
+
+
+
+n2
+
+
+
+
+n1->n2
+
+
+
+
+
+n3
+
+
+
+
+n2->n3
+
+
+
+
+
+n10
+
+
+
+
+n2->n10
+
+
+
+
+
+n3->n10
+
+
+
+
+
+n4
+
+E
+
+
+
+n5
+
+
+
+
+n6
+
+
+
+
+n5->n6
+
+
+
+
+
+n6->n4
+
+
+
+
+
+n9
+
+
+
+
+n6->n9
+
+
+
+
+
+n7
+
+S1
+
+
+
+n7->n2
+
+
+
+
+
+n7->n5
+
+
+
+
+
+n8
+
+S2
+
+
+
+n8->n6
+
+
+
+
+
+n10->n4
+
+
+
+
+
+n11
+
+
+
+
+n10->n11
+
+
+
+
+
diff --git a/versions/8.1.1/docs/images/targets.svg b/versions/8.1.1/docs/images/targets.svg
new file mode 100644
index 00000000..82f47e74
--- /dev/null
+++ b/versions/8.1.1/docs/images/targets.svg
@@ -0,0 +1,113 @@
+
+
+
+
+
+
+G1
+
+
+
+Target
+
+Target
+
+
+
+Rule
+
+Rule
+
+
+
+Target->Rule
+
+
+
+
+
+File
+
+File
+
+
+
+Target->File
+
+
+
+
+
+Package group
+
+Package group
+
+
+
+Target->Package group
+
+
+
+
+
+cc_library
+
+cc_library
+
+
+
+Rule->cc_library
+
+
+
+
+
+java_test
+
+java_test
+
+
+
+Rule->java_test
+
+
+
+
+
+...
+
+...
+
+
+
+Rule->...
+
+
+
+
+
+Source
+
+Source
+
+
+
+File->Source
+
+
+
+
+
+Generated
+
+Generated
+
+
+
+File->Generated
+
+
+
+
+
diff --git a/versions/8.1.1/docs/images/tutorial_java_01.svg b/versions/8.1.1/docs/images/tutorial_java_01.svg
new file mode 100644
index 00000000..2fe72f36
--- /dev/null
+++ b/versions/8.1.1/docs/images/tutorial_java_01.svg
@@ -0,0 +1,29 @@
+
+
+
+
+
+
+mygraph
+
+
+//:ProjectRunner
+
+//:ProjectRunner
+
+
+//:src/main/java/com/example/Greeting.java\n//:src/main/java/com/example/ProjectRunner.java
+
+//:src/main/java/com/example/Greeting.java
+//:src/main/java/com/example/ProjectRunner.java
+
+
+//:ProjectRunner->//:src/main/java/com/example/Greeting.java\n//:src/main/java/com/example/ProjectRunner.java
+
+
+
+
+
diff --git a/versions/8.1.1/docs/images/tutorial_java_02.svg b/versions/8.1.1/docs/images/tutorial_java_02.svg
new file mode 100644
index 00000000..40cbb218
--- /dev/null
+++ b/versions/8.1.1/docs/images/tutorial_java_02.svg
@@ -0,0 +1,48 @@
+
+
+
+
+
+
+mygraph
+
+
+//:ProjectRunner
+
+//:ProjectRunner
+
+
+//:greeter
+
+//:greeter
+
+
+//:ProjectRunner->//:greeter
+
+
+
+
+//:src/main/java/com/example/ProjectRunner.java
+
+//:src/main/java/com/example/ProjectRunner.java
+
+
+//:ProjectRunner->//:src/main/java/com/example/ProjectRunner.java
+
+
+
+
+//:src/main/java/com/example/Greeting.java
+
+//:src/main/java/com/example/Greeting.java
+
+
+//:greeter->//:src/main/java/com/example/Greeting.java
+
+
+
+
+
diff --git a/versions/8.1.1/docs/images/tutorial_java_03.svg b/versions/8.1.1/docs/images/tutorial_java_03.svg
new file mode 100644
index 00000000..7d79041a
--- /dev/null
+++ b/versions/8.1.1/docs/images/tutorial_java_03.svg
@@ -0,0 +1,48 @@
+
+
+
+
+
+
+mygraph
+
+
+//src/main/java/com/example/cmdline:runner
+
+//src/main/java/com/example/cmdline:runner
+
+
+//src/main/java/com/example/cmdline:Runner.java
+
+//src/main/java/com/example/cmdline:Runner.java
+
+
+//src/main/java/com/example/cmdline:runner->//src/main/java/com/example/cmdline:Runner.java
+
+
+
+
+//:greeter
+
+//:greeter
+
+
+//src/main/java/com/example/cmdline:runner->//:greeter
+
+
+
+
+//:src/main/java/com/example/Greeting.java
+
+//:src/main/java/com/example/Greeting.java
+
+
+//:greeter->//:src/main/java/com/example/Greeting.java
+
+
+
+
+
diff --git a/versions/8.1.1/docs/images/workers-clean-chart.png b/versions/8.1.1/docs/images/workers-clean-chart.png
new file mode 100644
index 00000000..63526fc1
Binary files /dev/null and b/versions/8.1.1/docs/images/workers-clean-chart.png differ
diff --git a/versions/8.1.1/docs/images/workers-incremental-chart.png b/versions/8.1.1/docs/images/workers-incremental-chart.png
new file mode 100644
index 00000000..1c62d25c
Binary files /dev/null and b/versions/8.1.1/docs/images/workers-incremental-chart.png differ
diff --git a/versions/8.1.1/docs/images/ws-diamond.png b/versions/8.1.1/docs/images/ws-diamond.png
new file mode 100644
index 00000000..154a7440
Binary files /dev/null and b/versions/8.1.1/docs/images/ws-diamond.png differ
diff --git a/versions/8.1.1/docs/images/ws-line.png b/versions/8.1.1/docs/images/ws-line.png
new file mode 100644
index 00000000..e8bfe7a1
Binary files /dev/null and b/versions/8.1.1/docs/images/ws-line.png differ
diff --git a/versions/8.1.1/docs/images/ws-multiline.png b/versions/8.1.1/docs/images/ws-multiline.png
new file mode 100644
index 00000000..f07b43b1
Binary files /dev/null and b/versions/8.1.1/docs/images/ws-multiline.png differ
diff --git a/versions/8.1.1/docs/sandboxing.mdx b/versions/8.1.1/docs/sandboxing.mdx
index bfbdc4a2..2854c878 100644
--- a/versions/8.1.1/docs/sandboxing.mdx
+++ b/versions/8.1.1/docs/sandboxing.mdx
@@ -48,7 +48,7 @@ containers on Linux and `sandbox-exec` on macOS, to constrain the action within
 ## What sandbox strategy to use {#sandboxing-strategies}
 
 You can choose which kind of sandboxing to use, if any, with the
-[strategy flags](user-manual#strategy-options). Using the `sandboxed`
+[strategy flags](/versions/8.1.1/docs/user-manual#strategy-options). Using the `sandboxed`
 strategy makes Bazel pick one of the sandbox implementations listed below,
 preferring an OS-specific sandbox to the less hermetic generic one.
 [Persistent workers](/versions/8.1.1/remote/persistent) run in a generic sandbox if you pass
diff --git a/versions/8.1.1/docs/user-manual.mdx b/versions/8.1.1/docs/user-manual.mdx
index 661c0ec1..775715f2 100644
--- a/versions/8.1.1/docs/user-manual.mdx
+++ b/versions/8.1.1/docs/user-manual.mdx
@@ -1143,12 +1143,12 @@ during execution can be examined.
 This option causes Bazel's execution phase to print the full command line
 for each command prior to executing it.
 
-
-  >>>>> # //examples/cpp:hello-world [action 'Linking examples/cpp/hello-world']
+```
+  >>>> # //examples/cpp:hello-world [action 'Linking examples/cpp/hello-world']
   (cd /home/johndoe/.cache/bazel/_bazel_johndoe/4c084335afceb392cfbe7c31afee3a9f/bazel && \
     exec env - \
     /usr/bin/gcc -o bazel-out/local-fastbuild/bin/examples/cpp/hello-world -B/usr/bin/ -Wl,-z,relro,-z,now -no-canonical-prefixes -pass-exit-codes -Wl,-S -Wl,@bazel-out/local_linux-fastbuild/bin/examples/cpp/hello-world-2.params)
-

+```
 
 Where possible, commands are printed in a Bourne shell compatible syntax,
 so that they can be easily copied and pasted to a shell command prompt.
diff --git a/versions/8.1.1/extending/auto-exec-groups.mdx b/versions/8.1.1/extending/auto-exec-groups.mdx
index 9c3d0d33..741e6520 100644
--- a/versions/8.1.1/extending/auto-exec-groups.mdx
+++ b/versions/8.1.1/extending/auto-exec-groups.mdx
@@ -27,9 +27,7 @@ doesn't detect that ([the error](#first-error-message) is raised), you can set
 
 If you need to use multiple toolchains on a single execution platform (an action
 uses executable or tools from two or more toolchains), you need to manually
-define [exec_groups][exec_groups] (check
-[When should I use a custom exec_group?][multiple_toolchains_exec_groups]
-section).
+define [exec_groups][exec_groups](check [When should I use a custom exec_group?][multiple_toolchains_exec_groups] section).
 
 ## History {#history}
 
@@ -42,8 +40,7 @@ my_rule = rule(
 )
 ```
 
-Rule `my_rule` registers two toolchain types. This means that the [Toolchain
-Resolution](https://bazel.build/extending/toolchains#toolchain-resolution) used
+Rule `my_rule` registers two toolchain types. This means that the [Toolchain Resolution](https://bazel.build/versions/8.1.1/extending/toolchains#toolchain-resolution) used
 to find an execution platform which supports both toolchain types. The selected
 execution platform was used for each registered action inside the rule, unless
 specified differently with [exec_groups][exec_groups].
diff --git a/versions/8.1.1/extending/concepts.mdx b/versions/8.1.1/extending/concepts.mdx
index 37ea889f..15299879 100644
--- a/versions/8.1.1/extending/concepts.mdx
+++ b/versions/8.1.1/extending/concepts.mdx
@@ -20,16 +20,14 @@ Before learning the more advanced concepts, first:
 ## Macros and rules {#macros-and-rules}
 
 A macro is a function that instantiates rules. Macros come in two flavors:
-[symbolic macros](/versions/8.1.1/extending/macros) (new in Bazel 8) and [legacy
-macros](/versions/8.1.1/extending/legacy-macros). The two flavors of macros are defined
+[symbolic macros](/versions/8.1.1/extending/macros) (new in Bazel 8) and [legacy macros](/versions/8.1.1/extending/legacy-macros). The two flavors of macros are defined
 differently, but behave almost the same from the point of view of a user. A
 macro is useful when a `BUILD` file is getting too repetitive or too complex, as
 it lets you reuse some code. The function is evaluated as soon as the `BUILD`
 file is read. After the evaluation of the `BUILD` file, Bazel has little
 information about macros. If your macro generates a `genrule`, Bazel will
 behave *almost* as if you declared that `genrule` in the `BUILD` file. (The one
-exception is that targets declared in a symbolic macro have [special visibility
-semantics](/versions/8.1.1/extending/macros#visibility): a symbolic macro can hide its internal
+exception is that targets declared in a symbolic macro have [special visibility semantics](/versions/8.1.1/extending/macros#visibility): a symbolic macro can hide its internal
 targets from the rest of the package.)
 
 A [rule](/versions/8.1.1/extending/rules) is more powerful than a macro. It can access Bazel
@@ -76,8 +74,7 @@ they will not be executed.
 ## Creating extensions
 
 * [Create your first macro](/versions/8.1.1/rules/macro-tutorial) in order to reuse some code.
-  Then [learn more about macros](/versions/8.1.1/extending/macros) and [using them to create
-  "custom verbs"](/versions/8.1.1/rules/verbs-tutorial).
+  Then [learn more about macros](/versions/8.1.1/extending/macros) and [using them to create "custom verbs"](/versions/8.1.1/rules/verbs-tutorial).
 
 * [Follow the rules tutorial](/versions/8.1.1/rules/rules-tutorial) to get started with rules.
   Next, you can read more about the [rules concepts](/versions/8.1.1/extending/rules).
@@ -92,8 +89,7 @@ them within reach:
 ## Going further
 
 In addition to [macros](/versions/8.1.1/extending/macros) and [rules](/versions/8.1.1/extending/rules), you
-may want to write [aspects](/versions/8.1.1/extending/aspects) and [repository
-rules](/versions/8.1.1/extending/repo).
+may want to write [aspects](/versions/8.1.1/extending/aspects) and [repository rules](/versions/8.1.1/extending/repo).
 
 * Use [Buildifier](https://github.com/bazelbuild/buildtools)
   consistently to format and lint your code.
diff --git a/versions/8.1.1/extending/depsets.mdx b/versions/8.1.1/extending/depsets.mdx
index 816c9418..ed933e91 100644
--- a/versions/8.1.1/extending/depsets.mdx
+++ b/versions/8.1.1/extending/depsets.mdx
@@ -111,8 +111,7 @@ need to ensure that if `B` depends on `A`, then `A.o` comes before `B.o` on the
 linker’s command line. Other tools might have the opposite requirement.
 
 Three traversal orders are supported: `postorder`, `preorder`, and
-`topological`. The first two work exactly like [tree
-traversals](https://en.wikipedia.org/wiki/Tree_traversal#Depth-first_search)
+`topological`. The first two work exactly like [tree traversals](https://en.wikipedia.org/wiki/Tree_traversal#Depth-first_search)
 except that they operate on DAGs and skip already visited nodes. The third order
 works as a topological sort from root to leaves, essentially the same as
 preorder except that shared children are listed only after all of their parents.
diff --git a/versions/8.1.1/extending/exec-groups.mdx b/versions/8.1.1/extending/exec-groups.mdx
index 2733b6a2..0b59afe5 100644
--- a/versions/8.1.1/extending/exec-groups.mdx
+++ b/versions/8.1.1/extending/exec-groups.mdx
@@ -63,8 +63,7 @@ test rules.
 
 In the rule implementation, you can declare that actions should be run on the
 execution platform of an execution group. You can do this by using the `exec_group`
-param of action generating methods, specifically [`ctx.actions.run`]
-(/rules/lib/builtins/actions#run) and
+param of action generating methods, specifically [`ctx.actions.run`](/versions/8.1.1/rules/lib/builtins/actions#run) and
 [`ctx.actions.run_shell`](/versions/8.1.1/rules/lib/builtins/actions#run_shell).
 
 ```python
diff --git a/versions/8.1.1/extending/legacy-macros.mdx b/versions/8.1.1/extending/legacy-macros.mdx
index d00f7e71..b7551fa4 100644
--- a/versions/8.1.1/extending/legacy-macros.mdx
+++ b/versions/8.1.1/extending/legacy-macros.mdx
@@ -9,7 +9,7 @@ anymore, and Bazel sees only the concrete set of instantiated rules.
 
 ## Why you shouldn't use legacy macros (and should use Symbolic macros instead) {#no-legacy-macros}
 
-Where possible you should use [symbolic macros](macros.md#macros).
+Where possible you should use [symbolic macros](/versions/8.1.1/extending/macros#macros).
 
 Symbolic macros
 
@@ -18,7 +18,7 @@ Symbolic macros
 *   Take typed attributes, which in turn means automatic label and select
     conversion.
 *   Are more readable
-*   Will soon have [lazy evaluation](macros.md/laziness)
+*   Will soon have [lazy evaluation](/versions/8.1.1/extending/macros#laziness)
 
 ## Usage {#usage}
 
@@ -152,7 +152,7 @@ the macro), use the function
 ## Label resolution in macros {#label-resolution}
 
 Since legacy macros are evaluated in the
-[loading phase](concepts.md#evaluation-model), label strings such as
+[loading phase](/versions/8.1.1/extending/concepts#evaluation-model), label strings such as
 `"//foo:bar"` that occur in a legacy macro are interpreted relative to the
 `BUILD` file in which the macro is used rather than relative to the `.bzl` file
 in which it is defined. This behavior is generally undesirable for macros that
diff --git a/versions/8.1.1/extending/macros.mdx b/versions/8.1.1/extending/macros.mdx
index 3b620b9a..5bedaef3 100644
--- a/versions/8.1.1/extending/macros.mdx
+++ b/versions/8.1.1/extending/macros.mdx
@@ -10,7 +10,7 @@ Macros are mainly used for encapsulation and code reuse of existing rules and
 other macros.
 
 Macros come in two flavors: symbolic macros, which are described on this page,
-and [legacy macros](legacy-macros.md). Where possible, we recommend using
+and [legacy macros](/versions/8.1.1/extending/legacy-macros). Where possible, we recommend using
 symbolic macros for code clarity.
 
 Symbolic macros offer typed arguments (string to label conversion, relative to
@@ -31,8 +31,7 @@ two required parameters: `attrs` and `implementation`.
 
 ### Attributes {#attributes}
 
-`attrs` accepts a dictionary of attribute name to [attribute
-types](https://bazel.build/rules/lib/toplevel/attr#members), which represents
+`attrs` accepts a dictionary of attribute name to [attribute types](https://bazel.build/versions/8.1.1/rules/lib/toplevel/attr#members), which represents
 the arguments to the macro. Two common attributes – `name` and `visibility` –
 are implicitly added to all macros and are not included in the dictionary passed
 to `attrs`.
@@ -66,9 +65,7 @@ To support this pattern, a macro can *inherit attributes* from a rule or another
 macro by passing the [rule](https://bazel.build/versions/8.1.1/rules/lib/builtins/rule) or
 [macro symbol](https://bazel.build/versions/8.1.1/rules/lib/builtins/macro) to `macro()`'s
 `inherit_attrs` argument. (You can also use the special string `"common"`
-instead of a rule or macro symbol to inherit the [common attributes defined for
-all Starlark build
-rules](https://bazel.build/reference/be/common-definitions#common-attributes).)
+instead of a rule or macro symbol to inherit the [common attributes defined for all Starlark build rules](https://bazel.build/versions/8.1.1/reference/be/common-definitions#common-attributes).)
 Only public attributes get inherited, and the attributes in the macro's own
 `attrs` dictionary override inherited attributes with the same name. You can
 also *remove* inherited attributes by using `None` as a value in the `attrs`
diff --git a/versions/8.1.1/extending/platforms.mdx b/versions/8.1.1/extending/platforms.mdx
index bad03150..a77ff544 100644
--- a/versions/8.1.1/extending/platforms.mdx
+++ b/versions/8.1.1/extending/platforms.mdx
@@ -245,8 +245,7 @@ cc_library(
 
 You can use the
 [`IncompatiblePlatformProvider`](/versions/8.1.1/rules/lib/providers/IncompatiblePlatformProvider)
-in `bazel cquery`'s [Starlark output
-format](/versions/8.1.1/query/cquery#output-format-definition) to distinguish
+in `bazel cquery`'s [Starlark output format](/versions/8.1.1/query/cquery#output-format-definition) to distinguish
 incompatible targets from compatible ones.
 
 This can be used to filter out incompatible targets. The example below will
@@ -266,5 +265,4 @@ $ bazel cquery //... --output=starlark --starlark:file=example.cquery
 
 ### Known Issues
 
-Incompatible targets [ignore visibility
-restrictions](https://github.com/bazelbuild/bazel/issues/16044).
+Incompatible targets [ignore visibility restrictions](https://github.com/bazelbuild/bazel/issues/16044).
diff --git a/versions/8.1.1/extending/repo.mdx b/versions/8.1.1/extending/repo.mdx
index 2963e0bb..2688c0cf 100644
--- a/versions/8.1.1/extending/repo.mdx
+++ b/versions/8.1.1/extending/repo.mdx
@@ -74,8 +74,7 @@ specified.
 
 The input parameter `repository_ctx` can be used to access attribute values, and
 non-hermetic functions (finding a binary, executing a binary, creating a file in
-the repository or downloading a file from the Internet). See [the API
-docs](/versions/8.1.1/rules/lib/builtins/repository_ctx) for more context. Example:
+the repository or downloading a file from the Internet). See [the API docs](/versions/8.1.1/rules/lib/builtins/repository_ctx) for more context. Example:
 
 ```python
 def _impl(repository_ctx):
@@ -144,8 +143,7 @@ definition has the `configure` attribute set, use `bazel fetch --force
 
 ## Examples
 
--   [C++ auto-configured
-    toolchain](https://cs.opensource.google/bazel/bazel/+/master:tools/cpp/cc_configure.bzl;drc=644b7d41748e09eff9e47cbab2be2263bb71f29a;l=176):
+-   [C++ auto-configured toolchain](https://cs.opensource.google/bazel/bazel/+/master:tools/cpp/cc_configure.bzl;drc=644b7d41748e09eff9e47cbab2be2263bb71f29a;l=176):
     it uses a repo rule to automatically create the C++ configuration files for
     Bazel by looking for the local C++ compiler, the environment and the flags
     the C++ compiler supports.
diff --git a/versions/8.1.1/extending/rules.mdx b/versions/8.1.1/extending/rules.mdx
index 9138e5bb..dc1b702b 100644
--- a/versions/8.1.1/extending/rules.mdx
+++ b/versions/8.1.1/extending/rules.mdx
@@ -449,8 +449,7 @@ def _example_library_impl(ctx):
 
 If `DefaultInfo` is not returned by a rule implementation or the `files`
 parameter is not specified, `DefaultInfo.files` defaults to all
-*predeclared outputs* (generally, those created by [output
-attributes](#output_attributes)).
+*predeclared outputs* (generally, those created by [output attributes](#output_attributes)).
 
 Rules that perform actions should provide default outputs, even if those outputs
 are not expected to be directly used. Actions that are not in the graph of the
diff --git a/versions/8.1.1/extending/toolchains.mdx b/versions/8.1.1/extending/toolchains.mdx
index 31744967..f36fddea 100644
--- a/versions/8.1.1/extending/toolchains.mdx
+++ b/versions/8.1.1/extending/toolchains.mdx
@@ -523,8 +523,7 @@ The set of available toolchains, in priority order, is created from
   4. Toolchains registered in the "WORKSPACE suffix"; this is only used by
      certain native rules bundled with the Bazel installation.
 
-**NOTE:** [Pseudo-targets like `:all`, `:*`, and
-`/...`](/versions/8.1.1/run/build#specifying-build-targets) are ordered by Bazel's package
+**NOTE:** [Pseudo-targets like `:all`, `:*`, and `/...`](/versions/8.1.1/run/build#specifying-build-targets) are ordered by Bazel's package
 loading mechanism, which uses a lexicographic ordering.
 
 The resolution steps are as follows.
diff --git a/versions/8.1.1/external/advanced.mdx b/versions/8.1.1/external/advanced.mdx
index e247b382..bb120a5a 100644
--- a/versions/8.1.1/external/advanced.mdx
+++ b/versions/8.1.1/external/advanced.mdx
@@ -4,10 +4,8 @@ title: 'Advanced topics on external dependencies'
 
 ## Shadowing dependencies in WORKSPACE
 
-Note: This section applies to the [WORKSPACE
-system](/versions/8.1.1/external/overview#workspace-system) only. For
-[Bzlmod](/versions/8.1.1/external/overview#bzlmod), use a [multiple-version
-override](/versions/8.1.1/external/module#multiple-version_override).
+Note: This section applies to the [WORKSPACE system](/versions/8.1.1/external/overview#workspace-system) only. For
+[Bzlmod](/versions/8.1.1/external/overview#bzlmod), use a [multiple-version override](/versions/8.1.1/external/module#multiple-version_override).
 
 Whenever possible, have a single version policy in your project, which is
 required for dependencies that you compile against and end up in your final
@@ -128,29 +126,24 @@ preferring IPv4 if enabled. In some situations, for example when the IPv4
 network cannot resolve/reach external addresses, this can cause `Network
 unreachable` exceptions and build failures. In these cases, you can override
 Bazel's behavior to prefer IPv6 by using the
-[`java.net.preferIPv6Addresses=true` system
-property](https://docs.oracle.com/javase/8/docs/api/java/net/doc-files/net-properties.html).
+[`java.net.preferIPv6Addresses=true` system property](https://docs.oracle.com/javase/8/docs/api/java/net/doc-files/net-properties.html).
 Specifically:
 
-*   Use `--host_jvm_args=-Djava.net.preferIPv6Addresses=true` [startup
-    option](/versions/8.1.1/docs/user-manual#startup-options), for example by adding the
+*   Use `--host_jvm_args=-Djava.net.preferIPv6Addresses=true` [startup option](/versions/8.1.1/docs/user-manual#startup-options), for example by adding the
     following line in your [`.bazelrc` file](/versions/8.1.1/run/bazelrc):
 
     `startup --host_jvm_args=-Djava.net.preferIPv6Addresses=true`
 
 *   When running Java build targets that need to connect to the internet (such
     as for integration tests), use the
-    `--jvmopt=-Djava.net.preferIPv6Addresses=true` [tool
-    flag](/versions/8.1.1/docs/user-manual#jvmopt). For example, include in your [`.bazelrc`
-    file](/versions/8.1.1/run/bazelrc):
+    `--jvmopt=-Djava.net.preferIPv6Addresses=true` [tool flag](/versions/8.1.1/docs/user-manual#jvmopt). For example, include in your [`.bazelrc` file](/versions/8.1.1/run/bazelrc):
 
     `build --jvmopt=-Djava.net.preferIPv6Addresses`
 
 *   If you are using [`rules_jvm_external`](https://github.com/bazelbuild/rules_jvm_external)
     for dependency version resolution, also add
     `-Djava.net.preferIPv6Addresses=true` to the `COURSIER_OPTS` environment
-    variable to [provide JVM options for
-    Coursier](https://github.com/bazelbuild/rules_jvm_external#provide-jvm-options-for-coursier-with-coursier_opts).
+    variable to [provide JVM options for Coursier](https://github.com/bazelbuild/rules_jvm_external#provide-jvm-options-for-coursier-with-coursier_opts).
 
 ## Offline builds
 
@@ -167,15 +160,12 @@ fetch a file with [`ctx.download`](/versions/8.1.1/rules/lib/builtins/repository
 providing a hash sum of the file needed, Bazel looks for a file matching the
 basename of the first URL, and uses the local copy if the hash matches.
 
-Bazel itself uses this technique to bootstrap offline from the [distribution
-artifact](https://github.com/bazelbuild/bazel-website/blob/master/designs/_posts/2016-10-11-distribution-artifact.md).
-It does so by [collecting all the needed external
-dependencies](https://github.com/bazelbuild/bazel/blob/5cfa0303d6ac3b5bd031ff60272ce80a704af8c2/WORKSPACE#L116)
+Bazel itself uses this technique to bootstrap offline from the [distribution artifact](https://github.com/bazelbuild/bazel-website/blob/master/designs/_posts/2016-10-11-distribution-artifact.md).
+It does so by [collecting all the needed external dependencies](https://github.com/bazelbuild/bazel/blob/5cfa0303d6ac3b5bd031ff60272ce80a704af8c2/WORKSPACE#L116)
 in an internal
 [`distdir_tar`](https://github.com/bazelbuild/bazel/blob/5cfa0303d6ac3b5bd031ff60272ce80a704af8c2/distdir.bzl#L44).
 
 Bazel allows execution of arbitrary commands in repository rules without knowing
 if they call out to the network, and so cannot enforce fully offline builds. To
 test if a build works correctly offline, manually block off the network (as
-Bazel does in its [bootstrap
-test](https://cs.opensource.google/bazel/bazel/+/master:src/test/shell/bazel/BUILD;l=1073;drc=88c426e73cc0eb0a41c0d7995e36acd94e7c9a48)).
\ No newline at end of file
+Bazel does in its [bootstrap test](https://cs.opensource.google/bazel/bazel/+/master:src/test/shell/bazel/BUILD;l=1073;drc=88c426e73cc0eb0a41c0d7995e36acd94e7c9a48)).
\ No newline at end of file
diff --git a/versions/8.1.1/external/images/mod_exampleBefore.svg b/versions/8.1.1/external/images/mod_exampleBefore.svg
new file mode 100644
index 00000000..66f01303
--- /dev/null
+++ b/versions/8.1.1/external/images/mod_exampleBefore.svg
@@ -0,0 +1,175 @@
+
+
+
+
+
+
+mygraph
+
+
+
+<root>
+
+<root> (my_project@1.0)
+
+
+
+bazel_skylib@1.1.1
+
+bazel_skylib@1.1.1
+
+
+
+<root>->bazel_skylib@1.1.1
+
+
+
+
+
+bazel_skylib@1.2.0
+
+bazel_skylib@1.2.0
+
+
+
+<root>->bazel_skylib@1.2.0
+
+
+
+
+
+rules_java@5.0.0
+
+rules_java@5.0.0
+
+
+
+<root>->rules_java@5.0.0
+
+
+
+
+
+stardoc@0.5.0
+
+stardoc@0.5.0
+
+
+
+<root>->stardoc@0.5.0
+
+
+
+
+
+platforms@0.0.4
+
+platforms@0.0.4
+
+
+
+bazel_skylib@1.1.1->platforms@0.0.4
+
+
+
+
+
+bazel_skylib@1.2.0->platforms@0.0.4
+
+
+
+
+
+rules_java@5.0.0->platforms@0.0.4
+
+
+
+
+
+rules_cc@0.0.1
+
+rules_cc@0.0.1
+
+
+
+rules_java@5.0.0->rules_cc@0.0.1
+
+
+
+
+
+rules_proto@4.0.0
+
+rules_proto@4.0.0
+
+
+
+rules_java@5.0.0->rules_proto@4.0.0
+
+
+
+
+
+bazel_skylib@1.0.3
+
+bazel_skylib@1.0.3
+
+
+
+stardoc@0.5.0->bazel_skylib@1.0.3
+
+
+
+
+
+rules_java@4.0.0
+
+rules_java@4.0.0
+
+
+
+stardoc@0.5.0->rules_java@4.0.0
+
+
+
+
+
+rules_cc@0.0.1->platforms@0.0.4
+
+
+
+
+
+rules_cc@0.0.1->bazel_skylib@1.0.3
+
+
+
+
+
+rules_proto@4.0.0->rules_cc@0.0.1
+
+
+
+
+
+rules_proto@4.0.0->bazel_skylib@1.0.3
+
+
+
+
+
+bazel_skylib@1.0.3->platforms@0.0.4
+
+
+
+
+
+rules_java@4.0.0->bazel_skylib@1.0.3
+
+
+
+
+
\ No newline at end of file
diff --git a/versions/8.1.1/external/images/mod_exampleResolved.svg b/versions/8.1.1/external/images/mod_exampleResolved.svg
new file mode 100644
index 00000000..224b694c
--- /dev/null
+++ b/versions/8.1.1/external/images/mod_exampleResolved.svg
@@ -0,0 +1,151 @@
+
+
+
+
+
+
+mygraph
+
+
+
+<root>
+
+<root> (my_project@1.0)
+
+
+
+bazel_skylib@1.1.1
+
+bazel_skylib@1.1.1
+
+
+
+<root>->bazel_skylib@1.1.1
+
+
+
+
+
+bazel_skylib@1.2.0
+
+bazel_skylib@1.2.0
+
+
+
+<root>->bazel_skylib@1.2.0
+
+
+
+
+
+rules_java@5.0.0
+
+rules_java@5.0.0
+
+
+
+<root>->rules_java@5.0.0
+
+
+
+
+
+stardoc@0.5.0
+
+stardoc@0.5.0
+
+
+
+<root>->stardoc@0.5.0
+
+
+
+
+
+platforms@0.0.4
+
+platforms@0.0.4
+
+
+
+bazel_skylib@1.1.1->platforms@0.0.4
+
+
+
+
+
+bazel_skylib@1.2.0->platforms@0.0.4
+
+
+
+
+
+rules_java@5.0.0->platforms@0.0.4
+
+
+
+
+
+rules_cc@0.0.1
+
+rules_cc@0.0.1
+
+
+
+rules_java@5.0.0->rules_cc@0.0.1
+
+
+
+
+
+rules_proto@4.0.0
+
+rules_proto@4.0.0
+
+
+
+rules_java@5.0.0->rules_proto@4.0.0
+
+
+
+
+
+stardoc@0.5.0->bazel_skylib@1.1.1
+
+
+
+
+
+stardoc@0.5.0->rules_java@5.0.0
+
+
+
+
+
+rules_cc@0.0.1->bazel_skylib@1.1.1
+
+
+
+
+
+rules_cc@0.0.1->platforms@0.0.4
+
+
+
+
+
+rules_proto@4.0.0->bazel_skylib@1.1.1
+
+
+
+
+
+rules_proto@4.0.0->rules_cc@0.0.1
+
+
+
+
+
\ No newline at end of file
diff --git a/versions/8.1.1/external/migration.mdx b/versions/8.1.1/external/migration.mdx
index 0474207f..c18cf5d9 100644
--- a/versions/8.1.1/external/migration.mdx
+++ b/versions/8.1.1/external/migration.mdx
@@ -2,8 +2,7 @@
 title: 'Bzlmod Migration Guide'
 ---
 
-Due to the [shortcomings of
-WORKSPACE](/versions/8.1.1/external/overview#workspace-shortcomings), Bzlmod is going to
+Due to the [shortcomings of WORKSPACE](/versions/8.1.1/external/overview#workspace-shortcomings), Bzlmod is going to
 replace the legacy WORKSPACE system. The WORKSPACE file will be disabled by
 default in Bazel 8 (late 2024) and will be removed in Bazel 9 (late 2025).
 This guide helps you migrate your project to Bzlmod and drop WORKSPACE for
@@ -117,9 +116,7 @@ Bazel module when it also adopts Bzlmod.
 
 *   **Bzlmod**
 
-    With Bzlmod, as long as the your dependency is available in [Bazel Central
-    Registry](https://registry.bazel.build) or your custom [Bazel
-    registry](/versions/8.1.1/external/registry), you can simply depend on it with a
+    With Bzlmod, as long as the your dependency is available in [Bazel Central Registry](https://registry.bazel.build) or your custom [Bazel registry](/versions/8.1.1/external/registry), you can simply depend on it with a
     [`bazel_dep`](/versions/8.1.1/rules/lib/globals/module#bazel_dep) directive.
 
     ```python
@@ -150,8 +147,7 @@ repository.
 
 If your dependency is not a Bazel project or not yet available in any Bazel
 registry, you can introduce it using
-[`use_repo_rule`](/versions/8.1.1/external/module#use_repo_rule) or [module
-extensions](/versions/8.1.1/external/extension).
+[`use_repo_rule`](/versions/8.1.1/external/module#use_repo_rule) or [module extensions](/versions/8.1.1/external/extension).
 
 *   **WORKSPACE**
 
@@ -604,8 +600,7 @@ macros.
 Fortunately, the flag
 [`--experimental_repository_resolved_file`][resolved_file_flag]
 can help. This flag essentially generates a "lock file" of all fetched external
-dependencies in your last Bazel command. You can find more details in this [blog
-post](https://blog.bazel.build/2018/07/09/bazel-sync-and-resolved-file.html).
+dependencies in your last Bazel command. You can find more details in this [blog post](https://blog.bazel.build/2018/07/09/bazel-sync-and-resolved-file.html).
 
 [resolved_file_flag]: /reference/command-line-reference#flag--experimental_repository_resolved_file
 
@@ -646,11 +641,9 @@ You may also know `bazel query` can be used for inspecting repository rules with
 bazel query --output=build //external:
 ```
 
-While it is more convenient and much faster, [bazel query can lie about
-external dependency version](https://github.com/bazelbuild/bazel/issues/12947),
+While it is more convenient and much faster, [bazel query can lie about external dependency version](https://github.com/bazelbuild/bazel/issues/12947),
 so be careful using it! Querying and inspecting external
-dependencies with Bzlmod is going to achieved by a [new
-subcommand](https://github.com/bazelbuild/bazel/issues/15365).
+dependencies with Bzlmod is going to achieved by a [new subcommand](https://github.com/bazelbuild/bazel/issues/15365).
 
 #### Built-in default dependencies {#builtin-default-deps}
 
@@ -697,8 +690,7 @@ Using the WORKSPACE.bzlmod file can make the migration easier because:
 #### Repository visibility {#repository-visibility}
 
 Bzlmod is able to control which other repositories are visible from a given
-repository, check [repository names and strict
-deps](/versions/8.1.1/external/module#repository_names_and_strict_deps) for more details.
+repository, check [repository names and strict deps](/versions/8.1.1/external/module#repository_names_and_strict_deps) for more details.
 
 Here is a summary of repository visibilities from different types of
 repositories when also taking WORKSPACE into consideration.
@@ -711,8 +703,7 @@ repositories when also taking WORKSPACE into consideration.
 | WORKSPACE Repos | All visible | Not visible | Not visible | All visible |
 
 Note: For the root module, if a repository `@foo` is defined in WORKSPACE and
-`@foo` is also used as an [apparent repository
-name](/versions/8.1.1/external/overview#apparent-repo-name) in MODULE.bazel, then `@foo`
+`@foo` is also used as an [apparent repository name](/versions/8.1.1/external/overview#apparent-repo-name) in MODULE.bazel, then `@foo`
 refers to the one introduced in MODULE.bazel.
 
 Note: For a module extension generated repository `@bar`, if `@foo` is used as
@@ -787,9 +778,7 @@ the project. Take note of a few things when creating the source archive:
     GitHub isn't going to guarantee the checksum of source archives generated on
     demand. In short, URLs in the form of
     `https://github.com///releases/download/...` is considered stable
-    while `https://github.com///archive/...` is not. Check [GitHub
-    Archive Checksum
-    Outage](https://blog.bazel.build/2023/02/15/github-archive-checksum.html)
+    while `https://github.com///archive/...` is not. Check [GitHub Archive Checksum Outage](https://blog.bazel.build/2023/02/15/github-archive-checksum.html)
     for more context.
 
 *   **Make sure the source tree follows the layout of the original repository.**
@@ -818,8 +807,7 @@ Pull Request.
 
 [bcr_contrib_guide]: https://github.com/bazelbuild/bazel-central-registry/tree/main/docs#contribute-a-bazel-module
 
-It is **highly recommended** to set up the [Publish to
-BCR](https://github.com/bazel-contrib/publish-to-bcr) GitHub App for your
+It is **highly recommended** to set up the [Publish to BCR](https://github.com/bazel-contrib/publish-to-bcr) GitHub App for your
 repository to automate the process of submitting your module to the BCR.
 
 ## Best practices {#best-practices}
diff --git a/versions/8.1.1/external/mod-command.mdx b/versions/8.1.1/external/mod-command.mdx
index e49acc52..9d0ddf44 100644
--- a/versions/8.1.1/external/mod-command.mdx
+++ b/versions/8.1.1/external/mod-command.mdx
@@ -61,11 +61,9 @@ The available subcommands and their respective required arguments are:
 
 *   ``: All present versions of the module ``.
 
-*   `@`: The repo with the given [apparent
-    name](overview#apparent-repo-name) in the context of the `--base_module`.
+*   `@`: The repo with the given [apparent name](/versions/8.1.1/external/overview#apparent-repo-name) in the context of the `--base_module`.
 
-*   `@@`: The repo with the given [canonical
-    name](overview#canonical-repo-name).
+*   `@@`: The repo with the given [canonical name](/versions/8.1.1/external/overview#canonical-repo-name).
 
 In a context requiring specifying modules, ``s referring to repos that
 correspond to modules (as opposed to extension-generated repos) can also be
@@ -87,8 +85,7 @@ The following options only affect the subcommands that print graphs (`graph`,
     information about the version resolution of each module. If the module
     version changed during resolution, show either which version replaced it or
     what was the original version, the reason it was replaced, and which modules
-    requested the new version if the reason was [Minimal Version
-    Selection](module#version-selection).
+    requested the new version if the reason was [Minimal Version Selection](/versions/8.1.1/external/module#version-selection).
 
 *   `--include_unused` *default: "false"*: Include in the output graph the
     modules which were originally present in the dependency graph, but became
@@ -192,7 +189,7 @@ use_repo(toolchains, my_jdk="remotejdk17_linux")
   

     
       

-        Graph Before Resolution
+        Graph Before Resolution
         
Graph Before Resolution

       

 {/* digraph mygraph {
@@ -222,7 +219,7 @@ use_repo(toolchains, my_jdk="remotejdk17_linux")
     		
     
       

-        Graph After Resolution
+        Graph After Resolution
        
Graph After Resolution

       

 {/* digraph mygraph {
diff --git a/versions/8.1.1/external/module.mdx b/versions/8.1.1/external/module.mdx
index 2728ea94..0628b7e3 100644
--- a/versions/8.1.1/external/module.mdx
+++ b/versions/8.1.1/external/module.mdx
@@ -122,8 +122,7 @@ serves multiple purposes:
     version, regardless of which versions of the dependency are requested in the
     dependency graph.
 *   With the `registry` attribute, you can force this dependency to come from a
-    specific registry, instead of following the normal [registry
-    selection](/versions/8.1.1/external/registry#selecting_registries) process.
+    specific registry, instead of following the normal [registry selection](/versions/8.1.1/external/registry#selecting_registries) process.
 *   With the `patch*` attributes, you can specify a set of patches to apply to
     the downloaded module.
 
@@ -176,13 +175,11 @@ With `bazel_dep`, you can define repos that represent other Bazel modules.
 Sometimes there is a need to define a repo that does _not_ represent a Bazel
 module; for example, one that contains a plain JSON file to be read as data.
 
-In this case, you could use the [`use_repo_rule`
-directive](/versions/8.1.1/rules/lib/globals/module#use_repo_rule) to directly define a repo
+In this case, you could use the [`use_repo_rule` directive](/versions/8.1.1/rules/lib/globals/module#use_repo_rule) to directly define a repo
 by invoking a repo rule. This repo will only be visible to the module it's
 defined in.
 
-Under the hood, this is implemented using the same mechanism as [module
-extensions](/versions/8.1.1/external/extension), which lets you define repos with more
+Under the hood, this is implemented using the same mechanism as [module extensions](/versions/8.1.1/external/extension), which lets you define repos with more
 flexibility.
 
 ## Repository names and strict deps
diff --git a/versions/8.1.1/external/overview.mdx b/versions/8.1.1/external/overview.mdx
index f8fbab98..42cf1296 100644
--- a/versions/8.1.1/external/overview.mdx
+++ b/versions/8.1.1/external/overview.mdx
@@ -128,8 +128,7 @@ for all build targets inside the repo.
 
 The syntax of a `REPO.bazel` file is similar to `BUILD` files, except that no
 `load` statements are supported, and only a single function, `repo()`, is
-available. `repo()` takes the same arguments as the [`package()`
-function](/versions/8.1.1/reference/be/functions#package) in `BUILD` files; whereas `package()`
+available. `repo()` takes the same arguments as the [`package()` function](/versions/8.1.1/reference/be/functions#package) in `BUILD` files; whereas `package()`
 specifies common attributes for all build targets inside the package, `repo()`
 analogously does so for all build targets inside the repo.
 
@@ -163,8 +162,7 @@ bazel_dep(name = "protobuf", version = "3.19.0")
 ```
 
 A module must only list its direct dependencies, which Bzlmod looks up in a
-[Bazel registry](/versions/8.1.1/external/registry) — by default, the [Bazel Central
-Registry](https://bcr.bazel.build/). The registry provides the
+[Bazel registry](/versions/8.1.1/external/registry) — by default, the [Bazel Central Registry](https://bcr.bazel.build/). The registry provides the
 dependencies' `MODULE.bazel` files, which allows Bazel to discover the entire
 transitive dependency graph before performing version resolution.
 
@@ -235,5 +233,4 @@ many pain points, including:
         `B` and `C`; `B` and `C` both depend on different versions of `D`).
 
 Due to the shortcomings of WORKSPACE, Bzlmod is going to replace the legacy
-WORKSPACE system in future Bazel releases. Please read the [Bzlmod migration
-guide](/versions/8.1.1/external/migration) on how to migrate to Bzlmod.
+WORKSPACE system in future Bazel releases. Please read the [Bzlmod migration guide](/versions/8.1.1/external/migration) on how to migrate to Bzlmod.
diff --git a/versions/8.1.1/external/registry.mdx b/versions/8.1.1/external/registry.mdx
index ea868c4c..e9ee12ee 100644
--- a/versions/8.1.1/external/registry.mdx
+++ b/versions/8.1.1/external/registry.mdx
@@ -42,8 +42,7 @@ An index registry must follow the format below:
             project
         *   `versions`: A list of all the versions of this module to be found in
             this registry
-        *   `yanked_versions`: A map of [*yanked*
-            versions](/versions/8.1.1/external/module#yanked_versions) of this module. The keys
+        *   `yanked_versions`: A map of [*yanked* versions](/versions/8.1.1/external/module#yanked_versions) of this module. The keys
             should be versions to yank and the values should be descriptions of
             why the version is yanked, ideally containing a link to more
             information
@@ -54,8 +53,7 @@ An index registry must follow the format below:
         *   The default type is "archive", representing an `http_archive` repo,
             with the following fields:
             *   `url`: The URL of the source archive
-            *   `integrity`: The [Subresource
-                Integrity](https://w3c.github.io/webappsec-subresource-integrity/#integrity-metadata-description)
+            *   `integrity`: The [Subresource Integrity](https://w3c.github.io/webappsec-subresource-integrity/#integrity-metadata-description)
                 checksum of the archive
             *   `strip_prefix`: A directory prefix to strip when extracting the
                 source archive
@@ -103,8 +101,7 @@ You can browse its contents using the web frontend at
 https://registry.bazel.build/.
 
 The Bazel community maintains the BCR, and contributors are welcome to submit
-pull requests. See the [BCR contribution
-guidelines](https://github.com/bazelbuild/bazel-central-registry/blob/main/docs/README.md).
+pull requests. See the [BCR contribution guidelines](https://github.com/bazelbuild/bazel-central-registry/blob/main/docs/README.md).
 
 In addition to following the format of a normal index registry, the BCR requires
 a `presubmit.yml` file for each module version
diff --git a/versions/8.1.1/external/vendor.mdx b/versions/8.1.1/external/vendor.mdx
index fe7fc846..8ee7ff04 100644
--- a/versions/8.1.1/external/vendor.mdx
+++ b/versions/8.1.1/external/vendor.mdx
@@ -23,9 +23,7 @@ absolute path.
 ## Vendor a specific external repository {#vendor-specific-repository}
 
 You can use the `vendor` command with the `--repo` flag to specify which repo
-to vendor, it accepts both [canonical repo
-name](/versions/8.1.1/external/overview#canonical-repo-name) and [apparent repo
-name](/versions/8.1.1/external/overview#apparent-repo-name).
+to vendor, it accepts both [canonical repo name](/versions/8.1.1/external/overview#canonical-repo-name) and [apparent repo name](/versions/8.1.1/external/overview#apparent-repo-name).
 
 For example, running:
 
diff --git a/versions/8.1.1/help.mdx b/versions/8.1.1/help.mdx
index 42da6b73..53762c83 100644
--- a/versions/8.1.1/help.mdx
+++ b/versions/8.1.1/help.mdx
@@ -46,5 +46,4 @@ what level of support Bazel provides.
 
 ## File a bug {#file-bug}
 
-If you encounter a bug or want to request a feature, file a [GitHub
-Issue](https://github.com/bazelbuild/bazel/issues).
+If you encounter a bug or want to request a feature, file a [GitHub Issue](https://github.com/bazelbuild/bazel/issues).
diff --git a/versions/8.1.1/images/about.svg b/versions/8.1.1/images/about.svg
new file mode 100644
index 00000000..f927298f
--- /dev/null
+++ b/versions/8.1.1/images/about.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/8.1.1/images/basics.svg b/versions/8.1.1/images/basics.svg
new file mode 100644
index 00000000..013ec519
--- /dev/null
+++ b/versions/8.1.1/images/basics.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/8.1.1/images/bazel_hero.svg b/versions/8.1.1/images/bazel_hero.svg
new file mode 100644
index 00000000..c48714d0
--- /dev/null
+++ b/versions/8.1.1/images/bazel_hero.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/8.1.1/images/community.svg b/versions/8.1.1/images/community.svg
new file mode 100644
index 00000000..29f87a76
--- /dev/null
+++ b/versions/8.1.1/images/community.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/8.1.1/images/distributed-build-remote-cache.png b/versions/8.1.1/images/distributed-build-remote-cache.png
new file mode 100644
index 00000000..99d8a915
Binary files /dev/null and b/versions/8.1.1/images/distributed-build-remote-cache.png differ
diff --git a/versions/8.1.1/images/essential_guide.svg b/versions/8.1.1/images/essential_guide.svg
new file mode 100644
index 00000000..4ee63ae9
--- /dev/null
+++ b/versions/8.1.1/images/essential_guide.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/8.1.1/images/essential_reference.svg b/versions/8.1.1/images/essential_reference.svg
new file mode 100644
index 00000000..4d29a8d5
--- /dev/null
+++ b/versions/8.1.1/images/essential_reference.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/8.1.1/images/essential_start.svg b/versions/8.1.1/images/essential_start.svg
new file mode 100644
index 00000000..c8f48f84
--- /dev/null
+++ b/versions/8.1.1/images/essential_start.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/8.1.1/images/extend.svg b/versions/8.1.1/images/extend.svg
new file mode 100644
index 00000000..77b2dd97
--- /dev/null
+++ b/versions/8.1.1/images/extend.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/8.1.1/images/guide.svg b/versions/8.1.1/images/guide.svg
new file mode 100644
index 00000000..23a5d35a
--- /dev/null
+++ b/versions/8.1.1/images/guide.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/8.1.1/images/high-level-build-system.png b/versions/8.1.1/images/high-level-build-system.png
new file mode 100644
index 00000000..462717fa
Binary files /dev/null and b/versions/8.1.1/images/high-level-build-system.png differ
diff --git a/versions/8.1.1/images/new_1.svg b/versions/8.1.1/images/new_1.svg
new file mode 100644
index 00000000..c4cd9dfd
--- /dev/null
+++ b/versions/8.1.1/images/new_1.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/8.1.1/images/new_2.svg b/versions/8.1.1/images/new_2.svg
new file mode 100644
index 00000000..c6b7021b
--- /dev/null
+++ b/versions/8.1.1/images/new_2.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/8.1.1/images/new_3.svg b/versions/8.1.1/images/new_3.svg
new file mode 100644
index 00000000..c2afb4ac
--- /dev/null
+++ b/versions/8.1.1/images/new_3.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/8.1.1/images/placeholder.png b/versions/8.1.1/images/placeholder.png
new file mode 100644
index 00000000..54f1fa0e
Binary files /dev/null and b/versions/8.1.1/images/placeholder.png differ
diff --git a/versions/8.1.1/images/reference.svg b/versions/8.1.1/images/reference.svg
new file mode 100644
index 00000000..7bbc9bea
--- /dev/null
+++ b/versions/8.1.1/images/reference.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/8.1.1/images/release_notes.svg b/versions/8.1.1/images/release_notes.svg
new file mode 100644
index 00000000..8a2e8b56
--- /dev/null
+++ b/versions/8.1.1/images/release_notes.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/8.1.1/images/remote-execution-system.png b/versions/8.1.1/images/remote-execution-system.png
new file mode 100644
index 00000000..8152fc0c
Binary files /dev/null and b/versions/8.1.1/images/remote-execution-system.png differ
diff --git a/versions/8.1.1/images/start.svg b/versions/8.1.1/images/start.svg
new file mode 100644
index 00000000..3bcebd7b
--- /dev/null
+++ b/versions/8.1.1/images/start.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/8.1.1/images/task-dependencies.png b/versions/8.1.1/images/task-dependencies.png
new file mode 100644
index 00000000..ae1f9c51
Binary files /dev/null and b/versions/8.1.1/images/task-dependencies.png differ
diff --git a/versions/8.1.1/images/test.png b/versions/8.1.1/images/test.png
new file mode 100644
index 00000000..243939da
Binary files /dev/null and b/versions/8.1.1/images/test.png differ
diff --git a/versions/8.1.1/images/transitive-dependencies.png b/versions/8.1.1/images/transitive-dependencies.png
new file mode 100644
index 00000000..ec641a08
Binary files /dev/null and b/versions/8.1.1/images/transitive-dependencies.png differ
diff --git a/versions/8.1.1/images/trunk-logo-dark.svg b/versions/8.1.1/images/trunk-logo-dark.svg
new file mode 100644
index 00000000..f25940af
--- /dev/null
+++ b/versions/8.1.1/images/trunk-logo-dark.svg
@@ -0,0 +1,22 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/versions/8.1.1/images/why_faq.svg b/versions/8.1.1/images/why_faq.svg
new file mode 100644
index 00000000..afec3f8f
--- /dev/null
+++ b/versions/8.1.1/images/why_faq.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/8.1.1/images/why_overview.svg b/versions/8.1.1/images/why_overview.svg
new file mode 100644
index 00000000..c10c363c
--- /dev/null
+++ b/versions/8.1.1/images/why_overview.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/8.1.1/images/why_vision.svg b/versions/8.1.1/images/why_vision.svg
new file mode 100644
index 00000000..739e415f
--- /dev/null
+++ b/versions/8.1.1/images/why_vision.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/8.1.1/install/bazelisk.mdx b/versions/8.1.1/install/bazelisk.mdx
index 241ecf2a..00f5d8fd 100644
--- a/versions/8.1.1/install/bazelisk.mdx
+++ b/versions/8.1.1/install/bazelisk.mdx
@@ -16,8 +16,7 @@ For more details, see
 ## Updating Bazel
 
 Bazel has a [backward compatibility policy](/versions/8.1.1/release/backward-compatibility)
-(see [guidance for rolling out incompatible
-changes](/versions/8.1.1/contribute/breaking-changes) if you
+(see [guidance for rolling out incompatible changes](/versions/8.1.1/contribute/breaking-changes) if you
 are the author of one). That page summarizes best practices on how to test and
 migrate your project with upcoming incompatible changes and how to provide
 feedback to the incompatible change authors.
diff --git a/versions/8.1.1/install/compile-source.mdx b/versions/8.1.1/install/compile-source.mdx
index 03edd11c..d339a270 100644
--- a/versions/8.1.1/install/compile-source.mdx
+++ b/versions/8.1.1/install/compile-source.mdx
@@ -45,8 +45,7 @@ it by typing `bazel` in a terminal.
 
 **Reason**: To build Bazel from a GitHub source tree, you need a pre-existing
 Bazel binary. You can install one from a package manager or download one from
-GitHub. See [Installing Bazel](/versions/8.1.1/install). (Or you can [build from
-scratch (bootstrap)](#bootstrap-bazel).)
+GitHub. See [Installing Bazel](/versions/8.1.1/install). (Or you can [build from scratch (bootstrap)](#bootstrap-bazel).)
 
 **Troubleshooting**:
 
@@ -239,8 +238,7 @@ For instructions for Unix-like systems, see
     ```
 
 *   **The Visual C++ compiler.** Install the Visual C++ compiler either as part
-    of Visual Studio 2015 or newer, or by installing the latest [Build Tools
-    for Visual Studio 2017](https://aka.ms/BuildTools).
+    of Visual Studio 2015 or newer, or by installing the latest [Build Tools for Visual Studio 2017](https://aka.ms/BuildTools).
 
 *   **JDK.** Version 21 is required.
 
diff --git a/versions/8.1.1/install/ide.mdx b/versions/8.1.1/install/ide.mdx
index 561d0e02..c42d95e9 100644
--- a/versions/8.1.1/install/ide.mdx
+++ b/versions/8.1.1/install/ide.mdx
@@ -38,10 +38,8 @@ To install, go to the IDE's plugin browser and search for `Bazel`.
 To manually install older versions, download the zip files from JetBrains'
 Plugin Repository and install the zip file from the IDE's plugin browser:
 
-*  [Android Studio
-   plugin](https://plugins.jetbrains.com/plugin/9185-android-studio-with-bazel)
-*  [IntelliJ
-   plugin](https://plugins.jetbrains.com/plugin/8609-intellij-with-bazel)
+*  [Android Studio plugin](https://plugins.jetbrains.com/plugin/9185-android-studio-with-bazel)
+*  [IntelliJ plugin](https://plugins.jetbrains.com/plugin/8609-intellij-with-bazel)
 *  [CLion plugin](https://plugins.jetbrains.com/plugin/9554-clion-with-bazel)
 
 ### Xcode {#xcode}
@@ -61,8 +59,7 @@ Features:
 * Starlark debugger for `.bzl` files during a build (set breakpoints, step
   through code, inspect variables, and so on)
 
-Find [the plugin on the Visual Studio
-marketplace](https://marketplace.visualstudio.com/items?itemName=BazelBuild.vscode-bazel).
+Find [the plugin on the Visual Studio marketplace](https://marketplace.visualstudio.com/items?itemName=BazelBuild.vscode-bazel).
 The plugin is [open source](https://github.com/bazelbuild/vscode-bazel).
 
 See also: [Autocomplete for Source Code](#autocomplete-for-source-code)
@@ -82,8 +79,7 @@ See also: [Autocomplete for Source Code](#autocomplete-for-source-code)
 
 ### Emacs {#emacs}
 
-See [`bazelbuild/bazel-emacs-mode` on
-GitHub](https://github.com/bazelbuild/emacs-bazel-mode)
+See [`bazelbuild/bazel-emacs-mode` on GitHub](https://github.com/bazelbuild/emacs-bazel-mode)
 
 See also: [Autocomplete for Source Code](#autocomplete-for-source-code)
 
@@ -115,6 +111,5 @@ tool for building Bazel targets when source files change.
 
 ## Building your own IDE plugin {#build-own-plugin}
 
-Read the [**IDE support** blog
-post](https://blog.bazel.build/2016/06/10/ide-support.html) to learn more about
+Read the [**IDE support** blog post](https://blog.bazel.build/2016/06/10/ide-support.html) to learn more about
 the Bazel APIs to use when building an IDE plugin.
diff --git a/versions/8.1.1/install/images/bazelisk.svg b/versions/8.1.1/install/images/bazelisk.svg
new file mode 100644
index 00000000..c0ae9f54
--- /dev/null
+++ b/versions/8.1.1/install/images/bazelisk.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/8.1.1/install/images/cli.svg b/versions/8.1.1/install/images/cli.svg
new file mode 100644
index 00000000..01119280
--- /dev/null
+++ b/versions/8.1.1/install/images/cli.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/8.1.1/install/images/docker.svg b/versions/8.1.1/install/images/docker.svg
new file mode 100644
index 00000000..21190ce0
--- /dev/null
+++ b/versions/8.1.1/install/images/docker.svg
@@ -0,0 +1,6 @@
+
\ No newline at end of file
diff --git a/versions/8.1.1/install/images/github.svg b/versions/8.1.1/install/images/github.svg
new file mode 100644
index 00000000..aa05db9c
--- /dev/null
+++ b/versions/8.1.1/install/images/github.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/8.1.1/install/images/install.svg b/versions/8.1.1/install/images/install.svg
new file mode 100644
index 00000000..ae080865
--- /dev/null
+++ b/versions/8.1.1/install/images/install.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/8.1.1/install/images/mac.svg b/versions/8.1.1/install/images/mac.svg
new file mode 100644
index 00000000..3ee4fe28
--- /dev/null
+++ b/versions/8.1.1/install/images/mac.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/8.1.1/install/images/redhat.svg b/versions/8.1.1/install/images/redhat.svg
new file mode 100644
index 00000000..078b3387
--- /dev/null
+++ b/versions/8.1.1/install/images/redhat.svg
@@ -0,0 +1,69 @@
+
+
+  
+    
+      
+        image/svg+xml
+        
+        
+      
+    
+  
+  
+  
+    
+  
+  
+  
+
diff --git a/versions/8.1.1/install/images/suse.png b/versions/8.1.1/install/images/suse.png
new file mode 100644
index 00000000..6435b689
Binary files /dev/null and b/versions/8.1.1/install/images/suse.png differ
diff --git a/versions/8.1.1/install/images/tune.svg b/versions/8.1.1/install/images/tune.svg
new file mode 100644
index 00000000..8d7d63cb
--- /dev/null
+++ b/versions/8.1.1/install/images/tune.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/8.1.1/install/images/ubuntu.svg b/versions/8.1.1/install/images/ubuntu.svg
new file mode 100644
index 00000000..f217bc8d
--- /dev/null
+++ b/versions/8.1.1/install/images/ubuntu.svg
@@ -0,0 +1,8 @@
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/versions/8.1.1/install/images/windows.svg b/versions/8.1.1/install/images/windows.svg
new file mode 100644
index 00000000..120b0190
--- /dev/null
+++ b/versions/8.1.1/install/images/windows.svg
@@ -0,0 +1,5 @@
+
+
+
+
+
\ No newline at end of file
diff --git a/versions/8.1.1/install/windows.mdx b/versions/8.1.1/install/windows.mdx
index d5d56dd6..00e45c80 100644
--- a/versions/8.1.1/install/windows.mdx
+++ b/versions/8.1.1/install/windows.mdx
@@ -31,8 +31,7 @@ To check your Windows version:
 
 Alternatively you can:
 
-*   [Download the Bazel binary (`bazel-version-windows-x86_64.exe`) from
- GitHub](https://github.com/bazelbuild/bazel/releases).
+*   [Download the Bazel binary (`bazel-version-windows-x86_64.exe`) from GitHub](https://github.com/bazelbuild/bazel/releases).
 *   [Install Bazel from Chocolatey](#chocolately)
 *   [Install Bazel from Scoop](#scoop)
 *   [Build Bazel from source](/versions/8.1.1/install/compile-source)
@@ -208,8 +207,7 @@ If that doesn't help:
     its dependencies, such as the MSYS2 shell. This will not install Visual C++
     though.
 
-See [Chocolatey installation and package maintenance
-guide](/versions/8.1.1/contribute/windows-chocolatey-maintenance) for more
+See [Chocolatey installation and package maintenance guide](/versions/8.1.1/contribute/windows-chocolatey-maintenance) for more
 information about the Chocolatey package.
 
 ### Using Scoop {#scoop}
@@ -226,8 +224,7 @@ information about the Chocolatey package.
     scoop install bazel
     ```
 
-See [Scoop installation and package maintenance
-guide](/versions/8.1.1/contribute/windows-scoop-maintenance) for more
+See [Scoop installation and package maintenance guide](/versions/8.1.1/contribute/windows-scoop-maintenance) for more
 information about the Scoop package.
 
 ### Build from source {#build-from-source}
diff --git a/versions/8.1.1/migrate/maven.mdx b/versions/8.1.1/migrate/maven.mdx
index c86694e2..6b2bff8e 100644
--- a/versions/8.1.1/migrate/maven.mdx
+++ b/versions/8.1.1/migrate/maven.mdx
@@ -19,8 +19,7 @@ directly run by Bazel since there's no Maven compatibility layer.
 ## Before you begin {#before-you-begin}
 
 *   [Install Bazel](/versions/8.1.1/install) if it's not yet installed.
-*   If you're new to Bazel, go through the tutorial [Introduction to Bazel:
-    Build Java](/versions/8.1.1/start/java) before you start migrating. The tutorial explains
+*   If you're new to Bazel, go through the tutorial [Introduction to Bazel: Build Java](/versions/8.1.1/start/java) before you start migrating. The tutorial explains
     Bazel's concepts, structure, and label syntax.
 
 ## Differences between Maven and Bazel {#dif-maven-bazel}
@@ -44,8 +43,7 @@ The steps below describe how to migrate your project to Bazel:
 3.  [Create more BUILD files](#3-build)
 4.  [Build using Bazel](#4-build)
 
-Examples below come from a migration of the [Guava
-project](https://github.com/google/guava) from Maven to Bazel. The
+Examples below come from a migration of the [Guava project](https://github.com/google/guava) from Maven to Bazel. The
 Guava project used is release `v31.1`. The examples using Guava do not walk
 through each step in the migration, but they do show the files and contents that
 are generated or added manually for the migration.
@@ -63,14 +61,12 @@ has no external dependencies, this file can be empty.
 If your project depends on files or packages that are not in one of the
 project's directories, specify these external dependencies in the MODULE.bazel
 file. You can use `rules_jvm_external` to manage dependencies from Maven. For
-instructions about using this ruleset, see [the
-README](https://github.com/bazelbuild/rules_jvm_external/#rules_jvm_external)
+instructions about using this ruleset, see [the README](https://github.com/bazelbuild/rules_jvm_external/#rules_jvm_external)
 .
 
 #### Guava project example: external dependencies {#guava-1}
 
-You can list the external dependencies of the [Guava
-project](https://github.com/google/guava) with the
+You can list the external dependencies of the [Guava project](https://github.com/google/guava) with the
 [`rules_jvm_external`](https://github.com/bazelbuild/rules_jvm_external)
 ruleset.
 
@@ -164,8 +160,7 @@ your build by adding more `BUILD` files with more granular targets.
             *   `resources`: Use globbing to list all resources in your project.
             *   `deps`: You need to determine which external dependencies your
                 project needs.
-        *   Take a look at the [example below of this top-level BUILD
-            file](#guava-2) from the migration of the Guava project.
+        *   Take a look at the [example below of this top-level BUILD file](#guava-2) from the migration of the Guava project.
 
 3.  Now that you have a `BUILD` file at the root of your project, build your
     project to ensure that it works. On the command line, from your workspace
diff --git a/versions/8.1.1/migrate/xcode.mdx b/versions/8.1.1/migrate/xcode.mdx
index 6e5e2c5c..061798d1 100644
--- a/versions/8.1.1/migrate/xcode.mdx
+++ b/versions/8.1.1/migrate/xcode.mdx
@@ -32,8 +32,7 @@ Before you begin, do the following:
 
 1.  [Install Bazel](/versions/8.1.1/install) if you have not already done so.
 
-2.  If you're not familiar with Bazel and its concepts, complete the [iOS app
-    tutorial](/versions/8.1.1/start/ios-app)). You should understand the Bazel workspace,
+2.  If you're not familiar with Bazel and its concepts, complete the [iOS app tutorial](/versions/8.1.1/start/ios-app)). You should understand the Bazel workspace,
     including the `MODULE.bazel` and `BUILD` files, as well as the concepts of
     targets, build rules, and Bazel packages.
 
@@ -44,8 +43,7 @@ Before you begin, do the following:
 Unlike Xcode, Bazel requires you to explicitly declare all dependencies for
 every target in the `BUILD` file.
 
-For more information on external dependencies, see [Working with external
-dependencies](/versions/8.1.1/docs/external).
+For more information on external dependencies, see [Working with external dependencies](/versions/8.1.1/docs/external).
 
 ## Build or test an Xcode project with Bazel {#build-xcode-project}
 
@@ -84,8 +82,7 @@ Note: Place the project source code within the directory tree containing the
 
 To integrate SwiftPM dependencies into the Bazel workspace with
 [swift_bazel](https://github.com/cgrindel/swift_bazel), you must
-convert them into Bazel packages as described in the [following
-tutorial](https://chuckgrindel.com/swift-packages-in-bazel-using-swift_bazel/)
+convert them into Bazel packages as described in the [following tutorial](https://chuckgrindel.com/swift-packages-in-bazel-using-swift_bazel/)
 .
 
 Note: SwiftPM support is a manual process with many variables. SwiftPM
@@ -103,8 +100,7 @@ initial build of the project as follows:
 *   [Step 3b: (Optional) Add the test target(s)](#step-3b-optional-add-the-test-target-s)
 *   [Step 3c: Add the library target(s)](#step-3c-add-the-library-target-s)
 
-**Tip:** To learn more about packages and other Bazel concepts, see [Workspaces,
-packages, and targets](/versions/8.1.1/concepts/build-ref).
+**Tip:** To learn more about packages and other Bazel concepts, see [Workspaces, packages, and targets](/versions/8.1.1/concepts/build-ref).
 
 #### Step 3a: Add the application target {#add-app-target}
 
@@ -132,8 +128,7 @@ In the target, specify the following at the minimum:
 
 #### Step 3b: (Optional) Add the test target(s) {#add-test-target}
 
-Bazel's [Apple build
-rules](https://github.com/bazelbuild/rules_apple) support running
+Bazel's [Apple build rules](https://github.com/bazelbuild/rules_apple) support running
 unit and UI tests on all Apple platforms. Add test targets as follows:
 
 *   [`macos_unit_test`](https://github.com/bazelbuild/rules_apple/blob/master/doc/rules-macos.md#macos_unit_test)
@@ -181,8 +176,7 @@ all sources and/or headers of a certain type. Use it carefully as it might
 include files you do not want Bazel to build.
 
 You can browse existing examples for various types of applications directly in
-the [rules_apple examples
-directory](https://github.com/bazelbuild/rules_apple/tree/master/examples/). For
+the [rules_apple examples directory](https://github.com/bazelbuild/rules_apple/tree/master/examples/). For
 example:
 
 *   [macOS application targets](https://github.com/bazelbuild/rules_apple/tree/master/examples/macos)
@@ -191,8 +185,7 @@ example:
 
 *   [Multi platform applications (macOS, iOS, watchOS, tvOS)](https://github.com/bazelbuild/rules_apple/tree/master/examples/multi_platform)
 
-For more information on build rules, see [Apple Rules for
-Bazel](https://github.com/bazelbuild/rules_apple).
+For more information on build rules, see [Apple Rules for Bazel](https://github.com/bazelbuild/rules_apple).
 
 At this point, it is a good idea to test the build:
 
diff --git a/versions/8.1.1/query/cquery.mdx b/versions/8.1.1/query/cquery.mdx
index 616d9772..079ffd95 100644
--- a/versions/8.1.1/query/cquery.mdx
+++ b/versions/8.1.1/query/cquery.mdx
@@ -6,8 +6,7 @@ title: ' Configurable Query (cquery)'
 [`select()`](/versions/8.1.1/docs/configurable-attributes) and build options' effects on the build
 graph.
 
-It achieves this by running over the results of Bazel's [analysis
-phase](/versions/8.1.1/extending/concepts#evaluation-model),
+It achieves this by running over the results of Bazel's [analysis phase](/versions/8.1.1/extending/concepts#evaluation-model),
 which integrates these effects. `query`, by contrast, runs over the results of
 Bazel's loading phase, before options are evaluated.
 
@@ -137,8 +136,7 @@ $ bazel cquery //foo --universe_scope=//foo,//genrule_with_foo_as_tool
 If you want to precisely declare which instance to query over, use
 the [`config`](#config) function.
 
-See `query`'s [target pattern
-documentation](/versions/8.1.1/query/language#target-patterns) for more information on target patterns.
+See `query`'s [target pattern documentation](/versions/8.1.1/query/language#target-patterns) for more information on target patterns.
 
 ## Functions {#functions}
 
diff --git a/versions/8.1.1/query/images/query_graph1.png b/versions/8.1.1/query/images/query_graph1.png
new file mode 100644
index 00000000..7bc9a61a
Binary files /dev/null and b/versions/8.1.1/query/images/query_graph1.png differ
diff --git a/versions/8.1.1/query/images/query_graph2.png b/versions/8.1.1/query/images/query_graph2.png
new file mode 100644
index 00000000..a0da22ff
Binary files /dev/null and b/versions/8.1.1/query/images/query_graph2.png differ
diff --git a/versions/8.1.1/query/images/query_graph3.png b/versions/8.1.1/query/images/query_graph3.png
new file mode 100644
index 00000000..4418f193
Binary files /dev/null and b/versions/8.1.1/query/images/query_graph3.png differ
diff --git a/versions/8.1.1/query/language.mdx b/versions/8.1.1/query/language.mdx
index 1caa0e8a..10ae32eb 100644
--- a/versions/8.1.1/query/language.mdx
+++ b/versions/8.1.1/query/language.mdx
@@ -1105,8 +1105,7 @@ is being used.
 
 ### On the ordering of results {#results-ordering}
 
-Although query expressions always follow the "[law of
-conservation of graph order](#graph-order)", _presenting_ the results may be done
+Although query expressions always follow the "[law of conservation of graph order](#graph-order)", _presenting_ the results may be done
 in either a dependency-ordered or unordered manner. This does **not**
 influence the targets in the result set or how the query is computed. It only
 affects how the results are printed to stdout. Moreover, nodes that are
@@ -1252,8 +1251,7 @@ and `maxrank` output formats print the labels of each
 target in the resulting graph, but instead of appearing in
 topological order, they appear in rank order, preceded by their
 rank number. These are unaffected by the result ordering
-`--[no]order_results` flag (see [notes on
-the ordering of results](#result-order)).
+`--[no]order_results` flag (see [notes on the ordering of results](#result-order)).
 
 There are two variants of this format: `minrank` ranks
 each node by the length of the shortest path from a root node to it.
diff --git a/versions/8.1.1/query/quickstart.mdx b/versions/8.1.1/query/quickstart.mdx
index 4e30099c..53209c62 100644
--- a/versions/8.1.1/query/quickstart.mdx
+++ b/versions/8.1.1/query/quickstart.mdx
@@ -205,7 +205,7 @@ dot -Tpng < graph.in > graph.png
 ```
 If you open up `graph.png`, you should see something like this. The graph below has been simplified to make the essential path details clearer in this guide.
 
-![Diagram showing a relationship from cafe to chef to the dishes: pizza and mac and cheese which diverges into the separate ingredients: cheese, tomatoes, dough, and macaroni.](images/query_graph1.png "Dependency graph")
+![Diagram showing a relationship from cafe to chef to the dishes: pizza and mac and cheese which diverges into the separate ingredients: cheese, tomatoes, dough, and macaroni.](/versions/8.1.1/query/images/query_graph1.png "Dependency graph")
 
 This helps when you want to see the outputs of the different query functions throughout this guide.
 
@@ -421,7 +421,7 @@ bazel query --noimplicit_deps 'deps(:runner)' --output graph > graph2.in
 dot -Tpng < graph2.in > graph2.png
 ```
 
-[![The same graph as the first one except now there is a spoke stemming from the chef target with smoothie which leads to banana and strawberry](images/query_graph2.png "Updated dependency graph")](images/query_graph2.png)
+[![The same graph as the first one except now there is a spoke stemming from the chef target with smoothie which leads to banana and strawberry](/versions/8.1.1/query/images/query_graph2.png "Updated dependency graph")](/query/images/query_graph2.png)
 
 Looking at `graph2.png`, you can see that `Smoothie` has no shared dependencies with other dishes but is just another target that the `Chef` relies on.
 
@@ -465,7 +465,7 @@ bazel query "allpaths(//src/main/java/com/example/restaurant/..., //src/main/jav
 //src/main/java/com/example/restaurant:chef
 ```
 
-![Output path of cafe to chef to pizza,mac and cheese to cheese](images/query_graph3.png "Output path for dependency")
+![Output path of cafe to chef to pizza,mac and cheese to cheese](/versions/8.1.1/query/images/query_graph3.png "Output path for dependency")
 
 The output of `allpaths()` is a little harder to read as it is a flattened list of the dependencies. Visualizing this graph using Graphviz makes the relationship clearer to understand.
 
diff --git a/versions/8.1.1/reference/be/c-cpp.mdx b/versions/8.1.1/reference/be/c-cpp.mdx
index 05af72fb..65524a4f 100644
--- a/versions/8.1.1/reference/be/c-cpp.mdx
+++ b/versions/8.1.1/reference/be/c-cpp.mdx
@@ -61,7 +61,7 @@ be `main`.
 | `hdrs_check` | String; default is `""` Deprecated, no-op. |
 | `includes` | List of strings; default is `[]` List of include dirs to be added to the compile line. Subject to ["Make variable"](/versions/8.1.1/reference/be/make-variables) substitution. Each string is prepended with the package path and passed to the C++ toolchain for expansion via the "include\_paths" CROSSTOOL feature. A toolchain running on a POSIX system with typical feature definitions will produce `-isystem path_to_package/include_entry`. This should only be used for third-party libraries that do not conform to the Google style of writing #include statements. Unlike [COPTS](#cc_binary.copts), these flags are added for this rule and every rule that depends on it. (Note: not the rules it depends upon!) Be very careful, since this may have far-reaching effects. When in doubt, add "-I" flags to [COPTS](#cc_binary.copts) instead. The added `include` paths will include generated files as well as files in the source tree. |
 | `link_extra_lib` | [Label](/versions/8.1.1/concepts/labels); default is `"@bazel_tools//tools/cpp:link_extra_lib"` Control linking of extra libraries. By default, C++ binaries are linked against `//tools/cpp:link_extra_lib`, which by default depends on the label flag `//tools/cpp:link_extra_libs`. Without setting the flag, this library is empty by default. Setting the label flag allows linking optional dependencies, such as overrides for weak symbols, interceptors for shared library functions, or special runtime libraries (for malloc replacements, prefer `malloc` or `--custom_malloc`). Setting this attribute to `None` disables this behaviour. |
-| `linkopts` | List of strings; default is `[]` Add these flags to the C++ linker command. Subject to ["Make" variable](make-variables) substitution, [Bourne shell tokenization](common-definitions#sh-tokenization) and [label expansion](common-definitions#label-expansion). Each string in this attribute is added to `LINKOPTS` before linking the binary target. Each element of this list that does not start with `$` or `-` is assumed to be the label of a target in `deps`. The list of files generated by that target is appended to the linker options. An error is reported if the label is invalid, or is not declared in `deps`. |
+| `linkopts` | List of strings; default is `[]` Add these flags to the C++ linker command. Subject to ["Make" variable](/versions/8.1.1/reference/be/make-variables) substitution, [Bourne shell tokenization](/versions/8.1.1/reference/be/common-definitions#sh-tokenization) and [label expansion](/versions/8.1.1/reference/be/common-definitions#label-expansion). Each string in this attribute is added to `LINKOPTS` before linking the binary target. Each element of this list that does not start with `$` or `-` is assumed to be the label of a target in `deps`. The list of files generated by that target is appended to the linker options. An error is reported if the label is invalid, or is not declared in `deps`. |
 | `linkshared` | Boolean; default is `False` Create a shared library. To enable this attribute, include `linkshared=True` in your rule. By default this option is off. The presence of this flag means that linking occurs with the `-shared` flag to `gcc`, and the resulting shared library is suitable for loading into for example a Java program. However, for build purposes it will never be linked into the dependent binary, as it is assumed that shared libraries built with a [cc\_binary](#cc_binary) rule are only loaded manually by other programs, so it should not be considered a substitute for the [cc\_library](#cc_library) rule. For sake of scalability we recommend avoiding this approach altogether and simply letting `java_library` depend on `cc_library` rules instead.  If you specify both `linkopts=['-static']` and `linkshared=True`, you get a single completely self-contained unit. If you specify both `linkstatic=True` and `linkshared=True`, you get a single, mostly self-contained unit. |
 | `linkstatic` | Boolean; default is `True` For [`cc_binary`](/versions/8.1.1/reference/be/c-cpp#cc_binary) and [`cc_test`](/versions/8.1.1/reference/be/c-cpp#cc_test): link the binary in static mode. For `cc_library.link_static`: see below. By default this option is on for `cc_binary` and off for the rest.  If enabled and this is a binary or test, this option tells the build tool to link in `.a`'s instead of `.so`'s for user libraries whenever possible. System libraries such as libc (but *not* the C/C++ runtime libraries, see below) are still linked dynamically, as are libraries for which there is no static library. So the resulting executable will still be dynamically linked, hence only *mostly* static.  There are really three different ways to link an executable:   * STATIC with fully\_static\_link feature, in which everything is linked statically;   e.g. "`gcc -static foo.o libbar.a libbaz.a -lm`".    This mode is enabled by specifying `fully_static_link` in the   [`features`](/versions/8.1.1/reference/be/common-definitions#features) attribute. * STATIC, in which all user libraries are linked statically (if a static   version is available), but where system libraries (excluding C/C++ runtime libraries)   are linked dynamically, e.g. "`gcc foo.o libfoo.a libbaz.a -lm`".    This mode is enabled by specifying `linkstatic=True`. * DYNAMIC, in which all libraries are linked dynamically (if a dynamic version is   available), e.g. "`gcc foo.o libfoo.so libbaz.so -lm`".    This mode is enabled by specifying `linkstatic=False`.   If the `linkstatic` attribute or `fully_static_link` in `features` is used outside of `//third_party` please include a comment near the rule to explain why.  The `linkstatic` attribute has a different meaning if used on a [`cc_library()`](/versions/8.1.1/reference/be/c-cpp#cc_library) rule. For a C++ library, `linkstatic=True` indicates that only static linking is allowed, so no `.so` will be produced. linkstatic=False does not prevent static libraries from being created. The attribute is meant to control the creation of dynamic libraries.  There should be very little code built with `linkstatic=False` in production. If `linkstatic=False`, then the build tool will create symlinks to depended-upon shared libraries in the `*.runfiles` area. |
 | `local_defines` | List of strings; default is `[]` List of defines to add to the compile line. Subject to ["Make" variable](/versions/8.1.1/reference/be/make-variables) substitution and [Bourne shell tokenization](/versions/8.1.1/reference/be/common-definitions#sh-tokenization). Each string, which must consist of a single Bourne shell token, is prepended with `-D` and added to the compile command line for this target, but not to its dependents. |
@@ -229,7 +229,7 @@ cc_import(
 | `alwayslink` | Boolean; default is `False` If 1, any binary that depends (directly or indirectly) on this C++ precompiled library will link in all the object files archived in the static library, even if some contain no symbols referenced by the binary. This is useful if your code isn't explicitly called by code in the binary, e.g., if your code registers to receive some callback provided by some service. If alwayslink doesn't work with VS 2017 on Windows, that is due to a [known issue](https://github.com/bazelbuild/bazel/issues/3949), please upgrade your VS 2017 to the latest version. |
 | `includes` | List of strings; default is `[]` List of include dirs to be added to the compile line. Subject to ["Make variable"](/versions/8.1.1/reference/be/make-variables) substitution. Each string is prepended with the package path and passed to the C++ toolchain for expansion via the "include\_paths" CROSSTOOL feature. A toolchain running on a POSIX system with typical feature definitions will produce `-isystem path_to_package/include_entry`. This should only be used for third-party libraries that do not conform to the Google style of writing #include statements. Unlike [COPTS](#cc_binary.copts), these flags are added for this rule and every rule that depends on it. (Note: not the rules it depends upon!) Be very careful, since this may have far-reaching effects. When in doubt, add "-I" flags to [COPTS](#cc_binary.copts) instead. The default `include` path doesn't include generated files. If you need to `#include` a generated header file, list it in the `srcs`. |
 | `interface_library` | [Label](/versions/8.1.1/concepts/labels); default is `None` A single interface library for linking the shared library. Permitted file types: `.ifso`, `.tbd`, `.lib`, `.so` or `.dylib` |
-| `linkopts` | List of strings; default is `[]` Add these flags to the C++ linker command. Subject to ["Make" variable](make-variables) substitution, [Bourne shell tokenization](common-definitions#sh-tokenization) and [label expansion](common-definitions#label-expansion). Each string in this attribute is added to `LINKOPTS` before linking the binary target. Each element of this list that does not start with `$` or `-` is assumed to be the label of a target in `deps`. The list of files generated by that target is appended to the linker options. An error is reported if the label is invalid, or is not declared in `deps`. |
+| `linkopts` | List of strings; default is `[]` Add these flags to the C++ linker command. Subject to ["Make" variable](/versions/8.1.1/reference/be/make-variables) substitution, [Bourne shell tokenization](/versions/8.1.1/reference/be/common-definitions#sh-tokenization) and [label expansion](/versions/8.1.1/reference/be/common-definitions#label-expansion). Each string in this attribute is added to `LINKOPTS` before linking the binary target. Each element of this list that does not start with `$` or `-` is assumed to be the label of a target in `deps`. The list of files generated by that target is appended to the linker options. An error is reported if the label is invalid, or is not declared in `deps`. |
 | `objects` | List of [labels](/versions/8.1.1/concepts/labels); default is `[]` |
 | `pic_objects` | List of [labels](/versions/8.1.1/concepts/labels); default is `[]` |
 | `pic_static_library` | [Label](/versions/8.1.1/concepts/labels); default is `None` |
@@ -453,7 +453,7 @@ cc_library(
 | `implementation_deps` | List of [labels](/versions/8.1.1/concepts/labels); default is `[]` The list of other libraries that the library target depends on. Unlike with `deps`, the headers and include paths of these libraries (and all their transitive deps) are only used for compilation of this library, and not libraries that depend on it. Libraries specified with `implementation_deps` are still linked in binary targets that depend on this library. |
 | `include_prefix` | String; default is `""` The prefix to add to the paths of the headers of this rule. When set, the headers in the `hdrs` attribute of this rule are accessible at is the value of this attribute prepended to their repository-relative path. The prefix in the `strip_include_prefix` attribute is removed before this prefix is added. This attribute is only legal under `third_party`. |
 | `includes` | List of strings; default is `[]` List of include dirs to be added to the compile line. Subject to ["Make variable"](/versions/8.1.1/reference/be/make-variables) substitution. Each string is prepended with the package path and passed to the C++ toolchain for expansion via the "include\_paths" CROSSTOOL feature. A toolchain running on a POSIX system with typical feature definitions will produce `-isystem path_to_package/include_entry`. This should only be used for third-party libraries that do not conform to the Google style of writing #include statements. Unlike [COPTS](#cc_binary.copts), these flags are added for this rule and every rule that depends on it. (Note: not the rules it depends upon!) Be very careful, since this may have far-reaching effects. When in doubt, add "-I" flags to [COPTS](#cc_binary.copts) instead. The added `include` paths will include generated files as well as files in the source tree. |
-| `linkopts` | List of strings; default is `[]` See [`cc_binary.linkopts`](/versions/8.1.1/reference/be/c-cpp#cc_binary.linkopts). The `linkopts` attribute is also applied to any target that depends, directly or indirectly, on this library via `deps` attributes (or via other attributes that are treated similarly: the [`malloc`](/versions/8.1.1/reference/be/c-cpp#cc_binary.malloc) attribute of [`cc_binary`](/versions/8.1.1/reference/be/c-cpp#cc_binary)). Dependency linkopts take precedence over dependent linkopts (i.e. dependency linkopts appear later in the command line). Linkopts specified in [`--linkopt`](../user-manual#flag--linkopt) take precedence over rule linkopts. |
+| `linkopts` | List of strings; default is `[]` See [`cc_binary.linkopts`](/versions/8.1.1/reference/be/c-cpp#cc_binary.linkopts). The `linkopts` attribute is also applied to any target that depends, directly or indirectly, on this library via `deps` attributes (or via other attributes that are treated similarly: the [`malloc`](/versions/8.1.1/reference/be/c-cpp#cc_binary.malloc) attribute of [`cc_binary`](/versions/8.1.1/reference/be/c-cpp#cc_binary)). Dependency linkopts take precedence over dependent linkopts (i.e. dependency linkopts appear later in the command line). Linkopts specified in [`--linkopt`](/versions/8.1.1/reference/user-manual#flag--linkopt) take precedence over rule linkopts. |
 
 Note that the `linkopts` attribute only applies
 when creating `.so` files or executables, not
@@ -736,7 +736,7 @@ that `cc_test` has extra [attributes common to all test rules (\*\_test)](/versi
 | `hdrs_check` | String; default is `""` Deprecated, no-op. |
 | `includes` | List of strings; default is `[]` List of include dirs to be added to the compile line. Subject to ["Make variable"](/versions/8.1.1/reference/be/make-variables) substitution. Each string is prepended with the package path and passed to the C++ toolchain for expansion via the "include\_paths" CROSSTOOL feature. A toolchain running on a POSIX system with typical feature definitions will produce `-isystem path_to_package/include_entry`. This should only be used for third-party libraries that do not conform to the Google style of writing #include statements. Unlike [COPTS](#cc_binary.copts), these flags are added for this rule and every rule that depends on it. (Note: not the rules it depends upon!) Be very careful, since this may have far-reaching effects. When in doubt, add "-I" flags to [COPTS](#cc_binary.copts) instead. The added `include` paths will include generated files as well as files in the source tree. |
 | `link_extra_lib` | [Label](/versions/8.1.1/concepts/labels); default is `"@bazel_tools//tools/cpp:link_extra_lib"` Control linking of extra libraries. By default, C++ binaries are linked against `//tools/cpp:link_extra_lib`, which by default depends on the label flag `//tools/cpp:link_extra_libs`. Without setting the flag, this library is empty by default. Setting the label flag allows linking optional dependencies, such as overrides for weak symbols, interceptors for shared library functions, or special runtime libraries (for malloc replacements, prefer `malloc` or `--custom_malloc`). Setting this attribute to `None` disables this behaviour. |
-| `linkopts` | List of strings; default is `[]` Add these flags to the C++ linker command. Subject to ["Make" variable](make-variables) substitution, [Bourne shell tokenization](common-definitions#sh-tokenization) and [label expansion](common-definitions#label-expansion). Each string in this attribute is added to `LINKOPTS` before linking the binary target. Each element of this list that does not start with `$` or `-` is assumed to be the label of a target in `deps`. The list of files generated by that target is appended to the linker options. An error is reported if the label is invalid, or is not declared in `deps`. |
+| `linkopts` | List of strings; default is `[]` Add these flags to the C++ linker command. Subject to ["Make" variable](/versions/8.1.1/reference/be/make-variables) substitution, [Bourne shell tokenization](/versions/8.1.1/reference/be/common-definitions#sh-tokenization) and [label expansion](/versions/8.1.1/reference/be/common-definitions#label-expansion). Each string in this attribute is added to `LINKOPTS` before linking the binary target. Each element of this list that does not start with `$` or `-` is assumed to be the label of a target in `deps`. The list of files generated by that target is appended to the linker options. An error is reported if the label is invalid, or is not declared in `deps`. |
 | `linkshared` | Boolean; default is `False` Create a shared library. To enable this attribute, include `linkshared=True` in your rule. By default this option is off. The presence of this flag means that linking occurs with the `-shared` flag to `gcc`, and the resulting shared library is suitable for loading into for example a Java program. However, for build purposes it will never be linked into the dependent binary, as it is assumed that shared libraries built with a [cc\_binary](#cc_binary) rule are only loaded manually by other programs, so it should not be considered a substitute for the [cc\_library](#cc_library) rule. For sake of scalability we recommend avoiding this approach altogether and simply letting `java_library` depend on `cc_library` rules instead.  If you specify both `linkopts=['-static']` and `linkshared=True`, you get a single completely self-contained unit. If you specify both `linkstatic=True` and `linkshared=True`, you get a single, mostly self-contained unit. |
 | `linkstatic` | Boolean; default is `False` For [`cc_binary`](/versions/8.1.1/reference/be/c-cpp#cc_binary) and [`cc_test`](/versions/8.1.1/reference/be/c-cpp#cc_test): link the binary in static mode. For `cc_library.link_static`: see below. By default this option is on for `cc_binary` and off for the rest.  If enabled and this is a binary or test, this option tells the build tool to link in `.a`'s instead of `.so`'s for user libraries whenever possible. System libraries such as libc (but *not* the C/C++ runtime libraries, see below) are still linked dynamically, as are libraries for which there is no static library. So the resulting executable will still be dynamically linked, hence only *mostly* static.  There are really three different ways to link an executable:   * STATIC with fully\_static\_link feature, in which everything is linked statically;   e.g. "`gcc -static foo.o libbar.a libbaz.a -lm`".    This mode is enabled by specifying `fully_static_link` in the   [`features`](/versions/8.1.1/reference/be/common-definitions#features) attribute. * STATIC, in which all user libraries are linked statically (if a static   version is available), but where system libraries (excluding C/C++ runtime libraries)   are linked dynamically, e.g. "`gcc foo.o libfoo.a libbaz.a -lm`".    This mode is enabled by specifying `linkstatic=True`. * DYNAMIC, in which all libraries are linked dynamically (if a dynamic version is   available), e.g. "`gcc foo.o libfoo.so libbaz.so -lm`".    This mode is enabled by specifying `linkstatic=False`.   If the `linkstatic` attribute or `fully_static_link` in `features` is used outside of `//third_party` please include a comment near the rule to explain why.  The `linkstatic` attribute has a different meaning if used on a [`cc_library()`](/versions/8.1.1/reference/be/c-cpp#cc_library) rule. For a C++ library, `linkstatic=True` indicates that only static linking is allowed, so no `.so` will be produced. linkstatic=False does not prevent static libraries from being created. The attribute is meant to control the creation of dynamic libraries.  There should be very little code built with `linkstatic=False` in production. If `linkstatic=False`, then the build tool will create symlinks to depended-upon shared libraries in the `*.runfiles` area. |
 | `local_defines` | List of strings; default is `[]` List of defines to add to the compile line. Subject to ["Make" variable](/versions/8.1.1/reference/be/make-variables) substitution and [Bourne shell tokenization](/versions/8.1.1/reference/be/common-definitions#sh-tokenization). Each string, which must consist of a single Bourne shell token, is prepended with `-D` and added to the compile command line for this target, but not to its dependents. |
diff --git a/versions/8.1.1/reference/be/common-definitions.mdx b/versions/8.1.1/reference/be/common-definitions.mdx
index a65184c5..e9938640 100644
--- a/versions/8.1.1/reference/be/common-definitions.mdx
+++ b/versions/8.1.1/reference/be/common-definitions.mdx
@@ -75,11 +75,11 @@ rules.
 | `deprecation` | String; [nonconfigurable](#configurable-attributes); default is `None`  An explanatory warning message associated with this target. Typically this is used to notify users that a target has become obsolete, or has become superseded by another rule, is private to a package, or is perhaps considered harmful for some reason. It is a good idea to include some reference (like a webpage, a bug number or example migration CLs) so that one can easily find out what changes are required to avoid the message. If there is a new target that can be used as a drop in replacement, it is a good idea to just migrate all users of the old target.  This attribute has no effect on the way things are built, but it may affect a build tool's diagnostic output. The build tool issues a warning when a rule with a `deprecation` attribute is depended upon by a target in another package.  Intra-package dependencies are exempt from this warning, so that, for example, building the tests of a deprecated rule does not encounter a warning.  If a deprecated target depends on another deprecated target, no warning message is issued.  Once people have stopped using it, the target can be removed. |
 | `distribs` | List of strings; [nonconfigurable](#configurable-attributes); default is `[]`  A list of distribution-method strings to be used for this particular target. This is part of a deprecated licensing API that Bazel no longer uses. Don't use this. |
 | `exec_compatible_with` | List of [labels](/versions/8.1.1/concepts/labels); [nonconfigurable](#configurable-attributes); default is `[]`  A list of `constraint_values` that must be present in the execution platform for this target. This is in addition to any constraints already set by the rule type. Constraints are used to restrict the list of available execution platforms. For more details, see the description of [toolchain resolution](/versions/8.1.1/docs/toolchains#toolchain-resolution). |
-| `exec_properties` | Dictionary of strings; default is `{}`  A dictionary of strings that will be added to the `exec_properties` of a platform selected for this target. See `exec_properties` of the [platform](platforms-and-toolchains#platform) rule.  If a key is present in both the platform and target-level properties, the value will be taken from the target. |
+| `exec_properties` | Dictionary of strings; default is `{}`  A dictionary of strings that will be added to the `exec_properties` of a platform selected for this target. See `exec_properties` of the [platform](/versions/8.1.1/reference/be/platforms-and-toolchains#platform) rule.  If a key is present in both the platform and target-level properties, the value will be taken from the target. |
 | `features` | List of *feature* strings; default is `[]`  A feature is string tag that can be enabled or disabled on a target. The meaning of a feature depends on the rule itself.  This `features` attribute is combined with the [package](/versions/8.1.1/reference/be/functions#package) level `features` attribute. For example, if the features ["a", "b"] are enabled on the package level, and a target's `features` attribute contains ["-a", "c"], the features enabled for the rule will be "b" and "c". [See example](https://github.com/bazelbuild/examples/blob/main/rules/features/BUILD). |
 | `restricted_to` | List of [labels](/versions/8.1.1/concepts/labels); [nonconfigurable](#configurable-attributes); default is `[]`  The list of environments this target can be built for, *instead* of default-supported environments.  This is part of Bazel's constraint system. See `compatible_with` for details. |
 | `tags` | List of strings; [nonconfigurable](#configurable-attributes); default is `[]`  *Tags* can be used on any rule. *Tags* on test and `test_suite` rules are useful for categorizing the tests. *Tags* on non-test targets are used to control sandboxed execution of `genrule`s and [Starlark](/versions/8.1.1/rules/concepts) actions, and for parsing by humans and/or external tools.  Bazel modifies the behavior of its sandboxing code if it finds the following keywords in the `tags` attribute of any test or `genrule` target, or the keys of `execution_requirements` for any Starlark action.   * `no-sandbox` keyword results in the action or test never being   sandboxed; it can still be cached or run remotely - use `no-cache`   or `no-remote` to prevent either or both of those. * `no-cache` keyword results in the action or test never being   cached (locally or remotely). Note: for the purposes of this tag, the disk cache   is considered a local cache, whereas the HTTP and gRPC caches are considered   remote. Other caches, such as Skyframe or the persistent action cache, are not   affected. * `no-remote-cache` keyword results in the action or test never being   cached remotely (but it may be cached locally; it may also be executed remotely).   Note: for the purposes of this tag, the disk cache is considered a local cache,   whereas the HTTP and gRPC caches are considered remote. Other caches, such as   Skyframe or the persistent action cache, are not affected.   If a combination of local disk cache and remote cache are used (combined cache),   it's treated as a remote cache and disabled entirely unless `--incompatible_remote_results_ignore_disk`   is set in which case the local components will be used. * `no-remote-exec` keyword results in the action or test never being   executed remotely (but it may be cached remotely). * `no-remote` keyword prevents the action or test from being executed remotely or   cached remotely. This is equivalent to using both   `no-remote-cache` and `no-remote-exec`. * `no-remote-cache-upload` keyword disables upload part of remote caching of a spawn.   it does not disable remote execution. * `local` keyword precludes the action or test from being remotely cached,   remotely executed, or run inside the sandbox.   For genrules and tests, marking the rule with the `local = True`   attribute has the same effect. * `requires-network` keyword allows access to the external   network from inside the sandbox. This tag only has an effect if sandboxing   is enabled. * `block-network` keyword blocks access to the external   network from inside the sandbox. In this case, only communication   with localhost is allowed. This tag only has an effect if sandboxing is   enabled. * `requires-fakeroot` runs the test or action as uid and gid 0 (i.e., the root   user). This is only supported on Linux. This tag takes precedence over the   `--sandbox_fake_username` command-line option.   *Tags* on tests are generally used to annotate a test's role in your debug and release process. Typically, tags are most useful for C++ and Python tests, which lack any runtime annotation ability. The use of tags and size elements gives flexibility in assembling suites of tests based around codebase check-in policy.  Bazel modifies test running behavior if it finds the following keywords in the `tags` attribute of the test rule:   * `exclusive` will force the test to be run in the   "exclusive" mode, ensuring that no other tests are running at the   same time. Such tests will be executed in serial fashion after all build   activity and non-exclusive tests have been completed. Remote execution is   disabled for such tests because Bazel doesn't have control over what's   running on a remote machine. * `exclusive-if-local` will force the test to be run in the   "exclusive" mode if it is executed locally, but will run the test in parallel if it's   executed remotely. * `manual` keyword will exclude the target from expansion of target pattern wildcards   (`...`, `:*`, `:all`, etc.) and `test_suite` rules   which do not list the test explicitly when computing the set of top-level targets to build/run   for the `build`, `test`, and `coverage` commands. It does not   affect target wildcard or test suite expansion in other contexts, including the   `query` command. Note that `manual` does not imply that a target should   not be built/run automatically by continuous build/test systems. For example, it may be   desirable to exclude a target from `bazel test ...` because it requires specific   Bazel flags, but still have it included in properly-configured presubmit or continuous test   runs. * `external` keyword will force test to be unconditionally   executed (regardless of `--cache_test_results`   value).  See [Tag Conventions](/versions/8.1.1/reference/test-encyclopedia#tag-conventions) in the Test Encyclopedia for more conventions on tags attached to test targets. |
-| `target_compatible_with` | List of [labels](/versions/8.1.1/concepts/labels); default is `[]`  A list of `constraint_value`s that must be present in the target platform for this target to be considered *compatible*. This is in addition to any constraints already set by the rule type. If the target platform does not satisfy all listed constraints then the target is considered *incompatible*. Incompatible targets are skipped for building and testing when the target pattern is expanded (e.g. `//...`, `:all`). When explicitly specified on the command line, incompatible targets cause Bazel to print an error and cause a build or test failure.  Targets that transitively depend on incompatible targets are themselves considered incompatible. They are also skipped for building and testing.  An empty list (which is the default) signifies that the target is compatible with all platforms. All rules other than [Workspace Rules](workspace) support this attribute. For some rules this attribute has no effect. For example, specifying `target_compatible_with` for a `cc_toolchain` is not useful. See the [Platforms](/versions/8.1.1/docs/platforms#skipping-incompatible-targets) page for more information about incompatible target skipping. |
+| `target_compatible_with` | List of [labels](/versions/8.1.1/concepts/labels); default is `[]`  A list of `constraint_value`s that must be present in the target platform for this target to be considered *compatible*. This is in addition to any constraints already set by the rule type. If the target platform does not satisfy all listed constraints then the target is considered *incompatible*. Incompatible targets are skipped for building and testing when the target pattern is expanded (e.g. `//...`, `:all`). When explicitly specified on the command line, incompatible targets cause Bazel to print an error and cause a build or test failure.  Targets that transitively depend on incompatible targets are themselves considered incompatible. They are also skipped for building and testing.  An empty list (which is the default) signifies that the target is compatible with all platforms. All rules other than [Workspace Rules](/versions/8.1.1/reference/be/workspace) support this attribute. For some rules this attribute has no effect. For example, specifying `target_compatible_with` for a `cc_toolchain` is not useful. See the [Platforms](/versions/8.1.1/docs/platforms#skipping-incompatible-targets) page for more information about incompatible target skipping. |
 | `testonly` | Boolean; [nonconfigurable](#configurable-attributes); default is `False` except for test and test suite targets  If `True`, only testonly targets (such as tests) can depend on this target.  Equivalently, a rule that is not `testonly` is not allowed to depend on any rule that is `testonly`.  Tests (`*_test` rules) and test suites ([test\_suite](/versions/8.1.1/reference/be/general#test_suite) rules) are `testonly` by default.  This attribute is intended to mean that the target should not be contained in binaries that are released to production.  Because testonly is enforced at build time, not run time, and propagates virally through the dependency tree, it should be applied judiciously. For example, stubs and fakes that are useful for unit tests may also be useful for integration tests involving the same binaries that will be released to production, and therefore should probably not be marked testonly. Conversely, rules that are dangerous to even link in, perhaps because they unconditionally override normal behavior, should definitely be marked testonly. |
 | `toolchains` | List of [labels](/versions/8.1.1/concepts/labels); [nonconfigurable](#configurable-attributes); default is `[]`  The set of targets whose [Make variables](/versions/8.1.1/reference/be/make-variables) this target is allowed to access. These targets are either instances of rules that provide `TemplateVariableInfo` or special targets for toolchain types built into Bazel. These include:  * `@bazel_tools//tools/cpp:current_cc_toolchain`* `@rules_java//toolchains:current_java_runtime`   Note that this is distinct from the concept of [toolchain resolution](/versions/8.1.1/docs/toolchains#toolchain-resolution) that is used by rule implementations for platform-dependent configuration. You cannot use this attribute to determine which specific `cc_toolchain` or `java_toolchain` a target will use. |
 | `visibility` | List of [labels](/versions/8.1.1/concepts/labels); [nonconfigurable](#configurable-attributes); default varies  The `visibility` attribute controls whether the target can be depended on by targets in other locations. See the documentation for [visibility](/versions/8.1.1/concepts/visibility).  For targets declared directly in a BUILD file or in legacy macros called from a BUILD file, the default value is the package's `default_visibility` if specified, or else `["//visibility:private"]`. For targets declared in one or more symbolic macros, the default value is always just `["//visibility:private"]` (which makes it useable only within the package containing the macro's code). |
diff --git a/versions/8.1.1/reference/be/functions.mdx b/versions/8.1.1/reference/be/functions.mdx
index 0ecf43a4..395c3d67 100644
--- a/versions/8.1.1/reference/be/functions.mdx
+++ b/versions/8.1.1/reference/be/functions.mdx
@@ -34,9 +34,9 @@ file, before any rule.
 | --- | --- |
 | `default_applicable_licenses` | Alias for [`default_package_metadata`](#package.default_package_metadata). |
 | `default_visibility` | List of [labels](/versions/8.1.1/concepts/labels); default is `[]`  The default visibility of the top-level rule targets and symbolic macros in this package — that is, the targets and symbolic macros that are not themselves declared inside a symbolic macro. This attribute is ignored if the target or macro specifies a `visibility` value.  For detailed information about the syntax of this attribute, see the documentation of [visibility](/versions/8.1.1/concepts/visibility). The package default visibility does not apply to [exports\_files](#exports_files), which is public by default. |
-| `default_deprecation` | String; default is `""`  Sets the default [`deprecation`](common-definitions#common.deprecation) message for all rules in this package. |
+| `default_deprecation` | String; default is `""`  Sets the default [`deprecation`](/versions/8.1.1/reference/be/common-definitions#common.deprecation) message for all rules in this package. |
 | `default_package_metadata` | List of [labels](/versions/8.1.1/concepts/labels); default is `[]`  Sets a default list of metadata targets which apply to all other targets in the package. These are typically targets related to OSS package and license declarations. See [rules\_license](https://github.com/bazelbuild/rules_license) for examples. |
-| `default_testonly` | Boolean; default is `False` except as noted  Sets the default [`testonly`](common-definitions#common.testonly) property for all rules in this package.  In packages under `javatests` the default value is `True`. |
+| `default_testonly` | Boolean; default is `False` except as noted  Sets the default [`testonly`](/versions/8.1.1/reference/be/common-definitions#common.testonly) property for all rules in this package.  In packages under `javatests` the default value is `True`. |
 | `features` | List strings; default is `[]`  Sets various flags that affect the semantics of this BUILD file.  This feature is mainly used by the people working on the build system to tag packages that need some kind of special handling. Do not use this unless explicitly requested by someone working on the build system. |
 
 ### Examples
@@ -66,7 +66,7 @@ visible target can only be referenced within its own package (not subpackages).
 In between these extremes, a target may allow access to its own package plus any
 of the packages described by one or more package groups. For a more detailed
 explanation of the visibility system, see the
-[visibility](common-definitions#common.visibility)
+[visibility](/versions/8.1.1/reference/be/common-definitions#common.visibility)
 attribute.
 
 A given package is considered to be in the group if it either matches the
@@ -159,7 +159,7 @@ visibility declaration can also be specified; in this case, the files will be
 visible to the targets specified. If no visibility is specified, the files
 will be visible to every package, even if a package default visibility was
 specified in the `package`
-function. The [licenses](common-definitions#common.licenses)
+function. The [licenses](/versions/8.1.1/reference/be/common-definitions#common.licenses)
 can also be specified.
 
 ### Example
@@ -262,8 +262,7 @@ There are several important limitations and caveats:
    package called "Foo.java" (which is allowed, though Bazel warns about it),
    then the consumer of the `glob()` will use the "Foo.java" rule
    (its outputs) instead of the "Foo.java" file. See
-   [GitHub
-   issue #10395](https://github.com/bazelbuild/bazel/issues/10395#issuecomment-583714657) for more details.
+   [GitHub issue #10395](https://github.com/bazelbuild/bazel/issues/10395#issuecomment-583714657) for more details.
 3. Globs may match files in subdirectories. And subdirectory names
    may be wildcarded. However...
 4. Labels are not allowed to cross the package boundary and glob does
@@ -409,7 +408,7 @@ select(
 ```
 
 `select()` is the helper function that makes a rule attribute
-[configurable](common-definitions#configurable-attributes).
+[configurable](/versions/8.1.1/reference/be/common-definitions#configurable-attributes).
 It can replace the right-hand side of
 *almost*
 any attribute assignment so its value depends on command-line Bazel flags.
diff --git a/versions/8.1.1/reference/be/general.mdx b/versions/8.1.1/reference/be/general.mdx
index ef4b2f60..22ba9115 100644
--- a/versions/8.1.1/reference/be/general.mdx
+++ b/versions/8.1.1/reference/be/general.mdx
@@ -158,9 +158,9 @@ some build targets.
   [here](/versions/8.1.1/reference/be/common-definitions#configurable-attributes) for more discussion.
 * Avoid repeating identical `config_setting` definitions in different packages.
   Instead, reference a common `config_setting` that defined in a canonical package.
-* [`values`](general#config_setting.values),
-  [`define_values`](general#config_setting.define_values), and
-  [`constraint_values`](general#config_setting.constraint_values)
+* [`values`](/versions/8.1.1/reference/be/general#config_setting.values),
+  [`define_values`](/versions/8.1.1/reference/be/general#config_setting.define_values), and
+  [`constraint_values`](/versions/8.1.1/reference/be/general#config_setting.constraint_values)
   can be used in any combination in the same `config_setting` but at least one must
   be set for any given `config_setting`.
 
@@ -169,10 +169,10 @@ some build targets.
 | Attributes | |
 | --- | --- |
 | `name` | [Name](/versions/8.1.1/concepts/labels#target-names); required  A unique name for this target. |
-| `constraint_values` | List of [labels](/versions/8.1.1/concepts/labels); [nonconfigurable](common-definitions#configurable-attributes); default is `[]` The minimum set of `constraint_values` that the target platform must specify in order to match this `config_setting`. (The execution platform is not considered here.) Any additional constraint values that the platform has are ignored. See [Configurable Build Attributes](https://bazel.build/versions/8.1.1/docs/configurable-attributes#platforms) for details. If two `config_setting`s match in the same `select` and one has all the same flags and `constraint_setting`s as the other plus additional ones, the one with more settings is chosen. This is known as "specialization". For example, a `config_setting` matching `x86` and `Linux` specializes a `config_setting` matching `x86`. If two `config_setting`s match and both have `constraint_value`s not present in the other, this is an error. |
-| `define_values` | Dictionary: String -> String; [nonconfigurable](common-definitions#configurable-attributes); default is `{}` The same as [`values`](/versions/8.1.1/reference/be/general#config_setting.values) but specifically for the `--define` flag. `--define` is special because its syntax (`--define KEY=VAL`) means `KEY=VAL` is a *value* from a Bazel flag perspective.  That means:  ```             config_setting(                 name = "a_and_b",                 values = {                     "define": "a=1",                     "define": "b=2",                 }) ```   doesn't work because the same key (`define`) appears twice in the dictionary. This attribute solves that problem:  ```             config_setting(                 name = "a_and_b",                 define_values = {                     "a": "1",                     "b": "2",                 }) ```   correctly matches `bazel build //foo --define a=1 --define b=2`. `--define` can still appear in [`values`](/versions/8.1.1/reference/be/general#config_setting.values) with normal flag syntax, and can be mixed freely with this attribute as long as dictionary keys remain distinct. |
-| `flag_values` | Dictionary: [label](/versions/8.1.1/concepts/labels) -> String; [nonconfigurable](common-definitions#configurable-attributes); default is `{}` The same as [`values`](/versions/8.1.1/reference/be/general#config_setting.values) but for [user-defined build flags](https://bazel.build/versions/8.1.1/rules/config#user-defined-build-settings). This is a distinct attribute because user-defined flags are referenced as labels while built-in flags are referenced as arbitrary strings. |
-| `values` | Dictionary: String -> String; [nonconfigurable](common-definitions#configurable-attributes); default is `{}` The set of configuration values that match this rule (expressed as build flags) This rule inherits the configuration of the configured target that references it in a `select` statement. It is considered to "match" a Bazel invocation if, for every entry in the dictionary, its configuration matches the entry's expected value. For example `values = {"compilation_mode": "opt"}` matches the invocations `bazel build --compilation_mode=opt ...` and `bazel build -c opt ...` on target-configured rules.  For convenience's sake, configuration values are specified as build flags (without the preceding `"--"`). But keep in mind that the two are not the same. This is because targets can be built in multiple configurations within the same build. For example, an exec configuration's "cpu" matches the value of `--host_cpu`, not `--cpu`. So different instances of the same `config_setting` may match the same invocation differently depending on the configuration of the rule using them.  If a flag is not explicitly set at the command line, its default value is used. If a key appears multiple times in the dictionary, only the last instance is used. If a key references a flag that can be set multiple times on the command line (e.g. `bazel build --copt=foo --copt=bar --copt=baz ...`), a match occurs if *any* of those settings match. |
+| `constraint_values` | List of [labels](/versions/8.1.1/concepts/labels); [nonconfigurable](/versions/8.1.1/reference/be/common-definitions#configurable-attributes); default is `[]` The minimum set of `constraint_values` that the target platform must specify in order to match this `config_setting`. (The execution platform is not considered here.) Any additional constraint values that the platform has are ignored. See [Configurable Build Attributes](https://bazel.build/versions/8.1.1/docs/configurable-attributes#platforms) for details. If two `config_setting`s match in the same `select` and one has all the same flags and `constraint_setting`s as the other plus additional ones, the one with more settings is chosen. This is known as "specialization". For example, a `config_setting` matching `x86` and `Linux` specializes a `config_setting` matching `x86`. If two `config_setting`s match and both have `constraint_value`s not present in the other, this is an error. |
+| `define_values` | Dictionary: String -> String; [nonconfigurable](/versions/8.1.1/reference/be/common-definitions#configurable-attributes); default is `{}` The same as [`values`](/versions/8.1.1/reference/be/general#config_setting.values) but specifically for the `--define` flag. `--define` is special because its syntax (`--define KEY=VAL`) means `KEY=VAL` is a *value* from a Bazel flag perspective.  That means:  ```             config_setting(                 name = "a_and_b",                 values = {                     "define": "a=1",                     "define": "b=2",                 }) ```   doesn't work because the same key (`define`) appears twice in the dictionary. This attribute solves that problem:  ```             config_setting(                 name = "a_and_b",                 define_values = {                     "a": "1",                     "b": "2",                 }) ```   correctly matches `bazel build //foo --define a=1 --define b=2`. `--define` can still appear in [`values`](/versions/8.1.1/reference/be/general#config_setting.values) with normal flag syntax, and can be mixed freely with this attribute as long as dictionary keys remain distinct. |
+| `flag_values` | Dictionary: [label](/versions/8.1.1/concepts/labels) -> String; [nonconfigurable](/versions/8.1.1/reference/be/common-definitions#configurable-attributes); default is `{}` The same as [`values`](/versions/8.1.1/reference/be/general#config_setting.values) but for [user-defined build flags](https://bazel.build/versions/8.1.1/rules/config#user-defined-build-settings). This is a distinct attribute because user-defined flags are referenced as labels while built-in flags are referenced as arbitrary strings. |
+| `values` | Dictionary: String -> String; [nonconfigurable](/versions/8.1.1/reference/be/common-definitions#configurable-attributes); default is `{}` The set of configuration values that match this rule (expressed as build flags) This rule inherits the configuration of the configured target that references it in a `select` statement. It is considered to "match" a Bazel invocation if, for every entry in the dictionary, its configuration matches the entry's expected value. For example `values = {"compilation_mode": "opt"}` matches the invocations `bazel build --compilation_mode=opt ...` and `bazel build -c opt ...` on target-configured rules.  For convenience's sake, configuration values are specified as build flags (without the preceding `"--"`). But keep in mind that the two are not the same. This is because targets can be built in multiple configurations within the same build. For example, an exec configuration's "cpu" matches the value of `--host_cpu`, not `--cpu`. So different instances of the same `config_setting` may match the same invocation differently depending on the configuration of the rule using them.  If a flag is not explicitly set at the command line, its default value is used. If a key appears multiple times in the dictionary, only the last instance is used. If a key references a flag that can be set multiple times on the command line (e.g. `bazel build --copt=foo --copt=bar --copt=baz ...`), a match occurs if *any* of those settings match. |
 
 ## filegroup
 
@@ -466,7 +466,7 @@ genrule(
 | --- | --- |
 | `name` | [Name](/versions/8.1.1/concepts/labels#target-names); required  A unique name for this target.  You may refer to this rule by name in the `srcs` or `deps` section of other `BUILD` rules. If the rule generates source files, you should use the `srcs` attribute. |
 | `srcs` | List of [labels](/versions/8.1.1/concepts/labels); default is `[]` A list of inputs for this rule, such as source files to process. *This attributes is not suitable to list tools executed by the `cmd`; use the [`tools`](/versions/8.1.1/reference/be/general#genrule.tools) attribute for them instead.*  The build system ensures these prerequisites are built before running the genrule command; they are built using the same configuration as the original build request. The names of the files of these prerequisites are available to the command as a space-separated list in `$(SRCS)`; alternatively the path of an individual `srcs` target `//x:y` can be obtained using `$(location //x:y)`, or using `$<` provided it's the only entry in `srcs`. |
-| `outs` | List of [filenames](/versions/8.1.1/concepts/build-ref#filename); [nonconfigurable](common-definitions#configurable-attributes); required A list of files generated by this rule. Output files must not cross package boundaries. Output filenames are interpreted as relative to the package.  If the `executable` flag is set, `outs` must contain exactly one label.  The genrule command is expected to create each output file at a predetermined location. The location is available in `cmd` using [genrule-specific "Make" variables](/versions/8.1.1/reference/be/make-variables#predefined_genrule_variables) (`$@`, `$(OUTS)`, `$(@D)` or `$(RULEDIR)`) or using [`$(location)`](/versions/8.1.1/reference/be/make-variables#predefined_label_variables) substitution. |
+| `outs` | List of [filenames](/versions/8.1.1/concepts/build-ref#filename); [nonconfigurable](/versions/8.1.1/reference/be/common-definitions#configurable-attributes); required A list of files generated by this rule. Output files must not cross package boundaries. Output filenames are interpreted as relative to the package.  If the `executable` flag is set, `outs` must contain exactly one label.  The genrule command is expected to create each output file at a predetermined location. The location is available in `cmd` using [genrule-specific "Make" variables](/versions/8.1.1/reference/be/make-variables#predefined_genrule_variables) (`$@`, `$(OUTS)`, `$(@D)` or `$(RULEDIR)`) or using [`$(location)`](/versions/8.1.1/reference/be/make-variables#predefined_label_variables) substitution. |
 | `cmd` | String; default is `""` The command to run. Subject to [`$(location)`](/versions/8.1.1/reference/be/make-variables#predefined_label_variables) and ["Make" variable](/versions/8.1.1/reference/be/make-variables) substitution.  1. First [`$(location)`](/versions/8.1.1/reference/be/make-variables#predefined_label_variables) substitution is applied, replacing all occurrences of `$(location     label)` and of `$(locations label)` (and similar    constructions using related variables `execpath`, `execpaths`,    `rootpath` and `rootpaths`). 2. Next, ["Make" variables](/versions/8.1.1/reference/be/make-variables) are expanded. Note that    predefined variables `$(JAVA)`, `$(JAVAC)` and    `$(JAVABASE)` expand under the *exec* configuration, so Java invocations    that run as part of a build step can correctly load shared libraries and other    dependencies. 3. Finally, the resulting command is executed using the Bash shell. If its exit code is    non-zero the command is considered to have failed.  This is the fallback of `cmd_bash`, `cmd_ps` and `cmd_bat`, if none of them are applicable. |
 
 If the command line length exceeds the platform limit (64K on Linux/macOS, 8K on Windows),
@@ -477,11 +477,11 @@ applies to all cmd attributes (`cmd`, `cmd_bash`, `cmd_ps`,
 | `cmd_bash` | String; default is `""` The Bash command to run. This attribute has higher priority than `cmd`. The command is expanded and runs in the exact same way as the `cmd` attribute. |
 | `cmd_bat` | String; default is `""` The Batch command to run on Windows. This attribute has higher priority than `cmd` and `cmd_bash`. The command runs in the similar way as the `cmd` attribute, with the following differences:   * This attribute only applies on Windows. * The command runs with `cmd.exe /c` with the following default arguments:   + `/S` - strip first and last quotes and execute everything else as is.   + `/E:ON` - enable extended command set.   + `/V:ON` - enable delayed variable expansion   + `/D` - ignore AutoRun registry entries. * After [$(location)](/versions/8.1.1/reference/be/make-variables#predefined_label_variables) and   ["Make" variable](/versions/8.1.1/reference/be/make-variables) substitution, the paths will be   expanded to Windows style paths (with backslash). |
 | `cmd_ps` | String; default is `""` The Powershell command to run on Windows. This attribute has higher priority than `cmd`, `cmd_bash` and `cmd_bat`. The command runs in the similar way as the `cmd` attribute, with the following differences:   * This attribute only applies on Windows. * The command runs with `powershell.exe /c`.   To make Powershell easier to use and less error-prone, we run the following commands to set up the environment before executing Powershell command in genrule.   * `Set-ExecutionPolicy -Scope CurrentUser RemoteSigned` - allow running   unsigned scripts. * `$errorActionPreference='Stop'` - In case there are multiple commands   separated by `;`, the action exits immediately if a Powershell CmdLet fails,   but this does **NOT** work for external command. * `$PSDefaultParameterValues['*:Encoding'] = 'utf8'` - change the default   encoding from utf-16 to utf-8. |
-| `executable` | Boolean; [nonconfigurable](common-definitions#configurable-attributes); default is `False` Declare output to be executable. Setting this flag to True means the output is an executable file and can be run using the `run` command. The genrule must produce exactly one output in this case. If this attribute is set, `run` will try executing the file regardless of its content.  Declaring data dependencies for the generated executable is not supported. |
+| `executable` | Boolean; [nonconfigurable](/versions/8.1.1/reference/be/common-definitions#configurable-attributes); default is `False` Declare output to be executable. Setting this flag to True means the output is an executable file and can be run using the `run` command. The genrule must produce exactly one output in this case. If this attribute is set, `run` will try executing the file regardless of its content.  Declaring data dependencies for the generated executable is not supported. |
 | `local` | Boolean; default is `False`  If set to True, this option forces this `genrule` to run using the "local" strategy, which means no remote execution, no sandboxing, no persistent workers.  This is equivalent to providing 'local' as a tag (`tags=["local"]`). |
 | `message` | String; default is `""` A progress message. A progress message that will be printed as this build step is executed. By default, the message is "Generating *output*" (or something equally bland) but you may provide a more specific one. Use this attribute instead of `echo` or other print statements in your `cmd` command, as this allows the build tool to control whether such progress messages are printed or not. |
 | `output_licenses` | Licence type; default is `["none"]` See [`common attributes`](/versions/8.1.1/reference/be/common-definitions#binary.output_licenses) |
-| `output_to_bindir` | Boolean; [nonconfigurable](common-definitions#configurable-attributes); default is `False`  If set to True, this option causes output files to be written into the `bin` directory instead of the `genfiles` directory. |
+| `output_to_bindir` | Boolean; [nonconfigurable](/versions/8.1.1/reference/be/common-definitions#configurable-attributes); default is `False`  If set to True, this option causes output files to be written into the `bin` directory instead of the `genfiles` directory. |
 | `tools` | List of [labels](/versions/8.1.1/concepts/labels); default is `[]` A list of *tool* dependencies for this rule. See the definition of [dependencies](/versions/8.1.1/concepts/build-ref#deps) for more information.   The build system ensures these prerequisites are built before running the genrule command; they are built using the [*exec* configuration](/versions/8.1.1/contribute/guide#configurations), since these tools are executed as part of the build. The path of an individual `tools` target `//x:y` can be obtained using `$(location //x:y)`.  Any `*_binary` or tool to be executed by `cmd` must appear in this list, not in `srcs`, to ensure they are built in the correct configuration. |
 
 ## starlark\_doc\_extract
@@ -571,5 +571,5 @@ test_suite(
 | Attributes | |
 | --- | --- |
 | `name` | [Name](/versions/8.1.1/concepts/labels#target-names); required  A unique name for this target. |
-| `tags` | List of strings; [nonconfigurable](common-definitions#configurable-attributes); default is `[]` List of text tags such as "small" or "database" or "-flaky". Tags may be any valid string. Tags which begin with a "-" character are considered negative tags. The preceding "-" character is not considered part of the tag, so a suite tag of "-small" matches a test's "small" size. All other tags are considered positive tags.  Optionally, to make positive tags more explicit, tags may also begin with the "+" character, which will not be evaluated as part of the text of the tag. It merely makes the positive and negative distinction easier to read.  Only test rules that match **all** of the positive tags and **none** of the negative tags will be included in the test suite. Note that this does not mean that error checking for dependencies on tests that are filtered out is skipped; the dependencies on skipped tests still need to be legal (e.g. not blocked by visibility constraints).  The `manual` tag keyword is treated differently than the above by the "test\_suite expansion" performed by the `bazel test` command on invocations involving wildcard [target patterns](https://bazel.build/versions/8.1.1/docs/build#specifying-build-targets). There, `test_suite` targets tagged "manual" are filtered out (and thus not expanded). This behavior is consistent with how `bazel build` and `bazel test` handle wildcard target patterns in general. Note that this is explicitly different from how `bazel query 'tests(E)'` behaves, as suites are always expanded by the `tests` query function, regardless of the `manual` tag.  Note that a test's `size` is considered a tag for the purpose of filtering.  If you need a `test_suite` that contains tests with mutually exclusive tags (e.g. all small and medium tests), you'll have to create three `test_suite` rules: one for all small tests, one for all medium tests, and one that includes the previous two. |
-| `tests` | List of [labels](/versions/8.1.1/concepts/labels); [nonconfigurable](common-definitions#configurable-attributes); default is `[]` A list of test suites and test targets of any language. Any `*_test` is accepted here, independent of the language. No `*_binary` targets are accepted however, even if they happen to run a test. Filtering by the specified `tags` is only done for tests listed directly in this attribute. If this attribute contains `test_suite`s, the tests inside those will not be filtered by this `test_suite` (they are considered to be filtered already).  If the `tests` attribute is unspecified or empty, the rule will default to including all test rules in the current BUILD file that are not tagged as `manual`. These rules are still subject to `tag` filtering. |
\ No newline at end of file
+| `tags` | List of strings; [nonconfigurable](/versions/8.1.1/reference/be/common-definitions#configurable-attributes); default is `[]` List of text tags such as "small" or "database" or "-flaky". Tags may be any valid string. Tags which begin with a "-" character are considered negative tags. The preceding "-" character is not considered part of the tag, so a suite tag of "-small" matches a test's "small" size. All other tags are considered positive tags.  Optionally, to make positive tags more explicit, tags may also begin with the "+" character, which will not be evaluated as part of the text of the tag. It merely makes the positive and negative distinction easier to read.  Only test rules that match **all** of the positive tags and **none** of the negative tags will be included in the test suite. Note that this does not mean that error checking for dependencies on tests that are filtered out is skipped; the dependencies on skipped tests still need to be legal (e.g. not blocked by visibility constraints).  The `manual` tag keyword is treated differently than the above by the "test\_suite expansion" performed by the `bazel test` command on invocations involving wildcard [target patterns](https://bazel.build/versions/8.1.1/docs/build#specifying-build-targets). There, `test_suite` targets tagged "manual" are filtered out (and thus not expanded). This behavior is consistent with how `bazel build` and `bazel test` handle wildcard target patterns in general. Note that this is explicitly different from how `bazel query 'tests(E)'` behaves, as suites are always expanded by the `tests` query function, regardless of the `manual` tag.  Note that a test's `size` is considered a tag for the purpose of filtering.  If you need a `test_suite` that contains tests with mutually exclusive tags (e.g. all small and medium tests), you'll have to create three `test_suite` rules: one for all small tests, one for all medium tests, and one that includes the previous two. |
+| `tests` | List of [labels](/versions/8.1.1/concepts/labels); [nonconfigurable](/versions/8.1.1/reference/be/common-definitions#configurable-attributes); default is `[]` A list of test suites and test targets of any language. Any `*_test` is accepted here, independent of the language. No `*_binary` targets are accepted however, even if they happen to run a test. Filtering by the specified `tags` is only done for tests listed directly in this attribute. If this attribute contains `test_suite`s, the tests inside those will not be filtered by this `test_suite` (they are considered to be filtered already).  If the `tests` attribute is unspecified or empty, the rule will default to including all test rules in the current BUILD file that are not tagged as `manual`. These rules are still subject to `tag` filtering. |
\ No newline at end of file
diff --git a/versions/8.1.1/reference/be/java.mdx b/versions/8.1.1/reference/be/java.mdx
index 2c678657..970f1433 100644
--- a/versions/8.1.1/reference/be/java.mdx
+++ b/versions/8.1.1/reference/be/java.mdx
@@ -15,7 +15,7 @@ title: 'Java Rules'
 
 ## java\_binary
 
-[View rule sourceopen\_in\_new](@rules_java//java/bazel/rules/bazel_java_binary.bzl)
+[View rule sourceopen\_in\_new](/versions/8.1.1/reference/be/@rules_java//java/bazel/rules/bazel_java_binary.bzl)
 
 ```
 java_binary(name, deps, srcs, data, resources, add_exports, add_opens, args, bootclasspath, classpath_resources, compatible_with, create_executable, deploy_env, deploy_manifest_lines, deprecation, distribs, env, exec_compatible_with, exec_properties, features, javacopts, jvm_flags, launcher, licenses, main_class, neverlink, output_licenses, plugins, resource_strip_prefix, restricted_to, runtime_deps, stamp, tags, target_compatible_with, testonly, toolchains, use_launcher, use_testrunner, visibility)
@@ -102,7 +102,7 @@ java_binary(
 | Attributes | |
 | --- | --- |
 | `name` | [Name](/versions/8.1.1/concepts/labels#target-names); required  A unique name for this target. |
-| `deps` | List of [labels](/versions/8.1.1/concepts/labels); default is `[]` The list of other libraries to be linked in to the target. See general comments about `deps` at [Typical attributes defined by most build rules](common-definitions#typical-attributes). |
+| `deps` | List of [labels](/versions/8.1.1/concepts/labels); default is `[]` The list of other libraries to be linked in to the target. See general comments about `deps` at [Typical attributes defined by most build rules](/versions/8.1.1/reference/be/common-definitions#typical-attributes). |
 | `srcs` | List of [labels](/versions/8.1.1/concepts/labels); default is `[]` The list of source files that are processed to create the target. This attribute is almost always required; see exceptions below. Source files of type `.java` are compiled. In case of generated `.java` files it is generally advisable to put the generating rule's name here instead of the name of the file itself. This not only improves readability but makes the rule more resilient to future changes: if the generating rule generates different files in the future, you only need to fix one place: the `outs` of the generating rule. You should not list the generating rule in `deps` because it is a no-op.  Source files of type `.srcjar` are unpacked and compiled. (This is useful if you need to generate a set of `.java` files with a genrule.)  Rules: if the rule (typically `genrule` or `filegroup`) generates any of the files listed above, they will be used the same way as described for source files.  This argument is almost always required, except if a [`main_class`](#java_binary.main_class) attribute specifies a class on the runtime classpath or you specify the `runtime_deps` argument. |
 | `data` | List of [labels](/versions/8.1.1/concepts/labels); default is `[]` The list of files needed by this library at runtime. See general comments about `data` at [Typical attributes defined by most build rules](/versions/8.1.1/reference/be/common-definitions#typical-attributes). |
 | `resources` | List of [labels](/versions/8.1.1/concepts/labels); default is `[]` A list of data files to include in a Java jar. Resources may be source files or generated files.  If resources are specified, they will be bundled in the jar along with the usual `.class` files produced by compilation. The location of the resources inside of the jar file is determined by the project structure. Bazel first looks for Maven's [standard directory layout](https://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html), (a "src" directory followed by a "resources" directory grandchild). If that is not found, Bazel then looks for the topmost directory named "java" or "javatests" (so, for example, if a resource is at `/x/java/y/java/z`, the path of the resource will be `y/java/z`. This heuristic cannot be overridden, however, the `resource_strip_prefix` attribute can be used to specify a specific alternative directory for resource files. |
@@ -112,9 +112,9 @@ java_binary(
 | `classpath_resources` | List of [labels](/versions/8.1.1/concepts/labels); default is `[]` *DO NOT USE THIS OPTION UNLESS THERE IS NO OTHER WAY)* A list of resources that must be located at the root of the java tree. This attribute's only purpose is to support third-party libraries that require that their resources be found on the classpath as exactly `"myconfig.xml"`. It is only allowed on binaries and not libraries, due to the danger of namespace conflicts. |
 | `create_executable` | Boolean; default is `True` Deprecated, use `java_single_jar` instead. |
 | `deploy_env` | List of [labels](/versions/8.1.1/concepts/labels); default is `[]` A list of other `java_binary` targets which represent the deployment environment for this binary. Set this attribute when building a plugin which will be loaded by another `java_binary`.  Setting this attribute excludes all dependencies from the runtime classpath (and the deploy jar) of this binary that are shared between this binary and the targets specified in `deploy_env`. |
-| `deploy_manifest_lines` | List of strings; default is `[]` A list of lines to add to the `META-INF/manifest.mf` file generated for the `*_deploy.jar` target. The contents of this attribute are *not* subject to ["Make variable"](make-variables) substitution. |
-| `javacopts` | List of strings; default is `[]` Extra compiler options for this binary. Subject to ["Make variable"](make-variables) substitution and [Bourne shell tokenization](common-definitions#sh-tokenization). These compiler options are passed to javac after the global compiler options. |
-| `jvm_flags` | List of strings; default is `[]` A list of flags to embed in the wrapper script generated for running this binary. Subject to [$(location)](/versions/8.1.1/reference/be/make-variables#location) and ["Make variable"](make-variables) substitution, and [Bourne shell tokenization](common-definitions#sh-tokenization). The wrapper script for a Java binary includes a CLASSPATH definition (to find all the dependent jars) and invokes the right Java interpreter. The command line generated by the wrapper script includes the name of the main class followed by a `"$@"` so you can pass along other arguments after the classname. However, arguments intended for parsing by the JVM must be specified *before* the classname on the command line. The contents of `jvm_flags` are added to the wrapper script before the classname is listed.  Note that this attribute has *no effect* on `*_deploy.jar` outputs. |
+| `deploy_manifest_lines` | List of strings; default is `[]` A list of lines to add to the `META-INF/manifest.mf` file generated for the `*_deploy.jar` target. The contents of this attribute are *not* subject to ["Make variable"](/versions/8.1.1/reference/be/make-variables) substitution. |
+| `javacopts` | List of strings; default is `[]` Extra compiler options for this binary. Subject to ["Make variable"](/versions/8.1.1/reference/be/make-variables) substitution and [Bourne shell tokenization](/versions/8.1.1/reference/be/common-definitions#sh-tokenization). These compiler options are passed to javac after the global compiler options. |
+| `jvm_flags` | List of strings; default is `[]` A list of flags to embed in the wrapper script generated for running this binary. Subject to [$(location)](/versions/8.1.1/reference/be/make-variables#location) and ["Make variable"](/versions/8.1.1/reference/be/make-variables) substitution, and [Bourne shell tokenization](/versions/8.1.1/reference/be/common-definitions#sh-tokenization). The wrapper script for a Java binary includes a CLASSPATH definition (to find all the dependent jars) and invokes the right Java interpreter. The command line generated by the wrapper script includes the name of the main class followed by a `"$@"` so you can pass along other arguments after the classname. However, arguments intended for parsing by the JVM must be specified *before* the classname on the command line. The contents of `jvm_flags` are added to the wrapper script before the classname is listed.  Note that this attribute has *no effect* on `*_deploy.jar` outputs. |
 | `launcher` | [Label](/versions/8.1.1/concepts/labels); default is `None` Specify a binary that will be used to run your Java program instead of the normal `bin/java` program included with the JDK. The target must be a `cc_binary`. Any `cc_binary` that implements the [Java Invocation API](http://docs.oracle.com/javase/7/docs/technotes/guides/jni/spec/invocation.html) can be specified as a value for this attribute. By default, Bazel will use the normal JDK launcher (bin/java or java.exe).  The related [`--java_launcher`](/versions/8.1.1/docs/user-manual#flag--java_launcher) Bazel flag affects only those `java_binary` and `java_test` targets that have *not* specified a `launcher` attribute.  Note that your native (C++, SWIG, JNI) dependencies will be built differently depending on whether you are using the JDK launcher or another launcher:   * If you are using the normal JDK launcher (the default), native dependencies are   built as a shared library named `{name}_nativedeps.so`, where   `{name}` is the `name` attribute of this java\_binary rule.   Unused code is *not* removed by the linker in this configuration. * If you are using any other launcher, native (C++) dependencies are statically   linked into a binary named `{name}_nativedeps`, where `{name}`   is the `name` attribute of this java\_binary rule. In this case,   the linker will remove any code it thinks is unused from the resulting binary,   which means any C++ code accessed only via JNI may not be linked in unless   that `cc_library` target specifies `alwayslink = True`.   When using any launcher other than the default JDK launcher, the format of the `*_deploy.jar` output changes. See the main [java\_binary](#java_binary) docs for details. |
 | `main_class` | String; default is `""` Name of class with `main()` method to use as entry point. If a rule uses this option, it does not need a `srcs=[...]` list. Thus, with this attribute one can make an executable from a Java library that already contains one or more `main()` methods. The value of this attribute is a class name, not a source file. The class must be available at runtime: it may be compiled by this rule (from `srcs`) or provided by direct or transitive dependencies (through `runtime_deps` or `deps`). If the class is unavailable, the binary will fail at runtime; there is no build-time check. |
 | `neverlink` | Boolean; default is `False` |
@@ -127,7 +127,7 @@ java_binary(
 
 ## java\_import
 
-[View rule sourceopen\_in\_new](@rules_java//java/bazel/rules/bazel_java_import.bzl)
+[View rule sourceopen\_in\_new](/versions/8.1.1/reference/be/@rules_java//java/bazel/rules/bazel_java_import.bzl)
 
 ```
 java_import(name, deps, data, add_exports, add_opens, compatible_with, constraints, deprecation, distribs, exec_compatible_with, exec_properties, exports, features, jars, licenses, neverlink, proguard_specs, restricted_to, runtime_deps, srcjar, tags, target_compatible_with, testonly, toolchains, visibility)
@@ -169,7 +169,7 @@ libraries for `java_library` and
 
 ## java\_library
 
-[View rule sourceopen\_in\_new](@rules_java//java/bazel/rules/bazel_java_library.bzl)
+[View rule sourceopen\_in\_new](/versions/8.1.1/reference/be/@rules_java//java/bazel/rules/bazel_java_library.bzl)
 
 ```
 java_library(name, deps, srcs, data, resources, add_exports, add_opens, bootclasspath, compatible_with, deprecation, distribs, exec_compatible_with, exec_properties, exported_plugins, exports, features, javabuilder_jvm_flags, javacopts, licenses, neverlink, plugins, proguard_specs, resource_strip_prefix, restricted_to, runtime_deps, tags, target_compatible_with, testonly, toolchains, visibility)
@@ -198,7 +198,7 @@ This rule compiles and links sources into a `.jar` file.
 | `exported_plugins` | List of [labels](/versions/8.1.1/concepts/labels); default is `[]` The list of `java_plugin`s (e.g. annotation processors) to export to libraries that directly depend on this library. The specified list of `java_plugin`s will be applied to any library which directly depends on this library, just as if that library had explicitly declared these labels in `plugins`. |
 | `exports` | List of [labels](/versions/8.1.1/concepts/labels); default is `[]` Exported libraries. Listing rules here will make them available to parent rules, as if the parents explicitly depended on these rules. This is not true for regular (non-exported) `deps`.  Summary: a rule *X* can access the code in *Y* if there exists a dependency path between them that begins with a `deps` edge followed by zero or more `exports` edges. Let's see some examples to illustrate this.  Assume *A* depends on *B* and *B* depends on *C*. In this case C is a *transitive* dependency of A, so changing C's sources and rebuilding A will correctly rebuild everything. However A will not be able to use classes in C. To allow that, either A has to declare C in its `deps`, or B can make it easier for A (and anything that may depend on A) by declaring C in its (B's) `exports` attribute.  The closure of exported libraries is available to all direct parent rules. Take a slightly different example: A depends on B, B depends on C and D, and also exports C but not D. Now A has access to C but not to D. Now, if C and D exported some libraries, C' and D' respectively, A could only access C' but not D'.  Important: an exported rule is not a regular dependency. Sticking to the previous example, if B exports C and wants to also use C, it has to also list it in its own `deps`. |
 | `javabuilder_jvm_flags` | List of strings; default is `[]` Restricted API, do not use! |
-| `javacopts` | List of strings; default is `[]` Extra compiler options for this library. Subject to ["Make variable"](make-variables) substitution and [Bourne shell tokenization](common-definitions#sh-tokenization). These compiler options are passed to javac after the global compiler options. |
+| `javacopts` | List of strings; default is `[]` Extra compiler options for this library. Subject to ["Make variable"](/versions/8.1.1/reference/be/make-variables) substitution and [Bourne shell tokenization](/versions/8.1.1/reference/be/common-definitions#sh-tokenization). These compiler options are passed to javac after the global compiler options. |
 | `neverlink` | Boolean; default is `False` Whether this library should only be used for compilation and not at runtime. Useful if the library will be provided by the runtime environment during execution. Examples of such libraries are the IDE APIs for IDE plug-ins or `tools.jar` for anything running on a standard JDK. Note that `neverlink = True` does not prevent the compiler from inlining material from this library into compilation targets that depend on it, as permitted by the Java Language Specification (e.g., `static final` constants of `String` or of primitive types). The preferred use case is therefore when the runtime library is identical to the compilation library.  If the runtime library differs from the compilation library then you must ensure that it differs only in places that the JLS forbids compilers to inline (and that must hold for all future versions of the JLS). |
 | `plugins` | List of [labels](/versions/8.1.1/concepts/labels); default is `[]` Java compiler plugins to run at compile-time. Every `java_plugin` specified in this attribute will be run whenever this rule is built. A library may also inherit plugins from dependencies that use `exported_plugins`. Resources generated by the plugin will be included in the resulting jar of this rule. |
 | `proguard_specs` | List of [labels](/versions/8.1.1/concepts/labels); default is `[]` Files to be used as Proguard specification. These will describe the set of specifications to be used by Proguard. If specified, they will be added to any `android_binary` target depending on this library. The files included here must only have idempotent rules, namely -dontnote, -dontwarn, assumenosideeffects, and rules that start with -keep. Other options can only appear in `android_binary`'s proguard\_specs, to ensure non-tautological merges. |
@@ -207,7 +207,7 @@ This rule compiles and links sources into a `.jar` file.
 
 ## java\_test
 
-[View rule sourceopen\_in\_new](@rules_java//java/bazel/rules/bazel_java_test.bzl)
+[View rule sourceopen\_in\_new](/versions/8.1.1/reference/be/@rules_java//java/bazel/rules/bazel_java_test.bzl)
 
 ```
 java_test(name, deps, srcs, data, resources, add_exports, add_opens, args, bootclasspath, classpath_resources, compatible_with, create_executable, deploy_manifest_lines, deprecation, distribs, env, env_inherit, exec_compatible_with, exec_properties, features, flaky, javacopts, jvm_flags, launcher, licenses, local, main_class, neverlink, plugins, resource_strip_prefix, restricted_to, runtime_deps, shard_count, size, stamp, tags, target_compatible_with, test_class, testonly, timeout, toolchains, use_launcher, use_testrunner, visibility)
@@ -225,8 +225,7 @@ test code. The test runner's main method is invoked instead of the main class be
   [java\_binary](#java_binary) for more details.
 
 See the section on `java_binary()` arguments. This rule also
-supports all [attributes common
-to all test rules (\*\_test)](https://bazel.build/versions/8.1.1/reference/be/common-definitions#common-attributes-tests).
+supports all [attributes common to all test rules (\*\_test)](https://bazel.build/versions/8.1.1/reference/be/common-definitions#common-attributes-tests).
 
 #### Examples
 
@@ -255,7 +254,7 @@ java_test(
 | Attributes | |
 | --- | --- |
 | `name` | [Name](/versions/8.1.1/concepts/labels#target-names); required  A unique name for this target. |
-| `deps` | List of [labels](/versions/8.1.1/concepts/labels); default is `[]` The list of other libraries to be linked in to the target. See general comments about `deps` at [Typical attributes defined by most build rules](common-definitions#typical-attributes). |
+| `deps` | List of [labels](/versions/8.1.1/concepts/labels); default is `[]` The list of other libraries to be linked in to the target. See general comments about `deps` at [Typical attributes defined by most build rules](/versions/8.1.1/reference/be/common-definitions#typical-attributes). |
 | `srcs` | List of [labels](/versions/8.1.1/concepts/labels); default is `[]` The list of source files that are processed to create the target. This attribute is almost always required; see exceptions below. Source files of type `.java` are compiled. In case of generated `.java` files it is generally advisable to put the generating rule's name here instead of the name of the file itself. This not only improves readability but makes the rule more resilient to future changes: if the generating rule generates different files in the future, you only need to fix one place: the `outs` of the generating rule. You should not list the generating rule in `deps` because it is a no-op.  Source files of type `.srcjar` are unpacked and compiled. (This is useful if you need to generate a set of `.java` files with a genrule.)  Rules: if the rule (typically `genrule` or `filegroup`) generates any of the files listed above, they will be used the same way as described for source files.  This argument is almost always required, except if a [`main_class`](#java_binary.main_class) attribute specifies a class on the runtime classpath or you specify the `runtime_deps` argument. |
 | `data` | List of [labels](/versions/8.1.1/concepts/labels); default is `[]` The list of files needed by this library at runtime. See general comments about `data` at [Typical attributes defined by most build rules](/versions/8.1.1/reference/be/common-definitions#typical-attributes). |
 | `resources` | List of [labels](/versions/8.1.1/concepts/labels); default is `[]` A list of data files to include in a Java jar. Resources may be source files or generated files.  If resources are specified, they will be bundled in the jar along with the usual `.class` files produced by compilation. The location of the resources inside of the jar file is determined by the project structure. Bazel first looks for Maven's [standard directory layout](https://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html), (a "src" directory followed by a "resources" directory grandchild). If that is not found, Bazel then looks for the topmost directory named "java" or "javatests" (so, for example, if a resource is at `/x/java/y/java/z`, the path of the resource will be `y/java/z`. This heuristic cannot be overridden, however, the `resource_strip_prefix` attribute can be used to specify a specific alternative directory for resource files. |
@@ -264,9 +263,9 @@ java_test(
 | `bootclasspath` | [Label](/versions/8.1.1/concepts/labels); default is `None` Restricted API, do not use! |
 | `classpath_resources` | List of [labels](/versions/8.1.1/concepts/labels); default is `[]` *DO NOT USE THIS OPTION UNLESS THERE IS NO OTHER WAY)* A list of resources that must be located at the root of the java tree. This attribute's only purpose is to support third-party libraries that require that their resources be found on the classpath as exactly `"myconfig.xml"`. It is only allowed on binaries and not libraries, due to the danger of namespace conflicts. |
 | `create_executable` | Boolean; default is `True` Deprecated, use `java_single_jar` instead. |
-| `deploy_manifest_lines` | List of strings; default is `[]` A list of lines to add to the `META-INF/manifest.mf` file generated for the `*_deploy.jar` target. The contents of this attribute are *not* subject to ["Make variable"](make-variables) substitution. |
-| `javacopts` | List of strings; default is `[]` Extra compiler options for this binary. Subject to ["Make variable"](make-variables) substitution and [Bourne shell tokenization](common-definitions#sh-tokenization). These compiler options are passed to javac after the global compiler options. |
-| `jvm_flags` | List of strings; default is `[]` A list of flags to embed in the wrapper script generated for running this binary. Subject to [$(location)](/versions/8.1.1/reference/be/make-variables#location) and ["Make variable"](make-variables) substitution, and [Bourne shell tokenization](common-definitions#sh-tokenization). The wrapper script for a Java binary includes a CLASSPATH definition (to find all the dependent jars) and invokes the right Java interpreter. The command line generated by the wrapper script includes the name of the main class followed by a `"$@"` so you can pass along other arguments after the classname. However, arguments intended for parsing by the JVM must be specified *before* the classname on the command line. The contents of `jvm_flags` are added to the wrapper script before the classname is listed.  Note that this attribute has *no effect* on `*_deploy.jar` outputs. |
+| `deploy_manifest_lines` | List of strings; default is `[]` A list of lines to add to the `META-INF/manifest.mf` file generated for the `*_deploy.jar` target. The contents of this attribute are *not* subject to ["Make variable"](/versions/8.1.1/reference/be/make-variables) substitution. |
+| `javacopts` | List of strings; default is `[]` Extra compiler options for this binary. Subject to ["Make variable"](/versions/8.1.1/reference/be/make-variables) substitution and [Bourne shell tokenization](/versions/8.1.1/reference/be/common-definitions#sh-tokenization). These compiler options are passed to javac after the global compiler options. |
+| `jvm_flags` | List of strings; default is `[]` A list of flags to embed in the wrapper script generated for running this binary. Subject to [$(location)](/versions/8.1.1/reference/be/make-variables#location) and ["Make variable"](/versions/8.1.1/reference/be/make-variables) substitution, and [Bourne shell tokenization](/versions/8.1.1/reference/be/common-definitions#sh-tokenization). The wrapper script for a Java binary includes a CLASSPATH definition (to find all the dependent jars) and invokes the right Java interpreter. The command line generated by the wrapper script includes the name of the main class followed by a `"$@"` so you can pass along other arguments after the classname. However, arguments intended for parsing by the JVM must be specified *before* the classname on the command line. The contents of `jvm_flags` are added to the wrapper script before the classname is listed.  Note that this attribute has *no effect* on `*_deploy.jar` outputs. |
 | `launcher` | [Label](/versions/8.1.1/concepts/labels); default is `None` Specify a binary that will be used to run your Java program instead of the normal `bin/java` program included with the JDK. The target must be a `cc_binary`. Any `cc_binary` that implements the [Java Invocation API](http://docs.oracle.com/javase/7/docs/technotes/guides/jni/spec/invocation.html) can be specified as a value for this attribute. By default, Bazel will use the normal JDK launcher (bin/java or java.exe).  The related [`--java_launcher`](/versions/8.1.1/docs/user-manual#flag--java_launcher) Bazel flag affects only those `java_binary` and `java_test` targets that have *not* specified a `launcher` attribute.  Note that your native (C++, SWIG, JNI) dependencies will be built differently depending on whether you are using the JDK launcher or another launcher:   * If you are using the normal JDK launcher (the default), native dependencies are   built as a shared library named `{name}_nativedeps.so`, where   `{name}` is the `name` attribute of this java\_binary rule.   Unused code is *not* removed by the linker in this configuration. * If you are using any other launcher, native (C++) dependencies are statically   linked into a binary named `{name}_nativedeps`, where `{name}`   is the `name` attribute of this java\_binary rule. In this case,   the linker will remove any code it thinks is unused from the resulting binary,   which means any C++ code accessed only via JNI may not be linked in unless   that `cc_library` target specifies `alwayslink = True`.   When using any launcher other than the default JDK launcher, the format of the `*_deploy.jar` output changes. See the main [java\_binary](#java_binary) docs for details. |
 | `main_class` | String; default is `""` Name of class with `main()` method to use as entry point. If a rule uses this option, it does not need a `srcs=[...]` list. Thus, with this attribute one can make an executable from a Java library that already contains one or more `main()` methods. The value of this attribute is a class name, not a source file. The class must be available at runtime: it may be compiled by this rule (from `srcs`) or provided by direct or transitive dependencies (through `runtime_deps` or `deps`). If the class is unavailable, the binary will fail at runtime; there is no build-time check. |
 | `neverlink` | Boolean; default is `False` |
@@ -280,7 +279,7 @@ java_test(
 
 ## java\_package\_configuration
 
-[View rule sourceopen\_in\_new](@rules_java//java/common/rules/java_package_configuration.bzl)
+[View rule sourceopen\_in\_new](/versions/8.1.1/reference/be/@rules_java//java/common/rules/java_package_configuration.bzl)
 
 ```
 java_package_configuration(name, data, compatible_with, deprecation, distribs, exec_compatible_with, exec_properties, features, javacopts, output_licenses, packages, restricted_to, system, tags, target_compatible_with, testonly, toolchains, visibility)
@@ -328,7 +327,7 @@ java_toolchain(
 
 ## java\_plugin
 
-[View rule sourceopen\_in\_new](@rules_java//java/bazel/rules/bazel_java_plugin.bzl)
+[View rule sourceopen\_in\_new](/versions/8.1.1/reference/be/@rules_java//java/bazel/rules/bazel_java_plugin.bzl)
 
 ```
 java_plugin(name, deps, srcs, data, resources, add_exports, add_opens, bootclasspath, compatible_with, deprecation, distribs, exec_compatible_with, exec_properties, features, generates_api, javabuilder_jvm_flags, javacopts, licenses, neverlink, output_licenses, plugins, processor_class, proguard_specs, resource_strip_prefix, restricted_to, tags, target_compatible_with, testonly, toolchains, visibility)
@@ -362,7 +361,7 @@ for the addition of the `processor_class` argument.
 | `bootclasspath` | [Label](/versions/8.1.1/concepts/labels); default is `None` Restricted API, do not use! |
 | `generates_api` | Boolean; default is `False` This attribute marks annotation processors that generate API code. If a rule uses an API-generating annotation processor, other rules depending on it can refer to the generated code only if their compilation actions are scheduled after the generating rule. This attribute instructs Bazel to introduce scheduling constraints when --java\_header\_compilation is enabled. *WARNING: This attribute affects build performance, use it only if necessary.* |
 | `javabuilder_jvm_flags` | List of strings; default is `[]` Restricted API, do not use! |
-| `javacopts` | List of strings; default is `[]` Extra compiler options for this library. Subject to ["Make variable"](make-variables) substitution and [Bourne shell tokenization](common-definitions#sh-tokenization). These compiler options are passed to javac after the global compiler options. |
+| `javacopts` | List of strings; default is `[]` Extra compiler options for this library. Subject to ["Make variable"](/versions/8.1.1/reference/be/make-variables) substitution and [Bourne shell tokenization](/versions/8.1.1/reference/be/common-definitions#sh-tokenization). These compiler options are passed to javac after the global compiler options. |
 | `neverlink` | Boolean; default is `False` Whether this library should only be used for compilation and not at runtime. Useful if the library will be provided by the runtime environment during execution. Examples of such libraries are the IDE APIs for IDE plug-ins or `tools.jar` for anything running on a standard JDK. Note that `neverlink = True` does not prevent the compiler from inlining material from this library into compilation targets that depend on it, as permitted by the Java Language Specification (e.g., `static final` constants of `String` or of primitive types). The preferred use case is therefore when the runtime library is identical to the compilation library.  If the runtime library differs from the compilation library then you must ensure that it differs only in places that the JLS forbids compilers to inline (and that must hold for all future versions of the JLS). |
 | `output_licenses` | List of strings; default is `[]` |
 | `plugins` | List of [labels](/versions/8.1.1/concepts/labels); default is `[]` Java compiler plugins to run at compile-time. Every `java_plugin` specified in this attribute will be run whenever this rule is built. A library may also inherit plugins from dependencies that use `exported_plugins`. Resources generated by the plugin will be included in the resulting jar of this rule. |
@@ -372,7 +371,7 @@ for the addition of the `processor_class` argument.
 
 ## java\_runtime
 
-[View rule sourceopen\_in\_new](@rules_java//java/common/rules/java_runtime.bzl)
+[View rule sourceopen\_in\_new](/versions/8.1.1/reference/be/@rules_java//java/common/rules/java_runtime.bzl)
 
 ```
 java_runtime(name, srcs, compatible_with, default_cds, deprecation, distribs, exec_compatible_with, exec_properties, features, hermetic_srcs, hermetic_static_libs, java, java_home, lib_ct_sym, lib_modules, output_licenses, restricted_to, tags, target_compatible_with, testonly, toolchains, version, visibility)
@@ -408,7 +407,7 @@ java_runtime(
 
 ## java\_toolchain
 
-[View rule sourceopen\_in\_new](@rules_java//java/common/rules/java_toolchain.bzl)
+[View rule sourceopen\_in\_new](/versions/8.1.1/reference/be/@rules_java//java/common/rules/java_toolchain.bzl)
 
 ```
 java_toolchain(name, android_lint_data, android_lint_jvm_opts, android_lint_opts, android_lint_package_configuration, android_lint_runner, bootclasspath, compatible_javacopts, compatible_with, deprecation, deps_checker, distribs, exec_compatible_with, exec_properties, features, forcibly_disable_header_compilation, genclass, header_compiler, header_compiler_builtin_processors, header_compiler_direct, ijar, jacocorunner, java_runtime, javabuilder, javabuilder_data, javabuilder_jvm_opts, javac_supports_multiplex_workers, javac_supports_worker_cancellation, javac_supports_worker_multiplex_sandboxing, javac_supports_workers, javacopts, jspecify_implicit_deps, jspecify_javacopts, jspecify_packages, jspecify_processor, jspecify_processor_class, jspecify_stubs, jvm_opts, licenses, misc, oneversion, oneversion_allowlist, oneversion_allowlist_for_tests, oneversion_whitelist, package_configuration, proguard_allowlister, reduced_classpath_incompatible_processors, restricted_to, singlejar, source_version, tags, target_compatible_with, target_version, testonly, timezone_data, toolchains, tools, turbine_data, turbine_jvm_opts, visibility, xlint)
diff --git a/versions/8.1.1/reference/be/make-variables.mdx b/versions/8.1.1/reference/be/make-variables.mdx
index a1af9f2d..4c57314f 100644
--- a/versions/8.1.1/reference/be/make-variables.mdx
+++ b/versions/8.1.1/reference/be/make-variables.mdx
@@ -19,8 +19,7 @@ targets, and *custom* variables, which are defined in dependency targets
 and only available to targets that depend on them.
 
 The reason for the term "Make" is historical: the syntax and semantics of
-these variables were originally intended to match [GNU
-Make](https://www.gnu.org/software/make/manual/html_node/Using-Variables.html).
+these variables were originally intended to match [GNU Make](https://www.gnu.org/software/make/manual/html_node/Using-Variables.html).
 
 ## Use
 
@@ -64,8 +63,7 @@ and look at the top output lines with capital letters.
 **Toolchain option variables**
 
 * `COMPILATION_MODE`:
-  `fastbuild`, `dbg`, or `opt`. ([more
-  details](https://bazel.build/versions/8.1.1/docs/user-manual#flag--compilation_mode))
+  `fastbuild`, `dbg`, or `opt`. ([more details](https://bazel.build/versions/8.1.1/docs/user-manual#flag--compilation_mode))
 
 **Path variables**
 
@@ -304,7 +302,7 @@ rare cases. If you are tempted to use them, please [contact the Bazel devs](http
 
 Rule and [toolchain](/versions/8.1.1/docs/toolchains) writers can define
 completely custom variables by returning a
-[TemplateVariableInfo](/versions/8.1.1/rules/lib/TemplateVariableInfo)
+[TemplateVariableInfo](/versions/8.1.1/rules/lib/providers/TemplateVariableInfo)
 provider. Any rules depending on these through the
 `toolchains` attribute can then read their values:
 
diff --git a/versions/8.1.1/reference/be/overview.mdx b/versions/8.1.1/reference/be/overview.mdx
index 13efbd5f..e0552a55 100644
--- a/versions/8.1.1/reference/be/overview.mdx
+++ b/versions/8.1.1/reference/be/overview.mdx
@@ -37,18 +37,18 @@ For non-native Starlark rules that ship separately from Bazel, see the list of
 
 | Language | Binary rules | Library rules | Test rules | Other rules |
 | --- | --- | --- | --- | --- |
-| C / C++ | [cc\_binary](c-cpp#cc_binary) | [cc\_import](c-cpp#cc_import)   [cc\_library](c-cpp#cc_library)   [cc\_shared\_library](c-cpp#cc_shared_library)   [cc\_static\_library](c-cpp#cc_static_library) | [cc\_test](c-cpp#cc_test) | [cc\_toolchain](c-cpp#cc_toolchain)   [cc\_toolchain\_suite](c-cpp#cc_toolchain_suite)   [fdo\_prefetch\_hints](c-cpp#fdo_prefetch_hints)   [fdo\_profile](c-cpp#fdo_profile)   [memprof\_profile](c-cpp#memprof_profile)   [propeller\_optimize](c-cpp#propeller_optimize) |
-| Java | [java\_binary](java#java_binary) | [java\_import](java#java_import)   [java\_library](java#java_library) | [java\_test](java#java_test) | [java\_package\_configuration](java#java_package_configuration)   [java\_plugin](java#java_plugin)   [java\_runtime](java#java_runtime)   [java\_toolchain](java#java_toolchain) |
-| Objective-C |  | [objc\_import](objective-c#objc_import)   [objc\_library](objective-c#objc_library) |  |  |
-| Protocol Buffer |  | [cc\_proto\_library](protocol-buffer#cc_proto_library)   [java\_lite\_proto\_library](protocol-buffer#java_lite_proto_library)   [java\_proto\_library](protocol-buffer#java_proto_library)   [proto\_library](protocol-buffer#proto_library)   [py\_proto\_library](protocol-buffer#py_proto_library) |  | [proto\_lang\_toolchain](protocol-buffer#proto_lang_toolchain)   [proto\_toolchain](protocol-buffer#proto_toolchain) |
-| Python | [py\_binary](python#py_binary) | [py\_library](python#py_library) | [py\_test](python#py_test) | [py\_runtime](python#py_runtime) |
-| Shell | [sh\_binary](shell#sh_binary) | [sh\_library](shell#sh_library) | [sh\_test](shell#sh_test) |  |
+| C / C++ | [cc\_binary](/versions/8.1.1/reference/be/c-cpp#cc_binary) | [cc\_import](/versions/8.1.1/reference/be/c-cpp#cc_import)   [cc\_library](/versions/8.1.1/reference/be/c-cpp#cc_library)   [cc\_shared\_library](/versions/8.1.1/reference/be/c-cpp#cc_shared_library)   [cc\_static\_library](/versions/8.1.1/reference/be/c-cpp#cc_static_library) | [cc\_test](/versions/8.1.1/reference/be/c-cpp#cc_test) | [cc\_toolchain](/versions/8.1.1/reference/be/c-cpp#cc_toolchain)   [cc\_toolchain\_suite](/versions/8.1.1/reference/be/c-cpp#cc_toolchain_suite)   [fdo\_prefetch\_hints](/versions/8.1.1/reference/be/c-cpp#fdo_prefetch_hints)   [fdo\_profile](/versions/8.1.1/reference/be/c-cpp#fdo_profile)   [memprof\_profile](/versions/8.1.1/reference/be/c-cpp#memprof_profile)   [propeller\_optimize](/versions/8.1.1/reference/be/c-cpp#propeller_optimize) |
+| Java | [java\_binary](/versions/8.1.1/reference/be/java#java_binary) | [java\_import](/versions/8.1.1/reference/be/java#java_import)   [java\_library](/versions/8.1.1/reference/be/java#java_library) | [java\_test](/versions/8.1.1/reference/be/java#java_test) | [java\_package\_configuration](/versions/8.1.1/reference/be/java#java_package_configuration)   [java\_plugin](/versions/8.1.1/reference/be/java#java_plugin)   [java\_runtime](/versions/8.1.1/reference/be/java#java_runtime)   [java\_toolchain](/versions/8.1.1/reference/be/java#java_toolchain) |
+| Objective-C |  | [objc\_import](/versions/8.1.1/reference/be/objective-c#objc_import)   [objc\_library](/versions/8.1.1/reference/be/objective-c#objc_library) |  |  |
+| Protocol Buffer |  | [cc\_proto\_library](/versions/8.1.1/reference/be/protocol-buffer#cc_proto_library)   [java\_lite\_proto\_library](/versions/8.1.1/reference/be/protocol-buffer#java_lite_proto_library)   [java\_proto\_library](/versions/8.1.1/reference/be/protocol-buffer#java_proto_library)   [proto\_library](/versions/8.1.1/reference/be/protocol-buffer#proto_library)   [py\_proto\_library](/versions/8.1.1/reference/be/protocol-buffer#py_proto_library) |  | [proto\_lang\_toolchain](/versions/8.1.1/reference/be/protocol-buffer#proto_lang_toolchain)   [proto\_toolchain](/versions/8.1.1/reference/be/protocol-buffer#proto_toolchain) |
+| Python | [py\_binary](/versions/8.1.1/reference/be/python#py_binary) | [py\_library](/versions/8.1.1/reference/be/python#py_library) | [py\_test](/versions/8.1.1/reference/be/python#py_test) | [py\_runtime](/versions/8.1.1/reference/be/python#py_runtime) |
+| Shell | [sh\_binary](/versions/8.1.1/reference/be/shell#sh_binary) | [sh\_library](/versions/8.1.1/reference/be/shell#sh_library) | [sh\_test](/versions/8.1.1/reference/be/shell#sh_test) |  |
 
 ### Language-agnostic native rules
 
 | Family | Rules |
 | --- | --- |
-| Extra Actions | * [action\_listener](extra-actions#action_listener)* [extra\_action](extra-actions#extra_action) |
-| General | * [alias](general#alias)* [config\_setting](general#config_setting)* [filegroup](general#filegroup)* [genquery](general#genquery)* [genrule](general#genrule)* [starlark\_doc\_extract](general#starlark_doc_extract)* [test\_suite](general#test_suite) |
-| Platforms and Toolchains | * [constraint\_setting](platforms-and-toolchains#constraint_setting)* [constraint\_value](platforms-and-toolchains#constraint_value)* [platform](platforms-and-toolchains#platform)* [toolchain](platforms-and-toolchains#toolchain)* [toolchain\_type](platforms-and-toolchains#toolchain_type) |
-| Workspace | * [bind](workspace#bind)* [local\_repository](workspace#local_repository)* [new\_local\_repository](workspace#new_local_repository) |
\ No newline at end of file
+| Extra Actions | * [action\_listener](/versions/8.1.1/reference/be/extra-actions#action_listener)* [extra\_action](/versions/8.1.1/reference/be/extra-actions#extra_action) |
+| General | * [alias](/versions/8.1.1/reference/be/general#alias)* [config\_setting](/versions/8.1.1/reference/be/general#config_setting)* [filegroup](/versions/8.1.1/reference/be/general#filegroup)* [genquery](/versions/8.1.1/reference/be/general#genquery)* [genrule](/versions/8.1.1/reference/be/general#genrule)* [starlark\_doc\_extract](/versions/8.1.1/reference/be/general#starlark_doc_extract)* [test\_suite](/versions/8.1.1/reference/be/general#test_suite) |
+| Platforms and Toolchains | * [constraint\_setting](/versions/8.1.1/reference/be/platforms-and-toolchains#constraint_setting)* [constraint\_value](/versions/8.1.1/reference/be/platforms-and-toolchains#constraint_value)* [platform](/versions/8.1.1/reference/be/platforms-and-toolchains#platform)* [toolchain](/versions/8.1.1/reference/be/platforms-and-toolchains#toolchain)* [toolchain\_type](/versions/8.1.1/reference/be/platforms-and-toolchains#toolchain_type) |
+| Workspace | * [bind](/versions/8.1.1/reference/be/workspace#bind)* [local\_repository](/versions/8.1.1/reference/be/workspace#local_repository)* [new\_local\_repository](/versions/8.1.1/reference/be/workspace#new_local_repository) |
\ No newline at end of file
diff --git a/versions/8.1.1/reference/be/platforms-and-toolchains.mdx b/versions/8.1.1/reference/be/platforms-and-toolchains.mdx
index 25fcda65..8bf96bf2 100644
--- a/versions/8.1.1/reference/be/platforms-and-toolchains.mdx
+++ b/versions/8.1.1/reference/be/platforms-and-toolchains.mdx
@@ -39,7 +39,7 @@ define a platform targeting an obscure cpu architecture.
 | Attributes | |
 | --- | --- |
 | `name` | [Name](/versions/8.1.1/concepts/labels#target-names); required  A unique name for this target. |
-| `default_constraint_value` | [Name](/versions/8.1.1/concepts/labels#target-names); [nonconfigurable](common-definitions#configurable-attributes); default is `None` The label of the default value for this setting, to be used if no value is given. If this attribute is present, the `constraint_value` it points to must be defined in the same package as this `constraint_setting`. If a constraint setting has a default value, then whenever a platform does not include any constraint value for that setting, it is the same as if the platform had specified the default value. Otherwise, if there is no default value, the constraint setting is considered to be unspecified by that platform. In that case, the platform would not match against any constraint list (such as for a `config_setting`) that requires a particular value for that setting. |
+| `default_constraint_value` | [Name](/versions/8.1.1/concepts/labels#target-names); [nonconfigurable](/versions/8.1.1/reference/be/common-definitions#configurable-attributes); default is `None` The label of the default value for this setting, to be used if no value is given. If this attribute is present, the `constraint_value` it points to must be defined in the same package as this `constraint_setting`. If a constraint setting has a default value, then whenever a platform does not include any constraint value for that setting, it is the same as if the platform had specified the default value. Otherwise, if there is no default value, the constraint setting is considered to be unspecified by that platform. In that case, the platform would not match against any constraint list (such as for a `config_setting`) that requires a particular value for that setting. |
 
 ## constraint\_value
 
@@ -73,7 +73,7 @@ Platforms can then declare that they have the `mips` architecture as an alternat
 | Attributes | |
 | --- | --- |
 | `name` | [Name](/versions/8.1.1/concepts/labels#target-names); required  A unique name for this target. |
-| `constraint_setting` | [Label](/versions/8.1.1/concepts/labels); [nonconfigurable](common-definitions#configurable-attributes); required The `constraint_setting` for which this `constraint_value` is a possible choice. |
+| `constraint_setting` | [Label](/versions/8.1.1/concepts/labels); [nonconfigurable](/versions/8.1.1/reference/be/common-definitions#configurable-attributes); required The `constraint_setting` for which this `constraint_value` is a possible choice. |
 
 ## platform
 
@@ -278,11 +278,11 @@ In this example, the child platforms have the following properties:
 | Attributes | |
 | --- | --- |
 | `name` | [Name](/versions/8.1.1/concepts/labels#target-names); required  A unique name for this target. |
-| `constraint_values` | List of [labels](/versions/8.1.1/concepts/labels); [nonconfigurable](common-definitions#configurable-attributes); default is `[]` The combination of constraint choices that this platform comprises. In order for a platform to apply to a given environment, the environment must have at least the values in this list. Each `constraint_value` in this list must be for a different `constraint_setting`. For example, you cannot define a platform that requires the cpu architecture to be both `@platforms//cpu:x86_64` and `@platforms//cpu:arm`. |
-| `exec_properties` | Dictionary: String -> String; [nonconfigurable](common-definitions#configurable-attributes); default is `{}` A map of strings that affect the way actions are executed remotely. Bazel makes no attempt to interpret this, it is treated as opaque data that's forwarded via the Platform field of the [remote execution protocol](https://github.com/bazelbuild/remote-apis). This includes any data from the parent platform's `exec_properties` attributes. If the child and parent platform define the same keys, the child's values are kept. Any keys associated with a value that is an empty string are removed from the dictionary. This attribute is a full replacement for the deprecated `remote_execution_properties`. |
-| `flags` | List of strings; [nonconfigurable](common-definitions#configurable-attributes); default is `[]` A list of flags that will be enabled when this platform is used as the target platform in a configuration. Only flags that can be set in transitions are allowed to be used. |
-| `parents` | List of [labels](/versions/8.1.1/concepts/labels); [nonconfigurable](common-definitions#configurable-attributes); default is `[]` The label of a `platform` target that this platform should inherit from. Although the attribute takes a list, there should be no more than one platform present. Any constraint\_settings not set directly on this platform will be found in the parent platform. See the section on [Platform Inheritance](#platform_inheritance) for details. |
-| `remote_execution_properties` | String; [nonconfigurable](common-definitions#configurable-attributes); default is `""` DEPRECATED. Please use exec\_properties attribute instead. A string used to configure a remote execution platform. Actual builds make no attempt to interpret this, it is treated as opaque data that can be used by a specific SpawnRunner. This can include data from the parent platform's "remote\_execution\_properties" attribute, by using the macro "{PARENT\_REMOTE\_EXECUTION\_PROPERTIES}". See the section on [Platform Inheritance](#platform_inheritance) for details. |
+| `constraint_values` | List of [labels](/versions/8.1.1/concepts/labels); [nonconfigurable](/versions/8.1.1/reference/be/common-definitions#configurable-attributes); default is `[]` The combination of constraint choices that this platform comprises. In order for a platform to apply to a given environment, the environment must have at least the values in this list. Each `constraint_value` in this list must be for a different `constraint_setting`. For example, you cannot define a platform that requires the cpu architecture to be both `@platforms//cpu:x86_64` and `@platforms//cpu:arm`. |
+| `exec_properties` | Dictionary: String -> String; [nonconfigurable](/versions/8.1.1/reference/be/common-definitions#configurable-attributes); default is `{}` A map of strings that affect the way actions are executed remotely. Bazel makes no attempt to interpret this, it is treated as opaque data that's forwarded via the Platform field of the [remote execution protocol](https://github.com/bazelbuild/remote-apis). This includes any data from the parent platform's `exec_properties` attributes. If the child and parent platform define the same keys, the child's values are kept. Any keys associated with a value that is an empty string are removed from the dictionary. This attribute is a full replacement for the deprecated `remote_execution_properties`. |
+| `flags` | List of strings; [nonconfigurable](/versions/8.1.1/reference/be/common-definitions#configurable-attributes); default is `[]` A list of flags that will be enabled when this platform is used as the target platform in a configuration. Only flags that can be set in transitions are allowed to be used. |
+| `parents` | List of [labels](/versions/8.1.1/concepts/labels); [nonconfigurable](/versions/8.1.1/reference/be/common-definitions#configurable-attributes); default is `[]` The label of a `platform` target that this platform should inherit from. Although the attribute takes a list, there should be no more than one platform present. Any constraint\_settings not set directly on this platform will be found in the parent platform. See the section on [Platform Inheritance](#platform_inheritance) for details. |
+| `remote_execution_properties` | String; [nonconfigurable](/versions/8.1.1/reference/be/common-definitions#configurable-attributes); default is `""` DEPRECATED. Please use exec\_properties attribute instead. A string used to configure a remote execution platform. Actual builds make no attempt to interpret this, it is treated as opaque data that can be used by a specific SpawnRunner. This can include data from the parent platform's "remote\_execution\_properties" attribute, by using the macro "{PARENT\_REMOTE\_EXECUTION\_PROPERTIES}". See the section on [Platform Inheritance](#platform_inheritance) for details. |
 | `required_settings` | List of [labels](/versions/8.1.1/concepts/labels); default is `[]` A list of `config_setting`s that must be satisfied by the target configuration in order for this platform to be used as an execution platform during toolchain resolution. Required settings are not inherited from parent platforms. |
 
 ## toolchain
@@ -303,11 +303,11 @@ details.
 | Attributes | |
 | --- | --- |
 | `name` | [Name](/versions/8.1.1/concepts/labels#target-names); required  A unique name for this target. |
-| `exec_compatible_with` | List of [labels](/versions/8.1.1/concepts/labels); [nonconfigurable](common-definitions#configurable-attributes); default is `[]` A list of `constraint_value`s that must be satisfied by an execution platform in order for this toolchain to be selected for a target building on that platform. |
-| `target_compatible_with` | List of [labels](/versions/8.1.1/concepts/labels); [nonconfigurable](common-definitions#configurable-attributes); default is `[]` A list of `constraint_value`s that must be satisfied by the target platform in order for this toolchain to be selected for a target building for that platform. |
+| `exec_compatible_with` | List of [labels](/versions/8.1.1/concepts/labels); [nonconfigurable](/versions/8.1.1/reference/be/common-definitions#configurable-attributes); default is `[]` A list of `constraint_value`s that must be satisfied by an execution platform in order for this toolchain to be selected for a target building on that platform. |
+| `target_compatible_with` | List of [labels](/versions/8.1.1/concepts/labels); [nonconfigurable](/versions/8.1.1/reference/be/common-definitions#configurable-attributes); default is `[]` A list of `constraint_value`s that must be satisfied by the target platform in order for this toolchain to be selected for a target building for that platform. |
 | `target_settings` | List of [labels](/versions/8.1.1/concepts/labels); default is `[]` A list of `config_setting`s that must be satisfied by the target configuration in order for this toolchain to be selected during toolchain resolution. |
 | `toolchain` | [Name](/versions/8.1.1/concepts/labels#target-names); required The target representing the actual tool or tool suite that is made available when this toolchain is selected. |
-| `toolchain_type` | [Label](/versions/8.1.1/concepts/labels); [nonconfigurable](common-definitions#configurable-attributes); required The label of a `toolchain_type` target that represents the role that this toolchain serves. |
+| `toolchain_type` | [Label](/versions/8.1.1/concepts/labels); [nonconfigurable](/versions/8.1.1/reference/be/common-definitions#configurable-attributes); required The label of a `toolchain_type` target that represents the role that this toolchain serves. |
 
 ## toolchain\_type
 
@@ -351,4 +351,4 @@ bar_binary = rule(
 | Attributes | |
 | --- | --- |
 | `name` | [Name](/versions/8.1.1/concepts/labels#target-names); required  A unique name for this target. |
-| `no_match_error` | String; [nonconfigurable](common-definitions#configurable-attributes); default is `""` A custom error message to display when no matching toolchain is found for this type. |
\ No newline at end of file
+| `no_match_error` | String; [nonconfigurable](/versions/8.1.1/reference/be/common-definitions#configurable-attributes); default is `""` A custom error message to display when no matching toolchain is found for this type. |
\ No newline at end of file
diff --git a/versions/8.1.1/reference/be/protocol-buffer.mdx b/versions/8.1.1/reference/be/protocol-buffer.mdx
index 19d05d23..33a453dc 100644
--- a/versions/8.1.1/reference/be/protocol-buffer.mdx
+++ b/versions/8.1.1/reference/be/protocol-buffer.mdx
@@ -22,7 +22,7 @@ cc_proto_library(name, deps, compatible_with, deprecation, distribs, exec_compat
 
 `cc_proto_library` generates C++ code from `.proto` files.
 
-`deps` must point to [`proto_library`](protocol-buffer#proto_library) rules.
+`deps` must point to [`proto_library`](/versions/8.1.1/reference/be/protocol-buffer#proto_library) rules.
 
 Example:
 
@@ -47,7 +47,7 @@ proto_library(
 | Attributes | |
 | --- | --- |
 | `name` | [Name](/versions/8.1.1/concepts/labels#target-names); required  A unique name for this target. |
-| `deps` | List of [labels](/versions/8.1.1/concepts/labels); default is `[]` The list of [`proto_library`](protocol-buffer#proto_library) rules to generate C++ code for. |
+| `deps` | List of [labels](/versions/8.1.1/concepts/labels); default is `[]` The list of [`proto_library`](/versions/8.1.1/reference/be/protocol-buffer#proto_library) rules to generate C++ code for. |
 
 ## java\_lite\_proto\_library
 
@@ -59,7 +59,7 @@ java_lite_proto_library(name, deps, compatible_with, deprecation, distribs, exec
 
 `java_lite_proto_library` generates Java code from `.proto` files.
 
-`deps` must point to [`proto_library`](protocol-buffer#proto_library) rules.
+`deps` must point to [`proto_library`](/versions/8.1.1/reference/be/protocol-buffer#proto_library) rules.
 
 Example:
 
@@ -84,7 +84,7 @@ proto_library(
 | Attributes | |
 | --- | --- |
 | `name` | [Name](/versions/8.1.1/concepts/labels#target-names); required  A unique name for this target. |
-| `deps` | List of [labels](/versions/8.1.1/concepts/labels); default is `[]` The list of [`proto_library`](protocol-buffer#proto_library) rules to generate Java code for. |
+| `deps` | List of [labels](/versions/8.1.1/concepts/labels); default is `[]` The list of [`proto_library`](/versions/8.1.1/reference/be/protocol-buffer#proto_library) rules to generate Java code for. |
 
 ## java\_proto\_library
 
@@ -96,7 +96,7 @@ java_proto_library(name, deps, compatible_with, deprecation, distribs, exec_comp
 
 `java_proto_library` generates Java code from `.proto` files.
 
-`deps` must point to [`proto_library`](protocol-buffer#proto_library) rules.
+`deps` must point to [`proto_library`](/versions/8.1.1/reference/be/protocol-buffer#proto_library) rules.
 
 Example:
 
@@ -121,7 +121,7 @@ proto_library(
 | Attributes | |
 | --- | --- |
 | `name` | [Name](/versions/8.1.1/concepts/labels#target-names); required  A unique name for this target. |
-| `deps` | List of [labels](/versions/8.1.1/concepts/labels); default is `[]` The list of [`proto_library`](protocol-buffer#proto_library) rules to generate Java code for. |
+| `deps` | List of [labels](/versions/8.1.1/concepts/labels); default is `[]` The list of [`proto_library`](/versions/8.1.1/reference/be/protocol-buffer#proto_library) rules to generate Java code for. |
 
 ## proto\_library
 
diff --git a/versions/8.1.1/reference/be/python.mdx b/versions/8.1.1/reference/be/python.mdx
index ae5369b6..a59bffbd 100644
--- a/versions/8.1.1/reference/be/python.mdx
+++ b/versions/8.1.1/reference/be/python.mdx
@@ -22,13 +22,13 @@ py_binary(name, deps, srcs, data, args, compatible_with, deprecation, distribs,
 | Attributes | |
 | --- | --- |
 | `name` | [Name](/versions/8.1.1/concepts/labels#target-names); required  A unique name for this target. |
-| `deps` | List of [labels](/versions/8.1.1/concepts/labels); default is `[]` List of additional libraries to be linked in to the target. See comments about the [`deps` attribute typically defined by rules](https://bazel.build/reference/be/common-definitions#typical-attributes). These are typically `py\_library` rules. Targets that only provide data files used at runtime belong in the `data` attribute. |
+| `deps` | List of [labels](/versions/8.1.1/concepts/labels); default is `[]` List of additional libraries to be linked in to the target. See comments about the [`deps` attribute typically defined by rules](https://bazel.build/versions/8.1.1/reference/be/common-definitions#typical-attributes). These are typically `py\_library` rules. Targets that only provide data files used at runtime belong in the `data` attribute. |
 | `srcs` | List of [labels](/versions/8.1.1/concepts/labels); required The list of Python source files that are processed to create the target. This includes all your checked-in code and may include generated source files. The `.py` files belong in `srcs` and library targets belong in `deps`. Other binary files that may be needed at run time belong in `data`. |
-| `data` | List of [labels](/versions/8.1.1/concepts/labels); default is `[]` The list of files need by this library at runtime. See comments about the [`data` attribute typically defined by rules](https://bazel.build/reference/be/common-definitions#typical-attributes). There is no `py\_embed\_data` like there is `cc\_embed\_data` and `go\_embed\_data`. This is because Python has a concept of runtime resources. |
+| `data` | List of [labels](/versions/8.1.1/concepts/labels); default is `[]` The list of files need by this library at runtime. See comments about the [`data` attribute typically defined by rules](https://bazel.build/versions/8.1.1/reference/be/common-definitions#typical-attributes). There is no `py\_embed\_data` like there is `cc\_embed\_data` and `go\_embed\_data`. This is because Python has a concept of runtime resources. |
 | `imports` | List of strings; default is `[]` List of import directories to be added to the PYTHONPATH. Subject to "Make variable" substitution. These import directories will be added for this rule and all rules that depend on it (note: not the rules this rule depends on. Each directory will be added to `PYTHONPATH` by `py\_binary` rules that depend on this rule. The strings are repo-runfiles-root relative, Absolute paths (paths that start with `/`) and paths that references a path above the execution root are not allowed and will result in an error. |
 | `legacy_create_init` | Integer; default is `-1` Whether to implicitly create empty `\_\_init\_\_.py` files in the runfiles tree. These are created in every directory containing Python source code or shared libraries, and every parent directory of those directories, excluding the repo root directory. The default, `-1` (auto), means true unless `--incompatible\_default\_to\_explicit\_init\_py` is used. If false, the user is responsible for creating (possibly empty) `\_\_init\_\_.py` files and adding them to the `srcs` of Python targets as required. |
 | `main` | [Label](/versions/8.1.1/concepts/labels); default is `None` Optional; the name of the source file that is the main entry point of the application. This file must also be listed in `srcs`. If left unspecified, `name`, with `.py` appended, is used instead. If `name` does not match any filename in `srcs`, `main` must be specified. |
-| `precompile` | String; default is `"inherit"` Whether py source files \*\*for this target\*\* should be precompiled. Values: \* `inherit`: Allow the downstream binary decide if precompiled files are used. \* `enabled`: Compile Python source files at build time. \* `disabled`: Don't compile Python source files at build time. :::{seealso} \* The {flag}`--precompile` flag, which can override this attribute in some cases and will affect all targets when building. \* The {obj}`pyc\_collection` attribute for transitively enabling precompiling on a per-target basis. \* The [Precompiling](precompiling) docs for a guide about using precompiling. ::: |
+| `precompile` | String; default is `"inherit"` Whether py source files \*\*for this target\*\* should be precompiled. Values: \* `inherit`: Allow the downstream binary decide if precompiled files are used. \* `enabled`: Compile Python source files at build time. \* `disabled`: Don't compile Python source files at build time. :::{seealso} \* The {flag}`--precompile` flag, which can override this attribute in some cases and will affect all targets when building. \* The {obj}`pyc\_collection` attribute for transitively enabling precompiling on a per-target basis. \* The [Precompiling](/versions/8.1.1/reference/be/precompiling) docs for a guide about using precompiling. ::: |
 | `precompile_invalidation_mode` | String; default is `"auto"` How precompiled files should be verified to be up-to-date with their associated source files. Possible values are: \* `auto`: The effective value will be automatically determined by other build settings. \* `checked\_hash`: Use the pyc file if the hash of the source file matches the hash recorded in the pyc file. This is most useful when working with code that you may modify. \* `unchecked\_hash`: Always use the pyc file; don't check the pyc's hash against the source file. This is most useful when the code won't be modified. For more information on pyc invalidation modes, see https://docs.python.org/3/library/py\_compile.html#py\_compile.PycInvalidationMode |
 | `precompile_optimize_level` | Integer; default is `0` The optimization level for precompiled files. For more information about optimization levels, see the `compile()` function's `optimize` arg docs at https://docs.python.org/3/library/functions.html#compile NOTE: The value `-1` means "current interpreter", which will be the interpreter used \_at build time when pycs are generated\_, not the interpreter used at runtime when the code actually runs. |
 | `precompile_source_retention` | String; default is `"inherit"` Determines, when a source file is compiled, if the source file is kept in the resulting output or not. Valid values are: \* `inherit`: Inherit the value from the {flag}`--precompile\_source\_retention` flag. \* `keep\_source`: Include the original Python source. \* `omit\_source`: Don't include the original py source. |
@@ -61,11 +61,11 @@ Source files are no longer added to the runfiles directly.
 | Attributes | |
 | --- | --- |
 | `name` | [Name](/versions/8.1.1/concepts/labels#target-names); required  A unique name for this target. |
-| `deps` | List of [labels](/versions/8.1.1/concepts/labels); default is `[]` List of additional libraries to be linked in to the target. See comments about the [`deps` attribute typically defined by rules](https://bazel.build/reference/be/common-definitions#typical-attributes). These are typically `py\_library` rules. Targets that only provide data files used at runtime belong in the `data` attribute. |
+| `deps` | List of [labels](/versions/8.1.1/concepts/labels); default is `[]` List of additional libraries to be linked in to the target. See comments about the [`deps` attribute typically defined by rules](https://bazel.build/versions/8.1.1/reference/be/common-definitions#typical-attributes). These are typically `py\_library` rules. Targets that only provide data files used at runtime belong in the `data` attribute. |
 | `srcs` | List of [labels](/versions/8.1.1/concepts/labels); default is `[]` The list of Python source files that are processed to create the target. This includes all your checked-in code and may include generated source files. The `.py` files belong in `srcs` and library targets belong in `deps`. Other binary files that may be needed at run time belong in `data`. |
-| `data` | List of [labels](/versions/8.1.1/concepts/labels); default is `[]` The list of files need by this library at runtime. See comments about the [`data` attribute typically defined by rules](https://bazel.build/reference/be/common-definitions#typical-attributes). There is no `py\_embed\_data` like there is `cc\_embed\_data` and `go\_embed\_data`. This is because Python has a concept of runtime resources. |
+| `data` | List of [labels](/versions/8.1.1/concepts/labels); default is `[]` The list of files need by this library at runtime. See comments about the [`data` attribute typically defined by rules](https://bazel.build/versions/8.1.1/reference/be/common-definitions#typical-attributes). There is no `py\_embed\_data` like there is `cc\_embed\_data` and `go\_embed\_data`. This is because Python has a concept of runtime resources. |
 | `imports` | List of strings; default is `[]` List of import directories to be added to the PYTHONPATH. Subject to "Make variable" substitution. These import directories will be added for this rule and all rules that depend on it (note: not the rules this rule depends on. Each directory will be added to `PYTHONPATH` by `py\_binary` rules that depend on this rule. The strings are repo-runfiles-root relative, Absolute paths (paths that start with `/`) and paths that references a path above the execution root are not allowed and will result in an error. |
-| `precompile` | String; default is `"inherit"` Whether py source files \*\*for this target\*\* should be precompiled. Values: \* `inherit`: Allow the downstream binary decide if precompiled files are used. \* `enabled`: Compile Python source files at build time. \* `disabled`: Don't compile Python source files at build time. :::{seealso} \* The {flag}`--precompile` flag, which can override this attribute in some cases and will affect all targets when building. \* The {obj}`pyc\_collection` attribute for transitively enabling precompiling on a per-target basis. \* The [Precompiling](precompiling) docs for a guide about using precompiling. ::: |
+| `precompile` | String; default is `"inherit"` Whether py source files \*\*for this target\*\* should be precompiled. Values: \* `inherit`: Allow the downstream binary decide if precompiled files are used. \* `enabled`: Compile Python source files at build time. \* `disabled`: Don't compile Python source files at build time. :::{seealso} \* The {flag}`--precompile` flag, which can override this attribute in some cases and will affect all targets when building. \* The {obj}`pyc\_collection` attribute for transitively enabling precompiling on a per-target basis. \* The [Precompiling](/versions/8.1.1/reference/be/precompiling) docs for a guide about using precompiling. ::: |
 | `precompile_invalidation_mode` | String; default is `"auto"` How precompiled files should be verified to be up-to-date with their associated source files. Possible values are: \* `auto`: The effective value will be automatically determined by other build settings. \* `checked\_hash`: Use the pyc file if the hash of the source file matches the hash recorded in the pyc file. This is most useful when working with code that you may modify. \* `unchecked\_hash`: Always use the pyc file; don't check the pyc's hash against the source file. This is most useful when the code won't be modified. For more information on pyc invalidation modes, see https://docs.python.org/3/library/py\_compile.html#py\_compile.PycInvalidationMode |
 | `precompile_optimize_level` | Integer; default is `0` The optimization level for precompiled files. For more information about optimization levels, see the `compile()` function's `optimize` arg docs at https://docs.python.org/3/library/functions.html#compile NOTE: The value `-1` means "current interpreter", which will be the interpreter used \_at build time when pycs are generated\_, not the interpreter used at runtime when the code actually runs. |
 | `precompile_source_retention` | String; default is `"inherit"` Determines, when a source file is compiled, if the source file is kept in the resulting output or not. Valid values are: \* `inherit`: Inherit the value from the {flag}`--precompile\_source\_retention` flag. \* `keep\_source`: Include the original Python source. \* `omit\_source`: Don't include the original py source. |
@@ -84,13 +84,13 @@ py_test(name, deps, srcs, data, args, compatible_with, deprecation, distribs, en
 | Attributes | |
 | --- | --- |
 | `name` | [Name](/versions/8.1.1/concepts/labels#target-names); required  A unique name for this target. |
-| `deps` | List of [labels](/versions/8.1.1/concepts/labels); default is `[]` List of additional libraries to be linked in to the target. See comments about the [`deps` attribute typically defined by rules](https://bazel.build/reference/be/common-definitions#typical-attributes). These are typically `py\_library` rules. Targets that only provide data files used at runtime belong in the `data` attribute. |
+| `deps` | List of [labels](/versions/8.1.1/concepts/labels); default is `[]` List of additional libraries to be linked in to the target. See comments about the [`deps` attribute typically defined by rules](https://bazel.build/versions/8.1.1/reference/be/common-definitions#typical-attributes). These are typically `py\_library` rules. Targets that only provide data files used at runtime belong in the `data` attribute. |
 | `srcs` | List of [labels](/versions/8.1.1/concepts/labels); required The list of Python source files that are processed to create the target. This includes all your checked-in code and may include generated source files. The `.py` files belong in `srcs` and library targets belong in `deps`. Other binary files that may be needed at run time belong in `data`. |
-| `data` | List of [labels](/versions/8.1.1/concepts/labels); default is `[]` The list of files need by this library at runtime. See comments about the [`data` attribute typically defined by rules](https://bazel.build/reference/be/common-definitions#typical-attributes). There is no `py\_embed\_data` like there is `cc\_embed\_data` and `go\_embed\_data`. This is because Python has a concept of runtime resources. |
+| `data` | List of [labels](/versions/8.1.1/concepts/labels); default is `[]` The list of files need by this library at runtime. See comments about the [`data` attribute typically defined by rules](https://bazel.build/versions/8.1.1/reference/be/common-definitions#typical-attributes). There is no `py\_embed\_data` like there is `cc\_embed\_data` and `go\_embed\_data`. This is because Python has a concept of runtime resources. |
 | `imports` | List of strings; default is `[]` List of import directories to be added to the PYTHONPATH. Subject to "Make variable" substitution. These import directories will be added for this rule and all rules that depend on it (note: not the rules this rule depends on. Each directory will be added to `PYTHONPATH` by `py\_binary` rules that depend on this rule. The strings are repo-runfiles-root relative, Absolute paths (paths that start with `/`) and paths that references a path above the execution root are not allowed and will result in an error. |
 | `legacy_create_init` | Integer; default is `-1` Whether to implicitly create empty `\_\_init\_\_.py` files in the runfiles tree. These are created in every directory containing Python source code or shared libraries, and every parent directory of those directories, excluding the repo root directory. The default, `-1` (auto), means true unless `--incompatible\_default\_to\_explicit\_init\_py` is used. If false, the user is responsible for creating (possibly empty) `\_\_init\_\_.py` files and adding them to the `srcs` of Python targets as required. |
 | `main` | [Label](/versions/8.1.1/concepts/labels); default is `None` Optional; the name of the source file that is the main entry point of the application. This file must also be listed in `srcs`. If left unspecified, `name`, with `.py` appended, is used instead. If `name` does not match any filename in `srcs`, `main` must be specified. |
-| `precompile` | String; default is `"inherit"` Whether py source files \*\*for this target\*\* should be precompiled. Values: \* `inherit`: Allow the downstream binary decide if precompiled files are used. \* `enabled`: Compile Python source files at build time. \* `disabled`: Don't compile Python source files at build time. :::{seealso} \* The {flag}`--precompile` flag, which can override this attribute in some cases and will affect all targets when building. \* The {obj}`pyc\_collection` attribute for transitively enabling precompiling on a per-target basis. \* The [Precompiling](precompiling) docs for a guide about using precompiling. ::: |
+| `precompile` | String; default is `"inherit"` Whether py source files \*\*for this target\*\* should be precompiled. Values: \* `inherit`: Allow the downstream binary decide if precompiled files are used. \* `enabled`: Compile Python source files at build time. \* `disabled`: Don't compile Python source files at build time. :::{seealso} \* The {flag}`--precompile` flag, which can override this attribute in some cases and will affect all targets when building. \* The {obj}`pyc\_collection` attribute for transitively enabling precompiling on a per-target basis. \* The [Precompiling](/versions/8.1.1/reference/be/precompiling) docs for a guide about using precompiling. ::: |
 | `precompile_invalidation_mode` | String; default is `"auto"` How precompiled files should be verified to be up-to-date with their associated source files. Possible values are: \* `auto`: The effective value will be automatically determined by other build settings. \* `checked\_hash`: Use the pyc file if the hash of the source file matches the hash recorded in the pyc file. This is most useful when working with code that you may modify. \* `unchecked\_hash`: Always use the pyc file; don't check the pyc's hash against the source file. This is most useful when the code won't be modified. For more information on pyc invalidation modes, see https://docs.python.org/3/library/py\_compile.html#py\_compile.PycInvalidationMode |
 | `precompile_optimize_level` | Integer; default is `0` The optimization level for precompiled files. For more information about optimization levels, see the `compile()` function's `optimize` arg docs at https://docs.python.org/3/library/functions.html#compile NOTE: The value `-1` means "current interpreter", which will be the interpreter used \_at build time when pycs are generated\_, not the interpreter used at runtime when the code actually runs. |
 | `precompile_source_retention` | String; default is `"inherit"` Determines, when a source file is compiled, if the source file is kept in the resulting output or not. Valid values are: \* `inherit`: Inherit the value from the {flag}`--precompile\_source\_retention` flag. \* `keep\_source`: Include the original Python source. \* `omit\_source`: Don't include the original py source. |
diff --git a/versions/8.1.1/reference/be/workspace.mdx b/versions/8.1.1/reference/be/workspace.mdx
index 79332940..5fe10537 100644
--- a/versions/8.1.1/reference/be/workspace.mdx
+++ b/versions/8.1.1/reference/be/workspace.mdx
@@ -25,8 +25,7 @@ bind(name, actual, compatible_with, deprecation, distribs, features, licenses, r
 
 *Warning: use of `bind()` is not recommended. See "[Consider removing bind](https://github.com/bazelbuild/bazel/issues/1952)" for a long
 discussion of its issues and alternatives. In particular, consider the use of
-[`repo_mapping`
-repository attributes](https://bazel.build/versions/8.1.1/rules/repository_rules#attributes).*
+[`repo_mapping` repository attributes](https://bazel.build/versions/8.1.1/rules/repository_rules#attributes).*
 
 *Warning: `select()` cannot be used in `bind()`. See the [Configurable Attributes FAQ](/versions/8.1.1/docs/configurable-attributes#bind-select) for
 details.*
@@ -114,8 +113,7 @@ local_repository(name, path, repo_mapping)
 ```
 
 Allows targets from a local directory to be bound. This means that the current repository can
-use targets defined in this other directory. See the [bind
-section](/versions/8.1.1/reference/be/workspace#bind_examples) for more details.
+use targets defined in this other directory. See the [bind section](/versions/8.1.1/reference/be/workspace#bind_examples) for more details.
 
 #### Examples
 
diff --git a/versions/8.1.1/reference/command-line-reference.mdx b/versions/8.1.1/reference/command-line-reference.mdx
index 65e5f306..26d0cf48 100644
--- a/versions/8.1.1/reference/command-line-reference.mdx
+++ b/versions/8.1.1/reference/command-line-reference.mdx
@@ -492,7 +492,7 @@ This option affects semantics of the Starlark language or the build API accessib
     [`loading_and_analysis`](#effect_tag_LOADING_AND_ANALYSIS), [`experimental`](#metadata_tag_EXPERIMENTAL)
 
 `--[no]experimental_isolated_extension_usages` default: "false"
-:   If true, enables the isolate parameter in the use\_extension function.
+:   If true, enables the isolate parameter in the use\_extension function.
 
     Tags:
     [`loading_and_analysis`](#effect_tag_LOADING_AND_ANALYSIS)
diff --git a/versions/8.1.1/reference/glossary.mdx b/versions/8.1.1/reference/glossary.mdx
index 691585dc..c21764ae 100644
--- a/versions/8.1.1/reference/glossary.mdx
+++ b/versions/8.1.1/reference/glossary.mdx
@@ -21,8 +21,7 @@ An in-memory graph of [actions](#action) and the [artifacts](#artifact) that
 these actions read and generate. The graph might include artifacts that exist as
 source files (for example, in the file system) as well as generated
 intermediate/final artifacts that are not mentioned in `BUILD` files. Produced
-during the [analysis phase](#analysis-phase) and used during the [execution
-phase](#execution-phase).
+during the [analysis phase](#analysis-phase) and used during the [execution phase](#execution-phase).
 
 ### Action graph query (aquery) {#action-graph-query}
 A [query](#query-concept) tool that can query over build [actions](#action).
@@ -37,8 +36,7 @@ invalidate individual actions deterministically.
 
 ### Analysis phase {#analysis-phase}
 The second phase of a build. Processes the [target graph](#target-graph)
-specified in [`BUILD` files](#build-file) to produce an in-memory [action
-graph](#action-graph) that determines the order of actions to run during the
+specified in [`BUILD` files](#build-file) to produce an in-memory [action graph](#action-graph) that determines the order of actions to run during the
 [execution phase](#execution-phase). This is the phase in which rule
 implementations are evaluated.
 
@@ -81,8 +79,7 @@ target's source files, dependencies, and custom compiler options. The particular
 attributes available for a given target depend on its rule type.
 
 ### .bazelrc {#bazelrc}
-Bazel’s configuration file used to change the default values for [startup
-flags](#startup-flags) and [command flags](#command-flags), and to define common
+Bazel’s configuration file used to change the default values for [startup flags](#startup-flags) and [command flags](#command-flags), and to define common
 groups of options that can then be set together on the Bazel command line using
 a `--config` flag. Bazel can combine settings from multiple bazelrc files
 (systemwide, per-workspace, per-user, or from a custom location), and a
@@ -108,8 +105,7 @@ directory.
 
 ### .bzl File {#bzl-file}
 A file that defines rules, [macros](#macro), and constants written in
-[Starlark](#starlark). These can then be imported into [`BUILD`
-files](#build-file) using the `load()` function.
+[Starlark](#starlark). These can then be imported into [`BUILD` files](#build-file) using the `load()` function.
 
 {/* TODO: ### Build event protocol */}
 
@@ -117,8 +113,7 @@ files](#build-file) using the `load()` function.
 
 ### Build graph {#build-graph}
 The dependency graph that Bazel constructs and traverses to perform a build.
-Includes nodes like [targets](#target), [configured
-targets](#configured-target), [actions](#action), and [artifacts](#artifact). A
+Includes nodes like [targets](#target), [configured targets](#configured-target), [actions](#action), and [artifacts](#artifact). A
 build is considered complete when all [artifacts](#artifact) on which a set of
 requested targets depend are verified as up-to-date.
 
@@ -158,8 +153,7 @@ graphs and restart the [analysis phase](#analysis-phase).
 ### Configuration {#configuration}
 Information outside of [rule](#rule) definitions that impacts how rules generate
 [actions](#action). Every build has at least one configuration specifying the
-target platform, action environment variables, and command-line [build
-flags](#command-flags). [Transitions](#transition) may create additional
+target platform, action environment variables, and command-line [build flags](#command-flags). [Transitions](#transition) may create additional
 configurations, such as for host tools or cross-compilation.
 
 **See also:** [Configurations](/versions/8.1.1/extending/rules#configurations)
@@ -174,8 +168,7 @@ configuration of `//:c` because changing `--javacopt` unnecessarily breaks C++
 build cacheability.
 
 ### Configured query (cquery) {#configured-query}
-A [query](#query-concept) tool that queries over [configured
-targets](#configured-target) (after the [analysis phase](#analysis-phase)
+A [query](#query-concept) tool that queries over [configured targets](#configured-target) (after the [analysis phase](#analysis-phase)
 completes). This means `select()` and [build flags](#command-flags) (such as
 `--platforms`) are accurately reflected in the results.
 
@@ -191,8 +184,7 @@ build, it has two configured targets: `` and ``.
 ### Correctness {#correctness}
 A build is correct when its output faithfully reflects the state of its
 transitive inputs. To achieve correct builds, Bazel strives to be
-[hermetic](#hermeticity), reproducible, and making [build
-analysis](#analysis-phase) and [action execution](#execution-phase)
+[hermetic](#hermeticity), reproducible, and making [build analysis](#analysis-phase) and [action execution](#execution-phase)
 deterministic.
 
 ### Dependency {#dependency}
@@ -234,8 +226,7 @@ compilation). A dynamic execution strategy can provide the best possible
 incremental and clean build times.
 
 ### Execution phase {#execution-phase}
-The third phase of a build. Executes the [actions](#action) in the [action
-graph](#action-graph) created during the [analysis phase](#analysis-phase).
+The third phase of a build. Executes the [actions](#action) in the [action graph](#action-graph) created during the [analysis phase](#analysis-phase).
 These actions invoke executables (compilers, scripts) to read and write
 [artifacts](#artifact). *Spawn strategies* control how these actions are
 executed: locally, remotely, dynamically, sandboxed, docker, and so on.
@@ -285,8 +276,7 @@ syntax may be omitted.
 The first phase of a build where Bazel executes [`BUILD` files](#build-file) to
 create [packages](#package). [Macros](#macro) and certain functions like
 `glob()` are evaluated in this phase. Interleaved with the second phase of the
-build, the [analysis phase](#analysis-phase), to build up a [target
-graph](#target-graph).
+build, the [analysis phase](#analysis-phase), to build up a [target graph](#target-graph).
 
 ### Legacy macro {#legacy-macro}
 A flavor of [macro](#macro) which is declared as an ordinary
@@ -336,8 +326,7 @@ Module metadata is hosted in Bazel registries.
 
 ### Module Extension {#module-extension}
 A piece of logic that can be run to generate [repos](#repository) by reading
-inputs from across the [module](#module) dependency graph and invoking [repo
-rules](#repository-rule). Module extensions have capabilities similar to repo
+inputs from across the [module](#module) dependency graph and invoking [repo rules](#repository-rule). Module extensions have capabilities similar to repo
 rules, allowing them to access the internet, perform file I/O, and so on.
 
 **See also:** [Module extensions](/versions/8.1.1/external/extension)
@@ -350,8 +339,7 @@ example, `native.cc_library` or `native.java_library`). User-defined rules
 
 ### Output base {#output-base}
 A [workspace](#workspace)-specific directory to store Bazel output files. Used
-to separate outputs from the *workspace*'s source tree (the [main
-repo](#repository)). Located in the [output user root](#output-user-root).
+to separate outputs from the *workspace*'s source tree (the [main repo](#repository)). Located in the [output user root](#output-user-root).
 
 ### Output groups {#output-groups}
 A group of files that is expected to be built when Bazel finishes building a
@@ -406,8 +394,7 @@ query variants: [query](#query-command), [cquery](#configured-query), and
 [aquery](#action-graph-query).
 
 ### query (command) {#query-command}
-A [query](#query-concept) tool that operates over the build's post-[loading
-phase](#loading-phase) [target graph](#target-graph). This is relatively fast,
+A [query](#query-concept) tool that operates over the build's post-[loading phase](#loading-phase) [target graph](#target-graph). This is relatively fast,
 but can't analyze the effects of `select()`, [build flags](#command-flags),
 [artifacts](#artifact), or build [actions](#action).
 
@@ -425,8 +412,7 @@ repo; multiple such files can coexist in a directory.
 The *main repo* is the repo in which the current Bazel command is being run.
 
 *External repos* are defined by specifying [modules](#module) in `MODULE.bazel`
-files, or invoking [repo rules](#repository-rule) in [module
-extensions](#module-extension). They can be fetched on demand to a predetermined
+files, or invoking [repo rules](#repository-rule) in [module extensions](#module-extension). They can be fetched on demand to a predetermined
 "magical" location on disk.
 
 Each repo has a unique, constant *canonical* name, and potentially different
@@ -437,8 +423,7 @@ Each repo has a unique, constant *canonical* name, and potentially different
 ### Repository cache {#repo-cache}
 A shared content-addressable cache of files downloaded by Bazel for builds,
 shareable across [workspaces](#workspace). Enables offline builds after the
-initial download. Commonly used to cache files downloaded through [repository
-rules](#repository-rule) like `http_archive` and repository rule APIs like
+initial download. Commonly used to cache files downloaded through [repository rules](#repository-rule) like `http_archive` and repository rule APIs like
 `repository_ctx.download`. Files are cached only if their SHA-256 checksums are
 specified for the download.
 
@@ -472,8 +457,7 @@ Rules are instantiated to produce rule targets in the
 [loading phase](#loading-phase). In the [analysis phase](#analysis-phase) rule
 targets communicate information to their downstream dependencies in the form of
 [providers](#provider), and register [actions](#action) describing how to
-generate their output artifacts. These actions are run in the [execution
-phase](#execution-phase).
+generate their output artifacts. These actions are run in the [execution phase](#execution-phase).
 
 Note: Historically the term "rule" has been used to refer to a rule target.
 This usage was inherited from tools like Make, but causes confusion and should
@@ -517,8 +501,7 @@ support the stamp attribute.
 ### Starlark {#starlark}
 The extension language for writing [rules](/versions/8.1.1/extending/rules) and [macros](#macro). A
 restricted subset of Python (syntactically and grammatically) aimed for the
-purpose of configuration, and for better performance. Uses the [`.bzl`
-file](#bzl-file) extension. [`BUILD` files](#build-file) use an even more
+purpose of configuration, and for better performance. Uses the [`.bzl` file](#bzl-file) extension. [`BUILD` files](#build-file) use an even more
 restricted version of Starlark (such as no `def` function definitions), formerly
 known as Skylark.
 
@@ -549,8 +532,7 @@ An object that is defined in a [`BUILD` file](#build-file) and identified by a
 [label](#label). Targets represent the buildable units of a workspace from
 the perspective of the end user.
 
-A target that is declared by instantiating a [rule](#rule) is called a [rule
-target](#rule-target). Depending on the rule, these may be runnable (like
+A target that is declared by instantiating a [rule](#rule) is called a [rule target](#rule-target). Depending on the rule, these may be runnable (like
 `cc_binary`) or testable (like `cc_test`). Rule targets typically depend on
 other targets via their [attributes](#attribute) (such as `deps`); these
 dependencies form the basis of the [target graph](#target-graph).
@@ -561,14 +543,11 @@ within a `BUILD` file. As a special case, the `BUILD` file of any package is
 always considered a source file target in that package.
 
 Targets are discovered during the [loading phase](#loading-phase). During the
-[analysis phase](#analysis-phase), targets are associated with [build
-configurations](#configuration) to form [configured
-targets](#configured-target).
+[analysis phase](#analysis-phase), targets are associated with [build configurations](#configuration) to form [configured targets](#configured-target).
 
 ### Target graph {#target-graph}
 An in-memory graph of [targets](#target) and their dependencies. Produced during
-the [loading phase](#loading-phase) and used as an input to the [analysis
-phase](#analysis-phase).
+the [loading phase](#loading-phase) and used as an input to the [analysis phase](#analysis-phase).
 
 ### Target pattern {#target-pattern}
 A way to specify a group of [targets](#target) on the command line. Commonly
@@ -581,8 +560,7 @@ packages recursively from the root of the [workspace](#workspace).
 Rule [targets](#target) instantiated from test rules, and therefore contains a
 test executable. A return code of zero from the completion of the executable
 indicates test success. The exact contract between Bazel and tests (such as test
-environment variables, test result collection methods) is specified in the [Test
-Encyclopedia](/versions/8.1.1/reference/test-encyclopedia).
+environment variables, test result collection methods) is specified in the [Test Encyclopedia](/versions/8.1.1/reference/test-encyclopedia).
 
 ### Toolchain {#toolchain}
 A set of tools to build outputs for a language. Typically, a toolchain includes
@@ -596,8 +574,7 @@ A build [target](#target) is top-level if it’s requested on the Bazel command
 line. For example, if `//:foo` depends on `//:bar`, and `bazel build //:foo` is
 called, then for this build, `//:foo` is top-level, and `//:bar` isn’t
 top-level, although both targets will need to be built. An important difference
-between top-level and non-top-level targets is that [command
-flags](#command-flags) set on the Bazel command line (or via
+between top-level and non-top-level targets is that [command flags](#command-flags) set on the Bazel command line (or via
 [.bazelrc](#bazelrc)) will set the [configuration](#configuration) for top-level
 targets, but might be modified by a [transition](#transition) for non-top-level
 targets.
@@ -628,8 +605,7 @@ or `.bzl` file may load a given `.bzl` file. Without context, usually
 **See also:** [Visibility documentation](/versions/8.1.1/concepts/visibility)
 
 ### Workspace {#workspace}
-The environment shared by all Bazel commands run from the same [main
-repository](#repository).
+The environment shared by all Bazel commands run from the same [main repository](#repository).
 
 Note that historically the concepts of "repository" and "workspace" have been
 conflated; the term "workspace" has often been used to refer to the main
diff --git a/versions/8.1.1/release/backward-compatibility.mdx b/versions/8.1.1/release/backward-compatibility.mdx
index 1dfb6403..9c6d4576 100644
--- a/versions/8.1.1/release/backward-compatibility.mdx
+++ b/versions/8.1.1/release/backward-compatibility.mdx
@@ -6,11 +6,9 @@ This page provides information about how to handle backward compatibility,
 including migrating from one release to another and how to communicate
 incompatible changes.
 
-Bazel is evolving. Minor versions released as part of an [LTS major
-version](/versions/8.1.1/release#bazel-versioning) are fully backward-compatible. New major LTS
+Bazel is evolving. Minor versions released as part of an [LTS major version](/versions/8.1.1/release#bazel-versioning) are fully backward-compatible. New major LTS
 releases may contain incompatible changes that require some migration effort.
-For more information about Bazel's release model, please check out the [Release
-Model](/versions/8.1.1/release) page.
+For more information about Bazel's release model, please check out the [Release Model](/versions/8.1.1/release) page.
 
 ## Summary {#summary}
 
@@ -59,8 +57,7 @@ available.
 ## Communicating incompatible changes {#communicating-incompatible-changes}
 
 The primary source of information about incompatible changes are GitHub issues
-marked with an ["incompatible-change"
-label](https://github.com/bazelbuild/bazel/issues?q=label%3Aincompatible-change).
+marked with an ["incompatible-change" label](https://github.com/bazelbuild/bazel/issues?q=label%3Aincompatible-change).
 
 For every incompatible change, the issue specifies the following:
 
diff --git a/versions/8.1.1/release/index.mdx b/versions/8.1.1/release/index.mdx
index f4d996e0..cd948d48 100644
--- a/versions/8.1.1/release/index.mdx
+++ b/versions/8.1.1/release/index.mdx
@@ -2,8 +2,7 @@
 title: 'Release Model'
 ---
 
-As announced in [the original blog
-post](https://blog.bazel.build/2020/11/10/long-term-support-release.html), Bazel
+As announced in [the original blog post](https://blog.bazel.build/2020/11/10/long-term-support-release.html), Bazel
 4.0 and higher versions provides support for two release tracks: rolling
 releases and long term support (LTS) releases. This page covers the latest
 information about Bazel's release model.
@@ -19,8 +18,7 @@ information about Bazel's release model.
 | Bazel 5 | Maintenance | [5.4.1](https://github.com/bazelbuild/bazel/releases/tag/5.4.1) | Jan 2025 |
 | Bazel 4 | Deprecated | [4.2.4](https://github.com/bazelbuild/bazel/releases/tag/4.2.4) | Jan 2024 |
 
-All Bazel LTS releases can be found on the [release
-page](https://github.com/bazelbuild/bazel/releases) on GitHub.
+All Bazel LTS releases can be found on the [release page](https://github.com/bazelbuild/bazel/releases) on GitHub.
 
 Note: Bazel version older than Bazel 5 are no longer supported, Bazel users are
 recommended to upgrade to the latest LTS release or use rolling releases if you
@@ -28,8 +26,7 @@ want to keep up with the latest changes at HEAD.
 
 ## Release versioning {#bazel-versioning}
 
-Bazel uses a _major.minor.patch_ [Semantic
-Versioning](https://semver.org/) scheme.
+Bazel uses a _major.minor.patch_ [Semantic Versioning](https://semver.org/) scheme.
 
 *   A _major release_ contains features that are not backward compatible with
     the previous release. Each major Bazel version is an LTS release.
@@ -72,8 +69,7 @@ Bazel regularly publish releases for two release tracks.
     release.
 *   Rolling releases can ship incompatible changes. Incompatible flags are
     recommended for major breaking changes, rolling out incompatible changes
-    should follow our [backward compatibility
-    policy](/versions/8.1.1/release/backward-compatibility).
+    should follow our [backward compatibility policy](/versions/8.1.1/release/backward-compatibility).
 
 ### LTS releases {#lts-releases}
 
@@ -89,8 +85,7 @@ Bazel regularly publish releases for two release tracks.
 *   A Bazel LTS release enters the Deprecated stage after being in ​​the
     Maintenance stage for 2 years.
 
-For planned releases, please check our [release
-issues](https://github.com/bazelbuild/bazel/issues?q=is%3Aopen+is%3Aissue+label%3Arelease)
+For planned releases, please check our [release issues](https://github.com/bazelbuild/bazel/issues?q=is%3Aopen+is%3Aissue+label%3Arelease)
 on Github.
 
 ## Release procedure & policies {#release-procedure-policies}
@@ -153,8 +148,7 @@ For LTS releases, the procedure and policies below are followed:
 1.  Identify release blockers and fix issues found on the release branch.
     *   The release branch is tested with the same test suite in
         [postsubmit](https://buildkite.com/bazel/bazel-bazel) and
-        [downstream test pipeline]
-        (https://buildkite.com/bazel/bazel-at-head-plus-downstream)
+        [downstream test pipeline](https://buildkite.com/bazel/bazel-at-head-plus-downstream)
         on Bazel CI. The Bazel team monitors testing results of the release
         branch and fixes any regressions found.
 1.  Create a new release candidate from the release branch when all known
@@ -210,5 +204,4 @@ feature.
 ## Rule compatibility {#rule-compatibility}
 
 If you are a rule authors and want to maintain compatibility with different
-Bazel versions, please check out the [Rule
-Compatibility](/versions/8.1.1/release/rule-compatibility) page.
+Bazel versions, please check out the [Rule Compatibility](/versions/8.1.1/release/rule-compatibility) page.
diff --git a/versions/8.1.1/release/rule-compatibility.mdx b/versions/8.1.1/release/rule-compatibility.mdx
index 8d3b0bdc..5317d4a4 100644
--- a/versions/8.1.1/release/rule-compatibility.mdx
+++ b/versions/8.1.1/release/rule-compatibility.mdx
@@ -53,18 +53,15 @@ Bazel LTS release.
 As Bazel rules authors, you can ensure a manageable migration process for users
 by following these best practices:
 
-1.  The rule should follow [Semantic
-    Versioning](https://semver.org/): minor versions of the same
+1.  The rule should follow [Semantic Versioning](https://semver.org/): minor versions of the same
     major version are backward compatible.
 1.  The rule at HEAD should be compatible with the latest Bazel LTS release.
 1.  The rule at HEAD should be compatible with Bazel at HEAD. To achieve this,
     you can
     *   Set up your own CI testing with Bazel at HEAD
-    *   Add your project to [Bazel downstream
-        testing](https://github.com/bazelbuild/continuous-integration/blob/master/docs/downstream-testing.md);
+    *   Add your project to [Bazel downstream testing](https://github.com/bazelbuild/continuous-integration/blob/master/docs/downstream-testing.md);
         the Bazel team files issues to your project if breaking changes in Bazel
-        affect your project, and you must follow our [downstream project
-        policies](https://github.com/bazelbuild/continuous-integration/blob/master/docs/downstream-testing.md#downstream-project-policies)
+        affect your project, and you must follow our [downstream project policies](https://github.com/bazelbuild/continuous-integration/blob/master/docs/downstream-testing.md#downstream-project-policies)
         to address issues timely.
 1.  The latest major version of the rule must be compatible with the latest
     Bazel LTS release.
diff --git a/versions/8.1.1/remote/bep-glossary.mdx b/versions/8.1.1/remote/bep-glossary.mdx
index f13ee4cb..b6bead11 100644
--- a/versions/8.1.1/remote/bep-glossary.mdx
+++ b/versions/8.1.1/remote/bep-glossary.mdx
@@ -36,7 +36,7 @@ BEP contains an event like the following:
 ## ActionExecuted {#actionexecuted}
 
 Provides details about the execution of a specific
-[Action](/versions/8.1.1/rules/lib/actions) in a build. By default, this event is
+[Action](/versions/8.1.1/rules/lib/builtins/actions) in a build. By default, this event is
 included in the BEP only for failed actions, to support identifying the root cause
 of build failures. Users may set the `--build_event_publish_all_actions` flag
 to include all `ActionExecuted` events.
@@ -410,5 +410,4 @@ workspace, such as the execution root.
 
 ## WorkspaceStatus {#workspacestatus}
 
-A single `WorkspaceStatus` event contains the result of the [workspace status
-command](/versions/8.1.1/docs/user-manual#workspace-status).
+A single `WorkspaceStatus` event contains the result of the [workspace status command](/versions/8.1.1/docs/user-manual#workspace-status).
diff --git a/versions/8.1.1/remote/bep.mdx b/versions/8.1.1/remote/bep.mdx
index fbce7e69..d01fa66f 100644
--- a/versions/8.1.1/remote/bep.mdx
+++ b/versions/8.1.1/remote/bep.mdx
@@ -2,14 +2,12 @@
 title: 'Build Event Protocol'
 ---
 
-The [Build Event
-Protocol](https://github.com/bazelbuild/bazel/blob/master/src/main/java/com/google/devtools/build/lib/buildeventstream/proto/build_event_stream.proto)
+The [Build Event Protocol](https://github.com/bazelbuild/bazel/blob/master/src/main/java/com/google/devtools/build/lib/buildeventstream/proto/build_event_stream.proto)
 (BEP) allows third-party programs to gain insight into a Bazel invocation. For
 example, you could use the BEP to gather information for an IDE
 plugin or a dashboard that displays build results.
 
-The protocol is a set of [protocol
-buffer](https://developers.google.com/protocol-buffers/) messages with some
+The protocol is a set of [protocol buffer](https://developers.google.com/protocol-buffers/) messages with some
 semantics defined on top of it. It includes information about build and test
 results, build progress, the build configuration and much more. The BEP is
 intended to be consumed programmatically and makes parsing Bazel’s
@@ -20,16 +18,13 @@ build event is a protocol buffer message consisting of a build event identifier,
 a set of child event identifiers, and a payload.
 
 *  __Build Event Identifier:__ Depending on the kind of build event, it might be
-an [opaque
-string](https://github.com/bazelbuild/bazel/blob/7.1.0/src/main/java/com/google/devtools/build/lib/buildeventstream/proto/build_event_stream.proto#L131-L140)
-or [structured
-information](https://github.com/bazelbuild/bazel/blob/7.1.0/src/main/java/com/google/devtools/build/lib/buildeventstream/proto/build_event_stream.proto#L194-L205)
+an [opaque string](https://github.com/bazelbuild/bazel/blob/7.1.0/src/main/java/com/google/devtools/build/lib/buildeventstream/proto/build_event_stream.proto#L131-L140)
+or [structured information](https://github.com/bazelbuild/bazel/blob/7.1.0/src/main/java/com/google/devtools/build/lib/buildeventstream/proto/build_event_stream.proto#L194-L205)
 revealing more about the build event. A build event identifier is unique within
 a build.
 
 *  __Children:__ A build event may announce other build events, by including
-their build event identifiers in its [children
-field](https://github.com/bazelbuild/bazel/blob/7.1.0/src/main/java/com/google/devtools/build/lib/buildeventstream/proto/build_event_stream.proto#L1276).
+their build event identifiers in its [children field](https://github.com/bazelbuild/bazel/blob/7.1.0/src/main/java/com/google/devtools/build/lib/buildeventstream/proto/build_event_stream.proto#L1276).
 For example, the `PatternExpanded` build event announces the targets it expands
 to as children. The protocol guarantees that all events, except for the first
 event, are announced by a previous event.
@@ -91,8 +86,7 @@ human-readable formats, such as text and JSON:
 
 ## Build Event Service {#build-event-service}
 
-The [Build Event
-Service](https://github.com/googleapis/googleapis/blob/master/google/devtools/build/v1/publish_build_event.proto)
+The [Build Event Service](https://github.com/googleapis/googleapis/blob/master/google/devtools/build/v1/publish_build_event.proto)
 Protocol is a generic [gRPC](https://www.grpc.io) service for publishing build events. The Build Event
 Service protocol is independent of the BEP and treats BEP events as opaque bytes.
 Bazel ships with a gRPC client implementation of the Build Event Service protocol that
@@ -136,8 +130,7 @@ For a description of each of these flags, see the
 The BEP typically contains many references to log files (test.log, test.xml,
 etc. ) stored on the machine where Bazel is running. A remote BES server
 typically can't access these files as they are on different machines. A way to
-work around this issue is to use Bazel with [remote
-caching](/versions/8.1.1/remote/caching).
+work around this issue is to use Bazel with [remote caching](/versions/8.1.1/remote/caching).
 Bazel will upload all output files to the remote cache (including files
 referenced in the BEP) and the BES server can then fetch the referenced files
 from the cache.
diff --git a/versions/8.1.1/remote/cache-local.mdx b/versions/8.1.1/remote/cache-local.mdx
index be730ca2..a691a41c 100644
--- a/versions/8.1.1/remote/cache-local.mdx
+++ b/versions/8.1.1/remote/cache-local.mdx
@@ -18,8 +18,7 @@ execution. However, local execution presents some additional challenges.
 ## Checking your cache hit rate {#cache-hits}
 
 Successful remote cache hits will show up in the status line, similar to
-[Cache Hits rate with Remote
-Execution](/versions/8.1.1/remote/cache-remote#check-cache-hits).
+[Cache Hits rate with Remote Execution](/versions/8.1.1/remote/cache-remote#check-cache-hits).
 
 In the standard output of your Bazel run, you will see something like the
 following:
@@ -66,8 +65,7 @@ the steps in this section.
    message you see does not give you enough information, try adding
    `--verbose_failures`.
 
-2. Follow the steps from [Troubleshooting cache hits for remote
-   execution](/versions/8.1.1/remote/cache-remote#troubleshooting_cache_hits) to
+2. Follow the steps from [Troubleshooting cache hits for remote execution](/versions/8.1.1/remote/cache-remote#troubleshooting_cache_hits) to
    ensure that your cache-writing Bazel invocations are able to get cache hits
    on the same machine and across machines.
 
@@ -81,7 +79,6 @@ the steps in this section.
    b. Ensure your cache-reading Bazel invocations build the same targets as the
       cache-writing Bazel invocations.
 
-   c. Follow the same steps as to [ensure caching across
-      machines](/versions/8.1.1/remote/cache-remote#caching-across-machines),
+   c. Follow the same steps as to [ensure caching across machines](/versions/8.1.1/remote/cache-remote#caching-across-machines),
       to ensure caching from your cache-writing Bazel invocation to your
       cache-reading Bazel invocation.
diff --git a/versions/8.1.1/remote/caching.mdx b/versions/8.1.1/remote/caching.mdx
index 7a7b4f2e..fc485f02 100644
--- a/versions/8.1.1/remote/caching.mdx
+++ b/versions/8.1.1/remote/caching.mdx
@@ -126,7 +126,7 @@ not provide technical support for bazel-remote.
 
 This cache stores contents on disk and also provides garbage collection
 to enforce an upper storage limit and clean unused artifacts. The cache is
-available as a [docker image] and its code is available on
+available as a [docker image](https://hub.docker.com/r/buchgr/bazel-remote-cache/) and its code is available on
 [GitHub](https://github.com/buchgr/bazel-remote/).
 Both the REST and gRPC remote cache APIs are supported.
 
@@ -308,8 +308,7 @@ or for the age of individual cache entries. Bazel will automatically garbage
 collect the disk cache while idling between builds; the idle timer can be set
 with `--experimental_disk_cache_gc_idle_delay` (defaulting to 5 minutes).
 
-As an alternative to automatic garbage collection, we also provide a [tool](
-https://github.com/bazelbuild/bazel/tree/master/src/tools/diskcache) to run a
+As an alternative to automatic garbage collection, we also provide a [tool](https://github.com/bazelbuild/bazel/tree/master/src/tools/diskcache) to run a
 garbage collection on demand.
 
 ## Known issues {#known-issues}
diff --git a/versions/8.1.1/remote/dynamic.mdx b/versions/8.1.1/remote/dynamic.mdx
index 379e43c4..eba1342c 100644
--- a/versions/8.1.1/remote/dynamic.mdx
+++ b/versions/8.1.1/remote/dynamic.mdx
@@ -12,8 +12,7 @@ alike.
 This page describes how to enable, tune, and debug dynamic execution. If you
 have both local and remote execution set up and are trying to adjust Bazel
 settings for better performance, this page is for you. If you don't already have
-remote execution set up, go to the Bazel [Remote Execution
-Overview](/versions/8.1.1/remote/rbe) first.
+remote execution set up, go to the Bazel [Remote Execution Overview](/versions/8.1.1/remote/rbe) first.
 
 ## Enabling dynamic execution? {#enabling-dynamic-execution}
 
@@ -44,14 +43,12 @@ are likely. The default value is 1000ms, but should be tuned to being just a bit
 longer than cache hits usually take. The actual time depends both on the remote
 system and on how long a round-trip takes. Usually, the value will be the same
 for all users of a given remote system, unless some of them are far enough away
-to add roundtrip latency. You can use the [Bazel profiling
-features](/versions/8.1.1/rules/performance#performance-profiling) to look at how long typical
+to add roundtrip latency. You can use the [Bazel profiling features](/versions/8.1.1/rules/performance#performance-profiling) to look at how long typical
 cache hits take.
 
 Dynamic execution can be used with local sandboxed strategy as well as with
 [persistent workers](/versions/8.1.1/remote/persistent). Persistent workers will automatically
-run with sandboxing when used with dynamic execution, and cannot use [multiplex
-workers](/versions/8.1.1/remote/multiplex). On Darwin and Windows systems, the sandboxed
+run with sandboxing when used with dynamic execution, and cannot use [multiplex workers](/versions/8.1.1/remote/multiplex). On Darwin and Windows systems, the sandboxed
 strategy can be slow; you can pass `--reuse_sandbox_directories` to reduce
 overhead of creating sandboxes on these systems.
 
@@ -67,8 +64,7 @@ entire action fails. This is an intentional choice to prevent differences
 between local and remote execution from going unnoticed.
 
 For more background on how dynamic execution and its locking works, see Julio
-Merino's excellent [blog
-posts](https://jmmv.dev/series/bazel-dynamic-execution/)
+Merino's excellent [blog posts](https://jmmv.dev/series/bazel-dynamic-execution/)
 
 ## When should I use dynamic execution? {#when-to-use}
 
diff --git a/versions/8.1.1/remote/output-directories.mdx b/versions/8.1.1/remote/output-directories.mdx
index 099d060f..02b9645c 100644
--- a/versions/8.1.1/remote/output-directories.mdx
+++ b/versions/8.1.1/remote/output-directories.mdx
@@ -25,7 +25,7 @@ The solution that's currently implemented:
 
 * Bazel must be invoked from a directory containing a repo boundary file, or a
   subdirectory thereof. In other words, Bazel must be invoked from inside a
-  [repository](../external/overview#repository). Otherwise, an error is
+  [repository](/versions/8.1.1/external/overview#repository). Otherwise, an error is
   reported.
 * The _outputRoot_ directory defaults to `${XDG_CACHE_HOME}/bazel` (or
   `~/.cache/bazel`, if the `XDG_CACHE_HOME` environment variable is not set) on
diff --git a/versions/8.1.1/remote/persistent.mdx b/versions/8.1.1/remote/persistent.mdx
index 9492be55..62c25e08 100644
--- a/versions/8.1.1/remote/persistent.mdx
+++ b/versions/8.1.1/remote/persistent.mdx
@@ -257,7 +257,6 @@ For more information on persistent workers, see:
 *   [Original persistent workers blog post](https://blog.bazel.build/2015/12/10/java-workers.html)
 *   [Haskell implementation description](https://www.tweag.io/blog/2019-09-25-bazel-ghc-persistent-worker-internship/)
 *   [Blog post by Mike Morearty](https://medium.com/@mmorearty/how-to-create-a-persistent-worker-for-bazel-7738bba2cabb)
-*   [Front End Development with Bazel: Angular/TypeScript and Persistent Workers
-    w/ Asana](https://www.youtube.com/watch?v=0pgERydGyqo)
+*   [Front End Development with Bazel: Angular/TypeScript and Persistent Workers w/ Asana](https://www.youtube.com/watch?v=0pgERydGyqo)
 *   [Bazel strategies explained](https://jmmv.dev/2019/12/bazel-strategies.html)
 *   [Informative worker strategy discussion on the bazel-discuss mailing list](https://groups.google.com/forum/#!msg/bazel-discuss/oAEnuhYOPm8/ol7hf4KWJgAJ)
diff --git a/versions/8.1.1/remote/rules.mdx b/versions/8.1.1/remote/rules.mdx
index b1c5ba0e..806800a3 100644
--- a/versions/8.1.1/remote/rules.mdx
+++ b/versions/8.1.1/remote/rules.mdx
@@ -54,8 +54,7 @@ variables that may not be set to equivalent values (or at all) in the remote
 execution environment.
 
 Toolchain rules currently exist for Bazel build and test rules for
-[Scala](https://github.com/bazelbuild/rules_scala/blob/master/scala/scala_toolch
-ain.bzl),
+[Scala](https://github.com/bazelbuild/rules_scala/blob/master/scala/scala_toolch ain.bzl),
 [Rust](https://github.com/bazelbuild/rules_rust/blob/main/rust/toolchain.bzl),
 and [Go](https://github.com/bazelbuild/rules_go/blob/master/go/toolchains.rst),
 and new toolchain rules are under way for other languages and tools such as
diff --git a/versions/8.1.1/remote/workspace.mdx b/versions/8.1.1/remote/workspace.mdx
index 679db269..c7ca3999 100644
--- a/versions/8.1.1/remote/workspace.mdx
+++ b/versions/8.1.1/remote/workspace.mdx
@@ -11,8 +11,7 @@ on the host machine. If your workspace rules access information about the
 host machine for use during execution, your build is likely to break due to
 incompatibilities between the environments.
 
-As part of [adapting Bazel rules for remote
-execution](/versions/8.1.1/remote/rules), you need to find such workspace rules
+As part of [adapting Bazel rules for remote execution](/versions/8.1.1/remote/rules), you need to find such workspace rules
 and fix them. This page describes how to find potentially problematic workspace
 rules using the workspace log.
 
diff --git a/versions/8.1.1/rules/challenges.mdx b/versions/8.1.1/rules/challenges.mdx
index c21841ed..a2e73aef 100644
--- a/versions/8.1.1/rules/challenges.mdx
+++ b/versions/8.1.1/rules/challenges.mdx
@@ -208,7 +208,7 @@ Bazel is heavily affected by both of these scenarios, so we introduced a set of
 custom collection classes that effectively compress the information in memory by
 avoiding the copy at each step. Almost all of these data structures have set
 semantics, so we called it
-[depset](/versions/8.1.1/rules/lib/depset)
+[depset](/versions/8.1.1/rules/lib/builtins/depset)
 (also known as `NestedSet` in the internal implementation). The majority of
 changes to reduce Bazel's memory consumption over the past several years were
 changes to use depsets instead of whatever was previously used.
diff --git a/versions/8.1.1/rules/faq.mdx b/versions/8.1.1/rules/faq.mdx
index d8464ca0..49daed8c 100644
--- a/versions/8.1.1/rules/faq.mdx
+++ b/versions/8.1.1/rules/faq.mdx
@@ -17,7 +17,7 @@ Bazel only executes the actions needed to produce the *requested* output files.
 
 * If you want the file to be built automatically whenever your target is
   mentioned on the command line, add it to your rule's default outputs by
-  returning a [`DefaultInfo`](lib/globals#DefaultInfo) provider.
+  returning a [`DefaultInfo`](/versions/8.1.1/rules/lib/globals#DefaultInfo) provider.
 
 See the [Rules page](/versions/8.1.1/extending/rules#requesting-output-files) for more information.
 
@@ -35,24 +35,24 @@ correct path.
 
 For actions, you declare inputs by passing them to the `ctx.actions.*` function
 that creates the action. The proper path for the file can be obtained using
-[`File.path`](lib/File#path).
+[`File.path`](/versions/8.1.1/rules/lib/builtins/File#path).
 
 For binaries (the executable outputs run by a `bazel run` or `bazel test`
 command), you declare inputs by including them in the
 [runfiles](/versions/8.1.1/extending/rules#runfiles). Instead of using the `path` field, use
-[`File.short_path`](lib/File#short_path), which is file's path relative to
+[`File.short_path`](/versions/8.1.1/rules/lib/builtins/File#short_path), which is file's path relative to
 the runfiles directory in which the binary executes.
 
 ## How can I control which files are built by `bazel build //pkg:mytarget`?
 
-Use the [`DefaultInfo`](lib/globals#DefaultInfo) provider to
+Use the [`DefaultInfo`](/versions/8.1.1/rules/lib/globals#DefaultInfo) provider to
 [set the default outputs](/versions/8.1.1/extending/rules#requesting-output-files).
 
 ## How can I run a program or do file I/O as part of my build?
 
 A tool can be declared as a target, just like any other part of your build, and
 run during the execution phase to help build other targets. To create an action
-that runs a tool, use [`ctx.actions.run`](lib/actions#run) and pass in the
+that runs a tool, use [`ctx.actions.run`](/versions/8.1.1/rules/lib/builtins/actions#run) and pass in the
 tool as the `executable` parameter.
 
 During the loading and analysis phases, a tool *cannot* run, nor can you perform
diff --git a/versions/8.1.1/rules/language.mdx b/versions/8.1.1/rules/language.mdx
index a931b451..5047c413 100644
--- a/versions/8.1.1/rules/language.mdx
+++ b/versions/8.1.1/rules/language.mdx
@@ -34,19 +34,19 @@ Starlark's semantics can differ from Python, but behavioral differences are
 rare, except for cases where Starlark raises an error. The following Python
 types are supported:
 
-* [None](lib/globals#None)
-* [bool](lib/bool)
-* [dict](lib/dict)
-* [tuple](lib/tuple)
-* [function](lib/function)
-* [int](lib/int)
-* [list](lib/list)
-* [string](lib/string)
+* [None](/versions/8.1.1/rules/lib/globals#None)
+* [bool](/versions/8.1.1/rules/lib/core/bool)
+* [dict](/versions/8.1.1/rules/lib/core/dict)
+* [tuple](/versions/8.1.1/rules/lib/core/tuple)
+* [function](/versions/8.1.1/rules/lib/core/function)
+* [int](/versions/8.1.1/rules/lib/core/int)
+* [list](/versions/8.1.1/rules/lib/core/list)
+* [string](/versions/8.1.1/rules/lib/core/string)
 
 ## Mutability
 
 Starlark favors immutability. Two mutable data structures are available:
-[lists](lib/list) and [dicts](lib/dict). Changes to mutable
+[lists](/versions/8.1.1/rules/lib/core/list) and [dicts](/versions/8.1.1/rules/lib/core/dict). Changes to mutable
 data-structures, such as appending a value to a list or deleting an entry in a
 dictionary are valid only for objects created in the current context. After a
 context finishes, its values become immutable.
@@ -93,10 +93,8 @@ values returned by rules are immutable.
 `BUILD` files register targets via making calls to rules. `.bzl` files provide
 definitions for constants, rules, macros, and functions.
 
-[Native functions](/versions/8.1.1/reference/be/functions) and [native rules](
-/reference/be/overview#language-specific-native-rules) are global symbols in
-`BUILD` files. `bzl` files need to load them using the [`native` module](
-/rules/lib/toplevel/native).
+[Native functions](/versions/8.1.1/reference/be/functions) and [native rules](/versions/8.1.1/reference/be/overview#language-specific-native-rules) are global symbols in
+`BUILD` files. `bzl` files need to load them using the [`native` module](/versions/8.1.1/rules/lib/toplevel/native).
 
 There are two syntactic restrictions in `BUILD` files: 1) declaring functions is
 illegal, and 2) `*args` and `**kwargs` arguments are not allowed.
@@ -130,7 +128,7 @@ not defined across value types. In short: `5 < 'foo'` will throw an error and
   error: `{"a": 4, "b": 7, "a": 1}`.
 
 * Strings are represented with double-quotes (such as when you call
-  [repr](lib/globals#repr)).
+  [repr](/versions/8.1.1/rules/lib/globals#repr)).
 
 * Strings aren't iterable.
 
@@ -138,12 +136,12 @@ The following Python features are not supported:
 
 * implicit string concatenation (use explicit `+` operator).
 * Chained comparisons (such as `1 < x < 5`).
-* `class` (see [`struct`](lib/struct#struct) function).
+* `class` (see [`struct`](/versions/8.1.1/rules/lib/builtins/struct#struct) function).
 * `import` (see [`load`](/versions/8.1.1/extending/concepts#loading-an-extension) statement).
 * `while`, `yield`.
 * float and set types.
 * generators and generator expressions.
 * `is` (use `==` instead).
-* `try`, `raise`, `except`, `finally` (see [`fail`](lib/globals#fail) for fatal errors).
+* `try`, `raise`, `except`, `finally` (see [`fail`](/versions/8.1.1/rules/lib/globals#fail) for fatal errors).
 * `global`, `nonlocal`.
 * most builtin functions, most methods.
diff --git a/versions/8.1.1/rules/legacy-macro-tutorial.mdx b/versions/8.1.1/rules/legacy-macro-tutorial.mdx
index 140d3a12..05d8ff36 100644
--- a/versions/8.1.1/rules/legacy-macro-tutorial.mdx
+++ b/versions/8.1.1/rules/legacy-macro-tutorial.mdx
@@ -3,9 +3,7 @@ title: 'Creating a Legacy Macro'
 ---
 
 IMPORTANT: This tutorial is for [*legacy macros*](/versions/8.1.1/extending/legacy-macros). If
-you only need to support Bazel 8 or newer, we recommend using [symbolic
-macros](/versions/8.1.1/extending/macros) instead; take a look at [Creating a Symbolic
-Macro](../macro-tutorial).
+you only need to support Bazel 8 or newer, we recommend using [symbolic macros](/versions/8.1.1/extending/macros) instead; take a look at [Creating a Symbolic Macro](/versions/8.1.1/rules/macro-tutorial).
 
 Imagine that you need to run a tool as part of your build. For example, you
 may want to generate or preprocess a source file, or compress a binary. In this
diff --git a/versions/8.1.1/rules/lib/builtins/Action.mdx b/versions/8.1.1/rules/lib/builtins/Action.mdx
index 95f73a3c..262063c4 100644
--- a/versions/8.1.1/rules/lib/builtins/Action.mdx
+++ b/versions/8.1.1/rules/lib/builtins/Action.mdx
@@ -4,7 +4,7 @@ title: 'Action'
 
 An action created during rule analysis.
 
-This object is visible for the purpose of testing, and may be obtained from an `Actions` provider. It is normally not necessary to access `Action` objects or their fields within a rule's implementation function. You may instead want to see the [Rules page](https://bazel.build/versions/8.1.1/extending/rules#actions) for a general discussion of how to use actions when defining custom rules, or the [API reference](../builtins/actions) for creating actions.
+This object is visible for the purpose of testing, and may be obtained from an `Actions` provider. It is normally not necessary to access `Action` objects or their fields within a rule's implementation function. You may instead want to see the [Rules page](https://bazel.build/versions/8.1.1/extending/rules#actions) for a general discussion of how to use actions when defining custom rules, or the [API reference](/versions/8.1.1/rules/lib/builtins/actions) for creating actions.
 
 Some fields of this object are only applicable for certain kinds of actions. Fields that are inapplicable are set to `None`.
 
@@ -25,7 +25,7 @@ Some fields of this object are only applicable for certain kinds of actions. Fie
 sequence Action.args
 ```
 
-A list of frozen [Args](../builtins/Args) objects containing information about the action arguments. These objects contain accurate argument information, including arguments involving expanded action output directories. However, [Args](../builtins/Args) objects are not readable in the analysis phase. For a less accurate account of arguments which is available in the analysis phase, see [argv](#argv).
+A list of frozen [Args](/versions/8.1.1/rules/lib/builtins/Args) objects containing information about the action arguments. These objects contain accurate argument information, including arguments involving expanded action output directories. However, [Args](/versions/8.1.1/rules/lib/builtins/Args) objects are not readable in the analysis phase. For a less accurate account of arguments which is available in the analysis phase, see [argv](#argv).
 
 Note that some types of actions do not yet support exposure of this field. For such action types, this is `None`.
 May return `None`.
@@ -36,7 +36,7 @@ May return `None`.
 sequence Action.argv
 ```
 
-For actions created by [ctx.actions.run()](../builtins/actions#run) or [ctx.actions.run\_shell()](../builtins/actions#run_shell) an immutable list of the arguments for the command line to be executed. Note that for shell actions the first two arguments will be the shell path and `"-c"`.
+For actions created by [ctx.actions.run()](/versions/8.1.1/rules/lib/builtins/actions#run) or [ctx.actions.run\_shell()](/versions/8.1.1/rules/lib/builtins/actions#run_shell) an immutable list of the arguments for the command line to be executed. Note that for shell actions the first two arguments will be the shell path and `"-c"`.
 May return `None`.
 
 ## content
@@ -45,7 +45,7 @@ May return `None`.
 string Action.content
 ```
 
-For actions created by [ctx.actions.write()](../builtins/actions#write) or [ctx.actions.expand\_template()](../builtins/actions#expand_template), the contents of the file to be written, if those contents can be computed during the analysis phase. The value is `None` if the contents cannot be determined until the execution phase, such as when a directory in an [Args](../builtins/Args) object needs to be expanded.
+For actions created by [ctx.actions.write()](/versions/8.1.1/rules/lib/builtins/actions#write) or [ctx.actions.expand\_template()](/versions/8.1.1/rules/lib/builtins/actions#expand_template), the contents of the file to be written, if those contents can be computed during the analysis phase. The value is `None` if the contents cannot be determined until the execution phase, such as when a directory in an [Args](/versions/8.1.1/rules/lib/builtins/Args) object needs to be expanded.
 May return `None`.
 
 ## env
@@ -86,5 +86,5 @@ A set of the output files of this action.
 dict Action.substitutions
 ```
 
-For actions created by [ctx.actions.expand\_template()](../builtins/actions#expand_template), an immutable dict holding the substitution mapping.
+For actions created by [ctx.actions.expand\_template()](/versions/8.1.1/rules/lib/builtins/actions#expand_template), an immutable dict holding the substitution mapping.
 May return `None`.
\ No newline at end of file
diff --git a/versions/8.1.1/rules/lib/builtins/Args.mdx b/versions/8.1.1/rules/lib/builtins/Args.mdx
index 44c603ef..c3c588e8 100644
--- a/versions/8.1.1/rules/lib/builtins/Args.mdx
+++ b/versions/8.1.1/rules/lib/builtins/Args.mdx
@@ -4,15 +4,15 @@ title: 'Args'
 
 An object that encapsulates, in a memory-efficient way, the data needed to build part or all of a command line.
 
-It often happens that an action requires a large command line containing values accumulated from transitive dependencies. For example, a linker command line might list every object file needed by all of the libraries being linked. It is best practice to store such transitive data in [`depset`](../builtins/depset)s, so that they can be shared by multiple targets. However, if the rule author had to convert these depsets into lists of strings in order to construct an action command line, it would defeat this memory-sharing optimization.
+It often happens that an action requires a large command line containing values accumulated from transitive dependencies. For example, a linker command line might list every object file needed by all of the libraries being linked. It is best practice to store such transitive data in [`depset`](/versions/8.1.1/rules/lib/builtins/depset)s, so that they can be shared by multiple targets. However, if the rule author had to convert these depsets into lists of strings in order to construct an action command line, it would defeat this memory-sharing optimization.
 
 For this reason, the action-constructing functions accept `Args` objects in addition to strings. Each `Args` object represents a concatenation of strings and depsets, with optional transformations for manipulating the data. `Args` objects do not process the depsets they encapsulate until the execution phase, when it comes time to calculate the command line. This helps defer any expensive copying until after the analysis phase is complete. See the [Optimizing Performance](https://bazel.build/versions/8.1.1/rules/performance) page for more information.
 
-`Args` are constructed by calling [`ctx.actions.args()`](../builtins/actions#args). They can be passed as the `arguments` parameter of [`ctx.actions.run()`](../builtins/actions#run) or [`ctx.actions.run_shell()`](../builtins/actions#run_shell). Each mutation of an `Args` object appends values to the eventual command line.
+`Args` are constructed by calling [`ctx.actions.args()`](/versions/8.1.1/rules/lib/builtins/actions#args). They can be passed as the `arguments` parameter of [`ctx.actions.run()`](/versions/8.1.1/rules/lib/builtins/actions#run) or [`ctx.actions.run_shell()`](/versions/8.1.1/rules/lib/builtins/actions#run_shell). Each mutation of an `Args` object appends values to the eventual command line.
 
 The `map_each` feature allows you to customize how items are transformed into strings. If you do not provide a `map_each` function, the standard conversion is as follows:
 
-* Values that are already strings are left as-is.* [`File`](../builtins/File) objects are turned into their `File.path` values.* [`Label`](../builtins/Label) objects are turned into a string representation that resolves back to the same object when resolved in the context of the main repository. If possible, the string representation uses the apparent name of a repository in favor of the repository's canonical name, which makes this representation suited for use in BUILD files. While the exact form of the representation is not guaranteed, typical examples are `//foo:bar`, `@repo//foo:bar` and `@@canonical_name+//foo:bar.bzl`.* All other types are turned into strings in an *unspecified* manner. For this reason, you should avoid passing values that are not of string or `File` type to `add()`, and if you pass them to `add_all()` or `add_joined()` then you should provide a `map_each` function.
+* Values that are already strings are left as-is.* [`File`](/versions/8.1.1/rules/lib/builtins/File) objects are turned into their `File.path` values.* [`Label`](/versions/8.1.1/rules/lib/builtins/Label) objects are turned into a string representation that resolves back to the same object when resolved in the context of the main repository. If possible, the string representation uses the apparent name of a repository in favor of the repository's canonical name, which makes this representation suited for use in BUILD files. While the exact form of the representation is not guaranteed, typical examples are `//foo:bar`, `@repo//foo:bar` and `@@canonical_name+//foo:bar.bzl`.* All other types are turned into strings in an *unspecified* manner. For this reason, you should avoid passing values that are not of string or `File` type to `add()`, and if you pass them to `add_all()` or `add_joined()` then you should provide a `map_each` function.
 
 When using string formatting (`format`, `format_each`, and `format_joined` params of the `add*()` methods), the format template is interpreted in the same way as `%`-substitution on strings, except that the template must have exactly one substitution placeholder and it must be `%s`. Literal percents may be escaped as `%%`. Formatting is applied after the value is converted to a string as per the above.
 
@@ -64,7 +64,7 @@ Appends an argument to this command line.
 | --- | --- |
 | `arg_name_or_value` | required  If two positional parameters are passed this is interpreted as the arg name. The arg name is added before the value without any processing. If only one positional parameter is passed, it is interpreted as `value` (see below). |
 | `value` | default is `unbound`  The object to append. It will be converted to a string using the standard conversion mentioned above. Since there is no `map_each` parameter for this function, `value` should be either a string or a `File`. A list, tuple, depset, or directory `File` must be passed to [`add_all()` or [`add_joined()`](#add_joined) instead of this method.](#add_all) |
-| `format` | [string](../core/string); or `None`; default is `None`  A format string pattern, to be applied to the stringified version of `value`. |
+| `format` | [string](/versions/8.1.1/rules/lib/core/string); or `None`; default is `None`  A format string pattern, to be applied to the stringified version of `value`. |
 
 ## add\_all
 
@@ -86,15 +86,15 @@ Note that empty strings are valid arguments that are subject to all these proces
 | Parameter | Description |
 | --- | --- |
 | `arg_name_or_values` | required  If two positional parameters are passed this is interpreted as the arg name. The arg name is added before the `values` as a separate argument without any processing. This arg name will not be added if `omit_if_empty` is true (the default) and no other items are appended (as happens if `values` is empty or all of its items are filtered). If only one positional parameter is passed, it is interpreted as `values` (see below). |
-| `values` | [sequence](../core/list); or [depset](../builtins/depset); default is `unbound`  The list, tuple, or depset whose items will be appended. |
-| `map_each` | callable; or `None`; default is `None`  A function that converts each item to zero or more strings, which may be further processed before appending. If this param is not provided, the standard conversion is used. The function is passed either one or two positional arguments: the item to convert, followed by an optional [`DirectoryExpander`](../builtins/DirectoryExpander). The second argument will be passed only if the supplied function is user-defined (not built-in) and declares more than one parameter. The return value's type depends on how many arguments are to be produced for the item:  * In the common case when each item turns into one string, the function should return that string.* If the item is to be filtered out entirely, the function should return `None`.* If the item turns into multiple strings, the function returns a list of those strings.  Returning a single string or `None` has the same effect as returning a list of length 1 or length 0 respectively. However, it is more efficient and readable to avoid creating a list where it is not needed. Ordinarily, items that are directories are automatically expanded to their contents when `expand_directories=True` is set. However, this will not expand directories contained inside other values -- for instance, when the items are structs that have directories as fields. In this situation, the `DirectoryExpander` argument can be applied to manually obtain the files of a given directory. To avoid unintended retention of large analysis-phase data structures into the execution phase, the `map_each` function must be declared by a top-level `def` statement; it may not be a nested function closure by default. *Warning:* [`print()`](../globals/all#print) statements that are executed during the call to `map_each` will not produce any visible output. |
-| `format_each` | [string](../core/string); or `None`; default is `None`  An optional format string pattern, applied to each string returned by the `map_each` function. The format string must have exactly one '%s' placeholder. |
-| `before_each` | [string](../core/string); or `None`; default is `None`  An optional argument to append before each argument derived from `values` is appended. |
-| `omit_if_empty` | [bool](../core/bool); default is `True`  If true, if there are no arguments derived from `values` to be appended, then all further processing is suppressed and the command line will be unchanged. If false, the arg name and `terminate_with`, if provided, will still be appended regardless of whether or not there are other arguments. |
-| `uniquify` | [bool](../core/bool); default is `False`  If true, duplicate arguments that are derived from `values` will be omitted. Only the first occurrence of each argument will remain. Usually this feature is not needed because depsets already omit duplicates, but it can be useful if `map_each` emits the same string for multiple items. |
-| `expand_directories` | [bool](../core/bool); default is `True`  If true, any directories in `values` will be expanded to a flat list of files. This happens before `map_each` is applied. |
-| `terminate_with` | [string](../core/string); or `None`; default is `None`  An optional argument to append after all other arguments. This argument will not be added if `omit_if_empty` is true (the default) and no other items are appended (as happens if `values` is empty or all of its items are filtered). |
-| `allow_closure` | [bool](../core/bool); default is `False`  If true, allows the use of closures in function parameters like `map_each`. Usually this isn't necessary and it risks retaining large analysis-phase data structures into the execution phase. |
+| `values` | [sequence](/versions/8.1.1/rules/lib/core/list); or [depset](/versions/8.1.1/rules/lib/builtins/depset); default is `unbound`  The list, tuple, or depset whose items will be appended. |
+| `map_each` | callable; or `None`; default is `None`  A function that converts each item to zero or more strings, which may be further processed before appending. If this param is not provided, the standard conversion is used. The function is passed either one or two positional arguments: the item to convert, followed by an optional [`DirectoryExpander`](/versions/8.1.1/rules/lib/builtins/DirectoryExpander). The second argument will be passed only if the supplied function is user-defined (not built-in) and declares more than one parameter. The return value's type depends on how many arguments are to be produced for the item:  * In the common case when each item turns into one string, the function should return that string.* If the item is to be filtered out entirely, the function should return `None`.* If the item turns into multiple strings, the function returns a list of those strings.  Returning a single string or `None` has the same effect as returning a list of length 1 or length 0 respectively. However, it is more efficient and readable to avoid creating a list where it is not needed. Ordinarily, items that are directories are automatically expanded to their contents when `expand_directories=True` is set. However, this will not expand directories contained inside other values -- for instance, when the items are structs that have directories as fields. In this situation, the `DirectoryExpander` argument can be applied to manually obtain the files of a given directory. To avoid unintended retention of large analysis-phase data structures into the execution phase, the `map_each` function must be declared by a top-level `def` statement; it may not be a nested function closure by default. *Warning:* [`print()`](/versions/8.1.1/rules/lib/globals/all#print) statements that are executed during the call to `map_each` will not produce any visible output. |
+| `format_each` | [string](/versions/8.1.1/rules/lib/core/string); or `None`; default is `None`  An optional format string pattern, applied to each string returned by the `map_each` function. The format string must have exactly one '%s' placeholder. |
+| `before_each` | [string](/versions/8.1.1/rules/lib/core/string); or `None`; default is `None`  An optional argument to append before each argument derived from `values` is appended. |
+| `omit_if_empty` | [bool](/versions/8.1.1/rules/lib/core/bool); default is `True`  If true, if there are no arguments derived from `values` to be appended, then all further processing is suppressed and the command line will be unchanged. If false, the arg name and `terminate_with`, if provided, will still be appended regardless of whether or not there are other arguments. |
+| `uniquify` | [bool](/versions/8.1.1/rules/lib/core/bool); default is `False`  If true, duplicate arguments that are derived from `values` will be omitted. Only the first occurrence of each argument will remain. Usually this feature is not needed because depsets already omit duplicates, but it can be useful if `map_each` emits the same string for multiple items. |
+| `expand_directories` | [bool](/versions/8.1.1/rules/lib/core/bool); default is `True`  If true, any directories in `values` will be expanded to a flat list of files. This happens before `map_each` is applied. |
+| `terminate_with` | [string](/versions/8.1.1/rules/lib/core/string); or `None`; default is `None`  An optional argument to append after all other arguments. This argument will not be added if `omit_if_empty` is true (the default) and no other items are appended (as happens if `values` is empty or all of its items are filtered). |
+| `allow_closure` | [bool](/versions/8.1.1/rules/lib/core/bool); default is `False`  If true, allows the use of closures in function parameters like `map_each`. Usually this isn't necessary and it risks retaining large analysis-phase data structures into the execution phase. |
 
 ## add\_joined
 
@@ -113,15 +113,15 @@ If after filtering there are no strings to join into an argument, and if `omit_i
 | Parameter | Description |
 | --- | --- |
 | `arg_name_or_values` | required  If two positional parameters are passed this is interpreted as the arg name. The arg name is added before `values` without any processing. This arg will not be added if `omit_if_empty` is true (the default) and there are no strings derived from `values` to join together (which can happen if `values` is empty or all of its items are filtered). If only one positional parameter is passed, it is interpreted as `values` (see below). |
-| `values` | [sequence](../core/list); or [depset](../builtins/depset); default is `unbound`  The list, tuple, or depset whose items will be joined. |
-| `join_with` | [string](../core/string); required  A delimiter string used to join together the strings obtained from applying `map_each` and `format_each`, in the same manner as [`string.join()`](../core/string#join). |
+| `values` | [sequence](/versions/8.1.1/rules/lib/core/list); or [depset](/versions/8.1.1/rules/lib/builtins/depset); default is `unbound`  The list, tuple, or depset whose items will be joined. |
+| `join_with` | [string](/versions/8.1.1/rules/lib/core/string); required  A delimiter string used to join together the strings obtained from applying `map_each` and `format_each`, in the same manner as [`string.join()`](/versions/8.1.1/rules/lib/core/string#join). |
 | `map_each` | callable; or `None`; default is `None`  Same as for [`add_all`](#add_all.map_each). |
-| `format_each` | [string](../core/string); or `None`; default is `None`  Same as for [`add_all`](#add_all.format_each). |
-| `format_joined` | [string](../core/string); or `None`; default is `None`  An optional format string pattern applied to the joined string. The format string must have exactly one '%s' placeholder. |
-| `omit_if_empty` | [bool](../core/bool); default is `True`  If true, if there are no strings to join together (either because `values` is empty or all its items are filtered), then all further processing is suppressed and the command line will be unchanged. If false, then even if there are no strings to join together, two arguments will be appended: the arg name followed by an empty string (which is the logical join of zero strings). |
-| `uniquify` | [bool](../core/bool); default is `False`  Same as for [`add_all`](#add_all.uniquify). |
-| `expand_directories` | [bool](../core/bool); default is `True`  Same as for [`add_all`](#add_all.expand_directories). |
-| `allow_closure` | [bool](../core/bool); default is `False`  Same as for [`add_all`](#add_all.allow_closure). |
+| `format_each` | [string](/versions/8.1.1/rules/lib/core/string); or `None`; default is `None`  Same as for [`add_all`](#add_all.format_each). |
+| `format_joined` | [string](/versions/8.1.1/rules/lib/core/string); or `None`; default is `None`  An optional format string pattern applied to the joined string. The format string must have exactly one '%s' placeholder. |
+| `omit_if_empty` | [bool](/versions/8.1.1/rules/lib/core/bool); default is `True`  If true, if there are no strings to join together (either because `values` is empty or all its items are filtered), then all further processing is suppressed and the command line will be unchanged. If false, then even if there are no strings to join together, two arguments will be appended: the arg name followed by an empty string (which is the logical join of zero strings). |
+| `uniquify` | [bool](/versions/8.1.1/rules/lib/core/bool); default is `False`  Same as for [`add_all`](#add_all.uniquify). |
+| `expand_directories` | [bool](/versions/8.1.1/rules/lib/core/bool); default is `True`  Same as for [`add_all`](#add_all.expand_directories). |
+| `allow_closure` | [bool](/versions/8.1.1/rules/lib/core/bool); default is `False`  Same as for [`add_all`](#add_all.allow_closure). |
 
 ## set\_param\_file\_format
 
@@ -135,7 +135,7 @@ Sets the format of the param file, if one is used
 
 | Parameter | Description |
 | --- | --- |
-| `format` | [string](../core/string); required  Must be one of:  * "multiline": Each item (argument name or value) is written verbatim to the param file with a newline character following it. * "shell": Same as "multiline", but the items are shell-quoted * "flag\_per\_line": Same as "multiline", but (1) only flags (beginning with '--') are written to the param file, and (2) the values of the flags, if any, are written on the same line with a '=' separator. This is the format expected by the Abseil flags library.   The format defaults to "shell" if not called. |
+| `format` | [string](/versions/8.1.1/rules/lib/core/string); required  Must be one of:  * "multiline": Each item (argument name or value) is written verbatim to the param file with a newline character following it. * "shell": Same as "multiline", but the items are shell-quoted * "flag\_per\_line": Same as "multiline", but (1) only flags (beginning with '--') are written to the param file, and (2) the values of the flags, if any, are written on the same line with a '=' separator. This is the format expected by the Abseil flags library.   The format defaults to "shell" if not called. |
 
 ## use\_param\_file
 
@@ -151,5 +151,5 @@ Bazel may choose to elide writing the params file to the output tree during exec
 
 | Parameter | Description |
 | --- | --- |
-| `param_file_arg` | [string](../core/string); required  A format string with a single "%s". If the args are spilled to a params file then they are replaced with an argument consisting of this string formatted with the path of the params file. For example, if the args are spilled to a params file "params.txt", then specifying "--file=%s" would cause the action command line to contain "--file=params.txt". |
-| `use_always` | [bool](../core/bool); default is `False`  Whether to always spill the args to a params file. If false, bazel will decide whether the arguments need to be spilled based on your system and arg length. |
\ No newline at end of file
+| `param_file_arg` | [string](/versions/8.1.1/rules/lib/core/string); required  A format string with a single "%s". If the args are spilled to a params file then they are replaced with an argument consisting of this string formatted with the path of the params file. For example, if the args are spilled to a params file "params.txt", then specifying "--file=%s" would cause the action command line to contain "--file=params.txt". |
+| `use_always` | [bool](/versions/8.1.1/rules/lib/core/bool); default is `False`  Whether to always spill the args to a params file. If false, bazel will decide whether the arguments need to be spilled based on your system and arg length. |
\ No newline at end of file
diff --git a/versions/8.1.1/rules/lib/builtins/Aspect.mdx b/versions/8.1.1/rules/lib/builtins/Aspect.mdx
index 30306f51..950b9ba1 100644
--- a/versions/8.1.1/rules/lib/builtins/Aspect.mdx
+++ b/versions/8.1.1/rules/lib/builtins/Aspect.mdx
@@ -3,4 +3,4 @@ title: 'Aspect'
 ---
 
 For more information about Aspects, please consult the
-[documentation of the aspect function](../globals/bzl#aspect) or the [introduction to Aspects](https://bazel.build/versions/8.1.1/rules/aspects).
\ No newline at end of file
+[documentation of the aspect function](/versions/8.1.1/rules/lib/globals/bzl#aspect) or the [introduction to Aspects](https://bazel.build/versions/8.1.1/rules/aspects).
\ No newline at end of file
diff --git a/versions/8.1.1/rules/lib/builtins/Attribute.mdx b/versions/8.1.1/rules/lib/builtins/Attribute.mdx
index 18486c41..72463a7c 100644
--- a/versions/8.1.1/rules/lib/builtins/Attribute.mdx
+++ b/versions/8.1.1/rules/lib/builtins/Attribute.mdx
@@ -2,4 +2,4 @@
 title: 'Attribute'
 ---
 
-Representation of a definition of an attribute. Use the [attr](../toplevel/attr) module to create an Attribute. They are only for use with a [rule](../globals/bzl#rule) or an [aspect](../globals/bzl#aspect).
\ No newline at end of file
+Representation of a definition of an attribute. Use the [attr](/versions/8.1.1/rules/lib/toplevel/attr) module to create an Attribute. They are only for use with a [rule](/versions/8.1.1/rules/lib/globals/bzl#rule) or an [aspect](/versions/8.1.1/rules/lib/globals/bzl#aspect).
\ No newline at end of file
diff --git a/versions/8.1.1/rules/lib/builtins/DirectoryExpander.mdx b/versions/8.1.1/rules/lib/builtins/DirectoryExpander.mdx
index 8bf9ae69..07292c94 100644
--- a/versions/8.1.1/rules/lib/builtins/DirectoryExpander.mdx
+++ b/versions/8.1.1/rules/lib/builtins/DirectoryExpander.mdx
@@ -2,7 +2,7 @@
 title: 'DirectoryExpander'
 ---
 
-Expands directories created by [`ctx.actions.declare_directory`](../builtins/actions#declare_directory) during the execution phase. This is useful to expand directories in [`map_each`](../builtins/Args#add_all.map_each).
+Expands directories created by [`ctx.actions.declare_directory`](/versions/8.1.1/rules/lib/builtins/actions#declare_directory) during the execution phase. This is useful to expand directories in [`map_each`](/versions/8.1.1/rules/lib/builtins/Args#add_all.map_each).
 
 ## Members
 
@@ -20,4 +20,4 @@ If the given `File` is a directory, this returns a list of `File`s recursively u
 
 | Parameter | Description |
 | --- | --- |
-| `file` | [File](../builtins/File); required  The directory or file to expand. |
\ No newline at end of file
+| `file` | [File](/versions/8.1.1/rules/lib/builtins/File); required  The directory or file to expand. |
\ No newline at end of file
diff --git a/versions/8.1.1/rules/lib/builtins/DottedVersion.mdx b/versions/8.1.1/rules/lib/builtins/DottedVersion.mdx
index f17cea85..9cead366 100644
--- a/versions/8.1.1/rules/lib/builtins/DottedVersion.mdx
+++ b/versions/8.1.1/rules/lib/builtins/DottedVersion.mdx
@@ -20,4 +20,4 @@ Compares based on most significant (first) not-matching version component. So, f
 
 | Parameter | Description |
 | --- | --- |
-| `other` | [DottedVersion](../builtins/DottedVersion); required  The other dotted version. |
\ No newline at end of file
+| `other` | [DottedVersion](/versions/8.1.1/rules/lib/builtins/DottedVersion); required  The other dotted version. |
\ No newline at end of file
diff --git a/versions/8.1.1/rules/lib/builtins/File.mdx b/versions/8.1.1/rules/lib/builtins/File.mdx
index 1c86beda..b0ea4ebd 100644
--- a/versions/8.1.1/rules/lib/builtins/File.mdx
+++ b/versions/8.1.1/rules/lib/builtins/File.mdx
@@ -4,7 +4,7 @@ title: 'File'
 
 This object is created during the analysis phase to represent a file or directory that will be read or written during the execution phase. It is not an open file handle, and cannot be used to directly read or write file contents. Rather, you use it to construct the action graph in a rule implementation function by passing it to action-creating functions. See the [Rules page](https://bazel.build/versions/8.1.1/extending/rules#files) for more information.
 
-When a `File` is passed to an [`Args`](../builtins/Args) object without using a `map_each` function, it is converted to a string by taking the value of its `path` field.
+When a `File` is passed to an [`Args`](/versions/8.1.1/rules/lib/builtins/Args) object without using a `map_each` function, it is converted to a string by taking the value of its `path` field.
 
 ## Members
 
@@ -83,7 +83,7 @@ May return `None`.
 string File.path
 ```
 
-The execution path of this file, relative to the workspace's execution directory. It consists of two parts, an optional first part called the *root* (see also the [root](../builtins/root) module), and the second part which is the `short_path`. The root may be empty, which it usually is for non-generated files. For generated files it usually contains a configuration-specific path fragment that encodes things like the target CPU architecture that was used while building said file. Use the `short_path` for the path under which the file is mapped if it's in the runfiles of a binary.
+The execution path of this file, relative to the workspace's execution directory. It consists of two parts, an optional first part called the *root* (see also the [root](/versions/8.1.1/rules/lib/builtins/root) module), and the second part which is the `short_path`. The root may be empty, which it usually is for non-generated files. For generated files it usually contains a configuration-specific path fragment that encodes things like the target CPU architecture that was used while building said file. Use the `short_path` for the path under which the file is mapped if it's in the runfiles of a binary.
 
 ## root
 
@@ -107,4 +107,4 @@ The path of this file relative to its root. This excludes the aforementioned *ro
 string File.tree_relative_path
 ```
 
-The path of this file relative to the root of the ancestor's tree, if the ancestor's [is\_directory](#is_directory) field is true. `tree_relative_path` is only available for expanded files of a directory in an action command, i.e. [Args.add\_all()](../builtins/Args#add_all). For other types of files, it is an error to access this field.
\ No newline at end of file
+The path of this file relative to the root of the ancestor's tree, if the ancestor's [is\_directory](#is_directory) field is true. `tree_relative_path` is only available for expanded files of a directory in an action command, i.e. [Args.add\_all()](/versions/8.1.1/rules/lib/builtins/Args#add_all). For other types of files, it is an error to access this field.
\ No newline at end of file
diff --git a/versions/8.1.1/rules/lib/builtins/Label.mdx b/versions/8.1.1/rules/lib/builtins/Label.mdx
index 75fe1c6c..3ed99d28 100644
--- a/versions/8.1.1/rules/lib/builtins/Label.mdx
+++ b/versions/8.1.1/rules/lib/builtins/Label.mdx
@@ -33,7 +33,7 @@ For macros, a related function, `native.package_relative_label()`, converts the
 
 | Parameter | Description |
 | --- | --- |
-| `input` | [string](../core/string); or [Label](../builtins/Label); required  The input label string or Label object. If a Label object is passed, it's returned as is. |
+| `input` | [string](/versions/8.1.1/rules/lib/core/string); or [Label](/versions/8.1.1/rules/lib/builtins/Label); required  The input label string or Label object. If a Label object is passed, it's returned as is. |
 
 ## name
 
@@ -66,7 +66,7 @@ Label Label.relative(relName)
 ```
 
 **Experimental**. This API is experimental and may change at any time. Please do not depend on it. It may be enabled on an experimental basis by setting `--+incompatible_enable_deprecated_label_apis`
-**Deprecated.** This method behaves surprisingly when used with an argument containing an apparent repo name. Prefer [`Label.same_package_label()`](#same_package_label), [`native.package_relative_label()`](../toplevel/native#package_relative_label), or [`Label()`](#Label) instead.
+**Deprecated.** This method behaves surprisingly when used with an argument containing an apparent repo name. Prefer [`Label.same_package_label()`](#same_package_label), [`native.package_relative_label()`](/versions/8.1.1/rules/lib/toplevel/native#package_relative_label), or [`Label()`](#Label) instead.
 
 Resolves a label that is either absolute (starts with `//`) or relative to the current package. If this label is in a remote repository, the argument will be resolved relative to that repository. If the argument contains a repository name, the current label is ignored and the argument is returned as-is, except that the repository name is rewritten if it is in the current repository mapping. Reserved labels will also be returned as-is.
 For example:
@@ -89,7 +89,7 @@ Label("@repo//foo/bar:baz").relative("@other//wiz:quux") == Label("@remapped//wi
 
 | Parameter | Description |
 | --- | --- |
-| `relName` | [string](../core/string); required |
+| `relName` | [string](/versions/8.1.1/rules/lib/core/string); required |
 
 ## repo\_name
 
@@ -115,7 +115,7 @@ Creates a label in the same package as this label with the given target name.
 
 | Parameter | Description |
 | --- | --- |
-| `target_name` | [string](../core/string); required |
+| `target_name` | [string](/versions/8.1.1/rules/lib/core/string); required |
 
 ## workspace\_name
 
diff --git a/versions/8.1.1/rules/lib/builtins/LateBoundDefault.mdx b/versions/8.1.1/rules/lib/builtins/LateBoundDefault.mdx
index edd0010c..dfbbee57 100644
--- a/versions/8.1.1/rules/lib/builtins/LateBoundDefault.mdx
+++ b/versions/8.1.1/rules/lib/builtins/LateBoundDefault.mdx
@@ -4,4 +4,4 @@ title: 'LateBoundDefault'
 
 Represents a late-bound default attribute value of type 'Label'. The value of a LateBoundDefault is only resolvable in the context of a rule implementation function, and depends on the current build configuration. For example, a LateBoundDefault might represent the Label of the java toolchain in the current build configuration.
 
-See [configuration\_field](../globals/bzl#configuration_field) for example usage.
\ No newline at end of file
+See [configuration\_field](/versions/8.1.1/rules/lib/globals/bzl#configuration_field) for example usage.
\ No newline at end of file
diff --git a/versions/8.1.1/rules/lib/builtins/Provider.mdx b/versions/8.1.1/rules/lib/builtins/Provider.mdx
index 54b9cf36..db4de1dd 100644
--- a/versions/8.1.1/rules/lib/builtins/Provider.mdx
+++ b/versions/8.1.1/rules/lib/builtins/Provider.mdx
@@ -14,7 +14,7 @@ This value has a dual purpose:
   ```
 
   Note: Some providers, defined internally, do not allow instance creation
-* It is a *key* to access a provider instance on a [Target](../builtins/Target)
+* It is a *key* to access a provider instance on a [Target](/versions/8.1.1/rules/lib/builtins/Target)
 
   ```
   DataInfo = provider()
@@ -22,4 +22,4 @@ This value has a dual purpose:
     ... ctx.attr.dep[DataInfo]
   ```
 
-Create a new `Provider` using the [provider](../globals/bzl#provider) function.
\ No newline at end of file
+Create a new `Provider` using the [provider](/versions/8.1.1/rules/lib/globals/bzl#provider) function.
\ No newline at end of file
diff --git a/versions/8.1.1/rules/lib/builtins/TemplateDict.mdx b/versions/8.1.1/rules/lib/builtins/TemplateDict.mdx
index 5f18fd44..1e67358e 100644
--- a/versions/8.1.1/rules/lib/builtins/TemplateDict.mdx
+++ b/versions/8.1.1/rules/lib/builtins/TemplateDict.mdx
@@ -21,8 +21,8 @@ Add a String value
 
 | Parameter | Description |
 | --- | --- |
-| `key` | [string](../core/string); required  A String key |
-| `value` | [string](../core/string); required  A String value |
+| `key` | [string](/versions/8.1.1/rules/lib/core/string); required  A String key |
+| `value` | [string](/versions/8.1.1/rules/lib/core/string); required  A String value |
 
 ## add\_joined
 
@@ -36,10 +36,10 @@ Add depset of values
 
 | Parameter | Description |
 | --- | --- |
-| `key` | [string](../core/string); required  A String key |
-| `values` | [depset](../builtins/depset); required  The depset whose items will be joined. |
-| `join_with` | [string](../core/string); required  A delimiter string used to join together the strings obtained from applying `map_each`, in the same manner as [`string.join()`](../core/string#join). |
+| `key` | [string](/versions/8.1.1/rules/lib/core/string); required  A String key |
+| `values` | [depset](/versions/8.1.1/rules/lib/builtins/depset); required  The depset whose items will be joined. |
+| `join_with` | [string](/versions/8.1.1/rules/lib/core/string); required  A delimiter string used to join together the strings obtained from applying `map_each`, in the same manner as [`string.join()`](/versions/8.1.1/rules/lib/core/string#join). |
 | `map_each` | callable; required  A Starlark function accepting a single argument and returning either a string, `None`, or a list of strings. This function is applied to each item of the depset specified in the `values` parameter |
-| `uniquify` | [bool](../core/bool); default is `False`  If true, duplicate strings derived from `values` will be omitted. Only the first occurrence of each string will remain. Usually this feature is not needed because depsets already omit duplicates, but it can be useful if `map_each` emits the same string for multiple items. |
-| `format_joined` | [string](../core/string); or `None`; default is `None`  An optional format string pattern applied to the joined string. The format string must have exactly one '%s' placeholder. |
-| `allow_closure` | [bool](../core/bool); default is `False`  If true, allows the use of closures in function parameters like `map_each`. Usually this isn't necessary and it risks retaining large analysis-phase data structures into the execution phase. |
\ No newline at end of file
+| `uniquify` | [bool](/versions/8.1.1/rules/lib/core/bool); default is `False`  If true, duplicate strings derived from `values` will be omitted. Only the first occurrence of each string will remain. Usually this feature is not needed because depsets already omit duplicates, but it can be useful if `map_each` emits the same string for multiple items. |
+| `format_joined` | [string](/versions/8.1.1/rules/lib/core/string); or `None`; default is `None`  An optional format string pattern applied to the joined string. The format string must have exactly one '%s' placeholder. |
+| `allow_closure` | [bool](/versions/8.1.1/rules/lib/core/bool); default is `False`  If true, allows the use of closures in function parameters like `map_each`. Usually this isn't necessary and it risks retaining large analysis-phase data structures into the execution phase. |
\ No newline at end of file
diff --git a/versions/8.1.1/rules/lib/builtins/actions.mdx b/versions/8.1.1/rules/lib/builtins/actions.mdx
index 4aa07945..5722947c 100644
--- a/versions/8.1.1/rules/lib/builtins/actions.mdx
+++ b/versions/8.1.1/rules/lib/builtins/actions.mdx
@@ -2,7 +2,7 @@
 title: 'actions'
 ---
 
-Module providing functions to create actions. Access this module using [`ctx.actions`](../builtins/ctx#actions).
+Module providing functions to create actions. Access this module using [`ctx.actions`](/versions/8.1.1/rules/lib/builtins/ctx#actions).
 
 ## Members
 
@@ -32,14 +32,14 @@ Returns an Args object that can be used to build memory-efficient command lines.
 File actions.declare_directory(filename, *, sibling=None)
 ```
 
-Declares that the rule or aspect creates a directory with the given name, in the current package. You must create an action that generates the directory. The contents of the directory are not directly accessible from Starlark, but can be expanded in an action command with [`Args.add_all()`](../builtins/Args#add_all). Only regular files and directories can be in the expanded contents of a declare\_directory.
+Declares that the rule or aspect creates a directory with the given name, in the current package. You must create an action that generates the directory. The contents of the directory are not directly accessible from Starlark, but can be expanded in an action command with [`Args.add_all()`](/versions/8.1.1/rules/lib/builtins/Args#add_all). Only regular files and directories can be in the expanded contents of a declare\_directory.
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `filename` | [string](../core/string); required  If no 'sibling' provided, path of the new directory, relative to the current package. Otherwise a base name for a file ('sibling' defines a directory). |
-| `sibling` | [File](../builtins/File); or `None`; default is `None`  A file that lives in the same directory as the newly declared directory. The file must be in the current package. |
+| `filename` | [string](/versions/8.1.1/rules/lib/core/string); required  If no 'sibling' provided, path of the new directory, relative to the current package. Otherwise a base name for a file ('sibling' defines a directory). |
+| `sibling` | [File](/versions/8.1.1/rules/lib/builtins/File); or `None`; default is `None`  A file that lives in the same directory as the newly declared directory. The file must be in the current package. |
 
 ## declare\_file
 
@@ -51,14 +51,14 @@ Declares that the rule or aspect creates a file with the given filename. If `sib
 
 Remember that in addition to declaring a file, you must separately create an action that emits the file. Creating that action will require passing the returned `File` object to the action's construction function.
 
-Note that [predeclared output files](https://bazel.build/versions/8.1.1/extending/rules#files) do not need to be (and cannot be) declared using this function. You can obtain their `File` objects from [`ctx.outputs`](../builtins/ctx#outputs) instead. [See example of use](https://github.com/bazelbuild/examples/tree/main/rules/computed_dependencies/hash.bzl).
+Note that [predeclared output files](https://bazel.build/versions/8.1.1/extending/rules#files) do not need to be (and cannot be) declared using this function. You can obtain their `File` objects from [`ctx.outputs`](/versions/8.1.1/rules/lib/builtins/ctx#outputs) instead. [See example of use](https://github.com/bazelbuild/examples/tree/main/rules/computed_dependencies/hash.bzl).
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `filename` | [string](../core/string); required  If no 'sibling' provided, path of the new file, relative to the current package. Otherwise a base name for a file ('sibling' determines a directory). |
-| `sibling` | [File](../builtins/File); or `None`; default is `None`  A file that lives in the same directory as the newly created file. The file must be in the current package. |
+| `filename` | [string](/versions/8.1.1/rules/lib/core/string); required  If no 'sibling' provided, path of the new file, relative to the current package. Otherwise a base name for a file ('sibling' determines a directory). |
+| `sibling` | [File](/versions/8.1.1/rules/lib/builtins/File); or `None`; default is `None`  A file that lives in the same directory as the newly created file. The file must be in the current package. |
 
 ## declare\_symlink
 
@@ -72,8 +72,8 @@ Declares that the rule or aspect creates a symlink with the given name in the cu
 
 | Parameter | Description |
 | --- | --- |
-| `filename` | [string](../core/string); required  If no 'sibling' provided, path of the new symlink, relative to the current package. Otherwise a base name for a file ('sibling' defines a directory). |
-| `sibling` | [File](../builtins/File); or `None`; default is `None`  A file that lives in the same directory as the newly declared symlink. |
+| `filename` | [string](/versions/8.1.1/rules/lib/core/string); required  If no 'sibling' provided, path of the new symlink, relative to the current package. Otherwise a base name for a file ('sibling' defines a directory). |
+| `sibling` | [File](/versions/8.1.1/rules/lib/builtins/File); or `None`; default is `None`  A file that lives in the same directory as the newly declared symlink. |
 
 ## do\_nothing
 
@@ -87,8 +87,8 @@ Creates an empty action that neither executes a command nor produces any output,
 
 | Parameter | Description |
 | --- | --- |
-| `mnemonic` | [string](../core/string); required  A one-word description of the action, for example, CppCompile or GoLink. |
-| `inputs` | [sequence](../core/list) of [File](../builtins/File)s; or [depset](../builtins/depset); default is `[]`  List of the input files of the action. |
+| `mnemonic` | [string](/versions/8.1.1/rules/lib/core/string); required  A one-word description of the action, for example, CppCompile or GoLink. |
+| `inputs` | [sequence](/versions/8.1.1/rules/lib/core/list) of [File](/versions/8.1.1/rules/lib/builtins/File)s; or [depset](/versions/8.1.1/rules/lib/builtins/depset); default is `[]`  List of the input files of the action. |
 
 ## expand\_template
 
@@ -102,11 +102,11 @@ Creates a template expansion action. When the action is executed, it will genera
 
 | Parameter | Description |
 | --- | --- |
-| `template` | [File](../builtins/File); required  The template file, which is a UTF-8 encoded text file. |
-| `output` | [File](../builtins/File); required  The output file, which is a UTF-8 encoded text file. |
-| `substitutions` | [dict](../core/dict); default is `{}`  Substitutions to make when expanding the template. |
-| `is_executable` | [bool](../core/bool); default is `False`  Whether the output file should be executable. |
-| `computed_substitutions` | [TemplateDict](../builtins/TemplateDict); default is `unbound`  Substitutions to make when expanding the template. |
+| `template` | [File](/versions/8.1.1/rules/lib/builtins/File); required  The template file, which is a UTF-8 encoded text file. |
+| `output` | [File](/versions/8.1.1/rules/lib/builtins/File); required  The output file, which is a UTF-8 encoded text file. |
+| `substitutions` | [dict](/versions/8.1.1/rules/lib/core/dict); default is `{}`  Substitutions to make when expanding the template. |
+| `is_executable` | [bool](/versions/8.1.1/rules/lib/core/bool); default is `False`  Whether the output file should be executable. |
+| `computed_substitutions` | [TemplateDict](/versions/8.1.1/rules/lib/builtins/TemplateDict); default is `unbound`  Substitutions to make when expanding the template. |
 
 ## run
 
@@ -120,22 +120,22 @@ Creates an action that runs an executable. [See example of use](https://github.c
 
 | Parameter | Description |
 | --- | --- |
-| `outputs` | [sequence](../core/list) of [File](../builtins/File)s; required  List of the output files of the action. |
-| `inputs` | [sequence](../core/list) of [File](../builtins/File)s; or [depset](../builtins/depset); default is `[]`  List or depset of the input files of the action. |
-| `unused_inputs_list` | [File](../builtins/File); or `None`; default is `None`  File containing list of inputs unused by the action. The content of this file (generally one of the outputs of the action) corresponds to the list of input files that were not used during the whole action execution. Any change in those files must not affect in any way the outputs of the action. |
-| `executable` | [File](../builtins/File); or [string](../core/string); or [FilesToRunProvider](../providers/FilesToRunProvider); required  The executable file to be called by the action. |
-| `tools` | [sequence](../core/list); or [depset](../builtins/depset); default is `unbound`  List or depset of any tools needed by the action. Tools are inputs with additional runfiles that are automatically made available to the action. When a list is provided, it can be a heterogenous collection of Files, FilesToRunProvider instances, or depsets of Files. Files which are directly in the list and come from ctx.executable will have their runfiles automatically added. When a depset is provided, it must contain only Files. In both cases, files within depsets are not cross-referenced with ctx.executable for runfiles. |
-| `arguments` | [sequence](../core/list); default is `[]`  Command line arguments of the action. Must be a list of strings or [`actions.args()`](#args) objects. |
-| `mnemonic` | [string](../core/string); or `None`; default is `None`  A one-word description of the action, for example, CppCompile or GoLink. |
-| `progress_message` | [string](../core/string); or `None`; default is `None`  Progress message to show to the user during the build, for example, "Compiling foo.cc to create foo.o". The message may contain `%{label}`, `%{input}`, or `%{output}` patterns, which are substituted with label string, first input, or output's path, respectively. Prefer to use patterns instead of static strings, because the former are more efficient. |
-| `use_default_shell_env` | [bool](../core/bool); default is `False`  Whether the action should use the default shell environment, which consists of a few OS-dependent variables as well as variables set via [`--action_env`](/versions/8.1.1/reference/command-line-reference#flag--action_env). If both `use_default_shell_env` and `env` are set to `True`, values set in `env` will overwrite the default shell environment if [`--incompatible_merge_fixed_and_default_shell_env`](/versions/8.1.1/reference/command-line-reference#flag--incompatible_merge_fixed_and_default_shell_env) is enabled (default). If the flag is not enabled, `env` is ignored. |
-| `env` | [dict](../core/dict); or `None`; default is `None`  Sets the dictionary of environment variables. If both `use_default_shell_env` and `env` are set to `True`, values set in `env` will overwrite the default shell environment if [`--incompatible_merge_fixed_and_default_shell_env`](/versions/8.1.1/reference/command-line-reference#flag--incompatible_merge_fixed_and_default_shell_env) is enabled (default). If the flag is not enabled, `env` is ignored. |
-| `execution_requirements` | [dict](../core/dict); or `None`; default is `None`  Information for scheduling the action. See [tags](/versions/8.1.1/reference/be/common-definitions#common.tags) for useful keys. |
-| `input_manifests` | [sequence](../core/list); or `None`; default is `None`  Legacy argument. Ignored. |
-| `exec_group` | [string](../core/string); or `None`; default is `None`  Runs the action on the given exec group's execution platform. If none, uses the target's default execution platform. |
-| `shadowed_action` | [Action](../builtins/Action); default is `None`  Runs the action using the given shadowed action's inputs and environment added to the action's inputs list and environment. The action environment can overwrite any of the shadowed action's environment variables. If none, uses only the action's inputs and given environment. |
+| `outputs` | [sequence](/versions/8.1.1/rules/lib/core/list) of [File](/versions/8.1.1/rules/lib/builtins/File)s; required  List of the output files of the action. |
+| `inputs` | [sequence](/versions/8.1.1/rules/lib/core/list) of [File](/versions/8.1.1/rules/lib/builtins/File)s; or [depset](/versions/8.1.1/rules/lib/builtins/depset); default is `[]`  List or depset of the input files of the action. |
+| `unused_inputs_list` | [File](/versions/8.1.1/rules/lib/builtins/File); or `None`; default is `None`  File containing list of inputs unused by the action. The content of this file (generally one of the outputs of the action) corresponds to the list of input files that were not used during the whole action execution. Any change in those files must not affect in any way the outputs of the action. |
+| `executable` | [File](/versions/8.1.1/rules/lib/builtins/File); or [string](/versions/8.1.1/rules/lib/core/string); or [FilesToRunProvider](/versions/8.1.1/rules/lib/providers/FilesToRunProvider); required  The executable file to be called by the action. |
+| `tools` | [sequence](/versions/8.1.1/rules/lib/core/list); or [depset](/versions/8.1.1/rules/lib/builtins/depset); default is `unbound`  List or depset of any tools needed by the action. Tools are inputs with additional runfiles that are automatically made available to the action. When a list is provided, it can be a heterogenous collection of Files, FilesToRunProvider instances, or depsets of Files. Files which are directly in the list and come from ctx.executable will have their runfiles automatically added. When a depset is provided, it must contain only Files. In both cases, files within depsets are not cross-referenced with ctx.executable for runfiles. |
+| `arguments` | [sequence](/versions/8.1.1/rules/lib/core/list); default is `[]`  Command line arguments of the action. Must be a list of strings or [`actions.args()`](#args) objects. |
+| `mnemonic` | [string](/versions/8.1.1/rules/lib/core/string); or `None`; default is `None`  A one-word description of the action, for example, CppCompile or GoLink. |
+| `progress_message` | [string](/versions/8.1.1/rules/lib/core/string); or `None`; default is `None`  Progress message to show to the user during the build, for example, "Compiling foo.cc to create foo.o". The message may contain `%{label}`, `%{input}`, or `%{output}` patterns, which are substituted with label string, first input, or output's path, respectively. Prefer to use patterns instead of static strings, because the former are more efficient. |
+| `use_default_shell_env` | [bool](/versions/8.1.1/rules/lib/core/bool); default is `False`  Whether the action should use the default shell environment, which consists of a few OS-dependent variables as well as variables set via [`--action_env`](/versions/8.1.1/reference/command-line-reference#flag--action_env). If both `use_default_shell_env` and `env` are set to `True`, values set in `env` will overwrite the default shell environment if [`--incompatible_merge_fixed_and_default_shell_env`](/versions/8.1.1/reference/command-line-reference#flag--incompatible_merge_fixed_and_default_shell_env) is enabled (default). If the flag is not enabled, `env` is ignored. |
+| `env` | [dict](/versions/8.1.1/rules/lib/core/dict); or `None`; default is `None`  Sets the dictionary of environment variables. If both `use_default_shell_env` and `env` are set to `True`, values set in `env` will overwrite the default shell environment if [`--incompatible_merge_fixed_and_default_shell_env`](/versions/8.1.1/reference/command-line-reference#flag--incompatible_merge_fixed_and_default_shell_env) is enabled (default). If the flag is not enabled, `env` is ignored. |
+| `execution_requirements` | [dict](/versions/8.1.1/rules/lib/core/dict); or `None`; default is `None`  Information for scheduling the action. See [tags](/versions/8.1.1/reference/be/common-definitions#common.tags) for useful keys. |
+| `input_manifests` | [sequence](/versions/8.1.1/rules/lib/core/list); or `None`; default is `None`  Legacy argument. Ignored. |
+| `exec_group` | [string](/versions/8.1.1/rules/lib/core/string); or `None`; default is `None`  Runs the action on the given exec group's execution platform. If none, uses the target's default execution platform. |
+| `shadowed_action` | [Action](/versions/8.1.1/rules/lib/builtins/Action); default is `None`  Runs the action using the given shadowed action's inputs and environment added to the action's inputs list and environment. The action environment can overwrite any of the shadowed action's environment variables. If none, uses only the action's inputs and given environment. |
 | `resource_set` | callable; or `None`; default is `None`  A callback function that returns a resource set dictionary, used to estimate resource usage at execution time if this action is run locally. The function accepts two positional arguments: a string representing an OS name (e.g. "osx"), and an integer representing the number of inputs to the action. The returned dictionary may contain the following entries, each of which may be a float or an int:  * "cpu": number of CPUs; default 1* "memory": in MB; default 250* "local\_test": number of local tests; default 1   If this parameter is set to `None` , the default values are used. The callback must be top-level (lambda and nested functions aren't allowed). |
-| `toolchain` | [Label](../builtins/Label); or [string](../core/string); or `None`; default is `unbound`  Toolchain type of the executable or tools used in this action.  If executable and tools are not coming from a toolchain, set this parameter to `None`.  If executable and tools are coming from a toolchain, toolchain type must be set so that the action executes on the correct execution platform.  Note that the rule which creates this action needs to define this toolchain inside its 'rule()' function.  When `toolchain` and `exec\_group` parameters are both set, `exec\_group` will be used. An error is raised in case the `exec\_group` doesn't specify the same toolchain. |
+| `toolchain` | [Label](/versions/8.1.1/rules/lib/builtins/Label); or [string](/versions/8.1.1/rules/lib/core/string); or `None`; default is `unbound`  Toolchain type of the executable or tools used in this action.  If executable and tools are not coming from a toolchain, set this parameter to `None`.  If executable and tools are coming from a toolchain, toolchain type must be set so that the action executes on the correct execution platform.  Note that the rule which creates this action needs to define this toolchain inside its 'rule()' function.  When `toolchain` and `exec\_group` parameters are both set, `exec\_group` will be used. An error is raised in case the `exec\_group` doesn't specify the same toolchain. |
 
 ## run\_shell
 
@@ -149,21 +149,21 @@ Creates an action that runs a shell command. [See example of use](https://github
 
 | Parameter | Description |
 | --- | --- |
-| `outputs` | [sequence](../core/list) of [File](../builtins/File)s; required  List of the output files of the action. |
-| `inputs` | [sequence](../core/list) of [File](../builtins/File)s; or [depset](../builtins/depset); default is `[]`  List or depset of the input files of the action. |
-| `tools` | [sequence](../core/list) of [File](../builtins/File)s; or [depset](../builtins/depset); default is `unbound`  List or depset of any tools needed by the action. Tools are inputs with additional runfiles that are automatically made available to the action. The list can contain Files or FilesToRunProvider instances. |
-| `arguments` | [sequence](../core/list); default is `[]`  Command line arguments of the action. Must be a list of strings or [`actions.args()`](#args) objects. Bazel passes the elements in this attribute as arguments to the command.The command can access these arguments using shell variable substitutions such as `$1`, `$2`, etc. Note that since Args objects are flattened before indexing, if there is an Args object of unknown size then all subsequent strings will be at unpredictable indices. It may be useful to use `$@` (to retrieve all arguments) in conjunction with Args objects of indeterminate size. In the case where `command` is a list of strings, this parameter may not be used. |
-| `mnemonic` | [string](../core/string); or `None`; default is `None`  A one-word description of the action, for example, CppCompile or GoLink. |
-| `command` | [string](../core/string); or [sequence](../core/list) of [string](../core/string)s; required  Shell command to execute. This may either be a string (preferred) or a sequence of strings **(deprecated)**. If `command` is a string, then it is executed as if by `sh -c  "" ` -- that is, the elements in `arguments` are made available to the command as `$1`, `$2` (or `%1`, `%2` if using Windows batch), etc. If `arguments` contains any [`actions.args()`](#args) objects, their contents are appended one by one to the command line, so `$`*i* can refer to individual strings within an Args object. Note that if an Args object of unknown size is passed as part of `arguments`, then the strings will be at unknown indices; in this case the `$@` shell substitution (retrieve all arguments) may be useful. **(Deprecated)** If `command` is a sequence of strings, the first item is the executable to run and the remaining items are its arguments. If this form is used, the `arguments` parameter must not be supplied. *Note that this form is deprecated and will soon be removed. It is disabled with `--incompatible\_run\_shell\_command\_string`. Use this flag to verify your code is compatible.*  Bazel uses the same shell to execute the command as it does for genrules. |
-| `progress_message` | [string](../core/string); or `None`; default is `None`  Progress message to show to the user during the build, for example, "Compiling foo.cc to create foo.o". The message may contain `%{label}`, `%{input}`, or `%{output}` patterns, which are substituted with label string, first input, or output's path, respectively. Prefer to use patterns instead of static strings, because the former are more efficient. |
-| `use_default_shell_env` | [bool](../core/bool); default is `False`  Whether the action should use the default shell environment, which consists of a few OS-dependent variables as well as variables set via [`--action_env`](/versions/8.1.1/reference/command-line-reference#flag--action_env). If both `use_default_shell_env` and `env` are set to `True`, values set in `env` will overwrite the default shell environment if [`--incompatible_merge_fixed_and_default_shell_env`](/versions/8.1.1/reference/command-line-reference#flag--incompatible_merge_fixed_and_default_shell_env) is enabled (default). If the flag is not enabled, `env` is ignored. |
-| `env` | [dict](../core/dict); or `None`; default is `None`  Sets the dictionary of environment variables. If both `use_default_shell_env` and `env` are set to `True`, values set in `env` will overwrite the default shell environment if [`--incompatible_merge_fixed_and_default_shell_env`](/versions/8.1.1/reference/command-line-reference#flag--incompatible_merge_fixed_and_default_shell_env) is enabled (default). If the flag is not enabled, `env` is ignored. |
-| `execution_requirements` | [dict](../core/dict); or `None`; default is `None`  Information for scheduling the action. See [tags](/versions/8.1.1/reference/be/common-definitions#common.tags) for useful keys. |
-| `input_manifests` | [sequence](../core/list); or `None`; default is `None`  Legacy argument. Ignored. |
-| `exec_group` | [string](../core/string); or `None`; default is `None`  Runs the action on the given exec group's execution platform. If none, uses the target's default execution platform. |
-| `shadowed_action` | [Action](../builtins/Action); default is `None`  Runs the action using the given shadowed action's discovered inputs added to the action's inputs list. If none, uses only the action's inputs. |
+| `outputs` | [sequence](/versions/8.1.1/rules/lib/core/list) of [File](/versions/8.1.1/rules/lib/builtins/File)s; required  List of the output files of the action. |
+| `inputs` | [sequence](/versions/8.1.1/rules/lib/core/list) of [File](/versions/8.1.1/rules/lib/builtins/File)s; or [depset](/versions/8.1.1/rules/lib/builtins/depset); default is `[]`  List or depset of the input files of the action. |
+| `tools` | [sequence](/versions/8.1.1/rules/lib/core/list) of [File](/versions/8.1.1/rules/lib/builtins/File)s; or [depset](/versions/8.1.1/rules/lib/builtins/depset); default is `unbound`  List or depset of any tools needed by the action. Tools are inputs with additional runfiles that are automatically made available to the action. The list can contain Files or FilesToRunProvider instances. |
+| `arguments` | [sequence](/versions/8.1.1/rules/lib/core/list); default is `[]`  Command line arguments of the action. Must be a list of strings or [`actions.args()`](#args) objects. Bazel passes the elements in this attribute as arguments to the command.The command can access these arguments using shell variable substitutions such as `$1`, `$2`, etc. Note that since Args objects are flattened before indexing, if there is an Args object of unknown size then all subsequent strings will be at unpredictable indices. It may be useful to use `$@` (to retrieve all arguments) in conjunction with Args objects of indeterminate size. In the case where `command` is a list of strings, this parameter may not be used. |
+| `mnemonic` | [string](/versions/8.1.1/rules/lib/core/string); or `None`; default is `None`  A one-word description of the action, for example, CppCompile or GoLink. |
+| `command` | [string](/versions/8.1.1/rules/lib/core/string); or [sequence](/versions/8.1.1/rules/lib/core/list) of [string](/versions/8.1.1/rules/lib/core/string)s; required  Shell command to execute. This may either be a string (preferred) or a sequence of strings **(deprecated)**. If `command` is a string, then it is executed as if by `sh -c  "" ` -- that is, the elements in `arguments` are made available to the command as `$1`, `$2` (or `%1`, `%2` if using Windows batch), etc. If `arguments` contains any [`actions.args()`](#args) objects, their contents are appended one by one to the command line, so `$`*i* can refer to individual strings within an Args object. Note that if an Args object of unknown size is passed as part of `arguments`, then the strings will be at unknown indices; in this case the `$@` shell substitution (retrieve all arguments) may be useful. **(Deprecated)** If `command` is a sequence of strings, the first item is the executable to run and the remaining items are its arguments. If this form is used, the `arguments` parameter must not be supplied. *Note that this form is deprecated and will soon be removed. It is disabled with `--incompatible\_run\_shell\_command\_string`. Use this flag to verify your code is compatible.*  Bazel uses the same shell to execute the command as it does for genrules. |
+| `progress_message` | [string](/versions/8.1.1/rules/lib/core/string); or `None`; default is `None`  Progress message to show to the user during the build, for example, "Compiling foo.cc to create foo.o". The message may contain `%{label}`, `%{input}`, or `%{output}` patterns, which are substituted with label string, first input, or output's path, respectively. Prefer to use patterns instead of static strings, because the former are more efficient. |
+| `use_default_shell_env` | [bool](/versions/8.1.1/rules/lib/core/bool); default is `False`  Whether the action should use the default shell environment, which consists of a few OS-dependent variables as well as variables set via [`--action_env`](/versions/8.1.1/reference/command-line-reference#flag--action_env). If both `use_default_shell_env` and `env` are set to `True`, values set in `env` will overwrite the default shell environment if [`--incompatible_merge_fixed_and_default_shell_env`](/versions/8.1.1/reference/command-line-reference#flag--incompatible_merge_fixed_and_default_shell_env) is enabled (default). If the flag is not enabled, `env` is ignored. |
+| `env` | [dict](/versions/8.1.1/rules/lib/core/dict); or `None`; default is `None`  Sets the dictionary of environment variables. If both `use_default_shell_env` and `env` are set to `True`, values set in `env` will overwrite the default shell environment if [`--incompatible_merge_fixed_and_default_shell_env`](/versions/8.1.1/reference/command-line-reference#flag--incompatible_merge_fixed_and_default_shell_env) is enabled (default). If the flag is not enabled, `env` is ignored. |
+| `execution_requirements` | [dict](/versions/8.1.1/rules/lib/core/dict); or `None`; default is `None`  Information for scheduling the action. See [tags](/versions/8.1.1/reference/be/common-definitions#common.tags) for useful keys. |
+| `input_manifests` | [sequence](/versions/8.1.1/rules/lib/core/list); or `None`; default is `None`  Legacy argument. Ignored. |
+| `exec_group` | [string](/versions/8.1.1/rules/lib/core/string); or `None`; default is `None`  Runs the action on the given exec group's execution platform. If none, uses the target's default execution platform. |
+| `shadowed_action` | [Action](/versions/8.1.1/rules/lib/builtins/Action); default is `None`  Runs the action using the given shadowed action's discovered inputs added to the action's inputs list. If none, uses only the action's inputs. |
 | `resource_set` | callable; or `None`; default is `None`  A callback function for estimating resource usage if run locally. See[`ctx.actions.run()`](#run.resource_set). |
-| `toolchain` | [Label](../builtins/Label); or [string](../core/string); or `None`; default is `unbound`  Toolchain type of the executable or tools used in this action.  If executable and tools are not coming from a toolchain, set this parameter to `None`.  If executable and tools are coming from a toolchain, toolchain type must be set so that the action executes on the correct execution platform.  Note that the rule which creates this action needs to define this toolchain inside its 'rule()' function.  When `toolchain` and `exec\_group` parameters are both set, `exec\_group` will be used. An error is raised in case the `exec\_group` doesn't specify the same toolchain. |
+| `toolchain` | [Label](/versions/8.1.1/rules/lib/builtins/Label); or [string](/versions/8.1.1/rules/lib/core/string); or `None`; default is `unbound`  Toolchain type of the executable or tools used in this action.  If executable and tools are not coming from a toolchain, set this parameter to `None`.  If executable and tools are coming from a toolchain, toolchain type must be set so that the action executes on the correct execution platform.  Note that the rule which creates this action needs to define this toolchain inside its 'rule()' function.  When `toolchain` and `exec\_group` parameters are both set, `exec\_group` will be used. An error is raised in case the `exec\_group` doesn't specify the same toolchain. |
 
 ## symlink
 
@@ -183,11 +183,11 @@ Otherwise, when you use `target_path`, declare `output` with [`declare_symlink()
 
 | Parameter | Description |
 | --- | --- |
-| `output` | [File](../builtins/File); required  The output of this action. |
-| `target_file` | [File](../builtins/File); or `None`; default is `None`  The File that the output symlink will point to. |
-| `target_path` | [string](../core/string); or `None`; default is `None`  The exact path that the output symlink will point to. No normalization or other processing is applied. |
-| `is_executable` | [bool](../core/bool); default is `False`  May only be used with `target_file`, not `target_path`. If true, when the action is executed, the `target_file`'s path is checked to confirm that it is executable, and an error is reported if it is not. Setting `is_executable` to False does not mean the target is not executable, just that no verification is done. This feature does not make sense for `target_path` because dangling symlinks might not exist at build time. |
-| `progress_message` | [string](../core/string); or `None`; default is `None`  Progress message to show to the user during the build. |
+| `output` | [File](/versions/8.1.1/rules/lib/builtins/File); required  The output of this action. |
+| `target_file` | [File](/versions/8.1.1/rules/lib/builtins/File); or `None`; default is `None`  The File that the output symlink will point to. |
+| `target_path` | [string](/versions/8.1.1/rules/lib/core/string); or `None`; default is `None`  The exact path that the output symlink will point to. No normalization or other processing is applied. |
+| `is_executable` | [bool](/versions/8.1.1/rules/lib/core/bool); default is `False`  May only be used with `target_file`, not `target_path`. If true, when the action is executed, the `target_file`'s path is checked to confirm that it is executable, and an error is reported if it is not. Setting `is_executable` to False does not mean the target is not executable, just that no verification is done. This feature does not make sense for `target_path` because dangling symlinks might not exist at build time. |
+| `progress_message` | [string](/versions/8.1.1/rules/lib/core/string); or `None`; default is `None`  Progress message to show to the user during the build. |
 
 ## template\_dict
 
@@ -209,6 +209,6 @@ Creates a file write action. When the action is executed, it will write the give
 
 | Parameter | Description |
 | --- | --- |
-| `output` | [File](../builtins/File); required  The output file. |
-| `content` | [string](../core/string); or [Args](../builtins/Args); required  the contents of the file. May be a either a string or an [`actions.args()`](#args) object. |
-| `is_executable` | [bool](../core/bool); default is `False`  Whether the output file should be executable. |
\ No newline at end of file
+| `output` | [File](/versions/8.1.1/rules/lib/builtins/File); required  The output file. |
+| `content` | [string](/versions/8.1.1/rules/lib/core/string); or [Args](/versions/8.1.1/rules/lib/builtins/Args); required  the contents of the file. May be a either a string or an [`actions.args()`](#args) object. |
+| `is_executable` | [bool](/versions/8.1.1/rules/lib/core/bool); default is `False`  Whether the output file should be executable. |
\ No newline at end of file
diff --git a/versions/8.1.1/rules/lib/builtins/apple_platform.mdx b/versions/8.1.1/rules/lib/builtins/apple_platform.mdx
index ba2fc42e..1dcfbecd 100644
--- a/versions/8.1.1/rules/lib/builtins/apple_platform.mdx
+++ b/versions/8.1.1/rules/lib/builtins/apple_platform.mdx
@@ -4,7 +4,7 @@ title: 'apple\_platform'
 
 Corresponds to Xcode's notion of a platform as would be found in `Xcode.app/Contents/Developer/Platforms`. Each platform represents an Apple platform type (such as iOS or tvOS) combined with one or more related CPU architectures. For example, the iOS simulator platform supports `x86_64` and `i386` architectures.
 
-Specific instances of this type can be retrieved from the fields of the [apple\_common.platform](../toplevel/apple_common#platform) struct:
+Specific instances of this type can be retrieved from the fields of the [apple\_common.platform](/versions/8.1.1/rules/lib/toplevel/apple_common#platform) struct:
 
 * `apple_common.platform.ios_device`
 * `apple_common.platform.ios_simulator`
@@ -14,7 +14,7 @@ Specific instances of this type can be retrieved from the fields of the [apple\_
 * `apple_common.platform.watchos_device`
 * `apple_common.platform.watchos_simulator`
 
-More commonly, however, the [apple](../fragments/apple) configuration fragment has fields/methods that allow rules to determine the platform for which a target is being built.
+More commonly, however, the [apple](/versions/8.1.1/rules/lib/fragments/apple) configuration fragment has fields/methods that allow rules to determine the platform for which a target is being built.
 
 Example:
 
diff --git a/versions/8.1.1/rules/lib/builtins/configuration.mdx b/versions/8.1.1/rules/lib/builtins/configuration.mdx
index 2608d2c8..726d4aa9 100644
--- a/versions/8.1.1/rules/lib/builtins/configuration.mdx
+++ b/versions/8.1.1/rules/lib/builtins/configuration.mdx
@@ -17,7 +17,7 @@ This object holds information about the environment in which the build is runnin
 bool configuration.coverage_enabled
 ```
 
-A boolean that tells whether code coverage is enabled for this run. Note that this does not compute whether a specific rule should be instrumented for code coverage data collection. For that, see the [`ctx.coverage_instrumented`](../builtins/ctx#coverage_instrumented) function.
+A boolean that tells whether code coverage is enabled for this run. Note that this does not compute whether a specific rule should be instrumented for code coverage data collection. For that, see the [`ctx.coverage_instrumented`](/versions/8.1.1/rules/lib/builtins/ctx#coverage_instrumented) function.
 
 ## default\_shell\_env
 
diff --git a/versions/8.1.1/rules/lib/builtins/ctx.mdx b/versions/8.1.1/rules/lib/builtins/ctx.mdx
index 4ceaaa72..6c66bf8d 100644
--- a/versions/8.1.1/rules/lib/builtins/ctx.mdx
+++ b/versions/8.1.1/rules/lib/builtins/ctx.mdx
@@ -66,7 +66,7 @@ A list of ids for all aspects applied to the target. Only available in aspect im
 struct ctx.attr
 ```
 
-A struct to access the values of the [attributes](https://bazel.build/versions/8.1.1/extending/rules#attributes). The values are provided by the user (if not, a default value is used). The attributes of the struct and the types of their values correspond to the keys and values of the [`attrs` dict](../globals/bzl#rule.attrs) provided to the [`rule` function](../globals/bzl#rule). [See example of use](https://github.com/bazelbuild/examples/blob/main/rules/attributes/printer.bzl).
+A struct to access the values of the [attributes](https://bazel.build/versions/8.1.1/extending/rules#attributes). The values are provided by the user (if not, a default value is used). The attributes of the struct and the types of their values correspond to the keys and values of the [`attrs` dict](/versions/8.1.1/rules/lib/globals/bzl#rule.attrs) provided to the [`rule` function](/versions/8.1.1/rules/lib/globals/bzl#rule). [See example of use](https://github.com/bazelbuild/examples/blob/main/rules/attributes/printer.bzl).
 
 ## bin\_dir
 
@@ -98,7 +98,7 @@ Value of the build setting represented by the current target. If this isn't the
 configuration ctx.configuration
 ```
 
-The default configuration. See the [configuration](../builtins/configuration) type for more details.
+The default configuration. See the [configuration](/versions/8.1.1/rules/lib/builtins/configuration) type for more details.
 
 ## coverage\_instrumented
 
@@ -106,13 +106,13 @@ The default configuration. See the [configuration](../builtins/configuration) ty
 bool ctx.coverage_instrumented(target=None)
 ```
 
-Returns whether code coverage instrumentation should be generated when performing compilation actions for this rule or, if `target` is provided, the rule specified by that Target. (If a non-rule or a Starlark rule Target is provided, this returns False.) Checks if the sources of the current rule (if no Target is provided) or the sources of Target should be instrumented based on the --instrumentation\_filter and --instrument\_test\_targets config settings. This differs from `coverage_enabled` in the [configuration](../builtins/configuration), which notes whether coverage data collection is enabled for the entire run, but not whether a specific target should be instrumented.
+Returns whether code coverage instrumentation should be generated when performing compilation actions for this rule or, if `target` is provided, the rule specified by that Target. (If a non-rule or a Starlark rule Target is provided, this returns False.) Checks if the sources of the current rule (if no Target is provided) or the sources of Target should be instrumented based on the --instrumentation\_filter and --instrument\_test\_targets config settings. This differs from `coverage_enabled` in the [configuration](/versions/8.1.1/rules/lib/builtins/configuration), which notes whether coverage data collection is enabled for the entire run, but not whether a specific target should be instrumented.
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `target` | [Target](../builtins/Target); or `None`; default is `None`  A Target specifying a rule. If not provided, defaults to the current rule. |
+| `target` | [Target](/versions/8.1.1/rules/lib/builtins/Target); or `None`; default is `None`  A Target specifying a rule. If not provided, defaults to the current rule. |
 
 ## created\_actions
 
@@ -120,7 +120,7 @@ Returns whether code coverage instrumentation should be generated when performin
 StarlarkValue ctx.created_actions()
 ```
 
-For rules with [\_skylark\_testable](../globals/bzl#rule._skylark_testable) set to `True`, this returns an `Actions` provider representing all actions created so far for the current rule. For all other rules, returns `None`. Note that the provider is not updated when subsequent actions are created, so you will have to call this function again if you wish to inspect them.
+For rules with [\_skylark\_testable](/versions/8.1.1/rules/lib/globals/bzl#rule._skylark_testable) set to `True`, this returns an `Actions` provider representing all actions created so far for the current rule. For all other rules, returns `None`. Note that the provider is not updated when subsequent actions are created, so you will have to call this function again if you wish to inspect them.
 
 This is intended to help write tests for rule-implementation helper functions, which may take in a `ctx` object and create actions on it.
 
@@ -146,7 +146,7 @@ A collection of the execution groups available for this rule, indexed by their n
 struct ctx.executable
 ```
 
-A `struct` containing executable files defined in [label type attributes](../toplevel/attr#label) marked as [`executable=True`](../toplevel/attr#label.executable). The struct fields correspond to the attribute names. Each value in the struct is either a [`File`](../builtins/File) or `None`. If an optional attribute is not specified in the rule then the corresponding struct value is `None`. If a label type is not marked as `executable=True`, no corresponding struct field is generated. [See example of use](https://github.com/bazelbuild/examples/blob/main/rules/actions_run/execute.bzl).
+A `struct` containing executable files defined in [label type attributes](/versions/8.1.1/rules/lib/toplevel/attr#label) marked as [`executable=True`](/versions/8.1.1/rules/lib/toplevel/attr#label.executable). The struct fields correspond to the attribute names. Each value in the struct is either a [`File`](/versions/8.1.1/rules/lib/builtins/File) or `None`. If an optional attribute is not specified in the rule then the corresponding struct value is `None`. If a label type is not marked as `executable=True`, no corresponding struct field is generated. [See example of use](https://github.com/bazelbuild/examples/blob/main/rules/actions_run/execute.bzl).
 
 ## expand\_location
 
@@ -164,8 +164,8 @@ This function is useful to let the user specify a command in a BUILD file (like
 
 | Parameter | Description |
 | --- | --- |
-| `input` | [string](../core/string); required  String to be expanded. |
-| `targets` | [sequence](../core/list) of [Target](../builtins/Target)s; default is `[]`  List of targets for additional lookup information. These are expanded as follows: A target with a single file in `DefaultInfo.files` expands to that file. Other targets expand to their `DefaultInfo.executable` file if set and if `--incompatible_locations_prefers_executable` is enabled, otherwise they expand to `DefaultInfo.files`. |
+| `input` | [string](/versions/8.1.1/rules/lib/core/string); required  String to be expanded. |
+| `targets` | [sequence](/versions/8.1.1/rules/lib/core/list) of [Target](/versions/8.1.1/rules/lib/builtins/Target)s; default is `[]`  List of targets for additional lookup information. These are expanded as follows: A target with a single file in `DefaultInfo.files` expands to that file. Other targets expand to their `DefaultInfo.executable` file if set and if `--incompatible_locations_prefers_executable` is enabled, otherwise they expand to `DefaultInfo.files`. |
 
 May return `None`.
 
@@ -175,7 +175,7 @@ May return `None`.
 string ctx.expand_make_variables(attribute_name, command, additional_substitutions)
 ```
 
-**Deprecated.** Use [ctx.var](../builtins/ctx#var) to access the variables instead.
+**Deprecated.** Use [ctx.var](/versions/8.1.1/rules/lib/builtins/ctx#var) to access the variables instead.
 Returns a string after expanding all references to "Make variables". The variables must have the following format: `$(VAR_NAME)`. Also, `$$VAR_NAME` expands to `$VAR_NAME`. Examples:
 
 ```
@@ -189,9 +189,9 @@ Additional variables may come from other places, such as configurations. Note th
 
 | Parameter | Description |
 | --- | --- |
-| `attribute_name` | [string](../core/string); required |
-| `command` | [string](../core/string); required  The expression to expand. It can contain references to "Make variables". |
-| `additional_substitutions` | [dict](../core/dict); required  Additional substitutions to make beyond the default make variables. |
+| `attribute_name` | [string](/versions/8.1.1/rules/lib/core/string); required |
+| `command` | [string](/versions/8.1.1/rules/lib/core/string); required  The expression to expand. It can contain references to "Make variables". |
+| `additional_substitutions` | [dict](/versions/8.1.1/rules/lib/core/dict); required  Additional substitutions to make beyond the default make variables. |
 
 ## features
 
@@ -207,7 +207,7 @@ The set of features that are explicitly enabled by the user for this rule. [See
 struct ctx.file
 ```
 
-A `struct` containing files defined in [label type attributes](../toplevel/attr#label) marked as [`allow_single_file`](../toplevel/attr#label.allow_single_file). The struct fields correspond to the attribute names. The struct value is always a [`File`](../builtins/File) or `None`. If an optional attribute is not specified in the rule then the corresponding struct value is `None`. If a label type is not marked as `allow_single_file`, no corresponding struct field is generated. It is a shortcut for:
+A `struct` containing files defined in [label type attributes](/versions/8.1.1/rules/lib/toplevel/attr#label) marked as [`allow_single_file`](/versions/8.1.1/rules/lib/toplevel/attr#label.allow_single_file). The struct fields correspond to the attribute names. The struct value is always a [`File`](/versions/8.1.1/rules/lib/builtins/File) or `None`. If an optional attribute is not specified in the rule then the corresponding struct value is `None`. If a label type is not marked as `allow_single_file`, no corresponding struct field is generated. It is a shortcut for:
 
 ```
 list(ctx.attr..files)[0]
@@ -221,7 +221,7 @@ In other words, use `file` to access the (singular) [default output](https://baz
 struct ctx.files
 ```
 
-A `struct` containing files defined in [label](../toplevel/attr#label) or [label list](../toplevel/attr#label_list) type attributes. The struct fields correspond to the attribute names. The struct values are `list` of [`File`](../builtins/File)s. It is a shortcut for:
+A `struct` containing files defined in [label](/versions/8.1.1/rules/lib/toplevel/attr#label) or [label list](/versions/8.1.1/rules/lib/toplevel/attr#label_list) type attributes. The struct fields correspond to the attribute names. The struct values are `list` of [`File`](/versions/8.1.1/rules/lib/builtins/File)s. It is a shortcut for:
 
 ```
 [f for t in ctx.attr. for f in t.files]
@@ -267,13 +267,13 @@ The label of the target currently being analyzed.
 structure ctx.outputs
 ```
 
-A pseudo-struct containing all the predeclared output files, represented by [`File`](../builtins/File) objects. See the [Rules page](https://bazel.build/versions/8.1.1/extending/rules#files) for more information and examples.
+A pseudo-struct containing all the predeclared output files, represented by [`File`](/versions/8.1.1/rules/lib/builtins/File) objects. See the [Rules page](https://bazel.build/versions/8.1.1/extending/rules#files) for more information and examples.
 
 This field does not exist on aspect contexts, since aspects do not have predeclared outputs.
 
 The fields of this object are defined as follows. It is an error if two outputs produce the same field name or have the same label.
 
-* If the rule declares an [`outputs`](../globals/bzl#rule.outputs) dict, then for every entry in the dict, there is a field whose name is the key and whose value is the corresponding `File`.* For every attribute of type [`attr.output`](../toplevel/attr#output) that the rule declares, there is a field whose name is the attribute's name. If the target specified a label for that attribute, then the field value is the corresponding `File`; otherwise the field value is `None`.* For every attribute of type [`attr.output_list`](../toplevel/attr#output_list) that the rule declares, there is a field whose name is the attribute's name. The field value is a list of `File` objects corresponding to the labels given for that attribute in the target, or an empty list if the attribute was not specified in the target.* **(Deprecated)** If the rule is marked [`executable`](../globals/bzl#rule.executable) or [`test`](../globals/bzl#rule.test), there is a field named `"executable"`, which is the default executable. It is recommended that instead of using this, you pass another file (either predeclared or not) to the `executable` arg of [`DefaultInfo`](../providers/DefaultInfo).
+* If the rule declares an [`outputs`](/versions/8.1.1/rules/lib/globals/bzl#rule.outputs) dict, then for every entry in the dict, there is a field whose name is the key and whose value is the corresponding `File`.* For every attribute of type [`attr.output`](/versions/8.1.1/rules/lib/toplevel/attr#output) that the rule declares, there is a field whose name is the attribute's name. If the target specified a label for that attribute, then the field value is the corresponding `File`; otherwise the field value is `None`.* For every attribute of type [`attr.output_list`](/versions/8.1.1/rules/lib/toplevel/attr#output_list) that the rule declares, there is a field whose name is the attribute's name. The field value is a list of `File` objects corresponding to the labels given for that attribute in the target, or an empty list if the attribute was not specified in the target.* **(Deprecated)** If the rule is marked [`executable`](/versions/8.1.1/rules/lib/globals/bzl#rule.executable) or [`test`](/versions/8.1.1/rules/lib/globals/bzl#rule.test), there is a field named `"executable"`, which is the default executable. It is recommended that instead of using this, you pass another file (either predeclared or not) to the `executable` arg of [`DefaultInfo`](/versions/8.1.1/rules/lib/providers/DefaultInfo).
 
 ## resolve\_command
 
@@ -288,13 +288,13 @@ tuple ctx.resolve_command(command='', attribute=None, expand_locations=False, ma
 
 | Parameter | Description |
 | --- | --- |
-| `command` | [string](../core/string); default is `''`  Command to resolve. |
-| `attribute` | [string](../core/string); or `None`; default is `None`  Name of the associated attribute for which to issue an error, or None. |
-| `expand_locations` | [bool](../core/bool); default is `False`  Shall we expand $(location) variables? See [ctx.expand\_location()](#expand_location) for more details. |
-| `make_variables` | [dict](../core/dict); or `None`; default is `None`  Make variables to expand, or None. |
-| `tools` | [sequence](../core/list) of [Target](../builtins/Target)s; default is `[]`  List of tools (list of targets). |
-| `label_dict` | [dict](../core/dict); default is `{}`  Dictionary of resolved labels and the corresponding list of Files (a dict of Label : list of Files). |
-| `execution_requirements` | [dict](../core/dict); default is `{}`  Information for scheduling the action to resolve this command. See [tags](/versions/8.1.1/reference/be/common-definitions#common.tags) for useful keys. |
+| `command` | [string](/versions/8.1.1/rules/lib/core/string); default is `''`  Command to resolve. |
+| `attribute` | [string](/versions/8.1.1/rules/lib/core/string); or `None`; default is `None`  Name of the associated attribute for which to issue an error, or None. |
+| `expand_locations` | [bool](/versions/8.1.1/rules/lib/core/bool); default is `False`  Shall we expand $(location) variables? See [ctx.expand\_location()](#expand_location) for more details. |
+| `make_variables` | [dict](/versions/8.1.1/rules/lib/core/dict); or `None`; default is `None`  Make variables to expand, or None. |
+| `tools` | [sequence](/versions/8.1.1/rules/lib/core/list) of [Target](/versions/8.1.1/rules/lib/builtins/Target)s; default is `[]`  List of tools (list of targets). |
+| `label_dict` | [dict](/versions/8.1.1/rules/lib/core/dict); default is `{}`  Dictionary of resolved labels and the corresponding list of Files (a dict of Label : list of Files). |
+| `execution_requirements` | [dict](/versions/8.1.1/rules/lib/core/dict); default is `{}`  Information for scheduling the action to resolve this command. See [tags](/versions/8.1.1/reference/be/common-definitions#common.tags) for useful keys. |
 
 ## resolve\_tools
 
@@ -310,7 +310,7 @@ In contrast to `ctx.resolve_command`, this method does not require that Bash be
 
 | Parameter | Description |
 | --- | --- |
-| `tools` | [sequence](../core/list) of [Target](../builtins/Target)s; default is `[]`  List of tools (list of targets). |
+| `tools` | [sequence](/versions/8.1.1/rules/lib/core/list) of [Target](/versions/8.1.1/rules/lib/builtins/Target)s; default is `[]`  List of tools (list of targets). |
 
 ## rule
 
@@ -332,12 +332,12 @@ Creates a runfiles object.
 
 | Parameter | Description |
 | --- | --- |
-| `files` | [sequence](../core/list) of [File](../builtins/File)s; default is `[]`  The list of files to be added to the runfiles. |
-| `transitive_files` | [depset](../builtins/depset) of [File](../builtins/File)s; or `None`; default is `None`  The (transitive) set of files to be added to the runfiles. The depset should use the `default` order (which, as the name implies, is the default). |
-| `collect_data` | [bool](../core/bool); default is `False`  **Use of this parameter is not recommended. See [runfiles guide](https://bazel.build/versions/8.1.1/extending/rules#runfiles)**. Whether to collect the data runfiles from the dependencies in srcs, data and deps attributes. |
-| `collect_default` | [bool](../core/bool); default is `False`  **Use of this parameter is not recommended. See [runfiles guide](https://bazel.build/versions/8.1.1/extending/rules#runfiles)**. Whether to collect the default runfiles from the dependencies in srcs, data and deps attributes. |
-| `symlinks` | [dict](../core/dict); or [depset](../builtins/depset) of [SymlinkEntry](../builtins/SymlinkEntry)s; default is `{}`  Either a SymlinkEntry depset or the map of symlinks to be added to the runfiles. Symlinks are always added under the main workspace's runfiles directory (e.g. `/_main/`, **not** the directory corresponding to the current target's repository. See [Runfiles symlinks](https://bazel.build/versions/8.1.1/extending/rules#runfiles_symlinks) in the rules guide. |
-| `root_symlinks` | [dict](../core/dict); or [depset](../builtins/depset) of [SymlinkEntry](../builtins/SymlinkEntry)s; default is `{}`  Either a SymlinkEntry depset or a map of symlinks to be added to the runfiles. See [Runfiles symlinks](https://bazel.build/versions/8.1.1/extending/rules#runfiles_symlinks) in the rules guide. |
+| `files` | [sequence](/versions/8.1.1/rules/lib/core/list) of [File](/versions/8.1.1/rules/lib/builtins/File)s; default is `[]`  The list of files to be added to the runfiles. |
+| `transitive_files` | [depset](/versions/8.1.1/rules/lib/builtins/depset) of [File](/versions/8.1.1/rules/lib/builtins/File)s; or `None`; default is `None`  The (transitive) set of files to be added to the runfiles. The depset should use the `default` order (which, as the name implies, is the default). |
+| `collect_data` | [bool](/versions/8.1.1/rules/lib/core/bool); default is `False`  **Use of this parameter is not recommended. See [runfiles guide](https://bazel.build/versions/8.1.1/extending/rules#runfiles)**. Whether to collect the data runfiles from the dependencies in srcs, data and deps attributes. |
+| `collect_default` | [bool](/versions/8.1.1/rules/lib/core/bool); default is `False`  **Use of this parameter is not recommended. See [runfiles guide](https://bazel.build/versions/8.1.1/extending/rules#runfiles)**. Whether to collect the default runfiles from the dependencies in srcs, data and deps attributes. |
+| `symlinks` | [dict](/versions/8.1.1/rules/lib/core/dict); or [depset](/versions/8.1.1/rules/lib/builtins/depset) of [SymlinkEntry](/versions/8.1.1/rules/lib/builtins/SymlinkEntry)s; default is `{}`  Either a SymlinkEntry depset or the map of symlinks to be added to the runfiles. Symlinks are always added under the main workspace's runfiles directory (e.g. `/_main/`, **not** the directory corresponding to the current target's repository. See [Runfiles symlinks](https://bazel.build/versions/8.1.1/extending/rules#runfiles_symlinks) in the rules guide. |
+| `root_symlinks` | [dict](/versions/8.1.1/rules/lib/core/dict); or [depset](/versions/8.1.1/rules/lib/builtins/depset) of [SymlinkEntry](/versions/8.1.1/rules/lib/builtins/SymlinkEntry)s; default is `{}`  Either a SymlinkEntry depset or a map of symlinks to be added to the runfiles. See [Runfiles symlinks](https://bazel.build/versions/8.1.1/extending/rules#runfiles_symlinks) in the rules guide. |
 
 ## split\_attr
 
@@ -367,7 +367,7 @@ Returns true if the given constraint value is part of the current target platfor
 
 | Parameter | Description |
 | --- | --- |
-| `constraintValue` | [ConstraintValueInfo](../providers/ConstraintValueInfo); required  The constraint value to check the target platform against. |
+| `constraintValue` | [ConstraintValueInfo](/versions/8.1.1/rules/lib/providers/ConstraintValueInfo); required  The constraint value to check the target platform against. |
 
 ## toolchains
 
diff --git a/versions/8.1.1/rules/lib/builtins/depset.mdx b/versions/8.1.1/rules/lib/builtins/depset.mdx
index a40f7d26..14585491 100644
--- a/versions/8.1.1/rules/lib/builtins/depset.mdx
+++ b/versions/8.1.1/rules/lib/builtins/depset.mdx
@@ -6,7 +6,7 @@ A specialized data structure that supports efficient merge operations and has a
 
 The elements of a depset must be hashable and all of the same type (as defined by the built-in type(x) function), but depsets are not simply hash sets and do not support fast membership tests. If you need a general set datatype, you can simulate one using a dictionary where all keys map to `True`.
 
-Depsets are immutable. They should be created using their [constructor function](../globals/bzl#depset) and merged or augmented with other depsets via the `transitive` argument.
+Depsets are immutable. They should be created using their [constructor function](/versions/8.1.1/rules/lib/globals/bzl#depset) and merged or augmented with other depsets via the `transitive` argument.
 
 The `order` parameter determines the kind of traversal that is done to convert the depset to an iterable. There are four possible values:
 
diff --git a/versions/8.1.1/rules/lib/builtins/fragments.mdx b/versions/8.1.1/rules/lib/builtins/fragments.mdx
index fcb2b699..de401221 100644
--- a/versions/8.1.1/rules/lib/builtins/fragments.mdx
+++ b/versions/8.1.1/rules/lib/builtins/fragments.mdx
@@ -6,4 +6,4 @@ A collection of configuration fragments available in the current rule implementa
 
 Only configuration fragments which are declared in the rule definition may be accessed in this collection.
 
-See the [configuration fragment reference](../fragments) for a list of available fragments and the [rules documentation](https://bazel.build/versions/8.1.1/extending/rules#configuration_fragments) for how to use them.
\ No newline at end of file
+See the [configuration fragment reference](/versions/8.1.1/rules/lib/fragments) for a list of available fragments and the [rules documentation](https://bazel.build/versions/8.1.1/extending/rules#configuration_fragments) for how to use them.
\ No newline at end of file
diff --git a/versions/8.1.1/rules/lib/builtins/macro.mdx b/versions/8.1.1/rules/lib/builtins/macro.mdx
index 34c572ad..5936dff5 100644
--- a/versions/8.1.1/rules/lib/builtins/macro.mdx
+++ b/versions/8.1.1/rules/lib/builtins/macro.mdx
@@ -3,7 +3,7 @@ title: 'macro'
 ---
 
 A callable Starlark value representing a symbolic macro; in other words, the return value of
-[`macro()`](../globals/bzl#macro). Invoking this value during package
+[`macro()`](/versions/8.1.1/rules/lib/globals/bzl#macro). Invoking this value during package
 construction time will instantiate the macro, and cause the macro's implementation function to be
 evaluated (in a separate context, different from the context in which the macro value was invoked),
 in most cases causing targets to be added to the package's target set. For more information, see
diff --git a/versions/8.1.1/rules/lib/builtins/module_ctx.mdx b/versions/8.1.1/rules/lib/builtins/module_ctx.mdx
index 4bb17215..15293f60 100644
--- a/versions/8.1.1/rules/lib/builtins/module_ctx.mdx
+++ b/versions/8.1.1/rules/lib/builtins/module_ctx.mdx
@@ -35,16 +35,16 @@ Downloads a file to the output path for the provided url and returns a struct co
 
 | Parameter | Description |
 | --- | --- |
-| `url` | [string](../core/string); or Iterable of [string](../core/string)s; required  List of mirror URLs referencing the same file. |
-| `output` | [string](../core/string); or [Label](../builtins/Label); or [path](../builtins/path); default is `''`  path to the output file, relative to the repository directory. |
-| `sha256` | [string](../core/string); default is `''`  The expected SHA-256 hash of the file downloaded. This must match the SHA-256 hash of the file downloaded. It is a security risk to omit the SHA-256 as remote files can change. At best omitting this field will make your build non-hermetic. It is optional to make development easier but should be set before shipping. If provided, the repository cache will first be checked for a file with the given hash; a download will only be attempted if the file was not found in the cache. After a successful download, the file will be added to the cache. |
-| `executable` | [bool](../core/bool); default is `False`  Set the executable flag on the created file, false by default. |
-| `allow_fail` | [bool](../core/bool); default is `False`  If set, indicate the error in the return value instead of raising an error for failed downloads. |
-| `canonical_id` | [string](../core/string); default is `''`  If set, restrict cache hits to those cases where the file was added to the cache with the same canonical id. By default caching uses the checksum (`sha256` or `integrity`). |
-| `auth` | [dict](../core/dict); default is `{}`  An optional dict specifying authentication information for some of the URLs. |
-| `headers` | [dict](../core/dict); default is `{}`  An optional dict specifying http headers for all URLs. |
-| `integrity` | [string](../core/string); default is `''`  Expected checksum of the file downloaded, in Subresource Integrity format. This must match the checksum of the file downloaded. It is a security risk to omit the checksum as remote files can change. At best omitting this field will make your build non-hermetic. It is optional to make development easier but should be set before shipping. If provided, the repository cache will first be checked for a file with the given checksum; a download will only be attempted if the file was not found in the cache. After a successful download, the file will be added to the cache. |
-| `block` | [bool](../core/bool); default is `True`  If set to false, the call returns immediately and instead of the regular return value, it returns a token with one single method, wait(), which blocks until the download is finished and returns the usual return value or throws as usual. |
+| `url` | [string](/versions/8.1.1/rules/lib/core/string); or Iterable of [string](/versions/8.1.1/rules/lib/core/string)s; required  List of mirror URLs referencing the same file. |
+| `output` | [string](/versions/8.1.1/rules/lib/core/string); or [Label](/versions/8.1.1/rules/lib/builtins/Label); or [path](/versions/8.1.1/rules/lib/builtins/path); default is `''`  path to the output file, relative to the repository directory. |
+| `sha256` | [string](/versions/8.1.1/rules/lib/core/string); default is `''`  The expected SHA-256 hash of the file downloaded. This must match the SHA-256 hash of the file downloaded. It is a security risk to omit the SHA-256 as remote files can change. At best omitting this field will make your build non-hermetic. It is optional to make development easier but should be set before shipping. If provided, the repository cache will first be checked for a file with the given hash; a download will only be attempted if the file was not found in the cache. After a successful download, the file will be added to the cache. |
+| `executable` | [bool](/versions/8.1.1/rules/lib/core/bool); default is `False`  Set the executable flag on the created file, false by default. |
+| `allow_fail` | [bool](/versions/8.1.1/rules/lib/core/bool); default is `False`  If set, indicate the error in the return value instead of raising an error for failed downloads. |
+| `canonical_id` | [string](/versions/8.1.1/rules/lib/core/string); default is `''`  If set, restrict cache hits to those cases where the file was added to the cache with the same canonical id. By default caching uses the checksum (`sha256` or `integrity`). |
+| `auth` | [dict](/versions/8.1.1/rules/lib/core/dict); default is `{}`  An optional dict specifying authentication information for some of the URLs. |
+| `headers` | [dict](/versions/8.1.1/rules/lib/core/dict); default is `{}`  An optional dict specifying http headers for all URLs. |
+| `integrity` | [string](/versions/8.1.1/rules/lib/core/string); default is `''`  Expected checksum of the file downloaded, in Subresource Integrity format. This must match the checksum of the file downloaded. It is a security risk to omit the checksum as remote files can change. At best omitting this field will make your build non-hermetic. It is optional to make development easier but should be set before shipping. If provided, the repository cache will first be checked for a file with the given checksum; a download will only be attempted if the file was not found in the cache. After a successful download, the file will be added to the cache. |
+| `block` | [bool](/versions/8.1.1/rules/lib/core/bool); default is `True`  If set to false, the call returns immediately and instead of the regular return value, it returns a token with one single method, wait(), which blocks until the download is finished and returns the usual return value or throws as usual. |
 
 ## download\_and\_extract
 
@@ -58,17 +58,17 @@ Downloads a file to the output path for the provided url, extracts it, and retur
 
 | Parameter | Description |
 | --- | --- |
-| `url` | [string](../core/string); or Iterable of [string](../core/string)s; required  List of mirror URLs referencing the same file. |
-| `output` | [string](../core/string); or [Label](../builtins/Label); or [path](../builtins/path); default is `''`  Path to the directory where the archive will be unpacked, relative to the repository directory. |
-| `sha256` | [string](../core/string); default is `''`  The expected SHA-256 hash of the file downloaded. This must match the SHA-256 hash of the file downloaded. It is a security risk to omit the SHA-256 as remote files can change. At best omitting this field will make your build non-hermetic. It is optional to make development easier but should be set before shipping. If provided, the repository cache will first be checked for a file with the given hash; a download will only be attempted if the file was not found in the cache. After a successful download, the file will be added to the cache. |
-| `type` | [string](../core/string); default is `''`  The archive type of the downloaded file. By default, the archive type is determined from the file extension of the URL. If the file has no extension, you can explicitly specify either "zip", "jar", "war", "aar", "nupkg", "tar", "tar.gz", "tgz", "tar.xz", "txz", ".tar.zst", ".tzst", "tar.bz2", ".tbz", ".ar", or ".deb" here. |
-| `strip_prefix` | [string](../core/string); default is `''`  A directory prefix to strip from the extracted files. Many archives contain a top-level directory that contains all files in the archive. Instead of needing to specify this prefix over and over in the `build_file`, this field can be used to strip it from extracted files. For compatibility, this parameter may also be used under the deprecated name `stripPrefix`. |
-| `allow_fail` | [bool](../core/bool); default is `False`  If set, indicate the error in the return value instead of raising an error for failed downloads. |
-| `canonical_id` | [string](../core/string); default is `''`  If set, restrict cache hits to those cases where the file was added to the cache with the same canonical id. By default caching uses the checksum" (`sha256` or `integrity`). |
-| `auth` | [dict](../core/dict); default is `{}`  An optional dict specifying authentication information for some of the URLs. |
-| `headers` | [dict](../core/dict); default is `{}`  An optional dict specifying http headers for all URLs. |
-| `integrity` | [string](../core/string); default is `''`  Expected checksum of the file downloaded, in Subresource Integrity format. This must match the checksum of the file downloaded. It is a security risk to omit the checksum as remote files can change. At best omitting this field will make your build non-hermetic. It is optional to make development easier but should be set before shipping. If provided, the repository cache will first be checked for a file with the given checksum; a download will only be attempted if the file was not found in the cache. After a successful download, the file will be added to the cache. |
-| `rename_files` | [dict](../core/dict); default is `{}`  An optional dict specifying files to rename during the extraction. Archive entries with names exactly matching a key will be renamed to the value, prior to any directory prefix adjustment. This can be used to extract archives that contain non-Unicode filenames, or which have files that would extract to the same path on case-insensitive filesystems. |
+| `url` | [string](/versions/8.1.1/rules/lib/core/string); or Iterable of [string](/versions/8.1.1/rules/lib/core/string)s; required  List of mirror URLs referencing the same file. |
+| `output` | [string](/versions/8.1.1/rules/lib/core/string); or [Label](/versions/8.1.1/rules/lib/builtins/Label); or [path](/versions/8.1.1/rules/lib/builtins/path); default is `''`  Path to the directory where the archive will be unpacked, relative to the repository directory. |
+| `sha256` | [string](/versions/8.1.1/rules/lib/core/string); default is `''`  The expected SHA-256 hash of the file downloaded. This must match the SHA-256 hash of the file downloaded. It is a security risk to omit the SHA-256 as remote files can change. At best omitting this field will make your build non-hermetic. It is optional to make development easier but should be set before shipping. If provided, the repository cache will first be checked for a file with the given hash; a download will only be attempted if the file was not found in the cache. After a successful download, the file will be added to the cache. |
+| `type` | [string](/versions/8.1.1/rules/lib/core/string); default is `''`  The archive type of the downloaded file. By default, the archive type is determined from the file extension of the URL. If the file has no extension, you can explicitly specify either "zip", "jar", "war", "aar", "nupkg", "tar", "tar.gz", "tgz", "tar.xz", "txz", ".tar.zst", ".tzst", "tar.bz2", ".tbz", ".ar", or ".deb" here. |
+| `strip_prefix` | [string](/versions/8.1.1/rules/lib/core/string); default is `''`  A directory prefix to strip from the extracted files. Many archives contain a top-level directory that contains all files in the archive. Instead of needing to specify this prefix over and over in the `build_file`, this field can be used to strip it from extracted files. For compatibility, this parameter may also be used under the deprecated name `stripPrefix`. |
+| `allow_fail` | [bool](/versions/8.1.1/rules/lib/core/bool); default is `False`  If set, indicate the error in the return value instead of raising an error for failed downloads. |
+| `canonical_id` | [string](/versions/8.1.1/rules/lib/core/string); default is `''`  If set, restrict cache hits to those cases where the file was added to the cache with the same canonical id. By default caching uses the checksum" (`sha256` or `integrity`). |
+| `auth` | [dict](/versions/8.1.1/rules/lib/core/dict); default is `{}`  An optional dict specifying authentication information for some of the URLs. |
+| `headers` | [dict](/versions/8.1.1/rules/lib/core/dict); default is `{}`  An optional dict specifying http headers for all URLs. |
+| `integrity` | [string](/versions/8.1.1/rules/lib/core/string); default is `''`  Expected checksum of the file downloaded, in Subresource Integrity format. This must match the checksum of the file downloaded. It is a security risk to omit the checksum as remote files can change. At best omitting this field will make your build non-hermetic. It is optional to make development easier but should be set before shipping. If provided, the repository cache will first be checked for a file with the given checksum; a download will only be attempted if the file was not found in the cache. After a successful download, the file will be added to the cache. |
+| `rename_files` | [dict](/versions/8.1.1/rules/lib/core/dict); default is `{}`  An optional dict specifying files to rename during the extraction. Archive entries with names exactly matching a key will be renamed to the value, prior to any directory prefix adjustment. This can be used to extract archives that contain non-Unicode filenames, or which have files that would extract to the same path on case-insensitive filesystems. |
 
 ## execute
 
@@ -82,11 +82,11 @@ Executes the command given by the list of arguments. The execution time of the c
 
 | Parameter | Description |
 | --- | --- |
-| `arguments` | [sequence](../core/list); required  List of arguments, the first element should be the path to the program to execute. |
-| `timeout` | [int](../core/int); default is `600`  Maximum duration of the command in seconds (default is 600 seconds). |
-| `environment` | [dict](../core/dict); default is `{}`  Force some environment variables to be set to be passed to the process. The value can be `None` to remove the environment variable. |
-| `quiet` | [bool](../core/bool); default is `True`  If stdout and stderr should be printed to the terminal. |
-| `working_directory` | [string](../core/string); default is `""`  Working directory for command execution. Can be relative to the repository root or absolute. The default is the repository root. |
+| `arguments` | [sequence](/versions/8.1.1/rules/lib/core/list); required  List of arguments, the first element should be the path to the program to execute. |
+| `timeout` | [int](/versions/8.1.1/rules/lib/core/int); default is `600`  Maximum duration of the command in seconds (default is 600 seconds). |
+| `environment` | [dict](/versions/8.1.1/rules/lib/core/dict); default is `{}`  Force some environment variables to be set to be passed to the process. The value can be `None` to remove the environment variable. |
+| `quiet` | [bool](/versions/8.1.1/rules/lib/core/bool); default is `True`  If stdout and stderr should be printed to the terminal. |
+| `working_directory` | [string](/versions/8.1.1/rules/lib/core/string); default is `""`  Working directory for command execution. Can be relative to the repository root or absolute. The default is the repository root. |
 
 ## extension\_metadata
 
@@ -100,9 +100,9 @@ Constructs an opaque object that can be returned from the module extension's imp
 
 | Parameter | Description |
 | --- | --- |
-| `root_module_direct_deps` | [sequence](../core/list) of [string](../core/string)s; or [string](../core/string); or `None`; default is `None`  The names of the repositories that the extension considers to be direct dependencies of the root module. If the root module imports additional repositories or does not import all of these repositories via [`use_repo`](../globals/module#use_repo), Bazel will print a warning when the extension is evaluated, instructing the user to run `bazel mod tidy` to fix the `use_repo` calls automatically. If one of `root_module_direct_deps` and will print a warning and a fixup command when the extension is evaluated. If one of `root_module_direct_deps` and `root_module_direct_dev_deps` is specified, the other has to be as well. The lists specified by these two parameters must be disjoint. Exactly one of `root_module_direct_deps` and `root_module_direct_dev_deps` can be set to the special value `"all"`, which is treated as if a list with the names of all repositories generated by the extension was specified as the value. |
-| `root_module_direct_dev_deps` | [sequence](../core/list) of [string](../core/string)s; or [string](../core/string); or `None`; default is `None`  The names of the repositories that the extension considers to be direct dev dependencies of the root module. If the root module imports additional repositories or does not import all of these repositories via [`use_repo`](../globals/module#use_repo) on an extension proxy created with `use_extension(..., dev_dependency = True)`, Bazel will print a warning when the extension is evaluated, instructing the user to run `bazel mod tidy` to fix the `use_repo` calls automatically. If one of `root_module_direct_deps` and `root_module_direct_dev_deps` is specified, the other has to be as well. The lists specified by these two parameters must be disjoint. Exactly one of `root_module_direct_deps` and `root_module_direct_dev_deps` can be set to the special value `"all"`, which is treated as if a list with the names of all repositories generated by the extension was specified as the value. |
-| `reproducible` | [bool](../core/bool); default is `False`  States that this module extension ensures complete reproducibility, thereby it should not be stored in the lockfile. |
+| `root_module_direct_deps` | [sequence](/versions/8.1.1/rules/lib/core/list) of [string](/versions/8.1.1/rules/lib/core/string)s; or [string](/versions/8.1.1/rules/lib/core/string); or `None`; default is `None`  The names of the repositories that the extension considers to be direct dependencies of the root module. If the root module imports additional repositories or does not import all of these repositories via [`use_repo`](/versions/8.1.1/rules/lib/globals/module#use_repo), Bazel will print a warning when the extension is evaluated, instructing the user to run `bazel mod tidy` to fix the `use_repo` calls automatically. If one of `root_module_direct_deps` and will print a warning and a fixup command when the extension is evaluated. If one of `root_module_direct_deps` and `root_module_direct_dev_deps` is specified, the other has to be as well. The lists specified by these two parameters must be disjoint. Exactly one of `root_module_direct_deps` and `root_module_direct_dev_deps` can be set to the special value `"all"`, which is treated as if a list with the names of all repositories generated by the extension was specified as the value. |
+| `root_module_direct_dev_deps` | [sequence](/versions/8.1.1/rules/lib/core/list) of [string](/versions/8.1.1/rules/lib/core/string)s; or [string](/versions/8.1.1/rules/lib/core/string); or `None`; default is `None`  The names of the repositories that the extension considers to be direct dev dependencies of the root module. If the root module imports additional repositories or does not import all of these repositories via [`use_repo`](/versions/8.1.1/rules/lib/globals/module#use_repo) on an extension proxy created with `use_extension(..., dev_dependency = True)`, Bazel will print a warning when the extension is evaluated, instructing the user to run `bazel mod tidy` to fix the `use_repo` calls automatically. If one of `root_module_direct_deps` and `root_module_direct_dev_deps` is specified, the other has to be as well. The lists specified by these two parameters must be disjoint. Exactly one of `root_module_direct_deps` and `root_module_direct_dev_deps` can be set to the special value `"all"`, which is treated as if a list with the names of all repositories generated by the extension was specified as the value. |
+| `reproducible` | [bool](/versions/8.1.1/rules/lib/core/bool); default is `False`  States that this module extension ensures complete reproducibility, thereby it should not be stored in the lockfile. |
 
 ## extract
 
@@ -116,11 +116,11 @@ Extract an archive to the repository directory.
 
 | Parameter | Description |
 | --- | --- |
-| `archive` | [string](../core/string); or [Label](../builtins/Label); or [path](../builtins/path); required  path to the archive that will be unpacked, relative to the repository directory. |
-| `output` | [string](../core/string); or [Label](../builtins/Label); or [path](../builtins/path); default is `''`  path to the directory where the archive will be unpacked, relative to the repository directory. |
-| `strip_prefix` | [string](../core/string); default is `''`  a directory prefix to strip from the extracted files. Many archives contain a top-level directory that contains all files in the archive. Instead of needing to specify this prefix over and over in the `build_file`, this field can be used to strip it from extracted files. For compatibility, this parameter may also be used under the deprecated name `stripPrefix`. |
-| `rename_files` | [dict](../core/dict); default is `{}`  An optional dict specifying files to rename during the extraction. Archive entries with names exactly matching a key will be renamed to the value, prior to any directory prefix adjustment. This can be used to extract archives that contain non-Unicode filenames, or which have files that would extract to the same path on case-insensitive filesystems. |
-| `watch_archive` | [string](../core/string); default is `'auto'`  whether to [watch](#watch) the archive file. Can be the string 'yes', 'no', or 'auto'. Passing 'yes' is equivalent to immediately invoking the [`watch()`](#watch) method; passing 'no' does not attempt to watch the file; passing 'auto' will only attempt to watch the file when it is legal to do so (see `watch()` docs for more information. |
+| `archive` | [string](/versions/8.1.1/rules/lib/core/string); or [Label](/versions/8.1.1/rules/lib/builtins/Label); or [path](/versions/8.1.1/rules/lib/builtins/path); required  path to the archive that will be unpacked, relative to the repository directory. |
+| `output` | [string](/versions/8.1.1/rules/lib/core/string); or [Label](/versions/8.1.1/rules/lib/builtins/Label); or [path](/versions/8.1.1/rules/lib/builtins/path); default is `''`  path to the directory where the archive will be unpacked, relative to the repository directory. |
+| `strip_prefix` | [string](/versions/8.1.1/rules/lib/core/string); default is `''`  a directory prefix to strip from the extracted files. Many archives contain a top-level directory that contains all files in the archive. Instead of needing to specify this prefix over and over in the `build_file`, this field can be used to strip it from extracted files. For compatibility, this parameter may also be used under the deprecated name `stripPrefix`. |
+| `rename_files` | [dict](/versions/8.1.1/rules/lib/core/dict); default is `{}`  An optional dict specifying files to rename during the extraction. Archive entries with names exactly matching a key will be renamed to the value, prior to any directory prefix adjustment. This can be used to extract archives that contain non-Unicode filenames, or which have files that would extract to the same path on case-insensitive filesystems. |
+| `watch_archive` | [string](/versions/8.1.1/rules/lib/core/string); default is `'auto'`  whether to [watch](#watch) the archive file. Can be the string 'yes', 'no', or 'auto'. Passing 'yes' is equivalent to immediately invoking the [`watch()`](#watch) method; passing 'no' does not attempt to watch the file; passing 'auto' will only attempt to watch the file when it is legal to do so (see `watch()` docs for more information. |
 
 ## file
 
@@ -134,10 +134,10 @@ Generates a file in the repository directory with the provided content.
 
 | Parameter | Description |
 | --- | --- |
-| `path` | [string](../core/string); or [Label](../builtins/Label); or [path](../builtins/path); required  Path of the file to create, relative to the repository directory. |
-| `content` | [string](../core/string); default is `''`  The content of the file to create, empty by default. |
-| `executable` | [bool](../core/bool); default is `True`  Set the executable flag on the created file, true by default. |
-| `legacy_utf8` | [bool](../core/bool); default is `False`  No-op. This parameter is deprecated and will be removed in a future version of Bazel. |
+| `path` | [string](/versions/8.1.1/rules/lib/core/string); or [Label](/versions/8.1.1/rules/lib/builtins/Label); or [path](/versions/8.1.1/rules/lib/builtins/path); required  Path of the file to create, relative to the repository directory. |
+| `content` | [string](/versions/8.1.1/rules/lib/core/string); default is `''`  The content of the file to create, empty by default. |
+| `executable` | [bool](/versions/8.1.1/rules/lib/core/bool); default is `True`  Set the executable flag on the created file, true by default. |
+| `legacy_utf8` | [bool](/versions/8.1.1/rules/lib/core/bool); default is `False`  No-op. This parameter is deprecated and will be removed in a future version of Bazel. |
 
 ## getenv
 
@@ -153,8 +153,8 @@ When building incrementally, any change to the value of the variable named by `n
 
 | Parameter | Description |
 | --- | --- |
-| `name` | [string](../core/string); required  Name of desired environment variable. |
-| `default` | [string](../core/string); or `None`; default is `None`  Default value to return if `name` is not found. |
+| `name` | [string](/versions/8.1.1/rules/lib/core/string); required  Name of desired environment variable. |
+| `default` | [string](/versions/8.1.1/rules/lib/core/string); or `None`; default is `None`  Default value to return if `name` is not found. |
 
 May return `None`.
 
@@ -164,13 +164,13 @@ May return `None`.
 bool module_ctx.is_dev_dependency(tag)
 ```
 
-Returns whether the given tag was specified on the result of a [use\_extension](../globals/module#use_extension) call with `devDependency = True`.
+Returns whether the given tag was specified on the result of a [use\_extension](/versions/8.1.1/rules/lib/globals/module#use_extension) call with `devDependency = True`.
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `tag` | bazel\_module\_tag; required  A tag obtained from [bazel\_module.tags](../builtins/bazel_module#tags). |
+| `tag` | bazel\_module\_tag; required  A tag obtained from [bazel\_module.tags](/versions/8.1.1/rules/lib/builtins/bazel_module#tags). |
 
 ## modules
 
@@ -178,7 +178,7 @@ Returns whether the given tag was specified on the result of a [use\_extension](
 list module_ctx.modules
 ```
 
-A list of all the Bazel modules in the external dependency graph that use this module extension, each of which is a [bazel\_module](../builtins/bazel_module) object that exposes all the tags it specified for this extension. The iteration order of this dictionary is guaranteed to be the same as breadth-first search starting from the root module.
+A list of all the Bazel modules in the external dependency graph that use this module extension, each of which is a [bazel\_module](/versions/8.1.1/rules/lib/builtins/bazel_module) object that exposes all the tags it specified for this extension. The iteration order of this dictionary is guaranteed to be the same as breadth-first search starting from the root module.
 
 ## os
 
@@ -200,7 +200,7 @@ Returns a path from a string, label or path. If the path is relative, it will re
 
 | Parameter | Description |
 | --- | --- |
-| `path` | [string](../core/string); or [Label](../builtins/Label); or [path](../builtins/path); required  `string`, `Label` or `path` from which to create a path from. |
+| `path` | [string](/versions/8.1.1/rules/lib/core/string); or [Label](/versions/8.1.1/rules/lib/builtins/Label); or [path](/versions/8.1.1/rules/lib/builtins/path); required  `string`, `Label` or `path` from which to create a path from. |
 
 ## read
 
@@ -214,8 +214,8 @@ Reads the content of a file on the filesystem.
 
 | Parameter | Description |
 | --- | --- |
-| `path` | [string](../core/string); or [Label](../builtins/Label); or [path](../builtins/path); required  Path of the file to read from. |
-| `watch` | [string](../core/string); default is `'auto'`  Whether to [watch](#watch) the file. Can be the string 'yes', 'no', or 'auto'. Passing 'yes' is equivalent to immediately invoking the [`watch()`](#watch) method; passing 'no' does not attempt to watch the file; passing 'auto' will only attempt to watch the file when it is legal to do so (see `watch()` docs for more information. |
+| `path` | [string](/versions/8.1.1/rules/lib/core/string); or [Label](/versions/8.1.1/rules/lib/builtins/Label); or [path](/versions/8.1.1/rules/lib/builtins/path); required  Path of the file to read from. |
+| `watch` | [string](/versions/8.1.1/rules/lib/core/string); default is `'auto'`  Whether to [watch](#watch) the file. Can be the string 'yes', 'no', or 'auto'. Passing 'yes' is equivalent to immediately invoking the [`watch()`](#watch) method; passing 'no' does not attempt to watch the file; passing 'auto' will only attempt to watch the file when it is legal to do so (see `watch()` docs for more information. |
 
 ## report\_progress
 
@@ -229,7 +229,7 @@ Updates the progress status for the fetching of this repository or module extens
 
 | Parameter | Description |
 | --- | --- |
-| `status` | [string](../core/string); default is `''`  `string` describing the current status of the fetch progress. |
+| `status` | [string](/versions/8.1.1/rules/lib/core/string); default is `''`  `string` describing the current status of the fetch progress. |
 
 ## root\_module\_has\_non\_dev\_dependency
 
@@ -247,7 +247,7 @@ None module_ctx.watch(path)
 
 Tells Bazel to watch for changes to the given path, whether or not it exists, or whether it's a file or a directory. Any changes to the file or directory will invalidate this repository or module extension, and cause it to be refetched or re-evaluated next time.
 
-"Changes" include changes to the contents of the file (if the path is a file); if the path was a file but is now a directory, or vice versa; and if the path starts or stops existing. Notably, this does *not* include changes to any files under the directory if the path is a directory. For that, use [`path.readdir()`](path#readdir) instead.
+"Changes" include changes to the contents of the file (if the path is a file); if the path was a file but is now a directory, or vice versa; and if the path starts or stops existing. Notably, this does *not* include changes to any files under the directory if the path is a directory. For that, use [`path.readdir()`](/versions/8.1.1/rules/lib/builtins/path#readdir) instead.
 
 Note that attempting to watch paths inside the repo currently being fetched, or inside the working directory of the current module extension, will result in an error. A module extension attempting to watch a path outside the current Bazel workspace will also result in an error.
 
@@ -255,7 +255,7 @@ Note that attempting to watch paths inside the repo currently being fetched, or
 
 | Parameter | Description |
 | --- | --- |
-| `path` | [string](../core/string); or [Label](../builtins/Label); or [path](../builtins/path); required  Path of the file to watch. |
+| `path` | [string](/versions/8.1.1/rules/lib/core/string); or [Label](/versions/8.1.1/rules/lib/builtins/Label); or [path](/versions/8.1.1/rules/lib/builtins/path); required  Path of the file to watch. |
 
 ## which
 
@@ -269,6 +269,6 @@ Returns the `path` of the corresponding program or `None` if there is no such pr
 
 | Parameter | Description |
 | --- | --- |
-| `program` | [string](../core/string); required  Program to find in the path. |
+| `program` | [string](/versions/8.1.1/rules/lib/core/string); required  Program to find in the path. |
 
 May return `None`.
\ No newline at end of file
diff --git a/versions/8.1.1/rules/lib/builtins/path.mdx b/versions/8.1.1/rules/lib/builtins/path.mdx
index d200110e..af1a7cfc 100644
--- a/versions/8.1.1/rules/lib/builtins/path.mdx
+++ b/versions/8.1.1/rules/lib/builtins/path.mdx
@@ -77,7 +77,7 @@ Returns the list of entries in the directory denoted by this path. Each entry is
 
 | Parameter | Description |
 | --- | --- |
-| `watch` | [string](../core/string); default is `'auto'`  whether Bazel should watch the list of entries in this directory and refetch the repository or re-evaluate the module extension next time when any changes are detected. Changes to detect include entry creation, deletion, and renaming. Note that this doesn't watch the *contents* of any entries in the directory. Can be the string 'yes', 'no', or 'auto'. If set to 'auto', Bazel will only watch this directory when it is legal to do so (see [`repository_ctx.watch()`](repository_ctx#watch) docs for more information). |
+| `watch` | [string](/versions/8.1.1/rules/lib/core/string); default is `'auto'`  whether Bazel should watch the list of entries in this directory and refetch the repository or re-evaluate the module extension next time when any changes are detected. Changes to detect include entry creation, deletion, and renaming. Note that this doesn't watch the *contents* of any entries in the directory. Can be the string 'yes', 'no', or 'auto'. If set to 'auto', Bazel will only watch this directory when it is legal to do so (see [`repository_ctx.watch()`](/versions/8.1.1/rules/lib/builtins/repository_ctx#watch) docs for more information). |
 
 ## realpath
 
diff --git a/versions/8.1.1/rules/lib/builtins/repository_ctx.mdx b/versions/8.1.1/rules/lib/builtins/repository_ctx.mdx
index e474f267..65cd75f2 100644
--- a/versions/8.1.1/rules/lib/builtins/repository_ctx.mdx
+++ b/versions/8.1.1/rules/lib/builtins/repository_ctx.mdx
@@ -49,7 +49,7 @@ Deletes a file or a directory. Returns a bool, indicating whether the file or di
 
 | Parameter | Description |
 | --- | --- |
-| `path` | [string](../core/string); or [path](../builtins/path); required  Path of the file to delete, relative to the repository directory, or absolute. Can be a path or a string. |
+| `path` | [string](/versions/8.1.1/rules/lib/core/string); or [path](/versions/8.1.1/rules/lib/builtins/path); required  Path of the file to delete, relative to the repository directory, or absolute. Can be a path or a string. |
 
 ## download
 
@@ -63,16 +63,16 @@ Downloads a file to the output path for the provided url and returns a struct co
 
 | Parameter | Description |
 | --- | --- |
-| `url` | [string](../core/string); or Iterable of [string](../core/string)s; required  List of mirror URLs referencing the same file. |
-| `output` | [string](../core/string); or [Label](../builtins/Label); or [path](../builtins/path); default is `''`  path to the output file, relative to the repository directory. |
-| `sha256` | [string](../core/string); default is `''`  The expected SHA-256 hash of the file downloaded. This must match the SHA-256 hash of the file downloaded. It is a security risk to omit the SHA-256 as remote files can change. At best omitting this field will make your build non-hermetic. It is optional to make development easier but should be set before shipping. If provided, the repository cache will first be checked for a file with the given hash; a download will only be attempted if the file was not found in the cache. After a successful download, the file will be added to the cache. |
-| `executable` | [bool](../core/bool); default is `False`  Set the executable flag on the created file, false by default. |
-| `allow_fail` | [bool](../core/bool); default is `False`  If set, indicate the error in the return value instead of raising an error for failed downloads. |
-| `canonical_id` | [string](../core/string); default is `''`  If set, restrict cache hits to those cases where the file was added to the cache with the same canonical id. By default caching uses the checksum (`sha256` or `integrity`). |
-| `auth` | [dict](../core/dict); default is `{}`  An optional dict specifying authentication information for some of the URLs. |
-| `headers` | [dict](../core/dict); default is `{}`  An optional dict specifying http headers for all URLs. |
-| `integrity` | [string](../core/string); default is `''`  Expected checksum of the file downloaded, in Subresource Integrity format. This must match the checksum of the file downloaded. It is a security risk to omit the checksum as remote files can change. At best omitting this field will make your build non-hermetic. It is optional to make development easier but should be set before shipping. If provided, the repository cache will first be checked for a file with the given checksum; a download will only be attempted if the file was not found in the cache. After a successful download, the file will be added to the cache. |
-| `block` | [bool](../core/bool); default is `True`  If set to false, the call returns immediately and instead of the regular return value, it returns a token with one single method, wait(), which blocks until the download is finished and returns the usual return value or throws as usual. |
+| `url` | [string](/versions/8.1.1/rules/lib/core/string); or Iterable of [string](/versions/8.1.1/rules/lib/core/string)s; required  List of mirror URLs referencing the same file. |
+| `output` | [string](/versions/8.1.1/rules/lib/core/string); or [Label](/versions/8.1.1/rules/lib/builtins/Label); or [path](/versions/8.1.1/rules/lib/builtins/path); default is `''`  path to the output file, relative to the repository directory. |
+| `sha256` | [string](/versions/8.1.1/rules/lib/core/string); default is `''`  The expected SHA-256 hash of the file downloaded. This must match the SHA-256 hash of the file downloaded. It is a security risk to omit the SHA-256 as remote files can change. At best omitting this field will make your build non-hermetic. It is optional to make development easier but should be set before shipping. If provided, the repository cache will first be checked for a file with the given hash; a download will only be attempted if the file was not found in the cache. After a successful download, the file will be added to the cache. |
+| `executable` | [bool](/versions/8.1.1/rules/lib/core/bool); default is `False`  Set the executable flag on the created file, false by default. |
+| `allow_fail` | [bool](/versions/8.1.1/rules/lib/core/bool); default is `False`  If set, indicate the error in the return value instead of raising an error for failed downloads. |
+| `canonical_id` | [string](/versions/8.1.1/rules/lib/core/string); default is `''`  If set, restrict cache hits to those cases where the file was added to the cache with the same canonical id. By default caching uses the checksum (`sha256` or `integrity`). |
+| `auth` | [dict](/versions/8.1.1/rules/lib/core/dict); default is `{}`  An optional dict specifying authentication information for some of the URLs. |
+| `headers` | [dict](/versions/8.1.1/rules/lib/core/dict); default is `{}`  An optional dict specifying http headers for all URLs. |
+| `integrity` | [string](/versions/8.1.1/rules/lib/core/string); default is `''`  Expected checksum of the file downloaded, in Subresource Integrity format. This must match the checksum of the file downloaded. It is a security risk to omit the checksum as remote files can change. At best omitting this field will make your build non-hermetic. It is optional to make development easier but should be set before shipping. If provided, the repository cache will first be checked for a file with the given checksum; a download will only be attempted if the file was not found in the cache. After a successful download, the file will be added to the cache. |
+| `block` | [bool](/versions/8.1.1/rules/lib/core/bool); default is `True`  If set to false, the call returns immediately and instead of the regular return value, it returns a token with one single method, wait(), which blocks until the download is finished and returns the usual return value or throws as usual. |
 
 ## download\_and\_extract
 
@@ -86,17 +86,17 @@ Downloads a file to the output path for the provided url, extracts it, and retur
 
 | Parameter | Description |
 | --- | --- |
-| `url` | [string](../core/string); or Iterable of [string](../core/string)s; required  List of mirror URLs referencing the same file. |
-| `output` | [string](../core/string); or [Label](../builtins/Label); or [path](../builtins/path); default is `''`  Path to the directory where the archive will be unpacked, relative to the repository directory. |
-| `sha256` | [string](../core/string); default is `''`  The expected SHA-256 hash of the file downloaded. This must match the SHA-256 hash of the file downloaded. It is a security risk to omit the SHA-256 as remote files can change. At best omitting this field will make your build non-hermetic. It is optional to make development easier but should be set before shipping. If provided, the repository cache will first be checked for a file with the given hash; a download will only be attempted if the file was not found in the cache. After a successful download, the file will be added to the cache. |
-| `type` | [string](../core/string); default is `''`  The archive type of the downloaded file. By default, the archive type is determined from the file extension of the URL. If the file has no extension, you can explicitly specify either "zip", "jar", "war", "aar", "nupkg", "tar", "tar.gz", "tgz", "tar.xz", "txz", ".tar.zst", ".tzst", "tar.bz2", ".tbz", ".ar", or ".deb" here. |
-| `strip_prefix` | [string](../core/string); default is `''`  A directory prefix to strip from the extracted files. Many archives contain a top-level directory that contains all files in the archive. Instead of needing to specify this prefix over and over in the `build_file`, this field can be used to strip it from extracted files. For compatibility, this parameter may also be used under the deprecated name `stripPrefix`. |
-| `allow_fail` | [bool](../core/bool); default is `False`  If set, indicate the error in the return value instead of raising an error for failed downloads. |
-| `canonical_id` | [string](../core/string); default is `''`  If set, restrict cache hits to those cases where the file was added to the cache with the same canonical id. By default caching uses the checksum" (`sha256` or `integrity`). |
-| `auth` | [dict](../core/dict); default is `{}`  An optional dict specifying authentication information for some of the URLs. |
-| `headers` | [dict](../core/dict); default is `{}`  An optional dict specifying http headers for all URLs. |
-| `integrity` | [string](../core/string); default is `''`  Expected checksum of the file downloaded, in Subresource Integrity format. This must match the checksum of the file downloaded. It is a security risk to omit the checksum as remote files can change. At best omitting this field will make your build non-hermetic. It is optional to make development easier but should be set before shipping. If provided, the repository cache will first be checked for a file with the given checksum; a download will only be attempted if the file was not found in the cache. After a successful download, the file will be added to the cache. |
-| `rename_files` | [dict](../core/dict); default is `{}`  An optional dict specifying files to rename during the extraction. Archive entries with names exactly matching a key will be renamed to the value, prior to any directory prefix adjustment. This can be used to extract archives that contain non-Unicode filenames, or which have files that would extract to the same path on case-insensitive filesystems. |
+| `url` | [string](/versions/8.1.1/rules/lib/core/string); or Iterable of [string](/versions/8.1.1/rules/lib/core/string)s; required  List of mirror URLs referencing the same file. |
+| `output` | [string](/versions/8.1.1/rules/lib/core/string); or [Label](/versions/8.1.1/rules/lib/builtins/Label); or [path](/versions/8.1.1/rules/lib/builtins/path); default is `''`  Path to the directory where the archive will be unpacked, relative to the repository directory. |
+| `sha256` | [string](/versions/8.1.1/rules/lib/core/string); default is `''`  The expected SHA-256 hash of the file downloaded. This must match the SHA-256 hash of the file downloaded. It is a security risk to omit the SHA-256 as remote files can change. At best omitting this field will make your build non-hermetic. It is optional to make development easier but should be set before shipping. If provided, the repository cache will first be checked for a file with the given hash; a download will only be attempted if the file was not found in the cache. After a successful download, the file will be added to the cache. |
+| `type` | [string](/versions/8.1.1/rules/lib/core/string); default is `''`  The archive type of the downloaded file. By default, the archive type is determined from the file extension of the URL. If the file has no extension, you can explicitly specify either "zip", "jar", "war", "aar", "nupkg", "tar", "tar.gz", "tgz", "tar.xz", "txz", ".tar.zst", ".tzst", "tar.bz2", ".tbz", ".ar", or ".deb" here. |
+| `strip_prefix` | [string](/versions/8.1.1/rules/lib/core/string); default is `''`  A directory prefix to strip from the extracted files. Many archives contain a top-level directory that contains all files in the archive. Instead of needing to specify this prefix over and over in the `build_file`, this field can be used to strip it from extracted files. For compatibility, this parameter may also be used under the deprecated name `stripPrefix`. |
+| `allow_fail` | [bool](/versions/8.1.1/rules/lib/core/bool); default is `False`  If set, indicate the error in the return value instead of raising an error for failed downloads. |
+| `canonical_id` | [string](/versions/8.1.1/rules/lib/core/string); default is `''`  If set, restrict cache hits to those cases where the file was added to the cache with the same canonical id. By default caching uses the checksum" (`sha256` or `integrity`). |
+| `auth` | [dict](/versions/8.1.1/rules/lib/core/dict); default is `{}`  An optional dict specifying authentication information for some of the URLs. |
+| `headers` | [dict](/versions/8.1.1/rules/lib/core/dict); default is `{}`  An optional dict specifying http headers for all URLs. |
+| `integrity` | [string](/versions/8.1.1/rules/lib/core/string); default is `''`  Expected checksum of the file downloaded, in Subresource Integrity format. This must match the checksum of the file downloaded. It is a security risk to omit the checksum as remote files can change. At best omitting this field will make your build non-hermetic. It is optional to make development easier but should be set before shipping. If provided, the repository cache will first be checked for a file with the given checksum; a download will only be attempted if the file was not found in the cache. After a successful download, the file will be added to the cache. |
+| `rename_files` | [dict](/versions/8.1.1/rules/lib/core/dict); default is `{}`  An optional dict specifying files to rename during the extraction. Archive entries with names exactly matching a key will be renamed to the value, prior to any directory prefix adjustment. This can be used to extract archives that contain non-Unicode filenames, or which have files that would extract to the same path on case-insensitive filesystems. |
 
 ## execute
 
@@ -110,11 +110,11 @@ Executes the command given by the list of arguments. The execution time of the c
 
 | Parameter | Description |
 | --- | --- |
-| `arguments` | [sequence](../core/list); required  List of arguments, the first element should be the path to the program to execute. |
-| `timeout` | [int](../core/int); default is `600`  Maximum duration of the command in seconds (default is 600 seconds). |
-| `environment` | [dict](../core/dict); default is `{}`  Force some environment variables to be set to be passed to the process. The value can be `None` to remove the environment variable. |
-| `quiet` | [bool](../core/bool); default is `True`  If stdout and stderr should be printed to the terminal. |
-| `working_directory` | [string](../core/string); default is `""`  Working directory for command execution. Can be relative to the repository root or absolute. The default is the repository root. |
+| `arguments` | [sequence](/versions/8.1.1/rules/lib/core/list); required  List of arguments, the first element should be the path to the program to execute. |
+| `timeout` | [int](/versions/8.1.1/rules/lib/core/int); default is `600`  Maximum duration of the command in seconds (default is 600 seconds). |
+| `environment` | [dict](/versions/8.1.1/rules/lib/core/dict); default is `{}`  Force some environment variables to be set to be passed to the process. The value can be `None` to remove the environment variable. |
+| `quiet` | [bool](/versions/8.1.1/rules/lib/core/bool); default is `True`  If stdout and stderr should be printed to the terminal. |
+| `working_directory` | [string](/versions/8.1.1/rules/lib/core/string); default is `""`  Working directory for command execution. Can be relative to the repository root or absolute. The default is the repository root. |
 
 ## extract
 
@@ -128,11 +128,11 @@ Extract an archive to the repository directory.
 
 | Parameter | Description |
 | --- | --- |
-| `archive` | [string](../core/string); or [Label](../builtins/Label); or [path](../builtins/path); required  path to the archive that will be unpacked, relative to the repository directory. |
-| `output` | [string](../core/string); or [Label](../builtins/Label); or [path](../builtins/path); default is `''`  path to the directory where the archive will be unpacked, relative to the repository directory. |
-| `strip_prefix` | [string](../core/string); default is `''`  a directory prefix to strip from the extracted files. Many archives contain a top-level directory that contains all files in the archive. Instead of needing to specify this prefix over and over in the `build_file`, this field can be used to strip it from extracted files. For compatibility, this parameter may also be used under the deprecated name `stripPrefix`. |
-| `rename_files` | [dict](../core/dict); default is `{}`  An optional dict specifying files to rename during the extraction. Archive entries with names exactly matching a key will be renamed to the value, prior to any directory prefix adjustment. This can be used to extract archives that contain non-Unicode filenames, or which have files that would extract to the same path on case-insensitive filesystems. |
-| `watch_archive` | [string](../core/string); default is `'auto'`  whether to [watch](#watch) the archive file. Can be the string 'yes', 'no', or 'auto'. Passing 'yes' is equivalent to immediately invoking the [`watch()`](#watch) method; passing 'no' does not attempt to watch the file; passing 'auto' will only attempt to watch the file when it is legal to do so (see `watch()` docs for more information. |
+| `archive` | [string](/versions/8.1.1/rules/lib/core/string); or [Label](/versions/8.1.1/rules/lib/builtins/Label); or [path](/versions/8.1.1/rules/lib/builtins/path); required  path to the archive that will be unpacked, relative to the repository directory. |
+| `output` | [string](/versions/8.1.1/rules/lib/core/string); or [Label](/versions/8.1.1/rules/lib/builtins/Label); or [path](/versions/8.1.1/rules/lib/builtins/path); default is `''`  path to the directory where the archive will be unpacked, relative to the repository directory. |
+| `strip_prefix` | [string](/versions/8.1.1/rules/lib/core/string); default is `''`  a directory prefix to strip from the extracted files. Many archives contain a top-level directory that contains all files in the archive. Instead of needing to specify this prefix over and over in the `build_file`, this field can be used to strip it from extracted files. For compatibility, this parameter may also be used under the deprecated name `stripPrefix`. |
+| `rename_files` | [dict](/versions/8.1.1/rules/lib/core/dict); default is `{}`  An optional dict specifying files to rename during the extraction. Archive entries with names exactly matching a key will be renamed to the value, prior to any directory prefix adjustment. This can be used to extract archives that contain non-Unicode filenames, or which have files that would extract to the same path on case-insensitive filesystems. |
+| `watch_archive` | [string](/versions/8.1.1/rules/lib/core/string); default is `'auto'`  whether to [watch](#watch) the archive file. Can be the string 'yes', 'no', or 'auto'. Passing 'yes' is equivalent to immediately invoking the [`watch()`](#watch) method; passing 'no' does not attempt to watch the file; passing 'auto' will only attempt to watch the file when it is legal to do so (see `watch()` docs for more information. |
 
 ## file
 
@@ -146,10 +146,10 @@ Generates a file in the repository directory with the provided content.
 
 | Parameter | Description |
 | --- | --- |
-| `path` | [string](../core/string); or [Label](../builtins/Label); or [path](../builtins/path); required  Path of the file to create, relative to the repository directory. |
-| `content` | [string](../core/string); default is `''`  The content of the file to create, empty by default. |
-| `executable` | [bool](../core/bool); default is `True`  Set the executable flag on the created file, true by default. |
-| `legacy_utf8` | [bool](../core/bool); default is `False`  No-op. This parameter is deprecated and will be removed in a future version of Bazel. |
+| `path` | [string](/versions/8.1.1/rules/lib/core/string); or [Label](/versions/8.1.1/rules/lib/builtins/Label); or [path](/versions/8.1.1/rules/lib/builtins/path); required  Path of the file to create, relative to the repository directory. |
+| `content` | [string](/versions/8.1.1/rules/lib/core/string); default is `''`  The content of the file to create, empty by default. |
+| `executable` | [bool](/versions/8.1.1/rules/lib/core/bool); default is `True`  Set the executable flag on the created file, true by default. |
+| `legacy_utf8` | [bool](/versions/8.1.1/rules/lib/core/bool); default is `False`  No-op. This parameter is deprecated and will be removed in a future version of Bazel. |
 
 ## getenv
 
@@ -165,8 +165,8 @@ When building incrementally, any change to the value of the variable named by `n
 
 | Parameter | Description |
 | --- | --- |
-| `name` | [string](../core/string); required  Name of desired environment variable. |
-| `default` | [string](../core/string); or `None`; default is `None`  Default value to return if `name` is not found. |
+| `name` | [string](/versions/8.1.1/rules/lib/core/string); required  Name of desired environment variable. |
+| `default` | [string](/versions/8.1.1/rules/lib/core/string); or `None`; default is `None`  Default value to return if `name` is not found. |
 
 May return `None`.
 
@@ -206,9 +206,9 @@ Apply a patch file to the root directory of external repository. The patch file
 
 | Parameter | Description |
 | --- | --- |
-| `patch_file` | [string](../core/string); or [Label](../builtins/Label); or [path](../builtins/path); required  The patch file to apply, it can be label, relative path or absolute path. If it's a relative path, it will resolve to the repository directory. |
-| `strip` | [int](../core/int); default is `0`  Strip the specified number of leading components from file names. |
-| `watch_patch` | [string](../core/string); default is `'auto'`  Whether to [watch](#watch) the patch file. Can be the string 'yes', 'no', or 'auto'. Passing 'yes' is equivalent to immediately invoking the [`watch()`](#watch) method; passing 'no' does not attempt to watch the file; passing 'auto' will only attempt to watch the file when it is legal to do so (see `watch()` docs for more information. |
+| `patch_file` | [string](/versions/8.1.1/rules/lib/core/string); or [Label](/versions/8.1.1/rules/lib/builtins/Label); or [path](/versions/8.1.1/rules/lib/builtins/path); required  The patch file to apply, it can be label, relative path or absolute path. If it's a relative path, it will resolve to the repository directory. |
+| `strip` | [int](/versions/8.1.1/rules/lib/core/int); default is `0`  Strip the specified number of leading components from file names. |
+| `watch_patch` | [string](/versions/8.1.1/rules/lib/core/string); default is `'auto'`  Whether to [watch](#watch) the patch file. Can be the string 'yes', 'no', or 'auto'. Passing 'yes' is equivalent to immediately invoking the [`watch()`](#watch) method; passing 'no' does not attempt to watch the file; passing 'auto' will only attempt to watch the file when it is legal to do so (see `watch()` docs for more information. |
 
 ## path
 
@@ -222,7 +222,7 @@ Returns a path from a string, label or path. If the path is relative, it will re
 
 | Parameter | Description |
 | --- | --- |
-| `path` | [string](../core/string); or [Label](../builtins/Label); or [path](../builtins/path); required  `string`, `Label` or `path` from which to create a path from. |
+| `path` | [string](/versions/8.1.1/rules/lib/core/string); or [Label](/versions/8.1.1/rules/lib/builtins/Label); or [path](/versions/8.1.1/rules/lib/builtins/path); required  `string`, `Label` or `path` from which to create a path from. |
 
 ## read
 
@@ -236,8 +236,8 @@ Reads the content of a file on the filesystem.
 
 | Parameter | Description |
 | --- | --- |
-| `path` | [string](../core/string); or [Label](../builtins/Label); or [path](../builtins/path); required  Path of the file to read from. |
-| `watch` | [string](../core/string); default is `'auto'`  Whether to [watch](#watch) the file. Can be the string 'yes', 'no', or 'auto'. Passing 'yes' is equivalent to immediately invoking the [`watch()`](#watch) method; passing 'no' does not attempt to watch the file; passing 'auto' will only attempt to watch the file when it is legal to do so (see `watch()` docs for more information. |
+| `path` | [string](/versions/8.1.1/rules/lib/core/string); or [Label](/versions/8.1.1/rules/lib/builtins/Label); or [path](/versions/8.1.1/rules/lib/builtins/path); required  Path of the file to read from. |
+| `watch` | [string](/versions/8.1.1/rules/lib/core/string); default is `'auto'`  Whether to [watch](#watch) the file. Can be the string 'yes', 'no', or 'auto'. Passing 'yes' is equivalent to immediately invoking the [`watch()`](#watch) method; passing 'no' does not attempt to watch the file; passing 'auto' will only attempt to watch the file when it is legal to do so (see `watch()` docs for more information. |
 
 ## rename
 
@@ -252,8 +252,8 @@ already exists. Both paths must be located within the repository.
 
 | Parameter | Description |
 | --- | --- |
-| `src` | [string](../core/string); or [Label](../builtins/Label); or [path](../builtins/path); required  The path of the existing file or directory to rename, relative to the repository directory. |
-| `dst` | [string](../core/string); or [Label](../builtins/Label); or [path](../builtins/path); required  The new name to which the file or directory will be renamed to, relative to the repository directory. |
+| `src` | [string](/versions/8.1.1/rules/lib/core/string); or [Label](/versions/8.1.1/rules/lib/builtins/Label); or [path](/versions/8.1.1/rules/lib/builtins/path); required  The path of the existing file or directory to rename, relative to the repository directory. |
+| `dst` | [string](/versions/8.1.1/rules/lib/core/string); or [Label](/versions/8.1.1/rules/lib/builtins/Label); or [path](/versions/8.1.1/rules/lib/builtins/path); required  The new name to which the file or directory will be renamed to, relative to the repository directory. |
 
 ## report\_progress
 
@@ -267,7 +267,7 @@ Updates the progress status for the fetching of this repository or module extens
 
 | Parameter | Description |
 | --- | --- |
-| `status` | [string](../core/string); default is `''`  `string` describing the current status of the fetch progress. |
+| `status` | [string](/versions/8.1.1/rules/lib/core/string); default is `''`  `string` describing the current status of the fetch progress. |
 
 ## symlink
 
@@ -281,8 +281,8 @@ Creates a symlink on the filesystem.
 
 | Parameter | Description |
 | --- | --- |
-| `target` | [string](../core/string); or [Label](../builtins/Label); or [path](../builtins/path); required  The path that the symlink should point to. |
-| `link_name` | [string](../core/string); or [Label](../builtins/Label); or [path](../builtins/path); required  The path of the symlink to create. |
+| `target` | [string](/versions/8.1.1/rules/lib/core/string); or [Label](/versions/8.1.1/rules/lib/builtins/Label); or [path](/versions/8.1.1/rules/lib/builtins/path); required  The path that the symlink should point to. |
+| `link_name` | [string](/versions/8.1.1/rules/lib/core/string); or [Label](/versions/8.1.1/rules/lib/builtins/Label); or [path](/versions/8.1.1/rules/lib/builtins/path); required  The path of the symlink to create. |
 
 ## template
 
@@ -296,11 +296,11 @@ Generates a new file using a `template`. Every occurrence in `template` of a key
 
 | Parameter | Description |
 | --- | --- |
-| `path` | [string](../core/string); or [Label](../builtins/Label); or [path](../builtins/path); required  Path of the file to create, relative to the repository directory. |
-| `template` | [string](../core/string); or [Label](../builtins/Label); or [path](../builtins/path); required  Path to the template file. |
-| `substitutions` | [dict](../core/dict); default is `{}`  Substitutions to make when expanding the template. |
-| `executable` | [bool](../core/bool); default is `True`  Set the executable flag on the created file, true by default. |
-| `watch_template` | [string](../core/string); default is `'auto'`  Whether to [watch](#watch) the template file. Can be the string 'yes', 'no', or 'auto'. Passing 'yes' is equivalent to immediately invoking the [`watch()`](#watch) method; passing 'no' does not attempt to watch the file; passing 'auto' will only attempt to watch the file when it is legal to do so (see `watch()` docs for more information. |
+| `path` | [string](/versions/8.1.1/rules/lib/core/string); or [Label](/versions/8.1.1/rules/lib/builtins/Label); or [path](/versions/8.1.1/rules/lib/builtins/path); required  Path of the file to create, relative to the repository directory. |
+| `template` | [string](/versions/8.1.1/rules/lib/core/string); or [Label](/versions/8.1.1/rules/lib/builtins/Label); or [path](/versions/8.1.1/rules/lib/builtins/path); required  Path to the template file. |
+| `substitutions` | [dict](/versions/8.1.1/rules/lib/core/dict); default is `{}`  Substitutions to make when expanding the template. |
+| `executable` | [bool](/versions/8.1.1/rules/lib/core/bool); default is `True`  Set the executable flag on the created file, true by default. |
+| `watch_template` | [string](/versions/8.1.1/rules/lib/core/string); default is `'auto'`  Whether to [watch](#watch) the template file. Can be the string 'yes', 'no', or 'auto'. Passing 'yes' is equivalent to immediately invoking the [`watch()`](#watch) method; passing 'no' does not attempt to watch the file; passing 'auto' will only attempt to watch the file when it is legal to do so (see `watch()` docs for more information. |
 
 ## watch
 
@@ -310,7 +310,7 @@ None repository_ctx.watch(path)
 
 Tells Bazel to watch for changes to the given path, whether or not it exists, or whether it's a file or a directory. Any changes to the file or directory will invalidate this repository or module extension, and cause it to be refetched or re-evaluated next time.
 
-"Changes" include changes to the contents of the file (if the path is a file); if the path was a file but is now a directory, or vice versa; and if the path starts or stops existing. Notably, this does *not* include changes to any files under the directory if the path is a directory. For that, use [`path.readdir()`](path#readdir) instead.
+"Changes" include changes to the contents of the file (if the path is a file); if the path was a file but is now a directory, or vice versa; and if the path starts or stops existing. Notably, this does *not* include changes to any files under the directory if the path is a directory. For that, use [`path.readdir()`](/versions/8.1.1/rules/lib/builtins/path#readdir) instead.
 
 Note that attempting to watch paths inside the repo currently being fetched, or inside the working directory of the current module extension, will result in an error. A module extension attempting to watch a path outside the current Bazel workspace will also result in an error.
 
@@ -318,7 +318,7 @@ Note that attempting to watch paths inside the repo currently being fetched, or
 
 | Parameter | Description |
 | --- | --- |
-| `path` | [string](../core/string); or [Label](../builtins/Label); or [path](../builtins/path); required  Path of the file to watch. |
+| `path` | [string](/versions/8.1.1/rules/lib/core/string); or [Label](/versions/8.1.1/rules/lib/builtins/Label); or [path](/versions/8.1.1/rules/lib/builtins/path); required  Path of the file to watch. |
 
 ## watch\_tree
 
@@ -334,7 +334,7 @@ Note that attempting to watch paths inside the repo currently being fetched will
 
 | Parameter | Description |
 | --- | --- |
-| `path` | [string](../core/string); or [Label](../builtins/Label); or [path](../builtins/path); required  Path of the directory tree to watch. |
+| `path` | [string](/versions/8.1.1/rules/lib/core/string); or [Label](/versions/8.1.1/rules/lib/builtins/Label); or [path](/versions/8.1.1/rules/lib/builtins/path); required  Path of the directory tree to watch. |
 
 ## which
 
@@ -348,7 +348,7 @@ Returns the `path` of the corresponding program or `None` if there is no such pr
 
 | Parameter | Description |
 | --- | --- |
-| `program` | [string](../core/string); required  Program to find in the path. |
+| `program` | [string](/versions/8.1.1/rules/lib/core/string); required  Program to find in the path. |
 
 May return `None`.
 
diff --git a/versions/8.1.1/rules/lib/builtins/repository_rule.mdx b/versions/8.1.1/rules/lib/builtins/repository_rule.mdx
index ef5dac59..2276b7a0 100644
--- a/versions/8.1.1/rules/lib/builtins/repository_rule.mdx
+++ b/versions/8.1.1/rules/lib/builtins/repository_rule.mdx
@@ -2,4 +2,4 @@
 title: 'repository\_rule'
 ---
 
-A callable value that may be invoked during evaluation of the WORKSPACE file or within the implementation function of a module extension to instantiate and return a repository rule. Created by [`repository_rule()`](../globals/bzl#repository_rule).
\ No newline at end of file
+A callable value that may be invoked during evaluation of the WORKSPACE file or within the implementation function of a module extension to instantiate and return a repository rule. Created by [`repository_rule()`](/versions/8.1.1/rules/lib/globals/bzl#repository_rule).
\ No newline at end of file
diff --git a/versions/8.1.1/rules/lib/builtins/rule.mdx b/versions/8.1.1/rules/lib/builtins/rule.mdx
index 3981bec0..263e2b8a 100644
--- a/versions/8.1.1/rules/lib/builtins/rule.mdx
+++ b/versions/8.1.1/rules/lib/builtins/rule.mdx
@@ -3,7 +3,7 @@ title: 'rule'
 ---
 
 A callable value representing the type of a native or Starlark rule (created by
-[`rule()`](../globals/bzl#rule)). Calling the value during
+[`rule()`](/versions/8.1.1/rules/lib/globals/bzl#rule)). Calling the value during
 evaluation of a package's BUILD file creates an instance of the rule and adds it to the
 package's target set. For more information, visit this page about
 [Rules](https://bazel.build/versions/8.1.1/extending/rules).
\ No newline at end of file
diff --git a/versions/8.1.1/rules/lib/builtins/rule_attributes.mdx b/versions/8.1.1/rules/lib/builtins/rule_attributes.mdx
index aa1cb7b7..f8970b6f 100644
--- a/versions/8.1.1/rules/lib/builtins/rule_attributes.mdx
+++ b/versions/8.1.1/rules/lib/builtins/rule_attributes.mdx
@@ -20,7 +20,7 @@ Information about attributes of a rule an aspect is applied to.
 struct rule_attributes.attr
 ```
 
-A struct to access the values of the [attributes](https://bazel.build/versions/8.1.1/extending/rules#attributes). The values are provided by the user (if not, a default value is used). The attributes of the struct and the types of their values correspond to the keys and values of the [`attrs` dict](../globals/bzl#rule.attrs) provided to the [`rule` function](../globals/bzl#rule). [See example of use](https://github.com/bazelbuild/examples/blob/main/rules/attributes/printer.bzl).
+A struct to access the values of the [attributes](https://bazel.build/versions/8.1.1/extending/rules#attributes). The values are provided by the user (if not, a default value is used). The attributes of the struct and the types of their values correspond to the keys and values of the [`attrs` dict](/versions/8.1.1/rules/lib/globals/bzl#rule.attrs) provided to the [`rule` function](/versions/8.1.1/rules/lib/globals/bzl#rule). [See example of use](https://github.com/bazelbuild/examples/blob/main/rules/attributes/printer.bzl).
 
 ## exec\_groups
 
@@ -36,7 +36,7 @@ A collection of the execution groups available for the rule the aspect is applie
 struct rule_attributes.executable
 ```
 
-A `struct` containing executable files defined in [label type attributes](../toplevel/attr#label) marked as [`executable=True`](../toplevel/attr#label.executable). The struct fields correspond to the attribute names. Each value in the struct is either a [`File`](../builtins/File) or `None`. If an optional attribute is not specified in the rule then the corresponding struct value is `None`. If a label type is not marked as `executable=True`, no corresponding struct field is generated. [See example of use](https://github.com/bazelbuild/examples/blob/main/rules/actions_run/execute.bzl).
+A `struct` containing executable files defined in [label type attributes](/versions/8.1.1/rules/lib/toplevel/attr#label) marked as [`executable=True`](/versions/8.1.1/rules/lib/toplevel/attr#label.executable). The struct fields correspond to the attribute names. Each value in the struct is either a [`File`](/versions/8.1.1/rules/lib/builtins/File) or `None`. If an optional attribute is not specified in the rule then the corresponding struct value is `None`. If a label type is not marked as `executable=True`, no corresponding struct field is generated. [See example of use](https://github.com/bazelbuild/examples/blob/main/rules/actions_run/execute.bzl).
 
 ## file
 
@@ -44,7 +44,7 @@ A `struct` containing executable files defined in [label type attributes](../top
 struct rule_attributes.file
 ```
 
-A `struct` containing files defined in [label type attributes](../toplevel/attr#label) marked as [`allow_single_file`](../toplevel/attr#label.allow_single_file). The struct fields correspond to the attribute names. The struct value is always a [`File`](../builtins/File) or `None`. If an optional attribute is not specified in the rule then the corresponding struct value is `None`. If a label type is not marked as `allow_single_file`, no corresponding struct field is generated. It is a shortcut for:
+A `struct` containing files defined in [label type attributes](/versions/8.1.1/rules/lib/toplevel/attr#label) marked as [`allow_single_file`](/versions/8.1.1/rules/lib/toplevel/attr#label.allow_single_file). The struct fields correspond to the attribute names. The struct value is always a [`File`](/versions/8.1.1/rules/lib/builtins/File) or `None`. If an optional attribute is not specified in the rule then the corresponding struct value is `None`. If a label type is not marked as `allow_single_file`, no corresponding struct field is generated. It is a shortcut for:
 
 ```
 list(ctx.attr..files)[0]
@@ -58,7 +58,7 @@ In other words, use `file` to access the (singular) [default output](https://baz
 struct rule_attributes.files
 ```
 
-A `struct` containing files defined in [label](../toplevel/attr#label) or [label list](../toplevel/attr#label_list) type attributes. The struct fields correspond to the attribute names. The struct values are `list` of [`File`](../builtins/File)s. It is a shortcut for:
+A `struct` containing files defined in [label](/versions/8.1.1/rules/lib/toplevel/attr#label) or [label list](/versions/8.1.1/rules/lib/toplevel/attr#label_list) type attributes. The struct fields correspond to the attribute names. The struct values are `list` of [`File`](/versions/8.1.1/rules/lib/builtins/File)s. It is a shortcut for:
 
 ```
 [f for t in ctx.attr. for f in t.files]
diff --git a/versions/8.1.1/rules/lib/builtins/runfiles.mdx b/versions/8.1.1/rules/lib/builtins/runfiles.mdx
index 0b916efb..d50a3e6c 100644
--- a/versions/8.1.1/rules/lib/builtins/runfiles.mdx
+++ b/versions/8.1.1/rules/lib/builtins/runfiles.mdx
@@ -2,7 +2,7 @@
 title: 'runfiles'
 ---
 
-A container of information regarding a set of files required at runtime execution. This object should be passed via [DefaultInfo](../providers/DefaultInfo) in order to tell the build system about the runfiles needed by the outputs produced by the rule.
+A container of information regarding a set of files required at runtime execution. This object should be passed via [DefaultInfo](/versions/8.1.1/rules/lib/providers/DefaultInfo) in order to tell the build system about the runfiles needed by the outputs produced by the rule.
 
 See [runfiles guide](https://bazel.build/versions/8.1.1/extending/rules#runfiles) for details.
 
@@ -45,7 +45,7 @@ Returns a new runfiles object that includes all the contents of this one and the
 
 | Parameter | Description |
 | --- | --- |
-| `other` | [runfiles](../builtins/runfiles); required  The runfiles object to merge into this. |
+| `other` | [runfiles](/versions/8.1.1/rules/lib/builtins/runfiles); required  The runfiles object to merge into this. |
 
 ## merge\_all
 
@@ -59,7 +59,7 @@ Returns a new runfiles object that includes all the contents of this one and of
 
 | Parameter | Description |
 | --- | --- |
-| `other` | [sequence](../core/list) of [runfiles](../builtins/runfiles)s; required  The sequence of runfiles objects to merge into this. |
+| `other` | [sequence](/versions/8.1.1/rules/lib/core/list) of [runfiles](/versions/8.1.1/rules/lib/builtins/runfiles)s; required  The sequence of runfiles objects to merge into this. |
 
 ## root\_symlinks
 
diff --git a/versions/8.1.1/rules/lib/builtins/tag_class.mdx b/versions/8.1.1/rules/lib/builtins/tag_class.mdx
index 7d4349d0..d19d12f0 100644
--- a/versions/8.1.1/rules/lib/builtins/tag_class.mdx
+++ b/versions/8.1.1/rules/lib/builtins/tag_class.mdx
@@ -2,4 +2,4 @@
 title: 'tag\_class'
 ---
 
-Defines a schema of attributes for a tag, created by [`tag_class()`](../globals/bzl#tag_class).
\ No newline at end of file
+Defines a schema of attributes for a tag, created by [`tag_class()`](/versions/8.1.1/rules/lib/globals/bzl#tag_class).
\ No newline at end of file
diff --git a/versions/8.1.1/rules/lib/builtins/transition.mdx b/versions/8.1.1/rules/lib/builtins/transition.mdx
index f60879dd..ff706c1c 100644
--- a/versions/8.1.1/rules/lib/builtins/transition.mdx
+++ b/versions/8.1.1/rules/lib/builtins/transition.mdx
@@ -39,5 +39,5 @@ For more details see [here](https://bazel.build/versions/8.1.1/rules/config#user
 | Parameter | Description |
 | --- | --- |
 | `implementation` | callable; required  The function implementing this transition. This function always has two parameters: `settings` and `attr`. The `settings` param is a dictionary whose set of keys is defined by the inputs parameter. So, for each build setting `--//foo=bar`, if `inputs` contains `//foo`, `settings` will have an entry `settings['//foo']='bar'`. The `attr` param is a reference to `ctx.attr`. This gives the implementation function access to the rule's attributes to make attribute-parameterized transitions possible. This function must return a `dict` from build setting identifier to build setting value; this represents the configuration transition: for each entry in the returned `dict`, the transition updates that setting to the new value. All other settings are unchanged. This function can also return a `list` of `dict`s or a `dict` of `dict`s in the case of a split transition. |
-| `inputs` | [sequence](../core/list) of [string](../core/string)s; required  List of build settings that can be read by this transition. This becomes the key set of the settings parameter of the implementation function parameter. |
-| `outputs` | [sequence](../core/list) of [string](../core/string)s; required  List of build settings that can be written by this transition. This must be a superset of the key set of the dictionary returned by this transition. |
\ No newline at end of file
+| `inputs` | [sequence](/versions/8.1.1/rules/lib/core/list) of [string](/versions/8.1.1/rules/lib/core/string)s; required  List of build settings that can be read by this transition. This becomes the key set of the settings parameter of the implementation function parameter. |
+| `outputs` | [sequence](/versions/8.1.1/rules/lib/core/list) of [string](/versions/8.1.1/rules/lib/core/string)s; required  List of build settings that can be written by this transition. This must be a superset of the key set of the dictionary returned by this transition. |
\ No newline at end of file
diff --git a/versions/8.1.1/rules/lib/core/bool.mdx b/versions/8.1.1/rules/lib/core/bool.mdx
index 52be3664..bf946018 100644
--- a/versions/8.1.1/rules/lib/core/bool.mdx
+++ b/versions/8.1.1/rules/lib/core/bool.mdx
@@ -2,4 +2,4 @@
 title: 'bool'
 ---
 
-A type to represent booleans. There are only two possible values: True and False. Any value can be converted to a boolean using the [bool](../globals/all#bool) function.
\ No newline at end of file
+A type to represent booleans. There are only two possible values: True and False. Any value can be converted to a boolean using the [bool](/versions/8.1.1/rules/lib/globals/all#bool) function.
\ No newline at end of file
diff --git a/versions/8.1.1/rules/lib/core/dict.mdx b/versions/8.1.1/rules/lib/core/dict.mdx
index 9005668c..3e874b3f 100644
--- a/versions/8.1.1/rules/lib/core/dict.mdx
+++ b/versions/8.1.1/rules/lib/core/dict.mdx
@@ -22,7 +22,7 @@ There are four ways to construct a dictionary:
      {i: 2*i for i in range(3)}  # {0: 0, 1: 2, 2: 4}
      ```
 
-     - A call to the built-in [dict](../globals/all#dict) function returns a dictionary containing the specified entries, which are inserted in argument order, positional arguments before named. As with comprehensions, duplicate keys are permitted.- The union expression `x | y` yields a new dictionary by combining two existing dictionaries. If the two dictionaries have a key `k` in common, the right hand side dictionary's value of the key (in other words, `y[k]`) wins. The `|=` variant of the union operator modifies a dictionary in-place. Example:
+     - A call to the built-in [dict](/versions/8.1.1/rules/lib/globals/all#dict) function returns a dictionary containing the specified entries, which are inserted in argument order, positional arguments before named. As with comprehensions, duplicate keys are permitted.- The union expression `x | y` yields a new dictionary by combining two existing dictionaries. If the two dictionaries have a key `k` in common, the right hand side dictionary's value of the key (in other words, `y[k]`) wins. The `|=` variant of the union operator modifies a dictionary in-place. Example:
 
          ```
          d = {"foo": "FOO", "bar": "BAR"} | {"foo": "FOO2", "baz": "BAZ"}
diff --git a/versions/8.1.1/rules/lib/core/json.mdx b/versions/8.1.1/rules/lib/core/json.mdx
index 0bb00e3e..3c64fbbe 100644
--- a/versions/8.1.1/rules/lib/core/json.mdx
+++ b/versions/8.1.1/rules/lib/core/json.mdx
@@ -29,7 +29,7 @@ If `x` is not a valid JSON encoding and the optional `default` parameter is *not
 
 | Parameter | Description |
 | --- | --- |
-| `x` | [string](../core/string); required  JSON string to decode. |
+| `x` | [string](/versions/8.1.1/rules/lib/core/string); required  JSON string to decode. |
 | `default` | default is `unbound`  If specified, the value to return when `x` cannot be decoded. |
 
 ## encode
@@ -64,8 +64,8 @@ The encode\_indent function is equivalent to `json.indent(json.encode(x), ...)`.
 | Parameter | Description |
 | --- | --- |
 | `x` | required |
-| `prefix` | [string](../core/string); default is `''` |
-| `indent` | [string](../core/string); default is `'\t'` |
+| `prefix` | [string](/versions/8.1.1/rules/lib/core/string); default is `''` |
+| `indent` | [string](/versions/8.1.1/rules/lib/core/string); default is `'\t'` |
 
 ## indent
 
@@ -84,6 +84,6 @@ If the input is not valid, the function may fail or return invalid output.
 
 | Parameter | Description |
 | --- | --- |
-| `s` | [string](../core/string); required |
-| `prefix` | [string](../core/string); default is `''` |
-| `indent` | [string](../core/string); default is `'\t'` |
\ No newline at end of file
+| `s` | [string](/versions/8.1.1/rules/lib/core/string); required |
+| `prefix` | [string](/versions/8.1.1/rules/lib/core/string); default is `''` |
+| `indent` | [string](/versions/8.1.1/rules/lib/core/string); default is `'\t'` |
\ No newline at end of file
diff --git a/versions/8.1.1/rules/lib/core/list.mdx b/versions/8.1.1/rules/lib/core/list.mdx
index c19e9780..70ca3804 100644
--- a/versions/8.1.1/rules/lib/core/list.mdx
+++ b/versions/8.1.1/rules/lib/core/list.mdx
@@ -91,8 +91,8 @@ Returns the index in the list of the first item whose value is x. It is an error
 | Parameter | Description |
 | --- | --- |
 | `x` | required |
-| `start` | [int](../core/int); or `None`; default is `None`  The start index of the list portion to inspect. |
-| `end` | [int](../core/int); or `None`; default is `None`  The end index of the list portion to inspect. |
+| `start` | [int](/versions/8.1.1/rules/lib/core/int); or `None`; default is `None`  The start index of the list portion to inspect. |
+| `end` | [int](/versions/8.1.1/rules/lib/core/int); or `None`; default is `None`  The end index of the list portion to inspect. |
 
 ## insert
 
@@ -106,7 +106,7 @@ Inserts an item at a given position.
 
 | Parameter | Description |
 | --- | --- |
-| `index` | [int](../core/int); required  The index of the given position. |
+| `index` | [int](/versions/8.1.1/rules/lib/core/int); required  The index of the given position. |
 | `item` | required  The item. |
 
 ## pop
@@ -121,7 +121,7 @@ Removes the item at the given position in the list, and returns it. If no `index
 
 | Parameter | Description |
 | --- | --- |
-| `i` | [int](../core/int); or `None`; default is `-1`  The index of the item. |
+| `i` | [int](/versions/8.1.1/rules/lib/core/int); or `None`; default is `-1`  The index of the item. |
 
 ## remove
 
diff --git a/versions/8.1.1/rules/lib/core/set.mdx b/versions/8.1.1/rules/lib/core/set.mdx
index aeb3b202..4ba1d3eb 100644
--- a/versions/8.1.1/rules/lib/core/set.mdx
+++ b/versions/8.1.1/rules/lib/core/set.mdx
@@ -3,14 +3,14 @@ title: 'set'
 ---
 
 The built-in set type. A set is a mutable, iterable collection of unique values – the set's
-*elements*. The [type name](../globals/all#type) of a set is `"set"`.
+*elements*. The [type name](/versions/8.1.1/rules/lib/globals/all#type) of a set is `"set"`.
 
 Sets provide constant-time operations to insert, remove, or check for the presence of a value.
 Sets are implemented using a hash table, and therefore, just like keys of a
-[dictionary](../dict), elements of a set must be hashable. A value may be used as an
+[dictionary](/versions/8.1.1/rules/lib/core/dict), elements of a set must be hashable. A value may be used as an
 element of a set if and only if it may be used as a key of a dictionary.
 
-Sets may be constructed using the [`set()`](../globals/all#set) built-in
+Sets may be constructed using the [`set()`](/versions/8.1.1/rules/lib/globals/all#set) built-in
 function, which returns a new set containing the unique elements of its optional argument, which
 must be an iterable. Calling `set()` without an argument constructs an empty set. Sets
 have no literal syntax.
@@ -26,7 +26,7 @@ s = set(["a", "b", "c"])
 
 A set is iterable, and thus may be used as the operand of a `for` loop, a list
 comprehension, and the various built-in functions that operate on iterables. Its length can be
-retrieved using the [`len()`](../globals/all#len) built-in function, and the
+retrieved using the [`len()`](/versions/8.1.1/rules/lib/globals/all#len) built-in function, and the
 order of iteration is the order in which elements were first added to the set:
 
 ```
diff --git a/versions/8.1.1/rules/lib/core/string.mdx b/versions/8.1.1/rules/lib/core/string.mdx
index 1673c6e4..ec55a0e9 100644
--- a/versions/8.1.1/rules/lib/core/string.mdx
+++ b/versions/8.1.1/rules/lib/core/string.mdx
@@ -81,9 +81,9 @@ Returns the number of (non-overlapping) occurrences of substring `sub` in string
 
 | Parameter | Description |
 | --- | --- |
-| `sub` | [string](../core/string); required |
-| `start` | [int](../core/int); or `None`; default is `0` |
-| `end` | [int](../core/int); or `None`; default is `None`  optional position before which to restrict to search. |
+| `sub` | [string](/versions/8.1.1/rules/lib/core/string); required |
+| `start` | [int](/versions/8.1.1/rules/lib/core/int); or `None`; default is `0` |
+| `end` | [int](/versions/8.1.1/rules/lib/core/int); or `None`; default is `None`  optional position before which to restrict to search. |
 
 ## elems
 
@@ -105,9 +105,9 @@ Returns True if the string ends with `sub`, otherwise False, optionally restrict
 
 | Parameter | Description |
 | --- | --- |
-| `sub` | [string](../core/string); or [tuple](../core/tuple) of [string](../core/string)s; required  The suffix (or tuple of alternative suffixes) to match. |
-| `start` | [int](../core/int); or `None`; default is `0`  Test beginning at this position. |
-| `end` | [int](../core/int); or `None`; default is `None`  optional position at which to stop comparing. |
+| `sub` | [string](/versions/8.1.1/rules/lib/core/string); or [tuple](/versions/8.1.1/rules/lib/core/tuple) of [string](/versions/8.1.1/rules/lib/core/string)s; required  The suffix (or tuple of alternative suffixes) to match. |
+| `start` | [int](/versions/8.1.1/rules/lib/core/int); or `None`; default is `0`  Test beginning at this position. |
+| `end` | [int](/versions/8.1.1/rules/lib/core/int); or `None`; default is `None`  optional position at which to stop comparing. |
 
 ## find
 
@@ -121,9 +121,9 @@ Returns the first index where `sub` is found, or -1 if no such index exists, opt
 
 | Parameter | Description |
 | --- | --- |
-| `sub` | [string](../core/string); required  The substring to find. |
-| `start` | [int](../core/int); or `None`; default is `0`  Restrict to search from this position. |
-| `end` | [int](../core/int); or `None`; default is `None`  optional position before which to restrict to search. |
+| `sub` | [string](/versions/8.1.1/rules/lib/core/string); required  The substring to find. |
+| `start` | [int](/versions/8.1.1/rules/lib/core/int); or `None`; default is `0`  Restrict to search from this position. |
+| `end` | [int](/versions/8.1.1/rules/lib/core/int); or `None`; default is `None`  optional position before which to restrict to search. |
 
 ## format
 
@@ -131,7 +131,7 @@ Returns the first index where `sub` is found, or -1 if no such index exists, opt
 string string.format(*args, **kwargs)
 ```
 
-Perform string interpolation. Format strings contain replacement fields surrounded by curly braces `{}`. Anything that is not contained in braces is considered literal text, which is copied unchanged to the output.If you need to include a brace character in the literal text, it can be escaped by doubling: `{{` and `}}`A replacement field can be either a name, a number, or empty. Values are converted to strings using the [str](../globals/all#str) function.
+Perform string interpolation. Format strings contain replacement fields surrounded by curly braces `{}`. Anything that is not contained in braces is considered literal text, which is copied unchanged to the output.If you need to include a brace character in the literal text, it can be escaped by doubling: `{{` and `}}`A replacement field can be either a name, a number, or empty. Values are converted to strings using the [str](/versions/8.1.1/rules/lib/globals/all#str) function.
 
 ```
 # Access in order:
@@ -161,9 +161,9 @@ Returns the first index where `sub` is found, or raises an error if no such inde
 
 | Parameter | Description |
 | --- | --- |
-| `sub` | [string](../core/string); required  The substring to find. |
-| `start` | [int](../core/int); or `None`; default is `0`  Restrict to search from this position. |
-| `end` | [int](../core/int); or `None`; default is `None`  optional position before which to restrict to search. |
+| `sub` | [string](/versions/8.1.1/rules/lib/core/string); required  The substring to find. |
+| `start` | [int](/versions/8.1.1/rules/lib/core/int); or `None`; default is `0`  Restrict to search from this position. |
+| `end` | [int](/versions/8.1.1/rules/lib/core/int); or `None`; default is `None`  optional position before which to restrict to search. |
 
 ## isalnum
 
@@ -263,7 +263,7 @@ Returns a copy of the string where leading characters that appear in `chars` are
 
 | Parameter | Description |
 | --- | --- |
-| `chars` | [string](../core/string); or `None`; default is `None`  The characters to remove, or all whitespace if None. |
+| `chars` | [string](/versions/8.1.1/rules/lib/core/string); or `None`; default is `None`  The characters to remove, or all whitespace if None. |
 
 ## partition
 
@@ -277,7 +277,7 @@ Splits the input string at the first occurrence of the separator `sep` and retur
 
 | Parameter | Description |
 | --- | --- |
-| `sep` | [string](../core/string); required  The string to split on. |
+| `sep` | [string](/versions/8.1.1/rules/lib/core/string); required  The string to split on. |
 
 ## removeprefix
 
@@ -291,7 +291,7 @@ If the string starts with `prefix`, returns a new string with the prefix removed
 
 | Parameter | Description |
 | --- | --- |
-| `prefix` | [string](../core/string); required  The prefix to remove if present. |
+| `prefix` | [string](/versions/8.1.1/rules/lib/core/string); required  The prefix to remove if present. |
 
 ## removesuffix
 
@@ -305,7 +305,7 @@ If the string ends with `suffix`, returns a new string with the suffix removed.
 
 | Parameter | Description |
 | --- | --- |
-| `suffix` | [string](../core/string); required  The suffix to remove if present. |
+| `suffix` | [string](/versions/8.1.1/rules/lib/core/string); required  The suffix to remove if present. |
 
 ## replace
 
@@ -319,9 +319,9 @@ Returns a copy of the string in which the occurrences of `old` have been replace
 
 | Parameter | Description |
 | --- | --- |
-| `old` | [string](../core/string); required  The string to be replaced. |
-| `new` | [string](../core/string); required  The string to replace with. |
-| `count` | [int](../core/int); default is `-1`  The maximum number of replacements. If omitted, or if the value is negative, there is no limit. |
+| `old` | [string](/versions/8.1.1/rules/lib/core/string); required  The string to be replaced. |
+| `new` | [string](/versions/8.1.1/rules/lib/core/string); required  The string to replace with. |
+| `count` | [int](/versions/8.1.1/rules/lib/core/int); default is `-1`  The maximum number of replacements. If omitted, or if the value is negative, there is no limit. |
 
 ## rfind
 
@@ -335,9 +335,9 @@ Returns the last index where `sub` is found, or -1 if no such index exists, opti
 
 | Parameter | Description |
 | --- | --- |
-| `sub` | [string](../core/string); required  The substring to find. |
-| `start` | [int](../core/int); or `None`; default is `0`  Restrict to search from this position. |
-| `end` | [int](../core/int); or `None`; default is `None`  optional position before which to restrict to search. |
+| `sub` | [string](/versions/8.1.1/rules/lib/core/string); required  The substring to find. |
+| `start` | [int](/versions/8.1.1/rules/lib/core/int); or `None`; default is `0`  Restrict to search from this position. |
+| `end` | [int](/versions/8.1.1/rules/lib/core/int); or `None`; default is `None`  optional position before which to restrict to search. |
 
 ## rindex
 
@@ -351,9 +351,9 @@ Returns the last index where `sub` is found, or raises an error if no such index
 
 | Parameter | Description |
 | --- | --- |
-| `sub` | [string](../core/string); required  The substring to find. |
-| `start` | [int](../core/int); or `None`; default is `0`  Restrict to search from this position. |
-| `end` | [int](../core/int); or `None`; default is `None`  optional position before which to restrict to search. |
+| `sub` | [string](/versions/8.1.1/rules/lib/core/string); required  The substring to find. |
+| `start` | [int](/versions/8.1.1/rules/lib/core/int); or `None`; default is `0`  Restrict to search from this position. |
+| `end` | [int](/versions/8.1.1/rules/lib/core/int); or `None`; default is `None`  optional position before which to restrict to search. |
 
 ## rpartition
 
@@ -367,7 +367,7 @@ Splits the input string at the last occurrence of the separator `sep` and return
 
 | Parameter | Description |
 | --- | --- |
-| `sep` | [string](../core/string); required  The string to split on. |
+| `sep` | [string](/versions/8.1.1/rules/lib/core/string); required  The string to split on. |
 
 ## rsplit
 
@@ -381,8 +381,8 @@ Returns a list of all the words in the string, using `sep` as the separator, opt
 
 | Parameter | Description |
 | --- | --- |
-| `sep` | [string](../core/string); required  The string to split on. |
-| `maxsplit` | [int](../core/int); or `None`; default is `None`  The maximum number of splits. |
+| `sep` | [string](/versions/8.1.1/rules/lib/core/string); required  The string to split on. |
+| `maxsplit` | [int](/versions/8.1.1/rules/lib/core/int); or `None`; default is `None`  The maximum number of splits. |
 
 ## rstrip
 
@@ -400,7 +400,7 @@ Returns a copy of the string where trailing characters that appear in `chars` ar
 
 | Parameter | Description |
 | --- | --- |
-| `chars` | [string](../core/string); or `None`; default is `None`  The characters to remove, or all whitespace if None. |
+| `chars` | [string](/versions/8.1.1/rules/lib/core/string); or `None`; default is `None`  The characters to remove, or all whitespace if None. |
 
 ## split
 
@@ -414,8 +414,8 @@ Returns a list of all the words in the string, using `sep` as the separator, opt
 
 | Parameter | Description |
 | --- | --- |
-| `sep` | [string](../core/string); required  The string to split on. |
-| `maxsplit` | [int](../core/int); or `None`; default is `None`  The maximum number of splits. |
+| `sep` | [string](/versions/8.1.1/rules/lib/core/string); required  The string to split on. |
+| `maxsplit` | [int](/versions/8.1.1/rules/lib/core/int); or `None`; default is `None`  The maximum number of splits. |
 
 ## splitlines
 
@@ -429,7 +429,7 @@ Splits the string at line boundaries ('\n', '\r\n', '\r') and returns the result
 
 | Parameter | Description |
 | --- | --- |
-| `keepends` | [bool](../core/bool); default is `False`  Whether the line breaks should be included in the resulting list. |
+| `keepends` | [bool](/versions/8.1.1/rules/lib/core/bool); default is `False`  Whether the line breaks should be included in the resulting list. |
 
 ## startswith
 
@@ -443,9 +443,9 @@ Returns True if the string starts with `sub`, otherwise False, optionally restri
 
 | Parameter | Description |
 | --- | --- |
-| `sub` | [string](../core/string); or [tuple](../core/tuple) of [string](../core/string)s; required  The prefix (or tuple of alternative prefixes) to match. |
-| `start` | [int](../core/int); or `None`; default is `0`  Test beginning at this position. |
-| `end` | [int](../core/int); or `None`; default is `None`  Stop comparing at this position. |
+| `sub` | [string](/versions/8.1.1/rules/lib/core/string); or [tuple](/versions/8.1.1/rules/lib/core/tuple) of [string](/versions/8.1.1/rules/lib/core/string)s; required  The prefix (or tuple of alternative prefixes) to match. |
+| `start` | [int](/versions/8.1.1/rules/lib/core/int); or `None`; default is `0`  Test beginning at this position. |
+| `end` | [int](/versions/8.1.1/rules/lib/core/int); or `None`; default is `None`  Stop comparing at this position. |
 
 ## strip
 
@@ -463,7 +463,7 @@ Returns a copy of the string where leading or trailing characters that appear in
 
 | Parameter | Description |
 | --- | --- |
-| `chars` | [string](../core/string); or `None`; default is `None`  The characters to remove, or all whitespace if None. |
+| `chars` | [string](/versions/8.1.1/rules/lib/core/string); or `None`; default is `None`  The characters to remove, or all whitespace if None. |
 
 ## title
 
diff --git a/versions/8.1.1/rules/lib/fragments.mdx b/versions/8.1.1/rules/lib/fragments.mdx
index 9ee76bd6..f197634d 100644
--- a/versions/8.1.1/rules/lib/fragments.mdx
+++ b/versions/8.1.1/rules/lib/fragments.mdx
@@ -2,7 +2,7 @@
 title: 'Configuration Fragments'
 ---
 
-Configuration fragments give rules access to language-specific parts of [configuration](builtins/configuration).
+Configuration fragments give rules access to language-specific parts of [configuration](/versions/8.1.1/rules/lib/builtins/configuration).
 
 Rule implementations can get them using `ctx.fragments.[fragment name]`
 
diff --git a/versions/8.1.1/rules/lib/fragments/apple.mdx b/versions/8.1.1/rules/lib/fragments/apple.mdx
index f7e8daff..8f97aa02 100644
--- a/versions/8.1.1/rules/lib/fragments/apple.mdx
+++ b/versions/8.1.1/rules/lib/fragments/apple.mdx
@@ -22,7 +22,7 @@ The platform of the current configuration for the given platform type. This shou
 
 | Parameter | Description |
 | --- | --- |
-| `platform_type` | [string](../core/string); required  The apple platform type. |
+| `platform_type` | [string](/versions/8.1.1/rules/lib/core/string); required  The apple platform type. |
 
 ## single\_arch\_cpu
 
diff --git a/versions/8.1.1/rules/lib/fragments/coverage.mdx b/versions/8.1.1/rules/lib/fragments/coverage.mdx
index 8a380e14..8aecda76 100644
--- a/versions/8.1.1/rules/lib/fragments/coverage.mdx
+++ b/versions/8.1.1/rules/lib/fragments/coverage.mdx
@@ -14,7 +14,7 @@ A configuration fragment representing the coverage configuration.
 Label coverage.output_generator
 ```
 
-Returns the label pointed to by the [`--coverage_output_generator`](https://bazel.build/versions/8.1.1/reference/command-line-reference#flag--coverage_output_generator) option if coverage collection is enabled, otherwise returns `None`. Can be accessed with [`configuration_field`](../globals/bzl#configuration_field):
+Returns the label pointed to by the [`--coverage_output_generator`](https://bazel.build/versions/8.1.1/reference/command-line-reference#flag--coverage_output_generator) option if coverage collection is enabled, otherwise returns `None`. Can be accessed with [`configuration_field`](/versions/8.1.1/rules/lib/globals/bzl#configuration_field):
 
 ```
 attr.label(
diff --git a/versions/8.1.1/rules/lib/fragments/cpp.mdx b/versions/8.1.1/rules/lib/fragments/cpp.mdx
index 28dac95a..db93891d 100644
--- a/versions/8.1.1/rules/lib/fragments/cpp.mdx
+++ b/versions/8.1.1/rules/lib/fragments/cpp.mdx
@@ -46,7 +46,7 @@ The flags passed to Bazel by [`--copt`](/versions/8.1.1/docs/user-manual#flag--c
 Label cpp.custom_malloc
 ```
 
-Returns label pointed to by [`--custom_malloc`](/versions/8.1.1/docs/user-manual#flag--custom_malloc) option. Can be accessed with [`configuration_field`](../globals/bzl#configuration_field):
+Returns label pointed to by [`--custom_malloc`](/versions/8.1.1/docs/user-manual#flag--custom_malloc) option. Can be accessed with [`configuration_field`](/versions/8.1.1/rules/lib/globals/bzl#configuration_field):
 
 ```
 attr.label(
diff --git a/versions/8.1.1/rules/lib/globals/all.mdx b/versions/8.1.1/rules/lib/globals/all.mdx
index 45106d41..84107ce9 100644
--- a/versions/8.1.1/rules/lib/globals/all.mdx
+++ b/versions/8.1.1/rules/lib/globals/all.mdx
@@ -50,7 +50,7 @@ abs(-2.3) == 2.3
 
 | Parameter | Description |
 | --- | --- |
-| `x` | [int](../core/int); or [float](../core/float); required  A number (int or float) |
+| `x` | [int](/versions/8.1.1/rules/lib/core/int); or [float](/versions/8.1.1/rules/lib/core/float); required  A number (int or float) |
 
 ## all
 
@@ -110,7 +110,7 @@ Constructor for the bool type. It returns `False` if the object is `None`, `Fals
 dict dict(pairs=[], **kwargs)
 ```
 
-Creates a [dictionary](../core/dict) from an optional positional argument and an optional set of keyword arguments. In the case where the same key is given multiple times, the last value will be used. Entries supplied via keyword arguments are considered to come after entries supplied via the positional argument.
+Creates a [dictionary](/versions/8.1.1/rules/lib/core/dict) from an optional positional argument and an optional set of keyword arguments. In the case where the same key is given multiple times, the last value will be used. Entries supplied via keyword arguments are considered to come after entries supplied via the positional argument.
 
 ### Parameters
 
@@ -150,7 +150,7 @@ enumerate([24, 21, 84]) == [(0, 24), (1, 21), (2, 84)]
 | Parameter | Description |
 | --- | --- |
 | `list` | required  input sequence. |
-| `start` | [int](../core/int); default is `0`  start index. |
+| `start` | [int](/versions/8.1.1/rules/lib/core/int); default is `0`  start index. |
 
 ## fail
 
@@ -165,8 +165,8 @@ Causes execution to fail with an error.
 | Parameter | Description |
 | --- | --- |
 | `msg` | default is `None`  Deprecated: use positional arguments instead. This argument acts like an implicit leading positional argument. |
-| `attr` | [string](../core/string); or `None`; default is `None`  Deprecated. Causes an optional prefix containing this string to be added to the error message. |
-| `sep` | [string](../core/string); default is `" "`  The separator string between the objects, default is space (" "). |
+| `attr` | [string](/versions/8.1.1/rules/lib/core/string); or `None`; default is `None`  Deprecated. Causes an optional prefix containing this string to be added to the error message. |
+| `sep` | [string](/versions/8.1.1/rules/lib/core/string); default is `" "`  The separator string between the objects, default is space (" "). |
 | `args` | required  A list of values, formatted with debugPrint (which is equivalent to str by default) and joined with sep (defaults to " "), that appear in the error message. |
 
 ## float
@@ -205,7 +205,7 @@ getattr(ctx.attr, "myattr", "mydefault")
 | Parameter | Description |
 | --- | --- |
 | `x` | required  The struct whose attribute is accessed. |
-| `name` | [string](../core/string); required  The name of the struct attribute. |
+| `name` | [string](/versions/8.1.1/rules/lib/core/string); required  The name of the struct attribute. |
 | `default` | default is `unbound`  The default value to return in case the struct doesn't have an attribute of the given name. |
 
 ## hasattr
@@ -225,7 +225,7 @@ hasattr(ctx.attr, "myattr")
 | Parameter | Description |
 | --- | --- |
 | `x` | required |
-| `name` | [string](../core/string); required  The name of the attribute. |
+| `name` | [string](/versions/8.1.1/rules/lib/core/string); required  The name of the attribute. |
 
 ## hash
 
@@ -245,7 +245,7 @@ Hashing of values besides strings is not currently supported.
 
 | Parameter | Description |
 | --- | --- |
-| `value` | [string](../core/string); required  String value to hash. |
+| `value` | [string](/versions/8.1.1/rules/lib/core/string); required  String value to hash. |
 
 ## int
 
@@ -372,7 +372,7 @@ Using `print` in production code is discouraged due to the spam it creates for u
 
 | Parameter | Description |
 | --- | --- |
-| `sep` | [string](../core/string); default is `" "`  The separator string between the objects, default is space (" "). |
+| `sep` | [string](/versions/8.1.1/rules/lib/core/string); default is `" "`  The separator string between the objects, default is space (" "). |
 | `args` | required  The objects to print. |
 
 ## range
@@ -393,9 +393,9 @@ range(3, 0, -1) == [3, 2, 1]
 
 | Parameter | Description |
 | --- | --- |
-| `start_or_stop` | [int](../core/int); required  Value of the start element if stop is provided, otherwise value of stop and the actual start is 0 |
-| `stop_or_none` | [int](../core/int); or `None`; default is `None`  optional index of the first item *not* to be included in the resulting list; generation of the list stops before `stop` is reached. |
-| `step` | [int](../core/int); default is `1`  The increment (default is 1). It may be negative. |
+| `start_or_stop` | [int](/versions/8.1.1/rules/lib/core/int); required  Value of the start element if stop is provided, otherwise value of stop and the actual start is 0 |
+| `stop_or_none` | [int](/versions/8.1.1/rules/lib/core/int); or `None`; default is `None`  optional index of the first item *not* to be included in the resulting list; generation of the list stops before `stop` is reached. |
+| `step` | [int](/versions/8.1.1/rules/lib/core/int); default is `1`  The increment (default is 1). It may be negative. |
 
 ## repr
 
@@ -439,7 +439,7 @@ reversed([3, 5, 4]) == [4, 5, 3]
 set set(elements=[])
 ```
 
-Creates a new [set](../core/set) containing the unique elements of a given
+Creates a new [set](/versions/8.1.1/rules/lib/core/set) containing the unique elements of a given
 iterable, preserving iteration order.
 
 If called with no argument, `set()` returns a new empty set.
@@ -479,7 +479,7 @@ sorted(["two", "three", "four"], key = len) == ["two", "four", "three"]  # sort
 | --- | --- |
 | `iterable` | iterable; required  The iterable sequence to sort. |
 | `key` | callable; or `None`; default is `None`  An optional function applied to each element before comparison. |
-| `reverse` | [bool](../core/bool); default is `False`  Return results in descending order. |
+| `reverse` | [bool](/versions/8.1.1/rules/lib/core/bool); default is `False`  Return results in descending order. |
 
 ## str
 
diff --git a/versions/8.1.1/rules/lib/globals/build.mdx b/versions/8.1.1/rules/lib/globals/build.mdx
index ba91f8aa..d4747c4c 100644
--- a/versions/8.1.1/rules/lib/globals/build.mdx
+++ b/versions/8.1.1/rules/lib/globals/build.mdx
@@ -28,7 +28,7 @@ Methods available in BUILD files. See also the Build Encyclopedia for extra [fun
 depset depset(direct=None, order="default", *, transitive=None)
 ```
 
-Creates a [depset](../builtins/depset). The `direct` parameter is a list of direct elements of the depset, and `transitive` parameter is a list of depsets whose elements become indirect elements of the created depset. The order in which elements are returned when the depset is converted to a list is specified by the `order` parameter. See the [Depsets overview](https://bazel.build/versions/8.1.1/extending/depsets) for more information.
+Creates a [depset](/versions/8.1.1/rules/lib/builtins/depset). The `direct` parameter is a list of direct elements of the depset, and `transitive` parameter is a list of depsets whose elements become indirect elements of the created depset. The order in which elements are returned when the depset is converted to a list is specified by the `order` parameter. See the [Depsets overview](https://bazel.build/versions/8.1.1/extending/depsets) for more information.
 
 All elements (direct and indirect) of a depset must be of the same type, as obtained by the expression `type(x)`.
 
@@ -42,9 +42,9 @@ The order of the created depset should be *compatible* with the order of its `tr
 
 | Parameter | Description |
 | --- | --- |
-| `direct` | [sequence](../core/list); or `None`; default is `None`  A list of *direct* elements of a depset. |
-| `order` | [string](../core/string); default is `"default"`  The traversal strategy for the new depset. See [here](../builtins/depset) for the possible values. |
-| `transitive` | [sequence](../core/list) of [depset](../builtins/depset)s; or `None`; default is `None`  A list of depsets whose elements will become indirect elements of the depset. |
+| `direct` | [sequence](/versions/8.1.1/rules/lib/core/list); or `None`; default is `None`  A list of *direct* elements of a depset. |
+| `order` | [string](/versions/8.1.1/rules/lib/core/string); default is `"default"`  The traversal strategy for the new depset. See [here](/versions/8.1.1/rules/lib/builtins/depset) for the possible values. |
+| `transitive` | [sequence](/versions/8.1.1/rules/lib/core/list) of [depset](/versions/8.1.1/rules/lib/builtins/depset)s; or `None`; default is `None`  A list of depsets whose elements will become indirect elements of the depset. |
 
 ## existing\_rule
 
@@ -72,7 +72,7 @@ If possible, avoid using this function. It makes BUILD files brittle and order-d
 
 | Parameter | Description |
 | --- | --- |
-| `name` | [string](../core/string); required  The name of the target. |
+| `name` | [string](/versions/8.1.1/rules/lib/core/string); required  The name of the target. |
 
 ## existing\_rules
 
@@ -98,9 +98,9 @@ Specifies a list of files belonging to this package that are exported to other p
 
 | Parameter | Description |
 | --- | --- |
-| `srcs` | [sequence](../core/list) of [string](../core/string)s; required  The list of files to export. |
-| `visibility` | [sequence](../core/list); or `None`; default is `None`  A visibility declaration can to be specified. The files will be visible to the targets specified. If no visibility is specified, the files will be visible to every package. |
-| `licenses` | [sequence](../core/list) of [string](../core/string)s; or `None`; default is `None`  Licenses to be specified. |
+| `srcs` | [sequence](/versions/8.1.1/rules/lib/core/list) of [string](/versions/8.1.1/rules/lib/core/string)s; required  The list of files to export. |
+| `visibility` | [sequence](/versions/8.1.1/rules/lib/core/list); or `None`; default is `None`  A visibility declaration can to be specified. The files will be visible to the targets specified. If no visibility is specified, the files will be visible to every package. |
+| `licenses` | [sequence](/versions/8.1.1/rules/lib/core/list) of [string](/versions/8.1.1/rules/lib/core/string)s; or `None`; default is `None`  Licenses to be specified. |
 
 ## glob
 
@@ -119,9 +119,9 @@ If the `exclude_directories` argument is enabled (set to `1`), files of type dir
 
 | Parameter | Description |
 | --- | --- |
-| `include` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  The list of glob patterns to include. |
-| `exclude` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  The list of glob patterns to exclude. |
-| `exclude_directories` | [int](../core/int); default is `1`  A flag whether to exclude directories or not. |
+| `include` | [sequence](/versions/8.1.1/rules/lib/core/list) of [string](/versions/8.1.1/rules/lib/core/string)s; default is `[]`  The list of glob patterns to include. |
+| `exclude` | [sequence](/versions/8.1.1/rules/lib/core/list) of [string](/versions/8.1.1/rules/lib/core/string)s; default is `[]`  The list of glob patterns to exclude. |
+| `exclude_directories` | [int](/versions/8.1.1/rules/lib/core/int); default is `1`  A flag whether to exclude directories or not. |
 | `allow_empty` | default is `unbound`  Whether we allow glob patterns to match nothing. If `allow\_empty` is False, each individual include pattern must match something and also the final result must be non-empty (after the matches of the `exclude` patterns are excluded). |
 
 ## module\_name
@@ -168,9 +168,9 @@ This function defines a set of packages and assigns a label to the group. The la
 
 | Parameter | Description |
 | --- | --- |
-| `name` | [string](../core/string); required  The unique name for this rule. |
-| `packages` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  A complete enumeration of packages in this group. |
-| `includes` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  Other package groups that are included in this one. |
+| `name` | [string](/versions/8.1.1/rules/lib/core/string); required  The unique name for this rule. |
+| `packages` | [sequence](/versions/8.1.1/rules/lib/core/list) of [string](/versions/8.1.1/rules/lib/core/string)s; default is `[]`  A complete enumeration of packages in this group. |
+| `includes` | [sequence](/versions/8.1.1/rules/lib/core/list) of [string](/versions/8.1.1/rules/lib/core/string)s; default is `[]`  Other package groups that are included in this one. |
 
 ## package\_name
 
@@ -186,19 +186,19 @@ The name of the package being evaluated, without the repository name. For exampl
 Label package_relative_label(input)
 ```
 
-Converts the input string into a [Label](../builtins/Label) object, in the context of the package currently being initialized (that is, the `BUILD` file for which the current macro is executing). If the input is already a `Label`, it is returned unchanged.
+Converts the input string into a [Label](/versions/8.1.1/rules/lib/builtins/Label) object, in the context of the package currently being initialized (that is, the `BUILD` file for which the current macro is executing). If the input is already a `Label`, it is returned unchanged.
 
 This function may only be called while evaluating a BUILD file and the macros it directly or indirectly calls; it may not be called in (for instance) a rule implementation function.
 
 The result of this function is the same `Label` value as would be produced by passing the given string to a label-valued attribute of a target declared in the BUILD file.
 
-*Usage note:* The difference between this function and [Label()](../builtins/Label#Label) is that `Label()` uses the context of the package of the `.bzl` file that called it, not the package of the `BUILD` file. Use `Label()` when you need to refer to a fixed target that is hardcoded into the macro, such as a compiler. Use `package_relative_label()` when you need to normalize a label string supplied by the BUILD file to a `Label` object. (There is no way to convert a string to a `Label` in the context of a package other than the BUILD file or the calling .bzl file. For that reason, outer macros should always prefer to pass Label objects to inner macros rather than label strings.)
+*Usage note:* The difference between this function and [Label()](/versions/8.1.1/rules/lib/builtins/Label#Label) is that `Label()` uses the context of the package of the `.bzl` file that called it, not the package of the `BUILD` file. Use `Label()` when you need to refer to a fixed target that is hardcoded into the macro, such as a compiler. Use `package_relative_label()` when you need to normalize a label string supplied by the BUILD file to a `Label` object. (There is no way to convert a string to a `Label` in the context of a package other than the BUILD file or the calling .bzl file. For that reason, outer macros should always prefer to pass Label objects to inner macros rather than label strings.)
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `input` | [string](../core/string); or [Label](../builtins/Label); required  The input label string or Label object. If a Label object is passed, it's returned as is. |
+| `input` | [string](/versions/8.1.1/rules/lib/core/string); or [Label](/versions/8.1.1/rules/lib/builtins/Label); required  The input label string or Label object. If a Label object is passed, it's returned as is. |
 
 ## repo\_name
 
@@ -231,8 +231,8 @@ unknown select(x, no_match_error='')
 
 | Parameter | Description |
 | --- | --- |
-| `x` | [dict](../core/dict); required |
-| `no_match_error` | [string](../core/string); default is `''`  Optional custom error to report if no condition matches. |
+| `x` | [dict](/versions/8.1.1/rules/lib/core/dict); required |
+| `no_match_error` | [string](/versions/8.1.1/rules/lib/core/string); default is `''`  Optional custom error to report if no condition matches. |
 
 ## subpackages
 
@@ -246,6 +246,6 @@ Returns a new mutable list of every direct subpackage of the current package, re
 
 | Parameter | Description |
 | --- | --- |
-| `include` | [sequence](../core/list) of [string](../core/string)s; required  The list of glob patterns to include in subpackages scan. |
-| `exclude` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  The list of glob patterns to exclude from subpackages scan. |
-| `allow_empty` | [bool](../core/bool); default is `False`  Whether we fail if the call returns an empty list. By default empty list indicates potential error in BUILD file where the call to subpackages() is superflous. Setting to true allows this function to succeed in that case. |*
\ No newline at end of file
+| `include` | [sequence](/versions/8.1.1/rules/lib/core/list) of [string](/versions/8.1.1/rules/lib/core/string)s; required  The list of glob patterns to include in subpackages scan. |
+| `exclude` | [sequence](/versions/8.1.1/rules/lib/core/list) of [string](/versions/8.1.1/rules/lib/core/string)s; default is `[]`  The list of glob patterns to exclude from subpackages scan. |
+| `allow_empty` | [bool](/versions/8.1.1/rules/lib/core/bool); default is `False`  Whether we fail if the call returns an empty list. By default empty list indicates potential error in BUILD file where the call to subpackages() is superflous. Setting to true allows this function to succeed in that case. |*
\ No newline at end of file
diff --git a/versions/8.1.1/rules/lib/globals/bzl.mdx b/versions/8.1.1/rules/lib/globals/bzl.mdx
index df4b4e8c..2b663636 100644
--- a/versions/8.1.1/rules/lib/globals/bzl.mdx
+++ b/versions/8.1.1/rules/lib/globals/bzl.mdx
@@ -28,7 +28,7 @@ Global methods available in all .bzl files.
 transition analysis_test_transition(settings)
 ```
 
-Creates a configuration transition to be applied on an analysis-test rule's dependencies. This transition may only be applied on attributes of rules with `analysis_test = True`. Such rules are restricted in capabilities (for example, the size of their dependency tree is limited), so transitions created using this function are limited in potential scope as compared to transitions created using [`transition()`](../builtins/transition).
+Creates a configuration transition to be applied on an analysis-test rule's dependencies. This transition may only be applied on attributes of rules with `analysis_test = True`. Such rules are restricted in capabilities (for example, the size of their dependency tree is limited), so transitions created using this function are limited in potential scope as compared to transitions created using [`transition()`](/versions/8.1.1/rules/lib/builtins/transition).
 
 This function is primarily designed to facilitate the [Analysis Test Framework](https://bazel.build/versions/8.1.1/rules/testing) core library. See its documentation (or its implementation) for best practices.
 
@@ -36,7 +36,7 @@ This function is primarily designed to facilitate the [Analysis Test Framework](
 
 | Parameter | Description |
 | --- | --- |
-| `settings` | [dict](../core/dict); required  A dictionary containing information about configuration settings which should be set by this configuration transition. Keys are build setting labels and values are their new post-transition values. All other settings are unchanged. Use this to declare specific configuration settings that an analysis test requires to be set in order to pass. |
+| `settings` | [dict](/versions/8.1.1/rules/lib/core/dict); required  A dictionary containing information about configuration settings which should be set by this configuration transition. Keys are build setting labels and values are their new post-transition values. All other settings are unchanged. Use this to declare specific configuration settings that an analysis test requires to be set in order to pass. |
 
 ## aspect
 
@@ -50,23 +50,23 @@ Creates a new aspect. The result of this function must be stored in a global val
 
 | Parameter | Description |
 | --- | --- |
-| `implementation` | [function](../core/function); required  A Starlark function that implements this aspect, with exactly two parameters: [Target](../builtins/Target) (the target to which the aspect is applied) and [ctx](../builtins/ctx) (the rule context which the target is created from). Attributes of the target are available via the `ctx.rule` field. This function is evaluated during the analysis phase for each application of an aspect to a target. |
-| `attr_aspects` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  List of attribute names. The aspect propagates along dependencies specified in the attributes of a target with these names. Common values here include `deps` and `exports`. The list can also contain a single string `"*"` to propagate along all dependencies of a target. |
-| `toolchains_aspects` | [sequence](../core/list); default is `[]`  List of toolchain types. The aspect propagates to target toolchains which match these toolchain types. |
-| `attrs` | [dict](../core/dict); default is `{}`  A dictionary declaring all the attributes of the aspect. It maps from an attribute name to an attribute object, like `attr.label` or `attr.string` (see [`attr`](../toplevel/attr) module). Aspect attributes are available to implementation function as fields of `ctx` parameter. Implicit attributes starting with `_` must have default values, and have type `label` or `label_list`.  Explicit attributes must have type `string`, and must use the `values` restriction. Explicit attributes restrict the aspect to only be used with rules that have attributes of the same name, type, and valid values according to the restriction.  Declared attributes will convert `None` to the default value. |
-| `required_providers` | [sequence](../core/list); default is `[]`  This attribute allows the aspect to limit its propagation to only the targets whose rules advertise its required providers. The value must be a list containing either individual providers or lists of providers but not both. For example, `[[FooInfo], [BarInfo], [BazInfo, QuxInfo]]` is a valid value while `[FooInfo, BarInfo, [BazInfo, QuxInfo]]` is not valid. An unnested list of providers will automatically be converted to a list containing one list of providers. That is, `[FooInfo, BarInfo]` will automatically be converted to `[[FooInfo, BarInfo]]`. To make some rule (e.g. `some_rule`) targets visible to an aspect, `some_rule` must advertise all providers from at least one of the required providers lists. For example, if the `required_providers` of an aspect are `[[FooInfo], [BarInfo], [BazInfo, QuxInfo]]`, this aspect can see `some_rule` targets if and only if `some_rule` provides `FooInfo`, *or* `BarInfo`, *or* both `BazInfo` *and* `QuxInfo`. |
-| `required_aspect_providers` | [sequence](../core/list); default is `[]`  This attribute allows this aspect to inspect other aspects. The value must be a list containing either individual providers or lists of providers but not both. For example, `[[FooInfo], [BarInfo], [BazInfo, QuxInfo]]` is a valid value while `[FooInfo, BarInfo, [BazInfo, QuxInfo]]` is not valid. An unnested list of providers will automatically be converted to a list containing one list of providers. That is, `[FooInfo, BarInfo]` will automatically be converted to `[[FooInfo, BarInfo]]`. To make another aspect (e.g. `other_aspect`) visible to this aspect, `other_aspect` must provide all providers from at least one of the lists. In the example of `[[FooInfo], [BarInfo], [BazInfo, QuxInfo]]`, this aspect can see `other_aspect` if and only if `other_aspect` provides `FooInfo`, *or* `BarInfo`, *or* both `BazInfo` *and* `QuxInfo`. |
-| `provides` | [sequence](../core/list); default is `[]`  A list of providers that the implementation function must return. It is an error if the implementation function omits any of the types of providers listed here from its return value. However, the implementation function may return additional providers not listed here. Each element of the list is an `*Info` object returned by [`provider()`](../globals/bzl#provider), except that a legacy provider is represented by its string name instead.When a target of the rule is used as a dependency for a target that declares a required provider, it is not necessary to specify that provider here. It is enough that the implementation function returns it. However, it is considered best practice to specify it, even though this is not required. The [`required_providers`](../globals/bzl#aspect.required_providers) field of an [aspect](../globals/bzl#aspect) does, however, require that providers are specified here. |
-| `requires` | [sequence](../core/list) of [Aspect](../builtins/Aspect)s; default is `[]`  List of aspects required to be propagated before this aspect. |
-| `fragments` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  List of names of configuration fragments that the aspect requires in target configuration. |
-| `host_fragments` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  List of names of configuration fragments that the aspect requires in host configuration. |
-| `toolchains` | [sequence](../core/list); default is `[]`  If set, the set of toolchains this aspect requires. The list can contain String, Label, or StarlarkToolchainTypeApi objects, in any combination. Toolchains will be found by checking the current platform, and provided to the aspect implementation via `ctx.toolchain`. |
-| `incompatible_use_toolchain_transition` | [bool](../core/bool); default is `False`  Deprecated, this is no longer in use and should be removed. |
-| `doc` | [string](../core/string); or `None`; default is `None`  A description of the aspect that can be extracted by documentation generating tools. |
-| `apply_to_generating_rules` | [bool](../core/bool); default is `False`  If true, the aspect will, when applied to an output file, instead apply to the output file's generating rule. For example, suppose an aspect propagates transitively through attribute `deps` and it is applied to target `alpha`. Suppose `alpha` has `deps = [':beta\_output']`, where `beta\_output` is a declared output of a target `beta`. Suppose `beta` has a target `charlie` as one of its `deps`. If `apply\_to\_generating\_rules=True` for the aspect, then the aspect will propagate through `alpha`, `beta`, and `charlie`. If False, then the aspect will propagate only to `alpha`.  False by default. |
-| `exec_compatible_with` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  A list of constraints on the execution platform that apply to all instances of this aspect. |
-| `exec_groups` | [dict](../core/dict); or `None`; default is `None`  Dict of execution group name (string) to [`exec_group`s](../globals/bzl#exec_group). If set, allows aspects to run actions on multiple execution platforms within a single instance. See [execution groups documentation](/versions/8.1.1/reference/exec-groups) for more info. |
-| `subrules` | [sequence](../core/list) of [Subrule](../builtins/Subrule)s; default is `[]`  Experimental: list of subrules used by this aspect. |
+| `implementation` | [function](/versions/8.1.1/rules/lib/core/function); required  A Starlark function that implements this aspect, with exactly two parameters: [Target](/versions/8.1.1/rules/lib/builtins/Target) (the target to which the aspect is applied) and [ctx](/versions/8.1.1/rules/lib/builtins/ctx) (the rule context which the target is created from). Attributes of the target are available via the `ctx.rule` field. This function is evaluated during the analysis phase for each application of an aspect to a target. |
+| `attr_aspects` | [sequence](/versions/8.1.1/rules/lib/core/list) of [string](/versions/8.1.1/rules/lib/core/string)s; default is `[]`  List of attribute names. The aspect propagates along dependencies specified in the attributes of a target with these names. Common values here include `deps` and `exports`. The list can also contain a single string `"*"` to propagate along all dependencies of a target. |
+| `toolchains_aspects` | [sequence](/versions/8.1.1/rules/lib/core/list); default is `[]`  List of toolchain types. The aspect propagates to target toolchains which match these toolchain types. |
+| `attrs` | [dict](/versions/8.1.1/rules/lib/core/dict); default is `{}`  A dictionary declaring all the attributes of the aspect. It maps from an attribute name to an attribute object, like `attr.label` or `attr.string` (see [`attr`](/versions/8.1.1/rules/lib/toplevel/attr) module). Aspect attributes are available to implementation function as fields of `ctx` parameter. Implicit attributes starting with `_` must have default values, and have type `label` or `label_list`.  Explicit attributes must have type `string`, and must use the `values` restriction. Explicit attributes restrict the aspect to only be used with rules that have attributes of the same name, type, and valid values according to the restriction.  Declared attributes will convert `None` to the default value. |
+| `required_providers` | [sequence](/versions/8.1.1/rules/lib/core/list); default is `[]`  This attribute allows the aspect to limit its propagation to only the targets whose rules advertise its required providers. The value must be a list containing either individual providers or lists of providers but not both. For example, `[[FooInfo], [BarInfo], [BazInfo, QuxInfo]]` is a valid value while `[FooInfo, BarInfo, [BazInfo, QuxInfo]]` is not valid. An unnested list of providers will automatically be converted to a list containing one list of providers. That is, `[FooInfo, BarInfo]` will automatically be converted to `[[FooInfo, BarInfo]]`. To make some rule (e.g. `some_rule`) targets visible to an aspect, `some_rule` must advertise all providers from at least one of the required providers lists. For example, if the `required_providers` of an aspect are `[[FooInfo], [BarInfo], [BazInfo, QuxInfo]]`, this aspect can see `some_rule` targets if and only if `some_rule` provides `FooInfo`, *or* `BarInfo`, *or* both `BazInfo` *and* `QuxInfo`. |
+| `required_aspect_providers` | [sequence](/versions/8.1.1/rules/lib/core/list); default is `[]`  This attribute allows this aspect to inspect other aspects. The value must be a list containing either individual providers or lists of providers but not both. For example, `[[FooInfo], [BarInfo], [BazInfo, QuxInfo]]` is a valid value while `[FooInfo, BarInfo, [BazInfo, QuxInfo]]` is not valid. An unnested list of providers will automatically be converted to a list containing one list of providers. That is, `[FooInfo, BarInfo]` will automatically be converted to `[[FooInfo, BarInfo]]`. To make another aspect (e.g. `other_aspect`) visible to this aspect, `other_aspect` must provide all providers from at least one of the lists. In the example of `[[FooInfo], [BarInfo], [BazInfo, QuxInfo]]`, this aspect can see `other_aspect` if and only if `other_aspect` provides `FooInfo`, *or* `BarInfo`, *or* both `BazInfo` *and* `QuxInfo`. |
+| `provides` | [sequence](/versions/8.1.1/rules/lib/core/list); default is `[]`  A list of providers that the implementation function must return. It is an error if the implementation function omits any of the types of providers listed here from its return value. However, the implementation function may return additional providers not listed here. Each element of the list is an `*Info` object returned by [`provider()`](/versions/8.1.1/rules/lib/globals/bzl#provider), except that a legacy provider is represented by its string name instead.When a target of the rule is used as a dependency for a target that declares a required provider, it is not necessary to specify that provider here. It is enough that the implementation function returns it. However, it is considered best practice to specify it, even though this is not required. The [`required_providers`](/versions/8.1.1/rules/lib/globals/bzl#aspect.required_providers) field of an [aspect](/versions/8.1.1/rules/lib/globals/bzl#aspect) does, however, require that providers are specified here. |
+| `requires` | [sequence](/versions/8.1.1/rules/lib/core/list) of [Aspect](/versions/8.1.1/rules/lib/builtins/Aspect)s; default is `[]`  List of aspects required to be propagated before this aspect. |
+| `fragments` | [sequence](/versions/8.1.1/rules/lib/core/list) of [string](/versions/8.1.1/rules/lib/core/string)s; default is `[]`  List of names of configuration fragments that the aspect requires in target configuration. |
+| `host_fragments` | [sequence](/versions/8.1.1/rules/lib/core/list) of [string](/versions/8.1.1/rules/lib/core/string)s; default is `[]`  List of names of configuration fragments that the aspect requires in host configuration. |
+| `toolchains` | [sequence](/versions/8.1.1/rules/lib/core/list); default is `[]`  If set, the set of toolchains this aspect requires. The list can contain String, Label, or StarlarkToolchainTypeApi objects, in any combination. Toolchains will be found by checking the current platform, and provided to the aspect implementation via `ctx.toolchain`. |
+| `incompatible_use_toolchain_transition` | [bool](/versions/8.1.1/rules/lib/core/bool); default is `False`  Deprecated, this is no longer in use and should be removed. |
+| `doc` | [string](/versions/8.1.1/rules/lib/core/string); or `None`; default is `None`  A description of the aspect that can be extracted by documentation generating tools. |
+| `apply_to_generating_rules` | [bool](/versions/8.1.1/rules/lib/core/bool); default is `False`  If true, the aspect will, when applied to an output file, instead apply to the output file's generating rule. For example, suppose an aspect propagates transitively through attribute `deps` and it is applied to target `alpha`. Suppose `alpha` has `deps = [':beta\_output']`, where `beta\_output` is a declared output of a target `beta`. Suppose `beta` has a target `charlie` as one of its `deps`. If `apply\_to\_generating\_rules=True` for the aspect, then the aspect will propagate through `alpha`, `beta`, and `charlie`. If False, then the aspect will propagate only to `alpha`.  False by default. |
+| `exec_compatible_with` | [sequence](/versions/8.1.1/rules/lib/core/list) of [string](/versions/8.1.1/rules/lib/core/string)s; default is `[]`  A list of constraints on the execution platform that apply to all instances of this aspect. |
+| `exec_groups` | [dict](/versions/8.1.1/rules/lib/core/dict); or `None`; default is `None`  Dict of execution group name (string) to [`exec_group`s](/versions/8.1.1/rules/lib/globals/bzl#exec_group). If set, allows aspects to run actions on multiple execution platforms within a single instance. See [execution groups documentation](/versions/8.1.1/reference/exec-groups) for more info. |
+| `subrules` | [sequence](/versions/8.1.1/rules/lib/core/list) of [Subrule](/versions/8.1.1/rules/lib/builtins/Subrule)s; default is `[]`  Experimental: list of subrules used by this aspect. |
 
 ## configuration\_field
 
@@ -74,7 +74,7 @@ Creates a new aspect. The result of this function must be stored in a global val
 LateBoundDefault configuration_field(fragment, name)
 ```
 
-References a late-bound default value for an attribute of type [label](../toplevel/attr#label). A value is 'late-bound' if it requires the configuration to be built before determining the value. Any attribute using this as a value must [be private](https://bazel.build/versions/8.1.1/extending/rules#private-attributes).
+References a late-bound default value for an attribute of type [label](/versions/8.1.1/rules/lib/toplevel/attr#label). A value is 'late-bound' if it requires the configuration to be built before determining the value. Any attribute using this as a value must [be private](https://bazel.build/versions/8.1.1/extending/rules#private-attributes).
 
 Example usage:
 
@@ -96,8 +96,8 @@ Accessing in rule implementation:
 
 | Parameter | Description |
 | --- | --- |
-| `fragment` | [string](../core/string); required |
-| `name` | [string](../core/string); required |
+| `fragment` | [string](/versions/8.1.1/rules/lib/core/string); required |
+| `name` | [string](/versions/8.1.1/rules/lib/core/string); required |
 
 ## depset
 
@@ -105,7 +105,7 @@ Accessing in rule implementation:
 depset depset(direct=None, order="default", *, transitive=None)
 ```
 
-Creates a [depset](../builtins/depset). The `direct` parameter is a list of direct elements of the depset, and `transitive` parameter is a list of depsets whose elements become indirect elements of the created depset. The order in which elements are returned when the depset is converted to a list is specified by the `order` parameter. See the [Depsets overview](https://bazel.build/versions/8.1.1/extending/depsets) for more information.
+Creates a [depset](/versions/8.1.1/rules/lib/builtins/depset). The `direct` parameter is a list of direct elements of the depset, and `transitive` parameter is a list of depsets whose elements become indirect elements of the created depset. The order in which elements are returned when the depset is converted to a list is specified by the `order` parameter. See the [Depsets overview](https://bazel.build/versions/8.1.1/extending/depsets) for more information.
 
 All elements (direct and indirect) of a depset must be of the same type, as obtained by the expression `type(x)`.
 
@@ -119,9 +119,9 @@ The order of the created depset should be *compatible* with the order of its `tr
 
 | Parameter | Description |
 | --- | --- |
-| `direct` | [sequence](../core/list); or `None`; default is `None`  A list of *direct* elements of a depset. |
-| `order` | [string](../core/string); default is `"default"`  The traversal strategy for the new depset. See [here](../builtins/depset) for the possible values. |
-| `transitive` | [sequence](../core/list) of [depset](../builtins/depset)s; or `None`; default is `None`  A list of depsets whose elements will become indirect elements of the depset. |
+| `direct` | [sequence](/versions/8.1.1/rules/lib/core/list); or `None`; default is `None`  A list of *direct* elements of a depset. |
+| `order` | [string](/versions/8.1.1/rules/lib/core/string); default is `"default"`  The traversal strategy for the new depset. See [here](/versions/8.1.1/rules/lib/builtins/depset) for the possible values. |
+| `transitive` | [sequence](/versions/8.1.1/rules/lib/core/list) of [depset](/versions/8.1.1/rules/lib/builtins/depset)s; or `None`; default is `None`  A list of depsets whose elements will become indirect elements of the depset. |
 
 ## exec\_group
 
@@ -135,8 +135,8 @@ Creates an [execution group](/versions/8.1.1/reference/exec-groups) which can be
 
 | Parameter | Description |
 | --- | --- |
-| `toolchains` | [sequence](../core/list); default is `[]`  The set of toolchains this execution group requires. The list can contain String, Label, or StarlarkToolchainTypeApi objects, in any combination. |
-| `exec_compatible_with` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  A list of constraints on the execution platform. |
+| `toolchains` | [sequence](/versions/8.1.1/rules/lib/core/list); default is `[]`  The set of toolchains this execution group requires. The list can contain String, Label, or StarlarkToolchainTypeApi objects, in any combination. |
+| `exec_compatible_with` | [sequence](/versions/8.1.1/rules/lib/core/list) of [string](/versions/8.1.1/rules/lib/core/string)s; default is `[]`  A list of constraints on the execution platform. |
 
 ## exec\_transition
 
@@ -144,15 +144,15 @@ Creates an [execution group](/versions/8.1.1/reference/exec-groups) which can be
 transition exec_transition(implementation, inputs, outputs)
 ```
 
-A specialized version of [`transition()`](../builtins/transition) used to define the exec transition. See its documentation (or its implementation) for best practices. Only usable from the Bazel builtins.
+A specialized version of [`transition()`](/versions/8.1.1/rules/lib/builtins/transition) used to define the exec transition. See its documentation (or its implementation) for best practices. Only usable from the Bazel builtins.
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
 | `implementation` | callable; required |
-| `inputs` | [sequence](../core/list) of [string](../core/string)s; required |
-| `outputs` | [sequence](../core/list) of [string](../core/string)s; required |
+| `inputs` | [sequence](/versions/8.1.1/rules/lib/core/list) of [string](/versions/8.1.1/rules/lib/core/string)s; required |
+| `outputs` | [sequence](/versions/8.1.1/rules/lib/core/list) of [string](/versions/8.1.1/rules/lib/core/string)s; required |
 
 ## macro
 
@@ -173,11 +173,11 @@ macros.
 
 | Parameter | Description |
 | --- | --- |
-| `implementation` | [function](../core/function); required  The Starlark function implementing this macro. The values of the macro's attributes are passed to the implementation function as keyword arguments. The implementation function must have at least two named parameters, `name` and `visibility`, and if the macro inherits attributes (see `inherit_attrs` below), it must have a `**kwargs` residual keyword parameter. By convention, the implementation function should have a named parameter for any attribute that the macro needs to examine, modify, or pass to non-"main" targets, while the "bulk" inherited attributes which will be passed to the "main" target unchanged are passed as `**kwargs`. The implementation function must not return a value. Instead, the implementation function *declares targets* by calling rule or macro symbols. The name of any target or inner symbolic macro declared by a symbolic macro (including by any Starlark function that the macro's implementation function transitively calls) must either equal `name` (this is referred to as the "main" target) or start with `name`, followed by a separator chracter (`"_"`, `"-"`, or `"."`) and a string suffix. (Targets violating this naming scheme are allowed to be declared, but cannot be built, configured, or depended upon.) By default, targets declared by a symbolic macro (including by any Starlark function that the macro's implementation function transitively calls) are visible only in the package containing the .bzl file defining the macro. To declare targets visible externally, *including to the caller of the symbolic macro*, the implementation function must set `visibility` appropriately – typically, by passing `visibility = visibility` to the rule or macro symbol being called. The following APIs are unavailable within a macro implementation function and any Starlark function it transitively calls:  * [`package()`, `licenses()`* `environment_group()`* [`native.glob()`](../toplevel/native#glob) – instead, you may pass       a glob into the macro via a label list attribute* [`native.subpackages()`](../toplevel/native#subpackages)* (allowed in rule finalizers only, see `finalizer` below)           [`native.existing_rules()`](../toplevel/native#existing_rules),           [`native.existing_rule()`](../toplevel/native#existing_rule)* (for `WORKSPACE` threads)             [`workspace()`](../globals/workspace#workspace),             [`register_toolchains()`](../globals/workspace#register_toolchains),             [`bind()`](../globals/workspace#register_execution_platforms>register_execution_platforms(), ), [repository rule instantiation](/versions/8.1.1/extending/rules#repository-rule-instantiation),/reference/be/functions#package) |
-| `attrs` | [dict](../core/dict); default is `{}`  A dictionary of the attributes this macro supports, analogous to [rule.attrs](#rule.attrs). Keys are attribute names, and values are either attribute objects like `attr.label_list(...)` (see the [attr](../toplevel/attr) module), or `None`. A `None` entry means that the macro does not have an attribute by that name, even if it would have otherwise inherited one via `inherit_attrs` (see below). The special `name` attribute is predeclared and must not be included in the dictionary. The `visibility` attribute name is reserved and must not be included in the dictionary. Attributes whose names start with `_` are private -- they cannot be passed at the call site of the rule. Such attributes can be assigned a default value (as in `attr.label(default="//pkg:foo")`) to create an implicit dependency on a label. To limit memory usage, there is a cap on the number of attributes that may be declared. |
-| `inherit_attrs` | [rule](../builtins/rule); or [macro](../builtins/macro); or [string](../core/string); or `None`; default is `None`  A rule symbol, macro symbol, or the name of a built-in common attribute list (see below) from which the macro should inherit attributes. If `inherit_attrs` is set to the string `"common"`, the macro will inherit [common rule attribute definitions](/versions/8.1.1/reference/be/common-definitions#common-attributes) used by all Starlark rules. Note that if the return value of `rule()` or `macro()` was not assigned to a global variable in a .bzl file, then such a value has not been registered as a rule or macro symbol, and therefore cannot be used for `inherit_attrs`. The inheritance mechanism works as follows:   1. The special `name` and `visibility` attributes are never inherited;- Hidden attributes (ones whose name starts with `"_"`) are never inherited;- Attributes whose names are already defined in the `attrs` dictionary are never        inherited (the entry in `attrs` takes precedence; note that an entry may be set to        `None` to ensure that no attribute by that name gets defined on the macro);- All other attributes are inherited from the rule or macro and effectively merged into the          `attrs` dict.   When a non-mandatory attribute is inherited, the default value of the attribute is overridden to be `None`, regardless of what it was specified in the original rule or macro. This ensures that when the macro forwards the attribute's value to an instance of the wrapped rule or macro – such as by passing in the unmodified `**kwargs` – a value that was absent from the outer macro's call will also be absent in the inner rule or macro's call (since passing `None` to an attribute is treated the same as omitting the attribute). This is important because omitting an attribute has subtly different semantics from passing its apparent default value. In particular, omitted attributes are not shown in some `bazel query` output formats, and computed defaults only execute when the value is omitted. If the macro needs to examine or modify an inherited attribute – for example, to add a value to an inherited `tags` attribute – you must make sure to handle the `None` case in the macro's implementation function. For example, the following macro inherits all attributes from `native.cc_library`, except for `cxxopts` (which is removed from the attribute list) and `copts` (which is given a new definition). It also takes care to checks for the default `None` value of the inherited `tags` attribute before appending an additional tag.  ``` def _my_cc_library_impl(name, visibility, tags, **kwargs):     # Append a tag; tags attr was inherited from native.cc_library, and     # therefore is None unless explicitly set by the caller of my_cc_library()     my_tags = (tags or []) + ["my_custom_tag"]     native.cc_library(         name = name,         visibility = visibility,         tags = my_tags,         **kwargs     )  my_cc_library = macro(     implementation = _my_cc_library_impl,     inherit_attrs = native.cc_library,     attrs = {         "cxxopts": None,         "copts": attr.string_list(default = ["-D_FOO"]),     }, ) ```   If `inherit_attrs` is set, the macro's implementation function *must* have a `**kwargs` residual keyword parameter. By convention, a macro should pass inherited, non-overridden attributes unchanged to the "main" rule or macro symbol which the macro is wrapping. Typically, most inherited attributes will not have a parameter in the implementation function's parameter list, and will simply be passed via `**kwargs`. It can be convenient for the implementation function to have explicit parameters for some inherited attributes (most commonly, `tags` and `testonly`) if the macro needs to pass those attributes to both "main" and non-"main" targets – but if the macro also needs to examine or manipulate those attributes, you must take care to handle the `None` default value of non-mandatory inherited attributes. |
-| `finalizer` | [bool](../core/bool); default is `False`  Whether this macro is a rule finalizer, which is a macro that, regardless of its position in a `BUILD` file, is evaluated at the end of package loading, after all non-finalizer targets have been defined. Unlike ordinary symbolic macros, rule finalizers may call [`native.existing_rule()`](../toplevel/native#existing_rule) and [`native.existing_rules()`](../toplevel/native#existing_rules) to query the set of *non-finalizer* rule targets defined in the current package. Note that `native.existing_rule()` and `native.existing_rules()` cannot access the targets defined by any rule finalizer, including this one. |
-| `doc` | [string](../core/string); or `None`; default is `None`  A description of the macro that can be extracted by documentation generating tools. |
+| `implementation` | [function](/versions/8.1.1/rules/lib/core/function); required  The Starlark function implementing this macro. The values of the macro's attributes are passed to the implementation function as keyword arguments. The implementation function must have at least two named parameters, `name` and `visibility`, and if the macro inherits attributes (see `inherit_attrs` below), it must have a `**kwargs` residual keyword parameter. By convention, the implementation function should have a named parameter for any attribute that the macro needs to examine, modify, or pass to non-"main" targets, while the "bulk" inherited attributes which will be passed to the "main" target unchanged are passed as `**kwargs`. The implementation function must not return a value. Instead, the implementation function *declares targets* by calling rule or macro symbols. The name of any target or inner symbolic macro declared by a symbolic macro (including by any Starlark function that the macro's implementation function transitively calls) must either equal `name` (this is referred to as the "main" target) or start with `name`, followed by a separator chracter (`"_"`, `"-"`, or `"."`) and a string suffix. (Targets violating this naming scheme are allowed to be declared, but cannot be built, configured, or depended upon.) By default, targets declared by a symbolic macro (including by any Starlark function that the macro's implementation function transitively calls) are visible only in the package containing the .bzl file defining the macro. To declare targets visible externally, *including to the caller of the symbolic macro*, the implementation function must set `visibility` appropriately – typically, by passing `visibility = visibility` to the rule or macro symbol being called. The following APIs are unavailable within a macro implementation function and any Starlark function it transitively calls:  * [`package()`, `licenses()`* `environment_group()`* [`native.glob()`](/versions/8.1.1/rules/lib/toplevel/native#glob) – instead, you may pass       a glob into the macro via a label list attribute* [`native.subpackages()`](/versions/8.1.1/rules/lib/toplevel/native#subpackages)* (allowed in rule finalizers only, see `finalizer` below)           [`native.existing_rules()`](/versions/8.1.1/rules/lib/toplevel/native#existing_rules),           [`native.existing_rule()`](/versions/8.1.1/rules/lib/toplevel/native#existing_rule)* (for `WORKSPACE` threads)             [`workspace()`](/versions/8.1.1/rules/lib/globals/workspace#workspace),             [`register_toolchains()`](/versions/8.1.1/rules/lib/globals/workspace#register_toolchains),             [`bind()`](/versions/8.1.1/rules/lib/globals/workspace#register_execution_platforms>register_execution_platforms(), ), [repository rule instantiation](/versions/8.1.1/extending/rules#repository-rule-instantiation),/reference/be/functions#package) |
+| `attrs` | [dict](/versions/8.1.1/rules/lib/core/dict); default is `{}`  A dictionary of the attributes this macro supports, analogous to [rule.attrs](#rule.attrs). Keys are attribute names, and values are either attribute objects like `attr.label_list(...)` (see the [attr](/versions/8.1.1/rules/lib/toplevel/attr) module), or `None`. A `None` entry means that the macro does not have an attribute by that name, even if it would have otherwise inherited one via `inherit_attrs` (see below). The special `name` attribute is predeclared and must not be included in the dictionary. The `visibility` attribute name is reserved and must not be included in the dictionary. Attributes whose names start with `_` are private -- they cannot be passed at the call site of the rule. Such attributes can be assigned a default value (as in `attr.label(default="//pkg:foo")`) to create an implicit dependency on a label. To limit memory usage, there is a cap on the number of attributes that may be declared. |
+| `inherit_attrs` | [rule](/versions/8.1.1/rules/lib/builtins/rule); or [macro](/versions/8.1.1/rules/lib/builtins/macro); or [string](/versions/8.1.1/rules/lib/core/string); or `None`; default is `None`  A rule symbol, macro symbol, or the name of a built-in common attribute list (see below) from which the macro should inherit attributes. If `inherit_attrs` is set to the string `"common"`, the macro will inherit [common rule attribute definitions](/versions/8.1.1/reference/be/common-definitions#common-attributes) used by all Starlark rules. Note that if the return value of `rule()` or `macro()` was not assigned to a global variable in a .bzl file, then such a value has not been registered as a rule or macro symbol, and therefore cannot be used for `inherit_attrs`. The inheritance mechanism works as follows:   1. The special `name` and `visibility` attributes are never inherited;- Hidden attributes (ones whose name starts with `"_"`) are never inherited;- Attributes whose names are already defined in the `attrs` dictionary are never        inherited (the entry in `attrs` takes precedence; note that an entry may be set to        `None` to ensure that no attribute by that name gets defined on the macro);- All other attributes are inherited from the rule or macro and effectively merged into the          `attrs` dict.   When a non-mandatory attribute is inherited, the default value of the attribute is overridden to be `None`, regardless of what it was specified in the original rule or macro. This ensures that when the macro forwards the attribute's value to an instance of the wrapped rule or macro – such as by passing in the unmodified `**kwargs` – a value that was absent from the outer macro's call will also be absent in the inner rule or macro's call (since passing `None` to an attribute is treated the same as omitting the attribute). This is important because omitting an attribute has subtly different semantics from passing its apparent default value. In particular, omitted attributes are not shown in some `bazel query` output formats, and computed defaults only execute when the value is omitted. If the macro needs to examine or modify an inherited attribute – for example, to add a value to an inherited `tags` attribute – you must make sure to handle the `None` case in the macro's implementation function. For example, the following macro inherits all attributes from `native.cc_library`, except for `cxxopts` (which is removed from the attribute list) and `copts` (which is given a new definition). It also takes care to checks for the default `None` value of the inherited `tags` attribute before appending an additional tag.  ``` def _my_cc_library_impl(name, visibility, tags, **kwargs):     # Append a tag; tags attr was inherited from native.cc_library, and     # therefore is None unless explicitly set by the caller of my_cc_library()     my_tags = (tags or []) + ["my_custom_tag"]     native.cc_library(         name = name,         visibility = visibility,         tags = my_tags,         **kwargs     )  my_cc_library = macro(     implementation = _my_cc_library_impl,     inherit_attrs = native.cc_library,     attrs = {         "cxxopts": None,         "copts": attr.string_list(default = ["-D_FOO"]),     }, ) ```   If `inherit_attrs` is set, the macro's implementation function *must* have a `**kwargs` residual keyword parameter. By convention, a macro should pass inherited, non-overridden attributes unchanged to the "main" rule or macro symbol which the macro is wrapping. Typically, most inherited attributes will not have a parameter in the implementation function's parameter list, and will simply be passed via `**kwargs`. It can be convenient for the implementation function to have explicit parameters for some inherited attributes (most commonly, `tags` and `testonly`) if the macro needs to pass those attributes to both "main" and non-"main" targets – but if the macro also needs to examine or manipulate those attributes, you must take care to handle the `None` default value of non-mandatory inherited attributes. |
+| `finalizer` | [bool](/versions/8.1.1/rules/lib/core/bool); default is `False`  Whether this macro is a rule finalizer, which is a macro that, regardless of its position in a `BUILD` file, is evaluated at the end of package loading, after all non-finalizer targets have been defined. Unlike ordinary symbolic macros, rule finalizers may call [`native.existing_rule()`](/versions/8.1.1/rules/lib/toplevel/native#existing_rule) and [`native.existing_rules()`](/versions/8.1.1/rules/lib/toplevel/native#existing_rules) to query the set of *non-finalizer* rule targets defined in the current package. Note that `native.existing_rule()` and `native.existing_rules()` cannot access the targets defined by any rule finalizer, including this one. |
+| `doc` | [string](/versions/8.1.1/rules/lib/core/string); or `None`; default is `None`  A description of the macro that can be extracted by documentation generating tools. |
 
 ## module\_extension
 
@@ -192,11 +192,11 @@ Creates a new module extension. Store it in a global value, so that it can be ex
 | Parameter | Description |
 | --- | --- |
 | `implementation` | callable; required  The function that implements this module extension. Must take a single parameter, `module_ctx`. The function is called once at the beginning of a build to determine the set of available repos. |
-| `tag_classes` | [dict](../core/dict); default is `{}`  A dictionary to declare all the tag classes used by the extension. It maps from the name of the tag class to a `tag_class` object. |
-| `doc` | [string](../core/string); or `None`; default is `None`  A description of the module extension that can be extracted by documentation generating tools. |
-| `environ` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  Provides a list of environment variable that this module extension depends on. If an environment variable in that list changes, the extension will be re-evaluated. |
-| `os_dependent` | [bool](../core/bool); default is `False`  Indicates whether this extension is OS-dependent or not |
-| `arch_dependent` | [bool](../core/bool); default is `False`  Indicates whether this extension is architecture-dependent or not |
+| `tag_classes` | [dict](/versions/8.1.1/rules/lib/core/dict); default is `{}`  A dictionary to declare all the tag classes used by the extension. It maps from the name of the tag class to a `tag_class` object. |
+| `doc` | [string](/versions/8.1.1/rules/lib/core/string); or `None`; default is `None`  A description of the module extension that can be extracted by documentation generating tools. |
+| `environ` | [sequence](/versions/8.1.1/rules/lib/core/list) of [string](/versions/8.1.1/rules/lib/core/string)s; default is `[]`  Provides a list of environment variable that this module extension depends on. If an environment variable in that list changes, the extension will be re-evaluated. |
+| `os_dependent` | [bool](/versions/8.1.1/rules/lib/core/bool); default is `False`  Indicates whether this extension is OS-dependent or not |
+| `arch_dependent` | [bool](/versions/8.1.1/rules/lib/core/bool); default is `False`  Indicates whether this extension is architecture-dependent or not |
 
 ## provider
 
@@ -219,16 +219,16 @@ def _my_library_impl(ctx):
 
 See [Rules (Providers)](https://bazel.build/versions/8.1.1/extending/rules#providers) for a comprehensive guide on how to use providers.
 
-Returns a [`Provider`](../builtins/Provider) callable value if `init` is not specified.
+Returns a [`Provider`](/versions/8.1.1/rules/lib/builtins/Provider) callable value if `init` is not specified.
 
-If `init` is specified, returns a tuple of 2 elements: a [`Provider`](../builtins/Provider) callable value and a *raw constructor* callable value. See  [Rules (Custom initialization of custom providers)](https://bazel.build/versions/8.1.1/extending/rules#custom_initialization_of_providers) and the discussion of the `init` parameter below for details.
+If `init` is specified, returns a tuple of 2 elements: a [`Provider`](/versions/8.1.1/rules/lib/builtins/Provider) callable value and a *raw constructor* callable value. See  [Rules (Custom initialization of custom providers)](https://bazel.build/versions/8.1.1/extending/rules#custom_initialization_of_providers) and the discussion of the `init` parameter below for details.
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `doc` | [string](../core/string); or `None`; default is `None` |
-| `fields` | [sequence](../core/list) of [string](../core/string)s; or [dict](../core/dict); or `None`; default is `None`  If specified, restricts the set of allowed fields.  Possible values are:  * list of fields:     ```   provider(fields = ['a', 'b'])   ```     * dictionary field name -> documentation:       ```     provider(            fields = { 'a' : 'Documentation for a', 'b' : 'Documentation for b' })     ```  All fields are optional. |
+| `doc` | [string](/versions/8.1.1/rules/lib/core/string); or `None`; default is `None` |
+| `fields` | [sequence](/versions/8.1.1/rules/lib/core/list) of [string](/versions/8.1.1/rules/lib/core/string)s; or [dict](/versions/8.1.1/rules/lib/core/dict); or `None`; default is `None`  If specified, restricts the set of allowed fields.  Possible values are:  * list of fields:     ```   provider(fields = ['a', 'b'])   ```     * dictionary field name -> documentation:       ```     provider(            fields = { 'a' : 'Documentation for a', 'b' : 'Documentation for b' })     ```  All fields are optional. |
 | `init` | callable; or `None`; default is `None` |
 
 ## repository\_rule
@@ -237,19 +237,19 @@ If `init` is specified, returns a tuple of 2 elements: a [`Provider`](../builtin
 callable repository_rule(implementation, *, attrs=None, local=False, environ=[], configure=False, remotable=False, doc=None)
 ```
 
-Creates a new repository rule. Store it in a global value, so that it can be loaded and called from a [`module_extension()`](#module_extension) implementation function, or used by [`use_repo_rule()`](../globals/module#use_repo_rule).
+Creates a new repository rule. Store it in a global value, so that it can be loaded and called from a [`module_extension()`](#module_extension) implementation function, or used by [`use_repo_rule()`](/versions/8.1.1/rules/lib/globals/module#use_repo_rule).
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
 | `implementation` | callable; required |
-| `attrs` | [dict](../core/dict); or `None`; default is `None` |
-| `local` | [bool](../core/bool); default is `False`  Indicate that this rule fetches everything from the local system and should be reevaluated at every fetch. |
-| `environ` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  **Deprecated**. This parameter has been deprecated. Migrate to `repository_ctx.getenv` instead. Provides a list of environment variable that this repository rule depends on. If an environment variable in that list change, the repository will be refetched. |
-| `configure` | [bool](../core/bool); default is `False`  Indicate that the repository inspects the system for configuration purpose |
-| `remotable` | [bool](../core/bool); default is `False`  **Experimental**. This parameter is experimental and may change at any time. Please do not depend on it. It may be enabled on an experimental basis by setting `--experimental_repo_remote_exec`  Compatible with remote execution |
-| `doc` | [string](../core/string); or `None`; default is `None` |
+| `attrs` | [dict](/versions/8.1.1/rules/lib/core/dict); or `None`; default is `None` |
+| `local` | [bool](/versions/8.1.1/rules/lib/core/bool); default is `False`  Indicate that this rule fetches everything from the local system and should be reevaluated at every fetch. |
+| `environ` | [sequence](/versions/8.1.1/rules/lib/core/list) of [string](/versions/8.1.1/rules/lib/core/string)s; default is `[]`  **Deprecated**. This parameter has been deprecated. Migrate to `repository_ctx.getenv` instead. Provides a list of environment variable that this repository rule depends on. If an environment variable in that list change, the repository will be refetched. |
+| `configure` | [bool](/versions/8.1.1/rules/lib/core/bool); default is `False`  Indicate that the repository inspects the system for configuration purpose |
+| `remotable` | [bool](/versions/8.1.1/rules/lib/core/bool); default is `False`  **Experimental**. This parameter is experimental and may change at any time. Please do not depend on it. It may be enabled on an experimental basis by setting `--experimental_repo_remote_exec`  Compatible with remote execution |
+| `doc` | [string](/versions/8.1.1/rules/lib/core/string); or `None`; default is `None` |
 
 ## rule
 
@@ -267,29 +267,29 @@ Test rules are required to have a name ending in `_test`, while all other rules
 
 | Parameter | Description |
 | --- | --- |
-| `implementation` | [function](../core/function); required  the Starlark function implementing this rule, must have exactly one parameter: [ctx](../builtins/ctx). The function is called during the analysis phase for each instance of the rule. It can access the attributes provided by the user. It must create actions to generate all the declared outputs. |
-| `test` | [bool](../core/bool); default is `unbound`  Whether this rule is a test rule, that is, whether it may be the subject of a `blaze test` command. All test rules are automatically considered [executable](#rule.executable); it is unnecessary (and discouraged) to explicitly set `executable = True` for a test rule. The value defaults to `False`. See the  [Rules page](https://bazel.build/versions/8.1.1/extending/rules#executable_rules_and_test_rules) for more information. |
-| `attrs` | [dict](../core/dict); default is `{}`  A dictionary to declare all the attributes of the rule. It maps from an attribute name to an attribute object (see [`attr`](../toplevel/attr) module). Attributes starting with `_` are private, and can be used to add an implicit dependency on a label. The attribute `name` is implicitly added and must not be specified. Attributes `visibility`, `deprecation`, `tags`, `testonly`, and `features` are implicitly added and cannot be overridden. Most rules need only a handful of attributes. To limit memory usage, there is a cap on the number of attributes that may be declared. Declared attributes will convert `None` to the default value. |
-| `outputs` | [dict](../core/dict); or `None`; or [function](../core/function); default is `None`  **Deprecated**. This parameter is deprecated and will be removed soon. Please do not depend on it. It is *disabled* with `--incompatible_no_rule_outputs_param`. Use this flag to verify your code is compatible with its imminent removal.  This parameter has been deprecated. Migrate rules to use `OutputGroupInfo` or `attr.output` instead. A schema for defining predeclared outputs. Unlike [`output`](../toplevel/attr#output) and [`output_list`](../toplevel/attr#output_list) attributes, the user does not specify the labels for these files. See the [Rules page](https://bazel.build/versions/8.1.1/extending/rules#files) for more on predeclared outputs. The value of this argument is either a dictionary or a callback function that produces a dictionary. The callback works similar to computed dependency attributes: The function's parameter names are matched against the rule's attributes, so for example if you pass `outputs = _my_func` with the definition `def _my_func(srcs, deps): ...`, the function has access to the attributes `srcs` and `deps`. Whether the dictionary is specified directly or via a function, it is interpreted as follows. Each entry in the dictionary creates a predeclared output where the key is an identifier and the value is a string template that determines the output's label. In the rule's implementation function, the identifier becomes the field name used to access the output's [`File`](../builtins/File) in [`ctx.outputs`](../builtins/ctx#outputs). The output's label has the same package as the rule, and the part after the package is produced by substituting each placeholder of the form `"%{ATTR}"` with a string formed from the value of the attribute `ATTR`:  * String-typed attributes are substituted verbatim.* Label-typed attributes become the part of the label after the package, minus the file extension. For example, the label `"//pkg:a/b.c"` becomes `"a/b"`.* Output-typed attributes become the part of the label after the package, including the file extension (for the above example, `"a/b.c"`).* All list-typed attributes (for example, `attr.label_list`) used in placeholders are required to have *exactly one element*. Their conversion is the same as their non-list version (`attr.label`).* Other attribute types may not appear in placeholders.* The special non-attribute placeholders `%{dirname}` and `%{basename}` expand to those parts of the rule's label, excluding its package. For example, in `"//pkg:a/b.c"`, the dirname is `a` and the basename is `b.c`.   In practice, the most common substitution placeholder is `"%{name}"`. For example, for a target named "foo", the outputs dict `{"bin": "%{name}.exe"}` predeclares an output named `foo.exe` that is accessible in the implementation function as `ctx.outputs.bin`. |
-| `executable` | [bool](../core/bool); default is `unbound` |
-| `output_to_genfiles` | [bool](../core/bool); default is `False`  If true, the files will be generated in the genfiles directory instead of the bin directory. Unless you need it for compatibility with existing rules (e.g. when generating header files for C++), do not set this flag. |
-| `fragments` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  List of names of configuration fragments that the rule requires in target configuration. |
-| `host_fragments` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  List of names of configuration fragments that the rule requires in host configuration. |
-| `_skylark_testable` | [bool](../core/bool); default is `False`  *(Experimental)*  If true, this rule will expose its actions for inspection by rules that depend on it via an `Actions` provider. The provider is also available to the rule itself by calling [ctx.created\_actions()](../builtins/ctx#created_actions).  This should only be used for testing the analysis-time behavior of Starlark rules. This flag may be removed in the future. |
-| `toolchains` | [sequence](../core/list); default is `[]`  If set, the set of toolchains this rule requires. The list can contain String, Label, or StarlarkToolchainTypeApi objects, in any combination. Toolchains will be found by checking the current platform, and provided to the rule implementation via `ctx.toolchain`. |
-| `incompatible_use_toolchain_transition` | [bool](../core/bool); default is `False`  Deprecated, this is no longer in use and should be removed. |
-| `doc` | [string](../core/string); or `None`; default is `None`  A description of the rule that can be extracted by documentation generating tools. |
-| `provides` | [sequence](../core/list); default is `[]`  A list of providers that the implementation function must return. It is an error if the implementation function omits any of the types of providers listed here from its return value. However, the implementation function may return additional providers not listed here. Each element of the list is an `*Info` object returned by [`provider()`](../globals/bzl#provider), except that a legacy provider is represented by its string name instead.When a target of the rule is used as a dependency for a target that declares a required provider, it is not necessary to specify that provider here. It is enough that the implementation function returns it. However, it is considered best practice to specify it, even though this is not required. The [`required_providers`](../globals/bzl#aspect.required_providers) field of an [aspect](../globals/bzl#aspect) does, however, require that providers are specified here. |
-| `dependency_resolution_rule` | [bool](../core/bool); default is `False`  If set, the rule can be a dependency through attributes also marked as available in materializers. Every attribute of rules with this flag set must be marked as available in materializers also. This is so that rules so marked cannot depend on rules that are not so marked. |
-| `exec_compatible_with` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  A list of constraints on the execution platform that apply to all targets of this rule type. |
-| `analysis_test` | [bool](../core/bool); default is `False`  If true, then this rule is treated as an analysis test. Note: Analysis test rules are primarily defined using infrastructure provided in core Starlark libraries. See [Testing](https://bazel.build/versions/8.1.1/rules/testing#testing-rules) for guidance. If a rule is defined as an analysis test rule, it becomes allowed to use configuration transitions defined using [analysis\_test\_transition](#analysis_test_transition) on its attributes, but opts into some restrictions:  * Targets of this rule are limited in the number of transitive dependencies they may have.* The rule is considered a test rule (as if `test=True` were set). This supersedes the value of `test`   * The rule implementation function may not register actions. Instead, it must register a pass/fail result via providing [AnalysisTestResultInfo](../providers/AnalysisTestResultInfo). |
-| `build_setting` | [BuildSetting](../builtins/BuildSetting); or `None`; default is `None`  If set, describes what kind of [`build setting`](/versions/8.1.1/rules/config#user-defined-build-settings) this rule is. See the [`config`](../toplevel/config) module. If this is set, a mandatory attribute named "build\_setting\_default" is automatically added to this rule, with a type corresponding to the value passed in here. |
+| `implementation` | [function](/versions/8.1.1/rules/lib/core/function); required  the Starlark function implementing this rule, must have exactly one parameter: [ctx](/versions/8.1.1/rules/lib/builtins/ctx). The function is called during the analysis phase for each instance of the rule. It can access the attributes provided by the user. It must create actions to generate all the declared outputs. |
+| `test` | [bool](/versions/8.1.1/rules/lib/core/bool); default is `unbound`  Whether this rule is a test rule, that is, whether it may be the subject of a `blaze test` command. All test rules are automatically considered [executable](#rule.executable); it is unnecessary (and discouraged) to explicitly set `executable = True` for a test rule. The value defaults to `False`. See the  [Rules page](https://bazel.build/versions/8.1.1/extending/rules#executable_rules_and_test_rules) for more information. |
+| `attrs` | [dict](/versions/8.1.1/rules/lib/core/dict); default is `{}`  A dictionary to declare all the attributes of the rule. It maps from an attribute name to an attribute object (see [`attr`](/versions/8.1.1/rules/lib/toplevel/attr) module). Attributes starting with `_` are private, and can be used to add an implicit dependency on a label. The attribute `name` is implicitly added and must not be specified. Attributes `visibility`, `deprecation`, `tags`, `testonly`, and `features` are implicitly added and cannot be overridden. Most rules need only a handful of attributes. To limit memory usage, there is a cap on the number of attributes that may be declared. Declared attributes will convert `None` to the default value. |
+| `outputs` | [dict](/versions/8.1.1/rules/lib/core/dict); or `None`; or [function](/versions/8.1.1/rules/lib/core/function); default is `None`  **Deprecated**. This parameter is deprecated and will be removed soon. Please do not depend on it. It is *disabled* with `--incompatible_no_rule_outputs_param`. Use this flag to verify your code is compatible with its imminent removal.  This parameter has been deprecated. Migrate rules to use `OutputGroupInfo` or `attr.output` instead. A schema for defining predeclared outputs. Unlike [`output`](/versions/8.1.1/rules/lib/toplevel/attr#output) and [`output_list`](/versions/8.1.1/rules/lib/toplevel/attr#output_list) attributes, the user does not specify the labels for these files. See the [Rules page](https://bazel.build/versions/8.1.1/extending/rules#files) for more on predeclared outputs. The value of this argument is either a dictionary or a callback function that produces a dictionary. The callback works similar to computed dependency attributes: The function's parameter names are matched against the rule's attributes, so for example if you pass `outputs = _my_func` with the definition `def _my_func(srcs, deps): ...`, the function has access to the attributes `srcs` and `deps`. Whether the dictionary is specified directly or via a function, it is interpreted as follows. Each entry in the dictionary creates a predeclared output where the key is an identifier and the value is a string template that determines the output's label. In the rule's implementation function, the identifier becomes the field name used to access the output's [`File`](/versions/8.1.1/rules/lib/builtins/File) in [`ctx.outputs`](/versions/8.1.1/rules/lib/builtins/ctx#outputs). The output's label has the same package as the rule, and the part after the package is produced by substituting each placeholder of the form `"%{ATTR}"` with a string formed from the value of the attribute `ATTR`:  * String-typed attributes are substituted verbatim.* Label-typed attributes become the part of the label after the package, minus the file extension. For example, the label `"//pkg:a/b.c"` becomes `"a/b"`.* Output-typed attributes become the part of the label after the package, including the file extension (for the above example, `"a/b.c"`).* All list-typed attributes (for example, `attr.label_list`) used in placeholders are required to have *exactly one element*. Their conversion is the same as their non-list version (`attr.label`).* Other attribute types may not appear in placeholders.* The special non-attribute placeholders `%{dirname}` and `%{basename}` expand to those parts of the rule's label, excluding its package. For example, in `"//pkg:a/b.c"`, the dirname is `a` and the basename is `b.c`.   In practice, the most common substitution placeholder is `"%{name}"`. For example, for a target named "foo", the outputs dict `{"bin": "%{name}.exe"}` predeclares an output named `foo.exe` that is accessible in the implementation function as `ctx.outputs.bin`. |
+| `executable` | [bool](/versions/8.1.1/rules/lib/core/bool); default is `unbound` |
+| `output_to_genfiles` | [bool](/versions/8.1.1/rules/lib/core/bool); default is `False`  If true, the files will be generated in the genfiles directory instead of the bin directory. Unless you need it for compatibility with existing rules (e.g. when generating header files for C++), do not set this flag. |
+| `fragments` | [sequence](/versions/8.1.1/rules/lib/core/list) of [string](/versions/8.1.1/rules/lib/core/string)s; default is `[]`  List of names of configuration fragments that the rule requires in target configuration. |
+| `host_fragments` | [sequence](/versions/8.1.1/rules/lib/core/list) of [string](/versions/8.1.1/rules/lib/core/string)s; default is `[]`  List of names of configuration fragments that the rule requires in host configuration. |
+| `_skylark_testable` | [bool](/versions/8.1.1/rules/lib/core/bool); default is `False`  *(Experimental)*  If true, this rule will expose its actions for inspection by rules that depend on it via an `Actions` provider. The provider is also available to the rule itself by calling [ctx.created\_actions()](/versions/8.1.1/rules/lib/builtins/ctx#created_actions).  This should only be used for testing the analysis-time behavior of Starlark rules. This flag may be removed in the future. |
+| `toolchains` | [sequence](/versions/8.1.1/rules/lib/core/list); default is `[]`  If set, the set of toolchains this rule requires. The list can contain String, Label, or StarlarkToolchainTypeApi objects, in any combination. Toolchains will be found by checking the current platform, and provided to the rule implementation via `ctx.toolchain`. |
+| `incompatible_use_toolchain_transition` | [bool](/versions/8.1.1/rules/lib/core/bool); default is `False`  Deprecated, this is no longer in use and should be removed. |
+| `doc` | [string](/versions/8.1.1/rules/lib/core/string); or `None`; default is `None`  A description of the rule that can be extracted by documentation generating tools. |
+| `provides` | [sequence](/versions/8.1.1/rules/lib/core/list); default is `[]`  A list of providers that the implementation function must return. It is an error if the implementation function omits any of the types of providers listed here from its return value. However, the implementation function may return additional providers not listed here. Each element of the list is an `*Info` object returned by [`provider()`](/versions/8.1.1/rules/lib/globals/bzl#provider), except that a legacy provider is represented by its string name instead.When a target of the rule is used as a dependency for a target that declares a required provider, it is not necessary to specify that provider here. It is enough that the implementation function returns it. However, it is considered best practice to specify it, even though this is not required. The [`required_providers`](/versions/8.1.1/rules/lib/globals/bzl#aspect.required_providers) field of an [aspect](/versions/8.1.1/rules/lib/globals/bzl#aspect) does, however, require that providers are specified here. |
+| `dependency_resolution_rule` | [bool](/versions/8.1.1/rules/lib/core/bool); default is `False`  If set, the rule can be a dependency through attributes also marked as available in materializers. Every attribute of rules with this flag set must be marked as available in materializers also. This is so that rules so marked cannot depend on rules that are not so marked. |
+| `exec_compatible_with` | [sequence](/versions/8.1.1/rules/lib/core/list) of [string](/versions/8.1.1/rules/lib/core/string)s; default is `[]`  A list of constraints on the execution platform that apply to all targets of this rule type. |
+| `analysis_test` | [bool](/versions/8.1.1/rules/lib/core/bool); default is `False`  If true, then this rule is treated as an analysis test. Note: Analysis test rules are primarily defined using infrastructure provided in core Starlark libraries. See [Testing](https://bazel.build/versions/8.1.1/rules/testing#testing-rules) for guidance. If a rule is defined as an analysis test rule, it becomes allowed to use configuration transitions defined using [analysis\_test\_transition](#analysis_test_transition) on its attributes, but opts into some restrictions:  * Targets of this rule are limited in the number of transitive dependencies they may have.* The rule is considered a test rule (as if `test=True` were set). This supersedes the value of `test`   * The rule implementation function may not register actions. Instead, it must register a pass/fail result via providing [AnalysisTestResultInfo](/versions/8.1.1/rules/lib/providers/AnalysisTestResultInfo). |
+| `build_setting` | [BuildSetting](/versions/8.1.1/rules/lib/builtins/BuildSetting); or `None`; default is `None`  If set, describes what kind of [`build setting`](/versions/8.1.1/rules/config#user-defined-build-settings) this rule is. See the [`config`](/versions/8.1.1/rules/lib/toplevel/config) module. If this is set, a mandatory attribute named "build\_setting\_default" is automatically added to this rule, with a type corresponding to the value passed in here. |
 | `cfg` | default is `None`  If set, points to the configuration transition the rule will apply to its own configuration before analysis. |
-| `exec_groups` | [dict](../core/dict); or `None`; default is `None`  Dict of execution group name (string) to [`exec_group`s](../globals/bzl#exec_group). If set, allows rules to run actions on multiple execution platforms within a single target. See [execution groups documentation](/versions/8.1.1/reference/exec-groups) for more info. |
+| `exec_groups` | [dict](/versions/8.1.1/rules/lib/core/dict); or `None`; default is `None`  Dict of execution group name (string) to [`exec_group`s](/versions/8.1.1/rules/lib/globals/bzl#exec_group). If set, allows rules to run actions on multiple execution platforms within a single target. See [execution groups documentation](/versions/8.1.1/reference/exec-groups) for more info. |
 | `initializer` | default is `None`  Experimental: the Stalark function initializing the attributes of the rule. The function is called at load time for each instance of the rule. It's called with `name` and the values of public attributes defined by the rule (not with generic attributes, for example `tags`). It has to return a dictionary from the attribute names to the desired values. The attributes that are not returned are unaffected. Returning `None` as value results in using the default value specified in the attribute definition. Initializers are evaluated before the default values specified in an attribute definition. Consequently, if a parameter in the initializer's signature contains a default values, it overwrites the default from the attribute definition (except if returning `None`). Similarly, if a parameter in the initializer's signature doesn't have a default, the parameter will become mandatory. It's a good practice to omit default/mandatory settings on an attribute definition in such cases. It's a good practice to use `**kwargs` for attributes that are not handled. In case of extended rules, all initializers are called proceeding from child to ancestors. Each initializer is passed only the public attributes it knows about. |
 | `parent` | default is `None`  Experimental: the Stalark rule that is extended. When set the public attributes are merged as well as advertised providers. The rule matches `executable` and `test` from the parent. Values of `fragments`, `toolchains`, `exec_compatible_with`, and `exec_groups` are merged. Legacy or deprecated parameters may not be set. Incoming configuration transition `cfg` of parent is applied after thisrule's incoming configuration. |
-| `extendable` | [bool](../core/bool); or [Label](../builtins/Label); or [string](../core/string); or `None`; default is `None`  Experimental: A label of an allowlist defining which rules can extending this rule. It can be set also to True/False to always allow/disallow extending. Bazel defaults to always allowing extensions. |
-| `subrules` | [sequence](../core/list) of [Subrule](../builtins/Subrule)s; default is `[]`  Experimental: List of subrules used by this rule. |
+| `extendable` | [bool](/versions/8.1.1/rules/lib/core/bool); or [Label](/versions/8.1.1/rules/lib/builtins/Label); or [string](/versions/8.1.1/rules/lib/core/string); or `None`; default is `None`  Experimental: A label of an allowlist defining which rules can extending this rule. It can be set also to True/False to always allow/disallow extending. Bazel defaults to always allowing extensions. |
+| `subrules` | [sequence](/versions/8.1.1/rules/lib/core/list) of [Subrule](/versions/8.1.1/rules/lib/builtins/Subrule)s; default is `[]`  Experimental: List of subrules used by this rule. |
 
 ## select
 
@@ -303,8 +303,8 @@ unknown select(x, no_match_error='')
 
 | Parameter | Description |
 | --- | --- |
-| `x` | [dict](../core/dict); required  A dict that maps configuration conditions to values. Each key is a [Label](../builtins/Label) or a label string that identifies a config\_setting or constraint\_value instance. See the [documentation on macros](https://bazel.build/versions/8.1.1/rules/macros#label-resolution) for when to use a Label instead of a string. |
-| `no_match_error` | [string](../core/string); default is `''`  Optional custom error to report if no condition matches. |
+| `x` | [dict](/versions/8.1.1/rules/lib/core/dict); required  A dict that maps configuration conditions to values. Each key is a [Label](/versions/8.1.1/rules/lib/builtins/Label) or a label string that identifies a config\_setting or constraint\_value instance. See the [documentation on macros](https://bazel.build/versions/8.1.1/rules/macros#label-resolution) for when to use a Label instead of a string. |
+| `no_match_error` | [string](/versions/8.1.1/rules/lib/core/string); default is `''`  Optional custom error to report if no condition matches. |
 
 ## subrule
 
@@ -318,11 +318,11 @@ Constructs a new instance of a subrule. The result of this function must be stor
 
 | Parameter | Description |
 | --- | --- |
-| `implementation` | [function](../core/function); required  The Starlark function implementing this subrule |
-| `attrs` | [dict](../core/dict); default is `{}`  A dictionary to declare all the (private) attributes of the subrule.  Subrules may only have private attributes that are label-typed (i.e. label or label-list). The resolved values corresponding to these labels are automatically passed by Bazel to the subrule's implementation function as named arguments (thus the implementation function is required to accept named parameters matching the attribute names). The types of these values will be:  * `FilesToRunProvider` for label attributes with `executable=True` * `File` for label attributes with `allow_single_file=True` * `Target` for all other label attributes * `[Target]` for all label-list attributes |
-| `toolchains` | [sequence](../core/list); default is `[]`  If set, the set of toolchains this subrule requires. The list can contain String, Label, or StarlarkToolchainTypeApi objects, in any combination. Toolchains will be found by checking the current platform, and provided to the subrule implementation via `ctx.toolchains`. Note that AEGs need to be enabled on the consuming rule(s) if this parameter is set. In case you haven't migrated to AEGs yet, see https://bazel.build/extending/auto-exec-groups#migration-aegs. |
-| `fragments` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  List of names of configuration fragments that the subrule requires in target configuration. |
-| `subrules` | [sequence](../core/list) of [Subrule](../builtins/Subrule)s; default is `[]`  List of other subrules needed by this subrule. |
+| `implementation` | [function](/versions/8.1.1/rules/lib/core/function); required  The Starlark function implementing this subrule |
+| `attrs` | [dict](/versions/8.1.1/rules/lib/core/dict); default is `{}`  A dictionary to declare all the (private) attributes of the subrule.  Subrules may only have private attributes that are label-typed (i.e. label or label-list). The resolved values corresponding to these labels are automatically passed by Bazel to the subrule's implementation function as named arguments (thus the implementation function is required to accept named parameters matching the attribute names). The types of these values will be:  * `FilesToRunProvider` for label attributes with `executable=True` * `File` for label attributes with `allow_single_file=True` * `Target` for all other label attributes * `[Target]` for all label-list attributes |
+| `toolchains` | [sequence](/versions/8.1.1/rules/lib/core/list); default is `[]`  If set, the set of toolchains this subrule requires. The list can contain String, Label, or StarlarkToolchainTypeApi objects, in any combination. Toolchains will be found by checking the current platform, and provided to the subrule implementation via `ctx.toolchains`. Note that AEGs need to be enabled on the consuming rule(s) if this parameter is set. In case you haven't migrated to AEGs yet, see https://bazel.build/extending/auto-exec-groups#migration-aegs. |
+| `fragments` | [sequence](/versions/8.1.1/rules/lib/core/list) of [string](/versions/8.1.1/rules/lib/core/string)s; default is `[]`  List of names of configuration fragments that the subrule requires in target configuration. |
+| `subrules` | [sequence](/versions/8.1.1/rules/lib/core/list) of [Subrule](/versions/8.1.1/rules/lib/builtins/Subrule)s; default is `[]`  List of other subrules needed by this subrule. |
 
 ## tag\_class
 
@@ -336,8 +336,8 @@ Creates a new tag\_class object, which defines an attribute schema for a class o
 
 | Parameter | Description |
 | --- | --- |
-| `attrs` | [dict](../core/dict); default is `{}`  A dictionary to declare all the attributes of this tag class. It maps from an attribute name to an attribute object (see [attr](../toplevel/attr) module). Note that unlike [`rule()`](../globals/bzl#rule), [`aspect()`](../globals/bzl#aspect) and [`repository_rule()`](../globals/bzl#repository_rule), declared attributes will not convert `None` to the default value. For the default to be used, the attribute must be omitted entirely by the caller. |
-| `doc` | [string](../core/string); or `None`; default is `None`  A description of the tag class that can be extracted by documentation generating tools. |
+| `attrs` | [dict](/versions/8.1.1/rules/lib/core/dict); default is `{}`  A dictionary to declare all the attributes of this tag class. It maps from an attribute name to an attribute object (see [attr](/versions/8.1.1/rules/lib/toplevel/attr) module). Note that unlike [`rule()`](/versions/8.1.1/rules/lib/globals/bzl#rule), [`aspect()`](/versions/8.1.1/rules/lib/globals/bzl#aspect) and [`repository_rule()`](/versions/8.1.1/rules/lib/globals/bzl#repository_rule), declared attributes will not convert `None` to the default value. For the default to be used, the attribute must be omitted entirely by the caller. |
+| `doc` | [string](/versions/8.1.1/rules/lib/core/string); or `None`; default is `None`  A description of the tag class that can be extracted by documentation generating tools. |
 
 ## visibility
 
diff --git a/versions/8.1.1/rules/lib/globals/module.mdx b/versions/8.1.1/rules/lib/globals/module.mdx
index 8a381905..8f8b453d 100644
--- a/versions/8.1.1/rules/lib/globals/module.mdx
+++ b/versions/8.1.1/rules/lib/globals/module.mdx
@@ -30,7 +30,7 @@ None archive_override(module_name, **kwargs)
 
 Specifies that this dependency should come from an archive file (zip, gzip, etc) at a
 certain location, instead of from a registry. Effectively, this dependency will be
-backed by an [`http_archive`](../repo/http#http_archive) rule.
+backed by an [`http_archive`](/versions/8.1.1/rules/lib/repo/http#http_archive) rule.
 
 This directive only takes effect in the root module; in other words, if a module is
 used as a dependency by others, its own overrides are ignored.
@@ -39,7 +39,7 @@ used as a dependency by others, its own overrides are ignored.
 
 | Parameter | Description |
 | --- | --- |
-| `module_name` | [string](../core/string); required  The name of the Bazel module dependency to apply this override to. |
+| `module_name` | [string](/versions/8.1.1/rules/lib/core/string); required  The name of the Bazel module dependency to apply this override to. |
 | `kwargs` | required  All other arguments are forwarded to the underlying `http_archive` repo rule. Note that the `name` attribute shouldn't be specified; use `module_name` instead. |
 
 ## bazel\_dep
@@ -54,11 +54,11 @@ Declares a direct dependency on another Bazel module.
 
 | Parameter | Description |
 | --- | --- |
-| `name` | [string](../core/string); required  The name of the module to be added as a direct dependency. |
-| `version` | [string](../core/string); default is `''`  The version of the module to be added as a direct dependency. |
-| `max_compatibility_level` | [int](../core/int); default is `-1`  The maximum `compatibility_level` supported for the module to be added as a direct dependency. The version of the module implies the minimum compatibility\_level supported, as well as the maximum if this attribute is not specified. |
-| `repo_name` | [string](../core/string); default is `''`  The name of the external repo representing this dependency. This is by default the name of the module. |
-| `dev_dependency` | [bool](../core/bool); default is `False`  If true, this dependency will be ignored if the current module is not the root module or `--ignore\_dev\_dependency` is enabled. |
+| `name` | [string](/versions/8.1.1/rules/lib/core/string); required  The name of the module to be added as a direct dependency. |
+| `version` | [string](/versions/8.1.1/rules/lib/core/string); default is `''`  The version of the module to be added as a direct dependency. |
+| `max_compatibility_level` | [int](/versions/8.1.1/rules/lib/core/int); default is `-1`  The maximum `compatibility_level` supported for the module to be added as a direct dependency. The version of the module implies the minimum compatibility\_level supported, as well as the maximum if this attribute is not specified. |
+| `repo_name` | [string](/versions/8.1.1/rules/lib/core/string); default is `''`  The name of the external repo representing this dependency. This is by default the name of the module. |
+| `dev_dependency` | [bool](/versions/8.1.1/rules/lib/core/bool); default is `False`  If true, this dependency will be ignored if the current module is not the root module or `--ignore\_dev\_dependency` is enabled. |
 
 ## git\_override
 
@@ -68,7 +68,7 @@ None git_override(module_name, **kwargs)
 
 Specifies that this dependency should come from a certain commit in a Git repository,
 instead of from a registry. Effectively, this dependency will be backed by a
-[`git_repository`](../repo/git#git_repository) rule.
+[`git_repository`](/versions/8.1.1/rules/lib/repo/git#git_repository) rule.
 
 This directive only takes effect in the root module; in other words, if a module is
 used as a dependency by others, its own overrides are ignored.
@@ -77,7 +77,7 @@ used as a dependency by others, its own overrides are ignored.
 
 | Parameter | Description |
 | --- | --- |
-| `module_name` | [string](../core/string); required  The name of the Bazel module dependency to apply this override to. |
+| `module_name` | [string](/versions/8.1.1/rules/lib/core/string); required  The name of the Bazel module dependency to apply this override to. |
 | `kwargs` | required  All other arguments are forwarded to the underlying `git_repository` repo rule. Note that the `name` attribute shouldn't be specified; use `module_name` instead. |
 
 ## include
@@ -98,7 +98,7 @@ Only files in the main repo may be included.
 
 | Parameter | Description |
 | --- | --- |
-| `label` | [string](../core/string); required  The label pointing to the file to include. The label must point to a file in the main repo; in other words, it **must **start with double slashes (`//`). The name of the file must end with `.MODULE.bazel` and must not start with `.`.**** |
+| `label` | [string](/versions/8.1.1/rules/lib/core/string); required  The label pointing to the file to include. The label must point to a file in the main repo; in other words, it **must **start with double slashes (`//`). The name of the file must end with `.MODULE.bazel` and must not start with `.`.**** |
 
 ## inject\_repo
 
@@ -138,8 +138,8 @@ used as a dependency by others, its own overrides are ignored.
 
 | Parameter | Description |
 | --- | --- |
-| `module_name` | [string](../core/string); required  The name of the Bazel module dependency to apply this override to. |
-| `path` | [string](../core/string); required  The path to the directory where this module is. |
+| `module_name` | [string](/versions/8.1.1/rules/lib/core/string); required  The name of the Bazel module dependency to apply this override to. |
+| `path` | [string](/versions/8.1.1/rules/lib/core/string); required  The path to the directory where this module is. |
 
 ## module
 
@@ -155,11 +155,11 @@ It should be called at most once, and if called, it must be the very first direc
 
 | Parameter | Description |
 | --- | --- |
-| `name` | [string](../core/string); default is `''`  The name of the module. Can be omitted only if this module is the root module (as in, if it's not going to be depended on by another module). A valid module name must: 1) only contain lowercase letters (a-z), digits (0-9), dots (.), hyphens (-), and underscores (\_); 2) begin with a lowercase letter; 3) end with a lowercase letter or digit. |
-| `version` | [string](../core/string); default is `''`  The version of the module. Can be omitted only if this module is the root module (as in, if it's not going to be depended on by another module). The version must be in a relaxed SemVer format; see [the documentation](/versions/8.1.1/external/module#version_format) for more details. |
-| `compatibility_level` | [int](../core/int); default is `0`  The compatibility level of the module; this should be changed every time a major incompatible change is introduced. This is essentially the "major version" of the module in terms of SemVer, except that it's not embedded in the version string itself, but exists as a separate field. Modules with different compatibility levels participate in version resolution as if they're modules with different names, but the final dependency graph cannot contain multiple modules with the same name but different compatibility levels (unless `multiple_version_override` is in effect). See [the documentation](/versions/8.1.1/external/module#compatibility_level) for more details. |
-| `repo_name` | [string](../core/string); default is `''`  The name of the repository representing this module, as seen by the module itself. By default, the name of the repo is the name of the module. This can be specified to ease migration for projects that have been using a repo name for itself that differs from its module name. |
-| `bazel_compatibility` | Iterable of [string](../core/string)s; default is `[]`  A list of bazel versions that allows users to declare which Bazel versions are compatible with this module. It does NOT affect dependency resolution, but bzlmod will use this information to check if your current Bazel version is compatible. The format of this value is a string of some constraint values separated by comma. Three constraints are supported: <=X.X.X: The Bazel version must be equal or older than X.X.X. Used when there is a known incompatible change in a newer version. >=X.X.X: The Bazel version must be equal or newer than X.X.X.Used when you depend on some features that are only available since X.X.X. -X.X.X: The Bazel version X.X.X is not compatible. Used when there is a bug in X.X.X that breaks you, but fixed in later versions. |
+| `name` | [string](/versions/8.1.1/rules/lib/core/string); default is `''`  The name of the module. Can be omitted only if this module is the root module (as in, if it's not going to be depended on by another module). A valid module name must: 1) only contain lowercase letters (a-z), digits (0-9), dots (.), hyphens (-), and underscores (\_); 2) begin with a lowercase letter; 3) end with a lowercase letter or digit. |
+| `version` | [string](/versions/8.1.1/rules/lib/core/string); default is `''`  The version of the module. Can be omitted only if this module is the root module (as in, if it's not going to be depended on by another module). The version must be in a relaxed SemVer format; see [the documentation](/versions/8.1.1/external/module#version_format) for more details. |
+| `compatibility_level` | [int](/versions/8.1.1/rules/lib/core/int); default is `0`  The compatibility level of the module; this should be changed every time a major incompatible change is introduced. This is essentially the "major version" of the module in terms of SemVer, except that it's not embedded in the version string itself, but exists as a separate field. Modules with different compatibility levels participate in version resolution as if they're modules with different names, but the final dependency graph cannot contain multiple modules with the same name but different compatibility levels (unless `multiple_version_override` is in effect). See [the documentation](/versions/8.1.1/external/module#compatibility_level) for more details. |
+| `repo_name` | [string](/versions/8.1.1/rules/lib/core/string); default is `''`  The name of the repository representing this module, as seen by the module itself. By default, the name of the repo is the name of the module. This can be specified to ease migration for projects that have been using a repo name for itself that differs from its module name. |
+| `bazel_compatibility` | Iterable of [string](/versions/8.1.1/rules/lib/core/string)s; default is `[]`  A list of bazel versions that allows users to declare which Bazel versions are compatible with this module. It does NOT affect dependency resolution, but bzlmod will use this information to check if your current Bazel version is compatible. The format of this value is a string of some constraint values separated by comma. Three constraints are supported: <=X.X.X: The Bazel version must be equal or older than X.X.X. Used when there is a known incompatible change in a newer version. >=X.X.X: The Bazel version must be equal or newer than X.X.X.Used when you depend on some features that are only available since X.X.X. -X.X.X: The Bazel version X.X.X is not compatible. Used when there is a bug in X.X.X that breaks you, but fixed in later versions. |
 
 ## multiple\_version\_override
 
@@ -173,9 +173,9 @@ Specifies that a dependency should still come from a registry, but multiple vers
 
 | Parameter | Description |
 | --- | --- |
-| `module_name` | [string](../core/string); required  The name of the Bazel module dependency to apply this override to. |
-| `versions` | Iterable of [string](../core/string)s; required  Explicitly specifies the versions allowed to coexist. These versions must already be present in the dependency graph pre-selection. Dependencies on this module will be "upgraded" to the nearest higher allowed version at the same compatibility level, whereas dependencies that have a higher version than any allowed versions at the same compatibility level will cause an error. |
-| `registry` | [string](../core/string); default is `''`  Overrides the registry for this module; instead of finding this module from the default list of registries, the given registry should be used. |
+| `module_name` | [string](/versions/8.1.1/rules/lib/core/string); required  The name of the Bazel module dependency to apply this override to. |
+| `versions` | Iterable of [string](/versions/8.1.1/rules/lib/core/string)s; required  Explicitly specifies the versions allowed to coexist. These versions must already be present in the dependency graph pre-selection. Dependencies on this module will be "upgraded" to the nearest higher allowed version at the same compatibility level, whereas dependencies that have a higher version than any allowed versions at the same compatibility level will cause an error. |
+| `registry` | [string](/versions/8.1.1/rules/lib/core/string); default is `''`  Overrides the registry for this module; instead of finding this module from the default list of registries, the given registry should be used. |
 
 ## override\_repo
 
@@ -209,8 +209,8 @@ Specifies already-defined execution platforms to be registered when this module
 
 | Parameter | Description |
 | --- | --- |
-| `dev_dependency` | [bool](../core/bool); default is `False`  If true, the execution platforms will not be registered if the current module is not the root module or `--ignore\_dev\_dependency` is enabled. |
-| `platform_labels` | [sequence](../core/list) of [string](../core/string)s; required  The target patterns to register. |
+| `dev_dependency` | [bool](/versions/8.1.1/rules/lib/core/bool); default is `False`  If true, the execution platforms will not be registered if the current module is not the root module or `--ignore\_dev\_dependency` is enabled. |
+| `platform_labels` | [sequence](/versions/8.1.1/rules/lib/core/list) of [string](/versions/8.1.1/rules/lib/core/string)s; required  The target patterns to register. |
 
 ## register\_toolchains
 
@@ -224,8 +224,8 @@ Specifies already-defined toolchains to be registered when this module is select
 
 | Parameter | Description |
 | --- | --- |
-| `dev_dependency` | [bool](../core/bool); default is `False`  If true, the toolchains will not be registered if the current module is not the root module or `--ignore\_dev\_dependency` is enabled. |
-| `toolchain_labels` | [sequence](../core/list) of [string](../core/string)s; required  The target patterns to register. |
+| `dev_dependency` | [bool](/versions/8.1.1/rules/lib/core/bool); default is `False`  If true, the toolchains will not be registered if the current module is not the root module or `--ignore\_dev\_dependency` is enabled. |
+| `toolchain_labels` | [sequence](/versions/8.1.1/rules/lib/core/list) of [string](/versions/8.1.1/rules/lib/core/string)s; required  The target patterns to register. |
 
 ## single\_version\_override
 
@@ -239,12 +239,12 @@ Specifies that a dependency should still come from a registry, but its version s
 
 | Parameter | Description |
 | --- | --- |
-| `module_name` | [string](../core/string); required  The name of the Bazel module dependency to apply this override to. |
-| `version` | [string](../core/string); default is `''`  Overrides the declared version of this module in the dependency graph. In other words, this module will be "pinned" to this override version. This attribute can be omitted if all one wants to override is the registry or the patches. |
-| `registry` | [string](../core/string); default is `''`  Overrides the registry for this module; instead of finding this module from the default list of registries, the given registry should be used. |
-| `patches` | Iterable of [string](../core/string)s; default is `[]`  A list of labels pointing to patch files to apply for this module. The patch files must exist in the source tree of the top level project. They are applied in the list order. If a patch makes changes to the MODULE.bazel file, these changes will only be effective if the patch file is provided by the root module. |
-| `patch_cmds` | Iterable of [string](../core/string)s; default is `[]`  Sequence of Bash commands to be applied on Linux/Macos after patches are applied. Changes to the MODULE.bazel file will not be effective. |
-| `patch_strip` | [int](../core/int); default is `0`  Same as the --strip argument of Unix patch. |
+| `module_name` | [string](/versions/8.1.1/rules/lib/core/string); required  The name of the Bazel module dependency to apply this override to. |
+| `version` | [string](/versions/8.1.1/rules/lib/core/string); default is `''`  Overrides the declared version of this module in the dependency graph. In other words, this module will be "pinned" to this override version. This attribute can be omitted if all one wants to override is the registry or the patches. |
+| `registry` | [string](/versions/8.1.1/rules/lib/core/string); default is `''`  Overrides the registry for this module; instead of finding this module from the default list of registries, the given registry should be used. |
+| `patches` | Iterable of [string](/versions/8.1.1/rules/lib/core/string)s; default is `[]`  A list of labels pointing to patch files to apply for this module. The patch files must exist in the source tree of the top level project. They are applied in the list order. If a patch makes changes to the MODULE.bazel file, these changes will only be effective if the patch file is provided by the root module. |
+| `patch_cmds` | Iterable of [string](/versions/8.1.1/rules/lib/core/string)s; default is `[]`  Sequence of Bash commands to be applied on Linux/Macos after patches are applied. Changes to the MODULE.bazel file will not be effective. |
+| `patch_strip` | [int](/versions/8.1.1/rules/lib/core/int); default is `0`  Same as the --strip argument of Unix patch. |
 
 ## use\_extension
 
@@ -258,10 +258,10 @@ Returns a proxy object representing a module extension; its methods can be invok
 
 | Parameter | Description |
 | --- | --- |
-| `extension_bzl_file` | [string](../core/string); required  A label to the Starlark file defining the module extension. |
-| `extension_name` | [string](../core/string); required  The name of the module extension to use. A symbol with this name must be exported by the Starlark file. |
-| `dev_dependency` | [bool](../core/bool); default is `False`  If true, this usage of the module extension will be ignored if the current module is not the root module or `--ignore\_dev\_dependency` is enabled. |
-| `isolate` | [bool](../core/bool); default is `False`  **Experimental**. This parameter is experimental and may change at any time. Please do not depend on it. It may be enabled on an experimental basis by setting `--experimental_isolated_extension_usages`  If true, this usage of the module extension will be isolated from all other usages, both in this and other modules. Tags created for this usage do not affect other usages and the repositories generated by the extension for this usage will be distinct from all other repositories generated by the extension. This parameter is currently experimental and only available with the flag `--experimental_isolated_extension_usages`. |
+| `extension_bzl_file` | [string](/versions/8.1.1/rules/lib/core/string); required  A label to the Starlark file defining the module extension. |
+| `extension_name` | [string](/versions/8.1.1/rules/lib/core/string); required  The name of the module extension to use. A symbol with this name must be exported by the Starlark file. |
+| `dev_dependency` | [bool](/versions/8.1.1/rules/lib/core/bool); default is `False`  If true, this usage of the module extension will be ignored if the current module is not the root module or `--ignore\_dev\_dependency` is enabled. |
+| `isolate` | [bool](/versions/8.1.1/rules/lib/core/bool); default is `False`  **Experimental**. This parameter is experimental and may change at any time. Please do not depend on it. It may be enabled on an experimental basis by setting `--experimental_isolated_extension_usages`  If true, this usage of the module extension will be isolated from all other usages, both in this and other modules. Tags created for this usage do not affect other usages and the repositories generated by the extension for this usage will be distinct from all other repositories generated by the extension. This parameter is currently experimental and only available with the flag `--experimental_isolated_extension_usages`. |
 
 ## use\_repo
 
@@ -291,5 +291,5 @@ Returns a proxy value that can be directly invoked in the MODULE.bazel file as a
 
 | Parameter | Description |
 | --- | --- |
-| `repo_rule_bzl_file` | [string](../core/string); required  A label to the Starlark file defining the repo rule. |
-| `repo_rule_name` | [string](../core/string); required  The name of the repo rule to use. A symbol with this name must be exported by the Starlark file. |
\ No newline at end of file
+| `repo_rule_bzl_file` | [string](/versions/8.1.1/rules/lib/core/string); required  A label to the Starlark file defining the repo rule. |
+| `repo_rule_name` | [string](/versions/8.1.1/rules/lib/core/string); required  The name of the repo rule to use. A symbol with this name must be exported by the Starlark file. |
\ No newline at end of file
diff --git a/versions/8.1.1/rules/lib/globals/repo.mdx b/versions/8.1.1/rules/lib/globals/repo.mdx
index 40342c47..c7a2fc8a 100644
--- a/versions/8.1.1/rules/lib/globals/repo.mdx
+++ b/versions/8.1.1/rules/lib/globals/repo.mdx
@@ -23,7 +23,7 @@ This function takes a list of strings and a directory is ignored if any of the g
 
 | Parameter | Description |
 | --- | --- |
-| `dirs` | [sequence](../core/list) of [string](../core/string)s; required |
+| `dirs` | [sequence](/versions/8.1.1/rules/lib/core/list) of [string](/versions/8.1.1/rules/lib/core/string)s; required |
 
 ## repo
 
diff --git a/versions/8.1.1/rules/lib/globals/workspace.mdx b/versions/8.1.1/rules/lib/globals/workspace.mdx
index 4558f7d5..0d48d45e 100644
--- a/versions/8.1.1/rules/lib/globals/workspace.mdx
+++ b/versions/8.1.1/rules/lib/globals/workspace.mdx
@@ -25,8 +25,8 @@ Gives a target an alias in the `//external` package.
 
 | Parameter | Description |
 | --- | --- |
-| `name` | [string](../core/string); required  The label under '//external' to serve as the alias name |
-| `actual` | [string](../core/string); or `None`; default is `None`  The real label to be aliased |
+| `name` | [string](/versions/8.1.1/rules/lib/core/string); required  The label under '//external' to serve as the alias name |
+| `actual` | [string](/versions/8.1.1/rules/lib/core/string); or `None`; default is `None`  The real label to be aliased |
 
 ## register\_execution\_platforms
 
@@ -40,7 +40,7 @@ Specifies already-defined execution platforms to be registered. Should be absolu
 
 | Parameter | Description |
 | --- | --- |
-| `platform_labels` | [sequence](../core/list) of [string](../core/string)s; required  The target patterns to register. |
+| `platform_labels` | [sequence](/versions/8.1.1/rules/lib/core/list) of [string](/versions/8.1.1/rules/lib/core/string)s; required  The target patterns to register. |
 
 ## register\_toolchains
 
@@ -54,7 +54,7 @@ Specifies already-defined toolchains to be registered. Should be absolute [targe
 
 | Parameter | Description |
 | --- | --- |
-| `toolchain_labels` | [sequence](../core/list) of [string](../core/string)s; required  The target patterns to register. |
+| `toolchain_labels` | [sequence](/versions/8.1.1/rules/lib/core/list) of [string](/versions/8.1.1/rules/lib/core/string)s; required  The target patterns to register. |
 
 ## workspace
 
@@ -74,4 +74,4 @@ This name is used for the directory that the repository's runfiles are stored in
 
 | Parameter | Description |
 | --- | --- |
-| `name` | [string](../core/string); required  the name of the workspace. Names must start with a letter and can only contain letters, numbers, underscores, dashes, and dots. |
\ No newline at end of file
+| `name` | [string](/versions/8.1.1/rules/lib/core/string); required  the name of the workspace. Names must start with a letter and can only contain letters, numbers, underscores, dashes, and dots. |
\ No newline at end of file
diff --git a/versions/8.1.1/rules/lib/providers/AnalysisTestResultInfo.mdx b/versions/8.1.1/rules/lib/providers/AnalysisTestResultInfo.mdx
index 1edabb04..502bdf92 100644
--- a/versions/8.1.1/rules/lib/providers/AnalysisTestResultInfo.mdx
+++ b/versions/8.1.1/rules/lib/providers/AnalysisTestResultInfo.mdx
@@ -22,8 +22,8 @@ The `AnalysisTestResultInfo` constructor.
 
 | Parameter | Description |
 | --- | --- |
-| `success` | [bool](../core/bool); required  If true, then the analysis-phase test represented by this target should pass. If false, the test should fail. |
-| `message` | [string](../core/string); required  A descriptive message containing information about the test and its success/failure. |
+| `success` | [bool](/versions/8.1.1/rules/lib/core/bool); required  If true, then the analysis-phase test represented by this target should pass. If false, the test should fail. |
+| `message` | [string](/versions/8.1.1/rules/lib/core/string); required  A descriptive message containing information about the test and its success/failure. |
 
 ## message
 
diff --git a/versions/8.1.1/rules/lib/providers/CcInfo.mdx b/versions/8.1.1/rules/lib/providers/CcInfo.mdx
index f3c0d961..3dc2c239 100644
--- a/versions/8.1.1/rules/lib/providers/CcInfo.mdx
+++ b/versions/8.1.1/rules/lib/providers/CcInfo.mdx
@@ -22,8 +22,8 @@ The `CcInfo` constructor.
 
 | Parameter | Description |
 | --- | --- |
-| `compilation_context` | [CompilationContext](../builtins/CompilationContext); or `None`; default is `None`  The `CompilationContext`. |
-| `linking_context` | [LinkingContext](../builtins/LinkingContext); or `None`; default is `None`  The `LinkingContext`. |
+| `compilation_context` | [CompilationContext](/versions/8.1.1/rules/lib/builtins/CompilationContext); or `None`; default is `None`  The `CompilationContext`. |
+| `linking_context` | [LinkingContext](/versions/8.1.1/rules/lib/builtins/LinkingContext); or `None`; default is `None`  The `LinkingContext`. |
 | `debug_context` | DebugContext; or `None`; default is `None`  The `DebugContext`. |
 
 ## compilation\_context
diff --git a/versions/8.1.1/rules/lib/providers/DebugPackageInfo.mdx b/versions/8.1.1/rules/lib/providers/DebugPackageInfo.mdx
index 6bac3007..e54cbd6d 100644
--- a/versions/8.1.1/rules/lib/providers/DebugPackageInfo.mdx
+++ b/versions/8.1.1/rules/lib/providers/DebugPackageInfo.mdx
@@ -24,10 +24,10 @@ The `DebugPackageInfo` constructor.
 
 | Parameter | Description |
 | --- | --- |
-| `target_label` | [Label](../builtins/Label); required  The label for the \*\_binary target |
-| `stripped_file` | [File](../builtins/File); or `None`; default is `None`  The stripped file (the explicit ".stripped" target) |
-| `unstripped_file` | [File](../builtins/File); required  The unstripped file (the default executable target). |
-| `dwp_file` | [File](../builtins/File); or `None`; default is `None`  The .dwp file (for fission builds) or null if --fission=no. |
+| `target_label` | [Label](/versions/8.1.1/rules/lib/builtins/Label); required  The label for the \*\_binary target |
+| `stripped_file` | [File](/versions/8.1.1/rules/lib/builtins/File); or `None`; default is `None`  The stripped file (the explicit ".stripped" target) |
+| `unstripped_file` | [File](/versions/8.1.1/rules/lib/builtins/File); required  The unstripped file (the default executable target). |
+| `dwp_file` | [File](/versions/8.1.1/rules/lib/builtins/File); or `None`; default is `None`  The .dwp file (for fission builds) or null if --fission=no. |
 
 ## dwp\_file
 
diff --git a/versions/8.1.1/rules/lib/providers/DefaultInfo.mdx b/versions/8.1.1/rules/lib/providers/DefaultInfo.mdx
index 2bbe819b..9e259377 100644
--- a/versions/8.1.1/rules/lib/providers/DefaultInfo.mdx
+++ b/versions/8.1.1/rules/lib/providers/DefaultInfo.mdx
@@ -28,11 +28,11 @@ The `DefaultInfo` constructor.
 
 | Parameter | Description |
 | --- | --- |
-| `files` | [depset](../builtins/depset); or `None`; default is `None`  A [`depset`](../builtins/depset) of [`File`](../builtins/File) objects representing the default outputs to build when this target is specified on the bazel command line. By default it is all predeclared outputs. |
-| `runfiles` | [runfiles](../builtins/runfiles); or `None`; default is `None`  runfiles descriptor describing the files that this target needs when run (via the `run` command or as a tool dependency). |
-| `data_runfiles` | [runfiles](../builtins/runfiles); or `None`; default is `None`  **It is recommended that you avoid using this parameter (see ["runfiles features to avoid"](https://bazel.build/versions/8.1.1/extending/rules#runfiles_features_to_avoid))** runfiles descriptor describing the runfiles this target needs to run when it is a dependency via the `data` attribute. |
-| `default_runfiles` | [runfiles](../builtins/runfiles); or `None`; default is `None`  **It is recommended that you avoid using this parameter (see ["runfiles features to avoid"](https://bazel.build/versions/8.1.1/extending/rules#runfiles_features_to_avoid))** runfiles descriptor describing the runfiles this target needs to run when it is a dependency via any attribute other than the `data` attribute. |
-| `executable` | [File](../builtins/File); or `None`; default is `None`  If this rule is marked [`executable`](../globals/bzl#rule.executable) or [`test`](../globals/bzl#rule.test), this is a [`File`](../builtins/File) object representing the file that should be executed to run the target. By default it is the predeclared output `ctx.outputs.executable` but it is recommended to pass another file (either predeclared or not) explicitly. |
+| `files` | [depset](/versions/8.1.1/rules/lib/builtins/depset); or `None`; default is `None`  A [`depset`](/versions/8.1.1/rules/lib/builtins/depset) of [`File`](/versions/8.1.1/rules/lib/builtins/File) objects representing the default outputs to build when this target is specified on the bazel command line. By default it is all predeclared outputs. |
+| `runfiles` | [runfiles](/versions/8.1.1/rules/lib/builtins/runfiles); or `None`; default is `None`  runfiles descriptor describing the files that this target needs when run (via the `run` command or as a tool dependency). |
+| `data_runfiles` | [runfiles](/versions/8.1.1/rules/lib/builtins/runfiles); or `None`; default is `None`  **It is recommended that you avoid using this parameter (see ["runfiles features to avoid"](https://bazel.build/versions/8.1.1/extending/rules#runfiles_features_to_avoid))** runfiles descriptor describing the runfiles this target needs to run when it is a dependency via the `data` attribute. |
+| `default_runfiles` | [runfiles](/versions/8.1.1/rules/lib/builtins/runfiles); or `None`; default is `None`  **It is recommended that you avoid using this parameter (see ["runfiles features to avoid"](https://bazel.build/versions/8.1.1/extending/rules#runfiles_features_to_avoid))** runfiles descriptor describing the runfiles this target needs to run when it is a dependency via any attribute other than the `data` attribute. |
+| `executable` | [File](/versions/8.1.1/rules/lib/builtins/File); or `None`; default is `None`  If this rule is marked [`executable`](/versions/8.1.1/rules/lib/globals/bzl#rule.executable) or [`test`](/versions/8.1.1/rules/lib/globals/bzl#rule.test), this is a [`File`](/versions/8.1.1/rules/lib/builtins/File) object representing the file that should be executed to run the target. By default it is the predeclared output `ctx.outputs.executable` but it is recommended to pass another file (either predeclared or not) explicitly. |
 
 ## data\_runfiles
 
@@ -58,7 +58,7 @@ May return `None`.
 depset DefaultInfo.files
 ```
 
-A [`depset`](../builtins/depset) of [`File`](../builtins/File) objects representing the default outputs to build when this target is specified on the bazel command line. By default it is all predeclared outputs.
+A [`depset`](/versions/8.1.1/rules/lib/builtins/depset) of [`File`](/versions/8.1.1/rules/lib/builtins/File) objects representing the default outputs to build when this target is specified on the bazel command line. By default it is all predeclared outputs.
 May return `None`.
 
 ## files\_to\_run
@@ -67,5 +67,5 @@ May return `None`.
 FilesToRunProvider DefaultInfo.files_to_run
 ```
 
-A [`FilesToRunProvider`](../providers/FilesToRunProvider) object containing information about the executable and runfiles of the target.
+A [`FilesToRunProvider`](/versions/8.1.1/rules/lib/providers/FilesToRunProvider) object containing information about the executable and runfiles of the target.
 May return `None`.
\ No newline at end of file
diff --git a/versions/8.1.1/rules/lib/providers/ExecutionInfo.mdx b/versions/8.1.1/rules/lib/providers/ExecutionInfo.mdx
index d351095e..1ff457bf 100644
--- a/versions/8.1.1/rules/lib/providers/ExecutionInfo.mdx
+++ b/versions/8.1.1/rules/lib/providers/ExecutionInfo.mdx
@@ -22,8 +22,8 @@ Creates an instance.
 
 | Parameter | Description |
 | --- | --- |
-| `requirements` | [dict](../core/dict); default is `{}`  A dict indicating special execution requirements, such as hardware platforms. |
-| `exec_group` | [string](../core/string); default is `'test'`  The name of the exec group that is used to execute the test. |
+| `requirements` | [dict](/versions/8.1.1/rules/lib/core/dict); default is `{}`  A dict indicating special execution requirements, such as hardware platforms. |
+| `exec_group` | [string](/versions/8.1.1/rules/lib/core/string); default is `'test'`  The name of the exec group that is used to execute the test. |
 
 ## exec\_group
 
diff --git a/versions/8.1.1/rules/lib/providers/FeatureFlagInfo.mdx b/versions/8.1.1/rules/lib/providers/FeatureFlagInfo.mdx
index ebade07a..518cb638 100644
--- a/versions/8.1.1/rules/lib/providers/FeatureFlagInfo.mdx
+++ b/versions/8.1.1/rules/lib/providers/FeatureFlagInfo.mdx
@@ -31,7 +31,7 @@ The value of the flag in the configuration used by the flag rule.
 
 | Parameter | Description |
 | --- | --- |
-| `value` | [string](../core/string); required  String, the value to check for validity for this flag. |
+| `value` | [string](/versions/8.1.1/rules/lib/core/string); required  String, the value to check for validity for this flag. |
 
 ## value
 
diff --git a/versions/8.1.1/rules/lib/providers/InstrumentedFilesInfo.mdx b/versions/8.1.1/rules/lib/providers/InstrumentedFilesInfo.mdx
index dff84332..388bdbdd 100644
--- a/versions/8.1.1/rules/lib/providers/InstrumentedFilesInfo.mdx
+++ b/versions/8.1.1/rules/lib/providers/InstrumentedFilesInfo.mdx
@@ -15,7 +15,7 @@ Contains information about source files and instrumentation metadata files for r
 depset InstrumentedFilesInfo.instrumented_files
 ```
 
-[`depset`](../builtins/depset) of [`File`](../builtins/File) objects representing instrumented source files for this target and its dependencies.
+[`depset`](/versions/8.1.1/rules/lib/builtins/depset) of [`File`](/versions/8.1.1/rules/lib/builtins/File) objects representing instrumented source files for this target and its dependencies.
 
 ## metadata\_files
 
@@ -23,4 +23,4 @@ depset InstrumentedFilesInfo.instrumented_files
 depset InstrumentedFilesInfo.metadata_files
 ```
 
-[`depset`](../builtins/depset) of [`File`](../builtins/File) objects representing coverage metadata files for this target and its dependencies. These files contain additional information required to generate LCOV-format coverage output after the code is executed, e.g. the `.gcno` files generated when `gcc` is run with `-ftest-coverage`.
\ No newline at end of file
+[`depset`](/versions/8.1.1/rules/lib/builtins/depset) of [`File`](/versions/8.1.1/rules/lib/builtins/File) objects representing coverage metadata files for this target and its dependencies. These files contain additional information required to generate LCOV-format coverage output after the code is executed, e.g. the `.gcno` files generated when `gcc` is run with `-ftest-coverage`.
\ No newline at end of file
diff --git a/versions/8.1.1/rules/lib/providers/PackageSpecificationInfo.mdx b/versions/8.1.1/rules/lib/providers/PackageSpecificationInfo.mdx
index 242a43e6..99b2136c 100644
--- a/versions/8.1.1/rules/lib/providers/PackageSpecificationInfo.mdx
+++ b/versions/8.1.1/rules/lib/providers/PackageSpecificationInfo.mdx
@@ -20,4 +20,4 @@ Checks if a target exists in a package group.
 
 | Parameter | Description |
 | --- | --- |
-| `target` | [Label](../builtins/Label); or [string](../core/string); required  A target which is checked if it exists inside the package group. |
\ No newline at end of file
+| `target` | [Label](/versions/8.1.1/rules/lib/builtins/Label); or [string](/versions/8.1.1/rules/lib/core/string); required  A target which is checked if it exists inside the package group. |
\ No newline at end of file
diff --git a/versions/8.1.1/rules/lib/providers/ProguardSpecProvider.mdx b/versions/8.1.1/rules/lib/providers/ProguardSpecProvider.mdx
index b7a337c2..ac3d078d 100644
--- a/versions/8.1.1/rules/lib/providers/ProguardSpecProvider.mdx
+++ b/versions/8.1.1/rules/lib/providers/ProguardSpecProvider.mdx
@@ -20,4 +20,4 @@ The `ProguardSpecProvider` constructor.
 
 | Parameter | Description |
 | --- | --- |
-| `specs` | [depset](../builtins/depset) of [File](../builtins/File)s; required  Transitive proguard specs. |
\ No newline at end of file
+| `specs` | [depset](/versions/8.1.1/rules/lib/builtins/depset) of [File](/versions/8.1.1/rules/lib/builtins/File)s; required  Transitive proguard specs. |
\ No newline at end of file
diff --git a/versions/8.1.1/rules/lib/repo/index.mdx b/versions/8.1.1/rules/lib/repo/index.mdx
index ab27e81c..800b7acb 100644
--- a/versions/8.1.1/rules/lib/repo/index.mdx
+++ b/versions/8.1.1/rules/lib/repo/index.mdx
@@ -3,10 +3,10 @@
 title: 'Repository Rules'
 ---
 
-* [Rules related to git](git)
-* [Rules related to http](http)
-* [Rules related to local directories](local)
+* [Rules related to git](/versions/8.1.1/rules/lib/repo/git)
+* [Rules related to http](/versions/8.1.1/rules/lib/repo/http)
+* [Rules related to local directories](/versions/8.1.1/rules/lib/repo/local)
 
 # Generic functions for repository rule authors
 
-* [Utility functions on patching](utils)
+* [Utility functions on patching](/versions/8.1.1/rules/lib/repo/utils)
diff --git a/versions/8.1.1/rules/lib/toplevel/apple_common.mdx b/versions/8.1.1/rules/lib/toplevel/apple_common.mdx
index d26f9c22..81379269 100644
--- a/versions/8.1.1/rules/lib/toplevel/apple_common.mdx
+++ b/versions/8.1.1/rules/lib/toplevel/apple_common.mdx
@@ -21,7 +21,7 @@ Functions for Starlark to access internals of the apple rule implementations.
 dict apple_common.apple_host_system_env(xcode_config)
 ```
 
-Returns a [dict](../core/dict) of environment variables that should be set for actions that need to run build tools on an Apple host system, such as the version of Xcode that should be used. The keys are variable names and the values are their corresponding values.
+Returns a [dict](/versions/8.1.1/rules/lib/core/dict) of environment variables that should be set for actions that need to run build tools on an Apple host system, such as the version of Xcode that should be used. The keys are variable names and the values are their corresponding values.
 
 ### Parameters
 
@@ -43,13 +43,13 @@ Utilities for resolving items from the apple toolchain.
 DottedVersion apple_common.dotted_version(version)
 ```
 
-Creates a new [DottedVersion](../builtins/DottedVersion) instance.
+Creates a new [DottedVersion](/versions/8.1.1/rules/lib/builtins/DottedVersion) instance.
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `version` | [string](../core/string); required  The string representation of the DottedVersion. |
+| `version` | [string](/versions/8.1.1/rules/lib/core/string); required  The string representation of the DottedVersion. |
 
 ## platform
 
@@ -69,7 +69,7 @@ An enum-like struct that contains the following fields corresponding to Apple pl
 * `watchos_device`
 * `watchos_simulator`
 
-These values can be passed to methods that expect a platform, like [XcodeVersionConfig.sdk\_version\_for\_platform](../providers/XcodeVersionConfig#sdk_version_for_platform).
+These values can be passed to methods that expect a platform, like [XcodeVersionConfig.sdk\_version\_for\_platform](/versions/8.1.1/rules/lib/providers/XcodeVersionConfig#sdk_version_for_platform).
 
 ## platform\_type
 
@@ -85,7 +85,7 @@ An enum-like struct that contains the following fields corresponding to Apple pl
 * `visionos`
 * `watchos`
 
-These values can be passed to methods that expect a platform type, like the 'apple' configuration fragment's [multi\_arch\_platform](../fragments/apple#multi_arch_platform) method.
+These values can be passed to methods that expect a platform type, like the 'apple' configuration fragment's [multi\_arch\_platform](/versions/8.1.1/rules/lib/fragments/apple#multi_arch_platform) method.
 
 Example:
 
diff --git a/versions/8.1.1/rules/lib/toplevel/attr.mdx b/versions/8.1.1/rules/lib/toplevel/attr.mdx
index b80da991..7861f67c 100644
--- a/versions/8.1.1/rules/lib/toplevel/attr.mdx
+++ b/versions/8.1.1/rules/lib/toplevel/attr.mdx
@@ -2,7 +2,7 @@
 title: 'attr'
 ---
 
-This is a top-level module for defining the attribute schemas of a rule or aspect. Each function returns an object representing the schema of a single attribute. These objects are used as the values of the `attrs` dictionary argument of [`rule()`](../globals/bzl#rule), [`aspect()`](../globals/bzl#aspect), [`repository_rule()`](../globals/bzl#repository_rule) and [`tag_class()`](../globals/bzl#tag_class).
+This is a top-level module for defining the attribute schemas of a rule or aspect. Each function returns an object representing the schema of a single attribute. These objects are used as the values of the `attrs` dictionary argument of [`rule()`](/versions/8.1.1/rules/lib/globals/bzl#rule), [`aspect()`](/versions/8.1.1/rules/lib/globals/bzl#aspect), [`repository_rule()`](/versions/8.1.1/rules/lib/globals/bzl#repository_rule) and [`tag_class()`](/versions/8.1.1/rules/lib/globals/bzl#tag_class).
 
 See the Rules page for more on [defining](https://bazel.build/versions/8.1.1/extending/rules#attributes)
 and [using](https://bazel.build/versions/8.1.1/extending/rules#implementation_function) attributes.
@@ -29,16 +29,16 @@ and [using](https://bazel.build/versions/8.1.1/extending/rules#implementation_fu
 Attribute attr.bool(configurable=unbound, default=False, doc=None, mandatory=False)
 ```
 
-Creates a schema for a boolean attribute. The corresponding [`ctx.attr`](../builtins/ctx#attr) attribute will be of type [`bool`](../core/bool).
+Creates a schema for a boolean attribute. The corresponding [`ctx.attr`](/versions/8.1.1/rules/lib/builtins/ctx#attr) attribute will be of type [`bool`](/versions/8.1.1/rules/lib/core/bool).
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `configurable` | [bool](../core/bool); or unbound; default is `unbound`  This argument can only be specified for an attribute of a symbolic macro. If `configurable` is explicitly set to `False`, the symbolic macro attribute is non-configurable - in other words, it cannot take a `select()` value. If the `configurable` is either unbound or explicitly set to `True`, the attribute is configurable and can take a `select()` value. For an attribute of a rule or aspect, `configurable` must be left unbound. Most Starlark rule attributes are always configurable, with the exception of `attr.output()`, `attr.output_list()`, and `attr.license()` rule attributes, which are always non-configurable. |
-| `default` | [bool](../core/bool); default is `False`  A default value to use if no value for this attribute is given when instantiating the rule. |
-| `doc` | [string](../core/string); or `None`; default is `None`  A description of the attribute that can be extracted by documentation generating tools. |
-| `mandatory` | [bool](../core/bool); default is `False`  If true, the value must be specified explicitly (even if it has a `default`). |
+| `configurable` | [bool](/versions/8.1.1/rules/lib/core/bool); or unbound; default is `unbound`  This argument can only be specified for an attribute of a symbolic macro. If `configurable` is explicitly set to `False`, the symbolic macro attribute is non-configurable - in other words, it cannot take a `select()` value. If the `configurable` is either unbound or explicitly set to `True`, the attribute is configurable and can take a `select()` value. For an attribute of a rule or aspect, `configurable` must be left unbound. Most Starlark rule attributes are always configurable, with the exception of `attr.output()`, `attr.output_list()`, and `attr.license()` rule attributes, which are always non-configurable. |
+| `default` | [bool](/versions/8.1.1/rules/lib/core/bool); default is `False`  A default value to use if no value for this attribute is given when instantiating the rule. |
+| `doc` | [string](/versions/8.1.1/rules/lib/core/string); or `None`; default is `None`  A description of the attribute that can be extracted by documentation generating tools. |
+| `mandatory` | [bool](/versions/8.1.1/rules/lib/core/bool); default is `False`  If true, the value must be specified explicitly (even if it has a `default`). |
 
 ## int
 
@@ -46,17 +46,17 @@ Creates a schema for a boolean attribute. The corresponding [`ctx.attr`](../buil
 Attribute attr.int(configurable=unbound, default=0, doc=None, mandatory=False, values=[])
 ```
 
-Creates a schema for an integer attribute. The value must be in the signed 32-bit range. The corresponding [`ctx.attr`](../builtins/ctx#attr) attribute will be of type [`int`](../core/int).
+Creates a schema for an integer attribute. The value must be in the signed 32-bit range. The corresponding [`ctx.attr`](/versions/8.1.1/rules/lib/builtins/ctx#attr) attribute will be of type [`int`](/versions/8.1.1/rules/lib/core/int).
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `configurable` | [bool](../core/bool); or unbound; default is `unbound`  This argument can only be specified for an attribute of a symbolic macro. If `configurable` is explicitly set to `False`, the symbolic macro attribute is non-configurable - in other words, it cannot take a `select()` value. If the `configurable` is either unbound or explicitly set to `True`, the attribute is configurable and can take a `select()` value. For an attribute of a rule or aspect, `configurable` must be left unbound. Most Starlark rule attributes are always configurable, with the exception of `attr.output()`, `attr.output_list()`, and `attr.license()` rule attributes, which are always non-configurable. |
-| `default` | [int](../core/int); default is `0`  A default value to use if no value for this attribute is given when instantiating the rule. |
-| `doc` | [string](../core/string); or `None`; default is `None`  A description of the attribute that can be extracted by documentation generating tools. |
-| `mandatory` | [bool](../core/bool); default is `False`  If true, the value must be specified explicitly (even if it has a `default`). |
-| `values` | [sequence](../core/list) of [int](../core/int)s; default is `[]`  The list of allowed values for the attribute. An error is raised if any other value is given. |
+| `configurable` | [bool](/versions/8.1.1/rules/lib/core/bool); or unbound; default is `unbound`  This argument can only be specified for an attribute of a symbolic macro. If `configurable` is explicitly set to `False`, the symbolic macro attribute is non-configurable - in other words, it cannot take a `select()` value. If the `configurable` is either unbound or explicitly set to `True`, the attribute is configurable and can take a `select()` value. For an attribute of a rule or aspect, `configurable` must be left unbound. Most Starlark rule attributes are always configurable, with the exception of `attr.output()`, `attr.output_list()`, and `attr.license()` rule attributes, which are always non-configurable. |
+| `default` | [int](/versions/8.1.1/rules/lib/core/int); default is `0`  A default value to use if no value for this attribute is given when instantiating the rule. |
+| `doc` | [string](/versions/8.1.1/rules/lib/core/string); or `None`; default is `None`  A description of the attribute that can be extracted by documentation generating tools. |
+| `mandatory` | [bool](/versions/8.1.1/rules/lib/core/bool); default is `False`  If true, the value must be specified explicitly (even if it has a `default`). |
+| `values` | [sequence](/versions/8.1.1/rules/lib/core/list) of [int](/versions/8.1.1/rules/lib/core/int)s; default is `[]`  The list of allowed values for the attribute. An error is raised if any other value is given. |
 
 ## int\_list
 
@@ -70,11 +70,11 @@ Creates a schema for a list-of-integers attribute. Each element must be in the s
 
 | Parameter | Description |
 | --- | --- |
-| `mandatory` | [bool](../core/bool); default is `False`  If true, the value must be specified explicitly (even if it has a `default`). |
-| `allow_empty` | [bool](../core/bool); default is `True`  True if the attribute can be empty. |
-| `configurable` | [bool](../core/bool); or unbound; default is `unbound`  This argument can only be specified for an attribute of a symbolic macro. If `configurable` is explicitly set to `False`, the symbolic macro attribute is non-configurable - in other words, it cannot take a `select()` value. If the `configurable` is either unbound or explicitly set to `True`, the attribute is configurable and can take a `select()` value. For an attribute of a rule or aspect, `configurable` must be left unbound. Most Starlark rule attributes are always configurable, with the exception of `attr.output()`, `attr.output_list()`, and `attr.license()` rule attributes, which are always non-configurable. |
-| `default` | [sequence](../core/list) of [int](../core/int)s; default is `[]`  A default value to use if no value for this attribute is given when instantiating the rule. |
-| `doc` | [string](../core/string); or `None`; default is `None`  A description of the attribute that can be extracted by documentation generating tools. |
+| `mandatory` | [bool](/versions/8.1.1/rules/lib/core/bool); default is `False`  If true, the value must be specified explicitly (even if it has a `default`). |
+| `allow_empty` | [bool](/versions/8.1.1/rules/lib/core/bool); default is `True`  True if the attribute can be empty. |
+| `configurable` | [bool](/versions/8.1.1/rules/lib/core/bool); or unbound; default is `unbound`  This argument can only be specified for an attribute of a symbolic macro. If `configurable` is explicitly set to `False`, the symbolic macro attribute is non-configurable - in other words, it cannot take a `select()` value. If the `configurable` is either unbound or explicitly set to `True`, the attribute is configurable and can take a `select()` value. For an attribute of a rule or aspect, `configurable` must be left unbound. Most Starlark rule attributes are always configurable, with the exception of `attr.output()`, `attr.output_list()`, and `attr.license()` rule attributes, which are always non-configurable. |
+| `default` | [sequence](/versions/8.1.1/rules/lib/core/list) of [int](/versions/8.1.1/rules/lib/core/int)s; default is `[]`  A default value to use if no value for this attribute is given when instantiating the rule. |
+| `doc` | [string](/versions/8.1.1/rules/lib/core/string); or `None`; default is `None`  A description of the attribute that can be extracted by documentation generating tools. |
 
 ## label
 
@@ -84,9 +84,9 @@ Attribute attr.label(configurable=unbound, default=None, materializer=None, doc=
 
 Creates a schema for a label attribute. This is a dependency attribute.
 
-This attribute contains unique [`Label`](../builtins/Label) values. If a string is supplied in place of a `Label`, it will be converted using the [label constructor](../builtins/Label#Label). The relative parts of the label path, including the (possibly renamed) repository, are resolved with respect to the instantiated target's package.
+This attribute contains unique [`Label`](/versions/8.1.1/rules/lib/builtins/Label) values. If a string is supplied in place of a `Label`, it will be converted using the [label constructor](/versions/8.1.1/rules/lib/builtins/Label#Label). The relative parts of the label path, including the (possibly renamed) repository, are resolved with respect to the instantiated target's package.
 
-At analysis time (within the rule's implementation function), when retrieving the attribute value from `ctx.attr`, labels are replaced by the corresponding [`Target`](../builtins/Target)s. This allows you to access the providers of the current target's dependencies.
+At analysis time (within the rule's implementation function), when retrieving the attribute value from `ctx.attr`, labels are replaced by the corresponding [`Target`](/versions/8.1.1/rules/lib/builtins/Target)s. This allows you to access the providers of the current target's dependencies.
 
 In addition to ordinary source files, this kind of attribute is often used to refer to a tool -- for example, a compiler. Such tools are considered to be dependencies, just like source files. To avoid requiring users to specify the tool's label every time they use the rule in their BUILD files, you can hard-code the label of a canonical tool as the `default` value of this attribute. If you also want to prevent users from overriding this default, you can make the attribute private by giving it a name that starts with an underscore. See the [Rules](https://bazel.build/versions/8.1.1/extending/rules#private-attributes) page for more information.
 
@@ -94,21 +94,21 @@ In addition to ordinary source files, this kind of attribute is often used to re
 
 | Parameter | Description |
 | --- | --- |
-| `configurable` | [bool](../core/bool); or unbound; default is `unbound`  This argument can only be specified for an attribute of a symbolic macro. If `configurable` is explicitly set to `False`, the symbolic macro attribute is non-configurable - in other words, it cannot take a `select()` value. If the `configurable` is either unbound or explicitly set to `True`, the attribute is configurable and can take a `select()` value. For an attribute of a rule or aspect, `configurable` must be left unbound. Most Starlark rule attributes are always configurable, with the exception of `attr.output()`, `attr.output_list()`, and `attr.license()` rule attributes, which are always non-configurable. |
-| `default` | [Label](../builtins/Label); or [string](../core/string); or [LateBoundDefault](../builtins/LateBoundDefault); or NativeComputedDefault; or [function](../core/function); or `None`; default is `None`  A default value to use if no value for this attribute is given when instantiating the rule.Use a string or the [`Label`](../builtins/Label#Label) function to specify a default value, for example, `attr.label(default = "//a:b")`. |
-| `materializer` | [function](../core/function); default is `None`  **Experimental**. This parameter is experimental and may change at any time. Please do not depend on it. It may be enabled on an experimental basis by setting `--experimental_dormant_deps`  If set, the attribute materializes dormant dependencies from the transitive closure. The value of this parameter must be a functon that gets access to the values of the attributes of the rule that either are not dependencies or are marked as available for dependency resolution. It must return either a dormant dependency or a list of them depending on the type of the attribute |
-| `doc` | [string](../core/string); or `None`; default is `None` |
-| `executable` | [bool](../core/bool); default is `False`  True if the dependency has to be executable. This means the label must refer to an executable file, or to a rule that outputs an executable file. Access the label with `ctx.executable.`. |
-| `allow_files` | [bool](../core/bool); or [sequence](../core/list) of [string](../core/string)s; or `None`; default is `None`  Whether `File` targets are allowed. Can be `True`, `False` (default), or a list of file extensions that are allowed (for example, `[".cc", ".cpp"]`). |
-| `allow_single_file` | default is `None`  This is similar to `allow_files`, with the restriction that the label must correspond to a single [File](../builtins/File). Access it through `ctx.file.`. |
-| `mandatory` | [bool](../core/bool); default is `False`  If true, the value must be specified explicitly (even if it has a `default`). |
-| `skip_validations` | [bool](../core/bool); default is `False`  If true, validation actions of transitive dependencies from this attribute will not run. This is a temporary mitigation and WILL be removed in the future. |
-| `providers` | [sequence](../core/list); default is `[]`  The providers that must be given by any dependency appearing in this attribute. The format of this argument is a list of lists of providers -- `*Info` objects returned by [`provider()`](../globals/bzl#provider) (or in the case of a legacy provider, its string name). The dependency must return ALL providers mentioned in at least ONE of the inner lists. As a convenience, this argument may also be a single-level list of providers, in which case it is wrapped in an outer list with one element. It is NOT required that the rule of the dependency advertises those providers in its `provides` parameter, however, it is considered best practice. |
+| `configurable` | [bool](/versions/8.1.1/rules/lib/core/bool); or unbound; default is `unbound`  This argument can only be specified for an attribute of a symbolic macro. If `configurable` is explicitly set to `False`, the symbolic macro attribute is non-configurable - in other words, it cannot take a `select()` value. If the `configurable` is either unbound or explicitly set to `True`, the attribute is configurable and can take a `select()` value. For an attribute of a rule or aspect, `configurable` must be left unbound. Most Starlark rule attributes are always configurable, with the exception of `attr.output()`, `attr.output_list()`, and `attr.license()` rule attributes, which are always non-configurable. |
+| `default` | [Label](/versions/8.1.1/rules/lib/builtins/Label); or [string](/versions/8.1.1/rules/lib/core/string); or [LateBoundDefault](/versions/8.1.1/rules/lib/builtins/LateBoundDefault); or NativeComputedDefault; or [function](/versions/8.1.1/rules/lib/core/function); or `None`; default is `None`  A default value to use if no value for this attribute is given when instantiating the rule.Use a string or the [`Label`](/versions/8.1.1/rules/lib/builtins/Label#Label) function to specify a default value, for example, `attr.label(default = "//a:b")`. |
+| `materializer` | [function](/versions/8.1.1/rules/lib/core/function); default is `None`  **Experimental**. This parameter is experimental and may change at any time. Please do not depend on it. It may be enabled on an experimental basis by setting `--experimental_dormant_deps`  If set, the attribute materializes dormant dependencies from the transitive closure. The value of this parameter must be a functon that gets access to the values of the attributes of the rule that either are not dependencies or are marked as available for dependency resolution. It must return either a dormant dependency or a list of them depending on the type of the attribute |
+| `doc` | [string](/versions/8.1.1/rules/lib/core/string); or `None`; default is `None` |
+| `executable` | [bool](/versions/8.1.1/rules/lib/core/bool); default is `False`  True if the dependency has to be executable. This means the label must refer to an executable file, or to a rule that outputs an executable file. Access the label with `ctx.executable.`. |
+| `allow_files` | [bool](/versions/8.1.1/rules/lib/core/bool); or [sequence](/versions/8.1.1/rules/lib/core/list) of [string](/versions/8.1.1/rules/lib/core/string)s; or `None`; default is `None`  Whether `File` targets are allowed. Can be `True`, `False` (default), or a list of file extensions that are allowed (for example, `[".cc", ".cpp"]`). |
+| `allow_single_file` | default is `None`  This is similar to `allow_files`, with the restriction that the label must correspond to a single [File](/versions/8.1.1/rules/lib/builtins/File). Access it through `ctx.file.`. |
+| `mandatory` | [bool](/versions/8.1.1/rules/lib/core/bool); default is `False`  If true, the value must be specified explicitly (even if it has a `default`). |
+| `skip_validations` | [bool](/versions/8.1.1/rules/lib/core/bool); default is `False`  If true, validation actions of transitive dependencies from this attribute will not run. This is a temporary mitigation and WILL be removed in the future. |
+| `providers` | [sequence](/versions/8.1.1/rules/lib/core/list); default is `[]`  The providers that must be given by any dependency appearing in this attribute. The format of this argument is a list of lists of providers -- `*Info` objects returned by [`provider()`](/versions/8.1.1/rules/lib/globals/bzl#provider) (or in the case of a legacy provider, its string name). The dependency must return ALL providers mentioned in at least ONE of the inner lists. As a convenience, this argument may also be a single-level list of providers, in which case it is wrapped in an outer list with one element. It is NOT required that the rule of the dependency advertises those providers in its `provides` parameter, however, it is considered best practice. |
 | `for_dependency_resolution` | default is `unbound`  If this is set, the attribute is available for materializers. Only rules marked with the flag of the same name are allowed to be referenced through such attributes. |
-| `allow_rules` | [sequence](../core/list) of [string](../core/string)s; or `None`; default is `None`  Which rule targets (name of the classes) are allowed. This is deprecated (kept only for compatibility), use providers instead. |
+| `allow_rules` | [sequence](/versions/8.1.1/rules/lib/core/list) of [string](/versions/8.1.1/rules/lib/core/string)s; or `None`; default is `None`  Which rule targets (name of the classes) are allowed. This is deprecated (kept only for compatibility), use providers instead. |
 | `cfg` | default is `None`  [Configuration](https://bazel.build/versions/8.1.1/extending/rules#configurations) of the attribute. It can be either `"exec"`, which indicates that the dependency is built for the `execution platform`, or `"target"`, which indicates that the dependency is build for the `target platform`. A typical example of the difference is when building mobile apps, where the `target platform` is `Android` or `iOS` while the `execution platform` is `Linux`, `macOS`, or `Windows`. This parameter is required if `executable` is True to guard against accidentally building host tools in the target configuration. `"target"` has no semantic effect, so don't set it when `executable` is False unless it really helps clarify your intentions. |
-| `aspects` | [sequence](../core/list) of [Aspect](../builtins/Aspect)s; default is `[]`  Aspects that should be applied to the dependency or dependencies specified by this attribute. |
-| `flags` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  Deprecated, will be removed. |
+| `aspects` | [sequence](/versions/8.1.1/rules/lib/core/list) of [Aspect](/versions/8.1.1/rules/lib/builtins/Aspect)s; default is `[]`  Aspects that should be applied to the dependency or dependencies specified by this attribute. |
+| `flags` | [sequence](/versions/8.1.1/rules/lib/core/list) of [string](/versions/8.1.1/rules/lib/core/string)s; default is `[]`  Deprecated, will be removed. |
 
 ## label\_keyed\_string\_dict
 
@@ -118,26 +118,26 @@ Attribute attr.label_keyed_string_dict(allow_empty=True, *, configurable=unbound
 
 Creates a schema for an attribute holding a dictionary, where the keys are labels and the values are strings. This is a dependency attribute.
 
-This attribute contains unique [`Label`](../builtins/Label) values. If a string is supplied in place of a `Label`, it will be converted using the [label constructor](../builtins/Label#Label). The relative parts of the label path, including the (possibly renamed) repository, are resolved with respect to the instantiated target's package.
+This attribute contains unique [`Label`](/versions/8.1.1/rules/lib/builtins/Label) values. If a string is supplied in place of a `Label`, it will be converted using the [label constructor](/versions/8.1.1/rules/lib/builtins/Label#Label). The relative parts of the label path, including the (possibly renamed) repository, are resolved with respect to the instantiated target's package.
 
-At analysis time (within the rule's implementation function), when retrieving the attribute value from `ctx.attr`, labels are replaced by the corresponding [`Target`](../builtins/Target)s. This allows you to access the providers of the current target's dependencies.
+At analysis time (within the rule's implementation function), when retrieving the attribute value from `ctx.attr`, labels are replaced by the corresponding [`Target`](/versions/8.1.1/rules/lib/builtins/Target)s. This allows you to access the providers of the current target's dependencies.
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `allow_empty` | [bool](../core/bool); default is `True`  True if the attribute can be empty. |
-| `configurable` | [bool](../core/bool); or unbound; default is `unbound`  This argument can only be specified for an attribute of a symbolic macro. If `configurable` is explicitly set to `False`, the symbolic macro attribute is non-configurable - in other words, it cannot take a `select()` value. If the `configurable` is either unbound or explicitly set to `True`, the attribute is configurable and can take a `select()` value. For an attribute of a rule or aspect, `configurable` must be left unbound. Most Starlark rule attributes are always configurable, with the exception of `attr.output()`, `attr.output_list()`, and `attr.license()` rule attributes, which are always non-configurable. |
-| `default` | [dict](../core/dict); or [function](../core/function); default is `{}`  A default value to use if no value for this attribute is given when instantiating the rule.Use strings or the [`Label`](../builtins/Label#Label) function to specify default values, for example, `attr.label_keyed_string_dict(default = {"//a:b": "value", "//a:c": "string"})`. |
-| `doc` | [string](../core/string); or `None`; default is `None`  A description of the attribute that can be extracted by documentation generating tools. |
-| `allow_files` | [bool](../core/bool); or [sequence](../core/list) of [string](../core/string)s; or `None`; default is `None`  Whether `File` targets are allowed. Can be `True`, `False` (default), or a list of file extensions that are allowed (for example, `[".cc", ".cpp"]`). |
-| `allow_rules` | [sequence](../core/list) of [string](../core/string)s; or `None`; default is `None`  Which rule targets (name of the classes) are allowed. This is deprecated (kept only for compatibility), use providers instead. |
-| `providers` | [sequence](../core/list); default is `[]`  The providers that must be given by any dependency appearing in this attribute. The format of this argument is a list of lists of providers -- `*Info` objects returned by [`provider()`](../globals/bzl#provider) (or in the case of a legacy provider, its string name). The dependency must return ALL providers mentioned in at least ONE of the inner lists. As a convenience, this argument may also be a single-level list of providers, in which case it is wrapped in an outer list with one element. It is NOT required that the rule of the dependency advertises those providers in its `provides` parameter, however, it is considered best practice. |
+| `allow_empty` | [bool](/versions/8.1.1/rules/lib/core/bool); default is `True`  True if the attribute can be empty. |
+| `configurable` | [bool](/versions/8.1.1/rules/lib/core/bool); or unbound; default is `unbound`  This argument can only be specified for an attribute of a symbolic macro. If `configurable` is explicitly set to `False`, the symbolic macro attribute is non-configurable - in other words, it cannot take a `select()` value. If the `configurable` is either unbound or explicitly set to `True`, the attribute is configurable and can take a `select()` value. For an attribute of a rule or aspect, `configurable` must be left unbound. Most Starlark rule attributes are always configurable, with the exception of `attr.output()`, `attr.output_list()`, and `attr.license()` rule attributes, which are always non-configurable. |
+| `default` | [dict](/versions/8.1.1/rules/lib/core/dict); or [function](/versions/8.1.1/rules/lib/core/function); default is `{}`  A default value to use if no value for this attribute is given when instantiating the rule.Use strings or the [`Label`](/versions/8.1.1/rules/lib/builtins/Label#Label) function to specify default values, for example, `attr.label_keyed_string_dict(default = {"//a:b": "value", "//a:c": "string"})`. |
+| `doc` | [string](/versions/8.1.1/rules/lib/core/string); or `None`; default is `None`  A description of the attribute that can be extracted by documentation generating tools. |
+| `allow_files` | [bool](/versions/8.1.1/rules/lib/core/bool); or [sequence](/versions/8.1.1/rules/lib/core/list) of [string](/versions/8.1.1/rules/lib/core/string)s; or `None`; default is `None`  Whether `File` targets are allowed. Can be `True`, `False` (default), or a list of file extensions that are allowed (for example, `[".cc", ".cpp"]`). |
+| `allow_rules` | [sequence](/versions/8.1.1/rules/lib/core/list) of [string](/versions/8.1.1/rules/lib/core/string)s; or `None`; default is `None`  Which rule targets (name of the classes) are allowed. This is deprecated (kept only for compatibility), use providers instead. |
+| `providers` | [sequence](/versions/8.1.1/rules/lib/core/list); default is `[]`  The providers that must be given by any dependency appearing in this attribute. The format of this argument is a list of lists of providers -- `*Info` objects returned by [`provider()`](/versions/8.1.1/rules/lib/globals/bzl#provider) (or in the case of a legacy provider, its string name). The dependency must return ALL providers mentioned in at least ONE of the inner lists. As a convenience, this argument may also be a single-level list of providers, in which case it is wrapped in an outer list with one element. It is NOT required that the rule of the dependency advertises those providers in its `provides` parameter, however, it is considered best practice. |
 | `for_dependency_resolution` | default is `unbound`  If this is set, the attribute is available for materializers. Only rules marked with the flag of the same name are allowed to be referenced through such attributes. |
-| `flags` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  Deprecated, will be removed. |
-| `mandatory` | [bool](../core/bool); default is `False`  If true, the value must be specified explicitly (even if it has a `default`). |
+| `flags` | [sequence](/versions/8.1.1/rules/lib/core/list) of [string](/versions/8.1.1/rules/lib/core/string)s; default is `[]`  Deprecated, will be removed. |
+| `mandatory` | [bool](/versions/8.1.1/rules/lib/core/bool); default is `False`  If true, the value must be specified explicitly (even if it has a `default`). |
 | `cfg` | default is `None`  [Configuration](https://bazel.build/versions/8.1.1/extending/rules#configurations) of the attribute. It can be either `"exec"`, which indicates that the dependency is built for the `execution platform`, or `"target"`, which indicates that the dependency is build for the `target platform`. A typical example of the difference is when building mobile apps, where the `target platform` is `Android` or `iOS` while the `execution platform` is `Linux`, `macOS`, or `Windows`. |
-| `aspects` | [sequence](../core/list) of [Aspect](../builtins/Aspect)s; default is `[]`  Aspects that should be applied to the dependency or dependencies specified by this attribute. |
+| `aspects` | [sequence](/versions/8.1.1/rules/lib/core/list) of [Aspect](/versions/8.1.1/rules/lib/builtins/Aspect)s; default is `[]`  Aspects that should be applied to the dependency or dependencies specified by this attribute. |
 
 ## label\_list
 
@@ -145,30 +145,30 @@ At analysis time (within the rule's implementation function), when retrieving th
 Attribute attr.label_list(allow_empty=True, *, configurable=unbound, default=[], materializer=None, doc=None, allow_files=None, allow_rules=None, providers=[], for_dependency_resolution=unbound, flags=[], mandatory=False, skip_validations=False, cfg=None, aspects=[])
 ```
 
-Creates a schema for a list-of-labels attribute. This is a dependency attribute. The corresponding [`ctx.attr`](../builtins/ctx#attr) attribute will be of type [list](../core/list) of [`Target`s](../builtins/Target).
+Creates a schema for a list-of-labels attribute. This is a dependency attribute. The corresponding [`ctx.attr`](/versions/8.1.1/rules/lib/builtins/ctx#attr) attribute will be of type [list](/versions/8.1.1/rules/lib/core/list) of [`Target`s](/versions/8.1.1/rules/lib/builtins/Target).
 
-This attribute contains unique [`Label`](../builtins/Label) values. If a string is supplied in place of a `Label`, it will be converted using the [label constructor](../builtins/Label#Label). The relative parts of the label path, including the (possibly renamed) repository, are resolved with respect to the instantiated target's package.
+This attribute contains unique [`Label`](/versions/8.1.1/rules/lib/builtins/Label) values. If a string is supplied in place of a `Label`, it will be converted using the [label constructor](/versions/8.1.1/rules/lib/builtins/Label#Label). The relative parts of the label path, including the (possibly renamed) repository, are resolved with respect to the instantiated target's package.
 
-At analysis time (within the rule's implementation function), when retrieving the attribute value from `ctx.attr`, labels are replaced by the corresponding [`Target`](../builtins/Target)s. This allows you to access the providers of the current target's dependencies.
+At analysis time (within the rule's implementation function), when retrieving the attribute value from `ctx.attr`, labels are replaced by the corresponding [`Target`](/versions/8.1.1/rules/lib/builtins/Target)s. This allows you to access the providers of the current target's dependencies.
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `allow_empty` | [bool](../core/bool); default is `True`  True if the attribute can be empty. |
-| `configurable` | [bool](../core/bool); or unbound; default is `unbound`  This argument can only be specified for an attribute of a symbolic macro. If `configurable` is explicitly set to `False`, the symbolic macro attribute is non-configurable - in other words, it cannot take a `select()` value. If the `configurable` is either unbound or explicitly set to `True`, the attribute is configurable and can take a `select()` value. For an attribute of a rule or aspect, `configurable` must be left unbound. Most Starlark rule attributes are always configurable, with the exception of `attr.output()`, `attr.output_list()`, and `attr.license()` rule attributes, which are always non-configurable. |
-| `default` | [sequence](../core/list) of [Label](../builtins/Label)s; or [function](../core/function); default is `[]`  A default value to use if no value for this attribute is given when instantiating the rule.Use strings or the [`Label`](../builtins/Label#Label) function to specify default values, for example, `attr.label_list(default = ["//a:b", "//a:c"])`. |
-| `materializer` | [function](../core/function); default is `None`  **Experimental**. This parameter is experimental and may change at any time. Please do not depend on it. It may be enabled on an experimental basis by setting `--experimental_dormant_deps`  If set, the attribute materializes dormant dependencies from the transitive closure. The value of this parameter must be a functon that gets access to the values of the attributes of the rule that either are not dependencies or are marked as available for dependency resolution. It must return either a dormant dependency or a list of them depending on the type of the attribute |
-| `doc` | [string](../core/string); or `None`; default is `None` |
-| `allow_files` | [bool](../core/bool); or [sequence](../core/list) of [string](../core/string)s; or `None`; default is `None`  Whether `File` targets are allowed. Can be `True`, `False` (default), or a list of file extensions that are allowed (for example, `[".cc", ".cpp"]`). |
-| `allow_rules` | [sequence](../core/list) of [string](../core/string)s; or `None`; default is `None`  Which rule targets (name of the classes) are allowed. This is deprecated (kept only for compatibility), use providers instead. |
-| `providers` | [sequence](../core/list); default is `[]`  The providers that must be given by any dependency appearing in this attribute. The format of this argument is a list of lists of providers -- `*Info` objects returned by [`provider()`](../globals/bzl#provider) (or in the case of a legacy provider, its string name). The dependency must return ALL providers mentioned in at least ONE of the inner lists. As a convenience, this argument may also be a single-level list of providers, in which case it is wrapped in an outer list with one element. It is NOT required that the rule of the dependency advertises those providers in its `provides` parameter, however, it is considered best practice. |
+| `allow_empty` | [bool](/versions/8.1.1/rules/lib/core/bool); default is `True`  True if the attribute can be empty. |
+| `configurable` | [bool](/versions/8.1.1/rules/lib/core/bool); or unbound; default is `unbound`  This argument can only be specified for an attribute of a symbolic macro. If `configurable` is explicitly set to `False`, the symbolic macro attribute is non-configurable - in other words, it cannot take a `select()` value. If the `configurable` is either unbound or explicitly set to `True`, the attribute is configurable and can take a `select()` value. For an attribute of a rule or aspect, `configurable` must be left unbound. Most Starlark rule attributes are always configurable, with the exception of `attr.output()`, `attr.output_list()`, and `attr.license()` rule attributes, which are always non-configurable. |
+| `default` | [sequence](/versions/8.1.1/rules/lib/core/list) of [Label](/versions/8.1.1/rules/lib/builtins/Label)s; or [function](/versions/8.1.1/rules/lib/core/function); default is `[]`  A default value to use if no value for this attribute is given when instantiating the rule.Use strings or the [`Label`](/versions/8.1.1/rules/lib/builtins/Label#Label) function to specify default values, for example, `attr.label_list(default = ["//a:b", "//a:c"])`. |
+| `materializer` | [function](/versions/8.1.1/rules/lib/core/function); default is `None`  **Experimental**. This parameter is experimental and may change at any time. Please do not depend on it. It may be enabled on an experimental basis by setting `--experimental_dormant_deps`  If set, the attribute materializes dormant dependencies from the transitive closure. The value of this parameter must be a functon that gets access to the values of the attributes of the rule that either are not dependencies or are marked as available for dependency resolution. It must return either a dormant dependency or a list of them depending on the type of the attribute |
+| `doc` | [string](/versions/8.1.1/rules/lib/core/string); or `None`; default is `None` |
+| `allow_files` | [bool](/versions/8.1.1/rules/lib/core/bool); or [sequence](/versions/8.1.1/rules/lib/core/list) of [string](/versions/8.1.1/rules/lib/core/string)s; or `None`; default is `None`  Whether `File` targets are allowed. Can be `True`, `False` (default), or a list of file extensions that are allowed (for example, `[".cc", ".cpp"]`). |
+| `allow_rules` | [sequence](/versions/8.1.1/rules/lib/core/list) of [string](/versions/8.1.1/rules/lib/core/string)s; or `None`; default is `None`  Which rule targets (name of the classes) are allowed. This is deprecated (kept only for compatibility), use providers instead. |
+| `providers` | [sequence](/versions/8.1.1/rules/lib/core/list); default is `[]`  The providers that must be given by any dependency appearing in this attribute. The format of this argument is a list of lists of providers -- `*Info` objects returned by [`provider()`](/versions/8.1.1/rules/lib/globals/bzl#provider) (or in the case of a legacy provider, its string name). The dependency must return ALL providers mentioned in at least ONE of the inner lists. As a convenience, this argument may also be a single-level list of providers, in which case it is wrapped in an outer list with one element. It is NOT required that the rule of the dependency advertises those providers in its `provides` parameter, however, it is considered best practice. |
 | `for_dependency_resolution` | default is `unbound`  If this is set, the attribute is available for materializers. Only rules marked with the flag of the same name are allowed to be referenced through such attributes. |
-| `flags` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  Deprecated, will be removed. |
-| `mandatory` | [bool](../core/bool); default is `False`  If true, the value must be specified explicitly (even if it has a `default`). |
-| `skip_validations` | [bool](../core/bool); default is `False`  If true, validation actions of transitive dependencies from this attribute will not run. This is a temporary mitigation and WILL be removed in the future. |
+| `flags` | [sequence](/versions/8.1.1/rules/lib/core/list) of [string](/versions/8.1.1/rules/lib/core/string)s; default is `[]`  Deprecated, will be removed. |
+| `mandatory` | [bool](/versions/8.1.1/rules/lib/core/bool); default is `False`  If true, the value must be specified explicitly (even if it has a `default`). |
+| `skip_validations` | [bool](/versions/8.1.1/rules/lib/core/bool); default is `False`  If true, validation actions of transitive dependencies from this attribute will not run. This is a temporary mitigation and WILL be removed in the future. |
 | `cfg` | default is `None`  [Configuration](https://bazel.build/versions/8.1.1/extending/rules#configurations) of the attribute. It can be either `"exec"`, which indicates that the dependency is built for the `execution platform`, or `"target"`, which indicates that the dependency is build for the `target platform`. A typical example of the difference is when building mobile apps, where the `target platform` is `Android` or `iOS` while the `execution platform` is `Linux`, `macOS`, or `Windows`. |
-| `aspects` | [sequence](../core/list) of [Aspect](../builtins/Aspect)s; default is `[]`  Aspects that should be applied to the dependency or dependencies specified by this attribute. |
+| `aspects` | [sequence](/versions/8.1.1/rules/lib/core/list) of [Aspect](/versions/8.1.1/rules/lib/builtins/Aspect)s; default is `[]`  Aspects that should be applied to the dependency or dependencies specified by this attribute. |
 
 ## output
 
@@ -178,16 +178,16 @@ Attribute attr.output(doc=None, mandatory=False)
 
 Creates a schema for an output (label) attribute.
 
-This attribute contains unique [`Label`](../builtins/Label) values. If a string is supplied in place of a `Label`, it will be converted using the [label constructor](../builtins/Label#Label). The relative parts of the label path, including the (possibly renamed) repository, are resolved with respect to the instantiated target's package.
+This attribute contains unique [`Label`](/versions/8.1.1/rules/lib/builtins/Label) values. If a string is supplied in place of a `Label`, it will be converted using the [label constructor](/versions/8.1.1/rules/lib/builtins/Label#Label). The relative parts of the label path, including the (possibly renamed) repository, are resolved with respect to the instantiated target's package.
 
-At analysis time, the corresponding [`File`](../builtins/File) can be retrieved using [`ctx.outputs`](../builtins/ctx#outputs).
+At analysis time, the corresponding [`File`](/versions/8.1.1/rules/lib/builtins/File) can be retrieved using [`ctx.outputs`](/versions/8.1.1/rules/lib/builtins/ctx#outputs).
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `doc` | [string](../core/string); or `None`; default is `None`  A description of the attribute that can be extracted by documentation generating tools. |
-| `mandatory` | [bool](../core/bool); default is `False`  If true, the value must be specified explicitly (even if it has a `default`). |
+| `doc` | [string](/versions/8.1.1/rules/lib/core/string); or `None`; default is `None`  A description of the attribute that can be extracted by documentation generating tools. |
+| `mandatory` | [bool](/versions/8.1.1/rules/lib/core/bool); default is `False`  If true, the value must be specified explicitly (even if it has a `default`). |
 
 ## output\_list
 
@@ -197,17 +197,17 @@ Attribute attr.output_list(allow_empty=True, *, doc=None, mandatory=False)
 
 Creates a schema for a list-of-outputs attribute.
 
-This attribute contains unique [`Label`](../builtins/Label) values. If a string is supplied in place of a `Label`, it will be converted using the [label constructor](../builtins/Label#Label). The relative parts of the label path, including the (possibly renamed) repository, are resolved with respect to the instantiated target's package.
+This attribute contains unique [`Label`](/versions/8.1.1/rules/lib/builtins/Label) values. If a string is supplied in place of a `Label`, it will be converted using the [label constructor](/versions/8.1.1/rules/lib/builtins/Label#Label). The relative parts of the label path, including the (possibly renamed) repository, are resolved with respect to the instantiated target's package.
 
-At analysis time, the corresponding [`File`](../builtins/File) can be retrieved using [`ctx.outputs`](../builtins/ctx#outputs).
+At analysis time, the corresponding [`File`](/versions/8.1.1/rules/lib/builtins/File) can be retrieved using [`ctx.outputs`](/versions/8.1.1/rules/lib/builtins/ctx#outputs).
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `allow_empty` | [bool](../core/bool); default is `True`  True if the attribute can be empty. |
-| `doc` | [string](../core/string); or `None`; default is `None`  A description of the attribute that can be extracted by documentation generating tools. |
-| `mandatory` | [bool](../core/bool); default is `False`  If true, the value must be specified explicitly (even if it has a `default`). |
+| `allow_empty` | [bool](/versions/8.1.1/rules/lib/core/bool); default is `True`  True if the attribute can be empty. |
+| `doc` | [string](/versions/8.1.1/rules/lib/core/string); or `None`; default is `None`  A description of the attribute that can be extracted by documentation generating tools. |
+| `mandatory` | [bool](/versions/8.1.1/rules/lib/core/bool); default is `False`  If true, the value must be specified explicitly (even if it has a `default`). |
 
 ## string
 
@@ -215,17 +215,17 @@ At analysis time, the corresponding [`File`](../builtins/File) can be retrieved
 Attribute attr.string(configurable=unbound, default='', doc=None, mandatory=False, values=[])
 ```
 
-Creates a schema for a [string](../core/string#attr) attribute.
+Creates a schema for a [string](/versions/8.1.1/rules/lib/core/string#attr) attribute.
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `configurable` | [bool](../core/bool); or unbound; default is `unbound`  This argument can only be specified for an attribute of a symbolic macro. If `configurable` is explicitly set to `False`, the symbolic macro attribute is non-configurable - in other words, it cannot take a `select()` value. If the `configurable` is either unbound or explicitly set to `True`, the attribute is configurable and can take a `select()` value. For an attribute of a rule or aspect, `configurable` must be left unbound. Most Starlark rule attributes are always configurable, with the exception of `attr.output()`, `attr.output_list()`, and `attr.license()` rule attributes, which are always non-configurable. |
-| `default` | [string](../core/string); or NativeComputedDefault; default is `''`  A default value to use if no value for this attribute is given when instantiating the rule. |
-| `doc` | [string](../core/string); or `None`; default is `None`  A description of the attribute that can be extracted by documentation generating tools. |
-| `mandatory` | [bool](../core/bool); default is `False`  If true, the value must be specified explicitly (even if it has a `default`). |
-| `values` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  The list of allowed values for the attribute. An error is raised if any other value is given. |
+| `configurable` | [bool](/versions/8.1.1/rules/lib/core/bool); or unbound; default is `unbound`  This argument can only be specified for an attribute of a symbolic macro. If `configurable` is explicitly set to `False`, the symbolic macro attribute is non-configurable - in other words, it cannot take a `select()` value. If the `configurable` is either unbound or explicitly set to `True`, the attribute is configurable and can take a `select()` value. For an attribute of a rule or aspect, `configurable` must be left unbound. Most Starlark rule attributes are always configurable, with the exception of `attr.output()`, `attr.output_list()`, and `attr.license()` rule attributes, which are always non-configurable. |
+| `default` | [string](/versions/8.1.1/rules/lib/core/string); or NativeComputedDefault; default is `''`  A default value to use if no value for this attribute is given when instantiating the rule. |
+| `doc` | [string](/versions/8.1.1/rules/lib/core/string); or `None`; default is `None`  A description of the attribute that can be extracted by documentation generating tools. |
+| `mandatory` | [bool](/versions/8.1.1/rules/lib/core/bool); default is `False`  If true, the value must be specified explicitly (even if it has a `default`). |
+| `values` | [sequence](/versions/8.1.1/rules/lib/core/list) of [string](/versions/8.1.1/rules/lib/core/string)s; default is `[]`  The list of allowed values for the attribute. An error is raised if any other value is given. |
 
 ## string\_dict
 
@@ -239,11 +239,11 @@ Creates a schema for an attribute holding a dictionary, where the keys and value
 
 | Parameter | Description |
 | --- | --- |
-| `allow_empty` | [bool](../core/bool); default is `True`  True if the attribute can be empty. |
-| `configurable` | [bool](../core/bool); or unbound; default is `unbound`  This argument can only be specified for an attribute of a symbolic macro. If `configurable` is explicitly set to `False`, the symbolic macro attribute is non-configurable - in other words, it cannot take a `select()` value. If the `configurable` is either unbound or explicitly set to `True`, the attribute is configurable and can take a `select()` value. For an attribute of a rule or aspect, `configurable` must be left unbound. Most Starlark rule attributes are always configurable, with the exception of `attr.output()`, `attr.output_list()`, and `attr.license()` rule attributes, which are always non-configurable. |
-| `default` | [dict](../core/dict); default is `{}`  A default value to use if no value for this attribute is given when instantiating the rule. |
-| `doc` | [string](../core/string); or `None`; default is `None`  A description of the attribute that can be extracted by documentation generating tools. |
-| `mandatory` | [bool](../core/bool); default is `False`  If true, the value must be specified explicitly (even if it has a `default`). |
+| `allow_empty` | [bool](/versions/8.1.1/rules/lib/core/bool); default is `True`  True if the attribute can be empty. |
+| `configurable` | [bool](/versions/8.1.1/rules/lib/core/bool); or unbound; default is `unbound`  This argument can only be specified for an attribute of a symbolic macro. If `configurable` is explicitly set to `False`, the symbolic macro attribute is non-configurable - in other words, it cannot take a `select()` value. If the `configurable` is either unbound or explicitly set to `True`, the attribute is configurable and can take a `select()` value. For an attribute of a rule or aspect, `configurable` must be left unbound. Most Starlark rule attributes are always configurable, with the exception of `attr.output()`, `attr.output_list()`, and `attr.license()` rule attributes, which are always non-configurable. |
+| `default` | [dict](/versions/8.1.1/rules/lib/core/dict); default is `{}`  A default value to use if no value for this attribute is given when instantiating the rule. |
+| `doc` | [string](/versions/8.1.1/rules/lib/core/string); or `None`; default is `None`  A description of the attribute that can be extracted by documentation generating tools. |
+| `mandatory` | [bool](/versions/8.1.1/rules/lib/core/bool); default is `False`  If true, the value must be specified explicitly (even if it has a `default`). |
 
 ## string\_keyed\_label\_dict
 
@@ -253,26 +253,26 @@ Attribute attr.string_keyed_label_dict(allow_empty=True, *, configurable=unbound
 
 Creates a schema for an attribute whose value is a dictionary where the keys are strings and the values are labels. This is a dependency attribute.
 
-This attribute contains unique [`Label`](../builtins/Label) values. If a string is supplied in place of a `Label`, it will be converted using the [label constructor](../builtins/Label#Label). The relative parts of the label path, including the (possibly renamed) repository, are resolved with respect to the instantiated target's package.
+This attribute contains unique [`Label`](/versions/8.1.1/rules/lib/builtins/Label) values. If a string is supplied in place of a `Label`, it will be converted using the [label constructor](/versions/8.1.1/rules/lib/builtins/Label#Label). The relative parts of the label path, including the (possibly renamed) repository, are resolved with respect to the instantiated target's package.
 
-At analysis time (within the rule's implementation function), when retrieving the attribute value from `ctx.attr`, labels are replaced by the corresponding [`Target`](../builtins/Target)s. This allows you to access the providers of the current target's dependencies.
+At analysis time (within the rule's implementation function), when retrieving the attribute value from `ctx.attr`, labels are replaced by the corresponding [`Target`](/versions/8.1.1/rules/lib/builtins/Target)s. This allows you to access the providers of the current target's dependencies.
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `allow_empty` | [bool](../core/bool); default is `True`  True if the attribute can be empty. |
-| `configurable` | [bool](../core/bool); or unbound; default is `unbound`  This argument can only be specified for an attribute of a symbolic macro. If `configurable` is explicitly set to `False`, the symbolic macro attribute is non-configurable - in other words, it cannot take a `select()` value. If the `configurable` is either unbound or explicitly set to `True`, the attribute is configurable and can take a `select()` value. For an attribute of a rule or aspect, `configurable` must be left unbound. Most Starlark rule attributes are always configurable, with the exception of `attr.output()`, `attr.output_list()`, and `attr.license()` rule attributes, which are always non-configurable. |
-| `default` | [dict](../core/dict); or [function](../core/function); default is `{}`  A default value to use if no value for this attribute is given when instantiating the rule.Use strings or the [`Label`](../builtins/Label#Label) function to specify default values, for example, `attr.string_keyed_label_dict(default = {"foo": "//a:b", "bar": "//a:c"})`. |
-| `doc` | [string](../core/string); or `None`; default is `None`  A description of the attribute that can be extracted by documentation generating tools. |
-| `allow_files` | [bool](../core/bool); or [sequence](../core/list) of [string](../core/string)s; or `None`; default is `None`  Whether `File` targets are allowed. Can be `True`, `False` (default), or a list of file extensions that are allowed (for example, `[".cc", ".cpp"]`). |
-| `allow_rules` | [sequence](../core/list) of [string](../core/string)s; or `None`; default is `None`  Which rule targets (name of the classes) are allowed. This is deprecated (kept only for compatibility), use providers instead. |
-| `providers` | [sequence](../core/list); default is `[]`  The providers that must be given by any dependency appearing in this attribute. The format of this argument is a list of lists of providers -- `*Info` objects returned by [`provider()`](../globals/bzl#provider) (or in the case of a legacy provider, its string name). The dependency must return ALL providers mentioned in at least ONE of the inner lists. As a convenience, this argument may also be a single-level list of providers, in which case it is wrapped in an outer list with one element. It is NOT required that the rule of the dependency advertises those providers in its `provides` parameter, however, it is considered best practice. |
+| `allow_empty` | [bool](/versions/8.1.1/rules/lib/core/bool); default is `True`  True if the attribute can be empty. |
+| `configurable` | [bool](/versions/8.1.1/rules/lib/core/bool); or unbound; default is `unbound`  This argument can only be specified for an attribute of a symbolic macro. If `configurable` is explicitly set to `False`, the symbolic macro attribute is non-configurable - in other words, it cannot take a `select()` value. If the `configurable` is either unbound or explicitly set to `True`, the attribute is configurable and can take a `select()` value. For an attribute of a rule or aspect, `configurable` must be left unbound. Most Starlark rule attributes are always configurable, with the exception of `attr.output()`, `attr.output_list()`, and `attr.license()` rule attributes, which are always non-configurable. |
+| `default` | [dict](/versions/8.1.1/rules/lib/core/dict); or [function](/versions/8.1.1/rules/lib/core/function); default is `{}`  A default value to use if no value for this attribute is given when instantiating the rule.Use strings or the [`Label`](/versions/8.1.1/rules/lib/builtins/Label#Label) function to specify default values, for example, `attr.string_keyed_label_dict(default = {"foo": "//a:b", "bar": "//a:c"})`. |
+| `doc` | [string](/versions/8.1.1/rules/lib/core/string); or `None`; default is `None`  A description of the attribute that can be extracted by documentation generating tools. |
+| `allow_files` | [bool](/versions/8.1.1/rules/lib/core/bool); or [sequence](/versions/8.1.1/rules/lib/core/list) of [string](/versions/8.1.1/rules/lib/core/string)s; or `None`; default is `None`  Whether `File` targets are allowed. Can be `True`, `False` (default), or a list of file extensions that are allowed (for example, `[".cc", ".cpp"]`). |
+| `allow_rules` | [sequence](/versions/8.1.1/rules/lib/core/list) of [string](/versions/8.1.1/rules/lib/core/string)s; or `None`; default is `None`  Which rule targets (name of the classes) are allowed. This is deprecated (kept only for compatibility), use providers instead. |
+| `providers` | [sequence](/versions/8.1.1/rules/lib/core/list); default is `[]`  The providers that must be given by any dependency appearing in this attribute. The format of this argument is a list of lists of providers -- `*Info` objects returned by [`provider()`](/versions/8.1.1/rules/lib/globals/bzl#provider) (or in the case of a legacy provider, its string name). The dependency must return ALL providers mentioned in at least ONE of the inner lists. As a convenience, this argument may also be a single-level list of providers, in which case it is wrapped in an outer list with one element. It is NOT required that the rule of the dependency advertises those providers in its `provides` parameter, however, it is considered best practice. |
 | `for_dependency_resolution` | default is `unbound`  If this is set, the attribute is available for materializers. Only rules marked with the flag of the same name are allowed to be referenced through such attributes. |
-| `flags` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  Deprecated, will be removed. |
-| `mandatory` | [bool](../core/bool); default is `False`  If true, the value must be specified explicitly (even if it has a `default`). |
+| `flags` | [sequence](/versions/8.1.1/rules/lib/core/list) of [string](/versions/8.1.1/rules/lib/core/string)s; default is `[]`  Deprecated, will be removed. |
+| `mandatory` | [bool](/versions/8.1.1/rules/lib/core/bool); default is `False`  If true, the value must be specified explicitly (even if it has a `default`). |
 | `cfg` | default is `None`  [Configuration](https://bazel.build/versions/8.1.1/extending/rules#configurations) of the attribute. It can be either `"exec"`, which indicates that the dependency is built for the `execution platform`, or `"target"`, which indicates that the dependency is build for the `target platform`. A typical example of the difference is when building mobile apps, where the `target platform` is `Android` or `iOS` while the `execution platform` is `Linux`, `macOS`, or `Windows`. |
-| `aspects` | [sequence](../core/list) of [Aspect](../builtins/Aspect)s; default is `[]`  Aspects that should be applied to the dependency or dependencies specified by this attribute. |
+| `aspects` | [sequence](/versions/8.1.1/rules/lib/core/list) of [Aspect](/versions/8.1.1/rules/lib/builtins/Aspect)s; default is `[]`  Aspects that should be applied to the dependency or dependencies specified by this attribute. |
 
 ## string\_list
 
@@ -286,11 +286,11 @@ Creates a schema for a list-of-strings attribute.
 
 | Parameter | Description |
 | --- | --- |
-| `mandatory` | [bool](../core/bool); default is `False`  If true, the value must be specified explicitly (even if it has a `default`). |
-| `allow_empty` | [bool](../core/bool); default is `True`  True if the attribute can be empty. |
-| `configurable` | [bool](../core/bool); or unbound; default is `unbound`  This argument can only be specified for an attribute of a symbolic macro. If `configurable` is explicitly set to `False`, the symbolic macro attribute is non-configurable - in other words, it cannot take a `select()` value. If the `configurable` is either unbound or explicitly set to `True`, the attribute is configurable and can take a `select()` value. For an attribute of a rule or aspect, `configurable` must be left unbound. Most Starlark rule attributes are always configurable, with the exception of `attr.output()`, `attr.output_list()`, and `attr.license()` rule attributes, which are always non-configurable. |
-| `default` | [sequence](../core/list) of [string](../core/string)s; or NativeComputedDefault; default is `[]`  A default value to use if no value for this attribute is given when instantiating the rule. |
-| `doc` | [string](../core/string); or `None`; default is `None`  A description of the attribute that can be extracted by documentation generating tools. |
+| `mandatory` | [bool](/versions/8.1.1/rules/lib/core/bool); default is `False`  If true, the value must be specified explicitly (even if it has a `default`). |
+| `allow_empty` | [bool](/versions/8.1.1/rules/lib/core/bool); default is `True`  True if the attribute can be empty. |
+| `configurable` | [bool](/versions/8.1.1/rules/lib/core/bool); or unbound; default is `unbound`  This argument can only be specified for an attribute of a symbolic macro. If `configurable` is explicitly set to `False`, the symbolic macro attribute is non-configurable - in other words, it cannot take a `select()` value. If the `configurable` is either unbound or explicitly set to `True`, the attribute is configurable and can take a `select()` value. For an attribute of a rule or aspect, `configurable` must be left unbound. Most Starlark rule attributes are always configurable, with the exception of `attr.output()`, `attr.output_list()`, and `attr.license()` rule attributes, which are always non-configurable. |
+| `default` | [sequence](/versions/8.1.1/rules/lib/core/list) of [string](/versions/8.1.1/rules/lib/core/string)s; or NativeComputedDefault; default is `[]`  A default value to use if no value for this attribute is given when instantiating the rule. |
+| `doc` | [string](/versions/8.1.1/rules/lib/core/string); or `None`; default is `None`  A description of the attribute that can be extracted by documentation generating tools. |
 
 ## string\_list\_dict
 
@@ -304,8 +304,8 @@ Creates a schema for an attribute holding a dictionary, where the keys are strin
 
 | Parameter | Description |
 | --- | --- |
-| `allow_empty` | [bool](../core/bool); default is `True`  True if the attribute can be empty. |
-| `configurable` | [bool](../core/bool); or unbound; default is `unbound`  This argument can only be specified for an attribute of a symbolic macro. If `configurable` is explicitly set to `False`, the symbolic macro attribute is non-configurable - in other words, it cannot take a `select()` value. If the `configurable` is either unbound or explicitly set to `True`, the attribute is configurable and can take a `select()` value. For an attribute of a rule or aspect, `configurable` must be left unbound. Most Starlark rule attributes are always configurable, with the exception of `attr.output()`, `attr.output_list()`, and `attr.license()` rule attributes, which are always non-configurable. |
-| `default` | [dict](../core/dict); default is `{}`  A default value to use if no value for this attribute is given when instantiating the rule. |
-| `doc` | [string](../core/string); or `None`; default is `None`  A description of the attribute that can be extracted by documentation generating tools. |
-| `mandatory` | [bool](../core/bool); default is `False`  If true, the value must be specified explicitly (even if it has a `default`). |
\ No newline at end of file
+| `allow_empty` | [bool](/versions/8.1.1/rules/lib/core/bool); default is `True`  True if the attribute can be empty. |
+| `configurable` | [bool](/versions/8.1.1/rules/lib/core/bool); or unbound; default is `unbound`  This argument can only be specified for an attribute of a symbolic macro. If `configurable` is explicitly set to `False`, the symbolic macro attribute is non-configurable - in other words, it cannot take a `select()` value. If the `configurable` is either unbound or explicitly set to `True`, the attribute is configurable and can take a `select()` value. For an attribute of a rule or aspect, `configurable` must be left unbound. Most Starlark rule attributes are always configurable, with the exception of `attr.output()`, `attr.output_list()`, and `attr.license()` rule attributes, which are always non-configurable. |
+| `default` | [dict](/versions/8.1.1/rules/lib/core/dict); default is `{}`  A default value to use if no value for this attribute is given when instantiating the rule. |
+| `doc` | [string](/versions/8.1.1/rules/lib/core/string); or `None`; default is `None`  A description of the attribute that can be extracted by documentation generating tools. |
+| `mandatory` | [bool](/versions/8.1.1/rules/lib/core/bool); default is `False`  If true, the value must be specified explicitly (even if it has a `default`). |
\ No newline at end of file
diff --git a/versions/8.1.1/rules/lib/toplevel/cc_common.mdx b/versions/8.1.1/rules/lib/toplevel/cc_common.mdx
index 1e6aebdc..821b505a 100644
--- a/versions/8.1.1/rules/lib/toplevel/cc_common.mdx
+++ b/versions/8.1.1/rules/lib/toplevel/cc_common.mdx
@@ -42,8 +42,8 @@ Returns True if given action\_config is enabled in the feature configuration.
 
 | Parameter | Description |
 | --- | --- |
-| `feature_configuration` | [FeatureConfiguration](../builtins/FeatureConfiguration); required  Feature configuration to be queried. |
-| `action_name` | [string](../core/string); required  Name of the action\_config. |
+| `feature_configuration` | [FeatureConfiguration](/versions/8.1.1/rules/lib/builtins/FeatureConfiguration); required  Feature configuration to be queried. |
+| `action_name` | [string](/versions/8.1.1/rules/lib/core/string); required  Name of the action\_config. |
 
 ## CcToolchainInfo
 
@@ -65,29 +65,29 @@ Should be used for C++ compilation. Returns tuple of (`CompilationContext`, `CcC
 
 | Parameter | Description |
 | --- | --- |
-| `actions` | [actions](../builtins/actions); required  `actions` object. |
-| `feature_configuration` | [FeatureConfiguration](../builtins/FeatureConfiguration); required  `feature_configuration` to be queried. |
+| `actions` | [actions](/versions/8.1.1/rules/lib/builtins/actions); required  `actions` object. |
+| `feature_configuration` | [FeatureConfiguration](/versions/8.1.1/rules/lib/builtins/FeatureConfiguration); required  `feature_configuration` to be queried. |
 | `cc_toolchain` | Info; required  `CcToolchainInfo` provider to be used. |
-| `srcs` | [sequence](../core/list); default is `[]`  The list of source files to be compiled. |
-| `public_hdrs` | [sequence](../core/list); default is `[]`  List of headers needed for compilation of srcs and may be included by dependent rules transitively. |
-| `private_hdrs` | [sequence](../core/list); default is `[]`  List of headers needed for compilation of srcs and NOT to be included by dependent rules. |
-| `includes` | [sequence](../core/list); or [depset](../builtins/depset); default is `[]`  Search paths for header files referenced both by angle bracket and quotes. Usually passed with -I. Propagated to dependents transitively. |
-| `quote_includes` | [sequence](../core/list); default is `[]`  Search paths for header files referenced by quotes, e.g. #include "foo/bar/header.h". They can be either relative to the exec root or absolute. Usually passed with -iquote. Propagated to dependents transitively. |
-| `system_includes` | [sequence](../core/list); default is `[]`  Search paths for header files referenced by angle brackets, e.g. #include <foo/bar/header.h>. They can be either relative to the exec root or absolute. Usually passed with -isystem. Propagated to dependents transitively. |
-| `framework_includes` | [sequence](../core/list); default is `[]`  Search paths for header files from Apple frameworks. They can be either relative to the exec root or absolute. Usually passed with -F. Propagated to dependents transitively. |
-| `defines` | [sequence](../core/list); default is `[]`  Set of defines needed to compile this target. Each define is a string. Propagated to dependents transitively. |
-| `local_defines` | [sequence](../core/list); default is `[]`  Set of defines needed to compile this target. Each define is a string. Not propagated to dependents transitively. |
-| `include_prefix` | [string](../core/string); default is `''`  The prefix to add to the paths of the headers of this rule. When set, the headers in the hdrs attribute of this rule are accessible at is the value of this attribute prepended to their repository-relative path. The prefix in the strip\_include\_prefix attribute is removed before this prefix is added. |
-| `strip_include_prefix` | [string](../core/string); default is `''`  The prefix to strip from the paths of the headers of this rule. When set, the headers in the hdrs attribute of this rule are accessible at their path with this prefix cut off. If it's a relative path, it's taken as a package-relative one. If it's an absolute one, it's understood as a repository-relative path. The prefix in the include\_prefix attribute is added after this prefix is stripped. |
-| `user_compile_flags` | [sequence](../core/list); default is `[]`  Additional list of compilation options. |
-| `conly_flags` | [sequence](../core/list); default is `[]`  Additional list of compilation options for C compiles. |
-| `cxx_flags` | [sequence](../core/list); default is `[]`  Additional list of compilation options for C++ compiles. |
-| `compilation_contexts` | [sequence](../core/list); default is `[]`  Headers from dependencies used for compilation. |
-| `name` | [string](../core/string); required  This is used for naming the output artifacts of actions created by this method. See also the `main\_output` arg. |
-| `disallow_pic_outputs` | [bool](../core/bool); default is `False`  Whether PIC outputs should be created. |
-| `disallow_nopic_outputs` | [bool](../core/bool); default is `False`  Whether NOPIC outputs should be created. |
-| `additional_inputs` | [sequence](../core/list); default is `[]`  List of additional files needed for compilation of srcs |
-| `module_interfaces` | [sequence](../core/list); default is `unbound`  The list of module interfaces source files to be compiled. Note: this is an experimental feature, only enabled with --experimental\_cpp\_modules |
+| `srcs` | [sequence](/versions/8.1.1/rules/lib/core/list); default is `[]`  The list of source files to be compiled. |
+| `public_hdrs` | [sequence](/versions/8.1.1/rules/lib/core/list); default is `[]`  List of headers needed for compilation of srcs and may be included by dependent rules transitively. |
+| `private_hdrs` | [sequence](/versions/8.1.1/rules/lib/core/list); default is `[]`  List of headers needed for compilation of srcs and NOT to be included by dependent rules. |
+| `includes` | [sequence](/versions/8.1.1/rules/lib/core/list); or [depset](/versions/8.1.1/rules/lib/builtins/depset); default is `[]`  Search paths for header files referenced both by angle bracket and quotes. Usually passed with -I. Propagated to dependents transitively. |
+| `quote_includes` | [sequence](/versions/8.1.1/rules/lib/core/list); default is `[]`  Search paths for header files referenced by quotes, e.g. #include "foo/bar/header.h". They can be either relative to the exec root or absolute. Usually passed with -iquote. Propagated to dependents transitively. |
+| `system_includes` | [sequence](/versions/8.1.1/rules/lib/core/list); default is `[]`  Search paths for header files referenced by angle brackets, e.g. #include <foo/bar/header.h>. They can be either relative to the exec root or absolute. Usually passed with -isystem. Propagated to dependents transitively. |
+| `framework_includes` | [sequence](/versions/8.1.1/rules/lib/core/list); default is `[]`  Search paths for header files from Apple frameworks. They can be either relative to the exec root or absolute. Usually passed with -F. Propagated to dependents transitively. |
+| `defines` | [sequence](/versions/8.1.1/rules/lib/core/list); default is `[]`  Set of defines needed to compile this target. Each define is a string. Propagated to dependents transitively. |
+| `local_defines` | [sequence](/versions/8.1.1/rules/lib/core/list); default is `[]`  Set of defines needed to compile this target. Each define is a string. Not propagated to dependents transitively. |
+| `include_prefix` | [string](/versions/8.1.1/rules/lib/core/string); default is `''`  The prefix to add to the paths of the headers of this rule. When set, the headers in the hdrs attribute of this rule are accessible at is the value of this attribute prepended to their repository-relative path. The prefix in the strip\_include\_prefix attribute is removed before this prefix is added. |
+| `strip_include_prefix` | [string](/versions/8.1.1/rules/lib/core/string); default is `''`  The prefix to strip from the paths of the headers of this rule. When set, the headers in the hdrs attribute of this rule are accessible at their path with this prefix cut off. If it's a relative path, it's taken as a package-relative one. If it's an absolute one, it's understood as a repository-relative path. The prefix in the include\_prefix attribute is added after this prefix is stripped. |
+| `user_compile_flags` | [sequence](/versions/8.1.1/rules/lib/core/list); default is `[]`  Additional list of compilation options. |
+| `conly_flags` | [sequence](/versions/8.1.1/rules/lib/core/list); default is `[]`  Additional list of compilation options for C compiles. |
+| `cxx_flags` | [sequence](/versions/8.1.1/rules/lib/core/list); default is `[]`  Additional list of compilation options for C++ compiles. |
+| `compilation_contexts` | [sequence](/versions/8.1.1/rules/lib/core/list); default is `[]`  Headers from dependencies used for compilation. |
+| `name` | [string](/versions/8.1.1/rules/lib/core/string); required  This is used for naming the output artifacts of actions created by this method. See also the `main\_output` arg. |
+| `disallow_pic_outputs` | [bool](/versions/8.1.1/rules/lib/core/bool); default is `False`  Whether PIC outputs should be created. |
+| `disallow_nopic_outputs` | [bool](/versions/8.1.1/rules/lib/core/bool); default is `False`  Whether NOPIC outputs should be created. |
+| `additional_inputs` | [sequence](/versions/8.1.1/rules/lib/core/list); default is `[]`  List of additional files needed for compilation of srcs |
+| `module_interfaces` | [sequence](/versions/8.1.1/rules/lib/core/list); default is `unbound`  The list of module interfaces source files to be compiled. Note: this is an experimental feature, only enabled with --experimental\_cpp\_modules |
 
 ## configure\_features
 
@@ -101,11 +101,11 @@ Creates a feature\_configuration instance. Requires the cpp configuration fragme
 
 | Parameter | Description |
 | --- | --- |
-| `ctx` | [ctx](../builtins/ctx); or `None`; default is `None`  The rule context. |
+| `ctx` | [ctx](/versions/8.1.1/rules/lib/builtins/ctx); or `None`; default is `None`  The rule context. |
 | `cc_toolchain` | Info; required  cc\_toolchain for which we configure features. |
-| `language` | [string](../core/string); or `None`; default is `None`  The language to configure for: either c++ or objc (default c++) |
-| `requested_features` | [sequence](../core/list); default is `[]`  List of features to be enabled. |
-| `unsupported_features` | [sequence](../core/list); default is `[]`  List of features that are unsupported by the current rule. |
+| `language` | [string](/versions/8.1.1/rules/lib/core/string); or `None`; default is `None`  The language to configure for: either c++ or objc (default c++) |
+| `requested_features` | [sequence](/versions/8.1.1/rules/lib/core/list); default is `[]`  List of features to be enabled. |
+| `unsupported_features` | [sequence](/versions/8.1.1/rules/lib/core/list); default is `[]`  List of features that are unsupported by the current rule. |
 
 ## create\_cc\_toolchain\_config\_info
 
@@ -119,22 +119,22 @@ Creates a `CcToolchainConfigInfo` provider
 
 | Parameter | Description |
 | --- | --- |
-| `ctx` | [ctx](../builtins/ctx); required  The rule context. |
-| `features` | [sequence](../core/list); default is `[]`  Contains all flag specifications for one feature. Arguments:  `name`: The feature's name. It is possible to introduce a feature without a change to Bazel by adding a 'feature' section to the toolchain and adding the corresponding string as feature in the `BUILD` file.  `enabled`: If 'True', this feature is enabled unless a rule type explicitly marks it as unsupported.  `flag_sets`: A FlagSet list. If the given feature is enabled, the flag sets will be applied for the actions are specified for.  `env_sets`: an EnvSet list. If the given feature is enabled, the env sets will be applied for the actions they are specified for.  `requires`: A list of feature sets defining when this feature is supported by the toolchain. The feature is supported if any of the feature sets fully apply, that is, when all features of a feature set are enabled. If `requires` is omitted, the feature is supported independently of which other features are enabled. Use this for example to filter flags depending on the build mode enabled (opt / fastbuild / dbg).  `implies`: A string list of features or action configs that are automatically enabled when this feature is enabled. If any of the implied features or action configs cannot be enabled, this feature will (silently) not be enabled either.  `provides`: A list of names this feature conflicts with. A feature cannot be enabled if:- `provides` contains the name of a different feature or action config that we want to enable.- `provides` contains the same value as a 'provides' in a different feature or action config that we want to enable. Use this in order to ensure that incompatible features cannot be accidentally activated at the same time, leading to hard to diagnose compiler errors. |
-| `action_configs` | [sequence](../core/list); default is `[]`  An action config corresponds to a Bazel action, and allows selection of a tool based on activated features. Action config activation occurs by the same semantics as features: a feature can 'require' or 'imply' an action config in the same way that it would another feature. Arguments:  `action_name`: The name of the Bazel action that this config applies to, e.g. 'c-compile' or 'c-module-compile'.  `enabled`: If 'True', this action is enabled unless a rule type explicitly marks it as unsupported.  `tools`: The tool applied to the action will be the first tool with a feature set that matches the feature configuration. An error will be thrown if no tool matches a provided feature configuration - for that reason, it's a good idea to provide a default tool with an empty feature set.  `flag_sets`: If the given action config is enabled, the flag sets will be applied to the corresponding action.  `implies`: A list of features or action configs that are automatically enabled when this action config is enabled. If any of the implied features or action configs cannot be enabled, this action config will (silently) not be enabled either. |
-| `artifact_name_patterns` | [sequence](../core/list); default is `[]`  The name for an artifact of a given category of input or output artifacts to an action. Arguments:  `category_name`: The category of artifacts that this selection applies to. This field is compared against a list of categories defined in Bazel. Example categories include "linked\_output" or the artifact for this selection. Together with the extension it is used to create an artifact name based on the target name.  `extension`: The extension for creating the artifact for this selection. Together with the prefix it is used to create an artifact name based on the target name. |
-| `cxx_builtin_include_directories` | [sequence](../core/list); default is `[]`  Built-in include directories for C++ compilation. These should be the exact paths used by the compiler, and are generally relative to the exec root.  The paths used by the compiler can be determined by 'gcc -E -xc++ - -v'.  We currently use the C++ paths also for C compilation, which is safe as long as there are no name clashes between C++ and C header files.  Relative paths are resolved relative to the configuration file directory.  If the compiler has --sysroot support, then these paths should use %sysroot% rather than the include path, and specify the sysroot attribute in order to give blaze the information necessary to make the correct replacements. |
-| `toolchain_identifier` | [string](../core/string); required  The unique identifier of the toolchain within the crosstool release. It must be possible to use this as a directory name in a path.  It has to match the following regex: [a-zA-Z\_][\.\- \w]\* |
-| `host_system_name` | [string](../core/string); or `None`; default is `None`  Ignored. |
-| `target_system_name` | [string](../core/string); or `None`; default is `None`  Deprecated. The GNU System Name. The string is exposed to CcToolchainInfo.target\_gnu\_system\_name. |
-| `target_cpu` | [string](../core/string); or `None`; default is `None`  Deprecated: Use cpu based constraints instead. If the string is "k8", `target\_cpu` will be omitted from the filename of raw FDO profile data. |
-| `target_libc` | [string](../core/string); or `None`; default is `None`  Deprecated: Use OS based constraints instead. The libc version string (e.g. "glibc-2.2.2"). If the string is "macosx", platform is assumed to be MacOS. Otherwise, Linux. The string is exposed to CcToolchainInfo.libc. |
-| `compiler` | [string](../core/string); required  The compiler string (e.g. "gcc"). The current toolchain's compiler is exposed to `@bazel\_tools//tools/cpp:compiler (compiler\_flag)` as a flag value. Targets that require compiler-specific flags can use the config\_settings in https://github.com/bazelbuild/rules\_cc/blob/main/cc/compiler/BUILD in select() statements or create custom config\_setting if the existing settings don't suffice. |
-| `abi_version` | [string](../core/string); or `None`; default is `None`  The abi in use, which is a gcc version. E.g.: "gcc-3.4". The string is set to C++ toolchain variable ABI. |
-| `abi_libc_version` | [string](../core/string); or `None`; default is `None`  The glibc version used by the abi we're using. The string is set to C++ toolchain variable ABI\_LIBC\_VERSION. |
-| `tool_paths` | [sequence](../core/list); default is `[]`  Tool locations. Arguments:  `name`: Name of the tool.  `path`: Location of the tool; Can be absolute path (in case of non hermetic toolchain), or path relative to the cc\_toolchain's package. |
-| `make_variables` | [sequence](../core/list); default is `[]`  A make variable that is made accessible to rules. |
-| `builtin_sysroot` | [string](../core/string); or `None`; default is `None`  The built-in sysroot. If this attribute is not present, Bazel does not allow using a different sysroot, i.e. through the --grte\_top option. |
+| `ctx` | [ctx](/versions/8.1.1/rules/lib/builtins/ctx); required  The rule context. |
+| `features` | [sequence](/versions/8.1.1/rules/lib/core/list); default is `[]`  Contains all flag specifications for one feature. Arguments:  `name`: The feature's name. It is possible to introduce a feature without a change to Bazel by adding a 'feature' section to the toolchain and adding the corresponding string as feature in the `BUILD` file.  `enabled`: If 'True', this feature is enabled unless a rule type explicitly marks it as unsupported.  `flag_sets`: A FlagSet list. If the given feature is enabled, the flag sets will be applied for the actions are specified for.  `env_sets`: an EnvSet list. If the given feature is enabled, the env sets will be applied for the actions they are specified for.  `requires`: A list of feature sets defining when this feature is supported by the toolchain. The feature is supported if any of the feature sets fully apply, that is, when all features of a feature set are enabled. If `requires` is omitted, the feature is supported independently of which other features are enabled. Use this for example to filter flags depending on the build mode enabled (opt / fastbuild / dbg).  `implies`: A string list of features or action configs that are automatically enabled when this feature is enabled. If any of the implied features or action configs cannot be enabled, this feature will (silently) not be enabled either.  `provides`: A list of names this feature conflicts with. A feature cannot be enabled if:- `provides` contains the name of a different feature or action config that we want to enable.- `provides` contains the same value as a 'provides' in a different feature or action config that we want to enable. Use this in order to ensure that incompatible features cannot be accidentally activated at the same time, leading to hard to diagnose compiler errors. |
+| `action_configs` | [sequence](/versions/8.1.1/rules/lib/core/list); default is `[]`  An action config corresponds to a Bazel action, and allows selection of a tool based on activated features. Action config activation occurs by the same semantics as features: a feature can 'require' or 'imply' an action config in the same way that it would another feature. Arguments:  `action_name`: The name of the Bazel action that this config applies to, e.g. 'c-compile' or 'c-module-compile'.  `enabled`: If 'True', this action is enabled unless a rule type explicitly marks it as unsupported.  `tools`: The tool applied to the action will be the first tool with a feature set that matches the feature configuration. An error will be thrown if no tool matches a provided feature configuration - for that reason, it's a good idea to provide a default tool with an empty feature set.  `flag_sets`: If the given action config is enabled, the flag sets will be applied to the corresponding action.  `implies`: A list of features or action configs that are automatically enabled when this action config is enabled. If any of the implied features or action configs cannot be enabled, this action config will (silently) not be enabled either. |
+| `artifact_name_patterns` | [sequence](/versions/8.1.1/rules/lib/core/list); default is `[]`  The name for an artifact of a given category of input or output artifacts to an action. Arguments:  `category_name`: The category of artifacts that this selection applies to. This field is compared against a list of categories defined in Bazel. Example categories include "linked\_output" or the artifact for this selection. Together with the extension it is used to create an artifact name based on the target name.  `extension`: The extension for creating the artifact for this selection. Together with the prefix it is used to create an artifact name based on the target name. |
+| `cxx_builtin_include_directories` | [sequence](/versions/8.1.1/rules/lib/core/list); default is `[]`  Built-in include directories for C++ compilation. These should be the exact paths used by the compiler, and are generally relative to the exec root.  The paths used by the compiler can be determined by 'gcc -E -xc++ - -v'.  We currently use the C++ paths also for C compilation, which is safe as long as there are no name clashes between C++ and C header files.  Relative paths are resolved relative to the configuration file directory.  If the compiler has --sysroot support, then these paths should use %sysroot% rather than the include path, and specify the sysroot attribute in order to give blaze the information necessary to make the correct replacements. |
+| `toolchain_identifier` | [string](/versions/8.1.1/rules/lib/core/string); required  The unique identifier of the toolchain within the crosstool release. It must be possible to use this as a directory name in a path.  It has to match the following regex: [a-zA-Z\_][\.\- \w]\* |
+| `host_system_name` | [string](/versions/8.1.1/rules/lib/core/string); or `None`; default is `None`  Ignored. |
+| `target_system_name` | [string](/versions/8.1.1/rules/lib/core/string); or `None`; default is `None`  Deprecated. The GNU System Name. The string is exposed to CcToolchainInfo.target\_gnu\_system\_name. |
+| `target_cpu` | [string](/versions/8.1.1/rules/lib/core/string); or `None`; default is `None`  Deprecated: Use cpu based constraints instead. If the string is "k8", `target\_cpu` will be omitted from the filename of raw FDO profile data. |
+| `target_libc` | [string](/versions/8.1.1/rules/lib/core/string); or `None`; default is `None`  Deprecated: Use OS based constraints instead. The libc version string (e.g. "glibc-2.2.2"). If the string is "macosx", platform is assumed to be MacOS. Otherwise, Linux. The string is exposed to CcToolchainInfo.libc. |
+| `compiler` | [string](/versions/8.1.1/rules/lib/core/string); required  The compiler string (e.g. "gcc"). The current toolchain's compiler is exposed to `@bazel\_tools//tools/cpp:compiler (compiler\_flag)` as a flag value. Targets that require compiler-specific flags can use the config\_settings in https://github.com/bazelbuild/rules\_cc/blob/main/cc/compiler/BUILD in select() statements or create custom config\_setting if the existing settings don't suffice. |
+| `abi_version` | [string](/versions/8.1.1/rules/lib/core/string); or `None`; default is `None`  The abi in use, which is a gcc version. E.g.: "gcc-3.4". The string is set to C++ toolchain variable ABI. |
+| `abi_libc_version` | [string](/versions/8.1.1/rules/lib/core/string); or `None`; default is `None`  The glibc version used by the abi we're using. The string is set to C++ toolchain variable ABI\_LIBC\_VERSION. |
+| `tool_paths` | [sequence](/versions/8.1.1/rules/lib/core/list); default is `[]`  Tool locations. Arguments:  `name`: Name of the tool.  `path`: Location of the tool; Can be absolute path (in case of non hermetic toolchain), or path relative to the cc\_toolchain's package. |
+| `make_variables` | [sequence](/versions/8.1.1/rules/lib/core/list); default is `[]`  A make variable that is made accessible to rules. |
+| `builtin_sysroot` | [string](/versions/8.1.1/rules/lib/core/string); or `None`; default is `None`  The built-in sysroot. If this attribute is not present, Bazel does not allow using a different sysroot, i.e. through the --grte\_top option. |
 
 ## create\_compilation\_context
 
@@ -168,8 +168,8 @@ Create compilation outputs object.
 
 | Parameter | Description |
 | --- | --- |
-| `objects` | [depset](../builtins/depset); or `None`; default is `None`  List of object files. |
-| `pic_objects` | [depset](../builtins/depset); or `None`; default is `None`  List of pic object files. |
+| `objects` | [depset](/versions/8.1.1/rules/lib/builtins/depset); or `None`; default is `None`  List of object files. |
+| `pic_objects` | [depset](/versions/8.1.1/rules/lib/builtins/depset); or `None`; default is `None`  List of pic object files. |
 
 ## create\_compile\_variables
 
@@ -184,21 +184,21 @@ Returns variables used for compilation actions.
 | Parameter | Description |
 | --- | --- |
 | `cc_toolchain` | Info; required  cc\_toolchain for which we are creating build variables. |
-| `feature_configuration` | [FeatureConfiguration](../builtins/FeatureConfiguration); required  Feature configuration to be queried. |
+| `feature_configuration` | [FeatureConfiguration](/versions/8.1.1/rules/lib/builtins/FeatureConfiguration); required  Feature configuration to be queried. |
 | `source_file` | default is `None`  Optional source file for the compilation. Please prefer passing source\_file here over appending it to the end of the command line generated from cc\_common.get\_memory\_inefficient\_command\_line, as then it's in the power of the toolchain author to properly specify and position compiler flags. |
 | `output_file` | default is `None`  Optional output file of the compilation. Please prefer passing output\_file here over appending it to the end of the command line generated from cc\_common.get\_memory\_inefficient\_command\_line, as then it's in the power of the toolchain author to properly specify and position compiler flags. |
-| `user_compile_flags` | [sequence](../core/list) of [string](../core/string)s; or `None`; default is `None`  List of additional compilation flags (copts). |
-| `include_directories` | [depset](../builtins/depset); or `None`; default is `None`  Depset of include directories. |
-| `quote_include_directories` | [depset](../builtins/depset); or `None`; default is `None`  Depset of quote include directories. |
-| `system_include_directories` | [depset](../builtins/depset); or `None`; default is `None`  Depset of system include directories. |
-| `framework_include_directories` | [depset](../builtins/depset); or `None`; default is `None`  Depset of framework include directories. |
-| `preprocessor_defines` | [depset](../builtins/depset); or `None`; default is `None`  Depset of preprocessor defines. |
-| `thinlto_index` | [string](../core/string); or `None`; default is `None`  LTO index file path. |
-| `thinlto_input_bitcode_file` | [string](../core/string); or `None`; default is `None`  Bitcode file that is input to LTO backend. |
-| `thinlto_output_object_file` | [string](../core/string); or `None`; default is `None`  Object file that is output by LTO backend. |
-| `use_pic` | [bool](../core/bool); default is `False`  When true the compilation will generate position independent code. |
-| `add_legacy_cxx_options` | [bool](../core/bool); default is `False`  Unused. |
-| `variables_extension` | [dict](../core/dict); default is `unbound`  A dictionary of additional variables used by compile actions. |
+| `user_compile_flags` | [sequence](/versions/8.1.1/rules/lib/core/list) of [string](/versions/8.1.1/rules/lib/core/string)s; or `None`; default is `None`  List of additional compilation flags (copts). |
+| `include_directories` | [depset](/versions/8.1.1/rules/lib/builtins/depset); or `None`; default is `None`  Depset of include directories. |
+| `quote_include_directories` | [depset](/versions/8.1.1/rules/lib/builtins/depset); or `None`; default is `None`  Depset of quote include directories. |
+| `system_include_directories` | [depset](/versions/8.1.1/rules/lib/builtins/depset); or `None`; default is `None`  Depset of system include directories. |
+| `framework_include_directories` | [depset](/versions/8.1.1/rules/lib/builtins/depset); or `None`; default is `None`  Depset of framework include directories. |
+| `preprocessor_defines` | [depset](/versions/8.1.1/rules/lib/builtins/depset); or `None`; default is `None`  Depset of preprocessor defines. |
+| `thinlto_index` | [string](/versions/8.1.1/rules/lib/core/string); or `None`; default is `None`  LTO index file path. |
+| `thinlto_input_bitcode_file` | [string](/versions/8.1.1/rules/lib/core/string); or `None`; default is `None`  Bitcode file that is input to LTO backend. |
+| `thinlto_output_object_file` | [string](/versions/8.1.1/rules/lib/core/string); or `None`; default is `None`  Object file that is output by LTO backend. |
+| `use_pic` | [bool](/versions/8.1.1/rules/lib/core/bool); default is `False`  When true the compilation will generate position independent code. |
+| `add_legacy_cxx_options` | [bool](/versions/8.1.1/rules/lib/core/bool); default is `False`  Unused. |
+| `variables_extension` | [dict](/versions/8.1.1/rules/lib/core/dict); default is `unbound`  A dictionary of additional variables used by compile actions. |
 
 ## create\_library\_to\_link
 
@@ -215,15 +215,15 @@ Creates `LibraryToLink`
 | `actions` | required  `actions` object. |
 | `feature_configuration` | default is `None`  `feature_configuration` to be queried. |
 | `cc_toolchain` | default is `None`  `CcToolchainInfo` provider to be used. |
-| `static_library` | [File](../builtins/File); or `None`; default is `None`  `File` of static library to be linked. |
-| `pic_static_library` | [File](../builtins/File); or `None`; default is `None`  `File` of pic static library to be linked. |
-| `dynamic_library` | [File](../builtins/File); or `None`; default is `None`  `File` of dynamic library to be linked. Always used for runtime and used for linking if `interface_library` is not passed. |
-| `interface_library` | [File](../builtins/File); or `None`; default is `None`  `File` of interface library to be linked. |
-| `pic_objects` | [sequence](../core/list) of [File](../builtins/File)s; default is `unbound`  Experimental, do not use |
-| `objects` | [sequence](../core/list) of [File](../builtins/File)s; default is `unbound`  Experimental, do not use |
-| `alwayslink` | [bool](../core/bool); default is `False`  Whether to link the static library/objects in the --whole\_archive block. |
-| `dynamic_library_symlink_path` | [string](../core/string); default is `''`  Override the default path of the dynamic library link in the solib directory. Empty string to use the default. |
-| `interface_library_symlink_path` | [string](../core/string); default is `''`  Override the default path of the interface library link in the solib directory. Empty string to use the default. |
+| `static_library` | [File](/versions/8.1.1/rules/lib/builtins/File); or `None`; default is `None`  `File` of static library to be linked. |
+| `pic_static_library` | [File](/versions/8.1.1/rules/lib/builtins/File); or `None`; default is `None`  `File` of pic static library to be linked. |
+| `dynamic_library` | [File](/versions/8.1.1/rules/lib/builtins/File); or `None`; default is `None`  `File` of dynamic library to be linked. Always used for runtime and used for linking if `interface_library` is not passed. |
+| `interface_library` | [File](/versions/8.1.1/rules/lib/builtins/File); or `None`; default is `None`  `File` of interface library to be linked. |
+| `pic_objects` | [sequence](/versions/8.1.1/rules/lib/core/list) of [File](/versions/8.1.1/rules/lib/builtins/File)s; default is `unbound`  Experimental, do not use |
+| `objects` | [sequence](/versions/8.1.1/rules/lib/core/list) of [File](/versions/8.1.1/rules/lib/builtins/File)s; default is `unbound`  Experimental, do not use |
+| `alwayslink` | [bool](/versions/8.1.1/rules/lib/core/bool); default is `False`  Whether to link the static library/objects in the --whole\_archive block. |
+| `dynamic_library_symlink_path` | [string](/versions/8.1.1/rules/lib/core/string); default is `''`  Override the default path of the dynamic library link in the solib directory. Empty string to use the default. |
+| `interface_library_symlink_path` | [string](/versions/8.1.1/rules/lib/core/string); default is `''`  Override the default path of the interface library link in the solib directory. Empty string to use the default. |
 
 ## create\_link\_variables
 
@@ -238,17 +238,17 @@ Returns link variables used for linking actions.
 | Parameter | Description |
 | --- | --- |
 | `cc_toolchain` | Info; required  cc\_toolchain for which we are creating build variables. |
-| `feature_configuration` | [FeatureConfiguration](../builtins/FeatureConfiguration); required  Feature configuration to be queried. |
-| `library_search_directories` | [depset](../builtins/depset); default is `[]`  Depset of directories where linker will look for libraries at link time. |
-| `runtime_library_search_directories` | [depset](../builtins/depset); default is `[]`  Depset of directories where loader will look for libraries at runtime. |
-| `user_link_flags` | [sequence](../core/list); default is `[]`  List of additional link flags (linkopts). |
+| `feature_configuration` | [FeatureConfiguration](/versions/8.1.1/rules/lib/builtins/FeatureConfiguration); required  Feature configuration to be queried. |
+| `library_search_directories` | [depset](/versions/8.1.1/rules/lib/builtins/depset); default is `[]`  Depset of directories where linker will look for libraries at link time. |
+| `runtime_library_search_directories` | [depset](/versions/8.1.1/rules/lib/builtins/depset); default is `[]`  Depset of directories where loader will look for libraries at runtime. |
+| `user_link_flags` | [sequence](/versions/8.1.1/rules/lib/core/list); default is `[]`  List of additional link flags (linkopts). |
 | `output_file` | default is `None`  Optional output file path. |
 | `param_file` | default is `None`  Optional param file path. |
-| `is_using_linker` | [bool](../core/bool); default is `True`  True when using linker, False when archiver. Caller is responsible for keeping this in sync with action name used (is\_using\_linker = True for linking executable or dynamic library, is\_using\_linker = False for archiving static library). |
-| `is_linking_dynamic_library` | [bool](../core/bool); default is `False`  True when creating dynamic library, False when executable or static library. Caller is responsible for keeping this in sync with action name used. This field will be removed once b/65151735 is fixed. |
-| `must_keep_debug` | [bool](../core/bool); default is `True`  When set to False, bazel will expose 'strip\_debug\_symbols' variable, which is usually used to use the linker to strip debug symbols from the output file. |
-| `use_test_only_flags` | [bool](../core/bool); default is `False`  When set to true, 'is\_cc\_test' variable will be set. |
-| `is_static_linking_mode` | [bool](../core/bool); default is `True`  Unused. |
+| `is_using_linker` | [bool](/versions/8.1.1/rules/lib/core/bool); default is `True`  True when using linker, False when archiver. Caller is responsible for keeping this in sync with action name used (is\_using\_linker = True for linking executable or dynamic library, is\_using\_linker = False for archiving static library). |
+| `is_linking_dynamic_library` | [bool](/versions/8.1.1/rules/lib/core/bool); default is `False`  True when creating dynamic library, False when executable or static library. Caller is responsible for keeping this in sync with action name used. This field will be removed once b/65151735 is fixed. |
+| `must_keep_debug` | [bool](/versions/8.1.1/rules/lib/core/bool); default is `True`  When set to False, bazel will expose 'strip\_debug\_symbols' variable, which is usually used to use the linker to strip debug symbols from the output file. |
+| `use_test_only_flags` | [bool](/versions/8.1.1/rules/lib/core/bool); default is `False`  When set to true, 'is\_cc\_test' variable will be set. |
+| `is_static_linking_mode` | [bool](/versions/8.1.1/rules/lib/core/bool); default is `True`  Unused. |
 
 ## create\_linker\_input
 
@@ -262,10 +262,10 @@ Creates a `LinkerInput`.
 
 | Parameter | Description |
 | --- | --- |
-| `owner` | [Label](../builtins/Label); required  The label of the target that produced all files used in this input. |
-| `libraries` | `None`; or [depset](../builtins/depset); default is `None`  List of `LibraryToLink`. |
-| `user_link_flags` | `None`; or [depset](../builtins/depset) of [string](../core/string)s; or [sequence](../core/list) of [string](../core/string)s; default is `None`  User link flags passed as strings. Accepts either [String], [[String]] or depset(String). The latter is discouraged as it's only kept for compatibility purposes, the depset is flattened. If you want to propagate user\_link\_flags via unflattened depsets() wrap them in a LinkerInput so that they are not flattened till the end. |
-| `additional_inputs` | `None`; or [depset](../builtins/depset); default is `None`  For additional inputs to the linking action, e.g.: linking scripts. |
+| `owner` | [Label](/versions/8.1.1/rules/lib/builtins/Label); required  The label of the target that produced all files used in this input. |
+| `libraries` | `None`; or [depset](/versions/8.1.1/rules/lib/builtins/depset); default is `None`  List of `LibraryToLink`. |
+| `user_link_flags` | `None`; or [depset](/versions/8.1.1/rules/lib/builtins/depset) of [string](/versions/8.1.1/rules/lib/core/string)s; or [sequence](/versions/8.1.1/rules/lib/core/list) of [string](/versions/8.1.1/rules/lib/core/string)s; default is `None`  User link flags passed as strings. Accepts either [String], [[String]] or depset(String). The latter is discouraged as it's only kept for compatibility purposes, the depset is flattened. If you want to propagate user\_link\_flags via unflattened depsets() wrap them in a LinkerInput so that they are not flattened till the end. |
+| `additional_inputs` | `None`; or [depset](/versions/8.1.1/rules/lib/builtins/depset); default is `None`  For additional inputs to the linking action, e.g.: linking scripts. |
 
 ## create\_linking\_context
 
@@ -279,10 +279,10 @@ Creates a `LinkingContext`.
 
 | Parameter | Description |
 | --- | --- |
-| `linker_inputs` | `None`; or [depset](../builtins/depset); default is `None`  Depset of `LinkerInput`. |
-| `libraries_to_link` | `None`; or [sequence](../core/list); default is `None`  **Deprecated**. This parameter is deprecated and will be removed soon. Please do not depend on it. It is *disabled* with `--incompatible_require_linker_input_cc_api`. Use this flag to verify your code is compatible with its imminent removal.  List of `LibraryToLink`. |
-| `user_link_flags` | `None`; or [sequence](../core/list); default is `None` |
-| `additional_inputs` | `None`; or [sequence](../core/list); default is `None` |
+| `linker_inputs` | `None`; or [depset](/versions/8.1.1/rules/lib/builtins/depset); default is `None`  Depset of `LinkerInput`. |
+| `libraries_to_link` | `None`; or [sequence](/versions/8.1.1/rules/lib/core/list); default is `None`  **Deprecated**. This parameter is deprecated and will be removed soon. Please do not depend on it. It is *disabled* with `--incompatible_require_linker_input_cc_api`. Use this flag to verify your code is compatible with its imminent removal.  List of `LibraryToLink`. |
+| `user_link_flags` | `None`; or [sequence](/versions/8.1.1/rules/lib/core/list); default is `None` |
+| `additional_inputs` | `None`; or [sequence](/versions/8.1.1/rules/lib/core/list); default is `None` |
 
 ## create\_linking\_context\_from\_compilation\_outputs
 
@@ -296,19 +296,19 @@ Should be used for creating library rules that can propagate information downstr
 
 | Parameter | Description |
 | --- | --- |
-| `actions` | [actions](../builtins/actions); required |
-| `name` | [string](../core/string); required  This is used for naming the output artifacts of actions created by this method. |
-| `feature_configuration` | [FeatureConfiguration](../builtins/FeatureConfiguration); required  `feature_configuration` to be queried. |
+| `actions` | [actions](/versions/8.1.1/rules/lib/builtins/actions); required |
+| `name` | [string](/versions/8.1.1/rules/lib/core/string); required  This is used for naming the output artifacts of actions created by this method. |
+| `feature_configuration` | [FeatureConfiguration](/versions/8.1.1/rules/lib/builtins/FeatureConfiguration); required  `feature_configuration` to be queried. |
 | `cc_toolchain` | Info; required  `CcToolchainInfo` provider to be used. |
-| `language` | [string](../core/string); default is `'c++'`  Only C++ supported for now. Do not use this parameter. |
-| `disallow_static_libraries` | [bool](../core/bool); default is `False`  Whether static libraries should be created. |
-| `disallow_dynamic_library` | [bool](../core/bool); default is `False`  Whether a dynamic library should be created. |
-| `compilation_outputs` | [CcCompilationOutputs](../builtins/CcCompilationOutputs); required  Compilation outputs containing object files to link. |
-| `linking_contexts` | [sequence](../core/list); default is `[]`  Libraries from dependencies. These libraries will be linked into the output artifact of the link() call, be it a binary or a library. |
-| `user_link_flags` | [sequence](../core/list); default is `[]`  Additional list of linking options. |
-| `alwayslink` | [bool](../core/bool); default is `False`  Whether this library should always be linked. |
-| `additional_inputs` | [sequence](../core/list); default is `[]`  For additional inputs to the linking action, e.g.: linking scripts. |
-| `variables_extension` | [dict](../core/dict); default is `unbound`  Additional variables to pass to the toolchain configuration when creating link command line. |
+| `language` | [string](/versions/8.1.1/rules/lib/core/string); default is `'c++'`  Only C++ supported for now. Do not use this parameter. |
+| `disallow_static_libraries` | [bool](/versions/8.1.1/rules/lib/core/bool); default is `False`  Whether static libraries should be created. |
+| `disallow_dynamic_library` | [bool](/versions/8.1.1/rules/lib/core/bool); default is `False`  Whether a dynamic library should be created. |
+| `compilation_outputs` | [CcCompilationOutputs](/versions/8.1.1/rules/lib/builtins/CcCompilationOutputs); required  Compilation outputs containing object files to link. |
+| `linking_contexts` | [sequence](/versions/8.1.1/rules/lib/core/list); default is `[]`  Libraries from dependencies. These libraries will be linked into the output artifact of the link() call, be it a binary or a library. |
+| `user_link_flags` | [sequence](/versions/8.1.1/rules/lib/core/list); default is `[]`  Additional list of linking options. |
+| `alwayslink` | [bool](/versions/8.1.1/rules/lib/core/bool); default is `False`  Whether this library should always be linked. |
+| `additional_inputs` | [sequence](/versions/8.1.1/rules/lib/core/list); default is `[]`  For additional inputs to the linking action, e.g.: linking scripts. |
+| `variables_extension` | [dict](/versions/8.1.1/rules/lib/core/dict); default is `unbound`  Additional variables to pass to the toolchain configuration when creating link command line. |
 
 ## create\_lto\_compilation\_context
 
@@ -322,7 +322,7 @@ Create LTO compilation context
 
 | Parameter | Description |
 | --- | --- |
-| `objects` | [dict](../core/dict); default is `{}`  map of full object to index object |
+| `objects` | [dict](/versions/8.1.1/rules/lib/core/dict); default is `{}`  map of full object to index object |
 
 ## do\_not\_use\_tools\_cpp\_compiler\_present
 
@@ -344,8 +344,8 @@ Returns environment variables to be set for given action.
 
 | Parameter | Description |
 | --- | --- |
-| `feature_configuration` | [FeatureConfiguration](../builtins/FeatureConfiguration); required  Feature configuration to be queried. |
-| `action_name` | [string](../core/string); required  Name of the action. Has to be one of the names in @bazel\_tools//tools/build\_defs/cc:action\_names.bzl (https://github.com/bazelbuild/bazel/blob/master/tools/build\_defs/cc/action\_names.bzl) |
+| `feature_configuration` | [FeatureConfiguration](/versions/8.1.1/rules/lib/builtins/FeatureConfiguration); required  Feature configuration to be queried. |
+| `action_name` | [string](/versions/8.1.1/rules/lib/core/string); required  Name of the action. Has to be one of the names in @bazel\_tools//tools/build\_defs/cc:action\_names.bzl (https://github.com/bazelbuild/bazel/blob/master/tools/build\_defs/cc/action\_names.bzl) |
 | `variables` | Variables; required  Build variables to be used for template expansion. |
 
 ## get\_execution\_requirements
@@ -360,8 +360,8 @@ Returns execution requirements for given action.
 
 | Parameter | Description |
 | --- | --- |
-| `feature_configuration` | [FeatureConfiguration](../builtins/FeatureConfiguration); required  Feature configuration to be queried. |
-| `action_name` | [string](../core/string); required  Name of the action. Has to be one of the names in @bazel\_tools//tools/build\_defs/cc:action\_names.bzl (https://github.com/bazelbuild/bazel/blob/master/tools/build\_defs/cc/action\_names.bzl) |
+| `feature_configuration` | [FeatureConfiguration](/versions/8.1.1/rules/lib/builtins/FeatureConfiguration); required  Feature configuration to be queried. |
+| `action_name` | [string](/versions/8.1.1/rules/lib/core/string); required  Name of the action. Has to be one of the names in @bazel\_tools//tools/build\_defs/cc:action\_names.bzl (https://github.com/bazelbuild/bazel/blob/master/tools/build\_defs/cc/action\_names.bzl) |
 
 ## get\_memory\_inefficient\_command\_line
 
@@ -375,8 +375,8 @@ Returns flattened command line flags for given action, using given variables for
 
 | Parameter | Description |
 | --- | --- |
-| `feature_configuration` | [FeatureConfiguration](../builtins/FeatureConfiguration); required  Feature configuration to be queried. |
-| `action_name` | [string](../core/string); required  Name of the action. Has to be one of the names in @bazel\_tools//tools/build\_defs/cc:action\_names.bzl (https://github.com/bazelbuild/bazel/blob/master/tools/build\_defs/cc/action\_names.bzl) |
+| `feature_configuration` | [FeatureConfiguration](/versions/8.1.1/rules/lib/builtins/FeatureConfiguration); required  Feature configuration to be queried. |
+| `action_name` | [string](/versions/8.1.1/rules/lib/core/string); required  Name of the action. Has to be one of the names in @bazel\_tools//tools/build\_defs/cc:action\_names.bzl (https://github.com/bazelbuild/bazel/blob/master/tools/build\_defs/cc/action\_names.bzl) |
 | `variables` | Variables; required  Build variables to be used for template expansions. |
 
 ## get\_tool\_for\_action
@@ -391,8 +391,8 @@ Returns tool path for given action.
 
 | Parameter | Description |
 | --- | --- |
-| `feature_configuration` | [FeatureConfiguration](../builtins/FeatureConfiguration); required  Feature configuration to be queried. |
-| `action_name` | [string](../core/string); required  Name of the action. Has to be one of the names in @bazel\_tools//tools/build\_defs/cc:action\_names.bzl (https://github.com/bazelbuild/bazel/blob/master/tools/build\_defs/cc/action\_names.bzl) |
+| `feature_configuration` | [FeatureConfiguration](/versions/8.1.1/rules/lib/builtins/FeatureConfiguration); required  Feature configuration to be queried. |
+| `action_name` | [string](/versions/8.1.1/rules/lib/core/string); required  Name of the action. Has to be one of the names in @bazel\_tools//tools/build\_defs/cc:action\_names.bzl (https://github.com/bazelbuild/bazel/blob/master/tools/build\_defs/cc/action\_names.bzl) |
 
 ## is\_enabled
 
@@ -406,8 +406,8 @@ Returns True if given feature is enabled in the feature configuration.
 
 | Parameter | Description |
 | --- | --- |
-| `feature_configuration` | [FeatureConfiguration](../builtins/FeatureConfiguration); required  Feature configuration to be queried. |
-| `feature_name` | [string](../core/string); required  Name of the feature. |
+| `feature_configuration` | [FeatureConfiguration](/versions/8.1.1/rules/lib/builtins/FeatureConfiguration); required  Feature configuration to be queried. |
+| `feature_name` | [string](/versions/8.1.1/rules/lib/core/string); required  Name of the feature. |
 
 ## link
 
@@ -421,20 +421,20 @@ Should be used for C++ transitive linking.
 
 | Parameter | Description |
 | --- | --- |
-| `actions` | [actions](../builtins/actions); required  `actions` object. |
-| `name` | [string](../core/string); required  This is used for naming the output artifacts of actions created by this method. |
-| `feature_configuration` | [FeatureConfiguration](../builtins/FeatureConfiguration); required  `feature_configuration` to be queried. |
+| `actions` | [actions](/versions/8.1.1/rules/lib/builtins/actions); required  `actions` object. |
+| `name` | [string](/versions/8.1.1/rules/lib/core/string); required  This is used for naming the output artifacts of actions created by this method. |
+| `feature_configuration` | [FeatureConfiguration](/versions/8.1.1/rules/lib/builtins/FeatureConfiguration); required  `feature_configuration` to be queried. |
 | `cc_toolchain` | Info; required  `CcToolchainInfo` provider to be used. |
-| `language` | [string](../core/string); default is `'c++'`  Only C++ supported for now. Do not use this parameter. |
-| `output_type` | [string](../core/string); default is `'executable'`  Can be either 'executable' or 'dynamic\_library'. |
-| `link_deps_statically` | [bool](../core/bool); default is `True`  True to link dependencies statically, False dynamically. |
-| `compilation_outputs` | [CcCompilationOutputs](../builtins/CcCompilationOutputs); or `None`; default is `None`  Compilation outputs containing object files to link. |
-| `linking_contexts` | [sequence](../core/list); default is `[]`  Linking contexts from dependencies to be linked into the linking context generated by this rule. |
-| `user_link_flags` | [sequence](../core/list); default is `[]`  Additional list of linker options. |
-| `stamp` | [int](../core/int); default is `0`  Whether to include build information in the linked executable, if output\_type is 'executable'. If 1, build information is always included. If 0 (the default build information is always excluded. If -1, uses the default behavior, which may be overridden by the --[no]stamp flag. This should be unset (or set to 0) when generating the executable output for test rules. |
-| `additional_inputs` | [sequence](../core/list); or [depset](../builtins/depset); default is `[]`  For additional inputs to the linking action, e.g.: linking scripts. |
-| `additional_outputs` | [sequence](../core/list); default is `[]`  For additional outputs to the linking action, e.g.: map files. |
-| `variables_extension` | [dict](../core/dict); default is `{}`  Additional variables to pass to the toolchain configuration when create link command line. |
+| `language` | [string](/versions/8.1.1/rules/lib/core/string); default is `'c++'`  Only C++ supported for now. Do not use this parameter. |
+| `output_type` | [string](/versions/8.1.1/rules/lib/core/string); default is `'executable'`  Can be either 'executable' or 'dynamic\_library'. |
+| `link_deps_statically` | [bool](/versions/8.1.1/rules/lib/core/bool); default is `True`  True to link dependencies statically, False dynamically. |
+| `compilation_outputs` | [CcCompilationOutputs](/versions/8.1.1/rules/lib/builtins/CcCompilationOutputs); or `None`; default is `None`  Compilation outputs containing object files to link. |
+| `linking_contexts` | [sequence](/versions/8.1.1/rules/lib/core/list); default is `[]`  Linking contexts from dependencies to be linked into the linking context generated by this rule. |
+| `user_link_flags` | [sequence](/versions/8.1.1/rules/lib/core/list); default is `[]`  Additional list of linker options. |
+| `stamp` | [int](/versions/8.1.1/rules/lib/core/int); default is `0`  Whether to include build information in the linked executable, if output\_type is 'executable'. If 1, build information is always included. If 0 (the default build information is always excluded. If -1, uses the default behavior, which may be overridden by the --[no]stamp flag. This should be unset (or set to 0) when generating the executable output for test rules. |
+| `additional_inputs` | [sequence](/versions/8.1.1/rules/lib/core/list); or [depset](/versions/8.1.1/rules/lib/builtins/depset); default is `[]`  For additional inputs to the linking action, e.g.: linking scripts. |
+| `additional_outputs` | [sequence](/versions/8.1.1/rules/lib/core/list); default is `[]`  For additional outputs to the linking action, e.g.: map files. |
+| `variables_extension` | [dict](/versions/8.1.1/rules/lib/core/dict); default is `{}`  Additional variables to pass to the toolchain configuration when create link command line. |
 
 ## merge\_compilation\_contexts
 
@@ -448,7 +448,7 @@ Merges multiple `CompilationContexts`s into one.
 
 | Parameter | Description |
 | --- | --- |
-| `compilation_contexts` | [sequence](../core/list); default is `[]`  List of `CompilationContexts`s to be merged. The headers of each context will be exported by the direct fields in the returned provider. |
+| `compilation_contexts` | [sequence](/versions/8.1.1/rules/lib/core/list); default is `[]`  List of `CompilationContexts`s to be merged. The headers of each context will be exported by the direct fields in the returned provider. |
 
 ## merge\_compilation\_outputs
 
@@ -462,4 +462,4 @@ Merge compilation outputs.
 
 | Parameter | Description |
 | --- | --- |
-| `compilation_outputs` | [sequence](../core/list); default is `[]` |
\ No newline at end of file
+| `compilation_outputs` | [sequence](/versions/8.1.1/rules/lib/core/list); default is `[]` |
\ No newline at end of file
diff --git a/versions/8.1.1/rules/lib/toplevel/config.mdx b/versions/8.1.1/rules/lib/toplevel/config.mdx
index 4b60c243..728da482 100644
--- a/versions/8.1.1/rules/lib/toplevel/config.mdx
+++ b/versions/8.1.1/rules/lib/toplevel/config.mdx
@@ -36,7 +36,7 @@ A bool-typed build setting
 
 | Parameter | Description |
 | --- | --- |
-| `flag` | [bool](../core/bool); default is `False` |
+| `flag` | [bool](/versions/8.1.1/rules/lib/core/bool); default is `False` |
 
 ## exec
 
@@ -50,7 +50,7 @@ Creates an execution transition.
 
 | Parameter | Description |
 | --- | --- |
-| `exec_group` | [string](../core/string); or `None`; default is `None`  The name of the exec group whose execution platform this transition will use. If not provided, this exec transition will use the target's default execution platform. |
+| `exec_group` | [string](/versions/8.1.1/rules/lib/core/string); or `None`; default is `None`  The name of the exec group whose execution platform this transition will use. If not provided, this exec transition will use the target's default execution platform. |
 
 ## int
 
@@ -64,7 +64,7 @@ An integer-typed build setting
 
 | Parameter | Description |
 | --- | --- |
-| `flag` | [bool](../core/bool); default is `False`  Whether or not this build setting is callable on the command line. |
+| `flag` | [bool](/versions/8.1.1/rules/lib/core/bool); default is `False`  Whether or not this build setting is callable on the command line. |
 
 ## none
 
@@ -86,8 +86,8 @@ A string-typed build setting
 
 | Parameter | Description |
 | --- | --- |
-| `flag` | [bool](../core/bool); default is `False`  Whether or not this build setting is callable on the command line. |
-| `allow_multiple` | [bool](../core/bool); default is `False`  Deprecated, use a `string_list` setting with `repeatable = True` instead. If set, this flag is allowed to be set multiple times on the command line. The Value of the flag as accessed in transitions and build setting implementation function will be a list of strings. Insertion order and repeated values are both maintained. This list can be post-processed in the build setting implementation function if different behavior is desired. |
+| `flag` | [bool](/versions/8.1.1/rules/lib/core/bool); default is `False`  Whether or not this build setting is callable on the command line. |
+| `allow_multiple` | [bool](/versions/8.1.1/rules/lib/core/bool); default is `False`  Deprecated, use a `string_list` setting with `repeatable = True` instead. If set, this flag is allowed to be set multiple times on the command line. The Value of the flag as accessed in transitions and build setting implementation function will be a list of strings. Insertion order and repeated values are both maintained. This list can be post-processed in the build setting implementation function if different behavior is desired. |
 
 ## string\_list
 
@@ -101,8 +101,8 @@ A string list-typed build setting. On the command line pass a list using comma-s
 
 | Parameter | Description |
 | --- | --- |
-| `flag` | [bool](../core/bool); default is `False`  Whether or not this build setting is callable on the command line. |
-| `repeatable` | [bool](../core/bool); default is `False`  If set, instead of expecting a comma-separated value, this flag is allowed to be set multiple times on the command line with each individual value treated as a single string to add to the list value. Insertion order and repeated values are both maintained. This list can be post-processed in the build setting implementation function if different behavior is desired. |
+| `flag` | [bool](/versions/8.1.1/rules/lib/core/bool); default is `False`  Whether or not this build setting is callable on the command line. |
+| `repeatable` | [bool](/versions/8.1.1/rules/lib/core/bool); default is `False`  If set, instead of expecting a comma-separated value, this flag is allowed to be set multiple times on the command line with each individual value treated as a single string to add to the list value. Insertion order and repeated values are both maintained. This list can be post-processed in the build setting implementation function if different behavior is desired. |
 
 ## target
 
diff --git a/versions/8.1.1/rules/lib/toplevel/config_common.mdx b/versions/8.1.1/rules/lib/toplevel/config_common.mdx
index 9169b17a..757201b4 100644
--- a/versions/8.1.1/rules/lib/toplevel/config_common.mdx
+++ b/versions/8.1.1/rules/lib/toplevel/config_common.mdx
@@ -29,5 +29,5 @@ Declare a rule's dependency on a toolchain type.
 
 | Parameter | Description |
 | --- | --- |
-| `name` | [string](../core/string); or [Label](../builtins/Label); required  The toolchain type that is required. |
-| `mandatory` | [bool](../core/bool); default is `True`  Whether the toolchain type is mandatory or optional. |
\ No newline at end of file
+| `name` | [string](/versions/8.1.1/rules/lib/core/string); or [Label](/versions/8.1.1/rules/lib/builtins/Label); required  The toolchain type that is required. |
+| `mandatory` | [bool](/versions/8.1.1/rules/lib/core/bool); default is `True`  Whether the toolchain type is mandatory or optional. |
\ No newline at end of file
diff --git a/versions/8.1.1/rules/lib/toplevel/coverage_common.mdx b/versions/8.1.1/rules/lib/toplevel/coverage_common.mdx
index e93e1226..86ef3f2e 100644
--- a/versions/8.1.1/rules/lib/toplevel/coverage_common.mdx
+++ b/versions/8.1.1/rules/lib/toplevel/coverage_common.mdx
@@ -14,14 +14,14 @@ Helper functions to access coverage-related infrastructure.
 InstrumentedFilesInfo coverage_common.instrumented_files_info(ctx, *, source_attributes=[], dependency_attributes=[], extensions=None, metadata_files=[])
 ```
 
-Creates a new [InstrumentedFilesInfo](../providers/InstrumentedFilesInfo) instance. Use this provider to communicate coverage-related attributes of the current build rule.
+Creates a new [InstrumentedFilesInfo](/versions/8.1.1/rules/lib/providers/InstrumentedFilesInfo) instance. Use this provider to communicate coverage-related attributes of the current build rule.
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `ctx` | [ctx](../builtins/ctx); required  The rule context. |
-| `source_attributes` | [sequence](../core/list); default is `[]`  A list of attribute names which contain source files processed by this rule. |
-| `dependency_attributes` | [sequence](../core/list); default is `[]`  A list of attribute names which might provide runtime dependencies (either code dependencies or runfiles). |
-| `extensions` | [sequence](../core/list) of [string](../core/string)s; or `None`; default is `None`  File extensions used to filter files from source\_attributes. For example, 'js'. If not provided (or None), then all files from source\_attributes will be added to instrumented files, if an empty list is provided, then no files from source attributes will be added. |
-| `metadata_files` | [sequence](../core/list) of [File](../builtins/File)s; default is `[]`  Additional files required to generate coverage LCOV files after code execution. e.g. .gcno files for C++. |
\ No newline at end of file
+| `ctx` | [ctx](/versions/8.1.1/rules/lib/builtins/ctx); required  The rule context. |
+| `source_attributes` | [sequence](/versions/8.1.1/rules/lib/core/list); default is `[]`  A list of attribute names which contain source files processed by this rule. |
+| `dependency_attributes` | [sequence](/versions/8.1.1/rules/lib/core/list); default is `[]`  A list of attribute names which might provide runtime dependencies (either code dependencies or runfiles). |
+| `extensions` | [sequence](/versions/8.1.1/rules/lib/core/list) of [string](/versions/8.1.1/rules/lib/core/string)s; or `None`; default is `None`  File extensions used to filter files from source\_attributes. For example, 'js'. If not provided (or None), then all files from source\_attributes will be added to instrumented files, if an empty list is provided, then no files from source attributes will be added. |
+| `metadata_files` | [sequence](/versions/8.1.1/rules/lib/core/list) of [File](/versions/8.1.1/rules/lib/builtins/File)s; default is `[]`  Additional files required to generate coverage LCOV files after code execution. e.g. .gcno files for C++. |
\ No newline at end of file
diff --git a/versions/8.1.1/rules/lib/toplevel/java_common.mdx b/versions/8.1.1/rules/lib/toplevel/java_common.mdx
index 0ba2fe67..b3faa6d3 100644
--- a/versions/8.1.1/rules/lib/toplevel/java_common.mdx
+++ b/versions/8.1.1/rules/lib/toplevel/java_common.mdx
@@ -35,33 +35,33 @@ Compiles Java source files/jars from the implementation of a Starlark rule and r
 
 | Parameter | Description |
 | --- | --- |
-| `ctx` | [ctx](../builtins/ctx); required  The rule context. |
-| `source_jars` | [sequence](../core/list) of [File](../builtins/File)s; default is `[]`  A list of the jars to be compiled. At least one of source\_jars or source\_files should be specified. |
-| `source_files` | [sequence](../core/list) of [File](../builtins/File)s; default is `[]`  A list of the Java source files to be compiled. At least one of source\_jars or source\_files should be specified. |
-| `output` | [File](../builtins/File); required |
-| `output_source_jar` | [File](../builtins/File); or `None`; default is `None`  The output source jar. Defaults to `{output\_jar}-src.jar` if unset. |
-| `javac_opts` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  A list of the desired javac options. |
-| `deps` | [sequence](../core/list) of [struct](../builtins/struct)s; default is `[]`  A list of dependencies. |
-| `runtime_deps` | [sequence](../core/list) of [struct](../builtins/struct)s; default is `[]`  A list of runtime dependencies. |
-| `exports` | [sequence](../core/list) of [struct](../builtins/struct)s; default is `[]`  A list of exports. |
-| `plugins` | [sequence](../core/list) of [struct](../builtins/struct)s; or [sequence](../core/list) of [struct](../builtins/struct)s; default is `[]`  A list of plugins. |
-| `exported_plugins` | [sequence](../core/list) of [struct](../builtins/struct)s; or [sequence](../core/list) of [struct](../builtins/struct)s; default is `[]`  A list of exported plugins. |
-| `native_libraries` | [sequence](../core/list) of [CcInfo](../providers/CcInfo)s; default is `[]`  CC native library dependencies that are needed for this library. |
-| `annotation_processor_additional_inputs` | [sequence](../core/list) of [File](../builtins/File)s; default is `[]`  A list of inputs that the Java compilation action will take in addition to the Java sources for annotation processing. |
-| `annotation_processor_additional_outputs` | [sequence](../core/list) of [File](../builtins/File)s; default is `[]`  A list of outputs that the Java compilation action will output in addition to the class jar from annotation processing. |
-| `strict_deps` | [string](../core/string); default is `'ERROR'`  A string that specifies how to handle strict deps. Possible values: 'OFF', 'ERROR', 'WARN' and 'DEFAULT'. For more details see [`--strict_java_deps flag`](/versions/8.1.1/docs/user-manual#flag--strict_java_deps). By default 'ERROR'. |
+| `ctx` | [ctx](/versions/8.1.1/rules/lib/builtins/ctx); required  The rule context. |
+| `source_jars` | [sequence](/versions/8.1.1/rules/lib/core/list) of [File](/versions/8.1.1/rules/lib/builtins/File)s; default is `[]`  A list of the jars to be compiled. At least one of source\_jars or source\_files should be specified. |
+| `source_files` | [sequence](/versions/8.1.1/rules/lib/core/list) of [File](/versions/8.1.1/rules/lib/builtins/File)s; default is `[]`  A list of the Java source files to be compiled. At least one of source\_jars or source\_files should be specified. |
+| `output` | [File](/versions/8.1.1/rules/lib/builtins/File); required |
+| `output_source_jar` | [File](/versions/8.1.1/rules/lib/builtins/File); or `None`; default is `None`  The output source jar. Defaults to `{output\_jar}-src.jar` if unset. |
+| `javac_opts` | [sequence](/versions/8.1.1/rules/lib/core/list) of [string](/versions/8.1.1/rules/lib/core/string)s; default is `[]`  A list of the desired javac options. |
+| `deps` | [sequence](/versions/8.1.1/rules/lib/core/list) of [struct](/versions/8.1.1/rules/lib/builtins/struct)s; default is `[]`  A list of dependencies. |
+| `runtime_deps` | [sequence](/versions/8.1.1/rules/lib/core/list) of [struct](/versions/8.1.1/rules/lib/builtins/struct)s; default is `[]`  A list of runtime dependencies. |
+| `exports` | [sequence](/versions/8.1.1/rules/lib/core/list) of [struct](/versions/8.1.1/rules/lib/builtins/struct)s; default is `[]`  A list of exports. |
+| `plugins` | [sequence](/versions/8.1.1/rules/lib/core/list) of [struct](/versions/8.1.1/rules/lib/builtins/struct)s; or [sequence](/versions/8.1.1/rules/lib/core/list) of [struct](/versions/8.1.1/rules/lib/builtins/struct)s; default is `[]`  A list of plugins. |
+| `exported_plugins` | [sequence](/versions/8.1.1/rules/lib/core/list) of [struct](/versions/8.1.1/rules/lib/builtins/struct)s; or [sequence](/versions/8.1.1/rules/lib/core/list) of [struct](/versions/8.1.1/rules/lib/builtins/struct)s; default is `[]`  A list of exported plugins. |
+| `native_libraries` | [sequence](/versions/8.1.1/rules/lib/core/list) of [CcInfo](/versions/8.1.1/rules/lib/providers/CcInfo)s; default is `[]`  CC native library dependencies that are needed for this library. |
+| `annotation_processor_additional_inputs` | [sequence](/versions/8.1.1/rules/lib/core/list) of [File](/versions/8.1.1/rules/lib/builtins/File)s; default is `[]`  A list of inputs that the Java compilation action will take in addition to the Java sources for annotation processing. |
+| `annotation_processor_additional_outputs` | [sequence](/versions/8.1.1/rules/lib/core/list) of [File](/versions/8.1.1/rules/lib/builtins/File)s; default is `[]`  A list of outputs that the Java compilation action will output in addition to the class jar from annotation processing. |
+| `strict_deps` | [string](/versions/8.1.1/rules/lib/core/string); default is `'ERROR'`  A string that specifies how to handle strict deps. Possible values: 'OFF', 'ERROR', 'WARN' and 'DEFAULT'. For more details see [`--strict_java_deps flag`](/versions/8.1.1/docs/user-manual#flag--strict_java_deps). By default 'ERROR'. |
 | `java_toolchain` | Info; required  A JavaToolchainInfo to be used for this compilation. Mandatory. |
 | `bootclasspath` | default is `None`  A BootClassPathInfo to be used for this compilation. If present, overrides the bootclasspath associated with the provided java\_toolchain. |
 | `host_javabase` | default is `None`  **Deprecated**. This parameter is deprecated and will be removed soon. Please do not depend on it. It is *disabled* with `--incompatible_java_common_parameters`. Use this flag to verify your code is compatible with its imminent removal.  Deprecated: You can drop this parameter (host\_javabase is provided with java\_toolchain) |
-| `sourcepath` | [sequence](../core/list) of [File](../builtins/File)s; default is `[]` |
-| `resources` | [sequence](../core/list) of [File](../builtins/File)s; default is `[]` |
-| `resource_jars` | [sequence](../core/list) of [File](../builtins/File)s; default is `[]` |
-| `classpath_resources` | [sequence](../core/list) of [File](../builtins/File)s; default is `[]` |
-| `neverlink` | [bool](../core/bool); default is `False` |
-| `enable_annotation_processing` | [bool](../core/bool); default is `True`  Disables annotation processing in this compilation, causing any annotation processors provided in plugins or in exported\_plugins of deps to be ignored. |
-| `enable_compile_jar_action` | [bool](../core/bool); default is `True`  Enables header compilation or ijar creation. If set to False, it forces use of the full class jar in the compilation classpaths of any dependants. Doing so is intended for use by non-library targets such as binaries that do not have dependants. |
-| `add_exports` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  Allow this library to access the given /. |
-| `add_opens` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  Allow this library to reflectively access the given /. |
+| `sourcepath` | [sequence](/versions/8.1.1/rules/lib/core/list) of [File](/versions/8.1.1/rules/lib/builtins/File)s; default is `[]` |
+| `resources` | [sequence](/versions/8.1.1/rules/lib/core/list) of [File](/versions/8.1.1/rules/lib/builtins/File)s; default is `[]` |
+| `resource_jars` | [sequence](/versions/8.1.1/rules/lib/core/list) of [File](/versions/8.1.1/rules/lib/builtins/File)s; default is `[]` |
+| `classpath_resources` | [sequence](/versions/8.1.1/rules/lib/core/list) of [File](/versions/8.1.1/rules/lib/builtins/File)s; default is `[]` |
+| `neverlink` | [bool](/versions/8.1.1/rules/lib/core/bool); default is `False` |
+| `enable_annotation_processing` | [bool](/versions/8.1.1/rules/lib/core/bool); default is `True`  Disables annotation processing in this compilation, causing any annotation processors provided in plugins or in exported\_plugins of deps to be ignored. |
+| `enable_compile_jar_action` | [bool](/versions/8.1.1/rules/lib/core/bool); default is `True`  Enables header compilation or ijar creation. If set to False, it forces use of the full class jar in the compilation classpaths of any dependants. Doing so is intended for use by non-library targets such as binaries that do not have dependants. |
+| `add_exports` | [sequence](/versions/8.1.1/rules/lib/core/list) of [string](/versions/8.1.1/rules/lib/core/string)s; default is `[]`  Allow this library to access the given /. |
+| `add_opens` | [sequence](/versions/8.1.1/rules/lib/core/list) of [string](/versions/8.1.1/rules/lib/core/string)s; default is `[]`  Allow this library to reflectively access the given /. |
 
 ## JavaRuntimeInfo
 
@@ -91,7 +91,7 @@ Merges the given providers into a single JavaInfo.
 
 | Parameter | Description |
 | --- | --- |
-| `providers` | [sequence](../core/list) of [struct](../builtins/struct)s; required  The list of providers to merge. |
+| `providers` | [sequence](/versions/8.1.1/rules/lib/core/list) of [struct](/versions/8.1.1/rules/lib/builtins/struct)s; required  The list of providers to merge. |
 
 ## pack\_sources
 
@@ -109,11 +109,11 @@ Packs sources and source jars into a single source jar file. The return value is
 
 | Parameter | Description |
 | --- | --- |
-| `actions` | [actions](../builtins/actions); required  ctx.actions |
-| `output_jar` | [File](../builtins/File); or `None`; default is `None`  **Deprecated**. This parameter is deprecated and will be removed soon. Please do not depend on it. It is *disabled* with `--incompatible_java_common_parameters`. Use this flag to verify your code is compatible with its imminent removal.  Deprecated: The output jar of the rule. Used to name the resulting source jar. The parameter sets output\_source\_jar parameter to `{output\_jar}-src.jar`.Use output\_source\_jar parameter directly instead. |
-| `output_source_jar` | [File](../builtins/File); or `None`; default is `None` |
-| `sources` | [sequence](../core/list) of [File](../builtins/File)s; default is `[]`  A list of Java source files to be packed into the source jar. |
-| `source_jars` | [sequence](../core/list) of [File](../builtins/File)s; default is `[]`  A list of source jars to be packed into the source jar. |
+| `actions` | [actions](/versions/8.1.1/rules/lib/builtins/actions); required  ctx.actions |
+| `output_jar` | [File](/versions/8.1.1/rules/lib/builtins/File); or `None`; default is `None`  **Deprecated**. This parameter is deprecated and will be removed soon. Please do not depend on it. It is *disabled* with `--incompatible_java_common_parameters`. Use this flag to verify your code is compatible with its imminent removal.  Deprecated: The output jar of the rule. Used to name the resulting source jar. The parameter sets output\_source\_jar parameter to `{output\_jar}-src.jar`.Use output\_source\_jar parameter directly instead. |
+| `output_source_jar` | [File](/versions/8.1.1/rules/lib/builtins/File); or `None`; default is `None` |
+| `sources` | [sequence](/versions/8.1.1/rules/lib/core/list) of [File](/versions/8.1.1/rules/lib/builtins/File)s; default is `[]`  A list of Java source files to be packed into the source jar. |
+| `source_jars` | [sequence](/versions/8.1.1/rules/lib/core/list) of [File](/versions/8.1.1/rules/lib/builtins/File)s; default is `[]`  A list of source jars to be packed into the source jar. |
 | `java_toolchain` | Info; required  A JavaToolchainInfo to used to find the ijar tool. |
 | `host_javabase` | default is `None`  **Deprecated**. This parameter is deprecated and will be removed soon. Please do not depend on it. It is *disabled* with `--incompatible_java_common_parameters`. Use this flag to verify your code is compatible with its imminent removal.  Deprecated: You can drop this parameter (host\_javabase is provided with java\_toolchain) |
 
@@ -129,9 +129,9 @@ Runs ijar on a jar, stripping it of its method bodies. This helps reduce rebuild
 
 | Parameter | Description |
 | --- | --- |
-| `actions` | [actions](../builtins/actions); required |
-| `jar` | [File](../builtins/File); required  The jar to run ijar on. |
-| `target_label` | [Label](../builtins/Label); or `None`; default is `None`  A target label to stamp the jar with. Used for `add_dep` support. Typically, you would pass `ctx.label` to stamp the jar with the current rule's label. |
+| `actions` | [actions](/versions/8.1.1/rules/lib/builtins/actions); required |
+| `jar` | [File](/versions/8.1.1/rules/lib/builtins/File); required  The jar to run ijar on. |
+| `target_label` | [Label](/versions/8.1.1/rules/lib/builtins/Label); or `None`; default is `None`  A target label to stamp the jar with. Used for `add_dep` support. Typically, you would pass `ctx.label` to stamp the jar with the current rule's label. |
 | `java_toolchain` | Info; required  A JavaToolchainInfo to used to find the ijar tool. |
 
 ## stamp\_jar
@@ -146,7 +146,7 @@ Stamps a jar with a target label for `add_dep` support. The return value is typi
 
 | Parameter | Description |
 | --- | --- |
-| `actions` | [actions](../builtins/actions); required  ctx.actions |
-| `jar` | [File](../builtins/File); required  The jar to run stamp\_jar on. |
-| `target_label` | [Label](../builtins/Label); required  A target label to stamp the jar with. Used for `add_dep` support. Typically, you would pass `ctx.label` to stamp the jar with the current rule's label. |
+| `actions` | [actions](/versions/8.1.1/rules/lib/builtins/actions); required  ctx.actions |
+| `jar` | [File](/versions/8.1.1/rules/lib/builtins/File); required  The jar to run stamp\_jar on. |
+| `target_label` | [Label](/versions/8.1.1/rules/lib/builtins/Label); required  A target label to stamp the jar with. Used for `add_dep` support. Typically, you would pass `ctx.label` to stamp the jar with the current rule's label. |
 | `java_toolchain` | Info; required  A JavaToolchainInfo to used to find the stamp\_jar tool. |
\ No newline at end of file
diff --git a/versions/8.1.1/rules/lib/toplevel/native.mdx b/versions/8.1.1/rules/lib/toplevel/native.mdx
index 204fb814..157567cb 100644
--- a/versions/8.1.1/rules/lib/toplevel/native.mdx
+++ b/versions/8.1.1/rules/lib/toplevel/native.mdx
@@ -46,7 +46,7 @@ If possible, avoid using this function. It makes BUILD files brittle and order-d
 
 | Parameter | Description |
 | --- | --- |
-| `name` | [string](../core/string); required |
+| `name` | [string](/versions/8.1.1/rules/lib/core/string); required |
 
 ## existing\_rules
 
@@ -72,9 +72,9 @@ Specifies a list of files belonging to this package that are exported to other p
 
 | Parameter | Description |
 | --- | --- |
-| `srcs` | [sequence](../core/list) of [string](../core/string)s; required  The list of files to export. |
-| `visibility` | [sequence](../core/list); or `None`; default is `None`  A visibility declaration can to be specified. The files will be visible to the targets specified. If no visibility is specified, the files will be visible to every package. |
-| `licenses` | [sequence](../core/list) of [string](../core/string)s; or `None`; default is `None`  Licenses to be specified. |
+| `srcs` | [sequence](/versions/8.1.1/rules/lib/core/list) of [string](/versions/8.1.1/rules/lib/core/string)s; required  The list of files to export. |
+| `visibility` | [sequence](/versions/8.1.1/rules/lib/core/list); or `None`; default is `None`  A visibility declaration can to be specified. The files will be visible to the targets specified. If no visibility is specified, the files will be visible to every package. |
+| `licenses` | [sequence](/versions/8.1.1/rules/lib/core/list) of [string](/versions/8.1.1/rules/lib/core/string)s; or `None`; default is `None`  Licenses to be specified. |
 
 ## glob
 
@@ -93,9 +93,9 @@ If the `exclude_directories` argument is enabled (set to `1`), files of type dir
 
 | Parameter | Description |
 | --- | --- |
-| `include` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  The list of glob patterns to include. |
-| `exclude` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  The list of glob patterns to exclude. |
-| `exclude_directories` | [int](../core/int); default is `1`  A flag whether to exclude directories or not. |
+| `include` | [sequence](/versions/8.1.1/rules/lib/core/list) of [string](/versions/8.1.1/rules/lib/core/string)s; default is `[]`  The list of glob patterns to include. |
+| `exclude` | [sequence](/versions/8.1.1/rules/lib/core/list) of [string](/versions/8.1.1/rules/lib/core/string)s; default is `[]`  The list of glob patterns to exclude. |
+| `exclude_directories` | [int](/versions/8.1.1/rules/lib/core/int); default is `1`  A flag whether to exclude directories or not. |
 | `allow_empty` | default is `unbound`  Whether we allow glob patterns to match nothing. If `allow\_empty` is False, each individual include pattern must match something and also the final result must be non-empty (after the matches of the `exclude` patterns are excluded). |
 
 ## module\_name
@@ -128,9 +128,9 @@ This function defines a set of packages and assigns a label to the group. The la
 
 | Parameter | Description |
 | --- | --- |
-| `name` | [string](../core/string); required  The unique name for this rule. |
-| `packages` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  A complete enumeration of packages in this group. |
-| `includes` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  Other package groups that are included in this one. |
+| `name` | [string](/versions/8.1.1/rules/lib/core/string); required  The unique name for this rule. |
+| `packages` | [sequence](/versions/8.1.1/rules/lib/core/list) of [string](/versions/8.1.1/rules/lib/core/string)s; default is `[]`  A complete enumeration of packages in this group. |
+| `includes` | [sequence](/versions/8.1.1/rules/lib/core/list) of [string](/versions/8.1.1/rules/lib/core/string)s; default is `[]`  Other package groups that are included in this one. |
 
 ## package\_name
 
@@ -146,19 +146,19 @@ The name of the package being evaluated, without the repository name. For exampl
 Label native.package_relative_label(input)
 ```
 
-Converts the input string into a [Label](../builtins/Label) object, in the context of the package currently being initialized (that is, the `BUILD` file for which the current macro is executing). If the input is already a `Label`, it is returned unchanged.
+Converts the input string into a [Label](/versions/8.1.1/rules/lib/builtins/Label) object, in the context of the package currently being initialized (that is, the `BUILD` file for which the current macro is executing). If the input is already a `Label`, it is returned unchanged.
 
 This function may only be called while evaluating a BUILD file and the macros it directly or indirectly calls; it may not be called in (for instance) a rule implementation function.
 
 The result of this function is the same `Label` value as would be produced by passing the given string to a label-valued attribute of a target declared in the BUILD file.
 
-*Usage note:* The difference between this function and [Label()](../builtins/Label#Label) is that `Label()` uses the context of the package of the `.bzl` file that called it, not the package of the `BUILD` file. Use `Label()` when you need to refer to a fixed target that is hardcoded into the macro, such as a compiler. Use `package_relative_label()` when you need to normalize a label string supplied by the BUILD file to a `Label` object. (There is no way to convert a string to a `Label` in the context of a package other than the BUILD file or the calling .bzl file. For that reason, outer macros should always prefer to pass Label objects to inner macros rather than label strings.)
+*Usage note:* The difference between this function and [Label()](/versions/8.1.1/rules/lib/builtins/Label#Label) is that `Label()` uses the context of the package of the `.bzl` file that called it, not the package of the `BUILD` file. Use `Label()` when you need to refer to a fixed target that is hardcoded into the macro, such as a compiler. Use `package_relative_label()` when you need to normalize a label string supplied by the BUILD file to a `Label` object. (There is no way to convert a string to a `Label` in the context of a package other than the BUILD file or the calling .bzl file. For that reason, outer macros should always prefer to pass Label objects to inner macros rather than label strings.)
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `input` | [string](../core/string); or [Label](../builtins/Label); required  The input label string or Label object. If a Label object is passed, it's returned as is. |
+| `input` | [string](/versions/8.1.1/rules/lib/core/string); or [Label](/versions/8.1.1/rules/lib/builtins/Label); required  The input label string or Label object. If a Label object is passed, it's returned as is. |
 
 ## repo\_name
 
@@ -191,6 +191,6 @@ Returns a new mutable list of every direct subpackage of the current package, re
 
 | Parameter | Description |
 | --- | --- |
-| `include` | [sequence](../core/list) of [string](../core/string)s; required |
-| `exclude` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  The list of glob patterns to exclude from subpackages scan. |
-| `allow_empty` | [bool](../core/bool); default is `False`  Whether we fail if the call returns an empty list. By default empty list indicates potential error in BUILD file where the call to subpackages() is superflous. Setting to true allows this function to succeed in that case. |*
\ No newline at end of file
+| `include` | [sequence](/versions/8.1.1/rules/lib/core/list) of [string](/versions/8.1.1/rules/lib/core/string)s; required |
+| `exclude` | [sequence](/versions/8.1.1/rules/lib/core/list) of [string](/versions/8.1.1/rules/lib/core/string)s; default is `[]`  The list of glob patterns to exclude from subpackages scan. |
+| `allow_empty` | [bool](/versions/8.1.1/rules/lib/core/bool); default is `False`  Whether we fail if the call returns an empty list. By default empty list indicates potential error in BUILD file where the call to subpackages() is superflous. Setting to true allows this function to succeed in that case. |*
\ No newline at end of file
diff --git a/versions/8.1.1/rules/lib/toplevel/platform_common.mdx b/versions/8.1.1/rules/lib/toplevel/platform_common.mdx
index 17edc7c5..4f3ecb28 100644
--- a/versions/8.1.1/rules/lib/toplevel/platform_common.mdx
+++ b/versions/8.1.1/rules/lib/toplevel/platform_common.mdx
@@ -18,7 +18,7 @@ Functions for Starlark to interact with the platform APIs.
 Provider platform_common.ConstraintSettingInfo
 ```
 
-The constructor/key for the [ConstraintSettingInfo](../providers/ConstraintSettingInfo) provider.
+The constructor/key for the [ConstraintSettingInfo](/versions/8.1.1/rules/lib/providers/ConstraintSettingInfo) provider.
 *Note: This API is experimental and may change at any time. It is disabled by default, but may be enabled with `--experimental_platforms_api`*
 
 ## ConstraintValueInfo
@@ -27,7 +27,7 @@ The constructor/key for the [ConstraintSettingInfo](../providers/ConstraintSetti
 Provider platform_common.ConstraintValueInfo
 ```
 
-The constructor/key for the [ConstraintValueInfo](../providers/ConstraintValueInfo) provider.
+The constructor/key for the [ConstraintValueInfo](/versions/8.1.1/rules/lib/providers/ConstraintValueInfo) provider.
 *Note: This API is experimental and may change at any time. It is disabled by default, but may be enabled with `--experimental_platforms_api`*
 
 ## PlatformInfo
@@ -36,7 +36,7 @@ The constructor/key for the [ConstraintValueInfo](../providers/ConstraintValueIn
 Provider platform_common.PlatformInfo
 ```
 
-The constructor/key for the [PlatformInfo](../providers/PlatformInfo) provider.
+The constructor/key for the [PlatformInfo](/versions/8.1.1/rules/lib/providers/PlatformInfo) provider.
 *Note: This API is experimental and may change at any time. It is disabled by default, but may be enabled with `--experimental_platforms_api`*
 
 ## TemplateVariableInfo
@@ -45,7 +45,7 @@ The constructor/key for the [PlatformInfo](../providers/PlatformInfo) provider.
 Provider platform_common.TemplateVariableInfo
 ```
 
-The constructor/key for the [TemplateVariableInfo](../providers/TemplateVariableInfo) provider.
+The constructor/key for the [TemplateVariableInfo](/versions/8.1.1/rules/lib/providers/TemplateVariableInfo) provider.
 
 ## ToolchainInfo
 
@@ -53,4 +53,4 @@ The constructor/key for the [TemplateVariableInfo](../providers/TemplateVariable
 Provider platform_common.ToolchainInfo
 ```
 
-The constructor/key for the [ToolchainInfo](../providers/ToolchainInfo) provider.
\ No newline at end of file
+The constructor/key for the [ToolchainInfo](/versions/8.1.1/rules/lib/providers/ToolchainInfo) provider.
\ No newline at end of file
diff --git a/versions/8.1.1/rules/lib/toplevel/testing.mdx b/versions/8.1.1/rules/lib/toplevel/testing.mdx
index 5489113c..c493b466 100644
--- a/versions/8.1.1/rules/lib/toplevel/testing.mdx
+++ b/versions/8.1.1/rules/lib/toplevel/testing.mdx
@@ -24,12 +24,12 @@ The number of transitive dependencies of the test are limited. The limit is cont
 
 | Parameter | Description |
 | --- | --- |
-| `name` | [string](../core/string); required  Name of the target. It should be a Starlark identifier, matching pattern '[A-Za-z\_][A-Za-z0-9\_]\*'. |
-| `implementation` | [function](../core/function); required  The Starlark function implementing this analysis test. It must have exactly one parameter: [ctx](../builtins/ctx). The function is called during the analysis phase. It can access the attributes declared by `attrs` and populated via `attr_values`. The implementation function may not register actions. Instead, it must register a pass/fail result via providing [AnalysisTestResultInfo](../providers/AnalysisTestResultInfo). |
-| `attrs` | [dict](../core/dict); default is `{}`  Dictionary declaring the attributes. See the [rule](../globals/bzl#rule) call. Attributes are allowed to use configuration transitions defined using [analysis\_test\_transition](../globals/bzl#analysis_test_transition). |
-| `fragments` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  List of configuration fragments that are available to the implementation of the analysis test. |
-| `toolchains` | [sequence](../core/list); default is `[]`  The set of toolchains the test requires. See the [rule](../globals/bzl#rule) call. |
-| `attr_values` | [dict](../core/dict) of [string](../core/string)s; default is `{}`  Dictionary of attribute values to pass to the implementation. |
+| `name` | [string](/versions/8.1.1/rules/lib/core/string); required  Name of the target. It should be a Starlark identifier, matching pattern '[A-Za-z\_][A-Za-z0-9\_]\*'. |
+| `implementation` | [function](/versions/8.1.1/rules/lib/core/function); required  The Starlark function implementing this analysis test. It must have exactly one parameter: [ctx](/versions/8.1.1/rules/lib/builtins/ctx). The function is called during the analysis phase. It can access the attributes declared by `attrs` and populated via `attr_values`. The implementation function may not register actions. Instead, it must register a pass/fail result via providing [AnalysisTestResultInfo](/versions/8.1.1/rules/lib/providers/AnalysisTestResultInfo). |
+| `attrs` | [dict](/versions/8.1.1/rules/lib/core/dict); default is `{}`  Dictionary declaring the attributes. See the [rule](/versions/8.1.1/rules/lib/globals/bzl#rule) call. Attributes are allowed to use configuration transitions defined using [analysis\_test\_transition](/versions/8.1.1/rules/lib/globals/bzl#analysis_test_transition). |
+| `fragments` | [sequence](/versions/8.1.1/rules/lib/core/list) of [string](/versions/8.1.1/rules/lib/core/string)s; default is `[]`  List of configuration fragments that are available to the implementation of the analysis test. |
+| `toolchains` | [sequence](/versions/8.1.1/rules/lib/core/list); default is `[]`  The set of toolchains the test requires. See the [rule](/versions/8.1.1/rules/lib/globals/bzl#rule) call. |
+| `attr_values` | [dict](/versions/8.1.1/rules/lib/core/dict) of [string](/versions/8.1.1/rules/lib/core/string)s; default is `{}`  Dictionary of attribute values to pass to the implementation. |
 
 ## ExecutionInfo
 
@@ -37,7 +37,7 @@ The number of transitive dependencies of the test are limited. The limit is cont
 ExecutionInfo testing.ExecutionInfo
 ```
 
-[testing.ExecutionInfo](../providers/ExecutionInfo) provider key/constructor
+[testing.ExecutionInfo](/versions/8.1.1/rules/lib/providers/ExecutionInfo) provider key/constructor
 
 ## TestEnvironment
 
@@ -51,5 +51,5 @@ RunEnvironmentInfo testing.TestEnvironment(environment, inherited_environment=[]
 
 | Parameter | Description |
 | --- | --- |
-| `environment` | [dict](../core/dict); required  A map of string keys and values that represent environment variables and their values. These will be made available during the test execution. |
-| `inherited_environment` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  A sequence of names of environment variables. These variables are made available during the test execution with their current value taken from the shell environment. If a variable is contained in both `environment` and `inherited_environment`, the value inherited from the shell environment will take precedence if set. |
\ No newline at end of file
+| `environment` | [dict](/versions/8.1.1/rules/lib/core/dict); required  A map of string keys and values that represent environment variables and their values. These will be made available during the test execution. |
+| `inherited_environment` | [sequence](/versions/8.1.1/rules/lib/core/list) of [string](/versions/8.1.1/rules/lib/core/string)s; default is `[]`  A sequence of names of environment variables. These variables are made available during the test execution with their current value taken from the shell environment. If a variable is contained in both `environment` and `inherited_environment`, the value inherited from the shell environment will take precedence if set. |
\ No newline at end of file
diff --git a/versions/8.1.1/rules/macro-tutorial.mdx b/versions/8.1.1/rules/macro-tutorial.mdx
index 40c6892c..a89f9b40 100644
--- a/versions/8.1.1/rules/macro-tutorial.mdx
+++ b/versions/8.1.1/rules/macro-tutorial.mdx
@@ -5,7 +5,7 @@ title: 'Creating a Symbolic Macro'
 IMPORTANT: This tutorial is for [*symbolic macros*](/versions/8.1.1/extending/macros) – the new
 macro system introduced in Bazel 8. If you need to support older Bazel versions,
 you will want to write a [legacy macro](/versions/8.1.1/extending/legacy-macros) instead; take
-a look at [Creating a Legacy Macro](../legacy-macro-tutorial).
+a look at [Creating a Legacy Macro](/versions/8.1.1/rules/legacy-macro-tutorial).
 
 Imagine that you need to run a tool as part of your build. For example, you
 may want to generate or preprocess a source file, or compress a binary. In this
diff --git a/versions/8.1.1/rules/performance.mdx b/versions/8.1.1/rules/performance.mdx
index f91d85c8..69e9eccd 100644
--- a/versions/8.1.1/rules/performance.mdx
+++ b/versions/8.1.1/rules/performance.mdx
@@ -15,7 +15,7 @@ widespread use.
 ## Use depsets {#use-depsets}
 
 Whenever you are rolling up information from rule dependencies you should use
-[depsets](lib/depset). Only use plain lists or dicts to publish information
+[depsets](/versions/8.1.1/rules/lib/builtins/depset). Only use plain lists or dicts to publish information
 local to the current rule.
 
 A depset represents information as a nested graph which enables sharing.
@@ -73,7 +73,7 @@ See the [depset overview](/versions/8.1.1/extending/depsets) page for more infor
 ### Avoid calling `depset.to_list()` {#avoid-depset-to-list}
 
 You can coerce a depset to a flat list using
-[`to_list()`](lib/depset#to_list), but doing so usually results in O(N^2)
+[`to_list()`](/versions/8.1.1/rules/lib/builtins/depset#to_list), but doing so usually results in O(N^2)
 cost. If at all possible, avoid any flattening of depsets except for debugging
 purposes.
 
@@ -115,7 +115,7 @@ x = depset(transitive = [i.deps for i in inputs])
 
 ## Use ctx.actions.args() for command lines {#ctx-actions-args}
 
-When building command lines you should use [ctx.actions.args()](lib/Args).
+When building command lines you should use [ctx.actions.args()](/versions/8.1.1/rules/lib/builtins/Args).
 This defers expansion of any depsets to the execution phase.
 
 Apart from being strictly faster, this will reduce the memory consumption of
@@ -126,11 +126,11 @@ Here are some tricks:
 * Pass depsets and lists directly as arguments, instead of flattening them
 yourself. They will get expanded by `ctx.actions.args()` for you.
 If you need any transformations on the depset contents, look at
-[ctx.actions.args#add](lib/Args#add) to see if anything fits the bill.
+[ctx.actions.args#add](/versions/8.1.1/rules/lib/builtins/Args#add) to see if anything fits the bill.
 
 * Are you passing `File#path` as arguments? No need. Any
-[File](lib/File) is automatically turned into its
-[path](lib/File#path), deferred to expansion time.
+[File](/versions/8.1.1/rules/lib/builtins/File) is automatically turned into its
+[path](/versions/8.1.1/rules/lib/builtins/File#path), deferred to expansion time.
 
 * Avoid constructing strings by concatenating them together.
 The best string argument is a constant as its memory will be shared between
@@ -138,10 +138,10 @@ all instances of your rule.
 
 * If the args are too long for the command line an `ctx.actions.args()` object
 can be conditionally or unconditionally written to a param file using
-[`ctx.actions.args#use_param_file`](lib/Args#use_param_file). This is
+[`ctx.actions.args#use_param_file`](/versions/8.1.1/rules/lib/builtins/Args#use_param_file). This is
 done behind the scenes when the action is executed. If you need to explicitly
 control the params file you can write it manually using
-[`ctx.actions.write`](lib/actions#write).
+[`ctx.actions.write`](/versions/8.1.1/rules/lib/builtins/actions#write).
 
 Example:
 
@@ -176,7 +176,7 @@ def _to_short_path(f):
 
 ## Transitive action inputs should be depsets {#transitive-action-inputs}
 
-When building an action using [ctx.actions.run](lib/actions?#run), do not
+When building an action using [ctx.actions.run](/versions/8.1.1/rules/lib/builtins/actions#run), do not
 forget that the `inputs` field accepts a depset. Use this whenever inputs are
 collected from dependencies transitively.
 
diff --git a/versions/8.1.1/rules/rules-tutorial.mdx b/versions/8.1.1/rules/rules-tutorial.mdx
index 3b3f54a8..214d8f07 100644
--- a/versions/8.1.1/rules/rules-tutorial.mdx
+++ b/versions/8.1.1/rules/rules-tutorial.mdx
@@ -31,9 +31,9 @@ foo_binary = rule(
 )
 ```
 
-When you call the [`rule`](lib/globals#rule) function, you
+When you call the [`rule`](/versions/8.1.1/rules/lib/globals#rule) function, you
 must define a callback function. The logic will go there, but you
-can leave the function empty for now. The [`ctx`](lib/ctx) argument
+can leave the function empty for now. The [`ctx`](/versions/8.1.1/rules/lib/builtins/ctx) argument
 provides information about the target.
 
 You can load the rule and use it from a `BUILD` file.
@@ -86,10 +86,10 @@ foo_binary(name = "bin1")
 foo_binary(name = "bin2")
 ```
 
-[`ctx.label`](lib/ctx#label)
+[`ctx.label`](/versions/8.1.1/rules/lib/builtins/ctx#label)
 corresponds to the label of the target being analyzed. The `ctx` object has
 many useful fields and methods; you can find an exhaustive list in the
-[API reference](lib/ctx).
+[API reference](/versions/8.1.1/rules/lib/builtins/ctx).
 
 Query the code:
 
@@ -145,7 +145,7 @@ bin2
 ```
 
 Whenever you declare a file, you have to tell Bazel how to generate it by
-creating an action. Use [`ctx.actions.write`](lib/actions#write),
+creating an action. Use [`ctx.actions.write`](/versions/8.1.1/rules/lib/builtins/actions#write),
 to create a file with the given content.
 
 ```python
@@ -200,7 +200,7 @@ You have successfully generated a file!
 ## Attributes
 
 To make the rule more useful, add new attributes using
-[the `attr` module](lib/attr) and update the rule definition.
+[the `attr` module](/versions/8.1.1/rules/lib/toplevel/attr) and update the rule definition.
 
 Add a string attribute called `username`:
 
@@ -236,22 +236,22 @@ def _foo_binary_impl(ctx):
 ```
 
 Note that you can make the attribute mandatory or set a default value. Look at
-the documentation of [`attr.string`](lib/attr#string).
-You may also use other types of attributes, such as [boolean](lib/attr#bool)
-or [list of integers](lib/attr#int_list).
+the documentation of [`attr.string`](/versions/8.1.1/rules/lib/toplevel/attr#string).
+You may also use other types of attributes, such as [boolean](/versions/8.1.1/rules/lib/toplevel/attr#bool)
+or [list of integers](/versions/8.1.1/rules/lib/toplevel/attr#int_list).
 
 ## Dependencies
 
-Dependency attributes, such as [`attr.label`](lib/attr#label)
-and [`attr.label_list`](lib/attr#label_list),
+Dependency attributes, such as [`attr.label`](/versions/8.1.1/rules/lib/toplevel/attr#label)
+and [`attr.label_list`](/versions/8.1.1/rules/lib/toplevel/attr#label_list),
 declare a dependency from the target that owns the attribute to the target whose
 label appears in the attribute's value. This kind of attribute forms the basis
 of the target graph.
 
 In the `BUILD` file, the target label appears as a string object, such as
 `//pkg:name`. In the implementation function, the target will be accessible as a
-[`Target`](lib/Target) object. For example, view the files returned
-by the target using [`Target.files`](lib/Target#modules.Target.files).
+[`Target`](/versions/8.1.1/rules/lib/builtins/Target) object. For example, view the files returned
+by the target using [`Target.files`](/versions/8.1.1/rules/lib/builtins/Target#modules.Target.files).
 
 ### Multiple files
 
@@ -294,7 +294,7 @@ implementation function, but this has two problems. First, as the template gets
 bigger, it becomes more memory efficient to put it in a separate file and avoid
 constructing large strings during the analysis phase. Second, using a separate
 file is more convenient for the user. Instead, use
-[`ctx.actions.expand_template`](lib/actions#expand_template),
+[`ctx.actions.expand_template`](/versions/8.1.1/rules/lib/builtins/actions#expand_template),
 which performs substitutions on a template file.
 
 Create a `template` attribute to declare a dependency on the template
diff --git a/versions/8.1.1/rules/testing.mdx b/versions/8.1.1/rules/testing.mdx
index d4aaa722..46d19df8 100644
--- a/versions/8.1.1/rules/testing.mdx
+++ b/versions/8.1.1/rules/testing.mdx
@@ -234,7 +234,7 @@ def _inspect_actions_test_impl(ctx):
 ```
 
 Note that `analysistest.target_actions(env)` returns a list of
-[`Action`](lib/Action) objects which represent actions registered by the
+[`Action`](/versions/8.1.1/rules/lib/builtins/Action) objects which represent actions registered by the
 target under test.
 
 ### Verifying rule behavior under different flags {#verifying-rule-behavior}
diff --git a/versions/8.1.1/rules/verbs-tutorial.mdx b/versions/8.1.1/rules/verbs-tutorial.mdx
index 8ef4d284..5e06ac09 100644
--- a/versions/8.1.1/rules/verbs-tutorial.mdx
+++ b/versions/8.1.1/rules/verbs-tutorial.mdx
@@ -49,8 +49,7 @@ This pattern can also be seen in the Angular project. The
 produces two targets. The first is a standard `nodejs_test` target which compares
 some generated output against a "golden" file (that is, a file containing the
 expected output). This can be built and run with a normal `bazel
-test` invocation. In `angular-cli`, you can run [one such
-target](https://github.com/angular/angular-cli/blob/e1269cb520871ee29b1a4eec6e6c0e4a94f0b5fc/etc/api/BUILD)
+test` invocation. In `angular-cli`, you can run [one such target](https://github.com/angular/angular-cli/blob/e1269cb520871ee29b1a4eec6e6c0e4a94f0b5fc/etc/api/BUILD)
 with `bazel test //etc/api:angular_devkit_core_api`.
 
 Over time, this golden file may need to be updated for legitimate reasons.
@@ -159,7 +158,7 @@ an imaginary `bazel publish` command.
 It's not immediately obvious what the implementation of the `_sphinx_publisher`
 rule might look like. Often, actions like this write a _launcher_ shell script.
 This method typically involves using
-[`ctx.actions.expand_template`](lib/actions#expand_template)
+[`ctx.actions.expand_template`](/versions/8.1.1/rules/lib/builtins/actions#expand_template)
 to write a very simple shell script, in this case invoking the publisher binary
 with a path to the output of the primary target. This way, the publisher
 implementation can remain generic, the `_sphinx_site` rule can just produce
diff --git a/versions/8.1.1/run/build.mdx b/versions/8.1.1/run/build.mdx
index 2b06f1aa..ba447022 100644
--- a/versions/8.1.1/run/build.mdx
+++ b/versions/8.1.1/run/build.mdx
@@ -626,8 +626,7 @@ Note: Hermeticity means that the action only uses its declared input
 files and no other files in the filesystem, and it only produces its declared
 output files. See [Hermeticity](/versions/8.1.1/basics/hermeticity) for more details.
 
-On some platforms such as [Google Kubernetes
-Engine](https://cloud.google.com/kubernetes-engine/) cluster nodes or Debian,
+On some platforms such as [Google Kubernetes Engine](https://cloud.google.com/kubernetes-engine/) cluster nodes or Debian,
 user namespaces are deactivated by default due to security
 concerns. This can be checked by looking at the file
 `/proc/sys/kernel/unprivileged_userns_clone`: if it exists and contains a 0,
diff --git a/versions/8.1.1/start/android-app.mdx b/versions/8.1.1/start/android-app.mdx
index 9dec18c9..b8dc8ae8 100644
--- a/versions/8.1.1/start/android-app.mdx
+++ b/versions/8.1.1/start/android-app.mdx
@@ -36,8 +36,7 @@ In this tutorial you learn how to:
 Before you begin the tutorial, install the following software:
 
 * **Bazel.** To install, follow the [installation instructions](/versions/8.1.1/install).
-* **Android Studio.** To install, follow the steps to [download Android
-  Studio](https://developer.android.com/sdk/index.html).
+* **Android Studio.** To install, follow the steps to [download Android Studio](https://developer.android.com/sdk/index.html).
   Execute the setup wizard to download the SDK and configure your environment.
 * (Optional) **Git.** Use `git` to download the Android app project.
 
@@ -52,8 +51,7 @@ This app has a single button that prints a greeting when clicked:
 
 **Figure 1.** Android app button greeting.
 
-Clone the repository with `git` (or [download the ZIP file
-directly](https://github.com/bazelbuild/examples/archive/master.zip)):
+Clone the repository with `git` (or [download the ZIP file directly](https://github.com/bazelbuild/examples/archive/master.zip)):
 
 ```posix-terminal
 git clone https://github.com/bazelbuild/examples
@@ -103,8 +101,7 @@ A [workspace](/versions/8.1.1/concepts/build-ref#workspace) is a directory that
 source files for one or more software projects, and has a `MODULE.bazel` file at
 its root.
 
-The `MODULE.bazel` file may be empty or may contain references to [external
-dependencies](/versions/8.1.1/external/overview) required to build your project.
+The `MODULE.bazel` file may be empty or may contain references to [external dependencies](/versions/8.1.1/external/overview) required to build your project.
 
 First, run the following command to create an empty `MODULE.bazel` file:
 
@@ -147,8 +144,7 @@ environment variable, and automatically detect the highest API level and the
 latest version of build tools installed within that location.
 
 You can set the `ANDROID_HOME` variable to the location of the Android SDK. Find
-the path to the installed SDK using Android Studio's [SDK
-Manager](https://developer.android.com/studio/intro/update#sdk-manager).
+the path to the installed SDK using Android Studio's [SDK Manager](https://developer.android.com/studio/intro/update#sdk-manager).
 Assuming the SDK is installed to default locations, you can use the following
 commands to set the `ANDROID_HOME` variable:
 
@@ -170,16 +166,14 @@ them permanent, run the following commands:
 | Windows (PowerShell)     | `[System.Environment]::SetEnvironmentVariable('ANDROID_HOME', "$env:LOCALAPPDATA\Android\Sdk", [System.EnvironmentVariableTarget]::User)` |
 
 **Optional:** If you want to compile native code into your Android app, you
-also need to download the [Android
-NDK](https://developer.android.com/ndk/downloads/index.html)
+also need to download the [Android NDK](https://developer.android.com/ndk/downloads/index.html)
 and use `rules_android_ndk` by adding the following line to your `MODULE.bazel` file:
 
 ```python
 bazel_dep(name = "rules_android_ndk", version = "0.1.2")
 ```
 
-For more information, read [Using the Android Native Development Kit with
-Bazel](/versions/8.1.1/docs/android-ndk).
+For more information, read [Using the Android Native Development Kit with Bazel](/versions/8.1.1/docs/android-ndk).
 
 It's not necessary to set the API levels to the same value for the SDK and NDK.
 [This page](https://developer.android.com/ndk/guides/stable_apis.html)
@@ -221,8 +215,7 @@ files or other dependencies. Bazel provides two build rules,
 build an Android app.
 
 For this tutorial, you'll first use the
-`android_library` rule to tell Bazel to build an [Android library
-module](http://developer.android.com/tools/projects/index.html#LibraryProjects)
+`android_library` rule to tell Bazel to build an [Android library module](http://developer.android.com/tools/projects/index.html#LibraryProjects)
 from the app source code and resource files. You'll then use the
 `android_binary` rule to tell Bazel how to build the Android application package.
 
@@ -337,11 +330,9 @@ file:
 ### Run the app
 
 You can now deploy the app to a connected Android device or emulator from the
-command line using the [`bazel
-mobile-install`](/versions/8.1.1/docs/user-manual#mobile-install) command. This command uses
+command line using the [`bazel mobile-install`](/versions/8.1.1/docs/user-manual#mobile-install) command. This command uses
 the Android Debug Bridge (`adb`) to communicate with the device. You must set up
-your device to use `adb` following the instructions in [Android Debug
-Bridge](http://developer.android.com/tools/help/adb.html) before deployment. You
+your device to use `adb` following the instructions in [Android Debug Bridge](http://developer.android.com/tools/help/adb.html) before deployment. You
 can also choose to install the app on the Android emulator included in Android
 Studio. Make sure the emulator is running before executing the command below.
 
diff --git a/versions/8.1.1/start/cpp.mdx b/versions/8.1.1/start/cpp.mdx
index 5fefdd35..89ab7ff9 100644
--- a/versions/8.1.1/start/cpp.mdx
+++ b/versions/8.1.1/start/cpp.mdx
@@ -19,8 +19,7 @@ Estimated completion time: 30 minutes.
 ### Prerequisites {#prerequisites}
 
 Start by [installing Bazel](https://bazel.build/versions/8.1.1/install), if you haven't
-already. This tutorial uses Git for source control, so for best results [install
-Git](https://git-scm.com/book/en/v2/Getting-Started-Installing-Git) as well.
+already. This tutorial uses Git for source control, so for best results [install Git](https://git-scm.com/book/en/v2/Getting-Started-Installing-Git) as well.
 
 Next, retrieve the sample project from Bazel's GitHub repository by running the
 following in your command-line tool of choice:
@@ -63,9 +62,7 @@ examples
 ```
 
 There are three sets of files, each set representing a stage in this tutorial.
-In the first stage, you will build a single [target]
-(https://bazel.build/reference/glossary#target) residing in a single [package]
-(https://bazel.build/reference/glossary#package). In the second stage, you will
+In the first stage, you will build a single [target](https://bazel.build/versions/8.1.1/reference/glossary#target) residing in a single [package](https://bazel.build/versions/8.1.1/reference/glossary#package). In the second stage, you will
 build both a binary and a library from a single package. In the third and final
 stage, you will build a project with multiple packages and build it with
 multiple targets.
@@ -86,8 +83,7 @@ It also contains these significant files:
 *   The `MODULE.bazel` file, which identifies the directory and its contents as
     a Bazel workspace and lives at the root of the project's directory
     structure. It's also where you specify your external dependencies.
-*   One or more [`BUILD`
-    files](https://bazel.build/reference/glossary#build-file), which tell Bazel
+*   One or more [`BUILD` files](https://bazel.build/versions/8.1.1/reference/glossary#build-file), which tell Bazel
     how to build different parts of the project. A directory within the
     workspace that contains a `BUILD` file is a
     [package](https://bazel.build/versions/8.1.1/reference/glossary#package). (More on packages
@@ -182,9 +178,7 @@ This results in a printed "`Hello world`" message.
 
 Here's the dependency graph of Stage 1:
 
-![Dependency graph for hello-world displays a single target with a single source
-file.](/versions/8.1.1/docs/images/cpp-tutorial-stage1.png "Dependency graph for hello-world
-displays a single target with a single source file.")
+![Dependency graph for hello-world displays a single target with a single source file.](/versions/8.1.1/docs/images/cpp-tutorial-stage1.png "Dependency graph for hello-world displays a single target with a single source file.")
 
 ### Summary: stage 1 {#summary-stage-1}
 
@@ -231,8 +225,7 @@ cc_binary(
 ```
 
 With this `BUILD` file, Bazel first builds the `hello-greet` library (using
-Bazel's built-in [`cc_library`
-rule](https://bazel.build/reference/be/c-cpp#cc_library)), then the
+Bazel's built-in [`cc_library` rule](https://bazel.build/versions/8.1.1/reference/be/c-cpp#cc_library)), then the
 `hello-world` binary. The `deps` attribute in the `hello-world` target tells
 Bazel that the `hello-greet` library is required to build the `hello-world`
 binary.
@@ -272,10 +265,7 @@ recompiles that file.
 Looking at the dependency graph, you can see that `hello-world` depends on an
 extra input named `hello-greet`:
 
-![Dependency graph for `hello-world` displays dependency changes after
-modification to the file.](/versions/8.1.1/docs/images/cpp-tutorial-stage2.png "Dependency
-graph for `hello-world` displays dependency changes after modification to the
-file.")
+![Dependency graph for `hello-world` displays dependency changes after modification to the file.](/versions/8.1.1/docs/images/cpp-tutorial-stage2.png "Dependency graph for `hello-world` displays dependency changes after modification to the file.")
 
 ### Summary: stage 2 {#summary-stage-2}
 
@@ -343,11 +333,7 @@ in the `lib` package (hence the target label `//lib:hello-time`) - Bazel knows
 this through the `deps` attribute. You can see this reflected in the dependency
 graph:
 
-![Dependency graph for `hello-world` displays how the target in the main package
-depends on the target in the `lib`
-package.](/versions/8.1.1/docs/images/cpp-tutorial-stage3.png "Dependency graph for
-`hello-world` displays how the target in the main package depends on the target
-in the `lib` package.")
+![Dependency graph for `hello-world` displays how the target in the main package depends on the target in the `lib` package.](/versions/8.1.1/docs/images/cpp-tutorial-stage3.png "Dependency graph for `hello-world` displays how the target in the main package depends on the target in the `lib` package.")
 
 For the build to succeed, you make the `//lib:hello-time` target in `lib/BUILD`
 explicitly visible to targets in `main/BUILD` using the visibility attribute.
@@ -395,15 +381,11 @@ Bazel journey.
 You've now completed your first basic build with Bazel, but this is just the
 start. Here are some more resources to continue learning with Bazel:
 
-*   To keep focusing on C++, read about common [C++ build use
-    cases](https://bazel.build/tutorials/cpp-use-cases).
+*   To keep focusing on C++, read about common [C++ build use cases](https://bazel.build/versions/8.1.1/tutorials/cpp-use-cases).
 *   To get started with building other applications with Bazel, see the
-    tutorials for [Java](https://bazel.build/versions/8.1.1/start/java), [Android
-    application](https://bazel.build/start/android-app), or [iOS
-    application](https://bazel.build/start/ios-app).
+    tutorials for [Java](https://bazel.build/versions/8.1.1/start/java), [Android application](https://bazel.build/versions/8.1.1/start/android-app), or [iOS application](https://bazel.build/versions/8.1.1/start/ios-app).
 *   To learn more about working with local and remote repositories, read about
     [external dependencies](https://bazel.build/versions/8.1.1/docs/external).
-*   To learn more about Bazel's other rules, see this [reference
-    guide](https://bazel.build/rules).
+*   To learn more about Bazel's other rules, see this [reference guide](https://bazel.build/versions/8.1.1/rules).
 
 Happy building!
\ No newline at end of file
diff --git a/versions/8.1.1/start/java.mdx b/versions/8.1.1/start/java.mdx
index 7571a904..56db7cb0 100644
--- a/versions/8.1.1/start/java.mdx
+++ b/versions/8.1.1/start/java.mdx
@@ -241,8 +241,7 @@ recompiles that file.
 Looking at the dependency graph, you can see that `ProjectRunner` depends on the
 same inputs as it did before, but the structure of the build is different:
 
-![Dependency graph of the target 'ProjectRunner' after adding a dependency](
-/docs/images/tutorial_java_02.svg)
+![Dependency graph of the target 'ProjectRunner' after adding a dependency](/versions/8.1.1/docs/images/tutorial_java_02.svg)
 
 You've now built the project with two targets. The `ProjectRunner` target builds
 one source files and depends on one other target (`:greeter`), which builds
@@ -426,7 +425,7 @@ For more details, see:
 *  The [C++ build tutorial](/versions/8.1.1/start/cpp) to get started with building
    C++ projects with Bazel.
 
-*  The [Android application tutorial](/versions/8.1.1/start/android-app ) and
+*  The [Android application tutorial](/versions/8.1.1/start/android-app) and
    [iOS application tutorial](/versions/8.1.1/start/ios-app)) to get started with
    building mobile applications for Android and iOS with Bazel.
 
diff --git a/versions/8.1.1/tutorials/ccp-toolchain-config.mdx b/versions/8.1.1/tutorials/ccp-toolchain-config.mdx
index e194c28e..23bdb30f 100644
--- a/versions/8.1.1/tutorials/ccp-toolchain-config.mdx
+++ b/versions/8.1.1/tutorials/ccp-toolchain-config.mdx
@@ -29,8 +29,7 @@ uses `clang version 16`, which you can install on your system.
 
 Set up your build environment as follows:
 
-1.  If you have not already done so, [download and install Bazel
-    7.0.2](https://bazel.build/install) or later.
+1.  If you have not already done so, [download and install Bazel 7.0.2](https://bazel.build/versions/8.1.1/install) or later.
 
 2.  Add an empty `MODULE.bazel` file at the root folder.
 
@@ -450,8 +449,7 @@ The key takeaways are:
 
 -   You need to specify a matching `platforms` flag in the command line for
     Bazel to resolve to the toolchain for the same constraint values on the
-    platform. The documentation holds more [information about language specific
-    configuration flags](/versions/8.1.1/concepts/platforms).
+    platform. The documentation holds more [information about language specific configuration flags](/versions/8.1.1/concepts/platforms).
 -   You have to let the toolchain know where the tools live. In this tutorial
     there is a simplified version where you access the tools from the system. If
     you are interested in a more self-contained approach, you can read about
@@ -464,5 +462,4 @@ The key takeaways are:
 
 ## Further reading {#further-reading}
 
-For more details, see [C++ toolchain
-configuration](/versions/8.1.1/docs/cc-toolchain-config-reference)
\ No newline at end of file
+For more details, see [C++ toolchain configuration](/versions/8.1.1/docs/cc-toolchain-config-reference)
\ No newline at end of file
diff --git a/versions/8.2.1/about/roadmap.mdx b/versions/8.2.1/about/roadmap.mdx
index e9ddad48..75a32a1d 100644
--- a/versions/8.2.1/about/roadmap.mdx
+++ b/versions/8.2.1/about/roadmap.mdx
@@ -13,8 +13,7 @@ projects.
 
 ## Bazel 8.0 Release
 
-We plan to bring Bazel 8.0 [long term support
-(LTS)](https://bazel.build/release/versioning) to you in late 2024.
+We plan to bring Bazel 8.0 [long term support (LTS)](https://bazel.build/versions/8.2.1/release/versioning) to you in late 2024.
 The following features are planned to be implemented.
 
 ### Bzlmod: external dependency management system
@@ -29,8 +28,7 @@ support will be removed. Starting with Bazel 7.1, you can set
 `--noenable_workspace` to opt into the new behavior.
 
 Bazel 8.0 will contain a number of enhancements to
-[Bazel's external dependency management]
-(https://docs.google.com/document/d/1moQfNcEIttsk6vYanNKIy3ZuK53hQUFq1b1r0rmsYVg/edit#heading=h.lgyp7ubwxmjc)
+[Bazel's external dependency management](https://docs.google.com/document/d/1moQfNcEIttsk6vYanNKIy3ZuK53hQUFq1b1r0rmsYVg/edit#heading=h.lgyp7ubwxmjc)
 functionality, including:
 
 *   The new flag `--enable_workspace` can be set to `false` to completely
diff --git a/versions/8.2.1/basics/dependencies.mdx b/versions/8.2.1/basics/dependencies.mdx
index 81851301..9fc1ff43 100644
--- a/versions/8.2.1/basics/dependencies.mdx
+++ b/versions/8.2.1/basics/dependencies.mdx
@@ -65,8 +65,7 @@ targets, we’ve made some strides in mitigating the downside by investing in
 tooling to automatically manage `BUILD` files to avoid burdening developers.
 
 Some of these tools, such as `buildifier` and `buildozer`, are available with
-Bazel in the [`buildtools`
-directory](https://github.com/bazelbuild/buildtools).
+Bazel in the [`buildtools` directory](https://github.com/bazelbuild/buildtools).
 
 ## Minimizing Module Visibility
 
@@ -106,8 +105,7 @@ transitive dependencies (Figure 1). Suppose target A depends on target B, which
 depends on a common library target C. Should target A be able to use classes
 defined in target C?
 
-[![Transitive
-dependencies](/versions/8.2.1/images/transitive-dependencies.png)](/versions/8.2.1/images/transitive-dependencies.png)
+[![Transitive dependencies](/versions/8.2.1/images/transitive-dependencies.png)](/versions/8.2.1/images/transitive-dependencies.png)
 
 **Figure 1**. Transitive dependencies
 
@@ -141,9 +139,7 @@ dependencies and adding them to a `BUILD` files without any developer
 intervention. But even without such tools, we’ve found the trade-off to be well
 worth it as the codebase scales: explicitly adding a dependency to `BUILD` file
 is a one-time cost, but dealing with implicit transitive dependencies can cause
-ongoing problems as long as the build target exists. Bazel [enforces strict
-transitive
-dependencies](https://blog.bazel.build/2017/06/28/sjd-unused_deps.html)
+ongoing problems as long as the build target exists. Bazel [enforces strict transitive dependencies](https://blog.bazel.build/2017/06/28/sjd-unused_deps.html)
 on Java code by default.
 
 ### External dependencies
@@ -192,8 +188,7 @@ so in theory there’s no reason that different versions of the same external
 dependency couldn’t both be declared in the build system under different names.
 That way, each target could choose which version of the dependency it wanted to
 use. This causes a lot of problems in practice, so Google enforces a strict
-[One-Version
-Rule](https://opensource.google/docs/thirdparty/oneversion/) for
+[One-Version Rule](https://opensource.google/docs/thirdparty/oneversion/) for
 all third-party dependencies in our codebase.
 
 The biggest problem with allowing multiple versions is the diamond dependency
@@ -232,8 +227,7 @@ Bazel did not use to automatically download transitive dependencies. It used to
 employ a `WORKSPACE` file that required all transitive dependencies to be
 listed, which led to a lot of pain when managing external dependencies. Bazel
 has since added support for automatic transitive external dependency management
-in the form of the `MODULE.bazel` file. See [external dependency
-overview](/versions/8.2.1/external/overview) for more details.
+in the form of the `MODULE.bazel` file. See [external dependency overview](/versions/8.2.1/external/overview) for more details.
 
 Yet again, the choice here is one between convenience and scalability. Small
 projects might prefer not having to worry about managing transitive dependencies
diff --git a/versions/8.2.1/community/images/Bitrise.png b/versions/8.2.1/community/images/Bitrise.png
new file mode 100644
index 00000000..07f85f1e
Binary files /dev/null and b/versions/8.2.1/community/images/Bitrise.png differ
diff --git a/versions/8.2.1/community/images/Gradle.png b/versions/8.2.1/community/images/Gradle.png
new file mode 100644
index 00000000..1e5f5eb0
Binary files /dev/null and b/versions/8.2.1/community/images/Gradle.png differ
diff --git a/versions/8.2.1/community/images/Linkedin-Logo.png b/versions/8.2.1/community/images/Linkedin-Logo.png
new file mode 100644
index 00000000..9dd8715c
Binary files /dev/null and b/versions/8.2.1/community/images/Linkedin-Logo.png differ
diff --git a/versions/8.2.1/community/images/Lucid_Software-logo.svg b/versions/8.2.1/community/images/Lucid_Software-logo.svg
new file mode 100644
index 00000000..6c8591e0
--- /dev/null
+++ b/versions/8.2.1/community/images/Lucid_Software-logo.svg
@@ -0,0 +1,16 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/versions/8.2.1/community/images/acqio_logo.svg b/versions/8.2.1/community/images/acqio_logo.svg
new file mode 100644
index 00000000..8fa11bcd
--- /dev/null
+++ b/versions/8.2.1/community/images/acqio_logo.svg
@@ -0,0 +1,60 @@
+
+
+
+
+
+	
+		
+			
+				
+					
+					
+					
+					
+					
+				
+				
+					
+						
+							
+								
+							
+						
+					
+				
+				
+					
+						
+							
+								
+							
+						
+					
+				
+			
+		
+	
+
+
diff --git a/versions/8.2.1/community/images/aspect-logo-2.png b/versions/8.2.1/community/images/aspect-logo-2.png
new file mode 100644
index 00000000..dfebc4cb
Binary files /dev/null and b/versions/8.2.1/community/images/aspect-logo-2.png differ
diff --git a/versions/8.2.1/community/images/bitrise-logo.png b/versions/8.2.1/community/images/bitrise-logo.png
new file mode 100644
index 00000000..27037ce6
Binary files /dev/null and b/versions/8.2.1/community/images/bitrise-logo.png differ
diff --git a/versions/8.2.1/community/images/buildbuddy-logo.svg b/versions/8.2.1/community/images/buildbuddy-logo.svg
new file mode 100644
index 00000000..bdb72dc6
--- /dev/null
+++ b/versions/8.2.1/community/images/buildbuddy-logo.svg
@@ -0,0 +1,11 @@
+
+
+
+
+
+
+
+
+
+
+
diff --git a/versions/8.2.1/community/images/buildkite.svg b/versions/8.2.1/community/images/buildkite.svg
new file mode 100644
index 00000000..209a4ab1
--- /dev/null
+++ b/versions/8.2.1/community/images/buildkite.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/8.2.1/community/images/codethink-logo.svg b/versions/8.2.1/community/images/codethink-logo.svg
new file mode 100644
index 00000000..406005d8
--- /dev/null
+++ b/versions/8.2.1/community/images/codethink-logo.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/8.2.1/community/images/develocity.png b/versions/8.2.1/community/images/develocity.png
new file mode 100644
index 00000000..eb3eb65a
Binary files /dev/null and b/versions/8.2.1/community/images/develocity.png differ
diff --git a/versions/8.2.1/community/images/dropbox.png b/versions/8.2.1/community/images/dropbox.png
new file mode 100644
index 00000000..125476a6
Binary files /dev/null and b/versions/8.2.1/community/images/dropbox.png differ
diff --git a/versions/8.2.1/community/images/engflow-logo.svg b/versions/8.2.1/community/images/engflow-logo.svg
new file mode 100644
index 00000000..e5f0c343
--- /dev/null
+++ b/versions/8.2.1/community/images/engflow-logo.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/8.2.1/community/images/epam-logo.png b/versions/8.2.1/community/images/epam-logo.png
new file mode 100644
index 00000000..e6a5674c
Binary files /dev/null and b/versions/8.2.1/community/images/epam-logo.png differ
diff --git a/versions/8.2.1/community/images/flare-logo.png b/versions/8.2.1/community/images/flare-logo.png
new file mode 100644
index 00000000..84cb0e5b
Binary files /dev/null and b/versions/8.2.1/community/images/flare-logo.png differ
diff --git a/versions/8.2.1/community/images/hermetiq-logo.png b/versions/8.2.1/community/images/hermetiq-logo.png
new file mode 100644
index 00000000..90765d96
Binary files /dev/null and b/versions/8.2.1/community/images/hermetiq-logo.png differ
diff --git a/versions/8.2.1/community/images/jetbrains.svg b/versions/8.2.1/community/images/jetbrains.svg
new file mode 100644
index 00000000..cb3a2a0e
--- /dev/null
+++ b/versions/8.2.1/community/images/jetbrains.svg
@@ -0,0 +1,13 @@
+
+  
+    
+      
+      
+      
+    
+  
+  
+  
+  
+  
+
diff --git a/versions/8.2.1/community/images/liulishuo.png b/versions/8.2.1/community/images/liulishuo.png
new file mode 100644
index 00000000..a6758e5c
Binary files /dev/null and b/versions/8.2.1/community/images/liulishuo.png differ
diff --git a/versions/8.2.1/community/images/nativelink.svg b/versions/8.2.1/community/images/nativelink.svg
new file mode 100644
index 00000000..148fcdce
--- /dev/null
+++ b/versions/8.2.1/community/images/nativelink.svg
@@ -0,0 +1,1123 @@
+
+
+  
+    
+    
+      
+      
+    
+    
+      
+      
+    
+    
+    
+      
+      
+    
+    
+      
+      
+      
+      
+      
+      
+      
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+      
+      
+    
+    
+    
+    
+      
+      
+    
+    
+    
+    
+      
+      
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+      
+      
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+      
+      
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+      
+      
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+      
+      
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+      
+      
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+      
+      
+    
+  
+  
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+  
+  
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+  
+
diff --git a/versions/8.2.1/community/images/oasis-logo.png b/versions/8.2.1/community/images/oasis-logo.png
new file mode 100644
index 00000000..846a9cd5
Binary files /dev/null and b/versions/8.2.1/community/images/oasis-logo.png differ
diff --git a/versions/8.2.1/community/images/sumglobal-logo.png b/versions/8.2.1/community/images/sumglobal-logo.png
new file mode 100644
index 00000000..6736328d
Binary files /dev/null and b/versions/8.2.1/community/images/sumglobal-logo.png differ
diff --git a/versions/8.2.1/community/images/trunk-logo-dark.svg b/versions/8.2.1/community/images/trunk-logo-dark.svg
new file mode 100644
index 00000000..f25940af
--- /dev/null
+++ b/versions/8.2.1/community/images/trunk-logo-dark.svg
@@ -0,0 +1,22 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/versions/8.2.1/community/images/tweag-logo.png b/versions/8.2.1/community/images/tweag-logo.png
new file mode 100644
index 00000000..20210ed7
Binary files /dev/null and b/versions/8.2.1/community/images/tweag-logo.png differ
diff --git a/versions/8.2.1/community/images/typedb.png b/versions/8.2.1/community/images/typedb.png
new file mode 100644
index 00000000..48ce1056
Binary files /dev/null and b/versions/8.2.1/community/images/typedb.png differ
diff --git a/versions/8.2.1/community/images/virtuslab.svg b/versions/8.2.1/community/images/virtuslab.svg
new file mode 100644
index 00000000..6fba0316
--- /dev/null
+++ b/versions/8.2.1/community/images/virtuslab.svg
@@ -0,0 +1,20 @@
+
+
+  
+    
+  
+  
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+  
+
diff --git a/versions/8.2.1/community/roadmaps-configurability.mdx b/versions/8.2.1/community/roadmaps-configurability.mdx
index c1f7eda2..272221eb 100644
--- a/versions/8.2.1/community/roadmaps-configurability.mdx
+++ b/versions/8.2.1/community/roadmaps-configurability.mdx
@@ -26,8 +26,7 @@ title: 'Bazel Configurability 2021 Roadmap'
 * Builds scale well, particularly w.r.t graph size and action caching.
 
 We also support
-[`cquery`](https://bazel.build/versions/8.2.1/query/cquery), [`Starlark
-configuration`](https://bazel.build/extending/config),
+[`cquery`](https://bazel.build/versions/8.2.1/query/cquery), [`Starlark configuration`](https://bazel.build/versions/8.2.1/extending/config),
 and
 [`select()`](https://bazel.build/versions/8.2.1/docs/configurable-attributes).
 
@@ -41,15 +40,13 @@ interest of accurate expectations.
 ### Platforms
 
 

-Q3 2021**Android rules use the new [platforms
-API](https://bazel.build/concepts/platforms)**
+Q3 2021**Android rules use the new [platforms API](https://bazel.build/versions/8.2.1/concepts/platforms)**
 IN PROGRESS ([#11749](https://github.com/bazelbuild/bazel/issues/11749))
 
 * This is our main priority for the beginning of 2021.
 
 

-Q3 2021**Builds support [multiple execution
-platforms](https://docs.google.com/document/d/1U9HzdDmtRnm244CaRM6JV-q2408mbNODAMewcGjnnbM/)**
+Q3 2021**Builds support [multiple execution platforms](https://docs.google.com/document/d/1U9HzdDmtRnm244CaRM6JV-q2408mbNODAMewcGjnnbM/)**
 IN PROGRESS ([#11748](https://github.com/bazelbuild/bazel/issues/11748))
 
 

diff --git a/versions/8.2.1/community/sig.mdx b/versions/8.2.1/community/sig.mdx
index 2cbf4dac..4224ff27 100644
--- a/versions/8.2.1/community/sig.mdx
+++ b/versions/8.2.1/community/sig.mdx
@@ -3,8 +3,7 @@ title: 'Bazel Special Interest Groups'
 ---
 
 Bazel hosts Special Interest Groups (SIGs) to focus collaboration on particular
-areas and to support communication and coordination between [Bazel owners,
-maintainers, and contributors](/versions/8.2.1/contribute/policy). This policy
+areas and to support communication and coordination between [Bazel owners, maintainers, and contributors](/versions/8.2.1/contribute/policy). This policy
 applies to [`bazelbuild`](http://github.com/bazelbuild).
 
 SIGs do their work in public. The ideal scope for a SIG covers a well-defined
diff --git a/versions/8.2.1/community/users.mdx b/versions/8.2.1/community/users.mdx
index 3333968e..561de990 100644
--- a/versions/8.2.1/community/users.mdx
+++ b/versions/8.2.1/community/users.mdx
@@ -304,11 +304,9 @@ safety systems_.
 Pigweed is an open-source solution for sustained, robust, and rapid embedded
 product development for large teams. Pigweed has shipped in millions of
 devices, including Google's suite of Pixel devices, Nest thermostats,
-[satellites](https://www.spinlaunch.com/), and [autonomous aerial
-drones](https://www.flyzipline.com/).
+[satellites](https://www.spinlaunch.com/), and [autonomous aerial drones](https://www.flyzipline.com/).
 
-Pigweed [uses Bazel as its primary build
-system](https://pigweed.dev/seed/0111-build-systems.html). The [Bazel for
+Pigweed [uses Bazel as its primary build system](https://pigweed.dev/seed/0111-build-systems.html). The [Bazel for
 Embedded][pw-bazel-great] blog post discusses why we think it's a great build
 system for embedded projects!
 
diff --git a/versions/8.2.1/concepts/build-ref.mdx b/versions/8.2.1/concepts/build-ref.mdx
index a6501030..6ba3b306 100644
--- a/versions/8.2.1/concepts/build-ref.mdx
+++ b/versions/8.2.1/concepts/build-ref.mdx
@@ -17,8 +17,7 @@ its root; such a boundary marker file could be `MODULE.bazel`, `REPO.bazel`, or
 in legacy contexts, `WORKSPACE` or `WORKSPACE.bazel`.
 
 The repo in which the current Bazel command is being run is called the _main
-repo_. Other, (external) repos are defined by _repo rules_; see [external
-dependencies overview](/versions/8.2.1/external/overview) for more information.
+repo_. Other, (external) repos are defined by _repo rules_; see [external dependencies overview](/versions/8.2.1/external/overview) for more information.
 
 ## Workspace {#workspace}
 
@@ -95,5 +94,4 @@ have three properties: the list of packages they contain, their name, and other
 package groups they include. The only allowed ways to refer to them are from the
 `visibility` attribute of rules or from the `default_visibility` attribute of
 the `package` function; they do not generate or consume files. For more
-information, refer to the [`package_group`
-documentation](/versions/8.2.1/reference/be/functions#package_group).
+information, refer to the [`package_group` documentation](/versions/8.2.1/reference/be/functions#package_group).
diff --git a/versions/8.2.1/concepts/labels.mdx b/versions/8.2.1/concepts/labels.mdx
index 37724f9b..14daada5 100644
--- a/versions/8.2.1/concepts/labels.mdx
+++ b/versions/8.2.1/concepts/labels.mdx
@@ -10,8 +10,7 @@ form looks like:
 ```
 
 The first part of the label is the repository name, `@@myrepo`. The double-`@`
-syntax signifies that this is a [*canonical* repo
-name](/versions/8.2.1/external/overview#canonical-repo-name), which is unique within
+syntax signifies that this is a [*canonical* repo name](/versions/8.2.1/external/overview#canonical-repo-name), which is unique within
 the workspace. Labels with canonical repo names unambiguously identify a target
 no matter which context they appear in.
 
diff --git a/versions/8.2.1/concepts/platforms.mdx b/versions/8.2.1/concepts/platforms.mdx
index a69fa60b..10dff937 100644
--- a/versions/8.2.1/concepts/platforms.mdx
+++ b/versions/8.2.1/concepts/platforms.mdx
@@ -77,8 +77,7 @@ To test your Android project with platforms, see
 for support.
 
 You can still use platform APIs with Apple builds (for example, when building
-with a mixture of Apple rules and pure C++) with [platform
-mappings](#platform-mappings).
+with a mixture of Apple rules and pure C++) with [platform mappings](#platform-mappings).
 
 ### Other languages {#other-languages}
 
@@ -241,8 +240,7 @@ sets `--cpu`, `--crossstool_top`, or other legacy flags, rules that read
 
 When migrating your project to platforms, you must either convert changes like
 `return { "//command_line_option:cpu": "arm" }` to `return {
-"//command_line_option:platforms": "//:my_arm_platform" }` or use [platform
-mappings](#platform-mappings) to support both styles during migration.
+"//command_line_option:platforms": "//:my_arm_platform" }` or use [platform mappings](#platform-mappings) to support both styles during migration.
 window.
 
 ## Migrating your rule set {#migrating-your-rule-set}
@@ -361,10 +359,8 @@ attributes declare a language's tools (like `compiler =
 this information to rules that need to build with these tools.
 
 Toolchains declare the `constraint_value`s of machines they can
-[target][target_compatible_with Attribute]
-(`target_compatible_with = ["@platforms//os:linux"]`) and machines their tools can
-[run on][exec_compatible_with Attribute]
-(`exec_compatible_with = ["@platforms//os:mac"]`).
+[target][target_compatible_with Attribute](`target_compatible_with = ["@platforms//os:linux"]`) and machines their tools can
+[run on][exec_compatible_with Attribute](`exec_compatible_with = ["@platforms//os:mac"]`).
 
 When building `$ bazel build //:myproject --platforms=//:myplatform`, Bazel
 automatically selects a toolchain that can run on the build machine and
diff --git a/versions/8.2.1/configure/attributes.mdx b/versions/8.2.1/configure/attributes.mdx
index a291aeb2..62c4cf91 100644
--- a/versions/8.2.1/configure/attributes.mdx
+++ b/versions/8.2.1/configure/attributes.mdx
@@ -2,8 +2,7 @@
 title: 'Configurable Build Attributes'
 ---
 
-**_Configurable attributes_**, commonly known as [`select()`](
-/reference/be/functions#select), is a Bazel feature that lets users toggle the values
+**_Configurable attributes_**, commonly known as [`select()`](/versions/8.2.1/reference/be/functions#select), is a Bazel feature that lets users toggle the values
 of build rule attributes at the command line.
 
 This can be used, for example, for a multiplatform library that automatically
@@ -407,8 +406,7 @@ sh_library(
 )
 ```
 
-If you need a `select` to match when multiple conditions match, consider [AND
-chaining](#and-chaining).
+If you need a `select` to match when multiple conditions match, consider [AND chaining](#and-chaining).
 
 ## OR chaining {#or-chaining}
 
diff --git a/versions/8.2.1/configure/integrate-cpp.mdx b/versions/8.2.1/configure/integrate-cpp.mdx
index f2ece735..f71d7d24 100644
--- a/versions/8.2.1/configure/integrate-cpp.mdx
+++ b/versions/8.2.1/configure/integrate-cpp.mdx
@@ -33,8 +33,7 @@ This is because when writing our own actions, they must behave
 consistently with the C++ toolchain - for example, passing C++ command line
 flags to a tool that invokes the C++ compiler behind the scenes.
 
-C++ rules use a special way of constructing command lines based on [feature
-configuration](/versions/8.2.1/docs/cc-toolchain-config-reference). To construct a command line,
+C++ rules use a special way of constructing command lines based on [feature configuration](/versions/8.2.1/docs/cc-toolchain-config-reference). To construct a command line,
 you need the following:
 
 * `features` and `action_configs` - these come from the `CcToolchainConfigInfo`
diff --git a/versions/8.2.1/configure/windows.mdx b/versions/8.2.1/configure/windows.mdx
index c3261084..0557ba1f 100644
--- a/versions/8.2.1/configure/windows.mdx
+++ b/versions/8.2.1/configure/windows.mdx
@@ -166,8 +166,7 @@ To build C++ targets with MSVC, you need:
         set BAZEL_VC=C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC
         ```
 
-*   The [Windows
-    SDK](https://developer.microsoft.com/en-us/windows/downloads/windows-10-sdk).
+*   The [Windows SDK](https://developer.microsoft.com/en-us/windows/downloads/windows-10-sdk).
 
     The Windows SDK contains header files and libraries you need when building
     Windows applications, including Bazel itself. By default, the latest Windows SDK installed will
@@ -186,8 +185,7 @@ To build C++ targets with MSVC, you need:
 
 If everything is set up, you can build a C++ target now!
 
-Try building a target from one of our [sample
-projects](https://github.com/bazelbuild/bazel/tree/master/examples):
+Try building a target from one of our [sample projects](https://github.com/bazelbuild/bazel/tree/master/examples):
 
 ```posix-terminal
 C:\projects\bazel> bazel build //examples/cpp:hello-world
@@ -209,8 +207,7 @@ For example, to build targets for ARM architecture, run:
 C:\projects\bazel> bazel build //examples/cpp:hello-world --cpu=x64_arm_windows
 ```
 
-To build and use Dynamically Linked Libraries (DLL files), see [this
-example](https://github.com/bazelbuild/bazel/tree/master/examples/windows/dll).
+To build and use Dynamically Linked Libraries (DLL files), see [this example](https://github.com/bazelbuild/bazel/tree/master/examples/windows/dll).
 
 **Command Line Length Limit**: To prevent the
 [Windows command line length limit issue](https://github.com/bazelbuild/bazel/issues/5163),
@@ -289,8 +286,7 @@ On Windows, Bazel builds two output files for `java_binary` rules:
 *   a `.jar` file
 *   a `.exe` file that can set up the environment for the JVM and run the binary
 
-Try building a target from one of our [sample
-projects](https://github.com/bazelbuild/bazel/tree/master/examples):
+Try building a target from one of our [sample projects](https://github.com/bazelbuild/bazel/tree/master/examples):
 
 ```posix-terminal
 C:\projects\bazel> bazel build //examples/java-native/src/main/java/com/example/myproject:hello-world
@@ -312,8 +308,7 @@ On Windows, Bazel builds two output files for `py_binary` rules:
 You can either run the executable file (it has a `.exe` extension) or you can run
 Python with the self-extracting zip file as the argument.
 
-Try building a target from one of our [sample
-projects](https://github.com/bazelbuild/bazel/tree/master/examples):
+Try building a target from one of our [sample projects](https://github.com/bazelbuild/bazel/tree/master/examples):
 
 ```posix-terminal
 C:\projects\bazel> bazel build //examples/py_native:bin
@@ -322,5 +317,4 @@ C:\projects\bazel> python bazel-bin\examples\py_native\bin.zip
 ```
 
 If you are interested in details about how Bazel builds Python targets on
-Windows, check out this [design
-doc](https://github.com/bazelbuild/bazel-website/blob/master/designs/_posts/2016-09-05-build-python-on-windows.md).
+Windows, check out this [design doc](https://github.com/bazelbuild/bazel-website/blob/master/designs/_posts/2016-09-05-build-python-on-windows.md).
diff --git a/versions/8.2.1/contribute/breaking-changes.mdx b/versions/8.2.1/contribute/breaking-changes.mdx
index 7244bbc6..607255b6 100644
--- a/versions/8.2.1/contribute/breaking-changes.mdx
+++ b/versions/8.2.1/contribute/breaking-changes.mdx
@@ -67,7 +67,7 @@ should contain the URL of the GitHub issue. As the flag name starts with
 ```
 
 In the commit description, add a brief summary of the flag.
-Also add [`RELNOTES:`](release-notes.md) in the following form:
+Also add [`RELNOTES:`](/versions/8.2.1/contribute/release-notes) in the following form:
 `RELNOTES: --incompatible_name_of_flag has been added. See #xyz for details`
 
 The commit should also update the relevant documentation, so that there is no
diff --git a/versions/8.2.1/contribute/codebase.mdx b/versions/8.2.1/contribute/codebase.mdx
index 3138dcf7..7a4770f1 100644
--- a/versions/8.2.1/contribute/codebase.mdx
+++ b/versions/8.2.1/contribute/codebase.mdx
@@ -227,8 +227,7 @@ repository", the others are called "external repositories".
 A repository is marked by a repo boundary file (`MODULE.bazel`, `REPO.bazel`, or
 in legacy contexts, `WORKSPACE` or `WORKSPACE.bazel`) in its root directory. The
 main repo is the source tree where you're invoking Bazel from. External repos
-are defined in various ways; see [external dependencies
-overview](/versions/8.2.1/external/overview) for more information.
+are defined in various ways; see [external dependencies overview](/versions/8.2.1/external/overview) for more information.
 
 Code of external repositories is symlinked or downloaded under
 `$OUTPUT_BASE/external`.
diff --git a/versions/8.2.1/contribute/design-documents.mdx b/versions/8.2.1/contribute/design-documents.mdx
index 994983f5..44461142 100644
--- a/versions/8.2.1/contribute/design-documents.mdx
+++ b/versions/8.2.1/contribute/design-documents.mdx
@@ -25,7 +25,7 @@ Here are some examples of significant changes:
 When you write a design document, you can coordinate with other Bazel developers
 and seek guidance from Bazel's core team. For example, when a proposal adds,
 removes, or modifies any function or object available in BUILD, MODULE.bazel, or
-bzl files, add the [Starlark team](maintainers-guide.md) as reviewers.
+bzl files, add the [Starlark team](/versions/8.2.1/contribute/maintainers-guide) as reviewers.
 Design documents are reviewed before submission because:
 
 *   Bazel is a very complex system; seemingly innocuous local changes can have
@@ -137,8 +137,7 @@ A lead reviewer should be a domain expert who is:
 *   Objective and capable of providing constructive feedback
 *   Available for the entire review period to lead the process
 
-Consider checking the contacts for various [team
-labels](/versions/8.2.1/contribute/maintainers-guide#team-labels).
+Consider checking the contacts for various [team labels](/versions/8.2.1/contribute/maintainers-guide#team-labels).
 
 ## Markdown vs Google Docs {#markdown-versus-gdocs}
 
@@ -168,12 +167,10 @@ Markdown for posterity.
 
 ### Using Google Docs {#gdocs}
 
-For consistency, use the [Bazel design doc template](
-https://docs.google.com/document/d/1cE5zrjrR40RXNg64XtRFewSv6FrLV6slGkkqxBumS1w/edit).
+For consistency, use the [Bazel design doc template](https://docs.google.com/document/d/1cE5zrjrR40RXNg64XtRFewSv6FrLV6slGkkqxBumS1w/edit).
 It includes the necessary header and creates visual
 consistency with other Bazel related documents. To do that, click on **File** >
-**Make a copy** or click this link to [make a copy of the design doc
-template](https://docs.google.com/document/d/1cE5zrjrR40RXNg64XtRFewSv6FrLV6slGkkqxBumS1w/copy).
+**Make a copy** or click this link to [make a copy of the design doc template](https://docs.google.com/document/d/1cE5zrjrR40RXNg64XtRFewSv6FrLV6slGkkqxBumS1w/copy).
 
 To make your document readable to the world, click on
 **Share** > **Advanced** > **Change…**, and
diff --git a/versions/8.2.1/contribute/images/structured-concurrency-3d.svg b/versions/8.2.1/contribute/images/structured-concurrency-3d.svg
new file mode 100644
index 00000000..accbb42a
--- /dev/null
+++ b/versions/8.2.1/contribute/images/structured-concurrency-3d.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/8.2.1/contribute/images/structured-concurrency.svg b/versions/8.2.1/contribute/images/structured-concurrency.svg
new file mode 100644
index 00000000..0258d9a9
--- /dev/null
+++ b/versions/8.2.1/contribute/images/structured-concurrency.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/8.2.1/contribute/images/suspend-resume.svg b/versions/8.2.1/contribute/images/suspend-resume.svg
new file mode 100644
index 00000000..7de1218f
--- /dev/null
+++ b/versions/8.2.1/contribute/images/suspend-resume.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/8.2.1/contribute/images/unstructured-concurrency.svg b/versions/8.2.1/contribute/images/unstructured-concurrency.svg
new file mode 100644
index 00000000..0951639a
--- /dev/null
+++ b/versions/8.2.1/contribute/images/unstructured-concurrency.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/8.2.1/contribute/index.mdx b/versions/8.2.1/contribute/index.mdx
index f1b70520..e1f8ca6f 100644
--- a/versions/8.2.1/contribute/index.mdx
+++ b/versions/8.2.1/contribute/index.mdx
@@ -10,8 +10,7 @@ As you use Bazel, you may find things that can be improved.
 You can help by [reporting issues](http://github.com/bazelbuild/bazel/issues)
 when:
 
-   - Bazel crashes or you encounter a bug that can [only be resolved using `bazel
-     clean`](/versions/8.2.1/run/build#correct-incremental-rebuilds).
+   - Bazel crashes or you encounter a bug that can [only be resolved using `bazel clean`](/versions/8.2.1/run/build#correct-incremental-rebuilds).
    - The documentation is incomplete or unclear. You can also report issues
      from the page you are viewing by using the "Create issue"
      link at the top right corner of the page.
@@ -21,11 +20,9 @@ when:
 
 You can engage with the Bazel community by:
 
-   - Answering questions [on Stack Overflow](
-     https://stackoverflow.com/questions/tagged/bazel).
+   - Answering questions [on Stack Overflow](https://stackoverflow.com/questions/tagged/bazel).
    - Helping other users [on Slack](https://slack.bazel.build).
-   - Improving documentation or [contributing examples](
-     https://github.com/bazelbuild/examples).
+   - Improving documentation or [contributing examples](https://github.com/bazelbuild/examples).
    - Sharing your experience or your tips, for example, on a blog or social media.
 
 ## Contribute code {#contribute-code}
@@ -40,8 +37,7 @@ You can contribute to the Bazel ecosystem by:
    - Contributing to Bazel-related tools, for example, migration tools.
    - Improving Bazel integration with other IDEs and tools.
 
-Before making a change, [create a GitHub
-issue](http://github.com/bazelbuild/bazel/issues)
+Before making a change, [create a GitHub issue](http://github.com/bazelbuild/bazel/issues)
 or email [bazel-discuss@](mailto:bazel-discuss@googlegroups.com).
 
 The most helpful contributions fix bugs or add features (as opposed
diff --git a/versions/8.2.1/contribute/maintainers-guide.mdx b/versions/8.2.1/contribute/maintainers-guide.mdx
index 73598706..fd5d5a29 100644
--- a/versions/8.2.1/contribute/maintainers-guide.mdx
+++ b/versions/8.2.1/contribute/maintainers-guide.mdx
@@ -4,8 +4,7 @@ title: 'Guide for Bazel Maintainers'
 
 This is a guide for the maintainers of the Bazel open source project.
 
-If you are looking to contribute to Bazel, please read [Contributing to
-Bazel](/versions/8.2.1/contribute) instead.
+If you are looking to contribute to Bazel, please read [Contributing to Bazel](/versions/8.2.1/contribute) instead.
 
 The objectives of this page are to:
 
@@ -37,8 +36,7 @@ repository.
 
 1. A user creates an issue by choosing one of the
 [issue templates](https://github.com/bazelbuild/bazel/issues/new/choose)
-   and it enters the pool of [unreviewed open
-   issues](https://github.com/bazelbuild/bazel/issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aopen+-label%3Auntriaged+-label%3Ap2+-label%3Ap1+-label%3Ap3+-label%3Ap4+-label%3Ateam-Starlark+-label%3Ateam-Rules-CPP+-label%3Ateam-Rules-Java+-label%3Ateam-XProduct+-label%3Ateam-Android+-label%3Ateam-Apple+-label%3Ateam-Configurability++-label%3Ateam-Performance+-label%3Ateam-Rules-Server+-label%3Ateam-Core+-label%3Ateam-Rules-Python+-label%3Ateam-Remote-Exec+-label%3Ateam-Local-Exec+-label%3Ateam-Bazel).
+   and it enters the pool of [unreviewed open issues](https://github.com/bazelbuild/bazel/issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aopen+-label%3Auntriaged+-label%3Ap2+-label%3Ap1+-label%3Ap3+-label%3Ap4+-label%3Ateam-Starlark+-label%3Ateam-Rules-CPP+-label%3Ateam-Rules-Java+-label%3Ateam-XProduct+-label%3Ateam-Android+-label%3Ateam-Apple+-label%3Ateam-Configurability++-label%3Ateam-Performance+-label%3Ateam-Rules-Server+-label%3Ateam-Core+-label%3Ateam-Rules-Python+-label%3Ateam-Remote-Exec+-label%3Ateam-Local-Exec+-label%3Ateam-Bazel).
 1. A member on the Developer Experience (DevEx) subteam rotation reviews the
    issue.
    1. If the issue is **not a bug** or a **feature request**, the DevEx member
@@ -58,21 +56,18 @@ repository.
 1. After reviewing the issue, the DevEx member decides if the issue requires
    immediate attention. If it does, they will assign the **P0**
    [priority](#priority) label and an owner from the list of team leads.
-1. The DevEx member assigns the `untriaged` label and exactly one [team
-   label](#team-labels) for routing.
+1. The DevEx member assigns the `untriaged` label and exactly one [team label](#team-labels) for routing.
 1. The DevEx member also assigns exactly one `type:` label, such as `type: bug`
    or `type: feature request`, according to the type of the issue.
 1. For platform-specific issues, the DevEx member assigns one `platform:` label,
    such as `platform:apple` for Mac-specific issues.
 1. If the issue is low priority and can be worked on by a new community
    contributor, the DevEx member assigns the `good first issue` label.
-At this stage, the issue enters the pool of [untriaged open
-issues](https://github.com/bazelbuild/bazel/issues?q=is%3Aissue+is%3Aopen+label%3Auntriaged).
+At this stage, the issue enters the pool of [untriaged open issues](https://github.com/bazelbuild/bazel/issues?q=is%3Aissue+is%3Aopen+label%3Auntriaged).
 
 Each Bazel subteam will triage all issues under labels they own, preferably on a
 weekly basis. The subteam will review and evaluate the issue and provide a
-resolution, if possible. If you are an owner of a team label, see [this section
-](#label-own) for more information.
+resolution, if possible. If you are an owner of a team label, see [this section](#label-own) for more information.
 
 When an issue is resolved, it can be closed.
 
@@ -111,8 +106,7 @@ preferably on a weekly basis.
      issue is either P0 or P1 we assume that is actively worked on.
 1. Remove the `untriaged` label.
 
-Note that you need to be in the [bazelbuild
-organization](https://github.com/bazelbuild) to be able to add or remove labels.
+Note that you need to be in the [bazelbuild organization](https://github.com/bazelbuild) to be able to add or remove labels.
 
 ### Pull Requests {#pull-requests}
 
@@ -138,8 +132,7 @@ issues.
   unusable, or a downed service that severely impacts development of the Bazel
   project. This includes regressions introduced in a new release that blocks a
   significant number of users, or an incompatible breaking change that was not
-  compliant to the [Breaking
-  Change](https://docs.google.com/document/d/1q5GGRxKrF_mnwtaPKI487P8OdDRh2nN7jX6U-FXnHL0/edit?pli=1#heading=h.ceof6vpkb3ik)
+  compliant to the [Breaking Change](https://docs.google.com/document/d/1q5GGRxKrF_mnwtaPKI487P8OdDRh2nN7jX6U-FXnHL0/edit?pli=1#heading=h.ceof6vpkb3ik)
   policy. No practical workaround exists.
 * [**P1**](https://github.com/bazelbuild/bazel/labels/P1) - Critical defect or
   feature which should be addressed in the next release, or a serious issue that
diff --git a/versions/8.2.1/contribute/naming.mdx b/versions/8.2.1/contribute/naming.mdx
index c8cf6f37..318895d8 100644
--- a/versions/8.2.1/contribute/naming.mdx
+++ b/versions/8.2.1/contribute/naming.mdx
@@ -4,8 +4,7 @@ title: 'Naming a Bazel related project'
 
 First, thank you for contributing to the Bazel ecosystem! Please reach out to
 the Bazel community on the
-[bazel-discuss mailing list](https://groups.google.com/forum/#!forum/bazel-discuss
-) to share your project and its suggested name.
+[bazel-discuss mailing list](https://groups.google.com/forum/#!forum/bazel-discuss) to share your project and its suggested name.
 
 If you are building a Bazel related tool or sharing your Skylark rules,
 we recommend following these guidelines for the name of your project:
diff --git a/versions/8.2.1/contribute/patch-acceptance.mdx b/versions/8.2.1/contribute/patch-acceptance.mdx
index 8e23f591..66e842ca 100644
--- a/versions/8.2.1/contribute/patch-acceptance.mdx
+++ b/versions/8.2.1/contribute/patch-acceptance.mdx
@@ -11,29 +11,24 @@ code base.
    need a corresponding issue for tracking.
 1. If you're proposing significant changes, write a
    [design document](/versions/8.2.1/contribute/design-documents).
-1. Ensure you've signed a [Contributor License
-   Agreement](https://cla.developers.google.com).
+1. Ensure you've signed a [Contributor License Agreement](https://cla.developers.google.com).
 1. Prepare a git commit that implements the feature. Don't forget to add tests
    and update the documentation. If your change has user-visible effects, please
    [add release notes](/versions/8.2.1/contribute/release-notes). If it is an incompatible change,
    read the [guide for rolling out breaking changes](/versions/8.2.1/contribute/breaking-changes).
 1. Create a pull request on
    [GitHub](https://github.com/bazelbuild/bazel/pulls). If you're new to GitHub,
-   read [about pull
-   requests](https://help.github.com/articles/about-pull-requests/). Note that
+   read [about pull requests](https://help.github.com/articles/about-pull-requests/). Note that
    we restrict permissions to create branches on the main Bazel repository, so
-   you will need to push your commit to [your own fork of the
-   repository](https://help.github.com/articles/working-with-forks/).
+   you will need to push your commit to [your own fork of the repository](https://help.github.com/articles/working-with-forks/).
 1. A Bazel maintainer should assign you a reviewer within two business days
    (excluding holidays in the USA and Germany). If you aren't assigned a
    reviewer in that time, you can request one by emailing
-   [bazel-discuss@googlegroups.com]
-   (mailto:bazel-discuss@googlegroups.com).
+   [bazel-discuss@googlegroups.com](mailto:bazel-discuss@googlegroups.com).
 1. Work with the reviewer to complete a code review. For each change, create a
    new commit and push it to make changes to your pull request. If the review
    takes too long (for instance, if the reviewer is unresponsive), send an email to
-   [bazel-discuss@googlegroups.com]
-   (mailto:bazel-discuss@googlegroups.com).
+   [bazel-discuss@googlegroups.com](mailto:bazel-discuss@googlegroups.com).
 1. After your review is complete, a Bazel maintainer applies your patch to
    Google's internal version control system.
 
diff --git a/versions/8.2.1/contribute/release-notes.mdx b/versions/8.2.1/contribute/release-notes.mdx
index 8113a865..0ff55367 100644
--- a/versions/8.2.1/contribute/release-notes.mdx
+++ b/versions/8.2.1/contribute/release-notes.mdx
@@ -16,8 +16,7 @@ the release announcement.
 * If the change adds / removes / changes Bazel in a user-visible way, then it
   may be advantageous to mention it.
 
-If the change is significant, follow the [design document
-policy](/versions/8.2.1/contribute/design-documents) first.
+If the change is significant, follow the [design document policy](/versions/8.2.1/contribute/design-documents) first.
 
 ## Guidelines {#guidelines}
 
@@ -60,10 +59,8 @@ change is about.
 
 ## Process {#process}
 
-As part of the [release
-process](https://github.com/bazelbuild/continuous-integration/blob/master/docs/release-playbook.md),
-we collect the `RELNOTES` tags of every commit. We copy everything in a [Google
-Doc](https://docs.google.com/document/d/1wDvulLlj4NAlPZamdlEVFORks3YXJonCjyuQMUQEmB0/edit)
+As part of the [release process](https://github.com/bazelbuild/continuous-integration/blob/master/docs/release-playbook.md),
+we collect the `RELNOTES` tags of every commit. We copy everything in a [Google Doc](https://docs.google.com/document/d/1wDvulLlj4NAlPZamdlEVFORks3YXJonCjyuQMUQEmB0/edit)
 where we review, edit, and organize the notes.
 
 The release manager sends an email to the
@@ -71,6 +68,4 @@ The release manager sends an email to the
 Bazel contributors are invited to contribute to the document and make sure
 their changes are correctly reflected in the announcement.
 
-Later, the announcement will be submitted to the [Bazel
-blog](https://blog.bazel.build/), using the [bazel-blog
-repository](https://github.com/bazelbuild/bazel-blog/tree/master/_posts).
+Later, the announcement will be submitted to the [Bazel blog](https://blog.bazel.build/), using the [bazel-blog repository](https://github.com/bazelbuild/bazel-blog/tree/master/_posts).
diff --git a/versions/8.2.1/contribute/statemachine-guide.mdx b/versions/8.2.1/contribute/statemachine-guide.mdx
index 4c952499..65670a14 100644
--- a/versions/8.2.1/contribute/statemachine-guide.mdx
+++ b/versions/8.2.1/contribute/statemachine-guide.mdx
@@ -172,8 +172,7 @@ instead, batches[^4] as many lookups as possible before doing so. The value
 might not be immediately available, for example, requiring a Skyframe restart,
 so the caller specifies what to do with the resulting value using a callback.
 
-The `StateMachine` processor ([`Driver`s and bridging to
-SkyFrame](#drivers-and-bridging)) guarantees that the value is available before
+The `StateMachine` processor ([`Driver`s and bridging to SkyFrame](#drivers-and-bridging)) guarantees that the value is available before
 the next state begins. An example follows.
 
 ```
@@ -284,8 +283,7 @@ and solutions to certain control flow problems.
 ### Sequential states
 
 This is the most common and straightforward control flow pattern. An example of
-this is shown in [Stateful computations inside
-`SkyKeyComputeState`](#stateful-computations).
+this is shown in [Stateful computations inside `SkyKeyComputeState`](#stateful-computations).
 
 ### Branching
 
@@ -545,8 +543,7 @@ section describes the propagation of data values.
 
 ### Implementing `Tasks.lookUp` callbacks
 
-There’s an example of implementing a `Tasks.lookUp` callback in [SkyValue
-lookups](#skyvalue-lookups). This section provides rationale and suggests
+There’s an example of implementing a `Tasks.lookUp` callback in [SkyValue lookups](#skyvalue-lookups). This section provides rationale and suggests
 approaches for handling multiple SkyValues.
 
 #### `Tasks.lookUp` callbacks {#tasks-lookup-callbacks}
@@ -710,8 +707,7 @@ class BarProducer implements StateMachine {
 Tip: It would be tempting to use the more concise signature void `accept(Bar
 value)` rather than the stuttery `void acceptBarValue(Bar value)` above.
 However, `Consumer` is a common overload of `void accept(Bar value)`,
-so doing this often leads to violations of the [Overloads: never
-split](https://google.github.io/styleguide/javaguide.html#s3.4.2-ordering-class-contents)
+so doing this often leads to violations of the [Overloads: never split](https://google.github.io/styleguide/javaguide.html#s3.4.2-ordering-class-contents)
 style-guide rule.
 
 Tip: Using a custom `ResultSink` type instead of a generic one from
@@ -774,14 +770,11 @@ pattern after accepting output from either a subtask or SkyValue lookup.
 Note that the implementation of `acceptBarError` eagerly forwards the result to
 the `Caller.ResultSink`, as required by [Error bubbling](#error-bubbling).
 
-Alternatives for top-level `StateMachine`s are described in [`Driver`s and
-bridging to SkyFunctions](#drivers-and-bridging).
+Alternatives for top-level `StateMachine`s are described in [`Driver`s and bridging to SkyFunctions](#drivers-and-bridging).
 
 ### Error handling {#error-handling}
 
-There's a couple of examples of error handling already in [`Tasks.lookUp`
-callbacks](#tasks-lookup-callbacks) and [Propagating values between
-`StateMachines`](#propagating-values). Exceptions, other than
+There's a couple of examples of error handling already in [`Tasks.lookUp` callbacks](#tasks-lookup-callbacks) and [Propagating values between `StateMachines`](#propagating-values). Exceptions, other than
 `InterruptedException` are not thrown, but instead passed around through
 callbacks as values. Such callbacks often have exclusive-or semantics, with
 exactly one of a value or error being passed.
@@ -1184,8 +1177,7 @@ states. Where it is possible, local stack `step` variables are young generation
 variables and efficiently GC'd.
 
 For `StateMachine` variables, breaking things down into subtasks and following
-the recommended pattern for [Propagating values between
-`StateMachine`s](#propagating-values) is also helpful. Observe that when
+the recommended pattern for [Propagating values between `StateMachine`s](#propagating-values) is also helpful. Observe that when
 following the pattern, only child `StateMachine`s have references to parent
 `StateMachine`s and not vice versa. This means that as children complete and
 update the parents using result callbacks, the children naturally fall out of
@@ -1207,8 +1199,7 @@ potentially reflecting local behavior.
 
 ### Concurrency tree diagram {#concurrency-tree-diagram}
 
-The following is an alternative view of the diagram in [Structured
-concurrency](#structured-concurrency) that better depicts the tree structure.
+The following is an alternative view of the diagram in [Structured concurrency](#structured-concurrency) that better depicts the tree structure.
 The blocks form a small tree.
 
 ![Structured Concurrency 3D](/versions/8.2.1/contribute/images/structured-concurrency-3d.svg)
diff --git a/versions/8.2.1/docs/android-instrumentation-test.mdx b/versions/8.2.1/docs/android-instrumentation-test.mdx
index 4d68e04e..68d3f7ea 100644
--- a/versions/8.2.1/docs/android-instrumentation-test.mdx
+++ b/versions/8.2.1/docs/android-instrumentation-test.mdx
@@ -2,8 +2,7 @@
 title: 'Android Instrumentation Tests'
 ---
 
-_If you're new to Bazel, start with the [Building Android with
-Bazel](/versions/8.2.1/start/android-app ) tutorial._
+_If you're new to Bazel, start with the [Building Android with Bazel](/versions/8.2.1/start/android-app) tutorial._
 
 ![Running Android instrumentation tests in parallel](/versions/8.2.1/docs/images/android_test.gif "Android instrumentation test")
 
@@ -18,9 +17,7 @@ emulators in a sandbox, ensuring that tests always run from a clean state. Each
 test gets an isolated emulator instance, allowing tests to run in parallel
 without passing states between them.
 
-For more information on Android instrumentation tests, check out the [Android
-developer
-documentation](https://developer.android.com/training/testing/unit-testing/instrumented-unit-tests.html).
+For more information on Android instrumentation tests, check out the [Android developer documentation](https://developer.android.com/training/testing/unit-testing/instrumented-unit-tests.html).
 
 Please file issues in the [GitHub issue tracker](https://github.com/bazelbuild/bazel/issues).
 
@@ -58,8 +55,7 @@ This results in output similar to the following:
 release 4.1.0
 ```
 
-- **KVM**. Bazel requires emulators to have [hardware
-  acceleration](https://developer.android.com/studio/run/emulator-acceleration.html#accel-check)
+- **KVM**. Bazel requires emulators to have [hardware acceleration](https://developer.android.com/studio/run/emulator-acceleration.html#accel-check)
   with KVM on Linux. You can follow these
   [installation instructions](https://help.ubuntu.com/community/KVM/Installation)
   for Ubuntu.
@@ -173,11 +169,9 @@ The main attributes of the rule `android_instrumentation_test` are:
 
 - `target_device`: An `android_device` target. This target describes the
   specifications of the Android emulator which Bazel uses to create, launch and
-  run the tests. See the [section on choosing an Android
-  device](#android-device-target) for more information.
+  run the tests. See the [section on choosing an Android device](#android-device-target) for more information.
 
-The test app's `AndroidManifest.xml` must include [an ``
-tag](https://developer.android.com/studio/test/#configure_instrumentation_manifest_settings).
+The test app's `AndroidManifest.xml` must include [an `` tag](https://developer.android.com/studio/test/#configure_instrumentation_manifest_settings).
 This tag must specify the attributes for the **package of the target app** and
 the **fully qualified class name of the instrumentation test runner**,
 `androidx.test.runner.AndroidJUnitRunner`.
@@ -214,8 +208,7 @@ repositories:
 - `@androidsdk`: The Android SDK. Download this through Android Studio.
 
 - `@android_test_support`: Hosts the test runner, emulator launcher, and
-  `android_device` targets. You can find the [latest release
-  here](https://github.com/android/android-test/releases).
+  `android_device` targets. You can find the [latest release here](https://github.com/android/android-test/releases).
 
 Enable these dependencies by adding the following lines to your `WORKSPACE`
 file:
@@ -240,8 +233,7 @@ android_test_repositories()
 
 ## Maven dependencies {#maven-dependencies}
 
-For managing dependencies on Maven artifacts from repositories, such as [Google
-Maven](https://maven.google.com) or [Maven Central](https://central.maven.org),
+For managing dependencies on Maven artifacts from repositories, such as [Google Maven](https://maven.google.com) or [Maven Central](https://central.maven.org),
 you should use a Maven resolver, such as
 [`rules_jvm_external`](https://github.com/bazelbuild/rules_jvm_external).
 
@@ -370,8 +362,7 @@ the device/emulator listed in `adb devices`.
 
 ## Sample projects {#sample-projects}
 
-If you are looking for canonical project samples, see the [Android testing
-samples](https://github.com/googlesamples/android-testing#experimental-bazel-support)
+If you are looking for canonical project samples, see the [Android testing samples](https://github.com/googlesamples/android-testing#experimental-bazel-support)
 for projects using Espresso and UIAutomator.
 
 ## Espresso setup {#espresso-setup}
@@ -560,8 +551,7 @@ API_LEVELS = [
 
 ## Known issues {#known-issues}
 
-- [Forked adb server processes are not terminated after
-  tests](https://github.com/bazelbuild/bazel/issues/4853)
+- [Forked adb server processes are not terminated after tests](https://github.com/bazelbuild/bazel/issues/4853)
 - While APK building works on all platforms (Linux, macOS, Windows), testing
   only works on Linux.
 - Even with `--config=local_adb`, users still need to specify
diff --git a/versions/8.2.1/docs/android-ndk.mdx b/versions/8.2.1/docs/android-ndk.mdx
index f9c423a5..b71cc6a1 100644
--- a/versions/8.2.1/docs/android-ndk.mdx
+++ b/versions/8.2.1/docs/android-ndk.mdx
@@ -2,8 +2,7 @@
 title: 'Using the Android Native Development Kit with Bazel'
 ---
 
-_If you're new to Bazel, please start with the [Building Android with
-Bazel](/versions/8.2.1/start/android-app ) tutorial._
+_If you're new to Bazel, please start with the [Building Android with Bazel](/versions/8.2.1/start/android-app) tutorial._
 
 ## Overview {#overview}
 
@@ -31,8 +30,7 @@ android_ndk_repository(
 )
 ```
 
-For more information about the `android_ndk_repository` rule, see the [Build
-Encyclopedia entry](/versions/8.2.1/reference/be/android#android_ndk_repository).
+For more information about the `android_ndk_repository` rule, see the [Build Encyclopedia entry](/versions/8.2.1/reference/be/android#android_ndk_repository).
 
 If you're using a recent version of the Android NDK (r22 and beyond), use the
 Starlark implementation of `android_ndk_repository`.
@@ -101,13 +99,11 @@ META-INF/MANIFEST.MF
 
 Bazel compiles all of the cc_libraries into a single shared object (`.so`) file,
 targeted for the `armeabi-v7a` ABI by default. To change this or build for
-multiple ABIs at the same time, see the section on [configuring the target
-ABI](#configuring-target-abi).
+multiple ABIs at the same time, see the section on [configuring the target ABI](#configuring-target-abi).
 
 ## Example setup {#example-setup}
 
-This example is available in the [Bazel examples
-repository](https://github.com/bazelbuild/examples/tree/master/android/ndk).
+This example is available in the [Bazel examples repository](https://github.com/bazelbuild/examples/tree/master/android/ndk).
 
 In the `BUILD.bazel` file, three targets are defined with the `android_binary`,
 `android_library`, and `cc_library` rules.
diff --git a/versions/8.2.1/docs/bazel-and-android.mdx b/versions/8.2.1/docs/bazel-and-android.mdx
index e7f0cd8c..fb85837e 100644
--- a/versions/8.2.1/docs/bazel-and-android.mdx
+++ b/versions/8.2.1/docs/bazel-and-android.mdx
@@ -10,7 +10,7 @@ Android projects with Bazel.
 
 The following resources will help you work with Bazel on Android projects:
 
-*  [Tutorial: Building an Android app](/versions/8.2.1/start/android-app ). This
+*  [Tutorial: Building an Android app](/versions/8.2.1/start/android-app). This
    tutorial is a good place to start learning about Bazel commands and concepts,
    and how to build Android apps with Bazel.
 *  [Codelab: Building Android Apps with Bazel](https://developer.android.com/codelabs/bazel-android-intro#0).
diff --git a/versions/8.2.1/docs/configurable-attributes.mdx b/versions/8.2.1/docs/configurable-attributes.mdx
index 29953abb..9db8b8ee 100644
--- a/versions/8.2.1/docs/configurable-attributes.mdx
+++ b/versions/8.2.1/docs/configurable-attributes.mdx
@@ -2,8 +2,7 @@
 title: 'Configurable Build Attributes'
 ---
 
-**_Configurable attributes_**, commonly known as [`select()`](
-/reference/be/functions#select), is a Bazel feature that lets users toggle the values
+**_Configurable attributes_**, commonly known as [`select()`](/versions/8.2.1/reference/be/functions#select), is a Bazel feature that lets users toggle the values
 of build rule attributes at the command line.
 
 This can be used, for example, for a multiplatform library that automatically
@@ -407,8 +406,7 @@ sh_library(
 )
 ```
 
-If you need a `select` to match when multiple conditions match, consider [AND
-chaining](#and-chaining).
+If you need a `select` to match when multiple conditions match, consider [AND chaining](#and-chaining).
 
 ## OR chaining {#or-chaining}
 
diff --git a/versions/8.2.1/docs/images/a_b_a_c.svg b/versions/8.2.1/docs/images/a_b_a_c.svg
new file mode 100644
index 00000000..d38be075
--- /dev/null
+++ b/versions/8.2.1/docs/images/a_b_a_c.svg
@@ -0,0 +1,42 @@
+
+
+
+
+
+
+G
+
+
+
+a
+
+a
+
+
+
+b
+
+b
+
+
+
+a->b
+
+
+
+
+
+c
+
+c
+
+
+
+a->c
+
+
+
+
+
+
diff --git a/versions/8.2.1/docs/images/a_b_c.svg b/versions/8.2.1/docs/images/a_b_c.svg
new file mode 100644
index 00000000..acd948ab
--- /dev/null
+++ b/versions/8.2.1/docs/images/a_b_c.svg
@@ -0,0 +1,41 @@
+
+
+
+
+
+
+G
+
+
+
+a
+
+a
+
+
+
+b
+
+b
+
+
+
+a->b
+
+
+
+
+
+c
+
+c
+
+
+
+b->c
+
+
+
+
+
diff --git a/versions/8.2.1/docs/images/a_b_c_ac.svg b/versions/8.2.1/docs/images/a_b_c_ac.svg
new file mode 100644
index 00000000..b099c53e
--- /dev/null
+++ b/versions/8.2.1/docs/images/a_b_c_ac.svg
@@ -0,0 +1,47 @@
+
+
+
+
+
+
+G
+
+
+
+a
+
+a
+
+
+
+b
+
+b
+
+
+
+a->b
+
+
+
+
+
+c
+
+c
+
+
+
+a->c
+
+
+
+
+
+b->c
+
+
+
+
+
diff --git a/versions/8.2.1/docs/images/ab_c.svg b/versions/8.2.1/docs/images/ab_c.svg
new file mode 100644
index 00000000..bcc4563f
--- /dev/null
+++ b/versions/8.2.1/docs/images/ab_c.svg
@@ -0,0 +1,36 @@
+
+
+
+
+
+
+G
+
+
+
+a
+
+a
+
+
+
+b
+
+b
+
+
+
+a->b
+
+
+
+
+
+c
+
+c
+
+
+
+
diff --git a/versions/8.2.1/docs/images/allpaths.svg b/versions/8.2.1/docs/images/allpaths.svg
new file mode 100644
index 00000000..47d0ee33
--- /dev/null
+++ b/versions/8.2.1/docs/images/allpaths.svg
@@ -0,0 +1,141 @@
+
+
+
+
+
+
+allpaths
+
+
+
+n1
+
+
+
+
+n2
+
+
+
+
+n1->n2
+
+
+
+
+
+n3
+
+
+
+
+n2->n3
+
+
+
+
+
+n10
+
+
+
+
+n2->n10
+
+
+
+
+
+n3->n10
+
+
+
+
+
+n4
+
+E
+
+
+
+n5
+
+
+
+
+n6
+
+
+
+
+n5->n6
+
+
+
+
+
+n6->n4
+
+
+
+
+
+n9
+
+
+
+
+n6->n9
+
+
+
+
+
+n7
+
+S1
+
+
+
+n7->n2
+
+
+
+
+
+n7->n5
+
+
+
+
+
+n8
+
+S2
+
+
+
+n8->n6
+
+
+
+
+
+n10->n4
+
+
+
+
+
+n11
+
+
+
+
+n10->n11
+
+
+
+
+
diff --git a/versions/8.2.1/docs/images/android_instrumentation_test.png b/versions/8.2.1/docs/images/android_instrumentation_test.png
new file mode 100644
index 00000000..e4534fbd
Binary files /dev/null and b/versions/8.2.1/docs/images/android_instrumentation_test.png differ
diff --git a/versions/8.2.1/docs/images/android_ndk.png b/versions/8.2.1/docs/images/android_ndk.png
new file mode 100644
index 00000000..76b63cb3
Binary files /dev/null and b/versions/8.2.1/docs/images/android_ndk.png differ
diff --git a/versions/8.2.1/docs/images/android_tutorial_app.png b/versions/8.2.1/docs/images/android_tutorial_app.png
new file mode 100644
index 00000000..076be5b9
Binary files /dev/null and b/versions/8.2.1/docs/images/android_tutorial_app.png differ
diff --git a/versions/8.2.1/docs/images/android_tutorial_before.png b/versions/8.2.1/docs/images/android_tutorial_before.png
new file mode 100644
index 00000000..8e41d419
Binary files /dev/null and b/versions/8.2.1/docs/images/android_tutorial_before.png differ
diff --git a/versions/8.2.1/docs/images/bep-graph.png b/versions/8.2.1/docs/images/bep-graph.png
new file mode 100644
index 00000000..82da6715
Binary files /dev/null and b/versions/8.2.1/docs/images/bep-graph.png differ
diff --git a/versions/8.2.1/docs/images/bep-graph.svg b/versions/8.2.1/docs/images/bep-graph.svg
new file mode 100644
index 00000000..62b1480f
--- /dev/null
+++ b/versions/8.2.1/docs/images/bep-graph.svg
@@ -0,0 +1,4 @@
+
+
+
+
diff --git a/versions/8.2.1/docs/images/cpp-tutorial-stage1.png b/versions/8.2.1/docs/images/cpp-tutorial-stage1.png
new file mode 100644
index 00000000..c85fb303
Binary files /dev/null and b/versions/8.2.1/docs/images/cpp-tutorial-stage1.png differ
diff --git a/versions/8.2.1/docs/images/cpp-tutorial-stage2.png b/versions/8.2.1/docs/images/cpp-tutorial-stage2.png
new file mode 100644
index 00000000..80e202c9
Binary files /dev/null and b/versions/8.2.1/docs/images/cpp-tutorial-stage2.png differ
diff --git a/versions/8.2.1/docs/images/cpp-tutorial-stage3.png b/versions/8.2.1/docs/images/cpp-tutorial-stage3.png
new file mode 100644
index 00000000..54d82f31
Binary files /dev/null and b/versions/8.2.1/docs/images/cpp-tutorial-stage3.png differ
diff --git a/versions/8.2.1/docs/images/deps.svg b/versions/8.2.1/docs/images/deps.svg
new file mode 100644
index 00000000..4354222a
--- /dev/null
+++ b/versions/8.2.1/docs/images/deps.svg
@@ -0,0 +1,101 @@
+
+
+
+
+
+
+G1
+
+
+
+r1
+
+rule
+
+
+
+s1
+
+in
+
+
+
+r1->s1
+
+
+
+
+
+s2
+
+in
+
+
+
+r1->s2
+
+
+
+
+
+s3
+
+in
+
+
+
+r1->s3
+
+
+
+
+
+r2
+
+rule
+
+
+
+r2->r1
+
+
+
+
+
+s4
+
+in
+
+
+
+r2->s4
+
+
+
+
+
+o1
+
+out
+
+
+
+o1->r1
+
+
+
+
+
+o2
+
+out
+
+
+
+o2->r2
+
+
+
+
+
diff --git a/versions/8.2.1/docs/images/dyn-trace-alldynamic.png b/versions/8.2.1/docs/images/dyn-trace-alldynamic.png
new file mode 100644
index 00000000..fe36b253
Binary files /dev/null and b/versions/8.2.1/docs/images/dyn-trace-alldynamic.png differ
diff --git a/versions/8.2.1/docs/images/dyn-trace-javaconly.png b/versions/8.2.1/docs/images/dyn-trace-javaconly.png
new file mode 100644
index 00000000..2ae41e52
Binary files /dev/null and b/versions/8.2.1/docs/images/dyn-trace-javaconly.png differ
diff --git a/versions/8.2.1/docs/images/e4b-workflow.png b/versions/8.2.1/docs/images/e4b-workflow.png
new file mode 100644
index 00000000..412822da
Binary files /dev/null and b/versions/8.2.1/docs/images/e4b-workflow.png differ
diff --git a/versions/8.2.1/docs/images/e4b-workflow.svg b/versions/8.2.1/docs/images/e4b-workflow.svg
new file mode 100644
index 00000000..1de66e02
--- /dev/null
+++ b/versions/8.2.1/docs/images/e4b-workflow.svg
@@ -0,0 +1,4 @@
+
+
+
+
diff --git a/versions/8.2.1/docs/images/error_example_1.png b/versions/8.2.1/docs/images/error_example_1.png
new file mode 100644
index 00000000..07ba1358
Binary files /dev/null and b/versions/8.2.1/docs/images/error_example_1.png differ
diff --git a/versions/8.2.1/docs/images/error_example_2.png b/versions/8.2.1/docs/images/error_example_2.png
new file mode 100644
index 00000000..861171ee
Binary files /dev/null and b/versions/8.2.1/docs/images/error_example_2.png differ
diff --git a/versions/8.2.1/docs/images/error_example_3.png b/versions/8.2.1/docs/images/error_example_3.png
new file mode 100644
index 00000000..dc16eec4
Binary files /dev/null and b/versions/8.2.1/docs/images/error_example_3.png differ
diff --git a/versions/8.2.1/docs/images/error_example_4.png b/versions/8.2.1/docs/images/error_example_4.png
new file mode 100644
index 00000000..84383e63
Binary files /dev/null and b/versions/8.2.1/docs/images/error_example_4.png differ
diff --git a/versions/8.2.1/docs/images/graph_ex_1.svg b/versions/8.2.1/docs/images/graph_ex_1.svg
new file mode 100644
index 00000000..dd7427f4
--- /dev/null
+++ b/versions/8.2.1/docs/images/graph_ex_1.svg
@@ -0,0 +1,131 @@
+
+
+
+
+
+
+mygraph
+
+
+
+//net/proto_compiler:protocol-compiler
+
+//net/proto_compiler:protocol-compiler
+
+
+
+//net/proto_compiler:util
+
+//net/proto_compiler:util
+
+
+
+//net/proto_compiler:protocol-compiler->//net/proto_compiler:util
+
+
+
+
+
+//net/proto_compiler:protocol-compiler-lib
+
+//net/proto_compiler:protocol-compiler-lib
+
+
+
+//net/proto_compiler:protocol-compiler->//net/proto_compiler:protocol-compiler-lib
+
+
+
+
+
+//net/proto2/bridge/public:compiler_upgrader
+
+//net/proto2/bridge/public:compiler_upgrader
+
+
+
+//net/proto_compiler:protocol-compiler->//net/proto2/bridge/public:compiler_upgrader
+
+
+
+
+
+//net/proto_compiler:parser
+
+//net/proto_compiler:parser
+
+
+
+//net/proto_compiler:util->//net/proto_compiler:parser
+
+
+
+
+
+//net/proto_compiler:proto-min-lib
+
+//net/proto_compiler:proto-min-lib
+
+
+
+//net/proto_compiler:protocol-compiler-lib->//net/proto_compiler:proto-min-lib
+
+
+
+
+
+//net/proto_compiler:protocol-compiler-lib->//net/proto_compiler:parser
+
+
+
+
+
+//net/proto2/bridge/internal:compiler_upgrader
+
+//net/proto2/bridge/internal:compiler_upgrader
+
+
+
+//net/proto2/bridge/public:compiler_upgrader->//net/proto2/bridge/internal:compiler_upgrader
+
+
+
+
+
+//net/proto_compiler:proto-min-lib->//net/proto_compiler:parser
+
+
+
+
+
+//util/regexp:regexp
+
+//util/regexp:regexp
+
+
+
+//net/proto_compiler:proto-min-lib->//util/regexp:regexp
+
+
+
+
+
+//net/proto_compiler:parser->//util/regexp:regexp
+
+
+
+
+
+//net/proto2/bridge/internal:compiler_upgrader->//net/proto2/bridge/public:compiler_upgrader
+
+
+
+
+
+//net/proto2/bridge/internal:compiler_upgrader->//net/proto_compiler:parser
+
+
+
+
+
diff --git a/versions/8.2.1/docs/images/graph_hello-world.svg b/versions/8.2.1/docs/images/graph_hello-world.svg
new file mode 100644
index 00000000..93b61444
--- /dev/null
+++ b/versions/8.2.1/docs/images/graph_hello-world.svg
@@ -0,0 +1,70 @@
+
+
+
+
+
+
+mygraph
+
+
+//main:hello-world
+
+//main:hello-world
+
+
+//main:hello-time
+
+//main:hello-time
+
+
+//main:hello-world->//main:hello-time
+
+
+
+
+//main:hello-world.cc
+
+//main:hello-world.cc
+
+
+//main:hello-world->//main:hello-world.cc
+
+
+
+
+//lib:hello-greet
+
+//lib:hello-greet
+
+
+//main:hello-world->//lib:hello-greet
+
+
+
+
+//main:hello-time.cc\n//main:hello-time.h
+
+//main:hello-time.cc
+//main:hello-time.h
+
+
+//main:hello-time->//main:hello-time.cc\n//main:hello-time.h
+
+
+
+
+//lib:hello-greet.cc\n//lib:hello-greet.h
+
+//lib:hello-greet.cc
+//lib:hello-greet.h
+
+
+//lib:hello-greet->//lib:hello-greet.cc\n//lib:hello-greet.h
+
+
+
+
+
diff --git a/versions/8.2.1/docs/images/json-trace-profile-network-usage.png b/versions/8.2.1/docs/images/json-trace-profile-network-usage.png
new file mode 100644
index 00000000..8a7500a6
Binary files /dev/null and b/versions/8.2.1/docs/images/json-trace-profile-network-usage.png differ
diff --git a/versions/8.2.1/docs/images/json-trace-profile-system-load-average.png b/versions/8.2.1/docs/images/json-trace-profile-system-load-average.png
new file mode 100644
index 00000000..e71b420c
Binary files /dev/null and b/versions/8.2.1/docs/images/json-trace-profile-system-load-average.png differ
diff --git a/versions/8.2.1/docs/images/json-trace-profile-workers-memory-usage.png b/versions/8.2.1/docs/images/json-trace-profile-workers-memory-usage.png
new file mode 100644
index 00000000..806505f0
Binary files /dev/null and b/versions/8.2.1/docs/images/json-trace-profile-workers-memory-usage.png differ
diff --git a/versions/8.2.1/docs/images/json-trace-profile.png b/versions/8.2.1/docs/images/json-trace-profile.png
new file mode 100644
index 00000000..538382b2
Binary files /dev/null and b/versions/8.2.1/docs/images/json-trace-profile.png differ
diff --git a/versions/8.2.1/docs/images/mobile-install-performance.svg b/versions/8.2.1/docs/images/mobile-install-performance.svg
new file mode 100644
index 00000000..b139d658
--- /dev/null
+++ b/versions/8.2.1/docs/images/mobile-install-performance.svg
@@ -0,0 +1,86 @@
+
+
+
+  
+    
+      
+    
+  
+  
+  
+    Build times
+  
+  
+    
+    
+      
+      
+        adb install
+      
+      
+    
+    
+      
+      
+        mobile-install
+      
+      
+    
+  
+  
+    
+    
+      
+        
+        
+        
+        
+        
+      
+      
+        
+        
+        
+        
+        
+        
+      
+      
+        
+      
+    
+    
+    
+      
+        Google Maps
+      
+      
+        Google+
+      
+      
+        YouTube
+      
+      
+        0
+      
+      
+        75
+      
+      
+        150
+      
+      
+        225
+      
+      
+        300
+      
+    
+  
+  
+    
+      Seconds
+    
+  
+  
+
diff --git a/versions/8.2.1/docs/images/namedsetoffiles-bep-graph.png b/versions/8.2.1/docs/images/namedsetoffiles-bep-graph.png
new file mode 100644
index 00000000..ea1e10cc
Binary files /dev/null and b/versions/8.2.1/docs/images/namedsetoffiles-bep-graph.png differ
diff --git a/versions/8.2.1/docs/images/out-ranked.svg b/versions/8.2.1/docs/images/out-ranked.svg
new file mode 100644
index 00000000..07e96804
--- /dev/null
+++ b/versions/8.2.1/docs/images/out-ranked.svg
@@ -0,0 +1,71 @@
+
+
+
+
+
+
+mygraph
+
+
+
+//a:a
+
+//a:a
+
+
+
+//a:a.cc
+
+//a:a.cc
+
+
+
+//a:a->//a:a.cc
+
+
+
+
+
+//b:b
+
+//b:b
+
+
+
+//b:b->//a:a
+
+
+
+
+
+//b:b.cc
+
+//b:b.cc
+
+
+
+//b:b->//b:b.cc
+
+
+
+
+
+//c:c
+
+//c:c
+
+
+
+//c:c->//a:a
+
+
+
+
+
+//c:c->//b:b
+
+
+
+
+
diff --git a/versions/8.2.1/docs/images/rbe-ci-1.png b/versions/8.2.1/docs/images/rbe-ci-1.png
new file mode 100644
index 00000000..fbe76a85
Binary files /dev/null and b/versions/8.2.1/docs/images/rbe-ci-1.png differ
diff --git a/versions/8.2.1/docs/images/rbe-ci-2.png b/versions/8.2.1/docs/images/rbe-ci-2.png
new file mode 100644
index 00000000..07611889
Binary files /dev/null and b/versions/8.2.1/docs/images/rbe-ci-2.png differ
diff --git a/versions/8.2.1/docs/images/somepath1.svg b/versions/8.2.1/docs/images/somepath1.svg
new file mode 100644
index 00000000..5e5f8812
--- /dev/null
+++ b/versions/8.2.1/docs/images/somepath1.svg
@@ -0,0 +1,141 @@
+
+
+
+
+
+
+somepath1
+
+
+
+n1
+
+
+
+
+n2
+
+
+
+
+n1->n2
+
+
+
+
+
+n3
+
+
+
+
+n2->n3
+
+
+
+
+
+n10
+
+
+
+
+n2->n10
+
+
+
+
+
+n3->n10
+
+
+
+
+
+n4
+
+E
+
+
+
+n5
+
+
+
+
+n6
+
+
+
+
+n5->n6
+
+
+
+
+
+n6->n4
+
+
+
+
+
+n9
+
+
+
+
+n6->n9
+
+
+
+
+
+n7
+
+S1
+
+
+
+n7->n2
+
+
+
+
+
+n7->n5
+
+
+
+
+
+n8
+
+S2
+
+
+
+n8->n6
+
+
+
+
+
+n10->n4
+
+
+
+
+
+n11
+
+
+
+
+n10->n11
+
+
+
+
+
diff --git a/versions/8.2.1/docs/images/somepath2.svg b/versions/8.2.1/docs/images/somepath2.svg
new file mode 100644
index 00000000..911f2c9b
--- /dev/null
+++ b/versions/8.2.1/docs/images/somepath2.svg
@@ -0,0 +1,141 @@
+
+
+
+
+
+
+somepath2
+
+
+
+n1
+
+
+
+
+n2
+
+
+
+
+n1->n2
+
+
+
+
+
+n3
+
+
+
+
+n2->n3
+
+
+
+
+
+n10
+
+
+
+
+n2->n10
+
+
+
+
+
+n3->n10
+
+
+
+
+
+n4
+
+E
+
+
+
+n5
+
+
+
+
+n6
+
+
+
+
+n5->n6
+
+
+
+
+
+n6->n4
+
+
+
+
+
+n9
+
+
+
+
+n6->n9
+
+
+
+
+
+n7
+
+S1
+
+
+
+n7->n2
+
+
+
+
+
+n7->n5
+
+
+
+
+
+n8
+
+S2
+
+
+
+n8->n6
+
+
+
+
+
+n10->n4
+
+
+
+
+
+n11
+
+
+
+
+n10->n11
+
+
+
+
+
diff --git a/versions/8.2.1/docs/images/targets.svg b/versions/8.2.1/docs/images/targets.svg
new file mode 100644
index 00000000..82f47e74
--- /dev/null
+++ b/versions/8.2.1/docs/images/targets.svg
@@ -0,0 +1,113 @@
+
+
+
+
+
+
+G1
+
+
+
+Target
+
+Target
+
+
+
+Rule
+
+Rule
+
+
+
+Target->Rule
+
+
+
+
+
+File
+
+File
+
+
+
+Target->File
+
+
+
+
+
+Package group
+
+Package group
+
+
+
+Target->Package group
+
+
+
+
+
+cc_library
+
+cc_library
+
+
+
+Rule->cc_library
+
+
+
+
+
+java_test
+
+java_test
+
+
+
+Rule->java_test
+
+
+
+
+
+...
+
+...
+
+
+
+Rule->...
+
+
+
+
+
+Source
+
+Source
+
+
+
+File->Source
+
+
+
+
+
+Generated
+
+Generated
+
+
+
+File->Generated
+
+
+
+
+
diff --git a/versions/8.2.1/docs/images/tutorial_java_01.svg b/versions/8.2.1/docs/images/tutorial_java_01.svg
new file mode 100644
index 00000000..2fe72f36
--- /dev/null
+++ b/versions/8.2.1/docs/images/tutorial_java_01.svg
@@ -0,0 +1,29 @@
+
+
+
+
+
+
+mygraph
+
+
+//:ProjectRunner
+
+//:ProjectRunner
+
+
+//:src/main/java/com/example/Greeting.java\n//:src/main/java/com/example/ProjectRunner.java
+
+//:src/main/java/com/example/Greeting.java
+//:src/main/java/com/example/ProjectRunner.java
+
+
+//:ProjectRunner->//:src/main/java/com/example/Greeting.java\n//:src/main/java/com/example/ProjectRunner.java
+
+
+
+
+
diff --git a/versions/8.2.1/docs/images/tutorial_java_02.svg b/versions/8.2.1/docs/images/tutorial_java_02.svg
new file mode 100644
index 00000000..40cbb218
--- /dev/null
+++ b/versions/8.2.1/docs/images/tutorial_java_02.svg
@@ -0,0 +1,48 @@
+
+
+
+
+
+
+mygraph
+
+
+//:ProjectRunner
+
+//:ProjectRunner
+
+
+//:greeter
+
+//:greeter
+
+
+//:ProjectRunner->//:greeter
+
+
+
+
+//:src/main/java/com/example/ProjectRunner.java
+
+//:src/main/java/com/example/ProjectRunner.java
+
+
+//:ProjectRunner->//:src/main/java/com/example/ProjectRunner.java
+
+
+
+
+//:src/main/java/com/example/Greeting.java
+
+//:src/main/java/com/example/Greeting.java
+
+
+//:greeter->//:src/main/java/com/example/Greeting.java
+
+
+
+
+
diff --git a/versions/8.2.1/docs/images/tutorial_java_03.svg b/versions/8.2.1/docs/images/tutorial_java_03.svg
new file mode 100644
index 00000000..7d79041a
--- /dev/null
+++ b/versions/8.2.1/docs/images/tutorial_java_03.svg
@@ -0,0 +1,48 @@
+
+
+
+
+
+
+mygraph
+
+
+//src/main/java/com/example/cmdline:runner
+
+//src/main/java/com/example/cmdline:runner
+
+
+//src/main/java/com/example/cmdline:Runner.java
+
+//src/main/java/com/example/cmdline:Runner.java
+
+
+//src/main/java/com/example/cmdline:runner->//src/main/java/com/example/cmdline:Runner.java
+
+
+
+
+//:greeter
+
+//:greeter
+
+
+//src/main/java/com/example/cmdline:runner->//:greeter
+
+
+
+
+//:src/main/java/com/example/Greeting.java
+
+//:src/main/java/com/example/Greeting.java
+
+
+//:greeter->//:src/main/java/com/example/Greeting.java
+
+
+
+
+
diff --git a/versions/8.2.1/docs/images/workers-clean-chart.png b/versions/8.2.1/docs/images/workers-clean-chart.png
new file mode 100644
index 00000000..63526fc1
Binary files /dev/null and b/versions/8.2.1/docs/images/workers-clean-chart.png differ
diff --git a/versions/8.2.1/docs/images/workers-incremental-chart.png b/versions/8.2.1/docs/images/workers-incremental-chart.png
new file mode 100644
index 00000000..1c62d25c
Binary files /dev/null and b/versions/8.2.1/docs/images/workers-incremental-chart.png differ
diff --git a/versions/8.2.1/docs/images/ws-diamond.png b/versions/8.2.1/docs/images/ws-diamond.png
new file mode 100644
index 00000000..154a7440
Binary files /dev/null and b/versions/8.2.1/docs/images/ws-diamond.png differ
diff --git a/versions/8.2.1/docs/images/ws-line.png b/versions/8.2.1/docs/images/ws-line.png
new file mode 100644
index 00000000..e8bfe7a1
Binary files /dev/null and b/versions/8.2.1/docs/images/ws-line.png differ
diff --git a/versions/8.2.1/docs/images/ws-multiline.png b/versions/8.2.1/docs/images/ws-multiline.png
new file mode 100644
index 00000000..f07b43b1
Binary files /dev/null and b/versions/8.2.1/docs/images/ws-multiline.png differ
diff --git a/versions/8.2.1/docs/sandboxing.mdx b/versions/8.2.1/docs/sandboxing.mdx
index ec8b5cbe..3908e8da 100644
--- a/versions/8.2.1/docs/sandboxing.mdx
+++ b/versions/8.2.1/docs/sandboxing.mdx
@@ -48,7 +48,7 @@ containers on Linux and `sandbox-exec` on macOS, to constrain the action within
 ## What sandbox strategy to use {#sandboxing-strategies}
 
 You can choose which kind of sandboxing to use, if any, with the
-[strategy flags](user-manual#strategy-options). Using the `sandboxed`
+[strategy flags](/versions/8.2.1/docs/user-manual#strategy-options). Using the `sandboxed`
 strategy makes Bazel pick one of the sandbox implementations listed below,
 preferring an OS-specific sandbox to the less hermetic generic one.
 [Persistent workers](/versions/8.2.1/remote/persistent) run in a generic sandbox if you pass
diff --git a/versions/8.2.1/docs/user-manual.mdx b/versions/8.2.1/docs/user-manual.mdx
index 1e39f186..2bec62e6 100644
--- a/versions/8.2.1/docs/user-manual.mdx
+++ b/versions/8.2.1/docs/user-manual.mdx
@@ -1161,8 +1161,8 @@ during execution can be examined.
 This option causes Bazel's execution phase to print the full command line
 for each command prior to executing it.
 
-```bash
-  >>>>> # //examples/cpp:hello-world [action 'Linking examples/cpp/hello-world']
+```
+  >>>> # //examples/cpp:hello-world [action 'Linking examples/cpp/hello-world']
   (cd /home/johndoe/.cache/bazel/_bazel_johndoe/4c084335afceb392cfbe7c31afee3a9f/bazel && \
     exec env - \
     /usr/bin/gcc -o bazel-out/local-fastbuild/bin/examples/cpp/hello-world -B/usr/bin/ -Wl,-z,relro,-z,now -no-canonical-prefixes -pass-exit-codes -Wl,-S -Wl,@bazel-out/local_linux-fastbuild/bin/examples/cpp/hello-world-2.params)
diff --git a/versions/8.2.1/extending/auto-exec-groups.mdx b/versions/8.2.1/extending/auto-exec-groups.mdx
index 9c3d0d33..f85e9212 100644
--- a/versions/8.2.1/extending/auto-exec-groups.mdx
+++ b/versions/8.2.1/extending/auto-exec-groups.mdx
@@ -27,9 +27,7 @@ doesn't detect that ([the error](#first-error-message) is raised), you can set
 
 If you need to use multiple toolchains on a single execution platform (an action
 uses executable or tools from two or more toolchains), you need to manually
-define [exec_groups][exec_groups] (check
-[When should I use a custom exec_group?][multiple_toolchains_exec_groups]
-section).
+define [exec_groups][exec_groups](check [When should I use a custom exec_group?][multiple_toolchains_exec_groups] section).
 
 ## History {#history}
 
@@ -42,8 +40,7 @@ my_rule = rule(
 )
 ```
 
-Rule `my_rule` registers two toolchain types. This means that the [Toolchain
-Resolution](https://bazel.build/extending/toolchains#toolchain-resolution) used
+Rule `my_rule` registers two toolchain types. This means that the [Toolchain Resolution](https://bazel.build/versions/8.2.1/extending/toolchains#toolchain-resolution) used
 to find an execution platform which supports both toolchain types. The selected
 execution platform was used for each registered action inside the rule, unless
 specified differently with [exec_groups][exec_groups].
diff --git a/versions/8.2.1/extending/concepts.mdx b/versions/8.2.1/extending/concepts.mdx
index 3eb8da4d..7579dc49 100644
--- a/versions/8.2.1/extending/concepts.mdx
+++ b/versions/8.2.1/extending/concepts.mdx
@@ -20,16 +20,14 @@ Before learning the more advanced concepts, first:
 ## Macros and rules {#macros-and-rules}
 
 A macro is a function that instantiates rules. Macros come in two flavors:
-[symbolic macros](/versions/8.2.1/extending/macros) (new in Bazel 8) and [legacy
-macros](/versions/8.2.1/extending/legacy-macros). The two flavors of macros are defined
+[symbolic macros](/versions/8.2.1/extending/macros) (new in Bazel 8) and [legacy macros](/versions/8.2.1/extending/legacy-macros). The two flavors of macros are defined
 differently, but behave almost the same from the point of view of a user. A
 macro is useful when a `BUILD` file is getting too repetitive or too complex, as
 it lets you reuse some code. The function is evaluated as soon as the `BUILD`
 file is read. After the evaluation of the `BUILD` file, Bazel has little
 information about macros. If your macro generates a `genrule`, Bazel will
 behave *almost* as if you declared that `genrule` in the `BUILD` file. (The one
-exception is that targets declared in a symbolic macro have [special visibility
-semantics](/versions/8.2.1/extending/macros#visibility): a symbolic macro can hide its internal
+exception is that targets declared in a symbolic macro have [special visibility semantics](/versions/8.2.1/extending/macros#visibility): a symbolic macro can hide its internal
 targets from the rest of the package.)
 
 A [rule](/versions/8.2.1/extending/rules) is more powerful than a macro. It can access Bazel
@@ -76,8 +74,7 @@ they will not be executed.
 ## Creating extensions
 
 * [Create your first macro](/versions/8.2.1/rules/macro-tutorial) in order to reuse some code.
-  Then [learn more about macros](/versions/8.2.1/extending/macros) and [using them to create
-  "custom verbs"](/versions/8.2.1/rules/verbs-tutorial).
+  Then [learn more about macros](/versions/8.2.1/extending/macros) and [using them to create "custom verbs"](/versions/8.2.1/rules/verbs-tutorial).
 
 * [Follow the rules tutorial](/versions/8.2.1/rules/rules-tutorial) to get started with rules.
   Next, you can read more about the [rules concepts](/versions/8.2.1/extending/rules).
@@ -92,8 +89,7 @@ them within reach:
 ## Going further
 
 In addition to [macros](/versions/8.2.1/extending/macros) and [rules](/versions/8.2.1/extending/rules), you
-may want to write [aspects](/versions/8.2.1/extending/aspects) and [repository
-rules](/versions/8.2.1/extending/repo).
+may want to write [aspects](/versions/8.2.1/extending/aspects) and [repository rules](/versions/8.2.1/extending/repo).
 
 * Use [Buildifier](https://github.com/bazelbuild/buildtools)
   consistently to format and lint your code.
diff --git a/versions/8.2.1/extending/depsets.mdx b/versions/8.2.1/extending/depsets.mdx
index 5fc3b106..8f95b876 100644
--- a/versions/8.2.1/extending/depsets.mdx
+++ b/versions/8.2.1/extending/depsets.mdx
@@ -111,8 +111,7 @@ need to ensure that if `B` depends on `A`, then `A.o` comes before `B.o` on the
 linker’s command line. Other tools might have the opposite requirement.
 
 Three traversal orders are supported: `postorder`, `preorder`, and
-`topological`. The first two work exactly like [tree
-traversals](https://en.wikipedia.org/wiki/Tree_traversal#Depth-first_search)
+`topological`. The first two work exactly like [tree traversals](https://en.wikipedia.org/wiki/Tree_traversal#Depth-first_search)
 except that they operate on DAGs and skip already visited nodes. The third order
 works as a topological sort from root to leaves, essentially the same as
 preorder except that shared children are listed only after all of their parents.
diff --git a/versions/8.2.1/extending/exec-groups.mdx b/versions/8.2.1/extending/exec-groups.mdx
index bfd6ec63..f00e3a76 100644
--- a/versions/8.2.1/extending/exec-groups.mdx
+++ b/versions/8.2.1/extending/exec-groups.mdx
@@ -63,8 +63,7 @@ test rules.
 
 In the rule implementation, you can declare that actions should be run on the
 execution platform of an execution group. You can do this by using the `exec_group`
-param of action generating methods, specifically [`ctx.actions.run`]
-(/rules/lib/builtins/actions#run) and
+param of action generating methods, specifically [`ctx.actions.run`](/versions/8.2.1/rules/lib/builtins/actions#run) and
 [`ctx.actions.run_shell`](/versions/8.2.1/rules/lib/builtins/actions#run_shell).
 
 ```python
diff --git a/versions/8.2.1/extending/legacy-macros.mdx b/versions/8.2.1/extending/legacy-macros.mdx
index 7a9ba01e..f47c953f 100644
--- a/versions/8.2.1/extending/legacy-macros.mdx
+++ b/versions/8.2.1/extending/legacy-macros.mdx
@@ -9,7 +9,7 @@ anymore, and Bazel sees only the concrete set of instantiated rules.
 
 ## Why you shouldn't use legacy macros (and should use Symbolic macros instead) {#no-legacy-macros}
 
-Where possible you should use [symbolic macros](macros.md#macros).
+Where possible you should use [symbolic macros](/versions/8.2.1/extending/macros#macros).
 
 Symbolic macros
 
@@ -18,7 +18,7 @@ Symbolic macros
 *   Take typed attributes, which in turn means automatic label and select
     conversion.
 *   Are more readable
-*   Will soon have [lazy evaluation](macros.md/laziness)
+*   Will soon have [lazy evaluation](/versions/8.2.1/extending/macros#laziness)
 
 ## Usage {#usage}
 
@@ -152,7 +152,7 @@ the macro), use the function
 ## Label resolution in macros {#label-resolution}
 
 Since legacy macros are evaluated in the
-[loading phase](concepts.md#evaluation-model), label strings such as
+[loading phase](/versions/8.2.1/extending/concepts#evaluation-model), label strings such as
 `"//foo:bar"` that occur in a legacy macro are interpreted relative to the
 `BUILD` file in which the macro is used rather than relative to the `.bzl` file
 in which it is defined. This behavior is generally undesirable for macros that
diff --git a/versions/8.2.1/extending/macros.mdx b/versions/8.2.1/extending/macros.mdx
index 3a27bf62..cbeb864e 100644
--- a/versions/8.2.1/extending/macros.mdx
+++ b/versions/8.2.1/extending/macros.mdx
@@ -10,7 +10,7 @@ Macros are mainly used for encapsulation and code reuse of existing rules and
 other macros.
 
 Macros come in two flavors: symbolic macros, which are described on this page,
-and [legacy macros](legacy-macros.md). Where possible, we recommend using
+and [legacy macros](/versions/8.2.1/extending/legacy-macros). Where possible, we recommend using
 symbolic macros for code clarity.
 
 Symbolic macros offer typed arguments (string to label conversion, relative to
@@ -31,8 +31,7 @@ two required parameters: `attrs` and `implementation`.
 
 ### Attributes {#attributes}
 
-`attrs` accepts a dictionary of attribute name to [attribute
-types](https://bazel.build/rules/lib/toplevel/attr#members), which represents
+`attrs` accepts a dictionary of attribute name to [attribute types](https://bazel.build/versions/8.2.1/rules/lib/toplevel/attr#members), which represents
 the arguments to the macro. Two common attributes – `name` and `visibility` –
 are implicitly added to all macros and are not included in the dictionary passed
 to `attrs`.
@@ -66,9 +65,7 @@ To support this pattern, a macro can *inherit attributes* from a rule or another
 macro by passing the [rule](https://bazel.build/versions/8.2.1/rules/lib/builtins/rule) or
 [macro symbol](https://bazel.build/versions/8.2.1/rules/lib/builtins/macro) to `macro()`'s
 `inherit_attrs` argument. (You can also use the special string `"common"`
-instead of a rule or macro symbol to inherit the [common attributes defined for
-all Starlark build
-rules](https://bazel.build/reference/be/common-definitions#common-attributes).)
+instead of a rule or macro symbol to inherit the [common attributes defined for all Starlark build rules](https://bazel.build/versions/8.2.1/reference/be/common-definitions#common-attributes).)
 Only public attributes get inherited, and the attributes in the macro's own
 `attrs` dictionary override inherited attributes with the same name. You can
 also *remove* inherited attributes by using `None` as a value in the `attrs`
diff --git a/versions/8.2.1/extending/platforms.mdx b/versions/8.2.1/extending/platforms.mdx
index 48ec3fa2..1bbde38a 100644
--- a/versions/8.2.1/extending/platforms.mdx
+++ b/versions/8.2.1/extending/platforms.mdx
@@ -245,8 +245,7 @@ cc_library(
 
 You can use the
 [`IncompatiblePlatformProvider`](/versions/8.2.1/rules/lib/providers/IncompatiblePlatformProvider)
-in `bazel cquery`'s [Starlark output
-format](/versions/8.2.1/query/cquery#output-format-definition) to distinguish
+in `bazel cquery`'s [Starlark output format](/versions/8.2.1/query/cquery#output-format-definition) to distinguish
 incompatible targets from compatible ones.
 
 This can be used to filter out incompatible targets. The example below will
@@ -266,5 +265,4 @@ $ bazel cquery //... --output=starlark --starlark:file=example.cquery
 
 ### Known Issues
 
-Incompatible targets [ignore visibility
-restrictions](https://github.com/bazelbuild/bazel/issues/16044).
+Incompatible targets [ignore visibility restrictions](https://github.com/bazelbuild/bazel/issues/16044).
diff --git a/versions/8.2.1/extending/repo.mdx b/versions/8.2.1/extending/repo.mdx
index 7b207a88..d8dcf489 100644
--- a/versions/8.2.1/extending/repo.mdx
+++ b/versions/8.2.1/extending/repo.mdx
@@ -74,8 +74,7 @@ specified.
 
 The input parameter `repository_ctx` can be used to access attribute values, and
 non-hermetic functions (finding a binary, executing a binary, creating a file in
-the repository or downloading a file from the Internet). See [the API
-docs](/versions/8.2.1/rules/lib/builtins/repository_ctx) for more context. Example:
+the repository or downloading a file from the Internet). See [the API docs](/versions/8.2.1/rules/lib/builtins/repository_ctx) for more context. Example:
 
 ```python
 def _impl(repository_ctx):
@@ -144,8 +143,7 @@ definition has the `configure` attribute set, use `bazel fetch --force
 
 ## Examples
 
--   [C++ auto-configured
-    toolchain](https://cs.opensource.google/bazel/bazel/+/master:tools/cpp/cc_configure.bzl;drc=644b7d41748e09eff9e47cbab2be2263bb71f29a;l=176):
+-   [C++ auto-configured toolchain](https://cs.opensource.google/bazel/bazel/+/master:tools/cpp/cc_configure.bzl;drc=644b7d41748e09eff9e47cbab2be2263bb71f29a;l=176):
     it uses a repo rule to automatically create the C++ configuration files for
     Bazel by looking for the local C++ compiler, the environment and the flags
     the C++ compiler supports.
diff --git a/versions/8.2.1/extending/rules.mdx b/versions/8.2.1/extending/rules.mdx
index 83cc1755..227d14fa 100644
--- a/versions/8.2.1/extending/rules.mdx
+++ b/versions/8.2.1/extending/rules.mdx
@@ -449,8 +449,7 @@ def _example_library_impl(ctx):
 
 If `DefaultInfo` is not returned by a rule implementation or the `files`
 parameter is not specified, `DefaultInfo.files` defaults to all
-*predeclared outputs* (generally, those created by [output
-attributes](#output_attributes)).
+*predeclared outputs* (generally, those created by [output attributes](#output_attributes)).
 
 Rules that perform actions should provide default outputs, even if those outputs
 are not expected to be directly used. Actions that are not in the graph of the
diff --git a/versions/8.2.1/extending/toolchains.mdx b/versions/8.2.1/extending/toolchains.mdx
index c7debd52..6cfb3351 100644
--- a/versions/8.2.1/extending/toolchains.mdx
+++ b/versions/8.2.1/extending/toolchains.mdx
@@ -523,8 +523,7 @@ The set of available toolchains, in priority order, is created from
   4. Toolchains registered in the "WORKSPACE suffix"; this is only used by
      certain native rules bundled with the Bazel installation.
 
-**NOTE:** [Pseudo-targets like `:all`, `:*`, and
-`/...`](/versions/8.2.1/run/build#specifying-build-targets) are ordered by Bazel's package
+**NOTE:** [Pseudo-targets like `:all`, `:*`, and `/...`](/versions/8.2.1/run/build#specifying-build-targets) are ordered by Bazel's package
 loading mechanism, which uses a lexicographic ordering.
 
 The resolution steps are as follows.
diff --git a/versions/8.2.1/external/advanced.mdx b/versions/8.2.1/external/advanced.mdx
index 883162cb..56c9e472 100644
--- a/versions/8.2.1/external/advanced.mdx
+++ b/versions/8.2.1/external/advanced.mdx
@@ -4,10 +4,8 @@ title: 'Advanced topics on external dependencies'
 
 ## Shadowing dependencies in WORKSPACE
 
-Note: This section applies to the [WORKSPACE
-system](/versions/8.2.1/external/overview#workspace-system) only. For
-[Bzlmod](/versions/8.2.1/external/overview#bzlmod), use a [multiple-version
-override](/versions/8.2.1/external/module#multiple-version_override).
+Note: This section applies to the [WORKSPACE system](/versions/8.2.1/external/overview#workspace-system) only. For
+[Bzlmod](/versions/8.2.1/external/overview#bzlmod), use a [multiple-version override](/versions/8.2.1/external/module#multiple-version_override).
 
 Whenever possible, have a single version policy in your project, which is
 required for dependencies that you compile against and end up in your final
@@ -128,29 +126,24 @@ preferring IPv4 if enabled. In some situations, for example when the IPv4
 network cannot resolve/reach external addresses, this can cause `Network
 unreachable` exceptions and build failures. In these cases, you can override
 Bazel's behavior to prefer IPv6 by using the
-[`java.net.preferIPv6Addresses=true` system
-property](https://docs.oracle.com/javase/8/docs/api/java/net/doc-files/net-properties.html).
+[`java.net.preferIPv6Addresses=true` system property](https://docs.oracle.com/javase/8/docs/api/java/net/doc-files/net-properties.html).
 Specifically:
 
-*   Use `--host_jvm_args=-Djava.net.preferIPv6Addresses=true` [startup
-    option](/versions/8.2.1/docs/user-manual#startup-options), for example by adding the
+*   Use `--host_jvm_args=-Djava.net.preferIPv6Addresses=true` [startup option](/versions/8.2.1/docs/user-manual#startup-options), for example by adding the
     following line in your [`.bazelrc` file](/versions/8.2.1/run/bazelrc):
 
     `startup --host_jvm_args=-Djava.net.preferIPv6Addresses=true`
 
 *   When running Java build targets that need to connect to the internet (such
     as for integration tests), use the
-    `--jvmopt=-Djava.net.preferIPv6Addresses=true` [tool
-    flag](/versions/8.2.1/docs/user-manual#jvmopt). For example, include in your [`.bazelrc`
-    file](/versions/8.2.1/run/bazelrc):
+    `--jvmopt=-Djava.net.preferIPv6Addresses=true` [tool flag](/versions/8.2.1/docs/user-manual#jvmopt). For example, include in your [`.bazelrc` file](/versions/8.2.1/run/bazelrc):
 
     `build --jvmopt=-Djava.net.preferIPv6Addresses`
 
 *   If you are using [`rules_jvm_external`](https://github.com/bazelbuild/rules_jvm_external)
     for dependency version resolution, also add
     `-Djava.net.preferIPv6Addresses=true` to the `COURSIER_OPTS` environment
-    variable to [provide JVM options for
-    Coursier](https://github.com/bazelbuild/rules_jvm_external#provide-jvm-options-for-coursier-with-coursier_opts).
+    variable to [provide JVM options for Coursier](https://github.com/bazelbuild/rules_jvm_external#provide-jvm-options-for-coursier-with-coursier_opts).
 
 ## Offline builds
 
@@ -167,15 +160,12 @@ fetch a file with [`ctx.download`](/versions/8.2.1/rules/lib/builtins/repository
 providing a hash sum of the file needed, Bazel looks for a file matching the
 basename of the first URL, and uses the local copy if the hash matches.
 
-Bazel itself uses this technique to bootstrap offline from the [distribution
-artifact](https://github.com/bazelbuild/bazel-website/blob/master/designs/_posts/2016-10-11-distribution-artifact.md).
-It does so by [collecting all the needed external
-dependencies](https://github.com/bazelbuild/bazel/blob/5cfa0303d6ac3b5bd031ff60272ce80a704af8c2/WORKSPACE#L116)
+Bazel itself uses this technique to bootstrap offline from the [distribution artifact](https://github.com/bazelbuild/bazel-website/blob/master/designs/_posts/2016-10-11-distribution-artifact.md).
+It does so by [collecting all the needed external dependencies](https://github.com/bazelbuild/bazel/blob/5cfa0303d6ac3b5bd031ff60272ce80a704af8c2/WORKSPACE#L116)
 in an internal
 [`distdir_tar`](https://github.com/bazelbuild/bazel/blob/5cfa0303d6ac3b5bd031ff60272ce80a704af8c2/distdir.bzl#L44).
 
 Bazel allows execution of arbitrary commands in repository rules without knowing
 if they call out to the network, and so cannot enforce fully offline builds. To
 test if a build works correctly offline, manually block off the network (as
-Bazel does in its [bootstrap
-test](https://cs.opensource.google/bazel/bazel/+/master:src/test/shell/bazel/BUILD;l=1073;drc=88c426e73cc0eb0a41c0d7995e36acd94e7c9a48)).
\ No newline at end of file
+Bazel does in its [bootstrap test](https://cs.opensource.google/bazel/bazel/+/master:src/test/shell/bazel/BUILD;l=1073;drc=88c426e73cc0eb0a41c0d7995e36acd94e7c9a48)).
\ No newline at end of file
diff --git a/versions/8.2.1/external/images/mod_exampleBefore.svg b/versions/8.2.1/external/images/mod_exampleBefore.svg
new file mode 100644
index 00000000..66f01303
--- /dev/null
+++ b/versions/8.2.1/external/images/mod_exampleBefore.svg
@@ -0,0 +1,175 @@
+
+
+
+
+
+
+mygraph
+
+
+
+<root>
+
+<root> (my_project@1.0)
+
+
+
+bazel_skylib@1.1.1
+
+bazel_skylib@1.1.1
+
+
+
+<root>->bazel_skylib@1.1.1
+
+
+
+
+
+bazel_skylib@1.2.0
+
+bazel_skylib@1.2.0
+
+
+
+<root>->bazel_skylib@1.2.0
+
+
+
+
+
+rules_java@5.0.0
+
+rules_java@5.0.0
+
+
+
+<root>->rules_java@5.0.0
+
+
+
+
+
+stardoc@0.5.0
+
+stardoc@0.5.0
+
+
+
+<root>->stardoc@0.5.0
+
+
+
+
+
+platforms@0.0.4
+
+platforms@0.0.4
+
+
+
+bazel_skylib@1.1.1->platforms@0.0.4
+
+
+
+
+
+bazel_skylib@1.2.0->platforms@0.0.4
+
+
+
+
+
+rules_java@5.0.0->platforms@0.0.4
+
+
+
+
+
+rules_cc@0.0.1
+
+rules_cc@0.0.1
+
+
+
+rules_java@5.0.0->rules_cc@0.0.1
+
+
+
+
+
+rules_proto@4.0.0
+
+rules_proto@4.0.0
+
+
+
+rules_java@5.0.0->rules_proto@4.0.0
+
+
+
+
+
+bazel_skylib@1.0.3
+
+bazel_skylib@1.0.3
+
+
+
+stardoc@0.5.0->bazel_skylib@1.0.3
+
+
+
+
+
+rules_java@4.0.0
+
+rules_java@4.0.0
+
+
+
+stardoc@0.5.0->rules_java@4.0.0
+
+
+
+
+
+rules_cc@0.0.1->platforms@0.0.4
+
+
+
+
+
+rules_cc@0.0.1->bazel_skylib@1.0.3
+
+
+
+
+
+rules_proto@4.0.0->rules_cc@0.0.1
+
+
+
+
+
+rules_proto@4.0.0->bazel_skylib@1.0.3
+
+
+
+
+
+bazel_skylib@1.0.3->platforms@0.0.4
+
+
+
+
+
+rules_java@4.0.0->bazel_skylib@1.0.3
+
+
+
+
+
\ No newline at end of file
diff --git a/versions/8.2.1/external/images/mod_exampleResolved.svg b/versions/8.2.1/external/images/mod_exampleResolved.svg
new file mode 100644
index 00000000..224b694c
--- /dev/null
+++ b/versions/8.2.1/external/images/mod_exampleResolved.svg
@@ -0,0 +1,151 @@
+
+
+
+
+
+
+mygraph
+
+
+
+<root>
+
+<root> (my_project@1.0)
+
+
+
+bazel_skylib@1.1.1
+
+bazel_skylib@1.1.1
+
+
+
+<root>->bazel_skylib@1.1.1
+
+
+
+
+
+bazel_skylib@1.2.0
+
+bazel_skylib@1.2.0
+
+
+
+<root>->bazel_skylib@1.2.0
+
+
+
+
+
+rules_java@5.0.0
+
+rules_java@5.0.0
+
+
+
+<root>->rules_java@5.0.0
+
+
+
+
+
+stardoc@0.5.0
+
+stardoc@0.5.0
+
+
+
+<root>->stardoc@0.5.0
+
+
+
+
+
+platforms@0.0.4
+
+platforms@0.0.4
+
+
+
+bazel_skylib@1.1.1->platforms@0.0.4
+
+
+
+
+
+bazel_skylib@1.2.0->platforms@0.0.4
+
+
+
+
+
+rules_java@5.0.0->platforms@0.0.4
+
+
+
+
+
+rules_cc@0.0.1
+
+rules_cc@0.0.1
+
+
+
+rules_java@5.0.0->rules_cc@0.0.1
+
+
+
+
+
+rules_proto@4.0.0
+
+rules_proto@4.0.0
+
+
+
+rules_java@5.0.0->rules_proto@4.0.0
+
+
+
+
+
+stardoc@0.5.0->bazel_skylib@1.1.1
+
+
+
+
+
+stardoc@0.5.0->rules_java@5.0.0
+
+
+
+
+
+rules_cc@0.0.1->bazel_skylib@1.1.1
+
+
+
+
+
+rules_cc@0.0.1->platforms@0.0.4
+
+
+
+
+
+rules_proto@4.0.0->bazel_skylib@1.1.1
+
+
+
+
+
+rules_proto@4.0.0->rules_cc@0.0.1
+
+
+
+
+
\ No newline at end of file
diff --git a/versions/8.2.1/external/migration.mdx b/versions/8.2.1/external/migration.mdx
index 2c779abb..78855bef 100644
--- a/versions/8.2.1/external/migration.mdx
+++ b/versions/8.2.1/external/migration.mdx
@@ -2,8 +2,7 @@
 title: 'Bzlmod Migration Guide'
 ---
 
-Due to the [shortcomings of
-WORKSPACE](/versions/8.2.1/external/overview#workspace-shortcomings), Bzlmod is going to
+Due to the [shortcomings of WORKSPACE](/versions/8.2.1/external/overview#workspace-shortcomings), Bzlmod is going to
 replace the legacy WORKSPACE system. The WORKSPACE file will be disabled by
 default in Bazel 8 (late 2024) and will be removed in Bazel 9 (late 2025).
 This guide helps you migrate your project to Bzlmod and drop WORKSPACE for
@@ -117,9 +116,7 @@ Bazel module when it also adopts Bzlmod.
 
 *   **Bzlmod**
 
-    With Bzlmod, as long as the your dependency is available in [Bazel Central
-    Registry](https://registry.bazel.build) or your custom [Bazel
-    registry](/versions/8.2.1/external/registry), you can simply depend on it with a
+    With Bzlmod, as long as the your dependency is available in [Bazel Central Registry](https://registry.bazel.build) or your custom [Bazel registry](/versions/8.2.1/external/registry), you can simply depend on it with a
     [`bazel_dep`](/versions/8.2.1/rules/lib/globals/module#bazel_dep) directive.
 
     ```python
@@ -150,8 +147,7 @@ repository.
 
 If your dependency is not a Bazel project or not yet available in any Bazel
 registry, you can introduce it using
-[`use_repo_rule`](/versions/8.2.1/external/module#use_repo_rule) or [module
-extensions](/versions/8.2.1/external/extension).
+[`use_repo_rule`](/versions/8.2.1/external/module#use_repo_rule) or [module extensions](/versions/8.2.1/external/extension).
 
 *   **WORKSPACE**
 
@@ -604,8 +600,7 @@ macros.
 Fortunately, the flag
 [`--experimental_repository_resolved_file`][resolved_file_flag]
 can help. This flag essentially generates a "lock file" of all fetched external
-dependencies in your last Bazel command. You can find more details in this [blog
-post](https://blog.bazel.build/2018/07/09/bazel-sync-and-resolved-file.html).
+dependencies in your last Bazel command. You can find more details in this [blog post](https://blog.bazel.build/2018/07/09/bazel-sync-and-resolved-file.html).
 
 [resolved_file_flag]: /reference/command-line-reference#flag--experimental_repository_resolved_file
 
@@ -646,11 +641,9 @@ You may also know `bazel query` can be used for inspecting repository rules with
 bazel query --output=build //external:
 ```
 
-While it is more convenient and much faster, [bazel query can lie about
-external dependency version](https://github.com/bazelbuild/bazel/issues/12947),
+While it is more convenient and much faster, [bazel query can lie about external dependency version](https://github.com/bazelbuild/bazel/issues/12947),
 so be careful using it! Querying and inspecting external
-dependencies with Bzlmod is going to achieved by a [new
-subcommand](https://github.com/bazelbuild/bazel/issues/15365).
+dependencies with Bzlmod is going to achieved by a [new subcommand](https://github.com/bazelbuild/bazel/issues/15365).
 
 #### Built-in default dependencies {#builtin-default-deps}
 
@@ -697,8 +690,7 @@ Using the WORKSPACE.bzlmod file can make the migration easier because:
 #### Repository visibility {#repository-visibility}
 
 Bzlmod is able to control which other repositories are visible from a given
-repository, check [repository names and strict
-deps](/versions/8.2.1/external/module#repository_names_and_strict_deps) for more details.
+repository, check [repository names and strict deps](/versions/8.2.1/external/module#repository_names_and_strict_deps) for more details.
 
 Here is a summary of repository visibilities from different types of
 repositories when also taking WORKSPACE into consideration.
@@ -711,8 +703,7 @@ repositories when also taking WORKSPACE into consideration.
 | WORKSPACE Repos | All visible | Not visible | Not visible | All visible |
 
 Note: For the root module, if a repository `@foo` is defined in WORKSPACE and
-`@foo` is also used as an [apparent repository
-name](/versions/8.2.1/external/overview#apparent-repo-name) in MODULE.bazel, then `@foo`
+`@foo` is also used as an [apparent repository name](/versions/8.2.1/external/overview#apparent-repo-name) in MODULE.bazel, then `@foo`
 refers to the one introduced in MODULE.bazel.
 
 Note: For a module extension generated repository `@bar`, if `@foo` is used as
@@ -787,9 +778,7 @@ the project. Take note of a few things when creating the source archive:
     GitHub isn't going to guarantee the checksum of source archives generated on
     demand. In short, URLs in the form of
     `https://github.com///releases/download/...` is considered stable
-    while `https://github.com///archive/...` is not. Check [GitHub
-    Archive Checksum
-    Outage](https://blog.bazel.build/2023/02/15/github-archive-checksum.html)
+    while `https://github.com///archive/...` is not. Check [GitHub Archive Checksum Outage](https://blog.bazel.build/2023/02/15/github-archive-checksum.html)
     for more context.
 
 *   **Make sure the source tree follows the layout of the original repository.**
@@ -818,8 +807,7 @@ Pull Request.
 
 [bcr_contrib_guide]: https://github.com/bazelbuild/bazel-central-registry/tree/main/docs#contribute-a-bazel-module
 
-It is **highly recommended** to set up the [Publish to
-BCR](https://github.com/bazel-contrib/publish-to-bcr) GitHub App for your
+It is **highly recommended** to set up the [Publish to BCR](https://github.com/bazel-contrib/publish-to-bcr) GitHub App for your
 repository to automate the process of submitting your module to the BCR.
 
 ## Best practices {#best-practices}
diff --git a/versions/8.2.1/external/mod-command.mdx b/versions/8.2.1/external/mod-command.mdx
index e49acc52..f633234f 100644
--- a/versions/8.2.1/external/mod-command.mdx
+++ b/versions/8.2.1/external/mod-command.mdx
@@ -61,11 +61,9 @@ The available subcommands and their respective required arguments are:
 
 *   ``: All present versions of the module ``.
 
-*   `@`: The repo with the given [apparent
-    name](overview#apparent-repo-name) in the context of the `--base_module`.
+*   `@`: The repo with the given [apparent name](/versions/8.2.1/external/overview#apparent-repo-name) in the context of the `--base_module`.
 
-*   `@@`: The repo with the given [canonical
-    name](overview#canonical-repo-name).
+*   `@@`: The repo with the given [canonical name](/versions/8.2.1/external/overview#canonical-repo-name).
 
 In a context requiring specifying modules, ``s referring to repos that
 correspond to modules (as opposed to extension-generated repos) can also be
@@ -87,8 +85,7 @@ The following options only affect the subcommands that print graphs (`graph`,
     information about the version resolution of each module. If the module
     version changed during resolution, show either which version replaced it or
     what was the original version, the reason it was replaced, and which modules
-    requested the new version if the reason was [Minimal Version
-    Selection](module#version-selection).
+    requested the new version if the reason was [Minimal Version Selection](/versions/8.2.1/external/module#version-selection).
 
 *   `--include_unused` *default: "false"*: Include in the output graph the
     modules which were originally present in the dependency graph, but became
@@ -192,7 +189,7 @@ use_repo(toolchains, my_jdk="remotejdk17_linux")
   

     
       

-        Graph Before Resolution
+        Graph Before Resolution
         
Graph Before Resolution

       

 {/* digraph mygraph {
@@ -222,7 +219,7 @@ use_repo(toolchains, my_jdk="remotejdk17_linux")
     		
     
       

-        Graph After Resolution
+        Graph After Resolution
        
Graph After Resolution

       

 {/* digraph mygraph {
diff --git a/versions/8.2.1/external/module.mdx b/versions/8.2.1/external/module.mdx
index 018ac455..b4d9906c 100644
--- a/versions/8.2.1/external/module.mdx
+++ b/versions/8.2.1/external/module.mdx
@@ -122,8 +122,7 @@ serves multiple purposes:
     version, regardless of which versions of the dependency are requested in the
     dependency graph.
 *   With the `registry` attribute, you can force this dependency to come from a
-    specific registry, instead of following the normal [registry
-    selection](/versions/8.2.1/external/registry#selecting_registries) process.
+    specific registry, instead of following the normal [registry selection](/versions/8.2.1/external/registry#selecting_registries) process.
 *   With the `patch*` attributes, you can specify a set of patches to apply to
     the downloaded module.
 
@@ -176,13 +175,11 @@ With `bazel_dep`, you can define repos that represent other Bazel modules.
 Sometimes there is a need to define a repo that does _not_ represent a Bazel
 module; for example, one that contains a plain JSON file to be read as data.
 
-In this case, you could use the [`use_repo_rule`
-directive](/versions/8.2.1/rules/lib/globals/module#use_repo_rule) to directly define a repo
+In this case, you could use the [`use_repo_rule` directive](/versions/8.2.1/rules/lib/globals/module#use_repo_rule) to directly define a repo
 by invoking a repo rule. This repo will only be visible to the module it's
 defined in.
 
-Under the hood, this is implemented using the same mechanism as [module
-extensions](/versions/8.2.1/external/extension), which lets you define repos with more
+Under the hood, this is implemented using the same mechanism as [module extensions](/versions/8.2.1/external/extension), which lets you define repos with more
 flexibility.
 
 ## Repository names and strict deps
diff --git a/versions/8.2.1/external/overview.mdx b/versions/8.2.1/external/overview.mdx
index b92fbd95..5e9b58a6 100644
--- a/versions/8.2.1/external/overview.mdx
+++ b/versions/8.2.1/external/overview.mdx
@@ -128,8 +128,7 @@ for all build targets inside the repo.
 
 The syntax of a `REPO.bazel` file is similar to `BUILD` files, except that no
 `load` statements are supported, and only a single function, `repo()`, is
-available. `repo()` takes the same arguments as the [`package()`
-function](/versions/8.2.1/reference/be/functions#package) in `BUILD` files; whereas `package()`
+available. `repo()` takes the same arguments as the [`package()` function](/versions/8.2.1/reference/be/functions#package) in `BUILD` files; whereas `package()`
 specifies common attributes for all build targets inside the package, `repo()`
 analogously does so for all build targets inside the repo.
 
@@ -163,8 +162,7 @@ bazel_dep(name = "protobuf", version = "3.19.0")
 ```
 
 A module must only list its direct dependencies, which Bzlmod looks up in a
-[Bazel registry](/versions/8.2.1/external/registry) — by default, the [Bazel Central
-Registry](https://bcr.bazel.build/). The registry provides the
+[Bazel registry](/versions/8.2.1/external/registry) — by default, the [Bazel Central Registry](https://bcr.bazel.build/). The registry provides the
 dependencies' `MODULE.bazel` files, which allows Bazel to discover the entire
 transitive dependency graph before performing version resolution.
 
@@ -235,5 +233,4 @@ many pain points, including:
         `B` and `C`; `B` and `C` both depend on different versions of `D`).
 
 Due to the shortcomings of WORKSPACE, Bzlmod is going to replace the legacy
-WORKSPACE system in future Bazel releases. Please read the [Bzlmod migration
-guide](/versions/8.2.1/external/migration) on how to migrate to Bzlmod.
+WORKSPACE system in future Bazel releases. Please read the [Bzlmod migration guide](/versions/8.2.1/external/migration) on how to migrate to Bzlmod.
diff --git a/versions/8.2.1/external/registry.mdx b/versions/8.2.1/external/registry.mdx
index 0fb17eaa..26a90821 100644
--- a/versions/8.2.1/external/registry.mdx
+++ b/versions/8.2.1/external/registry.mdx
@@ -42,8 +42,7 @@ An index registry must follow the format below:
             project
         *   `versions`: A list of all the versions of this module to be found in
             this registry
-        *   `yanked_versions`: A map of [*yanked*
-            versions](/versions/8.2.1/external/module#yanked_versions) of this module. The keys
+        *   `yanked_versions`: A map of [*yanked* versions](/versions/8.2.1/external/module#yanked_versions) of this module. The keys
             should be versions to yank and the values should be descriptions of
             why the version is yanked, ideally containing a link to more
             information
@@ -54,8 +53,7 @@ An index registry must follow the format below:
         *   The default type is "archive", representing an `http_archive` repo,
             with the following fields:
             *   `url`: The URL of the source archive
-            *   `integrity`: The [Subresource
-                Integrity](https://w3c.github.io/webappsec-subresource-integrity/#integrity-metadata-description)
+            *   `integrity`: The [Subresource Integrity](https://w3c.github.io/webappsec-subresource-integrity/#integrity-metadata-description)
                 checksum of the archive
             *   `strip_prefix`: A directory prefix to strip when extracting the
                 source archive
@@ -103,8 +101,7 @@ You can browse its contents using the web frontend at
 https://registry.bazel.build/.
 
 The Bazel community maintains the BCR, and contributors are welcome to submit
-pull requests. See the [BCR contribution
-guidelines](https://github.com/bazelbuild/bazel-central-registry/blob/main/docs/README.md).
+pull requests. See the [BCR contribution guidelines](https://github.com/bazelbuild/bazel-central-registry/blob/main/docs/README.md).
 
 In addition to following the format of a normal index registry, the BCR requires
 a `presubmit.yml` file for each module version
diff --git a/versions/8.2.1/external/vendor.mdx b/versions/8.2.1/external/vendor.mdx
index a8841098..f6fe5d62 100644
--- a/versions/8.2.1/external/vendor.mdx
+++ b/versions/8.2.1/external/vendor.mdx
@@ -23,9 +23,7 @@ absolute path.
 ## Vendor a specific external repository {#vendor-specific-repository}
 
 You can use the `vendor` command with the `--repo` flag to specify which repo
-to vendor, it accepts both [canonical repo
-name](/versions/8.2.1/external/overview#canonical-repo-name) and [apparent repo
-name](/versions/8.2.1/external/overview#apparent-repo-name).
+to vendor, it accepts both [canonical repo name](/versions/8.2.1/external/overview#canonical-repo-name) and [apparent repo name](/versions/8.2.1/external/overview#apparent-repo-name).
 
 For example, running:
 
diff --git a/versions/8.2.1/help.mdx b/versions/8.2.1/help.mdx
index 19357612..3ebe61af 100644
--- a/versions/8.2.1/help.mdx
+++ b/versions/8.2.1/help.mdx
@@ -46,5 +46,4 @@ what level of support Bazel provides.
 
 ## File a bug {#file-bug}
 
-If you encounter a bug or want to request a feature, file a [GitHub
-Issue](https://github.com/bazelbuild/bazel/issues).
+If you encounter a bug or want to request a feature, file a [GitHub Issue](https://github.com/bazelbuild/bazel/issues).
diff --git a/versions/8.2.1/images/about.svg b/versions/8.2.1/images/about.svg
new file mode 100644
index 00000000..f927298f
--- /dev/null
+++ b/versions/8.2.1/images/about.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/8.2.1/images/basics.svg b/versions/8.2.1/images/basics.svg
new file mode 100644
index 00000000..013ec519
--- /dev/null
+++ b/versions/8.2.1/images/basics.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/8.2.1/images/bazel_hero.svg b/versions/8.2.1/images/bazel_hero.svg
new file mode 100644
index 00000000..c48714d0
--- /dev/null
+++ b/versions/8.2.1/images/bazel_hero.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/8.2.1/images/community.svg b/versions/8.2.1/images/community.svg
new file mode 100644
index 00000000..29f87a76
--- /dev/null
+++ b/versions/8.2.1/images/community.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/8.2.1/images/distributed-build-remote-cache.png b/versions/8.2.1/images/distributed-build-remote-cache.png
new file mode 100644
index 00000000..99d8a915
Binary files /dev/null and b/versions/8.2.1/images/distributed-build-remote-cache.png differ
diff --git a/versions/8.2.1/images/essential_guide.svg b/versions/8.2.1/images/essential_guide.svg
new file mode 100644
index 00000000..4ee63ae9
--- /dev/null
+++ b/versions/8.2.1/images/essential_guide.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/8.2.1/images/essential_reference.svg b/versions/8.2.1/images/essential_reference.svg
new file mode 100644
index 00000000..4d29a8d5
--- /dev/null
+++ b/versions/8.2.1/images/essential_reference.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/8.2.1/images/essential_start.svg b/versions/8.2.1/images/essential_start.svg
new file mode 100644
index 00000000..c8f48f84
--- /dev/null
+++ b/versions/8.2.1/images/essential_start.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/8.2.1/images/extend.svg b/versions/8.2.1/images/extend.svg
new file mode 100644
index 00000000..77b2dd97
--- /dev/null
+++ b/versions/8.2.1/images/extend.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/8.2.1/images/guide.svg b/versions/8.2.1/images/guide.svg
new file mode 100644
index 00000000..23a5d35a
--- /dev/null
+++ b/versions/8.2.1/images/guide.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/8.2.1/images/high-level-build-system.png b/versions/8.2.1/images/high-level-build-system.png
new file mode 100644
index 00000000..462717fa
Binary files /dev/null and b/versions/8.2.1/images/high-level-build-system.png differ
diff --git a/versions/8.2.1/images/new_1.svg b/versions/8.2.1/images/new_1.svg
new file mode 100644
index 00000000..c4cd9dfd
--- /dev/null
+++ b/versions/8.2.1/images/new_1.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/8.2.1/images/new_2.svg b/versions/8.2.1/images/new_2.svg
new file mode 100644
index 00000000..c6b7021b
--- /dev/null
+++ b/versions/8.2.1/images/new_2.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/8.2.1/images/new_3.svg b/versions/8.2.1/images/new_3.svg
new file mode 100644
index 00000000..c2afb4ac
--- /dev/null
+++ b/versions/8.2.1/images/new_3.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/8.2.1/images/placeholder.png b/versions/8.2.1/images/placeholder.png
new file mode 100644
index 00000000..54f1fa0e
Binary files /dev/null and b/versions/8.2.1/images/placeholder.png differ
diff --git a/versions/8.2.1/images/reference.svg b/versions/8.2.1/images/reference.svg
new file mode 100644
index 00000000..7bbc9bea
--- /dev/null
+++ b/versions/8.2.1/images/reference.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/8.2.1/images/release_notes.svg b/versions/8.2.1/images/release_notes.svg
new file mode 100644
index 00000000..8a2e8b56
--- /dev/null
+++ b/versions/8.2.1/images/release_notes.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/8.2.1/images/remote-execution-system.png b/versions/8.2.1/images/remote-execution-system.png
new file mode 100644
index 00000000..8152fc0c
Binary files /dev/null and b/versions/8.2.1/images/remote-execution-system.png differ
diff --git a/versions/8.2.1/images/start.svg b/versions/8.2.1/images/start.svg
new file mode 100644
index 00000000..3bcebd7b
--- /dev/null
+++ b/versions/8.2.1/images/start.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/8.2.1/images/task-dependencies.png b/versions/8.2.1/images/task-dependencies.png
new file mode 100644
index 00000000..ae1f9c51
Binary files /dev/null and b/versions/8.2.1/images/task-dependencies.png differ
diff --git a/versions/8.2.1/images/test.png b/versions/8.2.1/images/test.png
new file mode 100644
index 00000000..243939da
Binary files /dev/null and b/versions/8.2.1/images/test.png differ
diff --git a/versions/8.2.1/images/transitive-dependencies.png b/versions/8.2.1/images/transitive-dependencies.png
new file mode 100644
index 00000000..ec641a08
Binary files /dev/null and b/versions/8.2.1/images/transitive-dependencies.png differ
diff --git a/versions/8.2.1/images/trunk-logo-dark.svg b/versions/8.2.1/images/trunk-logo-dark.svg
new file mode 100644
index 00000000..f25940af
--- /dev/null
+++ b/versions/8.2.1/images/trunk-logo-dark.svg
@@ -0,0 +1,22 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/versions/8.2.1/images/why_faq.svg b/versions/8.2.1/images/why_faq.svg
new file mode 100644
index 00000000..afec3f8f
--- /dev/null
+++ b/versions/8.2.1/images/why_faq.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/8.2.1/images/why_overview.svg b/versions/8.2.1/images/why_overview.svg
new file mode 100644
index 00000000..c10c363c
--- /dev/null
+++ b/versions/8.2.1/images/why_overview.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/8.2.1/images/why_vision.svg b/versions/8.2.1/images/why_vision.svg
new file mode 100644
index 00000000..739e415f
--- /dev/null
+++ b/versions/8.2.1/images/why_vision.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/8.2.1/install/bazelisk.mdx b/versions/8.2.1/install/bazelisk.mdx
index ecf32ae9..2fbcb775 100644
--- a/versions/8.2.1/install/bazelisk.mdx
+++ b/versions/8.2.1/install/bazelisk.mdx
@@ -16,8 +16,7 @@ For more details, see
 ## Updating Bazel
 
 Bazel has a [backward compatibility policy](/versions/8.2.1/release/backward-compatibility)
-(see [guidance for rolling out incompatible
-changes](/versions/8.2.1/contribute/breaking-changes) if you
+(see [guidance for rolling out incompatible changes](/versions/8.2.1/contribute/breaking-changes) if you
 are the author of one). That page summarizes best practices on how to test and
 migrate your project with upcoming incompatible changes and how to provide
 feedback to the incompatible change authors.
diff --git a/versions/8.2.1/install/compile-source.mdx b/versions/8.2.1/install/compile-source.mdx
index 2168fc33..b36af539 100644
--- a/versions/8.2.1/install/compile-source.mdx
+++ b/versions/8.2.1/install/compile-source.mdx
@@ -45,8 +45,7 @@ it by typing `bazel` in a terminal.
 
 **Reason**: To build Bazel from a GitHub source tree, you need a pre-existing
 Bazel binary. You can install one from a package manager or download one from
-GitHub. See [Installing Bazel](/versions/8.2.1/install). (Or you can [build from
-scratch (bootstrap)](#bootstrap-bazel).)
+GitHub. See [Installing Bazel](/versions/8.2.1/install). (Or you can [build from scratch (bootstrap)](#bootstrap-bazel).)
 
 **Troubleshooting**:
 
@@ -239,8 +238,7 @@ For instructions for Unix-like systems, see
     ```
 
 *   **The Visual C++ compiler.** Install the Visual C++ compiler either as part
-    of Visual Studio 2015 or newer, or by installing the latest [Build Tools
-    for Visual Studio 2017](https://aka.ms/BuildTools).
+    of Visual Studio 2015 or newer, or by installing the latest [Build Tools for Visual Studio 2017](https://aka.ms/BuildTools).
 
 *   **JDK.** Version 21 is required.
 
diff --git a/versions/8.2.1/install/ide.mdx b/versions/8.2.1/install/ide.mdx
index 561d0e02..c42d95e9 100644
--- a/versions/8.2.1/install/ide.mdx
+++ b/versions/8.2.1/install/ide.mdx
@@ -38,10 +38,8 @@ To install, go to the IDE's plugin browser and search for `Bazel`.
 To manually install older versions, download the zip files from JetBrains'
 Plugin Repository and install the zip file from the IDE's plugin browser:
 
-*  [Android Studio
-   plugin](https://plugins.jetbrains.com/plugin/9185-android-studio-with-bazel)
-*  [IntelliJ
-   plugin](https://plugins.jetbrains.com/plugin/8609-intellij-with-bazel)
+*  [Android Studio plugin](https://plugins.jetbrains.com/plugin/9185-android-studio-with-bazel)
+*  [IntelliJ plugin](https://plugins.jetbrains.com/plugin/8609-intellij-with-bazel)
 *  [CLion plugin](https://plugins.jetbrains.com/plugin/9554-clion-with-bazel)
 
 ### Xcode {#xcode}
@@ -61,8 +59,7 @@ Features:
 * Starlark debugger for `.bzl` files during a build (set breakpoints, step
   through code, inspect variables, and so on)
 
-Find [the plugin on the Visual Studio
-marketplace](https://marketplace.visualstudio.com/items?itemName=BazelBuild.vscode-bazel).
+Find [the plugin on the Visual Studio marketplace](https://marketplace.visualstudio.com/items?itemName=BazelBuild.vscode-bazel).
 The plugin is [open source](https://github.com/bazelbuild/vscode-bazel).
 
 See also: [Autocomplete for Source Code](#autocomplete-for-source-code)
@@ -82,8 +79,7 @@ See also: [Autocomplete for Source Code](#autocomplete-for-source-code)
 
 ### Emacs {#emacs}
 
-See [`bazelbuild/bazel-emacs-mode` on
-GitHub](https://github.com/bazelbuild/emacs-bazel-mode)
+See [`bazelbuild/bazel-emacs-mode` on GitHub](https://github.com/bazelbuild/emacs-bazel-mode)
 
 See also: [Autocomplete for Source Code](#autocomplete-for-source-code)
 
@@ -115,6 +111,5 @@ tool for building Bazel targets when source files change.
 
 ## Building your own IDE plugin {#build-own-plugin}
 
-Read the [**IDE support** blog
-post](https://blog.bazel.build/2016/06/10/ide-support.html) to learn more about
+Read the [**IDE support** blog post](https://blog.bazel.build/2016/06/10/ide-support.html) to learn more about
 the Bazel APIs to use when building an IDE plugin.
diff --git a/versions/8.2.1/install/images/bazelisk.svg b/versions/8.2.1/install/images/bazelisk.svg
new file mode 100644
index 00000000..c0ae9f54
--- /dev/null
+++ b/versions/8.2.1/install/images/bazelisk.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/8.2.1/install/images/cli.svg b/versions/8.2.1/install/images/cli.svg
new file mode 100644
index 00000000..01119280
--- /dev/null
+++ b/versions/8.2.1/install/images/cli.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/8.2.1/install/images/docker.svg b/versions/8.2.1/install/images/docker.svg
new file mode 100644
index 00000000..21190ce0
--- /dev/null
+++ b/versions/8.2.1/install/images/docker.svg
@@ -0,0 +1,6 @@
+
\ No newline at end of file
diff --git a/versions/8.2.1/install/images/github.svg b/versions/8.2.1/install/images/github.svg
new file mode 100644
index 00000000..aa05db9c
--- /dev/null
+++ b/versions/8.2.1/install/images/github.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/8.2.1/install/images/install.svg b/versions/8.2.1/install/images/install.svg
new file mode 100644
index 00000000..ae080865
--- /dev/null
+++ b/versions/8.2.1/install/images/install.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/8.2.1/install/images/mac.svg b/versions/8.2.1/install/images/mac.svg
new file mode 100644
index 00000000..3ee4fe28
--- /dev/null
+++ b/versions/8.2.1/install/images/mac.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/8.2.1/install/images/redhat.svg b/versions/8.2.1/install/images/redhat.svg
new file mode 100644
index 00000000..078b3387
--- /dev/null
+++ b/versions/8.2.1/install/images/redhat.svg
@@ -0,0 +1,69 @@
+
+
+  
+    
+      
+        image/svg+xml
+        
+        
+      
+    
+  
+  
+  
+    
+  
+  
+  
+
diff --git a/versions/8.2.1/install/images/suse.png b/versions/8.2.1/install/images/suse.png
new file mode 100644
index 00000000..6435b689
Binary files /dev/null and b/versions/8.2.1/install/images/suse.png differ
diff --git a/versions/8.2.1/install/images/tune.svg b/versions/8.2.1/install/images/tune.svg
new file mode 100644
index 00000000..8d7d63cb
--- /dev/null
+++ b/versions/8.2.1/install/images/tune.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/8.2.1/install/images/ubuntu.svg b/versions/8.2.1/install/images/ubuntu.svg
new file mode 100644
index 00000000..f217bc8d
--- /dev/null
+++ b/versions/8.2.1/install/images/ubuntu.svg
@@ -0,0 +1,8 @@
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/versions/8.2.1/install/images/windows.svg b/versions/8.2.1/install/images/windows.svg
new file mode 100644
index 00000000..120b0190
--- /dev/null
+++ b/versions/8.2.1/install/images/windows.svg
@@ -0,0 +1,5 @@
+
+
+
+
+
\ No newline at end of file
diff --git a/versions/8.2.1/install/windows.mdx b/versions/8.2.1/install/windows.mdx
index e1435f36..b75163a1 100644
--- a/versions/8.2.1/install/windows.mdx
+++ b/versions/8.2.1/install/windows.mdx
@@ -31,8 +31,7 @@ To check your Windows version:
 
 Alternatively you can:
 
-*   [Download the Bazel binary (`bazel-version-windows-x86_64.exe`) from
- GitHub](https://github.com/bazelbuild/bazel/releases).
+*   [Download the Bazel binary (`bazel-version-windows-x86_64.exe`) from GitHub](https://github.com/bazelbuild/bazel/releases).
 *   [Install Bazel from Chocolatey](#chocolately)
 *   [Install Bazel from Scoop](#scoop)
 *   [Build Bazel from source](/versions/8.2.1/install/compile-source)
@@ -208,8 +207,7 @@ If that doesn't help:
     its dependencies, such as the MSYS2 shell. This will not install Visual C++
     though.
 
-See [Chocolatey installation and package maintenance
-guide](/versions/8.2.1/contribute/windows-chocolatey-maintenance) for more
+See [Chocolatey installation and package maintenance guide](/versions/8.2.1/contribute/windows-chocolatey-maintenance) for more
 information about the Chocolatey package.
 
 ### Using Scoop {#scoop}
@@ -226,8 +224,7 @@ information about the Chocolatey package.
     scoop install bazel
     ```
 
-See [Scoop installation and package maintenance
-guide](/versions/8.2.1/contribute/windows-scoop-maintenance) for more
+See [Scoop installation and package maintenance guide](/versions/8.2.1/contribute/windows-scoop-maintenance) for more
 information about the Scoop package.
 
 ### Build from source {#build-from-source}
diff --git a/versions/8.2.1/migrate/maven.mdx b/versions/8.2.1/migrate/maven.mdx
index 3b91aec4..fc575c0c 100644
--- a/versions/8.2.1/migrate/maven.mdx
+++ b/versions/8.2.1/migrate/maven.mdx
@@ -19,8 +19,7 @@ directly run by Bazel since there's no Maven compatibility layer.
 ## Before you begin {#before-you-begin}
 
 *   [Install Bazel](/versions/8.2.1/install) if it's not yet installed.
-*   If you're new to Bazel, go through the tutorial [Introduction to Bazel:
-    Build Java](/versions/8.2.1/start/java) before you start migrating. The tutorial explains
+*   If you're new to Bazel, go through the tutorial [Introduction to Bazel: Build Java](/versions/8.2.1/start/java) before you start migrating. The tutorial explains
     Bazel's concepts, structure, and label syntax.
 
 ## Differences between Maven and Bazel {#dif-maven-bazel}
@@ -44,8 +43,7 @@ The steps below describe how to migrate your project to Bazel:
 3.  [Create more BUILD files](#3-build)
 4.  [Build using Bazel](#4-build)
 
-Examples below come from a migration of the [Guava
-project](https://github.com/google/guava) from Maven to Bazel. The
+Examples below come from a migration of the [Guava project](https://github.com/google/guava) from Maven to Bazel. The
 Guava project used is release `v31.1`. The examples using Guava do not walk
 through each step in the migration, but they do show the files and contents that
 are generated or added manually for the migration.
@@ -63,14 +61,12 @@ has no external dependencies, this file can be empty.
 If your project depends on files or packages that are not in one of the
 project's directories, specify these external dependencies in the MODULE.bazel
 file. You can use `rules_jvm_external` to manage dependencies from Maven. For
-instructions about using this ruleset, see [the
-README](https://github.com/bazelbuild/rules_jvm_external/#rules_jvm_external)
+instructions about using this ruleset, see [the README](https://github.com/bazelbuild/rules_jvm_external/#rules_jvm_external)
 .
 
 #### Guava project example: external dependencies {#guava-1}
 
-You can list the external dependencies of the [Guava
-project](https://github.com/google/guava) with the
+You can list the external dependencies of the [Guava project](https://github.com/google/guava) with the
 [`rules_jvm_external`](https://github.com/bazelbuild/rules_jvm_external)
 ruleset.
 
@@ -164,8 +160,7 @@ your build by adding more `BUILD` files with more granular targets.
             *   `resources`: Use globbing to list all resources in your project.
             *   `deps`: You need to determine which external dependencies your
                 project needs.
-        *   Take a look at the [example below of this top-level BUILD
-            file](#guava-2) from the migration of the Guava project.
+        *   Take a look at the [example below of this top-level BUILD file](#guava-2) from the migration of the Guava project.
 
 3.  Now that you have a `BUILD` file at the root of your project, build your
     project to ensure that it works. On the command line, from your workspace
diff --git a/versions/8.2.1/migrate/xcode.mdx b/versions/8.2.1/migrate/xcode.mdx
index 6e57a42a..ded70688 100644
--- a/versions/8.2.1/migrate/xcode.mdx
+++ b/versions/8.2.1/migrate/xcode.mdx
@@ -32,8 +32,7 @@ Before you begin, do the following:
 
 1.  [Install Bazel](/versions/8.2.1/install) if you have not already done so.
 
-2.  If you're not familiar with Bazel and its concepts, complete the [iOS app
-    tutorial](/versions/8.2.1/start/ios-app)). You should understand the Bazel workspace,
+2.  If you're not familiar with Bazel and its concepts, complete the [iOS app tutorial](/versions/8.2.1/start/ios-app)). You should understand the Bazel workspace,
     including the `MODULE.bazel` and `BUILD` files, as well as the concepts of
     targets, build rules, and Bazel packages.
 
@@ -44,8 +43,7 @@ Before you begin, do the following:
 Unlike Xcode, Bazel requires you to explicitly declare all dependencies for
 every target in the `BUILD` file.
 
-For more information on external dependencies, see [Working with external
-dependencies](/versions/8.2.1/docs/external).
+For more information on external dependencies, see [Working with external dependencies](/versions/8.2.1/docs/external).
 
 ## Build or test an Xcode project with Bazel {#build-xcode-project}
 
@@ -84,8 +82,7 @@ Note: Place the project source code within the directory tree containing the
 
 To integrate SwiftPM dependencies into the Bazel workspace with
 [swift_bazel](https://github.com/cgrindel/swift_bazel), you must
-convert them into Bazel packages as described in the [following
-tutorial](https://chuckgrindel.com/swift-packages-in-bazel-using-swift_bazel/)
+convert them into Bazel packages as described in the [following tutorial](https://chuckgrindel.com/swift-packages-in-bazel-using-swift_bazel/)
 .
 
 Note: SwiftPM support is a manual process with many variables. SwiftPM
@@ -103,8 +100,7 @@ initial build of the project as follows:
 *   [Step 3b: (Optional) Add the test target(s)](#step-3b-optional-add-the-test-target-s)
 *   [Step 3c: Add the library target(s)](#step-3c-add-the-library-target-s)
 
-**Tip:** To learn more about packages and other Bazel concepts, see [Workspaces,
-packages, and targets](/versions/8.2.1/concepts/build-ref).
+**Tip:** To learn more about packages and other Bazel concepts, see [Workspaces, packages, and targets](/versions/8.2.1/concepts/build-ref).
 
 #### Step 3a: Add the application target {#add-app-target}
 
@@ -132,8 +128,7 @@ In the target, specify the following at the minimum:
 
 #### Step 3b: (Optional) Add the test target(s) {#add-test-target}
 
-Bazel's [Apple build
-rules](https://github.com/bazelbuild/rules_apple) support running
+Bazel's [Apple build rules](https://github.com/bazelbuild/rules_apple) support running
 unit and UI tests on all Apple platforms. Add test targets as follows:
 
 *   [`macos_unit_test`](https://github.com/bazelbuild/rules_apple/blob/master/doc/rules-macos.md#macos_unit_test)
@@ -181,8 +176,7 @@ all sources and/or headers of a certain type. Use it carefully as it might
 include files you do not want Bazel to build.
 
 You can browse existing examples for various types of applications directly in
-the [rules_apple examples
-directory](https://github.com/bazelbuild/rules_apple/tree/master/examples/). For
+the [rules_apple examples directory](https://github.com/bazelbuild/rules_apple/tree/master/examples/). For
 example:
 
 *   [macOS application targets](https://github.com/bazelbuild/rules_apple/tree/master/examples/macos)
@@ -191,8 +185,7 @@ example:
 
 *   [Multi platform applications (macOS, iOS, watchOS, tvOS)](https://github.com/bazelbuild/rules_apple/tree/master/examples/multi_platform)
 
-For more information on build rules, see [Apple Rules for
-Bazel](https://github.com/bazelbuild/rules_apple).
+For more information on build rules, see [Apple Rules for Bazel](https://github.com/bazelbuild/rules_apple).
 
 At this point, it is a good idea to test the build:
 
diff --git a/versions/8.2.1/query/cquery.mdx b/versions/8.2.1/query/cquery.mdx
index 53d20ee5..45a4d38d 100644
--- a/versions/8.2.1/query/cquery.mdx
+++ b/versions/8.2.1/query/cquery.mdx
@@ -6,8 +6,7 @@ title: ' Configurable Query (cquery)'
 [`select()`](/versions/8.2.1/docs/configurable-attributes) and build options' effects on the build
 graph.
 
-It achieves this by running over the results of Bazel's [analysis
-phase](/versions/8.2.1/extending/concepts#evaluation-model),
+It achieves this by running over the results of Bazel's [analysis phase](/versions/8.2.1/extending/concepts#evaluation-model),
 which integrates these effects. `query`, by contrast, runs over the results of
 Bazel's loading phase, before options are evaluated.
 
@@ -137,8 +136,7 @@ $ bazel cquery //foo --universe_scope=//foo,//genrule_with_foo_as_tool
 If you want to precisely declare which instance to query over, use
 the [`config`](#config) function.
 
-See `query`'s [target pattern
-documentation](/versions/8.2.1/query/language#target-patterns) for more information on target patterns.
+See `query`'s [target pattern documentation](/versions/8.2.1/query/language#target-patterns) for more information on target patterns.
 
 ## Functions {#functions}
 
diff --git a/versions/8.2.1/query/images/query_graph1.png b/versions/8.2.1/query/images/query_graph1.png
new file mode 100644
index 00000000..7bc9a61a
Binary files /dev/null and b/versions/8.2.1/query/images/query_graph1.png differ
diff --git a/versions/8.2.1/query/images/query_graph2.png b/versions/8.2.1/query/images/query_graph2.png
new file mode 100644
index 00000000..a0da22ff
Binary files /dev/null and b/versions/8.2.1/query/images/query_graph2.png differ
diff --git a/versions/8.2.1/query/images/query_graph3.png b/versions/8.2.1/query/images/query_graph3.png
new file mode 100644
index 00000000..4418f193
Binary files /dev/null and b/versions/8.2.1/query/images/query_graph3.png differ
diff --git a/versions/8.2.1/query/language.mdx b/versions/8.2.1/query/language.mdx
index 11272fca..8a5964e7 100644
--- a/versions/8.2.1/query/language.mdx
+++ b/versions/8.2.1/query/language.mdx
@@ -1105,8 +1105,7 @@ is being used.
 
 ### On the ordering of results {#results-ordering}
 
-Although query expressions always follow the "[law of
-conservation of graph order](#graph-order)", _presenting_ the results may be done
+Although query expressions always follow the "[law of conservation of graph order](#graph-order)", _presenting_ the results may be done
 in either a dependency-ordered or unordered manner. This does **not**
 influence the targets in the result set or how the query is computed. It only
 affects how the results are printed to stdout. Moreover, nodes that are
@@ -1252,8 +1251,7 @@ and `maxrank` output formats print the labels of each
 target in the resulting graph, but instead of appearing in
 topological order, they appear in rank order, preceded by their
 rank number. These are unaffected by the result ordering
-`--[no]order_results` flag (see [notes on
-the ordering of results](#result-order)).
+`--[no]order_results` flag (see [notes on the ordering of results](#result-order)).
 
 There are two variants of this format: `minrank` ranks
 each node by the length of the shortest path from a root node to it.
diff --git a/versions/8.2.1/query/quickstart.mdx b/versions/8.2.1/query/quickstart.mdx
index 35151635..3737b7c8 100644
--- a/versions/8.2.1/query/quickstart.mdx
+++ b/versions/8.2.1/query/quickstart.mdx
@@ -205,7 +205,7 @@ dot -Tpng < graph.in > graph.png
 ```
 If you open up `graph.png`, you should see something like this. The graph below has been simplified to make the essential path details clearer in this guide.
 
-![Diagram showing a relationship from cafe to chef to the dishes: pizza and mac and cheese which diverges into the separate ingredients: cheese, tomatoes, dough, and macaroni.](images/query_graph1.png "Dependency graph")
+![Diagram showing a relationship from cafe to chef to the dishes: pizza and mac and cheese which diverges into the separate ingredients: cheese, tomatoes, dough, and macaroni.](/versions/8.2.1/query/images/query_graph1.png "Dependency graph")
 
 This helps when you want to see the outputs of the different query functions throughout this guide.
 
@@ -421,7 +421,7 @@ bazel query --noimplicit_deps 'deps(:runner)' --output graph > graph2.in
 dot -Tpng < graph2.in > graph2.png
 ```
 
-[![The same graph as the first one except now there is a spoke stemming from the chef target with smoothie which leads to banana and strawberry](images/query_graph2.png "Updated dependency graph")](images/query_graph2.png)
+[![The same graph as the first one except now there is a spoke stemming from the chef target with smoothie which leads to banana and strawberry](/versions/8.2.1/query/images/query_graph2.png "Updated dependency graph")](/query/images/query_graph2.png)
 
 Looking at `graph2.png`, you can see that `Smoothie` has no shared dependencies with other dishes but is just another target that the `Chef` relies on.
 
@@ -465,7 +465,7 @@ bazel query "allpaths(//src/main/java/com/example/restaurant/..., //src/main/jav
 //src/main/java/com/example/restaurant:chef
 ```
 
-![Output path of cafe to chef to pizza,mac and cheese to cheese](images/query_graph3.png "Output path for dependency")
+![Output path of cafe to chef to pizza,mac and cheese to cheese](/versions/8.2.1/query/images/query_graph3.png "Output path for dependency")
 
 The output of `allpaths()` is a little harder to read as it is a flattened list of the dependencies. Visualizing this graph using Graphviz makes the relationship clearer to understand.
 
diff --git a/versions/8.2.1/reference/be/c-cpp.mdx b/versions/8.2.1/reference/be/c-cpp.mdx
index 6b792d65..def54e7e 100644
--- a/versions/8.2.1/reference/be/c-cpp.mdx
+++ b/versions/8.2.1/reference/be/c-cpp.mdx
@@ -61,7 +61,7 @@ be `main`.
 | `hdrs_check` | String; default is `""` Deprecated, no-op. |
 | `includes` | List of strings; default is `[]` List of include dirs to be added to the compile line. Subject to ["Make variable"](/versions/8.2.1/reference/be/make-variables) substitution. Each string is prepended with the package path and passed to the C++ toolchain for expansion via the "include\_paths" CROSSTOOL feature. A toolchain running on a POSIX system with typical feature definitions will produce `-isystem path_to_package/include_entry`. This should only be used for third-party libraries that do not conform to the Google style of writing #include statements. Unlike [COPTS](#cc_binary.copts), these flags are added for this rule and every rule that depends on it. (Note: not the rules it depends upon!) Be very careful, since this may have far-reaching effects. When in doubt, add "-I" flags to [COPTS](#cc_binary.copts) instead. The added `include` paths will include generated files as well as files in the source tree. |
 | `link_extra_lib` | [Label](/versions/8.2.1/concepts/labels); default is `"@bazel_tools//tools/cpp:link_extra_lib"` Control linking of extra libraries. By default, C++ binaries are linked against `//tools/cpp:link_extra_lib`, which by default depends on the label flag `//tools/cpp:link_extra_libs`. Without setting the flag, this library is empty by default. Setting the label flag allows linking optional dependencies, such as overrides for weak symbols, interceptors for shared library functions, or special runtime libraries (for malloc replacements, prefer `malloc` or `--custom_malloc`). Setting this attribute to `None` disables this behaviour. |
-| `linkopts` | List of strings; default is `[]` Add these flags to the C++ linker command. Subject to ["Make" variable](make-variables) substitution, [Bourne shell tokenization](common-definitions#sh-tokenization) and [label expansion](common-definitions#label-expansion). Each string in this attribute is added to `LINKOPTS` before linking the binary target. Each element of this list that does not start with `$` or `-` is assumed to be the label of a target in `deps`. The list of files generated by that target is appended to the linker options. An error is reported if the label is invalid, or is not declared in `deps`. |
+| `linkopts` | List of strings; default is `[]` Add these flags to the C++ linker command. Subject to ["Make" variable](/versions/8.2.1/reference/be/make-variables) substitution, [Bourne shell tokenization](/versions/8.2.1/reference/be/common-definitions#sh-tokenization) and [label expansion](/versions/8.2.1/reference/be/common-definitions#label-expansion). Each string in this attribute is added to `LINKOPTS` before linking the binary target. Each element of this list that does not start with `$` or `-` is assumed to be the label of a target in `deps`. The list of files generated by that target is appended to the linker options. An error is reported if the label is invalid, or is not declared in `deps`. |
 | `linkshared` | Boolean; default is `False` Create a shared library. To enable this attribute, include `linkshared=True` in your rule. By default this option is off. The presence of this flag means that linking occurs with the `-shared` flag to `gcc`, and the resulting shared library is suitable for loading into for example a Java program. However, for build purposes it will never be linked into the dependent binary, as it is assumed that shared libraries built with a [cc\_binary](#cc_binary) rule are only loaded manually by other programs, so it should not be considered a substitute for the [cc\_library](#cc_library) rule. For sake of scalability we recommend avoiding this approach altogether and simply letting `java_library` depend on `cc_library` rules instead.  If you specify both `linkopts=['-static']` and `linkshared=True`, you get a single completely self-contained unit. If you specify both `linkstatic=True` and `linkshared=True`, you get a single, mostly self-contained unit. |
 | `linkstatic` | Boolean; default is `True` For [`cc_binary`](/versions/8.2.1/reference/be/c-cpp#cc_binary) and [`cc_test`](/versions/8.2.1/reference/be/c-cpp#cc_test): link the binary in static mode. For `cc_library.link_static`: see below. By default this option is on for `cc_binary` and off for the rest.  If enabled and this is a binary or test, this option tells the build tool to link in `.a`'s instead of `.so`'s for user libraries whenever possible. System libraries such as libc (but *not* the C/C++ runtime libraries, see below) are still linked dynamically, as are libraries for which there is no static library. So the resulting executable will still be dynamically linked, hence only *mostly* static.  There are really three different ways to link an executable:   * STATIC with fully\_static\_link feature, in which everything is linked statically;   e.g. "`gcc -static foo.o libbar.a libbaz.a -lm`".    This mode is enabled by specifying `fully_static_link` in the   [`features`](/versions/8.2.1/reference/be/common-definitions#features) attribute. * STATIC, in which all user libraries are linked statically (if a static   version is available), but where system libraries (excluding C/C++ runtime libraries)   are linked dynamically, e.g. "`gcc foo.o libfoo.a libbaz.a -lm`".    This mode is enabled by specifying `linkstatic=True`. * DYNAMIC, in which all libraries are linked dynamically (if a dynamic version is   available), e.g. "`gcc foo.o libfoo.so libbaz.so -lm`".    This mode is enabled by specifying `linkstatic=False`.   If the `linkstatic` attribute or `fully_static_link` in `features` is used outside of `//third_party` please include a comment near the rule to explain why.  The `linkstatic` attribute has a different meaning if used on a [`cc_library()`](/versions/8.2.1/reference/be/c-cpp#cc_library) rule. For a C++ library, `linkstatic=True` indicates that only static linking is allowed, so no `.so` will be produced. linkstatic=False does not prevent static libraries from being created. The attribute is meant to control the creation of dynamic libraries.  There should be very little code built with `linkstatic=False` in production. If `linkstatic=False`, then the build tool will create symlinks to depended-upon shared libraries in the `*.runfiles` area. |
 | `local_defines` | List of strings; default is `[]` List of defines to add to the compile line. Subject to ["Make" variable](/versions/8.2.1/reference/be/make-variables) substitution and [Bourne shell tokenization](/versions/8.2.1/reference/be/common-definitions#sh-tokenization). Each string, which must consist of a single Bourne shell token, is prepended with `-D` and added to the compile command line for this target, but not to its dependents. |
@@ -229,7 +229,7 @@ cc_import(
 | `alwayslink` | Boolean; default is `False` If 1, any binary that depends (directly or indirectly) on this C++ precompiled library will link in all the object files archived in the static library, even if some contain no symbols referenced by the binary. This is useful if your code isn't explicitly called by code in the binary, e.g., if your code registers to receive some callback provided by some service. If alwayslink doesn't work with VS 2017 on Windows, that is due to a [known issue](https://github.com/bazelbuild/bazel/issues/3949), please upgrade your VS 2017 to the latest version. |
 | `includes` | List of strings; default is `[]` List of include dirs to be added to the compile line. Subject to ["Make variable"](/versions/8.2.1/reference/be/make-variables) substitution. Each string is prepended with the package path and passed to the C++ toolchain for expansion via the "include\_paths" CROSSTOOL feature. A toolchain running on a POSIX system with typical feature definitions will produce `-isystem path_to_package/include_entry`. This should only be used for third-party libraries that do not conform to the Google style of writing #include statements. Unlike [COPTS](#cc_binary.copts), these flags are added for this rule and every rule that depends on it. (Note: not the rules it depends upon!) Be very careful, since this may have far-reaching effects. When in doubt, add "-I" flags to [COPTS](#cc_binary.copts) instead. The default `include` path doesn't include generated files. If you need to `#include` a generated header file, list it in the `srcs`. |
 | `interface_library` | [Label](/versions/8.2.1/concepts/labels); default is `None` A single interface library for linking the shared library. Permitted file types: `.ifso`, `.tbd`, `.lib`, `.so` or `.dylib` |
-| `linkopts` | List of strings; default is `[]` Add these flags to the C++ linker command. Subject to ["Make" variable](make-variables) substitution, [Bourne shell tokenization](common-definitions#sh-tokenization) and [label expansion](common-definitions#label-expansion). Each string in this attribute is added to `LINKOPTS` before linking the binary target. Each element of this list that does not start with `$` or `-` is assumed to be the label of a target in `deps`. The list of files generated by that target is appended to the linker options. An error is reported if the label is invalid, or is not declared in `deps`. |
+| `linkopts` | List of strings; default is `[]` Add these flags to the C++ linker command. Subject to ["Make" variable](/versions/8.2.1/reference/be/make-variables) substitution, [Bourne shell tokenization](/versions/8.2.1/reference/be/common-definitions#sh-tokenization) and [label expansion](/versions/8.2.1/reference/be/common-definitions#label-expansion). Each string in this attribute is added to `LINKOPTS` before linking the binary target. Each element of this list that does not start with `$` or `-` is assumed to be the label of a target in `deps`. The list of files generated by that target is appended to the linker options. An error is reported if the label is invalid, or is not declared in `deps`. |
 | `objects` | List of [labels](/versions/8.2.1/concepts/labels); default is `[]` |
 | `pic_objects` | List of [labels](/versions/8.2.1/concepts/labels); default is `[]` |
 | `pic_static_library` | [Label](/versions/8.2.1/concepts/labels); default is `None` |
@@ -453,7 +453,7 @@ cc_library(
 | `implementation_deps` | List of [labels](/versions/8.2.1/concepts/labels); default is `[]` The list of other libraries that the library target depends on. Unlike with `deps`, the headers and include paths of these libraries (and all their transitive deps) are only used for compilation of this library, and not libraries that depend on it. Libraries specified with `implementation_deps` are still linked in binary targets that depend on this library. |
 | `include_prefix` | String; default is `""` The prefix to add to the paths of the headers of this rule. When set, the headers in the `hdrs` attribute of this rule are accessible at is the value of this attribute prepended to their repository-relative path. The prefix in the `strip_include_prefix` attribute is removed before this prefix is added. This attribute is only legal under `third_party`. |
 | `includes` | List of strings; default is `[]` List of include dirs to be added to the compile line. Subject to ["Make variable"](/versions/8.2.1/reference/be/make-variables) substitution. Each string is prepended with the package path and passed to the C++ toolchain for expansion via the "include\_paths" CROSSTOOL feature. A toolchain running on a POSIX system with typical feature definitions will produce `-isystem path_to_package/include_entry`. This should only be used for third-party libraries that do not conform to the Google style of writing #include statements. Unlike [COPTS](#cc_binary.copts), these flags are added for this rule and every rule that depends on it. (Note: not the rules it depends upon!) Be very careful, since this may have far-reaching effects. When in doubt, add "-I" flags to [COPTS](#cc_binary.copts) instead. The added `include` paths will include generated files as well as files in the source tree. |
-| `linkopts` | List of strings; default is `[]` See [`cc_binary.linkopts`](/versions/8.2.1/reference/be/c-cpp#cc_binary.linkopts). The `linkopts` attribute is also applied to any target that depends, directly or indirectly, on this library via `deps` attributes (or via other attributes that are treated similarly: the [`malloc`](/versions/8.2.1/reference/be/c-cpp#cc_binary.malloc) attribute of [`cc_binary`](/versions/8.2.1/reference/be/c-cpp#cc_binary)). Dependency linkopts take precedence over dependent linkopts (i.e. dependency linkopts appear later in the command line). Linkopts specified in [`--linkopt`](../user-manual#flag--linkopt) take precedence over rule linkopts. |
+| `linkopts` | List of strings; default is `[]` See [`cc_binary.linkopts`](/versions/8.2.1/reference/be/c-cpp#cc_binary.linkopts). The `linkopts` attribute is also applied to any target that depends, directly or indirectly, on this library via `deps` attributes (or via other attributes that are treated similarly: the [`malloc`](/versions/8.2.1/reference/be/c-cpp#cc_binary.malloc) attribute of [`cc_binary`](/versions/8.2.1/reference/be/c-cpp#cc_binary)). Dependency linkopts take precedence over dependent linkopts (i.e. dependency linkopts appear later in the command line). Linkopts specified in [`--linkopt`](/versions/8.2.1/reference/user-manual#flag--linkopt) take precedence over rule linkopts. |
 
 Note that the `linkopts` attribute only applies
 when creating `.so` files or executables, not
@@ -736,7 +736,7 @@ that `cc_test` has extra [attributes common to all test rules (\*\_test)](/versi
 | `hdrs_check` | String; default is `""` Deprecated, no-op. |
 | `includes` | List of strings; default is `[]` List of include dirs to be added to the compile line. Subject to ["Make variable"](/versions/8.2.1/reference/be/make-variables) substitution. Each string is prepended with the package path and passed to the C++ toolchain for expansion via the "include\_paths" CROSSTOOL feature. A toolchain running on a POSIX system with typical feature definitions will produce `-isystem path_to_package/include_entry`. This should only be used for third-party libraries that do not conform to the Google style of writing #include statements. Unlike [COPTS](#cc_binary.copts), these flags are added for this rule and every rule that depends on it. (Note: not the rules it depends upon!) Be very careful, since this may have far-reaching effects. When in doubt, add "-I" flags to [COPTS](#cc_binary.copts) instead. The added `include` paths will include generated files as well as files in the source tree. |
 | `link_extra_lib` | [Label](/versions/8.2.1/concepts/labels); default is `"@bazel_tools//tools/cpp:link_extra_lib"` Control linking of extra libraries. By default, C++ binaries are linked against `//tools/cpp:link_extra_lib`, which by default depends on the label flag `//tools/cpp:link_extra_libs`. Without setting the flag, this library is empty by default. Setting the label flag allows linking optional dependencies, such as overrides for weak symbols, interceptors for shared library functions, or special runtime libraries (for malloc replacements, prefer `malloc` or `--custom_malloc`). Setting this attribute to `None` disables this behaviour. |
-| `linkopts` | List of strings; default is `[]` Add these flags to the C++ linker command. Subject to ["Make" variable](make-variables) substitution, [Bourne shell tokenization](common-definitions#sh-tokenization) and [label expansion](common-definitions#label-expansion). Each string in this attribute is added to `LINKOPTS` before linking the binary target. Each element of this list that does not start with `$` or `-` is assumed to be the label of a target in `deps`. The list of files generated by that target is appended to the linker options. An error is reported if the label is invalid, or is not declared in `deps`. |
+| `linkopts` | List of strings; default is `[]` Add these flags to the C++ linker command. Subject to ["Make" variable](/versions/8.2.1/reference/be/make-variables) substitution, [Bourne shell tokenization](/versions/8.2.1/reference/be/common-definitions#sh-tokenization) and [label expansion](/versions/8.2.1/reference/be/common-definitions#label-expansion). Each string in this attribute is added to `LINKOPTS` before linking the binary target. Each element of this list that does not start with `$` or `-` is assumed to be the label of a target in `deps`. The list of files generated by that target is appended to the linker options. An error is reported if the label is invalid, or is not declared in `deps`. |
 | `linkshared` | Boolean; default is `False` Create a shared library. To enable this attribute, include `linkshared=True` in your rule. By default this option is off. The presence of this flag means that linking occurs with the `-shared` flag to `gcc`, and the resulting shared library is suitable for loading into for example a Java program. However, for build purposes it will never be linked into the dependent binary, as it is assumed that shared libraries built with a [cc\_binary](#cc_binary) rule are only loaded manually by other programs, so it should not be considered a substitute for the [cc\_library](#cc_library) rule. For sake of scalability we recommend avoiding this approach altogether and simply letting `java_library` depend on `cc_library` rules instead.  If you specify both `linkopts=['-static']` and `linkshared=True`, you get a single completely self-contained unit. If you specify both `linkstatic=True` and `linkshared=True`, you get a single, mostly self-contained unit. |
 | `linkstatic` | Boolean; default is `False` For [`cc_binary`](/versions/8.2.1/reference/be/c-cpp#cc_binary) and [`cc_test`](/versions/8.2.1/reference/be/c-cpp#cc_test): link the binary in static mode. For `cc_library.link_static`: see below. By default this option is on for `cc_binary` and off for the rest.  If enabled and this is a binary or test, this option tells the build tool to link in `.a`'s instead of `.so`'s for user libraries whenever possible. System libraries such as libc (but *not* the C/C++ runtime libraries, see below) are still linked dynamically, as are libraries for which there is no static library. So the resulting executable will still be dynamically linked, hence only *mostly* static.  There are really three different ways to link an executable:   * STATIC with fully\_static\_link feature, in which everything is linked statically;   e.g. "`gcc -static foo.o libbar.a libbaz.a -lm`".    This mode is enabled by specifying `fully_static_link` in the   [`features`](/versions/8.2.1/reference/be/common-definitions#features) attribute. * STATIC, in which all user libraries are linked statically (if a static   version is available), but where system libraries (excluding C/C++ runtime libraries)   are linked dynamically, e.g. "`gcc foo.o libfoo.a libbaz.a -lm`".    This mode is enabled by specifying `linkstatic=True`. * DYNAMIC, in which all libraries are linked dynamically (if a dynamic version is   available), e.g. "`gcc foo.o libfoo.so libbaz.so -lm`".    This mode is enabled by specifying `linkstatic=False`.   If the `linkstatic` attribute or `fully_static_link` in `features` is used outside of `//third_party` please include a comment near the rule to explain why.  The `linkstatic` attribute has a different meaning if used on a [`cc_library()`](/versions/8.2.1/reference/be/c-cpp#cc_library) rule. For a C++ library, `linkstatic=True` indicates that only static linking is allowed, so no `.so` will be produced. linkstatic=False does not prevent static libraries from being created. The attribute is meant to control the creation of dynamic libraries.  There should be very little code built with `linkstatic=False` in production. If `linkstatic=False`, then the build tool will create symlinks to depended-upon shared libraries in the `*.runfiles` area. |
 | `local_defines` | List of strings; default is `[]` List of defines to add to the compile line. Subject to ["Make" variable](/versions/8.2.1/reference/be/make-variables) substitution and [Bourne shell tokenization](/versions/8.2.1/reference/be/common-definitions#sh-tokenization). Each string, which must consist of a single Bourne shell token, is prepended with `-D` and added to the compile command line for this target, but not to its dependents. |
diff --git a/versions/8.2.1/reference/be/common-definitions.mdx b/versions/8.2.1/reference/be/common-definitions.mdx
index faed592b..e7f574ed 100644
--- a/versions/8.2.1/reference/be/common-definitions.mdx
+++ b/versions/8.2.1/reference/be/common-definitions.mdx
@@ -75,11 +75,11 @@ rules.
 | `deprecation` | String; [nonconfigurable](#configurable-attributes); default is `None`  An explanatory warning message associated with this target. Typically this is used to notify users that a target has become obsolete, or has become superseded by another rule, is private to a package, or is perhaps considered harmful for some reason. It is a good idea to include some reference (like a webpage, a bug number or example migration CLs) so that one can easily find out what changes are required to avoid the message. If there is a new target that can be used as a drop in replacement, it is a good idea to just migrate all users of the old target.  This attribute has no effect on the way things are built, but it may affect a build tool's diagnostic output. The build tool issues a warning when a rule with a `deprecation` attribute is depended upon by a target in another package.  Intra-package dependencies are exempt from this warning, so that, for example, building the tests of a deprecated rule does not encounter a warning.  If a deprecated target depends on another deprecated target, no warning message is issued.  Once people have stopped using it, the target can be removed. |
 | `distribs` | List of strings; [nonconfigurable](#configurable-attributes); default is `[]`  A list of distribution-method strings to be used for this particular target. This is part of a deprecated licensing API that Bazel no longer uses. Don't use this. |
 | `exec_compatible_with` | List of [labels](/versions/8.2.1/concepts/labels); [nonconfigurable](#configurable-attributes); default is `[]`  A list of `constraint_values` that must be present in the execution platform for this target. This is in addition to any constraints already set by the rule type. Constraints are used to restrict the list of available execution platforms. For more details, see the description of [toolchain resolution](/versions/8.2.1/docs/toolchains#toolchain-resolution). |
-| `exec_properties` | Dictionary of strings; default is `{}`  A dictionary of strings that will be added to the `exec_properties` of a platform selected for this target. See `exec_properties` of the [platform](platforms-and-toolchains#platform) rule.  If a key is present in both the platform and target-level properties, the value will be taken from the target. |
+| `exec_properties` | Dictionary of strings; default is `{}`  A dictionary of strings that will be added to the `exec_properties` of a platform selected for this target. See `exec_properties` of the [platform](/versions/8.2.1/reference/be/platforms-and-toolchains#platform) rule.  If a key is present in both the platform and target-level properties, the value will be taken from the target. |
 | `features` | List of *feature* strings; default is `[]`  A feature is string tag that can be enabled or disabled on a target. The meaning of a feature depends on the rule itself.  This `features` attribute is combined with the [package](/versions/8.2.1/reference/be/functions#package) level `features` attribute. For example, if the features ["a", "b"] are enabled on the package level, and a target's `features` attribute contains ["-a", "c"], the features enabled for the rule will be "b" and "c". [See example](https://github.com/bazelbuild/examples/blob/main/rules/features/BUILD). |
 | `restricted_to` | List of [labels](/versions/8.2.1/concepts/labels); [nonconfigurable](#configurable-attributes); default is `[]`  The list of environments this target can be built for, *instead* of default-supported environments.  This is part of Bazel's constraint system. See `compatible_with` for details. |
 | `tags` | List of strings; [nonconfigurable](#configurable-attributes); default is `[]`  *Tags* can be used on any rule. *Tags* on test and `test_suite` rules are useful for categorizing the tests. *Tags* on non-test targets are used to control sandboxed execution of `genrule`s and [Starlark](/versions/8.2.1/rules/concepts) actions, and for parsing by humans and/or external tools.  Bazel modifies the behavior of its sandboxing code if it finds the following keywords in the `tags` attribute of any test or `genrule` target, or the keys of `execution_requirements` for any Starlark action.   * `no-sandbox` keyword results in the action or test never being   sandboxed; it can still be cached or run remotely - use `no-cache`   or `no-remote` to prevent either or both of those. * `no-cache` keyword results in the action or test never being   cached (locally or remotely). Note: for the purposes of this tag, the disk cache   is considered a local cache, whereas the HTTP and gRPC caches are considered   remote. Other caches, such as Skyframe or the persistent action cache, are not   affected. * `no-remote-cache` keyword results in the action or test never being   cached remotely (but it may be cached locally; it may also be executed remotely).   Note: for the purposes of this tag, the disk cache is considered a local cache,   whereas the HTTP and gRPC caches are considered remote. Other caches, such as   Skyframe or the persistent action cache, are not affected.   If a combination of local disk cache and remote cache are used (combined cache),   it's treated as a remote cache and disabled entirely unless `--incompatible_remote_results_ignore_disk`   is set in which case the local components will be used. * `no-remote-exec` keyword results in the action or test never being   executed remotely (but it may be cached remotely). * `no-remote` keyword prevents the action or test from being executed remotely or   cached remotely. This is equivalent to using both   `no-remote-cache` and `no-remote-exec`. * `no-remote-cache-upload` keyword disables upload part of remote caching of a spawn.   it does not disable remote execution. * `local` keyword precludes the action or test from being remotely cached,   remotely executed, or run inside the sandbox.   For genrules and tests, marking the rule with the `local = True`   attribute has the same effect. * `requires-network` keyword allows access to the external   network from inside the sandbox. This tag only has an effect if sandboxing   is enabled. * `block-network` keyword blocks access to the external   network from inside the sandbox. In this case, only communication   with localhost is allowed. This tag only has an effect if sandboxing is   enabled. * `requires-fakeroot` runs the test or action as uid and gid 0 (i.e., the root   user). This is only supported on Linux. This tag takes precedence over the   `--sandbox_fake_username` command-line option.   *Tags* on tests are generally used to annotate a test's role in your debug and release process. Typically, tags are most useful for C++ and Python tests, which lack any runtime annotation ability. The use of tags and size elements gives flexibility in assembling suites of tests based around codebase check-in policy.  Bazel modifies test running behavior if it finds the following keywords in the `tags` attribute of the test rule:   * `exclusive` will force the test to be run in the   "exclusive" mode, ensuring that no other tests are running at the   same time. Such tests will be executed in serial fashion after all build   activity and non-exclusive tests have been completed. Remote execution is   disabled for such tests because Bazel doesn't have control over what's   running on a remote machine. * `exclusive-if-local` will force the test to be run in the   "exclusive" mode if it is executed locally, but will run the test in parallel if it's   executed remotely. * `manual` keyword will exclude the target from expansion of target pattern wildcards   (`...`, `:*`, `:all`, etc.) and `test_suite` rules   which do not list the test explicitly when computing the set of top-level targets to build/run   for the `build`, `test`, and `coverage` commands. It does not   affect target wildcard or test suite expansion in other contexts, including the   `query` command. Note that `manual` does not imply that a target should   not be built/run automatically by continuous build/test systems. For example, it may be   desirable to exclude a target from `bazel test ...` because it requires specific   Bazel flags, but still have it included in properly-configured presubmit or continuous test   runs. * `external` keyword will force test to be unconditionally   executed (regardless of `--cache_test_results`   value).  See [Tag Conventions](/versions/8.2.1/reference/test-encyclopedia#tag-conventions) in the Test Encyclopedia for more conventions on tags attached to test targets. |
-| `target_compatible_with` | List of [labels](/versions/8.2.1/concepts/labels); default is `[]`  A list of `constraint_value`s that must be present in the target platform for this target to be considered *compatible*. This is in addition to any constraints already set by the rule type. If the target platform does not satisfy all listed constraints then the target is considered *incompatible*. Incompatible targets are skipped for building and testing when the target pattern is expanded (e.g. `//...`, `:all`). When explicitly specified on the command line, incompatible targets cause Bazel to print an error and cause a build or test failure.  Targets that transitively depend on incompatible targets are themselves considered incompatible. They are also skipped for building and testing.  An empty list (which is the default) signifies that the target is compatible with all platforms. All rules other than [Workspace Rules](workspace) support this attribute. For some rules this attribute has no effect. For example, specifying `target_compatible_with` for a `cc_toolchain` is not useful. See the [Platforms](/versions/8.2.1/docs/platforms#skipping-incompatible-targets) page for more information about incompatible target skipping. |
+| `target_compatible_with` | List of [labels](/versions/8.2.1/concepts/labels); default is `[]`  A list of `constraint_value`s that must be present in the target platform for this target to be considered *compatible*. This is in addition to any constraints already set by the rule type. If the target platform does not satisfy all listed constraints then the target is considered *incompatible*. Incompatible targets are skipped for building and testing when the target pattern is expanded (e.g. `//...`, `:all`). When explicitly specified on the command line, incompatible targets cause Bazel to print an error and cause a build or test failure.  Targets that transitively depend on incompatible targets are themselves considered incompatible. They are also skipped for building and testing.  An empty list (which is the default) signifies that the target is compatible with all platforms. All rules other than [Workspace Rules](/versions/8.2.1/reference/be/workspace) support this attribute. For some rules this attribute has no effect. For example, specifying `target_compatible_with` for a `cc_toolchain` is not useful. See the [Platforms](/versions/8.2.1/docs/platforms#skipping-incompatible-targets) page for more information about incompatible target skipping. |
 | `testonly` | Boolean; [nonconfigurable](#configurable-attributes); default is `False` except for test and test suite targets  If `True`, only testonly targets (such as tests) can depend on this target.  Equivalently, a rule that is not `testonly` is not allowed to depend on any rule that is `testonly`.  Tests (`*_test` rules) and test suites ([test\_suite](/versions/8.2.1/reference/be/general#test_suite) rules) are `testonly` by default.  This attribute is intended to mean that the target should not be contained in binaries that are released to production.  Because testonly is enforced at build time, not run time, and propagates virally through the dependency tree, it should be applied judiciously. For example, stubs and fakes that are useful for unit tests may also be useful for integration tests involving the same binaries that will be released to production, and therefore should probably not be marked testonly. Conversely, rules that are dangerous to even link in, perhaps because they unconditionally override normal behavior, should definitely be marked testonly. |
 | `toolchains` | List of [labels](/versions/8.2.1/concepts/labels); [nonconfigurable](#configurable-attributes); default is `[]`  The set of targets whose [Make variables](/versions/8.2.1/reference/be/make-variables) this target is allowed to access. These targets are either instances of rules that provide `TemplateVariableInfo` or special targets for toolchain types built into Bazel. These include:  * `@bazel_tools//tools/cpp:current_cc_toolchain`* `@rules_java//toolchains:current_java_runtime`   Note that this is distinct from the concept of [toolchain resolution](/versions/8.2.1/docs/toolchains#toolchain-resolution) that is used by rule implementations for platform-dependent configuration. You cannot use this attribute to determine which specific `cc_toolchain` or `java_toolchain` a target will use. |
 | `visibility` | List of [labels](/versions/8.2.1/concepts/labels); [nonconfigurable](#configurable-attributes); default varies  The `visibility` attribute controls whether the target can be depended on by targets in other locations. See the documentation for [visibility](/versions/8.2.1/concepts/visibility).  For targets declared directly in a BUILD file or in legacy macros called from a BUILD file, the default value is the package's `default_visibility` if specified, or else `["//visibility:private"]`. For targets declared in one or more symbolic macros, the default value is always just `["//visibility:private"]` (which makes it useable only within the package containing the macro's code). |
diff --git a/versions/8.2.1/reference/be/functions.mdx b/versions/8.2.1/reference/be/functions.mdx
index 1a2931e7..70317661 100644
--- a/versions/8.2.1/reference/be/functions.mdx
+++ b/versions/8.2.1/reference/be/functions.mdx
@@ -34,9 +34,9 @@ file, before any rule.
 | --- | --- |
 | `default_applicable_licenses` | Alias for [`default_package_metadata`](#package.default_package_metadata). |
 | `default_visibility` | List of [labels](/versions/8.2.1/concepts/labels); default is `[]`  The default visibility of the top-level rule targets and symbolic macros in this package — that is, the targets and symbolic macros that are not themselves declared inside a symbolic macro. This attribute is ignored if the target or macro specifies a `visibility` value.  For detailed information about the syntax of this attribute, see the documentation of [visibility](/versions/8.2.1/concepts/visibility). The package default visibility does not apply to [exports\_files](#exports_files), which is public by default. |
-| `default_deprecation` | String; default is `""`  Sets the default [`deprecation`](common-definitions#common.deprecation) message for all rules in this package. |
+| `default_deprecation` | String; default is `""`  Sets the default [`deprecation`](/versions/8.2.1/reference/be/common-definitions#common.deprecation) message for all rules in this package. |
 | `default_package_metadata` | List of [labels](/versions/8.2.1/concepts/labels); default is `[]`  Sets a default list of metadata targets which apply to all other targets in the package. These are typically targets related to OSS package and license declarations. See [rules\_license](https://github.com/bazelbuild/rules_license) for examples. |
-| `default_testonly` | Boolean; default is `False` except as noted  Sets the default [`testonly`](common-definitions#common.testonly) property for all rules in this package.  In packages under `javatests` the default value is `True`. |
+| `default_testonly` | Boolean; default is `False` except as noted  Sets the default [`testonly`](/versions/8.2.1/reference/be/common-definitions#common.testonly) property for all rules in this package.  In packages under `javatests` the default value is `True`. |
 | `features` | List strings; default is `[]`  Sets various flags that affect the semantics of this BUILD file.  This feature is mainly used by the people working on the build system to tag packages that need some kind of special handling. Do not use this unless explicitly requested by someone working on the build system. |
 
 ### Examples
@@ -66,7 +66,7 @@ visible target can only be referenced within its own package (not subpackages).
 In between these extremes, a target may allow access to its own package plus any
 of the packages described by one or more package groups. For a more detailed
 explanation of the visibility system, see the
-[visibility](common-definitions#common.visibility)
+[visibility](/versions/8.2.1/reference/be/common-definitions#common.visibility)
 attribute.
 
 A given package is considered to be in the group if it either matches the
@@ -159,7 +159,7 @@ visibility declaration can also be specified; in this case, the files will be
 visible to the targets specified. If no visibility is specified, the files
 will be visible to every package, even if a package default visibility was
 specified in the `package`
-function. The [licenses](common-definitions#common.licenses)
+function. The [licenses](/versions/8.2.1/reference/be/common-definitions#common.licenses)
 can also be specified.
 
 ### Example
@@ -262,8 +262,7 @@ There are several important limitations and caveats:
    package called "Foo.java" (which is allowed, though Bazel warns about it),
    then the consumer of the `glob()` will use the "Foo.java" rule
    (its outputs) instead of the "Foo.java" file. See
-   [GitHub
-   issue #10395](https://github.com/bazelbuild/bazel/issues/10395#issuecomment-583714657) for more details.
+   [GitHub issue #10395](https://github.com/bazelbuild/bazel/issues/10395#issuecomment-583714657) for more details.
 3. Globs may match files in subdirectories. And subdirectory names
    may be wildcarded. However...
 4. Labels are not allowed to cross the package boundary and glob does
@@ -409,7 +408,7 @@ select(
 ```
 
 `select()` is the helper function that makes a rule attribute
-[configurable](common-definitions#configurable-attributes).
+[configurable](/versions/8.2.1/reference/be/common-definitions#configurable-attributes).
 It can replace the right-hand side of
 *almost*
 any attribute assignment so its value depends on command-line Bazel flags.
diff --git a/versions/8.2.1/reference/be/general.mdx b/versions/8.2.1/reference/be/general.mdx
index 682db31c..8b7d6c99 100644
--- a/versions/8.2.1/reference/be/general.mdx
+++ b/versions/8.2.1/reference/be/general.mdx
@@ -158,9 +158,9 @@ some build targets.
   [here](/versions/8.2.1/reference/be/common-definitions#configurable-attributes) for more discussion.
 * Avoid repeating identical `config_setting` definitions in different packages.
   Instead, reference a common `config_setting` that defined in a canonical package.
-* [`values`](general#config_setting.values),
-  [`define_values`](general#config_setting.define_values), and
-  [`constraint_values`](general#config_setting.constraint_values)
+* [`values`](/versions/8.2.1/reference/be/general#config_setting.values),
+  [`define_values`](/versions/8.2.1/reference/be/general#config_setting.define_values), and
+  [`constraint_values`](/versions/8.2.1/reference/be/general#config_setting.constraint_values)
   can be used in any combination in the same `config_setting` but at least one must
   be set for any given `config_setting`.
 
@@ -169,10 +169,10 @@ some build targets.
 | Attributes | |
 | --- | --- |
 | `name` | [Name](/versions/8.2.1/concepts/labels#target-names); required  A unique name for this target. |
-| `constraint_values` | List of [labels](/versions/8.2.1/concepts/labels); [nonconfigurable](common-definitions#configurable-attributes); default is `[]` The minimum set of `constraint_values` that the target platform must specify in order to match this `config_setting`. (The execution platform is not considered here.) Any additional constraint values that the platform has are ignored. See [Configurable Build Attributes](https://bazel.build/versions/8.2.1/docs/configurable-attributes#platforms) for details. If two `config_setting`s match in the same `select` and one has all the same flags and `constraint_setting`s as the other plus additional ones, the one with more settings is chosen. This is known as "specialization". For example, a `config_setting` matching `x86` and `Linux` specializes a `config_setting` matching `x86`. If two `config_setting`s match and both have `constraint_value`s not present in the other, this is an error. |
-| `define_values` | Dictionary: String -> String; [nonconfigurable](common-definitions#configurable-attributes); default is `{}` The same as [`values`](/versions/8.2.1/reference/be/general#config_setting.values) but specifically for the `--define` flag. `--define` is special because its syntax (`--define KEY=VAL`) means `KEY=VAL` is a *value* from a Bazel flag perspective.  That means:  ```             config_setting(                 name = "a_and_b",                 values = {                     "define": "a=1",                     "define": "b=2",                 }) ```   doesn't work because the same key (`define`) appears twice in the dictionary. This attribute solves that problem:  ```             config_setting(                 name = "a_and_b",                 define_values = {                     "a": "1",                     "b": "2",                 }) ```   correctly matches `bazel build //foo --define a=1 --define b=2`. `--define` can still appear in [`values`](/versions/8.2.1/reference/be/general#config_setting.values) with normal flag syntax, and can be mixed freely with this attribute as long as dictionary keys remain distinct. |
-| `flag_values` | Dictionary: [label](/versions/8.2.1/concepts/labels) -> String; [nonconfigurable](common-definitions#configurable-attributes); default is `{}` The same as [`values`](/versions/8.2.1/reference/be/general#config_setting.values) but for [user-defined build flags](https://bazel.build/versions/8.2.1/rules/config#user-defined-build-settings). This is a distinct attribute because user-defined flags are referenced as labels while built-in flags are referenced as arbitrary strings. |
-| `values` | Dictionary: String -> String; [nonconfigurable](common-definitions#configurable-attributes); default is `{}` The set of configuration values that match this rule (expressed as build flags) This rule inherits the configuration of the configured target that references it in a `select` statement. It is considered to "match" a Bazel invocation if, for every entry in the dictionary, its configuration matches the entry's expected value. For example `values = {"compilation_mode": "opt"}` matches the invocations `bazel build --compilation_mode=opt ...` and `bazel build -c opt ...` on target-configured rules.  For convenience's sake, configuration values are specified as build flags (without the preceding `"--"`). But keep in mind that the two are not the same. This is because targets can be built in multiple configurations within the same build. For example, an exec configuration's "cpu" matches the value of `--host_cpu`, not `--cpu`. So different instances of the same `config_setting` may match the same invocation differently depending on the configuration of the rule using them.  If a flag is not explicitly set at the command line, its default value is used. If a key appears multiple times in the dictionary, only the last instance is used. If a key references a flag that can be set multiple times on the command line (e.g. `bazel build --copt=foo --copt=bar --copt=baz ...`), a match occurs if *any* of those settings match. |
+| `constraint_values` | List of [labels](/versions/8.2.1/concepts/labels); [nonconfigurable](/versions/8.2.1/reference/be/common-definitions#configurable-attributes); default is `[]` The minimum set of `constraint_values` that the target platform must specify in order to match this `config_setting`. (The execution platform is not considered here.) Any additional constraint values that the platform has are ignored. See [Configurable Build Attributes](https://bazel.build/versions/8.2.1/docs/configurable-attributes#platforms) for details. If two `config_setting`s match in the same `select` and one has all the same flags and `constraint_setting`s as the other plus additional ones, the one with more settings is chosen. This is known as "specialization". For example, a `config_setting` matching `x86` and `Linux` specializes a `config_setting` matching `x86`. If two `config_setting`s match and both have `constraint_value`s not present in the other, this is an error. |
+| `define_values` | Dictionary: String -> String; [nonconfigurable](/versions/8.2.1/reference/be/common-definitions#configurable-attributes); default is `{}` The same as [`values`](/versions/8.2.1/reference/be/general#config_setting.values) but specifically for the `--define` flag. `--define` is special because its syntax (`--define KEY=VAL`) means `KEY=VAL` is a *value* from a Bazel flag perspective.  That means:  ```             config_setting(                 name = "a_and_b",                 values = {                     "define": "a=1",                     "define": "b=2",                 }) ```   doesn't work because the same key (`define`) appears twice in the dictionary. This attribute solves that problem:  ```             config_setting(                 name = "a_and_b",                 define_values = {                     "a": "1",                     "b": "2",                 }) ```   correctly matches `bazel build //foo --define a=1 --define b=2`. `--define` can still appear in [`values`](/versions/8.2.1/reference/be/general#config_setting.values) with normal flag syntax, and can be mixed freely with this attribute as long as dictionary keys remain distinct. |
+| `flag_values` | Dictionary: [label](/versions/8.2.1/concepts/labels) -> String; [nonconfigurable](/versions/8.2.1/reference/be/common-definitions#configurable-attributes); default is `{}` The same as [`values`](/versions/8.2.1/reference/be/general#config_setting.values) but for [user-defined build flags](https://bazel.build/versions/8.2.1/rules/config#user-defined-build-settings). This is a distinct attribute because user-defined flags are referenced as labels while built-in flags are referenced as arbitrary strings. |
+| `values` | Dictionary: String -> String; [nonconfigurable](/versions/8.2.1/reference/be/common-definitions#configurable-attributes); default is `{}` The set of configuration values that match this rule (expressed as build flags) This rule inherits the configuration of the configured target that references it in a `select` statement. It is considered to "match" a Bazel invocation if, for every entry in the dictionary, its configuration matches the entry's expected value. For example `values = {"compilation_mode": "opt"}` matches the invocations `bazel build --compilation_mode=opt ...` and `bazel build -c opt ...` on target-configured rules.  For convenience's sake, configuration values are specified as build flags (without the preceding `"--"`). But keep in mind that the two are not the same. This is because targets can be built in multiple configurations within the same build. For example, an exec configuration's "cpu" matches the value of `--host_cpu`, not `--cpu`. So different instances of the same `config_setting` may match the same invocation differently depending on the configuration of the rule using them.  If a flag is not explicitly set at the command line, its default value is used. If a key appears multiple times in the dictionary, only the last instance is used. If a key references a flag that can be set multiple times on the command line (e.g. `bazel build --copt=foo --copt=bar --copt=baz ...`), a match occurs if *any* of those settings match. |
 
 ## filegroup
 
@@ -466,7 +466,7 @@ genrule(
 | --- | --- |
 | `name` | [Name](/versions/8.2.1/concepts/labels#target-names); required  A unique name for this target.  You may refer to this rule by name in the `srcs` or `deps` section of other `BUILD` rules. If the rule generates source files, you should use the `srcs` attribute. |
 | `srcs` | List of [labels](/versions/8.2.1/concepts/labels); default is `[]` A list of inputs for this rule, such as source files to process. *This attributes is not suitable to list tools executed by the `cmd`; use the [`tools`](/versions/8.2.1/reference/be/general#genrule.tools) attribute for them instead.*  The build system ensures these prerequisites are built before running the genrule command; they are built using the same configuration as the original build request. The names of the files of these prerequisites are available to the command as a space-separated list in `$(SRCS)`; alternatively the path of an individual `srcs` target `//x:y` can be obtained using `$(location //x:y)`, or using `$<` provided it's the only entry in `srcs`. |
-| `outs` | List of [filenames](/versions/8.2.1/concepts/build-ref#filename); [nonconfigurable](common-definitions#configurable-attributes); required A list of files generated by this rule. Output files must not cross package boundaries. Output filenames are interpreted as relative to the package.  If the `executable` flag is set, `outs` must contain exactly one label.  The genrule command is expected to create each output file at a predetermined location. The location is available in `cmd` using [genrule-specific "Make" variables](/versions/8.2.1/reference/be/make-variables#predefined_genrule_variables) (`$@`, `$(OUTS)`, `$(@D)` or `$(RULEDIR)`) or using [`$(location)`](/versions/8.2.1/reference/be/make-variables#predefined_label_variables) substitution. |
+| `outs` | List of [filenames](/versions/8.2.1/concepts/build-ref#filename); [nonconfigurable](/versions/8.2.1/reference/be/common-definitions#configurable-attributes); required A list of files generated by this rule. Output files must not cross package boundaries. Output filenames are interpreted as relative to the package.  If the `executable` flag is set, `outs` must contain exactly one label.  The genrule command is expected to create each output file at a predetermined location. The location is available in `cmd` using [genrule-specific "Make" variables](/versions/8.2.1/reference/be/make-variables#predefined_genrule_variables) (`$@`, `$(OUTS)`, `$(@D)` or `$(RULEDIR)`) or using [`$(location)`](/versions/8.2.1/reference/be/make-variables#predefined_label_variables) substitution. |
 | `cmd` | String; default is `""` The command to run. Subject to [`$(location)`](/versions/8.2.1/reference/be/make-variables#predefined_label_variables) and ["Make" variable](/versions/8.2.1/reference/be/make-variables) substitution.  1. First [`$(location)`](/versions/8.2.1/reference/be/make-variables#predefined_label_variables) substitution is applied, replacing all occurrences of `$(location     label)` and of `$(locations label)` (and similar    constructions using related variables `execpath`, `execpaths`,    `rootpath` and `rootpaths`). 2. Next, ["Make" variables](/versions/8.2.1/reference/be/make-variables) are expanded. Note that    predefined variables `$(JAVA)`, `$(JAVAC)` and    `$(JAVABASE)` expand under the *exec* configuration, so Java invocations    that run as part of a build step can correctly load shared libraries and other    dependencies. 3. Finally, the resulting command is executed using the Bash shell. If its exit code is    non-zero the command is considered to have failed.  This is the fallback of `cmd_bash`, `cmd_ps` and `cmd_bat`, if none of them are applicable. |
 
 If the command line length exceeds the platform limit (64K on Linux/macOS, 8K on Windows),
@@ -477,11 +477,11 @@ applies to all cmd attributes (`cmd`, `cmd_bash`, `cmd_ps`,
 | `cmd_bash` | String; default is `""` The Bash command to run. This attribute has higher priority than `cmd`. The command is expanded and runs in the exact same way as the `cmd` attribute. |
 | `cmd_bat` | String; default is `""` The Batch command to run on Windows. This attribute has higher priority than `cmd` and `cmd_bash`. The command runs in the similar way as the `cmd` attribute, with the following differences:   * This attribute only applies on Windows. * The command runs with `cmd.exe /c` with the following default arguments:   + `/S` - strip first and last quotes and execute everything else as is.   + `/E:ON` - enable extended command set.   + `/V:ON` - enable delayed variable expansion   + `/D` - ignore AutoRun registry entries. * After [$(location)](/versions/8.2.1/reference/be/make-variables#predefined_label_variables) and   ["Make" variable](/versions/8.2.1/reference/be/make-variables) substitution, the paths will be   expanded to Windows style paths (with backslash). |
 | `cmd_ps` | String; default is `""` The Powershell command to run on Windows. This attribute has higher priority than `cmd`, `cmd_bash` and `cmd_bat`. The command runs in the similar way as the `cmd` attribute, with the following differences:   * This attribute only applies on Windows. * The command runs with `powershell.exe /c`.   To make Powershell easier to use and less error-prone, we run the following commands to set up the environment before executing Powershell command in genrule.   * `Set-ExecutionPolicy -Scope CurrentUser RemoteSigned` - allow running   unsigned scripts. * `$errorActionPreference='Stop'` - In case there are multiple commands   separated by `;`, the action exits immediately if a Powershell CmdLet fails,   but this does **NOT** work for external command. * `$PSDefaultParameterValues['*:Encoding'] = 'utf8'` - change the default   encoding from utf-16 to utf-8. |
-| `executable` | Boolean; [nonconfigurable](common-definitions#configurable-attributes); default is `False` Declare output to be executable. Setting this flag to True means the output is an executable file and can be run using the `run` command. The genrule must produce exactly one output in this case. If this attribute is set, `run` will try executing the file regardless of its content.  Declaring data dependencies for the generated executable is not supported. |
+| `executable` | Boolean; [nonconfigurable](/versions/8.2.1/reference/be/common-definitions#configurable-attributes); default is `False` Declare output to be executable. Setting this flag to True means the output is an executable file and can be run using the `run` command. The genrule must produce exactly one output in this case. If this attribute is set, `run` will try executing the file regardless of its content.  Declaring data dependencies for the generated executable is not supported. |
 | `local` | Boolean; default is `False`  If set to True, this option forces this `genrule` to run using the "local" strategy, which means no remote execution, no sandboxing, no persistent workers.  This is equivalent to providing 'local' as a tag (`tags=["local"]`). |
 | `message` | String; default is `""` A progress message. A progress message that will be printed as this build step is executed. By default, the message is "Generating *output*" (or something equally bland) but you may provide a more specific one. Use this attribute instead of `echo` or other print statements in your `cmd` command, as this allows the build tool to control whether such progress messages are printed or not. |
 | `output_licenses` | Licence type; default is `["none"]` See [`common attributes`](/versions/8.2.1/reference/be/common-definitions#binary.output_licenses) |
-| `output_to_bindir` | Boolean; [nonconfigurable](common-definitions#configurable-attributes); default is `False`  If set to True, this option causes output files to be written into the `bin` directory instead of the `genfiles` directory. |
+| `output_to_bindir` | Boolean; [nonconfigurable](/versions/8.2.1/reference/be/common-definitions#configurable-attributes); default is `False`  If set to True, this option causes output files to be written into the `bin` directory instead of the `genfiles` directory. |
 | `tools` | List of [labels](/versions/8.2.1/concepts/labels); default is `[]` A list of *tool* dependencies for this rule. See the definition of [dependencies](/versions/8.2.1/concepts/build-ref#deps) for more information.   The build system ensures these prerequisites are built before running the genrule command; they are built using the [*exec* configuration](/versions/8.2.1/contribute/guide#configurations), since these tools are executed as part of the build. The path of an individual `tools` target `//x:y` can be obtained using `$(location //x:y)`.  Any `*_binary` or tool to be executed by `cmd` must appear in this list, not in `srcs`, to ensure they are built in the correct configuration. |
 
 ## starlark\_doc\_extract
@@ -571,5 +571,5 @@ test_suite(
 | Attributes | |
 | --- | --- |
 | `name` | [Name](/versions/8.2.1/concepts/labels#target-names); required  A unique name for this target. |
-| `tags` | List of strings; [nonconfigurable](common-definitions#configurable-attributes); default is `[]` List of text tags such as "small" or "database" or "-flaky". Tags may be any valid string. Tags which begin with a "-" character are considered negative tags. The preceding "-" character is not considered part of the tag, so a suite tag of "-small" matches a test's "small" size. All other tags are considered positive tags.  Optionally, to make positive tags more explicit, tags may also begin with the "+" character, which will not be evaluated as part of the text of the tag. It merely makes the positive and negative distinction easier to read.  Only test rules that match **all** of the positive tags and **none** of the negative tags will be included in the test suite. Note that this does not mean that error checking for dependencies on tests that are filtered out is skipped; the dependencies on skipped tests still need to be legal (e.g. not blocked by visibility constraints).  The `manual` tag keyword is treated differently than the above by the "test\_suite expansion" performed by the `bazel test` command on invocations involving wildcard [target patterns](https://bazel.build/versions/8.2.1/docs/build#specifying-build-targets). There, `test_suite` targets tagged "manual" are filtered out (and thus not expanded). This behavior is consistent with how `bazel build` and `bazel test` handle wildcard target patterns in general. Note that this is explicitly different from how `bazel query 'tests(E)'` behaves, as suites are always expanded by the `tests` query function, regardless of the `manual` tag.  Note that a test's `size` is considered a tag for the purpose of filtering.  If you need a `test_suite` that contains tests with mutually exclusive tags (e.g. all small and medium tests), you'll have to create three `test_suite` rules: one for all small tests, one for all medium tests, and one that includes the previous two. |
-| `tests` | List of [labels](/versions/8.2.1/concepts/labels); [nonconfigurable](common-definitions#configurable-attributes); default is `[]` A list of test suites and test targets of any language. Any `*_test` is accepted here, independent of the language. No `*_binary` targets are accepted however, even if they happen to run a test. Filtering by the specified `tags` is only done for tests listed directly in this attribute. If this attribute contains `test_suite`s, the tests inside those will not be filtered by this `test_suite` (they are considered to be filtered already).  If the `tests` attribute is unspecified or empty, the rule will default to including all test rules in the current BUILD file that are not tagged as `manual`. These rules are still subject to `tag` filtering. |
\ No newline at end of file
+| `tags` | List of strings; [nonconfigurable](/versions/8.2.1/reference/be/common-definitions#configurable-attributes); default is `[]` List of text tags such as "small" or "database" or "-flaky". Tags may be any valid string. Tags which begin with a "-" character are considered negative tags. The preceding "-" character is not considered part of the tag, so a suite tag of "-small" matches a test's "small" size. All other tags are considered positive tags.  Optionally, to make positive tags more explicit, tags may also begin with the "+" character, which will not be evaluated as part of the text of the tag. It merely makes the positive and negative distinction easier to read.  Only test rules that match **all** of the positive tags and **none** of the negative tags will be included in the test suite. Note that this does not mean that error checking for dependencies on tests that are filtered out is skipped; the dependencies on skipped tests still need to be legal (e.g. not blocked by visibility constraints).  The `manual` tag keyword is treated differently than the above by the "test\_suite expansion" performed by the `bazel test` command on invocations involving wildcard [target patterns](https://bazel.build/versions/8.2.1/docs/build#specifying-build-targets). There, `test_suite` targets tagged "manual" are filtered out (and thus not expanded). This behavior is consistent with how `bazel build` and `bazel test` handle wildcard target patterns in general. Note that this is explicitly different from how `bazel query 'tests(E)'` behaves, as suites are always expanded by the `tests` query function, regardless of the `manual` tag.  Note that a test's `size` is considered a tag for the purpose of filtering.  If you need a `test_suite` that contains tests with mutually exclusive tags (e.g. all small and medium tests), you'll have to create three `test_suite` rules: one for all small tests, one for all medium tests, and one that includes the previous two. |
+| `tests` | List of [labels](/versions/8.2.1/concepts/labels); [nonconfigurable](/versions/8.2.1/reference/be/common-definitions#configurable-attributes); default is `[]` A list of test suites and test targets of any language. Any `*_test` is accepted here, independent of the language. No `*_binary` targets are accepted however, even if they happen to run a test. Filtering by the specified `tags` is only done for tests listed directly in this attribute. If this attribute contains `test_suite`s, the tests inside those will not be filtered by this `test_suite` (they are considered to be filtered already).  If the `tests` attribute is unspecified or empty, the rule will default to including all test rules in the current BUILD file that are not tagged as `manual`. These rules are still subject to `tag` filtering. |
\ No newline at end of file
diff --git a/versions/8.2.1/reference/be/java.mdx b/versions/8.2.1/reference/be/java.mdx
index 013a1c18..9341c0c3 100644
--- a/versions/8.2.1/reference/be/java.mdx
+++ b/versions/8.2.1/reference/be/java.mdx
@@ -15,7 +15,7 @@ title: 'Java Rules'
 
 ## java\_binary
 
-[View rule sourceopen\_in\_new](@rules_java//java/bazel/rules/bazel_java_binary.bzl)
+[View rule sourceopen\_in\_new](/versions/8.2.1/reference/be/@rules_java//java/bazel/rules/bazel_java_binary.bzl)
 
 ```
 java_binary(name, deps, srcs, data, resources, add_exports, add_opens, args, bootclasspath, classpath_resources, compatible_with, create_executable, deploy_env, deploy_manifest_lines, deprecation, distribs, env, exec_compatible_with, exec_properties, features, javacopts, jvm_flags, launcher, licenses, main_class, neverlink, output_licenses, plugins, resource_strip_prefix, restricted_to, runtime_deps, stamp, tags, target_compatible_with, testonly, toolchains, use_launcher, use_testrunner, visibility)
@@ -102,7 +102,7 @@ java_binary(
 | Attributes | |
 | --- | --- |
 | `name` | [Name](/versions/8.2.1/concepts/labels#target-names); required  A unique name for this target. |
-| `deps` | List of [labels](/versions/8.2.1/concepts/labels); default is `[]` The list of other libraries to be linked in to the target. See general comments about `deps` at [Typical attributes defined by most build rules](common-definitions#typical-attributes). |
+| `deps` | List of [labels](/versions/8.2.1/concepts/labels); default is `[]` The list of other libraries to be linked in to the target. See general comments about `deps` at [Typical attributes defined by most build rules](/versions/8.2.1/reference/be/common-definitions#typical-attributes). |
 | `srcs` | List of [labels](/versions/8.2.1/concepts/labels); default is `[]` The list of source files that are processed to create the target. This attribute is almost always required; see exceptions below. Source files of type `.java` are compiled. In case of generated `.java` files it is generally advisable to put the generating rule's name here instead of the name of the file itself. This not only improves readability but makes the rule more resilient to future changes: if the generating rule generates different files in the future, you only need to fix one place: the `outs` of the generating rule. You should not list the generating rule in `deps` because it is a no-op.  Source files of type `.srcjar` are unpacked and compiled. (This is useful if you need to generate a set of `.java` files with a genrule.)  Rules: if the rule (typically `genrule` or `filegroup`) generates any of the files listed above, they will be used the same way as described for source files.  This argument is almost always required, except if a [`main_class`](#java_binary.main_class) attribute specifies a class on the runtime classpath or you specify the `runtime_deps` argument. |
 | `data` | List of [labels](/versions/8.2.1/concepts/labels); default is `[]` The list of files needed by this library at runtime. See general comments about `data` at [Typical attributes defined by most build rules](/versions/8.2.1/reference/be/common-definitions#typical-attributes). |
 | `resources` | List of [labels](/versions/8.2.1/concepts/labels); default is `[]` A list of data files to include in a Java jar. Resources may be source files or generated files.  If resources are specified, they will be bundled in the jar along with the usual `.class` files produced by compilation. The location of the resources inside of the jar file is determined by the project structure. Bazel first looks for Maven's [standard directory layout](https://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html), (a "src" directory followed by a "resources" directory grandchild). If that is not found, Bazel then looks for the topmost directory named "java" or "javatests" (so, for example, if a resource is at `/x/java/y/java/z`, the path of the resource will be `y/java/z`. This heuristic cannot be overridden, however, the `resource_strip_prefix` attribute can be used to specify a specific alternative directory for resource files. |
@@ -112,9 +112,9 @@ java_binary(
 | `classpath_resources` | List of [labels](/versions/8.2.1/concepts/labels); default is `[]` *DO NOT USE THIS OPTION UNLESS THERE IS NO OTHER WAY)* A list of resources that must be located at the root of the java tree. This attribute's only purpose is to support third-party libraries that require that their resources be found on the classpath as exactly `"myconfig.xml"`. It is only allowed on binaries and not libraries, due to the danger of namespace conflicts. |
 | `create_executable` | Boolean; default is `True` Deprecated, use `java_single_jar` instead. |
 | `deploy_env` | List of [labels](/versions/8.2.1/concepts/labels); default is `[]` A list of other `java_binary` targets which represent the deployment environment for this binary. Set this attribute when building a plugin which will be loaded by another `java_binary`.  Setting this attribute excludes all dependencies from the runtime classpath (and the deploy jar) of this binary that are shared between this binary and the targets specified in `deploy_env`. |
-| `deploy_manifest_lines` | List of strings; default is `[]` A list of lines to add to the `META-INF/manifest.mf` file generated for the `*_deploy.jar` target. The contents of this attribute are *not* subject to ["Make variable"](make-variables) substitution. |
-| `javacopts` | List of strings; default is `[]` Extra compiler options for this binary. Subject to ["Make variable"](make-variables) substitution and [Bourne shell tokenization](common-definitions#sh-tokenization). These compiler options are passed to javac after the global compiler options. |
-| `jvm_flags` | List of strings; default is `[]` A list of flags to embed in the wrapper script generated for running this binary. Subject to [$(location)](/versions/8.2.1/reference/be/make-variables#location) and ["Make variable"](make-variables) substitution, and [Bourne shell tokenization](common-definitions#sh-tokenization). The wrapper script for a Java binary includes a CLASSPATH definition (to find all the dependent jars) and invokes the right Java interpreter. The command line generated by the wrapper script includes the name of the main class followed by a `"$@"` so you can pass along other arguments after the classname. However, arguments intended for parsing by the JVM must be specified *before* the classname on the command line. The contents of `jvm_flags` are added to the wrapper script before the classname is listed.  Note that this attribute has *no effect* on `*_deploy.jar` outputs. |
+| `deploy_manifest_lines` | List of strings; default is `[]` A list of lines to add to the `META-INF/manifest.mf` file generated for the `*_deploy.jar` target. The contents of this attribute are *not* subject to ["Make variable"](/versions/8.2.1/reference/be/make-variables) substitution. |
+| `javacopts` | List of strings; default is `[]` Extra compiler options for this binary. Subject to ["Make variable"](/versions/8.2.1/reference/be/make-variables) substitution and [Bourne shell tokenization](/versions/8.2.1/reference/be/common-definitions#sh-tokenization). These compiler options are passed to javac after the global compiler options. |
+| `jvm_flags` | List of strings; default is `[]` A list of flags to embed in the wrapper script generated for running this binary. Subject to [$(location)](/versions/8.2.1/reference/be/make-variables#location) and ["Make variable"](/versions/8.2.1/reference/be/make-variables) substitution, and [Bourne shell tokenization](/versions/8.2.1/reference/be/common-definitions#sh-tokenization). The wrapper script for a Java binary includes a CLASSPATH definition (to find all the dependent jars) and invokes the right Java interpreter. The command line generated by the wrapper script includes the name of the main class followed by a `"$@"` so you can pass along other arguments after the classname. However, arguments intended for parsing by the JVM must be specified *before* the classname on the command line. The contents of `jvm_flags` are added to the wrapper script before the classname is listed.  Note that this attribute has *no effect* on `*_deploy.jar` outputs. |
 | `launcher` | [Label](/versions/8.2.1/concepts/labels); default is `None` Specify a binary that will be used to run your Java program instead of the normal `bin/java` program included with the JDK. The target must be a `cc_binary`. Any `cc_binary` that implements the [Java Invocation API](http://docs.oracle.com/javase/7/docs/technotes/guides/jni/spec/invocation.html) can be specified as a value for this attribute. By default, Bazel will use the normal JDK launcher (bin/java or java.exe).  The related [`--java_launcher`](/versions/8.2.1/docs/user-manual#flag--java_launcher) Bazel flag affects only those `java_binary` and `java_test` targets that have *not* specified a `launcher` attribute.  Note that your native (C++, SWIG, JNI) dependencies will be built differently depending on whether you are using the JDK launcher or another launcher:   * If you are using the normal JDK launcher (the default), native dependencies are   built as a shared library named `{name}_nativedeps.so`, where   `{name}` is the `name` attribute of this java\_binary rule.   Unused code is *not* removed by the linker in this configuration. * If you are using any other launcher, native (C++) dependencies are statically   linked into a binary named `{name}_nativedeps`, where `{name}`   is the `name` attribute of this java\_binary rule. In this case,   the linker will remove any code it thinks is unused from the resulting binary,   which means any C++ code accessed only via JNI may not be linked in unless   that `cc_library` target specifies `alwayslink = True`.   When using any launcher other than the default JDK launcher, the format of the `*_deploy.jar` output changes. See the main [java\_binary](#java_binary) docs for details. |
 | `main_class` | String; default is `""` Name of class with `main()` method to use as entry point. If a rule uses this option, it does not need a `srcs=[...]` list. Thus, with this attribute one can make an executable from a Java library that already contains one or more `main()` methods. The value of this attribute is a class name, not a source file. The class must be available at runtime: it may be compiled by this rule (from `srcs`) or provided by direct or transitive dependencies (through `runtime_deps` or `deps`). If the class is unavailable, the binary will fail at runtime; there is no build-time check. |
 | `neverlink` | Boolean; default is `False` |
@@ -127,7 +127,7 @@ java_binary(
 
 ## java\_import
 
-[View rule sourceopen\_in\_new](@rules_java//java/bazel/rules/bazel_java_import.bzl)
+[View rule sourceopen\_in\_new](/versions/8.2.1/reference/be/@rules_java//java/bazel/rules/bazel_java_import.bzl)
 
 ```
 java_import(name, deps, data, add_exports, add_opens, compatible_with, constraints, deprecation, distribs, exec_compatible_with, exec_properties, exports, features, jars, licenses, neverlink, proguard_specs, restricted_to, runtime_deps, srcjar, tags, target_compatible_with, testonly, toolchains, visibility)
@@ -169,7 +169,7 @@ libraries for `java_library` and
 
 ## java\_library
 
-[View rule sourceopen\_in\_new](@rules_java//java/bazel/rules/bazel_java_library.bzl)
+[View rule sourceopen\_in\_new](/versions/8.2.1/reference/be/@rules_java//java/bazel/rules/bazel_java_library.bzl)
 
 ```
 java_library(name, deps, srcs, data, resources, add_exports, add_opens, bootclasspath, compatible_with, deprecation, distribs, exec_compatible_with, exec_properties, exported_plugins, exports, features, javabuilder_jvm_flags, javacopts, licenses, neverlink, plugins, proguard_specs, resource_strip_prefix, restricted_to, runtime_deps, tags, target_compatible_with, testonly, toolchains, visibility)
@@ -198,7 +198,7 @@ This rule compiles and links sources into a `.jar` file.
 | `exported_plugins` | List of [labels](/versions/8.2.1/concepts/labels); default is `[]` The list of `java_plugin`s (e.g. annotation processors) to export to libraries that directly depend on this library. The specified list of `java_plugin`s will be applied to any library which directly depends on this library, just as if that library had explicitly declared these labels in `plugins`. |
 | `exports` | List of [labels](/versions/8.2.1/concepts/labels); default is `[]` Exported libraries. Listing rules here will make them available to parent rules, as if the parents explicitly depended on these rules. This is not true for regular (non-exported) `deps`.  Summary: a rule *X* can access the code in *Y* if there exists a dependency path between them that begins with a `deps` edge followed by zero or more `exports` edges. Let's see some examples to illustrate this.  Assume *A* depends on *B* and *B* depends on *C*. In this case C is a *transitive* dependency of A, so changing C's sources and rebuilding A will correctly rebuild everything. However A will not be able to use classes in C. To allow that, either A has to declare C in its `deps`, or B can make it easier for A (and anything that may depend on A) by declaring C in its (B's) `exports` attribute.  The closure of exported libraries is available to all direct parent rules. Take a slightly different example: A depends on B, B depends on C and D, and also exports C but not D. Now A has access to C but not to D. Now, if C and D exported some libraries, C' and D' respectively, A could only access C' but not D'.  Important: an exported rule is not a regular dependency. Sticking to the previous example, if B exports C and wants to also use C, it has to also list it in its own `deps`. |
 | `javabuilder_jvm_flags` | List of strings; default is `[]` Restricted API, do not use! |
-| `javacopts` | List of strings; default is `[]` Extra compiler options for this library. Subject to ["Make variable"](make-variables) substitution and [Bourne shell tokenization](common-definitions#sh-tokenization). These compiler options are passed to javac after the global compiler options. |
+| `javacopts` | List of strings; default is `[]` Extra compiler options for this library. Subject to ["Make variable"](/versions/8.2.1/reference/be/make-variables) substitution and [Bourne shell tokenization](/versions/8.2.1/reference/be/common-definitions#sh-tokenization). These compiler options are passed to javac after the global compiler options. |
 | `neverlink` | Boolean; default is `False` Whether this library should only be used for compilation and not at runtime. Useful if the library will be provided by the runtime environment during execution. Examples of such libraries are the IDE APIs for IDE plug-ins or `tools.jar` for anything running on a standard JDK. Note that `neverlink = True` does not prevent the compiler from inlining material from this library into compilation targets that depend on it, as permitted by the Java Language Specification (e.g., `static final` constants of `String` or of primitive types). The preferred use case is therefore when the runtime library is identical to the compilation library.  If the runtime library differs from the compilation library then you must ensure that it differs only in places that the JLS forbids compilers to inline (and that must hold for all future versions of the JLS). |
 | `plugins` | List of [labels](/versions/8.2.1/concepts/labels); default is `[]` Java compiler plugins to run at compile-time. Every `java_plugin` specified in this attribute will be run whenever this rule is built. A library may also inherit plugins from dependencies that use `exported_plugins`. Resources generated by the plugin will be included in the resulting jar of this rule. |
 | `proguard_specs` | List of [labels](/versions/8.2.1/concepts/labels); default is `[]` Files to be used as Proguard specification. These will describe the set of specifications to be used by Proguard. If specified, they will be added to any `android_binary` target depending on this library. The files included here must only have idempotent rules, namely -dontnote, -dontwarn, assumenosideeffects, and rules that start with -keep. Other options can only appear in `android_binary`'s proguard\_specs, to ensure non-tautological merges. |
@@ -207,7 +207,7 @@ This rule compiles and links sources into a `.jar` file.
 
 ## java\_test
 
-[View rule sourceopen\_in\_new](@rules_java//java/bazel/rules/bazel_java_test.bzl)
+[View rule sourceopen\_in\_new](/versions/8.2.1/reference/be/@rules_java//java/bazel/rules/bazel_java_test.bzl)
 
 ```
 java_test(name, deps, srcs, data, resources, add_exports, add_opens, args, bootclasspath, classpath_resources, compatible_with, create_executable, deploy_manifest_lines, deprecation, distribs, env, env_inherit, exec_compatible_with, exec_properties, features, flaky, javacopts, jvm_flags, launcher, licenses, local, main_class, neverlink, plugins, resource_strip_prefix, restricted_to, runtime_deps, shard_count, size, stamp, tags, target_compatible_with, test_class, testonly, timeout, toolchains, use_launcher, use_testrunner, visibility)
@@ -225,8 +225,7 @@ test code. The test runner's main method is invoked instead of the main class be
   [java\_binary](#java_binary) for more details.
 
 See the section on `java_binary()` arguments. This rule also
-supports all [attributes common
-to all test rules (\*\_test)](https://bazel.build/versions/8.2.1/reference/be/common-definitions#common-attributes-tests).
+supports all [attributes common to all test rules (\*\_test)](https://bazel.build/versions/8.2.1/reference/be/common-definitions#common-attributes-tests).
 
 #### Examples
 
@@ -255,7 +254,7 @@ java_test(
 | Attributes | |
 | --- | --- |
 | `name` | [Name](/versions/8.2.1/concepts/labels#target-names); required  A unique name for this target. |
-| `deps` | List of [labels](/versions/8.2.1/concepts/labels); default is `[]` The list of other libraries to be linked in to the target. See general comments about `deps` at [Typical attributes defined by most build rules](common-definitions#typical-attributes). |
+| `deps` | List of [labels](/versions/8.2.1/concepts/labels); default is `[]` The list of other libraries to be linked in to the target. See general comments about `deps` at [Typical attributes defined by most build rules](/versions/8.2.1/reference/be/common-definitions#typical-attributes). |
 | `srcs` | List of [labels](/versions/8.2.1/concepts/labels); default is `[]` The list of source files that are processed to create the target. This attribute is almost always required; see exceptions below. Source files of type `.java` are compiled. In case of generated `.java` files it is generally advisable to put the generating rule's name here instead of the name of the file itself. This not only improves readability but makes the rule more resilient to future changes: if the generating rule generates different files in the future, you only need to fix one place: the `outs` of the generating rule. You should not list the generating rule in `deps` because it is a no-op.  Source files of type `.srcjar` are unpacked and compiled. (This is useful if you need to generate a set of `.java` files with a genrule.)  Rules: if the rule (typically `genrule` or `filegroup`) generates any of the files listed above, they will be used the same way as described for source files.  This argument is almost always required, except if a [`main_class`](#java_binary.main_class) attribute specifies a class on the runtime classpath or you specify the `runtime_deps` argument. |
 | `data` | List of [labels](/versions/8.2.1/concepts/labels); default is `[]` The list of files needed by this library at runtime. See general comments about `data` at [Typical attributes defined by most build rules](/versions/8.2.1/reference/be/common-definitions#typical-attributes). |
 | `resources` | List of [labels](/versions/8.2.1/concepts/labels); default is `[]` A list of data files to include in a Java jar. Resources may be source files or generated files.  If resources are specified, they will be bundled in the jar along with the usual `.class` files produced by compilation. The location of the resources inside of the jar file is determined by the project structure. Bazel first looks for Maven's [standard directory layout](https://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html), (a "src" directory followed by a "resources" directory grandchild). If that is not found, Bazel then looks for the topmost directory named "java" or "javatests" (so, for example, if a resource is at `/x/java/y/java/z`, the path of the resource will be `y/java/z`. This heuristic cannot be overridden, however, the `resource_strip_prefix` attribute can be used to specify a specific alternative directory for resource files. |
@@ -264,9 +263,9 @@ java_test(
 | `bootclasspath` | [Label](/versions/8.2.1/concepts/labels); default is `None` Restricted API, do not use! |
 | `classpath_resources` | List of [labels](/versions/8.2.1/concepts/labels); default is `[]` *DO NOT USE THIS OPTION UNLESS THERE IS NO OTHER WAY)* A list of resources that must be located at the root of the java tree. This attribute's only purpose is to support third-party libraries that require that their resources be found on the classpath as exactly `"myconfig.xml"`. It is only allowed on binaries and not libraries, due to the danger of namespace conflicts. |
 | `create_executable` | Boolean; default is `True` Deprecated, use `java_single_jar` instead. |
-| `deploy_manifest_lines` | List of strings; default is `[]` A list of lines to add to the `META-INF/manifest.mf` file generated for the `*_deploy.jar` target. The contents of this attribute are *not* subject to ["Make variable"](make-variables) substitution. |
-| `javacopts` | List of strings; default is `[]` Extra compiler options for this binary. Subject to ["Make variable"](make-variables) substitution and [Bourne shell tokenization](common-definitions#sh-tokenization). These compiler options are passed to javac after the global compiler options. |
-| `jvm_flags` | List of strings; default is `[]` A list of flags to embed in the wrapper script generated for running this binary. Subject to [$(location)](/versions/8.2.1/reference/be/make-variables#location) and ["Make variable"](make-variables) substitution, and [Bourne shell tokenization](common-definitions#sh-tokenization). The wrapper script for a Java binary includes a CLASSPATH definition (to find all the dependent jars) and invokes the right Java interpreter. The command line generated by the wrapper script includes the name of the main class followed by a `"$@"` so you can pass along other arguments after the classname. However, arguments intended for parsing by the JVM must be specified *before* the classname on the command line. The contents of `jvm_flags` are added to the wrapper script before the classname is listed.  Note that this attribute has *no effect* on `*_deploy.jar` outputs. |
+| `deploy_manifest_lines` | List of strings; default is `[]` A list of lines to add to the `META-INF/manifest.mf` file generated for the `*_deploy.jar` target. The contents of this attribute are *not* subject to ["Make variable"](/versions/8.2.1/reference/be/make-variables) substitution. |
+| `javacopts` | List of strings; default is `[]` Extra compiler options for this binary. Subject to ["Make variable"](/versions/8.2.1/reference/be/make-variables) substitution and [Bourne shell tokenization](/versions/8.2.1/reference/be/common-definitions#sh-tokenization). These compiler options are passed to javac after the global compiler options. |
+| `jvm_flags` | List of strings; default is `[]` A list of flags to embed in the wrapper script generated for running this binary. Subject to [$(location)](/versions/8.2.1/reference/be/make-variables#location) and ["Make variable"](/versions/8.2.1/reference/be/make-variables) substitution, and [Bourne shell tokenization](/versions/8.2.1/reference/be/common-definitions#sh-tokenization). The wrapper script for a Java binary includes a CLASSPATH definition (to find all the dependent jars) and invokes the right Java interpreter. The command line generated by the wrapper script includes the name of the main class followed by a `"$@"` so you can pass along other arguments after the classname. However, arguments intended for parsing by the JVM must be specified *before* the classname on the command line. The contents of `jvm_flags` are added to the wrapper script before the classname is listed.  Note that this attribute has *no effect* on `*_deploy.jar` outputs. |
 | `launcher` | [Label](/versions/8.2.1/concepts/labels); default is `None` Specify a binary that will be used to run your Java program instead of the normal `bin/java` program included with the JDK. The target must be a `cc_binary`. Any `cc_binary` that implements the [Java Invocation API](http://docs.oracle.com/javase/7/docs/technotes/guides/jni/spec/invocation.html) can be specified as a value for this attribute. By default, Bazel will use the normal JDK launcher (bin/java or java.exe).  The related [`--java_launcher`](/versions/8.2.1/docs/user-manual#flag--java_launcher) Bazel flag affects only those `java_binary` and `java_test` targets that have *not* specified a `launcher` attribute.  Note that your native (C++, SWIG, JNI) dependencies will be built differently depending on whether you are using the JDK launcher or another launcher:   * If you are using the normal JDK launcher (the default), native dependencies are   built as a shared library named `{name}_nativedeps.so`, where   `{name}` is the `name` attribute of this java\_binary rule.   Unused code is *not* removed by the linker in this configuration. * If you are using any other launcher, native (C++) dependencies are statically   linked into a binary named `{name}_nativedeps`, where `{name}`   is the `name` attribute of this java\_binary rule. In this case,   the linker will remove any code it thinks is unused from the resulting binary,   which means any C++ code accessed only via JNI may not be linked in unless   that `cc_library` target specifies `alwayslink = True`.   When using any launcher other than the default JDK launcher, the format of the `*_deploy.jar` output changes. See the main [java\_binary](#java_binary) docs for details. |
 | `main_class` | String; default is `""` Name of class with `main()` method to use as entry point. If a rule uses this option, it does not need a `srcs=[...]` list. Thus, with this attribute one can make an executable from a Java library that already contains one or more `main()` methods. The value of this attribute is a class name, not a source file. The class must be available at runtime: it may be compiled by this rule (from `srcs`) or provided by direct or transitive dependencies (through `runtime_deps` or `deps`). If the class is unavailable, the binary will fail at runtime; there is no build-time check. |
 | `neverlink` | Boolean; default is `False` |
@@ -280,7 +279,7 @@ java_test(
 
 ## java\_package\_configuration
 
-[View rule sourceopen\_in\_new](@rules_java//java/common/rules/java_package_configuration.bzl)
+[View rule sourceopen\_in\_new](/versions/8.2.1/reference/be/@rules_java//java/common/rules/java_package_configuration.bzl)
 
 ```
 java_package_configuration(name, data, compatible_with, deprecation, distribs, exec_compatible_with, exec_properties, features, javacopts, output_licenses, packages, restricted_to, system, tags, target_compatible_with, testonly, toolchains, visibility)
@@ -328,7 +327,7 @@ java_toolchain(
 
 ## java\_plugin
 
-[View rule sourceopen\_in\_new](@rules_java//java/bazel/rules/bazel_java_plugin.bzl)
+[View rule sourceopen\_in\_new](/versions/8.2.1/reference/be/@rules_java//java/bazel/rules/bazel_java_plugin.bzl)
 
 ```
 java_plugin(name, deps, srcs, data, resources, add_exports, add_opens, bootclasspath, compatible_with, deprecation, distribs, exec_compatible_with, exec_properties, features, generates_api, javabuilder_jvm_flags, javacopts, licenses, neverlink, output_licenses, plugins, processor_class, proguard_specs, resource_strip_prefix, restricted_to, tags, target_compatible_with, testonly, toolchains, visibility)
@@ -362,7 +361,7 @@ for the addition of the `processor_class` argument.
 | `bootclasspath` | [Label](/versions/8.2.1/concepts/labels); default is `None` Restricted API, do not use! |
 | `generates_api` | Boolean; default is `False` This attribute marks annotation processors that generate API code. If a rule uses an API-generating annotation processor, other rules depending on it can refer to the generated code only if their compilation actions are scheduled after the generating rule. This attribute instructs Bazel to introduce scheduling constraints when --java\_header\_compilation is enabled. *WARNING: This attribute affects build performance, use it only if necessary.* |
 | `javabuilder_jvm_flags` | List of strings; default is `[]` Restricted API, do not use! |
-| `javacopts` | List of strings; default is `[]` Extra compiler options for this library. Subject to ["Make variable"](make-variables) substitution and [Bourne shell tokenization](common-definitions#sh-tokenization). These compiler options are passed to javac after the global compiler options. |
+| `javacopts` | List of strings; default is `[]` Extra compiler options for this library. Subject to ["Make variable"](/versions/8.2.1/reference/be/make-variables) substitution and [Bourne shell tokenization](/versions/8.2.1/reference/be/common-definitions#sh-tokenization). These compiler options are passed to javac after the global compiler options. |
 | `neverlink` | Boolean; default is `False` Whether this library should only be used for compilation and not at runtime. Useful if the library will be provided by the runtime environment during execution. Examples of such libraries are the IDE APIs for IDE plug-ins or `tools.jar` for anything running on a standard JDK. Note that `neverlink = True` does not prevent the compiler from inlining material from this library into compilation targets that depend on it, as permitted by the Java Language Specification (e.g., `static final` constants of `String` or of primitive types). The preferred use case is therefore when the runtime library is identical to the compilation library.  If the runtime library differs from the compilation library then you must ensure that it differs only in places that the JLS forbids compilers to inline (and that must hold for all future versions of the JLS). |
 | `output_licenses` | List of strings; default is `[]` |
 | `plugins` | List of [labels](/versions/8.2.1/concepts/labels); default is `[]` Java compiler plugins to run at compile-time. Every `java_plugin` specified in this attribute will be run whenever this rule is built. A library may also inherit plugins from dependencies that use `exported_plugins`. Resources generated by the plugin will be included in the resulting jar of this rule. |
@@ -372,7 +371,7 @@ for the addition of the `processor_class` argument.
 
 ## java\_runtime
 
-[View rule sourceopen\_in\_new](@rules_java//java/common/rules/java_runtime.bzl)
+[View rule sourceopen\_in\_new](/versions/8.2.1/reference/be/@rules_java//java/common/rules/java_runtime.bzl)
 
 ```
 java_runtime(name, srcs, compatible_with, default_cds, deprecation, distribs, exec_compatible_with, exec_properties, features, hermetic_srcs, hermetic_static_libs, java, java_home, lib_ct_sym, lib_modules, output_licenses, restricted_to, tags, target_compatible_with, testonly, toolchains, version, visibility)
@@ -408,7 +407,7 @@ java_runtime(
 
 ## java\_toolchain
 
-[View rule sourceopen\_in\_new](@rules_java//java/common/rules/java_toolchain.bzl)
+[View rule sourceopen\_in\_new](/versions/8.2.1/reference/be/@rules_java//java/common/rules/java_toolchain.bzl)
 
 ```
 java_toolchain(name, android_lint_data, android_lint_jvm_opts, android_lint_opts, android_lint_package_configuration, android_lint_runner, bootclasspath, compatible_javacopts, compatible_with, deprecation, deps_checker, distribs, exec_compatible_with, exec_properties, features, forcibly_disable_header_compilation, genclass, header_compiler, header_compiler_builtin_processors, header_compiler_direct, ijar, jacocorunner, java_runtime, javabuilder, javabuilder_data, javabuilder_jvm_opts, javac_supports_multiplex_workers, javac_supports_worker_cancellation, javac_supports_worker_multiplex_sandboxing, javac_supports_workers, javacopts, jspecify_implicit_deps, jspecify_javacopts, jspecify_packages, jspecify_processor, jspecify_processor_class, jspecify_stubs, jvm_opts, licenses, misc, oneversion, oneversion_allowlist, oneversion_allowlist_for_tests, oneversion_whitelist, package_configuration, proguard_allowlister, reduced_classpath_incompatible_processors, restricted_to, singlejar, source_version, tags, target_compatible_with, target_version, testonly, timezone_data, toolchains, tools, turbine_data, turbine_jvm_opts, visibility, xlint)
diff --git a/versions/8.2.1/reference/be/make-variables.mdx b/versions/8.2.1/reference/be/make-variables.mdx
index 55438eda..876f9424 100644
--- a/versions/8.2.1/reference/be/make-variables.mdx
+++ b/versions/8.2.1/reference/be/make-variables.mdx
@@ -19,8 +19,7 @@ targets, and *custom* variables, which are defined in dependency targets
 and only available to targets that depend on them.
 
 The reason for the term "Make" is historical: the syntax and semantics of
-these variables were originally intended to match [GNU
-Make](https://www.gnu.org/software/make/manual/html_node/Using-Variables.html).
+these variables were originally intended to match [GNU Make](https://www.gnu.org/software/make/manual/html_node/Using-Variables.html).
 
 ## Use
 
@@ -64,8 +63,7 @@ and look at the top output lines with capital letters.
 **Toolchain option variables**
 
 * `COMPILATION_MODE`:
-  `fastbuild`, `dbg`, or `opt`. ([more
-  details](https://bazel.build/versions/8.2.1/docs/user-manual#flag--compilation_mode))
+  `fastbuild`, `dbg`, or `opt`. ([more details](https://bazel.build/versions/8.2.1/docs/user-manual#flag--compilation_mode))
 
 **Path variables**
 
@@ -304,7 +302,7 @@ rare cases. If you are tempted to use them, please [contact the Bazel devs](http
 
 Rule and [toolchain](/versions/8.2.1/docs/toolchains) writers can define
 completely custom variables by returning a
-[TemplateVariableInfo](/versions/8.2.1/rules/lib/TemplateVariableInfo)
+[TemplateVariableInfo](/versions/8.2.1/rules/lib/providers/TemplateVariableInfo)
 provider. Any rules depending on these through the
 `toolchains` attribute can then read their values:
 
diff --git a/versions/8.2.1/reference/be/overview.mdx b/versions/8.2.1/reference/be/overview.mdx
index d1946430..1df4fedc 100644
--- a/versions/8.2.1/reference/be/overview.mdx
+++ b/versions/8.2.1/reference/be/overview.mdx
@@ -37,18 +37,18 @@ For non-native Starlark rules that ship separately from Bazel, see the list of
 
 | Language | Binary rules | Library rules | Test rules | Other rules |
 | --- | --- | --- | --- | --- |
-| C / C++ | [cc\_binary](c-cpp#cc_binary) | [cc\_import](c-cpp#cc_import)   [cc\_library](c-cpp#cc_library)   [cc\_shared\_library](c-cpp#cc_shared_library)   [cc\_static\_library](c-cpp#cc_static_library) | [cc\_test](c-cpp#cc_test) | [cc\_toolchain](c-cpp#cc_toolchain)   [cc\_toolchain\_suite](c-cpp#cc_toolchain_suite)   [fdo\_prefetch\_hints](c-cpp#fdo_prefetch_hints)   [fdo\_profile](c-cpp#fdo_profile)   [memprof\_profile](c-cpp#memprof_profile)   [propeller\_optimize](c-cpp#propeller_optimize) |
-| Java | [java\_binary](java#java_binary) | [java\_import](java#java_import)   [java\_library](java#java_library) | [java\_test](java#java_test) | [java\_package\_configuration](java#java_package_configuration)   [java\_plugin](java#java_plugin)   [java\_runtime](java#java_runtime)   [java\_toolchain](java#java_toolchain) |
-| Objective-C |  | [objc\_import](objective-c#objc_import)   [objc\_library](objective-c#objc_library) |  |  |
-| Protocol Buffer |  | [cc\_proto\_library](protocol-buffer#cc_proto_library)   [java\_lite\_proto\_library](protocol-buffer#java_lite_proto_library)   [java\_proto\_library](protocol-buffer#java_proto_library)   [proto\_library](protocol-buffer#proto_library)   [py\_proto\_library](protocol-buffer#py_proto_library) |  | [proto\_lang\_toolchain](protocol-buffer#proto_lang_toolchain)   [proto\_toolchain](protocol-buffer#proto_toolchain) |
-| Python | [py\_binary](python#py_binary) | [py\_library](python#py_library) | [py\_test](python#py_test) | [py\_runtime](python#py_runtime) |
-| Shell | [sh\_binary](shell#sh_binary) | [sh\_library](shell#sh_library) | [sh\_test](shell#sh_test) |  |
+| C / C++ | [cc\_binary](/versions/8.2.1/reference/be/c-cpp#cc_binary) | [cc\_import](/versions/8.2.1/reference/be/c-cpp#cc_import)   [cc\_library](/versions/8.2.1/reference/be/c-cpp#cc_library)   [cc\_shared\_library](/versions/8.2.1/reference/be/c-cpp#cc_shared_library)   [cc\_static\_library](/versions/8.2.1/reference/be/c-cpp#cc_static_library) | [cc\_test](/versions/8.2.1/reference/be/c-cpp#cc_test) | [cc\_toolchain](/versions/8.2.1/reference/be/c-cpp#cc_toolchain)   [cc\_toolchain\_suite](/versions/8.2.1/reference/be/c-cpp#cc_toolchain_suite)   [fdo\_prefetch\_hints](/versions/8.2.1/reference/be/c-cpp#fdo_prefetch_hints)   [fdo\_profile](/versions/8.2.1/reference/be/c-cpp#fdo_profile)   [memprof\_profile](/versions/8.2.1/reference/be/c-cpp#memprof_profile)   [propeller\_optimize](/versions/8.2.1/reference/be/c-cpp#propeller_optimize) |
+| Java | [java\_binary](/versions/8.2.1/reference/be/java#java_binary) | [java\_import](/versions/8.2.1/reference/be/java#java_import)   [java\_library](/versions/8.2.1/reference/be/java#java_library) | [java\_test](/versions/8.2.1/reference/be/java#java_test) | [java\_package\_configuration](/versions/8.2.1/reference/be/java#java_package_configuration)   [java\_plugin](/versions/8.2.1/reference/be/java#java_plugin)   [java\_runtime](/versions/8.2.1/reference/be/java#java_runtime)   [java\_toolchain](/versions/8.2.1/reference/be/java#java_toolchain) |
+| Objective-C |  | [objc\_import](/versions/8.2.1/reference/be/objective-c#objc_import)   [objc\_library](/versions/8.2.1/reference/be/objective-c#objc_library) |  |  |
+| Protocol Buffer |  | [cc\_proto\_library](/versions/8.2.1/reference/be/protocol-buffer#cc_proto_library)   [java\_lite\_proto\_library](/versions/8.2.1/reference/be/protocol-buffer#java_lite_proto_library)   [java\_proto\_library](/versions/8.2.1/reference/be/protocol-buffer#java_proto_library)   [proto\_library](/versions/8.2.1/reference/be/protocol-buffer#proto_library)   [py\_proto\_library](/versions/8.2.1/reference/be/protocol-buffer#py_proto_library) |  | [proto\_lang\_toolchain](/versions/8.2.1/reference/be/protocol-buffer#proto_lang_toolchain)   [proto\_toolchain](/versions/8.2.1/reference/be/protocol-buffer#proto_toolchain) |
+| Python | [py\_binary](/versions/8.2.1/reference/be/python#py_binary) | [py\_library](/versions/8.2.1/reference/be/python#py_library) | [py\_test](/versions/8.2.1/reference/be/python#py_test) | [py\_runtime](/versions/8.2.1/reference/be/python#py_runtime) |
+| Shell | [sh\_binary](/versions/8.2.1/reference/be/shell#sh_binary) | [sh\_library](/versions/8.2.1/reference/be/shell#sh_library) | [sh\_test](/versions/8.2.1/reference/be/shell#sh_test) |  |
 
 ### Language-agnostic native rules
 
 | Family | Rules |
 | --- | --- |
-| Extra Actions | * [action\_listener](extra-actions#action_listener)* [extra\_action](extra-actions#extra_action) |
-| General | * [alias](general#alias)* [config\_setting](general#config_setting)* [filegroup](general#filegroup)* [genquery](general#genquery)* [genrule](general#genrule)* [starlark\_doc\_extract](general#starlark_doc_extract)* [test\_suite](general#test_suite) |
-| Platforms and Toolchains | * [constraint\_setting](platforms-and-toolchains#constraint_setting)* [constraint\_value](platforms-and-toolchains#constraint_value)* [platform](platforms-and-toolchains#platform)* [toolchain](platforms-and-toolchains#toolchain)* [toolchain\_type](platforms-and-toolchains#toolchain_type) |
-| Workspace | * [bind](workspace#bind)* [local\_repository](workspace#local_repository)* [new\_local\_repository](workspace#new_local_repository) |
\ No newline at end of file
+| Extra Actions | * [action\_listener](/versions/8.2.1/reference/be/extra-actions#action_listener)* [extra\_action](/versions/8.2.1/reference/be/extra-actions#extra_action) |
+| General | * [alias](/versions/8.2.1/reference/be/general#alias)* [config\_setting](/versions/8.2.1/reference/be/general#config_setting)* [filegroup](/versions/8.2.1/reference/be/general#filegroup)* [genquery](/versions/8.2.1/reference/be/general#genquery)* [genrule](/versions/8.2.1/reference/be/general#genrule)* [starlark\_doc\_extract](/versions/8.2.1/reference/be/general#starlark_doc_extract)* [test\_suite](/versions/8.2.1/reference/be/general#test_suite) |
+| Platforms and Toolchains | * [constraint\_setting](/versions/8.2.1/reference/be/platforms-and-toolchains#constraint_setting)* [constraint\_value](/versions/8.2.1/reference/be/platforms-and-toolchains#constraint_value)* [platform](/versions/8.2.1/reference/be/platforms-and-toolchains#platform)* [toolchain](/versions/8.2.1/reference/be/platforms-and-toolchains#toolchain)* [toolchain\_type](/versions/8.2.1/reference/be/platforms-and-toolchains#toolchain_type) |
+| Workspace | * [bind](/versions/8.2.1/reference/be/workspace#bind)* [local\_repository](/versions/8.2.1/reference/be/workspace#local_repository)* [new\_local\_repository](/versions/8.2.1/reference/be/workspace#new_local_repository) |
\ No newline at end of file
diff --git a/versions/8.2.1/reference/be/platforms-and-toolchains.mdx b/versions/8.2.1/reference/be/platforms-and-toolchains.mdx
index 14cd450d..e3c09737 100644
--- a/versions/8.2.1/reference/be/platforms-and-toolchains.mdx
+++ b/versions/8.2.1/reference/be/platforms-and-toolchains.mdx
@@ -39,7 +39,7 @@ define a platform targeting an obscure cpu architecture.
 | Attributes | |
 | --- | --- |
 | `name` | [Name](/versions/8.2.1/concepts/labels#target-names); required  A unique name for this target. |
-| `default_constraint_value` | [Name](/versions/8.2.1/concepts/labels#target-names); [nonconfigurable](common-definitions#configurable-attributes); default is `None` The label of the default value for this setting, to be used if no value is given. If this attribute is present, the `constraint_value` it points to must be defined in the same package as this `constraint_setting`. If a constraint setting has a default value, then whenever a platform does not include any constraint value for that setting, it is the same as if the platform had specified the default value. Otherwise, if there is no default value, the constraint setting is considered to be unspecified by that platform. In that case, the platform would not match against any constraint list (such as for a `config_setting`) that requires a particular value for that setting. |
+| `default_constraint_value` | [Name](/versions/8.2.1/concepts/labels#target-names); [nonconfigurable](/versions/8.2.1/reference/be/common-definitions#configurable-attributes); default is `None` The label of the default value for this setting, to be used if no value is given. If this attribute is present, the `constraint_value` it points to must be defined in the same package as this `constraint_setting`. If a constraint setting has a default value, then whenever a platform does not include any constraint value for that setting, it is the same as if the platform had specified the default value. Otherwise, if there is no default value, the constraint setting is considered to be unspecified by that platform. In that case, the platform would not match against any constraint list (such as for a `config_setting`) that requires a particular value for that setting. |
 
 ## constraint\_value
 
@@ -73,7 +73,7 @@ Platforms can then declare that they have the `mips` architecture as an alternat
 | Attributes | |
 | --- | --- |
 | `name` | [Name](/versions/8.2.1/concepts/labels#target-names); required  A unique name for this target. |
-| `constraint_setting` | [Label](/versions/8.2.1/concepts/labels); [nonconfigurable](common-definitions#configurable-attributes); required The `constraint_setting` for which this `constraint_value` is a possible choice. |
+| `constraint_setting` | [Label](/versions/8.2.1/concepts/labels); [nonconfigurable](/versions/8.2.1/reference/be/common-definitions#configurable-attributes); required The `constraint_setting` for which this `constraint_value` is a possible choice. |
 
 ## platform
 
@@ -278,12 +278,12 @@ In this example, the child platforms have the following properties:
 | Attributes | |
 | --- | --- |
 | `name` | [Name](/versions/8.2.1/concepts/labels#target-names); required  A unique name for this target. |
-| `constraint_values` | List of [labels](/versions/8.2.1/concepts/labels); [nonconfigurable](common-definitions#configurable-attributes); default is `[]` The combination of constraint choices that this platform comprises. In order for a platform to apply to a given environment, the environment must have at least the values in this list. Each `constraint_value` in this list must be for a different `constraint_setting`. For example, you cannot define a platform that requires the cpu architecture to be both `@platforms//cpu:x86_64` and `@platforms//cpu:arm`. |
-| `exec_properties` | Dictionary: String -> String; [nonconfigurable](common-definitions#configurable-attributes); default is `{}` A map of strings that affect the way actions are executed remotely. Bazel makes no attempt to interpret this, it is treated as opaque data that's forwarded via the Platform field of the [remote execution protocol](https://github.com/bazelbuild/remote-apis). This includes any data from the parent platform's `exec_properties` attributes. If the child and parent platform define the same keys, the child's values are kept. Any keys associated with a value that is an empty string are removed from the dictionary. This attribute is a full replacement for the deprecated `remote_execution_properties`. |
-| `flags` | List of strings; [nonconfigurable](common-definitions#configurable-attributes); default is `[]` A list of flags that will be enabled when this platform is used as the target platform in a configuration. Only flags that can be set in transitions are allowed to be used. |
-| `missing_toolchain_error` | String; [nonconfigurable](common-definitions#configurable-attributes); default is `"For more information on platforms or toolchains see https://bazel.build/concepts/platforms-intro."` A custom error message that is displayed when a mandatory toolchain requirement cannot be satisfied for this target platform. Intended to point to relevant documentation users can read to understand why their toolchains are misconfigured. Not inherited from parent platforms. |
-| `parents` | List of [labels](/versions/8.2.1/concepts/labels); [nonconfigurable](common-definitions#configurable-attributes); default is `[]` The label of a `platform` target that this platform should inherit from. Although the attribute takes a list, there should be no more than one platform present. Any constraint\_settings not set directly on this platform will be found in the parent platform. See the section on [Platform Inheritance](#platform_inheritance) for details. |
-| `remote_execution_properties` | String; [nonconfigurable](common-definitions#configurable-attributes); default is `""` DEPRECATED. Please use exec\_properties attribute instead. A string used to configure a remote execution platform. Actual builds make no attempt to interpret this, it is treated as opaque data that can be used by a specific SpawnRunner. This can include data from the parent platform's "remote_execution_properties" attribute, by using the macro `{PARENT_REMOTE_EXECUTION_PROPERTIES}`. See the section on [Platform Inheritance](#platform_inheritance) for details. |
+| `constraint_values` | List of [labels](/versions/8.2.1/concepts/labels); [nonconfigurable](/versions/8.2.1/reference/be/common-definitions#configurable-attributes); default is `[]` The combination of constraint choices that this platform comprises. In order for a platform to apply to a given environment, the environment must have at least the values in this list. Each `constraint_value` in this list must be for a different `constraint_setting`. For example, you cannot define a platform that requires the cpu architecture to be both `@platforms//cpu:x86_64` and `@platforms//cpu:arm`. |
+| `exec_properties` | Dictionary: String -> String; [nonconfigurable](/versions/8.2.1/reference/be/common-definitions#configurable-attributes); default is `{}` A map of strings that affect the way actions are executed remotely. Bazel makes no attempt to interpret this, it is treated as opaque data that's forwarded via the Platform field of the [remote execution protocol](https://github.com/bazelbuild/remote-apis). This includes any data from the parent platform's `exec_properties` attributes. If the child and parent platform define the same keys, the child's values are kept. Any keys associated with a value that is an empty string are removed from the dictionary. This attribute is a full replacement for the deprecated `remote_execution_properties`. |
+| `flags` | List of strings; [nonconfigurable](/versions/8.2.1/reference/be/common-definitions#configurable-attributes); default is `[]` A list of flags that will be enabled when this platform is used as the target platform in a configuration. Only flags that can be set in transitions are allowed to be used. |
+| `missing_toolchain_error` | String; [nonconfigurable](/versions/8.2.1/reference/be/common-definitions#configurable-attributes); default is `"For more information on platforms or toolchains see https://bazel.build/concepts/platforms-intro."` A custom error message that is displayed when a mandatory toolchain requirement cannot be satisfied for this target platform. Intended to point to relevant documentation users can read to understand why their toolchains are misconfigured. Not inherited from parent platforms. |
+| `parents` | List of [labels](/versions/8.2.1/concepts/labels); [nonconfigurable](/versions/8.2.1/reference/be/common-definitions#configurable-attributes); default is `[]` The label of a `platform` target that this platform should inherit from. Although the attribute takes a list, there should be no more than one platform present. Any constraint\_settings not set directly on this platform will be found in the parent platform. See the section on [Platform Inheritance](#platform_inheritance) for details. |
+| `remote_execution_properties` | String; [nonconfigurable](/versions/8.2.1/reference/be/common-definitions#configurable-attributes); default is `""` DEPRECATED. Please use exec\_properties attribute instead. A string used to configure a remote execution platform. Actual builds make no attempt to interpret this, it is treated as opaque data that can be used by a specific SpawnRunner. This can include data from the parent platform's "remote_execution_properties" attribute, by using the macro `{PARENT_REMOTE_EXECUTION_PROPERTIES}`. See the section on [Platform Inheritance](#platform_inheritance) for details. |
 | `required_settings` | List of [labels](/versions/8.2.1/concepts/labels); default is `[]` A list of `config_setting`s that must be satisfied by the target configuration in order for this platform to be used as an execution platform during toolchain resolution. Required settings are not inherited from parent platforms. |
 
 ## toolchain
@@ -304,12 +304,12 @@ details.
 | Attributes | |
 | --- | --- |
 | `name` | [Name](/versions/8.2.1/concepts/labels#target-names); required  A unique name for this target. |
-| `exec_compatible_with` | List of [labels](/versions/8.2.1/concepts/labels); [nonconfigurable](common-definitions#configurable-attributes); default is `[]` A list of `constraint_value`s that must be satisfied by an execution platform in order for this toolchain to be selected for a target building on that platform. |
-| `target_compatible_with` | List of [labels](/versions/8.2.1/concepts/labels); [nonconfigurable](common-definitions#configurable-attributes); default is `[]` A list of `constraint_value`s that must be satisfied by the target platform in order for this toolchain to be selected for a target building for that platform. |
+| `exec_compatible_with` | List of [labels](/versions/8.2.1/concepts/labels); [nonconfigurable](/versions/8.2.1/reference/be/common-definitions#configurable-attributes); default is `[]` A list of `constraint_value`s that must be satisfied by an execution platform in order for this toolchain to be selected for a target building on that platform. |
+| `target_compatible_with` | List of [labels](/versions/8.2.1/concepts/labels); [nonconfigurable](/versions/8.2.1/reference/be/common-definitions#configurable-attributes); default is `[]` A list of `constraint_value`s that must be satisfied by the target platform in order for this toolchain to be selected for a target building for that platform. |
 | `target_settings` | List of [labels](/versions/8.2.1/concepts/labels); default is `[]` A list of `config_setting`s that must be satisfied by the target configuration in order for this toolchain to be selected during toolchain resolution. |
 | `toolchain` | [Name](/versions/8.2.1/concepts/labels#target-names); required The target representing the actual tool or tool suite that is made available when this toolchain is selected. |
-| `toolchain_type` | [Label](/versions/8.2.1/concepts/labels); [nonconfigurable](common-definitions#configurable-attributes); required The label of a `toolchain_type` target that represents the role that this toolchain serves. |
-| `use_target_platform_constraints` | Boolean; [nonconfigurable](common-definitions#configurable-attributes); default is `False` If `True`, this toolchain behaves as if its `exec_compatible_with` and `target_compatible_with` constraints are set to those of the current target platform. `exec_compatible_with` and `target_compatible_with` must not be set in that case. |
+| `toolchain_type` | [Label](/versions/8.2.1/concepts/labels); [nonconfigurable](/versions/8.2.1/reference/be/common-definitions#configurable-attributes); required The label of a `toolchain_type` target that represents the role that this toolchain serves. |
+| `use_target_platform_constraints` | Boolean; [nonconfigurable](/versions/8.2.1/reference/be/common-definitions#configurable-attributes); default is `False` If `True`, this toolchain behaves as if its `exec_compatible_with` and `target_compatible_with` constraints are set to those of the current target platform. `exec_compatible_with` and `target_compatible_with` must not be set in that case. |
 
 ## toolchain\_type
 
@@ -353,4 +353,4 @@ bar_binary = rule(
 | Attributes | |
 | --- | --- |
 | `name` | [Name](/versions/8.2.1/concepts/labels#target-names); required  A unique name for this target. |
-| `no_match_error` | String; [nonconfigurable](common-definitions#configurable-attributes); default is `""` A custom error message to display when no matching toolchain is found for this type. |
\ No newline at end of file
+| `no_match_error` | String; [nonconfigurable](/versions/8.2.1/reference/be/common-definitions#configurable-attributes); default is `""` A custom error message to display when no matching toolchain is found for this type. |
\ No newline at end of file
diff --git a/versions/8.2.1/reference/be/protocol-buffer.mdx b/versions/8.2.1/reference/be/protocol-buffer.mdx
index e6e63fec..0fc10d62 100644
--- a/versions/8.2.1/reference/be/protocol-buffer.mdx
+++ b/versions/8.2.1/reference/be/protocol-buffer.mdx
@@ -22,7 +22,7 @@ cc_proto_library(name, deps, compatible_with, deprecation, distribs, exec_compat
 
 `cc_proto_library` generates C++ code from `.proto` files.
 
-`deps` must point to [`proto_library`](protocol-buffer#proto_library) rules.
+`deps` must point to [`proto_library`](/versions/8.2.1/reference/be/protocol-buffer#proto_library) rules.
 
 Example:
 
@@ -47,7 +47,7 @@ proto_library(
 | Attributes | |
 | --- | --- |
 | `name` | [Name](/versions/8.2.1/concepts/labels#target-names); required  A unique name for this target. |
-| `deps` | List of [labels](/versions/8.2.1/concepts/labels); default is `[]` The list of [`proto_library`](protocol-buffer#proto_library) rules to generate C++ code for. |
+| `deps` | List of [labels](/versions/8.2.1/concepts/labels); default is `[]` The list of [`proto_library`](/versions/8.2.1/reference/be/protocol-buffer#proto_library) rules to generate C++ code for. |
 
 ## java\_lite\_proto\_library
 
@@ -59,7 +59,7 @@ java_lite_proto_library(name, deps, compatible_with, deprecation, distribs, exec
 
 `java_lite_proto_library` generates Java code from `.proto` files.
 
-`deps` must point to [`proto_library`](protocol-buffer#proto_library) rules.
+`deps` must point to [`proto_library`](/versions/8.2.1/reference/be/protocol-buffer#proto_library) rules.
 
 Example:
 
@@ -84,7 +84,7 @@ proto_library(
 | Attributes | |
 | --- | --- |
 | `name` | [Name](/versions/8.2.1/concepts/labels#target-names); required  A unique name for this target. |
-| `deps` | List of [labels](/versions/8.2.1/concepts/labels); default is `[]` The list of [`proto_library`](protocol-buffer#proto_library) rules to generate Java code for. |
+| `deps` | List of [labels](/versions/8.2.1/concepts/labels); default is `[]` The list of [`proto_library`](/versions/8.2.1/reference/be/protocol-buffer#proto_library) rules to generate Java code for. |
 
 ## java\_proto\_library
 
@@ -96,7 +96,7 @@ java_proto_library(name, deps, compatible_with, deprecation, distribs, exec_comp
 
 `java_proto_library` generates Java code from `.proto` files.
 
-`deps` must point to [`proto_library`](protocol-buffer#proto_library) rules.
+`deps` must point to [`proto_library`](/versions/8.2.1/reference/be/protocol-buffer#proto_library) rules.
 
 Example:
 
@@ -121,7 +121,7 @@ proto_library(
 | Attributes | |
 | --- | --- |
 | `name` | [Name](/versions/8.2.1/concepts/labels#target-names); required  A unique name for this target. |
-| `deps` | List of [labels](/versions/8.2.1/concepts/labels); default is `[]` The list of [`proto_library`](protocol-buffer#proto_library) rules to generate Java code for. |
+| `deps` | List of [labels](/versions/8.2.1/concepts/labels); default is `[]` The list of [`proto_library`](/versions/8.2.1/reference/be/protocol-buffer#proto_library) rules to generate Java code for. |
 
 ## proto\_library
 
diff --git a/versions/8.2.1/reference/be/python.mdx b/versions/8.2.1/reference/be/python.mdx
index 7f5a76aa..4204d142 100644
--- a/versions/8.2.1/reference/be/python.mdx
+++ b/versions/8.2.1/reference/be/python.mdx
@@ -22,13 +22,13 @@ py_binary(name, deps, srcs, data, args, compatible_with, deprecation, distribs,
 | Attributes | |
 | --- | --- |
 | `name` | [Name](/versions/8.2.1/concepts/labels#target-names); required  A unique name for this target. |
-| `deps` | List of [labels](/versions/8.2.1/concepts/labels); default is `[]` List of additional libraries to be linked in to the target. See comments about the [`deps` attribute typically defined by rules](https://bazel.build/reference/be/common-definitions#typical-attributes). These are typically `py\_library` rules. Targets that only provide data files used at runtime belong in the `data` attribute. |
+| `deps` | List of [labels](/versions/8.2.1/concepts/labels); default is `[]` List of additional libraries to be linked in to the target. See comments about the [`deps` attribute typically defined by rules](https://bazel.build/versions/8.2.1/reference/be/common-definitions#typical-attributes). These are typically `py\_library` rules. Targets that only provide data files used at runtime belong in the `data` attribute. |
 | `srcs` | List of [labels](/versions/8.2.1/concepts/labels); required The list of Python source files that are processed to create the target. This includes all your checked-in code and may include generated source files. The `.py` files belong in `srcs` and library targets belong in `deps`. Other binary files that may be needed at run time belong in `data`. |
-| `data` | List of [labels](/versions/8.2.1/concepts/labels); default is `[]` The list of files need by this library at runtime. See comments about the [`data` attribute typically defined by rules](https://bazel.build/reference/be/common-definitions#typical-attributes). There is no `py\_embed\_data` like there is `cc\_embed\_data` and `go\_embed\_data`. This is because Python has a concept of runtime resources. |
+| `data` | List of [labels](/versions/8.2.1/concepts/labels); default is `[]` The list of files need by this library at runtime. See comments about the [`data` attribute typically defined by rules](https://bazel.build/versions/8.2.1/reference/be/common-definitions#typical-attributes). There is no `py\_embed\_data` like there is `cc\_embed\_data` and `go\_embed\_data`. This is because Python has a concept of runtime resources. |
 | `imports` | List of strings; default is `[]` List of import directories to be added to the PYTHONPATH. Subject to "Make variable" substitution. These import directories will be added for this rule and all rules that depend on it (note: not the rules this rule depends on. Each directory will be added to `PYTHONPATH` by `py\_binary` rules that depend on this rule. The strings are repo-runfiles-root relative, Absolute paths (paths that start with `/`) and paths that references a path above the execution root are not allowed and will result in an error. |
 | `legacy_create_init` | Integer; default is `-1` Whether to implicitly create empty `\_\_init\_\_.py` files in the runfiles tree. These are created in every directory containing Python source code or shared libraries, and every parent directory of those directories, excluding the repo root directory. The default, `-1` (auto), means true unless `--incompatible\_default\_to\_explicit\_init\_py` is used. If false, the user is responsible for creating (possibly empty) `\_\_init\_\_.py` files and adding them to the `srcs` of Python targets as required. |
 | `main` | [Label](/versions/8.2.1/concepts/labels); default is `None` Optional; the name of the source file that is the main entry point of the application. This file must also be listed in `srcs`. If left unspecified, `name`, with `.py` appended, is used instead. If `name` does not match any filename in `srcs`, `main` must be specified. |
-| `precompile` | String; default is `"inherit"` Whether py source files \*\*for this target\*\* should be precompiled. Values: \* `inherit`: Allow the downstream binary decide if precompiled files are used. \* `enabled`: Compile Python source files at build time. \* `disabled`: Don't compile Python source files at build time. :::{seealso} \* The {flag}`--precompile` flag, which can override this attribute in some cases and will affect all targets when building. \* The {obj}`pyc\_collection` attribute for transitively enabling precompiling on a per-target basis. \* The [Precompiling](precompiling) docs for a guide about using precompiling. ::: |
+| `precompile` | String; default is `"inherit"` Whether py source files \*\*for this target\*\* should be precompiled. Values: \* `inherit`: Allow the downstream binary decide if precompiled files are used. \* `enabled`: Compile Python source files at build time. \* `disabled`: Don't compile Python source files at build time. :::{seealso} \* The {flag}`--precompile` flag, which can override this attribute in some cases and will affect all targets when building. \* The {obj}`pyc\_collection` attribute for transitively enabling precompiling on a per-target basis. \* The [Precompiling](/versions/8.2.1/reference/be/precompiling) docs for a guide about using precompiling. ::: |
 | `precompile_invalidation_mode` | String; default is `"auto"` How precompiled files should be verified to be up-to-date with their associated source files. Possible values are: \* `auto`: The effective value will be automatically determined by other build settings. \* `checked\_hash`: Use the pyc file if the hash of the source file matches the hash recorded in the pyc file. This is most useful when working with code that you may modify. \* `unchecked\_hash`: Always use the pyc file; don't check the pyc's hash against the source file. This is most useful when the code won't be modified. For more information on pyc invalidation modes, see https://docs.python.org/3/library/py\_compile.html#py\_compile.PycInvalidationMode |
 | `precompile_optimize_level` | Integer; default is `0` The optimization level for precompiled files. For more information about optimization levels, see the `compile()` function's `optimize` arg docs at https://docs.python.org/3/library/functions.html#compile NOTE: The value `-1` means "current interpreter", which will be the interpreter used \_at build time when pycs are generated\_, not the interpreter used at runtime when the code actually runs. |
 | `precompile_source_retention` | String; default is `"inherit"` Determines, when a source file is compiled, if the source file is kept in the resulting output or not. Valid values are: \* `inherit`: Inherit the value from the {flag}`--precompile\_source\_retention` flag. \* `keep\_source`: Include the original Python source. \* `omit\_source`: Don't include the original py source. |
@@ -61,11 +61,11 @@ Source files are no longer added to the runfiles directly.
 | Attributes | |
 | --- | --- |
 | `name` | [Name](/versions/8.2.1/concepts/labels#target-names); required  A unique name for this target. |
-| `deps` | List of [labels](/versions/8.2.1/concepts/labels); default is `[]` List of additional libraries to be linked in to the target. See comments about the [`deps` attribute typically defined by rules](https://bazel.build/reference/be/common-definitions#typical-attributes). These are typically `py\_library` rules. Targets that only provide data files used at runtime belong in the `data` attribute. |
+| `deps` | List of [labels](/versions/8.2.1/concepts/labels); default is `[]` List of additional libraries to be linked in to the target. See comments about the [`deps` attribute typically defined by rules](https://bazel.build/versions/8.2.1/reference/be/common-definitions#typical-attributes). These are typically `py\_library` rules. Targets that only provide data files used at runtime belong in the `data` attribute. |
 | `srcs` | List of [labels](/versions/8.2.1/concepts/labels); default is `[]` The list of Python source files that are processed to create the target. This includes all your checked-in code and may include generated source files. The `.py` files belong in `srcs` and library targets belong in `deps`. Other binary files that may be needed at run time belong in `data`. |
-| `data` | List of [labels](/versions/8.2.1/concepts/labels); default is `[]` The list of files need by this library at runtime. See comments about the [`data` attribute typically defined by rules](https://bazel.build/reference/be/common-definitions#typical-attributes). There is no `py\_embed\_data` like there is `cc\_embed\_data` and `go\_embed\_data`. This is because Python has a concept of runtime resources. |
+| `data` | List of [labels](/versions/8.2.1/concepts/labels); default is `[]` The list of files need by this library at runtime. See comments about the [`data` attribute typically defined by rules](https://bazel.build/versions/8.2.1/reference/be/common-definitions#typical-attributes). There is no `py\_embed\_data` like there is `cc\_embed\_data` and `go\_embed\_data`. This is because Python has a concept of runtime resources. |
 | `imports` | List of strings; default is `[]` List of import directories to be added to the PYTHONPATH. Subject to "Make variable" substitution. These import directories will be added for this rule and all rules that depend on it (note: not the rules this rule depends on. Each directory will be added to `PYTHONPATH` by `py\_binary` rules that depend on this rule. The strings are repo-runfiles-root relative, Absolute paths (paths that start with `/`) and paths that references a path above the execution root are not allowed and will result in an error. |
-| `precompile` | String; default is `"inherit"` Whether py source files \*\*for this target\*\* should be precompiled. Values: \* `inherit`: Allow the downstream binary decide if precompiled files are used. \* `enabled`: Compile Python source files at build time. \* `disabled`: Don't compile Python source files at build time. :::{seealso} \* The {flag}`--precompile` flag, which can override this attribute in some cases and will affect all targets when building. \* The {obj}`pyc\_collection` attribute for transitively enabling precompiling on a per-target basis. \* The [Precompiling](precompiling) docs for a guide about using precompiling. ::: |
+| `precompile` | String; default is `"inherit"` Whether py source files \*\*for this target\*\* should be precompiled. Values: \* `inherit`: Allow the downstream binary decide if precompiled files are used. \* `enabled`: Compile Python source files at build time. \* `disabled`: Don't compile Python source files at build time. :::{seealso} \* The {flag}`--precompile` flag, which can override this attribute in some cases and will affect all targets when building. \* The {obj}`pyc\_collection` attribute for transitively enabling precompiling on a per-target basis. \* The [Precompiling](/versions/8.2.1/reference/be/precompiling) docs for a guide about using precompiling. ::: |
 | `precompile_invalidation_mode` | String; default is `"auto"` How precompiled files should be verified to be up-to-date with their associated source files. Possible values are: \* `auto`: The effective value will be automatically determined by other build settings. \* `checked\_hash`: Use the pyc file if the hash of the source file matches the hash recorded in the pyc file. This is most useful when working with code that you may modify. \* `unchecked\_hash`: Always use the pyc file; don't check the pyc's hash against the source file. This is most useful when the code won't be modified. For more information on pyc invalidation modes, see https://docs.python.org/3/library/py\_compile.html#py\_compile.PycInvalidationMode |
 | `precompile_optimize_level` | Integer; default is `0` The optimization level for precompiled files. For more information about optimization levels, see the `compile()` function's `optimize` arg docs at https://docs.python.org/3/library/functions.html#compile NOTE: The value `-1` means "current interpreter", which will be the interpreter used \_at build time when pycs are generated\_, not the interpreter used at runtime when the code actually runs. |
 | `precompile_source_retention` | String; default is `"inherit"` Determines, when a source file is compiled, if the source file is kept in the resulting output or not. Valid values are: \* `inherit`: Inherit the value from the {flag}`--precompile\_source\_retention` flag. \* `keep\_source`: Include the original Python source. \* `omit\_source`: Don't include the original py source. |
@@ -84,13 +84,13 @@ py_test(name, deps, srcs, data, args, compatible_with, deprecation, distribs, en
 | Attributes | |
 | --- | --- |
 | `name` | [Name](/versions/8.2.1/concepts/labels#target-names); required  A unique name for this target. |
-| `deps` | List of [labels](/versions/8.2.1/concepts/labels); default is `[]` List of additional libraries to be linked in to the target. See comments about the [`deps` attribute typically defined by rules](https://bazel.build/reference/be/common-definitions#typical-attributes). These are typically `py\_library` rules. Targets that only provide data files used at runtime belong in the `data` attribute. |
+| `deps` | List of [labels](/versions/8.2.1/concepts/labels); default is `[]` List of additional libraries to be linked in to the target. See comments about the [`deps` attribute typically defined by rules](https://bazel.build/versions/8.2.1/reference/be/common-definitions#typical-attributes). These are typically `py\_library` rules. Targets that only provide data files used at runtime belong in the `data` attribute. |
 | `srcs` | List of [labels](/versions/8.2.1/concepts/labels); required The list of Python source files that are processed to create the target. This includes all your checked-in code and may include generated source files. The `.py` files belong in `srcs` and library targets belong in `deps`. Other binary files that may be needed at run time belong in `data`. |
-| `data` | List of [labels](/versions/8.2.1/concepts/labels); default is `[]` The list of files need by this library at runtime. See comments about the [`data` attribute typically defined by rules](https://bazel.build/reference/be/common-definitions#typical-attributes). There is no `py\_embed\_data` like there is `cc\_embed\_data` and `go\_embed\_data`. This is because Python has a concept of runtime resources. |
+| `data` | List of [labels](/versions/8.2.1/concepts/labels); default is `[]` The list of files need by this library at runtime. See comments about the [`data` attribute typically defined by rules](https://bazel.build/versions/8.2.1/reference/be/common-definitions#typical-attributes). There is no `py\_embed\_data` like there is `cc\_embed\_data` and `go\_embed\_data`. This is because Python has a concept of runtime resources. |
 | `imports` | List of strings; default is `[]` List of import directories to be added to the PYTHONPATH. Subject to "Make variable" substitution. These import directories will be added for this rule and all rules that depend on it (note: not the rules this rule depends on. Each directory will be added to `PYTHONPATH` by `py\_binary` rules that depend on this rule. The strings are repo-runfiles-root relative, Absolute paths (paths that start with `/`) and paths that references a path above the execution root are not allowed and will result in an error. |
 | `legacy_create_init` | Integer; default is `-1` Whether to implicitly create empty `\_\_init\_\_.py` files in the runfiles tree. These are created in every directory containing Python source code or shared libraries, and every parent directory of those directories, excluding the repo root directory. The default, `-1` (auto), means true unless `--incompatible\_default\_to\_explicit\_init\_py` is used. If false, the user is responsible for creating (possibly empty) `\_\_init\_\_.py` files and adding them to the `srcs` of Python targets as required. |
 | `main` | [Label](/versions/8.2.1/concepts/labels); default is `None` Optional; the name of the source file that is the main entry point of the application. This file must also be listed in `srcs`. If left unspecified, `name`, with `.py` appended, is used instead. If `name` does not match any filename in `srcs`, `main` must be specified. |
-| `precompile` | String; default is `"inherit"` Whether py source files \*\*for this target\*\* should be precompiled. Values: \* `inherit`: Allow the downstream binary decide if precompiled files are used. \* `enabled`: Compile Python source files at build time. \* `disabled`: Don't compile Python source files at build time. :::{seealso} \* The {flag}`--precompile` flag, which can override this attribute in some cases and will affect all targets when building. \* The {obj}`pyc\_collection` attribute for transitively enabling precompiling on a per-target basis. \* The [Precompiling](precompiling) docs for a guide about using precompiling. ::: |
+| `precompile` | String; default is `"inherit"` Whether py source files \*\*for this target\*\* should be precompiled. Values: \* `inherit`: Allow the downstream binary decide if precompiled files are used. \* `enabled`: Compile Python source files at build time. \* `disabled`: Don't compile Python source files at build time. :::{seealso} \* The {flag}`--precompile` flag, which can override this attribute in some cases and will affect all targets when building. \* The {obj}`pyc\_collection` attribute for transitively enabling precompiling on a per-target basis. \* The [Precompiling](/versions/8.2.1/reference/be/precompiling) docs for a guide about using precompiling. ::: |
 | `precompile_invalidation_mode` | String; default is `"auto"` How precompiled files should be verified to be up-to-date with their associated source files. Possible values are: \* `auto`: The effective value will be automatically determined by other build settings. \* `checked\_hash`: Use the pyc file if the hash of the source file matches the hash recorded in the pyc file. This is most useful when working with code that you may modify. \* `unchecked\_hash`: Always use the pyc file; don't check the pyc's hash against the source file. This is most useful when the code won't be modified. For more information on pyc invalidation modes, see https://docs.python.org/3/library/py\_compile.html#py\_compile.PycInvalidationMode |
 | `precompile_optimize_level` | Integer; default is `0` The optimization level for precompiled files. For more information about optimization levels, see the `compile()` function's `optimize` arg docs at https://docs.python.org/3/library/functions.html#compile NOTE: The value `-1` means "current interpreter", which will be the interpreter used \_at build time when pycs are generated\_, not the interpreter used at runtime when the code actually runs. |
 | `precompile_source_retention` | String; default is `"inherit"` Determines, when a source file is compiled, if the source file is kept in the resulting output or not. Valid values are: \* `inherit`: Inherit the value from the {flag}`--precompile\_source\_retention` flag. \* `keep\_source`: Include the original Python source. \* `omit\_source`: Don't include the original py source. |
diff --git a/versions/8.2.1/reference/be/workspace.mdx b/versions/8.2.1/reference/be/workspace.mdx
index 30de6592..135eee85 100644
--- a/versions/8.2.1/reference/be/workspace.mdx
+++ b/versions/8.2.1/reference/be/workspace.mdx
@@ -25,8 +25,7 @@ bind(name, actual, compatible_with, deprecation, distribs, features, licenses, r
 
 *Warning: use of `bind()` is not recommended. See "[Consider removing bind](https://github.com/bazelbuild/bazel/issues/1952)" for a long
 discussion of its issues and alternatives. In particular, consider the use of
-[`repo_mapping`
-repository attributes](https://bazel.build/versions/8.2.1/rules/repository_rules#attributes).*
+[`repo_mapping` repository attributes](https://bazel.build/versions/8.2.1/rules/repository_rules#attributes).*
 
 *Warning: `select()` cannot be used in `bind()`. See the [Configurable Attributes FAQ](/versions/8.2.1/docs/configurable-attributes#bind-select) for
 details.*
@@ -114,8 +113,7 @@ local_repository(name, path, repo_mapping)
 ```
 
 Allows targets from a local directory to be bound. This means that the current repository can
-use targets defined in this other directory. See the [bind
-section](/versions/8.2.1/reference/be/workspace#bind_examples) for more details.
+use targets defined in this other directory. See the [bind section](/versions/8.2.1/reference/be/workspace#bind_examples) for more details.
 
 #### Examples
 
diff --git a/versions/8.2.1/reference/command-line-reference.mdx b/versions/8.2.1/reference/command-line-reference.mdx
index 55c8103d..da0f6fad 100644
--- a/versions/8.2.1/reference/command-line-reference.mdx
+++ b/versions/8.2.1/reference/command-line-reference.mdx
@@ -498,7 +498,7 @@ This option affects semantics of the Starlark language or the build API accessib
     [`loading_and_analysis`](#effect_tag_LOADING_AND_ANALYSIS), [`experimental`](#metadata_tag_EXPERIMENTAL)
 
 `--[no]experimental_isolated_extension_usages` default: "false"
-:   If true, enables the isolate parameter in the use\_extension function.
+:   If true, enables the isolate parameter in the use\_extension function.
 
     Tags:
     [`loading_and_analysis`](#effect_tag_LOADING_AND_ANALYSIS)
diff --git a/versions/8.2.1/reference/glossary.mdx b/versions/8.2.1/reference/glossary.mdx
index 19606dd0..a4f490ec 100644
--- a/versions/8.2.1/reference/glossary.mdx
+++ b/versions/8.2.1/reference/glossary.mdx
@@ -21,8 +21,7 @@ An in-memory graph of [actions](#action) and the [artifacts](#artifact) that
 these actions read and generate. The graph might include artifacts that exist as
 source files (for example, in the file system) as well as generated
 intermediate/final artifacts that are not mentioned in `BUILD` files. Produced
-during the [analysis phase](#analysis-phase) and used during the [execution
-phase](#execution-phase).
+during the [analysis phase](#analysis-phase) and used during the [execution phase](#execution-phase).
 
 ### Action graph query (aquery) {#action-graph-query}
 A [query](#query-concept) tool that can query over build [actions](#action).
@@ -37,8 +36,7 @@ invalidate individual actions deterministically.
 
 ### Analysis phase {#analysis-phase}
 The second phase of a build. Processes the [target graph](#target-graph)
-specified in [`BUILD` files](#build-file) to produce an in-memory [action
-graph](#action-graph) that determines the order of actions to run during the
+specified in [`BUILD` files](#build-file) to produce an in-memory [action graph](#action-graph) that determines the order of actions to run during the
 [execution phase](#execution-phase). This is the phase in which rule
 implementations are evaluated.
 
@@ -81,8 +79,7 @@ target's source files, dependencies, and custom compiler options. The particular
 attributes available for a given target depend on its rule type.
 
 ### .bazelrc {#bazelrc}
-Bazel’s configuration file used to change the default values for [startup
-flags](#startup-flags) and [command flags](#command-flags), and to define common
+Bazel’s configuration file used to change the default values for [startup flags](#startup-flags) and [command flags](#command-flags), and to define common
 groups of options that can then be set together on the Bazel command line using
 a `--config` flag. Bazel can combine settings from multiple bazelrc files
 (systemwide, per-workspace, per-user, or from a custom location), and a
@@ -108,8 +105,7 @@ directory.
 
 ### .bzl File {#bzl-file}
 A file that defines rules, [macros](#macro), and constants written in
-[Starlark](#starlark). These can then be imported into [`BUILD`
-files](#build-file) using the `load()` function.
+[Starlark](#starlark). These can then be imported into [`BUILD` files](#build-file) using the `load()` function.
 
 {/* TODO: ### Build event protocol */}
 
@@ -117,8 +113,7 @@ files](#build-file) using the `load()` function.
 
 ### Build graph {#build-graph}
 The dependency graph that Bazel constructs and traverses to perform a build.
-Includes nodes like [targets](#target), [configured
-targets](#configured-target), [actions](#action), and [artifacts](#artifact). A
+Includes nodes like [targets](#target), [configured targets](#configured-target), [actions](#action), and [artifacts](#artifact). A
 build is considered complete when all [artifacts](#artifact) on which a set of
 requested targets depend are verified as up-to-date.
 
@@ -158,8 +153,7 @@ graphs and restart the [analysis phase](#analysis-phase).
 ### Configuration {#configuration}
 Information outside of [rule](#rule) definitions that impacts how rules generate
 [actions](#action). Every build has at least one configuration specifying the
-target platform, action environment variables, and command-line [build
-flags](#command-flags). [Transitions](#transition) may create additional
+target platform, action environment variables, and command-line [build flags](#command-flags). [Transitions](#transition) may create additional
 configurations, such as for host tools or cross-compilation.
 
 **See also:** [Configurations](/versions/8.2.1/extending/rules#configurations)
@@ -174,8 +168,7 @@ configuration of `//:c` because changing `--javacopt` unnecessarily breaks C++
 build cacheability.
 
 ### Configured query (cquery) {#configured-query}
-A [query](#query-concept) tool that queries over [configured
-targets](#configured-target) (after the [analysis phase](#analysis-phase)
+A [query](#query-concept) tool that queries over [configured targets](#configured-target) (after the [analysis phase](#analysis-phase)
 completes). This means `select()` and [build flags](#command-flags) (such as
 `--platforms`) are accurately reflected in the results.
 
@@ -191,8 +184,7 @@ build, it has two configured targets: `` and ``.
 ### Correctness {#correctness}
 A build is correct when its output faithfully reflects the state of its
 transitive inputs. To achieve correct builds, Bazel strives to be
-[hermetic](#hermeticity), reproducible, and making [build
-analysis](#analysis-phase) and [action execution](#execution-phase)
+[hermetic](#hermeticity), reproducible, and making [build analysis](#analysis-phase) and [action execution](#execution-phase)
 deterministic.
 
 ### Dependency {#dependency}
@@ -234,8 +226,7 @@ compilation). A dynamic execution strategy can provide the best possible
 incremental and clean build times.
 
 ### Execution phase {#execution-phase}
-The third phase of a build. Executes the [actions](#action) in the [action
-graph](#action-graph) created during the [analysis phase](#analysis-phase).
+The third phase of a build. Executes the [actions](#action) in the [action graph](#action-graph) created during the [analysis phase](#analysis-phase).
 These actions invoke executables (compilers, scripts) to read and write
 [artifacts](#artifact). *Spawn strategies* control how these actions are
 executed: locally, remotely, dynamically, sandboxed, docker, and so on.
@@ -285,8 +276,7 @@ syntax may be omitted.
 The first phase of a build where Bazel executes [`BUILD` files](#build-file) to
 create [packages](#package). [Macros](#macro) and certain functions like
 `glob()` are evaluated in this phase. Interleaved with the second phase of the
-build, the [analysis phase](#analysis-phase), to build up a [target
-graph](#target-graph).
+build, the [analysis phase](#analysis-phase), to build up a [target graph](#target-graph).
 
 ### Legacy macro {#legacy-macro}
 A flavor of [macro](#macro) which is declared as an ordinary
@@ -336,8 +326,7 @@ Module metadata is hosted in Bazel registries.
 
 ### Module Extension {#module-extension}
 A piece of logic that can be run to generate [repos](#repository) by reading
-inputs from across the [module](#module) dependency graph and invoking [repo
-rules](#repository-rule). Module extensions have capabilities similar to repo
+inputs from across the [module](#module) dependency graph and invoking [repo rules](#repository-rule). Module extensions have capabilities similar to repo
 rules, allowing them to access the internet, perform file I/O, and so on.
 
 **See also:** [Module extensions](/versions/8.2.1/external/extension)
@@ -350,8 +339,7 @@ example, `native.cc_library` or `native.java_library`). User-defined rules
 
 ### Output base {#output-base}
 A [workspace](#workspace)-specific directory to store Bazel output files. Used
-to separate outputs from the *workspace*'s source tree (the [main
-repo](#repository)). Located in the [output user root](#output-user-root).
+to separate outputs from the *workspace*'s source tree (the [main repo](#repository)). Located in the [output user root](#output-user-root).
 
 ### Output groups {#output-groups}
 A group of files that is expected to be built when Bazel finishes building a
@@ -406,8 +394,7 @@ query variants: [query](#query-command), [cquery](#configured-query), and
 [aquery](#action-graph-query).
 
 ### query (command) {#query-command}
-A [query](#query-concept) tool that operates over the build's post-[loading
-phase](#loading-phase) [target graph](#target-graph). This is relatively fast,
+A [query](#query-concept) tool that operates over the build's post-[loading phase](#loading-phase) [target graph](#target-graph). This is relatively fast,
 but can't analyze the effects of `select()`, [build flags](#command-flags),
 [artifacts](#artifact), or build [actions](#action).
 
@@ -425,8 +412,7 @@ repo; multiple such files can coexist in a directory.
 The *main repo* is the repo in which the current Bazel command is being run.
 
 *External repos* are defined by specifying [modules](#module) in `MODULE.bazel`
-files, or invoking [repo rules](#repository-rule) in [module
-extensions](#module-extension). They can be fetched on demand to a predetermined
+files, or invoking [repo rules](#repository-rule) in [module extensions](#module-extension). They can be fetched on demand to a predetermined
 "magical" location on disk.
 
 Each repo has a unique, constant *canonical* name, and potentially different
@@ -437,8 +423,7 @@ Each repo has a unique, constant *canonical* name, and potentially different
 ### Repository cache {#repo-cache}
 A shared content-addressable cache of files downloaded by Bazel for builds,
 shareable across [workspaces](#workspace). Enables offline builds after the
-initial download. Commonly used to cache files downloaded through [repository
-rules](#repository-rule) like `http_archive` and repository rule APIs like
+initial download. Commonly used to cache files downloaded through [repository rules](#repository-rule) like `http_archive` and repository rule APIs like
 `repository_ctx.download`. Files are cached only if their SHA-256 checksums are
 specified for the download.
 
@@ -472,8 +457,7 @@ Rules are instantiated to produce rule targets in the
 [loading phase](#loading-phase). In the [analysis phase](#analysis-phase) rule
 targets communicate information to their downstream dependencies in the form of
 [providers](#provider), and register [actions](#action) describing how to
-generate their output artifacts. These actions are run in the [execution
-phase](#execution-phase).
+generate their output artifacts. These actions are run in the [execution phase](#execution-phase).
 
 Note: Historically the term "rule" has been used to refer to a rule target.
 This usage was inherited from tools like Make, but causes confusion and should
@@ -517,8 +501,7 @@ support the stamp attribute.
 ### Starlark {#starlark}
 The extension language for writing [rules](/versions/8.2.1/extending/rules) and [macros](#macro). A
 restricted subset of Python (syntactically and grammatically) aimed for the
-purpose of configuration, and for better performance. Uses the [`.bzl`
-file](#bzl-file) extension. [`BUILD` files](#build-file) use an even more
+purpose of configuration, and for better performance. Uses the [`.bzl` file](#bzl-file) extension. [`BUILD` files](#build-file) use an even more
 restricted version of Starlark (such as no `def` function definitions), formerly
 known as Skylark.
 
@@ -549,8 +532,7 @@ An object that is defined in a [`BUILD` file](#build-file) and identified by a
 [label](#label). Targets represent the buildable units of a workspace from
 the perspective of the end user.
 
-A target that is declared by instantiating a [rule](#rule) is called a [rule
-target](#rule-target). Depending on the rule, these may be runnable (like
+A target that is declared by instantiating a [rule](#rule) is called a [rule target](#rule-target). Depending on the rule, these may be runnable (like
 `cc_binary`) or testable (like `cc_test`). Rule targets typically depend on
 other targets via their [attributes](#attribute) (such as `deps`); these
 dependencies form the basis of the [target graph](#target-graph).
@@ -561,14 +543,11 @@ within a `BUILD` file. As a special case, the `BUILD` file of any package is
 always considered a source file target in that package.
 
 Targets are discovered during the [loading phase](#loading-phase). During the
-[analysis phase](#analysis-phase), targets are associated with [build
-configurations](#configuration) to form [configured
-targets](#configured-target).
+[analysis phase](#analysis-phase), targets are associated with [build configurations](#configuration) to form [configured targets](#configured-target).
 
 ### Target graph {#target-graph}
 An in-memory graph of [targets](#target) and their dependencies. Produced during
-the [loading phase](#loading-phase) and used as an input to the [analysis
-phase](#analysis-phase).
+the [loading phase](#loading-phase) and used as an input to the [analysis phase](#analysis-phase).
 
 ### Target pattern {#target-pattern}
 A way to specify a group of [targets](#target) on the command line. Commonly
@@ -581,8 +560,7 @@ packages recursively from the root of the [workspace](#workspace).
 Rule [targets](#target) instantiated from test rules, and therefore contains a
 test executable. A return code of zero from the completion of the executable
 indicates test success. The exact contract between Bazel and tests (such as test
-environment variables, test result collection methods) is specified in the [Test
-Encyclopedia](/versions/8.2.1/reference/test-encyclopedia).
+environment variables, test result collection methods) is specified in the [Test Encyclopedia](/versions/8.2.1/reference/test-encyclopedia).
 
 ### Toolchain {#toolchain}
 A set of tools to build outputs for a language. Typically, a toolchain includes
@@ -596,8 +574,7 @@ A build [target](#target) is top-level if it’s requested on the Bazel command
 line. For example, if `//:foo` depends on `//:bar`, and `bazel build //:foo` is
 called, then for this build, `//:foo` is top-level, and `//:bar` isn’t
 top-level, although both targets will need to be built. An important difference
-between top-level and non-top-level targets is that [command
-flags](#command-flags) set on the Bazel command line (or via
+between top-level and non-top-level targets is that [command flags](#command-flags) set on the Bazel command line (or via
 [.bazelrc](#bazelrc)) will set the [configuration](#configuration) for top-level
 targets, but might be modified by a [transition](#transition) for non-top-level
 targets.
@@ -628,8 +605,7 @@ or `.bzl` file may load a given `.bzl` file. Without context, usually
 **See also:** [Visibility documentation](/versions/8.2.1/concepts/visibility)
 
 ### Workspace {#workspace}
-The environment shared by all Bazel commands run from the same [main
-repository](#repository).
+The environment shared by all Bazel commands run from the same [main repository](#repository).
 
 Note that historically the concepts of "repository" and "workspace" have been
 conflated; the term "workspace" has often been used to refer to the main
diff --git a/versions/8.2.1/release/backward-compatibility.mdx b/versions/8.2.1/release/backward-compatibility.mdx
index 6668690a..f3e8495a 100644
--- a/versions/8.2.1/release/backward-compatibility.mdx
+++ b/versions/8.2.1/release/backward-compatibility.mdx
@@ -6,11 +6,9 @@ This page provides information about how to handle backward compatibility,
 including migrating from one release to another and how to communicate
 incompatible changes.
 
-Bazel is evolving. Minor versions released as part of an [LTS major
-version](/versions/8.2.1/release#bazel-versioning) are fully backward-compatible. New major LTS
+Bazel is evolving. Minor versions released as part of an [LTS major version](/versions/8.2.1/release#bazel-versioning) are fully backward-compatible. New major LTS
 releases may contain incompatible changes that require some migration effort.
-For more information about Bazel's release model, please check out the [Release
-Model](/versions/8.2.1/release) page.
+For more information about Bazel's release model, please check out the [Release Model](/versions/8.2.1/release) page.
 
 ## Summary {#summary}
 
@@ -59,8 +57,7 @@ available.
 ## Communicating incompatible changes {#communicating-incompatible-changes}
 
 The primary source of information about incompatible changes are GitHub issues
-marked with an ["incompatible-change"
-label](https://github.com/bazelbuild/bazel/issues?q=label%3Aincompatible-change).
+marked with an ["incompatible-change" label](https://github.com/bazelbuild/bazel/issues?q=label%3Aincompatible-change).
 
 For every incompatible change, the issue specifies the following:
 
diff --git a/versions/8.2.1/release/index.mdx b/versions/8.2.1/release/index.mdx
index 152928b1..10264b87 100644
--- a/versions/8.2.1/release/index.mdx
+++ b/versions/8.2.1/release/index.mdx
@@ -2,8 +2,7 @@
 title: 'Release Model'
 ---
 
-As announced in [the original blog
-post](https://blog.bazel.build/2020/11/10/long-term-support-release.html), Bazel
+As announced in [the original blog post](https://blog.bazel.build/2020/11/10/long-term-support-release.html), Bazel
 4.0 and higher versions provides support for two release tracks: rolling
 releases and long term support (LTS) releases. This page covers the latest
 information about Bazel's release model.
@@ -19,8 +18,7 @@ information about Bazel's release model.
 | Bazel 5 | Maintenance | [5.4.1](https://github.com/bazelbuild/bazel/releases/tag/5.4.1) | Jan 2025 |
 | Bazel 4 | Deprecated | [4.2.4](https://github.com/bazelbuild/bazel/releases/tag/4.2.4) | Jan 2024 |
 
-All Bazel LTS releases can be found on the [release
-page](https://github.com/bazelbuild/bazel/releases) on GitHub.
+All Bazel LTS releases can be found on the [release page](https://github.com/bazelbuild/bazel/releases) on GitHub.
 
 Note: Bazel version older than Bazel 5 are no longer supported, Bazel users are
 recommended to upgrade to the latest LTS release or use rolling releases if you
@@ -28,8 +26,7 @@ want to keep up with the latest changes at HEAD.
 
 ## Release versioning {#bazel-versioning}
 
-Bazel uses a _major.minor.patch_ [Semantic
-Versioning](https://semver.org/) scheme.
+Bazel uses a _major.minor.patch_ [Semantic Versioning](https://semver.org/) scheme.
 
 *   A _major release_ contains features that are not backward compatible with
     the previous release. Each major Bazel version is an LTS release.
@@ -72,8 +69,7 @@ Bazel regularly publish releases for two release tracks.
     release.
 *   Rolling releases can ship incompatible changes. Incompatible flags are
     recommended for major breaking changes, rolling out incompatible changes
-    should follow our [backward compatibility
-    policy](/versions/8.2.1/release/backward-compatibility).
+    should follow our [backward compatibility policy](/versions/8.2.1/release/backward-compatibility).
 
 ### LTS releases {#lts-releases}
 
@@ -89,8 +85,7 @@ Bazel regularly publish releases for two release tracks.
 *   A Bazel LTS release enters the Deprecated stage after being in ​​the
     Maintenance stage for 2 years.
 
-For planned releases, please check our [release
-issues](https://github.com/bazelbuild/bazel/issues?q=is%3Aopen+is%3Aissue+label%3Arelease)
+For planned releases, please check our [release issues](https://github.com/bazelbuild/bazel/issues?q=is%3Aopen+is%3Aissue+label%3Arelease)
 on Github.
 
 ## Release procedure & policies {#release-procedure-policies}
@@ -153,8 +148,7 @@ For LTS releases, the procedure and policies below are followed:
 1.  Identify release blockers and fix issues found on the release branch.
     *   The release branch is tested with the same test suite in
         [postsubmit](https://buildkite.com/bazel/bazel-bazel) and
-        [downstream test pipeline]
-        (https://buildkite.com/bazel/bazel-at-head-plus-downstream)
+        [downstream test pipeline](https://buildkite.com/bazel/bazel-at-head-plus-downstream)
         on Bazel CI. The Bazel team monitors testing results of the release
         branch and fixes any regressions found.
 1.  Create a new release candidate from the release branch when all known
@@ -210,5 +204,4 @@ feature.
 ## Rule compatibility {#rule-compatibility}
 
 If you are a rule authors and want to maintain compatibility with different
-Bazel versions, please check out the [Rule
-Compatibility](/versions/8.2.1/release/rule-compatibility) page.
+Bazel versions, please check out the [Rule Compatibility](/versions/8.2.1/release/rule-compatibility) page.
diff --git a/versions/8.2.1/release/rule-compatibility.mdx b/versions/8.2.1/release/rule-compatibility.mdx
index b066e8f0..34d739dc 100644
--- a/versions/8.2.1/release/rule-compatibility.mdx
+++ b/versions/8.2.1/release/rule-compatibility.mdx
@@ -53,18 +53,15 @@ Bazel LTS release.
 As Bazel rules authors, you can ensure a manageable migration process for users
 by following these best practices:
 
-1.  The rule should follow [Semantic
-    Versioning](https://semver.org/): minor versions of the same
+1.  The rule should follow [Semantic Versioning](https://semver.org/): minor versions of the same
     major version are backward compatible.
 1.  The rule at HEAD should be compatible with the latest Bazel LTS release.
 1.  The rule at HEAD should be compatible with Bazel at HEAD. To achieve this,
     you can
     *   Set up your own CI testing with Bazel at HEAD
-    *   Add your project to [Bazel downstream
-        testing](https://github.com/bazelbuild/continuous-integration/blob/master/docs/downstream-testing.md);
+    *   Add your project to [Bazel downstream testing](https://github.com/bazelbuild/continuous-integration/blob/master/docs/downstream-testing.md);
         the Bazel team files issues to your project if breaking changes in Bazel
-        affect your project, and you must follow our [downstream project
-        policies](https://github.com/bazelbuild/continuous-integration/blob/master/docs/downstream-testing.md#downstream-project-policies)
+        affect your project, and you must follow our [downstream project policies](https://github.com/bazelbuild/continuous-integration/blob/master/docs/downstream-testing.md#downstream-project-policies)
         to address issues timely.
 1.  The latest major version of the rule must be compatible with the latest
     Bazel LTS release.
diff --git a/versions/8.2.1/remote/bep-glossary.mdx b/versions/8.2.1/remote/bep-glossary.mdx
index 58ea4ac6..dac5341a 100644
--- a/versions/8.2.1/remote/bep-glossary.mdx
+++ b/versions/8.2.1/remote/bep-glossary.mdx
@@ -36,7 +36,7 @@ BEP contains an event like the following:
 ## ActionExecuted {#actionexecuted}
 
 Provides details about the execution of a specific
-[Action](/versions/8.2.1/rules/lib/actions) in a build. By default, this event is
+[Action](/versions/8.2.1/rules/lib/builtins/actions) in a build. By default, this event is
 included in the BEP only for failed actions, to support identifying the root cause
 of build failures. Users may set the `--build_event_publish_all_actions` flag
 to include all `ActionExecuted` events.
@@ -410,5 +410,4 @@ workspace, such as the execution root.
 
 ## WorkspaceStatus {#workspacestatus}
 
-A single `WorkspaceStatus` event contains the result of the [workspace status
-command](/versions/8.2.1/docs/user-manual#workspace-status).
+A single `WorkspaceStatus` event contains the result of the [workspace status command](/versions/8.2.1/docs/user-manual#workspace-status).
diff --git a/versions/8.2.1/remote/bep.mdx b/versions/8.2.1/remote/bep.mdx
index a68eb3b8..98d2481d 100644
--- a/versions/8.2.1/remote/bep.mdx
+++ b/versions/8.2.1/remote/bep.mdx
@@ -2,14 +2,12 @@
 title: 'Build Event Protocol'
 ---
 
-The [Build Event
-Protocol](https://github.com/bazelbuild/bazel/blob/master/src/main/java/com/google/devtools/build/lib/buildeventstream/proto/build_event_stream.proto)
+The [Build Event Protocol](https://github.com/bazelbuild/bazel/blob/master/src/main/java/com/google/devtools/build/lib/buildeventstream/proto/build_event_stream.proto)
 (BEP) allows third-party programs to gain insight into a Bazel invocation. For
 example, you could use the BEP to gather information for an IDE
 plugin or a dashboard that displays build results.
 
-The protocol is a set of [protocol
-buffer](https://developers.google.com/protocol-buffers/) messages with some
+The protocol is a set of [protocol buffer](https://developers.google.com/protocol-buffers/) messages with some
 semantics defined on top of it. It includes information about build and test
 results, build progress, the build configuration and much more. The BEP is
 intended to be consumed programmatically and makes parsing Bazel’s
@@ -20,16 +18,13 @@ build event is a protocol buffer message consisting of a build event identifier,
 a set of child event identifiers, and a payload.
 
 *  __Build Event Identifier:__ Depending on the kind of build event, it might be
-an [opaque
-string](https://github.com/bazelbuild/bazel/blob/7.1.0/src/main/java/com/google/devtools/build/lib/buildeventstream/proto/build_event_stream.proto#L131-L140)
-or [structured
-information](https://github.com/bazelbuild/bazel/blob/7.1.0/src/main/java/com/google/devtools/build/lib/buildeventstream/proto/build_event_stream.proto#L194-L205)
+an [opaque string](https://github.com/bazelbuild/bazel/blob/7.1.0/src/main/java/com/google/devtools/build/lib/buildeventstream/proto/build_event_stream.proto#L131-L140)
+or [structured information](https://github.com/bazelbuild/bazel/blob/7.1.0/src/main/java/com/google/devtools/build/lib/buildeventstream/proto/build_event_stream.proto#L194-L205)
 revealing more about the build event. A build event identifier is unique within
 a build.
 
 *  __Children:__ A build event may announce other build events, by including
-their build event identifiers in its [children
-field](https://github.com/bazelbuild/bazel/blob/7.1.0/src/main/java/com/google/devtools/build/lib/buildeventstream/proto/build_event_stream.proto#L1276).
+their build event identifiers in its [children field](https://github.com/bazelbuild/bazel/blob/7.1.0/src/main/java/com/google/devtools/build/lib/buildeventstream/proto/build_event_stream.proto#L1276).
 For example, the `PatternExpanded` build event announces the targets it expands
 to as children. The protocol guarantees that all events, except for the first
 event, are announced by a previous event.
@@ -91,8 +86,7 @@ human-readable formats, such as text and JSON:
 
 ## Build Event Service {#build-event-service}
 
-The [Build Event
-Service](https://github.com/googleapis/googleapis/blob/master/google/devtools/build/v1/publish_build_event.proto)
+The [Build Event Service](https://github.com/googleapis/googleapis/blob/master/google/devtools/build/v1/publish_build_event.proto)
 Protocol is a generic [gRPC](https://www.grpc.io) service for publishing build events. The Build Event
 Service protocol is independent of the BEP and treats BEP events as opaque bytes.
 Bazel ships with a gRPC client implementation of the Build Event Service protocol that
@@ -136,8 +130,7 @@ For a description of each of these flags, see the
 The BEP typically contains many references to log files (test.log, test.xml,
 etc. ) stored on the machine where Bazel is running. A remote BES server
 typically can't access these files as they are on different machines. A way to
-work around this issue is to use Bazel with [remote
-caching](/versions/8.2.1/remote/caching).
+work around this issue is to use Bazel with [remote caching](/versions/8.2.1/remote/caching).
 Bazel will upload all output files to the remote cache (including files
 referenced in the BEP) and the BES server can then fetch the referenced files
 from the cache.
diff --git a/versions/8.2.1/remote/cache-local.mdx b/versions/8.2.1/remote/cache-local.mdx
index af49017c..87b8a0e8 100644
--- a/versions/8.2.1/remote/cache-local.mdx
+++ b/versions/8.2.1/remote/cache-local.mdx
@@ -18,8 +18,7 @@ execution. However, local execution presents some additional challenges.
 ## Checking your cache hit rate {#cache-hits}
 
 Successful remote cache hits will show up in the status line, similar to
-[Cache Hits rate with Remote
-Execution](/versions/8.2.1/remote/cache-remote#check-cache-hits).
+[Cache Hits rate with Remote Execution](/versions/8.2.1/remote/cache-remote#check-cache-hits).
 
 In the standard output of your Bazel run, you will see something like the
 following:
@@ -66,8 +65,7 @@ the steps in this section.
    message you see does not give you enough information, try adding
    `--verbose_failures`.
 
-2. Follow the steps from [Troubleshooting cache hits for remote
-   execution](/versions/8.2.1/remote/cache-remote#troubleshooting_cache_hits) to
+2. Follow the steps from [Troubleshooting cache hits for remote execution](/versions/8.2.1/remote/cache-remote#troubleshooting_cache_hits) to
    ensure that your cache-writing Bazel invocations are able to get cache hits
    on the same machine and across machines.
 
@@ -81,7 +79,6 @@ the steps in this section.
    b. Ensure your cache-reading Bazel invocations build the same targets as the
       cache-writing Bazel invocations.
 
-   c. Follow the same steps as to [ensure caching across
-      machines](/versions/8.2.1/remote/cache-remote#caching-across-machines),
+   c. Follow the same steps as to [ensure caching across machines](/versions/8.2.1/remote/cache-remote#caching-across-machines),
       to ensure caching from your cache-writing Bazel invocation to your
       cache-reading Bazel invocation.
diff --git a/versions/8.2.1/remote/caching.mdx b/versions/8.2.1/remote/caching.mdx
index 90802fb5..159da11e 100644
--- a/versions/8.2.1/remote/caching.mdx
+++ b/versions/8.2.1/remote/caching.mdx
@@ -126,7 +126,7 @@ not provide technical support for bazel-remote.
 
 This cache stores contents on disk and also provides garbage collection
 to enforce an upper storage limit and clean unused artifacts. The cache is
-available as a [docker image] and its code is available on
+available as a [docker image](https://hub.docker.com/r/buchgr/bazel-remote-cache/) and its code is available on
 [GitHub](https://github.com/buchgr/bazel-remote/).
 Both the REST and gRPC remote cache APIs are supported.
 
@@ -308,8 +308,7 @@ or for the age of individual cache entries. Bazel will automatically garbage
 collect the disk cache while idling between builds; the idle timer can be set
 with `--experimental_disk_cache_gc_idle_delay` (defaulting to 5 minutes).
 
-As an alternative to automatic garbage collection, we also provide a [tool](
-https://github.com/bazelbuild/bazel/tree/master/src/tools/diskcache) to run a
+As an alternative to automatic garbage collection, we also provide a [tool](https://github.com/bazelbuild/bazel/tree/master/src/tools/diskcache) to run a
 garbage collection on demand.
 
 ## Known issues {#known-issues}
diff --git a/versions/8.2.1/remote/dynamic.mdx b/versions/8.2.1/remote/dynamic.mdx
index 3a173a6b..dcf1f811 100644
--- a/versions/8.2.1/remote/dynamic.mdx
+++ b/versions/8.2.1/remote/dynamic.mdx
@@ -12,8 +12,7 @@ alike.
 This page describes how to enable, tune, and debug dynamic execution. If you
 have both local and remote execution set up and are trying to adjust Bazel
 settings for better performance, this page is for you. If you don't already have
-remote execution set up, go to the Bazel [Remote Execution
-Overview](/versions/8.2.1/remote/rbe) first.
+remote execution set up, go to the Bazel [Remote Execution Overview](/versions/8.2.1/remote/rbe) first.
 
 ## Enabling dynamic execution? {#enabling-dynamic-execution}
 
@@ -44,14 +43,12 @@ are likely. The default value is 1000ms, but should be tuned to being just a bit
 longer than cache hits usually take. The actual time depends both on the remote
 system and on how long a round-trip takes. Usually, the value will be the same
 for all users of a given remote system, unless some of them are far enough away
-to add roundtrip latency. You can use the [Bazel profiling
-features](/versions/8.2.1/rules/performance#performance-profiling) to look at how long typical
+to add roundtrip latency. You can use the [Bazel profiling features](/versions/8.2.1/rules/performance#performance-profiling) to look at how long typical
 cache hits take.
 
 Dynamic execution can be used with local sandboxed strategy as well as with
 [persistent workers](/versions/8.2.1/remote/persistent). Persistent workers will automatically
-run with sandboxing when used with dynamic execution, and cannot use [multiplex
-workers](/versions/8.2.1/remote/multiplex). On Darwin and Windows systems, the sandboxed
+run with sandboxing when used with dynamic execution, and cannot use [multiplex workers](/versions/8.2.1/remote/multiplex). On Darwin and Windows systems, the sandboxed
 strategy can be slow; you can pass `--reuse_sandbox_directories` to reduce
 overhead of creating sandboxes on these systems.
 
@@ -67,8 +64,7 @@ entire action fails. This is an intentional choice to prevent differences
 between local and remote execution from going unnoticed.
 
 For more background on how dynamic execution and its locking works, see Julio
-Merino's excellent [blog
-posts](https://jmmv.dev/series/bazel-dynamic-execution/)
+Merino's excellent [blog posts](https://jmmv.dev/series/bazel-dynamic-execution/)
 
 ## When should I use dynamic execution? {#when-to-use}
 
diff --git a/versions/8.2.1/remote/output-directories.mdx b/versions/8.2.1/remote/output-directories.mdx
index b9ccbdb3..fbe0aafd 100644
--- a/versions/8.2.1/remote/output-directories.mdx
+++ b/versions/8.2.1/remote/output-directories.mdx
@@ -25,7 +25,7 @@ The solution that's currently implemented:
 
 * Bazel must be invoked from a directory containing a repo boundary file, or a
   subdirectory thereof. In other words, Bazel must be invoked from inside a
-  [repository](../external/overview#repository). Otherwise, an error is
+  [repository](/versions/8.2.1/external/overview#repository). Otherwise, an error is
   reported.
 * The _outputRoot_ directory defaults to `${XDG_CACHE_HOME}/bazel` (or
   `~/.cache/bazel`, if the `XDG_CACHE_HOME` environment variable is not set) on
diff --git a/versions/8.2.1/remote/persistent.mdx b/versions/8.2.1/remote/persistent.mdx
index 3f654535..ec5264a0 100644
--- a/versions/8.2.1/remote/persistent.mdx
+++ b/versions/8.2.1/remote/persistent.mdx
@@ -257,7 +257,6 @@ For more information on persistent workers, see:
 *   [Original persistent workers blog post](https://blog.bazel.build/2015/12/10/java-workers.html)
 *   [Haskell implementation description](https://www.tweag.io/blog/2019-09-25-bazel-ghc-persistent-worker-internship/)
 *   [Blog post by Mike Morearty](https://medium.com/@mmorearty/how-to-create-a-persistent-worker-for-bazel-7738bba2cabb)
-*   [Front End Development with Bazel: Angular/TypeScript and Persistent Workers
-    w/ Asana](https://www.youtube.com/watch?v=0pgERydGyqo)
+*   [Front End Development with Bazel: Angular/TypeScript and Persistent Workers w/ Asana](https://www.youtube.com/watch?v=0pgERydGyqo)
 *   [Bazel strategies explained](https://jmmv.dev/2019/12/bazel-strategies.html)
 *   [Informative worker strategy discussion on the bazel-discuss mailing list](https://groups.google.com/forum/#!msg/bazel-discuss/oAEnuhYOPm8/ol7hf4KWJgAJ)
diff --git a/versions/8.2.1/remote/rules.mdx b/versions/8.2.1/remote/rules.mdx
index f9e22e7b..503ea395 100644
--- a/versions/8.2.1/remote/rules.mdx
+++ b/versions/8.2.1/remote/rules.mdx
@@ -54,8 +54,7 @@ variables that may not be set to equivalent values (or at all) in the remote
 execution environment.
 
 Toolchain rules currently exist for Bazel build and test rules for
-[Scala](https://github.com/bazelbuild/rules_scala/blob/master/scala/scala_toolch
-ain.bzl),
+[Scala](https://github.com/bazelbuild/rules_scala/blob/master/scala/scala_toolch ain.bzl),
 [Rust](https://github.com/bazelbuild/rules_rust/blob/main/rust/toolchain.bzl),
 and [Go](https://github.com/bazelbuild/rules_go/blob/master/go/toolchains.rst),
 and new toolchain rules are under way for other languages and tools such as
diff --git a/versions/8.2.1/remote/workspace.mdx b/versions/8.2.1/remote/workspace.mdx
index c7eea2bf..ce39388c 100644
--- a/versions/8.2.1/remote/workspace.mdx
+++ b/versions/8.2.1/remote/workspace.mdx
@@ -11,8 +11,7 @@ on the host machine. If your workspace rules access information about the
 host machine for use during execution, your build is likely to break due to
 incompatibilities between the environments.
 
-As part of [adapting Bazel rules for remote
-execution](/versions/8.2.1/remote/rules), you need to find such workspace rules
+As part of [adapting Bazel rules for remote execution](/versions/8.2.1/remote/rules), you need to find such workspace rules
 and fix them. This page describes how to find potentially problematic workspace
 rules using the workspace log.
 
diff --git a/versions/8.2.1/rules/challenges.mdx b/versions/8.2.1/rules/challenges.mdx
index 7bb26a65..af5f6b67 100644
--- a/versions/8.2.1/rules/challenges.mdx
+++ b/versions/8.2.1/rules/challenges.mdx
@@ -208,7 +208,7 @@ Bazel is heavily affected by both of these scenarios, so we introduced a set of
 custom collection classes that effectively compress the information in memory by
 avoiding the copy at each step. Almost all of these data structures have set
 semantics, so we called it
-[depset](/versions/8.2.1/rules/lib/depset)
+[depset](/versions/8.2.1/rules/lib/builtins/depset)
 (also known as `NestedSet` in the internal implementation). The majority of
 changes to reduce Bazel's memory consumption over the past several years were
 changes to use depsets instead of whatever was previously used.
diff --git a/versions/8.2.1/rules/faq.mdx b/versions/8.2.1/rules/faq.mdx
index 46371063..c094b309 100644
--- a/versions/8.2.1/rules/faq.mdx
+++ b/versions/8.2.1/rules/faq.mdx
@@ -17,7 +17,7 @@ Bazel only executes the actions needed to produce the *requested* output files.
 
 * If you want the file to be built automatically whenever your target is
   mentioned on the command line, add it to your rule's default outputs by
-  returning a [`DefaultInfo`](lib/globals#DefaultInfo) provider.
+  returning a [`DefaultInfo`](/versions/8.2.1/rules/lib/globals#DefaultInfo) provider.
 
 See the [Rules page](/versions/8.2.1/extending/rules#requesting-output-files) for more information.
 
@@ -35,24 +35,24 @@ correct path.
 
 For actions, you declare inputs by passing them to the `ctx.actions.*` function
 that creates the action. The proper path for the file can be obtained using
-[`File.path`](lib/File#path).
+[`File.path`](/versions/8.2.1/rules/lib/builtins/File#path).
 
 For binaries (the executable outputs run by a `bazel run` or `bazel test`
 command), you declare inputs by including them in the
 [runfiles](/versions/8.2.1/extending/rules#runfiles). Instead of using the `path` field, use
-[`File.short_path`](lib/File#short_path), which is file's path relative to
+[`File.short_path`](/versions/8.2.1/rules/lib/builtins/File#short_path), which is file's path relative to
 the runfiles directory in which the binary executes.
 
 ## How can I control which files are built by `bazel build //pkg:mytarget`?
 
-Use the [`DefaultInfo`](lib/globals#DefaultInfo) provider to
+Use the [`DefaultInfo`](/versions/8.2.1/rules/lib/globals#DefaultInfo) provider to
 [set the default outputs](/versions/8.2.1/extending/rules#requesting-output-files).
 
 ## How can I run a program or do file I/O as part of my build?
 
 A tool can be declared as a target, just like any other part of your build, and
 run during the execution phase to help build other targets. To create an action
-that runs a tool, use [`ctx.actions.run`](lib/actions#run) and pass in the
+that runs a tool, use [`ctx.actions.run`](/versions/8.2.1/rules/lib/builtins/actions#run) and pass in the
 tool as the `executable` parameter.
 
 During the loading and analysis phases, a tool *cannot* run, nor can you perform
diff --git a/versions/8.2.1/rules/language.mdx b/versions/8.2.1/rules/language.mdx
index e0ca1ec2..a7c06d89 100644
--- a/versions/8.2.1/rules/language.mdx
+++ b/versions/8.2.1/rules/language.mdx
@@ -34,19 +34,19 @@ Starlark's semantics can differ from Python, but behavioral differences are
 rare, except for cases where Starlark raises an error. The following Python
 types are supported:
 
-* [None](lib/globals#None)
-* [bool](lib/bool)
-* [dict](lib/dict)
-* [tuple](lib/tuple)
-* [function](lib/function)
-* [int](lib/int)
-* [list](lib/list)
-* [string](lib/string)
+* [None](/versions/8.2.1/rules/lib/globals#None)
+* [bool](/versions/8.2.1/rules/lib/core/bool)
+* [dict](/versions/8.2.1/rules/lib/core/dict)
+* [tuple](/versions/8.2.1/rules/lib/core/tuple)
+* [function](/versions/8.2.1/rules/lib/core/function)
+* [int](/versions/8.2.1/rules/lib/core/int)
+* [list](/versions/8.2.1/rules/lib/core/list)
+* [string](/versions/8.2.1/rules/lib/core/string)
 
 ## Mutability
 
 Starlark favors immutability. Two mutable data structures are available:
-[lists](lib/list) and [dicts](lib/dict). Changes to mutable
+[lists](/versions/8.2.1/rules/lib/core/list) and [dicts](/versions/8.2.1/rules/lib/core/dict). Changes to mutable
 data-structures, such as appending a value to a list or deleting an entry in a
 dictionary are valid only for objects created in the current context. After a
 context finishes, its values become immutable.
@@ -93,10 +93,8 @@ values returned by rules are immutable.
 `BUILD` files register targets via making calls to rules. `.bzl` files provide
 definitions for constants, rules, macros, and functions.
 
-[Native functions](/versions/8.2.1/reference/be/functions) and [native rules](
-/reference/be/overview#language-specific-native-rules) are global symbols in
-`BUILD` files. `bzl` files need to load them using the [`native` module](
-/rules/lib/toplevel/native).
+[Native functions](/versions/8.2.1/reference/be/functions) and [native rules](/versions/8.2.1/reference/be/overview#language-specific-native-rules) are global symbols in
+`BUILD` files. `bzl` files need to load them using the [`native` module](/versions/8.2.1/rules/lib/toplevel/native).
 
 There are two syntactic restrictions in `BUILD` files: 1) declaring functions is
 illegal, and 2) `*args` and `**kwargs` arguments are not allowed.
@@ -130,7 +128,7 @@ not defined across value types. In short: `5 < 'foo'` will throw an error and
   error: `{"a": 4, "b": 7, "a": 1}`.
 
 * Strings are represented with double-quotes (such as when you call
-  [repr](lib/globals#repr)).
+  [repr](/versions/8.2.1/rules/lib/globals#repr)).
 
 * Strings aren't iterable.
 
@@ -138,12 +136,12 @@ The following Python features are not supported:
 
 * implicit string concatenation (use explicit `+` operator).
 * Chained comparisons (such as `1 < x < 5`).
-* `class` (see [`struct`](lib/struct#struct) function).
+* `class` (see [`struct`](/versions/8.2.1/rules/lib/builtins/struct#struct) function).
 * `import` (see [`load`](/versions/8.2.1/extending/concepts#loading-an-extension) statement).
 * `while`, `yield`.
 * float and set types.
 * generators and generator expressions.
 * `is` (use `==` instead).
-* `try`, `raise`, `except`, `finally` (see [`fail`](lib/globals#fail) for fatal errors).
+* `try`, `raise`, `except`, `finally` (see [`fail`](/versions/8.2.1/rules/lib/globals#fail) for fatal errors).
 * `global`, `nonlocal`.
 * most builtin functions, most methods.
diff --git a/versions/8.2.1/rules/legacy-macro-tutorial.mdx b/versions/8.2.1/rules/legacy-macro-tutorial.mdx
index c115eed0..82ea9a4e 100644
--- a/versions/8.2.1/rules/legacy-macro-tutorial.mdx
+++ b/versions/8.2.1/rules/legacy-macro-tutorial.mdx
@@ -3,9 +3,7 @@ title: 'Creating a Legacy Macro'
 ---
 
 IMPORTANT: This tutorial is for [*legacy macros*](/versions/8.2.1/extending/legacy-macros). If
-you only need to support Bazel 8 or newer, we recommend using [symbolic
-macros](/versions/8.2.1/extending/macros) instead; take a look at [Creating a Symbolic
-Macro](../macro-tutorial).
+you only need to support Bazel 8 or newer, we recommend using [symbolic macros](/versions/8.2.1/extending/macros) instead; take a look at [Creating a Symbolic Macro](/versions/8.2.1/rules/macro-tutorial).
 
 Imagine that you need to run a tool as part of your build. For example, you
 may want to generate or preprocess a source file, or compress a binary. In this
diff --git a/versions/8.2.1/rules/lib/builtins/Action.mdx b/versions/8.2.1/rules/lib/builtins/Action.mdx
index 299c3245..998605c0 100644
--- a/versions/8.2.1/rules/lib/builtins/Action.mdx
+++ b/versions/8.2.1/rules/lib/builtins/Action.mdx
@@ -4,7 +4,7 @@ title: 'Action'
 
 An action created during rule analysis.
 
-This object is visible for the purpose of testing, and may be obtained from an `Actions` provider. It is normally not necessary to access `Action` objects or their fields within a rule's implementation function. You may instead want to see the [Rules page](https://bazel.build/versions/8.2.1/extending/rules#actions) for a general discussion of how to use actions when defining custom rules, or the [API reference](../builtins/actions) for creating actions.
+This object is visible for the purpose of testing, and may be obtained from an `Actions` provider. It is normally not necessary to access `Action` objects or their fields within a rule's implementation function. You may instead want to see the [Rules page](https://bazel.build/versions/8.2.1/extending/rules#actions) for a general discussion of how to use actions when defining custom rules, or the [API reference](/versions/8.2.1/rules/lib/builtins/actions) for creating actions.
 
 Some fields of this object are only applicable for certain kinds of actions. Fields that are inapplicable are set to `None`.
 
@@ -25,7 +25,7 @@ Some fields of this object are only applicable for certain kinds of actions. Fie
 sequence Action.args
 ```
 
-A list of frozen [Args](../builtins/Args) objects containing information about the action arguments. These objects contain accurate argument information, including arguments involving expanded action output directories. However, [Args](../builtins/Args) objects are not readable in the analysis phase. For a less accurate account of arguments which is available in the analysis phase, see [argv](#argv).
+A list of frozen [Args](/versions/8.2.1/rules/lib/builtins/Args) objects containing information about the action arguments. These objects contain accurate argument information, including arguments involving expanded action output directories. However, [Args](/versions/8.2.1/rules/lib/builtins/Args) objects are not readable in the analysis phase. For a less accurate account of arguments which is available in the analysis phase, see [argv](#argv).
 
 Note that some types of actions do not yet support exposure of this field. For such action types, this is `None`.
 May return `None`.
@@ -36,7 +36,7 @@ May return `None`.
 sequence Action.argv
 ```
 
-For actions created by [ctx.actions.run()](../builtins/actions#run) or [ctx.actions.run\_shell()](../builtins/actions#run_shell) an immutable list of the arguments for the command line to be executed. Note that for shell actions the first two arguments will be the shell path and `"-c"`.
+For actions created by [ctx.actions.run()](/versions/8.2.1/rules/lib/builtins/actions#run) or [ctx.actions.run\_shell()](/versions/8.2.1/rules/lib/builtins/actions#run_shell) an immutable list of the arguments for the command line to be executed. Note that for shell actions the first two arguments will be the shell path and `"-c"`.
 May return `None`.
 
 ## content
@@ -45,7 +45,7 @@ May return `None`.
 string Action.content
 ```
 
-For actions created by [ctx.actions.write()](../builtins/actions#write) or [ctx.actions.expand\_template()](../builtins/actions#expand_template), the contents of the file to be written, if those contents can be computed during the analysis phase. The value is `None` if the contents cannot be determined until the execution phase, such as when a directory in an [Args](../builtins/Args) object needs to be expanded.
+For actions created by [ctx.actions.write()](/versions/8.2.1/rules/lib/builtins/actions#write) or [ctx.actions.expand\_template()](/versions/8.2.1/rules/lib/builtins/actions#expand_template), the contents of the file to be written, if those contents can be computed during the analysis phase. The value is `None` if the contents cannot be determined until the execution phase, such as when a directory in an [Args](/versions/8.2.1/rules/lib/builtins/Args) object needs to be expanded.
 May return `None`.
 
 ## env
@@ -86,5 +86,5 @@ A set of the output files of this action.
 dict Action.substitutions
 ```
 
-For actions created by [ctx.actions.expand\_template()](../builtins/actions#expand_template), an immutable dict holding the substitution mapping.
+For actions created by [ctx.actions.expand\_template()](/versions/8.2.1/rules/lib/builtins/actions#expand_template), an immutable dict holding the substitution mapping.
 May return `None`.
\ No newline at end of file
diff --git a/versions/8.2.1/rules/lib/builtins/Args.mdx b/versions/8.2.1/rules/lib/builtins/Args.mdx
index f274b3ae..7ffd2178 100644
--- a/versions/8.2.1/rules/lib/builtins/Args.mdx
+++ b/versions/8.2.1/rules/lib/builtins/Args.mdx
@@ -4,15 +4,15 @@ title: 'Args'
 
 An object that encapsulates, in a memory-efficient way, the data needed to build part or all of a command line.
 
-It often happens that an action requires a large command line containing values accumulated from transitive dependencies. For example, a linker command line might list every object file needed by all of the libraries being linked. It is best practice to store such transitive data in [`depset`](../builtins/depset)s, so that they can be shared by multiple targets. However, if the rule author had to convert these depsets into lists of strings in order to construct an action command line, it would defeat this memory-sharing optimization.
+It often happens that an action requires a large command line containing values accumulated from transitive dependencies. For example, a linker command line might list every object file needed by all of the libraries being linked. It is best practice to store such transitive data in [`depset`](/versions/8.2.1/rules/lib/builtins/depset)s, so that they can be shared by multiple targets. However, if the rule author had to convert these depsets into lists of strings in order to construct an action command line, it would defeat this memory-sharing optimization.
 
 For this reason, the action-constructing functions accept `Args` objects in addition to strings. Each `Args` object represents a concatenation of strings and depsets, with optional transformations for manipulating the data. `Args` objects do not process the depsets they encapsulate until the execution phase, when it comes time to calculate the command line. This helps defer any expensive copying until after the analysis phase is complete. See the [Optimizing Performance](https://bazel.build/versions/8.2.1/rules/performance) page for more information.
 
-`Args` are constructed by calling [`ctx.actions.args()`](../builtins/actions#args). They can be passed as the `arguments` parameter of [`ctx.actions.run()`](../builtins/actions#run) or [`ctx.actions.run_shell()`](../builtins/actions#run_shell). Each mutation of an `Args` object appends values to the eventual command line.
+`Args` are constructed by calling [`ctx.actions.args()`](/versions/8.2.1/rules/lib/builtins/actions#args). They can be passed as the `arguments` parameter of [`ctx.actions.run()`](/versions/8.2.1/rules/lib/builtins/actions#run) or [`ctx.actions.run_shell()`](/versions/8.2.1/rules/lib/builtins/actions#run_shell). Each mutation of an `Args` object appends values to the eventual command line.
 
 The `map_each` feature allows you to customize how items are transformed into strings. If you do not provide a `map_each` function, the standard conversion is as follows:
 
-* Values that are already strings are left as-is.* [`File`](../builtins/File) objects are turned into their `File.path` values.* [`Label`](../builtins/Label) objects are turned into a string representation that resolves back to the same object when resolved in the context of the main repository. If possible, the string representation uses the apparent name of a repository in favor of the repository's canonical name, which makes this representation suited for use in BUILD files. While the exact form of the representation is not guaranteed, typical examples are `//foo:bar`, `@repo//foo:bar` and `@@canonical_name+//foo:bar.bzl`.* All other types are turned into strings in an *unspecified* manner. For this reason, you should avoid passing values that are not of string or `File` type to `add()`, and if you pass them to `add_all()` or `add_joined()` then you should provide a `map_each` function.
+* Values that are already strings are left as-is.* [`File`](/versions/8.2.1/rules/lib/builtins/File) objects are turned into their `File.path` values.* [`Label`](/versions/8.2.1/rules/lib/builtins/Label) objects are turned into a string representation that resolves back to the same object when resolved in the context of the main repository. If possible, the string representation uses the apparent name of a repository in favor of the repository's canonical name, which makes this representation suited for use in BUILD files. While the exact form of the representation is not guaranteed, typical examples are `//foo:bar`, `@repo//foo:bar` and `@@canonical_name+//foo:bar.bzl`.* All other types are turned into strings in an *unspecified* manner. For this reason, you should avoid passing values that are not of string or `File` type to `add()`, and if you pass them to `add_all()` or `add_joined()` then you should provide a `map_each` function.
 
 When using string formatting (`format`, `format_each`, and `format_joined` params of the `add*()` methods), the format template is interpreted in the same way as `%`-substitution on strings, except that the template must have exactly one substitution placeholder and it must be `%s`. Literal percents may be escaped as `%%`. Formatting is applied after the value is converted to a string as per the above.
 
@@ -64,7 +64,7 @@ Appends an argument to this command line.
 | --- | --- |
 | `arg_name_or_value` | required  If two positional parameters are passed this is interpreted as the arg name. The arg name is added before the value without any processing. If only one positional parameter is passed, it is interpreted as `value` (see below). |
 | `value` | default is `unbound`  The object to append. It will be converted to a string using the standard conversion mentioned above. Since there is no `map_each` parameter for this function, `value` should be either a string or a `File`. A list, tuple, depset, or directory `File` must be passed to [`add_all()` or [`add_joined()`](#add_joined) instead of this method.](#add_all) |
-| `format` | [string](../core/string); or `None`; default is `None`  A format string pattern, to be applied to the stringified version of `value`. |
+| `format` | [string](/versions/8.2.1/rules/lib/core/string); or `None`; default is `None`  A format string pattern, to be applied to the stringified version of `value`. |
 
 ## add\_all
 
@@ -86,15 +86,15 @@ Note that empty strings are valid arguments that are subject to all these proces
 | Parameter | Description |
 | --- | --- |
 | `arg_name_or_values` | required  If two positional parameters are passed this is interpreted as the arg name. The arg name is added before the `values` as a separate argument without any processing. This arg name will not be added if `omit_if_empty` is true (the default) and no other items are appended (as happens if `values` is empty or all of its items are filtered). If only one positional parameter is passed, it is interpreted as `values` (see below). |
-| `values` | [sequence](../core/list); or [depset](../builtins/depset); default is `unbound`  The list, tuple, or depset whose items will be appended. |
-| `map_each` | callable; or `None`; default is `None`  A function that converts each item to zero or more strings, which may be further processed before appending. If this param is not provided, the standard conversion is used. The function is passed either one or two positional arguments: the item to convert, followed by an optional [`DirectoryExpander`](../builtins/DirectoryExpander). The second argument will be passed only if the supplied function is user-defined (not built-in) and declares more than one parameter. The return value's type depends on how many arguments are to be produced for the item:  * In the common case when each item turns into one string, the function should return that string.* If the item is to be filtered out entirely, the function should return `None`.* If the item turns into multiple strings, the function returns a list of those strings.  Returning a single string or `None` has the same effect as returning a list of length 1 or length 0 respectively. However, it is more efficient and readable to avoid creating a list where it is not needed. Ordinarily, items that are directories are automatically expanded to their contents when `expand_directories=True` is set. However, this will not expand directories contained inside other values -- for instance, when the items are structs that have directories as fields. In this situation, the `DirectoryExpander` argument can be applied to manually obtain the files of a given directory. To avoid unintended retention of large analysis-phase data structures into the execution phase, the `map_each` function must be declared by a top-level `def` statement; it may not be a nested function closure by default. *Warning:* [`print()`](../globals/all#print) statements that are executed during the call to `map_each` will not produce any visible output. |
-| `format_each` | [string](../core/string); or `None`; default is `None`  An optional format string pattern, applied to each string returned by the `map_each` function. The format string must have exactly one '%s' placeholder. |
-| `before_each` | [string](../core/string); or `None`; default is `None`  An optional argument to append before each argument derived from `values` is appended. |
-| `omit_if_empty` | [bool](../core/bool); default is `True`  If true, if there are no arguments derived from `values` to be appended, then all further processing is suppressed and the command line will be unchanged. If false, the arg name and `terminate_with`, if provided, will still be appended regardless of whether or not there are other arguments. |
-| `uniquify` | [bool](../core/bool); default is `False`  If true, duplicate arguments that are derived from `values` will be omitted. Only the first occurrence of each argument will remain. Usually this feature is not needed because depsets already omit duplicates, but it can be useful if `map_each` emits the same string for multiple items. |
-| `expand_directories` | [bool](../core/bool); default is `True`  If true, any directories in `values` will be expanded to a flat list of files. This happens before `map_each` is applied. |
-| `terminate_with` | [string](../core/string); or `None`; default is `None`  An optional argument to append after all other arguments. This argument will not be added if `omit_if_empty` is true (the default) and no other items are appended (as happens if `values` is empty or all of its items are filtered). |
-| `allow_closure` | [bool](../core/bool); default is `False`  If true, allows the use of closures in function parameters like `map_each`. Usually this isn't necessary and it risks retaining large analysis-phase data structures into the execution phase. |
+| `values` | [sequence](/versions/8.2.1/rules/lib/core/list); or [depset](/versions/8.2.1/rules/lib/builtins/depset); default is `unbound`  The list, tuple, or depset whose items will be appended. |
+| `map_each` | callable; or `None`; default is `None`  A function that converts each item to zero or more strings, which may be further processed before appending. If this param is not provided, the standard conversion is used. The function is passed either one or two positional arguments: the item to convert, followed by an optional [`DirectoryExpander`](/versions/8.2.1/rules/lib/builtins/DirectoryExpander). The second argument will be passed only if the supplied function is user-defined (not built-in) and declares more than one parameter. The return value's type depends on how many arguments are to be produced for the item:  * In the common case when each item turns into one string, the function should return that string.* If the item is to be filtered out entirely, the function should return `None`.* If the item turns into multiple strings, the function returns a list of those strings.  Returning a single string or `None` has the same effect as returning a list of length 1 or length 0 respectively. However, it is more efficient and readable to avoid creating a list where it is not needed. Ordinarily, items that are directories are automatically expanded to their contents when `expand_directories=True` is set. However, this will not expand directories contained inside other values -- for instance, when the items are structs that have directories as fields. In this situation, the `DirectoryExpander` argument can be applied to manually obtain the files of a given directory. To avoid unintended retention of large analysis-phase data structures into the execution phase, the `map_each` function must be declared by a top-level `def` statement; it may not be a nested function closure by default. *Warning:* [`print()`](/versions/8.2.1/rules/lib/globals/all#print) statements that are executed during the call to `map_each` will not produce any visible output. |
+| `format_each` | [string](/versions/8.2.1/rules/lib/core/string); or `None`; default is `None`  An optional format string pattern, applied to each string returned by the `map_each` function. The format string must have exactly one '%s' placeholder. |
+| `before_each` | [string](/versions/8.2.1/rules/lib/core/string); or `None`; default is `None`  An optional argument to append before each argument derived from `values` is appended. |
+| `omit_if_empty` | [bool](/versions/8.2.1/rules/lib/core/bool); default is `True`  If true, if there are no arguments derived from `values` to be appended, then all further processing is suppressed and the command line will be unchanged. If false, the arg name and `terminate_with`, if provided, will still be appended regardless of whether or not there are other arguments. |
+| `uniquify` | [bool](/versions/8.2.1/rules/lib/core/bool); default is `False`  If true, duplicate arguments that are derived from `values` will be omitted. Only the first occurrence of each argument will remain. Usually this feature is not needed because depsets already omit duplicates, but it can be useful if `map_each` emits the same string for multiple items. |
+| `expand_directories` | [bool](/versions/8.2.1/rules/lib/core/bool); default is `True`  If true, any directories in `values` will be expanded to a flat list of files. This happens before `map_each` is applied. |
+| `terminate_with` | [string](/versions/8.2.1/rules/lib/core/string); or `None`; default is `None`  An optional argument to append after all other arguments. This argument will not be added if `omit_if_empty` is true (the default) and no other items are appended (as happens if `values` is empty or all of its items are filtered). |
+| `allow_closure` | [bool](/versions/8.2.1/rules/lib/core/bool); default is `False`  If true, allows the use of closures in function parameters like `map_each`. Usually this isn't necessary and it risks retaining large analysis-phase data structures into the execution phase. |
 
 ## add\_joined
 
@@ -113,15 +113,15 @@ If after filtering there are no strings to join into an argument, and if `omit_i
 | Parameter | Description |
 | --- | --- |
 | `arg_name_or_values` | required  If two positional parameters are passed this is interpreted as the arg name. The arg name is added before `values` without any processing. This arg will not be added if `omit_if_empty` is true (the default) and there are no strings derived from `values` to join together (which can happen if `values` is empty or all of its items are filtered). If only one positional parameter is passed, it is interpreted as `values` (see below). |
-| `values` | [sequence](../core/list); or [depset](../builtins/depset); default is `unbound`  The list, tuple, or depset whose items will be joined. |
-| `join_with` | [string](../core/string); required  A delimiter string used to join together the strings obtained from applying `map_each` and `format_each`, in the same manner as [`string.join()`](../core/string#join). |
+| `values` | [sequence](/versions/8.2.1/rules/lib/core/list); or [depset](/versions/8.2.1/rules/lib/builtins/depset); default is `unbound`  The list, tuple, or depset whose items will be joined. |
+| `join_with` | [string](/versions/8.2.1/rules/lib/core/string); required  A delimiter string used to join together the strings obtained from applying `map_each` and `format_each`, in the same manner as [`string.join()`](/versions/8.2.1/rules/lib/core/string#join). |
 | `map_each` | callable; or `None`; default is `None`  Same as for [`add_all`](#add_all.map_each). |
-| `format_each` | [string](../core/string); or `None`; default is `None`  Same as for [`add_all`](#add_all.format_each). |
-| `format_joined` | [string](../core/string); or `None`; default is `None`  An optional format string pattern applied to the joined string. The format string must have exactly one '%s' placeholder. |
-| `omit_if_empty` | [bool](../core/bool); default is `True`  If true, if there are no strings to join together (either because `values` is empty or all its items are filtered), then all further processing is suppressed and the command line will be unchanged. If false, then even if there are no strings to join together, two arguments will be appended: the arg name followed by an empty string (which is the logical join of zero strings). |
-| `uniquify` | [bool](../core/bool); default is `False`  Same as for [`add_all`](#add_all.uniquify). |
-| `expand_directories` | [bool](../core/bool); default is `True`  Same as for [`add_all`](#add_all.expand_directories). |
-| `allow_closure` | [bool](../core/bool); default is `False`  Same as for [`add_all`](#add_all.allow_closure). |
+| `format_each` | [string](/versions/8.2.1/rules/lib/core/string); or `None`; default is `None`  Same as for [`add_all`](#add_all.format_each). |
+| `format_joined` | [string](/versions/8.2.1/rules/lib/core/string); or `None`; default is `None`  An optional format string pattern applied to the joined string. The format string must have exactly one '%s' placeholder. |
+| `omit_if_empty` | [bool](/versions/8.2.1/rules/lib/core/bool); default is `True`  If true, if there are no strings to join together (either because `values` is empty or all its items are filtered), then all further processing is suppressed and the command line will be unchanged. If false, then even if there are no strings to join together, two arguments will be appended: the arg name followed by an empty string (which is the logical join of zero strings). |
+| `uniquify` | [bool](/versions/8.2.1/rules/lib/core/bool); default is `False`  Same as for [`add_all`](#add_all.uniquify). |
+| `expand_directories` | [bool](/versions/8.2.1/rules/lib/core/bool); default is `True`  Same as for [`add_all`](#add_all.expand_directories). |
+| `allow_closure` | [bool](/versions/8.2.1/rules/lib/core/bool); default is `False`  Same as for [`add_all`](#add_all.allow_closure). |
 
 ## set\_param\_file\_format
 
@@ -135,7 +135,7 @@ Sets the format of the param file, if one is used
 
 | Parameter | Description |
 | --- | --- |
-| `format` | [string](../core/string); required  Must be one of:  * "multiline": Each item (argument name or value) is written verbatim to the param file with a newline character following it. * "shell": Same as "multiline", but the items are shell-quoted * "flag\_per\_line": Same as "multiline", but (1) only flags (beginning with '--') are written to the param file, and (2) the values of the flags, if any, are written on the same line with a '=' separator. This is the format expected by the Abseil flags library.   The format defaults to "shell" if not called. |
+| `format` | [string](/versions/8.2.1/rules/lib/core/string); required  Must be one of:  * "multiline": Each item (argument name or value) is written verbatim to the param file with a newline character following it. * "shell": Same as "multiline", but the items are shell-quoted * "flag\_per\_line": Same as "multiline", but (1) only flags (beginning with '--') are written to the param file, and (2) the values of the flags, if any, are written on the same line with a '=' separator. This is the format expected by the Abseil flags library.   The format defaults to "shell" if not called. |
 
 ## use\_param\_file
 
@@ -151,5 +151,5 @@ Bazel may choose to elide writing the params file to the output tree during exec
 
 | Parameter | Description |
 | --- | --- |
-| `param_file_arg` | [string](../core/string); required  A format string with a single "%s". If the args are spilled to a params file then they are replaced with an argument consisting of this string formatted with the path of the params file. For example, if the args are spilled to a params file "params.txt", then specifying "--file=%s" would cause the action command line to contain "--file=params.txt". |
-| `use_always` | [bool](../core/bool); default is `False`  Whether to always spill the args to a params file. If false, bazel will decide whether the arguments need to be spilled based on your system and arg length. |
\ No newline at end of file
+| `param_file_arg` | [string](/versions/8.2.1/rules/lib/core/string); required  A format string with a single "%s". If the args are spilled to a params file then they are replaced with an argument consisting of this string formatted with the path of the params file. For example, if the args are spilled to a params file "params.txt", then specifying "--file=%s" would cause the action command line to contain "--file=params.txt". |
+| `use_always` | [bool](/versions/8.2.1/rules/lib/core/bool); default is `False`  Whether to always spill the args to a params file. If false, bazel will decide whether the arguments need to be spilled based on your system and arg length. |
\ No newline at end of file
diff --git a/versions/8.2.1/rules/lib/builtins/Aspect.mdx b/versions/8.2.1/rules/lib/builtins/Aspect.mdx
index ca75800d..74abdc2a 100644
--- a/versions/8.2.1/rules/lib/builtins/Aspect.mdx
+++ b/versions/8.2.1/rules/lib/builtins/Aspect.mdx
@@ -3,4 +3,4 @@ title: 'Aspect'
 ---
 
 For more information about Aspects, please consult the
-[documentation of the aspect function](../globals/bzl#aspect) or the [introduction to Aspects](https://bazel.build/versions/8.2.1/rules/aspects).
\ No newline at end of file
+[documentation of the aspect function](/versions/8.2.1/rules/lib/globals/bzl#aspect) or the [introduction to Aspects](https://bazel.build/versions/8.2.1/rules/aspects).
\ No newline at end of file
diff --git a/versions/8.2.1/rules/lib/builtins/Attribute.mdx b/versions/8.2.1/rules/lib/builtins/Attribute.mdx
index 18486c41..04c33b3f 100644
--- a/versions/8.2.1/rules/lib/builtins/Attribute.mdx
+++ b/versions/8.2.1/rules/lib/builtins/Attribute.mdx
@@ -2,4 +2,4 @@
 title: 'Attribute'
 ---
 
-Representation of a definition of an attribute. Use the [attr](../toplevel/attr) module to create an Attribute. They are only for use with a [rule](../globals/bzl#rule) or an [aspect](../globals/bzl#aspect).
\ No newline at end of file
+Representation of a definition of an attribute. Use the [attr](/versions/8.2.1/rules/lib/toplevel/attr) module to create an Attribute. They are only for use with a [rule](/versions/8.2.1/rules/lib/globals/bzl#rule) or an [aspect](/versions/8.2.1/rules/lib/globals/bzl#aspect).
\ No newline at end of file
diff --git a/versions/8.2.1/rules/lib/builtins/DirectoryExpander.mdx b/versions/8.2.1/rules/lib/builtins/DirectoryExpander.mdx
index 8bf9ae69..22d58c7a 100644
--- a/versions/8.2.1/rules/lib/builtins/DirectoryExpander.mdx
+++ b/versions/8.2.1/rules/lib/builtins/DirectoryExpander.mdx
@@ -2,7 +2,7 @@
 title: 'DirectoryExpander'
 ---
 
-Expands directories created by [`ctx.actions.declare_directory`](../builtins/actions#declare_directory) during the execution phase. This is useful to expand directories in [`map_each`](../builtins/Args#add_all.map_each).
+Expands directories created by [`ctx.actions.declare_directory`](/versions/8.2.1/rules/lib/builtins/actions#declare_directory) during the execution phase. This is useful to expand directories in [`map_each`](/versions/8.2.1/rules/lib/builtins/Args#add_all.map_each).
 
 ## Members
 
@@ -20,4 +20,4 @@ If the given `File` is a directory, this returns a list of `File`s recursively u
 
 | Parameter | Description |
 | --- | --- |
-| `file` | [File](../builtins/File); required  The directory or file to expand. |
\ No newline at end of file
+| `file` | [File](/versions/8.2.1/rules/lib/builtins/File); required  The directory or file to expand. |
\ No newline at end of file
diff --git a/versions/8.2.1/rules/lib/builtins/DottedVersion.mdx b/versions/8.2.1/rules/lib/builtins/DottedVersion.mdx
index f17cea85..e87ceab5 100644
--- a/versions/8.2.1/rules/lib/builtins/DottedVersion.mdx
+++ b/versions/8.2.1/rules/lib/builtins/DottedVersion.mdx
@@ -20,4 +20,4 @@ Compares based on most significant (first) not-matching version component. So, f
 
 | Parameter | Description |
 | --- | --- |
-| `other` | [DottedVersion](../builtins/DottedVersion); required  The other dotted version. |
\ No newline at end of file
+| `other` | [DottedVersion](/versions/8.2.1/rules/lib/builtins/DottedVersion); required  The other dotted version. |
\ No newline at end of file
diff --git a/versions/8.2.1/rules/lib/builtins/File.mdx b/versions/8.2.1/rules/lib/builtins/File.mdx
index c9de4af0..a2bca2a8 100644
--- a/versions/8.2.1/rules/lib/builtins/File.mdx
+++ b/versions/8.2.1/rules/lib/builtins/File.mdx
@@ -4,7 +4,7 @@ title: 'File'
 
 This object is created during the analysis phase to represent a file or directory that will be read or written during the execution phase. It is not an open file handle, and cannot be used to directly read or write file contents. Rather, you use it to construct the action graph in a rule implementation function by passing it to action-creating functions. See the [Rules page](https://bazel.build/versions/8.2.1/extending/rules#files) for more information.
 
-When a `File` is passed to an [`Args`](../builtins/Args) object without using a `map_each` function, it is converted to a string by taking the value of its `path` field.
+When a `File` is passed to an [`Args`](/versions/8.2.1/rules/lib/builtins/Args) object without using a `map_each` function, it is converted to a string by taking the value of its `path` field.
 
 ## Members
 
@@ -83,7 +83,7 @@ May return `None`.
 string File.path
 ```
 
-The execution path of this file, relative to the workspace's execution directory. It consists of two parts, an optional first part called the *root* (see also the [root](../builtins/root) module), and the second part which is the `short_path`. The root may be empty, which it usually is for non-generated files. For generated files it usually contains a configuration-specific path fragment that encodes things like the target CPU architecture that was used while building said file. Use the `short_path` for the path under which the file is mapped if it's in the runfiles of a binary.
+The execution path of this file, relative to the workspace's execution directory. It consists of two parts, an optional first part called the *root* (see also the [root](/versions/8.2.1/rules/lib/builtins/root) module), and the second part which is the `short_path`. The root may be empty, which it usually is for non-generated files. For generated files it usually contains a configuration-specific path fragment that encodes things like the target CPU architecture that was used while building said file. Use the `short_path` for the path under which the file is mapped if it's in the runfiles of a binary.
 
 ## root
 
@@ -107,4 +107,4 @@ The path of this file relative to its root. This excludes the aforementioned *ro
 string File.tree_relative_path
 ```
 
-The path of this file relative to the root of the ancestor's tree, if the ancestor's [is\_directory](#is_directory) field is true. `tree_relative_path` is only available for expanded files of a directory in an action command, i.e. [Args.add\_all()](../builtins/Args#add_all). For other types of files, it is an error to access this field.
\ No newline at end of file
+The path of this file relative to the root of the ancestor's tree, if the ancestor's [is\_directory](#is_directory) field is true. `tree_relative_path` is only available for expanded files of a directory in an action command, i.e. [Args.add\_all()](/versions/8.2.1/rules/lib/builtins/Args#add_all). For other types of files, it is an error to access this field.
\ No newline at end of file
diff --git a/versions/8.2.1/rules/lib/builtins/Label.mdx b/versions/8.2.1/rules/lib/builtins/Label.mdx
index e2359800..6e0dfdb7 100644
--- a/versions/8.2.1/rules/lib/builtins/Label.mdx
+++ b/versions/8.2.1/rules/lib/builtins/Label.mdx
@@ -33,7 +33,7 @@ For macros, a related function, `native.package_relative_label()`, converts the
 
 | Parameter | Description |
 | --- | --- |
-| `input` | [string](../core/string); or [Label](../builtins/Label); required  The input label string or Label object. If a Label object is passed, it's returned as is. |
+| `input` | [string](/versions/8.2.1/rules/lib/core/string); or [Label](/versions/8.2.1/rules/lib/builtins/Label); required  The input label string or Label object. If a Label object is passed, it's returned as is. |
 
 ## name
 
@@ -66,7 +66,7 @@ Label Label.relative(relName)
 ```
 
 **Experimental**. This API is experimental and may change at any time. Please do not depend on it. It may be enabled on an experimental basis by setting `--+incompatible_enable_deprecated_label_apis`
-**Deprecated.** This method behaves surprisingly when used with an argument containing an apparent repo name. Prefer [`Label.same_package_label()`](#same_package_label), [`native.package_relative_label()`](../toplevel/native#package_relative_label), or [`Label()`](#Label) instead.
+**Deprecated.** This method behaves surprisingly when used with an argument containing an apparent repo name. Prefer [`Label.same_package_label()`](#same_package_label), [`native.package_relative_label()`](/versions/8.2.1/rules/lib/toplevel/native#package_relative_label), or [`Label()`](#Label) instead.
 
 Resolves a label that is either absolute (starts with `//`) or relative to the current package. If this label is in a remote repository, the argument will be resolved relative to that repository. If the argument contains a repository name, the current label is ignored and the argument is returned as-is, except that the repository name is rewritten if it is in the current repository mapping. Reserved labels will also be returned as-is.
 For example:
@@ -89,7 +89,7 @@ Label("@repo//foo/bar:baz").relative("@other//wiz:quux") == Label("@remapped//wi
 
 | Parameter | Description |
 | --- | --- |
-| `relName` | [string](../core/string); required |
+| `relName` | [string](/versions/8.2.1/rules/lib/core/string); required |
 
 ## repo\_name
 
@@ -115,7 +115,7 @@ Creates a label in the same package as this label with the given target name.
 
 | Parameter | Description |
 | --- | --- |
-| `target_name` | [string](../core/string); required |
+| `target_name` | [string](/versions/8.2.1/rules/lib/core/string); required |
 
 ## workspace\_name
 
diff --git a/versions/8.2.1/rules/lib/builtins/LateBoundDefault.mdx b/versions/8.2.1/rules/lib/builtins/LateBoundDefault.mdx
index edd0010c..ec335e38 100644
--- a/versions/8.2.1/rules/lib/builtins/LateBoundDefault.mdx
+++ b/versions/8.2.1/rules/lib/builtins/LateBoundDefault.mdx
@@ -4,4 +4,4 @@ title: 'LateBoundDefault'
 
 Represents a late-bound default attribute value of type 'Label'. The value of a LateBoundDefault is only resolvable in the context of a rule implementation function, and depends on the current build configuration. For example, a LateBoundDefault might represent the Label of the java toolchain in the current build configuration.
 
-See [configuration\_field](../globals/bzl#configuration_field) for example usage.
\ No newline at end of file
+See [configuration\_field](/versions/8.2.1/rules/lib/globals/bzl#configuration_field) for example usage.
\ No newline at end of file
diff --git a/versions/8.2.1/rules/lib/builtins/Provider.mdx b/versions/8.2.1/rules/lib/builtins/Provider.mdx
index 54b9cf36..90630828 100644
--- a/versions/8.2.1/rules/lib/builtins/Provider.mdx
+++ b/versions/8.2.1/rules/lib/builtins/Provider.mdx
@@ -14,7 +14,7 @@ This value has a dual purpose:
   ```
 
   Note: Some providers, defined internally, do not allow instance creation
-* It is a *key* to access a provider instance on a [Target](../builtins/Target)
+* It is a *key* to access a provider instance on a [Target](/versions/8.2.1/rules/lib/builtins/Target)
 
   ```
   DataInfo = provider()
@@ -22,4 +22,4 @@ This value has a dual purpose:
     ... ctx.attr.dep[DataInfo]
   ```
 
-Create a new `Provider` using the [provider](../globals/bzl#provider) function.
\ No newline at end of file
+Create a new `Provider` using the [provider](/versions/8.2.1/rules/lib/globals/bzl#provider) function.
\ No newline at end of file
diff --git a/versions/8.2.1/rules/lib/builtins/TemplateDict.mdx b/versions/8.2.1/rules/lib/builtins/TemplateDict.mdx
index 5f18fd44..509ca10f 100644
--- a/versions/8.2.1/rules/lib/builtins/TemplateDict.mdx
+++ b/versions/8.2.1/rules/lib/builtins/TemplateDict.mdx
@@ -21,8 +21,8 @@ Add a String value
 
 | Parameter | Description |
 | --- | --- |
-| `key` | [string](../core/string); required  A String key |
-| `value` | [string](../core/string); required  A String value |
+| `key` | [string](/versions/8.2.1/rules/lib/core/string); required  A String key |
+| `value` | [string](/versions/8.2.1/rules/lib/core/string); required  A String value |
 
 ## add\_joined
 
@@ -36,10 +36,10 @@ Add depset of values
 
 | Parameter | Description |
 | --- | --- |
-| `key` | [string](../core/string); required  A String key |
-| `values` | [depset](../builtins/depset); required  The depset whose items will be joined. |
-| `join_with` | [string](../core/string); required  A delimiter string used to join together the strings obtained from applying `map_each`, in the same manner as [`string.join()`](../core/string#join). |
+| `key` | [string](/versions/8.2.1/rules/lib/core/string); required  A String key |
+| `values` | [depset](/versions/8.2.1/rules/lib/builtins/depset); required  The depset whose items will be joined. |
+| `join_with` | [string](/versions/8.2.1/rules/lib/core/string); required  A delimiter string used to join together the strings obtained from applying `map_each`, in the same manner as [`string.join()`](/versions/8.2.1/rules/lib/core/string#join). |
 | `map_each` | callable; required  A Starlark function accepting a single argument and returning either a string, `None`, or a list of strings. This function is applied to each item of the depset specified in the `values` parameter |
-| `uniquify` | [bool](../core/bool); default is `False`  If true, duplicate strings derived from `values` will be omitted. Only the first occurrence of each string will remain. Usually this feature is not needed because depsets already omit duplicates, but it can be useful if `map_each` emits the same string for multiple items. |
-| `format_joined` | [string](../core/string); or `None`; default is `None`  An optional format string pattern applied to the joined string. The format string must have exactly one '%s' placeholder. |
-| `allow_closure` | [bool](../core/bool); default is `False`  If true, allows the use of closures in function parameters like `map_each`. Usually this isn't necessary and it risks retaining large analysis-phase data structures into the execution phase. |
\ No newline at end of file
+| `uniquify` | [bool](/versions/8.2.1/rules/lib/core/bool); default is `False`  If true, duplicate strings derived from `values` will be omitted. Only the first occurrence of each string will remain. Usually this feature is not needed because depsets already omit duplicates, but it can be useful if `map_each` emits the same string for multiple items. |
+| `format_joined` | [string](/versions/8.2.1/rules/lib/core/string); or `None`; default is `None`  An optional format string pattern applied to the joined string. The format string must have exactly one '%s' placeholder. |
+| `allow_closure` | [bool](/versions/8.2.1/rules/lib/core/bool); default is `False`  If true, allows the use of closures in function parameters like `map_each`. Usually this isn't necessary and it risks retaining large analysis-phase data structures into the execution phase. |
\ No newline at end of file
diff --git a/versions/8.2.1/rules/lib/builtins/actions.mdx b/versions/8.2.1/rules/lib/builtins/actions.mdx
index b4564bb3..01682d60 100644
--- a/versions/8.2.1/rules/lib/builtins/actions.mdx
+++ b/versions/8.2.1/rules/lib/builtins/actions.mdx
@@ -2,7 +2,7 @@
 title: 'actions'
 ---
 
-Module providing functions to create actions. Access this module using [`ctx.actions`](../builtins/ctx#actions).
+Module providing functions to create actions. Access this module using [`ctx.actions`](/versions/8.2.1/rules/lib/builtins/ctx#actions).
 
 ## Members
 
@@ -32,14 +32,14 @@ Returns an Args object that can be used to build memory-efficient command lines.
 File actions.declare_directory(filename, *, sibling=None)
 ```
 
-Declares that the rule or aspect creates a directory with the given name, in the current package. You must create an action that generates the directory. The contents of the directory are not directly accessible from Starlark, but can be expanded in an action command with [`Args.add_all()`](../builtins/Args#add_all). Only regular files and directories can be in the expanded contents of a declare\_directory.
+Declares that the rule or aspect creates a directory with the given name, in the current package. You must create an action that generates the directory. The contents of the directory are not directly accessible from Starlark, but can be expanded in an action command with [`Args.add_all()`](/versions/8.2.1/rules/lib/builtins/Args#add_all). Only regular files and directories can be in the expanded contents of a declare\_directory.
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `filename` | [string](../core/string); required  If no 'sibling' provided, path of the new directory, relative to the current package. Otherwise a base name for a file ('sibling' defines a directory). |
-| `sibling` | [File](../builtins/File); or `None`; default is `None`  A file that lives in the same directory as the newly declared directory. The file must be in the current package. |
+| `filename` | [string](/versions/8.2.1/rules/lib/core/string); required  If no 'sibling' provided, path of the new directory, relative to the current package. Otherwise a base name for a file ('sibling' defines a directory). |
+| `sibling` | [File](/versions/8.2.1/rules/lib/builtins/File); or `None`; default is `None`  A file that lives in the same directory as the newly declared directory. The file must be in the current package. |
 
 ## declare\_file
 
@@ -51,14 +51,14 @@ Declares that the rule or aspect creates a file with the given filename. If `sib
 
 Remember that in addition to declaring a file, you must separately create an action that emits the file. Creating that action will require passing the returned `File` object to the action's construction function.
 
-Note that [predeclared output files](https://bazel.build/versions/8.2.1/extending/rules#files) do not need to be (and cannot be) declared using this function. You can obtain their `File` objects from [`ctx.outputs`](../builtins/ctx#outputs) instead. [See example of use](https://github.com/bazelbuild/examples/tree/main/rules/computed_dependencies/hash.bzl).
+Note that [predeclared output files](https://bazel.build/versions/8.2.1/extending/rules#files) do not need to be (and cannot be) declared using this function. You can obtain their `File` objects from [`ctx.outputs`](/versions/8.2.1/rules/lib/builtins/ctx#outputs) instead. [See example of use](https://github.com/bazelbuild/examples/tree/main/rules/computed_dependencies/hash.bzl).
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `filename` | [string](../core/string); required  If no 'sibling' provided, path of the new file, relative to the current package. Otherwise a base name for a file ('sibling' determines a directory). |
-| `sibling` | [File](../builtins/File); or `None`; default is `None`  A file that lives in the same directory as the newly created file. The file must be in the current package. |
+| `filename` | [string](/versions/8.2.1/rules/lib/core/string); required  If no 'sibling' provided, path of the new file, relative to the current package. Otherwise a base name for a file ('sibling' determines a directory). |
+| `sibling` | [File](/versions/8.2.1/rules/lib/builtins/File); or `None`; default is `None`  A file that lives in the same directory as the newly created file. The file must be in the current package. |
 
 ## declare\_symlink
 
@@ -72,8 +72,8 @@ Declares that the rule or aspect creates a symlink with the given name in the cu
 
 | Parameter | Description |
 | --- | --- |
-| `filename` | [string](../core/string); required  If no 'sibling' provided, path of the new symlink, relative to the current package. Otherwise a base name for a file ('sibling' defines a directory). |
-| `sibling` | [File](../builtins/File); or `None`; default is `None`  A file that lives in the same directory as the newly declared symlink. |
+| `filename` | [string](/versions/8.2.1/rules/lib/core/string); required  If no 'sibling' provided, path of the new symlink, relative to the current package. Otherwise a base name for a file ('sibling' defines a directory). |
+| `sibling` | [File](/versions/8.2.1/rules/lib/builtins/File); or `None`; default is `None`  A file that lives in the same directory as the newly declared symlink. |
 
 ## do\_nothing
 
@@ -87,8 +87,8 @@ Creates an empty action that neither executes a command nor produces any output,
 
 | Parameter | Description |
 | --- | --- |
-| `mnemonic` | [string](../core/string); required  A one-word description of the action, for example, CppCompile or GoLink. |
-| `inputs` | [sequence](../core/list) of [File](../builtins/File)s; or [depset](../builtins/depset); default is `[]`  List of the input files of the action. |
+| `mnemonic` | [string](/versions/8.2.1/rules/lib/core/string); required  A one-word description of the action, for example, CppCompile or GoLink. |
+| `inputs` | [sequence](/versions/8.2.1/rules/lib/core/list) of [File](/versions/8.2.1/rules/lib/builtins/File)s; or [depset](/versions/8.2.1/rules/lib/builtins/depset); default is `[]`  List of the input files of the action. |
 
 ## expand\_template
 
@@ -102,11 +102,11 @@ Creates a template expansion action. When the action is executed, it will genera
 
 | Parameter | Description |
 | --- | --- |
-| `template` | [File](../builtins/File); required  The template file, which is a UTF-8 encoded text file. |
-| `output` | [File](../builtins/File); required  The output file, which is a UTF-8 encoded text file. |
-| `substitutions` | [dict](../core/dict); default is `{}`  Substitutions to make when expanding the template. |
-| `is_executable` | [bool](../core/bool); default is `False`  Whether the output file should be executable. |
-| `computed_substitutions` | [TemplateDict](../builtins/TemplateDict); default is `unbound`  Substitutions to make when expanding the template. |
+| `template` | [File](/versions/8.2.1/rules/lib/builtins/File); required  The template file, which is a UTF-8 encoded text file. |
+| `output` | [File](/versions/8.2.1/rules/lib/builtins/File); required  The output file, which is a UTF-8 encoded text file. |
+| `substitutions` | [dict](/versions/8.2.1/rules/lib/core/dict); default is `{}`  Substitutions to make when expanding the template. |
+| `is_executable` | [bool](/versions/8.2.1/rules/lib/core/bool); default is `False`  Whether the output file should be executable. |
+| `computed_substitutions` | [TemplateDict](/versions/8.2.1/rules/lib/builtins/TemplateDict); default is `unbound`  Substitutions to make when expanding the template. |
 
 ## run
 
@@ -120,22 +120,22 @@ Creates an action that runs an executable. [See example of use](https://github.c
 
 | Parameter | Description |
 | --- | --- |
-| `outputs` | [sequence](../core/list) of [File](../builtins/File)s; required  List of the output files of the action. |
-| `inputs` | [sequence](../core/list) of [File](../builtins/File)s; or [depset](../builtins/depset); default is `[]`  List or depset of the input files of the action. |
-| `unused_inputs_list` | [File](../builtins/File); or `None`; default is `None`  File containing list of inputs unused by the action. The content of this file (generally one of the outputs of the action) corresponds to the list of input files that were not used during the whole action execution. Any change in those files must not affect in any way the outputs of the action. |
-| `executable` | [File](../builtins/File); or [string](../core/string); or [FilesToRunProvider](../providers/FilesToRunProvider); required  The executable file to be called by the action. |
-| `tools` | [sequence](../core/list); or [depset](../builtins/depset); default is `unbound`  List or depset of any tools needed by the action. Tools are inputs with additional runfiles that are automatically made available to the action. When a list is provided, it can be a heterogenous collection of Files, FilesToRunProvider instances, or depsets of Files. Files which are directly in the list and come from ctx.executable will have their runfiles automatically added. When a depset is provided, it must contain only Files. In both cases, files within depsets are not cross-referenced with ctx.executable for runfiles. |
-| `arguments` | [sequence](../core/list); default is `[]`  Command line arguments of the action. Must be a list of strings or [`actions.args()`](#args) objects. |
-| `mnemonic` | [string](../core/string); or `None`; default is `None`  A one-word description of the action, for example, CppCompile or GoLink. |
-| `progress_message` | [string](../core/string); or `None`; default is `None`  Progress message to show to the user during the build, for example, "Compiling foo.cc to create foo.o". The message may contain `%{label}`, `%{input}`, or `%{output}` patterns, which are substituted with label string, first input, or output's path, respectively. Prefer to use patterns instead of static strings, because the former are more efficient. |
-| `use_default_shell_env` | [bool](../core/bool); default is `False`  Whether the action should use the default shell environment, which consists of a few OS-dependent variables as well as variables set via [`--action_env`](/versions/8.2.1/reference/command-line-reference#flag--action_env). If both `use_default_shell_env` and `env` are set to `True`, values set in `env` will overwrite the default shell environment if [`--incompatible_merge_fixed_and_default_shell_env`](/versions/8.2.1/reference/command-line-reference#flag--incompatible_merge_fixed_and_default_shell_env) is enabled (default). If the flag is not enabled, `env` is ignored. |
-| `env` | [dict](../core/dict); or `None`; default is `None`  Sets the dictionary of environment variables. If both `use_default_shell_env` and `env` are set to `True`, values set in `env` will overwrite the default shell environment if [`--incompatible_merge_fixed_and_default_shell_env`](/versions/8.2.1/reference/command-line-reference#flag--incompatible_merge_fixed_and_default_shell_env) is enabled (default). If the flag is not enabled, `env` is ignored. |
-| `execution_requirements` | [dict](../core/dict); or `None`; default is `None`  Information for scheduling the action. See [tags](/versions/8.2.1/reference/be/common-definitions#common.tags) for useful keys. |
-| `input_manifests` | [sequence](../core/list); or `None`; default is `None`  Legacy argument. Ignored. |
-| `exec_group` | [string](../core/string); or `None`; default is `None`  Runs the action on the given exec group's execution platform. If none, uses the target's default execution platform. |
-| `shadowed_action` | [Action](../builtins/Action); default is `None`  Runs the action using the given shadowed action's inputs and environment added to the action's inputs list and environment. The action environment can overwrite any of the shadowed action's environment variables. If none, uses only the action's inputs and given environment. |
+| `outputs` | [sequence](/versions/8.2.1/rules/lib/core/list) of [File](/versions/8.2.1/rules/lib/builtins/File)s; required  List of the output files of the action. |
+| `inputs` | [sequence](/versions/8.2.1/rules/lib/core/list) of [File](/versions/8.2.1/rules/lib/builtins/File)s; or [depset](/versions/8.2.1/rules/lib/builtins/depset); default is `[]`  List or depset of the input files of the action. |
+| `unused_inputs_list` | [File](/versions/8.2.1/rules/lib/builtins/File); or `None`; default is `None`  File containing list of inputs unused by the action. The content of this file (generally one of the outputs of the action) corresponds to the list of input files that were not used during the whole action execution. Any change in those files must not affect in any way the outputs of the action. |
+| `executable` | [File](/versions/8.2.1/rules/lib/builtins/File); or [string](/versions/8.2.1/rules/lib/core/string); or [FilesToRunProvider](/versions/8.2.1/rules/lib/providers/FilesToRunProvider); required  The executable file to be called by the action. |
+| `tools` | [sequence](/versions/8.2.1/rules/lib/core/list); or [depset](/versions/8.2.1/rules/lib/builtins/depset); default is `unbound`  List or depset of any tools needed by the action. Tools are inputs with additional runfiles that are automatically made available to the action. When a list is provided, it can be a heterogenous collection of Files, FilesToRunProvider instances, or depsets of Files. Files which are directly in the list and come from ctx.executable will have their runfiles automatically added. When a depset is provided, it must contain only Files. In both cases, files within depsets are not cross-referenced with ctx.executable for runfiles. |
+| `arguments` | [sequence](/versions/8.2.1/rules/lib/core/list); default is `[]`  Command line arguments of the action. Must be a list of strings or [`actions.args()`](#args) objects. |
+| `mnemonic` | [string](/versions/8.2.1/rules/lib/core/string); or `None`; default is `None`  A one-word description of the action, for example, CppCompile or GoLink. |
+| `progress_message` | [string](/versions/8.2.1/rules/lib/core/string); or `None`; default is `None`  Progress message to show to the user during the build, for example, "Compiling foo.cc to create foo.o". The message may contain `%{label}`, `%{input}`, or `%{output}` patterns, which are substituted with label string, first input, or output's path, respectively. Prefer to use patterns instead of static strings, because the former are more efficient. |
+| `use_default_shell_env` | [bool](/versions/8.2.1/rules/lib/core/bool); default is `False`  Whether the action should use the default shell environment, which consists of a few OS-dependent variables as well as variables set via [`--action_env`](/versions/8.2.1/reference/command-line-reference#flag--action_env). If both `use_default_shell_env` and `env` are set to `True`, values set in `env` will overwrite the default shell environment if [`--incompatible_merge_fixed_and_default_shell_env`](/versions/8.2.1/reference/command-line-reference#flag--incompatible_merge_fixed_and_default_shell_env) is enabled (default). If the flag is not enabled, `env` is ignored. |
+| `env` | [dict](/versions/8.2.1/rules/lib/core/dict); or `None`; default is `None`  Sets the dictionary of environment variables. If both `use_default_shell_env` and `env` are set to `True`, values set in `env` will overwrite the default shell environment if [`--incompatible_merge_fixed_and_default_shell_env`](/versions/8.2.1/reference/command-line-reference#flag--incompatible_merge_fixed_and_default_shell_env) is enabled (default). If the flag is not enabled, `env` is ignored. |
+| `execution_requirements` | [dict](/versions/8.2.1/rules/lib/core/dict); or `None`; default is `None`  Information for scheduling the action. See [tags](/versions/8.2.1/reference/be/common-definitions#common.tags) for useful keys. |
+| `input_manifests` | [sequence](/versions/8.2.1/rules/lib/core/list); or `None`; default is `None`  Legacy argument. Ignored. |
+| `exec_group` | [string](/versions/8.2.1/rules/lib/core/string); or `None`; default is `None`  Runs the action on the given exec group's execution platform. If none, uses the target's default execution platform. |
+| `shadowed_action` | [Action](/versions/8.2.1/rules/lib/builtins/Action); default is `None`  Runs the action using the given shadowed action's inputs and environment added to the action's inputs list and environment. The action environment can overwrite any of the shadowed action's environment variables. If none, uses only the action's inputs and given environment. |
 | `resource_set` | callable; or `None`; default is `None`  A callback function that returns a resource set dictionary, used to estimate resource usage at execution time if this action is run locally. The function accepts two positional arguments: a string representing an OS name (e.g. "osx"), and an integer representing the number of inputs to the action. The returned dictionary may contain the following entries, each of which may be a float or an int:  * "cpu": number of CPUs; default 1* "memory": in MB; default 250* "local\_test": number of local tests; default 1   If this parameter is set to `None` , the default values are used. The callback must be top-level (lambda and nested functions aren't allowed). |
-| `toolchain` | [Label](../builtins/Label); or [string](../core/string); or `None`; default is `unbound`  Toolchain type of the executable or tools used in this action.  If executable and tools are not coming from a toolchain, set this parameter to `None`.  If executable and tools are coming from a toolchain, toolchain type must be set so that the action executes on the correct execution platform.  Note that the rule which creates this action needs to define this toolchain inside its 'rule()' function.  When `toolchain` and `exec\_group` parameters are both set, `exec\_group` will be used. An error is raised in case the `exec\_group` doesn't specify the same toolchain. |
+| `toolchain` | [Label](/versions/8.2.1/rules/lib/builtins/Label); or [string](/versions/8.2.1/rules/lib/core/string); or `None`; default is `unbound`  Toolchain type of the executable or tools used in this action.  If executable and tools are not coming from a toolchain, set this parameter to `None`.  If executable and tools are coming from a toolchain, toolchain type must be set so that the action executes on the correct execution platform.  Note that the rule which creates this action needs to define this toolchain inside its 'rule()' function.  When `toolchain` and `exec\_group` parameters are both set, `exec\_group` will be used. An error is raised in case the `exec\_group` doesn't specify the same toolchain. |
 
 ## run\_shell
 
@@ -149,21 +149,21 @@ Creates an action that runs a shell command. [See example of use](https://github
 
 | Parameter | Description |
 | --- | --- |
-| `outputs` | [sequence](../core/list) of [File](../builtins/File)s; required  List of the output files of the action. |
-| `inputs` | [sequence](../core/list) of [File](../builtins/File)s; or [depset](../builtins/depset); default is `[]`  List or depset of the input files of the action. |
-| `tools` | [sequence](../core/list) of [File](../builtins/File)s; or [depset](../builtins/depset); default is `unbound`  List or depset of any tools needed by the action. Tools are inputs with additional runfiles that are automatically made available to the action. The list can contain Files or FilesToRunProvider instances. |
-| `arguments` | [sequence](../core/list); default is `[]`  Command line arguments of the action. Must be a list of strings or [`actions.args()`](#args) objects. Bazel passes the elements in this attribute as arguments to the command.The command can access these arguments using shell variable substitutions such as `$1`, `$2`, etc. Note that since Args objects are flattened before indexing, if there is an Args object of unknown size then all subsequent strings will be at unpredictable indices. It may be useful to use `$@` (to retrieve all arguments) in conjunction with Args objects of indeterminate size. In the case where `command` is a list of strings, this parameter may not be used. |
-| `mnemonic` | [string](../core/string); or `None`; default is `None`  A one-word description of the action, for example, CppCompile or GoLink. |
-| `command` | [string](../core/string); or [sequence](../core/list) of [string](../core/string)s; required  Shell command to execute. This may either be a string (preferred) or a sequence of strings **(deprecated)**. If `command` is a string, then it is executed as if by `sh -c  "" ` -- that is, the elements in `arguments` are made available to the command as `$1`, `$2` (or `%1`, `%2` if using Windows batch), etc. If `arguments` contains any [`actions.args()`](#args) objects, their contents are appended one by one to the command line, so `$`*i* can refer to individual strings within an Args object. Note that if an Args object of unknown size is passed as part of `arguments`, then the strings will be at unknown indices; in this case the `$@` shell substitution (retrieve all arguments) may be useful. **(Deprecated)** If `command` is a sequence of strings, the first item is the executable to run and the remaining items are its arguments. If this form is used, the `arguments` parameter must not be supplied. *Note that this form is deprecated and will soon be removed. It is disabled with `--incompatible\_run\_shell\_command\_string`. Use this flag to verify your code is compatible.*  Bazel uses the same shell to execute the command as it does for genrules. |
-| `progress_message` | [string](../core/string); or `None`; default is `None`  Progress message to show to the user during the build, for example, "Compiling foo.cc to create foo.o". The message may contain `%{label}`, `%{input}`, or `%{output}` patterns, which are substituted with label string, first input, or output's path, respectively. Prefer to use patterns instead of static strings, because the former are more efficient. |
-| `use_default_shell_env` | [bool](../core/bool); default is `False`  Whether the action should use the default shell environment, which consists of a few OS-dependent variables as well as variables set via [`--action_env`](/versions/8.2.1/reference/command-line-reference#flag--action_env). If both `use_default_shell_env` and `env` are set to `True`, values set in `env` will overwrite the default shell environment if [`--incompatible_merge_fixed_and_default_shell_env`](/versions/8.2.1/reference/command-line-reference#flag--incompatible_merge_fixed_and_default_shell_env) is enabled (default). If the flag is not enabled, `env` is ignored. |
-| `env` | [dict](../core/dict); or `None`; default is `None`  Sets the dictionary of environment variables. If both `use_default_shell_env` and `env` are set to `True`, values set in `env` will overwrite the default shell environment if [`--incompatible_merge_fixed_and_default_shell_env`](/versions/8.2.1/reference/command-line-reference#flag--incompatible_merge_fixed_and_default_shell_env) is enabled (default). If the flag is not enabled, `env` is ignored. |
-| `execution_requirements` | [dict](../core/dict); or `None`; default is `None`  Information for scheduling the action. See [tags](/versions/8.2.1/reference/be/common-definitions#common.tags) for useful keys. |
-| `input_manifests` | [sequence](../core/list); or `None`; default is `None`  Legacy argument. Ignored. |
-| `exec_group` | [string](../core/string); or `None`; default is `None`  Runs the action on the given exec group's execution platform. If none, uses the target's default execution platform. |
-| `shadowed_action` | [Action](../builtins/Action); default is `None`  Runs the action using the given shadowed action's discovered inputs added to the action's inputs list. If none, uses only the action's inputs. |
+| `outputs` | [sequence](/versions/8.2.1/rules/lib/core/list) of [File](/versions/8.2.1/rules/lib/builtins/File)s; required  List of the output files of the action. |
+| `inputs` | [sequence](/versions/8.2.1/rules/lib/core/list) of [File](/versions/8.2.1/rules/lib/builtins/File)s; or [depset](/versions/8.2.1/rules/lib/builtins/depset); default is `[]`  List or depset of the input files of the action. |
+| `tools` | [sequence](/versions/8.2.1/rules/lib/core/list) of [File](/versions/8.2.1/rules/lib/builtins/File)s; or [depset](/versions/8.2.1/rules/lib/builtins/depset); default is `unbound`  List or depset of any tools needed by the action. Tools are inputs with additional runfiles that are automatically made available to the action. The list can contain Files or FilesToRunProvider instances. |
+| `arguments` | [sequence](/versions/8.2.1/rules/lib/core/list); default is `[]`  Command line arguments of the action. Must be a list of strings or [`actions.args()`](#args) objects. Bazel passes the elements in this attribute as arguments to the command.The command can access these arguments using shell variable substitutions such as `$1`, `$2`, etc. Note that since Args objects are flattened before indexing, if there is an Args object of unknown size then all subsequent strings will be at unpredictable indices. It may be useful to use `$@` (to retrieve all arguments) in conjunction with Args objects of indeterminate size. In the case where `command` is a list of strings, this parameter may not be used. |
+| `mnemonic` | [string](/versions/8.2.1/rules/lib/core/string); or `None`; default is `None`  A one-word description of the action, for example, CppCompile or GoLink. |
+| `command` | [string](/versions/8.2.1/rules/lib/core/string); or [sequence](/versions/8.2.1/rules/lib/core/list) of [string](/versions/8.2.1/rules/lib/core/string)s; required  Shell command to execute. This may either be a string (preferred) or a sequence of strings **(deprecated)**. If `command` is a string, then it is executed as if by `sh -c  "" ` -- that is, the elements in `arguments` are made available to the command as `$1`, `$2` (or `%1`, `%2` if using Windows batch), etc. If `arguments` contains any [`actions.args()`](#args) objects, their contents are appended one by one to the command line, so `$`*i* can refer to individual strings within an Args object. Note that if an Args object of unknown size is passed as part of `arguments`, then the strings will be at unknown indices; in this case the `$@` shell substitution (retrieve all arguments) may be useful. **(Deprecated)** If `command` is a sequence of strings, the first item is the executable to run and the remaining items are its arguments. If this form is used, the `arguments` parameter must not be supplied. *Note that this form is deprecated and will soon be removed. It is disabled with `--incompatible\_run\_shell\_command\_string`. Use this flag to verify your code is compatible.*  Bazel uses the same shell to execute the command as it does for genrules. |
+| `progress_message` | [string](/versions/8.2.1/rules/lib/core/string); or `None`; default is `None`  Progress message to show to the user during the build, for example, "Compiling foo.cc to create foo.o". The message may contain `%{label}`, `%{input}`, or `%{output}` patterns, which are substituted with label string, first input, or output's path, respectively. Prefer to use patterns instead of static strings, because the former are more efficient. |
+| `use_default_shell_env` | [bool](/versions/8.2.1/rules/lib/core/bool); default is `False`  Whether the action should use the default shell environment, which consists of a few OS-dependent variables as well as variables set via [`--action_env`](/versions/8.2.1/reference/command-line-reference#flag--action_env). If both `use_default_shell_env` and `env` are set to `True`, values set in `env` will overwrite the default shell environment if [`--incompatible_merge_fixed_and_default_shell_env`](/versions/8.2.1/reference/command-line-reference#flag--incompatible_merge_fixed_and_default_shell_env) is enabled (default). If the flag is not enabled, `env` is ignored. |
+| `env` | [dict](/versions/8.2.1/rules/lib/core/dict); or `None`; default is `None`  Sets the dictionary of environment variables. If both `use_default_shell_env` and `env` are set to `True`, values set in `env` will overwrite the default shell environment if [`--incompatible_merge_fixed_and_default_shell_env`](/versions/8.2.1/reference/command-line-reference#flag--incompatible_merge_fixed_and_default_shell_env) is enabled (default). If the flag is not enabled, `env` is ignored. |
+| `execution_requirements` | [dict](/versions/8.2.1/rules/lib/core/dict); or `None`; default is `None`  Information for scheduling the action. See [tags](/versions/8.2.1/reference/be/common-definitions#common.tags) for useful keys. |
+| `input_manifests` | [sequence](/versions/8.2.1/rules/lib/core/list); or `None`; default is `None`  Legacy argument. Ignored. |
+| `exec_group` | [string](/versions/8.2.1/rules/lib/core/string); or `None`; default is `None`  Runs the action on the given exec group's execution platform. If none, uses the target's default execution platform. |
+| `shadowed_action` | [Action](/versions/8.2.1/rules/lib/builtins/Action); default is `None`  Runs the action using the given shadowed action's discovered inputs added to the action's inputs list. If none, uses only the action's inputs. |
 | `resource_set` | callable; or `None`; default is `None`  A callback function for estimating resource usage if run locally. See[`ctx.actions.run()`](#run.resource_set). |
-| `toolchain` | [Label](../builtins/Label); or [string](../core/string); or `None`; default is `unbound`  Toolchain type of the executable or tools used in this action.  If executable and tools are not coming from a toolchain, set this parameter to `None`.  If executable and tools are coming from a toolchain, toolchain type must be set so that the action executes on the correct execution platform.  Note that the rule which creates this action needs to define this toolchain inside its 'rule()' function.  When `toolchain` and `exec\_group` parameters are both set, `exec\_group` will be used. An error is raised in case the `exec\_group` doesn't specify the same toolchain. |
+| `toolchain` | [Label](/versions/8.2.1/rules/lib/builtins/Label); or [string](/versions/8.2.1/rules/lib/core/string); or `None`; default is `unbound`  Toolchain type of the executable or tools used in this action.  If executable and tools are not coming from a toolchain, set this parameter to `None`.  If executable and tools are coming from a toolchain, toolchain type must be set so that the action executes on the correct execution platform.  Note that the rule which creates this action needs to define this toolchain inside its 'rule()' function.  When `toolchain` and `exec\_group` parameters are both set, `exec\_group` will be used. An error is raised in case the `exec\_group` doesn't specify the same toolchain. |
 
 ## symlink
 
@@ -183,11 +183,11 @@ Otherwise, when you use `target_path`, declare `output` with [`declare_symlink()
 
 | Parameter | Description |
 | --- | --- |
-| `output` | [File](../builtins/File); required  The output of this action. |
-| `target_file` | [File](../builtins/File); or `None`; default is `None`  The File that the output symlink will point to. |
-| `target_path` | [string](../core/string); or `None`; default is `None`  The exact path that the output symlink will point to. No normalization or other processing is applied. |
-| `is_executable` | [bool](../core/bool); default is `False`  May only be used with `target_file`, not `target_path`. If true, when the action is executed, the `target_file`'s path is checked to confirm that it is executable, and an error is reported if it is not. Setting `is_executable` to False does not mean the target is not executable, just that no verification is done. This feature does not make sense for `target_path` because dangling symlinks might not exist at build time. |
-| `progress_message` | [string](../core/string); or `None`; default is `None`  Progress message to show to the user during the build. |
+| `output` | [File](/versions/8.2.1/rules/lib/builtins/File); required  The output of this action. |
+| `target_file` | [File](/versions/8.2.1/rules/lib/builtins/File); or `None`; default is `None`  The File that the output symlink will point to. |
+| `target_path` | [string](/versions/8.2.1/rules/lib/core/string); or `None`; default is `None`  The exact path that the output symlink will point to. No normalization or other processing is applied. |
+| `is_executable` | [bool](/versions/8.2.1/rules/lib/core/bool); default is `False`  May only be used with `target_file`, not `target_path`. If true, when the action is executed, the `target_file`'s path is checked to confirm that it is executable, and an error is reported if it is not. Setting `is_executable` to False does not mean the target is not executable, just that no verification is done. This feature does not make sense for `target_path` because dangling symlinks might not exist at build time. |
+| `progress_message` | [string](/versions/8.2.1/rules/lib/core/string); or `None`; default is `None`  Progress message to show to the user during the build. |
 
 ## template\_dict
 
@@ -209,6 +209,6 @@ Creates a file write action. When the action is executed, it will write the give
 
 | Parameter | Description |
 | --- | --- |
-| `output` | [File](../builtins/File); required  The output file. |
-| `content` | [string](../core/string); or [Args](../builtins/Args); required  the contents of the file. May be a either a string or an [`actions.args()`](#args) object. |
-| `is_executable` | [bool](../core/bool); default is `False`  Whether the output file should be executable. |
\ No newline at end of file
+| `output` | [File](/versions/8.2.1/rules/lib/builtins/File); required  The output file. |
+| `content` | [string](/versions/8.2.1/rules/lib/core/string); or [Args](/versions/8.2.1/rules/lib/builtins/Args); required  the contents of the file. May be a either a string or an [`actions.args()`](#args) object. |
+| `is_executable` | [bool](/versions/8.2.1/rules/lib/core/bool); default is `False`  Whether the output file should be executable. |
\ No newline at end of file
diff --git a/versions/8.2.1/rules/lib/builtins/apple_platform.mdx b/versions/8.2.1/rules/lib/builtins/apple_platform.mdx
index ba2fc42e..963997c3 100644
--- a/versions/8.2.1/rules/lib/builtins/apple_platform.mdx
+++ b/versions/8.2.1/rules/lib/builtins/apple_platform.mdx
@@ -4,7 +4,7 @@ title: 'apple\_platform'
 
 Corresponds to Xcode's notion of a platform as would be found in `Xcode.app/Contents/Developer/Platforms`. Each platform represents an Apple platform type (such as iOS or tvOS) combined with one or more related CPU architectures. For example, the iOS simulator platform supports `x86_64` and `i386` architectures.
 
-Specific instances of this type can be retrieved from the fields of the [apple\_common.platform](../toplevel/apple_common#platform) struct:
+Specific instances of this type can be retrieved from the fields of the [apple\_common.platform](/versions/8.2.1/rules/lib/toplevel/apple_common#platform) struct:
 
 * `apple_common.platform.ios_device`
 * `apple_common.platform.ios_simulator`
@@ -14,7 +14,7 @@ Specific instances of this type can be retrieved from the fields of the [apple\_
 * `apple_common.platform.watchos_device`
 * `apple_common.platform.watchos_simulator`
 
-More commonly, however, the [apple](../fragments/apple) configuration fragment has fields/methods that allow rules to determine the platform for which a target is being built.
+More commonly, however, the [apple](/versions/8.2.1/rules/lib/fragments/apple) configuration fragment has fields/methods that allow rules to determine the platform for which a target is being built.
 
 Example:
 
diff --git a/versions/8.2.1/rules/lib/builtins/configuration.mdx b/versions/8.2.1/rules/lib/builtins/configuration.mdx
index d9e653a8..be556cb0 100644
--- a/versions/8.2.1/rules/lib/builtins/configuration.mdx
+++ b/versions/8.2.1/rules/lib/builtins/configuration.mdx
@@ -17,7 +17,7 @@ This object holds information about the environment in which the build is runnin
 bool configuration.coverage_enabled
 ```
 
-A boolean that tells whether code coverage is enabled for this run. Note that this does not compute whether a specific rule should be instrumented for code coverage data collection. For that, see the [`ctx.coverage_instrumented`](../builtins/ctx#coverage_instrumented) function.
+A boolean that tells whether code coverage is enabled for this run. Note that this does not compute whether a specific rule should be instrumented for code coverage data collection. For that, see the [`ctx.coverage_instrumented`](/versions/8.2.1/rules/lib/builtins/ctx#coverage_instrumented) function.
 
 ## default\_shell\_env
 
diff --git a/versions/8.2.1/rules/lib/builtins/ctx.mdx b/versions/8.2.1/rules/lib/builtins/ctx.mdx
index 238f8154..ab7a94c1 100644
--- a/versions/8.2.1/rules/lib/builtins/ctx.mdx
+++ b/versions/8.2.1/rules/lib/builtins/ctx.mdx
@@ -66,7 +66,7 @@ A list of ids for all aspects applied to the target. Only available in aspect im
 struct ctx.attr
 ```
 
-A struct to access the values of the [attributes](https://bazel.build/versions/8.2.1/extending/rules#attributes). The values are provided by the user (if not, a default value is used). The attributes of the struct and the types of their values correspond to the keys and values of the [`attrs` dict](../globals/bzl#rule.attrs) provided to the [`rule` function](../globals/bzl#rule). [See example of use](https://github.com/bazelbuild/examples/blob/main/rules/attributes/printer.bzl).
+A struct to access the values of the [attributes](https://bazel.build/versions/8.2.1/extending/rules#attributes). The values are provided by the user (if not, a default value is used). The attributes of the struct and the types of their values correspond to the keys and values of the [`attrs` dict](/versions/8.2.1/rules/lib/globals/bzl#rule.attrs) provided to the [`rule` function](/versions/8.2.1/rules/lib/globals/bzl#rule). [See example of use](https://github.com/bazelbuild/examples/blob/main/rules/attributes/printer.bzl).
 
 ## bin\_dir
 
@@ -98,7 +98,7 @@ Value of the build setting represented by the current target. If this isn't the
 configuration ctx.configuration
 ```
 
-The default configuration. See the [configuration](../builtins/configuration) type for more details.
+The default configuration. See the [configuration](/versions/8.2.1/rules/lib/builtins/configuration) type for more details.
 
 ## coverage\_instrumented
 
@@ -106,13 +106,13 @@ The default configuration. See the [configuration](../builtins/configuration) ty
 bool ctx.coverage_instrumented(target=None)
 ```
 
-Returns whether code coverage instrumentation should be generated when performing compilation actions for this rule or, if `target` is provided, the rule specified by that Target. (If a non-rule or a Starlark rule Target is provided, this returns False.) Checks if the sources of the current rule (if no Target is provided) or the sources of Target should be instrumented based on the --instrumentation\_filter and --instrument\_test\_targets config settings. This differs from `coverage_enabled` in the [configuration](../builtins/configuration), which notes whether coverage data collection is enabled for the entire run, but not whether a specific target should be instrumented.
+Returns whether code coverage instrumentation should be generated when performing compilation actions for this rule or, if `target` is provided, the rule specified by that Target. (If a non-rule or a Starlark rule Target is provided, this returns False.) Checks if the sources of the current rule (if no Target is provided) or the sources of Target should be instrumented based on the --instrumentation\_filter and --instrument\_test\_targets config settings. This differs from `coverage_enabled` in the [configuration](/versions/8.2.1/rules/lib/builtins/configuration), which notes whether coverage data collection is enabled for the entire run, but not whether a specific target should be instrumented.
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `target` | [Target](../builtins/Target); or `None`; default is `None`  A Target specifying a rule. If not provided, defaults to the current rule. |
+| `target` | [Target](/versions/8.2.1/rules/lib/builtins/Target); or `None`; default is `None`  A Target specifying a rule. If not provided, defaults to the current rule. |
 
 ## created\_actions
 
@@ -120,7 +120,7 @@ Returns whether code coverage instrumentation should be generated when performin
 StarlarkValue ctx.created_actions()
 ```
 
-For rules with [\_skylark\_testable](../globals/bzl#rule._skylark_testable) set to `True`, this returns an `Actions` provider representing all actions created so far for the current rule. For all other rules, returns `None`. Note that the provider is not updated when subsequent actions are created, so you will have to call this function again if you wish to inspect them.
+For rules with [\_skylark\_testable](/versions/8.2.1/rules/lib/globals/bzl#rule._skylark_testable) set to `True`, this returns an `Actions` provider representing all actions created so far for the current rule. For all other rules, returns `None`. Note that the provider is not updated when subsequent actions are created, so you will have to call this function again if you wish to inspect them.
 
 This is intended to help write tests for rule-implementation helper functions, which may take in a `ctx` object and create actions on it.
 
@@ -146,7 +146,7 @@ A collection of the execution groups available for this rule, indexed by their n
 struct ctx.executable
 ```
 
-A `struct` containing executable files defined in [label type attributes](../toplevel/attr#label) marked as [`executable=True`](../toplevel/attr#label.executable). The struct fields correspond to the attribute names. Each value in the struct is either a [`File`](../builtins/File) or `None`. If an optional attribute is not specified in the rule then the corresponding struct value is `None`. If a label type is not marked as `executable=True`, no corresponding struct field is generated. [See example of use](https://github.com/bazelbuild/examples/blob/main/rules/actions_run/execute.bzl).
+A `struct` containing executable files defined in [label type attributes](/versions/8.2.1/rules/lib/toplevel/attr#label) marked as [`executable=True`](/versions/8.2.1/rules/lib/toplevel/attr#label.executable). The struct fields correspond to the attribute names. Each value in the struct is either a [`File`](/versions/8.2.1/rules/lib/builtins/File) or `None`. If an optional attribute is not specified in the rule then the corresponding struct value is `None`. If a label type is not marked as `executable=True`, no corresponding struct field is generated. [See example of use](https://github.com/bazelbuild/examples/blob/main/rules/actions_run/execute.bzl).
 
 ## expand\_location
 
@@ -164,8 +164,8 @@ This function is useful to let the user specify a command in a BUILD file (like
 
 | Parameter | Description |
 | --- | --- |
-| `input` | [string](../core/string); required  String to be expanded. |
-| `targets` | [sequence](../core/list) of [Target](../builtins/Target)s; default is `[]`  List of targets for additional lookup information. These are expanded as follows: A target with a single file in `DefaultInfo.files` expands to that file. Other targets expand to their `DefaultInfo.executable` file if set and if `--incompatible_locations_prefers_executable` is enabled, otherwise they expand to `DefaultInfo.files`. |
+| `input` | [string](/versions/8.2.1/rules/lib/core/string); required  String to be expanded. |
+| `targets` | [sequence](/versions/8.2.1/rules/lib/core/list) of [Target](/versions/8.2.1/rules/lib/builtins/Target)s; default is `[]`  List of targets for additional lookup information. These are expanded as follows: A target with a single file in `DefaultInfo.files` expands to that file. Other targets expand to their `DefaultInfo.executable` file if set and if `--incompatible_locations_prefers_executable` is enabled, otherwise they expand to `DefaultInfo.files`. |
 
 May return `None`.
 
@@ -175,7 +175,7 @@ May return `None`.
 string ctx.expand_make_variables(attribute_name, command, additional_substitutions)
 ```
 
-**Deprecated.** Use [ctx.var](../builtins/ctx#var) to access the variables instead.
+**Deprecated.** Use [ctx.var](/versions/8.2.1/rules/lib/builtins/ctx#var) to access the variables instead.
 Returns a string after expanding all references to "Make variables". The variables must have the following format: `$(VAR_NAME)`. Also, `$$VAR_NAME` expands to `$VAR_NAME`. Examples:
 
 ```
@@ -189,9 +189,9 @@ Additional variables may come from other places, such as configurations. Note th
 
 | Parameter | Description |
 | --- | --- |
-| `attribute_name` | [string](../core/string); required |
-| `command` | [string](../core/string); required  The expression to expand. It can contain references to "Make variables". |
-| `additional_substitutions` | [dict](../core/dict); required  Additional substitutions to make beyond the default make variables. |
+| `attribute_name` | [string](/versions/8.2.1/rules/lib/core/string); required |
+| `command` | [string](/versions/8.2.1/rules/lib/core/string); required  The expression to expand. It can contain references to "Make variables". |
+| `additional_substitutions` | [dict](/versions/8.2.1/rules/lib/core/dict); required  Additional substitutions to make beyond the default make variables. |
 
 ## features
 
@@ -207,7 +207,7 @@ The set of features that are explicitly enabled by the user for this rule. [See
 struct ctx.file
 ```
 
-A `struct` containing files defined in [label type attributes](../toplevel/attr#label) marked as [`allow_single_file`](../toplevel/attr#label.allow_single_file). The struct fields correspond to the attribute names. The struct value is always a [`File`](../builtins/File) or `None`. If an optional attribute is not specified in the rule then the corresponding struct value is `None`. If a label type is not marked as `allow_single_file`, no corresponding struct field is generated. It is a shortcut for:
+A `struct` containing files defined in [label type attributes](/versions/8.2.1/rules/lib/toplevel/attr#label) marked as [`allow_single_file`](/versions/8.2.1/rules/lib/toplevel/attr#label.allow_single_file). The struct fields correspond to the attribute names. The struct value is always a [`File`](/versions/8.2.1/rules/lib/builtins/File) or `None`. If an optional attribute is not specified in the rule then the corresponding struct value is `None`. If a label type is not marked as `allow_single_file`, no corresponding struct field is generated. It is a shortcut for:
 
 ```
 list(ctx.attr..files)[0]
@@ -221,7 +221,7 @@ In other words, use `file` to access the (singular) [default output](https://baz
 struct ctx.files
 ```
 
-A `struct` containing files defined in [label](../toplevel/attr#label) or [label list](../toplevel/attr#label_list) type attributes. The struct fields correspond to the attribute names. The struct values are `list` of [`File`](../builtins/File)s. It is a shortcut for:
+A `struct` containing files defined in [label](/versions/8.2.1/rules/lib/toplevel/attr#label) or [label list](/versions/8.2.1/rules/lib/toplevel/attr#label_list) type attributes. The struct fields correspond to the attribute names. The struct values are `list` of [`File`](/versions/8.2.1/rules/lib/builtins/File)s. It is a shortcut for:
 
 ```
 [f for t in ctx.attr. for f in t.files]
@@ -267,13 +267,13 @@ The label of the target currently being analyzed.
 structure ctx.outputs
 ```
 
-A pseudo-struct containing all the predeclared output files, represented by [`File`](../builtins/File) objects. See the [Rules page](https://bazel.build/versions/8.2.1/extending/rules#files) for more information and examples.
+A pseudo-struct containing all the predeclared output files, represented by [`File`](/versions/8.2.1/rules/lib/builtins/File) objects. See the [Rules page](https://bazel.build/versions/8.2.1/extending/rules#files) for more information and examples.
 
 This field does not exist on aspect contexts, since aspects do not have predeclared outputs.
 
 The fields of this object are defined as follows. It is an error if two outputs produce the same field name or have the same label.
 
-* If the rule declares an [`outputs`](../globals/bzl#rule.outputs) dict, then for every entry in the dict, there is a field whose name is the key and whose value is the corresponding `File`.* For every attribute of type [`attr.output`](../toplevel/attr#output) that the rule declares, there is a field whose name is the attribute's name. If the target specified a label for that attribute, then the field value is the corresponding `File`; otherwise the field value is `None`.* For every attribute of type [`attr.output_list`](../toplevel/attr#output_list) that the rule declares, there is a field whose name is the attribute's name. The field value is a list of `File` objects corresponding to the labels given for that attribute in the target, or an empty list if the attribute was not specified in the target.* **(Deprecated)** If the rule is marked [`executable`](../globals/bzl#rule.executable) or [`test`](../globals/bzl#rule.test), there is a field named `"executable"`, which is the default executable. It is recommended that instead of using this, you pass another file (either predeclared or not) to the `executable` arg of [`DefaultInfo`](../providers/DefaultInfo).
+* If the rule declares an [`outputs`](/versions/8.2.1/rules/lib/globals/bzl#rule.outputs) dict, then for every entry in the dict, there is a field whose name is the key and whose value is the corresponding `File`.* For every attribute of type [`attr.output`](/versions/8.2.1/rules/lib/toplevel/attr#output) that the rule declares, there is a field whose name is the attribute's name. If the target specified a label for that attribute, then the field value is the corresponding `File`; otherwise the field value is `None`.* For every attribute of type [`attr.output_list`](/versions/8.2.1/rules/lib/toplevel/attr#output_list) that the rule declares, there is a field whose name is the attribute's name. The field value is a list of `File` objects corresponding to the labels given for that attribute in the target, or an empty list if the attribute was not specified in the target.* **(Deprecated)** If the rule is marked [`executable`](/versions/8.2.1/rules/lib/globals/bzl#rule.executable) or [`test`](/versions/8.2.1/rules/lib/globals/bzl#rule.test), there is a field named `"executable"`, which is the default executable. It is recommended that instead of using this, you pass another file (either predeclared or not) to the `executable` arg of [`DefaultInfo`](/versions/8.2.1/rules/lib/providers/DefaultInfo).
 
 ## resolve\_command
 
@@ -288,13 +288,13 @@ tuple ctx.resolve_command(command='', attribute=None, expand_locations=False, ma
 
 | Parameter | Description |
 | --- | --- |
-| `command` | [string](../core/string); default is `''`  Command to resolve. |
-| `attribute` | [string](../core/string); or `None`; default is `None`  Name of the associated attribute for which to issue an error, or None. |
-| `expand_locations` | [bool](../core/bool); default is `False`  Shall we expand $(location) variables? See [ctx.expand\_location()](#expand_location) for more details. |
-| `make_variables` | [dict](../core/dict); or `None`; default is `None`  Make variables to expand, or None. |
-| `tools` | [sequence](../core/list) of [Target](../builtins/Target)s; default is `[]`  List of tools (list of targets). |
-| `label_dict` | [dict](../core/dict); default is `{}`  Dictionary of resolved labels and the corresponding list of Files (a dict of Label : list of Files). |
-| `execution_requirements` | [dict](../core/dict); default is `{}`  Information for scheduling the action to resolve this command. See [tags](/versions/8.2.1/reference/be/common-definitions#common.tags) for useful keys. |
+| `command` | [string](/versions/8.2.1/rules/lib/core/string); default is `''`  Command to resolve. |
+| `attribute` | [string](/versions/8.2.1/rules/lib/core/string); or `None`; default is `None`  Name of the associated attribute for which to issue an error, or None. |
+| `expand_locations` | [bool](/versions/8.2.1/rules/lib/core/bool); default is `False`  Shall we expand $(location) variables? See [ctx.expand\_location()](#expand_location) for more details. |
+| `make_variables` | [dict](/versions/8.2.1/rules/lib/core/dict); or `None`; default is `None`  Make variables to expand, or None. |
+| `tools` | [sequence](/versions/8.2.1/rules/lib/core/list) of [Target](/versions/8.2.1/rules/lib/builtins/Target)s; default is `[]`  List of tools (list of targets). |
+| `label_dict` | [dict](/versions/8.2.1/rules/lib/core/dict); default is `{}`  Dictionary of resolved labels and the corresponding list of Files (a dict of Label : list of Files). |
+| `execution_requirements` | [dict](/versions/8.2.1/rules/lib/core/dict); default is `{}`  Information for scheduling the action to resolve this command. See [tags](/versions/8.2.1/reference/be/common-definitions#common.tags) for useful keys. |
 
 ## resolve\_tools
 
@@ -310,7 +310,7 @@ In contrast to `ctx.resolve_command`, this method does not require that Bash be
 
 | Parameter | Description |
 | --- | --- |
-| `tools` | [sequence](../core/list) of [Target](../builtins/Target)s; default is `[]`  List of tools (list of targets). |
+| `tools` | [sequence](/versions/8.2.1/rules/lib/core/list) of [Target](/versions/8.2.1/rules/lib/builtins/Target)s; default is `[]`  List of tools (list of targets). |
 
 ## rule
 
@@ -332,12 +332,12 @@ Creates a runfiles object.
 
 | Parameter | Description |
 | --- | --- |
-| `files` | [sequence](../core/list) of [File](../builtins/File)s; default is `[]`  The list of files to be added to the runfiles. |
-| `transitive_files` | [depset](../builtins/depset) of [File](../builtins/File)s; or `None`; default is `None`  The (transitive) set of files to be added to the runfiles. The depset should use the `default` order (which, as the name implies, is the default). |
-| `collect_data` | [bool](../core/bool); default is `False`  **Use of this parameter is not recommended. See [runfiles guide](https://bazel.build/versions/8.2.1/extending/rules#runfiles)**. Whether to collect the data runfiles from the dependencies in srcs, data and deps attributes. |
-| `collect_default` | [bool](../core/bool); default is `False`  **Use of this parameter is not recommended. See [runfiles guide](https://bazel.build/versions/8.2.1/extending/rules#runfiles)**. Whether to collect the default runfiles from the dependencies in srcs, data and deps attributes. |
-| `symlinks` | [dict](../core/dict); or [depset](../builtins/depset) of [SymlinkEntry](../builtins/SymlinkEntry)s; default is `{}`  Either a SymlinkEntry depset or the map of symlinks to be added to the runfiles. Symlinks are always added under the main workspace's runfiles directory (e.g. `/_main/`, **not** the directory corresponding to the current target's repository. See [Runfiles symlinks](https://bazel.build/versions/8.2.1/extending/rules#runfiles_symlinks) in the rules guide. |
-| `root_symlinks` | [dict](../core/dict); or [depset](../builtins/depset) of [SymlinkEntry](../builtins/SymlinkEntry)s; default is `{}`  Either a SymlinkEntry depset or a map of symlinks to be added to the runfiles. See [Runfiles symlinks](https://bazel.build/versions/8.2.1/extending/rules#runfiles_symlinks) in the rules guide. |
+| `files` | [sequence](/versions/8.2.1/rules/lib/core/list) of [File](/versions/8.2.1/rules/lib/builtins/File)s; default is `[]`  The list of files to be added to the runfiles. |
+| `transitive_files` | [depset](/versions/8.2.1/rules/lib/builtins/depset) of [File](/versions/8.2.1/rules/lib/builtins/File)s; or `None`; default is `None`  The (transitive) set of files to be added to the runfiles. The depset should use the `default` order (which, as the name implies, is the default). |
+| `collect_data` | [bool](/versions/8.2.1/rules/lib/core/bool); default is `False`  **Use of this parameter is not recommended. See [runfiles guide](https://bazel.build/versions/8.2.1/extending/rules#runfiles)**. Whether to collect the data runfiles from the dependencies in srcs, data and deps attributes. |
+| `collect_default` | [bool](/versions/8.2.1/rules/lib/core/bool); default is `False`  **Use of this parameter is not recommended. See [runfiles guide](https://bazel.build/versions/8.2.1/extending/rules#runfiles)**. Whether to collect the default runfiles from the dependencies in srcs, data and deps attributes. |
+| `symlinks` | [dict](/versions/8.2.1/rules/lib/core/dict); or [depset](/versions/8.2.1/rules/lib/builtins/depset) of [SymlinkEntry](/versions/8.2.1/rules/lib/builtins/SymlinkEntry)s; default is `{}`  Either a SymlinkEntry depset or the map of symlinks to be added to the runfiles. Symlinks are always added under the main workspace's runfiles directory (e.g. `/_main/`, **not** the directory corresponding to the current target's repository. See [Runfiles symlinks](https://bazel.build/versions/8.2.1/extending/rules#runfiles_symlinks) in the rules guide. |
+| `root_symlinks` | [dict](/versions/8.2.1/rules/lib/core/dict); or [depset](/versions/8.2.1/rules/lib/builtins/depset) of [SymlinkEntry](/versions/8.2.1/rules/lib/builtins/SymlinkEntry)s; default is `{}`  Either a SymlinkEntry depset or a map of symlinks to be added to the runfiles. See [Runfiles symlinks](https://bazel.build/versions/8.2.1/extending/rules#runfiles_symlinks) in the rules guide. |
 
 ## split\_attr
 
@@ -367,7 +367,7 @@ Returns true if the given constraint value is part of the current target platfor
 
 | Parameter | Description |
 | --- | --- |
-| `constraintValue` | [ConstraintValueInfo](../providers/ConstraintValueInfo); required  The constraint value to check the target platform against. |
+| `constraintValue` | [ConstraintValueInfo](/versions/8.2.1/rules/lib/providers/ConstraintValueInfo); required  The constraint value to check the target platform against. |
 
 ## toolchains
 
diff --git a/versions/8.2.1/rules/lib/builtins/depset.mdx b/versions/8.2.1/rules/lib/builtins/depset.mdx
index 8545eb39..bf5a26eb 100644
--- a/versions/8.2.1/rules/lib/builtins/depset.mdx
+++ b/versions/8.2.1/rules/lib/builtins/depset.mdx
@@ -6,7 +6,7 @@ A specialized data structure that supports efficient merge operations and has a
 
 The elements of a depset must be hashable and all of the same type (as defined by the built-in type(x) function), but depsets are not simply hash sets and do not support fast membership tests. If you need a general set datatype, you can simulate one using a dictionary where all keys map to `True`.
 
-Depsets are immutable. They should be created using their [constructor function](../globals/bzl#depset) and merged or augmented with other depsets via the `transitive` argument.
+Depsets are immutable. They should be created using their [constructor function](/versions/8.2.1/rules/lib/globals/bzl#depset) and merged or augmented with other depsets via the `transitive` argument.
 
 The `order` parameter determines the kind of traversal that is done to convert the depset to an iterable. There are four possible values:
 
diff --git a/versions/8.2.1/rules/lib/builtins/fragments.mdx b/versions/8.2.1/rules/lib/builtins/fragments.mdx
index 21a3bb50..057a9c52 100644
--- a/versions/8.2.1/rules/lib/builtins/fragments.mdx
+++ b/versions/8.2.1/rules/lib/builtins/fragments.mdx
@@ -6,4 +6,4 @@ A collection of configuration fragments available in the current rule implementa
 
 Only configuration fragments which are declared in the rule definition may be accessed in this collection.
 
-See the [configuration fragment reference](../fragments) for a list of available fragments and the [rules documentation](https://bazel.build/versions/8.2.1/extending/rules#configuration_fragments) for how to use them.
\ No newline at end of file
+See the [configuration fragment reference](/versions/8.2.1/rules/lib/fragments) for a list of available fragments and the [rules documentation](https://bazel.build/versions/8.2.1/extending/rules#configuration_fragments) for how to use them.
\ No newline at end of file
diff --git a/versions/8.2.1/rules/lib/builtins/macro.mdx b/versions/8.2.1/rules/lib/builtins/macro.mdx
index dd1b7093..1f1ccfc4 100644
--- a/versions/8.2.1/rules/lib/builtins/macro.mdx
+++ b/versions/8.2.1/rules/lib/builtins/macro.mdx
@@ -3,7 +3,7 @@ title: 'macro'
 ---
 
 A callable Starlark value representing a symbolic macro; in other words, the return value of
-[`macro()`](../globals/bzl#macro). Invoking this value during package
+[`macro()`](/versions/8.2.1/rules/lib/globals/bzl#macro). Invoking this value during package
 construction time will instantiate the macro, and cause the macro's implementation function to be
 evaluated (in a separate context, different from the context in which the macro value was invoked),
 in most cases causing targets to be added to the package's target set. For more information, see
diff --git a/versions/8.2.1/rules/lib/builtins/module_ctx.mdx b/versions/8.2.1/rules/lib/builtins/module_ctx.mdx
index d0c2531c..65ee3127 100644
--- a/versions/8.2.1/rules/lib/builtins/module_ctx.mdx
+++ b/versions/8.2.1/rules/lib/builtins/module_ctx.mdx
@@ -35,16 +35,16 @@ Downloads a file to the output path for the provided url and returns a struct co
 
 | Parameter | Description |
 | --- | --- |
-| `url` | [string](../core/string); or Iterable of [string](../core/string)s; required  List of mirror URLs referencing the same file. |
-| `output` | [string](../core/string); or [Label](../builtins/Label); or [path](../builtins/path); default is `''`  path to the output file, relative to the repository directory. |
-| `sha256` | [string](../core/string); default is `''`  The expected SHA-256 hash of the file downloaded. This must match the SHA-256 hash of the file downloaded. It is a security risk to omit the SHA-256 as remote files can change. At best omitting this field will make your build non-hermetic. It is optional to make development easier but should be set before shipping. If provided, the repository cache will first be checked for a file with the given hash; a download will only be attempted if the file was not found in the cache. After a successful download, the file will be added to the cache. |
-| `executable` | [bool](../core/bool); default is `False`  Set the executable flag on the created file, false by default. |
-| `allow_fail` | [bool](../core/bool); default is `False`  If set, indicate the error in the return value instead of raising an error for failed downloads. |
-| `canonical_id` | [string](../core/string); default is `''`  If set, restrict cache hits to those cases where the file was added to the cache with the same canonical id. By default caching uses the checksum (`sha256` or `integrity`). |
-| `auth` | [dict](../core/dict); default is `{}`  An optional dict specifying authentication information for some of the URLs. |
-| `headers` | [dict](../core/dict); default is `{}`  An optional dict specifying http headers for all URLs. |
-| `integrity` | [string](../core/string); default is `''`  Expected checksum of the file downloaded, in Subresource Integrity format. This must match the checksum of the file downloaded. It is a security risk to omit the checksum as remote files can change. At best omitting this field will make your build non-hermetic. It is optional to make development easier but should be set before shipping. If provided, the repository cache will first be checked for a file with the given checksum; a download will only be attempted if the file was not found in the cache. After a successful download, the file will be added to the cache. |
-| `block` | [bool](../core/bool); default is `True`  If set to false, the call returns immediately and instead of the regular return value, it returns a token with one single method, wait(), which blocks until the download is finished and returns the usual return value or throws as usual. |
+| `url` | [string](/versions/8.2.1/rules/lib/core/string); or Iterable of [string](/versions/8.2.1/rules/lib/core/string)s; required  List of mirror URLs referencing the same file. |
+| `output` | [string](/versions/8.2.1/rules/lib/core/string); or [Label](/versions/8.2.1/rules/lib/builtins/Label); or [path](/versions/8.2.1/rules/lib/builtins/path); default is `''`  path to the output file, relative to the repository directory. |
+| `sha256` | [string](/versions/8.2.1/rules/lib/core/string); default is `''`  The expected SHA-256 hash of the file downloaded. This must match the SHA-256 hash of the file downloaded. It is a security risk to omit the SHA-256 as remote files can change. At best omitting this field will make your build non-hermetic. It is optional to make development easier but should be set before shipping. If provided, the repository cache will first be checked for a file with the given hash; a download will only be attempted if the file was not found in the cache. After a successful download, the file will be added to the cache. |
+| `executable` | [bool](/versions/8.2.1/rules/lib/core/bool); default is `False`  Set the executable flag on the created file, false by default. |
+| `allow_fail` | [bool](/versions/8.2.1/rules/lib/core/bool); default is `False`  If set, indicate the error in the return value instead of raising an error for failed downloads. |
+| `canonical_id` | [string](/versions/8.2.1/rules/lib/core/string); default is `''`  If set, restrict cache hits to those cases where the file was added to the cache with the same canonical id. By default caching uses the checksum (`sha256` or `integrity`). |
+| `auth` | [dict](/versions/8.2.1/rules/lib/core/dict); default is `{}`  An optional dict specifying authentication information for some of the URLs. |
+| `headers` | [dict](/versions/8.2.1/rules/lib/core/dict); default is `{}`  An optional dict specifying http headers for all URLs. |
+| `integrity` | [string](/versions/8.2.1/rules/lib/core/string); default is `''`  Expected checksum of the file downloaded, in Subresource Integrity format. This must match the checksum of the file downloaded. It is a security risk to omit the checksum as remote files can change. At best omitting this field will make your build non-hermetic. It is optional to make development easier but should be set before shipping. If provided, the repository cache will first be checked for a file with the given checksum; a download will only be attempted if the file was not found in the cache. After a successful download, the file will be added to the cache. |
+| `block` | [bool](/versions/8.2.1/rules/lib/core/bool); default is `True`  If set to false, the call returns immediately and instead of the regular return value, it returns a token with one single method, wait(), which blocks until the download is finished and returns the usual return value or throws as usual. |
 
 ## download\_and\_extract
 
@@ -58,17 +58,17 @@ Downloads a file to the output path for the provided url, extracts it, and retur
 
 | Parameter | Description |
 | --- | --- |
-| `url` | [string](../core/string); or Iterable of [string](../core/string)s; required  List of mirror URLs referencing the same file. |
-| `output` | [string](../core/string); or [Label](../builtins/Label); or [path](../builtins/path); default is `''`  Path to the directory where the archive will be unpacked, relative to the repository directory. |
-| `sha256` | [string](../core/string); default is `''`  The expected SHA-256 hash of the file downloaded. This must match the SHA-256 hash of the file downloaded. It is a security risk to omit the SHA-256 as remote files can change. At best omitting this field will make your build non-hermetic. It is optional to make development easier but should be set before shipping. If provided, the repository cache will first be checked for a file with the given hash; a download will only be attempted if the file was not found in the cache. After a successful download, the file will be added to the cache. |
-| `type` | [string](../core/string); default is `''`  The archive type of the downloaded file. By default, the archive type is determined from the file extension of the URL. If the file has no extension, you can explicitly specify either "zip", "jar", "war", "aar", "nupkg", "tar", "tar.gz", "tgz", "tar.xz", "txz", ".tar.zst", ".tzst", "tar.bz2", ".tbz", ".ar", or ".deb" here. |
-| `strip_prefix` | [string](../core/string); default is `''`  A directory prefix to strip from the extracted files. Many archives contain a top-level directory that contains all files in the archive. Instead of needing to specify this prefix over and over in the `build_file`, this field can be used to strip it from extracted files. For compatibility, this parameter may also be used under the deprecated name `stripPrefix`. |
-| `allow_fail` | [bool](../core/bool); default is `False`  If set, indicate the error in the return value instead of raising an error for failed downloads. |
-| `canonical_id` | [string](../core/string); default is `''`  If set, restrict cache hits to those cases where the file was added to the cache with the same canonical id. By default caching uses the checksum" (`sha256` or `integrity`). |
-| `auth` | [dict](../core/dict); default is `{}`  An optional dict specifying authentication information for some of the URLs. |
-| `headers` | [dict](../core/dict); default is `{}`  An optional dict specifying http headers for all URLs. |
-| `integrity` | [string](../core/string); default is `''`  Expected checksum of the file downloaded, in Subresource Integrity format. This must match the checksum of the file downloaded. It is a security risk to omit the checksum as remote files can change. At best omitting this field will make your build non-hermetic. It is optional to make development easier but should be set before shipping. If provided, the repository cache will first be checked for a file with the given checksum; a download will only be attempted if the file was not found in the cache. After a successful download, the file will be added to the cache. |
-| `rename_files` | [dict](../core/dict); default is `{}`  An optional dict specifying files to rename during the extraction. Archive entries with names exactly matching a key will be renamed to the value, prior to any directory prefix adjustment. This can be used to extract archives that contain non-Unicode filenames, or which have files that would extract to the same path on case-insensitive filesystems. |
+| `url` | [string](/versions/8.2.1/rules/lib/core/string); or Iterable of [string](/versions/8.2.1/rules/lib/core/string)s; required  List of mirror URLs referencing the same file. |
+| `output` | [string](/versions/8.2.1/rules/lib/core/string); or [Label](/versions/8.2.1/rules/lib/builtins/Label); or [path](/versions/8.2.1/rules/lib/builtins/path); default is `''`  Path to the directory where the archive will be unpacked, relative to the repository directory. |
+| `sha256` | [string](/versions/8.2.1/rules/lib/core/string); default is `''`  The expected SHA-256 hash of the file downloaded. This must match the SHA-256 hash of the file downloaded. It is a security risk to omit the SHA-256 as remote files can change. At best omitting this field will make your build non-hermetic. It is optional to make development easier but should be set before shipping. If provided, the repository cache will first be checked for a file with the given hash; a download will only be attempted if the file was not found in the cache. After a successful download, the file will be added to the cache. |
+| `type` | [string](/versions/8.2.1/rules/lib/core/string); default is `''`  The archive type of the downloaded file. By default, the archive type is determined from the file extension of the URL. If the file has no extension, you can explicitly specify either "zip", "jar", "war", "aar", "nupkg", "tar", "tar.gz", "tgz", "tar.xz", "txz", ".tar.zst", ".tzst", "tar.bz2", ".tbz", ".ar", or ".deb" here. |
+| `strip_prefix` | [string](/versions/8.2.1/rules/lib/core/string); default is `''`  A directory prefix to strip from the extracted files. Many archives contain a top-level directory that contains all files in the archive. Instead of needing to specify this prefix over and over in the `build_file`, this field can be used to strip it from extracted files. For compatibility, this parameter may also be used under the deprecated name `stripPrefix`. |
+| `allow_fail` | [bool](/versions/8.2.1/rules/lib/core/bool); default is `False`  If set, indicate the error in the return value instead of raising an error for failed downloads. |
+| `canonical_id` | [string](/versions/8.2.1/rules/lib/core/string); default is `''`  If set, restrict cache hits to those cases where the file was added to the cache with the same canonical id. By default caching uses the checksum" (`sha256` or `integrity`). |
+| `auth` | [dict](/versions/8.2.1/rules/lib/core/dict); default is `{}`  An optional dict specifying authentication information for some of the URLs. |
+| `headers` | [dict](/versions/8.2.1/rules/lib/core/dict); default is `{}`  An optional dict specifying http headers for all URLs. |
+| `integrity` | [string](/versions/8.2.1/rules/lib/core/string); default is `''`  Expected checksum of the file downloaded, in Subresource Integrity format. This must match the checksum of the file downloaded. It is a security risk to omit the checksum as remote files can change. At best omitting this field will make your build non-hermetic. It is optional to make development easier but should be set before shipping. If provided, the repository cache will first be checked for a file with the given checksum; a download will only be attempted if the file was not found in the cache. After a successful download, the file will be added to the cache. |
+| `rename_files` | [dict](/versions/8.2.1/rules/lib/core/dict); default is `{}`  An optional dict specifying files to rename during the extraction. Archive entries with names exactly matching a key will be renamed to the value, prior to any directory prefix adjustment. This can be used to extract archives that contain non-Unicode filenames, or which have files that would extract to the same path on case-insensitive filesystems. |
 
 ## execute
 
@@ -82,11 +82,11 @@ Executes the command given by the list of arguments. The execution time of the c
 
 | Parameter | Description |
 | --- | --- |
-| `arguments` | [sequence](../core/list); required  List of arguments, the first element should be the path to the program to execute. |
-| `timeout` | [int](../core/int); default is `600`  Maximum duration of the command in seconds (default is 600 seconds). |
-| `environment` | [dict](../core/dict); default is `{}`  Force some environment variables to be set to be passed to the process. The value can be `None` to remove the environment variable. |
-| `quiet` | [bool](../core/bool); default is `True`  If stdout and stderr should be printed to the terminal. |
-| `working_directory` | [string](../core/string); default is `""`  Working directory for command execution. Can be relative to the repository root or absolute. The default is the repository root. |
+| `arguments` | [sequence](/versions/8.2.1/rules/lib/core/list); required  List of arguments, the first element should be the path to the program to execute. |
+| `timeout` | [int](/versions/8.2.1/rules/lib/core/int); default is `600`  Maximum duration of the command in seconds (default is 600 seconds). |
+| `environment` | [dict](/versions/8.2.1/rules/lib/core/dict); default is `{}`  Force some environment variables to be set to be passed to the process. The value can be `None` to remove the environment variable. |
+| `quiet` | [bool](/versions/8.2.1/rules/lib/core/bool); default is `True`  If stdout and stderr should be printed to the terminal. |
+| `working_directory` | [string](/versions/8.2.1/rules/lib/core/string); default is `""`  Working directory for command execution. Can be relative to the repository root or absolute. The default is the repository root. |
 
 ## extension\_metadata
 
@@ -100,9 +100,9 @@ Constructs an opaque object that can be returned from the module extension's imp
 
 | Parameter | Description |
 | --- | --- |
-| `root_module_direct_deps` | [sequence](../core/list) of [string](../core/string)s; or [string](../core/string); or `None`; default is `None`  The names of the repositories that the extension considers to be direct dependencies of the root module. If the root module imports additional repositories or does not import all of these repositories via [`use_repo`](../globals/module#use_repo), Bazel will print a warning when the extension is evaluated, instructing the user to run `bazel mod tidy` to fix the `use_repo` calls automatically. If one of `root_module_direct_deps` and will print a warning and a fixup command when the extension is evaluated. If one of `root_module_direct_deps` and `root_module_direct_dev_deps` is specified, the other has to be as well. The lists specified by these two parameters must be disjoint. Exactly one of `root_module_direct_deps` and `root_module_direct_dev_deps` can be set to the special value `"all"`, which is treated as if a list with the names of all repositories generated by the extension was specified as the value. |
-| `root_module_direct_dev_deps` | [sequence](../core/list) of [string](../core/string)s; or [string](../core/string); or `None`; default is `None`  The names of the repositories that the extension considers to be direct dev dependencies of the root module. If the root module imports additional repositories or does not import all of these repositories via [`use_repo`](../globals/module#use_repo) on an extension proxy created with `use_extension(..., dev_dependency = True)`, Bazel will print a warning when the extension is evaluated, instructing the user to run `bazel mod tidy` to fix the `use_repo` calls automatically. If one of `root_module_direct_deps` and `root_module_direct_dev_deps` is specified, the other has to be as well. The lists specified by these two parameters must be disjoint. Exactly one of `root_module_direct_deps` and `root_module_direct_dev_deps` can be set to the special value `"all"`, which is treated as if a list with the names of all repositories generated by the extension was specified as the value. |
-| `reproducible` | [bool](../core/bool); default is `False`  States that this module extension ensures complete reproducibility, thereby it should not be stored in the lockfile. |
+| `root_module_direct_deps` | [sequence](/versions/8.2.1/rules/lib/core/list) of [string](/versions/8.2.1/rules/lib/core/string)s; or [string](/versions/8.2.1/rules/lib/core/string); or `None`; default is `None`  The names of the repositories that the extension considers to be direct dependencies of the root module. If the root module imports additional repositories or does not import all of these repositories via [`use_repo`](/versions/8.2.1/rules/lib/globals/module#use_repo), Bazel will print a warning when the extension is evaluated, instructing the user to run `bazel mod tidy` to fix the `use_repo` calls automatically. If one of `root_module_direct_deps` and will print a warning and a fixup command when the extension is evaluated. If one of `root_module_direct_deps` and `root_module_direct_dev_deps` is specified, the other has to be as well. The lists specified by these two parameters must be disjoint. Exactly one of `root_module_direct_deps` and `root_module_direct_dev_deps` can be set to the special value `"all"`, which is treated as if a list with the names of all repositories generated by the extension was specified as the value. |
+| `root_module_direct_dev_deps` | [sequence](/versions/8.2.1/rules/lib/core/list) of [string](/versions/8.2.1/rules/lib/core/string)s; or [string](/versions/8.2.1/rules/lib/core/string); or `None`; default is `None`  The names of the repositories that the extension considers to be direct dev dependencies of the root module. If the root module imports additional repositories or does not import all of these repositories via [`use_repo`](/versions/8.2.1/rules/lib/globals/module#use_repo) on an extension proxy created with `use_extension(..., dev_dependency = True)`, Bazel will print a warning when the extension is evaluated, instructing the user to run `bazel mod tidy` to fix the `use_repo` calls automatically. If one of `root_module_direct_deps` and `root_module_direct_dev_deps` is specified, the other has to be as well. The lists specified by these two parameters must be disjoint. Exactly one of `root_module_direct_deps` and `root_module_direct_dev_deps` can be set to the special value `"all"`, which is treated as if a list with the names of all repositories generated by the extension was specified as the value. |
+| `reproducible` | [bool](/versions/8.2.1/rules/lib/core/bool); default is `False`  States that this module extension ensures complete reproducibility, thereby it should not be stored in the lockfile. |
 
 ## extract
 
@@ -116,11 +116,11 @@ Extract an archive to the repository directory.
 
 | Parameter | Description |
 | --- | --- |
-| `archive` | [string](../core/string); or [Label](../builtins/Label); or [path](../builtins/path); required  path to the archive that will be unpacked, relative to the repository directory. |
-| `output` | [string](../core/string); or [Label](../builtins/Label); or [path](../builtins/path); default is `''`  path to the directory where the archive will be unpacked, relative to the repository directory. |
-| `strip_prefix` | [string](../core/string); default is `''`  a directory prefix to strip from the extracted files. Many archives contain a top-level directory that contains all files in the archive. Instead of needing to specify this prefix over and over in the `build_file`, this field can be used to strip it from extracted files. For compatibility, this parameter may also be used under the deprecated name `stripPrefix`. |
-| `rename_files` | [dict](../core/dict); default is `{}`  An optional dict specifying files to rename during the extraction. Archive entries with names exactly matching a key will be renamed to the value, prior to any directory prefix adjustment. This can be used to extract archives that contain non-Unicode filenames, or which have files that would extract to the same path on case-insensitive filesystems. |
-| `watch_archive` | [string](../core/string); default is `'auto'`  whether to [watch](#watch) the archive file. Can be the string 'yes', 'no', or 'auto'. Passing 'yes' is equivalent to immediately invoking the [`watch()`](#watch) method; passing 'no' does not attempt to watch the file; passing 'auto' will only attempt to watch the file when it is legal to do so (see `watch()` docs for more information. |
+| `archive` | [string](/versions/8.2.1/rules/lib/core/string); or [Label](/versions/8.2.1/rules/lib/builtins/Label); or [path](/versions/8.2.1/rules/lib/builtins/path); required  path to the archive that will be unpacked, relative to the repository directory. |
+| `output` | [string](/versions/8.2.1/rules/lib/core/string); or [Label](/versions/8.2.1/rules/lib/builtins/Label); or [path](/versions/8.2.1/rules/lib/builtins/path); default is `''`  path to the directory where the archive will be unpacked, relative to the repository directory. |
+| `strip_prefix` | [string](/versions/8.2.1/rules/lib/core/string); default is `''`  a directory prefix to strip from the extracted files. Many archives contain a top-level directory that contains all files in the archive. Instead of needing to specify this prefix over and over in the `build_file`, this field can be used to strip it from extracted files. For compatibility, this parameter may also be used under the deprecated name `stripPrefix`. |
+| `rename_files` | [dict](/versions/8.2.1/rules/lib/core/dict); default is `{}`  An optional dict specifying files to rename during the extraction. Archive entries with names exactly matching a key will be renamed to the value, prior to any directory prefix adjustment. This can be used to extract archives that contain non-Unicode filenames, or which have files that would extract to the same path on case-insensitive filesystems. |
+| `watch_archive` | [string](/versions/8.2.1/rules/lib/core/string); default is `'auto'`  whether to [watch](#watch) the archive file. Can be the string 'yes', 'no', or 'auto'. Passing 'yes' is equivalent to immediately invoking the [`watch()`](#watch) method; passing 'no' does not attempt to watch the file; passing 'auto' will only attempt to watch the file when it is legal to do so (see `watch()` docs for more information. |
 
 ## file
 
@@ -134,10 +134,10 @@ Generates a file in the repository directory with the provided content.
 
 | Parameter | Description |
 | --- | --- |
-| `path` | [string](../core/string); or [Label](../builtins/Label); or [path](../builtins/path); required  Path of the file to create, relative to the repository directory. |
-| `content` | [string](../core/string); default is `''`  The content of the file to create, empty by default. |
-| `executable` | [bool](../core/bool); default is `True`  Set the executable flag on the created file, true by default. |
-| `legacy_utf8` | [bool](../core/bool); default is `False`  No-op. This parameter is deprecated and will be removed in a future version of Bazel. |
+| `path` | [string](/versions/8.2.1/rules/lib/core/string); or [Label](/versions/8.2.1/rules/lib/builtins/Label); or [path](/versions/8.2.1/rules/lib/builtins/path); required  Path of the file to create, relative to the repository directory. |
+| `content` | [string](/versions/8.2.1/rules/lib/core/string); default is `''`  The content of the file to create, empty by default. |
+| `executable` | [bool](/versions/8.2.1/rules/lib/core/bool); default is `True`  Set the executable flag on the created file, true by default. |
+| `legacy_utf8` | [bool](/versions/8.2.1/rules/lib/core/bool); default is `False`  No-op. This parameter is deprecated and will be removed in a future version of Bazel. |
 
 ## getenv
 
@@ -153,8 +153,8 @@ When building incrementally, any change to the value of the variable named by `n
 
 | Parameter | Description |
 | --- | --- |
-| `name` | [string](../core/string); required  Name of desired environment variable. |
-| `default` | [string](../core/string); or `None`; default is `None`  Default value to return if `name` is not found. |
+| `name` | [string](/versions/8.2.1/rules/lib/core/string); required  Name of desired environment variable. |
+| `default` | [string](/versions/8.2.1/rules/lib/core/string); or `None`; default is `None`  Default value to return if `name` is not found. |
 
 May return `None`.
 
@@ -164,13 +164,13 @@ May return `None`.
 bool module_ctx.is_dev_dependency(tag)
 ```
 
-Returns whether the given tag was specified on the result of a [use\_extension](../globals/module#use_extension) call with `devDependency = True`.
+Returns whether the given tag was specified on the result of a [use\_extension](/versions/8.2.1/rules/lib/globals/module#use_extension) call with `devDependency = True`.
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `tag` | bazel\_module\_tag; required  A tag obtained from [bazel\_module.tags](../builtins/bazel_module#tags). |
+| `tag` | bazel\_module\_tag; required  A tag obtained from [bazel\_module.tags](/versions/8.2.1/rules/lib/builtins/bazel_module#tags). |
 
 ## modules
 
@@ -178,7 +178,7 @@ Returns whether the given tag was specified on the result of a [use\_extension](
 list module_ctx.modules
 ```
 
-A list of all the Bazel modules in the external dependency graph that use this module extension, each of which is a [bazel\_module](../builtins/bazel_module) object that exposes all the tags it specified for this extension. The iteration order of this dictionary is guaranteed to be the same as breadth-first search starting from the root module.
+A list of all the Bazel modules in the external dependency graph that use this module extension, each of which is a [bazel\_module](/versions/8.2.1/rules/lib/builtins/bazel_module) object that exposes all the tags it specified for this extension. The iteration order of this dictionary is guaranteed to be the same as breadth-first search starting from the root module.
 
 ## os
 
@@ -200,7 +200,7 @@ Returns a path from a string, label or path. If the path is relative, it will re
 
 | Parameter | Description |
 | --- | --- |
-| `path` | [string](../core/string); or [Label](../builtins/Label); or [path](../builtins/path); required  `string`, `Label` or `path` from which to create a path from. |
+| `path` | [string](/versions/8.2.1/rules/lib/core/string); or [Label](/versions/8.2.1/rules/lib/builtins/Label); or [path](/versions/8.2.1/rules/lib/builtins/path); required  `string`, `Label` or `path` from which to create a path from. |
 
 ## read
 
@@ -214,8 +214,8 @@ Reads the content of a file on the filesystem.
 
 | Parameter | Description |
 | --- | --- |
-| `path` | [string](../core/string); or [Label](../builtins/Label); or [path](../builtins/path); required  Path of the file to read from. |
-| `watch` | [string](../core/string); default is `'auto'`  Whether to [watch](#watch) the file. Can be the string 'yes', 'no', or 'auto'. Passing 'yes' is equivalent to immediately invoking the [`watch()`](#watch) method; passing 'no' does not attempt to watch the file; passing 'auto' will only attempt to watch the file when it is legal to do so (see `watch()` docs for more information. |
+| `path` | [string](/versions/8.2.1/rules/lib/core/string); or [Label](/versions/8.2.1/rules/lib/builtins/Label); or [path](/versions/8.2.1/rules/lib/builtins/path); required  Path of the file to read from. |
+| `watch` | [string](/versions/8.2.1/rules/lib/core/string); default is `'auto'`  Whether to [watch](#watch) the file. Can be the string 'yes', 'no', or 'auto'. Passing 'yes' is equivalent to immediately invoking the [`watch()`](#watch) method; passing 'no' does not attempt to watch the file; passing 'auto' will only attempt to watch the file when it is legal to do so (see `watch()` docs for more information. |
 
 ## report\_progress
 
@@ -229,7 +229,7 @@ Updates the progress status for the fetching of this repository or module extens
 
 | Parameter | Description |
 | --- | --- |
-| `status` | [string](../core/string); default is `''`  `string` describing the current status of the fetch progress. |
+| `status` | [string](/versions/8.2.1/rules/lib/core/string); default is `''`  `string` describing the current status of the fetch progress. |
 
 ## root\_module\_has\_non\_dev\_dependency
 
@@ -247,7 +247,7 @@ None module_ctx.watch(path)
 
 Tells Bazel to watch for changes to the given path, whether or not it exists, or whether it's a file or a directory. Any changes to the file or directory will invalidate this repository or module extension, and cause it to be refetched or re-evaluated next time.
 
-"Changes" include changes to the contents of the file (if the path is a file); if the path was a file but is now a directory, or vice versa; and if the path starts or stops existing. Notably, this does *not* include changes to any files under the directory if the path is a directory. For that, use [`path.readdir()`](path#readdir) instead.
+"Changes" include changes to the contents of the file (if the path is a file); if the path was a file but is now a directory, or vice versa; and if the path starts or stops existing. Notably, this does *not* include changes to any files under the directory if the path is a directory. For that, use [`path.readdir()`](/versions/8.2.1/rules/lib/builtins/path#readdir) instead.
 
 Note that attempting to watch paths inside the repo currently being fetched, or inside the working directory of the current module extension, will result in an error. A module extension attempting to watch a path outside the current Bazel workspace will also result in an error.
 
@@ -255,7 +255,7 @@ Note that attempting to watch paths inside the repo currently being fetched, or
 
 | Parameter | Description |
 | --- | --- |
-| `path` | [string](../core/string); or [Label](../builtins/Label); or [path](../builtins/path); required  Path of the file to watch. |
+| `path` | [string](/versions/8.2.1/rules/lib/core/string); or [Label](/versions/8.2.1/rules/lib/builtins/Label); or [path](/versions/8.2.1/rules/lib/builtins/path); required  Path of the file to watch. |
 
 ## which
 
@@ -269,6 +269,6 @@ Returns the `path` of the corresponding program or `None` if there is no such pr
 
 | Parameter | Description |
 | --- | --- |
-| `program` | [string](../core/string); required  Program to find in the path. |
+| `program` | [string](/versions/8.2.1/rules/lib/core/string); required  Program to find in the path. |
 
 May return `None`.
\ No newline at end of file
diff --git a/versions/8.2.1/rules/lib/builtins/path.mdx b/versions/8.2.1/rules/lib/builtins/path.mdx
index d200110e..ed57b2f6 100644
--- a/versions/8.2.1/rules/lib/builtins/path.mdx
+++ b/versions/8.2.1/rules/lib/builtins/path.mdx
@@ -77,7 +77,7 @@ Returns the list of entries in the directory denoted by this path. Each entry is
 
 | Parameter | Description |
 | --- | --- |
-| `watch` | [string](../core/string); default is `'auto'`  whether Bazel should watch the list of entries in this directory and refetch the repository or re-evaluate the module extension next time when any changes are detected. Changes to detect include entry creation, deletion, and renaming. Note that this doesn't watch the *contents* of any entries in the directory. Can be the string 'yes', 'no', or 'auto'. If set to 'auto', Bazel will only watch this directory when it is legal to do so (see [`repository_ctx.watch()`](repository_ctx#watch) docs for more information). |
+| `watch` | [string](/versions/8.2.1/rules/lib/core/string); default is `'auto'`  whether Bazel should watch the list of entries in this directory and refetch the repository or re-evaluate the module extension next time when any changes are detected. Changes to detect include entry creation, deletion, and renaming. Note that this doesn't watch the *contents* of any entries in the directory. Can be the string 'yes', 'no', or 'auto'. If set to 'auto', Bazel will only watch this directory when it is legal to do so (see [`repository_ctx.watch()`](/versions/8.2.1/rules/lib/builtins/repository_ctx#watch) docs for more information). |
 
 ## realpath
 
diff --git a/versions/8.2.1/rules/lib/builtins/repository_ctx.mdx b/versions/8.2.1/rules/lib/builtins/repository_ctx.mdx
index 20de899b..6278789a 100644
--- a/versions/8.2.1/rules/lib/builtins/repository_ctx.mdx
+++ b/versions/8.2.1/rules/lib/builtins/repository_ctx.mdx
@@ -49,7 +49,7 @@ Deletes a file or a directory. Returns a bool, indicating whether the file or di
 
 | Parameter | Description |
 | --- | --- |
-| `path` | [string](../core/string); or [path](../builtins/path); required  Path of the file to delete, relative to the repository directory, or absolute. Can be a path or a string. |
+| `path` | [string](/versions/8.2.1/rules/lib/core/string); or [path](/versions/8.2.1/rules/lib/builtins/path); required  Path of the file to delete, relative to the repository directory, or absolute. Can be a path or a string. |
 
 ## download
 
@@ -63,16 +63,16 @@ Downloads a file to the output path for the provided url and returns a struct co
 
 | Parameter | Description |
 | --- | --- |
-| `url` | [string](../core/string); or Iterable of [string](../core/string)s; required  List of mirror URLs referencing the same file. |
-| `output` | [string](../core/string); or [Label](../builtins/Label); or [path](../builtins/path); default is `''`  path to the output file, relative to the repository directory. |
-| `sha256` | [string](../core/string); default is `''`  The expected SHA-256 hash of the file downloaded. This must match the SHA-256 hash of the file downloaded. It is a security risk to omit the SHA-256 as remote files can change. At best omitting this field will make your build non-hermetic. It is optional to make development easier but should be set before shipping. If provided, the repository cache will first be checked for a file with the given hash; a download will only be attempted if the file was not found in the cache. After a successful download, the file will be added to the cache. |
-| `executable` | [bool](../core/bool); default is `False`  Set the executable flag on the created file, false by default. |
-| `allow_fail` | [bool](../core/bool); default is `False`  If set, indicate the error in the return value instead of raising an error for failed downloads. |
-| `canonical_id` | [string](../core/string); default is `''`  If set, restrict cache hits to those cases where the file was added to the cache with the same canonical id. By default caching uses the checksum (`sha256` or `integrity`). |
-| `auth` | [dict](../core/dict); default is `{}`  An optional dict specifying authentication information for some of the URLs. |
-| `headers` | [dict](../core/dict); default is `{}`  An optional dict specifying http headers for all URLs. |
-| `integrity` | [string](../core/string); default is `''`  Expected checksum of the file downloaded, in Subresource Integrity format. This must match the checksum of the file downloaded. It is a security risk to omit the checksum as remote files can change. At best omitting this field will make your build non-hermetic. It is optional to make development easier but should be set before shipping. If provided, the repository cache will first be checked for a file with the given checksum; a download will only be attempted if the file was not found in the cache. After a successful download, the file will be added to the cache. |
-| `block` | [bool](../core/bool); default is `True`  If set to false, the call returns immediately and instead of the regular return value, it returns a token with one single method, wait(), which blocks until the download is finished and returns the usual return value or throws as usual. |
+| `url` | [string](/versions/8.2.1/rules/lib/core/string); or Iterable of [string](/versions/8.2.1/rules/lib/core/string)s; required  List of mirror URLs referencing the same file. |
+| `output` | [string](/versions/8.2.1/rules/lib/core/string); or [Label](/versions/8.2.1/rules/lib/builtins/Label); or [path](/versions/8.2.1/rules/lib/builtins/path); default is `''`  path to the output file, relative to the repository directory. |
+| `sha256` | [string](/versions/8.2.1/rules/lib/core/string); default is `''`  The expected SHA-256 hash of the file downloaded. This must match the SHA-256 hash of the file downloaded. It is a security risk to omit the SHA-256 as remote files can change. At best omitting this field will make your build non-hermetic. It is optional to make development easier but should be set before shipping. If provided, the repository cache will first be checked for a file with the given hash; a download will only be attempted if the file was not found in the cache. After a successful download, the file will be added to the cache. |
+| `executable` | [bool](/versions/8.2.1/rules/lib/core/bool); default is `False`  Set the executable flag on the created file, false by default. |
+| `allow_fail` | [bool](/versions/8.2.1/rules/lib/core/bool); default is `False`  If set, indicate the error in the return value instead of raising an error for failed downloads. |
+| `canonical_id` | [string](/versions/8.2.1/rules/lib/core/string); default is `''`  If set, restrict cache hits to those cases where the file was added to the cache with the same canonical id. By default caching uses the checksum (`sha256` or `integrity`). |
+| `auth` | [dict](/versions/8.2.1/rules/lib/core/dict); default is `{}`  An optional dict specifying authentication information for some of the URLs. |
+| `headers` | [dict](/versions/8.2.1/rules/lib/core/dict); default is `{}`  An optional dict specifying http headers for all URLs. |
+| `integrity` | [string](/versions/8.2.1/rules/lib/core/string); default is `''`  Expected checksum of the file downloaded, in Subresource Integrity format. This must match the checksum of the file downloaded. It is a security risk to omit the checksum as remote files can change. At best omitting this field will make your build non-hermetic. It is optional to make development easier but should be set before shipping. If provided, the repository cache will first be checked for a file with the given checksum; a download will only be attempted if the file was not found in the cache. After a successful download, the file will be added to the cache. |
+| `block` | [bool](/versions/8.2.1/rules/lib/core/bool); default is `True`  If set to false, the call returns immediately and instead of the regular return value, it returns a token with one single method, wait(), which blocks until the download is finished and returns the usual return value or throws as usual. |
 
 ## download\_and\_extract
 
@@ -86,17 +86,17 @@ Downloads a file to the output path for the provided url, extracts it, and retur
 
 | Parameter | Description |
 | --- | --- |
-| `url` | [string](../core/string); or Iterable of [string](../core/string)s; required  List of mirror URLs referencing the same file. |
-| `output` | [string](../core/string); or [Label](../builtins/Label); or [path](../builtins/path); default is `''`  Path to the directory where the archive will be unpacked, relative to the repository directory. |
-| `sha256` | [string](../core/string); default is `''`  The expected SHA-256 hash of the file downloaded. This must match the SHA-256 hash of the file downloaded. It is a security risk to omit the SHA-256 as remote files can change. At best omitting this field will make your build non-hermetic. It is optional to make development easier but should be set before shipping. If provided, the repository cache will first be checked for a file with the given hash; a download will only be attempted if the file was not found in the cache. After a successful download, the file will be added to the cache. |
-| `type` | [string](../core/string); default is `''`  The archive type of the downloaded file. By default, the archive type is determined from the file extension of the URL. If the file has no extension, you can explicitly specify either "zip", "jar", "war", "aar", "nupkg", "tar", "tar.gz", "tgz", "tar.xz", "txz", ".tar.zst", ".tzst", "tar.bz2", ".tbz", ".ar", or ".deb" here. |
-| `strip_prefix` | [string](../core/string); default is `''`  A directory prefix to strip from the extracted files. Many archives contain a top-level directory that contains all files in the archive. Instead of needing to specify this prefix over and over in the `build_file`, this field can be used to strip it from extracted files. For compatibility, this parameter may also be used under the deprecated name `stripPrefix`. |
-| `allow_fail` | [bool](../core/bool); default is `False`  If set, indicate the error in the return value instead of raising an error for failed downloads. |
-| `canonical_id` | [string](../core/string); default is `''`  If set, restrict cache hits to those cases where the file was added to the cache with the same canonical id. By default caching uses the checksum" (`sha256` or `integrity`). |
-| `auth` | [dict](../core/dict); default is `{}`  An optional dict specifying authentication information for some of the URLs. |
-| `headers` | [dict](../core/dict); default is `{}`  An optional dict specifying http headers for all URLs. |
-| `integrity` | [string](../core/string); default is `''`  Expected checksum of the file downloaded, in Subresource Integrity format. This must match the checksum of the file downloaded. It is a security risk to omit the checksum as remote files can change. At best omitting this field will make your build non-hermetic. It is optional to make development easier but should be set before shipping. If provided, the repository cache will first be checked for a file with the given checksum; a download will only be attempted if the file was not found in the cache. After a successful download, the file will be added to the cache. |
-| `rename_files` | [dict](../core/dict); default is `{}`  An optional dict specifying files to rename during the extraction. Archive entries with names exactly matching a key will be renamed to the value, prior to any directory prefix adjustment. This can be used to extract archives that contain non-Unicode filenames, or which have files that would extract to the same path on case-insensitive filesystems. |
+| `url` | [string](/versions/8.2.1/rules/lib/core/string); or Iterable of [string](/versions/8.2.1/rules/lib/core/string)s; required  List of mirror URLs referencing the same file. |
+| `output` | [string](/versions/8.2.1/rules/lib/core/string); or [Label](/versions/8.2.1/rules/lib/builtins/Label); or [path](/versions/8.2.1/rules/lib/builtins/path); default is `''`  Path to the directory where the archive will be unpacked, relative to the repository directory. |
+| `sha256` | [string](/versions/8.2.1/rules/lib/core/string); default is `''`  The expected SHA-256 hash of the file downloaded. This must match the SHA-256 hash of the file downloaded. It is a security risk to omit the SHA-256 as remote files can change. At best omitting this field will make your build non-hermetic. It is optional to make development easier but should be set before shipping. If provided, the repository cache will first be checked for a file with the given hash; a download will only be attempted if the file was not found in the cache. After a successful download, the file will be added to the cache. |
+| `type` | [string](/versions/8.2.1/rules/lib/core/string); default is `''`  The archive type of the downloaded file. By default, the archive type is determined from the file extension of the URL. If the file has no extension, you can explicitly specify either "zip", "jar", "war", "aar", "nupkg", "tar", "tar.gz", "tgz", "tar.xz", "txz", ".tar.zst", ".tzst", "tar.bz2", ".tbz", ".ar", or ".deb" here. |
+| `strip_prefix` | [string](/versions/8.2.1/rules/lib/core/string); default is `''`  A directory prefix to strip from the extracted files. Many archives contain a top-level directory that contains all files in the archive. Instead of needing to specify this prefix over and over in the `build_file`, this field can be used to strip it from extracted files. For compatibility, this parameter may also be used under the deprecated name `stripPrefix`. |
+| `allow_fail` | [bool](/versions/8.2.1/rules/lib/core/bool); default is `False`  If set, indicate the error in the return value instead of raising an error for failed downloads. |
+| `canonical_id` | [string](/versions/8.2.1/rules/lib/core/string); default is `''`  If set, restrict cache hits to those cases where the file was added to the cache with the same canonical id. By default caching uses the checksum" (`sha256` or `integrity`). |
+| `auth` | [dict](/versions/8.2.1/rules/lib/core/dict); default is `{}`  An optional dict specifying authentication information for some of the URLs. |
+| `headers` | [dict](/versions/8.2.1/rules/lib/core/dict); default is `{}`  An optional dict specifying http headers for all URLs. |
+| `integrity` | [string](/versions/8.2.1/rules/lib/core/string); default is `''`  Expected checksum of the file downloaded, in Subresource Integrity format. This must match the checksum of the file downloaded. It is a security risk to omit the checksum as remote files can change. At best omitting this field will make your build non-hermetic. It is optional to make development easier but should be set before shipping. If provided, the repository cache will first be checked for a file with the given checksum; a download will only be attempted if the file was not found in the cache. After a successful download, the file will be added to the cache. |
+| `rename_files` | [dict](/versions/8.2.1/rules/lib/core/dict); default is `{}`  An optional dict specifying files to rename during the extraction. Archive entries with names exactly matching a key will be renamed to the value, prior to any directory prefix adjustment. This can be used to extract archives that contain non-Unicode filenames, or which have files that would extract to the same path on case-insensitive filesystems. |
 
 ## execute
 
@@ -110,11 +110,11 @@ Executes the command given by the list of arguments. The execution time of the c
 
 | Parameter | Description |
 | --- | --- |
-| `arguments` | [sequence](../core/list); required  List of arguments, the first element should be the path to the program to execute. |
-| `timeout` | [int](../core/int); default is `600`  Maximum duration of the command in seconds (default is 600 seconds). |
-| `environment` | [dict](../core/dict); default is `{}`  Force some environment variables to be set to be passed to the process. The value can be `None` to remove the environment variable. |
-| `quiet` | [bool](../core/bool); default is `True`  If stdout and stderr should be printed to the terminal. |
-| `working_directory` | [string](../core/string); default is `""`  Working directory for command execution. Can be relative to the repository root or absolute. The default is the repository root. |
+| `arguments` | [sequence](/versions/8.2.1/rules/lib/core/list); required  List of arguments, the first element should be the path to the program to execute. |
+| `timeout` | [int](/versions/8.2.1/rules/lib/core/int); default is `600`  Maximum duration of the command in seconds (default is 600 seconds). |
+| `environment` | [dict](/versions/8.2.1/rules/lib/core/dict); default is `{}`  Force some environment variables to be set to be passed to the process. The value can be `None` to remove the environment variable. |
+| `quiet` | [bool](/versions/8.2.1/rules/lib/core/bool); default is `True`  If stdout and stderr should be printed to the terminal. |
+| `working_directory` | [string](/versions/8.2.1/rules/lib/core/string); default is `""`  Working directory for command execution. Can be relative to the repository root or absolute. The default is the repository root. |
 
 ## extract
 
@@ -128,11 +128,11 @@ Extract an archive to the repository directory.
 
 | Parameter | Description |
 | --- | --- |
-| `archive` | [string](../core/string); or [Label](../builtins/Label); or [path](../builtins/path); required  path to the archive that will be unpacked, relative to the repository directory. |
-| `output` | [string](../core/string); or [Label](../builtins/Label); or [path](../builtins/path); default is `''`  path to the directory where the archive will be unpacked, relative to the repository directory. |
-| `strip_prefix` | [string](../core/string); default is `''`  a directory prefix to strip from the extracted files. Many archives contain a top-level directory that contains all files in the archive. Instead of needing to specify this prefix over and over in the `build_file`, this field can be used to strip it from extracted files. For compatibility, this parameter may also be used under the deprecated name `stripPrefix`. |
-| `rename_files` | [dict](../core/dict); default is `{}`  An optional dict specifying files to rename during the extraction. Archive entries with names exactly matching a key will be renamed to the value, prior to any directory prefix adjustment. This can be used to extract archives that contain non-Unicode filenames, or which have files that would extract to the same path on case-insensitive filesystems. |
-| `watch_archive` | [string](../core/string); default is `'auto'`  whether to [watch](#watch) the archive file. Can be the string 'yes', 'no', or 'auto'. Passing 'yes' is equivalent to immediately invoking the [`watch()`](#watch) method; passing 'no' does not attempt to watch the file; passing 'auto' will only attempt to watch the file when it is legal to do so (see `watch()` docs for more information. |
+| `archive` | [string](/versions/8.2.1/rules/lib/core/string); or [Label](/versions/8.2.1/rules/lib/builtins/Label); or [path](/versions/8.2.1/rules/lib/builtins/path); required  path to the archive that will be unpacked, relative to the repository directory. |
+| `output` | [string](/versions/8.2.1/rules/lib/core/string); or [Label](/versions/8.2.1/rules/lib/builtins/Label); or [path](/versions/8.2.1/rules/lib/builtins/path); default is `''`  path to the directory where the archive will be unpacked, relative to the repository directory. |
+| `strip_prefix` | [string](/versions/8.2.1/rules/lib/core/string); default is `''`  a directory prefix to strip from the extracted files. Many archives contain a top-level directory that contains all files in the archive. Instead of needing to specify this prefix over and over in the `build_file`, this field can be used to strip it from extracted files. For compatibility, this parameter may also be used under the deprecated name `stripPrefix`. |
+| `rename_files` | [dict](/versions/8.2.1/rules/lib/core/dict); default is `{}`  An optional dict specifying files to rename during the extraction. Archive entries with names exactly matching a key will be renamed to the value, prior to any directory prefix adjustment. This can be used to extract archives that contain non-Unicode filenames, or which have files that would extract to the same path on case-insensitive filesystems. |
+| `watch_archive` | [string](/versions/8.2.1/rules/lib/core/string); default is `'auto'`  whether to [watch](#watch) the archive file. Can be the string 'yes', 'no', or 'auto'. Passing 'yes' is equivalent to immediately invoking the [`watch()`](#watch) method; passing 'no' does not attempt to watch the file; passing 'auto' will only attempt to watch the file when it is legal to do so (see `watch()` docs for more information. |
 
 ## file
 
@@ -146,10 +146,10 @@ Generates a file in the repository directory with the provided content.
 
 | Parameter | Description |
 | --- | --- |
-| `path` | [string](../core/string); or [Label](../builtins/Label); or [path](../builtins/path); required  Path of the file to create, relative to the repository directory. |
-| `content` | [string](../core/string); default is `''`  The content of the file to create, empty by default. |
-| `executable` | [bool](../core/bool); default is `True`  Set the executable flag on the created file, true by default. |
-| `legacy_utf8` | [bool](../core/bool); default is `False`  No-op. This parameter is deprecated and will be removed in a future version of Bazel. |
+| `path` | [string](/versions/8.2.1/rules/lib/core/string); or [Label](/versions/8.2.1/rules/lib/builtins/Label); or [path](/versions/8.2.1/rules/lib/builtins/path); required  Path of the file to create, relative to the repository directory. |
+| `content` | [string](/versions/8.2.1/rules/lib/core/string); default is `''`  The content of the file to create, empty by default. |
+| `executable` | [bool](/versions/8.2.1/rules/lib/core/bool); default is `True`  Set the executable flag on the created file, true by default. |
+| `legacy_utf8` | [bool](/versions/8.2.1/rules/lib/core/bool); default is `False`  No-op. This parameter is deprecated and will be removed in a future version of Bazel. |
 
 ## getenv
 
@@ -165,8 +165,8 @@ When building incrementally, any change to the value of the variable named by `n
 
 | Parameter | Description |
 | --- | --- |
-| `name` | [string](../core/string); required  Name of desired environment variable. |
-| `default` | [string](../core/string); or `None`; default is `None`  Default value to return if `name` is not found. |
+| `name` | [string](/versions/8.2.1/rules/lib/core/string); required  Name of desired environment variable. |
+| `default` | [string](/versions/8.2.1/rules/lib/core/string); or `None`; default is `None`  Default value to return if `name` is not found. |
 
 May return `None`.
 
@@ -206,9 +206,9 @@ Apply a patch file to the root directory of external repository. The patch file
 
 | Parameter | Description |
 | --- | --- |
-| `patch_file` | [string](../core/string); or [Label](../builtins/Label); or [path](../builtins/path); required  The patch file to apply, it can be label, relative path or absolute path. If it's a relative path, it will resolve to the repository directory. |
-| `strip` | [int](../core/int); default is `0`  Strip the specified number of leading components from file names. |
-| `watch_patch` | [string](../core/string); default is `'auto'`  Whether to [watch](#watch) the patch file. Can be the string 'yes', 'no', or 'auto'. Passing 'yes' is equivalent to immediately invoking the [`watch()`](#watch) method; passing 'no' does not attempt to watch the file; passing 'auto' will only attempt to watch the file when it is legal to do so (see `watch()` docs for more information. |
+| `patch_file` | [string](/versions/8.2.1/rules/lib/core/string); or [Label](/versions/8.2.1/rules/lib/builtins/Label); or [path](/versions/8.2.1/rules/lib/builtins/path); required  The patch file to apply, it can be label, relative path or absolute path. If it's a relative path, it will resolve to the repository directory. |
+| `strip` | [int](/versions/8.2.1/rules/lib/core/int); default is `0`  Strip the specified number of leading components from file names. |
+| `watch_patch` | [string](/versions/8.2.1/rules/lib/core/string); default is `'auto'`  Whether to [watch](#watch) the patch file. Can be the string 'yes', 'no', or 'auto'. Passing 'yes' is equivalent to immediately invoking the [`watch()`](#watch) method; passing 'no' does not attempt to watch the file; passing 'auto' will only attempt to watch the file when it is legal to do so (see `watch()` docs for more information. |
 
 ## path
 
@@ -222,7 +222,7 @@ Returns a path from a string, label or path. If the path is relative, it will re
 
 | Parameter | Description |
 | --- | --- |
-| `path` | [string](../core/string); or [Label](../builtins/Label); or [path](../builtins/path); required  `string`, `Label` or `path` from which to create a path from. |
+| `path` | [string](/versions/8.2.1/rules/lib/core/string); or [Label](/versions/8.2.1/rules/lib/builtins/Label); or [path](/versions/8.2.1/rules/lib/builtins/path); required  `string`, `Label` or `path` from which to create a path from. |
 
 ## read
 
@@ -236,8 +236,8 @@ Reads the content of a file on the filesystem.
 
 | Parameter | Description |
 | --- | --- |
-| `path` | [string](../core/string); or [Label](../builtins/Label); or [path](../builtins/path); required  Path of the file to read from. |
-| `watch` | [string](../core/string); default is `'auto'`  Whether to [watch](#watch) the file. Can be the string 'yes', 'no', or 'auto'. Passing 'yes' is equivalent to immediately invoking the [`watch()`](#watch) method; passing 'no' does not attempt to watch the file; passing 'auto' will only attempt to watch the file when it is legal to do so (see `watch()` docs for more information. |
+| `path` | [string](/versions/8.2.1/rules/lib/core/string); or [Label](/versions/8.2.1/rules/lib/builtins/Label); or [path](/versions/8.2.1/rules/lib/builtins/path); required  Path of the file to read from. |
+| `watch` | [string](/versions/8.2.1/rules/lib/core/string); default is `'auto'`  Whether to [watch](#watch) the file. Can be the string 'yes', 'no', or 'auto'. Passing 'yes' is equivalent to immediately invoking the [`watch()`](#watch) method; passing 'no' does not attempt to watch the file; passing 'auto' will only attempt to watch the file when it is legal to do so (see `watch()` docs for more information. |
 
 ## rename
 
@@ -252,8 +252,8 @@ already exists. Both paths must be located within the repository.
 
 | Parameter | Description |
 | --- | --- |
-| `src` | [string](../core/string); or [Label](../builtins/Label); or [path](../builtins/path); required  The path of the existing file or directory to rename, relative to the repository directory. |
-| `dst` | [string](../core/string); or [Label](../builtins/Label); or [path](../builtins/path); required  The new name to which the file or directory will be renamed to, relative to the repository directory. |
+| `src` | [string](/versions/8.2.1/rules/lib/core/string); or [Label](/versions/8.2.1/rules/lib/builtins/Label); or [path](/versions/8.2.1/rules/lib/builtins/path); required  The path of the existing file or directory to rename, relative to the repository directory. |
+| `dst` | [string](/versions/8.2.1/rules/lib/core/string); or [Label](/versions/8.2.1/rules/lib/builtins/Label); or [path](/versions/8.2.1/rules/lib/builtins/path); required  The new name to which the file or directory will be renamed to, relative to the repository directory. |
 
 ## report\_progress
 
@@ -267,7 +267,7 @@ Updates the progress status for the fetching of this repository or module extens
 
 | Parameter | Description |
 | --- | --- |
-| `status` | [string](../core/string); default is `''`  `string` describing the current status of the fetch progress. |
+| `status` | [string](/versions/8.2.1/rules/lib/core/string); default is `''`  `string` describing the current status of the fetch progress. |
 
 ## symlink
 
@@ -281,8 +281,8 @@ Creates a symlink on the filesystem.
 
 | Parameter | Description |
 | --- | --- |
-| `target` | [string](../core/string); or [Label](../builtins/Label); or [path](../builtins/path); required  The path that the symlink should point to. |
-| `link_name` | [string](../core/string); or [Label](../builtins/Label); or [path](../builtins/path); required  The path of the symlink to create. |
+| `target` | [string](/versions/8.2.1/rules/lib/core/string); or [Label](/versions/8.2.1/rules/lib/builtins/Label); or [path](/versions/8.2.1/rules/lib/builtins/path); required  The path that the symlink should point to. |
+| `link_name` | [string](/versions/8.2.1/rules/lib/core/string); or [Label](/versions/8.2.1/rules/lib/builtins/Label); or [path](/versions/8.2.1/rules/lib/builtins/path); required  The path of the symlink to create. |
 
 ## template
 
@@ -296,11 +296,11 @@ Generates a new file using a `template`. Every occurrence in `template` of a key
 
 | Parameter | Description |
 | --- | --- |
-| `path` | [string](../core/string); or [Label](../builtins/Label); or [path](../builtins/path); required  Path of the file to create, relative to the repository directory. |
-| `template` | [string](../core/string); or [Label](../builtins/Label); or [path](../builtins/path); required  Path to the template file. |
-| `substitutions` | [dict](../core/dict); default is `{}`  Substitutions to make when expanding the template. |
-| `executable` | [bool](../core/bool); default is `True`  Set the executable flag on the created file, true by default. |
-| `watch_template` | [string](../core/string); default is `'auto'`  Whether to [watch](#watch) the template file. Can be the string 'yes', 'no', or 'auto'. Passing 'yes' is equivalent to immediately invoking the [`watch()`](#watch) method; passing 'no' does not attempt to watch the file; passing 'auto' will only attempt to watch the file when it is legal to do so (see `watch()` docs for more information. |
+| `path` | [string](/versions/8.2.1/rules/lib/core/string); or [Label](/versions/8.2.1/rules/lib/builtins/Label); or [path](/versions/8.2.1/rules/lib/builtins/path); required  Path of the file to create, relative to the repository directory. |
+| `template` | [string](/versions/8.2.1/rules/lib/core/string); or [Label](/versions/8.2.1/rules/lib/builtins/Label); or [path](/versions/8.2.1/rules/lib/builtins/path); required  Path to the template file. |
+| `substitutions` | [dict](/versions/8.2.1/rules/lib/core/dict); default is `{}`  Substitutions to make when expanding the template. |
+| `executable` | [bool](/versions/8.2.1/rules/lib/core/bool); default is `True`  Set the executable flag on the created file, true by default. |
+| `watch_template` | [string](/versions/8.2.1/rules/lib/core/string); default is `'auto'`  Whether to [watch](#watch) the template file. Can be the string 'yes', 'no', or 'auto'. Passing 'yes' is equivalent to immediately invoking the [`watch()`](#watch) method; passing 'no' does not attempt to watch the file; passing 'auto' will only attempt to watch the file when it is legal to do so (see `watch()` docs for more information. |
 
 ## watch
 
@@ -310,7 +310,7 @@ None repository_ctx.watch(path)
 
 Tells Bazel to watch for changes to the given path, whether or not it exists, or whether it's a file or a directory. Any changes to the file or directory will invalidate this repository or module extension, and cause it to be refetched or re-evaluated next time.
 
-"Changes" include changes to the contents of the file (if the path is a file); if the path was a file but is now a directory, or vice versa; and if the path starts or stops existing. Notably, this does *not* include changes to any files under the directory if the path is a directory. For that, use [`path.readdir()`](path#readdir) instead.
+"Changes" include changes to the contents of the file (if the path is a file); if the path was a file but is now a directory, or vice versa; and if the path starts or stops existing. Notably, this does *not* include changes to any files under the directory if the path is a directory. For that, use [`path.readdir()`](/versions/8.2.1/rules/lib/builtins/path#readdir) instead.
 
 Note that attempting to watch paths inside the repo currently being fetched, or inside the working directory of the current module extension, will result in an error. A module extension attempting to watch a path outside the current Bazel workspace will also result in an error.
 
@@ -318,7 +318,7 @@ Note that attempting to watch paths inside the repo currently being fetched, or
 
 | Parameter | Description |
 | --- | --- |
-| `path` | [string](../core/string); or [Label](../builtins/Label); or [path](../builtins/path); required  Path of the file to watch. |
+| `path` | [string](/versions/8.2.1/rules/lib/core/string); or [Label](/versions/8.2.1/rules/lib/builtins/Label); or [path](/versions/8.2.1/rules/lib/builtins/path); required  Path of the file to watch. |
 
 ## watch\_tree
 
@@ -334,7 +334,7 @@ Note that attempting to watch paths inside the repo currently being fetched will
 
 | Parameter | Description |
 | --- | --- |
-| `path` | [string](../core/string); or [Label](../builtins/Label); or [path](../builtins/path); required  Path of the directory tree to watch. |
+| `path` | [string](/versions/8.2.1/rules/lib/core/string); or [Label](/versions/8.2.1/rules/lib/builtins/Label); or [path](/versions/8.2.1/rules/lib/builtins/path); required  Path of the directory tree to watch. |
 
 ## which
 
@@ -348,7 +348,7 @@ Returns the `path` of the corresponding program or `None` if there is no such pr
 
 | Parameter | Description |
 | --- | --- |
-| `program` | [string](../core/string); required  Program to find in the path. |
+| `program` | [string](/versions/8.2.1/rules/lib/core/string); required  Program to find in the path. |
 
 May return `None`.
 
diff --git a/versions/8.2.1/rules/lib/builtins/repository_rule.mdx b/versions/8.2.1/rules/lib/builtins/repository_rule.mdx
index ef5dac59..68468b56 100644
--- a/versions/8.2.1/rules/lib/builtins/repository_rule.mdx
+++ b/versions/8.2.1/rules/lib/builtins/repository_rule.mdx
@@ -2,4 +2,4 @@
 title: 'repository\_rule'
 ---
 
-A callable value that may be invoked during evaluation of the WORKSPACE file or within the implementation function of a module extension to instantiate and return a repository rule. Created by [`repository_rule()`](../globals/bzl#repository_rule).
\ No newline at end of file
+A callable value that may be invoked during evaluation of the WORKSPACE file or within the implementation function of a module extension to instantiate and return a repository rule. Created by [`repository_rule()`](/versions/8.2.1/rules/lib/globals/bzl#repository_rule).
\ No newline at end of file
diff --git a/versions/8.2.1/rules/lib/builtins/rule.mdx b/versions/8.2.1/rules/lib/builtins/rule.mdx
index 53f72a16..e2ba74e6 100644
--- a/versions/8.2.1/rules/lib/builtins/rule.mdx
+++ b/versions/8.2.1/rules/lib/builtins/rule.mdx
@@ -3,7 +3,7 @@ title: 'rule'
 ---
 
 A callable value representing the type of a native or Starlark rule (created by
-[`rule()`](../globals/bzl#rule)). Calling the value during
+[`rule()`](/versions/8.2.1/rules/lib/globals/bzl#rule)). Calling the value during
 evaluation of a package's BUILD file creates an instance of the rule and adds it to the
 package's target set. For more information, visit this page about
 [Rules](https://bazel.build/versions/8.2.1/extending/rules).
\ No newline at end of file
diff --git a/versions/8.2.1/rules/lib/builtins/rule_attributes.mdx b/versions/8.2.1/rules/lib/builtins/rule_attributes.mdx
index 046b21a5..3c3b2fe8 100644
--- a/versions/8.2.1/rules/lib/builtins/rule_attributes.mdx
+++ b/versions/8.2.1/rules/lib/builtins/rule_attributes.mdx
@@ -20,7 +20,7 @@ Information about attributes of a rule an aspect is applied to.
 struct rule_attributes.attr
 ```
 
-A struct to access the values of the [attributes](https://bazel.build/versions/8.2.1/extending/rules#attributes). The values are provided by the user (if not, a default value is used). The attributes of the struct and the types of their values correspond to the keys and values of the [`attrs` dict](../globals/bzl#rule.attrs) provided to the [`rule` function](../globals/bzl#rule). [See example of use](https://github.com/bazelbuild/examples/blob/main/rules/attributes/printer.bzl).
+A struct to access the values of the [attributes](https://bazel.build/versions/8.2.1/extending/rules#attributes). The values are provided by the user (if not, a default value is used). The attributes of the struct and the types of their values correspond to the keys and values of the [`attrs` dict](/versions/8.2.1/rules/lib/globals/bzl#rule.attrs) provided to the [`rule` function](/versions/8.2.1/rules/lib/globals/bzl#rule). [See example of use](https://github.com/bazelbuild/examples/blob/main/rules/attributes/printer.bzl).
 
 ## exec\_groups
 
@@ -36,7 +36,7 @@ A collection of the execution groups available for the rule the aspect is applie
 struct rule_attributes.executable
 ```
 
-A `struct` containing executable files defined in [label type attributes](../toplevel/attr#label) marked as [`executable=True`](../toplevel/attr#label.executable). The struct fields correspond to the attribute names. Each value in the struct is either a [`File`](../builtins/File) or `None`. If an optional attribute is not specified in the rule then the corresponding struct value is `None`. If a label type is not marked as `executable=True`, no corresponding struct field is generated. [See example of use](https://github.com/bazelbuild/examples/blob/main/rules/actions_run/execute.bzl).
+A `struct` containing executable files defined in [label type attributes](/versions/8.2.1/rules/lib/toplevel/attr#label) marked as [`executable=True`](/versions/8.2.1/rules/lib/toplevel/attr#label.executable). The struct fields correspond to the attribute names. Each value in the struct is either a [`File`](/versions/8.2.1/rules/lib/builtins/File) or `None`. If an optional attribute is not specified in the rule then the corresponding struct value is `None`. If a label type is not marked as `executable=True`, no corresponding struct field is generated. [See example of use](https://github.com/bazelbuild/examples/blob/main/rules/actions_run/execute.bzl).
 
 ## file
 
@@ -44,7 +44,7 @@ A `struct` containing executable files defined in [label type attributes](../top
 struct rule_attributes.file
 ```
 
-A `struct` containing files defined in [label type attributes](../toplevel/attr#label) marked as [`allow_single_file`](../toplevel/attr#label.allow_single_file). The struct fields correspond to the attribute names. The struct value is always a [`File`](../builtins/File) or `None`. If an optional attribute is not specified in the rule then the corresponding struct value is `None`. If a label type is not marked as `allow_single_file`, no corresponding struct field is generated. It is a shortcut for:
+A `struct` containing files defined in [label type attributes](/versions/8.2.1/rules/lib/toplevel/attr#label) marked as [`allow_single_file`](/versions/8.2.1/rules/lib/toplevel/attr#label.allow_single_file). The struct fields correspond to the attribute names. The struct value is always a [`File`](/versions/8.2.1/rules/lib/builtins/File) or `None`. If an optional attribute is not specified in the rule then the corresponding struct value is `None`. If a label type is not marked as `allow_single_file`, no corresponding struct field is generated. It is a shortcut for:
 
 ```
 list(ctx.attr..files)[0]
@@ -58,7 +58,7 @@ In other words, use `file` to access the (singular) [default output](https://baz
 struct rule_attributes.files
 ```
 
-A `struct` containing files defined in [label](../toplevel/attr#label) or [label list](../toplevel/attr#label_list) type attributes. The struct fields correspond to the attribute names. The struct values are `list` of [`File`](../builtins/File)s. It is a shortcut for:
+A `struct` containing files defined in [label](/versions/8.2.1/rules/lib/toplevel/attr#label) or [label list](/versions/8.2.1/rules/lib/toplevel/attr#label_list) type attributes. The struct fields correspond to the attribute names. The struct values are `list` of [`File`](/versions/8.2.1/rules/lib/builtins/File)s. It is a shortcut for:
 
 ```
 [f for t in ctx.attr. for f in t.files]
diff --git a/versions/8.2.1/rules/lib/builtins/runfiles.mdx b/versions/8.2.1/rules/lib/builtins/runfiles.mdx
index d2183c4f..695ef5da 100644
--- a/versions/8.2.1/rules/lib/builtins/runfiles.mdx
+++ b/versions/8.2.1/rules/lib/builtins/runfiles.mdx
@@ -2,7 +2,7 @@
 title: 'runfiles'
 ---
 
-A container of information regarding a set of files required at runtime execution. This object should be passed via [DefaultInfo](../providers/DefaultInfo) in order to tell the build system about the runfiles needed by the outputs produced by the rule.
+A container of information regarding a set of files required at runtime execution. This object should be passed via [DefaultInfo](/versions/8.2.1/rules/lib/providers/DefaultInfo) in order to tell the build system about the runfiles needed by the outputs produced by the rule.
 
 See [runfiles guide](https://bazel.build/versions/8.2.1/extending/rules#runfiles) for details.
 
@@ -45,7 +45,7 @@ Returns a new runfiles object that includes all the contents of this one and the
 
 | Parameter | Description |
 | --- | --- |
-| `other` | [runfiles](../builtins/runfiles); required  The runfiles object to merge into this. |
+| `other` | [runfiles](/versions/8.2.1/rules/lib/builtins/runfiles); required  The runfiles object to merge into this. |
 
 ## merge\_all
 
@@ -59,7 +59,7 @@ Returns a new runfiles object that includes all the contents of this one and of
 
 | Parameter | Description |
 | --- | --- |
-| `other` | [sequence](../core/list) of [runfiles](../builtins/runfiles)s; required  The sequence of runfiles objects to merge into this. |
+| `other` | [sequence](/versions/8.2.1/rules/lib/core/list) of [runfiles](/versions/8.2.1/rules/lib/builtins/runfiles)s; required  The sequence of runfiles objects to merge into this. |
 
 ## root\_symlinks
 
diff --git a/versions/8.2.1/rules/lib/builtins/tag_class.mdx b/versions/8.2.1/rules/lib/builtins/tag_class.mdx
index 7d4349d0..f2ad30d3 100644
--- a/versions/8.2.1/rules/lib/builtins/tag_class.mdx
+++ b/versions/8.2.1/rules/lib/builtins/tag_class.mdx
@@ -2,4 +2,4 @@
 title: 'tag\_class'
 ---
 
-Defines a schema of attributes for a tag, created by [`tag_class()`](../globals/bzl#tag_class).
\ No newline at end of file
+Defines a schema of attributes for a tag, created by [`tag_class()`](/versions/8.2.1/rules/lib/globals/bzl#tag_class).
\ No newline at end of file
diff --git a/versions/8.2.1/rules/lib/builtins/transition.mdx b/versions/8.2.1/rules/lib/builtins/transition.mdx
index 297dfee7..96fdde40 100644
--- a/versions/8.2.1/rules/lib/builtins/transition.mdx
+++ b/versions/8.2.1/rules/lib/builtins/transition.mdx
@@ -39,5 +39,5 @@ For more details see [here](https://bazel.build/versions/8.2.1/rules/config#user
 | Parameter | Description |
 | --- | --- |
 | `implementation` | callable; required  The function implementing this transition. This function always has two parameters: `settings` and `attr`. The `settings` param is a dictionary whose set of keys is defined by the inputs parameter. So, for each build setting `--//foo=bar`, if `inputs` contains `//foo`, `settings` will have an entry `settings['//foo']='bar'`. The `attr` param is a reference to `ctx.attr`. This gives the implementation function access to the rule's attributes to make attribute-parameterized transitions possible. This function must return a `dict` from build setting identifier to build setting value; this represents the configuration transition: for each entry in the returned `dict`, the transition updates that setting to the new value. All other settings are unchanged. This function can also return a `list` of `dict`s or a `dict` of `dict`s in the case of a split transition. |
-| `inputs` | [sequence](../core/list) of [string](../core/string)s; required  List of build settings that can be read by this transition. This becomes the key set of the settings parameter of the implementation function parameter. |
-| `outputs` | [sequence](../core/list) of [string](../core/string)s; required  List of build settings that can be written by this transition. This must be a superset of the key set of the dictionary returned by this transition. |
\ No newline at end of file
+| `inputs` | [sequence](/versions/8.2.1/rules/lib/core/list) of [string](/versions/8.2.1/rules/lib/core/string)s; required  List of build settings that can be read by this transition. This becomes the key set of the settings parameter of the implementation function parameter. |
+| `outputs` | [sequence](/versions/8.2.1/rules/lib/core/list) of [string](/versions/8.2.1/rules/lib/core/string)s; required  List of build settings that can be written by this transition. This must be a superset of the key set of the dictionary returned by this transition. |
\ No newline at end of file
diff --git a/versions/8.2.1/rules/lib/core/bool.mdx b/versions/8.2.1/rules/lib/core/bool.mdx
index 52be3664..2b5ddb91 100644
--- a/versions/8.2.1/rules/lib/core/bool.mdx
+++ b/versions/8.2.1/rules/lib/core/bool.mdx
@@ -2,4 +2,4 @@
 title: 'bool'
 ---
 
-A type to represent booleans. There are only two possible values: True and False. Any value can be converted to a boolean using the [bool](../globals/all#bool) function.
\ No newline at end of file
+A type to represent booleans. There are only two possible values: True and False. Any value can be converted to a boolean using the [bool](/versions/8.2.1/rules/lib/globals/all#bool) function.
\ No newline at end of file
diff --git a/versions/8.2.1/rules/lib/core/dict.mdx b/versions/8.2.1/rules/lib/core/dict.mdx
index 9005668c..fe67714a 100644
--- a/versions/8.2.1/rules/lib/core/dict.mdx
+++ b/versions/8.2.1/rules/lib/core/dict.mdx
@@ -22,7 +22,7 @@ There are four ways to construct a dictionary:
      {i: 2*i for i in range(3)}  # {0: 0, 1: 2, 2: 4}
      ```
 
-     - A call to the built-in [dict](../globals/all#dict) function returns a dictionary containing the specified entries, which are inserted in argument order, positional arguments before named. As with comprehensions, duplicate keys are permitted.- The union expression `x | y` yields a new dictionary by combining two existing dictionaries. If the two dictionaries have a key `k` in common, the right hand side dictionary's value of the key (in other words, `y[k]`) wins. The `|=` variant of the union operator modifies a dictionary in-place. Example:
+     - A call to the built-in [dict](/versions/8.2.1/rules/lib/globals/all#dict) function returns a dictionary containing the specified entries, which are inserted in argument order, positional arguments before named. As with comprehensions, duplicate keys are permitted.- The union expression `x | y` yields a new dictionary by combining two existing dictionaries. If the two dictionaries have a key `k` in common, the right hand side dictionary's value of the key (in other words, `y[k]`) wins. The `|=` variant of the union operator modifies a dictionary in-place. Example:
 
          ```
          d = {"foo": "FOO", "bar": "BAR"} | {"foo": "FOO2", "baz": "BAZ"}
diff --git a/versions/8.2.1/rules/lib/core/json.mdx b/versions/8.2.1/rules/lib/core/json.mdx
index 0bb00e3e..2a58c098 100644
--- a/versions/8.2.1/rules/lib/core/json.mdx
+++ b/versions/8.2.1/rules/lib/core/json.mdx
@@ -29,7 +29,7 @@ If `x` is not a valid JSON encoding and the optional `default` parameter is *not
 
 | Parameter | Description |
 | --- | --- |
-| `x` | [string](../core/string); required  JSON string to decode. |
+| `x` | [string](/versions/8.2.1/rules/lib/core/string); required  JSON string to decode. |
 | `default` | default is `unbound`  If specified, the value to return when `x` cannot be decoded. |
 
 ## encode
@@ -64,8 +64,8 @@ The encode\_indent function is equivalent to `json.indent(json.encode(x), ...)`.
 | Parameter | Description |
 | --- | --- |
 | `x` | required |
-| `prefix` | [string](../core/string); default is `''` |
-| `indent` | [string](../core/string); default is `'\t'` |
+| `prefix` | [string](/versions/8.2.1/rules/lib/core/string); default is `''` |
+| `indent` | [string](/versions/8.2.1/rules/lib/core/string); default is `'\t'` |
 
 ## indent
 
@@ -84,6 +84,6 @@ If the input is not valid, the function may fail or return invalid output.
 
 | Parameter | Description |
 | --- | --- |
-| `s` | [string](../core/string); required |
-| `prefix` | [string](../core/string); default is `''` |
-| `indent` | [string](../core/string); default is `'\t'` |
\ No newline at end of file
+| `s` | [string](/versions/8.2.1/rules/lib/core/string); required |
+| `prefix` | [string](/versions/8.2.1/rules/lib/core/string); default is `''` |
+| `indent` | [string](/versions/8.2.1/rules/lib/core/string); default is `'\t'` |
\ No newline at end of file
diff --git a/versions/8.2.1/rules/lib/core/list.mdx b/versions/8.2.1/rules/lib/core/list.mdx
index c19e9780..ffad0a55 100644
--- a/versions/8.2.1/rules/lib/core/list.mdx
+++ b/versions/8.2.1/rules/lib/core/list.mdx
@@ -91,8 +91,8 @@ Returns the index in the list of the first item whose value is x. It is an error
 | Parameter | Description |
 | --- | --- |
 | `x` | required |
-| `start` | [int](../core/int); or `None`; default is `None`  The start index of the list portion to inspect. |
-| `end` | [int](../core/int); or `None`; default is `None`  The end index of the list portion to inspect. |
+| `start` | [int](/versions/8.2.1/rules/lib/core/int); or `None`; default is `None`  The start index of the list portion to inspect. |
+| `end` | [int](/versions/8.2.1/rules/lib/core/int); or `None`; default is `None`  The end index of the list portion to inspect. |
 
 ## insert
 
@@ -106,7 +106,7 @@ Inserts an item at a given position.
 
 | Parameter | Description |
 | --- | --- |
-| `index` | [int](../core/int); required  The index of the given position. |
+| `index` | [int](/versions/8.2.1/rules/lib/core/int); required  The index of the given position. |
 | `item` | required  The item. |
 
 ## pop
@@ -121,7 +121,7 @@ Removes the item at the given position in the list, and returns it. If no `index
 
 | Parameter | Description |
 | --- | --- |
-| `i` | [int](../core/int); or `None`; default is `-1`  The index of the item. |
+| `i` | [int](/versions/8.2.1/rules/lib/core/int); or `None`; default is `-1`  The index of the item. |
 
 ## remove
 
diff --git a/versions/8.2.1/rules/lib/core/set.mdx b/versions/8.2.1/rules/lib/core/set.mdx
index aeb3b202..420b31bd 100644
--- a/versions/8.2.1/rules/lib/core/set.mdx
+++ b/versions/8.2.1/rules/lib/core/set.mdx
@@ -3,14 +3,14 @@ title: 'set'
 ---
 
 The built-in set type. A set is a mutable, iterable collection of unique values – the set's
-*elements*. The [type name](../globals/all#type) of a set is `"set"`.
+*elements*. The [type name](/versions/8.2.1/rules/lib/globals/all#type) of a set is `"set"`.
 
 Sets provide constant-time operations to insert, remove, or check for the presence of a value.
 Sets are implemented using a hash table, and therefore, just like keys of a
-[dictionary](../dict), elements of a set must be hashable. A value may be used as an
+[dictionary](/versions/8.2.1/rules/lib/core/dict), elements of a set must be hashable. A value may be used as an
 element of a set if and only if it may be used as a key of a dictionary.
 
-Sets may be constructed using the [`set()`](../globals/all#set) built-in
+Sets may be constructed using the [`set()`](/versions/8.2.1/rules/lib/globals/all#set) built-in
 function, which returns a new set containing the unique elements of its optional argument, which
 must be an iterable. Calling `set()` without an argument constructs an empty set. Sets
 have no literal syntax.
@@ -26,7 +26,7 @@ s = set(["a", "b", "c"])
 
 A set is iterable, and thus may be used as the operand of a `for` loop, a list
 comprehension, and the various built-in functions that operate on iterables. Its length can be
-retrieved using the [`len()`](../globals/all#len) built-in function, and the
+retrieved using the [`len()`](/versions/8.2.1/rules/lib/globals/all#len) built-in function, and the
 order of iteration is the order in which elements were first added to the set:
 
 ```
diff --git a/versions/8.2.1/rules/lib/core/string.mdx b/versions/8.2.1/rules/lib/core/string.mdx
index 1673c6e4..d980dadc 100644
--- a/versions/8.2.1/rules/lib/core/string.mdx
+++ b/versions/8.2.1/rules/lib/core/string.mdx
@@ -81,9 +81,9 @@ Returns the number of (non-overlapping) occurrences of substring `sub` in string
 
 | Parameter | Description |
 | --- | --- |
-| `sub` | [string](../core/string); required |
-| `start` | [int](../core/int); or `None`; default is `0` |
-| `end` | [int](../core/int); or `None`; default is `None`  optional position before which to restrict to search. |
+| `sub` | [string](/versions/8.2.1/rules/lib/core/string); required |
+| `start` | [int](/versions/8.2.1/rules/lib/core/int); or `None`; default is `0` |
+| `end` | [int](/versions/8.2.1/rules/lib/core/int); or `None`; default is `None`  optional position before which to restrict to search. |
 
 ## elems
 
@@ -105,9 +105,9 @@ Returns True if the string ends with `sub`, otherwise False, optionally restrict
 
 | Parameter | Description |
 | --- | --- |
-| `sub` | [string](../core/string); or [tuple](../core/tuple) of [string](../core/string)s; required  The suffix (or tuple of alternative suffixes) to match. |
-| `start` | [int](../core/int); or `None`; default is `0`  Test beginning at this position. |
-| `end` | [int](../core/int); or `None`; default is `None`  optional position at which to stop comparing. |
+| `sub` | [string](/versions/8.2.1/rules/lib/core/string); or [tuple](/versions/8.2.1/rules/lib/core/tuple) of [string](/versions/8.2.1/rules/lib/core/string)s; required  The suffix (or tuple of alternative suffixes) to match. |
+| `start` | [int](/versions/8.2.1/rules/lib/core/int); or `None`; default is `0`  Test beginning at this position. |
+| `end` | [int](/versions/8.2.1/rules/lib/core/int); or `None`; default is `None`  optional position at which to stop comparing. |
 
 ## find
 
@@ -121,9 +121,9 @@ Returns the first index where `sub` is found, or -1 if no such index exists, opt
 
 | Parameter | Description |
 | --- | --- |
-| `sub` | [string](../core/string); required  The substring to find. |
-| `start` | [int](../core/int); or `None`; default is `0`  Restrict to search from this position. |
-| `end` | [int](../core/int); or `None`; default is `None`  optional position before which to restrict to search. |
+| `sub` | [string](/versions/8.2.1/rules/lib/core/string); required  The substring to find. |
+| `start` | [int](/versions/8.2.1/rules/lib/core/int); or `None`; default is `0`  Restrict to search from this position. |
+| `end` | [int](/versions/8.2.1/rules/lib/core/int); or `None`; default is `None`  optional position before which to restrict to search. |
 
 ## format
 
@@ -131,7 +131,7 @@ Returns the first index where `sub` is found, or -1 if no such index exists, opt
 string string.format(*args, **kwargs)
 ```
 
-Perform string interpolation. Format strings contain replacement fields surrounded by curly braces `{}`. Anything that is not contained in braces is considered literal text, which is copied unchanged to the output.If you need to include a brace character in the literal text, it can be escaped by doubling: `{{` and `}}`A replacement field can be either a name, a number, or empty. Values are converted to strings using the [str](../globals/all#str) function.
+Perform string interpolation. Format strings contain replacement fields surrounded by curly braces `{}`. Anything that is not contained in braces is considered literal text, which is copied unchanged to the output.If you need to include a brace character in the literal text, it can be escaped by doubling: `{{` and `}}`A replacement field can be either a name, a number, or empty. Values are converted to strings using the [str](/versions/8.2.1/rules/lib/globals/all#str) function.
 
 ```
 # Access in order:
@@ -161,9 +161,9 @@ Returns the first index where `sub` is found, or raises an error if no such inde
 
 | Parameter | Description |
 | --- | --- |
-| `sub` | [string](../core/string); required  The substring to find. |
-| `start` | [int](../core/int); or `None`; default is `0`  Restrict to search from this position. |
-| `end` | [int](../core/int); or `None`; default is `None`  optional position before which to restrict to search. |
+| `sub` | [string](/versions/8.2.1/rules/lib/core/string); required  The substring to find. |
+| `start` | [int](/versions/8.2.1/rules/lib/core/int); or `None`; default is `0`  Restrict to search from this position. |
+| `end` | [int](/versions/8.2.1/rules/lib/core/int); or `None`; default is `None`  optional position before which to restrict to search. |
 
 ## isalnum
 
@@ -263,7 +263,7 @@ Returns a copy of the string where leading characters that appear in `chars` are
 
 | Parameter | Description |
 | --- | --- |
-| `chars` | [string](../core/string); or `None`; default is `None`  The characters to remove, or all whitespace if None. |
+| `chars` | [string](/versions/8.2.1/rules/lib/core/string); or `None`; default is `None`  The characters to remove, or all whitespace if None. |
 
 ## partition
 
@@ -277,7 +277,7 @@ Splits the input string at the first occurrence of the separator `sep` and retur
 
 | Parameter | Description |
 | --- | --- |
-| `sep` | [string](../core/string); required  The string to split on. |
+| `sep` | [string](/versions/8.2.1/rules/lib/core/string); required  The string to split on. |
 
 ## removeprefix
 
@@ -291,7 +291,7 @@ If the string starts with `prefix`, returns a new string with the prefix removed
 
 | Parameter | Description |
 | --- | --- |
-| `prefix` | [string](../core/string); required  The prefix to remove if present. |
+| `prefix` | [string](/versions/8.2.1/rules/lib/core/string); required  The prefix to remove if present. |
 
 ## removesuffix
 
@@ -305,7 +305,7 @@ If the string ends with `suffix`, returns a new string with the suffix removed.
 
 | Parameter | Description |
 | --- | --- |
-| `suffix` | [string](../core/string); required  The suffix to remove if present. |
+| `suffix` | [string](/versions/8.2.1/rules/lib/core/string); required  The suffix to remove if present. |
 
 ## replace
 
@@ -319,9 +319,9 @@ Returns a copy of the string in which the occurrences of `old` have been replace
 
 | Parameter | Description |
 | --- | --- |
-| `old` | [string](../core/string); required  The string to be replaced. |
-| `new` | [string](../core/string); required  The string to replace with. |
-| `count` | [int](../core/int); default is `-1`  The maximum number of replacements. If omitted, or if the value is negative, there is no limit. |
+| `old` | [string](/versions/8.2.1/rules/lib/core/string); required  The string to be replaced. |
+| `new` | [string](/versions/8.2.1/rules/lib/core/string); required  The string to replace with. |
+| `count` | [int](/versions/8.2.1/rules/lib/core/int); default is `-1`  The maximum number of replacements. If omitted, or if the value is negative, there is no limit. |
 
 ## rfind
 
@@ -335,9 +335,9 @@ Returns the last index where `sub` is found, or -1 if no such index exists, opti
 
 | Parameter | Description |
 | --- | --- |
-| `sub` | [string](../core/string); required  The substring to find. |
-| `start` | [int](../core/int); or `None`; default is `0`  Restrict to search from this position. |
-| `end` | [int](../core/int); or `None`; default is `None`  optional position before which to restrict to search. |
+| `sub` | [string](/versions/8.2.1/rules/lib/core/string); required  The substring to find. |
+| `start` | [int](/versions/8.2.1/rules/lib/core/int); or `None`; default is `0`  Restrict to search from this position. |
+| `end` | [int](/versions/8.2.1/rules/lib/core/int); or `None`; default is `None`  optional position before which to restrict to search. |
 
 ## rindex
 
@@ -351,9 +351,9 @@ Returns the last index where `sub` is found, or raises an error if no such index
 
 | Parameter | Description |
 | --- | --- |
-| `sub` | [string](../core/string); required  The substring to find. |
-| `start` | [int](../core/int); or `None`; default is `0`  Restrict to search from this position. |
-| `end` | [int](../core/int); or `None`; default is `None`  optional position before which to restrict to search. |
+| `sub` | [string](/versions/8.2.1/rules/lib/core/string); required  The substring to find. |
+| `start` | [int](/versions/8.2.1/rules/lib/core/int); or `None`; default is `0`  Restrict to search from this position. |
+| `end` | [int](/versions/8.2.1/rules/lib/core/int); or `None`; default is `None`  optional position before which to restrict to search. |
 
 ## rpartition
 
@@ -367,7 +367,7 @@ Splits the input string at the last occurrence of the separator `sep` and return
 
 | Parameter | Description |
 | --- | --- |
-| `sep` | [string](../core/string); required  The string to split on. |
+| `sep` | [string](/versions/8.2.1/rules/lib/core/string); required  The string to split on. |
 
 ## rsplit
 
@@ -381,8 +381,8 @@ Returns a list of all the words in the string, using `sep` as the separator, opt
 
 | Parameter | Description |
 | --- | --- |
-| `sep` | [string](../core/string); required  The string to split on. |
-| `maxsplit` | [int](../core/int); or `None`; default is `None`  The maximum number of splits. |
+| `sep` | [string](/versions/8.2.1/rules/lib/core/string); required  The string to split on. |
+| `maxsplit` | [int](/versions/8.2.1/rules/lib/core/int); or `None`; default is `None`  The maximum number of splits. |
 
 ## rstrip
 
@@ -400,7 +400,7 @@ Returns a copy of the string where trailing characters that appear in `chars` ar
 
 | Parameter | Description |
 | --- | --- |
-| `chars` | [string](../core/string); or `None`; default is `None`  The characters to remove, or all whitespace if None. |
+| `chars` | [string](/versions/8.2.1/rules/lib/core/string); or `None`; default is `None`  The characters to remove, or all whitespace if None. |
 
 ## split
 
@@ -414,8 +414,8 @@ Returns a list of all the words in the string, using `sep` as the separator, opt
 
 | Parameter | Description |
 | --- | --- |
-| `sep` | [string](../core/string); required  The string to split on. |
-| `maxsplit` | [int](../core/int); or `None`; default is `None`  The maximum number of splits. |
+| `sep` | [string](/versions/8.2.1/rules/lib/core/string); required  The string to split on. |
+| `maxsplit` | [int](/versions/8.2.1/rules/lib/core/int); or `None`; default is `None`  The maximum number of splits. |
 
 ## splitlines
 
@@ -429,7 +429,7 @@ Splits the string at line boundaries ('\n', '\r\n', '\r') and returns the result
 
 | Parameter | Description |
 | --- | --- |
-| `keepends` | [bool](../core/bool); default is `False`  Whether the line breaks should be included in the resulting list. |
+| `keepends` | [bool](/versions/8.2.1/rules/lib/core/bool); default is `False`  Whether the line breaks should be included in the resulting list. |
 
 ## startswith
 
@@ -443,9 +443,9 @@ Returns True if the string starts with `sub`, otherwise False, optionally restri
 
 | Parameter | Description |
 | --- | --- |
-| `sub` | [string](../core/string); or [tuple](../core/tuple) of [string](../core/string)s; required  The prefix (or tuple of alternative prefixes) to match. |
-| `start` | [int](../core/int); or `None`; default is `0`  Test beginning at this position. |
-| `end` | [int](../core/int); or `None`; default is `None`  Stop comparing at this position. |
+| `sub` | [string](/versions/8.2.1/rules/lib/core/string); or [tuple](/versions/8.2.1/rules/lib/core/tuple) of [string](/versions/8.2.1/rules/lib/core/string)s; required  The prefix (or tuple of alternative prefixes) to match. |
+| `start` | [int](/versions/8.2.1/rules/lib/core/int); or `None`; default is `0`  Test beginning at this position. |
+| `end` | [int](/versions/8.2.1/rules/lib/core/int); or `None`; default is `None`  Stop comparing at this position. |
 
 ## strip
 
@@ -463,7 +463,7 @@ Returns a copy of the string where leading or trailing characters that appear in
 
 | Parameter | Description |
 | --- | --- |
-| `chars` | [string](../core/string); or `None`; default is `None`  The characters to remove, or all whitespace if None. |
+| `chars` | [string](/versions/8.2.1/rules/lib/core/string); or `None`; default is `None`  The characters to remove, or all whitespace if None. |
 
 ## title
 
diff --git a/versions/8.2.1/rules/lib/fragments.mdx b/versions/8.2.1/rules/lib/fragments.mdx
index cecfe864..4876e9be 100644
--- a/versions/8.2.1/rules/lib/fragments.mdx
+++ b/versions/8.2.1/rules/lib/fragments.mdx
@@ -2,7 +2,7 @@
 title: 'Configuration Fragments'
 ---
 
-Configuration fragments give rules access to language-specific parts of [configuration](builtins/configuration).
+Configuration fragments give rules access to language-specific parts of [configuration](/versions/8.2.1/rules/lib/builtins/configuration).
 
 Rule implementations can get them using `ctx.fragments.[fragment name]`
 
diff --git a/versions/8.2.1/rules/lib/fragments/apple.mdx b/versions/8.2.1/rules/lib/fragments/apple.mdx
index f7e8daff..159ce54b 100644
--- a/versions/8.2.1/rules/lib/fragments/apple.mdx
+++ b/versions/8.2.1/rules/lib/fragments/apple.mdx
@@ -22,7 +22,7 @@ The platform of the current configuration for the given platform type. This shou
 
 | Parameter | Description |
 | --- | --- |
-| `platform_type` | [string](../core/string); required  The apple platform type. |
+| `platform_type` | [string](/versions/8.2.1/rules/lib/core/string); required  The apple platform type. |
 
 ## single\_arch\_cpu
 
diff --git a/versions/8.2.1/rules/lib/fragments/coverage.mdx b/versions/8.2.1/rules/lib/fragments/coverage.mdx
index bc20f828..b3b7d794 100644
--- a/versions/8.2.1/rules/lib/fragments/coverage.mdx
+++ b/versions/8.2.1/rules/lib/fragments/coverage.mdx
@@ -14,7 +14,7 @@ A configuration fragment representing the coverage configuration.
 Label coverage.output_generator
 ```
 
-Returns the label pointed to by the [`--coverage_output_generator`](https://bazel.build/versions/8.2.1/reference/command-line-reference#flag--coverage_output_generator) option if coverage collection is enabled, otherwise returns `None`. Can be accessed with [`configuration_field`](../globals/bzl#configuration_field):
+Returns the label pointed to by the [`--coverage_output_generator`](https://bazel.build/versions/8.2.1/reference/command-line-reference#flag--coverage_output_generator) option if coverage collection is enabled, otherwise returns `None`. Can be accessed with [`configuration_field`](/versions/8.2.1/rules/lib/globals/bzl#configuration_field):
 
 ```
 attr.label(
diff --git a/versions/8.2.1/rules/lib/fragments/cpp.mdx b/versions/8.2.1/rules/lib/fragments/cpp.mdx
index 475af257..f2e6e1fa 100644
--- a/versions/8.2.1/rules/lib/fragments/cpp.mdx
+++ b/versions/8.2.1/rules/lib/fragments/cpp.mdx
@@ -46,7 +46,7 @@ The flags passed to Bazel by [`--copt`](/versions/8.2.1/docs/user-manual#flag--c
 Label cpp.custom_malloc
 ```
 
-Returns label pointed to by [`--custom_malloc`](/versions/8.2.1/docs/user-manual#flag--custom_malloc) option. Can be accessed with [`configuration_field`](../globals/bzl#configuration_field):
+Returns label pointed to by [`--custom_malloc`](/versions/8.2.1/docs/user-manual#flag--custom_malloc) option. Can be accessed with [`configuration_field`](/versions/8.2.1/rules/lib/globals/bzl#configuration_field):
 
 ```
 attr.label(
diff --git a/versions/8.2.1/rules/lib/globals/all.mdx b/versions/8.2.1/rules/lib/globals/all.mdx
index 45106d41..7da1e264 100644
--- a/versions/8.2.1/rules/lib/globals/all.mdx
+++ b/versions/8.2.1/rules/lib/globals/all.mdx
@@ -50,7 +50,7 @@ abs(-2.3) == 2.3
 
 | Parameter | Description |
 | --- | --- |
-| `x` | [int](../core/int); or [float](../core/float); required  A number (int or float) |
+| `x` | [int](/versions/8.2.1/rules/lib/core/int); or [float](/versions/8.2.1/rules/lib/core/float); required  A number (int or float) |
 
 ## all
 
@@ -110,7 +110,7 @@ Constructor for the bool type. It returns `False` if the object is `None`, `Fals
 dict dict(pairs=[], **kwargs)
 ```
 
-Creates a [dictionary](../core/dict) from an optional positional argument and an optional set of keyword arguments. In the case where the same key is given multiple times, the last value will be used. Entries supplied via keyword arguments are considered to come after entries supplied via the positional argument.
+Creates a [dictionary](/versions/8.2.1/rules/lib/core/dict) from an optional positional argument and an optional set of keyword arguments. In the case where the same key is given multiple times, the last value will be used. Entries supplied via keyword arguments are considered to come after entries supplied via the positional argument.
 
 ### Parameters
 
@@ -150,7 +150,7 @@ enumerate([24, 21, 84]) == [(0, 24), (1, 21), (2, 84)]
 | Parameter | Description |
 | --- | --- |
 | `list` | required  input sequence. |
-| `start` | [int](../core/int); default is `0`  start index. |
+| `start` | [int](/versions/8.2.1/rules/lib/core/int); default is `0`  start index. |
 
 ## fail
 
@@ -165,8 +165,8 @@ Causes execution to fail with an error.
 | Parameter | Description |
 | --- | --- |
 | `msg` | default is `None`  Deprecated: use positional arguments instead. This argument acts like an implicit leading positional argument. |
-| `attr` | [string](../core/string); or `None`; default is `None`  Deprecated. Causes an optional prefix containing this string to be added to the error message. |
-| `sep` | [string](../core/string); default is `" "`  The separator string between the objects, default is space (" "). |
+| `attr` | [string](/versions/8.2.1/rules/lib/core/string); or `None`; default is `None`  Deprecated. Causes an optional prefix containing this string to be added to the error message. |
+| `sep` | [string](/versions/8.2.1/rules/lib/core/string); default is `" "`  The separator string between the objects, default is space (" "). |
 | `args` | required  A list of values, formatted with debugPrint (which is equivalent to str by default) and joined with sep (defaults to " "), that appear in the error message. |
 
 ## float
@@ -205,7 +205,7 @@ getattr(ctx.attr, "myattr", "mydefault")
 | Parameter | Description |
 | --- | --- |
 | `x` | required  The struct whose attribute is accessed. |
-| `name` | [string](../core/string); required  The name of the struct attribute. |
+| `name` | [string](/versions/8.2.1/rules/lib/core/string); required  The name of the struct attribute. |
 | `default` | default is `unbound`  The default value to return in case the struct doesn't have an attribute of the given name. |
 
 ## hasattr
@@ -225,7 +225,7 @@ hasattr(ctx.attr, "myattr")
 | Parameter | Description |
 | --- | --- |
 | `x` | required |
-| `name` | [string](../core/string); required  The name of the attribute. |
+| `name` | [string](/versions/8.2.1/rules/lib/core/string); required  The name of the attribute. |
 
 ## hash
 
@@ -245,7 +245,7 @@ Hashing of values besides strings is not currently supported.
 
 | Parameter | Description |
 | --- | --- |
-| `value` | [string](../core/string); required  String value to hash. |
+| `value` | [string](/versions/8.2.1/rules/lib/core/string); required  String value to hash. |
 
 ## int
 
@@ -372,7 +372,7 @@ Using `print` in production code is discouraged due to the spam it creates for u
 
 | Parameter | Description |
 | --- | --- |
-| `sep` | [string](../core/string); default is `" "`  The separator string between the objects, default is space (" "). |
+| `sep` | [string](/versions/8.2.1/rules/lib/core/string); default is `" "`  The separator string between the objects, default is space (" "). |
 | `args` | required  The objects to print. |
 
 ## range
@@ -393,9 +393,9 @@ range(3, 0, -1) == [3, 2, 1]
 
 | Parameter | Description |
 | --- | --- |
-| `start_or_stop` | [int](../core/int); required  Value of the start element if stop is provided, otherwise value of stop and the actual start is 0 |
-| `stop_or_none` | [int](../core/int); or `None`; default is `None`  optional index of the first item *not* to be included in the resulting list; generation of the list stops before `stop` is reached. |
-| `step` | [int](../core/int); default is `1`  The increment (default is 1). It may be negative. |
+| `start_or_stop` | [int](/versions/8.2.1/rules/lib/core/int); required  Value of the start element if stop is provided, otherwise value of stop and the actual start is 0 |
+| `stop_or_none` | [int](/versions/8.2.1/rules/lib/core/int); or `None`; default is `None`  optional index of the first item *not* to be included in the resulting list; generation of the list stops before `stop` is reached. |
+| `step` | [int](/versions/8.2.1/rules/lib/core/int); default is `1`  The increment (default is 1). It may be negative. |
 
 ## repr
 
@@ -439,7 +439,7 @@ reversed([3, 5, 4]) == [4, 5, 3]
 set set(elements=[])
 ```
 
-Creates a new [set](../core/set) containing the unique elements of a given
+Creates a new [set](/versions/8.2.1/rules/lib/core/set) containing the unique elements of a given
 iterable, preserving iteration order.
 
 If called with no argument, `set()` returns a new empty set.
@@ -479,7 +479,7 @@ sorted(["two", "three", "four"], key = len) == ["two", "four", "three"]  # sort
 | --- | --- |
 | `iterable` | iterable; required  The iterable sequence to sort. |
 | `key` | callable; or `None`; default is `None`  An optional function applied to each element before comparison. |
-| `reverse` | [bool](../core/bool); default is `False`  Return results in descending order. |
+| `reverse` | [bool](/versions/8.2.1/rules/lib/core/bool); default is `False`  Return results in descending order. |
 
 ## str
 
diff --git a/versions/8.2.1/rules/lib/globals/build.mdx b/versions/8.2.1/rules/lib/globals/build.mdx
index b785d2f3..c2301ce3 100644
--- a/versions/8.2.1/rules/lib/globals/build.mdx
+++ b/versions/8.2.1/rules/lib/globals/build.mdx
@@ -28,7 +28,7 @@ Methods available in BUILD files. See also the Build Encyclopedia for extra [fun
 depset depset(direct=None, order="default", *, transitive=None)
 ```
 
-Creates a [depset](../builtins/depset). The `direct` parameter is a list of direct elements of the depset, and `transitive` parameter is a list of depsets whose elements become indirect elements of the created depset. The order in which elements are returned when the depset is converted to a list is specified by the `order` parameter. See the [Depsets overview](https://bazel.build/versions/8.2.1/extending/depsets) for more information.
+Creates a [depset](/versions/8.2.1/rules/lib/builtins/depset). The `direct` parameter is a list of direct elements of the depset, and `transitive` parameter is a list of depsets whose elements become indirect elements of the created depset. The order in which elements are returned when the depset is converted to a list is specified by the `order` parameter. See the [Depsets overview](https://bazel.build/versions/8.2.1/extending/depsets) for more information.
 
 All elements (direct and indirect) of a depset must be of the same type, as obtained by the expression `type(x)`.
 
@@ -42,9 +42,9 @@ The order of the created depset should be *compatible* with the order of its `tr
 
 | Parameter | Description |
 | --- | --- |
-| `direct` | [sequence](../core/list); or `None`; default is `None`  A list of *direct* elements of a depset. |
-| `order` | [string](../core/string); default is `"default"`  The traversal strategy for the new depset. See [here](../builtins/depset) for the possible values. |
-| `transitive` | [sequence](../core/list) of [depset](../builtins/depset)s; or `None`; default is `None`  A list of depsets whose elements will become indirect elements of the depset. |
+| `direct` | [sequence](/versions/8.2.1/rules/lib/core/list); or `None`; default is `None`  A list of *direct* elements of a depset. |
+| `order` | [string](/versions/8.2.1/rules/lib/core/string); default is `"default"`  The traversal strategy for the new depset. See [here](/versions/8.2.1/rules/lib/builtins/depset) for the possible values. |
+| `transitive` | [sequence](/versions/8.2.1/rules/lib/core/list) of [depset](/versions/8.2.1/rules/lib/builtins/depset)s; or `None`; default is `None`  A list of depsets whose elements will become indirect elements of the depset. |
 
 ## existing\_rule
 
@@ -72,7 +72,7 @@ If possible, avoid using this function. It makes BUILD files brittle and order-d
 
 | Parameter | Description |
 | --- | --- |
-| `name` | [string](../core/string); required  The name of the target. |
+| `name` | [string](/versions/8.2.1/rules/lib/core/string); required  The name of the target. |
 
 ## existing\_rules
 
@@ -98,9 +98,9 @@ Specifies a list of files belonging to this package that are exported to other p
 
 | Parameter | Description |
 | --- | --- |
-| `srcs` | [sequence](../core/list) of [string](../core/string)s; required  The list of files to export. |
-| `visibility` | [sequence](../core/list); or `None`; default is `None`  A visibility declaration can to be specified. The files will be visible to the targets specified. If no visibility is specified, the files will be visible to every package. |
-| `licenses` | [sequence](../core/list) of [string](../core/string)s; or `None`; default is `None`  Licenses to be specified. |
+| `srcs` | [sequence](/versions/8.2.1/rules/lib/core/list) of [string](/versions/8.2.1/rules/lib/core/string)s; required  The list of files to export. |
+| `visibility` | [sequence](/versions/8.2.1/rules/lib/core/list); or `None`; default is `None`  A visibility declaration can to be specified. The files will be visible to the targets specified. If no visibility is specified, the files will be visible to every package. |
+| `licenses` | [sequence](/versions/8.2.1/rules/lib/core/list) of [string](/versions/8.2.1/rules/lib/core/string)s; or `None`; default is `None`  Licenses to be specified. |
 
 ## glob
 
@@ -119,9 +119,9 @@ If the `exclude_directories` argument is enabled (set to `1`), files of type dir
 
 | Parameter | Description |
 | --- | --- |
-| `include` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  The list of glob patterns to include. |
-| `exclude` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  The list of glob patterns to exclude. |
-| `exclude_directories` | [int](../core/int); default is `1`  A flag whether to exclude directories or not. |
+| `include` | [sequence](/versions/8.2.1/rules/lib/core/list) of [string](/versions/8.2.1/rules/lib/core/string)s; default is `[]`  The list of glob patterns to include. |
+| `exclude` | [sequence](/versions/8.2.1/rules/lib/core/list) of [string](/versions/8.2.1/rules/lib/core/string)s; default is `[]`  The list of glob patterns to exclude. |
+| `exclude_directories` | [int](/versions/8.2.1/rules/lib/core/int); default is `1`  A flag whether to exclude directories or not. |
 | `allow_empty` | default is `unbound`  Whether we allow glob patterns to match nothing. If `allow\_empty` is False, each individual include pattern must match something and also the final result must be non-empty (after the matches of the `exclude` patterns are excluded). |
 
 ## module\_name
@@ -168,9 +168,9 @@ This function defines a set of packages and assigns a label to the group. The la
 
 | Parameter | Description |
 | --- | --- |
-| `name` | [string](../core/string); required  The unique name for this rule. |
-| `packages` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  A complete enumeration of packages in this group. |
-| `includes` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  Other package groups that are included in this one. |
+| `name` | [string](/versions/8.2.1/rules/lib/core/string); required  The unique name for this rule. |
+| `packages` | [sequence](/versions/8.2.1/rules/lib/core/list) of [string](/versions/8.2.1/rules/lib/core/string)s; default is `[]`  A complete enumeration of packages in this group. |
+| `includes` | [sequence](/versions/8.2.1/rules/lib/core/list) of [string](/versions/8.2.1/rules/lib/core/string)s; default is `[]`  Other package groups that are included in this one. |
 
 ## package\_name
 
@@ -186,19 +186,19 @@ The name of the package being evaluated, without the repository name. For exampl
 Label package_relative_label(input)
 ```
 
-Converts the input string into a [Label](../builtins/Label) object, in the context of the package currently being initialized (that is, the `BUILD` file for which the current macro is executing). If the input is already a `Label`, it is returned unchanged.
+Converts the input string into a [Label](/versions/8.2.1/rules/lib/builtins/Label) object, in the context of the package currently being initialized (that is, the `BUILD` file for which the current macro is executing). If the input is already a `Label`, it is returned unchanged.
 
 This function may only be called while evaluating a BUILD file and the macros it directly or indirectly calls; it may not be called in (for instance) a rule implementation function.
 
 The result of this function is the same `Label` value as would be produced by passing the given string to a label-valued attribute of a target declared in the BUILD file.
 
-*Usage note:* The difference between this function and [Label()](../builtins/Label#Label) is that `Label()` uses the context of the package of the `.bzl` file that called it, not the package of the `BUILD` file. Use `Label()` when you need to refer to a fixed target that is hardcoded into the macro, such as a compiler. Use `package_relative_label()` when you need to normalize a label string supplied by the BUILD file to a `Label` object. (There is no way to convert a string to a `Label` in the context of a package other than the BUILD file or the calling .bzl file. For that reason, outer macros should always prefer to pass Label objects to inner macros rather than label strings.)
+*Usage note:* The difference between this function and [Label()](/versions/8.2.1/rules/lib/builtins/Label#Label) is that `Label()` uses the context of the package of the `.bzl` file that called it, not the package of the `BUILD` file. Use `Label()` when you need to refer to a fixed target that is hardcoded into the macro, such as a compiler. Use `package_relative_label()` when you need to normalize a label string supplied by the BUILD file to a `Label` object. (There is no way to convert a string to a `Label` in the context of a package other than the BUILD file or the calling .bzl file. For that reason, outer macros should always prefer to pass Label objects to inner macros rather than label strings.)
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `input` | [string](../core/string); or [Label](../builtins/Label); required  The input label string or Label object. If a Label object is passed, it's returned as is. |
+| `input` | [string](/versions/8.2.1/rules/lib/core/string); or [Label](/versions/8.2.1/rules/lib/builtins/Label); required  The input label string or Label object. If a Label object is passed, it's returned as is. |
 
 ## repo\_name
 
@@ -231,8 +231,8 @@ unknown select(x, no_match_error='')
 
 | Parameter | Description |
 | --- | --- |
-| `x` | [dict](../core/dict); required |
-| `no_match_error` | [string](../core/string); default is `''`  Optional custom error to report if no condition matches. |
+| `x` | [dict](/versions/8.2.1/rules/lib/core/dict); required |
+| `no_match_error` | [string](/versions/8.2.1/rules/lib/core/string); default is `''`  Optional custom error to report if no condition matches. |
 
 ## subpackages
 
@@ -246,6 +246,6 @@ Returns a new mutable list of every direct subpackage of the current package, re
 
 | Parameter | Description |
 | --- | --- |
-| `include` | [sequence](../core/list) of [string](../core/string)s; required  The list of glob patterns to include in subpackages scan. |
-| `exclude` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  The list of glob patterns to exclude from subpackages scan. |
-| `allow_empty` | [bool](../core/bool); default is `False`  Whether we fail if the call returns an empty list. By default empty list indicates potential error in BUILD file where the call to subpackages() is superflous. Setting to true allows this function to succeed in that case. |*
\ No newline at end of file
+| `include` | [sequence](/versions/8.2.1/rules/lib/core/list) of [string](/versions/8.2.1/rules/lib/core/string)s; required  The list of glob patterns to include in subpackages scan. |
+| `exclude` | [sequence](/versions/8.2.1/rules/lib/core/list) of [string](/versions/8.2.1/rules/lib/core/string)s; default is `[]`  The list of glob patterns to exclude from subpackages scan. |
+| `allow_empty` | [bool](/versions/8.2.1/rules/lib/core/bool); default is `False`  Whether we fail if the call returns an empty list. By default empty list indicates potential error in BUILD file where the call to subpackages() is superflous. Setting to true allows this function to succeed in that case. |*
\ No newline at end of file
diff --git a/versions/8.2.1/rules/lib/globals/bzl.mdx b/versions/8.2.1/rules/lib/globals/bzl.mdx
index 62591307..dc384a40 100644
--- a/versions/8.2.1/rules/lib/globals/bzl.mdx
+++ b/versions/8.2.1/rules/lib/globals/bzl.mdx
@@ -28,7 +28,7 @@ Global methods available in all .bzl files.
 transition analysis_test_transition(settings)
 ```
 
-Creates a configuration transition to be applied on an analysis-test rule's dependencies. This transition may only be applied on attributes of rules with `analysis_test = True`. Such rules are restricted in capabilities (for example, the size of their dependency tree is limited), so transitions created using this function are limited in potential scope as compared to transitions created using [`transition()`](../builtins/transition).
+Creates a configuration transition to be applied on an analysis-test rule's dependencies. This transition may only be applied on attributes of rules with `analysis_test = True`. Such rules are restricted in capabilities (for example, the size of their dependency tree is limited), so transitions created using this function are limited in potential scope as compared to transitions created using [`transition()`](/versions/8.2.1/rules/lib/builtins/transition).
 
 This function is primarily designed to facilitate the [Analysis Test Framework](https://bazel.build/versions/8.2.1/rules/testing) core library. See its documentation (or its implementation) for best practices.
 
@@ -36,7 +36,7 @@ This function is primarily designed to facilitate the [Analysis Test Framework](
 
 | Parameter | Description |
 | --- | --- |
-| `settings` | [dict](../core/dict); required  A dictionary containing information about configuration settings which should be set by this configuration transition. Keys are build setting labels and values are their new post-transition values. All other settings are unchanged. Use this to declare specific configuration settings that an analysis test requires to be set in order to pass. |
+| `settings` | [dict](/versions/8.2.1/rules/lib/core/dict); required  A dictionary containing information about configuration settings which should be set by this configuration transition. Keys are build setting labels and values are their new post-transition values. All other settings are unchanged. Use this to declare specific configuration settings that an analysis test requires to be set in order to pass. |
 
 ## aspect
 
@@ -50,23 +50,23 @@ Creates a new aspect. The result of this function must be stored in a global val
 
 | Parameter | Description |
 | --- | --- |
-| `implementation` | [function](../core/function); required  A Starlark function that implements this aspect, with exactly two parameters: [Target](../builtins/Target) (the target to which the aspect is applied) and [ctx](../builtins/ctx) (the rule context which the target is created from). Attributes of the target are available via the `ctx.rule` field. This function is evaluated during the analysis phase for each application of an aspect to a target. |
-| `attr_aspects` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  List of attribute names. The aspect propagates along dependencies specified in the attributes of a target with these names. Common values here include `deps` and `exports`. The list can also contain a single string `"*"` to propagate along all dependencies of a target. |
-| `toolchains_aspects` | [sequence](../core/list); default is `[]`  List of toolchain types. The aspect propagates to target toolchains which match these toolchain types. |
-| `attrs` | [dict](../core/dict); default is `{}`  A dictionary declaring all the attributes of the aspect. It maps from an attribute name to an attribute object, like `attr.label` or `attr.string` (see [`attr`](../toplevel/attr) module). Aspect attributes are available to implementation function as fields of `ctx` parameter. Implicit attributes starting with `_` must have default values, and have type `label` or `label_list`.  Explicit attributes must have type `string`, and must use the `values` restriction. Explicit attributes restrict the aspect to only be used with rules that have attributes of the same name, type, and valid values according to the restriction.  Declared attributes will convert `None` to the default value. |
-| `required_providers` | [sequence](../core/list); default is `[]`  This attribute allows the aspect to limit its propagation to only the targets whose rules advertise its required providers. The value must be a list containing either individual providers or lists of providers but not both. For example, `[[FooInfo], [BarInfo], [BazInfo, QuxInfo]]` is a valid value while `[FooInfo, BarInfo, [BazInfo, QuxInfo]]` is not valid. An unnested list of providers will automatically be converted to a list containing one list of providers. That is, `[FooInfo, BarInfo]` will automatically be converted to `[[FooInfo, BarInfo]]`. To make some rule (e.g. `some_rule`) targets visible to an aspect, `some_rule` must advertise all providers from at least one of the required providers lists. For example, if the `required_providers` of an aspect are `[[FooInfo], [BarInfo], [BazInfo, QuxInfo]]`, this aspect can see `some_rule` targets if and only if `some_rule` provides `FooInfo`, *or* `BarInfo`, *or* both `BazInfo` *and* `QuxInfo`. |
-| `required_aspect_providers` | [sequence](../core/list); default is `[]`  This attribute allows this aspect to inspect other aspects. The value must be a list containing either individual providers or lists of providers but not both. For example, `[[FooInfo], [BarInfo], [BazInfo, QuxInfo]]` is a valid value while `[FooInfo, BarInfo, [BazInfo, QuxInfo]]` is not valid. An unnested list of providers will automatically be converted to a list containing one list of providers. That is, `[FooInfo, BarInfo]` will automatically be converted to `[[FooInfo, BarInfo]]`. To make another aspect (e.g. `other_aspect`) visible to this aspect, `other_aspect` must provide all providers from at least one of the lists. In the example of `[[FooInfo], [BarInfo], [BazInfo, QuxInfo]]`, this aspect can see `other_aspect` if and only if `other_aspect` provides `FooInfo`, *or* `BarInfo`, *or* both `BazInfo` *and* `QuxInfo`. |
-| `provides` | [sequence](../core/list); default is `[]`  A list of providers that the implementation function must return. It is an error if the implementation function omits any of the types of providers listed here from its return value. However, the implementation function may return additional providers not listed here. Each element of the list is an `*Info` object returned by [`provider()`](../globals/bzl#provider), except that a legacy provider is represented by its string name instead.When a target of the rule is used as a dependency for a target that declares a required provider, it is not necessary to specify that provider here. It is enough that the implementation function returns it. However, it is considered best practice to specify it, even though this is not required. The [`required_providers`](../globals/bzl#aspect.required_providers) field of an [aspect](../globals/bzl#aspect) does, however, require that providers are specified here. |
-| `requires` | [sequence](../core/list) of [Aspect](../builtins/Aspect)s; default is `[]`  List of aspects required to be propagated before this aspect. |
-| `fragments` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  List of names of configuration fragments that the aspect requires in target configuration. |
-| `host_fragments` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  List of names of configuration fragments that the aspect requires in host configuration. |
-| `toolchains` | [sequence](../core/list); default is `[]`  If set, the set of toolchains this aspect requires. The list can contain String, Label, or StarlarkToolchainTypeApi objects, in any combination. Toolchains will be found by checking the current platform, and provided to the aspect implementation via `ctx.toolchain`. |
-| `incompatible_use_toolchain_transition` | [bool](../core/bool); default is `False`  Deprecated, this is no longer in use and should be removed. |
-| `doc` | [string](../core/string); or `None`; default is `None`  A description of the aspect that can be extracted by documentation generating tools. |
-| `apply_to_generating_rules` | [bool](../core/bool); default is `False`  If true, the aspect will, when applied to an output file, instead apply to the output file's generating rule. For example, suppose an aspect propagates transitively through attribute `deps` and it is applied to target `alpha`. Suppose `alpha` has `deps = [':beta\_output']`, where `beta\_output` is a declared output of a target `beta`. Suppose `beta` has a target `charlie` as one of its `deps`. If `apply\_to\_generating\_rules=True` for the aspect, then the aspect will propagate through `alpha`, `beta`, and `charlie`. If False, then the aspect will propagate only to `alpha`.  False by default. |
-| `exec_compatible_with` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  A list of constraints on the execution platform that apply to all instances of this aspect. |
-| `exec_groups` | [dict](../core/dict); or `None`; default is `None`  Dict of execution group name (string) to [`exec_group`s](../globals/bzl#exec_group). If set, allows aspects to run actions on multiple execution platforms within a single instance. See [execution groups documentation](/versions/8.2.1/reference/exec-groups) for more info. |
-| `subrules` | [sequence](../core/list) of [Subrule](../builtins/Subrule)s; default is `[]`  Experimental: list of subrules used by this aspect. |
+| `implementation` | [function](/versions/8.2.1/rules/lib/core/function); required  A Starlark function that implements this aspect, with exactly two parameters: [Target](/versions/8.2.1/rules/lib/builtins/Target) (the target to which the aspect is applied) and [ctx](/versions/8.2.1/rules/lib/builtins/ctx) (the rule context which the target is created from). Attributes of the target are available via the `ctx.rule` field. This function is evaluated during the analysis phase for each application of an aspect to a target. |
+| `attr_aspects` | [sequence](/versions/8.2.1/rules/lib/core/list) of [string](/versions/8.2.1/rules/lib/core/string)s; default is `[]`  List of attribute names. The aspect propagates along dependencies specified in the attributes of a target with these names. Common values here include `deps` and `exports`. The list can also contain a single string `"*"` to propagate along all dependencies of a target. |
+| `toolchains_aspects` | [sequence](/versions/8.2.1/rules/lib/core/list); default is `[]`  List of toolchain types. The aspect propagates to target toolchains which match these toolchain types. |
+| `attrs` | [dict](/versions/8.2.1/rules/lib/core/dict); default is `{}`  A dictionary declaring all the attributes of the aspect. It maps from an attribute name to an attribute object, like `attr.label` or `attr.string` (see [`attr`](/versions/8.2.1/rules/lib/toplevel/attr) module). Aspect attributes are available to implementation function as fields of `ctx` parameter. Implicit attributes starting with `_` must have default values, and have type `label` or `label_list`.  Explicit attributes must have type `string`, and must use the `values` restriction. Explicit attributes restrict the aspect to only be used with rules that have attributes of the same name, type, and valid values according to the restriction.  Declared attributes will convert `None` to the default value. |
+| `required_providers` | [sequence](/versions/8.2.1/rules/lib/core/list); default is `[]`  This attribute allows the aspect to limit its propagation to only the targets whose rules advertise its required providers. The value must be a list containing either individual providers or lists of providers but not both. For example, `[[FooInfo], [BarInfo], [BazInfo, QuxInfo]]` is a valid value while `[FooInfo, BarInfo, [BazInfo, QuxInfo]]` is not valid. An unnested list of providers will automatically be converted to a list containing one list of providers. That is, `[FooInfo, BarInfo]` will automatically be converted to `[[FooInfo, BarInfo]]`. To make some rule (e.g. `some_rule`) targets visible to an aspect, `some_rule` must advertise all providers from at least one of the required providers lists. For example, if the `required_providers` of an aspect are `[[FooInfo], [BarInfo], [BazInfo, QuxInfo]]`, this aspect can see `some_rule` targets if and only if `some_rule` provides `FooInfo`, *or* `BarInfo`, *or* both `BazInfo` *and* `QuxInfo`. |
+| `required_aspect_providers` | [sequence](/versions/8.2.1/rules/lib/core/list); default is `[]`  This attribute allows this aspect to inspect other aspects. The value must be a list containing either individual providers or lists of providers but not both. For example, `[[FooInfo], [BarInfo], [BazInfo, QuxInfo]]` is a valid value while `[FooInfo, BarInfo, [BazInfo, QuxInfo]]` is not valid. An unnested list of providers will automatically be converted to a list containing one list of providers. That is, `[FooInfo, BarInfo]` will automatically be converted to `[[FooInfo, BarInfo]]`. To make another aspect (e.g. `other_aspect`) visible to this aspect, `other_aspect` must provide all providers from at least one of the lists. In the example of `[[FooInfo], [BarInfo], [BazInfo, QuxInfo]]`, this aspect can see `other_aspect` if and only if `other_aspect` provides `FooInfo`, *or* `BarInfo`, *or* both `BazInfo` *and* `QuxInfo`. |
+| `provides` | [sequence](/versions/8.2.1/rules/lib/core/list); default is `[]`  A list of providers that the implementation function must return. It is an error if the implementation function omits any of the types of providers listed here from its return value. However, the implementation function may return additional providers not listed here. Each element of the list is an `*Info` object returned by [`provider()`](/versions/8.2.1/rules/lib/globals/bzl#provider), except that a legacy provider is represented by its string name instead.When a target of the rule is used as a dependency for a target that declares a required provider, it is not necessary to specify that provider here. It is enough that the implementation function returns it. However, it is considered best practice to specify it, even though this is not required. The [`required_providers`](/versions/8.2.1/rules/lib/globals/bzl#aspect.required_providers) field of an [aspect](/versions/8.2.1/rules/lib/globals/bzl#aspect) does, however, require that providers are specified here. |
+| `requires` | [sequence](/versions/8.2.1/rules/lib/core/list) of [Aspect](/versions/8.2.1/rules/lib/builtins/Aspect)s; default is `[]`  List of aspects required to be propagated before this aspect. |
+| `fragments` | [sequence](/versions/8.2.1/rules/lib/core/list) of [string](/versions/8.2.1/rules/lib/core/string)s; default is `[]`  List of names of configuration fragments that the aspect requires in target configuration. |
+| `host_fragments` | [sequence](/versions/8.2.1/rules/lib/core/list) of [string](/versions/8.2.1/rules/lib/core/string)s; default is `[]`  List of names of configuration fragments that the aspect requires in host configuration. |
+| `toolchains` | [sequence](/versions/8.2.1/rules/lib/core/list); default is `[]`  If set, the set of toolchains this aspect requires. The list can contain String, Label, or StarlarkToolchainTypeApi objects, in any combination. Toolchains will be found by checking the current platform, and provided to the aspect implementation via `ctx.toolchain`. |
+| `incompatible_use_toolchain_transition` | [bool](/versions/8.2.1/rules/lib/core/bool); default is `False`  Deprecated, this is no longer in use and should be removed. |
+| `doc` | [string](/versions/8.2.1/rules/lib/core/string); or `None`; default is `None`  A description of the aspect that can be extracted by documentation generating tools. |
+| `apply_to_generating_rules` | [bool](/versions/8.2.1/rules/lib/core/bool); default is `False`  If true, the aspect will, when applied to an output file, instead apply to the output file's generating rule. For example, suppose an aspect propagates transitively through attribute `deps` and it is applied to target `alpha`. Suppose `alpha` has `deps = [':beta\_output']`, where `beta\_output` is a declared output of a target `beta`. Suppose `beta` has a target `charlie` as one of its `deps`. If `apply\_to\_generating\_rules=True` for the aspect, then the aspect will propagate through `alpha`, `beta`, and `charlie`. If False, then the aspect will propagate only to `alpha`.  False by default. |
+| `exec_compatible_with` | [sequence](/versions/8.2.1/rules/lib/core/list) of [string](/versions/8.2.1/rules/lib/core/string)s; default is `[]`  A list of constraints on the execution platform that apply to all instances of this aspect. |
+| `exec_groups` | [dict](/versions/8.2.1/rules/lib/core/dict); or `None`; default is `None`  Dict of execution group name (string) to [`exec_group`s](/versions/8.2.1/rules/lib/globals/bzl#exec_group). If set, allows aspects to run actions on multiple execution platforms within a single instance. See [execution groups documentation](/versions/8.2.1/reference/exec-groups) for more info. |
+| `subrules` | [sequence](/versions/8.2.1/rules/lib/core/list) of [Subrule](/versions/8.2.1/rules/lib/builtins/Subrule)s; default is `[]`  Experimental: list of subrules used by this aspect. |
 
 ## configuration\_field
 
@@ -74,7 +74,7 @@ Creates a new aspect. The result of this function must be stored in a global val
 LateBoundDefault configuration_field(fragment, name)
 ```
 
-References a late-bound default value for an attribute of type [label](../toplevel/attr#label). A value is 'late-bound' if it requires the configuration to be built before determining the value. Any attribute using this as a value must [be private](https://bazel.build/versions/8.2.1/extending/rules#private-attributes).
+References a late-bound default value for an attribute of type [label](/versions/8.2.1/rules/lib/toplevel/attr#label). A value is 'late-bound' if it requires the configuration to be built before determining the value. Any attribute using this as a value must [be private](https://bazel.build/versions/8.2.1/extending/rules#private-attributes).
 
 Example usage:
 
@@ -96,8 +96,8 @@ Accessing in rule implementation:
 
 | Parameter | Description |
 | --- | --- |
-| `fragment` | [string](../core/string); required |
-| `name` | [string](../core/string); required |
+| `fragment` | [string](/versions/8.2.1/rules/lib/core/string); required |
+| `name` | [string](/versions/8.2.1/rules/lib/core/string); required |
 
 ## depset
 
@@ -105,7 +105,7 @@ Accessing in rule implementation:
 depset depset(direct=None, order="default", *, transitive=None)
 ```
 
-Creates a [depset](../builtins/depset). The `direct` parameter is a list of direct elements of the depset, and `transitive` parameter is a list of depsets whose elements become indirect elements of the created depset. The order in which elements are returned when the depset is converted to a list is specified by the `order` parameter. See the [Depsets overview](https://bazel.build/versions/8.2.1/extending/depsets) for more information.
+Creates a [depset](/versions/8.2.1/rules/lib/builtins/depset). The `direct` parameter is a list of direct elements of the depset, and `transitive` parameter is a list of depsets whose elements become indirect elements of the created depset. The order in which elements are returned when the depset is converted to a list is specified by the `order` parameter. See the [Depsets overview](https://bazel.build/versions/8.2.1/extending/depsets) for more information.
 
 All elements (direct and indirect) of a depset must be of the same type, as obtained by the expression `type(x)`.
 
@@ -119,9 +119,9 @@ The order of the created depset should be *compatible* with the order of its `tr
 
 | Parameter | Description |
 | --- | --- |
-| `direct` | [sequence](../core/list); or `None`; default is `None`  A list of *direct* elements of a depset. |
-| `order` | [string](../core/string); default is `"default"`  The traversal strategy for the new depset. See [here](../builtins/depset) for the possible values. |
-| `transitive` | [sequence](../core/list) of [depset](../builtins/depset)s; or `None`; default is `None`  A list of depsets whose elements will become indirect elements of the depset. |
+| `direct` | [sequence](/versions/8.2.1/rules/lib/core/list); or `None`; default is `None`  A list of *direct* elements of a depset. |
+| `order` | [string](/versions/8.2.1/rules/lib/core/string); default is `"default"`  The traversal strategy for the new depset. See [here](/versions/8.2.1/rules/lib/builtins/depset) for the possible values. |
+| `transitive` | [sequence](/versions/8.2.1/rules/lib/core/list) of [depset](/versions/8.2.1/rules/lib/builtins/depset)s; or `None`; default is `None`  A list of depsets whose elements will become indirect elements of the depset. |
 
 ## exec\_group
 
@@ -135,8 +135,8 @@ Creates an [execution group](/versions/8.2.1/reference/exec-groups) which can be
 
 | Parameter | Description |
 | --- | --- |
-| `toolchains` | [sequence](../core/list); default is `[]`  The set of toolchains this execution group requires. The list can contain String, Label, or StarlarkToolchainTypeApi objects, in any combination. |
-| `exec_compatible_with` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  A list of constraints on the execution platform. |
+| `toolchains` | [sequence](/versions/8.2.1/rules/lib/core/list); default is `[]`  The set of toolchains this execution group requires. The list can contain String, Label, or StarlarkToolchainTypeApi objects, in any combination. |
+| `exec_compatible_with` | [sequence](/versions/8.2.1/rules/lib/core/list) of [string](/versions/8.2.1/rules/lib/core/string)s; default is `[]`  A list of constraints on the execution platform. |
 
 ## exec\_transition
 
@@ -144,15 +144,15 @@ Creates an [execution group](/versions/8.2.1/reference/exec-groups) which can be
 transition exec_transition(implementation, inputs, outputs)
 ```
 
-A specialized version of [`transition()`](../builtins/transition) used to define the exec transition. See its documentation (or its implementation) for best practices. Only usable from the Bazel builtins.
+A specialized version of [`transition()`](/versions/8.2.1/rules/lib/builtins/transition) used to define the exec transition. See its documentation (or its implementation) for best practices. Only usable from the Bazel builtins.
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
 | `implementation` | callable; required |
-| `inputs` | [sequence](../core/list) of [string](../core/string)s; required |
-| `outputs` | [sequence](../core/list) of [string](../core/string)s; required |
+| `inputs` | [sequence](/versions/8.2.1/rules/lib/core/list) of [string](/versions/8.2.1/rules/lib/core/string)s; required |
+| `outputs` | [sequence](/versions/8.2.1/rules/lib/core/list) of [string](/versions/8.2.1/rules/lib/core/string)s; required |
 
 ## macro
 
@@ -173,11 +173,11 @@ macros.
 
 | Parameter | Description |
 | --- | --- |
-| `implementation` | [function](../core/function); required  The Starlark function implementing this macro. The values of the macro's attributes are passed to the implementation function as keyword arguments. The implementation function must have at least two named parameters, `name` and `visibility`, and if the macro inherits attributes (see `inherit_attrs` below), it must have a `**kwargs` residual keyword parameter. By convention, the implementation function should have a named parameter for any attribute that the macro needs to examine, modify, or pass to non-"main" targets, while the "bulk" inherited attributes which will be passed to the "main" target unchanged are passed as `**kwargs`. The implementation function must not return a value. Instead, the implementation function *declares targets* by calling rule or macro symbols. The name of any target or inner symbolic macro declared by a symbolic macro (including by any Starlark function that the macro's implementation function transitively calls) must either equal `name` (this is referred to as the "main" target) or start with `name`, followed by a separator chracter (`"_"`, `"-"`, or `"."`) and a string suffix. (Targets violating this naming scheme are allowed to be declared, but cannot be built, configured, or depended upon.) By default, targets declared by a symbolic macro (including by any Starlark function that the macro's implementation function transitively calls) are visible only in the package containing the .bzl file defining the macro. To declare targets visible externally, *including to the caller of the symbolic macro*, the implementation function must set `visibility` appropriately – typically, by passing `visibility = visibility` to the rule or macro symbol being called. The following APIs are unavailable within a macro implementation function and any Starlark function it transitively calls:  * [`package()`, `licenses()`* `environment_group()`* [`native.glob()`](../toplevel/native#glob) – instead, you may pass       a glob into the macro via a label list attribute* [`native.subpackages()`](../toplevel/native#subpackages)* (allowed in rule finalizers only, see `finalizer` below)           [`native.existing_rules()`](../toplevel/native#existing_rules),           [`native.existing_rule()`](../toplevel/native#existing_rule)* (for `WORKSPACE` threads)             [`workspace()`](../globals/workspace#workspace),             [`register_toolchains()`](../globals/workspace#register_toolchains),             [`bind()`](../globals/workspace#bind), [`register_execution_platforms()`](../globals/workspace#register_execution_platforms), [repository rule instantiation](/versions/8.2.1/reference/be/workspace#repository_rule) |
-| `attrs` | [dict](../core/dict); default is `{}`  A dictionary of the attributes this macro supports, analogous to [rule.attrs](#rule.attrs). Keys are attribute names, and values are either attribute objects like `attr.label_list(...)` (see the [attr](../toplevel/attr) module), or `None`. A `None` entry means that the macro does not have an attribute by that name, even if it would have otherwise inherited one via `inherit_attrs` (see below). The special `name` attribute is predeclared and must not be included in the dictionary. The `visibility` attribute name is reserved and must not be included in the dictionary. Attributes whose names start with `_` are private -- they cannot be passed at the call site of the rule. Such attributes can be assigned a default value (as in `attr.label(default="//pkg:foo")`) to create an implicit dependency on a label. To limit memory usage, there is a cap on the number of attributes that may be declared. |
-| `inherit_attrs` | [rule](../builtins/rule); or [macro](../builtins/macro); or [string](../core/string); or `None`; default is `None`  A rule symbol, macro symbol, or the name of a built-in common attribute list (see below) from which the macro should inherit attributes. If `inherit_attrs` is set to the string `"common"`, the macro will inherit [common rule attribute definitions](/versions/8.2.1/reference/be/common-definitions#common-attributes) used by all Starlark rules. Note that if the return value of `rule()` or `macro()` was not assigned to a global variable in a .bzl file, then such a value has not been registered as a rule or macro symbol, and therefore cannot be used for `inherit_attrs`. The inheritance mechanism works as follows:   1. The special `name` and `visibility` attributes are never inherited;- Hidden attributes (ones whose name starts with `"_"`) are never inherited;- Attributes whose names are already defined in the `attrs` dictionary are never        inherited (the entry in `attrs` takes precedence; note that an entry may be set to        `None` to ensure that no attribute by that name gets defined on the macro);- All other attributes are inherited from the rule or macro and effectively merged into the          `attrs` dict.   When a non-mandatory attribute is inherited, the default value of the attribute is overridden to be `None`, regardless of what it was specified in the original rule or macro. This ensures that when the macro forwards the attribute's value to an instance of the wrapped rule or macro – such as by passing in the unmodified `**kwargs` – a value that was absent from the outer macro's call will also be absent in the inner rule or macro's call (since passing `None` to an attribute is treated the same as omitting the attribute). This is important because omitting an attribute has subtly different semantics from passing its apparent default value. In particular, omitted attributes are not shown in some `bazel query` output formats, and computed defaults only execute when the value is omitted. If the macro needs to examine or modify an inherited attribute – for example, to add a value to an inherited `tags` attribute – you must make sure to handle the `None` case in the macro's implementation function. For example, the following macro inherits all attributes from `native.cc_library`, except for `cxxopts` (which is removed from the attribute list) and `copts` (which is given a new definition). It also takes care to checks for the default `None` value of the inherited `tags` attribute before appending an additional tag.  ``` def _my_cc_library_impl(name, visibility, tags, **kwargs):     # Append a tag; tags attr was inherited from native.cc_library, and     # therefore is None unless explicitly set by the caller of my_cc_library()     my_tags = (tags or []) + ["my_custom_tag"]     native.cc_library(         name = name,         visibility = visibility,         tags = my_tags,         **kwargs     )  my_cc_library = macro(     implementation = _my_cc_library_impl,     inherit_attrs = native.cc_library,     attrs = {         "cxxopts": None,         "copts": attr.string_list(default = ["-D_FOO"]),     }, ) ```   If `inherit_attrs` is set, the macro's implementation function *must* have a `**kwargs` residual keyword parameter. By convention, a macro should pass inherited, non-overridden attributes unchanged to the "main" rule or macro symbol which the macro is wrapping. Typically, most inherited attributes will not have a parameter in the implementation function's parameter list, and will simply be passed via `**kwargs`. It can be convenient for the implementation function to have explicit parameters for some inherited attributes (most commonly, `tags` and `testonly`) if the macro needs to pass those attributes to both "main" and non-"main" targets – but if the macro also needs to examine or manipulate those attributes, you must take care to handle the `None` default value of non-mandatory inherited attributes. |
-| `finalizer` | [bool](../core/bool); default is `False`  Whether this macro is a rule finalizer, which is a macro that, regardless of its position in a `BUILD` file, is evaluated at the end of package loading, after all non-finalizer targets have been defined. Unlike ordinary symbolic macros, rule finalizers may call [`native.existing_rule()`](../toplevel/native#existing_rule) and [`native.existing_rules()`](../toplevel/native#existing_rules) to query the set of *non-finalizer* rule targets defined in the current package. Note that `native.existing_rule()` and `native.existing_rules()` cannot access the targets defined by any rule finalizer, including this one. |
-| `doc` | [string](../core/string); or `None`; default is `None`  A description of the macro that can be extracted by documentation generating tools. |
+| `implementation` | [function](/versions/8.2.1/rules/lib/core/function); required  The Starlark function implementing this macro. The values of the macro's attributes are passed to the implementation function as keyword arguments. The implementation function must have at least two named parameters, `name` and `visibility`, and if the macro inherits attributes (see `inherit_attrs` below), it must have a `**kwargs` residual keyword parameter. By convention, the implementation function should have a named parameter for any attribute that the macro needs to examine, modify, or pass to non-"main" targets, while the "bulk" inherited attributes which will be passed to the "main" target unchanged are passed as `**kwargs`. The implementation function must not return a value. Instead, the implementation function *declares targets* by calling rule or macro symbols. The name of any target or inner symbolic macro declared by a symbolic macro (including by any Starlark function that the macro's implementation function transitively calls) must either equal `name` (this is referred to as the "main" target) or start with `name`, followed by a separator chracter (`"_"`, `"-"`, or `"."`) and a string suffix. (Targets violating this naming scheme are allowed to be declared, but cannot be built, configured, or depended upon.) By default, targets declared by a symbolic macro (including by any Starlark function that the macro's implementation function transitively calls) are visible only in the package containing the .bzl file defining the macro. To declare targets visible externally, *including to the caller of the symbolic macro*, the implementation function must set `visibility` appropriately – typically, by passing `visibility = visibility` to the rule or macro symbol being called. The following APIs are unavailable within a macro implementation function and any Starlark function it transitively calls:  * [`package()`, `licenses()`* `environment_group()`* [`native.glob()`](/versions/8.2.1/rules/lib/toplevel/native#glob) – instead, you may pass       a glob into the macro via a label list attribute* [`native.subpackages()`](/versions/8.2.1/rules/lib/toplevel/native#subpackages)* (allowed in rule finalizers only, see `finalizer` below)           [`native.existing_rules()`](/versions/8.2.1/rules/lib/toplevel/native#existing_rules),           [`native.existing_rule()`](/versions/8.2.1/rules/lib/toplevel/native#existing_rule)* (for `WORKSPACE` threads)             [`workspace()`](/versions/8.2.1/rules/lib/globals/workspace#workspace),             [`register_toolchains()`](/versions/8.2.1/rules/lib/globals/workspace#register_toolchains),             [`bind()`](/versions/8.2.1/rules/lib/globals/workspace#bind), [`register_execution_platforms()`](/versions/8.2.1/rules/lib/globals/workspace#register_execution_platforms), [repository rule instantiation](/versions/8.2.1/reference/be/workspace#repository_rule) |
+| `attrs` | [dict](/versions/8.2.1/rules/lib/core/dict); default is `{}`  A dictionary of the attributes this macro supports, analogous to [rule.attrs](#rule.attrs). Keys are attribute names, and values are either attribute objects like `attr.label_list(...)` (see the [attr](/versions/8.2.1/rules/lib/toplevel/attr) module), or `None`. A `None` entry means that the macro does not have an attribute by that name, even if it would have otherwise inherited one via `inherit_attrs` (see below). The special `name` attribute is predeclared and must not be included in the dictionary. The `visibility` attribute name is reserved and must not be included in the dictionary. Attributes whose names start with `_` are private -- they cannot be passed at the call site of the rule. Such attributes can be assigned a default value (as in `attr.label(default="//pkg:foo")`) to create an implicit dependency on a label. To limit memory usage, there is a cap on the number of attributes that may be declared. |
+| `inherit_attrs` | [rule](/versions/8.2.1/rules/lib/builtins/rule); or [macro](/versions/8.2.1/rules/lib/builtins/macro); or [string](/versions/8.2.1/rules/lib/core/string); or `None`; default is `None`  A rule symbol, macro symbol, or the name of a built-in common attribute list (see below) from which the macro should inherit attributes. If `inherit_attrs` is set to the string `"common"`, the macro will inherit [common rule attribute definitions](/versions/8.2.1/reference/be/common-definitions#common-attributes) used by all Starlark rules. Note that if the return value of `rule()` or `macro()` was not assigned to a global variable in a .bzl file, then such a value has not been registered as a rule or macro symbol, and therefore cannot be used for `inherit_attrs`. The inheritance mechanism works as follows:   1. The special `name` and `visibility` attributes are never inherited;- Hidden attributes (ones whose name starts with `"_"`) are never inherited;- Attributes whose names are already defined in the `attrs` dictionary are never        inherited (the entry in `attrs` takes precedence; note that an entry may be set to        `None` to ensure that no attribute by that name gets defined on the macro);- All other attributes are inherited from the rule or macro and effectively merged into the          `attrs` dict.   When a non-mandatory attribute is inherited, the default value of the attribute is overridden to be `None`, regardless of what it was specified in the original rule or macro. This ensures that when the macro forwards the attribute's value to an instance of the wrapped rule or macro – such as by passing in the unmodified `**kwargs` – a value that was absent from the outer macro's call will also be absent in the inner rule or macro's call (since passing `None` to an attribute is treated the same as omitting the attribute). This is important because omitting an attribute has subtly different semantics from passing its apparent default value. In particular, omitted attributes are not shown in some `bazel query` output formats, and computed defaults only execute when the value is omitted. If the macro needs to examine or modify an inherited attribute – for example, to add a value to an inherited `tags` attribute – you must make sure to handle the `None` case in the macro's implementation function. For example, the following macro inherits all attributes from `native.cc_library`, except for `cxxopts` (which is removed from the attribute list) and `copts` (which is given a new definition). It also takes care to checks for the default `None` value of the inherited `tags` attribute before appending an additional tag.  ``` def _my_cc_library_impl(name, visibility, tags, **kwargs):     # Append a tag; tags attr was inherited from native.cc_library, and     # therefore is None unless explicitly set by the caller of my_cc_library()     my_tags = (tags or []) + ["my_custom_tag"]     native.cc_library(         name = name,         visibility = visibility,         tags = my_tags,         **kwargs     )  my_cc_library = macro(     implementation = _my_cc_library_impl,     inherit_attrs = native.cc_library,     attrs = {         "cxxopts": None,         "copts": attr.string_list(default = ["-D_FOO"]),     }, ) ```   If `inherit_attrs` is set, the macro's implementation function *must* have a `**kwargs` residual keyword parameter. By convention, a macro should pass inherited, non-overridden attributes unchanged to the "main" rule or macro symbol which the macro is wrapping. Typically, most inherited attributes will not have a parameter in the implementation function's parameter list, and will simply be passed via `**kwargs`. It can be convenient for the implementation function to have explicit parameters for some inherited attributes (most commonly, `tags` and `testonly`) if the macro needs to pass those attributes to both "main" and non-"main" targets – but if the macro also needs to examine or manipulate those attributes, you must take care to handle the `None` default value of non-mandatory inherited attributes. |
+| `finalizer` | [bool](/versions/8.2.1/rules/lib/core/bool); default is `False`  Whether this macro is a rule finalizer, which is a macro that, regardless of its position in a `BUILD` file, is evaluated at the end of package loading, after all non-finalizer targets have been defined. Unlike ordinary symbolic macros, rule finalizers may call [`native.existing_rule()`](/versions/8.2.1/rules/lib/toplevel/native#existing_rule) and [`native.existing_rules()`](/versions/8.2.1/rules/lib/toplevel/native#existing_rules) to query the set of *non-finalizer* rule targets defined in the current package. Note that `native.existing_rule()` and `native.existing_rules()` cannot access the targets defined by any rule finalizer, including this one. |
+| `doc` | [string](/versions/8.2.1/rules/lib/core/string); or `None`; default is `None`  A description of the macro that can be extracted by documentation generating tools. |
 
 ## module\_extension
 
@@ -192,11 +192,11 @@ Creates a new module extension. Store it in a global value, so that it can be ex
 | Parameter | Description |
 | --- | --- |
 | `implementation` | callable; required  The function that implements this module extension. Must take a single parameter, `module_ctx`. The function is called once at the beginning of a build to determine the set of available repos. |
-| `tag_classes` | [dict](../core/dict); default is `{}`  A dictionary to declare all the tag classes used by the extension. It maps from the name of the tag class to a `tag_class` object. |
-| `doc` | [string](../core/string); or `None`; default is `None`  A description of the module extension that can be extracted by documentation generating tools. |
-| `environ` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  Provides a list of environment variable that this module extension depends on. If an environment variable in that list changes, the extension will be re-evaluated. |
-| `os_dependent` | [bool](../core/bool); default is `False`  Indicates whether this extension is OS-dependent or not |
-| `arch_dependent` | [bool](../core/bool); default is `False`  Indicates whether this extension is architecture-dependent or not |
+| `tag_classes` | [dict](/versions/8.2.1/rules/lib/core/dict); default is `{}`  A dictionary to declare all the tag classes used by the extension. It maps from the name of the tag class to a `tag_class` object. |
+| `doc` | [string](/versions/8.2.1/rules/lib/core/string); or `None`; default is `None`  A description of the module extension that can be extracted by documentation generating tools. |
+| `environ` | [sequence](/versions/8.2.1/rules/lib/core/list) of [string](/versions/8.2.1/rules/lib/core/string)s; default is `[]`  Provides a list of environment variable that this module extension depends on. If an environment variable in that list changes, the extension will be re-evaluated. |
+| `os_dependent` | [bool](/versions/8.2.1/rules/lib/core/bool); default is `False`  Indicates whether this extension is OS-dependent or not |
+| `arch_dependent` | [bool](/versions/8.2.1/rules/lib/core/bool); default is `False`  Indicates whether this extension is architecture-dependent or not |
 
 ## provider
 
@@ -219,16 +219,16 @@ def _my_library_impl(ctx):
 
 See [Rules (Providers)](https://bazel.build/versions/8.2.1/extending/rules#providers) for a comprehensive guide on how to use providers.
 
-Returns a [`Provider`](../builtins/Provider) callable value if `init` is not specified.
+Returns a [`Provider`](/versions/8.2.1/rules/lib/builtins/Provider) callable value if `init` is not specified.
 
-If `init` is specified, returns a tuple of 2 elements: a [`Provider`](../builtins/Provider) callable value and a *raw constructor* callable value. See  [Rules (Custom initialization of custom providers)](https://bazel.build/versions/8.2.1/extending/rules#custom_initialization_of_providers) and the discussion of the `init` parameter below for details.
+If `init` is specified, returns a tuple of 2 elements: a [`Provider`](/versions/8.2.1/rules/lib/builtins/Provider) callable value and a *raw constructor* callable value. See  [Rules (Custom initialization of custom providers)](https://bazel.build/versions/8.2.1/extending/rules#custom_initialization_of_providers) and the discussion of the `init` parameter below for details.
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `doc` | [string](../core/string); or `None`; default is `None` |
-| `fields` | [sequence](../core/list) of [string](../core/string)s; or [dict](../core/dict); or `None`; default is `None`  If specified, restricts the set of allowed fields.  Possible values are:  * list of fields:     ```   provider(fields = ['a', 'b'])   ```     * dictionary field name -> documentation:       ```     provider(            fields = { 'a' : 'Documentation for a', 'b' : 'Documentation for b' })     ```  All fields are optional. |
+| `doc` | [string](/versions/8.2.1/rules/lib/core/string); or `None`; default is `None` |
+| `fields` | [sequence](/versions/8.2.1/rules/lib/core/list) of [string](/versions/8.2.1/rules/lib/core/string)s; or [dict](/versions/8.2.1/rules/lib/core/dict); or `None`; default is `None`  If specified, restricts the set of allowed fields.  Possible values are:  * list of fields:     ```   provider(fields = ['a', 'b'])   ```     * dictionary field name -> documentation:       ```     provider(            fields = { 'a' : 'Documentation for a', 'b' : 'Documentation for b' })     ```  All fields are optional. |
 | `init` | callable; or `None`; default is `None` |
 
 ## repository\_rule
@@ -237,19 +237,19 @@ If `init` is specified, returns a tuple of 2 elements: a [`Provider`](../builtin
 callable repository_rule(implementation, *, attrs=None, local=False, environ=[], configure=False, remotable=False, doc=None)
 ```
 
-Creates a new repository rule. Store it in a global value, so that it can be loaded and called from a [`module_extension()`](#module_extension) implementation function, or used by [`use_repo_rule()`](../globals/module#use_repo_rule).
+Creates a new repository rule. Store it in a global value, so that it can be loaded and called from a [`module_extension()`](#module_extension) implementation function, or used by [`use_repo_rule()`](/versions/8.2.1/rules/lib/globals/module#use_repo_rule).
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
 | `implementation` | callable; required |
-| `attrs` | [dict](../core/dict); or `None`; default is `None` |
-| `local` | [bool](../core/bool); default is `False`  Indicate that this rule fetches everything from the local system and should be reevaluated at every fetch. |
-| `environ` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  **Deprecated**. This parameter has been deprecated. Migrate to `repository_ctx.getenv` instead. Provides a list of environment variable that this repository rule depends on. If an environment variable in that list change, the repository will be refetched. |
-| `configure` | [bool](../core/bool); default is `False`  Indicate that the repository inspects the system for configuration purpose |
-| `remotable` | [bool](../core/bool); default is `False`  **Experimental**. This parameter is experimental and may change at any time. Please do not depend on it. It may be enabled on an experimental basis by setting `--experimental_repo_remote_exec`  Compatible with remote execution |
-| `doc` | [string](../core/string); or `None`; default is `None` |
+| `attrs` | [dict](/versions/8.2.1/rules/lib/core/dict); or `None`; default is `None` |
+| `local` | [bool](/versions/8.2.1/rules/lib/core/bool); default is `False`  Indicate that this rule fetches everything from the local system and should be reevaluated at every fetch. |
+| `environ` | [sequence](/versions/8.2.1/rules/lib/core/list) of [string](/versions/8.2.1/rules/lib/core/string)s; default is `[]`  **Deprecated**. This parameter has been deprecated. Migrate to `repository_ctx.getenv` instead. Provides a list of environment variable that this repository rule depends on. If an environment variable in that list change, the repository will be refetched. |
+| `configure` | [bool](/versions/8.2.1/rules/lib/core/bool); default is `False`  Indicate that the repository inspects the system for configuration purpose |
+| `remotable` | [bool](/versions/8.2.1/rules/lib/core/bool); default is `False`  **Experimental**. This parameter is experimental and may change at any time. Please do not depend on it. It may be enabled on an experimental basis by setting `--experimental_repo_remote_exec`  Compatible with remote execution |
+| `doc` | [string](/versions/8.2.1/rules/lib/core/string); or `None`; default is `None` |
 
 ## rule
 
@@ -267,29 +267,29 @@ Test rules are required to have a name ending in `_test`, while all other rules
 
 | Parameter | Description |
 | --- | --- |
-| `implementation` | [function](../core/function); required  the Starlark function implementing this rule, must have exactly one parameter: [ctx](../builtins/ctx). The function is called during the analysis phase for each instance of the rule. It can access the attributes provided by the user. It must create actions to generate all the declared outputs. |
-| `test` | [bool](../core/bool); default is `unbound`  Whether this rule is a test rule, that is, whether it may be the subject of a `blaze test` command. All test rules are automatically considered [executable](#rule.executable); it is unnecessary (and discouraged) to explicitly set `executable = True` for a test rule. The value defaults to `False`. See the  [Rules page](https://bazel.build/versions/8.2.1/extending/rules#executable_rules_and_test_rules) for more information. |
-| `attrs` | [dict](../core/dict); default is `{}`  A dictionary to declare all the attributes of the rule. It maps from an attribute name to an attribute object (see [`attr`](../toplevel/attr) module). Attributes starting with `_` are private, and can be used to add an implicit dependency on a label. The attribute `name` is implicitly added and must not be specified. Attributes `visibility`, `deprecation`, `tags`, `testonly`, and `features` are implicitly added and cannot be overridden. Most rules need only a handful of attributes. To limit memory usage, there is a cap on the number of attributes that may be declared. Declared attributes will convert `None` to the default value. |
-| `outputs` | [dict](../core/dict); or `None`; or [function](../core/function); default is `None`  **Deprecated**. This parameter is deprecated and will be removed soon. Please do not depend on it. It is *disabled* with `--incompatible_no_rule_outputs_param`. Use this flag to verify your code is compatible with its imminent removal.  This parameter has been deprecated. Migrate rules to use `OutputGroupInfo` or `attr.output` instead. A schema for defining predeclared outputs. Unlike [`output`](../toplevel/attr#output) and [`output_list`](../toplevel/attr#output_list) attributes, the user does not specify the labels for these files. See the [Rules page](https://bazel.build/versions/8.2.1/extending/rules#files) for more on predeclared outputs. The value of this argument is either a dictionary or a callback function that produces a dictionary. The callback works similar to computed dependency attributes: The function's parameter names are matched against the rule's attributes, so for example if you pass `outputs = _my_func` with the definition `def _my_func(srcs, deps): ...`, the function has access to the attributes `srcs` and `deps`. Whether the dictionary is specified directly or via a function, it is interpreted as follows. Each entry in the dictionary creates a predeclared output where the key is an identifier and the value is a string template that determines the output's label. In the rule's implementation function, the identifier becomes the field name used to access the output's [`File`](../builtins/File) in [`ctx.outputs`](../builtins/ctx#outputs). The output's label has the same package as the rule, and the part after the package is produced by substituting each placeholder of the form `"%{ATTR}"` with a string formed from the value of the attribute `ATTR`:  * String-typed attributes are substituted verbatim.* Label-typed attributes become the part of the label after the package, minus the file extension. For example, the label `"//pkg:a/b.c"` becomes `"a/b"`.* Output-typed attributes become the part of the label after the package, including the file extension (for the above example, `"a/b.c"`).* All list-typed attributes (for example, `attr.label_list`) used in placeholders are required to have *exactly one element*. Their conversion is the same as their non-list version (`attr.label`).* Other attribute types may not appear in placeholders.* The special non-attribute placeholders `%{dirname}` and `%{basename}` expand to those parts of the rule's label, excluding its package. For example, in `"//pkg:a/b.c"`, the dirname is `a` and the basename is `b.c`.   In practice, the most common substitution placeholder is `"%{name}"`. For example, for a target named "foo", the outputs dict `{"bin": "%{name}.exe"}` predeclares an output named `foo.exe` that is accessible in the implementation function as `ctx.outputs.bin`. |
-| `executable` | [bool](../core/bool); default is `unbound` |
-| `output_to_genfiles` | [bool](../core/bool); default is `False`  If true, the files will be generated in the genfiles directory instead of the bin directory. Unless you need it for compatibility with existing rules (e.g. when generating header files for C++), do not set this flag. |
-| `fragments` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  List of names of configuration fragments that the rule requires in target configuration. |
-| `host_fragments` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  List of names of configuration fragments that the rule requires in host configuration. |
-| `_skylark_testable` | [bool](../core/bool); default is `False`  *(Experimental)*  If true, this rule will expose its actions for inspection by rules that depend on it via an `Actions` provider. The provider is also available to the rule itself by calling [ctx.created\_actions()](../builtins/ctx#created_actions).  This should only be used for testing the analysis-time behavior of Starlark rules. This flag may be removed in the future. |
-| `toolchains` | [sequence](../core/list); default is `[]`  If set, the set of toolchains this rule requires. The list can contain String, Label, or StarlarkToolchainTypeApi objects, in any combination. Toolchains will be found by checking the current platform, and provided to the rule implementation via `ctx.toolchain`. |
-| `incompatible_use_toolchain_transition` | [bool](../core/bool); default is `False`  Deprecated, this is no longer in use and should be removed. |
-| `doc` | [string](../core/string); or `None`; default is `None`  A description of the rule that can be extracted by documentation generating tools. |
-| `provides` | [sequence](../core/list); default is `[]`  A list of providers that the implementation function must return. It is an error if the implementation function omits any of the types of providers listed here from its return value. However, the implementation function may return additional providers not listed here. Each element of the list is an `*Info` object returned by [`provider()`](../globals/bzl#provider), except that a legacy provider is represented by its string name instead.When a target of the rule is used as a dependency for a target that declares a required provider, it is not necessary to specify that provider here. It is enough that the implementation function returns it. However, it is considered best practice to specify it, even though this is not required. The [`required_providers`](../globals/bzl#aspect.required_providers) field of an [aspect](../globals/bzl#aspect) does, however, require that providers are specified here. |
-| `dependency_resolution_rule` | [bool](../core/bool); default is `False`  If set, the rule can be a dependency through attributes also marked as available in materializers. Every attribute of rules with this flag set must be marked as available in materializers also. This is so that rules so marked cannot depend on rules that are not so marked. |
-| `exec_compatible_with` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  A list of constraints on the execution platform that apply to all targets of this rule type. |
-| `analysis_test` | [bool](../core/bool); default is `False`  If true, then this rule is treated as an analysis test. Note: Analysis test rules are primarily defined using infrastructure provided in core Starlark libraries. See [Testing](https://bazel.build/versions/8.2.1/rules/testing#testing-rules) for guidance. If a rule is defined as an analysis test rule, it becomes allowed to use configuration transitions defined using [analysis\_test\_transition](#analysis_test_transition) on its attributes, but opts into some restrictions:  * Targets of this rule are limited in the number of transitive dependencies they may have.* The rule is considered a test rule (as if `test=True` were set). This supersedes the value of `test`   * The rule implementation function may not register actions. Instead, it must register a pass/fail result via providing [AnalysisTestResultInfo](../providers/AnalysisTestResultInfo). |
-| `build_setting` | [BuildSetting](../builtins/BuildSetting); or `None`; default is `None`  If set, describes what kind of [`build setting`](/versions/8.2.1/rules/config#user-defined-build-settings) this rule is. See the [`config`](../toplevel/config) module. If this is set, a mandatory attribute named "build\_setting\_default" is automatically added to this rule, with a type corresponding to the value passed in here. |
+| `implementation` | [function](/versions/8.2.1/rules/lib/core/function); required  the Starlark function implementing this rule, must have exactly one parameter: [ctx](/versions/8.2.1/rules/lib/builtins/ctx). The function is called during the analysis phase for each instance of the rule. It can access the attributes provided by the user. It must create actions to generate all the declared outputs. |
+| `test` | [bool](/versions/8.2.1/rules/lib/core/bool); default is `unbound`  Whether this rule is a test rule, that is, whether it may be the subject of a `blaze test` command. All test rules are automatically considered [executable](#rule.executable); it is unnecessary (and discouraged) to explicitly set `executable = True` for a test rule. The value defaults to `False`. See the  [Rules page](https://bazel.build/versions/8.2.1/extending/rules#executable_rules_and_test_rules) for more information. |
+| `attrs` | [dict](/versions/8.2.1/rules/lib/core/dict); default is `{}`  A dictionary to declare all the attributes of the rule. It maps from an attribute name to an attribute object (see [`attr`](/versions/8.2.1/rules/lib/toplevel/attr) module). Attributes starting with `_` are private, and can be used to add an implicit dependency on a label. The attribute `name` is implicitly added and must not be specified. Attributes `visibility`, `deprecation`, `tags`, `testonly`, and `features` are implicitly added and cannot be overridden. Most rules need only a handful of attributes. To limit memory usage, there is a cap on the number of attributes that may be declared. Declared attributes will convert `None` to the default value. |
+| `outputs` | [dict](/versions/8.2.1/rules/lib/core/dict); or `None`; or [function](/versions/8.2.1/rules/lib/core/function); default is `None`  **Deprecated**. This parameter is deprecated and will be removed soon. Please do not depend on it. It is *disabled* with `--incompatible_no_rule_outputs_param`. Use this flag to verify your code is compatible with its imminent removal.  This parameter has been deprecated. Migrate rules to use `OutputGroupInfo` or `attr.output` instead. A schema for defining predeclared outputs. Unlike [`output`](/versions/8.2.1/rules/lib/toplevel/attr#output) and [`output_list`](/versions/8.2.1/rules/lib/toplevel/attr#output_list) attributes, the user does not specify the labels for these files. See the [Rules page](https://bazel.build/versions/8.2.1/extending/rules#files) for more on predeclared outputs. The value of this argument is either a dictionary or a callback function that produces a dictionary. The callback works similar to computed dependency attributes: The function's parameter names are matched against the rule's attributes, so for example if you pass `outputs = _my_func` with the definition `def _my_func(srcs, deps): ...`, the function has access to the attributes `srcs` and `deps`. Whether the dictionary is specified directly or via a function, it is interpreted as follows. Each entry in the dictionary creates a predeclared output where the key is an identifier and the value is a string template that determines the output's label. In the rule's implementation function, the identifier becomes the field name used to access the output's [`File`](/versions/8.2.1/rules/lib/builtins/File) in [`ctx.outputs`](/versions/8.2.1/rules/lib/builtins/ctx#outputs). The output's label has the same package as the rule, and the part after the package is produced by substituting each placeholder of the form `"%{ATTR}"` with a string formed from the value of the attribute `ATTR`:  * String-typed attributes are substituted verbatim.* Label-typed attributes become the part of the label after the package, minus the file extension. For example, the label `"//pkg:a/b.c"` becomes `"a/b"`.* Output-typed attributes become the part of the label after the package, including the file extension (for the above example, `"a/b.c"`).* All list-typed attributes (for example, `attr.label_list`) used in placeholders are required to have *exactly one element*. Their conversion is the same as their non-list version (`attr.label`).* Other attribute types may not appear in placeholders.* The special non-attribute placeholders `%{dirname}` and `%{basename}` expand to those parts of the rule's label, excluding its package. For example, in `"//pkg:a/b.c"`, the dirname is `a` and the basename is `b.c`.   In practice, the most common substitution placeholder is `"%{name}"`. For example, for a target named "foo", the outputs dict `{"bin": "%{name}.exe"}` predeclares an output named `foo.exe` that is accessible in the implementation function as `ctx.outputs.bin`. |
+| `executable` | [bool](/versions/8.2.1/rules/lib/core/bool); default is `unbound` |
+| `output_to_genfiles` | [bool](/versions/8.2.1/rules/lib/core/bool); default is `False`  If true, the files will be generated in the genfiles directory instead of the bin directory. Unless you need it for compatibility with existing rules (e.g. when generating header files for C++), do not set this flag. |
+| `fragments` | [sequence](/versions/8.2.1/rules/lib/core/list) of [string](/versions/8.2.1/rules/lib/core/string)s; default is `[]`  List of names of configuration fragments that the rule requires in target configuration. |
+| `host_fragments` | [sequence](/versions/8.2.1/rules/lib/core/list) of [string](/versions/8.2.1/rules/lib/core/string)s; default is `[]`  List of names of configuration fragments that the rule requires in host configuration. |
+| `_skylark_testable` | [bool](/versions/8.2.1/rules/lib/core/bool); default is `False`  *(Experimental)*  If true, this rule will expose its actions for inspection by rules that depend on it via an `Actions` provider. The provider is also available to the rule itself by calling [ctx.created\_actions()](/versions/8.2.1/rules/lib/builtins/ctx#created_actions).  This should only be used for testing the analysis-time behavior of Starlark rules. This flag may be removed in the future. |
+| `toolchains` | [sequence](/versions/8.2.1/rules/lib/core/list); default is `[]`  If set, the set of toolchains this rule requires. The list can contain String, Label, or StarlarkToolchainTypeApi objects, in any combination. Toolchains will be found by checking the current platform, and provided to the rule implementation via `ctx.toolchain`. |
+| `incompatible_use_toolchain_transition` | [bool](/versions/8.2.1/rules/lib/core/bool); default is `False`  Deprecated, this is no longer in use and should be removed. |
+| `doc` | [string](/versions/8.2.1/rules/lib/core/string); or `None`; default is `None`  A description of the rule that can be extracted by documentation generating tools. |
+| `provides` | [sequence](/versions/8.2.1/rules/lib/core/list); default is `[]`  A list of providers that the implementation function must return. It is an error if the implementation function omits any of the types of providers listed here from its return value. However, the implementation function may return additional providers not listed here. Each element of the list is an `*Info` object returned by [`provider()`](/versions/8.2.1/rules/lib/globals/bzl#provider), except that a legacy provider is represented by its string name instead.When a target of the rule is used as a dependency for a target that declares a required provider, it is not necessary to specify that provider here. It is enough that the implementation function returns it. However, it is considered best practice to specify it, even though this is not required. The [`required_providers`](/versions/8.2.1/rules/lib/globals/bzl#aspect.required_providers) field of an [aspect](/versions/8.2.1/rules/lib/globals/bzl#aspect) does, however, require that providers are specified here. |
+| `dependency_resolution_rule` | [bool](/versions/8.2.1/rules/lib/core/bool); default is `False`  If set, the rule can be a dependency through attributes also marked as available in materializers. Every attribute of rules with this flag set must be marked as available in materializers also. This is so that rules so marked cannot depend on rules that are not so marked. |
+| `exec_compatible_with` | [sequence](/versions/8.2.1/rules/lib/core/list) of [string](/versions/8.2.1/rules/lib/core/string)s; default is `[]`  A list of constraints on the execution platform that apply to all targets of this rule type. |
+| `analysis_test` | [bool](/versions/8.2.1/rules/lib/core/bool); default is `False`  If true, then this rule is treated as an analysis test. Note: Analysis test rules are primarily defined using infrastructure provided in core Starlark libraries. See [Testing](https://bazel.build/versions/8.2.1/rules/testing#testing-rules) for guidance. If a rule is defined as an analysis test rule, it becomes allowed to use configuration transitions defined using [analysis\_test\_transition](#analysis_test_transition) on its attributes, but opts into some restrictions:  * Targets of this rule are limited in the number of transitive dependencies they may have.* The rule is considered a test rule (as if `test=True` were set). This supersedes the value of `test`   * The rule implementation function may not register actions. Instead, it must register a pass/fail result via providing [AnalysisTestResultInfo](/versions/8.2.1/rules/lib/providers/AnalysisTestResultInfo). |
+| `build_setting` | [BuildSetting](/versions/8.2.1/rules/lib/builtins/BuildSetting); or `None`; default is `None`  If set, describes what kind of [`build setting`](/versions/8.2.1/rules/config#user-defined-build-settings) this rule is. See the [`config`](/versions/8.2.1/rules/lib/toplevel/config) module. If this is set, a mandatory attribute named "build\_setting\_default" is automatically added to this rule, with a type corresponding to the value passed in here. |
 | `cfg` | default is `None`  If set, points to the configuration transition the rule will apply to its own configuration before analysis. |
-| `exec_groups` | [dict](../core/dict); or `None`; default is `None`  Dict of execution group name (string) to [`exec_group`s](../globals/bzl#exec_group). If set, allows rules to run actions on multiple execution platforms within a single target. See [execution groups documentation](/versions/8.2.1/reference/exec-groups) for more info. |
+| `exec_groups` | [dict](/versions/8.2.1/rules/lib/core/dict); or `None`; default is `None`  Dict of execution group name (string) to [`exec_group`s](/versions/8.2.1/rules/lib/globals/bzl#exec_group). If set, allows rules to run actions on multiple execution platforms within a single target. See [execution groups documentation](/versions/8.2.1/reference/exec-groups) for more info. |
 | `initializer` | default is `None`  Experimental: the Stalark function initializing the attributes of the rule. The function is called at load time for each instance of the rule. It's called with `name` and the values of public attributes defined by the rule (not with generic attributes, for example `tags`). It has to return a dictionary from the attribute names to the desired values. The attributes that are not returned are unaffected. Returning `None` as value results in using the default value specified in the attribute definition. Initializers are evaluated before the default values specified in an attribute definition. Consequently, if a parameter in the initializer's signature contains a default values, it overwrites the default from the attribute definition (except if returning `None`). Similarly, if a parameter in the initializer's signature doesn't have a default, the parameter will become mandatory. It's a good practice to omit default/mandatory settings on an attribute definition in such cases. It's a good practice to use `**kwargs` for attributes that are not handled. In case of extended rules, all initializers are called proceeding from child to ancestors. Each initializer is passed only the public attributes it knows about. |
 | `parent` | default is `None`  Experimental: the Stalark rule that is extended. When set the public attributes are merged as well as advertised providers. The rule matches `executable` and `test` from the parent. Values of `fragments`, `toolchains`, `exec_compatible_with`, and `exec_groups` are merged. Legacy or deprecated parameters may not be set. Incoming configuration transition `cfg` of parent is applied after thisrule's incoming configuration. |
-| `extendable` | [bool](../core/bool); or [Label](../builtins/Label); or [string](../core/string); or `None`; default is `None`  Experimental: A label of an allowlist defining which rules can extending this rule. It can be set also to True/False to always allow/disallow extending. Bazel defaults to always allowing extensions. |
-| `subrules` | [sequence](../core/list) of [Subrule](../builtins/Subrule)s; default is `[]`  Experimental: List of subrules used by this rule. |
+| `extendable` | [bool](/versions/8.2.1/rules/lib/core/bool); or [Label](/versions/8.2.1/rules/lib/builtins/Label); or [string](/versions/8.2.1/rules/lib/core/string); or `None`; default is `None`  Experimental: A label of an allowlist defining which rules can extending this rule. It can be set also to True/False to always allow/disallow extending. Bazel defaults to always allowing extensions. |
+| `subrules` | [sequence](/versions/8.2.1/rules/lib/core/list) of [Subrule](/versions/8.2.1/rules/lib/builtins/Subrule)s; default is `[]`  Experimental: List of subrules used by this rule. |
 
 ## select
 
@@ -303,8 +303,8 @@ unknown select(x, no_match_error='')
 
 | Parameter | Description |
 | --- | --- |
-| `x` | [dict](../core/dict); required  A dict that maps configuration conditions to values. Each key is a [Label](../builtins/Label) or a label string that identifies a config\_setting or constraint\_value instance. See the [documentation on macros](https://bazel.build/versions/8.2.1/rules/macros#label-resolution) for when to use a Label instead of a string. |
-| `no_match_error` | [string](../core/string); default is `''`  Optional custom error to report if no condition matches. |
+| `x` | [dict](/versions/8.2.1/rules/lib/core/dict); required  A dict that maps configuration conditions to values. Each key is a [Label](/versions/8.2.1/rules/lib/builtins/Label) or a label string that identifies a config\_setting or constraint\_value instance. See the [documentation on macros](https://bazel.build/versions/8.2.1/rules/macros#label-resolution) for when to use a Label instead of a string. |
+| `no_match_error` | [string](/versions/8.2.1/rules/lib/core/string); default is `''`  Optional custom error to report if no condition matches. |
 
 ## subrule
 
@@ -318,11 +318,11 @@ Constructs a new instance of a subrule. The result of this function must be stor
 
 | Parameter | Description |
 | --- | --- |
-| `implementation` | [function](../core/function); required  The Starlark function implementing this subrule |
-| `attrs` | [dict](../core/dict); default is `{}`  A dictionary to declare all the (private) attributes of the subrule.  Subrules may only have private attributes that are label-typed (i.e. label or label-list). The resolved values corresponding to these labels are automatically passed by Bazel to the subrule's implementation function as named arguments (thus the implementation function is required to accept named parameters matching the attribute names). The types of these values will be:  * `FilesToRunProvider` for label attributes with `executable=True` * `File` for label attributes with `allow_single_file=True` * `Target` for all other label attributes * `[Target]` for all label-list attributes |
-| `toolchains` | [sequence](../core/list); default is `[]`  If set, the set of toolchains this subrule requires. The list can contain String, Label, or StarlarkToolchainTypeApi objects, in any combination. Toolchains will be found by checking the current platform, and provided to the subrule implementation via `ctx.toolchains`. Note that AEGs need to be enabled on the consuming rule(s) if this parameter is set. In case you haven't migrated to AEGs yet, see https://bazel.build/extending/auto-exec-groups#migration-aegs. |
-| `fragments` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  List of names of configuration fragments that the subrule requires in target configuration. |
-| `subrules` | [sequence](../core/list) of [Subrule](../builtins/Subrule)s; default is `[]`  List of other subrules needed by this subrule. |
+| `implementation` | [function](/versions/8.2.1/rules/lib/core/function); required  The Starlark function implementing this subrule |
+| `attrs` | [dict](/versions/8.2.1/rules/lib/core/dict); default is `{}`  A dictionary to declare all the (private) attributes of the subrule.  Subrules may only have private attributes that are label-typed (i.e. label or label-list). The resolved values corresponding to these labels are automatically passed by Bazel to the subrule's implementation function as named arguments (thus the implementation function is required to accept named parameters matching the attribute names). The types of these values will be:  * `FilesToRunProvider` for label attributes with `executable=True` * `File` for label attributes with `allow_single_file=True` * `Target` for all other label attributes * `[Target]` for all label-list attributes |
+| `toolchains` | [sequence](/versions/8.2.1/rules/lib/core/list); default is `[]`  If set, the set of toolchains this subrule requires. The list can contain String, Label, or StarlarkToolchainTypeApi objects, in any combination. Toolchains will be found by checking the current platform, and provided to the subrule implementation via `ctx.toolchains`. Note that AEGs need to be enabled on the consuming rule(s) if this parameter is set. In case you haven't migrated to AEGs yet, see https://bazel.build/extending/auto-exec-groups#migration-aegs. |
+| `fragments` | [sequence](/versions/8.2.1/rules/lib/core/list) of [string](/versions/8.2.1/rules/lib/core/string)s; default is `[]`  List of names of configuration fragments that the subrule requires in target configuration. |
+| `subrules` | [sequence](/versions/8.2.1/rules/lib/core/list) of [Subrule](/versions/8.2.1/rules/lib/builtins/Subrule)s; default is `[]`  List of other subrules needed by this subrule. |
 
 ## tag\_class
 
@@ -336,8 +336,8 @@ Creates a new tag\_class object, which defines an attribute schema for a class o
 
 | Parameter | Description |
 | --- | --- |
-| `attrs` | [dict](../core/dict); default is `{}`  A dictionary to declare all the attributes of this tag class. It maps from an attribute name to an attribute object (see [attr](../toplevel/attr) module). Note that unlike [`rule()`](../globals/bzl#rule), [`aspect()`](../globals/bzl#aspect) and [`repository_rule()`](../globals/bzl#repository_rule), declared attributes will not convert `None` to the default value. For the default to be used, the attribute must be omitted entirely by the caller. |
-| `doc` | [string](../core/string); or `None`; default is `None`  A description of the tag class that can be extracted by documentation generating tools. |
+| `attrs` | [dict](/versions/8.2.1/rules/lib/core/dict); default is `{}`  A dictionary to declare all the attributes of this tag class. It maps from an attribute name to an attribute object (see [attr](/versions/8.2.1/rules/lib/toplevel/attr) module). Note that unlike [`rule()`](/versions/8.2.1/rules/lib/globals/bzl#rule), [`aspect()`](/versions/8.2.1/rules/lib/globals/bzl#aspect) and [`repository_rule()`](/versions/8.2.1/rules/lib/globals/bzl#repository_rule), declared attributes will not convert `None` to the default value. For the default to be used, the attribute must be omitted entirely by the caller. |
+| `doc` | [string](/versions/8.2.1/rules/lib/core/string); or `None`; default is `None`  A description of the tag class that can be extracted by documentation generating tools. |
 
 ## visibility
 
diff --git a/versions/8.2.1/rules/lib/globals/module.mdx b/versions/8.2.1/rules/lib/globals/module.mdx
index 0af5f86f..cc221f3b 100644
--- a/versions/8.2.1/rules/lib/globals/module.mdx
+++ b/versions/8.2.1/rules/lib/globals/module.mdx
@@ -30,7 +30,7 @@ None archive_override(module_name, **kwargs)
 
 Specifies that this dependency should come from an archive file (zip, gzip, etc) at a
 certain location, instead of from a registry. Effectively, this dependency will be
-backed by an [`http_archive`](../repo/http#http_archive) rule.
+backed by an [`http_archive`](/versions/8.2.1/rules/lib/repo/http#http_archive) rule.
 
 This directive only takes effect in the root module; in other words, if a module is
 used as a dependency by others, its own overrides are ignored.
@@ -39,7 +39,7 @@ used as a dependency by others, its own overrides are ignored.
 
 | Parameter | Description |
 | --- | --- |
-| `module_name` | [string](../core/string); required  The name of the Bazel module dependency to apply this override to. |
+| `module_name` | [string](/versions/8.2.1/rules/lib/core/string); required  The name of the Bazel module dependency to apply this override to. |
 | `kwargs` | required  All other arguments are forwarded to the underlying `http_archive` repo rule. Note that the `name` attribute shouldn't be specified; use `module_name` instead. |
 
 ## bazel\_dep
@@ -54,11 +54,11 @@ Declares a direct dependency on another Bazel module.
 
 | Parameter | Description |
 | --- | --- |
-| `name` | [string](../core/string); required  The name of the module to be added as a direct dependency. |
-| `version` | [string](../core/string); default is `''`  The version of the module to be added as a direct dependency. |
-| `max_compatibility_level` | [int](../core/int); default is `-1`  The maximum `compatibility_level` supported for the module to be added as a direct dependency. The version of the module implies the minimum compatibility\_level supported, as well as the maximum if this attribute is not specified. |
-| `repo_name` | [string](../core/string); or `None`; default is `''`  The name of the external repo representing this dependency. This is by default the name of the module. Can be set to `None` to make this dependency a "*nodep*" dependency: in this case, this `bazel_dep` specification is only honored if the target module already exists in the dependency graph by some other means. |
-| `dev_dependency` | [bool](../core/bool); default is `False`  If true, this dependency will be ignored if the current module is not the root module or `--ignore_dev_dependency` is enabled. |
+| `name` | [string](/versions/8.2.1/rules/lib/core/string); required  The name of the module to be added as a direct dependency. |
+| `version` | [string](/versions/8.2.1/rules/lib/core/string); default is `''`  The version of the module to be added as a direct dependency. |
+| `max_compatibility_level` | [int](/versions/8.2.1/rules/lib/core/int); default is `-1`  The maximum `compatibility_level` supported for the module to be added as a direct dependency. The version of the module implies the minimum compatibility\_level supported, as well as the maximum if this attribute is not specified. |
+| `repo_name` | [string](/versions/8.2.1/rules/lib/core/string); or `None`; default is `''`  The name of the external repo representing this dependency. This is by default the name of the module. Can be set to `None` to make this dependency a "*nodep*" dependency: in this case, this `bazel_dep` specification is only honored if the target module already exists in the dependency graph by some other means. |
+| `dev_dependency` | [bool](/versions/8.2.1/rules/lib/core/bool); default is `False`  If true, this dependency will be ignored if the current module is not the root module or `--ignore_dev_dependency` is enabled. |
 
 ## git\_override
 
@@ -68,7 +68,7 @@ None git_override(module_name, **kwargs)
 
 Specifies that this dependency should come from a certain commit in a Git repository,
 instead of from a registry. Effectively, this dependency will be backed by a
-[`git_repository`](../repo/git#git_repository) rule.
+[`git_repository`](/versions/8.2.1/rules/lib/repo/git#git_repository) rule.
 
 This directive only takes effect in the root module; in other words, if a module is
 used as a dependency by others, its own overrides are ignored.
@@ -77,7 +77,7 @@ used as a dependency by others, its own overrides are ignored.
 
 | Parameter | Description |
 | --- | --- |
-| `module_name` | [string](../core/string); required  The name of the Bazel module dependency to apply this override to. |
+| `module_name` | [string](/versions/8.2.1/rules/lib/core/string); required  The name of the Bazel module dependency to apply this override to. |
 | `kwargs` | required  All other arguments are forwarded to the underlying `git_repository` repo rule. Note that the `name` attribute shouldn't be specified; use `module_name` instead. |
 
 ## include
@@ -98,7 +98,7 @@ Only files in the main repo may be included.
 
 | Parameter | Description |
 | --- | --- |
-| `label` | [string](../core/string); required  The label pointing to the file to include. The label must point to a file in the main repo; in other words, it **must **start with double slashes (`//`). The name of the file must end with `.MODULE.bazel` and must not start with `.`.**** |
+| `label` | [string](/versions/8.2.1/rules/lib/core/string); required  The label pointing to the file to include. The label must point to a file in the main repo; in other words, it **must **start with double slashes (`//`). The name of the file must end with `.MODULE.bazel` and must not start with `.`.**** |
 
 ## inject\_repo
 
@@ -138,8 +138,8 @@ used as a dependency by others, its own overrides are ignored.
 
 | Parameter | Description |
 | --- | --- |
-| `module_name` | [string](../core/string); required  The name of the Bazel module dependency to apply this override to. |
-| `path` | [string](../core/string); required  The path to the directory where this module is. |
+| `module_name` | [string](/versions/8.2.1/rules/lib/core/string); required  The name of the Bazel module dependency to apply this override to. |
+| `path` | [string](/versions/8.2.1/rules/lib/core/string); required  The path to the directory where this module is. |
 
 ## module
 
@@ -155,11 +155,11 @@ It should be called at most once, and if called, it must be the very first direc
 
 | Parameter | Description |
 | --- | --- |
-| `name` | [string](../core/string); default is `''`  The name of the module. Can be omitted only if this module is the root module (as in, if it's not going to be depended on by another module). A valid module name must: 1) only contain lowercase letters (a-z), digits (0-9), dots (.), hyphens (-), and underscores (\_); 2) begin with a lowercase letter; 3) end with a lowercase letter or digit. |
-| `version` | [string](../core/string); default is `''`  The version of the module. Can be omitted only if this module is the root module (as in, if it's not going to be depended on by another module). The version must be in a relaxed SemVer format; see [the documentation](/versions/8.2.1/external/module#version_format) for more details. |
-| `compatibility_level` | [int](../core/int); default is `0`  The compatibility level of the module; this should be changed every time a major incompatible change is introduced. This is essentially the "major version" of the module in terms of SemVer, except that it's not embedded in the version string itself, but exists as a separate field. Modules with different compatibility levels participate in version resolution as if they're modules with different names, but the final dependency graph cannot contain multiple modules with the same name but different compatibility levels (unless `multiple_version_override` is in effect). See [the documentation](/versions/8.2.1/external/module#compatibility_level) for more details. |
-| `repo_name` | [string](../core/string); default is `''`  The name of the repository representing this module, as seen by the module itself. By default, the name of the repo is the name of the module. This can be specified to ease migration for projects that have been using a repo name for itself that differs from its module name. |
-| `bazel_compatibility` | Iterable of [string](../core/string)s; default is `[]`  A list of bazel versions that allows users to declare which Bazel versions are compatible with this module. It does NOT affect dependency resolution, but bzlmod will use this information to check if your current Bazel version is compatible. The format of this value is a string of some constraint values separated by comma. Three constraints are supported: `\<=X.X.X`: The Bazel version must be equal or older than X.X.X. Used when there is a known incompatible change in a newer version. `\>=X.X.X`: The Bazel version must be equal or newer than X.X.X.Used when you depend on some features that are only available since X.X.X. `-X.X.X`: The Bazel version X.X.X is not compatible. Used when there is a bug in X.X.X that breaks you, but fixed in later versions. |
+| `name` | [string](/versions/8.2.1/rules/lib/core/string); default is `''`  The name of the module. Can be omitted only if this module is the root module (as in, if it's not going to be depended on by another module). A valid module name must: 1) only contain lowercase letters (a-z), digits (0-9), dots (.), hyphens (-), and underscores (\_); 2) begin with a lowercase letter; 3) end with a lowercase letter or digit. |
+| `version` | [string](/versions/8.2.1/rules/lib/core/string); default is `''`  The version of the module. Can be omitted only if this module is the root module (as in, if it's not going to be depended on by another module). The version must be in a relaxed SemVer format; see [the documentation](/versions/8.2.1/external/module#version_format) for more details. |
+| `compatibility_level` | [int](/versions/8.2.1/rules/lib/core/int); default is `0`  The compatibility level of the module; this should be changed every time a major incompatible change is introduced. This is essentially the "major version" of the module in terms of SemVer, except that it's not embedded in the version string itself, but exists as a separate field. Modules with different compatibility levels participate in version resolution as if they're modules with different names, but the final dependency graph cannot contain multiple modules with the same name but different compatibility levels (unless `multiple_version_override` is in effect). See [the documentation](/versions/8.2.1/external/module#compatibility_level) for more details. |
+| `repo_name` | [string](/versions/8.2.1/rules/lib/core/string); default is `''`  The name of the repository representing this module, as seen by the module itself. By default, the name of the repo is the name of the module. This can be specified to ease migration for projects that have been using a repo name for itself that differs from its module name. |
+| `bazel_compatibility` | Iterable of [string](/versions/8.2.1/rules/lib/core/string)s; default is `[]`  A list of bazel versions that allows users to declare which Bazel versions are compatible with this module. It does NOT affect dependency resolution, but bzlmod will use this information to check if your current Bazel version is compatible. The format of this value is a string of some constraint values separated by comma. Three constraints are supported: `\<=X.X.X`: The Bazel version must be equal or older than X.X.X. Used when there is a known incompatible change in a newer version. `\>=X.X.X`: The Bazel version must be equal or newer than X.X.X.Used when you depend on some features that are only available since X.X.X. `-X.X.X`: The Bazel version X.X.X is not compatible. Used when there is a bug in X.X.X that breaks you, but fixed in later versions. |
 
 ## multiple\_version\_override
 
@@ -173,9 +173,9 @@ Specifies that a dependency should still come from a registry, but multiple vers
 
 | Parameter | Description |
 | --- | --- |
-| `module_name` | [string](../core/string); required  The name of the Bazel module dependency to apply this override to. |
-| `versions` | Iterable of [string](../core/string)s; required  Explicitly specifies the versions allowed to coexist. These versions must already be present in the dependency graph pre-selection. Dependencies on this module will be "upgraded" to the nearest higher allowed version at the same compatibility level, whereas dependencies that have a higher version than any allowed versions at the same compatibility level will cause an error. |
-| `registry` | [string](../core/string); default is `''`  Overrides the registry for this module; instead of finding this module from the default list of registries, the given registry should be used. |
+| `module_name` | [string](/versions/8.2.1/rules/lib/core/string); required  The name of the Bazel module dependency to apply this override to. |
+| `versions` | Iterable of [string](/versions/8.2.1/rules/lib/core/string)s; required  Explicitly specifies the versions allowed to coexist. These versions must already be present in the dependency graph pre-selection. Dependencies on this module will be "upgraded" to the nearest higher allowed version at the same compatibility level, whereas dependencies that have a higher version than any allowed versions at the same compatibility level will cause an error. |
+| `registry` | [string](/versions/8.2.1/rules/lib/core/string); default is `''`  Overrides the registry for this module; instead of finding this module from the default list of registries, the given registry should be used. |
 
 ## override\_repo
 
@@ -209,8 +209,8 @@ Specifies already-defined execution platforms to be registered when this module
 
 | Parameter | Description |
 | --- | --- |
-| `dev_dependency` | [bool](../core/bool); default is `False`  If true, the execution platforms will not be registered if the current module is not the root module or `--ignore\_dev\_dependency` is enabled. |
-| `platform_labels` | [sequence](../core/list) of [string](../core/string)s; required  The target patterns to register. |
+| `dev_dependency` | [bool](/versions/8.2.1/rules/lib/core/bool); default is `False`  If true, the execution platforms will not be registered if the current module is not the root module or `--ignore\_dev\_dependency` is enabled. |
+| `platform_labels` | [sequence](/versions/8.2.1/rules/lib/core/list) of [string](/versions/8.2.1/rules/lib/core/string)s; required  The target patterns to register. |
 
 ## register\_toolchains
 
@@ -224,8 +224,8 @@ Specifies already-defined toolchains to be registered when this module is select
 
 | Parameter | Description |
 | --- | --- |
-| `dev_dependency` | [bool](../core/bool); default is `False`  If true, the toolchains will not be registered if the current module is not the root module or `--ignore\_dev\_dependency` is enabled. |
-| `toolchain_labels` | [sequence](../core/list) of [string](../core/string)s; required  The target patterns to register. |
+| `dev_dependency` | [bool](/versions/8.2.1/rules/lib/core/bool); default is `False`  If true, the toolchains will not be registered if the current module is not the root module or `--ignore\_dev\_dependency` is enabled. |
+| `toolchain_labels` | [sequence](/versions/8.2.1/rules/lib/core/list) of [string](/versions/8.2.1/rules/lib/core/string)s; required  The target patterns to register. |
 
 ## single\_version\_override
 
@@ -239,12 +239,12 @@ Specifies that a dependency should still come from a registry, but its version s
 
 | Parameter | Description |
 | --- | --- |
-| `module_name` | [string](../core/string); required  The name of the Bazel module dependency to apply this override to. |
-| `version` | [string](../core/string); default is `''`  Overrides the declared version of this module in the dependency graph. In other words, this module will be "pinned" to this override version. This attribute can be omitted if all one wants to override is the registry or the patches. |
-| `registry` | [string](../core/string); default is `''`  Overrides the registry for this module; instead of finding this module from the default list of registries, the given registry should be used. |
-| `patches` | Iterable of [string](../core/string)s; default is `[]`  A list of labels pointing to patch files to apply for this module. The patch files must exist in the source tree of the top level project. They are applied in the list order. If a patch makes changes to the MODULE.bazel file, these changes will only be effective if the patch file is provided by the root module. |
-| `patch_cmds` | Iterable of [string](../core/string)s; default is `[]`  Sequence of Bash commands to be applied on Linux/Macos after patches are applied. Changes to the MODULE.bazel file will not be effective. |
-| `patch_strip` | [int](../core/int); default is `0`  Same as the --strip argument of Unix patch. |
+| `module_name` | [string](/versions/8.2.1/rules/lib/core/string); required  The name of the Bazel module dependency to apply this override to. |
+| `version` | [string](/versions/8.2.1/rules/lib/core/string); default is `''`  Overrides the declared version of this module in the dependency graph. In other words, this module will be "pinned" to this override version. This attribute can be omitted if all one wants to override is the registry or the patches. |
+| `registry` | [string](/versions/8.2.1/rules/lib/core/string); default is `''`  Overrides the registry for this module; instead of finding this module from the default list of registries, the given registry should be used. |
+| `patches` | Iterable of [string](/versions/8.2.1/rules/lib/core/string)s; default is `[]`  A list of labels pointing to patch files to apply for this module. The patch files must exist in the source tree of the top level project. They are applied in the list order. If a patch makes changes to the MODULE.bazel file, these changes will only be effective if the patch file is provided by the root module. |
+| `patch_cmds` | Iterable of [string](/versions/8.2.1/rules/lib/core/string)s; default is `[]`  Sequence of Bash commands to be applied on Linux/Macos after patches are applied. Changes to the MODULE.bazel file will not be effective. |
+| `patch_strip` | [int](/versions/8.2.1/rules/lib/core/int); default is `0`  Same as the --strip argument of Unix patch. |
 
 ## use\_extension
 
@@ -258,10 +258,10 @@ Returns a proxy object representing a module extension; its methods can be invok
 
 | Parameter | Description |
 | --- | --- |
-| `extension_bzl_file` | [string](../core/string); required  A label to the Starlark file defining the module extension. |
-| `extension_name` | [string](../core/string); required  The name of the module extension to use. A symbol with this name must be exported by the Starlark file. |
-| `dev_dependency` | [bool](../core/bool); default is `False`  If true, this usage of the module extension will be ignored if the current module is not the root module or `--ignore\_dev\_dependency` is enabled. |
-| `isolate` | [bool](../core/bool); default is `False`  **Experimental**. This parameter is experimental and may change at any time. Please do not depend on it. It may be enabled on an experimental basis by setting `--experimental_isolated_extension_usages`  If true, this usage of the module extension will be isolated from all other usages, both in this and other modules. Tags created for this usage do not affect other usages and the repositories generated by the extension for this usage will be distinct from all other repositories generated by the extension. This parameter is currently experimental and only available with the flag `--experimental_isolated_extension_usages`. |
+| `extension_bzl_file` | [string](/versions/8.2.1/rules/lib/core/string); required  A label to the Starlark file defining the module extension. |
+| `extension_name` | [string](/versions/8.2.1/rules/lib/core/string); required  The name of the module extension to use. A symbol with this name must be exported by the Starlark file. |
+| `dev_dependency` | [bool](/versions/8.2.1/rules/lib/core/bool); default is `False`  If true, this usage of the module extension will be ignored if the current module is not the root module or `--ignore\_dev\_dependency` is enabled. |
+| `isolate` | [bool](/versions/8.2.1/rules/lib/core/bool); default is `False`  **Experimental**. This parameter is experimental and may change at any time. Please do not depend on it. It may be enabled on an experimental basis by setting `--experimental_isolated_extension_usages`  If true, this usage of the module extension will be isolated from all other usages, both in this and other modules. Tags created for this usage do not affect other usages and the repositories generated by the extension for this usage will be distinct from all other repositories generated by the extension. This parameter is currently experimental and only available with the flag `--experimental_isolated_extension_usages`. |
 
 ## use\_repo
 
@@ -291,5 +291,5 @@ Returns a proxy value that can be directly invoked in the MODULE.bazel file as a
 
 | Parameter | Description |
 | --- | --- |
-| `repo_rule_bzl_file` | [string](../core/string); required  A label to the Starlark file defining the repo rule. |
-| `repo_rule_name` | [string](../core/string); required  The name of the repo rule to use. A symbol with this name must be exported by the Starlark file. |
\ No newline at end of file
+| `repo_rule_bzl_file` | [string](/versions/8.2.1/rules/lib/core/string); required  A label to the Starlark file defining the repo rule. |
+| `repo_rule_name` | [string](/versions/8.2.1/rules/lib/core/string); required  The name of the repo rule to use. A symbol with this name must be exported by the Starlark file. |
\ No newline at end of file
diff --git a/versions/8.2.1/rules/lib/globals/repo.mdx b/versions/8.2.1/rules/lib/globals/repo.mdx
index 60f0ac1b..c898c7f6 100644
--- a/versions/8.2.1/rules/lib/globals/repo.mdx
+++ b/versions/8.2.1/rules/lib/globals/repo.mdx
@@ -23,7 +23,7 @@ This function takes a list of strings and a directory is ignored if any of the g
 
 | Parameter | Description |
 | --- | --- |
-| `dirs` | [sequence](../core/list) of [string](../core/string)s; required |
+| `dirs` | [sequence](/versions/8.2.1/rules/lib/core/list) of [string](/versions/8.2.1/rules/lib/core/string)s; required |
 
 ## repo
 
diff --git a/versions/8.2.1/rules/lib/globals/workspace.mdx b/versions/8.2.1/rules/lib/globals/workspace.mdx
index 6af902e3..dacf8ef9 100644
--- a/versions/8.2.1/rules/lib/globals/workspace.mdx
+++ b/versions/8.2.1/rules/lib/globals/workspace.mdx
@@ -25,8 +25,8 @@ Gives a target an alias in the `//external` package.
 
 | Parameter | Description |
 | --- | --- |
-| `name` | [string](../core/string); required  The label under '//external' to serve as the alias name |
-| `actual` | [string](../core/string); or `None`; default is `None`  The real label to be aliased |
+| `name` | [string](/versions/8.2.1/rules/lib/core/string); required  The label under '//external' to serve as the alias name |
+| `actual` | [string](/versions/8.2.1/rules/lib/core/string); or `None`; default is `None`  The real label to be aliased |
 
 ## register\_execution\_platforms
 
@@ -40,7 +40,7 @@ Specifies already-defined execution platforms to be registered. Should be absolu
 
 | Parameter | Description |
 | --- | --- |
-| `platform_labels` | [sequence](../core/list) of [string](../core/string)s; required  The target patterns to register. |
+| `platform_labels` | [sequence](/versions/8.2.1/rules/lib/core/list) of [string](/versions/8.2.1/rules/lib/core/string)s; required  The target patterns to register. |
 
 ## register\_toolchains
 
@@ -54,7 +54,7 @@ Specifies already-defined toolchains to be registered. Should be absolute [targe
 
 | Parameter | Description |
 | --- | --- |
-| `toolchain_labels` | [sequence](../core/list) of [string](../core/string)s; required  The target patterns to register. |
+| `toolchain_labels` | [sequence](/versions/8.2.1/rules/lib/core/list) of [string](/versions/8.2.1/rules/lib/core/string)s; required  The target patterns to register. |
 
 ## workspace
 
@@ -74,4 +74,4 @@ This name is used for the directory that the repository's runfiles are stored in
 
 | Parameter | Description |
 | --- | --- |
-| `name` | [string](../core/string); required  the name of the workspace. Names must start with a letter and can only contain letters, numbers, underscores, dashes, and dots. |
\ No newline at end of file
+| `name` | [string](/versions/8.2.1/rules/lib/core/string); required  the name of the workspace. Names must start with a letter and can only contain letters, numbers, underscores, dashes, and dots. |
\ No newline at end of file
diff --git a/versions/8.2.1/rules/lib/providers/AnalysisTestResultInfo.mdx b/versions/8.2.1/rules/lib/providers/AnalysisTestResultInfo.mdx
index 1edabb04..7ea23a35 100644
--- a/versions/8.2.1/rules/lib/providers/AnalysisTestResultInfo.mdx
+++ b/versions/8.2.1/rules/lib/providers/AnalysisTestResultInfo.mdx
@@ -22,8 +22,8 @@ The `AnalysisTestResultInfo` constructor.
 
 | Parameter | Description |
 | --- | --- |
-| `success` | [bool](../core/bool); required  If true, then the analysis-phase test represented by this target should pass. If false, the test should fail. |
-| `message` | [string](../core/string); required  A descriptive message containing information about the test and its success/failure. |
+| `success` | [bool](/versions/8.2.1/rules/lib/core/bool); required  If true, then the analysis-phase test represented by this target should pass. If false, the test should fail. |
+| `message` | [string](/versions/8.2.1/rules/lib/core/string); required  A descriptive message containing information about the test and its success/failure. |
 
 ## message
 
diff --git a/versions/8.2.1/rules/lib/providers/CcInfo.mdx b/versions/8.2.1/rules/lib/providers/CcInfo.mdx
index f3c0d961..a596beda 100644
--- a/versions/8.2.1/rules/lib/providers/CcInfo.mdx
+++ b/versions/8.2.1/rules/lib/providers/CcInfo.mdx
@@ -22,8 +22,8 @@ The `CcInfo` constructor.
 
 | Parameter | Description |
 | --- | --- |
-| `compilation_context` | [CompilationContext](../builtins/CompilationContext); or `None`; default is `None`  The `CompilationContext`. |
-| `linking_context` | [LinkingContext](../builtins/LinkingContext); or `None`; default is `None`  The `LinkingContext`. |
+| `compilation_context` | [CompilationContext](/versions/8.2.1/rules/lib/builtins/CompilationContext); or `None`; default is `None`  The `CompilationContext`. |
+| `linking_context` | [LinkingContext](/versions/8.2.1/rules/lib/builtins/LinkingContext); or `None`; default is `None`  The `LinkingContext`. |
 | `debug_context` | DebugContext; or `None`; default is `None`  The `DebugContext`. |
 
 ## compilation\_context
diff --git a/versions/8.2.1/rules/lib/providers/DebugPackageInfo.mdx b/versions/8.2.1/rules/lib/providers/DebugPackageInfo.mdx
index 777c8ebd..08276a07 100644
--- a/versions/8.2.1/rules/lib/providers/DebugPackageInfo.mdx
+++ b/versions/8.2.1/rules/lib/providers/DebugPackageInfo.mdx
@@ -24,10 +24,10 @@ The `DebugPackageInfo` constructor.
 
 | Parameter | Description |
 | --- | --- |
-| `target_label` | [Label](../builtins/Label); required  The label for the \*\_binary target |
-| `stripped_file` | [File](../builtins/File); or `None`; default is `None`  The stripped file (the explicit ".stripped" target) |
-| `unstripped_file` | [File](../builtins/File); required  The unstripped file (the default executable target). |
-| `dwp_file` | [File](../builtins/File); or `None`; default is `None`  The .dwp file (for fission builds) or null if --fission=no. |
+| `target_label` | [Label](/versions/8.2.1/rules/lib/builtins/Label); required  The label for the \*\_binary target |
+| `stripped_file` | [File](/versions/8.2.1/rules/lib/builtins/File); or `None`; default is `None`  The stripped file (the explicit ".stripped" target) |
+| `unstripped_file` | [File](/versions/8.2.1/rules/lib/builtins/File); required  The unstripped file (the default executable target). |
+| `dwp_file` | [File](/versions/8.2.1/rules/lib/builtins/File); or `None`; default is `None`  The .dwp file (for fission builds) or null if --fission=no. |
 
 ## dwp\_file
 
diff --git a/versions/8.2.1/rules/lib/providers/DefaultInfo.mdx b/versions/8.2.1/rules/lib/providers/DefaultInfo.mdx
index 181419d1..ef68872b 100644
--- a/versions/8.2.1/rules/lib/providers/DefaultInfo.mdx
+++ b/versions/8.2.1/rules/lib/providers/DefaultInfo.mdx
@@ -28,11 +28,11 @@ The `DefaultInfo` constructor.
 
 | Parameter | Description |
 | --- | --- |
-| `files` | [depset](../builtins/depset); or `None`; default is `None`  A [`depset`](../builtins/depset) of [`File`](../builtins/File) objects representing the default outputs to build when this target is specified on the bazel command line. By default it is all predeclared outputs. |
-| `runfiles` | [runfiles](../builtins/runfiles); or `None`; default is `None`  runfiles descriptor describing the files that this target needs when run (via the `run` command or as a tool dependency). |
-| `data_runfiles` | [runfiles](../builtins/runfiles); or `None`; default is `None`  **It is recommended that you avoid using this parameter (see ["runfiles features to avoid"](https://bazel.build/versions/8.2.1/extending/rules#runfiles_features_to_avoid))** runfiles descriptor describing the runfiles this target needs to run when it is a dependency via the `data` attribute. |
-| `default_runfiles` | [runfiles](../builtins/runfiles); or `None`; default is `None`  **It is recommended that you avoid using this parameter (see ["runfiles features to avoid"](https://bazel.build/versions/8.2.1/extending/rules#runfiles_features_to_avoid))** runfiles descriptor describing the runfiles this target needs to run when it is a dependency via any attribute other than the `data` attribute. |
-| `executable` | [File](../builtins/File); or `None`; default is `None`  If this rule is marked [`executable`](../globals/bzl#rule.executable) or [`test`](../globals/bzl#rule.test), this is a [`File`](../builtins/File) object representing the file that should be executed to run the target. By default it is the predeclared output `ctx.outputs.executable` but it is recommended to pass another file (either predeclared or not) explicitly. |
+| `files` | [depset](/versions/8.2.1/rules/lib/builtins/depset); or `None`; default is `None`  A [`depset`](/versions/8.2.1/rules/lib/builtins/depset) of [`File`](/versions/8.2.1/rules/lib/builtins/File) objects representing the default outputs to build when this target is specified on the bazel command line. By default it is all predeclared outputs. |
+| `runfiles` | [runfiles](/versions/8.2.1/rules/lib/builtins/runfiles); or `None`; default is `None`  runfiles descriptor describing the files that this target needs when run (via the `run` command or as a tool dependency). |
+| `data_runfiles` | [runfiles](/versions/8.2.1/rules/lib/builtins/runfiles); or `None`; default is `None`  **It is recommended that you avoid using this parameter (see ["runfiles features to avoid"](https://bazel.build/versions/8.2.1/extending/rules#runfiles_features_to_avoid))** runfiles descriptor describing the runfiles this target needs to run when it is a dependency via the `data` attribute. |
+| `default_runfiles` | [runfiles](/versions/8.2.1/rules/lib/builtins/runfiles); or `None`; default is `None`  **It is recommended that you avoid using this parameter (see ["runfiles features to avoid"](https://bazel.build/versions/8.2.1/extending/rules#runfiles_features_to_avoid))** runfiles descriptor describing the runfiles this target needs to run when it is a dependency via any attribute other than the `data` attribute. |
+| `executable` | [File](/versions/8.2.1/rules/lib/builtins/File); or `None`; default is `None`  If this rule is marked [`executable`](/versions/8.2.1/rules/lib/globals/bzl#rule.executable) or [`test`](/versions/8.2.1/rules/lib/globals/bzl#rule.test), this is a [`File`](/versions/8.2.1/rules/lib/builtins/File) object representing the file that should be executed to run the target. By default it is the predeclared output `ctx.outputs.executable` but it is recommended to pass another file (either predeclared or not) explicitly. |
 
 ## data\_runfiles
 
@@ -58,7 +58,7 @@ May return `None`.
 depset DefaultInfo.files
 ```
 
-A [`depset`](../builtins/depset) of [`File`](../builtins/File) objects representing the default outputs to build when this target is specified on the bazel command line. By default it is all predeclared outputs.
+A [`depset`](/versions/8.2.1/rules/lib/builtins/depset) of [`File`](/versions/8.2.1/rules/lib/builtins/File) objects representing the default outputs to build when this target is specified on the bazel command line. By default it is all predeclared outputs.
 May return `None`.
 
 ## files\_to\_run
@@ -67,5 +67,5 @@ May return `None`.
 FilesToRunProvider DefaultInfo.files_to_run
 ```
 
-A [`FilesToRunProvider`](../providers/FilesToRunProvider) object containing information about the executable and runfiles of the target.
+A [`FilesToRunProvider`](/versions/8.2.1/rules/lib/providers/FilesToRunProvider) object containing information about the executable and runfiles of the target.
 May return `None`.
\ No newline at end of file
diff --git a/versions/8.2.1/rules/lib/providers/ExecutionInfo.mdx b/versions/8.2.1/rules/lib/providers/ExecutionInfo.mdx
index d351095e..b3556435 100644
--- a/versions/8.2.1/rules/lib/providers/ExecutionInfo.mdx
+++ b/versions/8.2.1/rules/lib/providers/ExecutionInfo.mdx
@@ -22,8 +22,8 @@ Creates an instance.
 
 | Parameter | Description |
 | --- | --- |
-| `requirements` | [dict](../core/dict); default is `{}`  A dict indicating special execution requirements, such as hardware platforms. |
-| `exec_group` | [string](../core/string); default is `'test'`  The name of the exec group that is used to execute the test. |
+| `requirements` | [dict](/versions/8.2.1/rules/lib/core/dict); default is `{}`  A dict indicating special execution requirements, such as hardware platforms. |
+| `exec_group` | [string](/versions/8.2.1/rules/lib/core/string); default is `'test'`  The name of the exec group that is used to execute the test. |
 
 ## exec\_group
 
diff --git a/versions/8.2.1/rules/lib/providers/FeatureFlagInfo.mdx b/versions/8.2.1/rules/lib/providers/FeatureFlagInfo.mdx
index ebade07a..f1af1b24 100644
--- a/versions/8.2.1/rules/lib/providers/FeatureFlagInfo.mdx
+++ b/versions/8.2.1/rules/lib/providers/FeatureFlagInfo.mdx
@@ -31,7 +31,7 @@ The value of the flag in the configuration used by the flag rule.
 
 | Parameter | Description |
 | --- | --- |
-| `value` | [string](../core/string); required  String, the value to check for validity for this flag. |
+| `value` | [string](/versions/8.2.1/rules/lib/core/string); required  String, the value to check for validity for this flag. |
 
 ## value
 
diff --git a/versions/8.2.1/rules/lib/providers/InstrumentedFilesInfo.mdx b/versions/8.2.1/rules/lib/providers/InstrumentedFilesInfo.mdx
index 9c6d7237..4f665982 100644
--- a/versions/8.2.1/rules/lib/providers/InstrumentedFilesInfo.mdx
+++ b/versions/8.2.1/rules/lib/providers/InstrumentedFilesInfo.mdx
@@ -15,7 +15,7 @@ Contains information about source files and instrumentation metadata files for r
 depset InstrumentedFilesInfo.instrumented_files
 ```
 
-[`depset`](../builtins/depset) of [`File`](../builtins/File) objects representing instrumented source files for this target and its dependencies.
+[`depset`](/versions/8.2.1/rules/lib/builtins/depset) of [`File`](/versions/8.2.1/rules/lib/builtins/File) objects representing instrumented source files for this target and its dependencies.
 
 ## metadata\_files
 
@@ -23,4 +23,4 @@ depset InstrumentedFilesInfo.instrumented_files
 depset InstrumentedFilesInfo.metadata_files
 ```
 
-[`depset`](../builtins/depset) of [`File`](../builtins/File) objects representing coverage metadata files for this target and its dependencies. These files contain additional information required to generate LCOV-format coverage output after the code is executed, e.g. the `.gcno` files generated when `gcc` is run with `-ftest-coverage`.
\ No newline at end of file
+[`depset`](/versions/8.2.1/rules/lib/builtins/depset) of [`File`](/versions/8.2.1/rules/lib/builtins/File) objects representing coverage metadata files for this target and its dependencies. These files contain additional information required to generate LCOV-format coverage output after the code is executed, e.g. the `.gcno` files generated when `gcc` is run with `-ftest-coverage`.
\ No newline at end of file
diff --git a/versions/8.2.1/rules/lib/providers/PackageSpecificationInfo.mdx b/versions/8.2.1/rules/lib/providers/PackageSpecificationInfo.mdx
index 242a43e6..c1710b1a 100644
--- a/versions/8.2.1/rules/lib/providers/PackageSpecificationInfo.mdx
+++ b/versions/8.2.1/rules/lib/providers/PackageSpecificationInfo.mdx
@@ -20,4 +20,4 @@ Checks if a target exists in a package group.
 
 | Parameter | Description |
 | --- | --- |
-| `target` | [Label](../builtins/Label); or [string](../core/string); required  A target which is checked if it exists inside the package group. |
\ No newline at end of file
+| `target` | [Label](/versions/8.2.1/rules/lib/builtins/Label); or [string](/versions/8.2.1/rules/lib/core/string); required  A target which is checked if it exists inside the package group. |
\ No newline at end of file
diff --git a/versions/8.2.1/rules/lib/providers/ProguardSpecProvider.mdx b/versions/8.2.1/rules/lib/providers/ProguardSpecProvider.mdx
index b7a337c2..c0bdde98 100644
--- a/versions/8.2.1/rules/lib/providers/ProguardSpecProvider.mdx
+++ b/versions/8.2.1/rules/lib/providers/ProguardSpecProvider.mdx
@@ -20,4 +20,4 @@ The `ProguardSpecProvider` constructor.
 
 | Parameter | Description |
 | --- | --- |
-| `specs` | [depset](../builtins/depset) of [File](../builtins/File)s; required  Transitive proguard specs. |
\ No newline at end of file
+| `specs` | [depset](/versions/8.2.1/rules/lib/builtins/depset) of [File](/versions/8.2.1/rules/lib/builtins/File)s; required  Transitive proguard specs. |
\ No newline at end of file
diff --git a/versions/8.2.1/rules/lib/repo/index.mdx b/versions/8.2.1/rules/lib/repo/index.mdx
index ab27e81c..53fc8581 100644
--- a/versions/8.2.1/rules/lib/repo/index.mdx
+++ b/versions/8.2.1/rules/lib/repo/index.mdx
@@ -3,10 +3,10 @@
 title: 'Repository Rules'
 ---
 
-* [Rules related to git](git)
-* [Rules related to http](http)
-* [Rules related to local directories](local)
+* [Rules related to git](/versions/8.2.1/rules/lib/repo/git)
+* [Rules related to http](/versions/8.2.1/rules/lib/repo/http)
+* [Rules related to local directories](/versions/8.2.1/rules/lib/repo/local)
 
 # Generic functions for repository rule authors
 
-* [Utility functions on patching](utils)
+* [Utility functions on patching](/versions/8.2.1/rules/lib/repo/utils)
diff --git a/versions/8.2.1/rules/lib/toplevel/apple_common.mdx b/versions/8.2.1/rules/lib/toplevel/apple_common.mdx
index d26f9c22..520cbc23 100644
--- a/versions/8.2.1/rules/lib/toplevel/apple_common.mdx
+++ b/versions/8.2.1/rules/lib/toplevel/apple_common.mdx
@@ -21,7 +21,7 @@ Functions for Starlark to access internals of the apple rule implementations.
 dict apple_common.apple_host_system_env(xcode_config)
 ```
 
-Returns a [dict](../core/dict) of environment variables that should be set for actions that need to run build tools on an Apple host system, such as the version of Xcode that should be used. The keys are variable names and the values are their corresponding values.
+Returns a [dict](/versions/8.2.1/rules/lib/core/dict) of environment variables that should be set for actions that need to run build tools on an Apple host system, such as the version of Xcode that should be used. The keys are variable names and the values are their corresponding values.
 
 ### Parameters
 
@@ -43,13 +43,13 @@ Utilities for resolving items from the apple toolchain.
 DottedVersion apple_common.dotted_version(version)
 ```
 
-Creates a new [DottedVersion](../builtins/DottedVersion) instance.
+Creates a new [DottedVersion](/versions/8.2.1/rules/lib/builtins/DottedVersion) instance.
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `version` | [string](../core/string); required  The string representation of the DottedVersion. |
+| `version` | [string](/versions/8.2.1/rules/lib/core/string); required  The string representation of the DottedVersion. |
 
 ## platform
 
@@ -69,7 +69,7 @@ An enum-like struct that contains the following fields corresponding to Apple pl
 * `watchos_device`
 * `watchos_simulator`
 
-These values can be passed to methods that expect a platform, like [XcodeVersionConfig.sdk\_version\_for\_platform](../providers/XcodeVersionConfig#sdk_version_for_platform).
+These values can be passed to methods that expect a platform, like [XcodeVersionConfig.sdk\_version\_for\_platform](/versions/8.2.1/rules/lib/providers/XcodeVersionConfig#sdk_version_for_platform).
 
 ## platform\_type
 
@@ -85,7 +85,7 @@ An enum-like struct that contains the following fields corresponding to Apple pl
 * `visionos`
 * `watchos`
 
-These values can be passed to methods that expect a platform type, like the 'apple' configuration fragment's [multi\_arch\_platform](../fragments/apple#multi_arch_platform) method.
+These values can be passed to methods that expect a platform type, like the 'apple' configuration fragment's [multi\_arch\_platform](/versions/8.2.1/rules/lib/fragments/apple#multi_arch_platform) method.
 
 Example:
 
diff --git a/versions/8.2.1/rules/lib/toplevel/attr.mdx b/versions/8.2.1/rules/lib/toplevel/attr.mdx
index 9b0cd432..fc551f48 100644
--- a/versions/8.2.1/rules/lib/toplevel/attr.mdx
+++ b/versions/8.2.1/rules/lib/toplevel/attr.mdx
@@ -2,7 +2,7 @@
 title: 'attr'
 ---
 
-This is a top-level module for defining the attribute schemas of a rule or aspect. Each function returns an object representing the schema of a single attribute. These objects are used as the values of the `attrs` dictionary argument of [`rule()`](../globals/bzl#rule), [`aspect()`](../globals/bzl#aspect), [`repository_rule()`](../globals/bzl#repository_rule) and [`tag_class()`](../globals/bzl#tag_class).
+This is a top-level module for defining the attribute schemas of a rule or aspect. Each function returns an object representing the schema of a single attribute. These objects are used as the values of the `attrs` dictionary argument of [`rule()`](/versions/8.2.1/rules/lib/globals/bzl#rule), [`aspect()`](/versions/8.2.1/rules/lib/globals/bzl#aspect), [`repository_rule()`](/versions/8.2.1/rules/lib/globals/bzl#repository_rule) and [`tag_class()`](/versions/8.2.1/rules/lib/globals/bzl#tag_class).
 
 See the Rules page for more on [defining](https://bazel.build/versions/8.2.1/extending/rules#attributes)
 and [using](https://bazel.build/versions/8.2.1/extending/rules#implementation_function) attributes.
@@ -29,16 +29,16 @@ and [using](https://bazel.build/versions/8.2.1/extending/rules#implementation_fu
 Attribute attr.bool(configurable=unbound, default=False, doc=None, mandatory=False)
 ```
 
-Creates a schema for a boolean attribute. The corresponding [`ctx.attr`](../builtins/ctx#attr) attribute will be of type [`bool`](../core/bool).
+Creates a schema for a boolean attribute. The corresponding [`ctx.attr`](/versions/8.2.1/rules/lib/builtins/ctx#attr) attribute will be of type [`bool`](/versions/8.2.1/rules/lib/core/bool).
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `configurable` | [bool](../core/bool); or unbound; default is `unbound`  This argument can only be specified for an attribute of a symbolic macro. If `configurable` is explicitly set to `False`, the symbolic macro attribute is non-configurable - in other words, it cannot take a `select()` value. If the `configurable` is either unbound or explicitly set to `True`, the attribute is configurable and can take a `select()` value. For an attribute of a rule or aspect, `configurable` must be left unbound. Most Starlark rule attributes are always configurable, with the exception of `attr.output()`, `attr.output_list()`, and `attr.license()` rule attributes, which are always non-configurable. |
-| `default` | [bool](../core/bool); default is `False`  A default value to use if no value for this attribute is given when instantiating the rule. |
-| `doc` | [string](../core/string); or `None`; default is `None`  A description of the attribute that can be extracted by documentation generating tools. |
-| `mandatory` | [bool](../core/bool); default is `False`  If true, the value must be specified explicitly (even if it has a `default`). |
+| `configurable` | [bool](/versions/8.2.1/rules/lib/core/bool); or unbound; default is `unbound`  This argument can only be specified for an attribute of a symbolic macro. If `configurable` is explicitly set to `False`, the symbolic macro attribute is non-configurable - in other words, it cannot take a `select()` value. If the `configurable` is either unbound or explicitly set to `True`, the attribute is configurable and can take a `select()` value. For an attribute of a rule or aspect, `configurable` must be left unbound. Most Starlark rule attributes are always configurable, with the exception of `attr.output()`, `attr.output_list()`, and `attr.license()` rule attributes, which are always non-configurable. |
+| `default` | [bool](/versions/8.2.1/rules/lib/core/bool); default is `False`  A default value to use if no value for this attribute is given when instantiating the rule. |
+| `doc` | [string](/versions/8.2.1/rules/lib/core/string); or `None`; default is `None`  A description of the attribute that can be extracted by documentation generating tools. |
+| `mandatory` | [bool](/versions/8.2.1/rules/lib/core/bool); default is `False`  If true, the value must be specified explicitly (even if it has a `default`). |
 
 ## int
 
@@ -46,17 +46,17 @@ Creates a schema for a boolean attribute. The corresponding [`ctx.attr`](../buil
 Attribute attr.int(configurable=unbound, default=0, doc=None, mandatory=False, values=[])
 ```
 
-Creates a schema for an integer attribute. The value must be in the signed 32-bit range. The corresponding [`ctx.attr`](../builtins/ctx#attr) attribute will be of type [`int`](../core/int).
+Creates a schema for an integer attribute. The value must be in the signed 32-bit range. The corresponding [`ctx.attr`](/versions/8.2.1/rules/lib/builtins/ctx#attr) attribute will be of type [`int`](/versions/8.2.1/rules/lib/core/int).
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `configurable` | [bool](../core/bool); or unbound; default is `unbound`  This argument can only be specified for an attribute of a symbolic macro. If `configurable` is explicitly set to `False`, the symbolic macro attribute is non-configurable - in other words, it cannot take a `select()` value. If the `configurable` is either unbound or explicitly set to `True`, the attribute is configurable and can take a `select()` value. For an attribute of a rule or aspect, `configurable` must be left unbound. Most Starlark rule attributes are always configurable, with the exception of `attr.output()`, `attr.output_list()`, and `attr.license()` rule attributes, which are always non-configurable. |
-| `default` | [int](../core/int); default is `0`  A default value to use if no value for this attribute is given when instantiating the rule. |
-| `doc` | [string](../core/string); or `None`; default is `None`  A description of the attribute that can be extracted by documentation generating tools. |
-| `mandatory` | [bool](../core/bool); default is `False`  If true, the value must be specified explicitly (even if it has a `default`). |
-| `values` | [sequence](../core/list) of [int](../core/int)s; default is `[]`  The list of allowed values for the attribute. An error is raised if any other value is given. |
+| `configurable` | [bool](/versions/8.2.1/rules/lib/core/bool); or unbound; default is `unbound`  This argument can only be specified for an attribute of a symbolic macro. If `configurable` is explicitly set to `False`, the symbolic macro attribute is non-configurable - in other words, it cannot take a `select()` value. If the `configurable` is either unbound or explicitly set to `True`, the attribute is configurable and can take a `select()` value. For an attribute of a rule or aspect, `configurable` must be left unbound. Most Starlark rule attributes are always configurable, with the exception of `attr.output()`, `attr.output_list()`, and `attr.license()` rule attributes, which are always non-configurable. |
+| `default` | [int](/versions/8.2.1/rules/lib/core/int); default is `0`  A default value to use if no value for this attribute is given when instantiating the rule. |
+| `doc` | [string](/versions/8.2.1/rules/lib/core/string); or `None`; default is `None`  A description of the attribute that can be extracted by documentation generating tools. |
+| `mandatory` | [bool](/versions/8.2.1/rules/lib/core/bool); default is `False`  If true, the value must be specified explicitly (even if it has a `default`). |
+| `values` | [sequence](/versions/8.2.1/rules/lib/core/list) of [int](/versions/8.2.1/rules/lib/core/int)s; default is `[]`  The list of allowed values for the attribute. An error is raised if any other value is given. |
 
 ## int\_list
 
@@ -70,11 +70,11 @@ Creates a schema for a list-of-integers attribute. Each element must be in the s
 
 | Parameter | Description |
 | --- | --- |
-| `mandatory` | [bool](../core/bool); default is `False`  If true, the value must be specified explicitly (even if it has a `default`). |
-| `allow_empty` | [bool](../core/bool); default is `True`  True if the attribute can be empty. |
-| `configurable` | [bool](../core/bool); or unbound; default is `unbound`  This argument can only be specified for an attribute of a symbolic macro. If `configurable` is explicitly set to `False`, the symbolic macro attribute is non-configurable - in other words, it cannot take a `select()` value. If the `configurable` is either unbound or explicitly set to `True`, the attribute is configurable and can take a `select()` value. For an attribute of a rule or aspect, `configurable` must be left unbound. Most Starlark rule attributes are always configurable, with the exception of `attr.output()`, `attr.output_list()`, and `attr.license()` rule attributes, which are always non-configurable. |
-| `default` | [sequence](../core/list) of [int](../core/int)s; default is `[]`  A default value to use if no value for this attribute is given when instantiating the rule. |
-| `doc` | [string](../core/string); or `None`; default is `None`  A description of the attribute that can be extracted by documentation generating tools. |
+| `mandatory` | [bool](/versions/8.2.1/rules/lib/core/bool); default is `False`  If true, the value must be specified explicitly (even if it has a `default`). |
+| `allow_empty` | [bool](/versions/8.2.1/rules/lib/core/bool); default is `True`  True if the attribute can be empty. |
+| `configurable` | [bool](/versions/8.2.1/rules/lib/core/bool); or unbound; default is `unbound`  This argument can only be specified for an attribute of a symbolic macro. If `configurable` is explicitly set to `False`, the symbolic macro attribute is non-configurable - in other words, it cannot take a `select()` value. If the `configurable` is either unbound or explicitly set to `True`, the attribute is configurable and can take a `select()` value. For an attribute of a rule or aspect, `configurable` must be left unbound. Most Starlark rule attributes are always configurable, with the exception of `attr.output()`, `attr.output_list()`, and `attr.license()` rule attributes, which are always non-configurable. |
+| `default` | [sequence](/versions/8.2.1/rules/lib/core/list) of [int](/versions/8.2.1/rules/lib/core/int)s; default is `[]`  A default value to use if no value for this attribute is given when instantiating the rule. |
+| `doc` | [string](/versions/8.2.1/rules/lib/core/string); or `None`; default is `None`  A description of the attribute that can be extracted by documentation generating tools. |
 
 ## label
 
@@ -84,9 +84,9 @@ Attribute attr.label(configurable=unbound, default=None, materializer=None, doc=
 
 Creates a schema for a label attribute. This is a dependency attribute.
 
-This attribute contains unique [`Label`](../builtins/Label) values. If a string is supplied in place of a `Label`, it will be converted using the [label constructor](../builtins/Label#Label). The relative parts of the label path, including the (possibly renamed) repository, are resolved with respect to the instantiated target's package.
+This attribute contains unique [`Label`](/versions/8.2.1/rules/lib/builtins/Label) values. If a string is supplied in place of a `Label`, it will be converted using the [label constructor](/versions/8.2.1/rules/lib/builtins/Label#Label). The relative parts of the label path, including the (possibly renamed) repository, are resolved with respect to the instantiated target's package.
 
-At analysis time (within the rule's implementation function), when retrieving the attribute value from `ctx.attr`, labels are replaced by the corresponding [`Target`](../builtins/Target)s. This allows you to access the providers of the current target's dependencies.
+At analysis time (within the rule's implementation function), when retrieving the attribute value from `ctx.attr`, labels are replaced by the corresponding [`Target`](/versions/8.2.1/rules/lib/builtins/Target)s. This allows you to access the providers of the current target's dependencies.
 
 In addition to ordinary source files, this kind of attribute is often used to refer to a tool -- for example, a compiler. Such tools are considered to be dependencies, just like source files. To avoid requiring users to specify the tool's label every time they use the rule in their BUILD files, you can hard-code the label of a canonical tool as the `default` value of this attribute. If you also want to prevent users from overriding this default, you can make the attribute private by giving it a name that starts with an underscore. See the [Rules](https://bazel.build/versions/8.2.1/extending/rules#private-attributes) page for more information.
 
@@ -94,21 +94,21 @@ In addition to ordinary source files, this kind of attribute is often used to re
 
 | Parameter | Description |
 | --- | --- |
-| `configurable` | [bool](../core/bool); or unbound; default is `unbound`  This argument can only be specified for an attribute of a symbolic macro. If `configurable` is explicitly set to `False`, the symbolic macro attribute is non-configurable - in other words, it cannot take a `select()` value. If the `configurable` is either unbound or explicitly set to `True`, the attribute is configurable and can take a `select()` value. For an attribute of a rule or aspect, `configurable` must be left unbound. Most Starlark rule attributes are always configurable, with the exception of `attr.output()`, `attr.output_list()`, and `attr.license()` rule attributes, which are always non-configurable. |
-| `default` | [Label](../builtins/Label); or [string](../core/string); or [LateBoundDefault](../builtins/LateBoundDefault); or NativeComputedDefault; or [function](../core/function); or `None`; default is `None`  A default value to use if no value for this attribute is given when instantiating the rule.Use a string or the [`Label`](../builtins/Label#Label) function to specify a default value, for example, `attr.label(default = "//a:b")`. |
-| `materializer` | [function](../core/function); default is `None`  **Experimental**. This parameter is experimental and may change at any time. Please do not depend on it. It may be enabled on an experimental basis by setting `--experimental_dormant_deps`  If set, the attribute materializes dormant dependencies from the transitive closure. The value of this parameter must be a functon that gets access to the values of the attributes of the rule that either are not dependencies or are marked as available for dependency resolution. It must return either a dormant dependency or a list of them depending on the type of the attribute |
-| `doc` | [string](../core/string); or `None`; default is `None` |
-| `executable` | [bool](../core/bool); default is `False`  True if the dependency has to be executable. This means the label must refer to an executable file, or to a rule that outputs an executable file. Access the label with `ctx.executable.`. |
-| `allow_files` | [bool](../core/bool); or [sequence](../core/list) of [string](../core/string)s; or `None`; default is `None`  Whether `File` targets are allowed. Can be `True`, `False` (default), or a list of file extensions that are allowed (for example, `[".cc", ".cpp"]`). |
-| `allow_single_file` | default is `None`  This is similar to `allow_files`, with the restriction that the label must correspond to a single [File](../builtins/File). Access it through `ctx.file.`. |
-| `mandatory` | [bool](../core/bool); default is `False`  If true, the value must be specified explicitly (even if it has a `default`). |
-| `skip_validations` | [bool](../core/bool); default is `False`  If true, validation actions of transitive dependencies from this attribute will not run. This is a temporary mitigation and WILL be removed in the future. |
-| `providers` | [sequence](../core/list); default is `[]`  The providers that must be given by any dependency appearing in this attribute. The format of this argument is a list of lists of providers -- `*Info` objects returned by [`provider()`](../globals/bzl#provider) (or in the case of a legacy provider, its string name). The dependency must return ALL providers mentioned in at least ONE of the inner lists. As a convenience, this argument may also be a single-level list of providers, in which case it is wrapped in an outer list with one element. It is NOT required that the rule of the dependency advertises those providers in its `provides` parameter, however, it is considered best practice. |
+| `configurable` | [bool](/versions/8.2.1/rules/lib/core/bool); or unbound; default is `unbound`  This argument can only be specified for an attribute of a symbolic macro. If `configurable` is explicitly set to `False`, the symbolic macro attribute is non-configurable - in other words, it cannot take a `select()` value. If the `configurable` is either unbound or explicitly set to `True`, the attribute is configurable and can take a `select()` value. For an attribute of a rule or aspect, `configurable` must be left unbound. Most Starlark rule attributes are always configurable, with the exception of `attr.output()`, `attr.output_list()`, and `attr.license()` rule attributes, which are always non-configurable. |
+| `default` | [Label](/versions/8.2.1/rules/lib/builtins/Label); or [string](/versions/8.2.1/rules/lib/core/string); or [LateBoundDefault](/versions/8.2.1/rules/lib/builtins/LateBoundDefault); or NativeComputedDefault; or [function](/versions/8.2.1/rules/lib/core/function); or `None`; default is `None`  A default value to use if no value for this attribute is given when instantiating the rule.Use a string or the [`Label`](/versions/8.2.1/rules/lib/builtins/Label#Label) function to specify a default value, for example, `attr.label(default = "//a:b")`. |
+| `materializer` | [function](/versions/8.2.1/rules/lib/core/function); default is `None`  **Experimental**. This parameter is experimental and may change at any time. Please do not depend on it. It may be enabled on an experimental basis by setting `--experimental_dormant_deps`  If set, the attribute materializes dormant dependencies from the transitive closure. The value of this parameter must be a functon that gets access to the values of the attributes of the rule that either are not dependencies or are marked as available for dependency resolution. It must return either a dormant dependency or a list of them depending on the type of the attribute |
+| `doc` | [string](/versions/8.2.1/rules/lib/core/string); or `None`; default is `None` |
+| `executable` | [bool](/versions/8.2.1/rules/lib/core/bool); default is `False`  True if the dependency has to be executable. This means the label must refer to an executable file, or to a rule that outputs an executable file. Access the label with `ctx.executable.`. |
+| `allow_files` | [bool](/versions/8.2.1/rules/lib/core/bool); or [sequence](/versions/8.2.1/rules/lib/core/list) of [string](/versions/8.2.1/rules/lib/core/string)s; or `None`; default is `None`  Whether `File` targets are allowed. Can be `True`, `False` (default), or a list of file extensions that are allowed (for example, `[".cc", ".cpp"]`). |
+| `allow_single_file` | default is `None`  This is similar to `allow_files`, with the restriction that the label must correspond to a single [File](/versions/8.2.1/rules/lib/builtins/File). Access it through `ctx.file.`. |
+| `mandatory` | [bool](/versions/8.2.1/rules/lib/core/bool); default is `False`  If true, the value must be specified explicitly (even if it has a `default`). |
+| `skip_validations` | [bool](/versions/8.2.1/rules/lib/core/bool); default is `False`  If true, validation actions of transitive dependencies from this attribute will not run. This is a temporary mitigation and WILL be removed in the future. |
+| `providers` | [sequence](/versions/8.2.1/rules/lib/core/list); default is `[]`  The providers that must be given by any dependency appearing in this attribute. The format of this argument is a list of lists of providers -- `*Info` objects returned by [`provider()`](/versions/8.2.1/rules/lib/globals/bzl#provider) (or in the case of a legacy provider, its string name). The dependency must return ALL providers mentioned in at least ONE of the inner lists. As a convenience, this argument may also be a single-level list of providers, in which case it is wrapped in an outer list with one element. It is NOT required that the rule of the dependency advertises those providers in its `provides` parameter, however, it is considered best practice. |
 | `for_dependency_resolution` | default is `unbound`  If this is set, the attribute is available for materializers. Only rules marked with the flag of the same name are allowed to be referenced through such attributes. |
-| `allow_rules` | [sequence](../core/list) of [string](../core/string)s; or `None`; default is `None`  Which rule targets (name of the classes) are allowed. This is deprecated (kept only for compatibility), use providers instead. |
+| `allow_rules` | [sequence](/versions/8.2.1/rules/lib/core/list) of [string](/versions/8.2.1/rules/lib/core/string)s; or `None`; default is `None`  Which rule targets (name of the classes) are allowed. This is deprecated (kept only for compatibility), use providers instead. |
 | `cfg` | default is `None`  [Configuration](https://bazel.build/versions/8.2.1/extending/rules#configurations) of the attribute. It can be either `"exec"`, which indicates that the dependency is built for the `execution platform`, or `"target"`, which indicates that the dependency is build for the `target platform`. A typical example of the difference is when building mobile apps, where the `target platform` is `Android` or `iOS` while the `execution platform` is `Linux`, `macOS`, or `Windows`. This parameter is required if `executable` is True to guard against accidentally building host tools in the target configuration. `"target"` has no semantic effect, so don't set it when `executable` is False unless it really helps clarify your intentions. |
-| `aspects` | [sequence](../core/list) of [Aspect](../builtins/Aspect)s; default is `[]`  Aspects that should be applied to the dependency or dependencies specified by this attribute. |
-| `flags` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  Deprecated, will be removed. |
+| `aspects` | [sequence](/versions/8.2.1/rules/lib/core/list) of [Aspect](/versions/8.2.1/rules/lib/builtins/Aspect)s; default is `[]`  Aspects that should be applied to the dependency or dependencies specified by this attribute. |
+| `flags` | [sequence](/versions/8.2.1/rules/lib/core/list) of [string](/versions/8.2.1/rules/lib/core/string)s; default is `[]`  Deprecated, will be removed. |
 
 ## label\_keyed\_string\_dict
 
@@ -118,26 +118,26 @@ Attribute attr.label_keyed_string_dict(allow_empty=True, *, configurable=unbound
 
 Creates a schema for an attribute holding a dictionary, where the keys are labels and the values are strings. This is a dependency attribute.
 
-This attribute contains unique [`Label`](../builtins/Label) values. If a string is supplied in place of a `Label`, it will be converted using the [label constructor](../builtins/Label#Label). The relative parts of the label path, including the (possibly renamed) repository, are resolved with respect to the instantiated target's package.
+This attribute contains unique [`Label`](/versions/8.2.1/rules/lib/builtins/Label) values. If a string is supplied in place of a `Label`, it will be converted using the [label constructor](/versions/8.2.1/rules/lib/builtins/Label#Label). The relative parts of the label path, including the (possibly renamed) repository, are resolved with respect to the instantiated target's package.
 
-At analysis time (within the rule's implementation function), when retrieving the attribute value from `ctx.attr`, labels are replaced by the corresponding [`Target`](../builtins/Target)s. This allows you to access the providers of the current target's dependencies.
+At analysis time (within the rule's implementation function), when retrieving the attribute value from `ctx.attr`, labels are replaced by the corresponding [`Target`](/versions/8.2.1/rules/lib/builtins/Target)s. This allows you to access the providers of the current target's dependencies.
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `allow_empty` | [bool](../core/bool); default is `True`  True if the attribute can be empty. |
-| `configurable` | [bool](../core/bool); or unbound; default is `unbound`  This argument can only be specified for an attribute of a symbolic macro. If `configurable` is explicitly set to `False`, the symbolic macro attribute is non-configurable - in other words, it cannot take a `select()` value. If the `configurable` is either unbound or explicitly set to `True`, the attribute is configurable and can take a `select()` value. For an attribute of a rule or aspect, `configurable` must be left unbound. Most Starlark rule attributes are always configurable, with the exception of `attr.output()`, `attr.output_list()`, and `attr.license()` rule attributes, which are always non-configurable. |
-| `default` | [dict](../core/dict); or [function](../core/function); default is `{}`  A default value to use if no value for this attribute is given when instantiating the rule.Use strings or the [`Label`](../builtins/Label#Label) function to specify default values, for example, `attr.label_keyed_string_dict(default = {"//a:b": "value", "//a:c": "string"})`. |
-| `doc` | [string](../core/string); or `None`; default is `None`  A description of the attribute that can be extracted by documentation generating tools. |
-| `allow_files` | [bool](../core/bool); or [sequence](../core/list) of [string](../core/string)s; or `None`; default is `None`  Whether `File` targets are allowed. Can be `True`, `False` (default), or a list of file extensions that are allowed (for example, `[".cc", ".cpp"]`). |
-| `allow_rules` | [sequence](../core/list) of [string](../core/string)s; or `None`; default is `None`  Which rule targets (name of the classes) are allowed. This is deprecated (kept only for compatibility), use providers instead. |
-| `providers` | [sequence](../core/list); default is `[]`  The providers that must be given by any dependency appearing in this attribute. The format of this argument is a list of lists of providers -- `*Info` objects returned by [`provider()`](../globals/bzl#provider) (or in the case of a legacy provider, its string name). The dependency must return ALL providers mentioned in at least ONE of the inner lists. As a convenience, this argument may also be a single-level list of providers, in which case it is wrapped in an outer list with one element. It is NOT required that the rule of the dependency advertises those providers in its `provides` parameter, however, it is considered best practice. |
+| `allow_empty` | [bool](/versions/8.2.1/rules/lib/core/bool); default is `True`  True if the attribute can be empty. |
+| `configurable` | [bool](/versions/8.2.1/rules/lib/core/bool); or unbound; default is `unbound`  This argument can only be specified for an attribute of a symbolic macro. If `configurable` is explicitly set to `False`, the symbolic macro attribute is non-configurable - in other words, it cannot take a `select()` value. If the `configurable` is either unbound or explicitly set to `True`, the attribute is configurable and can take a `select()` value. For an attribute of a rule or aspect, `configurable` must be left unbound. Most Starlark rule attributes are always configurable, with the exception of `attr.output()`, `attr.output_list()`, and `attr.license()` rule attributes, which are always non-configurable. |
+| `default` | [dict](/versions/8.2.1/rules/lib/core/dict); or [function](/versions/8.2.1/rules/lib/core/function); default is `{}`  A default value to use if no value for this attribute is given when instantiating the rule.Use strings or the [`Label`](/versions/8.2.1/rules/lib/builtins/Label#Label) function to specify default values, for example, `attr.label_keyed_string_dict(default = {"//a:b": "value", "//a:c": "string"})`. |
+| `doc` | [string](/versions/8.2.1/rules/lib/core/string); or `None`; default is `None`  A description of the attribute that can be extracted by documentation generating tools. |
+| `allow_files` | [bool](/versions/8.2.1/rules/lib/core/bool); or [sequence](/versions/8.2.1/rules/lib/core/list) of [string](/versions/8.2.1/rules/lib/core/string)s; or `None`; default is `None`  Whether `File` targets are allowed. Can be `True`, `False` (default), or a list of file extensions that are allowed (for example, `[".cc", ".cpp"]`). |
+| `allow_rules` | [sequence](/versions/8.2.1/rules/lib/core/list) of [string](/versions/8.2.1/rules/lib/core/string)s; or `None`; default is `None`  Which rule targets (name of the classes) are allowed. This is deprecated (kept only for compatibility), use providers instead. |
+| `providers` | [sequence](/versions/8.2.1/rules/lib/core/list); default is `[]`  The providers that must be given by any dependency appearing in this attribute. The format of this argument is a list of lists of providers -- `*Info` objects returned by [`provider()`](/versions/8.2.1/rules/lib/globals/bzl#provider) (or in the case of a legacy provider, its string name). The dependency must return ALL providers mentioned in at least ONE of the inner lists. As a convenience, this argument may also be a single-level list of providers, in which case it is wrapped in an outer list with one element. It is NOT required that the rule of the dependency advertises those providers in its `provides` parameter, however, it is considered best practice. |
 | `for_dependency_resolution` | default is `unbound`  If this is set, the attribute is available for materializers. Only rules marked with the flag of the same name are allowed to be referenced through such attributes. |
-| `flags` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  Deprecated, will be removed. |
-| `mandatory` | [bool](../core/bool); default is `False`  If true, the value must be specified explicitly (even if it has a `default`). |
+| `flags` | [sequence](/versions/8.2.1/rules/lib/core/list) of [string](/versions/8.2.1/rules/lib/core/string)s; default is `[]`  Deprecated, will be removed. |
+| `mandatory` | [bool](/versions/8.2.1/rules/lib/core/bool); default is `False`  If true, the value must be specified explicitly (even if it has a `default`). |
 | `cfg` | default is `None`  [Configuration](https://bazel.build/versions/8.2.1/extending/rules#configurations) of the attribute. It can be either `"exec"`, which indicates that the dependency is built for the `execution platform`, or `"target"`, which indicates that the dependency is build for the `target platform`. A typical example of the difference is when building mobile apps, where the `target platform` is `Android` or `iOS` while the `execution platform` is `Linux`, `macOS`, or `Windows`. |
-| `aspects` | [sequence](../core/list) of [Aspect](../builtins/Aspect)s; default is `[]`  Aspects that should be applied to the dependency or dependencies specified by this attribute. |
+| `aspects` | [sequence](/versions/8.2.1/rules/lib/core/list) of [Aspect](/versions/8.2.1/rules/lib/builtins/Aspect)s; default is `[]`  Aspects that should be applied to the dependency or dependencies specified by this attribute. |
 
 ## label\_list
 
@@ -145,30 +145,30 @@ At analysis time (within the rule's implementation function), when retrieving th
 Attribute attr.label_list(allow_empty=True, *, configurable=unbound, default=[], materializer=None, doc=None, allow_files=None, allow_rules=None, providers=[], for_dependency_resolution=unbound, flags=[], mandatory=False, skip_validations=False, cfg=None, aspects=[])
 ```
 
-Creates a schema for a list-of-labels attribute. This is a dependency attribute. The corresponding [`ctx.attr`](../builtins/ctx#attr) attribute will be of type [list](../core/list) of [`Target`s](../builtins/Target).
+Creates a schema for a list-of-labels attribute. This is a dependency attribute. The corresponding [`ctx.attr`](/versions/8.2.1/rules/lib/builtins/ctx#attr) attribute will be of type [list](/versions/8.2.1/rules/lib/core/list) of [`Target`s](/versions/8.2.1/rules/lib/builtins/Target).
 
-This attribute contains unique [`Label`](../builtins/Label) values. If a string is supplied in place of a `Label`, it will be converted using the [label constructor](../builtins/Label#Label). The relative parts of the label path, including the (possibly renamed) repository, are resolved with respect to the instantiated target's package.
+This attribute contains unique [`Label`](/versions/8.2.1/rules/lib/builtins/Label) values. If a string is supplied in place of a `Label`, it will be converted using the [label constructor](/versions/8.2.1/rules/lib/builtins/Label#Label). The relative parts of the label path, including the (possibly renamed) repository, are resolved with respect to the instantiated target's package.
 
-At analysis time (within the rule's implementation function), when retrieving the attribute value from `ctx.attr`, labels are replaced by the corresponding [`Target`](../builtins/Target)s. This allows you to access the providers of the current target's dependencies.
+At analysis time (within the rule's implementation function), when retrieving the attribute value from `ctx.attr`, labels are replaced by the corresponding [`Target`](/versions/8.2.1/rules/lib/builtins/Target)s. This allows you to access the providers of the current target's dependencies.
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `allow_empty` | [bool](../core/bool); default is `True`  True if the attribute can be empty. |
-| `configurable` | [bool](../core/bool); or unbound; default is `unbound`  This argument can only be specified for an attribute of a symbolic macro. If `configurable` is explicitly set to `False`, the symbolic macro attribute is non-configurable - in other words, it cannot take a `select()` value. If the `configurable` is either unbound or explicitly set to `True`, the attribute is configurable and can take a `select()` value. For an attribute of a rule or aspect, `configurable` must be left unbound. Most Starlark rule attributes are always configurable, with the exception of `attr.output()`, `attr.output_list()`, and `attr.license()` rule attributes, which are always non-configurable. |
-| `default` | [sequence](../core/list) of [Label](../builtins/Label)s; or [function](../core/function); default is `[]`  A default value to use if no value for this attribute is given when instantiating the rule.Use strings or the [`Label`](../builtins/Label#Label) function to specify default values, for example, `attr.label_list(default = ["//a:b", "//a:c"])`. |
-| `materializer` | [function](../core/function); default is `None`  **Experimental**. This parameter is experimental and may change at any time. Please do not depend on it. It may be enabled on an experimental basis by setting `--experimental_dormant_deps`  If set, the attribute materializes dormant dependencies from the transitive closure. The value of this parameter must be a functon that gets access to the values of the attributes of the rule that either are not dependencies or are marked as available for dependency resolution. It must return either a dormant dependency or a list of them depending on the type of the attribute |
-| `doc` | [string](../core/string); or `None`; default is `None` |
-| `allow_files` | [bool](../core/bool); or [sequence](../core/list) of [string](../core/string)s; or `None`; default is `None`  Whether `File` targets are allowed. Can be `True`, `False` (default), or a list of file extensions that are allowed (for example, `[".cc", ".cpp"]`). |
-| `allow_rules` | [sequence](../core/list) of [string](../core/string)s; or `None`; default is `None`  Which rule targets (name of the classes) are allowed. This is deprecated (kept only for compatibility), use providers instead. |
-| `providers` | [sequence](../core/list); default is `[]`  The providers that must be given by any dependency appearing in this attribute. The format of this argument is a list of lists of providers -- `*Info` objects returned by [`provider()`](../globals/bzl#provider) (or in the case of a legacy provider, its string name). The dependency must return ALL providers mentioned in at least ONE of the inner lists. As a convenience, this argument may also be a single-level list of providers, in which case it is wrapped in an outer list with one element. It is NOT required that the rule of the dependency advertises those providers in its `provides` parameter, however, it is considered best practice. |
+| `allow_empty` | [bool](/versions/8.2.1/rules/lib/core/bool); default is `True`  True if the attribute can be empty. |
+| `configurable` | [bool](/versions/8.2.1/rules/lib/core/bool); or unbound; default is `unbound`  This argument can only be specified for an attribute of a symbolic macro. If `configurable` is explicitly set to `False`, the symbolic macro attribute is non-configurable - in other words, it cannot take a `select()` value. If the `configurable` is either unbound or explicitly set to `True`, the attribute is configurable and can take a `select()` value. For an attribute of a rule or aspect, `configurable` must be left unbound. Most Starlark rule attributes are always configurable, with the exception of `attr.output()`, `attr.output_list()`, and `attr.license()` rule attributes, which are always non-configurable. |
+| `default` | [sequence](/versions/8.2.1/rules/lib/core/list) of [Label](/versions/8.2.1/rules/lib/builtins/Label)s; or [function](/versions/8.2.1/rules/lib/core/function); default is `[]`  A default value to use if no value for this attribute is given when instantiating the rule.Use strings or the [`Label`](/versions/8.2.1/rules/lib/builtins/Label#Label) function to specify default values, for example, `attr.label_list(default = ["//a:b", "//a:c"])`. |
+| `materializer` | [function](/versions/8.2.1/rules/lib/core/function); default is `None`  **Experimental**. This parameter is experimental and may change at any time. Please do not depend on it. It may be enabled on an experimental basis by setting `--experimental_dormant_deps`  If set, the attribute materializes dormant dependencies from the transitive closure. The value of this parameter must be a functon that gets access to the values of the attributes of the rule that either are not dependencies or are marked as available for dependency resolution. It must return either a dormant dependency or a list of them depending on the type of the attribute |
+| `doc` | [string](/versions/8.2.1/rules/lib/core/string); or `None`; default is `None` |
+| `allow_files` | [bool](/versions/8.2.1/rules/lib/core/bool); or [sequence](/versions/8.2.1/rules/lib/core/list) of [string](/versions/8.2.1/rules/lib/core/string)s; or `None`; default is `None`  Whether `File` targets are allowed. Can be `True`, `False` (default), or a list of file extensions that are allowed (for example, `[".cc", ".cpp"]`). |
+| `allow_rules` | [sequence](/versions/8.2.1/rules/lib/core/list) of [string](/versions/8.2.1/rules/lib/core/string)s; or `None`; default is `None`  Which rule targets (name of the classes) are allowed. This is deprecated (kept only for compatibility), use providers instead. |
+| `providers` | [sequence](/versions/8.2.1/rules/lib/core/list); default is `[]`  The providers that must be given by any dependency appearing in this attribute. The format of this argument is a list of lists of providers -- `*Info` objects returned by [`provider()`](/versions/8.2.1/rules/lib/globals/bzl#provider) (or in the case of a legacy provider, its string name). The dependency must return ALL providers mentioned in at least ONE of the inner lists. As a convenience, this argument may also be a single-level list of providers, in which case it is wrapped in an outer list with one element. It is NOT required that the rule of the dependency advertises those providers in its `provides` parameter, however, it is considered best practice. |
 | `for_dependency_resolution` | default is `unbound`  If this is set, the attribute is available for materializers. Only rules marked with the flag of the same name are allowed to be referenced through such attributes. |
-| `flags` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  Deprecated, will be removed. |
-| `mandatory` | [bool](../core/bool); default is `False`  If true, the value must be specified explicitly (even if it has a `default`). |
-| `skip_validations` | [bool](../core/bool); default is `False`  If true, validation actions of transitive dependencies from this attribute will not run. This is a temporary mitigation and WILL be removed in the future. |
+| `flags` | [sequence](/versions/8.2.1/rules/lib/core/list) of [string](/versions/8.2.1/rules/lib/core/string)s; default is `[]`  Deprecated, will be removed. |
+| `mandatory` | [bool](/versions/8.2.1/rules/lib/core/bool); default is `False`  If true, the value must be specified explicitly (even if it has a `default`). |
+| `skip_validations` | [bool](/versions/8.2.1/rules/lib/core/bool); default is `False`  If true, validation actions of transitive dependencies from this attribute will not run. This is a temporary mitigation and WILL be removed in the future. |
 | `cfg` | default is `None`  [Configuration](https://bazel.build/versions/8.2.1/extending/rules#configurations) of the attribute. It can be either `"exec"`, which indicates that the dependency is built for the `execution platform`, or `"target"`, which indicates that the dependency is build for the `target platform`. A typical example of the difference is when building mobile apps, where the `target platform` is `Android` or `iOS` while the `execution platform` is `Linux`, `macOS`, or `Windows`. |
-| `aspects` | [sequence](../core/list) of [Aspect](../builtins/Aspect)s; default is `[]`  Aspects that should be applied to the dependency or dependencies specified by this attribute. |
+| `aspects` | [sequence](/versions/8.2.1/rules/lib/core/list) of [Aspect](/versions/8.2.1/rules/lib/builtins/Aspect)s; default is `[]`  Aspects that should be applied to the dependency or dependencies specified by this attribute. |
 
 ## output
 
@@ -178,16 +178,16 @@ Attribute attr.output(doc=None, mandatory=False)
 
 Creates a schema for an output (label) attribute.
 
-This attribute contains unique [`Label`](../builtins/Label) values. If a string is supplied in place of a `Label`, it will be converted using the [label constructor](../builtins/Label#Label). The relative parts of the label path, including the (possibly renamed) repository, are resolved with respect to the instantiated target's package.
+This attribute contains unique [`Label`](/versions/8.2.1/rules/lib/builtins/Label) values. If a string is supplied in place of a `Label`, it will be converted using the [label constructor](/versions/8.2.1/rules/lib/builtins/Label#Label). The relative parts of the label path, including the (possibly renamed) repository, are resolved with respect to the instantiated target's package.
 
-At analysis time, the corresponding [`File`](../builtins/File) can be retrieved using [`ctx.outputs`](../builtins/ctx#outputs).
+At analysis time, the corresponding [`File`](/versions/8.2.1/rules/lib/builtins/File) can be retrieved using [`ctx.outputs`](/versions/8.2.1/rules/lib/builtins/ctx#outputs).
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `doc` | [string](../core/string); or `None`; default is `None`  A description of the attribute that can be extracted by documentation generating tools. |
-| `mandatory` | [bool](../core/bool); default is `False`  If true, the value must be specified explicitly (even if it has a `default`). |
+| `doc` | [string](/versions/8.2.1/rules/lib/core/string); or `None`; default is `None`  A description of the attribute that can be extracted by documentation generating tools. |
+| `mandatory` | [bool](/versions/8.2.1/rules/lib/core/bool); default is `False`  If true, the value must be specified explicitly (even if it has a `default`). |
 
 ## output\_list
 
@@ -197,17 +197,17 @@ Attribute attr.output_list(allow_empty=True, *, doc=None, mandatory=False)
 
 Creates a schema for a list-of-outputs attribute.
 
-This attribute contains unique [`Label`](../builtins/Label) values. If a string is supplied in place of a `Label`, it will be converted using the [label constructor](../builtins/Label#Label). The relative parts of the label path, including the (possibly renamed) repository, are resolved with respect to the instantiated target's package.
+This attribute contains unique [`Label`](/versions/8.2.1/rules/lib/builtins/Label) values. If a string is supplied in place of a `Label`, it will be converted using the [label constructor](/versions/8.2.1/rules/lib/builtins/Label#Label). The relative parts of the label path, including the (possibly renamed) repository, are resolved with respect to the instantiated target's package.
 
-At analysis time, the corresponding [`File`](../builtins/File) can be retrieved using [`ctx.outputs`](../builtins/ctx#outputs).
+At analysis time, the corresponding [`File`](/versions/8.2.1/rules/lib/builtins/File) can be retrieved using [`ctx.outputs`](/versions/8.2.1/rules/lib/builtins/ctx#outputs).
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `allow_empty` | [bool](../core/bool); default is `True`  True if the attribute can be empty. |
-| `doc` | [string](../core/string); or `None`; default is `None`  A description of the attribute that can be extracted by documentation generating tools. |
-| `mandatory` | [bool](../core/bool); default is `False`  If true, the value must be specified explicitly (even if it has a `default`). |
+| `allow_empty` | [bool](/versions/8.2.1/rules/lib/core/bool); default is `True`  True if the attribute can be empty. |
+| `doc` | [string](/versions/8.2.1/rules/lib/core/string); or `None`; default is `None`  A description of the attribute that can be extracted by documentation generating tools. |
+| `mandatory` | [bool](/versions/8.2.1/rules/lib/core/bool); default is `False`  If true, the value must be specified explicitly (even if it has a `default`). |
 
 ## string
 
@@ -215,17 +215,17 @@ At analysis time, the corresponding [`File`](../builtins/File) can be retrieved
 Attribute attr.string(configurable=unbound, default='', doc=None, mandatory=False, values=[])
 ```
 
-Creates a schema for a [string](../core/string#attr) attribute.
+Creates a schema for a [string](/versions/8.2.1/rules/lib/core/string#attr) attribute.
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `configurable` | [bool](../core/bool); or unbound; default is `unbound`  This argument can only be specified for an attribute of a symbolic macro. If `configurable` is explicitly set to `False`, the symbolic macro attribute is non-configurable - in other words, it cannot take a `select()` value. If the `configurable` is either unbound or explicitly set to `True`, the attribute is configurable and can take a `select()` value. For an attribute of a rule or aspect, `configurable` must be left unbound. Most Starlark rule attributes are always configurable, with the exception of `attr.output()`, `attr.output_list()`, and `attr.license()` rule attributes, which are always non-configurable. |
-| `default` | [string](../core/string); or NativeComputedDefault; default is `''`  A default value to use if no value for this attribute is given when instantiating the rule. |
-| `doc` | [string](../core/string); or `None`; default is `None`  A description of the attribute that can be extracted by documentation generating tools. |
-| `mandatory` | [bool](../core/bool); default is `False`  If true, the value must be specified explicitly (even if it has a `default`). |
-| `values` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  The list of allowed values for the attribute. An error is raised if any other value is given. |
+| `configurable` | [bool](/versions/8.2.1/rules/lib/core/bool); or unbound; default is `unbound`  This argument can only be specified for an attribute of a symbolic macro. If `configurable` is explicitly set to `False`, the symbolic macro attribute is non-configurable - in other words, it cannot take a `select()` value. If the `configurable` is either unbound or explicitly set to `True`, the attribute is configurable and can take a `select()` value. For an attribute of a rule or aspect, `configurable` must be left unbound. Most Starlark rule attributes are always configurable, with the exception of `attr.output()`, `attr.output_list()`, and `attr.license()` rule attributes, which are always non-configurable. |
+| `default` | [string](/versions/8.2.1/rules/lib/core/string); or NativeComputedDefault; default is `''`  A default value to use if no value for this attribute is given when instantiating the rule. |
+| `doc` | [string](/versions/8.2.1/rules/lib/core/string); or `None`; default is `None`  A description of the attribute that can be extracted by documentation generating tools. |
+| `mandatory` | [bool](/versions/8.2.1/rules/lib/core/bool); default is `False`  If true, the value must be specified explicitly (even if it has a `default`). |
+| `values` | [sequence](/versions/8.2.1/rules/lib/core/list) of [string](/versions/8.2.1/rules/lib/core/string)s; default is `[]`  The list of allowed values for the attribute. An error is raised if any other value is given. |
 
 ## string\_dict
 
@@ -239,11 +239,11 @@ Creates a schema for an attribute holding a dictionary, where the keys and value
 
 | Parameter | Description |
 | --- | --- |
-| `allow_empty` | [bool](../core/bool); default is `True`  True if the attribute can be empty. |
-| `configurable` | [bool](../core/bool); or unbound; default is `unbound`  This argument can only be specified for an attribute of a symbolic macro. If `configurable` is explicitly set to `False`, the symbolic macro attribute is non-configurable - in other words, it cannot take a `select()` value. If the `configurable` is either unbound or explicitly set to `True`, the attribute is configurable and can take a `select()` value. For an attribute of a rule or aspect, `configurable` must be left unbound. Most Starlark rule attributes are always configurable, with the exception of `attr.output()`, `attr.output_list()`, and `attr.license()` rule attributes, which are always non-configurable. |
-| `default` | [dict](../core/dict); default is `{}`  A default value to use if no value for this attribute is given when instantiating the rule. |
-| `doc` | [string](../core/string); or `None`; default is `None`  A description of the attribute that can be extracted by documentation generating tools. |
-| `mandatory` | [bool](../core/bool); default is `False`  If true, the value must be specified explicitly (even if it has a `default`). |
+| `allow_empty` | [bool](/versions/8.2.1/rules/lib/core/bool); default is `True`  True if the attribute can be empty. |
+| `configurable` | [bool](/versions/8.2.1/rules/lib/core/bool); or unbound; default is `unbound`  This argument can only be specified for an attribute of a symbolic macro. If `configurable` is explicitly set to `False`, the symbolic macro attribute is non-configurable - in other words, it cannot take a `select()` value. If the `configurable` is either unbound or explicitly set to `True`, the attribute is configurable and can take a `select()` value. For an attribute of a rule or aspect, `configurable` must be left unbound. Most Starlark rule attributes are always configurable, with the exception of `attr.output()`, `attr.output_list()`, and `attr.license()` rule attributes, which are always non-configurable. |
+| `default` | [dict](/versions/8.2.1/rules/lib/core/dict); default is `{}`  A default value to use if no value for this attribute is given when instantiating the rule. |
+| `doc` | [string](/versions/8.2.1/rules/lib/core/string); or `None`; default is `None`  A description of the attribute that can be extracted by documentation generating tools. |
+| `mandatory` | [bool](/versions/8.2.1/rules/lib/core/bool); default is `False`  If true, the value must be specified explicitly (even if it has a `default`). |
 
 ## string\_keyed\_label\_dict
 
@@ -253,26 +253,26 @@ Attribute attr.string_keyed_label_dict(allow_empty=True, *, configurable=unbound
 
 Creates a schema for an attribute whose value is a dictionary where the keys are strings and the values are labels. This is a dependency attribute.
 
-This attribute contains unique [`Label`](../builtins/Label) values. If a string is supplied in place of a `Label`, it will be converted using the [label constructor](../builtins/Label#Label). The relative parts of the label path, including the (possibly renamed) repository, are resolved with respect to the instantiated target's package.
+This attribute contains unique [`Label`](/versions/8.2.1/rules/lib/builtins/Label) values. If a string is supplied in place of a `Label`, it will be converted using the [label constructor](/versions/8.2.1/rules/lib/builtins/Label#Label). The relative parts of the label path, including the (possibly renamed) repository, are resolved with respect to the instantiated target's package.
 
-At analysis time (within the rule's implementation function), when retrieving the attribute value from `ctx.attr`, labels are replaced by the corresponding [`Target`](../builtins/Target)s. This allows you to access the providers of the current target's dependencies.
+At analysis time (within the rule's implementation function), when retrieving the attribute value from `ctx.attr`, labels are replaced by the corresponding [`Target`](/versions/8.2.1/rules/lib/builtins/Target)s. This allows you to access the providers of the current target's dependencies.
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `allow_empty` | [bool](../core/bool); default is `True`  True if the attribute can be empty. |
-| `configurable` | [bool](../core/bool); or unbound; default is `unbound`  This argument can only be specified for an attribute of a symbolic macro. If `configurable` is explicitly set to `False`, the symbolic macro attribute is non-configurable - in other words, it cannot take a `select()` value. If the `configurable` is either unbound or explicitly set to `True`, the attribute is configurable and can take a `select()` value. For an attribute of a rule or aspect, `configurable` must be left unbound. Most Starlark rule attributes are always configurable, with the exception of `attr.output()`, `attr.output_list()`, and `attr.license()` rule attributes, which are always non-configurable. |
-| `default` | [dict](../core/dict); or [function](../core/function); default is `{}`  A default value to use if no value for this attribute is given when instantiating the rule.Use strings or the [`Label`](../builtins/Label#Label) function to specify default values, for example, `attr.string_keyed_label_dict(default = {"foo": "//a:b", "bar": "//a:c"})`. |
-| `doc` | [string](../core/string); or `None`; default is `None`  A description of the attribute that can be extracted by documentation generating tools. |
-| `allow_files` | [bool](../core/bool); or [sequence](../core/list) of [string](../core/string)s; or `None`; default is `None`  Whether `File` targets are allowed. Can be `True`, `False` (default), or a list of file extensions that are allowed (for example, `[".cc", ".cpp"]`). |
-| `allow_rules` | [sequence](../core/list) of [string](../core/string)s; or `None`; default is `None`  Which rule targets (name of the classes) are allowed. This is deprecated (kept only for compatibility), use providers instead. |
-| `providers` | [sequence](../core/list); default is `[]`  The providers that must be given by any dependency appearing in this attribute. The format of this argument is a list of lists of providers -- `*Info` objects returned by [`provider()`](../globals/bzl#provider) (or in the case of a legacy provider, its string name). The dependency must return ALL providers mentioned in at least ONE of the inner lists. As a convenience, this argument may also be a single-level list of providers, in which case it is wrapped in an outer list with one element. It is NOT required that the rule of the dependency advertises those providers in its `provides` parameter, however, it is considered best practice. |
+| `allow_empty` | [bool](/versions/8.2.1/rules/lib/core/bool); default is `True`  True if the attribute can be empty. |
+| `configurable` | [bool](/versions/8.2.1/rules/lib/core/bool); or unbound; default is `unbound`  This argument can only be specified for an attribute of a symbolic macro. If `configurable` is explicitly set to `False`, the symbolic macro attribute is non-configurable - in other words, it cannot take a `select()` value. If the `configurable` is either unbound or explicitly set to `True`, the attribute is configurable and can take a `select()` value. For an attribute of a rule or aspect, `configurable` must be left unbound. Most Starlark rule attributes are always configurable, with the exception of `attr.output()`, `attr.output_list()`, and `attr.license()` rule attributes, which are always non-configurable. |
+| `default` | [dict](/versions/8.2.1/rules/lib/core/dict); or [function](/versions/8.2.1/rules/lib/core/function); default is `{}`  A default value to use if no value for this attribute is given when instantiating the rule.Use strings or the [`Label`](/versions/8.2.1/rules/lib/builtins/Label#Label) function to specify default values, for example, `attr.string_keyed_label_dict(default = {"foo": "//a:b", "bar": "//a:c"})`. |
+| `doc` | [string](/versions/8.2.1/rules/lib/core/string); or `None`; default is `None`  A description of the attribute that can be extracted by documentation generating tools. |
+| `allow_files` | [bool](/versions/8.2.1/rules/lib/core/bool); or [sequence](/versions/8.2.1/rules/lib/core/list) of [string](/versions/8.2.1/rules/lib/core/string)s; or `None`; default is `None`  Whether `File` targets are allowed. Can be `True`, `False` (default), or a list of file extensions that are allowed (for example, `[".cc", ".cpp"]`). |
+| `allow_rules` | [sequence](/versions/8.2.1/rules/lib/core/list) of [string](/versions/8.2.1/rules/lib/core/string)s; or `None`; default is `None`  Which rule targets (name of the classes) are allowed. This is deprecated (kept only for compatibility), use providers instead. |
+| `providers` | [sequence](/versions/8.2.1/rules/lib/core/list); default is `[]`  The providers that must be given by any dependency appearing in this attribute. The format of this argument is a list of lists of providers -- `*Info` objects returned by [`provider()`](/versions/8.2.1/rules/lib/globals/bzl#provider) (or in the case of a legacy provider, its string name). The dependency must return ALL providers mentioned in at least ONE of the inner lists. As a convenience, this argument may also be a single-level list of providers, in which case it is wrapped in an outer list with one element. It is NOT required that the rule of the dependency advertises those providers in its `provides` parameter, however, it is considered best practice. |
 | `for_dependency_resolution` | default is `unbound`  If this is set, the attribute is available for materializers. Only rules marked with the flag of the same name are allowed to be referenced through such attributes. |
-| `flags` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  Deprecated, will be removed. |
-| `mandatory` | [bool](../core/bool); default is `False`  If true, the value must be specified explicitly (even if it has a `default`). |
+| `flags` | [sequence](/versions/8.2.1/rules/lib/core/list) of [string](/versions/8.2.1/rules/lib/core/string)s; default is `[]`  Deprecated, will be removed. |
+| `mandatory` | [bool](/versions/8.2.1/rules/lib/core/bool); default is `False`  If true, the value must be specified explicitly (even if it has a `default`). |
 | `cfg` | default is `None`  [Configuration](https://bazel.build/versions/8.2.1/extending/rules#configurations) of the attribute. It can be either `"exec"`, which indicates that the dependency is built for the `execution platform`, or `"target"`, which indicates that the dependency is build for the `target platform`. A typical example of the difference is when building mobile apps, where the `target platform` is `Android` or `iOS` while the `execution platform` is `Linux`, `macOS`, or `Windows`. |
-| `aspects` | [sequence](../core/list) of [Aspect](../builtins/Aspect)s; default is `[]`  Aspects that should be applied to the dependency or dependencies specified by this attribute. |
+| `aspects` | [sequence](/versions/8.2.1/rules/lib/core/list) of [Aspect](/versions/8.2.1/rules/lib/builtins/Aspect)s; default is `[]`  Aspects that should be applied to the dependency or dependencies specified by this attribute. |
 
 ## string\_list
 
@@ -286,11 +286,11 @@ Creates a schema for a list-of-strings attribute.
 
 | Parameter | Description |
 | --- | --- |
-| `mandatory` | [bool](../core/bool); default is `False`  If true, the value must be specified explicitly (even if it has a `default`). |
-| `allow_empty` | [bool](../core/bool); default is `True`  True if the attribute can be empty. |
-| `configurable` | [bool](../core/bool); or unbound; default is `unbound`  This argument can only be specified for an attribute of a symbolic macro. If `configurable` is explicitly set to `False`, the symbolic macro attribute is non-configurable - in other words, it cannot take a `select()` value. If the `configurable` is either unbound or explicitly set to `True`, the attribute is configurable and can take a `select()` value. For an attribute of a rule or aspect, `configurable` must be left unbound. Most Starlark rule attributes are always configurable, with the exception of `attr.output()`, `attr.output_list()`, and `attr.license()` rule attributes, which are always non-configurable. |
-| `default` | [sequence](../core/list) of [string](../core/string)s; or NativeComputedDefault; default is `[]`  A default value to use if no value for this attribute is given when instantiating the rule. |
-| `doc` | [string](../core/string); or `None`; default is `None`  A description of the attribute that can be extracted by documentation generating tools. |
+| `mandatory` | [bool](/versions/8.2.1/rules/lib/core/bool); default is `False`  If true, the value must be specified explicitly (even if it has a `default`). |
+| `allow_empty` | [bool](/versions/8.2.1/rules/lib/core/bool); default is `True`  True if the attribute can be empty. |
+| `configurable` | [bool](/versions/8.2.1/rules/lib/core/bool); or unbound; default is `unbound`  This argument can only be specified for an attribute of a symbolic macro. If `configurable` is explicitly set to `False`, the symbolic macro attribute is non-configurable - in other words, it cannot take a `select()` value. If the `configurable` is either unbound or explicitly set to `True`, the attribute is configurable and can take a `select()` value. For an attribute of a rule or aspect, `configurable` must be left unbound. Most Starlark rule attributes are always configurable, with the exception of `attr.output()`, `attr.output_list()`, and `attr.license()` rule attributes, which are always non-configurable. |
+| `default` | [sequence](/versions/8.2.1/rules/lib/core/list) of [string](/versions/8.2.1/rules/lib/core/string)s; or NativeComputedDefault; default is `[]`  A default value to use if no value for this attribute is given when instantiating the rule. |
+| `doc` | [string](/versions/8.2.1/rules/lib/core/string); or `None`; default is `None`  A description of the attribute that can be extracted by documentation generating tools. |
 
 ## string\_list\_dict
 
@@ -304,8 +304,8 @@ Creates a schema for an attribute holding a dictionary, where the keys are strin
 
 | Parameter | Description |
 | --- | --- |
-| `allow_empty` | [bool](../core/bool); default is `True`  True if the attribute can be empty. |
-| `configurable` | [bool](../core/bool); or unbound; default is `unbound`  This argument can only be specified for an attribute of a symbolic macro. If `configurable` is explicitly set to `False`, the symbolic macro attribute is non-configurable - in other words, it cannot take a `select()` value. If the `configurable` is either unbound or explicitly set to `True`, the attribute is configurable and can take a `select()` value. For an attribute of a rule or aspect, `configurable` must be left unbound. Most Starlark rule attributes are always configurable, with the exception of `attr.output()`, `attr.output_list()`, and `attr.license()` rule attributes, which are always non-configurable. |
-| `default` | [dict](../core/dict); default is `{}`  A default value to use if no value for this attribute is given when instantiating the rule. |
-| `doc` | [string](../core/string); or `None`; default is `None`  A description of the attribute that can be extracted by documentation generating tools. |
-| `mandatory` | [bool](../core/bool); default is `False`  If true, the value must be specified explicitly (even if it has a `default`). |
\ No newline at end of file
+| `allow_empty` | [bool](/versions/8.2.1/rules/lib/core/bool); default is `True`  True if the attribute can be empty. |
+| `configurable` | [bool](/versions/8.2.1/rules/lib/core/bool); or unbound; default is `unbound`  This argument can only be specified for an attribute of a symbolic macro. If `configurable` is explicitly set to `False`, the symbolic macro attribute is non-configurable - in other words, it cannot take a `select()` value. If the `configurable` is either unbound or explicitly set to `True`, the attribute is configurable and can take a `select()` value. For an attribute of a rule or aspect, `configurable` must be left unbound. Most Starlark rule attributes are always configurable, with the exception of `attr.output()`, `attr.output_list()`, and `attr.license()` rule attributes, which are always non-configurable. |
+| `default` | [dict](/versions/8.2.1/rules/lib/core/dict); default is `{}`  A default value to use if no value for this attribute is given when instantiating the rule. |
+| `doc` | [string](/versions/8.2.1/rules/lib/core/string); or `None`; default is `None`  A description of the attribute that can be extracted by documentation generating tools. |
+| `mandatory` | [bool](/versions/8.2.1/rules/lib/core/bool); default is `False`  If true, the value must be specified explicitly (even if it has a `default`). |
\ No newline at end of file
diff --git a/versions/8.2.1/rules/lib/toplevel/cc_common.mdx b/versions/8.2.1/rules/lib/toplevel/cc_common.mdx
index 9ebba717..16c2d0d1 100644
--- a/versions/8.2.1/rules/lib/toplevel/cc_common.mdx
+++ b/versions/8.2.1/rules/lib/toplevel/cc_common.mdx
@@ -42,8 +42,8 @@ Returns True if given action\_config is enabled in the feature configuration.
 
 | Parameter | Description |
 | --- | --- |
-| `feature_configuration` | [FeatureConfiguration](../builtins/FeatureConfiguration); required  Feature configuration to be queried. |
-| `action_name` | [string](../core/string); required  Name of the action\_config. |
+| `feature_configuration` | [FeatureConfiguration](/versions/8.2.1/rules/lib/builtins/FeatureConfiguration); required  Feature configuration to be queried. |
+| `action_name` | [string](/versions/8.2.1/rules/lib/core/string); required  Name of the action\_config. |
 
 ## CcToolchainInfo
 
@@ -65,29 +65,29 @@ Should be used for C++ compilation. Returns tuple of (`CompilationContext`, `CcC
 
 | Parameter | Description |
 | --- | --- |
-| `actions` | [actions](../builtins/actions); required  `actions` object. |
-| `feature_configuration` | [FeatureConfiguration](../builtins/FeatureConfiguration); required  `feature_configuration` to be queried. |
+| `actions` | [actions](/versions/8.2.1/rules/lib/builtins/actions); required  `actions` object. |
+| `feature_configuration` | [FeatureConfiguration](/versions/8.2.1/rules/lib/builtins/FeatureConfiguration); required  `feature_configuration` to be queried. |
 | `cc_toolchain` | Info; required  `CcToolchainInfo` provider to be used. |
-| `srcs` | [sequence](../core/list); default is `[]`  The list of source files to be compiled. |
-| `public_hdrs` | [sequence](../core/list); default is `[]`  List of headers needed for compilation of srcs and may be included by dependent rules transitively. |
-| `private_hdrs` | [sequence](../core/list); default is `[]`  List of headers needed for compilation of srcs and NOT to be included by dependent rules. |
-| `includes` | [sequence](../core/list); or [depset](../builtins/depset); default is `[]`  Search paths for header files referenced both by angle bracket and quotes. Usually passed with -I. Propagated to dependents transitively. |
-| `quote_includes` | [sequence](../core/list); default is `[]`  Search paths for header files referenced by quotes, e.g. #include "foo/bar/header.h". They can be either relative to the exec root or absolute. Usually passed with -iquote. Propagated to dependents transitively. |
-| `system_includes` | [sequence](../core/list); default is `[]`  Search paths for header files referenced by angle brackets, e.g. `#include `. They can be either relative to the exec root or absolute. Usually passed with -isystem. Propagated to dependents transitively. |
-| `framework_includes` | [sequence](../core/list); default is `[]`  Search paths for header files from Apple frameworks. They can be either relative to the exec root or absolute. Usually passed with -F. Propagated to dependents transitively. |
-| `defines` | [sequence](../core/list); default is `[]`  Set of defines needed to compile this target. Each define is a string. Propagated to dependents transitively. |
-| `local_defines` | [sequence](../core/list); default is `[]`  Set of defines needed to compile this target. Each define is a string. Not propagated to dependents transitively. |
-| `include_prefix` | [string](../core/string); default is `''`  The prefix to add to the paths of the headers of this rule. When set, the headers in the hdrs attribute of this rule are accessible at is the value of this attribute prepended to their repository-relative path. The prefix in the strip\_include\_prefix attribute is removed before this prefix is added. |
-| `strip_include_prefix` | [string](../core/string); default is `''`  The prefix to strip from the paths of the headers of this rule. When set, the headers in the hdrs attribute of this rule are accessible at their path with this prefix cut off. If it's a relative path, it's taken as a package-relative one. If it's an absolute one, it's understood as a repository-relative path. The prefix in the include\_prefix attribute is added after this prefix is stripped. |
-| `user_compile_flags` | [sequence](../core/list); default is `[]`  Additional list of compilation options. |
-| `conly_flags` | [sequence](../core/list); default is `[]`  Additional list of compilation options for C compiles. |
-| `cxx_flags` | [sequence](../core/list); default is `[]`  Additional list of compilation options for C++ compiles. |
-| `compilation_contexts` | [sequence](../core/list); default is `[]`  Headers from dependencies used for compilation. |
-| `name` | [string](../core/string); required  This is used for naming the output artifacts of actions created by this method. See also the `main\_output` arg. |
-| `disallow_pic_outputs` | [bool](../core/bool); default is `False`  Whether PIC outputs should be created. |
-| `disallow_nopic_outputs` | [bool](../core/bool); default is `False`  Whether NOPIC outputs should be created. |
-| `additional_inputs` | [sequence](../core/list); default is `[]`  List of additional files needed for compilation of srcs |
-| `module_interfaces` | [sequence](../core/list); default is `unbound`  The list of module interfaces source files to be compiled. Note: this is an experimental feature, only enabled with --experimental\_cpp\_modules |
+| `srcs` | [sequence](/versions/8.2.1/rules/lib/core/list); default is `[]`  The list of source files to be compiled. |
+| `public_hdrs` | [sequence](/versions/8.2.1/rules/lib/core/list); default is `[]`  List of headers needed for compilation of srcs and may be included by dependent rules transitively. |
+| `private_hdrs` | [sequence](/versions/8.2.1/rules/lib/core/list); default is `[]`  List of headers needed for compilation of srcs and NOT to be included by dependent rules. |
+| `includes` | [sequence](/versions/8.2.1/rules/lib/core/list); or [depset](/versions/8.2.1/rules/lib/builtins/depset); default is `[]`  Search paths for header files referenced both by angle bracket and quotes. Usually passed with -I. Propagated to dependents transitively. |
+| `quote_includes` | [sequence](/versions/8.2.1/rules/lib/core/list); default is `[]`  Search paths for header files referenced by quotes, e.g. #include "foo/bar/header.h". They can be either relative to the exec root or absolute. Usually passed with -iquote. Propagated to dependents transitively. |
+| `system_includes` | [sequence](/versions/8.2.1/rules/lib/core/list); default is `[]`  Search paths for header files referenced by angle brackets, e.g. `#include `. They can be either relative to the exec root or absolute. Usually passed with -isystem. Propagated to dependents transitively. |
+| `framework_includes` | [sequence](/versions/8.2.1/rules/lib/core/list); default is `[]`  Search paths for header files from Apple frameworks. They can be either relative to the exec root or absolute. Usually passed with -F. Propagated to dependents transitively. |
+| `defines` | [sequence](/versions/8.2.1/rules/lib/core/list); default is `[]`  Set of defines needed to compile this target. Each define is a string. Propagated to dependents transitively. |
+| `local_defines` | [sequence](/versions/8.2.1/rules/lib/core/list); default is `[]`  Set of defines needed to compile this target. Each define is a string. Not propagated to dependents transitively. |
+| `include_prefix` | [string](/versions/8.2.1/rules/lib/core/string); default is `''`  The prefix to add to the paths of the headers of this rule. When set, the headers in the hdrs attribute of this rule are accessible at is the value of this attribute prepended to their repository-relative path. The prefix in the strip\_include\_prefix attribute is removed before this prefix is added. |
+| `strip_include_prefix` | [string](/versions/8.2.1/rules/lib/core/string); default is `''`  The prefix to strip from the paths of the headers of this rule. When set, the headers in the hdrs attribute of this rule are accessible at their path with this prefix cut off. If it's a relative path, it's taken as a package-relative one. If it's an absolute one, it's understood as a repository-relative path. The prefix in the include\_prefix attribute is added after this prefix is stripped. |
+| `user_compile_flags` | [sequence](/versions/8.2.1/rules/lib/core/list); default is `[]`  Additional list of compilation options. |
+| `conly_flags` | [sequence](/versions/8.2.1/rules/lib/core/list); default is `[]`  Additional list of compilation options for C compiles. |
+| `cxx_flags` | [sequence](/versions/8.2.1/rules/lib/core/list); default is `[]`  Additional list of compilation options for C++ compiles. |
+| `compilation_contexts` | [sequence](/versions/8.2.1/rules/lib/core/list); default is `[]`  Headers from dependencies used for compilation. |
+| `name` | [string](/versions/8.2.1/rules/lib/core/string); required  This is used for naming the output artifacts of actions created by this method. See also the `main\_output` arg. |
+| `disallow_pic_outputs` | [bool](/versions/8.2.1/rules/lib/core/bool); default is `False`  Whether PIC outputs should be created. |
+| `disallow_nopic_outputs` | [bool](/versions/8.2.1/rules/lib/core/bool); default is `False`  Whether NOPIC outputs should be created. |
+| `additional_inputs` | [sequence](/versions/8.2.1/rules/lib/core/list); default is `[]`  List of additional files needed for compilation of srcs |
+| `module_interfaces` | [sequence](/versions/8.2.1/rules/lib/core/list); default is `unbound`  The list of module interfaces source files to be compiled. Note: this is an experimental feature, only enabled with --experimental\_cpp\_modules |
 
 ## configure\_features
 
@@ -101,11 +101,11 @@ Creates a feature\_configuration instance. Requires the cpp configuration fragme
 
 | Parameter | Description |
 | --- | --- |
-| `ctx` | [ctx](../builtins/ctx); or `None`; default is `None`  The rule context. |
+| `ctx` | [ctx](/versions/8.2.1/rules/lib/builtins/ctx); or `None`; default is `None`  The rule context. |
 | `cc_toolchain` | Info; required  cc\_toolchain for which we configure features. |
-| `language` | [string](../core/string); or `None`; default is `None`  The language to configure for: either c++ or objc (default c++) |
-| `requested_features` | [sequence](../core/list); default is `[]`  List of features to be enabled. |
-| `unsupported_features` | [sequence](../core/list); default is `[]`  List of features that are unsupported by the current rule. |
+| `language` | [string](/versions/8.2.1/rules/lib/core/string); or `None`; default is `None`  The language to configure for: either c++ or objc (default c++) |
+| `requested_features` | [sequence](/versions/8.2.1/rules/lib/core/list); default is `[]`  List of features to be enabled. |
+| `unsupported_features` | [sequence](/versions/8.2.1/rules/lib/core/list); default is `[]`  List of features that are unsupported by the current rule. |
 
 ## create\_cc\_toolchain\_config\_info
 
@@ -119,22 +119,22 @@ Creates a `CcToolchainConfigInfo` provider
 
 | Parameter | Description |
 | --- | --- |
-| `ctx` | [ctx](../builtins/ctx); required  The rule context. |
-| `features` | [sequence](../core/list); default is `[]`  Contains all flag specifications for one feature. Arguments:  `name`: The feature's name. It is possible to introduce a feature without a change to Bazel by adding a 'feature' section to the toolchain and adding the corresponding string as feature in the `BUILD` file.  `enabled`: If 'True', this feature is enabled unless a rule type explicitly marks it as unsupported.  `flag_sets`: A FlagSet list. If the given feature is enabled, the flag sets will be applied for the actions are specified for.  `env_sets`: an EnvSet list. If the given feature is enabled, the env sets will be applied for the actions they are specified for.  `requires`: A list of feature sets defining when this feature is supported by the toolchain. The feature is supported if any of the feature sets fully apply, that is, when all features of a feature set are enabled. If `requires` is omitted, the feature is supported independently of which other features are enabled. Use this for example to filter flags depending on the build mode enabled (opt / fastbuild / dbg).  `implies`: A string list of features or action configs that are automatically enabled when this feature is enabled. If any of the implied features or action configs cannot be enabled, this feature will (silently) not be enabled either.  `provides`: A list of names this feature conflicts with. A feature cannot be enabled if:- `provides` contains the name of a different feature or action config that we want to enable.- `provides` contains the same value as a 'provides' in a different feature or action config that we want to enable. Use this in order to ensure that incompatible features cannot be accidentally activated at the same time, leading to hard to diagnose compiler errors. |
-| `action_configs` | [sequence](../core/list); default is `[]`  An action config corresponds to a Bazel action, and allows selection of a tool based on activated features. Action config activation occurs by the same semantics as features: a feature can 'require' or 'imply' an action config in the same way that it would another feature. Arguments:  `action_name`: The name of the Bazel action that this config applies to, e.g. 'c-compile' or 'c-module-compile'.  `enabled`: If 'True', this action is enabled unless a rule type explicitly marks it as unsupported.  `tools`: The tool applied to the action will be the first tool with a feature set that matches the feature configuration. An error will be thrown if no tool matches a provided feature configuration - for that reason, it's a good idea to provide a default tool with an empty feature set.  `flag_sets`: If the given action config is enabled, the flag sets will be applied to the corresponding action.  `implies`: A list of features or action configs that are automatically enabled when this action config is enabled. If any of the implied features or action configs cannot be enabled, this action config will (silently) not be enabled either. |
-| `artifact_name_patterns` | [sequence](../core/list); default is `[]`  The name for an artifact of a given category of input or output artifacts to an action. Arguments:  `category_name`: The category of artifacts that this selection applies to. This field is compared against a list of categories defined in Bazel. Example categories include "linked\_output" or the artifact for this selection. Together with the extension it is used to create an artifact name based on the target name.  `extension`: The extension for creating the artifact for this selection. Together with the prefix it is used to create an artifact name based on the target name. |
-| `cxx_builtin_include_directories` | [sequence](../core/list); default is `[]`  Built-in include directories for C++ compilation. These should be the exact paths used by the compiler, and are generally relative to the exec root.  The paths used by the compiler can be determined by 'gcc -E -xc++ - -v'.  We currently use the C++ paths also for C compilation, which is safe as long as there are no name clashes between C++ and C header files.  Relative paths are resolved relative to the configuration file directory.  If the compiler has --sysroot support, then these paths should use %sysroot% rather than the include path, and specify the sysroot attribute in order to give blaze the information necessary to make the correct replacements. |
-| `toolchain_identifier` | [string](../core/string); required  The unique identifier of the toolchain within the crosstool release. It must be possible to use this as a directory name in a path.  It has to match the following regex: [a-zA-Z\_][\.\- \w]\* |
-| `host_system_name` | [string](../core/string); or `None`; default is `None`  Ignored. |
-| `target_system_name` | [string](../core/string); or `None`; default is `None`  Deprecated. The GNU System Name. The string is exposed to CcToolchainInfo.target\_gnu\_system\_name. |
-| `target_cpu` | [string](../core/string); or `None`; default is `None`  Deprecated: Use cpu based constraints instead. If the string is "k8", `target\_cpu` will be omitted from the filename of raw FDO profile data. |
-| `target_libc` | [string](../core/string); or `None`; default is `None`  Deprecated: Use OS based constraints instead. The libc version string (e.g. "glibc-2.2.2"). If the string is "macosx", platform is assumed to be MacOS. Otherwise, Linux. The string is exposed to CcToolchainInfo.libc. |
-| `compiler` | [string](../core/string); required  The compiler string (e.g. "gcc"). The current toolchain's compiler is exposed to `@bazel\_tools//tools/cpp:compiler (compiler\_flag)` as a flag value. Targets that require compiler-specific flags can use the config\_settings in https://github.com/bazelbuild/rules\_cc/blob/main/cc/compiler/BUILD in select() statements or create custom config\_setting if the existing settings don't suffice. |
-| `abi_version` | [string](../core/string); or `None`; default is `None`  The abi in use, which is a gcc version. E.g.: "gcc-3.4". The string is set to C++ toolchain variable ABI. |
-| `abi_libc_version` | [string](../core/string); or `None`; default is `None`  The glibc version used by the abi we're using. The string is set to C++ toolchain variable ABI\_LIBC\_VERSION. |
-| `tool_paths` | [sequence](../core/list); default is `[]`  Tool locations. Arguments:  `name`: Name of the tool.  `path`: Location of the tool; Can be absolute path (in case of non hermetic toolchain), or path relative to the cc\_toolchain's package. |
-| `make_variables` | [sequence](../core/list); default is `[]`  A make variable that is made accessible to rules. |
-| `builtin_sysroot` | [string](../core/string); or `None`; default is `None`  The built-in sysroot. If this attribute is not present, Bazel does not allow using a different sysroot, i.e. through the --grte\_top option. |
+| `ctx` | [ctx](/versions/8.2.1/rules/lib/builtins/ctx); required  The rule context. |
+| `features` | [sequence](/versions/8.2.1/rules/lib/core/list); default is `[]`  Contains all flag specifications for one feature. Arguments:  `name`: The feature's name. It is possible to introduce a feature without a change to Bazel by adding a 'feature' section to the toolchain and adding the corresponding string as feature in the `BUILD` file.  `enabled`: If 'True', this feature is enabled unless a rule type explicitly marks it as unsupported.  `flag_sets`: A FlagSet list. If the given feature is enabled, the flag sets will be applied for the actions are specified for.  `env_sets`: an EnvSet list. If the given feature is enabled, the env sets will be applied for the actions they are specified for.  `requires`: A list of feature sets defining when this feature is supported by the toolchain. The feature is supported if any of the feature sets fully apply, that is, when all features of a feature set are enabled. If `requires` is omitted, the feature is supported independently of which other features are enabled. Use this for example to filter flags depending on the build mode enabled (opt / fastbuild / dbg).  `implies`: A string list of features or action configs that are automatically enabled when this feature is enabled. If any of the implied features or action configs cannot be enabled, this feature will (silently) not be enabled either.  `provides`: A list of names this feature conflicts with. A feature cannot be enabled if:- `provides` contains the name of a different feature or action config that we want to enable.- `provides` contains the same value as a 'provides' in a different feature or action config that we want to enable. Use this in order to ensure that incompatible features cannot be accidentally activated at the same time, leading to hard to diagnose compiler errors. |
+| `action_configs` | [sequence](/versions/8.2.1/rules/lib/core/list); default is `[]`  An action config corresponds to a Bazel action, and allows selection of a tool based on activated features. Action config activation occurs by the same semantics as features: a feature can 'require' or 'imply' an action config in the same way that it would another feature. Arguments:  `action_name`: The name of the Bazel action that this config applies to, e.g. 'c-compile' or 'c-module-compile'.  `enabled`: If 'True', this action is enabled unless a rule type explicitly marks it as unsupported.  `tools`: The tool applied to the action will be the first tool with a feature set that matches the feature configuration. An error will be thrown if no tool matches a provided feature configuration - for that reason, it's a good idea to provide a default tool with an empty feature set.  `flag_sets`: If the given action config is enabled, the flag sets will be applied to the corresponding action.  `implies`: A list of features or action configs that are automatically enabled when this action config is enabled. If any of the implied features or action configs cannot be enabled, this action config will (silently) not be enabled either. |
+| `artifact_name_patterns` | [sequence](/versions/8.2.1/rules/lib/core/list); default is `[]`  The name for an artifact of a given category of input or output artifacts to an action. Arguments:  `category_name`: The category of artifacts that this selection applies to. This field is compared against a list of categories defined in Bazel. Example categories include "linked\_output" or the artifact for this selection. Together with the extension it is used to create an artifact name based on the target name.  `extension`: The extension for creating the artifact for this selection. Together with the prefix it is used to create an artifact name based on the target name. |
+| `cxx_builtin_include_directories` | [sequence](/versions/8.2.1/rules/lib/core/list); default is `[]`  Built-in include directories for C++ compilation. These should be the exact paths used by the compiler, and are generally relative to the exec root.  The paths used by the compiler can be determined by 'gcc -E -xc++ - -v'.  We currently use the C++ paths also for C compilation, which is safe as long as there are no name clashes between C++ and C header files.  Relative paths are resolved relative to the configuration file directory.  If the compiler has --sysroot support, then these paths should use %sysroot% rather than the include path, and specify the sysroot attribute in order to give blaze the information necessary to make the correct replacements. |
+| `toolchain_identifier` | [string](/versions/8.2.1/rules/lib/core/string); required  The unique identifier of the toolchain within the crosstool release. It must be possible to use this as a directory name in a path.  It has to match the following regex: [a-zA-Z\_][\.\- \w]\* |
+| `host_system_name` | [string](/versions/8.2.1/rules/lib/core/string); or `None`; default is `None`  Ignored. |
+| `target_system_name` | [string](/versions/8.2.1/rules/lib/core/string); or `None`; default is `None`  Deprecated. The GNU System Name. The string is exposed to CcToolchainInfo.target\_gnu\_system\_name. |
+| `target_cpu` | [string](/versions/8.2.1/rules/lib/core/string); or `None`; default is `None`  Deprecated: Use cpu based constraints instead. If the string is "k8", `target\_cpu` will be omitted from the filename of raw FDO profile data. |
+| `target_libc` | [string](/versions/8.2.1/rules/lib/core/string); or `None`; default is `None`  Deprecated: Use OS based constraints instead. The libc version string (e.g. "glibc-2.2.2"). If the string is "macosx", platform is assumed to be MacOS. Otherwise, Linux. The string is exposed to CcToolchainInfo.libc. |
+| `compiler` | [string](/versions/8.2.1/rules/lib/core/string); required  The compiler string (e.g. "gcc"). The current toolchain's compiler is exposed to `@bazel\_tools//tools/cpp:compiler (compiler\_flag)` as a flag value. Targets that require compiler-specific flags can use the config\_settings in https://github.com/bazelbuild/rules\_cc/blob/main/cc/compiler/BUILD in select() statements or create custom config\_setting if the existing settings don't suffice. |
+| `abi_version` | [string](/versions/8.2.1/rules/lib/core/string); or `None`; default is `None`  The abi in use, which is a gcc version. E.g.: "gcc-3.4". The string is set to C++ toolchain variable ABI. |
+| `abi_libc_version` | [string](/versions/8.2.1/rules/lib/core/string); or `None`; default is `None`  The glibc version used by the abi we're using. The string is set to C++ toolchain variable ABI\_LIBC\_VERSION. |
+| `tool_paths` | [sequence](/versions/8.2.1/rules/lib/core/list); default is `[]`  Tool locations. Arguments:  `name`: Name of the tool.  `path`: Location of the tool; Can be absolute path (in case of non hermetic toolchain), or path relative to the cc\_toolchain's package. |
+| `make_variables` | [sequence](/versions/8.2.1/rules/lib/core/list); default is `[]`  A make variable that is made accessible to rules. |
+| `builtin_sysroot` | [string](/versions/8.2.1/rules/lib/core/string); or `None`; default is `None`  The built-in sysroot. If this attribute is not present, Bazel does not allow using a different sysroot, i.e. through the --grte\_top option. |
 
 ## create\_compilation\_context
 
@@ -168,8 +168,8 @@ Create compilation outputs object.
 
 | Parameter | Description |
 | --- | --- |
-| `objects` | [depset](../builtins/depset); or `None`; default is `None`  List of object files. |
-| `pic_objects` | [depset](../builtins/depset); or `None`; default is `None`  List of pic object files. |
+| `objects` | [depset](/versions/8.2.1/rules/lib/builtins/depset); or `None`; default is `None`  List of object files. |
+| `pic_objects` | [depset](/versions/8.2.1/rules/lib/builtins/depset); or `None`; default is `None`  List of pic object files. |
 
 ## create\_compile\_variables
 
@@ -184,21 +184,21 @@ Returns variables used for compilation actions.
 | Parameter | Description |
 | --- | --- |
 | `cc_toolchain` | Info; required  cc\_toolchain for which we are creating build variables. |
-| `feature_configuration` | [FeatureConfiguration](../builtins/FeatureConfiguration); required  Feature configuration to be queried. |
+| `feature_configuration` | [FeatureConfiguration](/versions/8.2.1/rules/lib/builtins/FeatureConfiguration); required  Feature configuration to be queried. |
 | `source_file` | default is `None`  Optional source file for the compilation. Please prefer passing source\_file here over appending it to the end of the command line generated from cc\_common.get\_memory\_inefficient\_command\_line, as then it's in the power of the toolchain author to properly specify and position compiler flags. |
 | `output_file` | default is `None`  Optional output file of the compilation. Please prefer passing output\_file here over appending it to the end of the command line generated from cc\_common.get\_memory\_inefficient\_command\_line, as then it's in the power of the toolchain author to properly specify and position compiler flags. |
-| `user_compile_flags` | [sequence](../core/list) of [string](../core/string)s; or `None`; default is `None`  List of additional compilation flags (copts). |
-| `include_directories` | [depset](../builtins/depset); or `None`; default is `None`  Depset of include directories. |
-| `quote_include_directories` | [depset](../builtins/depset); or `None`; default is `None`  Depset of quote include directories. |
-| `system_include_directories` | [depset](../builtins/depset); or `None`; default is `None`  Depset of system include directories. |
-| `framework_include_directories` | [depset](../builtins/depset); or `None`; default is `None`  Depset of framework include directories. |
-| `preprocessor_defines` | [depset](../builtins/depset); or `None`; default is `None`  Depset of preprocessor defines. |
-| `thinlto_index` | [string](../core/string); or `None`; default is `None`  LTO index file path. |
-| `thinlto_input_bitcode_file` | [string](../core/string); or `None`; default is `None`  Bitcode file that is input to LTO backend. |
-| `thinlto_output_object_file` | [string](../core/string); or `None`; default is `None`  Object file that is output by LTO backend. |
-| `use_pic` | [bool](../core/bool); default is `False`  When true the compilation will generate position independent code. |
-| `add_legacy_cxx_options` | [bool](../core/bool); default is `False`  Unused. |
-| `variables_extension` | [dict](../core/dict); default is `unbound`  A dictionary of additional variables used by compile actions. |
+| `user_compile_flags` | [sequence](/versions/8.2.1/rules/lib/core/list) of [string](/versions/8.2.1/rules/lib/core/string)s; or `None`; default is `None`  List of additional compilation flags (copts). |
+| `include_directories` | [depset](/versions/8.2.1/rules/lib/builtins/depset); or `None`; default is `None`  Depset of include directories. |
+| `quote_include_directories` | [depset](/versions/8.2.1/rules/lib/builtins/depset); or `None`; default is `None`  Depset of quote include directories. |
+| `system_include_directories` | [depset](/versions/8.2.1/rules/lib/builtins/depset); or `None`; default is `None`  Depset of system include directories. |
+| `framework_include_directories` | [depset](/versions/8.2.1/rules/lib/builtins/depset); or `None`; default is `None`  Depset of framework include directories. |
+| `preprocessor_defines` | [depset](/versions/8.2.1/rules/lib/builtins/depset); or `None`; default is `None`  Depset of preprocessor defines. |
+| `thinlto_index` | [string](/versions/8.2.1/rules/lib/core/string); or `None`; default is `None`  LTO index file path. |
+| `thinlto_input_bitcode_file` | [string](/versions/8.2.1/rules/lib/core/string); or `None`; default is `None`  Bitcode file that is input to LTO backend. |
+| `thinlto_output_object_file` | [string](/versions/8.2.1/rules/lib/core/string); or `None`; default is `None`  Object file that is output by LTO backend. |
+| `use_pic` | [bool](/versions/8.2.1/rules/lib/core/bool); default is `False`  When true the compilation will generate position independent code. |
+| `add_legacy_cxx_options` | [bool](/versions/8.2.1/rules/lib/core/bool); default is `False`  Unused. |
+| `variables_extension` | [dict](/versions/8.2.1/rules/lib/core/dict); default is `unbound`  A dictionary of additional variables used by compile actions. |
 
 ## create\_library\_to\_link
 
@@ -215,15 +215,15 @@ Creates `LibraryToLink`
 | `actions` | required  `actions` object. |
 | `feature_configuration` | default is `None`  `feature_configuration` to be queried. |
 | `cc_toolchain` | default is `None`  `CcToolchainInfo` provider to be used. |
-| `static_library` | [File](../builtins/File); or `None`; default is `None`  `File` of static library to be linked. |
-| `pic_static_library` | [File](../builtins/File); or `None`; default is `None`  `File` of pic static library to be linked. |
-| `dynamic_library` | [File](../builtins/File); or `None`; default is `None`  `File` of dynamic library to be linked. Always used for runtime and used for linking if `interface_library` is not passed. |
-| `interface_library` | [File](../builtins/File); or `None`; default is `None`  `File` of interface library to be linked. |
-| `pic_objects` | [sequence](../core/list) of [File](../builtins/File)s; default is `unbound`  Experimental, do not use |
-| `objects` | [sequence](../core/list) of [File](../builtins/File)s; default is `unbound`  Experimental, do not use |
-| `alwayslink` | [bool](../core/bool); default is `False`  Whether to link the static library/objects in the --whole\_archive block. |
-| `dynamic_library_symlink_path` | [string](../core/string); default is `''`  Override the default path of the dynamic library link in the solib directory. Empty string to use the default. |
-| `interface_library_symlink_path` | [string](../core/string); default is `''`  Override the default path of the interface library link in the solib directory. Empty string to use the default. |
+| `static_library` | [File](/versions/8.2.1/rules/lib/builtins/File); or `None`; default is `None`  `File` of static library to be linked. |
+| `pic_static_library` | [File](/versions/8.2.1/rules/lib/builtins/File); or `None`; default is `None`  `File` of pic static library to be linked. |
+| `dynamic_library` | [File](/versions/8.2.1/rules/lib/builtins/File); or `None`; default is `None`  `File` of dynamic library to be linked. Always used for runtime and used for linking if `interface_library` is not passed. |
+| `interface_library` | [File](/versions/8.2.1/rules/lib/builtins/File); or `None`; default is `None`  `File` of interface library to be linked. |
+| `pic_objects` | [sequence](/versions/8.2.1/rules/lib/core/list) of [File](/versions/8.2.1/rules/lib/builtins/File)s; default is `unbound`  Experimental, do not use |
+| `objects` | [sequence](/versions/8.2.1/rules/lib/core/list) of [File](/versions/8.2.1/rules/lib/builtins/File)s; default is `unbound`  Experimental, do not use |
+| `alwayslink` | [bool](/versions/8.2.1/rules/lib/core/bool); default is `False`  Whether to link the static library/objects in the --whole\_archive block. |
+| `dynamic_library_symlink_path` | [string](/versions/8.2.1/rules/lib/core/string); default is `''`  Override the default path of the dynamic library link in the solib directory. Empty string to use the default. |
+| `interface_library_symlink_path` | [string](/versions/8.2.1/rules/lib/core/string); default is `''`  Override the default path of the interface library link in the solib directory. Empty string to use the default. |
 
 ## create\_link\_variables
 
@@ -238,17 +238,17 @@ Returns link variables used for linking actions.
 | Parameter | Description |
 | --- | --- |
 | `cc_toolchain` | Info; required  cc\_toolchain for which we are creating build variables. |
-| `feature_configuration` | [FeatureConfiguration](../builtins/FeatureConfiguration); required  Feature configuration to be queried. |
-| `library_search_directories` | [depset](../builtins/depset); default is `[]`  Depset of directories where linker will look for libraries at link time. |
-| `runtime_library_search_directories` | [depset](../builtins/depset); default is `[]`  Depset of directories where loader will look for libraries at runtime. |
-| `user_link_flags` | [sequence](../core/list); default is `[]`  List of additional link flags (linkopts). |
+| `feature_configuration` | [FeatureConfiguration](/versions/8.2.1/rules/lib/builtins/FeatureConfiguration); required  Feature configuration to be queried. |
+| `library_search_directories` | [depset](/versions/8.2.1/rules/lib/builtins/depset); default is `[]`  Depset of directories where linker will look for libraries at link time. |
+| `runtime_library_search_directories` | [depset](/versions/8.2.1/rules/lib/builtins/depset); default is `[]`  Depset of directories where loader will look for libraries at runtime. |
+| `user_link_flags` | [sequence](/versions/8.2.1/rules/lib/core/list); default is `[]`  List of additional link flags (linkopts). |
 | `output_file` | default is `None`  Optional output file path. |
 | `param_file` | default is `None`  Optional param file path. |
-| `is_using_linker` | [bool](../core/bool); default is `True`  True when using linker, False when archiver. Caller is responsible for keeping this in sync with action name used (is\_using\_linker = True for linking executable or dynamic library, is\_using\_linker = False for archiving static library). |
-| `is_linking_dynamic_library` | [bool](../core/bool); default is `False`  True when creating dynamic library, False when executable or static library. Caller is responsible for keeping this in sync with action name used. This field will be removed once b/65151735 is fixed. |
-| `must_keep_debug` | [bool](../core/bool); default is `True`  When set to False, bazel will expose 'strip\_debug\_symbols' variable, which is usually used to use the linker to strip debug symbols from the output file. |
-| `use_test_only_flags` | [bool](../core/bool); default is `False`  When set to true, 'is\_cc\_test' variable will be set. |
-| `is_static_linking_mode` | [bool](../core/bool); default is `True`  Unused. |
+| `is_using_linker` | [bool](/versions/8.2.1/rules/lib/core/bool); default is `True`  True when using linker, False when archiver. Caller is responsible for keeping this in sync with action name used (is\_using\_linker = True for linking executable or dynamic library, is\_using\_linker = False for archiving static library). |
+| `is_linking_dynamic_library` | [bool](/versions/8.2.1/rules/lib/core/bool); default is `False`  True when creating dynamic library, False when executable or static library. Caller is responsible for keeping this in sync with action name used. This field will be removed once b/65151735 is fixed. |
+| `must_keep_debug` | [bool](/versions/8.2.1/rules/lib/core/bool); default is `True`  When set to False, bazel will expose 'strip\_debug\_symbols' variable, which is usually used to use the linker to strip debug symbols from the output file. |
+| `use_test_only_flags` | [bool](/versions/8.2.1/rules/lib/core/bool); default is `False`  When set to true, 'is\_cc\_test' variable will be set. |
+| `is_static_linking_mode` | [bool](/versions/8.2.1/rules/lib/core/bool); default is `True`  Unused. |
 
 ## create\_linker\_input
 
@@ -262,10 +262,10 @@ Creates a `LinkerInput`.
 
 | Parameter | Description |
 | --- | --- |
-| `owner` | [Label](../builtins/Label); required  The label of the target that produced all files used in this input. |
-| `libraries` | `None`; or [depset](../builtins/depset); default is `None`  List of `LibraryToLink`. |
-| `user_link_flags` | `None`; or [depset](../builtins/depset) of [string](../core/string)s; or [sequence](../core/list) of [string](../core/string)s; default is `None`  User link flags passed as strings. Accepts either [String], [[String]] or depset(String). The latter is discouraged as it's only kept for compatibility purposes, the depset is flattened. If you want to propagate user\_link\_flags via unflattened depsets() wrap them in a LinkerInput so that they are not flattened till the end. |
-| `additional_inputs` | `None`; or [depset](../builtins/depset); default is `None`  For additional inputs to the linking action, e.g.: linking scripts. |
+| `owner` | [Label](/versions/8.2.1/rules/lib/builtins/Label); required  The label of the target that produced all files used in this input. |
+| `libraries` | `None`; or [depset](/versions/8.2.1/rules/lib/builtins/depset); default is `None`  List of `LibraryToLink`. |
+| `user_link_flags` | `None`; or [depset](/versions/8.2.1/rules/lib/builtins/depset) of [string](/versions/8.2.1/rules/lib/core/string)s; or [sequence](/versions/8.2.1/rules/lib/core/list) of [string](/versions/8.2.1/rules/lib/core/string)s; default is `None`  User link flags passed as strings. Accepts either [String], [[String]] or depset(String). The latter is discouraged as it's only kept for compatibility purposes, the depset is flattened. If you want to propagate user\_link\_flags via unflattened depsets() wrap them in a LinkerInput so that they are not flattened till the end. |
+| `additional_inputs` | `None`; or [depset](/versions/8.2.1/rules/lib/builtins/depset); default is `None`  For additional inputs to the linking action, e.g.: linking scripts. |
 
 ## create\_linking\_context
 
@@ -279,10 +279,10 @@ Creates a `LinkingContext`.
 
 | Parameter | Description |
 | --- | --- |
-| `linker_inputs` | `None`; or [depset](../builtins/depset); default is `None`  Depset of `LinkerInput`. |
-| `libraries_to_link` | `None`; or [sequence](../core/list); default is `None`  **Deprecated**. This parameter is deprecated and will be removed soon. Please do not depend on it. It is *disabled* with `--incompatible_require_linker_input_cc_api`. Use this flag to verify your code is compatible with its imminent removal.  List of `LibraryToLink`. |
-| `user_link_flags` | `None`; or [sequence](../core/list); default is `None` |
-| `additional_inputs` | `None`; or [sequence](../core/list); default is `None` |
+| `linker_inputs` | `None`; or [depset](/versions/8.2.1/rules/lib/builtins/depset); default is `None`  Depset of `LinkerInput`. |
+| `libraries_to_link` | `None`; or [sequence](/versions/8.2.1/rules/lib/core/list); default is `None`  **Deprecated**. This parameter is deprecated and will be removed soon. Please do not depend on it. It is *disabled* with `--incompatible_require_linker_input_cc_api`. Use this flag to verify your code is compatible with its imminent removal.  List of `LibraryToLink`. |
+| `user_link_flags` | `None`; or [sequence](/versions/8.2.1/rules/lib/core/list); default is `None` |
+| `additional_inputs` | `None`; or [sequence](/versions/8.2.1/rules/lib/core/list); default is `None` |
 
 ## create\_linking\_context\_from\_compilation\_outputs
 
@@ -296,19 +296,19 @@ Should be used for creating library rules that can propagate information downstr
 
 | Parameter | Description |
 | --- | --- |
-| `actions` | [actions](../builtins/actions); required |
-| `name` | [string](../core/string); required  This is used for naming the output artifacts of actions created by this method. |
-| `feature_configuration` | [FeatureConfiguration](../builtins/FeatureConfiguration); required  `feature_configuration` to be queried. |
+| `actions` | [actions](/versions/8.2.1/rules/lib/builtins/actions); required |
+| `name` | [string](/versions/8.2.1/rules/lib/core/string); required  This is used for naming the output artifacts of actions created by this method. |
+| `feature_configuration` | [FeatureConfiguration](/versions/8.2.1/rules/lib/builtins/FeatureConfiguration); required  `feature_configuration` to be queried. |
 | `cc_toolchain` | Info; required  `CcToolchainInfo` provider to be used. |
-| `language` | [string](../core/string); default is `'c++'`  Only C++ supported for now. Do not use this parameter. |
-| `disallow_static_libraries` | [bool](../core/bool); default is `False`  Whether static libraries should be created. |
-| `disallow_dynamic_library` | [bool](../core/bool); default is `False`  Whether a dynamic library should be created. |
-| `compilation_outputs` | [CcCompilationOutputs](../builtins/CcCompilationOutputs); required  Compilation outputs containing object files to link. |
-| `linking_contexts` | [sequence](../core/list); default is `[]`  Libraries from dependencies. These libraries will be linked into the output artifact of the link() call, be it a binary or a library. |
-| `user_link_flags` | [sequence](../core/list); default is `[]`  Additional list of linking options. |
-| `alwayslink` | [bool](../core/bool); default is `False`  Whether this library should always be linked. |
-| `additional_inputs` | [sequence](../core/list); default is `[]`  For additional inputs to the linking action, e.g.: linking scripts. |
-| `variables_extension` | [dict](../core/dict); default is `unbound`  Additional variables to pass to the toolchain configuration when creating link command line. |
+| `language` | [string](/versions/8.2.1/rules/lib/core/string); default is `'c++'`  Only C++ supported for now. Do not use this parameter. |
+| `disallow_static_libraries` | [bool](/versions/8.2.1/rules/lib/core/bool); default is `False`  Whether static libraries should be created. |
+| `disallow_dynamic_library` | [bool](/versions/8.2.1/rules/lib/core/bool); default is `False`  Whether a dynamic library should be created. |
+| `compilation_outputs` | [CcCompilationOutputs](/versions/8.2.1/rules/lib/builtins/CcCompilationOutputs); required  Compilation outputs containing object files to link. |
+| `linking_contexts` | [sequence](/versions/8.2.1/rules/lib/core/list); default is `[]`  Libraries from dependencies. These libraries will be linked into the output artifact of the link() call, be it a binary or a library. |
+| `user_link_flags` | [sequence](/versions/8.2.1/rules/lib/core/list); default is `[]`  Additional list of linking options. |
+| `alwayslink` | [bool](/versions/8.2.1/rules/lib/core/bool); default is `False`  Whether this library should always be linked. |
+| `additional_inputs` | [sequence](/versions/8.2.1/rules/lib/core/list); default is `[]`  For additional inputs to the linking action, e.g.: linking scripts. |
+| `variables_extension` | [dict](/versions/8.2.1/rules/lib/core/dict); default is `unbound`  Additional variables to pass to the toolchain configuration when creating link command line. |
 
 ## create\_lto\_compilation\_context
 
@@ -322,7 +322,7 @@ Create LTO compilation context
 
 | Parameter | Description |
 | --- | --- |
-| `objects` | [dict](../core/dict); default is `{}`  map of full object to index object |
+| `objects` | [dict](/versions/8.2.1/rules/lib/core/dict); default is `{}`  map of full object to index object |
 
 ## do\_not\_use\_tools\_cpp\_compiler\_present
 
@@ -344,8 +344,8 @@ Returns environment variables to be set for given action.
 
 | Parameter | Description |
 | --- | --- |
-| `feature_configuration` | [FeatureConfiguration](../builtins/FeatureConfiguration); required  Feature configuration to be queried. |
-| `action_name` | [string](../core/string); required  Name of the action. Has to be one of the names in @bazel\_tools//tools/build\_defs/cc:action\_names.bzl (https://github.com/bazelbuild/bazel/blob/master/tools/build\_defs/cc/action\_names.bzl) |
+| `feature_configuration` | [FeatureConfiguration](/versions/8.2.1/rules/lib/builtins/FeatureConfiguration); required  Feature configuration to be queried. |
+| `action_name` | [string](/versions/8.2.1/rules/lib/core/string); required  Name of the action. Has to be one of the names in @bazel\_tools//tools/build\_defs/cc:action\_names.bzl (https://github.com/bazelbuild/bazel/blob/master/tools/build\_defs/cc/action\_names.bzl) |
 | `variables` | Variables; required  Build variables to be used for template expansion. |
 
 ## get\_execution\_requirements
@@ -360,8 +360,8 @@ Returns execution requirements for given action.
 
 | Parameter | Description |
 | --- | --- |
-| `feature_configuration` | [FeatureConfiguration](../builtins/FeatureConfiguration); required  Feature configuration to be queried. |
-| `action_name` | [string](../core/string); required  Name of the action. Has to be one of the names in @bazel\_tools//tools/build\_defs/cc:action\_names.bzl (https://github.com/bazelbuild/bazel/blob/master/tools/build\_defs/cc/action\_names.bzl) |
+| `feature_configuration` | [FeatureConfiguration](/versions/8.2.1/rules/lib/builtins/FeatureConfiguration); required  Feature configuration to be queried. |
+| `action_name` | [string](/versions/8.2.1/rules/lib/core/string); required  Name of the action. Has to be one of the names in @bazel\_tools//tools/build\_defs/cc:action\_names.bzl (https://github.com/bazelbuild/bazel/blob/master/tools/build\_defs/cc/action\_names.bzl) |
 
 ## get\_memory\_inefficient\_command\_line
 
@@ -375,8 +375,8 @@ Returns flattened command line flags for given action, using given variables for
 
 | Parameter | Description |
 | --- | --- |
-| `feature_configuration` | [FeatureConfiguration](../builtins/FeatureConfiguration); required  Feature configuration to be queried. |
-| `action_name` | [string](../core/string); required  Name of the action. Has to be one of the names in @bazel\_tools//tools/build\_defs/cc:action\_names.bzl (https://github.com/bazelbuild/bazel/blob/master/tools/build\_defs/cc/action\_names.bzl) |
+| `feature_configuration` | [FeatureConfiguration](/versions/8.2.1/rules/lib/builtins/FeatureConfiguration); required  Feature configuration to be queried. |
+| `action_name` | [string](/versions/8.2.1/rules/lib/core/string); required  Name of the action. Has to be one of the names in @bazel\_tools//tools/build\_defs/cc:action\_names.bzl (https://github.com/bazelbuild/bazel/blob/master/tools/build\_defs/cc/action\_names.bzl) |
 | `variables` | Variables; required  Build variables to be used for template expansions. |
 
 ## get\_tool\_for\_action
@@ -391,8 +391,8 @@ Returns tool path for given action.
 
 | Parameter | Description |
 | --- | --- |
-| `feature_configuration` | [FeatureConfiguration](../builtins/FeatureConfiguration); required  Feature configuration to be queried. |
-| `action_name` | [string](../core/string); required  Name of the action. Has to be one of the names in @bazel\_tools//tools/build\_defs/cc:action\_names.bzl (https://github.com/bazelbuild/bazel/blob/master/tools/build\_defs/cc/action\_names.bzl) |
+| `feature_configuration` | [FeatureConfiguration](/versions/8.2.1/rules/lib/builtins/FeatureConfiguration); required  Feature configuration to be queried. |
+| `action_name` | [string](/versions/8.2.1/rules/lib/core/string); required  Name of the action. Has to be one of the names in @bazel\_tools//tools/build\_defs/cc:action\_names.bzl (https://github.com/bazelbuild/bazel/blob/master/tools/build\_defs/cc/action\_names.bzl) |
 
 ## is\_enabled
 
@@ -406,8 +406,8 @@ Returns True if given feature is enabled in the feature configuration.
 
 | Parameter | Description |
 | --- | --- |
-| `feature_configuration` | [FeatureConfiguration](../builtins/FeatureConfiguration); required  Feature configuration to be queried. |
-| `feature_name` | [string](../core/string); required  Name of the feature. |
+| `feature_configuration` | [FeatureConfiguration](/versions/8.2.1/rules/lib/builtins/FeatureConfiguration); required  Feature configuration to be queried. |
+| `feature_name` | [string](/versions/8.2.1/rules/lib/core/string); required  Name of the feature. |
 
 ## link
 
@@ -421,20 +421,20 @@ Should be used for C++ transitive linking.
 
 | Parameter | Description |
 | --- | --- |
-| `actions` | [actions](../builtins/actions); required  `actions` object. |
-| `name` | [string](../core/string); required  This is used for naming the output artifacts of actions created by this method. |
-| `feature_configuration` | [FeatureConfiguration](../builtins/FeatureConfiguration); required  `feature_configuration` to be queried. |
+| `actions` | [actions](/versions/8.2.1/rules/lib/builtins/actions); required  `actions` object. |
+| `name` | [string](/versions/8.2.1/rules/lib/core/string); required  This is used for naming the output artifacts of actions created by this method. |
+| `feature_configuration` | [FeatureConfiguration](/versions/8.2.1/rules/lib/builtins/FeatureConfiguration); required  `feature_configuration` to be queried. |
 | `cc_toolchain` | Info; required  `CcToolchainInfo` provider to be used. |
-| `language` | [string](../core/string); default is `'c++'`  Only C++ supported for now. Do not use this parameter. |
-| `output_type` | [string](../core/string); default is `'executable'`  Can be either 'executable' or 'dynamic\_library'. |
-| `link_deps_statically` | [bool](../core/bool); default is `True`  True to link dependencies statically, False dynamically. |
-| `compilation_outputs` | [CcCompilationOutputs](../builtins/CcCompilationOutputs); or `None`; default is `None`  Compilation outputs containing object files to link. |
-| `linking_contexts` | [sequence](../core/list); default is `[]`  Linking contexts from dependencies to be linked into the linking context generated by this rule. |
-| `user_link_flags` | [sequence](../core/list); default is `[]`  Additional list of linker options. |
-| `stamp` | [int](../core/int); default is `0`  Whether to include build information in the linked executable, if output\_type is 'executable'. If 1, build information is always included. If 0 (the default build information is always excluded. If -1, uses the default behavior, which may be overridden by the --[no]stamp flag. This should be unset (or set to 0) when generating the executable output for test rules. |
-| `additional_inputs` | [sequence](../core/list); or [depset](../builtins/depset); default is `[]`  For additional inputs to the linking action, e.g.: linking scripts. |
-| `additional_outputs` | [sequence](../core/list); default is `[]`  For additional outputs to the linking action, e.g.: map files. |
-| `variables_extension` | [dict](../core/dict); default is `{}`  Additional variables to pass to the toolchain configuration when create link command line. |
+| `language` | [string](/versions/8.2.1/rules/lib/core/string); default is `'c++'`  Only C++ supported for now. Do not use this parameter. |
+| `output_type` | [string](/versions/8.2.1/rules/lib/core/string); default is `'executable'`  Can be either 'executable' or 'dynamic\_library'. |
+| `link_deps_statically` | [bool](/versions/8.2.1/rules/lib/core/bool); default is `True`  True to link dependencies statically, False dynamically. |
+| `compilation_outputs` | [CcCompilationOutputs](/versions/8.2.1/rules/lib/builtins/CcCompilationOutputs); or `None`; default is `None`  Compilation outputs containing object files to link. |
+| `linking_contexts` | [sequence](/versions/8.2.1/rules/lib/core/list); default is `[]`  Linking contexts from dependencies to be linked into the linking context generated by this rule. |
+| `user_link_flags` | [sequence](/versions/8.2.1/rules/lib/core/list); default is `[]`  Additional list of linker options. |
+| `stamp` | [int](/versions/8.2.1/rules/lib/core/int); default is `0`  Whether to include build information in the linked executable, if output\_type is 'executable'. If 1, build information is always included. If 0 (the default build information is always excluded. If -1, uses the default behavior, which may be overridden by the --[no]stamp flag. This should be unset (or set to 0) when generating the executable output for test rules. |
+| `additional_inputs` | [sequence](/versions/8.2.1/rules/lib/core/list); or [depset](/versions/8.2.1/rules/lib/builtins/depset); default is `[]`  For additional inputs to the linking action, e.g.: linking scripts. |
+| `additional_outputs` | [sequence](/versions/8.2.1/rules/lib/core/list); default is `[]`  For additional outputs to the linking action, e.g.: map files. |
+| `variables_extension` | [dict](/versions/8.2.1/rules/lib/core/dict); default is `{}`  Additional variables to pass to the toolchain configuration when create link command line. |
 
 ## merge\_compilation\_contexts
 
@@ -448,7 +448,7 @@ Merges multiple `CompilationContexts`s into one.
 
 | Parameter | Description |
 | --- | --- |
-| `compilation_contexts` | [sequence](../core/list); default is `[]`  List of `CompilationContexts`s to be merged. The headers of each context will be exported by the direct fields in the returned provider. |
+| `compilation_contexts` | [sequence](/versions/8.2.1/rules/lib/core/list); default is `[]`  List of `CompilationContexts`s to be merged. The headers of each context will be exported by the direct fields in the returned provider. |
 
 ## merge\_compilation\_outputs
 
@@ -462,4 +462,4 @@ Merge compilation outputs.
 
 | Parameter | Description |
 | --- | --- |
-| `compilation_outputs` | [sequence](../core/list); default is `[]` |
\ No newline at end of file
+| `compilation_outputs` | [sequence](/versions/8.2.1/rules/lib/core/list); default is `[]` |
\ No newline at end of file
diff --git a/versions/8.2.1/rules/lib/toplevel/config.mdx b/versions/8.2.1/rules/lib/toplevel/config.mdx
index 4b60c243..f2331b2f 100644
--- a/versions/8.2.1/rules/lib/toplevel/config.mdx
+++ b/versions/8.2.1/rules/lib/toplevel/config.mdx
@@ -36,7 +36,7 @@ A bool-typed build setting
 
 | Parameter | Description |
 | --- | --- |
-| `flag` | [bool](../core/bool); default is `False` |
+| `flag` | [bool](/versions/8.2.1/rules/lib/core/bool); default is `False` |
 
 ## exec
 
@@ -50,7 +50,7 @@ Creates an execution transition.
 
 | Parameter | Description |
 | --- | --- |
-| `exec_group` | [string](../core/string); or `None`; default is `None`  The name of the exec group whose execution platform this transition will use. If not provided, this exec transition will use the target's default execution platform. |
+| `exec_group` | [string](/versions/8.2.1/rules/lib/core/string); or `None`; default is `None`  The name of the exec group whose execution platform this transition will use. If not provided, this exec transition will use the target's default execution platform. |
 
 ## int
 
@@ -64,7 +64,7 @@ An integer-typed build setting
 
 | Parameter | Description |
 | --- | --- |
-| `flag` | [bool](../core/bool); default is `False`  Whether or not this build setting is callable on the command line. |
+| `flag` | [bool](/versions/8.2.1/rules/lib/core/bool); default is `False`  Whether or not this build setting is callable on the command line. |
 
 ## none
 
@@ -86,8 +86,8 @@ A string-typed build setting
 
 | Parameter | Description |
 | --- | --- |
-| `flag` | [bool](../core/bool); default is `False`  Whether or not this build setting is callable on the command line. |
-| `allow_multiple` | [bool](../core/bool); default is `False`  Deprecated, use a `string_list` setting with `repeatable = True` instead. If set, this flag is allowed to be set multiple times on the command line. The Value of the flag as accessed in transitions and build setting implementation function will be a list of strings. Insertion order and repeated values are both maintained. This list can be post-processed in the build setting implementation function if different behavior is desired. |
+| `flag` | [bool](/versions/8.2.1/rules/lib/core/bool); default is `False`  Whether or not this build setting is callable on the command line. |
+| `allow_multiple` | [bool](/versions/8.2.1/rules/lib/core/bool); default is `False`  Deprecated, use a `string_list` setting with `repeatable = True` instead. If set, this flag is allowed to be set multiple times on the command line. The Value of the flag as accessed in transitions and build setting implementation function will be a list of strings. Insertion order and repeated values are both maintained. This list can be post-processed in the build setting implementation function if different behavior is desired. |
 
 ## string\_list
 
@@ -101,8 +101,8 @@ A string list-typed build setting. On the command line pass a list using comma-s
 
 | Parameter | Description |
 | --- | --- |
-| `flag` | [bool](../core/bool); default is `False`  Whether or not this build setting is callable on the command line. |
-| `repeatable` | [bool](../core/bool); default is `False`  If set, instead of expecting a comma-separated value, this flag is allowed to be set multiple times on the command line with each individual value treated as a single string to add to the list value. Insertion order and repeated values are both maintained. This list can be post-processed in the build setting implementation function if different behavior is desired. |
+| `flag` | [bool](/versions/8.2.1/rules/lib/core/bool); default is `False`  Whether or not this build setting is callable on the command line. |
+| `repeatable` | [bool](/versions/8.2.1/rules/lib/core/bool); default is `False`  If set, instead of expecting a comma-separated value, this flag is allowed to be set multiple times on the command line with each individual value treated as a single string to add to the list value. Insertion order and repeated values are both maintained. This list can be post-processed in the build setting implementation function if different behavior is desired. |
 
 ## target
 
diff --git a/versions/8.2.1/rules/lib/toplevel/config_common.mdx b/versions/8.2.1/rules/lib/toplevel/config_common.mdx
index 9169b17a..f47f6d7c 100644
--- a/versions/8.2.1/rules/lib/toplevel/config_common.mdx
+++ b/versions/8.2.1/rules/lib/toplevel/config_common.mdx
@@ -29,5 +29,5 @@ Declare a rule's dependency on a toolchain type.
 
 | Parameter | Description |
 | --- | --- |
-| `name` | [string](../core/string); or [Label](../builtins/Label); required  The toolchain type that is required. |
-| `mandatory` | [bool](../core/bool); default is `True`  Whether the toolchain type is mandatory or optional. |
\ No newline at end of file
+| `name` | [string](/versions/8.2.1/rules/lib/core/string); or [Label](/versions/8.2.1/rules/lib/builtins/Label); required  The toolchain type that is required. |
+| `mandatory` | [bool](/versions/8.2.1/rules/lib/core/bool); default is `True`  Whether the toolchain type is mandatory or optional. |
\ No newline at end of file
diff --git a/versions/8.2.1/rules/lib/toplevel/coverage_common.mdx b/versions/8.2.1/rules/lib/toplevel/coverage_common.mdx
index e93e1226..38f8b5fa 100644
--- a/versions/8.2.1/rules/lib/toplevel/coverage_common.mdx
+++ b/versions/8.2.1/rules/lib/toplevel/coverage_common.mdx
@@ -14,14 +14,14 @@ Helper functions to access coverage-related infrastructure.
 InstrumentedFilesInfo coverage_common.instrumented_files_info(ctx, *, source_attributes=[], dependency_attributes=[], extensions=None, metadata_files=[])
 ```
 
-Creates a new [InstrumentedFilesInfo](../providers/InstrumentedFilesInfo) instance. Use this provider to communicate coverage-related attributes of the current build rule.
+Creates a new [InstrumentedFilesInfo](/versions/8.2.1/rules/lib/providers/InstrumentedFilesInfo) instance. Use this provider to communicate coverage-related attributes of the current build rule.
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `ctx` | [ctx](../builtins/ctx); required  The rule context. |
-| `source_attributes` | [sequence](../core/list); default is `[]`  A list of attribute names which contain source files processed by this rule. |
-| `dependency_attributes` | [sequence](../core/list); default is `[]`  A list of attribute names which might provide runtime dependencies (either code dependencies or runfiles). |
-| `extensions` | [sequence](../core/list) of [string](../core/string)s; or `None`; default is `None`  File extensions used to filter files from source\_attributes. For example, 'js'. If not provided (or None), then all files from source\_attributes will be added to instrumented files, if an empty list is provided, then no files from source attributes will be added. |
-| `metadata_files` | [sequence](../core/list) of [File](../builtins/File)s; default is `[]`  Additional files required to generate coverage LCOV files after code execution. e.g. .gcno files for C++. |
\ No newline at end of file
+| `ctx` | [ctx](/versions/8.2.1/rules/lib/builtins/ctx); required  The rule context. |
+| `source_attributes` | [sequence](/versions/8.2.1/rules/lib/core/list); default is `[]`  A list of attribute names which contain source files processed by this rule. |
+| `dependency_attributes` | [sequence](/versions/8.2.1/rules/lib/core/list); default is `[]`  A list of attribute names which might provide runtime dependencies (either code dependencies or runfiles). |
+| `extensions` | [sequence](/versions/8.2.1/rules/lib/core/list) of [string](/versions/8.2.1/rules/lib/core/string)s; or `None`; default is `None`  File extensions used to filter files from source\_attributes. For example, 'js'. If not provided (or None), then all files from source\_attributes will be added to instrumented files, if an empty list is provided, then no files from source attributes will be added. |
+| `metadata_files` | [sequence](/versions/8.2.1/rules/lib/core/list) of [File](/versions/8.2.1/rules/lib/builtins/File)s; default is `[]`  Additional files required to generate coverage LCOV files after code execution. e.g. .gcno files for C++. |
\ No newline at end of file
diff --git a/versions/8.2.1/rules/lib/toplevel/java_common.mdx b/versions/8.2.1/rules/lib/toplevel/java_common.mdx
index 93be10d1..a5b2ee47 100644
--- a/versions/8.2.1/rules/lib/toplevel/java_common.mdx
+++ b/versions/8.2.1/rules/lib/toplevel/java_common.mdx
@@ -35,33 +35,33 @@ Compiles Java source files/jars from the implementation of a Starlark rule and r
 
 | Parameter | Description |
 | --- | --- |
-| `ctx` | [ctx](../builtins/ctx); required  The rule context. |
-| `source_jars` | [sequence](../core/list) of [File](../builtins/File)s; default is `[]`  A list of the jars to be compiled. At least one of source\_jars or source\_files should be specified. |
-| `source_files` | [sequence](../core/list) of [File](../builtins/File)s; default is `[]`  A list of the Java source files to be compiled. At least one of source\_jars or source\_files should be specified. |
-| `output` | [File](../builtins/File); required |
-| `output_source_jar` | [File](../builtins/File); or `None`; default is `None`  The output source jar. Defaults to `{output\_jar}-src.jar` if unset. |
-| `javac_opts` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  A list of the desired javac options. |
-| `deps` | [sequence](../core/list) of [struct](../builtins/struct)s; default is `[]`  A list of dependencies. |
-| `runtime_deps` | [sequence](../core/list) of [struct](../builtins/struct)s; default is `[]`  A list of runtime dependencies. |
-| `exports` | [sequence](../core/list) of [struct](../builtins/struct)s; default is `[]`  A list of exports. |
-| `plugins` | [sequence](../core/list) of [struct](../builtins/struct)s; or [sequence](../core/list) of [struct](../builtins/struct)s; default is `[]`  A list of plugins. |
-| `exported_plugins` | [sequence](../core/list) of [struct](../builtins/struct)s; or [sequence](../core/list) of [struct](../builtins/struct)s; default is `[]`  A list of exported plugins. |
-| `native_libraries` | [sequence](../core/list) of [CcInfo](../providers/CcInfo)s; default is `[]`  CC native library dependencies that are needed for this library. |
-| `annotation_processor_additional_inputs` | [sequence](../core/list) of [File](../builtins/File)s; default is `[]`  A list of inputs that the Java compilation action will take in addition to the Java sources for annotation processing. |
-| `annotation_processor_additional_outputs` | [sequence](../core/list) of [File](../builtins/File)s; default is `[]`  A list of outputs that the Java compilation action will output in addition to the class jar from annotation processing. |
-| `strict_deps` | [string](../core/string); default is `'ERROR'`  A string that specifies how to handle strict deps. Possible values: 'OFF', 'ERROR', 'WARN' and 'DEFAULT'. For more details see [`--strict_java_deps flag`](/versions/8.2.1/docs/user-manual#flag--strict_java_deps). By default 'ERROR'. |
+| `ctx` | [ctx](/versions/8.2.1/rules/lib/builtins/ctx); required  The rule context. |
+| `source_jars` | [sequence](/versions/8.2.1/rules/lib/core/list) of [File](/versions/8.2.1/rules/lib/builtins/File)s; default is `[]`  A list of the jars to be compiled. At least one of source\_jars or source\_files should be specified. |
+| `source_files` | [sequence](/versions/8.2.1/rules/lib/core/list) of [File](/versions/8.2.1/rules/lib/builtins/File)s; default is `[]`  A list of the Java source files to be compiled. At least one of source\_jars or source\_files should be specified. |
+| `output` | [File](/versions/8.2.1/rules/lib/builtins/File); required |
+| `output_source_jar` | [File](/versions/8.2.1/rules/lib/builtins/File); or `None`; default is `None`  The output source jar. Defaults to `{output\_jar}-src.jar` if unset. |
+| `javac_opts` | [sequence](/versions/8.2.1/rules/lib/core/list) of [string](/versions/8.2.1/rules/lib/core/string)s; default is `[]`  A list of the desired javac options. |
+| `deps` | [sequence](/versions/8.2.1/rules/lib/core/list) of [struct](/versions/8.2.1/rules/lib/builtins/struct)s; default is `[]`  A list of dependencies. |
+| `runtime_deps` | [sequence](/versions/8.2.1/rules/lib/core/list) of [struct](/versions/8.2.1/rules/lib/builtins/struct)s; default is `[]`  A list of runtime dependencies. |
+| `exports` | [sequence](/versions/8.2.1/rules/lib/core/list) of [struct](/versions/8.2.1/rules/lib/builtins/struct)s; default is `[]`  A list of exports. |
+| `plugins` | [sequence](/versions/8.2.1/rules/lib/core/list) of [struct](/versions/8.2.1/rules/lib/builtins/struct)s; or [sequence](/versions/8.2.1/rules/lib/core/list) of [struct](/versions/8.2.1/rules/lib/builtins/struct)s; default is `[]`  A list of plugins. |
+| `exported_plugins` | [sequence](/versions/8.2.1/rules/lib/core/list) of [struct](/versions/8.2.1/rules/lib/builtins/struct)s; or [sequence](/versions/8.2.1/rules/lib/core/list) of [struct](/versions/8.2.1/rules/lib/builtins/struct)s; default is `[]`  A list of exported plugins. |
+| `native_libraries` | [sequence](/versions/8.2.1/rules/lib/core/list) of [CcInfo](/versions/8.2.1/rules/lib/providers/CcInfo)s; default is `[]`  CC native library dependencies that are needed for this library. |
+| `annotation_processor_additional_inputs` | [sequence](/versions/8.2.1/rules/lib/core/list) of [File](/versions/8.2.1/rules/lib/builtins/File)s; default is `[]`  A list of inputs that the Java compilation action will take in addition to the Java sources for annotation processing. |
+| `annotation_processor_additional_outputs` | [sequence](/versions/8.2.1/rules/lib/core/list) of [File](/versions/8.2.1/rules/lib/builtins/File)s; default is `[]`  A list of outputs that the Java compilation action will output in addition to the class jar from annotation processing. |
+| `strict_deps` | [string](/versions/8.2.1/rules/lib/core/string); default is `'ERROR'`  A string that specifies how to handle strict deps. Possible values: 'OFF', 'ERROR', 'WARN' and 'DEFAULT'. For more details see [`--strict_java_deps flag`](/versions/8.2.1/docs/user-manual#flag--strict_java_deps). By default 'ERROR'. |
 | `java_toolchain` | Info; required  A JavaToolchainInfo to be used for this compilation. Mandatory. |
 | `bootclasspath` | default is `None`  A BootClassPathInfo to be used for this compilation. If present, overrides the bootclasspath associated with the provided java\_toolchain. |
 | `host_javabase` | default is `None`  **Deprecated**. This parameter is deprecated and will be removed soon. Please do not depend on it. It is *disabled* with `--incompatible_java_common_parameters`. Use this flag to verify your code is compatible with its imminent removal.  Deprecated: You can drop this parameter (host\_javabase is provided with java\_toolchain) |
-| `sourcepath` | [sequence](../core/list) of [File](../builtins/File)s; default is `[]` |
-| `resources` | [sequence](../core/list) of [File](../builtins/File)s; default is `[]` |
-| `resource_jars` | [sequence](../core/list) of [File](../builtins/File)s; default is `[]` |
-| `classpath_resources` | [sequence](../core/list) of [File](../builtins/File)s; default is `[]` |
-| `neverlink` | [bool](../core/bool); default is `False` |
-| `enable_annotation_processing` | [bool](../core/bool); default is `True`  Disables annotation processing in this compilation, causing any annotation processors provided in plugins or in exported\_plugins of deps to be ignored. |
-| `enable_compile_jar_action` | [bool](../core/bool); default is `True`  Enables header compilation or ijar creation. If set to False, it forces use of the full class jar in the compilation classpaths of any dependants. Doing so is intended for use by non-library targets such as binaries that do not have dependants. |
-| `add_exports` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  Allow this library to access the given /. |
-| `add_opens` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  Allow this library to reflectively access the given /. |
+| `sourcepath` | [sequence](/versions/8.2.1/rules/lib/core/list) of [File](/versions/8.2.1/rules/lib/builtins/File)s; default is `[]` |
+| `resources` | [sequence](/versions/8.2.1/rules/lib/core/list) of [File](/versions/8.2.1/rules/lib/builtins/File)s; default is `[]` |
+| `resource_jars` | [sequence](/versions/8.2.1/rules/lib/core/list) of [File](/versions/8.2.1/rules/lib/builtins/File)s; default is `[]` |
+| `classpath_resources` | [sequence](/versions/8.2.1/rules/lib/core/list) of [File](/versions/8.2.1/rules/lib/builtins/File)s; default is `[]` |
+| `neverlink` | [bool](/versions/8.2.1/rules/lib/core/bool); default is `False` |
+| `enable_annotation_processing` | [bool](/versions/8.2.1/rules/lib/core/bool); default is `True`  Disables annotation processing in this compilation, causing any annotation processors provided in plugins or in exported\_plugins of deps to be ignored. |
+| `enable_compile_jar_action` | [bool](/versions/8.2.1/rules/lib/core/bool); default is `True`  Enables header compilation or ijar creation. If set to False, it forces use of the full class jar in the compilation classpaths of any dependants. Doing so is intended for use by non-library targets such as binaries that do not have dependants. |
+| `add_exports` | [sequence](/versions/8.2.1/rules/lib/core/list) of [string](/versions/8.2.1/rules/lib/core/string)s; default is `[]`  Allow this library to access the given /. |
+| `add_opens` | [sequence](/versions/8.2.1/rules/lib/core/list) of [string](/versions/8.2.1/rules/lib/core/string)s; default is `[]`  Allow this library to reflectively access the given /. |
 
 ## JavaRuntimeInfo
 
@@ -91,7 +91,7 @@ Merges the given providers into a single JavaInfo.
 
 | Parameter | Description |
 | --- | --- |
-| `providers` | [sequence](../core/list) of [struct](../builtins/struct)s; required  The list of providers to merge. |
+| `providers` | [sequence](/versions/8.2.1/rules/lib/core/list) of [struct](/versions/8.2.1/rules/lib/builtins/struct)s; required  The list of providers to merge. |
 
 ## pack\_sources
 
@@ -109,11 +109,11 @@ Packs sources and source jars into a single source jar file. The return value is
 
 | Parameter | Description |
 | --- | --- |
-| `actions` | [actions](../builtins/actions); required  ctx.actions |
-| `output_jar` | [File](../builtins/File); or `None`; default is `None`  **Deprecated**. This parameter is deprecated and will be removed soon. Please do not depend on it. It is *disabled* with `--incompatible_java_common_parameters`. Use this flag to verify your code is compatible with its imminent removal.  Deprecated: The output jar of the rule. Used to name the resulting source jar. The parameter sets output\_source\_jar parameter to `{output\_jar}-src.jar`.Use output\_source\_jar parameter directly instead. |
-| `output_source_jar` | [File](../builtins/File); or `None`; default is `None` |
-| `sources` | [sequence](../core/list) of [File](../builtins/File)s; default is `[]`  A list of Java source files to be packed into the source jar. |
-| `source_jars` | [sequence](../core/list) of [File](../builtins/File)s; default is `[]`  A list of source jars to be packed into the source jar. |
+| `actions` | [actions](/versions/8.2.1/rules/lib/builtins/actions); required  ctx.actions |
+| `output_jar` | [File](/versions/8.2.1/rules/lib/builtins/File); or `None`; default is `None`  **Deprecated**. This parameter is deprecated and will be removed soon. Please do not depend on it. It is *disabled* with `--incompatible_java_common_parameters`. Use this flag to verify your code is compatible with its imminent removal.  Deprecated: The output jar of the rule. Used to name the resulting source jar. The parameter sets output\_source\_jar parameter to `{output\_jar}-src.jar`.Use output\_source\_jar parameter directly instead. |
+| `output_source_jar` | [File](/versions/8.2.1/rules/lib/builtins/File); or `None`; default is `None` |
+| `sources` | [sequence](/versions/8.2.1/rules/lib/core/list) of [File](/versions/8.2.1/rules/lib/builtins/File)s; default is `[]`  A list of Java source files to be packed into the source jar. |
+| `source_jars` | [sequence](/versions/8.2.1/rules/lib/core/list) of [File](/versions/8.2.1/rules/lib/builtins/File)s; default is `[]`  A list of source jars to be packed into the source jar. |
 | `java_toolchain` | Info; required  A JavaToolchainInfo to used to find the ijar tool. |
 | `host_javabase` | default is `None`  **Deprecated**. This parameter is deprecated and will be removed soon. Please do not depend on it. It is *disabled* with `--incompatible_java_common_parameters`. Use this flag to verify your code is compatible with its imminent removal.  Deprecated: You can drop this parameter (host\_javabase is provided with java\_toolchain) |
 
@@ -129,9 +129,9 @@ Runs ijar on a jar, stripping it of its method bodies. This helps reduce rebuild
 
 | Parameter | Description |
 | --- | --- |
-| `actions` | [actions](../builtins/actions); required |
-| `jar` | [File](../builtins/File); required  The jar to run ijar on. |
-| `target_label` | [Label](../builtins/Label); or `None`; default is `None`  A target label to stamp the jar with. Used for `add_dep` support. Typically, you would pass `ctx.label` to stamp the jar with the current rule's label. |
+| `actions` | [actions](/versions/8.2.1/rules/lib/builtins/actions); required |
+| `jar` | [File](/versions/8.2.1/rules/lib/builtins/File); required  The jar to run ijar on. |
+| `target_label` | [Label](/versions/8.2.1/rules/lib/builtins/Label); or `None`; default is `None`  A target label to stamp the jar with. Used for `add_dep` support. Typically, you would pass `ctx.label` to stamp the jar with the current rule's label. |
 | `java_toolchain` | Info; required  A JavaToolchainInfo to used to find the ijar tool. |
 
 ## stamp\_jar
@@ -146,7 +146,7 @@ Stamps a jar with a target label for `add_dep` support. The return value is typi
 
 | Parameter | Description |
 | --- | --- |
-| `actions` | [actions](../builtins/actions); required  ctx.actions |
-| `jar` | [File](../builtins/File); required  The jar to run stamp\_jar on. |
-| `target_label` | [Label](../builtins/Label); required  A target label to stamp the jar with. Used for `add_dep` support. Typically, you would pass `ctx.label` to stamp the jar with the current rule's label. |
+| `actions` | [actions](/versions/8.2.1/rules/lib/builtins/actions); required  ctx.actions |
+| `jar` | [File](/versions/8.2.1/rules/lib/builtins/File); required  The jar to run stamp\_jar on. |
+| `target_label` | [Label](/versions/8.2.1/rules/lib/builtins/Label); required  A target label to stamp the jar with. Used for `add_dep` support. Typically, you would pass `ctx.label` to stamp the jar with the current rule's label. |
 | `java_toolchain` | Info; required  A JavaToolchainInfo to used to find the stamp\_jar tool. |
\ No newline at end of file
diff --git a/versions/8.2.1/rules/lib/toplevel/native.mdx b/versions/8.2.1/rules/lib/toplevel/native.mdx
index 204fb814..a744dfca 100644
--- a/versions/8.2.1/rules/lib/toplevel/native.mdx
+++ b/versions/8.2.1/rules/lib/toplevel/native.mdx
@@ -46,7 +46,7 @@ If possible, avoid using this function. It makes BUILD files brittle and order-d
 
 | Parameter | Description |
 | --- | --- |
-| `name` | [string](../core/string); required |
+| `name` | [string](/versions/8.2.1/rules/lib/core/string); required |
 
 ## existing\_rules
 
@@ -72,9 +72,9 @@ Specifies a list of files belonging to this package that are exported to other p
 
 | Parameter | Description |
 | --- | --- |
-| `srcs` | [sequence](../core/list) of [string](../core/string)s; required  The list of files to export. |
-| `visibility` | [sequence](../core/list); or `None`; default is `None`  A visibility declaration can to be specified. The files will be visible to the targets specified. If no visibility is specified, the files will be visible to every package. |
-| `licenses` | [sequence](../core/list) of [string](../core/string)s; or `None`; default is `None`  Licenses to be specified. |
+| `srcs` | [sequence](/versions/8.2.1/rules/lib/core/list) of [string](/versions/8.2.1/rules/lib/core/string)s; required  The list of files to export. |
+| `visibility` | [sequence](/versions/8.2.1/rules/lib/core/list); or `None`; default is `None`  A visibility declaration can to be specified. The files will be visible to the targets specified. If no visibility is specified, the files will be visible to every package. |
+| `licenses` | [sequence](/versions/8.2.1/rules/lib/core/list) of [string](/versions/8.2.1/rules/lib/core/string)s; or `None`; default is `None`  Licenses to be specified. |
 
 ## glob
 
@@ -93,9 +93,9 @@ If the `exclude_directories` argument is enabled (set to `1`), files of type dir
 
 | Parameter | Description |
 | --- | --- |
-| `include` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  The list of glob patterns to include. |
-| `exclude` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  The list of glob patterns to exclude. |
-| `exclude_directories` | [int](../core/int); default is `1`  A flag whether to exclude directories or not. |
+| `include` | [sequence](/versions/8.2.1/rules/lib/core/list) of [string](/versions/8.2.1/rules/lib/core/string)s; default is `[]`  The list of glob patterns to include. |
+| `exclude` | [sequence](/versions/8.2.1/rules/lib/core/list) of [string](/versions/8.2.1/rules/lib/core/string)s; default is `[]`  The list of glob patterns to exclude. |
+| `exclude_directories` | [int](/versions/8.2.1/rules/lib/core/int); default is `1`  A flag whether to exclude directories or not. |
 | `allow_empty` | default is `unbound`  Whether we allow glob patterns to match nothing. If `allow\_empty` is False, each individual include pattern must match something and also the final result must be non-empty (after the matches of the `exclude` patterns are excluded). |
 
 ## module\_name
@@ -128,9 +128,9 @@ This function defines a set of packages and assigns a label to the group. The la
 
 | Parameter | Description |
 | --- | --- |
-| `name` | [string](../core/string); required  The unique name for this rule. |
-| `packages` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  A complete enumeration of packages in this group. |
-| `includes` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  Other package groups that are included in this one. |
+| `name` | [string](/versions/8.2.1/rules/lib/core/string); required  The unique name for this rule. |
+| `packages` | [sequence](/versions/8.2.1/rules/lib/core/list) of [string](/versions/8.2.1/rules/lib/core/string)s; default is `[]`  A complete enumeration of packages in this group. |
+| `includes` | [sequence](/versions/8.2.1/rules/lib/core/list) of [string](/versions/8.2.1/rules/lib/core/string)s; default is `[]`  Other package groups that are included in this one. |
 
 ## package\_name
 
@@ -146,19 +146,19 @@ The name of the package being evaluated, without the repository name. For exampl
 Label native.package_relative_label(input)
 ```
 
-Converts the input string into a [Label](../builtins/Label) object, in the context of the package currently being initialized (that is, the `BUILD` file for which the current macro is executing). If the input is already a `Label`, it is returned unchanged.
+Converts the input string into a [Label](/versions/8.2.1/rules/lib/builtins/Label) object, in the context of the package currently being initialized (that is, the `BUILD` file for which the current macro is executing). If the input is already a `Label`, it is returned unchanged.
 
 This function may only be called while evaluating a BUILD file and the macros it directly or indirectly calls; it may not be called in (for instance) a rule implementation function.
 
 The result of this function is the same `Label` value as would be produced by passing the given string to a label-valued attribute of a target declared in the BUILD file.
 
-*Usage note:* The difference between this function and [Label()](../builtins/Label#Label) is that `Label()` uses the context of the package of the `.bzl` file that called it, not the package of the `BUILD` file. Use `Label()` when you need to refer to a fixed target that is hardcoded into the macro, such as a compiler. Use `package_relative_label()` when you need to normalize a label string supplied by the BUILD file to a `Label` object. (There is no way to convert a string to a `Label` in the context of a package other than the BUILD file or the calling .bzl file. For that reason, outer macros should always prefer to pass Label objects to inner macros rather than label strings.)
+*Usage note:* The difference between this function and [Label()](/versions/8.2.1/rules/lib/builtins/Label#Label) is that `Label()` uses the context of the package of the `.bzl` file that called it, not the package of the `BUILD` file. Use `Label()` when you need to refer to a fixed target that is hardcoded into the macro, such as a compiler. Use `package_relative_label()` when you need to normalize a label string supplied by the BUILD file to a `Label` object. (There is no way to convert a string to a `Label` in the context of a package other than the BUILD file or the calling .bzl file. For that reason, outer macros should always prefer to pass Label objects to inner macros rather than label strings.)
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `input` | [string](../core/string); or [Label](../builtins/Label); required  The input label string or Label object. If a Label object is passed, it's returned as is. |
+| `input` | [string](/versions/8.2.1/rules/lib/core/string); or [Label](/versions/8.2.1/rules/lib/builtins/Label); required  The input label string or Label object. If a Label object is passed, it's returned as is. |
 
 ## repo\_name
 
@@ -191,6 +191,6 @@ Returns a new mutable list of every direct subpackage of the current package, re
 
 | Parameter | Description |
 | --- | --- |
-| `include` | [sequence](../core/list) of [string](../core/string)s; required |
-| `exclude` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  The list of glob patterns to exclude from subpackages scan. |
-| `allow_empty` | [bool](../core/bool); default is `False`  Whether we fail if the call returns an empty list. By default empty list indicates potential error in BUILD file where the call to subpackages() is superflous. Setting to true allows this function to succeed in that case. |*
\ No newline at end of file
+| `include` | [sequence](/versions/8.2.1/rules/lib/core/list) of [string](/versions/8.2.1/rules/lib/core/string)s; required |
+| `exclude` | [sequence](/versions/8.2.1/rules/lib/core/list) of [string](/versions/8.2.1/rules/lib/core/string)s; default is `[]`  The list of glob patterns to exclude from subpackages scan. |
+| `allow_empty` | [bool](/versions/8.2.1/rules/lib/core/bool); default is `False`  Whether we fail if the call returns an empty list. By default empty list indicates potential error in BUILD file where the call to subpackages() is superflous. Setting to true allows this function to succeed in that case. |*
\ No newline at end of file
diff --git a/versions/8.2.1/rules/lib/toplevel/platform_common.mdx b/versions/8.2.1/rules/lib/toplevel/platform_common.mdx
index 17edc7c5..06cc5828 100644
--- a/versions/8.2.1/rules/lib/toplevel/platform_common.mdx
+++ b/versions/8.2.1/rules/lib/toplevel/platform_common.mdx
@@ -18,7 +18,7 @@ Functions for Starlark to interact with the platform APIs.
 Provider platform_common.ConstraintSettingInfo
 ```
 
-The constructor/key for the [ConstraintSettingInfo](../providers/ConstraintSettingInfo) provider.
+The constructor/key for the [ConstraintSettingInfo](/versions/8.2.1/rules/lib/providers/ConstraintSettingInfo) provider.
 *Note: This API is experimental and may change at any time. It is disabled by default, but may be enabled with `--experimental_platforms_api`*
 
 ## ConstraintValueInfo
@@ -27,7 +27,7 @@ The constructor/key for the [ConstraintSettingInfo](../providers/ConstraintSetti
 Provider platform_common.ConstraintValueInfo
 ```
 
-The constructor/key for the [ConstraintValueInfo](../providers/ConstraintValueInfo) provider.
+The constructor/key for the [ConstraintValueInfo](/versions/8.2.1/rules/lib/providers/ConstraintValueInfo) provider.
 *Note: This API is experimental and may change at any time. It is disabled by default, but may be enabled with `--experimental_platforms_api`*
 
 ## PlatformInfo
@@ -36,7 +36,7 @@ The constructor/key for the [ConstraintValueInfo](../providers/ConstraintValueIn
 Provider platform_common.PlatformInfo
 ```
 
-The constructor/key for the [PlatformInfo](../providers/PlatformInfo) provider.
+The constructor/key for the [PlatformInfo](/versions/8.2.1/rules/lib/providers/PlatformInfo) provider.
 *Note: This API is experimental and may change at any time. It is disabled by default, but may be enabled with `--experimental_platforms_api`*
 
 ## TemplateVariableInfo
@@ -45,7 +45,7 @@ The constructor/key for the [PlatformInfo](../providers/PlatformInfo) provider.
 Provider platform_common.TemplateVariableInfo
 ```
 
-The constructor/key for the [TemplateVariableInfo](../providers/TemplateVariableInfo) provider.
+The constructor/key for the [TemplateVariableInfo](/versions/8.2.1/rules/lib/providers/TemplateVariableInfo) provider.
 
 ## ToolchainInfo
 
@@ -53,4 +53,4 @@ The constructor/key for the [TemplateVariableInfo](../providers/TemplateVariable
 Provider platform_common.ToolchainInfo
 ```
 
-The constructor/key for the [ToolchainInfo](../providers/ToolchainInfo) provider.
\ No newline at end of file
+The constructor/key for the [ToolchainInfo](/versions/8.2.1/rules/lib/providers/ToolchainInfo) provider.
\ No newline at end of file
diff --git a/versions/8.2.1/rules/lib/toplevel/testing.mdx b/versions/8.2.1/rules/lib/toplevel/testing.mdx
index 5489113c..0686197d 100644
--- a/versions/8.2.1/rules/lib/toplevel/testing.mdx
+++ b/versions/8.2.1/rules/lib/toplevel/testing.mdx
@@ -24,12 +24,12 @@ The number of transitive dependencies of the test are limited. The limit is cont
 
 | Parameter | Description |
 | --- | --- |
-| `name` | [string](../core/string); required  Name of the target. It should be a Starlark identifier, matching pattern '[A-Za-z\_][A-Za-z0-9\_]\*'. |
-| `implementation` | [function](../core/function); required  The Starlark function implementing this analysis test. It must have exactly one parameter: [ctx](../builtins/ctx). The function is called during the analysis phase. It can access the attributes declared by `attrs` and populated via `attr_values`. The implementation function may not register actions. Instead, it must register a pass/fail result via providing [AnalysisTestResultInfo](../providers/AnalysisTestResultInfo). |
-| `attrs` | [dict](../core/dict); default is `{}`  Dictionary declaring the attributes. See the [rule](../globals/bzl#rule) call. Attributes are allowed to use configuration transitions defined using [analysis\_test\_transition](../globals/bzl#analysis_test_transition). |
-| `fragments` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  List of configuration fragments that are available to the implementation of the analysis test. |
-| `toolchains` | [sequence](../core/list); default is `[]`  The set of toolchains the test requires. See the [rule](../globals/bzl#rule) call. |
-| `attr_values` | [dict](../core/dict) of [string](../core/string)s; default is `{}`  Dictionary of attribute values to pass to the implementation. |
+| `name` | [string](/versions/8.2.1/rules/lib/core/string); required  Name of the target. It should be a Starlark identifier, matching pattern '[A-Za-z\_][A-Za-z0-9\_]\*'. |
+| `implementation` | [function](/versions/8.2.1/rules/lib/core/function); required  The Starlark function implementing this analysis test. It must have exactly one parameter: [ctx](/versions/8.2.1/rules/lib/builtins/ctx). The function is called during the analysis phase. It can access the attributes declared by `attrs` and populated via `attr_values`. The implementation function may not register actions. Instead, it must register a pass/fail result via providing [AnalysisTestResultInfo](/versions/8.2.1/rules/lib/providers/AnalysisTestResultInfo). |
+| `attrs` | [dict](/versions/8.2.1/rules/lib/core/dict); default is `{}`  Dictionary declaring the attributes. See the [rule](/versions/8.2.1/rules/lib/globals/bzl#rule) call. Attributes are allowed to use configuration transitions defined using [analysis\_test\_transition](/versions/8.2.1/rules/lib/globals/bzl#analysis_test_transition). |
+| `fragments` | [sequence](/versions/8.2.1/rules/lib/core/list) of [string](/versions/8.2.1/rules/lib/core/string)s; default is `[]`  List of configuration fragments that are available to the implementation of the analysis test. |
+| `toolchains` | [sequence](/versions/8.2.1/rules/lib/core/list); default is `[]`  The set of toolchains the test requires. See the [rule](/versions/8.2.1/rules/lib/globals/bzl#rule) call. |
+| `attr_values` | [dict](/versions/8.2.1/rules/lib/core/dict) of [string](/versions/8.2.1/rules/lib/core/string)s; default is `{}`  Dictionary of attribute values to pass to the implementation. |
 
 ## ExecutionInfo
 
@@ -37,7 +37,7 @@ The number of transitive dependencies of the test are limited. The limit is cont
 ExecutionInfo testing.ExecutionInfo
 ```
 
-[testing.ExecutionInfo](../providers/ExecutionInfo) provider key/constructor
+[testing.ExecutionInfo](/versions/8.2.1/rules/lib/providers/ExecutionInfo) provider key/constructor
 
 ## TestEnvironment
 
@@ -51,5 +51,5 @@ RunEnvironmentInfo testing.TestEnvironment(environment, inherited_environment=[]
 
 | Parameter | Description |
 | --- | --- |
-| `environment` | [dict](../core/dict); required  A map of string keys and values that represent environment variables and their values. These will be made available during the test execution. |
-| `inherited_environment` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  A sequence of names of environment variables. These variables are made available during the test execution with their current value taken from the shell environment. If a variable is contained in both `environment` and `inherited_environment`, the value inherited from the shell environment will take precedence if set. |
\ No newline at end of file
+| `environment` | [dict](/versions/8.2.1/rules/lib/core/dict); required  A map of string keys and values that represent environment variables and their values. These will be made available during the test execution. |
+| `inherited_environment` | [sequence](/versions/8.2.1/rules/lib/core/list) of [string](/versions/8.2.1/rules/lib/core/string)s; default is `[]`  A sequence of names of environment variables. These variables are made available during the test execution with their current value taken from the shell environment. If a variable is contained in both `environment` and `inherited_environment`, the value inherited from the shell environment will take precedence if set. |
\ No newline at end of file
diff --git a/versions/8.2.1/rules/macro-tutorial.mdx b/versions/8.2.1/rules/macro-tutorial.mdx
index cf7acd0d..d65cf8d9 100644
--- a/versions/8.2.1/rules/macro-tutorial.mdx
+++ b/versions/8.2.1/rules/macro-tutorial.mdx
@@ -5,7 +5,7 @@ title: 'Creating a Symbolic Macro'
 IMPORTANT: This tutorial is for [*symbolic macros*](/versions/8.2.1/extending/macros) – the new
 macro system introduced in Bazel 8. If you need to support older Bazel versions,
 you will want to write a [legacy macro](/versions/8.2.1/extending/legacy-macros) instead; take
-a look at [Creating a Legacy Macro](../legacy-macro-tutorial).
+a look at [Creating a Legacy Macro](/versions/8.2.1/rules/legacy-macro-tutorial).
 
 Imagine that you need to run a tool as part of your build. For example, you
 may want to generate or preprocess a source file, or compress a binary. In this
diff --git a/versions/8.2.1/rules/performance.mdx b/versions/8.2.1/rules/performance.mdx
index 2e88f348..9625bb0b 100644
--- a/versions/8.2.1/rules/performance.mdx
+++ b/versions/8.2.1/rules/performance.mdx
@@ -15,7 +15,7 @@ widespread use.
 ## Use depsets {#use-depsets}
 
 Whenever you are rolling up information from rule dependencies you should use
-[depsets](lib/depset). Only use plain lists or dicts to publish information
+[depsets](/versions/8.2.1/rules/lib/builtins/depset). Only use plain lists or dicts to publish information
 local to the current rule.
 
 A depset represents information as a nested graph which enables sharing.
@@ -73,7 +73,7 @@ See the [depset overview](/versions/8.2.1/extending/depsets) page for more infor
 ### Avoid calling `depset.to_list()` {#avoid-depset-to-list}
 
 You can coerce a depset to a flat list using
-[`to_list()`](lib/depset#to_list), but doing so usually results in O(N^2)
+[`to_list()`](/versions/8.2.1/rules/lib/builtins/depset#to_list), but doing so usually results in O(N^2)
 cost. If at all possible, avoid any flattening of depsets except for debugging
 purposes.
 
@@ -115,7 +115,7 @@ x = depset(transitive = [i.deps for i in inputs])
 
 ## Use ctx.actions.args() for command lines {#ctx-actions-args}
 
-When building command lines you should use [ctx.actions.args()](lib/Args).
+When building command lines you should use [ctx.actions.args()](/versions/8.2.1/rules/lib/builtins/Args).
 This defers expansion of any depsets to the execution phase.
 
 Apart from being strictly faster, this will reduce the memory consumption of
@@ -126,11 +126,11 @@ Here are some tricks:
 * Pass depsets and lists directly as arguments, instead of flattening them
 yourself. They will get expanded by `ctx.actions.args()` for you.
 If you need any transformations on the depset contents, look at
-[ctx.actions.args#add](lib/Args#add) to see if anything fits the bill.
+[ctx.actions.args#add](/versions/8.2.1/rules/lib/builtins/Args#add) to see if anything fits the bill.
 
 * Are you passing `File#path` as arguments? No need. Any
-[File](lib/File) is automatically turned into its
-[path](lib/File#path), deferred to expansion time.
+[File](/versions/8.2.1/rules/lib/builtins/File) is automatically turned into its
+[path](/versions/8.2.1/rules/lib/builtins/File#path), deferred to expansion time.
 
 * Avoid constructing strings by concatenating them together.
 The best string argument is a constant as its memory will be shared between
@@ -138,10 +138,10 @@ all instances of your rule.
 
 * If the args are too long for the command line an `ctx.actions.args()` object
 can be conditionally or unconditionally written to a param file using
-[`ctx.actions.args#use_param_file`](lib/Args#use_param_file). This is
+[`ctx.actions.args#use_param_file`](/versions/8.2.1/rules/lib/builtins/Args#use_param_file). This is
 done behind the scenes when the action is executed. If you need to explicitly
 control the params file you can write it manually using
-[`ctx.actions.write`](lib/actions#write).
+[`ctx.actions.write`](/versions/8.2.1/rules/lib/builtins/actions#write).
 
 Example:
 
@@ -176,7 +176,7 @@ def _to_short_path(f):
 
 ## Transitive action inputs should be depsets {#transitive-action-inputs}
 
-When building an action using [ctx.actions.run](lib/actions?#run), do not
+When building an action using [ctx.actions.run](/versions/8.2.1/rules/lib/builtins/actions#run), do not
 forget that the `inputs` field accepts a depset. Use this whenever inputs are
 collected from dependencies transitively.
 
diff --git a/versions/8.2.1/rules/rules-tutorial.mdx b/versions/8.2.1/rules/rules-tutorial.mdx
index 21b205fd..0a6ec37b 100644
--- a/versions/8.2.1/rules/rules-tutorial.mdx
+++ b/versions/8.2.1/rules/rules-tutorial.mdx
@@ -31,9 +31,9 @@ foo_binary = rule(
 )
 ```
 
-When you call the [`rule`](lib/globals#rule) function, you
+When you call the [`rule`](/versions/8.2.1/rules/lib/globals#rule) function, you
 must define a callback function. The logic will go there, but you
-can leave the function empty for now. The [`ctx`](lib/ctx) argument
+can leave the function empty for now. The [`ctx`](/versions/8.2.1/rules/lib/builtins/ctx) argument
 provides information about the target.
 
 You can load the rule and use it from a `BUILD` file.
@@ -86,10 +86,10 @@ foo_binary(name = "bin1")
 foo_binary(name = "bin2")
 ```
 
-[`ctx.label`](lib/ctx#label)
+[`ctx.label`](/versions/8.2.1/rules/lib/builtins/ctx#label)
 corresponds to the label of the target being analyzed. The `ctx` object has
 many useful fields and methods; you can find an exhaustive list in the
-[API reference](lib/ctx).
+[API reference](/versions/8.2.1/rules/lib/builtins/ctx).
 
 Query the code:
 
@@ -145,7 +145,7 @@ bin2
 ```
 
 Whenever you declare a file, you have to tell Bazel how to generate it by
-creating an action. Use [`ctx.actions.write`](lib/actions#write),
+creating an action. Use [`ctx.actions.write`](/versions/8.2.1/rules/lib/builtins/actions#write),
 to create a file with the given content.
 
 ```python
@@ -200,7 +200,7 @@ You have successfully generated a file!
 ## Attributes
 
 To make the rule more useful, add new attributes using
-[the `attr` module](lib/attr) and update the rule definition.
+[the `attr` module](/versions/8.2.1/rules/lib/toplevel/attr) and update the rule definition.
 
 Add a string attribute called `username`:
 
@@ -236,22 +236,22 @@ def _foo_binary_impl(ctx):
 ```
 
 Note that you can make the attribute mandatory or set a default value. Look at
-the documentation of [`attr.string`](lib/attr#string).
-You may also use other types of attributes, such as [boolean](lib/attr#bool)
-or [list of integers](lib/attr#int_list).
+the documentation of [`attr.string`](/versions/8.2.1/rules/lib/toplevel/attr#string).
+You may also use other types of attributes, such as [boolean](/versions/8.2.1/rules/lib/toplevel/attr#bool)
+or [list of integers](/versions/8.2.1/rules/lib/toplevel/attr#int_list).
 
 ## Dependencies
 
-Dependency attributes, such as [`attr.label`](lib/attr#label)
-and [`attr.label_list`](lib/attr#label_list),
+Dependency attributes, such as [`attr.label`](/versions/8.2.1/rules/lib/toplevel/attr#label)
+and [`attr.label_list`](/versions/8.2.1/rules/lib/toplevel/attr#label_list),
 declare a dependency from the target that owns the attribute to the target whose
 label appears in the attribute's value. This kind of attribute forms the basis
 of the target graph.
 
 In the `BUILD` file, the target label appears as a string object, such as
 `//pkg:name`. In the implementation function, the target will be accessible as a
-[`Target`](lib/Target) object. For example, view the files returned
-by the target using [`Target.files`](lib/Target#modules.Target.files).
+[`Target`](/versions/8.2.1/rules/lib/builtins/Target) object. For example, view the files returned
+by the target using [`Target.files`](/versions/8.2.1/rules/lib/builtins/Target#modules.Target.files).
 
 ### Multiple files
 
@@ -294,7 +294,7 @@ implementation function, but this has two problems. First, as the template gets
 bigger, it becomes more memory efficient to put it in a separate file and avoid
 constructing large strings during the analysis phase. Second, using a separate
 file is more convenient for the user. Instead, use
-[`ctx.actions.expand_template`](lib/actions#expand_template),
+[`ctx.actions.expand_template`](/versions/8.2.1/rules/lib/builtins/actions#expand_template),
 which performs substitutions on a template file.
 
 Create a `template` attribute to declare a dependency on the template
diff --git a/versions/8.2.1/rules/testing.mdx b/versions/8.2.1/rules/testing.mdx
index 6408339c..b66a25b0 100644
--- a/versions/8.2.1/rules/testing.mdx
+++ b/versions/8.2.1/rules/testing.mdx
@@ -234,7 +234,7 @@ def _inspect_actions_test_impl(ctx):
 ```
 
 Note that `analysistest.target_actions(env)` returns a list of
-[`Action`](lib/Action) objects which represent actions registered by the
+[`Action`](/versions/8.2.1/rules/lib/builtins/Action) objects which represent actions registered by the
 target under test.
 
 ### Verifying rule behavior under different flags {#verifying-rule-behavior}
diff --git a/versions/8.2.1/rules/verbs-tutorial.mdx b/versions/8.2.1/rules/verbs-tutorial.mdx
index 0d225d4d..36d60ada 100644
--- a/versions/8.2.1/rules/verbs-tutorial.mdx
+++ b/versions/8.2.1/rules/verbs-tutorial.mdx
@@ -49,8 +49,7 @@ This pattern can also be seen in the Angular project. The
 produces two targets. The first is a standard `nodejs_test` target which compares
 some generated output against a "golden" file (that is, a file containing the
 expected output). This can be built and run with a normal `bazel
-test` invocation. In `angular-cli`, you can run [one such
-target](https://github.com/angular/angular-cli/blob/e1269cb520871ee29b1a4eec6e6c0e4a94f0b5fc/etc/api/BUILD)
+test` invocation. In `angular-cli`, you can run [one such target](https://github.com/angular/angular-cli/blob/e1269cb520871ee29b1a4eec6e6c0e4a94f0b5fc/etc/api/BUILD)
 with `bazel test //etc/api:angular_devkit_core_api`.
 
 Over time, this golden file may need to be updated for legitimate reasons.
@@ -159,7 +158,7 @@ an imaginary `bazel publish` command.
 It's not immediately obvious what the implementation of the `_sphinx_publisher`
 rule might look like. Often, actions like this write a _launcher_ shell script.
 This method typically involves using
-[`ctx.actions.expand_template`](lib/actions#expand_template)
+[`ctx.actions.expand_template`](/versions/8.2.1/rules/lib/builtins/actions#expand_template)
 to write a very simple shell script, in this case invoking the publisher binary
 with a path to the output of the primary target. This way, the publisher
 implementation can remain generic, the `_sphinx_site` rule can just produce
diff --git a/versions/8.2.1/run/build.mdx b/versions/8.2.1/run/build.mdx
index 5d16ff40..26ded2d3 100644
--- a/versions/8.2.1/run/build.mdx
+++ b/versions/8.2.1/run/build.mdx
@@ -633,8 +633,7 @@ Note: Hermeticity means that the action only uses its declared input
 files and no other files in the filesystem, and it only produces its declared
 output files. See [Hermeticity](/versions/8.2.1/basics/hermeticity) for more details.
 
-On some platforms such as [Google Kubernetes
-Engine](https://cloud.google.com/kubernetes-engine/) cluster nodes or Debian,
+On some platforms such as [Google Kubernetes Engine](https://cloud.google.com/kubernetes-engine/) cluster nodes or Debian,
 user namespaces are deactivated by default due to security
 concerns. This can be checked by looking at the file
 `/proc/sys/kernel/unprivileged_userns_clone`: if it exists and contains a 0,
diff --git a/versions/8.2.1/start/android-app.mdx b/versions/8.2.1/start/android-app.mdx
index 9066787e..56cefe70 100644
--- a/versions/8.2.1/start/android-app.mdx
+++ b/versions/8.2.1/start/android-app.mdx
@@ -36,8 +36,7 @@ In this tutorial you learn how to:
 Before you begin the tutorial, install the following software:
 
 * **Bazel.** To install, follow the [installation instructions](/versions/8.2.1/install).
-* **Android Studio.** To install, follow the steps to [download Android
-  Studio](https://developer.android.com/sdk/index.html).
+* **Android Studio.** To install, follow the steps to [download Android Studio](https://developer.android.com/sdk/index.html).
   Execute the setup wizard to download the SDK and configure your environment.
 * (Optional) **Git.** Use `git` to download the Android app project.
 
@@ -52,8 +51,7 @@ This app has a single button that prints a greeting when clicked:
 
 **Figure 1.** Android app button greeting.
 
-Clone the repository with `git` (or [download the ZIP file
-directly](https://github.com/bazelbuild/examples/archive/master.zip)):
+Clone the repository with `git` (or [download the ZIP file directly](https://github.com/bazelbuild/examples/archive/master.zip)):
 
 ```posix-terminal
 git clone https://github.com/bazelbuild/examples
@@ -103,8 +101,7 @@ A [workspace](/versions/8.2.1/concepts/build-ref#workspace) is a directory that
 source files for one or more software projects, and has a `MODULE.bazel` file at
 its root.
 
-The `MODULE.bazel` file may be empty or may contain references to [external
-dependencies](/versions/8.2.1/external/overview) required to build your project.
+The `MODULE.bazel` file may be empty or may contain references to [external dependencies](/versions/8.2.1/external/overview) required to build your project.
 
 First, run the following command to create an empty `MODULE.bazel` file:
 
@@ -147,8 +144,7 @@ environment variable, and automatically detect the highest API level and the
 latest version of build tools installed within that location.
 
 You can set the `ANDROID_HOME` variable to the location of the Android SDK. Find
-the path to the installed SDK using Android Studio's [SDK
-Manager](https://developer.android.com/studio/intro/update#sdk-manager).
+the path to the installed SDK using Android Studio's [SDK Manager](https://developer.android.com/studio/intro/update#sdk-manager).
 Assuming the SDK is installed to default locations, you can use the following
 commands to set the `ANDROID_HOME` variable:
 
@@ -170,16 +166,14 @@ them permanent, run the following commands:
 | Windows (PowerShell)     | `[System.Environment]::SetEnvironmentVariable('ANDROID_HOME', "$env:LOCALAPPDATA\Android\Sdk", [System.EnvironmentVariableTarget]::User)` |
 
 **Optional:** If you want to compile native code into your Android app, you
-also need to download the [Android
-NDK](https://developer.android.com/ndk/downloads/index.html)
+also need to download the [Android NDK](https://developer.android.com/ndk/downloads/index.html)
 and use `rules_android_ndk` by adding the following line to your `MODULE.bazel` file:
 
 ```python
 bazel_dep(name = "rules_android_ndk", version = "0.1.2")
 ```
 
-For more information, read [Using the Android Native Development Kit with
-Bazel](/versions/8.2.1/docs/android-ndk).
+For more information, read [Using the Android Native Development Kit with Bazel](/versions/8.2.1/docs/android-ndk).
 
 It's not necessary to set the API levels to the same value for the SDK and NDK.
 [This page](https://developer.android.com/ndk/guides/stable_apis.html)
@@ -221,8 +215,7 @@ files or other dependencies. Bazel provides two build rules,
 build an Android app.
 
 For this tutorial, you'll first use the
-`android_library` rule to tell Bazel to build an [Android library
-module](http://developer.android.com/tools/projects/index.html#LibraryProjects)
+`android_library` rule to tell Bazel to build an [Android library module](http://developer.android.com/tools/projects/index.html#LibraryProjects)
 from the app source code and resource files. You'll then use the
 `android_binary` rule to tell Bazel how to build the Android application package.
 
@@ -337,11 +330,9 @@ file:
 ### Run the app
 
 You can now deploy the app to a connected Android device or emulator from the
-command line using the [`bazel
-mobile-install`](/versions/8.2.1/docs/user-manual#mobile-install) command. This command uses
+command line using the [`bazel mobile-install`](/versions/8.2.1/docs/user-manual#mobile-install) command. This command uses
 the Android Debug Bridge (`adb`) to communicate with the device. You must set up
-your device to use `adb` following the instructions in [Android Debug
-Bridge](http://developer.android.com/tools/help/adb.html) before deployment. You
+your device to use `adb` following the instructions in [Android Debug Bridge](http://developer.android.com/tools/help/adb.html) before deployment. You
 can also choose to install the app on the Android emulator included in Android
 Studio. Make sure the emulator is running before executing the command below.
 
diff --git a/versions/8.2.1/start/cpp.mdx b/versions/8.2.1/start/cpp.mdx
index 646bd7db..b4ceabe2 100644
--- a/versions/8.2.1/start/cpp.mdx
+++ b/versions/8.2.1/start/cpp.mdx
@@ -19,8 +19,7 @@ Estimated completion time: 30 minutes.
 ### Prerequisites {#prerequisites}
 
 Start by [installing Bazel](https://bazel.build/versions/8.2.1/install), if you haven't
-already. This tutorial uses Git for source control, so for best results [install
-Git](https://git-scm.com/book/en/v2/Getting-Started-Installing-Git) as well.
+already. This tutorial uses Git for source control, so for best results [install Git](https://git-scm.com/book/en/v2/Getting-Started-Installing-Git) as well.
 
 Next, retrieve the sample project from Bazel's GitHub repository by running the
 following in your command-line tool of choice:
@@ -63,9 +62,7 @@ examples
 ```
 
 There are three sets of files, each set representing a stage in this tutorial.
-In the first stage, you will build a single [target]
-(https://bazel.build/reference/glossary#target) residing in a single [package]
-(https://bazel.build/reference/glossary#package). In the second stage, you will
+In the first stage, you will build a single [target](https://bazel.build/versions/8.2.1/reference/glossary#target) residing in a single [package](https://bazel.build/versions/8.2.1/reference/glossary#package). In the second stage, you will
 build both a binary and a library from a single package. In the third and final
 stage, you will build a project with multiple packages and build it with
 multiple targets.
@@ -86,8 +83,7 @@ It also contains these significant files:
 *   The `MODULE.bazel` file, which identifies the directory and its contents as
     a Bazel workspace and lives at the root of the project's directory
     structure. It's also where you specify your external dependencies.
-*   One or more [`BUILD`
-    files](https://bazel.build/reference/glossary#build-file), which tell Bazel
+*   One or more [`BUILD` files](https://bazel.build/versions/8.2.1/reference/glossary#build-file), which tell Bazel
     how to build different parts of the project. A directory within the
     workspace that contains a `BUILD` file is a
     [package](https://bazel.build/versions/8.2.1/reference/glossary#package). (More on packages
@@ -182,9 +178,7 @@ This results in a printed "`Hello world`" message.
 
 Here's the dependency graph of Stage 1:
 
-![Dependency graph for hello-world displays a single target with a single source
-file.](/versions/8.2.1/docs/images/cpp-tutorial-stage1.png "Dependency graph for hello-world
-displays a single target with a single source file.")
+![Dependency graph for hello-world displays a single target with a single source file.](/versions/8.2.1/docs/images/cpp-tutorial-stage1.png "Dependency graph for hello-world displays a single target with a single source file.")
 
 ### Summary: stage 1 {#summary-stage-1}
 
@@ -231,8 +225,7 @@ cc_binary(
 ```
 
 With this `BUILD` file, Bazel first builds the `hello-greet` library (using
-Bazel's built-in [`cc_library`
-rule](https://bazel.build/reference/be/c-cpp#cc_library)), then the
+Bazel's built-in [`cc_library` rule](https://bazel.build/versions/8.2.1/reference/be/c-cpp#cc_library)), then the
 `hello-world` binary. The `deps` attribute in the `hello-world` target tells
 Bazel that the `hello-greet` library is required to build the `hello-world`
 binary.
@@ -272,10 +265,7 @@ recompiles that file.
 Looking at the dependency graph, you can see that `hello-world` depends on an
 extra input named `hello-greet`:
 
-![Dependency graph for `hello-world` displays dependency changes after
-modification to the file.](/versions/8.2.1/docs/images/cpp-tutorial-stage2.png "Dependency
-graph for `hello-world` displays dependency changes after modification to the
-file.")
+![Dependency graph for `hello-world` displays dependency changes after modification to the file.](/versions/8.2.1/docs/images/cpp-tutorial-stage2.png "Dependency graph for `hello-world` displays dependency changes after modification to the file.")
 
 ### Summary: stage 2 {#summary-stage-2}
 
@@ -343,11 +333,7 @@ in the `lib` package (hence the target label `//lib:hello-time`) - Bazel knows
 this through the `deps` attribute. You can see this reflected in the dependency
 graph:
 
-![Dependency graph for `hello-world` displays how the target in the main package
-depends on the target in the `lib`
-package.](/versions/8.2.1/docs/images/cpp-tutorial-stage3.png "Dependency graph for
-`hello-world` displays how the target in the main package depends on the target
-in the `lib` package.")
+![Dependency graph for `hello-world` displays how the target in the main package depends on the target in the `lib` package.](/versions/8.2.1/docs/images/cpp-tutorial-stage3.png "Dependency graph for `hello-world` displays how the target in the main package depends on the target in the `lib` package.")
 
 For the build to succeed, you make the `//lib:hello-time` target in `lib/BUILD`
 explicitly visible to targets in `main/BUILD` using the visibility attribute.
@@ -395,15 +381,11 @@ Bazel journey.
 You've now completed your first basic build with Bazel, but this is just the
 start. Here are some more resources to continue learning with Bazel:
 
-*   To keep focusing on C++, read about common [C++ build use
-    cases](https://bazel.build/tutorials/cpp-use-cases).
+*   To keep focusing on C++, read about common [C++ build use cases](https://bazel.build/versions/8.2.1/tutorials/cpp-use-cases).
 *   To get started with building other applications with Bazel, see the
-    tutorials for [Java](https://bazel.build/versions/8.2.1/start/java), [Android
-    application](https://bazel.build/start/android-app), or [iOS
-    application](https://bazel.build/start/ios-app).
+    tutorials for [Java](https://bazel.build/versions/8.2.1/start/java), [Android application](https://bazel.build/versions/8.2.1/start/android-app), or [iOS application](https://bazel.build/versions/8.2.1/start/ios-app).
 *   To learn more about working with local and remote repositories, read about
     [external dependencies](https://bazel.build/versions/8.2.1/docs/external).
-*   To learn more about Bazel's other rules, see this [reference
-    guide](https://bazel.build/rules).
+*   To learn more about Bazel's other rules, see this [reference guide](https://bazel.build/versions/8.2.1/rules).
 
 Happy building!
\ No newline at end of file
diff --git a/versions/8.2.1/start/java.mdx b/versions/8.2.1/start/java.mdx
index ada49454..8aa7e829 100644
--- a/versions/8.2.1/start/java.mdx
+++ b/versions/8.2.1/start/java.mdx
@@ -241,8 +241,7 @@ recompiles that file.
 Looking at the dependency graph, you can see that `ProjectRunner` depends on the
 same inputs as it did before, but the structure of the build is different:
 
-![Dependency graph of the target 'ProjectRunner' after adding a dependency](
-/docs/images/tutorial_java_02.svg)
+![Dependency graph of the target 'ProjectRunner' after adding a dependency](/versions/8.2.1/docs/images/tutorial_java_02.svg)
 
 You've now built the project with two targets. The `ProjectRunner` target builds
 one source files and depends on one other target (`:greeter`), which builds
@@ -426,7 +425,7 @@ For more details, see:
 *  The [C++ build tutorial](/versions/8.2.1/start/cpp) to get started with building
    C++ projects with Bazel.
 
-*  The [Android application tutorial](/versions/8.2.1/start/android-app ) and
+*  The [Android application tutorial](/versions/8.2.1/start/android-app) and
    [iOS application tutorial](/versions/8.2.1/start/ios-app)) to get started with
    building mobile applications for Android and iOS with Bazel.
 
diff --git a/versions/8.2.1/tutorials/ccp-toolchain-config.mdx b/versions/8.2.1/tutorials/ccp-toolchain-config.mdx
index 4c3b46c7..39501b7c 100644
--- a/versions/8.2.1/tutorials/ccp-toolchain-config.mdx
+++ b/versions/8.2.1/tutorials/ccp-toolchain-config.mdx
@@ -29,8 +29,7 @@ uses `clang version 16`, which you can install on your system.
 
 Set up your build environment as follows:
 
-1.  If you have not already done so, [download and install Bazel
-    7.0.2](https://bazel.build/install) or later.
+1.  If you have not already done so, [download and install Bazel 7.0.2](https://bazel.build/versions/8.2.1/install) or later.
 
 2.  Add an empty `MODULE.bazel` file at the root folder.
 
@@ -450,8 +449,7 @@ The key takeaways are:
 
 -   You need to specify a matching `platforms` flag in the command line for
     Bazel to resolve to the toolchain for the same constraint values on the
-    platform. The documentation holds more [information about language specific
-    configuration flags](/versions/8.2.1/concepts/platforms).
+    platform. The documentation holds more [information about language specific configuration flags](/versions/8.2.1/concepts/platforms).
 -   You have to let the toolchain know where the tools live. In this tutorial
     there is a simplified version where you access the tools from the system. If
     you are interested in a more self-contained approach, you can read about
@@ -464,5 +462,4 @@ The key takeaways are:
 
 ## Further reading {#further-reading}
 
-For more details, see [C++ toolchain
-configuration](/versions/8.2.1/docs/cc-toolchain-config-reference)
\ No newline at end of file
+For more details, see [C++ toolchain configuration](/versions/8.2.1/docs/cc-toolchain-config-reference)
\ No newline at end of file
diff --git a/versions/8.3.1/about/roadmap.mdx b/versions/8.3.1/about/roadmap.mdx
index f36a5b4d..3c7f1fba 100644
--- a/versions/8.3.1/about/roadmap.mdx
+++ b/versions/8.3.1/about/roadmap.mdx
@@ -13,8 +13,7 @@ projects.
 
 ## Bazel 8.0 Release
 
-We plan to bring Bazel 8.0 [long term support
-(LTS)](https://bazel.build/release/versioning) to you in late 2024.
+We plan to bring Bazel 8.0 [long term support (LTS)](https://bazel.build/versions/8.3.1/release/versioning) to you in late 2024.
 The following features are planned to be implemented.
 
 ### Bzlmod: external dependency management system
@@ -29,8 +28,7 @@ support will be removed. Starting with Bazel 7.1, you can set
 `--noenable_workspace` to opt into the new behavior.
 
 Bazel 8.0 will contain a number of enhancements to
-[Bazel's external dependency management]
-(https://docs.google.com/document/d/1moQfNcEIttsk6vYanNKIy3ZuK53hQUFq1b1r0rmsYVg/edit#heading=h.lgyp7ubwxmjc)
+[Bazel's external dependency management](https://docs.google.com/document/d/1moQfNcEIttsk6vYanNKIy3ZuK53hQUFq1b1r0rmsYVg/edit#heading=h.lgyp7ubwxmjc)
 functionality, including:
 
 *   The new flag `--enable_workspace` can be set to `false` to completely
diff --git a/versions/8.3.1/basics/dependencies.mdx b/versions/8.3.1/basics/dependencies.mdx
index 206d99d5..0c178469 100644
--- a/versions/8.3.1/basics/dependencies.mdx
+++ b/versions/8.3.1/basics/dependencies.mdx
@@ -65,8 +65,7 @@ targets, we’ve made some strides in mitigating the downside by investing in
 tooling to automatically manage `BUILD` files to avoid burdening developers.
 
 Some of these tools, such as `buildifier` and `buildozer`, are available with
-Bazel in the [`buildtools`
-directory](https://github.com/bazelbuild/buildtools).
+Bazel in the [`buildtools` directory](https://github.com/bazelbuild/buildtools).
 
 ## Minimizing Module Visibility
 
@@ -106,8 +105,7 @@ transitive dependencies (Figure 1). Suppose target A depends on target B, which
 depends on a common library target C. Should target A be able to use classes
 defined in target C?
 
-[![Transitive
-dependencies](/versions/8.3.1/images/transitive-dependencies.png)](/versions/8.3.1/images/transitive-dependencies.png)
+[![Transitive dependencies](/versions/8.3.1/images/transitive-dependencies.png)](/versions/8.3.1/images/transitive-dependencies.png)
 
 **Figure 1**. Transitive dependencies
 
@@ -141,9 +139,7 @@ dependencies and adding them to a `BUILD` files without any developer
 intervention. But even without such tools, we’ve found the trade-off to be well
 worth it as the codebase scales: explicitly adding a dependency to `BUILD` file
 is a one-time cost, but dealing with implicit transitive dependencies can cause
-ongoing problems as long as the build target exists. Bazel [enforces strict
-transitive
-dependencies](https://blog.bazel.build/2017/06/28/sjd-unused_deps.html)
+ongoing problems as long as the build target exists. Bazel [enforces strict transitive dependencies](https://blog.bazel.build/2017/06/28/sjd-unused_deps.html)
 on Java code by default.
 
 ### External dependencies
@@ -192,8 +188,7 @@ so in theory there’s no reason that different versions of the same external
 dependency couldn’t both be declared in the build system under different names.
 That way, each target could choose which version of the dependency it wanted to
 use. This causes a lot of problems in practice, so Google enforces a strict
-[One-Version
-Rule](https://opensource.google/docs/thirdparty/oneversion/) for
+[One-Version Rule](https://opensource.google/docs/thirdparty/oneversion/) for
 all third-party dependencies in our codebase.
 
 The biggest problem with allowing multiple versions is the diamond dependency
@@ -232,8 +227,7 @@ Bazel did not use to automatically download transitive dependencies. It used to
 employ a `WORKSPACE` file that required all transitive dependencies to be
 listed, which led to a lot of pain when managing external dependencies. Bazel
 has since added support for automatic transitive external dependency management
-in the form of the `MODULE.bazel` file. See [external dependency
-overview](/versions/8.3.1/external/overview) for more details.
+in the form of the `MODULE.bazel` file. See [external dependency overview](/versions/8.3.1/external/overview) for more details.
 
 Yet again, the choice here is one between convenience and scalability. Small
 projects might prefer not having to worry about managing transitive dependencies
diff --git a/versions/8.3.1/community/images/Bitrise.png b/versions/8.3.1/community/images/Bitrise.png
new file mode 100644
index 00000000..07f85f1e
Binary files /dev/null and b/versions/8.3.1/community/images/Bitrise.png differ
diff --git a/versions/8.3.1/community/images/Gradle.png b/versions/8.3.1/community/images/Gradle.png
new file mode 100644
index 00000000..1e5f5eb0
Binary files /dev/null and b/versions/8.3.1/community/images/Gradle.png differ
diff --git a/versions/8.3.1/community/images/Linkedin-Logo.png b/versions/8.3.1/community/images/Linkedin-Logo.png
new file mode 100644
index 00000000..9dd8715c
Binary files /dev/null and b/versions/8.3.1/community/images/Linkedin-Logo.png differ
diff --git a/versions/8.3.1/community/images/Lucid_Software-logo.svg b/versions/8.3.1/community/images/Lucid_Software-logo.svg
new file mode 100644
index 00000000..6c8591e0
--- /dev/null
+++ b/versions/8.3.1/community/images/Lucid_Software-logo.svg
@@ -0,0 +1,16 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/versions/8.3.1/community/images/acqio_logo.svg b/versions/8.3.1/community/images/acqio_logo.svg
new file mode 100644
index 00000000..8fa11bcd
--- /dev/null
+++ b/versions/8.3.1/community/images/acqio_logo.svg
@@ -0,0 +1,60 @@
+
+
+
+
+
+	
+		
+			
+				
+					
+					
+					
+					
+					
+				
+				
+					
+						
+							
+								
+							
+						
+					
+				
+				
+					
+						
+							
+								
+							
+						
+					
+				
+			
+		
+	
+
+
diff --git a/versions/8.3.1/community/images/aspect-logo-2.png b/versions/8.3.1/community/images/aspect-logo-2.png
new file mode 100644
index 00000000..dfebc4cb
Binary files /dev/null and b/versions/8.3.1/community/images/aspect-logo-2.png differ
diff --git a/versions/8.3.1/community/images/bitrise-logo.png b/versions/8.3.1/community/images/bitrise-logo.png
new file mode 100644
index 00000000..27037ce6
Binary files /dev/null and b/versions/8.3.1/community/images/bitrise-logo.png differ
diff --git a/versions/8.3.1/community/images/buildbuddy-logo.svg b/versions/8.3.1/community/images/buildbuddy-logo.svg
new file mode 100644
index 00000000..bdb72dc6
--- /dev/null
+++ b/versions/8.3.1/community/images/buildbuddy-logo.svg
@@ -0,0 +1,11 @@
+
+
+
+
+
+
+
+
+
+
+
diff --git a/versions/8.3.1/community/images/buildkite.svg b/versions/8.3.1/community/images/buildkite.svg
new file mode 100644
index 00000000..209a4ab1
--- /dev/null
+++ b/versions/8.3.1/community/images/buildkite.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/8.3.1/community/images/codethink-logo.svg b/versions/8.3.1/community/images/codethink-logo.svg
new file mode 100644
index 00000000..406005d8
--- /dev/null
+++ b/versions/8.3.1/community/images/codethink-logo.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/8.3.1/community/images/develocity.png b/versions/8.3.1/community/images/develocity.png
new file mode 100644
index 00000000..eb3eb65a
Binary files /dev/null and b/versions/8.3.1/community/images/develocity.png differ
diff --git a/versions/8.3.1/community/images/dropbox.png b/versions/8.3.1/community/images/dropbox.png
new file mode 100644
index 00000000..125476a6
Binary files /dev/null and b/versions/8.3.1/community/images/dropbox.png differ
diff --git a/versions/8.3.1/community/images/engflow-logo.svg b/versions/8.3.1/community/images/engflow-logo.svg
new file mode 100644
index 00000000..e5f0c343
--- /dev/null
+++ b/versions/8.3.1/community/images/engflow-logo.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/8.3.1/community/images/epam-logo.png b/versions/8.3.1/community/images/epam-logo.png
new file mode 100644
index 00000000..e6a5674c
Binary files /dev/null and b/versions/8.3.1/community/images/epam-logo.png differ
diff --git a/versions/8.3.1/community/images/flare-logo.png b/versions/8.3.1/community/images/flare-logo.png
new file mode 100644
index 00000000..84cb0e5b
Binary files /dev/null and b/versions/8.3.1/community/images/flare-logo.png differ
diff --git a/versions/8.3.1/community/images/hermetiq-logo.png b/versions/8.3.1/community/images/hermetiq-logo.png
new file mode 100644
index 00000000..90765d96
Binary files /dev/null and b/versions/8.3.1/community/images/hermetiq-logo.png differ
diff --git a/versions/8.3.1/community/images/jetbrains.svg b/versions/8.3.1/community/images/jetbrains.svg
new file mode 100644
index 00000000..cb3a2a0e
--- /dev/null
+++ b/versions/8.3.1/community/images/jetbrains.svg
@@ -0,0 +1,13 @@
+
+  
+    
+      
+      
+      
+    
+  
+  
+  
+  
+  
+
diff --git a/versions/8.3.1/community/images/liulishuo.png b/versions/8.3.1/community/images/liulishuo.png
new file mode 100644
index 00000000..a6758e5c
Binary files /dev/null and b/versions/8.3.1/community/images/liulishuo.png differ
diff --git a/versions/8.3.1/community/images/nativelink.svg b/versions/8.3.1/community/images/nativelink.svg
new file mode 100644
index 00000000..148fcdce
--- /dev/null
+++ b/versions/8.3.1/community/images/nativelink.svg
@@ -0,0 +1,1123 @@
+
+
+  
+    
+    
+      
+      
+    
+    
+      
+      
+    
+    
+    
+      
+      
+    
+    
+      
+      
+      
+      
+      
+      
+      
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+      
+      
+    
+    
+    
+    
+      
+      
+    
+    
+    
+    
+      
+      
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+      
+      
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+      
+      
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+      
+      
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+      
+      
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+      
+      
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+      
+      
+    
+  
+  
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+  
+  
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+  
+
diff --git a/versions/8.3.1/community/images/oasis-logo.png b/versions/8.3.1/community/images/oasis-logo.png
new file mode 100644
index 00000000..846a9cd5
Binary files /dev/null and b/versions/8.3.1/community/images/oasis-logo.png differ
diff --git a/versions/8.3.1/community/images/sumglobal-logo.png b/versions/8.3.1/community/images/sumglobal-logo.png
new file mode 100644
index 00000000..6736328d
Binary files /dev/null and b/versions/8.3.1/community/images/sumglobal-logo.png differ
diff --git a/versions/8.3.1/community/images/trunk-logo-dark.svg b/versions/8.3.1/community/images/trunk-logo-dark.svg
new file mode 100644
index 00000000..f25940af
--- /dev/null
+++ b/versions/8.3.1/community/images/trunk-logo-dark.svg
@@ -0,0 +1,22 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/versions/8.3.1/community/images/tweag-logo.png b/versions/8.3.1/community/images/tweag-logo.png
new file mode 100644
index 00000000..20210ed7
Binary files /dev/null and b/versions/8.3.1/community/images/tweag-logo.png differ
diff --git a/versions/8.3.1/community/images/typedb.png b/versions/8.3.1/community/images/typedb.png
new file mode 100644
index 00000000..48ce1056
Binary files /dev/null and b/versions/8.3.1/community/images/typedb.png differ
diff --git a/versions/8.3.1/community/images/virtuslab.svg b/versions/8.3.1/community/images/virtuslab.svg
new file mode 100644
index 00000000..6fba0316
--- /dev/null
+++ b/versions/8.3.1/community/images/virtuslab.svg
@@ -0,0 +1,20 @@
+
+
+  
+    
+  
+  
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+  
+
diff --git a/versions/8.3.1/community/roadmaps-configurability.mdx b/versions/8.3.1/community/roadmaps-configurability.mdx
index 82422d88..ce4ec866 100644
--- a/versions/8.3.1/community/roadmaps-configurability.mdx
+++ b/versions/8.3.1/community/roadmaps-configurability.mdx
@@ -26,8 +26,7 @@ title: 'Bazel Configurability 2021 Roadmap'
 * Builds scale well, particularly w.r.t graph size and action caching.
 
 We also support
-[`cquery`](https://bazel.build/versions/8.3.1/query/cquery), [`Starlark
-configuration`](https://bazel.build/extending/config),
+[`cquery`](https://bazel.build/versions/8.3.1/query/cquery), [`Starlark configuration`](https://bazel.build/versions/8.3.1/extending/config),
 and
 [`select()`](https://bazel.build/versions/8.3.1/docs/configurable-attributes).
 
@@ -41,15 +40,13 @@ interest of accurate expectations.
 ### Platforms
 
 

-Q3 2021**Android rules use the new [platforms
-API](https://bazel.build/concepts/platforms)**
+Q3 2021**Android rules use the new [platforms API](https://bazel.build/versions/8.3.1/concepts/platforms)**
 IN PROGRESS ([#11749](https://github.com/bazelbuild/bazel/issues/11749))
 
 * This is our main priority for the beginning of 2021.
 
 

-Q3 2021**Builds support [multiple execution
-platforms](https://docs.google.com/document/d/1U9HzdDmtRnm244CaRM6JV-q2408mbNODAMewcGjnnbM/)**
+Q3 2021**Builds support [multiple execution platforms](https://docs.google.com/document/d/1U9HzdDmtRnm244CaRM6JV-q2408mbNODAMewcGjnnbM/)**
 IN PROGRESS ([#11748](https://github.com/bazelbuild/bazel/issues/11748))
 
 

diff --git a/versions/8.3.1/community/sig.mdx b/versions/8.3.1/community/sig.mdx
index 02c15497..9bde03d5 100644
--- a/versions/8.3.1/community/sig.mdx
+++ b/versions/8.3.1/community/sig.mdx
@@ -3,8 +3,7 @@ title: 'Bazel Special Interest Groups'
 ---
 
 Bazel hosts Special Interest Groups (SIGs) to focus collaboration on particular
-areas and to support communication and coordination between [Bazel owners,
-maintainers, and contributors](/versions/8.3.1/contribute/policy). This policy
+areas and to support communication and coordination between [Bazel owners, maintainers, and contributors](/versions/8.3.1/contribute/policy). This policy
 applies to [`bazelbuild`](http://github.com/bazelbuild).
 
 SIGs do their work in public. The ideal scope for a SIG covers a well-defined
diff --git a/versions/8.3.1/community/users.mdx b/versions/8.3.1/community/users.mdx
index 9ab2ef1f..ff669ef3 100644
--- a/versions/8.3.1/community/users.mdx
+++ b/versions/8.3.1/community/users.mdx
@@ -304,11 +304,9 @@ safety systems_.
 Pigweed is an open-source solution for sustained, robust, and rapid embedded
 product development for large teams. Pigweed has shipped in millions of
 devices, including Google's suite of Pixel devices, Nest thermostats,
-[satellites](https://www.spinlaunch.com/), and [autonomous aerial
-drones](https://www.flyzipline.com/).
+[satellites](https://www.spinlaunch.com/), and [autonomous aerial drones](https://www.flyzipline.com/).
 
-Pigweed [uses Bazel as its primary build
-system](https://pigweed.dev/seed/0111-build-systems.html). The [Bazel for
+Pigweed [uses Bazel as its primary build system](https://pigweed.dev/seed/0111-build-systems.html). The [Bazel for
 Embedded][pw-bazel-great] blog post discusses why we think it's a great build
 system for embedded projects!
 
diff --git a/versions/8.3.1/concepts/build-ref.mdx b/versions/8.3.1/concepts/build-ref.mdx
index 2dac5555..6e6ecbd0 100644
--- a/versions/8.3.1/concepts/build-ref.mdx
+++ b/versions/8.3.1/concepts/build-ref.mdx
@@ -17,8 +17,7 @@ its root; such a boundary marker file could be `MODULE.bazel`, `REPO.bazel`, or
 in legacy contexts, `WORKSPACE` or `WORKSPACE.bazel`.
 
 The repo in which the current Bazel command is being run is called the _main
-repo_. Other, (external) repos are defined by _repo rules_; see [external
-dependencies overview](/versions/8.3.1/external/overview) for more information.
+repo_. Other, (external) repos are defined by _repo rules_; see [external dependencies overview](/versions/8.3.1/external/overview) for more information.
 
 ## Workspace {#workspace}
 
@@ -95,5 +94,4 @@ have three properties: the list of packages they contain, their name, and other
 package groups they include. The only allowed ways to refer to them are from the
 `visibility` attribute of rules or from the `default_visibility` attribute of
 the `package` function; they do not generate or consume files. For more
-information, refer to the [`package_group`
-documentation](/versions/8.3.1/reference/be/functions#package_group).
+information, refer to the [`package_group` documentation](/versions/8.3.1/reference/be/functions#package_group).
diff --git a/versions/8.3.1/concepts/labels.mdx b/versions/8.3.1/concepts/labels.mdx
index b05be33c..3addec7a 100644
--- a/versions/8.3.1/concepts/labels.mdx
+++ b/versions/8.3.1/concepts/labels.mdx
@@ -10,8 +10,7 @@ form looks like:
 ```
 
 The first part of the label is the repository name, `@@myrepo`. The double-`@`
-syntax signifies that this is a [*canonical* repo
-name](/versions/8.3.1/external/overview#canonical-repo-name), which is unique within
+syntax signifies that this is a [*canonical* repo name](/versions/8.3.1/external/overview#canonical-repo-name), which is unique within
 the workspace. Labels with canonical repo names unambiguously identify a target
 no matter which context they appear in.
 
diff --git a/versions/8.3.1/concepts/platforms.mdx b/versions/8.3.1/concepts/platforms.mdx
index e2ea73c7..034dc411 100644
--- a/versions/8.3.1/concepts/platforms.mdx
+++ b/versions/8.3.1/concepts/platforms.mdx
@@ -77,8 +77,7 @@ To test your Android project with platforms, see
 for support.
 
 You can still use platform APIs with Apple builds (for example, when building
-with a mixture of Apple rules and pure C++) with [platform
-mappings](#platform-mappings).
+with a mixture of Apple rules and pure C++) with [platform mappings](#platform-mappings).
 
 ### Other languages {#other-languages}
 
@@ -241,8 +240,7 @@ sets `--cpu`, `--crossstool_top`, or other legacy flags, rules that read
 
 When migrating your project to platforms, you must either convert changes like
 `return { "//command_line_option:cpu": "arm" }` to `return {
-"//command_line_option:platforms": "//:my_arm_platform" }` or use [platform
-mappings](#platform-mappings) to support both styles during migration.
+"//command_line_option:platforms": "//:my_arm_platform" }` or use [platform mappings](#platform-mappings) to support both styles during migration.
 window.
 
 ## Migrating your rule set {#migrating-your-rule-set}
@@ -361,10 +359,8 @@ attributes declare a language's tools (like `compiler =
 this information to rules that need to build with these tools.
 
 Toolchains declare the `constraint_value`s of machines they can
-[target][target_compatible_with Attribute]
-(`target_compatible_with = ["@platforms//os:linux"]`) and machines their tools can
-[run on][exec_compatible_with Attribute]
-(`exec_compatible_with = ["@platforms//os:mac"]`).
+[target][target_compatible_with Attribute](`target_compatible_with = ["@platforms//os:linux"]`) and machines their tools can
+[run on][exec_compatible_with Attribute](`exec_compatible_with = ["@platforms//os:mac"]`).
 
 When building `$ bazel build //:myproject --platforms=//:myplatform`, Bazel
 automatically selects a toolchain that can run on the build machine and
diff --git a/versions/8.3.1/configure/attributes.mdx b/versions/8.3.1/configure/attributes.mdx
index e69c40b6..cc1a8e45 100644
--- a/versions/8.3.1/configure/attributes.mdx
+++ b/versions/8.3.1/configure/attributes.mdx
@@ -2,8 +2,7 @@
 title: 'Configurable Build Attributes'
 ---
 
-**_Configurable attributes_**, commonly known as [`select()`](
-/reference/be/functions#select), is a Bazel feature that lets users toggle the values
+**_Configurable attributes_**, commonly known as [`select()`](/versions/8.3.1/reference/be/functions#select), is a Bazel feature that lets users toggle the values
 of build rule attributes at the command line.
 
 This can be used, for example, for a multiplatform library that automatically
@@ -407,8 +406,7 @@ sh_library(
 )
 ```
 
-If you need a `select` to match when multiple conditions match, consider [AND
-chaining](#and-chaining).
+If you need a `select` to match when multiple conditions match, consider [AND chaining](#and-chaining).
 
 ## OR chaining {#or-chaining}
 
diff --git a/versions/8.3.1/configure/integrate-cpp.mdx b/versions/8.3.1/configure/integrate-cpp.mdx
index 3285d0eb..b6fbd806 100644
--- a/versions/8.3.1/configure/integrate-cpp.mdx
+++ b/versions/8.3.1/configure/integrate-cpp.mdx
@@ -33,8 +33,7 @@ This is because when writing our own actions, they must behave
 consistently with the C++ toolchain - for example, passing C++ command line
 flags to a tool that invokes the C++ compiler behind the scenes.
 
-C++ rules use a special way of constructing command lines based on [feature
-configuration](/versions/8.3.1/docs/cc-toolchain-config-reference). To construct a command line,
+C++ rules use a special way of constructing command lines based on [feature configuration](/versions/8.3.1/docs/cc-toolchain-config-reference). To construct a command line,
 you need the following:
 
 * `features` and `action_configs` - these come from the `CcToolchainConfigInfo`
diff --git a/versions/8.3.1/configure/windows.mdx b/versions/8.3.1/configure/windows.mdx
index d7ec8c08..565de620 100644
--- a/versions/8.3.1/configure/windows.mdx
+++ b/versions/8.3.1/configure/windows.mdx
@@ -166,8 +166,7 @@ To build C++ targets with MSVC, you need:
         set BAZEL_VC=C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC
         ```
 
-*   The [Windows
-    SDK](https://developer.microsoft.com/en-us/windows/downloads/windows-10-sdk).
+*   The [Windows SDK](https://developer.microsoft.com/en-us/windows/downloads/windows-10-sdk).
 
     The Windows SDK contains header files and libraries you need when building
     Windows applications, including Bazel itself. By default, the latest Windows SDK installed will
@@ -186,8 +185,7 @@ To build C++ targets with MSVC, you need:
 
 If everything is set up, you can build a C++ target now!
 
-Try building a target from one of our [sample
-projects](https://github.com/bazelbuild/bazel/tree/master/examples):
+Try building a target from one of our [sample projects](https://github.com/bazelbuild/bazel/tree/master/examples):
 
 
 
 
-To build and use Dynamically Linked Libraries (DLL files), see [this
-example](https://github.com/bazelbuild/bazel/tree/master/examples/windows/dll).
+To build and use Dynamically Linked Libraries (DLL files), see [this example](https://github.com/bazelbuild/bazel/tree/master/examples/windows/dll).
 
 **Command Line Length Limit**: To prevent the
 [Windows command line length limit issue](https://github.com/bazelbuild/bazel/issues/5163),
@@ -292,8 +289,7 @@ On Windows, Bazel builds two output files for `java_binary` rules:
 *   a `.jar` file
 *   a `.exe` file that can set up the environment for the JVM and run the binary
 
-Try building a target from one of our [sample
-projects](https://github.com/bazelbuild/bazel/tree/master/examples):
+Try building a target from one of our [sample projects](https://github.com/bazelbuild/bazel/tree/master/examples):
 
 
   
   
 
 If you are interested in details about how Bazel builds Python targets on
-Windows, check out this [design
-doc](https://github.com/bazelbuild/bazel-website/blob/master/designs/_posts/2016-09-05-build-python-on-windows.md).
+Windows, check out this [design doc](https://github.com/bazelbuild/bazel-website/blob/master/designs/_posts/2016-09-05-build-python-on-windows.md).
diff --git a/versions/8.3.1/contribute/breaking-changes.mdx b/versions/8.3.1/contribute/breaking-changes.mdx
index 3a47a53c..5f7a998a 100644
--- a/versions/8.3.1/contribute/breaking-changes.mdx
+++ b/versions/8.3.1/contribute/breaking-changes.mdx
@@ -67,7 +67,7 @@ should contain the URL of the GitHub issue. As the flag name starts with
 ```
 
 In the commit description, add a brief summary of the flag.
-Also add [`RELNOTES:`](release-notes.md) in the following form:
+Also add [`RELNOTES:`](/versions/8.3.1/contribute/release-notes) in the following form:
 `RELNOTES: --incompatible_name_of_flag has been added. See #xyz for details`
 
 The commit should also update the relevant documentation, so that there is no
diff --git a/versions/8.3.1/contribute/codebase.mdx b/versions/8.3.1/contribute/codebase.mdx
index 8e403a32..6b03e1f6 100644
--- a/versions/8.3.1/contribute/codebase.mdx
+++ b/versions/8.3.1/contribute/codebase.mdx
@@ -227,8 +227,7 @@ repository", the others are called "external repositories".
 A repository is marked by a repo boundary file (`MODULE.bazel`, `REPO.bazel`, or
 in legacy contexts, `WORKSPACE` or `WORKSPACE.bazel`) in its root directory. The
 main repo is the source tree where you're invoking Bazel from. External repos
-are defined in various ways; see [external dependencies
-overview](/versions/8.3.1/external/overview) for more information.
+are defined in various ways; see [external dependencies overview](/versions/8.3.1/external/overview) for more information.
 
 Code of external repositories is symlinked or downloaded under
 `$OUTPUT_BASE/external`.
diff --git a/versions/8.3.1/contribute/design-documents.mdx b/versions/8.3.1/contribute/design-documents.mdx
index 69e3ff86..b723e9d7 100644
--- a/versions/8.3.1/contribute/design-documents.mdx
+++ b/versions/8.3.1/contribute/design-documents.mdx
@@ -25,7 +25,7 @@ Here are some examples of significant changes:
 When you write a design document, you can coordinate with other Bazel developers
 and seek guidance from Bazel's core team. For example, when a proposal adds,
 removes, or modifies any function or object available in BUILD, MODULE.bazel, or
-bzl files, add the [Starlark team](maintainers-guide.md) as reviewers.
+bzl files, add the [Starlark team](/versions/8.3.1/contribute/maintainers-guide) as reviewers.
 Design documents are reviewed before submission because:
 
 *   Bazel is a very complex system; seemingly innocuous local changes can have
@@ -137,8 +137,7 @@ A lead reviewer should be a domain expert who is:
 *   Objective and capable of providing constructive feedback
 *   Available for the entire review period to lead the process
 
-Consider checking the contacts for various [team
-labels](/versions/8.3.1/contribute/maintainers-guide#team-labels).
+Consider checking the contacts for various [team labels](/versions/8.3.1/contribute/maintainers-guide#team-labels).
 
 ## Markdown vs Google Docs {#markdown-versus-gdocs}
 
@@ -168,12 +167,10 @@ Markdown for posterity.
 
 ### Using Google Docs {#gdocs}
 
-For consistency, use the [Bazel design doc template](
-https://docs.google.com/document/d/1cE5zrjrR40RXNg64XtRFewSv6FrLV6slGkkqxBumS1w/edit).
+For consistency, use the [Bazel design doc template](https://docs.google.com/document/d/1cE5zrjrR40RXNg64XtRFewSv6FrLV6slGkkqxBumS1w/edit).
 It includes the necessary header and creates visual
 consistency with other Bazel related documents. To do that, click on **File** >
-**Make a copy** or click this link to [make a copy of the design doc
-template](https://docs.google.com/document/d/1cE5zrjrR40RXNg64XtRFewSv6FrLV6slGkkqxBumS1w/copy).
+**Make a copy** or click this link to [make a copy of the design doc template](https://docs.google.com/document/d/1cE5zrjrR40RXNg64XtRFewSv6FrLV6slGkkqxBumS1w/copy).
 
 To make your document readable to the world, click on
 **Share** > **Advanced** > **Change…**, and
diff --git a/versions/8.3.1/contribute/images/structured-concurrency-3d.svg b/versions/8.3.1/contribute/images/structured-concurrency-3d.svg
new file mode 100644
index 00000000..accbb42a
--- /dev/null
+++ b/versions/8.3.1/contribute/images/structured-concurrency-3d.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/8.3.1/contribute/images/structured-concurrency.svg b/versions/8.3.1/contribute/images/structured-concurrency.svg
new file mode 100644
index 00000000..0258d9a9
--- /dev/null
+++ b/versions/8.3.1/contribute/images/structured-concurrency.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/8.3.1/contribute/images/suspend-resume.svg b/versions/8.3.1/contribute/images/suspend-resume.svg
new file mode 100644
index 00000000..7de1218f
--- /dev/null
+++ b/versions/8.3.1/contribute/images/suspend-resume.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/8.3.1/contribute/images/unstructured-concurrency.svg b/versions/8.3.1/contribute/images/unstructured-concurrency.svg
new file mode 100644
index 00000000..0951639a
--- /dev/null
+++ b/versions/8.3.1/contribute/images/unstructured-concurrency.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/8.3.1/contribute/index.mdx b/versions/8.3.1/contribute/index.mdx
index 8f99cfae..2e243a53 100644
--- a/versions/8.3.1/contribute/index.mdx
+++ b/versions/8.3.1/contribute/index.mdx
@@ -10,8 +10,7 @@ As you use Bazel, you may find things that can be improved.
 You can help by [reporting issues](http://github.com/bazelbuild/bazel/issues)
 when:
 
-   - Bazel crashes or you encounter a bug that can [only be resolved using `bazel
-     clean`](/versions/8.3.1/run/build#correct-incremental-rebuilds).
+   - Bazel crashes or you encounter a bug that can [only be resolved using `bazel clean`](/versions/8.3.1/run/build#correct-incremental-rebuilds).
    - The documentation is incomplete or unclear. You can also report issues
      from the page you are viewing by using the "Create issue"
      link at the top right corner of the page.
@@ -21,11 +20,9 @@ when:
 
 You can engage with the Bazel community by:
 
-   - Answering questions [on Stack Overflow](
-     https://stackoverflow.com/questions/tagged/bazel).
+   - Answering questions [on Stack Overflow](https://stackoverflow.com/questions/tagged/bazel).
    - Helping other users [on Slack](https://slack.bazel.build).
-   - Improving documentation or [contributing examples](
-     https://github.com/bazelbuild/examples).
+   - Improving documentation or [contributing examples](https://github.com/bazelbuild/examples).
    - Sharing your experience or your tips, for example, on a blog or social media.
 
 ## Contribute code {#contribute-code}
@@ -40,8 +37,7 @@ You can contribute to the Bazel ecosystem by:
    - Contributing to Bazel-related tools, for example, migration tools.
    - Improving Bazel integration with other IDEs and tools.
 
-Before making a change, [create a GitHub
-issue](http://github.com/bazelbuild/bazel/issues)
+Before making a change, [create a GitHub issue](http://github.com/bazelbuild/bazel/issues)
 or email [bazel-discuss@](mailto:bazel-discuss@googlegroups.com).
 
 The most helpful contributions fix bugs or add features (as opposed
diff --git a/versions/8.3.1/contribute/maintainers-guide.mdx b/versions/8.3.1/contribute/maintainers-guide.mdx
index 59789908..7f94e69b 100644
--- a/versions/8.3.1/contribute/maintainers-guide.mdx
+++ b/versions/8.3.1/contribute/maintainers-guide.mdx
@@ -4,8 +4,7 @@ title: 'Guide for Bazel Maintainers'
 
 This is a guide for the maintainers of the Bazel open source project.
 
-If you are looking to contribute to Bazel, please read [Contributing to
-Bazel](/versions/8.3.1/contribute) instead.
+If you are looking to contribute to Bazel, please read [Contributing to Bazel](/versions/8.3.1/contribute) instead.
 
 The objectives of this page are to:
 
@@ -37,8 +36,7 @@ repository.
 
 1. A user creates an issue by choosing one of the
 [issue templates](https://github.com/bazelbuild/bazel/issues/new/choose)
-   and it enters the pool of [unreviewed open
-   issues](https://github.com/bazelbuild/bazel/issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aopen+-label%3Auntriaged+-label%3Ap2+-label%3Ap1+-label%3Ap3+-label%3Ap4+-label%3Ateam-Starlark+-label%3Ateam-Rules-CPP+-label%3Ateam-Rules-Java+-label%3Ateam-XProduct+-label%3Ateam-Android+-label%3Ateam-Apple+-label%3Ateam-Configurability++-label%3Ateam-Performance+-label%3Ateam-Rules-Server+-label%3Ateam-Core+-label%3Ateam-Rules-Python+-label%3Ateam-Remote-Exec+-label%3Ateam-Local-Exec+-label%3Ateam-Bazel).
+   and it enters the pool of [unreviewed open issues](https://github.com/bazelbuild/bazel/issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aopen+-label%3Auntriaged+-label%3Ap2+-label%3Ap1+-label%3Ap3+-label%3Ap4+-label%3Ateam-Starlark+-label%3Ateam-Rules-CPP+-label%3Ateam-Rules-Java+-label%3Ateam-XProduct+-label%3Ateam-Android+-label%3Ateam-Apple+-label%3Ateam-Configurability++-label%3Ateam-Performance+-label%3Ateam-Rules-Server+-label%3Ateam-Core+-label%3Ateam-Rules-Python+-label%3Ateam-Remote-Exec+-label%3Ateam-Local-Exec+-label%3Ateam-Bazel).
 1. A member on the Developer Experience (DevEx) subteam rotation reviews the
    issue.
    1. If the issue is **not a bug** or a **feature request**, the DevEx member
@@ -58,21 +56,18 @@ repository.
 1. After reviewing the issue, the DevEx member decides if the issue requires
    immediate attention. If it does, they will assign the **P0**
    [priority](#priority) label and an owner from the list of team leads.
-1. The DevEx member assigns the `untriaged` label and exactly one [team
-   label](#team-labels) for routing.
+1. The DevEx member assigns the `untriaged` label and exactly one [team label](#team-labels) for routing.
 1. The DevEx member also assigns exactly one `type:` label, such as `type: bug`
    or `type: feature request`, according to the type of the issue.
 1. For platform-specific issues, the DevEx member assigns one `platform:` label,
    such as `platform:apple` for Mac-specific issues.
 1. If the issue is low priority and can be worked on by a new community
    contributor, the DevEx member assigns the `good first issue` label.
-At this stage, the issue enters the pool of [untriaged open
-issues](https://github.com/bazelbuild/bazel/issues?q=is%3Aissue+is%3Aopen+label%3Auntriaged).
+At this stage, the issue enters the pool of [untriaged open issues](https://github.com/bazelbuild/bazel/issues?q=is%3Aissue+is%3Aopen+label%3Auntriaged).
 
 Each Bazel subteam will triage all issues under labels they own, preferably on a
 weekly basis. The subteam will review and evaluate the issue and provide a
-resolution, if possible. If you are an owner of a team label, see [this section
-](#label-own) for more information.
+resolution, if possible. If you are an owner of a team label, see [this section](#label-own) for more information.
 
 When an issue is resolved, it can be closed.
 
@@ -111,8 +106,7 @@ preferably on a weekly basis.
      issue is either P0 or P1 we assume that is actively worked on.
 1. Remove the `untriaged` label.
 
-Note that you need to be in the [bazelbuild
-organization](https://github.com/bazelbuild) to be able to add or remove labels.
+Note that you need to be in the [bazelbuild organization](https://github.com/bazelbuild) to be able to add or remove labels.
 
 ### Pull Requests {#pull-requests}
 
@@ -138,8 +132,7 @@ issues.
   unusable, or a downed service that severely impacts development of the Bazel
   project. This includes regressions introduced in a new release that blocks a
   significant number of users, or an incompatible breaking change that was not
-  compliant to the [Breaking
-  Change](https://docs.google.com/document/d/1q5GGRxKrF_mnwtaPKI487P8OdDRh2nN7jX6U-FXnHL0/edit?pli=1#heading=h.ceof6vpkb3ik)
+  compliant to the [Breaking Change](https://docs.google.com/document/d/1q5GGRxKrF_mnwtaPKI487P8OdDRh2nN7jX6U-FXnHL0/edit?pli=1#heading=h.ceof6vpkb3ik)
   policy. No practical workaround exists.
 * [**P1**](https://github.com/bazelbuild/bazel/labels/P1) - Critical defect or
   feature which should be addressed in the next release, or a serious issue that
diff --git a/versions/8.3.1/contribute/naming.mdx b/versions/8.3.1/contribute/naming.mdx
index 5be66542..232ab686 100644
--- a/versions/8.3.1/contribute/naming.mdx
+++ b/versions/8.3.1/contribute/naming.mdx
@@ -4,8 +4,7 @@ title: 'Naming a Bazel related project'
 
 First, thank you for contributing to the Bazel ecosystem! Please reach out to
 the Bazel community on the
-[bazel-discuss mailing list](https://groups.google.com/forum/#!forum/bazel-discuss
-) to share your project and its suggested name.
+[bazel-discuss mailing list](https://groups.google.com/forum/#!forum/bazel-discuss) to share your project and its suggested name.
 
 If you are building a Bazel related tool or sharing your Skylark rules,
 we recommend following these guidelines for the name of your project:
diff --git a/versions/8.3.1/contribute/patch-acceptance.mdx b/versions/8.3.1/contribute/patch-acceptance.mdx
index f2ed8ad5..c97e11cf 100644
--- a/versions/8.3.1/contribute/patch-acceptance.mdx
+++ b/versions/8.3.1/contribute/patch-acceptance.mdx
@@ -11,29 +11,24 @@ code base.
    need a corresponding issue for tracking.
 1. If you're proposing significant changes, write a
    [design document](/versions/8.3.1/contribute/design-documents).
-1. Ensure you've signed a [Contributor License
-   Agreement](https://cla.developers.google.com).
+1. Ensure you've signed a [Contributor License Agreement](https://cla.developers.google.com).
 1. Prepare a git commit that implements the feature. Don't forget to add tests
    and update the documentation. If your change has user-visible effects, please
    [add release notes](/versions/8.3.1/contribute/release-notes). If it is an incompatible change,
    read the [guide for rolling out breaking changes](/versions/8.3.1/contribute/breaking-changes).
 1. Create a pull request on
    [GitHub](https://github.com/bazelbuild/bazel/pulls). If you're new to GitHub,
-   read [about pull
-   requests](https://help.github.com/articles/about-pull-requests/). Note that
+   read [about pull requests](https://help.github.com/articles/about-pull-requests/). Note that
    we restrict permissions to create branches on the main Bazel repository, so
-   you will need to push your commit to [your own fork of the
-   repository](https://help.github.com/articles/working-with-forks/).
+   you will need to push your commit to [your own fork of the repository](https://help.github.com/articles/working-with-forks/).
 1. A Bazel maintainer should assign you a reviewer within two business days
    (excluding holidays in the USA and Germany). If you aren't assigned a
    reviewer in that time, you can request one by emailing
-   [bazel-discuss@googlegroups.com]
-   (mailto:bazel-discuss@googlegroups.com).
+   [bazel-discuss@googlegroups.com](mailto:bazel-discuss@googlegroups.com).
 1. Work with the reviewer to complete a code review. For each change, create a
    new commit and push it to make changes to your pull request. If the review
    takes too long (for instance, if the reviewer is unresponsive), send an email to
-   [bazel-discuss@googlegroups.com]
-   (mailto:bazel-discuss@googlegroups.com).
+   [bazel-discuss@googlegroups.com](mailto:bazel-discuss@googlegroups.com).
 1. After your review is complete, a Bazel maintainer applies your patch to
    Google's internal version control system.
 
diff --git a/versions/8.3.1/contribute/release-notes.mdx b/versions/8.3.1/contribute/release-notes.mdx
index 751b9f0c..3c3f0d68 100644
--- a/versions/8.3.1/contribute/release-notes.mdx
+++ b/versions/8.3.1/contribute/release-notes.mdx
@@ -16,8 +16,7 @@ the release announcement.
 * If the change adds / removes / changes Bazel in a user-visible way, then it
   may be advantageous to mention it.
 
-If the change is significant, follow the [design document
-policy](/versions/8.3.1/contribute/design-documents) first.
+If the change is significant, follow the [design document policy](/versions/8.3.1/contribute/design-documents) first.
 
 ## Guidelines {#guidelines}
 
@@ -60,10 +59,8 @@ change is about.
 
 ## Process {#process}
 
-As part of the [release
-process](https://github.com/bazelbuild/continuous-integration/blob/master/docs/release-playbook.md),
-we collect the `RELNOTES` tags of every commit. We copy everything in a [Google
-Doc](https://docs.google.com/document/d/1wDvulLlj4NAlPZamdlEVFORks3YXJonCjyuQMUQEmB0/edit)
+As part of the [release process](https://github.com/bazelbuild/continuous-integration/blob/master/docs/release-playbook.md),
+we collect the `RELNOTES` tags of every commit. We copy everything in a [Google Doc](https://docs.google.com/document/d/1wDvulLlj4NAlPZamdlEVFORks3YXJonCjyuQMUQEmB0/edit)
 where we review, edit, and organize the notes.
 
 The release manager sends an email to the
@@ -71,6 +68,4 @@ The release manager sends an email to the
 Bazel contributors are invited to contribute to the document and make sure
 their changes are correctly reflected in the announcement.
 
-Later, the announcement will be submitted to the [Bazel
-blog](https://blog.bazel.build/), using the [bazel-blog
-repository](https://github.com/bazelbuild/bazel-blog/tree/master/_posts).
+Later, the announcement will be submitted to the [Bazel blog](https://blog.bazel.build/), using the [bazel-blog repository](https://github.com/bazelbuild/bazel-blog/tree/master/_posts).
diff --git a/versions/8.3.1/contribute/statemachine-guide.mdx b/versions/8.3.1/contribute/statemachine-guide.mdx
index 521201dd..f39faaab 100644
--- a/versions/8.3.1/contribute/statemachine-guide.mdx
+++ b/versions/8.3.1/contribute/statemachine-guide.mdx
@@ -172,8 +172,7 @@ instead, batches[^4] as many lookups as possible before doing so. The value
 might not be immediately available, for example, requiring a Skyframe restart,
 so the caller specifies what to do with the resulting value using a callback.
 
-The `StateMachine` processor ([`Driver`s and bridging to
-SkyFrame](#drivers-and-bridging)) guarantees that the value is available before
+The `StateMachine` processor ([`Driver`s and bridging to SkyFrame](#drivers-and-bridging)) guarantees that the value is available before
 the next state begins. An example follows.
 
 ```
@@ -284,8 +283,7 @@ and solutions to certain control flow problems.
 ### Sequential states
 
 This is the most common and straightforward control flow pattern. An example of
-this is shown in [Stateful computations inside
-`SkyKeyComputeState`](#stateful-computations).
+this is shown in [Stateful computations inside `SkyKeyComputeState`](#stateful-computations).
 
 ### Branching
 
@@ -545,8 +543,7 @@ section describes the propagation of data values.
 
 ### Implementing `Tasks.lookUp` callbacks
 
-There’s an example of implementing a `Tasks.lookUp` callback in [SkyValue
-lookups](#skyvalue-lookups). This section provides rationale and suggests
+There’s an example of implementing a `Tasks.lookUp` callback in [SkyValue lookups](#skyvalue-lookups). This section provides rationale and suggests
 approaches for handling multiple SkyValues.
 
 #### `Tasks.lookUp` callbacks {#tasks-lookup-callbacks}
@@ -710,8 +707,7 @@ class BarProducer implements StateMachine {
 Tip: It would be tempting to use the more concise signature void `accept(Bar
 value)` rather than the stuttery `void acceptBarValue(Bar value)` above.
 However, `Consumer` is a common overload of `void accept(Bar value)`,
-so doing this often leads to violations of the [Overloads: never
-split](https://google.github.io/styleguide/javaguide.html#s3.4.2-ordering-class-contents)
+so doing this often leads to violations of the [Overloads: never split](https://google.github.io/styleguide/javaguide.html#s3.4.2-ordering-class-contents)
 style-guide rule.
 
 Tip: Using a custom `ResultSink` type instead of a generic one from
@@ -774,14 +770,11 @@ pattern after accepting output from either a subtask or SkyValue lookup.
 Note that the implementation of `acceptBarError` eagerly forwards the result to
 the `Caller.ResultSink`, as required by [Error bubbling](#error-bubbling).
 
-Alternatives for top-level `StateMachine`s are described in [`Driver`s and
-bridging to SkyFunctions](#drivers-and-bridging).
+Alternatives for top-level `StateMachine`s are described in [`Driver`s and bridging to SkyFunctions](#drivers-and-bridging).
 
 ### Error handling {#error-handling}
 
-There's a couple of examples of error handling already in [`Tasks.lookUp`
-callbacks](#tasks-lookup-callbacks) and [Propagating values between
-`StateMachines`](#propagating-values). Exceptions, other than
+There's a couple of examples of error handling already in [`Tasks.lookUp` callbacks](#tasks-lookup-callbacks) and [Propagating values between `StateMachines`](#propagating-values). Exceptions, other than
 `InterruptedException` are not thrown, but instead passed around through
 callbacks as values. Such callbacks often have exclusive-or semantics, with
 exactly one of a value or error being passed.
@@ -1184,8 +1177,7 @@ states. Where it is possible, local stack `step` variables are young generation
 variables and efficiently GC'd.
 
 For `StateMachine` variables, breaking things down into subtasks and following
-the recommended pattern for [Propagating values between
-`StateMachine`s](#propagating-values) is also helpful. Observe that when
+the recommended pattern for [Propagating values between `StateMachine`s](#propagating-values) is also helpful. Observe that when
 following the pattern, only child `StateMachine`s have references to parent
 `StateMachine`s and not vice versa. This means that as children complete and
 update the parents using result callbacks, the children naturally fall out of
@@ -1207,8 +1199,7 @@ potentially reflecting local behavior.
 
 ### Concurrency tree diagram {#concurrency-tree-diagram}
 
-The following is an alternative view of the diagram in [Structured
-concurrency](#structured-concurrency) that better depicts the tree structure.
+The following is an alternative view of the diagram in [Structured concurrency](#structured-concurrency) that better depicts the tree structure.
 The blocks form a small tree.
 
 ![Structured Concurrency 3D](/versions/8.3.1/contribute/images/structured-concurrency-3d.svg)
diff --git a/versions/8.3.1/docs/android-instrumentation-test.mdx b/versions/8.3.1/docs/android-instrumentation-test.mdx
index 057851b8..26a2c8d0 100644
--- a/versions/8.3.1/docs/android-instrumentation-test.mdx
+++ b/versions/8.3.1/docs/android-instrumentation-test.mdx
@@ -2,8 +2,7 @@
 title: 'Android Instrumentation Tests'
 ---
 
-_If you're new to Bazel, start with the [Building Android with
-Bazel](/versions/8.3.1/start/android-app ) tutorial._
+_If you're new to Bazel, start with the [Building Android with Bazel](/versions/8.3.1/start/android-app) tutorial._
 
 ![Running Android instrumentation tests in parallel](/versions/8.3.1/docs/images/android_test.gif "Android instrumentation test")
 
@@ -18,9 +17,7 @@ emulators in a sandbox, ensuring that tests always run from a clean state. Each
 test gets an isolated emulator instance, allowing tests to run in parallel
 without passing states between them.
 
-For more information on Android instrumentation tests, check out the [Android
-developer
-documentation](https://developer.android.com/training/testing/unit-testing/instrumented-unit-tests.html).
+For more information on Android instrumentation tests, check out the [Android developer documentation](https://developer.android.com/training/testing/unit-testing/instrumented-unit-tests.html).
 
 Please file issues in the [GitHub issue tracker](https://github.com/bazelbuild/bazel/issues).
 
@@ -58,8 +55,7 @@ This results in output similar to the following:
 release 4.1.0
 ```
 
-- **KVM**. Bazel requires emulators to have [hardware
-  acceleration](https://developer.android.com/studio/run/emulator-acceleration.html#accel-check)
+- **KVM**. Bazel requires emulators to have [hardware acceleration](https://developer.android.com/studio/run/emulator-acceleration.html#accel-check)
   with KVM on Linux. You can follow these
   [installation instructions](https://help.ubuntu.com/community/KVM/Installation)
   for Ubuntu.
@@ -173,11 +169,9 @@ The main attributes of the rule `android_instrumentation_test` are:
 
 - `target_device`: An `android_device` target. This target describes the
   specifications of the Android emulator which Bazel uses to create, launch and
-  run the tests. See the [section on choosing an Android
-  device](#android-device-target) for more information.
+  run the tests. See the [section on choosing an Android device](#android-device-target) for more information.
 
-The test app's `AndroidManifest.xml` must include [an ``
-tag](https://developer.android.com/studio/test/#configure_instrumentation_manifest_settings).
+The test app's `AndroidManifest.xml` must include [an `` tag](https://developer.android.com/studio/test/#configure_instrumentation_manifest_settings).
 This tag must specify the attributes for the **package of the target app** and
 the **fully qualified class name of the instrumentation test runner**,
 `androidx.test.runner.AndroidJUnitRunner`.
@@ -214,8 +208,7 @@ repositories:
 - `@androidsdk`: The Android SDK. Download this through Android Studio.
 
 - `@android_test_support`: Hosts the test runner, emulator launcher, and
-  `android_device` targets. You can find the [latest release
-  here](https://github.com/android/android-test/releases).
+  `android_device` targets. You can find the [latest release here](https://github.com/android/android-test/releases).
 
 Enable these dependencies by adding the following lines to your `WORKSPACE`
 file:
@@ -240,8 +233,7 @@ android_test_repositories()
 
 ## Maven dependencies {#maven-dependencies}
 
-For managing dependencies on Maven artifacts from repositories, such as [Google
-Maven](https://maven.google.com) or [Maven Central](https://central.maven.org),
+For managing dependencies on Maven artifacts from repositories, such as [Google Maven](https://maven.google.com) or [Maven Central](https://central.maven.org),
 you should use a Maven resolver, such as
 [`rules_jvm_external`](https://github.com/bazelbuild/rules_jvm_external).
 
@@ -370,8 +362,7 @@ the device/emulator listed in `adb devices`.
 
 ## Sample projects {#sample-projects}
 
-If you are looking for canonical project samples, see the [Android testing
-samples](https://github.com/googlesamples/android-testing#experimental-bazel-support)
+If you are looking for canonical project samples, see the [Android testing samples](https://github.com/googlesamples/android-testing#experimental-bazel-support)
 for projects using Espresso and UIAutomator.
 
 ## Espresso setup {#espresso-setup}
@@ -560,8 +551,7 @@ API_LEVELS = [
 
 ## Known issues {#known-issues}
 
-- [Forked adb server processes are not terminated after
-  tests](https://github.com/bazelbuild/bazel/issues/4853)
+- [Forked adb server processes are not terminated after tests](https://github.com/bazelbuild/bazel/issues/4853)
 - While APK building works on all platforms (Linux, macOS, Windows), testing
   only works on Linux.
 - Even with `--config=local_adb`, users still need to specify
diff --git a/versions/8.3.1/docs/android-ndk.mdx b/versions/8.3.1/docs/android-ndk.mdx
index a12f5dec..d5ee45a6 100644
--- a/versions/8.3.1/docs/android-ndk.mdx
+++ b/versions/8.3.1/docs/android-ndk.mdx
@@ -2,8 +2,7 @@
 title: 'Using the Android Native Development Kit with Bazel'
 ---
 
-_If you're new to Bazel, please start with the [Building Android with
-Bazel](/versions/8.3.1/start/android-app ) tutorial._
+_If you're new to Bazel, please start with the [Building Android with Bazel](/versions/8.3.1/start/android-app) tutorial._
 
 ## Overview {#overview}
 
@@ -31,8 +30,7 @@ android_ndk_repository(
 )
 ```
 
-For more information about the `android_ndk_repository` rule, see the [Build
-Encyclopedia entry](/versions/8.3.1/reference/be/android#android_ndk_repository).
+For more information about the `android_ndk_repository` rule, see the [Build Encyclopedia entry](/versions/8.3.1/reference/be/android#android_ndk_repository).
 
 If you're using a recent version of the Android NDK (r22 and beyond), use the
 Starlark implementation of `android_ndk_repository`.
@@ -101,13 +99,11 @@ META-INF/MANIFEST.MF
 
 Bazel compiles all of the cc_libraries into a single shared object (`.so`) file,
 targeted for the `armeabi-v7a` ABI by default. To change this or build for
-multiple ABIs at the same time, see the section on [configuring the target
-ABI](#configuring-target-abi).
+multiple ABIs at the same time, see the section on [configuring the target ABI](#configuring-target-abi).
 
 ## Example setup {#example-setup}
 
-This example is available in the [Bazel examples
-repository](https://github.com/bazelbuild/examples/tree/master/android/ndk).
+This example is available in the [Bazel examples repository](https://github.com/bazelbuild/examples/tree/master/android/ndk).
 
 In the `BUILD.bazel` file, three targets are defined with the `android_binary`,
 `android_library`, and `cc_library` rules.
diff --git a/versions/8.3.1/docs/bazel-and-android.mdx b/versions/8.3.1/docs/bazel-and-android.mdx
index 7f51bd5f..fb45fac6 100644
--- a/versions/8.3.1/docs/bazel-and-android.mdx
+++ b/versions/8.3.1/docs/bazel-and-android.mdx
@@ -10,7 +10,7 @@ Android projects with Bazel.
 
 The following resources will help you work with Bazel on Android projects:
 
-*  [Tutorial: Building an Android app](/versions/8.3.1/start/android-app ). This
+*  [Tutorial: Building an Android app](/versions/8.3.1/start/android-app). This
    tutorial is a good place to start learning about Bazel commands and concepts,
    and how to build Android apps with Bazel.
 *  [Codelab: Building Android Apps with Bazel](https://developer.android.com/codelabs/bazel-android-intro#0).
diff --git a/versions/8.3.1/docs/configurable-attributes.mdx b/versions/8.3.1/docs/configurable-attributes.mdx
index 3833d28e..d7e6c38c 100644
--- a/versions/8.3.1/docs/configurable-attributes.mdx
+++ b/versions/8.3.1/docs/configurable-attributes.mdx
@@ -2,8 +2,7 @@
 title: 'Configurable Build Attributes'
 ---
 
-**_Configurable attributes_**, commonly known as [`select()`](
-/reference/be/functions#select), is a Bazel feature that lets users toggle the values
+**_Configurable attributes_**, commonly known as [`select()`](/versions/8.3.1/reference/be/functions#select), is a Bazel feature that lets users toggle the values
 of build rule attributes at the command line.
 
 This can be used, for example, for a multiplatform library that automatically
@@ -407,8 +406,7 @@ sh_library(
 )
 ```
 
-If you need a `select` to match when multiple conditions match, consider [AND
-chaining](#and-chaining).
+If you need a `select` to match when multiple conditions match, consider [AND chaining](#and-chaining).
 
 ## OR chaining {#or-chaining}
 
diff --git a/versions/8.3.1/docs/images/a_b_a_c.svg b/versions/8.3.1/docs/images/a_b_a_c.svg
new file mode 100644
index 00000000..d38be075
--- /dev/null
+++ b/versions/8.3.1/docs/images/a_b_a_c.svg
@@ -0,0 +1,42 @@
+
+
+
+
+
+
+G
+
+
+
+a
+
+a
+
+
+
+b
+
+b
+
+
+
+a->b
+
+
+
+
+
+c
+
+c
+
+
+
+a->c
+
+
+
+
+
+
diff --git a/versions/8.3.1/docs/images/a_b_c.svg b/versions/8.3.1/docs/images/a_b_c.svg
new file mode 100644
index 00000000..acd948ab
--- /dev/null
+++ b/versions/8.3.1/docs/images/a_b_c.svg
@@ -0,0 +1,41 @@
+
+
+
+
+
+
+G
+
+
+
+a
+
+a
+
+
+
+b
+
+b
+
+
+
+a->b
+
+
+
+
+
+c
+
+c
+
+
+
+b->c
+
+
+
+
+
diff --git a/versions/8.3.1/docs/images/a_b_c_ac.svg b/versions/8.3.1/docs/images/a_b_c_ac.svg
new file mode 100644
index 00000000..b099c53e
--- /dev/null
+++ b/versions/8.3.1/docs/images/a_b_c_ac.svg
@@ -0,0 +1,47 @@
+
+
+
+
+
+
+G
+
+
+
+a
+
+a
+
+
+
+b
+
+b
+
+
+
+a->b
+
+
+
+
+
+c
+
+c
+
+
+
+a->c
+
+
+
+
+
+b->c
+
+
+
+
+
diff --git a/versions/8.3.1/docs/images/ab_c.svg b/versions/8.3.1/docs/images/ab_c.svg
new file mode 100644
index 00000000..bcc4563f
--- /dev/null
+++ b/versions/8.3.1/docs/images/ab_c.svg
@@ -0,0 +1,36 @@
+
+
+
+
+
+
+G
+
+
+
+a
+
+a
+
+
+
+b
+
+b
+
+
+
+a->b
+
+
+
+
+
+c
+
+c
+
+
+
+
diff --git a/versions/8.3.1/docs/images/allpaths.svg b/versions/8.3.1/docs/images/allpaths.svg
new file mode 100644
index 00000000..47d0ee33
--- /dev/null
+++ b/versions/8.3.1/docs/images/allpaths.svg
@@ -0,0 +1,141 @@
+
+
+
+
+
+
+allpaths
+
+
+
+n1
+
+
+
+
+n2
+
+
+
+
+n1->n2
+
+
+
+
+
+n3
+
+
+
+
+n2->n3
+
+
+
+
+
+n10
+
+
+
+
+n2->n10
+
+
+
+
+
+n3->n10
+
+
+
+
+
+n4
+
+E
+
+
+
+n5
+
+
+
+
+n6
+
+
+
+
+n5->n6
+
+
+
+
+
+n6->n4
+
+
+
+
+
+n9
+
+
+
+
+n6->n9
+
+
+
+
+
+n7
+
+S1
+
+
+
+n7->n2
+
+
+
+
+
+n7->n5
+
+
+
+
+
+n8
+
+S2
+
+
+
+n8->n6
+
+
+
+
+
+n10->n4
+
+
+
+
+
+n11
+
+
+
+
+n10->n11
+
+
+
+
+
diff --git a/versions/8.3.1/docs/images/android_instrumentation_test.png b/versions/8.3.1/docs/images/android_instrumentation_test.png
new file mode 100644
index 00000000..e4534fbd
Binary files /dev/null and b/versions/8.3.1/docs/images/android_instrumentation_test.png differ
diff --git a/versions/8.3.1/docs/images/android_ndk.png b/versions/8.3.1/docs/images/android_ndk.png
new file mode 100644
index 00000000..76b63cb3
Binary files /dev/null and b/versions/8.3.1/docs/images/android_ndk.png differ
diff --git a/versions/8.3.1/docs/images/android_tutorial_app.png b/versions/8.3.1/docs/images/android_tutorial_app.png
new file mode 100644
index 00000000..076be5b9
Binary files /dev/null and b/versions/8.3.1/docs/images/android_tutorial_app.png differ
diff --git a/versions/8.3.1/docs/images/android_tutorial_before.png b/versions/8.3.1/docs/images/android_tutorial_before.png
new file mode 100644
index 00000000..8e41d419
Binary files /dev/null and b/versions/8.3.1/docs/images/android_tutorial_before.png differ
diff --git a/versions/8.3.1/docs/images/bep-graph.png b/versions/8.3.1/docs/images/bep-graph.png
new file mode 100644
index 00000000..82da6715
Binary files /dev/null and b/versions/8.3.1/docs/images/bep-graph.png differ
diff --git a/versions/8.3.1/docs/images/bep-graph.svg b/versions/8.3.1/docs/images/bep-graph.svg
new file mode 100644
index 00000000..62b1480f
--- /dev/null
+++ b/versions/8.3.1/docs/images/bep-graph.svg
@@ -0,0 +1,4 @@
+
+
+
+
diff --git a/versions/8.3.1/docs/images/cpp-tutorial-stage1.png b/versions/8.3.1/docs/images/cpp-tutorial-stage1.png
new file mode 100644
index 00000000..c85fb303
Binary files /dev/null and b/versions/8.3.1/docs/images/cpp-tutorial-stage1.png differ
diff --git a/versions/8.3.1/docs/images/cpp-tutorial-stage2.png b/versions/8.3.1/docs/images/cpp-tutorial-stage2.png
new file mode 100644
index 00000000..80e202c9
Binary files /dev/null and b/versions/8.3.1/docs/images/cpp-tutorial-stage2.png differ
diff --git a/versions/8.3.1/docs/images/cpp-tutorial-stage3.png b/versions/8.3.1/docs/images/cpp-tutorial-stage3.png
new file mode 100644
index 00000000..54d82f31
Binary files /dev/null and b/versions/8.3.1/docs/images/cpp-tutorial-stage3.png differ
diff --git a/versions/8.3.1/docs/images/deps.svg b/versions/8.3.1/docs/images/deps.svg
new file mode 100644
index 00000000..4354222a
--- /dev/null
+++ b/versions/8.3.1/docs/images/deps.svg
@@ -0,0 +1,101 @@
+
+
+
+
+
+
+G1
+
+
+
+r1
+
+rule
+
+
+
+s1
+
+in
+
+
+
+r1->s1
+
+
+
+
+
+s2
+
+in
+
+
+
+r1->s2
+
+
+
+
+
+s3
+
+in
+
+
+
+r1->s3
+
+
+
+
+
+r2
+
+rule
+
+
+
+r2->r1
+
+
+
+
+
+s4
+
+in
+
+
+
+r2->s4
+
+
+
+
+
+o1
+
+out
+
+
+
+o1->r1
+
+
+
+
+
+o2
+
+out
+
+
+
+o2->r2
+
+
+
+
+
diff --git a/versions/8.3.1/docs/images/dyn-trace-alldynamic.png b/versions/8.3.1/docs/images/dyn-trace-alldynamic.png
new file mode 100644
index 00000000..fe36b253
Binary files /dev/null and b/versions/8.3.1/docs/images/dyn-trace-alldynamic.png differ
diff --git a/versions/8.3.1/docs/images/dyn-trace-javaconly.png b/versions/8.3.1/docs/images/dyn-trace-javaconly.png
new file mode 100644
index 00000000..2ae41e52
Binary files /dev/null and b/versions/8.3.1/docs/images/dyn-trace-javaconly.png differ
diff --git a/versions/8.3.1/docs/images/e4b-workflow.png b/versions/8.3.1/docs/images/e4b-workflow.png
new file mode 100644
index 00000000..412822da
Binary files /dev/null and b/versions/8.3.1/docs/images/e4b-workflow.png differ
diff --git a/versions/8.3.1/docs/images/e4b-workflow.svg b/versions/8.3.1/docs/images/e4b-workflow.svg
new file mode 100644
index 00000000..1de66e02
--- /dev/null
+++ b/versions/8.3.1/docs/images/e4b-workflow.svg
@@ -0,0 +1,4 @@
+
+
+
+
diff --git a/versions/8.3.1/docs/images/error_example_1.png b/versions/8.3.1/docs/images/error_example_1.png
new file mode 100644
index 00000000..07ba1358
Binary files /dev/null and b/versions/8.3.1/docs/images/error_example_1.png differ
diff --git a/versions/8.3.1/docs/images/error_example_2.png b/versions/8.3.1/docs/images/error_example_2.png
new file mode 100644
index 00000000..861171ee
Binary files /dev/null and b/versions/8.3.1/docs/images/error_example_2.png differ
diff --git a/versions/8.3.1/docs/images/error_example_3.png b/versions/8.3.1/docs/images/error_example_3.png
new file mode 100644
index 00000000..dc16eec4
Binary files /dev/null and b/versions/8.3.1/docs/images/error_example_3.png differ
diff --git a/versions/8.3.1/docs/images/error_example_4.png b/versions/8.3.1/docs/images/error_example_4.png
new file mode 100644
index 00000000..84383e63
Binary files /dev/null and b/versions/8.3.1/docs/images/error_example_4.png differ
diff --git a/versions/8.3.1/docs/images/graph_ex_1.svg b/versions/8.3.1/docs/images/graph_ex_1.svg
new file mode 100644
index 00000000..dd7427f4
--- /dev/null
+++ b/versions/8.3.1/docs/images/graph_ex_1.svg
@@ -0,0 +1,131 @@
+
+
+
+
+
+
+mygraph
+
+
+
+//net/proto_compiler:protocol-compiler
+
+//net/proto_compiler:protocol-compiler
+
+
+
+//net/proto_compiler:util
+
+//net/proto_compiler:util
+
+
+
+//net/proto_compiler:protocol-compiler->//net/proto_compiler:util
+
+
+
+
+
+//net/proto_compiler:protocol-compiler-lib
+
+//net/proto_compiler:protocol-compiler-lib
+
+
+
+//net/proto_compiler:protocol-compiler->//net/proto_compiler:protocol-compiler-lib
+
+
+
+
+
+//net/proto2/bridge/public:compiler_upgrader
+
+//net/proto2/bridge/public:compiler_upgrader
+
+
+
+//net/proto_compiler:protocol-compiler->//net/proto2/bridge/public:compiler_upgrader
+
+
+
+
+
+//net/proto_compiler:parser
+
+//net/proto_compiler:parser
+
+
+
+//net/proto_compiler:util->//net/proto_compiler:parser
+
+
+
+
+
+//net/proto_compiler:proto-min-lib
+
+//net/proto_compiler:proto-min-lib
+
+
+
+//net/proto_compiler:protocol-compiler-lib->//net/proto_compiler:proto-min-lib
+
+
+
+
+
+//net/proto_compiler:protocol-compiler-lib->//net/proto_compiler:parser
+
+
+
+
+
+//net/proto2/bridge/internal:compiler_upgrader
+
+//net/proto2/bridge/internal:compiler_upgrader
+
+
+
+//net/proto2/bridge/public:compiler_upgrader->//net/proto2/bridge/internal:compiler_upgrader
+
+
+
+
+
+//net/proto_compiler:proto-min-lib->//net/proto_compiler:parser
+
+
+
+
+
+//util/regexp:regexp
+
+//util/regexp:regexp
+
+
+
+//net/proto_compiler:proto-min-lib->//util/regexp:regexp
+
+
+
+
+
+//net/proto_compiler:parser->//util/regexp:regexp
+
+
+
+
+
+//net/proto2/bridge/internal:compiler_upgrader->//net/proto2/bridge/public:compiler_upgrader
+
+
+
+
+
+//net/proto2/bridge/internal:compiler_upgrader->//net/proto_compiler:parser
+
+
+
+
+
diff --git a/versions/8.3.1/docs/images/graph_hello-world.svg b/versions/8.3.1/docs/images/graph_hello-world.svg
new file mode 100644
index 00000000..93b61444
--- /dev/null
+++ b/versions/8.3.1/docs/images/graph_hello-world.svg
@@ -0,0 +1,70 @@
+
+
+
+
+
+
+mygraph
+
+
+//main:hello-world
+
+//main:hello-world
+
+
+//main:hello-time
+
+//main:hello-time
+
+
+//main:hello-world->//main:hello-time
+
+
+
+
+//main:hello-world.cc
+
+//main:hello-world.cc
+
+
+//main:hello-world->//main:hello-world.cc
+
+
+
+
+//lib:hello-greet
+
+//lib:hello-greet
+
+
+//main:hello-world->//lib:hello-greet
+
+
+
+
+//main:hello-time.cc\n//main:hello-time.h
+
+//main:hello-time.cc
+//main:hello-time.h
+
+
+//main:hello-time->//main:hello-time.cc\n//main:hello-time.h
+
+
+
+
+//lib:hello-greet.cc\n//lib:hello-greet.h
+
+//lib:hello-greet.cc
+//lib:hello-greet.h
+
+
+//lib:hello-greet->//lib:hello-greet.cc\n//lib:hello-greet.h
+
+
+
+
+
diff --git a/versions/8.3.1/docs/images/json-trace-profile-network-usage.png b/versions/8.3.1/docs/images/json-trace-profile-network-usage.png
new file mode 100644
index 00000000..8a7500a6
Binary files /dev/null and b/versions/8.3.1/docs/images/json-trace-profile-network-usage.png differ
diff --git a/versions/8.3.1/docs/images/json-trace-profile-system-load-average.png b/versions/8.3.1/docs/images/json-trace-profile-system-load-average.png
new file mode 100644
index 00000000..e71b420c
Binary files /dev/null and b/versions/8.3.1/docs/images/json-trace-profile-system-load-average.png differ
diff --git a/versions/8.3.1/docs/images/json-trace-profile-workers-memory-usage.png b/versions/8.3.1/docs/images/json-trace-profile-workers-memory-usage.png
new file mode 100644
index 00000000..806505f0
Binary files /dev/null and b/versions/8.3.1/docs/images/json-trace-profile-workers-memory-usage.png differ
diff --git a/versions/8.3.1/docs/images/json-trace-profile.png b/versions/8.3.1/docs/images/json-trace-profile.png
new file mode 100644
index 00000000..538382b2
Binary files /dev/null and b/versions/8.3.1/docs/images/json-trace-profile.png differ
diff --git a/versions/8.3.1/docs/images/mobile-install-performance.svg b/versions/8.3.1/docs/images/mobile-install-performance.svg
new file mode 100644
index 00000000..b139d658
--- /dev/null
+++ b/versions/8.3.1/docs/images/mobile-install-performance.svg
@@ -0,0 +1,86 @@
+
+
+
+  
+    
+      
+    
+  
+  
+  
+    Build times
+  
+  
+    
+    
+      
+      
+        adb install
+      
+      
+    
+    
+      
+      
+        mobile-install
+      
+      
+    
+  
+  
+    
+    
+      
+        
+        
+        
+        
+        
+      
+      
+        
+        
+        
+        
+        
+        
+      
+      
+        
+      
+    
+    
+    
+      
+        Google Maps
+      
+      
+        Google+
+      
+      
+        YouTube
+      
+      
+        0
+      
+      
+        75
+      
+      
+        150
+      
+      
+        225
+      
+      
+        300
+      
+    
+  
+  
+    
+      Seconds
+    
+  
+  
+
diff --git a/versions/8.3.1/docs/images/namedsetoffiles-bep-graph.png b/versions/8.3.1/docs/images/namedsetoffiles-bep-graph.png
new file mode 100644
index 00000000..ea1e10cc
Binary files /dev/null and b/versions/8.3.1/docs/images/namedsetoffiles-bep-graph.png differ
diff --git a/versions/8.3.1/docs/images/out-ranked.svg b/versions/8.3.1/docs/images/out-ranked.svg
new file mode 100644
index 00000000..07e96804
--- /dev/null
+++ b/versions/8.3.1/docs/images/out-ranked.svg
@@ -0,0 +1,71 @@
+
+
+
+
+
+
+mygraph
+
+
+
+//a:a
+
+//a:a
+
+
+
+//a:a.cc
+
+//a:a.cc
+
+
+
+//a:a->//a:a.cc
+
+
+
+
+
+//b:b
+
+//b:b
+
+
+
+//b:b->//a:a
+
+
+
+
+
+//b:b.cc
+
+//b:b.cc
+
+
+
+//b:b->//b:b.cc
+
+
+
+
+
+//c:c
+
+//c:c
+
+
+
+//c:c->//a:a
+
+
+
+
+
+//c:c->//b:b
+
+
+
+
+
diff --git a/versions/8.3.1/docs/images/rbe-ci-1.png b/versions/8.3.1/docs/images/rbe-ci-1.png
new file mode 100644
index 00000000..fbe76a85
Binary files /dev/null and b/versions/8.3.1/docs/images/rbe-ci-1.png differ
diff --git a/versions/8.3.1/docs/images/rbe-ci-2.png b/versions/8.3.1/docs/images/rbe-ci-2.png
new file mode 100644
index 00000000..07611889
Binary files /dev/null and b/versions/8.3.1/docs/images/rbe-ci-2.png differ
diff --git a/versions/8.3.1/docs/images/somepath1.svg b/versions/8.3.1/docs/images/somepath1.svg
new file mode 100644
index 00000000..5e5f8812
--- /dev/null
+++ b/versions/8.3.1/docs/images/somepath1.svg
@@ -0,0 +1,141 @@
+
+
+
+
+
+
+somepath1
+
+
+
+n1
+
+
+
+
+n2
+
+
+
+
+n1->n2
+
+
+
+
+
+n3
+
+
+
+
+n2->n3
+
+
+
+
+
+n10
+
+
+
+
+n2->n10
+
+
+
+
+
+n3->n10
+
+
+
+
+
+n4
+
+E
+
+
+
+n5
+
+
+
+
+n6
+
+
+
+
+n5->n6
+
+
+
+
+
+n6->n4
+
+
+
+
+
+n9
+
+
+
+
+n6->n9
+
+
+
+
+
+n7
+
+S1
+
+
+
+n7->n2
+
+
+
+
+
+n7->n5
+
+
+
+
+
+n8
+
+S2
+
+
+
+n8->n6
+
+
+
+
+
+n10->n4
+
+
+
+
+
+n11
+
+
+
+
+n10->n11
+
+
+
+
+
diff --git a/versions/8.3.1/docs/images/somepath2.svg b/versions/8.3.1/docs/images/somepath2.svg
new file mode 100644
index 00000000..911f2c9b
--- /dev/null
+++ b/versions/8.3.1/docs/images/somepath2.svg
@@ -0,0 +1,141 @@
+
+
+
+
+
+
+somepath2
+
+
+
+n1
+
+
+
+
+n2
+
+
+
+
+n1->n2
+
+
+
+
+
+n3
+
+
+
+
+n2->n3
+
+
+
+
+
+n10
+
+
+
+
+n2->n10
+
+
+
+
+
+n3->n10
+
+
+
+
+
+n4
+
+E
+
+
+
+n5
+
+
+
+
+n6
+
+
+
+
+n5->n6
+
+
+
+
+
+n6->n4
+
+
+
+
+
+n9
+
+
+
+
+n6->n9
+
+
+
+
+
+n7
+
+S1
+
+
+
+n7->n2
+
+
+
+
+
+n7->n5
+
+
+
+
+
+n8
+
+S2
+
+
+
+n8->n6
+
+
+
+
+
+n10->n4
+
+
+
+
+
+n11
+
+
+
+
+n10->n11
+
+
+
+
+
diff --git a/versions/8.3.1/docs/images/targets.svg b/versions/8.3.1/docs/images/targets.svg
new file mode 100644
index 00000000..82f47e74
--- /dev/null
+++ b/versions/8.3.1/docs/images/targets.svg
@@ -0,0 +1,113 @@
+
+
+
+
+
+
+G1
+
+
+
+Target
+
+Target
+
+
+
+Rule
+
+Rule
+
+
+
+Target->Rule
+
+
+
+
+
+File
+
+File
+
+
+
+Target->File
+
+
+
+
+
+Package group
+
+Package group
+
+
+
+Target->Package group
+
+
+
+
+
+cc_library
+
+cc_library
+
+
+
+Rule->cc_library
+
+
+
+
+
+java_test
+
+java_test
+
+
+
+Rule->java_test
+
+
+
+
+
+...
+
+...
+
+
+
+Rule->...
+
+
+
+
+
+Source
+
+Source
+
+
+
+File->Source
+
+
+
+
+
+Generated
+
+Generated
+
+
+
+File->Generated
+
+
+
+
+
diff --git a/versions/8.3.1/docs/images/tutorial_java_01.svg b/versions/8.3.1/docs/images/tutorial_java_01.svg
new file mode 100644
index 00000000..2fe72f36
--- /dev/null
+++ b/versions/8.3.1/docs/images/tutorial_java_01.svg
@@ -0,0 +1,29 @@
+
+
+
+
+
+
+mygraph
+
+
+//:ProjectRunner
+
+//:ProjectRunner
+
+
+//:src/main/java/com/example/Greeting.java\n//:src/main/java/com/example/ProjectRunner.java
+
+//:src/main/java/com/example/Greeting.java
+//:src/main/java/com/example/ProjectRunner.java
+
+
+//:ProjectRunner->//:src/main/java/com/example/Greeting.java\n//:src/main/java/com/example/ProjectRunner.java
+
+
+
+
+
diff --git a/versions/8.3.1/docs/images/tutorial_java_02.svg b/versions/8.3.1/docs/images/tutorial_java_02.svg
new file mode 100644
index 00000000..40cbb218
--- /dev/null
+++ b/versions/8.3.1/docs/images/tutorial_java_02.svg
@@ -0,0 +1,48 @@
+
+
+
+
+
+
+mygraph
+
+
+//:ProjectRunner
+
+//:ProjectRunner
+
+
+//:greeter
+
+//:greeter
+
+
+//:ProjectRunner->//:greeter
+
+
+
+
+//:src/main/java/com/example/ProjectRunner.java
+
+//:src/main/java/com/example/ProjectRunner.java
+
+
+//:ProjectRunner->//:src/main/java/com/example/ProjectRunner.java
+
+
+
+
+//:src/main/java/com/example/Greeting.java
+
+//:src/main/java/com/example/Greeting.java
+
+
+//:greeter->//:src/main/java/com/example/Greeting.java
+
+
+
+
+
diff --git a/versions/8.3.1/docs/images/tutorial_java_03.svg b/versions/8.3.1/docs/images/tutorial_java_03.svg
new file mode 100644
index 00000000..7d79041a
--- /dev/null
+++ b/versions/8.3.1/docs/images/tutorial_java_03.svg
@@ -0,0 +1,48 @@
+
+
+
+
+
+
+mygraph
+
+
+//src/main/java/com/example/cmdline:runner
+
+//src/main/java/com/example/cmdline:runner
+
+
+//src/main/java/com/example/cmdline:Runner.java
+
+//src/main/java/com/example/cmdline:Runner.java
+
+
+//src/main/java/com/example/cmdline:runner->//src/main/java/com/example/cmdline:Runner.java
+
+
+
+
+//:greeter
+
+//:greeter
+
+
+//src/main/java/com/example/cmdline:runner->//:greeter
+
+
+
+
+//:src/main/java/com/example/Greeting.java
+
+//:src/main/java/com/example/Greeting.java
+
+
+//:greeter->//:src/main/java/com/example/Greeting.java
+
+
+
+
+
diff --git a/versions/8.3.1/docs/images/workers-clean-chart.png b/versions/8.3.1/docs/images/workers-clean-chart.png
new file mode 100644
index 00000000..63526fc1
Binary files /dev/null and b/versions/8.3.1/docs/images/workers-clean-chart.png differ
diff --git a/versions/8.3.1/docs/images/workers-incremental-chart.png b/versions/8.3.1/docs/images/workers-incremental-chart.png
new file mode 100644
index 00000000..1c62d25c
Binary files /dev/null and b/versions/8.3.1/docs/images/workers-incremental-chart.png differ
diff --git a/versions/8.3.1/docs/images/ws-diamond.png b/versions/8.3.1/docs/images/ws-diamond.png
new file mode 100644
index 00000000..154a7440
Binary files /dev/null and b/versions/8.3.1/docs/images/ws-diamond.png differ
diff --git a/versions/8.3.1/docs/images/ws-line.png b/versions/8.3.1/docs/images/ws-line.png
new file mode 100644
index 00000000..e8bfe7a1
Binary files /dev/null and b/versions/8.3.1/docs/images/ws-line.png differ
diff --git a/versions/8.3.1/docs/images/ws-multiline.png b/versions/8.3.1/docs/images/ws-multiline.png
new file mode 100644
index 00000000..f07b43b1
Binary files /dev/null and b/versions/8.3.1/docs/images/ws-multiline.png differ
diff --git a/versions/8.3.1/docs/sandboxing.mdx b/versions/8.3.1/docs/sandboxing.mdx
index 585073ee..89d4a8d3 100644
--- a/versions/8.3.1/docs/sandboxing.mdx
+++ b/versions/8.3.1/docs/sandboxing.mdx
@@ -48,7 +48,7 @@ containers on Linux and `sandbox-exec` on macOS, to constrain the action within
 ## What sandbox strategy to use {#sandboxing-strategies}
 
 You can choose which kind of sandboxing to use, if any, with the
-[strategy flags](user-manual#strategy-options). Using the `sandboxed`
+[strategy flags](/versions/8.3.1/docs/user-manual#strategy-options). Using the `sandboxed`
 strategy makes Bazel pick one of the sandbox implementations listed below,
 preferring an OS-specific sandbox to the less hermetic generic one.
 [Persistent workers](/versions/8.3.1/remote/persistent) run in a generic sandbox if you pass
diff --git a/versions/8.3.1/docs/user-manual.mdx b/versions/8.3.1/docs/user-manual.mdx
index c8d2e24b..a8c94b98 100644
--- a/versions/8.3.1/docs/user-manual.mdx
+++ b/versions/8.3.1/docs/user-manual.mdx
@@ -1145,12 +1145,12 @@ during execution can be examined.
 This option causes Bazel's execution phase to print the full command line
 for each command prior to executing it.
 
-
-  >>>>> # //examples/cpp:hello-world [action 'Linking examples/cpp/hello-world']
+```
+  >>>> # //examples/cpp:hello-world [action 'Linking examples/cpp/hello-world']
   (cd /home/johndoe/.cache/bazel/_bazel_johndoe/4c084335afceb392cfbe7c31afee3a9f/bazel && \
     exec env - \
     /usr/bin/gcc -o bazel-out/local-fastbuild/bin/examples/cpp/hello-world -B/usr/bin/ -Wl,-z,relro,-z,now -no-canonical-prefixes -pass-exit-codes -Wl,-S -Wl,@bazel-out/local_linux-fastbuild/bin/examples/cpp/hello-world-2.params)
-

+```
 
 Where possible, commands are printed in a Bourne shell compatible syntax,
 so that they can be easily copied and pasted to a shell command prompt.
diff --git a/versions/8.3.1/extending/auto-exec-groups.mdx b/versions/8.3.1/extending/auto-exec-groups.mdx
index 9c3d0d33..f55df1e4 100644
--- a/versions/8.3.1/extending/auto-exec-groups.mdx
+++ b/versions/8.3.1/extending/auto-exec-groups.mdx
@@ -27,9 +27,7 @@ doesn't detect that ([the error](#first-error-message) is raised), you can set
 
 If you need to use multiple toolchains on a single execution platform (an action
 uses executable or tools from two or more toolchains), you need to manually
-define [exec_groups][exec_groups] (check
-[When should I use a custom exec_group?][multiple_toolchains_exec_groups]
-section).
+define [exec_groups][exec_groups](check [When should I use a custom exec_group?][multiple_toolchains_exec_groups] section).
 
 ## History {#history}
 
@@ -42,8 +40,7 @@ my_rule = rule(
 )
 ```
 
-Rule `my_rule` registers two toolchain types. This means that the [Toolchain
-Resolution](https://bazel.build/extending/toolchains#toolchain-resolution) used
+Rule `my_rule` registers two toolchain types. This means that the [Toolchain Resolution](https://bazel.build/versions/8.3.1/extending/toolchains#toolchain-resolution) used
 to find an execution platform which supports both toolchain types. The selected
 execution platform was used for each registered action inside the rule, unless
 specified differently with [exec_groups][exec_groups].
diff --git a/versions/8.3.1/extending/concepts.mdx b/versions/8.3.1/extending/concepts.mdx
index d7307122..3ef1e5a7 100644
--- a/versions/8.3.1/extending/concepts.mdx
+++ b/versions/8.3.1/extending/concepts.mdx
@@ -20,16 +20,14 @@ Before learning the more advanced concepts, first:
 ## Macros and rules {#macros-and-rules}
 
 A macro is a function that instantiates rules. Macros come in two flavors:
-[symbolic macros](/versions/8.3.1/extending/macros) (new in Bazel 8) and [legacy
-macros](/versions/8.3.1/extending/legacy-macros). The two flavors of macros are defined
+[symbolic macros](/versions/8.3.1/extending/macros) (new in Bazel 8) and [legacy macros](/versions/8.3.1/extending/legacy-macros). The two flavors of macros are defined
 differently, but behave almost the same from the point of view of a user. A
 macro is useful when a `BUILD` file is getting too repetitive or too complex, as
 it lets you reuse some code. The function is evaluated as soon as the `BUILD`
 file is read. After the evaluation of the `BUILD` file, Bazel has little
 information about macros. If your macro generates a `genrule`, Bazel will
 behave *almost* as if you declared that `genrule` in the `BUILD` file. (The one
-exception is that targets declared in a symbolic macro have [special visibility
-semantics](/versions/8.3.1/extending/macros#visibility): a symbolic macro can hide its internal
+exception is that targets declared in a symbolic macro have [special visibility semantics](/versions/8.3.1/extending/macros#visibility): a symbolic macro can hide its internal
 targets from the rest of the package.)
 
 A [rule](/versions/8.3.1/extending/rules) is more powerful than a macro. It can access Bazel
@@ -76,8 +74,7 @@ they will not be executed.
 ## Creating extensions
 
 * [Create your first macro](/versions/8.3.1/rules/macro-tutorial) in order to reuse some code.
-  Then [learn more about macros](/versions/8.3.1/extending/macros) and [using them to create
-  "custom verbs"](/versions/8.3.1/rules/verbs-tutorial).
+  Then [learn more about macros](/versions/8.3.1/extending/macros) and [using them to create "custom verbs"](/versions/8.3.1/rules/verbs-tutorial).
 
 * [Follow the rules tutorial](/versions/8.3.1/rules/rules-tutorial) to get started with rules.
   Next, you can read more about the [rules concepts](/versions/8.3.1/extending/rules).
@@ -92,8 +89,7 @@ them within reach:
 ## Going further
 
 In addition to [macros](/versions/8.3.1/extending/macros) and [rules](/versions/8.3.1/extending/rules), you
-may want to write [aspects](/versions/8.3.1/extending/aspects) and [repository
-rules](/versions/8.3.1/extending/repo).
+may want to write [aspects](/versions/8.3.1/extending/aspects) and [repository rules](/versions/8.3.1/extending/repo).
 
 * Use [Buildifier](https://github.com/bazelbuild/buildtools)
   consistently to format and lint your code.
diff --git a/versions/8.3.1/extending/depsets.mdx b/versions/8.3.1/extending/depsets.mdx
index 541c5ef4..7bb6d477 100644
--- a/versions/8.3.1/extending/depsets.mdx
+++ b/versions/8.3.1/extending/depsets.mdx
@@ -111,8 +111,7 @@ need to ensure that if `B` depends on `A`, then `A.o` comes before `B.o` on the
 linker’s command line. Other tools might have the opposite requirement.
 
 Three traversal orders are supported: `postorder`, `preorder`, and
-`topological`. The first two work exactly like [tree
-traversals](https://en.wikipedia.org/wiki/Tree_traversal#Depth-first_search)
+`topological`. The first two work exactly like [tree traversals](https://en.wikipedia.org/wiki/Tree_traversal#Depth-first_search)
 except that they operate on DAGs and skip already visited nodes. The third order
 works as a topological sort from root to leaves, essentially the same as
 preorder except that shared children are listed only after all of their parents.
diff --git a/versions/8.3.1/extending/exec-groups.mdx b/versions/8.3.1/extending/exec-groups.mdx
index d9250bd8..05e89bdf 100644
--- a/versions/8.3.1/extending/exec-groups.mdx
+++ b/versions/8.3.1/extending/exec-groups.mdx
@@ -63,8 +63,7 @@ test rules.
 
 In the rule implementation, you can declare that actions should be run on the
 execution platform of an execution group. You can do this by using the `exec_group`
-param of action generating methods, specifically [`ctx.actions.run`]
-(/rules/lib/builtins/actions#run) and
+param of action generating methods, specifically [`ctx.actions.run`](/versions/8.3.1/rules/lib/builtins/actions#run) and
 [`ctx.actions.run_shell`](/versions/8.3.1/rules/lib/builtins/actions#run_shell).
 
 ```python
diff --git a/versions/8.3.1/extending/legacy-macros.mdx b/versions/8.3.1/extending/legacy-macros.mdx
index 24c11a97..0575acbd 100644
--- a/versions/8.3.1/extending/legacy-macros.mdx
+++ b/versions/8.3.1/extending/legacy-macros.mdx
@@ -9,7 +9,7 @@ anymore, and Bazel sees only the concrete set of instantiated rules.
 
 ## Why you shouldn't use legacy macros (and should use Symbolic macros instead) {#no-legacy-macros}
 
-Where possible you should use [symbolic macros](macros.md#macros).
+Where possible you should use [symbolic macros](/versions/8.3.1/extending/macros#macros).
 
 Symbolic macros
 
@@ -18,7 +18,7 @@ Symbolic macros
 *   Take typed attributes, which in turn means automatic label and select
     conversion.
 *   Are more readable
-*   Will soon have [lazy evaluation](macros.md/laziness)
+*   Will soon have [lazy evaluation](/versions/8.3.1/extending/macros#laziness)
 
 ## Usage {#usage}
 
@@ -152,7 +152,7 @@ the macro), use the function
 ## Label resolution in macros {#label-resolution}
 
 Since legacy macros are evaluated in the
-[loading phase](concepts.md#evaluation-model), label strings such as
+[loading phase](/versions/8.3.1/extending/concepts#evaluation-model), label strings such as
 `"//foo:bar"` that occur in a legacy macro are interpreted relative to the
 `BUILD` file in which the macro is used rather than relative to the `.bzl` file
 in which it is defined. This behavior is generally undesirable for macros that
diff --git a/versions/8.3.1/extending/macros.mdx b/versions/8.3.1/extending/macros.mdx
index 4de68793..9dcbb4dc 100644
--- a/versions/8.3.1/extending/macros.mdx
+++ b/versions/8.3.1/extending/macros.mdx
@@ -10,7 +10,7 @@ Macros are mainly used for encapsulation and code reuse of existing rules and
 other macros.
 
 Macros come in two flavors: symbolic macros, which are described on this page,
-and [legacy macros](legacy-macros.md). Where possible, we recommend using
+and [legacy macros](/versions/8.3.1/extending/legacy-macros). Where possible, we recommend using
 symbolic macros for code clarity.
 
 Symbolic macros offer typed arguments (string to label conversion, relative to
@@ -31,8 +31,7 @@ two required parameters: `attrs` and `implementation`.
 
 ### Attributes {#attributes}
 
-`attrs` accepts a dictionary of attribute name to [attribute
-types](https://bazel.build/rules/lib/toplevel/attr#members), which represents
+`attrs` accepts a dictionary of attribute name to [attribute types](https://bazel.build/versions/8.3.1/rules/lib/toplevel/attr#members), which represents
 the arguments to the macro. Two common attributes – `name` and `visibility` –
 are implicitly added to all macros and are not included in the dictionary passed
 to `attrs`.
@@ -66,9 +65,7 @@ To support this pattern, a macro can *inherit attributes* from a rule or another
 macro by passing the [rule](https://bazel.build/versions/8.3.1/rules/lib/builtins/rule) or
 [macro symbol](https://bazel.build/versions/8.3.1/rules/lib/builtins/macro) to `macro()`'s
 `inherit_attrs` argument. (You can also use the special string `"common"`
-instead of a rule or macro symbol to inherit the [common attributes defined for
-all Starlark build
-rules](https://bazel.build/reference/be/common-definitions#common-attributes).)
+instead of a rule or macro symbol to inherit the [common attributes defined for all Starlark build rules](https://bazel.build/versions/8.3.1/reference/be/common-definitions#common-attributes).)
 Only public attributes get inherited, and the attributes in the macro's own
 `attrs` dictionary override inherited attributes with the same name. You can
 also *remove* inherited attributes by using `None` as a value in the `attrs`
diff --git a/versions/8.3.1/extending/platforms.mdx b/versions/8.3.1/extending/platforms.mdx
index 4012667c..c3e87cf5 100644
--- a/versions/8.3.1/extending/platforms.mdx
+++ b/versions/8.3.1/extending/platforms.mdx
@@ -245,8 +245,7 @@ cc_library(
 
 You can use the
 [`IncompatiblePlatformProvider`](/versions/8.3.1/rules/lib/providers/IncompatiblePlatformProvider)
-in `bazel cquery`'s [Starlark output
-format](/versions/8.3.1/query/cquery#output-format-definition) to distinguish
+in `bazel cquery`'s [Starlark output format](/versions/8.3.1/query/cquery#output-format-definition) to distinguish
 incompatible targets from compatible ones.
 
 This can be used to filter out incompatible targets. The example below will
@@ -266,5 +265,4 @@ $ bazel cquery //... --output=starlark --starlark:file=example.cquery
 
 ### Known Issues
 
-Incompatible targets [ignore visibility
-restrictions](https://github.com/bazelbuild/bazel/issues/16044).
+Incompatible targets [ignore visibility restrictions](https://github.com/bazelbuild/bazel/issues/16044).
diff --git a/versions/8.3.1/extending/repo.mdx b/versions/8.3.1/extending/repo.mdx
index 0ab81226..6ca8e7de 100644
--- a/versions/8.3.1/extending/repo.mdx
+++ b/versions/8.3.1/extending/repo.mdx
@@ -74,8 +74,7 @@ specified.
 
 The input parameter `repository_ctx` can be used to access attribute values, and
 non-hermetic functions (finding a binary, executing a binary, creating a file in
-the repository or downloading a file from the Internet). See [the API
-docs](/versions/8.3.1/rules/lib/builtins/repository_ctx) for more context. Example:
+the repository or downloading a file from the Internet). See [the API docs](/versions/8.3.1/rules/lib/builtins/repository_ctx) for more context. Example:
 
 ```python
 def _impl(repository_ctx):
@@ -144,8 +143,7 @@ definition has the `configure` attribute set, use `bazel fetch --force
 
 ## Examples
 
--   [C++ auto-configured
-    toolchain](https://cs.opensource.google/bazel/bazel/+/master:tools/cpp/cc_configure.bzl;drc=644b7d41748e09eff9e47cbab2be2263bb71f29a;l=176):
+-   [C++ auto-configured toolchain](https://cs.opensource.google/bazel/bazel/+/master:tools/cpp/cc_configure.bzl;drc=644b7d41748e09eff9e47cbab2be2263bb71f29a;l=176):
     it uses a repo rule to automatically create the C++ configuration files for
     Bazel by looking for the local C++ compiler, the environment and the flags
     the C++ compiler supports.
diff --git a/versions/8.3.1/extending/rules.mdx b/versions/8.3.1/extending/rules.mdx
index 361c3995..076f61ed 100644
--- a/versions/8.3.1/extending/rules.mdx
+++ b/versions/8.3.1/extending/rules.mdx
@@ -449,8 +449,7 @@ def _example_library_impl(ctx):
 
 If `DefaultInfo` is not returned by a rule implementation or the `files`
 parameter is not specified, `DefaultInfo.files` defaults to all
-*predeclared outputs* (generally, those created by [output
-attributes](#output_attributes)).
+*predeclared outputs* (generally, those created by [output attributes](#output_attributes)).
 
 Rules that perform actions should provide default outputs, even if those outputs
 are not expected to be directly used. Actions that are not in the graph of the
@@ -995,8 +994,7 @@ By using `configuration_field`, the dependency on the Java LCOV merger tool can
 be avoided as long as coverage is not requested.
 
 When the test is run, it should emit coverage information in the form of one or
-more [LCOV files]
-(https://manpages.debian.org/unstable/lcov/geninfo.1.en.html#TRACEFILE_FORMAT)
+more [LCOV files](https://manpages.debian.org/unstable/lcov/geninfo.1.en.html#TRACEFILE_FORMAT)
 with unique names into the directory specified by the `COVERAGE_DIR` environment
 variable. Bazel will then merge these files into a single LCOV file using the
 `_lcov_merger` tool. If present, it will also collect C/C++ coverage using the
diff --git a/versions/8.3.1/extending/toolchains.mdx b/versions/8.3.1/extending/toolchains.mdx
index efe2957a..72403c6c 100644
--- a/versions/8.3.1/extending/toolchains.mdx
+++ b/versions/8.3.1/extending/toolchains.mdx
@@ -523,8 +523,7 @@ The set of available toolchains, in priority order, is created from
   4. Toolchains registered in the "WORKSPACE suffix"; this is only used by
      certain native rules bundled with the Bazel installation.
 
-**NOTE:** [Pseudo-targets like `:all`, `:*`, and
-`/...`](/versions/8.3.1/run/build#specifying-build-targets) are ordered by Bazel's package
+**NOTE:** [Pseudo-targets like `:all`, `:*`, and `/...`](/versions/8.3.1/run/build#specifying-build-targets) are ordered by Bazel's package
 loading mechanism, which uses a lexicographic ordering.
 
 The resolution steps are as follows.
diff --git a/versions/8.3.1/external/advanced.mdx b/versions/8.3.1/external/advanced.mdx
index a6de1008..b3895b92 100644
--- a/versions/8.3.1/external/advanced.mdx
+++ b/versions/8.3.1/external/advanced.mdx
@@ -4,10 +4,8 @@ title: 'Advanced topics on external dependencies'
 
 ## Shadowing dependencies in WORKSPACE
 
-Note: This section applies to the [WORKSPACE
-system](/versions/8.3.1/external/overview#workspace-system) only. For
-[Bzlmod](/versions/8.3.1/external/overview#bzlmod), use a [multiple-version
-override](/versions/8.3.1/external/module#multiple-version_override).
+Note: This section applies to the [WORKSPACE system](/versions/8.3.1/external/overview#workspace-system) only. For
+[Bzlmod](/versions/8.3.1/external/overview#bzlmod), use a [multiple-version override](/versions/8.3.1/external/module#multiple-version_override).
 
 Whenever possible, have a single version policy in your project, which is
 required for dependencies that you compile against and end up in your final
@@ -128,29 +126,24 @@ preferring IPv4 if enabled. In some situations, for example when the IPv4
 network cannot resolve/reach external addresses, this can cause `Network
 unreachable` exceptions and build failures. In these cases, you can override
 Bazel's behavior to prefer IPv6 by using the
-[`java.net.preferIPv6Addresses=true` system
-property](https://docs.oracle.com/javase/8/docs/api/java/net/doc-files/net-properties.html).
+[`java.net.preferIPv6Addresses=true` system property](https://docs.oracle.com/javase/8/docs/api/java/net/doc-files/net-properties.html).
 Specifically:
 
-*   Use `--host_jvm_args=-Djava.net.preferIPv6Addresses=true` [startup
-    option](/versions/8.3.1/docs/user-manual#startup-options), for example by adding the
+*   Use `--host_jvm_args=-Djava.net.preferIPv6Addresses=true` [startup option](/versions/8.3.1/docs/user-manual#startup-options), for example by adding the
     following line in your [`.bazelrc` file](/versions/8.3.1/run/bazelrc):
 
     `startup --host_jvm_args=-Djava.net.preferIPv6Addresses=true`
 
 *   When running Java build targets that need to connect to the internet (such
     as for integration tests), use the
-    `--jvmopt=-Djava.net.preferIPv6Addresses=true` [tool
-    flag](/versions/8.3.1/docs/user-manual#jvmopt). For example, include in your [`.bazelrc`
-    file](/versions/8.3.1/run/bazelrc):
+    `--jvmopt=-Djava.net.preferIPv6Addresses=true` [tool flag](/versions/8.3.1/docs/user-manual#jvmopt). For example, include in your [`.bazelrc` file](/versions/8.3.1/run/bazelrc):
 
     `build --jvmopt=-Djava.net.preferIPv6Addresses`
 
 *   If you are using [`rules_jvm_external`](https://github.com/bazelbuild/rules_jvm_external)
     for dependency version resolution, also add
     `-Djava.net.preferIPv6Addresses=true` to the `COURSIER_OPTS` environment
-    variable to [provide JVM options for
-    Coursier](https://github.com/bazelbuild/rules_jvm_external#provide-jvm-options-for-coursier-with-coursier_opts).
+    variable to [provide JVM options for Coursier](https://github.com/bazelbuild/rules_jvm_external#provide-jvm-options-for-coursier-with-coursier_opts).
 
 ## Offline builds
 
@@ -167,15 +160,12 @@ fetch a file with [`ctx.download`](/versions/8.3.1/rules/lib/builtins/repository
 providing a hash sum of the file needed, Bazel looks for a file matching the
 basename of the first URL, and uses the local copy if the hash matches.
 
-Bazel itself uses this technique to bootstrap offline from the [distribution
-artifact](https://github.com/bazelbuild/bazel-website/blob/master/designs/_posts/2016-10-11-distribution-artifact.md).
-It does so by [collecting all the needed external
-dependencies](https://github.com/bazelbuild/bazel/blob/5cfa0303d6ac3b5bd031ff60272ce80a704af8c2/WORKSPACE#L116)
+Bazel itself uses this technique to bootstrap offline from the [distribution artifact](https://github.com/bazelbuild/bazel-website/blob/master/designs/_posts/2016-10-11-distribution-artifact.md).
+It does so by [collecting all the needed external dependencies](https://github.com/bazelbuild/bazel/blob/5cfa0303d6ac3b5bd031ff60272ce80a704af8c2/WORKSPACE#L116)
 in an internal
 [`distdir_tar`](https://github.com/bazelbuild/bazel/blob/5cfa0303d6ac3b5bd031ff60272ce80a704af8c2/distdir.bzl#L44).
 
 Bazel allows execution of arbitrary commands in repository rules without knowing
 if they call out to the network, and so cannot enforce fully offline builds. To
 test if a build works correctly offline, manually block off the network (as
-Bazel does in its [bootstrap
-test](https://cs.opensource.google/bazel/bazel/+/master:src/test/shell/bazel/BUILD;l=1073;drc=88c426e73cc0eb0a41c0d7995e36acd94e7c9a48)).
\ No newline at end of file
+Bazel does in its [bootstrap test](https://cs.opensource.google/bazel/bazel/+/master:src/test/shell/bazel/BUILD;l=1073;drc=88c426e73cc0eb0a41c0d7995e36acd94e7c9a48)).
\ No newline at end of file
diff --git a/versions/8.3.1/external/images/mod_exampleBefore.svg b/versions/8.3.1/external/images/mod_exampleBefore.svg
new file mode 100644
index 00000000..66f01303
--- /dev/null
+++ b/versions/8.3.1/external/images/mod_exampleBefore.svg
@@ -0,0 +1,175 @@
+
+
+
+
+
+
+mygraph
+
+
+
+<root>
+
+<root> (my_project@1.0)
+
+
+
+bazel_skylib@1.1.1
+
+bazel_skylib@1.1.1
+
+
+
+<root>->bazel_skylib@1.1.1
+
+
+
+
+
+bazel_skylib@1.2.0
+
+bazel_skylib@1.2.0
+
+
+
+<root>->bazel_skylib@1.2.0
+
+
+
+
+
+rules_java@5.0.0
+
+rules_java@5.0.0
+
+
+
+<root>->rules_java@5.0.0
+
+
+
+
+
+stardoc@0.5.0
+
+stardoc@0.5.0
+
+
+
+<root>->stardoc@0.5.0
+
+
+
+
+
+platforms@0.0.4
+
+platforms@0.0.4
+
+
+
+bazel_skylib@1.1.1->platforms@0.0.4
+
+
+
+
+
+bazel_skylib@1.2.0->platforms@0.0.4
+
+
+
+
+
+rules_java@5.0.0->platforms@0.0.4
+
+
+
+
+
+rules_cc@0.0.1
+
+rules_cc@0.0.1
+
+
+
+rules_java@5.0.0->rules_cc@0.0.1
+
+
+
+
+
+rules_proto@4.0.0
+
+rules_proto@4.0.0
+
+
+
+rules_java@5.0.0->rules_proto@4.0.0
+
+
+
+
+
+bazel_skylib@1.0.3
+
+bazel_skylib@1.0.3
+
+
+
+stardoc@0.5.0->bazel_skylib@1.0.3
+
+
+
+
+
+rules_java@4.0.0
+
+rules_java@4.0.0
+
+
+
+stardoc@0.5.0->rules_java@4.0.0
+
+
+
+
+
+rules_cc@0.0.1->platforms@0.0.4
+
+
+
+
+
+rules_cc@0.0.1->bazel_skylib@1.0.3
+
+
+
+
+
+rules_proto@4.0.0->rules_cc@0.0.1
+
+
+
+
+
+rules_proto@4.0.0->bazel_skylib@1.0.3
+
+
+
+
+
+bazel_skylib@1.0.3->platforms@0.0.4
+
+
+
+
+
+rules_java@4.0.0->bazel_skylib@1.0.3
+
+
+
+
+
\ No newline at end of file
diff --git a/versions/8.3.1/external/images/mod_exampleResolved.svg b/versions/8.3.1/external/images/mod_exampleResolved.svg
new file mode 100644
index 00000000..224b694c
--- /dev/null
+++ b/versions/8.3.1/external/images/mod_exampleResolved.svg
@@ -0,0 +1,151 @@
+
+
+
+
+
+
+mygraph
+
+
+
+<root>
+
+<root> (my_project@1.0)
+
+
+
+bazel_skylib@1.1.1
+
+bazel_skylib@1.1.1
+
+
+
+<root>->bazel_skylib@1.1.1
+
+
+
+
+
+bazel_skylib@1.2.0
+
+bazel_skylib@1.2.0
+
+
+
+<root>->bazel_skylib@1.2.0
+
+
+
+
+
+rules_java@5.0.0
+
+rules_java@5.0.0
+
+
+
+<root>->rules_java@5.0.0
+
+
+
+
+
+stardoc@0.5.0
+
+stardoc@0.5.0
+
+
+
+<root>->stardoc@0.5.0
+
+
+
+
+
+platforms@0.0.4
+
+platforms@0.0.4
+
+
+
+bazel_skylib@1.1.1->platforms@0.0.4
+
+
+
+
+
+bazel_skylib@1.2.0->platforms@0.0.4
+
+
+
+
+
+rules_java@5.0.0->platforms@0.0.4
+
+
+
+
+
+rules_cc@0.0.1
+
+rules_cc@0.0.1
+
+
+
+rules_java@5.0.0->rules_cc@0.0.1
+
+
+
+
+
+rules_proto@4.0.0
+
+rules_proto@4.0.0
+
+
+
+rules_java@5.0.0->rules_proto@4.0.0
+
+
+
+
+
+stardoc@0.5.0->bazel_skylib@1.1.1
+
+
+
+
+
+stardoc@0.5.0->rules_java@5.0.0
+
+
+
+
+
+rules_cc@0.0.1->bazel_skylib@1.1.1
+
+
+
+
+
+rules_cc@0.0.1->platforms@0.0.4
+
+
+
+
+
+rules_proto@4.0.0->bazel_skylib@1.1.1
+
+
+
+
+
+rules_proto@4.0.0->rules_cc@0.0.1
+
+
+
+
+
\ No newline at end of file
diff --git a/versions/8.3.1/external/migration.mdx b/versions/8.3.1/external/migration.mdx
index 86b75f20..8e4c42eb 100644
--- a/versions/8.3.1/external/migration.mdx
+++ b/versions/8.3.1/external/migration.mdx
@@ -2,8 +2,7 @@
 title: 'Bzlmod Migration Guide'
 ---
 
-Due to the [shortcomings of
-WORKSPACE](/versions/8.3.1/external/overview#workspace-shortcomings), Bzlmod is going to
+Due to the [shortcomings of WORKSPACE](/versions/8.3.1/external/overview#workspace-shortcomings), Bzlmod is going to
 replace the legacy WORKSPACE system. The WORKSPACE file will be disabled by
 default in Bazel 8 (late 2024) and will be removed in Bazel 9 (late 2025).
 This guide helps you migrate your project to Bzlmod and drop WORKSPACE for
@@ -117,9 +116,7 @@ Bazel module when it also adopts Bzlmod.
 
 *   **Bzlmod**
 
-    With Bzlmod, as long as the your dependency is available in [Bazel Central
-    Registry](https://registry.bazel.build) or your custom [Bazel
-    registry](/versions/8.3.1/external/registry), you can simply depend on it with a
+    With Bzlmod, as long as the your dependency is available in [Bazel Central Registry](https://registry.bazel.build) or your custom [Bazel registry](/versions/8.3.1/external/registry), you can simply depend on it with a
     [`bazel_dep`](/versions/8.3.1/rules/lib/globals/module#bazel_dep) directive.
 
     ```python
@@ -150,8 +147,7 @@ repository.
 
 If your dependency is not a Bazel project or not yet available in any Bazel
 registry, you can introduce it using
-[`use_repo_rule`](/versions/8.3.1/external/module#use_repo_rule) or [module
-extensions](/versions/8.3.1/external/extension).
+[`use_repo_rule`](/versions/8.3.1/external/module#use_repo_rule) or [module extensions](/versions/8.3.1/external/extension).
 
 *   **WORKSPACE**
 
@@ -604,8 +600,7 @@ macros.
 Fortunately, the flag
 [`--experimental_repository_resolved_file`][resolved_file_flag]
 can help. This flag essentially generates a "lock file" of all fetched external
-dependencies in your last Bazel command. You can find more details in this [blog
-post](https://blog.bazel.build/2018/07/09/bazel-sync-and-resolved-file.html).
+dependencies in your last Bazel command. You can find more details in this [blog post](https://blog.bazel.build/2018/07/09/bazel-sync-and-resolved-file.html).
 
 [resolved_file_flag]: /reference/command-line-reference#flag--experimental_repository_resolved_file
 
@@ -646,11 +641,9 @@ You may also know `bazel query` can be used for inspecting repository rules with
 bazel query --output=build //external:
 ```
 
-While it is more convenient and much faster, [bazel query can lie about
-external dependency version](https://github.com/bazelbuild/bazel/issues/12947),
+While it is more convenient and much faster, [bazel query can lie about external dependency version](https://github.com/bazelbuild/bazel/issues/12947),
 so be careful using it! Querying and inspecting external
-dependencies with Bzlmod is going to achieved by a [new
-subcommand](https://github.com/bazelbuild/bazel/issues/15365).
+dependencies with Bzlmod is going to achieved by a [new subcommand](https://github.com/bazelbuild/bazel/issues/15365).
 
 #### Built-in default dependencies {#builtin-default-deps}
 
@@ -697,8 +690,7 @@ Using the WORKSPACE.bzlmod file can make the migration easier because:
 #### Repository visibility {#repository-visibility}
 
 Bzlmod is able to control which other repositories are visible from a given
-repository, check [repository names and strict
-deps](/versions/8.3.1/external/module#repository_names_and_strict_deps) for more details.
+repository, check [repository names and strict deps](/versions/8.3.1/external/module#repository_names_and_strict_deps) for more details.
 
 Here is a summary of repository visibilities from different types of
 repositories when also taking WORKSPACE into consideration.
@@ -711,8 +703,7 @@ repositories when also taking WORKSPACE into consideration.
 | WORKSPACE Repos | All visible | Not visible | Not visible | All visible |
 
 Note: For the root module, if a repository `@foo` is defined in WORKSPACE and
-`@foo` is also used as an [apparent repository
-name](/versions/8.3.1/external/overview#apparent-repo-name) in MODULE.bazel, then `@foo`
+`@foo` is also used as an [apparent repository name](/versions/8.3.1/external/overview#apparent-repo-name) in MODULE.bazel, then `@foo`
 refers to the one introduced in MODULE.bazel.
 
 Note: For a module extension generated repository `@bar`, if `@foo` is used as
@@ -787,9 +778,7 @@ the project. Take note of a few things when creating the source archive:
     GitHub isn't going to guarantee the checksum of source archives generated on
     demand. In short, URLs in the form of
     `https://github.com///releases/download/...` is considered stable
-    while `https://github.com///archive/...` is not. Check [GitHub
-    Archive Checksum
-    Outage](https://blog.bazel.build/2023/02/15/github-archive-checksum.html)
+    while `https://github.com///archive/...` is not. Check [GitHub Archive Checksum Outage](https://blog.bazel.build/2023/02/15/github-archive-checksum.html)
     for more context.
 
 *   **Make sure the source tree follows the layout of the original repository.**
@@ -818,8 +807,7 @@ Pull Request.
 
 [bcr_contrib_guide]: https://github.com/bazelbuild/bazel-central-registry/tree/main/docs#contribute-a-bazel-module
 
-It is **highly recommended** to set up the [Publish to
-BCR](https://github.com/bazel-contrib/publish-to-bcr) GitHub App for your
+It is **highly recommended** to set up the [Publish to BCR](https://github.com/bazel-contrib/publish-to-bcr) GitHub App for your
 repository to automate the process of submitting your module to the BCR.
 
 ## Best practices {#best-practices}
diff --git a/versions/8.3.1/external/mod-command.mdx b/versions/8.3.1/external/mod-command.mdx
index e49acc52..479bcc40 100644
--- a/versions/8.3.1/external/mod-command.mdx
+++ b/versions/8.3.1/external/mod-command.mdx
@@ -61,11 +61,9 @@ The available subcommands and their respective required arguments are:
 
 *   ``: All present versions of the module ``.
 
-*   `@`: The repo with the given [apparent
-    name](overview#apparent-repo-name) in the context of the `--base_module`.
+*   `@`: The repo with the given [apparent name](/versions/8.3.1/external/overview#apparent-repo-name) in the context of the `--base_module`.
 
-*   `@@`: The repo with the given [canonical
-    name](overview#canonical-repo-name).
+*   `@@`: The repo with the given [canonical name](/versions/8.3.1/external/overview#canonical-repo-name).
 
 In a context requiring specifying modules, ``s referring to repos that
 correspond to modules (as opposed to extension-generated repos) can also be
@@ -87,8 +85,7 @@ The following options only affect the subcommands that print graphs (`graph`,
     information about the version resolution of each module. If the module
     version changed during resolution, show either which version replaced it or
     what was the original version, the reason it was replaced, and which modules
-    requested the new version if the reason was [Minimal Version
-    Selection](module#version-selection).
+    requested the new version if the reason was [Minimal Version Selection](/versions/8.3.1/external/module#version-selection).
 
 *   `--include_unused` *default: "false"*: Include in the output graph the
     modules which were originally present in the dependency graph, but became
@@ -192,7 +189,7 @@ use_repo(toolchains, my_jdk="remotejdk17_linux")
   

     
       

-        Graph Before Resolution
+        Graph Before Resolution
         
Graph Before Resolution

       

 {/* digraph mygraph {
@@ -222,7 +219,7 @@ use_repo(toolchains, my_jdk="remotejdk17_linux")
     		
     
       

-        Graph After Resolution
+        Graph After Resolution
        
Graph After Resolution

       

 {/* digraph mygraph {
diff --git a/versions/8.3.1/external/module.mdx b/versions/8.3.1/external/module.mdx
index 42bfcfbf..ba934039 100644
--- a/versions/8.3.1/external/module.mdx
+++ b/versions/8.3.1/external/module.mdx
@@ -122,8 +122,7 @@ serves multiple purposes:
     version, regardless of which versions of the dependency are requested in the
     dependency graph.
 *   With the `registry` attribute, you can force this dependency to come from a
-    specific registry, instead of following the normal [registry
-    selection](/versions/8.3.1/external/registry#selecting_registries) process.
+    specific registry, instead of following the normal [registry selection](/versions/8.3.1/external/registry#selecting_registries) process.
 *   With the `patch*` attributes, you can specify a set of patches to apply to
     the downloaded module.
 
@@ -176,13 +175,11 @@ With `bazel_dep`, you can define repos that represent other Bazel modules.
 Sometimes there is a need to define a repo that does _not_ represent a Bazel
 module; for example, one that contains a plain JSON file to be read as data.
 
-In this case, you could use the [`use_repo_rule`
-directive](/versions/8.3.1/rules/lib/globals/module#use_repo_rule) to directly define a repo
+In this case, you could use the [`use_repo_rule` directive](/versions/8.3.1/rules/lib/globals/module#use_repo_rule) to directly define a repo
 by invoking a repo rule. This repo will only be visible to the module it's
 defined in.
 
-Under the hood, this is implemented using the same mechanism as [module
-extensions](/versions/8.3.1/external/extension), which lets you define repos with more
+Under the hood, this is implemented using the same mechanism as [module extensions](/versions/8.3.1/external/extension), which lets you define repos with more
 flexibility.
 
 ## Repository names and strict deps
diff --git a/versions/8.3.1/external/overview.mdx b/versions/8.3.1/external/overview.mdx
index 866e6a6e..99663b7d 100644
--- a/versions/8.3.1/external/overview.mdx
+++ b/versions/8.3.1/external/overview.mdx
@@ -128,8 +128,7 @@ for all build targets inside the repo.
 
 The syntax of a `REPO.bazel` file is similar to `BUILD` files, except that no
 `load` statements are supported, and only a single function, `repo()`, is
-available. `repo()` takes the same arguments as the [`package()`
-function](/versions/8.3.1/reference/be/functions#package) in `BUILD` files; whereas `package()`
+available. `repo()` takes the same arguments as the [`package()` function](/versions/8.3.1/reference/be/functions#package) in `BUILD` files; whereas `package()`
 specifies common attributes for all build targets inside the package, `repo()`
 analogously does so for all build targets inside the repo.
 
@@ -163,8 +162,7 @@ bazel_dep(name = "protobuf", version = "3.19.0")
 ```
 
 A module must only list its direct dependencies, which Bzlmod looks up in a
-[Bazel registry](/versions/8.3.1/external/registry) — by default, the [Bazel Central
-Registry](https://bcr.bazel.build/). The registry provides the
+[Bazel registry](/versions/8.3.1/external/registry) — by default, the [Bazel Central Registry](https://bcr.bazel.build/). The registry provides the
 dependencies' `MODULE.bazel` files, which allows Bazel to discover the entire
 transitive dependency graph before performing version resolution.
 
@@ -235,5 +233,4 @@ many pain points, including:
         `B` and `C`; `B` and `C` both depend on different versions of `D`).
 
 Due to the shortcomings of WORKSPACE, Bzlmod is going to replace the legacy
-WORKSPACE system in future Bazel releases. Please read the [Bzlmod migration
-guide](/versions/8.3.1/external/migration) on how to migrate to Bzlmod.
+WORKSPACE system in future Bazel releases. Please read the [Bzlmod migration guide](/versions/8.3.1/external/migration) on how to migrate to Bzlmod.
diff --git a/versions/8.3.1/external/registry.mdx b/versions/8.3.1/external/registry.mdx
index fdf438dd..57581359 100644
--- a/versions/8.3.1/external/registry.mdx
+++ b/versions/8.3.1/external/registry.mdx
@@ -42,8 +42,7 @@ An index registry must follow the format below:
             project
         *   `versions`: A list of all the versions of this module to be found in
             this registry
-        *   `yanked_versions`: A map of [*yanked*
-            versions](/versions/8.3.1/external/module#yanked_versions) of this module. The keys
+        *   `yanked_versions`: A map of [*yanked* versions](/versions/8.3.1/external/module#yanked_versions) of this module. The keys
             should be versions to yank and the values should be descriptions of
             why the version is yanked, ideally containing a link to more
             information
@@ -56,8 +55,7 @@ An index registry must follow the format below:
             *   `url`: The URL of the source archive
             *   `mirror_urls`: A list of string, the mirror URLs of the source archive.
                 The URLs are tried in order after `url` as backups.
-            *   `integrity`: The [Subresource
-                Integrity](https://w3c.github.io/webappsec-subresource-integrity/#integrity-metadata-description)
+            *   `integrity`: The [Subresource Integrity](https://w3c.github.io/webappsec-subresource-integrity/#integrity-metadata-description)
                 checksum of the archive
             *   `strip_prefix`: A directory prefix to strip when extracting the
                 source archive
@@ -105,8 +103,7 @@ You can browse its contents using the web frontend at
 https://registry.bazel.build/.
 
 The Bazel community maintains the BCR, and contributors are welcome to submit
-pull requests. See the [BCR contribution
-guidelines](https://github.com/bazelbuild/bazel-central-registry/blob/main/docs/README.md).
+pull requests. See the [BCR contribution guidelines](https://github.com/bazelbuild/bazel-central-registry/blob/main/docs/README.md).
 
 In addition to following the format of a normal index registry, the BCR requires
 a `presubmit.yml` file for each module version
diff --git a/versions/8.3.1/external/vendor.mdx b/versions/8.3.1/external/vendor.mdx
index 888f64ce..99750519 100644
--- a/versions/8.3.1/external/vendor.mdx
+++ b/versions/8.3.1/external/vendor.mdx
@@ -23,9 +23,7 @@ absolute path.
 ## Vendor a specific external repository {#vendor-specific-repository}
 
 You can use the `vendor` command with the `--repo` flag to specify which repo
-to vendor, it accepts both [canonical repo
-name](/versions/8.3.1/external/overview#canonical-repo-name) and [apparent repo
-name](/versions/8.3.1/external/overview#apparent-repo-name).
+to vendor, it accepts both [canonical repo name](/versions/8.3.1/external/overview#canonical-repo-name) and [apparent repo name](/versions/8.3.1/external/overview#apparent-repo-name).
 
 For example, running:
 
diff --git a/versions/8.3.1/help.mdx b/versions/8.3.1/help.mdx
index 7a401454..a06d83c9 100644
--- a/versions/8.3.1/help.mdx
+++ b/versions/8.3.1/help.mdx
@@ -46,5 +46,4 @@ what level of support Bazel provides.
 
 ## File a bug {#file-bug}
 
-If you encounter a bug or want to request a feature, file a [GitHub
-Issue](https://github.com/bazelbuild/bazel/issues).
+If you encounter a bug or want to request a feature, file a [GitHub Issue](https://github.com/bazelbuild/bazel/issues).
diff --git a/versions/8.3.1/images/about.svg b/versions/8.3.1/images/about.svg
new file mode 100644
index 00000000..f927298f
--- /dev/null
+++ b/versions/8.3.1/images/about.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/8.3.1/images/basics.svg b/versions/8.3.1/images/basics.svg
new file mode 100644
index 00000000..013ec519
--- /dev/null
+++ b/versions/8.3.1/images/basics.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/8.3.1/images/bazel_hero.svg b/versions/8.3.1/images/bazel_hero.svg
new file mode 100644
index 00000000..c48714d0
--- /dev/null
+++ b/versions/8.3.1/images/bazel_hero.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/8.3.1/images/community.svg b/versions/8.3.1/images/community.svg
new file mode 100644
index 00000000..29f87a76
--- /dev/null
+++ b/versions/8.3.1/images/community.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/8.3.1/images/distributed-build-remote-cache.png b/versions/8.3.1/images/distributed-build-remote-cache.png
new file mode 100644
index 00000000..99d8a915
Binary files /dev/null and b/versions/8.3.1/images/distributed-build-remote-cache.png differ
diff --git a/versions/8.3.1/images/essential_guide.svg b/versions/8.3.1/images/essential_guide.svg
new file mode 100644
index 00000000..4ee63ae9
--- /dev/null
+++ b/versions/8.3.1/images/essential_guide.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/8.3.1/images/essential_reference.svg b/versions/8.3.1/images/essential_reference.svg
new file mode 100644
index 00000000..4d29a8d5
--- /dev/null
+++ b/versions/8.3.1/images/essential_reference.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/8.3.1/images/essential_start.svg b/versions/8.3.1/images/essential_start.svg
new file mode 100644
index 00000000..c8f48f84
--- /dev/null
+++ b/versions/8.3.1/images/essential_start.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/8.3.1/images/extend.svg b/versions/8.3.1/images/extend.svg
new file mode 100644
index 00000000..77b2dd97
--- /dev/null
+++ b/versions/8.3.1/images/extend.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/8.3.1/images/guide.svg b/versions/8.3.1/images/guide.svg
new file mode 100644
index 00000000..23a5d35a
--- /dev/null
+++ b/versions/8.3.1/images/guide.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/8.3.1/images/high-level-build-system.png b/versions/8.3.1/images/high-level-build-system.png
new file mode 100644
index 00000000..462717fa
Binary files /dev/null and b/versions/8.3.1/images/high-level-build-system.png differ
diff --git a/versions/8.3.1/images/new_1.svg b/versions/8.3.1/images/new_1.svg
new file mode 100644
index 00000000..c4cd9dfd
--- /dev/null
+++ b/versions/8.3.1/images/new_1.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/8.3.1/images/new_2.svg b/versions/8.3.1/images/new_2.svg
new file mode 100644
index 00000000..c6b7021b
--- /dev/null
+++ b/versions/8.3.1/images/new_2.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/8.3.1/images/new_3.svg b/versions/8.3.1/images/new_3.svg
new file mode 100644
index 00000000..c2afb4ac
--- /dev/null
+++ b/versions/8.3.1/images/new_3.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/8.3.1/images/placeholder.png b/versions/8.3.1/images/placeholder.png
new file mode 100644
index 00000000..54f1fa0e
Binary files /dev/null and b/versions/8.3.1/images/placeholder.png differ
diff --git a/versions/8.3.1/images/reference.svg b/versions/8.3.1/images/reference.svg
new file mode 100644
index 00000000..7bbc9bea
--- /dev/null
+++ b/versions/8.3.1/images/reference.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/8.3.1/images/release_notes.svg b/versions/8.3.1/images/release_notes.svg
new file mode 100644
index 00000000..8a2e8b56
--- /dev/null
+++ b/versions/8.3.1/images/release_notes.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/8.3.1/images/remote-execution-system.png b/versions/8.3.1/images/remote-execution-system.png
new file mode 100644
index 00000000..8152fc0c
Binary files /dev/null and b/versions/8.3.1/images/remote-execution-system.png differ
diff --git a/versions/8.3.1/images/start.svg b/versions/8.3.1/images/start.svg
new file mode 100644
index 00000000..3bcebd7b
--- /dev/null
+++ b/versions/8.3.1/images/start.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/8.3.1/images/task-dependencies.png b/versions/8.3.1/images/task-dependencies.png
new file mode 100644
index 00000000..ae1f9c51
Binary files /dev/null and b/versions/8.3.1/images/task-dependencies.png differ
diff --git a/versions/8.3.1/images/test.png b/versions/8.3.1/images/test.png
new file mode 100644
index 00000000..243939da
Binary files /dev/null and b/versions/8.3.1/images/test.png differ
diff --git a/versions/8.3.1/images/transitive-dependencies.png b/versions/8.3.1/images/transitive-dependencies.png
new file mode 100644
index 00000000..ec641a08
Binary files /dev/null and b/versions/8.3.1/images/transitive-dependencies.png differ
diff --git a/versions/8.3.1/images/trunk-logo-dark.svg b/versions/8.3.1/images/trunk-logo-dark.svg
new file mode 100644
index 00000000..f25940af
--- /dev/null
+++ b/versions/8.3.1/images/trunk-logo-dark.svg
@@ -0,0 +1,22 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/versions/8.3.1/images/why_faq.svg b/versions/8.3.1/images/why_faq.svg
new file mode 100644
index 00000000..afec3f8f
--- /dev/null
+++ b/versions/8.3.1/images/why_faq.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/8.3.1/images/why_overview.svg b/versions/8.3.1/images/why_overview.svg
new file mode 100644
index 00000000..c10c363c
--- /dev/null
+++ b/versions/8.3.1/images/why_overview.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/8.3.1/images/why_vision.svg b/versions/8.3.1/images/why_vision.svg
new file mode 100644
index 00000000..739e415f
--- /dev/null
+++ b/versions/8.3.1/images/why_vision.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/8.3.1/install/bazelisk.mdx b/versions/8.3.1/install/bazelisk.mdx
index 8dd03b1e..aa10d046 100644
--- a/versions/8.3.1/install/bazelisk.mdx
+++ b/versions/8.3.1/install/bazelisk.mdx
@@ -16,8 +16,7 @@ For more details, see
 ## Updating Bazel
 
 Bazel has a [backward compatibility policy](/versions/8.3.1/release/backward-compatibility)
-(see [guidance for rolling out incompatible
-changes](/versions/8.3.1/contribute/breaking-changes) if you
+(see [guidance for rolling out incompatible changes](/versions/8.3.1/contribute/breaking-changes) if you
 are the author of one). That page summarizes best practices on how to test and
 migrate your project with upcoming incompatible changes and how to provide
 feedback to the incompatible change authors.
diff --git a/versions/8.3.1/install/compile-source.mdx b/versions/8.3.1/install/compile-source.mdx
index 47a813dd..11312f2e 100644
--- a/versions/8.3.1/install/compile-source.mdx
+++ b/versions/8.3.1/install/compile-source.mdx
@@ -45,8 +45,7 @@ it by typing `bazel` in a terminal.
 
 **Reason**: To build Bazel from a GitHub source tree, you need a pre-existing
 Bazel binary. You can install one from a package manager or download one from
-GitHub. See [Installing Bazel](/versions/8.3.1/install). (Or you can [build from
-scratch (bootstrap)](#bootstrap-bazel).)
+GitHub. See [Installing Bazel](/versions/8.3.1/install). (Or you can [build from scratch (bootstrap)](#bootstrap-bazel).)
 
 **Troubleshooting**:
 
@@ -239,8 +238,7 @@ For instructions for Unix-like systems, see
     ```
 
 *   **The Visual C++ compiler.** Install the Visual C++ compiler either as part
-    of Visual Studio 2015 or newer, or by installing the latest [Build Tools
-    for Visual Studio 2017](https://aka.ms/BuildTools).
+    of Visual Studio 2015 or newer, or by installing the latest [Build Tools for Visual Studio 2017](https://aka.ms/BuildTools).
 
 *   **JDK.** Version 21 is required.
 
diff --git a/versions/8.3.1/install/ide.mdx b/versions/8.3.1/install/ide.mdx
index 561d0e02..c42d95e9 100644
--- a/versions/8.3.1/install/ide.mdx
+++ b/versions/8.3.1/install/ide.mdx
@@ -38,10 +38,8 @@ To install, go to the IDE's plugin browser and search for `Bazel`.
 To manually install older versions, download the zip files from JetBrains'
 Plugin Repository and install the zip file from the IDE's plugin browser:
 
-*  [Android Studio
-   plugin](https://plugins.jetbrains.com/plugin/9185-android-studio-with-bazel)
-*  [IntelliJ
-   plugin](https://plugins.jetbrains.com/plugin/8609-intellij-with-bazel)
+*  [Android Studio plugin](https://plugins.jetbrains.com/plugin/9185-android-studio-with-bazel)
+*  [IntelliJ plugin](https://plugins.jetbrains.com/plugin/8609-intellij-with-bazel)
 *  [CLion plugin](https://plugins.jetbrains.com/plugin/9554-clion-with-bazel)
 
 ### Xcode {#xcode}
@@ -61,8 +59,7 @@ Features:
 * Starlark debugger for `.bzl` files during a build (set breakpoints, step
   through code, inspect variables, and so on)
 
-Find [the plugin on the Visual Studio
-marketplace](https://marketplace.visualstudio.com/items?itemName=BazelBuild.vscode-bazel).
+Find [the plugin on the Visual Studio marketplace](https://marketplace.visualstudio.com/items?itemName=BazelBuild.vscode-bazel).
 The plugin is [open source](https://github.com/bazelbuild/vscode-bazel).
 
 See also: [Autocomplete for Source Code](#autocomplete-for-source-code)
@@ -82,8 +79,7 @@ See also: [Autocomplete for Source Code](#autocomplete-for-source-code)
 
 ### Emacs {#emacs}
 
-See [`bazelbuild/bazel-emacs-mode` on
-GitHub](https://github.com/bazelbuild/emacs-bazel-mode)
+See [`bazelbuild/bazel-emacs-mode` on GitHub](https://github.com/bazelbuild/emacs-bazel-mode)
 
 See also: [Autocomplete for Source Code](#autocomplete-for-source-code)
 
@@ -115,6 +111,5 @@ tool for building Bazel targets when source files change.
 
 ## Building your own IDE plugin {#build-own-plugin}
 
-Read the [**IDE support** blog
-post](https://blog.bazel.build/2016/06/10/ide-support.html) to learn more about
+Read the [**IDE support** blog post](https://blog.bazel.build/2016/06/10/ide-support.html) to learn more about
 the Bazel APIs to use when building an IDE plugin.
diff --git a/versions/8.3.1/install/images/bazelisk.svg b/versions/8.3.1/install/images/bazelisk.svg
new file mode 100644
index 00000000..c0ae9f54
--- /dev/null
+++ b/versions/8.3.1/install/images/bazelisk.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/8.3.1/install/images/cli.svg b/versions/8.3.1/install/images/cli.svg
new file mode 100644
index 00000000..01119280
--- /dev/null
+++ b/versions/8.3.1/install/images/cli.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/8.3.1/install/images/docker.svg b/versions/8.3.1/install/images/docker.svg
new file mode 100644
index 00000000..21190ce0
--- /dev/null
+++ b/versions/8.3.1/install/images/docker.svg
@@ -0,0 +1,6 @@
+
\ No newline at end of file
diff --git a/versions/8.3.1/install/images/github.svg b/versions/8.3.1/install/images/github.svg
new file mode 100644
index 00000000..aa05db9c
--- /dev/null
+++ b/versions/8.3.1/install/images/github.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/8.3.1/install/images/install.svg b/versions/8.3.1/install/images/install.svg
new file mode 100644
index 00000000..ae080865
--- /dev/null
+++ b/versions/8.3.1/install/images/install.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/8.3.1/install/images/mac.svg b/versions/8.3.1/install/images/mac.svg
new file mode 100644
index 00000000..3ee4fe28
--- /dev/null
+++ b/versions/8.3.1/install/images/mac.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/8.3.1/install/images/redhat.svg b/versions/8.3.1/install/images/redhat.svg
new file mode 100644
index 00000000..078b3387
--- /dev/null
+++ b/versions/8.3.1/install/images/redhat.svg
@@ -0,0 +1,69 @@
+
+
+  
+    
+      
+        image/svg+xml
+        
+        
+      
+    
+  
+  
+  
+    
+  
+  
+  
+
diff --git a/versions/8.3.1/install/images/suse.png b/versions/8.3.1/install/images/suse.png
new file mode 100644
index 00000000..6435b689
Binary files /dev/null and b/versions/8.3.1/install/images/suse.png differ
diff --git a/versions/8.3.1/install/images/tune.svg b/versions/8.3.1/install/images/tune.svg
new file mode 100644
index 00000000..8d7d63cb
--- /dev/null
+++ b/versions/8.3.1/install/images/tune.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/8.3.1/install/images/ubuntu.svg b/versions/8.3.1/install/images/ubuntu.svg
new file mode 100644
index 00000000..f217bc8d
--- /dev/null
+++ b/versions/8.3.1/install/images/ubuntu.svg
@@ -0,0 +1,8 @@
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/versions/8.3.1/install/images/windows.svg b/versions/8.3.1/install/images/windows.svg
new file mode 100644
index 00000000..120b0190
--- /dev/null
+++ b/versions/8.3.1/install/images/windows.svg
@@ -0,0 +1,5 @@
+
+
+
+
+
\ No newline at end of file
diff --git a/versions/8.3.1/install/windows.mdx b/versions/8.3.1/install/windows.mdx
index beab6126..a0cd3939 100644
--- a/versions/8.3.1/install/windows.mdx
+++ b/versions/8.3.1/install/windows.mdx
@@ -31,8 +31,7 @@ To check your Windows version:
 
 Alternatively you can:
 
-*   [Download the Bazel binary (`bazel-version-windows-x86_64.exe`) from
- GitHub](https://github.com/bazelbuild/bazel/releases).
+*   [Download the Bazel binary (`bazel-version-windows-x86_64.exe`) from GitHub](https://github.com/bazelbuild/bazel/releases).
 *   [Install Bazel from Chocolatey](#chocolately)
 *   [Install Bazel from Scoop](#scoop)
 *   [Build Bazel from source](/versions/8.3.1/install/compile-source)
@@ -208,8 +207,7 @@ If that doesn't help:
     its dependencies, such as the MSYS2 shell. This will not install Visual C++
     though.
 
-See [Chocolatey installation and package maintenance
-guide](/versions/8.3.1/contribute/windows-chocolatey-maintenance) for more
+See [Chocolatey installation and package maintenance guide](/versions/8.3.1/contribute/windows-chocolatey-maintenance) for more
 information about the Chocolatey package.
 
 ### Using Scoop {#scoop}
@@ -226,8 +224,7 @@ information about the Chocolatey package.
     scoop install bazel
     ```
 
-See [Scoop installation and package maintenance
-guide](/versions/8.3.1/contribute/windows-scoop-maintenance) for more
+See [Scoop installation and package maintenance guide](/versions/8.3.1/contribute/windows-scoop-maintenance) for more
 information about the Scoop package.
 
 ### Build from source {#build-from-source}
diff --git a/versions/8.3.1/migrate/maven.mdx b/versions/8.3.1/migrate/maven.mdx
index 5615fd38..d2848efc 100644
--- a/versions/8.3.1/migrate/maven.mdx
+++ b/versions/8.3.1/migrate/maven.mdx
@@ -19,8 +19,7 @@ directly run by Bazel since there's no Maven compatibility layer.
 ## Before you begin {#before-you-begin}
 
 *   [Install Bazel](/versions/8.3.1/install) if it's not yet installed.
-*   If you're new to Bazel, go through the tutorial [Introduction to Bazel:
-    Build Java](/versions/8.3.1/start/java) before you start migrating. The tutorial explains
+*   If you're new to Bazel, go through the tutorial [Introduction to Bazel: Build Java](/versions/8.3.1/start/java) before you start migrating. The tutorial explains
     Bazel's concepts, structure, and label syntax.
 
 ## Differences between Maven and Bazel {#dif-maven-bazel}
@@ -44,8 +43,7 @@ The steps below describe how to migrate your project to Bazel:
 3.  [Create more BUILD files](#3-build)
 4.  [Build using Bazel](#4-build)
 
-Examples below come from a migration of the [Guava
-project](https://github.com/google/guava) from Maven to Bazel. The
+Examples below come from a migration of the [Guava project](https://github.com/google/guava) from Maven to Bazel. The
 Guava project used is release `v31.1`. The examples using Guava do not walk
 through each step in the migration, but they do show the files and contents that
 are generated or added manually for the migration.
@@ -63,14 +61,12 @@ has no external dependencies, this file can be empty.
 If your project depends on files or packages that are not in one of the
 project's directories, specify these external dependencies in the MODULE.bazel
 file. You can use `rules_jvm_external` to manage dependencies from Maven. For
-instructions about using this ruleset, see [the
-README](https://github.com/bazelbuild/rules_jvm_external/#rules_jvm_external)
+instructions about using this ruleset, see [the README](https://github.com/bazelbuild/rules_jvm_external/#rules_jvm_external)
 .
 
 #### Guava project example: external dependencies {#guava-1}
 
-You can list the external dependencies of the [Guava
-project](https://github.com/google/guava) with the
+You can list the external dependencies of the [Guava project](https://github.com/google/guava) with the
 [`rules_jvm_external`](https://github.com/bazelbuild/rules_jvm_external)
 ruleset.
 
@@ -164,8 +160,7 @@ your build by adding more `BUILD` files with more granular targets.
             *   `resources`: Use globbing to list all resources in your project.
             *   `deps`: You need to determine which external dependencies your
                 project needs.
-        *   Take a look at the [example below of this top-level BUILD
-            file](#guava-2) from the migration of the Guava project.
+        *   Take a look at the [example below of this top-level BUILD file](#guava-2) from the migration of the Guava project.
 
 3.  Now that you have a `BUILD` file at the root of your project, build your
     project to ensure that it works. On the command line, from your workspace
diff --git a/versions/8.3.1/migrate/xcode.mdx b/versions/8.3.1/migrate/xcode.mdx
index c65a095e..8744e79c 100644
--- a/versions/8.3.1/migrate/xcode.mdx
+++ b/versions/8.3.1/migrate/xcode.mdx
@@ -32,8 +32,7 @@ Before you begin, do the following:
 
 1.  [Install Bazel](/versions/8.3.1/install) if you have not already done so.
 
-2.  If you're not familiar with Bazel and its concepts, complete the [iOS app
-    tutorial](/versions/8.3.1/start/ios-app)). You should understand the Bazel workspace,
+2.  If you're not familiar with Bazel and its concepts, complete the [iOS app tutorial](/versions/8.3.1/start/ios-app)). You should understand the Bazel workspace,
     including the `MODULE.bazel` and `BUILD` files, as well as the concepts of
     targets, build rules, and Bazel packages.
 
@@ -44,8 +43,7 @@ Before you begin, do the following:
 Unlike Xcode, Bazel requires you to explicitly declare all dependencies for
 every target in the `BUILD` file.
 
-For more information on external dependencies, see [Working with external
-dependencies](/versions/8.3.1/docs/external).
+For more information on external dependencies, see [Working with external dependencies](/versions/8.3.1/docs/external).
 
 ## Build or test an Xcode project with Bazel {#build-xcode-project}
 
@@ -84,8 +82,7 @@ Note: Place the project source code within the directory tree containing the
 
 To integrate SwiftPM dependencies into the Bazel workspace with
 [swift_bazel](https://github.com/cgrindel/swift_bazel), you must
-convert them into Bazel packages as described in the [following
-tutorial](https://chuckgrindel.com/swift-packages-in-bazel-using-swift_bazel/)
+convert them into Bazel packages as described in the [following tutorial](https://chuckgrindel.com/swift-packages-in-bazel-using-swift_bazel/)
 .
 
 Note: SwiftPM support is a manual process with many variables. SwiftPM
@@ -103,8 +100,7 @@ initial build of the project as follows:
 *   [Step 3b: (Optional) Add the test target(s)](#step-3b-optional-add-the-test-target-s)
 *   [Step 3c: Add the library target(s)](#step-3c-add-the-library-target-s)
 
-**Tip:** To learn more about packages and other Bazel concepts, see [Workspaces,
-packages, and targets](/versions/8.3.1/concepts/build-ref).
+**Tip:** To learn more about packages and other Bazel concepts, see [Workspaces, packages, and targets](/versions/8.3.1/concepts/build-ref).
 
 #### Step 3a: Add the application target {#add-app-target}
 
@@ -132,8 +128,7 @@ In the target, specify the following at the minimum:
 
 #### Step 3b: (Optional) Add the test target(s) {#add-test-target}
 
-Bazel's [Apple build
-rules](https://github.com/bazelbuild/rules_apple) support running
+Bazel's [Apple build rules](https://github.com/bazelbuild/rules_apple) support running
 unit and UI tests on all Apple platforms. Add test targets as follows:
 
 *   [`macos_unit_test`](https://github.com/bazelbuild/rules_apple/blob/master/doc/rules-macos.md#macos_unit_test)
@@ -181,8 +176,7 @@ all sources and/or headers of a certain type. Use it carefully as it might
 include files you do not want Bazel to build.
 
 You can browse existing examples for various types of applications directly in
-the [rules_apple examples
-directory](https://github.com/bazelbuild/rules_apple/tree/master/examples/). For
+the [rules_apple examples directory](https://github.com/bazelbuild/rules_apple/tree/master/examples/). For
 example:
 
 *   [macOS application targets](https://github.com/bazelbuild/rules_apple/tree/master/examples/macos)
@@ -191,8 +185,7 @@ example:
 
 *   [Multi platform applications (macOS, iOS, watchOS, tvOS)](https://github.com/bazelbuild/rules_apple/tree/master/examples/multi_platform)
 
-For more information on build rules, see [Apple Rules for
-Bazel](https://github.com/bazelbuild/rules_apple).
+For more information on build rules, see [Apple Rules for Bazel](https://github.com/bazelbuild/rules_apple).
 
 At this point, it is a good idea to test the build:
 
diff --git a/versions/8.3.1/query/cquery.mdx b/versions/8.3.1/query/cquery.mdx
index fa5f48cb..455657b9 100644
--- a/versions/8.3.1/query/cquery.mdx
+++ b/versions/8.3.1/query/cquery.mdx
@@ -6,8 +6,7 @@ title: ' Configurable Query (cquery)'
 [`select()`](/versions/8.3.1/docs/configurable-attributes) and build options' effects on the build
 graph.
 
-It achieves this by running over the results of Bazel's [analysis
-phase](/versions/8.3.1/extending/concepts#evaluation-model),
+It achieves this by running over the results of Bazel's [analysis phase](/versions/8.3.1/extending/concepts#evaluation-model),
 which integrates these effects. `query`, by contrast, runs over the results of
 Bazel's loading phase, before options are evaluated.
 
@@ -137,8 +136,7 @@ $ bazel cquery //foo --universe_scope=//foo,//genrule_with_foo_as_tool
 If you want to precisely declare which instance to query over, use
 the [`config`](#config) function.
 
-See `query`'s [target pattern
-documentation](/versions/8.3.1/query/language#target-patterns) for more information on target patterns.
+See `query`'s [target pattern documentation](/versions/8.3.1/query/language#target-patterns) for more information on target patterns.
 
 ## Functions {#functions}
 
diff --git a/versions/8.3.1/query/images/query_graph1.png b/versions/8.3.1/query/images/query_graph1.png
new file mode 100644
index 00000000..7bc9a61a
Binary files /dev/null and b/versions/8.3.1/query/images/query_graph1.png differ
diff --git a/versions/8.3.1/query/images/query_graph2.png b/versions/8.3.1/query/images/query_graph2.png
new file mode 100644
index 00000000..a0da22ff
Binary files /dev/null and b/versions/8.3.1/query/images/query_graph2.png differ
diff --git a/versions/8.3.1/query/images/query_graph3.png b/versions/8.3.1/query/images/query_graph3.png
new file mode 100644
index 00000000..4418f193
Binary files /dev/null and b/versions/8.3.1/query/images/query_graph3.png differ
diff --git a/versions/8.3.1/query/language.mdx b/versions/8.3.1/query/language.mdx
index 7f3bfd7d..13a811a9 100644
--- a/versions/8.3.1/query/language.mdx
+++ b/versions/8.3.1/query/language.mdx
@@ -1105,8 +1105,7 @@ is being used.
 
 ### On the ordering of results {#results-ordering}
 
-Although query expressions always follow the "[law of
-conservation of graph order](#graph-order)", _presenting_ the results may be done
+Although query expressions always follow the "[law of conservation of graph order](#graph-order)", _presenting_ the results may be done
 in either a dependency-ordered or unordered manner. This does **not**
 influence the targets in the result set or how the query is computed. It only
 affects how the results are printed to stdout. Moreover, nodes that are
@@ -1252,8 +1251,7 @@ and `maxrank` output formats print the labels of each
 target in the resulting graph, but instead of appearing in
 topological order, they appear in rank order, preceded by their
 rank number. These are unaffected by the result ordering
-`--[no]order_results` flag (see [notes on
-the ordering of results](#result-order)).
+`--[no]order_results` flag (see [notes on the ordering of results](#result-order)).
 
 There are two variants of this format: `minrank` ranks
 each node by the length of the shortest path from a root node to it.
diff --git a/versions/8.3.1/query/quickstart.mdx b/versions/8.3.1/query/quickstart.mdx
index a87f087d..0de1e6a1 100644
--- a/versions/8.3.1/query/quickstart.mdx
+++ b/versions/8.3.1/query/quickstart.mdx
@@ -205,7 +205,7 @@ dot -Tpng < graph.in > graph.png
 ```
 If you open up `graph.png`, you should see something like this. The graph below has been simplified to make the essential path details clearer in this guide.
 
-![Diagram showing a relationship from cafe to chef to the dishes: pizza and mac and cheese which diverges into the separate ingredients: cheese, tomatoes, dough, and macaroni.](images/query_graph1.png "Dependency graph")
+![Diagram showing a relationship from cafe to chef to the dishes: pizza and mac and cheese which diverges into the separate ingredients: cheese, tomatoes, dough, and macaroni.](/versions/8.3.1/query/images/query_graph1.png "Dependency graph")
 
 This helps when you want to see the outputs of the different query functions throughout this guide.
 
@@ -421,7 +421,7 @@ bazel query --noimplicit_deps 'deps(:runner)' --output graph > graph2.in
 dot -Tpng < graph2.in > graph2.png
 ```
 
-[![The same graph as the first one except now there is a spoke stemming from the chef target with smoothie which leads to banana and strawberry](images/query_graph2.png "Updated dependency graph")](images/query_graph2.png)
+[![The same graph as the first one except now there is a spoke stemming from the chef target with smoothie which leads to banana and strawberry](/versions/8.3.1/query/images/query_graph2.png "Updated dependency graph")](/query/images/query_graph2.png)
 
 Looking at `graph2.png`, you can see that `Smoothie` has no shared dependencies with other dishes but is just another target that the `Chef` relies on.
 
@@ -465,7 +465,7 @@ bazel query "allpaths(//src/main/java/com/example/restaurant/..., //src/main/jav
 //src/main/java/com/example/restaurant:chef
 ```
 
-![Output path of cafe to chef to pizza,mac and cheese to cheese](images/query_graph3.png "Output path for dependency")
+![Output path of cafe to chef to pizza,mac and cheese to cheese](/versions/8.3.1/query/images/query_graph3.png "Output path for dependency")
 
 The output of `allpaths()` is a little harder to read as it is a flattened list of the dependencies. Visualizing this graph using Graphviz makes the relationship clearer to understand.
 
diff --git a/versions/8.3.1/reference/be/c-cpp.mdx b/versions/8.3.1/reference/be/c-cpp.mdx
index 384e050c..46e4ab9b 100644
--- a/versions/8.3.1/reference/be/c-cpp.mdx
+++ b/versions/8.3.1/reference/be/c-cpp.mdx
@@ -61,7 +61,7 @@ be `main`.
 | `hdrs_check` | String; default is `""` Deprecated, no-op. |
 | `includes` | List of strings; default is `[]` List of include dirs to be added to the compile line. Subject to ["Make variable"](/versions/8.3.1/reference/be/make-variables) substitution. Each string is prepended with the package path and passed to the C++ toolchain for expansion via the "include\_paths" CROSSTOOL feature. A toolchain running on a POSIX system with typical feature definitions will produce `-isystem path_to_package/include_entry`. This should only be used for third-party libraries that do not conform to the Google style of writing #include statements. Unlike [COPTS](#cc_binary.copts), these flags are added for this rule and every rule that depends on it. (Note: not the rules it depends upon!) Be very careful, since this may have far-reaching effects. When in doubt, add "-I" flags to [COPTS](#cc_binary.copts) instead. The added `include` paths will include generated files as well as files in the source tree. |
 | `link_extra_lib` | [Label](/versions/8.3.1/concepts/labels); default is `"@bazel_tools//tools/cpp:link_extra_lib"` Control linking of extra libraries. By default, C++ binaries are linked against `//tools/cpp:link_extra_lib`, which by default depends on the label flag `//tools/cpp:link_extra_libs`. Without setting the flag, this library is empty by default. Setting the label flag allows linking optional dependencies, such as overrides for weak symbols, interceptors for shared library functions, or special runtime libraries (for malloc replacements, prefer `malloc` or `--custom_malloc`). Setting this attribute to `None` disables this behaviour. |
-| `linkopts` | List of strings; default is `[]` Add these flags to the C++ linker command. Subject to ["Make" variable](make-variables) substitution, [Bourne shell tokenization](common-definitions#sh-tokenization) and [label expansion](common-definitions#label-expansion). Each string in this attribute is added to `LINKOPTS` before linking the binary target. Each element of this list that does not start with `$` or `-` is assumed to be the label of a target in `deps`. The list of files generated by that target is appended to the linker options. An error is reported if the label is invalid, or is not declared in `deps`. |
+| `linkopts` | List of strings; default is `[]` Add these flags to the C++ linker command. Subject to ["Make" variable](/versions/8.3.1/reference/be/make-variables) substitution, [Bourne shell tokenization](/versions/8.3.1/reference/be/common-definitions#sh-tokenization) and [label expansion](/versions/8.3.1/reference/be/common-definitions#label-expansion). Each string in this attribute is added to `LINKOPTS` before linking the binary target. Each element of this list that does not start with `$` or `-` is assumed to be the label of a target in `deps`. The list of files generated by that target is appended to the linker options. An error is reported if the label is invalid, or is not declared in `deps`. |
 | `linkshared` | Boolean; default is `False` Create a shared library. To enable this attribute, include `linkshared=True` in your rule. By default this option is off. The presence of this flag means that linking occurs with the `-shared` flag to `gcc`, and the resulting shared library is suitable for loading into for example a Java program. However, for build purposes it will never be linked into the dependent binary, as it is assumed that shared libraries built with a [cc\_binary](#cc_binary) rule are only loaded manually by other programs, so it should not be considered a substitute for the [cc\_library](#cc_library) rule. For sake of scalability we recommend avoiding this approach altogether and simply letting `java_library` depend on `cc_library` rules instead.  If you specify both `linkopts=['-static']` and `linkshared=True`, you get a single completely self-contained unit. If you specify both `linkstatic=True` and `linkshared=True`, you get a single, mostly self-contained unit. |
 | `linkstatic` | Boolean; default is `True` For [`cc_binary`](/versions/8.3.1/reference/be/c-cpp#cc_binary) and [`cc_test`](/versions/8.3.1/reference/be/c-cpp#cc_test): link the binary in static mode. For `cc_library.link_static`: see below. By default this option is on for `cc_binary` and off for the rest.  If enabled and this is a binary or test, this option tells the build tool to link in `.a`'s instead of `.so`'s for user libraries whenever possible. System libraries such as libc (but *not* the C/C++ runtime libraries, see below) are still linked dynamically, as are libraries for which there is no static library. So the resulting executable will still be dynamically linked, hence only *mostly* static.  There are really three different ways to link an executable:   * STATIC with fully\_static\_link feature, in which everything is linked statically;   e.g. "`gcc -static foo.o libbar.a libbaz.a -lm`".    This mode is enabled by specifying `fully_static_link` in the   [`features`](/versions/8.3.1/reference/be/common-definitions#features) attribute. * STATIC, in which all user libraries are linked statically (if a static   version is available), but where system libraries (excluding C/C++ runtime libraries)   are linked dynamically, e.g. "`gcc foo.o libfoo.a libbaz.a -lm`".    This mode is enabled by specifying `linkstatic=True`. * DYNAMIC, in which all libraries are linked dynamically (if a dynamic version is   available), e.g. "`gcc foo.o libfoo.so libbaz.so -lm`".    This mode is enabled by specifying `linkstatic=False`.   If the `linkstatic` attribute or `fully_static_link` in `features` is used outside of `//third_party` please include a comment near the rule to explain why.  The `linkstatic` attribute has a different meaning if used on a [`cc_library()`](/versions/8.3.1/reference/be/c-cpp#cc_library) rule. For a C++ library, `linkstatic=True` indicates that only static linking is allowed, so no `.so` will be produced. linkstatic=False does not prevent static libraries from being created. The attribute is meant to control the creation of dynamic libraries.  There should be very little code built with `linkstatic=False` in production. If `linkstatic=False`, then the build tool will create symlinks to depended-upon shared libraries in the `*.runfiles` area. |
 | `local_defines` | List of strings; default is `[]` List of defines to add to the compile line. Subject to ["Make" variable](/versions/8.3.1/reference/be/make-variables) substitution and [Bourne shell tokenization](/versions/8.3.1/reference/be/common-definitions#sh-tokenization). Each string, which must consist of a single Bourne shell token, is prepended with `-D` and added to the compile command line for this target, but not to its dependents. |
@@ -229,7 +229,7 @@ cc_import(
 | `alwayslink` | Boolean; default is `False` If 1, any binary that depends (directly or indirectly) on this C++ precompiled library will link in all the object files archived in the static library, even if some contain no symbols referenced by the binary. This is useful if your code isn't explicitly called by code in the binary, e.g., if your code registers to receive some callback provided by some service. If alwayslink doesn't work with VS 2017 on Windows, that is due to a [known issue](https://github.com/bazelbuild/bazel/issues/3949), please upgrade your VS 2017 to the latest version. |
 | `includes` | List of strings; default is `[]` List of include dirs to be added to the compile line. Subject to ["Make variable"](/versions/8.3.1/reference/be/make-variables) substitution. Each string is prepended with the package path and passed to the C++ toolchain for expansion via the "include\_paths" CROSSTOOL feature. A toolchain running on a POSIX system with typical feature definitions will produce `-isystem path_to_package/include_entry`. This should only be used for third-party libraries that do not conform to the Google style of writing #include statements. Unlike [COPTS](#cc_binary.copts), these flags are added for this rule and every rule that depends on it. (Note: not the rules it depends upon!) Be very careful, since this may have far-reaching effects. When in doubt, add "-I" flags to [COPTS](#cc_binary.copts) instead. The default `include` path doesn't include generated files. If you need to `#include` a generated header file, list it in the `srcs`. |
 | `interface_library` | [Label](/versions/8.3.1/concepts/labels); default is `None` A single interface library for linking the shared library. Permitted file types: `.ifso`, `.tbd`, `.lib`, `.so` or `.dylib` |
-| `linkopts` | List of strings; default is `[]` Add these flags to the C++ linker command. Subject to ["Make" variable](make-variables) substitution, [Bourne shell tokenization](common-definitions#sh-tokenization) and [label expansion](common-definitions#label-expansion). Each string in this attribute is added to `LINKOPTS` before linking the binary target. Each element of this list that does not start with `$` or `-` is assumed to be the label of a target in `deps`. The list of files generated by that target is appended to the linker options. An error is reported if the label is invalid, or is not declared in `deps`. |
+| `linkopts` | List of strings; default is `[]` Add these flags to the C++ linker command. Subject to ["Make" variable](/versions/8.3.1/reference/be/make-variables) substitution, [Bourne shell tokenization](/versions/8.3.1/reference/be/common-definitions#sh-tokenization) and [label expansion](/versions/8.3.1/reference/be/common-definitions#label-expansion). Each string in this attribute is added to `LINKOPTS` before linking the binary target. Each element of this list that does not start with `$` or `-` is assumed to be the label of a target in `deps`. The list of files generated by that target is appended to the linker options. An error is reported if the label is invalid, or is not declared in `deps`. |
 | `objects` | List of [labels](/versions/8.3.1/concepts/labels); default is `[]` |
 | `pic_objects` | List of [labels](/versions/8.3.1/concepts/labels); default is `[]` |
 | `pic_static_library` | [Label](/versions/8.3.1/concepts/labels); default is `None` |
@@ -453,7 +453,7 @@ cc_library(
 | `implementation_deps` | List of [labels](/versions/8.3.1/concepts/labels); default is `[]` The list of other libraries that the library target depends on. Unlike with `deps`, the headers and include paths of these libraries (and all their transitive deps) are only used for compilation of this library, and not libraries that depend on it. Libraries specified with `implementation_deps` are still linked in binary targets that depend on this library. |
 | `include_prefix` | String; default is `""` The prefix to add to the paths of the headers of this rule. When set, the headers in the `hdrs` attribute of this rule are accessible at is the value of this attribute prepended to their repository-relative path. The prefix in the `strip_include_prefix` attribute is removed before this prefix is added. This attribute is only legal under `third_party`. |
 | `includes` | List of strings; default is `[]` List of include dirs to be added to the compile line. Subject to ["Make variable"](/versions/8.3.1/reference/be/make-variables) substitution. Each string is prepended with the package path and passed to the C++ toolchain for expansion via the "include\_paths" CROSSTOOL feature. A toolchain running on a POSIX system with typical feature definitions will produce `-isystem path_to_package/include_entry`. This should only be used for third-party libraries that do not conform to the Google style of writing #include statements. Unlike [COPTS](#cc_binary.copts), these flags are added for this rule and every rule that depends on it. (Note: not the rules it depends upon!) Be very careful, since this may have far-reaching effects. When in doubt, add "-I" flags to [COPTS](#cc_binary.copts) instead. The added `include` paths will include generated files as well as files in the source tree. |
-| `linkopts` | List of strings; default is `[]` See [`cc_binary.linkopts`](/versions/8.3.1/reference/be/c-cpp#cc_binary.linkopts). The `linkopts` attribute is also applied to any target that depends, directly or indirectly, on this library via `deps` attributes (or via other attributes that are treated similarly: the [`malloc`](/versions/8.3.1/reference/be/c-cpp#cc_binary.malloc) attribute of [`cc_binary`](/versions/8.3.1/reference/be/c-cpp#cc_binary)). Dependency linkopts take precedence over dependent linkopts (i.e. dependency linkopts appear later in the command line). Linkopts specified in [`--linkopt`](../user-manual#flag--linkopt) take precedence over rule linkopts. |
+| `linkopts` | List of strings; default is `[]` See [`cc_binary.linkopts`](/versions/8.3.1/reference/be/c-cpp#cc_binary.linkopts). The `linkopts` attribute is also applied to any target that depends, directly or indirectly, on this library via `deps` attributes (or via other attributes that are treated similarly: the [`malloc`](/versions/8.3.1/reference/be/c-cpp#cc_binary.malloc) attribute of [`cc_binary`](/versions/8.3.1/reference/be/c-cpp#cc_binary)). Dependency linkopts take precedence over dependent linkopts (i.e. dependency linkopts appear later in the command line). Linkopts specified in [`--linkopt`](/versions/8.3.1/reference/user-manual#flag--linkopt) take precedence over rule linkopts. |
 
 Note that the `linkopts` attribute only applies
 when creating `.so` files or executables, not
@@ -736,7 +736,7 @@ that `cc_test` has extra [attributes common to all test rules (\*\_test)](/versi
 | `hdrs_check` | String; default is `""` Deprecated, no-op. |
 | `includes` | List of strings; default is `[]` List of include dirs to be added to the compile line. Subject to ["Make variable"](/versions/8.3.1/reference/be/make-variables) substitution. Each string is prepended with the package path and passed to the C++ toolchain for expansion via the "include\_paths" CROSSTOOL feature. A toolchain running on a POSIX system with typical feature definitions will produce `-isystem path_to_package/include_entry`. This should only be used for third-party libraries that do not conform to the Google style of writing #include statements. Unlike [COPTS](#cc_binary.copts), these flags are added for this rule and every rule that depends on it. (Note: not the rules it depends upon!) Be very careful, since this may have far-reaching effects. When in doubt, add "-I" flags to [COPTS](#cc_binary.copts) instead. The added `include` paths will include generated files as well as files in the source tree. |
 | `link_extra_lib` | [Label](/versions/8.3.1/concepts/labels); default is `"@bazel_tools//tools/cpp:link_extra_lib"` Control linking of extra libraries. By default, C++ binaries are linked against `//tools/cpp:link_extra_lib`, which by default depends on the label flag `//tools/cpp:link_extra_libs`. Without setting the flag, this library is empty by default. Setting the label flag allows linking optional dependencies, such as overrides for weak symbols, interceptors for shared library functions, or special runtime libraries (for malloc replacements, prefer `malloc` or `--custom_malloc`). Setting this attribute to `None` disables this behaviour. |
-| `linkopts` | List of strings; default is `[]` Add these flags to the C++ linker command. Subject to ["Make" variable](make-variables) substitution, [Bourne shell tokenization](common-definitions#sh-tokenization) and [label expansion](common-definitions#label-expansion). Each string in this attribute is added to `LINKOPTS` before linking the binary target. Each element of this list that does not start with `$` or `-` is assumed to be the label of a target in `deps`. The list of files generated by that target is appended to the linker options. An error is reported if the label is invalid, or is not declared in `deps`. |
+| `linkopts` | List of strings; default is `[]` Add these flags to the C++ linker command. Subject to ["Make" variable](/versions/8.3.1/reference/be/make-variables) substitution, [Bourne shell tokenization](/versions/8.3.1/reference/be/common-definitions#sh-tokenization) and [label expansion](/versions/8.3.1/reference/be/common-definitions#label-expansion). Each string in this attribute is added to `LINKOPTS` before linking the binary target. Each element of this list that does not start with `$` or `-` is assumed to be the label of a target in `deps`. The list of files generated by that target is appended to the linker options. An error is reported if the label is invalid, or is not declared in `deps`. |
 | `linkshared` | Boolean; default is `False` Create a shared library. To enable this attribute, include `linkshared=True` in your rule. By default this option is off. The presence of this flag means that linking occurs with the `-shared` flag to `gcc`, and the resulting shared library is suitable for loading into for example a Java program. However, for build purposes it will never be linked into the dependent binary, as it is assumed that shared libraries built with a [cc\_binary](#cc_binary) rule are only loaded manually by other programs, so it should not be considered a substitute for the [cc\_library](#cc_library) rule. For sake of scalability we recommend avoiding this approach altogether and simply letting `java_library` depend on `cc_library` rules instead.  If you specify both `linkopts=['-static']` and `linkshared=True`, you get a single completely self-contained unit. If you specify both `linkstatic=True` and `linkshared=True`, you get a single, mostly self-contained unit. |
 | `linkstatic` | Boolean; default is `False` For [`cc_binary`](/versions/8.3.1/reference/be/c-cpp#cc_binary) and [`cc_test`](/versions/8.3.1/reference/be/c-cpp#cc_test): link the binary in static mode. For `cc_library.link_static`: see below. By default this option is on for `cc_binary` and off for the rest.  If enabled and this is a binary or test, this option tells the build tool to link in `.a`'s instead of `.so`'s for user libraries whenever possible. System libraries such as libc (but *not* the C/C++ runtime libraries, see below) are still linked dynamically, as are libraries for which there is no static library. So the resulting executable will still be dynamically linked, hence only *mostly* static.  There are really three different ways to link an executable:   * STATIC with fully\_static\_link feature, in which everything is linked statically;   e.g. "`gcc -static foo.o libbar.a libbaz.a -lm`".    This mode is enabled by specifying `fully_static_link` in the   [`features`](/versions/8.3.1/reference/be/common-definitions#features) attribute. * STATIC, in which all user libraries are linked statically (if a static   version is available), but where system libraries (excluding C/C++ runtime libraries)   are linked dynamically, e.g. "`gcc foo.o libfoo.a libbaz.a -lm`".    This mode is enabled by specifying `linkstatic=True`. * DYNAMIC, in which all libraries are linked dynamically (if a dynamic version is   available), e.g. "`gcc foo.o libfoo.so libbaz.so -lm`".    This mode is enabled by specifying `linkstatic=False`.   If the `linkstatic` attribute or `fully_static_link` in `features` is used outside of `//third_party` please include a comment near the rule to explain why.  The `linkstatic` attribute has a different meaning if used on a [`cc_library()`](/versions/8.3.1/reference/be/c-cpp#cc_library) rule. For a C++ library, `linkstatic=True` indicates that only static linking is allowed, so no `.so` will be produced. linkstatic=False does not prevent static libraries from being created. The attribute is meant to control the creation of dynamic libraries.  There should be very little code built with `linkstatic=False` in production. If `linkstatic=False`, then the build tool will create symlinks to depended-upon shared libraries in the `*.runfiles` area. |
 | `local_defines` | List of strings; default is `[]` List of defines to add to the compile line. Subject to ["Make" variable](/versions/8.3.1/reference/be/make-variables) substitution and [Bourne shell tokenization](/versions/8.3.1/reference/be/common-definitions#sh-tokenization). Each string, which must consist of a single Bourne shell token, is prepended with `-D` and added to the compile command line for this target, but not to its dependents. |
diff --git a/versions/8.3.1/reference/be/common-definitions.mdx b/versions/8.3.1/reference/be/common-definitions.mdx
index 5b6cb94f..97771480 100644
--- a/versions/8.3.1/reference/be/common-definitions.mdx
+++ b/versions/8.3.1/reference/be/common-definitions.mdx
@@ -75,11 +75,11 @@ rules.
 | `deprecation` | String; [nonconfigurable](#configurable-attributes); default is `None`  An explanatory warning message associated with this target. Typically this is used to notify users that a target has become obsolete, or has become superseded by another rule, is private to a package, or is perhaps considered harmful for some reason. It is a good idea to include some reference (like a webpage, a bug number or example migration CLs) so that one can easily find out what changes are required to avoid the message. If there is a new target that can be used as a drop in replacement, it is a good idea to just migrate all users of the old target.  This attribute has no effect on the way things are built, but it may affect a build tool's diagnostic output. The build tool issues a warning when a rule with a `deprecation` attribute is depended upon by a target in another package.  Intra-package dependencies are exempt from this warning, so that, for example, building the tests of a deprecated rule does not encounter a warning.  If a deprecated target depends on another deprecated target, no warning message is issued.  Once people have stopped using it, the target can be removed. |
 | `distribs` | List of strings; [nonconfigurable](#configurable-attributes); default is `[]`  A list of distribution-method strings to be used for this particular target. This is part of a deprecated licensing API that Bazel no longer uses. Don't use this. |
 | `exec_compatible_with` | List of [labels](/versions/8.3.1/concepts/labels); [nonconfigurable](#configurable-attributes); default is `[]`  A list of `constraint_values` that must be present in the execution platform for this target. This is in addition to any constraints already set by the rule type. Constraints are used to restrict the list of available execution platforms. For more details, see the description of [toolchain resolution](/versions/8.3.1/docs/toolchains#toolchain-resolution). |
-| `exec_properties` | Dictionary of strings; default is `{}`  A dictionary of strings that will be added to the `exec_properties` of a platform selected for this target. See `exec_properties` of the [platform](platforms-and-toolchains#platform) rule.  If a key is present in both the platform and target-level properties, the value will be taken from the target. |
+| `exec_properties` | Dictionary of strings; default is `{}`  A dictionary of strings that will be added to the `exec_properties` of a platform selected for this target. See `exec_properties` of the [platform](/versions/8.3.1/reference/be/platforms-and-toolchains#platform) rule.  If a key is present in both the platform and target-level properties, the value will be taken from the target. |
 | `features` | List of *feature* strings; default is `[]`  A feature is string tag that can be enabled or disabled on a target. The meaning of a feature depends on the rule itself.  This `features` attribute is combined with the [package](/versions/8.3.1/reference/be/functions#package) level `features` attribute. For example, if the features ["a", "b"] are enabled on the package level, and a target's `features` attribute contains ["-a", "c"], the features enabled for the rule will be "b" and "c". [See example](https://github.com/bazelbuild/examples/blob/main/rules/features/BUILD). |
 | `restricted_to` | List of [labels](/versions/8.3.1/concepts/labels); [nonconfigurable](#configurable-attributes); default is `[]`  The list of environments this target can be built for, *instead* of default-supported environments.  This is part of Bazel's constraint system. See `compatible_with` for details. |
 | `tags` | List of strings; [nonconfigurable](#configurable-attributes); default is `[]`  *Tags* can be used on any rule. *Tags* on test and `test_suite` rules are useful for categorizing the tests. *Tags* on non-test targets are used to control sandboxed execution of `genrule`s and [Starlark](/versions/8.3.1/rules/concepts) actions, and for parsing by humans and/or external tools.  Bazel modifies the behavior of its sandboxing code if it finds the following keywords in the `tags` attribute of any test or `genrule` target, or the keys of `execution_requirements` for any Starlark action.   * `no-sandbox` keyword results in the action or test never being   sandboxed; it can still be cached or run remotely - use `no-cache`   or `no-remote` to prevent either or both of those. * `no-cache` keyword results in the action or test never being   cached (locally or remotely). Note: for the purposes of this tag, the disk cache   is considered a local cache, whereas the HTTP and gRPC caches are considered   remote. Other caches, such as Skyframe or the persistent action cache, are not   affected. * `no-remote-cache` keyword results in the action or test never being   cached remotely (but it may be cached locally; it may also be executed remotely).   Note: for the purposes of this tag, the disk cache is considered a local cache,   whereas the HTTP and gRPC caches are considered remote. Other caches, such as   Skyframe or the persistent action cache, are not affected.   If a combination of local disk cache and remote cache are used (combined cache),   it's treated as a remote cache and disabled entirely unless `--incompatible_remote_results_ignore_disk`   is set in which case the local components will be used. * `no-remote-exec` keyword results in the action or test never being   executed remotely (but it may be cached remotely). * `no-remote` keyword prevents the action or test from being executed remotely or   cached remotely. This is equivalent to using both   `no-remote-cache` and `no-remote-exec`. * `no-remote-cache-upload` keyword disables upload part of remote caching of a spawn.   it does not disable remote execution. * `local` keyword precludes the action or test from being remotely cached,   remotely executed, or run inside the sandbox.   For genrules and tests, marking the rule with the `local = True`   attribute has the same effect. * `requires-network` keyword allows access to the external   network from inside the sandbox. This tag only has an effect if sandboxing   is enabled. * `block-network` keyword blocks access to the external   network from inside the sandbox. In this case, only communication   with localhost is allowed. This tag only has an effect if sandboxing is   enabled. * `requires-fakeroot` runs the test or action as uid and gid 0 (i.e., the root   user). This is only supported on Linux. This tag takes precedence over the   `--sandbox_fake_username` command-line option.   *Tags* on tests are generally used to annotate a test's role in your debug and release process. Typically, tags are most useful for C++ and Python tests, which lack any runtime annotation ability. The use of tags and size elements gives flexibility in assembling suites of tests based around codebase check-in policy.  Bazel modifies test running behavior if it finds the following keywords in the `tags` attribute of the test rule:   * `exclusive` will force the test to be run in the   "exclusive" mode, ensuring that no other tests are running at the   same time. Such tests will be executed in serial fashion after all build   activity and non-exclusive tests have been completed. Remote execution is   disabled for such tests because Bazel doesn't have control over what's   running on a remote machine. * `exclusive-if-local` will force the test to be run in the   "exclusive" mode if it is executed locally, but will run the test in parallel if it's   executed remotely. * `manual` keyword will exclude the target from expansion of target pattern wildcards   (`...`, `:*`, `:all`, etc.) and `test_suite` rules   which do not list the test explicitly when computing the set of top-level targets to build/run   for the `build`, `test`, and `coverage` commands. It does not   affect target wildcard or test suite expansion in other contexts, including the   `query` command. Note that `manual` does not imply that a target should   not be built/run automatically by continuous build/test systems. For example, it may be   desirable to exclude a target from `bazel test ...` because it requires specific   Bazel flags, but still have it included in properly-configured presubmit or continuous test   runs. * `external` keyword will force test to be unconditionally   executed (regardless of `--cache_test_results`   value).  See [Tag Conventions](/versions/8.3.1/reference/test-encyclopedia#tag-conventions) in the Test Encyclopedia for more conventions on tags attached to test targets. |
-| `target_compatible_with` | List of [labels](/versions/8.3.1/concepts/labels); default is `[]`  A list of `constraint_value`s that must be present in the target platform for this target to be considered *compatible*. This is in addition to any constraints already set by the rule type. If the target platform does not satisfy all listed constraints then the target is considered *incompatible*. Incompatible targets are skipped for building and testing when the target pattern is expanded (e.g. `//...`, `:all`). When explicitly specified on the command line, incompatible targets cause Bazel to print an error and cause a build or test failure.  Targets that transitively depend on incompatible targets are themselves considered incompatible. They are also skipped for building and testing.  An empty list (which is the default) signifies that the target is compatible with all platforms. All rules other than [Workspace Rules](workspace) support this attribute. For some rules this attribute has no effect. For example, specifying `target_compatible_with` for a `cc_toolchain` is not useful. See the [Platforms](/versions/8.3.1/docs/platforms#skipping-incompatible-targets) page for more information about incompatible target skipping. |
+| `target_compatible_with` | List of [labels](/versions/8.3.1/concepts/labels); default is `[]`  A list of `constraint_value`s that must be present in the target platform for this target to be considered *compatible*. This is in addition to any constraints already set by the rule type. If the target platform does not satisfy all listed constraints then the target is considered *incompatible*. Incompatible targets are skipped for building and testing when the target pattern is expanded (e.g. `//...`, `:all`). When explicitly specified on the command line, incompatible targets cause Bazel to print an error and cause a build or test failure.  Targets that transitively depend on incompatible targets are themselves considered incompatible. They are also skipped for building and testing.  An empty list (which is the default) signifies that the target is compatible with all platforms. All rules other than [Workspace Rules](/versions/8.3.1/reference/be/workspace) support this attribute. For some rules this attribute has no effect. For example, specifying `target_compatible_with` for a `cc_toolchain` is not useful. See the [Platforms](/versions/8.3.1/docs/platforms#skipping-incompatible-targets) page for more information about incompatible target skipping. |
 | `testonly` | Boolean; [nonconfigurable](#configurable-attributes); default is `False` except for test and test suite targets  If `True`, only testonly targets (such as tests) can depend on this target.  Equivalently, a rule that is not `testonly` is not allowed to depend on any rule that is `testonly`.  Tests (`*_test` rules) and test suites ([test\_suite](/versions/8.3.1/reference/be/general#test_suite) rules) are `testonly` by default.  This attribute is intended to mean that the target should not be contained in binaries that are released to production.  Because testonly is enforced at build time, not run time, and propagates virally through the dependency tree, it should be applied judiciously. For example, stubs and fakes that are useful for unit tests may also be useful for integration tests involving the same binaries that will be released to production, and therefore should probably not be marked testonly. Conversely, rules that are dangerous to even link in, perhaps because they unconditionally override normal behavior, should definitely be marked testonly. |
 | `toolchains` | List of [labels](/versions/8.3.1/concepts/labels); [nonconfigurable](#configurable-attributes); default is `[]`  The set of targets whose [Make variables](/versions/8.3.1/reference/be/make-variables) this target is allowed to access. These targets are either instances of rules that provide `TemplateVariableInfo` or special targets for toolchain types built into Bazel. These include:  * `@bazel_tools//tools/cpp:current_cc_toolchain`* `@rules_java//toolchains:current_java_runtime`   Note that this is distinct from the concept of [toolchain resolution](/versions/8.3.1/docs/toolchains#toolchain-resolution) that is used by rule implementations for platform-dependent configuration. You cannot use this attribute to determine which specific `cc_toolchain` or `java_toolchain` a target will use. |
 | `visibility` | List of [labels](/versions/8.3.1/concepts/labels); [nonconfigurable](#configurable-attributes); default varies  The `visibility` attribute controls whether the target can be depended on by targets in other locations. See the documentation for [visibility](/versions/8.3.1/concepts/visibility).  For targets declared directly in a BUILD file or in legacy macros called from a BUILD file, the default value is the package's `default_visibility` if specified, or else `["//visibility:private"]`. For targets declared in one or more symbolic macros, the default value is always just `["//visibility:private"]` (which makes it useable only within the package containing the macro's code). |
diff --git a/versions/8.3.1/reference/be/functions.mdx b/versions/8.3.1/reference/be/functions.mdx
index f2f18d50..3a88fa3b 100644
--- a/versions/8.3.1/reference/be/functions.mdx
+++ b/versions/8.3.1/reference/be/functions.mdx
@@ -34,9 +34,9 @@ file, before any rule.
 | --- | --- |
 | `default_applicable_licenses` | Alias for [`default_package_metadata`](#package.default_package_metadata). |
 | `default_visibility` | List of [labels](/versions/8.3.1/concepts/labels); default is `[]`  The default visibility of the top-level rule targets and symbolic macros in this package — that is, the targets and symbolic macros that are not themselves declared inside a symbolic macro. This attribute is ignored if the target or macro specifies a `visibility` value.  For detailed information about the syntax of this attribute, see the documentation of [visibility](/versions/8.3.1/concepts/visibility). The package default visibility does not apply to [exports\_files](#exports_files), which is public by default. |
-| `default_deprecation` | String; default is `""`  Sets the default [`deprecation`](common-definitions#common.deprecation) message for all rules in this package. |
+| `default_deprecation` | String; default is `""`  Sets the default [`deprecation`](/versions/8.3.1/reference/be/common-definitions#common.deprecation) message for all rules in this package. |
 | `default_package_metadata` | List of [labels](/versions/8.3.1/concepts/labels); default is `[]`  Sets a default list of metadata targets which apply to all other targets in the package. These are typically targets related to OSS package and license declarations. See [rules\_license](https://github.com/bazelbuild/rules_license) for examples. |
-| `default_testonly` | Boolean; default is `False` except as noted  Sets the default [`testonly`](common-definitions#common.testonly) property for all rules in this package.  In packages under `javatests` the default value is `True`. |
+| `default_testonly` | Boolean; default is `False` except as noted  Sets the default [`testonly`](/versions/8.3.1/reference/be/common-definitions#common.testonly) property for all rules in this package.  In packages under `javatests` the default value is `True`. |
 | `features` | List strings; default is `[]`  Sets various flags that affect the semantics of this BUILD file.  This feature is mainly used by the people working on the build system to tag packages that need some kind of special handling. Do not use this unless explicitly requested by someone working on the build system. |
 
 ### Examples
@@ -66,7 +66,7 @@ visible target can only be referenced within its own package (not subpackages).
 In between these extremes, a target may allow access to its own package plus any
 of the packages described by one or more package groups. For a more detailed
 explanation of the visibility system, see the
-[visibility](common-definitions#common.visibility)
+[visibility](/versions/8.3.1/reference/be/common-definitions#common.visibility)
 attribute.
 
 A given package is considered to be in the group if it either matches the
@@ -159,7 +159,7 @@ visibility declaration can also be specified; in this case, the files will be
 visible to the targets specified. If no visibility is specified, the files
 will be visible to every package, even if a package default visibility was
 specified in the `package`
-function. The [licenses](common-definitions#common.licenses)
+function. The [licenses](/versions/8.3.1/reference/be/common-definitions#common.licenses)
 can also be specified.
 
 ### Example
@@ -262,8 +262,7 @@ There are several important limitations and caveats:
    package called "Foo.java" (which is allowed, though Bazel warns about it),
    then the consumer of the `glob()` will use the "Foo.java" rule
    (its outputs) instead of the "Foo.java" file. See
-   [GitHub
-   issue #10395](https://github.com/bazelbuild/bazel/issues/10395#issuecomment-583714657) for more details.
+   [GitHub issue #10395](https://github.com/bazelbuild/bazel/issues/10395#issuecomment-583714657) for more details.
 3. Globs may match files in subdirectories. And subdirectory names
    may be wildcarded. However...
 4. Labels are not allowed to cross the package boundary and glob does
@@ -409,7 +408,7 @@ select(
 ```
 
 `select()` is the helper function that makes a rule attribute
-[configurable](common-definitions#configurable-attributes).
+[configurable](/versions/8.3.1/reference/be/common-definitions#configurable-attributes).
 It can replace the right-hand side of
 *almost*
 any attribute assignment so its value depends on command-line Bazel flags.
diff --git a/versions/8.3.1/reference/be/general.mdx b/versions/8.3.1/reference/be/general.mdx
index d2c64297..713bee30 100644
--- a/versions/8.3.1/reference/be/general.mdx
+++ b/versions/8.3.1/reference/be/general.mdx
@@ -158,9 +158,9 @@ some build targets.
   [here](/versions/8.3.1/reference/be/common-definitions#configurable-attributes) for more discussion.
 * Avoid repeating identical `config_setting` definitions in different packages.
   Instead, reference a common `config_setting` that defined in a canonical package.
-* [`values`](general#config_setting.values),
-  [`define_values`](general#config_setting.define_values), and
-  [`constraint_values`](general#config_setting.constraint_values)
+* [`values`](/versions/8.3.1/reference/be/general#config_setting.values),
+  [`define_values`](/versions/8.3.1/reference/be/general#config_setting.define_values), and
+  [`constraint_values`](/versions/8.3.1/reference/be/general#config_setting.constraint_values)
   can be used in any combination in the same `config_setting` but at least one must
   be set for any given `config_setting`.
 
@@ -169,10 +169,10 @@ some build targets.
 | Attributes | |
 | --- | --- |
 | `name` | [Name](/versions/8.3.1/concepts/labels#target-names); required  A unique name for this target. |
-| `constraint_values` | List of [labels](/versions/8.3.1/concepts/labels); [nonconfigurable](common-definitions#configurable-attributes); default is `[]` The minimum set of `constraint_values` that the target platform must specify in order to match this `config_setting`. (The execution platform is not considered here.) Any additional constraint values that the platform has are ignored. See [Configurable Build Attributes](https://bazel.build/versions/8.3.1/docs/configurable-attributes#platforms) for details. If two `config_setting`s match in the same `select` and one has all the same flags and `constraint_setting`s as the other plus additional ones, the one with more settings is chosen. This is known as "specialization". For example, a `config_setting` matching `x86` and `Linux` specializes a `config_setting` matching `x86`. If two `config_setting`s match and both have `constraint_value`s not present in the other, this is an error. |
-| `define_values` | Dictionary: String -> String; [nonconfigurable](common-definitions#configurable-attributes); default is `{}` The same as [`values`](/versions/8.3.1/reference/be/general#config_setting.values) but specifically for the `--define` flag. `--define` is special because its syntax (`--define KEY=VAL`) means `KEY=VAL` is a *value* from a Bazel flag perspective.  That means:  ```             config_setting(                 name = "a_and_b",                 values = {                     "define": "a=1",                     "define": "b=2",                 }) ```   doesn't work because the same key (`define`) appears twice in the dictionary. This attribute solves that problem:  ```             config_setting(                 name = "a_and_b",                 define_values = {                     "a": "1",                     "b": "2",                 }) ```   correctly matches `bazel build //foo --define a=1 --define b=2`. `--define` can still appear in [`values`](/versions/8.3.1/reference/be/general#config_setting.values) with normal flag syntax, and can be mixed freely with this attribute as long as dictionary keys remain distinct. |
-| `flag_values` | Dictionary: [label](/versions/8.3.1/concepts/labels) -> String; [nonconfigurable](common-definitions#configurable-attributes); default is `{}` The same as [`values`](/versions/8.3.1/reference/be/general#config_setting.values) but for [user-defined build flags](https://bazel.build/versions/8.3.1/rules/config#user-defined-build-settings). This is a distinct attribute because user-defined flags are referenced as labels while built-in flags are referenced as arbitrary strings. |
-| `values` | Dictionary: String -> String; [nonconfigurable](common-definitions#configurable-attributes); default is `{}` The set of configuration values that match this rule (expressed as build flags) This rule inherits the configuration of the configured target that references it in a `select` statement. It is considered to "match" a Bazel invocation if, for every entry in the dictionary, its configuration matches the entry's expected value. For example `values = {"compilation_mode": "opt"}` matches the invocations `bazel build --compilation_mode=opt ...` and `bazel build -c opt ...` on target-configured rules.  For convenience's sake, configuration values are specified as build flags (without the preceding `"--"`). But keep in mind that the two are not the same. This is because targets can be built in multiple configurations within the same build. For example, an exec configuration's "cpu" matches the value of `--host_cpu`, not `--cpu`. So different instances of the same `config_setting` may match the same invocation differently depending on the configuration of the rule using them.  If a flag is not explicitly set at the command line, its default value is used. If a key appears multiple times in the dictionary, only the last instance is used. If a key references a flag that can be set multiple times on the command line (e.g. `bazel build --copt=foo --copt=bar --copt=baz ...`), a match occurs if *any* of those settings match. |
+| `constraint_values` | List of [labels](/versions/8.3.1/concepts/labels); [nonconfigurable](/versions/8.3.1/reference/be/common-definitions#configurable-attributes); default is `[]` The minimum set of `constraint_values` that the target platform must specify in order to match this `config_setting`. (The execution platform is not considered here.) Any additional constraint values that the platform has are ignored. See [Configurable Build Attributes](https://bazel.build/versions/8.3.1/docs/configurable-attributes#platforms) for details. If two `config_setting`s match in the same `select` and one has all the same flags and `constraint_setting`s as the other plus additional ones, the one with more settings is chosen. This is known as "specialization". For example, a `config_setting` matching `x86` and `Linux` specializes a `config_setting` matching `x86`. If two `config_setting`s match and both have `constraint_value`s not present in the other, this is an error. |
+| `define_values` | Dictionary: String -> String; [nonconfigurable](/versions/8.3.1/reference/be/common-definitions#configurable-attributes); default is `{}` The same as [`values`](/versions/8.3.1/reference/be/general#config_setting.values) but specifically for the `--define` flag. `--define` is special because its syntax (`--define KEY=VAL`) means `KEY=VAL` is a *value* from a Bazel flag perspective.  That means:  ```             config_setting(                 name = "a_and_b",                 values = {                     "define": "a=1",                     "define": "b=2",                 }) ```   doesn't work because the same key (`define`) appears twice in the dictionary. This attribute solves that problem:  ```             config_setting(                 name = "a_and_b",                 define_values = {                     "a": "1",                     "b": "2",                 }) ```   correctly matches `bazel build //foo --define a=1 --define b=2`. `--define` can still appear in [`values`](/versions/8.3.1/reference/be/general#config_setting.values) with normal flag syntax, and can be mixed freely with this attribute as long as dictionary keys remain distinct. |
+| `flag_values` | Dictionary: [label](/versions/8.3.1/concepts/labels) -> String; [nonconfigurable](/versions/8.3.1/reference/be/common-definitions#configurable-attributes); default is `{}` The same as [`values`](/versions/8.3.1/reference/be/general#config_setting.values) but for [user-defined build flags](https://bazel.build/versions/8.3.1/rules/config#user-defined-build-settings). This is a distinct attribute because user-defined flags are referenced as labels while built-in flags are referenced as arbitrary strings. |
+| `values` | Dictionary: String -> String; [nonconfigurable](/versions/8.3.1/reference/be/common-definitions#configurable-attributes); default is `{}` The set of configuration values that match this rule (expressed as build flags) This rule inherits the configuration of the configured target that references it in a `select` statement. It is considered to "match" a Bazel invocation if, for every entry in the dictionary, its configuration matches the entry's expected value. For example `values = {"compilation_mode": "opt"}` matches the invocations `bazel build --compilation_mode=opt ...` and `bazel build -c opt ...` on target-configured rules.  For convenience's sake, configuration values are specified as build flags (without the preceding `"--"`). But keep in mind that the two are not the same. This is because targets can be built in multiple configurations within the same build. For example, an exec configuration's "cpu" matches the value of `--host_cpu`, not `--cpu`. So different instances of the same `config_setting` may match the same invocation differently depending on the configuration of the rule using them.  If a flag is not explicitly set at the command line, its default value is used. If a key appears multiple times in the dictionary, only the last instance is used. If a key references a flag that can be set multiple times on the command line (e.g. `bazel build --copt=foo --copt=bar --copt=baz ...`), a match occurs if *any* of those settings match. |
 
 ## filegroup
 
@@ -466,7 +466,7 @@ genrule(
 | --- | --- |
 | `name` | [Name](/versions/8.3.1/concepts/labels#target-names); required  A unique name for this target.  You may refer to this rule by name in the `srcs` or `deps` section of other `BUILD` rules. If the rule generates source files, you should use the `srcs` attribute. |
 | `srcs` | List of [labels](/versions/8.3.1/concepts/labels); default is `[]` A list of inputs for this rule, such as source files to process. *This attributes is not suitable to list tools executed by the `cmd`; use the [`tools`](/versions/8.3.1/reference/be/general#genrule.tools) attribute for them instead.*  The build system ensures these prerequisites are built before running the genrule command; they are built using the same configuration as the original build request. The names of the files of these prerequisites are available to the command as a space-separated list in `$(SRCS)`; alternatively the path of an individual `srcs` target `//x:y` can be obtained using `$(location //x:y)`, or using `$<` provided it's the only entry in `srcs`. |
-| `outs` | List of [filenames](/versions/8.3.1/concepts/build-ref#filename); [nonconfigurable](common-definitions#configurable-attributes); required A list of files generated by this rule. Output files must not cross package boundaries. Output filenames are interpreted as relative to the package.  If the `executable` flag is set, `outs` must contain exactly one label.  The genrule command is expected to create each output file at a predetermined location. The location is available in `cmd` using [genrule-specific "Make" variables](/versions/8.3.1/reference/be/make-variables#predefined_genrule_variables) (`$@`, `$(OUTS)`, `$(@D)` or `$(RULEDIR)`) or using [`$(location)`](/versions/8.3.1/reference/be/make-variables#predefined_label_variables) substitution. |
+| `outs` | List of [filenames](/versions/8.3.1/concepts/build-ref#filename); [nonconfigurable](/versions/8.3.1/reference/be/common-definitions#configurable-attributes); required A list of files generated by this rule. Output files must not cross package boundaries. Output filenames are interpreted as relative to the package.  If the `executable` flag is set, `outs` must contain exactly one label.  The genrule command is expected to create each output file at a predetermined location. The location is available in `cmd` using [genrule-specific "Make" variables](/versions/8.3.1/reference/be/make-variables#predefined_genrule_variables) (`$@`, `$(OUTS)`, `$(@D)` or `$(RULEDIR)`) or using [`$(location)`](/versions/8.3.1/reference/be/make-variables#predefined_label_variables) substitution. |
 | `cmd` | String; default is `""` The command to run. Subject to [`$(location)`](/versions/8.3.1/reference/be/make-variables#predefined_label_variables) and ["Make" variable](/versions/8.3.1/reference/be/make-variables) substitution.  1. First [`$(location)`](/versions/8.3.1/reference/be/make-variables#predefined_label_variables) substitution is applied, replacing all occurrences of `$(location     label)` and of `$(locations label)` (and similar    constructions using related variables `execpath`, `execpaths`,    `rootpath` and `rootpaths`). 2. Next, ["Make" variables](/versions/8.3.1/reference/be/make-variables) are expanded. Note that    predefined variables `$(JAVA)`, `$(JAVAC)` and    `$(JAVABASE)` expand under the *exec* configuration, so Java invocations    that run as part of a build step can correctly load shared libraries and other    dependencies. 3. Finally, the resulting command is executed using the Bash shell. If its exit code is    non-zero the command is considered to have failed.  This is the fallback of `cmd_bash`, `cmd_ps` and `cmd_bat`, if none of them are applicable. |
 
 If the command line length exceeds the platform limit (64K on Linux/macOS, 8K on Windows),
@@ -477,12 +477,12 @@ applies to all cmd attributes (`cmd`, `cmd_bash`, `cmd_ps`,
 | `cmd_bash` | String; default is `""` The Bash command to run. This attribute has higher priority than `cmd`. The command is expanded and runs in the exact same way as the `cmd` attribute. |
 | `cmd_bat` | String; default is `""` The Batch command to run on Windows. This attribute has higher priority than `cmd` and `cmd_bash`. The command runs in the similar way as the `cmd` attribute, with the following differences:   * This attribute only applies on Windows. * The command runs with `cmd.exe /c` with the following default arguments:   + `/S` - strip first and last quotes and execute everything else as is.   + `/E:ON` - enable extended command set.   + `/V:ON` - enable delayed variable expansion   + `/D` - ignore AutoRun registry entries. * After [$(location)](/versions/8.3.1/reference/be/make-variables#predefined_label_variables) and   ["Make" variable](/versions/8.3.1/reference/be/make-variables) substitution, the paths will be   expanded to Windows style paths (with backslash). |
 | `cmd_ps` | String; default is `""` The Powershell command to run on Windows. This attribute has higher priority than `cmd`, `cmd_bash` and `cmd_bat`. The command runs in the similar way as the `cmd` attribute, with the following differences:   * This attribute only applies on Windows. * The command runs with `powershell.exe /c`.   To make Powershell easier to use and less error-prone, we run the following commands to set up the environment before executing Powershell command in genrule.   * `Set-ExecutionPolicy -Scope CurrentUser RemoteSigned` - allow running   unsigned scripts. * `$errorActionPreference='Stop'` - In case there are multiple commands   separated by `;`, the action exits immediately if a Powershell CmdLet fails,   but this does **NOT** work for external command. * `$PSDefaultParameterValues['*:Encoding'] = 'utf8'` - change the default   encoding from utf-16 to utf-8. |
-| `executable` | Boolean; [nonconfigurable](common-definitions#configurable-attributes); default is `False` Declare output to be executable. Setting this flag to True means the output is an executable file and can be run using the `run` command. The genrule must produce exactly one output in this case. If this attribute is set, `run` will try executing the file regardless of its content.  Declaring data dependencies for the generated executable is not supported. |
+| `executable` | Boolean; [nonconfigurable](/versions/8.3.1/reference/be/common-definitions#configurable-attributes); default is `False` Declare output to be executable. Setting this flag to True means the output is an executable file and can be run using the `run` command. The genrule must produce exactly one output in this case. If this attribute is set, `run` will try executing the file regardless of its content.  Declaring data dependencies for the generated executable is not supported. |
 | `local` | Boolean; default is `False`  If set to True, this option forces this `genrule` to run using the "local" strategy, which means no remote execution, no sandboxing, no persistent workers.  This is equivalent to providing 'local' as a tag (`tags=["local"]`). |
 | `message` | String; default is `""` A progress message. A progress message that will be printed as this build step is executed. By default, the message is "Generating *output*" (or something equally bland) but you may provide a more specific one. Use this attribute instead of `echo` or other print statements in your `cmd` command, as this allows the build tool to control whether such progress messages are printed or not. |
 | `output_licenses` | Licence type; default is `["none"]` See [`common attributes`](/versions/8.3.1/reference/be/common-definitions#binary.output_licenses) |
-| `output_to_bindir` | Boolean; [nonconfigurable](common-definitions#configurable-attributes); default is `False`  If set to True, this option causes output files to be written into the `bin` directory instead of the `genfiles` directory. |
-| `toolchains` | List of [labels](/versions/8.3.1/concepts/labels); [nonconfigurable](common-definitions#configurable-attributes); default is `[]`  The set of targets whose [Make variables](/versions/8.3.1/reference/be/make-variables) this genrule is allowed to access, or the [`toolchain_type`](/versions/8.3.1/docs/toolchains) targets that this genrule will access.  Toolchains accessed via `toolchain_type` must also provide a `TemplateVariableInfo` provider, which the target can use to access toolchain details. |
+| `output_to_bindir` | Boolean; [nonconfigurable](/versions/8.3.1/reference/be/common-definitions#configurable-attributes); default is `False`  If set to True, this option causes output files to be written into the `bin` directory instead of the `genfiles` directory. |
+| `toolchains` | List of [labels](/versions/8.3.1/concepts/labels); [nonconfigurable](/versions/8.3.1/reference/be/common-definitions#configurable-attributes); default is `[]`  The set of targets whose [Make variables](/versions/8.3.1/reference/be/make-variables) this genrule is allowed to access, or the [`toolchain_type`](/versions/8.3.1/docs/toolchains) targets that this genrule will access.  Toolchains accessed via `toolchain_type` must also provide a `TemplateVariableInfo` provider, which the target can use to access toolchain details. |
 | `tools` | List of [labels](/versions/8.3.1/concepts/labels); default is `[]` A list of *tool* dependencies for this rule. See the definition of [dependencies](/versions/8.3.1/concepts/build-ref#deps) for more information.   The build system ensures these prerequisites are built before running the genrule command; they are built using the [*exec* configuration](/versions/8.3.1/contribute/guide#configurations), since these tools are executed as part of the build. The path of an individual `tools` target `//x:y` can be obtained using `$(location //x:y)`.  Any `*_binary` or tool to be executed by `cmd` must appear in this list, not in `srcs`, to ensure they are built in the correct configuration. |
 
 ## starlark\_doc\_extract
@@ -572,5 +572,5 @@ test_suite(
 | Attributes | |
 | --- | --- |
 | `name` | [Name](/versions/8.3.1/concepts/labels#target-names); required  A unique name for this target. |
-| `tags` | List of strings; [nonconfigurable](common-definitions#configurable-attributes); default is `[]` List of text tags such as "small" or "database" or "-flaky". Tags may be any valid string. Tags which begin with a "-" character are considered negative tags. The preceding "-" character is not considered part of the tag, so a suite tag of "-small" matches a test's "small" size. All other tags are considered positive tags.  Optionally, to make positive tags more explicit, tags may also begin with the "+" character, which will not be evaluated as part of the text of the tag. It merely makes the positive and negative distinction easier to read.  Only test rules that match **all** of the positive tags and **none** of the negative tags will be included in the test suite. Note that this does not mean that error checking for dependencies on tests that are filtered out is skipped; the dependencies on skipped tests still need to be legal (e.g. not blocked by visibility constraints).  The `manual` tag keyword is treated differently than the above by the "test\_suite expansion" performed by the `bazel test` command on invocations involving wildcard [target patterns](https://bazel.build/versions/8.3.1/docs/build#specifying-build-targets). There, `test_suite` targets tagged "manual" are filtered out (and thus not expanded). This behavior is consistent with how `bazel build` and `bazel test` handle wildcard target patterns in general. Note that this is explicitly different from how `bazel query 'tests(E)'` behaves, as suites are always expanded by the `tests` query function, regardless of the `manual` tag.  Note that a test's `size` is considered a tag for the purpose of filtering.  If you need a `test_suite` that contains tests with mutually exclusive tags (e.g. all small and medium tests), you'll have to create three `test_suite` rules: one for all small tests, one for all medium tests, and one that includes the previous two. |
-| `tests` | List of [labels](/versions/8.3.1/concepts/labels); [nonconfigurable](common-definitions#configurable-attributes); default is `[]` A list of test suites and test targets of any language. Any `*_test` is accepted here, independent of the language. No `*_binary` targets are accepted however, even if they happen to run a test. Filtering by the specified `tags` is only done for tests listed directly in this attribute. If this attribute contains `test_suite`s, the tests inside those will not be filtered by this `test_suite` (they are considered to be filtered already).  If the `tests` attribute is unspecified or empty, the rule will default to including all test rules in the current BUILD file that are not tagged as `manual`. These rules are still subject to `tag` filtering. |
\ No newline at end of file
+| `tags` | List of strings; [nonconfigurable](/versions/8.3.1/reference/be/common-definitions#configurable-attributes); default is `[]` List of text tags such as "small" or "database" or "-flaky". Tags may be any valid string. Tags which begin with a "-" character are considered negative tags. The preceding "-" character is not considered part of the tag, so a suite tag of "-small" matches a test's "small" size. All other tags are considered positive tags.  Optionally, to make positive tags more explicit, tags may also begin with the "+" character, which will not be evaluated as part of the text of the tag. It merely makes the positive and negative distinction easier to read.  Only test rules that match **all** of the positive tags and **none** of the negative tags will be included in the test suite. Note that this does not mean that error checking for dependencies on tests that are filtered out is skipped; the dependencies on skipped tests still need to be legal (e.g. not blocked by visibility constraints).  The `manual` tag keyword is treated differently than the above by the "test\_suite expansion" performed by the `bazel test` command on invocations involving wildcard [target patterns](https://bazel.build/versions/8.3.1/docs/build#specifying-build-targets). There, `test_suite` targets tagged "manual" are filtered out (and thus not expanded). This behavior is consistent with how `bazel build` and `bazel test` handle wildcard target patterns in general. Note that this is explicitly different from how `bazel query 'tests(E)'` behaves, as suites are always expanded by the `tests` query function, regardless of the `manual` tag.  Note that a test's `size` is considered a tag for the purpose of filtering.  If you need a `test_suite` that contains tests with mutually exclusive tags (e.g. all small and medium tests), you'll have to create three `test_suite` rules: one for all small tests, one for all medium tests, and one that includes the previous two. |
+| `tests` | List of [labels](/versions/8.3.1/concepts/labels); [nonconfigurable](/versions/8.3.1/reference/be/common-definitions#configurable-attributes); default is `[]` A list of test suites and test targets of any language. Any `*_test` is accepted here, independent of the language. No `*_binary` targets are accepted however, even if they happen to run a test. Filtering by the specified `tags` is only done for tests listed directly in this attribute. If this attribute contains `test_suite`s, the tests inside those will not be filtered by this `test_suite` (they are considered to be filtered already).  If the `tests` attribute is unspecified or empty, the rule will default to including all test rules in the current BUILD file that are not tagged as `manual`. These rules are still subject to `tag` filtering. |
\ No newline at end of file
diff --git a/versions/8.3.1/reference/be/java.mdx b/versions/8.3.1/reference/be/java.mdx
index 0779edf4..b55d6449 100644
--- a/versions/8.3.1/reference/be/java.mdx
+++ b/versions/8.3.1/reference/be/java.mdx
@@ -15,7 +15,7 @@ title: 'Java Rules'
 
 ## java\_binary
 
-[View rule sourceopen\_in\_new](@rules_java//java/bazel/rules/bazel_java_binary.bzl)
+[View rule sourceopen\_in\_new](/versions/8.3.1/reference/be/@rules_java//java/bazel/rules/bazel_java_binary.bzl)
 
 ```
 java_binary(name, deps, srcs, data, resources, add_exports, add_opens, args, bootclasspath, classpath_resources, compatible_with, create_executable, deploy_env, deploy_manifest_lines, deprecation, distribs, env, exec_compatible_with, exec_properties, features, javacopts, jvm_flags, launcher, licenses, main_class, neverlink, output_licenses, plugins, resource_strip_prefix, restricted_to, runtime_deps, stamp, tags, target_compatible_with, testonly, toolchains, use_launcher, use_testrunner, visibility)
@@ -102,7 +102,7 @@ java_binary(
 | Attributes | |
 | --- | --- |
 | `name` | [Name](/versions/8.3.1/concepts/labels#target-names); required  A unique name for this target. |
-| `deps` | List of [labels](/versions/8.3.1/concepts/labels); default is `[]` The list of other libraries to be linked in to the target. See general comments about `deps` at [Typical attributes defined by most build rules](common-definitions#typical-attributes). |
+| `deps` | List of [labels](/versions/8.3.1/concepts/labels); default is `[]` The list of other libraries to be linked in to the target. See general comments about `deps` at [Typical attributes defined by most build rules](/versions/8.3.1/reference/be/common-definitions#typical-attributes). |
 | `srcs` | List of [labels](/versions/8.3.1/concepts/labels); default is `[]` The list of source files that are processed to create the target. This attribute is almost always required; see exceptions below. Source files of type `.java` are compiled. In case of generated `.java` files it is generally advisable to put the generating rule's name here instead of the name of the file itself. This not only improves readability but makes the rule more resilient to future changes: if the generating rule generates different files in the future, you only need to fix one place: the `outs` of the generating rule. You should not list the generating rule in `deps` because it is a no-op.  Source files of type `.srcjar` are unpacked and compiled. (This is useful if you need to generate a set of `.java` files with a genrule.)  Rules: if the rule (typically `genrule` or `filegroup`) generates any of the files listed above, they will be used the same way as described for source files.  This argument is almost always required, except if a [`main_class`](#java_binary.main_class) attribute specifies a class on the runtime classpath or you specify the `runtime_deps` argument. |
 | `data` | List of [labels](/versions/8.3.1/concepts/labels); default is `[]` The list of files needed by this library at runtime. See general comments about `data` at [Typical attributes defined by most build rules](/versions/8.3.1/reference/be/common-definitions#typical-attributes). |
 | `resources` | List of [labels](/versions/8.3.1/concepts/labels); default is `[]` A list of data files to include in a Java jar. Resources may be source files or generated files.  If resources are specified, they will be bundled in the jar along with the usual `.class` files produced by compilation. The location of the resources inside of the jar file is determined by the project structure. Bazel first looks for Maven's [standard directory layout](https://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html), (a "src" directory followed by a "resources" directory grandchild). If that is not found, Bazel then looks for the topmost directory named "java" or "javatests" (so, for example, if a resource is at `/x/java/y/java/z`, the path of the resource will be `y/java/z`. This heuristic cannot be overridden, however, the `resource_strip_prefix` attribute can be used to specify a specific alternative directory for resource files. |
@@ -112,9 +112,9 @@ java_binary(
 | `classpath_resources` | List of [labels](/versions/8.3.1/concepts/labels); default is `[]` *DO NOT USE THIS OPTION UNLESS THERE IS NO OTHER WAY)* A list of resources that must be located at the root of the java tree. This attribute's only purpose is to support third-party libraries that require that their resources be found on the classpath as exactly `"myconfig.xml"`. It is only allowed on binaries and not libraries, due to the danger of namespace conflicts. |
 | `create_executable` | Boolean; default is `True` Deprecated, use `java_single_jar` instead. |
 | `deploy_env` | List of [labels](/versions/8.3.1/concepts/labels); default is `[]` A list of other `java_binary` targets which represent the deployment environment for this binary. Set this attribute when building a plugin which will be loaded by another `java_binary`.  Setting this attribute excludes all dependencies from the runtime classpath (and the deploy jar) of this binary that are shared between this binary and the targets specified in `deploy_env`. |
-| `deploy_manifest_lines` | List of strings; default is `[]` A list of lines to add to the `META-INF/manifest.mf` file generated for the `*_deploy.jar` target. The contents of this attribute are *not* subject to ["Make variable"](make-variables) substitution. |
-| `javacopts` | List of strings; default is `[]` Extra compiler options for this binary. Subject to ["Make variable"](make-variables) substitution and [Bourne shell tokenization](common-definitions#sh-tokenization). These compiler options are passed to javac after the global compiler options. |
-| `jvm_flags` | List of strings; default is `[]` A list of flags to embed in the wrapper script generated for running this binary. Subject to [$(location)](/versions/8.3.1/reference/be/make-variables#location) and ["Make variable"](make-variables) substitution, and [Bourne shell tokenization](common-definitions#sh-tokenization). The wrapper script for a Java binary includes a CLASSPATH definition (to find all the dependent jars) and invokes the right Java interpreter. The command line generated by the wrapper script includes the name of the main class followed by a `"$@"` so you can pass along other arguments after the classname. However, arguments intended for parsing by the JVM must be specified *before* the classname on the command line. The contents of `jvm_flags` are added to the wrapper script before the classname is listed.  Note that this attribute has *no effect* on `*_deploy.jar` outputs. |
+| `deploy_manifest_lines` | List of strings; default is `[]` A list of lines to add to the `META-INF/manifest.mf` file generated for the `*_deploy.jar` target. The contents of this attribute are *not* subject to ["Make variable"](/versions/8.3.1/reference/be/make-variables) substitution. |
+| `javacopts` | List of strings; default is `[]` Extra compiler options for this binary. Subject to ["Make variable"](/versions/8.3.1/reference/be/make-variables) substitution and [Bourne shell tokenization](/versions/8.3.1/reference/be/common-definitions#sh-tokenization). These compiler options are passed to javac after the global compiler options. |
+| `jvm_flags` | List of strings; default is `[]` A list of flags to embed in the wrapper script generated for running this binary. Subject to [$(location)](/versions/8.3.1/reference/be/make-variables#location) and ["Make variable"](/versions/8.3.1/reference/be/make-variables) substitution, and [Bourne shell tokenization](/versions/8.3.1/reference/be/common-definitions#sh-tokenization). The wrapper script for a Java binary includes a CLASSPATH definition (to find all the dependent jars) and invokes the right Java interpreter. The command line generated by the wrapper script includes the name of the main class followed by a `"$@"` so you can pass along other arguments after the classname. However, arguments intended for parsing by the JVM must be specified *before* the classname on the command line. The contents of `jvm_flags` are added to the wrapper script before the classname is listed.  Note that this attribute has *no effect* on `*_deploy.jar` outputs. |
 | `launcher` | [Label](/versions/8.3.1/concepts/labels); default is `None` Specify a binary that will be used to run your Java program instead of the normal `bin/java` program included with the JDK. The target must be a `cc_binary`. Any `cc_binary` that implements the [Java Invocation API](http://docs.oracle.com/javase/7/docs/technotes/guides/jni/spec/invocation.html) can be specified as a value for this attribute. By default, Bazel will use the normal JDK launcher (bin/java or java.exe).  The related [`--java_launcher`](/versions/8.3.1/docs/user-manual#flag--java_launcher) Bazel flag affects only those `java_binary` and `java_test` targets that have *not* specified a `launcher` attribute.  Note that your native (C++, SWIG, JNI) dependencies will be built differently depending on whether you are using the JDK launcher or another launcher:   * If you are using the normal JDK launcher (the default), native dependencies are   built as a shared library named `{name}_nativedeps.so`, where   `{name}` is the `name` attribute of this java\_binary rule.   Unused code is *not* removed by the linker in this configuration. * If you are using any other launcher, native (C++) dependencies are statically   linked into a binary named `{name}_nativedeps`, where `{name}`   is the `name` attribute of this java\_binary rule. In this case,   the linker will remove any code it thinks is unused from the resulting binary,   which means any C++ code accessed only via JNI may not be linked in unless   that `cc_library` target specifies `alwayslink = True`.   When using any launcher other than the default JDK launcher, the format of the `*_deploy.jar` output changes. See the main [java\_binary](#java_binary) docs for details. |
 | `main_class` | String; default is `""` Name of class with `main()` method to use as entry point. If a rule uses this option, it does not need a `srcs=[...]` list. Thus, with this attribute one can make an executable from a Java library that already contains one or more `main()` methods. The value of this attribute is a class name, not a source file. The class must be available at runtime: it may be compiled by this rule (from `srcs`) or provided by direct or transitive dependencies (through `runtime_deps` or `deps`). If the class is unavailable, the binary will fail at runtime; there is no build-time check. |
 | `neverlink` | Boolean; default is `False` |
@@ -127,7 +127,7 @@ java_binary(
 
 ## java\_import
 
-[View rule sourceopen\_in\_new](@rules_java//java/bazel/rules/bazel_java_import.bzl)
+[View rule sourceopen\_in\_new](/versions/8.3.1/reference/be/@rules_java//java/bazel/rules/bazel_java_import.bzl)
 
 ```
 java_import(name, deps, data, add_exports, add_opens, compatible_with, constraints, deprecation, distribs, exec_compatible_with, exec_properties, exports, features, jars, licenses, neverlink, proguard_specs, restricted_to, runtime_deps, srcjar, tags, target_compatible_with, testonly, toolchains, visibility)
@@ -169,7 +169,7 @@ libraries for `java_library` and
 
 ## java\_library
 
-[View rule sourceopen\_in\_new](@rules_java//java/bazel/rules/bazel_java_library.bzl)
+[View rule sourceopen\_in\_new](/versions/8.3.1/reference/be/@rules_java//java/bazel/rules/bazel_java_library.bzl)
 
 ```
 java_library(name, deps, srcs, data, resources, add_exports, add_opens, bootclasspath, compatible_with, deprecation, distribs, exec_compatible_with, exec_properties, exported_plugins, exports, features, javabuilder_jvm_flags, javacopts, licenses, neverlink, plugins, proguard_specs, resource_strip_prefix, restricted_to, runtime_deps, tags, target_compatible_with, testonly, toolchains, visibility)
@@ -198,7 +198,7 @@ This rule compiles and links sources into a `.jar` file.
 | `exported_plugins` | List of [labels](/versions/8.3.1/concepts/labels); default is `[]` The list of `java_plugin`s (e.g. annotation processors) to export to libraries that directly depend on this library. The specified list of `java_plugin`s will be applied to any library which directly depends on this library, just as if that library had explicitly declared these labels in `plugins`. |
 | `exports` | List of [labels](/versions/8.3.1/concepts/labels); default is `[]` Exported libraries. Listing rules here will make them available to parent rules, as if the parents explicitly depended on these rules. This is not true for regular (non-exported) `deps`.  Summary: a rule *X* can access the code in *Y* if there exists a dependency path between them that begins with a `deps` edge followed by zero or more `exports` edges. Let's see some examples to illustrate this.  Assume *A* depends on *B* and *B* depends on *C*. In this case C is a *transitive* dependency of A, so changing C's sources and rebuilding A will correctly rebuild everything. However A will not be able to use classes in C. To allow that, either A has to declare C in its `deps`, or B can make it easier for A (and anything that may depend on A) by declaring C in its (B's) `exports` attribute.  The closure of exported libraries is available to all direct parent rules. Take a slightly different example: A depends on B, B depends on C and D, and also exports C but not D. Now A has access to C but not to D. Now, if C and D exported some libraries, C' and D' respectively, A could only access C' but not D'.  Important: an exported rule is not a regular dependency. Sticking to the previous example, if B exports C and wants to also use C, it has to also list it in its own `deps`. |
 | `javabuilder_jvm_flags` | List of strings; default is `[]` Restricted API, do not use! |
-| `javacopts` | List of strings; default is `[]` Extra compiler options for this library. Subject to ["Make variable"](make-variables) substitution and [Bourne shell tokenization](common-definitions#sh-tokenization). These compiler options are passed to javac after the global compiler options. |
+| `javacopts` | List of strings; default is `[]` Extra compiler options for this library. Subject to ["Make variable"](/versions/8.3.1/reference/be/make-variables) substitution and [Bourne shell tokenization](/versions/8.3.1/reference/be/common-definitions#sh-tokenization). These compiler options are passed to javac after the global compiler options. |
 | `neverlink` | Boolean; default is `False` Whether this library should only be used for compilation and not at runtime. Useful if the library will be provided by the runtime environment during execution. Examples of such libraries are the IDE APIs for IDE plug-ins or `tools.jar` for anything running on a standard JDK. Note that `neverlink = True` does not prevent the compiler from inlining material from this library into compilation targets that depend on it, as permitted by the Java Language Specification (e.g., `static final` constants of `String` or of primitive types). The preferred use case is therefore when the runtime library is identical to the compilation library.  If the runtime library differs from the compilation library then you must ensure that it differs only in places that the JLS forbids compilers to inline (and that must hold for all future versions of the JLS). |
 | `plugins` | List of [labels](/versions/8.3.1/concepts/labels); default is `[]` Java compiler plugins to run at compile-time. Every `java_plugin` specified in this attribute will be run whenever this rule is built. A library may also inherit plugins from dependencies that use `exported_plugins`. Resources generated by the plugin will be included in the resulting jar of this rule. |
 | `proguard_specs` | List of [labels](/versions/8.3.1/concepts/labels); default is `[]` Files to be used as Proguard specification. These will describe the set of specifications to be used by Proguard. If specified, they will be added to any `android_binary` target depending on this library. The files included here must only have idempotent rules, namely -dontnote, -dontwarn, assumenosideeffects, and rules that start with -keep. Other options can only appear in `android_binary`'s proguard\_specs, to ensure non-tautological merges. |
@@ -207,7 +207,7 @@ This rule compiles and links sources into a `.jar` file.
 
 ## java\_test
 
-[View rule sourceopen\_in\_new](@rules_java//java/bazel/rules/bazel_java_test.bzl)
+[View rule sourceopen\_in\_new](/versions/8.3.1/reference/be/@rules_java//java/bazel/rules/bazel_java_test.bzl)
 
 ```
 java_test(name, deps, srcs, data, resources, add_exports, add_opens, args, bootclasspath, classpath_resources, compatible_with, create_executable, deploy_manifest_lines, deprecation, distribs, env, env_inherit, exec_compatible_with, exec_properties, features, flaky, javacopts, jvm_flags, launcher, licenses, local, main_class, neverlink, plugins, resource_strip_prefix, restricted_to, runtime_deps, shard_count, size, stamp, tags, target_compatible_with, test_class, testonly, timeout, toolchains, use_launcher, use_testrunner, visibility)
@@ -225,8 +225,7 @@ test code. The test runner's main method is invoked instead of the main class be
   [java\_binary](#java_binary) for more details.
 
 See the section on `java_binary()` arguments. This rule also
-supports all [attributes common
-to all test rules (\*\_test)](https://bazel.build/versions/8.3.1/reference/be/common-definitions#common-attributes-tests).
+supports all [attributes common to all test rules (\*\_test)](https://bazel.build/versions/8.3.1/reference/be/common-definitions#common-attributes-tests).
 
 #### Examples
 
@@ -255,7 +254,7 @@ java_test(
 | Attributes | |
 | --- | --- |
 | `name` | [Name](/versions/8.3.1/concepts/labels#target-names); required  A unique name for this target. |
-| `deps` | List of [labels](/versions/8.3.1/concepts/labels); default is `[]` The list of other libraries to be linked in to the target. See general comments about `deps` at [Typical attributes defined by most build rules](common-definitions#typical-attributes). |
+| `deps` | List of [labels](/versions/8.3.1/concepts/labels); default is `[]` The list of other libraries to be linked in to the target. See general comments about `deps` at [Typical attributes defined by most build rules](/versions/8.3.1/reference/be/common-definitions#typical-attributes). |
 | `srcs` | List of [labels](/versions/8.3.1/concepts/labels); default is `[]` The list of source files that are processed to create the target. This attribute is almost always required; see exceptions below. Source files of type `.java` are compiled. In case of generated `.java` files it is generally advisable to put the generating rule's name here instead of the name of the file itself. This not only improves readability but makes the rule more resilient to future changes: if the generating rule generates different files in the future, you only need to fix one place: the `outs` of the generating rule. You should not list the generating rule in `deps` because it is a no-op.  Source files of type `.srcjar` are unpacked and compiled. (This is useful if you need to generate a set of `.java` files with a genrule.)  Rules: if the rule (typically `genrule` or `filegroup`) generates any of the files listed above, they will be used the same way as described for source files.  This argument is almost always required, except if a [`main_class`](#java_binary.main_class) attribute specifies a class on the runtime classpath or you specify the `runtime_deps` argument. |
 | `data` | List of [labels](/versions/8.3.1/concepts/labels); default is `[]` The list of files needed by this library at runtime. See general comments about `data` at [Typical attributes defined by most build rules](/versions/8.3.1/reference/be/common-definitions#typical-attributes). |
 | `resources` | List of [labels](/versions/8.3.1/concepts/labels); default is `[]` A list of data files to include in a Java jar. Resources may be source files or generated files.  If resources are specified, they will be bundled in the jar along with the usual `.class` files produced by compilation. The location of the resources inside of the jar file is determined by the project structure. Bazel first looks for Maven's [standard directory layout](https://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html), (a "src" directory followed by a "resources" directory grandchild). If that is not found, Bazel then looks for the topmost directory named "java" or "javatests" (so, for example, if a resource is at `/x/java/y/java/z`, the path of the resource will be `y/java/z`. This heuristic cannot be overridden, however, the `resource_strip_prefix` attribute can be used to specify a specific alternative directory for resource files. |
@@ -264,9 +263,9 @@ java_test(
 | `bootclasspath` | [Label](/versions/8.3.1/concepts/labels); default is `None` Restricted API, do not use! |
 | `classpath_resources` | List of [labels](/versions/8.3.1/concepts/labels); default is `[]` *DO NOT USE THIS OPTION UNLESS THERE IS NO OTHER WAY)* A list of resources that must be located at the root of the java tree. This attribute's only purpose is to support third-party libraries that require that their resources be found on the classpath as exactly `"myconfig.xml"`. It is only allowed on binaries and not libraries, due to the danger of namespace conflicts. |
 | `create_executable` | Boolean; default is `True` Deprecated, use `java_single_jar` instead. |
-| `deploy_manifest_lines` | List of strings; default is `[]` A list of lines to add to the `META-INF/manifest.mf` file generated for the `*_deploy.jar` target. The contents of this attribute are *not* subject to ["Make variable"](make-variables) substitution. |
-| `javacopts` | List of strings; default is `[]` Extra compiler options for this binary. Subject to ["Make variable"](make-variables) substitution and [Bourne shell tokenization](common-definitions#sh-tokenization). These compiler options are passed to javac after the global compiler options. |
-| `jvm_flags` | List of strings; default is `[]` A list of flags to embed in the wrapper script generated for running this binary. Subject to [$(location)](/versions/8.3.1/reference/be/make-variables#location) and ["Make variable"](make-variables) substitution, and [Bourne shell tokenization](common-definitions#sh-tokenization). The wrapper script for a Java binary includes a CLASSPATH definition (to find all the dependent jars) and invokes the right Java interpreter. The command line generated by the wrapper script includes the name of the main class followed by a `"$@"` so you can pass along other arguments after the classname. However, arguments intended for parsing by the JVM must be specified *before* the classname on the command line. The contents of `jvm_flags` are added to the wrapper script before the classname is listed.  Note that this attribute has *no effect* on `*_deploy.jar` outputs. |
+| `deploy_manifest_lines` | List of strings; default is `[]` A list of lines to add to the `META-INF/manifest.mf` file generated for the `*_deploy.jar` target. The contents of this attribute are *not* subject to ["Make variable"](/versions/8.3.1/reference/be/make-variables) substitution. |
+| `javacopts` | List of strings; default is `[]` Extra compiler options for this binary. Subject to ["Make variable"](/versions/8.3.1/reference/be/make-variables) substitution and [Bourne shell tokenization](/versions/8.3.1/reference/be/common-definitions#sh-tokenization). These compiler options are passed to javac after the global compiler options. |
+| `jvm_flags` | List of strings; default is `[]` A list of flags to embed in the wrapper script generated for running this binary. Subject to [$(location)](/versions/8.3.1/reference/be/make-variables#location) and ["Make variable"](/versions/8.3.1/reference/be/make-variables) substitution, and [Bourne shell tokenization](/versions/8.3.1/reference/be/common-definitions#sh-tokenization). The wrapper script for a Java binary includes a CLASSPATH definition (to find all the dependent jars) and invokes the right Java interpreter. The command line generated by the wrapper script includes the name of the main class followed by a `"$@"` so you can pass along other arguments after the classname. However, arguments intended for parsing by the JVM must be specified *before* the classname on the command line. The contents of `jvm_flags` are added to the wrapper script before the classname is listed.  Note that this attribute has *no effect* on `*_deploy.jar` outputs. |
 | `launcher` | [Label](/versions/8.3.1/concepts/labels); default is `None` Specify a binary that will be used to run your Java program instead of the normal `bin/java` program included with the JDK. The target must be a `cc_binary`. Any `cc_binary` that implements the [Java Invocation API](http://docs.oracle.com/javase/7/docs/technotes/guides/jni/spec/invocation.html) can be specified as a value for this attribute. By default, Bazel will use the normal JDK launcher (bin/java or java.exe).  The related [`--java_launcher`](/versions/8.3.1/docs/user-manual#flag--java_launcher) Bazel flag affects only those `java_binary` and `java_test` targets that have *not* specified a `launcher` attribute.  Note that your native (C++, SWIG, JNI) dependencies will be built differently depending on whether you are using the JDK launcher or another launcher:   * If you are using the normal JDK launcher (the default), native dependencies are   built as a shared library named `{name}_nativedeps.so`, where   `{name}` is the `name` attribute of this java\_binary rule.   Unused code is *not* removed by the linker in this configuration. * If you are using any other launcher, native (C++) dependencies are statically   linked into a binary named `{name}_nativedeps`, where `{name}`   is the `name` attribute of this java\_binary rule. In this case,   the linker will remove any code it thinks is unused from the resulting binary,   which means any C++ code accessed only via JNI may not be linked in unless   that `cc_library` target specifies `alwayslink = True`.   When using any launcher other than the default JDK launcher, the format of the `*_deploy.jar` output changes. See the main [java\_binary](#java_binary) docs for details. |
 | `main_class` | String; default is `""` Name of class with `main()` method to use as entry point. If a rule uses this option, it does not need a `srcs=[...]` list. Thus, with this attribute one can make an executable from a Java library that already contains one or more `main()` methods. The value of this attribute is a class name, not a source file. The class must be available at runtime: it may be compiled by this rule (from `srcs`) or provided by direct or transitive dependencies (through `runtime_deps` or `deps`). If the class is unavailable, the binary will fail at runtime; there is no build-time check. |
 | `neverlink` | Boolean; default is `False` |
@@ -280,7 +279,7 @@ java_test(
 
 ## java\_package\_configuration
 
-[View rule sourceopen\_in\_new](@rules_java//java/common/rules/java_package_configuration.bzl)
+[View rule sourceopen\_in\_new](/versions/8.3.1/reference/be/@rules_java//java/common/rules/java_package_configuration.bzl)
 
 ```
 java_package_configuration(name, data, compatible_with, deprecation, distribs, exec_compatible_with, exec_properties, features, javacopts, output_licenses, packages, restricted_to, system, tags, target_compatible_with, testonly, toolchains, visibility)
@@ -328,7 +327,7 @@ java_toolchain(
 
 ## java\_plugin
 
-[View rule sourceopen\_in\_new](@rules_java//java/bazel/rules/bazel_java_plugin.bzl)
+[View rule sourceopen\_in\_new](/versions/8.3.1/reference/be/@rules_java//java/bazel/rules/bazel_java_plugin.bzl)
 
 ```
 java_plugin(name, deps, srcs, data, resources, add_exports, add_opens, bootclasspath, compatible_with, deprecation, distribs, exec_compatible_with, exec_properties, features, generates_api, javabuilder_jvm_flags, javacopts, licenses, neverlink, output_licenses, plugins, processor_class, proguard_specs, resource_strip_prefix, restricted_to, tags, target_compatible_with, testonly, toolchains, visibility)
@@ -364,7 +363,7 @@ except for the addition of the `processor_class` and
 | `bootclasspath` | [Label](/versions/8.3.1/concepts/labels); default is `None` Restricted API, do not use! |
 | `generates_api` | Boolean; default is `False` This attribute marks annotation processors that generate API code. If a rule uses an API-generating annotation processor, other rules depending on it can refer to the generated code only if their compilation actions are scheduled after the generating rule. This attribute instructs Bazel to introduce scheduling constraints when --java\_header\_compilation is enabled. *WARNING: This attribute affects build performance, use it only if necessary.* |
 | `javabuilder_jvm_flags` | List of strings; default is `[]` Restricted API, do not use! |
-| `javacopts` | List of strings; default is `[]` Extra compiler options for this library. Subject to ["Make variable"](make-variables) substitution and [Bourne shell tokenization](common-definitions#sh-tokenization). These compiler options are passed to javac after the global compiler options. |
+| `javacopts` | List of strings; default is `[]` Extra compiler options for this library. Subject to ["Make variable"](/versions/8.3.1/reference/be/make-variables) substitution and [Bourne shell tokenization](/versions/8.3.1/reference/be/common-definitions#sh-tokenization). These compiler options are passed to javac after the global compiler options. |
 | `neverlink` | Boolean; default is `False` Whether this library should only be used for compilation and not at runtime. Useful if the library will be provided by the runtime environment during execution. Examples of such libraries are the IDE APIs for IDE plug-ins or `tools.jar` for anything running on a standard JDK. Note that `neverlink = True` does not prevent the compiler from inlining material from this library into compilation targets that depend on it, as permitted by the Java Language Specification (e.g., `static final` constants of `String` or of primitive types). The preferred use case is therefore when the runtime library is identical to the compilation library.  If the runtime library differs from the compilation library then you must ensure that it differs only in places that the JLS forbids compilers to inline (and that must hold for all future versions of the JLS). |
 | `output_licenses` | List of strings; default is `[]` |
 | `plugins` | List of [labels](/versions/8.3.1/concepts/labels); default is `[]` Java compiler plugins to run at compile-time. Every `java_plugin` specified in this attribute will be run whenever this rule is built. A library may also inherit plugins from dependencies that use `exported_plugins`. Resources generated by the plugin will be included in the resulting jar of this rule. |
@@ -374,7 +373,7 @@ except for the addition of the `processor_class` and
 
 ## java\_runtime
 
-[View rule sourceopen\_in\_new](@rules_java//java/common/rules/java_runtime.bzl)
+[View rule sourceopen\_in\_new](/versions/8.3.1/reference/be/@rules_java//java/common/rules/java_runtime.bzl)
 
 ```
 java_runtime(name, srcs, compatible_with, default_cds, deprecation, distribs, exec_compatible_with, exec_properties, features, hermetic_srcs, hermetic_static_libs, java, java_home, lib_ct_sym, lib_modules, output_licenses, restricted_to, tags, target_compatible_with, testonly, toolchains, version, visibility)
@@ -410,7 +409,7 @@ java_runtime(
 
 ## java\_toolchain
 
-[View rule sourceopen\_in\_new](@rules_java//java/common/rules/java_toolchain.bzl)
+[View rule sourceopen\_in\_new](/versions/8.3.1/reference/be/@rules_java//java/common/rules/java_toolchain.bzl)
 
 ```
 java_toolchain(name, android_lint_data, android_lint_jvm_opts, android_lint_opts, android_lint_package_configuration, android_lint_runner, bootclasspath, compatible_javacopts, compatible_with, deprecation, deps_checker, distribs, exec_compatible_with, exec_properties, features, forcibly_disable_header_compilation, genclass, header_compiler, header_compiler_builtin_processors, header_compiler_direct, ijar, jacocorunner, java_runtime, javabuilder, javabuilder_data, javabuilder_jvm_opts, javac_supports_multiplex_workers, javac_supports_worker_cancellation, javac_supports_worker_multiplex_sandboxing, javac_supports_workers, javacopts, jspecify_implicit_deps, jspecify_javacopts, jspecify_packages, jspecify_processor, jspecify_processor_class, jspecify_stubs, jvm_opts, licenses, misc, oneversion, oneversion_allowlist, oneversion_allowlist_for_tests, oneversion_whitelist, package_configuration, proguard_allowlister, reduced_classpath_incompatible_processors, restricted_to, singlejar, source_version, tags, target_compatible_with, target_version, testonly, timezone_data, toolchains, tools, turbine_data, turbine_jvm_opts, visibility, xlint)
diff --git a/versions/8.3.1/reference/be/make-variables.mdx b/versions/8.3.1/reference/be/make-variables.mdx
index 54146221..5663d1b4 100644
--- a/versions/8.3.1/reference/be/make-variables.mdx
+++ b/versions/8.3.1/reference/be/make-variables.mdx
@@ -19,8 +19,7 @@ targets, and *custom* variables, which are defined in dependency targets
 and only available to targets that depend on them.
 
 The reason for the term "Make" is historical: the syntax and semantics of
-these variables were originally intended to match [GNU
-Make](https://www.gnu.org/software/make/manual/html_node/Using-Variables.html).
+these variables were originally intended to match [GNU Make](https://www.gnu.org/software/make/manual/html_node/Using-Variables.html).
 
 ## Use
 
@@ -64,8 +63,7 @@ and look at the top output lines with capital letters.
 **Toolchain option variables**
 
 * `COMPILATION_MODE`:
-  `fastbuild`, `dbg`, or `opt`. ([more
-  details](https://bazel.build/versions/8.3.1/docs/user-manual#flag--compilation_mode))
+  `fastbuild`, `dbg`, or `opt`. ([more details](https://bazel.build/versions/8.3.1/docs/user-manual#flag--compilation_mode))
 
 **Path variables**
 
@@ -304,7 +302,7 @@ rare cases. If you are tempted to use them, please [contact the Bazel devs](http
 
 Rule and [toolchain](/versions/8.3.1/docs/toolchains) writers can define
 completely custom variables by returning a
-[TemplateVariableInfo](/versions/8.3.1/rules/lib/TemplateVariableInfo)
+[TemplateVariableInfo](/versions/8.3.1/rules/lib/providers/TemplateVariableInfo)
 provider. Any rules depending on these through the
 `toolchains` attribute can then read their values:
 
diff --git a/versions/8.3.1/reference/be/overview.mdx b/versions/8.3.1/reference/be/overview.mdx
index 6fb2e635..bb87a5e5 100644
--- a/versions/8.3.1/reference/be/overview.mdx
+++ b/versions/8.3.1/reference/be/overview.mdx
@@ -37,18 +37,18 @@ For non-native Starlark rules that ship separately from Bazel, see the list of
 
 | Language | Binary rules | Library rules | Test rules | Other rules |
 | --- | --- | --- | --- | --- |
-| C / C++ | [cc\_binary](c-cpp#cc_binary) | [cc\_import](c-cpp#cc_import)   [cc\_library](c-cpp#cc_library)   [cc\_shared\_library](c-cpp#cc_shared_library)   [cc\_static\_library](c-cpp#cc_static_library) | [cc\_test](c-cpp#cc_test) | [cc\_toolchain](c-cpp#cc_toolchain)   [cc\_toolchain\_suite](c-cpp#cc_toolchain_suite)   [fdo\_prefetch\_hints](c-cpp#fdo_prefetch_hints)   [fdo\_profile](c-cpp#fdo_profile)   [memprof\_profile](c-cpp#memprof_profile)   [propeller\_optimize](c-cpp#propeller_optimize) |
-| Java | [java\_binary](java#java_binary) | [java\_import](java#java_import)   [java\_library](java#java_library) | [java\_test](java#java_test) | [java\_package\_configuration](java#java_package_configuration)   [java\_plugin](java#java_plugin)   [java\_runtime](java#java_runtime)   [java\_toolchain](java#java_toolchain) |
-| Objective-C |  | [objc\_import](objective-c#objc_import)   [objc\_library](objective-c#objc_library) |  |  |
-| Protocol Buffer |  | [cc\_proto\_library](protocol-buffer#cc_proto_library)   [java\_lite\_proto\_library](protocol-buffer#java_lite_proto_library)   [java\_proto\_library](protocol-buffer#java_proto_library)   [proto\_library](protocol-buffer#proto_library)   [py\_proto\_library](protocol-buffer#py_proto_library) |  | [proto\_lang\_toolchain](protocol-buffer#proto_lang_toolchain)   [proto\_toolchain](protocol-buffer#proto_toolchain) |
-| Python | [py\_binary](python#py_binary) | [py\_library](python#py_library) | [py\_test](python#py_test) | [py\_runtime](python#py_runtime) |
-| Shell | [sh\_binary](shell#sh_binary) | [sh\_library](shell#sh_library) | [sh\_test](shell#sh_test) |  |
+| C / C++ | [cc\_binary](/versions/8.3.1/reference/be/c-cpp#cc_binary) | [cc\_import](/versions/8.3.1/reference/be/c-cpp#cc_import)   [cc\_library](/versions/8.3.1/reference/be/c-cpp#cc_library)   [cc\_shared\_library](/versions/8.3.1/reference/be/c-cpp#cc_shared_library)   [cc\_static\_library](/versions/8.3.1/reference/be/c-cpp#cc_static_library) | [cc\_test](/versions/8.3.1/reference/be/c-cpp#cc_test) | [cc\_toolchain](/versions/8.3.1/reference/be/c-cpp#cc_toolchain)   [cc\_toolchain\_suite](/versions/8.3.1/reference/be/c-cpp#cc_toolchain_suite)   [fdo\_prefetch\_hints](/versions/8.3.1/reference/be/c-cpp#fdo_prefetch_hints)   [fdo\_profile](/versions/8.3.1/reference/be/c-cpp#fdo_profile)   [memprof\_profile](/versions/8.3.1/reference/be/c-cpp#memprof_profile)   [propeller\_optimize](/versions/8.3.1/reference/be/c-cpp#propeller_optimize) |
+| Java | [java\_binary](/versions/8.3.1/reference/be/java#java_binary) | [java\_import](/versions/8.3.1/reference/be/java#java_import)   [java\_library](/versions/8.3.1/reference/be/java#java_library) | [java\_test](/versions/8.3.1/reference/be/java#java_test) | [java\_package\_configuration](/versions/8.3.1/reference/be/java#java_package_configuration)   [java\_plugin](/versions/8.3.1/reference/be/java#java_plugin)   [java\_runtime](/versions/8.3.1/reference/be/java#java_runtime)   [java\_toolchain](/versions/8.3.1/reference/be/java#java_toolchain) |
+| Objective-C |  | [objc\_import](/versions/8.3.1/reference/be/objective-c#objc_import)   [objc\_library](/versions/8.3.1/reference/be/objective-c#objc_library) |  |  |
+| Protocol Buffer |  | [cc\_proto\_library](/versions/8.3.1/reference/be/protocol-buffer#cc_proto_library)   [java\_lite\_proto\_library](/versions/8.3.1/reference/be/protocol-buffer#java_lite_proto_library)   [java\_proto\_library](/versions/8.3.1/reference/be/protocol-buffer#java_proto_library)   [proto\_library](/versions/8.3.1/reference/be/protocol-buffer#proto_library)   [py\_proto\_library](/versions/8.3.1/reference/be/protocol-buffer#py_proto_library) |  | [proto\_lang\_toolchain](/versions/8.3.1/reference/be/protocol-buffer#proto_lang_toolchain)   [proto\_toolchain](/versions/8.3.1/reference/be/protocol-buffer#proto_toolchain) |
+| Python | [py\_binary](/versions/8.3.1/reference/be/python#py_binary) | [py\_library](/versions/8.3.1/reference/be/python#py_library) | [py\_test](/versions/8.3.1/reference/be/python#py_test) | [py\_runtime](/versions/8.3.1/reference/be/python#py_runtime) |
+| Shell | [sh\_binary](/versions/8.3.1/reference/be/shell#sh_binary) | [sh\_library](/versions/8.3.1/reference/be/shell#sh_library) | [sh\_test](/versions/8.3.1/reference/be/shell#sh_test) |  |
 
 ### Language-agnostic native rules
 
 | Family | Rules |
 | --- | --- |
-| Extra Actions | * [action\_listener](extra-actions#action_listener)* [extra\_action](extra-actions#extra_action) |
-| General | * [alias](general#alias)* [config\_setting](general#config_setting)* [filegroup](general#filegroup)* [genquery](general#genquery)* [genrule](general#genrule)* [starlark\_doc\_extract](general#starlark_doc_extract)* [test\_suite](general#test_suite) |
-| Platforms and Toolchains | * [constraint\_setting](platforms-and-toolchains#constraint_setting)* [constraint\_value](platforms-and-toolchains#constraint_value)* [platform](platforms-and-toolchains#platform)* [toolchain](platforms-and-toolchains#toolchain)* [toolchain\_type](platforms-and-toolchains#toolchain_type) |
-| Workspace | * [bind](workspace#bind)* [local\_repository](workspace#local_repository)* [new\_local\_repository](workspace#new_local_repository) |
\ No newline at end of file
+| Extra Actions | * [action\_listener](/versions/8.3.1/reference/be/extra-actions#action_listener)* [extra\_action](/versions/8.3.1/reference/be/extra-actions#extra_action) |
+| General | * [alias](/versions/8.3.1/reference/be/general#alias)* [config\_setting](/versions/8.3.1/reference/be/general#config_setting)* [filegroup](/versions/8.3.1/reference/be/general#filegroup)* [genquery](/versions/8.3.1/reference/be/general#genquery)* [genrule](/versions/8.3.1/reference/be/general#genrule)* [starlark\_doc\_extract](/versions/8.3.1/reference/be/general#starlark_doc_extract)* [test\_suite](/versions/8.3.1/reference/be/general#test_suite) |
+| Platforms and Toolchains | * [constraint\_setting](/versions/8.3.1/reference/be/platforms-and-toolchains#constraint_setting)* [constraint\_value](/versions/8.3.1/reference/be/platforms-and-toolchains#constraint_value)* [platform](/versions/8.3.1/reference/be/platforms-and-toolchains#platform)* [toolchain](/versions/8.3.1/reference/be/platforms-and-toolchains#toolchain)* [toolchain\_type](/versions/8.3.1/reference/be/platforms-and-toolchains#toolchain_type) |
+| Workspace | * [bind](/versions/8.3.1/reference/be/workspace#bind)* [local\_repository](/versions/8.3.1/reference/be/workspace#local_repository)* [new\_local\_repository](/versions/8.3.1/reference/be/workspace#new_local_repository) |
\ No newline at end of file
diff --git a/versions/8.3.1/reference/be/platforms-and-toolchains.mdx b/versions/8.3.1/reference/be/platforms-and-toolchains.mdx
index accff229..db14ba82 100644
--- a/versions/8.3.1/reference/be/platforms-and-toolchains.mdx
+++ b/versions/8.3.1/reference/be/platforms-and-toolchains.mdx
@@ -39,7 +39,7 @@ define a platform targeting an obscure cpu architecture.
 | Attributes | |
 | --- | --- |
 | `name` | [Name](/versions/8.3.1/concepts/labels#target-names); required  A unique name for this target. |
-| `default_constraint_value` | [Name](/versions/8.3.1/concepts/labels#target-names); [nonconfigurable](common-definitions#configurable-attributes); default is `None` The label of the default value for this setting, to be used if no value is given. If this attribute is present, the `constraint_value` it points to must be defined in the same package as this `constraint_setting`. If a constraint setting has a default value, then whenever a platform does not include any constraint value for that setting, it is the same as if the platform had specified the default value. Otherwise, if there is no default value, the constraint setting is considered to be unspecified by that platform. In that case, the platform would not match against any constraint list (such as for a `config_setting`) that requires a particular value for that setting. |
+| `default_constraint_value` | [Name](/versions/8.3.1/concepts/labels#target-names); [nonconfigurable](/versions/8.3.1/reference/be/common-definitions#configurable-attributes); default is `None` The label of the default value for this setting, to be used if no value is given. If this attribute is present, the `constraint_value` it points to must be defined in the same package as this `constraint_setting`. If a constraint setting has a default value, then whenever a platform does not include any constraint value for that setting, it is the same as if the platform had specified the default value. Otherwise, if there is no default value, the constraint setting is considered to be unspecified by that platform. In that case, the platform would not match against any constraint list (such as for a `config_setting`) that requires a particular value for that setting. |
 
 ## constraint\_value
 
@@ -73,7 +73,7 @@ Platforms can then declare that they have the `mips` architecture as an alternat
 | Attributes | |
 | --- | --- |
 | `name` | [Name](/versions/8.3.1/concepts/labels#target-names); required  A unique name for this target. |
-| `constraint_setting` | [Label](/versions/8.3.1/concepts/labels); [nonconfigurable](common-definitions#configurable-attributes); required The `constraint_setting` for which this `constraint_value` is a possible choice. |
+| `constraint_setting` | [Label](/versions/8.3.1/concepts/labels); [nonconfigurable](/versions/8.3.1/reference/be/common-definitions#configurable-attributes); required The `constraint_setting` for which this `constraint_value` is a possible choice. |
 
 ## platform
 
@@ -278,12 +278,12 @@ In this example, the child platforms have the following properties:
 | Attributes | |
 | --- | --- |
 | `name` | [Name](/versions/8.3.1/concepts/labels#target-names); required  A unique name for this target. |
-| `constraint_values` | List of [labels](/versions/8.3.1/concepts/labels); [nonconfigurable](common-definitions#configurable-attributes); default is `[]` The combination of constraint choices that this platform comprises. In order for a platform to apply to a given environment, the environment must have at least the values in this list. Each `constraint_value` in this list must be for a different `constraint_setting`. For example, you cannot define a platform that requires the cpu architecture to be both `@platforms//cpu:x86_64` and `@platforms//cpu:arm`. |
-| `exec_properties` | Dictionary: String -> String; [nonconfigurable](common-definitions#configurable-attributes); default is \{}` A map of strings that affect the way actions are executed remotely. Bazel makes no attempt to interpret this, it is treated as opaque data that's forwarded via the Platform field of the [remote execution protocol](https://github.com/bazelbuild/remote-apis). This includes any data from the parent platform's `exec_properties` attributes. If the child and parent platform define the same keys, the child's values are kept. Any keys associated with a value that is an empty string are removed from the dictionary. This attribute is a full replacement for the deprecated `remote_execution_properties`. |
-| `flags` | List of strings; [nonconfigurable](common-definitions#configurable-attributes); default is `[]` A list of flags that will be enabled when this platform is used as the target platform in a configuration. Only flags that can be set in transitions are allowed to be used. |
-| `missing_toolchain_error` | String; [nonconfigurable](common-definitions#configurable-attributes); default is `"For more information on platforms or toolchains see https://bazel.build/concepts/platforms-intro."` A custom error message that is displayed when a mandatory toolchain requirement cannot be satisfied for this target platform. Intended to point to relevant documentation users can read to understand why their toolchains are misconfigured. Not inherited from parent platforms. |
-| `parents` | List of [labels](/versions/8.3.1/concepts/labels); [nonconfigurable](common-definitions#configurable-attributes); default is `[]` The label of a `platform` target that this platform should inherit from. Although the attribute takes a list, there should be no more than one platform present. Any constraint\_settings not set directly on this platform will be found in the parent platform. See the section on [Platform Inheritance](#platform_inheritance) for details. |
-| `remote_execution_properties` | String; [nonconfigurable](common-definitions#configurable-attributes); default is `""` DEPRECATED. Please use exec\_properties attribute instead. A string used to configure a remote execution platform. Actual builds make no attempt to interpret this, it is treated as opaque data that can be used by a specific SpawnRunner. This can include data from the parent platform's "remote\_execution\_properties" attribute, by using the macro "\{PARENT\_REMOTE\_EXECUTION\_PROPERTIES\}". See the section on [Platform Inheritance](#platform_inheritance) for details. |
+| `constraint_values` | List of [labels](/versions/8.3.1/concepts/labels); [nonconfigurable](/versions/8.3.1/reference/be/common-definitions#configurable-attributes); default is `[]` The combination of constraint choices that this platform comprises. In order for a platform to apply to a given environment, the environment must have at least the values in this list. Each `constraint_value` in this list must be for a different `constraint_setting`. For example, you cannot define a platform that requires the cpu architecture to be both `@platforms//cpu:x86_64` and `@platforms//cpu:arm`. |
+| `exec_properties` | Dictionary: String -> String; [nonconfigurable](/versions/8.3.1/reference/be/common-definitions#configurable-attributes); default is \{}` A map of strings that affect the way actions are executed remotely. Bazel makes no attempt to interpret this, it is treated as opaque data that's forwarded via the Platform field of the [remote execution protocol](https://github.com/bazelbuild/remote-apis). This includes any data from the parent platform's `exec_properties` attributes. If the child and parent platform define the same keys, the child's values are kept. Any keys associated with a value that is an empty string are removed from the dictionary. This attribute is a full replacement for the deprecated `remote_execution_properties`. |
+| `flags` | List of strings; [nonconfigurable](/versions/8.3.1/reference/be/common-definitions#configurable-attributes); default is `[]` A list of flags that will be enabled when this platform is used as the target platform in a configuration. Only flags that can be set in transitions are allowed to be used. |
+| `missing_toolchain_error` | String; [nonconfigurable](/versions/8.3.1/reference/be/common-definitions#configurable-attributes); default is `"For more information on platforms or toolchains see https://bazel.build/concepts/platforms-intro."` A custom error message that is displayed when a mandatory toolchain requirement cannot be satisfied for this target platform. Intended to point to relevant documentation users can read to understand why their toolchains are misconfigured. Not inherited from parent platforms. |
+| `parents` | List of [labels](/versions/8.3.1/concepts/labels); [nonconfigurable](/versions/8.3.1/reference/be/common-definitions#configurable-attributes); default is `[]` The label of a `platform` target that this platform should inherit from. Although the attribute takes a list, there should be no more than one platform present. Any constraint\_settings not set directly on this platform will be found in the parent platform. See the section on [Platform Inheritance](#platform_inheritance) for details. |
+| `remote_execution_properties` | String; [nonconfigurable](/versions/8.3.1/reference/be/common-definitions#configurable-attributes); default is `""` DEPRECATED. Please use exec\_properties attribute instead. A string used to configure a remote execution platform. Actual builds make no attempt to interpret this, it is treated as opaque data that can be used by a specific SpawnRunner. This can include data from the parent platform's "remote\_execution\_properties" attribute, by using the macro "\{PARENT\_REMOTE\_EXECUTION\_PROPERTIES\}". See the section on [Platform Inheritance](#platform_inheritance) for details. |
 | `required_settings` | List of [labels](/versions/8.3.1/concepts/labels); default is `[]` A list of `config_setting`s that must be satisfied by the target configuration in order for this platform to be used as an execution platform during toolchain resolution. Required settings are not inherited from parent platforms. |
 
 ## toolchain
@@ -304,12 +304,12 @@ details.
 | Attributes | |
 | --- | --- |
 | `name` | [Name](/versions/8.3.1/concepts/labels#target-names); required  A unique name for this target. |
-| `exec_compatible_with` | List of [labels](/versions/8.3.1/concepts/labels); [nonconfigurable](common-definitions#configurable-attributes); default is `[]` A list of `constraint_value`s that must be satisfied by an execution platform in order for this toolchain to be selected for a target building on that platform. |
-| `target_compatible_with` | List of [labels](/versions/8.3.1/concepts/labels); [nonconfigurable](common-definitions#configurable-attributes); default is `[]` A list of `constraint_value`s that must be satisfied by the target platform in order for this toolchain to be selected for a target building for that platform. |
+| `exec_compatible_with` | List of [labels](/versions/8.3.1/concepts/labels); [nonconfigurable](/versions/8.3.1/reference/be/common-definitions#configurable-attributes); default is `[]` A list of `constraint_value`s that must be satisfied by an execution platform in order for this toolchain to be selected for a target building on that platform. |
+| `target_compatible_with` | List of [labels](/versions/8.3.1/concepts/labels); [nonconfigurable](/versions/8.3.1/reference/be/common-definitions#configurable-attributes); default is `[]` A list of `constraint_value`s that must be satisfied by the target platform in order for this toolchain to be selected for a target building for that platform. |
 | `target_settings` | List of [labels](/versions/8.3.1/concepts/labels); default is `[]` A list of `config_setting`s that must be satisfied by the target configuration in order for this toolchain to be selected during toolchain resolution. |
 | `toolchain` | [Name](/versions/8.3.1/concepts/labels#target-names); required The target representing the actual tool or tool suite that is made available when this toolchain is selected. |
-| `toolchain_type` | [Label](/versions/8.3.1/concepts/labels); [nonconfigurable](common-definitions#configurable-attributes); required The label of a `toolchain_type` target that represents the role that this toolchain serves. |
-| `use_target_platform_constraints` | Boolean; [nonconfigurable](common-definitions#configurable-attributes); default is `False` If `True`, this toolchain behaves as if its `exec_compatible_with` and `target_compatible_with` constraints are set to those of the current target platform. `exec_compatible_with` and `target_compatible_with` must not be set in that case. |
+| `toolchain_type` | [Label](/versions/8.3.1/concepts/labels); [nonconfigurable](/versions/8.3.1/reference/be/common-definitions#configurable-attributes); required The label of a `toolchain_type` target that represents the role that this toolchain serves. |
+| `use_target_platform_constraints` | Boolean; [nonconfigurable](/versions/8.3.1/reference/be/common-definitions#configurable-attributes); default is `False` If `True`, this toolchain behaves as if its `exec_compatible_with` and `target_compatible_with` constraints are set to those of the current target platform. `exec_compatible_with` and `target_compatible_with` must not be set in that case. |
 
 ## toolchain\_type
 
@@ -353,4 +353,4 @@ bar_binary = rule(
 | Attributes | |
 | --- | --- |
 | `name` | [Name](/versions/8.3.1/concepts/labels#target-names); required  A unique name for this target. |
-| `no_match_error` | String; [nonconfigurable](common-definitions#configurable-attributes); default is `""` A custom error message to display when no matching toolchain is found for this type. |
\ No newline at end of file
+| `no_match_error` | String; [nonconfigurable](/versions/8.3.1/reference/be/common-definitions#configurable-attributes); default is `""` A custom error message to display when no matching toolchain is found for this type. |
\ No newline at end of file
diff --git a/versions/8.3.1/reference/be/protocol-buffer.mdx b/versions/8.3.1/reference/be/protocol-buffer.mdx
index 0de46100..b5e8eee3 100644
--- a/versions/8.3.1/reference/be/protocol-buffer.mdx
+++ b/versions/8.3.1/reference/be/protocol-buffer.mdx
@@ -22,7 +22,7 @@ cc_proto_library(name, deps, compatible_with, deprecation, distribs, exec_compat
 
 `cc_proto_library` generates C++ code from `.proto` files.
 
-`deps` must point to [`proto_library`](protocol-buffer#proto_library) rules.
+`deps` must point to [`proto_library`](/versions/8.3.1/reference/be/protocol-buffer#proto_library) rules.
 
 Example:
 
@@ -47,7 +47,7 @@ proto_library(
 | Attributes | |
 | --- | --- |
 | `name` | [Name](/versions/8.3.1/concepts/labels#target-names); required  A unique name for this target. |
-| `deps` | List of [labels](/versions/8.3.1/concepts/labels); default is `[]` The list of [`proto_library`](protocol-buffer#proto_library) rules to generate C++ code for. |
+| `deps` | List of [labels](/versions/8.3.1/concepts/labels); default is `[]` The list of [`proto_library`](/versions/8.3.1/reference/be/protocol-buffer#proto_library) rules to generate C++ code for. |
 
 ## java\_lite\_proto\_library
 
@@ -59,7 +59,7 @@ java_lite_proto_library(name, deps, compatible_with, deprecation, distribs, exec
 
 `java_lite_proto_library` generates Java code from `.proto` files.
 
-`deps` must point to [`proto_library`](protocol-buffer#proto_library) rules.
+`deps` must point to [`proto_library`](/versions/8.3.1/reference/be/protocol-buffer#proto_library) rules.
 
 Example:
 
@@ -84,7 +84,7 @@ proto_library(
 | Attributes | |
 | --- | --- |
 | `name` | [Name](/versions/8.3.1/concepts/labels#target-names); required  A unique name for this target. |
-| `deps` | List of [labels](/versions/8.3.1/concepts/labels); default is `[]` The list of [`proto_library`](protocol-buffer#proto_library) rules to generate Java code for. |
+| `deps` | List of [labels](/versions/8.3.1/concepts/labels); default is `[]` The list of [`proto_library`](/versions/8.3.1/reference/be/protocol-buffer#proto_library) rules to generate Java code for. |
 
 ## java\_proto\_library
 
@@ -96,7 +96,7 @@ java_proto_library(name, deps, compatible_with, deprecation, distribs, exec_comp
 
 `java_proto_library` generates Java code from `.proto` files.
 
-`deps` must point to [`proto_library`](protocol-buffer#proto_library) rules.
+`deps` must point to [`proto_library`](/versions/8.3.1/reference/be/protocol-buffer#proto_library) rules.
 
 Example:
 
@@ -121,7 +121,7 @@ proto_library(
 | Attributes | |
 | --- | --- |
 | `name` | [Name](/versions/8.3.1/concepts/labels#target-names); required  A unique name for this target. |
-| `deps` | List of [labels](/versions/8.3.1/concepts/labels); default is `[]` The list of [`proto_library`](protocol-buffer#proto_library) rules to generate Java code for. |
+| `deps` | List of [labels](/versions/8.3.1/concepts/labels); default is `[]` The list of [`proto_library`](/versions/8.3.1/reference/be/protocol-buffer#proto_library) rules to generate Java code for. |
 
 ## proto\_library
 
diff --git a/versions/8.3.1/reference/be/python.mdx b/versions/8.3.1/reference/be/python.mdx
index 8b13c358..c52a9eaf 100644
--- a/versions/8.3.1/reference/be/python.mdx
+++ b/versions/8.3.1/reference/be/python.mdx
@@ -22,13 +22,13 @@ py_binary(name, deps, srcs, data, args, compatible_with, deprecation, distribs,
 | Attributes | |
 | --- | --- |
 | `name` | [Name](/versions/8.3.1/concepts/labels#target-names); required  A unique name for this target. |
-| `deps` | List of [labels](/versions/8.3.1/concepts/labels); default is `[]` List of additional libraries to be linked in to the target. See comments about the [`deps` attribute typically defined by rules](https://bazel.build/reference/be/common-definitions#typical-attributes). These are typically `py\_library` rules. Targets that only provide data files used at runtime belong in the `data` attribute. |
+| `deps` | List of [labels](/versions/8.3.1/concepts/labels); default is `[]` List of additional libraries to be linked in to the target. See comments about the [`deps` attribute typically defined by rules](https://bazel.build/versions/8.3.1/reference/be/common-definitions#typical-attributes). These are typically `py\_library` rules. Targets that only provide data files used at runtime belong in the `data` attribute. |
 | `srcs` | List of [labels](/versions/8.3.1/concepts/labels); required The list of Python source files that are processed to create the target. This includes all your checked-in code and may include generated source files. The `.py` files belong in `srcs` and library targets belong in `deps`. Other binary files that may be needed at run time belong in `data`. |
-| `data` | List of [labels](/versions/8.3.1/concepts/labels); default is `[]` The list of files need by this library at runtime. See comments about the [`data` attribute typically defined by rules](https://bazel.build/reference/be/common-definitions#typical-attributes). There is no `py\_embed\_data` like there is `cc\_embed\_data` and `go\_embed\_data`. This is because Python has a concept of runtime resources. |
+| `data` | List of [labels](/versions/8.3.1/concepts/labels); default is `[]` The list of files need by this library at runtime. See comments about the [`data` attribute typically defined by rules](https://bazel.build/versions/8.3.1/reference/be/common-definitions#typical-attributes). There is no `py\_embed\_data` like there is `cc\_embed\_data` and `go\_embed\_data`. This is because Python has a concept of runtime resources. |
 | `imports` | List of strings; default is `[]` List of import directories to be added to the PYTHONPATH. Subject to "Make variable" substitution. These import directories will be added for this rule and all rules that depend on it (note: not the rules this rule depends on. Each directory will be added to `PYTHONPATH` by `py\_binary` rules that depend on this rule. The strings are repo-runfiles-root relative, Absolute paths (paths that start with `/`) and paths that references a path above the execution root are not allowed and will result in an error. |
 | `legacy_create_init` | Integer; default is `-1` Whether to implicitly create empty `\_\_init\_\_.py` files in the runfiles tree. These are created in every directory containing Python source code or shared libraries, and every parent directory of those directories, excluding the repo root directory. The default, `-1` (auto), means true unless `--incompatible\_default\_to\_explicit\_init\_py` is used. If false, the user is responsible for creating (possibly empty) `\_\_init\_\_.py` files and adding them to the `srcs` of Python targets as required. |
 | `main` | [Label](/versions/8.3.1/concepts/labels); default is `None` Optional; the name of the source file that is the main entry point of the application. This file must also be listed in `srcs`. If left unspecified, `name`, with `.py` appended, is used instead. If `name` does not match any filename in `srcs`, `main` must be specified. |
-| `precompile` | String; default is `"inherit"` Whether py source files \*\*for this target\*\* should be precompiled. Values: \* `inherit`: Allow the downstream binary decide if precompiled files are used. \* `enabled`: Compile Python source files at build time. \* `disabled`: Don't compile Python source files at build time. :::{seealso} \* The {flag}`--precompile` flag, which can override this attribute in some cases and will affect all targets when building. \* The {obj}`pyc\_collection` attribute for transitively enabling precompiling on a per-target basis. \* The [Precompiling](precompiling) docs for a guide about using precompiling. ::: |
+| `precompile` | String; default is `"inherit"` Whether py source files \*\*for this target\*\* should be precompiled. Values: \* `inherit`: Allow the downstream binary decide if precompiled files are used. \* `enabled`: Compile Python source files at build time. \* `disabled`: Don't compile Python source files at build time. :::{seealso} \* The {flag}`--precompile` flag, which can override this attribute in some cases and will affect all targets when building. \* The {obj}`pyc\_collection` attribute for transitively enabling precompiling on a per-target basis. \* The [Precompiling](/versions/8.3.1/reference/be/precompiling) docs for a guide about using precompiling. ::: |
 | `precompile_invalidation_mode` | String; default is `"auto"` How precompiled files should be verified to be up-to-date with their associated source files. Possible values are: \* `auto`: The effective value will be automatically determined by other build settings. \* `checked\_hash`: Use the pyc file if the hash of the source file matches the hash recorded in the pyc file. This is most useful when working with code that you may modify. \* `unchecked\_hash`: Always use the pyc file; don't check the pyc's hash against the source file. This is most useful when the code won't be modified. For more information on pyc invalidation modes, see https://docs.python.org/3/library/py\_compile.html#py\_compile.PycInvalidationMode |
 | `precompile_optimize_level` | Integer; default is `0` The optimization level for precompiled files. For more information about optimization levels, see the `compile()` function's `optimize` arg docs at https://docs.python.org/3/library/functions.html#compile NOTE: The value `-1` means "current interpreter", which will be the interpreter used \_at build time when pycs are generated\_, not the interpreter used at runtime when the code actually runs. |
 | `precompile_source_retention` | String; default is `"inherit"` Determines, when a source file is compiled, if the source file is kept in the resulting output or not. Valid values are: \* `inherit`: Inherit the value from the {flag}`--precompile\_source\_retention` flag. \* `keep\_source`: Include the original Python source. \* `omit\_source`: Don't include the original py source. |
@@ -61,11 +61,11 @@ Source files are no longer added to the runfiles directly.
 | Attributes | |
 | --- | --- |
 | `name` | [Name](/versions/8.3.1/concepts/labels#target-names); required  A unique name for this target. |
-| `deps` | List of [labels](/versions/8.3.1/concepts/labels); default is `[]` List of additional libraries to be linked in to the target. See comments about the [`deps` attribute typically defined by rules](https://bazel.build/reference/be/common-definitions#typical-attributes). These are typically `py\_library` rules. Targets that only provide data files used at runtime belong in the `data` attribute. |
+| `deps` | List of [labels](/versions/8.3.1/concepts/labels); default is `[]` List of additional libraries to be linked in to the target. See comments about the [`deps` attribute typically defined by rules](https://bazel.build/versions/8.3.1/reference/be/common-definitions#typical-attributes). These are typically `py\_library` rules. Targets that only provide data files used at runtime belong in the `data` attribute. |
 | `srcs` | List of [labels](/versions/8.3.1/concepts/labels); default is `[]` The list of Python source files that are processed to create the target. This includes all your checked-in code and may include generated source files. The `.py` files belong in `srcs` and library targets belong in `deps`. Other binary files that may be needed at run time belong in `data`. |
-| `data` | List of [labels](/versions/8.3.1/concepts/labels); default is `[]` The list of files need by this library at runtime. See comments about the [`data` attribute typically defined by rules](https://bazel.build/reference/be/common-definitions#typical-attributes). There is no `py\_embed\_data` like there is `cc\_embed\_data` and `go\_embed\_data`. This is because Python has a concept of runtime resources. |
+| `data` | List of [labels](/versions/8.3.1/concepts/labels); default is `[]` The list of files need by this library at runtime. See comments about the [`data` attribute typically defined by rules](https://bazel.build/versions/8.3.1/reference/be/common-definitions#typical-attributes). There is no `py\_embed\_data` like there is `cc\_embed\_data` and `go\_embed\_data`. This is because Python has a concept of runtime resources. |
 | `imports` | List of strings; default is `[]` List of import directories to be added to the PYTHONPATH. Subject to "Make variable" substitution. These import directories will be added for this rule and all rules that depend on it (note: not the rules this rule depends on. Each directory will be added to `PYTHONPATH` by `py\_binary` rules that depend on this rule. The strings are repo-runfiles-root relative, Absolute paths (paths that start with `/`) and paths that references a path above the execution root are not allowed and will result in an error. |
-| `precompile` | String; default is `"inherit"` Whether py source files \*\*for this target\*\* should be precompiled. Values: \* `inherit`: Allow the downstream binary decide if precompiled files are used. \* `enabled`: Compile Python source files at build time. \* `disabled`: Don't compile Python source files at build time. :::{seealso} \* The {flag}`--precompile` flag, which can override this attribute in some cases and will affect all targets when building. \* The {obj}`pyc\_collection` attribute for transitively enabling precompiling on a per-target basis. \* The [Precompiling](precompiling) docs for a guide about using precompiling. ::: |
+| `precompile` | String; default is `"inherit"` Whether py source files \*\*for this target\*\* should be precompiled. Values: \* `inherit`: Allow the downstream binary decide if precompiled files are used. \* `enabled`: Compile Python source files at build time. \* `disabled`: Don't compile Python source files at build time. :::{seealso} \* The {flag}`--precompile` flag, which can override this attribute in some cases and will affect all targets when building. \* The {obj}`pyc\_collection` attribute for transitively enabling precompiling on a per-target basis. \* The [Precompiling](/versions/8.3.1/reference/be/precompiling) docs for a guide about using precompiling. ::: |
 | `precompile_invalidation_mode` | String; default is `"auto"` How precompiled files should be verified to be up-to-date with their associated source files. Possible values are: \* `auto`: The effective value will be automatically determined by other build settings. \* `checked\_hash`: Use the pyc file if the hash of the source file matches the hash recorded in the pyc file. This is most useful when working with code that you may modify. \* `unchecked\_hash`: Always use the pyc file; don't check the pyc's hash against the source file. This is most useful when the code won't be modified. For more information on pyc invalidation modes, see https://docs.python.org/3/library/py\_compile.html#py\_compile.PycInvalidationMode |
 | `precompile_optimize_level` | Integer; default is `0` The optimization level for precompiled files. For more information about optimization levels, see the `compile()` function's `optimize` arg docs at https://docs.python.org/3/library/functions.html#compile NOTE: The value `-1` means "current interpreter", which will be the interpreter used \_at build time when pycs are generated\_, not the interpreter used at runtime when the code actually runs. |
 | `precompile_source_retention` | String; default is `"inherit"` Determines, when a source file is compiled, if the source file is kept in the resulting output or not. Valid values are: \* `inherit`: Inherit the value from the {flag}`--precompile\_source\_retention` flag. \* `keep\_source`: Include the original Python source. \* `omit\_source`: Don't include the original py source. |
@@ -84,13 +84,13 @@ py_test(name, deps, srcs, data, args, compatible_with, deprecation, distribs, en
 | Attributes | |
 | --- | --- |
 | `name` | [Name](/versions/8.3.1/concepts/labels#target-names); required  A unique name for this target. |
-| `deps` | List of [labels](/versions/8.3.1/concepts/labels); default is `[]` List of additional libraries to be linked in to the target. See comments about the [`deps` attribute typically defined by rules](https://bazel.build/reference/be/common-definitions#typical-attributes). These are typically `py\_library` rules. Targets that only provide data files used at runtime belong in the `data` attribute. |
+| `deps` | List of [labels](/versions/8.3.1/concepts/labels); default is `[]` List of additional libraries to be linked in to the target. See comments about the [`deps` attribute typically defined by rules](https://bazel.build/versions/8.3.1/reference/be/common-definitions#typical-attributes). These are typically `py\_library` rules. Targets that only provide data files used at runtime belong in the `data` attribute. |
 | `srcs` | List of [labels](/versions/8.3.1/concepts/labels); required The list of Python source files that are processed to create the target. This includes all your checked-in code and may include generated source files. The `.py` files belong in `srcs` and library targets belong in `deps`. Other binary files that may be needed at run time belong in `data`. |
-| `data` | List of [labels](/versions/8.3.1/concepts/labels); default is `[]` The list of files need by this library at runtime. See comments about the [`data` attribute typically defined by rules](https://bazel.build/reference/be/common-definitions#typical-attributes). There is no `py\_embed\_data` like there is `cc\_embed\_data` and `go\_embed\_data`. This is because Python has a concept of runtime resources. |
+| `data` | List of [labels](/versions/8.3.1/concepts/labels); default is `[]` The list of files need by this library at runtime. See comments about the [`data` attribute typically defined by rules](https://bazel.build/versions/8.3.1/reference/be/common-definitions#typical-attributes). There is no `py\_embed\_data` like there is `cc\_embed\_data` and `go\_embed\_data`. This is because Python has a concept of runtime resources. |
 | `imports` | List of strings; default is `[]` List of import directories to be added to the PYTHONPATH. Subject to "Make variable" substitution. These import directories will be added for this rule and all rules that depend on it (note: not the rules this rule depends on. Each directory will be added to `PYTHONPATH` by `py\_binary` rules that depend on this rule. The strings are repo-runfiles-root relative, Absolute paths (paths that start with `/`) and paths that references a path above the execution root are not allowed and will result in an error. |
 | `legacy_create_init` | Integer; default is `-1` Whether to implicitly create empty `\_\_init\_\_.py` files in the runfiles tree. These are created in every directory containing Python source code or shared libraries, and every parent directory of those directories, excluding the repo root directory. The default, `-1` (auto), means true unless `--incompatible\_default\_to\_explicit\_init\_py` is used. If false, the user is responsible for creating (possibly empty) `\_\_init\_\_.py` files and adding them to the `srcs` of Python targets as required. |
 | `main` | [Label](/versions/8.3.1/concepts/labels); default is `None` Optional; the name of the source file that is the main entry point of the application. This file must also be listed in `srcs`. If left unspecified, `name`, with `.py` appended, is used instead. If `name` does not match any filename in `srcs`, `main` must be specified. |
-| `precompile` | String; default is `"inherit"` Whether py source files \*\*for this target\*\* should be precompiled. Values: \* `inherit`: Allow the downstream binary decide if precompiled files are used. \* `enabled`: Compile Python source files at build time. \* `disabled`: Don't compile Python source files at build time. :::{seealso} \* The {flag}`--precompile` flag, which can override this attribute in some cases and will affect all targets when building. \* The {obj}`pyc\_collection` attribute for transitively enabling precompiling on a per-target basis. \* The [Precompiling](precompiling) docs for a guide about using precompiling. ::: |
+| `precompile` | String; default is `"inherit"` Whether py source files \*\*for this target\*\* should be precompiled. Values: \* `inherit`: Allow the downstream binary decide if precompiled files are used. \* `enabled`: Compile Python source files at build time. \* `disabled`: Don't compile Python source files at build time. :::{seealso} \* The {flag}`--precompile` flag, which can override this attribute in some cases and will affect all targets when building. \* The {obj}`pyc\_collection` attribute for transitively enabling precompiling on a per-target basis. \* The [Precompiling](/versions/8.3.1/reference/be/precompiling) docs for a guide about using precompiling. ::: |
 | `precompile_invalidation_mode` | String; default is `"auto"` How precompiled files should be verified to be up-to-date with their associated source files. Possible values are: \* `auto`: The effective value will be automatically determined by other build settings. \* `checked\_hash`: Use the pyc file if the hash of the source file matches the hash recorded in the pyc file. This is most useful when working with code that you may modify. \* `unchecked\_hash`: Always use the pyc file; don't check the pyc's hash against the source file. This is most useful when the code won't be modified. For more information on pyc invalidation modes, see https://docs.python.org/3/library/py\_compile.html#py\_compile.PycInvalidationMode |
 | `precompile_optimize_level` | Integer; default is `0` The optimization level for precompiled files. For more information about optimization levels, see the `compile()` function's `optimize` arg docs at https://docs.python.org/3/library/functions.html#compile NOTE: The value `-1` means "current interpreter", which will be the interpreter used \_at build time when pycs are generated\_, not the interpreter used at runtime when the code actually runs. |
 | `precompile_source_retention` | String; default is `"inherit"` Determines, when a source file is compiled, if the source file is kept in the resulting output or not. Valid values are: \* `inherit`: Inherit the value from the {flag}`--precompile\_source\_retention` flag. \* `keep\_source`: Include the original Python source. \* `omit\_source`: Don't include the original py source. |
diff --git a/versions/8.3.1/reference/be/workspace.mdx b/versions/8.3.1/reference/be/workspace.mdx
index e0318406..f4bf5dd6 100644
--- a/versions/8.3.1/reference/be/workspace.mdx
+++ b/versions/8.3.1/reference/be/workspace.mdx
@@ -25,8 +25,7 @@ bind(name, actual, compatible_with, deprecation, distribs, features, licenses, r
 
 *Warning: use of `bind()` is not recommended. See "[Consider removing bind](https://github.com/bazelbuild/bazel/issues/1952)" for a long
 discussion of its issues and alternatives. In particular, consider the use of
-[`repo_mapping`
-repository attributes](https://bazel.build/versions/8.3.1/rules/repository_rules#attributes).*
+[`repo_mapping` repository attributes](https://bazel.build/versions/8.3.1/rules/repository_rules#attributes).*
 
 *Warning: `select()` cannot be used in `bind()`. See the [Configurable Attributes FAQ](/versions/8.3.1/docs/configurable-attributes#bind-select) for
 details.*
@@ -114,8 +113,7 @@ local_repository(name, path, repo_mapping)
 ```
 
 Allows targets from a local directory to be bound. This means that the current repository can
-use targets defined in this other directory. See the [bind
-section](/versions/8.3.1/reference/be/workspace#bind_examples) for more details.
+use targets defined in this other directory. See the [bind section](/versions/8.3.1/reference/be/workspace#bind_examples) for more details.
 
 #### Examples
 
diff --git a/versions/8.3.1/reference/command-line-reference.mdx b/versions/8.3.1/reference/command-line-reference.mdx
index 771ff61e..10fecf91 100644
--- a/versions/8.3.1/reference/command-line-reference.mdx
+++ b/versions/8.3.1/reference/command-line-reference.mdx
@@ -517,7 +517,7 @@ This option affects semantics of the Starlark language or the build API accessib
     [`loading_and_analysis`](#effect_tag_LOADING_AND_ANALYSIS), [`experimental`](#metadata_tag_EXPERIMENTAL)
 
 `--[no]experimental_isolated_extension_usages` default: "false"
-:   If true, enables the isolate parameter in the use\_extension function.
+:   If true, enables the isolate parameter in the use\_extension function.
 
     Tags:
     [`loading_and_analysis`](#effect_tag_LOADING_AND_ANALYSIS)
diff --git a/versions/8.3.1/reference/glossary.mdx b/versions/8.3.1/reference/glossary.mdx
index c2f0c71e..6d789fed 100644
--- a/versions/8.3.1/reference/glossary.mdx
+++ b/versions/8.3.1/reference/glossary.mdx
@@ -21,8 +21,7 @@ An in-memory graph of [actions](#action) and the [artifacts](#artifact) that
 these actions read and generate. The graph might include artifacts that exist as
 source files (for example, in the file system) as well as generated
 intermediate/final artifacts that are not mentioned in `BUILD` files. Produced
-during the [analysis phase](#analysis-phase) and used during the [execution
-phase](#execution-phase).
+during the [analysis phase](#analysis-phase) and used during the [execution phase](#execution-phase).
 
 ### Action graph query (aquery) {#action-graph-query}
 A [query](#query-concept) tool that can query over build [actions](#action).
@@ -37,8 +36,7 @@ invalidate individual actions deterministically.
 
 ### Analysis phase {#analysis-phase}
 The second phase of a build. Processes the [target graph](#target-graph)
-specified in [`BUILD` files](#build-file) to produce an in-memory [action
-graph](#action-graph) that determines the order of actions to run during the
+specified in [`BUILD` files](#build-file) to produce an in-memory [action graph](#action-graph) that determines the order of actions to run during the
 [execution phase](#execution-phase). This is the phase in which rule
 implementations are evaluated.
 
@@ -81,8 +79,7 @@ target's source files, dependencies, and custom compiler options. The particular
 attributes available for a given target depend on its rule type.
 
 ### .bazelrc {#bazelrc}
-Bazel’s configuration file used to change the default values for [startup
-flags](#startup-flags) and [command flags](#command-flags), and to define common
+Bazel’s configuration file used to change the default values for [startup flags](#startup-flags) and [command flags](#command-flags), and to define common
 groups of options that can then be set together on the Bazel command line using
 a `--config` flag. Bazel can combine settings from multiple bazelrc files
 (systemwide, per-workspace, per-user, or from a custom location), and a
@@ -108,8 +105,7 @@ directory.
 
 ### .bzl File {#bzl-file}
 A file that defines rules, [macros](#macro), and constants written in
-[Starlark](#starlark). These can then be imported into [`BUILD`
-files](#build-file) using the `load()` function.
+[Starlark](#starlark). These can then be imported into [`BUILD` files](#build-file) using the `load()` function.
 
 {/* TODO: ### Build event protocol */}
 
@@ -117,8 +113,7 @@ files](#build-file) using the `load()` function.
 
 ### Build graph {#build-graph}
 The dependency graph that Bazel constructs and traverses to perform a build.
-Includes nodes like [targets](#target), [configured
-targets](#configured-target), [actions](#action), and [artifacts](#artifact). A
+Includes nodes like [targets](#target), [configured targets](#configured-target), [actions](#action), and [artifacts](#artifact). A
 build is considered complete when all [artifacts](#artifact) on which a set of
 requested targets depend are verified as up-to-date.
 
@@ -158,8 +153,7 @@ graphs and restart the [analysis phase](#analysis-phase).
 ### Configuration {#configuration}
 Information outside of [rule](#rule) definitions that impacts how rules generate
 [actions](#action). Every build has at least one configuration specifying the
-target platform, action environment variables, and command-line [build
-flags](#command-flags). [Transitions](#transition) may create additional
+target platform, action environment variables, and command-line [build flags](#command-flags). [Transitions](#transition) may create additional
 configurations, such as for host tools or cross-compilation.
 
 **See also:** [Configurations](/versions/8.3.1/extending/rules#configurations)
@@ -174,8 +168,7 @@ configuration of `//:c` because changing `--javacopt` unnecessarily breaks C++
 build cacheability.
 
 ### Configured query (cquery) {#configured-query}
-A [query](#query-concept) tool that queries over [configured
-targets](#configured-target) (after the [analysis phase](#analysis-phase)
+A [query](#query-concept) tool that queries over [configured targets](#configured-target) (after the [analysis phase](#analysis-phase)
 completes). This means `select()` and [build flags](#command-flags) (such as
 `--platforms`) are accurately reflected in the results.
 
@@ -191,8 +184,7 @@ build, it has two configured targets: `` and ``.
 ### Correctness {#correctness}
 A build is correct when its output faithfully reflects the state of its
 transitive inputs. To achieve correct builds, Bazel strives to be
-[hermetic](#hermeticity), reproducible, and making [build
-analysis](#analysis-phase) and [action execution](#execution-phase)
+[hermetic](#hermeticity), reproducible, and making [build analysis](#analysis-phase) and [action execution](#execution-phase)
 deterministic.
 
 ### Dependency {#dependency}
@@ -234,8 +226,7 @@ compilation). A dynamic execution strategy can provide the best possible
 incremental and clean build times.
 
 ### Execution phase {#execution-phase}
-The third phase of a build. Executes the [actions](#action) in the [action
-graph](#action-graph) created during the [analysis phase](#analysis-phase).
+The third phase of a build. Executes the [actions](#action) in the [action graph](#action-graph) created during the [analysis phase](#analysis-phase).
 These actions invoke executables (compilers, scripts) to read and write
 [artifacts](#artifact). *Spawn strategies* control how these actions are
 executed: locally, remotely, dynamically, sandboxed, docker, and so on.
@@ -285,8 +276,7 @@ syntax may be omitted.
 The first phase of a build where Bazel executes [`BUILD` files](#build-file) to
 create [packages](#package). [Macros](#macro) and certain functions like
 `glob()` are evaluated in this phase. Interleaved with the second phase of the
-build, the [analysis phase](#analysis-phase), to build up a [target
-graph](#target-graph).
+build, the [analysis phase](#analysis-phase), to build up a [target graph](#target-graph).
 
 ### Legacy macro {#legacy-macro}
 A flavor of [macro](#macro) which is declared as an ordinary
@@ -336,8 +326,7 @@ Module metadata is hosted in Bazel registries.
 
 ### Module Extension {#module-extension}
 A piece of logic that can be run to generate [repos](#repository) by reading
-inputs from across the [module](#module) dependency graph and invoking [repo
-rules](#repository-rule). Module extensions have capabilities similar to repo
+inputs from across the [module](#module) dependency graph and invoking [repo rules](#repository-rule). Module extensions have capabilities similar to repo
 rules, allowing them to access the internet, perform file I/O, and so on.
 
 **See also:** [Module extensions](/versions/8.3.1/external/extension)
@@ -350,8 +339,7 @@ example, `native.cc_library` or `native.java_library`). User-defined rules
 
 ### Output base {#output-base}
 A [workspace](#workspace)-specific directory to store Bazel output files. Used
-to separate outputs from the *workspace*'s source tree (the [main
-repo](#repository)). Located in the [output user root](#output-user-root).
+to separate outputs from the *workspace*'s source tree (the [main repo](#repository)). Located in the [output user root](#output-user-root).
 
 ### Output groups {#output-groups}
 A group of files that is expected to be built when Bazel finishes building a
@@ -406,8 +394,7 @@ query variants: [query](#query-command), [cquery](#configured-query), and
 [aquery](#action-graph-query).
 
 ### query (command) {#query-command}
-A [query](#query-concept) tool that operates over the build's post-[loading
-phase](#loading-phase) [target graph](#target-graph). This is relatively fast,
+A [query](#query-concept) tool that operates over the build's post-[loading phase](#loading-phase) [target graph](#target-graph). This is relatively fast,
 but can't analyze the effects of `select()`, [build flags](#command-flags),
 [artifacts](#artifact), or build [actions](#action).
 
@@ -425,8 +412,7 @@ repo; multiple such files can coexist in a directory.
 The *main repo* is the repo in which the current Bazel command is being run.
 
 *External repos* are defined by specifying [modules](#module) in `MODULE.bazel`
-files, or invoking [repo rules](#repository-rule) in [module
-extensions](#module-extension). They can be fetched on demand to a predetermined
+files, or invoking [repo rules](#repository-rule) in [module extensions](#module-extension). They can be fetched on demand to a predetermined
 "magical" location on disk.
 
 Each repo has a unique, constant *canonical* name, and potentially different
@@ -437,8 +423,7 @@ Each repo has a unique, constant *canonical* name, and potentially different
 ### Repository cache {#repo-cache}
 A shared content-addressable cache of files downloaded by Bazel for builds,
 shareable across [workspaces](#workspace). Enables offline builds after the
-initial download. Commonly used to cache files downloaded through [repository
-rules](#repository-rule) like `http_archive` and repository rule APIs like
+initial download. Commonly used to cache files downloaded through [repository rules](#repository-rule) like `http_archive` and repository rule APIs like
 `repository_ctx.download`. Files are cached only if their SHA-256 checksums are
 specified for the download.
 
@@ -472,8 +457,7 @@ Rules are instantiated to produce rule targets in the
 [loading phase](#loading-phase). In the [analysis phase](#analysis-phase) rule
 targets communicate information to their downstream dependencies in the form of
 [providers](#provider), and register [actions](#action) describing how to
-generate their output artifacts. These actions are run in the [execution
-phase](#execution-phase).
+generate their output artifacts. These actions are run in the [execution phase](#execution-phase).
 
 Note: Historically the term "rule" has been used to refer to a rule target.
 This usage was inherited from tools like Make, but causes confusion and should
@@ -517,8 +501,7 @@ support the stamp attribute.
 ### Starlark {#starlark}
 The extension language for writing [rules](/versions/8.3.1/extending/rules) and [macros](#macro). A
 restricted subset of Python (syntactically and grammatically) aimed for the
-purpose of configuration, and for better performance. Uses the [`.bzl`
-file](#bzl-file) extension. [`BUILD` files](#build-file) use an even more
+purpose of configuration, and for better performance. Uses the [`.bzl` file](#bzl-file) extension. [`BUILD` files](#build-file) use an even more
 restricted version of Starlark (such as no `def` function definitions), formerly
 known as Skylark.
 
@@ -549,8 +532,7 @@ An object that is defined in a [`BUILD` file](#build-file) and identified by a
 [label](#label). Targets represent the buildable units of a workspace from
 the perspective of the end user.
 
-A target that is declared by instantiating a [rule](#rule) is called a [rule
-target](#rule-target). Depending on the rule, these may be runnable (like
+A target that is declared by instantiating a [rule](#rule) is called a [rule target](#rule-target). Depending on the rule, these may be runnable (like
 `cc_binary`) or testable (like `cc_test`). Rule targets typically depend on
 other targets via their [attributes](#attribute) (such as `deps`); these
 dependencies form the basis of the [target graph](#target-graph).
@@ -561,14 +543,11 @@ within a `BUILD` file. As a special case, the `BUILD` file of any package is
 always considered a source file target in that package.
 
 Targets are discovered during the [loading phase](#loading-phase). During the
-[analysis phase](#analysis-phase), targets are associated with [build
-configurations](#configuration) to form [configured
-targets](#configured-target).
+[analysis phase](#analysis-phase), targets are associated with [build configurations](#configuration) to form [configured targets](#configured-target).
 
 ### Target graph {#target-graph}
 An in-memory graph of [targets](#target) and their dependencies. Produced during
-the [loading phase](#loading-phase) and used as an input to the [analysis
-phase](#analysis-phase).
+the [loading phase](#loading-phase) and used as an input to the [analysis phase](#analysis-phase).
 
 ### Target pattern {#target-pattern}
 A way to specify a group of [targets](#target) on the command line. Commonly
@@ -581,8 +560,7 @@ packages recursively from the root of the [workspace](#workspace).
 Rule [targets](#target) instantiated from test rules, and therefore contains a
 test executable. A return code of zero from the completion of the executable
 indicates test success. The exact contract between Bazel and tests (such as test
-environment variables, test result collection methods) is specified in the [Test
-Encyclopedia](/versions/8.3.1/reference/test-encyclopedia).
+environment variables, test result collection methods) is specified in the [Test Encyclopedia](/versions/8.3.1/reference/test-encyclopedia).
 
 ### Toolchain {#toolchain}
 A set of tools to build outputs for a language. Typically, a toolchain includes
@@ -596,8 +574,7 @@ A build [target](#target) is top-level if it’s requested on the Bazel command
 line. For example, if `//:foo` depends on `//:bar`, and `bazel build //:foo` is
 called, then for this build, `//:foo` is top-level, and `//:bar` isn’t
 top-level, although both targets will need to be built. An important difference
-between top-level and non-top-level targets is that [command
-flags](#command-flags) set on the Bazel command line (or via
+between top-level and non-top-level targets is that [command flags](#command-flags) set on the Bazel command line (or via
 [.bazelrc](#bazelrc)) will set the [configuration](#configuration) for top-level
 targets, but might be modified by a [transition](#transition) for non-top-level
 targets.
@@ -628,8 +605,7 @@ or `.bzl` file may load a given `.bzl` file. Without context, usually
 **See also:** [Visibility documentation](/versions/8.3.1/concepts/visibility)
 
 ### Workspace {#workspace}
-The environment shared by all Bazel commands run from the same [main
-repository](#repository).
+The environment shared by all Bazel commands run from the same [main repository](#repository).
 
 Note that historically the concepts of "repository" and "workspace" have been
 conflated; the term "workspace" has often been used to refer to the main
diff --git a/versions/8.3.1/release/backward-compatibility.mdx b/versions/8.3.1/release/backward-compatibility.mdx
index c739264f..bc2add9d 100644
--- a/versions/8.3.1/release/backward-compatibility.mdx
+++ b/versions/8.3.1/release/backward-compatibility.mdx
@@ -6,11 +6,9 @@ This page provides information about how to handle backward compatibility,
 including migrating from one release to another and how to communicate
 incompatible changes.
 
-Bazel is evolving. Minor versions released as part of an [LTS major
-version](/versions/8.3.1/release#bazel-versioning) are fully backward-compatible. New major LTS
+Bazel is evolving. Minor versions released as part of an [LTS major version](/versions/8.3.1/release#bazel-versioning) are fully backward-compatible. New major LTS
 releases may contain incompatible changes that require some migration effort.
-For more information about Bazel's release model, please check out the [Release
-Model](/versions/8.3.1/release) page.
+For more information about Bazel's release model, please check out the [Release Model](/versions/8.3.1/release) page.
 
 ## Summary {#summary}
 
@@ -59,8 +57,7 @@ available.
 ## Communicating incompatible changes {#communicating-incompatible-changes}
 
 The primary source of information about incompatible changes are GitHub issues
-marked with an ["incompatible-change"
-label](https://github.com/bazelbuild/bazel/issues?q=label%3Aincompatible-change).
+marked with an ["incompatible-change" label](https://github.com/bazelbuild/bazel/issues?q=label%3Aincompatible-change).
 
 For every incompatible change, the issue specifies the following:
 
diff --git a/versions/8.3.1/release/index.mdx b/versions/8.3.1/release/index.mdx
index 6f63d765..f631b477 100644
--- a/versions/8.3.1/release/index.mdx
+++ b/versions/8.3.1/release/index.mdx
@@ -2,8 +2,7 @@
 title: 'Release Model'
 ---
 
-As announced in [the original blog
-post](https://blog.bazel.build/2020/11/10/long-term-support-release.html), Bazel
+As announced in [the original blog post](https://blog.bazel.build/2020/11/10/long-term-support-release.html), Bazel
 4.0 and higher versions provides support for two release tracks: rolling
 releases and long term support (LTS) releases. This page covers the latest
 information about Bazel's release model.
@@ -19,8 +18,7 @@ information about Bazel's release model.
 | Bazel 5 | Maintenance | [5.4.1](https://github.com/bazelbuild/bazel/releases/tag/5.4.1) | Jan 2025 |
 | Bazel 4 | Deprecated | [4.2.4](https://github.com/bazelbuild/bazel/releases/tag/4.2.4) | Jan 2024 |
 
-All Bazel LTS releases can be found on the [release
-page](https://github.com/bazelbuild/bazel/releases) on GitHub.
+All Bazel LTS releases can be found on the [release page](https://github.com/bazelbuild/bazel/releases) on GitHub.
 
 Note: Bazel version older than Bazel 5 are no longer supported, Bazel users are
 recommended to upgrade to the latest LTS release or use rolling releases if you
@@ -28,8 +26,7 @@ want to keep up with the latest changes at HEAD.
 
 ## Release versioning {#bazel-versioning}
 
-Bazel uses a _major.minor.patch_ [Semantic
-Versioning](https://semver.org/) scheme.
+Bazel uses a _major.minor.patch_ [Semantic Versioning](https://semver.org/) scheme.
 
 *   A _major release_ contains features that are not backward compatible with
     the previous release. Each major Bazel version is an LTS release.
@@ -72,8 +69,7 @@ Bazel regularly publish releases for two release tracks.
     release.
 *   Rolling releases can ship incompatible changes. Incompatible flags are
     recommended for major breaking changes, rolling out incompatible changes
-    should follow our [backward compatibility
-    policy](/versions/8.3.1/release/backward-compatibility).
+    should follow our [backward compatibility policy](/versions/8.3.1/release/backward-compatibility).
 
 ### LTS releases {#lts-releases}
 
@@ -89,8 +85,7 @@ Bazel regularly publish releases for two release tracks.
 *   A Bazel LTS release enters the Deprecated stage after being in ​​the
     Maintenance stage for 2 years.
 
-For planned releases, please check our [release
-issues](https://github.com/bazelbuild/bazel/issues?q=is%3Aopen+is%3Aissue+label%3Arelease)
+For planned releases, please check our [release issues](https://github.com/bazelbuild/bazel/issues?q=is%3Aopen+is%3Aissue+label%3Arelease)
 on Github.
 
 ## Release procedure & policies {#release-procedure-policies}
@@ -153,8 +148,7 @@ For LTS releases, the procedure and policies below are followed:
 1.  Identify release blockers and fix issues found on the release branch.
     *   The release branch is tested with the same test suite in
         [postsubmit](https://buildkite.com/bazel/bazel-bazel) and
-        [downstream test pipeline]
-        (https://buildkite.com/bazel/bazel-at-head-plus-downstream)
+        [downstream test pipeline](https://buildkite.com/bazel/bazel-at-head-plus-downstream)
         on Bazel CI. The Bazel team monitors testing results of the release
         branch and fixes any regressions found.
 1.  Create a new release candidate from the release branch when all known
@@ -210,5 +204,4 @@ feature.
 ## Rule compatibility {#rule-compatibility}
 
 If you are a rule authors and want to maintain compatibility with different
-Bazel versions, please check out the [Rule
-Compatibility](/versions/8.3.1/release/rule-compatibility) page.
+Bazel versions, please check out the [Rule Compatibility](/versions/8.3.1/release/rule-compatibility) page.
diff --git a/versions/8.3.1/release/rule-compatibility.mdx b/versions/8.3.1/release/rule-compatibility.mdx
index 0413d259..6fa841cb 100644
--- a/versions/8.3.1/release/rule-compatibility.mdx
+++ b/versions/8.3.1/release/rule-compatibility.mdx
@@ -53,18 +53,15 @@ Bazel LTS release.
 As Bazel rules authors, you can ensure a manageable migration process for users
 by following these best practices:
 
-1.  The rule should follow [Semantic
-    Versioning](https://semver.org/): minor versions of the same
+1.  The rule should follow [Semantic Versioning](https://semver.org/): minor versions of the same
     major version are backward compatible.
 1.  The rule at HEAD should be compatible with the latest Bazel LTS release.
 1.  The rule at HEAD should be compatible with Bazel at HEAD. To achieve this,
     you can
     *   Set up your own CI testing with Bazel at HEAD
-    *   Add your project to [Bazel downstream
-        testing](https://github.com/bazelbuild/continuous-integration/blob/master/docs/downstream-testing.md);
+    *   Add your project to [Bazel downstream testing](https://github.com/bazelbuild/continuous-integration/blob/master/docs/downstream-testing.md);
         the Bazel team files issues to your project if breaking changes in Bazel
-        affect your project, and you must follow our [downstream project
-        policies](https://github.com/bazelbuild/continuous-integration/blob/master/docs/downstream-testing.md#downstream-project-policies)
+        affect your project, and you must follow our [downstream project policies](https://github.com/bazelbuild/continuous-integration/blob/master/docs/downstream-testing.md#downstream-project-policies)
         to address issues timely.
 1.  The latest major version of the rule must be compatible with the latest
     Bazel LTS release.
diff --git a/versions/8.3.1/remote/bep-glossary.mdx b/versions/8.3.1/remote/bep-glossary.mdx
index fee36d59..ac947d21 100644
--- a/versions/8.3.1/remote/bep-glossary.mdx
+++ b/versions/8.3.1/remote/bep-glossary.mdx
@@ -36,7 +36,7 @@ BEP contains an event like the following:
 ## ActionExecuted {#actionexecuted}
 
 Provides details about the execution of a specific
-[Action](/versions/8.3.1/rules/lib/actions) in a build. By default, this event is
+[Action](/versions/8.3.1/rules/lib/builtins/actions) in a build. By default, this event is
 included in the BEP only for failed actions, to support identifying the root cause
 of build failures. Users may set the `--build_event_publish_all_actions` flag
 to include all `ActionExecuted` events.
@@ -410,5 +410,4 @@ workspace, such as the execution root.
 
 ## WorkspaceStatus {#workspacestatus}
 
-A single `WorkspaceStatus` event contains the result of the [workspace status
-command](/versions/8.3.1/docs/user-manual#workspace-status).
+A single `WorkspaceStatus` event contains the result of the [workspace status command](/versions/8.3.1/docs/user-manual#workspace-status).
diff --git a/versions/8.3.1/remote/bep.mdx b/versions/8.3.1/remote/bep.mdx
index 89921412..b87cb89c 100644
--- a/versions/8.3.1/remote/bep.mdx
+++ b/versions/8.3.1/remote/bep.mdx
@@ -2,14 +2,12 @@
 title: 'Build Event Protocol'
 ---
 
-The [Build Event
-Protocol](https://github.com/bazelbuild/bazel/blob/master/src/main/java/com/google/devtools/build/lib/buildeventstream/proto/build_event_stream.proto)
+The [Build Event Protocol](https://github.com/bazelbuild/bazel/blob/master/src/main/java/com/google/devtools/build/lib/buildeventstream/proto/build_event_stream.proto)
 (BEP) allows third-party programs to gain insight into a Bazel invocation. For
 example, you could use the BEP to gather information for an IDE
 plugin or a dashboard that displays build results.
 
-The protocol is a set of [protocol
-buffer](https://developers.google.com/protocol-buffers/) messages with some
+The protocol is a set of [protocol buffer](https://developers.google.com/protocol-buffers/) messages with some
 semantics defined on top of it. It includes information about build and test
 results, build progress, the build configuration and much more. The BEP is
 intended to be consumed programmatically and makes parsing Bazel’s
@@ -20,16 +18,13 @@ build event is a protocol buffer message consisting of a build event identifier,
 a set of child event identifiers, and a payload.
 
 *  __Build Event Identifier:__ Depending on the kind of build event, it might be
-an [opaque
-string](https://github.com/bazelbuild/bazel/blob/7.1.0/src/main/java/com/google/devtools/build/lib/buildeventstream/proto/build_event_stream.proto#L131-L140)
-or [structured
-information](https://github.com/bazelbuild/bazel/blob/7.1.0/src/main/java/com/google/devtools/build/lib/buildeventstream/proto/build_event_stream.proto#L194-L205)
+an [opaque string](https://github.com/bazelbuild/bazel/blob/7.1.0/src/main/java/com/google/devtools/build/lib/buildeventstream/proto/build_event_stream.proto#L131-L140)
+or [structured information](https://github.com/bazelbuild/bazel/blob/7.1.0/src/main/java/com/google/devtools/build/lib/buildeventstream/proto/build_event_stream.proto#L194-L205)
 revealing more about the build event. A build event identifier is unique within
 a build.
 
 *  __Children:__ A build event may announce other build events, by including
-their build event identifiers in its [children
-field](https://github.com/bazelbuild/bazel/blob/7.1.0/src/main/java/com/google/devtools/build/lib/buildeventstream/proto/build_event_stream.proto#L1276).
+their build event identifiers in its [children field](https://github.com/bazelbuild/bazel/blob/7.1.0/src/main/java/com/google/devtools/build/lib/buildeventstream/proto/build_event_stream.proto#L1276).
 For example, the `PatternExpanded` build event announces the targets it expands
 to as children. The protocol guarantees that all events, except for the first
 event, are announced by a previous event.
@@ -91,8 +86,7 @@ human-readable formats, such as text and JSON:
 
 ## Build Event Service {#build-event-service}
 
-The [Build Event
-Service](https://github.com/googleapis/googleapis/blob/master/google/devtools/build/v1/publish_build_event.proto)
+The [Build Event Service](https://github.com/googleapis/googleapis/blob/master/google/devtools/build/v1/publish_build_event.proto)
 Protocol is a generic [gRPC](https://www.grpc.io) service for publishing build events. The Build Event
 Service protocol is independent of the BEP and treats BEP events as opaque bytes.
 Bazel ships with a gRPC client implementation of the Build Event Service protocol that
@@ -136,8 +130,7 @@ For a description of each of these flags, see the
 The BEP typically contains many references to log files (test.log, test.xml,
 etc. ) stored on the machine where Bazel is running. A remote BES server
 typically can't access these files as they are on different machines. A way to
-work around this issue is to use Bazel with [remote
-caching](/versions/8.3.1/remote/caching).
+work around this issue is to use Bazel with [remote caching](/versions/8.3.1/remote/caching).
 Bazel will upload all output files to the remote cache (including files
 referenced in the BEP) and the BES server can then fetch the referenced files
 from the cache.
diff --git a/versions/8.3.1/remote/cache-local.mdx b/versions/8.3.1/remote/cache-local.mdx
index 29538cea..4684f35f 100644
--- a/versions/8.3.1/remote/cache-local.mdx
+++ b/versions/8.3.1/remote/cache-local.mdx
@@ -18,8 +18,7 @@ execution. However, local execution presents some additional challenges.
 ## Checking your cache hit rate {#cache-hits}
 
 Successful remote cache hits will show up in the status line, similar to
-[Cache Hits rate with Remote
-Execution](/versions/8.3.1/remote/cache-remote#check-cache-hits).
+[Cache Hits rate with Remote Execution](/versions/8.3.1/remote/cache-remote#check-cache-hits).
 
 In the standard output of your Bazel run, you will see something like the
 following:
@@ -66,8 +65,7 @@ the steps in this section.
    message you see does not give you enough information, try adding
    `--verbose_failures`.
 
-2. Follow the steps from [Troubleshooting cache hits for remote
-   execution](/versions/8.3.1/remote/cache-remote#troubleshooting_cache_hits) to
+2. Follow the steps from [Troubleshooting cache hits for remote execution](/versions/8.3.1/remote/cache-remote#troubleshooting_cache_hits) to
    ensure that your cache-writing Bazel invocations are able to get cache hits
    on the same machine and across machines.
 
@@ -81,7 +79,6 @@ the steps in this section.
    b. Ensure your cache-reading Bazel invocations build the same targets as the
       cache-writing Bazel invocations.
 
-   c. Follow the same steps as to [ensure caching across
-      machines](/versions/8.3.1/remote/cache-remote#caching-across-machines),
+   c. Follow the same steps as to [ensure caching across machines](/versions/8.3.1/remote/cache-remote#caching-across-machines),
       to ensure caching from your cache-writing Bazel invocation to your
       cache-reading Bazel invocation.
diff --git a/versions/8.3.1/remote/caching.mdx b/versions/8.3.1/remote/caching.mdx
index 6141c102..c43522fe 100644
--- a/versions/8.3.1/remote/caching.mdx
+++ b/versions/8.3.1/remote/caching.mdx
@@ -126,7 +126,7 @@ not provide technical support for bazel-remote.
 
 This cache stores contents on disk and also provides garbage collection
 to enforce an upper storage limit and clean unused artifacts. The cache is
-available as a [docker image] and its code is available on
+available as a [docker image](https://hub.docker.com/r/buchgr/bazel-remote-cache/) and its code is available on
 [GitHub](https://github.com/buchgr/bazel-remote/).
 Both the REST and gRPC remote cache APIs are supported.
 
@@ -308,8 +308,7 @@ or for the age of individual cache entries. Bazel will automatically garbage
 collect the disk cache while idling between builds; the idle timer can be set
 with `--experimental_disk_cache_gc_idle_delay` (defaulting to 5 minutes).
 
-As an alternative to automatic garbage collection, we also provide a [tool](
-https://github.com/bazelbuild/bazel/tree/master/src/tools/diskcache) to run a
+As an alternative to automatic garbage collection, we also provide a [tool](https://github.com/bazelbuild/bazel/tree/master/src/tools/diskcache) to run a
 garbage collection on demand.
 
 ## Known issues {#known-issues}
diff --git a/versions/8.3.1/remote/dynamic.mdx b/versions/8.3.1/remote/dynamic.mdx
index 851555d0..f2564efe 100644
--- a/versions/8.3.1/remote/dynamic.mdx
+++ b/versions/8.3.1/remote/dynamic.mdx
@@ -12,8 +12,7 @@ alike.
 This page describes how to enable, tune, and debug dynamic execution. If you
 have both local and remote execution set up and are trying to adjust Bazel
 settings for better performance, this page is for you. If you don't already have
-remote execution set up, go to the Bazel [Remote Execution
-Overview](/versions/8.3.1/remote/rbe) first.
+remote execution set up, go to the Bazel [Remote Execution Overview](/versions/8.3.1/remote/rbe) first.
 
 ## Enabling dynamic execution? {#enabling-dynamic-execution}
 
@@ -44,14 +43,12 @@ are likely. The default value is 1000ms, but should be tuned to being just a bit
 longer than cache hits usually take. The actual time depends both on the remote
 system and on how long a round-trip takes. Usually, the value will be the same
 for all users of a given remote system, unless some of them are far enough away
-to add roundtrip latency. You can use the [Bazel profiling
-features](/versions/8.3.1/rules/performance#performance-profiling) to look at how long typical
+to add roundtrip latency. You can use the [Bazel profiling features](/versions/8.3.1/rules/performance#performance-profiling) to look at how long typical
 cache hits take.
 
 Dynamic execution can be used with local sandboxed strategy as well as with
 [persistent workers](/versions/8.3.1/remote/persistent). Persistent workers will automatically
-run with sandboxing when used with dynamic execution, and cannot use [multiplex
-workers](/versions/8.3.1/remote/multiplex). On Darwin and Windows systems, the sandboxed
+run with sandboxing when used with dynamic execution, and cannot use [multiplex workers](/versions/8.3.1/remote/multiplex). On Darwin and Windows systems, the sandboxed
 strategy can be slow; you can pass `--reuse_sandbox_directories` to reduce
 overhead of creating sandboxes on these systems.
 
@@ -67,8 +64,7 @@ entire action fails. This is an intentional choice to prevent differences
 between local and remote execution from going unnoticed.
 
 For more background on how dynamic execution and its locking works, see Julio
-Merino's excellent [blog
-posts](https://jmmv.dev/series/bazel-dynamic-execution/)
+Merino's excellent [blog posts](https://jmmv.dev/series/bazel-dynamic-execution/)
 
 ## When should I use dynamic execution? {#when-to-use}
 
diff --git a/versions/8.3.1/remote/output-directories.mdx b/versions/8.3.1/remote/output-directories.mdx
index d2ce6f95..4d86053d 100644
--- a/versions/8.3.1/remote/output-directories.mdx
+++ b/versions/8.3.1/remote/output-directories.mdx
@@ -25,7 +25,7 @@ The solution that's currently implemented:
 
 * Bazel must be invoked from a directory containing a repo boundary file, or a
   subdirectory thereof. In other words, Bazel must be invoked from inside a
-  [repository](../external/overview#repository). Otherwise, an error is
+  [repository](/versions/8.3.1/external/overview#repository). Otherwise, an error is
   reported.
 * The _outputRoot_ directory defaults to `${XDG_CACHE_HOME}/bazel` (or
   `~/.cache/bazel`, if the `XDG_CACHE_HOME` environment variable is not set) on
diff --git a/versions/8.3.1/remote/persistent.mdx b/versions/8.3.1/remote/persistent.mdx
index 9e6a3ccb..04117a20 100644
--- a/versions/8.3.1/remote/persistent.mdx
+++ b/versions/8.3.1/remote/persistent.mdx
@@ -257,7 +257,6 @@ For more information on persistent workers, see:
 *   [Original persistent workers blog post](https://blog.bazel.build/2015/12/10/java-workers.html)
 *   [Haskell implementation description](https://www.tweag.io/blog/2019-09-25-bazel-ghc-persistent-worker-internship/)
 *   [Blog post by Mike Morearty](https://medium.com/@mmorearty/how-to-create-a-persistent-worker-for-bazel-7738bba2cabb)
-*   [Front End Development with Bazel: Angular/TypeScript and Persistent Workers
-    w/ Asana](https://www.youtube.com/watch?v=0pgERydGyqo)
+*   [Front End Development with Bazel: Angular/TypeScript and Persistent Workers w/ Asana](https://www.youtube.com/watch?v=0pgERydGyqo)
 *   [Bazel strategies explained](https://jmmv.dev/2019/12/bazel-strategies.html)
 *   [Informative worker strategy discussion on the bazel-discuss mailing list](https://groups.google.com/forum/#!msg/bazel-discuss/oAEnuhYOPm8/ol7hf4KWJgAJ)
diff --git a/versions/8.3.1/remote/rules.mdx b/versions/8.3.1/remote/rules.mdx
index 5c48f4f2..7a6f54c8 100644
--- a/versions/8.3.1/remote/rules.mdx
+++ b/versions/8.3.1/remote/rules.mdx
@@ -54,8 +54,7 @@ variables that may not be set to equivalent values (or at all) in the remote
 execution environment.
 
 Toolchain rules currently exist for Bazel build and test rules for
-[Scala](https://github.com/bazelbuild/rules_scala/blob/master/scala/scala_toolch
-ain.bzl),
+[Scala](https://github.com/bazelbuild/rules_scala/blob/master/scala/scala_toolch ain.bzl),
 [Rust](https://github.com/bazelbuild/rules_rust/blob/main/rust/toolchain.bzl),
 and [Go](https://github.com/bazelbuild/rules_go/blob/master/go/toolchains.rst),
 and new toolchain rules are under way for other languages and tools such as
diff --git a/versions/8.3.1/remote/workspace.mdx b/versions/8.3.1/remote/workspace.mdx
index f4b91d64..35589d74 100644
--- a/versions/8.3.1/remote/workspace.mdx
+++ b/versions/8.3.1/remote/workspace.mdx
@@ -11,8 +11,7 @@ on the host machine. If your workspace rules access information about the
 host machine for use during execution, your build is likely to break due to
 incompatibilities between the environments.
 
-As part of [adapting Bazel rules for remote
-execution](/versions/8.3.1/remote/rules), you need to find such workspace rules
+As part of [adapting Bazel rules for remote execution](/versions/8.3.1/remote/rules), you need to find such workspace rules
 and fix them. This page describes how to find potentially problematic workspace
 rules using the workspace log.
 
diff --git a/versions/8.3.1/rules/challenges.mdx b/versions/8.3.1/rules/challenges.mdx
index 4b777a14..90624327 100644
--- a/versions/8.3.1/rules/challenges.mdx
+++ b/versions/8.3.1/rules/challenges.mdx
@@ -208,7 +208,7 @@ Bazel is heavily affected by both of these scenarios, so we introduced a set of
 custom collection classes that effectively compress the information in memory by
 avoiding the copy at each step. Almost all of these data structures have set
 semantics, so we called it
-[depset](/versions/8.3.1/rules/lib/depset)
+[depset](/versions/8.3.1/rules/lib/builtins/depset)
 (also known as `NestedSet` in the internal implementation). The majority of
 changes to reduce Bazel's memory consumption over the past several years were
 changes to use depsets instead of whatever was previously used.
diff --git a/versions/8.3.1/rules/faq.mdx b/versions/8.3.1/rules/faq.mdx
index 73c31edb..7771a904 100644
--- a/versions/8.3.1/rules/faq.mdx
+++ b/versions/8.3.1/rules/faq.mdx
@@ -17,7 +17,7 @@ Bazel only executes the actions needed to produce the *requested* output files.
 
 * If you want the file to be built automatically whenever your target is
   mentioned on the command line, add it to your rule's default outputs by
-  returning a [`DefaultInfo`](lib/globals#DefaultInfo) provider.
+  returning a [`DefaultInfo`](/versions/8.3.1/rules/lib/globals#DefaultInfo) provider.
 
 See the [Rules page](/versions/8.3.1/extending/rules#requesting-output-files) for more information.
 
@@ -35,24 +35,24 @@ correct path.
 
 For actions, you declare inputs by passing them to the `ctx.actions.*` function
 that creates the action. The proper path for the file can be obtained using
-[`File.path`](lib/File#path).
+[`File.path`](/versions/8.3.1/rules/lib/builtins/File#path).
 
 For binaries (the executable outputs run by a `bazel run` or `bazel test`
 command), you declare inputs by including them in the
 [runfiles](/versions/8.3.1/extending/rules#runfiles). Instead of using the `path` field, use
-[`File.short_path`](lib/File#short_path), which is file's path relative to
+[`File.short_path`](/versions/8.3.1/rules/lib/builtins/File#short_path), which is file's path relative to
 the runfiles directory in which the binary executes.
 
 ## How can I control which files are built by `bazel build //pkg:mytarget`?
 
-Use the [`DefaultInfo`](lib/globals#DefaultInfo) provider to
+Use the [`DefaultInfo`](/versions/8.3.1/rules/lib/globals#DefaultInfo) provider to
 [set the default outputs](/versions/8.3.1/extending/rules#requesting-output-files).
 
 ## How can I run a program or do file I/O as part of my build?
 
 A tool can be declared as a target, just like any other part of your build, and
 run during the execution phase to help build other targets. To create an action
-that runs a tool, use [`ctx.actions.run`](lib/actions#run) and pass in the
+that runs a tool, use [`ctx.actions.run`](/versions/8.3.1/rules/lib/builtins/actions#run) and pass in the
 tool as the `executable` parameter.
 
 During the loading and analysis phases, a tool *cannot* run, nor can you perform
diff --git a/versions/8.3.1/rules/language.mdx b/versions/8.3.1/rules/language.mdx
index 9a860ffd..0050d2cf 100644
--- a/versions/8.3.1/rules/language.mdx
+++ b/versions/8.3.1/rules/language.mdx
@@ -34,19 +34,19 @@ Starlark's semantics can differ from Python, but behavioral differences are
 rare, except for cases where Starlark raises an error. The following Python
 types are supported:
 
-* [None](lib/globals#None)
-* [bool](lib/bool)
-* [dict](lib/dict)
-* [tuple](lib/tuple)
-* [function](lib/function)
-* [int](lib/int)
-* [list](lib/list)
-* [string](lib/string)
+* [None](/versions/8.3.1/rules/lib/globals#None)
+* [bool](/versions/8.3.1/rules/lib/core/bool)
+* [dict](/versions/8.3.1/rules/lib/core/dict)
+* [tuple](/versions/8.3.1/rules/lib/core/tuple)
+* [function](/versions/8.3.1/rules/lib/core/function)
+* [int](/versions/8.3.1/rules/lib/core/int)
+* [list](/versions/8.3.1/rules/lib/core/list)
+* [string](/versions/8.3.1/rules/lib/core/string)
 
 ## Mutability
 
 Starlark favors immutability. Two mutable data structures are available:
-[lists](lib/list) and [dicts](lib/dict). Changes to mutable
+[lists](/versions/8.3.1/rules/lib/core/list) and [dicts](/versions/8.3.1/rules/lib/core/dict). Changes to mutable
 data-structures, such as appending a value to a list or deleting an entry in a
 dictionary are valid only for objects created in the current context. After a
 context finishes, its values become immutable.
@@ -93,10 +93,8 @@ values returned by rules are immutable.
 `BUILD` files register targets via making calls to rules. `.bzl` files provide
 definitions for constants, rules, macros, and functions.
 
-[Native functions](/versions/8.3.1/reference/be/functions) and [native rules](
-/reference/be/overview#language-specific-native-rules) are global symbols in
-`BUILD` files. `bzl` files need to load them using the [`native` module](
-/rules/lib/toplevel/native).
+[Native functions](/versions/8.3.1/reference/be/functions) and [native rules](/versions/8.3.1/reference/be/overview#language-specific-native-rules) are global symbols in
+`BUILD` files. `bzl` files need to load them using the [`native` module](/versions/8.3.1/rules/lib/toplevel/native).
 
 There are two syntactic restrictions in `BUILD` files: 1) declaring functions is
 illegal, and 2) `*args` and `**kwargs` arguments are not allowed.
@@ -130,7 +128,7 @@ not defined across value types. In short: `5 < 'foo'` will throw an error and
   error: `{"a": 4, "b": 7, "a": 1}`.
 
 * Strings are represented with double-quotes (such as when you call
-  [repr](lib/globals#repr)).
+  [repr](/versions/8.3.1/rules/lib/globals#repr)).
 
 * Strings aren't iterable.
 
@@ -138,12 +136,12 @@ The following Python features are not supported:
 
 * implicit string concatenation (use explicit `+` operator).
 * Chained comparisons (such as `1 < x < 5`).
-* `class` (see [`struct`](lib/struct#struct) function).
+* `class` (see [`struct`](/versions/8.3.1/rules/lib/builtins/struct#struct) function).
 * `import` (see [`load`](/versions/8.3.1/extending/concepts#loading-an-extension) statement).
 * `while`, `yield`.
 * float and set types.
 * generators and generator expressions.
 * `is` (use `==` instead).
-* `try`, `raise`, `except`, `finally` (see [`fail`](lib/globals#fail) for fatal errors).
+* `try`, `raise`, `except`, `finally` (see [`fail`](/versions/8.3.1/rules/lib/globals#fail) for fatal errors).
 * `global`, `nonlocal`.
 * most builtin functions, most methods.
diff --git a/versions/8.3.1/rules/legacy-macro-tutorial.mdx b/versions/8.3.1/rules/legacy-macro-tutorial.mdx
index 9a729284..3f5c708d 100644
--- a/versions/8.3.1/rules/legacy-macro-tutorial.mdx
+++ b/versions/8.3.1/rules/legacy-macro-tutorial.mdx
@@ -3,9 +3,7 @@ title: 'Creating a Legacy Macro'
 ---
 
 IMPORTANT: This tutorial is for [*legacy macros*](/versions/8.3.1/extending/legacy-macros). If
-you only need to support Bazel 8 or newer, we recommend using [symbolic
-macros](/versions/8.3.1/extending/macros) instead; take a look at [Creating a Symbolic
-Macro](../macro-tutorial).
+you only need to support Bazel 8 or newer, we recommend using [symbolic macros](/versions/8.3.1/extending/macros) instead; take a look at [Creating a Symbolic Macro](/versions/8.3.1/rules/macro-tutorial).
 
 Imagine that you need to run a tool as part of your build. For example, you
 may want to generate or preprocess a source file, or compress a binary. In this
diff --git a/versions/8.3.1/rules/lib/builtins/Action.mdx b/versions/8.3.1/rules/lib/builtins/Action.mdx
index 0364d44c..f53310bb 100644
--- a/versions/8.3.1/rules/lib/builtins/Action.mdx
+++ b/versions/8.3.1/rules/lib/builtins/Action.mdx
@@ -4,7 +4,7 @@ title: 'Action'
 
 An action created during rule analysis.
 
-This object is visible for the purpose of testing, and may be obtained from an `Actions` provider. It is normally not necessary to access `Action` objects or their fields within a rule's implementation function. You may instead want to see the [Rules page](https://bazel.build/versions/8.3.1/extending/rules#actions) for a general discussion of how to use actions when defining custom rules, or the [API reference](../builtins/actions) for creating actions.
+This object is visible for the purpose of testing, and may be obtained from an `Actions` provider. It is normally not necessary to access `Action` objects or their fields within a rule's implementation function. You may instead want to see the [Rules page](https://bazel.build/versions/8.3.1/extending/rules#actions) for a general discussion of how to use actions when defining custom rules, or the [API reference](/versions/8.3.1/rules/lib/builtins/actions) for creating actions.
 
 Some fields of this object are only applicable for certain kinds of actions. Fields that are inapplicable are set to `None`.
 
@@ -25,7 +25,7 @@ Some fields of this object are only applicable for certain kinds of actions. Fie
 sequence Action.args
 ```
 
-A list of frozen [Args](../builtins/Args) objects containing information about the action arguments. These objects contain accurate argument information, including arguments involving expanded action output directories. However, [Args](../builtins/Args) objects are not readable in the analysis phase. For a less accurate account of arguments which is available in the analysis phase, see [argv](#argv).
+A list of frozen [Args](/versions/8.3.1/rules/lib/builtins/Args) objects containing information about the action arguments. These objects contain accurate argument information, including arguments involving expanded action output directories. However, [Args](/versions/8.3.1/rules/lib/builtins/Args) objects are not readable in the analysis phase. For a less accurate account of arguments which is available in the analysis phase, see [argv](#argv).
 
 Note that some types of actions do not yet support exposure of this field. For such action types, this is `None`.
 May return `None`.
@@ -36,7 +36,7 @@ May return `None`.
 sequence Action.argv
 ```
 
-For actions created by [ctx.actions.run()](../builtins/actions#run) or [ctx.actions.run\_shell()](../builtins/actions#run_shell) an immutable list of the arguments for the command line to be executed. Note that for shell actions the first two arguments will be the shell path and `"-c"`.
+For actions created by [ctx.actions.run()](/versions/8.3.1/rules/lib/builtins/actions#run) or [ctx.actions.run\_shell()](/versions/8.3.1/rules/lib/builtins/actions#run_shell) an immutable list of the arguments for the command line to be executed. Note that for shell actions the first two arguments will be the shell path and `"-c"`.
 May return `None`.
 
 ## content
@@ -45,7 +45,7 @@ May return `None`.
 string Action.content
 ```
 
-For actions created by [ctx.actions.write()](../builtins/actions#write) or [ctx.actions.expand\_template()](../builtins/actions#expand_template), the contents of the file to be written, if those contents can be computed during the analysis phase. The value is `None` if the contents cannot be determined until the execution phase, such as when a directory in an [Args](../builtins/Args) object needs to be expanded.
+For actions created by [ctx.actions.write()](/versions/8.3.1/rules/lib/builtins/actions#write) or [ctx.actions.expand\_template()](/versions/8.3.1/rules/lib/builtins/actions#expand_template), the contents of the file to be written, if those contents can be computed during the analysis phase. The value is `None` if the contents cannot be determined until the execution phase, such as when a directory in an [Args](/versions/8.3.1/rules/lib/builtins/Args) object needs to be expanded.
 May return `None`.
 
 ## env
@@ -86,5 +86,5 @@ A set of the output files of this action.
 dict Action.substitutions
 ```
 
-For actions created by [ctx.actions.expand\_template()](../builtins/actions#expand_template), an immutable dict holding the substitution mapping.
+For actions created by [ctx.actions.expand\_template()](/versions/8.3.1/rules/lib/builtins/actions#expand_template), an immutable dict holding the substitution mapping.
 May return `None`.
\ No newline at end of file
diff --git a/versions/8.3.1/rules/lib/builtins/Args.mdx b/versions/8.3.1/rules/lib/builtins/Args.mdx
index ec58501a..3363ab53 100644
--- a/versions/8.3.1/rules/lib/builtins/Args.mdx
+++ b/versions/8.3.1/rules/lib/builtins/Args.mdx
@@ -4,15 +4,15 @@ title: 'Args'
 
 An object that encapsulates, in a memory-efficient way, the data needed to build part or all of a command line.
 
-It often happens that an action requires a large command line containing values accumulated from transitive dependencies. For example, a linker command line might list every object file needed by all of the libraries being linked. It is best practice to store such transitive data in [`depset`](../builtins/depset)s, so that they can be shared by multiple targets. However, if the rule author had to convert these depsets into lists of strings in order to construct an action command line, it would defeat this memory-sharing optimization.
+It often happens that an action requires a large command line containing values accumulated from transitive dependencies. For example, a linker command line might list every object file needed by all of the libraries being linked. It is best practice to store such transitive data in [`depset`](/versions/8.3.1/rules/lib/builtins/depset)s, so that they can be shared by multiple targets. However, if the rule author had to convert these depsets into lists of strings in order to construct an action command line, it would defeat this memory-sharing optimization.
 
 For this reason, the action-constructing functions accept `Args` objects in addition to strings. Each `Args` object represents a concatenation of strings and depsets, with optional transformations for manipulating the data. `Args` objects do not process the depsets they encapsulate until the execution phase, when it comes time to calculate the command line. This helps defer any expensive copying until after the analysis phase is complete. See the [Optimizing Performance](https://bazel.build/versions/8.3.1/rules/performance) page for more information.
 
-`Args` are constructed by calling [`ctx.actions.args()`](../builtins/actions#args). They can be passed as the `arguments` parameter of [`ctx.actions.run()`](../builtins/actions#run) or [`ctx.actions.run_shell()`](../builtins/actions#run_shell). Each mutation of an `Args` object appends values to the eventual command line.
+`Args` are constructed by calling [`ctx.actions.args()`](/versions/8.3.1/rules/lib/builtins/actions#args). They can be passed as the `arguments` parameter of [`ctx.actions.run()`](/versions/8.3.1/rules/lib/builtins/actions#run) or [`ctx.actions.run_shell()`](/versions/8.3.1/rules/lib/builtins/actions#run_shell). Each mutation of an `Args` object appends values to the eventual command line.
 
 The `map_each` feature allows you to customize how items are transformed into strings. If you do not provide a `map_each` function, the standard conversion is as follows:
 
-* Values that are already strings are left as-is.* [`File`](../builtins/File) objects are turned into their `File.path` values.* [`Label`](../builtins/Label) objects are turned into a string representation that resolves back to the same object when resolved in the context of the main repository. If possible, the string representation uses the apparent name of a repository in favor of the repository's canonical name, which makes this representation suited for use in BUILD files. While the exact form of the representation is not guaranteed, typical examples are `//foo:bar`, `@repo//foo:bar` and `@@canonical_name+//foo:bar.bzl`.* All other types are turned into strings in an *unspecified* manner. For this reason, you should avoid passing values that are not of string or `File` type to `add()`, and if you pass them to `add_all()` or `add_joined()` then you should provide a `map_each` function.
+* Values that are already strings are left as-is.* [`File`](/versions/8.3.1/rules/lib/builtins/File) objects are turned into their `File.path` values.* [`Label`](/versions/8.3.1/rules/lib/builtins/Label) objects are turned into a string representation that resolves back to the same object when resolved in the context of the main repository. If possible, the string representation uses the apparent name of a repository in favor of the repository's canonical name, which makes this representation suited for use in BUILD files. While the exact form of the representation is not guaranteed, typical examples are `//foo:bar`, `@repo//foo:bar` and `@@canonical_name+//foo:bar.bzl`.* All other types are turned into strings in an *unspecified* manner. For this reason, you should avoid passing values that are not of string or `File` type to `add()`, and if you pass them to `add_all()` or `add_joined()` then you should provide a `map_each` function.
 
 When using string formatting (`format`, `format_each`, and `format_joined` params of the `add*()` methods), the format template is interpreted in the same way as `%`-substitution on strings, except that the template must have exactly one substitution placeholder and it must be `%s`. Literal percents may be escaped as `%%`. Formatting is applied after the value is converted to a string as per the above.
 
@@ -64,7 +64,7 @@ Appends an argument to this command line.
 | --- | --- |
 | `arg_name_or_value` | required  If two positional parameters are passed this is interpreted as the arg name. The arg name is added before the value without any processing. If only one positional parameter is passed, it is interpreted as `value` (see below). |
 | `value` | default is `unbound`  The object to append. It will be converted to a string using the standard conversion mentioned above. Since there is no `map_each` parameter for this function, `value` should be either a string or a `File`. A list, tuple, depset, or directory `File` must be passed to [`add_all()` or [`add_joined()`](#add_joined) instead of this method.](#add_all) |
-| `format` | [string](../core/string); or `None`; default is `None`  A format string pattern, to be applied to the stringified version of `value`. |
+| `format` | [string](/versions/8.3.1/rules/lib/core/string); or `None`; default is `None`  A format string pattern, to be applied to the stringified version of `value`. |
 
 ## add\_all
 
@@ -86,15 +86,15 @@ Note that empty strings are valid arguments that are subject to all these proces
 | Parameter | Description |
 | --- | --- |
 | `arg_name_or_values` | required  If two positional parameters are passed this is interpreted as the arg name. The arg name is added before the `values` as a separate argument without any processing. This arg name will not be added if `omit_if_empty` is true (the default) and no other items are appended (as happens if `values` is empty or all of its items are filtered). If only one positional parameter is passed, it is interpreted as `values` (see below). |
-| `values` | [sequence](../core/list); or [depset](../builtins/depset); default is `unbound`  The list, tuple, or depset whose items will be appended. |
-| `map_each` | callable; or `None`; default is `None`  A function that converts each item to zero or more strings, which may be further processed before appending. If this param is not provided, the standard conversion is used. The function is passed either one or two positional arguments: the item to convert, followed by an optional [`DirectoryExpander`](../builtins/DirectoryExpander). The second argument will be passed only if the supplied function is user-defined (not built-in) and declares more than one parameter. The return value's type depends on how many arguments are to be produced for the item:  * In the common case when each item turns into one string, the function should return that string.* If the item is to be filtered out entirely, the function should return `None`.* If the item turns into multiple strings, the function returns a list of those strings.  Returning a single string or `None` has the same effect as returning a list of length 1 or length 0 respectively. However, it is more efficient and readable to avoid creating a list where it is not needed. Ordinarily, items that are directories are automatically expanded to their contents when `expand_directories=True` is set. However, this will not expand directories contained inside other values -- for instance, when the items are structs that have directories as fields. In this situation, the `DirectoryExpander` argument can be applied to manually obtain the files of a given directory. To avoid unintended retention of large analysis-phase data structures into the execution phase, the `map_each` function must be declared by a top-level `def` statement; it may not be a nested function closure by default. *Warning:* [`print()`](../globals/all#print) statements that are executed during the call to `map_each` will not produce any visible output. |
-| `format_each` | [string](../core/string); or `None`; default is `None`  An optional format string pattern, applied to each string returned by the `map_each` function. The format string must have exactly one '%s' placeholder. |
-| `before_each` | [string](../core/string); or `None`; default is `None`  An optional argument to append before each argument derived from `values` is appended. |
-| `omit_if_empty` | [bool](../core/bool); default is `True`  If true, if there are no arguments derived from `values` to be appended, then all further processing is suppressed and the command line will be unchanged. If false, the arg name and `terminate_with`, if provided, will still be appended regardless of whether or not there are other arguments. |
-| `uniquify` | [bool](../core/bool); default is `False`  If true, duplicate arguments that are derived from `values` will be omitted. Only the first occurrence of each argument will remain. Usually this feature is not needed because depsets already omit duplicates, but it can be useful if `map_each` emits the same string for multiple items. |
-| `expand_directories` | [bool](../core/bool); default is `True`  If true, any directories in `values` will be expanded to a flat list of files. This happens before `map_each` is applied. |
-| `terminate_with` | [string](../core/string); or `None`; default is `None`  An optional argument to append after all other arguments. This argument will not be added if `omit_if_empty` is true (the default) and no other items are appended (as happens if `values` is empty or all of its items are filtered). |
-| `allow_closure` | [bool](../core/bool); default is `False`  If true, allows the use of closures in function parameters like `map_each`. Usually this isn't necessary and it risks retaining large analysis-phase data structures into the execution phase. |
+| `values` | [sequence](/versions/8.3.1/rules/lib/core/list); or [depset](/versions/8.3.1/rules/lib/builtins/depset); default is `unbound`  The list, tuple, or depset whose items will be appended. |
+| `map_each` | callable; or `None`; default is `None`  A function that converts each item to zero or more strings, which may be further processed before appending. If this param is not provided, the standard conversion is used. The function is passed either one or two positional arguments: the item to convert, followed by an optional [`DirectoryExpander`](/versions/8.3.1/rules/lib/builtins/DirectoryExpander). The second argument will be passed only if the supplied function is user-defined (not built-in) and declares more than one parameter. The return value's type depends on how many arguments are to be produced for the item:  * In the common case when each item turns into one string, the function should return that string.* If the item is to be filtered out entirely, the function should return `None`.* If the item turns into multiple strings, the function returns a list of those strings.  Returning a single string or `None` has the same effect as returning a list of length 1 or length 0 respectively. However, it is more efficient and readable to avoid creating a list where it is not needed. Ordinarily, items that are directories are automatically expanded to their contents when `expand_directories=True` is set. However, this will not expand directories contained inside other values -- for instance, when the items are structs that have directories as fields. In this situation, the `DirectoryExpander` argument can be applied to manually obtain the files of a given directory. To avoid unintended retention of large analysis-phase data structures into the execution phase, the `map_each` function must be declared by a top-level `def` statement; it may not be a nested function closure by default. *Warning:* [`print()`](/versions/8.3.1/rules/lib/globals/all#print) statements that are executed during the call to `map_each` will not produce any visible output. |
+| `format_each` | [string](/versions/8.3.1/rules/lib/core/string); or `None`; default is `None`  An optional format string pattern, applied to each string returned by the `map_each` function. The format string must have exactly one '%s' placeholder. |
+| `before_each` | [string](/versions/8.3.1/rules/lib/core/string); or `None`; default is `None`  An optional argument to append before each argument derived from `values` is appended. |
+| `omit_if_empty` | [bool](/versions/8.3.1/rules/lib/core/bool); default is `True`  If true, if there are no arguments derived from `values` to be appended, then all further processing is suppressed and the command line will be unchanged. If false, the arg name and `terminate_with`, if provided, will still be appended regardless of whether or not there are other arguments. |
+| `uniquify` | [bool](/versions/8.3.1/rules/lib/core/bool); default is `False`  If true, duplicate arguments that are derived from `values` will be omitted. Only the first occurrence of each argument will remain. Usually this feature is not needed because depsets already omit duplicates, but it can be useful if `map_each` emits the same string for multiple items. |
+| `expand_directories` | [bool](/versions/8.3.1/rules/lib/core/bool); default is `True`  If true, any directories in `values` will be expanded to a flat list of files. This happens before `map_each` is applied. |
+| `terminate_with` | [string](/versions/8.3.1/rules/lib/core/string); or `None`; default is `None`  An optional argument to append after all other arguments. This argument will not be added if `omit_if_empty` is true (the default) and no other items are appended (as happens if `values` is empty or all of its items are filtered). |
+| `allow_closure` | [bool](/versions/8.3.1/rules/lib/core/bool); default is `False`  If true, allows the use of closures in function parameters like `map_each`. Usually this isn't necessary and it risks retaining large analysis-phase data structures into the execution phase. |
 
 ## add\_joined
 
@@ -113,15 +113,15 @@ If after filtering there are no strings to join into an argument, and if `omit_i
 | Parameter | Description |
 | --- | --- |
 | `arg_name_or_values` | required  If two positional parameters are passed this is interpreted as the arg name. The arg name is added before `values` without any processing. This arg will not be added if `omit_if_empty` is true (the default) and there are no strings derived from `values` to join together (which can happen if `values` is empty or all of its items are filtered). If only one positional parameter is passed, it is interpreted as `values` (see below). |
-| `values` | [sequence](../core/list); or [depset](../builtins/depset); default is `unbound`  The list, tuple, or depset whose items will be joined. |
-| `join_with` | [string](../core/string); required  A delimiter string used to join together the strings obtained from applying `map_each` and `format_each`, in the same manner as [`string.join()`](../core/string#join). |
+| `values` | [sequence](/versions/8.3.1/rules/lib/core/list); or [depset](/versions/8.3.1/rules/lib/builtins/depset); default is `unbound`  The list, tuple, or depset whose items will be joined. |
+| `join_with` | [string](/versions/8.3.1/rules/lib/core/string); required  A delimiter string used to join together the strings obtained from applying `map_each` and `format_each`, in the same manner as [`string.join()`](/versions/8.3.1/rules/lib/core/string#join). |
 | `map_each` | callable; or `None`; default is `None`  Same as for [`add_all`](#add_all.map_each). |
-| `format_each` | [string](../core/string); or `None`; default is `None`  Same as for [`add_all`](#add_all.format_each). |
-| `format_joined` | [string](../core/string); or `None`; default is `None`  An optional format string pattern applied to the joined string. The format string must have exactly one '%s' placeholder. |
-| `omit_if_empty` | [bool](../core/bool); default is `True`  If true, if there are no strings to join together (either because `values` is empty or all its items are filtered), then all further processing is suppressed and the command line will be unchanged. If false, then even if there are no strings to join together, two arguments will be appended: the arg name followed by an empty string (which is the logical join of zero strings). |
-| `uniquify` | [bool](../core/bool); default is `False`  Same as for [`add_all`](#add_all.uniquify). |
-| `expand_directories` | [bool](../core/bool); default is `True`  Same as for [`add_all`](#add_all.expand_directories). |
-| `allow_closure` | [bool](../core/bool); default is `False`  Same as for [`add_all`](#add_all.allow_closure). |
+| `format_each` | [string](/versions/8.3.1/rules/lib/core/string); or `None`; default is `None`  Same as for [`add_all`](#add_all.format_each). |
+| `format_joined` | [string](/versions/8.3.1/rules/lib/core/string); or `None`; default is `None`  An optional format string pattern applied to the joined string. The format string must have exactly one '%s' placeholder. |
+| `omit_if_empty` | [bool](/versions/8.3.1/rules/lib/core/bool); default is `True`  If true, if there are no strings to join together (either because `values` is empty or all its items are filtered), then all further processing is suppressed and the command line will be unchanged. If false, then even if there are no strings to join together, two arguments will be appended: the arg name followed by an empty string (which is the logical join of zero strings). |
+| `uniquify` | [bool](/versions/8.3.1/rules/lib/core/bool); default is `False`  Same as for [`add_all`](#add_all.uniquify). |
+| `expand_directories` | [bool](/versions/8.3.1/rules/lib/core/bool); default is `True`  Same as for [`add_all`](#add_all.expand_directories). |
+| `allow_closure` | [bool](/versions/8.3.1/rules/lib/core/bool); default is `False`  Same as for [`add_all`](#add_all.allow_closure). |
 
 ## set\_param\_file\_format
 
@@ -135,7 +135,7 @@ Sets the format of the param file, if one is used
 
 | Parameter | Description |
 | --- | --- |
-| `format` | [string](../core/string); required  Must be one of:  * "multiline": Each item (argument name or value) is written verbatim to the param file with a newline character following it. * "shell": Same as "multiline", but the items are shell-quoted * "flag\_per\_line": Same as "multiline", but (1) only flags (beginning with '--') are written to the param file, and (2) the values of the flags, if any, are written on the same line with a '=' separator. This is the format expected by the Abseil flags library.   The format defaults to "shell" if not called. |
+| `format` | [string](/versions/8.3.1/rules/lib/core/string); required  Must be one of:  * "multiline": Each item (argument name or value) is written verbatim to the param file with a newline character following it. * "shell": Same as "multiline", but the items are shell-quoted * "flag\_per\_line": Same as "multiline", but (1) only flags (beginning with '--') are written to the param file, and (2) the values of the flags, if any, are written on the same line with a '=' separator. This is the format expected by the Abseil flags library.   The format defaults to "shell" if not called. |
 
 ## use\_param\_file
 
@@ -151,5 +151,5 @@ Bazel may choose to elide writing the params file to the output tree during exec
 
 | Parameter | Description |
 | --- | --- |
-| `param_file_arg` | [string](../core/string); required  A format string with a single "%s". If the args are spilled to a params file then they are replaced with an argument consisting of this string formatted with the path of the params file. For example, if the args are spilled to a params file "params.txt", then specifying "--file=%s" would cause the action command line to contain "--file=params.txt". |
-| `use_always` | [bool](../core/bool); default is `False`  Whether to always spill the args to a params file. If false, bazel will decide whether the arguments need to be spilled based on your system and arg length. |
\ No newline at end of file
+| `param_file_arg` | [string](/versions/8.3.1/rules/lib/core/string); required  A format string with a single "%s". If the args are spilled to a params file then they are replaced with an argument consisting of this string formatted with the path of the params file. For example, if the args are spilled to a params file "params.txt", then specifying "--file=%s" would cause the action command line to contain "--file=params.txt". |
+| `use_always` | [bool](/versions/8.3.1/rules/lib/core/bool); default is `False`  Whether to always spill the args to a params file. If false, bazel will decide whether the arguments need to be spilled based on your system and arg length. |
\ No newline at end of file
diff --git a/versions/8.3.1/rules/lib/builtins/Aspect.mdx b/versions/8.3.1/rules/lib/builtins/Aspect.mdx
index 2dfc06a9..fd9e3995 100644
--- a/versions/8.3.1/rules/lib/builtins/Aspect.mdx
+++ b/versions/8.3.1/rules/lib/builtins/Aspect.mdx
@@ -3,4 +3,4 @@ title: 'Aspect'
 ---
 
 For more information about Aspects, please consult the
-[documentation of the aspect function](../globals/bzl#aspect) or the [introduction to Aspects](https://bazel.build/versions/8.3.1/rules/aspects).
\ No newline at end of file
+[documentation of the aspect function](/versions/8.3.1/rules/lib/globals/bzl#aspect) or the [introduction to Aspects](https://bazel.build/versions/8.3.1/rules/aspects).
\ No newline at end of file
diff --git a/versions/8.3.1/rules/lib/builtins/Attribute.mdx b/versions/8.3.1/rules/lib/builtins/Attribute.mdx
index 18486c41..ad37f25a 100644
--- a/versions/8.3.1/rules/lib/builtins/Attribute.mdx
+++ b/versions/8.3.1/rules/lib/builtins/Attribute.mdx
@@ -2,4 +2,4 @@
 title: 'Attribute'
 ---
 
-Representation of a definition of an attribute. Use the [attr](../toplevel/attr) module to create an Attribute. They are only for use with a [rule](../globals/bzl#rule) or an [aspect](../globals/bzl#aspect).
\ No newline at end of file
+Representation of a definition of an attribute. Use the [attr](/versions/8.3.1/rules/lib/toplevel/attr) module to create an Attribute. They are only for use with a [rule](/versions/8.3.1/rules/lib/globals/bzl#rule) or an [aspect](/versions/8.3.1/rules/lib/globals/bzl#aspect).
\ No newline at end of file
diff --git a/versions/8.3.1/rules/lib/builtins/DirectoryExpander.mdx b/versions/8.3.1/rules/lib/builtins/DirectoryExpander.mdx
index 8bf9ae69..7bab6d8b 100644
--- a/versions/8.3.1/rules/lib/builtins/DirectoryExpander.mdx
+++ b/versions/8.3.1/rules/lib/builtins/DirectoryExpander.mdx
@@ -2,7 +2,7 @@
 title: 'DirectoryExpander'
 ---
 
-Expands directories created by [`ctx.actions.declare_directory`](../builtins/actions#declare_directory) during the execution phase. This is useful to expand directories in [`map_each`](../builtins/Args#add_all.map_each).
+Expands directories created by [`ctx.actions.declare_directory`](/versions/8.3.1/rules/lib/builtins/actions#declare_directory) during the execution phase. This is useful to expand directories in [`map_each`](/versions/8.3.1/rules/lib/builtins/Args#add_all.map_each).
 
 ## Members
 
@@ -20,4 +20,4 @@ If the given `File` is a directory, this returns a list of `File`s recursively u
 
 | Parameter | Description |
 | --- | --- |
-| `file` | [File](../builtins/File); required  The directory or file to expand. |
\ No newline at end of file
+| `file` | [File](/versions/8.3.1/rules/lib/builtins/File); required  The directory or file to expand. |
\ No newline at end of file
diff --git a/versions/8.3.1/rules/lib/builtins/DottedVersion.mdx b/versions/8.3.1/rules/lib/builtins/DottedVersion.mdx
index f17cea85..46ce8893 100644
--- a/versions/8.3.1/rules/lib/builtins/DottedVersion.mdx
+++ b/versions/8.3.1/rules/lib/builtins/DottedVersion.mdx
@@ -20,4 +20,4 @@ Compares based on most significant (first) not-matching version component. So, f
 
 | Parameter | Description |
 | --- | --- |
-| `other` | [DottedVersion](../builtins/DottedVersion); required  The other dotted version. |
\ No newline at end of file
+| `other` | [DottedVersion](/versions/8.3.1/rules/lib/builtins/DottedVersion); required  The other dotted version. |
\ No newline at end of file
diff --git a/versions/8.3.1/rules/lib/builtins/File.mdx b/versions/8.3.1/rules/lib/builtins/File.mdx
index 43fad060..84f7b000 100644
--- a/versions/8.3.1/rules/lib/builtins/File.mdx
+++ b/versions/8.3.1/rules/lib/builtins/File.mdx
@@ -4,7 +4,7 @@ title: 'File'
 
 This object is created during the analysis phase to represent a file or directory that will be read or written during the execution phase. It is not an open file handle, and cannot be used to directly read or write file contents. Rather, you use it to construct the action graph in a rule implementation function by passing it to action-creating functions. See the [Rules page](https://bazel.build/versions/8.3.1/extending/rules#files) for more information.
 
-When a `File` is passed to an [`Args`](../builtins/Args) object without using a `map_each` function, it is converted to a string by taking the value of its `path` field.
+When a `File` is passed to an [`Args`](/versions/8.3.1/rules/lib/builtins/Args) object without using a `map_each` function, it is converted to a string by taking the value of its `path` field.
 
 ## Members
 
@@ -83,7 +83,7 @@ May return `None`.
 string File.path
 ```
 
-The execution path of this file, relative to the workspace's execution directory. It consists of two parts, an optional first part called the *root* (see also the [root](../builtins/root) module), and the second part which is the `short_path`. The root may be empty, which it usually is for non-generated files. For generated files it usually contains a configuration-specific path fragment that encodes things like the target CPU architecture that was used while building said file. Use the `short_path` for the path under which the file is mapped if it's in the runfiles of a binary.
+The execution path of this file, relative to the workspace's execution directory. It consists of two parts, an optional first part called the *root* (see also the [root](/versions/8.3.1/rules/lib/builtins/root) module), and the second part which is the `short_path`. The root may be empty, which it usually is for non-generated files. For generated files it usually contains a configuration-specific path fragment that encodes things like the target CPU architecture that was used while building said file. Use the `short_path` for the path under which the file is mapped if it's in the runfiles of a binary.
 
 ## root
 
@@ -107,4 +107,4 @@ The path of this file relative to its root. This excludes the aforementioned *ro
 string File.tree_relative_path
 ```
 
-The path of this file relative to the root of the ancestor's tree, if the ancestor's [is\_directory](#is_directory) field is true. `tree_relative_path` is only available for expanded files of a directory in an action command, i.e. [Args.add\_all()](../builtins/Args#add_all). For other types of files, it is an error to access this field.
\ No newline at end of file
+The path of this file relative to the root of the ancestor's tree, if the ancestor's [is\_directory](#is_directory) field is true. `tree_relative_path` is only available for expanded files of a directory in an action command, i.e. [Args.add\_all()](/versions/8.3.1/rules/lib/builtins/Args#add_all). For other types of files, it is an error to access this field.
\ No newline at end of file
diff --git a/versions/8.3.1/rules/lib/builtins/Label.mdx b/versions/8.3.1/rules/lib/builtins/Label.mdx
index 427ed1fa..376423b3 100644
--- a/versions/8.3.1/rules/lib/builtins/Label.mdx
+++ b/versions/8.3.1/rules/lib/builtins/Label.mdx
@@ -33,7 +33,7 @@ For macros, a related function, `native.package_relative_label()`, converts the
 
 | Parameter | Description |
 | --- | --- |
-| `input` | [string](../core/string); or [Label](../builtins/Label); required  The input label string or Label object. If a Label object is passed, it's returned as is. |
+| `input` | [string](/versions/8.3.1/rules/lib/core/string); or [Label](/versions/8.3.1/rules/lib/builtins/Label); required  The input label string or Label object. If a Label object is passed, it's returned as is. |
 
 ## name
 
@@ -66,7 +66,7 @@ Label Label.relative(relName)
 ```
 
 **Experimental**. This API is experimental and may change at any time. Please do not depend on it. It may be enabled on an experimental basis by setting `--+incompatible_enable_deprecated_label_apis`
-**Deprecated.** This method behaves surprisingly when used with an argument containing an apparent repo name. Prefer [`Label.same_package_label()`](#same_package_label), [`native.package_relative_label()`](../toplevel/native#package_relative_label), or [`Label()`](#Label) instead.
+**Deprecated.** This method behaves surprisingly when used with an argument containing an apparent repo name. Prefer [`Label.same_package_label()`](#same_package_label), [`native.package_relative_label()`](/versions/8.3.1/rules/lib/toplevel/native#package_relative_label), or [`Label()`](#Label) instead.
 
 Resolves a label that is either absolute (starts with `//`) or relative to the current package. If this label is in a remote repository, the argument will be resolved relative to that repository. If the argument contains a repository name, the current label is ignored and the argument is returned as-is, except that the repository name is rewritten if it is in the current repository mapping. Reserved labels will also be returned as-is.
 For example:
@@ -89,7 +89,7 @@ Label("@repo//foo/bar:baz").relative("@other//wiz:quux") == Label("@remapped//wi
 
 | Parameter | Description |
 | --- | --- |
-| `relName` | [string](../core/string); required |
+| `relName` | [string](/versions/8.3.1/rules/lib/core/string); required |
 
 ## repo\_name
 
@@ -115,7 +115,7 @@ Creates a label in the same package as this label with the given target name.
 
 | Parameter | Description |
 | --- | --- |
-| `target_name` | [string](../core/string); required |
+| `target_name` | [string](/versions/8.3.1/rules/lib/core/string); required |
 
 ## workspace\_name
 
diff --git a/versions/8.3.1/rules/lib/builtins/LateBoundDefault.mdx b/versions/8.3.1/rules/lib/builtins/LateBoundDefault.mdx
index edd0010c..1becff6a 100644
--- a/versions/8.3.1/rules/lib/builtins/LateBoundDefault.mdx
+++ b/versions/8.3.1/rules/lib/builtins/LateBoundDefault.mdx
@@ -4,4 +4,4 @@ title: 'LateBoundDefault'
 
 Represents a late-bound default attribute value of type 'Label'. The value of a LateBoundDefault is only resolvable in the context of a rule implementation function, and depends on the current build configuration. For example, a LateBoundDefault might represent the Label of the java toolchain in the current build configuration.
 
-See [configuration\_field](../globals/bzl#configuration_field) for example usage.
\ No newline at end of file
+See [configuration\_field](/versions/8.3.1/rules/lib/globals/bzl#configuration_field) for example usage.
\ No newline at end of file
diff --git a/versions/8.3.1/rules/lib/builtins/Provider.mdx b/versions/8.3.1/rules/lib/builtins/Provider.mdx
index 54b9cf36..72553455 100644
--- a/versions/8.3.1/rules/lib/builtins/Provider.mdx
+++ b/versions/8.3.1/rules/lib/builtins/Provider.mdx
@@ -14,7 +14,7 @@ This value has a dual purpose:
   ```
 
   Note: Some providers, defined internally, do not allow instance creation
-* It is a *key* to access a provider instance on a [Target](../builtins/Target)
+* It is a *key* to access a provider instance on a [Target](/versions/8.3.1/rules/lib/builtins/Target)
 
   ```
   DataInfo = provider()
@@ -22,4 +22,4 @@ This value has a dual purpose:
     ... ctx.attr.dep[DataInfo]
   ```
 
-Create a new `Provider` using the [provider](../globals/bzl#provider) function.
\ No newline at end of file
+Create a new `Provider` using the [provider](/versions/8.3.1/rules/lib/globals/bzl#provider) function.
\ No newline at end of file
diff --git a/versions/8.3.1/rules/lib/builtins/TemplateDict.mdx b/versions/8.3.1/rules/lib/builtins/TemplateDict.mdx
index 5f18fd44..75abe16c 100644
--- a/versions/8.3.1/rules/lib/builtins/TemplateDict.mdx
+++ b/versions/8.3.1/rules/lib/builtins/TemplateDict.mdx
@@ -21,8 +21,8 @@ Add a String value
 
 | Parameter | Description |
 | --- | --- |
-| `key` | [string](../core/string); required  A String key |
-| `value` | [string](../core/string); required  A String value |
+| `key` | [string](/versions/8.3.1/rules/lib/core/string); required  A String key |
+| `value` | [string](/versions/8.3.1/rules/lib/core/string); required  A String value |
 
 ## add\_joined
 
@@ -36,10 +36,10 @@ Add depset of values
 
 | Parameter | Description |
 | --- | --- |
-| `key` | [string](../core/string); required  A String key |
-| `values` | [depset](../builtins/depset); required  The depset whose items will be joined. |
-| `join_with` | [string](../core/string); required  A delimiter string used to join together the strings obtained from applying `map_each`, in the same manner as [`string.join()`](../core/string#join). |
+| `key` | [string](/versions/8.3.1/rules/lib/core/string); required  A String key |
+| `values` | [depset](/versions/8.3.1/rules/lib/builtins/depset); required  The depset whose items will be joined. |
+| `join_with` | [string](/versions/8.3.1/rules/lib/core/string); required  A delimiter string used to join together the strings obtained from applying `map_each`, in the same manner as [`string.join()`](/versions/8.3.1/rules/lib/core/string#join). |
 | `map_each` | callable; required  A Starlark function accepting a single argument and returning either a string, `None`, or a list of strings. This function is applied to each item of the depset specified in the `values` parameter |
-| `uniquify` | [bool](../core/bool); default is `False`  If true, duplicate strings derived from `values` will be omitted. Only the first occurrence of each string will remain. Usually this feature is not needed because depsets already omit duplicates, but it can be useful if `map_each` emits the same string for multiple items. |
-| `format_joined` | [string](../core/string); or `None`; default is `None`  An optional format string pattern applied to the joined string. The format string must have exactly one '%s' placeholder. |
-| `allow_closure` | [bool](../core/bool); default is `False`  If true, allows the use of closures in function parameters like `map_each`. Usually this isn't necessary and it risks retaining large analysis-phase data structures into the execution phase. |
\ No newline at end of file
+| `uniquify` | [bool](/versions/8.3.1/rules/lib/core/bool); default is `False`  If true, duplicate strings derived from `values` will be omitted. Only the first occurrence of each string will remain. Usually this feature is not needed because depsets already omit duplicates, but it can be useful if `map_each` emits the same string for multiple items. |
+| `format_joined` | [string](/versions/8.3.1/rules/lib/core/string); or `None`; default is `None`  An optional format string pattern applied to the joined string. The format string must have exactly one '%s' placeholder. |
+| `allow_closure` | [bool](/versions/8.3.1/rules/lib/core/bool); default is `False`  If true, allows the use of closures in function parameters like `map_each`. Usually this isn't necessary and it risks retaining large analysis-phase data structures into the execution phase. |
\ No newline at end of file
diff --git a/versions/8.3.1/rules/lib/builtins/actions.mdx b/versions/8.3.1/rules/lib/builtins/actions.mdx
index 3142f83a..257eaeb6 100644
--- a/versions/8.3.1/rules/lib/builtins/actions.mdx
+++ b/versions/8.3.1/rules/lib/builtins/actions.mdx
@@ -2,7 +2,7 @@
 title: 'actions'
 ---
 
-Module providing functions to create actions. Access this module using [`ctx.actions`](../builtins/ctx#actions).
+Module providing functions to create actions. Access this module using [`ctx.actions`](/versions/8.3.1/rules/lib/builtins/ctx#actions).
 
 ## Members
 
@@ -32,14 +32,14 @@ Returns an Args object that can be used to build memory-efficient command lines.
 File actions.declare_directory(filename, *, sibling=None)
 ```
 
-Declares that the rule or aspect creates a directory with the given name, in the current package. You must create an action that generates the directory. The contents of the directory are not directly accessible from Starlark, but can be expanded in an action command with [`Args.add_all()`](../builtins/Args#add_all). Only regular files and directories can be in the expanded contents of a declare\_directory.
+Declares that the rule or aspect creates a directory with the given name, in the current package. You must create an action that generates the directory. The contents of the directory are not directly accessible from Starlark, but can be expanded in an action command with [`Args.add_all()`](/versions/8.3.1/rules/lib/builtins/Args#add_all). Only regular files and directories can be in the expanded contents of a declare\_directory.
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `filename` | [string](../core/string); required  If no 'sibling' provided, path of the new directory, relative to the current package. Otherwise a base name for a file ('sibling' defines a directory). |
-| `sibling` | [File](../builtins/File); or `None`; default is `None`  A file that lives in the same directory as the newly declared directory. The file must be in the current package. |
+| `filename` | [string](/versions/8.3.1/rules/lib/core/string); required  If no 'sibling' provided, path of the new directory, relative to the current package. Otherwise a base name for a file ('sibling' defines a directory). |
+| `sibling` | [File](/versions/8.3.1/rules/lib/builtins/File); or `None`; default is `None`  A file that lives in the same directory as the newly declared directory. The file must be in the current package. |
 
 ## declare\_file
 
@@ -51,14 +51,14 @@ Declares that the rule or aspect creates a file with the given filename. If `sib
 
 Remember that in addition to declaring a file, you must separately create an action that emits the file. Creating that action will require passing the returned `File` object to the action's construction function.
 
-Note that [predeclared output files](https://bazel.build/versions/8.3.1/extending/rules#files) do not need to be (and cannot be) declared using this function. You can obtain their `File` objects from [`ctx.outputs`](../builtins/ctx#outputs) instead. [See example of use](https://github.com/bazelbuild/examples/tree/main/rules/computed_dependencies/hash.bzl).
+Note that [predeclared output files](https://bazel.build/versions/8.3.1/extending/rules#files) do not need to be (and cannot be) declared using this function. You can obtain their `File` objects from [`ctx.outputs`](/versions/8.3.1/rules/lib/builtins/ctx#outputs) instead. [See example of use](https://github.com/bazelbuild/examples/tree/main/rules/computed_dependencies/hash.bzl).
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `filename` | [string](../core/string); required  If no 'sibling' provided, path of the new file, relative to the current package. Otherwise a base name for a file ('sibling' determines a directory). |
-| `sibling` | [File](../builtins/File); or `None`; default is `None`  A file that lives in the same directory as the newly created file. The file must be in the current package. |
+| `filename` | [string](/versions/8.3.1/rules/lib/core/string); required  If no 'sibling' provided, path of the new file, relative to the current package. Otherwise a base name for a file ('sibling' determines a directory). |
+| `sibling` | [File](/versions/8.3.1/rules/lib/builtins/File); or `None`; default is `None`  A file that lives in the same directory as the newly created file. The file must be in the current package. |
 
 ## declare\_symlink
 
@@ -72,8 +72,8 @@ Declares that the rule or aspect creates a symlink with the given name in the cu
 
 | Parameter | Description |
 | --- | --- |
-| `filename` | [string](../core/string); required  If no 'sibling' provided, path of the new symlink, relative to the current package. Otherwise a base name for a file ('sibling' defines a directory). |
-| `sibling` | [File](../builtins/File); or `None`; default is `None`  A file that lives in the same directory as the newly declared symlink. |
+| `filename` | [string](/versions/8.3.1/rules/lib/core/string); required  If no 'sibling' provided, path of the new symlink, relative to the current package. Otherwise a base name for a file ('sibling' defines a directory). |
+| `sibling` | [File](/versions/8.3.1/rules/lib/builtins/File); or `None`; default is `None`  A file that lives in the same directory as the newly declared symlink. |
 
 ## do\_nothing
 
@@ -87,8 +87,8 @@ Creates an empty action that neither executes a command nor produces any output,
 
 | Parameter | Description |
 | --- | --- |
-| `mnemonic` | [string](../core/string); required  A one-word description of the action, for example, CppCompile or GoLink. |
-| `inputs` | [sequence](../core/list) of [File](../builtins/File)s; or [depset](../builtins/depset); default is `[]`  List of the input files of the action. |
+| `mnemonic` | [string](/versions/8.3.1/rules/lib/core/string); required  A one-word description of the action, for example, CppCompile or GoLink. |
+| `inputs` | [sequence](/versions/8.3.1/rules/lib/core/list) of [File](/versions/8.3.1/rules/lib/builtins/File)s; or [depset](/versions/8.3.1/rules/lib/builtins/depset); default is `[]`  List of the input files of the action. |
 
 ## expand\_template
 
@@ -102,11 +102,11 @@ Creates a template expansion action. When the action is executed, it will genera
 
 | Parameter | Description |
 | --- | --- |
-| `template` | [File](../builtins/File); required  The template file, which is a UTF-8 encoded text file. |
-| `output` | [File](../builtins/File); required  The output file, which is a UTF-8 encoded text file. |
-| `substitutions` | [dict](../core/dict); default is `{}`  Substitutions to make when expanding the template. |
-| `is_executable` | [bool](../core/bool); default is `False`  Whether the output file should be executable. |
-| `computed_substitutions` | [TemplateDict](../builtins/TemplateDict); default is `unbound`  Substitutions to make when expanding the template. |
+| `template` | [File](/versions/8.3.1/rules/lib/builtins/File); required  The template file, which is a UTF-8 encoded text file. |
+| `output` | [File](/versions/8.3.1/rules/lib/builtins/File); required  The output file, which is a UTF-8 encoded text file. |
+| `substitutions` | [dict](/versions/8.3.1/rules/lib/core/dict); default is `{}`  Substitutions to make when expanding the template. |
+| `is_executable` | [bool](/versions/8.3.1/rules/lib/core/bool); default is `False`  Whether the output file should be executable. |
+| `computed_substitutions` | [TemplateDict](/versions/8.3.1/rules/lib/builtins/TemplateDict); default is `unbound`  Substitutions to make when expanding the template. |
 
 ## run
 
@@ -120,22 +120,22 @@ Creates an action that runs an executable. [See example of use](https://github.c
 
 | Parameter | Description |
 | --- | --- |
-| `outputs` | [sequence](../core/list) of [File](../builtins/File)s; required  List of the output files of the action. |
-| `inputs` | [sequence](../core/list) of [File](../builtins/File)s; or [depset](../builtins/depset); default is `[]`  List or depset of the input files of the action. |
-| `unused_inputs_list` | [File](../builtins/File); or `None`; default is `None`  File containing list of inputs unused by the action. The content of this file (generally one of the outputs of the action) corresponds to the list of input files that were not used during the whole action execution. Any change in those files must not affect in any way the outputs of the action. |
-| `executable` | [File](../builtins/File); or [string](../core/string); or [FilesToRunProvider](../providers/FilesToRunProvider); required  The executable file to be called by the action. |
-| `tools` | [sequence](../core/list); or [depset](../builtins/depset); default is `unbound`  List or depset of any tools needed by the action. Tools are inputs with additional runfiles that are automatically made available to the action. When a list is provided, it can be a heterogenous collection of Files, FilesToRunProvider instances, or depsets of Files. Files which are directly in the list and come from ctx.executable will have their runfiles automatically added. When a depset is provided, it must contain only Files. In both cases, files within depsets are not cross-referenced with ctx.executable for runfiles. |
-| `arguments` | [sequence](../core/list); default is `[]`  Command line arguments of the action. Must be a list of strings or [`actions.args()`](#args) objects. |
-| `mnemonic` | [string](../core/string); or `None`; default is `None`  A one-word description of the action, for example, CppCompile or GoLink. |
-| `progress_message` | [string](../core/string); or `None`; default is `None`  Progress message to show to the user during the build, for example, "Compiling foo.cc to create foo.o". The message may contain `%{label}`, `%{input}`, or `%{output}` patterns, which are substituted with label string, first input, or output's path, respectively. Prefer to use patterns instead of static strings, because the former are more efficient. |
-| `use_default_shell_env` | [bool](../core/bool); default is `False`  Whether the action should use the default shell environment, which consists of a few OS-dependent variables as well as variables set via [`--action_env`](/versions/8.3.1/reference/command-line-reference#flag--action_env). If both `use_default_shell_env` and `env` are set to `True`, values set in `env` will overwrite the default shell environment if [`--incompatible_merge_fixed_and_default_shell_env`](/versions/8.3.1/reference/command-line-reference#flag--incompatible_merge_fixed_and_default_shell_env) is enabled (default). If the flag is not enabled, `env` is ignored. |
-| `env` | [dict](../core/dict); or `None`; default is `None`  Sets the dictionary of environment variables. If both `use_default_shell_env` and `env` are set to `True`, values set in `env` will overwrite the default shell environment if [`--incompatible_merge_fixed_and_default_shell_env`](/versions/8.3.1/reference/command-line-reference#flag--incompatible_merge_fixed_and_default_shell_env) is enabled (default). If the flag is not enabled, `env` is ignored. |
-| `execution_requirements` | [dict](../core/dict); or `None`; default is `None`  Information for scheduling the action. See [tags](/versions/8.3.1/reference/be/common-definitions#common.tags) for useful keys. |
-| `input_manifests` | [sequence](../core/list); or `None`; default is `None`  Legacy argument. Ignored. |
-| `exec_group` | [string](../core/string); or `None`; default is `None`  Runs the action on the given exec group's execution platform. If none, uses the target's default execution platform. |
-| `shadowed_action` | [Action](../builtins/Action); default is `None`  Runs the action using the given shadowed action's inputs and environment added to the action's inputs list and environment. The action environment can overwrite any of the shadowed action's environment variables. If none, uses only the action's inputs and given environment. |
+| `outputs` | [sequence](/versions/8.3.1/rules/lib/core/list) of [File](/versions/8.3.1/rules/lib/builtins/File)s; required  List of the output files of the action. |
+| `inputs` | [sequence](/versions/8.3.1/rules/lib/core/list) of [File](/versions/8.3.1/rules/lib/builtins/File)s; or [depset](/versions/8.3.1/rules/lib/builtins/depset); default is `[]`  List or depset of the input files of the action. |
+| `unused_inputs_list` | [File](/versions/8.3.1/rules/lib/builtins/File); or `None`; default is `None`  File containing list of inputs unused by the action. The content of this file (generally one of the outputs of the action) corresponds to the list of input files that were not used during the whole action execution. Any change in those files must not affect in any way the outputs of the action. |
+| `executable` | [File](/versions/8.3.1/rules/lib/builtins/File); or [string](/versions/8.3.1/rules/lib/core/string); or [FilesToRunProvider](/versions/8.3.1/rules/lib/providers/FilesToRunProvider); required  The executable file to be called by the action. |
+| `tools` | [sequence](/versions/8.3.1/rules/lib/core/list); or [depset](/versions/8.3.1/rules/lib/builtins/depset); default is `unbound`  List or depset of any tools needed by the action. Tools are inputs with additional runfiles that are automatically made available to the action. When a list is provided, it can be a heterogenous collection of Files, FilesToRunProvider instances, or depsets of Files. Files which are directly in the list and come from ctx.executable will have their runfiles automatically added. When a depset is provided, it must contain only Files. In both cases, files within depsets are not cross-referenced with ctx.executable for runfiles. |
+| `arguments` | [sequence](/versions/8.3.1/rules/lib/core/list); default is `[]`  Command line arguments of the action. Must be a list of strings or [`actions.args()`](#args) objects. |
+| `mnemonic` | [string](/versions/8.3.1/rules/lib/core/string); or `None`; default is `None`  A one-word description of the action, for example, CppCompile or GoLink. |
+| `progress_message` | [string](/versions/8.3.1/rules/lib/core/string); or `None`; default is `None`  Progress message to show to the user during the build, for example, "Compiling foo.cc to create foo.o". The message may contain `%{label}`, `%{input}`, or `%{output}` patterns, which are substituted with label string, first input, or output's path, respectively. Prefer to use patterns instead of static strings, because the former are more efficient. |
+| `use_default_shell_env` | [bool](/versions/8.3.1/rules/lib/core/bool); default is `False`  Whether the action should use the default shell environment, which consists of a few OS-dependent variables as well as variables set via [`--action_env`](/versions/8.3.1/reference/command-line-reference#flag--action_env). If both `use_default_shell_env` and `env` are set to `True`, values set in `env` will overwrite the default shell environment if [`--incompatible_merge_fixed_and_default_shell_env`](/versions/8.3.1/reference/command-line-reference#flag--incompatible_merge_fixed_and_default_shell_env) is enabled (default). If the flag is not enabled, `env` is ignored. |
+| `env` | [dict](/versions/8.3.1/rules/lib/core/dict); or `None`; default is `None`  Sets the dictionary of environment variables. If both `use_default_shell_env` and `env` are set to `True`, values set in `env` will overwrite the default shell environment if [`--incompatible_merge_fixed_and_default_shell_env`](/versions/8.3.1/reference/command-line-reference#flag--incompatible_merge_fixed_and_default_shell_env) is enabled (default). If the flag is not enabled, `env` is ignored. |
+| `execution_requirements` | [dict](/versions/8.3.1/rules/lib/core/dict); or `None`; default is `None`  Information for scheduling the action. See [tags](/versions/8.3.1/reference/be/common-definitions#common.tags) for useful keys. |
+| `input_manifests` | [sequence](/versions/8.3.1/rules/lib/core/list); or `None`; default is `None`  Legacy argument. Ignored. |
+| `exec_group` | [string](/versions/8.3.1/rules/lib/core/string); or `None`; default is `None`  Runs the action on the given exec group's execution platform. If none, uses the target's default execution platform. |
+| `shadowed_action` | [Action](/versions/8.3.1/rules/lib/builtins/Action); default is `None`  Runs the action using the given shadowed action's inputs and environment added to the action's inputs list and environment. The action environment can overwrite any of the shadowed action's environment variables. If none, uses only the action's inputs and given environment. |
 | `resource_set` | callable; or `None`; default is `None`  A callback function that returns a resource set dictionary, used to estimate resource usage at execution time if this action is run locally. The function accepts two positional arguments: a string representing an OS name (e.g. "osx"), and an integer representing the number of inputs to the action. The returned dictionary may contain the following entries, each of which may be a float or an int:  * "cpu": number of CPUs; default 1* "memory": in MB; default 250* "local\_test": number of local tests; default 1   If this parameter is set to `None` , the default values are used. The callback must be top-level (lambda and nested functions aren't allowed). |
-| `toolchain` | [Label](../builtins/Label); or [string](../core/string); or `None`; default is `unbound`  Toolchain type of the executable or tools used in this action.  If executable and tools are not coming from a toolchain, set this parameter to `None`.  If executable and tools are coming from a toolchain, toolchain type must be set so that the action executes on the correct execution platform.  Note that the rule which creates this action needs to define this toolchain inside its 'rule()' function.  When `toolchain` and `exec\_group` parameters are both set, `exec\_group` will be used. An error is raised in case the `exec\_group` doesn't specify the same toolchain. |
+| `toolchain` | [Label](/versions/8.3.1/rules/lib/builtins/Label); or [string](/versions/8.3.1/rules/lib/core/string); or `None`; default is `unbound`  Toolchain type of the executable or tools used in this action.  If executable and tools are not coming from a toolchain, set this parameter to `None`.  If executable and tools are coming from a toolchain, toolchain type must be set so that the action executes on the correct execution platform.  Note that the rule which creates this action needs to define this toolchain inside its 'rule()' function.  When `toolchain` and `exec\_group` parameters are both set, `exec\_group` will be used. An error is raised in case the `exec\_group` doesn't specify the same toolchain. |
 
 ## run\_shell
 
@@ -149,21 +149,21 @@ Creates an action that runs a shell command. [See example of use](https://github
 
 | Parameter | Description |
 | --- | --- |
-| `outputs` | [sequence](../core/list) of [File](../builtins/File)s; required  List of the output files of the action. |
-| `inputs` | [sequence](../core/list) of [File](../builtins/File)s; or [depset](../builtins/depset); default is `[]`  List or depset of the input files of the action. |
-| `tools` | [sequence](../core/list) of [File](../builtins/File)s; or [depset](../builtins/depset); default is `unbound`  List or depset of any tools needed by the action. Tools are inputs with additional runfiles that are automatically made available to the action. The list can contain Files or FilesToRunProvider instances. |
-| `arguments` | [sequence](../core/list); default is `[]`  Command line arguments of the action. Must be a list of strings or [`actions.args()`](#args) objects. Bazel passes the elements in this attribute as arguments to the command.The command can access these arguments using shell variable substitutions such as `$1`, `$2`, etc. Note that since Args objects are flattened before indexing, if there is an Args object of unknown size then all subsequent strings will be at unpredictable indices. It may be useful to use `$@` (to retrieve all arguments) in conjunction with Args objects of indeterminate size. In the case where `command` is a list of strings, this parameter may not be used. |
-| `mnemonic` | [string](../core/string); or `None`; default is `None`  A one-word description of the action, for example, CppCompile or GoLink. |
-| `command` | [string](../core/string); or [sequence](../core/list) of [string](../core/string)s; required  Shell command to execute. This may either be a string (preferred) or a sequence of strings **(deprecated)**. If `command` is a string, then it is executed as if by `sh -c  "" ` -- that is, the elements in `arguments` are made available to the command as `$1`, `$2` (or `%1`, `%2` if using Windows batch), etc. If `arguments` contains any [`actions.args()`](#args) objects, their contents are appended one by one to the command line, so `$`*i* can refer to individual strings within an Args object. Note that if an Args object of unknown size is passed as part of `arguments`, then the strings will be at unknown indices; in this case the `$@` shell substitution (retrieve all arguments) may be useful. **(Deprecated)** If `command` is a sequence of strings, the first item is the executable to run and the remaining items are its arguments. If this form is used, the `arguments` parameter must not be supplied. *Note that this form is deprecated and will soon be removed. It is disabled with `--incompatible\_run\_shell\_command\_string`. Use this flag to verify your code is compatible.*  Bazel uses the same shell to execute the command as it does for genrules. |
-| `progress_message` | [string](../core/string); or `None`; default is `None`  Progress message to show to the user during the build, for example, "Compiling foo.cc to create foo.o". The message may contain `%{label}`, `%{input}`, or `%{output}` patterns, which are substituted with label string, first input, or output's path, respectively. Prefer to use patterns instead of static strings, because the former are more efficient. |
-| `use_default_shell_env` | [bool](../core/bool); default is `False`  Whether the action should use the default shell environment, which consists of a few OS-dependent variables as well as variables set via [`--action_env`](/versions/8.3.1/reference/command-line-reference#flag--action_env). If both `use_default_shell_env` and `env` are set to `True`, values set in `env` will overwrite the default shell environment if [`--incompatible_merge_fixed_and_default_shell_env`](/versions/8.3.1/reference/command-line-reference#flag--incompatible_merge_fixed_and_default_shell_env) is enabled (default). If the flag is not enabled, `env` is ignored. |
-| `env` | [dict](../core/dict); or `None`; default is `None`  Sets the dictionary of environment variables. If both `use_default_shell_env` and `env` are set to `True`, values set in `env` will overwrite the default shell environment if [`--incompatible_merge_fixed_and_default_shell_env`](/versions/8.3.1/reference/command-line-reference#flag--incompatible_merge_fixed_and_default_shell_env) is enabled (default). If the flag is not enabled, `env` is ignored. |
-| `execution_requirements` | [dict](../core/dict); or `None`; default is `None`  Information for scheduling the action. See [tags](/versions/8.3.1/reference/be/common-definitions#common.tags) for useful keys. |
-| `input_manifests` | [sequence](../core/list); or `None`; default is `None`  Legacy argument. Ignored. |
-| `exec_group` | [string](../core/string); or `None`; default is `None`  Runs the action on the given exec group's execution platform. If none, uses the target's default execution platform. |
-| `shadowed_action` | [Action](../builtins/Action); default is `None`  Runs the action using the given shadowed action's discovered inputs added to the action's inputs list. If none, uses only the action's inputs. |
+| `outputs` | [sequence](/versions/8.3.1/rules/lib/core/list) of [File](/versions/8.3.1/rules/lib/builtins/File)s; required  List of the output files of the action. |
+| `inputs` | [sequence](/versions/8.3.1/rules/lib/core/list) of [File](/versions/8.3.1/rules/lib/builtins/File)s; or [depset](/versions/8.3.1/rules/lib/builtins/depset); default is `[]`  List or depset of the input files of the action. |
+| `tools` | [sequence](/versions/8.3.1/rules/lib/core/list) of [File](/versions/8.3.1/rules/lib/builtins/File)s; or [depset](/versions/8.3.1/rules/lib/builtins/depset); default is `unbound`  List or depset of any tools needed by the action. Tools are inputs with additional runfiles that are automatically made available to the action. The list can contain Files or FilesToRunProvider instances. |
+| `arguments` | [sequence](/versions/8.3.1/rules/lib/core/list); default is `[]`  Command line arguments of the action. Must be a list of strings or [`actions.args()`](#args) objects. Bazel passes the elements in this attribute as arguments to the command.The command can access these arguments using shell variable substitutions such as `$1`, `$2`, etc. Note that since Args objects are flattened before indexing, if there is an Args object of unknown size then all subsequent strings will be at unpredictable indices. It may be useful to use `$@` (to retrieve all arguments) in conjunction with Args objects of indeterminate size. In the case where `command` is a list of strings, this parameter may not be used. |
+| `mnemonic` | [string](/versions/8.3.1/rules/lib/core/string); or `None`; default is `None`  A one-word description of the action, for example, CppCompile or GoLink. |
+| `command` | [string](/versions/8.3.1/rules/lib/core/string); or [sequence](/versions/8.3.1/rules/lib/core/list) of [string](/versions/8.3.1/rules/lib/core/string)s; required  Shell command to execute. This may either be a string (preferred) or a sequence of strings **(deprecated)**. If `command` is a string, then it is executed as if by `sh -c  "" ` -- that is, the elements in `arguments` are made available to the command as `$1`, `$2` (or `%1`, `%2` if using Windows batch), etc. If `arguments` contains any [`actions.args()`](#args) objects, their contents are appended one by one to the command line, so `$`*i* can refer to individual strings within an Args object. Note that if an Args object of unknown size is passed as part of `arguments`, then the strings will be at unknown indices; in this case the `$@` shell substitution (retrieve all arguments) may be useful. **(Deprecated)** If `command` is a sequence of strings, the first item is the executable to run and the remaining items are its arguments. If this form is used, the `arguments` parameter must not be supplied. *Note that this form is deprecated and will soon be removed. It is disabled with `--incompatible\_run\_shell\_command\_string`. Use this flag to verify your code is compatible.*  Bazel uses the same shell to execute the command as it does for genrules. |
+| `progress_message` | [string](/versions/8.3.1/rules/lib/core/string); or `None`; default is `None`  Progress message to show to the user during the build, for example, "Compiling foo.cc to create foo.o". The message may contain `%{label}`, `%{input}`, or `%{output}` patterns, which are substituted with label string, first input, or output's path, respectively. Prefer to use patterns instead of static strings, because the former are more efficient. |
+| `use_default_shell_env` | [bool](/versions/8.3.1/rules/lib/core/bool); default is `False`  Whether the action should use the default shell environment, which consists of a few OS-dependent variables as well as variables set via [`--action_env`](/versions/8.3.1/reference/command-line-reference#flag--action_env). If both `use_default_shell_env` and `env` are set to `True`, values set in `env` will overwrite the default shell environment if [`--incompatible_merge_fixed_and_default_shell_env`](/versions/8.3.1/reference/command-line-reference#flag--incompatible_merge_fixed_and_default_shell_env) is enabled (default). If the flag is not enabled, `env` is ignored. |
+| `env` | [dict](/versions/8.3.1/rules/lib/core/dict); or `None`; default is `None`  Sets the dictionary of environment variables. If both `use_default_shell_env` and `env` are set to `True`, values set in `env` will overwrite the default shell environment if [`--incompatible_merge_fixed_and_default_shell_env`](/versions/8.3.1/reference/command-line-reference#flag--incompatible_merge_fixed_and_default_shell_env) is enabled (default). If the flag is not enabled, `env` is ignored. |
+| `execution_requirements` | [dict](/versions/8.3.1/rules/lib/core/dict); or `None`; default is `None`  Information for scheduling the action. See [tags](/versions/8.3.1/reference/be/common-definitions#common.tags) for useful keys. |
+| `input_manifests` | [sequence](/versions/8.3.1/rules/lib/core/list); or `None`; default is `None`  Legacy argument. Ignored. |
+| `exec_group` | [string](/versions/8.3.1/rules/lib/core/string); or `None`; default is `None`  Runs the action on the given exec group's execution platform. If none, uses the target's default execution platform. |
+| `shadowed_action` | [Action](/versions/8.3.1/rules/lib/builtins/Action); default is `None`  Runs the action using the given shadowed action's discovered inputs added to the action's inputs list. If none, uses only the action's inputs. |
 | `resource_set` | callable; or `None`; default is `None`  A callback function for estimating resource usage if run locally. See[`ctx.actions.run()`](#run.resource_set). |
-| `toolchain` | [Label](../builtins/Label); or [string](../core/string); or `None`; default is `unbound`  Toolchain type of the executable or tools used in this action.  If executable and tools are not coming from a toolchain, set this parameter to `None`.  If executable and tools are coming from a toolchain, toolchain type must be set so that the action executes on the correct execution platform.  Note that the rule which creates this action needs to define this toolchain inside its 'rule()' function.  When `toolchain` and `exec\_group` parameters are both set, `exec\_group` will be used. An error is raised in case the `exec\_group` doesn't specify the same toolchain. |
+| `toolchain` | [Label](/versions/8.3.1/rules/lib/builtins/Label); or [string](/versions/8.3.1/rules/lib/core/string); or `None`; default is `unbound`  Toolchain type of the executable or tools used in this action.  If executable and tools are not coming from a toolchain, set this parameter to `None`.  If executable and tools are coming from a toolchain, toolchain type must be set so that the action executes on the correct execution platform.  Note that the rule which creates this action needs to define this toolchain inside its 'rule()' function.  When `toolchain` and `exec\_group` parameters are both set, `exec\_group` will be used. An error is raised in case the `exec\_group` doesn't specify the same toolchain. |
 
 ## symlink
 
@@ -183,11 +183,11 @@ Otherwise, when you use `target_path`, declare `output` with [`declare_symlink()
 
 | Parameter | Description |
 | --- | --- |
-| `output` | [File](../builtins/File); required  The output of this action. |
-| `target_file` | [File](../builtins/File); or `None`; default is `None`  The File that the output symlink will point to. |
-| `target_path` | [string](../core/string); or `None`; default is `None`  The exact path that the output symlink will point to. No normalization or other processing is applied. |
-| `is_executable` | [bool](../core/bool); default is `False`  May only be used with `target_file`, not `target_path`. If true, when the action is executed, the `target_file`'s path is checked to confirm that it is executable, and an error is reported if it is not. Setting `is_executable` to False does not mean the target is not executable, just that no verification is done. This feature does not make sense for `target_path` because dangling symlinks might not exist at build time. |
-| `progress_message` | [string](../core/string); or `None`; default is `None`  Progress message to show to the user during the build. |
+| `output` | [File](/versions/8.3.1/rules/lib/builtins/File); required  The output of this action. |
+| `target_file` | [File](/versions/8.3.1/rules/lib/builtins/File); or `None`; default is `None`  The File that the output symlink will point to. |
+| `target_path` | [string](/versions/8.3.1/rules/lib/core/string); or `None`; default is `None`  The exact path that the output symlink will point to. No normalization or other processing is applied. |
+| `is_executable` | [bool](/versions/8.3.1/rules/lib/core/bool); default is `False`  May only be used with `target_file`, not `target_path`. If true, when the action is executed, the `target_file`'s path is checked to confirm that it is executable, and an error is reported if it is not. Setting `is_executable` to False does not mean the target is not executable, just that no verification is done. This feature does not make sense for `target_path` because dangling symlinks might not exist at build time. |
+| `progress_message` | [string](/versions/8.3.1/rules/lib/core/string); or `None`; default is `None`  Progress message to show to the user during the build. |
 
 ## template\_dict
 
@@ -209,6 +209,6 @@ Creates a file write action. When the action is executed, it will write the give
 
 | Parameter | Description |
 | --- | --- |
-| `output` | [File](../builtins/File); required  The output file. |
-| `content` | [string](../core/string); or [Args](../builtins/Args); required  the contents of the file. May be a either a string or an [`actions.args()`](#args) object. |
-| `is_executable` | [bool](../core/bool); default is `False`  Whether the output file should be executable. |
\ No newline at end of file
+| `output` | [File](/versions/8.3.1/rules/lib/builtins/File); required  The output file. |
+| `content` | [string](/versions/8.3.1/rules/lib/core/string); or [Args](/versions/8.3.1/rules/lib/builtins/Args); required  the contents of the file. May be a either a string or an [`actions.args()`](#args) object. |
+| `is_executable` | [bool](/versions/8.3.1/rules/lib/core/bool); default is `False`  Whether the output file should be executable. |
\ No newline at end of file
diff --git a/versions/8.3.1/rules/lib/builtins/apple_platform.mdx b/versions/8.3.1/rules/lib/builtins/apple_platform.mdx
index ba2fc42e..a639cf0e 100644
--- a/versions/8.3.1/rules/lib/builtins/apple_platform.mdx
+++ b/versions/8.3.1/rules/lib/builtins/apple_platform.mdx
@@ -4,7 +4,7 @@ title: 'apple\_platform'
 
 Corresponds to Xcode's notion of a platform as would be found in `Xcode.app/Contents/Developer/Platforms`. Each platform represents an Apple platform type (such as iOS or tvOS) combined with one or more related CPU architectures. For example, the iOS simulator platform supports `x86_64` and `i386` architectures.
 
-Specific instances of this type can be retrieved from the fields of the [apple\_common.platform](../toplevel/apple_common#platform) struct:
+Specific instances of this type can be retrieved from the fields of the [apple\_common.platform](/versions/8.3.1/rules/lib/toplevel/apple_common#platform) struct:
 
 * `apple_common.platform.ios_device`
 * `apple_common.platform.ios_simulator`
@@ -14,7 +14,7 @@ Specific instances of this type can be retrieved from the fields of the [apple\_
 * `apple_common.platform.watchos_device`
 * `apple_common.platform.watchos_simulator`
 
-More commonly, however, the [apple](../fragments/apple) configuration fragment has fields/methods that allow rules to determine the platform for which a target is being built.
+More commonly, however, the [apple](/versions/8.3.1/rules/lib/fragments/apple) configuration fragment has fields/methods that allow rules to determine the platform for which a target is being built.
 
 Example:
 
diff --git a/versions/8.3.1/rules/lib/builtins/configuration.mdx b/versions/8.3.1/rules/lib/builtins/configuration.mdx
index 67fec3ee..8db3f6f1 100644
--- a/versions/8.3.1/rules/lib/builtins/configuration.mdx
+++ b/versions/8.3.1/rules/lib/builtins/configuration.mdx
@@ -17,7 +17,7 @@ This object holds information about the environment in which the build is runnin
 bool configuration.coverage_enabled
 ```
 
-A boolean that tells whether code coverage is enabled for this run. Note that this does not compute whether a specific rule should be instrumented for code coverage data collection. For that, see the [`ctx.coverage_instrumented`](../builtins/ctx#coverage_instrumented) function.
+A boolean that tells whether code coverage is enabled for this run. Note that this does not compute whether a specific rule should be instrumented for code coverage data collection. For that, see the [`ctx.coverage_instrumented`](/versions/8.3.1/rules/lib/builtins/ctx#coverage_instrumented) function.
 
 ## default\_shell\_env
 
diff --git a/versions/8.3.1/rules/lib/builtins/ctx.mdx b/versions/8.3.1/rules/lib/builtins/ctx.mdx
index 265e00bf..c5d10817 100644
--- a/versions/8.3.1/rules/lib/builtins/ctx.mdx
+++ b/versions/8.3.1/rules/lib/builtins/ctx.mdx
@@ -66,7 +66,7 @@ A list of ids for all aspects applied to the target. Only available in aspect im
 struct ctx.attr
 ```
 
-A struct to access the values of the [attributes](https://bazel.build/versions/8.3.1/extending/rules#attributes). The values are provided by the user (if not, a default value is used). The attributes of the struct and the types of their values correspond to the keys and values of the [`attrs` dict](../globals/bzl#rule.attrs) provided to the [`rule` function](../globals/bzl#rule). [See example of use](https://github.com/bazelbuild/examples/blob/main/rules/attributes/printer.bzl).
+A struct to access the values of the [attributes](https://bazel.build/versions/8.3.1/extending/rules#attributes). The values are provided by the user (if not, a default value is used). The attributes of the struct and the types of their values correspond to the keys and values of the [`attrs` dict](/versions/8.3.1/rules/lib/globals/bzl#rule.attrs) provided to the [`rule` function](/versions/8.3.1/rules/lib/globals/bzl#rule). [See example of use](https://github.com/bazelbuild/examples/blob/main/rules/attributes/printer.bzl).
 
 ## bin\_dir
 
@@ -98,7 +98,7 @@ Value of the build setting represented by the current target. If this isn't the
 configuration ctx.configuration
 ```
 
-The default configuration. See the [configuration](../builtins/configuration) type for more details.
+The default configuration. See the [configuration](/versions/8.3.1/rules/lib/builtins/configuration) type for more details.
 
 ## coverage\_instrumented
 
@@ -106,13 +106,13 @@ The default configuration. See the [configuration](../builtins/configuration) ty
 bool ctx.coverage_instrumented(target=None)
 ```
 
-Returns whether code coverage instrumentation should be generated when performing compilation actions for this rule or, if `target` is provided, the rule specified by that Target. (If a non-rule or a Starlark rule Target is provided, this returns False.) Checks if the sources of the current rule (if no Target is provided) or the sources of Target should be instrumented based on the --instrumentation\_filter and --instrument\_test\_targets config settings. This differs from `coverage_enabled` in the [configuration](../builtins/configuration), which notes whether coverage data collection is enabled for the entire run, but not whether a specific target should be instrumented.
+Returns whether code coverage instrumentation should be generated when performing compilation actions for this rule or, if `target` is provided, the rule specified by that Target. (If a non-rule or a Starlark rule Target is provided, this returns False.) Checks if the sources of the current rule (if no Target is provided) or the sources of Target should be instrumented based on the --instrumentation\_filter and --instrument\_test\_targets config settings. This differs from `coverage_enabled` in the [configuration](/versions/8.3.1/rules/lib/builtins/configuration), which notes whether coverage data collection is enabled for the entire run, but not whether a specific target should be instrumented.
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `target` | [Target](../builtins/Target); or `None`; default is `None`  A Target specifying a rule. If not provided, defaults to the current rule. |
+| `target` | [Target](/versions/8.3.1/rules/lib/builtins/Target); or `None`; default is `None`  A Target specifying a rule. If not provided, defaults to the current rule. |
 
 ## created\_actions
 
@@ -120,7 +120,7 @@ Returns whether code coverage instrumentation should be generated when performin
 StarlarkValue ctx.created_actions()
 ```
 
-For rules with [\_skylark\_testable](../globals/bzl#rule._skylark_testable) set to `True`, this returns an `Actions` provider representing all actions created so far for the current rule. For all other rules, returns `None`. Note that the provider is not updated when subsequent actions are created, so you will have to call this function again if you wish to inspect them.
+For rules with [\_skylark\_testable](/versions/8.3.1/rules/lib/globals/bzl#rule._skylark_testable) set to `True`, this returns an `Actions` provider representing all actions created so far for the current rule. For all other rules, returns `None`. Note that the provider is not updated when subsequent actions are created, so you will have to call this function again if you wish to inspect them.
 
 This is intended to help write tests for rule-implementation helper functions, which may take in a `ctx` object and create actions on it.
 
@@ -146,7 +146,7 @@ A collection of the execution groups available for this rule, indexed by their n
 struct ctx.executable
 ```
 
-A `struct` containing executable files defined in [label type attributes](../toplevel/attr#label) marked as [`executable=True`](../toplevel/attr#label.executable). The struct fields correspond to the attribute names. Each value in the struct is either a [`File`](../builtins/File) or `None`. If an optional attribute is not specified in the rule then the corresponding struct value is `None`. If a label type is not marked as `executable=True`, no corresponding struct field is generated. [See example of use](https://github.com/bazelbuild/examples/blob/main/rules/actions_run/execute.bzl).
+A `struct` containing executable files defined in [label type attributes](/versions/8.3.1/rules/lib/toplevel/attr#label) marked as [`executable=True`](/versions/8.3.1/rules/lib/toplevel/attr#label.executable). The struct fields correspond to the attribute names. Each value in the struct is either a [`File`](/versions/8.3.1/rules/lib/builtins/File) or `None`. If an optional attribute is not specified in the rule then the corresponding struct value is `None`. If a label type is not marked as `executable=True`, no corresponding struct field is generated. [See example of use](https://github.com/bazelbuild/examples/blob/main/rules/actions_run/execute.bzl).
 
 ## expand\_location
 
@@ -164,8 +164,8 @@ This function is useful to let the user specify a command in a BUILD file (like
 
 | Parameter | Description |
 | --- | --- |
-| `input` | [string](../core/string); required  String to be expanded. |
-| `targets` | [sequence](../core/list) of [Target](../builtins/Target)s; default is `[]`  List of targets for additional lookup information. These are expanded as follows: A target with a single file in `DefaultInfo.files` expands to that file. Other targets expand to their `DefaultInfo.executable` file if set and if `--incompatible_locations_prefers_executable` is enabled, otherwise they expand to `DefaultInfo.files`. |
+| `input` | [string](/versions/8.3.1/rules/lib/core/string); required  String to be expanded. |
+| `targets` | [sequence](/versions/8.3.1/rules/lib/core/list) of [Target](/versions/8.3.1/rules/lib/builtins/Target)s; default is `[]`  List of targets for additional lookup information. These are expanded as follows: A target with a single file in `DefaultInfo.files` expands to that file. Other targets expand to their `DefaultInfo.executable` file if set and if `--incompatible_locations_prefers_executable` is enabled, otherwise they expand to `DefaultInfo.files`. |
 
 May return `None`.
 
@@ -175,7 +175,7 @@ May return `None`.
 string ctx.expand_make_variables(attribute_name, command, additional_substitutions)
 ```
 
-**Deprecated.** Use [ctx.var](../builtins/ctx#var) to access the variables instead.
+**Deprecated.** Use [ctx.var](/versions/8.3.1/rules/lib/builtins/ctx#var) to access the variables instead.
 Returns a string after expanding all references to "Make variables". The variables must have the following format: `$(VAR_NAME)`. Also, `$$VAR_NAME` expands to `$VAR_NAME`. Examples:
 
 ```
@@ -189,9 +189,9 @@ Additional variables may come from other places, such as configurations. Note th
 
 | Parameter | Description |
 | --- | --- |
-| `attribute_name` | [string](../core/string); required |
-| `command` | [string](../core/string); required  The expression to expand. It can contain references to "Make variables". |
-| `additional_substitutions` | [dict](../core/dict); required  Additional substitutions to make beyond the default make variables. |
+| `attribute_name` | [string](/versions/8.3.1/rules/lib/core/string); required |
+| `command` | [string](/versions/8.3.1/rules/lib/core/string); required  The expression to expand. It can contain references to "Make variables". |
+| `additional_substitutions` | [dict](/versions/8.3.1/rules/lib/core/dict); required  Additional substitutions to make beyond the default make variables. |
 
 ## features
 
@@ -207,7 +207,7 @@ The set of features that are explicitly enabled by the user for this rule. [See
 struct ctx.file
 ```
 
-A `struct` containing files defined in [label type attributes](../toplevel/attr#label) marked as [`allow_single_file`](../toplevel/attr#label.allow_single_file). The struct fields correspond to the attribute names. The struct value is always a [`File`](../builtins/File) or `None`. If an optional attribute is not specified in the rule then the corresponding struct value is `None`. If a label type is not marked as `allow_single_file`, no corresponding struct field is generated. It is a shortcut for:
+A `struct` containing files defined in [label type attributes](/versions/8.3.1/rules/lib/toplevel/attr#label) marked as [`allow_single_file`](/versions/8.3.1/rules/lib/toplevel/attr#label.allow_single_file). The struct fields correspond to the attribute names. The struct value is always a [`File`](/versions/8.3.1/rules/lib/builtins/File) or `None`. If an optional attribute is not specified in the rule then the corresponding struct value is `None`. If a label type is not marked as `allow_single_file`, no corresponding struct field is generated. It is a shortcut for:
 
 ```
 list(ctx.attr..files)[0]
@@ -221,7 +221,7 @@ In other words, use `file` to access the (singular) [default output](https://baz
 struct ctx.files
 ```
 
-A `struct` containing files defined in [label](../toplevel/attr#label) or [label list](../toplevel/attr#label_list) type attributes. The struct fields correspond to the attribute names. The struct values are `list` of [`File`](../builtins/File)s. It is a shortcut for:
+A `struct` containing files defined in [label](/versions/8.3.1/rules/lib/toplevel/attr#label) or [label list](/versions/8.3.1/rules/lib/toplevel/attr#label_list) type attributes. The struct fields correspond to the attribute names. The struct values are `list` of [`File`](/versions/8.3.1/rules/lib/builtins/File)s. It is a shortcut for:
 
 ```
 [f for t in ctx.attr. for f in t.files]
@@ -267,13 +267,13 @@ The label of the target currently being analyzed.
 structure ctx.outputs
 ```
 
-A pseudo-struct containing all the predeclared output files, represented by [`File`](../builtins/File) objects. See the [Rules page](https://bazel.build/versions/8.3.1/extending/rules#files) for more information and examples.
+A pseudo-struct containing all the predeclared output files, represented by [`File`](/versions/8.3.1/rules/lib/builtins/File) objects. See the [Rules page](https://bazel.build/versions/8.3.1/extending/rules#files) for more information and examples.
 
 This field does not exist on aspect contexts, since aspects do not have predeclared outputs.
 
 The fields of this object are defined as follows. It is an error if two outputs produce the same field name or have the same label.
 
-* If the rule declares an [`outputs`](../globals/bzl#rule.outputs) dict, then for every entry in the dict, there is a field whose name is the key and whose value is the corresponding `File`.* For every attribute of type [`attr.output`](../toplevel/attr#output) that the rule declares, there is a field whose name is the attribute's name. If the target specified a label for that attribute, then the field value is the corresponding `File`; otherwise the field value is `None`.* For every attribute of type [`attr.output_list`](../toplevel/attr#output_list) that the rule declares, there is a field whose name is the attribute's name. The field value is a list of `File` objects corresponding to the labels given for that attribute in the target, or an empty list if the attribute was not specified in the target.* **(Deprecated)** If the rule is marked [`executable`](../globals/bzl#rule.executable) or [`test`](../globals/bzl#rule.test), there is a field named `"executable"`, which is the default executable. It is recommended that instead of using this, you pass another file (either predeclared or not) to the `executable` arg of [`DefaultInfo`](../providers/DefaultInfo).
+* If the rule declares an [`outputs`](/versions/8.3.1/rules/lib/globals/bzl#rule.outputs) dict, then for every entry in the dict, there is a field whose name is the key and whose value is the corresponding `File`.* For every attribute of type [`attr.output`](/versions/8.3.1/rules/lib/toplevel/attr#output) that the rule declares, there is a field whose name is the attribute's name. If the target specified a label for that attribute, then the field value is the corresponding `File`; otherwise the field value is `None`.* For every attribute of type [`attr.output_list`](/versions/8.3.1/rules/lib/toplevel/attr#output_list) that the rule declares, there is a field whose name is the attribute's name. The field value is a list of `File` objects corresponding to the labels given for that attribute in the target, or an empty list if the attribute was not specified in the target.* **(Deprecated)** If the rule is marked [`executable`](/versions/8.3.1/rules/lib/globals/bzl#rule.executable) or [`test`](/versions/8.3.1/rules/lib/globals/bzl#rule.test), there is a field named `"executable"`, which is the default executable. It is recommended that instead of using this, you pass another file (either predeclared or not) to the `executable` arg of [`DefaultInfo`](/versions/8.3.1/rules/lib/providers/DefaultInfo).
 
 ## resolve\_command
 
@@ -288,13 +288,13 @@ tuple ctx.resolve_command(command='', attribute=None, expand_locations=False, ma
 
 | Parameter | Description |
 | --- | --- |
-| `command` | [string](../core/string); default is `''`  Command to resolve. |
-| `attribute` | [string](../core/string); or `None`; default is `None`  Name of the associated attribute for which to issue an error, or None. |
-| `expand_locations` | [bool](../core/bool); default is `False`  Shall we expand $(location) variables? See [ctx.expand\_location()](#expand_location) for more details. |
-| `make_variables` | [dict](../core/dict); or `None`; default is `None`  Make variables to expand, or None. |
-| `tools` | [sequence](../core/list) of [Target](../builtins/Target)s; default is `[]`  List of tools (list of targets). |
-| `label_dict` | [dict](../core/dict); default is `{}`  Dictionary of resolved labels and the corresponding list of Files (a dict of Label : list of Files). |
-| `execution_requirements` | [dict](../core/dict); default is `{}`  Information for scheduling the action to resolve this command. See [tags](/versions/8.3.1/reference/be/common-definitions#common.tags) for useful keys. |
+| `command` | [string](/versions/8.3.1/rules/lib/core/string); default is `''`  Command to resolve. |
+| `attribute` | [string](/versions/8.3.1/rules/lib/core/string); or `None`; default is `None`  Name of the associated attribute for which to issue an error, or None. |
+| `expand_locations` | [bool](/versions/8.3.1/rules/lib/core/bool); default is `False`  Shall we expand $(location) variables? See [ctx.expand\_location()](#expand_location) for more details. |
+| `make_variables` | [dict](/versions/8.3.1/rules/lib/core/dict); or `None`; default is `None`  Make variables to expand, or None. |
+| `tools` | [sequence](/versions/8.3.1/rules/lib/core/list) of [Target](/versions/8.3.1/rules/lib/builtins/Target)s; default is `[]`  List of tools (list of targets). |
+| `label_dict` | [dict](/versions/8.3.1/rules/lib/core/dict); default is `{}`  Dictionary of resolved labels and the corresponding list of Files (a dict of Label : list of Files). |
+| `execution_requirements` | [dict](/versions/8.3.1/rules/lib/core/dict); default is `{}`  Information for scheduling the action to resolve this command. See [tags](/versions/8.3.1/reference/be/common-definitions#common.tags) for useful keys. |
 
 ## resolve\_tools
 
@@ -310,7 +310,7 @@ In contrast to `ctx.resolve_command`, this method does not require that Bash be
 
 | Parameter | Description |
 | --- | --- |
-| `tools` | [sequence](../core/list) of [Target](../builtins/Target)s; default is `[]`  List of tools (list of targets). |
+| `tools` | [sequence](/versions/8.3.1/rules/lib/core/list) of [Target](/versions/8.3.1/rules/lib/builtins/Target)s; default is `[]`  List of tools (list of targets). |
 
 ## rule
 
@@ -332,12 +332,12 @@ Creates a runfiles object.
 
 | Parameter | Description |
 | --- | --- |
-| `files` | [sequence](../core/list) of [File](../builtins/File)s; default is `[]`  The list of files to be added to the runfiles. |
-| `transitive_files` | [depset](../builtins/depset) of [File](../builtins/File)s; or `None`; default is `None`  The (transitive) set of files to be added to the runfiles. The depset should use the `default` order (which, as the name implies, is the default). |
-| `collect_data` | [bool](../core/bool); default is `False`  **Use of this parameter is not recommended. See [runfiles guide](https://bazel.build/versions/8.3.1/extending/rules#runfiles)**. Whether to collect the data runfiles from the dependencies in srcs, data and deps attributes. |
-| `collect_default` | [bool](../core/bool); default is `False`  **Use of this parameter is not recommended. See [runfiles guide](https://bazel.build/versions/8.3.1/extending/rules#runfiles)**. Whether to collect the default runfiles from the dependencies in srcs, data and deps attributes. |
-| `symlinks` | [dict](../core/dict); or [depset](../builtins/depset) of [SymlinkEntry](../builtins/SymlinkEntry)s; default is `{}`  Either a SymlinkEntry depset or the map of symlinks to be added to the runfiles. Symlinks are always added under the main workspace's runfiles directory (e.g. `/_main/`, **not** the directory corresponding to the current target's repository. See [Runfiles symlinks](https://bazel.build/versions/8.3.1/extending/rules#runfiles_symlinks) in the rules guide. |
-| `root_symlinks` | [dict](../core/dict); or [depset](../builtins/depset) of [SymlinkEntry](../builtins/SymlinkEntry)s; default is `{}`  Either a SymlinkEntry depset or a map of symlinks to be added to the runfiles. See [Runfiles symlinks](https://bazel.build/versions/8.3.1/extending/rules#runfiles_symlinks) in the rules guide. |
+| `files` | [sequence](/versions/8.3.1/rules/lib/core/list) of [File](/versions/8.3.1/rules/lib/builtins/File)s; default is `[]`  The list of files to be added to the runfiles. |
+| `transitive_files` | [depset](/versions/8.3.1/rules/lib/builtins/depset) of [File](/versions/8.3.1/rules/lib/builtins/File)s; or `None`; default is `None`  The (transitive) set of files to be added to the runfiles. The depset should use the `default` order (which, as the name implies, is the default). |
+| `collect_data` | [bool](/versions/8.3.1/rules/lib/core/bool); default is `False`  **Use of this parameter is not recommended. See [runfiles guide](https://bazel.build/versions/8.3.1/extending/rules#runfiles)**. Whether to collect the data runfiles from the dependencies in srcs, data and deps attributes. |
+| `collect_default` | [bool](/versions/8.3.1/rules/lib/core/bool); default is `False`  **Use of this parameter is not recommended. See [runfiles guide](https://bazel.build/versions/8.3.1/extending/rules#runfiles)**. Whether to collect the default runfiles from the dependencies in srcs, data and deps attributes. |
+| `symlinks` | [dict](/versions/8.3.1/rules/lib/core/dict); or [depset](/versions/8.3.1/rules/lib/builtins/depset) of [SymlinkEntry](/versions/8.3.1/rules/lib/builtins/SymlinkEntry)s; default is `{}`  Either a SymlinkEntry depset or the map of symlinks to be added to the runfiles. Symlinks are always added under the main workspace's runfiles directory (e.g. `/_main/`, **not** the directory corresponding to the current target's repository. See [Runfiles symlinks](https://bazel.build/versions/8.3.1/extending/rules#runfiles_symlinks) in the rules guide. |
+| `root_symlinks` | [dict](/versions/8.3.1/rules/lib/core/dict); or [depset](/versions/8.3.1/rules/lib/builtins/depset) of [SymlinkEntry](/versions/8.3.1/rules/lib/builtins/SymlinkEntry)s; default is `{}`  Either a SymlinkEntry depset or a map of symlinks to be added to the runfiles. See [Runfiles symlinks](https://bazel.build/versions/8.3.1/extending/rules#runfiles_symlinks) in the rules guide. |
 
 ## split\_attr
 
@@ -367,7 +367,7 @@ Returns true if the given constraint value is part of the current target platfor
 
 | Parameter | Description |
 | --- | --- |
-| `constraintValue` | [ConstraintValueInfo](../providers/ConstraintValueInfo); required  The constraint value to check the target platform against. |
+| `constraintValue` | [ConstraintValueInfo](/versions/8.3.1/rules/lib/providers/ConstraintValueInfo); required  The constraint value to check the target platform against. |
 
 ## toolchains
 
diff --git a/versions/8.3.1/rules/lib/builtins/depset.mdx b/versions/8.3.1/rules/lib/builtins/depset.mdx
index 52667469..f433525a 100644
--- a/versions/8.3.1/rules/lib/builtins/depset.mdx
+++ b/versions/8.3.1/rules/lib/builtins/depset.mdx
@@ -6,7 +6,7 @@ A specialized data structure that supports efficient merge operations and has a
 
 The elements of a depset must be hashable and all of the same type (as defined by the built-in type(x) function), but depsets are not simply hash sets and do not support fast membership tests. If you need a general set datatype, you can simulate one using a dictionary where all keys map to `True`.
 
-Depsets are immutable. They should be created using their [constructor function](../globals/bzl#depset) and merged or augmented with other depsets via the `transitive` argument.
+Depsets are immutable. They should be created using their [constructor function](/versions/8.3.1/rules/lib/globals/bzl#depset) and merged or augmented with other depsets via the `transitive` argument.
 
 The `order` parameter determines the kind of traversal that is done to convert the depset to an iterable. There are four possible values:
 
diff --git a/versions/8.3.1/rules/lib/builtins/fragments.mdx b/versions/8.3.1/rules/lib/builtins/fragments.mdx
index 7fe935fc..1703ce3d 100644
--- a/versions/8.3.1/rules/lib/builtins/fragments.mdx
+++ b/versions/8.3.1/rules/lib/builtins/fragments.mdx
@@ -6,4 +6,4 @@ A collection of configuration fragments available in the current rule implementa
 
 Only configuration fragments which are declared in the rule definition may be accessed in this collection.
 
-See the [configuration fragment reference](../fragments) for a list of available fragments and the [rules documentation](https://bazel.build/versions/8.3.1/extending/rules#configuration_fragments) for how to use them.
\ No newline at end of file
+See the [configuration fragment reference](/versions/8.3.1/rules/lib/fragments) for a list of available fragments and the [rules documentation](https://bazel.build/versions/8.3.1/extending/rules#configuration_fragments) for how to use them.
\ No newline at end of file
diff --git a/versions/8.3.1/rules/lib/builtins/macro.mdx b/versions/8.3.1/rules/lib/builtins/macro.mdx
index 464806a9..3c11dcd4 100644
--- a/versions/8.3.1/rules/lib/builtins/macro.mdx
+++ b/versions/8.3.1/rules/lib/builtins/macro.mdx
@@ -3,7 +3,7 @@ title: 'macro'
 ---
 
 A callable Starlark value representing a symbolic macro; in other words, the return value of
-[`macro()`](../globals/bzl#macro). Invoking this value during package
+[`macro()`](/versions/8.3.1/rules/lib/globals/bzl#macro). Invoking this value during package
 construction time will instantiate the macro, and cause the macro's implementation function to be
 evaluated (in a separate context, different from the context in which the macro value was invoked),
 in most cases causing targets to be added to the package's target set. For more information, see
diff --git a/versions/8.3.1/rules/lib/builtins/module_ctx.mdx b/versions/8.3.1/rules/lib/builtins/module_ctx.mdx
index 42248e13..fb9787d0 100644
--- a/versions/8.3.1/rules/lib/builtins/module_ctx.mdx
+++ b/versions/8.3.1/rules/lib/builtins/module_ctx.mdx
@@ -35,16 +35,16 @@ Downloads a file to the output path for the provided url and returns a struct co
 
 | Parameter | Description |
 | --- | --- |
-| `url` | [string](../core/string); or Iterable of [string](../core/string)s; required  List of mirror URLs referencing the same file. |
-| `output` | [string](../core/string); or [Label](../builtins/Label); or [path](../builtins/path); default is `''`  path to the output file, relative to the repository directory. |
-| `sha256` | [string](../core/string); default is `''`  The expected SHA-256 hash of the file downloaded. This must match the SHA-256 hash of the file downloaded. It is a security risk to omit the SHA-256 as remote files can change. At best omitting this field will make your build non-hermetic. It is optional to make development easier but should be set before shipping. If provided, the repository cache will first be checked for a file with the given hash; a download will only be attempted if the file was not found in the cache. After a successful download, the file will be added to the cache. |
-| `executable` | [bool](../core/bool); default is `False`  Set the executable flag on the created file, false by default. |
-| `allow_fail` | [bool](../core/bool); default is `False`  If set, indicate the error in the return value instead of raising an error for failed downloads. |
-| `canonical_id` | [string](../core/string); default is `''`  If set, restrict cache hits to those cases where the file was added to the cache with the same canonical id. By default caching uses the checksum (`sha256` or `integrity`). |
-| `auth` | [dict](../core/dict); default is `{}`  An optional dict specifying authentication information for some of the URLs. |
-| `headers` | [dict](../core/dict); default is `{}`  An optional dict specifying http headers for all URLs. |
-| `integrity` | [string](../core/string); default is `''`  Expected checksum of the file downloaded, in Subresource Integrity format. This must match the checksum of the file downloaded. It is a security risk to omit the checksum as remote files can change. At best omitting this field will make your build non-hermetic. It is optional to make development easier but should be set before shipping. If provided, the repository cache will first be checked for a file with the given checksum; a download will only be attempted if the file was not found in the cache. After a successful download, the file will be added to the cache. |
-| `block` | [bool](../core/bool); default is `True`  If set to false, the call returns immediately and instead of the regular return value, it returns a token with one single method, wait(), which blocks until the download is finished and returns the usual return value or throws as usual. |
+| `url` | [string](/versions/8.3.1/rules/lib/core/string); or Iterable of [string](/versions/8.3.1/rules/lib/core/string)s; required  List of mirror URLs referencing the same file. |
+| `output` | [string](/versions/8.3.1/rules/lib/core/string); or [Label](/versions/8.3.1/rules/lib/builtins/Label); or [path](/versions/8.3.1/rules/lib/builtins/path); default is `''`  path to the output file, relative to the repository directory. |
+| `sha256` | [string](/versions/8.3.1/rules/lib/core/string); default is `''`  The expected SHA-256 hash of the file downloaded. This must match the SHA-256 hash of the file downloaded. It is a security risk to omit the SHA-256 as remote files can change. At best omitting this field will make your build non-hermetic. It is optional to make development easier but should be set before shipping. If provided, the repository cache will first be checked for a file with the given hash; a download will only be attempted if the file was not found in the cache. After a successful download, the file will be added to the cache. |
+| `executable` | [bool](/versions/8.3.1/rules/lib/core/bool); default is `False`  Set the executable flag on the created file, false by default. |
+| `allow_fail` | [bool](/versions/8.3.1/rules/lib/core/bool); default is `False`  If set, indicate the error in the return value instead of raising an error for failed downloads. |
+| `canonical_id` | [string](/versions/8.3.1/rules/lib/core/string); default is `''`  If set, restrict cache hits to those cases where the file was added to the cache with the same canonical id. By default caching uses the checksum (`sha256` or `integrity`). |
+| `auth` | [dict](/versions/8.3.1/rules/lib/core/dict); default is `{}`  An optional dict specifying authentication information for some of the URLs. |
+| `headers` | [dict](/versions/8.3.1/rules/lib/core/dict); default is `{}`  An optional dict specifying http headers for all URLs. |
+| `integrity` | [string](/versions/8.3.1/rules/lib/core/string); default is `''`  Expected checksum of the file downloaded, in Subresource Integrity format. This must match the checksum of the file downloaded. It is a security risk to omit the checksum as remote files can change. At best omitting this field will make your build non-hermetic. It is optional to make development easier but should be set before shipping. If provided, the repository cache will first be checked for a file with the given checksum; a download will only be attempted if the file was not found in the cache. After a successful download, the file will be added to the cache. |
+| `block` | [bool](/versions/8.3.1/rules/lib/core/bool); default is `True`  If set to false, the call returns immediately and instead of the regular return value, it returns a token with one single method, wait(), which blocks until the download is finished and returns the usual return value or throws as usual. |
 
 ## download\_and\_extract
 
@@ -58,17 +58,17 @@ Downloads a file to the output path for the provided url, extracts it, and retur
 
 | Parameter | Description |
 | --- | --- |
-| `url` | [string](../core/string); or Iterable of [string](../core/string)s; required  List of mirror URLs referencing the same file. |
-| `output` | [string](../core/string); or [Label](../builtins/Label); or [path](../builtins/path); default is `''`  Path to the directory where the archive will be unpacked, relative to the repository directory. |
-| `sha256` | [string](../core/string); default is `''`  The expected SHA-256 hash of the file downloaded. This must match the SHA-256 hash of the file downloaded. It is a security risk to omit the SHA-256 as remote files can change. At best omitting this field will make your build non-hermetic. It is optional to make development easier but should be set before shipping. If provided, the repository cache will first be checked for a file with the given hash; a download will only be attempted if the file was not found in the cache. After a successful download, the file will be added to the cache. |
-| `type` | [string](../core/string); default is `''`  The archive type of the downloaded file. By default, the archive type is determined from the file extension of the URL. If the file has no extension, you can explicitly specify either "zip", "jar", "war", "aar", "nupkg", "whl", "tar", "tar.gz", "tgz", "tar.xz", "txz", ".tar.zst", ".tzst", "tar.bz2", ".tbz", ".ar", or ".deb" here. |
-| `strip_prefix` | [string](../core/string); default is `''`  A directory prefix to strip from the extracted files. Many archives contain a top-level directory that contains all files in the archive. Instead of needing to specify this prefix over and over in the `build_file`, this field can be used to strip it from extracted files. For compatibility, this parameter may also be used under the deprecated name `stripPrefix`. |
-| `allow_fail` | [bool](../core/bool); default is `False`  If set, indicate the error in the return value instead of raising an error for failed downloads. |
-| `canonical_id` | [string](../core/string); default is `''`  If set, restrict cache hits to those cases where the file was added to the cache with the same canonical id. By default caching uses the checksum" (`sha256` or `integrity`). |
-| `auth` | [dict](../core/dict); default is `{}`  An optional dict specifying authentication information for some of the URLs. |
-| `headers` | [dict](../core/dict); default is `{}`  An optional dict specifying http headers for all URLs. |
-| `integrity` | [string](../core/string); default is `''`  Expected checksum of the file downloaded, in Subresource Integrity format. This must match the checksum of the file downloaded. It is a security risk to omit the checksum as remote files can change. At best omitting this field will make your build non-hermetic. It is optional to make development easier but should be set before shipping. If provided, the repository cache will first be checked for a file with the given checksum; a download will only be attempted if the file was not found in the cache. After a successful download, the file will be added to the cache. |
-| `rename_files` | [dict](../core/dict); default is `{}`  An optional dict specifying files to rename during the extraction. Archive entries with names exactly matching a key will be renamed to the value, prior to any directory prefix adjustment. This can be used to extract archives that contain non-Unicode filenames, or which have files that would extract to the same path on case-insensitive filesystems. |
+| `url` | [string](/versions/8.3.1/rules/lib/core/string); or Iterable of [string](/versions/8.3.1/rules/lib/core/string)s; required  List of mirror URLs referencing the same file. |
+| `output` | [string](/versions/8.3.1/rules/lib/core/string); or [Label](/versions/8.3.1/rules/lib/builtins/Label); or [path](/versions/8.3.1/rules/lib/builtins/path); default is `''`  Path to the directory where the archive will be unpacked, relative to the repository directory. |
+| `sha256` | [string](/versions/8.3.1/rules/lib/core/string); default is `''`  The expected SHA-256 hash of the file downloaded. This must match the SHA-256 hash of the file downloaded. It is a security risk to omit the SHA-256 as remote files can change. At best omitting this field will make your build non-hermetic. It is optional to make development easier but should be set before shipping. If provided, the repository cache will first be checked for a file with the given hash; a download will only be attempted if the file was not found in the cache. After a successful download, the file will be added to the cache. |
+| `type` | [string](/versions/8.3.1/rules/lib/core/string); default is `''`  The archive type of the downloaded file. By default, the archive type is determined from the file extension of the URL. If the file has no extension, you can explicitly specify either "zip", "jar", "war", "aar", "nupkg", "whl", "tar", "tar.gz", "tgz", "tar.xz", "txz", ".tar.zst", ".tzst", "tar.bz2", ".tbz", ".ar", or ".deb" here. |
+| `strip_prefix` | [string](/versions/8.3.1/rules/lib/core/string); default is `''`  A directory prefix to strip from the extracted files. Many archives contain a top-level directory that contains all files in the archive. Instead of needing to specify this prefix over and over in the `build_file`, this field can be used to strip it from extracted files. For compatibility, this parameter may also be used under the deprecated name `stripPrefix`. |
+| `allow_fail` | [bool](/versions/8.3.1/rules/lib/core/bool); default is `False`  If set, indicate the error in the return value instead of raising an error for failed downloads. |
+| `canonical_id` | [string](/versions/8.3.1/rules/lib/core/string); default is `''`  If set, restrict cache hits to those cases where the file was added to the cache with the same canonical id. By default caching uses the checksum" (`sha256` or `integrity`). |
+| `auth` | [dict](/versions/8.3.1/rules/lib/core/dict); default is `{}`  An optional dict specifying authentication information for some of the URLs. |
+| `headers` | [dict](/versions/8.3.1/rules/lib/core/dict); default is `{}`  An optional dict specifying http headers for all URLs. |
+| `integrity` | [string](/versions/8.3.1/rules/lib/core/string); default is `''`  Expected checksum of the file downloaded, in Subresource Integrity format. This must match the checksum of the file downloaded. It is a security risk to omit the checksum as remote files can change. At best omitting this field will make your build non-hermetic. It is optional to make development easier but should be set before shipping. If provided, the repository cache will first be checked for a file with the given checksum; a download will only be attempted if the file was not found in the cache. After a successful download, the file will be added to the cache. |
+| `rename_files` | [dict](/versions/8.3.1/rules/lib/core/dict); default is `{}`  An optional dict specifying files to rename during the extraction. Archive entries with names exactly matching a key will be renamed to the value, prior to any directory prefix adjustment. This can be used to extract archives that contain non-Unicode filenames, or which have files that would extract to the same path on case-insensitive filesystems. |
 
 ## execute
 
@@ -82,11 +82,11 @@ Executes the command given by the list of arguments. The execution time of the c
 
 | Parameter | Description |
 | --- | --- |
-| `arguments` | [sequence](../core/list); required  List of arguments, the first element should be the path to the program to execute. |
-| `timeout` | [int](../core/int); default is `600`  Maximum duration of the command in seconds (default is 600 seconds). |
-| `environment` | [dict](../core/dict); default is `{}`  Force some environment variables to be set to be passed to the process. The value can be `None` to remove the environment variable. |
-| `quiet` | [bool](../core/bool); default is `True`  If stdout and stderr should be printed to the terminal. |
-| `working_directory` | [string](../core/string); default is `""`  Working directory for command execution. Can be relative to the repository root or absolute. The default is the repository root. |
+| `arguments` | [sequence](/versions/8.3.1/rules/lib/core/list); required  List of arguments, the first element should be the path to the program to execute. |
+| `timeout` | [int](/versions/8.3.1/rules/lib/core/int); default is `600`  Maximum duration of the command in seconds (default is 600 seconds). |
+| `environment` | [dict](/versions/8.3.1/rules/lib/core/dict); default is `{}`  Force some environment variables to be set to be passed to the process. The value can be `None` to remove the environment variable. |
+| `quiet` | [bool](/versions/8.3.1/rules/lib/core/bool); default is `True`  If stdout and stderr should be printed to the terminal. |
+| `working_directory` | [string](/versions/8.3.1/rules/lib/core/string); default is `""`  Working directory for command execution. Can be relative to the repository root or absolute. The default is the repository root. |
 
 ## extension\_metadata
 
@@ -100,9 +100,9 @@ Constructs an opaque object that can be returned from the module extension's imp
 
 | Parameter | Description |
 | --- | --- |
-| `root_module_direct_deps` | [sequence](../core/list) of [string](../core/string)s; or [string](../core/string); or `None`; default is `None`  The names of the repositories that the extension considers to be direct dependencies of the root module. If the root module imports additional repositories or does not import all of these repositories via [`use_repo`](../globals/module#use_repo), Bazel will print a warning when the extension is evaluated, instructing the user to run `bazel mod tidy` to fix the `use_repo` calls automatically. If one of `root_module_direct_deps` and will print a warning and a fixup command when the extension is evaluated. If one of `root_module_direct_deps` and `root_module_direct_dev_deps` is specified, the other has to be as well. The lists specified by these two parameters must be disjoint. Exactly one of `root_module_direct_deps` and `root_module_direct_dev_deps` can be set to the special value `"all"`, which is treated as if a list with the names of all repositories generated by the extension was specified as the value. |
-| `root_module_direct_dev_deps` | [sequence](../core/list) of [string](../core/string)s; or [string](../core/string); or `None`; default is `None`  The names of the repositories that the extension considers to be direct dev dependencies of the root module. If the root module imports additional repositories or does not import all of these repositories via [`use_repo`](../globals/module#use_repo) on an extension proxy created with `use_extension(..., dev_dependency = True)`, Bazel will print a warning when the extension is evaluated, instructing the user to run `bazel mod tidy` to fix the `use_repo` calls automatically. If one of `root_module_direct_deps` and `root_module_direct_dev_deps` is specified, the other has to be as well. The lists specified by these two parameters must be disjoint. Exactly one of `root_module_direct_deps` and `root_module_direct_dev_deps` can be set to the special value `"all"`, which is treated as if a list with the names of all repositories generated by the extension was specified as the value. |
-| `reproducible` | [bool](../core/bool); default is `False`  States that this module extension ensures complete reproducibility, thereby it should not be stored in the lockfile. |
+| `root_module_direct_deps` | [sequence](/versions/8.3.1/rules/lib/core/list) of [string](/versions/8.3.1/rules/lib/core/string)s; or [string](/versions/8.3.1/rules/lib/core/string); or `None`; default is `None`  The names of the repositories that the extension considers to be direct dependencies of the root module. If the root module imports additional repositories or does not import all of these repositories via [`use_repo`](/versions/8.3.1/rules/lib/globals/module#use_repo), Bazel will print a warning when the extension is evaluated, instructing the user to run `bazel mod tidy` to fix the `use_repo` calls automatically. If one of `root_module_direct_deps` and will print a warning and a fixup command when the extension is evaluated. If one of `root_module_direct_deps` and `root_module_direct_dev_deps` is specified, the other has to be as well. The lists specified by these two parameters must be disjoint. Exactly one of `root_module_direct_deps` and `root_module_direct_dev_deps` can be set to the special value `"all"`, which is treated as if a list with the names of all repositories generated by the extension was specified as the value. |
+| `root_module_direct_dev_deps` | [sequence](/versions/8.3.1/rules/lib/core/list) of [string](/versions/8.3.1/rules/lib/core/string)s; or [string](/versions/8.3.1/rules/lib/core/string); or `None`; default is `None`  The names of the repositories that the extension considers to be direct dev dependencies of the root module. If the root module imports additional repositories or does not import all of these repositories via [`use_repo`](/versions/8.3.1/rules/lib/globals/module#use_repo) on an extension proxy created with `use_extension(..., dev_dependency = True)`, Bazel will print a warning when the extension is evaluated, instructing the user to run `bazel mod tidy` to fix the `use_repo` calls automatically. If one of `root_module_direct_deps` and `root_module_direct_dev_deps` is specified, the other has to be as well. The lists specified by these two parameters must be disjoint. Exactly one of `root_module_direct_deps` and `root_module_direct_dev_deps` can be set to the special value `"all"`, which is treated as if a list with the names of all repositories generated by the extension was specified as the value. |
+| `reproducible` | [bool](/versions/8.3.1/rules/lib/core/bool); default is `False`  States that this module extension ensures complete reproducibility, thereby it should not be stored in the lockfile. |
 
 ## extract
 
@@ -116,11 +116,11 @@ Extract an archive to the repository directory.
 
 | Parameter | Description |
 | --- | --- |
-| `archive` | [string](../core/string); or [Label](../builtins/Label); or [path](../builtins/path); required  path to the archive that will be unpacked, relative to the repository directory. |
-| `output` | [string](../core/string); or [Label](../builtins/Label); or [path](../builtins/path); default is `''`  path to the directory where the archive will be unpacked, relative to the repository directory. |
-| `strip_prefix` | [string](../core/string); default is `''`  a directory prefix to strip from the extracted files. Many archives contain a top-level directory that contains all files in the archive. Instead of needing to specify this prefix over and over in the `build_file`, this field can be used to strip it from extracted files. For compatibility, this parameter may also be used under the deprecated name `stripPrefix`. |
-| `rename_files` | [dict](../core/dict); default is `{}`  An optional dict specifying files to rename during the extraction. Archive entries with names exactly matching a key will be renamed to the value, prior to any directory prefix adjustment. This can be used to extract archives that contain non-Unicode filenames, or which have files that would extract to the same path on case-insensitive filesystems. |
-| `watch_archive` | [string](../core/string); default is `'auto'`  whether to [watch](#watch) the archive file. Can be the string 'yes', 'no', or 'auto'. Passing 'yes' is equivalent to immediately invoking the [`watch()`](#watch) method; passing 'no' does not attempt to watch the file; passing 'auto' will only attempt to watch the file when it is legal to do so (see `watch()` docs for more information. |
+| `archive` | [string](/versions/8.3.1/rules/lib/core/string); or [Label](/versions/8.3.1/rules/lib/builtins/Label); or [path](/versions/8.3.1/rules/lib/builtins/path); required  path to the archive that will be unpacked, relative to the repository directory. |
+| `output` | [string](/versions/8.3.1/rules/lib/core/string); or [Label](/versions/8.3.1/rules/lib/builtins/Label); or [path](/versions/8.3.1/rules/lib/builtins/path); default is `''`  path to the directory where the archive will be unpacked, relative to the repository directory. |
+| `strip_prefix` | [string](/versions/8.3.1/rules/lib/core/string); default is `''`  a directory prefix to strip from the extracted files. Many archives contain a top-level directory that contains all files in the archive. Instead of needing to specify this prefix over and over in the `build_file`, this field can be used to strip it from extracted files. For compatibility, this parameter may also be used under the deprecated name `stripPrefix`. |
+| `rename_files` | [dict](/versions/8.3.1/rules/lib/core/dict); default is `{}`  An optional dict specifying files to rename during the extraction. Archive entries with names exactly matching a key will be renamed to the value, prior to any directory prefix adjustment. This can be used to extract archives that contain non-Unicode filenames, or which have files that would extract to the same path on case-insensitive filesystems. |
+| `watch_archive` | [string](/versions/8.3.1/rules/lib/core/string); default is `'auto'`  whether to [watch](#watch) the archive file. Can be the string 'yes', 'no', or 'auto'. Passing 'yes' is equivalent to immediately invoking the [`watch()`](#watch) method; passing 'no' does not attempt to watch the file; passing 'auto' will only attempt to watch the file when it is legal to do so (see `watch()` docs for more information. |
 
 ## file
 
@@ -134,10 +134,10 @@ Generates a file in the repository directory with the provided content.
 
 | Parameter | Description |
 | --- | --- |
-| `path` | [string](../core/string); or [Label](../builtins/Label); or [path](../builtins/path); required  Path of the file to create, relative to the repository directory. |
-| `content` | [string](../core/string); default is `''`  The content of the file to create, empty by default. |
-| `executable` | [bool](../core/bool); default is `True`  Set the executable flag on the created file, true by default. |
-| `legacy_utf8` | [bool](../core/bool); default is `False`  No-op. This parameter is deprecated and will be removed in a future version of Bazel. |
+| `path` | [string](/versions/8.3.1/rules/lib/core/string); or [Label](/versions/8.3.1/rules/lib/builtins/Label); or [path](/versions/8.3.1/rules/lib/builtins/path); required  Path of the file to create, relative to the repository directory. |
+| `content` | [string](/versions/8.3.1/rules/lib/core/string); default is `''`  The content of the file to create, empty by default. |
+| `executable` | [bool](/versions/8.3.1/rules/lib/core/bool); default is `True`  Set the executable flag on the created file, true by default. |
+| `legacy_utf8` | [bool](/versions/8.3.1/rules/lib/core/bool); default is `False`  No-op. This parameter is deprecated and will be removed in a future version of Bazel. |
 
 ## getenv
 
@@ -153,8 +153,8 @@ When building incrementally, any change to the value of the variable named by `n
 
 | Parameter | Description |
 | --- | --- |
-| `name` | [string](../core/string); required  Name of desired environment variable. |
-| `default` | [string](../core/string); or `None`; default is `None`  Default value to return if `name` is not found. |
+| `name` | [string](/versions/8.3.1/rules/lib/core/string); required  Name of desired environment variable. |
+| `default` | [string](/versions/8.3.1/rules/lib/core/string); or `None`; default is `None`  Default value to return if `name` is not found. |
 
 May return `None`.
 
@@ -164,13 +164,13 @@ May return `None`.
 bool module_ctx.is_dev_dependency(tag)
 ```
 
-Returns whether the given tag was specified on the result of a [use\_extension](../globals/module#use_extension) call with `devDependency = True`.
+Returns whether the given tag was specified on the result of a [use\_extension](/versions/8.3.1/rules/lib/globals/module#use_extension) call with `devDependency = True`.
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `tag` | bazel\_module\_tag; required  A tag obtained from [bazel\_module.tags](../builtins/bazel_module#tags). |
+| `tag` | bazel\_module\_tag; required  A tag obtained from [bazel\_module.tags](/versions/8.3.1/rules/lib/builtins/bazel_module#tags). |
 
 ## modules
 
@@ -178,7 +178,7 @@ Returns whether the given tag was specified on the result of a [use\_extension](
 list module_ctx.modules
 ```
 
-A list of all the Bazel modules in the external dependency graph that use this module extension, each of which is a [bazel\_module](../builtins/bazel_module) object that exposes all the tags it specified for this extension. The iteration order of this dictionary is guaranteed to be the same as breadth-first search starting from the root module.
+A list of all the Bazel modules in the external dependency graph that use this module extension, each of which is a [bazel\_module](/versions/8.3.1/rules/lib/builtins/bazel_module) object that exposes all the tags it specified for this extension. The iteration order of this dictionary is guaranteed to be the same as breadth-first search starting from the root module.
 
 ## os
 
@@ -200,7 +200,7 @@ Returns a path from a string, label or path. If the path is relative, it will re
 
 | Parameter | Description |
 | --- | --- |
-| `path` | [string](../core/string); or [Label](../builtins/Label); or [path](../builtins/path); required  `string`, `Label` or `path` from which to create a path from. |
+| `path` | [string](/versions/8.3.1/rules/lib/core/string); or [Label](/versions/8.3.1/rules/lib/builtins/Label); or [path](/versions/8.3.1/rules/lib/builtins/path); required  `string`, `Label` or `path` from which to create a path from. |
 
 ## read
 
@@ -214,8 +214,8 @@ Reads the content of a file on the filesystem.
 
 | Parameter | Description |
 | --- | --- |
-| `path` | [string](../core/string); or [Label](../builtins/Label); or [path](../builtins/path); required  Path of the file to read from. |
-| `watch` | [string](../core/string); default is `'auto'`  Whether to [watch](#watch) the file. Can be the string 'yes', 'no', or 'auto'. Passing 'yes' is equivalent to immediately invoking the [`watch()`](#watch) method; passing 'no' does not attempt to watch the file; passing 'auto' will only attempt to watch the file when it is legal to do so (see `watch()` docs for more information. |
+| `path` | [string](/versions/8.3.1/rules/lib/core/string); or [Label](/versions/8.3.1/rules/lib/builtins/Label); or [path](/versions/8.3.1/rules/lib/builtins/path); required  Path of the file to read from. |
+| `watch` | [string](/versions/8.3.1/rules/lib/core/string); default is `'auto'`  Whether to [watch](#watch) the file. Can be the string 'yes', 'no', or 'auto'. Passing 'yes' is equivalent to immediately invoking the [`watch()`](#watch) method; passing 'no' does not attempt to watch the file; passing 'auto' will only attempt to watch the file when it is legal to do so (see `watch()` docs for more information. |
 
 ## report\_progress
 
@@ -229,7 +229,7 @@ Updates the progress status for the fetching of this repository or module extens
 
 | Parameter | Description |
 | --- | --- |
-| `status` | [string](../core/string); default is `''`  `string` describing the current status of the fetch progress. |
+| `status` | [string](/versions/8.3.1/rules/lib/core/string); default is `''`  `string` describing the current status of the fetch progress. |
 
 ## root\_module\_has\_non\_dev\_dependency
 
@@ -247,7 +247,7 @@ None module_ctx.watch(path)
 
 Tells Bazel to watch for changes to the given path, whether or not it exists, or whether it's a file or a directory. Any changes to the file or directory will invalidate this repository or module extension, and cause it to be refetched or re-evaluated next time.
 
-"Changes" include changes to the contents of the file (if the path is a file); if the path was a file but is now a directory, or vice versa; and if the path starts or stops existing. Notably, this does *not* include changes to any files under the directory if the path is a directory. For that, use [`path.readdir()`](path#readdir) instead.
+"Changes" include changes to the contents of the file (if the path is a file); if the path was a file but is now a directory, or vice versa; and if the path starts or stops existing. Notably, this does *not* include changes to any files under the directory if the path is a directory. For that, use [`path.readdir()`](/versions/8.3.1/rules/lib/builtins/path#readdir) instead.
 
 Note that attempting to watch paths inside the repo currently being fetched, or inside the working directory of the current module extension, will result in an error. A module extension attempting to watch a path outside the current Bazel workspace will also result in an error.
 
@@ -255,7 +255,7 @@ Note that attempting to watch paths inside the repo currently being fetched, or
 
 | Parameter | Description |
 | --- | --- |
-| `path` | [string](../core/string); or [Label](../builtins/Label); or [path](../builtins/path); required  Path of the file to watch. |
+| `path` | [string](/versions/8.3.1/rules/lib/core/string); or [Label](/versions/8.3.1/rules/lib/builtins/Label); or [path](/versions/8.3.1/rules/lib/builtins/path); required  Path of the file to watch. |
 
 ## which
 
@@ -269,6 +269,6 @@ Returns the `path` of the corresponding program or `None` if there is no such pr
 
 | Parameter | Description |
 | --- | --- |
-| `program` | [string](../core/string); required  Program to find in the path. |
+| `program` | [string](/versions/8.3.1/rules/lib/core/string); required  Program to find in the path. |
 
 May return `None`.
\ No newline at end of file
diff --git a/versions/8.3.1/rules/lib/builtins/path.mdx b/versions/8.3.1/rules/lib/builtins/path.mdx
index d200110e..709101c3 100644
--- a/versions/8.3.1/rules/lib/builtins/path.mdx
+++ b/versions/8.3.1/rules/lib/builtins/path.mdx
@@ -77,7 +77,7 @@ Returns the list of entries in the directory denoted by this path. Each entry is
 
 | Parameter | Description |
 | --- | --- |
-| `watch` | [string](../core/string); default is `'auto'`  whether Bazel should watch the list of entries in this directory and refetch the repository or re-evaluate the module extension next time when any changes are detected. Changes to detect include entry creation, deletion, and renaming. Note that this doesn't watch the *contents* of any entries in the directory. Can be the string 'yes', 'no', or 'auto'. If set to 'auto', Bazel will only watch this directory when it is legal to do so (see [`repository_ctx.watch()`](repository_ctx#watch) docs for more information). |
+| `watch` | [string](/versions/8.3.1/rules/lib/core/string); default is `'auto'`  whether Bazel should watch the list of entries in this directory and refetch the repository or re-evaluate the module extension next time when any changes are detected. Changes to detect include entry creation, deletion, and renaming. Note that this doesn't watch the *contents* of any entries in the directory. Can be the string 'yes', 'no', or 'auto'. If set to 'auto', Bazel will only watch this directory when it is legal to do so (see [`repository_ctx.watch()`](/versions/8.3.1/rules/lib/builtins/repository_ctx#watch) docs for more information). |
 
 ## realpath
 
diff --git a/versions/8.3.1/rules/lib/builtins/repo_metadata.mdx b/versions/8.3.1/rules/lib/builtins/repo_metadata.mdx
index 0b28cbac..e70b8d8a 100644
--- a/versions/8.3.1/rules/lib/builtins/repo_metadata.mdx
+++ b/versions/8.3.1/rules/lib/builtins/repo_metadata.mdx
@@ -2,4 +2,4 @@
 title: 'repo\_metadata'
 ---
 
-See [`repository_ctx.repo_metadata`](repository_ctx#repo_metadata).
\ No newline at end of file
+See [`repository_ctx.repo_metadata`](/versions/8.3.1/rules/lib/builtins/repository_ctx#repo_metadata).
\ No newline at end of file
diff --git a/versions/8.3.1/rules/lib/builtins/repository_ctx.mdx b/versions/8.3.1/rules/lib/builtins/repository_ctx.mdx
index 37311c96..2a106663 100644
--- a/versions/8.3.1/rules/lib/builtins/repository_ctx.mdx
+++ b/versions/8.3.1/rules/lib/builtins/repository_ctx.mdx
@@ -50,7 +50,7 @@ Deletes a file or a directory. Returns a bool, indicating whether the file or di
 
 | Parameter | Description |
 | --- | --- |
-| `path` | [string](../core/string); or [path](../builtins/path); required  Path of the file to delete, relative to the repository directory, or absolute. Can be a path or a string. |
+| `path` | [string](/versions/8.3.1/rules/lib/core/string); or [path](/versions/8.3.1/rules/lib/builtins/path); required  Path of the file to delete, relative to the repository directory, or absolute. Can be a path or a string. |
 
 ## download
 
@@ -64,16 +64,16 @@ Downloads a file to the output path for the provided url and returns a struct co
 
 | Parameter | Description |
 | --- | --- |
-| `url` | [string](../core/string); or Iterable of [string](../core/string)s; required  List of mirror URLs referencing the same file. |
-| `output` | [string](../core/string); or [Label](../builtins/Label); or [path](../builtins/path); default is `''`  path to the output file, relative to the repository directory. |
-| `sha256` | [string](../core/string); default is `''`  The expected SHA-256 hash of the file downloaded. This must match the SHA-256 hash of the file downloaded. It is a security risk to omit the SHA-256 as remote files can change. At best omitting this field will make your build non-hermetic. It is optional to make development easier but should be set before shipping. If provided, the repository cache will first be checked for a file with the given hash; a download will only be attempted if the file was not found in the cache. After a successful download, the file will be added to the cache. |
-| `executable` | [bool](../core/bool); default is `False`  Set the executable flag on the created file, false by default. |
-| `allow_fail` | [bool](../core/bool); default is `False`  If set, indicate the error in the return value instead of raising an error for failed downloads. |
-| `canonical_id` | [string](../core/string); default is `''`  If set, restrict cache hits to those cases where the file was added to the cache with the same canonical id. By default caching uses the checksum (`sha256` or `integrity`). |
-| `auth` | [dict](../core/dict); default is `{}`  An optional dict specifying authentication information for some of the URLs. |
-| `headers` | [dict](../core/dict); default is `{}`  An optional dict specifying http headers for all URLs. |
-| `integrity` | [string](../core/string); default is `''`  Expected checksum of the file downloaded, in Subresource Integrity format. This must match the checksum of the file downloaded. It is a security risk to omit the checksum as remote files can change. At best omitting this field will make your build non-hermetic. It is optional to make development easier but should be set before shipping. If provided, the repository cache will first be checked for a file with the given checksum; a download will only be attempted if the file was not found in the cache. After a successful download, the file will be added to the cache. |
-| `block` | [bool](../core/bool); default is `True`  If set to false, the call returns immediately and instead of the regular return value, it returns a token with one single method, wait(), which blocks until the download is finished and returns the usual return value or throws as usual. |
+| `url` | [string](/versions/8.3.1/rules/lib/core/string); or Iterable of [string](/versions/8.3.1/rules/lib/core/string)s; required  List of mirror URLs referencing the same file. |
+| `output` | [string](/versions/8.3.1/rules/lib/core/string); or [Label](/versions/8.3.1/rules/lib/builtins/Label); or [path](/versions/8.3.1/rules/lib/builtins/path); default is `''`  path to the output file, relative to the repository directory. |
+| `sha256` | [string](/versions/8.3.1/rules/lib/core/string); default is `''`  The expected SHA-256 hash of the file downloaded. This must match the SHA-256 hash of the file downloaded. It is a security risk to omit the SHA-256 as remote files can change. At best omitting this field will make your build non-hermetic. It is optional to make development easier but should be set before shipping. If provided, the repository cache will first be checked for a file with the given hash; a download will only be attempted if the file was not found in the cache. After a successful download, the file will be added to the cache. |
+| `executable` | [bool](/versions/8.3.1/rules/lib/core/bool); default is `False`  Set the executable flag on the created file, false by default. |
+| `allow_fail` | [bool](/versions/8.3.1/rules/lib/core/bool); default is `False`  If set, indicate the error in the return value instead of raising an error for failed downloads. |
+| `canonical_id` | [string](/versions/8.3.1/rules/lib/core/string); default is `''`  If set, restrict cache hits to those cases where the file was added to the cache with the same canonical id. By default caching uses the checksum (`sha256` or `integrity`). |
+| `auth` | [dict](/versions/8.3.1/rules/lib/core/dict); default is `{}`  An optional dict specifying authentication information for some of the URLs. |
+| `headers` | [dict](/versions/8.3.1/rules/lib/core/dict); default is `{}`  An optional dict specifying http headers for all URLs. |
+| `integrity` | [string](/versions/8.3.1/rules/lib/core/string); default is `''`  Expected checksum of the file downloaded, in Subresource Integrity format. This must match the checksum of the file downloaded. It is a security risk to omit the checksum as remote files can change. At best omitting this field will make your build non-hermetic. It is optional to make development easier but should be set before shipping. If provided, the repository cache will first be checked for a file with the given checksum; a download will only be attempted if the file was not found in the cache. After a successful download, the file will be added to the cache. |
+| `block` | [bool](/versions/8.3.1/rules/lib/core/bool); default is `True`  If set to false, the call returns immediately and instead of the regular return value, it returns a token with one single method, wait(), which blocks until the download is finished and returns the usual return value or throws as usual. |
 
 ## download\_and\_extract
 
@@ -87,17 +87,17 @@ Downloads a file to the output path for the provided url, extracts it, and retur
 
 | Parameter | Description |
 | --- | --- |
-| `url` | [string](../core/string); or Iterable of [string](../core/string)s; required  List of mirror URLs referencing the same file. |
-| `output` | [string](../core/string); or [Label](../builtins/Label); or [path](../builtins/path); default is `''`  Path to the directory where the archive will be unpacked, relative to the repository directory. |
-| `sha256` | [string](../core/string); default is `''`  The expected SHA-256 hash of the file downloaded. This must match the SHA-256 hash of the file downloaded. It is a security risk to omit the SHA-256 as remote files can change. At best omitting this field will make your build non-hermetic. It is optional to make development easier but should be set before shipping. If provided, the repository cache will first be checked for a file with the given hash; a download will only be attempted if the file was not found in the cache. After a successful download, the file will be added to the cache. |
-| `type` | [string](../core/string); default is `''`  The archive type of the downloaded file. By default, the archive type is determined from the file extension of the URL. If the file has no extension, you can explicitly specify either "zip", "jar", "war", "aar", "nupkg", "whl", "tar", "tar.gz", "tgz", "tar.xz", "txz", ".tar.zst", ".tzst", "tar.bz2", ".tbz", ".ar", or ".deb" here. |
-| `strip_prefix` | [string](../core/string); default is `''`  A directory prefix to strip from the extracted files. Many archives contain a top-level directory that contains all files in the archive. Instead of needing to specify this prefix over and over in the `build_file`, this field can be used to strip it from extracted files. For compatibility, this parameter may also be used under the deprecated name `stripPrefix`. |
-| `allow_fail` | [bool](../core/bool); default is `False`  If set, indicate the error in the return value instead of raising an error for failed downloads. |
-| `canonical_id` | [string](../core/string); default is `''`  If set, restrict cache hits to those cases where the file was added to the cache with the same canonical id. By default caching uses the checksum" (`sha256` or `integrity`). |
-| `auth` | [dict](../core/dict); default is `{}`  An optional dict specifying authentication information for some of the URLs. |
-| `headers` | [dict](../core/dict); default is `{}`  An optional dict specifying http headers for all URLs. |
-| `integrity` | [string](../core/string); default is `''`  Expected checksum of the file downloaded, in Subresource Integrity format. This must match the checksum of the file downloaded. It is a security risk to omit the checksum as remote files can change. At best omitting this field will make your build non-hermetic. It is optional to make development easier but should be set before shipping. If provided, the repository cache will first be checked for a file with the given checksum; a download will only be attempted if the file was not found in the cache. After a successful download, the file will be added to the cache. |
-| `rename_files` | [dict](../core/dict); default is `{}`  An optional dict specifying files to rename during the extraction. Archive entries with names exactly matching a key will be renamed to the value, prior to any directory prefix adjustment. This can be used to extract archives that contain non-Unicode filenames, or which have files that would extract to the same path on case-insensitive filesystems. |
+| `url` | [string](/versions/8.3.1/rules/lib/core/string); or Iterable of [string](/versions/8.3.1/rules/lib/core/string)s; required  List of mirror URLs referencing the same file. |
+| `output` | [string](/versions/8.3.1/rules/lib/core/string); or [Label](/versions/8.3.1/rules/lib/builtins/Label); or [path](/versions/8.3.1/rules/lib/builtins/path); default is `''`  Path to the directory where the archive will be unpacked, relative to the repository directory. |
+| `sha256` | [string](/versions/8.3.1/rules/lib/core/string); default is `''`  The expected SHA-256 hash of the file downloaded. This must match the SHA-256 hash of the file downloaded. It is a security risk to omit the SHA-256 as remote files can change. At best omitting this field will make your build non-hermetic. It is optional to make development easier but should be set before shipping. If provided, the repository cache will first be checked for a file with the given hash; a download will only be attempted if the file was not found in the cache. After a successful download, the file will be added to the cache. |
+| `type` | [string](/versions/8.3.1/rules/lib/core/string); default is `''`  The archive type of the downloaded file. By default, the archive type is determined from the file extension of the URL. If the file has no extension, you can explicitly specify either "zip", "jar", "war", "aar", "nupkg", "whl", "tar", "tar.gz", "tgz", "tar.xz", "txz", ".tar.zst", ".tzst", "tar.bz2", ".tbz", ".ar", or ".deb" here. |
+| `strip_prefix` | [string](/versions/8.3.1/rules/lib/core/string); default is `''`  A directory prefix to strip from the extracted files. Many archives contain a top-level directory that contains all files in the archive. Instead of needing to specify this prefix over and over in the `build_file`, this field can be used to strip it from extracted files. For compatibility, this parameter may also be used under the deprecated name `stripPrefix`. |
+| `allow_fail` | [bool](/versions/8.3.1/rules/lib/core/bool); default is `False`  If set, indicate the error in the return value instead of raising an error for failed downloads. |
+| `canonical_id` | [string](/versions/8.3.1/rules/lib/core/string); default is `''`  If set, restrict cache hits to those cases where the file was added to the cache with the same canonical id. By default caching uses the checksum" (`sha256` or `integrity`). |
+| `auth` | [dict](/versions/8.3.1/rules/lib/core/dict); default is `{}`  An optional dict specifying authentication information for some of the URLs. |
+| `headers` | [dict](/versions/8.3.1/rules/lib/core/dict); default is `{}`  An optional dict specifying http headers for all URLs. |
+| `integrity` | [string](/versions/8.3.1/rules/lib/core/string); default is `''`  Expected checksum of the file downloaded, in Subresource Integrity format. This must match the checksum of the file downloaded. It is a security risk to omit the checksum as remote files can change. At best omitting this field will make your build non-hermetic. It is optional to make development easier but should be set before shipping. If provided, the repository cache will first be checked for a file with the given checksum; a download will only be attempted if the file was not found in the cache. After a successful download, the file will be added to the cache. |
+| `rename_files` | [dict](/versions/8.3.1/rules/lib/core/dict); default is `{}`  An optional dict specifying files to rename during the extraction. Archive entries with names exactly matching a key will be renamed to the value, prior to any directory prefix adjustment. This can be used to extract archives that contain non-Unicode filenames, or which have files that would extract to the same path on case-insensitive filesystems. |
 
 ## execute
 
@@ -111,11 +111,11 @@ Executes the command given by the list of arguments. The execution time of the c
 
 | Parameter | Description |
 | --- | --- |
-| `arguments` | [sequence](../core/list); required  List of arguments, the first element should be the path to the program to execute. |
-| `timeout` | [int](../core/int); default is `600`  Maximum duration of the command in seconds (default is 600 seconds). |
-| `environment` | [dict](../core/dict); default is `{}`  Force some environment variables to be set to be passed to the process. The value can be `None` to remove the environment variable. |
-| `quiet` | [bool](../core/bool); default is `True`  If stdout and stderr should be printed to the terminal. |
-| `working_directory` | [string](../core/string); default is `""`  Working directory for command execution. Can be relative to the repository root or absolute. The default is the repository root. |
+| `arguments` | [sequence](/versions/8.3.1/rules/lib/core/list); required  List of arguments, the first element should be the path to the program to execute. |
+| `timeout` | [int](/versions/8.3.1/rules/lib/core/int); default is `600`  Maximum duration of the command in seconds (default is 600 seconds). |
+| `environment` | [dict](/versions/8.3.1/rules/lib/core/dict); default is `{}`  Force some environment variables to be set to be passed to the process. The value can be `None` to remove the environment variable. |
+| `quiet` | [bool](/versions/8.3.1/rules/lib/core/bool); default is `True`  If stdout and stderr should be printed to the terminal. |
+| `working_directory` | [string](/versions/8.3.1/rules/lib/core/string); default is `""`  Working directory for command execution. Can be relative to the repository root or absolute. The default is the repository root. |
 
 ## extract
 
@@ -129,11 +129,11 @@ Extract an archive to the repository directory.
 
 | Parameter | Description |
 | --- | --- |
-| `archive` | [string](../core/string); or [Label](../builtins/Label); or [path](../builtins/path); required  path to the archive that will be unpacked, relative to the repository directory. |
-| `output` | [string](../core/string); or [Label](../builtins/Label); or [path](../builtins/path); default is `''`  path to the directory where the archive will be unpacked, relative to the repository directory. |
-| `strip_prefix` | [string](../core/string); default is `''`  a directory prefix to strip from the extracted files. Many archives contain a top-level directory that contains all files in the archive. Instead of needing to specify this prefix over and over in the `build_file`, this field can be used to strip it from extracted files. For compatibility, this parameter may also be used under the deprecated name `stripPrefix`. |
-| `rename_files` | [dict](../core/dict); default is `{}`  An optional dict specifying files to rename during the extraction. Archive entries with names exactly matching a key will be renamed to the value, prior to any directory prefix adjustment. This can be used to extract archives that contain non-Unicode filenames, or which have files that would extract to the same path on case-insensitive filesystems. |
-| `watch_archive` | [string](../core/string); default is `'auto'`  whether to [watch](#watch) the archive file. Can be the string 'yes', 'no', or 'auto'. Passing 'yes' is equivalent to immediately invoking the [`watch()`](#watch) method; passing 'no' does not attempt to watch the file; passing 'auto' will only attempt to watch the file when it is legal to do so (see `watch()` docs for more information. |
+| `archive` | [string](/versions/8.3.1/rules/lib/core/string); or [Label](/versions/8.3.1/rules/lib/builtins/Label); or [path](/versions/8.3.1/rules/lib/builtins/path); required  path to the archive that will be unpacked, relative to the repository directory. |
+| `output` | [string](/versions/8.3.1/rules/lib/core/string); or [Label](/versions/8.3.1/rules/lib/builtins/Label); or [path](/versions/8.3.1/rules/lib/builtins/path); default is `''`  path to the directory where the archive will be unpacked, relative to the repository directory. |
+| `strip_prefix` | [string](/versions/8.3.1/rules/lib/core/string); default is `''`  a directory prefix to strip from the extracted files. Many archives contain a top-level directory that contains all files in the archive. Instead of needing to specify this prefix over and over in the `build_file`, this field can be used to strip it from extracted files. For compatibility, this parameter may also be used under the deprecated name `stripPrefix`. |
+| `rename_files` | [dict](/versions/8.3.1/rules/lib/core/dict); default is `{}`  An optional dict specifying files to rename during the extraction. Archive entries with names exactly matching a key will be renamed to the value, prior to any directory prefix adjustment. This can be used to extract archives that contain non-Unicode filenames, or which have files that would extract to the same path on case-insensitive filesystems. |
+| `watch_archive` | [string](/versions/8.3.1/rules/lib/core/string); default is `'auto'`  whether to [watch](#watch) the archive file. Can be the string 'yes', 'no', or 'auto'. Passing 'yes' is equivalent to immediately invoking the [`watch()`](#watch) method; passing 'no' does not attempt to watch the file; passing 'auto' will only attempt to watch the file when it is legal to do so (see `watch()` docs for more information. |
 
 ## file
 
@@ -147,10 +147,10 @@ Generates a file in the repository directory with the provided content.
 
 | Parameter | Description |
 | --- | --- |
-| `path` | [string](../core/string); or [Label](../builtins/Label); or [path](../builtins/path); required  Path of the file to create, relative to the repository directory. |
-| `content` | [string](../core/string); default is `''`  The content of the file to create, empty by default. |
-| `executable` | [bool](../core/bool); default is `True`  Set the executable flag on the created file, true by default. |
-| `legacy_utf8` | [bool](../core/bool); default is `False`  No-op. This parameter is deprecated and will be removed in a future version of Bazel. |
+| `path` | [string](/versions/8.3.1/rules/lib/core/string); or [Label](/versions/8.3.1/rules/lib/builtins/Label); or [path](/versions/8.3.1/rules/lib/builtins/path); required  Path of the file to create, relative to the repository directory. |
+| `content` | [string](/versions/8.3.1/rules/lib/core/string); default is `''`  The content of the file to create, empty by default. |
+| `executable` | [bool](/versions/8.3.1/rules/lib/core/bool); default is `True`  Set the executable flag on the created file, true by default. |
+| `legacy_utf8` | [bool](/versions/8.3.1/rules/lib/core/bool); default is `False`  No-op. This parameter is deprecated and will be removed in a future version of Bazel. |
 
 ## getenv
 
@@ -166,8 +166,8 @@ When building incrementally, any change to the value of the variable named by `n
 
 | Parameter | Description |
 | --- | --- |
-| `name` | [string](../core/string); required  Name of desired environment variable. |
-| `default` | [string](../core/string); or `None`; default is `None`  Default value to return if `name` is not found. |
+| `name` | [string](/versions/8.3.1/rules/lib/core/string); required  Name of desired environment variable. |
+| `default` | [string](/versions/8.3.1/rules/lib/core/string); or `None`; default is `None`  Default value to return if `name` is not found. |
 
 May return `None`.
 
@@ -207,9 +207,9 @@ Apply a patch file to the root directory of external repository. The patch file
 
 | Parameter | Description |
 | --- | --- |
-| `patch_file` | [string](../core/string); or [Label](../builtins/Label); or [path](../builtins/path); required  The patch file to apply, it can be label, relative path or absolute path. If it's a relative path, it will resolve to the repository directory. |
-| `strip` | [int](../core/int); default is `0`  Strip the specified number of leading components from file names. |
-| `watch_patch` | [string](../core/string); default is `'auto'`  Whether to [watch](#watch) the patch file. Can be the string 'yes', 'no', or 'auto'. Passing 'yes' is equivalent to immediately invoking the [`watch()`](#watch) method; passing 'no' does not attempt to watch the file; passing 'auto' will only attempt to watch the file when it is legal to do so (see `watch()` docs for more information. |
+| `patch_file` | [string](/versions/8.3.1/rules/lib/core/string); or [Label](/versions/8.3.1/rules/lib/builtins/Label); or [path](/versions/8.3.1/rules/lib/builtins/path); required  The patch file to apply, it can be label, relative path or absolute path. If it's a relative path, it will resolve to the repository directory. |
+| `strip` | [int](/versions/8.3.1/rules/lib/core/int); default is `0`  Strip the specified number of leading components from file names. |
+| `watch_patch` | [string](/versions/8.3.1/rules/lib/core/string); default is `'auto'`  Whether to [watch](#watch) the patch file. Can be the string 'yes', 'no', or 'auto'. Passing 'yes' is equivalent to immediately invoking the [`watch()`](#watch) method; passing 'no' does not attempt to watch the file; passing 'auto' will only attempt to watch the file when it is legal to do so (see `watch()` docs for more information. |
 
 ## path
 
@@ -223,7 +223,7 @@ Returns a path from a string, label or path. If the path is relative, it will re
 
 | Parameter | Description |
 | --- | --- |
-| `path` | [string](../core/string); or [Label](../builtins/Label); or [path](../builtins/path); required  `string`, `Label` or `path` from which to create a path from. |
+| `path` | [string](/versions/8.3.1/rules/lib/core/string); or [Label](/versions/8.3.1/rules/lib/builtins/Label); or [path](/versions/8.3.1/rules/lib/builtins/path); required  `string`, `Label` or `path` from which to create a path from. |
 
 ## read
 
@@ -237,8 +237,8 @@ Reads the content of a file on the filesystem.
 
 | Parameter | Description |
 | --- | --- |
-| `path` | [string](../core/string); or [Label](../builtins/Label); or [path](../builtins/path); required  Path of the file to read from. |
-| `watch` | [string](../core/string); default is `'auto'`  Whether to [watch](#watch) the file. Can be the string 'yes', 'no', or 'auto'. Passing 'yes' is equivalent to immediately invoking the [`watch()`](#watch) method; passing 'no' does not attempt to watch the file; passing 'auto' will only attempt to watch the file when it is legal to do so (see `watch()` docs for more information. |
+| `path` | [string](/versions/8.3.1/rules/lib/core/string); or [Label](/versions/8.3.1/rules/lib/builtins/Label); or [path](/versions/8.3.1/rules/lib/builtins/path); required  Path of the file to read from. |
+| `watch` | [string](/versions/8.3.1/rules/lib/core/string); default is `'auto'`  Whether to [watch](#watch) the file. Can be the string 'yes', 'no', or 'auto'. Passing 'yes' is equivalent to immediately invoking the [`watch()`](#watch) method; passing 'no' does not attempt to watch the file; passing 'auto' will only attempt to watch the file when it is legal to do so (see `watch()` docs for more information. |
 
 ## rename
 
@@ -253,8 +253,8 @@ already exists. Both paths must be located within the repository.
 
 | Parameter | Description |
 | --- | --- |
-| `src` | [string](../core/string); or [Label](../builtins/Label); or [path](../builtins/path); required  The path of the existing file or directory to rename, relative to the repository directory. |
-| `dst` | [string](../core/string); or [Label](../builtins/Label); or [path](../builtins/path); required  The new name to which the file or directory will be renamed to, relative to the repository directory. |
+| `src` | [string](/versions/8.3.1/rules/lib/core/string); or [Label](/versions/8.3.1/rules/lib/builtins/Label); or [path](/versions/8.3.1/rules/lib/builtins/path); required  The path of the existing file or directory to rename, relative to the repository directory. |
+| `dst` | [string](/versions/8.3.1/rules/lib/core/string); or [Label](/versions/8.3.1/rules/lib/builtins/Label); or [path](/versions/8.3.1/rules/lib/builtins/path); required  The new name to which the file or directory will be renamed to, relative to the repository directory. |
 
 ## repo\_metadata
 
@@ -268,8 +268,8 @@ Constructs an opaque object that can be returned from the repo rule's implementa
 
 | Parameter | Description |
 | --- | --- |
-| `reproducible` | [bool](../core/bool); default is `False`  States that this repo can be reproducibly refetched; that is, if it were fetched another time with exactly the same input attributes, repo rule definition, watched files and environment variables, etc., then exactly the same output would be produced. This property needs to hold even if other untracked conditions change, such as information from the internet, the path of the workspace root, output from running arbitrary executables, etc. If set to True, this allows the fetched repo contents to be cached across workspaces. Note that setting this to True does not guarantee caching in the repo contents cache; for example, local repo rules are never cached. |
-| `attrs_for_reproducibility` | [dict](../core/dict); default is `{}`  If `reproducible` is False, this can be specified to tell Bazel which attributes of the original repo rule to change to make it reproducible. |
+| `reproducible` | [bool](/versions/8.3.1/rules/lib/core/bool); default is `False`  States that this repo can be reproducibly refetched; that is, if it were fetched another time with exactly the same input attributes, repo rule definition, watched files and environment variables, etc., then exactly the same output would be produced. This property needs to hold even if other untracked conditions change, such as information from the internet, the path of the workspace root, output from running arbitrary executables, etc. If set to True, this allows the fetched repo contents to be cached across workspaces. Note that setting this to True does not guarantee caching in the repo contents cache; for example, local repo rules are never cached. |
+| `attrs_for_reproducibility` | [dict](/versions/8.3.1/rules/lib/core/dict); default is `{}`  If `reproducible` is False, this can be specified to tell Bazel which attributes of the original repo rule to change to make it reproducible. |
 
 ## report\_progress
 
@@ -283,7 +283,7 @@ Updates the progress status for the fetching of this repository or module extens
 
 | Parameter | Description |
 | --- | --- |
-| `status` | [string](../core/string); default is `''`  `string` describing the current status of the fetch progress. |
+| `status` | [string](/versions/8.3.1/rules/lib/core/string); default is `''`  `string` describing the current status of the fetch progress. |
 
 ## symlink
 
@@ -297,8 +297,8 @@ Creates a symlink on the filesystem.
 
 | Parameter | Description |
 | --- | --- |
-| `target` | [string](../core/string); or [Label](../builtins/Label); or [path](../builtins/path); required  The path that the symlink should point to. |
-| `link_name` | [string](../core/string); or [Label](../builtins/Label); or [path](../builtins/path); required  The path of the symlink to create. |
+| `target` | [string](/versions/8.3.1/rules/lib/core/string); or [Label](/versions/8.3.1/rules/lib/builtins/Label); or [path](/versions/8.3.1/rules/lib/builtins/path); required  The path that the symlink should point to. |
+| `link_name` | [string](/versions/8.3.1/rules/lib/core/string); or [Label](/versions/8.3.1/rules/lib/builtins/Label); or [path](/versions/8.3.1/rules/lib/builtins/path); required  The path of the symlink to create. |
 
 ## template
 
@@ -312,11 +312,11 @@ Generates a new file using a `template`. Every occurrence in `template` of a key
 
 | Parameter | Description |
 | --- | --- |
-| `path` | [string](../core/string); or [Label](../builtins/Label); or [path](../builtins/path); required  Path of the file to create, relative to the repository directory. |
-| `template` | [string](../core/string); or [Label](../builtins/Label); or [path](../builtins/path); required  Path to the template file. |
-| `substitutions` | [dict](../core/dict); default is `{}`  Substitutions to make when expanding the template. |
-| `executable` | [bool](../core/bool); default is `True`  Set the executable flag on the created file, true by default. |
-| `watch_template` | [string](../core/string); default is `'auto'`  Whether to [watch](#watch) the template file. Can be the string 'yes', 'no', or 'auto'. Passing 'yes' is equivalent to immediately invoking the [`watch()`](#watch) method; passing 'no' does not attempt to watch the file; passing 'auto' will only attempt to watch the file when it is legal to do so (see `watch()` docs for more information. |
+| `path` | [string](/versions/8.3.1/rules/lib/core/string); or [Label](/versions/8.3.1/rules/lib/builtins/Label); or [path](/versions/8.3.1/rules/lib/builtins/path); required  Path of the file to create, relative to the repository directory. |
+| `template` | [string](/versions/8.3.1/rules/lib/core/string); or [Label](/versions/8.3.1/rules/lib/builtins/Label); or [path](/versions/8.3.1/rules/lib/builtins/path); required  Path to the template file. |
+| `substitutions` | [dict](/versions/8.3.1/rules/lib/core/dict); default is `{}`  Substitutions to make when expanding the template. |
+| `executable` | [bool](/versions/8.3.1/rules/lib/core/bool); default is `True`  Set the executable flag on the created file, true by default. |
+| `watch_template` | [string](/versions/8.3.1/rules/lib/core/string); default is `'auto'`  Whether to [watch](#watch) the template file. Can be the string 'yes', 'no', or 'auto'. Passing 'yes' is equivalent to immediately invoking the [`watch()`](#watch) method; passing 'no' does not attempt to watch the file; passing 'auto' will only attempt to watch the file when it is legal to do so (see `watch()` docs for more information. |
 
 ## watch
 
@@ -326,7 +326,7 @@ None repository_ctx.watch(path)
 
 Tells Bazel to watch for changes to the given path, whether or not it exists, or whether it's a file or a directory. Any changes to the file or directory will invalidate this repository or module extension, and cause it to be refetched or re-evaluated next time.
 
-"Changes" include changes to the contents of the file (if the path is a file); if the path was a file but is now a directory, or vice versa; and if the path starts or stops existing. Notably, this does *not* include changes to any files under the directory if the path is a directory. For that, use [`path.readdir()`](path#readdir) instead.
+"Changes" include changes to the contents of the file (if the path is a file); if the path was a file but is now a directory, or vice versa; and if the path starts or stops existing. Notably, this does *not* include changes to any files under the directory if the path is a directory. For that, use [`path.readdir()`](/versions/8.3.1/rules/lib/builtins/path#readdir) instead.
 
 Note that attempting to watch paths inside the repo currently being fetched, or inside the working directory of the current module extension, will result in an error. A module extension attempting to watch a path outside the current Bazel workspace will also result in an error.
 
@@ -334,7 +334,7 @@ Note that attempting to watch paths inside the repo currently being fetched, or
 
 | Parameter | Description |
 | --- | --- |
-| `path` | [string](../core/string); or [Label](../builtins/Label); or [path](../builtins/path); required  Path of the file to watch. |
+| `path` | [string](/versions/8.3.1/rules/lib/core/string); or [Label](/versions/8.3.1/rules/lib/builtins/Label); or [path](/versions/8.3.1/rules/lib/builtins/path); required  Path of the file to watch. |
 
 ## watch\_tree
 
@@ -350,7 +350,7 @@ Note that attempting to watch paths inside the repo currently being fetched will
 
 | Parameter | Description |
 | --- | --- |
-| `path` | [string](../core/string); or [Label](../builtins/Label); or [path](../builtins/path); required  Path of the directory tree to watch. |
+| `path` | [string](/versions/8.3.1/rules/lib/core/string); or [Label](/versions/8.3.1/rules/lib/builtins/Label); or [path](/versions/8.3.1/rules/lib/builtins/path); required  Path of the directory tree to watch. |
 
 ## which
 
@@ -364,7 +364,7 @@ Returns the `path` of the corresponding program or `None` if there is no such pr
 
 | Parameter | Description |
 | --- | --- |
-| `program` | [string](../core/string); required  Program to find in the path. |
+| `program` | [string](/versions/8.3.1/rules/lib/core/string); required  Program to find in the path. |
 
 May return `None`.
 
diff --git a/versions/8.3.1/rules/lib/builtins/repository_rule.mdx b/versions/8.3.1/rules/lib/builtins/repository_rule.mdx
index ef5dac59..78f829b7 100644
--- a/versions/8.3.1/rules/lib/builtins/repository_rule.mdx
+++ b/versions/8.3.1/rules/lib/builtins/repository_rule.mdx
@@ -2,4 +2,4 @@
 title: 'repository\_rule'
 ---
 
-A callable value that may be invoked during evaluation of the WORKSPACE file or within the implementation function of a module extension to instantiate and return a repository rule. Created by [`repository_rule()`](../globals/bzl#repository_rule).
\ No newline at end of file
+A callable value that may be invoked during evaluation of the WORKSPACE file or within the implementation function of a module extension to instantiate and return a repository rule. Created by [`repository_rule()`](/versions/8.3.1/rules/lib/globals/bzl#repository_rule).
\ No newline at end of file
diff --git a/versions/8.3.1/rules/lib/builtins/rule.mdx b/versions/8.3.1/rules/lib/builtins/rule.mdx
index cbe76283..a47f0907 100644
--- a/versions/8.3.1/rules/lib/builtins/rule.mdx
+++ b/versions/8.3.1/rules/lib/builtins/rule.mdx
@@ -3,7 +3,7 @@ title: 'rule'
 ---
 
 A callable value representing the type of a native or Starlark rule (created by
-[`rule()`](../globals/bzl#rule)). Calling the value during
+[`rule()`](/versions/8.3.1/rules/lib/globals/bzl#rule)). Calling the value during
 evaluation of a package's BUILD file creates an instance of the rule and adds it to the
 package's target set. For more information, visit this page about
 [Rules](https://bazel.build/versions/8.3.1/extending/rules).
\ No newline at end of file
diff --git a/versions/8.3.1/rules/lib/builtins/rule_attributes.mdx b/versions/8.3.1/rules/lib/builtins/rule_attributes.mdx
index a377498b..f249585d 100644
--- a/versions/8.3.1/rules/lib/builtins/rule_attributes.mdx
+++ b/versions/8.3.1/rules/lib/builtins/rule_attributes.mdx
@@ -20,7 +20,7 @@ Information about attributes of a rule an aspect is applied to.
 struct rule_attributes.attr
 ```
 
-A struct to access the values of the [attributes](https://bazel.build/versions/8.3.1/extending/rules#attributes). The values are provided by the user (if not, a default value is used). The attributes of the struct and the types of their values correspond to the keys and values of the [`attrs` dict](../globals/bzl#rule.attrs) provided to the [`rule` function](../globals/bzl#rule). [See example of use](https://github.com/bazelbuild/examples/blob/main/rules/attributes/printer.bzl).
+A struct to access the values of the [attributes](https://bazel.build/versions/8.3.1/extending/rules#attributes). The values are provided by the user (if not, a default value is used). The attributes of the struct and the types of their values correspond to the keys and values of the [`attrs` dict](/versions/8.3.1/rules/lib/globals/bzl#rule.attrs) provided to the [`rule` function](/versions/8.3.1/rules/lib/globals/bzl#rule). [See example of use](https://github.com/bazelbuild/examples/blob/main/rules/attributes/printer.bzl).
 
 ## exec\_groups
 
@@ -36,7 +36,7 @@ A collection of the execution groups available for the rule the aspect is applie
 struct rule_attributes.executable
 ```
 
-A `struct` containing executable files defined in [label type attributes](../toplevel/attr#label) marked as [`executable=True`](../toplevel/attr#label.executable). The struct fields correspond to the attribute names. Each value in the struct is either a [`File`](../builtins/File) or `None`. If an optional attribute is not specified in the rule then the corresponding struct value is `None`. If a label type is not marked as `executable=True`, no corresponding struct field is generated. [See example of use](https://github.com/bazelbuild/examples/blob/main/rules/actions_run/execute.bzl).
+A `struct` containing executable files defined in [label type attributes](/versions/8.3.1/rules/lib/toplevel/attr#label) marked as [`executable=True`](/versions/8.3.1/rules/lib/toplevel/attr#label.executable). The struct fields correspond to the attribute names. Each value in the struct is either a [`File`](/versions/8.3.1/rules/lib/builtins/File) or `None`. If an optional attribute is not specified in the rule then the corresponding struct value is `None`. If a label type is not marked as `executable=True`, no corresponding struct field is generated. [See example of use](https://github.com/bazelbuild/examples/blob/main/rules/actions_run/execute.bzl).
 
 ## file
 
@@ -44,7 +44,7 @@ A `struct` containing executable files defined in [label type attributes](../top
 struct rule_attributes.file
 ```
 
-A `struct` containing files defined in [label type attributes](../toplevel/attr#label) marked as [`allow_single_file`](../toplevel/attr#label.allow_single_file). The struct fields correspond to the attribute names. The struct value is always a [`File`](../builtins/File) or `None`. If an optional attribute is not specified in the rule then the corresponding struct value is `None`. If a label type is not marked as `allow_single_file`, no corresponding struct field is generated. It is a shortcut for:
+A `struct` containing files defined in [label type attributes](/versions/8.3.1/rules/lib/toplevel/attr#label) marked as [`allow_single_file`](/versions/8.3.1/rules/lib/toplevel/attr#label.allow_single_file). The struct fields correspond to the attribute names. The struct value is always a [`File`](/versions/8.3.1/rules/lib/builtins/File) or `None`. If an optional attribute is not specified in the rule then the corresponding struct value is `None`. If a label type is not marked as `allow_single_file`, no corresponding struct field is generated. It is a shortcut for:
 
 ```
 list(ctx.attr..files)[0]
@@ -58,7 +58,7 @@ In other words, use `file` to access the (singular) [default output](https://baz
 struct rule_attributes.files
 ```
 
-A `struct` containing files defined in [label](../toplevel/attr#label) or [label list](../toplevel/attr#label_list) type attributes. The struct fields correspond to the attribute names. The struct values are `list` of [`File`](../builtins/File)s. It is a shortcut for:
+A `struct` containing files defined in [label](/versions/8.3.1/rules/lib/toplevel/attr#label) or [label list](/versions/8.3.1/rules/lib/toplevel/attr#label_list) type attributes. The struct fields correspond to the attribute names. The struct values are `list` of [`File`](/versions/8.3.1/rules/lib/builtins/File)s. It is a shortcut for:
 
 ```
 [f for t in ctx.attr. for f in t.files]
diff --git a/versions/8.3.1/rules/lib/builtins/runfiles.mdx b/versions/8.3.1/rules/lib/builtins/runfiles.mdx
index a79dd297..d0ef71cc 100644
--- a/versions/8.3.1/rules/lib/builtins/runfiles.mdx
+++ b/versions/8.3.1/rules/lib/builtins/runfiles.mdx
@@ -2,7 +2,7 @@
 title: 'runfiles'
 ---
 
-A container of information regarding a set of files required at runtime execution. This object should be passed via [DefaultInfo](../providers/DefaultInfo) in order to tell the build system about the runfiles needed by the outputs produced by the rule.
+A container of information regarding a set of files required at runtime execution. This object should be passed via [DefaultInfo](/versions/8.3.1/rules/lib/providers/DefaultInfo) in order to tell the build system about the runfiles needed by the outputs produced by the rule.
 
 See [runfiles guide](https://bazel.build/versions/8.3.1/extending/rules#runfiles) for details.
 
@@ -45,7 +45,7 @@ Returns a new runfiles object that includes all the contents of this one and the
 
 | Parameter | Description |
 | --- | --- |
-| `other` | [runfiles](../builtins/runfiles); required  The runfiles object to merge into this. |
+| `other` | [runfiles](/versions/8.3.1/rules/lib/builtins/runfiles); required  The runfiles object to merge into this. |
 
 ## merge\_all
 
@@ -59,7 +59,7 @@ Returns a new runfiles object that includes all the contents of this one and of
 
 | Parameter | Description |
 | --- | --- |
-| `other` | [sequence](../core/list) of [runfiles](../builtins/runfiles)s; required  The sequence of runfiles objects to merge into this. |
+| `other` | [sequence](/versions/8.3.1/rules/lib/core/list) of [runfiles](/versions/8.3.1/rules/lib/builtins/runfiles)s; required  The sequence of runfiles objects to merge into this. |
 
 ## root\_symlinks
 
diff --git a/versions/8.3.1/rules/lib/builtins/tag_class.mdx b/versions/8.3.1/rules/lib/builtins/tag_class.mdx
index 7d4349d0..47fdeb8d 100644
--- a/versions/8.3.1/rules/lib/builtins/tag_class.mdx
+++ b/versions/8.3.1/rules/lib/builtins/tag_class.mdx
@@ -2,4 +2,4 @@
 title: 'tag\_class'
 ---
 
-Defines a schema of attributes for a tag, created by [`tag_class()`](../globals/bzl#tag_class).
\ No newline at end of file
+Defines a schema of attributes for a tag, created by [`tag_class()`](/versions/8.3.1/rules/lib/globals/bzl#tag_class).
\ No newline at end of file
diff --git a/versions/8.3.1/rules/lib/builtins/transition.mdx b/versions/8.3.1/rules/lib/builtins/transition.mdx
index a3c76526..0af6839f 100644
--- a/versions/8.3.1/rules/lib/builtins/transition.mdx
+++ b/versions/8.3.1/rules/lib/builtins/transition.mdx
@@ -39,5 +39,5 @@ For more details see [here](https://bazel.build/versions/8.3.1/rules/config#user
 | Parameter | Description |
 | --- | --- |
 | `implementation` | callable; required  The function implementing this transition. This function always has two parameters: `settings` and `attr`. The `settings` param is a dictionary whose set of keys is defined by the inputs parameter. So, for each build setting `--//foo=bar`, if `inputs` contains `//foo`, `settings` will have an entry `settings['//foo']='bar'`. The `attr` param is a reference to `ctx.attr`. This gives the implementation function access to the rule's attributes to make attribute-parameterized transitions possible. This function must return a `dict` from build setting identifier to build setting value; this represents the configuration transition: for each entry in the returned `dict`, the transition updates that setting to the new value. All other settings are unchanged. This function can also return a `list` of `dict`s or a `dict` of `dict`s in the case of a split transition. |
-| `inputs` | [sequence](../core/list) of [string](../core/string)s; required  List of build settings that can be read by this transition. This becomes the key set of the settings parameter of the implementation function parameter. |
-| `outputs` | [sequence](../core/list) of [string](../core/string)s; required  List of build settings that can be written by this transition. This must be a superset of the key set of the dictionary returned by this transition. |
\ No newline at end of file
+| `inputs` | [sequence](/versions/8.3.1/rules/lib/core/list) of [string](/versions/8.3.1/rules/lib/core/string)s; required  List of build settings that can be read by this transition. This becomes the key set of the settings parameter of the implementation function parameter. |
+| `outputs` | [sequence](/versions/8.3.1/rules/lib/core/list) of [string](/versions/8.3.1/rules/lib/core/string)s; required  List of build settings that can be written by this transition. This must be a superset of the key set of the dictionary returned by this transition. |
\ No newline at end of file
diff --git a/versions/8.3.1/rules/lib/core/bool.mdx b/versions/8.3.1/rules/lib/core/bool.mdx
index 52be3664..776ec4cf 100644
--- a/versions/8.3.1/rules/lib/core/bool.mdx
+++ b/versions/8.3.1/rules/lib/core/bool.mdx
@@ -2,4 +2,4 @@
 title: 'bool'
 ---
 
-A type to represent booleans. There are only two possible values: True and False. Any value can be converted to a boolean using the [bool](../globals/all#bool) function.
\ No newline at end of file
+A type to represent booleans. There are only two possible values: True and False. Any value can be converted to a boolean using the [bool](/versions/8.3.1/rules/lib/globals/all#bool) function.
\ No newline at end of file
diff --git a/versions/8.3.1/rules/lib/core/dict.mdx b/versions/8.3.1/rules/lib/core/dict.mdx
index 9005668c..5d02d610 100644
--- a/versions/8.3.1/rules/lib/core/dict.mdx
+++ b/versions/8.3.1/rules/lib/core/dict.mdx
@@ -22,7 +22,7 @@ There are four ways to construct a dictionary:
      {i: 2*i for i in range(3)}  # {0: 0, 1: 2, 2: 4}
      ```
 
-     - A call to the built-in [dict](../globals/all#dict) function returns a dictionary containing the specified entries, which are inserted in argument order, positional arguments before named. As with comprehensions, duplicate keys are permitted.- The union expression `x | y` yields a new dictionary by combining two existing dictionaries. If the two dictionaries have a key `k` in common, the right hand side dictionary's value of the key (in other words, `y[k]`) wins. The `|=` variant of the union operator modifies a dictionary in-place. Example:
+     - A call to the built-in [dict](/versions/8.3.1/rules/lib/globals/all#dict) function returns a dictionary containing the specified entries, which are inserted in argument order, positional arguments before named. As with comprehensions, duplicate keys are permitted.- The union expression `x | y` yields a new dictionary by combining two existing dictionaries. If the two dictionaries have a key `k` in common, the right hand side dictionary's value of the key (in other words, `y[k]`) wins. The `|=` variant of the union operator modifies a dictionary in-place. Example:
 
          ```
          d = {"foo": "FOO", "bar": "BAR"} | {"foo": "FOO2", "baz": "BAZ"}
diff --git a/versions/8.3.1/rules/lib/core/json.mdx b/versions/8.3.1/rules/lib/core/json.mdx
index 0bb00e3e..d0500350 100644
--- a/versions/8.3.1/rules/lib/core/json.mdx
+++ b/versions/8.3.1/rules/lib/core/json.mdx
@@ -29,7 +29,7 @@ If `x` is not a valid JSON encoding and the optional `default` parameter is *not
 
 | Parameter | Description |
 | --- | --- |
-| `x` | [string](../core/string); required  JSON string to decode. |
+| `x` | [string](/versions/8.3.1/rules/lib/core/string); required  JSON string to decode. |
 | `default` | default is `unbound`  If specified, the value to return when `x` cannot be decoded. |
 
 ## encode
@@ -64,8 +64,8 @@ The encode\_indent function is equivalent to `json.indent(json.encode(x), ...)`.
 | Parameter | Description |
 | --- | --- |
 | `x` | required |
-| `prefix` | [string](../core/string); default is `''` |
-| `indent` | [string](../core/string); default is `'\t'` |
+| `prefix` | [string](/versions/8.3.1/rules/lib/core/string); default is `''` |
+| `indent` | [string](/versions/8.3.1/rules/lib/core/string); default is `'\t'` |
 
 ## indent
 
@@ -84,6 +84,6 @@ If the input is not valid, the function may fail or return invalid output.
 
 | Parameter | Description |
 | --- | --- |
-| `s` | [string](../core/string); required |
-| `prefix` | [string](../core/string); default is `''` |
-| `indent` | [string](../core/string); default is `'\t'` |
\ No newline at end of file
+| `s` | [string](/versions/8.3.1/rules/lib/core/string); required |
+| `prefix` | [string](/versions/8.3.1/rules/lib/core/string); default is `''` |
+| `indent` | [string](/versions/8.3.1/rules/lib/core/string); default is `'\t'` |
\ No newline at end of file
diff --git a/versions/8.3.1/rules/lib/core/list.mdx b/versions/8.3.1/rules/lib/core/list.mdx
index c19e9780..6b4751b4 100644
--- a/versions/8.3.1/rules/lib/core/list.mdx
+++ b/versions/8.3.1/rules/lib/core/list.mdx
@@ -91,8 +91,8 @@ Returns the index in the list of the first item whose value is x. It is an error
 | Parameter | Description |
 | --- | --- |
 | `x` | required |
-| `start` | [int](../core/int); or `None`; default is `None`  The start index of the list portion to inspect. |
-| `end` | [int](../core/int); or `None`; default is `None`  The end index of the list portion to inspect. |
+| `start` | [int](/versions/8.3.1/rules/lib/core/int); or `None`; default is `None`  The start index of the list portion to inspect. |
+| `end` | [int](/versions/8.3.1/rules/lib/core/int); or `None`; default is `None`  The end index of the list portion to inspect. |
 
 ## insert
 
@@ -106,7 +106,7 @@ Inserts an item at a given position.
 
 | Parameter | Description |
 | --- | --- |
-| `index` | [int](../core/int); required  The index of the given position. |
+| `index` | [int](/versions/8.3.1/rules/lib/core/int); required  The index of the given position. |
 | `item` | required  The item. |
 
 ## pop
@@ -121,7 +121,7 @@ Removes the item at the given position in the list, and returns it. If no `index
 
 | Parameter | Description |
 | --- | --- |
-| `i` | [int](../core/int); or `None`; default is `-1`  The index of the item. |
+| `i` | [int](/versions/8.3.1/rules/lib/core/int); or `None`; default is `-1`  The index of the item. |
 
 ## remove
 
diff --git a/versions/8.3.1/rules/lib/core/set.mdx b/versions/8.3.1/rules/lib/core/set.mdx
index aeb3b202..d7a6cd50 100644
--- a/versions/8.3.1/rules/lib/core/set.mdx
+++ b/versions/8.3.1/rules/lib/core/set.mdx
@@ -3,14 +3,14 @@ title: 'set'
 ---
 
 The built-in set type. A set is a mutable, iterable collection of unique values – the set's
-*elements*. The [type name](../globals/all#type) of a set is `"set"`.
+*elements*. The [type name](/versions/8.3.1/rules/lib/globals/all#type) of a set is `"set"`.
 
 Sets provide constant-time operations to insert, remove, or check for the presence of a value.
 Sets are implemented using a hash table, and therefore, just like keys of a
-[dictionary](../dict), elements of a set must be hashable. A value may be used as an
+[dictionary](/versions/8.3.1/rules/lib/core/dict), elements of a set must be hashable. A value may be used as an
 element of a set if and only if it may be used as a key of a dictionary.
 
-Sets may be constructed using the [`set()`](../globals/all#set) built-in
+Sets may be constructed using the [`set()`](/versions/8.3.1/rules/lib/globals/all#set) built-in
 function, which returns a new set containing the unique elements of its optional argument, which
 must be an iterable. Calling `set()` without an argument constructs an empty set. Sets
 have no literal syntax.
@@ -26,7 +26,7 @@ s = set(["a", "b", "c"])
 
 A set is iterable, and thus may be used as the operand of a `for` loop, a list
 comprehension, and the various built-in functions that operate on iterables. Its length can be
-retrieved using the [`len()`](../globals/all#len) built-in function, and the
+retrieved using the [`len()`](/versions/8.3.1/rules/lib/globals/all#len) built-in function, and the
 order of iteration is the order in which elements were first added to the set:
 
 ```
diff --git a/versions/8.3.1/rules/lib/core/string.mdx b/versions/8.3.1/rules/lib/core/string.mdx
index 1673c6e4..abc625ac 100644
--- a/versions/8.3.1/rules/lib/core/string.mdx
+++ b/versions/8.3.1/rules/lib/core/string.mdx
@@ -81,9 +81,9 @@ Returns the number of (non-overlapping) occurrences of substring `sub` in string
 
 | Parameter | Description |
 | --- | --- |
-| `sub` | [string](../core/string); required |
-| `start` | [int](../core/int); or `None`; default is `0` |
-| `end` | [int](../core/int); or `None`; default is `None`  optional position before which to restrict to search. |
+| `sub` | [string](/versions/8.3.1/rules/lib/core/string); required |
+| `start` | [int](/versions/8.3.1/rules/lib/core/int); or `None`; default is `0` |
+| `end` | [int](/versions/8.3.1/rules/lib/core/int); or `None`; default is `None`  optional position before which to restrict to search. |
 
 ## elems
 
@@ -105,9 +105,9 @@ Returns True if the string ends with `sub`, otherwise False, optionally restrict
 
 | Parameter | Description |
 | --- | --- |
-| `sub` | [string](../core/string); or [tuple](../core/tuple) of [string](../core/string)s; required  The suffix (or tuple of alternative suffixes) to match. |
-| `start` | [int](../core/int); or `None`; default is `0`  Test beginning at this position. |
-| `end` | [int](../core/int); or `None`; default is `None`  optional position at which to stop comparing. |
+| `sub` | [string](/versions/8.3.1/rules/lib/core/string); or [tuple](/versions/8.3.1/rules/lib/core/tuple) of [string](/versions/8.3.1/rules/lib/core/string)s; required  The suffix (or tuple of alternative suffixes) to match. |
+| `start` | [int](/versions/8.3.1/rules/lib/core/int); or `None`; default is `0`  Test beginning at this position. |
+| `end` | [int](/versions/8.3.1/rules/lib/core/int); or `None`; default is `None`  optional position at which to stop comparing. |
 
 ## find
 
@@ -121,9 +121,9 @@ Returns the first index where `sub` is found, or -1 if no such index exists, opt
 
 | Parameter | Description |
 | --- | --- |
-| `sub` | [string](../core/string); required  The substring to find. |
-| `start` | [int](../core/int); or `None`; default is `0`  Restrict to search from this position. |
-| `end` | [int](../core/int); or `None`; default is `None`  optional position before which to restrict to search. |
+| `sub` | [string](/versions/8.3.1/rules/lib/core/string); required  The substring to find. |
+| `start` | [int](/versions/8.3.1/rules/lib/core/int); or `None`; default is `0`  Restrict to search from this position. |
+| `end` | [int](/versions/8.3.1/rules/lib/core/int); or `None`; default is `None`  optional position before which to restrict to search. |
 
 ## format
 
@@ -131,7 +131,7 @@ Returns the first index where `sub` is found, or -1 if no such index exists, opt
 string string.format(*args, **kwargs)
 ```
 
-Perform string interpolation. Format strings contain replacement fields surrounded by curly braces `{}`. Anything that is not contained in braces is considered literal text, which is copied unchanged to the output.If you need to include a brace character in the literal text, it can be escaped by doubling: `{{` and `}}`A replacement field can be either a name, a number, or empty. Values are converted to strings using the [str](../globals/all#str) function.
+Perform string interpolation. Format strings contain replacement fields surrounded by curly braces `{}`. Anything that is not contained in braces is considered literal text, which is copied unchanged to the output.If you need to include a brace character in the literal text, it can be escaped by doubling: `{{` and `}}`A replacement field can be either a name, a number, or empty. Values are converted to strings using the [str](/versions/8.3.1/rules/lib/globals/all#str) function.
 
 ```
 # Access in order:
@@ -161,9 +161,9 @@ Returns the first index where `sub` is found, or raises an error if no such inde
 
 | Parameter | Description |
 | --- | --- |
-| `sub` | [string](../core/string); required  The substring to find. |
-| `start` | [int](../core/int); or `None`; default is `0`  Restrict to search from this position. |
-| `end` | [int](../core/int); or `None`; default is `None`  optional position before which to restrict to search. |
+| `sub` | [string](/versions/8.3.1/rules/lib/core/string); required  The substring to find. |
+| `start` | [int](/versions/8.3.1/rules/lib/core/int); or `None`; default is `0`  Restrict to search from this position. |
+| `end` | [int](/versions/8.3.1/rules/lib/core/int); or `None`; default is `None`  optional position before which to restrict to search. |
 
 ## isalnum
 
@@ -263,7 +263,7 @@ Returns a copy of the string where leading characters that appear in `chars` are
 
 | Parameter | Description |
 | --- | --- |
-| `chars` | [string](../core/string); or `None`; default is `None`  The characters to remove, or all whitespace if None. |
+| `chars` | [string](/versions/8.3.1/rules/lib/core/string); or `None`; default is `None`  The characters to remove, or all whitespace if None. |
 
 ## partition
 
@@ -277,7 +277,7 @@ Splits the input string at the first occurrence of the separator `sep` and retur
 
 | Parameter | Description |
 | --- | --- |
-| `sep` | [string](../core/string); required  The string to split on. |
+| `sep` | [string](/versions/8.3.1/rules/lib/core/string); required  The string to split on. |
 
 ## removeprefix
 
@@ -291,7 +291,7 @@ If the string starts with `prefix`, returns a new string with the prefix removed
 
 | Parameter | Description |
 | --- | --- |
-| `prefix` | [string](../core/string); required  The prefix to remove if present. |
+| `prefix` | [string](/versions/8.3.1/rules/lib/core/string); required  The prefix to remove if present. |
 
 ## removesuffix
 
@@ -305,7 +305,7 @@ If the string ends with `suffix`, returns a new string with the suffix removed.
 
 | Parameter | Description |
 | --- | --- |
-| `suffix` | [string](../core/string); required  The suffix to remove if present. |
+| `suffix` | [string](/versions/8.3.1/rules/lib/core/string); required  The suffix to remove if present. |
 
 ## replace
 
@@ -319,9 +319,9 @@ Returns a copy of the string in which the occurrences of `old` have been replace
 
 | Parameter | Description |
 | --- | --- |
-| `old` | [string](../core/string); required  The string to be replaced. |
-| `new` | [string](../core/string); required  The string to replace with. |
-| `count` | [int](../core/int); default is `-1`  The maximum number of replacements. If omitted, or if the value is negative, there is no limit. |
+| `old` | [string](/versions/8.3.1/rules/lib/core/string); required  The string to be replaced. |
+| `new` | [string](/versions/8.3.1/rules/lib/core/string); required  The string to replace with. |
+| `count` | [int](/versions/8.3.1/rules/lib/core/int); default is `-1`  The maximum number of replacements. If omitted, or if the value is negative, there is no limit. |
 
 ## rfind
 
@@ -335,9 +335,9 @@ Returns the last index where `sub` is found, or -1 if no such index exists, opti
 
 | Parameter | Description |
 | --- | --- |
-| `sub` | [string](../core/string); required  The substring to find. |
-| `start` | [int](../core/int); or `None`; default is `0`  Restrict to search from this position. |
-| `end` | [int](../core/int); or `None`; default is `None`  optional position before which to restrict to search. |
+| `sub` | [string](/versions/8.3.1/rules/lib/core/string); required  The substring to find. |
+| `start` | [int](/versions/8.3.1/rules/lib/core/int); or `None`; default is `0`  Restrict to search from this position. |
+| `end` | [int](/versions/8.3.1/rules/lib/core/int); or `None`; default is `None`  optional position before which to restrict to search. |
 
 ## rindex
 
@@ -351,9 +351,9 @@ Returns the last index where `sub` is found, or raises an error if no such index
 
 | Parameter | Description |
 | --- | --- |
-| `sub` | [string](../core/string); required  The substring to find. |
-| `start` | [int](../core/int); or `None`; default is `0`  Restrict to search from this position. |
-| `end` | [int](../core/int); or `None`; default is `None`  optional position before which to restrict to search. |
+| `sub` | [string](/versions/8.3.1/rules/lib/core/string); required  The substring to find. |
+| `start` | [int](/versions/8.3.1/rules/lib/core/int); or `None`; default is `0`  Restrict to search from this position. |
+| `end` | [int](/versions/8.3.1/rules/lib/core/int); or `None`; default is `None`  optional position before which to restrict to search. |
 
 ## rpartition
 
@@ -367,7 +367,7 @@ Splits the input string at the last occurrence of the separator `sep` and return
 
 | Parameter | Description |
 | --- | --- |
-| `sep` | [string](../core/string); required  The string to split on. |
+| `sep` | [string](/versions/8.3.1/rules/lib/core/string); required  The string to split on. |
 
 ## rsplit
 
@@ -381,8 +381,8 @@ Returns a list of all the words in the string, using `sep` as the separator, opt
 
 | Parameter | Description |
 | --- | --- |
-| `sep` | [string](../core/string); required  The string to split on. |
-| `maxsplit` | [int](../core/int); or `None`; default is `None`  The maximum number of splits. |
+| `sep` | [string](/versions/8.3.1/rules/lib/core/string); required  The string to split on. |
+| `maxsplit` | [int](/versions/8.3.1/rules/lib/core/int); or `None`; default is `None`  The maximum number of splits. |
 
 ## rstrip
 
@@ -400,7 +400,7 @@ Returns a copy of the string where trailing characters that appear in `chars` ar
 
 | Parameter | Description |
 | --- | --- |
-| `chars` | [string](../core/string); or `None`; default is `None`  The characters to remove, or all whitespace if None. |
+| `chars` | [string](/versions/8.3.1/rules/lib/core/string); or `None`; default is `None`  The characters to remove, or all whitespace if None. |
 
 ## split
 
@@ -414,8 +414,8 @@ Returns a list of all the words in the string, using `sep` as the separator, opt
 
 | Parameter | Description |
 | --- | --- |
-| `sep` | [string](../core/string); required  The string to split on. |
-| `maxsplit` | [int](../core/int); or `None`; default is `None`  The maximum number of splits. |
+| `sep` | [string](/versions/8.3.1/rules/lib/core/string); required  The string to split on. |
+| `maxsplit` | [int](/versions/8.3.1/rules/lib/core/int); or `None`; default is `None`  The maximum number of splits. |
 
 ## splitlines
 
@@ -429,7 +429,7 @@ Splits the string at line boundaries ('\n', '\r\n', '\r') and returns the result
 
 | Parameter | Description |
 | --- | --- |
-| `keepends` | [bool](../core/bool); default is `False`  Whether the line breaks should be included in the resulting list. |
+| `keepends` | [bool](/versions/8.3.1/rules/lib/core/bool); default is `False`  Whether the line breaks should be included in the resulting list. |
 
 ## startswith
 
@@ -443,9 +443,9 @@ Returns True if the string starts with `sub`, otherwise False, optionally restri
 
 | Parameter | Description |
 | --- | --- |
-| `sub` | [string](../core/string); or [tuple](../core/tuple) of [string](../core/string)s; required  The prefix (or tuple of alternative prefixes) to match. |
-| `start` | [int](../core/int); or `None`; default is `0`  Test beginning at this position. |
-| `end` | [int](../core/int); or `None`; default is `None`  Stop comparing at this position. |
+| `sub` | [string](/versions/8.3.1/rules/lib/core/string); or [tuple](/versions/8.3.1/rules/lib/core/tuple) of [string](/versions/8.3.1/rules/lib/core/string)s; required  The prefix (or tuple of alternative prefixes) to match. |
+| `start` | [int](/versions/8.3.1/rules/lib/core/int); or `None`; default is `0`  Test beginning at this position. |
+| `end` | [int](/versions/8.3.1/rules/lib/core/int); or `None`; default is `None`  Stop comparing at this position. |
 
 ## strip
 
@@ -463,7 +463,7 @@ Returns a copy of the string where leading or trailing characters that appear in
 
 | Parameter | Description |
 | --- | --- |
-| `chars` | [string](../core/string); or `None`; default is `None`  The characters to remove, or all whitespace if None. |
+| `chars` | [string](/versions/8.3.1/rules/lib/core/string); or `None`; default is `None`  The characters to remove, or all whitespace if None. |
 
 ## title
 
diff --git a/versions/8.3.1/rules/lib/fragments.mdx b/versions/8.3.1/rules/lib/fragments.mdx
index 81eb40d9..dc6c3bd5 100644
--- a/versions/8.3.1/rules/lib/fragments.mdx
+++ b/versions/8.3.1/rules/lib/fragments.mdx
@@ -2,7 +2,7 @@
 title: 'Configuration Fragments'
 ---
 
-Configuration fragments give rules access to language-specific parts of [configuration](builtins/configuration).
+Configuration fragments give rules access to language-specific parts of [configuration](/versions/8.3.1/rules/lib/builtins/configuration).
 
 Rule implementations can get them using `ctx.fragments.[fragment name]`
 
diff --git a/versions/8.3.1/rules/lib/fragments/apple.mdx b/versions/8.3.1/rules/lib/fragments/apple.mdx
index f7e8daff..3b2d5c53 100644
--- a/versions/8.3.1/rules/lib/fragments/apple.mdx
+++ b/versions/8.3.1/rules/lib/fragments/apple.mdx
@@ -22,7 +22,7 @@ The platform of the current configuration for the given platform type. This shou
 
 | Parameter | Description |
 | --- | --- |
-| `platform_type` | [string](../core/string); required  The apple platform type. |
+| `platform_type` | [string](/versions/8.3.1/rules/lib/core/string); required  The apple platform type. |
 
 ## single\_arch\_cpu
 
diff --git a/versions/8.3.1/rules/lib/fragments/coverage.mdx b/versions/8.3.1/rules/lib/fragments/coverage.mdx
index a7de23a2..b3100409 100644
--- a/versions/8.3.1/rules/lib/fragments/coverage.mdx
+++ b/versions/8.3.1/rules/lib/fragments/coverage.mdx
@@ -14,7 +14,7 @@ A configuration fragment representing the coverage configuration.
 Label coverage.output_generator
 ```
 
-Returns the label pointed to by the [`--coverage_output_generator`](https://bazel.build/versions/8.3.1/reference/command-line-reference#flag--coverage_output_generator) option if coverage collection is enabled, otherwise returns `None`. Can be accessed with [`configuration_field`](../globals/bzl#configuration_field):
+Returns the label pointed to by the [`--coverage_output_generator`](https://bazel.build/versions/8.3.1/reference/command-line-reference#flag--coverage_output_generator) option if coverage collection is enabled, otherwise returns `None`. Can be accessed with [`configuration_field`](/versions/8.3.1/rules/lib/globals/bzl#configuration_field):
 
 ```
 attr.label(
diff --git a/versions/8.3.1/rules/lib/fragments/cpp.mdx b/versions/8.3.1/rules/lib/fragments/cpp.mdx
index 4f83225c..aaa359ad 100644
--- a/versions/8.3.1/rules/lib/fragments/cpp.mdx
+++ b/versions/8.3.1/rules/lib/fragments/cpp.mdx
@@ -46,7 +46,7 @@ The flags passed to Bazel by [`--copt`](/versions/8.3.1/docs/user-manual#flag--c
 Label cpp.custom_malloc
 ```
 
-Returns label pointed to by [`--custom_malloc`](/versions/8.3.1/docs/user-manual#flag--custom_malloc) option. Can be accessed with [`configuration_field`](../globals/bzl#configuration_field):
+Returns label pointed to by [`--custom_malloc`](/versions/8.3.1/docs/user-manual#flag--custom_malloc) option. Can be accessed with [`configuration_field`](/versions/8.3.1/rules/lib/globals/bzl#configuration_field):
 
 ```
 attr.label(
diff --git a/versions/8.3.1/rules/lib/globals/all.mdx b/versions/8.3.1/rules/lib/globals/all.mdx
index 45106d41..5345afa2 100644
--- a/versions/8.3.1/rules/lib/globals/all.mdx
+++ b/versions/8.3.1/rules/lib/globals/all.mdx
@@ -50,7 +50,7 @@ abs(-2.3) == 2.3
 
 | Parameter | Description |
 | --- | --- |
-| `x` | [int](../core/int); or [float](../core/float); required  A number (int or float) |
+| `x` | [int](/versions/8.3.1/rules/lib/core/int); or [float](/versions/8.3.1/rules/lib/core/float); required  A number (int or float) |
 
 ## all
 
@@ -110,7 +110,7 @@ Constructor for the bool type. It returns `False` if the object is `None`, `Fals
 dict dict(pairs=[], **kwargs)
 ```
 
-Creates a [dictionary](../core/dict) from an optional positional argument and an optional set of keyword arguments. In the case where the same key is given multiple times, the last value will be used. Entries supplied via keyword arguments are considered to come after entries supplied via the positional argument.
+Creates a [dictionary](/versions/8.3.1/rules/lib/core/dict) from an optional positional argument and an optional set of keyword arguments. In the case where the same key is given multiple times, the last value will be used. Entries supplied via keyword arguments are considered to come after entries supplied via the positional argument.
 
 ### Parameters
 
@@ -150,7 +150,7 @@ enumerate([24, 21, 84]) == [(0, 24), (1, 21), (2, 84)]
 | Parameter | Description |
 | --- | --- |
 | `list` | required  input sequence. |
-| `start` | [int](../core/int); default is `0`  start index. |
+| `start` | [int](/versions/8.3.1/rules/lib/core/int); default is `0`  start index. |
 
 ## fail
 
@@ -165,8 +165,8 @@ Causes execution to fail with an error.
 | Parameter | Description |
 | --- | --- |
 | `msg` | default is `None`  Deprecated: use positional arguments instead. This argument acts like an implicit leading positional argument. |
-| `attr` | [string](../core/string); or `None`; default is `None`  Deprecated. Causes an optional prefix containing this string to be added to the error message. |
-| `sep` | [string](../core/string); default is `" "`  The separator string between the objects, default is space (" "). |
+| `attr` | [string](/versions/8.3.1/rules/lib/core/string); or `None`; default is `None`  Deprecated. Causes an optional prefix containing this string to be added to the error message. |
+| `sep` | [string](/versions/8.3.1/rules/lib/core/string); default is `" "`  The separator string between the objects, default is space (" "). |
 | `args` | required  A list of values, formatted with debugPrint (which is equivalent to str by default) and joined with sep (defaults to " "), that appear in the error message. |
 
 ## float
@@ -205,7 +205,7 @@ getattr(ctx.attr, "myattr", "mydefault")
 | Parameter | Description |
 | --- | --- |
 | `x` | required  The struct whose attribute is accessed. |
-| `name` | [string](../core/string); required  The name of the struct attribute. |
+| `name` | [string](/versions/8.3.1/rules/lib/core/string); required  The name of the struct attribute. |
 | `default` | default is `unbound`  The default value to return in case the struct doesn't have an attribute of the given name. |
 
 ## hasattr
@@ -225,7 +225,7 @@ hasattr(ctx.attr, "myattr")
 | Parameter | Description |
 | --- | --- |
 | `x` | required |
-| `name` | [string](../core/string); required  The name of the attribute. |
+| `name` | [string](/versions/8.3.1/rules/lib/core/string); required  The name of the attribute. |
 
 ## hash
 
@@ -245,7 +245,7 @@ Hashing of values besides strings is not currently supported.
 
 | Parameter | Description |
 | --- | --- |
-| `value` | [string](../core/string); required  String value to hash. |
+| `value` | [string](/versions/8.3.1/rules/lib/core/string); required  String value to hash. |
 
 ## int
 
@@ -372,7 +372,7 @@ Using `print` in production code is discouraged due to the spam it creates for u
 
 | Parameter | Description |
 | --- | --- |
-| `sep` | [string](../core/string); default is `" "`  The separator string between the objects, default is space (" "). |
+| `sep` | [string](/versions/8.3.1/rules/lib/core/string); default is `" "`  The separator string between the objects, default is space (" "). |
 | `args` | required  The objects to print. |
 
 ## range
@@ -393,9 +393,9 @@ range(3, 0, -1) == [3, 2, 1]
 
 | Parameter | Description |
 | --- | --- |
-| `start_or_stop` | [int](../core/int); required  Value of the start element if stop is provided, otherwise value of stop and the actual start is 0 |
-| `stop_or_none` | [int](../core/int); or `None`; default is `None`  optional index of the first item *not* to be included in the resulting list; generation of the list stops before `stop` is reached. |
-| `step` | [int](../core/int); default is `1`  The increment (default is 1). It may be negative. |
+| `start_or_stop` | [int](/versions/8.3.1/rules/lib/core/int); required  Value of the start element if stop is provided, otherwise value of stop and the actual start is 0 |
+| `stop_or_none` | [int](/versions/8.3.1/rules/lib/core/int); or `None`; default is `None`  optional index of the first item *not* to be included in the resulting list; generation of the list stops before `stop` is reached. |
+| `step` | [int](/versions/8.3.1/rules/lib/core/int); default is `1`  The increment (default is 1). It may be negative. |
 
 ## repr
 
@@ -439,7 +439,7 @@ reversed([3, 5, 4]) == [4, 5, 3]
 set set(elements=[])
 ```
 
-Creates a new [set](../core/set) containing the unique elements of a given
+Creates a new [set](/versions/8.3.1/rules/lib/core/set) containing the unique elements of a given
 iterable, preserving iteration order.
 
 If called with no argument, `set()` returns a new empty set.
@@ -479,7 +479,7 @@ sorted(["two", "three", "four"], key = len) == ["two", "four", "three"]  # sort
 | --- | --- |
 | `iterable` | iterable; required  The iterable sequence to sort. |
 | `key` | callable; or `None`; default is `None`  An optional function applied to each element before comparison. |
-| `reverse` | [bool](../core/bool); default is `False`  Return results in descending order. |
+| `reverse` | [bool](/versions/8.3.1/rules/lib/core/bool); default is `False`  Return results in descending order. |
 
 ## str
 
diff --git a/versions/8.3.1/rules/lib/globals/build.mdx b/versions/8.3.1/rules/lib/globals/build.mdx
index 88c3934c..5b46feca 100644
--- a/versions/8.3.1/rules/lib/globals/build.mdx
+++ b/versions/8.3.1/rules/lib/globals/build.mdx
@@ -28,7 +28,7 @@ Methods available in BUILD files. See also the Build Encyclopedia for extra [fun
 depset depset(direct=None, order="default", *, transitive=None)
 ```
 
-Creates a [depset](../builtins/depset). The `direct` parameter is a list of direct elements of the depset, and `transitive` parameter is a list of depsets whose elements become indirect elements of the created depset. The order in which elements are returned when the depset is converted to a list is specified by the `order` parameter. See the [Depsets overview](https://bazel.build/versions/8.3.1/extending/depsets) for more information.
+Creates a [depset](/versions/8.3.1/rules/lib/builtins/depset). The `direct` parameter is a list of direct elements of the depset, and `transitive` parameter is a list of depsets whose elements become indirect elements of the created depset. The order in which elements are returned when the depset is converted to a list is specified by the `order` parameter. See the [Depsets overview](https://bazel.build/versions/8.3.1/extending/depsets) for more information.
 
 All elements (direct and indirect) of a depset must be of the same type, as obtained by the expression `type(x)`.
 
@@ -42,9 +42,9 @@ The order of the created depset should be *compatible* with the order of its `tr
 
 | Parameter | Description |
 | --- | --- |
-| `direct` | [sequence](../core/list); or `None`; default is `None`  A list of *direct* elements of a depset. |
-| `order` | [string](../core/string); default is `"default"`  The traversal strategy for the new depset. See [here](../builtins/depset) for the possible values. |
-| `transitive` | [sequence](../core/list) of [depset](../builtins/depset)s; or `None`; default is `None`  A list of depsets whose elements will become indirect elements of the depset. |
+| `direct` | [sequence](/versions/8.3.1/rules/lib/core/list); or `None`; default is `None`  A list of *direct* elements of a depset. |
+| `order` | [string](/versions/8.3.1/rules/lib/core/string); default is `"default"`  The traversal strategy for the new depset. See [here](/versions/8.3.1/rules/lib/builtins/depset) for the possible values. |
+| `transitive` | [sequence](/versions/8.3.1/rules/lib/core/list) of [depset](/versions/8.3.1/rules/lib/builtins/depset)s; or `None`; default is `None`  A list of depsets whose elements will become indirect elements of the depset. |
 
 ## existing\_rule
 
@@ -72,7 +72,7 @@ If possible, avoid using this function. It makes BUILD files brittle and order-d
 
 | Parameter | Description |
 | --- | --- |
-| `name` | [string](../core/string); required  The name of the target. |
+| `name` | [string](/versions/8.3.1/rules/lib/core/string); required  The name of the target. |
 
 ## existing\_rules
 
@@ -98,9 +98,9 @@ Specifies a list of files belonging to this package that are exported to other p
 
 | Parameter | Description |
 | --- | --- |
-| `srcs` | [sequence](../core/list) of [string](../core/string)s; required  The list of files to export. |
-| `visibility` | [sequence](../core/list); or `None`; default is `None`  A visibility declaration can to be specified. The files will be visible to the targets specified. If no visibility is specified, the files will be visible to every package. |
-| `licenses` | [sequence](../core/list) of [string](../core/string)s; or `None`; default is `None`  Licenses to be specified. |
+| `srcs` | [sequence](/versions/8.3.1/rules/lib/core/list) of [string](/versions/8.3.1/rules/lib/core/string)s; required  The list of files to export. |
+| `visibility` | [sequence](/versions/8.3.1/rules/lib/core/list); or `None`; default is `None`  A visibility declaration can to be specified. The files will be visible to the targets specified. If no visibility is specified, the files will be visible to every package. |
+| `licenses` | [sequence](/versions/8.3.1/rules/lib/core/list) of [string](/versions/8.3.1/rules/lib/core/string)s; or `None`; default is `None`  Licenses to be specified. |
 
 ## glob
 
@@ -119,9 +119,9 @@ If the `exclude_directories` argument is enabled (set to `1`), files of type dir
 
 | Parameter | Description |
 | --- | --- |
-| `include` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  The list of glob patterns to include. |
-| `exclude` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  The list of glob patterns to exclude. |
-| `exclude_directories` | [int](../core/int); default is `1`  A flag whether to exclude directories or not. |
+| `include` | [sequence](/versions/8.3.1/rules/lib/core/list) of [string](/versions/8.3.1/rules/lib/core/string)s; default is `[]`  The list of glob patterns to include. |
+| `exclude` | [sequence](/versions/8.3.1/rules/lib/core/list) of [string](/versions/8.3.1/rules/lib/core/string)s; default is `[]`  The list of glob patterns to exclude. |
+| `exclude_directories` | [int](/versions/8.3.1/rules/lib/core/int); default is `1`  A flag whether to exclude directories or not. |
 | `allow_empty` | default is `unbound`  Whether we allow glob patterns to match nothing. If `allow\_empty` is False, each individual include pattern must match something and also the final result must be non-empty (after the matches of the `exclude` patterns are excluded). |
 
 ## module\_name
@@ -168,9 +168,9 @@ This function defines a set of packages and assigns a label to the group. The la
 
 | Parameter | Description |
 | --- | --- |
-| `name` | [string](../core/string); required  The unique name for this rule. |
-| `packages` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  A complete enumeration of packages in this group. |
-| `includes` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  Other package groups that are included in this one. |
+| `name` | [string](/versions/8.3.1/rules/lib/core/string); required  The unique name for this rule. |
+| `packages` | [sequence](/versions/8.3.1/rules/lib/core/list) of [string](/versions/8.3.1/rules/lib/core/string)s; default is `[]`  A complete enumeration of packages in this group. |
+| `includes` | [sequence](/versions/8.3.1/rules/lib/core/list) of [string](/versions/8.3.1/rules/lib/core/string)s; default is `[]`  Other package groups that are included in this one. |
 
 ## package\_name
 
@@ -186,19 +186,19 @@ The name of the package being evaluated, without the repository name. For exampl
 Label package_relative_label(input)
 ```
 
-Converts the input string into a [Label](../builtins/Label) object, in the context of the package currently being initialized (that is, the `BUILD` file for which the current macro is executing). If the input is already a `Label`, it is returned unchanged.
+Converts the input string into a [Label](/versions/8.3.1/rules/lib/builtins/Label) object, in the context of the package currently being initialized (that is, the `BUILD` file for which the current macro is executing). If the input is already a `Label`, it is returned unchanged.
 
 This function may only be called while evaluating a BUILD file and the macros it directly or indirectly calls; it may not be called in (for instance) a rule implementation function.
 
 The result of this function is the same `Label` value as would be produced by passing the given string to a label-valued attribute of a target declared in the BUILD file.
 
-*Usage note:* The difference between this function and [Label()](../builtins/Label#Label) is that `Label()` uses the context of the package of the `.bzl` file that called it, not the package of the `BUILD` file. Use `Label()` when you need to refer to a fixed target that is hardcoded into the macro, such as a compiler. Use `package_relative_label()` when you need to normalize a label string supplied by the BUILD file to a `Label` object. (There is no way to convert a string to a `Label` in the context of a package other than the BUILD file or the calling .bzl file. For that reason, outer macros should always prefer to pass Label objects to inner macros rather than label strings.)
+*Usage note:* The difference between this function and [Label()](/versions/8.3.1/rules/lib/builtins/Label#Label) is that `Label()` uses the context of the package of the `.bzl` file that called it, not the package of the `BUILD` file. Use `Label()` when you need to refer to a fixed target that is hardcoded into the macro, such as a compiler. Use `package_relative_label()` when you need to normalize a label string supplied by the BUILD file to a `Label` object. (There is no way to convert a string to a `Label` in the context of a package other than the BUILD file or the calling .bzl file. For that reason, outer macros should always prefer to pass Label objects to inner macros rather than label strings.)
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `input` | [string](../core/string); or [Label](../builtins/Label); required  The input label string or Label object. If a Label object is passed, it's returned as is. |
+| `input` | [string](/versions/8.3.1/rules/lib/core/string); or [Label](/versions/8.3.1/rules/lib/builtins/Label); required  The input label string or Label object. If a Label object is passed, it's returned as is. |
 
 ## repo\_name
 
@@ -231,8 +231,8 @@ unknown select(x, no_match_error='')
 
 | Parameter | Description |
 | --- | --- |
-| `x` | [dict](../core/dict); required |
-| `no_match_error` | [string](../core/string); default is `''`  Optional custom error to report if no condition matches. |
+| `x` | [dict](/versions/8.3.1/rules/lib/core/dict); required |
+| `no_match_error` | [string](/versions/8.3.1/rules/lib/core/string); default is `''`  Optional custom error to report if no condition matches. |
 
 ## subpackages
 
@@ -246,6 +246,6 @@ Returns a new mutable list of every direct subpackage of the current package, re
 
 | Parameter | Description |
 | --- | --- |
-| `include` | [sequence](../core/list) of [string](../core/string)s; required  The list of glob patterns to include in subpackages scan. |
-| `exclude` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  The list of glob patterns to exclude from subpackages scan. |
-| `allow_empty` | [bool](../core/bool); default is `False`  Whether we fail if the call returns an empty list. By default empty list indicates potential error in BUILD file where the call to subpackages() is superflous. Setting to true allows this function to succeed in that case. |*
\ No newline at end of file
+| `include` | [sequence](/versions/8.3.1/rules/lib/core/list) of [string](/versions/8.3.1/rules/lib/core/string)s; required  The list of glob patterns to include in subpackages scan. |
+| `exclude` | [sequence](/versions/8.3.1/rules/lib/core/list) of [string](/versions/8.3.1/rules/lib/core/string)s; default is `[]`  The list of glob patterns to exclude from subpackages scan. |
+| `allow_empty` | [bool](/versions/8.3.1/rules/lib/core/bool); default is `False`  Whether we fail if the call returns an empty list. By default empty list indicates potential error in BUILD file where the call to subpackages() is superflous. Setting to true allows this function to succeed in that case. |*
\ No newline at end of file
diff --git a/versions/8.3.1/rules/lib/globals/bzl.mdx b/versions/8.3.1/rules/lib/globals/bzl.mdx
index 49ffd8d4..4ea72525 100644
--- a/versions/8.3.1/rules/lib/globals/bzl.mdx
+++ b/versions/8.3.1/rules/lib/globals/bzl.mdx
@@ -28,7 +28,7 @@ Global methods available in all .bzl files.
 transition analysis_test_transition(settings)
 ```
 
-Creates a configuration transition to be applied on an analysis-test rule's dependencies. This transition may only be applied on attributes of rules with `analysis_test = True`. Such rules are restricted in capabilities (for example, the size of their dependency tree is limited), so transitions created using this function are limited in potential scope as compared to transitions created using [`transition()`](../builtins/transition).
+Creates a configuration transition to be applied on an analysis-test rule's dependencies. This transition may only be applied on attributes of rules with `analysis_test = True`. Such rules are restricted in capabilities (for example, the size of their dependency tree is limited), so transitions created using this function are limited in potential scope as compared to transitions created using [`transition()`](/versions/8.3.1/rules/lib/builtins/transition).
 
 This function is primarily designed to facilitate the [Analysis Test Framework](https://bazel.build/versions/8.3.1/rules/testing) core library. See its documentation (or its implementation) for best practices.
 
@@ -36,7 +36,7 @@ This function is primarily designed to facilitate the [Analysis Test Framework](
 
 | Parameter | Description |
 | --- | --- |
-| `settings` | [dict](../core/dict); required  A dictionary containing information about configuration settings which should be set by this configuration transition. Keys are build setting labels and values are their new post-transition values. All other settings are unchanged. Use this to declare specific configuration settings that an analysis test requires to be set in order to pass. |
+| `settings` | [dict](/versions/8.3.1/rules/lib/core/dict); required  A dictionary containing information about configuration settings which should be set by this configuration transition. Keys are build setting labels and values are their new post-transition values. All other settings are unchanged. Use this to declare specific configuration settings that an analysis test requires to be set in order to pass. |
 
 ## aspect
 
@@ -50,23 +50,23 @@ Creates a new aspect. The result of this function must be stored in a global val
 
 | Parameter | Description |
 | --- | --- |
-| `implementation` | [function](../core/function); required  A Starlark function that implements this aspect, with exactly two parameters: [Target](../builtins/Target) (the target to which the aspect is applied) and [ctx](../builtins/ctx) (the rule context which the target is created from). Attributes of the target are available via the `ctx.rule` field. This function is evaluated during the analysis phase for each application of an aspect to a target. |
-| `attr_aspects` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  List of attribute names. The aspect propagates along dependencies specified in the attributes of a target with these names. Common values here include `deps` and `exports`. The list can also contain a single string `"*"` to propagate along all dependencies of a target. |
-| `toolchains_aspects` | [sequence](../core/list); default is `[]`  List of toolchain types. The aspect propagates to target toolchains which match these toolchain types. |
-| `attrs` | [dict](../core/dict); default is `{}`  A dictionary declaring all the attributes of the aspect. It maps from an attribute name to an attribute object, like `attr.label` or `attr.string` (see [`attr`](../toplevel/attr) module). Aspect attributes are available to implementation function as fields of `ctx` parameter. Implicit attributes starting with `_` must have default values, and have type `label` or `label_list`.  Explicit attributes must have type `string`, and must use the `values` restriction. Explicit attributes restrict the aspect to only be used with rules that have attributes of the same name, type, and valid values according to the restriction.  Declared attributes will convert `None` to the default value. |
-| `required_providers` | [sequence](../core/list); default is `[]`  This attribute allows the aspect to limit its propagation to only the targets whose rules advertise its required providers. The value must be a list containing either individual providers or lists of providers but not both. For example, `[[FooInfo], [BarInfo], [BazInfo, QuxInfo]]` is a valid value while `[FooInfo, BarInfo, [BazInfo, QuxInfo]]` is not valid. An unnested list of providers will automatically be converted to a list containing one list of providers. That is, `[FooInfo, BarInfo]` will automatically be converted to `[[FooInfo, BarInfo]]`. To make some rule (e.g. `some_rule`) targets visible to an aspect, `some_rule` must advertise all providers from at least one of the required providers lists. For example, if the `required_providers` of an aspect are `[[FooInfo], [BarInfo], [BazInfo, QuxInfo]]`, this aspect can see `some_rule` targets if and only if `some_rule` provides `FooInfo`, *or* `BarInfo`, *or* both `BazInfo` *and* `QuxInfo`. |
-| `required_aspect_providers` | [sequence](../core/list); default is `[]`  This attribute allows this aspect to inspect other aspects. The value must be a list containing either individual providers or lists of providers but not both. For example, `[[FooInfo], [BarInfo], [BazInfo, QuxInfo]]` is a valid value while `[FooInfo, BarInfo, [BazInfo, QuxInfo]]` is not valid. An unnested list of providers will automatically be converted to a list containing one list of providers. That is, `[FooInfo, BarInfo]` will automatically be converted to `[[FooInfo, BarInfo]]`. To make another aspect (e.g. `other_aspect`) visible to this aspect, `other_aspect` must provide all providers from at least one of the lists. In the example of `[[FooInfo], [BarInfo], [BazInfo, QuxInfo]]`, this aspect can see `other_aspect` if and only if `other_aspect` provides `FooInfo`, *or* `BarInfo`, *or* both `BazInfo` *and* `QuxInfo`. |
-| `provides` | [sequence](../core/list); default is `[]`  A list of providers that the implementation function must return. It is an error if the implementation function omits any of the types of providers listed here from its return value. However, the implementation function may return additional providers not listed here. Each element of the list is an `*Info` object returned by [`provider()`](../globals/bzl#provider), except that a legacy provider is represented by its string name instead.When a target of the rule is used as a dependency for a target that declares a required provider, it is not necessary to specify that provider here. It is enough that the implementation function returns it. However, it is considered best practice to specify it, even though this is not required. The [`required_providers`](../globals/bzl#aspect.required_providers) field of an [aspect](../globals/bzl#aspect) does, however, require that providers are specified here. |
-| `requires` | [sequence](../core/list) of [Aspect](../builtins/Aspect)s; default is `[]`  List of aspects required to be propagated before this aspect. |
-| `fragments` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  List of names of configuration fragments that the aspect requires in target configuration. |
-| `host_fragments` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  List of names of configuration fragments that the aspect requires in host configuration. |
-| `toolchains` | [sequence](../core/list); default is `[]`  If set, the set of toolchains this aspect requires. The list can contain String, Label, or StarlarkToolchainTypeApi objects, in any combination. Toolchains will be found by checking the current platform, and provided to the aspect implementation via `ctx.toolchain`. |
-| `incompatible_use_toolchain_transition` | [bool](../core/bool); default is `False`  Deprecated, this is no longer in use and should be removed. |
-| `doc` | [string](../core/string); or `None`; default is `None`  A description of the aspect that can be extracted by documentation generating tools. |
-| `apply_to_generating_rules` | [bool](../core/bool); default is `False`  If true, the aspect will, when applied to an output file, instead apply to the output file's generating rule. For example, suppose an aspect propagates transitively through attribute `deps` and it is applied to target `alpha`. Suppose `alpha` has `deps = [':beta\_output']`, where `beta\_output` is a declared output of a target `beta`. Suppose `beta` has a target `charlie` as one of its `deps`. If `apply\_to\_generating\_rules=True` for the aspect, then the aspect will propagate through `alpha`, `beta`, and `charlie`. If False, then the aspect will propagate only to `alpha`.  False by default. |
-| `exec_compatible_with` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  A list of constraints on the execution platform that apply to all instances of this aspect. |
-| `exec_groups` | [dict](../core/dict); or `None`; default is `None`  Dict of execution group name (string) to [`exec_group`s](../globals/bzl#exec_group). If set, allows aspects to run actions on multiple execution platforms within a single instance. See [execution groups documentation](/versions/8.3.1/reference/exec-groups) for more info. |
-| `subrules` | [sequence](../core/list) of [Subrule](../builtins/Subrule)s; default is `[]`  Experimental: list of subrules used by this aspect. |
+| `implementation` | [function](/versions/8.3.1/rules/lib/core/function); required  A Starlark function that implements this aspect, with exactly two parameters: [Target](/versions/8.3.1/rules/lib/builtins/Target) (the target to which the aspect is applied) and [ctx](/versions/8.3.1/rules/lib/builtins/ctx) (the rule context which the target is created from). Attributes of the target are available via the `ctx.rule` field. This function is evaluated during the analysis phase for each application of an aspect to a target. |
+| `attr_aspects` | [sequence](/versions/8.3.1/rules/lib/core/list) of [string](/versions/8.3.1/rules/lib/core/string)s; default is `[]`  List of attribute names. The aspect propagates along dependencies specified in the attributes of a target with these names. Common values here include `deps` and `exports`. The list can also contain a single string `"*"` to propagate along all dependencies of a target. |
+| `toolchains_aspects` | [sequence](/versions/8.3.1/rules/lib/core/list); default is `[]`  List of toolchain types. The aspect propagates to target toolchains which match these toolchain types. |
+| `attrs` | [dict](/versions/8.3.1/rules/lib/core/dict); default is `{}`  A dictionary declaring all the attributes of the aspect. It maps from an attribute name to an attribute object, like `attr.label` or `attr.string` (see [`attr`](/versions/8.3.1/rules/lib/toplevel/attr) module). Aspect attributes are available to implementation function as fields of `ctx` parameter. Implicit attributes starting with `_` must have default values, and have type `label` or `label_list`.  Explicit attributes must have type `string`, and must use the `values` restriction. Explicit attributes restrict the aspect to only be used with rules that have attributes of the same name, type, and valid values according to the restriction.  Declared attributes will convert `None` to the default value. |
+| `required_providers` | [sequence](/versions/8.3.1/rules/lib/core/list); default is `[]`  This attribute allows the aspect to limit its propagation to only the targets whose rules advertise its required providers. The value must be a list containing either individual providers or lists of providers but not both. For example, `[[FooInfo], [BarInfo], [BazInfo, QuxInfo]]` is a valid value while `[FooInfo, BarInfo, [BazInfo, QuxInfo]]` is not valid. An unnested list of providers will automatically be converted to a list containing one list of providers. That is, `[FooInfo, BarInfo]` will automatically be converted to `[[FooInfo, BarInfo]]`. To make some rule (e.g. `some_rule`) targets visible to an aspect, `some_rule` must advertise all providers from at least one of the required providers lists. For example, if the `required_providers` of an aspect are `[[FooInfo], [BarInfo], [BazInfo, QuxInfo]]`, this aspect can see `some_rule` targets if and only if `some_rule` provides `FooInfo`, *or* `BarInfo`, *or* both `BazInfo` *and* `QuxInfo`. |
+| `required_aspect_providers` | [sequence](/versions/8.3.1/rules/lib/core/list); default is `[]`  This attribute allows this aspect to inspect other aspects. The value must be a list containing either individual providers or lists of providers but not both. For example, `[[FooInfo], [BarInfo], [BazInfo, QuxInfo]]` is a valid value while `[FooInfo, BarInfo, [BazInfo, QuxInfo]]` is not valid. An unnested list of providers will automatically be converted to a list containing one list of providers. That is, `[FooInfo, BarInfo]` will automatically be converted to `[[FooInfo, BarInfo]]`. To make another aspect (e.g. `other_aspect`) visible to this aspect, `other_aspect` must provide all providers from at least one of the lists. In the example of `[[FooInfo], [BarInfo], [BazInfo, QuxInfo]]`, this aspect can see `other_aspect` if and only if `other_aspect` provides `FooInfo`, *or* `BarInfo`, *or* both `BazInfo` *and* `QuxInfo`. |
+| `provides` | [sequence](/versions/8.3.1/rules/lib/core/list); default is `[]`  A list of providers that the implementation function must return. It is an error if the implementation function omits any of the types of providers listed here from its return value. However, the implementation function may return additional providers not listed here. Each element of the list is an `*Info` object returned by [`provider()`](/versions/8.3.1/rules/lib/globals/bzl#provider), except that a legacy provider is represented by its string name instead.When a target of the rule is used as a dependency for a target that declares a required provider, it is not necessary to specify that provider here. It is enough that the implementation function returns it. However, it is considered best practice to specify it, even though this is not required. The [`required_providers`](/versions/8.3.1/rules/lib/globals/bzl#aspect.required_providers) field of an [aspect](/versions/8.3.1/rules/lib/globals/bzl#aspect) does, however, require that providers are specified here. |
+| `requires` | [sequence](/versions/8.3.1/rules/lib/core/list) of [Aspect](/versions/8.3.1/rules/lib/builtins/Aspect)s; default is `[]`  List of aspects required to be propagated before this aspect. |
+| `fragments` | [sequence](/versions/8.3.1/rules/lib/core/list) of [string](/versions/8.3.1/rules/lib/core/string)s; default is `[]`  List of names of configuration fragments that the aspect requires in target configuration. |
+| `host_fragments` | [sequence](/versions/8.3.1/rules/lib/core/list) of [string](/versions/8.3.1/rules/lib/core/string)s; default is `[]`  List of names of configuration fragments that the aspect requires in host configuration. |
+| `toolchains` | [sequence](/versions/8.3.1/rules/lib/core/list); default is `[]`  If set, the set of toolchains this aspect requires. The list can contain String, Label, or StarlarkToolchainTypeApi objects, in any combination. Toolchains will be found by checking the current platform, and provided to the aspect implementation via `ctx.toolchain`. |
+| `incompatible_use_toolchain_transition` | [bool](/versions/8.3.1/rules/lib/core/bool); default is `False`  Deprecated, this is no longer in use and should be removed. |
+| `doc` | [string](/versions/8.3.1/rules/lib/core/string); or `None`; default is `None`  A description of the aspect that can be extracted by documentation generating tools. |
+| `apply_to_generating_rules` | [bool](/versions/8.3.1/rules/lib/core/bool); default is `False`  If true, the aspect will, when applied to an output file, instead apply to the output file's generating rule. For example, suppose an aspect propagates transitively through attribute `deps` and it is applied to target `alpha`. Suppose `alpha` has `deps = [':beta\_output']`, where `beta\_output` is a declared output of a target `beta`. Suppose `beta` has a target `charlie` as one of its `deps`. If `apply\_to\_generating\_rules=True` for the aspect, then the aspect will propagate through `alpha`, `beta`, and `charlie`. If False, then the aspect will propagate only to `alpha`.  False by default. |
+| `exec_compatible_with` | [sequence](/versions/8.3.1/rules/lib/core/list) of [string](/versions/8.3.1/rules/lib/core/string)s; default is `[]`  A list of constraints on the execution platform that apply to all instances of this aspect. |
+| `exec_groups` | [dict](/versions/8.3.1/rules/lib/core/dict); or `None`; default is `None`  Dict of execution group name (string) to [`exec_group`s](/versions/8.3.1/rules/lib/globals/bzl#exec_group). If set, allows aspects to run actions on multiple execution platforms within a single instance. See [execution groups documentation](/versions/8.3.1/reference/exec-groups) for more info. |
+| `subrules` | [sequence](/versions/8.3.1/rules/lib/core/list) of [Subrule](/versions/8.3.1/rules/lib/builtins/Subrule)s; default is `[]`  Experimental: list of subrules used by this aspect. |
 
 ## configuration\_field
 
@@ -74,7 +74,7 @@ Creates a new aspect. The result of this function must be stored in a global val
 LateBoundDefault configuration_field(fragment, name)
 ```
 
-References a late-bound default value for an attribute of type [label](../toplevel/attr#label). A value is 'late-bound' if it requires the configuration to be built before determining the value. Any attribute using this as a value must [be private](https://bazel.build/versions/8.3.1/extending/rules#private-attributes).
+References a late-bound default value for an attribute of type [label](/versions/8.3.1/rules/lib/toplevel/attr#label). A value is 'late-bound' if it requires the configuration to be built before determining the value. Any attribute using this as a value must [be private](https://bazel.build/versions/8.3.1/extending/rules#private-attributes).
 
 Example usage:
 
@@ -96,8 +96,8 @@ Accessing in rule implementation:
 
 | Parameter | Description |
 | --- | --- |
-| `fragment` | [string](../core/string); required |
-| `name` | [string](../core/string); required |
+| `fragment` | [string](/versions/8.3.1/rules/lib/core/string); required |
+| `name` | [string](/versions/8.3.1/rules/lib/core/string); required |
 
 ## depset
 
@@ -105,7 +105,7 @@ Accessing in rule implementation:
 depset depset(direct=None, order="default", *, transitive=None)
 ```
 
-Creates a [depset](../builtins/depset). The `direct` parameter is a list of direct elements of the depset, and `transitive` parameter is a list of depsets whose elements become indirect elements of the created depset. The order in which elements are returned when the depset is converted to a list is specified by the `order` parameter. See the [Depsets overview](https://bazel.build/versions/8.3.1/extending/depsets) for more information.
+Creates a [depset](/versions/8.3.1/rules/lib/builtins/depset). The `direct` parameter is a list of direct elements of the depset, and `transitive` parameter is a list of depsets whose elements become indirect elements of the created depset. The order in which elements are returned when the depset is converted to a list is specified by the `order` parameter. See the [Depsets overview](https://bazel.build/versions/8.3.1/extending/depsets) for more information.
 
 All elements (direct and indirect) of a depset must be of the same type, as obtained by the expression `type(x)`.
 
@@ -119,9 +119,9 @@ The order of the created depset should be *compatible* with the order of its `tr
 
 | Parameter | Description |
 | --- | --- |
-| `direct` | [sequence](../core/list); or `None`; default is `None`  A list of *direct* elements of a depset. |
-| `order` | [string](../core/string); default is `"default"`  The traversal strategy for the new depset. See [here](../builtins/depset) for the possible values. |
-| `transitive` | [sequence](../core/list) of [depset](../builtins/depset)s; or `None`; default is `None`  A list of depsets whose elements will become indirect elements of the depset. |
+| `direct` | [sequence](/versions/8.3.1/rules/lib/core/list); or `None`; default is `None`  A list of *direct* elements of a depset. |
+| `order` | [string](/versions/8.3.1/rules/lib/core/string); default is `"default"`  The traversal strategy for the new depset. See [here](/versions/8.3.1/rules/lib/builtins/depset) for the possible values. |
+| `transitive` | [sequence](/versions/8.3.1/rules/lib/core/list) of [depset](/versions/8.3.1/rules/lib/builtins/depset)s; or `None`; default is `None`  A list of depsets whose elements will become indirect elements of the depset. |
 
 ## exec\_group
 
@@ -135,8 +135,8 @@ Creates an [execution group](/versions/8.3.1/reference/exec-groups) which can be
 
 | Parameter | Description |
 | --- | --- |
-| `toolchains` | [sequence](../core/list); default is `[]`  The set of toolchains this execution group requires. The list can contain String, Label, or StarlarkToolchainTypeApi objects, in any combination. |
-| `exec_compatible_with` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  A list of constraints on the execution platform. |
+| `toolchains` | [sequence](/versions/8.3.1/rules/lib/core/list); default is `[]`  The set of toolchains this execution group requires. The list can contain String, Label, or StarlarkToolchainTypeApi objects, in any combination. |
+| `exec_compatible_with` | [sequence](/versions/8.3.1/rules/lib/core/list) of [string](/versions/8.3.1/rules/lib/core/string)s; default is `[]`  A list of constraints on the execution platform. |
 
 ## exec\_transition
 
@@ -144,15 +144,15 @@ Creates an [execution group](/versions/8.3.1/reference/exec-groups) which can be
 transition exec_transition(implementation, inputs, outputs)
 ```
 
-A specialized version of [`transition()`](../builtins/transition) used to define the exec transition. See its documentation (or its implementation) for best practices. Only usable from the Bazel builtins.
+A specialized version of [`transition()`](/versions/8.3.1/rules/lib/builtins/transition) used to define the exec transition. See its documentation (or its implementation) for best practices. Only usable from the Bazel builtins.
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
 | `implementation` | callable; required |
-| `inputs` | [sequence](../core/list) of [string](../core/string)s; required |
-| `outputs` | [sequence](../core/list) of [string](../core/string)s; required |
+| `inputs` | [sequence](/versions/8.3.1/rules/lib/core/list) of [string](/versions/8.3.1/rules/lib/core/string)s; required |
+| `outputs` | [sequence](/versions/8.3.1/rules/lib/core/list) of [string](/versions/8.3.1/rules/lib/core/string)s; required |
 
 ## macro
 
@@ -173,11 +173,11 @@ macros.
 
 | Parameter | Description |
 | --- | --- |
-| `implementation` | [function](../core/function); required  The Starlark function implementing this macro. The values of the macro's attributes are passed to the implementation function as keyword arguments. The implementation function must have at least two named parameters, `name` and `visibility`, and if the macro inherits attributes (see `inherit_attrs` below), it must have a `**kwargs` residual keyword parameter. By convention, the implementation function should have a named parameter for any attribute that the macro needs to examine, modify, or pass to non-"main" targets, while the "bulk" inherited attributes which will be passed to the "main" target unchanged are passed as `**kwargs`. The implementation function must not return a value. Instead, the implementation function *declares targets* by calling rule or macro symbols. The name of any target or inner symbolic macro declared by a symbolic macro (including by any Starlark function that the macro's implementation function transitively calls) must either equal `name` (this is referred to as the "main" target) or start with `name`, followed by a separator chracter (`"_"`, `"-"`, or `"."`) and a string suffix. (Targets violating this naming scheme are allowed to be declared, but cannot be built, configured, or depended upon.) By default, targets declared by a symbolic macro (including by any Starlark function that the macro's implementation function transitively calls) are visible only in the package containing the .bzl file defining the macro. To declare targets visible externally, *including to the caller of the symbolic macro*, the implementation function must set `visibility` appropriately – typically, by passing `visibility = visibility` to the rule or macro symbol being called. The following APIs are unavailable within a macro implementation function and any Starlark function it transitively calls:  * [`package()`, `licenses()`* `environment_group()`* [`native.glob()`](../toplevel/native#glob) – instead, you may pass       a glob into the macro via a label list attribute* [`native.subpackages()`](../toplevel/native#subpackages)* (allowed in rule finalizers only, see `finalizer` below)           [`native.existing_rules()`](../toplevel/native#existing_rules),           [`native.existing_rule()`](../toplevel/native#existing_rule)* (for `WORKSPACE` threads)             [`workspace()`](../globals/workspace#workspace),             [`register_toolchains()`](../globals/workspace#register_toolchains),             [`bind()`](../globals/workspace#bind), [`register_execution_platforms()`](../globals/workspace#register_execution_platforms), repository rule instantiation |
-| `attrs` | [dict](../core/dict); default is `{}`  A dictionary of the attributes this macro supports, analogous to [rule.attrs](#rule.attrs). Keys are attribute names, and values are either attribute objects like `attr.label_list(...)` (see the [attr](../toplevel/attr) module), or `None`. A `None` entry means that the macro does not have an attribute by that name, even if it would have otherwise inherited one via `inherit_attrs` (see below). The special `name` attribute is predeclared and must not be included in the dictionary. The `visibility` attribute name is reserved and must not be included in the dictionary. Attributes whose names start with `_` are private -- they cannot be passed at the call site of the rule. Such attributes can be assigned a default value (as in `attr.label(default="//pkg:foo")`) to create an implicit dependency on a label. To limit memory usage, there is a cap on the number of attributes that may be declared. |
-| `inherit_attrs` | [rule](../builtins/rule); or [macro](../builtins/macro); or [string](../core/string); or `None`; default is `None`  A rule symbol, macro symbol, or the name of a built-in common attribute list (see below) from which the macro should inherit attributes. If `inherit_attrs` is set to the string `"common"`, the macro will inherit [common rule attribute definitions](/versions/8.3.1/reference/be/common-definitions#common-attributes) used by all Starlark rules. Note that if the return value of `rule()` or `macro()` was not assigned to a global variable in a .bzl file, then such a value has not been registered as a rule or macro symbol, and therefore cannot be used for `inherit_attrs`. The inheritance mechanism works as follows:   1. The special `name` and `visibility` attributes are never inherited;- Hidden attributes (ones whose name starts with `"_"`) are never inherited;- Attributes whose names are already defined in the `attrs` dictionary are never        inherited (the entry in `attrs` takes precedence; note that an entry may be set to        `None` to ensure that no attribute by that name gets defined on the macro);- All other attributes are inherited from the rule or macro and effectively merged into the          `attrs` dict.   When a non-mandatory attribute is inherited, the default value of the attribute is overridden to be `None`, regardless of what it was specified in the original rule or macro. This ensures that when the macro forwards the attribute's value to an instance of the wrapped rule or macro – such as by passing in the unmodified `**kwargs` – a value that was absent from the outer macro's call will also be absent in the inner rule or macro's call (since passing `None` to an attribute is treated the same as omitting the attribute). This is important because omitting an attribute has subtly different semantics from passing its apparent default value. In particular, omitted attributes are not shown in some `bazel query` output formats, and computed defaults only execute when the value is omitted. If the macro needs to examine or modify an inherited attribute – for example, to add a value to an inherited `tags` attribute – you must make sure to handle the `None` case in the macro's implementation function. For example, the following macro inherits all attributes from `native.cc_library`, except for `cxxopts` (which is removed from the attribute list) and `copts` (which is given a new definition). It also takes care to checks for the default `None` value of the inherited `tags` attribute before appending an additional tag.  ``` def _my_cc_library_impl(name, visibility, tags, **kwargs):     # Append a tag; tags attr was inherited from native.cc_library, and     # therefore is None unless explicitly set by the caller of my_cc_library()     my_tags = (tags or []) + ["my_custom_tag"]     native.cc_library(         name = name,         visibility = visibility,         tags = my_tags,         **kwargs     )  my_cc_library = macro(     implementation = _my_cc_library_impl,     inherit_attrs = native.cc_library,     attrs = {         "cxxopts": None,         "copts": attr.string_list(default = ["-D_FOO"]),     }, ) ```   If `inherit_attrs` is set, the macro's implementation function *must* have a `**kwargs` residual keyword parameter. By convention, a macro should pass inherited, non-overridden attributes unchanged to the "main" rule or macro symbol which the macro is wrapping. Typically, most inherited attributes will not have a parameter in the implementation function's parameter list, and will simply be passed via `**kwargs`. It can be convenient for the implementation function to have explicit parameters for some inherited attributes (most commonly, `tags` and `testonly`) if the macro needs to pass those attributes to both "main" and non-"main" targets – but if the macro also needs to examine or manipulate those attributes, you must take care to handle the `None` default value of non-mandatory inherited attributes. |
-| `finalizer` | [bool](../core/bool); default is `False`  Whether this macro is a rule finalizer, which is a macro that, regardless of its position in a `BUILD` file, is evaluated at the end of package loading, after all non-finalizer targets have been defined. Unlike ordinary symbolic macros, rule finalizers may call [`native.existing_rule()`](../toplevel/native#existing_rule) and [`native.existing_rules()`](../toplevel/native#existing_rules) to query the set of *non-finalizer* rule targets defined in the current package. Note that `native.existing_rule()` and `native.existing_rules()` cannot access the targets defined by any rule finalizer, including this one. |
-| `doc` | [string](../core/string); or `None`; default is `None`  A description of the macro that can be extracted by documentation generating tools. |
+| `implementation` | [function](/versions/8.3.1/rules/lib/core/function); required  The Starlark function implementing this macro. The values of the macro's attributes are passed to the implementation function as keyword arguments. The implementation function must have at least two named parameters, `name` and `visibility`, and if the macro inherits attributes (see `inherit_attrs` below), it must have a `**kwargs` residual keyword parameter. By convention, the implementation function should have a named parameter for any attribute that the macro needs to examine, modify, or pass to non-"main" targets, while the "bulk" inherited attributes which will be passed to the "main" target unchanged are passed as `**kwargs`. The implementation function must not return a value. Instead, the implementation function *declares targets* by calling rule or macro symbols. The name of any target or inner symbolic macro declared by a symbolic macro (including by any Starlark function that the macro's implementation function transitively calls) must either equal `name` (this is referred to as the "main" target) or start with `name`, followed by a separator chracter (`"_"`, `"-"`, or `"."`) and a string suffix. (Targets violating this naming scheme are allowed to be declared, but cannot be built, configured, or depended upon.) By default, targets declared by a symbolic macro (including by any Starlark function that the macro's implementation function transitively calls) are visible only in the package containing the .bzl file defining the macro. To declare targets visible externally, *including to the caller of the symbolic macro*, the implementation function must set `visibility` appropriately – typically, by passing `visibility = visibility` to the rule or macro symbol being called. The following APIs are unavailable within a macro implementation function and any Starlark function it transitively calls:  * [`package()`, `licenses()`* `environment_group()`* [`native.glob()`](/versions/8.3.1/rules/lib/toplevel/native#glob) – instead, you may pass       a glob into the macro via a label list attribute* [`native.subpackages()`](/versions/8.3.1/rules/lib/toplevel/native#subpackages)* (allowed in rule finalizers only, see `finalizer` below)           [`native.existing_rules()`](/versions/8.3.1/rules/lib/toplevel/native#existing_rules),           [`native.existing_rule()`](/versions/8.3.1/rules/lib/toplevel/native#existing_rule)* (for `WORKSPACE` threads)             [`workspace()`](/versions/8.3.1/rules/lib/globals/workspace#workspace),             [`register_toolchains()`](/versions/8.3.1/rules/lib/globals/workspace#register_toolchains),             [`bind()`](/versions/8.3.1/rules/lib/globals/workspace#bind), [`register_execution_platforms()`](/versions/8.3.1/rules/lib/globals/workspace#register_execution_platforms), repository rule instantiation |
+| `attrs` | [dict](/versions/8.3.1/rules/lib/core/dict); default is `{}`  A dictionary of the attributes this macro supports, analogous to [rule.attrs](#rule.attrs). Keys are attribute names, and values are either attribute objects like `attr.label_list(...)` (see the [attr](/versions/8.3.1/rules/lib/toplevel/attr) module), or `None`. A `None` entry means that the macro does not have an attribute by that name, even if it would have otherwise inherited one via `inherit_attrs` (see below). The special `name` attribute is predeclared and must not be included in the dictionary. The `visibility` attribute name is reserved and must not be included in the dictionary. Attributes whose names start with `_` are private -- they cannot be passed at the call site of the rule. Such attributes can be assigned a default value (as in `attr.label(default="//pkg:foo")`) to create an implicit dependency on a label. To limit memory usage, there is a cap on the number of attributes that may be declared. |
+| `inherit_attrs` | [rule](/versions/8.3.1/rules/lib/builtins/rule); or [macro](/versions/8.3.1/rules/lib/builtins/macro); or [string](/versions/8.3.1/rules/lib/core/string); or `None`; default is `None`  A rule symbol, macro symbol, or the name of a built-in common attribute list (see below) from which the macro should inherit attributes. If `inherit_attrs` is set to the string `"common"`, the macro will inherit [common rule attribute definitions](/versions/8.3.1/reference/be/common-definitions#common-attributes) used by all Starlark rules. Note that if the return value of `rule()` or `macro()` was not assigned to a global variable in a .bzl file, then such a value has not been registered as a rule or macro symbol, and therefore cannot be used for `inherit_attrs`. The inheritance mechanism works as follows:   1. The special `name` and `visibility` attributes are never inherited;- Hidden attributes (ones whose name starts with `"_"`) are never inherited;- Attributes whose names are already defined in the `attrs` dictionary are never        inherited (the entry in `attrs` takes precedence; note that an entry may be set to        `None` to ensure that no attribute by that name gets defined on the macro);- All other attributes are inherited from the rule or macro and effectively merged into the          `attrs` dict.   When a non-mandatory attribute is inherited, the default value of the attribute is overridden to be `None`, regardless of what it was specified in the original rule or macro. This ensures that when the macro forwards the attribute's value to an instance of the wrapped rule or macro – such as by passing in the unmodified `**kwargs` – a value that was absent from the outer macro's call will also be absent in the inner rule or macro's call (since passing `None` to an attribute is treated the same as omitting the attribute). This is important because omitting an attribute has subtly different semantics from passing its apparent default value. In particular, omitted attributes are not shown in some `bazel query` output formats, and computed defaults only execute when the value is omitted. If the macro needs to examine or modify an inherited attribute – for example, to add a value to an inherited `tags` attribute – you must make sure to handle the `None` case in the macro's implementation function. For example, the following macro inherits all attributes from `native.cc_library`, except for `cxxopts` (which is removed from the attribute list) and `copts` (which is given a new definition). It also takes care to checks for the default `None` value of the inherited `tags` attribute before appending an additional tag.  ``` def _my_cc_library_impl(name, visibility, tags, **kwargs):     # Append a tag; tags attr was inherited from native.cc_library, and     # therefore is None unless explicitly set by the caller of my_cc_library()     my_tags = (tags or []) + ["my_custom_tag"]     native.cc_library(         name = name,         visibility = visibility,         tags = my_tags,         **kwargs     )  my_cc_library = macro(     implementation = _my_cc_library_impl,     inherit_attrs = native.cc_library,     attrs = {         "cxxopts": None,         "copts": attr.string_list(default = ["-D_FOO"]),     }, ) ```   If `inherit_attrs` is set, the macro's implementation function *must* have a `**kwargs` residual keyword parameter. By convention, a macro should pass inherited, non-overridden attributes unchanged to the "main" rule or macro symbol which the macro is wrapping. Typically, most inherited attributes will not have a parameter in the implementation function's parameter list, and will simply be passed via `**kwargs`. It can be convenient for the implementation function to have explicit parameters for some inherited attributes (most commonly, `tags` and `testonly`) if the macro needs to pass those attributes to both "main" and non-"main" targets – but if the macro also needs to examine or manipulate those attributes, you must take care to handle the `None` default value of non-mandatory inherited attributes. |
+| `finalizer` | [bool](/versions/8.3.1/rules/lib/core/bool); default is `False`  Whether this macro is a rule finalizer, which is a macro that, regardless of its position in a `BUILD` file, is evaluated at the end of package loading, after all non-finalizer targets have been defined. Unlike ordinary symbolic macros, rule finalizers may call [`native.existing_rule()`](/versions/8.3.1/rules/lib/toplevel/native#existing_rule) and [`native.existing_rules()`](/versions/8.3.1/rules/lib/toplevel/native#existing_rules) to query the set of *non-finalizer* rule targets defined in the current package. Note that `native.existing_rule()` and `native.existing_rules()` cannot access the targets defined by any rule finalizer, including this one. |
+| `doc` | [string](/versions/8.3.1/rules/lib/core/string); or `None`; default is `None`  A description of the macro that can be extracted by documentation generating tools. |
 
 ## module\_extension
 
@@ -192,11 +192,11 @@ Creates a new module extension. Store it in a global value, so that it can be ex
 | Parameter | Description |
 | --- | --- |
 | `implementation` | callable; required  The function that implements this module extension. Must take a single parameter, `module_ctx`. The function is called once at the beginning of a build to determine the set of available repos. |
-| `tag_classes` | [dict](../core/dict); default is `{}`  A dictionary to declare all the tag classes used by the extension. It maps from the name of the tag class to a `tag_class` object. |
-| `doc` | [string](../core/string); or `None`; default is `None`  A description of the module extension that can be extracted by documentation generating tools. |
-| `environ` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  Provides a list of environment variable that this module extension depends on. If an environment variable in that list changes, the extension will be re-evaluated. |
-| `os_dependent` | [bool](../core/bool); default is `False`  Indicates whether this extension is OS-dependent or not |
-| `arch_dependent` | [bool](../core/bool); default is `False`  Indicates whether this extension is architecture-dependent or not |
+| `tag_classes` | [dict](/versions/8.3.1/rules/lib/core/dict); default is `{}`  A dictionary to declare all the tag classes used by the extension. It maps from the name of the tag class to a `tag_class` object. |
+| `doc` | [string](/versions/8.3.1/rules/lib/core/string); or `None`; default is `None`  A description of the module extension that can be extracted by documentation generating tools. |
+| `environ` | [sequence](/versions/8.3.1/rules/lib/core/list) of [string](/versions/8.3.1/rules/lib/core/string)s; default is `[]`  Provides a list of environment variable that this module extension depends on. If an environment variable in that list changes, the extension will be re-evaluated. |
+| `os_dependent` | [bool](/versions/8.3.1/rules/lib/core/bool); default is `False`  Indicates whether this extension is OS-dependent or not |
+| `arch_dependent` | [bool](/versions/8.3.1/rules/lib/core/bool); default is `False`  Indicates whether this extension is architecture-dependent or not |
 
 ## provider
 
@@ -219,16 +219,16 @@ def _my_library_impl(ctx):
 
 See [Rules (Providers)](https://bazel.build/versions/8.3.1/extending/rules#providers) for a comprehensive guide on how to use providers.
 
-Returns a [`Provider`](../builtins/Provider) callable value if `init` is not specified.
+Returns a [`Provider`](/versions/8.3.1/rules/lib/builtins/Provider) callable value if `init` is not specified.
 
-If `init` is specified, returns a tuple of 2 elements: a [`Provider`](../builtins/Provider) callable value and a *raw constructor* callable value. See  [Rules (Custom initialization of custom providers)](https://bazel.build/versions/8.3.1/extending/rules#custom_initialization_of_providers) and the discussion of the `init` parameter below for details.
+If `init` is specified, returns a tuple of 2 elements: a [`Provider`](/versions/8.3.1/rules/lib/builtins/Provider) callable value and a *raw constructor* callable value. See  [Rules (Custom initialization of custom providers)](https://bazel.build/versions/8.3.1/extending/rules#custom_initialization_of_providers) and the discussion of the `init` parameter below for details.
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `doc` | [string](../core/string); or `None`; default is `None` |
-| `fields` | [sequence](../core/list) of [string](../core/string)s; or [dict](../core/dict); or `None`; default is `None`  If specified, restricts the set of allowed fields.  Possible values are:  * list of fields:     ```   provider(fields = ['a', 'b'])   ```     * dictionary field name -> documentation:       ```     provider(            fields = { 'a' : 'Documentation for a', 'b' : 'Documentation for b' })     ```  All fields are optional. |
+| `doc` | [string](/versions/8.3.1/rules/lib/core/string); or `None`; default is `None` |
+| `fields` | [sequence](/versions/8.3.1/rules/lib/core/list) of [string](/versions/8.3.1/rules/lib/core/string)s; or [dict](/versions/8.3.1/rules/lib/core/dict); or `None`; default is `None`  If specified, restricts the set of allowed fields.  Possible values are:  * list of fields:     ```   provider(fields = ['a', 'b'])   ```     * dictionary field name -> documentation:       ```     provider(            fields = { 'a' : 'Documentation for a', 'b' : 'Documentation for b' })     ```  All fields are optional. |
 | `init` | callable; or `None`; default is `None` |
 
 ## repository\_rule
@@ -237,19 +237,19 @@ If `init` is specified, returns a tuple of 2 elements: a [`Provider`](../builtin
 callable repository_rule(implementation, *, attrs=None, local=False, environ=[], configure=False, remotable=False, doc=None)
 ```
 
-Creates a new repository rule. Store it in a global value, so that it can be loaded and called from a [`module_extension()`](#module_extension) implementation function, or used by [`use_repo_rule()`](../globals/module#use_repo_rule).
+Creates a new repository rule. Store it in a global value, so that it can be loaded and called from a [`module_extension()`](#module_extension) implementation function, or used by [`use_repo_rule()`](/versions/8.3.1/rules/lib/globals/module#use_repo_rule).
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
 | `implementation` | callable; required |
-| `attrs` | [dict](../core/dict); or `None`; default is `None` |
-| `local` | [bool](../core/bool); default is `False`  Indicate that this rule fetches everything from the local system and should be reevaluated at every fetch. |
-| `environ` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  **Deprecated**. This parameter has been deprecated. Migrate to `repository_ctx.getenv` instead. Provides a list of environment variable that this repository rule depends on. If an environment variable in that list change, the repository will be refetched. |
-| `configure` | [bool](../core/bool); default is `False`  Indicate that the repository inspects the system for configuration purpose |
-| `remotable` | [bool](../core/bool); default is `False`  **Experimental**. This parameter is experimental and may change at any time. Please do not depend on it. It may be enabled on an experimental basis by setting `--experimental_repo_remote_exec`  Compatible with remote execution |
-| `doc` | [string](../core/string); or `None`; default is `None` |
+| `attrs` | [dict](/versions/8.3.1/rules/lib/core/dict); or `None`; default is `None` |
+| `local` | [bool](/versions/8.3.1/rules/lib/core/bool); default is `False`  Indicate that this rule fetches everything from the local system and should be reevaluated at every fetch. |
+| `environ` | [sequence](/versions/8.3.1/rules/lib/core/list) of [string](/versions/8.3.1/rules/lib/core/string)s; default is `[]`  **Deprecated**. This parameter has been deprecated. Migrate to `repository_ctx.getenv` instead. Provides a list of environment variable that this repository rule depends on. If an environment variable in that list change, the repository will be refetched. |
+| `configure` | [bool](/versions/8.3.1/rules/lib/core/bool); default is `False`  Indicate that the repository inspects the system for configuration purpose |
+| `remotable` | [bool](/versions/8.3.1/rules/lib/core/bool); default is `False`  **Experimental**. This parameter is experimental and may change at any time. Please do not depend on it. It may be enabled on an experimental basis by setting `--experimental_repo_remote_exec`  Compatible with remote execution |
+| `doc` | [string](/versions/8.3.1/rules/lib/core/string); or `None`; default is `None` |
 
 ## rule
 
@@ -267,29 +267,29 @@ Test rules are required to have a name ending in `_test`, while all other rules
 
 | Parameter | Description |
 | --- | --- |
-| `implementation` | [function](../core/function); required  the Starlark function implementing this rule, must have exactly one parameter: [ctx](../builtins/ctx). The function is called during the analysis phase for each instance of the rule. It can access the attributes provided by the user. It must create actions to generate all the declared outputs. |
-| `test` | [bool](../core/bool); default is `unbound`  Whether this rule is a test rule, that is, whether it may be the subject of a `blaze test` command. All test rules are automatically considered [executable](#rule.executable); it is unnecessary (and discouraged) to explicitly set `executable = True` for a test rule. The value defaults to `False`. See the  [Rules page](https://bazel.build/versions/8.3.1/extending/rules#executable_rules_and_test_rules) for more information. |
-| `attrs` | [dict](../core/dict); default is `{}`  A dictionary to declare all the attributes of the rule. It maps from an attribute name to an attribute object (see [`attr`](../toplevel/attr) module). Attributes starting with `_` are private, and can be used to add an implicit dependency on a label. The attribute `name` is implicitly added and must not be specified. Attributes `visibility`, `deprecation`, `tags`, `testonly`, and `features` are implicitly added and cannot be overridden. Most rules need only a handful of attributes. To limit memory usage, there is a cap on the number of attributes that may be declared. Declared attributes will convert `None` to the default value. |
-| `outputs` | [dict](../core/dict); or `None`; or [function](../core/function); default is `None`  **Deprecated**. This parameter is deprecated and will be removed soon. Please do not depend on it. It is *disabled* with `--incompatible_no_rule_outputs_param`. Use this flag to verify your code is compatible with its imminent removal.  This parameter has been deprecated. Migrate rules to use `OutputGroupInfo` or `attr.output` instead. A schema for defining predeclared outputs. Unlike [`output`](../toplevel/attr#output) and [`output_list`](../toplevel/attr#output_list) attributes, the user does not specify the labels for these files. See the [Rules page](https://bazel.build/versions/8.3.1/extending/rules#files) for more on predeclared outputs. The value of this argument is either a dictionary or a callback function that produces a dictionary. The callback works similar to computed dependency attributes: The function's parameter names are matched against the rule's attributes, so for example if you pass `outputs = _my_func` with the definition `def _my_func(srcs, deps): ...`, the function has access to the attributes `srcs` and `deps`. Whether the dictionary is specified directly or via a function, it is interpreted as follows. Each entry in the dictionary creates a predeclared output where the key is an identifier and the value is a string template that determines the output's label. In the rule's implementation function, the identifier becomes the field name used to access the output's [`File`](../builtins/File) in [`ctx.outputs`](../builtins/ctx#outputs). The output's label has the same package as the rule, and the part after the package is produced by substituting each placeholder of the form `"%{ATTR}"` with a string formed from the value of the attribute `ATTR`:  * String-typed attributes are substituted verbatim.* Label-typed attributes become the part of the label after the package, minus the file extension. For example, the label `"//pkg:a/b.c"` becomes `"a/b"`.* Output-typed attributes become the part of the label after the package, including the file extension (for the above example, `"a/b.c"`).* All list-typed attributes (for example, `attr.label_list`) used in placeholders are required to have *exactly one element*. Their conversion is the same as their non-list version (`attr.label`).* Other attribute types may not appear in placeholders.* The special non-attribute placeholders `%{dirname}` and `%{basename}` expand to those parts of the rule's label, excluding its package. For example, in `"//pkg:a/b.c"`, the dirname is `a` and the basename is `b.c`.   In practice, the most common substitution placeholder is `"%{name}"`. For example, for a target named "foo", the outputs dict `{"bin": "%{name}.exe"}` predeclares an output named `foo.exe` that is accessible in the implementation function as `ctx.outputs.bin`. |
-| `executable` | [bool](../core/bool); default is `unbound` |
-| `output_to_genfiles` | [bool](../core/bool); default is `False`  If true, the files will be generated in the genfiles directory instead of the bin directory. Unless you need it for compatibility with existing rules (e.g. when generating header files for C++), do not set this flag. |
-| `fragments` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  List of names of configuration fragments that the rule requires in target configuration. |
-| `host_fragments` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  List of names of configuration fragments that the rule requires in host configuration. |
-| `_skylark_testable` | [bool](../core/bool); default is `False`  *(Experimental)*  If true, this rule will expose its actions for inspection by rules that depend on it via an `Actions` provider. The provider is also available to the rule itself by calling [ctx.created\_actions()](../builtins/ctx#created_actions).  This should only be used for testing the analysis-time behavior of Starlark rules. This flag may be removed in the future. |
-| `toolchains` | [sequence](../core/list); default is `[]`  If set, the set of toolchains this rule requires. The list can contain String, Label, or StarlarkToolchainTypeApi objects, in any combination. Toolchains will be found by checking the current platform, and provided to the rule implementation via `ctx.toolchain`. |
-| `incompatible_use_toolchain_transition` | [bool](../core/bool); default is `False`  Deprecated, this is no longer in use and should be removed. |
-| `doc` | [string](../core/string); or `None`; default is `None`  A description of the rule that can be extracted by documentation generating tools. |
-| `provides` | [sequence](../core/list); default is `[]`  A list of providers that the implementation function must return. It is an error if the implementation function omits any of the types of providers listed here from its return value. However, the implementation function may return additional providers not listed here. Each element of the list is an `*Info` object returned by [`provider()`](../globals/bzl#provider), except that a legacy provider is represented by its string name instead.When a target of the rule is used as a dependency for a target that declares a required provider, it is not necessary to specify that provider here. It is enough that the implementation function returns it. However, it is considered best practice to specify it, even though this is not required. The [`required_providers`](../globals/bzl#aspect.required_providers) field of an [aspect](../globals/bzl#aspect) does, however, require that providers are specified here. |
-| `dependency_resolution_rule` | [bool](../core/bool); default is `False`  If set, the rule can be a dependency through attributes also marked as available in materializers. Every attribute of rules with this flag set must be marked as available in materializers also. This is so that rules so marked cannot depend on rules that are not so marked. |
-| `exec_compatible_with` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  A list of constraints on the execution platform that apply to all targets of this rule type. |
-| `analysis_test` | [bool](../core/bool); default is `False`  If true, then this rule is treated as an analysis test. Note: Analysis test rules are primarily defined using infrastructure provided in core Starlark libraries. See [Testing](https://bazel.build/versions/8.3.1/rules/testing#testing-rules) for guidance. If a rule is defined as an analysis test rule, it becomes allowed to use configuration transitions defined using [analysis\_test\_transition](#analysis_test_transition) on its attributes, but opts into some restrictions:  * Targets of this rule are limited in the number of transitive dependencies they may have.* The rule is considered a test rule (as if `test=True` were set). This supersedes the value of `test`   * The rule implementation function may not register actions. Instead, it must register a pass/fail result via providing [AnalysisTestResultInfo](../providers/AnalysisTestResultInfo). |
-| `build_setting` | [BuildSetting](../builtins/BuildSetting); or `None`; default is `None`  If set, describes what kind of [`build setting`](/versions/8.3.1/rules/config#user-defined-build-settings) this rule is. See the [`config`](../toplevel/config) module. If this is set, a mandatory attribute named "build\_setting\_default" is automatically added to this rule, with a type corresponding to the value passed in here. |
+| `implementation` | [function](/versions/8.3.1/rules/lib/core/function); required  the Starlark function implementing this rule, must have exactly one parameter: [ctx](/versions/8.3.1/rules/lib/builtins/ctx). The function is called during the analysis phase for each instance of the rule. It can access the attributes provided by the user. It must create actions to generate all the declared outputs. |
+| `test` | [bool](/versions/8.3.1/rules/lib/core/bool); default is `unbound`  Whether this rule is a test rule, that is, whether it may be the subject of a `blaze test` command. All test rules are automatically considered [executable](#rule.executable); it is unnecessary (and discouraged) to explicitly set `executable = True` for a test rule. The value defaults to `False`. See the  [Rules page](https://bazel.build/versions/8.3.1/extending/rules#executable_rules_and_test_rules) for more information. |
+| `attrs` | [dict](/versions/8.3.1/rules/lib/core/dict); default is `{}`  A dictionary to declare all the attributes of the rule. It maps from an attribute name to an attribute object (see [`attr`](/versions/8.3.1/rules/lib/toplevel/attr) module). Attributes starting with `_` are private, and can be used to add an implicit dependency on a label. The attribute `name` is implicitly added and must not be specified. Attributes `visibility`, `deprecation`, `tags`, `testonly`, and `features` are implicitly added and cannot be overridden. Most rules need only a handful of attributes. To limit memory usage, there is a cap on the number of attributes that may be declared. Declared attributes will convert `None` to the default value. |
+| `outputs` | [dict](/versions/8.3.1/rules/lib/core/dict); or `None`; or [function](/versions/8.3.1/rules/lib/core/function); default is `None`  **Deprecated**. This parameter is deprecated and will be removed soon. Please do not depend on it. It is *disabled* with `--incompatible_no_rule_outputs_param`. Use this flag to verify your code is compatible with its imminent removal.  This parameter has been deprecated. Migrate rules to use `OutputGroupInfo` or `attr.output` instead. A schema for defining predeclared outputs. Unlike [`output`](/versions/8.3.1/rules/lib/toplevel/attr#output) and [`output_list`](/versions/8.3.1/rules/lib/toplevel/attr#output_list) attributes, the user does not specify the labels for these files. See the [Rules page](https://bazel.build/versions/8.3.1/extending/rules#files) for more on predeclared outputs. The value of this argument is either a dictionary or a callback function that produces a dictionary. The callback works similar to computed dependency attributes: The function's parameter names are matched against the rule's attributes, so for example if you pass `outputs = _my_func` with the definition `def _my_func(srcs, deps): ...`, the function has access to the attributes `srcs` and `deps`. Whether the dictionary is specified directly or via a function, it is interpreted as follows. Each entry in the dictionary creates a predeclared output where the key is an identifier and the value is a string template that determines the output's label. In the rule's implementation function, the identifier becomes the field name used to access the output's [`File`](/versions/8.3.1/rules/lib/builtins/File) in [`ctx.outputs`](/versions/8.3.1/rules/lib/builtins/ctx#outputs). The output's label has the same package as the rule, and the part after the package is produced by substituting each placeholder of the form `"%{ATTR}"` with a string formed from the value of the attribute `ATTR`:  * String-typed attributes are substituted verbatim.* Label-typed attributes become the part of the label after the package, minus the file extension. For example, the label `"//pkg:a/b.c"` becomes `"a/b"`.* Output-typed attributes become the part of the label after the package, including the file extension (for the above example, `"a/b.c"`).* All list-typed attributes (for example, `attr.label_list`) used in placeholders are required to have *exactly one element*. Their conversion is the same as their non-list version (`attr.label`).* Other attribute types may not appear in placeholders.* The special non-attribute placeholders `%{dirname}` and `%{basename}` expand to those parts of the rule's label, excluding its package. For example, in `"//pkg:a/b.c"`, the dirname is `a` and the basename is `b.c`.   In practice, the most common substitution placeholder is `"%{name}"`. For example, for a target named "foo", the outputs dict `{"bin": "%{name}.exe"}` predeclares an output named `foo.exe` that is accessible in the implementation function as `ctx.outputs.bin`. |
+| `executable` | [bool](/versions/8.3.1/rules/lib/core/bool); default is `unbound` |
+| `output_to_genfiles` | [bool](/versions/8.3.1/rules/lib/core/bool); default is `False`  If true, the files will be generated in the genfiles directory instead of the bin directory. Unless you need it for compatibility with existing rules (e.g. when generating header files for C++), do not set this flag. |
+| `fragments` | [sequence](/versions/8.3.1/rules/lib/core/list) of [string](/versions/8.3.1/rules/lib/core/string)s; default is `[]`  List of names of configuration fragments that the rule requires in target configuration. |
+| `host_fragments` | [sequence](/versions/8.3.1/rules/lib/core/list) of [string](/versions/8.3.1/rules/lib/core/string)s; default is `[]`  List of names of configuration fragments that the rule requires in host configuration. |
+| `_skylark_testable` | [bool](/versions/8.3.1/rules/lib/core/bool); default is `False`  *(Experimental)*  If true, this rule will expose its actions for inspection by rules that depend on it via an `Actions` provider. The provider is also available to the rule itself by calling [ctx.created\_actions()](/versions/8.3.1/rules/lib/builtins/ctx#created_actions).  This should only be used for testing the analysis-time behavior of Starlark rules. This flag may be removed in the future. |
+| `toolchains` | [sequence](/versions/8.3.1/rules/lib/core/list); default is `[]`  If set, the set of toolchains this rule requires. The list can contain String, Label, or StarlarkToolchainTypeApi objects, in any combination. Toolchains will be found by checking the current platform, and provided to the rule implementation via `ctx.toolchain`. |
+| `incompatible_use_toolchain_transition` | [bool](/versions/8.3.1/rules/lib/core/bool); default is `False`  Deprecated, this is no longer in use and should be removed. |
+| `doc` | [string](/versions/8.3.1/rules/lib/core/string); or `None`; default is `None`  A description of the rule that can be extracted by documentation generating tools. |
+| `provides` | [sequence](/versions/8.3.1/rules/lib/core/list); default is `[]`  A list of providers that the implementation function must return. It is an error if the implementation function omits any of the types of providers listed here from its return value. However, the implementation function may return additional providers not listed here. Each element of the list is an `*Info` object returned by [`provider()`](/versions/8.3.1/rules/lib/globals/bzl#provider), except that a legacy provider is represented by its string name instead.When a target of the rule is used as a dependency for a target that declares a required provider, it is not necessary to specify that provider here. It is enough that the implementation function returns it. However, it is considered best practice to specify it, even though this is not required. The [`required_providers`](/versions/8.3.1/rules/lib/globals/bzl#aspect.required_providers) field of an [aspect](/versions/8.3.1/rules/lib/globals/bzl#aspect) does, however, require that providers are specified here. |
+| `dependency_resolution_rule` | [bool](/versions/8.3.1/rules/lib/core/bool); default is `False`  If set, the rule can be a dependency through attributes also marked as available in materializers. Every attribute of rules with this flag set must be marked as available in materializers also. This is so that rules so marked cannot depend on rules that are not so marked. |
+| `exec_compatible_with` | [sequence](/versions/8.3.1/rules/lib/core/list) of [string](/versions/8.3.1/rules/lib/core/string)s; default is `[]`  A list of constraints on the execution platform that apply to all targets of this rule type. |
+| `analysis_test` | [bool](/versions/8.3.1/rules/lib/core/bool); default is `False`  If true, then this rule is treated as an analysis test. Note: Analysis test rules are primarily defined using infrastructure provided in core Starlark libraries. See [Testing](https://bazel.build/versions/8.3.1/rules/testing#testing-rules) for guidance. If a rule is defined as an analysis test rule, it becomes allowed to use configuration transitions defined using [analysis\_test\_transition](#analysis_test_transition) on its attributes, but opts into some restrictions:  * Targets of this rule are limited in the number of transitive dependencies they may have.* The rule is considered a test rule (as if `test=True` were set). This supersedes the value of `test`   * The rule implementation function may not register actions. Instead, it must register a pass/fail result via providing [AnalysisTestResultInfo](/versions/8.3.1/rules/lib/providers/AnalysisTestResultInfo). |
+| `build_setting` | [BuildSetting](/versions/8.3.1/rules/lib/builtins/BuildSetting); or `None`; default is `None`  If set, describes what kind of [`build setting`](/versions/8.3.1/rules/config#user-defined-build-settings) this rule is. See the [`config`](/versions/8.3.1/rules/lib/toplevel/config) module. If this is set, a mandatory attribute named "build\_setting\_default" is automatically added to this rule, with a type corresponding to the value passed in here. |
 | `cfg` | default is `None`  If set, points to the configuration transition the rule will apply to its own configuration before analysis. |
-| `exec_groups` | [dict](../core/dict); or `None`; default is `None`  Dict of execution group name (string) to [`exec_group`s](../globals/bzl#exec_group). If set, allows rules to run actions on multiple execution platforms within a single target. See [execution groups documentation](/versions/8.3.1/reference/exec-groups) for more info. |
+| `exec_groups` | [dict](/versions/8.3.1/rules/lib/core/dict); or `None`; default is `None`  Dict of execution group name (string) to [`exec_group`s](/versions/8.3.1/rules/lib/globals/bzl#exec_group). If set, allows rules to run actions on multiple execution platforms within a single target. See [execution groups documentation](/versions/8.3.1/reference/exec-groups) for more info. |
 | `initializer` | default is `None`  Experimental: the Stalark function initializing the attributes of the rule. The function is called at load time for each instance of the rule. It's called with `name` and the values of public attributes defined by the rule (not with generic attributes, for example `tags`). It has to return a dictionary from the attribute names to the desired values. The attributes that are not returned are unaffected. Returning `None` as value results in using the default value specified in the attribute definition. Initializers are evaluated before the default values specified in an attribute definition. Consequently, if a parameter in the initializer's signature contains a default values, it overwrites the default from the attribute definition (except if returning `None`). Similarly, if a parameter in the initializer's signature doesn't have a default, the parameter will become mandatory. It's a good practice to omit default/mandatory settings on an attribute definition in such cases. It's a good practice to use `**kwargs` for attributes that are not handled. In case of extended rules, all initializers are called proceeding from child to ancestors. Each initializer is passed only the public attributes it knows about. |
 | `parent` | default is `None`  Experimental: the Stalark rule that is extended. When set the public attributes are merged as well as advertised providers. The rule matches `executable` and `test` from the parent. Values of `fragments`, `toolchains`, `exec_compatible_with`, and `exec_groups` are merged. Legacy or deprecated parameters may not be set. Incoming configuration transition `cfg` of parent is applied after thisrule's incoming configuration. |
-| `extendable` | [bool](../core/bool); or [Label](../builtins/Label); or [string](../core/string); or `None`; default is `None`  Experimental: A label of an allowlist defining which rules can extending this rule. It can be set also to True/False to always allow/disallow extending. Bazel defaults to always allowing extensions. |
-| `subrules` | [sequence](../core/list) of [Subrule](../builtins/Subrule)s; default is `[]`  Experimental: List of subrules used by this rule. |
+| `extendable` | [bool](/versions/8.3.1/rules/lib/core/bool); or [Label](/versions/8.3.1/rules/lib/builtins/Label); or [string](/versions/8.3.1/rules/lib/core/string); or `None`; default is `None`  Experimental: A label of an allowlist defining which rules can extending this rule. It can be set also to True/False to always allow/disallow extending. Bazel defaults to always allowing extensions. |
+| `subrules` | [sequence](/versions/8.3.1/rules/lib/core/list) of [Subrule](/versions/8.3.1/rules/lib/builtins/Subrule)s; default is `[]`  Experimental: List of subrules used by this rule. |
 
 ## select
 
@@ -303,8 +303,8 @@ unknown select(x, no_match_error='')
 
 | Parameter | Description |
 | --- | --- |
-| `x` | [dict](../core/dict); required  A dict that maps configuration conditions to values. Each key is a [Label](../builtins/Label) or a label string that identifies a config\_setting or constraint\_value instance. See the [documentation on macros](https://bazel.build/versions/8.3.1/rules/macros#label-resolution) for when to use a Label instead of a string. |
-| `no_match_error` | [string](../core/string); default is `''`  Optional custom error to report if no condition matches. |
+| `x` | [dict](/versions/8.3.1/rules/lib/core/dict); required  A dict that maps configuration conditions to values. Each key is a [Label](/versions/8.3.1/rules/lib/builtins/Label) or a label string that identifies a config\_setting or constraint\_value instance. See the [documentation on macros](https://bazel.build/versions/8.3.1/rules/macros#label-resolution) for when to use a Label instead of a string. |
+| `no_match_error` | [string](/versions/8.3.1/rules/lib/core/string); default is `''`  Optional custom error to report if no condition matches. |
 
 ## subrule
 
@@ -318,11 +318,11 @@ Constructs a new instance of a subrule. The result of this function must be stor
 
 | Parameter | Description |
 | --- | --- |
-| `implementation` | [function](../core/function); required  The Starlark function implementing this subrule |
-| `attrs` | [dict](../core/dict); default is `{}`  A dictionary to declare all the (private) attributes of the subrule.  Subrules may only have private attributes that are label-typed (i.e. label or label-list). The resolved values corresponding to these labels are automatically passed by Bazel to the subrule's implementation function as named arguments (thus the implementation function is required to accept named parameters matching the attribute names). The types of these values will be:  * `FilesToRunProvider` for label attributes with `executable=True` * `File` for label attributes with `allow_single_file=True` * `Target` for all other label attributes * `[Target]` for all label-list attributes |
-| `toolchains` | [sequence](../core/list); default is `[]`  If set, the set of toolchains this subrule requires. The list can contain String, Label, or StarlarkToolchainTypeApi objects, in any combination. Toolchains will be found by checking the current platform, and provided to the subrule implementation via `ctx.toolchains`. Note that AEGs need to be enabled on the consuming rule(s) if this parameter is set. In case you haven't migrated to AEGs yet, see https://bazel.build/extending/auto-exec-groups#migration-aegs. |
-| `fragments` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  List of names of configuration fragments that the subrule requires in target configuration. |
-| `subrules` | [sequence](../core/list) of [Subrule](../builtins/Subrule)s; default is `[]`  List of other subrules needed by this subrule. |
+| `implementation` | [function](/versions/8.3.1/rules/lib/core/function); required  The Starlark function implementing this subrule |
+| `attrs` | [dict](/versions/8.3.1/rules/lib/core/dict); default is `{}`  A dictionary to declare all the (private) attributes of the subrule.  Subrules may only have private attributes that are label-typed (i.e. label or label-list). The resolved values corresponding to these labels are automatically passed by Bazel to the subrule's implementation function as named arguments (thus the implementation function is required to accept named parameters matching the attribute names). The types of these values will be:  * `FilesToRunProvider` for label attributes with `executable=True` * `File` for label attributes with `allow_single_file=True` * `Target` for all other label attributes * `[Target]` for all label-list attributes |
+| `toolchains` | [sequence](/versions/8.3.1/rules/lib/core/list); default is `[]`  If set, the set of toolchains this subrule requires. The list can contain String, Label, or StarlarkToolchainTypeApi objects, in any combination. Toolchains will be found by checking the current platform, and provided to the subrule implementation via `ctx.toolchains`. Note that AEGs need to be enabled on the consuming rule(s) if this parameter is set. In case you haven't migrated to AEGs yet, see https://bazel.build/extending/auto-exec-groups#migration-aegs. |
+| `fragments` | [sequence](/versions/8.3.1/rules/lib/core/list) of [string](/versions/8.3.1/rules/lib/core/string)s; default is `[]`  List of names of configuration fragments that the subrule requires in target configuration. |
+| `subrules` | [sequence](/versions/8.3.1/rules/lib/core/list) of [Subrule](/versions/8.3.1/rules/lib/builtins/Subrule)s; default is `[]`  List of other subrules needed by this subrule. |
 
 ## tag\_class
 
@@ -336,8 +336,8 @@ Creates a new tag\_class object, which defines an attribute schema for a class o
 
 | Parameter | Description |
 | --- | --- |
-| `attrs` | [dict](../core/dict); default is `{}`  A dictionary to declare all the attributes of this tag class. It maps from an attribute name to an attribute object (see [attr](../toplevel/attr) module). Note that unlike [`rule()`](../globals/bzl#rule), [`aspect()`](../globals/bzl#aspect) and [`repository_rule()`](../globals/bzl#repository_rule), declared attributes will not convert `None` to the default value. For the default to be used, the attribute must be omitted entirely by the caller. |
-| `doc` | [string](../core/string); or `None`; default is `None`  A description of the tag class that can be extracted by documentation generating tools. |
+| `attrs` | [dict](/versions/8.3.1/rules/lib/core/dict); default is `{}`  A dictionary to declare all the attributes of this tag class. It maps from an attribute name to an attribute object (see [attr](/versions/8.3.1/rules/lib/toplevel/attr) module). Note that unlike [`rule()`](/versions/8.3.1/rules/lib/globals/bzl#rule), [`aspect()`](/versions/8.3.1/rules/lib/globals/bzl#aspect) and [`repository_rule()`](/versions/8.3.1/rules/lib/globals/bzl#repository_rule), declared attributes will not convert `None` to the default value. For the default to be used, the attribute must be omitted entirely by the caller. |
+| `doc` | [string](/versions/8.3.1/rules/lib/core/string); or `None`; default is `None`  A description of the tag class that can be extracted by documentation generating tools. |
 
 ## visibility
 
diff --git a/versions/8.3.1/rules/lib/globals/module.mdx b/versions/8.3.1/rules/lib/globals/module.mdx
index 83bc2456..35baef4e 100644
--- a/versions/8.3.1/rules/lib/globals/module.mdx
+++ b/versions/8.3.1/rules/lib/globals/module.mdx
@@ -30,7 +30,7 @@ None archive_override(module_name, **kwargs)
 
 Specifies that this dependency should come from an archive file (zip, gzip, etc) at a
 certain location, instead of from a registry. Effectively, this dependency will be
-backed by an [`http_archive`](../repo/http#http_archive) rule.
+backed by an [`http_archive`](/versions/8.3.1/rules/lib/repo/http#http_archive) rule.
 
 This directive only takes effect in the root module; in other words, if a module is
 used as a dependency by others, its own overrides are ignored.
@@ -39,7 +39,7 @@ used as a dependency by others, its own overrides are ignored.
 
 | Parameter | Description |
 | --- | --- |
-| `module_name` | [string](../core/string); required  The name of the Bazel module dependency to apply this override to. |
+| `module_name` | [string](/versions/8.3.1/rules/lib/core/string); required  The name of the Bazel module dependency to apply this override to. |
 | `kwargs` | required  All other arguments are forwarded to the underlying `http_archive` repo rule. Note that the `name` attribute shouldn't be specified; use `module_name` instead. |
 
 ## bazel\_dep
@@ -54,11 +54,11 @@ Declares a direct dependency on another Bazel module.
 
 | Parameter | Description |
 | --- | --- |
-| `name` | [string](../core/string); required  The name of the module to be added as a direct dependency. |
-| `version` | [string](../core/string); default is `''`  The version of the module to be added as a direct dependency. |
-| `max_compatibility_level` | [int](../core/int); default is `-1`  The maximum `compatibility_level` supported for the module to be added as a direct dependency. The version of the module implies the minimum compatibility\_level supported, as well as the maximum if this attribute is not specified. |
-| `repo_name` | [string](../core/string); or `None`; default is `''`  The name of the external repo representing this dependency. This is by default the name of the module. Can be set to `None` to make this dependency a "*nodep*" dependency: in this case, this `bazel_dep` specification is only honored if the target module already exists in the dependency graph by some other means. |
-| `dev_dependency` | [bool](../core/bool); default is `False`  If true, this dependency will be ignored if the current module is not the root module or `--ignore_dev_dependency` is enabled. |
+| `name` | [string](/versions/8.3.1/rules/lib/core/string); required  The name of the module to be added as a direct dependency. |
+| `version` | [string](/versions/8.3.1/rules/lib/core/string); default is `''`  The version of the module to be added as a direct dependency. |
+| `max_compatibility_level` | [int](/versions/8.3.1/rules/lib/core/int); default is `-1`  The maximum `compatibility_level` supported for the module to be added as a direct dependency. The version of the module implies the minimum compatibility\_level supported, as well as the maximum if this attribute is not specified. |
+| `repo_name` | [string](/versions/8.3.1/rules/lib/core/string); or `None`; default is `''`  The name of the external repo representing this dependency. This is by default the name of the module. Can be set to `None` to make this dependency a "*nodep*" dependency: in this case, this `bazel_dep` specification is only honored if the target module already exists in the dependency graph by some other means. |
+| `dev_dependency` | [bool](/versions/8.3.1/rules/lib/core/bool); default is `False`  If true, this dependency will be ignored if the current module is not the root module or `--ignore_dev_dependency` is enabled. |
 
 ## git\_override
 
@@ -68,7 +68,7 @@ None git_override(module_name, **kwargs)
 
 Specifies that this dependency should come from a certain commit in a Git repository,
 instead of from a registry. Effectively, this dependency will be backed by a
-[`git_repository`](../repo/git#git_repository) rule.
+[`git_repository`](/versions/8.3.1/rules/lib/repo/git#git_repository) rule.
 
 This directive only takes effect in the root module; in other words, if a module is
 used as a dependency by others, its own overrides are ignored.
@@ -77,7 +77,7 @@ used as a dependency by others, its own overrides are ignored.
 
 | Parameter | Description |
 | --- | --- |
-| `module_name` | [string](../core/string); required  The name of the Bazel module dependency to apply this override to. |
+| `module_name` | [string](/versions/8.3.1/rules/lib/core/string); required  The name of the Bazel module dependency to apply this override to. |
 | `kwargs` | required  All other arguments are forwarded to the underlying `git_repository` repo rule. Note that the `name` attribute shouldn't be specified; use `module_name` instead. |
 
 ## include
@@ -98,7 +98,7 @@ Only files in the main repo may be included.
 
 | Parameter | Description |
 | --- | --- |
-| `label` | [string](../core/string); required  The label pointing to the file to include. The label must point to a file in the main repo; in other words, it **must **start with double slashes (`//`). The name of the file must end with `.MODULE.bazel` and must not start with `.`.**** |
+| `label` | [string](/versions/8.3.1/rules/lib/core/string); required  The label pointing to the file to include. The label must point to a file in the main repo; in other words, it **must **start with double slashes (`//`). The name of the file must end with `.MODULE.bazel` and must not start with `.`.**** |
 
 ## inject\_repo
 
@@ -138,8 +138,8 @@ used as a dependency by others, its own overrides are ignored.
 
 | Parameter | Description |
 | --- | --- |
-| `module_name` | [string](../core/string); required  The name of the Bazel module dependency to apply this override to. |
-| `path` | [string](../core/string); required  The path to the directory where this module is. |
+| `module_name` | [string](/versions/8.3.1/rules/lib/core/string); required  The name of the Bazel module dependency to apply this override to. |
+| `path` | [string](/versions/8.3.1/rules/lib/core/string); required  The path to the directory where this module is. |
 
 ## module
 
@@ -155,11 +155,11 @@ It should be called at most once, and if called, it must be the very first direc
 
 | Parameter | Description |
 | --- | --- |
-| `name` | [string](../core/string); default is `''`  The name of the module. Can be omitted only if this module is the root module (as in, if it's not going to be depended on by another module). A valid module name must: 1) only contain lowercase letters (a-z), digits (0-9), dots (.), hyphens (-), and underscores (\_); 2) begin with a lowercase letter; 3) end with a lowercase letter or digit. |
-| `version` | [string](../core/string); default is `''`  The version of the module. Can be omitted only if this module is the root module (as in, if it's not going to be depended on by another module). The version must be in a relaxed SemVer format; see [the documentation](/versions/8.3.1/external/module#version_format) for more details. |
-| `compatibility_level` | [int](../core/int); default is `0`  The compatibility level of the module; this should be changed every time a major incompatible change is introduced. This is essentially the "major version" of the module in terms of SemVer, except that it's not embedded in the version string itself, but exists as a separate field. Modules with different compatibility levels participate in version resolution as if they're modules with different names, but the final dependency graph cannot contain multiple modules with the same name but different compatibility levels (unless `multiple_version_override` is in effect). See [the documentation](/versions/8.3.1/external/module#compatibility_level) for more details. |
-| `repo_name` | [string](../core/string); default is `''`  The name of the repository representing this module, as seen by the module itself. By default, the name of the repo is the name of the module. This can be specified to ease migration for projects that have been using a repo name for itself that differs from its module name. |
-| `bazel_compatibility` | Iterable of [string](../core/string)s; default is `[]`  A list of bazel versions that allows users to declare which Bazel versions are compatible with this module. It does NOT affect dependency resolution, but bzlmod will use this information to check if your current Bazel version is compatible. The format of this value is a string of some constraint values separated by comma. Three constraints are supported: <=X.X.X: The Bazel version must be equal or older than X.X.X. Used when there is a known incompatible change in a newer version. >=X.X.X: The Bazel version must be equal or newer than X.X.X.Used when you depend on some features that are only available since X.X.X. -X.X.X: The Bazel version X.X.X is not compatible. Used when there is a bug in X.X.X that breaks you, but fixed in later versions. |
+| `name` | [string](/versions/8.3.1/rules/lib/core/string); default is `''`  The name of the module. Can be omitted only if this module is the root module (as in, if it's not going to be depended on by another module). A valid module name must: 1) only contain lowercase letters (a-z), digits (0-9), dots (.), hyphens (-), and underscores (\_); 2) begin with a lowercase letter; 3) end with a lowercase letter or digit. |
+| `version` | [string](/versions/8.3.1/rules/lib/core/string); default is `''`  The version of the module. Can be omitted only if this module is the root module (as in, if it's not going to be depended on by another module). The version must be in a relaxed SemVer format; see [the documentation](/versions/8.3.1/external/module#version_format) for more details. |
+| `compatibility_level` | [int](/versions/8.3.1/rules/lib/core/int); default is `0`  The compatibility level of the module; this should be changed every time a major incompatible change is introduced. This is essentially the "major version" of the module in terms of SemVer, except that it's not embedded in the version string itself, but exists as a separate field. Modules with different compatibility levels participate in version resolution as if they're modules with different names, but the final dependency graph cannot contain multiple modules with the same name but different compatibility levels (unless `multiple_version_override` is in effect). See [the documentation](/versions/8.3.1/external/module#compatibility_level) for more details. |
+| `repo_name` | [string](/versions/8.3.1/rules/lib/core/string); default is `''`  The name of the repository representing this module, as seen by the module itself. By default, the name of the repo is the name of the module. This can be specified to ease migration for projects that have been using a repo name for itself that differs from its module name. |
+| `bazel_compatibility` | Iterable of [string](/versions/8.3.1/rules/lib/core/string)s; default is `[]`  A list of bazel versions that allows users to declare which Bazel versions are compatible with this module. It does NOT affect dependency resolution, but bzlmod will use this information to check if your current Bazel version is compatible. The format of this value is a string of some constraint values separated by comma. Three constraints are supported: <=X.X.X: The Bazel version must be equal or older than X.X.X. Used when there is a known incompatible change in a newer version. >=X.X.X: The Bazel version must be equal or newer than X.X.X.Used when you depend on some features that are only available since X.X.X. -X.X.X: The Bazel version X.X.X is not compatible. Used when there is a bug in X.X.X that breaks you, but fixed in later versions. |
 
 ## multiple\_version\_override
 
@@ -173,9 +173,9 @@ Specifies that a dependency should still come from a registry, but multiple vers
 
 | Parameter | Description |
 | --- | --- |
-| `module_name` | [string](../core/string); required  The name of the Bazel module dependency to apply this override to. |
-| `versions` | Iterable of [string](../core/string)s; required  Explicitly specifies the versions allowed to coexist. These versions must already be present in the dependency graph pre-selection. Dependencies on this module will be "upgraded" to the nearest higher allowed version at the same compatibility level, whereas dependencies that have a higher version than any allowed versions at the same compatibility level will cause an error. |
-| `registry` | [string](../core/string); default is `''`  Overrides the registry for this module; instead of finding this module from the default list of registries, the given registry should be used. |
+| `module_name` | [string](/versions/8.3.1/rules/lib/core/string); required  The name of the Bazel module dependency to apply this override to. |
+| `versions` | Iterable of [string](/versions/8.3.1/rules/lib/core/string)s; required  Explicitly specifies the versions allowed to coexist. These versions must already be present in the dependency graph pre-selection. Dependencies on this module will be "upgraded" to the nearest higher allowed version at the same compatibility level, whereas dependencies that have a higher version than any allowed versions at the same compatibility level will cause an error. |
+| `registry` | [string](/versions/8.3.1/rules/lib/core/string); default is `''`  Overrides the registry for this module; instead of finding this module from the default list of registries, the given registry should be used. |
 
 ## override\_repo
 
@@ -209,8 +209,8 @@ Specifies already-defined execution platforms to be registered when this module
 
 | Parameter | Description |
 | --- | --- |
-| `dev_dependency` | [bool](../core/bool); default is `False`  If true, the execution platforms will not be registered if the current module is not the root module or `--ignore\_dev\_dependency` is enabled. |
-| `platform_labels` | [sequence](../core/list) of [string](../core/string)s; required  The target patterns to register. |
+| `dev_dependency` | [bool](/versions/8.3.1/rules/lib/core/bool); default is `False`  If true, the execution platforms will not be registered if the current module is not the root module or `--ignore\_dev\_dependency` is enabled. |
+| `platform_labels` | [sequence](/versions/8.3.1/rules/lib/core/list) of [string](/versions/8.3.1/rules/lib/core/string)s; required  The target patterns to register. |
 
 ## register\_toolchains
 
@@ -224,8 +224,8 @@ Specifies already-defined toolchains to be registered when this module is select
 
 | Parameter | Description |
 | --- | --- |
-| `dev_dependency` | [bool](../core/bool); default is `False`  If true, the toolchains will not be registered if the current module is not the root module or `--ignore\_dev\_dependency` is enabled. |
-| `toolchain_labels` | [sequence](../core/list) of [string](../core/string)s; required  The target patterns to register. |
+| `dev_dependency` | [bool](/versions/8.3.1/rules/lib/core/bool); default is `False`  If true, the toolchains will not be registered if the current module is not the root module or `--ignore\_dev\_dependency` is enabled. |
+| `toolchain_labels` | [sequence](/versions/8.3.1/rules/lib/core/list) of [string](/versions/8.3.1/rules/lib/core/string)s; required  The target patterns to register. |
 
 ## single\_version\_override
 
@@ -239,12 +239,12 @@ Specifies that a dependency should still come from a registry, but its version s
 
 | Parameter | Description |
 | --- | --- |
-| `module_name` | [string](../core/string); required  The name of the Bazel module dependency to apply this override to. |
-| `version` | [string](../core/string); default is `''`  Overrides the declared version of this module in the dependency graph. In other words, this module will be "pinned" to this override version. This attribute can be omitted if all one wants to override is the registry or the patches. |
-| `registry` | [string](../core/string); default is `''`  Overrides the registry for this module; instead of finding this module from the default list of registries, the given registry should be used. |
-| `patches` | Iterable of [string](../core/string)s; default is `[]`  A list of labels pointing to patch files to apply for this module. The patch files must exist in the source tree of the top level project. They are applied in the list order. If a patch makes changes to the MODULE.bazel file, these changes will only be effective if the patch file is provided by the root module. |
-| `patch_cmds` | Iterable of [string](../core/string)s; default is `[]`  Sequence of Bash commands to be applied on Linux/Macos after patches are applied. Changes to the MODULE.bazel file will not be effective. |
-| `patch_strip` | [int](../core/int); default is `0`  Same as the --strip argument of Unix patch. |
+| `module_name` | [string](/versions/8.3.1/rules/lib/core/string); required  The name of the Bazel module dependency to apply this override to. |
+| `version` | [string](/versions/8.3.1/rules/lib/core/string); default is `''`  Overrides the declared version of this module in the dependency graph. In other words, this module will be "pinned" to this override version. This attribute can be omitted if all one wants to override is the registry or the patches. |
+| `registry` | [string](/versions/8.3.1/rules/lib/core/string); default is `''`  Overrides the registry for this module; instead of finding this module from the default list of registries, the given registry should be used. |
+| `patches` | Iterable of [string](/versions/8.3.1/rules/lib/core/string)s; default is `[]`  A list of labels pointing to patch files to apply for this module. The patch files must exist in the source tree of the top level project. They are applied in the list order. If a patch makes changes to the MODULE.bazel file, these changes will only be effective if the patch file is provided by the root module. |
+| `patch_cmds` | Iterable of [string](/versions/8.3.1/rules/lib/core/string)s; default is `[]`  Sequence of Bash commands to be applied on Linux/Macos after patches are applied. Changes to the MODULE.bazel file will not be effective. |
+| `patch_strip` | [int](/versions/8.3.1/rules/lib/core/int); default is `0`  Same as the --strip argument of Unix patch. |
 
 ## use\_extension
 
@@ -258,10 +258,10 @@ Returns a proxy object representing a module extension; its methods can be invok
 
 | Parameter | Description |
 | --- | --- |
-| `extension_bzl_file` | [string](../core/string); required  A label to the Starlark file defining the module extension. |
-| `extension_name` | [string](../core/string); required  The name of the module extension to use. A symbol with this name must be exported by the Starlark file. |
-| `dev_dependency` | [bool](../core/bool); default is `False`  If true, this usage of the module extension will be ignored if the current module is not the root module or `--ignore\_dev\_dependency` is enabled. |
-| `isolate` | [bool](../core/bool); default is `False`  **Experimental**. This parameter is experimental and may change at any time. Please do not depend on it. It may be enabled on an experimental basis by setting `--experimental_isolated_extension_usages`  If true, this usage of the module extension will be isolated from all other usages, both in this and other modules. Tags created for this usage do not affect other usages and the repositories generated by the extension for this usage will be distinct from all other repositories generated by the extension. This parameter is currently experimental and only available with the flag `--experimental_isolated_extension_usages`. |
+| `extension_bzl_file` | [string](/versions/8.3.1/rules/lib/core/string); required  A label to the Starlark file defining the module extension. |
+| `extension_name` | [string](/versions/8.3.1/rules/lib/core/string); required  The name of the module extension to use. A symbol with this name must be exported by the Starlark file. |
+| `dev_dependency` | [bool](/versions/8.3.1/rules/lib/core/bool); default is `False`  If true, this usage of the module extension will be ignored if the current module is not the root module or `--ignore\_dev\_dependency` is enabled. |
+| `isolate` | [bool](/versions/8.3.1/rules/lib/core/bool); default is `False`  **Experimental**. This parameter is experimental and may change at any time. Please do not depend on it. It may be enabled on an experimental basis by setting `--experimental_isolated_extension_usages`  If true, this usage of the module extension will be isolated from all other usages, both in this and other modules. Tags created for this usage do not affect other usages and the repositories generated by the extension for this usage will be distinct from all other repositories generated by the extension. This parameter is currently experimental and only available with the flag `--experimental_isolated_extension_usages`. |
 
 ## use\_repo
 
@@ -291,5 +291,5 @@ Returns a proxy value that can be directly invoked in the MODULE.bazel file as a
 
 | Parameter | Description |
 | --- | --- |
-| `repo_rule_bzl_file` | [string](../core/string); required  A label to the Starlark file defining the repo rule. |
-| `repo_rule_name` | [string](../core/string); required  The name of the repo rule to use. A symbol with this name must be exported by the Starlark file. |
\ No newline at end of file
+| `repo_rule_bzl_file` | [string](/versions/8.3.1/rules/lib/core/string); required  A label to the Starlark file defining the repo rule. |
+| `repo_rule_name` | [string](/versions/8.3.1/rules/lib/core/string); required  The name of the repo rule to use. A symbol with this name must be exported by the Starlark file. |
\ No newline at end of file
diff --git a/versions/8.3.1/rules/lib/globals/repo.mdx b/versions/8.3.1/rules/lib/globals/repo.mdx
index 5beb97a3..ed5ff76a 100644
--- a/versions/8.3.1/rules/lib/globals/repo.mdx
+++ b/versions/8.3.1/rules/lib/globals/repo.mdx
@@ -23,7 +23,7 @@ This function takes a list of strings and a directory is ignored if any of the g
 
 | Parameter | Description |
 | --- | --- |
-| `dirs` | [sequence](../core/list) of [string](../core/string)s; required |
+| `dirs` | [sequence](/versions/8.3.1/rules/lib/core/list) of [string](/versions/8.3.1/rules/lib/core/string)s; required |
 
 ## repo
 
diff --git a/versions/8.3.1/rules/lib/globals/workspace.mdx b/versions/8.3.1/rules/lib/globals/workspace.mdx
index 6b67aaaa..c93b814b 100644
--- a/versions/8.3.1/rules/lib/globals/workspace.mdx
+++ b/versions/8.3.1/rules/lib/globals/workspace.mdx
@@ -25,8 +25,8 @@ Gives a target an alias in the `//external` package.
 
 | Parameter | Description |
 | --- | --- |
-| `name` | [string](../core/string); required  The label under '//external' to serve as the alias name |
-| `actual` | [string](../core/string); or `None`; default is `None`  The real label to be aliased |
+| `name` | [string](/versions/8.3.1/rules/lib/core/string); required  The label under '//external' to serve as the alias name |
+| `actual` | [string](/versions/8.3.1/rules/lib/core/string); or `None`; default is `None`  The real label to be aliased |
 
 ## register\_execution\_platforms
 
@@ -40,7 +40,7 @@ Specifies already-defined execution platforms to be registered. Should be absolu
 
 | Parameter | Description |
 | --- | --- |
-| `platform_labels` | [sequence](../core/list) of [string](../core/string)s; required  The target patterns to register. |
+| `platform_labels` | [sequence](/versions/8.3.1/rules/lib/core/list) of [string](/versions/8.3.1/rules/lib/core/string)s; required  The target patterns to register. |
 
 ## register\_toolchains
 
@@ -54,7 +54,7 @@ Specifies already-defined toolchains to be registered. Should be absolute [targe
 
 | Parameter | Description |
 | --- | --- |
-| `toolchain_labels` | [sequence](../core/list) of [string](../core/string)s; required  The target patterns to register. |
+| `toolchain_labels` | [sequence](/versions/8.3.1/rules/lib/core/list) of [string](/versions/8.3.1/rules/lib/core/string)s; required  The target patterns to register. |
 
 ## workspace
 
@@ -74,4 +74,4 @@ This name is used for the directory that the repository's runfiles are stored in
 
 | Parameter | Description |
 | --- | --- |
-| `name` | [string](../core/string); required  the name of the workspace. Names must start with a letter and can only contain letters, numbers, underscores, dashes, and dots. |
\ No newline at end of file
+| `name` | [string](/versions/8.3.1/rules/lib/core/string); required  the name of the workspace. Names must start with a letter and can only contain letters, numbers, underscores, dashes, and dots. |
\ No newline at end of file
diff --git a/versions/8.3.1/rules/lib/providers/AnalysisTestResultInfo.mdx b/versions/8.3.1/rules/lib/providers/AnalysisTestResultInfo.mdx
index 1edabb04..1bbd1029 100644
--- a/versions/8.3.1/rules/lib/providers/AnalysisTestResultInfo.mdx
+++ b/versions/8.3.1/rules/lib/providers/AnalysisTestResultInfo.mdx
@@ -22,8 +22,8 @@ The `AnalysisTestResultInfo` constructor.
 
 | Parameter | Description |
 | --- | --- |
-| `success` | [bool](../core/bool); required  If true, then the analysis-phase test represented by this target should pass. If false, the test should fail. |
-| `message` | [string](../core/string); required  A descriptive message containing information about the test and its success/failure. |
+| `success` | [bool](/versions/8.3.1/rules/lib/core/bool); required  If true, then the analysis-phase test represented by this target should pass. If false, the test should fail. |
+| `message` | [string](/versions/8.3.1/rules/lib/core/string); required  A descriptive message containing information about the test and its success/failure. |
 
 ## message
 
diff --git a/versions/8.3.1/rules/lib/providers/CcInfo.mdx b/versions/8.3.1/rules/lib/providers/CcInfo.mdx
index f3c0d961..a491c9cd 100644
--- a/versions/8.3.1/rules/lib/providers/CcInfo.mdx
+++ b/versions/8.3.1/rules/lib/providers/CcInfo.mdx
@@ -22,8 +22,8 @@ The `CcInfo` constructor.
 
 | Parameter | Description |
 | --- | --- |
-| `compilation_context` | [CompilationContext](../builtins/CompilationContext); or `None`; default is `None`  The `CompilationContext`. |
-| `linking_context` | [LinkingContext](../builtins/LinkingContext); or `None`; default is `None`  The `LinkingContext`. |
+| `compilation_context` | [CompilationContext](/versions/8.3.1/rules/lib/builtins/CompilationContext); or `None`; default is `None`  The `CompilationContext`. |
+| `linking_context` | [LinkingContext](/versions/8.3.1/rules/lib/builtins/LinkingContext); or `None`; default is `None`  The `LinkingContext`. |
 | `debug_context` | DebugContext; or `None`; default is `None`  The `DebugContext`. |
 
 ## compilation\_context
diff --git a/versions/8.3.1/rules/lib/providers/DebugPackageInfo.mdx b/versions/8.3.1/rules/lib/providers/DebugPackageInfo.mdx
index d1e74940..7769c015 100644
--- a/versions/8.3.1/rules/lib/providers/DebugPackageInfo.mdx
+++ b/versions/8.3.1/rules/lib/providers/DebugPackageInfo.mdx
@@ -24,10 +24,10 @@ The `DebugPackageInfo` constructor.
 
 | Parameter | Description |
 | --- | --- |
-| `target_label` | [Label](../builtins/Label); required  The label for the \*\_binary target |
-| `stripped_file` | [File](../builtins/File); or `None`; default is `None`  The stripped file (the explicit ".stripped" target) |
-| `unstripped_file` | [File](../builtins/File); required  The unstripped file (the default executable target). |
-| `dwp_file` | [File](../builtins/File); or `None`; default is `None`  The .dwp file (for fission builds) or null if --fission=no. |
+| `target_label` | [Label](/versions/8.3.1/rules/lib/builtins/Label); required  The label for the \*\_binary target |
+| `stripped_file` | [File](/versions/8.3.1/rules/lib/builtins/File); or `None`; default is `None`  The stripped file (the explicit ".stripped" target) |
+| `unstripped_file` | [File](/versions/8.3.1/rules/lib/builtins/File); required  The unstripped file (the default executable target). |
+| `dwp_file` | [File](/versions/8.3.1/rules/lib/builtins/File); or `None`; default is `None`  The .dwp file (for fission builds) or null if --fission=no. |
 
 ## dwp\_file
 
diff --git a/versions/8.3.1/rules/lib/providers/DefaultInfo.mdx b/versions/8.3.1/rules/lib/providers/DefaultInfo.mdx
index 91735418..9e21e901 100644
--- a/versions/8.3.1/rules/lib/providers/DefaultInfo.mdx
+++ b/versions/8.3.1/rules/lib/providers/DefaultInfo.mdx
@@ -28,11 +28,11 @@ The `DefaultInfo` constructor.
 
 | Parameter | Description |
 | --- | --- |
-| `files` | [depset](../builtins/depset); or `None`; default is `None`  A [`depset`](../builtins/depset) of [`File`](../builtins/File) objects representing the default outputs to build when this target is specified on the bazel command line. By default it is all predeclared outputs. |
-| `runfiles` | [runfiles](../builtins/runfiles); or `None`; default is `None`  runfiles descriptor describing the files that this target needs when run (via the `run` command or as a tool dependency). |
-| `data_runfiles` | [runfiles](../builtins/runfiles); or `None`; default is `None`  **It is recommended that you avoid using this parameter (see ["runfiles features to avoid"](https://bazel.build/versions/8.3.1/extending/rules#runfiles_features_to_avoid))** runfiles descriptor describing the runfiles this target needs to run when it is a dependency via the `data` attribute. |
-| `default_runfiles` | [runfiles](../builtins/runfiles); or `None`; default is `None`  **It is recommended that you avoid using this parameter (see ["runfiles features to avoid"](https://bazel.build/versions/8.3.1/extending/rules#runfiles_features_to_avoid))** runfiles descriptor describing the runfiles this target needs to run when it is a dependency via any attribute other than the `data` attribute. |
-| `executable` | [File](../builtins/File); or `None`; default is `None`  If this rule is marked [`executable`](../globals/bzl#rule.executable) or [`test`](../globals/bzl#rule.test), this is a [`File`](../builtins/File) object representing the file that should be executed to run the target. By default it is the predeclared output `ctx.outputs.executable` but it is recommended to pass another file (either predeclared or not) explicitly. |
+| `files` | [depset](/versions/8.3.1/rules/lib/builtins/depset); or `None`; default is `None`  A [`depset`](/versions/8.3.1/rules/lib/builtins/depset) of [`File`](/versions/8.3.1/rules/lib/builtins/File) objects representing the default outputs to build when this target is specified on the bazel command line. By default it is all predeclared outputs. |
+| `runfiles` | [runfiles](/versions/8.3.1/rules/lib/builtins/runfiles); or `None`; default is `None`  runfiles descriptor describing the files that this target needs when run (via the `run` command or as a tool dependency). |
+| `data_runfiles` | [runfiles](/versions/8.3.1/rules/lib/builtins/runfiles); or `None`; default is `None`  **It is recommended that you avoid using this parameter (see ["runfiles features to avoid"](https://bazel.build/versions/8.3.1/extending/rules#runfiles_features_to_avoid))** runfiles descriptor describing the runfiles this target needs to run when it is a dependency via the `data` attribute. |
+| `default_runfiles` | [runfiles](/versions/8.3.1/rules/lib/builtins/runfiles); or `None`; default is `None`  **It is recommended that you avoid using this parameter (see ["runfiles features to avoid"](https://bazel.build/versions/8.3.1/extending/rules#runfiles_features_to_avoid))** runfiles descriptor describing the runfiles this target needs to run when it is a dependency via any attribute other than the `data` attribute. |
+| `executable` | [File](/versions/8.3.1/rules/lib/builtins/File); or `None`; default is `None`  If this rule is marked [`executable`](/versions/8.3.1/rules/lib/globals/bzl#rule.executable) or [`test`](/versions/8.3.1/rules/lib/globals/bzl#rule.test), this is a [`File`](/versions/8.3.1/rules/lib/builtins/File) object representing the file that should be executed to run the target. By default it is the predeclared output `ctx.outputs.executable` but it is recommended to pass another file (either predeclared or not) explicitly. |
 
 ## data\_runfiles
 
@@ -58,7 +58,7 @@ May return `None`.
 depset DefaultInfo.files
 ```
 
-A [`depset`](../builtins/depset) of [`File`](../builtins/File) objects representing the default outputs to build when this target is specified on the bazel command line. By default it is all predeclared outputs.
+A [`depset`](/versions/8.3.1/rules/lib/builtins/depset) of [`File`](/versions/8.3.1/rules/lib/builtins/File) objects representing the default outputs to build when this target is specified on the bazel command line. By default it is all predeclared outputs.
 May return `None`.
 
 ## files\_to\_run
@@ -67,5 +67,5 @@ May return `None`.
 FilesToRunProvider DefaultInfo.files_to_run
 ```
 
-A [`FilesToRunProvider`](../providers/FilesToRunProvider) object containing information about the executable and runfiles of the target.
+A [`FilesToRunProvider`](/versions/8.3.1/rules/lib/providers/FilesToRunProvider) object containing information about the executable and runfiles of the target.
 May return `None`.
\ No newline at end of file
diff --git a/versions/8.3.1/rules/lib/providers/ExecutionInfo.mdx b/versions/8.3.1/rules/lib/providers/ExecutionInfo.mdx
index d351095e..c969afd2 100644
--- a/versions/8.3.1/rules/lib/providers/ExecutionInfo.mdx
+++ b/versions/8.3.1/rules/lib/providers/ExecutionInfo.mdx
@@ -22,8 +22,8 @@ Creates an instance.
 
 | Parameter | Description |
 | --- | --- |
-| `requirements` | [dict](../core/dict); default is `{}`  A dict indicating special execution requirements, such as hardware platforms. |
-| `exec_group` | [string](../core/string); default is `'test'`  The name of the exec group that is used to execute the test. |
+| `requirements` | [dict](/versions/8.3.1/rules/lib/core/dict); default is `{}`  A dict indicating special execution requirements, such as hardware platforms. |
+| `exec_group` | [string](/versions/8.3.1/rules/lib/core/string); default is `'test'`  The name of the exec group that is used to execute the test. |
 
 ## exec\_group
 
diff --git a/versions/8.3.1/rules/lib/providers/FeatureFlagInfo.mdx b/versions/8.3.1/rules/lib/providers/FeatureFlagInfo.mdx
index ebade07a..348f100b 100644
--- a/versions/8.3.1/rules/lib/providers/FeatureFlagInfo.mdx
+++ b/versions/8.3.1/rules/lib/providers/FeatureFlagInfo.mdx
@@ -31,7 +31,7 @@ The value of the flag in the configuration used by the flag rule.
 
 | Parameter | Description |
 | --- | --- |
-| `value` | [string](../core/string); required  String, the value to check for validity for this flag. |
+| `value` | [string](/versions/8.3.1/rules/lib/core/string); required  String, the value to check for validity for this flag. |
 
 ## value
 
diff --git a/versions/8.3.1/rules/lib/providers/InstrumentedFilesInfo.mdx b/versions/8.3.1/rules/lib/providers/InstrumentedFilesInfo.mdx
index aa597935..65bb0014 100644
--- a/versions/8.3.1/rules/lib/providers/InstrumentedFilesInfo.mdx
+++ b/versions/8.3.1/rules/lib/providers/InstrumentedFilesInfo.mdx
@@ -15,7 +15,7 @@ Contains information about source files and instrumentation metadata files for r
 depset InstrumentedFilesInfo.instrumented_files
 ```
 
-[`depset`](../builtins/depset) of [`File`](../builtins/File) objects representing instrumented source files for this target and its dependencies.
+[`depset`](/versions/8.3.1/rules/lib/builtins/depset) of [`File`](/versions/8.3.1/rules/lib/builtins/File) objects representing instrumented source files for this target and its dependencies.
 
 ## metadata\_files
 
@@ -23,4 +23,4 @@ depset InstrumentedFilesInfo.instrumented_files
 depset InstrumentedFilesInfo.metadata_files
 ```
 
-[`depset`](../builtins/depset) of [`File`](../builtins/File) objects representing coverage metadata files for this target and its dependencies. These files contain additional information required to generate LCOV-format coverage output after the code is executed, e.g. the `.gcno` files generated when `gcc` is run with `-ftest-coverage`.
\ No newline at end of file
+[`depset`](/versions/8.3.1/rules/lib/builtins/depset) of [`File`](/versions/8.3.1/rules/lib/builtins/File) objects representing coverage metadata files for this target and its dependencies. These files contain additional information required to generate LCOV-format coverage output after the code is executed, e.g. the `.gcno` files generated when `gcc` is run with `-ftest-coverage`.
\ No newline at end of file
diff --git a/versions/8.3.1/rules/lib/providers/PackageSpecificationInfo.mdx b/versions/8.3.1/rules/lib/providers/PackageSpecificationInfo.mdx
index 242a43e6..c2a2b6be 100644
--- a/versions/8.3.1/rules/lib/providers/PackageSpecificationInfo.mdx
+++ b/versions/8.3.1/rules/lib/providers/PackageSpecificationInfo.mdx
@@ -20,4 +20,4 @@ Checks if a target exists in a package group.
 
 | Parameter | Description |
 | --- | --- |
-| `target` | [Label](../builtins/Label); or [string](../core/string); required  A target which is checked if it exists inside the package group. |
\ No newline at end of file
+| `target` | [Label](/versions/8.3.1/rules/lib/builtins/Label); or [string](/versions/8.3.1/rules/lib/core/string); required  A target which is checked if it exists inside the package group. |
\ No newline at end of file
diff --git a/versions/8.3.1/rules/lib/providers/ProguardSpecProvider.mdx b/versions/8.3.1/rules/lib/providers/ProguardSpecProvider.mdx
index b7a337c2..1dfe0850 100644
--- a/versions/8.3.1/rules/lib/providers/ProguardSpecProvider.mdx
+++ b/versions/8.3.1/rules/lib/providers/ProguardSpecProvider.mdx
@@ -20,4 +20,4 @@ The `ProguardSpecProvider` constructor.
 
 | Parameter | Description |
 | --- | --- |
-| `specs` | [depset](../builtins/depset) of [File](../builtins/File)s; required  Transitive proguard specs. |
\ No newline at end of file
+| `specs` | [depset](/versions/8.3.1/rules/lib/builtins/depset) of [File](/versions/8.3.1/rules/lib/builtins/File)s; required  Transitive proguard specs. |
\ No newline at end of file
diff --git a/versions/8.3.1/rules/lib/repo/index.mdx b/versions/8.3.1/rules/lib/repo/index.mdx
index ab27e81c..2164c623 100644
--- a/versions/8.3.1/rules/lib/repo/index.mdx
+++ b/versions/8.3.1/rules/lib/repo/index.mdx
@@ -3,10 +3,10 @@
 title: 'Repository Rules'
 ---
 
-* [Rules related to git](git)
-* [Rules related to http](http)
-* [Rules related to local directories](local)
+* [Rules related to git](/versions/8.3.1/rules/lib/repo/git)
+* [Rules related to http](/versions/8.3.1/rules/lib/repo/http)
+* [Rules related to local directories](/versions/8.3.1/rules/lib/repo/local)
 
 # Generic functions for repository rule authors
 
-* [Utility functions on patching](utils)
+* [Utility functions on patching](/versions/8.3.1/rules/lib/repo/utils)
diff --git a/versions/8.3.1/rules/lib/toplevel/apple_common.mdx b/versions/8.3.1/rules/lib/toplevel/apple_common.mdx
index d26f9c22..0686b6a0 100644
--- a/versions/8.3.1/rules/lib/toplevel/apple_common.mdx
+++ b/versions/8.3.1/rules/lib/toplevel/apple_common.mdx
@@ -21,7 +21,7 @@ Functions for Starlark to access internals of the apple rule implementations.
 dict apple_common.apple_host_system_env(xcode_config)
 ```
 
-Returns a [dict](../core/dict) of environment variables that should be set for actions that need to run build tools on an Apple host system, such as the version of Xcode that should be used. The keys are variable names and the values are their corresponding values.
+Returns a [dict](/versions/8.3.1/rules/lib/core/dict) of environment variables that should be set for actions that need to run build tools on an Apple host system, such as the version of Xcode that should be used. The keys are variable names and the values are their corresponding values.
 
 ### Parameters
 
@@ -43,13 +43,13 @@ Utilities for resolving items from the apple toolchain.
 DottedVersion apple_common.dotted_version(version)
 ```
 
-Creates a new [DottedVersion](../builtins/DottedVersion) instance.
+Creates a new [DottedVersion](/versions/8.3.1/rules/lib/builtins/DottedVersion) instance.
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `version` | [string](../core/string); required  The string representation of the DottedVersion. |
+| `version` | [string](/versions/8.3.1/rules/lib/core/string); required  The string representation of the DottedVersion. |
 
 ## platform
 
@@ -69,7 +69,7 @@ An enum-like struct that contains the following fields corresponding to Apple pl
 * `watchos_device`
 * `watchos_simulator`
 
-These values can be passed to methods that expect a platform, like [XcodeVersionConfig.sdk\_version\_for\_platform](../providers/XcodeVersionConfig#sdk_version_for_platform).
+These values can be passed to methods that expect a platform, like [XcodeVersionConfig.sdk\_version\_for\_platform](/versions/8.3.1/rules/lib/providers/XcodeVersionConfig#sdk_version_for_platform).
 
 ## platform\_type
 
@@ -85,7 +85,7 @@ An enum-like struct that contains the following fields corresponding to Apple pl
 * `visionos`
 * `watchos`
 
-These values can be passed to methods that expect a platform type, like the 'apple' configuration fragment's [multi\_arch\_platform](../fragments/apple#multi_arch_platform) method.
+These values can be passed to methods that expect a platform type, like the 'apple' configuration fragment's [multi\_arch\_platform](/versions/8.3.1/rules/lib/fragments/apple#multi_arch_platform) method.
 
 Example:
 
diff --git a/versions/8.3.1/rules/lib/toplevel/attr.mdx b/versions/8.3.1/rules/lib/toplevel/attr.mdx
index 32461577..97885a25 100644
--- a/versions/8.3.1/rules/lib/toplevel/attr.mdx
+++ b/versions/8.3.1/rules/lib/toplevel/attr.mdx
@@ -2,7 +2,7 @@
 title: 'attr'
 ---
 
-This is a top-level module for defining the attribute schemas of a rule or aspect. Each function returns an object representing the schema of a single attribute. These objects are used as the values of the `attrs` dictionary argument of [`rule()`](../globals/bzl#rule), [`aspect()`](../globals/bzl#aspect), [`repository_rule()`](../globals/bzl#repository_rule) and [`tag_class()`](../globals/bzl#tag_class).
+This is a top-level module for defining the attribute schemas of a rule or aspect. Each function returns an object representing the schema of a single attribute. These objects are used as the values of the `attrs` dictionary argument of [`rule()`](/versions/8.3.1/rules/lib/globals/bzl#rule), [`aspect()`](/versions/8.3.1/rules/lib/globals/bzl#aspect), [`repository_rule()`](/versions/8.3.1/rules/lib/globals/bzl#repository_rule) and [`tag_class()`](/versions/8.3.1/rules/lib/globals/bzl#tag_class).
 
 See the Rules page for more on [defining](https://bazel.build/versions/8.3.1/extending/rules#attributes)
 and [using](https://bazel.build/versions/8.3.1/extending/rules#implementation_function) attributes.
@@ -29,16 +29,16 @@ and [using](https://bazel.build/versions/8.3.1/extending/rules#implementation_fu
 Attribute attr.bool(configurable=unbound, default=False, doc=None, mandatory=False)
 ```
 
-Creates a schema for a boolean attribute. The corresponding [`ctx.attr`](../builtins/ctx#attr) attribute will be of type [`bool`](../core/bool).
+Creates a schema for a boolean attribute. The corresponding [`ctx.attr`](/versions/8.3.1/rules/lib/builtins/ctx#attr) attribute will be of type [`bool`](/versions/8.3.1/rules/lib/core/bool).
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `configurable` | [bool](../core/bool); or unbound; default is `unbound`  This argument can only be specified for an attribute of a symbolic macro. If `configurable` is explicitly set to `False`, the symbolic macro attribute is non-configurable - in other words, it cannot take a `select()` value. If the `configurable` is either unbound or explicitly set to `True`, the attribute is configurable and can take a `select()` value. For an attribute of a rule or aspect, `configurable` must be left unbound. Most Starlark rule attributes are always configurable, with the exception of `attr.output()`, `attr.output_list()`, and `attr.license()` rule attributes, which are always non-configurable. |
-| `default` | [bool](../core/bool); default is `False`  A default value to use if no value for this attribute is given when instantiating the rule. |
-| `doc` | [string](../core/string); or `None`; default is `None`  A description of the attribute that can be extracted by documentation generating tools. |
-| `mandatory` | [bool](../core/bool); default is `False`  If true, the value must be specified explicitly (even if it has a `default`). |
+| `configurable` | [bool](/versions/8.3.1/rules/lib/core/bool); or unbound; default is `unbound`  This argument can only be specified for an attribute of a symbolic macro. If `configurable` is explicitly set to `False`, the symbolic macro attribute is non-configurable - in other words, it cannot take a `select()` value. If the `configurable` is either unbound or explicitly set to `True`, the attribute is configurable and can take a `select()` value. For an attribute of a rule or aspect, `configurable` must be left unbound. Most Starlark rule attributes are always configurable, with the exception of `attr.output()`, `attr.output_list()`, and `attr.license()` rule attributes, which are always non-configurable. |
+| `default` | [bool](/versions/8.3.1/rules/lib/core/bool); default is `False`  A default value to use if no value for this attribute is given when instantiating the rule. |
+| `doc` | [string](/versions/8.3.1/rules/lib/core/string); or `None`; default is `None`  A description of the attribute that can be extracted by documentation generating tools. |
+| `mandatory` | [bool](/versions/8.3.1/rules/lib/core/bool); default is `False`  If true, the value must be specified explicitly (even if it has a `default`). |
 
 ## int
 
@@ -46,17 +46,17 @@ Creates a schema for a boolean attribute. The corresponding [`ctx.attr`](../buil
 Attribute attr.int(configurable=unbound, default=0, doc=None, mandatory=False, values=[])
 ```
 
-Creates a schema for an integer attribute. The value must be in the signed 32-bit range. The corresponding [`ctx.attr`](../builtins/ctx#attr) attribute will be of type [`int`](../core/int).
+Creates a schema for an integer attribute. The value must be in the signed 32-bit range. The corresponding [`ctx.attr`](/versions/8.3.1/rules/lib/builtins/ctx#attr) attribute will be of type [`int`](/versions/8.3.1/rules/lib/core/int).
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `configurable` | [bool](../core/bool); or unbound; default is `unbound`  This argument can only be specified for an attribute of a symbolic macro. If `configurable` is explicitly set to `False`, the symbolic macro attribute is non-configurable - in other words, it cannot take a `select()` value. If the `configurable` is either unbound or explicitly set to `True`, the attribute is configurable and can take a `select()` value. For an attribute of a rule or aspect, `configurable` must be left unbound. Most Starlark rule attributes are always configurable, with the exception of `attr.output()`, `attr.output_list()`, and `attr.license()` rule attributes, which are always non-configurable. |
-| `default` | [int](../core/int); default is `0`  A default value to use if no value for this attribute is given when instantiating the rule. |
-| `doc` | [string](../core/string); or `None`; default is `None`  A description of the attribute that can be extracted by documentation generating tools. |
-| `mandatory` | [bool](../core/bool); default is `False`  If true, the value must be specified explicitly (even if it has a `default`). |
-| `values` | [sequence](../core/list) of [int](../core/int)s; default is `[]`  The list of allowed values for the attribute. An error is raised if any other value is given. |
+| `configurable` | [bool](/versions/8.3.1/rules/lib/core/bool); or unbound; default is `unbound`  This argument can only be specified for an attribute of a symbolic macro. If `configurable` is explicitly set to `False`, the symbolic macro attribute is non-configurable - in other words, it cannot take a `select()` value. If the `configurable` is either unbound or explicitly set to `True`, the attribute is configurable and can take a `select()` value. For an attribute of a rule or aspect, `configurable` must be left unbound. Most Starlark rule attributes are always configurable, with the exception of `attr.output()`, `attr.output_list()`, and `attr.license()` rule attributes, which are always non-configurable. |
+| `default` | [int](/versions/8.3.1/rules/lib/core/int); default is `0`  A default value to use if no value for this attribute is given when instantiating the rule. |
+| `doc` | [string](/versions/8.3.1/rules/lib/core/string); or `None`; default is `None`  A description of the attribute that can be extracted by documentation generating tools. |
+| `mandatory` | [bool](/versions/8.3.1/rules/lib/core/bool); default is `False`  If true, the value must be specified explicitly (even if it has a `default`). |
+| `values` | [sequence](/versions/8.3.1/rules/lib/core/list) of [int](/versions/8.3.1/rules/lib/core/int)s; default is `[]`  The list of allowed values for the attribute. An error is raised if any other value is given. |
 
 ## int\_list
 
@@ -70,11 +70,11 @@ Creates a schema for a list-of-integers attribute. Each element must be in the s
 
 | Parameter | Description |
 | --- | --- |
-| `mandatory` | [bool](../core/bool); default is `False`  If true, the value must be specified explicitly (even if it has a `default`). |
-| `allow_empty` | [bool](../core/bool); default is `True`  True if the attribute can be empty. |
-| `configurable` | [bool](../core/bool); or unbound; default is `unbound`  This argument can only be specified for an attribute of a symbolic macro. If `configurable` is explicitly set to `False`, the symbolic macro attribute is non-configurable - in other words, it cannot take a `select()` value. If the `configurable` is either unbound or explicitly set to `True`, the attribute is configurable and can take a `select()` value. For an attribute of a rule or aspect, `configurable` must be left unbound. Most Starlark rule attributes are always configurable, with the exception of `attr.output()`, `attr.output_list()`, and `attr.license()` rule attributes, which are always non-configurable. |
-| `default` | [sequence](../core/list) of [int](../core/int)s; default is `[]`  A default value to use if no value for this attribute is given when instantiating the rule. |
-| `doc` | [string](../core/string); or `None`; default is `None`  A description of the attribute that can be extracted by documentation generating tools. |
+| `mandatory` | [bool](/versions/8.3.1/rules/lib/core/bool); default is `False`  If true, the value must be specified explicitly (even if it has a `default`). |
+| `allow_empty` | [bool](/versions/8.3.1/rules/lib/core/bool); default is `True`  True if the attribute can be empty. |
+| `configurable` | [bool](/versions/8.3.1/rules/lib/core/bool); or unbound; default is `unbound`  This argument can only be specified for an attribute of a symbolic macro. If `configurable` is explicitly set to `False`, the symbolic macro attribute is non-configurable - in other words, it cannot take a `select()` value. If the `configurable` is either unbound or explicitly set to `True`, the attribute is configurable and can take a `select()` value. For an attribute of a rule or aspect, `configurable` must be left unbound. Most Starlark rule attributes are always configurable, with the exception of `attr.output()`, `attr.output_list()`, and `attr.license()` rule attributes, which are always non-configurable. |
+| `default` | [sequence](/versions/8.3.1/rules/lib/core/list) of [int](/versions/8.3.1/rules/lib/core/int)s; default is `[]`  A default value to use if no value for this attribute is given when instantiating the rule. |
+| `doc` | [string](/versions/8.3.1/rules/lib/core/string); or `None`; default is `None`  A description of the attribute that can be extracted by documentation generating tools. |
 
 ## label
 
@@ -84,9 +84,9 @@ Attribute attr.label(configurable=unbound, default=None, materializer=None, doc=
 
 Creates a schema for a label attribute. This is a dependency attribute.
 
-This attribute contains unique [`Label`](../builtins/Label) values. If a string is supplied in place of a `Label`, it will be converted using the [label constructor](../builtins/Label#Label). The relative parts of the label path, including the (possibly renamed) repository, are resolved with respect to the instantiated target's package.
+This attribute contains unique [`Label`](/versions/8.3.1/rules/lib/builtins/Label) values. If a string is supplied in place of a `Label`, it will be converted using the [label constructor](/versions/8.3.1/rules/lib/builtins/Label#Label). The relative parts of the label path, including the (possibly renamed) repository, are resolved with respect to the instantiated target's package.
 
-At analysis time (within the rule's implementation function), when retrieving the attribute value from `ctx.attr`, labels are replaced by the corresponding [`Target`](../builtins/Target)s. This allows you to access the providers of the current target's dependencies.
+At analysis time (within the rule's implementation function), when retrieving the attribute value from `ctx.attr`, labels are replaced by the corresponding [`Target`](/versions/8.3.1/rules/lib/builtins/Target)s. This allows you to access the providers of the current target's dependencies.
 
 In addition to ordinary source files, this kind of attribute is often used to refer to a tool -- for example, a compiler. Such tools are considered to be dependencies, just like source files. To avoid requiring users to specify the tool's label every time they use the rule in their BUILD files, you can hard-code the label of a canonical tool as the `default` value of this attribute. If you also want to prevent users from overriding this default, you can make the attribute private by giving it a name that starts with an underscore. See the [Rules](https://bazel.build/versions/8.3.1/extending/rules#private-attributes) page for more information.
 
@@ -94,21 +94,21 @@ In addition to ordinary source files, this kind of attribute is often used to re
 
 | Parameter | Description |
 | --- | --- |
-| `configurable` | [bool](../core/bool); or unbound; default is `unbound`  This argument can only be specified for an attribute of a symbolic macro. If `configurable` is explicitly set to `False`, the symbolic macro attribute is non-configurable - in other words, it cannot take a `select()` value. If the `configurable` is either unbound or explicitly set to `True`, the attribute is configurable and can take a `select()` value. For an attribute of a rule or aspect, `configurable` must be left unbound. Most Starlark rule attributes are always configurable, with the exception of `attr.output()`, `attr.output_list()`, and `attr.license()` rule attributes, which are always non-configurable. |
-| `default` | [Label](../builtins/Label); or [string](../core/string); or [LateBoundDefault](../builtins/LateBoundDefault); or NativeComputedDefault; or [function](../core/function); or `None`; default is `None`  A default value to use if no value for this attribute is given when instantiating the rule.Use a string or the [`Label`](../builtins/Label#Label) function to specify a default value, for example, `attr.label(default = "//a:b")`. |
-| `materializer` | [function](../core/function); default is `None`  **Experimental**. This parameter is experimental and may change at any time. Please do not depend on it. It may be enabled on an experimental basis by setting `--experimental_dormant_deps`  If set, the attribute materializes dormant dependencies from the transitive closure. The value of this parameter must be a functon that gets access to the values of the attributes of the rule that either are not dependencies or are marked as available for dependency resolution. It must return either a dormant dependency or a list of them depending on the type of the attribute |
-| `doc` | [string](../core/string); or `None`; default is `None` |
-| `executable` | [bool](../core/bool); default is `False`  True if the dependency has to be executable. This means the label must refer to an executable file, or to a rule that outputs an executable file. Access the label with `ctx.executable.`. |
-| `allow_files` | [bool](../core/bool); or [sequence](../core/list) of [string](../core/string)s; or `None`; default is `None`  Whether `File` targets are allowed. Can be `True`, `False` (default), or a list of file extensions that are allowed (for example, `[".cc", ".cpp"]`). |
-| `allow_single_file` | default is `None`  This is similar to `allow_files`, with the restriction that the label must correspond to a single [File](../builtins/File). Access it through `ctx.file.`. |
-| `mandatory` | [bool](../core/bool); default is `False`  If true, the value must be specified explicitly (even if it has a `default`). |
-| `skip_validations` | [bool](../core/bool); default is `False`  If true, validation actions of transitive dependencies from this attribute will not run. This is a temporary mitigation and WILL be removed in the future. |
-| `providers` | [sequence](../core/list); default is `[]`  The providers that must be given by any dependency appearing in this attribute. The format of this argument is a list of lists of providers -- `*Info` objects returned by [`provider()`](../globals/bzl#provider) (or in the case of a legacy provider, its string name). The dependency must return ALL providers mentioned in at least ONE of the inner lists. As a convenience, this argument may also be a single-level list of providers, in which case it is wrapped in an outer list with one element. It is NOT required that the rule of the dependency advertises those providers in its `provides` parameter, however, it is considered best practice. |
+| `configurable` | [bool](/versions/8.3.1/rules/lib/core/bool); or unbound; default is `unbound`  This argument can only be specified for an attribute of a symbolic macro. If `configurable` is explicitly set to `False`, the symbolic macro attribute is non-configurable - in other words, it cannot take a `select()` value. If the `configurable` is either unbound or explicitly set to `True`, the attribute is configurable and can take a `select()` value. For an attribute of a rule or aspect, `configurable` must be left unbound. Most Starlark rule attributes are always configurable, with the exception of `attr.output()`, `attr.output_list()`, and `attr.license()` rule attributes, which are always non-configurable. |
+| `default` | [Label](/versions/8.3.1/rules/lib/builtins/Label); or [string](/versions/8.3.1/rules/lib/core/string); or [LateBoundDefault](/versions/8.3.1/rules/lib/builtins/LateBoundDefault); or NativeComputedDefault; or [function](/versions/8.3.1/rules/lib/core/function); or `None`; default is `None`  A default value to use if no value for this attribute is given when instantiating the rule.Use a string or the [`Label`](/versions/8.3.1/rules/lib/builtins/Label#Label) function to specify a default value, for example, `attr.label(default = "//a:b")`. |
+| `materializer` | [function](/versions/8.3.1/rules/lib/core/function); default is `None`  **Experimental**. This parameter is experimental and may change at any time. Please do not depend on it. It may be enabled on an experimental basis by setting `--experimental_dormant_deps`  If set, the attribute materializes dormant dependencies from the transitive closure. The value of this parameter must be a functon that gets access to the values of the attributes of the rule that either are not dependencies or are marked as available for dependency resolution. It must return either a dormant dependency or a list of them depending on the type of the attribute |
+| `doc` | [string](/versions/8.3.1/rules/lib/core/string); or `None`; default is `None` |
+| `executable` | [bool](/versions/8.3.1/rules/lib/core/bool); default is `False`  True if the dependency has to be executable. This means the label must refer to an executable file, or to a rule that outputs an executable file. Access the label with `ctx.executable.`. |
+| `allow_files` | [bool](/versions/8.3.1/rules/lib/core/bool); or [sequence](/versions/8.3.1/rules/lib/core/list) of [string](/versions/8.3.1/rules/lib/core/string)s; or `None`; default is `None`  Whether `File` targets are allowed. Can be `True`, `False` (default), or a list of file extensions that are allowed (for example, `[".cc", ".cpp"]`). |
+| `allow_single_file` | default is `None`  This is similar to `allow_files`, with the restriction that the label must correspond to a single [File](/versions/8.3.1/rules/lib/builtins/File). Access it through `ctx.file.`. |
+| `mandatory` | [bool](/versions/8.3.1/rules/lib/core/bool); default is `False`  If true, the value must be specified explicitly (even if it has a `default`). |
+| `skip_validations` | [bool](/versions/8.3.1/rules/lib/core/bool); default is `False`  If true, validation actions of transitive dependencies from this attribute will not run. This is a temporary mitigation and WILL be removed in the future. |
+| `providers` | [sequence](/versions/8.3.1/rules/lib/core/list); default is `[]`  The providers that must be given by any dependency appearing in this attribute. The format of this argument is a list of lists of providers -- `*Info` objects returned by [`provider()`](/versions/8.3.1/rules/lib/globals/bzl#provider) (or in the case of a legacy provider, its string name). The dependency must return ALL providers mentioned in at least ONE of the inner lists. As a convenience, this argument may also be a single-level list of providers, in which case it is wrapped in an outer list with one element. It is NOT required that the rule of the dependency advertises those providers in its `provides` parameter, however, it is considered best practice. |
 | `for_dependency_resolution` | default is `unbound`  If this is set, the attribute is available for materializers. Only rules marked with the flag of the same name are allowed to be referenced through such attributes. |
-| `allow_rules` | [sequence](../core/list) of [string](../core/string)s; or `None`; default is `None`  Which rule targets (name of the classes) are allowed. This is deprecated (kept only for compatibility), use providers instead. |
+| `allow_rules` | [sequence](/versions/8.3.1/rules/lib/core/list) of [string](/versions/8.3.1/rules/lib/core/string)s; or `None`; default is `None`  Which rule targets (name of the classes) are allowed. This is deprecated (kept only for compatibility), use providers instead. |
 | `cfg` | default is `None`  [Configuration](https://bazel.build/versions/8.3.1/extending/rules#configurations) of the attribute. It can be either `"exec"`, which indicates that the dependency is built for the `execution platform`, or `"target"`, which indicates that the dependency is build for the `target platform`. A typical example of the difference is when building mobile apps, where the `target platform` is `Android` or `iOS` while the `execution platform` is `Linux`, `macOS`, or `Windows`. This parameter is required if `executable` is True to guard against accidentally building host tools in the target configuration. `"target"` has no semantic effect, so don't set it when `executable` is False unless it really helps clarify your intentions. |
-| `aspects` | [sequence](../core/list) of [Aspect](../builtins/Aspect)s; default is `[]`  Aspects that should be applied to the dependency or dependencies specified by this attribute. |
-| `flags` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  Deprecated, will be removed. |
+| `aspects` | [sequence](/versions/8.3.1/rules/lib/core/list) of [Aspect](/versions/8.3.1/rules/lib/builtins/Aspect)s; default is `[]`  Aspects that should be applied to the dependency or dependencies specified by this attribute. |
+| `flags` | [sequence](/versions/8.3.1/rules/lib/core/list) of [string](/versions/8.3.1/rules/lib/core/string)s; default is `[]`  Deprecated, will be removed. |
 
 ## label\_keyed\_string\_dict
 
@@ -118,26 +118,26 @@ Attribute attr.label_keyed_string_dict(allow_empty=True, *, configurable=unbound
 
 Creates a schema for an attribute holding a dictionary, where the keys are labels and the values are strings. This is a dependency attribute.
 
-This attribute contains unique [`Label`](../builtins/Label) values. If a string is supplied in place of a `Label`, it will be converted using the [label constructor](../builtins/Label#Label). The relative parts of the label path, including the (possibly renamed) repository, are resolved with respect to the instantiated target's package.
+This attribute contains unique [`Label`](/versions/8.3.1/rules/lib/builtins/Label) values. If a string is supplied in place of a `Label`, it will be converted using the [label constructor](/versions/8.3.1/rules/lib/builtins/Label#Label). The relative parts of the label path, including the (possibly renamed) repository, are resolved with respect to the instantiated target's package.
 
-At analysis time (within the rule's implementation function), when retrieving the attribute value from `ctx.attr`, labels are replaced by the corresponding [`Target`](../builtins/Target)s. This allows you to access the providers of the current target's dependencies.
+At analysis time (within the rule's implementation function), when retrieving the attribute value from `ctx.attr`, labels are replaced by the corresponding [`Target`](/versions/8.3.1/rules/lib/builtins/Target)s. This allows you to access the providers of the current target's dependencies.
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `allow_empty` | [bool](../core/bool); default is `True`  True if the attribute can be empty. |
-| `configurable` | [bool](../core/bool); or unbound; default is `unbound`  This argument can only be specified for an attribute of a symbolic macro. If `configurable` is explicitly set to `False`, the symbolic macro attribute is non-configurable - in other words, it cannot take a `select()` value. If the `configurable` is either unbound or explicitly set to `True`, the attribute is configurable and can take a `select()` value. For an attribute of a rule or aspect, `configurable` must be left unbound. Most Starlark rule attributes are always configurable, with the exception of `attr.output()`, `attr.output_list()`, and `attr.license()` rule attributes, which are always non-configurable. |
-| `default` | [dict](../core/dict); or [function](../core/function); default is `{}`  A default value to use if no value for this attribute is given when instantiating the rule.Use strings or the [`Label`](../builtins/Label#Label) function to specify default values, for example, `attr.label_keyed_string_dict(default = {"//a:b": "value", "//a:c": "string"})`. |
-| `doc` | [string](../core/string); or `None`; default is `None`  A description of the attribute that can be extracted by documentation generating tools. |
-| `allow_files` | [bool](../core/bool); or [sequence](../core/list) of [string](../core/string)s; or `None`; default is `None`  Whether `File` targets are allowed. Can be `True`, `False` (default), or a list of file extensions that are allowed (for example, `[".cc", ".cpp"]`). |
-| `allow_rules` | [sequence](../core/list) of [string](../core/string)s; or `None`; default is `None`  Which rule targets (name of the classes) are allowed. This is deprecated (kept only for compatibility), use providers instead. |
-| `providers` | [sequence](../core/list); default is `[]`  The providers that must be given by any dependency appearing in this attribute. The format of this argument is a list of lists of providers -- `*Info` objects returned by [`provider()`](../globals/bzl#provider) (or in the case of a legacy provider, its string name). The dependency must return ALL providers mentioned in at least ONE of the inner lists. As a convenience, this argument may also be a single-level list of providers, in which case it is wrapped in an outer list with one element. It is NOT required that the rule of the dependency advertises those providers in its `provides` parameter, however, it is considered best practice. |
+| `allow_empty` | [bool](/versions/8.3.1/rules/lib/core/bool); default is `True`  True if the attribute can be empty. |
+| `configurable` | [bool](/versions/8.3.1/rules/lib/core/bool); or unbound; default is `unbound`  This argument can only be specified for an attribute of a symbolic macro. If `configurable` is explicitly set to `False`, the symbolic macro attribute is non-configurable - in other words, it cannot take a `select()` value. If the `configurable` is either unbound or explicitly set to `True`, the attribute is configurable and can take a `select()` value. For an attribute of a rule or aspect, `configurable` must be left unbound. Most Starlark rule attributes are always configurable, with the exception of `attr.output()`, `attr.output_list()`, and `attr.license()` rule attributes, which are always non-configurable. |
+| `default` | [dict](/versions/8.3.1/rules/lib/core/dict); or [function](/versions/8.3.1/rules/lib/core/function); default is `{}`  A default value to use if no value for this attribute is given when instantiating the rule.Use strings or the [`Label`](/versions/8.3.1/rules/lib/builtins/Label#Label) function to specify default values, for example, `attr.label_keyed_string_dict(default = {"//a:b": "value", "//a:c": "string"})`. |
+| `doc` | [string](/versions/8.3.1/rules/lib/core/string); or `None`; default is `None`  A description of the attribute that can be extracted by documentation generating tools. |
+| `allow_files` | [bool](/versions/8.3.1/rules/lib/core/bool); or [sequence](/versions/8.3.1/rules/lib/core/list) of [string](/versions/8.3.1/rules/lib/core/string)s; or `None`; default is `None`  Whether `File` targets are allowed. Can be `True`, `False` (default), or a list of file extensions that are allowed (for example, `[".cc", ".cpp"]`). |
+| `allow_rules` | [sequence](/versions/8.3.1/rules/lib/core/list) of [string](/versions/8.3.1/rules/lib/core/string)s; or `None`; default is `None`  Which rule targets (name of the classes) are allowed. This is deprecated (kept only for compatibility), use providers instead. |
+| `providers` | [sequence](/versions/8.3.1/rules/lib/core/list); default is `[]`  The providers that must be given by any dependency appearing in this attribute. The format of this argument is a list of lists of providers -- `*Info` objects returned by [`provider()`](/versions/8.3.1/rules/lib/globals/bzl#provider) (or in the case of a legacy provider, its string name). The dependency must return ALL providers mentioned in at least ONE of the inner lists. As a convenience, this argument may also be a single-level list of providers, in which case it is wrapped in an outer list with one element. It is NOT required that the rule of the dependency advertises those providers in its `provides` parameter, however, it is considered best practice. |
 | `for_dependency_resolution` | default is `unbound`  If this is set, the attribute is available for materializers. Only rules marked with the flag of the same name are allowed to be referenced through such attributes. |
-| `flags` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  Deprecated, will be removed. |
-| `mandatory` | [bool](../core/bool); default is `False`  If true, the value must be specified explicitly (even if it has a `default`). |
+| `flags` | [sequence](/versions/8.3.1/rules/lib/core/list) of [string](/versions/8.3.1/rules/lib/core/string)s; default is `[]`  Deprecated, will be removed. |
+| `mandatory` | [bool](/versions/8.3.1/rules/lib/core/bool); default is `False`  If true, the value must be specified explicitly (even if it has a `default`). |
 | `cfg` | default is `None`  [Configuration](https://bazel.build/versions/8.3.1/extending/rules#configurations) of the attribute. It can be either `"exec"`, which indicates that the dependency is built for the `execution platform`, or `"target"`, which indicates that the dependency is build for the `target platform`. A typical example of the difference is when building mobile apps, where the `target platform` is `Android` or `iOS` while the `execution platform` is `Linux`, `macOS`, or `Windows`. |
-| `aspects` | [sequence](../core/list) of [Aspect](../builtins/Aspect)s; default is `[]`  Aspects that should be applied to the dependency or dependencies specified by this attribute. |
+| `aspects` | [sequence](/versions/8.3.1/rules/lib/core/list) of [Aspect](/versions/8.3.1/rules/lib/builtins/Aspect)s; default is `[]`  Aspects that should be applied to the dependency or dependencies specified by this attribute. |
 
 ## label\_list
 
@@ -145,30 +145,30 @@ At analysis time (within the rule's implementation function), when retrieving th
 Attribute attr.label_list(allow_empty=True, *, configurable=unbound, default=[], materializer=None, doc=None, allow_files=None, allow_rules=None, providers=[], for_dependency_resolution=unbound, flags=[], mandatory=False, skip_validations=False, cfg=None, aspects=[])
 ```
 
-Creates a schema for a list-of-labels attribute. This is a dependency attribute. The corresponding [`ctx.attr`](../builtins/ctx#attr) attribute will be of type [list](../core/list) of [`Target`s](../builtins/Target).
+Creates a schema for a list-of-labels attribute. This is a dependency attribute. The corresponding [`ctx.attr`](/versions/8.3.1/rules/lib/builtins/ctx#attr) attribute will be of type [list](/versions/8.3.1/rules/lib/core/list) of [`Target`s](/versions/8.3.1/rules/lib/builtins/Target).
 
-This attribute contains unique [`Label`](../builtins/Label) values. If a string is supplied in place of a `Label`, it will be converted using the [label constructor](../builtins/Label#Label). The relative parts of the label path, including the (possibly renamed) repository, are resolved with respect to the instantiated target's package.
+This attribute contains unique [`Label`](/versions/8.3.1/rules/lib/builtins/Label) values. If a string is supplied in place of a `Label`, it will be converted using the [label constructor](/versions/8.3.1/rules/lib/builtins/Label#Label). The relative parts of the label path, including the (possibly renamed) repository, are resolved with respect to the instantiated target's package.
 
-At analysis time (within the rule's implementation function), when retrieving the attribute value from `ctx.attr`, labels are replaced by the corresponding [`Target`](../builtins/Target)s. This allows you to access the providers of the current target's dependencies.
+At analysis time (within the rule's implementation function), when retrieving the attribute value from `ctx.attr`, labels are replaced by the corresponding [`Target`](/versions/8.3.1/rules/lib/builtins/Target)s. This allows you to access the providers of the current target's dependencies.
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `allow_empty` | [bool](../core/bool); default is `True`  True if the attribute can be empty. |
-| `configurable` | [bool](../core/bool); or unbound; default is `unbound`  This argument can only be specified for an attribute of a symbolic macro. If `configurable` is explicitly set to `False`, the symbolic macro attribute is non-configurable - in other words, it cannot take a `select()` value. If the `configurable` is either unbound or explicitly set to `True`, the attribute is configurable and can take a `select()` value. For an attribute of a rule or aspect, `configurable` must be left unbound. Most Starlark rule attributes are always configurable, with the exception of `attr.output()`, `attr.output_list()`, and `attr.license()` rule attributes, which are always non-configurable. |
-| `default` | [sequence](../core/list) of [Label](../builtins/Label)s; or [function](../core/function); default is `[]`  A default value to use if no value for this attribute is given when instantiating the rule.Use strings or the [`Label`](../builtins/Label#Label) function to specify default values, for example, `attr.label_list(default = ["//a:b", "//a:c"])`. |
-| `materializer` | [function](../core/function); default is `None`  **Experimental**. This parameter is experimental and may change at any time. Please do not depend on it. It may be enabled on an experimental basis by setting `--experimental_dormant_deps`  If set, the attribute materializes dormant dependencies from the transitive closure. The value of this parameter must be a functon that gets access to the values of the attributes of the rule that either are not dependencies or are marked as available for dependency resolution. It must return either a dormant dependency or a list of them depending on the type of the attribute |
-| `doc` | [string](../core/string); or `None`; default is `None` |
-| `allow_files` | [bool](../core/bool); or [sequence](../core/list) of [string](../core/string)s; or `None`; default is `None`  Whether `File` targets are allowed. Can be `True`, `False` (default), or a list of file extensions that are allowed (for example, `[".cc", ".cpp"]`). |
-| `allow_rules` | [sequence](../core/list) of [string](../core/string)s; or `None`; default is `None`  Which rule targets (name of the classes) are allowed. This is deprecated (kept only for compatibility), use providers instead. |
-| `providers` | [sequence](../core/list); default is `[]`  The providers that must be given by any dependency appearing in this attribute. The format of this argument is a list of lists of providers -- `*Info` objects returned by [`provider()`](../globals/bzl#provider) (or in the case of a legacy provider, its string name). The dependency must return ALL providers mentioned in at least ONE of the inner lists. As a convenience, this argument may also be a single-level list of providers, in which case it is wrapped in an outer list with one element. It is NOT required that the rule of the dependency advertises those providers in its `provides` parameter, however, it is considered best practice. |
+| `allow_empty` | [bool](/versions/8.3.1/rules/lib/core/bool); default is `True`  True if the attribute can be empty. |
+| `configurable` | [bool](/versions/8.3.1/rules/lib/core/bool); or unbound; default is `unbound`  This argument can only be specified for an attribute of a symbolic macro. If `configurable` is explicitly set to `False`, the symbolic macro attribute is non-configurable - in other words, it cannot take a `select()` value. If the `configurable` is either unbound or explicitly set to `True`, the attribute is configurable and can take a `select()` value. For an attribute of a rule or aspect, `configurable` must be left unbound. Most Starlark rule attributes are always configurable, with the exception of `attr.output()`, `attr.output_list()`, and `attr.license()` rule attributes, which are always non-configurable. |
+| `default` | [sequence](/versions/8.3.1/rules/lib/core/list) of [Label](/versions/8.3.1/rules/lib/builtins/Label)s; or [function](/versions/8.3.1/rules/lib/core/function); default is `[]`  A default value to use if no value for this attribute is given when instantiating the rule.Use strings or the [`Label`](/versions/8.3.1/rules/lib/builtins/Label#Label) function to specify default values, for example, `attr.label_list(default = ["//a:b", "//a:c"])`. |
+| `materializer` | [function](/versions/8.3.1/rules/lib/core/function); default is `None`  **Experimental**. This parameter is experimental and may change at any time. Please do not depend on it. It may be enabled on an experimental basis by setting `--experimental_dormant_deps`  If set, the attribute materializes dormant dependencies from the transitive closure. The value of this parameter must be a functon that gets access to the values of the attributes of the rule that either are not dependencies or are marked as available for dependency resolution. It must return either a dormant dependency or a list of them depending on the type of the attribute |
+| `doc` | [string](/versions/8.3.1/rules/lib/core/string); or `None`; default is `None` |
+| `allow_files` | [bool](/versions/8.3.1/rules/lib/core/bool); or [sequence](/versions/8.3.1/rules/lib/core/list) of [string](/versions/8.3.1/rules/lib/core/string)s; or `None`; default is `None`  Whether `File` targets are allowed. Can be `True`, `False` (default), or a list of file extensions that are allowed (for example, `[".cc", ".cpp"]`). |
+| `allow_rules` | [sequence](/versions/8.3.1/rules/lib/core/list) of [string](/versions/8.3.1/rules/lib/core/string)s; or `None`; default is `None`  Which rule targets (name of the classes) are allowed. This is deprecated (kept only for compatibility), use providers instead. |
+| `providers` | [sequence](/versions/8.3.1/rules/lib/core/list); default is `[]`  The providers that must be given by any dependency appearing in this attribute. The format of this argument is a list of lists of providers -- `*Info` objects returned by [`provider()`](/versions/8.3.1/rules/lib/globals/bzl#provider) (or in the case of a legacy provider, its string name). The dependency must return ALL providers mentioned in at least ONE of the inner lists. As a convenience, this argument may also be a single-level list of providers, in which case it is wrapped in an outer list with one element. It is NOT required that the rule of the dependency advertises those providers in its `provides` parameter, however, it is considered best practice. |
 | `for_dependency_resolution` | default is `unbound`  If this is set, the attribute is available for materializers. Only rules marked with the flag of the same name are allowed to be referenced through such attributes. |
-| `flags` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  Deprecated, will be removed. |
-| `mandatory` | [bool](../core/bool); default is `False`  If true, the value must be specified explicitly (even if it has a `default`). |
-| `skip_validations` | [bool](../core/bool); default is `False`  If true, validation actions of transitive dependencies from this attribute will not run. This is a temporary mitigation and WILL be removed in the future. |
+| `flags` | [sequence](/versions/8.3.1/rules/lib/core/list) of [string](/versions/8.3.1/rules/lib/core/string)s; default is `[]`  Deprecated, will be removed. |
+| `mandatory` | [bool](/versions/8.3.1/rules/lib/core/bool); default is `False`  If true, the value must be specified explicitly (even if it has a `default`). |
+| `skip_validations` | [bool](/versions/8.3.1/rules/lib/core/bool); default is `False`  If true, validation actions of transitive dependencies from this attribute will not run. This is a temporary mitigation and WILL be removed in the future. |
 | `cfg` | default is `None`  [Configuration](https://bazel.build/versions/8.3.1/extending/rules#configurations) of the attribute. It can be either `"exec"`, which indicates that the dependency is built for the `execution platform`, or `"target"`, which indicates that the dependency is build for the `target platform`. A typical example of the difference is when building mobile apps, where the `target platform` is `Android` or `iOS` while the `execution platform` is `Linux`, `macOS`, or `Windows`. |
-| `aspects` | [sequence](../core/list) of [Aspect](../builtins/Aspect)s; default is `[]`  Aspects that should be applied to the dependency or dependencies specified by this attribute. |
+| `aspects` | [sequence](/versions/8.3.1/rules/lib/core/list) of [Aspect](/versions/8.3.1/rules/lib/builtins/Aspect)s; default is `[]`  Aspects that should be applied to the dependency or dependencies specified by this attribute. |
 
 ## output
 
@@ -178,16 +178,16 @@ Attribute attr.output(doc=None, mandatory=False)
 
 Creates a schema for an output (label) attribute.
 
-This attribute contains unique [`Label`](../builtins/Label) values. If a string is supplied in place of a `Label`, it will be converted using the [label constructor](../builtins/Label#Label). The relative parts of the label path, including the (possibly renamed) repository, are resolved with respect to the instantiated target's package.
+This attribute contains unique [`Label`](/versions/8.3.1/rules/lib/builtins/Label) values. If a string is supplied in place of a `Label`, it will be converted using the [label constructor](/versions/8.3.1/rules/lib/builtins/Label#Label). The relative parts of the label path, including the (possibly renamed) repository, are resolved with respect to the instantiated target's package.
 
-At analysis time, the corresponding [`File`](../builtins/File) can be retrieved using [`ctx.outputs`](../builtins/ctx#outputs).
+At analysis time, the corresponding [`File`](/versions/8.3.1/rules/lib/builtins/File) can be retrieved using [`ctx.outputs`](/versions/8.3.1/rules/lib/builtins/ctx#outputs).
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `doc` | [string](../core/string); or `None`; default is `None`  A description of the attribute that can be extracted by documentation generating tools. |
-| `mandatory` | [bool](../core/bool); default is `False`  If true, the value must be specified explicitly (even if it has a `default`). |
+| `doc` | [string](/versions/8.3.1/rules/lib/core/string); or `None`; default is `None`  A description of the attribute that can be extracted by documentation generating tools. |
+| `mandatory` | [bool](/versions/8.3.1/rules/lib/core/bool); default is `False`  If true, the value must be specified explicitly (even if it has a `default`). |
 
 ## output\_list
 
@@ -197,17 +197,17 @@ Attribute attr.output_list(allow_empty=True, *, doc=None, mandatory=False)
 
 Creates a schema for a list-of-outputs attribute.
 
-This attribute contains unique [`Label`](../builtins/Label) values. If a string is supplied in place of a `Label`, it will be converted using the [label constructor](../builtins/Label#Label). The relative parts of the label path, including the (possibly renamed) repository, are resolved with respect to the instantiated target's package.
+This attribute contains unique [`Label`](/versions/8.3.1/rules/lib/builtins/Label) values. If a string is supplied in place of a `Label`, it will be converted using the [label constructor](/versions/8.3.1/rules/lib/builtins/Label#Label). The relative parts of the label path, including the (possibly renamed) repository, are resolved with respect to the instantiated target's package.
 
-At analysis time, the corresponding [`File`](../builtins/File) can be retrieved using [`ctx.outputs`](../builtins/ctx#outputs).
+At analysis time, the corresponding [`File`](/versions/8.3.1/rules/lib/builtins/File) can be retrieved using [`ctx.outputs`](/versions/8.3.1/rules/lib/builtins/ctx#outputs).
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `allow_empty` | [bool](../core/bool); default is `True`  True if the attribute can be empty. |
-| `doc` | [string](../core/string); or `None`; default is `None`  A description of the attribute that can be extracted by documentation generating tools. |
-| `mandatory` | [bool](../core/bool); default is `False`  If true, the value must be specified explicitly (even if it has a `default`). |
+| `allow_empty` | [bool](/versions/8.3.1/rules/lib/core/bool); default is `True`  True if the attribute can be empty. |
+| `doc` | [string](/versions/8.3.1/rules/lib/core/string); or `None`; default is `None`  A description of the attribute that can be extracted by documentation generating tools. |
+| `mandatory` | [bool](/versions/8.3.1/rules/lib/core/bool); default is `False`  If true, the value must be specified explicitly (even if it has a `default`). |
 
 ## string
 
@@ -215,17 +215,17 @@ At analysis time, the corresponding [`File`](../builtins/File) can be retrieved
 Attribute attr.string(configurable=unbound, default='', doc=None, mandatory=False, values=[])
 ```
 
-Creates a schema for a [string](../core/string#attr) attribute.
+Creates a schema for a [string](/versions/8.3.1/rules/lib/core/string#attr) attribute.
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `configurable` | [bool](../core/bool); or unbound; default is `unbound`  This argument can only be specified for an attribute of a symbolic macro. If `configurable` is explicitly set to `False`, the symbolic macro attribute is non-configurable - in other words, it cannot take a `select()` value. If the `configurable` is either unbound or explicitly set to `True`, the attribute is configurable and can take a `select()` value. For an attribute of a rule or aspect, `configurable` must be left unbound. Most Starlark rule attributes are always configurable, with the exception of `attr.output()`, `attr.output_list()`, and `attr.license()` rule attributes, which are always non-configurable. |
-| `default` | [string](../core/string); or NativeComputedDefault; default is `''`  A default value to use if no value for this attribute is given when instantiating the rule. |
-| `doc` | [string](../core/string); or `None`; default is `None`  A description of the attribute that can be extracted by documentation generating tools. |
-| `mandatory` | [bool](../core/bool); default is `False`  If true, the value must be specified explicitly (even if it has a `default`). |
-| `values` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  The list of allowed values for the attribute. An error is raised if any other value is given. |
+| `configurable` | [bool](/versions/8.3.1/rules/lib/core/bool); or unbound; default is `unbound`  This argument can only be specified for an attribute of a symbolic macro. If `configurable` is explicitly set to `False`, the symbolic macro attribute is non-configurable - in other words, it cannot take a `select()` value. If the `configurable` is either unbound or explicitly set to `True`, the attribute is configurable and can take a `select()` value. For an attribute of a rule or aspect, `configurable` must be left unbound. Most Starlark rule attributes are always configurable, with the exception of `attr.output()`, `attr.output_list()`, and `attr.license()` rule attributes, which are always non-configurable. |
+| `default` | [string](/versions/8.3.1/rules/lib/core/string); or NativeComputedDefault; default is `''`  A default value to use if no value for this attribute is given when instantiating the rule. |
+| `doc` | [string](/versions/8.3.1/rules/lib/core/string); or `None`; default is `None`  A description of the attribute that can be extracted by documentation generating tools. |
+| `mandatory` | [bool](/versions/8.3.1/rules/lib/core/bool); default is `False`  If true, the value must be specified explicitly (even if it has a `default`). |
+| `values` | [sequence](/versions/8.3.1/rules/lib/core/list) of [string](/versions/8.3.1/rules/lib/core/string)s; default is `[]`  The list of allowed values for the attribute. An error is raised if any other value is given. |
 
 ## string\_dict
 
@@ -239,11 +239,11 @@ Creates a schema for an attribute holding a dictionary, where the keys and value
 
 | Parameter | Description |
 | --- | --- |
-| `allow_empty` | [bool](../core/bool); default is `True`  True if the attribute can be empty. |
-| `configurable` | [bool](../core/bool); or unbound; default is `unbound`  This argument can only be specified for an attribute of a symbolic macro. If `configurable` is explicitly set to `False`, the symbolic macro attribute is non-configurable - in other words, it cannot take a `select()` value. If the `configurable` is either unbound or explicitly set to `True`, the attribute is configurable and can take a `select()` value. For an attribute of a rule or aspect, `configurable` must be left unbound. Most Starlark rule attributes are always configurable, with the exception of `attr.output()`, `attr.output_list()`, and `attr.license()` rule attributes, which are always non-configurable. |
-| `default` | [dict](../core/dict); default is `{}`  A default value to use if no value for this attribute is given when instantiating the rule. |
-| `doc` | [string](../core/string); or `None`; default is `None`  A description of the attribute that can be extracted by documentation generating tools. |
-| `mandatory` | [bool](../core/bool); default is `False`  If true, the value must be specified explicitly (even if it has a `default`). |
+| `allow_empty` | [bool](/versions/8.3.1/rules/lib/core/bool); default is `True`  True if the attribute can be empty. |
+| `configurable` | [bool](/versions/8.3.1/rules/lib/core/bool); or unbound; default is `unbound`  This argument can only be specified for an attribute of a symbolic macro. If `configurable` is explicitly set to `False`, the symbolic macro attribute is non-configurable - in other words, it cannot take a `select()` value. If the `configurable` is either unbound or explicitly set to `True`, the attribute is configurable and can take a `select()` value. For an attribute of a rule or aspect, `configurable` must be left unbound. Most Starlark rule attributes are always configurable, with the exception of `attr.output()`, `attr.output_list()`, and `attr.license()` rule attributes, which are always non-configurable. |
+| `default` | [dict](/versions/8.3.1/rules/lib/core/dict); default is `{}`  A default value to use if no value for this attribute is given when instantiating the rule. |
+| `doc` | [string](/versions/8.3.1/rules/lib/core/string); or `None`; default is `None`  A description of the attribute that can be extracted by documentation generating tools. |
+| `mandatory` | [bool](/versions/8.3.1/rules/lib/core/bool); default is `False`  If true, the value must be specified explicitly (even if it has a `default`). |
 
 ## string\_keyed\_label\_dict
 
@@ -253,26 +253,26 @@ Attribute attr.string_keyed_label_dict(allow_empty=True, *, configurable=unbound
 
 Creates a schema for an attribute whose value is a dictionary where the keys are strings and the values are labels. This is a dependency attribute.
 
-This attribute contains unique [`Label`](../builtins/Label) values. If a string is supplied in place of a `Label`, it will be converted using the [label constructor](../builtins/Label#Label). The relative parts of the label path, including the (possibly renamed) repository, are resolved with respect to the instantiated target's package.
+This attribute contains unique [`Label`](/versions/8.3.1/rules/lib/builtins/Label) values. If a string is supplied in place of a `Label`, it will be converted using the [label constructor](/versions/8.3.1/rules/lib/builtins/Label#Label). The relative parts of the label path, including the (possibly renamed) repository, are resolved with respect to the instantiated target's package.
 
-At analysis time (within the rule's implementation function), when retrieving the attribute value from `ctx.attr`, labels are replaced by the corresponding [`Target`](../builtins/Target)s. This allows you to access the providers of the current target's dependencies.
+At analysis time (within the rule's implementation function), when retrieving the attribute value from `ctx.attr`, labels are replaced by the corresponding [`Target`](/versions/8.3.1/rules/lib/builtins/Target)s. This allows you to access the providers of the current target's dependencies.
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `allow_empty` | [bool](../core/bool); default is `True`  True if the attribute can be empty. |
-| `configurable` | [bool](../core/bool); or unbound; default is `unbound`  This argument can only be specified for an attribute of a symbolic macro. If `configurable` is explicitly set to `False`, the symbolic macro attribute is non-configurable - in other words, it cannot take a `select()` value. If the `configurable` is either unbound or explicitly set to `True`, the attribute is configurable and can take a `select()` value. For an attribute of a rule or aspect, `configurable` must be left unbound. Most Starlark rule attributes are always configurable, with the exception of `attr.output()`, `attr.output_list()`, and `attr.license()` rule attributes, which are always non-configurable. |
-| `default` | [dict](../core/dict); or [function](../core/function); default is `{}`  A default value to use if no value for this attribute is given when instantiating the rule.Use strings or the [`Label`](../builtins/Label#Label) function to specify default values, for example, `attr.string_keyed_label_dict(default = {"foo": "//a:b", "bar": "//a:c"})`. |
-| `doc` | [string](../core/string); or `None`; default is `None`  A description of the attribute that can be extracted by documentation generating tools. |
-| `allow_files` | [bool](../core/bool); or [sequence](../core/list) of [string](../core/string)s; or `None`; default is `None`  Whether `File` targets are allowed. Can be `True`, `False` (default), or a list of file extensions that are allowed (for example, `[".cc", ".cpp"]`). |
-| `allow_rules` | [sequence](../core/list) of [string](../core/string)s; or `None`; default is `None`  Which rule targets (name of the classes) are allowed. This is deprecated (kept only for compatibility), use providers instead. |
-| `providers` | [sequence](../core/list); default is `[]`  The providers that must be given by any dependency appearing in this attribute. The format of this argument is a list of lists of providers -- `*Info` objects returned by [`provider()`](../globals/bzl#provider) (or in the case of a legacy provider, its string name). The dependency must return ALL providers mentioned in at least ONE of the inner lists. As a convenience, this argument may also be a single-level list of providers, in which case it is wrapped in an outer list with one element. It is NOT required that the rule of the dependency advertises those providers in its `provides` parameter, however, it is considered best practice. |
+| `allow_empty` | [bool](/versions/8.3.1/rules/lib/core/bool); default is `True`  True if the attribute can be empty. |
+| `configurable` | [bool](/versions/8.3.1/rules/lib/core/bool); or unbound; default is `unbound`  This argument can only be specified for an attribute of a symbolic macro. If `configurable` is explicitly set to `False`, the symbolic macro attribute is non-configurable - in other words, it cannot take a `select()` value. If the `configurable` is either unbound or explicitly set to `True`, the attribute is configurable and can take a `select()` value. For an attribute of a rule or aspect, `configurable` must be left unbound. Most Starlark rule attributes are always configurable, with the exception of `attr.output()`, `attr.output_list()`, and `attr.license()` rule attributes, which are always non-configurable. |
+| `default` | [dict](/versions/8.3.1/rules/lib/core/dict); or [function](/versions/8.3.1/rules/lib/core/function); default is `{}`  A default value to use if no value for this attribute is given when instantiating the rule.Use strings or the [`Label`](/versions/8.3.1/rules/lib/builtins/Label#Label) function to specify default values, for example, `attr.string_keyed_label_dict(default = {"foo": "//a:b", "bar": "//a:c"})`. |
+| `doc` | [string](/versions/8.3.1/rules/lib/core/string); or `None`; default is `None`  A description of the attribute that can be extracted by documentation generating tools. |
+| `allow_files` | [bool](/versions/8.3.1/rules/lib/core/bool); or [sequence](/versions/8.3.1/rules/lib/core/list) of [string](/versions/8.3.1/rules/lib/core/string)s; or `None`; default is `None`  Whether `File` targets are allowed. Can be `True`, `False` (default), or a list of file extensions that are allowed (for example, `[".cc", ".cpp"]`). |
+| `allow_rules` | [sequence](/versions/8.3.1/rules/lib/core/list) of [string](/versions/8.3.1/rules/lib/core/string)s; or `None`; default is `None`  Which rule targets (name of the classes) are allowed. This is deprecated (kept only for compatibility), use providers instead. |
+| `providers` | [sequence](/versions/8.3.1/rules/lib/core/list); default is `[]`  The providers that must be given by any dependency appearing in this attribute. The format of this argument is a list of lists of providers -- `*Info` objects returned by [`provider()`](/versions/8.3.1/rules/lib/globals/bzl#provider) (or in the case of a legacy provider, its string name). The dependency must return ALL providers mentioned in at least ONE of the inner lists. As a convenience, this argument may also be a single-level list of providers, in which case it is wrapped in an outer list with one element. It is NOT required that the rule of the dependency advertises those providers in its `provides` parameter, however, it is considered best practice. |
 | `for_dependency_resolution` | default is `unbound`  If this is set, the attribute is available for materializers. Only rules marked with the flag of the same name are allowed to be referenced through such attributes. |
-| `flags` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  Deprecated, will be removed. |
-| `mandatory` | [bool](../core/bool); default is `False`  If true, the value must be specified explicitly (even if it has a `default`). |
+| `flags` | [sequence](/versions/8.3.1/rules/lib/core/list) of [string](/versions/8.3.1/rules/lib/core/string)s; default is `[]`  Deprecated, will be removed. |
+| `mandatory` | [bool](/versions/8.3.1/rules/lib/core/bool); default is `False`  If true, the value must be specified explicitly (even if it has a `default`). |
 | `cfg` | default is `None`  [Configuration](https://bazel.build/versions/8.3.1/extending/rules#configurations) of the attribute. It can be either `"exec"`, which indicates that the dependency is built for the `execution platform`, or `"target"`, which indicates that the dependency is build for the `target platform`. A typical example of the difference is when building mobile apps, where the `target platform` is `Android` or `iOS` while the `execution platform` is `Linux`, `macOS`, or `Windows`. |
-| `aspects` | [sequence](../core/list) of [Aspect](../builtins/Aspect)s; default is `[]`  Aspects that should be applied to the dependency or dependencies specified by this attribute. |
+| `aspects` | [sequence](/versions/8.3.1/rules/lib/core/list) of [Aspect](/versions/8.3.1/rules/lib/builtins/Aspect)s; default is `[]`  Aspects that should be applied to the dependency or dependencies specified by this attribute. |
 
 ## string\_list
 
@@ -286,11 +286,11 @@ Creates a schema for a list-of-strings attribute.
 
 | Parameter | Description |
 | --- | --- |
-| `mandatory` | [bool](../core/bool); default is `False`  If true, the value must be specified explicitly (even if it has a `default`). |
-| `allow_empty` | [bool](../core/bool); default is `True`  True if the attribute can be empty. |
-| `configurable` | [bool](../core/bool); or unbound; default is `unbound`  This argument can only be specified for an attribute of a symbolic macro. If `configurable` is explicitly set to `False`, the symbolic macro attribute is non-configurable - in other words, it cannot take a `select()` value. If the `configurable` is either unbound or explicitly set to `True`, the attribute is configurable and can take a `select()` value. For an attribute of a rule or aspect, `configurable` must be left unbound. Most Starlark rule attributes are always configurable, with the exception of `attr.output()`, `attr.output_list()`, and `attr.license()` rule attributes, which are always non-configurable. |
-| `default` | [sequence](../core/list) of [string](../core/string)s; or NativeComputedDefault; default is `[]`  A default value to use if no value for this attribute is given when instantiating the rule. |
-| `doc` | [string](../core/string); or `None`; default is `None`  A description of the attribute that can be extracted by documentation generating tools. |
+| `mandatory` | [bool](/versions/8.3.1/rules/lib/core/bool); default is `False`  If true, the value must be specified explicitly (even if it has a `default`). |
+| `allow_empty` | [bool](/versions/8.3.1/rules/lib/core/bool); default is `True`  True if the attribute can be empty. |
+| `configurable` | [bool](/versions/8.3.1/rules/lib/core/bool); or unbound; default is `unbound`  This argument can only be specified for an attribute of a symbolic macro. If `configurable` is explicitly set to `False`, the symbolic macro attribute is non-configurable - in other words, it cannot take a `select()` value. If the `configurable` is either unbound or explicitly set to `True`, the attribute is configurable and can take a `select()` value. For an attribute of a rule or aspect, `configurable` must be left unbound. Most Starlark rule attributes are always configurable, with the exception of `attr.output()`, `attr.output_list()`, and `attr.license()` rule attributes, which are always non-configurable. |
+| `default` | [sequence](/versions/8.3.1/rules/lib/core/list) of [string](/versions/8.3.1/rules/lib/core/string)s; or NativeComputedDefault; default is `[]`  A default value to use if no value for this attribute is given when instantiating the rule. |
+| `doc` | [string](/versions/8.3.1/rules/lib/core/string); or `None`; default is `None`  A description of the attribute that can be extracted by documentation generating tools. |
 
 ## string\_list\_dict
 
@@ -304,8 +304,8 @@ Creates a schema for an attribute holding a dictionary, where the keys are strin
 
 | Parameter | Description |
 | --- | --- |
-| `allow_empty` | [bool](../core/bool); default is `True`  True if the attribute can be empty. |
-| `configurable` | [bool](../core/bool); or unbound; default is `unbound`  This argument can only be specified for an attribute of a symbolic macro. If `configurable` is explicitly set to `False`, the symbolic macro attribute is non-configurable - in other words, it cannot take a `select()` value. If the `configurable` is either unbound or explicitly set to `True`, the attribute is configurable and can take a `select()` value. For an attribute of a rule or aspect, `configurable` must be left unbound. Most Starlark rule attributes are always configurable, with the exception of `attr.output()`, `attr.output_list()`, and `attr.license()` rule attributes, which are always non-configurable. |
-| `default` | [dict](../core/dict); default is `{}`  A default value to use if no value for this attribute is given when instantiating the rule. |
-| `doc` | [string](../core/string); or `None`; default is `None`  A description of the attribute that can be extracted by documentation generating tools. |
-| `mandatory` | [bool](../core/bool); default is `False`  If true, the value must be specified explicitly (even if it has a `default`). |
\ No newline at end of file
+| `allow_empty` | [bool](/versions/8.3.1/rules/lib/core/bool); default is `True`  True if the attribute can be empty. |
+| `configurable` | [bool](/versions/8.3.1/rules/lib/core/bool); or unbound; default is `unbound`  This argument can only be specified for an attribute of a symbolic macro. If `configurable` is explicitly set to `False`, the symbolic macro attribute is non-configurable - in other words, it cannot take a `select()` value. If the `configurable` is either unbound or explicitly set to `True`, the attribute is configurable and can take a `select()` value. For an attribute of a rule or aspect, `configurable` must be left unbound. Most Starlark rule attributes are always configurable, with the exception of `attr.output()`, `attr.output_list()`, and `attr.license()` rule attributes, which are always non-configurable. |
+| `default` | [dict](/versions/8.3.1/rules/lib/core/dict); default is `{}`  A default value to use if no value for this attribute is given when instantiating the rule. |
+| `doc` | [string](/versions/8.3.1/rules/lib/core/string); or `None`; default is `None`  A description of the attribute that can be extracted by documentation generating tools. |
+| `mandatory` | [bool](/versions/8.3.1/rules/lib/core/bool); default is `False`  If true, the value must be specified explicitly (even if it has a `default`). |
\ No newline at end of file
diff --git a/versions/8.3.1/rules/lib/toplevel/cc_common.mdx b/versions/8.3.1/rules/lib/toplevel/cc_common.mdx
index cfe4e09f..56964788 100644
--- a/versions/8.3.1/rules/lib/toplevel/cc_common.mdx
+++ b/versions/8.3.1/rules/lib/toplevel/cc_common.mdx
@@ -42,8 +42,8 @@ Returns True if given action\_config is enabled in the feature configuration.
 
 | Parameter | Description |
 | --- | --- |
-| `feature_configuration` | [FeatureConfiguration](../builtins/FeatureConfiguration); required  Feature configuration to be queried. |
-| `action_name` | [string](../core/string); required  Name of the action\_config. |
+| `feature_configuration` | [FeatureConfiguration](/versions/8.3.1/rules/lib/builtins/FeatureConfiguration); required  Feature configuration to be queried. |
+| `action_name` | [string](/versions/8.3.1/rules/lib/core/string); required  Name of the action\_config. |
 
 ## CcToolchainInfo
 
@@ -65,29 +65,29 @@ Should be used for C++ compilation. Returns tuple of (`CompilationContext`, `CcC
 
 | Parameter | Description |
 | --- | --- |
-| `actions` | [actions](../builtins/actions); required  `actions` object. |
-| `feature_configuration` | [FeatureConfiguration](../builtins/FeatureConfiguration); required  `feature_configuration` to be queried. |
+| `actions` | [actions](/versions/8.3.1/rules/lib/builtins/actions); required  `actions` object. |
+| `feature_configuration` | [FeatureConfiguration](/versions/8.3.1/rules/lib/builtins/FeatureConfiguration); required  `feature_configuration` to be queried. |
 | `cc_toolchain` | Info; required  `CcToolchainInfo` provider to be used. |
-| `srcs` | [sequence](../core/list); default is `[]`  The list of source files to be compiled. |
-| `public_hdrs` | [sequence](../core/list); default is `[]`  List of headers needed for compilation of srcs and may be included by dependent rules transitively. |
-| `private_hdrs` | [sequence](../core/list); default is `[]`  List of headers needed for compilation of srcs and NOT to be included by dependent rules. |
-| `includes` | [sequence](../core/list); or [depset](../builtins/depset); default is `[]`  Search paths for header files referenced both by angle bracket and quotes. Usually passed with -I. Propagated to dependents transitively. |
-| `quote_includes` | [sequence](../core/list); default is `[]`  Search paths for header files referenced by quotes, e.g. #include "foo/bar/header.h". They can be either relative to the exec root or absolute. Usually passed with -iquote. Propagated to dependents transitively. |
-| `system_includes` | [sequence](../core/list); default is `[]`  Search paths for header files referenced by angle brackets, e.g. #include <foo/bar/header.h>. They can be either relative to the exec root or absolute. Usually passed with -isystem. Propagated to dependents transitively. |
-| `framework_includes` | [sequence](../core/list); default is `[]`  Search paths for header files from Apple frameworks. They can be either relative to the exec root or absolute. Usually passed with -F. Propagated to dependents transitively. |
-| `defines` | [sequence](../core/list); default is `[]`  Set of defines needed to compile this target. Each define is a string. Propagated to dependents transitively. |
-| `local_defines` | [sequence](../core/list); default is `[]`  Set of defines needed to compile this target. Each define is a string. Not propagated to dependents transitively. |
-| `include_prefix` | [string](../core/string); default is `''`  The prefix to add to the paths of the headers of this rule. When set, the headers in the hdrs attribute of this rule are accessible at is the value of this attribute prepended to their repository-relative path. The prefix in the strip\_include\_prefix attribute is removed before this prefix is added. |
-| `strip_include_prefix` | [string](../core/string); default is `''`  The prefix to strip from the paths of the headers of this rule. When set, the headers in the hdrs attribute of this rule are accessible at their path with this prefix cut off. If it's a relative path, it's taken as a package-relative one. If it's an absolute one, it's understood as a repository-relative path. The prefix in the include\_prefix attribute is added after this prefix is stripped. |
-| `user_compile_flags` | [sequence](../core/list); default is `[]`  Additional list of compilation options. |
-| `conly_flags` | [sequence](../core/list); default is `[]`  Additional list of compilation options for C compiles. |
-| `cxx_flags` | [sequence](../core/list); default is `[]`  Additional list of compilation options for C++ compiles. |
-| `compilation_contexts` | [sequence](../core/list); default is `[]`  Headers from dependencies used for compilation. |
-| `name` | [string](../core/string); required  This is used for naming the output artifacts of actions created by this method. See also the `main\_output` arg. |
-| `disallow_pic_outputs` | [bool](../core/bool); default is `False`  Whether PIC outputs should be created. |
-| `disallow_nopic_outputs` | [bool](../core/bool); default is `False`  Whether NOPIC outputs should be created. |
-| `additional_inputs` | [sequence](../core/list); default is `[]`  List of additional files needed for compilation of srcs |
-| `module_interfaces` | [sequence](../core/list); default is `unbound`  The list of module interfaces source files to be compiled. Note: this is an experimental feature, only enabled with --experimental\_cpp\_modules |
+| `srcs` | [sequence](/versions/8.3.1/rules/lib/core/list); default is `[]`  The list of source files to be compiled. |
+| `public_hdrs` | [sequence](/versions/8.3.1/rules/lib/core/list); default is `[]`  List of headers needed for compilation of srcs and may be included by dependent rules transitively. |
+| `private_hdrs` | [sequence](/versions/8.3.1/rules/lib/core/list); default is `[]`  List of headers needed for compilation of srcs and NOT to be included by dependent rules. |
+| `includes` | [sequence](/versions/8.3.1/rules/lib/core/list); or [depset](/versions/8.3.1/rules/lib/builtins/depset); default is `[]`  Search paths for header files referenced both by angle bracket and quotes. Usually passed with -I. Propagated to dependents transitively. |
+| `quote_includes` | [sequence](/versions/8.3.1/rules/lib/core/list); default is `[]`  Search paths for header files referenced by quotes, e.g. #include "foo/bar/header.h". They can be either relative to the exec root or absolute. Usually passed with -iquote. Propagated to dependents transitively. |
+| `system_includes` | [sequence](/versions/8.3.1/rules/lib/core/list); default is `[]`  Search paths for header files referenced by angle brackets, e.g. #include <foo/bar/header.h>. They can be either relative to the exec root or absolute. Usually passed with -isystem. Propagated to dependents transitively. |
+| `framework_includes` | [sequence](/versions/8.3.1/rules/lib/core/list); default is `[]`  Search paths for header files from Apple frameworks. They can be either relative to the exec root or absolute. Usually passed with -F. Propagated to dependents transitively. |
+| `defines` | [sequence](/versions/8.3.1/rules/lib/core/list); default is `[]`  Set of defines needed to compile this target. Each define is a string. Propagated to dependents transitively. |
+| `local_defines` | [sequence](/versions/8.3.1/rules/lib/core/list); default is `[]`  Set of defines needed to compile this target. Each define is a string. Not propagated to dependents transitively. |
+| `include_prefix` | [string](/versions/8.3.1/rules/lib/core/string); default is `''`  The prefix to add to the paths of the headers of this rule. When set, the headers in the hdrs attribute of this rule are accessible at is the value of this attribute prepended to their repository-relative path. The prefix in the strip\_include\_prefix attribute is removed before this prefix is added. |
+| `strip_include_prefix` | [string](/versions/8.3.1/rules/lib/core/string); default is `''`  The prefix to strip from the paths of the headers of this rule. When set, the headers in the hdrs attribute of this rule are accessible at their path with this prefix cut off. If it's a relative path, it's taken as a package-relative one. If it's an absolute one, it's understood as a repository-relative path. The prefix in the include\_prefix attribute is added after this prefix is stripped. |
+| `user_compile_flags` | [sequence](/versions/8.3.1/rules/lib/core/list); default is `[]`  Additional list of compilation options. |
+| `conly_flags` | [sequence](/versions/8.3.1/rules/lib/core/list); default is `[]`  Additional list of compilation options for C compiles. |
+| `cxx_flags` | [sequence](/versions/8.3.1/rules/lib/core/list); default is `[]`  Additional list of compilation options for C++ compiles. |
+| `compilation_contexts` | [sequence](/versions/8.3.1/rules/lib/core/list); default is `[]`  Headers from dependencies used for compilation. |
+| `name` | [string](/versions/8.3.1/rules/lib/core/string); required  This is used for naming the output artifacts of actions created by this method. See also the `main\_output` arg. |
+| `disallow_pic_outputs` | [bool](/versions/8.3.1/rules/lib/core/bool); default is `False`  Whether PIC outputs should be created. |
+| `disallow_nopic_outputs` | [bool](/versions/8.3.1/rules/lib/core/bool); default is `False`  Whether NOPIC outputs should be created. |
+| `additional_inputs` | [sequence](/versions/8.3.1/rules/lib/core/list); default is `[]`  List of additional files needed for compilation of srcs |
+| `module_interfaces` | [sequence](/versions/8.3.1/rules/lib/core/list); default is `unbound`  The list of module interfaces source files to be compiled. Note: this is an experimental feature, only enabled with --experimental\_cpp\_modules |
 
 ## configure\_features
 
@@ -101,11 +101,11 @@ Creates a feature\_configuration instance. Requires the cpp configuration fragme
 
 | Parameter | Description |
 | --- | --- |
-| `ctx` | [ctx](../builtins/ctx); or `None`; default is `None`  The rule context. |
+| `ctx` | [ctx](/versions/8.3.1/rules/lib/builtins/ctx); or `None`; default is `None`  The rule context. |
 | `cc_toolchain` | Info; required  cc\_toolchain for which we configure features. |
-| `language` | [string](../core/string); or `None`; default is `None`  The language to configure for: either c++ or objc (default c++) |
-| `requested_features` | [sequence](../core/list); default is `[]`  List of features to be enabled. |
-| `unsupported_features` | [sequence](../core/list); default is `[]`  List of features that are unsupported by the current rule. |
+| `language` | [string](/versions/8.3.1/rules/lib/core/string); or `None`; default is `None`  The language to configure for: either c++ or objc (default c++) |
+| `requested_features` | [sequence](/versions/8.3.1/rules/lib/core/list); default is `[]`  List of features to be enabled. |
+| `unsupported_features` | [sequence](/versions/8.3.1/rules/lib/core/list); default is `[]`  List of features that are unsupported by the current rule. |
 
 ## create\_cc\_toolchain\_config\_info
 
@@ -119,22 +119,22 @@ Creates a `CcToolchainConfigInfo` provider
 
 | Parameter | Description |
 | --- | --- |
-| `ctx` | [ctx](../builtins/ctx); required  The rule context. |
-| `features` | [sequence](../core/list); default is `[]`  Contains all flag specifications for one feature. Arguments:  `name`: The feature's name. It is possible to introduce a feature without a change to Bazel by adding a 'feature' section to the toolchain and adding the corresponding string as feature in the `BUILD` file.  `enabled`: If 'True', this feature is enabled unless a rule type explicitly marks it as unsupported.  `flag_sets`: A FlagSet list. If the given feature is enabled, the flag sets will be applied for the actions are specified for.  `env_sets`: an EnvSet list. If the given feature is enabled, the env sets will be applied for the actions they are specified for.  `requires`: A list of feature sets defining when this feature is supported by the toolchain. The feature is supported if any of the feature sets fully apply, that is, when all features of a feature set are enabled. If `requires` is omitted, the feature is supported independently of which other features are enabled. Use this for example to filter flags depending on the build mode enabled (opt / fastbuild / dbg).  `implies`: A string list of features or action configs that are automatically enabled when this feature is enabled. If any of the implied features or action configs cannot be enabled, this feature will (silently) not be enabled either.  `provides`: A list of names this feature conflicts with. A feature cannot be enabled if:- `provides` contains the name of a different feature or action config that we want to enable.- `provides` contains the same value as a 'provides' in a different feature or action config that we want to enable. Use this in order to ensure that incompatible features cannot be accidentally activated at the same time, leading to hard to diagnose compiler errors. |
-| `action_configs` | [sequence](../core/list); default is `[]`  An action config corresponds to a Bazel action, and allows selection of a tool based on activated features. Action config activation occurs by the same semantics as features: a feature can 'require' or 'imply' an action config in the same way that it would another feature. Arguments:  `action_name`: The name of the Bazel action that this config applies to, e.g. 'c-compile' or 'c-module-compile'.  `enabled`: If 'True', this action is enabled unless a rule type explicitly marks it as unsupported.  `tools`: The tool applied to the action will be the first tool with a feature set that matches the feature configuration. An error will be thrown if no tool matches a provided feature configuration - for that reason, it's a good idea to provide a default tool with an empty feature set.  `flag_sets`: If the given action config is enabled, the flag sets will be applied to the corresponding action.  `implies`: A list of features or action configs that are automatically enabled when this action config is enabled. If any of the implied features or action configs cannot be enabled, this action config will (silently) not be enabled either. |
-| `artifact_name_patterns` | [sequence](../core/list); default is `[]`  The name for an artifact of a given category of input or output artifacts to an action. Arguments:  `category_name`: The category of artifacts that this selection applies to. This field is compared against a list of categories defined in Bazel. Example categories include "linked\_output" or the artifact for this selection. Together with the extension it is used to create an artifact name based on the target name.  `extension`: The extension for creating the artifact for this selection. Together with the prefix it is used to create an artifact name based on the target name. |
-| `cxx_builtin_include_directories` | [sequence](../core/list); default is `[]`  Built-in include directories for C++ compilation. These should be the exact paths used by the compiler, and are generally relative to the exec root.  The paths used by the compiler can be determined by 'gcc -E -xc++ - -v'.  We currently use the C++ paths also for C compilation, which is safe as long as there are no name clashes between C++ and C header files.  Relative paths are resolved relative to the configuration file directory.  If the compiler has --sysroot support, then these paths should use %sysroot% rather than the include path, and specify the sysroot attribute in order to give blaze the information necessary to make the correct replacements. |
-| `toolchain_identifier` | [string](../core/string); required  The unique identifier of the toolchain within the crosstool release. It must be possible to use this as a directory name in a path.  It has to match the following regex: [a-zA-Z\_][\.\- \w]\* |
-| `host_system_name` | [string](../core/string); or `None`; default is `None`  Ignored. |
-| `target_system_name` | [string](../core/string); or `None`; default is `None`  Deprecated. The GNU System Name. The string is exposed to CcToolchainInfo.target\_gnu\_system\_name. |
-| `target_cpu` | [string](../core/string); or `None`; default is `None`  Deprecated: Use cpu based constraints instead. If the string is "k8", `target\_cpu` will be omitted from the filename of raw FDO profile data. |
-| `target_libc` | [string](../core/string); or `None`; default is `None`  Deprecated: Use OS based constraints instead. The libc version string (e.g. "glibc-2.2.2"). If the string is "macosx", platform is assumed to be MacOS. Otherwise, Linux. The string is exposed to CcToolchainInfo.libc. |
-| `compiler` | [string](../core/string); required  The compiler string (e.g. "gcc"). The current toolchain's compiler is exposed to `@bazel\_tools//tools/cpp:compiler (compiler\_flag)` as a flag value. Targets that require compiler-specific flags can use the config\_settings in https://github.com/bazelbuild/rules\_cc/blob/main/cc/compiler/BUILD in select() statements or create custom config\_setting if the existing settings don't suffice. |
-| `abi_version` | [string](../core/string); or `None`; default is `None`  The abi in use, which is a gcc version. E.g.: "gcc-3.4". The string is set to C++ toolchain variable ABI. |
-| `abi_libc_version` | [string](../core/string); or `None`; default is `None`  The glibc version used by the abi we're using. The string is set to C++ toolchain variable ABI\_LIBC\_VERSION. |
-| `tool_paths` | [sequence](../core/list); default is `[]`  Tool locations. Arguments:  `name`: Name of the tool.  `path`: Location of the tool; Can be absolute path (in case of non hermetic toolchain), or path relative to the cc\_toolchain's package. |
-| `make_variables` | [sequence](../core/list); default is `[]`  A make variable that is made accessible to rules. |
-| `builtin_sysroot` | [string](../core/string); or `None`; default is `None`  The built-in sysroot. If this attribute is not present, Bazel does not allow using a different sysroot, i.e. through the --grte\_top option. |
+| `ctx` | [ctx](/versions/8.3.1/rules/lib/builtins/ctx); required  The rule context. |
+| `features` | [sequence](/versions/8.3.1/rules/lib/core/list); default is `[]`  Contains all flag specifications for one feature. Arguments:  `name`: The feature's name. It is possible to introduce a feature without a change to Bazel by adding a 'feature' section to the toolchain and adding the corresponding string as feature in the `BUILD` file.  `enabled`: If 'True', this feature is enabled unless a rule type explicitly marks it as unsupported.  `flag_sets`: A FlagSet list. If the given feature is enabled, the flag sets will be applied for the actions are specified for.  `env_sets`: an EnvSet list. If the given feature is enabled, the env sets will be applied for the actions they are specified for.  `requires`: A list of feature sets defining when this feature is supported by the toolchain. The feature is supported if any of the feature sets fully apply, that is, when all features of a feature set are enabled. If `requires` is omitted, the feature is supported independently of which other features are enabled. Use this for example to filter flags depending on the build mode enabled (opt / fastbuild / dbg).  `implies`: A string list of features or action configs that are automatically enabled when this feature is enabled. If any of the implied features or action configs cannot be enabled, this feature will (silently) not be enabled either.  `provides`: A list of names this feature conflicts with. A feature cannot be enabled if:- `provides` contains the name of a different feature or action config that we want to enable.- `provides` contains the same value as a 'provides' in a different feature or action config that we want to enable. Use this in order to ensure that incompatible features cannot be accidentally activated at the same time, leading to hard to diagnose compiler errors. |
+| `action_configs` | [sequence](/versions/8.3.1/rules/lib/core/list); default is `[]`  An action config corresponds to a Bazel action, and allows selection of a tool based on activated features. Action config activation occurs by the same semantics as features: a feature can 'require' or 'imply' an action config in the same way that it would another feature. Arguments:  `action_name`: The name of the Bazel action that this config applies to, e.g. 'c-compile' or 'c-module-compile'.  `enabled`: If 'True', this action is enabled unless a rule type explicitly marks it as unsupported.  `tools`: The tool applied to the action will be the first tool with a feature set that matches the feature configuration. An error will be thrown if no tool matches a provided feature configuration - for that reason, it's a good idea to provide a default tool with an empty feature set.  `flag_sets`: If the given action config is enabled, the flag sets will be applied to the corresponding action.  `implies`: A list of features or action configs that are automatically enabled when this action config is enabled. If any of the implied features or action configs cannot be enabled, this action config will (silently) not be enabled either. |
+| `artifact_name_patterns` | [sequence](/versions/8.3.1/rules/lib/core/list); default is `[]`  The name for an artifact of a given category of input or output artifacts to an action. Arguments:  `category_name`: The category of artifacts that this selection applies to. This field is compared against a list of categories defined in Bazel. Example categories include "linked\_output" or the artifact for this selection. Together with the extension it is used to create an artifact name based on the target name.  `extension`: The extension for creating the artifact for this selection. Together with the prefix it is used to create an artifact name based on the target name. |
+| `cxx_builtin_include_directories` | [sequence](/versions/8.3.1/rules/lib/core/list); default is `[]`  Built-in include directories for C++ compilation. These should be the exact paths used by the compiler, and are generally relative to the exec root.  The paths used by the compiler can be determined by 'gcc -E -xc++ - -v'.  We currently use the C++ paths also for C compilation, which is safe as long as there are no name clashes between C++ and C header files.  Relative paths are resolved relative to the configuration file directory.  If the compiler has --sysroot support, then these paths should use %sysroot% rather than the include path, and specify the sysroot attribute in order to give blaze the information necessary to make the correct replacements. |
+| `toolchain_identifier` | [string](/versions/8.3.1/rules/lib/core/string); required  The unique identifier of the toolchain within the crosstool release. It must be possible to use this as a directory name in a path.  It has to match the following regex: [a-zA-Z\_][\.\- \w]\* |
+| `host_system_name` | [string](/versions/8.3.1/rules/lib/core/string); or `None`; default is `None`  Ignored. |
+| `target_system_name` | [string](/versions/8.3.1/rules/lib/core/string); or `None`; default is `None`  Deprecated. The GNU System Name. The string is exposed to CcToolchainInfo.target\_gnu\_system\_name. |
+| `target_cpu` | [string](/versions/8.3.1/rules/lib/core/string); or `None`; default is `None`  Deprecated: Use cpu based constraints instead. If the string is "k8", `target\_cpu` will be omitted from the filename of raw FDO profile data. |
+| `target_libc` | [string](/versions/8.3.1/rules/lib/core/string); or `None`; default is `None`  Deprecated: Use OS based constraints instead. The libc version string (e.g. "glibc-2.2.2"). If the string is "macosx", platform is assumed to be MacOS. Otherwise, Linux. The string is exposed to CcToolchainInfo.libc. |
+| `compiler` | [string](/versions/8.3.1/rules/lib/core/string); required  The compiler string (e.g. "gcc"). The current toolchain's compiler is exposed to `@bazel\_tools//tools/cpp:compiler (compiler\_flag)` as a flag value. Targets that require compiler-specific flags can use the config\_settings in https://github.com/bazelbuild/rules\_cc/blob/main/cc/compiler/BUILD in select() statements or create custom config\_setting if the existing settings don't suffice. |
+| `abi_version` | [string](/versions/8.3.1/rules/lib/core/string); or `None`; default is `None`  The abi in use, which is a gcc version. E.g.: "gcc-3.4". The string is set to C++ toolchain variable ABI. |
+| `abi_libc_version` | [string](/versions/8.3.1/rules/lib/core/string); or `None`; default is `None`  The glibc version used by the abi we're using. The string is set to C++ toolchain variable ABI\_LIBC\_VERSION. |
+| `tool_paths` | [sequence](/versions/8.3.1/rules/lib/core/list); default is `[]`  Tool locations. Arguments:  `name`: Name of the tool.  `path`: Location of the tool; Can be absolute path (in case of non hermetic toolchain), or path relative to the cc\_toolchain's package. |
+| `make_variables` | [sequence](/versions/8.3.1/rules/lib/core/list); default is `[]`  A make variable that is made accessible to rules. |
+| `builtin_sysroot` | [string](/versions/8.3.1/rules/lib/core/string); or `None`; default is `None`  The built-in sysroot. If this attribute is not present, Bazel does not allow using a different sysroot, i.e. through the --grte\_top option. |
 
 ## create\_compilation\_context
 
@@ -168,8 +168,8 @@ Create compilation outputs object.
 
 | Parameter | Description |
 | --- | --- |
-| `objects` | [depset](../builtins/depset); or `None`; default is `None`  List of object files. |
-| `pic_objects` | [depset](../builtins/depset); or `None`; default is `None`  List of pic object files. |
+| `objects` | [depset](/versions/8.3.1/rules/lib/builtins/depset); or `None`; default is `None`  List of object files. |
+| `pic_objects` | [depset](/versions/8.3.1/rules/lib/builtins/depset); or `None`; default is `None`  List of pic object files. |
 
 ## create\_compile\_variables
 
@@ -184,21 +184,21 @@ Returns variables used for compilation actions.
 | Parameter | Description |
 | --- | --- |
 | `cc_toolchain` | Info; required  cc\_toolchain for which we are creating build variables. |
-| `feature_configuration` | [FeatureConfiguration](../builtins/FeatureConfiguration); required  Feature configuration to be queried. |
+| `feature_configuration` | [FeatureConfiguration](/versions/8.3.1/rules/lib/builtins/FeatureConfiguration); required  Feature configuration to be queried. |
 | `source_file` | default is `None`  Optional source file for the compilation. Please prefer passing source\_file here over appending it to the end of the command line generated from cc\_common.get\_memory\_inefficient\_command\_line, as then it's in the power of the toolchain author to properly specify and position compiler flags. |
 | `output_file` | default is `None`  Optional output file of the compilation. Please prefer passing output\_file here over appending it to the end of the command line generated from cc\_common.get\_memory\_inefficient\_command\_line, as then it's in the power of the toolchain author to properly specify and position compiler flags. |
-| `user_compile_flags` | [sequence](../core/list) of [string](../core/string)s; or `None`; default is `None`  List of additional compilation flags (copts). |
-| `include_directories` | [depset](../builtins/depset); or `None`; default is `None`  Depset of include directories. |
-| `quote_include_directories` | [depset](../builtins/depset); or `None`; default is `None`  Depset of quote include directories. |
-| `system_include_directories` | [depset](../builtins/depset); or `None`; default is `None`  Depset of system include directories. |
-| `framework_include_directories` | [depset](../builtins/depset); or `None`; default is `None`  Depset of framework include directories. |
-| `preprocessor_defines` | [depset](../builtins/depset); or `None`; default is `None`  Depset of preprocessor defines. |
-| `thinlto_index` | [string](../core/string); or `None`; default is `None`  LTO index file path. |
-| `thinlto_input_bitcode_file` | [string](../core/string); or `None`; default is `None`  Bitcode file that is input to LTO backend. |
-| `thinlto_output_object_file` | [string](../core/string); or `None`; default is `None`  Object file that is output by LTO backend. |
-| `use_pic` | [bool](../core/bool); default is `False`  When true the compilation will generate position independent code. |
-| `add_legacy_cxx_options` | [bool](../core/bool); default is `False`  Unused. |
-| `variables_extension` | [dict](../core/dict); default is `unbound`  A dictionary of additional variables used by compile actions. |
+| `user_compile_flags` | [sequence](/versions/8.3.1/rules/lib/core/list) of [string](/versions/8.3.1/rules/lib/core/string)s; or `None`; default is `None`  List of additional compilation flags (copts). |
+| `include_directories` | [depset](/versions/8.3.1/rules/lib/builtins/depset); or `None`; default is `None`  Depset of include directories. |
+| `quote_include_directories` | [depset](/versions/8.3.1/rules/lib/builtins/depset); or `None`; default is `None`  Depset of quote include directories. |
+| `system_include_directories` | [depset](/versions/8.3.1/rules/lib/builtins/depset); or `None`; default is `None`  Depset of system include directories. |
+| `framework_include_directories` | [depset](/versions/8.3.1/rules/lib/builtins/depset); or `None`; default is `None`  Depset of framework include directories. |
+| `preprocessor_defines` | [depset](/versions/8.3.1/rules/lib/builtins/depset); or `None`; default is `None`  Depset of preprocessor defines. |
+| `thinlto_index` | [string](/versions/8.3.1/rules/lib/core/string); or `None`; default is `None`  LTO index file path. |
+| `thinlto_input_bitcode_file` | [string](/versions/8.3.1/rules/lib/core/string); or `None`; default is `None`  Bitcode file that is input to LTO backend. |
+| `thinlto_output_object_file` | [string](/versions/8.3.1/rules/lib/core/string); or `None`; default is `None`  Object file that is output by LTO backend. |
+| `use_pic` | [bool](/versions/8.3.1/rules/lib/core/bool); default is `False`  When true the compilation will generate position independent code. |
+| `add_legacy_cxx_options` | [bool](/versions/8.3.1/rules/lib/core/bool); default is `False`  Unused. |
+| `variables_extension` | [dict](/versions/8.3.1/rules/lib/core/dict); default is `unbound`  A dictionary of additional variables used by compile actions. |
 
 ## create\_library\_to\_link
 
@@ -215,15 +215,15 @@ Creates `LibraryToLink`
 | `actions` | required  `actions` object. |
 | `feature_configuration` | default is `None`  `feature_configuration` to be queried. |
 | `cc_toolchain` | default is `None`  `CcToolchainInfo` provider to be used. |
-| `static_library` | [File](../builtins/File); or `None`; default is `None`  `File` of static library to be linked. |
-| `pic_static_library` | [File](../builtins/File); or `None`; default is `None`  `File` of pic static library to be linked. |
-| `dynamic_library` | [File](../builtins/File); or `None`; default is `None`  `File` of dynamic library to be linked. Always used for runtime and used for linking if `interface_library` is not passed. |
-| `interface_library` | [File](../builtins/File); or `None`; default is `None`  `File` of interface library to be linked. |
-| `pic_objects` | [sequence](../core/list) of [File](../builtins/File)s; default is `unbound`  Experimental, do not use |
-| `objects` | [sequence](../core/list) of [File](../builtins/File)s; default is `unbound`  Experimental, do not use |
-| `alwayslink` | [bool](../core/bool); default is `False`  Whether to link the static library/objects in the --whole\_archive block. |
-| `dynamic_library_symlink_path` | [string](../core/string); default is `''`  Override the default path of the dynamic library link in the solib directory. Empty string to use the default. |
-| `interface_library_symlink_path` | [string](../core/string); default is `''`  Override the default path of the interface library link in the solib directory. Empty string to use the default. |
+| `static_library` | [File](/versions/8.3.1/rules/lib/builtins/File); or `None`; default is `None`  `File` of static library to be linked. |
+| `pic_static_library` | [File](/versions/8.3.1/rules/lib/builtins/File); or `None`; default is `None`  `File` of pic static library to be linked. |
+| `dynamic_library` | [File](/versions/8.3.1/rules/lib/builtins/File); or `None`; default is `None`  `File` of dynamic library to be linked. Always used for runtime and used for linking if `interface_library` is not passed. |
+| `interface_library` | [File](/versions/8.3.1/rules/lib/builtins/File); or `None`; default is `None`  `File` of interface library to be linked. |
+| `pic_objects` | [sequence](/versions/8.3.1/rules/lib/core/list) of [File](/versions/8.3.1/rules/lib/builtins/File)s; default is `unbound`  Experimental, do not use |
+| `objects` | [sequence](/versions/8.3.1/rules/lib/core/list) of [File](/versions/8.3.1/rules/lib/builtins/File)s; default is `unbound`  Experimental, do not use |
+| `alwayslink` | [bool](/versions/8.3.1/rules/lib/core/bool); default is `False`  Whether to link the static library/objects in the --whole\_archive block. |
+| `dynamic_library_symlink_path` | [string](/versions/8.3.1/rules/lib/core/string); default is `''`  Override the default path of the dynamic library link in the solib directory. Empty string to use the default. |
+| `interface_library_symlink_path` | [string](/versions/8.3.1/rules/lib/core/string); default is `''`  Override the default path of the interface library link in the solib directory. Empty string to use the default. |
 
 ## create\_link\_variables
 
@@ -238,17 +238,17 @@ Returns link variables used for linking actions.
 | Parameter | Description |
 | --- | --- |
 | `cc_toolchain` | Info; required  cc\_toolchain for which we are creating build variables. |
-| `feature_configuration` | [FeatureConfiguration](../builtins/FeatureConfiguration); required  Feature configuration to be queried. |
-| `library_search_directories` | [depset](../builtins/depset); default is `[]`  Depset of directories where linker will look for libraries at link time. |
-| `runtime_library_search_directories` | [depset](../builtins/depset); default is `[]`  Depset of directories where loader will look for libraries at runtime. |
-| `user_link_flags` | [sequence](../core/list); default is `[]`  List of additional link flags (linkopts). |
+| `feature_configuration` | [FeatureConfiguration](/versions/8.3.1/rules/lib/builtins/FeatureConfiguration); required  Feature configuration to be queried. |
+| `library_search_directories` | [depset](/versions/8.3.1/rules/lib/builtins/depset); default is `[]`  Depset of directories where linker will look for libraries at link time. |
+| `runtime_library_search_directories` | [depset](/versions/8.3.1/rules/lib/builtins/depset); default is `[]`  Depset of directories where loader will look for libraries at runtime. |
+| `user_link_flags` | [sequence](/versions/8.3.1/rules/lib/core/list); default is `[]`  List of additional link flags (linkopts). |
 | `output_file` | default is `None`  Optional output file path. |
 | `param_file` | default is `None`  Optional param file path. |
-| `is_using_linker` | [bool](../core/bool); default is `True`  True when using linker, False when archiver. Caller is responsible for keeping this in sync with action name used (is\_using\_linker = True for linking executable or dynamic library, is\_using\_linker = False for archiving static library). |
-| `is_linking_dynamic_library` | [bool](../core/bool); default is `False`  True when creating dynamic library, False when executable or static library. Caller is responsible for keeping this in sync with action name used. This field will be removed once b/65151735 is fixed. |
-| `must_keep_debug` | [bool](../core/bool); default is `True`  When set to False, bazel will expose 'strip\_debug\_symbols' variable, which is usually used to use the linker to strip debug symbols from the output file. |
-| `use_test_only_flags` | [bool](../core/bool); default is `False`  When set to true, 'is\_cc\_test' variable will be set. |
-| `is_static_linking_mode` | [bool](../core/bool); default is `True`  Unused. |
+| `is_using_linker` | [bool](/versions/8.3.1/rules/lib/core/bool); default is `True`  True when using linker, False when archiver. Caller is responsible for keeping this in sync with action name used (is\_using\_linker = True for linking executable or dynamic library, is\_using\_linker = False for archiving static library). |
+| `is_linking_dynamic_library` | [bool](/versions/8.3.1/rules/lib/core/bool); default is `False`  True when creating dynamic library, False when executable or static library. Caller is responsible for keeping this in sync with action name used. This field will be removed once b/65151735 is fixed. |
+| `must_keep_debug` | [bool](/versions/8.3.1/rules/lib/core/bool); default is `True`  When set to False, bazel will expose 'strip\_debug\_symbols' variable, which is usually used to use the linker to strip debug symbols from the output file. |
+| `use_test_only_flags` | [bool](/versions/8.3.1/rules/lib/core/bool); default is `False`  When set to true, 'is\_cc\_test' variable will be set. |
+| `is_static_linking_mode` | [bool](/versions/8.3.1/rules/lib/core/bool); default is `True`  Unused. |
 
 ## create\_linker\_input
 
@@ -262,10 +262,10 @@ Creates a `LinkerInput`.
 
 | Parameter | Description |
 | --- | --- |
-| `owner` | [Label](../builtins/Label); required  The label of the target that produced all files used in this input. |
-| `libraries` | `None`; or [depset](../builtins/depset); default is `None`  List of `LibraryToLink`. |
-| `user_link_flags` | `None`; or [depset](../builtins/depset) of [string](../core/string)s; or [sequence](../core/list) of [string](../core/string)s; default is `None`  User link flags passed as strings. Accepts either [String], [[String]] or depset(String). The latter is discouraged as it's only kept for compatibility purposes, the depset is flattened. If you want to propagate user\_link\_flags via unflattened depsets() wrap them in a LinkerInput so that they are not flattened till the end. |
-| `additional_inputs` | `None`; or [depset](../builtins/depset); default is `None`  For additional inputs to the linking action, e.g.: linking scripts. |
+| `owner` | [Label](/versions/8.3.1/rules/lib/builtins/Label); required  The label of the target that produced all files used in this input. |
+| `libraries` | `None`; or [depset](/versions/8.3.1/rules/lib/builtins/depset); default is `None`  List of `LibraryToLink`. |
+| `user_link_flags` | `None`; or [depset](/versions/8.3.1/rules/lib/builtins/depset) of [string](/versions/8.3.1/rules/lib/core/string)s; or [sequence](/versions/8.3.1/rules/lib/core/list) of [string](/versions/8.3.1/rules/lib/core/string)s; default is `None`  User link flags passed as strings. Accepts either [String], [[String]] or depset(String). The latter is discouraged as it's only kept for compatibility purposes, the depset is flattened. If you want to propagate user\_link\_flags via unflattened depsets() wrap them in a LinkerInput so that they are not flattened till the end. |
+| `additional_inputs` | `None`; or [depset](/versions/8.3.1/rules/lib/builtins/depset); default is `None`  For additional inputs to the linking action, e.g.: linking scripts. |
 
 ## create\_linking\_context
 
@@ -279,10 +279,10 @@ Creates a `LinkingContext`.
 
 | Parameter | Description |
 | --- | --- |
-| `linker_inputs` | `None`; or [depset](../builtins/depset); default is `None`  Depset of `LinkerInput`. |
-| `libraries_to_link` | `None`; or [sequence](../core/list); default is `None`  **Deprecated**. This parameter is deprecated and will be removed soon. Please do not depend on it. It is *disabled* with `--incompatible_require_linker_input_cc_api`. Use this flag to verify your code is compatible with its imminent removal.  List of `LibraryToLink`. |
-| `user_link_flags` | `None`; or [sequence](../core/list); default is `None` |
-| `additional_inputs` | `None`; or [sequence](../core/list); default is `None` |
+| `linker_inputs` | `None`; or [depset](/versions/8.3.1/rules/lib/builtins/depset); default is `None`  Depset of `LinkerInput`. |
+| `libraries_to_link` | `None`; or [sequence](/versions/8.3.1/rules/lib/core/list); default is `None`  **Deprecated**. This parameter is deprecated and will be removed soon. Please do not depend on it. It is *disabled* with `--incompatible_require_linker_input_cc_api`. Use this flag to verify your code is compatible with its imminent removal.  List of `LibraryToLink`. |
+| `user_link_flags` | `None`; or [sequence](/versions/8.3.1/rules/lib/core/list); default is `None` |
+| `additional_inputs` | `None`; or [sequence](/versions/8.3.1/rules/lib/core/list); default is `None` |
 
 ## create\_linking\_context\_from\_compilation\_outputs
 
@@ -296,19 +296,19 @@ Should be used for creating library rules that can propagate information downstr
 
 | Parameter | Description |
 | --- | --- |
-| `actions` | [actions](../builtins/actions); required |
-| `name` | [string](../core/string); required  This is used for naming the output artifacts of actions created by this method. |
-| `feature_configuration` | [FeatureConfiguration](../builtins/FeatureConfiguration); required  `feature_configuration` to be queried. |
+| `actions` | [actions](/versions/8.3.1/rules/lib/builtins/actions); required |
+| `name` | [string](/versions/8.3.1/rules/lib/core/string); required  This is used for naming the output artifacts of actions created by this method. |
+| `feature_configuration` | [FeatureConfiguration](/versions/8.3.1/rules/lib/builtins/FeatureConfiguration); required  `feature_configuration` to be queried. |
 | `cc_toolchain` | Info; required  `CcToolchainInfo` provider to be used. |
-| `language` | [string](../core/string); default is `'c++'`  Only C++ supported for now. Do not use this parameter. |
-| `disallow_static_libraries` | [bool](../core/bool); default is `False`  Whether static libraries should be created. |
-| `disallow_dynamic_library` | [bool](../core/bool); default is `False`  Whether a dynamic library should be created. |
-| `compilation_outputs` | [CcCompilationOutputs](../builtins/CcCompilationOutputs); required  Compilation outputs containing object files to link. |
-| `linking_contexts` | [sequence](../core/list); default is `[]`  Libraries from dependencies. These libraries will be linked into the output artifact of the link() call, be it a binary or a library. |
-| `user_link_flags` | [sequence](../core/list); default is `[]`  Additional list of linking options. |
-| `alwayslink` | [bool](../core/bool); default is `False`  Whether this library should always be linked. |
-| `additional_inputs` | [sequence](../core/list); default is `[]`  For additional inputs to the linking action, e.g.: linking scripts. |
-| `variables_extension` | [dict](../core/dict); default is `unbound`  Additional variables to pass to the toolchain configuration when creating link command line. |
+| `language` | [string](/versions/8.3.1/rules/lib/core/string); default is `'c++'`  Only C++ supported for now. Do not use this parameter. |
+| `disallow_static_libraries` | [bool](/versions/8.3.1/rules/lib/core/bool); default is `False`  Whether static libraries should be created. |
+| `disallow_dynamic_library` | [bool](/versions/8.3.1/rules/lib/core/bool); default is `False`  Whether a dynamic library should be created. |
+| `compilation_outputs` | [CcCompilationOutputs](/versions/8.3.1/rules/lib/builtins/CcCompilationOutputs); required  Compilation outputs containing object files to link. |
+| `linking_contexts` | [sequence](/versions/8.3.1/rules/lib/core/list); default is `[]`  Libraries from dependencies. These libraries will be linked into the output artifact of the link() call, be it a binary or a library. |
+| `user_link_flags` | [sequence](/versions/8.3.1/rules/lib/core/list); default is `[]`  Additional list of linking options. |
+| `alwayslink` | [bool](/versions/8.3.1/rules/lib/core/bool); default is `False`  Whether this library should always be linked. |
+| `additional_inputs` | [sequence](/versions/8.3.1/rules/lib/core/list); default is `[]`  For additional inputs to the linking action, e.g.: linking scripts. |
+| `variables_extension` | [dict](/versions/8.3.1/rules/lib/core/dict); default is `unbound`  Additional variables to pass to the toolchain configuration when creating link command line. |
 
 ## create\_lto\_compilation\_context
 
@@ -322,7 +322,7 @@ Create LTO compilation context
 
 | Parameter | Description |
 | --- | --- |
-| `objects` | [dict](../core/dict); default is `{}`  map of full object to index object |
+| `objects` | [dict](/versions/8.3.1/rules/lib/core/dict); default is `{}`  map of full object to index object |
 
 ## do\_not\_use\_tools\_cpp\_compiler\_present
 
@@ -344,8 +344,8 @@ Returns environment variables to be set for given action.
 
 | Parameter | Description |
 | --- | --- |
-| `feature_configuration` | [FeatureConfiguration](../builtins/FeatureConfiguration); required  Feature configuration to be queried. |
-| `action_name` | [string](../core/string); required  Name of the action. Has to be one of the names in @bazel\_tools//tools/build\_defs/cc:action\_names.bzl (https://github.com/bazelbuild/bazel/blob/master/tools/build\_defs/cc/action\_names.bzl) |
+| `feature_configuration` | [FeatureConfiguration](/versions/8.3.1/rules/lib/builtins/FeatureConfiguration); required  Feature configuration to be queried. |
+| `action_name` | [string](/versions/8.3.1/rules/lib/core/string); required  Name of the action. Has to be one of the names in @bazel\_tools//tools/build\_defs/cc:action\_names.bzl (https://github.com/bazelbuild/bazel/blob/master/tools/build\_defs/cc/action\_names.bzl) |
 | `variables` | Variables; required  Build variables to be used for template expansion. |
 
 ## get\_execution\_requirements
@@ -360,8 +360,8 @@ Returns execution requirements for given action.
 
 | Parameter | Description |
 | --- | --- |
-| `feature_configuration` | [FeatureConfiguration](../builtins/FeatureConfiguration); required  Feature configuration to be queried. |
-| `action_name` | [string](../core/string); required  Name of the action. Has to be one of the names in @bazel\_tools//tools/build\_defs/cc:action\_names.bzl (https://github.com/bazelbuild/bazel/blob/master/tools/build\_defs/cc/action\_names.bzl) |
+| `feature_configuration` | [FeatureConfiguration](/versions/8.3.1/rules/lib/builtins/FeatureConfiguration); required  Feature configuration to be queried. |
+| `action_name` | [string](/versions/8.3.1/rules/lib/core/string); required  Name of the action. Has to be one of the names in @bazel\_tools//tools/build\_defs/cc:action\_names.bzl (https://github.com/bazelbuild/bazel/blob/master/tools/build\_defs/cc/action\_names.bzl) |
 
 ## get\_memory\_inefficient\_command\_line
 
@@ -375,8 +375,8 @@ Returns flattened command line flags for given action, using given variables for
 
 | Parameter | Description |
 | --- | --- |
-| `feature_configuration` | [FeatureConfiguration](../builtins/FeatureConfiguration); required  Feature configuration to be queried. |
-| `action_name` | [string](../core/string); required  Name of the action. Has to be one of the names in @bazel\_tools//tools/build\_defs/cc:action\_names.bzl (https://github.com/bazelbuild/bazel/blob/master/tools/build\_defs/cc/action\_names.bzl) |
+| `feature_configuration` | [FeatureConfiguration](/versions/8.3.1/rules/lib/builtins/FeatureConfiguration); required  Feature configuration to be queried. |
+| `action_name` | [string](/versions/8.3.1/rules/lib/core/string); required  Name of the action. Has to be one of the names in @bazel\_tools//tools/build\_defs/cc:action\_names.bzl (https://github.com/bazelbuild/bazel/blob/master/tools/build\_defs/cc/action\_names.bzl) |
 | `variables` | Variables; required  Build variables to be used for template expansions. |
 
 ## get\_tool\_for\_action
@@ -391,8 +391,8 @@ Returns tool path for given action.
 
 | Parameter | Description |
 | --- | --- |
-| `feature_configuration` | [FeatureConfiguration](../builtins/FeatureConfiguration); required  Feature configuration to be queried. |
-| `action_name` | [string](../core/string); required  Name of the action. Has to be one of the names in @bazel\_tools//tools/build\_defs/cc:action\_names.bzl (https://github.com/bazelbuild/bazel/blob/master/tools/build\_defs/cc/action\_names.bzl) |
+| `feature_configuration` | [FeatureConfiguration](/versions/8.3.1/rules/lib/builtins/FeatureConfiguration); required  Feature configuration to be queried. |
+| `action_name` | [string](/versions/8.3.1/rules/lib/core/string); required  Name of the action. Has to be one of the names in @bazel\_tools//tools/build\_defs/cc:action\_names.bzl (https://github.com/bazelbuild/bazel/blob/master/tools/build\_defs/cc/action\_names.bzl) |
 
 ## is\_enabled
 
@@ -406,8 +406,8 @@ Returns True if given feature is enabled in the feature configuration.
 
 | Parameter | Description |
 | --- | --- |
-| `feature_configuration` | [FeatureConfiguration](../builtins/FeatureConfiguration); required  Feature configuration to be queried. |
-| `feature_name` | [string](../core/string); required  Name of the feature. |
+| `feature_configuration` | [FeatureConfiguration](/versions/8.3.1/rules/lib/builtins/FeatureConfiguration); required  Feature configuration to be queried. |
+| `feature_name` | [string](/versions/8.3.1/rules/lib/core/string); required  Name of the feature. |
 
 ## link
 
@@ -421,20 +421,20 @@ Should be used for C++ transitive linking.
 
 | Parameter | Description |
 | --- | --- |
-| `actions` | [actions](../builtins/actions); required  `actions` object. |
-| `name` | [string](../core/string); required  This is used for naming the output artifacts of actions created by this method. |
-| `feature_configuration` | [FeatureConfiguration](../builtins/FeatureConfiguration); required  `feature_configuration` to be queried. |
+| `actions` | [actions](/versions/8.3.1/rules/lib/builtins/actions); required  `actions` object. |
+| `name` | [string](/versions/8.3.1/rules/lib/core/string); required  This is used for naming the output artifacts of actions created by this method. |
+| `feature_configuration` | [FeatureConfiguration](/versions/8.3.1/rules/lib/builtins/FeatureConfiguration); required  `feature_configuration` to be queried. |
 | `cc_toolchain` | Info; required  `CcToolchainInfo` provider to be used. |
-| `language` | [string](../core/string); default is `'c++'`  Only C++ supported for now. Do not use this parameter. |
-| `output_type` | [string](../core/string); default is `'executable'`  Can be either 'executable' or 'dynamic\_library'. |
-| `link_deps_statically` | [bool](../core/bool); default is `True`  True to link dependencies statically, False dynamically. |
-| `compilation_outputs` | [CcCompilationOutputs](../builtins/CcCompilationOutputs); or `None`; default is `None`  Compilation outputs containing object files to link. |
-| `linking_contexts` | [sequence](../core/list); default is `[]`  Linking contexts from dependencies to be linked into the linking context generated by this rule. |
-| `user_link_flags` | [sequence](../core/list); default is `[]`  Additional list of linker options. |
-| `stamp` | [int](../core/int); default is `0`  Whether to include build information in the linked executable, if output\_type is 'executable'. If 1, build information is always included. If 0 (the default build information is always excluded. If -1, uses the default behavior, which may be overridden by the --[no]stamp flag. This should be unset (or set to 0) when generating the executable output for test rules. |
-| `additional_inputs` | [sequence](../core/list); or [depset](../builtins/depset); default is `[]`  For additional inputs to the linking action, e.g.: linking scripts. |
-| `additional_outputs` | [sequence](../core/list); default is `[]`  For additional outputs to the linking action, e.g.: map files. |
-| `variables_extension` | [dict](../core/dict); default is `{}`  Additional variables to pass to the toolchain configuration when create link command line. |
+| `language` | [string](/versions/8.3.1/rules/lib/core/string); default is `'c++'`  Only C++ supported for now. Do not use this parameter. |
+| `output_type` | [string](/versions/8.3.1/rules/lib/core/string); default is `'executable'`  Can be either 'executable' or 'dynamic\_library'. |
+| `link_deps_statically` | [bool](/versions/8.3.1/rules/lib/core/bool); default is `True`  True to link dependencies statically, False dynamically. |
+| `compilation_outputs` | [CcCompilationOutputs](/versions/8.3.1/rules/lib/builtins/CcCompilationOutputs); or `None`; default is `None`  Compilation outputs containing object files to link. |
+| `linking_contexts` | [sequence](/versions/8.3.1/rules/lib/core/list); default is `[]`  Linking contexts from dependencies to be linked into the linking context generated by this rule. |
+| `user_link_flags` | [sequence](/versions/8.3.1/rules/lib/core/list); default is `[]`  Additional list of linker options. |
+| `stamp` | [int](/versions/8.3.1/rules/lib/core/int); default is `0`  Whether to include build information in the linked executable, if output\_type is 'executable'. If 1, build information is always included. If 0 (the default build information is always excluded. If -1, uses the default behavior, which may be overridden by the --[no]stamp flag. This should be unset (or set to 0) when generating the executable output for test rules. |
+| `additional_inputs` | [sequence](/versions/8.3.1/rules/lib/core/list); or [depset](/versions/8.3.1/rules/lib/builtins/depset); default is `[]`  For additional inputs to the linking action, e.g.: linking scripts. |
+| `additional_outputs` | [sequence](/versions/8.3.1/rules/lib/core/list); default is `[]`  For additional outputs to the linking action, e.g.: map files. |
+| `variables_extension` | [dict](/versions/8.3.1/rules/lib/core/dict); default is `{}`  Additional variables to pass to the toolchain configuration when create link command line. |
 
 ## merge\_compilation\_contexts
 
@@ -448,7 +448,7 @@ Merges multiple `CompilationContexts`s into one.
 
 | Parameter | Description |
 | --- | --- |
-| `compilation_contexts` | [sequence](../core/list); default is `[]`  List of `CompilationContexts`s to be merged. The headers of each context will be exported by the direct fields in the returned provider. |
+| `compilation_contexts` | [sequence](/versions/8.3.1/rules/lib/core/list); default is `[]`  List of `CompilationContexts`s to be merged. The headers of each context will be exported by the direct fields in the returned provider. |
 
 ## merge\_compilation\_outputs
 
@@ -462,4 +462,4 @@ Merge compilation outputs.
 
 | Parameter | Description |
 | --- | --- |
-| `compilation_outputs` | [sequence](../core/list); default is `[]` |
\ No newline at end of file
+| `compilation_outputs` | [sequence](/versions/8.3.1/rules/lib/core/list); default is `[]` |
\ No newline at end of file
diff --git a/versions/8.3.1/rules/lib/toplevel/config.mdx b/versions/8.3.1/rules/lib/toplevel/config.mdx
index 4b60c243..ccc7ea1d 100644
--- a/versions/8.3.1/rules/lib/toplevel/config.mdx
+++ b/versions/8.3.1/rules/lib/toplevel/config.mdx
@@ -36,7 +36,7 @@ A bool-typed build setting
 
 | Parameter | Description |
 | --- | --- |
-| `flag` | [bool](../core/bool); default is `False` |
+| `flag` | [bool](/versions/8.3.1/rules/lib/core/bool); default is `False` |
 
 ## exec
 
@@ -50,7 +50,7 @@ Creates an execution transition.
 
 | Parameter | Description |
 | --- | --- |
-| `exec_group` | [string](../core/string); or `None`; default is `None`  The name of the exec group whose execution platform this transition will use. If not provided, this exec transition will use the target's default execution platform. |
+| `exec_group` | [string](/versions/8.3.1/rules/lib/core/string); or `None`; default is `None`  The name of the exec group whose execution platform this transition will use. If not provided, this exec transition will use the target's default execution platform. |
 
 ## int
 
@@ -64,7 +64,7 @@ An integer-typed build setting
 
 | Parameter | Description |
 | --- | --- |
-| `flag` | [bool](../core/bool); default is `False`  Whether or not this build setting is callable on the command line. |
+| `flag` | [bool](/versions/8.3.1/rules/lib/core/bool); default is `False`  Whether or not this build setting is callable on the command line. |
 
 ## none
 
@@ -86,8 +86,8 @@ A string-typed build setting
 
 | Parameter | Description |
 | --- | --- |
-| `flag` | [bool](../core/bool); default is `False`  Whether or not this build setting is callable on the command line. |
-| `allow_multiple` | [bool](../core/bool); default is `False`  Deprecated, use a `string_list` setting with `repeatable = True` instead. If set, this flag is allowed to be set multiple times on the command line. The Value of the flag as accessed in transitions and build setting implementation function will be a list of strings. Insertion order and repeated values are both maintained. This list can be post-processed in the build setting implementation function if different behavior is desired. |
+| `flag` | [bool](/versions/8.3.1/rules/lib/core/bool); default is `False`  Whether or not this build setting is callable on the command line. |
+| `allow_multiple` | [bool](/versions/8.3.1/rules/lib/core/bool); default is `False`  Deprecated, use a `string_list` setting with `repeatable = True` instead. If set, this flag is allowed to be set multiple times on the command line. The Value of the flag as accessed in transitions and build setting implementation function will be a list of strings. Insertion order and repeated values are both maintained. This list can be post-processed in the build setting implementation function if different behavior is desired. |
 
 ## string\_list
 
@@ -101,8 +101,8 @@ A string list-typed build setting. On the command line pass a list using comma-s
 
 | Parameter | Description |
 | --- | --- |
-| `flag` | [bool](../core/bool); default is `False`  Whether or not this build setting is callable on the command line. |
-| `repeatable` | [bool](../core/bool); default is `False`  If set, instead of expecting a comma-separated value, this flag is allowed to be set multiple times on the command line with each individual value treated as a single string to add to the list value. Insertion order and repeated values are both maintained. This list can be post-processed in the build setting implementation function if different behavior is desired. |
+| `flag` | [bool](/versions/8.3.1/rules/lib/core/bool); default is `False`  Whether or not this build setting is callable on the command line. |
+| `repeatable` | [bool](/versions/8.3.1/rules/lib/core/bool); default is `False`  If set, instead of expecting a comma-separated value, this flag is allowed to be set multiple times on the command line with each individual value treated as a single string to add to the list value. Insertion order and repeated values are both maintained. This list can be post-processed in the build setting implementation function if different behavior is desired. |
 
 ## target
 
diff --git a/versions/8.3.1/rules/lib/toplevel/config_common.mdx b/versions/8.3.1/rules/lib/toplevel/config_common.mdx
index 9169b17a..bab25482 100644
--- a/versions/8.3.1/rules/lib/toplevel/config_common.mdx
+++ b/versions/8.3.1/rules/lib/toplevel/config_common.mdx
@@ -29,5 +29,5 @@ Declare a rule's dependency on a toolchain type.
 
 | Parameter | Description |
 | --- | --- |
-| `name` | [string](../core/string); or [Label](../builtins/Label); required  The toolchain type that is required. |
-| `mandatory` | [bool](../core/bool); default is `True`  Whether the toolchain type is mandatory or optional. |
\ No newline at end of file
+| `name` | [string](/versions/8.3.1/rules/lib/core/string); or [Label](/versions/8.3.1/rules/lib/builtins/Label); required  The toolchain type that is required. |
+| `mandatory` | [bool](/versions/8.3.1/rules/lib/core/bool); default is `True`  Whether the toolchain type is mandatory or optional. |
\ No newline at end of file
diff --git a/versions/8.3.1/rules/lib/toplevel/coverage_common.mdx b/versions/8.3.1/rules/lib/toplevel/coverage_common.mdx
index e93e1226..e2a78cf2 100644
--- a/versions/8.3.1/rules/lib/toplevel/coverage_common.mdx
+++ b/versions/8.3.1/rules/lib/toplevel/coverage_common.mdx
@@ -14,14 +14,14 @@ Helper functions to access coverage-related infrastructure.
 InstrumentedFilesInfo coverage_common.instrumented_files_info(ctx, *, source_attributes=[], dependency_attributes=[], extensions=None, metadata_files=[])
 ```
 
-Creates a new [InstrumentedFilesInfo](../providers/InstrumentedFilesInfo) instance. Use this provider to communicate coverage-related attributes of the current build rule.
+Creates a new [InstrumentedFilesInfo](/versions/8.3.1/rules/lib/providers/InstrumentedFilesInfo) instance. Use this provider to communicate coverage-related attributes of the current build rule.
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `ctx` | [ctx](../builtins/ctx); required  The rule context. |
-| `source_attributes` | [sequence](../core/list); default is `[]`  A list of attribute names which contain source files processed by this rule. |
-| `dependency_attributes` | [sequence](../core/list); default is `[]`  A list of attribute names which might provide runtime dependencies (either code dependencies or runfiles). |
-| `extensions` | [sequence](../core/list) of [string](../core/string)s; or `None`; default is `None`  File extensions used to filter files from source\_attributes. For example, 'js'. If not provided (or None), then all files from source\_attributes will be added to instrumented files, if an empty list is provided, then no files from source attributes will be added. |
-| `metadata_files` | [sequence](../core/list) of [File](../builtins/File)s; default is `[]`  Additional files required to generate coverage LCOV files after code execution. e.g. .gcno files for C++. |
\ No newline at end of file
+| `ctx` | [ctx](/versions/8.3.1/rules/lib/builtins/ctx); required  The rule context. |
+| `source_attributes` | [sequence](/versions/8.3.1/rules/lib/core/list); default is `[]`  A list of attribute names which contain source files processed by this rule. |
+| `dependency_attributes` | [sequence](/versions/8.3.1/rules/lib/core/list); default is `[]`  A list of attribute names which might provide runtime dependencies (either code dependencies or runfiles). |
+| `extensions` | [sequence](/versions/8.3.1/rules/lib/core/list) of [string](/versions/8.3.1/rules/lib/core/string)s; or `None`; default is `None`  File extensions used to filter files from source\_attributes. For example, 'js'. If not provided (or None), then all files from source\_attributes will be added to instrumented files, if an empty list is provided, then no files from source attributes will be added. |
+| `metadata_files` | [sequence](/versions/8.3.1/rules/lib/core/list) of [File](/versions/8.3.1/rules/lib/builtins/File)s; default is `[]`  Additional files required to generate coverage LCOV files after code execution. e.g. .gcno files for C++. |
\ No newline at end of file
diff --git a/versions/8.3.1/rules/lib/toplevel/java_common.mdx b/versions/8.3.1/rules/lib/toplevel/java_common.mdx
index 9b993e13..7767927a 100644
--- a/versions/8.3.1/rules/lib/toplevel/java_common.mdx
+++ b/versions/8.3.1/rules/lib/toplevel/java_common.mdx
@@ -35,33 +35,33 @@ Compiles Java source files/jars from the implementation of a Starlark rule and r
 
 | Parameter | Description |
 | --- | --- |
-| `ctx` | [ctx](../builtins/ctx); required  The rule context. |
-| `source_jars` | [sequence](../core/list) of [File](../builtins/File)s; default is `[]`  A list of the jars to be compiled. At least one of source\_jars or source\_files should be specified. |
-| `source_files` | [sequence](../core/list) of [File](../builtins/File)s; default is `[]`  A list of the Java source files to be compiled. At least one of source\_jars or source\_files should be specified. |
-| `output` | [File](../builtins/File); required |
-| `output_source_jar` | [File](../builtins/File); or `None`; default is `None`  The output source jar. Defaults to `{output\_jar}-src.jar` if unset. |
-| `javac_opts` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  A list of the desired javac options. |
-| `deps` | [sequence](../core/list) of [struct](../builtins/struct)s; default is `[]`  A list of dependencies. |
-| `runtime_deps` | [sequence](../core/list) of [struct](../builtins/struct)s; default is `[]`  A list of runtime dependencies. |
-| `exports` | [sequence](../core/list) of [struct](../builtins/struct)s; default is `[]`  A list of exports. |
-| `plugins` | [sequence](../core/list) of [struct](../builtins/struct)s; or [sequence](../core/list) of [struct](../builtins/struct)s; default is `[]`  A list of plugins. |
-| `exported_plugins` | [sequence](../core/list) of [struct](../builtins/struct)s; or [sequence](../core/list) of [struct](../builtins/struct)s; default is `[]`  A list of exported plugins. |
-| `native_libraries` | [sequence](../core/list) of [CcInfo](../providers/CcInfo)s; default is `[]`  CC native library dependencies that are needed for this library. |
-| `annotation_processor_additional_inputs` | [sequence](../core/list) of [File](../builtins/File)s; default is `[]`  A list of inputs that the Java compilation action will take in addition to the Java sources for annotation processing. |
-| `annotation_processor_additional_outputs` | [sequence](../core/list) of [File](../builtins/File)s; default is `[]`  A list of outputs that the Java compilation action will output in addition to the class jar from annotation processing. |
-| `strict_deps` | [string](../core/string); default is `'ERROR'`  A string that specifies how to handle strict deps. Possible values: 'OFF', 'ERROR', 'WARN' and 'DEFAULT'. For more details see [`--strict_java_deps flag`](/versions/8.3.1/docs/user-manual#flag--strict_java_deps). By default 'ERROR'. |
+| `ctx` | [ctx](/versions/8.3.1/rules/lib/builtins/ctx); required  The rule context. |
+| `source_jars` | [sequence](/versions/8.3.1/rules/lib/core/list) of [File](/versions/8.3.1/rules/lib/builtins/File)s; default is `[]`  A list of the jars to be compiled. At least one of source\_jars or source\_files should be specified. |
+| `source_files` | [sequence](/versions/8.3.1/rules/lib/core/list) of [File](/versions/8.3.1/rules/lib/builtins/File)s; default is `[]`  A list of the Java source files to be compiled. At least one of source\_jars or source\_files should be specified. |
+| `output` | [File](/versions/8.3.1/rules/lib/builtins/File); required |
+| `output_source_jar` | [File](/versions/8.3.1/rules/lib/builtins/File); or `None`; default is `None`  The output source jar. Defaults to `{output\_jar}-src.jar` if unset. |
+| `javac_opts` | [sequence](/versions/8.3.1/rules/lib/core/list) of [string](/versions/8.3.1/rules/lib/core/string)s; default is `[]`  A list of the desired javac options. |
+| `deps` | [sequence](/versions/8.3.1/rules/lib/core/list) of [struct](/versions/8.3.1/rules/lib/builtins/struct)s; default is `[]`  A list of dependencies. |
+| `runtime_deps` | [sequence](/versions/8.3.1/rules/lib/core/list) of [struct](/versions/8.3.1/rules/lib/builtins/struct)s; default is `[]`  A list of runtime dependencies. |
+| `exports` | [sequence](/versions/8.3.1/rules/lib/core/list) of [struct](/versions/8.3.1/rules/lib/builtins/struct)s; default is `[]`  A list of exports. |
+| `plugins` | [sequence](/versions/8.3.1/rules/lib/core/list) of [struct](/versions/8.3.1/rules/lib/builtins/struct)s; or [sequence](/versions/8.3.1/rules/lib/core/list) of [struct](/versions/8.3.1/rules/lib/builtins/struct)s; default is `[]`  A list of plugins. |
+| `exported_plugins` | [sequence](/versions/8.3.1/rules/lib/core/list) of [struct](/versions/8.3.1/rules/lib/builtins/struct)s; or [sequence](/versions/8.3.1/rules/lib/core/list) of [struct](/versions/8.3.1/rules/lib/builtins/struct)s; default is `[]`  A list of exported plugins. |
+| `native_libraries` | [sequence](/versions/8.3.1/rules/lib/core/list) of [CcInfo](/versions/8.3.1/rules/lib/providers/CcInfo)s; default is `[]`  CC native library dependencies that are needed for this library. |
+| `annotation_processor_additional_inputs` | [sequence](/versions/8.3.1/rules/lib/core/list) of [File](/versions/8.3.1/rules/lib/builtins/File)s; default is `[]`  A list of inputs that the Java compilation action will take in addition to the Java sources for annotation processing. |
+| `annotation_processor_additional_outputs` | [sequence](/versions/8.3.1/rules/lib/core/list) of [File](/versions/8.3.1/rules/lib/builtins/File)s; default is `[]`  A list of outputs that the Java compilation action will output in addition to the class jar from annotation processing. |
+| `strict_deps` | [string](/versions/8.3.1/rules/lib/core/string); default is `'ERROR'`  A string that specifies how to handle strict deps. Possible values: 'OFF', 'ERROR', 'WARN' and 'DEFAULT'. For more details see [`--strict_java_deps flag`](/versions/8.3.1/docs/user-manual#flag--strict_java_deps). By default 'ERROR'. |
 | `java_toolchain` | Info; required  A JavaToolchainInfo to be used for this compilation. Mandatory. |
 | `bootclasspath` | default is `None`  A BootClassPathInfo to be used for this compilation. If present, overrides the bootclasspath associated with the provided java\_toolchain. |
 | `host_javabase` | default is `None`  **Deprecated**. This parameter is deprecated and will be removed soon. Please do not depend on it. It is *disabled* with `--incompatible_java_common_parameters`. Use this flag to verify your code is compatible with its imminent removal.  Deprecated: You can drop this parameter (host\_javabase is provided with java\_toolchain) |
-| `sourcepath` | [sequence](../core/list) of [File](../builtins/File)s; default is `[]` |
-| `resources` | [sequence](../core/list) of [File](../builtins/File)s; default is `[]` |
-| `resource_jars` | [sequence](../core/list) of [File](../builtins/File)s; default is `[]` |
-| `classpath_resources` | [sequence](../core/list) of [File](../builtins/File)s; default is `[]` |
-| `neverlink` | [bool](../core/bool); default is `False` |
-| `enable_annotation_processing` | [bool](../core/bool); default is `True`  Disables annotation processing in this compilation, causing any annotation processors provided in plugins or in exported\_plugins of deps to be ignored. |
-| `enable_compile_jar_action` | [bool](../core/bool); default is `True`  Enables header compilation or ijar creation. If set to False, it forces use of the full class jar in the compilation classpaths of any dependants. Doing so is intended for use by non-library targets such as binaries that do not have dependants. |
-| `add_exports` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  Allow this library to access the given /. |
-| `add_opens` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  Allow this library to reflectively access the given /. |
+| `sourcepath` | [sequence](/versions/8.3.1/rules/lib/core/list) of [File](/versions/8.3.1/rules/lib/builtins/File)s; default is `[]` |
+| `resources` | [sequence](/versions/8.3.1/rules/lib/core/list) of [File](/versions/8.3.1/rules/lib/builtins/File)s; default is `[]` |
+| `resource_jars` | [sequence](/versions/8.3.1/rules/lib/core/list) of [File](/versions/8.3.1/rules/lib/builtins/File)s; default is `[]` |
+| `classpath_resources` | [sequence](/versions/8.3.1/rules/lib/core/list) of [File](/versions/8.3.1/rules/lib/builtins/File)s; default is `[]` |
+| `neverlink` | [bool](/versions/8.3.1/rules/lib/core/bool); default is `False` |
+| `enable_annotation_processing` | [bool](/versions/8.3.1/rules/lib/core/bool); default is `True`  Disables annotation processing in this compilation, causing any annotation processors provided in plugins or in exported\_plugins of deps to be ignored. |
+| `enable_compile_jar_action` | [bool](/versions/8.3.1/rules/lib/core/bool); default is `True`  Enables header compilation or ijar creation. If set to False, it forces use of the full class jar in the compilation classpaths of any dependants. Doing so is intended for use by non-library targets such as binaries that do not have dependants. |
+| `add_exports` | [sequence](/versions/8.3.1/rules/lib/core/list) of [string](/versions/8.3.1/rules/lib/core/string)s; default is `[]`  Allow this library to access the given /. |
+| `add_opens` | [sequence](/versions/8.3.1/rules/lib/core/list) of [string](/versions/8.3.1/rules/lib/core/string)s; default is `[]`  Allow this library to reflectively access the given /. |
 
 ## JavaRuntimeInfo
 
@@ -91,7 +91,7 @@ Merges the given providers into a single JavaInfo.
 
 | Parameter | Description |
 | --- | --- |
-| `providers` | [sequence](../core/list) of [struct](../builtins/struct)s; required  The list of providers to merge. |
+| `providers` | [sequence](/versions/8.3.1/rules/lib/core/list) of [struct](/versions/8.3.1/rules/lib/builtins/struct)s; required  The list of providers to merge. |
 
 ## pack\_sources
 
@@ -109,11 +109,11 @@ Packs sources and source jars into a single source jar file. The return value is
 
 | Parameter | Description |
 | --- | --- |
-| `actions` | [actions](../builtins/actions); required  ctx.actions |
-| `output_jar` | [File](../builtins/File); or `None`; default is `None`  **Deprecated**. This parameter is deprecated and will be removed soon. Please do not depend on it. It is *disabled* with `--incompatible_java_common_parameters`. Use this flag to verify your code is compatible with its imminent removal.  Deprecated: The output jar of the rule. Used to name the resulting source jar. The parameter sets output\_source\_jar parameter to `{output\_jar}-src.jar`.Use output\_source\_jar parameter directly instead. |
-| `output_source_jar` | [File](../builtins/File); or `None`; default is `None` |
-| `sources` | [sequence](../core/list) of [File](../builtins/File)s; default is `[]`  A list of Java source files to be packed into the source jar. |
-| `source_jars` | [sequence](../core/list) of [File](../builtins/File)s; default is `[]`  A list of source jars to be packed into the source jar. |
+| `actions` | [actions](/versions/8.3.1/rules/lib/builtins/actions); required  ctx.actions |
+| `output_jar` | [File](/versions/8.3.1/rules/lib/builtins/File); or `None`; default is `None`  **Deprecated**. This parameter is deprecated and will be removed soon. Please do not depend on it. It is *disabled* with `--incompatible_java_common_parameters`. Use this flag to verify your code is compatible with its imminent removal.  Deprecated: The output jar of the rule. Used to name the resulting source jar. The parameter sets output\_source\_jar parameter to `{output\_jar}-src.jar`.Use output\_source\_jar parameter directly instead. |
+| `output_source_jar` | [File](/versions/8.3.1/rules/lib/builtins/File); or `None`; default is `None` |
+| `sources` | [sequence](/versions/8.3.1/rules/lib/core/list) of [File](/versions/8.3.1/rules/lib/builtins/File)s; default is `[]`  A list of Java source files to be packed into the source jar. |
+| `source_jars` | [sequence](/versions/8.3.1/rules/lib/core/list) of [File](/versions/8.3.1/rules/lib/builtins/File)s; default is `[]`  A list of source jars to be packed into the source jar. |
 | `java_toolchain` | Info; required  A JavaToolchainInfo to used to find the ijar tool. |
 | `host_javabase` | default is `None`  **Deprecated**. This parameter is deprecated and will be removed soon. Please do not depend on it. It is *disabled* with `--incompatible_java_common_parameters`. Use this flag to verify your code is compatible with its imminent removal.  Deprecated: You can drop this parameter (host\_javabase is provided with java\_toolchain) |
 
@@ -129,9 +129,9 @@ Runs ijar on a jar, stripping it of its method bodies. This helps reduce rebuild
 
 | Parameter | Description |
 | --- | --- |
-| `actions` | [actions](../builtins/actions); required |
-| `jar` | [File](../builtins/File); required  The jar to run ijar on. |
-| `target_label` | [Label](../builtins/Label); or `None`; default is `None`  A target label to stamp the jar with. Used for `add_dep` support. Typically, you would pass `ctx.label` to stamp the jar with the current rule's label. |
+| `actions` | [actions](/versions/8.3.1/rules/lib/builtins/actions); required |
+| `jar` | [File](/versions/8.3.1/rules/lib/builtins/File); required  The jar to run ijar on. |
+| `target_label` | [Label](/versions/8.3.1/rules/lib/builtins/Label); or `None`; default is `None`  A target label to stamp the jar with. Used for `add_dep` support. Typically, you would pass `ctx.label` to stamp the jar with the current rule's label. |
 | `java_toolchain` | Info; required  A JavaToolchainInfo to used to find the ijar tool. |
 
 ## stamp\_jar
@@ -146,7 +146,7 @@ Stamps a jar with a target label for `add_dep` support. The return value is typi
 
 | Parameter | Description |
 | --- | --- |
-| `actions` | [actions](../builtins/actions); required  ctx.actions |
-| `jar` | [File](../builtins/File); required  The jar to run stamp\_jar on. |
-| `target_label` | [Label](../builtins/Label); required  A target label to stamp the jar with. Used for `add_dep` support. Typically, you would pass `ctx.label` to stamp the jar with the current rule's label. |
+| `actions` | [actions](/versions/8.3.1/rules/lib/builtins/actions); required  ctx.actions |
+| `jar` | [File](/versions/8.3.1/rules/lib/builtins/File); required  The jar to run stamp\_jar on. |
+| `target_label` | [Label](/versions/8.3.1/rules/lib/builtins/Label); required  A target label to stamp the jar with. Used for `add_dep` support. Typically, you would pass `ctx.label` to stamp the jar with the current rule's label. |
 | `java_toolchain` | Info; required  A JavaToolchainInfo to used to find the stamp\_jar tool. |
\ No newline at end of file
diff --git a/versions/8.3.1/rules/lib/toplevel/native.mdx b/versions/8.3.1/rules/lib/toplevel/native.mdx
index 204fb814..b114bbc5 100644
--- a/versions/8.3.1/rules/lib/toplevel/native.mdx
+++ b/versions/8.3.1/rules/lib/toplevel/native.mdx
@@ -46,7 +46,7 @@ If possible, avoid using this function. It makes BUILD files brittle and order-d
 
 | Parameter | Description |
 | --- | --- |
-| `name` | [string](../core/string); required |
+| `name` | [string](/versions/8.3.1/rules/lib/core/string); required |
 
 ## existing\_rules
 
@@ -72,9 +72,9 @@ Specifies a list of files belonging to this package that are exported to other p
 
 | Parameter | Description |
 | --- | --- |
-| `srcs` | [sequence](../core/list) of [string](../core/string)s; required  The list of files to export. |
-| `visibility` | [sequence](../core/list); or `None`; default is `None`  A visibility declaration can to be specified. The files will be visible to the targets specified. If no visibility is specified, the files will be visible to every package. |
-| `licenses` | [sequence](../core/list) of [string](../core/string)s; or `None`; default is `None`  Licenses to be specified. |
+| `srcs` | [sequence](/versions/8.3.1/rules/lib/core/list) of [string](/versions/8.3.1/rules/lib/core/string)s; required  The list of files to export. |
+| `visibility` | [sequence](/versions/8.3.1/rules/lib/core/list); or `None`; default is `None`  A visibility declaration can to be specified. The files will be visible to the targets specified. If no visibility is specified, the files will be visible to every package. |
+| `licenses` | [sequence](/versions/8.3.1/rules/lib/core/list) of [string](/versions/8.3.1/rules/lib/core/string)s; or `None`; default is `None`  Licenses to be specified. |
 
 ## glob
 
@@ -93,9 +93,9 @@ If the `exclude_directories` argument is enabled (set to `1`), files of type dir
 
 | Parameter | Description |
 | --- | --- |
-| `include` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  The list of glob patterns to include. |
-| `exclude` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  The list of glob patterns to exclude. |
-| `exclude_directories` | [int](../core/int); default is `1`  A flag whether to exclude directories or not. |
+| `include` | [sequence](/versions/8.3.1/rules/lib/core/list) of [string](/versions/8.3.1/rules/lib/core/string)s; default is `[]`  The list of glob patterns to include. |
+| `exclude` | [sequence](/versions/8.3.1/rules/lib/core/list) of [string](/versions/8.3.1/rules/lib/core/string)s; default is `[]`  The list of glob patterns to exclude. |
+| `exclude_directories` | [int](/versions/8.3.1/rules/lib/core/int); default is `1`  A flag whether to exclude directories or not. |
 | `allow_empty` | default is `unbound`  Whether we allow glob patterns to match nothing. If `allow\_empty` is False, each individual include pattern must match something and also the final result must be non-empty (after the matches of the `exclude` patterns are excluded). |
 
 ## module\_name
@@ -128,9 +128,9 @@ This function defines a set of packages and assigns a label to the group. The la
 
 | Parameter | Description |
 | --- | --- |
-| `name` | [string](../core/string); required  The unique name for this rule. |
-| `packages` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  A complete enumeration of packages in this group. |
-| `includes` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  Other package groups that are included in this one. |
+| `name` | [string](/versions/8.3.1/rules/lib/core/string); required  The unique name for this rule. |
+| `packages` | [sequence](/versions/8.3.1/rules/lib/core/list) of [string](/versions/8.3.1/rules/lib/core/string)s; default is `[]`  A complete enumeration of packages in this group. |
+| `includes` | [sequence](/versions/8.3.1/rules/lib/core/list) of [string](/versions/8.3.1/rules/lib/core/string)s; default is `[]`  Other package groups that are included in this one. |
 
 ## package\_name
 
@@ -146,19 +146,19 @@ The name of the package being evaluated, without the repository name. For exampl
 Label native.package_relative_label(input)
 ```
 
-Converts the input string into a [Label](../builtins/Label) object, in the context of the package currently being initialized (that is, the `BUILD` file for which the current macro is executing). If the input is already a `Label`, it is returned unchanged.
+Converts the input string into a [Label](/versions/8.3.1/rules/lib/builtins/Label) object, in the context of the package currently being initialized (that is, the `BUILD` file for which the current macro is executing). If the input is already a `Label`, it is returned unchanged.
 
 This function may only be called while evaluating a BUILD file and the macros it directly or indirectly calls; it may not be called in (for instance) a rule implementation function.
 
 The result of this function is the same `Label` value as would be produced by passing the given string to a label-valued attribute of a target declared in the BUILD file.
 
-*Usage note:* The difference between this function and [Label()](../builtins/Label#Label) is that `Label()` uses the context of the package of the `.bzl` file that called it, not the package of the `BUILD` file. Use `Label()` when you need to refer to a fixed target that is hardcoded into the macro, such as a compiler. Use `package_relative_label()` when you need to normalize a label string supplied by the BUILD file to a `Label` object. (There is no way to convert a string to a `Label` in the context of a package other than the BUILD file or the calling .bzl file. For that reason, outer macros should always prefer to pass Label objects to inner macros rather than label strings.)
+*Usage note:* The difference between this function and [Label()](/versions/8.3.1/rules/lib/builtins/Label#Label) is that `Label()` uses the context of the package of the `.bzl` file that called it, not the package of the `BUILD` file. Use `Label()` when you need to refer to a fixed target that is hardcoded into the macro, such as a compiler. Use `package_relative_label()` when you need to normalize a label string supplied by the BUILD file to a `Label` object. (There is no way to convert a string to a `Label` in the context of a package other than the BUILD file or the calling .bzl file. For that reason, outer macros should always prefer to pass Label objects to inner macros rather than label strings.)
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `input` | [string](../core/string); or [Label](../builtins/Label); required  The input label string or Label object. If a Label object is passed, it's returned as is. |
+| `input` | [string](/versions/8.3.1/rules/lib/core/string); or [Label](/versions/8.3.1/rules/lib/builtins/Label); required  The input label string or Label object. If a Label object is passed, it's returned as is. |
 
 ## repo\_name
 
@@ -191,6 +191,6 @@ Returns a new mutable list of every direct subpackage of the current package, re
 
 | Parameter | Description |
 | --- | --- |
-| `include` | [sequence](../core/list) of [string](../core/string)s; required |
-| `exclude` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  The list of glob patterns to exclude from subpackages scan. |
-| `allow_empty` | [bool](../core/bool); default is `False`  Whether we fail if the call returns an empty list. By default empty list indicates potential error in BUILD file where the call to subpackages() is superflous. Setting to true allows this function to succeed in that case. |*
\ No newline at end of file
+| `include` | [sequence](/versions/8.3.1/rules/lib/core/list) of [string](/versions/8.3.1/rules/lib/core/string)s; required |
+| `exclude` | [sequence](/versions/8.3.1/rules/lib/core/list) of [string](/versions/8.3.1/rules/lib/core/string)s; default is `[]`  The list of glob patterns to exclude from subpackages scan. |
+| `allow_empty` | [bool](/versions/8.3.1/rules/lib/core/bool); default is `False`  Whether we fail if the call returns an empty list. By default empty list indicates potential error in BUILD file where the call to subpackages() is superflous. Setting to true allows this function to succeed in that case. |*
\ No newline at end of file
diff --git a/versions/8.3.1/rules/lib/toplevel/platform_common.mdx b/versions/8.3.1/rules/lib/toplevel/platform_common.mdx
index 17edc7c5..d692e45a 100644
--- a/versions/8.3.1/rules/lib/toplevel/platform_common.mdx
+++ b/versions/8.3.1/rules/lib/toplevel/platform_common.mdx
@@ -18,7 +18,7 @@ Functions for Starlark to interact with the platform APIs.
 Provider platform_common.ConstraintSettingInfo
 ```
 
-The constructor/key for the [ConstraintSettingInfo](../providers/ConstraintSettingInfo) provider.
+The constructor/key for the [ConstraintSettingInfo](/versions/8.3.1/rules/lib/providers/ConstraintSettingInfo) provider.
 *Note: This API is experimental and may change at any time. It is disabled by default, but may be enabled with `--experimental_platforms_api`*
 
 ## ConstraintValueInfo
@@ -27,7 +27,7 @@ The constructor/key for the [ConstraintSettingInfo](../providers/ConstraintSetti
 Provider platform_common.ConstraintValueInfo
 ```
 
-The constructor/key for the [ConstraintValueInfo](../providers/ConstraintValueInfo) provider.
+The constructor/key for the [ConstraintValueInfo](/versions/8.3.1/rules/lib/providers/ConstraintValueInfo) provider.
 *Note: This API is experimental and may change at any time. It is disabled by default, but may be enabled with `--experimental_platforms_api`*
 
 ## PlatformInfo
@@ -36,7 +36,7 @@ The constructor/key for the [ConstraintValueInfo](../providers/ConstraintValueIn
 Provider platform_common.PlatformInfo
 ```
 
-The constructor/key for the [PlatformInfo](../providers/PlatformInfo) provider.
+The constructor/key for the [PlatformInfo](/versions/8.3.1/rules/lib/providers/PlatformInfo) provider.
 *Note: This API is experimental and may change at any time. It is disabled by default, but may be enabled with `--experimental_platforms_api`*
 
 ## TemplateVariableInfo
@@ -45,7 +45,7 @@ The constructor/key for the [PlatformInfo](../providers/PlatformInfo) provider.
 Provider platform_common.TemplateVariableInfo
 ```
 
-The constructor/key for the [TemplateVariableInfo](../providers/TemplateVariableInfo) provider.
+The constructor/key for the [TemplateVariableInfo](/versions/8.3.1/rules/lib/providers/TemplateVariableInfo) provider.
 
 ## ToolchainInfo
 
@@ -53,4 +53,4 @@ The constructor/key for the [TemplateVariableInfo](../providers/TemplateVariable
 Provider platform_common.ToolchainInfo
 ```
 
-The constructor/key for the [ToolchainInfo](../providers/ToolchainInfo) provider.
\ No newline at end of file
+The constructor/key for the [ToolchainInfo](/versions/8.3.1/rules/lib/providers/ToolchainInfo) provider.
\ No newline at end of file
diff --git a/versions/8.3.1/rules/lib/toplevel/testing.mdx b/versions/8.3.1/rules/lib/toplevel/testing.mdx
index 5489113c..f74462bd 100644
--- a/versions/8.3.1/rules/lib/toplevel/testing.mdx
+++ b/versions/8.3.1/rules/lib/toplevel/testing.mdx
@@ -24,12 +24,12 @@ The number of transitive dependencies of the test are limited. The limit is cont
 
 | Parameter | Description |
 | --- | --- |
-| `name` | [string](../core/string); required  Name of the target. It should be a Starlark identifier, matching pattern '[A-Za-z\_][A-Za-z0-9\_]\*'. |
-| `implementation` | [function](../core/function); required  The Starlark function implementing this analysis test. It must have exactly one parameter: [ctx](../builtins/ctx). The function is called during the analysis phase. It can access the attributes declared by `attrs` and populated via `attr_values`. The implementation function may not register actions. Instead, it must register a pass/fail result via providing [AnalysisTestResultInfo](../providers/AnalysisTestResultInfo). |
-| `attrs` | [dict](../core/dict); default is `{}`  Dictionary declaring the attributes. See the [rule](../globals/bzl#rule) call. Attributes are allowed to use configuration transitions defined using [analysis\_test\_transition](../globals/bzl#analysis_test_transition). |
-| `fragments` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  List of configuration fragments that are available to the implementation of the analysis test. |
-| `toolchains` | [sequence](../core/list); default is `[]`  The set of toolchains the test requires. See the [rule](../globals/bzl#rule) call. |
-| `attr_values` | [dict](../core/dict) of [string](../core/string)s; default is `{}`  Dictionary of attribute values to pass to the implementation. |
+| `name` | [string](/versions/8.3.1/rules/lib/core/string); required  Name of the target. It should be a Starlark identifier, matching pattern '[A-Za-z\_][A-Za-z0-9\_]\*'. |
+| `implementation` | [function](/versions/8.3.1/rules/lib/core/function); required  The Starlark function implementing this analysis test. It must have exactly one parameter: [ctx](/versions/8.3.1/rules/lib/builtins/ctx). The function is called during the analysis phase. It can access the attributes declared by `attrs` and populated via `attr_values`. The implementation function may not register actions. Instead, it must register a pass/fail result via providing [AnalysisTestResultInfo](/versions/8.3.1/rules/lib/providers/AnalysisTestResultInfo). |
+| `attrs` | [dict](/versions/8.3.1/rules/lib/core/dict); default is `{}`  Dictionary declaring the attributes. See the [rule](/versions/8.3.1/rules/lib/globals/bzl#rule) call. Attributes are allowed to use configuration transitions defined using [analysis\_test\_transition](/versions/8.3.1/rules/lib/globals/bzl#analysis_test_transition). |
+| `fragments` | [sequence](/versions/8.3.1/rules/lib/core/list) of [string](/versions/8.3.1/rules/lib/core/string)s; default is `[]`  List of configuration fragments that are available to the implementation of the analysis test. |
+| `toolchains` | [sequence](/versions/8.3.1/rules/lib/core/list); default is `[]`  The set of toolchains the test requires. See the [rule](/versions/8.3.1/rules/lib/globals/bzl#rule) call. |
+| `attr_values` | [dict](/versions/8.3.1/rules/lib/core/dict) of [string](/versions/8.3.1/rules/lib/core/string)s; default is `{}`  Dictionary of attribute values to pass to the implementation. |
 
 ## ExecutionInfo
 
@@ -37,7 +37,7 @@ The number of transitive dependencies of the test are limited. The limit is cont
 ExecutionInfo testing.ExecutionInfo
 ```
 
-[testing.ExecutionInfo](../providers/ExecutionInfo) provider key/constructor
+[testing.ExecutionInfo](/versions/8.3.1/rules/lib/providers/ExecutionInfo) provider key/constructor
 
 ## TestEnvironment
 
@@ -51,5 +51,5 @@ RunEnvironmentInfo testing.TestEnvironment(environment, inherited_environment=[]
 
 | Parameter | Description |
 | --- | --- |
-| `environment` | [dict](../core/dict); required  A map of string keys and values that represent environment variables and their values. These will be made available during the test execution. |
-| `inherited_environment` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  A sequence of names of environment variables. These variables are made available during the test execution with their current value taken from the shell environment. If a variable is contained in both `environment` and `inherited_environment`, the value inherited from the shell environment will take precedence if set. |
\ No newline at end of file
+| `environment` | [dict](/versions/8.3.1/rules/lib/core/dict); required  A map of string keys and values that represent environment variables and their values. These will be made available during the test execution. |
+| `inherited_environment` | [sequence](/versions/8.3.1/rules/lib/core/list) of [string](/versions/8.3.1/rules/lib/core/string)s; default is `[]`  A sequence of names of environment variables. These variables are made available during the test execution with their current value taken from the shell environment. If a variable is contained in both `environment` and `inherited_environment`, the value inherited from the shell environment will take precedence if set. |
\ No newline at end of file
diff --git a/versions/8.3.1/rules/macro-tutorial.mdx b/versions/8.3.1/rules/macro-tutorial.mdx
index 8917c648..6794ee48 100644
--- a/versions/8.3.1/rules/macro-tutorial.mdx
+++ b/versions/8.3.1/rules/macro-tutorial.mdx
@@ -5,7 +5,7 @@ title: 'Creating a Symbolic Macro'
 IMPORTANT: This tutorial is for [*symbolic macros*](/versions/8.3.1/extending/macros) – the new
 macro system introduced in Bazel 8. If you need to support older Bazel versions,
 you will want to write a [legacy macro](/versions/8.3.1/extending/legacy-macros) instead; take
-a look at [Creating a Legacy Macro](../legacy-macro-tutorial).
+a look at [Creating a Legacy Macro](/versions/8.3.1/rules/legacy-macro-tutorial).
 
 Imagine that you need to run a tool as part of your build. For example, you
 may want to generate or preprocess a source file, or compress a binary. In this
diff --git a/versions/8.3.1/rules/performance.mdx b/versions/8.3.1/rules/performance.mdx
index 4b953a05..281c2bdd 100644
--- a/versions/8.3.1/rules/performance.mdx
+++ b/versions/8.3.1/rules/performance.mdx
@@ -15,7 +15,7 @@ widespread use.
 ## Use depsets {#use-depsets}
 
 Whenever you are rolling up information from rule dependencies you should use
-[depsets](lib/depset). Only use plain lists or dicts to publish information
+[depsets](/versions/8.3.1/rules/lib/builtins/depset). Only use plain lists or dicts to publish information
 local to the current rule.
 
 A depset represents information as a nested graph which enables sharing.
@@ -73,7 +73,7 @@ See the [depset overview](/versions/8.3.1/extending/depsets) page for more infor
 ### Avoid calling `depset.to_list()` {#avoid-depset-to-list}
 
 You can coerce a depset to a flat list using
-[`to_list()`](lib/depset#to_list), but doing so usually results in O(N^2)
+[`to_list()`](/versions/8.3.1/rules/lib/builtins/depset#to_list), but doing so usually results in O(N^2)
 cost. If at all possible, avoid any flattening of depsets except for debugging
 purposes.
 
@@ -115,7 +115,7 @@ x = depset(transitive = [i.deps for i in inputs])
 
 ## Use ctx.actions.args() for command lines {#ctx-actions-args}
 
-When building command lines you should use [ctx.actions.args()](lib/Args).
+When building command lines you should use [ctx.actions.args()](/versions/8.3.1/rules/lib/builtins/Args).
 This defers expansion of any depsets to the execution phase.
 
 Apart from being strictly faster, this will reduce the memory consumption of
@@ -126,11 +126,11 @@ Here are some tricks:
 * Pass depsets and lists directly as arguments, instead of flattening them
 yourself. They will get expanded by `ctx.actions.args()` for you.
 If you need any transformations on the depset contents, look at
-[ctx.actions.args#add](lib/Args#add) to see if anything fits the bill.
+[ctx.actions.args#add](/versions/8.3.1/rules/lib/builtins/Args#add) to see if anything fits the bill.
 
 * Are you passing `File#path` as arguments? No need. Any
-[File](lib/File) is automatically turned into its
-[path](lib/File#path), deferred to expansion time.
+[File](/versions/8.3.1/rules/lib/builtins/File) is automatically turned into its
+[path](/versions/8.3.1/rules/lib/builtins/File#path), deferred to expansion time.
 
 * Avoid constructing strings by concatenating them together.
 The best string argument is a constant as its memory will be shared between
@@ -138,10 +138,10 @@ all instances of your rule.
 
 * If the args are too long for the command line an `ctx.actions.args()` object
 can be conditionally or unconditionally written to a param file using
-[`ctx.actions.args#use_param_file`](lib/Args#use_param_file). This is
+[`ctx.actions.args#use_param_file`](/versions/8.3.1/rules/lib/builtins/Args#use_param_file). This is
 done behind the scenes when the action is executed. If you need to explicitly
 control the params file you can write it manually using
-[`ctx.actions.write`](lib/actions#write).
+[`ctx.actions.write`](/versions/8.3.1/rules/lib/builtins/actions#write).
 
 Example:
 
@@ -176,7 +176,7 @@ def _to_short_path(f):
 
 ## Transitive action inputs should be depsets {#transitive-action-inputs}
 
-When building an action using [ctx.actions.run](lib/actions?#run), do not
+When building an action using [ctx.actions.run](/versions/8.3.1/rules/lib/builtins/actions#run), do not
 forget that the `inputs` field accepts a depset. Use this whenever inputs are
 collected from dependencies transitively.
 
diff --git a/versions/8.3.1/rules/rules-tutorial.mdx b/versions/8.3.1/rules/rules-tutorial.mdx
index 431a799e..024f2a81 100644
--- a/versions/8.3.1/rules/rules-tutorial.mdx
+++ b/versions/8.3.1/rules/rules-tutorial.mdx
@@ -31,9 +31,9 @@ foo_binary = rule(
 )
 ```
 
-When you call the [`rule`](lib/globals#rule) function, you
+When you call the [`rule`](/versions/8.3.1/rules/lib/globals#rule) function, you
 must define a callback function. The logic will go there, but you
-can leave the function empty for now. The [`ctx`](lib/ctx) argument
+can leave the function empty for now. The [`ctx`](/versions/8.3.1/rules/lib/builtins/ctx) argument
 provides information about the target.
 
 You can load the rule and use it from a `BUILD` file.
@@ -86,10 +86,10 @@ foo_binary(name = "bin1")
 foo_binary(name = "bin2")
 ```
 
-[`ctx.label`](lib/ctx#label)
+[`ctx.label`](/versions/8.3.1/rules/lib/builtins/ctx#label)
 corresponds to the label of the target being analyzed. The `ctx` object has
 many useful fields and methods; you can find an exhaustive list in the
-[API reference](lib/ctx).
+[API reference](/versions/8.3.1/rules/lib/builtins/ctx).
 
 Query the code:
 
@@ -145,7 +145,7 @@ bin2
 ```
 
 Whenever you declare a file, you have to tell Bazel how to generate it by
-creating an action. Use [`ctx.actions.write`](lib/actions#write),
+creating an action. Use [`ctx.actions.write`](/versions/8.3.1/rules/lib/builtins/actions#write),
 to create a file with the given content.
 
 ```python
@@ -200,7 +200,7 @@ You have successfully generated a file!
 ## Attributes
 
 To make the rule more useful, add new attributes using
-[the `attr` module](lib/attr) and update the rule definition.
+[the `attr` module](/versions/8.3.1/rules/lib/toplevel/attr) and update the rule definition.
 
 Add a string attribute called `username`:
 
@@ -236,22 +236,22 @@ def _foo_binary_impl(ctx):
 ```
 
 Note that you can make the attribute mandatory or set a default value. Look at
-the documentation of [`attr.string`](lib/attr#string).
-You may also use other types of attributes, such as [boolean](lib/attr#bool)
-or [list of integers](lib/attr#int_list).
+the documentation of [`attr.string`](/versions/8.3.1/rules/lib/toplevel/attr#string).
+You may also use other types of attributes, such as [boolean](/versions/8.3.1/rules/lib/toplevel/attr#bool)
+or [list of integers](/versions/8.3.1/rules/lib/toplevel/attr#int_list).
 
 ## Dependencies
 
-Dependency attributes, such as [`attr.label`](lib/attr#label)
-and [`attr.label_list`](lib/attr#label_list),
+Dependency attributes, such as [`attr.label`](/versions/8.3.1/rules/lib/toplevel/attr#label)
+and [`attr.label_list`](/versions/8.3.1/rules/lib/toplevel/attr#label_list),
 declare a dependency from the target that owns the attribute to the target whose
 label appears in the attribute's value. This kind of attribute forms the basis
 of the target graph.
 
 In the `BUILD` file, the target label appears as a string object, such as
 `//pkg:name`. In the implementation function, the target will be accessible as a
-[`Target`](lib/Target) object. For example, view the files returned
-by the target using [`Target.files`](lib/Target#modules.Target.files).
+[`Target`](/versions/8.3.1/rules/lib/builtins/Target) object. For example, view the files returned
+by the target using [`Target.files`](/versions/8.3.1/rules/lib/builtins/Target#modules.Target.files).
 
 ### Multiple files
 
@@ -294,7 +294,7 @@ implementation function, but this has two problems. First, as the template gets
 bigger, it becomes more memory efficient to put it in a separate file and avoid
 constructing large strings during the analysis phase. Second, using a separate
 file is more convenient for the user. Instead, use
-[`ctx.actions.expand_template`](lib/actions#expand_template),
+[`ctx.actions.expand_template`](/versions/8.3.1/rules/lib/builtins/actions#expand_template),
 which performs substitutions on a template file.
 
 Create a `template` attribute to declare a dependency on the template
diff --git a/versions/8.3.1/rules/testing.mdx b/versions/8.3.1/rules/testing.mdx
index 1b018d9a..b0222b60 100644
--- a/versions/8.3.1/rules/testing.mdx
+++ b/versions/8.3.1/rules/testing.mdx
@@ -234,7 +234,7 @@ def _inspect_actions_test_impl(ctx):
 ```
 
 Note that `analysistest.target_actions(env)` returns a list of
-[`Action`](lib/Action) objects which represent actions registered by the
+[`Action`](/versions/8.3.1/rules/lib/builtins/Action) objects which represent actions registered by the
 target under test.
 
 ### Verifying rule behavior under different flags {#verifying-rule-behavior}
diff --git a/versions/8.3.1/rules/verbs-tutorial.mdx b/versions/8.3.1/rules/verbs-tutorial.mdx
index b34725ee..526d5914 100644
--- a/versions/8.3.1/rules/verbs-tutorial.mdx
+++ b/versions/8.3.1/rules/verbs-tutorial.mdx
@@ -49,8 +49,7 @@ This pattern can also be seen in the Angular project. The
 produces two targets. The first is a standard `nodejs_test` target which compares
 some generated output against a "golden" file (that is, a file containing the
 expected output). This can be built and run with a normal `bazel
-test` invocation. In `angular-cli`, you can run [one such
-target](https://github.com/angular/angular-cli/blob/e1269cb520871ee29b1a4eec6e6c0e4a94f0b5fc/etc/api/BUILD)
+test` invocation. In `angular-cli`, you can run [one such target](https://github.com/angular/angular-cli/blob/e1269cb520871ee29b1a4eec6e6c0e4a94f0b5fc/etc/api/BUILD)
 with `bazel test //etc/api:angular_devkit_core_api`.
 
 Over time, this golden file may need to be updated for legitimate reasons.
@@ -159,7 +158,7 @@ an imaginary `bazel publish` command.
 It's not immediately obvious what the implementation of the `_sphinx_publisher`
 rule might look like. Often, actions like this write a _launcher_ shell script.
 This method typically involves using
-[`ctx.actions.expand_template`](lib/actions#expand_template)
+[`ctx.actions.expand_template`](/versions/8.3.1/rules/lib/builtins/actions#expand_template)
 to write a very simple shell script, in this case invoking the publisher binary
 with a path to the output of the primary target. This way, the publisher
 implementation can remain generic, the `_sphinx_site` rule can just produce
diff --git a/versions/8.3.1/run/build.mdx b/versions/8.3.1/run/build.mdx
index 92fb3fc1..8a3fabca 100644
--- a/versions/8.3.1/run/build.mdx
+++ b/versions/8.3.1/run/build.mdx
@@ -626,8 +626,7 @@ Note: Hermeticity means that the action only uses its declared input
 files and no other files in the filesystem, and it only produces its declared
 output files. See [Hermeticity](/versions/8.3.1/basics/hermeticity) for more details.
 
-On some platforms such as [Google Kubernetes
-Engine](https://cloud.google.com/kubernetes-engine/) cluster nodes or Debian,
+On some platforms such as [Google Kubernetes Engine](https://cloud.google.com/kubernetes-engine/) cluster nodes or Debian,
 user namespaces are deactivated by default due to security
 concerns. This can be checked by looking at the file
 `/proc/sys/kernel/unprivileged_userns_clone`: if it exists and contains a 0,
diff --git a/versions/8.3.1/start/android-app.mdx b/versions/8.3.1/start/android-app.mdx
index 8abda7da..f6bc09fd 100644
--- a/versions/8.3.1/start/android-app.mdx
+++ b/versions/8.3.1/start/android-app.mdx
@@ -36,8 +36,7 @@ In this tutorial you learn how to:
 Before you begin the tutorial, install the following software:
 
 * **Bazel.** To install, follow the [installation instructions](/versions/8.3.1/install).
-* **Android Studio.** To install, follow the steps to [download Android
-  Studio](https://developer.android.com/sdk/index.html).
+* **Android Studio.** To install, follow the steps to [download Android Studio](https://developer.android.com/sdk/index.html).
   Execute the setup wizard to download the SDK and configure your environment.
 * (Optional) **Git.** Use `git` to download the Android app project.
 
@@ -52,8 +51,7 @@ This app has a single button that prints a greeting when clicked:
 
 **Figure 1.** Android app button greeting.
 
-Clone the repository with `git` (or [download the ZIP file
-directly](https://github.com/bazelbuild/examples/archive/master.zip)):
+Clone the repository with `git` (or [download the ZIP file directly](https://github.com/bazelbuild/examples/archive/master.zip)):
 
 ```posix-terminal
 git clone https://github.com/bazelbuild/examples
@@ -103,8 +101,7 @@ A [workspace](/versions/8.3.1/concepts/build-ref#workspace) is a directory that
 source files for one or more software projects, and has a `MODULE.bazel` file at
 its root.
 
-The `MODULE.bazel` file may be empty or may contain references to [external
-dependencies](/versions/8.3.1/external/overview) required to build your project.
+The `MODULE.bazel` file may be empty or may contain references to [external dependencies](/versions/8.3.1/external/overview) required to build your project.
 
 First, run the following command to create an empty `MODULE.bazel` file:
 
@@ -147,8 +144,7 @@ environment variable, and automatically detect the highest API level and the
 latest version of build tools installed within that location.
 
 You can set the `ANDROID_HOME` variable to the location of the Android SDK. Find
-the path to the installed SDK using Android Studio's [SDK
-Manager](https://developer.android.com/studio/intro/update#sdk-manager).
+the path to the installed SDK using Android Studio's [SDK Manager](https://developer.android.com/studio/intro/update#sdk-manager).
 Assuming the SDK is installed to default locations, you can use the following
 commands to set the `ANDROID_HOME` variable:
 
@@ -170,16 +166,14 @@ them permanent, run the following commands:
 | Windows (PowerShell)     | `[System.Environment]::SetEnvironmentVariable('ANDROID_HOME', "$env:LOCALAPPDATA\Android\Sdk", [System.EnvironmentVariableTarget]::User)` |
 
 **Optional:** If you want to compile native code into your Android app, you
-also need to download the [Android
-NDK](https://developer.android.com/ndk/downloads/index.html)
+also need to download the [Android NDK](https://developer.android.com/ndk/downloads/index.html)
 and use `rules_android_ndk` by adding the following line to your `MODULE.bazel` file:
 
 ```python
 bazel_dep(name = "rules_android_ndk", version = "0.1.2")
 ```
 
-For more information, read [Using the Android Native Development Kit with
-Bazel](/versions/8.3.1/docs/android-ndk).
+For more information, read [Using the Android Native Development Kit with Bazel](/versions/8.3.1/docs/android-ndk).
 
 It's not necessary to set the API levels to the same value for the SDK and NDK.
 [This page](https://developer.android.com/ndk/guides/stable_apis.html)
@@ -221,8 +215,7 @@ files or other dependencies. Bazel provides two build rules,
 build an Android app.
 
 For this tutorial, you'll first use the
-`android_library` rule to tell Bazel to build an [Android library
-module](http://developer.android.com/tools/projects/index.html#LibraryProjects)
+`android_library` rule to tell Bazel to build an [Android library module](http://developer.android.com/tools/projects/index.html#LibraryProjects)
 from the app source code and resource files. You'll then use the
 `android_binary` rule to tell Bazel how to build the Android application package.
 
@@ -337,11 +330,9 @@ file:
 ### Run the app
 
 You can now deploy the app to a connected Android device or emulator from the
-command line using the [`bazel
-mobile-install`](/versions/8.3.1/docs/user-manual#mobile-install) command. This command uses
+command line using the [`bazel mobile-install`](/versions/8.3.1/docs/user-manual#mobile-install) command. This command uses
 the Android Debug Bridge (`adb`) to communicate with the device. You must set up
-your device to use `adb` following the instructions in [Android Debug
-Bridge](http://developer.android.com/tools/help/adb.html) before deployment. You
+your device to use `adb` following the instructions in [Android Debug Bridge](http://developer.android.com/tools/help/adb.html) before deployment. You
 can also choose to install the app on the Android emulator included in Android
 Studio. Make sure the emulator is running before executing the command below.
 
diff --git a/versions/8.3.1/start/cpp.mdx b/versions/8.3.1/start/cpp.mdx
index 8cd927ec..fb2c35fe 100644
--- a/versions/8.3.1/start/cpp.mdx
+++ b/versions/8.3.1/start/cpp.mdx
@@ -19,8 +19,7 @@ Estimated completion time: 30 minutes.
 ### Prerequisites {#prerequisites}
 
 Start by [installing Bazel](https://bazel.build/versions/8.3.1/install), if you haven't
-already. This tutorial uses Git for source control, so for best results [install
-Git](https://git-scm.com/book/en/v2/Getting-Started-Installing-Git) as well.
+already. This tutorial uses Git for source control, so for best results [install Git](https://git-scm.com/book/en/v2/Getting-Started-Installing-Git) as well.
 
 Next, retrieve the sample project from Bazel's GitHub repository by running the
 following in your command-line tool of choice:
@@ -63,9 +62,7 @@ examples
 ```
 
 There are three sets of files, each set representing a stage in this tutorial.
-In the first stage, you will build a single [target]
-(https://bazel.build/reference/glossary#target) residing in a single [package]
-(https://bazel.build/reference/glossary#package). In the second stage, you will
+In the first stage, you will build a single [target](https://bazel.build/versions/8.3.1/reference/glossary#target) residing in a single [package](https://bazel.build/versions/8.3.1/reference/glossary#package). In the second stage, you will
 build both a binary and a library from a single package. In the third and final
 stage, you will build a project with multiple packages and build it with
 multiple targets.
@@ -86,8 +83,7 @@ It also contains these significant files:
 *   The `MODULE.bazel` file, which identifies the directory and its contents as
     a Bazel workspace and lives at the root of the project's directory
     structure. It's also where you specify your external dependencies.
-*   One or more [`BUILD`
-    files](https://bazel.build/reference/glossary#build-file), which tell Bazel
+*   One or more [`BUILD` files](https://bazel.build/versions/8.3.1/reference/glossary#build-file), which tell Bazel
     how to build different parts of the project. A directory within the
     workspace that contains a `BUILD` file is a
     [package](https://bazel.build/versions/8.3.1/reference/glossary#package). (More on packages
@@ -182,9 +178,7 @@ This results in a printed "`Hello world`" message.
 
 Here's the dependency graph of Stage 1:
 
-![Dependency graph for hello-world displays a single target with a single source
-file.](/versions/8.3.1/docs/images/cpp-tutorial-stage1.png "Dependency graph for hello-world
-displays a single target with a single source file.")
+![Dependency graph for hello-world displays a single target with a single source file.](/versions/8.3.1/docs/images/cpp-tutorial-stage1.png "Dependency graph for hello-world displays a single target with a single source file.")
 
 ### Summary: stage 1 {#summary-stage-1}
 
@@ -231,8 +225,7 @@ cc_binary(
 ```
 
 With this `BUILD` file, Bazel first builds the `hello-greet` library (using
-Bazel's built-in [`cc_library`
-rule](https://bazel.build/reference/be/c-cpp#cc_library)), then the
+Bazel's built-in [`cc_library` rule](https://bazel.build/versions/8.3.1/reference/be/c-cpp#cc_library)), then the
 `hello-world` binary. The `deps` attribute in the `hello-world` target tells
 Bazel that the `hello-greet` library is required to build the `hello-world`
 binary.
@@ -272,10 +265,7 @@ recompiles that file.
 Looking at the dependency graph, you can see that `hello-world` depends on an
 extra input named `hello-greet`:
 
-![Dependency graph for `hello-world` displays dependency changes after
-modification to the file.](/versions/8.3.1/docs/images/cpp-tutorial-stage2.png "Dependency
-graph for `hello-world` displays dependency changes after modification to the
-file.")
+![Dependency graph for `hello-world` displays dependency changes after modification to the file.](/versions/8.3.1/docs/images/cpp-tutorial-stage2.png "Dependency graph for `hello-world` displays dependency changes after modification to the file.")
 
 ### Summary: stage 2 {#summary-stage-2}
 
@@ -343,11 +333,7 @@ in the `lib` package (hence the target label `//lib:hello-time`) - Bazel knows
 this through the `deps` attribute. You can see this reflected in the dependency
 graph:
 
-![Dependency graph for `hello-world` displays how the target in the main package
-depends on the target in the `lib`
-package.](/versions/8.3.1/docs/images/cpp-tutorial-stage3.png "Dependency graph for
-`hello-world` displays how the target in the main package depends on the target
-in the `lib` package.")
+![Dependency graph for `hello-world` displays how the target in the main package depends on the target in the `lib` package.](/versions/8.3.1/docs/images/cpp-tutorial-stage3.png "Dependency graph for `hello-world` displays how the target in the main package depends on the target in the `lib` package.")
 
 For the build to succeed, you make the `//lib:hello-time` target in `lib/BUILD`
 explicitly visible to targets in `main/BUILD` using the visibility attribute.
@@ -395,15 +381,11 @@ Bazel journey.
 You've now completed your first basic build with Bazel, but this is just the
 start. Here are some more resources to continue learning with Bazel:
 
-*   To keep focusing on C++, read about common [C++ build use
-    cases](https://bazel.build/tutorials/cpp-use-cases).
+*   To keep focusing on C++, read about common [C++ build use cases](https://bazel.build/versions/8.3.1/tutorials/cpp-use-cases).
 *   To get started with building other applications with Bazel, see the
-    tutorials for [Java](https://bazel.build/versions/8.3.1/start/java), [Android
-    application](https://bazel.build/start/android-app), or [iOS
-    application](https://bazel.build/start/ios-app).
+    tutorials for [Java](https://bazel.build/versions/8.3.1/start/java), [Android application](https://bazel.build/versions/8.3.1/start/android-app), or [iOS application](https://bazel.build/versions/8.3.1/start/ios-app).
 *   To learn more about working with local and remote repositories, read about
     [external dependencies](https://bazel.build/versions/8.3.1/docs/external).
-*   To learn more about Bazel's other rules, see this [reference
-    guide](https://bazel.build/rules).
+*   To learn more about Bazel's other rules, see this [reference guide](https://bazel.build/versions/8.3.1/rules).
 
 Happy building!
\ No newline at end of file
diff --git a/versions/8.3.1/start/java.mdx b/versions/8.3.1/start/java.mdx
index 4ffd1b3d..4f2fb70d 100644
--- a/versions/8.3.1/start/java.mdx
+++ b/versions/8.3.1/start/java.mdx
@@ -241,8 +241,7 @@ recompiles that file.
 Looking at the dependency graph, you can see that `ProjectRunner` depends on the
 same inputs as it did before, but the structure of the build is different:
 
-![Dependency graph of the target 'ProjectRunner' after adding a dependency](
-/docs/images/tutorial_java_02.svg)
+![Dependency graph of the target 'ProjectRunner' after adding a dependency](/versions/8.3.1/docs/images/tutorial_java_02.svg)
 
 You've now built the project with two targets. The `ProjectRunner` target builds
 one source files and depends on one other target (`:greeter`), which builds
@@ -426,7 +425,7 @@ For more details, see:
 *  The [C++ build tutorial](/versions/8.3.1/start/cpp) to get started with building
    C++ projects with Bazel.
 
-*  The [Android application tutorial](/versions/8.3.1/start/android-app ) and
+*  The [Android application tutorial](/versions/8.3.1/start/android-app) and
    [iOS application tutorial](/versions/8.3.1/start/ios-app)) to get started with
    building mobile applications for Android and iOS with Bazel.
 
diff --git a/versions/8.3.1/tutorials/ccp-toolchain-config.mdx b/versions/8.3.1/tutorials/ccp-toolchain-config.mdx
index 55f65877..3f18c66e 100644
--- a/versions/8.3.1/tutorials/ccp-toolchain-config.mdx
+++ b/versions/8.3.1/tutorials/ccp-toolchain-config.mdx
@@ -29,8 +29,7 @@ uses `clang version 16`, which you can install on your system.
 
 Set up your build environment as follows:
 
-1.  If you have not already done so, [download and install Bazel
-    7.0.2](https://bazel.build/install) or later.
+1.  If you have not already done so, [download and install Bazel 7.0.2](https://bazel.build/versions/8.3.1/install) or later.
 
 2.  Add an empty `MODULE.bazel` file at the root folder.
 
@@ -450,8 +449,7 @@ The key takeaways are:
 
 -   You need to specify a matching `platforms` flag in the command line for
     Bazel to resolve to the toolchain for the same constraint values on the
-    platform. The documentation holds more [information about language specific
-    configuration flags](/versions/8.3.1/concepts/platforms).
+    platform. The documentation holds more [information about language specific configuration flags](/versions/8.3.1/concepts/platforms).
 -   You have to let the toolchain know where the tools live. In this tutorial
     there is a simplified version where you access the tools from the system. If
     you are interested in a more self-contained approach, you can read about
@@ -464,5 +462,4 @@ The key takeaways are:
 
 ## Further reading {#further-reading}
 
-For more details, see [C++ toolchain
-configuration](/versions/8.3.1/docs/cc-toolchain-config-reference)
\ No newline at end of file
+For more details, see [C++ toolchain configuration](/versions/8.3.1/docs/cc-toolchain-config-reference)
\ No newline at end of file
diff --git a/versions/8.4.2/about/roadmap.mdx b/versions/8.4.2/about/roadmap.mdx
index 285b97e1..770f9958 100644
--- a/versions/8.4.2/about/roadmap.mdx
+++ b/versions/8.4.2/about/roadmap.mdx
@@ -13,8 +13,7 @@ projects.
 
 ## Bazel 8.0 Release
 
-We plan to bring Bazel 8.0 [long term support
-(LTS)](https://bazel.build/release/versioning) to you in late 2024.
+We plan to bring Bazel 8.0 [long term support (LTS)](https://bazel.build/versions/8.4.2/release/versioning) to you in late 2024.
 The following features are planned to be implemented.
 
 ### Bzlmod: external dependency management system
@@ -29,8 +28,7 @@ support will be removed. Starting with Bazel 7.1, you can set
 `--noenable_workspace` to opt into the new behavior.
 
 Bazel 8.0 will contain a number of enhancements to
-[Bazel's external dependency management]
-(https://docs.google.com/document/d/1moQfNcEIttsk6vYanNKIy3ZuK53hQUFq1b1r0rmsYVg/edit#heading=h.lgyp7ubwxmjc)
+[Bazel's external dependency management](https://docs.google.com/document/d/1moQfNcEIttsk6vYanNKIy3ZuK53hQUFq1b1r0rmsYVg/edit#heading=h.lgyp7ubwxmjc)
 functionality, including:
 
 *   The new flag `--enable_workspace` can be set to `false` to completely
diff --git a/versions/8.4.2/basics/dependencies.mdx b/versions/8.4.2/basics/dependencies.mdx
index df852d50..f7512b07 100644
--- a/versions/8.4.2/basics/dependencies.mdx
+++ b/versions/8.4.2/basics/dependencies.mdx
@@ -65,8 +65,7 @@ targets, we’ve made some strides in mitigating the downside by investing in
 tooling to automatically manage `BUILD` files to avoid burdening developers.
 
 Some of these tools, such as `buildifier` and `buildozer`, are available with
-Bazel in the [`buildtools`
-directory](https://github.com/bazelbuild/buildtools).
+Bazel in the [`buildtools` directory](https://github.com/bazelbuild/buildtools).
 
 ## Minimizing Module Visibility
 
@@ -106,8 +105,7 @@ transitive dependencies (Figure 1). Suppose target A depends on target B, which
 depends on a common library target C. Should target A be able to use classes
 defined in target C?
 
-[![Transitive
-dependencies](/versions/8.4.2/images/transitive-dependencies.png)](/versions/8.4.2/images/transitive-dependencies.png)
+[![Transitive dependencies](/versions/8.4.2/images/transitive-dependencies.png)](/versions/8.4.2/images/transitive-dependencies.png)
 
 **Figure 1**. Transitive dependencies
 
@@ -141,9 +139,7 @@ dependencies and adding them to a `BUILD` files without any developer
 intervention. But even without such tools, we’ve found the trade-off to be well
 worth it as the codebase scales: explicitly adding a dependency to `BUILD` file
 is a one-time cost, but dealing with implicit transitive dependencies can cause
-ongoing problems as long as the build target exists. Bazel [enforces strict
-transitive
-dependencies](https://blog.bazel.build/2017/06/28/sjd-unused_deps.html)
+ongoing problems as long as the build target exists. Bazel [enforces strict transitive dependencies](https://blog.bazel.build/2017/06/28/sjd-unused_deps.html)
 on Java code by default.
 
 ### External dependencies
@@ -192,8 +188,7 @@ so in theory there’s no reason that different versions of the same external
 dependency couldn’t both be declared in the build system under different names.
 That way, each target could choose which version of the dependency it wanted to
 use. This causes a lot of problems in practice, so Google enforces a strict
-[One-Version
-Rule](https://opensource.google/docs/thirdparty/oneversion/) for
+[One-Version Rule](https://opensource.google/docs/thirdparty/oneversion/) for
 all third-party dependencies in our codebase.
 
 The biggest problem with allowing multiple versions is the diamond dependency
@@ -232,8 +227,7 @@ Bazel did not use to automatically download transitive dependencies. It used to
 employ a `WORKSPACE` file that required all transitive dependencies to be
 listed, which led to a lot of pain when managing external dependencies. Bazel
 has since added support for automatic transitive external dependency management
-in the form of the `MODULE.bazel` file. See [external dependency
-overview](/versions/8.4.2/external/overview) for more details.
+in the form of the `MODULE.bazel` file. See [external dependency overview](/versions/8.4.2/external/overview) for more details.
 
 Yet again, the choice here is one between convenience and scalability. Small
 projects might prefer not having to worry about managing transitive dependencies
diff --git a/versions/8.4.2/community/images/Bitrise.png b/versions/8.4.2/community/images/Bitrise.png
new file mode 100644
index 00000000..07f85f1e
Binary files /dev/null and b/versions/8.4.2/community/images/Bitrise.png differ
diff --git a/versions/8.4.2/community/images/Gradle.png b/versions/8.4.2/community/images/Gradle.png
new file mode 100644
index 00000000..1e5f5eb0
Binary files /dev/null and b/versions/8.4.2/community/images/Gradle.png differ
diff --git a/versions/8.4.2/community/images/Linkedin-Logo.png b/versions/8.4.2/community/images/Linkedin-Logo.png
new file mode 100644
index 00000000..9dd8715c
Binary files /dev/null and b/versions/8.4.2/community/images/Linkedin-Logo.png differ
diff --git a/versions/8.4.2/community/images/Lucid_Software-logo.svg b/versions/8.4.2/community/images/Lucid_Software-logo.svg
new file mode 100644
index 00000000..6c8591e0
--- /dev/null
+++ b/versions/8.4.2/community/images/Lucid_Software-logo.svg
@@ -0,0 +1,16 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/versions/8.4.2/community/images/acqio_logo.svg b/versions/8.4.2/community/images/acqio_logo.svg
new file mode 100644
index 00000000..8fa11bcd
--- /dev/null
+++ b/versions/8.4.2/community/images/acqio_logo.svg
@@ -0,0 +1,60 @@
+
+
+
+
+
+	
+		
+			
+				
+					
+					
+					
+					
+					
+				
+				
+					
+						
+							
+								
+							
+						
+					
+				
+				
+					
+						
+							
+								
+							
+						
+					
+				
+			
+		
+	
+
+
diff --git a/versions/8.4.2/community/images/aspect-logo-2.png b/versions/8.4.2/community/images/aspect-logo-2.png
new file mode 100644
index 00000000..dfebc4cb
Binary files /dev/null and b/versions/8.4.2/community/images/aspect-logo-2.png differ
diff --git a/versions/8.4.2/community/images/bitrise-logo.png b/versions/8.4.2/community/images/bitrise-logo.png
new file mode 100644
index 00000000..27037ce6
Binary files /dev/null and b/versions/8.4.2/community/images/bitrise-logo.png differ
diff --git a/versions/8.4.2/community/images/buildbuddy-logo.svg b/versions/8.4.2/community/images/buildbuddy-logo.svg
new file mode 100644
index 00000000..bdb72dc6
--- /dev/null
+++ b/versions/8.4.2/community/images/buildbuddy-logo.svg
@@ -0,0 +1,11 @@
+
+
+
+
+
+
+
+
+
+
+
diff --git a/versions/8.4.2/community/images/buildkite.svg b/versions/8.4.2/community/images/buildkite.svg
new file mode 100644
index 00000000..209a4ab1
--- /dev/null
+++ b/versions/8.4.2/community/images/buildkite.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/8.4.2/community/images/codethink-logo.svg b/versions/8.4.2/community/images/codethink-logo.svg
new file mode 100644
index 00000000..406005d8
--- /dev/null
+++ b/versions/8.4.2/community/images/codethink-logo.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/8.4.2/community/images/develocity.png b/versions/8.4.2/community/images/develocity.png
new file mode 100644
index 00000000..eb3eb65a
Binary files /dev/null and b/versions/8.4.2/community/images/develocity.png differ
diff --git a/versions/8.4.2/community/images/dropbox.png b/versions/8.4.2/community/images/dropbox.png
new file mode 100644
index 00000000..125476a6
Binary files /dev/null and b/versions/8.4.2/community/images/dropbox.png differ
diff --git a/versions/8.4.2/community/images/engflow-logo.svg b/versions/8.4.2/community/images/engflow-logo.svg
new file mode 100644
index 00000000..e5f0c343
--- /dev/null
+++ b/versions/8.4.2/community/images/engflow-logo.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/8.4.2/community/images/epam-logo.png b/versions/8.4.2/community/images/epam-logo.png
new file mode 100644
index 00000000..e6a5674c
Binary files /dev/null and b/versions/8.4.2/community/images/epam-logo.png differ
diff --git a/versions/8.4.2/community/images/flare-logo.png b/versions/8.4.2/community/images/flare-logo.png
new file mode 100644
index 00000000..84cb0e5b
Binary files /dev/null and b/versions/8.4.2/community/images/flare-logo.png differ
diff --git a/versions/8.4.2/community/images/hermetiq-logo.png b/versions/8.4.2/community/images/hermetiq-logo.png
new file mode 100644
index 00000000..90765d96
Binary files /dev/null and b/versions/8.4.2/community/images/hermetiq-logo.png differ
diff --git a/versions/8.4.2/community/images/jetbrains.svg b/versions/8.4.2/community/images/jetbrains.svg
new file mode 100644
index 00000000..cb3a2a0e
--- /dev/null
+++ b/versions/8.4.2/community/images/jetbrains.svg
@@ -0,0 +1,13 @@
+
+  
+    
+      
+      
+      
+    
+  
+  
+  
+  
+  
+
diff --git a/versions/8.4.2/community/images/liulishuo.png b/versions/8.4.2/community/images/liulishuo.png
new file mode 100644
index 00000000..a6758e5c
Binary files /dev/null and b/versions/8.4.2/community/images/liulishuo.png differ
diff --git a/versions/8.4.2/community/images/nativelink.svg b/versions/8.4.2/community/images/nativelink.svg
new file mode 100644
index 00000000..148fcdce
--- /dev/null
+++ b/versions/8.4.2/community/images/nativelink.svg
@@ -0,0 +1,1123 @@
+
+
+  
+    
+    
+      
+      
+    
+    
+      
+      
+    
+    
+    
+      
+      
+    
+    
+      
+      
+      
+      
+      
+      
+      
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+      
+      
+    
+    
+    
+    
+      
+      
+    
+    
+    
+    
+      
+      
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+      
+      
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+      
+      
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+      
+      
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+      
+      
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+      
+      
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+      
+      
+    
+  
+  
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+  
+  
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+  
+
diff --git a/versions/8.4.2/community/images/oasis-logo.png b/versions/8.4.2/community/images/oasis-logo.png
new file mode 100644
index 00000000..846a9cd5
Binary files /dev/null and b/versions/8.4.2/community/images/oasis-logo.png differ
diff --git a/versions/8.4.2/community/images/sumglobal-logo.png b/versions/8.4.2/community/images/sumglobal-logo.png
new file mode 100644
index 00000000..6736328d
Binary files /dev/null and b/versions/8.4.2/community/images/sumglobal-logo.png differ
diff --git a/versions/8.4.2/community/images/trunk-logo-dark.svg b/versions/8.4.2/community/images/trunk-logo-dark.svg
new file mode 100644
index 00000000..f25940af
--- /dev/null
+++ b/versions/8.4.2/community/images/trunk-logo-dark.svg
@@ -0,0 +1,22 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/versions/8.4.2/community/images/tweag-logo.png b/versions/8.4.2/community/images/tweag-logo.png
new file mode 100644
index 00000000..20210ed7
Binary files /dev/null and b/versions/8.4.2/community/images/tweag-logo.png differ
diff --git a/versions/8.4.2/community/images/typedb.png b/versions/8.4.2/community/images/typedb.png
new file mode 100644
index 00000000..48ce1056
Binary files /dev/null and b/versions/8.4.2/community/images/typedb.png differ
diff --git a/versions/8.4.2/community/images/virtuslab.svg b/versions/8.4.2/community/images/virtuslab.svg
new file mode 100644
index 00000000..6fba0316
--- /dev/null
+++ b/versions/8.4.2/community/images/virtuslab.svg
@@ -0,0 +1,20 @@
+
+
+  
+    
+  
+  
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+  
+
diff --git a/versions/8.4.2/community/roadmaps-configurability.mdx b/versions/8.4.2/community/roadmaps-configurability.mdx
index 70069a49..bdd4be8e 100644
--- a/versions/8.4.2/community/roadmaps-configurability.mdx
+++ b/versions/8.4.2/community/roadmaps-configurability.mdx
@@ -26,8 +26,7 @@ title: 'Bazel Configurability 2021 Roadmap'
 * Builds scale well, particularly w.r.t graph size and action caching.
 
 We also support
-[`cquery`](https://bazel.build/versions/8.4.2/query/cquery), [`Starlark
-configuration`](https://bazel.build/extending/config),
+[`cquery`](https://bazel.build/versions/8.4.2/query/cquery), [`Starlark configuration`](https://bazel.build/versions/8.4.2/extending/config),
 and
 [`select()`](https://bazel.build/versions/8.4.2/docs/configurable-attributes).
 
@@ -41,15 +40,13 @@ interest of accurate expectations.
 ### Platforms
 
 

-Q3 2021**Android rules use the new [platforms
-API](https://bazel.build/concepts/platforms)**
+Q3 2021**Android rules use the new [platforms API](https://bazel.build/versions/8.4.2/concepts/platforms)**
 IN PROGRESS ([#11749](https://github.com/bazelbuild/bazel/issues/11749))
 
 * This is our main priority for the beginning of 2021.
 
 

-Q3 2021**Builds support [multiple execution
-platforms](https://docs.google.com/document/d/1U9HzdDmtRnm244CaRM6JV-q2408mbNODAMewcGjnnbM/)**
+Q3 2021**Builds support [multiple execution platforms](https://docs.google.com/document/d/1U9HzdDmtRnm244CaRM6JV-q2408mbNODAMewcGjnnbM/)**
 IN PROGRESS ([#11748](https://github.com/bazelbuild/bazel/issues/11748))
 
 

diff --git a/versions/8.4.2/community/sig.mdx b/versions/8.4.2/community/sig.mdx
index 83e5be51..ef361188 100644
--- a/versions/8.4.2/community/sig.mdx
+++ b/versions/8.4.2/community/sig.mdx
@@ -3,8 +3,7 @@ title: 'Bazel Special Interest Groups'
 ---
 
 Bazel hosts Special Interest Groups (SIGs) to focus collaboration on particular
-areas and to support communication and coordination between [Bazel owners,
-maintainers, and contributors](/versions/8.4.2/contribute/policy). This policy
+areas and to support communication and coordination between [Bazel owners, maintainers, and contributors](/versions/8.4.2/contribute/policy). This policy
 applies to [`bazelbuild`](http://github.com/bazelbuild).
 
 SIGs do their work in public. The ideal scope for a SIG covers a well-defined
diff --git a/versions/8.4.2/community/users.mdx b/versions/8.4.2/community/users.mdx
index c2a62677..70d3c436 100644
--- a/versions/8.4.2/community/users.mdx
+++ b/versions/8.4.2/community/users.mdx
@@ -304,11 +304,9 @@ safety systems_.
 Pigweed is an open-source solution for sustained, robust, and rapid embedded
 product development for large teams. Pigweed has shipped in millions of
 devices, including Google's suite of Pixel devices, Nest thermostats,
-[satellites](https://www.spinlaunch.com/), and [autonomous aerial
-drones](https://www.flyzipline.com/).
+[satellites](https://www.spinlaunch.com/), and [autonomous aerial drones](https://www.flyzipline.com/).
 
-Pigweed [uses Bazel as its primary build
-system](https://pigweed.dev/seed/0111-build-systems.html). The [Bazel for
+Pigweed [uses Bazel as its primary build system](https://pigweed.dev/seed/0111-build-systems.html). The [Bazel for
 Embedded][pw-bazel-great] blog post discusses why we think it's a great build
 system for embedded projects!
 
diff --git a/versions/8.4.2/concepts/build-ref.mdx b/versions/8.4.2/concepts/build-ref.mdx
index 166fe41d..28d423fb 100644
--- a/versions/8.4.2/concepts/build-ref.mdx
+++ b/versions/8.4.2/concepts/build-ref.mdx
@@ -17,8 +17,7 @@ its root; such a boundary marker file could be `MODULE.bazel`, `REPO.bazel`, or
 in legacy contexts, `WORKSPACE` or `WORKSPACE.bazel`.
 
 The repo in which the current Bazel command is being run is called the _main
-repo_. Other, (external) repos are defined by _repo rules_; see [external
-dependencies overview](/versions/8.4.2/external/overview) for more information.
+repo_. Other, (external) repos are defined by _repo rules_; see [external dependencies overview](/versions/8.4.2/external/overview) for more information.
 
 ## Workspace {#workspace}
 
@@ -95,5 +94,4 @@ have three properties: the list of packages they contain, their name, and other
 package groups they include. The only allowed ways to refer to them are from the
 `visibility` attribute of rules or from the `default_visibility` attribute of
 the `package` function; they do not generate or consume files. For more
-information, refer to the [`package_group`
-documentation](/versions/8.4.2/reference/be/functions#package_group).
+information, refer to the [`package_group` documentation](/versions/8.4.2/reference/be/functions#package_group).
diff --git a/versions/8.4.2/concepts/labels.mdx b/versions/8.4.2/concepts/labels.mdx
index 34f013f7..66585828 100644
--- a/versions/8.4.2/concepts/labels.mdx
+++ b/versions/8.4.2/concepts/labels.mdx
@@ -10,8 +10,7 @@ form looks like:
 ```
 
 The first part of the label is the repository name, `@@myrepo`. The double-`@`
-syntax signifies that this is a [*canonical* repo
-name](/versions/8.4.2/external/overview#canonical-repo-name), which is unique within
+syntax signifies that this is a [*canonical* repo name](/versions/8.4.2/external/overview#canonical-repo-name), which is unique within
 the workspace. Labels with canonical repo names unambiguously identify a target
 no matter which context they appear in.
 
diff --git a/versions/8.4.2/concepts/platforms.mdx b/versions/8.4.2/concepts/platforms.mdx
index 6d6af144..625434bf 100644
--- a/versions/8.4.2/concepts/platforms.mdx
+++ b/versions/8.4.2/concepts/platforms.mdx
@@ -77,8 +77,7 @@ To test your Android project with platforms, see
 for support.
 
 You can still use platform APIs with Apple builds (for example, when building
-with a mixture of Apple rules and pure C++) with [platform
-mappings](#platform-mappings).
+with a mixture of Apple rules and pure C++) with [platform mappings](#platform-mappings).
 
 ### Other languages {#other-languages}
 
@@ -241,8 +240,7 @@ sets `--cpu`, `--crossstool_top`, or other legacy flags, rules that read
 
 When migrating your project to platforms, you must either convert changes like
 `return { "//command_line_option:cpu": "arm" }` to `return {
-"//command_line_option:platforms": "//:my_arm_platform" }` or use [platform
-mappings](#platform-mappings) to support both styles during migration.
+"//command_line_option:platforms": "//:my_arm_platform" }` or use [platform mappings](#platform-mappings) to support both styles during migration.
 window.
 
 ## Migrating your rule set {#migrating-your-rule-set}
@@ -361,10 +359,8 @@ attributes declare a language's tools (like `compiler =
 this information to rules that need to build with these tools.
 
 Toolchains declare the `constraint_value`s of machines they can
-[target][target_compatible_with Attribute]
-(`target_compatible_with = ["@platforms//os:linux"]`) and machines their tools can
-[run on][exec_compatible_with Attribute]
-(`exec_compatible_with = ["@platforms//os:mac"]`).
+[target][target_compatible_with Attribute](`target_compatible_with = ["@platforms//os:linux"]`) and machines their tools can
+[run on][exec_compatible_with Attribute](`exec_compatible_with = ["@platforms//os:mac"]`).
 
 When building `$ bazel build //:myproject --platforms=//:myplatform`, Bazel
 automatically selects a toolchain that can run on the build machine and
diff --git a/versions/8.4.2/configure/attributes.mdx b/versions/8.4.2/configure/attributes.mdx
index aa431fae..4b70c4b2 100644
--- a/versions/8.4.2/configure/attributes.mdx
+++ b/versions/8.4.2/configure/attributes.mdx
@@ -2,8 +2,7 @@
 title: 'Configurable Build Attributes'
 ---
 
-**_Configurable attributes_**, commonly known as [`select()`](
-/reference/be/functions#select), is a Bazel feature that lets users toggle the values
+**_Configurable attributes_**, commonly known as [`select()`](/versions/8.4.2/reference/be/functions#select), is a Bazel feature that lets users toggle the values
 of build rule attributes at the command line.
 
 This can be used, for example, for a multiplatform library that automatically
@@ -407,8 +406,7 @@ sh_library(
 )
 ```
 
-If you need a `select` to match when multiple conditions match, consider [AND
-chaining](#and-chaining).
+If you need a `select` to match when multiple conditions match, consider [AND chaining](#and-chaining).
 
 ## OR chaining {#or-chaining}
 
diff --git a/versions/8.4.2/configure/integrate-cpp.mdx b/versions/8.4.2/configure/integrate-cpp.mdx
index 5d7c4284..45a456cc 100644
--- a/versions/8.4.2/configure/integrate-cpp.mdx
+++ b/versions/8.4.2/configure/integrate-cpp.mdx
@@ -33,8 +33,7 @@ This is because when writing our own actions, they must behave
 consistently with the C++ toolchain - for example, passing C++ command line
 flags to a tool that invokes the C++ compiler behind the scenes.
 
-C++ rules use a special way of constructing command lines based on [feature
-configuration](/versions/8.4.2/docs/cc-toolchain-config-reference). To construct a command line,
+C++ rules use a special way of constructing command lines based on [feature configuration](/versions/8.4.2/docs/cc-toolchain-config-reference). To construct a command line,
 you need the following:
 
 * `features` and `action_configs` - these come from the `CcToolchainConfigInfo`
diff --git a/versions/8.4.2/configure/windows.mdx b/versions/8.4.2/configure/windows.mdx
index 075dc0a3..5f2a69f5 100644
--- a/versions/8.4.2/configure/windows.mdx
+++ b/versions/8.4.2/configure/windows.mdx
@@ -166,8 +166,7 @@ To build C++ targets with MSVC, you need:
         set BAZEL_VC=C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC
         ```
 
-*   The [Windows
-    SDK](https://developer.microsoft.com/en-us/windows/downloads/windows-10-sdk).
+*   The [Windows SDK](https://developer.microsoft.com/en-us/windows/downloads/windows-10-sdk).
 
     The Windows SDK contains header files and libraries you need when building
     Windows applications, including Bazel itself. By default, the latest Windows SDK installed will
@@ -186,8 +185,7 @@ To build C++ targets with MSVC, you need:
 
 If everything is set up, you can build a C++ target now!
 
-Try building a target from one of our [sample
-projects](https://github.com/bazelbuild/bazel/tree/master/examples):
+Try building a target from one of our [sample projects](https://github.com/bazelbuild/bazel/tree/master/examples):
 
 
 
 
-To build and use Dynamically Linked Libraries (DLL files), see [this
-example](https://github.com/bazelbuild/bazel/tree/master/examples/windows/dll).
+To build and use Dynamically Linked Libraries (DLL files), see [this example](https://github.com/bazelbuild/bazel/tree/master/examples/windows/dll).
 
 **Command Line Length Limit**: To prevent the
 [Windows command line length limit issue](https://github.com/bazelbuild/bazel/issues/5163),
@@ -292,8 +289,7 @@ On Windows, Bazel builds two output files for `java_binary` rules:
 *   a `.jar` file
 *   a `.exe` file that can set up the environment for the JVM and run the binary
 
-Try building a target from one of our [sample
-projects](https://github.com/bazelbuild/bazel/tree/master/examples):
+Try building a target from one of our [sample projects](https://github.com/bazelbuild/bazel/tree/master/examples):
 
 
   
   
 
 If you are interested in details about how Bazel builds Python targets on
-Windows, check out this [design
-doc](https://github.com/bazelbuild/bazel-website/blob/master/designs/_posts/2016-09-05-build-python-on-windows.md).
+Windows, check out this [design doc](https://github.com/bazelbuild/bazel-website/blob/master/designs/_posts/2016-09-05-build-python-on-windows.md).
diff --git a/versions/8.4.2/contribute/breaking-changes.mdx b/versions/8.4.2/contribute/breaking-changes.mdx
index 62de8261..a0e8d379 100644
--- a/versions/8.4.2/contribute/breaking-changes.mdx
+++ b/versions/8.4.2/contribute/breaking-changes.mdx
@@ -67,7 +67,7 @@ should contain the URL of the GitHub issue. As the flag name starts with
 ```
 
 In the commit description, add a brief summary of the flag.
-Also add [`RELNOTES:`](release-notes.md) in the following form:
+Also add [`RELNOTES:`](/versions/8.4.2/contribute/release-notes) in the following form:
 `RELNOTES: --incompatible_name_of_flag has been added. See #xyz for details`
 
 The commit should also update the relevant documentation, so that there is no
diff --git a/versions/8.4.2/contribute/codebase.mdx b/versions/8.4.2/contribute/codebase.mdx
index ceb6f7aa..0dee2a09 100644
--- a/versions/8.4.2/contribute/codebase.mdx
+++ b/versions/8.4.2/contribute/codebase.mdx
@@ -227,8 +227,7 @@ repository", the others are called "external repositories".
 A repository is marked by a repo boundary file (`MODULE.bazel`, `REPO.bazel`, or
 in legacy contexts, `WORKSPACE` or `WORKSPACE.bazel`) in its root directory. The
 main repo is the source tree where you're invoking Bazel from. External repos
-are defined in various ways; see [external dependencies
-overview](/versions/8.4.2/external/overview) for more information.
+are defined in various ways; see [external dependencies overview](/versions/8.4.2/external/overview) for more information.
 
 Code of external repositories is symlinked or downloaded under
 `$OUTPUT_BASE/external`.
diff --git a/versions/8.4.2/contribute/design-documents.mdx b/versions/8.4.2/contribute/design-documents.mdx
index 888258f8..49e3f377 100644
--- a/versions/8.4.2/contribute/design-documents.mdx
+++ b/versions/8.4.2/contribute/design-documents.mdx
@@ -25,7 +25,7 @@ Here are some examples of significant changes:
 When you write a design document, you can coordinate with other Bazel developers
 and seek guidance from Bazel's core team. For example, when a proposal adds,
 removes, or modifies any function or object available in BUILD, MODULE.bazel, or
-bzl files, add the [Starlark team](maintainers-guide.md) as reviewers.
+bzl files, add the [Starlark team](/versions/8.4.2/contribute/maintainers-guide) as reviewers.
 Design documents are reviewed before submission because:
 
 *   Bazel is a very complex system; seemingly innocuous local changes can have
@@ -137,8 +137,7 @@ A lead reviewer should be a domain expert who is:
 *   Objective and capable of providing constructive feedback
 *   Available for the entire review period to lead the process
 
-Consider checking the contacts for various [team
-labels](/versions/8.4.2/contribute/maintainers-guide#team-labels).
+Consider checking the contacts for various [team labels](/versions/8.4.2/contribute/maintainers-guide#team-labels).
 
 ## Markdown vs Google Docs {#markdown-versus-gdocs}
 
@@ -168,12 +167,10 @@ Markdown for posterity.
 
 ### Using Google Docs {#gdocs}
 
-For consistency, use the [Bazel design doc template](
-https://docs.google.com/document/d/1cE5zrjrR40RXNg64XtRFewSv6FrLV6slGkkqxBumS1w/edit).
+For consistency, use the [Bazel design doc template](https://docs.google.com/document/d/1cE5zrjrR40RXNg64XtRFewSv6FrLV6slGkkqxBumS1w/edit).
 It includes the necessary header and creates visual
 consistency with other Bazel related documents. To do that, click on **File** >
-**Make a copy** or click this link to [make a copy of the design doc
-template](https://docs.google.com/document/d/1cE5zrjrR40RXNg64XtRFewSv6FrLV6slGkkqxBumS1w/copy).
+**Make a copy** or click this link to [make a copy of the design doc template](https://docs.google.com/document/d/1cE5zrjrR40RXNg64XtRFewSv6FrLV6slGkkqxBumS1w/copy).
 
 To make your document readable to the world, click on
 **Share** > **Advanced** > **Change…**, and
diff --git a/versions/8.4.2/contribute/images/structured-concurrency-3d.svg b/versions/8.4.2/contribute/images/structured-concurrency-3d.svg
new file mode 100644
index 00000000..accbb42a
--- /dev/null
+++ b/versions/8.4.2/contribute/images/structured-concurrency-3d.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/8.4.2/contribute/images/structured-concurrency.svg b/versions/8.4.2/contribute/images/structured-concurrency.svg
new file mode 100644
index 00000000..0258d9a9
--- /dev/null
+++ b/versions/8.4.2/contribute/images/structured-concurrency.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/8.4.2/contribute/images/suspend-resume.svg b/versions/8.4.2/contribute/images/suspend-resume.svg
new file mode 100644
index 00000000..7de1218f
--- /dev/null
+++ b/versions/8.4.2/contribute/images/suspend-resume.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/8.4.2/contribute/images/unstructured-concurrency.svg b/versions/8.4.2/contribute/images/unstructured-concurrency.svg
new file mode 100644
index 00000000..0951639a
--- /dev/null
+++ b/versions/8.4.2/contribute/images/unstructured-concurrency.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/8.4.2/contribute/index.mdx b/versions/8.4.2/contribute/index.mdx
index 70cce39a..94927d21 100644
--- a/versions/8.4.2/contribute/index.mdx
+++ b/versions/8.4.2/contribute/index.mdx
@@ -10,8 +10,7 @@ As you use Bazel, you may find things that can be improved.
 You can help by [reporting issues](http://github.com/bazelbuild/bazel/issues)
 when:
 
-   - Bazel crashes or you encounter a bug that can [only be resolved using `bazel
-     clean`](/versions/8.4.2/run/build#correct-incremental-rebuilds).
+   - Bazel crashes or you encounter a bug that can [only be resolved using `bazel clean`](/versions/8.4.2/run/build#correct-incremental-rebuilds).
    - The documentation is incomplete or unclear. You can also report issues
      from the page you are viewing by using the "Create issue"
      link at the top right corner of the page.
@@ -21,11 +20,9 @@ when:
 
 You can engage with the Bazel community by:
 
-   - Answering questions [on Stack Overflow](
-     https://stackoverflow.com/questions/tagged/bazel).
+   - Answering questions [on Stack Overflow](https://stackoverflow.com/questions/tagged/bazel).
    - Helping other users [on Slack](https://slack.bazel.build).
-   - Improving documentation or [contributing examples](
-     https://github.com/bazelbuild/examples).
+   - Improving documentation or [contributing examples](https://github.com/bazelbuild/examples).
    - Sharing your experience or your tips, for example, on a blog or social media.
 
 ## Contribute code {#contribute-code}
@@ -40,8 +37,7 @@ You can contribute to the Bazel ecosystem by:
    - Contributing to Bazel-related tools, for example, migration tools.
    - Improving Bazel integration with other IDEs and tools.
 
-Before making a change, [create a GitHub
-issue](http://github.com/bazelbuild/bazel/issues)
+Before making a change, [create a GitHub issue](http://github.com/bazelbuild/bazel/issues)
 or email [bazel-discuss@](mailto:bazel-discuss@googlegroups.com).
 
 The most helpful contributions fix bugs or add features (as opposed
diff --git a/versions/8.4.2/contribute/maintainers-guide.mdx b/versions/8.4.2/contribute/maintainers-guide.mdx
index a5799174..bd281f83 100644
--- a/versions/8.4.2/contribute/maintainers-guide.mdx
+++ b/versions/8.4.2/contribute/maintainers-guide.mdx
@@ -4,8 +4,7 @@ title: 'Guide for Bazel Maintainers'
 
 This is a guide for the maintainers of the Bazel open source project.
 
-If you are looking to contribute to Bazel, please read [Contributing to
-Bazel](/versions/8.4.2/contribute) instead.
+If you are looking to contribute to Bazel, please read [Contributing to Bazel](/versions/8.4.2/contribute) instead.
 
 The objectives of this page are to:
 
@@ -37,8 +36,7 @@ repository.
 
 1. A user creates an issue by choosing one of the
 [issue templates](https://github.com/bazelbuild/bazel/issues/new/choose)
-   and it enters the pool of [unreviewed open
-   issues](https://github.com/bazelbuild/bazel/issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aopen+-label%3Auntriaged+-label%3Ap2+-label%3Ap1+-label%3Ap3+-label%3Ap4+-label%3Ateam-Starlark+-label%3Ateam-Rules-CPP+-label%3Ateam-Rules-Java+-label%3Ateam-XProduct+-label%3Ateam-Android+-label%3Ateam-Apple+-label%3Ateam-Configurability++-label%3Ateam-Performance+-label%3Ateam-Rules-Server+-label%3Ateam-Core+-label%3Ateam-Rules-Python+-label%3Ateam-Remote-Exec+-label%3Ateam-Local-Exec+-label%3Ateam-Bazel).
+   and it enters the pool of [unreviewed open issues](https://github.com/bazelbuild/bazel/issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aopen+-label%3Auntriaged+-label%3Ap2+-label%3Ap1+-label%3Ap3+-label%3Ap4+-label%3Ateam-Starlark+-label%3Ateam-Rules-CPP+-label%3Ateam-Rules-Java+-label%3Ateam-XProduct+-label%3Ateam-Android+-label%3Ateam-Apple+-label%3Ateam-Configurability++-label%3Ateam-Performance+-label%3Ateam-Rules-Server+-label%3Ateam-Core+-label%3Ateam-Rules-Python+-label%3Ateam-Remote-Exec+-label%3Ateam-Local-Exec+-label%3Ateam-Bazel).
 1. A member on the Developer Experience (DevEx) subteam rotation reviews the
    issue.
    1. If the issue is **not a bug** or a **feature request**, the DevEx member
@@ -58,21 +56,18 @@ repository.
 1. After reviewing the issue, the DevEx member decides if the issue requires
    immediate attention. If it does, they will assign the **P0**
    [priority](#priority) label and an owner from the list of team leads.
-1. The DevEx member assigns the `untriaged` label and exactly one [team
-   label](#team-labels) for routing.
+1. The DevEx member assigns the `untriaged` label and exactly one [team label](#team-labels) for routing.
 1. The DevEx member also assigns exactly one `type:` label, such as `type: bug`
    or `type: feature request`, according to the type of the issue.
 1. For platform-specific issues, the DevEx member assigns one `platform:` label,
    such as `platform:apple` for Mac-specific issues.
 1. If the issue is low priority and can be worked on by a new community
    contributor, the DevEx member assigns the `good first issue` label.
-At this stage, the issue enters the pool of [untriaged open
-issues](https://github.com/bazelbuild/bazel/issues?q=is%3Aissue+is%3Aopen+label%3Auntriaged).
+At this stage, the issue enters the pool of [untriaged open issues](https://github.com/bazelbuild/bazel/issues?q=is%3Aissue+is%3Aopen+label%3Auntriaged).
 
 Each Bazel subteam will triage all issues under labels they own, preferably on a
 weekly basis. The subteam will review and evaluate the issue and provide a
-resolution, if possible. If you are an owner of a team label, see [this section
-](#label-own) for more information.
+resolution, if possible. If you are an owner of a team label, see [this section](#label-own) for more information.
 
 When an issue is resolved, it can be closed.
 
@@ -111,8 +106,7 @@ preferably on a weekly basis.
      issue is either P0 or P1 we assume that is actively worked on.
 1. Remove the `untriaged` label.
 
-Note that you need to be in the [bazelbuild
-organization](https://github.com/bazelbuild) to be able to add or remove labels.
+Note that you need to be in the [bazelbuild organization](https://github.com/bazelbuild) to be able to add or remove labels.
 
 ### Pull Requests {#pull-requests}
 
@@ -138,8 +132,7 @@ issues.
   unusable, or a downed service that severely impacts development of the Bazel
   project. This includes regressions introduced in a new release that blocks a
   significant number of users, or an incompatible breaking change that was not
-  compliant to the [Breaking
-  Change](https://docs.google.com/document/d/1q5GGRxKrF_mnwtaPKI487P8OdDRh2nN7jX6U-FXnHL0/edit?pli=1#heading=h.ceof6vpkb3ik)
+  compliant to the [Breaking Change](https://docs.google.com/document/d/1q5GGRxKrF_mnwtaPKI487P8OdDRh2nN7jX6U-FXnHL0/edit?pli=1#heading=h.ceof6vpkb3ik)
   policy. No practical workaround exists.
 * [**P1**](https://github.com/bazelbuild/bazel/labels/P1) - Critical defect or
   feature which should be addressed in the next release, or a serious issue that
diff --git a/versions/8.4.2/contribute/naming.mdx b/versions/8.4.2/contribute/naming.mdx
index 1c2fd0de..d18cd8f5 100644
--- a/versions/8.4.2/contribute/naming.mdx
+++ b/versions/8.4.2/contribute/naming.mdx
@@ -4,8 +4,7 @@ title: 'Naming a Bazel related project'
 
 First, thank you for contributing to the Bazel ecosystem! Please reach out to
 the Bazel community on the
-[bazel-discuss mailing list](https://groups.google.com/forum/#!forum/bazel-discuss
-) to share your project and its suggested name.
+[bazel-discuss mailing list](https://groups.google.com/forum/#!forum/bazel-discuss) to share your project and its suggested name.
 
 If you are building a Bazel related tool or sharing your Skylark rules,
 we recommend following these guidelines for the name of your project:
diff --git a/versions/8.4.2/contribute/patch-acceptance.mdx b/versions/8.4.2/contribute/patch-acceptance.mdx
index 1bad7123..abfec71e 100644
--- a/versions/8.4.2/contribute/patch-acceptance.mdx
+++ b/versions/8.4.2/contribute/patch-acceptance.mdx
@@ -11,29 +11,24 @@ code base.
    need a corresponding issue for tracking.
 1. If you're proposing significant changes, write a
    [design document](/versions/8.4.2/contribute/design-documents).
-1. Ensure you've signed a [Contributor License
-   Agreement](https://cla.developers.google.com).
+1. Ensure you've signed a [Contributor License Agreement](https://cla.developers.google.com).
 1. Prepare a git commit that implements the feature. Don't forget to add tests
    and update the documentation. If your change has user-visible effects, please
    [add release notes](/versions/8.4.2/contribute/release-notes). If it is an incompatible change,
    read the [guide for rolling out breaking changes](/versions/8.4.2/contribute/breaking-changes).
 1. Create a pull request on
    [GitHub](https://github.com/bazelbuild/bazel/pulls). If you're new to GitHub,
-   read [about pull
-   requests](https://help.github.com/articles/about-pull-requests/). Note that
+   read [about pull requests](https://help.github.com/articles/about-pull-requests/). Note that
    we restrict permissions to create branches on the main Bazel repository, so
-   you will need to push your commit to [your own fork of the
-   repository](https://help.github.com/articles/working-with-forks/).
+   you will need to push your commit to [your own fork of the repository](https://help.github.com/articles/working-with-forks/).
 1. A Bazel maintainer should assign you a reviewer within two business days
    (excluding holidays in the USA and Germany). If you aren't assigned a
    reviewer in that time, you can request one by emailing
-   [bazel-discuss@googlegroups.com]
-   (mailto:bazel-discuss@googlegroups.com).
+   [bazel-discuss@googlegroups.com](mailto:bazel-discuss@googlegroups.com).
 1. Work with the reviewer to complete a code review. For each change, create a
    new commit and push it to make changes to your pull request. If the review
    takes too long (for instance, if the reviewer is unresponsive), send an email to
-   [bazel-discuss@googlegroups.com]
-   (mailto:bazel-discuss@googlegroups.com).
+   [bazel-discuss@googlegroups.com](mailto:bazel-discuss@googlegroups.com).
 1. After your review is complete, a Bazel maintainer applies your patch to
    Google's internal version control system.
 
diff --git a/versions/8.4.2/contribute/release-notes.mdx b/versions/8.4.2/contribute/release-notes.mdx
index 7dd604d5..84105e81 100644
--- a/versions/8.4.2/contribute/release-notes.mdx
+++ b/versions/8.4.2/contribute/release-notes.mdx
@@ -16,8 +16,7 @@ the release announcement.
 * If the change adds / removes / changes Bazel in a user-visible way, then it
   may be advantageous to mention it.
 
-If the change is significant, follow the [design document
-policy](/versions/8.4.2/contribute/design-documents) first.
+If the change is significant, follow the [design document policy](/versions/8.4.2/contribute/design-documents) first.
 
 ## Guidelines {#guidelines}
 
@@ -60,10 +59,8 @@ change is about.
 
 ## Process {#process}
 
-As part of the [release
-process](https://github.com/bazelbuild/continuous-integration/blob/master/docs/release-playbook.md),
-we collect the `RELNOTES` tags of every commit. We copy everything in a [Google
-Doc](https://docs.google.com/document/d/1wDvulLlj4NAlPZamdlEVFORks3YXJonCjyuQMUQEmB0/edit)
+As part of the [release process](https://github.com/bazelbuild/continuous-integration/blob/master/docs/release-playbook.md),
+we collect the `RELNOTES` tags of every commit. We copy everything in a [Google Doc](https://docs.google.com/document/d/1wDvulLlj4NAlPZamdlEVFORks3YXJonCjyuQMUQEmB0/edit)
 where we review, edit, and organize the notes.
 
 The release manager sends an email to the
@@ -71,6 +68,4 @@ The release manager sends an email to the
 Bazel contributors are invited to contribute to the document and make sure
 their changes are correctly reflected in the announcement.
 
-Later, the announcement will be submitted to the [Bazel
-blog](https://blog.bazel.build/), using the [bazel-blog
-repository](https://github.com/bazelbuild/bazel-blog/tree/master/_posts).
+Later, the announcement will be submitted to the [Bazel blog](https://blog.bazel.build/), using the [bazel-blog repository](https://github.com/bazelbuild/bazel-blog/tree/master/_posts).
diff --git a/versions/8.4.2/contribute/statemachine-guide.mdx b/versions/8.4.2/contribute/statemachine-guide.mdx
index 44c6d5ea..aef298fc 100644
--- a/versions/8.4.2/contribute/statemachine-guide.mdx
+++ b/versions/8.4.2/contribute/statemachine-guide.mdx
@@ -172,8 +172,7 @@ instead, batches[^4] as many lookups as possible before doing so. The value
 might not be immediately available, for example, requiring a Skyframe restart,
 so the caller specifies what to do with the resulting value using a callback.
 
-The `StateMachine` processor ([`Driver`s and bridging to
-SkyFrame](#drivers-and-bridging)) guarantees that the value is available before
+The `StateMachine` processor ([`Driver`s and bridging to SkyFrame](#drivers-and-bridging)) guarantees that the value is available before
 the next state begins. An example follows.
 
 ```
@@ -284,8 +283,7 @@ and solutions to certain control flow problems.
 ### Sequential states
 
 This is the most common and straightforward control flow pattern. An example of
-this is shown in [Stateful computations inside
-`SkyKeyComputeState`](#stateful-computations).
+this is shown in [Stateful computations inside `SkyKeyComputeState`](#stateful-computations).
 
 ### Branching
 
@@ -545,8 +543,7 @@ section describes the propagation of data values.
 
 ### Implementing `Tasks.lookUp` callbacks
 
-There’s an example of implementing a `Tasks.lookUp` callback in [SkyValue
-lookups](#skyvalue-lookups). This section provides rationale and suggests
+There’s an example of implementing a `Tasks.lookUp` callback in [SkyValue lookups](#skyvalue-lookups). This section provides rationale and suggests
 approaches for handling multiple SkyValues.
 
 #### `Tasks.lookUp` callbacks {#tasks-lookup-callbacks}
@@ -710,8 +707,7 @@ class BarProducer implements StateMachine {
 Tip: It would be tempting to use the more concise signature void `accept(Bar
 value)` rather than the stuttery `void acceptBarValue(Bar value)` above.
 However, `Consumer` is a common overload of `void accept(Bar value)`,
-so doing this often leads to violations of the [Overloads: never
-split](https://google.github.io/styleguide/javaguide.html#s3.4.2-ordering-class-contents)
+so doing this often leads to violations of the [Overloads: never split](https://google.github.io/styleguide/javaguide.html#s3.4.2-ordering-class-contents)
 style-guide rule.
 
 Tip: Using a custom `ResultSink` type instead of a generic one from
@@ -774,14 +770,11 @@ pattern after accepting output from either a subtask or SkyValue lookup.
 Note that the implementation of `acceptBarError` eagerly forwards the result to
 the `Caller.ResultSink`, as required by [Error bubbling](#error-bubbling).
 
-Alternatives for top-level `StateMachine`s are described in [`Driver`s and
-bridging to SkyFunctions](#drivers-and-bridging).
+Alternatives for top-level `StateMachine`s are described in [`Driver`s and bridging to SkyFunctions](#drivers-and-bridging).
 
 ### Error handling {#error-handling}
 
-There's a couple of examples of error handling already in [`Tasks.lookUp`
-callbacks](#tasks-lookup-callbacks) and [Propagating values between
-`StateMachines`](#propagating-values). Exceptions, other than
+There's a couple of examples of error handling already in [`Tasks.lookUp` callbacks](#tasks-lookup-callbacks) and [Propagating values between `StateMachines`](#propagating-values). Exceptions, other than
 `InterruptedException` are not thrown, but instead passed around through
 callbacks as values. Such callbacks often have exclusive-or semantics, with
 exactly one of a value or error being passed.
@@ -1184,8 +1177,7 @@ states. Where it is possible, local stack `step` variables are young generation
 variables and efficiently GC'd.
 
 For `StateMachine` variables, breaking things down into subtasks and following
-the recommended pattern for [Propagating values between
-`StateMachine`s](#propagating-values) is also helpful. Observe that when
+the recommended pattern for [Propagating values between `StateMachine`s](#propagating-values) is also helpful. Observe that when
 following the pattern, only child `StateMachine`s have references to parent
 `StateMachine`s and not vice versa. This means that as children complete and
 update the parents using result callbacks, the children naturally fall out of
@@ -1207,8 +1199,7 @@ potentially reflecting local behavior.
 
 ### Concurrency tree diagram {#concurrency-tree-diagram}
 
-The following is an alternative view of the diagram in [Structured
-concurrency](#structured-concurrency) that better depicts the tree structure.
+The following is an alternative view of the diagram in [Structured concurrency](#structured-concurrency) that better depicts the tree structure.
 The blocks form a small tree.
 
 ![Structured Concurrency 3D](/versions/8.4.2/contribute/images/structured-concurrency-3d.svg)
diff --git a/versions/8.4.2/docs/android-instrumentation-test.mdx b/versions/8.4.2/docs/android-instrumentation-test.mdx
index fd5bfffa..c9a76051 100644
--- a/versions/8.4.2/docs/android-instrumentation-test.mdx
+++ b/versions/8.4.2/docs/android-instrumentation-test.mdx
@@ -2,8 +2,7 @@
 title: 'Android Instrumentation Tests'
 ---
 
-_If you're new to Bazel, start with the [Building Android with
-Bazel](/versions/8.4.2/start/android-app ) tutorial._
+_If you're new to Bazel, start with the [Building Android with Bazel](/versions/8.4.2/start/android-app) tutorial._
 
 ![Running Android instrumentation tests in parallel](/versions/8.4.2/docs/images/android_test.gif "Android instrumentation test")
 
@@ -18,9 +17,7 @@ emulators in a sandbox, ensuring that tests always run from a clean state. Each
 test gets an isolated emulator instance, allowing tests to run in parallel
 without passing states between them.
 
-For more information on Android instrumentation tests, check out the [Android
-developer
-documentation](https://developer.android.com/training/testing/unit-testing/instrumented-unit-tests.html).
+For more information on Android instrumentation tests, check out the [Android developer documentation](https://developer.android.com/training/testing/unit-testing/instrumented-unit-tests.html).
 
 Please file issues in the [GitHub issue tracker](https://github.com/bazelbuild/bazel/issues).
 
@@ -58,8 +55,7 @@ This results in output similar to the following:
 release 4.1.0
 ```
 
-- **KVM**. Bazel requires emulators to have [hardware
-  acceleration](https://developer.android.com/studio/run/emulator-acceleration.html#accel-check)
+- **KVM**. Bazel requires emulators to have [hardware acceleration](https://developer.android.com/studio/run/emulator-acceleration.html#accel-check)
   with KVM on Linux. You can follow these
   [installation instructions](https://help.ubuntu.com/community/KVM/Installation)
   for Ubuntu.
@@ -173,11 +169,9 @@ The main attributes of the rule `android_instrumentation_test` are:
 
 - `target_device`: An `android_device` target. This target describes the
   specifications of the Android emulator which Bazel uses to create, launch and
-  run the tests. See the [section on choosing an Android
-  device](#android-device-target) for more information.
+  run the tests. See the [section on choosing an Android device](#android-device-target) for more information.
 
-The test app's `AndroidManifest.xml` must include [an ``
-tag](https://developer.android.com/studio/test/#configure_instrumentation_manifest_settings).
+The test app's `AndroidManifest.xml` must include [an `` tag](https://developer.android.com/studio/test/#configure_instrumentation_manifest_settings).
 This tag must specify the attributes for the **package of the target app** and
 the **fully qualified class name of the instrumentation test runner**,
 `androidx.test.runner.AndroidJUnitRunner`.
@@ -214,8 +208,7 @@ repositories:
 - `@androidsdk`: The Android SDK. Download this through Android Studio.
 
 - `@android_test_support`: Hosts the test runner, emulator launcher, and
-  `android_device` targets. You can find the [latest release
-  here](https://github.com/android/android-test/releases).
+  `android_device` targets. You can find the [latest release here](https://github.com/android/android-test/releases).
 
 Enable these dependencies by adding the following lines to your `WORKSPACE`
 file:
@@ -240,8 +233,7 @@ android_test_repositories()
 
 ## Maven dependencies {#maven-dependencies}
 
-For managing dependencies on Maven artifacts from repositories, such as [Google
-Maven](https://maven.google.com) or [Maven Central](https://central.maven.org),
+For managing dependencies on Maven artifacts from repositories, such as [Google Maven](https://maven.google.com) or [Maven Central](https://central.maven.org),
 you should use a Maven resolver, such as
 [`rules_jvm_external`](https://github.com/bazelbuild/rules_jvm_external).
 
@@ -370,8 +362,7 @@ the device/emulator listed in `adb devices`.
 
 ## Sample projects {#sample-projects}
 
-If you are looking for canonical project samples, see the [Android testing
-samples](https://github.com/googlesamples/android-testing#experimental-bazel-support)
+If you are looking for canonical project samples, see the [Android testing samples](https://github.com/googlesamples/android-testing#experimental-bazel-support)
 for projects using Espresso and UIAutomator.
 
 ## Espresso setup {#espresso-setup}
@@ -560,8 +551,7 @@ API_LEVELS = [
 
 ## Known issues {#known-issues}
 
-- [Forked adb server processes are not terminated after
-  tests](https://github.com/bazelbuild/bazel/issues/4853)
+- [Forked adb server processes are not terminated after tests](https://github.com/bazelbuild/bazel/issues/4853)
 - While APK building works on all platforms (Linux, macOS, Windows), testing
   only works on Linux.
 - Even with `--config=local_adb`, users still need to specify
diff --git a/versions/8.4.2/docs/android-ndk.mdx b/versions/8.4.2/docs/android-ndk.mdx
index f897e4e9..3a964118 100644
--- a/versions/8.4.2/docs/android-ndk.mdx
+++ b/versions/8.4.2/docs/android-ndk.mdx
@@ -2,8 +2,7 @@
 title: 'Using the Android Native Development Kit with Bazel'
 ---
 
-_If you're new to Bazel, please start with the [Building Android with
-Bazel](/versions/8.4.2/start/android-app ) tutorial._
+_If you're new to Bazel, please start with the [Building Android with Bazel](/versions/8.4.2/start/android-app) tutorial._
 
 ## Overview {#overview}
 
@@ -31,8 +30,7 @@ android_ndk_repository(
 )
 ```
 
-For more information about the `android_ndk_repository` rule, see the [Build
-Encyclopedia entry](/versions/8.4.2/reference/be/android#android_ndk_repository).
+For more information about the `android_ndk_repository` rule, see the [Build Encyclopedia entry](/versions/8.4.2/reference/be/android#android_ndk_repository).
 
 If you're using a recent version of the Android NDK (r22 and beyond), use the
 Starlark implementation of `android_ndk_repository`.
@@ -101,13 +99,11 @@ META-INF/MANIFEST.MF
 
 Bazel compiles all of the cc_libraries into a single shared object (`.so`) file,
 targeted for the `armeabi-v7a` ABI by default. To change this or build for
-multiple ABIs at the same time, see the section on [configuring the target
-ABI](#configuring-target-abi).
+multiple ABIs at the same time, see the section on [configuring the target ABI](#configuring-target-abi).
 
 ## Example setup {#example-setup}
 
-This example is available in the [Bazel examples
-repository](https://github.com/bazelbuild/examples/tree/master/android/ndk).
+This example is available in the [Bazel examples repository](https://github.com/bazelbuild/examples/tree/master/android/ndk).
 
 In the `BUILD.bazel` file, three targets are defined with the `android_binary`,
 `android_library`, and `cc_library` rules.
diff --git a/versions/8.4.2/docs/bazel-and-android.mdx b/versions/8.4.2/docs/bazel-and-android.mdx
index 49efa832..d0c6e7c7 100644
--- a/versions/8.4.2/docs/bazel-and-android.mdx
+++ b/versions/8.4.2/docs/bazel-and-android.mdx
@@ -10,7 +10,7 @@ Android projects with Bazel.
 
 The following resources will help you work with Bazel on Android projects:
 
-*  [Tutorial: Building an Android app](/versions/8.4.2/start/android-app ). This
+*  [Tutorial: Building an Android app](/versions/8.4.2/start/android-app). This
    tutorial is a good place to start learning about Bazel commands and concepts,
    and how to build Android apps with Bazel.
 *  [Codelab: Building Android Apps with Bazel](https://developer.android.com/codelabs/bazel-android-intro#0).
diff --git a/versions/8.4.2/docs/configurable-attributes.mdx b/versions/8.4.2/docs/configurable-attributes.mdx
index b4682fb6..2f54aeb4 100644
--- a/versions/8.4.2/docs/configurable-attributes.mdx
+++ b/versions/8.4.2/docs/configurable-attributes.mdx
@@ -2,8 +2,7 @@
 title: 'Configurable Build Attributes'
 ---
 
-**_Configurable attributes_**, commonly known as [`select()`](
-/reference/be/functions#select), is a Bazel feature that lets users toggle the values
+**_Configurable attributes_**, commonly known as [`select()`](/versions/8.4.2/reference/be/functions#select), is a Bazel feature that lets users toggle the values
 of build rule attributes at the command line.
 
 This can be used, for example, for a multiplatform library that automatically
@@ -407,8 +406,7 @@ sh_library(
 )
 ```
 
-If you need a `select` to match when multiple conditions match, consider [AND
-chaining](#and-chaining).
+If you need a `select` to match when multiple conditions match, consider [AND chaining](#and-chaining).
 
 ## OR chaining {#or-chaining}
 
diff --git a/versions/8.4.2/docs/images/a_b_a_c.svg b/versions/8.4.2/docs/images/a_b_a_c.svg
new file mode 100644
index 00000000..d38be075
--- /dev/null
+++ b/versions/8.4.2/docs/images/a_b_a_c.svg
@@ -0,0 +1,42 @@
+
+
+
+
+
+
+G
+
+
+
+a
+
+a
+
+
+
+b
+
+b
+
+
+
+a->b
+
+
+
+
+
+c
+
+c
+
+
+
+a->c
+
+
+
+
+
+
diff --git a/versions/8.4.2/docs/images/a_b_c.svg b/versions/8.4.2/docs/images/a_b_c.svg
new file mode 100644
index 00000000..acd948ab
--- /dev/null
+++ b/versions/8.4.2/docs/images/a_b_c.svg
@@ -0,0 +1,41 @@
+
+
+
+
+
+
+G
+
+
+
+a
+
+a
+
+
+
+b
+
+b
+
+
+
+a->b
+
+
+
+
+
+c
+
+c
+
+
+
+b->c
+
+
+
+
+
diff --git a/versions/8.4.2/docs/images/a_b_c_ac.svg b/versions/8.4.2/docs/images/a_b_c_ac.svg
new file mode 100644
index 00000000..b099c53e
--- /dev/null
+++ b/versions/8.4.2/docs/images/a_b_c_ac.svg
@@ -0,0 +1,47 @@
+
+
+
+
+
+
+G
+
+
+
+a
+
+a
+
+
+
+b
+
+b
+
+
+
+a->b
+
+
+
+
+
+c
+
+c
+
+
+
+a->c
+
+
+
+
+
+b->c
+
+
+
+
+
diff --git a/versions/8.4.2/docs/images/ab_c.svg b/versions/8.4.2/docs/images/ab_c.svg
new file mode 100644
index 00000000..bcc4563f
--- /dev/null
+++ b/versions/8.4.2/docs/images/ab_c.svg
@@ -0,0 +1,36 @@
+
+
+
+
+
+
+G
+
+
+
+a
+
+a
+
+
+
+b
+
+b
+
+
+
+a->b
+
+
+
+
+
+c
+
+c
+
+
+
+
diff --git a/versions/8.4.2/docs/images/allpaths.svg b/versions/8.4.2/docs/images/allpaths.svg
new file mode 100644
index 00000000..47d0ee33
--- /dev/null
+++ b/versions/8.4.2/docs/images/allpaths.svg
@@ -0,0 +1,141 @@
+
+
+
+
+
+
+allpaths
+
+
+
+n1
+
+
+
+
+n2
+
+
+
+
+n1->n2
+
+
+
+
+
+n3
+
+
+
+
+n2->n3
+
+
+
+
+
+n10
+
+
+
+
+n2->n10
+
+
+
+
+
+n3->n10
+
+
+
+
+
+n4
+
+E
+
+
+
+n5
+
+
+
+
+n6
+
+
+
+
+n5->n6
+
+
+
+
+
+n6->n4
+
+
+
+
+
+n9
+
+
+
+
+n6->n9
+
+
+
+
+
+n7
+
+S1
+
+
+
+n7->n2
+
+
+
+
+
+n7->n5
+
+
+
+
+
+n8
+
+S2
+
+
+
+n8->n6
+
+
+
+
+
+n10->n4
+
+
+
+
+
+n11
+
+
+
+
+n10->n11
+
+
+
+
+
diff --git a/versions/8.4.2/docs/images/android_instrumentation_test.png b/versions/8.4.2/docs/images/android_instrumentation_test.png
new file mode 100644
index 00000000..e4534fbd
Binary files /dev/null and b/versions/8.4.2/docs/images/android_instrumentation_test.png differ
diff --git a/versions/8.4.2/docs/images/android_ndk.png b/versions/8.4.2/docs/images/android_ndk.png
new file mode 100644
index 00000000..76b63cb3
Binary files /dev/null and b/versions/8.4.2/docs/images/android_ndk.png differ
diff --git a/versions/8.4.2/docs/images/android_tutorial_app.png b/versions/8.4.2/docs/images/android_tutorial_app.png
new file mode 100644
index 00000000..076be5b9
Binary files /dev/null and b/versions/8.4.2/docs/images/android_tutorial_app.png differ
diff --git a/versions/8.4.2/docs/images/android_tutorial_before.png b/versions/8.4.2/docs/images/android_tutorial_before.png
new file mode 100644
index 00000000..8e41d419
Binary files /dev/null and b/versions/8.4.2/docs/images/android_tutorial_before.png differ
diff --git a/versions/8.4.2/docs/images/bep-graph.png b/versions/8.4.2/docs/images/bep-graph.png
new file mode 100644
index 00000000..82da6715
Binary files /dev/null and b/versions/8.4.2/docs/images/bep-graph.png differ
diff --git a/versions/8.4.2/docs/images/bep-graph.svg b/versions/8.4.2/docs/images/bep-graph.svg
new file mode 100644
index 00000000..62b1480f
--- /dev/null
+++ b/versions/8.4.2/docs/images/bep-graph.svg
@@ -0,0 +1,4 @@
+
+
+
+
diff --git a/versions/8.4.2/docs/images/cpp-tutorial-stage1.png b/versions/8.4.2/docs/images/cpp-tutorial-stage1.png
new file mode 100644
index 00000000..c85fb303
Binary files /dev/null and b/versions/8.4.2/docs/images/cpp-tutorial-stage1.png differ
diff --git a/versions/8.4.2/docs/images/cpp-tutorial-stage2.png b/versions/8.4.2/docs/images/cpp-tutorial-stage2.png
new file mode 100644
index 00000000..80e202c9
Binary files /dev/null and b/versions/8.4.2/docs/images/cpp-tutorial-stage2.png differ
diff --git a/versions/8.4.2/docs/images/cpp-tutorial-stage3.png b/versions/8.4.2/docs/images/cpp-tutorial-stage3.png
new file mode 100644
index 00000000..54d82f31
Binary files /dev/null and b/versions/8.4.2/docs/images/cpp-tutorial-stage3.png differ
diff --git a/versions/8.4.2/docs/images/deps.svg b/versions/8.4.2/docs/images/deps.svg
new file mode 100644
index 00000000..4354222a
--- /dev/null
+++ b/versions/8.4.2/docs/images/deps.svg
@@ -0,0 +1,101 @@
+
+
+
+
+
+
+G1
+
+
+
+r1
+
+rule
+
+
+
+s1
+
+in
+
+
+
+r1->s1
+
+
+
+
+
+s2
+
+in
+
+
+
+r1->s2
+
+
+
+
+
+s3
+
+in
+
+
+
+r1->s3
+
+
+
+
+
+r2
+
+rule
+
+
+
+r2->r1
+
+
+
+
+
+s4
+
+in
+
+
+
+r2->s4
+
+
+
+
+
+o1
+
+out
+
+
+
+o1->r1
+
+
+
+
+
+o2
+
+out
+
+
+
+o2->r2
+
+
+
+
+
diff --git a/versions/8.4.2/docs/images/dyn-trace-alldynamic.png b/versions/8.4.2/docs/images/dyn-trace-alldynamic.png
new file mode 100644
index 00000000..fe36b253
Binary files /dev/null and b/versions/8.4.2/docs/images/dyn-trace-alldynamic.png differ
diff --git a/versions/8.4.2/docs/images/dyn-trace-javaconly.png b/versions/8.4.2/docs/images/dyn-trace-javaconly.png
new file mode 100644
index 00000000..2ae41e52
Binary files /dev/null and b/versions/8.4.2/docs/images/dyn-trace-javaconly.png differ
diff --git a/versions/8.4.2/docs/images/e4b-workflow.png b/versions/8.4.2/docs/images/e4b-workflow.png
new file mode 100644
index 00000000..412822da
Binary files /dev/null and b/versions/8.4.2/docs/images/e4b-workflow.png differ
diff --git a/versions/8.4.2/docs/images/e4b-workflow.svg b/versions/8.4.2/docs/images/e4b-workflow.svg
new file mode 100644
index 00000000..1de66e02
--- /dev/null
+++ b/versions/8.4.2/docs/images/e4b-workflow.svg
@@ -0,0 +1,4 @@
+
+
+
+
diff --git a/versions/8.4.2/docs/images/error_example_1.png b/versions/8.4.2/docs/images/error_example_1.png
new file mode 100644
index 00000000..07ba1358
Binary files /dev/null and b/versions/8.4.2/docs/images/error_example_1.png differ
diff --git a/versions/8.4.2/docs/images/error_example_2.png b/versions/8.4.2/docs/images/error_example_2.png
new file mode 100644
index 00000000..861171ee
Binary files /dev/null and b/versions/8.4.2/docs/images/error_example_2.png differ
diff --git a/versions/8.4.2/docs/images/error_example_3.png b/versions/8.4.2/docs/images/error_example_3.png
new file mode 100644
index 00000000..dc16eec4
Binary files /dev/null and b/versions/8.4.2/docs/images/error_example_3.png differ
diff --git a/versions/8.4.2/docs/images/error_example_4.png b/versions/8.4.2/docs/images/error_example_4.png
new file mode 100644
index 00000000..84383e63
Binary files /dev/null and b/versions/8.4.2/docs/images/error_example_4.png differ
diff --git a/versions/8.4.2/docs/images/graph_ex_1.svg b/versions/8.4.2/docs/images/graph_ex_1.svg
new file mode 100644
index 00000000..dd7427f4
--- /dev/null
+++ b/versions/8.4.2/docs/images/graph_ex_1.svg
@@ -0,0 +1,131 @@
+
+
+
+
+
+
+mygraph
+
+
+
+//net/proto_compiler:protocol-compiler
+
+//net/proto_compiler:protocol-compiler
+
+
+
+//net/proto_compiler:util
+
+//net/proto_compiler:util
+
+
+
+//net/proto_compiler:protocol-compiler->//net/proto_compiler:util
+
+
+
+
+
+//net/proto_compiler:protocol-compiler-lib
+
+//net/proto_compiler:protocol-compiler-lib
+
+
+
+//net/proto_compiler:protocol-compiler->//net/proto_compiler:protocol-compiler-lib
+
+
+
+
+
+//net/proto2/bridge/public:compiler_upgrader
+
+//net/proto2/bridge/public:compiler_upgrader
+
+
+
+//net/proto_compiler:protocol-compiler->//net/proto2/bridge/public:compiler_upgrader
+
+
+
+
+
+//net/proto_compiler:parser
+
+//net/proto_compiler:parser
+
+
+
+//net/proto_compiler:util->//net/proto_compiler:parser
+
+
+
+
+
+//net/proto_compiler:proto-min-lib
+
+//net/proto_compiler:proto-min-lib
+
+
+
+//net/proto_compiler:protocol-compiler-lib->//net/proto_compiler:proto-min-lib
+
+
+
+
+
+//net/proto_compiler:protocol-compiler-lib->//net/proto_compiler:parser
+
+
+
+
+
+//net/proto2/bridge/internal:compiler_upgrader
+
+//net/proto2/bridge/internal:compiler_upgrader
+
+
+
+//net/proto2/bridge/public:compiler_upgrader->//net/proto2/bridge/internal:compiler_upgrader
+
+
+
+
+
+//net/proto_compiler:proto-min-lib->//net/proto_compiler:parser
+
+
+
+
+
+//util/regexp:regexp
+
+//util/regexp:regexp
+
+
+
+//net/proto_compiler:proto-min-lib->//util/regexp:regexp
+
+
+
+
+
+//net/proto_compiler:parser->//util/regexp:regexp
+
+
+
+
+
+//net/proto2/bridge/internal:compiler_upgrader->//net/proto2/bridge/public:compiler_upgrader
+
+
+
+
+
+//net/proto2/bridge/internal:compiler_upgrader->//net/proto_compiler:parser
+
+
+
+
+
diff --git a/versions/8.4.2/docs/images/graph_hello-world.svg b/versions/8.4.2/docs/images/graph_hello-world.svg
new file mode 100644
index 00000000..93b61444
--- /dev/null
+++ b/versions/8.4.2/docs/images/graph_hello-world.svg
@@ -0,0 +1,70 @@
+
+
+
+
+
+
+mygraph
+
+
+//main:hello-world
+
+//main:hello-world
+
+
+//main:hello-time
+
+//main:hello-time
+
+
+//main:hello-world->//main:hello-time
+
+
+
+
+//main:hello-world.cc
+
+//main:hello-world.cc
+
+
+//main:hello-world->//main:hello-world.cc
+
+
+
+
+//lib:hello-greet
+
+//lib:hello-greet
+
+
+//main:hello-world->//lib:hello-greet
+
+
+
+
+//main:hello-time.cc\n//main:hello-time.h
+
+//main:hello-time.cc
+//main:hello-time.h
+
+
+//main:hello-time->//main:hello-time.cc\n//main:hello-time.h
+
+
+
+
+//lib:hello-greet.cc\n//lib:hello-greet.h
+
+//lib:hello-greet.cc
+//lib:hello-greet.h
+
+
+//lib:hello-greet->//lib:hello-greet.cc\n//lib:hello-greet.h
+
+
+
+
+
diff --git a/versions/8.4.2/docs/images/json-trace-profile-network-usage.png b/versions/8.4.2/docs/images/json-trace-profile-network-usage.png
new file mode 100644
index 00000000..8a7500a6
Binary files /dev/null and b/versions/8.4.2/docs/images/json-trace-profile-network-usage.png differ
diff --git a/versions/8.4.2/docs/images/json-trace-profile-system-load-average.png b/versions/8.4.2/docs/images/json-trace-profile-system-load-average.png
new file mode 100644
index 00000000..e71b420c
Binary files /dev/null and b/versions/8.4.2/docs/images/json-trace-profile-system-load-average.png differ
diff --git a/versions/8.4.2/docs/images/json-trace-profile-workers-memory-usage.png b/versions/8.4.2/docs/images/json-trace-profile-workers-memory-usage.png
new file mode 100644
index 00000000..806505f0
Binary files /dev/null and b/versions/8.4.2/docs/images/json-trace-profile-workers-memory-usage.png differ
diff --git a/versions/8.4.2/docs/images/json-trace-profile.png b/versions/8.4.2/docs/images/json-trace-profile.png
new file mode 100644
index 00000000..538382b2
Binary files /dev/null and b/versions/8.4.2/docs/images/json-trace-profile.png differ
diff --git a/versions/8.4.2/docs/images/mobile-install-performance.svg b/versions/8.4.2/docs/images/mobile-install-performance.svg
new file mode 100644
index 00000000..b139d658
--- /dev/null
+++ b/versions/8.4.2/docs/images/mobile-install-performance.svg
@@ -0,0 +1,86 @@
+
+
+
+  
+    
+      
+    
+  
+  
+  
+    Build times
+  
+  
+    
+    
+      
+      
+        adb install
+      
+      
+    
+    
+      
+      
+        mobile-install
+      
+      
+    
+  
+  
+    
+    
+      
+        
+        
+        
+        
+        
+      
+      
+        
+        
+        
+        
+        
+        
+      
+      
+        
+      
+    
+    
+    
+      
+        Google Maps
+      
+      
+        Google+
+      
+      
+        YouTube
+      
+      
+        0
+      
+      
+        75
+      
+      
+        150
+      
+      
+        225
+      
+      
+        300
+      
+    
+  
+  
+    
+      Seconds
+    
+  
+  
+
diff --git a/versions/8.4.2/docs/images/namedsetoffiles-bep-graph.png b/versions/8.4.2/docs/images/namedsetoffiles-bep-graph.png
new file mode 100644
index 00000000..ea1e10cc
Binary files /dev/null and b/versions/8.4.2/docs/images/namedsetoffiles-bep-graph.png differ
diff --git a/versions/8.4.2/docs/images/out-ranked.svg b/versions/8.4.2/docs/images/out-ranked.svg
new file mode 100644
index 00000000..07e96804
--- /dev/null
+++ b/versions/8.4.2/docs/images/out-ranked.svg
@@ -0,0 +1,71 @@
+
+
+
+
+
+
+mygraph
+
+
+
+//a:a
+
+//a:a
+
+
+
+//a:a.cc
+
+//a:a.cc
+
+
+
+//a:a->//a:a.cc
+
+
+
+
+
+//b:b
+
+//b:b
+
+
+
+//b:b->//a:a
+
+
+
+
+
+//b:b.cc
+
+//b:b.cc
+
+
+
+//b:b->//b:b.cc
+
+
+
+
+
+//c:c
+
+//c:c
+
+
+
+//c:c->//a:a
+
+
+
+
+
+//c:c->//b:b
+
+
+
+
+
diff --git a/versions/8.4.2/docs/images/rbe-ci-1.png b/versions/8.4.2/docs/images/rbe-ci-1.png
new file mode 100644
index 00000000..fbe76a85
Binary files /dev/null and b/versions/8.4.2/docs/images/rbe-ci-1.png differ
diff --git a/versions/8.4.2/docs/images/rbe-ci-2.png b/versions/8.4.2/docs/images/rbe-ci-2.png
new file mode 100644
index 00000000..07611889
Binary files /dev/null and b/versions/8.4.2/docs/images/rbe-ci-2.png differ
diff --git a/versions/8.4.2/docs/images/somepath1.svg b/versions/8.4.2/docs/images/somepath1.svg
new file mode 100644
index 00000000..5e5f8812
--- /dev/null
+++ b/versions/8.4.2/docs/images/somepath1.svg
@@ -0,0 +1,141 @@
+
+
+
+
+
+
+somepath1
+
+
+
+n1
+
+
+
+
+n2
+
+
+
+
+n1->n2
+
+
+
+
+
+n3
+
+
+
+
+n2->n3
+
+
+
+
+
+n10
+
+
+
+
+n2->n10
+
+
+
+
+
+n3->n10
+
+
+
+
+
+n4
+
+E
+
+
+
+n5
+
+
+
+
+n6
+
+
+
+
+n5->n6
+
+
+
+
+
+n6->n4
+
+
+
+
+
+n9
+
+
+
+
+n6->n9
+
+
+
+
+
+n7
+
+S1
+
+
+
+n7->n2
+
+
+
+
+
+n7->n5
+
+
+
+
+
+n8
+
+S2
+
+
+
+n8->n6
+
+
+
+
+
+n10->n4
+
+
+
+
+
+n11
+
+
+
+
+n10->n11
+
+
+
+
+
diff --git a/versions/8.4.2/docs/images/somepath2.svg b/versions/8.4.2/docs/images/somepath2.svg
new file mode 100644
index 00000000..911f2c9b
--- /dev/null
+++ b/versions/8.4.2/docs/images/somepath2.svg
@@ -0,0 +1,141 @@
+
+
+
+
+
+
+somepath2
+
+
+
+n1
+
+
+
+
+n2
+
+
+
+
+n1->n2
+
+
+
+
+
+n3
+
+
+
+
+n2->n3
+
+
+
+
+
+n10
+
+
+
+
+n2->n10
+
+
+
+
+
+n3->n10
+
+
+
+
+
+n4
+
+E
+
+
+
+n5
+
+
+
+
+n6
+
+
+
+
+n5->n6
+
+
+
+
+
+n6->n4
+
+
+
+
+
+n9
+
+
+
+
+n6->n9
+
+
+
+
+
+n7
+
+S1
+
+
+
+n7->n2
+
+
+
+
+
+n7->n5
+
+
+
+
+
+n8
+
+S2
+
+
+
+n8->n6
+
+
+
+
+
+n10->n4
+
+
+
+
+
+n11
+
+
+
+
+n10->n11
+
+
+
+
+
diff --git a/versions/8.4.2/docs/images/targets.svg b/versions/8.4.2/docs/images/targets.svg
new file mode 100644
index 00000000..82f47e74
--- /dev/null
+++ b/versions/8.4.2/docs/images/targets.svg
@@ -0,0 +1,113 @@
+
+
+
+
+
+
+G1
+
+
+
+Target
+
+Target
+
+
+
+Rule
+
+Rule
+
+
+
+Target->Rule
+
+
+
+
+
+File
+
+File
+
+
+
+Target->File
+
+
+
+
+
+Package group
+
+Package group
+
+
+
+Target->Package group
+
+
+
+
+
+cc_library
+
+cc_library
+
+
+
+Rule->cc_library
+
+
+
+
+
+java_test
+
+java_test
+
+
+
+Rule->java_test
+
+
+
+
+
+...
+
+...
+
+
+
+Rule->...
+
+
+
+
+
+Source
+
+Source
+
+
+
+File->Source
+
+
+
+
+
+Generated
+
+Generated
+
+
+
+File->Generated
+
+
+
+
+
diff --git a/versions/8.4.2/docs/images/tutorial_java_01.svg b/versions/8.4.2/docs/images/tutorial_java_01.svg
new file mode 100644
index 00000000..2fe72f36
--- /dev/null
+++ b/versions/8.4.2/docs/images/tutorial_java_01.svg
@@ -0,0 +1,29 @@
+
+
+
+
+
+
+mygraph
+
+
+//:ProjectRunner
+
+//:ProjectRunner
+
+
+//:src/main/java/com/example/Greeting.java\n//:src/main/java/com/example/ProjectRunner.java
+
+//:src/main/java/com/example/Greeting.java
+//:src/main/java/com/example/ProjectRunner.java
+
+
+//:ProjectRunner->//:src/main/java/com/example/Greeting.java\n//:src/main/java/com/example/ProjectRunner.java
+
+
+
+
+
diff --git a/versions/8.4.2/docs/images/tutorial_java_02.svg b/versions/8.4.2/docs/images/tutorial_java_02.svg
new file mode 100644
index 00000000..40cbb218
--- /dev/null
+++ b/versions/8.4.2/docs/images/tutorial_java_02.svg
@@ -0,0 +1,48 @@
+
+
+
+
+
+
+mygraph
+
+
+//:ProjectRunner
+
+//:ProjectRunner
+
+
+//:greeter
+
+//:greeter
+
+
+//:ProjectRunner->//:greeter
+
+
+
+
+//:src/main/java/com/example/ProjectRunner.java
+
+//:src/main/java/com/example/ProjectRunner.java
+
+
+//:ProjectRunner->//:src/main/java/com/example/ProjectRunner.java
+
+
+
+
+//:src/main/java/com/example/Greeting.java
+
+//:src/main/java/com/example/Greeting.java
+
+
+//:greeter->//:src/main/java/com/example/Greeting.java
+
+
+
+
+
diff --git a/versions/8.4.2/docs/images/tutorial_java_03.svg b/versions/8.4.2/docs/images/tutorial_java_03.svg
new file mode 100644
index 00000000..7d79041a
--- /dev/null
+++ b/versions/8.4.2/docs/images/tutorial_java_03.svg
@@ -0,0 +1,48 @@
+
+
+
+
+
+
+mygraph
+
+
+//src/main/java/com/example/cmdline:runner
+
+//src/main/java/com/example/cmdline:runner
+
+
+//src/main/java/com/example/cmdline:Runner.java
+
+//src/main/java/com/example/cmdline:Runner.java
+
+
+//src/main/java/com/example/cmdline:runner->//src/main/java/com/example/cmdline:Runner.java
+
+
+
+
+//:greeter
+
+//:greeter
+
+
+//src/main/java/com/example/cmdline:runner->//:greeter
+
+
+
+
+//:src/main/java/com/example/Greeting.java
+
+//:src/main/java/com/example/Greeting.java
+
+
+//:greeter->//:src/main/java/com/example/Greeting.java
+
+
+
+
+
diff --git a/versions/8.4.2/docs/images/workers-clean-chart.png b/versions/8.4.2/docs/images/workers-clean-chart.png
new file mode 100644
index 00000000..63526fc1
Binary files /dev/null and b/versions/8.4.2/docs/images/workers-clean-chart.png differ
diff --git a/versions/8.4.2/docs/images/workers-incremental-chart.png b/versions/8.4.2/docs/images/workers-incremental-chart.png
new file mode 100644
index 00000000..1c62d25c
Binary files /dev/null and b/versions/8.4.2/docs/images/workers-incremental-chart.png differ
diff --git a/versions/8.4.2/docs/images/ws-diamond.png b/versions/8.4.2/docs/images/ws-diamond.png
new file mode 100644
index 00000000..154a7440
Binary files /dev/null and b/versions/8.4.2/docs/images/ws-diamond.png differ
diff --git a/versions/8.4.2/docs/images/ws-line.png b/versions/8.4.2/docs/images/ws-line.png
new file mode 100644
index 00000000..e8bfe7a1
Binary files /dev/null and b/versions/8.4.2/docs/images/ws-line.png differ
diff --git a/versions/8.4.2/docs/images/ws-multiline.png b/versions/8.4.2/docs/images/ws-multiline.png
new file mode 100644
index 00000000..f07b43b1
Binary files /dev/null and b/versions/8.4.2/docs/images/ws-multiline.png differ
diff --git a/versions/8.4.2/docs/sandboxing.mdx b/versions/8.4.2/docs/sandboxing.mdx
index 4ebd64a6..708acc85 100644
--- a/versions/8.4.2/docs/sandboxing.mdx
+++ b/versions/8.4.2/docs/sandboxing.mdx
@@ -48,7 +48,7 @@ containers on Linux and `sandbox-exec` on macOS, to constrain the action within
 ## What sandbox strategy to use {#sandboxing-strategies}
 
 You can choose which kind of sandboxing to use, if any, with the
-[strategy flags](user-manual#strategy-options). Using the `sandboxed`
+[strategy flags](/versions/8.4.2/docs/user-manual#strategy-options). Using the `sandboxed`
 strategy makes Bazel pick one of the sandbox implementations listed below,
 preferring an OS-specific sandbox to the less hermetic generic one.
 [Persistent workers](/versions/8.4.2/remote/persistent) run in a generic sandbox if you pass
diff --git a/versions/8.4.2/docs/user-manual.mdx b/versions/8.4.2/docs/user-manual.mdx
index 3903f7d4..76a2354b 100644
--- a/versions/8.4.2/docs/user-manual.mdx
+++ b/versions/8.4.2/docs/user-manual.mdx
@@ -1145,12 +1145,12 @@ during execution can be examined.
 This option causes Bazel's execution phase to print the full command line
 for each command prior to executing it.
 
-
-  >>>>> # //examples/cpp:hello-world [action 'Linking examples/cpp/hello-world']
+```
+  >>>> # //examples/cpp:hello-world [action 'Linking examples/cpp/hello-world']
   (cd /home/johndoe/.cache/bazel/_bazel_johndoe/4c084335afceb392cfbe7c31afee3a9f/bazel && \
     exec env - \
     /usr/bin/gcc -o bazel-out/local-fastbuild/bin/examples/cpp/hello-world -B/usr/bin/ -Wl,-z,relro,-z,now -no-canonical-prefixes -pass-exit-codes -Wl,-S -Wl,@bazel-out/local_linux-fastbuild/bin/examples/cpp/hello-world-2.params)
-

+```
 
 Where possible, commands are printed in a Bourne shell compatible syntax,
 so that they can be easily copied and pasted to a shell command prompt.
diff --git a/versions/8.4.2/extending/auto-exec-groups.mdx b/versions/8.4.2/extending/auto-exec-groups.mdx
index 9c3d0d33..8318cceb 100644
--- a/versions/8.4.2/extending/auto-exec-groups.mdx
+++ b/versions/8.4.2/extending/auto-exec-groups.mdx
@@ -27,9 +27,7 @@ doesn't detect that ([the error](#first-error-message) is raised), you can set
 
 If you need to use multiple toolchains on a single execution platform (an action
 uses executable or tools from two or more toolchains), you need to manually
-define [exec_groups][exec_groups] (check
-[When should I use a custom exec_group?][multiple_toolchains_exec_groups]
-section).
+define [exec_groups][exec_groups](check [When should I use a custom exec_group?][multiple_toolchains_exec_groups] section).
 
 ## History {#history}
 
@@ -42,8 +40,7 @@ my_rule = rule(
 )
 ```
 
-Rule `my_rule` registers two toolchain types. This means that the [Toolchain
-Resolution](https://bazel.build/extending/toolchains#toolchain-resolution) used
+Rule `my_rule` registers two toolchain types. This means that the [Toolchain Resolution](https://bazel.build/versions/8.4.2/extending/toolchains#toolchain-resolution) used
 to find an execution platform which supports both toolchain types. The selected
 execution platform was used for each registered action inside the rule, unless
 specified differently with [exec_groups][exec_groups].
diff --git a/versions/8.4.2/extending/concepts.mdx b/versions/8.4.2/extending/concepts.mdx
index ae668507..4e8ea4a2 100644
--- a/versions/8.4.2/extending/concepts.mdx
+++ b/versions/8.4.2/extending/concepts.mdx
@@ -20,16 +20,14 @@ Before learning the more advanced concepts, first:
 ## Macros and rules {#macros-and-rules}
 
 A macro is a function that instantiates rules. Macros come in two flavors:
-[symbolic macros](/versions/8.4.2/extending/macros) (new in Bazel 8) and [legacy
-macros](/versions/8.4.2/extending/legacy-macros). The two flavors of macros are defined
+[symbolic macros](/versions/8.4.2/extending/macros) (new in Bazel 8) and [legacy macros](/versions/8.4.2/extending/legacy-macros). The two flavors of macros are defined
 differently, but behave almost the same from the point of view of a user. A
 macro is useful when a `BUILD` file is getting too repetitive or too complex, as
 it lets you reuse some code. The function is evaluated as soon as the `BUILD`
 file is read. After the evaluation of the `BUILD` file, Bazel has little
 information about macros. If your macro generates a `genrule`, Bazel will
 behave *almost* as if you declared that `genrule` in the `BUILD` file. (The one
-exception is that targets declared in a symbolic macro have [special visibility
-semantics](/versions/8.4.2/extending/macros#visibility): a symbolic macro can hide its internal
+exception is that targets declared in a symbolic macro have [special visibility semantics](/versions/8.4.2/extending/macros#visibility): a symbolic macro can hide its internal
 targets from the rest of the package.)
 
 A [rule](/versions/8.4.2/extending/rules) is more powerful than a macro. It can access Bazel
@@ -76,8 +74,7 @@ they will not be executed.
 ## Creating extensions
 
 * [Create your first macro](/versions/8.4.2/rules/macro-tutorial) in order to reuse some code.
-  Then [learn more about macros](/versions/8.4.2/extending/macros) and [using them to create
-  "custom verbs"](/versions/8.4.2/rules/verbs-tutorial).
+  Then [learn more about macros](/versions/8.4.2/extending/macros) and [using them to create "custom verbs"](/versions/8.4.2/rules/verbs-tutorial).
 
 * [Follow the rules tutorial](/versions/8.4.2/rules/rules-tutorial) to get started with rules.
   Next, you can read more about the [rules concepts](/versions/8.4.2/extending/rules).
@@ -92,8 +89,7 @@ them within reach:
 ## Going further
 
 In addition to [macros](/versions/8.4.2/extending/macros) and [rules](/versions/8.4.2/extending/rules), you
-may want to write [aspects](/versions/8.4.2/extending/aspects) and [repository
-rules](/versions/8.4.2/extending/repo).
+may want to write [aspects](/versions/8.4.2/extending/aspects) and [repository rules](/versions/8.4.2/extending/repo).
 
 * Use [Buildifier](https://github.com/bazelbuild/buildtools)
   consistently to format and lint your code.
diff --git a/versions/8.4.2/extending/depsets.mdx b/versions/8.4.2/extending/depsets.mdx
index bbb975a7..762d6c63 100644
--- a/versions/8.4.2/extending/depsets.mdx
+++ b/versions/8.4.2/extending/depsets.mdx
@@ -111,8 +111,7 @@ need to ensure that if `B` depends on `A`, then `A.o` comes before `B.o` on the
 linker’s command line. Other tools might have the opposite requirement.
 
 Three traversal orders are supported: `postorder`, `preorder`, and
-`topological`. The first two work exactly like [tree
-traversals](https://en.wikipedia.org/wiki/Tree_traversal#Depth-first_search)
+`topological`. The first two work exactly like [tree traversals](https://en.wikipedia.org/wiki/Tree_traversal#Depth-first_search)
 except that they operate on DAGs and skip already visited nodes. The third order
 works as a topological sort from root to leaves, essentially the same as
 preorder except that shared children are listed only after all of their parents.
diff --git a/versions/8.4.2/extending/exec-groups.mdx b/versions/8.4.2/extending/exec-groups.mdx
index ab85c99c..76f132a0 100644
--- a/versions/8.4.2/extending/exec-groups.mdx
+++ b/versions/8.4.2/extending/exec-groups.mdx
@@ -63,8 +63,7 @@ test rules.
 
 In the rule implementation, you can declare that actions should be run on the
 execution platform of an execution group. You can do this by using the `exec_group`
-param of action generating methods, specifically [`ctx.actions.run`]
-(/rules/lib/builtins/actions#run) and
+param of action generating methods, specifically [`ctx.actions.run`](/versions/8.4.2/rules/lib/builtins/actions#run) and
 [`ctx.actions.run_shell`](/versions/8.4.2/rules/lib/builtins/actions#run_shell).
 
 ```python
diff --git a/versions/8.4.2/extending/legacy-macros.mdx b/versions/8.4.2/extending/legacy-macros.mdx
index 248c572c..8c7986c1 100644
--- a/versions/8.4.2/extending/legacy-macros.mdx
+++ b/versions/8.4.2/extending/legacy-macros.mdx
@@ -9,7 +9,7 @@ anymore, and Bazel sees only the concrete set of instantiated rules.
 
 ## Why you shouldn't use legacy macros (and should use Symbolic macros instead) {#no-legacy-macros}
 
-Where possible you should use [symbolic macros](macros.md#macros).
+Where possible you should use [symbolic macros](/versions/8.4.2/extending/macros#macros).
 
 Symbolic macros
 
@@ -18,7 +18,7 @@ Symbolic macros
 *   Take typed attributes, which in turn means automatic label and select
     conversion.
 *   Are more readable
-*   Will soon have [lazy evaluation](macros.md/laziness)
+*   Will soon have [lazy evaluation](/versions/8.4.2/extending/macros#laziness)
 
 ## Usage {#usage}
 
@@ -152,7 +152,7 @@ the macro), use the function
 ## Label resolution in macros {#label-resolution}
 
 Since legacy macros are evaluated in the
-[loading phase](concepts.md#evaluation-model), label strings such as
+[loading phase](/versions/8.4.2/extending/concepts#evaluation-model), label strings such as
 `"//foo:bar"` that occur in a legacy macro are interpreted relative to the
 `BUILD` file in which the macro is used rather than relative to the `.bzl` file
 in which it is defined. This behavior is generally undesirable for macros that
diff --git a/versions/8.4.2/extending/macros.mdx b/versions/8.4.2/extending/macros.mdx
index 068d15fb..e5a7e67c 100644
--- a/versions/8.4.2/extending/macros.mdx
+++ b/versions/8.4.2/extending/macros.mdx
@@ -10,7 +10,7 @@ Macros are mainly used for encapsulation and code reuse of existing rules and
 other macros.
 
 Macros come in two flavors: symbolic macros, which are described on this page,
-and [legacy macros](legacy-macros.md). Where possible, we recommend using
+and [legacy macros](/versions/8.4.2/extending/legacy-macros). Where possible, we recommend using
 symbolic macros for code clarity.
 
 Symbolic macros offer typed arguments (string to label conversion, relative to
@@ -31,8 +31,7 @@ two required parameters: `attrs` and `implementation`.
 
 ### Attributes {#attributes}
 
-`attrs` accepts a dictionary of attribute name to [attribute
-types](https://bazel.build/rules/lib/toplevel/attr#members), which represents
+`attrs` accepts a dictionary of attribute name to [attribute types](https://bazel.build/versions/8.4.2/rules/lib/toplevel/attr#members), which represents
 the arguments to the macro. Two common attributes – `name` and `visibility` –
 are implicitly added to all macros and are not included in the dictionary passed
 to `attrs`.
@@ -66,9 +65,7 @@ To support this pattern, a macro can *inherit attributes* from a rule or another
 macro by passing the [rule](https://bazel.build/versions/8.4.2/rules/lib/builtins/rule) or
 [macro symbol](https://bazel.build/versions/8.4.2/rules/lib/builtins/macro) to `macro()`'s
 `inherit_attrs` argument. (You can also use the special string `"common"`
-instead of a rule or macro symbol to inherit the [common attributes defined for
-all Starlark build
-rules](https://bazel.build/reference/be/common-definitions#common-attributes).)
+instead of a rule or macro symbol to inherit the [common attributes defined for all Starlark build rules](https://bazel.build/versions/8.4.2/reference/be/common-definitions#common-attributes).)
 Only public attributes get inherited, and the attributes in the macro's own
 `attrs` dictionary override inherited attributes with the same name. You can
 also *remove* inherited attributes by using `None` as a value in the `attrs`
diff --git a/versions/8.4.2/extending/platforms.mdx b/versions/8.4.2/extending/platforms.mdx
index 8d9bd1c1..31ef5469 100644
--- a/versions/8.4.2/extending/platforms.mdx
+++ b/versions/8.4.2/extending/platforms.mdx
@@ -245,8 +245,7 @@ cc_library(
 
 You can use the
 [`IncompatiblePlatformProvider`](/versions/8.4.2/rules/lib/providers/IncompatiblePlatformProvider)
-in `bazel cquery`'s [Starlark output
-format](/versions/8.4.2/query/cquery#output-format-definition) to distinguish
+in `bazel cquery`'s [Starlark output format](/versions/8.4.2/query/cquery#output-format-definition) to distinguish
 incompatible targets from compatible ones.
 
 This can be used to filter out incompatible targets. The example below will
@@ -266,5 +265,4 @@ $ bazel cquery //... --output=starlark --starlark:file=example.cquery
 
 ### Known Issues
 
-Incompatible targets [ignore visibility
-restrictions](https://github.com/bazelbuild/bazel/issues/16044).
+Incompatible targets [ignore visibility restrictions](https://github.com/bazelbuild/bazel/issues/16044).
diff --git a/versions/8.4.2/extending/repo.mdx b/versions/8.4.2/extending/repo.mdx
index 0744dc40..9dbc0c92 100644
--- a/versions/8.4.2/extending/repo.mdx
+++ b/versions/8.4.2/extending/repo.mdx
@@ -74,8 +74,7 @@ specified.
 
 The input parameter `repository_ctx` can be used to access attribute values, and
 non-hermetic functions (finding a binary, executing a binary, creating a file in
-the repository or downloading a file from the Internet). See [the API
-docs](/versions/8.4.2/rules/lib/builtins/repository_ctx) for more context. Example:
+the repository or downloading a file from the Internet). See [the API docs](/versions/8.4.2/rules/lib/builtins/repository_ctx) for more context. Example:
 
 ```python
 def _impl(repository_ctx):
@@ -144,8 +143,7 @@ definition has the `configure` attribute set, use `bazel fetch --force
 
 ## Examples
 
--   [C++ auto-configured
-    toolchain](https://cs.opensource.google/bazel/bazel/+/master:tools/cpp/cc_configure.bzl;drc=644b7d41748e09eff9e47cbab2be2263bb71f29a;l=176):
+-   [C++ auto-configured toolchain](https://cs.opensource.google/bazel/bazel/+/master:tools/cpp/cc_configure.bzl;drc=644b7d41748e09eff9e47cbab2be2263bb71f29a;l=176):
     it uses a repo rule to automatically create the C++ configuration files for
     Bazel by looking for the local C++ compiler, the environment and the flags
     the C++ compiler supports.
diff --git a/versions/8.4.2/extending/rules.mdx b/versions/8.4.2/extending/rules.mdx
index 4bc21657..37ca68fe 100644
--- a/versions/8.4.2/extending/rules.mdx
+++ b/versions/8.4.2/extending/rules.mdx
@@ -449,8 +449,7 @@ def _example_library_impl(ctx):
 
 If `DefaultInfo` is not returned by a rule implementation or the `files`
 parameter is not specified, `DefaultInfo.files` defaults to all
-*predeclared outputs* (generally, those created by [output
-attributes](#output_attributes)).
+*predeclared outputs* (generally, those created by [output attributes](#output_attributes)).
 
 Rules that perform actions should provide default outputs, even if those outputs
 are not expected to be directly used. Actions that are not in the graph of the
@@ -995,8 +994,7 @@ By using `configuration_field`, the dependency on the Java LCOV merger tool can
 be avoided as long as coverage is not requested.
 
 When the test is run, it should emit coverage information in the form of one or
-more [LCOV files]
-(https://manpages.debian.org/unstable/lcov/geninfo.1.en.html#TRACEFILE_FORMAT)
+more [LCOV files](https://manpages.debian.org/unstable/lcov/geninfo.1.en.html#TRACEFILE_FORMAT)
 with unique names into the directory specified by the `COVERAGE_DIR` environment
 variable. Bazel will then merge these files into a single LCOV file using the
 `_lcov_merger` tool. If present, it will also collect C/C++ coverage using the
diff --git a/versions/8.4.2/extending/toolchains.mdx b/versions/8.4.2/extending/toolchains.mdx
index 810e6469..0bc673c9 100644
--- a/versions/8.4.2/extending/toolchains.mdx
+++ b/versions/8.4.2/extending/toolchains.mdx
@@ -523,8 +523,7 @@ The set of available toolchains, in priority order, is created from
   4. Toolchains registered in the "WORKSPACE suffix"; this is only used by
      certain native rules bundled with the Bazel installation.
 
-**NOTE:** [Pseudo-targets like `:all`, `:*`, and
-`/...`](/versions/8.4.2/run/build#specifying-build-targets) are ordered by Bazel's package
+**NOTE:** [Pseudo-targets like `:all`, `:*`, and `/...`](/versions/8.4.2/run/build#specifying-build-targets) are ordered by Bazel's package
 loading mechanism, which uses a lexicographic ordering.
 
 The resolution steps are as follows.
diff --git a/versions/8.4.2/external/advanced.mdx b/versions/8.4.2/external/advanced.mdx
index 63520d82..98dd9ab8 100644
--- a/versions/8.4.2/external/advanced.mdx
+++ b/versions/8.4.2/external/advanced.mdx
@@ -4,10 +4,8 @@ title: 'Advanced topics on external dependencies'
 
 ## Shadowing dependencies in WORKSPACE
 
-Note: This section applies to the [WORKSPACE
-system](/versions/8.4.2/external/overview#workspace-system) only. For
-[Bzlmod](/versions/8.4.2/external/overview#bzlmod), use a [multiple-version
-override](/versions/8.4.2/external/module#multiple-version_override).
+Note: This section applies to the [WORKSPACE system](/versions/8.4.2/external/overview#workspace-system) only. For
+[Bzlmod](/versions/8.4.2/external/overview#bzlmod), use a [multiple-version override](/versions/8.4.2/external/module#multiple-version_override).
 
 Whenever possible, have a single version policy in your project, which is
 required for dependencies that you compile against and end up in your final
@@ -128,29 +126,24 @@ preferring IPv4 if enabled. In some situations, for example when the IPv4
 network cannot resolve/reach external addresses, this can cause `Network
 unreachable` exceptions and build failures. In these cases, you can override
 Bazel's behavior to prefer IPv6 by using the
-[`java.net.preferIPv6Addresses=true` system
-property](https://docs.oracle.com/javase/8/docs/api/java/net/doc-files/net-properties.html).
+[`java.net.preferIPv6Addresses=true` system property](https://docs.oracle.com/javase/8/docs/api/java/net/doc-files/net-properties.html).
 Specifically:
 
-*   Use `--host_jvm_args=-Djava.net.preferIPv6Addresses=true` [startup
-    option](/versions/8.4.2/docs/user-manual#startup-options), for example by adding the
+*   Use `--host_jvm_args=-Djava.net.preferIPv6Addresses=true` [startup option](/versions/8.4.2/docs/user-manual#startup-options), for example by adding the
     following line in your [`.bazelrc` file](/versions/8.4.2/run/bazelrc):
 
     `startup --host_jvm_args=-Djava.net.preferIPv6Addresses=true`
 
 *   When running Java build targets that need to connect to the internet (such
     as for integration tests), use the
-    `--jvmopt=-Djava.net.preferIPv6Addresses=true` [tool
-    flag](/versions/8.4.2/docs/user-manual#jvmopt). For example, include in your [`.bazelrc`
-    file](/versions/8.4.2/run/bazelrc):
+    `--jvmopt=-Djava.net.preferIPv6Addresses=true` [tool flag](/versions/8.4.2/docs/user-manual#jvmopt). For example, include in your [`.bazelrc` file](/versions/8.4.2/run/bazelrc):
 
     `build --jvmopt=-Djava.net.preferIPv6Addresses`
 
 *   If you are using [`rules_jvm_external`](https://github.com/bazelbuild/rules_jvm_external)
     for dependency version resolution, also add
     `-Djava.net.preferIPv6Addresses=true` to the `COURSIER_OPTS` environment
-    variable to [provide JVM options for
-    Coursier](https://github.com/bazelbuild/rules_jvm_external#provide-jvm-options-for-coursier-with-coursier_opts).
+    variable to [provide JVM options for Coursier](https://github.com/bazelbuild/rules_jvm_external#provide-jvm-options-for-coursier-with-coursier_opts).
 
 ## Offline builds
 
@@ -167,15 +160,12 @@ fetch a file with [`ctx.download`](/versions/8.4.2/rules/lib/builtins/repository
 providing a hash sum of the file needed, Bazel looks for a file matching the
 basename of the first URL, and uses the local copy if the hash matches.
 
-Bazel itself uses this technique to bootstrap offline from the [distribution
-artifact](https://github.com/bazelbuild/bazel-website/blob/master/designs/_posts/2016-10-11-distribution-artifact.md).
-It does so by [collecting all the needed external
-dependencies](https://github.com/bazelbuild/bazel/blob/5cfa0303d6ac3b5bd031ff60272ce80a704af8c2/WORKSPACE#L116)
+Bazel itself uses this technique to bootstrap offline from the [distribution artifact](https://github.com/bazelbuild/bazel-website/blob/master/designs/_posts/2016-10-11-distribution-artifact.md).
+It does so by [collecting all the needed external dependencies](https://github.com/bazelbuild/bazel/blob/5cfa0303d6ac3b5bd031ff60272ce80a704af8c2/WORKSPACE#L116)
 in an internal
 [`distdir_tar`](https://github.com/bazelbuild/bazel/blob/5cfa0303d6ac3b5bd031ff60272ce80a704af8c2/distdir.bzl#L44).
 
 Bazel allows execution of arbitrary commands in repository rules without knowing
 if they call out to the network, and so cannot enforce fully offline builds. To
 test if a build works correctly offline, manually block off the network (as
-Bazel does in its [bootstrap
-test](https://cs.opensource.google/bazel/bazel/+/master:src/test/shell/bazel/BUILD;l=1073;drc=88c426e73cc0eb0a41c0d7995e36acd94e7c9a48)).
\ No newline at end of file
+Bazel does in its [bootstrap test](https://cs.opensource.google/bazel/bazel/+/master:src/test/shell/bazel/BUILD;l=1073;drc=88c426e73cc0eb0a41c0d7995e36acd94e7c9a48)).
\ No newline at end of file
diff --git a/versions/8.4.2/external/images/mod_exampleBefore.svg b/versions/8.4.2/external/images/mod_exampleBefore.svg
new file mode 100644
index 00000000..66f01303
--- /dev/null
+++ b/versions/8.4.2/external/images/mod_exampleBefore.svg
@@ -0,0 +1,175 @@
+
+
+
+
+
+
+mygraph
+
+
+
+<root>
+
+<root> (my_project@1.0)
+
+
+
+bazel_skylib@1.1.1
+
+bazel_skylib@1.1.1
+
+
+
+<root>->bazel_skylib@1.1.1
+
+
+
+
+
+bazel_skylib@1.2.0
+
+bazel_skylib@1.2.0
+
+
+
+<root>->bazel_skylib@1.2.0
+
+
+
+
+
+rules_java@5.0.0
+
+rules_java@5.0.0
+
+
+
+<root>->rules_java@5.0.0
+
+
+
+
+
+stardoc@0.5.0
+
+stardoc@0.5.0
+
+
+
+<root>->stardoc@0.5.0
+
+
+
+
+
+platforms@0.0.4
+
+platforms@0.0.4
+
+
+
+bazel_skylib@1.1.1->platforms@0.0.4
+
+
+
+
+
+bazel_skylib@1.2.0->platforms@0.0.4
+
+
+
+
+
+rules_java@5.0.0->platforms@0.0.4
+
+
+
+
+
+rules_cc@0.0.1
+
+rules_cc@0.0.1
+
+
+
+rules_java@5.0.0->rules_cc@0.0.1
+
+
+
+
+
+rules_proto@4.0.0
+
+rules_proto@4.0.0
+
+
+
+rules_java@5.0.0->rules_proto@4.0.0
+
+
+
+
+
+bazel_skylib@1.0.3
+
+bazel_skylib@1.0.3
+
+
+
+stardoc@0.5.0->bazel_skylib@1.0.3
+
+
+
+
+
+rules_java@4.0.0
+
+rules_java@4.0.0
+
+
+
+stardoc@0.5.0->rules_java@4.0.0
+
+
+
+
+
+rules_cc@0.0.1->platforms@0.0.4
+
+
+
+
+
+rules_cc@0.0.1->bazel_skylib@1.0.3
+
+
+
+
+
+rules_proto@4.0.0->rules_cc@0.0.1
+
+
+
+
+
+rules_proto@4.0.0->bazel_skylib@1.0.3
+
+
+
+
+
+bazel_skylib@1.0.3->platforms@0.0.4
+
+
+
+
+
+rules_java@4.0.0->bazel_skylib@1.0.3
+
+
+
+
+
\ No newline at end of file
diff --git a/versions/8.4.2/external/images/mod_exampleResolved.svg b/versions/8.4.2/external/images/mod_exampleResolved.svg
new file mode 100644
index 00000000..224b694c
--- /dev/null
+++ b/versions/8.4.2/external/images/mod_exampleResolved.svg
@@ -0,0 +1,151 @@
+
+
+
+
+
+
+mygraph
+
+
+
+<root>
+
+<root> (my_project@1.0)
+
+
+
+bazel_skylib@1.1.1
+
+bazel_skylib@1.1.1
+
+
+
+<root>->bazel_skylib@1.1.1
+
+
+
+
+
+bazel_skylib@1.2.0
+
+bazel_skylib@1.2.0
+
+
+
+<root>->bazel_skylib@1.2.0
+
+
+
+
+
+rules_java@5.0.0
+
+rules_java@5.0.0
+
+
+
+<root>->rules_java@5.0.0
+
+
+
+
+
+stardoc@0.5.0
+
+stardoc@0.5.0
+
+
+
+<root>->stardoc@0.5.0
+
+
+
+
+
+platforms@0.0.4
+
+platforms@0.0.4
+
+
+
+bazel_skylib@1.1.1->platforms@0.0.4
+
+
+
+
+
+bazel_skylib@1.2.0->platforms@0.0.4
+
+
+
+
+
+rules_java@5.0.0->platforms@0.0.4
+
+
+
+
+
+rules_cc@0.0.1
+
+rules_cc@0.0.1
+
+
+
+rules_java@5.0.0->rules_cc@0.0.1
+
+
+
+
+
+rules_proto@4.0.0
+
+rules_proto@4.0.0
+
+
+
+rules_java@5.0.0->rules_proto@4.0.0
+
+
+
+
+
+stardoc@0.5.0->bazel_skylib@1.1.1
+
+
+
+
+
+stardoc@0.5.0->rules_java@5.0.0
+
+
+
+
+
+rules_cc@0.0.1->bazel_skylib@1.1.1
+
+
+
+
+
+rules_cc@0.0.1->platforms@0.0.4
+
+
+
+
+
+rules_proto@4.0.0->bazel_skylib@1.1.1
+
+
+
+
+
+rules_proto@4.0.0->rules_cc@0.0.1
+
+
+
+
+
\ No newline at end of file
diff --git a/versions/8.4.2/external/migration.mdx b/versions/8.4.2/external/migration.mdx
index e3d79ab4..bfdc6ad5 100644
--- a/versions/8.4.2/external/migration.mdx
+++ b/versions/8.4.2/external/migration.mdx
@@ -2,8 +2,7 @@
 title: 'Bzlmod Migration Guide'
 ---
 
-Due to the [shortcomings of
-WORKSPACE](/versions/8.4.2/external/overview#workspace-shortcomings), Bzlmod is going to
+Due to the [shortcomings of WORKSPACE](/versions/8.4.2/external/overview#workspace-shortcomings), Bzlmod is going to
 replace the legacy WORKSPACE system. The WORKSPACE file will be disabled by
 default in Bazel 8 (late 2024) and will be removed in Bazel 9 (late 2025).
 This guide helps you migrate your project to Bzlmod and drop WORKSPACE for
@@ -117,9 +116,7 @@ Bazel module when it also adopts Bzlmod.
 
 *   **Bzlmod**
 
-    With Bzlmod, as long as the your dependency is available in [Bazel Central
-    Registry](https://registry.bazel.build) or your custom [Bazel
-    registry](/versions/8.4.2/external/registry), you can simply depend on it with a
+    With Bzlmod, as long as the your dependency is available in [Bazel Central Registry](https://registry.bazel.build) or your custom [Bazel registry](/versions/8.4.2/external/registry), you can simply depend on it with a
     [`bazel_dep`](/versions/8.4.2/rules/lib/globals/module#bazel_dep) directive.
 
     ```python
@@ -150,8 +147,7 @@ repository.
 
 If your dependency is not a Bazel project or not yet available in any Bazel
 registry, you can introduce it using
-[`use_repo_rule`](/versions/8.4.2/external/module#use_repo_rule) or [module
-extensions](/versions/8.4.2/external/extension).
+[`use_repo_rule`](/versions/8.4.2/external/module#use_repo_rule) or [module extensions](/versions/8.4.2/external/extension).
 
 *   **WORKSPACE**
 
@@ -604,8 +600,7 @@ macros.
 Fortunately, the flag
 [`--experimental_repository_resolved_file`][resolved_file_flag]
 can help. This flag essentially generates a "lock file" of all fetched external
-dependencies in your last Bazel command. You can find more details in this [blog
-post](https://blog.bazel.build/2018/07/09/bazel-sync-and-resolved-file.html).
+dependencies in your last Bazel command. You can find more details in this [blog post](https://blog.bazel.build/2018/07/09/bazel-sync-and-resolved-file.html).
 
 [resolved_file_flag]: /reference/command-line-reference#flag--experimental_repository_resolved_file
 
@@ -646,11 +641,9 @@ You may also know `bazel query` can be used for inspecting repository rules with
 bazel query --output=build //external:
 ```
 
-While it is more convenient and much faster, [bazel query can lie about
-external dependency version](https://github.com/bazelbuild/bazel/issues/12947),
+While it is more convenient and much faster, [bazel query can lie about external dependency version](https://github.com/bazelbuild/bazel/issues/12947),
 so be careful using it! Querying and inspecting external
-dependencies with Bzlmod is going to achieved by a [new
-subcommand](https://github.com/bazelbuild/bazel/issues/15365).
+dependencies with Bzlmod is going to achieved by a [new subcommand](https://github.com/bazelbuild/bazel/issues/15365).
 
 #### Built-in default dependencies {#builtin-default-deps}
 
@@ -697,8 +690,7 @@ Using the WORKSPACE.bzlmod file can make the migration easier because:
 #### Repository visibility {#repository-visibility}
 
 Bzlmod is able to control which other repositories are visible from a given
-repository, check [repository names and strict
-deps](/versions/8.4.2/external/module#repository_names_and_strict_deps) for more details.
+repository, check [repository names and strict deps](/versions/8.4.2/external/module#repository_names_and_strict_deps) for more details.
 
 Here is a summary of repository visibilities from different types of
 repositories when also taking WORKSPACE into consideration.
@@ -711,8 +703,7 @@ repositories when also taking WORKSPACE into consideration.
 | WORKSPACE Repos | All visible | Not visible | Not visible | All visible |
 
 Note: For the root module, if a repository `@foo` is defined in WORKSPACE and
-`@foo` is also used as an [apparent repository
-name](/versions/8.4.2/external/overview#apparent-repo-name) in MODULE.bazel, then `@foo`
+`@foo` is also used as an [apparent repository name](/versions/8.4.2/external/overview#apparent-repo-name) in MODULE.bazel, then `@foo`
 refers to the one introduced in MODULE.bazel.
 
 Note: For a module extension generated repository `@bar`, if `@foo` is used as
@@ -787,9 +778,7 @@ the project. Take note of a few things when creating the source archive:
     GitHub isn't going to guarantee the checksum of source archives generated on
     demand. In short, URLs in the form of
     `https://github.com///releases/download/...` is considered stable
-    while `https://github.com///archive/...` is not. Check [GitHub
-    Archive Checksum
-    Outage](https://blog.bazel.build/2023/02/15/github-archive-checksum.html)
+    while `https://github.com///archive/...` is not. Check [GitHub Archive Checksum Outage](https://blog.bazel.build/2023/02/15/github-archive-checksum.html)
     for more context.
 
 *   **Make sure the source tree follows the layout of the original repository.**
@@ -818,8 +807,7 @@ Pull Request.
 
 [bcr_contrib_guide]: https://github.com/bazelbuild/bazel-central-registry/tree/main/docs#contribute-a-bazel-module
 
-It is **highly recommended** to set up the [Publish to
-BCR](https://github.com/bazel-contrib/publish-to-bcr) GitHub App for your
+It is **highly recommended** to set up the [Publish to BCR](https://github.com/bazel-contrib/publish-to-bcr) GitHub App for your
 repository to automate the process of submitting your module to the BCR.
 
 ## Best practices {#best-practices}
diff --git a/versions/8.4.2/external/mod-command.mdx b/versions/8.4.2/external/mod-command.mdx
index e49acc52..e27755a5 100644
--- a/versions/8.4.2/external/mod-command.mdx
+++ b/versions/8.4.2/external/mod-command.mdx
@@ -61,11 +61,9 @@ The available subcommands and their respective required arguments are:
 
 *   ``: All present versions of the module ``.
 
-*   `@`: The repo with the given [apparent
-    name](overview#apparent-repo-name) in the context of the `--base_module`.
+*   `@`: The repo with the given [apparent name](/versions/8.4.2/external/overview#apparent-repo-name) in the context of the `--base_module`.
 
-*   `@@`: The repo with the given [canonical
-    name](overview#canonical-repo-name).
+*   `@@`: The repo with the given [canonical name](/versions/8.4.2/external/overview#canonical-repo-name).
 
 In a context requiring specifying modules, ``s referring to repos that
 correspond to modules (as opposed to extension-generated repos) can also be
@@ -87,8 +85,7 @@ The following options only affect the subcommands that print graphs (`graph`,
     information about the version resolution of each module. If the module
     version changed during resolution, show either which version replaced it or
     what was the original version, the reason it was replaced, and which modules
-    requested the new version if the reason was [Minimal Version
-    Selection](module#version-selection).
+    requested the new version if the reason was [Minimal Version Selection](/versions/8.4.2/external/module#version-selection).
 
 *   `--include_unused` *default: "false"*: Include in the output graph the
     modules which were originally present in the dependency graph, but became
@@ -192,7 +189,7 @@ use_repo(toolchains, my_jdk="remotejdk17_linux")
   

     
       

-        Graph Before Resolution
+        Graph Before Resolution
         
Graph Before Resolution

       

 {/* digraph mygraph {
@@ -222,7 +219,7 @@ use_repo(toolchains, my_jdk="remotejdk17_linux")
     		
     
       

-        Graph After Resolution
+        Graph After Resolution
        
Graph After Resolution

       

 {/* digraph mygraph {
diff --git a/versions/8.4.2/external/module.mdx b/versions/8.4.2/external/module.mdx
index f99f6cfa..211773e9 100644
--- a/versions/8.4.2/external/module.mdx
+++ b/versions/8.4.2/external/module.mdx
@@ -122,8 +122,7 @@ serves multiple purposes:
     version, regardless of which versions of the dependency are requested in the
     dependency graph.
 *   With the `registry` attribute, you can force this dependency to come from a
-    specific registry, instead of following the normal [registry
-    selection](/versions/8.4.2/external/registry#selecting_registries) process.
+    specific registry, instead of following the normal [registry selection](/versions/8.4.2/external/registry#selecting_registries) process.
 *   With the `patch*` attributes, you can specify a set of patches to apply to
     the downloaded module.
 
@@ -176,13 +175,11 @@ With `bazel_dep`, you can define repos that represent other Bazel modules.
 Sometimes there is a need to define a repo that does _not_ represent a Bazel
 module; for example, one that contains a plain JSON file to be read as data.
 
-In this case, you could use the [`use_repo_rule`
-directive](/versions/8.4.2/rules/lib/globals/module#use_repo_rule) to directly define a repo
+In this case, you could use the [`use_repo_rule` directive](/versions/8.4.2/rules/lib/globals/module#use_repo_rule) to directly define a repo
 by invoking a repo rule. This repo will only be visible to the module it's
 defined in.
 
-Under the hood, this is implemented using the same mechanism as [module
-extensions](/versions/8.4.2/external/extension), which lets you define repos with more
+Under the hood, this is implemented using the same mechanism as [module extensions](/versions/8.4.2/external/extension), which lets you define repos with more
 flexibility.
 
 ## Repository names and strict deps
diff --git a/versions/8.4.2/external/overview.mdx b/versions/8.4.2/external/overview.mdx
index f478bfc8..1bd53ef6 100644
--- a/versions/8.4.2/external/overview.mdx
+++ b/versions/8.4.2/external/overview.mdx
@@ -128,8 +128,7 @@ for all build targets inside the repo.
 
 The syntax of a `REPO.bazel` file is similar to `BUILD` files, except that no
 `load` statements are supported, and only a single function, `repo()`, is
-available. `repo()` takes the same arguments as the [`package()`
-function](/versions/8.4.2/reference/be/functions#package) in `BUILD` files; whereas `package()`
+available. `repo()` takes the same arguments as the [`package()` function](/versions/8.4.2/reference/be/functions#package) in `BUILD` files; whereas `package()`
 specifies common attributes for all build targets inside the package, `repo()`
 analogously does so for all build targets inside the repo.
 
@@ -163,8 +162,7 @@ bazel_dep(name = "protobuf", version = "3.19.0")
 ```
 
 A module must only list its direct dependencies, which Bzlmod looks up in a
-[Bazel registry](/versions/8.4.2/external/registry) — by default, the [Bazel Central
-Registry](https://bcr.bazel.build/). The registry provides the
+[Bazel registry](/versions/8.4.2/external/registry) — by default, the [Bazel Central Registry](https://bcr.bazel.build/). The registry provides the
 dependencies' `MODULE.bazel` files, which allows Bazel to discover the entire
 transitive dependency graph before performing version resolution.
 
@@ -235,5 +233,4 @@ many pain points, including:
         `B` and `C`; `B` and `C` both depend on different versions of `D`).
 
 Due to the shortcomings of WORKSPACE, Bzlmod is going to replace the legacy
-WORKSPACE system in future Bazel releases. Please read the [Bzlmod migration
-guide](/versions/8.4.2/external/migration) on how to migrate to Bzlmod.
+WORKSPACE system in future Bazel releases. Please read the [Bzlmod migration guide](/versions/8.4.2/external/migration) on how to migrate to Bzlmod.
diff --git a/versions/8.4.2/external/registry.mdx b/versions/8.4.2/external/registry.mdx
index fe14da63..616bef30 100644
--- a/versions/8.4.2/external/registry.mdx
+++ b/versions/8.4.2/external/registry.mdx
@@ -42,8 +42,7 @@ An index registry must follow the format below:
             project
         *   `versions`: A list of all the versions of this module to be found in
             this registry
-        *   `yanked_versions`: A map of [*yanked*
-            versions](/versions/8.4.2/external/module#yanked_versions) of this module. The keys
+        *   `yanked_versions`: A map of [*yanked* versions](/versions/8.4.2/external/module#yanked_versions) of this module. The keys
             should be versions to yank and the values should be descriptions of
             why the version is yanked, ideally containing a link to more
             information
@@ -56,8 +55,7 @@ An index registry must follow the format below:
             *   `url`: The URL of the source archive
             *   `mirror_urls`: A list of string, the mirror URLs of the source archive.
                 The URLs are tried in order after `url` as backups.
-            *   `integrity`: The [Subresource
-                Integrity](https://w3c.github.io/webappsec-subresource-integrity/#integrity-metadata-description)
+            *   `integrity`: The [Subresource Integrity](https://w3c.github.io/webappsec-subresource-integrity/#integrity-metadata-description)
                 checksum of the archive
             *   `strip_prefix`: A directory prefix to strip when extracting the
                 source archive
@@ -105,8 +103,7 @@ You can browse its contents using the web frontend at
 https://registry.bazel.build/.
 
 The Bazel community maintains the BCR, and contributors are welcome to submit
-pull requests. See the [BCR contribution
-guidelines](https://github.com/bazelbuild/bazel-central-registry/blob/main/docs/README.md).
+pull requests. See the [BCR contribution guidelines](https://github.com/bazelbuild/bazel-central-registry/blob/main/docs/README.md).
 
 In addition to following the format of a normal index registry, the BCR requires
 a `presubmit.yml` file for each module version
diff --git a/versions/8.4.2/external/vendor.mdx b/versions/8.4.2/external/vendor.mdx
index 22d6c65a..fa441fd5 100644
--- a/versions/8.4.2/external/vendor.mdx
+++ b/versions/8.4.2/external/vendor.mdx
@@ -23,9 +23,7 @@ absolute path.
 ## Vendor a specific external repository {#vendor-specific-repository}
 
 You can use the `vendor` command with the `--repo` flag to specify which repo
-to vendor, it accepts both [canonical repo
-name](/versions/8.4.2/external/overview#canonical-repo-name) and [apparent repo
-name](/versions/8.4.2/external/overview#apparent-repo-name).
+to vendor, it accepts both [canonical repo name](/versions/8.4.2/external/overview#canonical-repo-name) and [apparent repo name](/versions/8.4.2/external/overview#apparent-repo-name).
 
 For example, running:
 
diff --git a/versions/8.4.2/help.mdx b/versions/8.4.2/help.mdx
index 3c5ebd27..1aef1e7c 100644
--- a/versions/8.4.2/help.mdx
+++ b/versions/8.4.2/help.mdx
@@ -46,5 +46,4 @@ what level of support Bazel provides.
 
 ## File a bug {#file-bug}
 
-If you encounter a bug or want to request a feature, file a [GitHub
-Issue](https://github.com/bazelbuild/bazel/issues).
+If you encounter a bug or want to request a feature, file a [GitHub Issue](https://github.com/bazelbuild/bazel/issues).
diff --git a/versions/8.4.2/images/about.svg b/versions/8.4.2/images/about.svg
new file mode 100644
index 00000000..f927298f
--- /dev/null
+++ b/versions/8.4.2/images/about.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/8.4.2/images/basics.svg b/versions/8.4.2/images/basics.svg
new file mode 100644
index 00000000..013ec519
--- /dev/null
+++ b/versions/8.4.2/images/basics.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/8.4.2/images/bazel_hero.svg b/versions/8.4.2/images/bazel_hero.svg
new file mode 100644
index 00000000..c48714d0
--- /dev/null
+++ b/versions/8.4.2/images/bazel_hero.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/8.4.2/images/community.svg b/versions/8.4.2/images/community.svg
new file mode 100644
index 00000000..29f87a76
--- /dev/null
+++ b/versions/8.4.2/images/community.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/8.4.2/images/distributed-build-remote-cache.png b/versions/8.4.2/images/distributed-build-remote-cache.png
new file mode 100644
index 00000000..99d8a915
Binary files /dev/null and b/versions/8.4.2/images/distributed-build-remote-cache.png differ
diff --git a/versions/8.4.2/images/essential_guide.svg b/versions/8.4.2/images/essential_guide.svg
new file mode 100644
index 00000000..4ee63ae9
--- /dev/null
+++ b/versions/8.4.2/images/essential_guide.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/8.4.2/images/essential_reference.svg b/versions/8.4.2/images/essential_reference.svg
new file mode 100644
index 00000000..4d29a8d5
--- /dev/null
+++ b/versions/8.4.2/images/essential_reference.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/8.4.2/images/essential_start.svg b/versions/8.4.2/images/essential_start.svg
new file mode 100644
index 00000000..c8f48f84
--- /dev/null
+++ b/versions/8.4.2/images/essential_start.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/8.4.2/images/extend.svg b/versions/8.4.2/images/extend.svg
new file mode 100644
index 00000000..77b2dd97
--- /dev/null
+++ b/versions/8.4.2/images/extend.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/8.4.2/images/guide.svg b/versions/8.4.2/images/guide.svg
new file mode 100644
index 00000000..23a5d35a
--- /dev/null
+++ b/versions/8.4.2/images/guide.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/8.4.2/images/high-level-build-system.png b/versions/8.4.2/images/high-level-build-system.png
new file mode 100644
index 00000000..462717fa
Binary files /dev/null and b/versions/8.4.2/images/high-level-build-system.png differ
diff --git a/versions/8.4.2/images/new_1.svg b/versions/8.4.2/images/new_1.svg
new file mode 100644
index 00000000..c4cd9dfd
--- /dev/null
+++ b/versions/8.4.2/images/new_1.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/8.4.2/images/new_2.svg b/versions/8.4.2/images/new_2.svg
new file mode 100644
index 00000000..c6b7021b
--- /dev/null
+++ b/versions/8.4.2/images/new_2.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/8.4.2/images/new_3.svg b/versions/8.4.2/images/new_3.svg
new file mode 100644
index 00000000..c2afb4ac
--- /dev/null
+++ b/versions/8.4.2/images/new_3.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/8.4.2/images/placeholder.png b/versions/8.4.2/images/placeholder.png
new file mode 100644
index 00000000..54f1fa0e
Binary files /dev/null and b/versions/8.4.2/images/placeholder.png differ
diff --git a/versions/8.4.2/images/reference.svg b/versions/8.4.2/images/reference.svg
new file mode 100644
index 00000000..7bbc9bea
--- /dev/null
+++ b/versions/8.4.2/images/reference.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/8.4.2/images/release_notes.svg b/versions/8.4.2/images/release_notes.svg
new file mode 100644
index 00000000..8a2e8b56
--- /dev/null
+++ b/versions/8.4.2/images/release_notes.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/8.4.2/images/remote-execution-system.png b/versions/8.4.2/images/remote-execution-system.png
new file mode 100644
index 00000000..8152fc0c
Binary files /dev/null and b/versions/8.4.2/images/remote-execution-system.png differ
diff --git a/versions/8.4.2/images/start.svg b/versions/8.4.2/images/start.svg
new file mode 100644
index 00000000..3bcebd7b
--- /dev/null
+++ b/versions/8.4.2/images/start.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/8.4.2/images/task-dependencies.png b/versions/8.4.2/images/task-dependencies.png
new file mode 100644
index 00000000..ae1f9c51
Binary files /dev/null and b/versions/8.4.2/images/task-dependencies.png differ
diff --git a/versions/8.4.2/images/test.png b/versions/8.4.2/images/test.png
new file mode 100644
index 00000000..243939da
Binary files /dev/null and b/versions/8.4.2/images/test.png differ
diff --git a/versions/8.4.2/images/transitive-dependencies.png b/versions/8.4.2/images/transitive-dependencies.png
new file mode 100644
index 00000000..ec641a08
Binary files /dev/null and b/versions/8.4.2/images/transitive-dependencies.png differ
diff --git a/versions/8.4.2/images/trunk-logo-dark.svg b/versions/8.4.2/images/trunk-logo-dark.svg
new file mode 100644
index 00000000..f25940af
--- /dev/null
+++ b/versions/8.4.2/images/trunk-logo-dark.svg
@@ -0,0 +1,22 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/versions/8.4.2/images/why_faq.svg b/versions/8.4.2/images/why_faq.svg
new file mode 100644
index 00000000..afec3f8f
--- /dev/null
+++ b/versions/8.4.2/images/why_faq.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/8.4.2/images/why_overview.svg b/versions/8.4.2/images/why_overview.svg
new file mode 100644
index 00000000..c10c363c
--- /dev/null
+++ b/versions/8.4.2/images/why_overview.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/8.4.2/images/why_vision.svg b/versions/8.4.2/images/why_vision.svg
new file mode 100644
index 00000000..739e415f
--- /dev/null
+++ b/versions/8.4.2/images/why_vision.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/8.4.2/install/bazelisk.mdx b/versions/8.4.2/install/bazelisk.mdx
index 89fb2cb9..79e33cab 100644
--- a/versions/8.4.2/install/bazelisk.mdx
+++ b/versions/8.4.2/install/bazelisk.mdx
@@ -16,8 +16,7 @@ For more details, see
 ## Updating Bazel
 
 Bazel has a [backward compatibility policy](/versions/8.4.2/release/backward-compatibility)
-(see [guidance for rolling out incompatible
-changes](/versions/8.4.2/contribute/breaking-changes) if you
+(see [guidance for rolling out incompatible changes](/versions/8.4.2/contribute/breaking-changes) if you
 are the author of one). That page summarizes best practices on how to test and
 migrate your project with upcoming incompatible changes and how to provide
 feedback to the incompatible change authors.
diff --git a/versions/8.4.2/install/compile-source.mdx b/versions/8.4.2/install/compile-source.mdx
index 5f6f2f57..245fa27e 100644
--- a/versions/8.4.2/install/compile-source.mdx
+++ b/versions/8.4.2/install/compile-source.mdx
@@ -45,8 +45,7 @@ it by typing `bazel` in a terminal.
 
 **Reason**: To build Bazel from a GitHub source tree, you need a pre-existing
 Bazel binary. You can install one from a package manager or download one from
-GitHub. See [Installing Bazel](/versions/8.4.2/install). (Or you can [build from
-scratch (bootstrap)](#bootstrap-bazel).)
+GitHub. See [Installing Bazel](/versions/8.4.2/install). (Or you can [build from scratch (bootstrap)](#bootstrap-bazel).)
 
 **Troubleshooting**:
 
@@ -239,8 +238,7 @@ For instructions for Unix-like systems, see
     ```
 
 *   **The Visual C++ compiler.** Install the Visual C++ compiler either as part
-    of Visual Studio 2015 or newer, or by installing the latest [Build Tools
-    for Visual Studio 2017](https://aka.ms/BuildTools).
+    of Visual Studio 2015 or newer, or by installing the latest [Build Tools for Visual Studio 2017](https://aka.ms/BuildTools).
 
 *   **JDK.** Version 21 is required.
 
diff --git a/versions/8.4.2/install/ide.mdx b/versions/8.4.2/install/ide.mdx
index 561d0e02..c42d95e9 100644
--- a/versions/8.4.2/install/ide.mdx
+++ b/versions/8.4.2/install/ide.mdx
@@ -38,10 +38,8 @@ To install, go to the IDE's plugin browser and search for `Bazel`.
 To manually install older versions, download the zip files from JetBrains'
 Plugin Repository and install the zip file from the IDE's plugin browser:
 
-*  [Android Studio
-   plugin](https://plugins.jetbrains.com/plugin/9185-android-studio-with-bazel)
-*  [IntelliJ
-   plugin](https://plugins.jetbrains.com/plugin/8609-intellij-with-bazel)
+*  [Android Studio plugin](https://plugins.jetbrains.com/plugin/9185-android-studio-with-bazel)
+*  [IntelliJ plugin](https://plugins.jetbrains.com/plugin/8609-intellij-with-bazel)
 *  [CLion plugin](https://plugins.jetbrains.com/plugin/9554-clion-with-bazel)
 
 ### Xcode {#xcode}
@@ -61,8 +59,7 @@ Features:
 * Starlark debugger for `.bzl` files during a build (set breakpoints, step
   through code, inspect variables, and so on)
 
-Find [the plugin on the Visual Studio
-marketplace](https://marketplace.visualstudio.com/items?itemName=BazelBuild.vscode-bazel).
+Find [the plugin on the Visual Studio marketplace](https://marketplace.visualstudio.com/items?itemName=BazelBuild.vscode-bazel).
 The plugin is [open source](https://github.com/bazelbuild/vscode-bazel).
 
 See also: [Autocomplete for Source Code](#autocomplete-for-source-code)
@@ -82,8 +79,7 @@ See also: [Autocomplete for Source Code](#autocomplete-for-source-code)
 
 ### Emacs {#emacs}
 
-See [`bazelbuild/bazel-emacs-mode` on
-GitHub](https://github.com/bazelbuild/emacs-bazel-mode)
+See [`bazelbuild/bazel-emacs-mode` on GitHub](https://github.com/bazelbuild/emacs-bazel-mode)
 
 See also: [Autocomplete for Source Code](#autocomplete-for-source-code)
 
@@ -115,6 +111,5 @@ tool for building Bazel targets when source files change.
 
 ## Building your own IDE plugin {#build-own-plugin}
 
-Read the [**IDE support** blog
-post](https://blog.bazel.build/2016/06/10/ide-support.html) to learn more about
+Read the [**IDE support** blog post](https://blog.bazel.build/2016/06/10/ide-support.html) to learn more about
 the Bazel APIs to use when building an IDE plugin.
diff --git a/versions/8.4.2/install/images/bazelisk.svg b/versions/8.4.2/install/images/bazelisk.svg
new file mode 100644
index 00000000..c0ae9f54
--- /dev/null
+++ b/versions/8.4.2/install/images/bazelisk.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/8.4.2/install/images/cli.svg b/versions/8.4.2/install/images/cli.svg
new file mode 100644
index 00000000..01119280
--- /dev/null
+++ b/versions/8.4.2/install/images/cli.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/8.4.2/install/images/docker.svg b/versions/8.4.2/install/images/docker.svg
new file mode 100644
index 00000000..21190ce0
--- /dev/null
+++ b/versions/8.4.2/install/images/docker.svg
@@ -0,0 +1,6 @@
+
\ No newline at end of file
diff --git a/versions/8.4.2/install/images/github.svg b/versions/8.4.2/install/images/github.svg
new file mode 100644
index 00000000..aa05db9c
--- /dev/null
+++ b/versions/8.4.2/install/images/github.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/8.4.2/install/images/install.svg b/versions/8.4.2/install/images/install.svg
new file mode 100644
index 00000000..ae080865
--- /dev/null
+++ b/versions/8.4.2/install/images/install.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/8.4.2/install/images/mac.svg b/versions/8.4.2/install/images/mac.svg
new file mode 100644
index 00000000..3ee4fe28
--- /dev/null
+++ b/versions/8.4.2/install/images/mac.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/8.4.2/install/images/redhat.svg b/versions/8.4.2/install/images/redhat.svg
new file mode 100644
index 00000000..078b3387
--- /dev/null
+++ b/versions/8.4.2/install/images/redhat.svg
@@ -0,0 +1,69 @@
+
+
+  
+    
+      
+        image/svg+xml
+        
+        
+      
+    
+  
+  
+  
+    
+  
+  
+  
+
diff --git a/versions/8.4.2/install/images/suse.png b/versions/8.4.2/install/images/suse.png
new file mode 100644
index 00000000..6435b689
Binary files /dev/null and b/versions/8.4.2/install/images/suse.png differ
diff --git a/versions/8.4.2/install/images/tune.svg b/versions/8.4.2/install/images/tune.svg
new file mode 100644
index 00000000..8d7d63cb
--- /dev/null
+++ b/versions/8.4.2/install/images/tune.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/8.4.2/install/images/ubuntu.svg b/versions/8.4.2/install/images/ubuntu.svg
new file mode 100644
index 00000000..f217bc8d
--- /dev/null
+++ b/versions/8.4.2/install/images/ubuntu.svg
@@ -0,0 +1,8 @@
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/versions/8.4.2/install/images/windows.svg b/versions/8.4.2/install/images/windows.svg
new file mode 100644
index 00000000..120b0190
--- /dev/null
+++ b/versions/8.4.2/install/images/windows.svg
@@ -0,0 +1,5 @@
+
+
+
+
+
\ No newline at end of file
diff --git a/versions/8.4.2/install/windows.mdx b/versions/8.4.2/install/windows.mdx
index 8db7ad81..3cd4173e 100644
--- a/versions/8.4.2/install/windows.mdx
+++ b/versions/8.4.2/install/windows.mdx
@@ -31,8 +31,7 @@ To check your Windows version:
 
 Alternatively you can:
 
-*   [Download the Bazel binary (`bazel-version-windows-x86_64.exe`) from
- GitHub](https://github.com/bazelbuild/bazel/releases).
+*   [Download the Bazel binary (`bazel-version-windows-x86_64.exe`) from GitHub](https://github.com/bazelbuild/bazel/releases).
 *   [Install Bazel from Chocolatey](#chocolately)
 *   [Install Bazel from Scoop](#scoop)
 *   [Build Bazel from source](/versions/8.4.2/install/compile-source)
@@ -208,8 +207,7 @@ If that doesn't help:
     its dependencies, such as the MSYS2 shell. This will not install Visual C++
     though.
 
-See [Chocolatey installation and package maintenance
-guide](/versions/8.4.2/contribute/windows-chocolatey-maintenance) for more
+See [Chocolatey installation and package maintenance guide](/versions/8.4.2/contribute/windows-chocolatey-maintenance) for more
 information about the Chocolatey package.
 
 ### Using Scoop {#scoop}
@@ -226,8 +224,7 @@ information about the Chocolatey package.
     scoop install bazel
     ```
 
-See [Scoop installation and package maintenance
-guide](/versions/8.4.2/contribute/windows-scoop-maintenance) for more
+See [Scoop installation and package maintenance guide](/versions/8.4.2/contribute/windows-scoop-maintenance) for more
 information about the Scoop package.
 
 ### Build from source {#build-from-source}
diff --git a/versions/8.4.2/migrate/maven.mdx b/versions/8.4.2/migrate/maven.mdx
index 159ca3f5..60348d55 100644
--- a/versions/8.4.2/migrate/maven.mdx
+++ b/versions/8.4.2/migrate/maven.mdx
@@ -19,8 +19,7 @@ directly run by Bazel since there's no Maven compatibility layer.
 ## Before you begin {#before-you-begin}
 
 *   [Install Bazel](/versions/8.4.2/install) if it's not yet installed.
-*   If you're new to Bazel, go through the tutorial [Introduction to Bazel:
-    Build Java](/versions/8.4.2/start/java) before you start migrating. The tutorial explains
+*   If you're new to Bazel, go through the tutorial [Introduction to Bazel: Build Java](/versions/8.4.2/start/java) before you start migrating. The tutorial explains
     Bazel's concepts, structure, and label syntax.
 
 ## Differences between Maven and Bazel {#dif-maven-bazel}
@@ -44,8 +43,7 @@ The steps below describe how to migrate your project to Bazel:
 3.  [Create more BUILD files](#3-build)
 4.  [Build using Bazel](#4-build)
 
-Examples below come from a migration of the [Guava
-project](https://github.com/google/guava) from Maven to Bazel. The
+Examples below come from a migration of the [Guava project](https://github.com/google/guava) from Maven to Bazel. The
 Guava project used is release `v31.1`. The examples using Guava do not walk
 through each step in the migration, but they do show the files and contents that
 are generated or added manually for the migration.
@@ -63,14 +61,12 @@ has no external dependencies, this file can be empty.
 If your project depends on files or packages that are not in one of the
 project's directories, specify these external dependencies in the MODULE.bazel
 file. You can use `rules_jvm_external` to manage dependencies from Maven. For
-instructions about using this ruleset, see [the
-README](https://github.com/bazelbuild/rules_jvm_external/#rules_jvm_external)
+instructions about using this ruleset, see [the README](https://github.com/bazelbuild/rules_jvm_external/#rules_jvm_external)
 .
 
 #### Guava project example: external dependencies {#guava-1}
 
-You can list the external dependencies of the [Guava
-project](https://github.com/google/guava) with the
+You can list the external dependencies of the [Guava project](https://github.com/google/guava) with the
 [`rules_jvm_external`](https://github.com/bazelbuild/rules_jvm_external)
 ruleset.
 
@@ -164,8 +160,7 @@ your build by adding more `BUILD` files with more granular targets.
             *   `resources`: Use globbing to list all resources in your project.
             *   `deps`: You need to determine which external dependencies your
                 project needs.
-        *   Take a look at the [example below of this top-level BUILD
-            file](#guava-2) from the migration of the Guava project.
+        *   Take a look at the [example below of this top-level BUILD file](#guava-2) from the migration of the Guava project.
 
 3.  Now that you have a `BUILD` file at the root of your project, build your
     project to ensure that it works. On the command line, from your workspace
diff --git a/versions/8.4.2/migrate/xcode.mdx b/versions/8.4.2/migrate/xcode.mdx
index 554706df..673593b7 100644
--- a/versions/8.4.2/migrate/xcode.mdx
+++ b/versions/8.4.2/migrate/xcode.mdx
@@ -32,8 +32,7 @@ Before you begin, do the following:
 
 1.  [Install Bazel](/versions/8.4.2/install) if you have not already done so.
 
-2.  If you're not familiar with Bazel and its concepts, complete the [iOS app
-    tutorial](/versions/8.4.2/start/ios-app)). You should understand the Bazel workspace,
+2.  If you're not familiar with Bazel and its concepts, complete the [iOS app tutorial](/versions/8.4.2/start/ios-app)). You should understand the Bazel workspace,
     including the `MODULE.bazel` and `BUILD` files, as well as the concepts of
     targets, build rules, and Bazel packages.
 
@@ -44,8 +43,7 @@ Before you begin, do the following:
 Unlike Xcode, Bazel requires you to explicitly declare all dependencies for
 every target in the `BUILD` file.
 
-For more information on external dependencies, see [Working with external
-dependencies](/versions/8.4.2/docs/external).
+For more information on external dependencies, see [Working with external dependencies](/versions/8.4.2/docs/external).
 
 ## Build or test an Xcode project with Bazel {#build-xcode-project}
 
@@ -84,8 +82,7 @@ Note: Place the project source code within the directory tree containing the
 
 To integrate SwiftPM dependencies into the Bazel workspace with
 [swift_bazel](https://github.com/cgrindel/swift_bazel), you must
-convert them into Bazel packages as described in the [following
-tutorial](https://chuckgrindel.com/swift-packages-in-bazel-using-swift_bazel/)
+convert them into Bazel packages as described in the [following tutorial](https://chuckgrindel.com/swift-packages-in-bazel-using-swift_bazel/)
 .
 
 Note: SwiftPM support is a manual process with many variables. SwiftPM
@@ -103,8 +100,7 @@ initial build of the project as follows:
 *   [Step 3b: (Optional) Add the test target(s)](#step-3b-optional-add-the-test-target-s)
 *   [Step 3c: Add the library target(s)](#step-3c-add-the-library-target-s)
 
-**Tip:** To learn more about packages and other Bazel concepts, see [Workspaces,
-packages, and targets](/versions/8.4.2/concepts/build-ref).
+**Tip:** To learn more about packages and other Bazel concepts, see [Workspaces, packages, and targets](/versions/8.4.2/concepts/build-ref).
 
 #### Step 3a: Add the application target {#add-app-target}
 
@@ -132,8 +128,7 @@ In the target, specify the following at the minimum:
 
 #### Step 3b: (Optional) Add the test target(s) {#add-test-target}
 
-Bazel's [Apple build
-rules](https://github.com/bazelbuild/rules_apple) support running
+Bazel's [Apple build rules](https://github.com/bazelbuild/rules_apple) support running
 unit and UI tests on all Apple platforms. Add test targets as follows:
 
 *   [`macos_unit_test`](https://github.com/bazelbuild/rules_apple/blob/master/doc/rules-macos.md#macos_unit_test)
@@ -181,8 +176,7 @@ all sources and/or headers of a certain type. Use it carefully as it might
 include files you do not want Bazel to build.
 
 You can browse existing examples for various types of applications directly in
-the [rules_apple examples
-directory](https://github.com/bazelbuild/rules_apple/tree/master/examples/). For
+the [rules_apple examples directory](https://github.com/bazelbuild/rules_apple/tree/master/examples/). For
 example:
 
 *   [macOS application targets](https://github.com/bazelbuild/rules_apple/tree/master/examples/macos)
@@ -191,8 +185,7 @@ example:
 
 *   [Multi platform applications (macOS, iOS, watchOS, tvOS)](https://github.com/bazelbuild/rules_apple/tree/master/examples/multi_platform)
 
-For more information on build rules, see [Apple Rules for
-Bazel](https://github.com/bazelbuild/rules_apple).
+For more information on build rules, see [Apple Rules for Bazel](https://github.com/bazelbuild/rules_apple).
 
 At this point, it is a good idea to test the build:
 
diff --git a/versions/8.4.2/query/cquery.mdx b/versions/8.4.2/query/cquery.mdx
index 8b469ece..3903397f 100644
--- a/versions/8.4.2/query/cquery.mdx
+++ b/versions/8.4.2/query/cquery.mdx
@@ -6,8 +6,7 @@ title: ' Configurable Query (cquery)'
 [`select()`](/versions/8.4.2/docs/configurable-attributes) and build options' effects on the build
 graph.
 
-It achieves this by running over the results of Bazel's [analysis
-phase](/versions/8.4.2/extending/concepts#evaluation-model),
+It achieves this by running over the results of Bazel's [analysis phase](/versions/8.4.2/extending/concepts#evaluation-model),
 which integrates these effects. `query`, by contrast, runs over the results of
 Bazel's loading phase, before options are evaluated.
 
@@ -137,8 +136,7 @@ $ bazel cquery //foo --universe_scope=//foo,//genrule_with_foo_as_tool
 If you want to precisely declare which instance to query over, use
 the [`config`](#config) function.
 
-See `query`'s [target pattern
-documentation](/versions/8.4.2/query/language#target-patterns) for more information on target patterns.
+See `query`'s [target pattern documentation](/versions/8.4.2/query/language#target-patterns) for more information on target patterns.
 
 ## Functions {#functions}
 
diff --git a/versions/8.4.2/query/images/query_graph1.png b/versions/8.4.2/query/images/query_graph1.png
new file mode 100644
index 00000000..7bc9a61a
Binary files /dev/null and b/versions/8.4.2/query/images/query_graph1.png differ
diff --git a/versions/8.4.2/query/images/query_graph2.png b/versions/8.4.2/query/images/query_graph2.png
new file mode 100644
index 00000000..a0da22ff
Binary files /dev/null and b/versions/8.4.2/query/images/query_graph2.png differ
diff --git a/versions/8.4.2/query/images/query_graph3.png b/versions/8.4.2/query/images/query_graph3.png
new file mode 100644
index 00000000..4418f193
Binary files /dev/null and b/versions/8.4.2/query/images/query_graph3.png differ
diff --git a/versions/8.4.2/query/language.mdx b/versions/8.4.2/query/language.mdx
index 7def9b63..28f6b002 100644
--- a/versions/8.4.2/query/language.mdx
+++ b/versions/8.4.2/query/language.mdx
@@ -1105,8 +1105,7 @@ is being used.
 
 ### On the ordering of results {#results-ordering}
 
-Although query expressions always follow the "[law of
-conservation of graph order](#graph-order)", _presenting_ the results may be done
+Although query expressions always follow the "[law of conservation of graph order](#graph-order)", _presenting_ the results may be done
 in either a dependency-ordered or unordered manner. This does **not**
 influence the targets in the result set or how the query is computed. It only
 affects how the results are printed to stdout. Moreover, nodes that are
@@ -1252,8 +1251,7 @@ and `maxrank` output formats print the labels of each
 target in the resulting graph, but instead of appearing in
 topological order, they appear in rank order, preceded by their
 rank number. These are unaffected by the result ordering
-`--[no]order_results` flag (see [notes on
-the ordering of results](#result-order)).
+`--[no]order_results` flag (see [notes on the ordering of results](#result-order)).
 
 There are two variants of this format: `minrank` ranks
 each node by the length of the shortest path from a root node to it.
diff --git a/versions/8.4.2/query/quickstart.mdx b/versions/8.4.2/query/quickstart.mdx
index 5c8894f9..8a912446 100644
--- a/versions/8.4.2/query/quickstart.mdx
+++ b/versions/8.4.2/query/quickstart.mdx
@@ -205,7 +205,7 @@ dot -Tpng < graph.in > graph.png
 ```
 If you open up `graph.png`, you should see something like this. The graph below has been simplified to make the essential path details clearer in this guide.
 
-![Diagram showing a relationship from cafe to chef to the dishes: pizza and mac and cheese which diverges into the separate ingredients: cheese, tomatoes, dough, and macaroni.](images/query_graph1.png "Dependency graph")
+![Diagram showing a relationship from cafe to chef to the dishes: pizza and mac and cheese which diverges into the separate ingredients: cheese, tomatoes, dough, and macaroni.](/versions/8.4.2/query/images/query_graph1.png "Dependency graph")
 
 This helps when you want to see the outputs of the different query functions throughout this guide.
 
@@ -421,7 +421,7 @@ bazel query --noimplicit_deps 'deps(:runner)' --output graph > graph2.in
 dot -Tpng < graph2.in > graph2.png
 ```
 
-[![The same graph as the first one except now there is a spoke stemming from the chef target with smoothie which leads to banana and strawberry](images/query_graph2.png "Updated dependency graph")](images/query_graph2.png)
+[![The same graph as the first one except now there is a spoke stemming from the chef target with smoothie which leads to banana and strawberry](/versions/8.4.2/query/images/query_graph2.png "Updated dependency graph")](/query/images/query_graph2.png)
 
 Looking at `graph2.png`, you can see that `Smoothie` has no shared dependencies with other dishes but is just another target that the `Chef` relies on.
 
@@ -465,7 +465,7 @@ bazel query "allpaths(//src/main/java/com/example/restaurant/..., //src/main/jav
 //src/main/java/com/example/restaurant:chef
 ```
 
-![Output path of cafe to chef to pizza,mac and cheese to cheese](images/query_graph3.png "Output path for dependency")
+![Output path of cafe to chef to pizza,mac and cheese to cheese](/versions/8.4.2/query/images/query_graph3.png "Output path for dependency")
 
 The output of `allpaths()` is a little harder to read as it is a flattened list of the dependencies. Visualizing this graph using Graphviz makes the relationship clearer to understand.
 
diff --git a/versions/8.4.2/reference/be/c-cpp.mdx b/versions/8.4.2/reference/be/c-cpp.mdx
index d89d462c..e29c0607 100644
--- a/versions/8.4.2/reference/be/c-cpp.mdx
+++ b/versions/8.4.2/reference/be/c-cpp.mdx
@@ -61,7 +61,7 @@ be `main`.
 | `hdrs_check` | String; default is `""` Deprecated, no-op. |
 | `includes` | List of strings; default is `[]` List of include dirs to be added to the compile line. Subject to ["Make variable"](/versions/8.4.2/reference/be/make-variables) substitution. Each string is prepended with the package path and passed to the C++ toolchain for expansion via the "include\_paths" CROSSTOOL feature. A toolchain running on a POSIX system with typical feature definitions will produce `-isystem path_to_package/include_entry`. This should only be used for third-party libraries that do not conform to the Google style of writing #include statements. Unlike [COPTS](#cc_binary.copts), these flags are added for this rule and every rule that depends on it. (Note: not the rules it depends upon!) Be very careful, since this may have far-reaching effects. When in doubt, add "-I" flags to [COPTS](#cc_binary.copts) instead. The added `include` paths will include generated files as well as files in the source tree. |
 | `link_extra_lib` | [Label](/versions/8.4.2/concepts/labels); default is `"@bazel_tools//tools/cpp:link_extra_lib"` Control linking of extra libraries. By default, C++ binaries are linked against `//tools/cpp:link_extra_lib`, which by default depends on the label flag `//tools/cpp:link_extra_libs`. Without setting the flag, this library is empty by default. Setting the label flag allows linking optional dependencies, such as overrides for weak symbols, interceptors for shared library functions, or special runtime libraries (for malloc replacements, prefer `malloc` or `--custom_malloc`). Setting this attribute to `None` disables this behaviour. |
-| `linkopts` | List of strings; default is `[]` Add these flags to the C++ linker command. Subject to ["Make" variable](make-variables) substitution, [Bourne shell tokenization](common-definitions#sh-tokenization) and [label expansion](common-definitions#label-expansion). Each string in this attribute is added to `LINKOPTS` before linking the binary target. Each element of this list that does not start with `$` or `-` is assumed to be the label of a target in `deps`. The list of files generated by that target is appended to the linker options. An error is reported if the label is invalid, or is not declared in `deps`. |
+| `linkopts` | List of strings; default is `[]` Add these flags to the C++ linker command. Subject to ["Make" variable](/versions/8.4.2/reference/be/make-variables) substitution, [Bourne shell tokenization](/versions/8.4.2/reference/be/common-definitions#sh-tokenization) and [label expansion](/versions/8.4.2/reference/be/common-definitions#label-expansion). Each string in this attribute is added to `LINKOPTS` before linking the binary target. Each element of this list that does not start with `$` or `-` is assumed to be the label of a target in `deps`. The list of files generated by that target is appended to the linker options. An error is reported if the label is invalid, or is not declared in `deps`. |
 | `linkshared` | Boolean; default is `False` Create a shared library. To enable this attribute, include `linkshared=True` in your rule. By default this option is off. The presence of this flag means that linking occurs with the `-shared` flag to `gcc`, and the resulting shared library is suitable for loading into for example a Java program. However, for build purposes it will never be linked into the dependent binary, as it is assumed that shared libraries built with a [cc\_binary](#cc_binary) rule are only loaded manually by other programs, so it should not be considered a substitute for the [cc\_library](#cc_library) rule. For sake of scalability we recommend avoiding this approach altogether and simply letting `java_library` depend on `cc_library` rules instead.  If you specify both `linkopts=['-static']` and `linkshared=True`, you get a single completely self-contained unit. If you specify both `linkstatic=True` and `linkshared=True`, you get a single, mostly self-contained unit. |
 | `linkstatic` | Boolean; default is `True` For [`cc_binary`](/versions/8.4.2/reference/be/c-cpp#cc_binary) and [`cc_test`](/versions/8.4.2/reference/be/c-cpp#cc_test): link the binary in static mode. For `cc_library.link_static`: see below. By default this option is on for `cc_binary` and off for the rest.  If enabled and this is a binary or test, this option tells the build tool to link in `.a`'s instead of `.so`'s for user libraries whenever possible. System libraries such as libc (but *not* the C/C++ runtime libraries, see below) are still linked dynamically, as are libraries for which there is no static library. So the resulting executable will still be dynamically linked, hence only *mostly* static.  There are really three different ways to link an executable:   * STATIC with fully\_static\_link feature, in which everything is linked statically;   e.g. "`gcc -static foo.o libbar.a libbaz.a -lm`".    This mode is enabled by specifying `fully_static_link` in the   [`features`](/versions/8.4.2/reference/be/common-definitions#features) attribute. * STATIC, in which all user libraries are linked statically (if a static   version is available), but where system libraries (excluding C/C++ runtime libraries)   are linked dynamically, e.g. "`gcc foo.o libfoo.a libbaz.a -lm`".    This mode is enabled by specifying `linkstatic=True`. * DYNAMIC, in which all libraries are linked dynamically (if a dynamic version is   available), e.g. "`gcc foo.o libfoo.so libbaz.so -lm`".    This mode is enabled by specifying `linkstatic=False`.   If the `linkstatic` attribute or `fully_static_link` in `features` is used outside of `//third_party` please include a comment near the rule to explain why.  The `linkstatic` attribute has a different meaning if used on a [`cc_library()`](/versions/8.4.2/reference/be/c-cpp#cc_library) rule. For a C++ library, `linkstatic=True` indicates that only static linking is allowed, so no `.so` will be produced. linkstatic=False does not prevent static libraries from being created. The attribute is meant to control the creation of dynamic libraries.  There should be very little code built with `linkstatic=False` in production. If `linkstatic=False`, then the build tool will create symlinks to depended-upon shared libraries in the `*.runfiles` area. |
 | `local_defines` | List of strings; default is `[]` List of defines to add to the compile line. Subject to ["Make" variable](/versions/8.4.2/reference/be/make-variables) substitution and [Bourne shell tokenization](/versions/8.4.2/reference/be/common-definitions#sh-tokenization). Each string, which must consist of a single Bourne shell token, is prepended with `-D` and added to the compile command line for this target, but not to its dependents. |
@@ -229,7 +229,7 @@ cc_import(
 | `alwayslink` | Boolean; default is `False` If 1, any binary that depends (directly or indirectly) on this C++ precompiled library will link in all the object files archived in the static library, even if some contain no symbols referenced by the binary. This is useful if your code isn't explicitly called by code in the binary, e.g., if your code registers to receive some callback provided by some service. If alwayslink doesn't work with VS 2017 on Windows, that is due to a [known issue](https://github.com/bazelbuild/bazel/issues/3949), please upgrade your VS 2017 to the latest version. |
 | `includes` | List of strings; default is `[]` List of include dirs to be added to the compile line. Subject to ["Make variable"](/versions/8.4.2/reference/be/make-variables) substitution. Each string is prepended with the package path and passed to the C++ toolchain for expansion via the "include\_paths" CROSSTOOL feature. A toolchain running on a POSIX system with typical feature definitions will produce `-isystem path_to_package/include_entry`. This should only be used for third-party libraries that do not conform to the Google style of writing #include statements. Unlike [COPTS](#cc_binary.copts), these flags are added for this rule and every rule that depends on it. (Note: not the rules it depends upon!) Be very careful, since this may have far-reaching effects. When in doubt, add "-I" flags to [COPTS](#cc_binary.copts) instead. The default `include` path doesn't include generated files. If you need to `#include` a generated header file, list it in the `srcs`. |
 | `interface_library` | [Label](/versions/8.4.2/concepts/labels); default is `None` A single interface library for linking the shared library. Permitted file types: `.ifso`, `.tbd`, `.lib`, `.so` or `.dylib` |
-| `linkopts` | List of strings; default is `[]` Add these flags to the C++ linker command. Subject to ["Make" variable](make-variables) substitution, [Bourne shell tokenization](common-definitions#sh-tokenization) and [label expansion](common-definitions#label-expansion). Each string in this attribute is added to `LINKOPTS` before linking the binary target. Each element of this list that does not start with `$` or `-` is assumed to be the label of a target in `deps`. The list of files generated by that target is appended to the linker options. An error is reported if the label is invalid, or is not declared in `deps`. |
+| `linkopts` | List of strings; default is `[]` Add these flags to the C++ linker command. Subject to ["Make" variable](/versions/8.4.2/reference/be/make-variables) substitution, [Bourne shell tokenization](/versions/8.4.2/reference/be/common-definitions#sh-tokenization) and [label expansion](/versions/8.4.2/reference/be/common-definitions#label-expansion). Each string in this attribute is added to `LINKOPTS` before linking the binary target. Each element of this list that does not start with `$` or `-` is assumed to be the label of a target in `deps`. The list of files generated by that target is appended to the linker options. An error is reported if the label is invalid, or is not declared in `deps`. |
 | `objects` | List of [labels](/versions/8.4.2/concepts/labels); default is `[]` |
 | `pic_objects` | List of [labels](/versions/8.4.2/concepts/labels); default is `[]` |
 | `pic_static_library` | [Label](/versions/8.4.2/concepts/labels); default is `None` |
@@ -454,7 +454,7 @@ cc_library(
 | `implementation_deps` | List of [labels](/versions/8.4.2/concepts/labels); default is `[]` The list of other libraries that the library target depends on. Unlike with `deps`, the headers and include paths of these libraries (and all their transitive deps) are only used for compilation of this library, and not libraries that depend on it. Libraries specified with `implementation_deps` are still linked in binary targets that depend on this library. |
 | `include_prefix` | String; default is `""` The prefix to add to the paths of the headers of this rule. When set, the headers in the `hdrs` attribute of this rule are accessible at is the value of this attribute prepended to their repository-relative path. The prefix in the `strip_include_prefix` attribute is removed before this prefix is added. This attribute is only legal under `third_party`. |
 | `includes` | List of strings; default is `[]` List of include dirs to be added to the compile line. Subject to ["Make variable"](/versions/8.4.2/reference/be/make-variables) substitution. Each string is prepended with the package path and passed to the C++ toolchain for expansion via the "include\_paths" CROSSTOOL feature. A toolchain running on a POSIX system with typical feature definitions will produce `-isystem path_to_package/include_entry`. This should only be used for third-party libraries that do not conform to the Google style of writing #include statements. Unlike [COPTS](#cc_binary.copts), these flags are added for this rule and every rule that depends on it. (Note: not the rules it depends upon!) Be very careful, since this may have far-reaching effects. When in doubt, add "-I" flags to [COPTS](#cc_binary.copts) instead. The added `include` paths will include generated files as well as files in the source tree. |
-| `linkopts` | List of strings; default is `[]` See [`cc_binary.linkopts`](/versions/8.4.2/reference/be/c-cpp#cc_binary.linkopts). The `linkopts` attribute is also applied to any target that depends, directly or indirectly, on this library via `deps` attributes (or via other attributes that are treated similarly: the [`malloc`](/versions/8.4.2/reference/be/c-cpp#cc_binary.malloc) attribute of [`cc_binary`](/versions/8.4.2/reference/be/c-cpp#cc_binary)). Dependency linkopts take precedence over dependent linkopts (i.e. dependency linkopts appear later in the command line). Linkopts specified in [`--linkopt`](../user-manual#flag--linkopt) take precedence over rule linkopts. |
+| `linkopts` | List of strings; default is `[]` See [`cc_binary.linkopts`](/versions/8.4.2/reference/be/c-cpp#cc_binary.linkopts). The `linkopts` attribute is also applied to any target that depends, directly or indirectly, on this library via `deps` attributes (or via other attributes that are treated similarly: the [`malloc`](/versions/8.4.2/reference/be/c-cpp#cc_binary.malloc) attribute of [`cc_binary`](/versions/8.4.2/reference/be/c-cpp#cc_binary)). Dependency linkopts take precedence over dependent linkopts (i.e. dependency linkopts appear later in the command line). Linkopts specified in [`--linkopt`](/versions/8.4.2/reference/user-manual#flag--linkopt) take precedence over rule linkopts. |
 
 Note that the `linkopts` attribute only applies
 when creating `.so` files or executables, not
@@ -736,7 +736,7 @@ that `cc_test` has extra [attributes common to all test rules (\*\_test)](/versi
 | `hdrs_check` | String; default is `""` Deprecated, no-op. |
 | `includes` | List of strings; default is `[]` List of include dirs to be added to the compile line. Subject to ["Make variable"](/versions/8.4.2/reference/be/make-variables) substitution. Each string is prepended with the package path and passed to the C++ toolchain for expansion via the "include\_paths" CROSSTOOL feature. A toolchain running on a POSIX system with typical feature definitions will produce `-isystem path_to_package/include_entry`. This should only be used for third-party libraries that do not conform to the Google style of writing #include statements. Unlike [COPTS](#cc_binary.copts), these flags are added for this rule and every rule that depends on it. (Note: not the rules it depends upon!) Be very careful, since this may have far-reaching effects. When in doubt, add "-I" flags to [COPTS](#cc_binary.copts) instead. The added `include` paths will include generated files as well as files in the source tree. |
 | `link_extra_lib` | [Label](/versions/8.4.2/concepts/labels); default is `"@bazel_tools//tools/cpp:link_extra_lib"` Control linking of extra libraries. By default, C++ binaries are linked against `//tools/cpp:link_extra_lib`, which by default depends on the label flag `//tools/cpp:link_extra_libs`. Without setting the flag, this library is empty by default. Setting the label flag allows linking optional dependencies, such as overrides for weak symbols, interceptors for shared library functions, or special runtime libraries (for malloc replacements, prefer `malloc` or `--custom_malloc`). Setting this attribute to `None` disables this behaviour. |
-| `linkopts` | List of strings; default is `[]` Add these flags to the C++ linker command. Subject to ["Make" variable](make-variables) substitution, [Bourne shell tokenization](common-definitions#sh-tokenization) and [label expansion](common-definitions#label-expansion). Each string in this attribute is added to `LINKOPTS` before linking the binary target. Each element of this list that does not start with `$` or `-` is assumed to be the label of a target in `deps`. The list of files generated by that target is appended to the linker options. An error is reported if the label is invalid, or is not declared in `deps`. |
+| `linkopts` | List of strings; default is `[]` Add these flags to the C++ linker command. Subject to ["Make" variable](/versions/8.4.2/reference/be/make-variables) substitution, [Bourne shell tokenization](/versions/8.4.2/reference/be/common-definitions#sh-tokenization) and [label expansion](/versions/8.4.2/reference/be/common-definitions#label-expansion). Each string in this attribute is added to `LINKOPTS` before linking the binary target. Each element of this list that does not start with `$` or `-` is assumed to be the label of a target in `deps`. The list of files generated by that target is appended to the linker options. An error is reported if the label is invalid, or is not declared in `deps`. |
 | `linkshared` | Boolean; default is `False` Create a shared library. To enable this attribute, include `linkshared=True` in your rule. By default this option is off. The presence of this flag means that linking occurs with the `-shared` flag to `gcc`, and the resulting shared library is suitable for loading into for example a Java program. However, for build purposes it will never be linked into the dependent binary, as it is assumed that shared libraries built with a [cc\_binary](#cc_binary) rule are only loaded manually by other programs, so it should not be considered a substitute for the [cc\_library](#cc_library) rule. For sake of scalability we recommend avoiding this approach altogether and simply letting `java_library` depend on `cc_library` rules instead.  If you specify both `linkopts=['-static']` and `linkshared=True`, you get a single completely self-contained unit. If you specify both `linkstatic=True` and `linkshared=True`, you get a single, mostly self-contained unit. |
 | `linkstatic` | Boolean; default is `False` For [`cc_binary`](/versions/8.4.2/reference/be/c-cpp#cc_binary) and [`cc_test`](/versions/8.4.2/reference/be/c-cpp#cc_test): link the binary in static mode. For `cc_library.link_static`: see below. By default this option is on for `cc_binary` and off for the rest.  If enabled and this is a binary or test, this option tells the build tool to link in `.a`'s instead of `.so`'s for user libraries whenever possible. System libraries such as libc (but *not* the C/C++ runtime libraries, see below) are still linked dynamically, as are libraries for which there is no static library. So the resulting executable will still be dynamically linked, hence only *mostly* static.  There are really three different ways to link an executable:   * STATIC with fully\_static\_link feature, in which everything is linked statically;   e.g. "`gcc -static foo.o libbar.a libbaz.a -lm`".    This mode is enabled by specifying `fully_static_link` in the   [`features`](/versions/8.4.2/reference/be/common-definitions#features) attribute. * STATIC, in which all user libraries are linked statically (if a static   version is available), but where system libraries (excluding C/C++ runtime libraries)   are linked dynamically, e.g. "`gcc foo.o libfoo.a libbaz.a -lm`".    This mode is enabled by specifying `linkstatic=True`. * DYNAMIC, in which all libraries are linked dynamically (if a dynamic version is   available), e.g. "`gcc foo.o libfoo.so libbaz.so -lm`".    This mode is enabled by specifying `linkstatic=False`.   If the `linkstatic` attribute or `fully_static_link` in `features` is used outside of `//third_party` please include a comment near the rule to explain why.  The `linkstatic` attribute has a different meaning if used on a [`cc_library()`](/versions/8.4.2/reference/be/c-cpp#cc_library) rule. For a C++ library, `linkstatic=True` indicates that only static linking is allowed, so no `.so` will be produced. linkstatic=False does not prevent static libraries from being created. The attribute is meant to control the creation of dynamic libraries.  There should be very little code built with `linkstatic=False` in production. If `linkstatic=False`, then the build tool will create symlinks to depended-upon shared libraries in the `*.runfiles` area. |
 | `local_defines` | List of strings; default is `[]` List of defines to add to the compile line. Subject to ["Make" variable](/versions/8.4.2/reference/be/make-variables) substitution and [Bourne shell tokenization](/versions/8.4.2/reference/be/common-definitions#sh-tokenization). Each string, which must consist of a single Bourne shell token, is prepended with `-D` and added to the compile command line for this target, but not to its dependents. |
diff --git a/versions/8.4.2/reference/be/common-definitions.mdx b/versions/8.4.2/reference/be/common-definitions.mdx
index c668d70c..4e4975cf 100644
--- a/versions/8.4.2/reference/be/common-definitions.mdx
+++ b/versions/8.4.2/reference/be/common-definitions.mdx
@@ -75,11 +75,11 @@ rules.
 | `deprecation` | String; [nonconfigurable](#configurable-attributes); default is `None`  An explanatory warning message associated with this target. Typically this is used to notify users that a target has become obsolete, or has become superseded by another rule, is private to a package, or is perhaps considered harmful for some reason. It is a good idea to include some reference (like a webpage, a bug number or example migration CLs) so that one can easily find out what changes are required to avoid the message. If there is a new target that can be used as a drop in replacement, it is a good idea to just migrate all users of the old target.  This attribute has no effect on the way things are built, but it may affect a build tool's diagnostic output. The build tool issues a warning when a rule with a `deprecation` attribute is depended upon by a target in another package.  Intra-package dependencies are exempt from this warning, so that, for example, building the tests of a deprecated rule does not encounter a warning.  If a deprecated target depends on another deprecated target, no warning message is issued.  Once people have stopped using it, the target can be removed. |
 | `distribs` | List of strings; [nonconfigurable](#configurable-attributes); default is `[]`  A list of distribution-method strings to be used for this particular target. This is part of a deprecated licensing API that Bazel no longer uses. Don't use this. |
 | `exec_compatible_with` | List of [labels](/versions/8.4.2/concepts/labels); [nonconfigurable](#configurable-attributes); default is `[]`  A list of `constraint_values` that must be present in the execution platform for this target. This is in addition to any constraints already set by the rule type. Constraints are used to restrict the list of available execution platforms. For more details, see the description of [toolchain resolution](/versions/8.4.2/docs/toolchains#toolchain-resolution). |
-| `exec_properties` | Dictionary of strings; default is `{}`  A dictionary of strings that will be added to the `exec_properties` of a platform selected for this target. See `exec_properties` of the [platform](platforms-and-toolchains#platform) rule.  If a key is present in both the platform and target-level properties, the value will be taken from the target. |
+| `exec_properties` | Dictionary of strings; default is `{}`  A dictionary of strings that will be added to the `exec_properties` of a platform selected for this target. See `exec_properties` of the [platform](/versions/8.4.2/reference/be/platforms-and-toolchains#platform) rule.  If a key is present in both the platform and target-level properties, the value will be taken from the target. |
 | `features` | List of *feature* strings; default is `[]`  A feature is string tag that can be enabled or disabled on a target. The meaning of a feature depends on the rule itself.  This `features` attribute is combined with the [package](/versions/8.4.2/reference/be/functions#package) level `features` attribute. For example, if the features ["a", "b"] are enabled on the package level, and a target's `features` attribute contains ["-a", "c"], the features enabled for the rule will be "b" and "c". [See example](https://github.com/bazelbuild/examples/blob/main/rules/features/BUILD). |
 | `restricted_to` | List of [labels](/versions/8.4.2/concepts/labels); [nonconfigurable](#configurable-attributes); default is `[]`  The list of environments this target can be built for, *instead* of default-supported environments.  This is part of Bazel's constraint system. See `compatible_with` for details. |
 | `tags` | List of strings; [nonconfigurable](#configurable-attributes); default is `[]`  *Tags* can be used on any rule. *Tags* on test and `test_suite` rules are useful for categorizing the tests. *Tags* on non-test targets are used to control sandboxed execution of `genrule`s and [Starlark](/versions/8.4.2/rules/concepts) actions, and for parsing by humans and/or external tools.  Bazel modifies the behavior of its sandboxing code if it finds the following keywords in the `tags` attribute of any test or `genrule` target, or the keys of `execution_requirements` for any Starlark action.   * `no-sandbox` keyword results in the action or test never being   sandboxed; it can still be cached or run remotely - use `no-cache`   or `no-remote` to prevent either or both of those. * `no-cache` keyword results in the action or test never being   cached (locally or remotely). Note: for the purposes of this tag, the disk cache   is considered a local cache, whereas the HTTP and gRPC caches are considered   remote. Other caches, such as Skyframe or the persistent action cache, are not   affected. * `no-remote-cache` keyword results in the action or test never being   cached remotely (but it may be cached locally; it may also be executed remotely).   Note: for the purposes of this tag, the disk cache is considered a local cache,   whereas the HTTP and gRPC caches are considered remote. Other caches, such as   Skyframe or the persistent action cache, are not affected.   If a combination of local disk cache and remote cache are used (combined cache),   it's treated as a remote cache and disabled entirely unless `--incompatible_remote_results_ignore_disk`   is set in which case the local components will be used. * `no-remote-exec` keyword results in the action or test never being   executed remotely (but it may be cached remotely). * `no-remote` keyword prevents the action or test from being executed remotely or   cached remotely. This is equivalent to using both   `no-remote-cache` and `no-remote-exec`. * `no-remote-cache-upload` keyword disables upload part of remote caching of a spawn.   it does not disable remote execution. * `local` keyword precludes the action or test from being remotely cached,   remotely executed, or run inside the sandbox.   For genrules and tests, marking the rule with the `local = True`   attribute has the same effect. * `requires-network` keyword allows access to the external   network from inside the sandbox. This tag only has an effect if sandboxing   is enabled. * `block-network` keyword blocks access to the external   network from inside the sandbox. In this case, only communication   with localhost is allowed. This tag only has an effect if sandboxing is   enabled. * `requires-fakeroot` runs the test or action as uid and gid 0 (i.e., the root   user). This is only supported on Linux. This tag takes precedence over the   `--sandbox_fake_username` command-line option.   *Tags* on tests are generally used to annotate a test's role in your debug and release process. Typically, tags are most useful for C++ and Python tests, which lack any runtime annotation ability. The use of tags and size elements gives flexibility in assembling suites of tests based around codebase check-in policy.  Bazel modifies test running behavior if it finds the following keywords in the `tags` attribute of the test rule:   * `exclusive` will force the test to be run in the   "exclusive" mode, ensuring that no other tests are running at the   same time. Such tests will be executed in serial fashion after all build   activity and non-exclusive tests have been completed. Remote execution is   disabled for such tests because Bazel doesn't have control over what's   running on a remote machine. * `exclusive-if-local` will force the test to be run in the   "exclusive" mode if it is executed locally, but will run the test in parallel if it's   executed remotely. * `manual` keyword will exclude the target from expansion of target pattern wildcards   (`...`, `:*`, `:all`, etc.) and `test_suite` rules   which do not list the test explicitly when computing the set of top-level targets to build/run   for the `build`, `test`, and `coverage` commands. It does not   affect target wildcard or test suite expansion in other contexts, including the   `query` command. Note that `manual` does not imply that a target should   not be built/run automatically by continuous build/test systems. For example, it may be   desirable to exclude a target from `bazel test ...` because it requires specific   Bazel flags, but still have it included in properly-configured presubmit or continuous test   runs. * `external` keyword will force test to be unconditionally   executed (regardless of `--cache_test_results`   value).  See [Tag Conventions](/versions/8.4.2/reference/test-encyclopedia#tag-conventions) in the Test Encyclopedia for more conventions on tags attached to test targets. |
-| `target_compatible_with` | List of [labels](/versions/8.4.2/concepts/labels); default is `[]`  A list of `constraint_value`s that must be present in the target platform for this target to be considered *compatible*. This is in addition to any constraints already set by the rule type. If the target platform does not satisfy all listed constraints then the target is considered *incompatible*. Incompatible targets are skipped for building and testing when the target pattern is expanded (e.g. `//...`, `:all`). When explicitly specified on the command line, incompatible targets cause Bazel to print an error and cause a build or test failure.  Targets that transitively depend on incompatible targets are themselves considered incompatible. They are also skipped for building and testing.  An empty list (which is the default) signifies that the target is compatible with all platforms. All rules other than [Workspace Rules](workspace) support this attribute. For some rules this attribute has no effect. For example, specifying `target_compatible_with` for a `cc_toolchain` is not useful. See the [Platforms](/versions/8.4.2/docs/platforms#skipping-incompatible-targets) page for more information about incompatible target skipping. |
+| `target_compatible_with` | List of [labels](/versions/8.4.2/concepts/labels); default is `[]`  A list of `constraint_value`s that must be present in the target platform for this target to be considered *compatible*. This is in addition to any constraints already set by the rule type. If the target platform does not satisfy all listed constraints then the target is considered *incompatible*. Incompatible targets are skipped for building and testing when the target pattern is expanded (e.g. `//...`, `:all`). When explicitly specified on the command line, incompatible targets cause Bazel to print an error and cause a build or test failure.  Targets that transitively depend on incompatible targets are themselves considered incompatible. They are also skipped for building and testing.  An empty list (which is the default) signifies that the target is compatible with all platforms. All rules other than [Workspace Rules](/versions/8.4.2/reference/be/workspace) support this attribute. For some rules this attribute has no effect. For example, specifying `target_compatible_with` for a `cc_toolchain` is not useful. See the [Platforms](/versions/8.4.2/docs/platforms#skipping-incompatible-targets) page for more information about incompatible target skipping. |
 | `testonly` | Boolean; [nonconfigurable](#configurable-attributes); default is `False` except for test and test suite targets  If `True`, only testonly targets (such as tests) can depend on this target.  Equivalently, a rule that is not `testonly` is not allowed to depend on any rule that is `testonly`.  Tests (`*_test` rules) and test suites ([test\_suite](/versions/8.4.2/reference/be/general#test_suite) rules) are `testonly` by default.  This attribute is intended to mean that the target should not be contained in binaries that are released to production.  Because testonly is enforced at build time, not run time, and propagates virally through the dependency tree, it should be applied judiciously. For example, stubs and fakes that are useful for unit tests may also be useful for integration tests involving the same binaries that will be released to production, and therefore should probably not be marked testonly. Conversely, rules that are dangerous to even link in, perhaps because they unconditionally override normal behavior, should definitely be marked testonly. |
 | `toolchains` | List of [labels](/versions/8.4.2/concepts/labels); [nonconfigurable](#configurable-attributes); default is `[]`  The set of targets whose [Make variables](/versions/8.4.2/reference/be/make-variables) this target is allowed to access. These targets are either instances of rules that provide `TemplateVariableInfo` or special targets for toolchain types built into Bazel. These include:  * `@bazel_tools//tools/cpp:current_cc_toolchain`* `@rules_java//toolchains:current_java_runtime`   Note that this is distinct from the concept of [toolchain resolution](/versions/8.4.2/docs/toolchains#toolchain-resolution) that is used by rule implementations for platform-dependent configuration. You cannot use this attribute to determine which specific `cc_toolchain` or `java_toolchain` a target will use. |
 | `visibility` | List of [labels](/versions/8.4.2/concepts/labels); [nonconfigurable](#configurable-attributes); default varies  The `visibility` attribute controls whether the target can be depended on by targets in other locations. See the documentation for [visibility](/versions/8.4.2/concepts/visibility).  For targets declared directly in a BUILD file or in legacy macros called from a BUILD file, the default value is the package's `default_visibility` if specified, or else `["//visibility:private"]`. For targets declared in one or more symbolic macros, the default value is always just `["//visibility:private"]` (which makes it useable only within the package containing the macro's code). |
diff --git a/versions/8.4.2/reference/be/functions.mdx b/versions/8.4.2/reference/be/functions.mdx
index 5c5af2a5..22a99e51 100644
--- a/versions/8.4.2/reference/be/functions.mdx
+++ b/versions/8.4.2/reference/be/functions.mdx
@@ -34,9 +34,9 @@ file, before any rule.
 | --- | --- |
 | `default_applicable_licenses` | Alias for [`default_package_metadata`](#package.default_package_metadata). |
 | `default_visibility` | List of [labels](/versions/8.4.2/concepts/labels); default is `[]`  The default visibility of the top-level rule targets and symbolic macros in this package — that is, the targets and symbolic macros that are not themselves declared inside a symbolic macro. This attribute is ignored if the target or macro specifies a `visibility` value.  For detailed information about the syntax of this attribute, see the documentation of [visibility](/versions/8.4.2/concepts/visibility). The package default visibility does not apply to [exports\_files](#exports_files), which is public by default. |
-| `default_deprecation` | String; default is `""`  Sets the default [`deprecation`](common-definitions#common.deprecation) message for all rules in this package. |
+| `default_deprecation` | String; default is `""`  Sets the default [`deprecation`](/versions/8.4.2/reference/be/common-definitions#common.deprecation) message for all rules in this package. |
 | `default_package_metadata` | List of [labels](/versions/8.4.2/concepts/labels); default is `[]`  Sets a default list of metadata targets which apply to all other targets in the package. These are typically targets related to OSS package and license declarations. See [rules\_license](https://github.com/bazelbuild/rules_license) for examples. |
-| `default_testonly` | Boolean; default is `False` except as noted  Sets the default [`testonly`](common-definitions#common.testonly) property for all rules in this package.  In packages under `javatests` the default value is `True`. |
+| `default_testonly` | Boolean; default is `False` except as noted  Sets the default [`testonly`](/versions/8.4.2/reference/be/common-definitions#common.testonly) property for all rules in this package.  In packages under `javatests` the default value is `True`. |
 | `features` | List strings; default is `[]`  Sets various flags that affect the semantics of this BUILD file.  This feature is mainly used by the people working on the build system to tag packages that need some kind of special handling. Do not use this unless explicitly requested by someone working on the build system. |
 
 ### Examples
@@ -66,7 +66,7 @@ visible target can only be referenced within its own package (not subpackages).
 In between these extremes, a target may allow access to its own package plus any
 of the packages described by one or more package groups. For a more detailed
 explanation of the visibility system, see the
-[visibility](common-definitions#common.visibility)
+[visibility](/versions/8.4.2/reference/be/common-definitions#common.visibility)
 attribute.
 
 A given package is considered to be in the group if it either matches the
@@ -159,7 +159,7 @@ visibility declaration can also be specified; in this case, the files will be
 visible to the targets specified. If no visibility is specified, the files
 will be visible to every package, even if a package default visibility was
 specified in the `package`
-function. The [licenses](common-definitions#common.licenses)
+function. The [licenses](/versions/8.4.2/reference/be/common-definitions#common.licenses)
 can also be specified.
 
 ### Example
@@ -262,8 +262,7 @@ There are several important limitations and caveats:
    package called "Foo.java" (which is allowed, though Bazel warns about it),
    then the consumer of the `glob()` will use the "Foo.java" rule
    (its outputs) instead of the "Foo.java" file. See
-   [GitHub
-   issue #10395](https://github.com/bazelbuild/bazel/issues/10395#issuecomment-583714657) for more details.
+   [GitHub issue #10395](https://github.com/bazelbuild/bazel/issues/10395#issuecomment-583714657) for more details.
 3. Globs may match files in subdirectories. And subdirectory names
    may be wildcarded. However...
 4. Labels are not allowed to cross the package boundary and glob does
@@ -409,7 +408,7 @@ select(
 ```
 
 `select()` is the helper function that makes a rule attribute
-[configurable](common-definitions#configurable-attributes).
+[configurable](/versions/8.4.2/reference/be/common-definitions#configurable-attributes).
 It can replace the right-hand side of
 *almost*
 any attribute assignment so its value depends on command-line Bazel flags.
diff --git a/versions/8.4.2/reference/be/general.mdx b/versions/8.4.2/reference/be/general.mdx
index f77267b6..5b5d8d20 100644
--- a/versions/8.4.2/reference/be/general.mdx
+++ b/versions/8.4.2/reference/be/general.mdx
@@ -158,9 +158,9 @@ some build targets.
   [here](/versions/8.4.2/reference/be/common-definitions#configurable-attributes) for more discussion.
 * Avoid repeating identical `config_setting` definitions in different packages.
   Instead, reference a common `config_setting` that defined in a canonical package.
-* [`values`](general#config_setting.values),
-  [`define_values`](general#config_setting.define_values), and
-  [`constraint_values`](general#config_setting.constraint_values)
+* [`values`](/versions/8.4.2/reference/be/general#config_setting.values),
+  [`define_values`](/versions/8.4.2/reference/be/general#config_setting.define_values), and
+  [`constraint_values`](/versions/8.4.2/reference/be/general#config_setting.constraint_values)
   can be used in any combination in the same `config_setting` but at least one must
   be set for any given `config_setting`.
 
@@ -169,10 +169,10 @@ some build targets.
 | Attributes | |
 | --- | --- |
 | `name` | [Name](/versions/8.4.2/concepts/labels#target-names); required  A unique name for this target. |
-| `constraint_values` | List of [labels](/versions/8.4.2/concepts/labels); [nonconfigurable](common-definitions#configurable-attributes); default is `[]` The minimum set of `constraint_values` that the target platform must specify in order to match this `config_setting`. (The execution platform is not considered here.) Any additional constraint values that the platform has are ignored. See [Configurable Build Attributes](https://bazel.build/versions/8.4.2/docs/configurable-attributes#platforms) for details. If two `config_setting`s match in the same `select` and one has all the same flags and `constraint_setting`s as the other plus additional ones, the one with more settings is chosen. This is known as "specialization". For example, a `config_setting` matching `x86` and `Linux` specializes a `config_setting` matching `x86`. If two `config_setting`s match and both have `constraint_value`s not present in the other, this is an error. |
-| `define_values` | Dictionary: String -> String; [nonconfigurable](common-definitions#configurable-attributes); default is `{}` The same as [`values`](/versions/8.4.2/reference/be/general#config_setting.values) but specifically for the `--define` flag. `--define` is special because its syntax (`--define KEY=VAL`) means `KEY=VAL` is a *value* from a Bazel flag perspective.  That means:  ```             config_setting(                 name = "a_and_b",                 values = {                     "define": "a=1",                     "define": "b=2",                 }) ```   doesn't work because the same key (`define`) appears twice in the dictionary. This attribute solves that problem:  ```             config_setting(                 name = "a_and_b",                 define_values = {                     "a": "1",                     "b": "2",                 }) ```   correctly matches `bazel build //foo --define a=1 --define b=2`. `--define` can still appear in [`values`](/versions/8.4.2/reference/be/general#config_setting.values) with normal flag syntax, and can be mixed freely with this attribute as long as dictionary keys remain distinct. |
-| `flag_values` | Dictionary: [label](/versions/8.4.2/concepts/labels) -> String; [nonconfigurable](common-definitions#configurable-attributes); default is `{}` The same as [`values`](/versions/8.4.2/reference/be/general#config_setting.values) but for [user-defined build flags](https://bazel.build/versions/8.4.2/rules/config#user-defined-build-settings). This is a distinct attribute because user-defined flags are referenced as labels while built-in flags are referenced as arbitrary strings. |
-| `values` | Dictionary: String -> String; [nonconfigurable](common-definitions#configurable-attributes); default is `{}` The set of configuration values that match this rule (expressed as build flags) This rule inherits the configuration of the configured target that references it in a `select` statement. It is considered to "match" a Bazel invocation if, for every entry in the dictionary, its configuration matches the entry's expected value. For example `values = {"compilation_mode": "opt"}` matches the invocations `bazel build --compilation_mode=opt ...` and `bazel build -c opt ...` on target-configured rules.  For convenience's sake, configuration values are specified as build flags (without the preceding `"--"`). But keep in mind that the two are not the same. This is because targets can be built in multiple configurations within the same build. For example, an exec configuration's "cpu" matches the value of `--host_cpu`, not `--cpu`. So different instances of the same `config_setting` may match the same invocation differently depending on the configuration of the rule using them.  If a flag is not explicitly set at the command line, its default value is used. If a key appears multiple times in the dictionary, only the last instance is used. If a key references a flag that can be set multiple times on the command line (e.g. `bazel build --copt=foo --copt=bar --copt=baz ...`), a match occurs if *any* of those settings match. |
+| `constraint_values` | List of [labels](/versions/8.4.2/concepts/labels); [nonconfigurable](/versions/8.4.2/reference/be/common-definitions#configurable-attributes); default is `[]` The minimum set of `constraint_values` that the target platform must specify in order to match this `config_setting`. (The execution platform is not considered here.) Any additional constraint values that the platform has are ignored. See [Configurable Build Attributes](https://bazel.build/versions/8.4.2/docs/configurable-attributes#platforms) for details. If two `config_setting`s match in the same `select` and one has all the same flags and `constraint_setting`s as the other plus additional ones, the one with more settings is chosen. This is known as "specialization". For example, a `config_setting` matching `x86` and `Linux` specializes a `config_setting` matching `x86`. If two `config_setting`s match and both have `constraint_value`s not present in the other, this is an error. |
+| `define_values` | Dictionary: String -> String; [nonconfigurable](/versions/8.4.2/reference/be/common-definitions#configurable-attributes); default is `{}` The same as [`values`](/versions/8.4.2/reference/be/general#config_setting.values) but specifically for the `--define` flag. `--define` is special because its syntax (`--define KEY=VAL`) means `KEY=VAL` is a *value* from a Bazel flag perspective.  That means:  ```             config_setting(                 name = "a_and_b",                 values = {                     "define": "a=1",                     "define": "b=2",                 }) ```   doesn't work because the same key (`define`) appears twice in the dictionary. This attribute solves that problem:  ```             config_setting(                 name = "a_and_b",                 define_values = {                     "a": "1",                     "b": "2",                 }) ```   correctly matches `bazel build //foo --define a=1 --define b=2`. `--define` can still appear in [`values`](/versions/8.4.2/reference/be/general#config_setting.values) with normal flag syntax, and can be mixed freely with this attribute as long as dictionary keys remain distinct. |
+| `flag_values` | Dictionary: [label](/versions/8.4.2/concepts/labels) -> String; [nonconfigurable](/versions/8.4.2/reference/be/common-definitions#configurable-attributes); default is `{}` The same as [`values`](/versions/8.4.2/reference/be/general#config_setting.values) but for [user-defined build flags](https://bazel.build/versions/8.4.2/rules/config#user-defined-build-settings). This is a distinct attribute because user-defined flags are referenced as labels while built-in flags are referenced as arbitrary strings. |
+| `values` | Dictionary: String -> String; [nonconfigurable](/versions/8.4.2/reference/be/common-definitions#configurable-attributes); default is `{}` The set of configuration values that match this rule (expressed as build flags) This rule inherits the configuration of the configured target that references it in a `select` statement. It is considered to "match" a Bazel invocation if, for every entry in the dictionary, its configuration matches the entry's expected value. For example `values = {"compilation_mode": "opt"}` matches the invocations `bazel build --compilation_mode=opt ...` and `bazel build -c opt ...` on target-configured rules.  For convenience's sake, configuration values are specified as build flags (without the preceding `"--"`). But keep in mind that the two are not the same. This is because targets can be built in multiple configurations within the same build. For example, an exec configuration's "cpu" matches the value of `--host_cpu`, not `--cpu`. So different instances of the same `config_setting` may match the same invocation differently depending on the configuration of the rule using them.  If a flag is not explicitly set at the command line, its default value is used. If a key appears multiple times in the dictionary, only the last instance is used. If a key references a flag that can be set multiple times on the command line (e.g. `bazel build --copt=foo --copt=bar --copt=baz ...`), a match occurs if *any* of those settings match. |
 
 ## filegroup
 
@@ -466,7 +466,7 @@ genrule(
 | --- | --- |
 | `name` | [Name](/versions/8.4.2/concepts/labels#target-names); required  A unique name for this target.  You may refer to this rule by name in the `srcs` or `deps` section of other `BUILD` rules. If the rule generates source files, you should use the `srcs` attribute. |
 | `srcs` | List of [labels](/versions/8.4.2/concepts/labels); default is `[]` A list of inputs for this rule, such as source files to process. *This attributes is not suitable to list tools executed by the `cmd`; use the [`tools`](/versions/8.4.2/reference/be/general#genrule.tools) attribute for them instead.*  The build system ensures these prerequisites are built before running the genrule command; they are built using the same configuration as the original build request. The names of the files of these prerequisites are available to the command as a space-separated list in `$(SRCS)`; alternatively the path of an individual `srcs` target `//x:y` can be obtained using `$(location //x:y)`, or using `$<` provided it's the only entry in `srcs`. |
-| `outs` | List of [filenames](/versions/8.4.2/concepts/build-ref#filename); [nonconfigurable](common-definitions#configurable-attributes); required A list of files generated by this rule. Output files must not cross package boundaries. Output filenames are interpreted as relative to the package.  If the `executable` flag is set, `outs` must contain exactly one label.  The genrule command is expected to create each output file at a predetermined location. The location is available in `cmd` using [genrule-specific "Make" variables](/versions/8.4.2/reference/be/make-variables#predefined_genrule_variables) (`$@`, `$(OUTS)`, `$(@D)` or `$(RULEDIR)`) or using [`$(location)`](/versions/8.4.2/reference/be/make-variables#predefined_label_variables) substitution. |
+| `outs` | List of [filenames](/versions/8.4.2/concepts/build-ref#filename); [nonconfigurable](/versions/8.4.2/reference/be/common-definitions#configurable-attributes); required A list of files generated by this rule. Output files must not cross package boundaries. Output filenames are interpreted as relative to the package.  If the `executable` flag is set, `outs` must contain exactly one label.  The genrule command is expected to create each output file at a predetermined location. The location is available in `cmd` using [genrule-specific "Make" variables](/versions/8.4.2/reference/be/make-variables#predefined_genrule_variables) (`$@`, `$(OUTS)`, `$(@D)` or `$(RULEDIR)`) or using [`$(location)`](/versions/8.4.2/reference/be/make-variables#predefined_label_variables) substitution. |
 | `cmd` | String; default is `""` The command to run. Subject to [`$(location)`](/versions/8.4.2/reference/be/make-variables#predefined_label_variables) and ["Make" variable](/versions/8.4.2/reference/be/make-variables) substitution.  1. First [`$(location)`](/versions/8.4.2/reference/be/make-variables#predefined_label_variables) substitution is applied, replacing all occurrences of `$(location     label)` and of `$(locations label)` (and similar    constructions using related variables `execpath`, `execpaths`,    `rootpath` and `rootpaths`). 2. Next, ["Make" variables](/versions/8.4.2/reference/be/make-variables) are expanded. Note that    predefined variables `$(JAVA)`, `$(JAVAC)` and    `$(JAVABASE)` expand under the *exec* configuration, so Java invocations    that run as part of a build step can correctly load shared libraries and other    dependencies. 3. Finally, the resulting command is executed using the Bash shell. If its exit code is    non-zero the command is considered to have failed.  This is the fallback of `cmd_bash`, `cmd_ps` and `cmd_bat`, if none of them are applicable. |
 
 If the command line length exceeds the platform limit (64K on Linux/macOS, 8K on Windows),
@@ -477,12 +477,12 @@ applies to all cmd attributes (`cmd`, `cmd_bash`, `cmd_ps`,
 | `cmd_bash` | String; default is `""` The Bash command to run. This attribute has higher priority than `cmd`. The command is expanded and runs in the exact same way as the `cmd` attribute. |
 | `cmd_bat` | String; default is `""` The Batch command to run on Windows. This attribute has higher priority than `cmd` and `cmd_bash`. The command runs in the similar way as the `cmd` attribute, with the following differences:   * This attribute only applies on Windows. * The command runs with `cmd.exe /c` with the following default arguments:   + `/S` - strip first and last quotes and execute everything else as is.   + `/E:ON` - enable extended command set.   + `/V:ON` - enable delayed variable expansion   + `/D` - ignore AutoRun registry entries. * After [$(location)](/versions/8.4.2/reference/be/make-variables#predefined_label_variables) and   ["Make" variable](/versions/8.4.2/reference/be/make-variables) substitution, the paths will be   expanded to Windows style paths (with backslash). |
 | `cmd_ps` | String; default is `""` The Powershell command to run on Windows. This attribute has higher priority than `cmd`, `cmd_bash` and `cmd_bat`. The command runs in the similar way as the `cmd` attribute, with the following differences:   * This attribute only applies on Windows. * The command runs with `powershell.exe /c`.   To make Powershell easier to use and less error-prone, we run the following commands to set up the environment before executing Powershell command in genrule.   * `Set-ExecutionPolicy -Scope CurrentUser RemoteSigned` - allow running   unsigned scripts. * `$errorActionPreference='Stop'` - In case there are multiple commands   separated by `;`, the action exits immediately if a Powershell CmdLet fails,   but this does **NOT** work for external command. * `$PSDefaultParameterValues['*:Encoding'] = 'utf8'` - change the default   encoding from utf-16 to utf-8. |
-| `executable` | Boolean; [nonconfigurable](common-definitions#configurable-attributes); default is `False` Declare output to be executable. Setting this flag to True means the output is an executable file and can be run using the `run` command. The genrule must produce exactly one output in this case. If this attribute is set, `run` will try executing the file regardless of its content.  Declaring data dependencies for the generated executable is not supported. |
+| `executable` | Boolean; [nonconfigurable](/versions/8.4.2/reference/be/common-definitions#configurable-attributes); default is `False` Declare output to be executable. Setting this flag to True means the output is an executable file and can be run using the `run` command. The genrule must produce exactly one output in this case. If this attribute is set, `run` will try executing the file regardless of its content.  Declaring data dependencies for the generated executable is not supported. |
 | `local` | Boolean; default is `False`  If set to True, this option forces this `genrule` to run using the "local" strategy, which means no remote execution, no sandboxing, no persistent workers.  This is equivalent to providing 'local' as a tag (`tags=["local"]`). |
 | `message` | String; default is `""` A progress message. A progress message that will be printed as this build step is executed. By default, the message is "Generating *output*" (or something equally bland) but you may provide a more specific one. Use this attribute instead of `echo` or other print statements in your `cmd` command, as this allows the build tool to control whether such progress messages are printed or not. |
 | `output_licenses` | Licence type; default is `["none"]` See [`common attributes`](/versions/8.4.2/reference/be/common-definitions#binary.output_licenses) |
-| `output_to_bindir` | Boolean; [nonconfigurable](common-definitions#configurable-attributes); default is `False`  If set to True, this option causes output files to be written into the `bin` directory instead of the `genfiles` directory. |
-| `toolchains` | List of [labels](/versions/8.4.2/concepts/labels); [nonconfigurable](common-definitions#configurable-attributes); default is `[]`  The set of targets whose [Make variables](/versions/8.4.2/reference/be/make-variables) this genrule is allowed to access, or the [`toolchain_type`](/versions/8.4.2/docs/toolchains) targets that this genrule will access.  Toolchains accessed via `toolchain_type` must also provide a `TemplateVariableInfo` provider, which the target can use to access toolchain details. |
+| `output_to_bindir` | Boolean; [nonconfigurable](/versions/8.4.2/reference/be/common-definitions#configurable-attributes); default is `False`  If set to True, this option causes output files to be written into the `bin` directory instead of the `genfiles` directory. |
+| `toolchains` | List of [labels](/versions/8.4.2/concepts/labels); [nonconfigurable](/versions/8.4.2/reference/be/common-definitions#configurable-attributes); default is `[]`  The set of targets whose [Make variables](/versions/8.4.2/reference/be/make-variables) this genrule is allowed to access, or the [`toolchain_type`](/versions/8.4.2/docs/toolchains) targets that this genrule will access.  Toolchains accessed via `toolchain_type` must also provide a `TemplateVariableInfo` provider, which the target can use to access toolchain details. |
 | `tools` | List of [labels](/versions/8.4.2/concepts/labels); default is `[]` A list of *tool* dependencies for this rule. See the definition of [dependencies](/versions/8.4.2/concepts/build-ref#deps) for more information.   The build system ensures these prerequisites are built before running the genrule command; they are built using the [*exec* configuration](/versions/8.4.2/contribute/guide#configurations), since these tools are executed as part of the build. The path of an individual `tools` target `//x:y` can be obtained using `$(location //x:y)`.  Any `*_binary` or tool to be executed by `cmd` must appear in this list, not in `srcs`, to ensure they are built in the correct configuration. |
 
 ## starlark\_doc\_extract
@@ -572,5 +572,5 @@ test_suite(
 | Attributes | |
 | --- | --- |
 | `name` | [Name](/versions/8.4.2/concepts/labels#target-names); required  A unique name for this target. |
-| `tags` | List of strings; [nonconfigurable](common-definitions#configurable-attributes); default is `[]` List of text tags such as "small" or "database" or "-flaky". Tags may be any valid string. Tags which begin with a "-" character are considered negative tags. The preceding "-" character is not considered part of the tag, so a suite tag of "-small" matches a test's "small" size. All other tags are considered positive tags.  Optionally, to make positive tags more explicit, tags may also begin with the "+" character, which will not be evaluated as part of the text of the tag. It merely makes the positive and negative distinction easier to read.  Only test rules that match **all** of the positive tags and **none** of the negative tags will be included in the test suite. Note that this does not mean that error checking for dependencies on tests that are filtered out is skipped; the dependencies on skipped tests still need to be legal (e.g. not blocked by visibility constraints).  The `manual` tag keyword is treated differently than the above by the "test\_suite expansion" performed by the `bazel test` command on invocations involving wildcard [target patterns](https://bazel.build/versions/8.4.2/docs/build#specifying-build-targets). There, `test_suite` targets tagged "manual" are filtered out (and thus not expanded). This behavior is consistent with how `bazel build` and `bazel test` handle wildcard target patterns in general. Note that this is explicitly different from how `bazel query 'tests(E)'` behaves, as suites are always expanded by the `tests` query function, regardless of the `manual` tag.  Note that a test's `size` is considered a tag for the purpose of filtering.  If you need a `test_suite` that contains tests with mutually exclusive tags (e.g. all small and medium tests), you'll have to create three `test_suite` rules: one for all small tests, one for all medium tests, and one that includes the previous two. |
-| `tests` | List of [labels](/versions/8.4.2/concepts/labels); [nonconfigurable](common-definitions#configurable-attributes); default is `[]` A list of test suites and test targets of any language. Any `*_test` is accepted here, independent of the language. No `*_binary` targets are accepted however, even if they happen to run a test. Filtering by the specified `tags` is only done for tests listed directly in this attribute. If this attribute contains `test_suite`s, the tests inside those will not be filtered by this `test_suite` (they are considered to be filtered already).  If the `tests` attribute is unspecified or empty, the rule will default to including all test rules in the current BUILD file that are not tagged as `manual`. These rules are still subject to `tag` filtering. |
\ No newline at end of file
+| `tags` | List of strings; [nonconfigurable](/versions/8.4.2/reference/be/common-definitions#configurable-attributes); default is `[]` List of text tags such as "small" or "database" or "-flaky". Tags may be any valid string. Tags which begin with a "-" character are considered negative tags. The preceding "-" character is not considered part of the tag, so a suite tag of "-small" matches a test's "small" size. All other tags are considered positive tags.  Optionally, to make positive tags more explicit, tags may also begin with the "+" character, which will not be evaluated as part of the text of the tag. It merely makes the positive and negative distinction easier to read.  Only test rules that match **all** of the positive tags and **none** of the negative tags will be included in the test suite. Note that this does not mean that error checking for dependencies on tests that are filtered out is skipped; the dependencies on skipped tests still need to be legal (e.g. not blocked by visibility constraints).  The `manual` tag keyword is treated differently than the above by the "test\_suite expansion" performed by the `bazel test` command on invocations involving wildcard [target patterns](https://bazel.build/versions/8.4.2/docs/build#specifying-build-targets). There, `test_suite` targets tagged "manual" are filtered out (and thus not expanded). This behavior is consistent with how `bazel build` and `bazel test` handle wildcard target patterns in general. Note that this is explicitly different from how `bazel query 'tests(E)'` behaves, as suites are always expanded by the `tests` query function, regardless of the `manual` tag.  Note that a test's `size` is considered a tag for the purpose of filtering.  If you need a `test_suite` that contains tests with mutually exclusive tags (e.g. all small and medium tests), you'll have to create three `test_suite` rules: one for all small tests, one for all medium tests, and one that includes the previous two. |
+| `tests` | List of [labels](/versions/8.4.2/concepts/labels); [nonconfigurable](/versions/8.4.2/reference/be/common-definitions#configurable-attributes); default is `[]` A list of test suites and test targets of any language. Any `*_test` is accepted here, independent of the language. No `*_binary` targets are accepted however, even if they happen to run a test. Filtering by the specified `tags` is only done for tests listed directly in this attribute. If this attribute contains `test_suite`s, the tests inside those will not be filtered by this `test_suite` (they are considered to be filtered already).  If the `tests` attribute is unspecified or empty, the rule will default to including all test rules in the current BUILD file that are not tagged as `manual`. These rules are still subject to `tag` filtering. |
\ No newline at end of file
diff --git a/versions/8.4.2/reference/be/java.mdx b/versions/8.4.2/reference/be/java.mdx
index eba1c248..5cdf99c9 100644
--- a/versions/8.4.2/reference/be/java.mdx
+++ b/versions/8.4.2/reference/be/java.mdx
@@ -15,7 +15,7 @@ title: 'Java Rules'
 
 ## java\_binary
 
-[View rule sourceopen\_in\_new](@rules_java//java/bazel/rules/bazel_java_binary.bzl)
+[View rule sourceopen\_in\_new](/versions/8.4.2/reference/be/@rules_java//java/bazel/rules/bazel_java_binary.bzl)
 
 ```
 java_binary(name, deps, srcs, data, resources, add_exports, add_opens, args, bootclasspath, classpath_resources, compatible_with, create_executable, deploy_env, deploy_manifest_lines, deprecation, distribs, env, exec_compatible_with, exec_properties, features, javacopts, jvm_flags, launcher, licenses, main_class, neverlink, output_licenses, plugins, resource_strip_prefix, restricted_to, runtime_deps, stamp, tags, target_compatible_with, testonly, toolchains, use_launcher, use_testrunner, visibility)
@@ -102,7 +102,7 @@ java_binary(
 | Attributes | |
 | --- | --- |
 | `name` | [Name](/versions/8.4.2/concepts/labels#target-names); required  A unique name for this target. |
-| `deps` | List of [labels](/versions/8.4.2/concepts/labels); default is `[]` The list of other libraries to be linked in to the target. See general comments about `deps` at [Typical attributes defined by most build rules](common-definitions#typical-attributes). |
+| `deps` | List of [labels](/versions/8.4.2/concepts/labels); default is `[]` The list of other libraries to be linked in to the target. See general comments about `deps` at [Typical attributes defined by most build rules](/versions/8.4.2/reference/be/common-definitions#typical-attributes). |
 | `srcs` | List of [labels](/versions/8.4.2/concepts/labels); default is `[]` The list of source files that are processed to create the target. This attribute is almost always required; see exceptions below. Source files of type `.java` are compiled. In case of generated `.java` files it is generally advisable to put the generating rule's name here instead of the name of the file itself. This not only improves readability but makes the rule more resilient to future changes: if the generating rule generates different files in the future, you only need to fix one place: the `outs` of the generating rule. You should not list the generating rule in `deps` because it is a no-op.  Source files of type `.srcjar` are unpacked and compiled. (This is useful if you need to generate a set of `.java` files with a genrule.)  Rules: if the rule (typically `genrule` or `filegroup`) generates any of the files listed above, they will be used the same way as described for source files.  This argument is almost always required, except if a [`main_class`](#java_binary.main_class) attribute specifies a class on the runtime classpath or you specify the `runtime_deps` argument. |
 | `data` | List of [labels](/versions/8.4.2/concepts/labels); default is `[]` The list of files needed by this library at runtime. See general comments about `data` at [Typical attributes defined by most build rules](/versions/8.4.2/reference/be/common-definitions#typical-attributes). |
 | `resources` | List of [labels](/versions/8.4.2/concepts/labels); default is `[]` A list of data files to include in a Java jar. Resources may be source files or generated files.  If resources are specified, they will be bundled in the jar along with the usual `.class` files produced by compilation. The location of the resources inside of the jar file is determined by the project structure. Bazel first looks for Maven's [standard directory layout](https://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html), (a "src" directory followed by a "resources" directory grandchild). If that is not found, Bazel then looks for the topmost directory named "java" or "javatests" (so, for example, if a resource is at `/x/java/y/java/z`, the path of the resource will be `y/java/z`. This heuristic cannot be overridden, however, the `resource_strip_prefix` attribute can be used to specify a specific alternative directory for resource files. |
@@ -112,9 +112,9 @@ java_binary(
 | `classpath_resources` | List of [labels](/versions/8.4.2/concepts/labels); default is `[]` *DO NOT USE THIS OPTION UNLESS THERE IS NO OTHER WAY)* A list of resources that must be located at the root of the java tree. This attribute's only purpose is to support third-party libraries that require that their resources be found on the classpath as exactly `"myconfig.xml"`. It is only allowed on binaries and not libraries, due to the danger of namespace conflicts. |
 | `create_executable` | Boolean; default is `True` Deprecated, use `java_single_jar` instead. |
 | `deploy_env` | List of [labels](/versions/8.4.2/concepts/labels); default is `[]` A list of other `java_binary` targets which represent the deployment environment for this binary. Set this attribute when building a plugin which will be loaded by another `java_binary`.  Setting this attribute excludes all dependencies from the runtime classpath (and the deploy jar) of this binary that are shared between this binary and the targets specified in `deploy_env`. |
-| `deploy_manifest_lines` | List of strings; default is `[]` A list of lines to add to the `META-INF/manifest.mf` file generated for the `*_deploy.jar` target. The contents of this attribute are *not* subject to ["Make variable"](make-variables) substitution. |
-| `javacopts` | List of strings; default is `[]` Extra compiler options for this binary. Subject to ["Make variable"](make-variables) substitution and [Bourne shell tokenization](common-definitions#sh-tokenization). These compiler options are passed to javac after the global compiler options. |
-| `jvm_flags` | List of strings; default is `[]` A list of flags to embed in the wrapper script generated for running this binary. Subject to [$(location)](/versions/8.4.2/reference/be/make-variables#location) and ["Make variable"](make-variables) substitution, and [Bourne shell tokenization](common-definitions#sh-tokenization). The wrapper script for a Java binary includes a CLASSPATH definition (to find all the dependent jars) and invokes the right Java interpreter. The command line generated by the wrapper script includes the name of the main class followed by a `"$@"` so you can pass along other arguments after the classname. However, arguments intended for parsing by the JVM must be specified *before* the classname on the command line. The contents of `jvm_flags` are added to the wrapper script before the classname is listed.  Note that this attribute has *no effect* on `*_deploy.jar` outputs. |
+| `deploy_manifest_lines` | List of strings; default is `[]` A list of lines to add to the `META-INF/manifest.mf` file generated for the `*_deploy.jar` target. The contents of this attribute are *not* subject to ["Make variable"](/versions/8.4.2/reference/be/make-variables) substitution. |
+| `javacopts` | List of strings; default is `[]` Extra compiler options for this binary. Subject to ["Make variable"](/versions/8.4.2/reference/be/make-variables) substitution and [Bourne shell tokenization](/versions/8.4.2/reference/be/common-definitions#sh-tokenization). These compiler options are passed to javac after the global compiler options. |
+| `jvm_flags` | List of strings; default is `[]` A list of flags to embed in the wrapper script generated for running this binary. Subject to [$(location)](/versions/8.4.2/reference/be/make-variables#location) and ["Make variable"](/versions/8.4.2/reference/be/make-variables) substitution, and [Bourne shell tokenization](/versions/8.4.2/reference/be/common-definitions#sh-tokenization). The wrapper script for a Java binary includes a CLASSPATH definition (to find all the dependent jars) and invokes the right Java interpreter. The command line generated by the wrapper script includes the name of the main class followed by a `"$@"` so you can pass along other arguments after the classname. However, arguments intended for parsing by the JVM must be specified *before* the classname on the command line. The contents of `jvm_flags` are added to the wrapper script before the classname is listed.  Note that this attribute has *no effect* on `*_deploy.jar` outputs. |
 | `launcher` | [Label](/versions/8.4.2/concepts/labels); default is `None` Specify a binary that will be used to run your Java program instead of the normal `bin/java` program included with the JDK. The target must be a `cc_binary`. Any `cc_binary` that implements the [Java Invocation API](http://docs.oracle.com/javase/7/docs/technotes/guides/jni/spec/invocation.html) can be specified as a value for this attribute. By default, Bazel will use the normal JDK launcher (bin/java or java.exe).  The related [`--java_launcher`](/versions/8.4.2/docs/user-manual#flag--java_launcher) Bazel flag affects only those `java_binary` and `java_test` targets that have *not* specified a `launcher` attribute.  Note that your native (C++, SWIG, JNI) dependencies will be built differently depending on whether you are using the JDK launcher or another launcher:   * If you are using the normal JDK launcher (the default), native dependencies are   built as a shared library named `{name}_nativedeps.so`, where   `{name}` is the `name` attribute of this java\_binary rule.   Unused code is *not* removed by the linker in this configuration. * If you are using any other launcher, native (C++) dependencies are statically   linked into a binary named `{name}_nativedeps`, where `{name}`   is the `name` attribute of this java\_binary rule. In this case,   the linker will remove any code it thinks is unused from the resulting binary,   which means any C++ code accessed only via JNI may not be linked in unless   that `cc_library` target specifies `alwayslink = True`.   When using any launcher other than the default JDK launcher, the format of the `*_deploy.jar` output changes. See the main [java\_binary](#java_binary) docs for details. |
 | `main_class` | String; default is `""` Name of class with `main()` method to use as entry point. If a rule uses this option, it does not need a `srcs=[...]` list. Thus, with this attribute one can make an executable from a Java library that already contains one or more `main()` methods. The value of this attribute is a class name, not a source file. The class must be available at runtime: it may be compiled by this rule (from `srcs`) or provided by direct or transitive dependencies (through `runtime_deps` or `deps`). If the class is unavailable, the binary will fail at runtime; there is no build-time check. |
 | `neverlink` | Boolean; default is `False` |
@@ -127,7 +127,7 @@ java_binary(
 
 ## java\_import
 
-[View rule sourceopen\_in\_new](@rules_java//java/bazel/rules/bazel_java_import.bzl)
+[View rule sourceopen\_in\_new](/versions/8.4.2/reference/be/@rules_java//java/bazel/rules/bazel_java_import.bzl)
 
 ```
 java_import(name, deps, data, add_exports, add_opens, compatible_with, constraints, deprecation, distribs, exec_compatible_with, exec_properties, exports, features, jars, licenses, neverlink, proguard_specs, restricted_to, runtime_deps, srcjar, tags, target_compatible_with, testonly, toolchains, visibility)
@@ -169,7 +169,7 @@ libraries for `java_library` and
 
 ## java\_library
 
-[View rule sourceopen\_in\_new](@rules_java//java/bazel/rules/bazel_java_library.bzl)
+[View rule sourceopen\_in\_new](/versions/8.4.2/reference/be/@rules_java//java/bazel/rules/bazel_java_library.bzl)
 
 ```
 java_library(name, deps, srcs, data, resources, add_exports, add_opens, bootclasspath, compatible_with, deprecation, distribs, exec_compatible_with, exec_properties, exported_plugins, exports, features, javabuilder_jvm_flags, javacopts, licenses, neverlink, plugins, proguard_specs, resource_strip_prefix, restricted_to, runtime_deps, tags, target_compatible_with, testonly, toolchains, visibility)
@@ -198,7 +198,7 @@ This rule compiles and links sources into a `.jar` file.
 | `exported_plugins` | List of [labels](/versions/8.4.2/concepts/labels); default is `[]` The list of `java_plugin`s (e.g. annotation processors) to export to libraries that directly depend on this library. The specified list of `java_plugin`s will be applied to any library which directly depends on this library, just as if that library had explicitly declared these labels in `plugins`. |
 | `exports` | List of [labels](/versions/8.4.2/concepts/labels); default is `[]` Exported libraries. Listing rules here will make them available to parent rules, as if the parents explicitly depended on these rules. This is not true for regular (non-exported) `deps`.  Summary: a rule *X* can access the code in *Y* if there exists a dependency path between them that begins with a `deps` edge followed by zero or more `exports` edges. Let's see some examples to illustrate this.  Assume *A* depends on *B* and *B* depends on *C*. In this case C is a *transitive* dependency of A, so changing C's sources and rebuilding A will correctly rebuild everything. However A will not be able to use classes in C. To allow that, either A has to declare C in its `deps`, or B can make it easier for A (and anything that may depend on A) by declaring C in its (B's) `exports` attribute.  The closure of exported libraries is available to all direct parent rules. Take a slightly different example: A depends on B, B depends on C and D, and also exports C but not D. Now A has access to C but not to D. Now, if C and D exported some libraries, C' and D' respectively, A could only access C' but not D'.  Important: an exported rule is not a regular dependency. Sticking to the previous example, if B exports C and wants to also use C, it has to also list it in its own `deps`. |
 | `javabuilder_jvm_flags` | List of strings; default is `[]` Restricted API, do not use! |
-| `javacopts` | List of strings; default is `[]` Extra compiler options for this library. Subject to ["Make variable"](make-variables) substitution and [Bourne shell tokenization](common-definitions#sh-tokenization). These compiler options are passed to javac after the global compiler options. |
+| `javacopts` | List of strings; default is `[]` Extra compiler options for this library. Subject to ["Make variable"](/versions/8.4.2/reference/be/make-variables) substitution and [Bourne shell tokenization](/versions/8.4.2/reference/be/common-definitions#sh-tokenization). These compiler options are passed to javac after the global compiler options. |
 | `neverlink` | Boolean; default is `False` Whether this library should only be used for compilation and not at runtime. Useful if the library will be provided by the runtime environment during execution. Examples of such libraries are the IDE APIs for IDE plug-ins or `tools.jar` for anything running on a standard JDK. Note that `neverlink = True` does not prevent the compiler from inlining material from this library into compilation targets that depend on it, as permitted by the Java Language Specification (e.g., `static final` constants of `String` or of primitive types). The preferred use case is therefore when the runtime library is identical to the compilation library.  If the runtime library differs from the compilation library then you must ensure that it differs only in places that the JLS forbids compilers to inline (and that must hold for all future versions of the JLS). |
 | `plugins` | List of [labels](/versions/8.4.2/concepts/labels); default is `[]` Java compiler plugins to run at compile-time. Every `java_plugin` specified in this attribute will be run whenever this rule is built. A library may also inherit plugins from dependencies that use `exported_plugins`. Resources generated by the plugin will be included in the resulting jar of this rule. |
 | `proguard_specs` | List of [labels](/versions/8.4.2/concepts/labels); default is `[]` Files to be used as Proguard specification. These will describe the set of specifications to be used by Proguard. If specified, they will be added to any `android_binary` target depending on this library. The files included here must only have idempotent rules, namely -dontnote, -dontwarn, assumenosideeffects, and rules that start with -keep. Other options can only appear in `android_binary`'s proguard\_specs, to ensure non-tautological merges. |
@@ -207,7 +207,7 @@ This rule compiles and links sources into a `.jar` file.
 
 ## java\_test
 
-[View rule sourceopen\_in\_new](@rules_java//java/bazel/rules/bazel_java_test.bzl)
+[View rule sourceopen\_in\_new](/versions/8.4.2/reference/be/@rules_java//java/bazel/rules/bazel_java_test.bzl)
 
 ```
 java_test(name, deps, srcs, data, resources, add_exports, add_opens, args, bootclasspath, classpath_resources, compatible_with, create_executable, deploy_manifest_lines, deprecation, distribs, env, env_inherit, exec_compatible_with, exec_properties, features, flaky, javacopts, jvm_flags, launcher, licenses, local, main_class, neverlink, plugins, resource_strip_prefix, restricted_to, runtime_deps, shard_count, size, stamp, tags, target_compatible_with, test_class, testonly, timeout, toolchains, use_launcher, use_testrunner, visibility)
@@ -225,8 +225,7 @@ test code. The test runner's main method is invoked instead of the main class be
   [java\_binary](#java_binary) for more details.
 
 See the section on `java_binary()` arguments. This rule also
-supports all [attributes common
-to all test rules (\*\_test)](https://bazel.build/versions/8.4.2/reference/be/common-definitions#common-attributes-tests).
+supports all [attributes common to all test rules (\*\_test)](https://bazel.build/versions/8.4.2/reference/be/common-definitions#common-attributes-tests).
 
 #### Examples
 
@@ -255,7 +254,7 @@ java_test(
 | Attributes | |
 | --- | --- |
 | `name` | [Name](/versions/8.4.2/concepts/labels#target-names); required  A unique name for this target. |
-| `deps` | List of [labels](/versions/8.4.2/concepts/labels); default is `[]` The list of other libraries to be linked in to the target. See general comments about `deps` at [Typical attributes defined by most build rules](common-definitions#typical-attributes). |
+| `deps` | List of [labels](/versions/8.4.2/concepts/labels); default is `[]` The list of other libraries to be linked in to the target. See general comments about `deps` at [Typical attributes defined by most build rules](/versions/8.4.2/reference/be/common-definitions#typical-attributes). |
 | `srcs` | List of [labels](/versions/8.4.2/concepts/labels); default is `[]` The list of source files that are processed to create the target. This attribute is almost always required; see exceptions below. Source files of type `.java` are compiled. In case of generated `.java` files it is generally advisable to put the generating rule's name here instead of the name of the file itself. This not only improves readability but makes the rule more resilient to future changes: if the generating rule generates different files in the future, you only need to fix one place: the `outs` of the generating rule. You should not list the generating rule in `deps` because it is a no-op.  Source files of type `.srcjar` are unpacked and compiled. (This is useful if you need to generate a set of `.java` files with a genrule.)  Rules: if the rule (typically `genrule` or `filegroup`) generates any of the files listed above, they will be used the same way as described for source files.  This argument is almost always required, except if a [`main_class`](#java_binary.main_class) attribute specifies a class on the runtime classpath or you specify the `runtime_deps` argument. |
 | `data` | List of [labels](/versions/8.4.2/concepts/labels); default is `[]` The list of files needed by this library at runtime. See general comments about `data` at [Typical attributes defined by most build rules](/versions/8.4.2/reference/be/common-definitions#typical-attributes). |
 | `resources` | List of [labels](/versions/8.4.2/concepts/labels); default is `[]` A list of data files to include in a Java jar. Resources may be source files or generated files.  If resources are specified, they will be bundled in the jar along with the usual `.class` files produced by compilation. The location of the resources inside of the jar file is determined by the project structure. Bazel first looks for Maven's [standard directory layout](https://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html), (a "src" directory followed by a "resources" directory grandchild). If that is not found, Bazel then looks for the topmost directory named "java" or "javatests" (so, for example, if a resource is at `/x/java/y/java/z`, the path of the resource will be `y/java/z`. This heuristic cannot be overridden, however, the `resource_strip_prefix` attribute can be used to specify a specific alternative directory for resource files. |
@@ -264,9 +263,9 @@ java_test(
 | `bootclasspath` | [Label](/versions/8.4.2/concepts/labels); default is `None` Restricted API, do not use! |
 | `classpath_resources` | List of [labels](/versions/8.4.2/concepts/labels); default is `[]` *DO NOT USE THIS OPTION UNLESS THERE IS NO OTHER WAY)* A list of resources that must be located at the root of the java tree. This attribute's only purpose is to support third-party libraries that require that their resources be found on the classpath as exactly `"myconfig.xml"`. It is only allowed on binaries and not libraries, due to the danger of namespace conflicts. |
 | `create_executable` | Boolean; default is `True` Deprecated, use `java_single_jar` instead. |
-| `deploy_manifest_lines` | List of strings; default is `[]` A list of lines to add to the `META-INF/manifest.mf` file generated for the `*_deploy.jar` target. The contents of this attribute are *not* subject to ["Make variable"](make-variables) substitution. |
-| `javacopts` | List of strings; default is `[]` Extra compiler options for this binary. Subject to ["Make variable"](make-variables) substitution and [Bourne shell tokenization](common-definitions#sh-tokenization). These compiler options are passed to javac after the global compiler options. |
-| `jvm_flags` | List of strings; default is `[]` A list of flags to embed in the wrapper script generated for running this binary. Subject to [$(location)](/versions/8.4.2/reference/be/make-variables#location) and ["Make variable"](make-variables) substitution, and [Bourne shell tokenization](common-definitions#sh-tokenization). The wrapper script for a Java binary includes a CLASSPATH definition (to find all the dependent jars) and invokes the right Java interpreter. The command line generated by the wrapper script includes the name of the main class followed by a `"$@"` so you can pass along other arguments after the classname. However, arguments intended for parsing by the JVM must be specified *before* the classname on the command line. The contents of `jvm_flags` are added to the wrapper script before the classname is listed.  Note that this attribute has *no effect* on `*_deploy.jar` outputs. |
+| `deploy_manifest_lines` | List of strings; default is `[]` A list of lines to add to the `META-INF/manifest.mf` file generated for the `*_deploy.jar` target. The contents of this attribute are *not* subject to ["Make variable"](/versions/8.4.2/reference/be/make-variables) substitution. |
+| `javacopts` | List of strings; default is `[]` Extra compiler options for this binary. Subject to ["Make variable"](/versions/8.4.2/reference/be/make-variables) substitution and [Bourne shell tokenization](/versions/8.4.2/reference/be/common-definitions#sh-tokenization). These compiler options are passed to javac after the global compiler options. |
+| `jvm_flags` | List of strings; default is `[]` A list of flags to embed in the wrapper script generated for running this binary. Subject to [$(location)](/versions/8.4.2/reference/be/make-variables#location) and ["Make variable"](/versions/8.4.2/reference/be/make-variables) substitution, and [Bourne shell tokenization](/versions/8.4.2/reference/be/common-definitions#sh-tokenization). The wrapper script for a Java binary includes a CLASSPATH definition (to find all the dependent jars) and invokes the right Java interpreter. The command line generated by the wrapper script includes the name of the main class followed by a `"$@"` so you can pass along other arguments after the classname. However, arguments intended for parsing by the JVM must be specified *before* the classname on the command line. The contents of `jvm_flags` are added to the wrapper script before the classname is listed.  Note that this attribute has *no effect* on `*_deploy.jar` outputs. |
 | `launcher` | [Label](/versions/8.4.2/concepts/labels); default is `None` Specify a binary that will be used to run your Java program instead of the normal `bin/java` program included with the JDK. The target must be a `cc_binary`. Any `cc_binary` that implements the [Java Invocation API](http://docs.oracle.com/javase/7/docs/technotes/guides/jni/spec/invocation.html) can be specified as a value for this attribute. By default, Bazel will use the normal JDK launcher (bin/java or java.exe).  The related [`--java_launcher`](/versions/8.4.2/docs/user-manual#flag--java_launcher) Bazel flag affects only those `java_binary` and `java_test` targets that have *not* specified a `launcher` attribute.  Note that your native (C++, SWIG, JNI) dependencies will be built differently depending on whether you are using the JDK launcher or another launcher:   * If you are using the normal JDK launcher (the default), native dependencies are   built as a shared library named `{name}_nativedeps.so`, where   `{name}` is the `name` attribute of this java\_binary rule.   Unused code is *not* removed by the linker in this configuration. * If you are using any other launcher, native (C++) dependencies are statically   linked into a binary named `{name}_nativedeps`, where `{name}`   is the `name` attribute of this java\_binary rule. In this case,   the linker will remove any code it thinks is unused from the resulting binary,   which means any C++ code accessed only via JNI may not be linked in unless   that `cc_library` target specifies `alwayslink = True`.   When using any launcher other than the default JDK launcher, the format of the `*_deploy.jar` output changes. See the main [java\_binary](#java_binary) docs for details. |
 | `main_class` | String; default is `""` Name of class with `main()` method to use as entry point. If a rule uses this option, it does not need a `srcs=[...]` list. Thus, with this attribute one can make an executable from a Java library that already contains one or more `main()` methods. The value of this attribute is a class name, not a source file. The class must be available at runtime: it may be compiled by this rule (from `srcs`) or provided by direct or transitive dependencies (through `runtime_deps` or `deps`). If the class is unavailable, the binary will fail at runtime; there is no build-time check. |
 | `neverlink` | Boolean; default is `False` |
@@ -280,7 +279,7 @@ java_test(
 
 ## java\_package\_configuration
 
-[View rule sourceopen\_in\_new](@rules_java//java/common/rules/java_package_configuration.bzl)
+[View rule sourceopen\_in\_new](/versions/8.4.2/reference/be/@rules_java//java/common/rules/java_package_configuration.bzl)
 
 ```
 java_package_configuration(name, data, compatible_with, deprecation, distribs, exec_compatible_with, exec_properties, features, javacopts, output_licenses, packages, restricted_to, system, tags, target_compatible_with, testonly, toolchains, visibility)
@@ -328,7 +327,7 @@ java_toolchain(
 
 ## java\_plugin
 
-[View rule sourceopen\_in\_new](@rules_java//java/bazel/rules/bazel_java_plugin.bzl)
+[View rule sourceopen\_in\_new](/versions/8.4.2/reference/be/@rules_java//java/bazel/rules/bazel_java_plugin.bzl)
 
 ```
 java_plugin(name, deps, srcs, data, resources, add_exports, add_opens, bootclasspath, compatible_with, deprecation, distribs, exec_compatible_with, exec_properties, features, generates_api, javabuilder_jvm_flags, javacopts, licenses, neverlink, output_licenses, plugins, processor_class, proguard_specs, resource_strip_prefix, restricted_to, tags, target_compatible_with, testonly, toolchains, visibility)
@@ -364,7 +363,7 @@ except for the addition of the `processor_class` and
 | `bootclasspath` | [Label](/versions/8.4.2/concepts/labels); default is `None` Restricted API, do not use! |
 | `generates_api` | Boolean; default is `False` This attribute marks annotation processors that generate API code. If a rule uses an API-generating annotation processor, other rules depending on it can refer to the generated code only if their compilation actions are scheduled after the generating rule. This attribute instructs Bazel to introduce scheduling constraints when --java\_header\_compilation is enabled. *WARNING: This attribute affects build performance, use it only if necessary.* |
 | `javabuilder_jvm_flags` | List of strings; default is `[]` Restricted API, do not use! |
-| `javacopts` | List of strings; default is `[]` Extra compiler options for this library. Subject to ["Make variable"](make-variables) substitution and [Bourne shell tokenization](common-definitions#sh-tokenization). These compiler options are passed to javac after the global compiler options. |
+| `javacopts` | List of strings; default is `[]` Extra compiler options for this library. Subject to ["Make variable"](/versions/8.4.2/reference/be/make-variables) substitution and [Bourne shell tokenization](/versions/8.4.2/reference/be/common-definitions#sh-tokenization). These compiler options are passed to javac after the global compiler options. |
 | `neverlink` | Boolean; default is `False` Whether this library should only be used for compilation and not at runtime. Useful if the library will be provided by the runtime environment during execution. Examples of such libraries are the IDE APIs for IDE plug-ins or `tools.jar` for anything running on a standard JDK. Note that `neverlink = True` does not prevent the compiler from inlining material from this library into compilation targets that depend on it, as permitted by the Java Language Specification (e.g., `static final` constants of `String` or of primitive types). The preferred use case is therefore when the runtime library is identical to the compilation library.  If the runtime library differs from the compilation library then you must ensure that it differs only in places that the JLS forbids compilers to inline (and that must hold for all future versions of the JLS). |
 | `output_licenses` | List of strings; default is `[]` |
 | `plugins` | List of [labels](/versions/8.4.2/concepts/labels); default is `[]` Java compiler plugins to run at compile-time. Every `java_plugin` specified in this attribute will be run whenever this rule is built. A library may also inherit plugins from dependencies that use `exported_plugins`. Resources generated by the plugin will be included in the resulting jar of this rule. |
@@ -374,7 +373,7 @@ except for the addition of the `processor_class` and
 
 ## java\_runtime
 
-[View rule sourceopen\_in\_new](@rules_java//java/common/rules/java_runtime.bzl)
+[View rule sourceopen\_in\_new](/versions/8.4.2/reference/be/@rules_java//java/common/rules/java_runtime.bzl)
 
 ```
 java_runtime(name, srcs, compatible_with, default_cds, deprecation, distribs, exec_compatible_with, exec_properties, features, hermetic_srcs, hermetic_static_libs, java, java_home, lib_ct_sym, lib_modules, output_licenses, restricted_to, tags, target_compatible_with, testonly, toolchains, version, visibility)
@@ -410,7 +409,7 @@ java_runtime(
 
 ## java\_toolchain
 
-[View rule sourceopen\_in\_new](@rules_java//java/common/rules/java_toolchain.bzl)
+[View rule sourceopen\_in\_new](/versions/8.4.2/reference/be/@rules_java//java/common/rules/java_toolchain.bzl)
 
 ```
 java_toolchain(name, android_lint_data, android_lint_jvm_opts, android_lint_opts, android_lint_package_configuration, android_lint_runner, bootclasspath, compatible_javacopts, compatible_with, deprecation, deps_checker, distribs, exec_compatible_with, exec_properties, features, forcibly_disable_header_compilation, genclass, header_compiler, header_compiler_builtin_processors, header_compiler_direct, ijar, jacocorunner, java_runtime, javabuilder, javabuilder_data, javabuilder_jvm_opts, javac_supports_multiplex_workers, javac_supports_worker_cancellation, javac_supports_worker_multiplex_sandboxing, javac_supports_workers, javacopts, jspecify_implicit_deps, jspecify_javacopts, jspecify_packages, jspecify_processor, jspecify_processor_class, jspecify_stubs, jvm_opts, licenses, misc, oneversion, oneversion_allowlist, oneversion_allowlist_for_tests, oneversion_whitelist, package_configuration, proguard_allowlister, reduced_classpath_incompatible_processors, restricted_to, singlejar, source_version, tags, target_compatible_with, target_version, testonly, timezone_data, toolchains, tools, turbine_data, turbine_jvm_opts, visibility, xlint)
diff --git a/versions/8.4.2/reference/be/make-variables.mdx b/versions/8.4.2/reference/be/make-variables.mdx
index 8836e398..2b02ba39 100644
--- a/versions/8.4.2/reference/be/make-variables.mdx
+++ b/versions/8.4.2/reference/be/make-variables.mdx
@@ -19,8 +19,7 @@ targets, and *custom* variables, which are defined in dependency targets
 and only available to targets that depend on them.
 
 The reason for the term "Make" is historical: the syntax and semantics of
-these variables were originally intended to match [GNU
-Make](https://www.gnu.org/software/make/manual/html_node/Using-Variables.html).
+these variables were originally intended to match [GNU Make](https://www.gnu.org/software/make/manual/html_node/Using-Variables.html).
 
 ## Use
 
@@ -64,8 +63,7 @@ and look at the top output lines with capital letters.
 **Toolchain option variables**
 
 * `COMPILATION_MODE`:
-  `fastbuild`, `dbg`, or `opt`. ([more
-  details](https://bazel.build/versions/8.4.2/docs/user-manual#flag--compilation_mode))
+  `fastbuild`, `dbg`, or `opt`. ([more details](https://bazel.build/versions/8.4.2/docs/user-manual#flag--compilation_mode))
 
 **Path variables**
 
@@ -304,7 +302,7 @@ rare cases. If you are tempted to use them, please [contact the Bazel devs](http
 
 Rule and [toolchain](/versions/8.4.2/docs/toolchains) writers can define
 completely custom variables by returning a
-[TemplateVariableInfo](/versions/8.4.2/rules/lib/TemplateVariableInfo)
+[TemplateVariableInfo](/versions/8.4.2/rules/lib/providers/TemplateVariableInfo)
 provider. Any rules depending on these through the
 `toolchains` attribute can then read their values:
 
diff --git a/versions/8.4.2/reference/be/overview.mdx b/versions/8.4.2/reference/be/overview.mdx
index d9e22042..f359b09b 100644
--- a/versions/8.4.2/reference/be/overview.mdx
+++ b/versions/8.4.2/reference/be/overview.mdx
@@ -37,18 +37,18 @@ For non-native Starlark rules that ship separately from Bazel, see the list of
 
 | Language | Binary rules | Library rules | Test rules | Other rules |
 | --- | --- | --- | --- | --- |
-| C / C++ | [cc\_binary](c-cpp#cc_binary) | [cc\_import](c-cpp#cc_import)   [cc\_library](c-cpp#cc_library)   [cc\_shared\_library](c-cpp#cc_shared_library)   [cc\_static\_library](c-cpp#cc_static_library) | [cc\_test](c-cpp#cc_test) | [cc\_toolchain](c-cpp#cc_toolchain)   [cc\_toolchain\_suite](c-cpp#cc_toolchain_suite)   [fdo\_prefetch\_hints](c-cpp#fdo_prefetch_hints)   [fdo\_profile](c-cpp#fdo_profile)   [memprof\_profile](c-cpp#memprof_profile)   [propeller\_optimize](c-cpp#propeller_optimize) |
-| Java | [java\_binary](java#java_binary) | [java\_import](java#java_import)   [java\_library](java#java_library) | [java\_test](java#java_test) | [java\_package\_configuration](java#java_package_configuration)   [java\_plugin](java#java_plugin)   [java\_runtime](java#java_runtime)   [java\_toolchain](java#java_toolchain) |
-| Objective-C |  | [objc\_import](objective-c#objc_import)   [objc\_library](objective-c#objc_library) |  |  |
-| Protocol Buffer |  | [cc\_proto\_library](protocol-buffer#cc_proto_library)   [java\_lite\_proto\_library](protocol-buffer#java_lite_proto_library)   [java\_proto\_library](protocol-buffer#java_proto_library)   [proto\_library](protocol-buffer#proto_library)   [py\_proto\_library](protocol-buffer#py_proto_library) |  | [proto\_lang\_toolchain](protocol-buffer#proto_lang_toolchain)   [proto\_toolchain](protocol-buffer#proto_toolchain) |
-| Python | [py\_binary](python#py_binary) | [py\_library](python#py_library) | [py\_test](python#py_test) | [py\_runtime](python#py_runtime) |
-| Shell | [sh\_binary](shell#sh_binary) | [sh\_library](shell#sh_library) | [sh\_test](shell#sh_test) |  |
+| C / C++ | [cc\_binary](/versions/8.4.2/reference/be/c-cpp#cc_binary) | [cc\_import](/versions/8.4.2/reference/be/c-cpp#cc_import)   [cc\_library](/versions/8.4.2/reference/be/c-cpp#cc_library)   [cc\_shared\_library](/versions/8.4.2/reference/be/c-cpp#cc_shared_library)   [cc\_static\_library](/versions/8.4.2/reference/be/c-cpp#cc_static_library) | [cc\_test](/versions/8.4.2/reference/be/c-cpp#cc_test) | [cc\_toolchain](/versions/8.4.2/reference/be/c-cpp#cc_toolchain)   [cc\_toolchain\_suite](/versions/8.4.2/reference/be/c-cpp#cc_toolchain_suite)   [fdo\_prefetch\_hints](/versions/8.4.2/reference/be/c-cpp#fdo_prefetch_hints)   [fdo\_profile](/versions/8.4.2/reference/be/c-cpp#fdo_profile)   [memprof\_profile](/versions/8.4.2/reference/be/c-cpp#memprof_profile)   [propeller\_optimize](/versions/8.4.2/reference/be/c-cpp#propeller_optimize) |
+| Java | [java\_binary](/versions/8.4.2/reference/be/java#java_binary) | [java\_import](/versions/8.4.2/reference/be/java#java_import)   [java\_library](/versions/8.4.2/reference/be/java#java_library) | [java\_test](/versions/8.4.2/reference/be/java#java_test) | [java\_package\_configuration](/versions/8.4.2/reference/be/java#java_package_configuration)   [java\_plugin](/versions/8.4.2/reference/be/java#java_plugin)   [java\_runtime](/versions/8.4.2/reference/be/java#java_runtime)   [java\_toolchain](/versions/8.4.2/reference/be/java#java_toolchain) |
+| Objective-C |  | [objc\_import](/versions/8.4.2/reference/be/objective-c#objc_import)   [objc\_library](/versions/8.4.2/reference/be/objective-c#objc_library) |  |  |
+| Protocol Buffer |  | [cc\_proto\_library](/versions/8.4.2/reference/be/protocol-buffer#cc_proto_library)   [java\_lite\_proto\_library](/versions/8.4.2/reference/be/protocol-buffer#java_lite_proto_library)   [java\_proto\_library](/versions/8.4.2/reference/be/protocol-buffer#java_proto_library)   [proto\_library](/versions/8.4.2/reference/be/protocol-buffer#proto_library)   [py\_proto\_library](/versions/8.4.2/reference/be/protocol-buffer#py_proto_library) |  | [proto\_lang\_toolchain](/versions/8.4.2/reference/be/protocol-buffer#proto_lang_toolchain)   [proto\_toolchain](/versions/8.4.2/reference/be/protocol-buffer#proto_toolchain) |
+| Python | [py\_binary](/versions/8.4.2/reference/be/python#py_binary) | [py\_library](/versions/8.4.2/reference/be/python#py_library) | [py\_test](/versions/8.4.2/reference/be/python#py_test) | [py\_runtime](/versions/8.4.2/reference/be/python#py_runtime) |
+| Shell | [sh\_binary](/versions/8.4.2/reference/be/shell#sh_binary) | [sh\_library](/versions/8.4.2/reference/be/shell#sh_library) | [sh\_test](/versions/8.4.2/reference/be/shell#sh_test) |  |
 
 ### Language-agnostic native rules
 
 | Family | Rules |
 | --- | --- |
-| Extra Actions | * [action\_listener](extra-actions#action_listener)* [extra\_action](extra-actions#extra_action) |
-| General | * [alias](general#alias)* [config\_setting](general#config_setting)* [filegroup](general#filegroup)* [genquery](general#genquery)* [genrule](general#genrule)* [starlark\_doc\_extract](general#starlark_doc_extract)* [test\_suite](general#test_suite) |
-| Platforms and Toolchains | * [constraint\_setting](platforms-and-toolchains#constraint_setting)* [constraint\_value](platforms-and-toolchains#constraint_value)* [platform](platforms-and-toolchains#platform)* [toolchain](platforms-and-toolchains#toolchain)* [toolchain\_type](platforms-and-toolchains#toolchain_type) |
-| Workspace | * [bind](workspace#bind)* [local\_repository](workspace#local_repository)* [new\_local\_repository](workspace#new_local_repository) |
\ No newline at end of file
+| Extra Actions | * [action\_listener](/versions/8.4.2/reference/be/extra-actions#action_listener)* [extra\_action](/versions/8.4.2/reference/be/extra-actions#extra_action) |
+| General | * [alias](/versions/8.4.2/reference/be/general#alias)* [config\_setting](/versions/8.4.2/reference/be/general#config_setting)* [filegroup](/versions/8.4.2/reference/be/general#filegroup)* [genquery](/versions/8.4.2/reference/be/general#genquery)* [genrule](/versions/8.4.2/reference/be/general#genrule)* [starlark\_doc\_extract](/versions/8.4.2/reference/be/general#starlark_doc_extract)* [test\_suite](/versions/8.4.2/reference/be/general#test_suite) |
+| Platforms and Toolchains | * [constraint\_setting](/versions/8.4.2/reference/be/platforms-and-toolchains#constraint_setting)* [constraint\_value](/versions/8.4.2/reference/be/platforms-and-toolchains#constraint_value)* [platform](/versions/8.4.2/reference/be/platforms-and-toolchains#platform)* [toolchain](/versions/8.4.2/reference/be/platforms-and-toolchains#toolchain)* [toolchain\_type](/versions/8.4.2/reference/be/platforms-and-toolchains#toolchain_type) |
+| Workspace | * [bind](/versions/8.4.2/reference/be/workspace#bind)* [local\_repository](/versions/8.4.2/reference/be/workspace#local_repository)* [new\_local\_repository](/versions/8.4.2/reference/be/workspace#new_local_repository) |
\ No newline at end of file
diff --git a/versions/8.4.2/reference/be/platforms-and-toolchains.mdx b/versions/8.4.2/reference/be/platforms-and-toolchains.mdx
index 2f248408..0182f4c2 100644
--- a/versions/8.4.2/reference/be/platforms-and-toolchains.mdx
+++ b/versions/8.4.2/reference/be/platforms-and-toolchains.mdx
@@ -39,7 +39,7 @@ define a platform targeting an obscure cpu architecture.
 | Attributes | |
 | --- | --- |
 | `name` | [Name](/versions/8.4.2/concepts/labels#target-names); required  A unique name for this target. |
-| `default_constraint_value` | [Name](/versions/8.4.2/concepts/labels#target-names); [nonconfigurable](common-definitions#configurable-attributes); default is `None` The label of the default value for this setting, to be used if no value is given. If this attribute is present, the `constraint_value` it points to must be defined in the same package as this `constraint_setting`. If a constraint setting has a default value, then whenever a platform does not include any constraint value for that setting, it is the same as if the platform had specified the default value. Otherwise, if there is no default value, the constraint setting is considered to be unspecified by that platform. In that case, the platform would not match against any constraint list (such as for a `config_setting`) that requires a particular value for that setting. |
+| `default_constraint_value` | [Name](/versions/8.4.2/concepts/labels#target-names); [nonconfigurable](/versions/8.4.2/reference/be/common-definitions#configurable-attributes); default is `None` The label of the default value for this setting, to be used if no value is given. If this attribute is present, the `constraint_value` it points to must be defined in the same package as this `constraint_setting`. If a constraint setting has a default value, then whenever a platform does not include any constraint value for that setting, it is the same as if the platform had specified the default value. Otherwise, if there is no default value, the constraint setting is considered to be unspecified by that platform. In that case, the platform would not match against any constraint list (such as for a `config_setting`) that requires a particular value for that setting. |
 
 ## constraint\_value
 
@@ -73,7 +73,7 @@ Platforms can then declare that they have the `mips` architecture as an alternat
 | Attributes | |
 | --- | --- |
 | `name` | [Name](/versions/8.4.2/concepts/labels#target-names); required  A unique name for this target. |
-| `constraint_setting` | [Label](/versions/8.4.2/concepts/labels); [nonconfigurable](common-definitions#configurable-attributes); required The `constraint_setting` for which this `constraint_value` is a possible choice. |
+| `constraint_setting` | [Label](/versions/8.4.2/concepts/labels); [nonconfigurable](/versions/8.4.2/reference/be/common-definitions#configurable-attributes); required The `constraint_setting` for which this `constraint_value` is a possible choice. |
 
 ## platform
 
@@ -278,12 +278,12 @@ In this example, the child platforms have the following properties:
 | Attributes | |
 | --- | --- |
 | `name` | [Name](/versions/8.4.2/concepts/labels#target-names); required  A unique name for this target. |
-| `constraint_values` | List of [labels](/versions/8.4.2/concepts/labels); [nonconfigurable](common-definitions#configurable-attributes); default is `[]` The combination of constraint choices that this platform comprises. In order for a platform to apply to a given environment, the environment must have at least the values in this list. Each `constraint_value` in this list must be for a different `constraint_setting`. For example, you cannot define a platform that requires the cpu architecture to be both `@platforms//cpu:x86_64` and `@platforms//cpu:arm`. |
-| `exec_properties` | Dictionary: String -> String; [nonconfigurable](common-definitions#configurable-attributes); default is `{}` A map of strings that affect the way actions are executed remotely. Bazel makes no attempt to interpret this, it is treated as opaque data that's forwarded via the Platform field of the [remote execution protocol](https://github.com/bazelbuild/remote-apis). This includes any data from the parent platform's `exec_properties` attributes. If the child and parent platform define the same keys, the child's values are kept. Any keys associated with a value that is an empty string are removed from the dictionary. This attribute is a full replacement for the deprecated `remote_execution_properties`. |
-| `flags` | List of strings; [nonconfigurable](common-definitions#configurable-attributes); default is `[]` A list of flags that will be enabled when this platform is used as the target platform in a configuration. Only flags that can be set in transitions are allowed to be used. |
-| `missing_toolchain_error` | String; [nonconfigurable](common-definitions#configurable-attributes); default is `"For more information on platforms or toolchains see https://bazel.build/concepts/platforms-intro."` A custom error message that is displayed when a mandatory toolchain requirement cannot be satisfied for this target platform. Intended to point to relevant documentation users can read to understand why their toolchains are misconfigured. Not inherited from parent platforms. |
-| `parents` | List of [labels](/versions/8.4.2/concepts/labels); [nonconfigurable](common-definitions#configurable-attributes); default is `[]` The label of a `platform` target that this platform should inherit from. Although the attribute takes a list, there should be no more than one platform present. Any constraint\_settings not set directly on this platform will be found in the parent platform. See the section on [Platform Inheritance](#platform_inheritance) for details. |
-| `remote_execution_properties` | String; [nonconfigurable](common-definitions#configurable-attributes); default is `""` DEPRECATED. Please use exec\_properties attribute instead. A string used to configure a remote execution platform. Actual builds make no attempt to interpret this, it is treated as opaque data that can be used by a specific SpawnRunner. This can include data from the parent platform's "remote\_execution\_properties" attribute, by using the macro "\{PARENT\_REMOTE\_EXECUTION\_PROPERTIES\}". See the section on [Platform Inheritance](#platform_inheritance) for details. |
+| `constraint_values` | List of [labels](/versions/8.4.2/concepts/labels); [nonconfigurable](/versions/8.4.2/reference/be/common-definitions#configurable-attributes); default is `[]` The combination of constraint choices that this platform comprises. In order for a platform to apply to a given environment, the environment must have at least the values in this list. Each `constraint_value` in this list must be for a different `constraint_setting`. For example, you cannot define a platform that requires the cpu architecture to be both `@platforms//cpu:x86_64` and `@platforms//cpu:arm`. |
+| `exec_properties` | Dictionary: String -> String; [nonconfigurable](/versions/8.4.2/reference/be/common-definitions#configurable-attributes); default is `{}` A map of strings that affect the way actions are executed remotely. Bazel makes no attempt to interpret this, it is treated as opaque data that's forwarded via the Platform field of the [remote execution protocol](https://github.com/bazelbuild/remote-apis). This includes any data from the parent platform's `exec_properties` attributes. If the child and parent platform define the same keys, the child's values are kept. Any keys associated with a value that is an empty string are removed from the dictionary. This attribute is a full replacement for the deprecated `remote_execution_properties`. |
+| `flags` | List of strings; [nonconfigurable](/versions/8.4.2/reference/be/common-definitions#configurable-attributes); default is `[]` A list of flags that will be enabled when this platform is used as the target platform in a configuration. Only flags that can be set in transitions are allowed to be used. |
+| `missing_toolchain_error` | String; [nonconfigurable](/versions/8.4.2/reference/be/common-definitions#configurable-attributes); default is `"For more information on platforms or toolchains see https://bazel.build/concepts/platforms-intro."` A custom error message that is displayed when a mandatory toolchain requirement cannot be satisfied for this target platform. Intended to point to relevant documentation users can read to understand why their toolchains are misconfigured. Not inherited from parent platforms. |
+| `parents` | List of [labels](/versions/8.4.2/concepts/labels); [nonconfigurable](/versions/8.4.2/reference/be/common-definitions#configurable-attributes); default is `[]` The label of a `platform` target that this platform should inherit from. Although the attribute takes a list, there should be no more than one platform present. Any constraint\_settings not set directly on this platform will be found in the parent platform. See the section on [Platform Inheritance](#platform_inheritance) for details. |
+| `remote_execution_properties` | String; [nonconfigurable](/versions/8.4.2/reference/be/common-definitions#configurable-attributes); default is `""` DEPRECATED. Please use exec\_properties attribute instead. A string used to configure a remote execution platform. Actual builds make no attempt to interpret this, it is treated as opaque data that can be used by a specific SpawnRunner. This can include data from the parent platform's "remote\_execution\_properties" attribute, by using the macro "\{PARENT\_REMOTE\_EXECUTION\_PROPERTIES\}". See the section on [Platform Inheritance](#platform_inheritance) for details. |
 | `required_settings` | List of [labels](/versions/8.4.2/concepts/labels); default is `[]` A list of `config_setting`s that must be satisfied by the target configuration in order for this platform to be used as an execution platform during toolchain resolution. Required settings are not inherited from parent platforms. |
 
 ## toolchain
@@ -304,12 +304,12 @@ details.
 | Attributes | |
 | --- | --- |
 | `name` | [Name](/versions/8.4.2/concepts/labels#target-names); required  A unique name for this target. |
-| `exec_compatible_with` | List of [labels](/versions/8.4.2/concepts/labels); [nonconfigurable](common-definitions#configurable-attributes); default is `[]` A list of `constraint_value`s that must be satisfied by an execution platform in order for this toolchain to be selected for a target building on that platform. |
-| `target_compatible_with` | List of [labels](/versions/8.4.2/concepts/labels); [nonconfigurable](common-definitions#configurable-attributes); default is `[]` A list of `constraint_value`s that must be satisfied by the target platform in order for this toolchain to be selected for a target building for that platform. |
+| `exec_compatible_with` | List of [labels](/versions/8.4.2/concepts/labels); [nonconfigurable](/versions/8.4.2/reference/be/common-definitions#configurable-attributes); default is `[]` A list of `constraint_value`s that must be satisfied by an execution platform in order for this toolchain to be selected for a target building on that platform. |
+| `target_compatible_with` | List of [labels](/versions/8.4.2/concepts/labels); [nonconfigurable](/versions/8.4.2/reference/be/common-definitions#configurable-attributes); default is `[]` A list of `constraint_value`s that must be satisfied by the target platform in order for this toolchain to be selected for a target building for that platform. |
 | `target_settings` | List of [labels](/versions/8.4.2/concepts/labels); default is `[]` A list of `config_setting`s that must be satisfied by the target configuration in order for this toolchain to be selected during toolchain resolution. |
 | `toolchain` | [Name](/versions/8.4.2/concepts/labels#target-names); required The target representing the actual tool or tool suite that is made available when this toolchain is selected. |
-| `toolchain_type` | [Label](/versions/8.4.2/concepts/labels); [nonconfigurable](common-definitions#configurable-attributes); required The label of a `toolchain_type` target that represents the role that this toolchain serves. |
-| `use_target_platform_constraints` | Boolean; [nonconfigurable](common-definitions#configurable-attributes); default is `False` If `True`, this toolchain behaves as if its `exec_compatible_with` and `target_compatible_with` constraints are set to those of the current target platform. `exec_compatible_with` and `target_compatible_with` must not be set in that case. |
+| `toolchain_type` | [Label](/versions/8.4.2/concepts/labels); [nonconfigurable](/versions/8.4.2/reference/be/common-definitions#configurable-attributes); required The label of a `toolchain_type` target that represents the role that this toolchain serves. |
+| `use_target_platform_constraints` | Boolean; [nonconfigurable](/versions/8.4.2/reference/be/common-definitions#configurable-attributes); default is `False` If `True`, this toolchain behaves as if its `exec_compatible_with` and `target_compatible_with` constraints are set to those of the current target platform. `exec_compatible_with` and `target_compatible_with` must not be set in that case. |
 
 ## toolchain\_type
 
@@ -353,4 +353,4 @@ bar_binary = rule(
 | Attributes | |
 | --- | --- |
 | `name` | [Name](/versions/8.4.2/concepts/labels#target-names); required  A unique name for this target. |
-| `no_match_error` | String; [nonconfigurable](common-definitions#configurable-attributes); default is `""` A custom error message to display when no matching toolchain is found for this type. |
\ No newline at end of file
+| `no_match_error` | String; [nonconfigurable](/versions/8.4.2/reference/be/common-definitions#configurable-attributes); default is `""` A custom error message to display when no matching toolchain is found for this type. |
\ No newline at end of file
diff --git a/versions/8.4.2/reference/be/protocol-buffer.mdx b/versions/8.4.2/reference/be/protocol-buffer.mdx
index 8a861673..8aaea9e5 100644
--- a/versions/8.4.2/reference/be/protocol-buffer.mdx
+++ b/versions/8.4.2/reference/be/protocol-buffer.mdx
@@ -22,7 +22,7 @@ cc_proto_library(name, deps, compatible_with, deprecation, distribs, exec_compat
 
 `cc_proto_library` generates C++ code from `.proto` files.
 
-`deps` must point to [`proto_library`](protocol-buffer#proto_library) rules.
+`deps` must point to [`proto_library`](/versions/8.4.2/reference/be/protocol-buffer#proto_library) rules.
 
 Example:
 
@@ -47,7 +47,7 @@ proto_library(
 | Attributes | |
 | --- | --- |
 | `name` | [Name](/versions/8.4.2/concepts/labels#target-names); required  A unique name for this target. |
-| `deps` | List of [labels](/versions/8.4.2/concepts/labels); default is `[]` The list of [`proto_library`](protocol-buffer#proto_library) rules to generate C++ code for. |
+| `deps` | List of [labels](/versions/8.4.2/concepts/labels); default is `[]` The list of [`proto_library`](/versions/8.4.2/reference/be/protocol-buffer#proto_library) rules to generate C++ code for. |
 
 ## java\_lite\_proto\_library
 
@@ -59,7 +59,7 @@ java_lite_proto_library(name, deps, compatible_with, deprecation, distribs, exec
 
 `java_lite_proto_library` generates Java code from `.proto` files.
 
-`deps` must point to [`proto_library`](protocol-buffer#proto_library) rules.
+`deps` must point to [`proto_library`](/versions/8.4.2/reference/be/protocol-buffer#proto_library) rules.
 
 Example:
 
@@ -84,7 +84,7 @@ proto_library(
 | Attributes | |
 | --- | --- |
 | `name` | [Name](/versions/8.4.2/concepts/labels#target-names); required  A unique name for this target. |
-| `deps` | List of [labels](/versions/8.4.2/concepts/labels); default is `[]` The list of [`proto_library`](protocol-buffer#proto_library) rules to generate Java code for. |
+| `deps` | List of [labels](/versions/8.4.2/concepts/labels); default is `[]` The list of [`proto_library`](/versions/8.4.2/reference/be/protocol-buffer#proto_library) rules to generate Java code for. |
 
 ## java\_proto\_library
 
@@ -96,7 +96,7 @@ java_proto_library(name, deps, compatible_with, deprecation, distribs, exec_comp
 
 `java_proto_library` generates Java code from `.proto` files.
 
-`deps` must point to [`proto_library`](protocol-buffer#proto_library) rules.
+`deps` must point to [`proto_library`](/versions/8.4.2/reference/be/protocol-buffer#proto_library) rules.
 
 Example:
 
@@ -121,7 +121,7 @@ proto_library(
 | Attributes | |
 | --- | --- |
 | `name` | [Name](/versions/8.4.2/concepts/labels#target-names); required  A unique name for this target. |
-| `deps` | List of [labels](/versions/8.4.2/concepts/labels); default is `[]` The list of [`proto_library`](protocol-buffer#proto_library) rules to generate Java code for. |
+| `deps` | List of [labels](/versions/8.4.2/concepts/labels); default is `[]` The list of [`proto_library`](/versions/8.4.2/reference/be/protocol-buffer#proto_library) rules to generate Java code for. |
 
 ## proto\_library
 
diff --git a/versions/8.4.2/reference/be/python.mdx b/versions/8.4.2/reference/be/python.mdx
index 49950c5e..678d8b80 100644
--- a/versions/8.4.2/reference/be/python.mdx
+++ b/versions/8.4.2/reference/be/python.mdx
@@ -22,13 +22,13 @@ py_binary(name, deps, srcs, data, args, compatible_with, deprecation, distribs,
 | Attributes | |
 | --- | --- |
 | `name` | [Name](/versions/8.4.2/concepts/labels#target-names); required  A unique name for this target. |
-| `deps` | List of [labels](/versions/8.4.2/concepts/labels); default is `[]` List of additional libraries to be linked in to the target. See comments about the [`deps` attribute typically defined by rules](https://bazel.build/reference/be/common-definitions#typical-attributes). These are typically `py\_library` rules. Targets that only provide data files used at runtime belong in the `data` attribute. |
+| `deps` | List of [labels](/versions/8.4.2/concepts/labels); default is `[]` List of additional libraries to be linked in to the target. See comments about the [`deps` attribute typically defined by rules](https://bazel.build/versions/8.4.2/reference/be/common-definitions#typical-attributes). These are typically `py\_library` rules. Targets that only provide data files used at runtime belong in the `data` attribute. |
 | `srcs` | List of [labels](/versions/8.4.2/concepts/labels); required The list of Python source files that are processed to create the target. This includes all your checked-in code and may include generated source files. The `.py` files belong in `srcs` and library targets belong in `deps`. Other binary files that may be needed at run time belong in `data`. |
-| `data` | List of [labels](/versions/8.4.2/concepts/labels); default is `[]` The list of files need by this library at runtime. See comments about the [`data` attribute typically defined by rules](https://bazel.build/reference/be/common-definitions#typical-attributes). There is no `py\_embed\_data` like there is `cc\_embed\_data` and `go\_embed\_data`. This is because Python has a concept of runtime resources. |
+| `data` | List of [labels](/versions/8.4.2/concepts/labels); default is `[]` The list of files need by this library at runtime. See comments about the [`data` attribute typically defined by rules](https://bazel.build/versions/8.4.2/reference/be/common-definitions#typical-attributes). There is no `py\_embed\_data` like there is `cc\_embed\_data` and `go\_embed\_data`. This is because Python has a concept of runtime resources. |
 | `imports` | List of strings; default is `[]` List of import directories to be added to the PYTHONPATH. Subject to "Make variable" substitution. These import directories will be added for this rule and all rules that depend on it (note: not the rules this rule depends on. Each directory will be added to `PYTHONPATH` by `py\_binary` rules that depend on this rule. The strings are repo-runfiles-root relative, Absolute paths (paths that start with `/`) and paths that references a path above the execution root are not allowed and will result in an error. |
 | `legacy_create_init` | Integer; default is `-1` Whether to implicitly create empty `\_\_init\_\_.py` files in the runfiles tree. These are created in every directory containing Python source code or shared libraries, and every parent directory of those directories, excluding the repo root directory. The default, `-1` (auto), means true unless `--incompatible\_default\_to\_explicit\_init\_py` is used. If false, the user is responsible for creating (possibly empty) `\_\_init\_\_.py` files and adding them to the `srcs` of Python targets as required. |
 | `main` | [Label](/versions/8.4.2/concepts/labels); default is `None` Optional; the name of the source file that is the main entry point of the application. This file must also be listed in `srcs`. If left unspecified, `name`, with `.py` appended, is used instead. If `name` does not match any filename in `srcs`, `main` must be specified. |
-| `precompile` | String; default is `"inherit"` Whether py source files \*\*for this target\*\* should be precompiled. Values: \* `inherit`: Allow the downstream binary decide if precompiled files are used. \* `enabled`: Compile Python source files at build time. \* `disabled`: Don't compile Python source files at build time. :::{seealso} \* The {flag}`--precompile` flag, which can override this attribute in some cases and will affect all targets when building. \* The {obj}`pyc\_collection` attribute for transitively enabling precompiling on a per-target basis. \* The [Precompiling](precompiling) docs for a guide about using precompiling. ::: |
+| `precompile` | String; default is `"inherit"` Whether py source files \*\*for this target\*\* should be precompiled. Values: \* `inherit`: Allow the downstream binary decide if precompiled files are used. \* `enabled`: Compile Python source files at build time. \* `disabled`: Don't compile Python source files at build time. :::{seealso} \* The {flag}`--precompile` flag, which can override this attribute in some cases and will affect all targets when building. \* The {obj}`pyc\_collection` attribute for transitively enabling precompiling on a per-target basis. \* The [Precompiling](/versions/8.4.2/reference/be/precompiling) docs for a guide about using precompiling. ::: |
 | `precompile_invalidation_mode` | String; default is `"auto"` How precompiled files should be verified to be up-to-date with their associated source files. Possible values are: \* `auto`: The effective value will be automatically determined by other build settings. \* `checked\_hash`: Use the pyc file if the hash of the source file matches the hash recorded in the pyc file. This is most useful when working with code that you may modify. \* `unchecked\_hash`: Always use the pyc file; don't check the pyc's hash against the source file. This is most useful when the code won't be modified. For more information on pyc invalidation modes, see https://docs.python.org/3/library/py\_compile.html#py\_compile.PycInvalidationMode |
 | `precompile_optimize_level` | Integer; default is `0` The optimization level for precompiled files. For more information about optimization levels, see the `compile()` function's `optimize` arg docs at https://docs.python.org/3/library/functions.html#compile NOTE: The value `-1` means "current interpreter", which will be the interpreter used \_at build time when pycs are generated\_, not the interpreter used at runtime when the code actually runs. |
 | `precompile_source_retention` | String; default is `"inherit"` Determines, when a source file is compiled, if the source file is kept in the resulting output or not. Valid values are: \* `inherit`: Inherit the value from the {flag}`--precompile\_source\_retention` flag. \* `keep\_source`: Include the original Python source. \* `omit\_source`: Don't include the original py source. |
@@ -61,11 +61,11 @@ Source files are no longer added to the runfiles directly.
 | Attributes | |
 | --- | --- |
 | `name` | [Name](/versions/8.4.2/concepts/labels#target-names); required  A unique name for this target. |
-| `deps` | List of [labels](/versions/8.4.2/concepts/labels); default is `[]` List of additional libraries to be linked in to the target. See comments about the [`deps` attribute typically defined by rules](https://bazel.build/reference/be/common-definitions#typical-attributes). These are typically `py\_library` rules. Targets that only provide data files used at runtime belong in the `data` attribute. |
+| `deps` | List of [labels](/versions/8.4.2/concepts/labels); default is `[]` List of additional libraries to be linked in to the target. See comments about the [`deps` attribute typically defined by rules](https://bazel.build/versions/8.4.2/reference/be/common-definitions#typical-attributes). These are typically `py\_library` rules. Targets that only provide data files used at runtime belong in the `data` attribute. |
 | `srcs` | List of [labels](/versions/8.4.2/concepts/labels); default is `[]` The list of Python source files that are processed to create the target. This includes all your checked-in code and may include generated source files. The `.py` files belong in `srcs` and library targets belong in `deps`. Other binary files that may be needed at run time belong in `data`. |
-| `data` | List of [labels](/versions/8.4.2/concepts/labels); default is `[]` The list of files need by this library at runtime. See comments about the [`data` attribute typically defined by rules](https://bazel.build/reference/be/common-definitions#typical-attributes). There is no `py\_embed\_data` like there is `cc\_embed\_data` and `go\_embed\_data`. This is because Python has a concept of runtime resources. |
+| `data` | List of [labels](/versions/8.4.2/concepts/labels); default is `[]` The list of files need by this library at runtime. See comments about the [`data` attribute typically defined by rules](https://bazel.build/versions/8.4.2/reference/be/common-definitions#typical-attributes). There is no `py\_embed\_data` like there is `cc\_embed\_data` and `go\_embed\_data`. This is because Python has a concept of runtime resources. |
 | `imports` | List of strings; default is `[]` List of import directories to be added to the PYTHONPATH. Subject to "Make variable" substitution. These import directories will be added for this rule and all rules that depend on it (note: not the rules this rule depends on. Each directory will be added to `PYTHONPATH` by `py\_binary` rules that depend on this rule. The strings are repo-runfiles-root relative, Absolute paths (paths that start with `/`) and paths that references a path above the execution root are not allowed and will result in an error. |
-| `precompile` | String; default is `"inherit"` Whether py source files \*\*for this target\*\* should be precompiled. Values: \* `inherit`: Allow the downstream binary decide if precompiled files are used. \* `enabled`: Compile Python source files at build time. \* `disabled`: Don't compile Python source files at build time. :::{seealso} \* The {flag}`--precompile` flag, which can override this attribute in some cases and will affect all targets when building. \* The {obj}`pyc\_collection` attribute for transitively enabling precompiling on a per-target basis. \* The [Precompiling](precompiling) docs for a guide about using precompiling. ::: |
+| `precompile` | String; default is `"inherit"` Whether py source files \*\*for this target\*\* should be precompiled. Values: \* `inherit`: Allow the downstream binary decide if precompiled files are used. \* `enabled`: Compile Python source files at build time. \* `disabled`: Don't compile Python source files at build time. :::{seealso} \* The {flag}`--precompile` flag, which can override this attribute in some cases and will affect all targets when building. \* The {obj}`pyc\_collection` attribute for transitively enabling precompiling on a per-target basis. \* The [Precompiling](/versions/8.4.2/reference/be/precompiling) docs for a guide about using precompiling. ::: |
 | `precompile_invalidation_mode` | String; default is `"auto"` How precompiled files should be verified to be up-to-date with their associated source files. Possible values are: \* `auto`: The effective value will be automatically determined by other build settings. \* `checked\_hash`: Use the pyc file if the hash of the source file matches the hash recorded in the pyc file. This is most useful when working with code that you may modify. \* `unchecked\_hash`: Always use the pyc file; don't check the pyc's hash against the source file. This is most useful when the code won't be modified. For more information on pyc invalidation modes, see https://docs.python.org/3/library/py\_compile.html#py\_compile.PycInvalidationMode |
 | `precompile_optimize_level` | Integer; default is `0` The optimization level for precompiled files. For more information about optimization levels, see the `compile()` function's `optimize` arg docs at https://docs.python.org/3/library/functions.html#compile NOTE: The value `-1` means "current interpreter", which will be the interpreter used \_at build time when pycs are generated\_, not the interpreter used at runtime when the code actually runs. |
 | `precompile_source_retention` | String; default is `"inherit"` Determines, when a source file is compiled, if the source file is kept in the resulting output or not. Valid values are: \* `inherit`: Inherit the value from the {flag}`--precompile\_source\_retention` flag. \* `keep\_source`: Include the original Python source. \* `omit\_source`: Don't include the original py source. |
@@ -84,13 +84,13 @@ py_test(name, deps, srcs, data, args, compatible_with, deprecation, distribs, en
 | Attributes | |
 | --- | --- |
 | `name` | [Name](/versions/8.4.2/concepts/labels#target-names); required  A unique name for this target. |
-| `deps` | List of [labels](/versions/8.4.2/concepts/labels); default is `[]` List of additional libraries to be linked in to the target. See comments about the [`deps` attribute typically defined by rules](https://bazel.build/reference/be/common-definitions#typical-attributes). These are typically `py\_library` rules. Targets that only provide data files used at runtime belong in the `data` attribute. |
+| `deps` | List of [labels](/versions/8.4.2/concepts/labels); default is `[]` List of additional libraries to be linked in to the target. See comments about the [`deps` attribute typically defined by rules](https://bazel.build/versions/8.4.2/reference/be/common-definitions#typical-attributes). These are typically `py\_library` rules. Targets that only provide data files used at runtime belong in the `data` attribute. |
 | `srcs` | List of [labels](/versions/8.4.2/concepts/labels); required The list of Python source files that are processed to create the target. This includes all your checked-in code and may include generated source files. The `.py` files belong in `srcs` and library targets belong in `deps`. Other binary files that may be needed at run time belong in `data`. |
-| `data` | List of [labels](/versions/8.4.2/concepts/labels); default is `[]` The list of files need by this library at runtime. See comments about the [`data` attribute typically defined by rules](https://bazel.build/reference/be/common-definitions#typical-attributes). There is no `py\_embed\_data` like there is `cc\_embed\_data` and `go\_embed\_data`. This is because Python has a concept of runtime resources. |
+| `data` | List of [labels](/versions/8.4.2/concepts/labels); default is `[]` The list of files need by this library at runtime. See comments about the [`data` attribute typically defined by rules](https://bazel.build/versions/8.4.2/reference/be/common-definitions#typical-attributes). There is no `py\_embed\_data` like there is `cc\_embed\_data` and `go\_embed\_data`. This is because Python has a concept of runtime resources. |
 | `imports` | List of strings; default is `[]` List of import directories to be added to the PYTHONPATH. Subject to "Make variable" substitution. These import directories will be added for this rule and all rules that depend on it (note: not the rules this rule depends on. Each directory will be added to `PYTHONPATH` by `py\_binary` rules that depend on this rule. The strings are repo-runfiles-root relative, Absolute paths (paths that start with `/`) and paths that references a path above the execution root are not allowed and will result in an error. |
 | `legacy_create_init` | Integer; default is `-1` Whether to implicitly create empty `\_\_init\_\_.py` files in the runfiles tree. These are created in every directory containing Python source code or shared libraries, and every parent directory of those directories, excluding the repo root directory. The default, `-1` (auto), means true unless `--incompatible\_default\_to\_explicit\_init\_py` is used. If false, the user is responsible for creating (possibly empty) `\_\_init\_\_.py` files and adding them to the `srcs` of Python targets as required. |
 | `main` | [Label](/versions/8.4.2/concepts/labels); default is `None` Optional; the name of the source file that is the main entry point of the application. This file must also be listed in `srcs`. If left unspecified, `name`, with `.py` appended, is used instead. If `name` does not match any filename in `srcs`, `main` must be specified. |
-| `precompile` | String; default is `"inherit"` Whether py source files \*\*for this target\*\* should be precompiled. Values: \* `inherit`: Allow the downstream binary decide if precompiled files are used. \* `enabled`: Compile Python source files at build time. \* `disabled`: Don't compile Python source files at build time. :::{seealso} \* The {flag}`--precompile` flag, which can override this attribute in some cases and will affect all targets when building. \* The {obj}`pyc\_collection` attribute for transitively enabling precompiling on a per-target basis. \* The [Precompiling](precompiling) docs for a guide about using precompiling. ::: |
+| `precompile` | String; default is `"inherit"` Whether py source files \*\*for this target\*\* should be precompiled. Values: \* `inherit`: Allow the downstream binary decide if precompiled files are used. \* `enabled`: Compile Python source files at build time. \* `disabled`: Don't compile Python source files at build time. :::{seealso} \* The {flag}`--precompile` flag, which can override this attribute in some cases and will affect all targets when building. \* The {obj}`pyc\_collection` attribute for transitively enabling precompiling on a per-target basis. \* The [Precompiling](/versions/8.4.2/reference/be/precompiling) docs for a guide about using precompiling. ::: |
 | `precompile_invalidation_mode` | String; default is `"auto"` How precompiled files should be verified to be up-to-date with their associated source files. Possible values are: \* `auto`: The effective value will be automatically determined by other build settings. \* `checked\_hash`: Use the pyc file if the hash of the source file matches the hash recorded in the pyc file. This is most useful when working with code that you may modify. \* `unchecked\_hash`: Always use the pyc file; don't check the pyc's hash against the source file. This is most useful when the code won't be modified. For more information on pyc invalidation modes, see https://docs.python.org/3/library/py\_compile.html#py\_compile.PycInvalidationMode |
 | `precompile_optimize_level` | Integer; default is `0` The optimization level for precompiled files. For more information about optimization levels, see the `compile()` function's `optimize` arg docs at https://docs.python.org/3/library/functions.html#compile NOTE: The value `-1` means "current interpreter", which will be the interpreter used \_at build time when pycs are generated\_, not the interpreter used at runtime when the code actually runs. |
 | `precompile_source_retention` | String; default is `"inherit"` Determines, when a source file is compiled, if the source file is kept in the resulting output or not. Valid values are: \* `inherit`: Inherit the value from the {flag}`--precompile\_source\_retention` flag. \* `keep\_source`: Include the original Python source. \* `omit\_source`: Don't include the original py source. |
diff --git a/versions/8.4.2/reference/be/workspace.mdx b/versions/8.4.2/reference/be/workspace.mdx
index fb05cfa5..36de1e3c 100644
--- a/versions/8.4.2/reference/be/workspace.mdx
+++ b/versions/8.4.2/reference/be/workspace.mdx
@@ -25,8 +25,7 @@ bind(name, actual, compatible_with, deprecation, distribs, features, licenses, r
 
 *Warning: use of `bind()` is not recommended. See "[Consider removing bind](https://github.com/bazelbuild/bazel/issues/1952)" for a long
 discussion of its issues and alternatives. In particular, consider the use of
-[`repo_mapping`
-repository attributes](https://bazel.build/versions/8.4.2/rules/repository_rules#attributes).*
+[`repo_mapping` repository attributes](https://bazel.build/versions/8.4.2/rules/repository_rules#attributes).*
 
 *Warning: `select()` cannot be used in `bind()`. See the [Configurable Attributes FAQ](/versions/8.4.2/docs/configurable-attributes#bind-select) for
 details.*
@@ -114,8 +113,7 @@ local_repository(name, path, repo_mapping)
 ```
 
 Allows targets from a local directory to be bound. This means that the current repository can
-use targets defined in this other directory. See the [bind
-section](/versions/8.4.2/reference/be/workspace#bind_examples) for more details.
+use targets defined in this other directory. See the [bind section](/versions/8.4.2/reference/be/workspace#bind_examples) for more details.
 
 #### Examples
 
diff --git a/versions/8.4.2/reference/command-line-reference.mdx b/versions/8.4.2/reference/command-line-reference.mdx
index 88ae3557..0e1b29f5 100644
--- a/versions/8.4.2/reference/command-line-reference.mdx
+++ b/versions/8.4.2/reference/command-line-reference.mdx
@@ -511,7 +511,7 @@ This option affects semantics of the Starlark language or the build API accessib
     [`loading_and_analysis`](#effect_tag_LOADING_AND_ANALYSIS), [`experimental`](#metadata_tag_EXPERIMENTAL)
 
 `--[no]experimental_isolated_extension_usages` default: "false"
-:   If true, enables the isolate parameter in the use\_extension function.
+:   If true, enables the isolate parameter in the use\_extension function.
 
     Tags:
     [`loading_and_analysis`](#effect_tag_LOADING_AND_ANALYSIS)
diff --git a/versions/8.4.2/reference/glossary.mdx b/versions/8.4.2/reference/glossary.mdx
index 9732d9f7..128e82c4 100644
--- a/versions/8.4.2/reference/glossary.mdx
+++ b/versions/8.4.2/reference/glossary.mdx
@@ -21,8 +21,7 @@ An in-memory graph of [actions](#action) and the [artifacts](#artifact) that
 these actions read and generate. The graph might include artifacts that exist as
 source files (for example, in the file system) as well as generated
 intermediate/final artifacts that are not mentioned in `BUILD` files. Produced
-during the [analysis phase](#analysis-phase) and used during the [execution
-phase](#execution-phase).
+during the [analysis phase](#analysis-phase) and used during the [execution phase](#execution-phase).
 
 ### Action graph query (aquery) {#action-graph-query}
 A [query](#query-concept) tool that can query over build [actions](#action).
@@ -37,8 +36,7 @@ invalidate individual actions deterministically.
 
 ### Analysis phase {#analysis-phase}
 The second phase of a build. Processes the [target graph](#target-graph)
-specified in [`BUILD` files](#build-file) to produce an in-memory [action
-graph](#action-graph) that determines the order of actions to run during the
+specified in [`BUILD` files](#build-file) to produce an in-memory [action graph](#action-graph) that determines the order of actions to run during the
 [execution phase](#execution-phase). This is the phase in which rule
 implementations are evaluated.
 
@@ -81,8 +79,7 @@ target's source files, dependencies, and custom compiler options. The particular
 attributes available for a given target depend on its rule type.
 
 ### .bazelrc {#bazelrc}
-Bazel’s configuration file used to change the default values for [startup
-flags](#startup-flags) and [command flags](#command-flags), and to define common
+Bazel’s configuration file used to change the default values for [startup flags](#startup-flags) and [command flags](#command-flags), and to define common
 groups of options that can then be set together on the Bazel command line using
 a `--config` flag. Bazel can combine settings from multiple bazelrc files
 (systemwide, per-workspace, per-user, or from a custom location), and a
@@ -108,8 +105,7 @@ directory.
 
 ### .bzl File {#bzl-file}
 A file that defines rules, [macros](#macro), and constants written in
-[Starlark](#starlark). These can then be imported into [`BUILD`
-files](#build-file) using the `load()` function.
+[Starlark](#starlark). These can then be imported into [`BUILD` files](#build-file) using the `load()` function.
 
 {/* TODO: ### Build event protocol */}
 
@@ -117,8 +113,7 @@ files](#build-file) using the `load()` function.
 
 ### Build graph {#build-graph}
 The dependency graph that Bazel constructs and traverses to perform a build.
-Includes nodes like [targets](#target), [configured
-targets](#configured-target), [actions](#action), and [artifacts](#artifact). A
+Includes nodes like [targets](#target), [configured targets](#configured-target), [actions](#action), and [artifacts](#artifact). A
 build is considered complete when all [artifacts](#artifact) on which a set of
 requested targets depend are verified as up-to-date.
 
@@ -158,8 +153,7 @@ graphs and restart the [analysis phase](#analysis-phase).
 ### Configuration {#configuration}
 Information outside of [rule](#rule) definitions that impacts how rules generate
 [actions](#action). Every build has at least one configuration specifying the
-target platform, action environment variables, and command-line [build
-flags](#command-flags). [Transitions](#transition) may create additional
+target platform, action environment variables, and command-line [build flags](#command-flags). [Transitions](#transition) may create additional
 configurations, such as for host tools or cross-compilation.
 
 **See also:** [Configurations](/versions/8.4.2/extending/rules#configurations)
@@ -174,8 +168,7 @@ configuration of `//:c` because changing `--javacopt` unnecessarily breaks C++
 build cacheability.
 
 ### Configured query (cquery) {#configured-query}
-A [query](#query-concept) tool that queries over [configured
-targets](#configured-target) (after the [analysis phase](#analysis-phase)
+A [query](#query-concept) tool that queries over [configured targets](#configured-target) (after the [analysis phase](#analysis-phase)
 completes). This means `select()` and [build flags](#command-flags) (such as
 `--platforms`) are accurately reflected in the results.
 
@@ -191,8 +184,7 @@ build, it has two configured targets: `` and ``.
 ### Correctness {#correctness}
 A build is correct when its output faithfully reflects the state of its
 transitive inputs. To achieve correct builds, Bazel strives to be
-[hermetic](#hermeticity), reproducible, and making [build
-analysis](#analysis-phase) and [action execution](#execution-phase)
+[hermetic](#hermeticity), reproducible, and making [build analysis](#analysis-phase) and [action execution](#execution-phase)
 deterministic.
 
 ### Dependency {#dependency}
@@ -234,8 +226,7 @@ compilation). A dynamic execution strategy can provide the best possible
 incremental and clean build times.
 
 ### Execution phase {#execution-phase}
-The third phase of a build. Executes the [actions](#action) in the [action
-graph](#action-graph) created during the [analysis phase](#analysis-phase).
+The third phase of a build. Executes the [actions](#action) in the [action graph](#action-graph) created during the [analysis phase](#analysis-phase).
 These actions invoke executables (compilers, scripts) to read and write
 [artifacts](#artifact). *Spawn strategies* control how these actions are
 executed: locally, remotely, dynamically, sandboxed, docker, and so on.
@@ -285,8 +276,7 @@ syntax may be omitted.
 The first phase of a build where Bazel executes [`BUILD` files](#build-file) to
 create [packages](#package). [Macros](#macro) and certain functions like
 `glob()` are evaluated in this phase. Interleaved with the second phase of the
-build, the [analysis phase](#analysis-phase), to build up a [target
-graph](#target-graph).
+build, the [analysis phase](#analysis-phase), to build up a [target graph](#target-graph).
 
 ### Legacy macro {#legacy-macro}
 A flavor of [macro](#macro) which is declared as an ordinary
@@ -336,8 +326,7 @@ Module metadata is hosted in Bazel registries.
 
 ### Module Extension {#module-extension}
 A piece of logic that can be run to generate [repos](#repository) by reading
-inputs from across the [module](#module) dependency graph and invoking [repo
-rules](#repository-rule). Module extensions have capabilities similar to repo
+inputs from across the [module](#module) dependency graph and invoking [repo rules](#repository-rule). Module extensions have capabilities similar to repo
 rules, allowing them to access the internet, perform file I/O, and so on.
 
 **See also:** [Module extensions](/versions/8.4.2/external/extension)
@@ -350,8 +339,7 @@ example, `native.cc_library` or `native.java_library`). User-defined rules
 
 ### Output base {#output-base}
 A [workspace](#workspace)-specific directory to store Bazel output files. Used
-to separate outputs from the *workspace*'s source tree (the [main
-repo](#repository)). Located in the [output user root](#output-user-root).
+to separate outputs from the *workspace*'s source tree (the [main repo](#repository)). Located in the [output user root](#output-user-root).
 
 ### Output groups {#output-groups}
 A group of files that is expected to be built when Bazel finishes building a
@@ -406,8 +394,7 @@ query variants: [query](#query-command), [cquery](#configured-query), and
 [aquery](#action-graph-query).
 
 ### query (command) {#query-command}
-A [query](#query-concept) tool that operates over the build's post-[loading
-phase](#loading-phase) [target graph](#target-graph). This is relatively fast,
+A [query](#query-concept) tool that operates over the build's post-[loading phase](#loading-phase) [target graph](#target-graph). This is relatively fast,
 but can't analyze the effects of `select()`, [build flags](#command-flags),
 [artifacts](#artifact), or build [actions](#action).
 
@@ -425,8 +412,7 @@ repo; multiple such files can coexist in a directory.
 The *main repo* is the repo in which the current Bazel command is being run.
 
 *External repos* are defined by specifying [modules](#module) in `MODULE.bazel`
-files, or invoking [repo rules](#repository-rule) in [module
-extensions](#module-extension). They can be fetched on demand to a predetermined
+files, or invoking [repo rules](#repository-rule) in [module extensions](#module-extension). They can be fetched on demand to a predetermined
 "magical" location on disk.
 
 Each repo has a unique, constant *canonical* name, and potentially different
@@ -437,8 +423,7 @@ Each repo has a unique, constant *canonical* name, and potentially different
 ### Repository cache {#repo-cache}
 A shared content-addressable cache of files downloaded by Bazel for builds,
 shareable across [workspaces](#workspace). Enables offline builds after the
-initial download. Commonly used to cache files downloaded through [repository
-rules](#repository-rule) like `http_archive` and repository rule APIs like
+initial download. Commonly used to cache files downloaded through [repository rules](#repository-rule) like `http_archive` and repository rule APIs like
 `repository_ctx.download`. Files are cached only if their SHA-256 checksums are
 specified for the download.
 
@@ -472,8 +457,7 @@ Rules are instantiated to produce rule targets in the
 [loading phase](#loading-phase). In the [analysis phase](#analysis-phase) rule
 targets communicate information to their downstream dependencies in the form of
 [providers](#provider), and register [actions](#action) describing how to
-generate their output artifacts. These actions are run in the [execution
-phase](#execution-phase).
+generate their output artifacts. These actions are run in the [execution phase](#execution-phase).
 
 Note: Historically the term "rule" has been used to refer to a rule target.
 This usage was inherited from tools like Make, but causes confusion and should
@@ -517,8 +501,7 @@ support the stamp attribute.
 ### Starlark {#starlark}
 The extension language for writing [rules](/versions/8.4.2/extending/rules) and [macros](#macro). A
 restricted subset of Python (syntactically and grammatically) aimed for the
-purpose of configuration, and for better performance. Uses the [`.bzl`
-file](#bzl-file) extension. [`BUILD` files](#build-file) use an even more
+purpose of configuration, and for better performance. Uses the [`.bzl` file](#bzl-file) extension. [`BUILD` files](#build-file) use an even more
 restricted version of Starlark (such as no `def` function definitions), formerly
 known as Skylark.
 
@@ -549,8 +532,7 @@ An object that is defined in a [`BUILD` file](#build-file) and identified by a
 [label](#label). Targets represent the buildable units of a workspace from
 the perspective of the end user.
 
-A target that is declared by instantiating a [rule](#rule) is called a [rule
-target](#rule-target). Depending on the rule, these may be runnable (like
+A target that is declared by instantiating a [rule](#rule) is called a [rule target](#rule-target). Depending on the rule, these may be runnable (like
 `cc_binary`) or testable (like `cc_test`). Rule targets typically depend on
 other targets via their [attributes](#attribute) (such as `deps`); these
 dependencies form the basis of the [target graph](#target-graph).
@@ -561,14 +543,11 @@ within a `BUILD` file. As a special case, the `BUILD` file of any package is
 always considered a source file target in that package.
 
 Targets are discovered during the [loading phase](#loading-phase). During the
-[analysis phase](#analysis-phase), targets are associated with [build
-configurations](#configuration) to form [configured
-targets](#configured-target).
+[analysis phase](#analysis-phase), targets are associated with [build configurations](#configuration) to form [configured targets](#configured-target).
 
 ### Target graph {#target-graph}
 An in-memory graph of [targets](#target) and their dependencies. Produced during
-the [loading phase](#loading-phase) and used as an input to the [analysis
-phase](#analysis-phase).
+the [loading phase](#loading-phase) and used as an input to the [analysis phase](#analysis-phase).
 
 ### Target pattern {#target-pattern}
 A way to specify a group of [targets](#target) on the command line. Commonly
@@ -581,8 +560,7 @@ packages recursively from the root of the [workspace](#workspace).
 Rule [targets](#target) instantiated from test rules, and therefore contains a
 test executable. A return code of zero from the completion of the executable
 indicates test success. The exact contract between Bazel and tests (such as test
-environment variables, test result collection methods) is specified in the [Test
-Encyclopedia](/versions/8.4.2/reference/test-encyclopedia).
+environment variables, test result collection methods) is specified in the [Test Encyclopedia](/versions/8.4.2/reference/test-encyclopedia).
 
 ### Toolchain {#toolchain}
 A set of tools to build outputs for a language. Typically, a toolchain includes
@@ -596,8 +574,7 @@ A build [target](#target) is top-level if it’s requested on the Bazel command
 line. For example, if `//:foo` depends on `//:bar`, and `bazel build //:foo` is
 called, then for this build, `//:foo` is top-level, and `//:bar` isn’t
 top-level, although both targets will need to be built. An important difference
-between top-level and non-top-level targets is that [command
-flags](#command-flags) set on the Bazel command line (or via
+between top-level and non-top-level targets is that [command flags](#command-flags) set on the Bazel command line (or via
 [.bazelrc](#bazelrc)) will set the [configuration](#configuration) for top-level
 targets, but might be modified by a [transition](#transition) for non-top-level
 targets.
@@ -628,8 +605,7 @@ or `.bzl` file may load a given `.bzl` file. Without context, usually
 **See also:** [Visibility documentation](/versions/8.4.2/concepts/visibility)
 
 ### Workspace {#workspace}
-The environment shared by all Bazel commands run from the same [main
-repository](#repository).
+The environment shared by all Bazel commands run from the same [main repository](#repository).
 
 Note that historically the concepts of "repository" and "workspace" have been
 conflated; the term "workspace" has often been used to refer to the main
diff --git a/versions/8.4.2/release/backward-compatibility.mdx b/versions/8.4.2/release/backward-compatibility.mdx
index fad4582e..f71bcc21 100644
--- a/versions/8.4.2/release/backward-compatibility.mdx
+++ b/versions/8.4.2/release/backward-compatibility.mdx
@@ -6,11 +6,9 @@ This page provides information about how to handle backward compatibility,
 including migrating from one release to another and how to communicate
 incompatible changes.
 
-Bazel is evolving. Minor versions released as part of an [LTS major
-version](/versions/8.4.2/release#bazel-versioning) are fully backward-compatible. New major LTS
+Bazel is evolving. Minor versions released as part of an [LTS major version](/versions/8.4.2/release#bazel-versioning) are fully backward-compatible. New major LTS
 releases may contain incompatible changes that require some migration effort.
-For more information about Bazel's release model, please check out the [Release
-Model](/versions/8.4.2/release) page.
+For more information about Bazel's release model, please check out the [Release Model](/versions/8.4.2/release) page.
 
 ## Summary {#summary}
 
@@ -59,8 +57,7 @@ available.
 ## Communicating incompatible changes {#communicating-incompatible-changes}
 
 The primary source of information about incompatible changes are GitHub issues
-marked with an ["incompatible-change"
-label](https://github.com/bazelbuild/bazel/issues?q=label%3Aincompatible-change).
+marked with an ["incompatible-change" label](https://github.com/bazelbuild/bazel/issues?q=label%3Aincompatible-change).
 
 For every incompatible change, the issue specifies the following:
 
diff --git a/versions/8.4.2/release/index.mdx b/versions/8.4.2/release/index.mdx
index a7a37681..0c00fd8e 100644
--- a/versions/8.4.2/release/index.mdx
+++ b/versions/8.4.2/release/index.mdx
@@ -2,8 +2,7 @@
 title: 'Release Model'
 ---
 
-As announced in [the original blog
-post](https://blog.bazel.build/2020/11/10/long-term-support-release.html), Bazel
+As announced in [the original blog post](https://blog.bazel.build/2020/11/10/long-term-support-release.html), Bazel
 4.0 and higher versions provides support for two release tracks: rolling
 releases and long term support (LTS) releases. This page covers the latest
 information about Bazel's release model.
@@ -19,8 +18,7 @@ information about Bazel's release model.
 | Bazel 5 | Maintenance | [5.4.1](https://github.com/bazelbuild/bazel/releases/tag/5.4.1) | Jan 2025 |
 | Bazel 4 | Deprecated | [4.2.4](https://github.com/bazelbuild/bazel/releases/tag/4.2.4) | Jan 2024 |
 
-All Bazel LTS releases can be found on the [release
-page](https://github.com/bazelbuild/bazel/releases) on GitHub.
+All Bazel LTS releases can be found on the [release page](https://github.com/bazelbuild/bazel/releases) on GitHub.
 
 Note: Bazel version older than Bazel 5 are no longer supported, Bazel users are
 recommended to upgrade to the latest LTS release or use rolling releases if you
@@ -28,8 +26,7 @@ want to keep up with the latest changes at HEAD.
 
 ## Release versioning {#bazel-versioning}
 
-Bazel uses a _major.minor.patch_ [Semantic
-Versioning](https://semver.org/) scheme.
+Bazel uses a _major.minor.patch_ [Semantic Versioning](https://semver.org/) scheme.
 
 *   A _major release_ contains features that are not backward compatible with
     the previous release. Each major Bazel version is an LTS release.
@@ -72,8 +69,7 @@ Bazel regularly publish releases for two release tracks.
     release.
 *   Rolling releases can ship incompatible changes. Incompatible flags are
     recommended for major breaking changes, rolling out incompatible changes
-    should follow our [backward compatibility
-    policy](/versions/8.4.2/release/backward-compatibility).
+    should follow our [backward compatibility policy](/versions/8.4.2/release/backward-compatibility).
 
 ### LTS releases {#lts-releases}
 
@@ -89,8 +85,7 @@ Bazel regularly publish releases for two release tracks.
 *   A Bazel LTS release enters the Deprecated stage after being in ​​the
     Maintenance stage for 2 years.
 
-For planned releases, please check our [release
-issues](https://github.com/bazelbuild/bazel/issues?q=is%3Aopen+is%3Aissue+label%3Arelease)
+For planned releases, please check our [release issues](https://github.com/bazelbuild/bazel/issues?q=is%3Aopen+is%3Aissue+label%3Arelease)
 on Github.
 
 ## Release procedure & policies {#release-procedure-policies}
@@ -153,8 +148,7 @@ For LTS releases, the procedure and policies below are followed:
 1.  Identify release blockers and fix issues found on the release branch.
     *   The release branch is tested with the same test suite in
         [postsubmit](https://buildkite.com/bazel/bazel-bazel) and
-        [downstream test pipeline]
-        (https://buildkite.com/bazel/bazel-at-head-plus-downstream)
+        [downstream test pipeline](https://buildkite.com/bazel/bazel-at-head-plus-downstream)
         on Bazel CI. The Bazel team monitors testing results of the release
         branch and fixes any regressions found.
 1.  Create a new release candidate from the release branch when all known
@@ -210,5 +204,4 @@ feature.
 ## Rule compatibility {#rule-compatibility}
 
 If you are a rule authors and want to maintain compatibility with different
-Bazel versions, please check out the [Rule
-Compatibility](/versions/8.4.2/release/rule-compatibility) page.
+Bazel versions, please check out the [Rule Compatibility](/versions/8.4.2/release/rule-compatibility) page.
diff --git a/versions/8.4.2/release/rule-compatibility.mdx b/versions/8.4.2/release/rule-compatibility.mdx
index 17c88b35..729a62e5 100644
--- a/versions/8.4.2/release/rule-compatibility.mdx
+++ b/versions/8.4.2/release/rule-compatibility.mdx
@@ -53,18 +53,15 @@ Bazel LTS release.
 As Bazel rules authors, you can ensure a manageable migration process for users
 by following these best practices:
 
-1.  The rule should follow [Semantic
-    Versioning](https://semver.org/): minor versions of the same
+1.  The rule should follow [Semantic Versioning](https://semver.org/): minor versions of the same
     major version are backward compatible.
 1.  The rule at HEAD should be compatible with the latest Bazel LTS release.
 1.  The rule at HEAD should be compatible with Bazel at HEAD. To achieve this,
     you can
     *   Set up your own CI testing with Bazel at HEAD
-    *   Add your project to [Bazel downstream
-        testing](https://github.com/bazelbuild/continuous-integration/blob/master/docs/downstream-testing.md);
+    *   Add your project to [Bazel downstream testing](https://github.com/bazelbuild/continuous-integration/blob/master/docs/downstream-testing.md);
         the Bazel team files issues to your project if breaking changes in Bazel
-        affect your project, and you must follow our [downstream project
-        policies](https://github.com/bazelbuild/continuous-integration/blob/master/docs/downstream-testing.md#downstream-project-policies)
+        affect your project, and you must follow our [downstream project policies](https://github.com/bazelbuild/continuous-integration/blob/master/docs/downstream-testing.md#downstream-project-policies)
         to address issues timely.
 1.  The latest major version of the rule must be compatible with the latest
     Bazel LTS release.
diff --git a/versions/8.4.2/remote/bep-glossary.mdx b/versions/8.4.2/remote/bep-glossary.mdx
index 6916cd3c..458a258a 100644
--- a/versions/8.4.2/remote/bep-glossary.mdx
+++ b/versions/8.4.2/remote/bep-glossary.mdx
@@ -36,7 +36,7 @@ BEP contains an event like the following:
 ## ActionExecuted {#actionexecuted}
 
 Provides details about the execution of a specific
-[Action](/versions/8.4.2/rules/lib/actions) in a build. By default, this event is
+[Action](/versions/8.4.2/rules/lib/builtins/actions) in a build. By default, this event is
 included in the BEP only for failed actions, to support identifying the root cause
 of build failures. Users may set the `--build_event_publish_all_actions` flag
 to include all `ActionExecuted` events.
@@ -410,5 +410,4 @@ workspace, such as the execution root.
 
 ## WorkspaceStatus {#workspacestatus}
 
-A single `WorkspaceStatus` event contains the result of the [workspace status
-command](/versions/8.4.2/docs/user-manual#workspace-status).
+A single `WorkspaceStatus` event contains the result of the [workspace status command](/versions/8.4.2/docs/user-manual#workspace-status).
diff --git a/versions/8.4.2/remote/bep.mdx b/versions/8.4.2/remote/bep.mdx
index 3485b928..9adb8cd9 100644
--- a/versions/8.4.2/remote/bep.mdx
+++ b/versions/8.4.2/remote/bep.mdx
@@ -2,14 +2,12 @@
 title: 'Build Event Protocol'
 ---
 
-The [Build Event
-Protocol](https://github.com/bazelbuild/bazel/blob/master/src/main/java/com/google/devtools/build/lib/buildeventstream/proto/build_event_stream.proto)
+The [Build Event Protocol](https://github.com/bazelbuild/bazel/blob/master/src/main/java/com/google/devtools/build/lib/buildeventstream/proto/build_event_stream.proto)
 (BEP) allows third-party programs to gain insight into a Bazel invocation. For
 example, you could use the BEP to gather information for an IDE
 plugin or a dashboard that displays build results.
 
-The protocol is a set of [protocol
-buffer](https://developers.google.com/protocol-buffers/) messages with some
+The protocol is a set of [protocol buffer](https://developers.google.com/protocol-buffers/) messages with some
 semantics defined on top of it. It includes information about build and test
 results, build progress, the build configuration and much more. The BEP is
 intended to be consumed programmatically and makes parsing Bazel’s
@@ -20,16 +18,13 @@ build event is a protocol buffer message consisting of a build event identifier,
 a set of child event identifiers, and a payload.
 
 *  __Build Event Identifier:__ Depending on the kind of build event, it might be
-an [opaque
-string](https://github.com/bazelbuild/bazel/blob/7.1.0/src/main/java/com/google/devtools/build/lib/buildeventstream/proto/build_event_stream.proto#L131-L140)
-or [structured
-information](https://github.com/bazelbuild/bazel/blob/7.1.0/src/main/java/com/google/devtools/build/lib/buildeventstream/proto/build_event_stream.proto#L194-L205)
+an [opaque string](https://github.com/bazelbuild/bazel/blob/7.1.0/src/main/java/com/google/devtools/build/lib/buildeventstream/proto/build_event_stream.proto#L131-L140)
+or [structured information](https://github.com/bazelbuild/bazel/blob/7.1.0/src/main/java/com/google/devtools/build/lib/buildeventstream/proto/build_event_stream.proto#L194-L205)
 revealing more about the build event. A build event identifier is unique within
 a build.
 
 *  __Children:__ A build event may announce other build events, by including
-their build event identifiers in its [children
-field](https://github.com/bazelbuild/bazel/blob/7.1.0/src/main/java/com/google/devtools/build/lib/buildeventstream/proto/build_event_stream.proto#L1276).
+their build event identifiers in its [children field](https://github.com/bazelbuild/bazel/blob/7.1.0/src/main/java/com/google/devtools/build/lib/buildeventstream/proto/build_event_stream.proto#L1276).
 For example, the `PatternExpanded` build event announces the targets it expands
 to as children. The protocol guarantees that all events, except for the first
 event, are announced by a previous event.
@@ -91,8 +86,7 @@ human-readable formats, such as text and JSON:
 
 ## Build Event Service {#build-event-service}
 
-The [Build Event
-Service](https://github.com/googleapis/googleapis/blob/master/google/devtools/build/v1/publish_build_event.proto)
+The [Build Event Service](https://github.com/googleapis/googleapis/blob/master/google/devtools/build/v1/publish_build_event.proto)
 Protocol is a generic [gRPC](https://www.grpc.io) service for publishing build events. The Build Event
 Service protocol is independent of the BEP and treats BEP events as opaque bytes.
 Bazel ships with a gRPC client implementation of the Build Event Service protocol that
@@ -136,8 +130,7 @@ For a description of each of these flags, see the
 The BEP typically contains many references to log files (test.log, test.xml,
 etc. ) stored on the machine where Bazel is running. A remote BES server
 typically can't access these files as they are on different machines. A way to
-work around this issue is to use Bazel with [remote
-caching](/versions/8.4.2/remote/caching).
+work around this issue is to use Bazel with [remote caching](/versions/8.4.2/remote/caching).
 Bazel will upload all output files to the remote cache (including files
 referenced in the BEP) and the BES server can then fetch the referenced files
 from the cache.
diff --git a/versions/8.4.2/remote/cache-local.mdx b/versions/8.4.2/remote/cache-local.mdx
index 5df18a90..dc6918ff 100644
--- a/versions/8.4.2/remote/cache-local.mdx
+++ b/versions/8.4.2/remote/cache-local.mdx
@@ -18,8 +18,7 @@ execution. However, local execution presents some additional challenges.
 ## Checking your cache hit rate {#cache-hits}
 
 Successful remote cache hits will show up in the status line, similar to
-[Cache Hits rate with Remote
-Execution](/versions/8.4.2/remote/cache-remote#check-cache-hits).
+[Cache Hits rate with Remote Execution](/versions/8.4.2/remote/cache-remote#check-cache-hits).
 
 In the standard output of your Bazel run, you will see something like the
 following:
@@ -66,8 +65,7 @@ the steps in this section.
    message you see does not give you enough information, try adding
    `--verbose_failures`.
 
-2. Follow the steps from [Troubleshooting cache hits for remote
-   execution](/versions/8.4.2/remote/cache-remote#troubleshooting_cache_hits) to
+2. Follow the steps from [Troubleshooting cache hits for remote execution](/versions/8.4.2/remote/cache-remote#troubleshooting_cache_hits) to
    ensure that your cache-writing Bazel invocations are able to get cache hits
    on the same machine and across machines.
 
@@ -81,7 +79,6 @@ the steps in this section.
    b. Ensure your cache-reading Bazel invocations build the same targets as the
       cache-writing Bazel invocations.
 
-   c. Follow the same steps as to [ensure caching across
-      machines](/versions/8.4.2/remote/cache-remote#caching-across-machines),
+   c. Follow the same steps as to [ensure caching across machines](/versions/8.4.2/remote/cache-remote#caching-across-machines),
       to ensure caching from your cache-writing Bazel invocation to your
       cache-reading Bazel invocation.
diff --git a/versions/8.4.2/remote/caching.mdx b/versions/8.4.2/remote/caching.mdx
index 5b85e31d..c9f1f4c7 100644
--- a/versions/8.4.2/remote/caching.mdx
+++ b/versions/8.4.2/remote/caching.mdx
@@ -126,7 +126,7 @@ not provide technical support for bazel-remote.
 
 This cache stores contents on disk and also provides garbage collection
 to enforce an upper storage limit and clean unused artifacts. The cache is
-available as a [docker image] and its code is available on
+available as a [docker image](https://hub.docker.com/r/buchgr/bazel-remote-cache/) and its code is available on
 [GitHub](https://github.com/buchgr/bazel-remote/).
 Both the REST and gRPC remote cache APIs are supported.
 
@@ -308,8 +308,7 @@ or for the age of individual cache entries. Bazel will automatically garbage
 collect the disk cache while idling between builds; the idle timer can be set
 with `--experimental_disk_cache_gc_idle_delay` (defaulting to 5 minutes).
 
-As an alternative to automatic garbage collection, we also provide a [tool](
-https://github.com/bazelbuild/bazel/tree/master/src/tools/diskcache) to run a
+As an alternative to automatic garbage collection, we also provide a [tool](https://github.com/bazelbuild/bazel/tree/master/src/tools/diskcache) to run a
 garbage collection on demand.
 
 ## Known issues {#known-issues}
diff --git a/versions/8.4.2/remote/dynamic.mdx b/versions/8.4.2/remote/dynamic.mdx
index dec854f7..b2ab6ca6 100644
--- a/versions/8.4.2/remote/dynamic.mdx
+++ b/versions/8.4.2/remote/dynamic.mdx
@@ -12,8 +12,7 @@ alike.
 This page describes how to enable, tune, and debug dynamic execution. If you
 have both local and remote execution set up and are trying to adjust Bazel
 settings for better performance, this page is for you. If you don't already have
-remote execution set up, go to the Bazel [Remote Execution
-Overview](/versions/8.4.2/remote/rbe) first.
+remote execution set up, go to the Bazel [Remote Execution Overview](/versions/8.4.2/remote/rbe) first.
 
 ## Enabling dynamic execution? {#enabling-dynamic-execution}
 
@@ -44,14 +43,12 @@ are likely. The default value is 1000ms, but should be tuned to being just a bit
 longer than cache hits usually take. The actual time depends both on the remote
 system and on how long a round-trip takes. Usually, the value will be the same
 for all users of a given remote system, unless some of them are far enough away
-to add roundtrip latency. You can use the [Bazel profiling
-features](/versions/8.4.2/rules/performance#performance-profiling) to look at how long typical
+to add roundtrip latency. You can use the [Bazel profiling features](/versions/8.4.2/rules/performance#performance-profiling) to look at how long typical
 cache hits take.
 
 Dynamic execution can be used with local sandboxed strategy as well as with
 [persistent workers](/versions/8.4.2/remote/persistent). Persistent workers will automatically
-run with sandboxing when used with dynamic execution, and cannot use [multiplex
-workers](/versions/8.4.2/remote/multiplex). On Darwin and Windows systems, the sandboxed
+run with sandboxing when used with dynamic execution, and cannot use [multiplex workers](/versions/8.4.2/remote/multiplex). On Darwin and Windows systems, the sandboxed
 strategy can be slow; you can pass `--reuse_sandbox_directories` to reduce
 overhead of creating sandboxes on these systems.
 
@@ -67,8 +64,7 @@ entire action fails. This is an intentional choice to prevent differences
 between local and remote execution from going unnoticed.
 
 For more background on how dynamic execution and its locking works, see Julio
-Merino's excellent [blog
-posts](https://jmmv.dev/series/bazel-dynamic-execution/)
+Merino's excellent [blog posts](https://jmmv.dev/series/bazel-dynamic-execution/)
 
 ## When should I use dynamic execution? {#when-to-use}
 
diff --git a/versions/8.4.2/remote/output-directories.mdx b/versions/8.4.2/remote/output-directories.mdx
index b5420cbc..ce020687 100644
--- a/versions/8.4.2/remote/output-directories.mdx
+++ b/versions/8.4.2/remote/output-directories.mdx
@@ -25,7 +25,7 @@ The solution that's currently implemented:
 
 * Bazel must be invoked from a directory containing a repo boundary file, or a
   subdirectory thereof. In other words, Bazel must be invoked from inside a
-  [repository](../external/overview#repository). Otherwise, an error is
+  [repository](/versions/8.4.2/external/overview#repository). Otherwise, an error is
   reported.
 * The _outputRoot_ directory defaults to `~/.cache/bazel` on Linux,
   `/private/var/tmp` on macOS, and on Windows it defaults to `%HOME%` if
diff --git a/versions/8.4.2/remote/persistent.mdx b/versions/8.4.2/remote/persistent.mdx
index 76baeaa6..ebc9678f 100644
--- a/versions/8.4.2/remote/persistent.mdx
+++ b/versions/8.4.2/remote/persistent.mdx
@@ -257,7 +257,6 @@ For more information on persistent workers, see:
 *   [Original persistent workers blog post](https://blog.bazel.build/2015/12/10/java-workers.html)
 *   [Haskell implementation description](https://www.tweag.io/blog/2019-09-25-bazel-ghc-persistent-worker-internship/)
 *   [Blog post by Mike Morearty](https://medium.com/@mmorearty/how-to-create-a-persistent-worker-for-bazel-7738bba2cabb)
-*   [Front End Development with Bazel: Angular/TypeScript and Persistent Workers
-    w/ Asana](https://www.youtube.com/watch?v=0pgERydGyqo)
+*   [Front End Development with Bazel: Angular/TypeScript and Persistent Workers w/ Asana](https://www.youtube.com/watch?v=0pgERydGyqo)
 *   [Bazel strategies explained](https://jmmv.dev/2019/12/bazel-strategies.html)
 *   [Informative worker strategy discussion on the bazel-discuss mailing list](https://groups.google.com/forum/#!msg/bazel-discuss/oAEnuhYOPm8/ol7hf4KWJgAJ)
diff --git a/versions/8.4.2/remote/rules.mdx b/versions/8.4.2/remote/rules.mdx
index 528a9f28..9dfb8d81 100644
--- a/versions/8.4.2/remote/rules.mdx
+++ b/versions/8.4.2/remote/rules.mdx
@@ -54,8 +54,7 @@ variables that may not be set to equivalent values (or at all) in the remote
 execution environment.
 
 Toolchain rules currently exist for Bazel build and test rules for
-[Scala](https://github.com/bazelbuild/rules_scala/blob/master/scala/scala_toolch
-ain.bzl),
+[Scala](https://github.com/bazelbuild/rules_scala/blob/master/scala/scala_toolch ain.bzl),
 [Rust](https://github.com/bazelbuild/rules_rust/blob/main/rust/toolchain.bzl),
 and [Go](https://github.com/bazelbuild/rules_go/blob/master/go/toolchains.rst),
 and new toolchain rules are under way for other languages and tools such as
diff --git a/versions/8.4.2/remote/workspace.mdx b/versions/8.4.2/remote/workspace.mdx
index f79779af..cf904c3a 100644
--- a/versions/8.4.2/remote/workspace.mdx
+++ b/versions/8.4.2/remote/workspace.mdx
@@ -11,8 +11,7 @@ on the host machine. If your workspace rules access information about the
 host machine for use during execution, your build is likely to break due to
 incompatibilities between the environments.
 
-As part of [adapting Bazel rules for remote
-execution](/versions/8.4.2/remote/rules), you need to find such workspace rules
+As part of [adapting Bazel rules for remote execution](/versions/8.4.2/remote/rules), you need to find such workspace rules
 and fix them. This page describes how to find potentially problematic workspace
 rules using the workspace log.
 
diff --git a/versions/8.4.2/rules/challenges.mdx b/versions/8.4.2/rules/challenges.mdx
index 8cff1b1a..029e4950 100644
--- a/versions/8.4.2/rules/challenges.mdx
+++ b/versions/8.4.2/rules/challenges.mdx
@@ -208,7 +208,7 @@ Bazel is heavily affected by both of these scenarios, so we introduced a set of
 custom collection classes that effectively compress the information in memory by
 avoiding the copy at each step. Almost all of these data structures have set
 semantics, so we called it
-[depset](/versions/8.4.2/rules/lib/depset)
+[depset](/versions/8.4.2/rules/lib/builtins/depset)
 (also known as `NestedSet` in the internal implementation). The majority of
 changes to reduce Bazel's memory consumption over the past several years were
 changes to use depsets instead of whatever was previously used.
diff --git a/versions/8.4.2/rules/faq.mdx b/versions/8.4.2/rules/faq.mdx
index d01907f8..c1fa82ed 100644
--- a/versions/8.4.2/rules/faq.mdx
+++ b/versions/8.4.2/rules/faq.mdx
@@ -17,7 +17,7 @@ Bazel only executes the actions needed to produce the *requested* output files.
 
 * If you want the file to be built automatically whenever your target is
   mentioned on the command line, add it to your rule's default outputs by
-  returning a [`DefaultInfo`](lib/globals#DefaultInfo) provider.
+  returning a [`DefaultInfo`](/versions/8.4.2/rules/lib/globals#DefaultInfo) provider.
 
 See the [Rules page](/versions/8.4.2/extending/rules#requesting-output-files) for more information.
 
@@ -35,24 +35,24 @@ correct path.
 
 For actions, you declare inputs by passing them to the `ctx.actions.*` function
 that creates the action. The proper path for the file can be obtained using
-[`File.path`](lib/File#path).
+[`File.path`](/versions/8.4.2/rules/lib/builtins/File#path).
 
 For binaries (the executable outputs run by a `bazel run` or `bazel test`
 command), you declare inputs by including them in the
 [runfiles](/versions/8.4.2/extending/rules#runfiles). Instead of using the `path` field, use
-[`File.short_path`](lib/File#short_path), which is file's path relative to
+[`File.short_path`](/versions/8.4.2/rules/lib/builtins/File#short_path), which is file's path relative to
 the runfiles directory in which the binary executes.
 
 ## How can I control which files are built by `bazel build //pkg:mytarget`?
 
-Use the [`DefaultInfo`](lib/globals#DefaultInfo) provider to
+Use the [`DefaultInfo`](/versions/8.4.2/rules/lib/globals#DefaultInfo) provider to
 [set the default outputs](/versions/8.4.2/extending/rules#requesting-output-files).
 
 ## How can I run a program or do file I/O as part of my build?
 
 A tool can be declared as a target, just like any other part of your build, and
 run during the execution phase to help build other targets. To create an action
-that runs a tool, use [`ctx.actions.run`](lib/actions#run) and pass in the
+that runs a tool, use [`ctx.actions.run`](/versions/8.4.2/rules/lib/builtins/actions#run) and pass in the
 tool as the `executable` parameter.
 
 During the loading and analysis phases, a tool *cannot* run, nor can you perform
diff --git a/versions/8.4.2/rules/language.mdx b/versions/8.4.2/rules/language.mdx
index e2a953af..34678ed9 100644
--- a/versions/8.4.2/rules/language.mdx
+++ b/versions/8.4.2/rules/language.mdx
@@ -34,19 +34,19 @@ Starlark's semantics can differ from Python, but behavioral differences are
 rare, except for cases where Starlark raises an error. The following Python
 types are supported:
 
-* [None](lib/globals#None)
-* [bool](lib/bool)
-* [dict](lib/dict)
-* [tuple](lib/tuple)
-* [function](lib/function)
-* [int](lib/int)
-* [list](lib/list)
-* [string](lib/string)
+* [None](/versions/8.4.2/rules/lib/globals#None)
+* [bool](/versions/8.4.2/rules/lib/core/bool)
+* [dict](/versions/8.4.2/rules/lib/core/dict)
+* [tuple](/versions/8.4.2/rules/lib/core/tuple)
+* [function](/versions/8.4.2/rules/lib/core/function)
+* [int](/versions/8.4.2/rules/lib/core/int)
+* [list](/versions/8.4.2/rules/lib/core/list)
+* [string](/versions/8.4.2/rules/lib/core/string)
 
 ## Mutability
 
 Starlark favors immutability. Two mutable data structures are available:
-[lists](lib/list) and [dicts](lib/dict). Changes to mutable
+[lists](/versions/8.4.2/rules/lib/core/list) and [dicts](/versions/8.4.2/rules/lib/core/dict). Changes to mutable
 data-structures, such as appending a value to a list or deleting an entry in a
 dictionary are valid only for objects created in the current context. After a
 context finishes, its values become immutable.
@@ -93,10 +93,8 @@ values returned by rules are immutable.
 `BUILD` files register targets via making calls to rules. `.bzl` files provide
 definitions for constants, rules, macros, and functions.
 
-[Native functions](/versions/8.4.2/reference/be/functions) and [native rules](
-/reference/be/overview#language-specific-native-rules) are global symbols in
-`BUILD` files. `bzl` files need to load them using the [`native` module](
-/rules/lib/toplevel/native).
+[Native functions](/versions/8.4.2/reference/be/functions) and [native rules](/versions/8.4.2/reference/be/overview#language-specific-native-rules) are global symbols in
+`BUILD` files. `bzl` files need to load them using the [`native` module](/versions/8.4.2/rules/lib/toplevel/native).
 
 There are two syntactic restrictions in `BUILD` files: 1) declaring functions is
 illegal, and 2) `*args` and `**kwargs` arguments are not allowed.
@@ -130,7 +128,7 @@ not defined across value types. In short: `5 < 'foo'` will throw an error and
   error: `{"a": 4, "b": 7, "a": 1}`.
 
 * Strings are represented with double-quotes (such as when you call
-  [repr](lib/globals#repr)).
+  [repr](/versions/8.4.2/rules/lib/globals#repr)).
 
 * Strings aren't iterable.
 
@@ -138,12 +136,12 @@ The following Python features are not supported:
 
 * implicit string concatenation (use explicit `+` operator).
 * Chained comparisons (such as `1 < x < 5`).
-* `class` (see [`struct`](lib/struct#struct) function).
+* `class` (see [`struct`](/versions/8.4.2/rules/lib/builtins/struct#struct) function).
 * `import` (see [`load`](/versions/8.4.2/extending/concepts#loading-an-extension) statement).
 * `while`, `yield`.
 * float and set types.
 * generators and generator expressions.
 * `is` (use `==` instead).
-* `try`, `raise`, `except`, `finally` (see [`fail`](lib/globals#fail) for fatal errors).
+* `try`, `raise`, `except`, `finally` (see [`fail`](/versions/8.4.2/rules/lib/globals#fail) for fatal errors).
 * `global`, `nonlocal`.
 * most builtin functions, most methods.
diff --git a/versions/8.4.2/rules/legacy-macro-tutorial.mdx b/versions/8.4.2/rules/legacy-macro-tutorial.mdx
index 87120c6d..9f5185d7 100644
--- a/versions/8.4.2/rules/legacy-macro-tutorial.mdx
+++ b/versions/8.4.2/rules/legacy-macro-tutorial.mdx
@@ -3,9 +3,7 @@ title: 'Creating a Legacy Macro'
 ---
 
 IMPORTANT: This tutorial is for [*legacy macros*](/versions/8.4.2/extending/legacy-macros). If
-you only need to support Bazel 8 or newer, we recommend using [symbolic
-macros](/versions/8.4.2/extending/macros) instead; take a look at [Creating a Symbolic
-Macro](../macro-tutorial).
+you only need to support Bazel 8 or newer, we recommend using [symbolic macros](/versions/8.4.2/extending/macros) instead; take a look at [Creating a Symbolic Macro](/versions/8.4.2/rules/macro-tutorial).
 
 Imagine that you need to run a tool as part of your build. For example, you
 may want to generate or preprocess a source file, or compress a binary. In this
diff --git a/versions/8.4.2/rules/lib/builtins/Action.mdx b/versions/8.4.2/rules/lib/builtins/Action.mdx
index 10f87e10..afe1b729 100644
--- a/versions/8.4.2/rules/lib/builtins/Action.mdx
+++ b/versions/8.4.2/rules/lib/builtins/Action.mdx
@@ -4,7 +4,7 @@ title: 'Action'
 
 An action created during rule analysis.
 
-This object is visible for the purpose of testing, and may be obtained from an `Actions` provider. It is normally not necessary to access `Action` objects or their fields within a rule's implementation function. You may instead want to see the [Rules page](https://bazel.build/versions/8.4.2/extending/rules#actions) for a general discussion of how to use actions when defining custom rules, or the [API reference](../builtins/actions) for creating actions.
+This object is visible for the purpose of testing, and may be obtained from an `Actions` provider. It is normally not necessary to access `Action` objects or their fields within a rule's implementation function. You may instead want to see the [Rules page](https://bazel.build/versions/8.4.2/extending/rules#actions) for a general discussion of how to use actions when defining custom rules, or the [API reference](/versions/8.4.2/rules/lib/builtins/actions) for creating actions.
 
 Some fields of this object are only applicable for certain kinds of actions. Fields that are inapplicable are set to `None`.
 
@@ -25,7 +25,7 @@ Some fields of this object are only applicable for certain kinds of actions. Fie
 sequence Action.args
 ```
 
-A list of frozen [Args](../builtins/Args) objects containing information about the action arguments. These objects contain accurate argument information, including arguments involving expanded action output directories. However, [Args](../builtins/Args) objects are not readable in the analysis phase. For a less accurate account of arguments which is available in the analysis phase, see [argv](#argv).
+A list of frozen [Args](/versions/8.4.2/rules/lib/builtins/Args) objects containing information about the action arguments. These objects contain accurate argument information, including arguments involving expanded action output directories. However, [Args](/versions/8.4.2/rules/lib/builtins/Args) objects are not readable in the analysis phase. For a less accurate account of arguments which is available in the analysis phase, see [argv](#argv).
 
 Note that some types of actions do not yet support exposure of this field. For such action types, this is `None`.
 May return `None`.
@@ -36,7 +36,7 @@ May return `None`.
 sequence Action.argv
 ```
 
-For actions created by [ctx.actions.run()](../builtins/actions#run) or [ctx.actions.run\_shell()](../builtins/actions#run_shell) an immutable list of the arguments for the command line to be executed. Note that for shell actions the first two arguments will be the shell path and `"-c"`.
+For actions created by [ctx.actions.run()](/versions/8.4.2/rules/lib/builtins/actions#run) or [ctx.actions.run\_shell()](/versions/8.4.2/rules/lib/builtins/actions#run_shell) an immutable list of the arguments for the command line to be executed. Note that for shell actions the first two arguments will be the shell path and `"-c"`.
 May return `None`.
 
 ## content
@@ -45,7 +45,7 @@ May return `None`.
 string Action.content
 ```
 
-For actions created by [ctx.actions.write()](../builtins/actions#write) or [ctx.actions.expand\_template()](../builtins/actions#expand_template), the contents of the file to be written, if those contents can be computed during the analysis phase. The value is `None` if the contents cannot be determined until the execution phase, such as when a directory in an [Args](../builtins/Args) object needs to be expanded.
+For actions created by [ctx.actions.write()](/versions/8.4.2/rules/lib/builtins/actions#write) or [ctx.actions.expand\_template()](/versions/8.4.2/rules/lib/builtins/actions#expand_template), the contents of the file to be written, if those contents can be computed during the analysis phase. The value is `None` if the contents cannot be determined until the execution phase, such as when a directory in an [Args](/versions/8.4.2/rules/lib/builtins/Args) object needs to be expanded.
 May return `None`.
 
 ## env
@@ -86,5 +86,5 @@ A set of the output files of this action.
 dict Action.substitutions
 ```
 
-For actions created by [ctx.actions.expand\_template()](../builtins/actions#expand_template), an immutable dict holding the substitution mapping.
+For actions created by [ctx.actions.expand\_template()](/versions/8.4.2/rules/lib/builtins/actions#expand_template), an immutable dict holding the substitution mapping.
 May return `None`.
\ No newline at end of file
diff --git a/versions/8.4.2/rules/lib/builtins/Args.mdx b/versions/8.4.2/rules/lib/builtins/Args.mdx
index 5d862675..0ffa1ec1 100644
--- a/versions/8.4.2/rules/lib/builtins/Args.mdx
+++ b/versions/8.4.2/rules/lib/builtins/Args.mdx
@@ -4,15 +4,15 @@ title: 'Args'
 
 An object that encapsulates, in a memory-efficient way, the data needed to build part or all of a command line.
 
-It often happens that an action requires a large command line containing values accumulated from transitive dependencies. For example, a linker command line might list every object file needed by all of the libraries being linked. It is best practice to store such transitive data in [`depset`](../builtins/depset)s, so that they can be shared by multiple targets. However, if the rule author had to convert these depsets into lists of strings in order to construct an action command line, it would defeat this memory-sharing optimization.
+It often happens that an action requires a large command line containing values accumulated from transitive dependencies. For example, a linker command line might list every object file needed by all of the libraries being linked. It is best practice to store such transitive data in [`depset`](/versions/8.4.2/rules/lib/builtins/depset)s, so that they can be shared by multiple targets. However, if the rule author had to convert these depsets into lists of strings in order to construct an action command line, it would defeat this memory-sharing optimization.
 
 For this reason, the action-constructing functions accept `Args` objects in addition to strings. Each `Args` object represents a concatenation of strings and depsets, with optional transformations for manipulating the data. `Args` objects do not process the depsets they encapsulate until the execution phase, when it comes time to calculate the command line. This helps defer any expensive copying until after the analysis phase is complete. See the [Optimizing Performance](https://bazel.build/versions/8.4.2/rules/performance) page for more information.
 
-`Args` are constructed by calling [`ctx.actions.args()`](../builtins/actions#args). They can be passed as the `arguments` parameter of [`ctx.actions.run()`](../builtins/actions#run) or [`ctx.actions.run_shell()`](../builtins/actions#run_shell). Each mutation of an `Args` object appends values to the eventual command line.
+`Args` are constructed by calling [`ctx.actions.args()`](/versions/8.4.2/rules/lib/builtins/actions#args). They can be passed as the `arguments` parameter of [`ctx.actions.run()`](/versions/8.4.2/rules/lib/builtins/actions#run) or [`ctx.actions.run_shell()`](/versions/8.4.2/rules/lib/builtins/actions#run_shell). Each mutation of an `Args` object appends values to the eventual command line.
 
 The `map_each` feature allows you to customize how items are transformed into strings. If you do not provide a `map_each` function, the standard conversion is as follows:
 
-* Values that are already strings are left as-is.* [`File`](../builtins/File) objects are turned into their `File.path` values.* [`Label`](../builtins/Label) objects are turned into a string representation that resolves back to the same object when resolved in the context of the main repository. If possible, the string representation uses the apparent name of a repository in favor of the repository's canonical name, which makes this representation suited for use in BUILD files. While the exact form of the representation is not guaranteed, typical examples are `//foo:bar`, `@repo//foo:bar` and `@@canonical_name+//foo:bar.bzl`.* All other types are turned into strings in an *unspecified* manner. For this reason, you should avoid passing values that are not of string or `File` type to `add()`, and if you pass them to `add_all()` or `add_joined()` then you should provide a `map_each` function.
+* Values that are already strings are left as-is.* [`File`](/versions/8.4.2/rules/lib/builtins/File) objects are turned into their `File.path` values.* [`Label`](/versions/8.4.2/rules/lib/builtins/Label) objects are turned into a string representation that resolves back to the same object when resolved in the context of the main repository. If possible, the string representation uses the apparent name of a repository in favor of the repository's canonical name, which makes this representation suited for use in BUILD files. While the exact form of the representation is not guaranteed, typical examples are `//foo:bar`, `@repo//foo:bar` and `@@canonical_name+//foo:bar.bzl`.* All other types are turned into strings in an *unspecified* manner. For this reason, you should avoid passing values that are not of string or `File` type to `add()`, and if you pass them to `add_all()` or `add_joined()` then you should provide a `map_each` function.
 
 When using string formatting (`format`, `format_each`, and `format_joined` params of the `add*()` methods), the format template is interpreted in the same way as `%`-substitution on strings, except that the template must have exactly one substitution placeholder and it must be `%s`. Literal percents may be escaped as `%%`. Formatting is applied after the value is converted to a string as per the above.
 
@@ -64,7 +64,7 @@ Appends an argument to this command line.
 | --- | --- |
 | `arg_name_or_value` | required  If two positional parameters are passed this is interpreted as the arg name. The arg name is added before the value without any processing. If only one positional parameter is passed, it is interpreted as `value` (see below). |
 | `value` | default is `unbound`  The object to append. It will be converted to a string using the standard conversion mentioned above. Since there is no `map_each` parameter for this function, `value` should be either a string or a `File`. A list, tuple, depset, or directory `File` must be passed to [`add_all()` or [`add_joined()`](#add_joined) instead of this method.](#add_all) |
-| `format` | [string](../core/string); or `None`; default is `None`  A format string pattern, to be applied to the stringified version of `value`. |
+| `format` | [string](/versions/8.4.2/rules/lib/core/string); or `None`; default is `None`  A format string pattern, to be applied to the stringified version of `value`. |
 
 ## add\_all
 
@@ -86,15 +86,15 @@ Note that empty strings are valid arguments that are subject to all these proces
 | Parameter | Description |
 | --- | --- |
 | `arg_name_or_values` | required  If two positional parameters are passed this is interpreted as the arg name. The arg name is added before the `values` as a separate argument without any processing. This arg name will not be added if `omit_if_empty` is true (the default) and no other items are appended (as happens if `values` is empty or all of its items are filtered). If only one positional parameter is passed, it is interpreted as `values` (see below). |
-| `values` | [sequence](../core/list); or [depset](../builtins/depset); default is `unbound`  The list, tuple, or depset whose items will be appended. |
-| `map_each` | callable; or `None`; default is `None`  A function that converts each item to zero or more strings, which may be further processed before appending. If this param is not provided, the standard conversion is used. The function is passed either one or two positional arguments: the item to convert, followed by an optional [`DirectoryExpander`](../builtins/DirectoryExpander). The second argument will be passed only if the supplied function is user-defined (not built-in) and declares more than one parameter. The return value's type depends on how many arguments are to be produced for the item:  * In the common case when each item turns into one string, the function should return that string.* If the item is to be filtered out entirely, the function should return `None`.* If the item turns into multiple strings, the function returns a list of those strings.  Returning a single string or `None` has the same effect as returning a list of length 1 or length 0 respectively. However, it is more efficient and readable to avoid creating a list where it is not needed. Ordinarily, items that are directories are automatically expanded to their contents when `expand_directories=True` is set. However, this will not expand directories contained inside other values -- for instance, when the items are structs that have directories as fields. In this situation, the `DirectoryExpander` argument can be applied to manually obtain the files of a given directory. To avoid unintended retention of large analysis-phase data structures into the execution phase, the `map_each` function must be declared by a top-level `def` statement; it may not be a nested function closure by default. *Warning:* [`print()`](../globals/all#print) statements that are executed during the call to `map_each` will not produce any visible output. |
-| `format_each` | [string](../core/string); or `None`; default is `None`  An optional format string pattern, applied to each string returned by the `map_each` function. The format string must have exactly one '%s' placeholder. |
-| `before_each` | [string](../core/string); or `None`; default is `None`  An optional argument to append before each argument derived from `values` is appended. |
-| `omit_if_empty` | [bool](../core/bool); default is `True`  If true, if there are no arguments derived from `values` to be appended, then all further processing is suppressed and the command line will be unchanged. If false, the arg name and `terminate_with`, if provided, will still be appended regardless of whether or not there are other arguments. |
-| `uniquify` | [bool](../core/bool); default is `False`  If true, duplicate arguments that are derived from `values` will be omitted. Only the first occurrence of each argument will remain. Usually this feature is not needed because depsets already omit duplicates, but it can be useful if `map_each` emits the same string for multiple items. |
-| `expand_directories` | [bool](../core/bool); default is `True`  If true, any directories in `values` will be expanded to a flat list of files. This happens before `map_each` is applied. |
-| `terminate_with` | [string](../core/string); or `None`; default is `None`  An optional argument to append after all other arguments. This argument will not be added if `omit_if_empty` is true (the default) and no other items are appended (as happens if `values` is empty or all of its items are filtered). |
-| `allow_closure` | [bool](../core/bool); default is `False`  If true, allows the use of closures in function parameters like `map_each`. Usually this isn't necessary and it risks retaining large analysis-phase data structures into the execution phase. |
+| `values` | [sequence](/versions/8.4.2/rules/lib/core/list); or [depset](/versions/8.4.2/rules/lib/builtins/depset); default is `unbound`  The list, tuple, or depset whose items will be appended. |
+| `map_each` | callable; or `None`; default is `None`  A function that converts each item to zero or more strings, which may be further processed before appending. If this param is not provided, the standard conversion is used. The function is passed either one or two positional arguments: the item to convert, followed by an optional [`DirectoryExpander`](/versions/8.4.2/rules/lib/builtins/DirectoryExpander). The second argument will be passed only if the supplied function is user-defined (not built-in) and declares more than one parameter. The return value's type depends on how many arguments are to be produced for the item:  * In the common case when each item turns into one string, the function should return that string.* If the item is to be filtered out entirely, the function should return `None`.* If the item turns into multiple strings, the function returns a list of those strings.  Returning a single string or `None` has the same effect as returning a list of length 1 or length 0 respectively. However, it is more efficient and readable to avoid creating a list where it is not needed. Ordinarily, items that are directories are automatically expanded to their contents when `expand_directories=True` is set. However, this will not expand directories contained inside other values -- for instance, when the items are structs that have directories as fields. In this situation, the `DirectoryExpander` argument can be applied to manually obtain the files of a given directory. To avoid unintended retention of large analysis-phase data structures into the execution phase, the `map_each` function must be declared by a top-level `def` statement; it may not be a nested function closure by default. *Warning:* [`print()`](/versions/8.4.2/rules/lib/globals/all#print) statements that are executed during the call to `map_each` will not produce any visible output. |
+| `format_each` | [string](/versions/8.4.2/rules/lib/core/string); or `None`; default is `None`  An optional format string pattern, applied to each string returned by the `map_each` function. The format string must have exactly one '%s' placeholder. |
+| `before_each` | [string](/versions/8.4.2/rules/lib/core/string); or `None`; default is `None`  An optional argument to append before each argument derived from `values` is appended. |
+| `omit_if_empty` | [bool](/versions/8.4.2/rules/lib/core/bool); default is `True`  If true, if there are no arguments derived from `values` to be appended, then all further processing is suppressed and the command line will be unchanged. If false, the arg name and `terminate_with`, if provided, will still be appended regardless of whether or not there are other arguments. |
+| `uniquify` | [bool](/versions/8.4.2/rules/lib/core/bool); default is `False`  If true, duplicate arguments that are derived from `values` will be omitted. Only the first occurrence of each argument will remain. Usually this feature is not needed because depsets already omit duplicates, but it can be useful if `map_each` emits the same string for multiple items. |
+| `expand_directories` | [bool](/versions/8.4.2/rules/lib/core/bool); default is `True`  If true, any directories in `values` will be expanded to a flat list of files. This happens before `map_each` is applied. |
+| `terminate_with` | [string](/versions/8.4.2/rules/lib/core/string); or `None`; default is `None`  An optional argument to append after all other arguments. This argument will not be added if `omit_if_empty` is true (the default) and no other items are appended (as happens if `values` is empty or all of its items are filtered). |
+| `allow_closure` | [bool](/versions/8.4.2/rules/lib/core/bool); default is `False`  If true, allows the use of closures in function parameters like `map_each`. Usually this isn't necessary and it risks retaining large analysis-phase data structures into the execution phase. |
 
 ## add\_joined
 
@@ -113,15 +113,15 @@ If after filtering there are no strings to join into an argument, and if `omit_i
 | Parameter | Description |
 | --- | --- |
 | `arg_name_or_values` | required  If two positional parameters are passed this is interpreted as the arg name. The arg name is added before `values` without any processing. This arg will not be added if `omit_if_empty` is true (the default) and there are no strings derived from `values` to join together (which can happen if `values` is empty or all of its items are filtered). If only one positional parameter is passed, it is interpreted as `values` (see below). |
-| `values` | [sequence](../core/list); or [depset](../builtins/depset); default is `unbound`  The list, tuple, or depset whose items will be joined. |
-| `join_with` | [string](../core/string); required  A delimiter string used to join together the strings obtained from applying `map_each` and `format_each`, in the same manner as [`string.join()`](../core/string#join). |
+| `values` | [sequence](/versions/8.4.2/rules/lib/core/list); or [depset](/versions/8.4.2/rules/lib/builtins/depset); default is `unbound`  The list, tuple, or depset whose items will be joined. |
+| `join_with` | [string](/versions/8.4.2/rules/lib/core/string); required  A delimiter string used to join together the strings obtained from applying `map_each` and `format_each`, in the same manner as [`string.join()`](/versions/8.4.2/rules/lib/core/string#join). |
 | `map_each` | callable; or `None`; default is `None`  Same as for [`add_all`](#add_all.map_each). |
-| `format_each` | [string](../core/string); or `None`; default is `None`  Same as for [`add_all`](#add_all.format_each). |
-| `format_joined` | [string](../core/string); or `None`; default is `None`  An optional format string pattern applied to the joined string. The format string must have exactly one '%s' placeholder. |
-| `omit_if_empty` | [bool](../core/bool); default is `True`  If true, if there are no strings to join together (either because `values` is empty or all its items are filtered), then all further processing is suppressed and the command line will be unchanged. If false, then even if there are no strings to join together, two arguments will be appended: the arg name followed by an empty string (which is the logical join of zero strings). |
-| `uniquify` | [bool](../core/bool); default is `False`  Same as for [`add_all`](#add_all.uniquify). |
-| `expand_directories` | [bool](../core/bool); default is `True`  Same as for [`add_all`](#add_all.expand_directories). |
-| `allow_closure` | [bool](../core/bool); default is `False`  Same as for [`add_all`](#add_all.allow_closure). |
+| `format_each` | [string](/versions/8.4.2/rules/lib/core/string); or `None`; default is `None`  Same as for [`add_all`](#add_all.format_each). |
+| `format_joined` | [string](/versions/8.4.2/rules/lib/core/string); or `None`; default is `None`  An optional format string pattern applied to the joined string. The format string must have exactly one '%s' placeholder. |
+| `omit_if_empty` | [bool](/versions/8.4.2/rules/lib/core/bool); default is `True`  If true, if there are no strings to join together (either because `values` is empty or all its items are filtered), then all further processing is suppressed and the command line will be unchanged. If false, then even if there are no strings to join together, two arguments will be appended: the arg name followed by an empty string (which is the logical join of zero strings). |
+| `uniquify` | [bool](/versions/8.4.2/rules/lib/core/bool); default is `False`  Same as for [`add_all`](#add_all.uniquify). |
+| `expand_directories` | [bool](/versions/8.4.2/rules/lib/core/bool); default is `True`  Same as for [`add_all`](#add_all.expand_directories). |
+| `allow_closure` | [bool](/versions/8.4.2/rules/lib/core/bool); default is `False`  Same as for [`add_all`](#add_all.allow_closure). |
 
 ## set\_param\_file\_format
 
@@ -135,7 +135,7 @@ Sets the format of the param file, if one is used
 
 | Parameter | Description |
 | --- | --- |
-| `format` | [string](../core/string); required  Must be one of:  * "multiline": Each item (argument name or value) is written verbatim to the param file with a newline character following it. * "shell": Same as "multiline", but the items are shell-quoted * "flag\_per\_line": Same as "multiline", but (1) only flags (beginning with '--') are written to the param file, and (2) the values of the flags, if any, are written on the same line with a '=' separator. This is the format expected by the Abseil flags library.   The format defaults to "shell" if not called. |
+| `format` | [string](/versions/8.4.2/rules/lib/core/string); required  Must be one of:  * "multiline": Each item (argument name or value) is written verbatim to the param file with a newline character following it. * "shell": Same as "multiline", but the items are shell-quoted * "flag\_per\_line": Same as "multiline", but (1) only flags (beginning with '--') are written to the param file, and (2) the values of the flags, if any, are written on the same line with a '=' separator. This is the format expected by the Abseil flags library.   The format defaults to "shell" if not called. |
 
 ## use\_param\_file
 
@@ -151,5 +151,5 @@ Bazel may choose to elide writing the params file to the output tree during exec
 
 | Parameter | Description |
 | --- | --- |
-| `param_file_arg` | [string](../core/string); required  A format string with a single "%s". If the args are spilled to a params file then they are replaced with an argument consisting of this string formatted with the path of the params file. For example, if the args are spilled to a params file "params.txt", then specifying "--file=%s" would cause the action command line to contain "--file=params.txt". |
-| `use_always` | [bool](../core/bool); default is `False`  Whether to always spill the args to a params file. If false, bazel will decide whether the arguments need to be spilled based on your system and arg length. |
\ No newline at end of file
+| `param_file_arg` | [string](/versions/8.4.2/rules/lib/core/string); required  A format string with a single "%s". If the args are spilled to a params file then they are replaced with an argument consisting of this string formatted with the path of the params file. For example, if the args are spilled to a params file "params.txt", then specifying "--file=%s" would cause the action command line to contain "--file=params.txt". |
+| `use_always` | [bool](/versions/8.4.2/rules/lib/core/bool); default is `False`  Whether to always spill the args to a params file. If false, bazel will decide whether the arguments need to be spilled based on your system and arg length. |
\ No newline at end of file
diff --git a/versions/8.4.2/rules/lib/builtins/Aspect.mdx b/versions/8.4.2/rules/lib/builtins/Aspect.mdx
index 40de1366..647037ef 100644
--- a/versions/8.4.2/rules/lib/builtins/Aspect.mdx
+++ b/versions/8.4.2/rules/lib/builtins/Aspect.mdx
@@ -3,4 +3,4 @@ title: 'Aspect'
 ---
 
 For more information about Aspects, please consult the
-[documentation of the aspect function](../globals/bzl#aspect) or the [introduction to Aspects](https://bazel.build/versions/8.4.2/rules/aspects).
\ No newline at end of file
+[documentation of the aspect function](/versions/8.4.2/rules/lib/globals/bzl#aspect) or the [introduction to Aspects](https://bazel.build/versions/8.4.2/rules/aspects).
\ No newline at end of file
diff --git a/versions/8.4.2/rules/lib/builtins/Attribute.mdx b/versions/8.4.2/rules/lib/builtins/Attribute.mdx
index 18486c41..1b9a6957 100644
--- a/versions/8.4.2/rules/lib/builtins/Attribute.mdx
+++ b/versions/8.4.2/rules/lib/builtins/Attribute.mdx
@@ -2,4 +2,4 @@
 title: 'Attribute'
 ---
 
-Representation of a definition of an attribute. Use the [attr](../toplevel/attr) module to create an Attribute. They are only for use with a [rule](../globals/bzl#rule) or an [aspect](../globals/bzl#aspect).
\ No newline at end of file
+Representation of a definition of an attribute. Use the [attr](/versions/8.4.2/rules/lib/toplevel/attr) module to create an Attribute. They are only for use with a [rule](/versions/8.4.2/rules/lib/globals/bzl#rule) or an [aspect](/versions/8.4.2/rules/lib/globals/bzl#aspect).
\ No newline at end of file
diff --git a/versions/8.4.2/rules/lib/builtins/DirectoryExpander.mdx b/versions/8.4.2/rules/lib/builtins/DirectoryExpander.mdx
index 8bf9ae69..b76a4d39 100644
--- a/versions/8.4.2/rules/lib/builtins/DirectoryExpander.mdx
+++ b/versions/8.4.2/rules/lib/builtins/DirectoryExpander.mdx
@@ -2,7 +2,7 @@
 title: 'DirectoryExpander'
 ---
 
-Expands directories created by [`ctx.actions.declare_directory`](../builtins/actions#declare_directory) during the execution phase. This is useful to expand directories in [`map_each`](../builtins/Args#add_all.map_each).
+Expands directories created by [`ctx.actions.declare_directory`](/versions/8.4.2/rules/lib/builtins/actions#declare_directory) during the execution phase. This is useful to expand directories in [`map_each`](/versions/8.4.2/rules/lib/builtins/Args#add_all.map_each).
 
 ## Members
 
@@ -20,4 +20,4 @@ If the given `File` is a directory, this returns a list of `File`s recursively u
 
 | Parameter | Description |
 | --- | --- |
-| `file` | [File](../builtins/File); required  The directory or file to expand. |
\ No newline at end of file
+| `file` | [File](/versions/8.4.2/rules/lib/builtins/File); required  The directory or file to expand. |
\ No newline at end of file
diff --git a/versions/8.4.2/rules/lib/builtins/DottedVersion.mdx b/versions/8.4.2/rules/lib/builtins/DottedVersion.mdx
index f17cea85..a3aeb234 100644
--- a/versions/8.4.2/rules/lib/builtins/DottedVersion.mdx
+++ b/versions/8.4.2/rules/lib/builtins/DottedVersion.mdx
@@ -20,4 +20,4 @@ Compares based on most significant (first) not-matching version component. So, f
 
 | Parameter | Description |
 | --- | --- |
-| `other` | [DottedVersion](../builtins/DottedVersion); required  The other dotted version. |
\ No newline at end of file
+| `other` | [DottedVersion](/versions/8.4.2/rules/lib/builtins/DottedVersion); required  The other dotted version. |
\ No newline at end of file
diff --git a/versions/8.4.2/rules/lib/builtins/File.mdx b/versions/8.4.2/rules/lib/builtins/File.mdx
index 0e9acee0..d39b3746 100644
--- a/versions/8.4.2/rules/lib/builtins/File.mdx
+++ b/versions/8.4.2/rules/lib/builtins/File.mdx
@@ -4,7 +4,7 @@ title: 'File'
 
 This object is created during the analysis phase to represent a file or directory that will be read or written during the execution phase. It is not an open file handle, and cannot be used to directly read or write file contents. Rather, you use it to construct the action graph in a rule implementation function by passing it to action-creating functions. See the [Rules page](https://bazel.build/versions/8.4.2/extending/rules#files) for more information.
 
-When a `File` is passed to an [`Args`](../builtins/Args) object without using a `map_each` function, it is converted to a string by taking the value of its `path` field.
+When a `File` is passed to an [`Args`](/versions/8.4.2/rules/lib/builtins/Args) object without using a `map_each` function, it is converted to a string by taking the value of its `path` field.
 
 ## Members
 
@@ -83,7 +83,7 @@ May return `None`.
 string File.path
 ```
 
-The execution path of this file, relative to the workspace's execution directory. It consists of two parts, an optional first part called the *root* (see also the [root](../builtins/root) module), and the second part which is the `short_path`. The root may be empty, which it usually is for non-generated files. For generated files it usually contains a configuration-specific path fragment that encodes things like the target CPU architecture that was used while building said file. Use the `short_path` for the path under which the file is mapped if it's in the runfiles of a binary.
+The execution path of this file, relative to the workspace's execution directory. It consists of two parts, an optional first part called the *root* (see also the [root](/versions/8.4.2/rules/lib/builtins/root) module), and the second part which is the `short_path`. The root may be empty, which it usually is for non-generated files. For generated files it usually contains a configuration-specific path fragment that encodes things like the target CPU architecture that was used while building said file. Use the `short_path` for the path under which the file is mapped if it's in the runfiles of a binary.
 
 ## root
 
@@ -107,4 +107,4 @@ The path of this file relative to its root. This excludes the aforementioned *ro
 string File.tree_relative_path
 ```
 
-The path of this file relative to the root of the ancestor's tree, if the ancestor's [is\_directory](#is_directory) field is true. `tree_relative_path` is only available for expanded files of a directory in an action command, i.e. [Args.add\_all()](../builtins/Args#add_all). For other types of files, it is an error to access this field.
\ No newline at end of file
+The path of this file relative to the root of the ancestor's tree, if the ancestor's [is\_directory](#is_directory) field is true. `tree_relative_path` is only available for expanded files of a directory in an action command, i.e. [Args.add\_all()](/versions/8.4.2/rules/lib/builtins/Args#add_all). For other types of files, it is an error to access this field.
\ No newline at end of file
diff --git a/versions/8.4.2/rules/lib/builtins/Label.mdx b/versions/8.4.2/rules/lib/builtins/Label.mdx
index cfbcb8dd..494b168d 100644
--- a/versions/8.4.2/rules/lib/builtins/Label.mdx
+++ b/versions/8.4.2/rules/lib/builtins/Label.mdx
@@ -33,7 +33,7 @@ For macros, a related function, `native.package_relative_label()`, converts the
 
 | Parameter | Description |
 | --- | --- |
-| `input` | [string](../core/string); or [Label](../builtins/Label); required  The input label string or Label object. If a Label object is passed, it's returned as is. |
+| `input` | [string](/versions/8.4.2/rules/lib/core/string); or [Label](/versions/8.4.2/rules/lib/builtins/Label); required  The input label string or Label object. If a Label object is passed, it's returned as is. |
 
 ## name
 
@@ -66,7 +66,7 @@ Label Label.relative(relName)
 ```
 
 **Experimental**. This API is experimental and may change at any time. Please do not depend on it. It may be enabled on an experimental basis by setting `--+incompatible_enable_deprecated_label_apis`
-**Deprecated.** This method behaves surprisingly when used with an argument containing an apparent repo name. Prefer [`Label.same_package_label()`](#same_package_label), [`native.package_relative_label()`](../toplevel/native#package_relative_label), or [`Label()`](#Label) instead.
+**Deprecated.** This method behaves surprisingly when used with an argument containing an apparent repo name. Prefer [`Label.same_package_label()`](#same_package_label), [`native.package_relative_label()`](/versions/8.4.2/rules/lib/toplevel/native#package_relative_label), or [`Label()`](#Label) instead.
 
 Resolves a label that is either absolute (starts with `//`) or relative to the current package. If this label is in a remote repository, the argument will be resolved relative to that repository. If the argument contains a repository name, the current label is ignored and the argument is returned as-is, except that the repository name is rewritten if it is in the current repository mapping. Reserved labels will also be returned as-is.
 For example:
@@ -89,7 +89,7 @@ Label("@repo//foo/bar:baz").relative("@other//wiz:quux") == Label("@remapped//wi
 
 | Parameter | Description |
 | --- | --- |
-| `relName` | [string](../core/string); required |
+| `relName` | [string](/versions/8.4.2/rules/lib/core/string); required |
 
 ## repo\_name
 
@@ -115,7 +115,7 @@ Creates a label in the same package as this label with the given target name.
 
 | Parameter | Description |
 | --- | --- |
-| `target_name` | [string](../core/string); required |
+| `target_name` | [string](/versions/8.4.2/rules/lib/core/string); required |
 
 ## workspace\_name
 
diff --git a/versions/8.4.2/rules/lib/builtins/LateBoundDefault.mdx b/versions/8.4.2/rules/lib/builtins/LateBoundDefault.mdx
index edd0010c..48cc06d1 100644
--- a/versions/8.4.2/rules/lib/builtins/LateBoundDefault.mdx
+++ b/versions/8.4.2/rules/lib/builtins/LateBoundDefault.mdx
@@ -4,4 +4,4 @@ title: 'LateBoundDefault'
 
 Represents a late-bound default attribute value of type 'Label'. The value of a LateBoundDefault is only resolvable in the context of a rule implementation function, and depends on the current build configuration. For example, a LateBoundDefault might represent the Label of the java toolchain in the current build configuration.
 
-See [configuration\_field](../globals/bzl#configuration_field) for example usage.
\ No newline at end of file
+See [configuration\_field](/versions/8.4.2/rules/lib/globals/bzl#configuration_field) for example usage.
\ No newline at end of file
diff --git a/versions/8.4.2/rules/lib/builtins/Provider.mdx b/versions/8.4.2/rules/lib/builtins/Provider.mdx
index 54b9cf36..f95f66e3 100644
--- a/versions/8.4.2/rules/lib/builtins/Provider.mdx
+++ b/versions/8.4.2/rules/lib/builtins/Provider.mdx
@@ -14,7 +14,7 @@ This value has a dual purpose:
   ```
 
   Note: Some providers, defined internally, do not allow instance creation
-* It is a *key* to access a provider instance on a [Target](../builtins/Target)
+* It is a *key* to access a provider instance on a [Target](/versions/8.4.2/rules/lib/builtins/Target)
 
   ```
   DataInfo = provider()
@@ -22,4 +22,4 @@ This value has a dual purpose:
     ... ctx.attr.dep[DataInfo]
   ```
 
-Create a new `Provider` using the [provider](../globals/bzl#provider) function.
\ No newline at end of file
+Create a new `Provider` using the [provider](/versions/8.4.2/rules/lib/globals/bzl#provider) function.
\ No newline at end of file
diff --git a/versions/8.4.2/rules/lib/builtins/TemplateDict.mdx b/versions/8.4.2/rules/lib/builtins/TemplateDict.mdx
index 5f18fd44..ca45d4df 100644
--- a/versions/8.4.2/rules/lib/builtins/TemplateDict.mdx
+++ b/versions/8.4.2/rules/lib/builtins/TemplateDict.mdx
@@ -21,8 +21,8 @@ Add a String value
 
 | Parameter | Description |
 | --- | --- |
-| `key` | [string](../core/string); required  A String key |
-| `value` | [string](../core/string); required  A String value |
+| `key` | [string](/versions/8.4.2/rules/lib/core/string); required  A String key |
+| `value` | [string](/versions/8.4.2/rules/lib/core/string); required  A String value |
 
 ## add\_joined
 
@@ -36,10 +36,10 @@ Add depset of values
 
 | Parameter | Description |
 | --- | --- |
-| `key` | [string](../core/string); required  A String key |
-| `values` | [depset](../builtins/depset); required  The depset whose items will be joined. |
-| `join_with` | [string](../core/string); required  A delimiter string used to join together the strings obtained from applying `map_each`, in the same manner as [`string.join()`](../core/string#join). |
+| `key` | [string](/versions/8.4.2/rules/lib/core/string); required  A String key |
+| `values` | [depset](/versions/8.4.2/rules/lib/builtins/depset); required  The depset whose items will be joined. |
+| `join_with` | [string](/versions/8.4.2/rules/lib/core/string); required  A delimiter string used to join together the strings obtained from applying `map_each`, in the same manner as [`string.join()`](/versions/8.4.2/rules/lib/core/string#join). |
 | `map_each` | callable; required  A Starlark function accepting a single argument and returning either a string, `None`, or a list of strings. This function is applied to each item of the depset specified in the `values` parameter |
-| `uniquify` | [bool](../core/bool); default is `False`  If true, duplicate strings derived from `values` will be omitted. Only the first occurrence of each string will remain. Usually this feature is not needed because depsets already omit duplicates, but it can be useful if `map_each` emits the same string for multiple items. |
-| `format_joined` | [string](../core/string); or `None`; default is `None`  An optional format string pattern applied to the joined string. The format string must have exactly one '%s' placeholder. |
-| `allow_closure` | [bool](../core/bool); default is `False`  If true, allows the use of closures in function parameters like `map_each`. Usually this isn't necessary and it risks retaining large analysis-phase data structures into the execution phase. |
\ No newline at end of file
+| `uniquify` | [bool](/versions/8.4.2/rules/lib/core/bool); default is `False`  If true, duplicate strings derived from `values` will be omitted. Only the first occurrence of each string will remain. Usually this feature is not needed because depsets already omit duplicates, but it can be useful if `map_each` emits the same string for multiple items. |
+| `format_joined` | [string](/versions/8.4.2/rules/lib/core/string); or `None`; default is `None`  An optional format string pattern applied to the joined string. The format string must have exactly one '%s' placeholder. |
+| `allow_closure` | [bool](/versions/8.4.2/rules/lib/core/bool); default is `False`  If true, allows the use of closures in function parameters like `map_each`. Usually this isn't necessary and it risks retaining large analysis-phase data structures into the execution phase. |
\ No newline at end of file
diff --git a/versions/8.4.2/rules/lib/builtins/actions.mdx b/versions/8.4.2/rules/lib/builtins/actions.mdx
index 7fbf5bdf..127a2568 100644
--- a/versions/8.4.2/rules/lib/builtins/actions.mdx
+++ b/versions/8.4.2/rules/lib/builtins/actions.mdx
@@ -2,7 +2,7 @@
 title: 'actions'
 ---
 
-Module providing functions to create actions. Access this module using [`ctx.actions`](../builtins/ctx#actions).
+Module providing functions to create actions. Access this module using [`ctx.actions`](/versions/8.4.2/rules/lib/builtins/ctx#actions).
 
 ## Members
 
@@ -32,14 +32,14 @@ Returns an Args object that can be used to build memory-efficient command lines.
 File actions.declare_directory(filename, *, sibling=None)
 ```
 
-Declares that the rule or aspect creates a directory with the given name, in the current package. You must create an action that generates the directory. The contents of the directory are not directly accessible from Starlark, but can be expanded in an action command with [`Args.add_all()`](../builtins/Args#add_all). Only regular files and directories can be in the expanded contents of a declare\_directory.
+Declares that the rule or aspect creates a directory with the given name, in the current package. You must create an action that generates the directory. The contents of the directory are not directly accessible from Starlark, but can be expanded in an action command with [`Args.add_all()`](/versions/8.4.2/rules/lib/builtins/Args#add_all). Only regular files and directories can be in the expanded contents of a declare\_directory.
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `filename` | [string](../core/string); required  If no 'sibling' provided, path of the new directory, relative to the current package. Otherwise a base name for a file ('sibling' defines a directory). |
-| `sibling` | [File](../builtins/File); or `None`; default is `None`  A file that lives in the same directory as the newly declared directory. The file must be in the current package. |
+| `filename` | [string](/versions/8.4.2/rules/lib/core/string); required  If no 'sibling' provided, path of the new directory, relative to the current package. Otherwise a base name for a file ('sibling' defines a directory). |
+| `sibling` | [File](/versions/8.4.2/rules/lib/builtins/File); or `None`; default is `None`  A file that lives in the same directory as the newly declared directory. The file must be in the current package. |
 
 ## declare\_file
 
@@ -51,14 +51,14 @@ Declares that the rule or aspect creates a file with the given filename. If `sib
 
 Remember that in addition to declaring a file, you must separately create an action that emits the file. Creating that action will require passing the returned `File` object to the action's construction function.
 
-Note that [predeclared output files](https://bazel.build/versions/8.4.2/extending/rules#files) do not need to be (and cannot be) declared using this function. You can obtain their `File` objects from [`ctx.outputs`](../builtins/ctx#outputs) instead. [See example of use](https://github.com/bazelbuild/examples/tree/main/rules/computed_dependencies/hash.bzl).
+Note that [predeclared output files](https://bazel.build/versions/8.4.2/extending/rules#files) do not need to be (and cannot be) declared using this function. You can obtain their `File` objects from [`ctx.outputs`](/versions/8.4.2/rules/lib/builtins/ctx#outputs) instead. [See example of use](https://github.com/bazelbuild/examples/tree/main/rules/computed_dependencies/hash.bzl).
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `filename` | [string](../core/string); required  If no 'sibling' provided, path of the new file, relative to the current package. Otherwise a base name for a file ('sibling' determines a directory). |
-| `sibling` | [File](../builtins/File); or `None`; default is `None`  A file that lives in the same directory as the newly created file. The file must be in the current package. |
+| `filename` | [string](/versions/8.4.2/rules/lib/core/string); required  If no 'sibling' provided, path of the new file, relative to the current package. Otherwise a base name for a file ('sibling' determines a directory). |
+| `sibling` | [File](/versions/8.4.2/rules/lib/builtins/File); or `None`; default is `None`  A file that lives in the same directory as the newly created file. The file must be in the current package. |
 
 ## declare\_symlink
 
@@ -72,8 +72,8 @@ Declares that the rule or aspect creates a symlink with the given name in the cu
 
 | Parameter | Description |
 | --- | --- |
-| `filename` | [string](../core/string); required  If no 'sibling' provided, path of the new symlink, relative to the current package. Otherwise a base name for a file ('sibling' defines a directory). |
-| `sibling` | [File](../builtins/File); or `None`; default is `None`  A file that lives in the same directory as the newly declared symlink. |
+| `filename` | [string](/versions/8.4.2/rules/lib/core/string); required  If no 'sibling' provided, path of the new symlink, relative to the current package. Otherwise a base name for a file ('sibling' defines a directory). |
+| `sibling` | [File](/versions/8.4.2/rules/lib/builtins/File); or `None`; default is `None`  A file that lives in the same directory as the newly declared symlink. |
 
 ## do\_nothing
 
@@ -87,8 +87,8 @@ Creates an empty action that neither executes a command nor produces any output,
 
 | Parameter | Description |
 | --- | --- |
-| `mnemonic` | [string](../core/string); required  A one-word description of the action, for example, CppCompile or GoLink. |
-| `inputs` | [sequence](../core/list) of [File](../builtins/File)s; or [depset](../builtins/depset); default is `[]`  List of the input files of the action. |
+| `mnemonic` | [string](/versions/8.4.2/rules/lib/core/string); required  A one-word description of the action, for example, CppCompile or GoLink. |
+| `inputs` | [sequence](/versions/8.4.2/rules/lib/core/list) of [File](/versions/8.4.2/rules/lib/builtins/File)s; or [depset](/versions/8.4.2/rules/lib/builtins/depset); default is `[]`  List of the input files of the action. |
 
 ## expand\_template
 
@@ -102,11 +102,11 @@ Creates a template expansion action. When the action is executed, it will genera
 
 | Parameter | Description |
 | --- | --- |
-| `template` | [File](../builtins/File); required  The template file, which is a UTF-8 encoded text file. |
-| `output` | [File](../builtins/File); required  The output file, which is a UTF-8 encoded text file. |
-| `substitutions` | [dict](../core/dict); default is `{}`  Substitutions to make when expanding the template. |
-| `is_executable` | [bool](../core/bool); default is `False`  Whether the output file should be executable. |
-| `computed_substitutions` | [TemplateDict](../builtins/TemplateDict); default is `unbound`  Substitutions to make when expanding the template. |
+| `template` | [File](/versions/8.4.2/rules/lib/builtins/File); required  The template file, which is a UTF-8 encoded text file. |
+| `output` | [File](/versions/8.4.2/rules/lib/builtins/File); required  The output file, which is a UTF-8 encoded text file. |
+| `substitutions` | [dict](/versions/8.4.2/rules/lib/core/dict); default is `{}`  Substitutions to make when expanding the template. |
+| `is_executable` | [bool](/versions/8.4.2/rules/lib/core/bool); default is `False`  Whether the output file should be executable. |
+| `computed_substitutions` | [TemplateDict](/versions/8.4.2/rules/lib/builtins/TemplateDict); default is `unbound`  Substitutions to make when expanding the template. |
 
 ## run
 
@@ -120,22 +120,22 @@ Creates an action that runs an executable. [See example of use](https://github.c
 
 | Parameter | Description |
 | --- | --- |
-| `outputs` | [sequence](../core/list) of [File](../builtins/File)s; required  List of the output files of the action. |
-| `inputs` | [sequence](../core/list) of [File](../builtins/File)s; or [depset](../builtins/depset); default is `[]`  List or depset of the input files of the action. |
-| `unused_inputs_list` | [File](../builtins/File); or `None`; default is `None`  File containing list of inputs unused by the action. The content of this file (generally one of the outputs of the action) corresponds to the list of input files that were not used during the whole action execution. Any change in those files must not affect in any way the outputs of the action. |
-| `executable` | [File](../builtins/File); or [string](../core/string); or [FilesToRunProvider](../providers/FilesToRunProvider); required  The executable file to be called by the action. |
-| `tools` | [sequence](../core/list); or [depset](../builtins/depset); default is `unbound`  List or depset of any tools needed by the action. Tools are inputs with additional runfiles that are automatically made available to the action. When a list is provided, it can be a heterogenous collection of Files, FilesToRunProvider instances, or depsets of Files. Files which are directly in the list and come from ctx.executable will have their runfiles automatically added. When a depset is provided, it must contain only Files. In both cases, files within depsets are not cross-referenced with ctx.executable for runfiles. |
-| `arguments` | [sequence](../core/list); default is `[]`  Command line arguments of the action. Must be a list of strings or [`actions.args()`](#args) objects. |
-| `mnemonic` | [string](../core/string); or `None`; default is `None`  A one-word description of the action, for example, CppCompile or GoLink. |
-| `progress_message` | [string](../core/string); or `None`; default is `None`  Progress message to show to the user during the build, for example, "Compiling foo.cc to create foo.o". The message may contain `%{label}`, `%{input}`, or `%{output}` patterns, which are substituted with label string, first input, or output's path, respectively. Prefer to use patterns instead of static strings, because the former are more efficient. |
-| `use_default_shell_env` | [bool](../core/bool); default is `False`  Whether the action should use the default shell environment, which consists of a few OS-dependent variables as well as variables set via [`--action_env`](/versions/8.4.2/reference/command-line-reference#flag--action_env). If both `use_default_shell_env` and `env` are set to `True`, values set in `env` will overwrite the default shell environment if [`--incompatible_merge_fixed_and_default_shell_env`](/versions/8.4.2/reference/command-line-reference#flag--incompatible_merge_fixed_and_default_shell_env) is enabled (default). If the flag is not enabled, `env` is ignored. |
-| `env` | [dict](../core/dict); or `None`; default is `None`  Sets the dictionary of environment variables. If both `use_default_shell_env` and `env` are set to `True`, values set in `env` will overwrite the default shell environment if [`--incompatible_merge_fixed_and_default_shell_env`](/versions/8.4.2/reference/command-line-reference#flag--incompatible_merge_fixed_and_default_shell_env) is enabled (default). If the flag is not enabled, `env` is ignored. |
-| `execution_requirements` | [dict](../core/dict); or `None`; default is `None`  Information for scheduling the action. See [tags](/versions/8.4.2/reference/be/common-definitions#common.tags) for useful keys. |
-| `input_manifests` | [sequence](../core/list); or `None`; default is `None`  Legacy argument. Ignored. |
-| `exec_group` | [string](../core/string); or `None`; default is `None`  Runs the action on the given exec group's execution platform. If none, uses the target's default execution platform. |
-| `shadowed_action` | [Action](../builtins/Action); default is `None`  Runs the action using the given shadowed action's inputs and environment added to the action's inputs list and environment. The action environment can overwrite any of the shadowed action's environment variables. If none, uses only the action's inputs and given environment. |
+| `outputs` | [sequence](/versions/8.4.2/rules/lib/core/list) of [File](/versions/8.4.2/rules/lib/builtins/File)s; required  List of the output files of the action. |
+| `inputs` | [sequence](/versions/8.4.2/rules/lib/core/list) of [File](/versions/8.4.2/rules/lib/builtins/File)s; or [depset](/versions/8.4.2/rules/lib/builtins/depset); default is `[]`  List or depset of the input files of the action. |
+| `unused_inputs_list` | [File](/versions/8.4.2/rules/lib/builtins/File); or `None`; default is `None`  File containing list of inputs unused by the action. The content of this file (generally one of the outputs of the action) corresponds to the list of input files that were not used during the whole action execution. Any change in those files must not affect in any way the outputs of the action. |
+| `executable` | [File](/versions/8.4.2/rules/lib/builtins/File); or [string](/versions/8.4.2/rules/lib/core/string); or [FilesToRunProvider](/versions/8.4.2/rules/lib/providers/FilesToRunProvider); required  The executable file to be called by the action. |
+| `tools` | [sequence](/versions/8.4.2/rules/lib/core/list); or [depset](/versions/8.4.2/rules/lib/builtins/depset); default is `unbound`  List or depset of any tools needed by the action. Tools are inputs with additional runfiles that are automatically made available to the action. When a list is provided, it can be a heterogenous collection of Files, FilesToRunProvider instances, or depsets of Files. Files which are directly in the list and come from ctx.executable will have their runfiles automatically added. When a depset is provided, it must contain only Files. In both cases, files within depsets are not cross-referenced with ctx.executable for runfiles. |
+| `arguments` | [sequence](/versions/8.4.2/rules/lib/core/list); default is `[]`  Command line arguments of the action. Must be a list of strings or [`actions.args()`](#args) objects. |
+| `mnemonic` | [string](/versions/8.4.2/rules/lib/core/string); or `None`; default is `None`  A one-word description of the action, for example, CppCompile or GoLink. |
+| `progress_message` | [string](/versions/8.4.2/rules/lib/core/string); or `None`; default is `None`  Progress message to show to the user during the build, for example, "Compiling foo.cc to create foo.o". The message may contain `%{label}`, `%{input}`, or `%{output}` patterns, which are substituted with label string, first input, or output's path, respectively. Prefer to use patterns instead of static strings, because the former are more efficient. |
+| `use_default_shell_env` | [bool](/versions/8.4.2/rules/lib/core/bool); default is `False`  Whether the action should use the default shell environment, which consists of a few OS-dependent variables as well as variables set via [`--action_env`](/versions/8.4.2/reference/command-line-reference#flag--action_env). If both `use_default_shell_env` and `env` are set to `True`, values set in `env` will overwrite the default shell environment if [`--incompatible_merge_fixed_and_default_shell_env`](/versions/8.4.2/reference/command-line-reference#flag--incompatible_merge_fixed_and_default_shell_env) is enabled (default). If the flag is not enabled, `env` is ignored. |
+| `env` | [dict](/versions/8.4.2/rules/lib/core/dict); or `None`; default is `None`  Sets the dictionary of environment variables. If both `use_default_shell_env` and `env` are set to `True`, values set in `env` will overwrite the default shell environment if [`--incompatible_merge_fixed_and_default_shell_env`](/versions/8.4.2/reference/command-line-reference#flag--incompatible_merge_fixed_and_default_shell_env) is enabled (default). If the flag is not enabled, `env` is ignored. |
+| `execution_requirements` | [dict](/versions/8.4.2/rules/lib/core/dict); or `None`; default is `None`  Information for scheduling the action. See [tags](/versions/8.4.2/reference/be/common-definitions#common.tags) for useful keys. |
+| `input_manifests` | [sequence](/versions/8.4.2/rules/lib/core/list); or `None`; default is `None`  Legacy argument. Ignored. |
+| `exec_group` | [string](/versions/8.4.2/rules/lib/core/string); or `None`; default is `None`  Runs the action on the given exec group's execution platform. If none, uses the target's default execution platform. |
+| `shadowed_action` | [Action](/versions/8.4.2/rules/lib/builtins/Action); default is `None`  Runs the action using the given shadowed action's inputs and environment added to the action's inputs list and environment. The action environment can overwrite any of the shadowed action's environment variables. If none, uses only the action's inputs and given environment. |
 | `resource_set` | callable; or `None`; default is `None`  A callback function that returns a resource set dictionary, used to estimate resource usage at execution time if this action is run locally. The function accepts two positional arguments: a string representing an OS name (e.g. "osx"), and an integer representing the number of inputs to the action. The returned dictionary may contain the following entries, each of which may be a float or an int:  * "cpu": number of CPUs; default 1* "memory": in MB; default 250* "local\_test": number of local tests; default 1   If this parameter is set to `None` , the default values are used. The callback must be top-level (lambda and nested functions aren't allowed). |
-| `toolchain` | [Label](../builtins/Label); or [string](../core/string); or `None`; default is `unbound`  Toolchain type of the executable or tools used in this action.  If executable and tools are not coming from a toolchain, set this parameter to `None`.  If executable and tools are coming from a toolchain, toolchain type must be set so that the action executes on the correct execution platform.  Note that the rule which creates this action needs to define this toolchain inside its 'rule()' function.  When `toolchain` and `exec\_group` parameters are both set, `exec\_group` will be used. An error is raised in case the `exec\_group` doesn't specify the same toolchain. |
+| `toolchain` | [Label](/versions/8.4.2/rules/lib/builtins/Label); or [string](/versions/8.4.2/rules/lib/core/string); or `None`; default is `unbound`  Toolchain type of the executable or tools used in this action.  If executable and tools are not coming from a toolchain, set this parameter to `None`.  If executable and tools are coming from a toolchain, toolchain type must be set so that the action executes on the correct execution platform.  Note that the rule which creates this action needs to define this toolchain inside its 'rule()' function.  When `toolchain` and `exec\_group` parameters are both set, `exec\_group` will be used. An error is raised in case the `exec\_group` doesn't specify the same toolchain. |
 
 ## run\_shell
 
@@ -149,21 +149,21 @@ Creates an action that runs a shell command. [See example of use](https://github
 
 | Parameter | Description |
 | --- | --- |
-| `outputs` | [sequence](../core/list) of [File](../builtins/File)s; required  List of the output files of the action. |
-| `inputs` | [sequence](../core/list) of [File](../builtins/File)s; or [depset](../builtins/depset); default is `[]`  List or depset of the input files of the action. |
-| `tools` | [sequence](../core/list) of [File](../builtins/File)s; or [depset](../builtins/depset); default is `unbound`  List or depset of any tools needed by the action. Tools are inputs with additional runfiles that are automatically made available to the action. The list can contain Files or FilesToRunProvider instances. |
-| `arguments` | [sequence](../core/list); default is `[]`  Command line arguments of the action. Must be a list of strings or [`actions.args()`](#args) objects. Bazel passes the elements in this attribute as arguments to the command.The command can access these arguments using shell variable substitutions such as `$1`, `$2`, etc. Note that since Args objects are flattened before indexing, if there is an Args object of unknown size then all subsequent strings will be at unpredictable indices. It may be useful to use `$@` (to retrieve all arguments) in conjunction with Args objects of indeterminate size. In the case where `command` is a list of strings, this parameter may not be used. |
-| `mnemonic` | [string](../core/string); or `None`; default is `None`  A one-word description of the action, for example, CppCompile or GoLink. |
-| `command` | [string](../core/string); or [sequence](../core/list) of [string](../core/string)s; required  Shell command to execute. This may either be a string (preferred) or a sequence of strings **(deprecated)**. If `command` is a string, then it is executed as if by `sh -c  "" ` -- that is, the elements in `arguments` are made available to the command as `$1`, `$2` (or `%1`, `%2` if using Windows batch), etc. If `arguments` contains any [`actions.args()`](#args) objects, their contents are appended one by one to the command line, so `$`*i* can refer to individual strings within an Args object. Note that if an Args object of unknown size is passed as part of `arguments`, then the strings will be at unknown indices; in this case the `$@` shell substitution (retrieve all arguments) may be useful. **(Deprecated)** If `command` is a sequence of strings, the first item is the executable to run and the remaining items are its arguments. If this form is used, the `arguments` parameter must not be supplied. *Note that this form is deprecated and will soon be removed. It is disabled with `--incompatible\_run\_shell\_command\_string`. Use this flag to verify your code is compatible.*  Bazel uses the same shell to execute the command as it does for genrules. |
-| `progress_message` | [string](../core/string); or `None`; default is `None`  Progress message to show to the user during the build, for example, "Compiling foo.cc to create foo.o". The message may contain `%{label}`, `%{input}`, or `%{output}` patterns, which are substituted with label string, first input, or output's path, respectively. Prefer to use patterns instead of static strings, because the former are more efficient. |
-| `use_default_shell_env` | [bool](../core/bool); default is `False`  Whether the action should use the default shell environment, which consists of a few OS-dependent variables as well as variables set via [`--action_env`](/versions/8.4.2/reference/command-line-reference#flag--action_env). If both `use_default_shell_env` and `env` are set to `True`, values set in `env` will overwrite the default shell environment if [`--incompatible_merge_fixed_and_default_shell_env`](/versions/8.4.2/reference/command-line-reference#flag--incompatible_merge_fixed_and_default_shell_env) is enabled (default). If the flag is not enabled, `env` is ignored. |
-| `env` | [dict](../core/dict); or `None`; default is `None`  Sets the dictionary of environment variables. If both `use_default_shell_env` and `env` are set to `True`, values set in `env` will overwrite the default shell environment if [`--incompatible_merge_fixed_and_default_shell_env`](/versions/8.4.2/reference/command-line-reference#flag--incompatible_merge_fixed_and_default_shell_env) is enabled (default). If the flag is not enabled, `env` is ignored. |
-| `execution_requirements` | [dict](../core/dict); or `None`; default is `None`  Information for scheduling the action. See [tags](/versions/8.4.2/reference/be/common-definitions#common.tags) for useful keys. |
-| `input_manifests` | [sequence](../core/list); or `None`; default is `None`  Legacy argument. Ignored. |
-| `exec_group` | [string](../core/string); or `None`; default is `None`  Runs the action on the given exec group's execution platform. If none, uses the target's default execution platform. |
-| `shadowed_action` | [Action](../builtins/Action); default is `None`  Runs the action using the given shadowed action's discovered inputs added to the action's inputs list. If none, uses only the action's inputs. |
+| `outputs` | [sequence](/versions/8.4.2/rules/lib/core/list) of [File](/versions/8.4.2/rules/lib/builtins/File)s; required  List of the output files of the action. |
+| `inputs` | [sequence](/versions/8.4.2/rules/lib/core/list) of [File](/versions/8.4.2/rules/lib/builtins/File)s; or [depset](/versions/8.4.2/rules/lib/builtins/depset); default is `[]`  List or depset of the input files of the action. |
+| `tools` | [sequence](/versions/8.4.2/rules/lib/core/list) of [File](/versions/8.4.2/rules/lib/builtins/File)s; or [depset](/versions/8.4.2/rules/lib/builtins/depset); default is `unbound`  List or depset of any tools needed by the action. Tools are inputs with additional runfiles that are automatically made available to the action. The list can contain Files or FilesToRunProvider instances. |
+| `arguments` | [sequence](/versions/8.4.2/rules/lib/core/list); default is `[]`  Command line arguments of the action. Must be a list of strings or [`actions.args()`](#args) objects. Bazel passes the elements in this attribute as arguments to the command.The command can access these arguments using shell variable substitutions such as `$1`, `$2`, etc. Note that since Args objects are flattened before indexing, if there is an Args object of unknown size then all subsequent strings will be at unpredictable indices. It may be useful to use `$@` (to retrieve all arguments) in conjunction with Args objects of indeterminate size. In the case where `command` is a list of strings, this parameter may not be used. |
+| `mnemonic` | [string](/versions/8.4.2/rules/lib/core/string); or `None`; default is `None`  A one-word description of the action, for example, CppCompile or GoLink. |
+| `command` | [string](/versions/8.4.2/rules/lib/core/string); or [sequence](/versions/8.4.2/rules/lib/core/list) of [string](/versions/8.4.2/rules/lib/core/string)s; required  Shell command to execute. This may either be a string (preferred) or a sequence of strings **(deprecated)**. If `command` is a string, then it is executed as if by `sh -c  "" ` -- that is, the elements in `arguments` are made available to the command as `$1`, `$2` (or `%1`, `%2` if using Windows batch), etc. If `arguments` contains any [`actions.args()`](#args) objects, their contents are appended one by one to the command line, so `$`*i* can refer to individual strings within an Args object. Note that if an Args object of unknown size is passed as part of `arguments`, then the strings will be at unknown indices; in this case the `$@` shell substitution (retrieve all arguments) may be useful. **(Deprecated)** If `command` is a sequence of strings, the first item is the executable to run and the remaining items are its arguments. If this form is used, the `arguments` parameter must not be supplied. *Note that this form is deprecated and will soon be removed. It is disabled with `--incompatible\_run\_shell\_command\_string`. Use this flag to verify your code is compatible.*  Bazel uses the same shell to execute the command as it does for genrules. |
+| `progress_message` | [string](/versions/8.4.2/rules/lib/core/string); or `None`; default is `None`  Progress message to show to the user during the build, for example, "Compiling foo.cc to create foo.o". The message may contain `%{label}`, `%{input}`, or `%{output}` patterns, which are substituted with label string, first input, or output's path, respectively. Prefer to use patterns instead of static strings, because the former are more efficient. |
+| `use_default_shell_env` | [bool](/versions/8.4.2/rules/lib/core/bool); default is `False`  Whether the action should use the default shell environment, which consists of a few OS-dependent variables as well as variables set via [`--action_env`](/versions/8.4.2/reference/command-line-reference#flag--action_env). If both `use_default_shell_env` and `env` are set to `True`, values set in `env` will overwrite the default shell environment if [`--incompatible_merge_fixed_and_default_shell_env`](/versions/8.4.2/reference/command-line-reference#flag--incompatible_merge_fixed_and_default_shell_env) is enabled (default). If the flag is not enabled, `env` is ignored. |
+| `env` | [dict](/versions/8.4.2/rules/lib/core/dict); or `None`; default is `None`  Sets the dictionary of environment variables. If both `use_default_shell_env` and `env` are set to `True`, values set in `env` will overwrite the default shell environment if [`--incompatible_merge_fixed_and_default_shell_env`](/versions/8.4.2/reference/command-line-reference#flag--incompatible_merge_fixed_and_default_shell_env) is enabled (default). If the flag is not enabled, `env` is ignored. |
+| `execution_requirements` | [dict](/versions/8.4.2/rules/lib/core/dict); or `None`; default is `None`  Information for scheduling the action. See [tags](/versions/8.4.2/reference/be/common-definitions#common.tags) for useful keys. |
+| `input_manifests` | [sequence](/versions/8.4.2/rules/lib/core/list); or `None`; default is `None`  Legacy argument. Ignored. |
+| `exec_group` | [string](/versions/8.4.2/rules/lib/core/string); or `None`; default is `None`  Runs the action on the given exec group's execution platform. If none, uses the target's default execution platform. |
+| `shadowed_action` | [Action](/versions/8.4.2/rules/lib/builtins/Action); default is `None`  Runs the action using the given shadowed action's discovered inputs added to the action's inputs list. If none, uses only the action's inputs. |
 | `resource_set` | callable; or `None`; default is `None`  A callback function for estimating resource usage if run locally. See[`ctx.actions.run()`](#run.resource_set). |
-| `toolchain` | [Label](../builtins/Label); or [string](../core/string); or `None`; default is `unbound`  Toolchain type of the executable or tools used in this action.  If executable and tools are not coming from a toolchain, set this parameter to `None`.  If executable and tools are coming from a toolchain, toolchain type must be set so that the action executes on the correct execution platform.  Note that the rule which creates this action needs to define this toolchain inside its 'rule()' function.  When `toolchain` and `exec\_group` parameters are both set, `exec\_group` will be used. An error is raised in case the `exec\_group` doesn't specify the same toolchain. |
+| `toolchain` | [Label](/versions/8.4.2/rules/lib/builtins/Label); or [string](/versions/8.4.2/rules/lib/core/string); or `None`; default is `unbound`  Toolchain type of the executable or tools used in this action.  If executable and tools are not coming from a toolchain, set this parameter to `None`.  If executable and tools are coming from a toolchain, toolchain type must be set so that the action executes on the correct execution platform.  Note that the rule which creates this action needs to define this toolchain inside its 'rule()' function.  When `toolchain` and `exec\_group` parameters are both set, `exec\_group` will be used. An error is raised in case the `exec\_group` doesn't specify the same toolchain. |
 
 ## symlink
 
@@ -183,11 +183,11 @@ Otherwise, when you use `target_path`, declare `output` with [`declare_symlink()
 
 | Parameter | Description |
 | --- | --- |
-| `output` | [File](../builtins/File); required  The output of this action. |
-| `target_file` | [File](../builtins/File); or `None`; default is `None`  The File that the output symlink will point to. |
-| `target_path` | [string](../core/string); or `None`; default is `None`  The exact path that the output symlink will point to. No normalization or other processing is applied. |
-| `is_executable` | [bool](../core/bool); default is `False`  May only be used with `target_file`, not `target_path`. If true, when the action is executed, the `target_file`'s path is checked to confirm that it is executable, and an error is reported if it is not. Setting `is_executable` to False does not mean the target is not executable, just that no verification is done. This feature does not make sense for `target_path` because dangling symlinks might not exist at build time. |
-| `progress_message` | [string](../core/string); or `None`; default is `None`  Progress message to show to the user during the build. |
+| `output` | [File](/versions/8.4.2/rules/lib/builtins/File); required  The output of this action. |
+| `target_file` | [File](/versions/8.4.2/rules/lib/builtins/File); or `None`; default is `None`  The File that the output symlink will point to. |
+| `target_path` | [string](/versions/8.4.2/rules/lib/core/string); or `None`; default is `None`  The exact path that the output symlink will point to. No normalization or other processing is applied. |
+| `is_executable` | [bool](/versions/8.4.2/rules/lib/core/bool); default is `False`  May only be used with `target_file`, not `target_path`. If true, when the action is executed, the `target_file`'s path is checked to confirm that it is executable, and an error is reported if it is not. Setting `is_executable` to False does not mean the target is not executable, just that no verification is done. This feature does not make sense for `target_path` because dangling symlinks might not exist at build time. |
+| `progress_message` | [string](/versions/8.4.2/rules/lib/core/string); or `None`; default is `None`  Progress message to show to the user during the build. |
 
 ## template\_dict
 
@@ -209,6 +209,6 @@ Creates a file write action. When the action is executed, it will write the give
 
 | Parameter | Description |
 | --- | --- |
-| `output` | [File](../builtins/File); required  The output file. |
-| `content` | [string](../core/string); or [Args](../builtins/Args); required  the contents of the file. May be a either a string or an [`actions.args()`](#args) object. |
-| `is_executable` | [bool](../core/bool); default is `False`  Whether the output file should be executable. |
\ No newline at end of file
+| `output` | [File](/versions/8.4.2/rules/lib/builtins/File); required  The output file. |
+| `content` | [string](/versions/8.4.2/rules/lib/core/string); or [Args](/versions/8.4.2/rules/lib/builtins/Args); required  the contents of the file. May be a either a string or an [`actions.args()`](#args) object. |
+| `is_executable` | [bool](/versions/8.4.2/rules/lib/core/bool); default is `False`  Whether the output file should be executable. |
\ No newline at end of file
diff --git a/versions/8.4.2/rules/lib/builtins/apple_platform.mdx b/versions/8.4.2/rules/lib/builtins/apple_platform.mdx
index ba2fc42e..5cf68039 100644
--- a/versions/8.4.2/rules/lib/builtins/apple_platform.mdx
+++ b/versions/8.4.2/rules/lib/builtins/apple_platform.mdx
@@ -4,7 +4,7 @@ title: 'apple\_platform'
 
 Corresponds to Xcode's notion of a platform as would be found in `Xcode.app/Contents/Developer/Platforms`. Each platform represents an Apple platform type (such as iOS or tvOS) combined with one or more related CPU architectures. For example, the iOS simulator platform supports `x86_64` and `i386` architectures.
 
-Specific instances of this type can be retrieved from the fields of the [apple\_common.platform](../toplevel/apple_common#platform) struct:
+Specific instances of this type can be retrieved from the fields of the [apple\_common.platform](/versions/8.4.2/rules/lib/toplevel/apple_common#platform) struct:
 
 * `apple_common.platform.ios_device`
 * `apple_common.platform.ios_simulator`
@@ -14,7 +14,7 @@ Specific instances of this type can be retrieved from the fields of the [apple\_
 * `apple_common.platform.watchos_device`
 * `apple_common.platform.watchos_simulator`
 
-More commonly, however, the [apple](../fragments/apple) configuration fragment has fields/methods that allow rules to determine the platform for which a target is being built.
+More commonly, however, the [apple](/versions/8.4.2/rules/lib/fragments/apple) configuration fragment has fields/methods that allow rules to determine the platform for which a target is being built.
 
 Example:
 
diff --git a/versions/8.4.2/rules/lib/builtins/configuration.mdx b/versions/8.4.2/rules/lib/builtins/configuration.mdx
index e5226191..24bc15d9 100644
--- a/versions/8.4.2/rules/lib/builtins/configuration.mdx
+++ b/versions/8.4.2/rules/lib/builtins/configuration.mdx
@@ -17,7 +17,7 @@ This object holds information about the environment in which the build is runnin
 bool configuration.coverage_enabled
 ```
 
-A boolean that tells whether code coverage is enabled for this run. Note that this does not compute whether a specific rule should be instrumented for code coverage data collection. For that, see the [`ctx.coverage_instrumented`](../builtins/ctx#coverage_instrumented) function.
+A boolean that tells whether code coverage is enabled for this run. Note that this does not compute whether a specific rule should be instrumented for code coverage data collection. For that, see the [`ctx.coverage_instrumented`](/versions/8.4.2/rules/lib/builtins/ctx#coverage_instrumented) function.
 
 ## default\_shell\_env
 
diff --git a/versions/8.4.2/rules/lib/builtins/ctx.mdx b/versions/8.4.2/rules/lib/builtins/ctx.mdx
index 43e10a16..b9c192ee 100644
--- a/versions/8.4.2/rules/lib/builtins/ctx.mdx
+++ b/versions/8.4.2/rules/lib/builtins/ctx.mdx
@@ -66,7 +66,7 @@ A list of ids for all aspects applied to the target. Only available in aspect im
 struct ctx.attr
 ```
 
-A struct to access the values of the [attributes](https://bazel.build/versions/8.4.2/extending/rules#attributes). The values are provided by the user (if not, a default value is used). The attributes of the struct and the types of their values correspond to the keys and values of the [`attrs` dict](../globals/bzl#rule.attrs) provided to the [`rule` function](../globals/bzl#rule). [See example of use](https://github.com/bazelbuild/examples/blob/main/rules/attributes/printer.bzl).
+A struct to access the values of the [attributes](https://bazel.build/versions/8.4.2/extending/rules#attributes). The values are provided by the user (if not, a default value is used). The attributes of the struct and the types of their values correspond to the keys and values of the [`attrs` dict](/versions/8.4.2/rules/lib/globals/bzl#rule.attrs) provided to the [`rule` function](/versions/8.4.2/rules/lib/globals/bzl#rule). [See example of use](https://github.com/bazelbuild/examples/blob/main/rules/attributes/printer.bzl).
 
 ## bin\_dir
 
@@ -98,7 +98,7 @@ Value of the build setting represented by the current target. If this isn't the
 configuration ctx.configuration
 ```
 
-The default configuration. See the [configuration](../builtins/configuration) type for more details.
+The default configuration. See the [configuration](/versions/8.4.2/rules/lib/builtins/configuration) type for more details.
 
 ## coverage\_instrumented
 
@@ -106,13 +106,13 @@ The default configuration. See the [configuration](../builtins/configuration) ty
 bool ctx.coverage_instrumented(target=None)
 ```
 
-Returns whether code coverage instrumentation should be generated when performing compilation actions for this rule or, if `target` is provided, the rule specified by that Target. (If a non-rule or a Starlark rule Target is provided, this returns False.) Checks if the sources of the current rule (if no Target is provided) or the sources of Target should be instrumented based on the --instrumentation\_filter and --instrument\_test\_targets config settings. This differs from `coverage_enabled` in the [configuration](../builtins/configuration), which notes whether coverage data collection is enabled for the entire run, but not whether a specific target should be instrumented.
+Returns whether code coverage instrumentation should be generated when performing compilation actions for this rule or, if `target` is provided, the rule specified by that Target. (If a non-rule or a Starlark rule Target is provided, this returns False.) Checks if the sources of the current rule (if no Target is provided) or the sources of Target should be instrumented based on the --instrumentation\_filter and --instrument\_test\_targets config settings. This differs from `coverage_enabled` in the [configuration](/versions/8.4.2/rules/lib/builtins/configuration), which notes whether coverage data collection is enabled for the entire run, but not whether a specific target should be instrumented.
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `target` | [Target](../builtins/Target); or `None`; default is `None`  A Target specifying a rule. If not provided, defaults to the current rule. |
+| `target` | [Target](/versions/8.4.2/rules/lib/builtins/Target); or `None`; default is `None`  A Target specifying a rule. If not provided, defaults to the current rule. |
 
 ## created\_actions
 
@@ -120,7 +120,7 @@ Returns whether code coverage instrumentation should be generated when performin
 StarlarkValue ctx.created_actions()
 ```
 
-For rules with [\_skylark\_testable](../globals/bzl#rule._skylark_testable) set to `True`, this returns an `Actions` provider representing all actions created so far for the current rule. For all other rules, returns `None`. Note that the provider is not updated when subsequent actions are created, so you will have to call this function again if you wish to inspect them.
+For rules with [\_skylark\_testable](/versions/8.4.2/rules/lib/globals/bzl#rule._skylark_testable) set to `True`, this returns an `Actions` provider representing all actions created so far for the current rule. For all other rules, returns `None`. Note that the provider is not updated when subsequent actions are created, so you will have to call this function again if you wish to inspect them.
 
 This is intended to help write tests for rule-implementation helper functions, which may take in a `ctx` object and create actions on it.
 
@@ -146,7 +146,7 @@ A collection of the execution groups available for this rule, indexed by their n
 struct ctx.executable
 ```
 
-A `struct` containing executable files defined in [label type attributes](../toplevel/attr#label) marked as [`executable=True`](../toplevel/attr#label.executable). The struct fields correspond to the attribute names. Each value in the struct is either a [`File`](../builtins/File) or `None`. If an optional attribute is not specified in the rule then the corresponding struct value is `None`. If a label type is not marked as `executable=True`, no corresponding struct field is generated. [See example of use](https://github.com/bazelbuild/examples/blob/main/rules/actions_run/execute.bzl).
+A `struct` containing executable files defined in [label type attributes](/versions/8.4.2/rules/lib/toplevel/attr#label) marked as [`executable=True`](/versions/8.4.2/rules/lib/toplevel/attr#label.executable). The struct fields correspond to the attribute names. Each value in the struct is either a [`File`](/versions/8.4.2/rules/lib/builtins/File) or `None`. If an optional attribute is not specified in the rule then the corresponding struct value is `None`. If a label type is not marked as `executable=True`, no corresponding struct field is generated. [See example of use](https://github.com/bazelbuild/examples/blob/main/rules/actions_run/execute.bzl).
 
 ## expand\_location
 
@@ -164,8 +164,8 @@ This function is useful to let the user specify a command in a BUILD file (like
 
 | Parameter | Description |
 | --- | --- |
-| `input` | [string](../core/string); required  String to be expanded. |
-| `targets` | [sequence](../core/list) of [Target](../builtins/Target)s; default is `[]`  List of targets for additional lookup information. These are expanded as follows: A target with a single file in `DefaultInfo.files` expands to that file. Other targets expand to their `DefaultInfo.executable` file if set and if `--incompatible_locations_prefers_executable` is enabled, otherwise they expand to `DefaultInfo.files`. |
+| `input` | [string](/versions/8.4.2/rules/lib/core/string); required  String to be expanded. |
+| `targets` | [sequence](/versions/8.4.2/rules/lib/core/list) of [Target](/versions/8.4.2/rules/lib/builtins/Target)s; default is `[]`  List of targets for additional lookup information. These are expanded as follows: A target with a single file in `DefaultInfo.files` expands to that file. Other targets expand to their `DefaultInfo.executable` file if set and if `--incompatible_locations_prefers_executable` is enabled, otherwise they expand to `DefaultInfo.files`. |
 
 May return `None`.
 
@@ -175,7 +175,7 @@ May return `None`.
 string ctx.expand_make_variables(attribute_name, command, additional_substitutions)
 ```
 
-**Deprecated.** Use [ctx.var](../builtins/ctx#var) to access the variables instead.
+**Deprecated.** Use [ctx.var](/versions/8.4.2/rules/lib/builtins/ctx#var) to access the variables instead.
 Returns a string after expanding all references to "Make variables". The variables must have the following format: `$(VAR_NAME)`. Also, `$$VAR_NAME` expands to `$VAR_NAME`. Examples:
 
 ```
@@ -189,9 +189,9 @@ Additional variables may come from other places, such as configurations. Note th
 
 | Parameter | Description |
 | --- | --- |
-| `attribute_name` | [string](../core/string); required |
-| `command` | [string](../core/string); required  The expression to expand. It can contain references to "Make variables". |
-| `additional_substitutions` | [dict](../core/dict); required  Additional substitutions to make beyond the default make variables. |
+| `attribute_name` | [string](/versions/8.4.2/rules/lib/core/string); required |
+| `command` | [string](/versions/8.4.2/rules/lib/core/string); required  The expression to expand. It can contain references to "Make variables". |
+| `additional_substitutions` | [dict](/versions/8.4.2/rules/lib/core/dict); required  Additional substitutions to make beyond the default make variables. |
 
 ## features
 
@@ -207,7 +207,7 @@ The set of features that are explicitly enabled by the user for this rule. [See
 struct ctx.file
 ```
 
-A `struct` containing files defined in [label type attributes](../toplevel/attr#label) marked as [`allow_single_file`](../toplevel/attr#label.allow_single_file). The struct fields correspond to the attribute names. The struct value is always a [`File`](../builtins/File) or `None`. If an optional attribute is not specified in the rule then the corresponding struct value is `None`. If a label type is not marked as `allow_single_file`, no corresponding struct field is generated. It is a shortcut for:
+A `struct` containing files defined in [label type attributes](/versions/8.4.2/rules/lib/toplevel/attr#label) marked as [`allow_single_file`](/versions/8.4.2/rules/lib/toplevel/attr#label.allow_single_file). The struct fields correspond to the attribute names. The struct value is always a [`File`](/versions/8.4.2/rules/lib/builtins/File) or `None`. If an optional attribute is not specified in the rule then the corresponding struct value is `None`. If a label type is not marked as `allow_single_file`, no corresponding struct field is generated. It is a shortcut for:
 
 ```
 list(ctx.attr..files)[0]
@@ -221,7 +221,7 @@ In other words, use `file` to access the (singular) [default output](https://baz
 struct ctx.files
 ```
 
-A `struct` containing files defined in [label](../toplevel/attr#label) or [label list](../toplevel/attr#label_list) type attributes. The struct fields correspond to the attribute names. The struct values are `list` of [`File`](../builtins/File)s. It is a shortcut for:
+A `struct` containing files defined in [label](/versions/8.4.2/rules/lib/toplevel/attr#label) or [label list](/versions/8.4.2/rules/lib/toplevel/attr#label_list) type attributes. The struct fields correspond to the attribute names. The struct values are `list` of [`File`](/versions/8.4.2/rules/lib/builtins/File)s. It is a shortcut for:
 
 ```
 [f for t in ctx.attr. for f in t.files]
@@ -267,13 +267,13 @@ The label of the target currently being analyzed.
 structure ctx.outputs
 ```
 
-A pseudo-struct containing all the predeclared output files, represented by [`File`](../builtins/File) objects. See the [Rules page](https://bazel.build/versions/8.4.2/extending/rules#files) for more information and examples.
+A pseudo-struct containing all the predeclared output files, represented by [`File`](/versions/8.4.2/rules/lib/builtins/File) objects. See the [Rules page](https://bazel.build/versions/8.4.2/extending/rules#files) for more information and examples.
 
 This field does not exist on aspect contexts, since aspects do not have predeclared outputs.
 
 The fields of this object are defined as follows. It is an error if two outputs produce the same field name or have the same label.
 
-* If the rule declares an [`outputs`](../globals/bzl#rule.outputs) dict, then for every entry in the dict, there is a field whose name is the key and whose value is the corresponding `File`.* For every attribute of type [`attr.output`](../toplevel/attr#output) that the rule declares, there is a field whose name is the attribute's name. If the target specified a label for that attribute, then the field value is the corresponding `File`; otherwise the field value is `None`.* For every attribute of type [`attr.output_list`](../toplevel/attr#output_list) that the rule declares, there is a field whose name is the attribute's name. The field value is a list of `File` objects corresponding to the labels given for that attribute in the target, or an empty list if the attribute was not specified in the target.* **(Deprecated)** If the rule is marked [`executable`](../globals/bzl#rule.executable) or [`test`](../globals/bzl#rule.test), there is a field named `"executable"`, which is the default executable. It is recommended that instead of using this, you pass another file (either predeclared or not) to the `executable` arg of [`DefaultInfo`](../providers/DefaultInfo).
+* If the rule declares an [`outputs`](/versions/8.4.2/rules/lib/globals/bzl#rule.outputs) dict, then for every entry in the dict, there is a field whose name is the key and whose value is the corresponding `File`.* For every attribute of type [`attr.output`](/versions/8.4.2/rules/lib/toplevel/attr#output) that the rule declares, there is a field whose name is the attribute's name. If the target specified a label for that attribute, then the field value is the corresponding `File`; otherwise the field value is `None`.* For every attribute of type [`attr.output_list`](/versions/8.4.2/rules/lib/toplevel/attr#output_list) that the rule declares, there is a field whose name is the attribute's name. The field value is a list of `File` objects corresponding to the labels given for that attribute in the target, or an empty list if the attribute was not specified in the target.* **(Deprecated)** If the rule is marked [`executable`](/versions/8.4.2/rules/lib/globals/bzl#rule.executable) or [`test`](/versions/8.4.2/rules/lib/globals/bzl#rule.test), there is a field named `"executable"`, which is the default executable. It is recommended that instead of using this, you pass another file (either predeclared or not) to the `executable` arg of [`DefaultInfo`](/versions/8.4.2/rules/lib/providers/DefaultInfo).
 
 ## resolve\_command
 
@@ -288,13 +288,13 @@ tuple ctx.resolve_command(command='', attribute=None, expand_locations=False, ma
 
 | Parameter | Description |
 | --- | --- |
-| `command` | [string](../core/string); default is `''`  Command to resolve. |
-| `attribute` | [string](../core/string); or `None`; default is `None`  Name of the associated attribute for which to issue an error, or None. |
-| `expand_locations` | [bool](../core/bool); default is `False`  Shall we expand $(location) variables? See [ctx.expand\_location()](#expand_location) for more details. |
-| `make_variables` | [dict](../core/dict); or `None`; default is `None`  Make variables to expand, or None. |
-| `tools` | [sequence](../core/list) of [Target](../builtins/Target)s; default is `[]`  List of tools (list of targets). |
-| `label_dict` | [dict](../core/dict); default is `{}`  Dictionary of resolved labels and the corresponding list of Files (a dict of Label : list of Files). |
-| `execution_requirements` | [dict](../core/dict); default is `{}`  Information for scheduling the action to resolve this command. See [tags](/versions/8.4.2/reference/be/common-definitions#common.tags) for useful keys. |
+| `command` | [string](/versions/8.4.2/rules/lib/core/string); default is `''`  Command to resolve. |
+| `attribute` | [string](/versions/8.4.2/rules/lib/core/string); or `None`; default is `None`  Name of the associated attribute for which to issue an error, or None. |
+| `expand_locations` | [bool](/versions/8.4.2/rules/lib/core/bool); default is `False`  Shall we expand $(location) variables? See [ctx.expand\_location()](#expand_location) for more details. |
+| `make_variables` | [dict](/versions/8.4.2/rules/lib/core/dict); or `None`; default is `None`  Make variables to expand, or None. |
+| `tools` | [sequence](/versions/8.4.2/rules/lib/core/list) of [Target](/versions/8.4.2/rules/lib/builtins/Target)s; default is `[]`  List of tools (list of targets). |
+| `label_dict` | [dict](/versions/8.4.2/rules/lib/core/dict); default is `{}`  Dictionary of resolved labels and the corresponding list of Files (a dict of Label : list of Files). |
+| `execution_requirements` | [dict](/versions/8.4.2/rules/lib/core/dict); default is `{}`  Information for scheduling the action to resolve this command. See [tags](/versions/8.4.2/reference/be/common-definitions#common.tags) for useful keys. |
 
 ## resolve\_tools
 
@@ -310,7 +310,7 @@ In contrast to `ctx.resolve_command`, this method does not require that Bash be
 
 | Parameter | Description |
 | --- | --- |
-| `tools` | [sequence](../core/list) of [Target](../builtins/Target)s; default is `[]`  List of tools (list of targets). |
+| `tools` | [sequence](/versions/8.4.2/rules/lib/core/list) of [Target](/versions/8.4.2/rules/lib/builtins/Target)s; default is `[]`  List of tools (list of targets). |
 
 ## rule
 
@@ -332,12 +332,12 @@ Creates a runfiles object.
 
 | Parameter | Description |
 | --- | --- |
-| `files` | [sequence](../core/list) of [File](../builtins/File)s; default is `[]`  The list of files to be added to the runfiles. |
-| `transitive_files` | [depset](../builtins/depset) of [File](../builtins/File)s; or `None`; default is `None`  The (transitive) set of files to be added to the runfiles. The depset should use the `default` order (which, as the name implies, is the default). |
-| `collect_data` | [bool](../core/bool); default is `False`  **Use of this parameter is not recommended. See [runfiles guide](https://bazel.build/versions/8.4.2/extending/rules#runfiles)**. Whether to collect the data runfiles from the dependencies in srcs, data and deps attributes. |
-| `collect_default` | [bool](../core/bool); default is `False`  **Use of this parameter is not recommended. See [runfiles guide](https://bazel.build/versions/8.4.2/extending/rules#runfiles)**. Whether to collect the default runfiles from the dependencies in srcs, data and deps attributes. |
-| `symlinks` | [dict](../core/dict); or [depset](../builtins/depset) of [SymlinkEntry](../builtins/SymlinkEntry)s; default is `{}`  Either a SymlinkEntry depset or the map of symlinks to be added to the runfiles. Symlinks are always added under the main workspace's runfiles directory (e.g. `/_main/`, **not** the directory corresponding to the current target's repository. See [Runfiles symlinks](https://bazel.build/versions/8.4.2/extending/rules#runfiles_symlinks) in the rules guide. |
-| `root_symlinks` | [dict](../core/dict); or [depset](../builtins/depset) of [SymlinkEntry](../builtins/SymlinkEntry)s; default is `{}`  Either a SymlinkEntry depset or a map of symlinks to be added to the runfiles. See [Runfiles symlinks](https://bazel.build/versions/8.4.2/extending/rules#runfiles_symlinks) in the rules guide. |
+| `files` | [sequence](/versions/8.4.2/rules/lib/core/list) of [File](/versions/8.4.2/rules/lib/builtins/File)s; default is `[]`  The list of files to be added to the runfiles. |
+| `transitive_files` | [depset](/versions/8.4.2/rules/lib/builtins/depset) of [File](/versions/8.4.2/rules/lib/builtins/File)s; or `None`; default is `None`  The (transitive) set of files to be added to the runfiles. The depset should use the `default` order (which, as the name implies, is the default). |
+| `collect_data` | [bool](/versions/8.4.2/rules/lib/core/bool); default is `False`  **Use of this parameter is not recommended. See [runfiles guide](https://bazel.build/versions/8.4.2/extending/rules#runfiles)**. Whether to collect the data runfiles from the dependencies in srcs, data and deps attributes. |
+| `collect_default` | [bool](/versions/8.4.2/rules/lib/core/bool); default is `False`  **Use of this parameter is not recommended. See [runfiles guide](https://bazel.build/versions/8.4.2/extending/rules#runfiles)**. Whether to collect the default runfiles from the dependencies in srcs, data and deps attributes. |
+| `symlinks` | [dict](/versions/8.4.2/rules/lib/core/dict); or [depset](/versions/8.4.2/rules/lib/builtins/depset) of [SymlinkEntry](/versions/8.4.2/rules/lib/builtins/SymlinkEntry)s; default is `{}`  Either a SymlinkEntry depset or the map of symlinks to be added to the runfiles. Symlinks are always added under the main workspace's runfiles directory (e.g. `/_main/`, **not** the directory corresponding to the current target's repository. See [Runfiles symlinks](https://bazel.build/versions/8.4.2/extending/rules#runfiles_symlinks) in the rules guide. |
+| `root_symlinks` | [dict](/versions/8.4.2/rules/lib/core/dict); or [depset](/versions/8.4.2/rules/lib/builtins/depset) of [SymlinkEntry](/versions/8.4.2/rules/lib/builtins/SymlinkEntry)s; default is `{}`  Either a SymlinkEntry depset or a map of symlinks to be added to the runfiles. See [Runfiles symlinks](https://bazel.build/versions/8.4.2/extending/rules#runfiles_symlinks) in the rules guide. |
 
 ## split\_attr
 
@@ -367,7 +367,7 @@ Returns true if the given constraint value is part of the current target platfor
 
 | Parameter | Description |
 | --- | --- |
-| `constraintValue` | [ConstraintValueInfo](../providers/ConstraintValueInfo); required  The constraint value to check the target platform against. |
+| `constraintValue` | [ConstraintValueInfo](/versions/8.4.2/rules/lib/providers/ConstraintValueInfo); required  The constraint value to check the target platform against. |
 
 ## toolchains
 
diff --git a/versions/8.4.2/rules/lib/builtins/depset.mdx b/versions/8.4.2/rules/lib/builtins/depset.mdx
index e2eb7198..b4c397ba 100644
--- a/versions/8.4.2/rules/lib/builtins/depset.mdx
+++ b/versions/8.4.2/rules/lib/builtins/depset.mdx
@@ -6,7 +6,7 @@ A specialized data structure that supports efficient merge operations and has a
 
 The elements of a depset must be hashable and all of the same type (as defined by the built-in type(x) function), but depsets are not simply hash sets and do not support fast membership tests. If you need a general set datatype, you can simulate one using a dictionary where all keys map to `True`.
 
-Depsets are immutable. They should be created using their [constructor function](../globals/bzl#depset) and merged or augmented with other depsets via the `transitive` argument.
+Depsets are immutable. They should be created using their [constructor function](/versions/8.4.2/rules/lib/globals/bzl#depset) and merged or augmented with other depsets via the `transitive` argument.
 
 The `order` parameter determines the kind of traversal that is done to convert the depset to an iterable. There are four possible values:
 
diff --git a/versions/8.4.2/rules/lib/builtins/fragments.mdx b/versions/8.4.2/rules/lib/builtins/fragments.mdx
index 061fd020..e722512e 100644
--- a/versions/8.4.2/rules/lib/builtins/fragments.mdx
+++ b/versions/8.4.2/rules/lib/builtins/fragments.mdx
@@ -6,4 +6,4 @@ A collection of configuration fragments available in the current rule implementa
 
 Only configuration fragments which are declared in the rule definition may be accessed in this collection.
 
-See the [configuration fragment reference](../fragments) for a list of available fragments and the [rules documentation](https://bazel.build/versions/8.4.2/extending/rules#configuration_fragments) for how to use them.
\ No newline at end of file
+See the [configuration fragment reference](/versions/8.4.2/rules/lib/fragments) for a list of available fragments and the [rules documentation](https://bazel.build/versions/8.4.2/extending/rules#configuration_fragments) for how to use them.
\ No newline at end of file
diff --git a/versions/8.4.2/rules/lib/builtins/macro.mdx b/versions/8.4.2/rules/lib/builtins/macro.mdx
index 35929ebb..fd625363 100644
--- a/versions/8.4.2/rules/lib/builtins/macro.mdx
+++ b/versions/8.4.2/rules/lib/builtins/macro.mdx
@@ -3,7 +3,7 @@ title: 'macro'
 ---
 
 A callable Starlark value representing a symbolic macro; in other words, the return value of
-[`macro()`](../globals/bzl#macro). Invoking this value during package
+[`macro()`](/versions/8.4.2/rules/lib/globals/bzl#macro). Invoking this value during package
 construction time will instantiate the macro, and cause the macro's implementation function to be
 evaluated (in a separate context, different from the context in which the macro value was invoked),
 in most cases causing targets to be added to the package's target set. For more information, see
diff --git a/versions/8.4.2/rules/lib/builtins/module_ctx.mdx b/versions/8.4.2/rules/lib/builtins/module_ctx.mdx
index abbe0b71..a298161c 100644
--- a/versions/8.4.2/rules/lib/builtins/module_ctx.mdx
+++ b/versions/8.4.2/rules/lib/builtins/module_ctx.mdx
@@ -35,16 +35,16 @@ Downloads a file to the output path for the provided url and returns a struct co
 
 | Parameter | Description |
 | --- | --- |
-| `url` | [string](../core/string); or Iterable of [string](../core/string)s; required  List of mirror URLs referencing the same file. |
-| `output` | [string](../core/string); or [Label](../builtins/Label); or [path](../builtins/path); default is `''`  path to the output file, relative to the repository directory. |
-| `sha256` | [string](../core/string); default is `''`  The expected SHA-256 hash of the file downloaded. This must match the SHA-256 hash of the file downloaded. It is a security risk to omit the SHA-256 as remote files can change. At best omitting this field will make your build non-hermetic. It is optional to make development easier but should be set before shipping. If provided, the repository cache will first be checked for a file with the given hash; a download will only be attempted if the file was not found in the cache. After a successful download, the file will be added to the cache. |
-| `executable` | [bool](../core/bool); default is `False`  Set the executable flag on the created file, false by default. |
-| `allow_fail` | [bool](../core/bool); default is `False`  If set, indicate the error in the return value instead of raising an error for failed downloads. |
-| `canonical_id` | [string](../core/string); default is `''`  If set, restrict cache hits to those cases where the file was added to the cache with the same canonical id. By default caching uses the checksum (`sha256` or `integrity`). |
-| `auth` | [dict](../core/dict); default is `{}`  An optional dict specifying authentication information for some of the URLs. |
-| `headers` | [dict](../core/dict); default is `{}`  An optional dict specifying http headers for all URLs. |
-| `integrity` | [string](../core/string); default is `''`  Expected checksum of the file downloaded, in Subresource Integrity format. This must match the checksum of the file downloaded. It is a security risk to omit the checksum as remote files can change. At best omitting this field will make your build non-hermetic. It is optional to make development easier but should be set before shipping. If provided, the repository cache will first be checked for a file with the given checksum; a download will only be attempted if the file was not found in the cache. After a successful download, the file will be added to the cache. |
-| `block` | [bool](../core/bool); default is `True`  If set to false, the call returns immediately and instead of the regular return value, it returns a token with one single method, wait(), which blocks until the download is finished and returns the usual return value or throws as usual. |
+| `url` | [string](/versions/8.4.2/rules/lib/core/string); or Iterable of [string](/versions/8.4.2/rules/lib/core/string)s; required  List of mirror URLs referencing the same file. |
+| `output` | [string](/versions/8.4.2/rules/lib/core/string); or [Label](/versions/8.4.2/rules/lib/builtins/Label); or [path](/versions/8.4.2/rules/lib/builtins/path); default is `''`  path to the output file, relative to the repository directory. |
+| `sha256` | [string](/versions/8.4.2/rules/lib/core/string); default is `''`  The expected SHA-256 hash of the file downloaded. This must match the SHA-256 hash of the file downloaded. It is a security risk to omit the SHA-256 as remote files can change. At best omitting this field will make your build non-hermetic. It is optional to make development easier but should be set before shipping. If provided, the repository cache will first be checked for a file with the given hash; a download will only be attempted if the file was not found in the cache. After a successful download, the file will be added to the cache. |
+| `executable` | [bool](/versions/8.4.2/rules/lib/core/bool); default is `False`  Set the executable flag on the created file, false by default. |
+| `allow_fail` | [bool](/versions/8.4.2/rules/lib/core/bool); default is `False`  If set, indicate the error in the return value instead of raising an error for failed downloads. |
+| `canonical_id` | [string](/versions/8.4.2/rules/lib/core/string); default is `''`  If set, restrict cache hits to those cases where the file was added to the cache with the same canonical id. By default caching uses the checksum (`sha256` or `integrity`). |
+| `auth` | [dict](/versions/8.4.2/rules/lib/core/dict); default is `{}`  An optional dict specifying authentication information for some of the URLs. |
+| `headers` | [dict](/versions/8.4.2/rules/lib/core/dict); default is `{}`  An optional dict specifying http headers for all URLs. |
+| `integrity` | [string](/versions/8.4.2/rules/lib/core/string); default is `''`  Expected checksum of the file downloaded, in Subresource Integrity format. This must match the checksum of the file downloaded. It is a security risk to omit the checksum as remote files can change. At best omitting this field will make your build non-hermetic. It is optional to make development easier but should be set before shipping. If provided, the repository cache will first be checked for a file with the given checksum; a download will only be attempted if the file was not found in the cache. After a successful download, the file will be added to the cache. |
+| `block` | [bool](/versions/8.4.2/rules/lib/core/bool); default is `True`  If set to false, the call returns immediately and instead of the regular return value, it returns a token with one single method, wait(), which blocks until the download is finished and returns the usual return value or throws as usual. |
 
 ## download\_and\_extract
 
@@ -58,17 +58,17 @@ Downloads a file to the output path for the provided url, extracts it, and retur
 
 | Parameter | Description |
 | --- | --- |
-| `url` | [string](../core/string); or Iterable of [string](../core/string)s; required  List of mirror URLs referencing the same file. |
-| `output` | [string](../core/string); or [Label](../builtins/Label); or [path](../builtins/path); default is `''`  Path to the directory where the archive will be unpacked, relative to the repository directory. |
-| `sha256` | [string](../core/string); default is `''`  The expected SHA-256 hash of the file downloaded. This must match the SHA-256 hash of the file downloaded. It is a security risk to omit the SHA-256 as remote files can change. At best omitting this field will make your build non-hermetic. It is optional to make development easier but should be set before shipping. If provided, the repository cache will first be checked for a file with the given hash; a download will only be attempted if the file was not found in the cache. After a successful download, the file will be added to the cache. |
-| `type` | [string](../core/string); default is `''`  The archive type of the downloaded file. By default, the archive type is determined from the file extension of the URL. If the file has no extension, you can explicitly specify either "zip", "jar", "war", "aar", "nupkg", "whl", "tar", "tar.gz", "tgz", "tar.xz", "txz", ".tar.zst", ".tzst", "tar.bz2", ".tbz", ".ar", or ".deb" here. |
-| `strip_prefix` | [string](../core/string); default is `''`  A directory prefix to strip from the extracted files. Many archives contain a top-level directory that contains all files in the archive. Instead of needing to specify this prefix over and over in the `build_file`, this field can be used to strip it from extracted files. For compatibility, this parameter may also be used under the deprecated name `stripPrefix`. |
-| `allow_fail` | [bool](../core/bool); default is `False`  If set, indicate the error in the return value instead of raising an error for failed downloads. |
-| `canonical_id` | [string](../core/string); default is `''`  If set, restrict cache hits to those cases where the file was added to the cache with the same canonical id. By default caching uses the checksum" (`sha256` or `integrity`). |
-| `auth` | [dict](../core/dict); default is `{}`  An optional dict specifying authentication information for some of the URLs. |
-| `headers` | [dict](../core/dict); default is `{}`  An optional dict specifying http headers for all URLs. |
-| `integrity` | [string](../core/string); default is `''`  Expected checksum of the file downloaded, in Subresource Integrity format. This must match the checksum of the file downloaded. It is a security risk to omit the checksum as remote files can change. At best omitting this field will make your build non-hermetic. It is optional to make development easier but should be set before shipping. If provided, the repository cache will first be checked for a file with the given checksum; a download will only be attempted if the file was not found in the cache. After a successful download, the file will be added to the cache. |
-| `rename_files` | [dict](../core/dict); default is `{}`  An optional dict specifying files to rename during the extraction. Archive entries with names exactly matching a key will be renamed to the value, prior to any directory prefix adjustment. This can be used to extract archives that contain non-Unicode filenames, or which have files that would extract to the same path on case-insensitive filesystems. |
+| `url` | [string](/versions/8.4.2/rules/lib/core/string); or Iterable of [string](/versions/8.4.2/rules/lib/core/string)s; required  List of mirror URLs referencing the same file. |
+| `output` | [string](/versions/8.4.2/rules/lib/core/string); or [Label](/versions/8.4.2/rules/lib/builtins/Label); or [path](/versions/8.4.2/rules/lib/builtins/path); default is `''`  Path to the directory where the archive will be unpacked, relative to the repository directory. |
+| `sha256` | [string](/versions/8.4.2/rules/lib/core/string); default is `''`  The expected SHA-256 hash of the file downloaded. This must match the SHA-256 hash of the file downloaded. It is a security risk to omit the SHA-256 as remote files can change. At best omitting this field will make your build non-hermetic. It is optional to make development easier but should be set before shipping. If provided, the repository cache will first be checked for a file with the given hash; a download will only be attempted if the file was not found in the cache. After a successful download, the file will be added to the cache. |
+| `type` | [string](/versions/8.4.2/rules/lib/core/string); default is `''`  The archive type of the downloaded file. By default, the archive type is determined from the file extension of the URL. If the file has no extension, you can explicitly specify either "zip", "jar", "war", "aar", "nupkg", "whl", "tar", "tar.gz", "tgz", "tar.xz", "txz", ".tar.zst", ".tzst", "tar.bz2", ".tbz", ".ar", or ".deb" here. |
+| `strip_prefix` | [string](/versions/8.4.2/rules/lib/core/string); default is `''`  A directory prefix to strip from the extracted files. Many archives contain a top-level directory that contains all files in the archive. Instead of needing to specify this prefix over and over in the `build_file`, this field can be used to strip it from extracted files. For compatibility, this parameter may also be used under the deprecated name `stripPrefix`. |
+| `allow_fail` | [bool](/versions/8.4.2/rules/lib/core/bool); default is `False`  If set, indicate the error in the return value instead of raising an error for failed downloads. |
+| `canonical_id` | [string](/versions/8.4.2/rules/lib/core/string); default is `''`  If set, restrict cache hits to those cases where the file was added to the cache with the same canonical id. By default caching uses the checksum" (`sha256` or `integrity`). |
+| `auth` | [dict](/versions/8.4.2/rules/lib/core/dict); default is `{}`  An optional dict specifying authentication information for some of the URLs. |
+| `headers` | [dict](/versions/8.4.2/rules/lib/core/dict); default is `{}`  An optional dict specifying http headers for all URLs. |
+| `integrity` | [string](/versions/8.4.2/rules/lib/core/string); default is `''`  Expected checksum of the file downloaded, in Subresource Integrity format. This must match the checksum of the file downloaded. It is a security risk to omit the checksum as remote files can change. At best omitting this field will make your build non-hermetic. It is optional to make development easier but should be set before shipping. If provided, the repository cache will first be checked for a file with the given checksum; a download will only be attempted if the file was not found in the cache. After a successful download, the file will be added to the cache. |
+| `rename_files` | [dict](/versions/8.4.2/rules/lib/core/dict); default is `{}`  An optional dict specifying files to rename during the extraction. Archive entries with names exactly matching a key will be renamed to the value, prior to any directory prefix adjustment. This can be used to extract archives that contain non-Unicode filenames, or which have files that would extract to the same path on case-insensitive filesystems. |
 
 ## execute
 
@@ -82,11 +82,11 @@ Executes the command given by the list of arguments. The execution time of the c
 
 | Parameter | Description |
 | --- | --- |
-| `arguments` | [sequence](../core/list); required  List of arguments, the first element should be the path to the program to execute. |
-| `timeout` | [int](../core/int); default is `600`  Maximum duration of the command in seconds (default is 600 seconds). |
-| `environment` | [dict](../core/dict); default is `{}`  Force some environment variables to be set to be passed to the process. The value can be `None` to remove the environment variable. |
-| `quiet` | [bool](../core/bool); default is `True`  If stdout and stderr should be printed to the terminal. |
-| `working_directory` | [string](../core/string); default is `""`  Working directory for command execution. Can be relative to the repository root or absolute. The default is the repository root. |
+| `arguments` | [sequence](/versions/8.4.2/rules/lib/core/list); required  List of arguments, the first element should be the path to the program to execute. |
+| `timeout` | [int](/versions/8.4.2/rules/lib/core/int); default is `600`  Maximum duration of the command in seconds (default is 600 seconds). |
+| `environment` | [dict](/versions/8.4.2/rules/lib/core/dict); default is `{}`  Force some environment variables to be set to be passed to the process. The value can be `None` to remove the environment variable. |
+| `quiet` | [bool](/versions/8.4.2/rules/lib/core/bool); default is `True`  If stdout and stderr should be printed to the terminal. |
+| `working_directory` | [string](/versions/8.4.2/rules/lib/core/string); default is `""`  Working directory for command execution. Can be relative to the repository root or absolute. The default is the repository root. |
 
 ## extension\_metadata
 
@@ -100,9 +100,9 @@ Constructs an opaque object that can be returned from the module extension's imp
 
 | Parameter | Description |
 | --- | --- |
-| `root_module_direct_deps` | [sequence](../core/list) of [string](../core/string)s; or [string](../core/string); or `None`; default is `None`  The names of the repositories that the extension considers to be direct dependencies of the root module. If the root module imports additional repositories or does not import all of these repositories via [`use_repo`](../globals/module#use_repo), Bazel will print a warning when the extension is evaluated, instructing the user to run `bazel mod tidy` to fix the `use_repo` calls automatically. If one of `root_module_direct_deps` and will print a warning and a fixup command when the extension is evaluated. If one of `root_module_direct_deps` and `root_module_direct_dev_deps` is specified, the other has to be as well. The lists specified by these two parameters must be disjoint. Exactly one of `root_module_direct_deps` and `root_module_direct_dev_deps` can be set to the special value `"all"`, which is treated as if a list with the names of all repositories generated by the extension was specified as the value. |
-| `root_module_direct_dev_deps` | [sequence](../core/list) of [string](../core/string)s; or [string](../core/string); or `None`; default is `None`  The names of the repositories that the extension considers to be direct dev dependencies of the root module. If the root module imports additional repositories or does not import all of these repositories via [`use_repo`](../globals/module#use_repo) on an extension proxy created with `use_extension(..., dev_dependency = True)`, Bazel will print a warning when the extension is evaluated, instructing the user to run `bazel mod tidy` to fix the `use_repo` calls automatically. If one of `root_module_direct_deps` and `root_module_direct_dev_deps` is specified, the other has to be as well. The lists specified by these two parameters must be disjoint. Exactly one of `root_module_direct_deps` and `root_module_direct_dev_deps` can be set to the special value `"all"`, which is treated as if a list with the names of all repositories generated by the extension was specified as the value. |
-| `reproducible` | [bool](../core/bool); default is `False`  States that this module extension ensures complete reproducibility, thereby it should not be stored in the lockfile. |
+| `root_module_direct_deps` | [sequence](/versions/8.4.2/rules/lib/core/list) of [string](/versions/8.4.2/rules/lib/core/string)s; or [string](/versions/8.4.2/rules/lib/core/string); or `None`; default is `None`  The names of the repositories that the extension considers to be direct dependencies of the root module. If the root module imports additional repositories or does not import all of these repositories via [`use_repo`](/versions/8.4.2/rules/lib/globals/module#use_repo), Bazel will print a warning when the extension is evaluated, instructing the user to run `bazel mod tidy` to fix the `use_repo` calls automatically. If one of `root_module_direct_deps` and will print a warning and a fixup command when the extension is evaluated. If one of `root_module_direct_deps` and `root_module_direct_dev_deps` is specified, the other has to be as well. The lists specified by these two parameters must be disjoint. Exactly one of `root_module_direct_deps` and `root_module_direct_dev_deps` can be set to the special value `"all"`, which is treated as if a list with the names of all repositories generated by the extension was specified as the value. |
+| `root_module_direct_dev_deps` | [sequence](/versions/8.4.2/rules/lib/core/list) of [string](/versions/8.4.2/rules/lib/core/string)s; or [string](/versions/8.4.2/rules/lib/core/string); or `None`; default is `None`  The names of the repositories that the extension considers to be direct dev dependencies of the root module. If the root module imports additional repositories or does not import all of these repositories via [`use_repo`](/versions/8.4.2/rules/lib/globals/module#use_repo) on an extension proxy created with `use_extension(..., dev_dependency = True)`, Bazel will print a warning when the extension is evaluated, instructing the user to run `bazel mod tidy` to fix the `use_repo` calls automatically. If one of `root_module_direct_deps` and `root_module_direct_dev_deps` is specified, the other has to be as well. The lists specified by these two parameters must be disjoint. Exactly one of `root_module_direct_deps` and `root_module_direct_dev_deps` can be set to the special value `"all"`, which is treated as if a list with the names of all repositories generated by the extension was specified as the value. |
+| `reproducible` | [bool](/versions/8.4.2/rules/lib/core/bool); default is `False`  States that this module extension ensures complete reproducibility, thereby it should not be stored in the lockfile. |
 
 ## extract
 
@@ -116,11 +116,11 @@ Extract an archive to the repository directory.
 
 | Parameter | Description |
 | --- | --- |
-| `archive` | [string](../core/string); or [Label](../builtins/Label); or [path](../builtins/path); required  path to the archive that will be unpacked, relative to the repository directory. |
-| `output` | [string](../core/string); or [Label](../builtins/Label); or [path](../builtins/path); default is `''`  path to the directory where the archive will be unpacked, relative to the repository directory. |
-| `strip_prefix` | [string](../core/string); default is `''`  a directory prefix to strip from the extracted files. Many archives contain a top-level directory that contains all files in the archive. Instead of needing to specify this prefix over and over in the `build_file`, this field can be used to strip it from extracted files. For compatibility, this parameter may also be used under the deprecated name `stripPrefix`. |
-| `rename_files` | [dict](../core/dict); default is `{}`  An optional dict specifying files to rename during the extraction. Archive entries with names exactly matching a key will be renamed to the value, prior to any directory prefix adjustment. This can be used to extract archives that contain non-Unicode filenames, or which have files that would extract to the same path on case-insensitive filesystems. |
-| `watch_archive` | [string](../core/string); default is `'auto'`  whether to [watch](#watch) the archive file. Can be the string 'yes', 'no', or 'auto'. Passing 'yes' is equivalent to immediately invoking the [`watch()`](#watch) method; passing 'no' does not attempt to watch the file; passing 'auto' will only attempt to watch the file when it is legal to do so (see `watch()` docs for more information. |
+| `archive` | [string](/versions/8.4.2/rules/lib/core/string); or [Label](/versions/8.4.2/rules/lib/builtins/Label); or [path](/versions/8.4.2/rules/lib/builtins/path); required  path to the archive that will be unpacked, relative to the repository directory. |
+| `output` | [string](/versions/8.4.2/rules/lib/core/string); or [Label](/versions/8.4.2/rules/lib/builtins/Label); or [path](/versions/8.4.2/rules/lib/builtins/path); default is `''`  path to the directory where the archive will be unpacked, relative to the repository directory. |
+| `strip_prefix` | [string](/versions/8.4.2/rules/lib/core/string); default is `''`  a directory prefix to strip from the extracted files. Many archives contain a top-level directory that contains all files in the archive. Instead of needing to specify this prefix over and over in the `build_file`, this field can be used to strip it from extracted files. For compatibility, this parameter may also be used under the deprecated name `stripPrefix`. |
+| `rename_files` | [dict](/versions/8.4.2/rules/lib/core/dict); default is `{}`  An optional dict specifying files to rename during the extraction. Archive entries with names exactly matching a key will be renamed to the value, prior to any directory prefix adjustment. This can be used to extract archives that contain non-Unicode filenames, or which have files that would extract to the same path on case-insensitive filesystems. |
+| `watch_archive` | [string](/versions/8.4.2/rules/lib/core/string); default is `'auto'`  whether to [watch](#watch) the archive file. Can be the string 'yes', 'no', or 'auto'. Passing 'yes' is equivalent to immediately invoking the [`watch()`](#watch) method; passing 'no' does not attempt to watch the file; passing 'auto' will only attempt to watch the file when it is legal to do so (see `watch()` docs for more information. |
 
 ## file
 
@@ -134,10 +134,10 @@ Generates a file in the repository directory with the provided content.
 
 | Parameter | Description |
 | --- | --- |
-| `path` | [string](../core/string); or [Label](../builtins/Label); or [path](../builtins/path); required  Path of the file to create, relative to the repository directory. |
-| `content` | [string](../core/string); default is `''`  The content of the file to create, empty by default. |
-| `executable` | [bool](../core/bool); default is `True`  Set the executable flag on the created file, true by default. |
-| `legacy_utf8` | [bool](../core/bool); default is `False`  No-op. This parameter is deprecated and will be removed in a future version of Bazel. |
+| `path` | [string](/versions/8.4.2/rules/lib/core/string); or [Label](/versions/8.4.2/rules/lib/builtins/Label); or [path](/versions/8.4.2/rules/lib/builtins/path); required  Path of the file to create, relative to the repository directory. |
+| `content` | [string](/versions/8.4.2/rules/lib/core/string); default is `''`  The content of the file to create, empty by default. |
+| `executable` | [bool](/versions/8.4.2/rules/lib/core/bool); default is `True`  Set the executable flag on the created file, true by default. |
+| `legacy_utf8` | [bool](/versions/8.4.2/rules/lib/core/bool); default is `False`  No-op. This parameter is deprecated and will be removed in a future version of Bazel. |
 
 ## getenv
 
@@ -153,8 +153,8 @@ When building incrementally, any change to the value of the variable named by `n
 
 | Parameter | Description |
 | --- | --- |
-| `name` | [string](../core/string); required  Name of desired environment variable. |
-| `default` | [string](../core/string); or `None`; default is `None`  Default value to return if `name` is not found. |
+| `name` | [string](/versions/8.4.2/rules/lib/core/string); required  Name of desired environment variable. |
+| `default` | [string](/versions/8.4.2/rules/lib/core/string); or `None`; default is `None`  Default value to return if `name` is not found. |
 
 May return `None`.
 
@@ -164,13 +164,13 @@ May return `None`.
 bool module_ctx.is_dev_dependency(tag)
 ```
 
-Returns whether the given tag was specified on the result of a [use\_extension](../globals/module#use_extension) call with `devDependency = True`.
+Returns whether the given tag was specified on the result of a [use\_extension](/versions/8.4.2/rules/lib/globals/module#use_extension) call with `devDependency = True`.
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `tag` | bazel\_module\_tag; required  A tag obtained from [bazel\_module.tags](../builtins/bazel_module#tags). |
+| `tag` | bazel\_module\_tag; required  A tag obtained from [bazel\_module.tags](/versions/8.4.2/rules/lib/builtins/bazel_module#tags). |
 
 ## modules
 
@@ -178,7 +178,7 @@ Returns whether the given tag was specified on the result of a [use\_extension](
 list module_ctx.modules
 ```
 
-A list of all the Bazel modules in the external dependency graph that use this module extension, each of which is a [bazel\_module](../builtins/bazel_module) object that exposes all the tags it specified for this extension. The iteration order of this dictionary is guaranteed to be the same as breadth-first search starting from the root module.
+A list of all the Bazel modules in the external dependency graph that use this module extension, each of which is a [bazel\_module](/versions/8.4.2/rules/lib/builtins/bazel_module) object that exposes all the tags it specified for this extension. The iteration order of this dictionary is guaranteed to be the same as breadth-first search starting from the root module.
 
 ## os
 
@@ -200,7 +200,7 @@ Returns a path from a string, label or path. If the path is relative, it will re
 
 | Parameter | Description |
 | --- | --- |
-| `path` | [string](../core/string); or [Label](../builtins/Label); or [path](../builtins/path); required  `string`, `Label` or `path` from which to create a path from. |
+| `path` | [string](/versions/8.4.2/rules/lib/core/string); or [Label](/versions/8.4.2/rules/lib/builtins/Label); or [path](/versions/8.4.2/rules/lib/builtins/path); required  `string`, `Label` or `path` from which to create a path from. |
 
 ## read
 
@@ -214,8 +214,8 @@ Reads the content of a file on the filesystem.
 
 | Parameter | Description |
 | --- | --- |
-| `path` | [string](../core/string); or [Label](../builtins/Label); or [path](../builtins/path); required  Path of the file to read from. |
-| `watch` | [string](../core/string); default is `'auto'`  Whether to [watch](#watch) the file. Can be the string 'yes', 'no', or 'auto'. Passing 'yes' is equivalent to immediately invoking the [`watch()`](#watch) method; passing 'no' does not attempt to watch the file; passing 'auto' will only attempt to watch the file when it is legal to do so (see `watch()` docs for more information. |
+| `path` | [string](/versions/8.4.2/rules/lib/core/string); or [Label](/versions/8.4.2/rules/lib/builtins/Label); or [path](/versions/8.4.2/rules/lib/builtins/path); required  Path of the file to read from. |
+| `watch` | [string](/versions/8.4.2/rules/lib/core/string); default is `'auto'`  Whether to [watch](#watch) the file. Can be the string 'yes', 'no', or 'auto'. Passing 'yes' is equivalent to immediately invoking the [`watch()`](#watch) method; passing 'no' does not attempt to watch the file; passing 'auto' will only attempt to watch the file when it is legal to do so (see `watch()` docs for more information. |
 
 ## report\_progress
 
@@ -229,7 +229,7 @@ Updates the progress status for the fetching of this repository or module extens
 
 | Parameter | Description |
 | --- | --- |
-| `status` | [string](../core/string); default is `''`  `string` describing the current status of the fetch progress. |
+| `status` | [string](/versions/8.4.2/rules/lib/core/string); default is `''`  `string` describing the current status of the fetch progress. |
 
 ## root\_module\_has\_non\_dev\_dependency
 
@@ -247,7 +247,7 @@ None module_ctx.watch(path)
 
 Tells Bazel to watch for changes to the given path, whether or not it exists, or whether it's a file or a directory. Any changes to the file or directory will invalidate this repository or module extension, and cause it to be refetched or re-evaluated next time.
 
-"Changes" include changes to the contents of the file (if the path is a file); if the path was a file but is now a directory, or vice versa; and if the path starts or stops existing. Notably, this does *not* include changes to any files under the directory if the path is a directory. For that, use [`path.readdir()`](path#readdir) instead.
+"Changes" include changes to the contents of the file (if the path is a file); if the path was a file but is now a directory, or vice versa; and if the path starts or stops existing. Notably, this does *not* include changes to any files under the directory if the path is a directory. For that, use [`path.readdir()`](/versions/8.4.2/rules/lib/builtins/path#readdir) instead.
 
 Note that attempting to watch paths inside the repo currently being fetched, or inside the working directory of the current module extension, will result in an error. A module extension attempting to watch a path outside the current Bazel workspace will also result in an error.
 
@@ -255,7 +255,7 @@ Note that attempting to watch paths inside the repo currently being fetched, or
 
 | Parameter | Description |
 | --- | --- |
-| `path` | [string](../core/string); or [Label](../builtins/Label); or [path](../builtins/path); required  Path of the file to watch. |
+| `path` | [string](/versions/8.4.2/rules/lib/core/string); or [Label](/versions/8.4.2/rules/lib/builtins/Label); or [path](/versions/8.4.2/rules/lib/builtins/path); required  Path of the file to watch. |
 
 ## which
 
@@ -269,6 +269,6 @@ Returns the `path` of the corresponding program or `None` if there is no such pr
 
 | Parameter | Description |
 | --- | --- |
-| `program` | [string](../core/string); required  Program to find in the path. |
+| `program` | [string](/versions/8.4.2/rules/lib/core/string); required  Program to find in the path. |
 
 May return `None`.
\ No newline at end of file
diff --git a/versions/8.4.2/rules/lib/builtins/path.mdx b/versions/8.4.2/rules/lib/builtins/path.mdx
index d200110e..fb68380f 100644
--- a/versions/8.4.2/rules/lib/builtins/path.mdx
+++ b/versions/8.4.2/rules/lib/builtins/path.mdx
@@ -77,7 +77,7 @@ Returns the list of entries in the directory denoted by this path. Each entry is
 
 | Parameter | Description |
 | --- | --- |
-| `watch` | [string](../core/string); default is `'auto'`  whether Bazel should watch the list of entries in this directory and refetch the repository or re-evaluate the module extension next time when any changes are detected. Changes to detect include entry creation, deletion, and renaming. Note that this doesn't watch the *contents* of any entries in the directory. Can be the string 'yes', 'no', or 'auto'. If set to 'auto', Bazel will only watch this directory when it is legal to do so (see [`repository_ctx.watch()`](repository_ctx#watch) docs for more information). |
+| `watch` | [string](/versions/8.4.2/rules/lib/core/string); default is `'auto'`  whether Bazel should watch the list of entries in this directory and refetch the repository or re-evaluate the module extension next time when any changes are detected. Changes to detect include entry creation, deletion, and renaming. Note that this doesn't watch the *contents* of any entries in the directory. Can be the string 'yes', 'no', or 'auto'. If set to 'auto', Bazel will only watch this directory when it is legal to do so (see [`repository_ctx.watch()`](/versions/8.4.2/rules/lib/builtins/repository_ctx#watch) docs for more information). |
 
 ## realpath
 
diff --git a/versions/8.4.2/rules/lib/builtins/repo_metadata.mdx b/versions/8.4.2/rules/lib/builtins/repo_metadata.mdx
index 0b28cbac..15437094 100644
--- a/versions/8.4.2/rules/lib/builtins/repo_metadata.mdx
+++ b/versions/8.4.2/rules/lib/builtins/repo_metadata.mdx
@@ -2,4 +2,4 @@
 title: 'repo\_metadata'
 ---
 
-See [`repository_ctx.repo_metadata`](repository_ctx#repo_metadata).
\ No newline at end of file
+See [`repository_ctx.repo_metadata`](/versions/8.4.2/rules/lib/builtins/repository_ctx#repo_metadata).
\ No newline at end of file
diff --git a/versions/8.4.2/rules/lib/builtins/repository_ctx.mdx b/versions/8.4.2/rules/lib/builtins/repository_ctx.mdx
index 3aa20cbb..15e264aa 100644
--- a/versions/8.4.2/rules/lib/builtins/repository_ctx.mdx
+++ b/versions/8.4.2/rules/lib/builtins/repository_ctx.mdx
@@ -50,7 +50,7 @@ Deletes a file or a directory. Returns a bool, indicating whether the file or di
 
 | Parameter | Description |
 | --- | --- |
-| `path` | [string](../core/string); or [path](../builtins/path); required  Path of the file to delete, relative to the repository directory, or absolute. Can be a path or a string. |
+| `path` | [string](/versions/8.4.2/rules/lib/core/string); or [path](/versions/8.4.2/rules/lib/builtins/path); required  Path of the file to delete, relative to the repository directory, or absolute. Can be a path or a string. |
 
 ## download
 
@@ -64,16 +64,16 @@ Downloads a file to the output path for the provided url and returns a struct co
 
 | Parameter | Description |
 | --- | --- |
-| `url` | [string](../core/string); or Iterable of [string](../core/string)s; required  List of mirror URLs referencing the same file. |
-| `output` | [string](../core/string); or [Label](../builtins/Label); or [path](../builtins/path); default is `''`  path to the output file, relative to the repository directory. |
-| `sha256` | [string](../core/string); default is `''`  The expected SHA-256 hash of the file downloaded. This must match the SHA-256 hash of the file downloaded. It is a security risk to omit the SHA-256 as remote files can change. At best omitting this field will make your build non-hermetic. It is optional to make development easier but should be set before shipping. If provided, the repository cache will first be checked for a file with the given hash; a download will only be attempted if the file was not found in the cache. After a successful download, the file will be added to the cache. |
-| `executable` | [bool](../core/bool); default is `False`  Set the executable flag on the created file, false by default. |
-| `allow_fail` | [bool](../core/bool); default is `False`  If set, indicate the error in the return value instead of raising an error for failed downloads. |
-| `canonical_id` | [string](../core/string); default is `''`  If set, restrict cache hits to those cases where the file was added to the cache with the same canonical id. By default caching uses the checksum (`sha256` or `integrity`). |
-| `auth` | [dict](../core/dict); default is `{}`  An optional dict specifying authentication information for some of the URLs. |
-| `headers` | [dict](../core/dict); default is `{}`  An optional dict specifying http headers for all URLs. |
-| `integrity` | [string](../core/string); default is `''`  Expected checksum of the file downloaded, in Subresource Integrity format. This must match the checksum of the file downloaded. It is a security risk to omit the checksum as remote files can change. At best omitting this field will make your build non-hermetic. It is optional to make development easier but should be set before shipping. If provided, the repository cache will first be checked for a file with the given checksum; a download will only be attempted if the file was not found in the cache. After a successful download, the file will be added to the cache. |
-| `block` | [bool](../core/bool); default is `True`  If set to false, the call returns immediately and instead of the regular return value, it returns a token with one single method, wait(), which blocks until the download is finished and returns the usual return value or throws as usual. |
+| `url` | [string](/versions/8.4.2/rules/lib/core/string); or Iterable of [string](/versions/8.4.2/rules/lib/core/string)s; required  List of mirror URLs referencing the same file. |
+| `output` | [string](/versions/8.4.2/rules/lib/core/string); or [Label](/versions/8.4.2/rules/lib/builtins/Label); or [path](/versions/8.4.2/rules/lib/builtins/path); default is `''`  path to the output file, relative to the repository directory. |
+| `sha256` | [string](/versions/8.4.2/rules/lib/core/string); default is `''`  The expected SHA-256 hash of the file downloaded. This must match the SHA-256 hash of the file downloaded. It is a security risk to omit the SHA-256 as remote files can change. At best omitting this field will make your build non-hermetic. It is optional to make development easier but should be set before shipping. If provided, the repository cache will first be checked for a file with the given hash; a download will only be attempted if the file was not found in the cache. After a successful download, the file will be added to the cache. |
+| `executable` | [bool](/versions/8.4.2/rules/lib/core/bool); default is `False`  Set the executable flag on the created file, false by default. |
+| `allow_fail` | [bool](/versions/8.4.2/rules/lib/core/bool); default is `False`  If set, indicate the error in the return value instead of raising an error for failed downloads. |
+| `canonical_id` | [string](/versions/8.4.2/rules/lib/core/string); default is `''`  If set, restrict cache hits to those cases where the file was added to the cache with the same canonical id. By default caching uses the checksum (`sha256` or `integrity`). |
+| `auth` | [dict](/versions/8.4.2/rules/lib/core/dict); default is `{}`  An optional dict specifying authentication information for some of the URLs. |
+| `headers` | [dict](/versions/8.4.2/rules/lib/core/dict); default is `{}`  An optional dict specifying http headers for all URLs. |
+| `integrity` | [string](/versions/8.4.2/rules/lib/core/string); default is `''`  Expected checksum of the file downloaded, in Subresource Integrity format. This must match the checksum of the file downloaded. It is a security risk to omit the checksum as remote files can change. At best omitting this field will make your build non-hermetic. It is optional to make development easier but should be set before shipping. If provided, the repository cache will first be checked for a file with the given checksum; a download will only be attempted if the file was not found in the cache. After a successful download, the file will be added to the cache. |
+| `block` | [bool](/versions/8.4.2/rules/lib/core/bool); default is `True`  If set to false, the call returns immediately and instead of the regular return value, it returns a token with one single method, wait(), which blocks until the download is finished and returns the usual return value or throws as usual. |
 
 ## download\_and\_extract
 
@@ -87,17 +87,17 @@ Downloads a file to the output path for the provided url, extracts it, and retur
 
 | Parameter | Description |
 | --- | --- |
-| `url` | [string](../core/string); or Iterable of [string](../core/string)s; required  List of mirror URLs referencing the same file. |
-| `output` | [string](../core/string); or [Label](../builtins/Label); or [path](../builtins/path); default is `''`  Path to the directory where the archive will be unpacked, relative to the repository directory. |
-| `sha256` | [string](../core/string); default is `''`  The expected SHA-256 hash of the file downloaded. This must match the SHA-256 hash of the file downloaded. It is a security risk to omit the SHA-256 as remote files can change. At best omitting this field will make your build non-hermetic. It is optional to make development easier but should be set before shipping. If provided, the repository cache will first be checked for a file with the given hash; a download will only be attempted if the file was not found in the cache. After a successful download, the file will be added to the cache. |
-| `type` | [string](../core/string); default is `''`  The archive type of the downloaded file. By default, the archive type is determined from the file extension of the URL. If the file has no extension, you can explicitly specify either "zip", "jar", "war", "aar", "nupkg", "whl", "tar", "tar.gz", "tgz", "tar.xz", "txz", ".tar.zst", ".tzst", "tar.bz2", ".tbz", ".ar", or ".deb" here. |
-| `strip_prefix` | [string](../core/string); default is `''`  A directory prefix to strip from the extracted files. Many archives contain a top-level directory that contains all files in the archive. Instead of needing to specify this prefix over and over in the `build_file`, this field can be used to strip it from extracted files. For compatibility, this parameter may also be used under the deprecated name `stripPrefix`. |
-| `allow_fail` | [bool](../core/bool); default is `False`  If set, indicate the error in the return value instead of raising an error for failed downloads. |
-| `canonical_id` | [string](../core/string); default is `''`  If set, restrict cache hits to those cases where the file was added to the cache with the same canonical id. By default caching uses the checksum" (`sha256` or `integrity`). |
-| `auth` | [dict](../core/dict); default is `{}`  An optional dict specifying authentication information for some of the URLs. |
-| `headers` | [dict](../core/dict); default is `{}`  An optional dict specifying http headers for all URLs. |
-| `integrity` | [string](../core/string); default is `''`  Expected checksum of the file downloaded, in Subresource Integrity format. This must match the checksum of the file downloaded. It is a security risk to omit the checksum as remote files can change. At best omitting this field will make your build non-hermetic. It is optional to make development easier but should be set before shipping. If provided, the repository cache will first be checked for a file with the given checksum; a download will only be attempted if the file was not found in the cache. After a successful download, the file will be added to the cache. |
-| `rename_files` | [dict](../core/dict); default is `{}`  An optional dict specifying files to rename during the extraction. Archive entries with names exactly matching a key will be renamed to the value, prior to any directory prefix adjustment. This can be used to extract archives that contain non-Unicode filenames, or which have files that would extract to the same path on case-insensitive filesystems. |
+| `url` | [string](/versions/8.4.2/rules/lib/core/string); or Iterable of [string](/versions/8.4.2/rules/lib/core/string)s; required  List of mirror URLs referencing the same file. |
+| `output` | [string](/versions/8.4.2/rules/lib/core/string); or [Label](/versions/8.4.2/rules/lib/builtins/Label); or [path](/versions/8.4.2/rules/lib/builtins/path); default is `''`  Path to the directory where the archive will be unpacked, relative to the repository directory. |
+| `sha256` | [string](/versions/8.4.2/rules/lib/core/string); default is `''`  The expected SHA-256 hash of the file downloaded. This must match the SHA-256 hash of the file downloaded. It is a security risk to omit the SHA-256 as remote files can change. At best omitting this field will make your build non-hermetic. It is optional to make development easier but should be set before shipping. If provided, the repository cache will first be checked for a file with the given hash; a download will only be attempted if the file was not found in the cache. After a successful download, the file will be added to the cache. |
+| `type` | [string](/versions/8.4.2/rules/lib/core/string); default is `''`  The archive type of the downloaded file. By default, the archive type is determined from the file extension of the URL. If the file has no extension, you can explicitly specify either "zip", "jar", "war", "aar", "nupkg", "whl", "tar", "tar.gz", "tgz", "tar.xz", "txz", ".tar.zst", ".tzst", "tar.bz2", ".tbz", ".ar", or ".deb" here. |
+| `strip_prefix` | [string](/versions/8.4.2/rules/lib/core/string); default is `''`  A directory prefix to strip from the extracted files. Many archives contain a top-level directory that contains all files in the archive. Instead of needing to specify this prefix over and over in the `build_file`, this field can be used to strip it from extracted files. For compatibility, this parameter may also be used under the deprecated name `stripPrefix`. |
+| `allow_fail` | [bool](/versions/8.4.2/rules/lib/core/bool); default is `False`  If set, indicate the error in the return value instead of raising an error for failed downloads. |
+| `canonical_id` | [string](/versions/8.4.2/rules/lib/core/string); default is `''`  If set, restrict cache hits to those cases where the file was added to the cache with the same canonical id. By default caching uses the checksum" (`sha256` or `integrity`). |
+| `auth` | [dict](/versions/8.4.2/rules/lib/core/dict); default is `{}`  An optional dict specifying authentication information for some of the URLs. |
+| `headers` | [dict](/versions/8.4.2/rules/lib/core/dict); default is `{}`  An optional dict specifying http headers for all URLs. |
+| `integrity` | [string](/versions/8.4.2/rules/lib/core/string); default is `''`  Expected checksum of the file downloaded, in Subresource Integrity format. This must match the checksum of the file downloaded. It is a security risk to omit the checksum as remote files can change. At best omitting this field will make your build non-hermetic. It is optional to make development easier but should be set before shipping. If provided, the repository cache will first be checked for a file with the given checksum; a download will only be attempted if the file was not found in the cache. After a successful download, the file will be added to the cache. |
+| `rename_files` | [dict](/versions/8.4.2/rules/lib/core/dict); default is `{}`  An optional dict specifying files to rename during the extraction. Archive entries with names exactly matching a key will be renamed to the value, prior to any directory prefix adjustment. This can be used to extract archives that contain non-Unicode filenames, or which have files that would extract to the same path on case-insensitive filesystems. |
 
 ## execute
 
@@ -111,11 +111,11 @@ Executes the command given by the list of arguments. The execution time of the c
 
 | Parameter | Description |
 | --- | --- |
-| `arguments` | [sequence](../core/list); required  List of arguments, the first element should be the path to the program to execute. |
-| `timeout` | [int](../core/int); default is `600`  Maximum duration of the command in seconds (default is 600 seconds). |
-| `environment` | [dict](../core/dict); default is `{}`  Force some environment variables to be set to be passed to the process. The value can be `None` to remove the environment variable. |
-| `quiet` | [bool](../core/bool); default is `True`  If stdout and stderr should be printed to the terminal. |
-| `working_directory` | [string](../core/string); default is `""`  Working directory for command execution. Can be relative to the repository root or absolute. The default is the repository root. |
+| `arguments` | [sequence](/versions/8.4.2/rules/lib/core/list); required  List of arguments, the first element should be the path to the program to execute. |
+| `timeout` | [int](/versions/8.4.2/rules/lib/core/int); default is `600`  Maximum duration of the command in seconds (default is 600 seconds). |
+| `environment` | [dict](/versions/8.4.2/rules/lib/core/dict); default is `{}`  Force some environment variables to be set to be passed to the process. The value can be `None` to remove the environment variable. |
+| `quiet` | [bool](/versions/8.4.2/rules/lib/core/bool); default is `True`  If stdout and stderr should be printed to the terminal. |
+| `working_directory` | [string](/versions/8.4.2/rules/lib/core/string); default is `""`  Working directory for command execution. Can be relative to the repository root or absolute. The default is the repository root. |
 
 ## extract
 
@@ -129,11 +129,11 @@ Extract an archive to the repository directory.
 
 | Parameter | Description |
 | --- | --- |
-| `archive` | [string](../core/string); or [Label](../builtins/Label); or [path](../builtins/path); required  path to the archive that will be unpacked, relative to the repository directory. |
-| `output` | [string](../core/string); or [Label](../builtins/Label); or [path](../builtins/path); default is `''`  path to the directory where the archive will be unpacked, relative to the repository directory. |
-| `strip_prefix` | [string](../core/string); default is `''`  a directory prefix to strip from the extracted files. Many archives contain a top-level directory that contains all files in the archive. Instead of needing to specify this prefix over and over in the `build_file`, this field can be used to strip it from extracted files. For compatibility, this parameter may also be used under the deprecated name `stripPrefix`. |
-| `rename_files` | [dict](../core/dict); default is `{}`  An optional dict specifying files to rename during the extraction. Archive entries with names exactly matching a key will be renamed to the value, prior to any directory prefix adjustment. This can be used to extract archives that contain non-Unicode filenames, or which have files that would extract to the same path on case-insensitive filesystems. |
-| `watch_archive` | [string](../core/string); default is `'auto'`  whether to [watch](#watch) the archive file. Can be the string 'yes', 'no', or 'auto'. Passing 'yes' is equivalent to immediately invoking the [`watch()`](#watch) method; passing 'no' does not attempt to watch the file; passing 'auto' will only attempt to watch the file when it is legal to do so (see `watch()` docs for more information. |
+| `archive` | [string](/versions/8.4.2/rules/lib/core/string); or [Label](/versions/8.4.2/rules/lib/builtins/Label); or [path](/versions/8.4.2/rules/lib/builtins/path); required  path to the archive that will be unpacked, relative to the repository directory. |
+| `output` | [string](/versions/8.4.2/rules/lib/core/string); or [Label](/versions/8.4.2/rules/lib/builtins/Label); or [path](/versions/8.4.2/rules/lib/builtins/path); default is `''`  path to the directory where the archive will be unpacked, relative to the repository directory. |
+| `strip_prefix` | [string](/versions/8.4.2/rules/lib/core/string); default is `''`  a directory prefix to strip from the extracted files. Many archives contain a top-level directory that contains all files in the archive. Instead of needing to specify this prefix over and over in the `build_file`, this field can be used to strip it from extracted files. For compatibility, this parameter may also be used under the deprecated name `stripPrefix`. |
+| `rename_files` | [dict](/versions/8.4.2/rules/lib/core/dict); default is `{}`  An optional dict specifying files to rename during the extraction. Archive entries with names exactly matching a key will be renamed to the value, prior to any directory prefix adjustment. This can be used to extract archives that contain non-Unicode filenames, or which have files that would extract to the same path on case-insensitive filesystems. |
+| `watch_archive` | [string](/versions/8.4.2/rules/lib/core/string); default is `'auto'`  whether to [watch](#watch) the archive file. Can be the string 'yes', 'no', or 'auto'. Passing 'yes' is equivalent to immediately invoking the [`watch()`](#watch) method; passing 'no' does not attempt to watch the file; passing 'auto' will only attempt to watch the file when it is legal to do so (see `watch()` docs for more information. |
 
 ## file
 
@@ -147,10 +147,10 @@ Generates a file in the repository directory with the provided content.
 
 | Parameter | Description |
 | --- | --- |
-| `path` | [string](../core/string); or [Label](../builtins/Label); or [path](../builtins/path); required  Path of the file to create, relative to the repository directory. |
-| `content` | [string](../core/string); default is `''`  The content of the file to create, empty by default. |
-| `executable` | [bool](../core/bool); default is `True`  Set the executable flag on the created file, true by default. |
-| `legacy_utf8` | [bool](../core/bool); default is `False`  No-op. This parameter is deprecated and will be removed in a future version of Bazel. |
+| `path` | [string](/versions/8.4.2/rules/lib/core/string); or [Label](/versions/8.4.2/rules/lib/builtins/Label); or [path](/versions/8.4.2/rules/lib/builtins/path); required  Path of the file to create, relative to the repository directory. |
+| `content` | [string](/versions/8.4.2/rules/lib/core/string); default is `''`  The content of the file to create, empty by default. |
+| `executable` | [bool](/versions/8.4.2/rules/lib/core/bool); default is `True`  Set the executable flag on the created file, true by default. |
+| `legacy_utf8` | [bool](/versions/8.4.2/rules/lib/core/bool); default is `False`  No-op. This parameter is deprecated and will be removed in a future version of Bazel. |
 
 ## getenv
 
@@ -166,8 +166,8 @@ When building incrementally, any change to the value of the variable named by `n
 
 | Parameter | Description |
 | --- | --- |
-| `name` | [string](../core/string); required  Name of desired environment variable. |
-| `default` | [string](../core/string); or `None`; default is `None`  Default value to return if `name` is not found. |
+| `name` | [string](/versions/8.4.2/rules/lib/core/string); required  Name of desired environment variable. |
+| `default` | [string](/versions/8.4.2/rules/lib/core/string); or `None`; default is `None`  Default value to return if `name` is not found. |
 
 May return `None`.
 
@@ -207,9 +207,9 @@ Apply a patch file to the root directory of external repository. The patch file
 
 | Parameter | Description |
 | --- | --- |
-| `patch_file` | [string](../core/string); or [Label](../builtins/Label); or [path](../builtins/path); required  The patch file to apply, it can be label, relative path or absolute path. If it's a relative path, it will resolve to the repository directory. |
-| `strip` | [int](../core/int); default is `0`  Strip the specified number of leading components from file names. |
-| `watch_patch` | [string](../core/string); default is `'auto'`  Whether to [watch](#watch) the patch file. Can be the string 'yes', 'no', or 'auto'. Passing 'yes' is equivalent to immediately invoking the [`watch()`](#watch) method; passing 'no' does not attempt to watch the file; passing 'auto' will only attempt to watch the file when it is legal to do so (see `watch()` docs for more information. |
+| `patch_file` | [string](/versions/8.4.2/rules/lib/core/string); or [Label](/versions/8.4.2/rules/lib/builtins/Label); or [path](/versions/8.4.2/rules/lib/builtins/path); required  The patch file to apply, it can be label, relative path or absolute path. If it's a relative path, it will resolve to the repository directory. |
+| `strip` | [int](/versions/8.4.2/rules/lib/core/int); default is `0`  Strip the specified number of leading components from file names. |
+| `watch_patch` | [string](/versions/8.4.2/rules/lib/core/string); default is `'auto'`  Whether to [watch](#watch) the patch file. Can be the string 'yes', 'no', or 'auto'. Passing 'yes' is equivalent to immediately invoking the [`watch()`](#watch) method; passing 'no' does not attempt to watch the file; passing 'auto' will only attempt to watch the file when it is legal to do so (see `watch()` docs for more information. |
 
 ## path
 
@@ -223,7 +223,7 @@ Returns a path from a string, label or path. If the path is relative, it will re
 
 | Parameter | Description |
 | --- | --- |
-| `path` | [string](../core/string); or [Label](../builtins/Label); or [path](../builtins/path); required  `string`, `Label` or `path` from which to create a path from. |
+| `path` | [string](/versions/8.4.2/rules/lib/core/string); or [Label](/versions/8.4.2/rules/lib/builtins/Label); or [path](/versions/8.4.2/rules/lib/builtins/path); required  `string`, `Label` or `path` from which to create a path from. |
 
 ## read
 
@@ -237,8 +237,8 @@ Reads the content of a file on the filesystem.
 
 | Parameter | Description |
 | --- | --- |
-| `path` | [string](../core/string); or [Label](../builtins/Label); or [path](../builtins/path); required  Path of the file to read from. |
-| `watch` | [string](../core/string); default is `'auto'`  Whether to [watch](#watch) the file. Can be the string 'yes', 'no', or 'auto'. Passing 'yes' is equivalent to immediately invoking the [`watch()`](#watch) method; passing 'no' does not attempt to watch the file; passing 'auto' will only attempt to watch the file when it is legal to do so (see `watch()` docs for more information. |
+| `path` | [string](/versions/8.4.2/rules/lib/core/string); or [Label](/versions/8.4.2/rules/lib/builtins/Label); or [path](/versions/8.4.2/rules/lib/builtins/path); required  Path of the file to read from. |
+| `watch` | [string](/versions/8.4.2/rules/lib/core/string); default is `'auto'`  Whether to [watch](#watch) the file. Can be the string 'yes', 'no', or 'auto'. Passing 'yes' is equivalent to immediately invoking the [`watch()`](#watch) method; passing 'no' does not attempt to watch the file; passing 'auto' will only attempt to watch the file when it is legal to do so (see `watch()` docs for more information. |
 
 ## rename
 
@@ -253,8 +253,8 @@ already exists. Both paths must be located within the repository.
 
 | Parameter | Description |
 | --- | --- |
-| `src` | [string](../core/string); or [Label](../builtins/Label); or [path](../builtins/path); required  The path of the existing file or directory to rename, relative to the repository directory. |
-| `dst` | [string](../core/string); or [Label](../builtins/Label); or [path](../builtins/path); required  The new name to which the file or directory will be renamed to, relative to the repository directory. |
+| `src` | [string](/versions/8.4.2/rules/lib/core/string); or [Label](/versions/8.4.2/rules/lib/builtins/Label); or [path](/versions/8.4.2/rules/lib/builtins/path); required  The path of the existing file or directory to rename, relative to the repository directory. |
+| `dst` | [string](/versions/8.4.2/rules/lib/core/string); or [Label](/versions/8.4.2/rules/lib/builtins/Label); or [path](/versions/8.4.2/rules/lib/builtins/path); required  The new name to which the file or directory will be renamed to, relative to the repository directory. |
 
 ## repo\_metadata
 
@@ -268,8 +268,8 @@ Constructs an opaque object that can be returned from the repo rule's implementa
 
 | Parameter | Description |
 | --- | --- |
-| `reproducible` | [bool](../core/bool); default is `False`  States that this repo can be reproducibly refetched; that is, if it were fetched another time with exactly the same input attributes, repo rule definition, watched files and environment variables, etc., then exactly the same output would be produced. This property needs to hold even if other untracked conditions change, such as information from the internet, the path of the workspace root, output from running arbitrary executables, etc. If set to True, this allows the fetched repo contents to be cached across workspaces. Note that setting this to True does not guarantee caching in the repo contents cache; for example, local repo rules are never cached. |
-| `attrs_for_reproducibility` | [dict](../core/dict); default is `{}`  If `reproducible` is False, this can be specified to tell Bazel which attributes of the original repo rule to change to make it reproducible. |
+| `reproducible` | [bool](/versions/8.4.2/rules/lib/core/bool); default is `False`  States that this repo can be reproducibly refetched; that is, if it were fetched another time with exactly the same input attributes, repo rule definition, watched files and environment variables, etc., then exactly the same output would be produced. This property needs to hold even if other untracked conditions change, such as information from the internet, the path of the workspace root, output from running arbitrary executables, etc. If set to True, this allows the fetched repo contents to be cached across workspaces. Note that setting this to True does not guarantee caching in the repo contents cache; for example, local repo rules are never cached. |
+| `attrs_for_reproducibility` | [dict](/versions/8.4.2/rules/lib/core/dict); default is `{}`  If `reproducible` is False, this can be specified to tell Bazel which attributes of the original repo rule to change to make it reproducible. |
 
 ## report\_progress
 
@@ -283,7 +283,7 @@ Updates the progress status for the fetching of this repository or module extens
 
 | Parameter | Description |
 | --- | --- |
-| `status` | [string](../core/string); default is `''`  `string` describing the current status of the fetch progress. |
+| `status` | [string](/versions/8.4.2/rules/lib/core/string); default is `''`  `string` describing the current status of the fetch progress. |
 
 ## symlink
 
@@ -297,8 +297,8 @@ Creates a symlink on the filesystem.
 
 | Parameter | Description |
 | --- | --- |
-| `target` | [string](../core/string); or [Label](../builtins/Label); or [path](../builtins/path); required  The path that the symlink should point to. |
-| `link_name` | [string](../core/string); or [Label](../builtins/Label); or [path](../builtins/path); required  The path of the symlink to create. |
+| `target` | [string](/versions/8.4.2/rules/lib/core/string); or [Label](/versions/8.4.2/rules/lib/builtins/Label); or [path](/versions/8.4.2/rules/lib/builtins/path); required  The path that the symlink should point to. |
+| `link_name` | [string](/versions/8.4.2/rules/lib/core/string); or [Label](/versions/8.4.2/rules/lib/builtins/Label); or [path](/versions/8.4.2/rules/lib/builtins/path); required  The path of the symlink to create. |
 
 ## template
 
@@ -312,11 +312,11 @@ Generates a new file using a `template`. Every occurrence in `template` of a key
 
 | Parameter | Description |
 | --- | --- |
-| `path` | [string](../core/string); or [Label](../builtins/Label); or [path](../builtins/path); required  Path of the file to create, relative to the repository directory. |
-| `template` | [string](../core/string); or [Label](../builtins/Label); or [path](../builtins/path); required  Path to the template file. |
-| `substitutions` | [dict](../core/dict); default is `{}`  Substitutions to make when expanding the template. |
-| `executable` | [bool](../core/bool); default is `True`  Set the executable flag on the created file, true by default. |
-| `watch_template` | [string](../core/string); default is `'auto'`  Whether to [watch](#watch) the template file. Can be the string 'yes', 'no', or 'auto'. Passing 'yes' is equivalent to immediately invoking the [`watch()`](#watch) method; passing 'no' does not attempt to watch the file; passing 'auto' will only attempt to watch the file when it is legal to do so (see `watch()` docs for more information. |
+| `path` | [string](/versions/8.4.2/rules/lib/core/string); or [Label](/versions/8.4.2/rules/lib/builtins/Label); or [path](/versions/8.4.2/rules/lib/builtins/path); required  Path of the file to create, relative to the repository directory. |
+| `template` | [string](/versions/8.4.2/rules/lib/core/string); or [Label](/versions/8.4.2/rules/lib/builtins/Label); or [path](/versions/8.4.2/rules/lib/builtins/path); required  Path to the template file. |
+| `substitutions` | [dict](/versions/8.4.2/rules/lib/core/dict); default is `{}`  Substitutions to make when expanding the template. |
+| `executable` | [bool](/versions/8.4.2/rules/lib/core/bool); default is `True`  Set the executable flag on the created file, true by default. |
+| `watch_template` | [string](/versions/8.4.2/rules/lib/core/string); default is `'auto'`  Whether to [watch](#watch) the template file. Can be the string 'yes', 'no', or 'auto'. Passing 'yes' is equivalent to immediately invoking the [`watch()`](#watch) method; passing 'no' does not attempt to watch the file; passing 'auto' will only attempt to watch the file when it is legal to do so (see `watch()` docs for more information. |
 
 ## watch
 
@@ -326,7 +326,7 @@ None repository_ctx.watch(path)
 
 Tells Bazel to watch for changes to the given path, whether or not it exists, or whether it's a file or a directory. Any changes to the file or directory will invalidate this repository or module extension, and cause it to be refetched or re-evaluated next time.
 
-"Changes" include changes to the contents of the file (if the path is a file); if the path was a file but is now a directory, or vice versa; and if the path starts or stops existing. Notably, this does *not* include changes to any files under the directory if the path is a directory. For that, use [`path.readdir()`](path#readdir) instead.
+"Changes" include changes to the contents of the file (if the path is a file); if the path was a file but is now a directory, or vice versa; and if the path starts or stops existing. Notably, this does *not* include changes to any files under the directory if the path is a directory. For that, use [`path.readdir()`](/versions/8.4.2/rules/lib/builtins/path#readdir) instead.
 
 Note that attempting to watch paths inside the repo currently being fetched, or inside the working directory of the current module extension, will result in an error. A module extension attempting to watch a path outside the current Bazel workspace will also result in an error.
 
@@ -334,7 +334,7 @@ Note that attempting to watch paths inside the repo currently being fetched, or
 
 | Parameter | Description |
 | --- | --- |
-| `path` | [string](../core/string); or [Label](../builtins/Label); or [path](../builtins/path); required  Path of the file to watch. |
+| `path` | [string](/versions/8.4.2/rules/lib/core/string); or [Label](/versions/8.4.2/rules/lib/builtins/Label); or [path](/versions/8.4.2/rules/lib/builtins/path); required  Path of the file to watch. |
 
 ## watch\_tree
 
@@ -350,7 +350,7 @@ Note that attempting to watch paths inside the repo currently being fetched will
 
 | Parameter | Description |
 | --- | --- |
-| `path` | [string](../core/string); or [Label](../builtins/Label); or [path](../builtins/path); required  Path of the directory tree to watch. |
+| `path` | [string](/versions/8.4.2/rules/lib/core/string); or [Label](/versions/8.4.2/rules/lib/builtins/Label); or [path](/versions/8.4.2/rules/lib/builtins/path); required  Path of the directory tree to watch. |
 
 ## which
 
@@ -364,7 +364,7 @@ Returns the `path` of the corresponding program or `None` if there is no such pr
 
 | Parameter | Description |
 | --- | --- |
-| `program` | [string](../core/string); required  Program to find in the path. |
+| `program` | [string](/versions/8.4.2/rules/lib/core/string); required  Program to find in the path. |
 
 May return `None`.
 
diff --git a/versions/8.4.2/rules/lib/builtins/repository_rule.mdx b/versions/8.4.2/rules/lib/builtins/repository_rule.mdx
index ef5dac59..cd813034 100644
--- a/versions/8.4.2/rules/lib/builtins/repository_rule.mdx
+++ b/versions/8.4.2/rules/lib/builtins/repository_rule.mdx
@@ -2,4 +2,4 @@
 title: 'repository\_rule'
 ---
 
-A callable value that may be invoked during evaluation of the WORKSPACE file or within the implementation function of a module extension to instantiate and return a repository rule. Created by [`repository_rule()`](../globals/bzl#repository_rule).
\ No newline at end of file
+A callable value that may be invoked during evaluation of the WORKSPACE file or within the implementation function of a module extension to instantiate and return a repository rule. Created by [`repository_rule()`](/versions/8.4.2/rules/lib/globals/bzl#repository_rule).
\ No newline at end of file
diff --git a/versions/8.4.2/rules/lib/builtins/rule.mdx b/versions/8.4.2/rules/lib/builtins/rule.mdx
index b415b9d0..a878175c 100644
--- a/versions/8.4.2/rules/lib/builtins/rule.mdx
+++ b/versions/8.4.2/rules/lib/builtins/rule.mdx
@@ -3,7 +3,7 @@ title: 'rule'
 ---
 
 A callable value representing the type of a native or Starlark rule (created by
-[`rule()`](../globals/bzl#rule)). Calling the value during
+[`rule()`](/versions/8.4.2/rules/lib/globals/bzl#rule)). Calling the value during
 evaluation of a package's BUILD file creates an instance of the rule and adds it to the
 package's target set. For more information, visit this page about
 [Rules](https://bazel.build/versions/8.4.2/extending/rules).
\ No newline at end of file
diff --git a/versions/8.4.2/rules/lib/builtins/rule_attributes.mdx b/versions/8.4.2/rules/lib/builtins/rule_attributes.mdx
index d85b7eb8..a8dacefb 100644
--- a/versions/8.4.2/rules/lib/builtins/rule_attributes.mdx
+++ b/versions/8.4.2/rules/lib/builtins/rule_attributes.mdx
@@ -20,7 +20,7 @@ Information about attributes of a rule an aspect is applied to.
 struct rule_attributes.attr
 ```
 
-A struct to access the values of the [attributes](https://bazel.build/versions/8.4.2/extending/rules#attributes). The values are provided by the user (if not, a default value is used). The attributes of the struct and the types of their values correspond to the keys and values of the [`attrs` dict](../globals/bzl#rule.attrs) provided to the [`rule` function](../globals/bzl#rule). [See example of use](https://github.com/bazelbuild/examples/blob/main/rules/attributes/printer.bzl).
+A struct to access the values of the [attributes](https://bazel.build/versions/8.4.2/extending/rules#attributes). The values are provided by the user (if not, a default value is used). The attributes of the struct and the types of their values correspond to the keys and values of the [`attrs` dict](/versions/8.4.2/rules/lib/globals/bzl#rule.attrs) provided to the [`rule` function](/versions/8.4.2/rules/lib/globals/bzl#rule). [See example of use](https://github.com/bazelbuild/examples/blob/main/rules/attributes/printer.bzl).
 
 ## exec\_groups
 
@@ -36,7 +36,7 @@ A collection of the execution groups available for the rule the aspect is applie
 struct rule_attributes.executable
 ```
 
-A `struct` containing executable files defined in [label type attributes](../toplevel/attr#label) marked as [`executable=True`](../toplevel/attr#label.executable). The struct fields correspond to the attribute names. Each value in the struct is either a [`File`](../builtins/File) or `None`. If an optional attribute is not specified in the rule then the corresponding struct value is `None`. If a label type is not marked as `executable=True`, no corresponding struct field is generated. [See example of use](https://github.com/bazelbuild/examples/blob/main/rules/actions_run/execute.bzl).
+A `struct` containing executable files defined in [label type attributes](/versions/8.4.2/rules/lib/toplevel/attr#label) marked as [`executable=True`](/versions/8.4.2/rules/lib/toplevel/attr#label.executable). The struct fields correspond to the attribute names. Each value in the struct is either a [`File`](/versions/8.4.2/rules/lib/builtins/File) or `None`. If an optional attribute is not specified in the rule then the corresponding struct value is `None`. If a label type is not marked as `executable=True`, no corresponding struct field is generated. [See example of use](https://github.com/bazelbuild/examples/blob/main/rules/actions_run/execute.bzl).
 
 ## file
 
@@ -44,7 +44,7 @@ A `struct` containing executable files defined in [label type attributes](../top
 struct rule_attributes.file
 ```
 
-A `struct` containing files defined in [label type attributes](../toplevel/attr#label) marked as [`allow_single_file`](../toplevel/attr#label.allow_single_file). The struct fields correspond to the attribute names. The struct value is always a [`File`](../builtins/File) or `None`. If an optional attribute is not specified in the rule then the corresponding struct value is `None`. If a label type is not marked as `allow_single_file`, no corresponding struct field is generated. It is a shortcut for:
+A `struct` containing files defined in [label type attributes](/versions/8.4.2/rules/lib/toplevel/attr#label) marked as [`allow_single_file`](/versions/8.4.2/rules/lib/toplevel/attr#label.allow_single_file). The struct fields correspond to the attribute names. The struct value is always a [`File`](/versions/8.4.2/rules/lib/builtins/File) or `None`. If an optional attribute is not specified in the rule then the corresponding struct value is `None`. If a label type is not marked as `allow_single_file`, no corresponding struct field is generated. It is a shortcut for:
 
 ```
 list(ctx.attr..files)[0]
@@ -58,7 +58,7 @@ In other words, use `file` to access the (singular) [default output](https://baz
 struct rule_attributes.files
 ```
 
-A `struct` containing files defined in [label](../toplevel/attr#label) or [label list](../toplevel/attr#label_list) type attributes. The struct fields correspond to the attribute names. The struct values are `list` of [`File`](../builtins/File)s. It is a shortcut for:
+A `struct` containing files defined in [label](/versions/8.4.2/rules/lib/toplevel/attr#label) or [label list](/versions/8.4.2/rules/lib/toplevel/attr#label_list) type attributes. The struct fields correspond to the attribute names. The struct values are `list` of [`File`](/versions/8.4.2/rules/lib/builtins/File)s. It is a shortcut for:
 
 ```
 [f for t in ctx.attr. for f in t.files]
diff --git a/versions/8.4.2/rules/lib/builtins/runfiles.mdx b/versions/8.4.2/rules/lib/builtins/runfiles.mdx
index f8fcef26..f8c2eb38 100644
--- a/versions/8.4.2/rules/lib/builtins/runfiles.mdx
+++ b/versions/8.4.2/rules/lib/builtins/runfiles.mdx
@@ -2,7 +2,7 @@
 title: 'runfiles'
 ---
 
-A container of information regarding a set of files required at runtime execution. This object should be passed via [DefaultInfo](../providers/DefaultInfo) in order to tell the build system about the runfiles needed by the outputs produced by the rule.
+A container of information regarding a set of files required at runtime execution. This object should be passed via [DefaultInfo](/versions/8.4.2/rules/lib/providers/DefaultInfo) in order to tell the build system about the runfiles needed by the outputs produced by the rule.
 
 See [runfiles guide](https://bazel.build/versions/8.4.2/extending/rules#runfiles) for details.
 
@@ -45,7 +45,7 @@ Returns a new runfiles object that includes all the contents of this one and the
 
 | Parameter | Description |
 | --- | --- |
-| `other` | [runfiles](../builtins/runfiles); required  The runfiles object to merge into this. |
+| `other` | [runfiles](/versions/8.4.2/rules/lib/builtins/runfiles); required  The runfiles object to merge into this. |
 
 ## merge\_all
 
@@ -59,7 +59,7 @@ Returns a new runfiles object that includes all the contents of this one and of
 
 | Parameter | Description |
 | --- | --- |
-| `other` | [sequence](../core/list) of [runfiles](../builtins/runfiles)s; required  The sequence of runfiles objects to merge into this. |
+| `other` | [sequence](/versions/8.4.2/rules/lib/core/list) of [runfiles](/versions/8.4.2/rules/lib/builtins/runfiles)s; required  The sequence of runfiles objects to merge into this. |
 
 ## root\_symlinks
 
diff --git a/versions/8.4.2/rules/lib/builtins/tag_class.mdx b/versions/8.4.2/rules/lib/builtins/tag_class.mdx
index 7d4349d0..a4329b42 100644
--- a/versions/8.4.2/rules/lib/builtins/tag_class.mdx
+++ b/versions/8.4.2/rules/lib/builtins/tag_class.mdx
@@ -2,4 +2,4 @@
 title: 'tag\_class'
 ---
 
-Defines a schema of attributes for a tag, created by [`tag_class()`](../globals/bzl#tag_class).
\ No newline at end of file
+Defines a schema of attributes for a tag, created by [`tag_class()`](/versions/8.4.2/rules/lib/globals/bzl#tag_class).
\ No newline at end of file
diff --git a/versions/8.4.2/rules/lib/builtins/transition.mdx b/versions/8.4.2/rules/lib/builtins/transition.mdx
index de141eab..75269b6c 100644
--- a/versions/8.4.2/rules/lib/builtins/transition.mdx
+++ b/versions/8.4.2/rules/lib/builtins/transition.mdx
@@ -39,5 +39,5 @@ For more details see [here](https://bazel.build/versions/8.4.2/rules/config#user
 | Parameter | Description |
 | --- | --- |
 | `implementation` | callable; required  The function implementing this transition. This function always has two parameters: `settings` and `attr`. The `settings` param is a dictionary whose set of keys is defined by the inputs parameter. So, for each build setting `--//foo=bar`, if `inputs` contains `//foo`, `settings` will have an entry `settings['//foo']='bar'`. The `attr` param is a reference to `ctx.attr`. This gives the implementation function access to the rule's attributes to make attribute-parameterized transitions possible. This function must return a `dict` from build setting identifier to build setting value; this represents the configuration transition: for each entry in the returned `dict`, the transition updates that setting to the new value. All other settings are unchanged. This function can also return a `list` of `dict`s or a `dict` of `dict`s in the case of a split transition. |
-| `inputs` | [sequence](../core/list) of [string](../core/string)s; required  List of build settings that can be read by this transition. This becomes the key set of the settings parameter of the implementation function parameter. |
-| `outputs` | [sequence](../core/list) of [string](../core/string)s; required  List of build settings that can be written by this transition. This must be a superset of the key set of the dictionary returned by this transition. |
\ No newline at end of file
+| `inputs` | [sequence](/versions/8.4.2/rules/lib/core/list) of [string](/versions/8.4.2/rules/lib/core/string)s; required  List of build settings that can be read by this transition. This becomes the key set of the settings parameter of the implementation function parameter. |
+| `outputs` | [sequence](/versions/8.4.2/rules/lib/core/list) of [string](/versions/8.4.2/rules/lib/core/string)s; required  List of build settings that can be written by this transition. This must be a superset of the key set of the dictionary returned by this transition. |
\ No newline at end of file
diff --git a/versions/8.4.2/rules/lib/core/bool.mdx b/versions/8.4.2/rules/lib/core/bool.mdx
index 52be3664..561c799b 100644
--- a/versions/8.4.2/rules/lib/core/bool.mdx
+++ b/versions/8.4.2/rules/lib/core/bool.mdx
@@ -2,4 +2,4 @@
 title: 'bool'
 ---
 
-A type to represent booleans. There are only two possible values: True and False. Any value can be converted to a boolean using the [bool](../globals/all#bool) function.
\ No newline at end of file
+A type to represent booleans. There are only two possible values: True and False. Any value can be converted to a boolean using the [bool](/versions/8.4.2/rules/lib/globals/all#bool) function.
\ No newline at end of file
diff --git a/versions/8.4.2/rules/lib/core/dict.mdx b/versions/8.4.2/rules/lib/core/dict.mdx
index 9005668c..9aba4286 100644
--- a/versions/8.4.2/rules/lib/core/dict.mdx
+++ b/versions/8.4.2/rules/lib/core/dict.mdx
@@ -22,7 +22,7 @@ There are four ways to construct a dictionary:
      {i: 2*i for i in range(3)}  # {0: 0, 1: 2, 2: 4}
      ```
 
-     - A call to the built-in [dict](../globals/all#dict) function returns a dictionary containing the specified entries, which are inserted in argument order, positional arguments before named. As with comprehensions, duplicate keys are permitted.- The union expression `x | y` yields a new dictionary by combining two existing dictionaries. If the two dictionaries have a key `k` in common, the right hand side dictionary's value of the key (in other words, `y[k]`) wins. The `|=` variant of the union operator modifies a dictionary in-place. Example:
+     - A call to the built-in [dict](/versions/8.4.2/rules/lib/globals/all#dict) function returns a dictionary containing the specified entries, which are inserted in argument order, positional arguments before named. As with comprehensions, duplicate keys are permitted.- The union expression `x | y` yields a new dictionary by combining two existing dictionaries. If the two dictionaries have a key `k` in common, the right hand side dictionary's value of the key (in other words, `y[k]`) wins. The `|=` variant of the union operator modifies a dictionary in-place. Example:
 
          ```
          d = {"foo": "FOO", "bar": "BAR"} | {"foo": "FOO2", "baz": "BAZ"}
diff --git a/versions/8.4.2/rules/lib/core/json.mdx b/versions/8.4.2/rules/lib/core/json.mdx
index 0bb00e3e..35ba1941 100644
--- a/versions/8.4.2/rules/lib/core/json.mdx
+++ b/versions/8.4.2/rules/lib/core/json.mdx
@@ -29,7 +29,7 @@ If `x` is not a valid JSON encoding and the optional `default` parameter is *not
 
 | Parameter | Description |
 | --- | --- |
-| `x` | [string](../core/string); required  JSON string to decode. |
+| `x` | [string](/versions/8.4.2/rules/lib/core/string); required  JSON string to decode. |
 | `default` | default is `unbound`  If specified, the value to return when `x` cannot be decoded. |
 
 ## encode
@@ -64,8 +64,8 @@ The encode\_indent function is equivalent to `json.indent(json.encode(x), ...)`.
 | Parameter | Description |
 | --- | --- |
 | `x` | required |
-| `prefix` | [string](../core/string); default is `''` |
-| `indent` | [string](../core/string); default is `'\t'` |
+| `prefix` | [string](/versions/8.4.2/rules/lib/core/string); default is `''` |
+| `indent` | [string](/versions/8.4.2/rules/lib/core/string); default is `'\t'` |
 
 ## indent
 
@@ -84,6 +84,6 @@ If the input is not valid, the function may fail or return invalid output.
 
 | Parameter | Description |
 | --- | --- |
-| `s` | [string](../core/string); required |
-| `prefix` | [string](../core/string); default is `''` |
-| `indent` | [string](../core/string); default is `'\t'` |
\ No newline at end of file
+| `s` | [string](/versions/8.4.2/rules/lib/core/string); required |
+| `prefix` | [string](/versions/8.4.2/rules/lib/core/string); default is `''` |
+| `indent` | [string](/versions/8.4.2/rules/lib/core/string); default is `'\t'` |
\ No newline at end of file
diff --git a/versions/8.4.2/rules/lib/core/list.mdx b/versions/8.4.2/rules/lib/core/list.mdx
index c19e9780..dd36fd4d 100644
--- a/versions/8.4.2/rules/lib/core/list.mdx
+++ b/versions/8.4.2/rules/lib/core/list.mdx
@@ -91,8 +91,8 @@ Returns the index in the list of the first item whose value is x. It is an error
 | Parameter | Description |
 | --- | --- |
 | `x` | required |
-| `start` | [int](../core/int); or `None`; default is `None`  The start index of the list portion to inspect. |
-| `end` | [int](../core/int); or `None`; default is `None`  The end index of the list portion to inspect. |
+| `start` | [int](/versions/8.4.2/rules/lib/core/int); or `None`; default is `None`  The start index of the list portion to inspect. |
+| `end` | [int](/versions/8.4.2/rules/lib/core/int); or `None`; default is `None`  The end index of the list portion to inspect. |
 
 ## insert
 
@@ -106,7 +106,7 @@ Inserts an item at a given position.
 
 | Parameter | Description |
 | --- | --- |
-| `index` | [int](../core/int); required  The index of the given position. |
+| `index` | [int](/versions/8.4.2/rules/lib/core/int); required  The index of the given position. |
 | `item` | required  The item. |
 
 ## pop
@@ -121,7 +121,7 @@ Removes the item at the given position in the list, and returns it. If no `index
 
 | Parameter | Description |
 | --- | --- |
-| `i` | [int](../core/int); or `None`; default is `-1`  The index of the item. |
+| `i` | [int](/versions/8.4.2/rules/lib/core/int); or `None`; default is `-1`  The index of the item. |
 
 ## remove
 
diff --git a/versions/8.4.2/rules/lib/core/set.mdx b/versions/8.4.2/rules/lib/core/set.mdx
index aeb3b202..ed28098f 100644
--- a/versions/8.4.2/rules/lib/core/set.mdx
+++ b/versions/8.4.2/rules/lib/core/set.mdx
@@ -3,14 +3,14 @@ title: 'set'
 ---
 
 The built-in set type. A set is a mutable, iterable collection of unique values – the set's
-*elements*. The [type name](../globals/all#type) of a set is `"set"`.
+*elements*. The [type name](/versions/8.4.2/rules/lib/globals/all#type) of a set is `"set"`.
 
 Sets provide constant-time operations to insert, remove, or check for the presence of a value.
 Sets are implemented using a hash table, and therefore, just like keys of a
-[dictionary](../dict), elements of a set must be hashable. A value may be used as an
+[dictionary](/versions/8.4.2/rules/lib/core/dict), elements of a set must be hashable. A value may be used as an
 element of a set if and only if it may be used as a key of a dictionary.
 
-Sets may be constructed using the [`set()`](../globals/all#set) built-in
+Sets may be constructed using the [`set()`](/versions/8.4.2/rules/lib/globals/all#set) built-in
 function, which returns a new set containing the unique elements of its optional argument, which
 must be an iterable. Calling `set()` without an argument constructs an empty set. Sets
 have no literal syntax.
@@ -26,7 +26,7 @@ s = set(["a", "b", "c"])
 
 A set is iterable, and thus may be used as the operand of a `for` loop, a list
 comprehension, and the various built-in functions that operate on iterables. Its length can be
-retrieved using the [`len()`](../globals/all#len) built-in function, and the
+retrieved using the [`len()`](/versions/8.4.2/rules/lib/globals/all#len) built-in function, and the
 order of iteration is the order in which elements were first added to the set:
 
 ```
diff --git a/versions/8.4.2/rules/lib/core/string.mdx b/versions/8.4.2/rules/lib/core/string.mdx
index 1673c6e4..fb521c0e 100644
--- a/versions/8.4.2/rules/lib/core/string.mdx
+++ b/versions/8.4.2/rules/lib/core/string.mdx
@@ -81,9 +81,9 @@ Returns the number of (non-overlapping) occurrences of substring `sub` in string
 
 | Parameter | Description |
 | --- | --- |
-| `sub` | [string](../core/string); required |
-| `start` | [int](../core/int); or `None`; default is `0` |
-| `end` | [int](../core/int); or `None`; default is `None`  optional position before which to restrict to search. |
+| `sub` | [string](/versions/8.4.2/rules/lib/core/string); required |
+| `start` | [int](/versions/8.4.2/rules/lib/core/int); or `None`; default is `0` |
+| `end` | [int](/versions/8.4.2/rules/lib/core/int); or `None`; default is `None`  optional position before which to restrict to search. |
 
 ## elems
 
@@ -105,9 +105,9 @@ Returns True if the string ends with `sub`, otherwise False, optionally restrict
 
 | Parameter | Description |
 | --- | --- |
-| `sub` | [string](../core/string); or [tuple](../core/tuple) of [string](../core/string)s; required  The suffix (or tuple of alternative suffixes) to match. |
-| `start` | [int](../core/int); or `None`; default is `0`  Test beginning at this position. |
-| `end` | [int](../core/int); or `None`; default is `None`  optional position at which to stop comparing. |
+| `sub` | [string](/versions/8.4.2/rules/lib/core/string); or [tuple](/versions/8.4.2/rules/lib/core/tuple) of [string](/versions/8.4.2/rules/lib/core/string)s; required  The suffix (or tuple of alternative suffixes) to match. |
+| `start` | [int](/versions/8.4.2/rules/lib/core/int); or `None`; default is `0`  Test beginning at this position. |
+| `end` | [int](/versions/8.4.2/rules/lib/core/int); or `None`; default is `None`  optional position at which to stop comparing. |
 
 ## find
 
@@ -121,9 +121,9 @@ Returns the first index where `sub` is found, or -1 if no such index exists, opt
 
 | Parameter | Description |
 | --- | --- |
-| `sub` | [string](../core/string); required  The substring to find. |
-| `start` | [int](../core/int); or `None`; default is `0`  Restrict to search from this position. |
-| `end` | [int](../core/int); or `None`; default is `None`  optional position before which to restrict to search. |
+| `sub` | [string](/versions/8.4.2/rules/lib/core/string); required  The substring to find. |
+| `start` | [int](/versions/8.4.2/rules/lib/core/int); or `None`; default is `0`  Restrict to search from this position. |
+| `end` | [int](/versions/8.4.2/rules/lib/core/int); or `None`; default is `None`  optional position before which to restrict to search. |
 
 ## format
 
@@ -131,7 +131,7 @@ Returns the first index where `sub` is found, or -1 if no such index exists, opt
 string string.format(*args, **kwargs)
 ```
 
-Perform string interpolation. Format strings contain replacement fields surrounded by curly braces `{}`. Anything that is not contained in braces is considered literal text, which is copied unchanged to the output.If you need to include a brace character in the literal text, it can be escaped by doubling: `{{` and `}}`A replacement field can be either a name, a number, or empty. Values are converted to strings using the [str](../globals/all#str) function.
+Perform string interpolation. Format strings contain replacement fields surrounded by curly braces `{}`. Anything that is not contained in braces is considered literal text, which is copied unchanged to the output.If you need to include a brace character in the literal text, it can be escaped by doubling: `{{` and `}}`A replacement field can be either a name, a number, or empty. Values are converted to strings using the [str](/versions/8.4.2/rules/lib/globals/all#str) function.
 
 ```
 # Access in order:
@@ -161,9 +161,9 @@ Returns the first index where `sub` is found, or raises an error if no such inde
 
 | Parameter | Description |
 | --- | --- |
-| `sub` | [string](../core/string); required  The substring to find. |
-| `start` | [int](../core/int); or `None`; default is `0`  Restrict to search from this position. |
-| `end` | [int](../core/int); or `None`; default is `None`  optional position before which to restrict to search. |
+| `sub` | [string](/versions/8.4.2/rules/lib/core/string); required  The substring to find. |
+| `start` | [int](/versions/8.4.2/rules/lib/core/int); or `None`; default is `0`  Restrict to search from this position. |
+| `end` | [int](/versions/8.4.2/rules/lib/core/int); or `None`; default is `None`  optional position before which to restrict to search. |
 
 ## isalnum
 
@@ -263,7 +263,7 @@ Returns a copy of the string where leading characters that appear in `chars` are
 
 | Parameter | Description |
 | --- | --- |
-| `chars` | [string](../core/string); or `None`; default is `None`  The characters to remove, or all whitespace if None. |
+| `chars` | [string](/versions/8.4.2/rules/lib/core/string); or `None`; default is `None`  The characters to remove, or all whitespace if None. |
 
 ## partition
 
@@ -277,7 +277,7 @@ Splits the input string at the first occurrence of the separator `sep` and retur
 
 | Parameter | Description |
 | --- | --- |
-| `sep` | [string](../core/string); required  The string to split on. |
+| `sep` | [string](/versions/8.4.2/rules/lib/core/string); required  The string to split on. |
 
 ## removeprefix
 
@@ -291,7 +291,7 @@ If the string starts with `prefix`, returns a new string with the prefix removed
 
 | Parameter | Description |
 | --- | --- |
-| `prefix` | [string](../core/string); required  The prefix to remove if present. |
+| `prefix` | [string](/versions/8.4.2/rules/lib/core/string); required  The prefix to remove if present. |
 
 ## removesuffix
 
@@ -305,7 +305,7 @@ If the string ends with `suffix`, returns a new string with the suffix removed.
 
 | Parameter | Description |
 | --- | --- |
-| `suffix` | [string](../core/string); required  The suffix to remove if present. |
+| `suffix` | [string](/versions/8.4.2/rules/lib/core/string); required  The suffix to remove if present. |
 
 ## replace
 
@@ -319,9 +319,9 @@ Returns a copy of the string in which the occurrences of `old` have been replace
 
 | Parameter | Description |
 | --- | --- |
-| `old` | [string](../core/string); required  The string to be replaced. |
-| `new` | [string](../core/string); required  The string to replace with. |
-| `count` | [int](../core/int); default is `-1`  The maximum number of replacements. If omitted, or if the value is negative, there is no limit. |
+| `old` | [string](/versions/8.4.2/rules/lib/core/string); required  The string to be replaced. |
+| `new` | [string](/versions/8.4.2/rules/lib/core/string); required  The string to replace with. |
+| `count` | [int](/versions/8.4.2/rules/lib/core/int); default is `-1`  The maximum number of replacements. If omitted, or if the value is negative, there is no limit. |
 
 ## rfind
 
@@ -335,9 +335,9 @@ Returns the last index where `sub` is found, or -1 if no such index exists, opti
 
 | Parameter | Description |
 | --- | --- |
-| `sub` | [string](../core/string); required  The substring to find. |
-| `start` | [int](../core/int); or `None`; default is `0`  Restrict to search from this position. |
-| `end` | [int](../core/int); or `None`; default is `None`  optional position before which to restrict to search. |
+| `sub` | [string](/versions/8.4.2/rules/lib/core/string); required  The substring to find. |
+| `start` | [int](/versions/8.4.2/rules/lib/core/int); or `None`; default is `0`  Restrict to search from this position. |
+| `end` | [int](/versions/8.4.2/rules/lib/core/int); or `None`; default is `None`  optional position before which to restrict to search. |
 
 ## rindex
 
@@ -351,9 +351,9 @@ Returns the last index where `sub` is found, or raises an error if no such index
 
 | Parameter | Description |
 | --- | --- |
-| `sub` | [string](../core/string); required  The substring to find. |
-| `start` | [int](../core/int); or `None`; default is `0`  Restrict to search from this position. |
-| `end` | [int](../core/int); or `None`; default is `None`  optional position before which to restrict to search. |
+| `sub` | [string](/versions/8.4.2/rules/lib/core/string); required  The substring to find. |
+| `start` | [int](/versions/8.4.2/rules/lib/core/int); or `None`; default is `0`  Restrict to search from this position. |
+| `end` | [int](/versions/8.4.2/rules/lib/core/int); or `None`; default is `None`  optional position before which to restrict to search. |
 
 ## rpartition
 
@@ -367,7 +367,7 @@ Splits the input string at the last occurrence of the separator `sep` and return
 
 | Parameter | Description |
 | --- | --- |
-| `sep` | [string](../core/string); required  The string to split on. |
+| `sep` | [string](/versions/8.4.2/rules/lib/core/string); required  The string to split on. |
 
 ## rsplit
 
@@ -381,8 +381,8 @@ Returns a list of all the words in the string, using `sep` as the separator, opt
 
 | Parameter | Description |
 | --- | --- |
-| `sep` | [string](../core/string); required  The string to split on. |
-| `maxsplit` | [int](../core/int); or `None`; default is `None`  The maximum number of splits. |
+| `sep` | [string](/versions/8.4.2/rules/lib/core/string); required  The string to split on. |
+| `maxsplit` | [int](/versions/8.4.2/rules/lib/core/int); or `None`; default is `None`  The maximum number of splits. |
 
 ## rstrip
 
@@ -400,7 +400,7 @@ Returns a copy of the string where trailing characters that appear in `chars` ar
 
 | Parameter | Description |
 | --- | --- |
-| `chars` | [string](../core/string); or `None`; default is `None`  The characters to remove, or all whitespace if None. |
+| `chars` | [string](/versions/8.4.2/rules/lib/core/string); or `None`; default is `None`  The characters to remove, or all whitespace if None. |
 
 ## split
 
@@ -414,8 +414,8 @@ Returns a list of all the words in the string, using `sep` as the separator, opt
 
 | Parameter | Description |
 | --- | --- |
-| `sep` | [string](../core/string); required  The string to split on. |
-| `maxsplit` | [int](../core/int); or `None`; default is `None`  The maximum number of splits. |
+| `sep` | [string](/versions/8.4.2/rules/lib/core/string); required  The string to split on. |
+| `maxsplit` | [int](/versions/8.4.2/rules/lib/core/int); or `None`; default is `None`  The maximum number of splits. |
 
 ## splitlines
 
@@ -429,7 +429,7 @@ Splits the string at line boundaries ('\n', '\r\n', '\r') and returns the result
 
 | Parameter | Description |
 | --- | --- |
-| `keepends` | [bool](../core/bool); default is `False`  Whether the line breaks should be included in the resulting list. |
+| `keepends` | [bool](/versions/8.4.2/rules/lib/core/bool); default is `False`  Whether the line breaks should be included in the resulting list. |
 
 ## startswith
 
@@ -443,9 +443,9 @@ Returns True if the string starts with `sub`, otherwise False, optionally restri
 
 | Parameter | Description |
 | --- | --- |
-| `sub` | [string](../core/string); or [tuple](../core/tuple) of [string](../core/string)s; required  The prefix (or tuple of alternative prefixes) to match. |
-| `start` | [int](../core/int); or `None`; default is `0`  Test beginning at this position. |
-| `end` | [int](../core/int); or `None`; default is `None`  Stop comparing at this position. |
+| `sub` | [string](/versions/8.4.2/rules/lib/core/string); or [tuple](/versions/8.4.2/rules/lib/core/tuple) of [string](/versions/8.4.2/rules/lib/core/string)s; required  The prefix (or tuple of alternative prefixes) to match. |
+| `start` | [int](/versions/8.4.2/rules/lib/core/int); or `None`; default is `0`  Test beginning at this position. |
+| `end` | [int](/versions/8.4.2/rules/lib/core/int); or `None`; default is `None`  Stop comparing at this position. |
 
 ## strip
 
@@ -463,7 +463,7 @@ Returns a copy of the string where leading or trailing characters that appear in
 
 | Parameter | Description |
 | --- | --- |
-| `chars` | [string](../core/string); or `None`; default is `None`  The characters to remove, or all whitespace if None. |
+| `chars` | [string](/versions/8.4.2/rules/lib/core/string); or `None`; default is `None`  The characters to remove, or all whitespace if None. |
 
 ## title
 
diff --git a/versions/8.4.2/rules/lib/fragments.mdx b/versions/8.4.2/rules/lib/fragments.mdx
index 39548b5f..bb1d662b 100644
--- a/versions/8.4.2/rules/lib/fragments.mdx
+++ b/versions/8.4.2/rules/lib/fragments.mdx
@@ -2,7 +2,7 @@
 title: 'Configuration Fragments'
 ---
 
-Configuration fragments give rules access to language-specific parts of [configuration](builtins/configuration).
+Configuration fragments give rules access to language-specific parts of [configuration](/versions/8.4.2/rules/lib/builtins/configuration).
 
 Rule implementations can get them using `ctx.fragments.[fragment name]`
 
diff --git a/versions/8.4.2/rules/lib/fragments/apple.mdx b/versions/8.4.2/rules/lib/fragments/apple.mdx
index f7e8daff..a3bc8568 100644
--- a/versions/8.4.2/rules/lib/fragments/apple.mdx
+++ b/versions/8.4.2/rules/lib/fragments/apple.mdx
@@ -22,7 +22,7 @@ The platform of the current configuration for the given platform type. This shou
 
 | Parameter | Description |
 | --- | --- |
-| `platform_type` | [string](../core/string); required  The apple platform type. |
+| `platform_type` | [string](/versions/8.4.2/rules/lib/core/string); required  The apple platform type. |
 
 ## single\_arch\_cpu
 
diff --git a/versions/8.4.2/rules/lib/fragments/coverage.mdx b/versions/8.4.2/rules/lib/fragments/coverage.mdx
index a867b4f2..b230303b 100644
--- a/versions/8.4.2/rules/lib/fragments/coverage.mdx
+++ b/versions/8.4.2/rules/lib/fragments/coverage.mdx
@@ -14,7 +14,7 @@ A configuration fragment representing the coverage configuration.
 Label coverage.output_generator
 ```
 
-Returns the label pointed to by the [`--coverage_output_generator`](https://bazel.build/versions/8.4.2/reference/command-line-reference#flag--coverage_output_generator) option if coverage collection is enabled, otherwise returns `None`. Can be accessed with [`configuration_field`](../globals/bzl#configuration_field):
+Returns the label pointed to by the [`--coverage_output_generator`](https://bazel.build/versions/8.4.2/reference/command-line-reference#flag--coverage_output_generator) option if coverage collection is enabled, otherwise returns `None`. Can be accessed with [`configuration_field`](/versions/8.4.2/rules/lib/globals/bzl#configuration_field):
 
 ```
 attr.label(
diff --git a/versions/8.4.2/rules/lib/fragments/cpp.mdx b/versions/8.4.2/rules/lib/fragments/cpp.mdx
index c3e49cd9..ea29fc4d 100644
--- a/versions/8.4.2/rules/lib/fragments/cpp.mdx
+++ b/versions/8.4.2/rules/lib/fragments/cpp.mdx
@@ -46,7 +46,7 @@ The flags passed to Bazel by [`--copt`](/versions/8.4.2/docs/user-manual#flag--c
 Label cpp.custom_malloc
 ```
 
-Returns label pointed to by [`--custom_malloc`](/versions/8.4.2/docs/user-manual#flag--custom_malloc) option. Can be accessed with [`configuration_field`](../globals/bzl#configuration_field):
+Returns label pointed to by [`--custom_malloc`](/versions/8.4.2/docs/user-manual#flag--custom_malloc) option. Can be accessed with [`configuration_field`](/versions/8.4.2/rules/lib/globals/bzl#configuration_field):
 
 ```
 attr.label(
diff --git a/versions/8.4.2/rules/lib/globals/all.mdx b/versions/8.4.2/rules/lib/globals/all.mdx
index 45106d41..d1747457 100644
--- a/versions/8.4.2/rules/lib/globals/all.mdx
+++ b/versions/8.4.2/rules/lib/globals/all.mdx
@@ -50,7 +50,7 @@ abs(-2.3) == 2.3
 
 | Parameter | Description |
 | --- | --- |
-| `x` | [int](../core/int); or [float](../core/float); required  A number (int or float) |
+| `x` | [int](/versions/8.4.2/rules/lib/core/int); or [float](/versions/8.4.2/rules/lib/core/float); required  A number (int or float) |
 
 ## all
 
@@ -110,7 +110,7 @@ Constructor for the bool type. It returns `False` if the object is `None`, `Fals
 dict dict(pairs=[], **kwargs)
 ```
 
-Creates a [dictionary](../core/dict) from an optional positional argument and an optional set of keyword arguments. In the case where the same key is given multiple times, the last value will be used. Entries supplied via keyword arguments are considered to come after entries supplied via the positional argument.
+Creates a [dictionary](/versions/8.4.2/rules/lib/core/dict) from an optional positional argument and an optional set of keyword arguments. In the case where the same key is given multiple times, the last value will be used. Entries supplied via keyword arguments are considered to come after entries supplied via the positional argument.
 
 ### Parameters
 
@@ -150,7 +150,7 @@ enumerate([24, 21, 84]) == [(0, 24), (1, 21), (2, 84)]
 | Parameter | Description |
 | --- | --- |
 | `list` | required  input sequence. |
-| `start` | [int](../core/int); default is `0`  start index. |
+| `start` | [int](/versions/8.4.2/rules/lib/core/int); default is `0`  start index. |
 
 ## fail
 
@@ -165,8 +165,8 @@ Causes execution to fail with an error.
 | Parameter | Description |
 | --- | --- |
 | `msg` | default is `None`  Deprecated: use positional arguments instead. This argument acts like an implicit leading positional argument. |
-| `attr` | [string](../core/string); or `None`; default is `None`  Deprecated. Causes an optional prefix containing this string to be added to the error message. |
-| `sep` | [string](../core/string); default is `" "`  The separator string between the objects, default is space (" "). |
+| `attr` | [string](/versions/8.4.2/rules/lib/core/string); or `None`; default is `None`  Deprecated. Causes an optional prefix containing this string to be added to the error message. |
+| `sep` | [string](/versions/8.4.2/rules/lib/core/string); default is `" "`  The separator string between the objects, default is space (" "). |
 | `args` | required  A list of values, formatted with debugPrint (which is equivalent to str by default) and joined with sep (defaults to " "), that appear in the error message. |
 
 ## float
@@ -205,7 +205,7 @@ getattr(ctx.attr, "myattr", "mydefault")
 | Parameter | Description |
 | --- | --- |
 | `x` | required  The struct whose attribute is accessed. |
-| `name` | [string](../core/string); required  The name of the struct attribute. |
+| `name` | [string](/versions/8.4.2/rules/lib/core/string); required  The name of the struct attribute. |
 | `default` | default is `unbound`  The default value to return in case the struct doesn't have an attribute of the given name. |
 
 ## hasattr
@@ -225,7 +225,7 @@ hasattr(ctx.attr, "myattr")
 | Parameter | Description |
 | --- | --- |
 | `x` | required |
-| `name` | [string](../core/string); required  The name of the attribute. |
+| `name` | [string](/versions/8.4.2/rules/lib/core/string); required  The name of the attribute. |
 
 ## hash
 
@@ -245,7 +245,7 @@ Hashing of values besides strings is not currently supported.
 
 | Parameter | Description |
 | --- | --- |
-| `value` | [string](../core/string); required  String value to hash. |
+| `value` | [string](/versions/8.4.2/rules/lib/core/string); required  String value to hash. |
 
 ## int
 
@@ -372,7 +372,7 @@ Using `print` in production code is discouraged due to the spam it creates for u
 
 | Parameter | Description |
 | --- | --- |
-| `sep` | [string](../core/string); default is `" "`  The separator string between the objects, default is space (" "). |
+| `sep` | [string](/versions/8.4.2/rules/lib/core/string); default is `" "`  The separator string between the objects, default is space (" "). |
 | `args` | required  The objects to print. |
 
 ## range
@@ -393,9 +393,9 @@ range(3, 0, -1) == [3, 2, 1]
 
 | Parameter | Description |
 | --- | --- |
-| `start_or_stop` | [int](../core/int); required  Value of the start element if stop is provided, otherwise value of stop and the actual start is 0 |
-| `stop_or_none` | [int](../core/int); or `None`; default is `None`  optional index of the first item *not* to be included in the resulting list; generation of the list stops before `stop` is reached. |
-| `step` | [int](../core/int); default is `1`  The increment (default is 1). It may be negative. |
+| `start_or_stop` | [int](/versions/8.4.2/rules/lib/core/int); required  Value of the start element if stop is provided, otherwise value of stop and the actual start is 0 |
+| `stop_or_none` | [int](/versions/8.4.2/rules/lib/core/int); or `None`; default is `None`  optional index of the first item *not* to be included in the resulting list; generation of the list stops before `stop` is reached. |
+| `step` | [int](/versions/8.4.2/rules/lib/core/int); default is `1`  The increment (default is 1). It may be negative. |
 
 ## repr
 
@@ -439,7 +439,7 @@ reversed([3, 5, 4]) == [4, 5, 3]
 set set(elements=[])
 ```
 
-Creates a new [set](../core/set) containing the unique elements of a given
+Creates a new [set](/versions/8.4.2/rules/lib/core/set) containing the unique elements of a given
 iterable, preserving iteration order.
 
 If called with no argument, `set()` returns a new empty set.
@@ -479,7 +479,7 @@ sorted(["two", "three", "four"], key = len) == ["two", "four", "three"]  # sort
 | --- | --- |
 | `iterable` | iterable; required  The iterable sequence to sort. |
 | `key` | callable; or `None`; default is `None`  An optional function applied to each element before comparison. |
-| `reverse` | [bool](../core/bool); default is `False`  Return results in descending order. |
+| `reverse` | [bool](/versions/8.4.2/rules/lib/core/bool); default is `False`  Return results in descending order. |
 
 ## str
 
diff --git a/versions/8.4.2/rules/lib/globals/build.mdx b/versions/8.4.2/rules/lib/globals/build.mdx
index 8d0d6775..3a04e08f 100644
--- a/versions/8.4.2/rules/lib/globals/build.mdx
+++ b/versions/8.4.2/rules/lib/globals/build.mdx
@@ -28,7 +28,7 @@ Methods available in BUILD files. See also the Build Encyclopedia for extra [fun
 depset depset(direct=None, order="default", *, transitive=None)
 ```
 
-Creates a [depset](../builtins/depset). The `direct` parameter is a list of direct elements of the depset, and `transitive` parameter is a list of depsets whose elements become indirect elements of the created depset. The order in which elements are returned when the depset is converted to a list is specified by the `order` parameter. See the [Depsets overview](https://bazel.build/versions/8.4.2/extending/depsets) for more information.
+Creates a [depset](/versions/8.4.2/rules/lib/builtins/depset). The `direct` parameter is a list of direct elements of the depset, and `transitive` parameter is a list of depsets whose elements become indirect elements of the created depset. The order in which elements are returned when the depset is converted to a list is specified by the `order` parameter. See the [Depsets overview](https://bazel.build/versions/8.4.2/extending/depsets) for more information.
 
 All elements (direct and indirect) of a depset must be of the same type, as obtained by the expression `type(x)`.
 
@@ -42,9 +42,9 @@ The order of the created depset should be *compatible* with the order of its `tr
 
 | Parameter | Description |
 | --- | --- |
-| `direct` | [sequence](../core/list); or `None`; default is `None`  A list of *direct* elements of a depset. |
-| `order` | [string](../core/string); default is `"default"`  The traversal strategy for the new depset. See [here](../builtins/depset) for the possible values. |
-| `transitive` | [sequence](../core/list) of [depset](../builtins/depset)s; or `None`; default is `None`  A list of depsets whose elements will become indirect elements of the depset. |
+| `direct` | [sequence](/versions/8.4.2/rules/lib/core/list); or `None`; default is `None`  A list of *direct* elements of a depset. |
+| `order` | [string](/versions/8.4.2/rules/lib/core/string); default is `"default"`  The traversal strategy for the new depset. See [here](/versions/8.4.2/rules/lib/builtins/depset) for the possible values. |
+| `transitive` | [sequence](/versions/8.4.2/rules/lib/core/list) of [depset](/versions/8.4.2/rules/lib/builtins/depset)s; or `None`; default is `None`  A list of depsets whose elements will become indirect elements of the depset. |
 
 ## existing\_rule
 
@@ -72,7 +72,7 @@ If possible, avoid using this function. It makes BUILD files brittle and order-d
 
 | Parameter | Description |
 | --- | --- |
-| `name` | [string](../core/string); required  The name of the target. |
+| `name` | [string](/versions/8.4.2/rules/lib/core/string); required  The name of the target. |
 
 ## existing\_rules
 
@@ -98,9 +98,9 @@ Specifies a list of files belonging to this package that are exported to other p
 
 | Parameter | Description |
 | --- | --- |
-| `srcs` | [sequence](../core/list) of [string](../core/string)s; required  The list of files to export. |
-| `visibility` | [sequence](../core/list); or `None`; default is `None`  A visibility declaration can to be specified. The files will be visible to the targets specified. If no visibility is specified, the files will be visible to every package. |
-| `licenses` | [sequence](../core/list) of [string](../core/string)s; or `None`; default is `None`  Licenses to be specified. |
+| `srcs` | [sequence](/versions/8.4.2/rules/lib/core/list) of [string](/versions/8.4.2/rules/lib/core/string)s; required  The list of files to export. |
+| `visibility` | [sequence](/versions/8.4.2/rules/lib/core/list); or `None`; default is `None`  A visibility declaration can to be specified. The files will be visible to the targets specified. If no visibility is specified, the files will be visible to every package. |
+| `licenses` | [sequence](/versions/8.4.2/rules/lib/core/list) of [string](/versions/8.4.2/rules/lib/core/string)s; or `None`; default is `None`  Licenses to be specified. |
 
 ## glob
 
@@ -119,9 +119,9 @@ If the `exclude_directories` argument is enabled (set to `1`), files of type dir
 
 | Parameter | Description |
 | --- | --- |
-| `include` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  The list of glob patterns to include. |
-| `exclude` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  The list of glob patterns to exclude. |
-| `exclude_directories` | [int](../core/int); default is `1`  A flag whether to exclude directories or not. |
+| `include` | [sequence](/versions/8.4.2/rules/lib/core/list) of [string](/versions/8.4.2/rules/lib/core/string)s; default is `[]`  The list of glob patterns to include. |
+| `exclude` | [sequence](/versions/8.4.2/rules/lib/core/list) of [string](/versions/8.4.2/rules/lib/core/string)s; default is `[]`  The list of glob patterns to exclude. |
+| `exclude_directories` | [int](/versions/8.4.2/rules/lib/core/int); default is `1`  A flag whether to exclude directories or not. |
 | `allow_empty` | default is `unbound`  Whether we allow glob patterns to match nothing. If `allow\_empty` is False, each individual include pattern must match something and also the final result must be non-empty (after the matches of the `exclude` patterns are excluded). |
 
 ## module\_name
@@ -168,9 +168,9 @@ This function defines a set of packages and assigns a label to the group. The la
 
 | Parameter | Description |
 | --- | --- |
-| `name` | [string](../core/string); required  The unique name for this rule. |
-| `packages` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  A complete enumeration of packages in this group. |
-| `includes` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  Other package groups that are included in this one. |
+| `name` | [string](/versions/8.4.2/rules/lib/core/string); required  The unique name for this rule. |
+| `packages` | [sequence](/versions/8.4.2/rules/lib/core/list) of [string](/versions/8.4.2/rules/lib/core/string)s; default is `[]`  A complete enumeration of packages in this group. |
+| `includes` | [sequence](/versions/8.4.2/rules/lib/core/list) of [string](/versions/8.4.2/rules/lib/core/string)s; default is `[]`  Other package groups that are included in this one. |
 
 ## package\_name
 
@@ -186,19 +186,19 @@ The name of the package being evaluated, without the repository name. For exampl
 Label package_relative_label(input)
 ```
 
-Converts the input string into a [Label](../builtins/Label) object, in the context of the package currently being initialized (that is, the `BUILD` file for which the current macro is executing). If the input is already a `Label`, it is returned unchanged.
+Converts the input string into a [Label](/versions/8.4.2/rules/lib/builtins/Label) object, in the context of the package currently being initialized (that is, the `BUILD` file for which the current macro is executing). If the input is already a `Label`, it is returned unchanged.
 
 This function may only be called while evaluating a BUILD file and the macros it directly or indirectly calls; it may not be called in (for instance) a rule implementation function.
 
 The result of this function is the same `Label` value as would be produced by passing the given string to a label-valued attribute of a target declared in the BUILD file.
 
-*Usage note:* The difference between this function and [Label()](../builtins/Label#Label) is that `Label()` uses the context of the package of the `.bzl` file that called it, not the package of the `BUILD` file. Use `Label()` when you need to refer to a fixed target that is hardcoded into the macro, such as a compiler. Use `package_relative_label()` when you need to normalize a label string supplied by the BUILD file to a `Label` object. (There is no way to convert a string to a `Label` in the context of a package other than the BUILD file or the calling .bzl file. For that reason, outer macros should always prefer to pass Label objects to inner macros rather than label strings.)
+*Usage note:* The difference between this function and [Label()](/versions/8.4.2/rules/lib/builtins/Label#Label) is that `Label()` uses the context of the package of the `.bzl` file that called it, not the package of the `BUILD` file. Use `Label()` when you need to refer to a fixed target that is hardcoded into the macro, such as a compiler. Use `package_relative_label()` when you need to normalize a label string supplied by the BUILD file to a `Label` object. (There is no way to convert a string to a `Label` in the context of a package other than the BUILD file or the calling .bzl file. For that reason, outer macros should always prefer to pass Label objects to inner macros rather than label strings.)
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `input` | [string](../core/string); or [Label](../builtins/Label); required  The input label string or Label object. If a Label object is passed, it's returned as is. |
+| `input` | [string](/versions/8.4.2/rules/lib/core/string); or [Label](/versions/8.4.2/rules/lib/builtins/Label); required  The input label string or Label object. If a Label object is passed, it's returned as is. |
 
 ## repo\_name
 
@@ -231,8 +231,8 @@ unknown select(x, no_match_error='')
 
 | Parameter | Description |
 | --- | --- |
-| `x` | [dict](../core/dict); required |
-| `no_match_error` | [string](../core/string); default is `''`  Optional custom error to report if no condition matches. |
+| `x` | [dict](/versions/8.4.2/rules/lib/core/dict); required |
+| `no_match_error` | [string](/versions/8.4.2/rules/lib/core/string); default is `''`  Optional custom error to report if no condition matches. |
 
 ## subpackages
 
@@ -246,6 +246,6 @@ Returns a new mutable list of every direct subpackage of the current package, re
 
 | Parameter | Description |
 | --- | --- |
-| `include` | [sequence](../core/list) of [string](../core/string)s; required  The list of glob patterns to include in subpackages scan. |
-| `exclude` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  The list of glob patterns to exclude from subpackages scan. |
-| `allow_empty` | [bool](../core/bool); default is `False`  Whether we fail if the call returns an empty list. By default empty list indicates potential error in BUILD file where the call to subpackages() is superflous. Setting to true allows this function to succeed in that case. |*
\ No newline at end of file
+| `include` | [sequence](/versions/8.4.2/rules/lib/core/list) of [string](/versions/8.4.2/rules/lib/core/string)s; required  The list of glob patterns to include in subpackages scan. |
+| `exclude` | [sequence](/versions/8.4.2/rules/lib/core/list) of [string](/versions/8.4.2/rules/lib/core/string)s; default is `[]`  The list of glob patterns to exclude from subpackages scan. |
+| `allow_empty` | [bool](/versions/8.4.2/rules/lib/core/bool); default is `False`  Whether we fail if the call returns an empty list. By default empty list indicates potential error in BUILD file where the call to subpackages() is superflous. Setting to true allows this function to succeed in that case. |*
\ No newline at end of file
diff --git a/versions/8.4.2/rules/lib/globals/bzl.mdx b/versions/8.4.2/rules/lib/globals/bzl.mdx
index 6a750477..d6cd42cc 100644
--- a/versions/8.4.2/rules/lib/globals/bzl.mdx
+++ b/versions/8.4.2/rules/lib/globals/bzl.mdx
@@ -28,7 +28,7 @@ Global methods available in all .bzl files.
 transition analysis_test_transition(settings)
 ```
 
-Creates a configuration transition to be applied on an analysis-test rule's dependencies. This transition may only be applied on attributes of rules with `analysis_test = True`. Such rules are restricted in capabilities (for example, the size of their dependency tree is limited), so transitions created using this function are limited in potential scope as compared to transitions created using [`transition()`](../builtins/transition).
+Creates a configuration transition to be applied on an analysis-test rule's dependencies. This transition may only be applied on attributes of rules with `analysis_test = True`. Such rules are restricted in capabilities (for example, the size of their dependency tree is limited), so transitions created using this function are limited in potential scope as compared to transitions created using [`transition()`](/versions/8.4.2/rules/lib/builtins/transition).
 
 This function is primarily designed to facilitate the [Analysis Test Framework](https://bazel.build/versions/8.4.2/rules/testing) core library. See its documentation (or its implementation) for best practices.
 
@@ -36,7 +36,7 @@ This function is primarily designed to facilitate the [Analysis Test Framework](
 
 | Parameter | Description |
 | --- | --- |
-| `settings` | [dict](../core/dict); required  A dictionary containing information about configuration settings which should be set by this configuration transition. Keys are build setting labels and values are their new post-transition values. All other settings are unchanged. Use this to declare specific configuration settings that an analysis test requires to be set in order to pass. |
+| `settings` | [dict](/versions/8.4.2/rules/lib/core/dict); required  A dictionary containing information about configuration settings which should be set by this configuration transition. Keys are build setting labels and values are their new post-transition values. All other settings are unchanged. Use this to declare specific configuration settings that an analysis test requires to be set in order to pass. |
 
 ## aspect
 
@@ -50,23 +50,23 @@ Creates a new aspect. The result of this function must be stored in a global val
 
 | Parameter | Description |
 | --- | --- |
-| `implementation` | [function](../core/function); required  A Starlark function that implements this aspect, with exactly two parameters: [Target](../builtins/Target) (the target to which the aspect is applied) and [ctx](../builtins/ctx) (the rule context which the target is created from). Attributes of the target are available via the `ctx.rule` field. This function is evaluated during the analysis phase for each application of an aspect to a target. |
-| `attr_aspects` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  List of attribute names. The aspect propagates along dependencies specified in the attributes of a target with these names. Common values here include `deps` and `exports`. The list can also contain a single string `"*"` to propagate along all dependencies of a target. |
-| `toolchains_aspects` | [sequence](../core/list); default is `[]`  List of toolchain types. The aspect propagates to target toolchains which match these toolchain types. |
-| `attrs` | [dict](../core/dict); default is `{}`  A dictionary declaring all the attributes of the aspect. It maps from an attribute name to an attribute object, like `attr.label` or `attr.string` (see [`attr`](../toplevel/attr) module). Aspect attributes are available to implementation function as fields of `ctx` parameter. Implicit attributes starting with `_` must have default values, and have type `label` or `label_list`.  Explicit attributes must have type `string`, and must use the `values` restriction. Explicit attributes restrict the aspect to only be used with rules that have attributes of the same name, type, and valid values according to the restriction.  Declared attributes will convert `None` to the default value. |
-| `required_providers` | [sequence](../core/list); default is `[]`  This attribute allows the aspect to limit its propagation to only the targets whose rules advertise its required providers. The value must be a list containing either individual providers or lists of providers but not both. For example, `[[FooInfo], [BarInfo], [BazInfo, QuxInfo]]` is a valid value while `[FooInfo, BarInfo, [BazInfo, QuxInfo]]` is not valid. An unnested list of providers will automatically be converted to a list containing one list of providers. That is, `[FooInfo, BarInfo]` will automatically be converted to `[[FooInfo, BarInfo]]`. To make some rule (e.g. `some_rule`) targets visible to an aspect, `some_rule` must advertise all providers from at least one of the required providers lists. For example, if the `required_providers` of an aspect are `[[FooInfo], [BarInfo], [BazInfo, QuxInfo]]`, this aspect can see `some_rule` targets if and only if `some_rule` provides `FooInfo`, *or* `BarInfo`, *or* both `BazInfo` *and* `QuxInfo`. |
-| `required_aspect_providers` | [sequence](../core/list); default is `[]`  This attribute allows this aspect to inspect other aspects. The value must be a list containing either individual providers or lists of providers but not both. For example, `[[FooInfo], [BarInfo], [BazInfo, QuxInfo]]` is a valid value while `[FooInfo, BarInfo, [BazInfo, QuxInfo]]` is not valid. An unnested list of providers will automatically be converted to a list containing one list of providers. That is, `[FooInfo, BarInfo]` will automatically be converted to `[[FooInfo, BarInfo]]`. To make another aspect (e.g. `other_aspect`) visible to this aspect, `other_aspect` must provide all providers from at least one of the lists. In the example of `[[FooInfo], [BarInfo], [BazInfo, QuxInfo]]`, this aspect can see `other_aspect` if and only if `other_aspect` provides `FooInfo`, *or* `BarInfo`, *or* both `BazInfo` *and* `QuxInfo`. |
-| `provides` | [sequence](../core/list); default is `[]`  A list of providers that the implementation function must return. It is an error if the implementation function omits any of the types of providers listed here from its return value. However, the implementation function may return additional providers not listed here. Each element of the list is an `*Info` object returned by [`provider()`](../globals/bzl#provider), except that a legacy provider is represented by its string name instead.When a target of the rule is used as a dependency for a target that declares a required provider, it is not necessary to specify that provider here. It is enough that the implementation function returns it. However, it is considered best practice to specify it, even though this is not required. The [`required_providers`](../globals/bzl#aspect.required_providers) field of an [aspect](../globals/bzl#aspect) does, however, require that providers are specified here. |
-| `requires` | [sequence](../core/list) of [Aspect](../builtins/Aspect)s; default is `[]`  List of aspects required to be propagated before this aspect. |
-| `fragments` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  List of names of configuration fragments that the aspect requires in target configuration. |
-| `host_fragments` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  List of names of configuration fragments that the aspect requires in host configuration. |
-| `toolchains` | [sequence](../core/list); default is `[]`  If set, the set of toolchains this aspect requires. The list can contain String, Label, or StarlarkToolchainTypeApi objects, in any combination. Toolchains will be found by checking the current platform, and provided to the aspect implementation via `ctx.toolchain`. |
-| `incompatible_use_toolchain_transition` | [bool](../core/bool); default is `False`  Deprecated, this is no longer in use and should be removed. |
-| `doc` | [string](../core/string); or `None`; default is `None`  A description of the aspect that can be extracted by documentation generating tools. |
-| `apply_to_generating_rules` | [bool](../core/bool); default is `False`  If true, the aspect will, when applied to an output file, instead apply to the output file's generating rule. For example, suppose an aspect propagates transitively through attribute `deps` and it is applied to target `alpha`. Suppose `alpha` has `deps = [':beta\_output']`, where `beta\_output` is a declared output of a target `beta`. Suppose `beta` has a target `charlie` as one of its `deps`. If `apply\_to\_generating\_rules=True` for the aspect, then the aspect will propagate through `alpha`, `beta`, and `charlie`. If False, then the aspect will propagate only to `alpha`.  False by default. |
-| `exec_compatible_with` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  A list of constraints on the execution platform that apply to all instances of this aspect. |
-| `exec_groups` | [dict](../core/dict); or `None`; default is `None`  Dict of execution group name (string) to [`exec_group`s](../globals/bzl#exec_group). If set, allows aspects to run actions on multiple execution platforms within a single instance. See [execution groups documentation](/versions/8.4.2/reference/exec-groups) for more info. |
-| `subrules` | [sequence](../core/list) of [Subrule](../builtins/Subrule)s; default is `[]`  Experimental: list of subrules used by this aspect. |
+| `implementation` | [function](/versions/8.4.2/rules/lib/core/function); required  A Starlark function that implements this aspect, with exactly two parameters: [Target](/versions/8.4.2/rules/lib/builtins/Target) (the target to which the aspect is applied) and [ctx](/versions/8.4.2/rules/lib/builtins/ctx) (the rule context which the target is created from). Attributes of the target are available via the `ctx.rule` field. This function is evaluated during the analysis phase for each application of an aspect to a target. |
+| `attr_aspects` | [sequence](/versions/8.4.2/rules/lib/core/list) of [string](/versions/8.4.2/rules/lib/core/string)s; default is `[]`  List of attribute names. The aspect propagates along dependencies specified in the attributes of a target with these names. Common values here include `deps` and `exports`. The list can also contain a single string `"*"` to propagate along all dependencies of a target. |
+| `toolchains_aspects` | [sequence](/versions/8.4.2/rules/lib/core/list); default is `[]`  List of toolchain types. The aspect propagates to target toolchains which match these toolchain types. |
+| `attrs` | [dict](/versions/8.4.2/rules/lib/core/dict); default is `{}`  A dictionary declaring all the attributes of the aspect. It maps from an attribute name to an attribute object, like `attr.label` or `attr.string` (see [`attr`](/versions/8.4.2/rules/lib/toplevel/attr) module). Aspect attributes are available to implementation function as fields of `ctx` parameter. Implicit attributes starting with `_` must have default values, and have type `label` or `label_list`.  Explicit attributes must have type `string`, and must use the `values` restriction. Explicit attributes restrict the aspect to only be used with rules that have attributes of the same name, type, and valid values according to the restriction.  Declared attributes will convert `None` to the default value. |
+| `required_providers` | [sequence](/versions/8.4.2/rules/lib/core/list); default is `[]`  This attribute allows the aspect to limit its propagation to only the targets whose rules advertise its required providers. The value must be a list containing either individual providers or lists of providers but not both. For example, `[[FooInfo], [BarInfo], [BazInfo, QuxInfo]]` is a valid value while `[FooInfo, BarInfo, [BazInfo, QuxInfo]]` is not valid. An unnested list of providers will automatically be converted to a list containing one list of providers. That is, `[FooInfo, BarInfo]` will automatically be converted to `[[FooInfo, BarInfo]]`. To make some rule (e.g. `some_rule`) targets visible to an aspect, `some_rule` must advertise all providers from at least one of the required providers lists. For example, if the `required_providers` of an aspect are `[[FooInfo], [BarInfo], [BazInfo, QuxInfo]]`, this aspect can see `some_rule` targets if and only if `some_rule` provides `FooInfo`, *or* `BarInfo`, *or* both `BazInfo` *and* `QuxInfo`. |
+| `required_aspect_providers` | [sequence](/versions/8.4.2/rules/lib/core/list); default is `[]`  This attribute allows this aspect to inspect other aspects. The value must be a list containing either individual providers or lists of providers but not both. For example, `[[FooInfo], [BarInfo], [BazInfo, QuxInfo]]` is a valid value while `[FooInfo, BarInfo, [BazInfo, QuxInfo]]` is not valid. An unnested list of providers will automatically be converted to a list containing one list of providers. That is, `[FooInfo, BarInfo]` will automatically be converted to `[[FooInfo, BarInfo]]`. To make another aspect (e.g. `other_aspect`) visible to this aspect, `other_aspect` must provide all providers from at least one of the lists. In the example of `[[FooInfo], [BarInfo], [BazInfo, QuxInfo]]`, this aspect can see `other_aspect` if and only if `other_aspect` provides `FooInfo`, *or* `BarInfo`, *or* both `BazInfo` *and* `QuxInfo`. |
+| `provides` | [sequence](/versions/8.4.2/rules/lib/core/list); default is `[]`  A list of providers that the implementation function must return. It is an error if the implementation function omits any of the types of providers listed here from its return value. However, the implementation function may return additional providers not listed here. Each element of the list is an `*Info` object returned by [`provider()`](/versions/8.4.2/rules/lib/globals/bzl#provider), except that a legacy provider is represented by its string name instead.When a target of the rule is used as a dependency for a target that declares a required provider, it is not necessary to specify that provider here. It is enough that the implementation function returns it. However, it is considered best practice to specify it, even though this is not required. The [`required_providers`](/versions/8.4.2/rules/lib/globals/bzl#aspect.required_providers) field of an [aspect](/versions/8.4.2/rules/lib/globals/bzl#aspect) does, however, require that providers are specified here. |
+| `requires` | [sequence](/versions/8.4.2/rules/lib/core/list) of [Aspect](/versions/8.4.2/rules/lib/builtins/Aspect)s; default is `[]`  List of aspects required to be propagated before this aspect. |
+| `fragments` | [sequence](/versions/8.4.2/rules/lib/core/list) of [string](/versions/8.4.2/rules/lib/core/string)s; default is `[]`  List of names of configuration fragments that the aspect requires in target configuration. |
+| `host_fragments` | [sequence](/versions/8.4.2/rules/lib/core/list) of [string](/versions/8.4.2/rules/lib/core/string)s; default is `[]`  List of names of configuration fragments that the aspect requires in host configuration. |
+| `toolchains` | [sequence](/versions/8.4.2/rules/lib/core/list); default is `[]`  If set, the set of toolchains this aspect requires. The list can contain String, Label, or StarlarkToolchainTypeApi objects, in any combination. Toolchains will be found by checking the current platform, and provided to the aspect implementation via `ctx.toolchain`. |
+| `incompatible_use_toolchain_transition` | [bool](/versions/8.4.2/rules/lib/core/bool); default is `False`  Deprecated, this is no longer in use and should be removed. |
+| `doc` | [string](/versions/8.4.2/rules/lib/core/string); or `None`; default is `None`  A description of the aspect that can be extracted by documentation generating tools. |
+| `apply_to_generating_rules` | [bool](/versions/8.4.2/rules/lib/core/bool); default is `False`  If true, the aspect will, when applied to an output file, instead apply to the output file's generating rule. For example, suppose an aspect propagates transitively through attribute `deps` and it is applied to target `alpha`. Suppose `alpha` has `deps = [':beta\_output']`, where `beta\_output` is a declared output of a target `beta`. Suppose `beta` has a target `charlie` as one of its `deps`. If `apply\_to\_generating\_rules=True` for the aspect, then the aspect will propagate through `alpha`, `beta`, and `charlie`. If False, then the aspect will propagate only to `alpha`.  False by default. |
+| `exec_compatible_with` | [sequence](/versions/8.4.2/rules/lib/core/list) of [string](/versions/8.4.2/rules/lib/core/string)s; default is `[]`  A list of constraints on the execution platform that apply to all instances of this aspect. |
+| `exec_groups` | [dict](/versions/8.4.2/rules/lib/core/dict); or `None`; default is `None`  Dict of execution group name (string) to [`exec_group`s](/versions/8.4.2/rules/lib/globals/bzl#exec_group). If set, allows aspects to run actions on multiple execution platforms within a single instance. See [execution groups documentation](/versions/8.4.2/reference/exec-groups) for more info. |
+| `subrules` | [sequence](/versions/8.4.2/rules/lib/core/list) of [Subrule](/versions/8.4.2/rules/lib/builtins/Subrule)s; default is `[]`  Experimental: list of subrules used by this aspect. |
 
 ## configuration\_field
 
@@ -74,7 +74,7 @@ Creates a new aspect. The result of this function must be stored in a global val
 LateBoundDefault configuration_field(fragment, name)
 ```
 
-References a late-bound default value for an attribute of type [label](../toplevel/attr#label). A value is 'late-bound' if it requires the configuration to be built before determining the value. Any attribute using this as a value must [be private](https://bazel.build/versions/8.4.2/extending/rules#private-attributes).
+References a late-bound default value for an attribute of type [label](/versions/8.4.2/rules/lib/toplevel/attr#label). A value is 'late-bound' if it requires the configuration to be built before determining the value. Any attribute using this as a value must [be private](https://bazel.build/versions/8.4.2/extending/rules#private-attributes).
 
 Example usage:
 
@@ -96,8 +96,8 @@ Accessing in rule implementation:
 
 | Parameter | Description |
 | --- | --- |
-| `fragment` | [string](../core/string); required |
-| `name` | [string](../core/string); required |
+| `fragment` | [string](/versions/8.4.2/rules/lib/core/string); required |
+| `name` | [string](/versions/8.4.2/rules/lib/core/string); required |
 
 ## depset
 
@@ -105,7 +105,7 @@ Accessing in rule implementation:
 depset depset(direct=None, order="default", *, transitive=None)
 ```
 
-Creates a [depset](../builtins/depset). The `direct` parameter is a list of direct elements of the depset, and `transitive` parameter is a list of depsets whose elements become indirect elements of the created depset. The order in which elements are returned when the depset is converted to a list is specified by the `order` parameter. See the [Depsets overview](https://bazel.build/versions/8.4.2/extending/depsets) for more information.
+Creates a [depset](/versions/8.4.2/rules/lib/builtins/depset). The `direct` parameter is a list of direct elements of the depset, and `transitive` parameter is a list of depsets whose elements become indirect elements of the created depset. The order in which elements are returned when the depset is converted to a list is specified by the `order` parameter. See the [Depsets overview](https://bazel.build/versions/8.4.2/extending/depsets) for more information.
 
 All elements (direct and indirect) of a depset must be of the same type, as obtained by the expression `type(x)`.
 
@@ -119,9 +119,9 @@ The order of the created depset should be *compatible* with the order of its `tr
 
 | Parameter | Description |
 | --- | --- |
-| `direct` | [sequence](../core/list); or `None`; default is `None`  A list of *direct* elements of a depset. |
-| `order` | [string](../core/string); default is `"default"`  The traversal strategy for the new depset. See [here](../builtins/depset) for the possible values. |
-| `transitive` | [sequence](../core/list) of [depset](../builtins/depset)s; or `None`; default is `None`  A list of depsets whose elements will become indirect elements of the depset. |
+| `direct` | [sequence](/versions/8.4.2/rules/lib/core/list); or `None`; default is `None`  A list of *direct* elements of a depset. |
+| `order` | [string](/versions/8.4.2/rules/lib/core/string); default is `"default"`  The traversal strategy for the new depset. See [here](/versions/8.4.2/rules/lib/builtins/depset) for the possible values. |
+| `transitive` | [sequence](/versions/8.4.2/rules/lib/core/list) of [depset](/versions/8.4.2/rules/lib/builtins/depset)s; or `None`; default is `None`  A list of depsets whose elements will become indirect elements of the depset. |
 
 ## exec\_group
 
@@ -135,8 +135,8 @@ Creates an [execution group](/versions/8.4.2/reference/exec-groups) which can be
 
 | Parameter | Description |
 | --- | --- |
-| `toolchains` | [sequence](../core/list); default is `[]`  The set of toolchains this execution group requires. The list can contain String, Label, or StarlarkToolchainTypeApi objects, in any combination. |
-| `exec_compatible_with` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  A list of constraints on the execution platform. |
+| `toolchains` | [sequence](/versions/8.4.2/rules/lib/core/list); default is `[]`  The set of toolchains this execution group requires. The list can contain String, Label, or StarlarkToolchainTypeApi objects, in any combination. |
+| `exec_compatible_with` | [sequence](/versions/8.4.2/rules/lib/core/list) of [string](/versions/8.4.2/rules/lib/core/string)s; default is `[]`  A list of constraints on the execution platform. |
 
 ## exec\_transition
 
@@ -144,15 +144,15 @@ Creates an [execution group](/versions/8.4.2/reference/exec-groups) which can be
 transition exec_transition(implementation, inputs, outputs)
 ```
 
-A specialized version of [`transition()`](../builtins/transition) used to define the exec transition. See its documentation (or its implementation) for best practices. Only usable from the Bazel builtins.
+A specialized version of [`transition()`](/versions/8.4.2/rules/lib/builtins/transition) used to define the exec transition. See its documentation (or its implementation) for best practices. Only usable from the Bazel builtins.
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
 | `implementation` | callable; required |
-| `inputs` | [sequence](../core/list) of [string](../core/string)s; required |
-| `outputs` | [sequence](../core/list) of [string](../core/string)s; required |
+| `inputs` | [sequence](/versions/8.4.2/rules/lib/core/list) of [string](/versions/8.4.2/rules/lib/core/string)s; required |
+| `outputs` | [sequence](/versions/8.4.2/rules/lib/core/list) of [string](/versions/8.4.2/rules/lib/core/string)s; required |
 
 ## macro
 
@@ -173,11 +173,11 @@ macros.
 
 | Parameter | Description |
 | --- | --- |
-| `implementation` | [function](../core/function); required  The Starlark function implementing this macro. The values of the macro's attributes are passed to the implementation function as keyword arguments. The implementation function must have at least two named parameters, `name` and `visibility`, and if the macro inherits attributes (see `inherit_attrs` below), it must have a `**kwargs` residual keyword parameter. By convention, the implementation function should have a named parameter for any attribute that the macro needs to examine, modify, or pass to non-"main" targets, while the "bulk" inherited attributes which will be passed to the "main" target unchanged are passed as `**kwargs`. The implementation function must not return a value. Instead, the implementation function *declares targets* by calling rule or macro symbols. The name of any target or inner symbolic macro declared by a symbolic macro (including by any Starlark function that the macro's implementation function transitively calls) must either equal `name` (this is referred to as the "main" target) or start with `name`, followed by a separator chracter (`"_"`, `"-"`, or `"."`) and a string suffix. (Targets violating this naming scheme are allowed to be declared, but cannot be built, configured, or depended upon.) By default, targets declared by a symbolic macro (including by any Starlark function that the macro's implementation function transitively calls) are visible only in the package containing the .bzl file defining the macro. To declare targets visible externally, *including to the caller of the symbolic macro*, the implementation function must set `visibility` appropriately – typically, by passing `visibility = visibility` to the rule or macro symbol being called. The following APIs are unavailable within a macro implementation function and any Starlark function it transitively calls:  * [`package()`, `licenses()`* `environment_group()`* [`native.glob()`](../toplevel/native#glob) – instead, you may pass       a glob into the macro via a label list attribute* [`native.subpackages()`](../toplevel/native#subpackages)* (allowed in rule finalizers only, see `finalizer` below)           [`native.existing_rules()`](../toplevel/native#existing_rules),           [`native.existing_rule()`](../toplevel/native#existing_rule)* (for `WORKSPACE` threads)             [`workspace()`](../globals/workspace#workspace),             [`register_toolchains()`](../globals/workspace#register_toolchains),             [`bind()`](../globals/workspace#bind), [`register_execution_platforms()`](../globals/workspace#register_execution_platforms), [repository rule instantiation](/versions/8.4.2/reference/be/functions#package) |
-| `attrs` | [dict](../core/dict); default is `{}`  A dictionary of the attributes this macro supports, analogous to [rule.attrs](#rule.attrs). Keys are attribute names, and values are either attribute objects like `attr.label_list(...)` (see the [attr](../toplevel/attr) module), or `None`. A `None` entry means that the macro does not have an attribute by that name, even if it would have otherwise inherited one via `inherit_attrs` (see below). The special `name` attribute is predeclared and must not be included in the dictionary. The `visibility` attribute name is reserved and must not be included in the dictionary. Attributes whose names start with `_` are private -- they cannot be passed at the call site of the rule. Such attributes can be assigned a default value (as in `attr.label(default="//pkg:foo")`) to create an implicit dependency on a label. To limit memory usage, there is a cap on the number of attributes that may be declared. |
-| `inherit_attrs` | [rule](../builtins/rule); or [macro](../builtins/macro); or [string](../core/string); or `None`; default is `None`  A rule symbol, macro symbol, or the name of a built-in common attribute list (see below) from which the macro should inherit attributes. If `inherit_attrs` is set to the string `"common"`, the macro will inherit [common rule attribute definitions](/versions/8.4.2/reference/be/common-definitions#common-attributes) used by all Starlark rules. Note that if the return value of `rule()` or `macro()` was not assigned to a global variable in a .bzl file, then such a value has not been registered as a rule or macro symbol, and therefore cannot be used for `inherit_attrs`. The inheritance mechanism works as follows:   1. The special `name` and `visibility` attributes are never inherited;- Hidden attributes (ones whose name starts with `"_"`) are never inherited;- Attributes whose names are already defined in the `attrs` dictionary are never        inherited (the entry in `attrs` takes precedence; note that an entry may be set to        `None` to ensure that no attribute by that name gets defined on the macro);- All other attributes are inherited from the rule or macro and effectively merged into the          `attrs` dict.   When a non-mandatory attribute is inherited, the default value of the attribute is overridden to be `None`, regardless of what it was specified in the original rule or macro. This ensures that when the macro forwards the attribute's value to an instance of the wrapped rule or macro – such as by passing in the unmodified `**kwargs` – a value that was absent from the outer macro's call will also be absent in the inner rule or macro's call (since passing `None` to an attribute is treated the same as omitting the attribute). This is important because omitting an attribute has subtly different semantics from passing its apparent default value. In particular, omitted attributes are not shown in some `bazel query` output formats, and computed defaults only execute when the value is omitted. If the macro needs to examine or modify an inherited attribute – for example, to add a value to an inherited `tags` attribute – you must make sure to handle the `None` case in the macro's implementation function. For example, the following macro inherits all attributes from `native.cc_library`, except for `cxxopts` (which is removed from the attribute list) and `copts` (which is given a new definition). It also takes care to checks for the default `None` value of the inherited `tags` attribute before appending an additional tag.  ``` def _my_cc_library_impl(name, visibility, tags, **kwargs):     # Append a tag; tags attr was inherited from native.cc_library, and     # therefore is None unless explicitly set by the caller of my_cc_library()     my_tags = (tags or []) + ["my_custom_tag"]     native.cc_library(         name = name,         visibility = visibility,         tags = my_tags,         **kwargs     )  my_cc_library = macro(     implementation = _my_cc_library_impl,     inherit_attrs = native.cc_library,     attrs = {         "cxxopts": None,         "copts": attr.string_list(default = ["-D_FOO"]),     }, ) ```   If `inherit_attrs` is set, the macro's implementation function *must* have a `**kwargs` residual keyword parameter. By convention, a macro should pass inherited, non-overridden attributes unchanged to the "main" rule or macro symbol which the macro is wrapping. Typically, most inherited attributes will not have a parameter in the implementation function's parameter list, and will simply be passed via `**kwargs`. It can be convenient for the implementation function to have explicit parameters for some inherited attributes (most commonly, `tags` and `testonly`) if the macro needs to pass those attributes to both "main" and non-"main" targets – but if the macro also needs to examine or manipulate those attributes, you must take care to handle the `None` default value of non-mandatory inherited attributes. |
-| `finalizer` | [bool](../core/bool); default is `False`  Whether this macro is a rule finalizer, which is a macro that, regardless of its position in a `BUILD` file, is evaluated at the end of package loading, after all non-finalizer targets have been defined. Unlike ordinary symbolic macros, rule finalizers may call [`native.existing_rule()`](../toplevel/native#existing_rule) and [`native.existing_rules()`](../toplevel/native#existing_rules) to query the set of *non-finalizer* rule targets defined in the current package. Note that `native.existing_rule()` and `native.existing_rules()` cannot access the targets defined by any rule finalizer, including this one. |
-| `doc` | [string](../core/string); or `None`; default is `None`  A description of the macro that can be extracted by documentation generating tools. |
+| `implementation` | [function](/versions/8.4.2/rules/lib/core/function); required  The Starlark function implementing this macro. The values of the macro's attributes are passed to the implementation function as keyword arguments. The implementation function must have at least two named parameters, `name` and `visibility`, and if the macro inherits attributes (see `inherit_attrs` below), it must have a `**kwargs` residual keyword parameter. By convention, the implementation function should have a named parameter for any attribute that the macro needs to examine, modify, or pass to non-"main" targets, while the "bulk" inherited attributes which will be passed to the "main" target unchanged are passed as `**kwargs`. The implementation function must not return a value. Instead, the implementation function *declares targets* by calling rule or macro symbols. The name of any target or inner symbolic macro declared by a symbolic macro (including by any Starlark function that the macro's implementation function transitively calls) must either equal `name` (this is referred to as the "main" target) or start with `name`, followed by a separator chracter (`"_"`, `"-"`, or `"."`) and a string suffix. (Targets violating this naming scheme are allowed to be declared, but cannot be built, configured, or depended upon.) By default, targets declared by a symbolic macro (including by any Starlark function that the macro's implementation function transitively calls) are visible only in the package containing the .bzl file defining the macro. To declare targets visible externally, *including to the caller of the symbolic macro*, the implementation function must set `visibility` appropriately – typically, by passing `visibility = visibility` to the rule or macro symbol being called. The following APIs are unavailable within a macro implementation function and any Starlark function it transitively calls:  * [`package()`, `licenses()`* `environment_group()`* [`native.glob()`](/versions/8.4.2/rules/lib/toplevel/native#glob) – instead, you may pass       a glob into the macro via a label list attribute* [`native.subpackages()`](/versions/8.4.2/rules/lib/toplevel/native#subpackages)* (allowed in rule finalizers only, see `finalizer` below)           [`native.existing_rules()`](/versions/8.4.2/rules/lib/toplevel/native#existing_rules),           [`native.existing_rule()`](/versions/8.4.2/rules/lib/toplevel/native#existing_rule)* (for `WORKSPACE` threads)             [`workspace()`](/versions/8.4.2/rules/lib/globals/workspace#workspace),             [`register_toolchains()`](/versions/8.4.2/rules/lib/globals/workspace#register_toolchains),             [`bind()`](/versions/8.4.2/rules/lib/globals/workspace#bind), [`register_execution_platforms()`](/versions/8.4.2/rules/lib/globals/workspace#register_execution_platforms), [repository rule instantiation](/versions/8.4.2/reference/be/functions#package) |
+| `attrs` | [dict](/versions/8.4.2/rules/lib/core/dict); default is `{}`  A dictionary of the attributes this macro supports, analogous to [rule.attrs](#rule.attrs). Keys are attribute names, and values are either attribute objects like `attr.label_list(...)` (see the [attr](/versions/8.4.2/rules/lib/toplevel/attr) module), or `None`. A `None` entry means that the macro does not have an attribute by that name, even if it would have otherwise inherited one via `inherit_attrs` (see below). The special `name` attribute is predeclared and must not be included in the dictionary. The `visibility` attribute name is reserved and must not be included in the dictionary. Attributes whose names start with `_` are private -- they cannot be passed at the call site of the rule. Such attributes can be assigned a default value (as in `attr.label(default="//pkg:foo")`) to create an implicit dependency on a label. To limit memory usage, there is a cap on the number of attributes that may be declared. |
+| `inherit_attrs` | [rule](/versions/8.4.2/rules/lib/builtins/rule); or [macro](/versions/8.4.2/rules/lib/builtins/macro); or [string](/versions/8.4.2/rules/lib/core/string); or `None`; default is `None`  A rule symbol, macro symbol, or the name of a built-in common attribute list (see below) from which the macro should inherit attributes. If `inherit_attrs` is set to the string `"common"`, the macro will inherit [common rule attribute definitions](/versions/8.4.2/reference/be/common-definitions#common-attributes) used by all Starlark rules. Note that if the return value of `rule()` or `macro()` was not assigned to a global variable in a .bzl file, then such a value has not been registered as a rule or macro symbol, and therefore cannot be used for `inherit_attrs`. The inheritance mechanism works as follows:   1. The special `name` and `visibility` attributes are never inherited;- Hidden attributes (ones whose name starts with `"_"`) are never inherited;- Attributes whose names are already defined in the `attrs` dictionary are never        inherited (the entry in `attrs` takes precedence; note that an entry may be set to        `None` to ensure that no attribute by that name gets defined on the macro);- All other attributes are inherited from the rule or macro and effectively merged into the          `attrs` dict.   When a non-mandatory attribute is inherited, the default value of the attribute is overridden to be `None`, regardless of what it was specified in the original rule or macro. This ensures that when the macro forwards the attribute's value to an instance of the wrapped rule or macro – such as by passing in the unmodified `**kwargs` – a value that was absent from the outer macro's call will also be absent in the inner rule or macro's call (since passing `None` to an attribute is treated the same as omitting the attribute). This is important because omitting an attribute has subtly different semantics from passing its apparent default value. In particular, omitted attributes are not shown in some `bazel query` output formats, and computed defaults only execute when the value is omitted. If the macro needs to examine or modify an inherited attribute – for example, to add a value to an inherited `tags` attribute – you must make sure to handle the `None` case in the macro's implementation function. For example, the following macro inherits all attributes from `native.cc_library`, except for `cxxopts` (which is removed from the attribute list) and `copts` (which is given a new definition). It also takes care to checks for the default `None` value of the inherited `tags` attribute before appending an additional tag.  ``` def _my_cc_library_impl(name, visibility, tags, **kwargs):     # Append a tag; tags attr was inherited from native.cc_library, and     # therefore is None unless explicitly set by the caller of my_cc_library()     my_tags = (tags or []) + ["my_custom_tag"]     native.cc_library(         name = name,         visibility = visibility,         tags = my_tags,         **kwargs     )  my_cc_library = macro(     implementation = _my_cc_library_impl,     inherit_attrs = native.cc_library,     attrs = {         "cxxopts": None,         "copts": attr.string_list(default = ["-D_FOO"]),     }, ) ```   If `inherit_attrs` is set, the macro's implementation function *must* have a `**kwargs` residual keyword parameter. By convention, a macro should pass inherited, non-overridden attributes unchanged to the "main" rule or macro symbol which the macro is wrapping. Typically, most inherited attributes will not have a parameter in the implementation function's parameter list, and will simply be passed via `**kwargs`. It can be convenient for the implementation function to have explicit parameters for some inherited attributes (most commonly, `tags` and `testonly`) if the macro needs to pass those attributes to both "main" and non-"main" targets – but if the macro also needs to examine or manipulate those attributes, you must take care to handle the `None` default value of non-mandatory inherited attributes. |
+| `finalizer` | [bool](/versions/8.4.2/rules/lib/core/bool); default is `False`  Whether this macro is a rule finalizer, which is a macro that, regardless of its position in a `BUILD` file, is evaluated at the end of package loading, after all non-finalizer targets have been defined. Unlike ordinary symbolic macros, rule finalizers may call [`native.existing_rule()`](/versions/8.4.2/rules/lib/toplevel/native#existing_rule) and [`native.existing_rules()`](/versions/8.4.2/rules/lib/toplevel/native#existing_rules) to query the set of *non-finalizer* rule targets defined in the current package. Note that `native.existing_rule()` and `native.existing_rules()` cannot access the targets defined by any rule finalizer, including this one. |
+| `doc` | [string](/versions/8.4.2/rules/lib/core/string); or `None`; default is `None`  A description of the macro that can be extracted by documentation generating tools. |
 
 ## module\_extension
 
@@ -192,11 +192,11 @@ Creates a new module extension. Store it in a global value, so that it can be ex
 | Parameter | Description |
 | --- | --- |
 | `implementation` | callable; required  The function that implements this module extension. Must take a single parameter, `module_ctx`. The function is called once at the beginning of a build to determine the set of available repos. |
-| `tag_classes` | [dict](../core/dict); default is `{}`  A dictionary to declare all the tag classes used by the extension. It maps from the name of the tag class to a `tag_class` object. |
-| `doc` | [string](../core/string); or `None`; default is `None`  A description of the module extension that can be extracted by documentation generating tools. |
-| `environ` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  Provides a list of environment variable that this module extension depends on. If an environment variable in that list changes, the extension will be re-evaluated. |
-| `os_dependent` | [bool](../core/bool); default is `False`  Indicates whether this extension is OS-dependent or not |
-| `arch_dependent` | [bool](../core/bool); default is `False`  Indicates whether this extension is architecture-dependent or not |
+| `tag_classes` | [dict](/versions/8.4.2/rules/lib/core/dict); default is `{}`  A dictionary to declare all the tag classes used by the extension. It maps from the name of the tag class to a `tag_class` object. |
+| `doc` | [string](/versions/8.4.2/rules/lib/core/string); or `None`; default is `None`  A description of the module extension that can be extracted by documentation generating tools. |
+| `environ` | [sequence](/versions/8.4.2/rules/lib/core/list) of [string](/versions/8.4.2/rules/lib/core/string)s; default is `[]`  Provides a list of environment variable that this module extension depends on. If an environment variable in that list changes, the extension will be re-evaluated. |
+| `os_dependent` | [bool](/versions/8.4.2/rules/lib/core/bool); default is `False`  Indicates whether this extension is OS-dependent or not |
+| `arch_dependent` | [bool](/versions/8.4.2/rules/lib/core/bool); default is `False`  Indicates whether this extension is architecture-dependent or not |
 
 ## provider
 
@@ -219,16 +219,16 @@ def _my_library_impl(ctx):
 
 See [Rules (Providers)](https://bazel.build/versions/8.4.2/extending/rules#providers) for a comprehensive guide on how to use providers.
 
-Returns a [`Provider`](../builtins/Provider) callable value if `init` is not specified.
+Returns a [`Provider`](/versions/8.4.2/rules/lib/builtins/Provider) callable value if `init` is not specified.
 
-If `init` is specified, returns a tuple of 2 elements: a [`Provider`](../builtins/Provider) callable value and a *raw constructor* callable value. See  [Rules (Custom initialization of custom providers)](https://bazel.build/versions/8.4.2/extending/rules#custom_initialization_of_providers) and the discussion of the `init` parameter below for details.
+If `init` is specified, returns a tuple of 2 elements: a [`Provider`](/versions/8.4.2/rules/lib/builtins/Provider) callable value and a *raw constructor* callable value. See  [Rules (Custom initialization of custom providers)](https://bazel.build/versions/8.4.2/extending/rules#custom_initialization_of_providers) and the discussion of the `init` parameter below for details.
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `doc` | [string](../core/string); or `None`; default is `None` |
-| `fields` | [sequence](../core/list) of [string](../core/string)s; or [dict](../core/dict); or `None`; default is `None`  If specified, restricts the set of allowed fields.  Possible values are:  * list of fields:     ```   provider(fields = ['a', 'b'])   ```     * dictionary field name -> documentation:       ```     provider(            fields = { 'a' : 'Documentation for a', 'b' : 'Documentation for b' })     ```  All fields are optional. |
+| `doc` | [string](/versions/8.4.2/rules/lib/core/string); or `None`; default is `None` |
+| `fields` | [sequence](/versions/8.4.2/rules/lib/core/list) of [string](/versions/8.4.2/rules/lib/core/string)s; or [dict](/versions/8.4.2/rules/lib/core/dict); or `None`; default is `None`  If specified, restricts the set of allowed fields.  Possible values are:  * list of fields:     ```   provider(fields = ['a', 'b'])   ```     * dictionary field name -> documentation:       ```     provider(            fields = { 'a' : 'Documentation for a', 'b' : 'Documentation for b' })     ```  All fields are optional. |
 | `init` | callable; or `None`; default is `None` |
 
 ## repository\_rule
@@ -237,19 +237,19 @@ If `init` is specified, returns a tuple of 2 elements: a [`Provider`](../builtin
 callable repository_rule(implementation, *, attrs=None, local=False, environ=[], configure=False, remotable=False, doc=None)
 ```
 
-Creates a new repository rule. Store it in a global value, so that it can be loaded and called from a [`module_extension()`](#module_extension) implementation function, or used by [`use_repo_rule()`](../globals/module#use_repo_rule).
+Creates a new repository rule. Store it in a global value, so that it can be loaded and called from a [`module_extension()`](#module_extension) implementation function, or used by [`use_repo_rule()`](/versions/8.4.2/rules/lib/globals/module#use_repo_rule).
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
 | `implementation` | callable; required |
-| `attrs` | [dict](../core/dict); or `None`; default is `None` |
-| `local` | [bool](../core/bool); default is `False`  Indicate that this rule fetches everything from the local system and should be reevaluated at every fetch. |
-| `environ` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  **Deprecated**. This parameter has been deprecated. Migrate to `repository_ctx.getenv` instead. Provides a list of environment variable that this repository rule depends on. If an environment variable in that list change, the repository will be refetched. |
-| `configure` | [bool](../core/bool); default is `False`  Indicate that the repository inspects the system for configuration purpose |
-| `remotable` | [bool](../core/bool); default is `False`  **Experimental**. This parameter is experimental and may change at any time. Please do not depend on it. It may be enabled on an experimental basis by setting `--experimental_repo_remote_exec`  Compatible with remote execution |
-| `doc` | [string](../core/string); or `None`; default is `None` |
+| `attrs` | [dict](/versions/8.4.2/rules/lib/core/dict); or `None`; default is `None` |
+| `local` | [bool](/versions/8.4.2/rules/lib/core/bool); default is `False`  Indicate that this rule fetches everything from the local system and should be reevaluated at every fetch. |
+| `environ` | [sequence](/versions/8.4.2/rules/lib/core/list) of [string](/versions/8.4.2/rules/lib/core/string)s; default is `[]`  **Deprecated**. This parameter has been deprecated. Migrate to `repository_ctx.getenv` instead. Provides a list of environment variable that this repository rule depends on. If an environment variable in that list change, the repository will be refetched. |
+| `configure` | [bool](/versions/8.4.2/rules/lib/core/bool); default is `False`  Indicate that the repository inspects the system for configuration purpose |
+| `remotable` | [bool](/versions/8.4.2/rules/lib/core/bool); default is `False`  **Experimental**. This parameter is experimental and may change at any time. Please do not depend on it. It may be enabled on an experimental basis by setting `--experimental_repo_remote_exec`  Compatible with remote execution |
+| `doc` | [string](/versions/8.4.2/rules/lib/core/string); or `None`; default is `None` |
 
 ## rule
 
@@ -267,29 +267,29 @@ Test rules are required to have a name ending in `_test`, while all other rules
 
 | Parameter | Description |
 | --- | --- |
-| `implementation` | [function](../core/function); required  the Starlark function implementing this rule, must have exactly one parameter: [ctx](../builtins/ctx). The function is called during the analysis phase for each instance of the rule. It can access the attributes provided by the user. It must create actions to generate all the declared outputs. |
-| `test` | [bool](../core/bool); default is `unbound`  Whether this rule is a test rule, that is, whether it may be the subject of a `blaze test` command. All test rules are automatically considered [executable](#rule.executable); it is unnecessary (and discouraged) to explicitly set `executable = True` for a test rule. The value defaults to `False`. See the  [Rules page](https://bazel.build/versions/8.4.2/extending/rules#executable_rules_and_test_rules) for more information. |
-| `attrs` | [dict](../core/dict); default is `{}`  A dictionary to declare all the attributes of the rule. It maps from an attribute name to an attribute object (see [`attr`](../toplevel/attr) module). Attributes starting with `_` are private, and can be used to add an implicit dependency on a label. The attribute `name` is implicitly added and must not be specified. Attributes `visibility`, `deprecation`, `tags`, `testonly`, and `features` are implicitly added and cannot be overridden. Most rules need only a handful of attributes. To limit memory usage, there is a cap on the number of attributes that may be declared. Declared attributes will convert `None` to the default value. |
-| `outputs` | [dict](../core/dict); or `None`; or [function](../core/function); default is `None`  **Deprecated**. This parameter is deprecated and will be removed soon. Please do not depend on it. It is *disabled* with `--incompatible_no_rule_outputs_param`. Use this flag to verify your code is compatible with its imminent removal.  This parameter has been deprecated. Migrate rules to use `OutputGroupInfo` or `attr.output` instead. A schema for defining predeclared outputs. Unlike [`output`](../toplevel/attr#output) and [`output_list`](../toplevel/attr#output_list) attributes, the user does not specify the labels for these files. See the [Rules page](https://bazel.build/versions/8.4.2/extending/rules#files) for more on predeclared outputs. The value of this argument is either a dictionary or a callback function that produces a dictionary. The callback works similar to computed dependency attributes: The function's parameter names are matched against the rule's attributes, so for example if you pass `outputs = _my_func` with the definition `def _my_func(srcs, deps): ...`, the function has access to the attributes `srcs` and `deps`. Whether the dictionary is specified directly or via a function, it is interpreted as follows. Each entry in the dictionary creates a predeclared output where the key is an identifier and the value is a string template that determines the output's label. In the rule's implementation function, the identifier becomes the field name used to access the output's [`File`](../builtins/File) in [`ctx.outputs`](../builtins/ctx#outputs). The output's label has the same package as the rule, and the part after the package is produced by substituting each placeholder of the form `"%{ATTR}"` with a string formed from the value of the attribute `ATTR`:  * String-typed attributes are substituted verbatim.* Label-typed attributes become the part of the label after the package, minus the file extension. For example, the label `"//pkg:a/b.c"` becomes `"a/b"`.* Output-typed attributes become the part of the label after the package, including the file extension (for the above example, `"a/b.c"`).* All list-typed attributes (for example, `attr.label_list`) used in placeholders are required to have *exactly one element*. Their conversion is the same as their non-list version (`attr.label`).* Other attribute types may not appear in placeholders.* The special non-attribute placeholders `%{dirname}` and `%{basename}` expand to those parts of the rule's label, excluding its package. For example, in `"//pkg:a/b.c"`, the dirname is `a` and the basename is `b.c`.   In practice, the most common substitution placeholder is `"%{name}"`. For example, for a target named "foo", the outputs dict `{"bin": "%{name}.exe"}` predeclares an output named `foo.exe` that is accessible in the implementation function as `ctx.outputs.bin`. |
-| `executable` | [bool](../core/bool); default is `unbound` |
-| `output_to_genfiles` | [bool](../core/bool); default is `False`  If true, the files will be generated in the genfiles directory instead of the bin directory. Unless you need it for compatibility with existing rules (e.g. when generating header files for C++), do not set this flag. |
-| `fragments` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  List of names of configuration fragments that the rule requires in target configuration. |
-| `host_fragments` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  List of names of configuration fragments that the rule requires in host configuration. |
-| `_skylark_testable` | [bool](../core/bool); default is `False`  *(Experimental)*  If true, this rule will expose its actions for inspection by rules that depend on it via an `Actions` provider. The provider is also available to the rule itself by calling [ctx.created\_actions()](../builtins/ctx#created_actions).  This should only be used for testing the analysis-time behavior of Starlark rules. This flag may be removed in the future. |
-| `toolchains` | [sequence](../core/list); default is `[]`  If set, the set of toolchains this rule requires. The list can contain String, Label, or StarlarkToolchainTypeApi objects, in any combination. Toolchains will be found by checking the current platform, and provided to the rule implementation via `ctx.toolchain`. |
-| `incompatible_use_toolchain_transition` | [bool](../core/bool); default is `False`  Deprecated, this is no longer in use and should be removed. |
-| `doc` | [string](../core/string); or `None`; default is `None`  A description of the rule that can be extracted by documentation generating tools. |
-| `provides` | [sequence](../core/list); default is `[]`  A list of providers that the implementation function must return. It is an error if the implementation function omits any of the types of providers listed here from its return value. However, the implementation function may return additional providers not listed here. Each element of the list is an `*Info` object returned by [`provider()`](../globals/bzl#provider), except that a legacy provider is represented by its string name instead.When a target of the rule is used as a dependency for a target that declares a required provider, it is not necessary to specify that provider here. It is enough that the implementation function returns it. However, it is considered best practice to specify it, even though this is not required. The [`required_providers`](../globals/bzl#aspect.required_providers) field of an [aspect](../globals/bzl#aspect) does, however, require that providers are specified here. |
-| `dependency_resolution_rule` | [bool](../core/bool); default is `False`  If set, the rule can be a dependency through attributes also marked as available in materializers. Every attribute of rules with this flag set must be marked as available in materializers also. This is so that rules so marked cannot depend on rules that are not so marked. |
-| `exec_compatible_with` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  A list of constraints on the execution platform that apply to all targets of this rule type. |
-| `analysis_test` | [bool](../core/bool); default is `False`  If true, then this rule is treated as an analysis test. Note: Analysis test rules are primarily defined using infrastructure provided in core Starlark libraries. See [Testing](https://bazel.build/versions/8.4.2/rules/testing#testing-rules) for guidance. If a rule is defined as an analysis test rule, it becomes allowed to use configuration transitions defined using [analysis\_test\_transition](#analysis_test_transition) on its attributes, but opts into some restrictions:  * Targets of this rule are limited in the number of transitive dependencies they may have.* The rule is considered a test rule (as if `test=True` were set). This supersedes the value of `test`   * The rule implementation function may not register actions. Instead, it must register a pass/fail result via providing [AnalysisTestResultInfo](../providers/AnalysisTestResultInfo). |
-| `build_setting` | [BuildSetting](../builtins/BuildSetting); or `None`; default is `None`  If set, describes what kind of [`build setting`](/versions/8.4.2/rules/config#user-defined-build-settings) this rule is. See the [`config`](../toplevel/config) module. If this is set, a mandatory attribute named "build\_setting\_default" is automatically added to this rule, with a type corresponding to the value passed in here. |
+| `implementation` | [function](/versions/8.4.2/rules/lib/core/function); required  the Starlark function implementing this rule, must have exactly one parameter: [ctx](/versions/8.4.2/rules/lib/builtins/ctx). The function is called during the analysis phase for each instance of the rule. It can access the attributes provided by the user. It must create actions to generate all the declared outputs. |
+| `test` | [bool](/versions/8.4.2/rules/lib/core/bool); default is `unbound`  Whether this rule is a test rule, that is, whether it may be the subject of a `blaze test` command. All test rules are automatically considered [executable](#rule.executable); it is unnecessary (and discouraged) to explicitly set `executable = True` for a test rule. The value defaults to `False`. See the  [Rules page](https://bazel.build/versions/8.4.2/extending/rules#executable_rules_and_test_rules) for more information. |
+| `attrs` | [dict](/versions/8.4.2/rules/lib/core/dict); default is `{}`  A dictionary to declare all the attributes of the rule. It maps from an attribute name to an attribute object (see [`attr`](/versions/8.4.2/rules/lib/toplevel/attr) module). Attributes starting with `_` are private, and can be used to add an implicit dependency on a label. The attribute `name` is implicitly added and must not be specified. Attributes `visibility`, `deprecation`, `tags`, `testonly`, and `features` are implicitly added and cannot be overridden. Most rules need only a handful of attributes. To limit memory usage, there is a cap on the number of attributes that may be declared. Declared attributes will convert `None` to the default value. |
+| `outputs` | [dict](/versions/8.4.2/rules/lib/core/dict); or `None`; or [function](/versions/8.4.2/rules/lib/core/function); default is `None`  **Deprecated**. This parameter is deprecated and will be removed soon. Please do not depend on it. It is *disabled* with `--incompatible_no_rule_outputs_param`. Use this flag to verify your code is compatible with its imminent removal.  This parameter has been deprecated. Migrate rules to use `OutputGroupInfo` or `attr.output` instead. A schema for defining predeclared outputs. Unlike [`output`](/versions/8.4.2/rules/lib/toplevel/attr#output) and [`output_list`](/versions/8.4.2/rules/lib/toplevel/attr#output_list) attributes, the user does not specify the labels for these files. See the [Rules page](https://bazel.build/versions/8.4.2/extending/rules#files) for more on predeclared outputs. The value of this argument is either a dictionary or a callback function that produces a dictionary. The callback works similar to computed dependency attributes: The function's parameter names are matched against the rule's attributes, so for example if you pass `outputs = _my_func` with the definition `def _my_func(srcs, deps): ...`, the function has access to the attributes `srcs` and `deps`. Whether the dictionary is specified directly or via a function, it is interpreted as follows. Each entry in the dictionary creates a predeclared output where the key is an identifier and the value is a string template that determines the output's label. In the rule's implementation function, the identifier becomes the field name used to access the output's [`File`](/versions/8.4.2/rules/lib/builtins/File) in [`ctx.outputs`](/versions/8.4.2/rules/lib/builtins/ctx#outputs). The output's label has the same package as the rule, and the part after the package is produced by substituting each placeholder of the form `"%{ATTR}"` with a string formed from the value of the attribute `ATTR`:  * String-typed attributes are substituted verbatim.* Label-typed attributes become the part of the label after the package, minus the file extension. For example, the label `"//pkg:a/b.c"` becomes `"a/b"`.* Output-typed attributes become the part of the label after the package, including the file extension (for the above example, `"a/b.c"`).* All list-typed attributes (for example, `attr.label_list`) used in placeholders are required to have *exactly one element*. Their conversion is the same as their non-list version (`attr.label`).* Other attribute types may not appear in placeholders.* The special non-attribute placeholders `%{dirname}` and `%{basename}` expand to those parts of the rule's label, excluding its package. For example, in `"//pkg:a/b.c"`, the dirname is `a` and the basename is `b.c`.   In practice, the most common substitution placeholder is `"%{name}"`. For example, for a target named "foo", the outputs dict `{"bin": "%{name}.exe"}` predeclares an output named `foo.exe` that is accessible in the implementation function as `ctx.outputs.bin`. |
+| `executable` | [bool](/versions/8.4.2/rules/lib/core/bool); default is `unbound` |
+| `output_to_genfiles` | [bool](/versions/8.4.2/rules/lib/core/bool); default is `False`  If true, the files will be generated in the genfiles directory instead of the bin directory. Unless you need it for compatibility with existing rules (e.g. when generating header files for C++), do not set this flag. |
+| `fragments` | [sequence](/versions/8.4.2/rules/lib/core/list) of [string](/versions/8.4.2/rules/lib/core/string)s; default is `[]`  List of names of configuration fragments that the rule requires in target configuration. |
+| `host_fragments` | [sequence](/versions/8.4.2/rules/lib/core/list) of [string](/versions/8.4.2/rules/lib/core/string)s; default is `[]`  List of names of configuration fragments that the rule requires in host configuration. |
+| `_skylark_testable` | [bool](/versions/8.4.2/rules/lib/core/bool); default is `False`  *(Experimental)*  If true, this rule will expose its actions for inspection by rules that depend on it via an `Actions` provider. The provider is also available to the rule itself by calling [ctx.created\_actions()](/versions/8.4.2/rules/lib/builtins/ctx#created_actions).  This should only be used for testing the analysis-time behavior of Starlark rules. This flag may be removed in the future. |
+| `toolchains` | [sequence](/versions/8.4.2/rules/lib/core/list); default is `[]`  If set, the set of toolchains this rule requires. The list can contain String, Label, or StarlarkToolchainTypeApi objects, in any combination. Toolchains will be found by checking the current platform, and provided to the rule implementation via `ctx.toolchain`. |
+| `incompatible_use_toolchain_transition` | [bool](/versions/8.4.2/rules/lib/core/bool); default is `False`  Deprecated, this is no longer in use and should be removed. |
+| `doc` | [string](/versions/8.4.2/rules/lib/core/string); or `None`; default is `None`  A description of the rule that can be extracted by documentation generating tools. |
+| `provides` | [sequence](/versions/8.4.2/rules/lib/core/list); default is `[]`  A list of providers that the implementation function must return. It is an error if the implementation function omits any of the types of providers listed here from its return value. However, the implementation function may return additional providers not listed here. Each element of the list is an `*Info` object returned by [`provider()`](/versions/8.4.2/rules/lib/globals/bzl#provider), except that a legacy provider is represented by its string name instead.When a target of the rule is used as a dependency for a target that declares a required provider, it is not necessary to specify that provider here. It is enough that the implementation function returns it. However, it is considered best practice to specify it, even though this is not required. The [`required_providers`](/versions/8.4.2/rules/lib/globals/bzl#aspect.required_providers) field of an [aspect](/versions/8.4.2/rules/lib/globals/bzl#aspect) does, however, require that providers are specified here. |
+| `dependency_resolution_rule` | [bool](/versions/8.4.2/rules/lib/core/bool); default is `False`  If set, the rule can be a dependency through attributes also marked as available in materializers. Every attribute of rules with this flag set must be marked as available in materializers also. This is so that rules so marked cannot depend on rules that are not so marked. |
+| `exec_compatible_with` | [sequence](/versions/8.4.2/rules/lib/core/list) of [string](/versions/8.4.2/rules/lib/core/string)s; default is `[]`  A list of constraints on the execution platform that apply to all targets of this rule type. |
+| `analysis_test` | [bool](/versions/8.4.2/rules/lib/core/bool); default is `False`  If true, then this rule is treated as an analysis test. Note: Analysis test rules are primarily defined using infrastructure provided in core Starlark libraries. See [Testing](https://bazel.build/versions/8.4.2/rules/testing#testing-rules) for guidance. If a rule is defined as an analysis test rule, it becomes allowed to use configuration transitions defined using [analysis\_test\_transition](#analysis_test_transition) on its attributes, but opts into some restrictions:  * Targets of this rule are limited in the number of transitive dependencies they may have.* The rule is considered a test rule (as if `test=True` were set). This supersedes the value of `test`   * The rule implementation function may not register actions. Instead, it must register a pass/fail result via providing [AnalysisTestResultInfo](/versions/8.4.2/rules/lib/providers/AnalysisTestResultInfo). |
+| `build_setting` | [BuildSetting](/versions/8.4.2/rules/lib/builtins/BuildSetting); or `None`; default is `None`  If set, describes what kind of [`build setting`](/versions/8.4.2/rules/config#user-defined-build-settings) this rule is. See the [`config`](/versions/8.4.2/rules/lib/toplevel/config) module. If this is set, a mandatory attribute named "build\_setting\_default" is automatically added to this rule, with a type corresponding to the value passed in here. |
 | `cfg` | default is `None`  If set, points to the configuration transition the rule will apply to its own configuration before analysis. |
-| `exec_groups` | [dict](../core/dict); or `None`; default is `None`  Dict of execution group name (string) to [`exec_group`s](../globals/bzl#exec_group). If set, allows rules to run actions on multiple execution platforms within a single target. See [execution groups documentation](/versions/8.4.2/reference/exec-groups) for more info. |
+| `exec_groups` | [dict](/versions/8.4.2/rules/lib/core/dict); or `None`; default is `None`  Dict of execution group name (string) to [`exec_group`s](/versions/8.4.2/rules/lib/globals/bzl#exec_group). If set, allows rules to run actions on multiple execution platforms within a single target. See [execution groups documentation](/versions/8.4.2/reference/exec-groups) for more info. |
 | `initializer` | default is `None`  Experimental: the Stalark function initializing the attributes of the rule. The function is called at load time for each instance of the rule. It's called with `name` and the values of public attributes defined by the rule (not with generic attributes, for example `tags`). It has to return a dictionary from the attribute names to the desired values. The attributes that are not returned are unaffected. Returning `None` as value results in using the default value specified in the attribute definition. Initializers are evaluated before the default values specified in an attribute definition. Consequently, if a parameter in the initializer's signature contains a default values, it overwrites the default from the attribute definition (except if returning `None`). Similarly, if a parameter in the initializer's signature doesn't have a default, the parameter will become mandatory. It's a good practice to omit default/mandatory settings on an attribute definition in such cases. It's a good practice to use `**kwargs` for attributes that are not handled. In case of extended rules, all initializers are called proceeding from child to ancestors. Each initializer is passed only the public attributes it knows about. |
 | `parent` | default is `None`  Experimental: the Stalark rule that is extended. When set the public attributes are merged as well as advertised providers. The rule matches `executable` and `test` from the parent. Values of `fragments`, `toolchains`, `exec_compatible_with`, and `exec_groups` are merged. Legacy or deprecated parameters may not be set. Incoming configuration transition `cfg` of parent is applied after thisrule's incoming configuration. |
-| `extendable` | [bool](../core/bool); or [Label](../builtins/Label); or [string](../core/string); or `None`; default is `None`  Experimental: A label of an allowlist defining which rules can extending this rule. It can be set also to True/False to always allow/disallow extending. Bazel defaults to always allowing extensions. |
-| `subrules` | [sequence](../core/list) of [Subrule](../builtins/Subrule)s; default is `[]`  Experimental: List of subrules used by this rule. |
+| `extendable` | [bool](/versions/8.4.2/rules/lib/core/bool); or [Label](/versions/8.4.2/rules/lib/builtins/Label); or [string](/versions/8.4.2/rules/lib/core/string); or `None`; default is `None`  Experimental: A label of an allowlist defining which rules can extending this rule. It can be set also to True/False to always allow/disallow extending. Bazel defaults to always allowing extensions. |
+| `subrules` | [sequence](/versions/8.4.2/rules/lib/core/list) of [Subrule](/versions/8.4.2/rules/lib/builtins/Subrule)s; default is `[]`  Experimental: List of subrules used by this rule. |
 
 ## select
 
@@ -303,8 +303,8 @@ unknown select(x, no_match_error='')
 
 | Parameter | Description |
 | --- | --- |
-| `x` | [dict](../core/dict); required  A dict that maps configuration conditions to values. Each key is a [Label](../builtins/Label) or a label string that identifies a config\_setting or constraint\_value instance. See the [documentation on macros](https://bazel.build/versions/8.4.2/rules/macros#label-resolution) for when to use a Label instead of a string. |
-| `no_match_error` | [string](../core/string); default is `''`  Optional custom error to report if no condition matches. |
+| `x` | [dict](/versions/8.4.2/rules/lib/core/dict); required  A dict that maps configuration conditions to values. Each key is a [Label](/versions/8.4.2/rules/lib/builtins/Label) or a label string that identifies a config\_setting or constraint\_value instance. See the [documentation on macros](https://bazel.build/versions/8.4.2/rules/macros#label-resolution) for when to use a Label instead of a string. |
+| `no_match_error` | [string](/versions/8.4.2/rules/lib/core/string); default is `''`  Optional custom error to report if no condition matches. |
 
 ## subrule
 
@@ -318,11 +318,11 @@ Constructs a new instance of a subrule. The result of this function must be stor
 
 | Parameter | Description |
 | --- | --- |
-| `implementation` | [function](../core/function); required  The Starlark function implementing this subrule |
-| `attrs` | [dict](../core/dict); default is `{}`  A dictionary to declare all the (private) attributes of the subrule.  Subrules may only have private attributes that are label-typed (i.e. label or label-list). The resolved values corresponding to these labels are automatically passed by Bazel to the subrule's implementation function as named arguments (thus the implementation function is required to accept named parameters matching the attribute names). The types of these values will be:  * `FilesToRunProvider` for label attributes with `executable=True` * `File` for label attributes with `allow_single_file=True` * `Target` for all other label attributes * `[Target]` for all label-list attributes |
-| `toolchains` | [sequence](../core/list); default is `[]`  If set, the set of toolchains this subrule requires. The list can contain String, Label, or StarlarkToolchainTypeApi objects, in any combination. Toolchains will be found by checking the current platform, and provided to the subrule implementation via `ctx.toolchains`. Note that AEGs need to be enabled on the consuming rule(s) if this parameter is set. In case you haven't migrated to AEGs yet, see https://bazel.build/extending/auto-exec-groups#migration-aegs. |
-| `fragments` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  List of names of configuration fragments that the subrule requires in target configuration. |
-| `subrules` | [sequence](../core/list) of [Subrule](../builtins/Subrule)s; default is `[]`  List of other subrules needed by this subrule. |
+| `implementation` | [function](/versions/8.4.2/rules/lib/core/function); required  The Starlark function implementing this subrule |
+| `attrs` | [dict](/versions/8.4.2/rules/lib/core/dict); default is `{}`  A dictionary to declare all the (private) attributes of the subrule.  Subrules may only have private attributes that are label-typed (i.e. label or label-list). The resolved values corresponding to these labels are automatically passed by Bazel to the subrule's implementation function as named arguments (thus the implementation function is required to accept named parameters matching the attribute names). The types of these values will be:  * `FilesToRunProvider` for label attributes with `executable=True` * `File` for label attributes with `allow_single_file=True` * `Target` for all other label attributes * `[Target]` for all label-list attributes |
+| `toolchains` | [sequence](/versions/8.4.2/rules/lib/core/list); default is `[]`  If set, the set of toolchains this subrule requires. The list can contain String, Label, or StarlarkToolchainTypeApi objects, in any combination. Toolchains will be found by checking the current platform, and provided to the subrule implementation via `ctx.toolchains`. Note that AEGs need to be enabled on the consuming rule(s) if this parameter is set. In case you haven't migrated to AEGs yet, see https://bazel.build/extending/auto-exec-groups#migration-aegs. |
+| `fragments` | [sequence](/versions/8.4.2/rules/lib/core/list) of [string](/versions/8.4.2/rules/lib/core/string)s; default is `[]`  List of names of configuration fragments that the subrule requires in target configuration. |
+| `subrules` | [sequence](/versions/8.4.2/rules/lib/core/list) of [Subrule](/versions/8.4.2/rules/lib/builtins/Subrule)s; default is `[]`  List of other subrules needed by this subrule. |
 
 ## tag\_class
 
@@ -336,8 +336,8 @@ Creates a new tag\_class object, which defines an attribute schema for a class o
 
 | Parameter | Description |
 | --- | --- |
-| `attrs` | [dict](../core/dict); default is `{}`  A dictionary to declare all the attributes of this tag class. It maps from an attribute name to an attribute object (see [attr](../toplevel/attr) module). Note that unlike [`rule()`](../globals/bzl#rule), [`aspect()`](../globals/bzl#aspect) and [`repository_rule()`](../globals/bzl#repository_rule), declared attributes will not convert `None` to the default value. For the default to be used, the attribute must be omitted entirely by the caller. |
-| `doc` | [string](../core/string); or `None`; default is `None`  A description of the tag class that can be extracted by documentation generating tools. |
+| `attrs` | [dict](/versions/8.4.2/rules/lib/core/dict); default is `{}`  A dictionary to declare all the attributes of this tag class. It maps from an attribute name to an attribute object (see [attr](/versions/8.4.2/rules/lib/toplevel/attr) module). Note that unlike [`rule()`](/versions/8.4.2/rules/lib/globals/bzl#rule), [`aspect()`](/versions/8.4.2/rules/lib/globals/bzl#aspect) and [`repository_rule()`](/versions/8.4.2/rules/lib/globals/bzl#repository_rule), declared attributes will not convert `None` to the default value. For the default to be used, the attribute must be omitted entirely by the caller. |
+| `doc` | [string](/versions/8.4.2/rules/lib/core/string); or `None`; default is `None`  A description of the tag class that can be extracted by documentation generating tools. |
 
 ## visibility
 
diff --git a/versions/8.4.2/rules/lib/globals/module.mdx b/versions/8.4.2/rules/lib/globals/module.mdx
index 8c2cc820..68f313b2 100644
--- a/versions/8.4.2/rules/lib/globals/module.mdx
+++ b/versions/8.4.2/rules/lib/globals/module.mdx
@@ -30,7 +30,7 @@ None archive_override(module_name, **kwargs)
 
 Specifies that this dependency should come from an archive file (zip, gzip, etc) at a
 certain location, instead of from a registry. Effectively, this dependency will be
-backed by an [`http_archive`](../repo/http#http_archive) rule.
+backed by an [`http_archive`](/versions/8.4.2/rules/lib/repo/http#http_archive) rule.
 
 This directive only takes effect in the root module; in other words, if a module is
 used as a dependency by others, its own overrides are ignored.
@@ -39,7 +39,7 @@ used as a dependency by others, its own overrides are ignored.
 
 | Parameter | Description |
 | --- | --- |
-| `module_name` | [string](../core/string); required  The name of the Bazel module dependency to apply this override to. |
+| `module_name` | [string](/versions/8.4.2/rules/lib/core/string); required  The name of the Bazel module dependency to apply this override to. |
 | `kwargs` | required  All other arguments are forwarded to the underlying `http_archive` repo rule. Note that the `name` attribute shouldn't be specified; use `module_name` instead. |
 
 ## bazel\_dep
@@ -54,11 +54,11 @@ Declares a direct dependency on another Bazel module.
 
 | Parameter | Description |
 | --- | --- |
-| `name` | [string](../core/string); required  The name of the module to be added as a direct dependency. |
-| `version` | [string](../core/string); default is `''`  The version of the module to be added as a direct dependency. |
-| `max_compatibility_level` | [int](../core/int); default is `-1`  The maximum `compatibility_level` supported for the module to be added as a direct dependency. The version of the module implies the minimum compatibility\_level supported, as well as the maximum if this attribute is not specified. |
-| `repo_name` | [string](../core/string); or `None`; default is `''`  The name of the external repo representing this dependency. This is by default the name of the module. Can be set to `None` to make this dependency a "*nodep*" dependency: in this case, this `bazel_dep` specification is only honored if the target module already exists in the dependency graph by some other means. |
-| `dev_dependency` | [bool](../core/bool); default is `False`  If true, this dependency will be ignored if the current module is not the root module or `--ignore_dev_dependency` is enabled. |
+| `name` | [string](/versions/8.4.2/rules/lib/core/string); required  The name of the module to be added as a direct dependency. |
+| `version` | [string](/versions/8.4.2/rules/lib/core/string); default is `''`  The version of the module to be added as a direct dependency. |
+| `max_compatibility_level` | [int](/versions/8.4.2/rules/lib/core/int); default is `-1`  The maximum `compatibility_level` supported for the module to be added as a direct dependency. The version of the module implies the minimum compatibility\_level supported, as well as the maximum if this attribute is not specified. |
+| `repo_name` | [string](/versions/8.4.2/rules/lib/core/string); or `None`; default is `''`  The name of the external repo representing this dependency. This is by default the name of the module. Can be set to `None` to make this dependency a "*nodep*" dependency: in this case, this `bazel_dep` specification is only honored if the target module already exists in the dependency graph by some other means. |
+| `dev_dependency` | [bool](/versions/8.4.2/rules/lib/core/bool); default is `False`  If true, this dependency will be ignored if the current module is not the root module or `--ignore_dev_dependency` is enabled. |
 
 ## git\_override
 
@@ -68,7 +68,7 @@ None git_override(module_name, **kwargs)
 
 Specifies that this dependency should come from a certain commit in a Git repository,
 instead of from a registry. Effectively, this dependency will be backed by a
-[`git_repository`](../repo/git#git_repository) rule.
+[`git_repository`](/versions/8.4.2/rules/lib/repo/git#git_repository) rule.
 
 This directive only takes effect in the root module; in other words, if a module is
 used as a dependency by others, its own overrides are ignored.
@@ -77,7 +77,7 @@ used as a dependency by others, its own overrides are ignored.
 
 | Parameter | Description |
 | --- | --- |
-| `module_name` | [string](../core/string); required  The name of the Bazel module dependency to apply this override to. |
+| `module_name` | [string](/versions/8.4.2/rules/lib/core/string); required  The name of the Bazel module dependency to apply this override to. |
 | `kwargs` | required  All other arguments are forwarded to the underlying `git_repository` repo rule. Note that the `name` attribute shouldn't be specified; use `module_name` instead. |
 
 ## include
@@ -98,7 +98,7 @@ Only files in the main repo may be included.
 
 | Parameter | Description |
 | --- | --- |
-| `label` | [string](../core/string); required  The label pointing to the file to include. The label must point to a file in the main repo; in other words, it **must **start with double slashes (`//`). The name of the file must end with `.MODULE.bazel` and must not start with `.`.**** |
+| `label` | [string](/versions/8.4.2/rules/lib/core/string); required  The label pointing to the file to include. The label must point to a file in the main repo; in other words, it **must **start with double slashes (`//`). The name of the file must end with `.MODULE.bazel` and must not start with `.`.**** |
 
 ## inject\_repo
 
@@ -138,8 +138,8 @@ used as a dependency by others, its own overrides are ignored.
 
 | Parameter | Description |
 | --- | --- |
-| `module_name` | [string](../core/string); required  The name of the Bazel module dependency to apply this override to. |
-| `path` | [string](../core/string); required  The path to the directory where this module is. |
+| `module_name` | [string](/versions/8.4.2/rules/lib/core/string); required  The name of the Bazel module dependency to apply this override to. |
+| `path` | [string](/versions/8.4.2/rules/lib/core/string); required  The path to the directory where this module is. |
 
 ## module
 
@@ -155,11 +155,11 @@ It should be called at most once, and if called, it must be the very first direc
 
 | Parameter | Description |
 | --- | --- |
-| `name` | [string](../core/string); default is `''`  The name of the module. Can be omitted only if this module is the root module (as in, if it's not going to be depended on by another module). A valid module name must: 1) only contain lowercase letters (a-z), digits (0-9), dots (.), hyphens (-), and underscores (\_); 2) begin with a lowercase letter; 3) end with a lowercase letter or digit. |
-| `version` | [string](../core/string); default is `''`  The version of the module. Can be omitted only if this module is the root module (as in, if it's not going to be depended on by another module). The version must be in a relaxed SemVer format; see [the documentation](/versions/8.4.2/external/module#version_format) for more details. |
-| `compatibility_level` | [int](../core/int); default is `0`  The compatibility level of the module; this should be changed every time a major incompatible change is introduced. This is essentially the "major version" of the module in terms of SemVer, except that it's not embedded in the version string itself, but exists as a separate field. Modules with different compatibility levels participate in version resolution as if they're modules with different names, but the final dependency graph cannot contain multiple modules with the same name but different compatibility levels (unless `multiple_version_override` is in effect). See [the documentation](/versions/8.4.2/external/module#compatibility_level) for more details. |
-| `repo_name` | [string](../core/string); default is `''`  The name of the repository representing this module, as seen by the module itself. By default, the name of the repo is the name of the module. This can be specified to ease migration for projects that have been using a repo name for itself that differs from its module name. |
-| `bazel_compatibility` | Iterable of [string](../core/string)s; default is `[]`  A list of bazel versions that allows users to declare which Bazel versions are compatible with this module. It does NOT affect dependency resolution, but bzlmod will use this information to check if your current Bazel version is compatible. The format of this value is a string of some constraint values separated by comma. Three constraints are supported: <=X.X.X: The Bazel version must be equal or older than X.X.X. Used when there is a known incompatible change in a newer version. >=X.X.X: The Bazel version must be equal or newer than X.X.X.Used when you depend on some features that are only available since X.X.X. -X.X.X: The Bazel version X.X.X is not compatible. Used when there is a bug in X.X.X that breaks you, but fixed in later versions. |
+| `name` | [string](/versions/8.4.2/rules/lib/core/string); default is `''`  The name of the module. Can be omitted only if this module is the root module (as in, if it's not going to be depended on by another module). A valid module name must: 1) only contain lowercase letters (a-z), digits (0-9), dots (.), hyphens (-), and underscores (\_); 2) begin with a lowercase letter; 3) end with a lowercase letter or digit. |
+| `version` | [string](/versions/8.4.2/rules/lib/core/string); default is `''`  The version of the module. Can be omitted only if this module is the root module (as in, if it's not going to be depended on by another module). The version must be in a relaxed SemVer format; see [the documentation](/versions/8.4.2/external/module#version_format) for more details. |
+| `compatibility_level` | [int](/versions/8.4.2/rules/lib/core/int); default is `0`  The compatibility level of the module; this should be changed every time a major incompatible change is introduced. This is essentially the "major version" of the module in terms of SemVer, except that it's not embedded in the version string itself, but exists as a separate field. Modules with different compatibility levels participate in version resolution as if they're modules with different names, but the final dependency graph cannot contain multiple modules with the same name but different compatibility levels (unless `multiple_version_override` is in effect). See [the documentation](/versions/8.4.2/external/module#compatibility_level) for more details. |
+| `repo_name` | [string](/versions/8.4.2/rules/lib/core/string); default is `''`  The name of the repository representing this module, as seen by the module itself. By default, the name of the repo is the name of the module. This can be specified to ease migration for projects that have been using a repo name for itself that differs from its module name. |
+| `bazel_compatibility` | Iterable of [string](/versions/8.4.2/rules/lib/core/string)s; default is `[]`  A list of bazel versions that allows users to declare which Bazel versions are compatible with this module. It does NOT affect dependency resolution, but bzlmod will use this information to check if your current Bazel version is compatible. The format of this value is a string of some constraint values separated by comma. Three constraints are supported: <=X.X.X: The Bazel version must be equal or older than X.X.X. Used when there is a known incompatible change in a newer version. >=X.X.X: The Bazel version must be equal or newer than X.X.X.Used when you depend on some features that are only available since X.X.X. -X.X.X: The Bazel version X.X.X is not compatible. Used when there is a bug in X.X.X that breaks you, but fixed in later versions. |
 
 ## multiple\_version\_override
 
@@ -173,9 +173,9 @@ Specifies that a dependency should still come from a registry, but multiple vers
 
 | Parameter | Description |
 | --- | --- |
-| `module_name` | [string](../core/string); required  The name of the Bazel module dependency to apply this override to. |
-| `versions` | Iterable of [string](../core/string)s; required  Explicitly specifies the versions allowed to coexist. These versions must already be present in the dependency graph pre-selection. Dependencies on this module will be "upgraded" to the nearest higher allowed version at the same compatibility level, whereas dependencies that have a higher version than any allowed versions at the same compatibility level will cause an error. |
-| `registry` | [string](../core/string); default is `''`  Overrides the registry for this module; instead of finding this module from the default list of registries, the given registry should be used. |
+| `module_name` | [string](/versions/8.4.2/rules/lib/core/string); required  The name of the Bazel module dependency to apply this override to. |
+| `versions` | Iterable of [string](/versions/8.4.2/rules/lib/core/string)s; required  Explicitly specifies the versions allowed to coexist. These versions must already be present in the dependency graph pre-selection. Dependencies on this module will be "upgraded" to the nearest higher allowed version at the same compatibility level, whereas dependencies that have a higher version than any allowed versions at the same compatibility level will cause an error. |
+| `registry` | [string](/versions/8.4.2/rules/lib/core/string); default is `''`  Overrides the registry for this module; instead of finding this module from the default list of registries, the given registry should be used. |
 
 ## override\_repo
 
@@ -209,8 +209,8 @@ Specifies already-defined execution platforms to be registered when this module
 
 | Parameter | Description |
 | --- | --- |
-| `dev_dependency` | [bool](../core/bool); default is `False`  If true, the execution platforms will not be registered if the current module is not the root module or `--ignore\_dev\_dependency` is enabled. |
-| `platform_labels` | [sequence](../core/list) of [string](../core/string)s; required  The target patterns to register. |
+| `dev_dependency` | [bool](/versions/8.4.2/rules/lib/core/bool); default is `False`  If true, the execution platforms will not be registered if the current module is not the root module or `--ignore\_dev\_dependency` is enabled. |
+| `platform_labels` | [sequence](/versions/8.4.2/rules/lib/core/list) of [string](/versions/8.4.2/rules/lib/core/string)s; required  The target patterns to register. |
 
 ## register\_toolchains
 
@@ -224,8 +224,8 @@ Specifies already-defined toolchains to be registered when this module is select
 
 | Parameter | Description |
 | --- | --- |
-| `dev_dependency` | [bool](../core/bool); default is `False`  If true, the toolchains will not be registered if the current module is not the root module or `--ignore\_dev\_dependency` is enabled. |
-| `toolchain_labels` | [sequence](../core/list) of [string](../core/string)s; required  The target patterns to register. |
+| `dev_dependency` | [bool](/versions/8.4.2/rules/lib/core/bool); default is `False`  If true, the toolchains will not be registered if the current module is not the root module or `--ignore\_dev\_dependency` is enabled. |
+| `toolchain_labels` | [sequence](/versions/8.4.2/rules/lib/core/list) of [string](/versions/8.4.2/rules/lib/core/string)s; required  The target patterns to register. |
 
 ## single\_version\_override
 
@@ -239,12 +239,12 @@ Specifies that a dependency should still come from a registry, but its version s
 
 | Parameter | Description |
 | --- | --- |
-| `module_name` | [string](../core/string); required  The name of the Bazel module dependency to apply this override to. |
-| `version` | [string](../core/string); default is `''`  Overrides the declared version of this module in the dependency graph. In other words, this module will be "pinned" to this override version. This attribute can be omitted if all one wants to override is the registry or the patches. |
-| `registry` | [string](../core/string); default is `''`  Overrides the registry for this module; instead of finding this module from the default list of registries, the given registry should be used. |
-| `patches` | Iterable of [string](../core/string)s; default is `[]`  A list of labels pointing to patch files to apply for this module. The patch files must exist in the source tree of the top level project. They are applied in the list order. If a patch makes changes to the MODULE.bazel file, these changes will only be effective if the patch file is provided by the root module. |
-| `patch_cmds` | Iterable of [string](../core/string)s; default is `[]`  Sequence of Bash commands to be applied on Linux/Macos after patches are applied. Changes to the MODULE.bazel file will not be effective. |
-| `patch_strip` | [int](../core/int); default is `0`  Same as the --strip argument of Unix patch. |
+| `module_name` | [string](/versions/8.4.2/rules/lib/core/string); required  The name of the Bazel module dependency to apply this override to. |
+| `version` | [string](/versions/8.4.2/rules/lib/core/string); default is `''`  Overrides the declared version of this module in the dependency graph. In other words, this module will be "pinned" to this override version. This attribute can be omitted if all one wants to override is the registry or the patches. |
+| `registry` | [string](/versions/8.4.2/rules/lib/core/string); default is `''`  Overrides the registry for this module; instead of finding this module from the default list of registries, the given registry should be used. |
+| `patches` | Iterable of [string](/versions/8.4.2/rules/lib/core/string)s; default is `[]`  A list of labels pointing to patch files to apply for this module. The patch files must exist in the source tree of the top level project. They are applied in the list order. If a patch makes changes to the MODULE.bazel file, these changes will only be effective if the patch file is provided by the root module. |
+| `patch_cmds` | Iterable of [string](/versions/8.4.2/rules/lib/core/string)s; default is `[]`  Sequence of Bash commands to be applied on Linux/Macos after patches are applied. Changes to the MODULE.bazel file will not be effective. |
+| `patch_strip` | [int](/versions/8.4.2/rules/lib/core/int); default is `0`  Same as the --strip argument of Unix patch. |
 
 ## use\_extension
 
@@ -258,10 +258,10 @@ Returns a proxy object representing a module extension; its methods can be invok
 
 | Parameter | Description |
 | --- | --- |
-| `extension_bzl_file` | [string](../core/string); required  A label to the Starlark file defining the module extension. |
-| `extension_name` | [string](../core/string); required  The name of the module extension to use. A symbol with this name must be exported by the Starlark file. |
-| `dev_dependency` | [bool](../core/bool); default is `False`  If true, this usage of the module extension will be ignored if the current module is not the root module or `--ignore\_dev\_dependency` is enabled. |
-| `isolate` | [bool](../core/bool); default is `False`  **Experimental**. This parameter is experimental and may change at any time. Please do not depend on it. It may be enabled on an experimental basis by setting `--experimental_isolated_extension_usages`  If true, this usage of the module extension will be isolated from all other usages, both in this and other modules. Tags created for this usage do not affect other usages and the repositories generated by the extension for this usage will be distinct from all other repositories generated by the extension. This parameter is currently experimental and only available with the flag `--experimental_isolated_extension_usages`. |
+| `extension_bzl_file` | [string](/versions/8.4.2/rules/lib/core/string); required  A label to the Starlark file defining the module extension. |
+| `extension_name` | [string](/versions/8.4.2/rules/lib/core/string); required  The name of the module extension to use. A symbol with this name must be exported by the Starlark file. |
+| `dev_dependency` | [bool](/versions/8.4.2/rules/lib/core/bool); default is `False`  If true, this usage of the module extension will be ignored if the current module is not the root module or `--ignore\_dev\_dependency` is enabled. |
+| `isolate` | [bool](/versions/8.4.2/rules/lib/core/bool); default is `False`  **Experimental**. This parameter is experimental and may change at any time. Please do not depend on it. It may be enabled on an experimental basis by setting `--experimental_isolated_extension_usages`  If true, this usage of the module extension will be isolated from all other usages, both in this and other modules. Tags created for this usage do not affect other usages and the repositories generated by the extension for this usage will be distinct from all other repositories generated by the extension. This parameter is currently experimental and only available with the flag `--experimental_isolated_extension_usages`. |
 
 ## use\_repo
 
@@ -291,5 +291,5 @@ Returns a proxy value that can be directly invoked in the MODULE.bazel file as a
 
 | Parameter | Description |
 | --- | --- |
-| `repo_rule_bzl_file` | [string](../core/string); required  A label to the Starlark file defining the repo rule. |
-| `repo_rule_name` | [string](../core/string); required  The name of the repo rule to use. A symbol with this name must be exported by the Starlark file. |
\ No newline at end of file
+| `repo_rule_bzl_file` | [string](/versions/8.4.2/rules/lib/core/string); required  A label to the Starlark file defining the repo rule. |
+| `repo_rule_name` | [string](/versions/8.4.2/rules/lib/core/string); required  The name of the repo rule to use. A symbol with this name must be exported by the Starlark file. |
\ No newline at end of file
diff --git a/versions/8.4.2/rules/lib/globals/repo.mdx b/versions/8.4.2/rules/lib/globals/repo.mdx
index 465a17c4..b89db5db 100644
--- a/versions/8.4.2/rules/lib/globals/repo.mdx
+++ b/versions/8.4.2/rules/lib/globals/repo.mdx
@@ -23,7 +23,7 @@ This function takes a list of strings and a directory is ignored if any of the g
 
 | Parameter | Description |
 | --- | --- |
-| `dirs` | [sequence](../core/list) of [string](../core/string)s; required |
+| `dirs` | [sequence](/versions/8.4.2/rules/lib/core/list) of [string](/versions/8.4.2/rules/lib/core/string)s; required |
 
 ## repo
 
diff --git a/versions/8.4.2/rules/lib/globals/workspace.mdx b/versions/8.4.2/rules/lib/globals/workspace.mdx
index 40167008..fd221dbc 100644
--- a/versions/8.4.2/rules/lib/globals/workspace.mdx
+++ b/versions/8.4.2/rules/lib/globals/workspace.mdx
@@ -25,8 +25,8 @@ Gives a target an alias in the `//external` package.
 
 | Parameter | Description |
 | --- | --- |
-| `name` | [string](../core/string); required  The label under '//external' to serve as the alias name |
-| `actual` | [string](../core/string); or `None`; default is `None`  The real label to be aliased |
+| `name` | [string](/versions/8.4.2/rules/lib/core/string); required  The label under '//external' to serve as the alias name |
+| `actual` | [string](/versions/8.4.2/rules/lib/core/string); or `None`; default is `None`  The real label to be aliased |
 
 ## register\_execution\_platforms
 
@@ -40,7 +40,7 @@ Specifies already-defined execution platforms to be registered. Should be absolu
 
 | Parameter | Description |
 | --- | --- |
-| `platform_labels` | [sequence](../core/list) of [string](../core/string)s; required  The target patterns to register. |
+| `platform_labels` | [sequence](/versions/8.4.2/rules/lib/core/list) of [string](/versions/8.4.2/rules/lib/core/string)s; required  The target patterns to register. |
 
 ## register\_toolchains
 
@@ -54,7 +54,7 @@ Specifies already-defined toolchains to be registered. Should be absolute [targe
 
 | Parameter | Description |
 | --- | --- |
-| `toolchain_labels` | [sequence](../core/list) of [string](../core/string)s; required  The target patterns to register. |
+| `toolchain_labels` | [sequence](/versions/8.4.2/rules/lib/core/list) of [string](/versions/8.4.2/rules/lib/core/string)s; required  The target patterns to register. |
 
 ## workspace
 
@@ -74,4 +74,4 @@ This name is used for the directory that the repository's runfiles are stored in
 
 | Parameter | Description |
 | --- | --- |
-| `name` | [string](../core/string); required  the name of the workspace. Names must start with a letter and can only contain letters, numbers, underscores, dashes, and dots. |
\ No newline at end of file
+| `name` | [string](/versions/8.4.2/rules/lib/core/string); required  the name of the workspace. Names must start with a letter and can only contain letters, numbers, underscores, dashes, and dots. |
\ No newline at end of file
diff --git a/versions/8.4.2/rules/lib/providers/AnalysisTestResultInfo.mdx b/versions/8.4.2/rules/lib/providers/AnalysisTestResultInfo.mdx
index 1edabb04..c8e8f8fc 100644
--- a/versions/8.4.2/rules/lib/providers/AnalysisTestResultInfo.mdx
+++ b/versions/8.4.2/rules/lib/providers/AnalysisTestResultInfo.mdx
@@ -22,8 +22,8 @@ The `AnalysisTestResultInfo` constructor.
 
 | Parameter | Description |
 | --- | --- |
-| `success` | [bool](../core/bool); required  If true, then the analysis-phase test represented by this target should pass. If false, the test should fail. |
-| `message` | [string](../core/string); required  A descriptive message containing information about the test and its success/failure. |
+| `success` | [bool](/versions/8.4.2/rules/lib/core/bool); required  If true, then the analysis-phase test represented by this target should pass. If false, the test should fail. |
+| `message` | [string](/versions/8.4.2/rules/lib/core/string); required  A descriptive message containing information about the test and its success/failure. |
 
 ## message
 
diff --git a/versions/8.4.2/rules/lib/providers/CcInfo.mdx b/versions/8.4.2/rules/lib/providers/CcInfo.mdx
index f3c0d961..a74f6113 100644
--- a/versions/8.4.2/rules/lib/providers/CcInfo.mdx
+++ b/versions/8.4.2/rules/lib/providers/CcInfo.mdx
@@ -22,8 +22,8 @@ The `CcInfo` constructor.
 
 | Parameter | Description |
 | --- | --- |
-| `compilation_context` | [CompilationContext](../builtins/CompilationContext); or `None`; default is `None`  The `CompilationContext`. |
-| `linking_context` | [LinkingContext](../builtins/LinkingContext); or `None`; default is `None`  The `LinkingContext`. |
+| `compilation_context` | [CompilationContext](/versions/8.4.2/rules/lib/builtins/CompilationContext); or `None`; default is `None`  The `CompilationContext`. |
+| `linking_context` | [LinkingContext](/versions/8.4.2/rules/lib/builtins/LinkingContext); or `None`; default is `None`  The `LinkingContext`. |
 | `debug_context` | DebugContext; or `None`; default is `None`  The `DebugContext`. |
 
 ## compilation\_context
diff --git a/versions/8.4.2/rules/lib/providers/DebugPackageInfo.mdx b/versions/8.4.2/rules/lib/providers/DebugPackageInfo.mdx
index 777c8ebd..168241ed 100644
--- a/versions/8.4.2/rules/lib/providers/DebugPackageInfo.mdx
+++ b/versions/8.4.2/rules/lib/providers/DebugPackageInfo.mdx
@@ -24,10 +24,10 @@ The `DebugPackageInfo` constructor.
 
 | Parameter | Description |
 | --- | --- |
-| `target_label` | [Label](../builtins/Label); required  The label for the \*\_binary target |
-| `stripped_file` | [File](../builtins/File); or `None`; default is `None`  The stripped file (the explicit ".stripped" target) |
-| `unstripped_file` | [File](../builtins/File); required  The unstripped file (the default executable target). |
-| `dwp_file` | [File](../builtins/File); or `None`; default is `None`  The .dwp file (for fission builds) or null if --fission=no. |
+| `target_label` | [Label](/versions/8.4.2/rules/lib/builtins/Label); required  The label for the \*\_binary target |
+| `stripped_file` | [File](/versions/8.4.2/rules/lib/builtins/File); or `None`; default is `None`  The stripped file (the explicit ".stripped" target) |
+| `unstripped_file` | [File](/versions/8.4.2/rules/lib/builtins/File); required  The unstripped file (the default executable target). |
+| `dwp_file` | [File](/versions/8.4.2/rules/lib/builtins/File); or `None`; default is `None`  The .dwp file (for fission builds) or null if --fission=no. |
 
 ## dwp\_file
 
diff --git a/versions/8.4.2/rules/lib/providers/DefaultInfo.mdx b/versions/8.4.2/rules/lib/providers/DefaultInfo.mdx
index 332ea264..4548153d 100644
--- a/versions/8.4.2/rules/lib/providers/DefaultInfo.mdx
+++ b/versions/8.4.2/rules/lib/providers/DefaultInfo.mdx
@@ -28,11 +28,11 @@ The `DefaultInfo` constructor.
 
 | Parameter | Description |
 | --- | --- |
-| `files` | [depset](../builtins/depset); or `None`; default is `None`  A [`depset`](../builtins/depset) of [`File`](../builtins/File) objects representing the default outputs to build when this target is specified on the bazel command line. By default it is all predeclared outputs. |
-| `runfiles` | [runfiles](../builtins/runfiles); or `None`; default is `None`  runfiles descriptor describing the files that this target needs when run (via the `run` command or as a tool dependency). |
-| `data_runfiles` | [runfiles](../builtins/runfiles); or `None`; default is `None`  **It is recommended that you avoid using this parameter (see ["runfiles features to avoid"](https://bazel.build/versions/8.4.2/extending/rules#runfiles_features_to_avoid))** runfiles descriptor describing the runfiles this target needs to run when it is a dependency via the `data` attribute. |
-| `default_runfiles` | [runfiles](../builtins/runfiles); or `None`; default is `None`  **It is recommended that you avoid using this parameter (see ["runfiles features to avoid"](https://bazel.build/versions/8.4.2/extending/rules#runfiles_features_to_avoid))** runfiles descriptor describing the runfiles this target needs to run when it is a dependency via any attribute other than the `data` attribute. |
-| `executable` | [File](../builtins/File); or `None`; default is `None`  If this rule is marked [`executable`](../globals/bzl#rule.executable) or [`test`](../globals/bzl#rule.test), this is a [`File`](../builtins/File) object representing the file that should be executed to run the target. By default it is the predeclared output `ctx.outputs.executable` but it is recommended to pass another file (either predeclared or not) explicitly. |
+| `files` | [depset](/versions/8.4.2/rules/lib/builtins/depset); or `None`; default is `None`  A [`depset`](/versions/8.4.2/rules/lib/builtins/depset) of [`File`](/versions/8.4.2/rules/lib/builtins/File) objects representing the default outputs to build when this target is specified on the bazel command line. By default it is all predeclared outputs. |
+| `runfiles` | [runfiles](/versions/8.4.2/rules/lib/builtins/runfiles); or `None`; default is `None`  runfiles descriptor describing the files that this target needs when run (via the `run` command or as a tool dependency). |
+| `data_runfiles` | [runfiles](/versions/8.4.2/rules/lib/builtins/runfiles); or `None`; default is `None`  **It is recommended that you avoid using this parameter (see ["runfiles features to avoid"](https://bazel.build/versions/8.4.2/extending/rules#runfiles_features_to_avoid))** runfiles descriptor describing the runfiles this target needs to run when it is a dependency via the `data` attribute. |
+| `default_runfiles` | [runfiles](/versions/8.4.2/rules/lib/builtins/runfiles); or `None`; default is `None`  **It is recommended that you avoid using this parameter (see ["runfiles features to avoid"](https://bazel.build/versions/8.4.2/extending/rules#runfiles_features_to_avoid))** runfiles descriptor describing the runfiles this target needs to run when it is a dependency via any attribute other than the `data` attribute. |
+| `executable` | [File](/versions/8.4.2/rules/lib/builtins/File); or `None`; default is `None`  If this rule is marked [`executable`](/versions/8.4.2/rules/lib/globals/bzl#rule.executable) or [`test`](/versions/8.4.2/rules/lib/globals/bzl#rule.test), this is a [`File`](/versions/8.4.2/rules/lib/builtins/File) object representing the file that should be executed to run the target. By default it is the predeclared output `ctx.outputs.executable` but it is recommended to pass another file (either predeclared or not) explicitly. |
 
 ## data\_runfiles
 
@@ -58,7 +58,7 @@ May return `None`.
 depset DefaultInfo.files
 ```
 
-A [`depset`](../builtins/depset) of [`File`](../builtins/File) objects representing the default outputs to build when this target is specified on the bazel command line. By default it is all predeclared outputs.
+A [`depset`](/versions/8.4.2/rules/lib/builtins/depset) of [`File`](/versions/8.4.2/rules/lib/builtins/File) objects representing the default outputs to build when this target is specified on the bazel command line. By default it is all predeclared outputs.
 May return `None`.
 
 ## files\_to\_run
@@ -67,5 +67,5 @@ May return `None`.
 FilesToRunProvider DefaultInfo.files_to_run
 ```
 
-A [`FilesToRunProvider`](../providers/FilesToRunProvider) object containing information about the executable and runfiles of the target.
+A [`FilesToRunProvider`](/versions/8.4.2/rules/lib/providers/FilesToRunProvider) object containing information about the executable and runfiles of the target.
 May return `None`.
\ No newline at end of file
diff --git a/versions/8.4.2/rules/lib/providers/ExecutionInfo.mdx b/versions/8.4.2/rules/lib/providers/ExecutionInfo.mdx
index d351095e..a2da4802 100644
--- a/versions/8.4.2/rules/lib/providers/ExecutionInfo.mdx
+++ b/versions/8.4.2/rules/lib/providers/ExecutionInfo.mdx
@@ -22,8 +22,8 @@ Creates an instance.
 
 | Parameter | Description |
 | --- | --- |
-| `requirements` | [dict](../core/dict); default is `{}`  A dict indicating special execution requirements, such as hardware platforms. |
-| `exec_group` | [string](../core/string); default is `'test'`  The name of the exec group that is used to execute the test. |
+| `requirements` | [dict](/versions/8.4.2/rules/lib/core/dict); default is `{}`  A dict indicating special execution requirements, such as hardware platforms. |
+| `exec_group` | [string](/versions/8.4.2/rules/lib/core/string); default is `'test'`  The name of the exec group that is used to execute the test. |
 
 ## exec\_group
 
diff --git a/versions/8.4.2/rules/lib/providers/FeatureFlagInfo.mdx b/versions/8.4.2/rules/lib/providers/FeatureFlagInfo.mdx
index ebade07a..904dc016 100644
--- a/versions/8.4.2/rules/lib/providers/FeatureFlagInfo.mdx
+++ b/versions/8.4.2/rules/lib/providers/FeatureFlagInfo.mdx
@@ -31,7 +31,7 @@ The value of the flag in the configuration used by the flag rule.
 
 | Parameter | Description |
 | --- | --- |
-| `value` | [string](../core/string); required  String, the value to check for validity for this flag. |
+| `value` | [string](/versions/8.4.2/rules/lib/core/string); required  String, the value to check for validity for this flag. |
 
 ## value
 
diff --git a/versions/8.4.2/rules/lib/providers/InstrumentedFilesInfo.mdx b/versions/8.4.2/rules/lib/providers/InstrumentedFilesInfo.mdx
index 25ab4a9e..59427a7c 100644
--- a/versions/8.4.2/rules/lib/providers/InstrumentedFilesInfo.mdx
+++ b/versions/8.4.2/rules/lib/providers/InstrumentedFilesInfo.mdx
@@ -15,7 +15,7 @@ Contains information about source files and instrumentation metadata files for r
 depset InstrumentedFilesInfo.instrumented_files
 ```
 
-[`depset`](../builtins/depset) of [`File`](../builtins/File) objects representing instrumented source files for this target and its dependencies.
+[`depset`](/versions/8.4.2/rules/lib/builtins/depset) of [`File`](/versions/8.4.2/rules/lib/builtins/File) objects representing instrumented source files for this target and its dependencies.
 
 ## metadata\_files
 
@@ -23,4 +23,4 @@ depset InstrumentedFilesInfo.instrumented_files
 depset InstrumentedFilesInfo.metadata_files
 ```
 
-[`depset`](../builtins/depset) of [`File`](../builtins/File) objects representing coverage metadata files for this target and its dependencies. These files contain additional information required to generate LCOV-format coverage output after the code is executed, e.g. the `.gcno` files generated when `gcc` is run with `-ftest-coverage`.
\ No newline at end of file
+[`depset`](/versions/8.4.2/rules/lib/builtins/depset) of [`File`](/versions/8.4.2/rules/lib/builtins/File) objects representing coverage metadata files for this target and its dependencies. These files contain additional information required to generate LCOV-format coverage output after the code is executed, e.g. the `.gcno` files generated when `gcc` is run with `-ftest-coverage`.
\ No newline at end of file
diff --git a/versions/8.4.2/rules/lib/providers/PackageSpecificationInfo.mdx b/versions/8.4.2/rules/lib/providers/PackageSpecificationInfo.mdx
index 242a43e6..d9030510 100644
--- a/versions/8.4.2/rules/lib/providers/PackageSpecificationInfo.mdx
+++ b/versions/8.4.2/rules/lib/providers/PackageSpecificationInfo.mdx
@@ -20,4 +20,4 @@ Checks if a target exists in a package group.
 
 | Parameter | Description |
 | --- | --- |
-| `target` | [Label](../builtins/Label); or [string](../core/string); required  A target which is checked if it exists inside the package group. |
\ No newline at end of file
+| `target` | [Label](/versions/8.4.2/rules/lib/builtins/Label); or [string](/versions/8.4.2/rules/lib/core/string); required  A target which is checked if it exists inside the package group. |
\ No newline at end of file
diff --git a/versions/8.4.2/rules/lib/providers/ProguardSpecProvider.mdx b/versions/8.4.2/rules/lib/providers/ProguardSpecProvider.mdx
index b7a337c2..1afc8a23 100644
--- a/versions/8.4.2/rules/lib/providers/ProguardSpecProvider.mdx
+++ b/versions/8.4.2/rules/lib/providers/ProguardSpecProvider.mdx
@@ -20,4 +20,4 @@ The `ProguardSpecProvider` constructor.
 
 | Parameter | Description |
 | --- | --- |
-| `specs` | [depset](../builtins/depset) of [File](../builtins/File)s; required  Transitive proguard specs. |
\ No newline at end of file
+| `specs` | [depset](/versions/8.4.2/rules/lib/builtins/depset) of [File](/versions/8.4.2/rules/lib/builtins/File)s; required  Transitive proguard specs. |
\ No newline at end of file
diff --git a/versions/8.4.2/rules/lib/repo/index.mdx b/versions/8.4.2/rules/lib/repo/index.mdx
index ab27e81c..69f01635 100644
--- a/versions/8.4.2/rules/lib/repo/index.mdx
+++ b/versions/8.4.2/rules/lib/repo/index.mdx
@@ -3,10 +3,10 @@
 title: 'Repository Rules'
 ---
 
-* [Rules related to git](git)
-* [Rules related to http](http)
-* [Rules related to local directories](local)
+* [Rules related to git](/versions/8.4.2/rules/lib/repo/git)
+* [Rules related to http](/versions/8.4.2/rules/lib/repo/http)
+* [Rules related to local directories](/versions/8.4.2/rules/lib/repo/local)
 
 # Generic functions for repository rule authors
 
-* [Utility functions on patching](utils)
+* [Utility functions on patching](/versions/8.4.2/rules/lib/repo/utils)
diff --git a/versions/8.4.2/rules/lib/toplevel/apple_common.mdx b/versions/8.4.2/rules/lib/toplevel/apple_common.mdx
index d26f9c22..4d3b9f4f 100644
--- a/versions/8.4.2/rules/lib/toplevel/apple_common.mdx
+++ b/versions/8.4.2/rules/lib/toplevel/apple_common.mdx
@@ -21,7 +21,7 @@ Functions for Starlark to access internals of the apple rule implementations.
 dict apple_common.apple_host_system_env(xcode_config)
 ```
 
-Returns a [dict](../core/dict) of environment variables that should be set for actions that need to run build tools on an Apple host system, such as the version of Xcode that should be used. The keys are variable names and the values are their corresponding values.
+Returns a [dict](/versions/8.4.2/rules/lib/core/dict) of environment variables that should be set for actions that need to run build tools on an Apple host system, such as the version of Xcode that should be used. The keys are variable names and the values are their corresponding values.
 
 ### Parameters
 
@@ -43,13 +43,13 @@ Utilities for resolving items from the apple toolchain.
 DottedVersion apple_common.dotted_version(version)
 ```
 
-Creates a new [DottedVersion](../builtins/DottedVersion) instance.
+Creates a new [DottedVersion](/versions/8.4.2/rules/lib/builtins/DottedVersion) instance.
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `version` | [string](../core/string); required  The string representation of the DottedVersion. |
+| `version` | [string](/versions/8.4.2/rules/lib/core/string); required  The string representation of the DottedVersion. |
 
 ## platform
 
@@ -69,7 +69,7 @@ An enum-like struct that contains the following fields corresponding to Apple pl
 * `watchos_device`
 * `watchos_simulator`
 
-These values can be passed to methods that expect a platform, like [XcodeVersionConfig.sdk\_version\_for\_platform](../providers/XcodeVersionConfig#sdk_version_for_platform).
+These values can be passed to methods that expect a platform, like [XcodeVersionConfig.sdk\_version\_for\_platform](/versions/8.4.2/rules/lib/providers/XcodeVersionConfig#sdk_version_for_platform).
 
 ## platform\_type
 
@@ -85,7 +85,7 @@ An enum-like struct that contains the following fields corresponding to Apple pl
 * `visionos`
 * `watchos`
 
-These values can be passed to methods that expect a platform type, like the 'apple' configuration fragment's [multi\_arch\_platform](../fragments/apple#multi_arch_platform) method.
+These values can be passed to methods that expect a platform type, like the 'apple' configuration fragment's [multi\_arch\_platform](/versions/8.4.2/rules/lib/fragments/apple#multi_arch_platform) method.
 
 Example:
 
diff --git a/versions/8.4.2/rules/lib/toplevel/attr.mdx b/versions/8.4.2/rules/lib/toplevel/attr.mdx
index 3cab347c..ee9e2761 100644
--- a/versions/8.4.2/rules/lib/toplevel/attr.mdx
+++ b/versions/8.4.2/rules/lib/toplevel/attr.mdx
@@ -2,7 +2,7 @@
 title: 'attr'
 ---
 
-This is a top-level module for defining the attribute schemas of a rule or aspect. Each function returns an object representing the schema of a single attribute. These objects are used as the values of the `attrs` dictionary argument of [`rule()`](../globals/bzl#rule), [`aspect()`](../globals/bzl#aspect), [`repository_rule()`](../globals/bzl#repository_rule) and [`tag_class()`](../globals/bzl#tag_class).
+This is a top-level module for defining the attribute schemas of a rule or aspect. Each function returns an object representing the schema of a single attribute. These objects are used as the values of the `attrs` dictionary argument of [`rule()`](/versions/8.4.2/rules/lib/globals/bzl#rule), [`aspect()`](/versions/8.4.2/rules/lib/globals/bzl#aspect), [`repository_rule()`](/versions/8.4.2/rules/lib/globals/bzl#repository_rule) and [`tag_class()`](/versions/8.4.2/rules/lib/globals/bzl#tag_class).
 
 See the Rules page for more on [defining](https://bazel.build/versions/8.4.2/extending/rules#attributes)
 and [using](https://bazel.build/versions/8.4.2/extending/rules#implementation_function) attributes.
@@ -29,16 +29,16 @@ and [using](https://bazel.build/versions/8.4.2/extending/rules#implementation_fu
 Attribute attr.bool(configurable=unbound, default=False, doc=None, mandatory=False)
 ```
 
-Creates a schema for a boolean attribute. The corresponding [`ctx.attr`](../builtins/ctx#attr) attribute will be of type [`bool`](../core/bool).
+Creates a schema for a boolean attribute. The corresponding [`ctx.attr`](/versions/8.4.2/rules/lib/builtins/ctx#attr) attribute will be of type [`bool`](/versions/8.4.2/rules/lib/core/bool).
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `configurable` | [bool](../core/bool); or unbound; default is `unbound`  This argument can only be specified for an attribute of a symbolic macro. If `configurable` is explicitly set to `False`, the symbolic macro attribute is non-configurable - in other words, it cannot take a `select()` value. If the `configurable` is either unbound or explicitly set to `True`, the attribute is configurable and can take a `select()` value. For an attribute of a rule or aspect, `configurable` must be left unbound. Most Starlark rule attributes are always configurable, with the exception of `attr.output()`, `attr.output_list()`, and `attr.license()` rule attributes, which are always non-configurable. |
-| `default` | [bool](../core/bool); default is `False`  A default value to use if no value for this attribute is given when instantiating the rule. |
-| `doc` | [string](../core/string); or `None`; default is `None`  A description of the attribute that can be extracted by documentation generating tools. |
-| `mandatory` | [bool](../core/bool); default is `False`  If true, the value must be specified explicitly (even if it has a `default`). |
+| `configurable` | [bool](/versions/8.4.2/rules/lib/core/bool); or unbound; default is `unbound`  This argument can only be specified for an attribute of a symbolic macro. If `configurable` is explicitly set to `False`, the symbolic macro attribute is non-configurable - in other words, it cannot take a `select()` value. If the `configurable` is either unbound or explicitly set to `True`, the attribute is configurable and can take a `select()` value. For an attribute of a rule or aspect, `configurable` must be left unbound. Most Starlark rule attributes are always configurable, with the exception of `attr.output()`, `attr.output_list()`, and `attr.license()` rule attributes, which are always non-configurable. |
+| `default` | [bool](/versions/8.4.2/rules/lib/core/bool); default is `False`  A default value to use if no value for this attribute is given when instantiating the rule. |
+| `doc` | [string](/versions/8.4.2/rules/lib/core/string); or `None`; default is `None`  A description of the attribute that can be extracted by documentation generating tools. |
+| `mandatory` | [bool](/versions/8.4.2/rules/lib/core/bool); default is `False`  If true, the value must be specified explicitly (even if it has a `default`). |
 
 ## int
 
@@ -46,17 +46,17 @@ Creates a schema for a boolean attribute. The corresponding [`ctx.attr`](../buil
 Attribute attr.int(configurable=unbound, default=0, doc=None, mandatory=False, values=[])
 ```
 
-Creates a schema for an integer attribute. The value must be in the signed 32-bit range. The corresponding [`ctx.attr`](../builtins/ctx#attr) attribute will be of type [`int`](../core/int).
+Creates a schema for an integer attribute. The value must be in the signed 32-bit range. The corresponding [`ctx.attr`](/versions/8.4.2/rules/lib/builtins/ctx#attr) attribute will be of type [`int`](/versions/8.4.2/rules/lib/core/int).
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `configurable` | [bool](../core/bool); or unbound; default is `unbound`  This argument can only be specified for an attribute of a symbolic macro. If `configurable` is explicitly set to `False`, the symbolic macro attribute is non-configurable - in other words, it cannot take a `select()` value. If the `configurable` is either unbound or explicitly set to `True`, the attribute is configurable and can take a `select()` value. For an attribute of a rule or aspect, `configurable` must be left unbound. Most Starlark rule attributes are always configurable, with the exception of `attr.output()`, `attr.output_list()`, and `attr.license()` rule attributes, which are always non-configurable. |
-| `default` | [int](../core/int); default is `0`  A default value to use if no value for this attribute is given when instantiating the rule. |
-| `doc` | [string](../core/string); or `None`; default is `None`  A description of the attribute that can be extracted by documentation generating tools. |
-| `mandatory` | [bool](../core/bool); default is `False`  If true, the value must be specified explicitly (even if it has a `default`). |
-| `values` | [sequence](../core/list) of [int](../core/int)s; default is `[]`  The list of allowed values for the attribute. An error is raised if any other value is given. |
+| `configurable` | [bool](/versions/8.4.2/rules/lib/core/bool); or unbound; default is `unbound`  This argument can only be specified for an attribute of a symbolic macro. If `configurable` is explicitly set to `False`, the symbolic macro attribute is non-configurable - in other words, it cannot take a `select()` value. If the `configurable` is either unbound or explicitly set to `True`, the attribute is configurable and can take a `select()` value. For an attribute of a rule or aspect, `configurable` must be left unbound. Most Starlark rule attributes are always configurable, with the exception of `attr.output()`, `attr.output_list()`, and `attr.license()` rule attributes, which are always non-configurable. |
+| `default` | [int](/versions/8.4.2/rules/lib/core/int); default is `0`  A default value to use if no value for this attribute is given when instantiating the rule. |
+| `doc` | [string](/versions/8.4.2/rules/lib/core/string); or `None`; default is `None`  A description of the attribute that can be extracted by documentation generating tools. |
+| `mandatory` | [bool](/versions/8.4.2/rules/lib/core/bool); default is `False`  If true, the value must be specified explicitly (even if it has a `default`). |
+| `values` | [sequence](/versions/8.4.2/rules/lib/core/list) of [int](/versions/8.4.2/rules/lib/core/int)s; default is `[]`  The list of allowed values for the attribute. An error is raised if any other value is given. |
 
 ## int\_list
 
@@ -70,11 +70,11 @@ Creates a schema for a list-of-integers attribute. Each element must be in the s
 
 | Parameter | Description |
 | --- | --- |
-| `mandatory` | [bool](../core/bool); default is `False`  If true, the value must be specified explicitly (even if it has a `default`). |
-| `allow_empty` | [bool](../core/bool); default is `True`  True if the attribute can be empty. |
-| `configurable` | [bool](../core/bool); or unbound; default is `unbound`  This argument can only be specified for an attribute of a symbolic macro. If `configurable` is explicitly set to `False`, the symbolic macro attribute is non-configurable - in other words, it cannot take a `select()` value. If the `configurable` is either unbound or explicitly set to `True`, the attribute is configurable and can take a `select()` value. For an attribute of a rule or aspect, `configurable` must be left unbound. Most Starlark rule attributes are always configurable, with the exception of `attr.output()`, `attr.output_list()`, and `attr.license()` rule attributes, which are always non-configurable. |
-| `default` | [sequence](../core/list) of [int](../core/int)s; default is `[]`  A default value to use if no value for this attribute is given when instantiating the rule. |
-| `doc` | [string](../core/string); or `None`; default is `None`  A description of the attribute that can be extracted by documentation generating tools. |
+| `mandatory` | [bool](/versions/8.4.2/rules/lib/core/bool); default is `False`  If true, the value must be specified explicitly (even if it has a `default`). |
+| `allow_empty` | [bool](/versions/8.4.2/rules/lib/core/bool); default is `True`  True if the attribute can be empty. |
+| `configurable` | [bool](/versions/8.4.2/rules/lib/core/bool); or unbound; default is `unbound`  This argument can only be specified for an attribute of a symbolic macro. If `configurable` is explicitly set to `False`, the symbolic macro attribute is non-configurable - in other words, it cannot take a `select()` value. If the `configurable` is either unbound or explicitly set to `True`, the attribute is configurable and can take a `select()` value. For an attribute of a rule or aspect, `configurable` must be left unbound. Most Starlark rule attributes are always configurable, with the exception of `attr.output()`, `attr.output_list()`, and `attr.license()` rule attributes, which are always non-configurable. |
+| `default` | [sequence](/versions/8.4.2/rules/lib/core/list) of [int](/versions/8.4.2/rules/lib/core/int)s; default is `[]`  A default value to use if no value for this attribute is given when instantiating the rule. |
+| `doc` | [string](/versions/8.4.2/rules/lib/core/string); or `None`; default is `None`  A description of the attribute that can be extracted by documentation generating tools. |
 
 ## label
 
@@ -84,9 +84,9 @@ Attribute attr.label(configurable=unbound, default=None, materializer=None, doc=
 
 Creates a schema for a label attribute. This is a dependency attribute.
 
-This attribute contains unique [`Label`](../builtins/Label) values. If a string is supplied in place of a `Label`, it will be converted using the [label constructor](../builtins/Label#Label). The relative parts of the label path, including the (possibly renamed) repository, are resolved with respect to the instantiated target's package.
+This attribute contains unique [`Label`](/versions/8.4.2/rules/lib/builtins/Label) values. If a string is supplied in place of a `Label`, it will be converted using the [label constructor](/versions/8.4.2/rules/lib/builtins/Label#Label). The relative parts of the label path, including the (possibly renamed) repository, are resolved with respect to the instantiated target's package.
 
-At analysis time (within the rule's implementation function), when retrieving the attribute value from `ctx.attr`, labels are replaced by the corresponding [`Target`](../builtins/Target)s. This allows you to access the providers of the current target's dependencies.
+At analysis time (within the rule's implementation function), when retrieving the attribute value from `ctx.attr`, labels are replaced by the corresponding [`Target`](/versions/8.4.2/rules/lib/builtins/Target)s. This allows you to access the providers of the current target's dependencies.
 
 In addition to ordinary source files, this kind of attribute is often used to refer to a tool -- for example, a compiler. Such tools are considered to be dependencies, just like source files. To avoid requiring users to specify the tool's label every time they use the rule in their BUILD files, you can hard-code the label of a canonical tool as the `default` value of this attribute. If you also want to prevent users from overriding this default, you can make the attribute private by giving it a name that starts with an underscore. See the [Rules](https://bazel.build/versions/8.4.2/extending/rules#private-attributes) page for more information.
 
@@ -94,21 +94,21 @@ In addition to ordinary source files, this kind of attribute is often used to re
 
 | Parameter | Description |
 | --- | --- |
-| `configurable` | [bool](../core/bool); or unbound; default is `unbound`  This argument can only be specified for an attribute of a symbolic macro. If `configurable` is explicitly set to `False`, the symbolic macro attribute is non-configurable - in other words, it cannot take a `select()` value. If the `configurable` is either unbound or explicitly set to `True`, the attribute is configurable and can take a `select()` value. For an attribute of a rule or aspect, `configurable` must be left unbound. Most Starlark rule attributes are always configurable, with the exception of `attr.output()`, `attr.output_list()`, and `attr.license()` rule attributes, which are always non-configurable. |
-| `default` | [Label](../builtins/Label); or [string](../core/string); or [LateBoundDefault](../builtins/LateBoundDefault); or NativeComputedDefault; or [function](../core/function); or `None`; default is `None`  A default value to use if no value for this attribute is given when instantiating the rule.Use a string or the [`Label`](../builtins/Label#Label) function to specify a default value, for example, `attr.label(default = "//a:b")`. |
-| `materializer` | [function](../core/function); default is `None`  **Experimental**. This parameter is experimental and may change at any time. Please do not depend on it. It may be enabled on an experimental basis by setting `--experimental_dormant_deps`  If set, the attribute materializes dormant dependencies from the transitive closure. The value of this parameter must be a functon that gets access to the values of the attributes of the rule that either are not dependencies or are marked as available for dependency resolution. It must return either a dormant dependency or a list of them depending on the type of the attribute |
-| `doc` | [string](../core/string); or `None`; default is `None` |
-| `executable` | [bool](../core/bool); default is `False`  True if the dependency has to be executable. This means the label must refer to an executable file, or to a rule that outputs an executable file. Access the label with `ctx.executable.`. |
-| `allow_files` | [bool](../core/bool); or [sequence](../core/list) of [string](../core/string)s; or `None`; default is `None`  Whether `File` targets are allowed. Can be `True`, `False` (default), or a list of file extensions that are allowed (for example, `[".cc", ".cpp"]`). |
-| `allow_single_file` | default is `None`  This is similar to `allow_files`, with the restriction that the label must correspond to a single [File](../builtins/File). Access it through `ctx.file.`. |
-| `mandatory` | [bool](../core/bool); default is `False`  If true, the value must be specified explicitly (even if it has a `default`). |
-| `skip_validations` | [bool](../core/bool); default is `False`  If true, validation actions of transitive dependencies from this attribute will not run. This is a temporary mitigation and WILL be removed in the future. |
-| `providers` | [sequence](../core/list); default is `[]`  The providers that must be given by any dependency appearing in this attribute. The format of this argument is a list of lists of providers -- `*Info` objects returned by [`provider()`](../globals/bzl#provider) (or in the case of a legacy provider, its string name). The dependency must return ALL providers mentioned in at least ONE of the inner lists. As a convenience, this argument may also be a single-level list of providers, in which case it is wrapped in an outer list with one element. It is NOT required that the rule of the dependency advertises those providers in its `provides` parameter, however, it is considered best practice. |
+| `configurable` | [bool](/versions/8.4.2/rules/lib/core/bool); or unbound; default is `unbound`  This argument can only be specified for an attribute of a symbolic macro. If `configurable` is explicitly set to `False`, the symbolic macro attribute is non-configurable - in other words, it cannot take a `select()` value. If the `configurable` is either unbound or explicitly set to `True`, the attribute is configurable and can take a `select()` value. For an attribute of a rule or aspect, `configurable` must be left unbound. Most Starlark rule attributes are always configurable, with the exception of `attr.output()`, `attr.output_list()`, and `attr.license()` rule attributes, which are always non-configurable. |
+| `default` | [Label](/versions/8.4.2/rules/lib/builtins/Label); or [string](/versions/8.4.2/rules/lib/core/string); or [LateBoundDefault](/versions/8.4.2/rules/lib/builtins/LateBoundDefault); or NativeComputedDefault; or [function](/versions/8.4.2/rules/lib/core/function); or `None`; default is `None`  A default value to use if no value for this attribute is given when instantiating the rule.Use a string or the [`Label`](/versions/8.4.2/rules/lib/builtins/Label#Label) function to specify a default value, for example, `attr.label(default = "//a:b")`. |
+| `materializer` | [function](/versions/8.4.2/rules/lib/core/function); default is `None`  **Experimental**. This parameter is experimental and may change at any time. Please do not depend on it. It may be enabled on an experimental basis by setting `--experimental_dormant_deps`  If set, the attribute materializes dormant dependencies from the transitive closure. The value of this parameter must be a functon that gets access to the values of the attributes of the rule that either are not dependencies or are marked as available for dependency resolution. It must return either a dormant dependency or a list of them depending on the type of the attribute |
+| `doc` | [string](/versions/8.4.2/rules/lib/core/string); or `None`; default is `None` |
+| `executable` | [bool](/versions/8.4.2/rules/lib/core/bool); default is `False`  True if the dependency has to be executable. This means the label must refer to an executable file, or to a rule that outputs an executable file. Access the label with `ctx.executable.`. |
+| `allow_files` | [bool](/versions/8.4.2/rules/lib/core/bool); or [sequence](/versions/8.4.2/rules/lib/core/list) of [string](/versions/8.4.2/rules/lib/core/string)s; or `None`; default is `None`  Whether `File` targets are allowed. Can be `True`, `False` (default), or a list of file extensions that are allowed (for example, `[".cc", ".cpp"]`). |
+| `allow_single_file` | default is `None`  This is similar to `allow_files`, with the restriction that the label must correspond to a single [File](/versions/8.4.2/rules/lib/builtins/File). Access it through `ctx.file.`. |
+| `mandatory` | [bool](/versions/8.4.2/rules/lib/core/bool); default is `False`  If true, the value must be specified explicitly (even if it has a `default`). |
+| `skip_validations` | [bool](/versions/8.4.2/rules/lib/core/bool); default is `False`  If true, validation actions of transitive dependencies from this attribute will not run. This is a temporary mitigation and WILL be removed in the future. |
+| `providers` | [sequence](/versions/8.4.2/rules/lib/core/list); default is `[]`  The providers that must be given by any dependency appearing in this attribute. The format of this argument is a list of lists of providers -- `*Info` objects returned by [`provider()`](/versions/8.4.2/rules/lib/globals/bzl#provider) (or in the case of a legacy provider, its string name). The dependency must return ALL providers mentioned in at least ONE of the inner lists. As a convenience, this argument may also be a single-level list of providers, in which case it is wrapped in an outer list with one element. It is NOT required that the rule of the dependency advertises those providers in its `provides` parameter, however, it is considered best practice. |
 | `for_dependency_resolution` | default is `unbound`  If this is set, the attribute is available for materializers. Only rules marked with the flag of the same name are allowed to be referenced through such attributes. |
-| `allow_rules` | [sequence](../core/list) of [string](../core/string)s; or `None`; default is `None`  Which rule targets (name of the classes) are allowed. This is deprecated (kept only for compatibility), use providers instead. |
+| `allow_rules` | [sequence](/versions/8.4.2/rules/lib/core/list) of [string](/versions/8.4.2/rules/lib/core/string)s; or `None`; default is `None`  Which rule targets (name of the classes) are allowed. This is deprecated (kept only for compatibility), use providers instead. |
 | `cfg` | default is `None`  [Configuration](https://bazel.build/versions/8.4.2/extending/rules#configurations) of the attribute. It can be either `"exec"`, which indicates that the dependency is built for the `execution platform`, or `"target"`, which indicates that the dependency is build for the `target platform`. A typical example of the difference is when building mobile apps, where the `target platform` is `Android` or `iOS` while the `execution platform` is `Linux`, `macOS`, or `Windows`. This parameter is required if `executable` is True to guard against accidentally building host tools in the target configuration. `"target"` has no semantic effect, so don't set it when `executable` is False unless it really helps clarify your intentions. |
-| `aspects` | [sequence](../core/list) of [Aspect](../builtins/Aspect)s; default is `[]`  Aspects that should be applied to the dependency or dependencies specified by this attribute. |
-| `flags` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  Deprecated, will be removed. |
+| `aspects` | [sequence](/versions/8.4.2/rules/lib/core/list) of [Aspect](/versions/8.4.2/rules/lib/builtins/Aspect)s; default is `[]`  Aspects that should be applied to the dependency or dependencies specified by this attribute. |
+| `flags` | [sequence](/versions/8.4.2/rules/lib/core/list) of [string](/versions/8.4.2/rules/lib/core/string)s; default is `[]`  Deprecated, will be removed. |
 
 ## label\_keyed\_string\_dict
 
@@ -118,26 +118,26 @@ Attribute attr.label_keyed_string_dict(allow_empty=True, *, configurable=unbound
 
 Creates a schema for an attribute holding a dictionary, where the keys are labels and the values are strings. This is a dependency attribute.
 
-This attribute contains unique [`Label`](../builtins/Label) values. If a string is supplied in place of a `Label`, it will be converted using the [label constructor](../builtins/Label#Label). The relative parts of the label path, including the (possibly renamed) repository, are resolved with respect to the instantiated target's package.
+This attribute contains unique [`Label`](/versions/8.4.2/rules/lib/builtins/Label) values. If a string is supplied in place of a `Label`, it will be converted using the [label constructor](/versions/8.4.2/rules/lib/builtins/Label#Label). The relative parts of the label path, including the (possibly renamed) repository, are resolved with respect to the instantiated target's package.
 
-At analysis time (within the rule's implementation function), when retrieving the attribute value from `ctx.attr`, labels are replaced by the corresponding [`Target`](../builtins/Target)s. This allows you to access the providers of the current target's dependencies.
+At analysis time (within the rule's implementation function), when retrieving the attribute value from `ctx.attr`, labels are replaced by the corresponding [`Target`](/versions/8.4.2/rules/lib/builtins/Target)s. This allows you to access the providers of the current target's dependencies.
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `allow_empty` | [bool](../core/bool); default is `True`  True if the attribute can be empty. |
-| `configurable` | [bool](../core/bool); or unbound; default is `unbound`  This argument can only be specified for an attribute of a symbolic macro. If `configurable` is explicitly set to `False`, the symbolic macro attribute is non-configurable - in other words, it cannot take a `select()` value. If the `configurable` is either unbound or explicitly set to `True`, the attribute is configurable and can take a `select()` value. For an attribute of a rule or aspect, `configurable` must be left unbound. Most Starlark rule attributes are always configurable, with the exception of `attr.output()`, `attr.output_list()`, and `attr.license()` rule attributes, which are always non-configurable. |
-| `default` | [dict](../core/dict); or [function](../core/function); default is `{}`  A default value to use if no value for this attribute is given when instantiating the rule.Use strings or the [`Label`](../builtins/Label#Label) function to specify default values, for example, `attr.label_keyed_string_dict(default = {"//a:b": "value", "//a:c": "string"})`. |
-| `doc` | [string](../core/string); or `None`; default is `None`  A description of the attribute that can be extracted by documentation generating tools. |
-| `allow_files` | [bool](../core/bool); or [sequence](../core/list) of [string](../core/string)s; or `None`; default is `None`  Whether `File` targets are allowed. Can be `True`, `False` (default), or a list of file extensions that are allowed (for example, `[".cc", ".cpp"]`). |
-| `allow_rules` | [sequence](../core/list) of [string](../core/string)s; or `None`; default is `None`  Which rule targets (name of the classes) are allowed. This is deprecated (kept only for compatibility), use providers instead. |
-| `providers` | [sequence](../core/list); default is `[]`  The providers that must be given by any dependency appearing in this attribute. The format of this argument is a list of lists of providers -- `*Info` objects returned by [`provider()`](../globals/bzl#provider) (or in the case of a legacy provider, its string name). The dependency must return ALL providers mentioned in at least ONE of the inner lists. As a convenience, this argument may also be a single-level list of providers, in which case it is wrapped in an outer list with one element. It is NOT required that the rule of the dependency advertises those providers in its `provides` parameter, however, it is considered best practice. |
+| `allow_empty` | [bool](/versions/8.4.2/rules/lib/core/bool); default is `True`  True if the attribute can be empty. |
+| `configurable` | [bool](/versions/8.4.2/rules/lib/core/bool); or unbound; default is `unbound`  This argument can only be specified for an attribute of a symbolic macro. If `configurable` is explicitly set to `False`, the symbolic macro attribute is non-configurable - in other words, it cannot take a `select()` value. If the `configurable` is either unbound or explicitly set to `True`, the attribute is configurable and can take a `select()` value. For an attribute of a rule or aspect, `configurable` must be left unbound. Most Starlark rule attributes are always configurable, with the exception of `attr.output()`, `attr.output_list()`, and `attr.license()` rule attributes, which are always non-configurable. |
+| `default` | [dict](/versions/8.4.2/rules/lib/core/dict); or [function](/versions/8.4.2/rules/lib/core/function); default is `{}`  A default value to use if no value for this attribute is given when instantiating the rule.Use strings or the [`Label`](/versions/8.4.2/rules/lib/builtins/Label#Label) function to specify default values, for example, `attr.label_keyed_string_dict(default = {"//a:b": "value", "//a:c": "string"})`. |
+| `doc` | [string](/versions/8.4.2/rules/lib/core/string); or `None`; default is `None`  A description of the attribute that can be extracted by documentation generating tools. |
+| `allow_files` | [bool](/versions/8.4.2/rules/lib/core/bool); or [sequence](/versions/8.4.2/rules/lib/core/list) of [string](/versions/8.4.2/rules/lib/core/string)s; or `None`; default is `None`  Whether `File` targets are allowed. Can be `True`, `False` (default), or a list of file extensions that are allowed (for example, `[".cc", ".cpp"]`). |
+| `allow_rules` | [sequence](/versions/8.4.2/rules/lib/core/list) of [string](/versions/8.4.2/rules/lib/core/string)s; or `None`; default is `None`  Which rule targets (name of the classes) are allowed. This is deprecated (kept only for compatibility), use providers instead. |
+| `providers` | [sequence](/versions/8.4.2/rules/lib/core/list); default is `[]`  The providers that must be given by any dependency appearing in this attribute. The format of this argument is a list of lists of providers -- `*Info` objects returned by [`provider()`](/versions/8.4.2/rules/lib/globals/bzl#provider) (or in the case of a legacy provider, its string name). The dependency must return ALL providers mentioned in at least ONE of the inner lists. As a convenience, this argument may also be a single-level list of providers, in which case it is wrapped in an outer list with one element. It is NOT required that the rule of the dependency advertises those providers in its `provides` parameter, however, it is considered best practice. |
 | `for_dependency_resolution` | default is `unbound`  If this is set, the attribute is available for materializers. Only rules marked with the flag of the same name are allowed to be referenced through such attributes. |
-| `flags` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  Deprecated, will be removed. |
-| `mandatory` | [bool](../core/bool); default is `False`  If true, the value must be specified explicitly (even if it has a `default`). |
+| `flags` | [sequence](/versions/8.4.2/rules/lib/core/list) of [string](/versions/8.4.2/rules/lib/core/string)s; default is `[]`  Deprecated, will be removed. |
+| `mandatory` | [bool](/versions/8.4.2/rules/lib/core/bool); default is `False`  If true, the value must be specified explicitly (even if it has a `default`). |
 | `cfg` | default is `None`  [Configuration](https://bazel.build/versions/8.4.2/extending/rules#configurations) of the attribute. It can be either `"exec"`, which indicates that the dependency is built for the `execution platform`, or `"target"`, which indicates that the dependency is build for the `target platform`. A typical example of the difference is when building mobile apps, where the `target platform` is `Android` or `iOS` while the `execution platform` is `Linux`, `macOS`, or `Windows`. |
-| `aspects` | [sequence](../core/list) of [Aspect](../builtins/Aspect)s; default is `[]`  Aspects that should be applied to the dependency or dependencies specified by this attribute. |
+| `aspects` | [sequence](/versions/8.4.2/rules/lib/core/list) of [Aspect](/versions/8.4.2/rules/lib/builtins/Aspect)s; default is `[]`  Aspects that should be applied to the dependency or dependencies specified by this attribute. |
 
 ## label\_list
 
@@ -145,30 +145,30 @@ At analysis time (within the rule's implementation function), when retrieving th
 Attribute attr.label_list(allow_empty=True, *, configurable=unbound, default=[], materializer=None, doc=None, allow_files=None, allow_rules=None, providers=[], for_dependency_resolution=unbound, flags=[], mandatory=False, skip_validations=False, cfg=None, aspects=[])
 ```
 
-Creates a schema for a list-of-labels attribute. This is a dependency attribute. The corresponding [`ctx.attr`](../builtins/ctx#attr) attribute will be of type [list](../core/list) of [`Target`s](../builtins/Target).
+Creates a schema for a list-of-labels attribute. This is a dependency attribute. The corresponding [`ctx.attr`](/versions/8.4.2/rules/lib/builtins/ctx#attr) attribute will be of type [list](/versions/8.4.2/rules/lib/core/list) of [`Target`s](/versions/8.4.2/rules/lib/builtins/Target).
 
-This attribute contains unique [`Label`](../builtins/Label) values. If a string is supplied in place of a `Label`, it will be converted using the [label constructor](../builtins/Label#Label). The relative parts of the label path, including the (possibly renamed) repository, are resolved with respect to the instantiated target's package.
+This attribute contains unique [`Label`](/versions/8.4.2/rules/lib/builtins/Label) values. If a string is supplied in place of a `Label`, it will be converted using the [label constructor](/versions/8.4.2/rules/lib/builtins/Label#Label). The relative parts of the label path, including the (possibly renamed) repository, are resolved with respect to the instantiated target's package.
 
-At analysis time (within the rule's implementation function), when retrieving the attribute value from `ctx.attr`, labels are replaced by the corresponding [`Target`](../builtins/Target)s. This allows you to access the providers of the current target's dependencies.
+At analysis time (within the rule's implementation function), when retrieving the attribute value from `ctx.attr`, labels are replaced by the corresponding [`Target`](/versions/8.4.2/rules/lib/builtins/Target)s. This allows you to access the providers of the current target's dependencies.
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `allow_empty` | [bool](../core/bool); default is `True`  True if the attribute can be empty. |
-| `configurable` | [bool](../core/bool); or unbound; default is `unbound`  This argument can only be specified for an attribute of a symbolic macro. If `configurable` is explicitly set to `False`, the symbolic macro attribute is non-configurable - in other words, it cannot take a `select()` value. If the `configurable` is either unbound or explicitly set to `True`, the attribute is configurable and can take a `select()` value. For an attribute of a rule or aspect, `configurable` must be left unbound. Most Starlark rule attributes are always configurable, with the exception of `attr.output()`, `attr.output_list()`, and `attr.license()` rule attributes, which are always non-configurable. |
-| `default` | [sequence](../core/list) of [Label](../builtins/Label)s; or [function](../core/function); default is `[]`  A default value to use if no value for this attribute is given when instantiating the rule.Use strings or the [`Label`](../builtins/Label#Label) function to specify default values, for example, `attr.label_list(default = ["//a:b", "//a:c"])`. |
-| `materializer` | [function](../core/function); default is `None`  **Experimental**. This parameter is experimental and may change at any time. Please do not depend on it. It may be enabled on an experimental basis by setting `--experimental_dormant_deps`  If set, the attribute materializes dormant dependencies from the transitive closure. The value of this parameter must be a functon that gets access to the values of the attributes of the rule that either are not dependencies or are marked as available for dependency resolution. It must return either a dormant dependency or a list of them depending on the type of the attribute |
-| `doc` | [string](../core/string); or `None`; default is `None` |
-| `allow_files` | [bool](../core/bool); or [sequence](../core/list) of [string](../core/string)s; or `None`; default is `None`  Whether `File` targets are allowed. Can be `True`, `False` (default), or a list of file extensions that are allowed (for example, `[".cc", ".cpp"]`). |
-| `allow_rules` | [sequence](../core/list) of [string](../core/string)s; or `None`; default is `None`  Which rule targets (name of the classes) are allowed. This is deprecated (kept only for compatibility), use providers instead. |
-| `providers` | [sequence](../core/list); default is `[]`  The providers that must be given by any dependency appearing in this attribute. The format of this argument is a list of lists of providers -- `*Info` objects returned by [`provider()`](../globals/bzl#provider) (or in the case of a legacy provider, its string name). The dependency must return ALL providers mentioned in at least ONE of the inner lists. As a convenience, this argument may also be a single-level list of providers, in which case it is wrapped in an outer list with one element. It is NOT required that the rule of the dependency advertises those providers in its `provides` parameter, however, it is considered best practice. |
+| `allow_empty` | [bool](/versions/8.4.2/rules/lib/core/bool); default is `True`  True if the attribute can be empty. |
+| `configurable` | [bool](/versions/8.4.2/rules/lib/core/bool); or unbound; default is `unbound`  This argument can only be specified for an attribute of a symbolic macro. If `configurable` is explicitly set to `False`, the symbolic macro attribute is non-configurable - in other words, it cannot take a `select()` value. If the `configurable` is either unbound or explicitly set to `True`, the attribute is configurable and can take a `select()` value. For an attribute of a rule or aspect, `configurable` must be left unbound. Most Starlark rule attributes are always configurable, with the exception of `attr.output()`, `attr.output_list()`, and `attr.license()` rule attributes, which are always non-configurable. |
+| `default` | [sequence](/versions/8.4.2/rules/lib/core/list) of [Label](/versions/8.4.2/rules/lib/builtins/Label)s; or [function](/versions/8.4.2/rules/lib/core/function); default is `[]`  A default value to use if no value for this attribute is given when instantiating the rule.Use strings or the [`Label`](/versions/8.4.2/rules/lib/builtins/Label#Label) function to specify default values, for example, `attr.label_list(default = ["//a:b", "//a:c"])`. |
+| `materializer` | [function](/versions/8.4.2/rules/lib/core/function); default is `None`  **Experimental**. This parameter is experimental and may change at any time. Please do not depend on it. It may be enabled on an experimental basis by setting `--experimental_dormant_deps`  If set, the attribute materializes dormant dependencies from the transitive closure. The value of this parameter must be a functon that gets access to the values of the attributes of the rule that either are not dependencies or are marked as available for dependency resolution. It must return either a dormant dependency or a list of them depending on the type of the attribute |
+| `doc` | [string](/versions/8.4.2/rules/lib/core/string); or `None`; default is `None` |
+| `allow_files` | [bool](/versions/8.4.2/rules/lib/core/bool); or [sequence](/versions/8.4.2/rules/lib/core/list) of [string](/versions/8.4.2/rules/lib/core/string)s; or `None`; default is `None`  Whether `File` targets are allowed. Can be `True`, `False` (default), or a list of file extensions that are allowed (for example, `[".cc", ".cpp"]`). |
+| `allow_rules` | [sequence](/versions/8.4.2/rules/lib/core/list) of [string](/versions/8.4.2/rules/lib/core/string)s; or `None`; default is `None`  Which rule targets (name of the classes) are allowed. This is deprecated (kept only for compatibility), use providers instead. |
+| `providers` | [sequence](/versions/8.4.2/rules/lib/core/list); default is `[]`  The providers that must be given by any dependency appearing in this attribute. The format of this argument is a list of lists of providers -- `*Info` objects returned by [`provider()`](/versions/8.4.2/rules/lib/globals/bzl#provider) (or in the case of a legacy provider, its string name). The dependency must return ALL providers mentioned in at least ONE of the inner lists. As a convenience, this argument may also be a single-level list of providers, in which case it is wrapped in an outer list with one element. It is NOT required that the rule of the dependency advertises those providers in its `provides` parameter, however, it is considered best practice. |
 | `for_dependency_resolution` | default is `unbound`  If this is set, the attribute is available for materializers. Only rules marked with the flag of the same name are allowed to be referenced through such attributes. |
-| `flags` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  Deprecated, will be removed. |
-| `mandatory` | [bool](../core/bool); default is `False`  If true, the value must be specified explicitly (even if it has a `default`). |
-| `skip_validations` | [bool](../core/bool); default is `False`  If true, validation actions of transitive dependencies from this attribute will not run. This is a temporary mitigation and WILL be removed in the future. |
+| `flags` | [sequence](/versions/8.4.2/rules/lib/core/list) of [string](/versions/8.4.2/rules/lib/core/string)s; default is `[]`  Deprecated, will be removed. |
+| `mandatory` | [bool](/versions/8.4.2/rules/lib/core/bool); default is `False`  If true, the value must be specified explicitly (even if it has a `default`). |
+| `skip_validations` | [bool](/versions/8.4.2/rules/lib/core/bool); default is `False`  If true, validation actions of transitive dependencies from this attribute will not run. This is a temporary mitigation and WILL be removed in the future. |
 | `cfg` | default is `None`  [Configuration](https://bazel.build/versions/8.4.2/extending/rules#configurations) of the attribute. It can be either `"exec"`, which indicates that the dependency is built for the `execution platform`, or `"target"`, which indicates that the dependency is build for the `target platform`. A typical example of the difference is when building mobile apps, where the `target platform` is `Android` or `iOS` while the `execution platform` is `Linux`, `macOS`, or `Windows`. |
-| `aspects` | [sequence](../core/list) of [Aspect](../builtins/Aspect)s; default is `[]`  Aspects that should be applied to the dependency or dependencies specified by this attribute. |
+| `aspects` | [sequence](/versions/8.4.2/rules/lib/core/list) of [Aspect](/versions/8.4.2/rules/lib/builtins/Aspect)s; default is `[]`  Aspects that should be applied to the dependency or dependencies specified by this attribute. |
 
 ## output
 
@@ -178,16 +178,16 @@ Attribute attr.output(doc=None, mandatory=False)
 
 Creates a schema for an output (label) attribute.
 
-This attribute contains unique [`Label`](../builtins/Label) values. If a string is supplied in place of a `Label`, it will be converted using the [label constructor](../builtins/Label#Label). The relative parts of the label path, including the (possibly renamed) repository, are resolved with respect to the instantiated target's package.
+This attribute contains unique [`Label`](/versions/8.4.2/rules/lib/builtins/Label) values. If a string is supplied in place of a `Label`, it will be converted using the [label constructor](/versions/8.4.2/rules/lib/builtins/Label#Label). The relative parts of the label path, including the (possibly renamed) repository, are resolved with respect to the instantiated target's package.
 
-At analysis time, the corresponding [`File`](../builtins/File) can be retrieved using [`ctx.outputs`](../builtins/ctx#outputs).
+At analysis time, the corresponding [`File`](/versions/8.4.2/rules/lib/builtins/File) can be retrieved using [`ctx.outputs`](/versions/8.4.2/rules/lib/builtins/ctx#outputs).
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `doc` | [string](../core/string); or `None`; default is `None`  A description of the attribute that can be extracted by documentation generating tools. |
-| `mandatory` | [bool](../core/bool); default is `False`  If true, the value must be specified explicitly (even if it has a `default`). |
+| `doc` | [string](/versions/8.4.2/rules/lib/core/string); or `None`; default is `None`  A description of the attribute that can be extracted by documentation generating tools. |
+| `mandatory` | [bool](/versions/8.4.2/rules/lib/core/bool); default is `False`  If true, the value must be specified explicitly (even if it has a `default`). |
 
 ## output\_list
 
@@ -197,17 +197,17 @@ Attribute attr.output_list(allow_empty=True, *, doc=None, mandatory=False)
 
 Creates a schema for a list-of-outputs attribute.
 
-This attribute contains unique [`Label`](../builtins/Label) values. If a string is supplied in place of a `Label`, it will be converted using the [label constructor](../builtins/Label#Label). The relative parts of the label path, including the (possibly renamed) repository, are resolved with respect to the instantiated target's package.
+This attribute contains unique [`Label`](/versions/8.4.2/rules/lib/builtins/Label) values. If a string is supplied in place of a `Label`, it will be converted using the [label constructor](/versions/8.4.2/rules/lib/builtins/Label#Label). The relative parts of the label path, including the (possibly renamed) repository, are resolved with respect to the instantiated target's package.
 
-At analysis time, the corresponding [`File`](../builtins/File) can be retrieved using [`ctx.outputs`](../builtins/ctx#outputs).
+At analysis time, the corresponding [`File`](/versions/8.4.2/rules/lib/builtins/File) can be retrieved using [`ctx.outputs`](/versions/8.4.2/rules/lib/builtins/ctx#outputs).
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `allow_empty` | [bool](../core/bool); default is `True`  True if the attribute can be empty. |
-| `doc` | [string](../core/string); or `None`; default is `None`  A description of the attribute that can be extracted by documentation generating tools. |
-| `mandatory` | [bool](../core/bool); default is `False`  If true, the value must be specified explicitly (even if it has a `default`). |
+| `allow_empty` | [bool](/versions/8.4.2/rules/lib/core/bool); default is `True`  True if the attribute can be empty. |
+| `doc` | [string](/versions/8.4.2/rules/lib/core/string); or `None`; default is `None`  A description of the attribute that can be extracted by documentation generating tools. |
+| `mandatory` | [bool](/versions/8.4.2/rules/lib/core/bool); default is `False`  If true, the value must be specified explicitly (even if it has a `default`). |
 
 ## string
 
@@ -215,17 +215,17 @@ At analysis time, the corresponding [`File`](../builtins/File) can be retrieved
 Attribute attr.string(configurable=unbound, default='', doc=None, mandatory=False, values=[])
 ```
 
-Creates a schema for a [string](../core/string#attr) attribute.
+Creates a schema for a [string](/versions/8.4.2/rules/lib/core/string#attr) attribute.
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `configurable` | [bool](../core/bool); or unbound; default is `unbound`  This argument can only be specified for an attribute of a symbolic macro. If `configurable` is explicitly set to `False`, the symbolic macro attribute is non-configurable - in other words, it cannot take a `select()` value. If the `configurable` is either unbound or explicitly set to `True`, the attribute is configurable and can take a `select()` value. For an attribute of a rule or aspect, `configurable` must be left unbound. Most Starlark rule attributes are always configurable, with the exception of `attr.output()`, `attr.output_list()`, and `attr.license()` rule attributes, which are always non-configurable. |
-| `default` | [string](../core/string); or NativeComputedDefault; default is `''`  A default value to use if no value for this attribute is given when instantiating the rule. |
-| `doc` | [string](../core/string); or `None`; default is `None`  A description of the attribute that can be extracted by documentation generating tools. |
-| `mandatory` | [bool](../core/bool); default is `False`  If true, the value must be specified explicitly (even if it has a `default`). |
-| `values` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  The list of allowed values for the attribute. An error is raised if any other value is given. |
+| `configurable` | [bool](/versions/8.4.2/rules/lib/core/bool); or unbound; default is `unbound`  This argument can only be specified for an attribute of a symbolic macro. If `configurable` is explicitly set to `False`, the symbolic macro attribute is non-configurable - in other words, it cannot take a `select()` value. If the `configurable` is either unbound or explicitly set to `True`, the attribute is configurable and can take a `select()` value. For an attribute of a rule or aspect, `configurable` must be left unbound. Most Starlark rule attributes are always configurable, with the exception of `attr.output()`, `attr.output_list()`, and `attr.license()` rule attributes, which are always non-configurable. |
+| `default` | [string](/versions/8.4.2/rules/lib/core/string); or NativeComputedDefault; default is `''`  A default value to use if no value for this attribute is given when instantiating the rule. |
+| `doc` | [string](/versions/8.4.2/rules/lib/core/string); or `None`; default is `None`  A description of the attribute that can be extracted by documentation generating tools. |
+| `mandatory` | [bool](/versions/8.4.2/rules/lib/core/bool); default is `False`  If true, the value must be specified explicitly (even if it has a `default`). |
+| `values` | [sequence](/versions/8.4.2/rules/lib/core/list) of [string](/versions/8.4.2/rules/lib/core/string)s; default is `[]`  The list of allowed values for the attribute. An error is raised if any other value is given. |
 
 ## string\_dict
 
@@ -239,11 +239,11 @@ Creates a schema for an attribute holding a dictionary, where the keys and value
 
 | Parameter | Description |
 | --- | --- |
-| `allow_empty` | [bool](../core/bool); default is `True`  True if the attribute can be empty. |
-| `configurable` | [bool](../core/bool); or unbound; default is `unbound`  This argument can only be specified for an attribute of a symbolic macro. If `configurable` is explicitly set to `False`, the symbolic macro attribute is non-configurable - in other words, it cannot take a `select()` value. If the `configurable` is either unbound or explicitly set to `True`, the attribute is configurable and can take a `select()` value. For an attribute of a rule or aspect, `configurable` must be left unbound. Most Starlark rule attributes are always configurable, with the exception of `attr.output()`, `attr.output_list()`, and `attr.license()` rule attributes, which are always non-configurable. |
-| `default` | [dict](../core/dict); default is `{}`  A default value to use if no value for this attribute is given when instantiating the rule. |
-| `doc` | [string](../core/string); or `None`; default is `None`  A description of the attribute that can be extracted by documentation generating tools. |
-| `mandatory` | [bool](../core/bool); default is `False`  If true, the value must be specified explicitly (even if it has a `default`). |
+| `allow_empty` | [bool](/versions/8.4.2/rules/lib/core/bool); default is `True`  True if the attribute can be empty. |
+| `configurable` | [bool](/versions/8.4.2/rules/lib/core/bool); or unbound; default is `unbound`  This argument can only be specified for an attribute of a symbolic macro. If `configurable` is explicitly set to `False`, the symbolic macro attribute is non-configurable - in other words, it cannot take a `select()` value. If the `configurable` is either unbound or explicitly set to `True`, the attribute is configurable and can take a `select()` value. For an attribute of a rule or aspect, `configurable` must be left unbound. Most Starlark rule attributes are always configurable, with the exception of `attr.output()`, `attr.output_list()`, and `attr.license()` rule attributes, which are always non-configurable. |
+| `default` | [dict](/versions/8.4.2/rules/lib/core/dict); default is `{}`  A default value to use if no value for this attribute is given when instantiating the rule. |
+| `doc` | [string](/versions/8.4.2/rules/lib/core/string); or `None`; default is `None`  A description of the attribute that can be extracted by documentation generating tools. |
+| `mandatory` | [bool](/versions/8.4.2/rules/lib/core/bool); default is `False`  If true, the value must be specified explicitly (even if it has a `default`). |
 
 ## string\_keyed\_label\_dict
 
@@ -253,26 +253,26 @@ Attribute attr.string_keyed_label_dict(allow_empty=True, *, configurable=unbound
 
 Creates a schema for an attribute whose value is a dictionary where the keys are strings and the values are labels. This is a dependency attribute.
 
-This attribute contains unique [`Label`](../builtins/Label) values. If a string is supplied in place of a `Label`, it will be converted using the [label constructor](../builtins/Label#Label). The relative parts of the label path, including the (possibly renamed) repository, are resolved with respect to the instantiated target's package.
+This attribute contains unique [`Label`](/versions/8.4.2/rules/lib/builtins/Label) values. If a string is supplied in place of a `Label`, it will be converted using the [label constructor](/versions/8.4.2/rules/lib/builtins/Label#Label). The relative parts of the label path, including the (possibly renamed) repository, are resolved with respect to the instantiated target's package.
 
-At analysis time (within the rule's implementation function), when retrieving the attribute value from `ctx.attr`, labels are replaced by the corresponding [`Target`](../builtins/Target)s. This allows you to access the providers of the current target's dependencies.
+At analysis time (within the rule's implementation function), when retrieving the attribute value from `ctx.attr`, labels are replaced by the corresponding [`Target`](/versions/8.4.2/rules/lib/builtins/Target)s. This allows you to access the providers of the current target's dependencies.
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `allow_empty` | [bool](../core/bool); default is `True`  True if the attribute can be empty. |
-| `configurable` | [bool](../core/bool); or unbound; default is `unbound`  This argument can only be specified for an attribute of a symbolic macro. If `configurable` is explicitly set to `False`, the symbolic macro attribute is non-configurable - in other words, it cannot take a `select()` value. If the `configurable` is either unbound or explicitly set to `True`, the attribute is configurable and can take a `select()` value. For an attribute of a rule or aspect, `configurable` must be left unbound. Most Starlark rule attributes are always configurable, with the exception of `attr.output()`, `attr.output_list()`, and `attr.license()` rule attributes, which are always non-configurable. |
-| `default` | [dict](../core/dict); or [function](../core/function); default is `{}`  A default value to use if no value for this attribute is given when instantiating the rule.Use strings or the [`Label`](../builtins/Label#Label) function to specify default values, for example, `attr.string_keyed_label_dict(default = {"foo": "//a:b", "bar": "//a:c"})`. |
-| `doc` | [string](../core/string); or `None`; default is `None`  A description of the attribute that can be extracted by documentation generating tools. |
-| `allow_files` | [bool](../core/bool); or [sequence](../core/list) of [string](../core/string)s; or `None`; default is `None`  Whether `File` targets are allowed. Can be `True`, `False` (default), or a list of file extensions that are allowed (for example, `[".cc", ".cpp"]`). |
-| `allow_rules` | [sequence](../core/list) of [string](../core/string)s; or `None`; default is `None`  Which rule targets (name of the classes) are allowed. This is deprecated (kept only for compatibility), use providers instead. |
-| `providers` | [sequence](../core/list); default is `[]`  The providers that must be given by any dependency appearing in this attribute. The format of this argument is a list of lists of providers -- `*Info` objects returned by [`provider()`](../globals/bzl#provider) (or in the case of a legacy provider, its string name). The dependency must return ALL providers mentioned in at least ONE of the inner lists. As a convenience, this argument may also be a single-level list of providers, in which case it is wrapped in an outer list with one element. It is NOT required that the rule of the dependency advertises those providers in its `provides` parameter, however, it is considered best practice. |
+| `allow_empty` | [bool](/versions/8.4.2/rules/lib/core/bool); default is `True`  True if the attribute can be empty. |
+| `configurable` | [bool](/versions/8.4.2/rules/lib/core/bool); or unbound; default is `unbound`  This argument can only be specified for an attribute of a symbolic macro. If `configurable` is explicitly set to `False`, the symbolic macro attribute is non-configurable - in other words, it cannot take a `select()` value. If the `configurable` is either unbound or explicitly set to `True`, the attribute is configurable and can take a `select()` value. For an attribute of a rule or aspect, `configurable` must be left unbound. Most Starlark rule attributes are always configurable, with the exception of `attr.output()`, `attr.output_list()`, and `attr.license()` rule attributes, which are always non-configurable. |
+| `default` | [dict](/versions/8.4.2/rules/lib/core/dict); or [function](/versions/8.4.2/rules/lib/core/function); default is `{}`  A default value to use if no value for this attribute is given when instantiating the rule.Use strings or the [`Label`](/versions/8.4.2/rules/lib/builtins/Label#Label) function to specify default values, for example, `attr.string_keyed_label_dict(default = {"foo": "//a:b", "bar": "//a:c"})`. |
+| `doc` | [string](/versions/8.4.2/rules/lib/core/string); or `None`; default is `None`  A description of the attribute that can be extracted by documentation generating tools. |
+| `allow_files` | [bool](/versions/8.4.2/rules/lib/core/bool); or [sequence](/versions/8.4.2/rules/lib/core/list) of [string](/versions/8.4.2/rules/lib/core/string)s; or `None`; default is `None`  Whether `File` targets are allowed. Can be `True`, `False` (default), or a list of file extensions that are allowed (for example, `[".cc", ".cpp"]`). |
+| `allow_rules` | [sequence](/versions/8.4.2/rules/lib/core/list) of [string](/versions/8.4.2/rules/lib/core/string)s; or `None`; default is `None`  Which rule targets (name of the classes) are allowed. This is deprecated (kept only for compatibility), use providers instead. |
+| `providers` | [sequence](/versions/8.4.2/rules/lib/core/list); default is `[]`  The providers that must be given by any dependency appearing in this attribute. The format of this argument is a list of lists of providers -- `*Info` objects returned by [`provider()`](/versions/8.4.2/rules/lib/globals/bzl#provider) (or in the case of a legacy provider, its string name). The dependency must return ALL providers mentioned in at least ONE of the inner lists. As a convenience, this argument may also be a single-level list of providers, in which case it is wrapped in an outer list with one element. It is NOT required that the rule of the dependency advertises those providers in its `provides` parameter, however, it is considered best practice. |
 | `for_dependency_resolution` | default is `unbound`  If this is set, the attribute is available for materializers. Only rules marked with the flag of the same name are allowed to be referenced through such attributes. |
-| `flags` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  Deprecated, will be removed. |
-| `mandatory` | [bool](../core/bool); default is `False`  If true, the value must be specified explicitly (even if it has a `default`). |
+| `flags` | [sequence](/versions/8.4.2/rules/lib/core/list) of [string](/versions/8.4.2/rules/lib/core/string)s; default is `[]`  Deprecated, will be removed. |
+| `mandatory` | [bool](/versions/8.4.2/rules/lib/core/bool); default is `False`  If true, the value must be specified explicitly (even if it has a `default`). |
 | `cfg` | default is `None`  [Configuration](https://bazel.build/versions/8.4.2/extending/rules#configurations) of the attribute. It can be either `"exec"`, which indicates that the dependency is built for the `execution platform`, or `"target"`, which indicates that the dependency is build for the `target platform`. A typical example of the difference is when building mobile apps, where the `target platform` is `Android` or `iOS` while the `execution platform` is `Linux`, `macOS`, or `Windows`. |
-| `aspects` | [sequence](../core/list) of [Aspect](../builtins/Aspect)s; default is `[]`  Aspects that should be applied to the dependency or dependencies specified by this attribute. |
+| `aspects` | [sequence](/versions/8.4.2/rules/lib/core/list) of [Aspect](/versions/8.4.2/rules/lib/builtins/Aspect)s; default is `[]`  Aspects that should be applied to the dependency or dependencies specified by this attribute. |
 
 ## string\_list
 
@@ -286,11 +286,11 @@ Creates a schema for a list-of-strings attribute.
 
 | Parameter | Description |
 | --- | --- |
-| `mandatory` | [bool](../core/bool); default is `False`  If true, the value must be specified explicitly (even if it has a `default`). |
-| `allow_empty` | [bool](../core/bool); default is `True`  True if the attribute can be empty. |
-| `configurable` | [bool](../core/bool); or unbound; default is `unbound`  This argument can only be specified for an attribute of a symbolic macro. If `configurable` is explicitly set to `False`, the symbolic macro attribute is non-configurable - in other words, it cannot take a `select()` value. If the `configurable` is either unbound or explicitly set to `True`, the attribute is configurable and can take a `select()` value. For an attribute of a rule or aspect, `configurable` must be left unbound. Most Starlark rule attributes are always configurable, with the exception of `attr.output()`, `attr.output_list()`, and `attr.license()` rule attributes, which are always non-configurable. |
-| `default` | [sequence](../core/list) of [string](../core/string)s; or NativeComputedDefault; default is `[]`  A default value to use if no value for this attribute is given when instantiating the rule. |
-| `doc` | [string](../core/string); or `None`; default is `None`  A description of the attribute that can be extracted by documentation generating tools. |
+| `mandatory` | [bool](/versions/8.4.2/rules/lib/core/bool); default is `False`  If true, the value must be specified explicitly (even if it has a `default`). |
+| `allow_empty` | [bool](/versions/8.4.2/rules/lib/core/bool); default is `True`  True if the attribute can be empty. |
+| `configurable` | [bool](/versions/8.4.2/rules/lib/core/bool); or unbound; default is `unbound`  This argument can only be specified for an attribute of a symbolic macro. If `configurable` is explicitly set to `False`, the symbolic macro attribute is non-configurable - in other words, it cannot take a `select()` value. If the `configurable` is either unbound or explicitly set to `True`, the attribute is configurable and can take a `select()` value. For an attribute of a rule or aspect, `configurable` must be left unbound. Most Starlark rule attributes are always configurable, with the exception of `attr.output()`, `attr.output_list()`, and `attr.license()` rule attributes, which are always non-configurable. |
+| `default` | [sequence](/versions/8.4.2/rules/lib/core/list) of [string](/versions/8.4.2/rules/lib/core/string)s; or NativeComputedDefault; default is `[]`  A default value to use if no value for this attribute is given when instantiating the rule. |
+| `doc` | [string](/versions/8.4.2/rules/lib/core/string); or `None`; default is `None`  A description of the attribute that can be extracted by documentation generating tools. |
 
 ## string\_list\_dict
 
@@ -304,8 +304,8 @@ Creates a schema for an attribute holding a dictionary, where the keys are strin
 
 | Parameter | Description |
 | --- | --- |
-| `allow_empty` | [bool](../core/bool); default is `True`  True if the attribute can be empty. |
-| `configurable` | [bool](../core/bool); or unbound; default is `unbound`  This argument can only be specified for an attribute of a symbolic macro. If `configurable` is explicitly set to `False`, the symbolic macro attribute is non-configurable - in other words, it cannot take a `select()` value. If the `configurable` is either unbound or explicitly set to `True`, the attribute is configurable and can take a `select()` value. For an attribute of a rule or aspect, `configurable` must be left unbound. Most Starlark rule attributes are always configurable, with the exception of `attr.output()`, `attr.output_list()`, and `attr.license()` rule attributes, which are always non-configurable. |
-| `default` | [dict](../core/dict); default is `{}`  A default value to use if no value for this attribute is given when instantiating the rule. |
-| `doc` | [string](../core/string); or `None`; default is `None`  A description of the attribute that can be extracted by documentation generating tools. |
-| `mandatory` | [bool](../core/bool); default is `False`  If true, the value must be specified explicitly (even if it has a `default`). |
\ No newline at end of file
+| `allow_empty` | [bool](/versions/8.4.2/rules/lib/core/bool); default is `True`  True if the attribute can be empty. |
+| `configurable` | [bool](/versions/8.4.2/rules/lib/core/bool); or unbound; default is `unbound`  This argument can only be specified for an attribute of a symbolic macro. If `configurable` is explicitly set to `False`, the symbolic macro attribute is non-configurable - in other words, it cannot take a `select()` value. If the `configurable` is either unbound or explicitly set to `True`, the attribute is configurable and can take a `select()` value. For an attribute of a rule or aspect, `configurable` must be left unbound. Most Starlark rule attributes are always configurable, with the exception of `attr.output()`, `attr.output_list()`, and `attr.license()` rule attributes, which are always non-configurable. |
+| `default` | [dict](/versions/8.4.2/rules/lib/core/dict); default is `{}`  A default value to use if no value for this attribute is given when instantiating the rule. |
+| `doc` | [string](/versions/8.4.2/rules/lib/core/string); or `None`; default is `None`  A description of the attribute that can be extracted by documentation generating tools. |
+| `mandatory` | [bool](/versions/8.4.2/rules/lib/core/bool); default is `False`  If true, the value must be specified explicitly (even if it has a `default`). |
\ No newline at end of file
diff --git a/versions/8.4.2/rules/lib/toplevel/cc_common.mdx b/versions/8.4.2/rules/lib/toplevel/cc_common.mdx
index cb3f3d24..5e3c3d6d 100644
--- a/versions/8.4.2/rules/lib/toplevel/cc_common.mdx
+++ b/versions/8.4.2/rules/lib/toplevel/cc_common.mdx
@@ -42,8 +42,8 @@ Returns True if given action\_config is enabled in the feature configuration.
 
 | Parameter | Description |
 | --- | --- |
-| `feature_configuration` | [FeatureConfiguration](../builtins/FeatureConfiguration); required  Feature configuration to be queried. |
-| `action_name` | [string](../core/string); required  Name of the action\_config. |
+| `feature_configuration` | [FeatureConfiguration](/versions/8.4.2/rules/lib/builtins/FeatureConfiguration); required  Feature configuration to be queried. |
+| `action_name` | [string](/versions/8.4.2/rules/lib/core/string); required  Name of the action\_config. |
 
 ## CcToolchainInfo
 
@@ -65,29 +65,29 @@ Should be used for C++ compilation. Returns tuple of (`CompilationContext`, `CcC
 
 | Parameter | Description |
 | --- | --- |
-| `actions` | [actions](../builtins/actions); required  `actions` object. |
-| `feature_configuration` | [FeatureConfiguration](../builtins/FeatureConfiguration); required  `feature_configuration` to be queried. |
+| `actions` | [actions](/versions/8.4.2/rules/lib/builtins/actions); required  `actions` object. |
+| `feature_configuration` | [FeatureConfiguration](/versions/8.4.2/rules/lib/builtins/FeatureConfiguration); required  `feature_configuration` to be queried. |
 | `cc_toolchain` | Info; required  `CcToolchainInfo` provider to be used. |
-| `srcs` | [sequence](../core/list); default is `[]`  The list of source files to be compiled. |
-| `public_hdrs` | [sequence](../core/list); default is `[]`  List of headers needed for compilation of srcs and may be included by dependent rules transitively. |
-| `private_hdrs` | [sequence](../core/list); default is `[]`  List of headers needed for compilation of srcs and NOT to be included by dependent rules. |
-| `includes` | [sequence](../core/list); or [depset](../builtins/depset); default is `[]`  Search paths for header files referenced both by angle bracket and quotes. Usually passed with -I. Propagated to dependents transitively. |
-| `quote_includes` | [sequence](../core/list); default is `[]`  Search paths for header files referenced by quotes, e.g. #include "foo/bar/header.h". They can be either relative to the exec root or absolute. Usually passed with -iquote. Propagated to dependents transitively. |
-| `system_includes` | [sequence](../core/list); default is `[]`  Search paths for header files referenced by angle brackets, e.g. #include <foo/bar/header.h>. They can be either relative to the exec root or absolute. Usually passed with -isystem. Propagated to dependents transitively. |
-| `framework_includes` | [sequence](../core/list); default is `[]`  Search paths for header files from Apple frameworks. They can be either relative to the exec root or absolute. Usually passed with -F. Propagated to dependents transitively. |
-| `defines` | [sequence](../core/list); default is `[]`  Set of defines needed to compile this target. Each define is a string. Propagated to dependents transitively. |
-| `local_defines` | [sequence](../core/list); default is `[]`  Set of defines needed to compile this target. Each define is a string. Not propagated to dependents transitively. |
-| `include_prefix` | [string](../core/string); default is `''`  The prefix to add to the paths of the headers of this rule. When set, the headers in the hdrs attribute of this rule are accessible at is the value of this attribute prepended to their repository-relative path. The prefix in the strip\_include\_prefix attribute is removed before this prefix is added. |
-| `strip_include_prefix` | [string](../core/string); default is `''`  The prefix to strip from the paths of the headers of this rule. When set, the headers in the hdrs attribute of this rule are accessible at their path with this prefix cut off. If it's a relative path, it's taken as a package-relative one. If it's an absolute one, it's understood as a repository-relative path. The prefix in the include\_prefix attribute is added after this prefix is stripped. |
-| `user_compile_flags` | [sequence](../core/list); default is `[]`  Additional list of compilation options. |
-| `conly_flags` | [sequence](../core/list); default is `[]`  Additional list of compilation options for C compiles. |
-| `cxx_flags` | [sequence](../core/list); default is `[]`  Additional list of compilation options for C++ compiles. |
-| `compilation_contexts` | [sequence](../core/list); default is `[]`  Headers from dependencies used for compilation. |
-| `name` | [string](../core/string); required  This is used for naming the output artifacts of actions created by this method. See also the `main\_output` arg. |
-| `disallow_pic_outputs` | [bool](../core/bool); default is `False`  Whether PIC outputs should be created. |
-| `disallow_nopic_outputs` | [bool](../core/bool); default is `False`  Whether NOPIC outputs should be created. |
-| `additional_inputs` | [sequence](../core/list); default is `[]`  List of additional files needed for compilation of srcs |
-| `module_interfaces` | [sequence](../core/list); default is `unbound`  The list of module interfaces source files to be compiled. Note: this is an experimental feature, only enabled with --experimental\_cpp\_modules |
+| `srcs` | [sequence](/versions/8.4.2/rules/lib/core/list); default is `[]`  The list of source files to be compiled. |
+| `public_hdrs` | [sequence](/versions/8.4.2/rules/lib/core/list); default is `[]`  List of headers needed for compilation of srcs and may be included by dependent rules transitively. |
+| `private_hdrs` | [sequence](/versions/8.4.2/rules/lib/core/list); default is `[]`  List of headers needed for compilation of srcs and NOT to be included by dependent rules. |
+| `includes` | [sequence](/versions/8.4.2/rules/lib/core/list); or [depset](/versions/8.4.2/rules/lib/builtins/depset); default is `[]`  Search paths for header files referenced both by angle bracket and quotes. Usually passed with -I. Propagated to dependents transitively. |
+| `quote_includes` | [sequence](/versions/8.4.2/rules/lib/core/list); default is `[]`  Search paths for header files referenced by quotes, e.g. #include "foo/bar/header.h". They can be either relative to the exec root or absolute. Usually passed with -iquote. Propagated to dependents transitively. |
+| `system_includes` | [sequence](/versions/8.4.2/rules/lib/core/list); default is `[]`  Search paths for header files referenced by angle brackets, e.g. #include <foo/bar/header.h>. They can be either relative to the exec root or absolute. Usually passed with -isystem. Propagated to dependents transitively. |
+| `framework_includes` | [sequence](/versions/8.4.2/rules/lib/core/list); default is `[]`  Search paths for header files from Apple frameworks. They can be either relative to the exec root or absolute. Usually passed with -F. Propagated to dependents transitively. |
+| `defines` | [sequence](/versions/8.4.2/rules/lib/core/list); default is `[]`  Set of defines needed to compile this target. Each define is a string. Propagated to dependents transitively. |
+| `local_defines` | [sequence](/versions/8.4.2/rules/lib/core/list); default is `[]`  Set of defines needed to compile this target. Each define is a string. Not propagated to dependents transitively. |
+| `include_prefix` | [string](/versions/8.4.2/rules/lib/core/string); default is `''`  The prefix to add to the paths of the headers of this rule. When set, the headers in the hdrs attribute of this rule are accessible at is the value of this attribute prepended to their repository-relative path. The prefix in the strip\_include\_prefix attribute is removed before this prefix is added. |
+| `strip_include_prefix` | [string](/versions/8.4.2/rules/lib/core/string); default is `''`  The prefix to strip from the paths of the headers of this rule. When set, the headers in the hdrs attribute of this rule are accessible at their path with this prefix cut off. If it's a relative path, it's taken as a package-relative one. If it's an absolute one, it's understood as a repository-relative path. The prefix in the include\_prefix attribute is added after this prefix is stripped. |
+| `user_compile_flags` | [sequence](/versions/8.4.2/rules/lib/core/list); default is `[]`  Additional list of compilation options. |
+| `conly_flags` | [sequence](/versions/8.4.2/rules/lib/core/list); default is `[]`  Additional list of compilation options for C compiles. |
+| `cxx_flags` | [sequence](/versions/8.4.2/rules/lib/core/list); default is `[]`  Additional list of compilation options for C++ compiles. |
+| `compilation_contexts` | [sequence](/versions/8.4.2/rules/lib/core/list); default is `[]`  Headers from dependencies used for compilation. |
+| `name` | [string](/versions/8.4.2/rules/lib/core/string); required  This is used for naming the output artifacts of actions created by this method. See also the `main\_output` arg. |
+| `disallow_pic_outputs` | [bool](/versions/8.4.2/rules/lib/core/bool); default is `False`  Whether PIC outputs should be created. |
+| `disallow_nopic_outputs` | [bool](/versions/8.4.2/rules/lib/core/bool); default is `False`  Whether NOPIC outputs should be created. |
+| `additional_inputs` | [sequence](/versions/8.4.2/rules/lib/core/list); default is `[]`  List of additional files needed for compilation of srcs |
+| `module_interfaces` | [sequence](/versions/8.4.2/rules/lib/core/list); default is `unbound`  The list of module interfaces source files to be compiled. Note: this is an experimental feature, only enabled with --experimental\_cpp\_modules |
 
 ## configure\_features
 
@@ -101,11 +101,11 @@ Creates a feature\_configuration instance. Requires the cpp configuration fragme
 
 | Parameter | Description |
 | --- | --- |
-| `ctx` | [ctx](../builtins/ctx); or `None`; default is `None`  The rule context. |
+| `ctx` | [ctx](/versions/8.4.2/rules/lib/builtins/ctx); or `None`; default is `None`  The rule context. |
 | `cc_toolchain` | Info; required  cc\_toolchain for which we configure features. |
-| `language` | [string](../core/string); or `None`; default is `None`  The language to configure for: either c++ or objc (default c++) |
-| `requested_features` | [sequence](../core/list); default is `[]`  List of features to be enabled. |
-| `unsupported_features` | [sequence](../core/list); default is `[]`  List of features that are unsupported by the current rule. |
+| `language` | [string](/versions/8.4.2/rules/lib/core/string); or `None`; default is `None`  The language to configure for: either c++ or objc (default c++) |
+| `requested_features` | [sequence](/versions/8.4.2/rules/lib/core/list); default is `[]`  List of features to be enabled. |
+| `unsupported_features` | [sequence](/versions/8.4.2/rules/lib/core/list); default is `[]`  List of features that are unsupported by the current rule. |
 
 ## create\_cc\_toolchain\_config\_info
 
@@ -119,22 +119,22 @@ Creates a `CcToolchainConfigInfo` provider
 
 | Parameter | Description |
 | --- | --- |
-| `ctx` | [ctx](../builtins/ctx); required  The rule context. |
-| `features` | [sequence](../core/list); default is `[]`  Contains all flag specifications for one feature. Arguments:  `name`: The feature's name. It is possible to introduce a feature without a change to Bazel by adding a 'feature' section to the toolchain and adding the corresponding string as feature in the `BUILD` file.  `enabled`: If 'True', this feature is enabled unless a rule type explicitly marks it as unsupported.  `flag_sets`: A FlagSet list. If the given feature is enabled, the flag sets will be applied for the actions are specified for.  `env_sets`: an EnvSet list. If the given feature is enabled, the env sets will be applied for the actions they are specified for.  `requires`: A list of feature sets defining when this feature is supported by the toolchain. The feature is supported if any of the feature sets fully apply, that is, when all features of a feature set are enabled. If `requires` is omitted, the feature is supported independently of which other features are enabled. Use this for example to filter flags depending on the build mode enabled (opt / fastbuild / dbg).  `implies`: A string list of features or action configs that are automatically enabled when this feature is enabled. If any of the implied features or action configs cannot be enabled, this feature will (silently) not be enabled either.  `provides`: A list of names this feature conflicts with. A feature cannot be enabled if:- `provides` contains the name of a different feature or action config that we want to enable.- `provides` contains the same value as a 'provides' in a different feature or action config that we want to enable. Use this in order to ensure that incompatible features cannot be accidentally activated at the same time, leading to hard to diagnose compiler errors. |
-| `action_configs` | [sequence](../core/list); default is `[]`  An action config corresponds to a Bazel action, and allows selection of a tool based on activated features. Action config activation occurs by the same semantics as features: a feature can 'require' or 'imply' an action config in the same way that it would another feature. Arguments:  `action_name`: The name of the Bazel action that this config applies to, e.g. 'c-compile' or 'c-module-compile'.  `enabled`: If 'True', this action is enabled unless a rule type explicitly marks it as unsupported.  `tools`: The tool applied to the action will be the first tool with a feature set that matches the feature configuration. An error will be thrown if no tool matches a provided feature configuration - for that reason, it's a good idea to provide a default tool with an empty feature set.  `flag_sets`: If the given action config is enabled, the flag sets will be applied to the corresponding action.  `implies`: A list of features or action configs that are automatically enabled when this action config is enabled. If any of the implied features or action configs cannot be enabled, this action config will (silently) not be enabled either. |
-| `artifact_name_patterns` | [sequence](../core/list); default is `[]`  The name for an artifact of a given category of input or output artifacts to an action. Arguments:  `category_name`: The category of artifacts that this selection applies to. This field is compared against a list of categories defined in Bazel. Example categories include "linked\_output" or the artifact for this selection. Together with the extension it is used to create an artifact name based on the target name.  `extension`: The extension for creating the artifact for this selection. Together with the prefix it is used to create an artifact name based on the target name. |
-| `cxx_builtin_include_directories` | [sequence](../core/list); default is `[]`  Built-in include directories for C++ compilation. These should be the exact paths used by the compiler, and are generally relative to the exec root.  The paths used by the compiler can be determined by 'gcc -E -xc++ - -v'.  We currently use the C++ paths also for C compilation, which is safe as long as there are no name clashes between C++ and C header files.  Relative paths are resolved relative to the configuration file directory.  If the compiler has --sysroot support, then these paths should use %sysroot% rather than the include path, and specify the sysroot attribute in order to give blaze the information necessary to make the correct replacements. |
-| `toolchain_identifier` | [string](../core/string); required  The unique identifier of the toolchain within the crosstool release. It must be possible to use this as a directory name in a path.  It has to match the following regex: [a-zA-Z\_][\.\- \w]\* |
-| `host_system_name` | [string](../core/string); or `None`; default is `None`  Ignored. |
-| `target_system_name` | [string](../core/string); or `None`; default is `None`  Deprecated. The GNU System Name. The string is exposed to CcToolchainInfo.target\_gnu\_system\_name. |
-| `target_cpu` | [string](../core/string); or `None`; default is `None`  Deprecated: Use cpu based constraints instead. If the string is "k8", `target\_cpu` will be omitted from the filename of raw FDO profile data. |
-| `target_libc` | [string](../core/string); or `None`; default is `None`  Deprecated: Use OS based constraints instead. The libc version string (e.g. "glibc-2.2.2"). If the string is "macosx", platform is assumed to be MacOS. Otherwise, Linux. The string is exposed to CcToolchainInfo.libc. |
-| `compiler` | [string](../core/string); required  The compiler string (e.g. "gcc"). The current toolchain's compiler is exposed to `@bazel\_tools//tools/cpp:compiler (compiler\_flag)` as a flag value. Targets that require compiler-specific flags can use the config\_settings in https://github.com/bazelbuild/rules\_cc/blob/main/cc/compiler/BUILD in select() statements or create custom config\_setting if the existing settings don't suffice. |
-| `abi_version` | [string](../core/string); or `None`; default is `None`  The abi in use, which is a gcc version. E.g.: "gcc-3.4". The string is set to C++ toolchain variable ABI. |
-| `abi_libc_version` | [string](../core/string); or `None`; default is `None`  The glibc version used by the abi we're using. The string is set to C++ toolchain variable ABI\_LIBC\_VERSION. |
-| `tool_paths` | [sequence](../core/list); default is `[]`  Tool locations. Arguments:  `name`: Name of the tool.  `path`: Location of the tool; Can be absolute path (in case of non hermetic toolchain), or path relative to the cc\_toolchain's package. |
-| `make_variables` | [sequence](../core/list); default is `[]`  A make variable that is made accessible to rules. |
-| `builtin_sysroot` | [string](../core/string); or `None`; default is `None`  The built-in sysroot. If this attribute is not present, Bazel does not allow using a different sysroot, i.e. through the --grte\_top option. |
+| `ctx` | [ctx](/versions/8.4.2/rules/lib/builtins/ctx); required  The rule context. |
+| `features` | [sequence](/versions/8.4.2/rules/lib/core/list); default is `[]`  Contains all flag specifications for one feature. Arguments:  `name`: The feature's name. It is possible to introduce a feature without a change to Bazel by adding a 'feature' section to the toolchain and adding the corresponding string as feature in the `BUILD` file.  `enabled`: If 'True', this feature is enabled unless a rule type explicitly marks it as unsupported.  `flag_sets`: A FlagSet list. If the given feature is enabled, the flag sets will be applied for the actions are specified for.  `env_sets`: an EnvSet list. If the given feature is enabled, the env sets will be applied for the actions they are specified for.  `requires`: A list of feature sets defining when this feature is supported by the toolchain. The feature is supported if any of the feature sets fully apply, that is, when all features of a feature set are enabled. If `requires` is omitted, the feature is supported independently of which other features are enabled. Use this for example to filter flags depending on the build mode enabled (opt / fastbuild / dbg).  `implies`: A string list of features or action configs that are automatically enabled when this feature is enabled. If any of the implied features or action configs cannot be enabled, this feature will (silently) not be enabled either.  `provides`: A list of names this feature conflicts with. A feature cannot be enabled if:- `provides` contains the name of a different feature or action config that we want to enable.- `provides` contains the same value as a 'provides' in a different feature or action config that we want to enable. Use this in order to ensure that incompatible features cannot be accidentally activated at the same time, leading to hard to diagnose compiler errors. |
+| `action_configs` | [sequence](/versions/8.4.2/rules/lib/core/list); default is `[]`  An action config corresponds to a Bazel action, and allows selection of a tool based on activated features. Action config activation occurs by the same semantics as features: a feature can 'require' or 'imply' an action config in the same way that it would another feature. Arguments:  `action_name`: The name of the Bazel action that this config applies to, e.g. 'c-compile' or 'c-module-compile'.  `enabled`: If 'True', this action is enabled unless a rule type explicitly marks it as unsupported.  `tools`: The tool applied to the action will be the first tool with a feature set that matches the feature configuration. An error will be thrown if no tool matches a provided feature configuration - for that reason, it's a good idea to provide a default tool with an empty feature set.  `flag_sets`: If the given action config is enabled, the flag sets will be applied to the corresponding action.  `implies`: A list of features or action configs that are automatically enabled when this action config is enabled. If any of the implied features or action configs cannot be enabled, this action config will (silently) not be enabled either. |
+| `artifact_name_patterns` | [sequence](/versions/8.4.2/rules/lib/core/list); default is `[]`  The name for an artifact of a given category of input or output artifacts to an action. Arguments:  `category_name`: The category of artifacts that this selection applies to. This field is compared against a list of categories defined in Bazel. Example categories include "linked\_output" or the artifact for this selection. Together with the extension it is used to create an artifact name based on the target name.  `extension`: The extension for creating the artifact for this selection. Together with the prefix it is used to create an artifact name based on the target name. |
+| `cxx_builtin_include_directories` | [sequence](/versions/8.4.2/rules/lib/core/list); default is `[]`  Built-in include directories for C++ compilation. These should be the exact paths used by the compiler, and are generally relative to the exec root.  The paths used by the compiler can be determined by 'gcc -E -xc++ - -v'.  We currently use the C++ paths also for C compilation, which is safe as long as there are no name clashes between C++ and C header files.  Relative paths are resolved relative to the configuration file directory.  If the compiler has --sysroot support, then these paths should use %sysroot% rather than the include path, and specify the sysroot attribute in order to give blaze the information necessary to make the correct replacements. |
+| `toolchain_identifier` | [string](/versions/8.4.2/rules/lib/core/string); required  The unique identifier of the toolchain within the crosstool release. It must be possible to use this as a directory name in a path.  It has to match the following regex: [a-zA-Z\_][\.\- \w]\* |
+| `host_system_name` | [string](/versions/8.4.2/rules/lib/core/string); or `None`; default is `None`  Ignored. |
+| `target_system_name` | [string](/versions/8.4.2/rules/lib/core/string); or `None`; default is `None`  Deprecated. The GNU System Name. The string is exposed to CcToolchainInfo.target\_gnu\_system\_name. |
+| `target_cpu` | [string](/versions/8.4.2/rules/lib/core/string); or `None`; default is `None`  Deprecated: Use cpu based constraints instead. If the string is "k8", `target\_cpu` will be omitted from the filename of raw FDO profile data. |
+| `target_libc` | [string](/versions/8.4.2/rules/lib/core/string); or `None`; default is `None`  Deprecated: Use OS based constraints instead. The libc version string (e.g. "glibc-2.2.2"). If the string is "macosx", platform is assumed to be MacOS. Otherwise, Linux. The string is exposed to CcToolchainInfo.libc. |
+| `compiler` | [string](/versions/8.4.2/rules/lib/core/string); required  The compiler string (e.g. "gcc"). The current toolchain's compiler is exposed to `@bazel\_tools//tools/cpp:compiler (compiler\_flag)` as a flag value. Targets that require compiler-specific flags can use the config\_settings in https://github.com/bazelbuild/rules\_cc/blob/main/cc/compiler/BUILD in select() statements or create custom config\_setting if the existing settings don't suffice. |
+| `abi_version` | [string](/versions/8.4.2/rules/lib/core/string); or `None`; default is `None`  The abi in use, which is a gcc version. E.g.: "gcc-3.4". The string is set to C++ toolchain variable ABI. |
+| `abi_libc_version` | [string](/versions/8.4.2/rules/lib/core/string); or `None`; default is `None`  The glibc version used by the abi we're using. The string is set to C++ toolchain variable ABI\_LIBC\_VERSION. |
+| `tool_paths` | [sequence](/versions/8.4.2/rules/lib/core/list); default is `[]`  Tool locations. Arguments:  `name`: Name of the tool.  `path`: Location of the tool; Can be absolute path (in case of non hermetic toolchain), or path relative to the cc\_toolchain's package. |
+| `make_variables` | [sequence](/versions/8.4.2/rules/lib/core/list); default is `[]`  A make variable that is made accessible to rules. |
+| `builtin_sysroot` | [string](/versions/8.4.2/rules/lib/core/string); or `None`; default is `None`  The built-in sysroot. If this attribute is not present, Bazel does not allow using a different sysroot, i.e. through the --grte\_top option. |
 
 ## create\_compilation\_context
 
@@ -168,8 +168,8 @@ Create compilation outputs object.
 
 | Parameter | Description |
 | --- | --- |
-| `objects` | [depset](../builtins/depset); or `None`; default is `None`  List of object files. |
-| `pic_objects` | [depset](../builtins/depset); or `None`; default is `None`  List of pic object files. |
+| `objects` | [depset](/versions/8.4.2/rules/lib/builtins/depset); or `None`; default is `None`  List of object files. |
+| `pic_objects` | [depset](/versions/8.4.2/rules/lib/builtins/depset); or `None`; default is `None`  List of pic object files. |
 
 ## create\_compile\_variables
 
@@ -184,21 +184,21 @@ Returns variables used for compilation actions.
 | Parameter | Description |
 | --- | --- |
 | `cc_toolchain` | Info; required  cc\_toolchain for which we are creating build variables. |
-| `feature_configuration` | [FeatureConfiguration](../builtins/FeatureConfiguration); required  Feature configuration to be queried. |
+| `feature_configuration` | [FeatureConfiguration](/versions/8.4.2/rules/lib/builtins/FeatureConfiguration); required  Feature configuration to be queried. |
 | `source_file` | default is `None`  Optional source file for the compilation. Please prefer passing source\_file here over appending it to the end of the command line generated from cc\_common.get\_memory\_inefficient\_command\_line, as then it's in the power of the toolchain author to properly specify and position compiler flags. |
 | `output_file` | default is `None`  Optional output file of the compilation. Please prefer passing output\_file here over appending it to the end of the command line generated from cc\_common.get\_memory\_inefficient\_command\_line, as then it's in the power of the toolchain author to properly specify and position compiler flags. |
-| `user_compile_flags` | [sequence](../core/list) of [string](../core/string)s; or `None`; default is `None`  List of additional compilation flags (copts). |
-| `include_directories` | [depset](../builtins/depset); or `None`; default is `None`  Depset of include directories. |
-| `quote_include_directories` | [depset](../builtins/depset); or `None`; default is `None`  Depset of quote include directories. |
-| `system_include_directories` | [depset](../builtins/depset); or `None`; default is `None`  Depset of system include directories. |
-| `framework_include_directories` | [depset](../builtins/depset); or `None`; default is `None`  Depset of framework include directories. |
-| `preprocessor_defines` | [depset](../builtins/depset); or `None`; default is `None`  Depset of preprocessor defines. |
-| `thinlto_index` | [string](../core/string); or `None`; default is `None`  LTO index file path. |
-| `thinlto_input_bitcode_file` | [string](../core/string); or `None`; default is `None`  Bitcode file that is input to LTO backend. |
-| `thinlto_output_object_file` | [string](../core/string); or `None`; default is `None`  Object file that is output by LTO backend. |
-| `use_pic` | [bool](../core/bool); default is `False`  When true the compilation will generate position independent code. |
-| `add_legacy_cxx_options` | [bool](../core/bool); default is `False`  Unused. |
-| `variables_extension` | [dict](../core/dict); default is `unbound`  A dictionary of additional variables used by compile actions. |
+| `user_compile_flags` | [sequence](/versions/8.4.2/rules/lib/core/list) of [string](/versions/8.4.2/rules/lib/core/string)s; or `None`; default is `None`  List of additional compilation flags (copts). |
+| `include_directories` | [depset](/versions/8.4.2/rules/lib/builtins/depset); or `None`; default is `None`  Depset of include directories. |
+| `quote_include_directories` | [depset](/versions/8.4.2/rules/lib/builtins/depset); or `None`; default is `None`  Depset of quote include directories. |
+| `system_include_directories` | [depset](/versions/8.4.2/rules/lib/builtins/depset); or `None`; default is `None`  Depset of system include directories. |
+| `framework_include_directories` | [depset](/versions/8.4.2/rules/lib/builtins/depset); or `None`; default is `None`  Depset of framework include directories. |
+| `preprocessor_defines` | [depset](/versions/8.4.2/rules/lib/builtins/depset); or `None`; default is `None`  Depset of preprocessor defines. |
+| `thinlto_index` | [string](/versions/8.4.2/rules/lib/core/string); or `None`; default is `None`  LTO index file path. |
+| `thinlto_input_bitcode_file` | [string](/versions/8.4.2/rules/lib/core/string); or `None`; default is `None`  Bitcode file that is input to LTO backend. |
+| `thinlto_output_object_file` | [string](/versions/8.4.2/rules/lib/core/string); or `None`; default is `None`  Object file that is output by LTO backend. |
+| `use_pic` | [bool](/versions/8.4.2/rules/lib/core/bool); default is `False`  When true the compilation will generate position independent code. |
+| `add_legacy_cxx_options` | [bool](/versions/8.4.2/rules/lib/core/bool); default is `False`  Unused. |
+| `variables_extension` | [dict](/versions/8.4.2/rules/lib/core/dict); default is `unbound`  A dictionary of additional variables used by compile actions. |
 
 ## create\_library\_to\_link
 
@@ -215,15 +215,15 @@ Creates `LibraryToLink`
 | `actions` | required  `actions` object. |
 | `feature_configuration` | default is `None`  `feature_configuration` to be queried. |
 | `cc_toolchain` | default is `None`  `CcToolchainInfo` provider to be used. |
-| `static_library` | [File](../builtins/File); or `None`; default is `None`  `File` of static library to be linked. |
-| `pic_static_library` | [File](../builtins/File); or `None`; default is `None`  `File` of pic static library to be linked. |
-| `dynamic_library` | [File](../builtins/File); or `None`; default is `None`  `File` of dynamic library to be linked. Always used for runtime and used for linking if `interface_library` is not passed. |
-| `interface_library` | [File](../builtins/File); or `None`; default is `None`  `File` of interface library to be linked. |
-| `pic_objects` | [sequence](../core/list) of [File](../builtins/File)s; default is `unbound`  Experimental, do not use |
-| `objects` | [sequence](../core/list) of [File](../builtins/File)s; default is `unbound`  Experimental, do not use |
-| `alwayslink` | [bool](../core/bool); default is `False`  Whether to link the static library/objects in the --whole\_archive block. |
-| `dynamic_library_symlink_path` | [string](../core/string); default is `''`  Override the default path of the dynamic library link in the solib directory. Empty string to use the default. |
-| `interface_library_symlink_path` | [string](../core/string); default is `''`  Override the default path of the interface library link in the solib directory. Empty string to use the default. |
+| `static_library` | [File](/versions/8.4.2/rules/lib/builtins/File); or `None`; default is `None`  `File` of static library to be linked. |
+| `pic_static_library` | [File](/versions/8.4.2/rules/lib/builtins/File); or `None`; default is `None`  `File` of pic static library to be linked. |
+| `dynamic_library` | [File](/versions/8.4.2/rules/lib/builtins/File); or `None`; default is `None`  `File` of dynamic library to be linked. Always used for runtime and used for linking if `interface_library` is not passed. |
+| `interface_library` | [File](/versions/8.4.2/rules/lib/builtins/File); or `None`; default is `None`  `File` of interface library to be linked. |
+| `pic_objects` | [sequence](/versions/8.4.2/rules/lib/core/list) of [File](/versions/8.4.2/rules/lib/builtins/File)s; default is `unbound`  Experimental, do not use |
+| `objects` | [sequence](/versions/8.4.2/rules/lib/core/list) of [File](/versions/8.4.2/rules/lib/builtins/File)s; default is `unbound`  Experimental, do not use |
+| `alwayslink` | [bool](/versions/8.4.2/rules/lib/core/bool); default is `False`  Whether to link the static library/objects in the --whole\_archive block. |
+| `dynamic_library_symlink_path` | [string](/versions/8.4.2/rules/lib/core/string); default is `''`  Override the default path of the dynamic library link in the solib directory. Empty string to use the default. |
+| `interface_library_symlink_path` | [string](/versions/8.4.2/rules/lib/core/string); default is `''`  Override the default path of the interface library link in the solib directory. Empty string to use the default. |
 
 ## create\_link\_variables
 
@@ -238,17 +238,17 @@ Returns link variables used for linking actions.
 | Parameter | Description |
 | --- | --- |
 | `cc_toolchain` | Info; required  cc\_toolchain for which we are creating build variables. |
-| `feature_configuration` | [FeatureConfiguration](../builtins/FeatureConfiguration); required  Feature configuration to be queried. |
-| `library_search_directories` | [depset](../builtins/depset); default is `[]`  Depset of directories where linker will look for libraries at link time. |
-| `runtime_library_search_directories` | [depset](../builtins/depset); default is `[]`  Depset of directories where loader will look for libraries at runtime. |
-| `user_link_flags` | [sequence](../core/list); default is `[]`  List of additional link flags (linkopts). |
+| `feature_configuration` | [FeatureConfiguration](/versions/8.4.2/rules/lib/builtins/FeatureConfiguration); required  Feature configuration to be queried. |
+| `library_search_directories` | [depset](/versions/8.4.2/rules/lib/builtins/depset); default is `[]`  Depset of directories where linker will look for libraries at link time. |
+| `runtime_library_search_directories` | [depset](/versions/8.4.2/rules/lib/builtins/depset); default is `[]`  Depset of directories where loader will look for libraries at runtime. |
+| `user_link_flags` | [sequence](/versions/8.4.2/rules/lib/core/list); default is `[]`  List of additional link flags (linkopts). |
 | `output_file` | default is `None`  Optional output file path. |
 | `param_file` | default is `None`  Optional param file path. |
-| `is_using_linker` | [bool](../core/bool); default is `True`  True when using linker, False when archiver. Caller is responsible for keeping this in sync with action name used (is\_using\_linker = True for linking executable or dynamic library, is\_using\_linker = False for archiving static library). |
-| `is_linking_dynamic_library` | [bool](../core/bool); default is `False`  True when creating dynamic library, False when executable or static library. Caller is responsible for keeping this in sync with action name used. This field will be removed once b/65151735 is fixed. |
-| `must_keep_debug` | [bool](../core/bool); default is `True`  When set to False, bazel will expose 'strip\_debug\_symbols' variable, which is usually used to use the linker to strip debug symbols from the output file. |
-| `use_test_only_flags` | [bool](../core/bool); default is `False`  When set to true, 'is\_cc\_test' variable will be set. |
-| `is_static_linking_mode` | [bool](../core/bool); default is `True`  Unused. |
+| `is_using_linker` | [bool](/versions/8.4.2/rules/lib/core/bool); default is `True`  True when using linker, False when archiver. Caller is responsible for keeping this in sync with action name used (is\_using\_linker = True for linking executable or dynamic library, is\_using\_linker = False for archiving static library). |
+| `is_linking_dynamic_library` | [bool](/versions/8.4.2/rules/lib/core/bool); default is `False`  True when creating dynamic library, False when executable or static library. Caller is responsible for keeping this in sync with action name used. This field will be removed once b/65151735 is fixed. |
+| `must_keep_debug` | [bool](/versions/8.4.2/rules/lib/core/bool); default is `True`  When set to False, bazel will expose 'strip\_debug\_symbols' variable, which is usually used to use the linker to strip debug symbols from the output file. |
+| `use_test_only_flags` | [bool](/versions/8.4.2/rules/lib/core/bool); default is `False`  When set to true, 'is\_cc\_test' variable will be set. |
+| `is_static_linking_mode` | [bool](/versions/8.4.2/rules/lib/core/bool); default is `True`  Unused. |
 
 ## create\_linker\_input
 
@@ -262,10 +262,10 @@ Creates a `LinkerInput`.
 
 | Parameter | Description |
 | --- | --- |
-| `owner` | [Label](../builtins/Label); required  The label of the target that produced all files used in this input. |
-| `libraries` | `None`; or [depset](../builtins/depset); default is `None`  List of `LibraryToLink`. |
-| `user_link_flags` | `None`; or [depset](../builtins/depset) of [string](../core/string)s; or [sequence](../core/list) of [string](../core/string)s; default is `None`  User link flags passed as strings. Accepts either [String], [[String]] or depset(String). The latter is discouraged as it's only kept for compatibility purposes, the depset is flattened. If you want to propagate user\_link\_flags via unflattened depsets() wrap them in a LinkerInput so that they are not flattened till the end. |
-| `additional_inputs` | `None`; or [depset](../builtins/depset); default is `None`  For additional inputs to the linking action, e.g.: linking scripts. |
+| `owner` | [Label](/versions/8.4.2/rules/lib/builtins/Label); required  The label of the target that produced all files used in this input. |
+| `libraries` | `None`; or [depset](/versions/8.4.2/rules/lib/builtins/depset); default is `None`  List of `LibraryToLink`. |
+| `user_link_flags` | `None`; or [depset](/versions/8.4.2/rules/lib/builtins/depset) of [string](/versions/8.4.2/rules/lib/core/string)s; or [sequence](/versions/8.4.2/rules/lib/core/list) of [string](/versions/8.4.2/rules/lib/core/string)s; default is `None`  User link flags passed as strings. Accepts either [String], [[String]] or depset(String). The latter is discouraged as it's only kept for compatibility purposes, the depset is flattened. If you want to propagate user\_link\_flags via unflattened depsets() wrap them in a LinkerInput so that they are not flattened till the end. |
+| `additional_inputs` | `None`; or [depset](/versions/8.4.2/rules/lib/builtins/depset); default is `None`  For additional inputs to the linking action, e.g.: linking scripts. |
 
 ## create\_linking\_context
 
@@ -279,10 +279,10 @@ Creates a `LinkingContext`.
 
 | Parameter | Description |
 | --- | --- |
-| `linker_inputs` | `None`; or [depset](../builtins/depset); default is `None`  Depset of `LinkerInput`. |
-| `libraries_to_link` | `None`; or [sequence](../core/list); default is `None`  **Deprecated**. This parameter is deprecated and will be removed soon. Please do not depend on it. It is *disabled* with `--incompatible_require_linker_input_cc_api`. Use this flag to verify your code is compatible with its imminent removal.  List of `LibraryToLink`. |
-| `user_link_flags` | `None`; or [sequence](../core/list); default is `None` |
-| `additional_inputs` | `None`; or [sequence](../core/list); default is `None` |
+| `linker_inputs` | `None`; or [depset](/versions/8.4.2/rules/lib/builtins/depset); default is `None`  Depset of `LinkerInput`. |
+| `libraries_to_link` | `None`; or [sequence](/versions/8.4.2/rules/lib/core/list); default is `None`  **Deprecated**. This parameter is deprecated and will be removed soon. Please do not depend on it. It is *disabled* with `--incompatible_require_linker_input_cc_api`. Use this flag to verify your code is compatible with its imminent removal.  List of `LibraryToLink`. |
+| `user_link_flags` | `None`; or [sequence](/versions/8.4.2/rules/lib/core/list); default is `None` |
+| `additional_inputs` | `None`; or [sequence](/versions/8.4.2/rules/lib/core/list); default is `None` |
 
 ## create\_linking\_context\_from\_compilation\_outputs
 
@@ -296,19 +296,19 @@ Should be used for creating library rules that can propagate information downstr
 
 | Parameter | Description |
 | --- | --- |
-| `actions` | [actions](../builtins/actions); required |
-| `name` | [string](../core/string); required  This is used for naming the output artifacts of actions created by this method. |
-| `feature_configuration` | [FeatureConfiguration](../builtins/FeatureConfiguration); required  `feature_configuration` to be queried. |
+| `actions` | [actions](/versions/8.4.2/rules/lib/builtins/actions); required |
+| `name` | [string](/versions/8.4.2/rules/lib/core/string); required  This is used for naming the output artifacts of actions created by this method. |
+| `feature_configuration` | [FeatureConfiguration](/versions/8.4.2/rules/lib/builtins/FeatureConfiguration); required  `feature_configuration` to be queried. |
 | `cc_toolchain` | Info; required  `CcToolchainInfo` provider to be used. |
-| `language` | [string](../core/string); default is `'c++'`  Only C++ supported for now. Do not use this parameter. |
-| `disallow_static_libraries` | [bool](../core/bool); default is `False`  Whether static libraries should be created. |
-| `disallow_dynamic_library` | [bool](../core/bool); default is `False`  Whether a dynamic library should be created. |
-| `compilation_outputs` | [CcCompilationOutputs](../builtins/CcCompilationOutputs); required  Compilation outputs containing object files to link. |
-| `linking_contexts` | [sequence](../core/list); default is `[]`  Libraries from dependencies. These libraries will be linked into the output artifact of the link() call, be it a binary or a library. |
-| `user_link_flags` | [sequence](../core/list); default is `[]`  Additional list of linking options. |
-| `alwayslink` | [bool](../core/bool); default is `False`  Whether this library should always be linked. |
-| `additional_inputs` | [sequence](../core/list); default is `[]`  For additional inputs to the linking action, e.g.: linking scripts. |
-| `variables_extension` | [dict](../core/dict); default is `unbound`  Additional variables to pass to the toolchain configuration when creating link command line. |
+| `language` | [string](/versions/8.4.2/rules/lib/core/string); default is `'c++'`  Only C++ supported for now. Do not use this parameter. |
+| `disallow_static_libraries` | [bool](/versions/8.4.2/rules/lib/core/bool); default is `False`  Whether static libraries should be created. |
+| `disallow_dynamic_library` | [bool](/versions/8.4.2/rules/lib/core/bool); default is `False`  Whether a dynamic library should be created. |
+| `compilation_outputs` | [CcCompilationOutputs](/versions/8.4.2/rules/lib/builtins/CcCompilationOutputs); required  Compilation outputs containing object files to link. |
+| `linking_contexts` | [sequence](/versions/8.4.2/rules/lib/core/list); default is `[]`  Libraries from dependencies. These libraries will be linked into the output artifact of the link() call, be it a binary or a library. |
+| `user_link_flags` | [sequence](/versions/8.4.2/rules/lib/core/list); default is `[]`  Additional list of linking options. |
+| `alwayslink` | [bool](/versions/8.4.2/rules/lib/core/bool); default is `False`  Whether this library should always be linked. |
+| `additional_inputs` | [sequence](/versions/8.4.2/rules/lib/core/list); default is `[]`  For additional inputs to the linking action, e.g.: linking scripts. |
+| `variables_extension` | [dict](/versions/8.4.2/rules/lib/core/dict); default is `unbound`  Additional variables to pass to the toolchain configuration when creating link command line. |
 
 ## create\_lto\_compilation\_context
 
@@ -322,7 +322,7 @@ Create LTO compilation context
 
 | Parameter | Description |
 | --- | --- |
-| `objects` | [dict](../core/dict); default is `{}`  map of full object to index object |
+| `objects` | [dict](/versions/8.4.2/rules/lib/core/dict); default is `{}`  map of full object to index object |
 
 ## do\_not\_use\_tools\_cpp\_compiler\_present
 
@@ -344,8 +344,8 @@ Returns environment variables to be set for given action.
 
 | Parameter | Description |
 | --- | --- |
-| `feature_configuration` | [FeatureConfiguration](../builtins/FeatureConfiguration); required  Feature configuration to be queried. |
-| `action_name` | [string](../core/string); required  Name of the action. Has to be one of the names in @bazel\_tools//tools/build\_defs/cc:action\_names.bzl (https://github.com/bazelbuild/bazel/blob/master/tools/build\_defs/cc/action\_names.bzl) |
+| `feature_configuration` | [FeatureConfiguration](/versions/8.4.2/rules/lib/builtins/FeatureConfiguration); required  Feature configuration to be queried. |
+| `action_name` | [string](/versions/8.4.2/rules/lib/core/string); required  Name of the action. Has to be one of the names in @bazel\_tools//tools/build\_defs/cc:action\_names.bzl (https://github.com/bazelbuild/bazel/blob/master/tools/build\_defs/cc/action\_names.bzl) |
 | `variables` | Variables; required  Build variables to be used for template expansion. |
 
 ## get\_execution\_requirements
@@ -360,8 +360,8 @@ Returns execution requirements for given action.
 
 | Parameter | Description |
 | --- | --- |
-| `feature_configuration` | [FeatureConfiguration](../builtins/FeatureConfiguration); required  Feature configuration to be queried. |
-| `action_name` | [string](../core/string); required  Name of the action. Has to be one of the names in @bazel\_tools//tools/build\_defs/cc:action\_names.bzl (https://github.com/bazelbuild/bazel/blob/master/tools/build\_defs/cc/action\_names.bzl) |
+| `feature_configuration` | [FeatureConfiguration](/versions/8.4.2/rules/lib/builtins/FeatureConfiguration); required  Feature configuration to be queried. |
+| `action_name` | [string](/versions/8.4.2/rules/lib/core/string); required  Name of the action. Has to be one of the names in @bazel\_tools//tools/build\_defs/cc:action\_names.bzl (https://github.com/bazelbuild/bazel/blob/master/tools/build\_defs/cc/action\_names.bzl) |
 
 ## get\_memory\_inefficient\_command\_line
 
@@ -375,8 +375,8 @@ Returns flattened command line flags for given action, using given variables for
 
 | Parameter | Description |
 | --- | --- |
-| `feature_configuration` | [FeatureConfiguration](../builtins/FeatureConfiguration); required  Feature configuration to be queried. |
-| `action_name` | [string](../core/string); required  Name of the action. Has to be one of the names in @bazel\_tools//tools/build\_defs/cc:action\_names.bzl (https://github.com/bazelbuild/bazel/blob/master/tools/build\_defs/cc/action\_names.bzl) |
+| `feature_configuration` | [FeatureConfiguration](/versions/8.4.2/rules/lib/builtins/FeatureConfiguration); required  Feature configuration to be queried. |
+| `action_name` | [string](/versions/8.4.2/rules/lib/core/string); required  Name of the action. Has to be one of the names in @bazel\_tools//tools/build\_defs/cc:action\_names.bzl (https://github.com/bazelbuild/bazel/blob/master/tools/build\_defs/cc/action\_names.bzl) |
 | `variables` | Variables; required  Build variables to be used for template expansions. |
 
 ## get\_tool\_for\_action
@@ -391,8 +391,8 @@ Returns tool path for given action.
 
 | Parameter | Description |
 | --- | --- |
-| `feature_configuration` | [FeatureConfiguration](../builtins/FeatureConfiguration); required  Feature configuration to be queried. |
-| `action_name` | [string](../core/string); required  Name of the action. Has to be one of the names in @bazel\_tools//tools/build\_defs/cc:action\_names.bzl (https://github.com/bazelbuild/bazel/blob/master/tools/build\_defs/cc/action\_names.bzl) |
+| `feature_configuration` | [FeatureConfiguration](/versions/8.4.2/rules/lib/builtins/FeatureConfiguration); required  Feature configuration to be queried. |
+| `action_name` | [string](/versions/8.4.2/rules/lib/core/string); required  Name of the action. Has to be one of the names in @bazel\_tools//tools/build\_defs/cc:action\_names.bzl (https://github.com/bazelbuild/bazel/blob/master/tools/build\_defs/cc/action\_names.bzl) |
 
 ## is\_enabled
 
@@ -406,8 +406,8 @@ Returns True if given feature is enabled in the feature configuration.
 
 | Parameter | Description |
 | --- | --- |
-| `feature_configuration` | [FeatureConfiguration](../builtins/FeatureConfiguration); required  Feature configuration to be queried. |
-| `feature_name` | [string](../core/string); required  Name of the feature. |
+| `feature_configuration` | [FeatureConfiguration](/versions/8.4.2/rules/lib/builtins/FeatureConfiguration); required  Feature configuration to be queried. |
+| `feature_name` | [string](/versions/8.4.2/rules/lib/core/string); required  Name of the feature. |
 
 ## link
 
@@ -421,20 +421,20 @@ Should be used for C++ transitive linking.
 
 | Parameter | Description |
 | --- | --- |
-| `actions` | [actions](../builtins/actions); required  `actions` object. |
-| `name` | [string](../core/string); required  This is used for naming the output artifacts of actions created by this method. |
-| `feature_configuration` | [FeatureConfiguration](../builtins/FeatureConfiguration); required  `feature_configuration` to be queried. |
+| `actions` | [actions](/versions/8.4.2/rules/lib/builtins/actions); required  `actions` object. |
+| `name` | [string](/versions/8.4.2/rules/lib/core/string); required  This is used for naming the output artifacts of actions created by this method. |
+| `feature_configuration` | [FeatureConfiguration](/versions/8.4.2/rules/lib/builtins/FeatureConfiguration); required  `feature_configuration` to be queried. |
 | `cc_toolchain` | Info; required  `CcToolchainInfo` provider to be used. |
-| `language` | [string](../core/string); default is `'c++'`  Only C++ supported for now. Do not use this parameter. |
-| `output_type` | [string](../core/string); default is `'executable'`  Can be either 'executable' or 'dynamic\_library'. |
-| `link_deps_statically` | [bool](../core/bool); default is `True`  True to link dependencies statically, False dynamically. |
-| `compilation_outputs` | [CcCompilationOutputs](../builtins/CcCompilationOutputs); or `None`; default is `None`  Compilation outputs containing object files to link. |
-| `linking_contexts` | [sequence](../core/list); default is `[]`  Linking contexts from dependencies to be linked into the linking context generated by this rule. |
-| `user_link_flags` | [sequence](../core/list); default is `[]`  Additional list of linker options. |
-| `stamp` | [int](../core/int); default is `0`  Whether to include build information in the linked executable, if output\_type is 'executable'. If 1, build information is always included. If 0 (the default build information is always excluded. If -1, uses the default behavior, which may be overridden by the --[no]stamp flag. This should be unset (or set to 0) when generating the executable output for test rules. |
-| `additional_inputs` | [sequence](../core/list); or [depset](../builtins/depset); default is `[]`  For additional inputs to the linking action, e.g.: linking scripts. |
-| `additional_outputs` | [sequence](../core/list); default is `[]`  For additional outputs to the linking action, e.g.: map files. |
-| `variables_extension` | [dict](../core/dict); default is `{}`  Additional variables to pass to the toolchain configuration when create link command line. |
+| `language` | [string](/versions/8.4.2/rules/lib/core/string); default is `'c++'`  Only C++ supported for now. Do not use this parameter. |
+| `output_type` | [string](/versions/8.4.2/rules/lib/core/string); default is `'executable'`  Can be either 'executable' or 'dynamic\_library'. |
+| `link_deps_statically` | [bool](/versions/8.4.2/rules/lib/core/bool); default is `True`  True to link dependencies statically, False dynamically. |
+| `compilation_outputs` | [CcCompilationOutputs](/versions/8.4.2/rules/lib/builtins/CcCompilationOutputs); or `None`; default is `None`  Compilation outputs containing object files to link. |
+| `linking_contexts` | [sequence](/versions/8.4.2/rules/lib/core/list); default is `[]`  Linking contexts from dependencies to be linked into the linking context generated by this rule. |
+| `user_link_flags` | [sequence](/versions/8.4.2/rules/lib/core/list); default is `[]`  Additional list of linker options. |
+| `stamp` | [int](/versions/8.4.2/rules/lib/core/int); default is `0`  Whether to include build information in the linked executable, if output\_type is 'executable'. If 1, build information is always included. If 0 (the default build information is always excluded. If -1, uses the default behavior, which may be overridden by the --[no]stamp flag. This should be unset (or set to 0) when generating the executable output for test rules. |
+| `additional_inputs` | [sequence](/versions/8.4.2/rules/lib/core/list); or [depset](/versions/8.4.2/rules/lib/builtins/depset); default is `[]`  For additional inputs to the linking action, e.g.: linking scripts. |
+| `additional_outputs` | [sequence](/versions/8.4.2/rules/lib/core/list); default is `[]`  For additional outputs to the linking action, e.g.: map files. |
+| `variables_extension` | [dict](/versions/8.4.2/rules/lib/core/dict); default is `{}`  Additional variables to pass to the toolchain configuration when create link command line. |
 
 ## merge\_compilation\_contexts
 
@@ -448,7 +448,7 @@ Merges multiple `CompilationContexts`s into one.
 
 | Parameter | Description |
 | --- | --- |
-| `compilation_contexts` | [sequence](../core/list); default is `[]`  List of `CompilationContexts`s to be merged. The headers of each context will be exported by the direct fields in the returned provider. |
+| `compilation_contexts` | [sequence](/versions/8.4.2/rules/lib/core/list); default is `[]`  List of `CompilationContexts`s to be merged. The headers of each context will be exported by the direct fields in the returned provider. |
 
 ## merge\_compilation\_outputs
 
@@ -462,4 +462,4 @@ Merge compilation outputs.
 
 | Parameter | Description |
 | --- | --- |
-| `compilation_outputs` | [sequence](../core/list); default is `[]` |
\ No newline at end of file
+| `compilation_outputs` | [sequence](/versions/8.4.2/rules/lib/core/list); default is `[]` |
\ No newline at end of file
diff --git a/versions/8.4.2/rules/lib/toplevel/config.mdx b/versions/8.4.2/rules/lib/toplevel/config.mdx
index 4b60c243..729e62e3 100644
--- a/versions/8.4.2/rules/lib/toplevel/config.mdx
+++ b/versions/8.4.2/rules/lib/toplevel/config.mdx
@@ -36,7 +36,7 @@ A bool-typed build setting
 
 | Parameter | Description |
 | --- | --- |
-| `flag` | [bool](../core/bool); default is `False` |
+| `flag` | [bool](/versions/8.4.2/rules/lib/core/bool); default is `False` |
 
 ## exec
 
@@ -50,7 +50,7 @@ Creates an execution transition.
 
 | Parameter | Description |
 | --- | --- |
-| `exec_group` | [string](../core/string); or `None`; default is `None`  The name of the exec group whose execution platform this transition will use. If not provided, this exec transition will use the target's default execution platform. |
+| `exec_group` | [string](/versions/8.4.2/rules/lib/core/string); or `None`; default is `None`  The name of the exec group whose execution platform this transition will use. If not provided, this exec transition will use the target's default execution platform. |
 
 ## int
 
@@ -64,7 +64,7 @@ An integer-typed build setting
 
 | Parameter | Description |
 | --- | --- |
-| `flag` | [bool](../core/bool); default is `False`  Whether or not this build setting is callable on the command line. |
+| `flag` | [bool](/versions/8.4.2/rules/lib/core/bool); default is `False`  Whether or not this build setting is callable on the command line. |
 
 ## none
 
@@ -86,8 +86,8 @@ A string-typed build setting
 
 | Parameter | Description |
 | --- | --- |
-| `flag` | [bool](../core/bool); default is `False`  Whether or not this build setting is callable on the command line. |
-| `allow_multiple` | [bool](../core/bool); default is `False`  Deprecated, use a `string_list` setting with `repeatable = True` instead. If set, this flag is allowed to be set multiple times on the command line. The Value of the flag as accessed in transitions and build setting implementation function will be a list of strings. Insertion order and repeated values are both maintained. This list can be post-processed in the build setting implementation function if different behavior is desired. |
+| `flag` | [bool](/versions/8.4.2/rules/lib/core/bool); default is `False`  Whether or not this build setting is callable on the command line. |
+| `allow_multiple` | [bool](/versions/8.4.2/rules/lib/core/bool); default is `False`  Deprecated, use a `string_list` setting with `repeatable = True` instead. If set, this flag is allowed to be set multiple times on the command line. The Value of the flag as accessed in transitions and build setting implementation function will be a list of strings. Insertion order and repeated values are both maintained. This list can be post-processed in the build setting implementation function if different behavior is desired. |
 
 ## string\_list
 
@@ -101,8 +101,8 @@ A string list-typed build setting. On the command line pass a list using comma-s
 
 | Parameter | Description |
 | --- | --- |
-| `flag` | [bool](../core/bool); default is `False`  Whether or not this build setting is callable on the command line. |
-| `repeatable` | [bool](../core/bool); default is `False`  If set, instead of expecting a comma-separated value, this flag is allowed to be set multiple times on the command line with each individual value treated as a single string to add to the list value. Insertion order and repeated values are both maintained. This list can be post-processed in the build setting implementation function if different behavior is desired. |
+| `flag` | [bool](/versions/8.4.2/rules/lib/core/bool); default is `False`  Whether or not this build setting is callable on the command line. |
+| `repeatable` | [bool](/versions/8.4.2/rules/lib/core/bool); default is `False`  If set, instead of expecting a comma-separated value, this flag is allowed to be set multiple times on the command line with each individual value treated as a single string to add to the list value. Insertion order and repeated values are both maintained. This list can be post-processed in the build setting implementation function if different behavior is desired. |
 
 ## target
 
diff --git a/versions/8.4.2/rules/lib/toplevel/config_common.mdx b/versions/8.4.2/rules/lib/toplevel/config_common.mdx
index 9169b17a..d5014c40 100644
--- a/versions/8.4.2/rules/lib/toplevel/config_common.mdx
+++ b/versions/8.4.2/rules/lib/toplevel/config_common.mdx
@@ -29,5 +29,5 @@ Declare a rule's dependency on a toolchain type.
 
 | Parameter | Description |
 | --- | --- |
-| `name` | [string](../core/string); or [Label](../builtins/Label); required  The toolchain type that is required. |
-| `mandatory` | [bool](../core/bool); default is `True`  Whether the toolchain type is mandatory or optional. |
\ No newline at end of file
+| `name` | [string](/versions/8.4.2/rules/lib/core/string); or [Label](/versions/8.4.2/rules/lib/builtins/Label); required  The toolchain type that is required. |
+| `mandatory` | [bool](/versions/8.4.2/rules/lib/core/bool); default is `True`  Whether the toolchain type is mandatory or optional. |
\ No newline at end of file
diff --git a/versions/8.4.2/rules/lib/toplevel/coverage_common.mdx b/versions/8.4.2/rules/lib/toplevel/coverage_common.mdx
index e93e1226..2ab98f68 100644
--- a/versions/8.4.2/rules/lib/toplevel/coverage_common.mdx
+++ b/versions/8.4.2/rules/lib/toplevel/coverage_common.mdx
@@ -14,14 +14,14 @@ Helper functions to access coverage-related infrastructure.
 InstrumentedFilesInfo coverage_common.instrumented_files_info(ctx, *, source_attributes=[], dependency_attributes=[], extensions=None, metadata_files=[])
 ```
 
-Creates a new [InstrumentedFilesInfo](../providers/InstrumentedFilesInfo) instance. Use this provider to communicate coverage-related attributes of the current build rule.
+Creates a new [InstrumentedFilesInfo](/versions/8.4.2/rules/lib/providers/InstrumentedFilesInfo) instance. Use this provider to communicate coverage-related attributes of the current build rule.
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `ctx` | [ctx](../builtins/ctx); required  The rule context. |
-| `source_attributes` | [sequence](../core/list); default is `[]`  A list of attribute names which contain source files processed by this rule. |
-| `dependency_attributes` | [sequence](../core/list); default is `[]`  A list of attribute names which might provide runtime dependencies (either code dependencies or runfiles). |
-| `extensions` | [sequence](../core/list) of [string](../core/string)s; or `None`; default is `None`  File extensions used to filter files from source\_attributes. For example, 'js'. If not provided (or None), then all files from source\_attributes will be added to instrumented files, if an empty list is provided, then no files from source attributes will be added. |
-| `metadata_files` | [sequence](../core/list) of [File](../builtins/File)s; default is `[]`  Additional files required to generate coverage LCOV files after code execution. e.g. .gcno files for C++. |
\ No newline at end of file
+| `ctx` | [ctx](/versions/8.4.2/rules/lib/builtins/ctx); required  The rule context. |
+| `source_attributes` | [sequence](/versions/8.4.2/rules/lib/core/list); default is `[]`  A list of attribute names which contain source files processed by this rule. |
+| `dependency_attributes` | [sequence](/versions/8.4.2/rules/lib/core/list); default is `[]`  A list of attribute names which might provide runtime dependencies (either code dependencies or runfiles). |
+| `extensions` | [sequence](/versions/8.4.2/rules/lib/core/list) of [string](/versions/8.4.2/rules/lib/core/string)s; or `None`; default is `None`  File extensions used to filter files from source\_attributes. For example, 'js'. If not provided (or None), then all files from source\_attributes will be added to instrumented files, if an empty list is provided, then no files from source attributes will be added. |
+| `metadata_files` | [sequence](/versions/8.4.2/rules/lib/core/list) of [File](/versions/8.4.2/rules/lib/builtins/File)s; default is `[]`  Additional files required to generate coverage LCOV files after code execution. e.g. .gcno files for C++. |
\ No newline at end of file
diff --git a/versions/8.4.2/rules/lib/toplevel/java_common.mdx b/versions/8.4.2/rules/lib/toplevel/java_common.mdx
index 8c953f60..7f21a520 100644
--- a/versions/8.4.2/rules/lib/toplevel/java_common.mdx
+++ b/versions/8.4.2/rules/lib/toplevel/java_common.mdx
@@ -35,33 +35,33 @@ Compiles Java source files/jars from the implementation of a Starlark rule and r
 
 | Parameter | Description |
 | --- | --- |
-| `ctx` | [ctx](../builtins/ctx); required  The rule context. |
-| `source_jars` | [sequence](../core/list) of [File](../builtins/File)s; default is `[]`  A list of the jars to be compiled. At least one of source\_jars or source\_files should be specified. |
-| `source_files` | [sequence](../core/list) of [File](../builtins/File)s; default is `[]`  A list of the Java source files to be compiled. At least one of source\_jars or source\_files should be specified. |
-| `output` | [File](../builtins/File); required |
-| `output_source_jar` | [File](../builtins/File); or `None`; default is `None`  The output source jar. Defaults to `{output\_jar}-src.jar` if unset. |
-| `javac_opts` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  A list of the desired javac options. |
-| `deps` | [sequence](../core/list) of [struct](../builtins/struct)s; default is `[]`  A list of dependencies. |
-| `runtime_deps` | [sequence](../core/list) of [struct](../builtins/struct)s; default is `[]`  A list of runtime dependencies. |
-| `exports` | [sequence](../core/list) of [struct](../builtins/struct)s; default is `[]`  A list of exports. |
-| `plugins` | [sequence](../core/list) of [struct](../builtins/struct)s; or [sequence](../core/list) of [struct](../builtins/struct)s; default is `[]`  A list of plugins. |
-| `exported_plugins` | [sequence](../core/list) of [struct](../builtins/struct)s; or [sequence](../core/list) of [struct](../builtins/struct)s; default is `[]`  A list of exported plugins. |
-| `native_libraries` | [sequence](../core/list) of [CcInfo](../providers/CcInfo)s; default is `[]`  CC native library dependencies that are needed for this library. |
-| `annotation_processor_additional_inputs` | [sequence](../core/list) of [File](../builtins/File)s; default is `[]`  A list of inputs that the Java compilation action will take in addition to the Java sources for annotation processing. |
-| `annotation_processor_additional_outputs` | [sequence](../core/list) of [File](../builtins/File)s; default is `[]`  A list of outputs that the Java compilation action will output in addition to the class jar from annotation processing. |
-| `strict_deps` | [string](../core/string); default is `'ERROR'`  A string that specifies how to handle strict deps. Possible values: 'OFF', 'ERROR', 'WARN' and 'DEFAULT'. For more details see [`--strict_java_deps flag`](/versions/8.4.2/docs/user-manual#flag--strict_java_deps). By default 'ERROR'. |
+| `ctx` | [ctx](/versions/8.4.2/rules/lib/builtins/ctx); required  The rule context. |
+| `source_jars` | [sequence](/versions/8.4.2/rules/lib/core/list) of [File](/versions/8.4.2/rules/lib/builtins/File)s; default is `[]`  A list of the jars to be compiled. At least one of source\_jars or source\_files should be specified. |
+| `source_files` | [sequence](/versions/8.4.2/rules/lib/core/list) of [File](/versions/8.4.2/rules/lib/builtins/File)s; default is `[]`  A list of the Java source files to be compiled. At least one of source\_jars or source\_files should be specified. |
+| `output` | [File](/versions/8.4.2/rules/lib/builtins/File); required |
+| `output_source_jar` | [File](/versions/8.4.2/rules/lib/builtins/File); or `None`; default is `None`  The output source jar. Defaults to `{output\_jar}-src.jar` if unset. |
+| `javac_opts` | [sequence](/versions/8.4.2/rules/lib/core/list) of [string](/versions/8.4.2/rules/lib/core/string)s; default is `[]`  A list of the desired javac options. |
+| `deps` | [sequence](/versions/8.4.2/rules/lib/core/list) of [struct](/versions/8.4.2/rules/lib/builtins/struct)s; default is `[]`  A list of dependencies. |
+| `runtime_deps` | [sequence](/versions/8.4.2/rules/lib/core/list) of [struct](/versions/8.4.2/rules/lib/builtins/struct)s; default is `[]`  A list of runtime dependencies. |
+| `exports` | [sequence](/versions/8.4.2/rules/lib/core/list) of [struct](/versions/8.4.2/rules/lib/builtins/struct)s; default is `[]`  A list of exports. |
+| `plugins` | [sequence](/versions/8.4.2/rules/lib/core/list) of [struct](/versions/8.4.2/rules/lib/builtins/struct)s; or [sequence](/versions/8.4.2/rules/lib/core/list) of [struct](/versions/8.4.2/rules/lib/builtins/struct)s; default is `[]`  A list of plugins. |
+| `exported_plugins` | [sequence](/versions/8.4.2/rules/lib/core/list) of [struct](/versions/8.4.2/rules/lib/builtins/struct)s; or [sequence](/versions/8.4.2/rules/lib/core/list) of [struct](/versions/8.4.2/rules/lib/builtins/struct)s; default is `[]`  A list of exported plugins. |
+| `native_libraries` | [sequence](/versions/8.4.2/rules/lib/core/list) of [CcInfo](/versions/8.4.2/rules/lib/providers/CcInfo)s; default is `[]`  CC native library dependencies that are needed for this library. |
+| `annotation_processor_additional_inputs` | [sequence](/versions/8.4.2/rules/lib/core/list) of [File](/versions/8.4.2/rules/lib/builtins/File)s; default is `[]`  A list of inputs that the Java compilation action will take in addition to the Java sources for annotation processing. |
+| `annotation_processor_additional_outputs` | [sequence](/versions/8.4.2/rules/lib/core/list) of [File](/versions/8.4.2/rules/lib/builtins/File)s; default is `[]`  A list of outputs that the Java compilation action will output in addition to the class jar from annotation processing. |
+| `strict_deps` | [string](/versions/8.4.2/rules/lib/core/string); default is `'ERROR'`  A string that specifies how to handle strict deps. Possible values: 'OFF', 'ERROR', 'WARN' and 'DEFAULT'. For more details see [`--strict_java_deps flag`](/versions/8.4.2/docs/user-manual#flag--strict_java_deps). By default 'ERROR'. |
 | `java_toolchain` | Info; required  A JavaToolchainInfo to be used for this compilation. Mandatory. |
 | `bootclasspath` | default is `None`  A BootClassPathInfo to be used for this compilation. If present, overrides the bootclasspath associated with the provided java\_toolchain. |
 | `host_javabase` | default is `None`  **Deprecated**. This parameter is deprecated and will be removed soon. Please do not depend on it. It is *disabled* with `--incompatible_java_common_parameters`. Use this flag to verify your code is compatible with its imminent removal.  Deprecated: You can drop this parameter (host\_javabase is provided with java\_toolchain) |
-| `sourcepath` | [sequence](../core/list) of [File](../builtins/File)s; default is `[]` |
-| `resources` | [sequence](../core/list) of [File](../builtins/File)s; default is `[]` |
-| `resource_jars` | [sequence](../core/list) of [File](../builtins/File)s; default is `[]` |
-| `classpath_resources` | [sequence](../core/list) of [File](../builtins/File)s; default is `[]` |
-| `neverlink` | [bool](../core/bool); default is `False` |
-| `enable_annotation_processing` | [bool](../core/bool); default is `True`  Disables annotation processing in this compilation, causing any annotation processors provided in plugins or in exported\_plugins of deps to be ignored. |
-| `enable_compile_jar_action` | [bool](../core/bool); default is `True`  Enables header compilation or ijar creation. If set to False, it forces use of the full class jar in the compilation classpaths of any dependants. Doing so is intended for use by non-library targets such as binaries that do not have dependants. |
-| `add_exports` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  Allow this library to access the given /. |
-| `add_opens` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  Allow this library to reflectively access the given /. |
+| `sourcepath` | [sequence](/versions/8.4.2/rules/lib/core/list) of [File](/versions/8.4.2/rules/lib/builtins/File)s; default is `[]` |
+| `resources` | [sequence](/versions/8.4.2/rules/lib/core/list) of [File](/versions/8.4.2/rules/lib/builtins/File)s; default is `[]` |
+| `resource_jars` | [sequence](/versions/8.4.2/rules/lib/core/list) of [File](/versions/8.4.2/rules/lib/builtins/File)s; default is `[]` |
+| `classpath_resources` | [sequence](/versions/8.4.2/rules/lib/core/list) of [File](/versions/8.4.2/rules/lib/builtins/File)s; default is `[]` |
+| `neverlink` | [bool](/versions/8.4.2/rules/lib/core/bool); default is `False` |
+| `enable_annotation_processing` | [bool](/versions/8.4.2/rules/lib/core/bool); default is `True`  Disables annotation processing in this compilation, causing any annotation processors provided in plugins or in exported\_plugins of deps to be ignored. |
+| `enable_compile_jar_action` | [bool](/versions/8.4.2/rules/lib/core/bool); default is `True`  Enables header compilation or ijar creation. If set to False, it forces use of the full class jar in the compilation classpaths of any dependants. Doing so is intended for use by non-library targets such as binaries that do not have dependants. |
+| `add_exports` | [sequence](/versions/8.4.2/rules/lib/core/list) of [string](/versions/8.4.2/rules/lib/core/string)s; default is `[]`  Allow this library to access the given /. |
+| `add_opens` | [sequence](/versions/8.4.2/rules/lib/core/list) of [string](/versions/8.4.2/rules/lib/core/string)s; default is `[]`  Allow this library to reflectively access the given /. |
 
 ## JavaRuntimeInfo
 
@@ -91,7 +91,7 @@ Merges the given providers into a single JavaInfo.
 
 | Parameter | Description |
 | --- | --- |
-| `providers` | [sequence](../core/list) of [struct](../builtins/struct)s; required  The list of providers to merge. |
+| `providers` | [sequence](/versions/8.4.2/rules/lib/core/list) of [struct](/versions/8.4.2/rules/lib/builtins/struct)s; required  The list of providers to merge. |
 
 ## pack\_sources
 
@@ -109,11 +109,11 @@ Packs sources and source jars into a single source jar file. The return value is
 
 | Parameter | Description |
 | --- | --- |
-| `actions` | [actions](../builtins/actions); required  ctx.actions |
-| `output_jar` | [File](../builtins/File); or `None`; default is `None`  **Deprecated**. This parameter is deprecated and will be removed soon. Please do not depend on it. It is *disabled* with `--incompatible_java_common_parameters`. Use this flag to verify your code is compatible with its imminent removal.  Deprecated: The output jar of the rule. Used to name the resulting source jar. The parameter sets output\_source\_jar parameter to `{output\_jar}-src.jar`.Use output\_source\_jar parameter directly instead. |
-| `output_source_jar` | [File](../builtins/File); or `None`; default is `None` |
-| `sources` | [sequence](../core/list) of [File](../builtins/File)s; default is `[]`  A list of Java source files to be packed into the source jar. |
-| `source_jars` | [sequence](../core/list) of [File](../builtins/File)s; default is `[]`  A list of source jars to be packed into the source jar. |
+| `actions` | [actions](/versions/8.4.2/rules/lib/builtins/actions); required  ctx.actions |
+| `output_jar` | [File](/versions/8.4.2/rules/lib/builtins/File); or `None`; default is `None`  **Deprecated**. This parameter is deprecated and will be removed soon. Please do not depend on it. It is *disabled* with `--incompatible_java_common_parameters`. Use this flag to verify your code is compatible with its imminent removal.  Deprecated: The output jar of the rule. Used to name the resulting source jar. The parameter sets output\_source\_jar parameter to `{output\_jar}-src.jar`.Use output\_source\_jar parameter directly instead. |
+| `output_source_jar` | [File](/versions/8.4.2/rules/lib/builtins/File); or `None`; default is `None` |
+| `sources` | [sequence](/versions/8.4.2/rules/lib/core/list) of [File](/versions/8.4.2/rules/lib/builtins/File)s; default is `[]`  A list of Java source files to be packed into the source jar. |
+| `source_jars` | [sequence](/versions/8.4.2/rules/lib/core/list) of [File](/versions/8.4.2/rules/lib/builtins/File)s; default is `[]`  A list of source jars to be packed into the source jar. |
 | `java_toolchain` | Info; required  A JavaToolchainInfo to used to find the ijar tool. |
 | `host_javabase` | default is `None`  **Deprecated**. This parameter is deprecated and will be removed soon. Please do not depend on it. It is *disabled* with `--incompatible_java_common_parameters`. Use this flag to verify your code is compatible with its imminent removal.  Deprecated: You can drop this parameter (host\_javabase is provided with java\_toolchain) |
 
@@ -129,9 +129,9 @@ Runs ijar on a jar, stripping it of its method bodies. This helps reduce rebuild
 
 | Parameter | Description |
 | --- | --- |
-| `actions` | [actions](../builtins/actions); required |
-| `jar` | [File](../builtins/File); required  The jar to run ijar on. |
-| `target_label` | [Label](../builtins/Label); or `None`; default is `None`  A target label to stamp the jar with. Used for `add_dep` support. Typically, you would pass `ctx.label` to stamp the jar with the current rule's label. |
+| `actions` | [actions](/versions/8.4.2/rules/lib/builtins/actions); required |
+| `jar` | [File](/versions/8.4.2/rules/lib/builtins/File); required  The jar to run ijar on. |
+| `target_label` | [Label](/versions/8.4.2/rules/lib/builtins/Label); or `None`; default is `None`  A target label to stamp the jar with. Used for `add_dep` support. Typically, you would pass `ctx.label` to stamp the jar with the current rule's label. |
 | `java_toolchain` | Info; required  A JavaToolchainInfo to used to find the ijar tool. |
 
 ## stamp\_jar
@@ -146,7 +146,7 @@ Stamps a jar with a target label for `add_dep` support. The return value is typi
 
 | Parameter | Description |
 | --- | --- |
-| `actions` | [actions](../builtins/actions); required  ctx.actions |
-| `jar` | [File](../builtins/File); required  The jar to run stamp\_jar on. |
-| `target_label` | [Label](../builtins/Label); required  A target label to stamp the jar with. Used for `add_dep` support. Typically, you would pass `ctx.label` to stamp the jar with the current rule's label. |
+| `actions` | [actions](/versions/8.4.2/rules/lib/builtins/actions); required  ctx.actions |
+| `jar` | [File](/versions/8.4.2/rules/lib/builtins/File); required  The jar to run stamp\_jar on. |
+| `target_label` | [Label](/versions/8.4.2/rules/lib/builtins/Label); required  A target label to stamp the jar with. Used for `add_dep` support. Typically, you would pass `ctx.label` to stamp the jar with the current rule's label. |
 | `java_toolchain` | Info; required  A JavaToolchainInfo to used to find the stamp\_jar tool. |
\ No newline at end of file
diff --git a/versions/8.4.2/rules/lib/toplevel/native.mdx b/versions/8.4.2/rules/lib/toplevel/native.mdx
index 204fb814..66848d94 100644
--- a/versions/8.4.2/rules/lib/toplevel/native.mdx
+++ b/versions/8.4.2/rules/lib/toplevel/native.mdx
@@ -46,7 +46,7 @@ If possible, avoid using this function. It makes BUILD files brittle and order-d
 
 | Parameter | Description |
 | --- | --- |
-| `name` | [string](../core/string); required |
+| `name` | [string](/versions/8.4.2/rules/lib/core/string); required |
 
 ## existing\_rules
 
@@ -72,9 +72,9 @@ Specifies a list of files belonging to this package that are exported to other p
 
 | Parameter | Description |
 | --- | --- |
-| `srcs` | [sequence](../core/list) of [string](../core/string)s; required  The list of files to export. |
-| `visibility` | [sequence](../core/list); or `None`; default is `None`  A visibility declaration can to be specified. The files will be visible to the targets specified. If no visibility is specified, the files will be visible to every package. |
-| `licenses` | [sequence](../core/list) of [string](../core/string)s; or `None`; default is `None`  Licenses to be specified. |
+| `srcs` | [sequence](/versions/8.4.2/rules/lib/core/list) of [string](/versions/8.4.2/rules/lib/core/string)s; required  The list of files to export. |
+| `visibility` | [sequence](/versions/8.4.2/rules/lib/core/list); or `None`; default is `None`  A visibility declaration can to be specified. The files will be visible to the targets specified. If no visibility is specified, the files will be visible to every package. |
+| `licenses` | [sequence](/versions/8.4.2/rules/lib/core/list) of [string](/versions/8.4.2/rules/lib/core/string)s; or `None`; default is `None`  Licenses to be specified. |
 
 ## glob
 
@@ -93,9 +93,9 @@ If the `exclude_directories` argument is enabled (set to `1`), files of type dir
 
 | Parameter | Description |
 | --- | --- |
-| `include` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  The list of glob patterns to include. |
-| `exclude` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  The list of glob patterns to exclude. |
-| `exclude_directories` | [int](../core/int); default is `1`  A flag whether to exclude directories or not. |
+| `include` | [sequence](/versions/8.4.2/rules/lib/core/list) of [string](/versions/8.4.2/rules/lib/core/string)s; default is `[]`  The list of glob patterns to include. |
+| `exclude` | [sequence](/versions/8.4.2/rules/lib/core/list) of [string](/versions/8.4.2/rules/lib/core/string)s; default is `[]`  The list of glob patterns to exclude. |
+| `exclude_directories` | [int](/versions/8.4.2/rules/lib/core/int); default is `1`  A flag whether to exclude directories or not. |
 | `allow_empty` | default is `unbound`  Whether we allow glob patterns to match nothing. If `allow\_empty` is False, each individual include pattern must match something and also the final result must be non-empty (after the matches of the `exclude` patterns are excluded). |
 
 ## module\_name
@@ -128,9 +128,9 @@ This function defines a set of packages and assigns a label to the group. The la
 
 | Parameter | Description |
 | --- | --- |
-| `name` | [string](../core/string); required  The unique name for this rule. |
-| `packages` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  A complete enumeration of packages in this group. |
-| `includes` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  Other package groups that are included in this one. |
+| `name` | [string](/versions/8.4.2/rules/lib/core/string); required  The unique name for this rule. |
+| `packages` | [sequence](/versions/8.4.2/rules/lib/core/list) of [string](/versions/8.4.2/rules/lib/core/string)s; default is `[]`  A complete enumeration of packages in this group. |
+| `includes` | [sequence](/versions/8.4.2/rules/lib/core/list) of [string](/versions/8.4.2/rules/lib/core/string)s; default is `[]`  Other package groups that are included in this one. |
 
 ## package\_name
 
@@ -146,19 +146,19 @@ The name of the package being evaluated, without the repository name. For exampl
 Label native.package_relative_label(input)
 ```
 
-Converts the input string into a [Label](../builtins/Label) object, in the context of the package currently being initialized (that is, the `BUILD` file for which the current macro is executing). If the input is already a `Label`, it is returned unchanged.
+Converts the input string into a [Label](/versions/8.4.2/rules/lib/builtins/Label) object, in the context of the package currently being initialized (that is, the `BUILD` file for which the current macro is executing). If the input is already a `Label`, it is returned unchanged.
 
 This function may only be called while evaluating a BUILD file and the macros it directly or indirectly calls; it may not be called in (for instance) a rule implementation function.
 
 The result of this function is the same `Label` value as would be produced by passing the given string to a label-valued attribute of a target declared in the BUILD file.
 
-*Usage note:* The difference between this function and [Label()](../builtins/Label#Label) is that `Label()` uses the context of the package of the `.bzl` file that called it, not the package of the `BUILD` file. Use `Label()` when you need to refer to a fixed target that is hardcoded into the macro, such as a compiler. Use `package_relative_label()` when you need to normalize a label string supplied by the BUILD file to a `Label` object. (There is no way to convert a string to a `Label` in the context of a package other than the BUILD file or the calling .bzl file. For that reason, outer macros should always prefer to pass Label objects to inner macros rather than label strings.)
+*Usage note:* The difference between this function and [Label()](/versions/8.4.2/rules/lib/builtins/Label#Label) is that `Label()` uses the context of the package of the `.bzl` file that called it, not the package of the `BUILD` file. Use `Label()` when you need to refer to a fixed target that is hardcoded into the macro, such as a compiler. Use `package_relative_label()` when you need to normalize a label string supplied by the BUILD file to a `Label` object. (There is no way to convert a string to a `Label` in the context of a package other than the BUILD file or the calling .bzl file. For that reason, outer macros should always prefer to pass Label objects to inner macros rather than label strings.)
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `input` | [string](../core/string); or [Label](../builtins/Label); required  The input label string or Label object. If a Label object is passed, it's returned as is. |
+| `input` | [string](/versions/8.4.2/rules/lib/core/string); or [Label](/versions/8.4.2/rules/lib/builtins/Label); required  The input label string or Label object. If a Label object is passed, it's returned as is. |
 
 ## repo\_name
 
@@ -191,6 +191,6 @@ Returns a new mutable list of every direct subpackage of the current package, re
 
 | Parameter | Description |
 | --- | --- |
-| `include` | [sequence](../core/list) of [string](../core/string)s; required |
-| `exclude` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  The list of glob patterns to exclude from subpackages scan. |
-| `allow_empty` | [bool](../core/bool); default is `False`  Whether we fail if the call returns an empty list. By default empty list indicates potential error in BUILD file where the call to subpackages() is superflous. Setting to true allows this function to succeed in that case. |*
\ No newline at end of file
+| `include` | [sequence](/versions/8.4.2/rules/lib/core/list) of [string](/versions/8.4.2/rules/lib/core/string)s; required |
+| `exclude` | [sequence](/versions/8.4.2/rules/lib/core/list) of [string](/versions/8.4.2/rules/lib/core/string)s; default is `[]`  The list of glob patterns to exclude from subpackages scan. |
+| `allow_empty` | [bool](/versions/8.4.2/rules/lib/core/bool); default is `False`  Whether we fail if the call returns an empty list. By default empty list indicates potential error in BUILD file where the call to subpackages() is superflous. Setting to true allows this function to succeed in that case. |*
\ No newline at end of file
diff --git a/versions/8.4.2/rules/lib/toplevel/platform_common.mdx b/versions/8.4.2/rules/lib/toplevel/platform_common.mdx
index 17edc7c5..afadf704 100644
--- a/versions/8.4.2/rules/lib/toplevel/platform_common.mdx
+++ b/versions/8.4.2/rules/lib/toplevel/platform_common.mdx
@@ -18,7 +18,7 @@ Functions for Starlark to interact with the platform APIs.
 Provider platform_common.ConstraintSettingInfo
 ```
 
-The constructor/key for the [ConstraintSettingInfo](../providers/ConstraintSettingInfo) provider.
+The constructor/key for the [ConstraintSettingInfo](/versions/8.4.2/rules/lib/providers/ConstraintSettingInfo) provider.
 *Note: This API is experimental and may change at any time. It is disabled by default, but may be enabled with `--experimental_platforms_api`*
 
 ## ConstraintValueInfo
@@ -27,7 +27,7 @@ The constructor/key for the [ConstraintSettingInfo](../providers/ConstraintSetti
 Provider platform_common.ConstraintValueInfo
 ```
 
-The constructor/key for the [ConstraintValueInfo](../providers/ConstraintValueInfo) provider.
+The constructor/key for the [ConstraintValueInfo](/versions/8.4.2/rules/lib/providers/ConstraintValueInfo) provider.
 *Note: This API is experimental and may change at any time. It is disabled by default, but may be enabled with `--experimental_platforms_api`*
 
 ## PlatformInfo
@@ -36,7 +36,7 @@ The constructor/key for the [ConstraintValueInfo](../providers/ConstraintValueIn
 Provider platform_common.PlatformInfo
 ```
 
-The constructor/key for the [PlatformInfo](../providers/PlatformInfo) provider.
+The constructor/key for the [PlatformInfo](/versions/8.4.2/rules/lib/providers/PlatformInfo) provider.
 *Note: This API is experimental and may change at any time. It is disabled by default, but may be enabled with `--experimental_platforms_api`*
 
 ## TemplateVariableInfo
@@ -45,7 +45,7 @@ The constructor/key for the [PlatformInfo](../providers/PlatformInfo) provider.
 Provider platform_common.TemplateVariableInfo
 ```
 
-The constructor/key for the [TemplateVariableInfo](../providers/TemplateVariableInfo) provider.
+The constructor/key for the [TemplateVariableInfo](/versions/8.4.2/rules/lib/providers/TemplateVariableInfo) provider.
 
 ## ToolchainInfo
 
@@ -53,4 +53,4 @@ The constructor/key for the [TemplateVariableInfo](../providers/TemplateVariable
 Provider platform_common.ToolchainInfo
 ```
 
-The constructor/key for the [ToolchainInfo](../providers/ToolchainInfo) provider.
\ No newline at end of file
+The constructor/key for the [ToolchainInfo](/versions/8.4.2/rules/lib/providers/ToolchainInfo) provider.
\ No newline at end of file
diff --git a/versions/8.4.2/rules/lib/toplevel/testing.mdx b/versions/8.4.2/rules/lib/toplevel/testing.mdx
index 5489113c..07bde9b0 100644
--- a/versions/8.4.2/rules/lib/toplevel/testing.mdx
+++ b/versions/8.4.2/rules/lib/toplevel/testing.mdx
@@ -24,12 +24,12 @@ The number of transitive dependencies of the test are limited. The limit is cont
 
 | Parameter | Description |
 | --- | --- |
-| `name` | [string](../core/string); required  Name of the target. It should be a Starlark identifier, matching pattern '[A-Za-z\_][A-Za-z0-9\_]\*'. |
-| `implementation` | [function](../core/function); required  The Starlark function implementing this analysis test. It must have exactly one parameter: [ctx](../builtins/ctx). The function is called during the analysis phase. It can access the attributes declared by `attrs` and populated via `attr_values`. The implementation function may not register actions. Instead, it must register a pass/fail result via providing [AnalysisTestResultInfo](../providers/AnalysisTestResultInfo). |
-| `attrs` | [dict](../core/dict); default is `{}`  Dictionary declaring the attributes. See the [rule](../globals/bzl#rule) call. Attributes are allowed to use configuration transitions defined using [analysis\_test\_transition](../globals/bzl#analysis_test_transition). |
-| `fragments` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  List of configuration fragments that are available to the implementation of the analysis test. |
-| `toolchains` | [sequence](../core/list); default is `[]`  The set of toolchains the test requires. See the [rule](../globals/bzl#rule) call. |
-| `attr_values` | [dict](../core/dict) of [string](../core/string)s; default is `{}`  Dictionary of attribute values to pass to the implementation. |
+| `name` | [string](/versions/8.4.2/rules/lib/core/string); required  Name of the target. It should be a Starlark identifier, matching pattern '[A-Za-z\_][A-Za-z0-9\_]\*'. |
+| `implementation` | [function](/versions/8.4.2/rules/lib/core/function); required  The Starlark function implementing this analysis test. It must have exactly one parameter: [ctx](/versions/8.4.2/rules/lib/builtins/ctx). The function is called during the analysis phase. It can access the attributes declared by `attrs` and populated via `attr_values`. The implementation function may not register actions. Instead, it must register a pass/fail result via providing [AnalysisTestResultInfo](/versions/8.4.2/rules/lib/providers/AnalysisTestResultInfo). |
+| `attrs` | [dict](/versions/8.4.2/rules/lib/core/dict); default is `{}`  Dictionary declaring the attributes. See the [rule](/versions/8.4.2/rules/lib/globals/bzl#rule) call. Attributes are allowed to use configuration transitions defined using [analysis\_test\_transition](/versions/8.4.2/rules/lib/globals/bzl#analysis_test_transition). |
+| `fragments` | [sequence](/versions/8.4.2/rules/lib/core/list) of [string](/versions/8.4.2/rules/lib/core/string)s; default is `[]`  List of configuration fragments that are available to the implementation of the analysis test. |
+| `toolchains` | [sequence](/versions/8.4.2/rules/lib/core/list); default is `[]`  The set of toolchains the test requires. See the [rule](/versions/8.4.2/rules/lib/globals/bzl#rule) call. |
+| `attr_values` | [dict](/versions/8.4.2/rules/lib/core/dict) of [string](/versions/8.4.2/rules/lib/core/string)s; default is `{}`  Dictionary of attribute values to pass to the implementation. |
 
 ## ExecutionInfo
 
@@ -37,7 +37,7 @@ The number of transitive dependencies of the test are limited. The limit is cont
 ExecutionInfo testing.ExecutionInfo
 ```
 
-[testing.ExecutionInfo](../providers/ExecutionInfo) provider key/constructor
+[testing.ExecutionInfo](/versions/8.4.2/rules/lib/providers/ExecutionInfo) provider key/constructor
 
 ## TestEnvironment
 
@@ -51,5 +51,5 @@ RunEnvironmentInfo testing.TestEnvironment(environment, inherited_environment=[]
 
 | Parameter | Description |
 | --- | --- |
-| `environment` | [dict](../core/dict); required  A map of string keys and values that represent environment variables and their values. These will be made available during the test execution. |
-| `inherited_environment` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  A sequence of names of environment variables. These variables are made available during the test execution with their current value taken from the shell environment. If a variable is contained in both `environment` and `inherited_environment`, the value inherited from the shell environment will take precedence if set. |
\ No newline at end of file
+| `environment` | [dict](/versions/8.4.2/rules/lib/core/dict); required  A map of string keys and values that represent environment variables and their values. These will be made available during the test execution. |
+| `inherited_environment` | [sequence](/versions/8.4.2/rules/lib/core/list) of [string](/versions/8.4.2/rules/lib/core/string)s; default is `[]`  A sequence of names of environment variables. These variables are made available during the test execution with their current value taken from the shell environment. If a variable is contained in both `environment` and `inherited_environment`, the value inherited from the shell environment will take precedence if set. |
\ No newline at end of file
diff --git a/versions/8.4.2/rules/macro-tutorial.mdx b/versions/8.4.2/rules/macro-tutorial.mdx
index ac0bd3a9..96c9152e 100644
--- a/versions/8.4.2/rules/macro-tutorial.mdx
+++ b/versions/8.4.2/rules/macro-tutorial.mdx
@@ -5,7 +5,7 @@ title: 'Creating a Symbolic Macro'
 IMPORTANT: This tutorial is for [*symbolic macros*](/versions/8.4.2/extending/macros) – the new
 macro system introduced in Bazel 8. If you need to support older Bazel versions,
 you will want to write a [legacy macro](/versions/8.4.2/extending/legacy-macros) instead; take
-a look at [Creating a Legacy Macro](../legacy-macro-tutorial).
+a look at [Creating a Legacy Macro](/versions/8.4.2/rules/legacy-macro-tutorial).
 
 Imagine that you need to run a tool as part of your build. For example, you
 may want to generate or preprocess a source file, or compress a binary. In this
diff --git a/versions/8.4.2/rules/performance.mdx b/versions/8.4.2/rules/performance.mdx
index bf79ab49..1ecb8069 100644
--- a/versions/8.4.2/rules/performance.mdx
+++ b/versions/8.4.2/rules/performance.mdx
@@ -15,7 +15,7 @@ widespread use.
 ## Use depsets {#use-depsets}
 
 Whenever you are rolling up information from rule dependencies you should use
-[depsets](lib/depset). Only use plain lists or dicts to publish information
+[depsets](/versions/8.4.2/rules/lib/builtins/depset). Only use plain lists or dicts to publish information
 local to the current rule.
 
 A depset represents information as a nested graph which enables sharing.
@@ -73,7 +73,7 @@ See the [depset overview](/versions/8.4.2/extending/depsets) page for more infor
 ### Avoid calling `depset.to_list()` {#avoid-depset-to-list}
 
 You can coerce a depset to a flat list using
-[`to_list()`](lib/depset#to_list), but doing so usually results in O(N^2)
+[`to_list()`](/versions/8.4.2/rules/lib/builtins/depset#to_list), but doing so usually results in O(N^2)
 cost. If at all possible, avoid any flattening of depsets except for debugging
 purposes.
 
@@ -115,7 +115,7 @@ x = depset(transitive = [i.deps for i in inputs])
 
 ## Use ctx.actions.args() for command lines {#ctx-actions-args}
 
-When building command lines you should use [ctx.actions.args()](lib/Args).
+When building command lines you should use [ctx.actions.args()](/versions/8.4.2/rules/lib/builtins/Args).
 This defers expansion of any depsets to the execution phase.
 
 Apart from being strictly faster, this will reduce the memory consumption of
@@ -126,11 +126,11 @@ Here are some tricks:
 * Pass depsets and lists directly as arguments, instead of flattening them
 yourself. They will get expanded by `ctx.actions.args()` for you.
 If you need any transformations on the depset contents, look at
-[ctx.actions.args#add](lib/Args#add) to see if anything fits the bill.
+[ctx.actions.args#add](/versions/8.4.2/rules/lib/builtins/Args#add) to see if anything fits the bill.
 
 * Are you passing `File#path` as arguments? No need. Any
-[File](lib/File) is automatically turned into its
-[path](lib/File#path), deferred to expansion time.
+[File](/versions/8.4.2/rules/lib/builtins/File) is automatically turned into its
+[path](/versions/8.4.2/rules/lib/builtins/File#path), deferred to expansion time.
 
 * Avoid constructing strings by concatenating them together.
 The best string argument is a constant as its memory will be shared between
@@ -138,10 +138,10 @@ all instances of your rule.
 
 * If the args are too long for the command line an `ctx.actions.args()` object
 can be conditionally or unconditionally written to a param file using
-[`ctx.actions.args#use_param_file`](lib/Args#use_param_file). This is
+[`ctx.actions.args#use_param_file`](/versions/8.4.2/rules/lib/builtins/Args#use_param_file). This is
 done behind the scenes when the action is executed. If you need to explicitly
 control the params file you can write it manually using
-[`ctx.actions.write`](lib/actions#write).
+[`ctx.actions.write`](/versions/8.4.2/rules/lib/builtins/actions#write).
 
 Example:
 
@@ -176,7 +176,7 @@ def _to_short_path(f):
 
 ## Transitive action inputs should be depsets {#transitive-action-inputs}
 
-When building an action using [ctx.actions.run](lib/actions?#run), do not
+When building an action using [ctx.actions.run](/versions/8.4.2/rules/lib/builtins/actions#run), do not
 forget that the `inputs` field accepts a depset. Use this whenever inputs are
 collected from dependencies transitively.
 
diff --git a/versions/8.4.2/rules/rules-tutorial.mdx b/versions/8.4.2/rules/rules-tutorial.mdx
index 2bdbff34..d85ff5f4 100644
--- a/versions/8.4.2/rules/rules-tutorial.mdx
+++ b/versions/8.4.2/rules/rules-tutorial.mdx
@@ -31,9 +31,9 @@ foo_binary = rule(
 )
 ```
 
-When you call the [`rule`](lib/globals#rule) function, you
+When you call the [`rule`](/versions/8.4.2/rules/lib/globals#rule) function, you
 must define a callback function. The logic will go there, but you
-can leave the function empty for now. The [`ctx`](lib/ctx) argument
+can leave the function empty for now. The [`ctx`](/versions/8.4.2/rules/lib/builtins/ctx) argument
 provides information about the target.
 
 You can load the rule and use it from a `BUILD` file.
@@ -86,10 +86,10 @@ foo_binary(name = "bin1")
 foo_binary(name = "bin2")
 ```
 
-[`ctx.label`](lib/ctx#label)
+[`ctx.label`](/versions/8.4.2/rules/lib/builtins/ctx#label)
 corresponds to the label of the target being analyzed. The `ctx` object has
 many useful fields and methods; you can find an exhaustive list in the
-[API reference](lib/ctx).
+[API reference](/versions/8.4.2/rules/lib/builtins/ctx).
 
 Query the code:
 
@@ -145,7 +145,7 @@ bin2
 ```
 
 Whenever you declare a file, you have to tell Bazel how to generate it by
-creating an action. Use [`ctx.actions.write`](lib/actions#write),
+creating an action. Use [`ctx.actions.write`](/versions/8.4.2/rules/lib/builtins/actions#write),
 to create a file with the given content.
 
 ```python
@@ -200,7 +200,7 @@ You have successfully generated a file!
 ## Attributes
 
 To make the rule more useful, add new attributes using
-[the `attr` module](lib/attr) and update the rule definition.
+[the `attr` module](/versions/8.4.2/rules/lib/toplevel/attr) and update the rule definition.
 
 Add a string attribute called `username`:
 
@@ -236,22 +236,22 @@ def _foo_binary_impl(ctx):
 ```
 
 Note that you can make the attribute mandatory or set a default value. Look at
-the documentation of [`attr.string`](lib/attr#string).
-You may also use other types of attributes, such as [boolean](lib/attr#bool)
-or [list of integers](lib/attr#int_list).
+the documentation of [`attr.string`](/versions/8.4.2/rules/lib/toplevel/attr#string).
+You may also use other types of attributes, such as [boolean](/versions/8.4.2/rules/lib/toplevel/attr#bool)
+or [list of integers](/versions/8.4.2/rules/lib/toplevel/attr#int_list).
 
 ## Dependencies
 
-Dependency attributes, such as [`attr.label`](lib/attr#label)
-and [`attr.label_list`](lib/attr#label_list),
+Dependency attributes, such as [`attr.label`](/versions/8.4.2/rules/lib/toplevel/attr#label)
+and [`attr.label_list`](/versions/8.4.2/rules/lib/toplevel/attr#label_list),
 declare a dependency from the target that owns the attribute to the target whose
 label appears in the attribute's value. This kind of attribute forms the basis
 of the target graph.
 
 In the `BUILD` file, the target label appears as a string object, such as
 `//pkg:name`. In the implementation function, the target will be accessible as a
-[`Target`](lib/Target) object. For example, view the files returned
-by the target using [`Target.files`](lib/Target#modules.Target.files).
+[`Target`](/versions/8.4.2/rules/lib/builtins/Target) object. For example, view the files returned
+by the target using [`Target.files`](/versions/8.4.2/rules/lib/builtins/Target#modules.Target.files).
 
 ### Multiple files
 
@@ -294,7 +294,7 @@ implementation function, but this has two problems. First, as the template gets
 bigger, it becomes more memory efficient to put it in a separate file and avoid
 constructing large strings during the analysis phase. Second, using a separate
 file is more convenient for the user. Instead, use
-[`ctx.actions.expand_template`](lib/actions#expand_template),
+[`ctx.actions.expand_template`](/versions/8.4.2/rules/lib/builtins/actions#expand_template),
 which performs substitutions on a template file.
 
 Create a `template` attribute to declare a dependency on the template
diff --git a/versions/8.4.2/rules/testing.mdx b/versions/8.4.2/rules/testing.mdx
index 27e89306..b89b723f 100644
--- a/versions/8.4.2/rules/testing.mdx
+++ b/versions/8.4.2/rules/testing.mdx
@@ -234,7 +234,7 @@ def _inspect_actions_test_impl(ctx):
 ```
 
 Note that `analysistest.target_actions(env)` returns a list of
-[`Action`](lib/Action) objects which represent actions registered by the
+[`Action`](/versions/8.4.2/rules/lib/builtins/Action) objects which represent actions registered by the
 target under test.
 
 ### Verifying rule behavior under different flags {#verifying-rule-behavior}
diff --git a/versions/8.4.2/rules/verbs-tutorial.mdx b/versions/8.4.2/rules/verbs-tutorial.mdx
index 707b00da..9aa3f821 100644
--- a/versions/8.4.2/rules/verbs-tutorial.mdx
+++ b/versions/8.4.2/rules/verbs-tutorial.mdx
@@ -49,8 +49,7 @@ This pattern can also be seen in the Angular project. The
 produces two targets. The first is a standard `nodejs_test` target which compares
 some generated output against a "golden" file (that is, a file containing the
 expected output). This can be built and run with a normal `bazel
-test` invocation. In `angular-cli`, you can run [one such
-target](https://github.com/angular/angular-cli/blob/e1269cb520871ee29b1a4eec6e6c0e4a94f0b5fc/etc/api/BUILD)
+test` invocation. In `angular-cli`, you can run [one such target](https://github.com/angular/angular-cli/blob/e1269cb520871ee29b1a4eec6e6c0e4a94f0b5fc/etc/api/BUILD)
 with `bazel test //etc/api:angular_devkit_core_api`.
 
 Over time, this golden file may need to be updated for legitimate reasons.
@@ -159,7 +158,7 @@ an imaginary `bazel publish` command.
 It's not immediately obvious what the implementation of the `_sphinx_publisher`
 rule might look like. Often, actions like this write a _launcher_ shell script.
 This method typically involves using
-[`ctx.actions.expand_template`](lib/actions#expand_template)
+[`ctx.actions.expand_template`](/versions/8.4.2/rules/lib/builtins/actions#expand_template)
 to write a very simple shell script, in this case invoking the publisher binary
 with a path to the output of the primary target. This way, the publisher
 implementation can remain generic, the `_sphinx_site` rule can just produce
diff --git a/versions/8.4.2/run/build.mdx b/versions/8.4.2/run/build.mdx
index 8019e019..43ee0190 100644
--- a/versions/8.4.2/run/build.mdx
+++ b/versions/8.4.2/run/build.mdx
@@ -626,8 +626,7 @@ Note: Hermeticity means that the action only uses its declared input
 files and no other files in the filesystem, and it only produces its declared
 output files. See [Hermeticity](/versions/8.4.2/basics/hermeticity) for more details.
 
-On some platforms such as [Google Kubernetes
-Engine](https://cloud.google.com/kubernetes-engine/) cluster nodes or Debian,
+On some platforms such as [Google Kubernetes Engine](https://cloud.google.com/kubernetes-engine/) cluster nodes or Debian,
 user namespaces are deactivated by default due to security
 concerns. This can be checked by looking at the file
 `/proc/sys/kernel/unprivileged_userns_clone`: if it exists and contains a 0,
diff --git a/versions/8.4.2/start/android-app.mdx b/versions/8.4.2/start/android-app.mdx
index 8bac659e..dbe20e8c 100644
--- a/versions/8.4.2/start/android-app.mdx
+++ b/versions/8.4.2/start/android-app.mdx
@@ -36,8 +36,7 @@ In this tutorial you learn how to:
 Before you begin the tutorial, install the following software:
 
 * **Bazel.** To install, follow the [installation instructions](/versions/8.4.2/install).
-* **Android Studio.** To install, follow the steps to [download Android
-  Studio](https://developer.android.com/sdk/index.html).
+* **Android Studio.** To install, follow the steps to [download Android Studio](https://developer.android.com/sdk/index.html).
   Execute the setup wizard to download the SDK and configure your environment.
 * (Optional) **Git.** Use `git` to download the Android app project.
 
@@ -52,8 +51,7 @@ This app has a single button that prints a greeting when clicked:
 
 **Figure 1.** Android app button greeting.
 
-Clone the repository with `git` (or [download the ZIP file
-directly](https://github.com/bazelbuild/examples/archive/master.zip)):
+Clone the repository with `git` (or [download the ZIP file directly](https://github.com/bazelbuild/examples/archive/master.zip)):
 
 ```posix-terminal
 git clone https://github.com/bazelbuild/examples
@@ -103,8 +101,7 @@ A [workspace](/versions/8.4.2/concepts/build-ref#workspace) is a directory that
 source files for one or more software projects, and has a `MODULE.bazel` file at
 its root.
 
-The `MODULE.bazel` file may be empty or may contain references to [external
-dependencies](/versions/8.4.2/external/overview) required to build your project.
+The `MODULE.bazel` file may be empty or may contain references to [external dependencies](/versions/8.4.2/external/overview) required to build your project.
 
 First, run the following command to create an empty `MODULE.bazel` file:
 
@@ -147,8 +144,7 @@ environment variable, and automatically detect the highest API level and the
 latest version of build tools installed within that location.
 
 You can set the `ANDROID_HOME` variable to the location of the Android SDK. Find
-the path to the installed SDK using Android Studio's [SDK
-Manager](https://developer.android.com/studio/intro/update#sdk-manager).
+the path to the installed SDK using Android Studio's [SDK Manager](https://developer.android.com/studio/intro/update#sdk-manager).
 Assuming the SDK is installed to default locations, you can use the following
 commands to set the `ANDROID_HOME` variable:
 
@@ -170,16 +166,14 @@ them permanent, run the following commands:
 | Windows (PowerShell)     | `[System.Environment]::SetEnvironmentVariable('ANDROID_HOME', "$env:LOCALAPPDATA\Android\Sdk", [System.EnvironmentVariableTarget]::User)` |
 
 **Optional:** If you want to compile native code into your Android app, you
-also need to download the [Android
-NDK](https://developer.android.com/ndk/downloads/index.html)
+also need to download the [Android NDK](https://developer.android.com/ndk/downloads/index.html)
 and use `rules_android_ndk` by adding the following line to your `MODULE.bazel` file:
 
 ```python
 bazel_dep(name = "rules_android_ndk", version = "0.1.2")
 ```
 
-For more information, read [Using the Android Native Development Kit with
-Bazel](/versions/8.4.2/docs/android-ndk).
+For more information, read [Using the Android Native Development Kit with Bazel](/versions/8.4.2/docs/android-ndk).
 
 It's not necessary to set the API levels to the same value for the SDK and NDK.
 [This page](https://developer.android.com/ndk/guides/stable_apis.html)
@@ -221,8 +215,7 @@ files or other dependencies. Bazel provides two build rules,
 build an Android app.
 
 For this tutorial, you'll first use the
-`android_library` rule to tell Bazel to build an [Android library
-module](http://developer.android.com/tools/projects/index.html#LibraryProjects)
+`android_library` rule to tell Bazel to build an [Android library module](http://developer.android.com/tools/projects/index.html#LibraryProjects)
 from the app source code and resource files. You'll then use the
 `android_binary` rule to tell Bazel how to build the Android application package.
 
@@ -337,11 +330,9 @@ file:
 ### Run the app
 
 You can now deploy the app to a connected Android device or emulator from the
-command line using the [`bazel
-mobile-install`](/versions/8.4.2/docs/user-manual#mobile-install) command. This command uses
+command line using the [`bazel mobile-install`](/versions/8.4.2/docs/user-manual#mobile-install) command. This command uses
 the Android Debug Bridge (`adb`) to communicate with the device. You must set up
-your device to use `adb` following the instructions in [Android Debug
-Bridge](http://developer.android.com/tools/help/adb.html) before deployment. You
+your device to use `adb` following the instructions in [Android Debug Bridge](http://developer.android.com/tools/help/adb.html) before deployment. You
 can also choose to install the app on the Android emulator included in Android
 Studio. Make sure the emulator is running before executing the command below.
 
diff --git a/versions/8.4.2/start/cpp.mdx b/versions/8.4.2/start/cpp.mdx
index 435bf46d..20dccdd1 100644
--- a/versions/8.4.2/start/cpp.mdx
+++ b/versions/8.4.2/start/cpp.mdx
@@ -19,8 +19,7 @@ Estimated completion time: 30 minutes.
 ### Prerequisites {#prerequisites}
 
 Start by [installing Bazel](https://bazel.build/versions/8.4.2/install), if you haven't
-already. This tutorial uses Git for source control, so for best results [install
-Git](https://git-scm.com/book/en/v2/Getting-Started-Installing-Git) as well.
+already. This tutorial uses Git for source control, so for best results [install Git](https://git-scm.com/book/en/v2/Getting-Started-Installing-Git) as well.
 
 Next, retrieve the sample project from Bazel's GitHub repository by running the
 following in your command-line tool of choice:
@@ -63,9 +62,7 @@ examples
 ```
 
 There are three sets of files, each set representing a stage in this tutorial.
-In the first stage, you will build a single [target]
-(https://bazel.build/reference/glossary#target) residing in a single [package]
-(https://bazel.build/reference/glossary#package). In the second stage, you will
+In the first stage, you will build a single [target](https://bazel.build/versions/8.4.2/reference/glossary#target) residing in a single [package](https://bazel.build/versions/8.4.2/reference/glossary#package). In the second stage, you will
 build both a binary and a library from a single package. In the third and final
 stage, you will build a project with multiple packages and build it with
 multiple targets.
@@ -86,8 +83,7 @@ It also contains these significant files:
 *   The `MODULE.bazel` file, which identifies the directory and its contents as
     a Bazel workspace and lives at the root of the project's directory
     structure. It's also where you specify your external dependencies.
-*   One or more [`BUILD`
-    files](https://bazel.build/reference/glossary#build-file), which tell Bazel
+*   One or more [`BUILD` files](https://bazel.build/versions/8.4.2/reference/glossary#build-file), which tell Bazel
     how to build different parts of the project. A directory within the
     workspace that contains a `BUILD` file is a
     [package](https://bazel.build/versions/8.4.2/reference/glossary#package). (More on packages
@@ -182,9 +178,7 @@ This results in a printed "`Hello world`" message.
 
 Here's the dependency graph of Stage 1:
 
-![Dependency graph for hello-world displays a single target with a single source
-file.](/versions/8.4.2/docs/images/cpp-tutorial-stage1.png "Dependency graph for hello-world
-displays a single target with a single source file.")
+![Dependency graph for hello-world displays a single target with a single source file.](/versions/8.4.2/docs/images/cpp-tutorial-stage1.png "Dependency graph for hello-world displays a single target with a single source file.")
 
 ### Summary: stage 1 {#summary-stage-1}
 
@@ -231,8 +225,7 @@ cc_binary(
 ```
 
 With this `BUILD` file, Bazel first builds the `hello-greet` library (using
-Bazel's built-in [`cc_library`
-rule](https://bazel.build/reference/be/c-cpp#cc_library)), then the
+Bazel's built-in [`cc_library` rule](https://bazel.build/versions/8.4.2/reference/be/c-cpp#cc_library)), then the
 `hello-world` binary. The `deps` attribute in the `hello-world` target tells
 Bazel that the `hello-greet` library is required to build the `hello-world`
 binary.
@@ -272,10 +265,7 @@ recompiles that file.
 Looking at the dependency graph, you can see that `hello-world` depends on an
 extra input named `hello-greet`:
 
-![Dependency graph for `hello-world` displays dependency changes after
-modification to the file.](/versions/8.4.2/docs/images/cpp-tutorial-stage2.png "Dependency
-graph for `hello-world` displays dependency changes after modification to the
-file.")
+![Dependency graph for `hello-world` displays dependency changes after modification to the file.](/versions/8.4.2/docs/images/cpp-tutorial-stage2.png "Dependency graph for `hello-world` displays dependency changes after modification to the file.")
 
 ### Summary: stage 2 {#summary-stage-2}
 
@@ -343,11 +333,7 @@ in the `lib` package (hence the target label `//lib:hello-time`) - Bazel knows
 this through the `deps` attribute. You can see this reflected in the dependency
 graph:
 
-![Dependency graph for `hello-world` displays how the target in the main package
-depends on the target in the `lib`
-package.](/versions/8.4.2/docs/images/cpp-tutorial-stage3.png "Dependency graph for
-`hello-world` displays how the target in the main package depends on the target
-in the `lib` package.")
+![Dependency graph for `hello-world` displays how the target in the main package depends on the target in the `lib` package.](/versions/8.4.2/docs/images/cpp-tutorial-stage3.png "Dependency graph for `hello-world` displays how the target in the main package depends on the target in the `lib` package.")
 
 For the build to succeed, you make the `//lib:hello-time` target in `lib/BUILD`
 explicitly visible to targets in `main/BUILD` using the visibility attribute.
@@ -395,15 +381,11 @@ Bazel journey.
 You've now completed your first basic build with Bazel, but this is just the
 start. Here are some more resources to continue learning with Bazel:
 
-*   To keep focusing on C++, read about common [C++ build use
-    cases](https://bazel.build/tutorials/cpp-use-cases).
+*   To keep focusing on C++, read about common [C++ build use cases](https://bazel.build/versions/8.4.2/tutorials/cpp-use-cases).
 *   To get started with building other applications with Bazel, see the
-    tutorials for [Java](https://bazel.build/versions/8.4.2/start/java), [Android
-    application](https://bazel.build/start/android-app), or [iOS
-    application](https://bazel.build/start/ios-app).
+    tutorials for [Java](https://bazel.build/versions/8.4.2/start/java), [Android application](https://bazel.build/versions/8.4.2/start/android-app), or [iOS application](https://bazel.build/versions/8.4.2/start/ios-app).
 *   To learn more about working with local and remote repositories, read about
     [external dependencies](https://bazel.build/versions/8.4.2/docs/external).
-*   To learn more about Bazel's other rules, see this [reference
-    guide](https://bazel.build/rules).
+*   To learn more about Bazel's other rules, see this [reference guide](https://bazel.build/versions/8.4.2/rules).
 
 Happy building!
\ No newline at end of file
diff --git a/versions/8.4.2/start/java.mdx b/versions/8.4.2/start/java.mdx
index 2db06d40..130faaf3 100644
--- a/versions/8.4.2/start/java.mdx
+++ b/versions/8.4.2/start/java.mdx
@@ -241,8 +241,7 @@ recompiles that file.
 Looking at the dependency graph, you can see that `ProjectRunner` depends on the
 same inputs as it did before, but the structure of the build is different:
 
-![Dependency graph of the target 'ProjectRunner' after adding a dependency](
-/docs/images/tutorial_java_02.svg)
+![Dependency graph of the target 'ProjectRunner' after adding a dependency](/versions/8.4.2/docs/images/tutorial_java_02.svg)
 
 You've now built the project with two targets. The `ProjectRunner` target builds
 one source files and depends on one other target (`:greeter`), which builds
@@ -426,7 +425,7 @@ For more details, see:
 *  The [C++ build tutorial](/versions/8.4.2/start/cpp) to get started with building
    C++ projects with Bazel.
 
-*  The [Android application tutorial](/versions/8.4.2/start/android-app ) and
+*  The [Android application tutorial](/versions/8.4.2/start/android-app) and
    [iOS application tutorial](/versions/8.4.2/start/ios-app)) to get started with
    building mobile applications for Android and iOS with Bazel.
 
diff --git a/versions/8.4.2/tutorials/ccp-toolchain-config.mdx b/versions/8.4.2/tutorials/ccp-toolchain-config.mdx
index 40952f56..16b87ba9 100644
--- a/versions/8.4.2/tutorials/ccp-toolchain-config.mdx
+++ b/versions/8.4.2/tutorials/ccp-toolchain-config.mdx
@@ -29,8 +29,7 @@ uses `clang version 16`, which you can install on your system.
 
 Set up your build environment as follows:
 
-1.  If you have not already done so, [download and install Bazel
-    7.0.2](https://bazel.build/install) or later.
+1.  If you have not already done so, [download and install Bazel 7.0.2](https://bazel.build/versions/8.4.2/install) or later.
 
 2.  Add an empty `MODULE.bazel` file at the root folder.
 
@@ -450,8 +449,7 @@ The key takeaways are:
 
 -   You need to specify a matching `platforms` flag in the command line for
     Bazel to resolve to the toolchain for the same constraint values on the
-    platform. The documentation holds more [information about language specific
-    configuration flags](/versions/8.4.2/concepts/platforms).
+    platform. The documentation holds more [information about language specific configuration flags](/versions/8.4.2/concepts/platforms).
 -   You have to let the toolchain know where the tools live. In this tutorial
     there is a simplified version where you access the tools from the system. If
     you are interested in a more self-contained approach, you can read about
@@ -464,5 +462,4 @@ The key takeaways are:
 
 ## Further reading {#further-reading}
 
-For more details, see [C++ toolchain
-configuration](/versions/8.4.2/docs/cc-toolchain-config-reference)
\ No newline at end of file
+For more details, see [C++ toolchain configuration](/versions/8.4.2/docs/cc-toolchain-config-reference)
\ No newline at end of file
diff --git a/versions/8.5.1/about/roadmap.mdx b/versions/8.5.1/about/roadmap.mdx
index c86f27da..3b997e16 100644
--- a/versions/8.5.1/about/roadmap.mdx
+++ b/versions/8.5.1/about/roadmap.mdx
@@ -13,8 +13,7 @@ projects.
 
 ## Bazel 8.0 Release
 
-We plan to bring Bazel 8.0 [long term support
-(LTS)](https://bazel.build/release/versioning) to you in late 2024.
+We plan to bring Bazel 8.0 [long term support (LTS)](https://bazel.build/versions/8.5.1/release/versioning) to you in late 2024.
 The following features are planned to be implemented.
 
 ### Bzlmod: external dependency management system
@@ -29,8 +28,7 @@ support will be removed. Starting with Bazel 7.1, you can set
 `--noenable_workspace` to opt into the new behavior.
 
 Bazel 8.0 will contain a number of enhancements to
-[Bazel's external dependency management]
-(https://docs.google.com/document/d/1moQfNcEIttsk6vYanNKIy3ZuK53hQUFq1b1r0rmsYVg/edit#heading=h.lgyp7ubwxmjc)
+[Bazel's external dependency management](https://docs.google.com/document/d/1moQfNcEIttsk6vYanNKIy3ZuK53hQUFq1b1r0rmsYVg/edit#heading=h.lgyp7ubwxmjc)
 functionality, including:
 
 *   The new flag `--enable_workspace` can be set to `false` to completely
diff --git a/versions/8.5.1/basics/dependencies.mdx b/versions/8.5.1/basics/dependencies.mdx
index 82667e8d..06af7914 100644
--- a/versions/8.5.1/basics/dependencies.mdx
+++ b/versions/8.5.1/basics/dependencies.mdx
@@ -65,8 +65,7 @@ targets, we’ve made some strides in mitigating the downside by investing in
 tooling to automatically manage `BUILD` files to avoid burdening developers.
 
 Some of these tools, such as `buildifier` and `buildozer`, are available with
-Bazel in the [`buildtools`
-directory](https://github.com/bazelbuild/buildtools).
+Bazel in the [`buildtools` directory](https://github.com/bazelbuild/buildtools).
 
 ## Minimizing Module Visibility
 
@@ -106,8 +105,7 @@ transitive dependencies (Figure 1). Suppose target A depends on target B, which
 depends on a common library target C. Should target A be able to use classes
 defined in target C?
 
-[![Transitive
-dependencies](/versions/8.5.1/images/transitive-dependencies.png)](/versions/8.5.1/images/transitive-dependencies.png)
+[![Transitive dependencies](/versions/8.5.1/images/transitive-dependencies.png)](/versions/8.5.1/images/transitive-dependencies.png)
 
 **Figure 1**. Transitive dependencies
 
@@ -141,9 +139,7 @@ dependencies and adding them to a `BUILD` files without any developer
 intervention. But even without such tools, we’ve found the trade-off to be well
 worth it as the codebase scales: explicitly adding a dependency to `BUILD` file
 is a one-time cost, but dealing with implicit transitive dependencies can cause
-ongoing problems as long as the build target exists. Bazel [enforces strict
-transitive
-dependencies](https://blog.bazel.build/2017/06/28/sjd-unused_deps.html)
+ongoing problems as long as the build target exists. Bazel [enforces strict transitive dependencies](https://blog.bazel.build/2017/06/28/sjd-unused_deps.html)
 on Java code by default.
 
 ### External dependencies
@@ -192,8 +188,7 @@ so in theory there’s no reason that different versions of the same external
 dependency couldn’t both be declared in the build system under different names.
 That way, each target could choose which version of the dependency it wanted to
 use. This causes a lot of problems in practice, so Google enforces a strict
-[One-Version
-Rule](https://opensource.google/docs/thirdparty/oneversion/) for
+[One-Version Rule](https://opensource.google/docs/thirdparty/oneversion/) for
 all third-party dependencies in our codebase.
 
 The biggest problem with allowing multiple versions is the diamond dependency
@@ -232,8 +227,7 @@ Bazel did not use to automatically download transitive dependencies. It used to
 employ a `WORKSPACE` file that required all transitive dependencies to be
 listed, which led to a lot of pain when managing external dependencies. Bazel
 has since added support for automatic transitive external dependency management
-in the form of the `MODULE.bazel` file. See [external dependency
-overview](/versions/8.5.1/external/overview) for more details.
+in the form of the `MODULE.bazel` file. See [external dependency overview](/versions/8.5.1/external/overview) for more details.
 
 Yet again, the choice here is one between convenience and scalability. Small
 projects might prefer not having to worry about managing transitive dependencies
diff --git a/versions/8.5.1/community/images/Bitrise.png b/versions/8.5.1/community/images/Bitrise.png
new file mode 100644
index 00000000..07f85f1e
Binary files /dev/null and b/versions/8.5.1/community/images/Bitrise.png differ
diff --git a/versions/8.5.1/community/images/Gradle.png b/versions/8.5.1/community/images/Gradle.png
new file mode 100644
index 00000000..1e5f5eb0
Binary files /dev/null and b/versions/8.5.1/community/images/Gradle.png differ
diff --git a/versions/8.5.1/community/images/Linkedin-Logo.png b/versions/8.5.1/community/images/Linkedin-Logo.png
new file mode 100644
index 00000000..9dd8715c
Binary files /dev/null and b/versions/8.5.1/community/images/Linkedin-Logo.png differ
diff --git a/versions/8.5.1/community/images/Lucid_Software-logo.svg b/versions/8.5.1/community/images/Lucid_Software-logo.svg
new file mode 100644
index 00000000..6c8591e0
--- /dev/null
+++ b/versions/8.5.1/community/images/Lucid_Software-logo.svg
@@ -0,0 +1,16 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/versions/8.5.1/community/images/acqio_logo.svg b/versions/8.5.1/community/images/acqio_logo.svg
new file mode 100644
index 00000000..8fa11bcd
--- /dev/null
+++ b/versions/8.5.1/community/images/acqio_logo.svg
@@ -0,0 +1,60 @@
+
+
+
+
+
+	
+		
+			
+				
+					
+					
+					
+					
+					
+				
+				
+					
+						
+							
+								
+							
+						
+					
+				
+				
+					
+						
+							
+								
+							
+						
+					
+				
+			
+		
+	
+
+
diff --git a/versions/8.5.1/community/images/aspect-logo-2.png b/versions/8.5.1/community/images/aspect-logo-2.png
new file mode 100644
index 00000000..dfebc4cb
Binary files /dev/null and b/versions/8.5.1/community/images/aspect-logo-2.png differ
diff --git a/versions/8.5.1/community/images/bitrise-logo.png b/versions/8.5.1/community/images/bitrise-logo.png
new file mode 100644
index 00000000..27037ce6
Binary files /dev/null and b/versions/8.5.1/community/images/bitrise-logo.png differ
diff --git a/versions/8.5.1/community/images/buildbuddy-logo.svg b/versions/8.5.1/community/images/buildbuddy-logo.svg
new file mode 100644
index 00000000..bdb72dc6
--- /dev/null
+++ b/versions/8.5.1/community/images/buildbuddy-logo.svg
@@ -0,0 +1,11 @@
+
+
+
+
+
+
+
+
+
+
+
diff --git a/versions/8.5.1/community/images/buildkite.svg b/versions/8.5.1/community/images/buildkite.svg
new file mode 100644
index 00000000..209a4ab1
--- /dev/null
+++ b/versions/8.5.1/community/images/buildkite.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/8.5.1/community/images/codethink-logo.svg b/versions/8.5.1/community/images/codethink-logo.svg
new file mode 100644
index 00000000..406005d8
--- /dev/null
+++ b/versions/8.5.1/community/images/codethink-logo.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/8.5.1/community/images/develocity.png b/versions/8.5.1/community/images/develocity.png
new file mode 100644
index 00000000..eb3eb65a
Binary files /dev/null and b/versions/8.5.1/community/images/develocity.png differ
diff --git a/versions/8.5.1/community/images/dropbox.png b/versions/8.5.1/community/images/dropbox.png
new file mode 100644
index 00000000..125476a6
Binary files /dev/null and b/versions/8.5.1/community/images/dropbox.png differ
diff --git a/versions/8.5.1/community/images/engflow-logo.svg b/versions/8.5.1/community/images/engflow-logo.svg
new file mode 100644
index 00000000..e5f0c343
--- /dev/null
+++ b/versions/8.5.1/community/images/engflow-logo.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/8.5.1/community/images/epam-logo.png b/versions/8.5.1/community/images/epam-logo.png
new file mode 100644
index 00000000..e6a5674c
Binary files /dev/null and b/versions/8.5.1/community/images/epam-logo.png differ
diff --git a/versions/8.5.1/community/images/flare-logo.png b/versions/8.5.1/community/images/flare-logo.png
new file mode 100644
index 00000000..84cb0e5b
Binary files /dev/null and b/versions/8.5.1/community/images/flare-logo.png differ
diff --git a/versions/8.5.1/community/images/hermetiq-logo.png b/versions/8.5.1/community/images/hermetiq-logo.png
new file mode 100644
index 00000000..90765d96
Binary files /dev/null and b/versions/8.5.1/community/images/hermetiq-logo.png differ
diff --git a/versions/8.5.1/community/images/jetbrains.svg b/versions/8.5.1/community/images/jetbrains.svg
new file mode 100644
index 00000000..cb3a2a0e
--- /dev/null
+++ b/versions/8.5.1/community/images/jetbrains.svg
@@ -0,0 +1,13 @@
+
+  
+    
+      
+      
+      
+    
+  
+  
+  
+  
+  
+
diff --git a/versions/8.5.1/community/images/liulishuo.png b/versions/8.5.1/community/images/liulishuo.png
new file mode 100644
index 00000000..a6758e5c
Binary files /dev/null and b/versions/8.5.1/community/images/liulishuo.png differ
diff --git a/versions/8.5.1/community/images/nativelink.svg b/versions/8.5.1/community/images/nativelink.svg
new file mode 100644
index 00000000..148fcdce
--- /dev/null
+++ b/versions/8.5.1/community/images/nativelink.svg
@@ -0,0 +1,1123 @@
+
+
+  
+    
+    
+      
+      
+    
+    
+      
+      
+    
+    
+    
+      
+      
+    
+    
+      
+      
+      
+      
+      
+      
+      
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+      
+      
+    
+    
+    
+    
+      
+      
+    
+    
+    
+    
+      
+      
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+      
+      
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+      
+      
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+      
+      
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+      
+      
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+      
+      
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+      
+      
+    
+  
+  
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+  
+  
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+  
+
diff --git a/versions/8.5.1/community/images/oasis-logo.png b/versions/8.5.1/community/images/oasis-logo.png
new file mode 100644
index 00000000..846a9cd5
Binary files /dev/null and b/versions/8.5.1/community/images/oasis-logo.png differ
diff --git a/versions/8.5.1/community/images/sumglobal-logo.png b/versions/8.5.1/community/images/sumglobal-logo.png
new file mode 100644
index 00000000..6736328d
Binary files /dev/null and b/versions/8.5.1/community/images/sumglobal-logo.png differ
diff --git a/versions/8.5.1/community/images/trunk-logo-dark.svg b/versions/8.5.1/community/images/trunk-logo-dark.svg
new file mode 100644
index 00000000..f25940af
--- /dev/null
+++ b/versions/8.5.1/community/images/trunk-logo-dark.svg
@@ -0,0 +1,22 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/versions/8.5.1/community/images/tweag-logo.png b/versions/8.5.1/community/images/tweag-logo.png
new file mode 100644
index 00000000..20210ed7
Binary files /dev/null and b/versions/8.5.1/community/images/tweag-logo.png differ
diff --git a/versions/8.5.1/community/images/typedb.png b/versions/8.5.1/community/images/typedb.png
new file mode 100644
index 00000000..48ce1056
Binary files /dev/null and b/versions/8.5.1/community/images/typedb.png differ
diff --git a/versions/8.5.1/community/images/virtuslab.svg b/versions/8.5.1/community/images/virtuslab.svg
new file mode 100644
index 00000000..6fba0316
--- /dev/null
+++ b/versions/8.5.1/community/images/virtuslab.svg
@@ -0,0 +1,20 @@
+
+
+  
+    
+  
+  
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+  
+
diff --git a/versions/8.5.1/community/roadmaps-configurability.mdx b/versions/8.5.1/community/roadmaps-configurability.mdx
index b516dd59..23ba0d45 100644
--- a/versions/8.5.1/community/roadmaps-configurability.mdx
+++ b/versions/8.5.1/community/roadmaps-configurability.mdx
@@ -26,8 +26,7 @@ title: 'Bazel Configurability 2021 Roadmap'
 * Builds scale well, particularly w.r.t graph size and action caching.
 
 We also support
-[`cquery`](https://bazel.build/versions/8.5.1/query/cquery), [`Starlark
-configuration`](https://bazel.build/extending/config),
+[`cquery`](https://bazel.build/versions/8.5.1/query/cquery), [`Starlark configuration`](https://bazel.build/versions/8.5.1/extending/config),
 and
 [`select()`](https://bazel.build/versions/8.5.1/docs/configurable-attributes).
 
@@ -41,15 +40,13 @@ interest of accurate expectations.
 ### Platforms
 
 

-Q3 2021**Android rules use the new [platforms
-API](https://bazel.build/concepts/platforms)**
+Q3 2021**Android rules use the new [platforms API](https://bazel.build/versions/8.5.1/concepts/platforms)**
 IN PROGRESS ([#11749](https://github.com/bazelbuild/bazel/issues/11749))
 
 * This is our main priority for the beginning of 2021.
 
 

-Q3 2021**Builds support [multiple execution
-platforms](https://docs.google.com/document/d/1U9HzdDmtRnm244CaRM6JV-q2408mbNODAMewcGjnnbM/)**
+Q3 2021**Builds support [multiple execution platforms](https://docs.google.com/document/d/1U9HzdDmtRnm244CaRM6JV-q2408mbNODAMewcGjnnbM/)**
 IN PROGRESS ([#11748](https://github.com/bazelbuild/bazel/issues/11748))
 
 

diff --git a/versions/8.5.1/community/sig.mdx b/versions/8.5.1/community/sig.mdx
index a99f246a..b4643dd9 100644
--- a/versions/8.5.1/community/sig.mdx
+++ b/versions/8.5.1/community/sig.mdx
@@ -3,8 +3,7 @@ title: 'Bazel Special Interest Groups'
 ---
 
 Bazel hosts Special Interest Groups (SIGs) to focus collaboration on particular
-areas and to support communication and coordination between [Bazel owners,
-maintainers, and contributors](/versions/8.5.1/contribute/policy). This policy
+areas and to support communication and coordination between [Bazel owners, maintainers, and contributors](/versions/8.5.1/contribute/policy). This policy
 applies to [`bazelbuild`](http://github.com/bazelbuild).
 
 SIGs do their work in public. The ideal scope for a SIG covers a well-defined
diff --git a/versions/8.5.1/community/users.mdx b/versions/8.5.1/community/users.mdx
index 17cf6c64..63f0d026 100644
--- a/versions/8.5.1/community/users.mdx
+++ b/versions/8.5.1/community/users.mdx
@@ -304,11 +304,9 @@ safety systems_.
 Pigweed is an open-source solution for sustained, robust, and rapid embedded
 product development for large teams. Pigweed has shipped in millions of
 devices, including Google's suite of Pixel devices, Nest thermostats,
-[satellites](https://www.spinlaunch.com/), and [autonomous aerial
-drones](https://www.flyzipline.com/).
+[satellites](https://www.spinlaunch.com/), and [autonomous aerial drones](https://www.flyzipline.com/).
 
-Pigweed [uses Bazel as its primary build
-system](https://pigweed.dev/seed/0111-build-systems.html). The [Bazel for
+Pigweed [uses Bazel as its primary build system](https://pigweed.dev/seed/0111-build-systems.html). The [Bazel for
 Embedded][pw-bazel-great] blog post discusses why we think it's a great build
 system for embedded projects!
 
diff --git a/versions/8.5.1/concepts/build-ref.mdx b/versions/8.5.1/concepts/build-ref.mdx
index 2301173e..6b7ac1c2 100644
--- a/versions/8.5.1/concepts/build-ref.mdx
+++ b/versions/8.5.1/concepts/build-ref.mdx
@@ -17,8 +17,7 @@ its root; such a boundary marker file could be `MODULE.bazel`, `REPO.bazel`, or
 in legacy contexts, `WORKSPACE` or `WORKSPACE.bazel`.
 
 The repo in which the current Bazel command is being run is called the _main
-repo_. Other, (external) repos are defined by _repo rules_; see [external
-dependencies overview](/versions/8.5.1/external/overview) for more information.
+repo_. Other, (external) repos are defined by _repo rules_; see [external dependencies overview](/versions/8.5.1/external/overview) for more information.
 
 ## Workspace {#workspace}
 
@@ -95,5 +94,4 @@ have three properties: the list of packages they contain, their name, and other
 package groups they include. The only allowed ways to refer to them are from the
 `visibility` attribute of rules or from the `default_visibility` attribute of
 the `package` function; they do not generate or consume files. For more
-information, refer to the [`package_group`
-documentation](/versions/8.5.1/reference/be/functions#package_group).
+information, refer to the [`package_group` documentation](/versions/8.5.1/reference/be/functions#package_group).
diff --git a/versions/8.5.1/concepts/labels.mdx b/versions/8.5.1/concepts/labels.mdx
index a9a0439d..c6a2d650 100644
--- a/versions/8.5.1/concepts/labels.mdx
+++ b/versions/8.5.1/concepts/labels.mdx
@@ -10,8 +10,7 @@ form looks like:
 ```
 
 The first part of the label is the repository name, `@@myrepo`. The double-`@`
-syntax signifies that this is a [*canonical* repo
-name](/versions/8.5.1/external/overview#canonical-repo-name), which is unique within
+syntax signifies that this is a [*canonical* repo name](/versions/8.5.1/external/overview#canonical-repo-name), which is unique within
 the workspace. Labels with canonical repo names unambiguously identify a target
 no matter which context they appear in.
 
diff --git a/versions/8.5.1/concepts/platforms.mdx b/versions/8.5.1/concepts/platforms.mdx
index a9c45b09..b9f48e3e 100644
--- a/versions/8.5.1/concepts/platforms.mdx
+++ b/versions/8.5.1/concepts/platforms.mdx
@@ -77,8 +77,7 @@ To test your Android project with platforms, see
 for support.
 
 You can still use platform APIs with Apple builds (for example, when building
-with a mixture of Apple rules and pure C++) with [platform
-mappings](#platform-mappings).
+with a mixture of Apple rules and pure C++) with [platform mappings](#platform-mappings).
 
 ### Other languages {#other-languages}
 
@@ -241,8 +240,7 @@ sets `--cpu`, `--crossstool_top`, or other legacy flags, rules that read
 
 When migrating your project to platforms, you must either convert changes like
 `return { "//command_line_option:cpu": "arm" }` to `return {
-"//command_line_option:platforms": "//:my_arm_platform" }` or use [platform
-mappings](#platform-mappings) to support both styles during migration.
+"//command_line_option:platforms": "//:my_arm_platform" }` or use [platform mappings](#platform-mappings) to support both styles during migration.
 window.
 
 ## Migrating your rule set {#migrating-your-rule-set}
@@ -361,10 +359,8 @@ attributes declare a language's tools (like `compiler =
 this information to rules that need to build with these tools.
 
 Toolchains declare the `constraint_value`s of machines they can
-[target][target_compatible_with Attribute]
-(`target_compatible_with = ["@platforms//os:linux"]`) and machines their tools can
-[run on][exec_compatible_with Attribute]
-(`exec_compatible_with = ["@platforms//os:mac"]`).
+[target][target_compatible_with Attribute](`target_compatible_with = ["@platforms//os:linux"]`) and machines their tools can
+[run on][exec_compatible_with Attribute](`exec_compatible_with = ["@platforms//os:mac"]`).
 
 When building `$ bazel build //:myproject --platforms=//:myplatform`, Bazel
 automatically selects a toolchain that can run on the build machine and
diff --git a/versions/8.5.1/configure/attributes.mdx b/versions/8.5.1/configure/attributes.mdx
index 53c4d7b0..25780646 100644
--- a/versions/8.5.1/configure/attributes.mdx
+++ b/versions/8.5.1/configure/attributes.mdx
@@ -2,8 +2,7 @@
 title: 'Configurable Build Attributes'
 ---
 
-**_Configurable attributes_**, commonly known as [`select()`](
-/reference/be/functions#select), is a Bazel feature that lets users toggle the values
+**_Configurable attributes_**, commonly known as [`select()`](/versions/8.5.1/reference/be/functions#select), is a Bazel feature that lets users toggle the values
 of build rule attributes at the command line.
 
 This can be used, for example, for a multiplatform library that automatically
@@ -407,8 +406,7 @@ sh_library(
 )
 ```
 
-If you need a `select` to match when multiple conditions match, consider [AND
-chaining](#and-chaining).
+If you need a `select` to match when multiple conditions match, consider [AND chaining](#and-chaining).
 
 ## OR chaining {#or-chaining}
 
diff --git a/versions/8.5.1/configure/integrate-cpp.mdx b/versions/8.5.1/configure/integrate-cpp.mdx
index 0ea5a00c..f162a1bc 100644
--- a/versions/8.5.1/configure/integrate-cpp.mdx
+++ b/versions/8.5.1/configure/integrate-cpp.mdx
@@ -33,8 +33,7 @@ This is because when writing our own actions, they must behave
 consistently with the C++ toolchain - for example, passing C++ command line
 flags to a tool that invokes the C++ compiler behind the scenes.
 
-C++ rules use a special way of constructing command lines based on [feature
-configuration](/versions/8.5.1/docs/cc-toolchain-config-reference). To construct a command line,
+C++ rules use a special way of constructing command lines based on [feature configuration](/versions/8.5.1/docs/cc-toolchain-config-reference). To construct a command line,
 you need the following:
 
 * `features` and `action_configs` - these come from the `CcToolchainConfigInfo`
diff --git a/versions/8.5.1/configure/windows.mdx b/versions/8.5.1/configure/windows.mdx
index a370cca4..cb69752b 100644
--- a/versions/8.5.1/configure/windows.mdx
+++ b/versions/8.5.1/configure/windows.mdx
@@ -166,8 +166,7 @@ To build C++ targets with MSVC, you need:
         set BAZEL_VC=C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC
         ```
 
-*   The [Windows
-    SDK](https://developer.microsoft.com/en-us/windows/downloads/windows-10-sdk).
+*   The [Windows SDK](https://developer.microsoft.com/en-us/windows/downloads/windows-10-sdk).
 
     The Windows SDK contains header files and libraries you need when building
     Windows applications, including Bazel itself. By default, the latest Windows SDK installed will
@@ -186,8 +185,7 @@ To build C++ targets with MSVC, you need:
 
 If everything is set up, you can build a C++ target now!
 
-Try building a target from one of our [sample
-projects](https://github.com/bazelbuild/bazel/tree/master/examples):
+Try building a target from one of our [sample projects](https://github.com/bazelbuild/bazel/tree/master/examples):
 
 
 
 
-To build and use Dynamically Linked Libraries (DLL files), see [this
-example](https://github.com/bazelbuild/bazel/tree/master/examples/windows/dll).
+To build and use Dynamically Linked Libraries (DLL files), see [this example](https://github.com/bazelbuild/bazel/tree/master/examples/windows/dll).
 
 **Command Line Length Limit**: To prevent the
 [Windows command line length limit issue](https://github.com/bazelbuild/bazel/issues/5163),
@@ -292,8 +289,7 @@ On Windows, Bazel builds two output files for `java_binary` rules:
 *   a `.jar` file
 *   a `.exe` file that can set up the environment for the JVM and run the binary
 
-Try building a target from one of our [sample
-projects](https://github.com/bazelbuild/bazel/tree/master/examples):
+Try building a target from one of our [sample projects](https://github.com/bazelbuild/bazel/tree/master/examples):
 
 ```
 bazel build //examples/java-native/src/main/java/com/example/myproject:hello-world
@@ -315,8 +311,7 @@ On Windows, Bazel builds two output files for `py_binary` rules:
 You can either run the executable file (it has a `.exe` extension) or you can run
 Python with the self-extracting zip file as the argument.
 
-Try building a target from one of our [sample
-projects](https://github.com/bazelbuild/bazel/tree/master/examples):
+Try building a target from one of our [sample projects](https://github.com/bazelbuild/bazel/tree/master/examples):
 
 ```
 bazel build //examples/py_native:bin
@@ -325,5 +320,4 @@ python bazel-bin\examples\py_native\bin.zip
 ```
 
 If you are interested in details about how Bazel builds Python targets on
-Windows, check out this [design
-doc](https://github.com/bazelbuild/bazel-website/blob/master/designs/_posts/2016-09-05-build-python-on-windows.md).
+Windows, check out this [design doc](https://github.com/bazelbuild/bazel-website/blob/master/designs/_posts/2016-09-05-build-python-on-windows.md).
diff --git a/versions/8.5.1/contribute/breaking-changes.mdx b/versions/8.5.1/contribute/breaking-changes.mdx
index 9ffd4bf8..10c3672c 100644
--- a/versions/8.5.1/contribute/breaking-changes.mdx
+++ b/versions/8.5.1/contribute/breaking-changes.mdx
@@ -67,7 +67,7 @@ should contain the URL of the GitHub issue. As the flag name starts with
 ```
 
 In the commit description, add a brief summary of the flag.
-Also add [`RELNOTES:`](release-notes.md) in the following form:
+Also add [`RELNOTES:`](/versions/8.5.1/contribute/release-notes) in the following form:
 `RELNOTES: --incompatible_name_of_flag has been added. See #xyz for details`
 
 The commit should also update the relevant documentation, so that there is no
diff --git a/versions/8.5.1/contribute/codebase.mdx b/versions/8.5.1/contribute/codebase.mdx
index fac52984..cbfdecab 100644
--- a/versions/8.5.1/contribute/codebase.mdx
+++ b/versions/8.5.1/contribute/codebase.mdx
@@ -227,8 +227,7 @@ repository", the others are called "external repositories".
 A repository is marked by a repo boundary file (`MODULE.bazel`, `REPO.bazel`, or
 in legacy contexts, `WORKSPACE` or `WORKSPACE.bazel`) in its root directory. The
 main repo is the source tree where you're invoking Bazel from. External repos
-are defined in various ways; see [external dependencies
-overview](/versions/8.5.1/external/overview) for more information.
+are defined in various ways; see [external dependencies overview](/versions/8.5.1/external/overview) for more information.
 
 Code of external repositories is symlinked or downloaded under
 `$OUTPUT_BASE/external`.
diff --git a/versions/8.5.1/contribute/design-documents.mdx b/versions/8.5.1/contribute/design-documents.mdx
index d57b1633..2f0938fd 100644
--- a/versions/8.5.1/contribute/design-documents.mdx
+++ b/versions/8.5.1/contribute/design-documents.mdx
@@ -25,7 +25,7 @@ Here are some examples of significant changes:
 When you write a design document, you can coordinate with other Bazel developers
 and seek guidance from Bazel's core team. For example, when a proposal adds,
 removes, or modifies any function or object available in BUILD, MODULE.bazel, or
-bzl files, add the [Starlark team](maintainers-guide.md) as reviewers.
+bzl files, add the [Starlark team](/versions/8.5.1/contribute/maintainers-guide) as reviewers.
 Design documents are reviewed before submission because:
 
 *   Bazel is a very complex system; seemingly innocuous local changes can have
@@ -137,8 +137,7 @@ A lead reviewer should be a domain expert who is:
 *   Objective and capable of providing constructive feedback
 *   Available for the entire review period to lead the process
 
-Consider checking the contacts for various [team
-labels](/versions/8.5.1/contribute/maintainers-guide#team-labels).
+Consider checking the contacts for various [team labels](/versions/8.5.1/contribute/maintainers-guide#team-labels).
 
 ## Markdown vs Google Docs {#markdown-versus-gdocs}
 
@@ -168,12 +167,10 @@ Markdown for posterity.
 
 ### Using Google Docs {#gdocs}
 
-For consistency, use the [Bazel design doc template](
-https://docs.google.com/document/d/1cE5zrjrR40RXNg64XtRFewSv6FrLV6slGkkqxBumS1w/edit).
+For consistency, use the [Bazel design doc template](https://docs.google.com/document/d/1cE5zrjrR40RXNg64XtRFewSv6FrLV6slGkkqxBumS1w/edit).
 It includes the necessary header and creates visual
 consistency with other Bazel related documents. To do that, click on **File** >
-**Make a copy** or click this link to [make a copy of the design doc
-template](https://docs.google.com/document/d/1cE5zrjrR40RXNg64XtRFewSv6FrLV6slGkkqxBumS1w/copy).
+**Make a copy** or click this link to [make a copy of the design doc template](https://docs.google.com/document/d/1cE5zrjrR40RXNg64XtRFewSv6FrLV6slGkkqxBumS1w/copy).
 
 To make your document readable to the world, click on
 **Share** > **Advanced** > **Change…**, and
diff --git a/versions/8.5.1/contribute/images/structured-concurrency-3d.svg b/versions/8.5.1/contribute/images/structured-concurrency-3d.svg
new file mode 100644
index 00000000..accbb42a
--- /dev/null
+++ b/versions/8.5.1/contribute/images/structured-concurrency-3d.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/8.5.1/contribute/images/structured-concurrency.svg b/versions/8.5.1/contribute/images/structured-concurrency.svg
new file mode 100644
index 00000000..0258d9a9
--- /dev/null
+++ b/versions/8.5.1/contribute/images/structured-concurrency.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/8.5.1/contribute/images/suspend-resume.svg b/versions/8.5.1/contribute/images/suspend-resume.svg
new file mode 100644
index 00000000..7de1218f
--- /dev/null
+++ b/versions/8.5.1/contribute/images/suspend-resume.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/8.5.1/contribute/images/unstructured-concurrency.svg b/versions/8.5.1/contribute/images/unstructured-concurrency.svg
new file mode 100644
index 00000000..0951639a
--- /dev/null
+++ b/versions/8.5.1/contribute/images/unstructured-concurrency.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/8.5.1/contribute/index.mdx b/versions/8.5.1/contribute/index.mdx
index 997229f8..33b9ecfc 100644
--- a/versions/8.5.1/contribute/index.mdx
+++ b/versions/8.5.1/contribute/index.mdx
@@ -10,8 +10,7 @@ As you use Bazel, you may find things that can be improved.
 You can help by [reporting issues](http://github.com/bazelbuild/bazel/issues)
 when:
 
-   - Bazel crashes or you encounter a bug that can [only be resolved using `bazel
-     clean`](/versions/8.5.1/run/build#correct-incremental-rebuilds).
+   - Bazel crashes or you encounter a bug that can [only be resolved using `bazel clean`](/versions/8.5.1/run/build#correct-incremental-rebuilds).
    - The documentation is incomplete or unclear. You can also report issues
      from the page you are viewing by using the "Create issue"
      link at the top right corner of the page.
@@ -21,11 +20,9 @@ when:
 
 You can engage with the Bazel community by:
 
-   - Answering questions [on Stack Overflow](
-     https://stackoverflow.com/questions/tagged/bazel).
+   - Answering questions [on Stack Overflow](https://stackoverflow.com/questions/tagged/bazel).
    - Helping other users [on Slack](https://slack.bazel.build).
-   - Improving documentation or [contributing examples](
-     https://github.com/bazelbuild/examples).
+   - Improving documentation or [contributing examples](https://github.com/bazelbuild/examples).
    - Sharing your experience or your tips, for example, on a blog or social media.
 
 ## Contribute code {#contribute-code}
@@ -40,8 +37,7 @@ You can contribute to the Bazel ecosystem by:
    - Contributing to Bazel-related tools, for example, migration tools.
    - Improving Bazel integration with other IDEs and tools.
 
-Before making a change, [create a GitHub
-issue](http://github.com/bazelbuild/bazel/issues)
+Before making a change, [create a GitHub issue](http://github.com/bazelbuild/bazel/issues)
 or email [bazel-discuss@](mailto:bazel-discuss@googlegroups.com).
 
 The most helpful contributions fix bugs or add features (as opposed
diff --git a/versions/8.5.1/contribute/maintainers-guide.mdx b/versions/8.5.1/contribute/maintainers-guide.mdx
index 8ee9e37d..576973cd 100644
--- a/versions/8.5.1/contribute/maintainers-guide.mdx
+++ b/versions/8.5.1/contribute/maintainers-guide.mdx
@@ -4,8 +4,7 @@ title: 'Guide for Bazel Maintainers'
 
 This is a guide for the maintainers of the Bazel open source project.
 
-If you are looking to contribute to Bazel, please read [Contributing to
-Bazel](/versions/8.5.1/contribute) instead.
+If you are looking to contribute to Bazel, please read [Contributing to Bazel](/versions/8.5.1/contribute) instead.
 
 The objectives of this page are to:
 
@@ -37,8 +36,7 @@ repository.
 
 1. A user creates an issue by choosing one of the
 [issue templates](https://github.com/bazelbuild/bazel/issues/new/choose)
-   and it enters the pool of [unreviewed open
-   issues](https://github.com/bazelbuild/bazel/issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aopen+-label%3Auntriaged+-label%3Ap2+-label%3Ap1+-label%3Ap3+-label%3Ap4+-label%3Ateam-Starlark+-label%3Ateam-Rules-CPP+-label%3Ateam-Rules-Java+-label%3Ateam-XProduct+-label%3Ateam-Android+-label%3Ateam-Apple+-label%3Ateam-Configurability++-label%3Ateam-Performance+-label%3Ateam-Rules-Server+-label%3Ateam-Core+-label%3Ateam-Rules-Python+-label%3Ateam-Remote-Exec+-label%3Ateam-Local-Exec+-label%3Ateam-Bazel).
+   and it enters the pool of [unreviewed open issues](https://github.com/bazelbuild/bazel/issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aopen+-label%3Auntriaged+-label%3Ap2+-label%3Ap1+-label%3Ap3+-label%3Ap4+-label%3Ateam-Starlark+-label%3Ateam-Rules-CPP+-label%3Ateam-Rules-Java+-label%3Ateam-XProduct+-label%3Ateam-Android+-label%3Ateam-Apple+-label%3Ateam-Configurability++-label%3Ateam-Performance+-label%3Ateam-Rules-Server+-label%3Ateam-Core+-label%3Ateam-Rules-Python+-label%3Ateam-Remote-Exec+-label%3Ateam-Local-Exec+-label%3Ateam-Bazel).
 1. A member on the Developer Experience (DevEx) subteam rotation reviews the
    issue.
    1. If the issue is **not a bug** or a **feature request**, the DevEx member
@@ -58,21 +56,18 @@ repository.
 1. After reviewing the issue, the DevEx member decides if the issue requires
    immediate attention. If it does, they will assign the **P0**
    [priority](#priority) label and an owner from the list of team leads.
-1. The DevEx member assigns the `untriaged` label and exactly one [team
-   label](#team-labels) for routing.
+1. The DevEx member assigns the `untriaged` label and exactly one [team label](#team-labels) for routing.
 1. The DevEx member also assigns exactly one `type:` label, such as `type: bug`
    or `type: feature request`, according to the type of the issue.
 1. For platform-specific issues, the DevEx member assigns one `platform:` label,
    such as `platform:apple` for Mac-specific issues.
 1. If the issue is low priority and can be worked on by a new community
    contributor, the DevEx member assigns the `good first issue` label.
-At this stage, the issue enters the pool of [untriaged open
-issues](https://github.com/bazelbuild/bazel/issues?q=is%3Aissue+is%3Aopen+label%3Auntriaged).
+At this stage, the issue enters the pool of [untriaged open issues](https://github.com/bazelbuild/bazel/issues?q=is%3Aissue+is%3Aopen+label%3Auntriaged).
 
 Each Bazel subteam will triage all issues under labels they own, preferably on a
 weekly basis. The subteam will review and evaluate the issue and provide a
-resolution, if possible. If you are an owner of a team label, see [this section
-](#label-own) for more information.
+resolution, if possible. If you are an owner of a team label, see [this section](#label-own) for more information.
 
 When an issue is resolved, it can be closed.
 
@@ -111,8 +106,7 @@ preferably on a weekly basis.
      issue is either P0 or P1 we assume that is actively worked on.
 1. Remove the `untriaged` label.
 
-Note that you need to be in the [bazelbuild
-organization](https://github.com/bazelbuild) to be able to add or remove labels.
+Note that you need to be in the [bazelbuild organization](https://github.com/bazelbuild) to be able to add or remove labels.
 
 ### Pull Requests {#pull-requests}
 
@@ -138,8 +132,7 @@ issues.
   unusable, or a downed service that severely impacts development of the Bazel
   project. This includes regressions introduced in a new release that blocks a
   significant number of users, or an incompatible breaking change that was not
-  compliant to the [Breaking
-  Change](https://docs.google.com/document/d/1q5GGRxKrF_mnwtaPKI487P8OdDRh2nN7jX6U-FXnHL0/edit?pli=1#heading=h.ceof6vpkb3ik)
+  compliant to the [Breaking Change](https://docs.google.com/document/d/1q5GGRxKrF_mnwtaPKI487P8OdDRh2nN7jX6U-FXnHL0/edit?pli=1#heading=h.ceof6vpkb3ik)
   policy. No practical workaround exists.
 * [**P1**](https://github.com/bazelbuild/bazel/labels/P1) - Critical defect or
   feature which should be addressed in the next release, or a serious issue that
diff --git a/versions/8.5.1/contribute/naming.mdx b/versions/8.5.1/contribute/naming.mdx
index eb32e772..1edb560b 100644
--- a/versions/8.5.1/contribute/naming.mdx
+++ b/versions/8.5.1/contribute/naming.mdx
@@ -4,8 +4,7 @@ title: 'Naming a Bazel related project'
 
 First, thank you for contributing to the Bazel ecosystem! Please reach out to
 the Bazel community on the
-[bazel-discuss mailing list](https://groups.google.com/forum/#!forum/bazel-discuss
-) to share your project and its suggested name.
+[bazel-discuss mailing list](https://groups.google.com/forum/#!forum/bazel-discuss) to share your project and its suggested name.
 
 If you are building a Bazel related tool or sharing your Skylark rules,
 we recommend following these guidelines for the name of your project:
diff --git a/versions/8.5.1/contribute/patch-acceptance.mdx b/versions/8.5.1/contribute/patch-acceptance.mdx
index 6573de5d..9ea286cf 100644
--- a/versions/8.5.1/contribute/patch-acceptance.mdx
+++ b/versions/8.5.1/contribute/patch-acceptance.mdx
@@ -11,29 +11,24 @@ code base.
    need a corresponding issue for tracking.
 1. If you're proposing significant changes, write a
    [design document](/versions/8.5.1/contribute/design-documents).
-1. Ensure you've signed a [Contributor License
-   Agreement](https://cla.developers.google.com).
+1. Ensure you've signed a [Contributor License Agreement](https://cla.developers.google.com).
 1. Prepare a git commit that implements the feature. Don't forget to add tests
    and update the documentation. If your change has user-visible effects, please
    [add release notes](/versions/8.5.1/contribute/release-notes). If it is an incompatible change,
    read the [guide for rolling out breaking changes](/versions/8.5.1/contribute/breaking-changes).
 1. Create a pull request on
    [GitHub](https://github.com/bazelbuild/bazel/pulls). If you're new to GitHub,
-   read [about pull
-   requests](https://help.github.com/articles/about-pull-requests/). Note that
+   read [about pull requests](https://help.github.com/articles/about-pull-requests/). Note that
    we restrict permissions to create branches on the main Bazel repository, so
-   you will need to push your commit to [your own fork of the
-   repository](https://help.github.com/articles/working-with-forks/).
+   you will need to push your commit to [your own fork of the repository](https://help.github.com/articles/working-with-forks/).
 1. A Bazel maintainer should assign you a reviewer within two business days
    (excluding holidays in the USA and Germany). If you aren't assigned a
    reviewer in that time, you can request one by emailing
-   [bazel-discuss@googlegroups.com]
-   (mailto:bazel-discuss@googlegroups.com).
+   [bazel-discuss@googlegroups.com](mailto:bazel-discuss@googlegroups.com).
 1. Work with the reviewer to complete a code review. For each change, create a
    new commit and push it to make changes to your pull request. If the review
    takes too long (for instance, if the reviewer is unresponsive), send an email to
-   [bazel-discuss@googlegroups.com]
-   (mailto:bazel-discuss@googlegroups.com).
+   [bazel-discuss@googlegroups.com](mailto:bazel-discuss@googlegroups.com).
 1. After your review is complete, a Bazel maintainer applies your patch to
    Google's internal version control system.
 
diff --git a/versions/8.5.1/contribute/release-notes.mdx b/versions/8.5.1/contribute/release-notes.mdx
index 134915d3..4267d3d2 100644
--- a/versions/8.5.1/contribute/release-notes.mdx
+++ b/versions/8.5.1/contribute/release-notes.mdx
@@ -16,8 +16,7 @@ the release announcement.
 * If the change adds / removes / changes Bazel in a user-visible way, then it
   may be advantageous to mention it.
 
-If the change is significant, follow the [design document
-policy](/versions/8.5.1/contribute/design-documents) first.
+If the change is significant, follow the [design document policy](/versions/8.5.1/contribute/design-documents) first.
 
 ## Guidelines {#guidelines}
 
@@ -60,10 +59,8 @@ change is about.
 
 ## Process {#process}
 
-As part of the [release
-process](https://github.com/bazelbuild/continuous-integration/blob/master/docs/release-playbook.md),
-we collect the `RELNOTES` tags of every commit. We copy everything in a [Google
-Doc](https://docs.google.com/document/d/1wDvulLlj4NAlPZamdlEVFORks3YXJonCjyuQMUQEmB0/edit)
+As part of the [release process](https://github.com/bazelbuild/continuous-integration/blob/master/docs/release-playbook.md),
+we collect the `RELNOTES` tags of every commit. We copy everything in a [Google Doc](https://docs.google.com/document/d/1wDvulLlj4NAlPZamdlEVFORks3YXJonCjyuQMUQEmB0/edit)
 where we review, edit, and organize the notes.
 
 The release manager sends an email to the
@@ -71,6 +68,4 @@ The release manager sends an email to the
 Bazel contributors are invited to contribute to the document and make sure
 their changes are correctly reflected in the announcement.
 
-Later, the announcement will be submitted to the [Bazel
-blog](https://blog.bazel.build/), using the [bazel-blog
-repository](https://github.com/bazelbuild/bazel-blog/tree/master/_posts).
+Later, the announcement will be submitted to the [Bazel blog](https://blog.bazel.build/), using the [bazel-blog repository](https://github.com/bazelbuild/bazel-blog/tree/master/_posts).
diff --git a/versions/8.5.1/contribute/statemachine-guide.mdx b/versions/8.5.1/contribute/statemachine-guide.mdx
index 28a6ebf8..4d2a8263 100644
--- a/versions/8.5.1/contribute/statemachine-guide.mdx
+++ b/versions/8.5.1/contribute/statemachine-guide.mdx
@@ -172,8 +172,7 @@ instead, batches[^4] as many lookups as possible before doing so. The value
 might not be immediately available, for example, requiring a Skyframe restart,
 so the caller specifies what to do with the resulting value using a callback.
 
-The `StateMachine` processor ([`Driver`s and bridging to
-SkyFrame](#drivers-and-bridging)) guarantees that the value is available before
+The `StateMachine` processor ([`Driver`s and bridging to SkyFrame](#drivers-and-bridging)) guarantees that the value is available before
 the next state begins. An example follows.
 
 ```
@@ -284,8 +283,7 @@ and solutions to certain control flow problems.
 ### Sequential states
 
 This is the most common and straightforward control flow pattern. An example of
-this is shown in [Stateful computations inside
-`SkyKeyComputeState`](#stateful-computations).
+this is shown in [Stateful computations inside `SkyKeyComputeState`](#stateful-computations).
 
 ### Branching
 
@@ -545,8 +543,7 @@ section describes the propagation of data values.
 
 ### Implementing `Tasks.lookUp` callbacks
 
-There’s an example of implementing a `Tasks.lookUp` callback in [SkyValue
-lookups](#skyvalue-lookups). This section provides rationale and suggests
+There’s an example of implementing a `Tasks.lookUp` callback in [SkyValue lookups](#skyvalue-lookups). This section provides rationale and suggests
 approaches for handling multiple SkyValues.
 
 #### `Tasks.lookUp` callbacks {#tasks-lookup-callbacks}
@@ -710,8 +707,7 @@ class BarProducer implements StateMachine {
 Tip: It would be tempting to use the more concise signature void `accept(Bar
 value)` rather than the stuttery `void acceptBarValue(Bar value)` above.
 However, `Consumer` is a common overload of `void accept(Bar value)`,
-so doing this often leads to violations of the [Overloads: never
-split](https://google.github.io/styleguide/javaguide.html#s3.4.2-ordering-class-contents)
+so doing this often leads to violations of the [Overloads: never split](https://google.github.io/styleguide/javaguide.html#s3.4.2-ordering-class-contents)
 style-guide rule.
 
 Tip: Using a custom `ResultSink` type instead of a generic one from
@@ -774,14 +770,11 @@ pattern after accepting output from either a subtask or SkyValue lookup.
 Note that the implementation of `acceptBarError` eagerly forwards the result to
 the `Caller.ResultSink`, as required by [Error bubbling](#error-bubbling).
 
-Alternatives for top-level `StateMachine`s are described in [`Driver`s and
-bridging to SkyFunctions](#drivers-and-bridging).
+Alternatives for top-level `StateMachine`s are described in [`Driver`s and bridging to SkyFunctions](#drivers-and-bridging).
 
 ### Error handling {#error-handling}
 
-There's a couple of examples of error handling already in [`Tasks.lookUp`
-callbacks](#tasks-lookup-callbacks) and [Propagating values between
-`StateMachines`](#propagating-values). Exceptions, other than
+There's a couple of examples of error handling already in [`Tasks.lookUp` callbacks](#tasks-lookup-callbacks) and [Propagating values between `StateMachines`](#propagating-values). Exceptions, other than
 `InterruptedException` are not thrown, but instead passed around through
 callbacks as values. Such callbacks often have exclusive-or semantics, with
 exactly one of a value or error being passed.
@@ -1184,8 +1177,7 @@ states. Where it is possible, local stack `step` variables are young generation
 variables and efficiently GC'd.
 
 For `StateMachine` variables, breaking things down into subtasks and following
-the recommended pattern for [Propagating values between
-`StateMachine`s](#propagating-values) is also helpful. Observe that when
+the recommended pattern for [Propagating values between `StateMachine`s](#propagating-values) is also helpful. Observe that when
 following the pattern, only child `StateMachine`s have references to parent
 `StateMachine`s and not vice versa. This means that as children complete and
 update the parents using result callbacks, the children naturally fall out of
@@ -1207,8 +1199,7 @@ potentially reflecting local behavior.
 
 ### Concurrency tree diagram {#concurrency-tree-diagram}
 
-The following is an alternative view of the diagram in [Structured
-concurrency](#structured-concurrency) that better depicts the tree structure.
+The following is an alternative view of the diagram in [Structured concurrency](#structured-concurrency) that better depicts the tree structure.
 The blocks form a small tree.
 
 ![Structured Concurrency 3D](/versions/8.5.1/contribute/images/structured-concurrency-3d.svg)
diff --git a/versions/8.5.1/docs/android-instrumentation-test.mdx b/versions/8.5.1/docs/android-instrumentation-test.mdx
index c825e2f0..78be6bc9 100644
--- a/versions/8.5.1/docs/android-instrumentation-test.mdx
+++ b/versions/8.5.1/docs/android-instrumentation-test.mdx
@@ -2,8 +2,7 @@
 title: 'Android Instrumentation Tests'
 ---
 
-_If you're new to Bazel, start with the [Building Android with
-Bazel](/versions/8.5.1/start/android-app ) tutorial._
+_If you're new to Bazel, start with the [Building Android with Bazel](/versions/8.5.1/start/android-app) tutorial._
 
 ![Running Android instrumentation tests in parallel](/versions/8.5.1/docs/images/android_test.gif "Android instrumentation test")
 
@@ -18,9 +17,7 @@ emulators in a sandbox, ensuring that tests always run from a clean state. Each
 test gets an isolated emulator instance, allowing tests to run in parallel
 without passing states between them.
 
-For more information on Android instrumentation tests, check out the [Android
-developer
-documentation](https://developer.android.com/training/testing/unit-testing/instrumented-unit-tests.html).
+For more information on Android instrumentation tests, check out the [Android developer documentation](https://developer.android.com/training/testing/unit-testing/instrumented-unit-tests.html).
 
 Please file issues in the [GitHub issue tracker](https://github.com/bazelbuild/bazel/issues).
 
@@ -58,8 +55,7 @@ This results in output similar to the following:
 release 4.1.0
 ```
 
-- **KVM**. Bazel requires emulators to have [hardware
-  acceleration](https://developer.android.com/studio/run/emulator-acceleration.html#accel-check)
+- **KVM**. Bazel requires emulators to have [hardware acceleration](https://developer.android.com/studio/run/emulator-acceleration.html#accel-check)
   with KVM on Linux. You can follow these
   [installation instructions](https://help.ubuntu.com/community/KVM/Installation)
   for Ubuntu.
@@ -173,11 +169,9 @@ The main attributes of the rule `android_instrumentation_test` are:
 
 - `target_device`: An `android_device` target. This target describes the
   specifications of the Android emulator which Bazel uses to create, launch and
-  run the tests. See the [section on choosing an Android
-  device](#android-device-target) for more information.
+  run the tests. See the [section on choosing an Android device](#android-device-target) for more information.
 
-The test app's `AndroidManifest.xml` must include [an ``
-tag](https://developer.android.com/studio/test/#configure_instrumentation_manifest_settings).
+The test app's `AndroidManifest.xml` must include [an `` tag](https://developer.android.com/studio/test/#configure_instrumentation_manifest_settings).
 This tag must specify the attributes for the **package of the target app** and
 the **fully qualified class name of the instrumentation test runner**,
 `androidx.test.runner.AndroidJUnitRunner`.
@@ -214,8 +208,7 @@ repositories:
 - `@androidsdk`: The Android SDK. Download this through Android Studio.
 
 - `@android_test_support`: Hosts the test runner, emulator launcher, and
-  `android_device` targets. You can find the [latest release
-  here](https://github.com/android/android-test/releases).
+  `android_device` targets. You can find the [latest release here](https://github.com/android/android-test/releases).
 
 Enable these dependencies by adding the following lines to your `WORKSPACE`
 file:
@@ -240,8 +233,7 @@ android_test_repositories()
 
 ## Maven dependencies {#maven-dependencies}
 
-For managing dependencies on Maven artifacts from repositories, such as [Google
-Maven](https://maven.google.com) or [Maven Central](https://central.maven.org),
+For managing dependencies on Maven artifacts from repositories, such as [Google Maven](https://maven.google.com) or [Maven Central](https://central.maven.org),
 you should use a Maven resolver, such as
 [`rules_jvm_external`](https://github.com/bazelbuild/rules_jvm_external).
 
@@ -370,8 +362,7 @@ the device/emulator listed in `adb devices`.
 
 ## Sample projects {#sample-projects}
 
-If you are looking for canonical project samples, see the [Android testing
-samples](https://github.com/googlesamples/android-testing#experimental-bazel-support)
+If you are looking for canonical project samples, see the [Android testing samples](https://github.com/googlesamples/android-testing#experimental-bazel-support)
 for projects using Espresso and UIAutomator.
 
 ## Espresso setup {#espresso-setup}
@@ -560,8 +551,7 @@ API_LEVELS = [
 
 ## Known issues {#known-issues}
 
-- [Forked adb server processes are not terminated after
-  tests](https://github.com/bazelbuild/bazel/issues/4853)
+- [Forked adb server processes are not terminated after tests](https://github.com/bazelbuild/bazel/issues/4853)
 - While APK building works on all platforms (Linux, macOS, Windows), testing
   only works on Linux.
 - Even with `--config=local_adb`, users still need to specify
diff --git a/versions/8.5.1/docs/android-ndk.mdx b/versions/8.5.1/docs/android-ndk.mdx
index f0628538..e343b6af 100644
--- a/versions/8.5.1/docs/android-ndk.mdx
+++ b/versions/8.5.1/docs/android-ndk.mdx
@@ -2,8 +2,7 @@
 title: 'Using the Android Native Development Kit with Bazel'
 ---
 
-_If you're new to Bazel, please start with the [Building Android with
-Bazel](/versions/8.5.1/start/android-app ) tutorial._
+_If you're new to Bazel, please start with the [Building Android with Bazel](/versions/8.5.1/start/android-app) tutorial._
 
 ## Overview {#overview}
 
@@ -31,8 +30,7 @@ android_ndk_repository(
 )
 ```
 
-For more information about the `android_ndk_repository` rule, see the [Build
-Encyclopedia entry](/versions/8.5.1/reference/be/android#android_ndk_repository).
+For more information about the `android_ndk_repository` rule, see the [Build Encyclopedia entry](/versions/8.5.1/reference/be/android#android_ndk_repository).
 
 If you're using a recent version of the Android NDK (r22 and beyond), use the
 Starlark implementation of `android_ndk_repository`.
@@ -101,13 +99,11 @@ META-INF/MANIFEST.MF
 
 Bazel compiles all of the cc_libraries into a single shared object (`.so`) file,
 targeted for the `armeabi-v7a` ABI by default. To change this or build for
-multiple ABIs at the same time, see the section on [configuring the target
-ABI](#configuring-target-abi).
+multiple ABIs at the same time, see the section on [configuring the target ABI](#configuring-target-abi).
 
 ## Example setup {#example-setup}
 
-This example is available in the [Bazel examples
-repository](https://github.com/bazelbuild/examples/tree/master/android/ndk).
+This example is available in the [Bazel examples repository](https://github.com/bazelbuild/examples/tree/master/android/ndk).
 
 In the `BUILD.bazel` file, three targets are defined with the `android_binary`,
 `android_library`, and `cc_library` rules.
diff --git a/versions/8.5.1/docs/bazel-and-android.mdx b/versions/8.5.1/docs/bazel-and-android.mdx
index 694a4a59..b1fcdfb7 100644
--- a/versions/8.5.1/docs/bazel-and-android.mdx
+++ b/versions/8.5.1/docs/bazel-and-android.mdx
@@ -10,7 +10,7 @@ Android projects with Bazel.
 
 The following resources will help you work with Bazel on Android projects:
 
-*  [Tutorial: Building an Android app](/versions/8.5.1/start/android-app ). This
+*  [Tutorial: Building an Android app](/versions/8.5.1/start/android-app). This
    tutorial is a good place to start learning about Bazel commands and concepts,
    and how to build Android apps with Bazel.
 *  [Codelab: Building Android Apps with Bazel](https://developer.android.com/codelabs/bazel-android-intro#0).
diff --git a/versions/8.5.1/docs/configurable-attributes.mdx b/versions/8.5.1/docs/configurable-attributes.mdx
index d69cc498..84eff413 100644
--- a/versions/8.5.1/docs/configurable-attributes.mdx
+++ b/versions/8.5.1/docs/configurable-attributes.mdx
@@ -2,8 +2,7 @@
 title: 'Configurable Build Attributes'
 ---
 
-**_Configurable attributes_**, commonly known as [`select()`](
-/reference/be/functions#select), is a Bazel feature that lets users toggle the values
+**_Configurable attributes_**, commonly known as [`select()`](/versions/8.5.1/reference/be/functions#select), is a Bazel feature that lets users toggle the values
 of build rule attributes at the command line.
 
 This can be used, for example, for a multiplatform library that automatically
@@ -407,8 +406,7 @@ sh_library(
 )
 ```
 
-If you need a `select` to match when multiple conditions match, consider [AND
-chaining](#and-chaining).
+If you need a `select` to match when multiple conditions match, consider [AND chaining](#and-chaining).
 
 ## OR chaining {#or-chaining}
 
diff --git a/versions/8.5.1/docs/images/a_b_a_c.svg b/versions/8.5.1/docs/images/a_b_a_c.svg
new file mode 100644
index 00000000..d38be075
--- /dev/null
+++ b/versions/8.5.1/docs/images/a_b_a_c.svg
@@ -0,0 +1,42 @@
+
+
+
+
+
+
+G
+
+
+
+a
+
+a
+
+
+
+b
+
+b
+
+
+
+a->b
+
+
+
+
+
+c
+
+c
+
+
+
+a->c
+
+
+
+
+
+
diff --git a/versions/8.5.1/docs/images/a_b_c.svg b/versions/8.5.1/docs/images/a_b_c.svg
new file mode 100644
index 00000000..acd948ab
--- /dev/null
+++ b/versions/8.5.1/docs/images/a_b_c.svg
@@ -0,0 +1,41 @@
+
+
+
+
+
+
+G
+
+
+
+a
+
+a
+
+
+
+b
+
+b
+
+
+
+a->b
+
+
+
+
+
+c
+
+c
+
+
+
+b->c
+
+
+
+
+
diff --git a/versions/8.5.1/docs/images/a_b_c_ac.svg b/versions/8.5.1/docs/images/a_b_c_ac.svg
new file mode 100644
index 00000000..b099c53e
--- /dev/null
+++ b/versions/8.5.1/docs/images/a_b_c_ac.svg
@@ -0,0 +1,47 @@
+
+
+
+
+
+
+G
+
+
+
+a
+
+a
+
+
+
+b
+
+b
+
+
+
+a->b
+
+
+
+
+
+c
+
+c
+
+
+
+a->c
+
+
+
+
+
+b->c
+
+
+
+
+
diff --git a/versions/8.5.1/docs/images/ab_c.svg b/versions/8.5.1/docs/images/ab_c.svg
new file mode 100644
index 00000000..bcc4563f
--- /dev/null
+++ b/versions/8.5.1/docs/images/ab_c.svg
@@ -0,0 +1,36 @@
+
+
+
+
+
+
+G
+
+
+
+a
+
+a
+
+
+
+b
+
+b
+
+
+
+a->b
+
+
+
+
+
+c
+
+c
+
+
+
+
diff --git a/versions/8.5.1/docs/images/allpaths.svg b/versions/8.5.1/docs/images/allpaths.svg
new file mode 100644
index 00000000..47d0ee33
--- /dev/null
+++ b/versions/8.5.1/docs/images/allpaths.svg
@@ -0,0 +1,141 @@
+
+
+
+
+
+
+allpaths
+
+
+
+n1
+
+
+
+
+n2
+
+
+
+
+n1->n2
+
+
+
+
+
+n3
+
+
+
+
+n2->n3
+
+
+
+
+
+n10
+
+
+
+
+n2->n10
+
+
+
+
+
+n3->n10
+
+
+
+
+
+n4
+
+E
+
+
+
+n5
+
+
+
+
+n6
+
+
+
+
+n5->n6
+
+
+
+
+
+n6->n4
+
+
+
+
+
+n9
+
+
+
+
+n6->n9
+
+
+
+
+
+n7
+
+S1
+
+
+
+n7->n2
+
+
+
+
+
+n7->n5
+
+
+
+
+
+n8
+
+S2
+
+
+
+n8->n6
+
+
+
+
+
+n10->n4
+
+
+
+
+
+n11
+
+
+
+
+n10->n11
+
+
+
+
+
diff --git a/versions/8.5.1/docs/images/android_instrumentation_test.png b/versions/8.5.1/docs/images/android_instrumentation_test.png
new file mode 100644
index 00000000..e4534fbd
Binary files /dev/null and b/versions/8.5.1/docs/images/android_instrumentation_test.png differ
diff --git a/versions/8.5.1/docs/images/android_ndk.png b/versions/8.5.1/docs/images/android_ndk.png
new file mode 100644
index 00000000..76b63cb3
Binary files /dev/null and b/versions/8.5.1/docs/images/android_ndk.png differ
diff --git a/versions/8.5.1/docs/images/android_tutorial_app.png b/versions/8.5.1/docs/images/android_tutorial_app.png
new file mode 100644
index 00000000..076be5b9
Binary files /dev/null and b/versions/8.5.1/docs/images/android_tutorial_app.png differ
diff --git a/versions/8.5.1/docs/images/android_tutorial_before.png b/versions/8.5.1/docs/images/android_tutorial_before.png
new file mode 100644
index 00000000..8e41d419
Binary files /dev/null and b/versions/8.5.1/docs/images/android_tutorial_before.png differ
diff --git a/versions/8.5.1/docs/images/bep-graph.png b/versions/8.5.1/docs/images/bep-graph.png
new file mode 100644
index 00000000..82da6715
Binary files /dev/null and b/versions/8.5.1/docs/images/bep-graph.png differ
diff --git a/versions/8.5.1/docs/images/bep-graph.svg b/versions/8.5.1/docs/images/bep-graph.svg
new file mode 100644
index 00000000..62b1480f
--- /dev/null
+++ b/versions/8.5.1/docs/images/bep-graph.svg
@@ -0,0 +1,4 @@
+
+
+
+
diff --git a/versions/8.5.1/docs/images/cpp-tutorial-stage1.png b/versions/8.5.1/docs/images/cpp-tutorial-stage1.png
new file mode 100644
index 00000000..c85fb303
Binary files /dev/null and b/versions/8.5.1/docs/images/cpp-tutorial-stage1.png differ
diff --git a/versions/8.5.1/docs/images/cpp-tutorial-stage2.png b/versions/8.5.1/docs/images/cpp-tutorial-stage2.png
new file mode 100644
index 00000000..80e202c9
Binary files /dev/null and b/versions/8.5.1/docs/images/cpp-tutorial-stage2.png differ
diff --git a/versions/8.5.1/docs/images/cpp-tutorial-stage3.png b/versions/8.5.1/docs/images/cpp-tutorial-stage3.png
new file mode 100644
index 00000000..54d82f31
Binary files /dev/null and b/versions/8.5.1/docs/images/cpp-tutorial-stage3.png differ
diff --git a/versions/8.5.1/docs/images/deps.svg b/versions/8.5.1/docs/images/deps.svg
new file mode 100644
index 00000000..4354222a
--- /dev/null
+++ b/versions/8.5.1/docs/images/deps.svg
@@ -0,0 +1,101 @@
+
+
+
+
+
+
+G1
+
+
+
+r1
+
+rule
+
+
+
+s1
+
+in
+
+
+
+r1->s1
+
+
+
+
+
+s2
+
+in
+
+
+
+r1->s2
+
+
+
+
+
+s3
+
+in
+
+
+
+r1->s3
+
+
+
+
+
+r2
+
+rule
+
+
+
+r2->r1
+
+
+
+
+
+s4
+
+in
+
+
+
+r2->s4
+
+
+
+
+
+o1
+
+out
+
+
+
+o1->r1
+
+
+
+
+
+o2
+
+out
+
+
+
+o2->r2
+
+
+
+
+
diff --git a/versions/8.5.1/docs/images/dyn-trace-alldynamic.png b/versions/8.5.1/docs/images/dyn-trace-alldynamic.png
new file mode 100644
index 00000000..fe36b253
Binary files /dev/null and b/versions/8.5.1/docs/images/dyn-trace-alldynamic.png differ
diff --git a/versions/8.5.1/docs/images/dyn-trace-javaconly.png b/versions/8.5.1/docs/images/dyn-trace-javaconly.png
new file mode 100644
index 00000000..2ae41e52
Binary files /dev/null and b/versions/8.5.1/docs/images/dyn-trace-javaconly.png differ
diff --git a/versions/8.5.1/docs/images/e4b-workflow.png b/versions/8.5.1/docs/images/e4b-workflow.png
new file mode 100644
index 00000000..412822da
Binary files /dev/null and b/versions/8.5.1/docs/images/e4b-workflow.png differ
diff --git a/versions/8.5.1/docs/images/e4b-workflow.svg b/versions/8.5.1/docs/images/e4b-workflow.svg
new file mode 100644
index 00000000..1de66e02
--- /dev/null
+++ b/versions/8.5.1/docs/images/e4b-workflow.svg
@@ -0,0 +1,4 @@
+
+
+
+
diff --git a/versions/8.5.1/docs/images/error_example_1.png b/versions/8.5.1/docs/images/error_example_1.png
new file mode 100644
index 00000000..07ba1358
Binary files /dev/null and b/versions/8.5.1/docs/images/error_example_1.png differ
diff --git a/versions/8.5.1/docs/images/error_example_2.png b/versions/8.5.1/docs/images/error_example_2.png
new file mode 100644
index 00000000..861171ee
Binary files /dev/null and b/versions/8.5.1/docs/images/error_example_2.png differ
diff --git a/versions/8.5.1/docs/images/error_example_3.png b/versions/8.5.1/docs/images/error_example_3.png
new file mode 100644
index 00000000..dc16eec4
Binary files /dev/null and b/versions/8.5.1/docs/images/error_example_3.png differ
diff --git a/versions/8.5.1/docs/images/error_example_4.png b/versions/8.5.1/docs/images/error_example_4.png
new file mode 100644
index 00000000..84383e63
Binary files /dev/null and b/versions/8.5.1/docs/images/error_example_4.png differ
diff --git a/versions/8.5.1/docs/images/graph_ex_1.svg b/versions/8.5.1/docs/images/graph_ex_1.svg
new file mode 100644
index 00000000..dd7427f4
--- /dev/null
+++ b/versions/8.5.1/docs/images/graph_ex_1.svg
@@ -0,0 +1,131 @@
+
+
+
+
+
+
+mygraph
+
+
+
+//net/proto_compiler:protocol-compiler
+
+//net/proto_compiler:protocol-compiler
+
+
+
+//net/proto_compiler:util
+
+//net/proto_compiler:util
+
+
+
+//net/proto_compiler:protocol-compiler->//net/proto_compiler:util
+
+
+
+
+
+//net/proto_compiler:protocol-compiler-lib
+
+//net/proto_compiler:protocol-compiler-lib
+
+
+
+//net/proto_compiler:protocol-compiler->//net/proto_compiler:protocol-compiler-lib
+
+
+
+
+
+//net/proto2/bridge/public:compiler_upgrader
+
+//net/proto2/bridge/public:compiler_upgrader
+
+
+
+//net/proto_compiler:protocol-compiler->//net/proto2/bridge/public:compiler_upgrader
+
+
+
+
+
+//net/proto_compiler:parser
+
+//net/proto_compiler:parser
+
+
+
+//net/proto_compiler:util->//net/proto_compiler:parser
+
+
+
+
+
+//net/proto_compiler:proto-min-lib
+
+//net/proto_compiler:proto-min-lib
+
+
+
+//net/proto_compiler:protocol-compiler-lib->//net/proto_compiler:proto-min-lib
+
+
+
+
+
+//net/proto_compiler:protocol-compiler-lib->//net/proto_compiler:parser
+
+
+
+
+
+//net/proto2/bridge/internal:compiler_upgrader
+
+//net/proto2/bridge/internal:compiler_upgrader
+
+
+
+//net/proto2/bridge/public:compiler_upgrader->//net/proto2/bridge/internal:compiler_upgrader
+
+
+
+
+
+//net/proto_compiler:proto-min-lib->//net/proto_compiler:parser
+
+
+
+
+
+//util/regexp:regexp
+
+//util/regexp:regexp
+
+
+
+//net/proto_compiler:proto-min-lib->//util/regexp:regexp
+
+
+
+
+
+//net/proto_compiler:parser->//util/regexp:regexp
+
+
+
+
+
+//net/proto2/bridge/internal:compiler_upgrader->//net/proto2/bridge/public:compiler_upgrader
+
+
+
+
+
+//net/proto2/bridge/internal:compiler_upgrader->//net/proto_compiler:parser
+
+
+
+
+
diff --git a/versions/8.5.1/docs/images/graph_hello-world.svg b/versions/8.5.1/docs/images/graph_hello-world.svg
new file mode 100644
index 00000000..93b61444
--- /dev/null
+++ b/versions/8.5.1/docs/images/graph_hello-world.svg
@@ -0,0 +1,70 @@
+
+
+
+
+
+
+mygraph
+
+
+//main:hello-world
+
+//main:hello-world
+
+
+//main:hello-time
+
+//main:hello-time
+
+
+//main:hello-world->//main:hello-time
+
+
+
+
+//main:hello-world.cc
+
+//main:hello-world.cc
+
+
+//main:hello-world->//main:hello-world.cc
+
+
+
+
+//lib:hello-greet
+
+//lib:hello-greet
+
+
+//main:hello-world->//lib:hello-greet
+
+
+
+
+//main:hello-time.cc\n//main:hello-time.h
+
+//main:hello-time.cc
+//main:hello-time.h
+
+
+//main:hello-time->//main:hello-time.cc\n//main:hello-time.h
+
+
+
+
+//lib:hello-greet.cc\n//lib:hello-greet.h
+
+//lib:hello-greet.cc
+//lib:hello-greet.h
+
+
+//lib:hello-greet->//lib:hello-greet.cc\n//lib:hello-greet.h
+
+
+
+
+
diff --git a/versions/8.5.1/docs/images/json-trace-profile-network-usage.png b/versions/8.5.1/docs/images/json-trace-profile-network-usage.png
new file mode 100644
index 00000000..8a7500a6
Binary files /dev/null and b/versions/8.5.1/docs/images/json-trace-profile-network-usage.png differ
diff --git a/versions/8.5.1/docs/images/json-trace-profile-system-load-average.png b/versions/8.5.1/docs/images/json-trace-profile-system-load-average.png
new file mode 100644
index 00000000..e71b420c
Binary files /dev/null and b/versions/8.5.1/docs/images/json-trace-profile-system-load-average.png differ
diff --git a/versions/8.5.1/docs/images/json-trace-profile-workers-memory-usage.png b/versions/8.5.1/docs/images/json-trace-profile-workers-memory-usage.png
new file mode 100644
index 00000000..806505f0
Binary files /dev/null and b/versions/8.5.1/docs/images/json-trace-profile-workers-memory-usage.png differ
diff --git a/versions/8.5.1/docs/images/json-trace-profile.png b/versions/8.5.1/docs/images/json-trace-profile.png
new file mode 100644
index 00000000..538382b2
Binary files /dev/null and b/versions/8.5.1/docs/images/json-trace-profile.png differ
diff --git a/versions/8.5.1/docs/images/mobile-install-performance.svg b/versions/8.5.1/docs/images/mobile-install-performance.svg
new file mode 100644
index 00000000..b139d658
--- /dev/null
+++ b/versions/8.5.1/docs/images/mobile-install-performance.svg
@@ -0,0 +1,86 @@
+
+
+
+  
+    
+      
+    
+  
+  
+  
+    Build times
+  
+  
+    
+    
+      
+      
+        adb install
+      
+      
+    
+    
+      
+      
+        mobile-install
+      
+      
+    
+  
+  
+    
+    
+      
+        
+        
+        
+        
+        
+      
+      
+        
+        
+        
+        
+        
+        
+      
+      
+        
+      
+    
+    
+    
+      
+        Google Maps
+      
+      
+        Google+
+      
+      
+        YouTube
+      
+      
+        0
+      
+      
+        75
+      
+      
+        150
+      
+      
+        225
+      
+      
+        300
+      
+    
+  
+  
+    
+      Seconds
+    
+  
+  
+
diff --git a/versions/8.5.1/docs/images/namedsetoffiles-bep-graph.png b/versions/8.5.1/docs/images/namedsetoffiles-bep-graph.png
new file mode 100644
index 00000000..ea1e10cc
Binary files /dev/null and b/versions/8.5.1/docs/images/namedsetoffiles-bep-graph.png differ
diff --git a/versions/8.5.1/docs/images/out-ranked.svg b/versions/8.5.1/docs/images/out-ranked.svg
new file mode 100644
index 00000000..07e96804
--- /dev/null
+++ b/versions/8.5.1/docs/images/out-ranked.svg
@@ -0,0 +1,71 @@
+
+
+
+
+
+
+mygraph
+
+
+
+//a:a
+
+//a:a
+
+
+
+//a:a.cc
+
+//a:a.cc
+
+
+
+//a:a->//a:a.cc
+
+
+
+
+
+//b:b
+
+//b:b
+
+
+
+//b:b->//a:a
+
+
+
+
+
+//b:b.cc
+
+//b:b.cc
+
+
+
+//b:b->//b:b.cc
+
+
+
+
+
+//c:c
+
+//c:c
+
+
+
+//c:c->//a:a
+
+
+
+
+
+//c:c->//b:b
+
+
+
+
+
diff --git a/versions/8.5.1/docs/images/rbe-ci-1.png b/versions/8.5.1/docs/images/rbe-ci-1.png
new file mode 100644
index 00000000..fbe76a85
Binary files /dev/null and b/versions/8.5.1/docs/images/rbe-ci-1.png differ
diff --git a/versions/8.5.1/docs/images/rbe-ci-2.png b/versions/8.5.1/docs/images/rbe-ci-2.png
new file mode 100644
index 00000000..07611889
Binary files /dev/null and b/versions/8.5.1/docs/images/rbe-ci-2.png differ
diff --git a/versions/8.5.1/docs/images/somepath1.svg b/versions/8.5.1/docs/images/somepath1.svg
new file mode 100644
index 00000000..5e5f8812
--- /dev/null
+++ b/versions/8.5.1/docs/images/somepath1.svg
@@ -0,0 +1,141 @@
+
+
+
+
+
+
+somepath1
+
+
+
+n1
+
+
+
+
+n2
+
+
+
+
+n1->n2
+
+
+
+
+
+n3
+
+
+
+
+n2->n3
+
+
+
+
+
+n10
+
+
+
+
+n2->n10
+
+
+
+
+
+n3->n10
+
+
+
+
+
+n4
+
+E
+
+
+
+n5
+
+
+
+
+n6
+
+
+
+
+n5->n6
+
+
+
+
+
+n6->n4
+
+
+
+
+
+n9
+
+
+
+
+n6->n9
+
+
+
+
+
+n7
+
+S1
+
+
+
+n7->n2
+
+
+
+
+
+n7->n5
+
+
+
+
+
+n8
+
+S2
+
+
+
+n8->n6
+
+
+
+
+
+n10->n4
+
+
+
+
+
+n11
+
+
+
+
+n10->n11
+
+
+
+
+
diff --git a/versions/8.5.1/docs/images/somepath2.svg b/versions/8.5.1/docs/images/somepath2.svg
new file mode 100644
index 00000000..911f2c9b
--- /dev/null
+++ b/versions/8.5.1/docs/images/somepath2.svg
@@ -0,0 +1,141 @@
+
+
+
+
+
+
+somepath2
+
+
+
+n1
+
+
+
+
+n2
+
+
+
+
+n1->n2
+
+
+
+
+
+n3
+
+
+
+
+n2->n3
+
+
+
+
+
+n10
+
+
+
+
+n2->n10
+
+
+
+
+
+n3->n10
+
+
+
+
+
+n4
+
+E
+
+
+
+n5
+
+
+
+
+n6
+
+
+
+
+n5->n6
+
+
+
+
+
+n6->n4
+
+
+
+
+
+n9
+
+
+
+
+n6->n9
+
+
+
+
+
+n7
+
+S1
+
+
+
+n7->n2
+
+
+
+
+
+n7->n5
+
+
+
+
+
+n8
+
+S2
+
+
+
+n8->n6
+
+
+
+
+
+n10->n4
+
+
+
+
+
+n11
+
+
+
+
+n10->n11
+
+
+
+
+
diff --git a/versions/8.5.1/docs/images/targets.svg b/versions/8.5.1/docs/images/targets.svg
new file mode 100644
index 00000000..82f47e74
--- /dev/null
+++ b/versions/8.5.1/docs/images/targets.svg
@@ -0,0 +1,113 @@
+
+
+
+
+
+
+G1
+
+
+
+Target
+
+Target
+
+
+
+Rule
+
+Rule
+
+
+
+Target->Rule
+
+
+
+
+
+File
+
+File
+
+
+
+Target->File
+
+
+
+
+
+Package group
+
+Package group
+
+
+
+Target->Package group
+
+
+
+
+
+cc_library
+
+cc_library
+
+
+
+Rule->cc_library
+
+
+
+
+
+java_test
+
+java_test
+
+
+
+Rule->java_test
+
+
+
+
+
+...
+
+...
+
+
+
+Rule->...
+
+
+
+
+
+Source
+
+Source
+
+
+
+File->Source
+
+
+
+
+
+Generated
+
+Generated
+
+
+
+File->Generated
+
+
+
+
+
diff --git a/versions/8.5.1/docs/images/tutorial_java_01.svg b/versions/8.5.1/docs/images/tutorial_java_01.svg
new file mode 100644
index 00000000..2fe72f36
--- /dev/null
+++ b/versions/8.5.1/docs/images/tutorial_java_01.svg
@@ -0,0 +1,29 @@
+
+
+
+
+
+
+mygraph
+
+
+//:ProjectRunner
+
+//:ProjectRunner
+
+
+//:src/main/java/com/example/Greeting.java\n//:src/main/java/com/example/ProjectRunner.java
+
+//:src/main/java/com/example/Greeting.java
+//:src/main/java/com/example/ProjectRunner.java
+
+
+//:ProjectRunner->//:src/main/java/com/example/Greeting.java\n//:src/main/java/com/example/ProjectRunner.java
+
+
+
+
+
diff --git a/versions/8.5.1/docs/images/tutorial_java_02.svg b/versions/8.5.1/docs/images/tutorial_java_02.svg
new file mode 100644
index 00000000..40cbb218
--- /dev/null
+++ b/versions/8.5.1/docs/images/tutorial_java_02.svg
@@ -0,0 +1,48 @@
+
+
+
+
+
+
+mygraph
+
+
+//:ProjectRunner
+
+//:ProjectRunner
+
+
+//:greeter
+
+//:greeter
+
+
+//:ProjectRunner->//:greeter
+
+
+
+
+//:src/main/java/com/example/ProjectRunner.java
+
+//:src/main/java/com/example/ProjectRunner.java
+
+
+//:ProjectRunner->//:src/main/java/com/example/ProjectRunner.java
+
+
+
+
+//:src/main/java/com/example/Greeting.java
+
+//:src/main/java/com/example/Greeting.java
+
+
+//:greeter->//:src/main/java/com/example/Greeting.java
+
+
+
+
+
diff --git a/versions/8.5.1/docs/images/tutorial_java_03.svg b/versions/8.5.1/docs/images/tutorial_java_03.svg
new file mode 100644
index 00000000..7d79041a
--- /dev/null
+++ b/versions/8.5.1/docs/images/tutorial_java_03.svg
@@ -0,0 +1,48 @@
+
+
+
+
+
+
+mygraph
+
+
+//src/main/java/com/example/cmdline:runner
+
+//src/main/java/com/example/cmdline:runner
+
+
+//src/main/java/com/example/cmdline:Runner.java
+
+//src/main/java/com/example/cmdline:Runner.java
+
+
+//src/main/java/com/example/cmdline:runner->//src/main/java/com/example/cmdline:Runner.java
+
+
+
+
+//:greeter
+
+//:greeter
+
+
+//src/main/java/com/example/cmdline:runner->//:greeter
+
+
+
+
+//:src/main/java/com/example/Greeting.java
+
+//:src/main/java/com/example/Greeting.java
+
+
+//:greeter->//:src/main/java/com/example/Greeting.java
+
+
+
+
+
diff --git a/versions/8.5.1/docs/images/workers-clean-chart.png b/versions/8.5.1/docs/images/workers-clean-chart.png
new file mode 100644
index 00000000..63526fc1
Binary files /dev/null and b/versions/8.5.1/docs/images/workers-clean-chart.png differ
diff --git a/versions/8.5.1/docs/images/workers-incremental-chart.png b/versions/8.5.1/docs/images/workers-incremental-chart.png
new file mode 100644
index 00000000..1c62d25c
Binary files /dev/null and b/versions/8.5.1/docs/images/workers-incremental-chart.png differ
diff --git a/versions/8.5.1/docs/images/ws-diamond.png b/versions/8.5.1/docs/images/ws-diamond.png
new file mode 100644
index 00000000..154a7440
Binary files /dev/null and b/versions/8.5.1/docs/images/ws-diamond.png differ
diff --git a/versions/8.5.1/docs/images/ws-line.png b/versions/8.5.1/docs/images/ws-line.png
new file mode 100644
index 00000000..e8bfe7a1
Binary files /dev/null and b/versions/8.5.1/docs/images/ws-line.png differ
diff --git a/versions/8.5.1/docs/images/ws-multiline.png b/versions/8.5.1/docs/images/ws-multiline.png
new file mode 100644
index 00000000..f07b43b1
Binary files /dev/null and b/versions/8.5.1/docs/images/ws-multiline.png differ
diff --git a/versions/8.5.1/docs/sandboxing.mdx b/versions/8.5.1/docs/sandboxing.mdx
index 30f0ef68..1c99ff60 100644
--- a/versions/8.5.1/docs/sandboxing.mdx
+++ b/versions/8.5.1/docs/sandboxing.mdx
@@ -48,7 +48,7 @@ containers on Linux and `sandbox-exec` on macOS, to constrain the action within
 ## What sandbox strategy to use {#sandboxing-strategies}
 
 You can choose which kind of sandboxing to use, if any, with the
-[strategy flags](user-manual#strategy-options). Using the `sandboxed`
+[strategy flags](/versions/8.5.1/docs/user-manual#strategy-options). Using the `sandboxed`
 strategy makes Bazel pick one of the sandbox implementations listed below,
 preferring an OS-specific sandbox to the less hermetic generic one.
 [Persistent workers](/versions/8.5.1/remote/persistent) run in a generic sandbox if you pass
diff --git a/versions/8.5.1/docs/user-manual.mdx b/versions/8.5.1/docs/user-manual.mdx
index 9edc2cf5..ab346dc4 100644
--- a/versions/8.5.1/docs/user-manual.mdx
+++ b/versions/8.5.1/docs/user-manual.mdx
@@ -1162,7 +1162,7 @@ This option causes Bazel's execution phase to print the full command line
 for each command prior to executing it.
 
 ```
-  >>>>> # //examples/cpp:hello-world [action 'Linking examples/cpp/hello-world']
+  >>>> # //examples/cpp:hello-world [action 'Linking examples/cpp/hello-world']
   (cd /home/johndoe/.cache/bazel/_bazel_johndoe/4c084335afceb392cfbe7c31afee3a9f/bazel && \
     exec env - \
     /usr/bin/gcc -o bazel-out/local-fastbuild/bin/examples/cpp/hello-world -B/usr/bin/ -Wl,-z,relro,-z,now -no-canonical-prefixes -pass-exit-codes -Wl,-S -Wl,@bazel-out/local_linux-fastbuild/bin/examples/cpp/hello-world-2.params)
diff --git a/versions/8.5.1/extending/auto-exec-groups.mdx b/versions/8.5.1/extending/auto-exec-groups.mdx
index 9c3d0d33..555ae573 100644
--- a/versions/8.5.1/extending/auto-exec-groups.mdx
+++ b/versions/8.5.1/extending/auto-exec-groups.mdx
@@ -27,9 +27,7 @@ doesn't detect that ([the error](#first-error-message) is raised), you can set
 
 If you need to use multiple toolchains on a single execution platform (an action
 uses executable or tools from two or more toolchains), you need to manually
-define [exec_groups][exec_groups] (check
-[When should I use a custom exec_group?][multiple_toolchains_exec_groups]
-section).
+define [exec_groups][exec_groups](check [When should I use a custom exec_group?][multiple_toolchains_exec_groups] section).
 
 ## History {#history}
 
@@ -42,8 +40,7 @@ my_rule = rule(
 )
 ```
 
-Rule `my_rule` registers two toolchain types. This means that the [Toolchain
-Resolution](https://bazel.build/extending/toolchains#toolchain-resolution) used
+Rule `my_rule` registers two toolchain types. This means that the [Toolchain Resolution](https://bazel.build/versions/8.5.1/extending/toolchains#toolchain-resolution) used
 to find an execution platform which supports both toolchain types. The selected
 execution platform was used for each registered action inside the rule, unless
 specified differently with [exec_groups][exec_groups].
diff --git a/versions/8.5.1/extending/concepts.mdx b/versions/8.5.1/extending/concepts.mdx
index 8cb6fbff..d5e72977 100644
--- a/versions/8.5.1/extending/concepts.mdx
+++ b/versions/8.5.1/extending/concepts.mdx
@@ -20,16 +20,14 @@ Before learning the more advanced concepts, first:
 ## Macros and rules {#macros-and-rules}
 
 A macro is a function that instantiates rules. Macros come in two flavors:
-[symbolic macros](/versions/8.5.1/extending/macros) (new in Bazel 8) and [legacy
-macros](/versions/8.5.1/extending/legacy-macros). The two flavors of macros are defined
+[symbolic macros](/versions/8.5.1/extending/macros) (new in Bazel 8) and [legacy macros](/versions/8.5.1/extending/legacy-macros). The two flavors of macros are defined
 differently, but behave almost the same from the point of view of a user. A
 macro is useful when a `BUILD` file is getting too repetitive or too complex, as
 it lets you reuse some code. The function is evaluated as soon as the `BUILD`
 file is read. After the evaluation of the `BUILD` file, Bazel has little
 information about macros. If your macro generates a `genrule`, Bazel will
 behave *almost* as if you declared that `genrule` in the `BUILD` file. (The one
-exception is that targets declared in a symbolic macro have [special visibility
-semantics](/versions/8.5.1/extending/macros#visibility): a symbolic macro can hide its internal
+exception is that targets declared in a symbolic macro have [special visibility semantics](/versions/8.5.1/extending/macros#visibility): a symbolic macro can hide its internal
 targets from the rest of the package.)
 
 A [rule](/versions/8.5.1/extending/rules) is more powerful than a macro. It can access Bazel
@@ -76,8 +74,7 @@ they will not be executed.
 ## Creating extensions
 
 * [Create your first macro](/versions/8.5.1/rules/macro-tutorial) in order to reuse some code.
-  Then [learn more about macros](/versions/8.5.1/extending/macros) and [using them to create
-  "custom verbs"](/versions/8.5.1/rules/verbs-tutorial).
+  Then [learn more about macros](/versions/8.5.1/extending/macros) and [using them to create "custom verbs"](/versions/8.5.1/rules/verbs-tutorial).
 
 * [Follow the rules tutorial](/versions/8.5.1/rules/rules-tutorial) to get started with rules.
   Next, you can read more about the [rules concepts](/versions/8.5.1/extending/rules).
@@ -92,8 +89,7 @@ them within reach:
 ## Going further
 
 In addition to [macros](/versions/8.5.1/extending/macros) and [rules](/versions/8.5.1/extending/rules), you
-may want to write [aspects](/versions/8.5.1/extending/aspects) and [repository
-rules](/versions/8.5.1/extending/repo).
+may want to write [aspects](/versions/8.5.1/extending/aspects) and [repository rules](/versions/8.5.1/extending/repo).
 
 * Use [Buildifier](https://github.com/bazelbuild/buildtools)
   consistently to format and lint your code.
diff --git a/versions/8.5.1/extending/depsets.mdx b/versions/8.5.1/extending/depsets.mdx
index 9a2c217b..29551df0 100644
--- a/versions/8.5.1/extending/depsets.mdx
+++ b/versions/8.5.1/extending/depsets.mdx
@@ -111,8 +111,7 @@ need to ensure that if `B` depends on `A`, then `A.o` comes before `B.o` on the
 linker’s command line. Other tools might have the opposite requirement.
 
 Three traversal orders are supported: `postorder`, `preorder`, and
-`topological`. The first two work exactly like [tree
-traversals](https://en.wikipedia.org/wiki/Tree_traversal#Depth-first_search)
+`topological`. The first two work exactly like [tree traversals](https://en.wikipedia.org/wiki/Tree_traversal#Depth-first_search)
 except that they operate on DAGs and skip already visited nodes. The third order
 works as a topological sort from root to leaves, essentially the same as
 preorder except that shared children are listed only after all of their parents.
diff --git a/versions/8.5.1/extending/exec-groups.mdx b/versions/8.5.1/extending/exec-groups.mdx
index b7ad7a22..444c1f60 100644
--- a/versions/8.5.1/extending/exec-groups.mdx
+++ b/versions/8.5.1/extending/exec-groups.mdx
@@ -63,8 +63,7 @@ test rules.
 
 In the rule implementation, you can declare that actions should be run on the
 execution platform of an execution group. You can do this by using the `exec_group`
-param of action generating methods, specifically [`ctx.actions.run`]
-(/rules/lib/builtins/actions#run) and
+param of action generating methods, specifically [`ctx.actions.run`](/versions/8.5.1/rules/lib/builtins/actions#run) and
 [`ctx.actions.run_shell`](/versions/8.5.1/rules/lib/builtins/actions#run_shell).
 
 ```python
diff --git a/versions/8.5.1/extending/legacy-macros.mdx b/versions/8.5.1/extending/legacy-macros.mdx
index 62bff6c2..3bc02d9f 100644
--- a/versions/8.5.1/extending/legacy-macros.mdx
+++ b/versions/8.5.1/extending/legacy-macros.mdx
@@ -9,7 +9,7 @@ anymore, and Bazel sees only the concrete set of instantiated rules.
 
 ## Why you shouldn't use legacy macros (and should use Symbolic macros instead) {#no-legacy-macros}
 
-Where possible you should use [symbolic macros](macros.md#macros).
+Where possible you should use [symbolic macros](/versions/8.5.1/extending/macros#macros).
 
 Symbolic macros
 
@@ -18,7 +18,7 @@ Symbolic macros
 *   Take typed attributes, which in turn means automatic label and select
     conversion.
 *   Are more readable
-*   Will soon have [lazy evaluation](macros.md/laziness)
+*   Will soon have [lazy evaluation](/versions/8.5.1/extending/macros#laziness)
 
 ## Usage {#usage}
 
@@ -152,7 +152,7 @@ the macro), use the function
 ## Label resolution in macros {#label-resolution}
 
 Since legacy macros are evaluated in the
-[loading phase](concepts.md#evaluation-model), label strings such as
+[loading phase](/versions/8.5.1/extending/concepts#evaluation-model), label strings such as
 `"//foo:bar"` that occur in a legacy macro are interpreted relative to the
 `BUILD` file in which the macro is used rather than relative to the `.bzl` file
 in which it is defined. This behavior is generally undesirable for macros that
diff --git a/versions/8.5.1/extending/macros.mdx b/versions/8.5.1/extending/macros.mdx
index 2cb2b528..5a5f104a 100644
--- a/versions/8.5.1/extending/macros.mdx
+++ b/versions/8.5.1/extending/macros.mdx
@@ -10,7 +10,7 @@ Macros are mainly used for encapsulation and code reuse of existing rules and
 other macros.
 
 Macros come in two flavors: symbolic macros, which are described on this page,
-and [legacy macros](legacy-macros.md). Where possible, we recommend using
+and [legacy macros](/versions/8.5.1/extending/legacy-macros). Where possible, we recommend using
 symbolic macros for code clarity.
 
 Symbolic macros offer typed arguments (string to label conversion, relative to
@@ -31,8 +31,7 @@ two required parameters: `attrs` and `implementation`.
 
 ### Attributes {#attributes}
 
-`attrs` accepts a dictionary of attribute name to [attribute
-types](https://bazel.build/rules/lib/toplevel/attr#members), which represents
+`attrs` accepts a dictionary of attribute name to [attribute types](https://bazel.build/versions/8.5.1/rules/lib/toplevel/attr#members), which represents
 the arguments to the macro. Two common attributes – `name` and `visibility` –
 are implicitly added to all macros and are not included in the dictionary passed
 to `attrs`.
@@ -66,9 +65,7 @@ To support this pattern, a macro can *inherit attributes* from a rule or another
 macro by passing the [rule](https://bazel.build/versions/8.5.1/rules/lib/builtins/rule) or
 [macro symbol](https://bazel.build/versions/8.5.1/rules/lib/builtins/macro) to `macro()`'s
 `inherit_attrs` argument. (You can also use the special string `"common"`
-instead of a rule or macro symbol to inherit the [common attributes defined for
-all Starlark build
-rules](https://bazel.build/reference/be/common-definitions#common-attributes).)
+instead of a rule or macro symbol to inherit the [common attributes defined for all Starlark build rules](https://bazel.build/versions/8.5.1/reference/be/common-definitions#common-attributes).)
 Only public attributes get inherited, and the attributes in the macro's own
 `attrs` dictionary override inherited attributes with the same name. You can
 also *remove* inherited attributes by using `None` as a value in the `attrs`
diff --git a/versions/8.5.1/extending/platforms.mdx b/versions/8.5.1/extending/platforms.mdx
index 68d302c7..c3f6748f 100644
--- a/versions/8.5.1/extending/platforms.mdx
+++ b/versions/8.5.1/extending/platforms.mdx
@@ -245,8 +245,7 @@ cc_library(
 
 You can use the
 [`IncompatiblePlatformProvider`](/versions/8.5.1/rules/lib/providers/IncompatiblePlatformProvider)
-in `bazel cquery`'s [Starlark output
-format](/versions/8.5.1/query/cquery#output-format-definition) to distinguish
+in `bazel cquery`'s [Starlark output format](/versions/8.5.1/query/cquery#output-format-definition) to distinguish
 incompatible targets from compatible ones.
 
 This can be used to filter out incompatible targets. The example below will
@@ -266,5 +265,4 @@ $ bazel cquery //... --output=starlark --starlark:file=example.cquery
 
 ### Known Issues
 
-Incompatible targets [ignore visibility
-restrictions](https://github.com/bazelbuild/bazel/issues/16044).
+Incompatible targets [ignore visibility restrictions](https://github.com/bazelbuild/bazel/issues/16044).
diff --git a/versions/8.5.1/extending/repo.mdx b/versions/8.5.1/extending/repo.mdx
index e5771852..c216da30 100644
--- a/versions/8.5.1/extending/repo.mdx
+++ b/versions/8.5.1/extending/repo.mdx
@@ -74,8 +74,7 @@ specified.
 
 The input parameter `repository_ctx` can be used to access attribute values, and
 non-hermetic functions (finding a binary, executing a binary, creating a file in
-the repository or downloading a file from the Internet). See [the API
-docs](/versions/8.5.1/rules/lib/builtins/repository_ctx) for more context. Example:
+the repository or downloading a file from the Internet). See [the API docs](/versions/8.5.1/rules/lib/builtins/repository_ctx) for more context. Example:
 
 ```python
 def _impl(repository_ctx):
@@ -144,8 +143,7 @@ definition has the `configure` attribute set, use `bazel fetch --force
 
 ## Examples
 
--   [C++ auto-configured
-    toolchain](https://cs.opensource.google/bazel/bazel/+/master:tools/cpp/cc_configure.bzl;drc=644b7d41748e09eff9e47cbab2be2263bb71f29a;l=176):
+-   [C++ auto-configured toolchain](https://cs.opensource.google/bazel/bazel/+/master:tools/cpp/cc_configure.bzl;drc=644b7d41748e09eff9e47cbab2be2263bb71f29a;l=176):
     it uses a repo rule to automatically create the C++ configuration files for
     Bazel by looking for the local C++ compiler, the environment and the flags
     the C++ compiler supports.
diff --git a/versions/8.5.1/extending/rules.mdx b/versions/8.5.1/extending/rules.mdx
index 022899d1..6d103fe9 100644
--- a/versions/8.5.1/extending/rules.mdx
+++ b/versions/8.5.1/extending/rules.mdx
@@ -449,8 +449,7 @@ def _example_library_impl(ctx):
 
 If `DefaultInfo` is not returned by a rule implementation or the `files`
 parameter is not specified, `DefaultInfo.files` defaults to all
-*predeclared outputs* (generally, those created by [output
-attributes](#output_attributes)).
+*predeclared outputs* (generally, those created by [output attributes](#output_attributes)).
 
 Rules that perform actions should provide default outputs, even if those outputs
 are not expected to be directly used. Actions that are not in the graph of the
@@ -995,8 +994,7 @@ By using `configuration_field`, the dependency on the Java LCOV merger tool can
 be avoided as long as coverage is not requested.
 
 When the test is run, it should emit coverage information in the form of one or
-more [LCOV files]
-(https://manpages.debian.org/unstable/lcov/geninfo.1.en.html#TRACEFILE_FORMAT)
+more [LCOV files](https://manpages.debian.org/unstable/lcov/geninfo.1.en.html#TRACEFILE_FORMAT)
 with unique names into the directory specified by the `COVERAGE_DIR` environment
 variable. Bazel will then merge these files into a single LCOV file using the
 `_lcov_merger` tool. If present, it will also collect C/C++ coverage using the
diff --git a/versions/8.5.1/extending/toolchains.mdx b/versions/8.5.1/extending/toolchains.mdx
index 6da4aba3..b4fe4a6f 100644
--- a/versions/8.5.1/extending/toolchains.mdx
+++ b/versions/8.5.1/extending/toolchains.mdx
@@ -523,8 +523,7 @@ The set of available toolchains, in priority order, is created from
   4. Toolchains registered in the "WORKSPACE suffix"; this is only used by
      certain native rules bundled with the Bazel installation.
 
-**NOTE:** [Pseudo-targets like `:all`, `:*`, and
-`/...`](/versions/8.5.1/run/build#specifying-build-targets) are ordered by Bazel's package
+**NOTE:** [Pseudo-targets like `:all`, `:*`, and `/...`](/versions/8.5.1/run/build#specifying-build-targets) are ordered by Bazel's package
 loading mechanism, which uses a lexicographic ordering.
 
 The resolution steps are as follows.
diff --git a/versions/8.5.1/external/advanced.mdx b/versions/8.5.1/external/advanced.mdx
index 3d9cedf9..a9d9674a 100644
--- a/versions/8.5.1/external/advanced.mdx
+++ b/versions/8.5.1/external/advanced.mdx
@@ -4,10 +4,8 @@ title: 'Advanced topics on external dependencies'
 
 ## Shadowing dependencies in WORKSPACE
 
-Note: This section applies to the [WORKSPACE
-system](/versions/8.5.1/external/overview#workspace-system) only. For
-[Bzlmod](/versions/8.5.1/external/overview#bzlmod), use a [multiple-version
-override](/versions/8.5.1/external/module#multiple-version_override).
+Note: This section applies to the [WORKSPACE system](/versions/8.5.1/external/overview#workspace-system) only. For
+[Bzlmod](/versions/8.5.1/external/overview#bzlmod), use a [multiple-version override](/versions/8.5.1/external/module#multiple-version_override).
 
 Whenever possible, have a single version policy in your project, which is
 required for dependencies that you compile against and end up in your final
@@ -128,29 +126,24 @@ preferring IPv4 if enabled. In some situations, for example when the IPv4
 network cannot resolve/reach external addresses, this can cause `Network
 unreachable` exceptions and build failures. In these cases, you can override
 Bazel's behavior to prefer IPv6 by using the
-[`java.net.preferIPv6Addresses=true` system
-property](https://docs.oracle.com/javase/8/docs/api/java/net/doc-files/net-properties.html).
+[`java.net.preferIPv6Addresses=true` system property](https://docs.oracle.com/javase/8/docs/api/java/net/doc-files/net-properties.html).
 Specifically:
 
-*   Use `--host_jvm_args=-Djava.net.preferIPv6Addresses=true` [startup
-    option](/versions/8.5.1/docs/user-manual#startup-options), for example by adding the
+*   Use `--host_jvm_args=-Djava.net.preferIPv6Addresses=true` [startup option](/versions/8.5.1/docs/user-manual#startup-options), for example by adding the
     following line in your [`.bazelrc` file](/versions/8.5.1/run/bazelrc):
 
     `startup --host_jvm_args=-Djava.net.preferIPv6Addresses=true`
 
 *   When running Java build targets that need to connect to the internet (such
     as for integration tests), use the
-    `--jvmopt=-Djava.net.preferIPv6Addresses=true` [tool
-    flag](/versions/8.5.1/docs/user-manual#jvmopt). For example, include in your [`.bazelrc`
-    file](/versions/8.5.1/run/bazelrc):
+    `--jvmopt=-Djava.net.preferIPv6Addresses=true` [tool flag](/versions/8.5.1/docs/user-manual#jvmopt). For example, include in your [`.bazelrc` file](/versions/8.5.1/run/bazelrc):
 
     `build --jvmopt=-Djava.net.preferIPv6Addresses`
 
 *   If you are using [`rules_jvm_external`](https://github.com/bazelbuild/rules_jvm_external)
     for dependency version resolution, also add
     `-Djava.net.preferIPv6Addresses=true` to the `COURSIER_OPTS` environment
-    variable to [provide JVM options for
-    Coursier](https://github.com/bazelbuild/rules_jvm_external#provide-jvm-options-for-coursier-with-coursier_opts).
+    variable to [provide JVM options for Coursier](https://github.com/bazelbuild/rules_jvm_external#provide-jvm-options-for-coursier-with-coursier_opts).
 
 ## Offline builds
 
@@ -167,15 +160,12 @@ fetch a file with [`ctx.download`](/versions/8.5.1/rules/lib/builtins/repository
 providing a hash sum of the file needed, Bazel looks for a file matching the
 basename of the first URL, and uses the local copy if the hash matches.
 
-Bazel itself uses this technique to bootstrap offline from the [distribution
-artifact](https://github.com/bazelbuild/bazel-website/blob/master/designs/_posts/2016-10-11-distribution-artifact.md).
-It does so by [collecting all the needed external
-dependencies](https://github.com/bazelbuild/bazel/blob/5cfa0303d6ac3b5bd031ff60272ce80a704af8c2/WORKSPACE#L116)
+Bazel itself uses this technique to bootstrap offline from the [distribution artifact](https://github.com/bazelbuild/bazel-website/blob/master/designs/_posts/2016-10-11-distribution-artifact.md).
+It does so by [collecting all the needed external dependencies](https://github.com/bazelbuild/bazel/blob/5cfa0303d6ac3b5bd031ff60272ce80a704af8c2/WORKSPACE#L116)
 in an internal
 [`distdir_tar`](https://github.com/bazelbuild/bazel/blob/5cfa0303d6ac3b5bd031ff60272ce80a704af8c2/distdir.bzl#L44).
 
 Bazel allows execution of arbitrary commands in repository rules without knowing
 if they call out to the network, and so cannot enforce fully offline builds. To
 test if a build works correctly offline, manually block off the network (as
-Bazel does in its [bootstrap
-test](https://cs.opensource.google/bazel/bazel/+/master:src/test/shell/bazel/BUILD;l=1073;drc=88c426e73cc0eb0a41c0d7995e36acd94e7c9a48)).
\ No newline at end of file
+Bazel does in its [bootstrap test](https://cs.opensource.google/bazel/bazel/+/master:src/test/shell/bazel/BUILD;l=1073;drc=88c426e73cc0eb0a41c0d7995e36acd94e7c9a48)).
\ No newline at end of file
diff --git a/versions/8.5.1/external/images/mod_exampleBefore.svg b/versions/8.5.1/external/images/mod_exampleBefore.svg
new file mode 100644
index 00000000..66f01303
--- /dev/null
+++ b/versions/8.5.1/external/images/mod_exampleBefore.svg
@@ -0,0 +1,175 @@
+
+
+
+
+
+
+mygraph
+
+
+
+<root>
+
+<root> (my_project@1.0)
+
+
+
+bazel_skylib@1.1.1
+
+bazel_skylib@1.1.1
+
+
+
+<root>->bazel_skylib@1.1.1
+
+
+
+
+
+bazel_skylib@1.2.0
+
+bazel_skylib@1.2.0
+
+
+
+<root>->bazel_skylib@1.2.0
+
+
+
+
+
+rules_java@5.0.0
+
+rules_java@5.0.0
+
+
+
+<root>->rules_java@5.0.0
+
+
+
+
+
+stardoc@0.5.0
+
+stardoc@0.5.0
+
+
+
+<root>->stardoc@0.5.0
+
+
+
+
+
+platforms@0.0.4
+
+platforms@0.0.4
+
+
+
+bazel_skylib@1.1.1->platforms@0.0.4
+
+
+
+
+
+bazel_skylib@1.2.0->platforms@0.0.4
+
+
+
+
+
+rules_java@5.0.0->platforms@0.0.4
+
+
+
+
+
+rules_cc@0.0.1
+
+rules_cc@0.0.1
+
+
+
+rules_java@5.0.0->rules_cc@0.0.1
+
+
+
+
+
+rules_proto@4.0.0
+
+rules_proto@4.0.0
+
+
+
+rules_java@5.0.0->rules_proto@4.0.0
+
+
+
+
+
+bazel_skylib@1.0.3
+
+bazel_skylib@1.0.3
+
+
+
+stardoc@0.5.0->bazel_skylib@1.0.3
+
+
+
+
+
+rules_java@4.0.0
+
+rules_java@4.0.0
+
+
+
+stardoc@0.5.0->rules_java@4.0.0
+
+
+
+
+
+rules_cc@0.0.1->platforms@0.0.4
+
+
+
+
+
+rules_cc@0.0.1->bazel_skylib@1.0.3
+
+
+
+
+
+rules_proto@4.0.0->rules_cc@0.0.1
+
+
+
+
+
+rules_proto@4.0.0->bazel_skylib@1.0.3
+
+
+
+
+
+bazel_skylib@1.0.3->platforms@0.0.4
+
+
+
+
+
+rules_java@4.0.0->bazel_skylib@1.0.3
+
+
+
+
+
\ No newline at end of file
diff --git a/versions/8.5.1/external/images/mod_exampleResolved.svg b/versions/8.5.1/external/images/mod_exampleResolved.svg
new file mode 100644
index 00000000..224b694c
--- /dev/null
+++ b/versions/8.5.1/external/images/mod_exampleResolved.svg
@@ -0,0 +1,151 @@
+
+
+
+
+
+
+mygraph
+
+
+
+<root>
+
+<root> (my_project@1.0)
+
+
+
+bazel_skylib@1.1.1
+
+bazel_skylib@1.1.1
+
+
+
+<root>->bazel_skylib@1.1.1
+
+
+
+
+
+bazel_skylib@1.2.0
+
+bazel_skylib@1.2.0
+
+
+
+<root>->bazel_skylib@1.2.0
+
+
+
+
+
+rules_java@5.0.0
+
+rules_java@5.0.0
+
+
+
+<root>->rules_java@5.0.0
+
+
+
+
+
+stardoc@0.5.0
+
+stardoc@0.5.0
+
+
+
+<root>->stardoc@0.5.0
+
+
+
+
+
+platforms@0.0.4
+
+platforms@0.0.4
+
+
+
+bazel_skylib@1.1.1->platforms@0.0.4
+
+
+
+
+
+bazel_skylib@1.2.0->platforms@0.0.4
+
+
+
+
+
+rules_java@5.0.0->platforms@0.0.4
+
+
+
+
+
+rules_cc@0.0.1
+
+rules_cc@0.0.1
+
+
+
+rules_java@5.0.0->rules_cc@0.0.1
+
+
+
+
+
+rules_proto@4.0.0
+
+rules_proto@4.0.0
+
+
+
+rules_java@5.0.0->rules_proto@4.0.0
+
+
+
+
+
+stardoc@0.5.0->bazel_skylib@1.1.1
+
+
+
+
+
+stardoc@0.5.0->rules_java@5.0.0
+
+
+
+
+
+rules_cc@0.0.1->bazel_skylib@1.1.1
+
+
+
+
+
+rules_cc@0.0.1->platforms@0.0.4
+
+
+
+
+
+rules_proto@4.0.0->bazel_skylib@1.1.1
+
+
+
+
+
+rules_proto@4.0.0->rules_cc@0.0.1
+
+
+
+
+
\ No newline at end of file
diff --git a/versions/8.5.1/external/migration.mdx b/versions/8.5.1/external/migration.mdx
index e7f6f9eb..d86238b8 100644
--- a/versions/8.5.1/external/migration.mdx
+++ b/versions/8.5.1/external/migration.mdx
@@ -2,8 +2,7 @@
 title: 'Bzlmod Migration Guide'
 ---
 
-Due to the [shortcomings of
-WORKSPACE](/versions/8.5.1/external/overview#workspace-shortcomings), Bzlmod is going to
+Due to the [shortcomings of WORKSPACE](/versions/8.5.1/external/overview#workspace-shortcomings), Bzlmod is going to
 replace the legacy WORKSPACE system. The WORKSPACE file will be disabled by
 default in Bazel 8 (late 2024) and will be removed in Bazel 9 (late 2025).
 This guide helps you migrate your project to Bzlmod and drop WORKSPACE for
@@ -117,9 +116,7 @@ Bazel module when it also adopts Bzlmod.
 
 *   **Bzlmod**
 
-    With Bzlmod, as long as the your dependency is available in [Bazel Central
-    Registry](https://registry.bazel.build) or your custom [Bazel
-    registry](/versions/8.5.1/external/registry), you can simply depend on it with a
+    With Bzlmod, as long as the your dependency is available in [Bazel Central Registry](https://registry.bazel.build) or your custom [Bazel registry](/versions/8.5.1/external/registry), you can simply depend on it with a
     [`bazel_dep`](/versions/8.5.1/rules/lib/globals/module#bazel_dep) directive.
 
     ```python
@@ -150,8 +147,7 @@ repository.
 
 If your dependency is not a Bazel project or not yet available in any Bazel
 registry, you can introduce it using
-[`use_repo_rule`](/versions/8.5.1/external/module#use_repo_rule) or [module
-extensions](/versions/8.5.1/external/extension).
+[`use_repo_rule`](/versions/8.5.1/external/module#use_repo_rule) or [module extensions](/versions/8.5.1/external/extension).
 
 *   **WORKSPACE**
 
@@ -604,8 +600,7 @@ macros.
 Fortunately, the flag
 [`--experimental_repository_resolved_file`][resolved_file_flag]
 can help. This flag essentially generates a "lock file" of all fetched external
-dependencies in your last Bazel command. You can find more details in this [blog
-post](https://blog.bazel.build/2018/07/09/bazel-sync-and-resolved-file.html).
+dependencies in your last Bazel command. You can find more details in this [blog post](https://blog.bazel.build/2018/07/09/bazel-sync-and-resolved-file.html).
 
 [resolved_file_flag]: /reference/command-line-reference#flag--experimental_repository_resolved_file
 
@@ -646,11 +641,9 @@ You may also know `bazel query` can be used for inspecting repository rules with
 bazel query --output=build //external:
 ```
 
-While it is more convenient and much faster, [bazel query can lie about
-external dependency version](https://github.com/bazelbuild/bazel/issues/12947),
+While it is more convenient and much faster, [bazel query can lie about external dependency version](https://github.com/bazelbuild/bazel/issues/12947),
 so be careful using it! Querying and inspecting external
-dependencies with Bzlmod is going to achieved by a [new
-subcommand](https://github.com/bazelbuild/bazel/issues/15365).
+dependencies with Bzlmod is going to achieved by a [new subcommand](https://github.com/bazelbuild/bazel/issues/15365).
 
 #### Built-in default dependencies {#builtin-default-deps}
 
@@ -697,8 +690,7 @@ Using the WORKSPACE.bzlmod file can make the migration easier because:
 #### Repository visibility {#repository-visibility}
 
 Bzlmod is able to control which other repositories are visible from a given
-repository, check [repository names and strict
-deps](/versions/8.5.1/external/module#repository_names_and_strict_deps) for more details.
+repository, check [repository names and strict deps](/versions/8.5.1/external/module#repository_names_and_strict_deps) for more details.
 
 Here is a summary of repository visibilities from different types of
 repositories when also taking WORKSPACE into consideration.
@@ -711,8 +703,7 @@ repositories when also taking WORKSPACE into consideration.
 | WORKSPACE Repos | All visible | Not visible | Not visible | All visible |
 
 Note: For the root module, if a repository `@foo` is defined in WORKSPACE and
-`@foo` is also used as an [apparent repository
-name](/versions/8.5.1/external/overview#apparent-repo-name) in MODULE.bazel, then `@foo`
+`@foo` is also used as an [apparent repository name](/versions/8.5.1/external/overview#apparent-repo-name) in MODULE.bazel, then `@foo`
 refers to the one introduced in MODULE.bazel.
 
 Note: For a module extension generated repository `@bar`, if `@foo` is used as
@@ -787,9 +778,7 @@ the project. Take note of a few things when creating the source archive:
     GitHub isn't going to guarantee the checksum of source archives generated on
     demand. In short, URLs in the form of
     `https://github.com///releases/download/...` is considered stable
-    while `https://github.com///archive/...` is not. Check [GitHub
-    Archive Checksum
-    Outage](https://blog.bazel.build/2023/02/15/github-archive-checksum.html)
+    while `https://github.com///archive/...` is not. Check [GitHub Archive Checksum Outage](https://blog.bazel.build/2023/02/15/github-archive-checksum.html)
     for more context.
 
 *   **Make sure the source tree follows the layout of the original repository.**
@@ -818,8 +807,7 @@ Pull Request.
 
 [bcr_contrib_guide]: https://github.com/bazelbuild/bazel-central-registry/tree/main/docs#contribute-a-bazel-module
 
-It is **highly recommended** to set up the [Publish to
-BCR](https://github.com/bazel-contrib/publish-to-bcr) GitHub App for your
+It is **highly recommended** to set up the [Publish to BCR](https://github.com/bazel-contrib/publish-to-bcr) GitHub App for your
 repository to automate the process of submitting your module to the BCR.
 
 ## Best practices {#best-practices}
diff --git a/versions/8.5.1/external/mod-command.mdx b/versions/8.5.1/external/mod-command.mdx
index a0412220..5ec3e377 100644
--- a/versions/8.5.1/external/mod-command.mdx
+++ b/versions/8.5.1/external/mod-command.mdx
@@ -62,11 +62,9 @@ The available subcommands and their respective required arguments are:
 
 *   ``: All present versions of the module ``.
 
-*   `@`: The repo with the given [apparent
-    name](overview#apparent-repo-name) in the context of the `--base_module`.
+*   `@`: The repo with the given [apparent name](/versions/8.5.1/external/overview#apparent-repo-name) in the context of the `--base_module`.
 
-*   `@@`: The repo with the given [canonical
-    name](overview#canonical-repo-name).
+*   `@@`: The repo with the given [canonical name](/versions/8.5.1/external/overview#canonical-repo-name).
 
 In a context requiring specifying modules, ``s referring to repos that
 correspond to modules (as opposed to extension-generated repos) can also be
@@ -88,8 +86,7 @@ The following options only affect the subcommands that print graphs (`graph`,
     information about the version resolution of each module. If the module
     version changed during resolution, show either which version replaced it or
     what was the original version, the reason it was replaced, and which modules
-    requested the new version if the reason was [Minimal Version
-    Selection](module#version-selection).
+    requested the new version if the reason was [Minimal Version Selection](/versions/8.5.1/external/module#version-selection).
 
 *   `--include_unused` *default: "false"*: Include in the output graph the
     modules which were originally present in the dependency graph, but became
@@ -193,7 +190,7 @@ use_repo(toolchains, my_jdk="remotejdk17_linux")
   

     
       

-        Graph Before Resolution
+        Graph Before Resolution
         
Graph Before Resolution

       

 {/* digraph mygraph {
@@ -223,7 +220,7 @@ use_repo(toolchains, my_jdk="remotejdk17_linux")
     		
     
       

-        Graph After Resolution
+        Graph After Resolution
        
Graph After Resolution

       

 {/* digraph mygraph {
diff --git a/versions/8.5.1/external/module.mdx b/versions/8.5.1/external/module.mdx
index 4d8e5dcf..b947b7ce 100644
--- a/versions/8.5.1/external/module.mdx
+++ b/versions/8.5.1/external/module.mdx
@@ -122,8 +122,7 @@ serves multiple purposes:
     version, regardless of which versions of the dependency are requested in the
     dependency graph.
 *   With the `registry` attribute, you can force this dependency to come from a
-    specific registry, instead of following the normal [registry
-    selection](/versions/8.5.1/external/registry#selecting_registries) process.
+    specific registry, instead of following the normal [registry selection](/versions/8.5.1/external/registry#selecting_registries) process.
 *   With the `patch*` attributes, you can specify a set of patches to apply to
     the downloaded module.
 
@@ -176,13 +175,11 @@ With `bazel_dep`, you can define repos that represent other Bazel modules.
 Sometimes there is a need to define a repo that does _not_ represent a Bazel
 module; for example, one that contains a plain JSON file to be read as data.
 
-In this case, you could use the [`use_repo_rule`
-directive](/versions/8.5.1/rules/lib/globals/module#use_repo_rule) to directly define a repo
+In this case, you could use the [`use_repo_rule` directive](/versions/8.5.1/rules/lib/globals/module#use_repo_rule) to directly define a repo
 by invoking a repo rule. This repo will only be visible to the module it's
 defined in.
 
-Under the hood, this is implemented using the same mechanism as [module
-extensions](/versions/8.5.1/external/extension), which lets you define repos with more
+Under the hood, this is implemented using the same mechanism as [module extensions](/versions/8.5.1/external/extension), which lets you define repos with more
 flexibility.
 
 ## Repository names and strict deps
diff --git a/versions/8.5.1/external/overview.mdx b/versions/8.5.1/external/overview.mdx
index 6d6ae6ea..e5d486a0 100644
--- a/versions/8.5.1/external/overview.mdx
+++ b/versions/8.5.1/external/overview.mdx
@@ -128,8 +128,7 @@ for all build targets inside the repo.
 
 The syntax of a `REPO.bazel` file is similar to `BUILD` files, except that no
 `load` statements are supported, and only a single function, `repo()`, is
-available. `repo()` takes the same arguments as the [`package()`
-function](/versions/8.5.1/reference/be/functions#package) in `BUILD` files; whereas `package()`
+available. `repo()` takes the same arguments as the [`package()` function](/versions/8.5.1/reference/be/functions#package) in `BUILD` files; whereas `package()`
 specifies common attributes for all build targets inside the package, `repo()`
 analogously does so for all build targets inside the repo.
 
@@ -163,8 +162,7 @@ bazel_dep(name = "protobuf", version = "3.19.0")
 ```
 
 A module must only list its direct dependencies, which Bzlmod looks up in a
-[Bazel registry](/versions/8.5.1/external/registry) — by default, the [Bazel Central
-Registry](https://bcr.bazel.build/). The registry provides the
+[Bazel registry](/versions/8.5.1/external/registry) — by default, the [Bazel Central Registry](https://bcr.bazel.build/). The registry provides the
 dependencies' `MODULE.bazel` files, which allows Bazel to discover the entire
 transitive dependency graph before performing version resolution.
 
@@ -235,5 +233,4 @@ many pain points, including:
         `B` and `C`; `B` and `C` both depend on different versions of `D`).
 
 Due to the shortcomings of WORKSPACE, Bzlmod is going to replace the legacy
-WORKSPACE system in future Bazel releases. Please read the [Bzlmod migration
-guide](/versions/8.5.1/external/migration) on how to migrate to Bzlmod.
+WORKSPACE system in future Bazel releases. Please read the [Bzlmod migration guide](/versions/8.5.1/external/migration) on how to migrate to Bzlmod.
diff --git a/versions/8.5.1/external/registry.mdx b/versions/8.5.1/external/registry.mdx
index 74d55237..8ec76e21 100644
--- a/versions/8.5.1/external/registry.mdx
+++ b/versions/8.5.1/external/registry.mdx
@@ -42,8 +42,7 @@ An index registry must follow the format below:
             project
         *   `versions`: A list of all the versions of this module to be found in
             this registry
-        *   `yanked_versions`: A map of [*yanked*
-            versions](/versions/8.5.1/external/module#yanked_versions) of this module. The keys
+        *   `yanked_versions`: A map of [*yanked* versions](/versions/8.5.1/external/module#yanked_versions) of this module. The keys
             should be versions to yank and the values should be descriptions of
             why the version is yanked, ideally containing a link to more
             information
@@ -56,8 +55,7 @@ An index registry must follow the format below:
             *   `url`: The URL of the source archive
             *   `mirror_urls`: A list of string, the mirror URLs of the source archive.
                 The URLs are tried in order after `url` as backups.
-            *   `integrity`: The [Subresource
-                Integrity](https://w3c.github.io/webappsec-subresource-integrity/#integrity-metadata-description)
+            *   `integrity`: The [Subresource Integrity](https://w3c.github.io/webappsec-subresource-integrity/#integrity-metadata-description)
                 checksum of the archive
             *   `strip_prefix`: A directory prefix to strip when extracting the
                 source archive
@@ -105,8 +103,7 @@ You can browse its contents using the web frontend at
 https://registry.bazel.build/.
 
 The Bazel community maintains the BCR, and contributors are welcome to submit
-pull requests. See the [BCR contribution
-guidelines](https://github.com/bazelbuild/bazel-central-registry/blob/main/docs/README.md).
+pull requests. See the [BCR contribution guidelines](https://github.com/bazelbuild/bazel-central-registry/blob/main/docs/README.md).
 
 In addition to following the format of a normal index registry, the BCR requires
 a `presubmit.yml` file for each module version
diff --git a/versions/8.5.1/external/vendor.mdx b/versions/8.5.1/external/vendor.mdx
index b2f569b2..4ce92ef1 100644
--- a/versions/8.5.1/external/vendor.mdx
+++ b/versions/8.5.1/external/vendor.mdx
@@ -23,9 +23,7 @@ absolute path.
 ## Vendor a specific external repository {#vendor-specific-repository}
 
 You can use the `vendor` command with the `--repo` flag to specify which repo
-to vendor, it accepts both [canonical repo
-name](/versions/8.5.1/external/overview#canonical-repo-name) and [apparent repo
-name](/versions/8.5.1/external/overview#apparent-repo-name).
+to vendor, it accepts both [canonical repo name](/versions/8.5.1/external/overview#canonical-repo-name) and [apparent repo name](/versions/8.5.1/external/overview#apparent-repo-name).
 
 For example, running:
 
diff --git a/versions/8.5.1/help.mdx b/versions/8.5.1/help.mdx
index 4d23265f..4121504a 100644
--- a/versions/8.5.1/help.mdx
+++ b/versions/8.5.1/help.mdx
@@ -46,5 +46,4 @@ what level of support Bazel provides.
 
 ## File a bug {#file-bug}
 
-If you encounter a bug or want to request a feature, file a [GitHub
-Issue](https://github.com/bazelbuild/bazel/issues).
+If you encounter a bug or want to request a feature, file a [GitHub Issue](https://github.com/bazelbuild/bazel/issues).
diff --git a/versions/8.5.1/images/about.svg b/versions/8.5.1/images/about.svg
new file mode 100644
index 00000000..f927298f
--- /dev/null
+++ b/versions/8.5.1/images/about.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/8.5.1/images/basics.svg b/versions/8.5.1/images/basics.svg
new file mode 100644
index 00000000..013ec519
--- /dev/null
+++ b/versions/8.5.1/images/basics.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/8.5.1/images/bazel_hero.svg b/versions/8.5.1/images/bazel_hero.svg
new file mode 100644
index 00000000..c48714d0
--- /dev/null
+++ b/versions/8.5.1/images/bazel_hero.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/8.5.1/images/community.svg b/versions/8.5.1/images/community.svg
new file mode 100644
index 00000000..29f87a76
--- /dev/null
+++ b/versions/8.5.1/images/community.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/8.5.1/images/distributed-build-remote-cache.png b/versions/8.5.1/images/distributed-build-remote-cache.png
new file mode 100644
index 00000000..99d8a915
Binary files /dev/null and b/versions/8.5.1/images/distributed-build-remote-cache.png differ
diff --git a/versions/8.5.1/images/essential_guide.svg b/versions/8.5.1/images/essential_guide.svg
new file mode 100644
index 00000000..4ee63ae9
--- /dev/null
+++ b/versions/8.5.1/images/essential_guide.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/8.5.1/images/essential_reference.svg b/versions/8.5.1/images/essential_reference.svg
new file mode 100644
index 00000000..4d29a8d5
--- /dev/null
+++ b/versions/8.5.1/images/essential_reference.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/8.5.1/images/essential_start.svg b/versions/8.5.1/images/essential_start.svg
new file mode 100644
index 00000000..c8f48f84
--- /dev/null
+++ b/versions/8.5.1/images/essential_start.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/8.5.1/images/extend.svg b/versions/8.5.1/images/extend.svg
new file mode 100644
index 00000000..77b2dd97
--- /dev/null
+++ b/versions/8.5.1/images/extend.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/8.5.1/images/guide.svg b/versions/8.5.1/images/guide.svg
new file mode 100644
index 00000000..23a5d35a
--- /dev/null
+++ b/versions/8.5.1/images/guide.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/8.5.1/images/high-level-build-system.png b/versions/8.5.1/images/high-level-build-system.png
new file mode 100644
index 00000000..462717fa
Binary files /dev/null and b/versions/8.5.1/images/high-level-build-system.png differ
diff --git a/versions/8.5.1/images/new_1.svg b/versions/8.5.1/images/new_1.svg
new file mode 100644
index 00000000..c4cd9dfd
--- /dev/null
+++ b/versions/8.5.1/images/new_1.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/8.5.1/images/new_2.svg b/versions/8.5.1/images/new_2.svg
new file mode 100644
index 00000000..c6b7021b
--- /dev/null
+++ b/versions/8.5.1/images/new_2.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/8.5.1/images/new_3.svg b/versions/8.5.1/images/new_3.svg
new file mode 100644
index 00000000..c2afb4ac
--- /dev/null
+++ b/versions/8.5.1/images/new_3.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/8.5.1/images/placeholder.png b/versions/8.5.1/images/placeholder.png
new file mode 100644
index 00000000..54f1fa0e
Binary files /dev/null and b/versions/8.5.1/images/placeholder.png differ
diff --git a/versions/8.5.1/images/reference.svg b/versions/8.5.1/images/reference.svg
new file mode 100644
index 00000000..7bbc9bea
--- /dev/null
+++ b/versions/8.5.1/images/reference.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/8.5.1/images/release_notes.svg b/versions/8.5.1/images/release_notes.svg
new file mode 100644
index 00000000..8a2e8b56
--- /dev/null
+++ b/versions/8.5.1/images/release_notes.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/8.5.1/images/remote-execution-system.png b/versions/8.5.1/images/remote-execution-system.png
new file mode 100644
index 00000000..8152fc0c
Binary files /dev/null and b/versions/8.5.1/images/remote-execution-system.png differ
diff --git a/versions/8.5.1/images/start.svg b/versions/8.5.1/images/start.svg
new file mode 100644
index 00000000..3bcebd7b
--- /dev/null
+++ b/versions/8.5.1/images/start.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/8.5.1/images/task-dependencies.png b/versions/8.5.1/images/task-dependencies.png
new file mode 100644
index 00000000..ae1f9c51
Binary files /dev/null and b/versions/8.5.1/images/task-dependencies.png differ
diff --git a/versions/8.5.1/images/test.png b/versions/8.5.1/images/test.png
new file mode 100644
index 00000000..243939da
Binary files /dev/null and b/versions/8.5.1/images/test.png differ
diff --git a/versions/8.5.1/images/transitive-dependencies.png b/versions/8.5.1/images/transitive-dependencies.png
new file mode 100644
index 00000000..ec641a08
Binary files /dev/null and b/versions/8.5.1/images/transitive-dependencies.png differ
diff --git a/versions/8.5.1/images/trunk-logo-dark.svg b/versions/8.5.1/images/trunk-logo-dark.svg
new file mode 100644
index 00000000..f25940af
--- /dev/null
+++ b/versions/8.5.1/images/trunk-logo-dark.svg
@@ -0,0 +1,22 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/versions/8.5.1/images/why_faq.svg b/versions/8.5.1/images/why_faq.svg
new file mode 100644
index 00000000..afec3f8f
--- /dev/null
+++ b/versions/8.5.1/images/why_faq.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/8.5.1/images/why_overview.svg b/versions/8.5.1/images/why_overview.svg
new file mode 100644
index 00000000..c10c363c
--- /dev/null
+++ b/versions/8.5.1/images/why_overview.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/8.5.1/images/why_vision.svg b/versions/8.5.1/images/why_vision.svg
new file mode 100644
index 00000000..739e415f
--- /dev/null
+++ b/versions/8.5.1/images/why_vision.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/8.5.1/install/bazelisk.mdx b/versions/8.5.1/install/bazelisk.mdx
index b3bd88a9..d53e96bd 100644
--- a/versions/8.5.1/install/bazelisk.mdx
+++ b/versions/8.5.1/install/bazelisk.mdx
@@ -16,8 +16,7 @@ For more details, see
 ## Updating Bazel
 
 Bazel has a [backward compatibility policy](/versions/8.5.1/release/backward-compatibility)
-(see [guidance for rolling out incompatible
-changes](/versions/8.5.1/contribute/breaking-changes) if you
+(see [guidance for rolling out incompatible changes](/versions/8.5.1/contribute/breaking-changes) if you
 are the author of one). That page summarizes best practices on how to test and
 migrate your project with upcoming incompatible changes and how to provide
 feedback to the incompatible change authors.
diff --git a/versions/8.5.1/install/compile-source.mdx b/versions/8.5.1/install/compile-source.mdx
index c193471f..3943d9af 100644
--- a/versions/8.5.1/install/compile-source.mdx
+++ b/versions/8.5.1/install/compile-source.mdx
@@ -45,8 +45,7 @@ it by typing `bazel` in a terminal.
 
 **Reason**: To build Bazel from a GitHub source tree, you need a pre-existing
 Bazel binary. You can install one from a package manager or download one from
-GitHub. See [Installing Bazel](/versions/8.5.1/install). (Or you can [build from
-scratch (bootstrap)](#bootstrap-bazel).)
+GitHub. See [Installing Bazel](/versions/8.5.1/install). (Or you can [build from scratch (bootstrap)](#bootstrap-bazel).)
 
 **Troubleshooting**:
 
@@ -239,8 +238,7 @@ For instructions for Unix-like systems, see
     ```
 
 *   **The Visual C++ compiler.** Install the Visual C++ compiler either as part
-    of Visual Studio 2015 or newer, or by installing the latest [Build Tools
-    for Visual Studio 2017](https://aka.ms/BuildTools).
+    of Visual Studio 2015 or newer, or by installing the latest [Build Tools for Visual Studio 2017](https://aka.ms/BuildTools).
 
 *   **JDK.** Version 21 is required.
 
diff --git a/versions/8.5.1/install/ide.mdx b/versions/8.5.1/install/ide.mdx
index 561d0e02..c42d95e9 100644
--- a/versions/8.5.1/install/ide.mdx
+++ b/versions/8.5.1/install/ide.mdx
@@ -38,10 +38,8 @@ To install, go to the IDE's plugin browser and search for `Bazel`.
 To manually install older versions, download the zip files from JetBrains'
 Plugin Repository and install the zip file from the IDE's plugin browser:
 
-*  [Android Studio
-   plugin](https://plugins.jetbrains.com/plugin/9185-android-studio-with-bazel)
-*  [IntelliJ
-   plugin](https://plugins.jetbrains.com/plugin/8609-intellij-with-bazel)
+*  [Android Studio plugin](https://plugins.jetbrains.com/plugin/9185-android-studio-with-bazel)
+*  [IntelliJ plugin](https://plugins.jetbrains.com/plugin/8609-intellij-with-bazel)
 *  [CLion plugin](https://plugins.jetbrains.com/plugin/9554-clion-with-bazel)
 
 ### Xcode {#xcode}
@@ -61,8 +59,7 @@ Features:
 * Starlark debugger for `.bzl` files during a build (set breakpoints, step
   through code, inspect variables, and so on)
 
-Find [the plugin on the Visual Studio
-marketplace](https://marketplace.visualstudio.com/items?itemName=BazelBuild.vscode-bazel).
+Find [the plugin on the Visual Studio marketplace](https://marketplace.visualstudio.com/items?itemName=BazelBuild.vscode-bazel).
 The plugin is [open source](https://github.com/bazelbuild/vscode-bazel).
 
 See also: [Autocomplete for Source Code](#autocomplete-for-source-code)
@@ -82,8 +79,7 @@ See also: [Autocomplete for Source Code](#autocomplete-for-source-code)
 
 ### Emacs {#emacs}
 
-See [`bazelbuild/bazel-emacs-mode` on
-GitHub](https://github.com/bazelbuild/emacs-bazel-mode)
+See [`bazelbuild/bazel-emacs-mode` on GitHub](https://github.com/bazelbuild/emacs-bazel-mode)
 
 See also: [Autocomplete for Source Code](#autocomplete-for-source-code)
 
@@ -115,6 +111,5 @@ tool for building Bazel targets when source files change.
 
 ## Building your own IDE plugin {#build-own-plugin}
 
-Read the [**IDE support** blog
-post](https://blog.bazel.build/2016/06/10/ide-support.html) to learn more about
+Read the [**IDE support** blog post](https://blog.bazel.build/2016/06/10/ide-support.html) to learn more about
 the Bazel APIs to use when building an IDE plugin.
diff --git a/versions/8.5.1/install/images/bazelisk.svg b/versions/8.5.1/install/images/bazelisk.svg
new file mode 100644
index 00000000..c0ae9f54
--- /dev/null
+++ b/versions/8.5.1/install/images/bazelisk.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/8.5.1/install/images/cli.svg b/versions/8.5.1/install/images/cli.svg
new file mode 100644
index 00000000..01119280
--- /dev/null
+++ b/versions/8.5.1/install/images/cli.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/8.5.1/install/images/docker.svg b/versions/8.5.1/install/images/docker.svg
new file mode 100644
index 00000000..21190ce0
--- /dev/null
+++ b/versions/8.5.1/install/images/docker.svg
@@ -0,0 +1,6 @@
+
\ No newline at end of file
diff --git a/versions/8.5.1/install/images/github.svg b/versions/8.5.1/install/images/github.svg
new file mode 100644
index 00000000..aa05db9c
--- /dev/null
+++ b/versions/8.5.1/install/images/github.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/8.5.1/install/images/install.svg b/versions/8.5.1/install/images/install.svg
new file mode 100644
index 00000000..ae080865
--- /dev/null
+++ b/versions/8.5.1/install/images/install.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/8.5.1/install/images/mac.svg b/versions/8.5.1/install/images/mac.svg
new file mode 100644
index 00000000..3ee4fe28
--- /dev/null
+++ b/versions/8.5.1/install/images/mac.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/8.5.1/install/images/redhat.svg b/versions/8.5.1/install/images/redhat.svg
new file mode 100644
index 00000000..078b3387
--- /dev/null
+++ b/versions/8.5.1/install/images/redhat.svg
@@ -0,0 +1,69 @@
+
+
+  
+    
+      
+        image/svg+xml
+        
+        
+      
+    
+  
+  
+  
+    
+  
+  
+  
+
diff --git a/versions/8.5.1/install/images/suse.png b/versions/8.5.1/install/images/suse.png
new file mode 100644
index 00000000..6435b689
Binary files /dev/null and b/versions/8.5.1/install/images/suse.png differ
diff --git a/versions/8.5.1/install/images/tune.svg b/versions/8.5.1/install/images/tune.svg
new file mode 100644
index 00000000..8d7d63cb
--- /dev/null
+++ b/versions/8.5.1/install/images/tune.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/8.5.1/install/images/ubuntu.svg b/versions/8.5.1/install/images/ubuntu.svg
new file mode 100644
index 00000000..f217bc8d
--- /dev/null
+++ b/versions/8.5.1/install/images/ubuntu.svg
@@ -0,0 +1,8 @@
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/versions/8.5.1/install/images/windows.svg b/versions/8.5.1/install/images/windows.svg
new file mode 100644
index 00000000..120b0190
--- /dev/null
+++ b/versions/8.5.1/install/images/windows.svg
@@ -0,0 +1,5 @@
+
+
+
+
+
\ No newline at end of file
diff --git a/versions/8.5.1/install/windows.mdx b/versions/8.5.1/install/windows.mdx
index bff9ff8e..b9d210ba 100644
--- a/versions/8.5.1/install/windows.mdx
+++ b/versions/8.5.1/install/windows.mdx
@@ -31,8 +31,7 @@ To check your Windows version:
 
 Alternatively you can:
 
-*   [Download the Bazel binary (`bazel-version-windows-x86_64.exe`) from
- GitHub](https://github.com/bazelbuild/bazel/releases).
+*   [Download the Bazel binary (`bazel-version-windows-x86_64.exe`) from GitHub](https://github.com/bazelbuild/bazel/releases).
 *   [Install Bazel from Chocolatey](#chocolately)
 *   [Install Bazel from Scoop](#scoop)
 *   [Build Bazel from source](/versions/8.5.1/install/compile-source)
@@ -208,8 +207,7 @@ If that doesn't help:
     its dependencies, such as the MSYS2 shell. This will not install Visual C++
     though.
 
-See [Chocolatey installation and package maintenance
-guide](/versions/8.5.1/contribute/windows-chocolatey-maintenance) for more
+See [Chocolatey installation and package maintenance guide](/versions/8.5.1/contribute/windows-chocolatey-maintenance) for more
 information about the Chocolatey package.
 
 ### Using Scoop {#scoop}
@@ -226,8 +224,7 @@ information about the Chocolatey package.
     scoop install bazel
     ```
 
-See [Scoop installation and package maintenance
-guide](/versions/8.5.1/contribute/windows-scoop-maintenance) for more
+See [Scoop installation and package maintenance guide](/versions/8.5.1/contribute/windows-scoop-maintenance) for more
 information about the Scoop package.
 
 ### Build from source {#build-from-source}
diff --git a/versions/8.5.1/migrate/maven.mdx b/versions/8.5.1/migrate/maven.mdx
index 4f1b4f66..0ce791d4 100644
--- a/versions/8.5.1/migrate/maven.mdx
+++ b/versions/8.5.1/migrate/maven.mdx
@@ -19,8 +19,7 @@ directly run by Bazel since there's no Maven compatibility layer.
 ## Before you begin {#before-you-begin}
 
 *   [Install Bazel](/versions/8.5.1/install) if it's not yet installed.
-*   If you're new to Bazel, go through the tutorial [Introduction to Bazel:
-    Build Java](/versions/8.5.1/start/java) before you start migrating. The tutorial explains
+*   If you're new to Bazel, go through the tutorial [Introduction to Bazel: Build Java](/versions/8.5.1/start/java) before you start migrating. The tutorial explains
     Bazel's concepts, structure, and label syntax.
 
 ## Differences between Maven and Bazel {#dif-maven-bazel}
@@ -44,8 +43,7 @@ The steps below describe how to migrate your project to Bazel:
 3.  [Create more BUILD files](#3-build)
 4.  [Build using Bazel](#4-build)
 
-Examples below come from a migration of the [Guava
-project](https://github.com/google/guava) from Maven to Bazel. The
+Examples below come from a migration of the [Guava project](https://github.com/google/guava) from Maven to Bazel. The
 Guava project used is release `v31.1`. The examples using Guava do not walk
 through each step in the migration, but they do show the files and contents that
 are generated or added manually for the migration.
@@ -63,14 +61,12 @@ has no external dependencies, this file can be empty.
 If your project depends on files or packages that are not in one of the
 project's directories, specify these external dependencies in the MODULE.bazel
 file. You can use `rules_jvm_external` to manage dependencies from Maven. For
-instructions about using this ruleset, see [the
-README](https://github.com/bazelbuild/rules_jvm_external/#rules_jvm_external)
+instructions about using this ruleset, see [the README](https://github.com/bazelbuild/rules_jvm_external/#rules_jvm_external)
 .
 
 #### Guava project example: external dependencies {#guava-1}
 
-You can list the external dependencies of the [Guava
-project](https://github.com/google/guava) with the
+You can list the external dependencies of the [Guava project](https://github.com/google/guava) with the
 [`rules_jvm_external`](https://github.com/bazelbuild/rules_jvm_external)
 ruleset.
 
@@ -164,8 +160,7 @@ your build by adding more `BUILD` files with more granular targets.
             *   `resources`: Use globbing to list all resources in your project.
             *   `deps`: You need to determine which external dependencies your
                 project needs.
-        *   Take a look at the [example below of this top-level BUILD
-            file](#guava-2) from the migration of the Guava project.
+        *   Take a look at the [example below of this top-level BUILD file](#guava-2) from the migration of the Guava project.
 
 3.  Now that you have a `BUILD` file at the root of your project, build your
     project to ensure that it works. On the command line, from your workspace
diff --git a/versions/8.5.1/migrate/xcode.mdx b/versions/8.5.1/migrate/xcode.mdx
index ca2e47e4..af6f40b6 100644
--- a/versions/8.5.1/migrate/xcode.mdx
+++ b/versions/8.5.1/migrate/xcode.mdx
@@ -32,8 +32,7 @@ Before you begin, do the following:
 
 1.  [Install Bazel](/versions/8.5.1/install) if you have not already done so.
 
-2.  If you're not familiar with Bazel and its concepts, complete the [iOS app
-    tutorial](/versions/8.5.1/start/ios-app)). You should understand the Bazel workspace,
+2.  If you're not familiar with Bazel and its concepts, complete the [iOS app tutorial](/versions/8.5.1/start/ios-app)). You should understand the Bazel workspace,
     including the `MODULE.bazel` and `BUILD` files, as well as the concepts of
     targets, build rules, and Bazel packages.
 
@@ -44,8 +43,7 @@ Before you begin, do the following:
 Unlike Xcode, Bazel requires you to explicitly declare all dependencies for
 every target in the `BUILD` file.
 
-For more information on external dependencies, see [Working with external
-dependencies](/versions/8.5.1/docs/external).
+For more information on external dependencies, see [Working with external dependencies](/versions/8.5.1/docs/external).
 
 ## Build or test an Xcode project with Bazel {#build-xcode-project}
 
@@ -84,8 +82,7 @@ Note: Place the project source code within the directory tree containing the
 
 To integrate SwiftPM dependencies into the Bazel workspace with
 [swift_bazel](https://github.com/cgrindel/swift_bazel), you must
-convert them into Bazel packages as described in the [following
-tutorial](https://chuckgrindel.com/swift-packages-in-bazel-using-swift_bazel/)
+convert them into Bazel packages as described in the [following tutorial](https://chuckgrindel.com/swift-packages-in-bazel-using-swift_bazel/)
 .
 
 Note: SwiftPM support is a manual process with many variables. SwiftPM
@@ -103,8 +100,7 @@ initial build of the project as follows:
 *   [Step 3b: (Optional) Add the test target(s)](#step-3b-optional-add-the-test-target-s)
 *   [Step 3c: Add the library target(s)](#step-3c-add-the-library-target-s)
 
-**Tip:** To learn more about packages and other Bazel concepts, see [Workspaces,
-packages, and targets](/versions/8.5.1/concepts/build-ref).
+**Tip:** To learn more about packages and other Bazel concepts, see [Workspaces, packages, and targets](/versions/8.5.1/concepts/build-ref).
 
 #### Step 3a: Add the application target {#add-app-target}
 
@@ -132,8 +128,7 @@ In the target, specify the following at the minimum:
 
 #### Step 3b: (Optional) Add the test target(s) {#add-test-target}
 
-Bazel's [Apple build
-rules](https://github.com/bazelbuild/rules_apple) support running
+Bazel's [Apple build rules](https://github.com/bazelbuild/rules_apple) support running
 unit and UI tests on all Apple platforms. Add test targets as follows:
 
 *   [`macos_unit_test`](https://github.com/bazelbuild/rules_apple/blob/master/doc/rules-macos.md#macos_unit_test)
@@ -181,8 +176,7 @@ all sources and/or headers of a certain type. Use it carefully as it might
 include files you do not want Bazel to build.
 
 You can browse existing examples for various types of applications directly in
-the [rules_apple examples
-directory](https://github.com/bazelbuild/rules_apple/tree/master/examples/). For
+the [rules_apple examples directory](https://github.com/bazelbuild/rules_apple/tree/master/examples/). For
 example:
 
 *   [macOS application targets](https://github.com/bazelbuild/rules_apple/tree/master/examples/macos)
@@ -191,8 +185,7 @@ example:
 
 *   [Multi platform applications (macOS, iOS, watchOS, tvOS)](https://github.com/bazelbuild/rules_apple/tree/master/examples/multi_platform)
 
-For more information on build rules, see [Apple Rules for
-Bazel](https://github.com/bazelbuild/rules_apple).
+For more information on build rules, see [Apple Rules for Bazel](https://github.com/bazelbuild/rules_apple).
 
 At this point, it is a good idea to test the build:
 
diff --git a/versions/8.5.1/query/cquery.mdx b/versions/8.5.1/query/cquery.mdx
index c4721b50..75f8bb8a 100644
--- a/versions/8.5.1/query/cquery.mdx
+++ b/versions/8.5.1/query/cquery.mdx
@@ -6,8 +6,7 @@ title: ' Configurable Query (cquery)'
 [`select()`](/versions/8.5.1/docs/configurable-attributes) and build options' effects on the build
 graph.
 
-It achieves this by running over the results of Bazel's [analysis
-phase](/versions/8.5.1/extending/concepts#evaluation-model),
+It achieves this by running over the results of Bazel's [analysis phase](/versions/8.5.1/extending/concepts#evaluation-model),
 which integrates these effects. `query`, by contrast, runs over the results of
 Bazel's loading phase, before options are evaluated.
 
@@ -137,8 +136,7 @@ $ bazel cquery //foo --universe_scope=//foo,//genrule_with_foo_as_tool
 If you want to precisely declare which instance to query over, use
 the [`config`](#config) function.
 
-See `query`'s [target pattern
-documentation](/versions/8.5.1/query/language#target-patterns) for more information on target patterns.
+See `query`'s [target pattern documentation](/versions/8.5.1/query/language#target-patterns) for more information on target patterns.
 
 ## Functions {#functions}
 
diff --git a/versions/8.5.1/query/images/query_graph1.png b/versions/8.5.1/query/images/query_graph1.png
new file mode 100644
index 00000000..7bc9a61a
Binary files /dev/null and b/versions/8.5.1/query/images/query_graph1.png differ
diff --git a/versions/8.5.1/query/images/query_graph2.png b/versions/8.5.1/query/images/query_graph2.png
new file mode 100644
index 00000000..a0da22ff
Binary files /dev/null and b/versions/8.5.1/query/images/query_graph2.png differ
diff --git a/versions/8.5.1/query/images/query_graph3.png b/versions/8.5.1/query/images/query_graph3.png
new file mode 100644
index 00000000..4418f193
Binary files /dev/null and b/versions/8.5.1/query/images/query_graph3.png differ
diff --git a/versions/8.5.1/query/language.mdx b/versions/8.5.1/query/language.mdx
index 521b16d7..7243addc 100644
--- a/versions/8.5.1/query/language.mdx
+++ b/versions/8.5.1/query/language.mdx
@@ -1120,8 +1120,7 @@ is being used.
 
 ### On the ordering of results {#results-ordering}
 
-Although query expressions always follow the "[law of
-conservation of graph order](#graph-order)", _presenting_ the results may be done
+Although query expressions always follow the "[law of conservation of graph order](#graph-order)", _presenting_ the results may be done
 in either a dependency-ordered or unordered manner. This does **not**
 influence the targets in the result set or how the query is computed. It only
 affects how the results are printed to stdout. Moreover, nodes that are
@@ -1267,8 +1266,7 @@ and `maxrank` output formats print the labels of each
 target in the resulting graph, but instead of appearing in
 topological order, they appear in rank order, preceded by their
 rank number. These are unaffected by the result ordering
-`--[no]order_results` flag (see [notes on
-the ordering of results](#result-order)).
+`--[no]order_results` flag (see [notes on the ordering of results](#result-order)).
 
 There are two variants of this format: `minrank` ranks
 each node by the length of the shortest path from a root node to it.
diff --git a/versions/8.5.1/query/quickstart.mdx b/versions/8.5.1/query/quickstart.mdx
index 4c8705c7..a9d2b024 100644
--- a/versions/8.5.1/query/quickstart.mdx
+++ b/versions/8.5.1/query/quickstart.mdx
@@ -205,7 +205,7 @@ dot -Tpng < graph.in > graph.png
 ```
 If you open up `graph.png`, you should see something like this. The graph below has been simplified to make the essential path details clearer in this guide.
 
-![Diagram showing a relationship from cafe to chef to the dishes: pizza and mac and cheese which diverges into the separate ingredients: cheese, tomatoes, dough, and macaroni.](images/query_graph1.png "Dependency graph")
+![Diagram showing a relationship from cafe to chef to the dishes: pizza and mac and cheese which diverges into the separate ingredients: cheese, tomatoes, dough, and macaroni.](/versions/8.5.1/query/images/query_graph1.png "Dependency graph")
 
 This helps when you want to see the outputs of the different query functions throughout this guide.
 
@@ -421,7 +421,7 @@ bazel query --noimplicit_deps 'deps(:runner)' --output graph > graph2.in
 dot -Tpng < graph2.in > graph2.png
 ```
 
-[![The same graph as the first one except now there is a spoke stemming from the chef target with smoothie which leads to banana and strawberry](images/query_graph2.png "Updated dependency graph")](images/query_graph2.png)
+[![The same graph as the first one except now there is a spoke stemming from the chef target with smoothie which leads to banana and strawberry](/versions/8.5.1/query/images/query_graph2.png "Updated dependency graph")](/query/images/query_graph2.png)
 
 Looking at `graph2.png`, you can see that `Smoothie` has no shared dependencies with other dishes but is just another target that the `Chef` relies on.
 
@@ -465,7 +465,7 @@ bazel query "allpaths(//src/main/java/com/example/restaurant/..., //src/main/jav
 //src/main/java/com/example/restaurant:chef
 ```
 
-![Output path of cafe to chef to pizza,mac and cheese to cheese](images/query_graph3.png "Output path for dependency")
+![Output path of cafe to chef to pizza,mac and cheese to cheese](/versions/8.5.1/query/images/query_graph3.png "Output path for dependency")
 
 The output of `allpaths()` is a little harder to read as it is a flattened list of the dependencies. Visualizing this graph using Graphviz makes the relationship clearer to understand.
 
diff --git a/versions/8.5.1/reference/be/c-cpp.mdx b/versions/8.5.1/reference/be/c-cpp.mdx
index 0dc11270..29877019 100644
--- a/versions/8.5.1/reference/be/c-cpp.mdx
+++ b/versions/8.5.1/reference/be/c-cpp.mdx
@@ -61,7 +61,7 @@ be `main`.
 | `hdrs_check` | String; default is `""` Deprecated, no-op. |
 | `includes` | List of strings; default is `[]` List of include dirs to be added to the compile line. Subject to ["Make variable"](/versions/8.5.1/reference/be/make-variables) substitution. Each string is prepended with the package path and passed to the C++ toolchain for expansion via the "include\_paths" CROSSTOOL feature. A toolchain running on a POSIX system with typical feature definitions will produce `-isystem path_to_package/include_entry`. This should only be used for third-party libraries that do not conform to the Google style of writing #include statements. Unlike [COPTS](#cc_binary.copts), these flags are added for this rule and every rule that depends on it. (Note: not the rules it depends upon!) Be very careful, since this may have far-reaching effects. When in doubt, add "-I" flags to [COPTS](#cc_binary.copts) instead. The added `include` paths will include generated files as well as files in the source tree. |
 | `link_extra_lib` | [Label](/versions/8.5.1/concepts/labels); default is `"@bazel_tools//tools/cpp:link_extra_lib"` Control linking of extra libraries. By default, C++ binaries are linked against `//tools/cpp:link_extra_lib`, which by default depends on the label flag `//tools/cpp:link_extra_libs`. Without setting the flag, this library is empty by default. Setting the label flag allows linking optional dependencies, such as overrides for weak symbols, interceptors for shared library functions, or special runtime libraries (for malloc replacements, prefer `malloc` or `--custom_malloc`). Setting this attribute to `None` disables this behaviour. |
-| `linkopts` | List of strings; default is `[]` Add these flags to the C++ linker command. Subject to ["Make" variable](make-variables) substitution, [Bourne shell tokenization](common-definitions#sh-tokenization) and [label expansion](common-definitions#label-expansion). Each string in this attribute is added to `LINKOPTS` before linking the binary target. Each element of this list that does not start with `$` or `-` is assumed to be the label of a target in `deps`. The list of files generated by that target is appended to the linker options. An error is reported if the label is invalid, or is not declared in `deps`. |
+| `linkopts` | List of strings; default is `[]` Add these flags to the C++ linker command. Subject to ["Make" variable](/versions/8.5.1/reference/be/make-variables) substitution, [Bourne shell tokenization](/versions/8.5.1/reference/be/common-definitions#sh-tokenization) and [label expansion](/versions/8.5.1/reference/be/common-definitions#label-expansion). Each string in this attribute is added to `LINKOPTS` before linking the binary target. Each element of this list that does not start with `$` or `-` is assumed to be the label of a target in `deps`. The list of files generated by that target is appended to the linker options. An error is reported if the label is invalid, or is not declared in `deps`. |
 | `linkshared` | Boolean; default is `False` Create a shared library. To enable this attribute, include `linkshared=True` in your rule. By default this option is off. The presence of this flag means that linking occurs with the `-shared` flag to `gcc`, and the resulting shared library is suitable for loading into for example a Java program. However, for build purposes it will never be linked into the dependent binary, as it is assumed that shared libraries built with a [cc\_binary](#cc_binary) rule are only loaded manually by other programs, so it should not be considered a substitute for the [cc\_library](#cc_library) rule. For sake of scalability we recommend avoiding this approach altogether and simply letting `java_library` depend on `cc_library` rules instead.  If you specify both `linkopts=['-static']` and `linkshared=True`, you get a single completely self-contained unit. If you specify both `linkstatic=True` and `linkshared=True`, you get a single, mostly self-contained unit. |
 | `linkstatic` | Boolean; default is `True` For [`cc_binary`](/versions/8.5.1/reference/be/c-cpp#cc_binary) and [`cc_test`](/versions/8.5.1/reference/be/c-cpp#cc_test): link the binary in static mode. For `cc_library.link_static`: see below. By default this option is on for `cc_binary` and off for the rest.  If enabled and this is a binary or test, this option tells the build tool to link in `.a`'s instead of `.so`'s for user libraries whenever possible. System libraries such as libc (but *not* the C/C++ runtime libraries, see below) are still linked dynamically, as are libraries for which there is no static library. So the resulting executable will still be dynamically linked, hence only *mostly* static.  There are really three different ways to link an executable:   * STATIC with fully\_static\_link feature, in which everything is linked statically;   e.g. "`gcc -static foo.o libbar.a libbaz.a -lm`".    This mode is enabled by specifying `fully_static_link` in the   [`features`](/versions/8.5.1/reference/be/common-definitions#features) attribute. * STATIC, in which all user libraries are linked statically (if a static   version is available), but where system libraries (excluding C/C++ runtime libraries)   are linked dynamically, e.g. "`gcc foo.o libfoo.a libbaz.a -lm`".    This mode is enabled by specifying `linkstatic=True`. * DYNAMIC, in which all libraries are linked dynamically (if a dynamic version is   available), e.g. "`gcc foo.o libfoo.so libbaz.so -lm`".    This mode is enabled by specifying `linkstatic=False`.   If the `linkstatic` attribute or `fully_static_link` in `features` is used outside of `//third_party` please include a comment near the rule to explain why.  The `linkstatic` attribute has a different meaning if used on a [`cc_library()`](/versions/8.5.1/reference/be/c-cpp#cc_library) rule. For a C++ library, `linkstatic=True` indicates that only static linking is allowed, so no `.so` will be produced. linkstatic=False does not prevent static libraries from being created. The attribute is meant to control the creation of dynamic libraries.  There should be very little code built with `linkstatic=False` in production. If `linkstatic=False`, then the build tool will create symlinks to depended-upon shared libraries in the `*.runfiles` area. |
 | `local_defines` | List of strings; default is `[]` List of defines to add to the compile line. Subject to ["Make" variable](/versions/8.5.1/reference/be/make-variables) substitution and [Bourne shell tokenization](/versions/8.5.1/reference/be/common-definitions#sh-tokenization). Each string, which must consist of a single Bourne shell token, is prepended with `-D` and added to the compile command line for this target, but not to its dependents. |
@@ -229,7 +229,7 @@ cc_import(
 | `alwayslink` | Boolean; default is `False` If 1, any binary that depends (directly or indirectly) on this C++ precompiled library will link in all the object files archived in the static library, even if some contain no symbols referenced by the binary. This is useful if your code isn't explicitly called by code in the binary, e.g., if your code registers to receive some callback provided by some service. If alwayslink doesn't work with VS 2017 on Windows, that is due to a [known issue](https://github.com/bazelbuild/bazel/issues/3949), please upgrade your VS 2017 to the latest version. |
 | `includes` | List of strings; default is `[]` List of include dirs to be added to the compile line. Subject to ["Make variable"](/versions/8.5.1/reference/be/make-variables) substitution. Each string is prepended with the package path and passed to the C++ toolchain for expansion via the "include\_paths" CROSSTOOL feature. A toolchain running on a POSIX system with typical feature definitions will produce `-isystem path_to_package/include_entry`. This should only be used for third-party libraries that do not conform to the Google style of writing #include statements. Unlike [COPTS](#cc_binary.copts), these flags are added for this rule and every rule that depends on it. (Note: not the rules it depends upon!) Be very careful, since this may have far-reaching effects. When in doubt, add "-I" flags to [COPTS](#cc_binary.copts) instead. The default `include` path doesn't include generated files. If you need to `#include` a generated header file, list it in the `srcs`. |
 | `interface_library` | [Label](/versions/8.5.1/concepts/labels); default is `None` A single interface library for linking the shared library. Permitted file types: `.ifso`, `.tbd`, `.lib`, `.so` or `.dylib` |
-| `linkopts` | List of strings; default is `[]` Add these flags to the C++ linker command. Subject to ["Make" variable](make-variables) substitution, [Bourne shell tokenization](common-definitions#sh-tokenization) and [label expansion](common-definitions#label-expansion). Each string in this attribute is added to `LINKOPTS` before linking the binary target. Each element of this list that does not start with `$` or `-` is assumed to be the label of a target in `deps`. The list of files generated by that target is appended to the linker options. An error is reported if the label is invalid, or is not declared in `deps`. |
+| `linkopts` | List of strings; default is `[]` Add these flags to the C++ linker command. Subject to ["Make" variable](/versions/8.5.1/reference/be/make-variables) substitution, [Bourne shell tokenization](/versions/8.5.1/reference/be/common-definitions#sh-tokenization) and [label expansion](/versions/8.5.1/reference/be/common-definitions#label-expansion). Each string in this attribute is added to `LINKOPTS` before linking the binary target. Each element of this list that does not start with `$` or `-` is assumed to be the label of a target in `deps`. The list of files generated by that target is appended to the linker options. An error is reported if the label is invalid, or is not declared in `deps`. |
 | `objects` | List of [labels](/versions/8.5.1/concepts/labels); default is `[]` |
 | `pic_objects` | List of [labels](/versions/8.5.1/concepts/labels); default is `[]` |
 | `pic_static_library` | [Label](/versions/8.5.1/concepts/labels); default is `None` |
@@ -454,7 +454,7 @@ cc_library(
 | `implementation_deps` | List of [labels](/versions/8.5.1/concepts/labels); default is `[]` The list of other libraries that the library target depends on. Unlike with `deps`, the headers and include paths of these libraries (and all their transitive deps) are only used for compilation of this library, and not libraries that depend on it. Libraries specified with `implementation_deps` are still linked in binary targets that depend on this library. |
 | `include_prefix` | String; default is `""` The prefix to add to the paths of the headers of this rule. When set, the headers in the `hdrs` attribute of this rule are accessible at is the value of this attribute prepended to their repository-relative path. The prefix in the `strip_include_prefix` attribute is removed before this prefix is added. This attribute is only legal under `third_party`. |
 | `includes` | List of strings; default is `[]` List of include dirs to be added to the compile line. Subject to ["Make variable"](/versions/8.5.1/reference/be/make-variables) substitution. Each string is prepended with the package path and passed to the C++ toolchain for expansion via the "include\_paths" CROSSTOOL feature. A toolchain running on a POSIX system with typical feature definitions will produce `-isystem path_to_package/include_entry`. This should only be used for third-party libraries that do not conform to the Google style of writing #include statements. Unlike [COPTS](#cc_binary.copts), these flags are added for this rule and every rule that depends on it. (Note: not the rules it depends upon!) Be very careful, since this may have far-reaching effects. When in doubt, add "-I" flags to [COPTS](#cc_binary.copts) instead. The added `include` paths will include generated files as well as files in the source tree. |
-| `linkopts` | List of strings; default is `[]` See [`cc_binary.linkopts`](/versions/8.5.1/reference/be/c-cpp#cc_binary.linkopts). The `linkopts` attribute is also applied to any target that depends, directly or indirectly, on this library via `deps` attributes (or via other attributes that are treated similarly: the [`malloc`](/versions/8.5.1/reference/be/c-cpp#cc_binary.malloc) attribute of [`cc_binary`](/versions/8.5.1/reference/be/c-cpp#cc_binary)). Dependency linkopts take precedence over dependent linkopts (i.e. dependency linkopts appear later in the command line). Linkopts specified in [`--linkopt`](../user-manual#flag--linkopt) take precedence over rule linkopts. |
+| `linkopts` | List of strings; default is `[]` See [`cc_binary.linkopts`](/versions/8.5.1/reference/be/c-cpp#cc_binary.linkopts). The `linkopts` attribute is also applied to any target that depends, directly or indirectly, on this library via `deps` attributes (or via other attributes that are treated similarly: the [`malloc`](/versions/8.5.1/reference/be/c-cpp#cc_binary.malloc) attribute of [`cc_binary`](/versions/8.5.1/reference/be/c-cpp#cc_binary)). Dependency linkopts take precedence over dependent linkopts (i.e. dependency linkopts appear later in the command line). Linkopts specified in [`--linkopt`](/versions/8.5.1/reference/user-manual#flag--linkopt) take precedence over rule linkopts. |
 
 Note that the `linkopts` attribute only applies
 when creating `.so` files or executables, not
@@ -736,7 +736,7 @@ that `cc_test` has extra [attributes common to all test rules (\*\_test)](/versi
 | `hdrs_check` | String; default is `""` Deprecated, no-op. |
 | `includes` | List of strings; default is `[]` List of include dirs to be added to the compile line. Subject to ["Make variable"](/versions/8.5.1/reference/be/make-variables) substitution. Each string is prepended with the package path and passed to the C++ toolchain for expansion via the "include\_paths" CROSSTOOL feature. A toolchain running on a POSIX system with typical feature definitions will produce `-isystem path_to_package/include_entry`. This should only be used for third-party libraries that do not conform to the Google style of writing #include statements. Unlike [COPTS](#cc_binary.copts), these flags are added for this rule and every rule that depends on it. (Note: not the rules it depends upon!) Be very careful, since this may have far-reaching effects. When in doubt, add "-I" flags to [COPTS](#cc_binary.copts) instead. The added `include` paths will include generated files as well as files in the source tree. |
 | `link_extra_lib` | [Label](/versions/8.5.1/concepts/labels); default is `"@bazel_tools//tools/cpp:link_extra_lib"` Control linking of extra libraries. By default, C++ binaries are linked against `//tools/cpp:link_extra_lib`, which by default depends on the label flag `//tools/cpp:link_extra_libs`. Without setting the flag, this library is empty by default. Setting the label flag allows linking optional dependencies, such as overrides for weak symbols, interceptors for shared library functions, or special runtime libraries (for malloc replacements, prefer `malloc` or `--custom_malloc`). Setting this attribute to `None` disables this behaviour. |
-| `linkopts` | List of strings; default is `[]` Add these flags to the C++ linker command. Subject to ["Make" variable](make-variables) substitution, [Bourne shell tokenization](common-definitions#sh-tokenization) and [label expansion](common-definitions#label-expansion). Each string in this attribute is added to `LINKOPTS` before linking the binary target. Each element of this list that does not start with `$` or `-` is assumed to be the label of a target in `deps`. The list of files generated by that target is appended to the linker options. An error is reported if the label is invalid, or is not declared in `deps`. |
+| `linkopts` | List of strings; default is `[]` Add these flags to the C++ linker command. Subject to ["Make" variable](/versions/8.5.1/reference/be/make-variables) substitution, [Bourne shell tokenization](/versions/8.5.1/reference/be/common-definitions#sh-tokenization) and [label expansion](/versions/8.5.1/reference/be/common-definitions#label-expansion). Each string in this attribute is added to `LINKOPTS` before linking the binary target. Each element of this list that does not start with `$` or `-` is assumed to be the label of a target in `deps`. The list of files generated by that target is appended to the linker options. An error is reported if the label is invalid, or is not declared in `deps`. |
 | `linkshared` | Boolean; default is `False` Create a shared library. To enable this attribute, include `linkshared=True` in your rule. By default this option is off. The presence of this flag means that linking occurs with the `-shared` flag to `gcc`, and the resulting shared library is suitable for loading into for example a Java program. However, for build purposes it will never be linked into the dependent binary, as it is assumed that shared libraries built with a [cc\_binary](#cc_binary) rule are only loaded manually by other programs, so it should not be considered a substitute for the [cc\_library](#cc_library) rule. For sake of scalability we recommend avoiding this approach altogether and simply letting `java_library` depend on `cc_library` rules instead.  If you specify both `linkopts=['-static']` and `linkshared=True`, you get a single completely self-contained unit. If you specify both `linkstatic=True` and `linkshared=True`, you get a single, mostly self-contained unit. |
 | `linkstatic` | Boolean; default is `False` For [`cc_binary`](/versions/8.5.1/reference/be/c-cpp#cc_binary) and [`cc_test`](/versions/8.5.1/reference/be/c-cpp#cc_test): link the binary in static mode. For `cc_library.link_static`: see below. By default this option is on for `cc_binary` and off for the rest.  If enabled and this is a binary or test, this option tells the build tool to link in `.a`'s instead of `.so`'s for user libraries whenever possible. System libraries such as libc (but *not* the C/C++ runtime libraries, see below) are still linked dynamically, as are libraries for which there is no static library. So the resulting executable will still be dynamically linked, hence only *mostly* static.  There are really three different ways to link an executable:   * STATIC with fully\_static\_link feature, in which everything is linked statically;   e.g. "`gcc -static foo.o libbar.a libbaz.a -lm`".    This mode is enabled by specifying `fully_static_link` in the   [`features`](/versions/8.5.1/reference/be/common-definitions#features) attribute. * STATIC, in which all user libraries are linked statically (if a static   version is available), but where system libraries (excluding C/C++ runtime libraries)   are linked dynamically, e.g. "`gcc foo.o libfoo.a libbaz.a -lm`".    This mode is enabled by specifying `linkstatic=True`. * DYNAMIC, in which all libraries are linked dynamically (if a dynamic version is   available), e.g. "`gcc foo.o libfoo.so libbaz.so -lm`".    This mode is enabled by specifying `linkstatic=False`.   If the `linkstatic` attribute or `fully_static_link` in `features` is used outside of `//third_party` please include a comment near the rule to explain why.  The `linkstatic` attribute has a different meaning if used on a [`cc_library()`](/versions/8.5.1/reference/be/c-cpp#cc_library) rule. For a C++ library, `linkstatic=True` indicates that only static linking is allowed, so no `.so` will be produced. linkstatic=False does not prevent static libraries from being created. The attribute is meant to control the creation of dynamic libraries.  There should be very little code built with `linkstatic=False` in production. If `linkstatic=False`, then the build tool will create symlinks to depended-upon shared libraries in the `*.runfiles` area. |
 | `local_defines` | List of strings; default is `[]` List of defines to add to the compile line. Subject to ["Make" variable](/versions/8.5.1/reference/be/make-variables) substitution and [Bourne shell tokenization](/versions/8.5.1/reference/be/common-definitions#sh-tokenization). Each string, which must consist of a single Bourne shell token, is prepended with `-D` and added to the compile command line for this target, but not to its dependents. |
diff --git a/versions/8.5.1/reference/be/common-definitions.mdx b/versions/8.5.1/reference/be/common-definitions.mdx
index ffe107f6..da3a5faf 100644
--- a/versions/8.5.1/reference/be/common-definitions.mdx
+++ b/versions/8.5.1/reference/be/common-definitions.mdx
@@ -75,11 +75,11 @@ rules.
 | `deprecation` | String; [nonconfigurable](#configurable-attributes); default is `None`  An explanatory warning message associated with this target. Typically this is used to notify users that a target has become obsolete, or has become superseded by another rule, is private to a package, or is perhaps considered harmful for some reason. It is a good idea to include some reference (like a webpage, a bug number or example migration CLs) so that one can easily find out what changes are required to avoid the message. If there is a new target that can be used as a drop in replacement, it is a good idea to just migrate all users of the old target.  This attribute has no effect on the way things are built, but it may affect a build tool's diagnostic output. The build tool issues a warning when a rule with a `deprecation` attribute is depended upon by a target in another package.  Intra-package dependencies are exempt from this warning, so that, for example, building the tests of a deprecated rule does not encounter a warning.  If a deprecated target depends on another deprecated target, no warning message is issued.  Once people have stopped using it, the target can be removed. |
 | `distribs` | List of strings; [nonconfigurable](#configurable-attributes); default is `[]`  A list of distribution-method strings to be used for this particular target. This is part of a deprecated licensing API that Bazel no longer uses. Don't use this. |
 | `exec_compatible_with` | List of [labels](/versions/8.5.1/concepts/labels); [nonconfigurable](#configurable-attributes); default is `[]`  A list of `constraint_values` that must be present in the execution platform for this target. This is in addition to any constraints already set by the rule type. Constraints are used to restrict the list of available execution platforms. For more details, see the description of [toolchain resolution](/versions/8.5.1/docs/toolchains#toolchain-resolution). |
-| `exec_properties` | Dictionary of strings; default is `{}`  A dictionary of strings that will be added to the `exec_properties` of a platform selected for this target. See `exec_properties` of the [platform](platforms-and-toolchains#platform) rule.  If a key is present in both the platform and target-level properties, the value will be taken from the target. |
+| `exec_properties` | Dictionary of strings; default is `{}`  A dictionary of strings that will be added to the `exec_properties` of a platform selected for this target. See `exec_properties` of the [platform](/versions/8.5.1/reference/be/platforms-and-toolchains#platform) rule.  If a key is present in both the platform and target-level properties, the value will be taken from the target. |
 | `features` | List of *feature* strings; default is `[]`  A feature is string tag that can be enabled or disabled on a target. The meaning of a feature depends on the rule itself.  This `features` attribute is combined with the [package](/versions/8.5.1/reference/be/functions#package) level `features` attribute. For example, if the features ["a", "b"] are enabled on the package level, and a target's `features` attribute contains ["-a", "c"], the features enabled for the rule will be "b" and "c". [See example](https://github.com/bazelbuild/examples/blob/main/rules/features/BUILD). |
 | `restricted_to` | List of [labels](/versions/8.5.1/concepts/labels); [nonconfigurable](#configurable-attributes); default is `[]`  The list of environments this target can be built for, *instead* of default-supported environments.  This is part of Bazel's constraint system. See `compatible_with` for details. |
 | `tags` | List of strings; [nonconfigurable](#configurable-attributes); default is `[]`  *Tags* can be used on any rule. *Tags* on test and `test_suite` rules are useful for categorizing the tests. *Tags* on non-test targets are used to control sandboxed execution of `genrule`s and [Starlark](/versions/8.5.1/rules/concepts) actions, and for parsing by humans and/or external tools.  Bazel modifies the behavior of its sandboxing code if it finds the following keywords in the `tags` attribute of any test or `genrule` target, or the keys of `execution_requirements` for any Starlark action.   * `no-sandbox` keyword results in the action or test never being   sandboxed; it can still be cached or run remotely - use `no-cache`   or `no-remote` to prevent either or both of those. * `no-cache` keyword results in the action or test never being   cached (locally or remotely). Note: for the purposes of this tag, the disk cache   is considered a local cache, whereas the HTTP and gRPC caches are considered   remote. Other caches, such as Skyframe or the persistent action cache, are not   affected. * `no-remote-cache` keyword results in the action or test never being   cached remotely (but it may be cached locally; it may also be executed remotely).   Note: for the purposes of this tag, the disk cache is considered a local cache,   whereas the HTTP and gRPC caches are considered remote. Other caches, such as   Skyframe or the persistent action cache, are not affected.   If a combination of local disk cache and remote cache are used (combined cache),   it's treated as a remote cache and disabled entirely unless `--incompatible_remote_results_ignore_disk`   is set in which case the local components will be used. * `no-remote-exec` keyword results in the action or test never being   executed remotely (but it may be cached remotely). * `no-remote` keyword prevents the action or test from being executed remotely or   cached remotely. This is equivalent to using both   `no-remote-cache` and `no-remote-exec`. * `no-remote-cache-upload` keyword disables upload part of remote caching of a spawn.   it does not disable remote execution. * `local` keyword precludes the action or test from being remotely cached,   remotely executed, or run inside the sandbox.   For genrules and tests, marking the rule with the `local = True`   attribute has the same effect. * `requires-network` keyword allows access to the external   network from inside the sandbox. This tag only has an effect if sandboxing   is enabled. * `block-network` keyword blocks access to the external   network from inside the sandbox. In this case, only communication   with localhost is allowed. This tag only has an effect if sandboxing is   enabled. * `requires-fakeroot` runs the test or action as uid and gid 0 (i.e., the root   user). This is only supported on Linux. This tag takes precedence over the   `--sandbox_fake_username` command-line option.   *Tags* on tests are generally used to annotate a test's role in your debug and release process. Typically, tags are most useful for C++ and Python tests, which lack any runtime annotation ability. The use of tags and size elements gives flexibility in assembling suites of tests based around codebase check-in policy.  Bazel modifies test running behavior if it finds the following keywords in the `tags` attribute of the test rule:   * `exclusive` will force the test to be run in the   "exclusive" mode, ensuring that no other tests are running at the   same time. Such tests will be executed in serial fashion after all build   activity and non-exclusive tests have been completed. Remote execution is   disabled for such tests because Bazel doesn't have control over what's   running on a remote machine. * `exclusive-if-local` will force the test to be run in the   "exclusive" mode if it is executed locally, but will run the test in parallel if it's   executed remotely. * `manual` keyword will exclude the target from expansion of target pattern wildcards   (`...`, `:*`, `:all`, etc.) and `test_suite` rules   which do not list the test explicitly when computing the set of top-level targets to build/run   for the `build`, `test`, and `coverage` commands. It does not   affect target wildcard or test suite expansion in other contexts, including the   `query` command. Note that `manual` does not imply that a target should   not be built/run automatically by continuous build/test systems. For example, it may be   desirable to exclude a target from `bazel test ...` because it requires specific   Bazel flags, but still have it included in properly-configured presubmit or continuous test   runs. * `external` keyword will force test to be unconditionally   executed (regardless of `--cache_test_results`   value).  See [Tag Conventions](/versions/8.5.1/reference/test-encyclopedia#tag-conventions) in the Test Encyclopedia for more conventions on tags attached to test targets. |
-| `target_compatible_with` | List of [labels](/versions/8.5.1/concepts/labels); default is `[]`  A list of `constraint_value`s that must be present in the target platform for this target to be considered *compatible*. This is in addition to any constraints already set by the rule type. If the target platform does not satisfy all listed constraints then the target is considered *incompatible*. Incompatible targets are skipped for building and testing when the target pattern is expanded (e.g. `//...`, `:all`). When explicitly specified on the command line, incompatible targets cause Bazel to print an error and cause a build or test failure.  Targets that transitively depend on incompatible targets are themselves considered incompatible. They are also skipped for building and testing.  An empty list (which is the default) signifies that the target is compatible with all platforms. All rules other than [Workspace Rules](workspace) support this attribute. For some rules this attribute has no effect. For example, specifying `target_compatible_with` for a `cc_toolchain` is not useful. See the [Platforms](/versions/8.5.1/docs/platforms#skipping-incompatible-targets) page for more information about incompatible target skipping. |
+| `target_compatible_with` | List of [labels](/versions/8.5.1/concepts/labels); default is `[]`  A list of `constraint_value`s that must be present in the target platform for this target to be considered *compatible*. This is in addition to any constraints already set by the rule type. If the target platform does not satisfy all listed constraints then the target is considered *incompatible*. Incompatible targets are skipped for building and testing when the target pattern is expanded (e.g. `//...`, `:all`). When explicitly specified on the command line, incompatible targets cause Bazel to print an error and cause a build or test failure.  Targets that transitively depend on incompatible targets are themselves considered incompatible. They are also skipped for building and testing.  An empty list (which is the default) signifies that the target is compatible with all platforms. All rules other than [Workspace Rules](/versions/8.5.1/reference/be/workspace) support this attribute. For some rules this attribute has no effect. For example, specifying `target_compatible_with` for a `cc_toolchain` is not useful. See the [Platforms](/versions/8.5.1/docs/platforms#skipping-incompatible-targets) page for more information about incompatible target skipping. |
 | `testonly` | Boolean; [nonconfigurable](#configurable-attributes); default is `False` except for test and test suite targets  If `True`, only testonly targets (such as tests) can depend on this target.  Equivalently, a rule that is not `testonly` is not allowed to depend on any rule that is `testonly`.  Tests (`*_test` rules) and test suites ([test\_suite](/versions/8.5.1/reference/be/general#test_suite) rules) are `testonly` by default.  This attribute is intended to mean that the target should not be contained in binaries that are released to production.  Because testonly is enforced at build time, not run time, and propagates virally through the dependency tree, it should be applied judiciously. For example, stubs and fakes that are useful for unit tests may also be useful for integration tests involving the same binaries that will be released to production, and therefore should probably not be marked testonly. Conversely, rules that are dangerous to even link in, perhaps because they unconditionally override normal behavior, should definitely be marked testonly. |
 | `toolchains` | List of [labels](/versions/8.5.1/concepts/labels); [nonconfigurable](#configurable-attributes); default is `[]`  The set of targets whose [Make variables](/versions/8.5.1/reference/be/make-variables) this target is allowed to access. These targets are either instances of rules that provide `TemplateVariableInfo` or special targets for toolchain types built into Bazel. These include:  * `@bazel_tools//tools/cpp:current_cc_toolchain`* `@rules_java//toolchains:current_java_runtime`   Note that this is distinct from the concept of [toolchain resolution](/versions/8.5.1/docs/toolchains#toolchain-resolution) that is used by rule implementations for platform-dependent configuration. You cannot use this attribute to determine which specific `cc_toolchain` or `java_toolchain` a target will use. |
 | `visibility` | List of [labels](/versions/8.5.1/concepts/labels); [nonconfigurable](#configurable-attributes); default varies  The `visibility` attribute controls whether the target can be depended on by targets in other locations. See the documentation for [visibility](/versions/8.5.1/concepts/visibility).  For targets declared directly in a BUILD file or in legacy macros called from a BUILD file, the default value is the package's `default_visibility` if specified, or else `["//visibility:private"]`. For targets declared in one or more symbolic macros, the default value is always just `["//visibility:private"]` (which makes it useable only within the package containing the macro's code). |
diff --git a/versions/8.5.1/reference/be/functions.mdx b/versions/8.5.1/reference/be/functions.mdx
index 58e36d7a..c06e6625 100644
--- a/versions/8.5.1/reference/be/functions.mdx
+++ b/versions/8.5.1/reference/be/functions.mdx
@@ -34,9 +34,9 @@ file, before any rule.
 | --- | --- |
 | `default_applicable_licenses` | Alias for [`default_package_metadata`](#package.default_package_metadata). |
 | `default_visibility` | List of [labels](/versions/8.5.1/concepts/labels); default is `[]`  The default visibility of the top-level rule targets and symbolic macros in this package — that is, the targets and symbolic macros that are not themselves declared inside a symbolic macro. This attribute is ignored if the target or macro specifies a `visibility` value.  For detailed information about the syntax of this attribute, see the documentation of [visibility](/versions/8.5.1/concepts/visibility). The package default visibility does not apply to [exports\_files](#exports_files), which is public by default. |
-| `default_deprecation` | String; default is `""`  Sets the default [`deprecation`](common-definitions#common.deprecation) message for all rules in this package. |
+| `default_deprecation` | String; default is `""`  Sets the default [`deprecation`](/versions/8.5.1/reference/be/common-definitions#common.deprecation) message for all rules in this package. |
 | `default_package_metadata` | List of [labels](/versions/8.5.1/concepts/labels); default is `[]`  Sets a default list of metadata targets which apply to all other targets in the package. These are typically targets related to OSS package and license declarations. See [rules\_license](https://github.com/bazelbuild/rules_license) for examples. |
-| `default_testonly` | Boolean; default is `False` except as noted  Sets the default [`testonly`](common-definitions#common.testonly) property for all rules in this package.  In packages under `javatests` the default value is `True`. |
+| `default_testonly` | Boolean; default is `False` except as noted  Sets the default [`testonly`](/versions/8.5.1/reference/be/common-definitions#common.testonly) property for all rules in this package.  In packages under `javatests` the default value is `True`. |
 | `features` | List strings; default is `[]`  Sets various flags that affect the semantics of this BUILD file.  This feature is mainly used by the people working on the build system to tag packages that need some kind of special handling. Do not use this unless explicitly requested by someone working on the build system. |
 
 ### Examples
@@ -66,7 +66,7 @@ visible target can only be referenced within its own package (not subpackages).
 In between these extremes, a target may allow access to its own package plus any
 of the packages described by one or more package groups. For a more detailed
 explanation of the visibility system, see the
-[visibility](common-definitions#common.visibility)
+[visibility](/versions/8.5.1/reference/be/common-definitions#common.visibility)
 attribute.
 
 A given package is considered to be in the group if it either matches the
@@ -159,7 +159,7 @@ visibility declaration can also be specified; in this case, the files will be
 visible to the targets specified. If no visibility is specified, the files
 will be visible to every package, even if a package default visibility was
 specified in the `package`
-function. The [licenses](common-definitions#common.licenses)
+function. The [licenses](/versions/8.5.1/reference/be/common-definitions#common.licenses)
 can also be specified.
 
 ### Example
@@ -262,8 +262,7 @@ There are several important limitations and caveats:
    package called "Foo.java" (which is allowed, though Bazel warns about it),
    then the consumer of the `glob()` will use the "Foo.java" rule
    (its outputs) instead of the "Foo.java" file. See
-   [GitHub
-   issue #10395](https://github.com/bazelbuild/bazel/issues/10395#issuecomment-583714657) for more details.
+   [GitHub issue #10395](https://github.com/bazelbuild/bazel/issues/10395#issuecomment-583714657) for more details.
 3. Globs may match files in subdirectories. And subdirectory names
    may be wildcarded. However...
 4. Labels are not allowed to cross the package boundary and glob does
@@ -409,7 +408,7 @@ select(
 ```
 
 `select()` is the helper function that makes a rule attribute
-[configurable](common-definitions#configurable-attributes).
+[configurable](/versions/8.5.1/reference/be/common-definitions#configurable-attributes).
 It can replace the right-hand side of
 *almost*
 any attribute assignment so its value depends on command-line Bazel flags.
diff --git a/versions/8.5.1/reference/be/general.mdx b/versions/8.5.1/reference/be/general.mdx
index 8c348f4f..38ed838b 100644
--- a/versions/8.5.1/reference/be/general.mdx
+++ b/versions/8.5.1/reference/be/general.mdx
@@ -158,9 +158,9 @@ some build targets.
   [here](/versions/8.5.1/reference/be/common-definitions#configurable-attributes) for more discussion.
 * Avoid repeating identical `config_setting` definitions in different packages.
   Instead, reference a common `config_setting` that defined in a canonical package.
-* [`values`](general#config_setting.values),
-  [`define_values`](general#config_setting.define_values), and
-  [`constraint_values`](general#config_setting.constraint_values)
+* [`values`](/versions/8.5.1/reference/be/general#config_setting.values),
+  [`define_values`](/versions/8.5.1/reference/be/general#config_setting.define_values), and
+  [`constraint_values`](/versions/8.5.1/reference/be/general#config_setting.constraint_values)
   can be used in any combination in the same `config_setting` but at least one must
   be set for any given `config_setting`.
 
@@ -169,10 +169,10 @@ some build targets.
 | Attributes | |
 | --- | --- |
 | `name` | [Name](/versions/8.5.1/concepts/labels#target-names); required  A unique name for this target. |
-| `constraint_values` | List of [labels](/versions/8.5.1/concepts/labels); [nonconfigurable](common-definitions#configurable-attributes); default is `[]` The minimum set of `constraint_values` that the target platform must specify in order to match this `config_setting`. (The execution platform is not considered here.) Any additional constraint values that the platform has are ignored. See [Configurable Build Attributes](https://bazel.build/versions/8.5.1/docs/configurable-attributes#platforms) for details. If two `config_setting`s match in the same `select` and one has all the same flags and `constraint_setting`s as the other plus additional ones, the one with more settings is chosen. This is known as "specialization". For example, a `config_setting` matching `x86` and `Linux` specializes a `config_setting` matching `x86`. If two `config_setting`s match and both have `constraint_value`s not present in the other, this is an error. |
-| `define_values` | Dictionary: String -> String; [nonconfigurable](common-definitions#configurable-attributes); default is `{}` The same as [`values`](/versions/8.5.1/reference/be/general#config_setting.values) but specifically for the `--define` flag. `--define` is special because its syntax (`--define KEY=VAL`) means `KEY=VAL` is a *value* from a Bazel flag perspective.  That means:  ```             config_setting(                 name = "a_and_b",                 values = {                     "define": "a=1",                     "define": "b=2",                 }) ```   doesn't work because the same key (`define`) appears twice in the dictionary. This attribute solves that problem:  ```             config_setting(                 name = "a_and_b",                 define_values = {                     "a": "1",                     "b": "2",                 }) ```   correctly matches `bazel build //foo --define a=1 --define b=2`. `--define` can still appear in [`values`](/versions/8.5.1/reference/be/general#config_setting.values) with normal flag syntax, and can be mixed freely with this attribute as long as dictionary keys remain distinct. |
-| `flag_values` | Dictionary: [label](/versions/8.5.1/concepts/labels) -> String; [nonconfigurable](common-definitions#configurable-attributes); default is `{}` The same as [`values`](/versions/8.5.1/reference/be/general#config_setting.values) but for [user-defined build flags](https://bazel.build/versions/8.5.1/rules/config#user-defined-build-settings). This is a distinct attribute because user-defined flags are referenced as labels while built-in flags are referenced as arbitrary strings. |
-| `values` | Dictionary: String -> String; [nonconfigurable](common-definitions#configurable-attributes); default is `{}` The set of configuration values that match this rule (expressed as build flags) This rule inherits the configuration of the configured target that references it in a `select` statement. It is considered to "match" a Bazel invocation if, for every entry in the dictionary, its configuration matches the entry's expected value. For example `values = {"compilation_mode": "opt"}` matches the invocations `bazel build --compilation_mode=opt ...` and `bazel build -c opt ...` on target-configured rules.  For convenience's sake, configuration values are specified as build flags (without the preceding `"--"`). But keep in mind that the two are not the same. This is because targets can be built in multiple configurations within the same build. For example, an exec configuration's "cpu" matches the value of `--host_cpu`, not `--cpu`. So different instances of the same `config_setting` may match the same invocation differently depending on the configuration of the rule using them.  If a flag is not explicitly set at the command line, its default value is used. If a key appears multiple times in the dictionary, only the last instance is used. If a key references a flag that can be set multiple times on the command line (e.g. `bazel build --copt=foo --copt=bar --copt=baz ...`), a match occurs if *any* of those settings match. |
+| `constraint_values` | List of [labels](/versions/8.5.1/concepts/labels); [nonconfigurable](/versions/8.5.1/reference/be/common-definitions#configurable-attributes); default is `[]` The minimum set of `constraint_values` that the target platform must specify in order to match this `config_setting`. (The execution platform is not considered here.) Any additional constraint values that the platform has are ignored. See [Configurable Build Attributes](https://bazel.build/versions/8.5.1/docs/configurable-attributes#platforms) for details. If two `config_setting`s match in the same `select` and one has all the same flags and `constraint_setting`s as the other plus additional ones, the one with more settings is chosen. This is known as "specialization". For example, a `config_setting` matching `x86` and `Linux` specializes a `config_setting` matching `x86`. If two `config_setting`s match and both have `constraint_value`s not present in the other, this is an error. |
+| `define_values` | Dictionary: String -> String; [nonconfigurable](/versions/8.5.1/reference/be/common-definitions#configurable-attributes); default is `{}` The same as [`values`](/versions/8.5.1/reference/be/general#config_setting.values) but specifically for the `--define` flag. `--define` is special because its syntax (`--define KEY=VAL`) means `KEY=VAL` is a *value* from a Bazel flag perspective.  That means:  ```             config_setting(                 name = "a_and_b",                 values = {                     "define": "a=1",                     "define": "b=2",                 }) ```   doesn't work because the same key (`define`) appears twice in the dictionary. This attribute solves that problem:  ```             config_setting(                 name = "a_and_b",                 define_values = {                     "a": "1",                     "b": "2",                 }) ```   correctly matches `bazel build //foo --define a=1 --define b=2`. `--define` can still appear in [`values`](/versions/8.5.1/reference/be/general#config_setting.values) with normal flag syntax, and can be mixed freely with this attribute as long as dictionary keys remain distinct. |
+| `flag_values` | Dictionary: [label](/versions/8.5.1/concepts/labels) -> String; [nonconfigurable](/versions/8.5.1/reference/be/common-definitions#configurable-attributes); default is `{}` The same as [`values`](/versions/8.5.1/reference/be/general#config_setting.values) but for [user-defined build flags](https://bazel.build/versions/8.5.1/rules/config#user-defined-build-settings). This is a distinct attribute because user-defined flags are referenced as labels while built-in flags are referenced as arbitrary strings. |
+| `values` | Dictionary: String -> String; [nonconfigurable](/versions/8.5.1/reference/be/common-definitions#configurable-attributes); default is `{}` The set of configuration values that match this rule (expressed as build flags) This rule inherits the configuration of the configured target that references it in a `select` statement. It is considered to "match" a Bazel invocation if, for every entry in the dictionary, its configuration matches the entry's expected value. For example `values = {"compilation_mode": "opt"}` matches the invocations `bazel build --compilation_mode=opt ...` and `bazel build -c opt ...` on target-configured rules.  For convenience's sake, configuration values are specified as build flags (without the preceding `"--"`). But keep in mind that the two are not the same. This is because targets can be built in multiple configurations within the same build. For example, an exec configuration's "cpu" matches the value of `--host_cpu`, not `--cpu`. So different instances of the same `config_setting` may match the same invocation differently depending on the configuration of the rule using them.  If a flag is not explicitly set at the command line, its default value is used. If a key appears multiple times in the dictionary, only the last instance is used. If a key references a flag that can be set multiple times on the command line (e.g. `bazel build --copt=foo --copt=bar --copt=baz ...`), a match occurs if *any* of those settings match. |
 
 ## filegroup
 
@@ -466,7 +466,7 @@ genrule(
 | --- | --- |
 | `name` | [Name](/versions/8.5.1/concepts/labels#target-names); required  A unique name for this target.  You may refer to this rule by name in the `srcs` or `deps` section of other `BUILD` rules. If the rule generates source files, you should use the `srcs` attribute. |
 | `srcs` | List of [labels](/versions/8.5.1/concepts/labels); default is `[]` A list of inputs for this rule, such as source files to process. *This attributes is not suitable to list tools executed by the `cmd`; use the [`tools`](/versions/8.5.1/reference/be/general#genrule.tools) attribute for them instead.*  The build system ensures these prerequisites are built before running the genrule command; they are built using the same configuration as the original build request. The names of the files of these prerequisites are available to the command as a space-separated list in `$(SRCS)`; alternatively the path of an individual `srcs` target `//x:y` can be obtained using `$(location //x:y)`, or using `$<` provided it's the only entry in `srcs`. |
-| `outs` | List of [filenames](/versions/8.5.1/concepts/build-ref#filename); [nonconfigurable](common-definitions#configurable-attributes); required A list of files generated by this rule. Output files must not cross package boundaries. Output filenames are interpreted as relative to the package.  If the `executable` flag is set, `outs` must contain exactly one label.  The genrule command is expected to create each output file at a predetermined location. The location is available in `cmd` using [genrule-specific "Make" variables](/versions/8.5.1/reference/be/make-variables#predefined_genrule_variables) (`$@`, `$(OUTS)`, `$(@D)` or `$(RULEDIR)`) or using [`$(location)`](/versions/8.5.1/reference/be/make-variables#predefined_label_variables) substitution. |
+| `outs` | List of [filenames](/versions/8.5.1/concepts/build-ref#filename); [nonconfigurable](/versions/8.5.1/reference/be/common-definitions#configurable-attributes); required A list of files generated by this rule. Output files must not cross package boundaries. Output filenames are interpreted as relative to the package.  If the `executable` flag is set, `outs` must contain exactly one label.  The genrule command is expected to create each output file at a predetermined location. The location is available in `cmd` using [genrule-specific "Make" variables](/versions/8.5.1/reference/be/make-variables#predefined_genrule_variables) (`$@`, `$(OUTS)`, `$(@D)` or `$(RULEDIR)`) or using [`$(location)`](/versions/8.5.1/reference/be/make-variables#predefined_label_variables) substitution. |
 | `cmd` | String; default is `""` The command to run. Subject to [`$(location)`](/versions/8.5.1/reference/be/make-variables#predefined_label_variables) and ["Make" variable](/versions/8.5.1/reference/be/make-variables) substitution.  1. First [`$(location)`](/versions/8.5.1/reference/be/make-variables#predefined_label_variables) substitution is applied, replacing all occurrences of `$(location     label)` and of `$(locations label)` (and similar    constructions using related variables `execpath`, `execpaths`,    `rootpath` and `rootpaths`). 2. Next, ["Make" variables](/versions/8.5.1/reference/be/make-variables) are expanded. Note that    predefined variables `$(JAVA)`, `$(JAVAC)` and    `$(JAVABASE)` expand under the *exec* configuration, so Java invocations    that run as part of a build step can correctly load shared libraries and other    dependencies. 3. Finally, the resulting command is executed using the Bash shell. If its exit code is    non-zero the command is considered to have failed.  This is the fallback of `cmd_bash`, `cmd_ps` and `cmd_bat`, if none of them are applicable. |
 
 If the command line length exceeds the platform limit (64K on Linux/macOS, 8K on Windows),
@@ -477,12 +477,12 @@ applies to all cmd attributes (`cmd`, `cmd_bash`, `cmd_ps`,
 | `cmd_bash` | String; default is `""` The Bash command to run. This attribute has higher priority than `cmd`. The command is expanded and runs in the exact same way as the `cmd` attribute. |
 | `cmd_bat` | String; default is `""` The Batch command to run on Windows. This attribute has higher priority than `cmd` and `cmd_bash`. The command runs in the similar way as the `cmd` attribute, with the following differences:   * This attribute only applies on Windows. * The command runs with `cmd.exe /c` with the following default arguments:   + `/S` - strip first and last quotes and execute everything else as is.   + `/E:ON` - enable extended command set.   + `/V:ON` - enable delayed variable expansion   + `/D` - ignore AutoRun registry entries. * After [$(location)](/versions/8.5.1/reference/be/make-variables#predefined_label_variables) and   ["Make" variable](/versions/8.5.1/reference/be/make-variables) substitution, the paths will be   expanded to Windows style paths (with backslash). |
 | `cmd_ps` | String; default is `""` The Powershell command to run on Windows. This attribute has higher priority than `cmd`, `cmd_bash` and `cmd_bat`. The command runs in the similar way as the `cmd` attribute, with the following differences:   * This attribute only applies on Windows. * The command runs with `powershell.exe /c`.   To make Powershell easier to use and less error-prone, we run the following commands to set up the environment before executing Powershell command in genrule.   * `Set-ExecutionPolicy -Scope CurrentUser RemoteSigned` - allow running   unsigned scripts. * `$errorActionPreference='Stop'` - In case there are multiple commands   separated by `;`, the action exits immediately if a Powershell CmdLet fails,   but this does **NOT** work for external command. * `$PSDefaultParameterValues['*:Encoding'] = 'utf8'` - change the default   encoding from utf-16 to utf-8. |
-| `executable` | Boolean; [nonconfigurable](common-definitions#configurable-attributes); default is `False` Declare output to be executable. Setting this flag to True means the output is an executable file and can be run using the `run` command. The genrule must produce exactly one output in this case. If this attribute is set, `run` will try executing the file regardless of its content.  Declaring data dependencies for the generated executable is not supported. |
+| `executable` | Boolean; [nonconfigurable](/versions/8.5.1/reference/be/common-definitions#configurable-attributes); default is `False` Declare output to be executable. Setting this flag to True means the output is an executable file and can be run using the `run` command. The genrule must produce exactly one output in this case. If this attribute is set, `run` will try executing the file regardless of its content.  Declaring data dependencies for the generated executable is not supported. |
 | `local` | Boolean; default is `False`  If set to True, this option forces this `genrule` to run using the "local" strategy, which means no remote execution, no sandboxing, no persistent workers.  This is equivalent to providing 'local' as a tag (`tags=["local"]`). |
 | `message` | String; default is `""` A progress message. A progress message that will be printed as this build step is executed. By default, the message is "Generating *output*" (or something equally bland) but you may provide a more specific one. Use this attribute instead of `echo` or other print statements in your `cmd` command, as this allows the build tool to control whether such progress messages are printed or not. |
 | `output_licenses` | Licence type; default is `["none"]` See [`common attributes`](/versions/8.5.1/reference/be/common-definitions#binary.output_licenses) |
-| `output_to_bindir` | Boolean; [nonconfigurable](common-definitions#configurable-attributes); default is `False`  If set to True, this option causes output files to be written into the `bin` directory instead of the `genfiles` directory. |
-| `toolchains` | List of [labels](/versions/8.5.1/concepts/labels); [nonconfigurable](common-definitions#configurable-attributes); default is `[]`  The set of targets whose [Make variables](/versions/8.5.1/reference/be/make-variables) this genrule is allowed to access, or the [`toolchain_type`](/versions/8.5.1/docs/toolchains) targets that this genrule will access.  Toolchains accessed via `toolchain_type` must also provide a `TemplateVariableInfo` provider, which the target can use to access toolchain details. |
+| `output_to_bindir` | Boolean; [nonconfigurable](/versions/8.5.1/reference/be/common-definitions#configurable-attributes); default is `False`  If set to True, this option causes output files to be written into the `bin` directory instead of the `genfiles` directory. |
+| `toolchains` | List of [labels](/versions/8.5.1/concepts/labels); [nonconfigurable](/versions/8.5.1/reference/be/common-definitions#configurable-attributes); default is `[]`  The set of targets whose [Make variables](/versions/8.5.1/reference/be/make-variables) this genrule is allowed to access, or the [`toolchain_type`](/versions/8.5.1/docs/toolchains) targets that this genrule will access.  Toolchains accessed via `toolchain_type` must also provide a `TemplateVariableInfo` provider, which the target can use to access toolchain details. |
 | `tools` | List of [labels](/versions/8.5.1/concepts/labels); default is `[]` A list of *tool* dependencies for this rule. See the definition of [dependencies](/versions/8.5.1/concepts/build-ref#deps) for more information.   The build system ensures these prerequisites are built before running the genrule command; they are built using the [*exec* configuration](/versions/8.5.1/contribute/guide#configurations), since these tools are executed as part of the build. The path of an individual `tools` target `//x:y` can be obtained using `$(location //x:y)`.  Any `*_binary` or tool to be executed by `cmd` must appear in this list, not in `srcs`, to ensure they are built in the correct configuration. |
 
 ## starlark\_doc\_extract
@@ -572,5 +572,5 @@ test_suite(
 | Attributes | |
 | --- | --- |
 | `name` | [Name](/versions/8.5.1/concepts/labels#target-names); required  A unique name for this target. |
-| `tags` | List of strings; [nonconfigurable](common-definitions#configurable-attributes); default is `[]` List of text tags such as "small" or "database" or "-flaky". Tags may be any valid string. Tags which begin with a "-" character are considered negative tags. The preceding "-" character is not considered part of the tag, so a suite tag of "-small" matches a test's "small" size. All other tags are considered positive tags.  Optionally, to make positive tags more explicit, tags may also begin with the "+" character, which will not be evaluated as part of the text of the tag. It merely makes the positive and negative distinction easier to read.  Only test rules that match **all** of the positive tags and **none** of the negative tags will be included in the test suite. Note that this does not mean that error checking for dependencies on tests that are filtered out is skipped; the dependencies on skipped tests still need to be legal (e.g. not blocked by visibility constraints).  The `manual` tag keyword is treated differently than the above by the "test\_suite expansion" performed by the `bazel test` command on invocations involving wildcard [target patterns](https://bazel.build/versions/8.5.1/docs/build#specifying-build-targets). There, `test_suite` targets tagged "manual" are filtered out (and thus not expanded). This behavior is consistent with how `bazel build` and `bazel test` handle wildcard target patterns in general. Note that this is explicitly different from how `bazel query 'tests(E)'` behaves, as suites are always expanded by the `tests` query function, regardless of the `manual` tag.  Note that a test's `size` is considered a tag for the purpose of filtering.  If you need a `test_suite` that contains tests with mutually exclusive tags (e.g. all small and medium tests), you'll have to create three `test_suite` rules: one for all small tests, one for all medium tests, and one that includes the previous two. |
-| `tests` | List of [labels](/versions/8.5.1/concepts/labels); [nonconfigurable](common-definitions#configurable-attributes); default is `[]` A list of test suites and test targets of any language. Any `*_test` is accepted here, independent of the language. No `*_binary` targets are accepted however, even if they happen to run a test. Filtering by the specified `tags` is only done for tests listed directly in this attribute. If this attribute contains `test_suite`s, the tests inside those will not be filtered by this `test_suite` (they are considered to be filtered already).  If the `tests` attribute is unspecified or empty, the rule will default to including all test rules in the current BUILD file that are not tagged as `manual`. These rules are still subject to `tag` filtering. |
\ No newline at end of file
+| `tags` | List of strings; [nonconfigurable](/versions/8.5.1/reference/be/common-definitions#configurable-attributes); default is `[]` List of text tags such as "small" or "database" or "-flaky". Tags may be any valid string. Tags which begin with a "-" character are considered negative tags. The preceding "-" character is not considered part of the tag, so a suite tag of "-small" matches a test's "small" size. All other tags are considered positive tags.  Optionally, to make positive tags more explicit, tags may also begin with the "+" character, which will not be evaluated as part of the text of the tag. It merely makes the positive and negative distinction easier to read.  Only test rules that match **all** of the positive tags and **none** of the negative tags will be included in the test suite. Note that this does not mean that error checking for dependencies on tests that are filtered out is skipped; the dependencies on skipped tests still need to be legal (e.g. not blocked by visibility constraints).  The `manual` tag keyword is treated differently than the above by the "test\_suite expansion" performed by the `bazel test` command on invocations involving wildcard [target patterns](https://bazel.build/versions/8.5.1/docs/build#specifying-build-targets). There, `test_suite` targets tagged "manual" are filtered out (and thus not expanded). This behavior is consistent with how `bazel build` and `bazel test` handle wildcard target patterns in general. Note that this is explicitly different from how `bazel query 'tests(E)'` behaves, as suites are always expanded by the `tests` query function, regardless of the `manual` tag.  Note that a test's `size` is considered a tag for the purpose of filtering.  If you need a `test_suite` that contains tests with mutually exclusive tags (e.g. all small and medium tests), you'll have to create three `test_suite` rules: one for all small tests, one for all medium tests, and one that includes the previous two. |
+| `tests` | List of [labels](/versions/8.5.1/concepts/labels); [nonconfigurable](/versions/8.5.1/reference/be/common-definitions#configurable-attributes); default is `[]` A list of test suites and test targets of any language. Any `*_test` is accepted here, independent of the language. No `*_binary` targets are accepted however, even if they happen to run a test. Filtering by the specified `tags` is only done for tests listed directly in this attribute. If this attribute contains `test_suite`s, the tests inside those will not be filtered by this `test_suite` (they are considered to be filtered already).  If the `tests` attribute is unspecified or empty, the rule will default to including all test rules in the current BUILD file that are not tagged as `manual`. These rules are still subject to `tag` filtering. |
\ No newline at end of file
diff --git a/versions/8.5.1/reference/be/java.mdx b/versions/8.5.1/reference/be/java.mdx
index c545b821..e15c26a2 100644
--- a/versions/8.5.1/reference/be/java.mdx
+++ b/versions/8.5.1/reference/be/java.mdx
@@ -15,7 +15,7 @@ title: 'Java Rules'
 
 ## java\_binary
 
-[View rule sourceopen\_in\_new](@rules_java//java/bazel/rules/bazel_java_binary.bzl)
+[View rule sourceopen\_in\_new](/versions/8.5.1/reference/be/@rules_java//java/bazel/rules/bazel_java_binary.bzl)
 
 ```
 java_binary(name, deps, srcs, data, resources, add_exports, add_opens, args, bootclasspath, classpath_resources, compatible_with, create_executable, deploy_env, deploy_manifest_lines, deprecation, distribs, env, exec_compatible_with, exec_properties, features, javacopts, jvm_flags, launcher, licenses, main_class, neverlink, output_licenses, plugins, resource_strip_prefix, restricted_to, runtime_deps, stamp, tags, target_compatible_with, testonly, toolchains, use_launcher, use_testrunner, visibility)
@@ -102,7 +102,7 @@ java_binary(
 | Attributes | |
 | --- | --- |
 | `name` | [Name](/versions/8.5.1/concepts/labels#target-names); required  A unique name for this target. |
-| `deps` | List of [labels](/versions/8.5.1/concepts/labels); default is `[]` The list of other libraries to be linked in to the target. See general comments about `deps` at [Typical attributes defined by most build rules](common-definitions#typical-attributes). |
+| `deps` | List of [labels](/versions/8.5.1/concepts/labels); default is `[]` The list of other libraries to be linked in to the target. See general comments about `deps` at [Typical attributes defined by most build rules](/versions/8.5.1/reference/be/common-definitions#typical-attributes). |
 | `srcs` | List of [labels](/versions/8.5.1/concepts/labels); default is `[]` The list of source files that are processed to create the target. This attribute is almost always required; see exceptions below. Source files of type `.java` are compiled. In case of generated `.java` files it is generally advisable to put the generating rule's name here instead of the name of the file itself. This not only improves readability but makes the rule more resilient to future changes: if the generating rule generates different files in the future, you only need to fix one place: the `outs` of the generating rule. You should not list the generating rule in `deps` because it is a no-op.  Source files of type `.srcjar` are unpacked and compiled. (This is useful if you need to generate a set of `.java` files with a genrule.)  Rules: if the rule (typically `genrule` or `filegroup`) generates any of the files listed above, they will be used the same way as described for source files.  This argument is almost always required, except if a [`main_class`](#java_binary.main_class) attribute specifies a class on the runtime classpath or you specify the `runtime_deps` argument. |
 | `data` | List of [labels](/versions/8.5.1/concepts/labels); default is `[]` The list of files needed by this library at runtime. See general comments about `data` at [Typical attributes defined by most build rules](/versions/8.5.1/reference/be/common-definitions#typical-attributes). |
 | `resources` | List of [labels](/versions/8.5.1/concepts/labels); default is `[]` A list of data files to include in a Java jar. Resources may be source files or generated files.  If resources are specified, they will be bundled in the jar along with the usual `.class` files produced by compilation. The location of the resources inside of the jar file is determined by the project structure. Bazel first looks for Maven's [standard directory layout](https://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html), (a "src" directory followed by a "resources" directory grandchild). If that is not found, Bazel then looks for the topmost directory named "java" or "javatests" (so, for example, if a resource is at `/x/java/y/java/z`, the path of the resource will be `y/java/z`. This heuristic cannot be overridden, however, the `resource_strip_prefix` attribute can be used to specify a specific alternative directory for resource files. |
@@ -112,9 +112,9 @@ java_binary(
 | `classpath_resources` | List of [labels](/versions/8.5.1/concepts/labels); default is `[]` *DO NOT USE THIS OPTION UNLESS THERE IS NO OTHER WAY)* A list of resources that must be located at the root of the java tree. This attribute's only purpose is to support third-party libraries that require that their resources be found on the classpath as exactly `"myconfig.xml"`. It is only allowed on binaries and not libraries, due to the danger of namespace conflicts. |
 | `create_executable` | Boolean; default is `True` Deprecated, use `java_single_jar` instead. |
 | `deploy_env` | List of [labels](/versions/8.5.1/concepts/labels); default is `[]` A list of other `java_binary` targets which represent the deployment environment for this binary. Set this attribute when building a plugin which will be loaded by another `java_binary`.  Setting this attribute excludes all dependencies from the runtime classpath (and the deploy jar) of this binary that are shared between this binary and the targets specified in `deploy_env`. |
-| `deploy_manifest_lines` | List of strings; default is `[]` A list of lines to add to the `META-INF/manifest.mf` file generated for the `*_deploy.jar` target. The contents of this attribute are *not* subject to ["Make variable"](make-variables) substitution. |
-| `javacopts` | List of strings; default is `[]` Extra compiler options for this binary. Subject to ["Make variable"](make-variables) substitution and [Bourne shell tokenization](common-definitions#sh-tokenization). These compiler options are passed to javac after the global compiler options. |
-| `jvm_flags` | List of strings; default is `[]` A list of flags to embed in the wrapper script generated for running this binary. Subject to [$(location)](/versions/8.5.1/reference/be/make-variables#location) and ["Make variable"](make-variables) substitution, and [Bourne shell tokenization](common-definitions#sh-tokenization). The wrapper script for a Java binary includes a CLASSPATH definition (to find all the dependent jars) and invokes the right Java interpreter. The command line generated by the wrapper script includes the name of the main class followed by a `"$@"` so you can pass along other arguments after the classname. However, arguments intended for parsing by the JVM must be specified *before* the classname on the command line. The contents of `jvm_flags` are added to the wrapper script before the classname is listed.  Note that this attribute has *no effect* on `*_deploy.jar` outputs. |
+| `deploy_manifest_lines` | List of strings; default is `[]` A list of lines to add to the `META-INF/manifest.mf` file generated for the `*_deploy.jar` target. The contents of this attribute are *not* subject to ["Make variable"](/versions/8.5.1/reference/be/make-variables) substitution. |
+| `javacopts` | List of strings; default is `[]` Extra compiler options for this binary. Subject to ["Make variable"](/versions/8.5.1/reference/be/make-variables) substitution and [Bourne shell tokenization](/versions/8.5.1/reference/be/common-definitions#sh-tokenization). These compiler options are passed to javac after the global compiler options. |
+| `jvm_flags` | List of strings; default is `[]` A list of flags to embed in the wrapper script generated for running this binary. Subject to [$(location)](/versions/8.5.1/reference/be/make-variables#location) and ["Make variable"](/versions/8.5.1/reference/be/make-variables) substitution, and [Bourne shell tokenization](/versions/8.5.1/reference/be/common-definitions#sh-tokenization). The wrapper script for a Java binary includes a CLASSPATH definition (to find all the dependent jars) and invokes the right Java interpreter. The command line generated by the wrapper script includes the name of the main class followed by a `"$@"` so you can pass along other arguments after the classname. However, arguments intended for parsing by the JVM must be specified *before* the classname on the command line. The contents of `jvm_flags` are added to the wrapper script before the classname is listed.  Note that this attribute has *no effect* on `*_deploy.jar` outputs. |
 | `launcher` | [Label](/versions/8.5.1/concepts/labels); default is `None` Specify a binary that will be used to run your Java program instead of the normal `bin/java` program included with the JDK. The target must be a `cc_binary`. Any `cc_binary` that implements the [Java Invocation API](http://docs.oracle.com/javase/7/docs/technotes/guides/jni/spec/invocation.html) can be specified as a value for this attribute. By default, Bazel will use the normal JDK launcher (bin/java or java.exe).  The related [`--java_launcher`](/versions/8.5.1/docs/user-manual#flag--java_launcher) Bazel flag affects only those `java_binary` and `java_test` targets that have *not* specified a `launcher` attribute.  Note that your native (C++, SWIG, JNI) dependencies will be built differently depending on whether you are using the JDK launcher or another launcher:   * If you are using the normal JDK launcher (the default), native dependencies are   built as a shared library named `{name}_nativedeps.so`, where   `{name}` is the `name` attribute of this java\_binary rule.   Unused code is *not* removed by the linker in this configuration. * If you are using any other launcher, native (C++) dependencies are statically   linked into a binary named `{name}_nativedeps`, where `{name}`   is the `name` attribute of this java\_binary rule. In this case,   the linker will remove any code it thinks is unused from the resulting binary,   which means any C++ code accessed only via JNI may not be linked in unless   that `cc_library` target specifies `alwayslink = True`.   When using any launcher other than the default JDK launcher, the format of the `*_deploy.jar` output changes. See the main [java\_binary](#java_binary) docs for details. |
 | `main_class` | String; default is `""` Name of class with `main()` method to use as entry point. If a rule uses this option, it does not need a `srcs=[...]` list. Thus, with this attribute one can make an executable from a Java library that already contains one or more `main()` methods. The value of this attribute is a class name, not a source file. The class must be available at runtime: it may be compiled by this rule (from `srcs`) or provided by direct or transitive dependencies (through `runtime_deps` or `deps`). If the class is unavailable, the binary will fail at runtime; there is no build-time check. |
 | `neverlink` | Boolean; default is `False` |
@@ -127,7 +127,7 @@ java_binary(
 
 ## java\_import
 
-[View rule sourceopen\_in\_new](@rules_java//java/bazel/rules/bazel_java_import.bzl)
+[View rule sourceopen\_in\_new](/versions/8.5.1/reference/be/@rules_java//java/bazel/rules/bazel_java_import.bzl)
 
 ```
 java_import(name, deps, data, add_exports, add_opens, compatible_with, constraints, deprecation, distribs, exec_compatible_with, exec_properties, exports, features, jars, licenses, neverlink, proguard_specs, restricted_to, runtime_deps, srcjar, tags, target_compatible_with, testonly, toolchains, visibility)
@@ -169,7 +169,7 @@ libraries for `java_library` and
 
 ## java\_library
 
-[View rule sourceopen\_in\_new](@rules_java//java/bazel/rules/bazel_java_library.bzl)
+[View rule sourceopen\_in\_new](/versions/8.5.1/reference/be/@rules_java//java/bazel/rules/bazel_java_library.bzl)
 
 ```
 java_library(name, deps, srcs, data, resources, add_exports, add_opens, bootclasspath, compatible_with, deprecation, distribs, exec_compatible_with, exec_properties, exported_plugins, exports, features, javabuilder_jvm_flags, javacopts, licenses, neverlink, plugins, proguard_specs, resource_strip_prefix, restricted_to, runtime_deps, tags, target_compatible_with, testonly, toolchains, visibility)
@@ -198,7 +198,7 @@ This rule compiles and links sources into a `.jar` file.
 | `exported_plugins` | List of [labels](/versions/8.5.1/concepts/labels); default is `[]` The list of `java_plugin`s (e.g. annotation processors) to export to libraries that directly depend on this library. The specified list of `java_plugin`s will be applied to any library which directly depends on this library, just as if that library had explicitly declared these labels in `plugins`. |
 | `exports` | List of [labels](/versions/8.5.1/concepts/labels); default is `[]` Exported libraries. Listing rules here will make them available to parent rules, as if the parents explicitly depended on these rules. This is not true for regular (non-exported) `deps`.  Summary: a rule *X* can access the code in *Y* if there exists a dependency path between them that begins with a `deps` edge followed by zero or more `exports` edges. Let's see some examples to illustrate this.  Assume *A* depends on *B* and *B* depends on *C*. In this case C is a *transitive* dependency of A, so changing C's sources and rebuilding A will correctly rebuild everything. However A will not be able to use classes in C. To allow that, either A has to declare C in its `deps`, or B can make it easier for A (and anything that may depend on A) by declaring C in its (B's) `exports` attribute.  The closure of exported libraries is available to all direct parent rules. Take a slightly different example: A depends on B, B depends on C and D, and also exports C but not D. Now A has access to C but not to D. Now, if C and D exported some libraries, C' and D' respectively, A could only access C' but not D'.  Important: an exported rule is not a regular dependency. Sticking to the previous example, if B exports C and wants to also use C, it has to also list it in its own `deps`. |
 | `javabuilder_jvm_flags` | List of strings; default is `[]` Restricted API, do not use! |
-| `javacopts` | List of strings; default is `[]` Extra compiler options for this library. Subject to ["Make variable"](make-variables) substitution and [Bourne shell tokenization](common-definitions#sh-tokenization). These compiler options are passed to javac after the global compiler options. |
+| `javacopts` | List of strings; default is `[]` Extra compiler options for this library. Subject to ["Make variable"](/versions/8.5.1/reference/be/make-variables) substitution and [Bourne shell tokenization](/versions/8.5.1/reference/be/common-definitions#sh-tokenization). These compiler options are passed to javac after the global compiler options. |
 | `neverlink` | Boolean; default is `False` Whether this library should only be used for compilation and not at runtime. Useful if the library will be provided by the runtime environment during execution. Examples of such libraries are the IDE APIs for IDE plug-ins or `tools.jar` for anything running on a standard JDK. Note that `neverlink = True` does not prevent the compiler from inlining material from this library into compilation targets that depend on it, as permitted by the Java Language Specification (e.g., `static final` constants of `String` or of primitive types). The preferred use case is therefore when the runtime library is identical to the compilation library.  If the runtime library differs from the compilation library then you must ensure that it differs only in places that the JLS forbids compilers to inline (and that must hold for all future versions of the JLS). |
 | `plugins` | List of [labels](/versions/8.5.1/concepts/labels); default is `[]` Java compiler plugins to run at compile-time. Every `java_plugin` specified in this attribute will be run whenever this rule is built. A library may also inherit plugins from dependencies that use `exported_plugins`. Resources generated by the plugin will be included in the resulting jar of this rule. |
 | `proguard_specs` | List of [labels](/versions/8.5.1/concepts/labels); default is `[]` Files to be used as Proguard specification. These will describe the set of specifications to be used by Proguard. If specified, they will be added to any `android_binary` target depending on this library. The files included here must only have idempotent rules, namely -dontnote, -dontwarn, assumenosideeffects, and rules that start with -keep. Other options can only appear in `android_binary`'s proguard\_specs, to ensure non-tautological merges. |
@@ -207,7 +207,7 @@ This rule compiles and links sources into a `.jar` file.
 
 ## java\_test
 
-[View rule sourceopen\_in\_new](@rules_java//java/bazel/rules/bazel_java_test.bzl)
+[View rule sourceopen\_in\_new](/versions/8.5.1/reference/be/@rules_java//java/bazel/rules/bazel_java_test.bzl)
 
 ```
 java_test(name, deps, srcs, data, resources, add_exports, add_opens, args, bootclasspath, classpath_resources, compatible_with, create_executable, deploy_manifest_lines, deprecation, distribs, env, env_inherit, exec_compatible_with, exec_properties, features, flaky, javacopts, jvm_flags, launcher, licenses, local, main_class, neverlink, plugins, resource_strip_prefix, restricted_to, runtime_deps, shard_count, size, stamp, tags, target_compatible_with, test_class, testonly, timeout, toolchains, use_launcher, use_testrunner, visibility)
@@ -225,8 +225,7 @@ test code. The test runner's main method is invoked instead of the main class be
   [java\_binary](#java_binary) for more details.
 
 See the section on `java_binary()` arguments. This rule also
-supports all [attributes common
-to all test rules (\*\_test)](https://bazel.build/versions/8.5.1/reference/be/common-definitions#common-attributes-tests).
+supports all [attributes common to all test rules (\*\_test)](https://bazel.build/versions/8.5.1/reference/be/common-definitions#common-attributes-tests).
 
 #### Examples
 
@@ -255,7 +254,7 @@ java_test(
 | Attributes | |
 | --- | --- |
 | `name` | [Name](/versions/8.5.1/concepts/labels#target-names); required  A unique name for this target. |
-| `deps` | List of [labels](/versions/8.5.1/concepts/labels); default is `[]` The list of other libraries to be linked in to the target. See general comments about `deps` at [Typical attributes defined by most build rules](common-definitions#typical-attributes). |
+| `deps` | List of [labels](/versions/8.5.1/concepts/labels); default is `[]` The list of other libraries to be linked in to the target. See general comments about `deps` at [Typical attributes defined by most build rules](/versions/8.5.1/reference/be/common-definitions#typical-attributes). |
 | `srcs` | List of [labels](/versions/8.5.1/concepts/labels); default is `[]` The list of source files that are processed to create the target. This attribute is almost always required; see exceptions below. Source files of type `.java` are compiled. In case of generated `.java` files it is generally advisable to put the generating rule's name here instead of the name of the file itself. This not only improves readability but makes the rule more resilient to future changes: if the generating rule generates different files in the future, you only need to fix one place: the `outs` of the generating rule. You should not list the generating rule in `deps` because it is a no-op.  Source files of type `.srcjar` are unpacked and compiled. (This is useful if you need to generate a set of `.java` files with a genrule.)  Rules: if the rule (typically `genrule` or `filegroup`) generates any of the files listed above, they will be used the same way as described for source files.  This argument is almost always required, except if a [`main_class`](#java_binary.main_class) attribute specifies a class on the runtime classpath or you specify the `runtime_deps` argument. |
 | `data` | List of [labels](/versions/8.5.1/concepts/labels); default is `[]` The list of files needed by this library at runtime. See general comments about `data` at [Typical attributes defined by most build rules](/versions/8.5.1/reference/be/common-definitions#typical-attributes). |
 | `resources` | List of [labels](/versions/8.5.1/concepts/labels); default is `[]` A list of data files to include in a Java jar. Resources may be source files or generated files.  If resources are specified, they will be bundled in the jar along with the usual `.class` files produced by compilation. The location of the resources inside of the jar file is determined by the project structure. Bazel first looks for Maven's [standard directory layout](https://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html), (a "src" directory followed by a "resources" directory grandchild). If that is not found, Bazel then looks for the topmost directory named "java" or "javatests" (so, for example, if a resource is at `/x/java/y/java/z`, the path of the resource will be `y/java/z`. This heuristic cannot be overridden, however, the `resource_strip_prefix` attribute can be used to specify a specific alternative directory for resource files. |
@@ -264,9 +263,9 @@ java_test(
 | `bootclasspath` | [Label](/versions/8.5.1/concepts/labels); default is `None` Restricted API, do not use! |
 | `classpath_resources` | List of [labels](/versions/8.5.1/concepts/labels); default is `[]` *DO NOT USE THIS OPTION UNLESS THERE IS NO OTHER WAY)* A list of resources that must be located at the root of the java tree. This attribute's only purpose is to support third-party libraries that require that their resources be found on the classpath as exactly `"myconfig.xml"`. It is only allowed on binaries and not libraries, due to the danger of namespace conflicts. |
 | `create_executable` | Boolean; default is `True` Deprecated, use `java_single_jar` instead. |
-| `deploy_manifest_lines` | List of strings; default is `[]` A list of lines to add to the `META-INF/manifest.mf` file generated for the `*_deploy.jar` target. The contents of this attribute are *not* subject to ["Make variable"](make-variables) substitution. |
-| `javacopts` | List of strings; default is `[]` Extra compiler options for this binary. Subject to ["Make variable"](make-variables) substitution and [Bourne shell tokenization](common-definitions#sh-tokenization). These compiler options are passed to javac after the global compiler options. |
-| `jvm_flags` | List of strings; default is `[]` A list of flags to embed in the wrapper script generated for running this binary. Subject to [$(location)](/versions/8.5.1/reference/be/make-variables#location) and ["Make variable"](make-variables) substitution, and [Bourne shell tokenization](common-definitions#sh-tokenization). The wrapper script for a Java binary includes a CLASSPATH definition (to find all the dependent jars) and invokes the right Java interpreter. The command line generated by the wrapper script includes the name of the main class followed by a `"$@"` so you can pass along other arguments after the classname. However, arguments intended for parsing by the JVM must be specified *before* the classname on the command line. The contents of `jvm_flags` are added to the wrapper script before the classname is listed.  Note that this attribute has *no effect* on `*_deploy.jar` outputs. |
+| `deploy_manifest_lines` | List of strings; default is `[]` A list of lines to add to the `META-INF/manifest.mf` file generated for the `*_deploy.jar` target. The contents of this attribute are *not* subject to ["Make variable"](/versions/8.5.1/reference/be/make-variables) substitution. |
+| `javacopts` | List of strings; default is `[]` Extra compiler options for this binary. Subject to ["Make variable"](/versions/8.5.1/reference/be/make-variables) substitution and [Bourne shell tokenization](/versions/8.5.1/reference/be/common-definitions#sh-tokenization). These compiler options are passed to javac after the global compiler options. |
+| `jvm_flags` | List of strings; default is `[]` A list of flags to embed in the wrapper script generated for running this binary. Subject to [$(location)](/versions/8.5.1/reference/be/make-variables#location) and ["Make variable"](/versions/8.5.1/reference/be/make-variables) substitution, and [Bourne shell tokenization](/versions/8.5.1/reference/be/common-definitions#sh-tokenization). The wrapper script for a Java binary includes a CLASSPATH definition (to find all the dependent jars) and invokes the right Java interpreter. The command line generated by the wrapper script includes the name of the main class followed by a `"$@"` so you can pass along other arguments after the classname. However, arguments intended for parsing by the JVM must be specified *before* the classname on the command line. The contents of `jvm_flags` are added to the wrapper script before the classname is listed.  Note that this attribute has *no effect* on `*_deploy.jar` outputs. |
 | `launcher` | [Label](/versions/8.5.1/concepts/labels); default is `None` Specify a binary that will be used to run your Java program instead of the normal `bin/java` program included with the JDK. The target must be a `cc_binary`. Any `cc_binary` that implements the [Java Invocation API](http://docs.oracle.com/javase/7/docs/technotes/guides/jni/spec/invocation.html) can be specified as a value for this attribute. By default, Bazel will use the normal JDK launcher (bin/java or java.exe).  The related [`--java_launcher`](/versions/8.5.1/docs/user-manual#flag--java_launcher) Bazel flag affects only those `java_binary` and `java_test` targets that have *not* specified a `launcher` attribute.  Note that your native (C++, SWIG, JNI) dependencies will be built differently depending on whether you are using the JDK launcher or another launcher:   * If you are using the normal JDK launcher (the default), native dependencies are   built as a shared library named `{name}_nativedeps.so`, where   `{name}` is the `name` attribute of this java\_binary rule.   Unused code is *not* removed by the linker in this configuration. * If you are using any other launcher, native (C++) dependencies are statically   linked into a binary named `{name}_nativedeps`, where `{name}`   is the `name` attribute of this java\_binary rule. In this case,   the linker will remove any code it thinks is unused from the resulting binary,   which means any C++ code accessed only via JNI may not be linked in unless   that `cc_library` target specifies `alwayslink = True`.   When using any launcher other than the default JDK launcher, the format of the `*_deploy.jar` output changes. See the main [java\_binary](#java_binary) docs for details. |
 | `main_class` | String; default is `""` Name of class with `main()` method to use as entry point. If a rule uses this option, it does not need a `srcs=[...]` list. Thus, with this attribute one can make an executable from a Java library that already contains one or more `main()` methods. The value of this attribute is a class name, not a source file. The class must be available at runtime: it may be compiled by this rule (from `srcs`) or provided by direct or transitive dependencies (through `runtime_deps` or `deps`). If the class is unavailable, the binary will fail at runtime; there is no build-time check. |
 | `neverlink` | Boolean; default is `False` |
@@ -280,7 +279,7 @@ java_test(
 
 ## java\_package\_configuration
 
-[View rule sourceopen\_in\_new](@rules_java//java/common/rules/java_package_configuration.bzl)
+[View rule sourceopen\_in\_new](/versions/8.5.1/reference/be/@rules_java//java/common/rules/java_package_configuration.bzl)
 
 ```
 java_package_configuration(name, data, compatible_with, deprecation, distribs, exec_compatible_with, exec_properties, features, javacopts, output_licenses, packages, restricted_to, system, tags, target_compatible_with, testonly, toolchains, visibility)
@@ -328,7 +327,7 @@ java_toolchain(
 
 ## java\_plugin
 
-[View rule sourceopen\_in\_new](@rules_java//java/bazel/rules/bazel_java_plugin.bzl)
+[View rule sourceopen\_in\_new](/versions/8.5.1/reference/be/@rules_java//java/bazel/rules/bazel_java_plugin.bzl)
 
 ```
 java_plugin(name, deps, srcs, data, resources, add_exports, add_opens, bootclasspath, compatible_with, deprecation, distribs, exec_compatible_with, exec_properties, features, generates_api, javabuilder_jvm_flags, javacopts, licenses, neverlink, output_licenses, plugins, processor_class, proguard_specs, resource_strip_prefix, restricted_to, tags, target_compatible_with, testonly, toolchains, visibility)
@@ -364,7 +363,7 @@ except for the addition of the `processor_class` and
 | `bootclasspath` | [Label](/versions/8.5.1/concepts/labels); default is `None` Restricted API, do not use! |
 | `generates_api` | Boolean; default is `False` This attribute marks annotation processors that generate API code. If a rule uses an API-generating annotation processor, other rules depending on it can refer to the generated code only if their compilation actions are scheduled after the generating rule. This attribute instructs Bazel to introduce scheduling constraints when --java\_header\_compilation is enabled. *WARNING: This attribute affects build performance, use it only if necessary.* |
 | `javabuilder_jvm_flags` | List of strings; default is `[]` Restricted API, do not use! |
-| `javacopts` | List of strings; default is `[]` Extra compiler options for this library. Subject to ["Make variable"](make-variables) substitution and [Bourne shell tokenization](common-definitions#sh-tokenization). These compiler options are passed to javac after the global compiler options. |
+| `javacopts` | List of strings; default is `[]` Extra compiler options for this library. Subject to ["Make variable"](/versions/8.5.1/reference/be/make-variables) substitution and [Bourne shell tokenization](/versions/8.5.1/reference/be/common-definitions#sh-tokenization). These compiler options are passed to javac after the global compiler options. |
 | `neverlink` | Boolean; default is `False` Whether this library should only be used for compilation and not at runtime. Useful if the library will be provided by the runtime environment during execution. Examples of such libraries are the IDE APIs for IDE plug-ins or `tools.jar` for anything running on a standard JDK. Note that `neverlink = True` does not prevent the compiler from inlining material from this library into compilation targets that depend on it, as permitted by the Java Language Specification (e.g., `static final` constants of `String` or of primitive types). The preferred use case is therefore when the runtime library is identical to the compilation library.  If the runtime library differs from the compilation library then you must ensure that it differs only in places that the JLS forbids compilers to inline (and that must hold for all future versions of the JLS). |
 | `output_licenses` | List of strings; default is `[]` |
 | `plugins` | List of [labels](/versions/8.5.1/concepts/labels); default is `[]` Java compiler plugins to run at compile-time. Every `java_plugin` specified in this attribute will be run whenever this rule is built. A library may also inherit plugins from dependencies that use `exported_plugins`. Resources generated by the plugin will be included in the resulting jar of this rule. |
@@ -374,7 +373,7 @@ except for the addition of the `processor_class` and
 
 ## java\_runtime
 
-[View rule sourceopen\_in\_new](@rules_java//java/common/rules/java_runtime.bzl)
+[View rule sourceopen\_in\_new](/versions/8.5.1/reference/be/@rules_java//java/common/rules/java_runtime.bzl)
 
 ```
 java_runtime(name, srcs, compatible_with, default_cds, deprecation, distribs, exec_compatible_with, exec_properties, features, hermetic_srcs, hermetic_static_libs, java, java_home, lib_ct_sym, lib_modules, output_licenses, restricted_to, tags, target_compatible_with, testonly, toolchains, version, visibility)
@@ -410,7 +409,7 @@ java_runtime(
 
 ## java\_toolchain
 
-[View rule sourceopen\_in\_new](@rules_java//java/common/rules/java_toolchain.bzl)
+[View rule sourceopen\_in\_new](/versions/8.5.1/reference/be/@rules_java//java/common/rules/java_toolchain.bzl)
 
 ```
 java_toolchain(name, android_lint_data, android_lint_jvm_opts, android_lint_opts, android_lint_package_configuration, android_lint_runner, bootclasspath, compatible_javacopts, compatible_with, deprecation, deps_checker, distribs, exec_compatible_with, exec_properties, features, forcibly_disable_header_compilation, genclass, header_compiler, header_compiler_builtin_processors, header_compiler_direct, ijar, jacocorunner, java_runtime, javabuilder, javabuilder_data, javabuilder_jvm_opts, javac_supports_multiplex_workers, javac_supports_worker_cancellation, javac_supports_worker_multiplex_sandboxing, javac_supports_workers, javacopts, jspecify_implicit_deps, jspecify_javacopts, jspecify_packages, jspecify_processor, jspecify_processor_class, jspecify_stubs, jvm_opts, licenses, misc, oneversion, oneversion_allowlist, oneversion_allowlist_for_tests, oneversion_whitelist, package_configuration, proguard_allowlister, reduced_classpath_incompatible_processors, restricted_to, singlejar, source_version, tags, target_compatible_with, target_version, testonly, timezone_data, toolchains, tools, turbine_data, turbine_jvm_opts, visibility, xlint)
diff --git a/versions/8.5.1/reference/be/make-variables.mdx b/versions/8.5.1/reference/be/make-variables.mdx
index a5ae6aba..10a055e6 100644
--- a/versions/8.5.1/reference/be/make-variables.mdx
+++ b/versions/8.5.1/reference/be/make-variables.mdx
@@ -19,8 +19,7 @@ targets, and *custom* variables, which are defined in dependency targets
 and only available to targets that depend on them.
 
 The reason for the term "Make" is historical: the syntax and semantics of
-these variables were originally intended to match [GNU
-Make](https://www.gnu.org/software/make/manual/html_node/Using-Variables.html).
+these variables were originally intended to match [GNU Make](https://www.gnu.org/software/make/manual/html_node/Using-Variables.html).
 
 ## Use
 
@@ -64,8 +63,7 @@ and look at the top output lines with capital letters.
 **Toolchain option variables**
 
 * `COMPILATION_MODE`:
-  `fastbuild`, `dbg`, or `opt`. ([more
-  details](https://bazel.build/versions/8.5.1/docs/user-manual#flag--compilation_mode))
+  `fastbuild`, `dbg`, or `opt`. ([more details](https://bazel.build/versions/8.5.1/docs/user-manual#flag--compilation_mode))
 
 **Path variables**
 
@@ -304,7 +302,7 @@ rare cases. If you are tempted to use them, please [contact the Bazel devs](http
 
 Rule and [toolchain](/versions/8.5.1/docs/toolchains) writers can define
 completely custom variables by returning a
-[TemplateVariableInfo](/versions/8.5.1/rules/lib/TemplateVariableInfo)
+[TemplateVariableInfo](/versions/8.5.1/rules/lib/providers/TemplateVariableInfo)
 provider. Any rules depending on these through the
 `toolchains` attribute can then read their values:
 
diff --git a/versions/8.5.1/reference/be/overview.mdx b/versions/8.5.1/reference/be/overview.mdx
index 3666977d..b30284b1 100644
--- a/versions/8.5.1/reference/be/overview.mdx
+++ b/versions/8.5.1/reference/be/overview.mdx
@@ -37,18 +37,18 @@ For non-native Starlark rules that ship separately from Bazel, see the list of
 
 | Language | Binary rules | Library rules | Test rules | Other rules |
 | --- | --- | --- | --- | --- |
-| C / C++ | [cc\_binary](c-cpp#cc_binary) | [cc\_import](c-cpp#cc_import)   [cc\_library](c-cpp#cc_library)   [cc\_shared\_library](c-cpp#cc_shared_library)   [cc\_static\_library](c-cpp#cc_static_library) | [cc\_test](c-cpp#cc_test) | [cc\_toolchain](c-cpp#cc_toolchain)   [cc\_toolchain\_suite](c-cpp#cc_toolchain_suite)   [fdo\_prefetch\_hints](c-cpp#fdo_prefetch_hints)   [fdo\_profile](c-cpp#fdo_profile)   [memprof\_profile](c-cpp#memprof_profile)   [propeller\_optimize](c-cpp#propeller_optimize) |
-| Java | [java\_binary](java#java_binary) | [java\_import](java#java_import)   [java\_library](java#java_library) | [java\_test](java#java_test) | [java\_package\_configuration](java#java_package_configuration)   [java\_plugin](java#java_plugin)   [java\_runtime](java#java_runtime)   [java\_toolchain](java#java_toolchain) |
-| Objective-C |  | [objc\_import](objective-c#objc_import)   [objc\_library](objective-c#objc_library) |  |  |
-| Protocol Buffer |  | [cc\_proto\_library](protocol-buffer#cc_proto_library)   [java\_lite\_proto\_library](protocol-buffer#java_lite_proto_library)   [java\_proto\_library](protocol-buffer#java_proto_library)   [proto\_library](protocol-buffer#proto_library)   [py\_proto\_library](protocol-buffer#py_proto_library) |  | [proto\_lang\_toolchain](protocol-buffer#proto_lang_toolchain)   [proto\_toolchain](protocol-buffer#proto_toolchain) |
-| Python | [py\_binary](python#py_binary) | [py\_library](python#py_library) | [py\_test](python#py_test) | [py\_runtime](python#py_runtime) |
-| Shell | [sh\_binary](shell#sh_binary) | [sh\_library](shell#sh_library) | [sh\_test](shell#sh_test) |  |
+| C / C++ | [cc\_binary](/versions/8.5.1/reference/be/c-cpp#cc_binary) | [cc\_import](/versions/8.5.1/reference/be/c-cpp#cc_import)   [cc\_library](/versions/8.5.1/reference/be/c-cpp#cc_library)   [cc\_shared\_library](/versions/8.5.1/reference/be/c-cpp#cc_shared_library)   [cc\_static\_library](/versions/8.5.1/reference/be/c-cpp#cc_static_library) | [cc\_test](/versions/8.5.1/reference/be/c-cpp#cc_test) | [cc\_toolchain](/versions/8.5.1/reference/be/c-cpp#cc_toolchain)   [cc\_toolchain\_suite](/versions/8.5.1/reference/be/c-cpp#cc_toolchain_suite)   [fdo\_prefetch\_hints](/versions/8.5.1/reference/be/c-cpp#fdo_prefetch_hints)   [fdo\_profile](/versions/8.5.1/reference/be/c-cpp#fdo_profile)   [memprof\_profile](/versions/8.5.1/reference/be/c-cpp#memprof_profile)   [propeller\_optimize](/versions/8.5.1/reference/be/c-cpp#propeller_optimize) |
+| Java | [java\_binary](/versions/8.5.1/reference/be/java#java_binary) | [java\_import](/versions/8.5.1/reference/be/java#java_import)   [java\_library](/versions/8.5.1/reference/be/java#java_library) | [java\_test](/versions/8.5.1/reference/be/java#java_test) | [java\_package\_configuration](/versions/8.5.1/reference/be/java#java_package_configuration)   [java\_plugin](/versions/8.5.1/reference/be/java#java_plugin)   [java\_runtime](/versions/8.5.1/reference/be/java#java_runtime)   [java\_toolchain](/versions/8.5.1/reference/be/java#java_toolchain) |
+| Objective-C |  | [objc\_import](/versions/8.5.1/reference/be/objective-c#objc_import)   [objc\_library](/versions/8.5.1/reference/be/objective-c#objc_library) |  |  |
+| Protocol Buffer |  | [cc\_proto\_library](/versions/8.5.1/reference/be/protocol-buffer#cc_proto_library)   [java\_lite\_proto\_library](/versions/8.5.1/reference/be/protocol-buffer#java_lite_proto_library)   [java\_proto\_library](/versions/8.5.1/reference/be/protocol-buffer#java_proto_library)   [proto\_library](/versions/8.5.1/reference/be/protocol-buffer#proto_library)   [py\_proto\_library](/versions/8.5.1/reference/be/protocol-buffer#py_proto_library) |  | [proto\_lang\_toolchain](/versions/8.5.1/reference/be/protocol-buffer#proto_lang_toolchain)   [proto\_toolchain](/versions/8.5.1/reference/be/protocol-buffer#proto_toolchain) |
+| Python | [py\_binary](/versions/8.5.1/reference/be/python#py_binary) | [py\_library](/versions/8.5.1/reference/be/python#py_library) | [py\_test](/versions/8.5.1/reference/be/python#py_test) | [py\_runtime](/versions/8.5.1/reference/be/python#py_runtime) |
+| Shell | [sh\_binary](/versions/8.5.1/reference/be/shell#sh_binary) | [sh\_library](/versions/8.5.1/reference/be/shell#sh_library) | [sh\_test](/versions/8.5.1/reference/be/shell#sh_test) |  |
 
 ### Language-agnostic native rules
 
 | Family | Rules |
 | --- | --- |
-| Extra Actions | * [action\_listener](extra-actions#action_listener)* [extra\_action](extra-actions#extra_action) |
-| General | * [alias](general#alias)* [config\_setting](general#config_setting)* [filegroup](general#filegroup)* [genquery](general#genquery)* [genrule](general#genrule)* [starlark\_doc\_extract](general#starlark_doc_extract)* [test\_suite](general#test_suite) |
-| Platforms and Toolchains | * [constraint\_setting](platforms-and-toolchains#constraint_setting)* [constraint\_value](platforms-and-toolchains#constraint_value)* [platform](platforms-and-toolchains#platform)* [toolchain](platforms-and-toolchains#toolchain)* [toolchain\_type](platforms-and-toolchains#toolchain_type) |
-| Workspace | * [bind](workspace#bind)* [local\_repository](workspace#local_repository)* [new\_local\_repository](workspace#new_local_repository) |
\ No newline at end of file
+| Extra Actions | * [action\_listener](/versions/8.5.1/reference/be/extra-actions#action_listener)* [extra\_action](/versions/8.5.1/reference/be/extra-actions#extra_action) |
+| General | * [alias](/versions/8.5.1/reference/be/general#alias)* [config\_setting](/versions/8.5.1/reference/be/general#config_setting)* [filegroup](/versions/8.5.1/reference/be/general#filegroup)* [genquery](/versions/8.5.1/reference/be/general#genquery)* [genrule](/versions/8.5.1/reference/be/general#genrule)* [starlark\_doc\_extract](/versions/8.5.1/reference/be/general#starlark_doc_extract)* [test\_suite](/versions/8.5.1/reference/be/general#test_suite) |
+| Platforms and Toolchains | * [constraint\_setting](/versions/8.5.1/reference/be/platforms-and-toolchains#constraint_setting)* [constraint\_value](/versions/8.5.1/reference/be/platforms-and-toolchains#constraint_value)* [platform](/versions/8.5.1/reference/be/platforms-and-toolchains#platform)* [toolchain](/versions/8.5.1/reference/be/platforms-and-toolchains#toolchain)* [toolchain\_type](/versions/8.5.1/reference/be/platforms-and-toolchains#toolchain_type) |
+| Workspace | * [bind](/versions/8.5.1/reference/be/workspace#bind)* [local\_repository](/versions/8.5.1/reference/be/workspace#local_repository)* [new\_local\_repository](/versions/8.5.1/reference/be/workspace#new_local_repository) |
\ No newline at end of file
diff --git a/versions/8.5.1/reference/be/platforms-and-toolchains.mdx b/versions/8.5.1/reference/be/platforms-and-toolchains.mdx
index fecb8bd7..b647487a 100644
--- a/versions/8.5.1/reference/be/platforms-and-toolchains.mdx
+++ b/versions/8.5.1/reference/be/platforms-and-toolchains.mdx
@@ -39,7 +39,7 @@ define a platform targeting an obscure cpu architecture.
 | Attributes | |
 | --- | --- |
 | `name` | [Name](/versions/8.5.1/concepts/labels#target-names); required  A unique name for this target. |
-| `default_constraint_value` | [Name](/versions/8.5.1/concepts/labels#target-names); [nonconfigurable](common-definitions#configurable-attributes); default is `None` The label of the default value for this setting, to be used if no value is given. If this attribute is present, the `constraint_value` it points to must be defined in the same package as this `constraint_setting`. If a constraint setting has a default value, then whenever a platform does not include any constraint value for that setting, it is the same as if the platform had specified the default value. Otherwise, if there is no default value, the constraint setting is considered to be unspecified by that platform. In that case, the platform would not match against any constraint list (such as for a `config_setting`) that requires a particular value for that setting. |
+| `default_constraint_value` | [Name](/versions/8.5.1/concepts/labels#target-names); [nonconfigurable](/versions/8.5.1/reference/be/common-definitions#configurable-attributes); default is `None` The label of the default value for this setting, to be used if no value is given. If this attribute is present, the `constraint_value` it points to must be defined in the same package as this `constraint_setting`. If a constraint setting has a default value, then whenever a platform does not include any constraint value for that setting, it is the same as if the platform had specified the default value. Otherwise, if there is no default value, the constraint setting is considered to be unspecified by that platform. In that case, the platform would not match against any constraint list (such as for a `config_setting`) that requires a particular value for that setting. |
 
 ## constraint\_value
 
@@ -73,7 +73,7 @@ Platforms can then declare that they have the `mips` architecture as an alternat
 | Attributes | |
 | --- | --- |
 | `name` | [Name](/versions/8.5.1/concepts/labels#target-names); required  A unique name for this target. |
-| `constraint_setting` | [Label](/versions/8.5.1/concepts/labels); [nonconfigurable](common-definitions#configurable-attributes); required The `constraint_setting` for which this `constraint_value` is a possible choice. |
+| `constraint_setting` | [Label](/versions/8.5.1/concepts/labels); [nonconfigurable](/versions/8.5.1/reference/be/common-definitions#configurable-attributes); required The `constraint_setting` for which this `constraint_value` is a possible choice. |
 
 ## platform
 
@@ -278,12 +278,12 @@ In this example, the child platforms have the following properties:
 | Attributes | |
 | --- | --- |
 | `name` | [Name](/versions/8.5.1/concepts/labels#target-names); required  A unique name for this target. |
-| `constraint_values` | List of [labels](/versions/8.5.1/concepts/labels); [nonconfigurable](common-definitions#configurable-attributes); default is `[]` The combination of constraint choices that this platform comprises. In order for a platform to apply to a given environment, the environment must have at least the values in this list. Each `constraint_value` in this list must be for a different `constraint_setting`. For example, you cannot define a platform that requires the cpu architecture to be both `@platforms//cpu:x86_64` and `@platforms//cpu:arm`. |
-| `exec_properties` | Dictionary: String -> String; [nonconfigurable](common-definitions#configurable-attributes); default is {} A map of strings that affect the way actions are executed remotely. Bazel makes no attempt to interpret this, it is treated as opaque data that's forwarded via the Platform field of the [remote execution protocol](https://github.com/bazelbuild/remote-apis). This includes any data from the parent platform's `exec_properties` attributes. If the child and parent platform define the same keys, the child's values are kept. Any keys associated with a value that is an empty string are removed from the dictionary. This attribute is a full replacement for the deprecated `remote_execution_properties`. |
-| `flags` | List of strings; [nonconfigurable](common-definitions#configurable-attributes); default is `[]` A list of flags that will be enabled when this platform is used as the target platform in a configuration. Only flags that can be set in transitions are allowed to be used. |
-| `missing_toolchain_error` | String; [nonconfigurable](common-definitions#configurable-attributes); default is `"For more information on platforms or toolchains see https://bazel.build/concepts/platforms-intro."` A custom error message that is displayed when a mandatory toolchain requirement cannot be satisfied for this target platform. Intended to point to relevant documentation users can read to understand why their toolchains are misconfigured. Not inherited from parent platforms. |
-| `parents` | List of [labels](/versions/8.5.1/concepts/labels); [nonconfigurable](common-definitions#configurable-attributes); default is `[]` The label of a `platform` target that this platform should inherit from. Although the attribute takes a list, there should be no more than one platform present. Any constraint\_settings not set directly on this platform will be found in the parent platform. See the section on [Platform Inheritance](#platform_inheritance) for details. |
-| `remote_execution_properties` | String; [nonconfigurable](common-definitions#configurable-attributes); default is `""` DEPRECATED. Please use exec\_properties attribute instead. A string used to configure a remote execution platform. Actual builds make no attempt to interpret this, it is treated as opaque data that can be used by a specific SpawnRunner. This can include data from the parent platform's "remote\_execution\_properties" attribute, by using the macro "\{PARENT\_REMOTE\_EXECUTION\_PROPERTIES\}". See the section on [Platform Inheritance](#platform_inheritance) for details. |
+| `constraint_values` | List of [labels](/versions/8.5.1/concepts/labels); [nonconfigurable](/versions/8.5.1/reference/be/common-definitions#configurable-attributes); default is `[]` The combination of constraint choices that this platform comprises. In order for a platform to apply to a given environment, the environment must have at least the values in this list. Each `constraint_value` in this list must be for a different `constraint_setting`. For example, you cannot define a platform that requires the cpu architecture to be both `@platforms//cpu:x86_64` and `@platforms//cpu:arm`. |
+| `exec_properties` | Dictionary: String -> String; [nonconfigurable](/versions/8.5.1/reference/be/common-definitions#configurable-attributes); default is {} A map of strings that affect the way actions are executed remotely. Bazel makes no attempt to interpret this, it is treated as opaque data that's forwarded via the Platform field of the [remote execution protocol](https://github.com/bazelbuild/remote-apis). This includes any data from the parent platform's `exec_properties` attributes. If the child and parent platform define the same keys, the child's values are kept. Any keys associated with a value that is an empty string are removed from the dictionary. This attribute is a full replacement for the deprecated `remote_execution_properties`. |
+| `flags` | List of strings; [nonconfigurable](/versions/8.5.1/reference/be/common-definitions#configurable-attributes); default is `[]` A list of flags that will be enabled when this platform is used as the target platform in a configuration. Only flags that can be set in transitions are allowed to be used. |
+| `missing_toolchain_error` | String; [nonconfigurable](/versions/8.5.1/reference/be/common-definitions#configurable-attributes); default is `"For more information on platforms or toolchains see https://bazel.build/concepts/platforms-intro."` A custom error message that is displayed when a mandatory toolchain requirement cannot be satisfied for this target platform. Intended to point to relevant documentation users can read to understand why their toolchains are misconfigured. Not inherited from parent platforms. |
+| `parents` | List of [labels](/versions/8.5.1/concepts/labels); [nonconfigurable](/versions/8.5.1/reference/be/common-definitions#configurable-attributes); default is `[]` The label of a `platform` target that this platform should inherit from. Although the attribute takes a list, there should be no more than one platform present. Any constraint\_settings not set directly on this platform will be found in the parent platform. See the section on [Platform Inheritance](#platform_inheritance) for details. |
+| `remote_execution_properties` | String; [nonconfigurable](/versions/8.5.1/reference/be/common-definitions#configurable-attributes); default is `""` DEPRECATED. Please use exec\_properties attribute instead. A string used to configure a remote execution platform. Actual builds make no attempt to interpret this, it is treated as opaque data that can be used by a specific SpawnRunner. This can include data from the parent platform's "remote\_execution\_properties" attribute, by using the macro "\{PARENT\_REMOTE\_EXECUTION\_PROPERTIES\}". See the section on [Platform Inheritance](#platform_inheritance) for details. |
 | `required_settings` | List of [labels](/versions/8.5.1/concepts/labels); default is `[]` A list of `config_setting`s that must be satisfied by the target configuration in order for this platform to be used as an execution platform during toolchain resolution. Required settings are not inherited from parent platforms. |
 
 ## toolchain
@@ -304,12 +304,12 @@ details.
 | Attributes | |
 | --- | --- |
 | `name` | [Name](/versions/8.5.1/concepts/labels#target-names); required  A unique name for this target. |
-| `exec_compatible_with` | List of [labels](/versions/8.5.1/concepts/labels); [nonconfigurable](common-definitions#configurable-attributes); default is `[]` A list of `constraint_value`s that must be satisfied by an execution platform in order for this toolchain to be selected for a target building on that platform. |
-| `target_compatible_with` | List of [labels](/versions/8.5.1/concepts/labels); [nonconfigurable](common-definitions#configurable-attributes); default is `[]` A list of `constraint_value`s that must be satisfied by the target platform in order for this toolchain to be selected for a target building for that platform. |
+| `exec_compatible_with` | List of [labels](/versions/8.5.1/concepts/labels); [nonconfigurable](/versions/8.5.1/reference/be/common-definitions#configurable-attributes); default is `[]` A list of `constraint_value`s that must be satisfied by an execution platform in order for this toolchain to be selected for a target building on that platform. |
+| `target_compatible_with` | List of [labels](/versions/8.5.1/concepts/labels); [nonconfigurable](/versions/8.5.1/reference/be/common-definitions#configurable-attributes); default is `[]` A list of `constraint_value`s that must be satisfied by the target platform in order for this toolchain to be selected for a target building for that platform. |
 | `target_settings` | List of [labels](/versions/8.5.1/concepts/labels); default is `[]` A list of `config_setting`s that must be satisfied by the target configuration in order for this toolchain to be selected during toolchain resolution. |
 | `toolchain` | [Name](/versions/8.5.1/concepts/labels#target-names); required The target representing the actual tool or tool suite that is made available when this toolchain is selected. |
-| `toolchain_type` | [Label](/versions/8.5.1/concepts/labels); [nonconfigurable](common-definitions#configurable-attributes); required The label of a `toolchain_type` target that represents the role that this toolchain serves. |
-| `use_target_platform_constraints` | Boolean; [nonconfigurable](common-definitions#configurable-attributes); default is `False` If `True`, this toolchain behaves as if its `exec_compatible_with` and `target_compatible_with` constraints are set to those of the current target platform. `exec_compatible_with` and `target_compatible_with` must not be set in that case. |
+| `toolchain_type` | [Label](/versions/8.5.1/concepts/labels); [nonconfigurable](/versions/8.5.1/reference/be/common-definitions#configurable-attributes); required The label of a `toolchain_type` target that represents the role that this toolchain serves. |
+| `use_target_platform_constraints` | Boolean; [nonconfigurable](/versions/8.5.1/reference/be/common-definitions#configurable-attributes); default is `False` If `True`, this toolchain behaves as if its `exec_compatible_with` and `target_compatible_with` constraints are set to those of the current target platform. `exec_compatible_with` and `target_compatible_with` must not be set in that case. |
 
 ## toolchain\_type
 
@@ -353,4 +353,4 @@ bar_binary = rule(
 | Attributes | |
 | --- | --- |
 | `name` | [Name](/versions/8.5.1/concepts/labels#target-names); required  A unique name for this target. |
-| `no_match_error` | String; [nonconfigurable](common-definitions#configurable-attributes); default is `""` A custom error message to display when no matching toolchain is found for this type. |
\ No newline at end of file
+| `no_match_error` | String; [nonconfigurable](/versions/8.5.1/reference/be/common-definitions#configurable-attributes); default is `""` A custom error message to display when no matching toolchain is found for this type. |
\ No newline at end of file
diff --git a/versions/8.5.1/reference/be/protocol-buffer.mdx b/versions/8.5.1/reference/be/protocol-buffer.mdx
index 9e69abbc..17faf623 100644
--- a/versions/8.5.1/reference/be/protocol-buffer.mdx
+++ b/versions/8.5.1/reference/be/protocol-buffer.mdx
@@ -22,7 +22,7 @@ cc_proto_library(name, deps, compatible_with, deprecation, distribs, exec_compat
 
 `cc_proto_library` generates C++ code from `.proto` files.
 
-`deps` must point to [`proto_library`](protocol-buffer#proto_library) rules.
+`deps` must point to [`proto_library`](/versions/8.5.1/reference/be/protocol-buffer#proto_library) rules.
 
 Example:
 
@@ -47,7 +47,7 @@ proto_library(
 | Attributes | |
 | --- | --- |
 | `name` | [Name](/versions/8.5.1/concepts/labels#target-names); required  A unique name for this target. |
-| `deps` | List of [labels](/versions/8.5.1/concepts/labels); default is `[]` The list of [`proto_library`](protocol-buffer#proto_library) rules to generate C++ code for. |
+| `deps` | List of [labels](/versions/8.5.1/concepts/labels); default is `[]` The list of [`proto_library`](/versions/8.5.1/reference/be/protocol-buffer#proto_library) rules to generate C++ code for. |
 
 ## java\_lite\_proto\_library
 
@@ -59,7 +59,7 @@ java_lite_proto_library(name, deps, compatible_with, deprecation, distribs, exec
 
 `java_lite_proto_library` generates Java code from `.proto` files.
 
-`deps` must point to [`proto_library`](protocol-buffer#proto_library) rules.
+`deps` must point to [`proto_library`](/versions/8.5.1/reference/be/protocol-buffer#proto_library) rules.
 
 Example:
 
@@ -84,7 +84,7 @@ proto_library(
 | Attributes | |
 | --- | --- |
 | `name` | [Name](/versions/8.5.1/concepts/labels#target-names); required  A unique name for this target. |
-| `deps` | List of [labels](/versions/8.5.1/concepts/labels); default is `[]` The list of [`proto_library`](protocol-buffer#proto_library) rules to generate Java code for. |
+| `deps` | List of [labels](/versions/8.5.1/concepts/labels); default is `[]` The list of [`proto_library`](/versions/8.5.1/reference/be/protocol-buffer#proto_library) rules to generate Java code for. |
 
 ## java\_proto\_library
 
@@ -96,7 +96,7 @@ java_proto_library(name, deps, compatible_with, deprecation, distribs, exec_comp
 
 `java_proto_library` generates Java code from `.proto` files.
 
-`deps` must point to [`proto_library`](protocol-buffer#proto_library) rules.
+`deps` must point to [`proto_library`](/versions/8.5.1/reference/be/protocol-buffer#proto_library) rules.
 
 Example:
 
@@ -121,7 +121,7 @@ proto_library(
 | Attributes | |
 | --- | --- |
 | `name` | [Name](/versions/8.5.1/concepts/labels#target-names); required  A unique name for this target. |
-| `deps` | List of [labels](/versions/8.5.1/concepts/labels); default is `[]` The list of [`proto_library`](protocol-buffer#proto_library) rules to generate Java code for. |
+| `deps` | List of [labels](/versions/8.5.1/concepts/labels); default is `[]` The list of [`proto_library`](/versions/8.5.1/reference/be/protocol-buffer#proto_library) rules to generate Java code for. |
 
 ## proto\_library
 
diff --git a/versions/8.5.1/reference/be/python.mdx b/versions/8.5.1/reference/be/python.mdx
index e96a746e..f7d4dfba 100644
--- a/versions/8.5.1/reference/be/python.mdx
+++ b/versions/8.5.1/reference/be/python.mdx
@@ -22,13 +22,13 @@ py_binary(name, deps, srcs, data, args, compatible_with, deprecation, distribs,
 | Attributes | |
 | --- | --- |
 | `name` | [Name](/versions/8.5.1/concepts/labels#target-names); required  A unique name for this target. |
-| `deps` | List of [labels](/versions/8.5.1/concepts/labels); default is `[]` List of additional libraries to be linked in to the target. See comments about the [`deps` attribute typically defined by rules](https://bazel.build/reference/be/common-definitions#typical-attributes). These are typically `py\_library` rules. Targets that only provide data files used at runtime belong in the `data` attribute. |
+| `deps` | List of [labels](/versions/8.5.1/concepts/labels); default is `[]` List of additional libraries to be linked in to the target. See comments about the [`deps` attribute typically defined by rules](https://bazel.build/versions/8.5.1/reference/be/common-definitions#typical-attributes). These are typically `py\_library` rules. Targets that only provide data files used at runtime belong in the `data` attribute. |
 | `srcs` | List of [labels](/versions/8.5.1/concepts/labels); required The list of Python source files that are processed to create the target. This includes all your checked-in code and may include generated source files. The `.py` files belong in `srcs` and library targets belong in `deps`. Other binary files that may be needed at run time belong in `data`. |
-| `data` | List of [labels](/versions/8.5.1/concepts/labels); default is `[]` The list of files need by this library at runtime. See comments about the [`data` attribute typically defined by rules](https://bazel.build/reference/be/common-definitions#typical-attributes). There is no `py\_embed\_data` like there is `cc\_embed\_data` and `go\_embed\_data`. This is because Python has a concept of runtime resources. |
+| `data` | List of [labels](/versions/8.5.1/concepts/labels); default is `[]` The list of files need by this library at runtime. See comments about the [`data` attribute typically defined by rules](https://bazel.build/versions/8.5.1/reference/be/common-definitions#typical-attributes). There is no `py\_embed\_data` like there is `cc\_embed\_data` and `go\_embed\_data`. This is because Python has a concept of runtime resources. |
 | `imports` | List of strings; default is `[]` List of import directories to be added to the PYTHONPATH. Subject to "Make variable" substitution. These import directories will be added for this rule and all rules that depend on it (note: not the rules this rule depends on. Each directory will be added to `PYTHONPATH` by `py\_binary` rules that depend on this rule. The strings are repo-runfiles-root relative, Absolute paths (paths that start with `/`) and paths that references a path above the execution root are not allowed and will result in an error. |
 | `legacy_create_init` | Integer; default is `-1` Whether to implicitly create empty `\_\_init\_\_.py` files in the runfiles tree. These are created in every directory containing Python source code or shared libraries, and every parent directory of those directories, excluding the repo root directory. The default, `-1` (auto), means true unless `--incompatible\_default\_to\_explicit\_init\_py` is used. If false, the user is responsible for creating (possibly empty) `\_\_init\_\_.py` files and adding them to the `srcs` of Python targets as required. |
 | `main` | [Label](/versions/8.5.1/concepts/labels); default is `None` Optional; the name of the source file that is the main entry point of the application. This file must also be listed in `srcs`. If left unspecified, `name`, with `.py` appended, is used instead. If `name` does not match any filename in `srcs`, `main` must be specified. |
-| `precompile` | String; default is `"inherit"` Whether py source files \*\*for this target\*\* should be precompiled. Values: \* `inherit`: Allow the downstream binary decide if precompiled files are used. \* `enabled`: Compile Python source files at build time. \* `disabled`: Don't compile Python source files at build time. :::{seealso} \* The {flag}`--precompile` flag, which can override this attribute in some cases and will affect all targets when building. \* The {obj}`pyc\_collection` attribute for transitively enabling precompiling on a per-target basis. \* The [Precompiling](precompiling) docs for a guide about using precompiling. ::: |
+| `precompile` | String; default is `"inherit"` Whether py source files \*\*for this target\*\* should be precompiled. Values: \* `inherit`: Allow the downstream binary decide if precompiled files are used. \* `enabled`: Compile Python source files at build time. \* `disabled`: Don't compile Python source files at build time. :::{seealso} \* The {flag}`--precompile` flag, which can override this attribute in some cases and will affect all targets when building. \* The {obj}`pyc\_collection` attribute for transitively enabling precompiling on a per-target basis. \* The [Precompiling](/versions/8.5.1/reference/be/precompiling) docs for a guide about using precompiling. ::: |
 | `precompile_invalidation_mode` | String; default is `"auto"` How precompiled files should be verified to be up-to-date with their associated source files. Possible values are: \* `auto`: The effective value will be automatically determined by other build settings. \* `checked\_hash`: Use the pyc file if the hash of the source file matches the hash recorded in the pyc file. This is most useful when working with code that you may modify. \* `unchecked\_hash`: Always use the pyc file; don't check the pyc's hash against the source file. This is most useful when the code won't be modified. For more information on pyc invalidation modes, see https://docs.python.org/3/library/py\_compile.html#py\_compile.PycInvalidationMode |
 | `precompile_optimize_level` | Integer; default is `0` The optimization level for precompiled files. For more information about optimization levels, see the `compile()` function's `optimize` arg docs at https://docs.python.org/3/library/functions.html#compile NOTE: The value `-1` means "current interpreter", which will be the interpreter used \_at build time when pycs are generated\_, not the interpreter used at runtime when the code actually runs. |
 | `precompile_source_retention` | String; default is `"inherit"` Determines, when a source file is compiled, if the source file is kept in the resulting output or not. Valid values are: \* `inherit`: Inherit the value from the {flag}`--precompile\_source\_retention` flag. \* `keep\_source`: Include the original Python source. \* `omit\_source`: Don't include the original py source. |
@@ -61,11 +61,11 @@ Source files are no longer added to the runfiles directly.
 | Attributes | |
 | --- | --- |
 | `name` | [Name](/versions/8.5.1/concepts/labels#target-names); required  A unique name for this target. |
-| `deps` | List of [labels](/versions/8.5.1/concepts/labels); default is `[]` List of additional libraries to be linked in to the target. See comments about the [`deps` attribute typically defined by rules](https://bazel.build/reference/be/common-definitions#typical-attributes). These are typically `py\_library` rules. Targets that only provide data files used at runtime belong in the `data` attribute. |
+| `deps` | List of [labels](/versions/8.5.1/concepts/labels); default is `[]` List of additional libraries to be linked in to the target. See comments about the [`deps` attribute typically defined by rules](https://bazel.build/versions/8.5.1/reference/be/common-definitions#typical-attributes). These are typically `py\_library` rules. Targets that only provide data files used at runtime belong in the `data` attribute. |
 | `srcs` | List of [labels](/versions/8.5.1/concepts/labels); default is `[]` The list of Python source files that are processed to create the target. This includes all your checked-in code and may include generated source files. The `.py` files belong in `srcs` and library targets belong in `deps`. Other binary files that may be needed at run time belong in `data`. |
-| `data` | List of [labels](/versions/8.5.1/concepts/labels); default is `[]` The list of files need by this library at runtime. See comments about the [`data` attribute typically defined by rules](https://bazel.build/reference/be/common-definitions#typical-attributes). There is no `py\_embed\_data` like there is `cc\_embed\_data` and `go\_embed\_data`. This is because Python has a concept of runtime resources. |
+| `data` | List of [labels](/versions/8.5.1/concepts/labels); default is `[]` The list of files need by this library at runtime. See comments about the [`data` attribute typically defined by rules](https://bazel.build/versions/8.5.1/reference/be/common-definitions#typical-attributes). There is no `py\_embed\_data` like there is `cc\_embed\_data` and `go\_embed\_data`. This is because Python has a concept of runtime resources. |
 | `imports` | List of strings; default is `[]` List of import directories to be added to the PYTHONPATH. Subject to "Make variable" substitution. These import directories will be added for this rule and all rules that depend on it (note: not the rules this rule depends on. Each directory will be added to `PYTHONPATH` by `py\_binary` rules that depend on this rule. The strings are repo-runfiles-root relative, Absolute paths (paths that start with `/`) and paths that references a path above the execution root are not allowed and will result in an error. |
-| `precompile` | String; default is `"inherit"` Whether py source files \*\*for this target\*\* should be precompiled. Values: \* `inherit`: Allow the downstream binary decide if precompiled files are used. \* `enabled`: Compile Python source files at build time. \* `disabled`: Don't compile Python source files at build time. :::{seealso} \* The {flag}`--precompile` flag, which can override this attribute in some cases and will affect all targets when building. \* The {obj}`pyc\_collection` attribute for transitively enabling precompiling on a per-target basis. \* The [Precompiling](precompiling) docs for a guide about using precompiling. ::: |
+| `precompile` | String; default is `"inherit"` Whether py source files \*\*for this target\*\* should be precompiled. Values: \* `inherit`: Allow the downstream binary decide if precompiled files are used. \* `enabled`: Compile Python source files at build time. \* `disabled`: Don't compile Python source files at build time. :::{seealso} \* The {flag}`--precompile` flag, which can override this attribute in some cases and will affect all targets when building. \* The {obj}`pyc\_collection` attribute for transitively enabling precompiling on a per-target basis. \* The [Precompiling](/versions/8.5.1/reference/be/precompiling) docs for a guide about using precompiling. ::: |
 | `precompile_invalidation_mode` | String; default is `"auto"` How precompiled files should be verified to be up-to-date with their associated source files. Possible values are: \* `auto`: The effective value will be automatically determined by other build settings. \* `checked\_hash`: Use the pyc file if the hash of the source file matches the hash recorded in the pyc file. This is most useful when working with code that you may modify. \* `unchecked\_hash`: Always use the pyc file; don't check the pyc's hash against the source file. This is most useful when the code won't be modified. For more information on pyc invalidation modes, see https://docs.python.org/3/library/py\_compile.html#py\_compile.PycInvalidationMode |
 | `precompile_optimize_level` | Integer; default is `0` The optimization level for precompiled files. For more information about optimization levels, see the `compile()` function's `optimize` arg docs at https://docs.python.org/3/library/functions.html#compile NOTE: The value `-1` means "current interpreter", which will be the interpreter used \_at build time when pycs are generated\_, not the interpreter used at runtime when the code actually runs. |
 | `precompile_source_retention` | String; default is `"inherit"` Determines, when a source file is compiled, if the source file is kept in the resulting output or not. Valid values are: \* `inherit`: Inherit the value from the {flag}`--precompile\_source\_retention` flag. \* `keep\_source`: Include the original Python source. \* `omit\_source`: Don't include the original py source. |
@@ -84,13 +84,13 @@ py_test(name, deps, srcs, data, args, compatible_with, deprecation, distribs, en
 | Attributes | |
 | --- | --- |
 | `name` | [Name](/versions/8.5.1/concepts/labels#target-names); required  A unique name for this target. |
-| `deps` | List of [labels](/versions/8.5.1/concepts/labels); default is `[]` List of additional libraries to be linked in to the target. See comments about the [`deps` attribute typically defined by rules](https://bazel.build/reference/be/common-definitions#typical-attributes). These are typically `py\_library` rules. Targets that only provide data files used at runtime belong in the `data` attribute. |
+| `deps` | List of [labels](/versions/8.5.1/concepts/labels); default is `[]` List of additional libraries to be linked in to the target. See comments about the [`deps` attribute typically defined by rules](https://bazel.build/versions/8.5.1/reference/be/common-definitions#typical-attributes). These are typically `py\_library` rules. Targets that only provide data files used at runtime belong in the `data` attribute. |
 | `srcs` | List of [labels](/versions/8.5.1/concepts/labels); required The list of Python source files that are processed to create the target. This includes all your checked-in code and may include generated source files. The `.py` files belong in `srcs` and library targets belong in `deps`. Other binary files that may be needed at run time belong in `data`. |
-| `data` | List of [labels](/versions/8.5.1/concepts/labels); default is `[]` The list of files need by this library at runtime. See comments about the [`data` attribute typically defined by rules](https://bazel.build/reference/be/common-definitions#typical-attributes). There is no `py\_embed\_data` like there is `cc\_embed\_data` and `go\_embed\_data`. This is because Python has a concept of runtime resources. |
+| `data` | List of [labels](/versions/8.5.1/concepts/labels); default is `[]` The list of files need by this library at runtime. See comments about the [`data` attribute typically defined by rules](https://bazel.build/versions/8.5.1/reference/be/common-definitions#typical-attributes). There is no `py\_embed\_data` like there is `cc\_embed\_data` and `go\_embed\_data`. This is because Python has a concept of runtime resources. |
 | `imports` | List of strings; default is `[]` List of import directories to be added to the PYTHONPATH. Subject to "Make variable" substitution. These import directories will be added for this rule and all rules that depend on it (note: not the rules this rule depends on. Each directory will be added to `PYTHONPATH` by `py\_binary` rules that depend on this rule. The strings are repo-runfiles-root relative, Absolute paths (paths that start with `/`) and paths that references a path above the execution root are not allowed and will result in an error. |
 | `legacy_create_init` | Integer; default is `-1` Whether to implicitly create empty `\_\_init\_\_.py` files in the runfiles tree. These are created in every directory containing Python source code or shared libraries, and every parent directory of those directories, excluding the repo root directory. The default, `-1` (auto), means true unless `--incompatible\_default\_to\_explicit\_init\_py` is used. If false, the user is responsible for creating (possibly empty) `\_\_init\_\_.py` files and adding them to the `srcs` of Python targets as required. |
 | `main` | [Label](/versions/8.5.1/concepts/labels); default is `None` Optional; the name of the source file that is the main entry point of the application. This file must also be listed in `srcs`. If left unspecified, `name`, with `.py` appended, is used instead. If `name` does not match any filename in `srcs`, `main` must be specified. |
-| `precompile` | String; default is `"inherit"` Whether py source files \*\*for this target\*\* should be precompiled. Values: \* `inherit`: Allow the downstream binary decide if precompiled files are used. \* `enabled`: Compile Python source files at build time. \* `disabled`: Don't compile Python source files at build time. :::{seealso} \* The {flag}`--precompile` flag, which can override this attribute in some cases and will affect all targets when building. \* The {obj}`pyc\_collection` attribute for transitively enabling precompiling on a per-target basis. \* The [Precompiling](precompiling) docs for a guide about using precompiling. ::: |
+| `precompile` | String; default is `"inherit"` Whether py source files \*\*for this target\*\* should be precompiled. Values: \* `inherit`: Allow the downstream binary decide if precompiled files are used. \* `enabled`: Compile Python source files at build time. \* `disabled`: Don't compile Python source files at build time. :::{seealso} \* The {flag}`--precompile` flag, which can override this attribute in some cases and will affect all targets when building. \* The {obj}`pyc\_collection` attribute for transitively enabling precompiling on a per-target basis. \* The [Precompiling](/versions/8.5.1/reference/be/precompiling) docs for a guide about using precompiling. ::: |
 | `precompile_invalidation_mode` | String; default is `"auto"` How precompiled files should be verified to be up-to-date with their associated source files. Possible values are: \* `auto`: The effective value will be automatically determined by other build settings. \* `checked\_hash`: Use the pyc file if the hash of the source file matches the hash recorded in the pyc file. This is most useful when working with code that you may modify. \* `unchecked\_hash`: Always use the pyc file; don't check the pyc's hash against the source file. This is most useful when the code won't be modified. For more information on pyc invalidation modes, see https://docs.python.org/3/library/py\_compile.html#py\_compile.PycInvalidationMode |
 | `precompile_optimize_level` | Integer; default is `0` The optimization level for precompiled files. For more information about optimization levels, see the `compile()` function's `optimize` arg docs at https://docs.python.org/3/library/functions.html#compile NOTE: The value `-1` means "current interpreter", which will be the interpreter used \_at build time when pycs are generated\_, not the interpreter used at runtime when the code actually runs. |
 | `precompile_source_retention` | String; default is `"inherit"` Determines, when a source file is compiled, if the source file is kept in the resulting output or not. Valid values are: \* `inherit`: Inherit the value from the {flag}`--precompile\_source\_retention` flag. \* `keep\_source`: Include the original Python source. \* `omit\_source`: Don't include the original py source. |
diff --git a/versions/8.5.1/reference/be/workspace.mdx b/versions/8.5.1/reference/be/workspace.mdx
index 82e93dfa..78b5d809 100644
--- a/versions/8.5.1/reference/be/workspace.mdx
+++ b/versions/8.5.1/reference/be/workspace.mdx
@@ -25,8 +25,7 @@ bind(name, actual, compatible_with, deprecation, distribs, features, licenses, r
 
 *Warning: use of `bind()` is not recommended. See "[Consider removing bind](https://github.com/bazelbuild/bazel/issues/1952)" for a long
 discussion of its issues and alternatives. In particular, consider the use of
-[`repo_mapping`
-repository attributes](https://bazel.build/versions/8.5.1/rules/repository_rules#attributes).*
+[`repo_mapping` repository attributes](https://bazel.build/versions/8.5.1/rules/repository_rules#attributes).*
 
 *Warning: `select()` cannot be used in `bind()`. See the [Configurable Attributes FAQ](/versions/8.5.1/docs/configurable-attributes#bind-select) for
 details.*
@@ -114,8 +113,7 @@ local_repository(name, path, repo_mapping)
 ```
 
 Allows targets from a local directory to be bound. This means that the current repository can
-use targets defined in this other directory. See the [bind
-section](/versions/8.5.1/reference/be/workspace#bind_examples) for more details.
+use targets defined in this other directory. See the [bind section](/versions/8.5.1/reference/be/workspace#bind_examples) for more details.
 
 #### Examples
 
diff --git a/versions/8.5.1/reference/command-line-reference.mdx b/versions/8.5.1/reference/command-line-reference.mdx
index c0711e04..bdbc24cc 100644
--- a/versions/8.5.1/reference/command-line-reference.mdx
+++ b/versions/8.5.1/reference/command-line-reference.mdx
@@ -511,7 +511,7 @@ This option affects semantics of the Starlark language or the build API accessib
     [`loading_and_analysis`](#effect_tag_LOADING_AND_ANALYSIS), [`experimental`](#metadata_tag_EXPERIMENTAL)
 
 `--[no]experimental_isolated_extension_usages` default: "false"
-:   If true, enables the isolate parameter in the use\_extension function.
+:   If true, enables the isolate parameter in the use\_extension function.
 
     Tags:
     [`loading_and_analysis`](#effect_tag_LOADING_AND_ANALYSIS)
diff --git a/versions/8.5.1/reference/glossary.mdx b/versions/8.5.1/reference/glossary.mdx
index 7fb81c45..0e004520 100644
--- a/versions/8.5.1/reference/glossary.mdx
+++ b/versions/8.5.1/reference/glossary.mdx
@@ -21,8 +21,7 @@ An in-memory graph of [actions](#action) and the [artifacts](#artifact) that
 these actions read and generate. The graph might include artifacts that exist as
 source files (for example, in the file system) as well as generated
 intermediate/final artifacts that are not mentioned in `BUILD` files. Produced
-during the [analysis phase](#analysis-phase) and used during the [execution
-phase](#execution-phase).
+during the [analysis phase](#analysis-phase) and used during the [execution phase](#execution-phase).
 
 ### Action graph query (aquery) {#action-graph-query}
 A [query](#query-concept) tool that can query over build [actions](#action).
@@ -37,8 +36,7 @@ invalidate individual actions deterministically.
 
 ### Analysis phase {#analysis-phase}
 The second phase of a build. Processes the [target graph](#target-graph)
-specified in [`BUILD` files](#build-file) to produce an in-memory [action
-graph](#action-graph) that determines the order of actions to run during the
+specified in [`BUILD` files](#build-file) to produce an in-memory [action graph](#action-graph) that determines the order of actions to run during the
 [execution phase](#execution-phase). This is the phase in which rule
 implementations are evaluated.
 
@@ -81,8 +79,7 @@ target's source files, dependencies, and custom compiler options. The particular
 attributes available for a given target depend on its rule type.
 
 ### .bazelrc {#bazelrc}
-Bazel’s configuration file used to change the default values for [startup
-flags](#startup-flags) and [command flags](#command-flags), and to define common
+Bazel’s configuration file used to change the default values for [startup flags](#startup-flags) and [command flags](#command-flags), and to define common
 groups of options that can then be set together on the Bazel command line using
 a `--config` flag. Bazel can combine settings from multiple bazelrc files
 (systemwide, per-workspace, per-user, or from a custom location), and a
@@ -108,8 +105,7 @@ directory.
 
 ### .bzl File {#bzl-file}
 A file that defines rules, [macros](#macro), and constants written in
-[Starlark](#starlark). These can then be imported into [`BUILD`
-files](#build-file) using the `load()` function.
+[Starlark](#starlark). These can then be imported into [`BUILD` files](#build-file) using the `load()` function.
 
 {/* TODO: ### Build event protocol */}
 
@@ -117,8 +113,7 @@ files](#build-file) using the `load()` function.
 
 ### Build graph {#build-graph}
 The dependency graph that Bazel constructs and traverses to perform a build.
-Includes nodes like [targets](#target), [configured
-targets](#configured-target), [actions](#action), and [artifacts](#artifact). A
+Includes nodes like [targets](#target), [configured targets](#configured-target), [actions](#action), and [artifacts](#artifact). A
 build is considered complete when all [artifacts](#artifact) on which a set of
 requested targets depend are verified as up-to-date.
 
@@ -158,8 +153,7 @@ graphs and restart the [analysis phase](#analysis-phase).
 ### Configuration {#configuration}
 Information outside of [rule](#rule) definitions that impacts how rules generate
 [actions](#action). Every build has at least one configuration specifying the
-target platform, action environment variables, and command-line [build
-flags](#command-flags). [Transitions](#transition) may create additional
+target platform, action environment variables, and command-line [build flags](#command-flags). [Transitions](#transition) may create additional
 configurations, such as for host tools or cross-compilation.
 
 **See also:** [Configurations](/versions/8.5.1/extending/rules#configurations)
@@ -174,8 +168,7 @@ configuration of `//:c` because changing `--javacopt` unnecessarily breaks C++
 build cacheability.
 
 ### Configured query (cquery) {#configured-query}
-A [query](#query-concept) tool that queries over [configured
-targets](#configured-target) (after the [analysis phase](#analysis-phase)
+A [query](#query-concept) tool that queries over [configured targets](#configured-target) (after the [analysis phase](#analysis-phase)
 completes). This means `select()` and [build flags](#command-flags) (such as
 `--platforms`) are accurately reflected in the results.
 
@@ -191,8 +184,7 @@ build, it has two configured targets: `` and ``.
 ### Correctness {#correctness}
 A build is correct when its output faithfully reflects the state of its
 transitive inputs. To achieve correct builds, Bazel strives to be
-[hermetic](#hermeticity), reproducible, and making [build
-analysis](#analysis-phase) and [action execution](#execution-phase)
+[hermetic](#hermeticity), reproducible, and making [build analysis](#analysis-phase) and [action execution](#execution-phase)
 deterministic.
 
 ### Dependency {#dependency}
@@ -234,8 +226,7 @@ compilation). A dynamic execution strategy can provide the best possible
 incremental and clean build times.
 
 ### Execution phase {#execution-phase}
-The third phase of a build. Executes the [actions](#action) in the [action
-graph](#action-graph) created during the [analysis phase](#analysis-phase).
+The third phase of a build. Executes the [actions](#action) in the [action graph](#action-graph) created during the [analysis phase](#analysis-phase).
 These actions invoke executables (compilers, scripts) to read and write
 [artifacts](#artifact). *Spawn strategies* control how these actions are
 executed: locally, remotely, dynamically, sandboxed, docker, and so on.
@@ -285,8 +276,7 @@ syntax may be omitted.
 The first phase of a build where Bazel executes [`BUILD` files](#build-file) to
 create [packages](#package). [Macros](#macro) and certain functions like
 `glob()` are evaluated in this phase. Interleaved with the second phase of the
-build, the [analysis phase](#analysis-phase), to build up a [target
-graph](#target-graph).
+build, the [analysis phase](#analysis-phase), to build up a [target graph](#target-graph).
 
 ### Legacy macro {#legacy-macro}
 A flavor of [macro](#macro) which is declared as an ordinary
@@ -336,8 +326,7 @@ Module metadata is hosted in Bazel registries.
 
 ### Module Extension {#module-extension}
 A piece of logic that can be run to generate [repos](#repository) by reading
-inputs from across the [module](#module) dependency graph and invoking [repo
-rules](#repository-rule). Module extensions have capabilities similar to repo
+inputs from across the [module](#module) dependency graph and invoking [repo rules](#repository-rule). Module extensions have capabilities similar to repo
 rules, allowing them to access the internet, perform file I/O, and so on.
 
 **See also:** [Module extensions](/versions/8.5.1/external/extension)
@@ -350,8 +339,7 @@ example, `native.cc_library` or `native.java_library`). User-defined rules
 
 ### Output base {#output-base}
 A [workspace](#workspace)-specific directory to store Bazel output files. Used
-to separate outputs from the *workspace*'s source tree (the [main
-repo](#repository)). Located in the [output user root](#output-user-root).
+to separate outputs from the *workspace*'s source tree (the [main repo](#repository)). Located in the [output user root](#output-user-root).
 
 ### Output groups {#output-groups}
 A group of files that is expected to be built when Bazel finishes building a
@@ -406,8 +394,7 @@ query variants: [query](#query-command), [cquery](#configured-query), and
 [aquery](#action-graph-query).
 
 ### query (command) {#query-command}
-A [query](#query-concept) tool that operates over the build's post-[loading
-phase](#loading-phase) [target graph](#target-graph). This is relatively fast,
+A [query](#query-concept) tool that operates over the build's post-[loading phase](#loading-phase) [target graph](#target-graph). This is relatively fast,
 but can't analyze the effects of `select()`, [build flags](#command-flags),
 [artifacts](#artifact), or build [actions](#action).
 
@@ -425,8 +412,7 @@ repo; multiple such files can coexist in a directory.
 The *main repo* is the repo in which the current Bazel command is being run.
 
 *External repos* are defined by specifying [modules](#module) in `MODULE.bazel`
-files, or invoking [repo rules](#repository-rule) in [module
-extensions](#module-extension). They can be fetched on demand to a predetermined
+files, or invoking [repo rules](#repository-rule) in [module extensions](#module-extension). They can be fetched on demand to a predetermined
 "magical" location on disk.
 
 Each repo has a unique, constant *canonical* name, and potentially different
@@ -437,8 +423,7 @@ Each repo has a unique, constant *canonical* name, and potentially different
 ### Repository cache {#repo-cache}
 A shared content-addressable cache of files downloaded by Bazel for builds,
 shareable across [workspaces](#workspace). Enables offline builds after the
-initial download. Commonly used to cache files downloaded through [repository
-rules](#repository-rule) like `http_archive` and repository rule APIs like
+initial download. Commonly used to cache files downloaded through [repository rules](#repository-rule) like `http_archive` and repository rule APIs like
 `repository_ctx.download`. Files are cached only if their SHA-256 checksums are
 specified for the download.
 
@@ -472,8 +457,7 @@ Rules are instantiated to produce rule targets in the
 [loading phase](#loading-phase). In the [analysis phase](#analysis-phase) rule
 targets communicate information to their downstream dependencies in the form of
 [providers](#provider), and register [actions](#action) describing how to
-generate their output artifacts. These actions are run in the [execution
-phase](#execution-phase).
+generate their output artifacts. These actions are run in the [execution phase](#execution-phase).
 
 Note: Historically the term "rule" has been used to refer to a rule target.
 This usage was inherited from tools like Make, but causes confusion and should
@@ -517,8 +501,7 @@ support the stamp attribute.
 ### Starlark {#starlark}
 The extension language for writing [rules](/versions/8.5.1/extending/rules) and [macros](#macro). A
 restricted subset of Python (syntactically and grammatically) aimed for the
-purpose of configuration, and for better performance. Uses the [`.bzl`
-file](#bzl-file) extension. [`BUILD` files](#build-file) use an even more
+purpose of configuration, and for better performance. Uses the [`.bzl` file](#bzl-file) extension. [`BUILD` files](#build-file) use an even more
 restricted version of Starlark (such as no `def` function definitions), formerly
 known as Skylark.
 
@@ -549,8 +532,7 @@ An object that is defined in a [`BUILD` file](#build-file) and identified by a
 [label](#label). Targets represent the buildable units of a workspace from
 the perspective of the end user.
 
-A target that is declared by instantiating a [rule](#rule) is called a [rule
-target](#rule-target). Depending on the rule, these may be runnable (like
+A target that is declared by instantiating a [rule](#rule) is called a [rule target](#rule-target). Depending on the rule, these may be runnable (like
 `cc_binary`) or testable (like `cc_test`). Rule targets typically depend on
 other targets via their [attributes](#attribute) (such as `deps`); these
 dependencies form the basis of the [target graph](#target-graph).
@@ -561,14 +543,11 @@ within a `BUILD` file. As a special case, the `BUILD` file of any package is
 always considered a source file target in that package.
 
 Targets are discovered during the [loading phase](#loading-phase). During the
-[analysis phase](#analysis-phase), targets are associated with [build
-configurations](#configuration) to form [configured
-targets](#configured-target).
+[analysis phase](#analysis-phase), targets are associated with [build configurations](#configuration) to form [configured targets](#configured-target).
 
 ### Target graph {#target-graph}
 An in-memory graph of [targets](#target) and their dependencies. Produced during
-the [loading phase](#loading-phase) and used as an input to the [analysis
-phase](#analysis-phase).
+the [loading phase](#loading-phase) and used as an input to the [analysis phase](#analysis-phase).
 
 ### Target pattern {#target-pattern}
 A way to specify a group of [targets](#target) on the command line. Commonly
@@ -581,8 +560,7 @@ packages recursively from the root of the [workspace](#workspace).
 Rule [targets](#target) instantiated from test rules, and therefore contains a
 test executable. A return code of zero from the completion of the executable
 indicates test success. The exact contract between Bazel and tests (such as test
-environment variables, test result collection methods) is specified in the [Test
-Encyclopedia](/versions/8.5.1/reference/test-encyclopedia).
+environment variables, test result collection methods) is specified in the [Test Encyclopedia](/versions/8.5.1/reference/test-encyclopedia).
 
 ### Toolchain {#toolchain}
 A set of tools to build outputs for a language. Typically, a toolchain includes
@@ -596,8 +574,7 @@ A build [target](#target) is top-level if it’s requested on the Bazel command
 line. For example, if `//:foo` depends on `//:bar`, and `bazel build //:foo` is
 called, then for this build, `//:foo` is top-level, and `//:bar` isn’t
 top-level, although both targets will need to be built. An important difference
-between top-level and non-top-level targets is that [command
-flags](#command-flags) set on the Bazel command line (or via
+between top-level and non-top-level targets is that [command flags](#command-flags) set on the Bazel command line (or via
 [.bazelrc](#bazelrc)) will set the [configuration](#configuration) for top-level
 targets, but might be modified by a [transition](#transition) for non-top-level
 targets.
@@ -628,8 +605,7 @@ or `.bzl` file may load a given `.bzl` file. Without context, usually
 **See also:** [Visibility documentation](/versions/8.5.1/concepts/visibility)
 
 ### Workspace {#workspace}
-The environment shared by all Bazel commands run from the same [main
-repository](#repository).
+The environment shared by all Bazel commands run from the same [main repository](#repository).
 
 Note that historically the concepts of "repository" and "workspace" have been
 conflated; the term "workspace" has often been used to refer to the main
diff --git a/versions/8.5.1/release/backward-compatibility.mdx b/versions/8.5.1/release/backward-compatibility.mdx
index eba056ee..7f9a40ed 100644
--- a/versions/8.5.1/release/backward-compatibility.mdx
+++ b/versions/8.5.1/release/backward-compatibility.mdx
@@ -6,11 +6,9 @@ This page provides information about how to handle backward compatibility,
 including migrating from one release to another and how to communicate
 incompatible changes.
 
-Bazel is evolving. Minor versions released as part of an [LTS major
-version](/versions/8.5.1/release#bazel-versioning) are fully backward-compatible. New major LTS
+Bazel is evolving. Minor versions released as part of an [LTS major version](/versions/8.5.1/release#bazel-versioning) are fully backward-compatible. New major LTS
 releases may contain incompatible changes that require some migration effort.
-For more information about Bazel's release model, please check out the [Release
-Model](/versions/8.5.1/release) page.
+For more information about Bazel's release model, please check out the [Release Model](/versions/8.5.1/release) page.
 
 ## Summary {#summary}
 
@@ -59,8 +57,7 @@ available.
 ## Communicating incompatible changes {#communicating-incompatible-changes}
 
 The primary source of information about incompatible changes are GitHub issues
-marked with an ["incompatible-change"
-label](https://github.com/bazelbuild/bazel/issues?q=label%3Aincompatible-change).
+marked with an ["incompatible-change" label](https://github.com/bazelbuild/bazel/issues?q=label%3Aincompatible-change).
 
 For every incompatible change, the issue specifies the following:
 
diff --git a/versions/8.5.1/release/index.mdx b/versions/8.5.1/release/index.mdx
index 49422dec..726a5635 100644
--- a/versions/8.5.1/release/index.mdx
+++ b/versions/8.5.1/release/index.mdx
@@ -2,8 +2,7 @@
 title: 'Release Model'
 ---
 
-As announced in [the original blog
-post](https://blog.bazel.build/2020/11/10/long-term-support-release.html), Bazel
+As announced in [the original blog post](https://blog.bazel.build/2020/11/10/long-term-support-release.html), Bazel
 4.0 and higher versions provides support for two release tracks: rolling
 releases and long term support (LTS) releases. This page covers the latest
 information about Bazel's release model.
@@ -19,8 +18,7 @@ information about Bazel's release model.
 | Bazel 5 | Maintenance | [5.4.1](https://github.com/bazelbuild/bazel/releases/tag/5.4.1) | Jan 2025 |
 | Bazel 4 | Deprecated | [4.2.4](https://github.com/bazelbuild/bazel/releases/tag/4.2.4) | Jan 2024 |
 
-All Bazel LTS releases can be found on the [release
-page](https://github.com/bazelbuild/bazel/releases) on GitHub.
+All Bazel LTS releases can be found on the [release page](https://github.com/bazelbuild/bazel/releases) on GitHub.
 
 Note: Bazel version older than Bazel 5 are no longer supported, Bazel users are
 recommended to upgrade to the latest LTS release or use rolling releases if you
@@ -28,8 +26,7 @@ want to keep up with the latest changes at HEAD.
 
 ## Release versioning {#bazel-versioning}
 
-Bazel uses a _major.minor.patch_ [Semantic
-Versioning](https://semver.org/) scheme.
+Bazel uses a _major.minor.patch_ [Semantic Versioning](https://semver.org/) scheme.
 
 *   A _major release_ contains features that are not backward compatible with
     the previous release. Each major Bazel version is an LTS release.
@@ -72,8 +69,7 @@ Bazel regularly publish releases for two release tracks.
     release.
 *   Rolling releases can ship incompatible changes. Incompatible flags are
     recommended for major breaking changes, rolling out incompatible changes
-    should follow our [backward compatibility
-    policy](/versions/8.5.1/release/backward-compatibility).
+    should follow our [backward compatibility policy](/versions/8.5.1/release/backward-compatibility).
 
 ### LTS releases {#lts-releases}
 
@@ -89,8 +85,7 @@ Bazel regularly publish releases for two release tracks.
 *   A Bazel LTS release enters the Deprecated stage after being in ​​the
     Maintenance stage for 2 years.
 
-For planned releases, please check our [release
-issues](https://github.com/bazelbuild/bazel/issues?q=is%3Aopen+is%3Aissue+label%3Arelease)
+For planned releases, please check our [release issues](https://github.com/bazelbuild/bazel/issues?q=is%3Aopen+is%3Aissue+label%3Arelease)
 on Github.
 
 ## Release procedure & policies {#release-procedure-policies}
@@ -153,8 +148,7 @@ For LTS releases, the procedure and policies below are followed:
 1.  Identify release blockers and fix issues found on the release branch.
     *   The release branch is tested with the same test suite in
         [postsubmit](https://buildkite.com/bazel/bazel-bazel) and
-        [downstream test pipeline]
-        (https://buildkite.com/bazel/bazel-at-head-plus-downstream)
+        [downstream test pipeline](https://buildkite.com/bazel/bazel-at-head-plus-downstream)
         on Bazel CI. The Bazel team monitors testing results of the release
         branch and fixes any regressions found.
 1.  Create a new release candidate from the release branch when all known
@@ -210,5 +204,4 @@ feature.
 ## Rule compatibility {#rule-compatibility}
 
 If you are a rule authors and want to maintain compatibility with different
-Bazel versions, please check out the [Rule
-Compatibility](/versions/8.5.1/release/rule-compatibility) page.
+Bazel versions, please check out the [Rule Compatibility](/versions/8.5.1/release/rule-compatibility) page.
diff --git a/versions/8.5.1/release/rule-compatibility.mdx b/versions/8.5.1/release/rule-compatibility.mdx
index c5082e89..2a511aa2 100644
--- a/versions/8.5.1/release/rule-compatibility.mdx
+++ b/versions/8.5.1/release/rule-compatibility.mdx
@@ -53,18 +53,15 @@ Bazel LTS release.
 As Bazel rules authors, you can ensure a manageable migration process for users
 by following these best practices:
 
-1.  The rule should follow [Semantic
-    Versioning](https://semver.org/): minor versions of the same
+1.  The rule should follow [Semantic Versioning](https://semver.org/): minor versions of the same
     major version are backward compatible.
 1.  The rule at HEAD should be compatible with the latest Bazel LTS release.
 1.  The rule at HEAD should be compatible with Bazel at HEAD. To achieve this,
     you can
     *   Set up your own CI testing with Bazel at HEAD
-    *   Add your project to [Bazel downstream
-        testing](https://github.com/bazelbuild/continuous-integration/blob/master/docs/downstream-testing.md);
+    *   Add your project to [Bazel downstream testing](https://github.com/bazelbuild/continuous-integration/blob/master/docs/downstream-testing.md);
         the Bazel team files issues to your project if breaking changes in Bazel
-        affect your project, and you must follow our [downstream project
-        policies](https://github.com/bazelbuild/continuous-integration/blob/master/docs/downstream-testing.md#downstream-project-policies)
+        affect your project, and you must follow our [downstream project policies](https://github.com/bazelbuild/continuous-integration/blob/master/docs/downstream-testing.md#downstream-project-policies)
         to address issues timely.
 1.  The latest major version of the rule must be compatible with the latest
     Bazel LTS release.
diff --git a/versions/8.5.1/remote/bep-glossary.mdx b/versions/8.5.1/remote/bep-glossary.mdx
index 7ab2a884..b1edb2f4 100644
--- a/versions/8.5.1/remote/bep-glossary.mdx
+++ b/versions/8.5.1/remote/bep-glossary.mdx
@@ -36,7 +36,7 @@ BEP contains an event like the following:
 ## ActionExecuted {#actionexecuted}
 
 Provides details about the execution of a specific
-[Action](/versions/8.5.1/rules/lib/actions) in a build. By default, this event is
+[Action](/versions/8.5.1/rules/lib/builtins/actions) in a build. By default, this event is
 included in the BEP only for failed actions, to support identifying the root cause
 of build failures. Users may set the `--build_event_publish_all_actions` flag
 to include all `ActionExecuted` events.
@@ -410,5 +410,4 @@ workspace, such as the execution root.
 
 ## WorkspaceStatus {#workspacestatus}
 
-A single `WorkspaceStatus` event contains the result of the [workspace status
-command](/versions/8.5.1/docs/user-manual#workspace-status).
+A single `WorkspaceStatus` event contains the result of the [workspace status command](/versions/8.5.1/docs/user-manual#workspace-status).
diff --git a/versions/8.5.1/remote/bep.mdx b/versions/8.5.1/remote/bep.mdx
index 2f37c08d..ea1a1df5 100644
--- a/versions/8.5.1/remote/bep.mdx
+++ b/versions/8.5.1/remote/bep.mdx
@@ -2,14 +2,12 @@
 title: 'Build Event Protocol'
 ---
 
-The [Build Event
-Protocol](https://github.com/bazelbuild/bazel/blob/master/src/main/java/com/google/devtools/build/lib/buildeventstream/proto/build_event_stream.proto)
+The [Build Event Protocol](https://github.com/bazelbuild/bazel/blob/master/src/main/java/com/google/devtools/build/lib/buildeventstream/proto/build_event_stream.proto)
 (BEP) allows third-party programs to gain insight into a Bazel invocation. For
 example, you could use the BEP to gather information for an IDE
 plugin or a dashboard that displays build results.
 
-The protocol is a set of [protocol
-buffer](https://developers.google.com/protocol-buffers/) messages with some
+The protocol is a set of [protocol buffer](https://developers.google.com/protocol-buffers/) messages with some
 semantics defined on top of it. It includes information about build and test
 results, build progress, the build configuration and much more. The BEP is
 intended to be consumed programmatically and makes parsing Bazel’s
@@ -20,16 +18,13 @@ build event is a protocol buffer message consisting of a build event identifier,
 a set of child event identifiers, and a payload.
 
 *  __Build Event Identifier:__ Depending on the kind of build event, it might be
-an [opaque
-string](https://github.com/bazelbuild/bazel/blob/7.1.0/src/main/java/com/google/devtools/build/lib/buildeventstream/proto/build_event_stream.proto#L131-L140)
-or [structured
-information](https://github.com/bazelbuild/bazel/blob/7.1.0/src/main/java/com/google/devtools/build/lib/buildeventstream/proto/build_event_stream.proto#L194-L205)
+an [opaque string](https://github.com/bazelbuild/bazel/blob/7.1.0/src/main/java/com/google/devtools/build/lib/buildeventstream/proto/build_event_stream.proto#L131-L140)
+or [structured information](https://github.com/bazelbuild/bazel/blob/7.1.0/src/main/java/com/google/devtools/build/lib/buildeventstream/proto/build_event_stream.proto#L194-L205)
 revealing more about the build event. A build event identifier is unique within
 a build.
 
 *  __Children:__ A build event may announce other build events, by including
-their build event identifiers in its [children
-field](https://github.com/bazelbuild/bazel/blob/7.1.0/src/main/java/com/google/devtools/build/lib/buildeventstream/proto/build_event_stream.proto#L1276).
+their build event identifiers in its [children field](https://github.com/bazelbuild/bazel/blob/7.1.0/src/main/java/com/google/devtools/build/lib/buildeventstream/proto/build_event_stream.proto#L1276).
 For example, the `PatternExpanded` build event announces the targets it expands
 to as children. The protocol guarantees that all events, except for the first
 event, are announced by a previous event.
@@ -91,8 +86,7 @@ human-readable formats, such as text and JSON:
 
 ## Build Event Service {#build-event-service}
 
-The [Build Event
-Service](https://github.com/googleapis/googleapis/blob/master/google/devtools/build/v1/publish_build_event.proto)
+The [Build Event Service](https://github.com/googleapis/googleapis/blob/master/google/devtools/build/v1/publish_build_event.proto)
 Protocol is a generic [gRPC](https://www.grpc.io) service for publishing build events. The Build Event
 Service protocol is independent of the BEP and treats BEP events as opaque bytes.
 Bazel ships with a gRPC client implementation of the Build Event Service protocol that
@@ -136,8 +130,7 @@ For a description of each of these flags, see the
 The BEP typically contains many references to log files (test.log, test.xml,
 etc. ) stored on the machine where Bazel is running. A remote BES server
 typically can't access these files as they are on different machines. A way to
-work around this issue is to use Bazel with [remote
-caching](/versions/8.5.1/remote/caching).
+work around this issue is to use Bazel with [remote caching](/versions/8.5.1/remote/caching).
 Bazel will upload all output files to the remote cache (including files
 referenced in the BEP) and the BES server can then fetch the referenced files
 from the cache.
diff --git a/versions/8.5.1/remote/cache-local.mdx b/versions/8.5.1/remote/cache-local.mdx
index add2e191..e02ac2a6 100644
--- a/versions/8.5.1/remote/cache-local.mdx
+++ b/versions/8.5.1/remote/cache-local.mdx
@@ -18,8 +18,7 @@ execution. However, local execution presents some additional challenges.
 ## Checking your cache hit rate {#cache-hits}
 
 Successful remote cache hits will show up in the status line, similar to
-[Cache Hits rate with Remote
-Execution](/versions/8.5.1/remote/cache-remote#check-cache-hits).
+[Cache Hits rate with Remote Execution](/versions/8.5.1/remote/cache-remote#check-cache-hits).
 
 In the standard output of your Bazel run, you will see something like the
 following:
@@ -66,8 +65,7 @@ the steps in this section.
    message you see does not give you enough information, try adding
    `--verbose_failures`.
 
-2. Follow the steps from [Troubleshooting cache hits for remote
-   execution](/versions/8.5.1/remote/cache-remote#troubleshooting_cache_hits) to
+2. Follow the steps from [Troubleshooting cache hits for remote execution](/versions/8.5.1/remote/cache-remote#troubleshooting_cache_hits) to
    ensure that your cache-writing Bazel invocations are able to get cache hits
    on the same machine and across machines.
 
@@ -81,7 +79,6 @@ the steps in this section.
    b. Ensure your cache-reading Bazel invocations build the same targets as the
       cache-writing Bazel invocations.
 
-   c. Follow the same steps as to [ensure caching across
-      machines](/versions/8.5.1/remote/cache-remote#caching-across-machines),
+   c. Follow the same steps as to [ensure caching across machines](/versions/8.5.1/remote/cache-remote#caching-across-machines),
       to ensure caching from your cache-writing Bazel invocation to your
       cache-reading Bazel invocation.
diff --git a/versions/8.5.1/remote/caching.mdx b/versions/8.5.1/remote/caching.mdx
index 3a300a85..10f9365d 100644
--- a/versions/8.5.1/remote/caching.mdx
+++ b/versions/8.5.1/remote/caching.mdx
@@ -126,7 +126,7 @@ not provide technical support for bazel-remote.
 
 This cache stores contents on disk and also provides garbage collection
 to enforce an upper storage limit and clean unused artifacts. The cache is
-available as a [docker image] and its code is available on
+available as a [docker image](https://hub.docker.com/r/buchgr/bazel-remote-cache/) and its code is available on
 [GitHub](https://github.com/buchgr/bazel-remote/).
 Both the REST and gRPC remote cache APIs are supported.
 
@@ -308,8 +308,7 @@ or for the age of individual cache entries. Bazel will automatically garbage
 collect the disk cache while idling between builds; the idle timer can be set
 with `--experimental_disk_cache_gc_idle_delay` (defaulting to 5 minutes).
 
-As an alternative to automatic garbage collection, we also provide a [tool](
-https://github.com/bazelbuild/bazel/tree/master/src/tools/diskcache) to run a
+As an alternative to automatic garbage collection, we also provide a [tool](https://github.com/bazelbuild/bazel/tree/master/src/tools/diskcache) to run a
 garbage collection on demand.
 
 ## Known issues {#known-issues}
diff --git a/versions/8.5.1/remote/dynamic.mdx b/versions/8.5.1/remote/dynamic.mdx
index 1effcc66..ffd9503f 100644
--- a/versions/8.5.1/remote/dynamic.mdx
+++ b/versions/8.5.1/remote/dynamic.mdx
@@ -12,8 +12,7 @@ alike.
 This page describes how to enable, tune, and debug dynamic execution. If you
 have both local and remote execution set up and are trying to adjust Bazel
 settings for better performance, this page is for you. If you don't already have
-remote execution set up, go to the Bazel [Remote Execution
-Overview](/versions/8.5.1/remote/rbe) first.
+remote execution set up, go to the Bazel [Remote Execution Overview](/versions/8.5.1/remote/rbe) first.
 
 ## Enabling dynamic execution? {#enabling-dynamic-execution}
 
@@ -44,14 +43,12 @@ are likely. The default value is 1000ms, but should be tuned to being just a bit
 longer than cache hits usually take. The actual time depends both on the remote
 system and on how long a round-trip takes. Usually, the value will be the same
 for all users of a given remote system, unless some of them are far enough away
-to add roundtrip latency. You can use the [Bazel profiling
-features](/versions/8.5.1/rules/performance#performance-profiling) to look at how long typical
+to add roundtrip latency. You can use the [Bazel profiling features](/versions/8.5.1/rules/performance#performance-profiling) to look at how long typical
 cache hits take.
 
 Dynamic execution can be used with local sandboxed strategy as well as with
 [persistent workers](/versions/8.5.1/remote/persistent). Persistent workers will automatically
-run with sandboxing when used with dynamic execution, and cannot use [multiplex
-workers](/versions/8.5.1/remote/multiplex). On Darwin and Windows systems, the sandboxed
+run with sandboxing when used with dynamic execution, and cannot use [multiplex workers](/versions/8.5.1/remote/multiplex). On Darwin and Windows systems, the sandboxed
 strategy can be slow; you can pass `--reuse_sandbox_directories` to reduce
 overhead of creating sandboxes on these systems.
 
@@ -67,8 +64,7 @@ entire action fails. This is an intentional choice to prevent differences
 between local and remote execution from going unnoticed.
 
 For more background on how dynamic execution and its locking works, see Julio
-Merino's excellent [blog
-posts](https://jmmv.dev/series/bazel-dynamic-execution/)
+Merino's excellent [blog posts](https://jmmv.dev/series/bazel-dynamic-execution/)
 
 ## When should I use dynamic execution? {#when-to-use}
 
diff --git a/versions/8.5.1/remote/output-directories.mdx b/versions/8.5.1/remote/output-directories.mdx
index 6d6612e7..4b5893dd 100644
--- a/versions/8.5.1/remote/output-directories.mdx
+++ b/versions/8.5.1/remote/output-directories.mdx
@@ -25,7 +25,7 @@ The solution that's currently implemented:
 
 * Bazel must be invoked from a directory containing a repo boundary file, or a
   subdirectory thereof. In other words, Bazel must be invoked from inside a
-  [repository](../external/overview#repository). Otherwise, an error is
+  [repository](/versions/8.5.1/external/overview#repository). Otherwise, an error is
   reported.
 * The _outputRoot_ directory defaults to `~/.cache/bazel` on Linux,
   `/private/var/tmp` on macOS, and on Windows it defaults to `%HOME%` if
diff --git a/versions/8.5.1/remote/persistent.mdx b/versions/8.5.1/remote/persistent.mdx
index 00024069..e2282cb5 100644
--- a/versions/8.5.1/remote/persistent.mdx
+++ b/versions/8.5.1/remote/persistent.mdx
@@ -257,7 +257,6 @@ For more information on persistent workers, see:
 *   [Original persistent workers blog post](https://blog.bazel.build/2015/12/10/java-workers.html)
 *   [Haskell implementation description](https://www.tweag.io/blog/2019-09-25-bazel-ghc-persistent-worker-internship/)
 *   [Blog post by Mike Morearty](https://medium.com/@mmorearty/how-to-create-a-persistent-worker-for-bazel-7738bba2cabb)
-*   [Front End Development with Bazel: Angular/TypeScript and Persistent Workers
-    w/ Asana](https://www.youtube.com/watch?v=0pgERydGyqo)
+*   [Front End Development with Bazel: Angular/TypeScript and Persistent Workers w/ Asana](https://www.youtube.com/watch?v=0pgERydGyqo)
 *   [Bazel strategies explained](https://jmmv.dev/2019/12/bazel-strategies.html)
 *   [Informative worker strategy discussion on the bazel-discuss mailing list](https://groups.google.com/forum/#!msg/bazel-discuss/oAEnuhYOPm8/ol7hf4KWJgAJ)
diff --git a/versions/8.5.1/remote/rules.mdx b/versions/8.5.1/remote/rules.mdx
index 239ecfcd..081fd75c 100644
--- a/versions/8.5.1/remote/rules.mdx
+++ b/versions/8.5.1/remote/rules.mdx
@@ -54,8 +54,7 @@ variables that may not be set to equivalent values (or at all) in the remote
 execution environment.
 
 Toolchain rules currently exist for Bazel build and test rules for
-[Scala](https://github.com/bazelbuild/rules_scala/blob/master/scala/scala_toolch
-ain.bzl),
+[Scala](https://github.com/bazelbuild/rules_scala/blob/master/scala/scala_toolch ain.bzl),
 [Rust](https://github.com/bazelbuild/rules_rust/blob/main/rust/toolchain.bzl),
 and [Go](https://github.com/bazelbuild/rules_go/blob/master/go/toolchains.rst),
 and new toolchain rules are under way for other languages and tools such as
diff --git a/versions/8.5.1/remote/workspace.mdx b/versions/8.5.1/remote/workspace.mdx
index ae1d1633..38401b77 100644
--- a/versions/8.5.1/remote/workspace.mdx
+++ b/versions/8.5.1/remote/workspace.mdx
@@ -11,8 +11,7 @@ on the host machine. If your workspace rules access information about the
 host machine for use during execution, your build is likely to break due to
 incompatibilities between the environments.
 
-As part of [adapting Bazel rules for remote
-execution](/versions/8.5.1/remote/rules), you need to find such workspace rules
+As part of [adapting Bazel rules for remote execution](/versions/8.5.1/remote/rules), you need to find such workspace rules
 and fix them. This page describes how to find potentially problematic workspace
 rules using the workspace log.
 
diff --git a/versions/8.5.1/rules/challenges.mdx b/versions/8.5.1/rules/challenges.mdx
index 5d493ef4..52cec9ce 100644
--- a/versions/8.5.1/rules/challenges.mdx
+++ b/versions/8.5.1/rules/challenges.mdx
@@ -208,7 +208,7 @@ Bazel is heavily affected by both of these scenarios, so we introduced a set of
 custom collection classes that effectively compress the information in memory by
 avoiding the copy at each step. Almost all of these data structures have set
 semantics, so we called it
-[depset](/versions/8.5.1/rules/lib/depset)
+[depset](/versions/8.5.1/rules/lib/builtins/depset)
 (also known as `NestedSet` in the internal implementation). The majority of
 changes to reduce Bazel's memory consumption over the past several years were
 changes to use depsets instead of whatever was previously used.
diff --git a/versions/8.5.1/rules/faq.mdx b/versions/8.5.1/rules/faq.mdx
index e6970c80..f9c9fc43 100644
--- a/versions/8.5.1/rules/faq.mdx
+++ b/versions/8.5.1/rules/faq.mdx
@@ -17,7 +17,7 @@ Bazel only executes the actions needed to produce the *requested* output files.
 
 * If you want the file to be built automatically whenever your target is
   mentioned on the command line, add it to your rule's default outputs by
-  returning a [`DefaultInfo`](lib/globals#DefaultInfo) provider.
+  returning a [`DefaultInfo`](/versions/8.5.1/rules/lib/globals#DefaultInfo) provider.
 
 See the [Rules page](/versions/8.5.1/extending/rules#requesting-output-files) for more information.
 
@@ -35,24 +35,24 @@ correct path.
 
 For actions, you declare inputs by passing them to the `ctx.actions.*` function
 that creates the action. The proper path for the file can be obtained using
-[`File.path`](lib/File#path).
+[`File.path`](/versions/8.5.1/rules/lib/builtins/File#path).
 
 For binaries (the executable outputs run by a `bazel run` or `bazel test`
 command), you declare inputs by including them in the
 [runfiles](/versions/8.5.1/extending/rules#runfiles). Instead of using the `path` field, use
-[`File.short_path`](lib/File#short_path), which is file's path relative to
+[`File.short_path`](/versions/8.5.1/rules/lib/builtins/File#short_path), which is file's path relative to
 the runfiles directory in which the binary executes.
 
 ## How can I control which files are built by `bazel build //pkg:mytarget`?
 
-Use the [`DefaultInfo`](lib/globals#DefaultInfo) provider to
+Use the [`DefaultInfo`](/versions/8.5.1/rules/lib/globals#DefaultInfo) provider to
 [set the default outputs](/versions/8.5.1/extending/rules#requesting-output-files).
 
 ## How can I run a program or do file I/O as part of my build?
 
 A tool can be declared as a target, just like any other part of your build, and
 run during the execution phase to help build other targets. To create an action
-that runs a tool, use [`ctx.actions.run`](lib/actions#run) and pass in the
+that runs a tool, use [`ctx.actions.run`](/versions/8.5.1/rules/lib/builtins/actions#run) and pass in the
 tool as the `executable` parameter.
 
 During the loading and analysis phases, a tool *cannot* run, nor can you perform
diff --git a/versions/8.5.1/rules/language.mdx b/versions/8.5.1/rules/language.mdx
index f267ce5d..8ea61e88 100644
--- a/versions/8.5.1/rules/language.mdx
+++ b/versions/8.5.1/rules/language.mdx
@@ -34,19 +34,19 @@ Starlark's semantics can differ from Python, but behavioral differences are
 rare, except for cases where Starlark raises an error. The following Python
 types are supported:
 
-* [None](lib/globals#None)
-* [bool](lib/bool)
-* [dict](lib/dict)
-* [tuple](lib/tuple)
-* [function](lib/function)
-* [int](lib/int)
-* [list](lib/list)
-* [string](lib/string)
+* [None](/versions/8.5.1/rules/lib/globals#None)
+* [bool](/versions/8.5.1/rules/lib/core/bool)
+* [dict](/versions/8.5.1/rules/lib/core/dict)
+* [tuple](/versions/8.5.1/rules/lib/core/tuple)
+* [function](/versions/8.5.1/rules/lib/core/function)
+* [int](/versions/8.5.1/rules/lib/core/int)
+* [list](/versions/8.5.1/rules/lib/core/list)
+* [string](/versions/8.5.1/rules/lib/core/string)
 
 ## Mutability
 
 Starlark favors immutability. Two mutable data structures are available:
-[lists](lib/list) and [dicts](lib/dict). Changes to mutable
+[lists](/versions/8.5.1/rules/lib/core/list) and [dicts](/versions/8.5.1/rules/lib/core/dict). Changes to mutable
 data-structures, such as appending a value to a list or deleting an entry in a
 dictionary are valid only for objects created in the current context. After a
 context finishes, its values become immutable.
@@ -93,10 +93,8 @@ values returned by rules are immutable.
 `BUILD` files register targets via making calls to rules. `.bzl` files provide
 definitions for constants, rules, macros, and functions.
 
-[Native functions](/versions/8.5.1/reference/be/functions) and [native rules](
-/reference/be/overview#language-specific-native-rules) are global symbols in
-`BUILD` files. `bzl` files need to load them using the [`native` module](
-/rules/lib/toplevel/native).
+[Native functions](/versions/8.5.1/reference/be/functions) and [native rules](/versions/8.5.1/reference/be/overview#language-specific-native-rules) are global symbols in
+`BUILD` files. `bzl` files need to load them using the [`native` module](/versions/8.5.1/rules/lib/toplevel/native).
 
 There are two syntactic restrictions in `BUILD` files: 1) declaring functions is
 illegal, and 2) `*args` and `**kwargs` arguments are not allowed.
@@ -130,7 +128,7 @@ not defined across value types. In short: `5 < 'foo'` will throw an error and
   error: `{"a": 4, "b": 7, "a": 1}`.
 
 * Strings are represented with double-quotes (such as when you call
-  [repr](lib/globals#repr)).
+  [repr](/versions/8.5.1/rules/lib/globals#repr)).
 
 * Strings aren't iterable.
 
@@ -138,12 +136,12 @@ The following Python features are not supported:
 
 * implicit string concatenation (use explicit `+` operator).
 * Chained comparisons (such as `1 < x < 5`).
-* `class` (see [`struct`](lib/struct#struct) function).
+* `class` (see [`struct`](/versions/8.5.1/rules/lib/builtins/struct#struct) function).
 * `import` (see [`load`](/versions/8.5.1/extending/concepts#loading-an-extension) statement).
 * `while`, `yield`.
 * float and set types.
 * generators and generator expressions.
 * `is` (use `==` instead).
-* `try`, `raise`, `except`, `finally` (see [`fail`](lib/globals#fail) for fatal errors).
+* `try`, `raise`, `except`, `finally` (see [`fail`](/versions/8.5.1/rules/lib/globals#fail) for fatal errors).
 * `global`, `nonlocal`.
 * most builtin functions, most methods.
diff --git a/versions/8.5.1/rules/legacy-macro-tutorial.mdx b/versions/8.5.1/rules/legacy-macro-tutorial.mdx
index 67e7944f..3f2c7cf8 100644
--- a/versions/8.5.1/rules/legacy-macro-tutorial.mdx
+++ b/versions/8.5.1/rules/legacy-macro-tutorial.mdx
@@ -3,9 +3,7 @@ title: 'Creating a Legacy Macro'
 ---
 
 IMPORTANT: This tutorial is for [*legacy macros*](/versions/8.5.1/extending/legacy-macros). If
-you only need to support Bazel 8 or newer, we recommend using [symbolic
-macros](/versions/8.5.1/extending/macros) instead; take a look at [Creating a Symbolic
-Macro](../macro-tutorial).
+you only need to support Bazel 8 or newer, we recommend using [symbolic macros](/versions/8.5.1/extending/macros) instead; take a look at [Creating a Symbolic Macro](/versions/8.5.1/rules/macro-tutorial).
 
 Imagine that you need to run a tool as part of your build. For example, you
 may want to generate or preprocess a source file, or compress a binary. In this
diff --git a/versions/8.5.1/rules/lib/builtins/Action.mdx b/versions/8.5.1/rules/lib/builtins/Action.mdx
index bbb30900..50272b65 100644
--- a/versions/8.5.1/rules/lib/builtins/Action.mdx
+++ b/versions/8.5.1/rules/lib/builtins/Action.mdx
@@ -4,7 +4,7 @@ title: 'Action'
 
 An action created during rule analysis.
 
-This object is visible for the purpose of testing, and may be obtained from an `Actions` provider. It is normally not necessary to access `Action` objects or their fields within a rule's implementation function. You may instead want to see the [Rules page](https://bazel.build/versions/8.5.1/extending/rules#actions) for a general discussion of how to use actions when defining custom rules, or the [API reference](../builtins/actions) for creating actions.
+This object is visible for the purpose of testing, and may be obtained from an `Actions` provider. It is normally not necessary to access `Action` objects or their fields within a rule's implementation function. You may instead want to see the [Rules page](https://bazel.build/versions/8.5.1/extending/rules#actions) for a general discussion of how to use actions when defining custom rules, or the [API reference](/versions/8.5.1/rules/lib/builtins/actions) for creating actions.
 
 Some fields of this object are only applicable for certain kinds of actions. Fields that are inapplicable are set to `None`.
 
@@ -25,7 +25,7 @@ Some fields of this object are only applicable for certain kinds of actions. Fie
 sequence Action.args
 ```
 
-A list of frozen [Args](../builtins/Args) objects containing information about the action arguments. These objects contain accurate argument information, including arguments involving expanded action output directories. However, [Args](../builtins/Args) objects are not readable in the analysis phase. For a less accurate account of arguments which is available in the analysis phase, see [argv](#argv).
+A list of frozen [Args](/versions/8.5.1/rules/lib/builtins/Args) objects containing information about the action arguments. These objects contain accurate argument information, including arguments involving expanded action output directories. However, [Args](/versions/8.5.1/rules/lib/builtins/Args) objects are not readable in the analysis phase. For a less accurate account of arguments which is available in the analysis phase, see [argv](#argv).
 
 Note that some types of actions do not yet support exposure of this field. For such action types, this is `None`.
 May return `None`.
@@ -36,7 +36,7 @@ May return `None`.
 sequence Action.argv
 ```
 
-For actions created by [ctx.actions.run()](../builtins/actions#run) or [ctx.actions.run\_shell()](../builtins/actions#run_shell) an immutable list of the arguments for the command line to be executed. Note that for shell actions the first two arguments will be the shell path and `"-c"`.
+For actions created by [ctx.actions.run()](/versions/8.5.1/rules/lib/builtins/actions#run) or [ctx.actions.run\_shell()](/versions/8.5.1/rules/lib/builtins/actions#run_shell) an immutable list of the arguments for the command line to be executed. Note that for shell actions the first two arguments will be the shell path and `"-c"`.
 May return `None`.
 
 ## content
@@ -45,7 +45,7 @@ May return `None`.
 string Action.content
 ```
 
-For actions created by [ctx.actions.write()](../builtins/actions#write) or [ctx.actions.expand\_template()](../builtins/actions#expand_template), the contents of the file to be written, if those contents can be computed during the analysis phase. The value is `None` if the contents cannot be determined until the execution phase, such as when a directory in an [Args](../builtins/Args) object needs to be expanded.
+For actions created by [ctx.actions.write()](/versions/8.5.1/rules/lib/builtins/actions#write) or [ctx.actions.expand\_template()](/versions/8.5.1/rules/lib/builtins/actions#expand_template), the contents of the file to be written, if those contents can be computed during the analysis phase. The value is `None` if the contents cannot be determined until the execution phase, such as when a directory in an [Args](/versions/8.5.1/rules/lib/builtins/Args) object needs to be expanded.
 May return `None`.
 
 ## env
@@ -86,5 +86,5 @@ A set of the output files of this action.
 dict Action.substitutions
 ```
 
-For actions created by [ctx.actions.expand\_template()](../builtins/actions#expand_template), an immutable dict holding the substitution mapping.
+For actions created by [ctx.actions.expand\_template()](/versions/8.5.1/rules/lib/builtins/actions#expand_template), an immutable dict holding the substitution mapping.
 May return `None`.
\ No newline at end of file
diff --git a/versions/8.5.1/rules/lib/builtins/Args.mdx b/versions/8.5.1/rules/lib/builtins/Args.mdx
index 20f430d6..40006578 100644
--- a/versions/8.5.1/rules/lib/builtins/Args.mdx
+++ b/versions/8.5.1/rules/lib/builtins/Args.mdx
@@ -4,15 +4,15 @@ title: 'Args'
 
 An object that encapsulates, in a memory-efficient way, the data needed to build part or all of a command line.
 
-It often happens that an action requires a large command line containing values accumulated from transitive dependencies. For example, a linker command line might list every object file needed by all of the libraries being linked. It is best practice to store such transitive data in [`depset`](../builtins/depset)s, so that they can be shared by multiple targets. However, if the rule author had to convert these depsets into lists of strings in order to construct an action command line, it would defeat this memory-sharing optimization.
+It often happens that an action requires a large command line containing values accumulated from transitive dependencies. For example, a linker command line might list every object file needed by all of the libraries being linked. It is best practice to store such transitive data in [`depset`](/versions/8.5.1/rules/lib/builtins/depset)s, so that they can be shared by multiple targets. However, if the rule author had to convert these depsets into lists of strings in order to construct an action command line, it would defeat this memory-sharing optimization.
 
 For this reason, the action-constructing functions accept `Args` objects in addition to strings. Each `Args` object represents a concatenation of strings and depsets, with optional transformations for manipulating the data. `Args` objects do not process the depsets they encapsulate until the execution phase, when it comes time to calculate the command line. This helps defer any expensive copying until after the analysis phase is complete. See the [Optimizing Performance](https://bazel.build/versions/8.5.1/rules/performance) page for more information.
 
-`Args` are constructed by calling [`ctx.actions.args()`](../builtins/actions#args). They can be passed as the `arguments` parameter of [`ctx.actions.run()`](../builtins/actions#run) or [`ctx.actions.run_shell()`](../builtins/actions#run_shell). Each mutation of an `Args` object appends values to the eventual command line.
+`Args` are constructed by calling [`ctx.actions.args()`](/versions/8.5.1/rules/lib/builtins/actions#args). They can be passed as the `arguments` parameter of [`ctx.actions.run()`](/versions/8.5.1/rules/lib/builtins/actions#run) or [`ctx.actions.run_shell()`](/versions/8.5.1/rules/lib/builtins/actions#run_shell). Each mutation of an `Args` object appends values to the eventual command line.
 
 The `map_each` feature allows you to customize how items are transformed into strings. If you do not provide a `map_each` function, the standard conversion is as follows:
 
-* Values that are already strings are left as-is.* [`File`](../builtins/File) objects are turned into their `File.path` values.* [`Label`](../builtins/Label) objects are turned into a string representation that resolves back to the same object when resolved in the context of the main repository. If possible, the string representation uses the apparent name of a repository in favor of the repository's canonical name, which makes this representation suited for use in BUILD files. While the exact form of the representation is not guaranteed, typical examples are `//foo:bar`, `@repo//foo:bar` and `@@canonical_name+//foo:bar.bzl`.* All other types are turned into strings in an *unspecified* manner. For this reason, you should avoid passing values that are not of string or `File` type to `add()`, and if you pass them to `add_all()` or `add_joined()` then you should provide a `map_each` function.
+* Values that are already strings are left as-is.* [`File`](/versions/8.5.1/rules/lib/builtins/File) objects are turned into their `File.path` values.* [`Label`](/versions/8.5.1/rules/lib/builtins/Label) objects are turned into a string representation that resolves back to the same object when resolved in the context of the main repository. If possible, the string representation uses the apparent name of a repository in favor of the repository's canonical name, which makes this representation suited for use in BUILD files. While the exact form of the representation is not guaranteed, typical examples are `//foo:bar`, `@repo//foo:bar` and `@@canonical_name+//foo:bar.bzl`.* All other types are turned into strings in an *unspecified* manner. For this reason, you should avoid passing values that are not of string or `File` type to `add()`, and if you pass them to `add_all()` or `add_joined()` then you should provide a `map_each` function.
 
 When using string formatting (`format`, `format_each`, and `format_joined` params of the `add*()` methods), the format template is interpreted in the same way as `%`-substitution on strings, except that the template must have exactly one substitution placeholder and it must be `%s`. Literal percents may be escaped as `%%`. Formatting is applied after the value is converted to a string as per the above.
 
@@ -64,7 +64,7 @@ Appends an argument to this command line.
 | --- | --- |
 | `arg_name_or_value` | required  If two positional parameters are passed this is interpreted as the arg name. The arg name is added before the value without any processing. If only one positional parameter is passed, it is interpreted as `value` (see below). |
 | `value` | default is `unbound`  The object to append. It will be converted to a string using the standard conversion mentioned above. Since there is no `map_each` parameter for this function, `value` should be either a string or a `File`. A list, tuple, depset, or directory `File` must be passed to [`add_all()` or [`add_joined()`](#add_joined) instead of this method.](#add_all) |
-| `format` | [string](../core/string); or `None`; default is `None`  A format string pattern, to be applied to the stringified version of `value`. |
+| `format` | [string](/versions/8.5.1/rules/lib/core/string); or `None`; default is `None`  A format string pattern, to be applied to the stringified version of `value`. |
 
 ## add\_all
 
@@ -86,15 +86,15 @@ Note that empty strings are valid arguments that are subject to all these proces
 | Parameter | Description |
 | --- | --- |
 | `arg_name_or_values` | required  If two positional parameters are passed this is interpreted as the arg name. The arg name is added before the `values` as a separate argument without any processing. This arg name will not be added if `omit_if_empty` is true (the default) and no other items are appended (as happens if `values` is empty or all of its items are filtered). If only one positional parameter is passed, it is interpreted as `values` (see below). |
-| `values` | [sequence](../core/list); or [depset](../builtins/depset); default is `unbound`  The list, tuple, or depset whose items will be appended. |
-| `map_each` | callable; or `None`; default is `None`  A function that converts each item to zero or more strings, which may be further processed before appending. If this param is not provided, the standard conversion is used. The function is passed either one or two positional arguments: the item to convert, followed by an optional [`DirectoryExpander`](../builtins/DirectoryExpander). The second argument will be passed only if the supplied function is user-defined (not built-in) and declares more than one parameter. The return value's type depends on how many arguments are to be produced for the item:  * In the common case when each item turns into one string, the function should return that string.* If the item is to be filtered out entirely, the function should return `None`.* If the item turns into multiple strings, the function returns a list of those strings.  Returning a single string or `None` has the same effect as returning a list of length 1 or length 0 respectively. However, it is more efficient and readable to avoid creating a list where it is not needed. Ordinarily, items that are directories are automatically expanded to their contents when `expand_directories=True` is set. However, this will not expand directories contained inside other values -- for instance, when the items are structs that have directories as fields. In this situation, the `DirectoryExpander` argument can be applied to manually obtain the files of a given directory. To avoid unintended retention of large analysis-phase data structures into the execution phase, the `map_each` function must be declared by a top-level `def` statement; it may not be a nested function closure by default. *Warning:* [`print()`](../globals/all#print) statements that are executed during the call to `map_each` will not produce any visible output. |
-| `format_each` | [string](../core/string); or `None`; default is `None`  An optional format string pattern, applied to each string returned by the `map_each` function. The format string must have exactly one '%s' placeholder. |
-| `before_each` | [string](../core/string); or `None`; default is `None`  An optional argument to append before each argument derived from `values` is appended. |
-| `omit_if_empty` | [bool](../core/bool); default is `True`  If true, if there are no arguments derived from `values` to be appended, then all further processing is suppressed and the command line will be unchanged. If false, the arg name and `terminate_with`, if provided, will still be appended regardless of whether or not there are other arguments. |
-| `uniquify` | [bool](../core/bool); default is `False`  If true, duplicate arguments that are derived from `values` will be omitted. Only the first occurrence of each argument will remain. Usually this feature is not needed because depsets already omit duplicates, but it can be useful if `map_each` emits the same string for multiple items. |
-| `expand_directories` | [bool](../core/bool); default is `True`  If true, any directories in `values` will be expanded to a flat list of files. This happens before `map_each` is applied. |
-| `terminate_with` | [string](../core/string); or `None`; default is `None`  An optional argument to append after all other arguments. This argument will not be added if `omit_if_empty` is true (the default) and no other items are appended (as happens if `values` is empty or all of its items are filtered). |
-| `allow_closure` | [bool](../core/bool); default is `False`  If true, allows the use of closures in function parameters like `map_each`. Usually this isn't necessary and it risks retaining large analysis-phase data structures into the execution phase. |
+| `values` | [sequence](/versions/8.5.1/rules/lib/core/list); or [depset](/versions/8.5.1/rules/lib/builtins/depset); default is `unbound`  The list, tuple, or depset whose items will be appended. |
+| `map_each` | callable; or `None`; default is `None`  A function that converts each item to zero or more strings, which may be further processed before appending. If this param is not provided, the standard conversion is used. The function is passed either one or two positional arguments: the item to convert, followed by an optional [`DirectoryExpander`](/versions/8.5.1/rules/lib/builtins/DirectoryExpander). The second argument will be passed only if the supplied function is user-defined (not built-in) and declares more than one parameter. The return value's type depends on how many arguments are to be produced for the item:  * In the common case when each item turns into one string, the function should return that string.* If the item is to be filtered out entirely, the function should return `None`.* If the item turns into multiple strings, the function returns a list of those strings.  Returning a single string or `None` has the same effect as returning a list of length 1 or length 0 respectively. However, it is more efficient and readable to avoid creating a list where it is not needed. Ordinarily, items that are directories are automatically expanded to their contents when `expand_directories=True` is set. However, this will not expand directories contained inside other values -- for instance, when the items are structs that have directories as fields. In this situation, the `DirectoryExpander` argument can be applied to manually obtain the files of a given directory. To avoid unintended retention of large analysis-phase data structures into the execution phase, the `map_each` function must be declared by a top-level `def` statement; it may not be a nested function closure by default. *Warning:* [`print()`](/versions/8.5.1/rules/lib/globals/all#print) statements that are executed during the call to `map_each` will not produce any visible output. |
+| `format_each` | [string](/versions/8.5.1/rules/lib/core/string); or `None`; default is `None`  An optional format string pattern, applied to each string returned by the `map_each` function. The format string must have exactly one '%s' placeholder. |
+| `before_each` | [string](/versions/8.5.1/rules/lib/core/string); or `None`; default is `None`  An optional argument to append before each argument derived from `values` is appended. |
+| `omit_if_empty` | [bool](/versions/8.5.1/rules/lib/core/bool); default is `True`  If true, if there are no arguments derived from `values` to be appended, then all further processing is suppressed and the command line will be unchanged. If false, the arg name and `terminate_with`, if provided, will still be appended regardless of whether or not there are other arguments. |
+| `uniquify` | [bool](/versions/8.5.1/rules/lib/core/bool); default is `False`  If true, duplicate arguments that are derived from `values` will be omitted. Only the first occurrence of each argument will remain. Usually this feature is not needed because depsets already omit duplicates, but it can be useful if `map_each` emits the same string for multiple items. |
+| `expand_directories` | [bool](/versions/8.5.1/rules/lib/core/bool); default is `True`  If true, any directories in `values` will be expanded to a flat list of files. This happens before `map_each` is applied. |
+| `terminate_with` | [string](/versions/8.5.1/rules/lib/core/string); or `None`; default is `None`  An optional argument to append after all other arguments. This argument will not be added if `omit_if_empty` is true (the default) and no other items are appended (as happens if `values` is empty or all of its items are filtered). |
+| `allow_closure` | [bool](/versions/8.5.1/rules/lib/core/bool); default is `False`  If true, allows the use of closures in function parameters like `map_each`. Usually this isn't necessary and it risks retaining large analysis-phase data structures into the execution phase. |
 
 ## add\_joined
 
@@ -113,15 +113,15 @@ If after filtering there are no strings to join into an argument, and if `omit_i
 | Parameter | Description |
 | --- | --- |
 | `arg_name_or_values` | required  If two positional parameters are passed this is interpreted as the arg name. The arg name is added before `values` without any processing. This arg will not be added if `omit_if_empty` is true (the default) and there are no strings derived from `values` to join together (which can happen if `values` is empty or all of its items are filtered). If only one positional parameter is passed, it is interpreted as `values` (see below). |
-| `values` | [sequence](../core/list); or [depset](../builtins/depset); default is `unbound`  The list, tuple, or depset whose items will be joined. |
-| `join_with` | [string](../core/string); required  A delimiter string used to join together the strings obtained from applying `map_each` and `format_each`, in the same manner as [`string.join()`](../core/string#join). |
+| `values` | [sequence](/versions/8.5.1/rules/lib/core/list); or [depset](/versions/8.5.1/rules/lib/builtins/depset); default is `unbound`  The list, tuple, or depset whose items will be joined. |
+| `join_with` | [string](/versions/8.5.1/rules/lib/core/string); required  A delimiter string used to join together the strings obtained from applying `map_each` and `format_each`, in the same manner as [`string.join()`](/versions/8.5.1/rules/lib/core/string#join). |
 | `map_each` | callable; or `None`; default is `None`  Same as for [`add_all`](#add_all.map_each). |
-| `format_each` | [string](../core/string); or `None`; default is `None`  Same as for [`add_all`](#add_all.format_each). |
-| `format_joined` | [string](../core/string); or `None`; default is `None`  An optional format string pattern applied to the joined string. The format string must have exactly one '%s' placeholder. |
-| `omit_if_empty` | [bool](../core/bool); default is `True`  If true, if there are no strings to join together (either because `values` is empty or all its items are filtered), then all further processing is suppressed and the command line will be unchanged. If false, then even if there are no strings to join together, two arguments will be appended: the arg name followed by an empty string (which is the logical join of zero strings). |
-| `uniquify` | [bool](../core/bool); default is `False`  Same as for [`add_all`](#add_all.uniquify). |
-| `expand_directories` | [bool](../core/bool); default is `True`  Same as for [`add_all`](#add_all.expand_directories). |
-| `allow_closure` | [bool](../core/bool); default is `False`  Same as for [`add_all`](#add_all.allow_closure). |
+| `format_each` | [string](/versions/8.5.1/rules/lib/core/string); or `None`; default is `None`  Same as for [`add_all`](#add_all.format_each). |
+| `format_joined` | [string](/versions/8.5.1/rules/lib/core/string); or `None`; default is `None`  An optional format string pattern applied to the joined string. The format string must have exactly one '%s' placeholder. |
+| `omit_if_empty` | [bool](/versions/8.5.1/rules/lib/core/bool); default is `True`  If true, if there are no strings to join together (either because `values` is empty or all its items are filtered), then all further processing is suppressed and the command line will be unchanged. If false, then even if there are no strings to join together, two arguments will be appended: the arg name followed by an empty string (which is the logical join of zero strings). |
+| `uniquify` | [bool](/versions/8.5.1/rules/lib/core/bool); default is `False`  Same as for [`add_all`](#add_all.uniquify). |
+| `expand_directories` | [bool](/versions/8.5.1/rules/lib/core/bool); default is `True`  Same as for [`add_all`](#add_all.expand_directories). |
+| `allow_closure` | [bool](/versions/8.5.1/rules/lib/core/bool); default is `False`  Same as for [`add_all`](#add_all.allow_closure). |
 
 ## set\_param\_file\_format
 
@@ -135,7 +135,7 @@ Sets the format of the param file, if one is used
 
 | Parameter | Description |
 | --- | --- |
-| `format` | [string](../core/string); required  Must be one of:  * "multiline": Each item (argument name or value) is written verbatim to the param file with a newline character following it. * "shell": Same as "multiline", but the items are shell-quoted * "flag\_per\_line": Same as "multiline", but (1) only flags (beginning with '--') are written to the param file, and (2) the values of the flags, if any, are written on the same line with a '=' separator. This is the format expected by the Abseil flags library.   The format defaults to "shell" if not called. |
+| `format` | [string](/versions/8.5.1/rules/lib/core/string); required  Must be one of:  * "multiline": Each item (argument name or value) is written verbatim to the param file with a newline character following it. * "shell": Same as "multiline", but the items are shell-quoted * "flag\_per\_line": Same as "multiline", but (1) only flags (beginning with '--') are written to the param file, and (2) the values of the flags, if any, are written on the same line with a '=' separator. This is the format expected by the Abseil flags library.   The format defaults to "shell" if not called. |
 
 ## use\_param\_file
 
@@ -151,5 +151,5 @@ Bazel may choose to elide writing the params file to the output tree during exec
 
 | Parameter | Description |
 | --- | --- |
-| `param_file_arg` | [string](../core/string); required  A format string with a single "%s". If the args are spilled to a params file then they are replaced with an argument consisting of this string formatted with the path of the params file. For example, if the args are spilled to a params file "params.txt", then specifying "--file=%s" would cause the action command line to contain "--file=params.txt". |
-| `use_always` | [bool](../core/bool); default is `False`  Whether to always spill the args to a params file. If false, bazel will decide whether the arguments need to be spilled based on your system and arg length. |
\ No newline at end of file
+| `param_file_arg` | [string](/versions/8.5.1/rules/lib/core/string); required  A format string with a single "%s". If the args are spilled to a params file then they are replaced with an argument consisting of this string formatted with the path of the params file. For example, if the args are spilled to a params file "params.txt", then specifying "--file=%s" would cause the action command line to contain "--file=params.txt". |
+| `use_always` | [bool](/versions/8.5.1/rules/lib/core/bool); default is `False`  Whether to always spill the args to a params file. If false, bazel will decide whether the arguments need to be spilled based on your system and arg length. |
\ No newline at end of file
diff --git a/versions/8.5.1/rules/lib/builtins/Aspect.mdx b/versions/8.5.1/rules/lib/builtins/Aspect.mdx
index 4a20909b..54f1d4c7 100644
--- a/versions/8.5.1/rules/lib/builtins/Aspect.mdx
+++ b/versions/8.5.1/rules/lib/builtins/Aspect.mdx
@@ -3,4 +3,4 @@ title: 'Aspect'
 ---
 
 For more information about Aspects, please consult the
-[documentation of the aspect function](../globals/bzl#aspect) or the [introduction to Aspects](https://bazel.build/versions/8.5.1/rules/aspects).
\ No newline at end of file
+[documentation of the aspect function](/versions/8.5.1/rules/lib/globals/bzl#aspect) or the [introduction to Aspects](https://bazel.build/versions/8.5.1/rules/aspects).
\ No newline at end of file
diff --git a/versions/8.5.1/rules/lib/builtins/Attribute.mdx b/versions/8.5.1/rules/lib/builtins/Attribute.mdx
index 18486c41..57754e9b 100644
--- a/versions/8.5.1/rules/lib/builtins/Attribute.mdx
+++ b/versions/8.5.1/rules/lib/builtins/Attribute.mdx
@@ -2,4 +2,4 @@
 title: 'Attribute'
 ---
 
-Representation of a definition of an attribute. Use the [attr](../toplevel/attr) module to create an Attribute. They are only for use with a [rule](../globals/bzl#rule) or an [aspect](../globals/bzl#aspect).
\ No newline at end of file
+Representation of a definition of an attribute. Use the [attr](/versions/8.5.1/rules/lib/toplevel/attr) module to create an Attribute. They are only for use with a [rule](/versions/8.5.1/rules/lib/globals/bzl#rule) or an [aspect](/versions/8.5.1/rules/lib/globals/bzl#aspect).
\ No newline at end of file
diff --git a/versions/8.5.1/rules/lib/builtins/DirectoryExpander.mdx b/versions/8.5.1/rules/lib/builtins/DirectoryExpander.mdx
index 8bf9ae69..bb498e1f 100644
--- a/versions/8.5.1/rules/lib/builtins/DirectoryExpander.mdx
+++ b/versions/8.5.1/rules/lib/builtins/DirectoryExpander.mdx
@@ -2,7 +2,7 @@
 title: 'DirectoryExpander'
 ---
 
-Expands directories created by [`ctx.actions.declare_directory`](../builtins/actions#declare_directory) during the execution phase. This is useful to expand directories in [`map_each`](../builtins/Args#add_all.map_each).
+Expands directories created by [`ctx.actions.declare_directory`](/versions/8.5.1/rules/lib/builtins/actions#declare_directory) during the execution phase. This is useful to expand directories in [`map_each`](/versions/8.5.1/rules/lib/builtins/Args#add_all.map_each).
 
 ## Members
 
@@ -20,4 +20,4 @@ If the given `File` is a directory, this returns a list of `File`s recursively u
 
 | Parameter | Description |
 | --- | --- |
-| `file` | [File](../builtins/File); required  The directory or file to expand. |
\ No newline at end of file
+| `file` | [File](/versions/8.5.1/rules/lib/builtins/File); required  The directory or file to expand. |
\ No newline at end of file
diff --git a/versions/8.5.1/rules/lib/builtins/DottedVersion.mdx b/versions/8.5.1/rules/lib/builtins/DottedVersion.mdx
index f17cea85..abfecf7b 100644
--- a/versions/8.5.1/rules/lib/builtins/DottedVersion.mdx
+++ b/versions/8.5.1/rules/lib/builtins/DottedVersion.mdx
@@ -20,4 +20,4 @@ Compares based on most significant (first) not-matching version component. So, f
 
 | Parameter | Description |
 | --- | --- |
-| `other` | [DottedVersion](../builtins/DottedVersion); required  The other dotted version. |
\ No newline at end of file
+| `other` | [DottedVersion](/versions/8.5.1/rules/lib/builtins/DottedVersion); required  The other dotted version. |
\ No newline at end of file
diff --git a/versions/8.5.1/rules/lib/builtins/Facts.mdx b/versions/8.5.1/rules/lib/builtins/Facts.mdx
index f88937d4..22e97fab 100644
--- a/versions/8.5.1/rules/lib/builtins/Facts.mdx
+++ b/versions/8.5.1/rules/lib/builtins/Facts.mdx
@@ -24,5 +24,5 @@ Returns the value for `key` if it exists, or `default`.
 
 | Parameter | Description |
 | --- | --- |
-| `key` | [string](../core/string); required  The key to look up. |
+| `key` | [string](/versions/8.5.1/rules/lib/core/string); required  The key to look up. |
 | `default` | default is `None`  The value to return if `key` is not present. |
\ No newline at end of file
diff --git a/versions/8.5.1/rules/lib/builtins/File.mdx b/versions/8.5.1/rules/lib/builtins/File.mdx
index 797412ea..8e781c81 100644
--- a/versions/8.5.1/rules/lib/builtins/File.mdx
+++ b/versions/8.5.1/rules/lib/builtins/File.mdx
@@ -4,7 +4,7 @@ title: 'File'
 
 This object is created during the analysis phase to represent a file or directory that will be read or written during the execution phase. It is not an open file handle, and cannot be used to directly read or write file contents. Rather, you use it to construct the action graph in a rule implementation function by passing it to action-creating functions. See the [Rules page](https://bazel.build/versions/8.5.1/extending/rules#files) for more information.
 
-When a `File` is passed to an [`Args`](../builtins/Args) object without using a `map_each` function, it is converted to a string by taking the value of its `path` field.
+When a `File` is passed to an [`Args`](/versions/8.5.1/rules/lib/builtins/Args) object without using a `map_each` function, it is converted to a string by taking the value of its `path` field.
 
 ## Members
 
@@ -83,7 +83,7 @@ May return `None`.
 string File.path
 ```
 
-The execution path of this file, relative to the workspace's execution directory. It consists of two parts, an optional first part called the *root* (see also the [root](../builtins/root) module), and the second part which is the `short_path`. The root may be empty, which it usually is for non-generated files. For generated files it usually contains a configuration-specific path fragment that encodes things like the target CPU architecture that was used while building said file. Use the `short_path` for the path under which the file is mapped if it's in the runfiles of a binary.
+The execution path of this file, relative to the workspace's execution directory. It consists of two parts, an optional first part called the *root* (see also the [root](/versions/8.5.1/rules/lib/builtins/root) module), and the second part which is the `short_path`. The root may be empty, which it usually is for non-generated files. For generated files it usually contains a configuration-specific path fragment that encodes things like the target CPU architecture that was used while building said file. Use the `short_path` for the path under which the file is mapped if it's in the runfiles of a binary.
 
 ## root
 
@@ -107,4 +107,4 @@ The path of this file relative to its root. This excludes the aforementioned *ro
 string File.tree_relative_path
 ```
 
-The path of this file relative to the root of the ancestor's tree, if the ancestor's [is\_directory](#is_directory) field is true. `tree_relative_path` is only available for expanded files of a directory in an action command, i.e. [Args.add\_all()](../builtins/Args#add_all). For other types of files, it is an error to access this field.
\ No newline at end of file
+The path of this file relative to the root of the ancestor's tree, if the ancestor's [is\_directory](#is_directory) field is true. `tree_relative_path` is only available for expanded files of a directory in an action command, i.e. [Args.add\_all()](/versions/8.5.1/rules/lib/builtins/Args#add_all). For other types of files, it is an error to access this field.
\ No newline at end of file
diff --git a/versions/8.5.1/rules/lib/builtins/Label.mdx b/versions/8.5.1/rules/lib/builtins/Label.mdx
index 380c220f..6c38454b 100644
--- a/versions/8.5.1/rules/lib/builtins/Label.mdx
+++ b/versions/8.5.1/rules/lib/builtins/Label.mdx
@@ -33,7 +33,7 @@ For macros, a related function, `native.package_relative_label()`, converts the
 
 | Parameter | Description |
 | --- | --- |
-| `input` | [string](../core/string); or [Label](../builtins/Label); required  The input label string or Label object. If a Label object is passed, it's returned as is. |
+| `input` | [string](/versions/8.5.1/rules/lib/core/string); or [Label](/versions/8.5.1/rules/lib/builtins/Label); required  The input label string or Label object. If a Label object is passed, it's returned as is. |
 
 ## name
 
@@ -66,7 +66,7 @@ Label Label.relative(relName)
 ```
 
 **Experimental**. This API is experimental and may change at any time. Please do not depend on it. It may be enabled on an experimental basis by setting `--+incompatible_enable_deprecated_label_apis`
-**Deprecated.** This method behaves surprisingly when used with an argument containing an apparent repo name. Prefer [`Label.same_package_label()`](#same_package_label), [`native.package_relative_label()`](../toplevel/native#package_relative_label), or [`Label()`](#Label) instead.
+**Deprecated.** This method behaves surprisingly when used with an argument containing an apparent repo name. Prefer [`Label.same_package_label()`](#same_package_label), [`native.package_relative_label()`](/versions/8.5.1/rules/lib/toplevel/native#package_relative_label), or [`Label()`](#Label) instead.
 
 Resolves a label that is either absolute (starts with `//`) or relative to the current package. If this label is in a remote repository, the argument will be resolved relative to that repository. If the argument contains a repository name, the current label is ignored and the argument is returned as-is, except that the repository name is rewritten if it is in the current repository mapping. Reserved labels will also be returned as-is.
 For example:
@@ -89,7 +89,7 @@ Label("@repo//foo/bar:baz").relative("@other//wiz:quux") == Label("@remapped//wi
 
 | Parameter | Description |
 | --- | --- |
-| `relName` | [string](../core/string); required |
+| `relName` | [string](/versions/8.5.1/rules/lib/core/string); required |
 
 ## repo\_name
 
@@ -115,7 +115,7 @@ Creates a label in the same package as this label with the given target name.
 
 | Parameter | Description |
 | --- | --- |
-| `target_name` | [string](../core/string); required |
+| `target_name` | [string](/versions/8.5.1/rules/lib/core/string); required |
 
 ## workspace\_name
 
diff --git a/versions/8.5.1/rules/lib/builtins/LateBoundDefault.mdx b/versions/8.5.1/rules/lib/builtins/LateBoundDefault.mdx
index edd0010c..f615180b 100644
--- a/versions/8.5.1/rules/lib/builtins/LateBoundDefault.mdx
+++ b/versions/8.5.1/rules/lib/builtins/LateBoundDefault.mdx
@@ -4,4 +4,4 @@ title: 'LateBoundDefault'
 
 Represents a late-bound default attribute value of type 'Label'. The value of a LateBoundDefault is only resolvable in the context of a rule implementation function, and depends on the current build configuration. For example, a LateBoundDefault might represent the Label of the java toolchain in the current build configuration.
 
-See [configuration\_field](../globals/bzl#configuration_field) for example usage.
\ No newline at end of file
+See [configuration\_field](/versions/8.5.1/rules/lib/globals/bzl#configuration_field) for example usage.
\ No newline at end of file
diff --git a/versions/8.5.1/rules/lib/builtins/Provider.mdx b/versions/8.5.1/rules/lib/builtins/Provider.mdx
index 54b9cf36..3dd287a9 100644
--- a/versions/8.5.1/rules/lib/builtins/Provider.mdx
+++ b/versions/8.5.1/rules/lib/builtins/Provider.mdx
@@ -14,7 +14,7 @@ This value has a dual purpose:
   ```
 
   Note: Some providers, defined internally, do not allow instance creation
-* It is a *key* to access a provider instance on a [Target](../builtins/Target)
+* It is a *key* to access a provider instance on a [Target](/versions/8.5.1/rules/lib/builtins/Target)
 
   ```
   DataInfo = provider()
@@ -22,4 +22,4 @@ This value has a dual purpose:
     ... ctx.attr.dep[DataInfo]
   ```
 
-Create a new `Provider` using the [provider](../globals/bzl#provider) function.
\ No newline at end of file
+Create a new `Provider` using the [provider](/versions/8.5.1/rules/lib/globals/bzl#provider) function.
\ No newline at end of file
diff --git a/versions/8.5.1/rules/lib/builtins/TemplateDict.mdx b/versions/8.5.1/rules/lib/builtins/TemplateDict.mdx
index 5f18fd44..741c8c24 100644
--- a/versions/8.5.1/rules/lib/builtins/TemplateDict.mdx
+++ b/versions/8.5.1/rules/lib/builtins/TemplateDict.mdx
@@ -21,8 +21,8 @@ Add a String value
 
 | Parameter | Description |
 | --- | --- |
-| `key` | [string](../core/string); required  A String key |
-| `value` | [string](../core/string); required  A String value |
+| `key` | [string](/versions/8.5.1/rules/lib/core/string); required  A String key |
+| `value` | [string](/versions/8.5.1/rules/lib/core/string); required  A String value |
 
 ## add\_joined
 
@@ -36,10 +36,10 @@ Add depset of values
 
 | Parameter | Description |
 | --- | --- |
-| `key` | [string](../core/string); required  A String key |
-| `values` | [depset](../builtins/depset); required  The depset whose items will be joined. |
-| `join_with` | [string](../core/string); required  A delimiter string used to join together the strings obtained from applying `map_each`, in the same manner as [`string.join()`](../core/string#join). |
+| `key` | [string](/versions/8.5.1/rules/lib/core/string); required  A String key |
+| `values` | [depset](/versions/8.5.1/rules/lib/builtins/depset); required  The depset whose items will be joined. |
+| `join_with` | [string](/versions/8.5.1/rules/lib/core/string); required  A delimiter string used to join together the strings obtained from applying `map_each`, in the same manner as [`string.join()`](/versions/8.5.1/rules/lib/core/string#join). |
 | `map_each` | callable; required  A Starlark function accepting a single argument and returning either a string, `None`, or a list of strings. This function is applied to each item of the depset specified in the `values` parameter |
-| `uniquify` | [bool](../core/bool); default is `False`  If true, duplicate strings derived from `values` will be omitted. Only the first occurrence of each string will remain. Usually this feature is not needed because depsets already omit duplicates, but it can be useful if `map_each` emits the same string for multiple items. |
-| `format_joined` | [string](../core/string); or `None`; default is `None`  An optional format string pattern applied to the joined string. The format string must have exactly one '%s' placeholder. |
-| `allow_closure` | [bool](../core/bool); default is `False`  If true, allows the use of closures in function parameters like `map_each`. Usually this isn't necessary and it risks retaining large analysis-phase data structures into the execution phase. |
\ No newline at end of file
+| `uniquify` | [bool](/versions/8.5.1/rules/lib/core/bool); default is `False`  If true, duplicate strings derived from `values` will be omitted. Only the first occurrence of each string will remain. Usually this feature is not needed because depsets already omit duplicates, but it can be useful if `map_each` emits the same string for multiple items. |
+| `format_joined` | [string](/versions/8.5.1/rules/lib/core/string); or `None`; default is `None`  An optional format string pattern applied to the joined string. The format string must have exactly one '%s' placeholder. |
+| `allow_closure` | [bool](/versions/8.5.1/rules/lib/core/bool); default is `False`  If true, allows the use of closures in function parameters like `map_each`. Usually this isn't necessary and it risks retaining large analysis-phase data structures into the execution phase. |
\ No newline at end of file
diff --git a/versions/8.5.1/rules/lib/builtins/actions.mdx b/versions/8.5.1/rules/lib/builtins/actions.mdx
index c167a6bf..6055fd38 100644
--- a/versions/8.5.1/rules/lib/builtins/actions.mdx
+++ b/versions/8.5.1/rules/lib/builtins/actions.mdx
@@ -2,7 +2,7 @@
 title: 'actions'
 ---
 
-Module providing functions to create actions. Access this module using [`ctx.actions`](../builtins/ctx#actions).
+Module providing functions to create actions. Access this module using [`ctx.actions`](/versions/8.5.1/rules/lib/builtins/ctx#actions).
 
 ## Members
 
@@ -32,14 +32,14 @@ Returns an Args object that can be used to build memory-efficient command lines.
 File actions.declare_directory(filename, *, sibling=None)
 ```
 
-Declares that the rule or aspect creates a directory with the given name, in the current package. You must create an action that generates the directory. The contents of the directory are not directly accessible from Starlark, but can be expanded in an action command with [`Args.add_all()`](../builtins/Args#add_all). Only regular files and directories can be in the expanded contents of a declare\_directory.
+Declares that the rule or aspect creates a directory with the given name, in the current package. You must create an action that generates the directory. The contents of the directory are not directly accessible from Starlark, but can be expanded in an action command with [`Args.add_all()`](/versions/8.5.1/rules/lib/builtins/Args#add_all). Only regular files and directories can be in the expanded contents of a declare\_directory.
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `filename` | [string](../core/string); required  If no 'sibling' provided, path of the new directory, relative to the current package. Otherwise a base name for a file ('sibling' defines a directory). |
-| `sibling` | [File](../builtins/File); or `None`; default is `None`  A file that lives in the same directory as the newly declared directory. The file must be in the current package. |
+| `filename` | [string](/versions/8.5.1/rules/lib/core/string); required  If no 'sibling' provided, path of the new directory, relative to the current package. Otherwise a base name for a file ('sibling' defines a directory). |
+| `sibling` | [File](/versions/8.5.1/rules/lib/builtins/File); or `None`; default is `None`  A file that lives in the same directory as the newly declared directory. The file must be in the current package. |
 
 ## declare\_file
 
@@ -51,14 +51,14 @@ Declares that the rule or aspect creates a file with the given filename. If `sib
 
 Remember that in addition to declaring a file, you must separately create an action that emits the file. Creating that action will require passing the returned `File` object to the action's construction function.
 
-Note that [predeclared output files](https://bazel.build/versions/8.5.1/extending/rules#files) do not need to be (and cannot be) declared using this function. You can obtain their `File` objects from [`ctx.outputs`](../builtins/ctx#outputs) instead. [See example of use](https://github.com/bazelbuild/examples/tree/main/rules/computed_dependencies/hash.bzl).
+Note that [predeclared output files](https://bazel.build/versions/8.5.1/extending/rules#files) do not need to be (and cannot be) declared using this function. You can obtain their `File` objects from [`ctx.outputs`](/versions/8.5.1/rules/lib/builtins/ctx#outputs) instead. [See example of use](https://github.com/bazelbuild/examples/tree/main/rules/computed_dependencies/hash.bzl).
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `filename` | [string](../core/string); required  If no 'sibling' provided, path of the new file, relative to the current package. Otherwise a base name for a file ('sibling' determines a directory). |
-| `sibling` | [File](../builtins/File); or `None`; default is `None`  A file that lives in the same directory as the newly created file. The file must be in the current package. |
+| `filename` | [string](/versions/8.5.1/rules/lib/core/string); required  If no 'sibling' provided, path of the new file, relative to the current package. Otherwise a base name for a file ('sibling' determines a directory). |
+| `sibling` | [File](/versions/8.5.1/rules/lib/builtins/File); or `None`; default is `None`  A file that lives in the same directory as the newly created file. The file must be in the current package. |
 
 ## declare\_symlink
 
@@ -72,8 +72,8 @@ Declares that the rule or aspect creates a symlink with the given name in the cu
 
 | Parameter | Description |
 | --- | --- |
-| `filename` | [string](../core/string); required  If no 'sibling' provided, path of the new symlink, relative to the current package. Otherwise a base name for a file ('sibling' defines a directory). |
-| `sibling` | [File](../builtins/File); or `None`; default is `None`  A file that lives in the same directory as the newly declared symlink. |
+| `filename` | [string](/versions/8.5.1/rules/lib/core/string); required  If no 'sibling' provided, path of the new symlink, relative to the current package. Otherwise a base name for a file ('sibling' defines a directory). |
+| `sibling` | [File](/versions/8.5.1/rules/lib/builtins/File); or `None`; default is `None`  A file that lives in the same directory as the newly declared symlink. |
 
 ## do\_nothing
 
@@ -87,8 +87,8 @@ Creates an empty action that neither executes a command nor produces any output,
 
 | Parameter | Description |
 | --- | --- |
-| `mnemonic` | [string](../core/string); required  A one-word description of the action, for example, CppCompile or GoLink. |
-| `inputs` | [sequence](../core/list) of [File](../builtins/File)s; or [depset](../builtins/depset); default is `[]`  List of the input files of the action. |
+| `mnemonic` | [string](/versions/8.5.1/rules/lib/core/string); required  A one-word description of the action, for example, CppCompile or GoLink. |
+| `inputs` | [sequence](/versions/8.5.1/rules/lib/core/list) of [File](/versions/8.5.1/rules/lib/builtins/File)s; or [depset](/versions/8.5.1/rules/lib/builtins/depset); default is `[]`  List of the input files of the action. |
 
 ## expand\_template
 
@@ -102,11 +102,11 @@ Creates a template expansion action. When the action is executed, it will genera
 
 | Parameter | Description |
 | --- | --- |
-| `template` | [File](../builtins/File); required  The template file, which is a UTF-8 encoded text file. |
-| `output` | [File](../builtins/File); required  The output file, which is a UTF-8 encoded text file. |
-| `substitutions` | [dict](../core/dict); default is `{}`  Substitutions to make when expanding the template. |
-| `is_executable` | [bool](../core/bool); default is `False`  Whether the output file should be executable. |
-| `computed_substitutions` | [TemplateDict](../builtins/TemplateDict); default is `unbound`  Substitutions to make when expanding the template. |
+| `template` | [File](/versions/8.5.1/rules/lib/builtins/File); required  The template file, which is a UTF-8 encoded text file. |
+| `output` | [File](/versions/8.5.1/rules/lib/builtins/File); required  The output file, which is a UTF-8 encoded text file. |
+| `substitutions` | [dict](/versions/8.5.1/rules/lib/core/dict); default is `{}`  Substitutions to make when expanding the template. |
+| `is_executable` | [bool](/versions/8.5.1/rules/lib/core/bool); default is `False`  Whether the output file should be executable. |
+| `computed_substitutions` | [TemplateDict](/versions/8.5.1/rules/lib/builtins/TemplateDict); default is `unbound`  Substitutions to make when expanding the template. |
 
 ## run
 
@@ -120,22 +120,22 @@ Creates an action that runs an executable. [See example of use](https://github.c
 
 | Parameter | Description |
 | --- | --- |
-| `outputs` | [sequence](../core/list) of [File](../builtins/File)s; required  List of the output files of the action. |
-| `inputs` | [sequence](../core/list) of [File](../builtins/File)s; or [depset](../builtins/depset); default is `[]`  List or depset of the input files of the action. |
-| `unused_inputs_list` | [File](../builtins/File); or `None`; default is `None`  File containing list of inputs unused by the action. The content of this file (generally one of the outputs of the action) corresponds to the list of input files that were not used during the whole action execution. Any change in those files must not affect in any way the outputs of the action. |
-| `executable` | [File](../builtins/File); or [string](../core/string); or [FilesToRunProvider](../providers/FilesToRunProvider); required  The executable file to be called by the action. |
-| `tools` | [sequence](../core/list); or [depset](../builtins/depset); default is `unbound`  List or depset of any tools needed by the action. Tools are inputs with additional runfiles that are automatically made available to the action. When a list is provided, it can be a heterogenous collection of Files, FilesToRunProvider instances, or depsets of Files. Files which are directly in the list and come from ctx.executable will have their runfiles automatically added. When a depset is provided, it must contain only Files. In both cases, files within depsets are not cross-referenced with ctx.executable for runfiles. |
-| `arguments` | [sequence](../core/list); default is `[]`  Command line arguments of the action. Must be a list of strings or [`actions.args()`](#args) objects. |
-| `mnemonic` | [string](../core/string); or `None`; default is `None`  A one-word description of the action, for example, CppCompile or GoLink. |
-| `progress_message` | [string](../core/string); or `None`; default is `None`  Progress message to show to the user during the build, for example, "Compiling foo.cc to create foo.o". The message may contain `%{label}`, `%{input}`, or `%{output}` patterns, which are substituted with label string, first input, or output's path, respectively. Prefer to use patterns instead of static strings, because the former are more efficient. |
-| `use_default_shell_env` | [bool](../core/bool); default is `False`  Whether the action should use the default shell environment, which consists of a few OS-dependent variables as well as variables set via [`--action_env`](/versions/8.5.1/reference/command-line-reference#flag--action_env). If both `use_default_shell_env` and `env` are set to `True`, values set in `env` will overwrite the default shell environment if [`--incompatible_merge_fixed_and_default_shell_env`](/versions/8.5.1/reference/command-line-reference#flag--incompatible_merge_fixed_and_default_shell_env) is enabled (default). If the flag is not enabled, `env` is ignored. |
-| `env` | [dict](../core/dict); or `None`; default is `None`  Sets the dictionary of environment variables. If both `use_default_shell_env` and `env` are set to `True`, values set in `env` will overwrite the default shell environment if [`--incompatible_merge_fixed_and_default_shell_env`](/versions/8.5.1/reference/command-line-reference#flag--incompatible_merge_fixed_and_default_shell_env) is enabled (default). If the flag is not enabled, `env` is ignored. |
-| `execution_requirements` | [dict](../core/dict); or `None`; default is `None`  Information for scheduling the action. See [tags](/versions/8.5.1/reference/be/common-definitions#common.tags) for useful keys. |
-| `input_manifests` | [sequence](../core/list); or `None`; default is `None`  Legacy argument. Ignored. |
-| `exec_group` | [string](../core/string); or `None`; default is `None`  Runs the action on the given exec group's execution platform. If none, uses the target's default execution platform. |
-| `shadowed_action` | [Action](../builtins/Action); default is `None`  Runs the action using the given shadowed action's inputs and environment added to the action's inputs list and environment. The action environment can overwrite any of the shadowed action's environment variables. If none, uses only the action's inputs and given environment. |
+| `outputs` | [sequence](/versions/8.5.1/rules/lib/core/list) of [File](/versions/8.5.1/rules/lib/builtins/File)s; required  List of the output files of the action. |
+| `inputs` | [sequence](/versions/8.5.1/rules/lib/core/list) of [File](/versions/8.5.1/rules/lib/builtins/File)s; or [depset](/versions/8.5.1/rules/lib/builtins/depset); default is `[]`  List or depset of the input files of the action. |
+| `unused_inputs_list` | [File](/versions/8.5.1/rules/lib/builtins/File); or `None`; default is `None`  File containing list of inputs unused by the action. The content of this file (generally one of the outputs of the action) corresponds to the list of input files that were not used during the whole action execution. Any change in those files must not affect in any way the outputs of the action. |
+| `executable` | [File](/versions/8.5.1/rules/lib/builtins/File); or [string](/versions/8.5.1/rules/lib/core/string); or [FilesToRunProvider](/versions/8.5.1/rules/lib/providers/FilesToRunProvider); required  The executable file to be called by the action. |
+| `tools` | [sequence](/versions/8.5.1/rules/lib/core/list); or [depset](/versions/8.5.1/rules/lib/builtins/depset); default is `unbound`  List or depset of any tools needed by the action. Tools are inputs with additional runfiles that are automatically made available to the action. When a list is provided, it can be a heterogenous collection of Files, FilesToRunProvider instances, or depsets of Files. Files which are directly in the list and come from ctx.executable will have their runfiles automatically added. When a depset is provided, it must contain only Files. In both cases, files within depsets are not cross-referenced with ctx.executable for runfiles. |
+| `arguments` | [sequence](/versions/8.5.1/rules/lib/core/list); default is `[]`  Command line arguments of the action. Must be a list of strings or [`actions.args()`](#args) objects. |
+| `mnemonic` | [string](/versions/8.5.1/rules/lib/core/string); or `None`; default is `None`  A one-word description of the action, for example, CppCompile or GoLink. |
+| `progress_message` | [string](/versions/8.5.1/rules/lib/core/string); or `None`; default is `None`  Progress message to show to the user during the build, for example, "Compiling foo.cc to create foo.o". The message may contain `%{label}`, `%{input}`, or `%{output}` patterns, which are substituted with label string, first input, or output's path, respectively. Prefer to use patterns instead of static strings, because the former are more efficient. |
+| `use_default_shell_env` | [bool](/versions/8.5.1/rules/lib/core/bool); default is `False`  Whether the action should use the default shell environment, which consists of a few OS-dependent variables as well as variables set via [`--action_env`](/versions/8.5.1/reference/command-line-reference#flag--action_env). If both `use_default_shell_env` and `env` are set to `True`, values set in `env` will overwrite the default shell environment if [`--incompatible_merge_fixed_and_default_shell_env`](/versions/8.5.1/reference/command-line-reference#flag--incompatible_merge_fixed_and_default_shell_env) is enabled (default). If the flag is not enabled, `env` is ignored. |
+| `env` | [dict](/versions/8.5.1/rules/lib/core/dict); or `None`; default is `None`  Sets the dictionary of environment variables. If both `use_default_shell_env` and `env` are set to `True`, values set in `env` will overwrite the default shell environment if [`--incompatible_merge_fixed_and_default_shell_env`](/versions/8.5.1/reference/command-line-reference#flag--incompatible_merge_fixed_and_default_shell_env) is enabled (default). If the flag is not enabled, `env` is ignored. |
+| `execution_requirements` | [dict](/versions/8.5.1/rules/lib/core/dict); or `None`; default is `None`  Information for scheduling the action. See [tags](/versions/8.5.1/reference/be/common-definitions#common.tags) for useful keys. |
+| `input_manifests` | [sequence](/versions/8.5.1/rules/lib/core/list); or `None`; default is `None`  Legacy argument. Ignored. |
+| `exec_group` | [string](/versions/8.5.1/rules/lib/core/string); or `None`; default is `None`  Runs the action on the given exec group's execution platform. If none, uses the target's default execution platform. |
+| `shadowed_action` | [Action](/versions/8.5.1/rules/lib/builtins/Action); default is `None`  Runs the action using the given shadowed action's inputs and environment added to the action's inputs list and environment. The action environment can overwrite any of the shadowed action's environment variables. If none, uses only the action's inputs and given environment. |
 | `resource_set` | callable; or `None`; default is `None`  A callback function that returns a resource set dictionary, used to estimate resource usage at execution time if this action is run locally. The function accepts two positional arguments: a string representing an OS name (e.g. "osx"), and an integer representing the number of inputs to the action. The returned dictionary may contain the following entries, each of which may be a float or an int:  * "cpu": number of CPUs; default 1* "memory": in MB; default 250* "local\_test": number of local tests; default 1   If this parameter is set to `None` , the default values are used. The callback must be top-level (lambda and nested functions aren't allowed). |
-| `toolchain` | [Label](../builtins/Label); or [string](../core/string); or `None`; default is `unbound`  Toolchain type of the executable or tools used in this action.  If executable and tools are not coming from a toolchain, set this parameter to `None`.  If executable and tools are coming from a toolchain, toolchain type must be set so that the action executes on the correct execution platform.  Note that the rule which creates this action needs to define this toolchain inside its 'rule()' function.  When `toolchain` and `exec\_group` parameters are both set, `exec\_group` will be used. An error is raised in case the `exec\_group` doesn't specify the same toolchain. |
+| `toolchain` | [Label](/versions/8.5.1/rules/lib/builtins/Label); or [string](/versions/8.5.1/rules/lib/core/string); or `None`; default is `unbound`  Toolchain type of the executable or tools used in this action.  If executable and tools are not coming from a toolchain, set this parameter to `None`.  If executable and tools are coming from a toolchain, toolchain type must be set so that the action executes on the correct execution platform.  Note that the rule which creates this action needs to define this toolchain inside its 'rule()' function.  When `toolchain` and `exec\_group` parameters are both set, `exec\_group` will be used. An error is raised in case the `exec\_group` doesn't specify the same toolchain. |
 
 ## run\_shell
 
@@ -149,21 +149,21 @@ Creates an action that runs a shell command. [See example of use](https://github
 
 | Parameter | Description |
 | --- | --- |
-| `outputs` | [sequence](../core/list) of [File](../builtins/File)s; required  List of the output files of the action. |
-| `inputs` | [sequence](../core/list) of [File](../builtins/File)s; or [depset](../builtins/depset); default is `[]`  List or depset of the input files of the action. |
-| `tools` | [sequence](../core/list) of [File](../builtins/File)s; or [depset](../builtins/depset); default is `unbound`  List or depset of any tools needed by the action. Tools are inputs with additional runfiles that are automatically made available to the action. The list can contain Files or FilesToRunProvider instances. |
-| `arguments` | [sequence](../core/list); default is `[]`  Command line arguments of the action. Must be a list of strings or [`actions.args()`](#args) objects. Bazel passes the elements in this attribute as arguments to the command.The command can access these arguments using shell variable substitutions such as `$1`, `$2`, etc. Note that since Args objects are flattened before indexing, if there is an Args object of unknown size then all subsequent strings will be at unpredictable indices. It may be useful to use `$@` (to retrieve all arguments) in conjunction with Args objects of indeterminate size. In the case where `command` is a list of strings, this parameter may not be used. |
-| `mnemonic` | [string](../core/string); or `None`; default is `None`  A one-word description of the action, for example, CppCompile or GoLink. |
-| `command` | [string](../core/string); or [sequence](../core/list) of [string](../core/string)s; required  Shell command to execute. This may either be a string (preferred) or a sequence of strings **(deprecated)**. If `command` is a string, then it is executed as if by `sh -c  "" ` -- that is, the elements in `arguments` are made available to the command as `$1`, `$2` (or `%1`, `%2` if using Windows batch), etc. If `arguments` contains any [`actions.args()`](#args) objects, their contents are appended one by one to the command line, so `$`*i* can refer to individual strings within an Args object. Note that if an Args object of unknown size is passed as part of `arguments`, then the strings will be at unknown indices; in this case the `$@` shell substitution (retrieve all arguments) may be useful. **(Deprecated)** If `command` is a sequence of strings, the first item is the executable to run and the remaining items are its arguments. If this form is used, the `arguments` parameter must not be supplied. *Note that this form is deprecated and will soon be removed. It is disabled with `--incompatible\_run\_shell\_command\_string`. Use this flag to verify your code is compatible.*  Bazel uses the same shell to execute the command as it does for genrules. |
-| `progress_message` | [string](../core/string); or `None`; default is `None`  Progress message to show to the user during the build, for example, "Compiling foo.cc to create foo.o". The message may contain `%{label}`, `%{input}`, or `%{output}` patterns, which are substituted with label string, first input, or output's path, respectively. Prefer to use patterns instead of static strings, because the former are more efficient. |
-| `use_default_shell_env` | [bool](../core/bool); default is `False`  Whether the action should use the default shell environment, which consists of a few OS-dependent variables as well as variables set via [`--action_env`](/versions/8.5.1/reference/command-line-reference#flag--action_env). If both `use_default_shell_env` and `env` are set to `True`, values set in `env` will overwrite the default shell environment if [`--incompatible_merge_fixed_and_default_shell_env`](/versions/8.5.1/reference/command-line-reference#flag--incompatible_merge_fixed_and_default_shell_env) is enabled (default). If the flag is not enabled, `env` is ignored. |
-| `env` | [dict](../core/dict); or `None`; default is `None`  Sets the dictionary of environment variables. If both `use_default_shell_env` and `env` are set to `True`, values set in `env` will overwrite the default shell environment if [`--incompatible_merge_fixed_and_default_shell_env`](/versions/8.5.1/reference/command-line-reference#flag--incompatible_merge_fixed_and_default_shell_env) is enabled (default). If the flag is not enabled, `env` is ignored. |
-| `execution_requirements` | [dict](../core/dict); or `None`; default is `None`  Information for scheduling the action. See [tags](/versions/8.5.1/reference/be/common-definitions#common.tags) for useful keys. |
-| `input_manifests` | [sequence](../core/list); or `None`; default is `None`  Legacy argument. Ignored. |
-| `exec_group` | [string](../core/string); or `None`; default is `None`  Runs the action on the given exec group's execution platform. If none, uses the target's default execution platform. |
-| `shadowed_action` | [Action](../builtins/Action); default is `None`  Runs the action using the given shadowed action's discovered inputs added to the action's inputs list. If none, uses only the action's inputs. |
+| `outputs` | [sequence](/versions/8.5.1/rules/lib/core/list) of [File](/versions/8.5.1/rules/lib/builtins/File)s; required  List of the output files of the action. |
+| `inputs` | [sequence](/versions/8.5.1/rules/lib/core/list) of [File](/versions/8.5.1/rules/lib/builtins/File)s; or [depset](/versions/8.5.1/rules/lib/builtins/depset); default is `[]`  List or depset of the input files of the action. |
+| `tools` | [sequence](/versions/8.5.1/rules/lib/core/list) of [File](/versions/8.5.1/rules/lib/builtins/File)s; or [depset](/versions/8.5.1/rules/lib/builtins/depset); default is `unbound`  List or depset of any tools needed by the action. Tools are inputs with additional runfiles that are automatically made available to the action. The list can contain Files or FilesToRunProvider instances. |
+| `arguments` | [sequence](/versions/8.5.1/rules/lib/core/list); default is `[]`  Command line arguments of the action. Must be a list of strings or [`actions.args()`](#args) objects. Bazel passes the elements in this attribute as arguments to the command.The command can access these arguments using shell variable substitutions such as `$1`, `$2`, etc. Note that since Args objects are flattened before indexing, if there is an Args object of unknown size then all subsequent strings will be at unpredictable indices. It may be useful to use `$@` (to retrieve all arguments) in conjunction with Args objects of indeterminate size. In the case where `command` is a list of strings, this parameter may not be used. |
+| `mnemonic` | [string](/versions/8.5.1/rules/lib/core/string); or `None`; default is `None`  A one-word description of the action, for example, CppCompile or GoLink. |
+| `command` | [string](/versions/8.5.1/rules/lib/core/string); or [sequence](/versions/8.5.1/rules/lib/core/list) of [string](/versions/8.5.1/rules/lib/core/string)s; required  Shell command to execute. This may either be a string (preferred) or a sequence of strings **(deprecated)**. If `command` is a string, then it is executed as if by `sh -c  "" ` -- that is, the elements in `arguments` are made available to the command as `$1`, `$2` (or `%1`, `%2` if using Windows batch), etc. If `arguments` contains any [`actions.args()`](#args) objects, their contents are appended one by one to the command line, so `$`*i* can refer to individual strings within an Args object. Note that if an Args object of unknown size is passed as part of `arguments`, then the strings will be at unknown indices; in this case the `$@` shell substitution (retrieve all arguments) may be useful. **(Deprecated)** If `command` is a sequence of strings, the first item is the executable to run and the remaining items are its arguments. If this form is used, the `arguments` parameter must not be supplied. *Note that this form is deprecated and will soon be removed. It is disabled with `--incompatible\_run\_shell\_command\_string`. Use this flag to verify your code is compatible.*  Bazel uses the same shell to execute the command as it does for genrules. |
+| `progress_message` | [string](/versions/8.5.1/rules/lib/core/string); or `None`; default is `None`  Progress message to show to the user during the build, for example, "Compiling foo.cc to create foo.o". The message may contain `%{label}`, `%{input}`, or `%{output}` patterns, which are substituted with label string, first input, or output's path, respectively. Prefer to use patterns instead of static strings, because the former are more efficient. |
+| `use_default_shell_env` | [bool](/versions/8.5.1/rules/lib/core/bool); default is `False`  Whether the action should use the default shell environment, which consists of a few OS-dependent variables as well as variables set via [`--action_env`](/versions/8.5.1/reference/command-line-reference#flag--action_env). If both `use_default_shell_env` and `env` are set to `True`, values set in `env` will overwrite the default shell environment if [`--incompatible_merge_fixed_and_default_shell_env`](/versions/8.5.1/reference/command-line-reference#flag--incompatible_merge_fixed_and_default_shell_env) is enabled (default). If the flag is not enabled, `env` is ignored. |
+| `env` | [dict](/versions/8.5.1/rules/lib/core/dict); or `None`; default is `None`  Sets the dictionary of environment variables. If both `use_default_shell_env` and `env` are set to `True`, values set in `env` will overwrite the default shell environment if [`--incompatible_merge_fixed_and_default_shell_env`](/versions/8.5.1/reference/command-line-reference#flag--incompatible_merge_fixed_and_default_shell_env) is enabled (default). If the flag is not enabled, `env` is ignored. |
+| `execution_requirements` | [dict](/versions/8.5.1/rules/lib/core/dict); or `None`; default is `None`  Information for scheduling the action. See [tags](/versions/8.5.1/reference/be/common-definitions#common.tags) for useful keys. |
+| `input_manifests` | [sequence](/versions/8.5.1/rules/lib/core/list); or `None`; default is `None`  Legacy argument. Ignored. |
+| `exec_group` | [string](/versions/8.5.1/rules/lib/core/string); or `None`; default is `None`  Runs the action on the given exec group's execution platform. If none, uses the target's default execution platform. |
+| `shadowed_action` | [Action](/versions/8.5.1/rules/lib/builtins/Action); default is `None`  Runs the action using the given shadowed action's discovered inputs added to the action's inputs list. If none, uses only the action's inputs. |
 | `resource_set` | callable; or `None`; default is `None`  A callback function for estimating resource usage if run locally. See[`ctx.actions.run()`](#run.resource_set). |
-| `toolchain` | [Label](../builtins/Label); or [string](../core/string); or `None`; default is `unbound`  Toolchain type of the executable or tools used in this action.  If executable and tools are not coming from a toolchain, set this parameter to `None`.  If executable and tools are coming from a toolchain, toolchain type must be set so that the action executes on the correct execution platform.  Note that the rule which creates this action needs to define this toolchain inside its 'rule()' function.  When `toolchain` and `exec\_group` parameters are both set, `exec\_group` will be used. An error is raised in case the `exec\_group` doesn't specify the same toolchain. |
+| `toolchain` | [Label](/versions/8.5.1/rules/lib/builtins/Label); or [string](/versions/8.5.1/rules/lib/core/string); or `None`; default is `unbound`  Toolchain type of the executable or tools used in this action.  If executable and tools are not coming from a toolchain, set this parameter to `None`.  If executable and tools are coming from a toolchain, toolchain type must be set so that the action executes on the correct execution platform.  Note that the rule which creates this action needs to define this toolchain inside its 'rule()' function.  When `toolchain` and `exec\_group` parameters are both set, `exec\_group` will be used. An error is raised in case the `exec\_group` doesn't specify the same toolchain. |
 
 ## symlink
 
@@ -183,11 +183,11 @@ Otherwise, when you use `target_path`, declare `output` with [`declare_symlink()
 
 | Parameter | Description |
 | --- | --- |
-| `output` | [File](../builtins/File); required  The output of this action. |
-| `target_file` | [File](../builtins/File); or `None`; default is `None`  The File that the output symlink will point to. |
-| `target_path` | [string](../core/string); or `None`; default is `None`  The exact path that the output symlink will point to. No normalization or other processing is applied. |
-| `is_executable` | [bool](../core/bool); default is `False`  May only be used with `target_file`, not `target_path`. If true, when the action is executed, the `target_file`'s path is checked to confirm that it is executable, and an error is reported if it is not. Setting `is_executable` to False does not mean the target is not executable, just that no verification is done. This feature does not make sense for `target_path` because dangling symlinks might not exist at build time. |
-| `progress_message` | [string](../core/string); or `None`; default is `None`  Progress message to show to the user during the build. |
+| `output` | [File](/versions/8.5.1/rules/lib/builtins/File); required  The output of this action. |
+| `target_file` | [File](/versions/8.5.1/rules/lib/builtins/File); or `None`; default is `None`  The File that the output symlink will point to. |
+| `target_path` | [string](/versions/8.5.1/rules/lib/core/string); or `None`; default is `None`  The exact path that the output symlink will point to. No normalization or other processing is applied. |
+| `is_executable` | [bool](/versions/8.5.1/rules/lib/core/bool); default is `False`  May only be used with `target_file`, not `target_path`. If true, when the action is executed, the `target_file`'s path is checked to confirm that it is executable, and an error is reported if it is not. Setting `is_executable` to False does not mean the target is not executable, just that no verification is done. This feature does not make sense for `target_path` because dangling symlinks might not exist at build time. |
+| `progress_message` | [string](/versions/8.5.1/rules/lib/core/string); or `None`; default is `None`  Progress message to show to the user during the build. |
 
 ## template\_dict
 
@@ -209,6 +209,6 @@ Creates a file write action. When the action is executed, it will write the give
 
 | Parameter | Description |
 | --- | --- |
-| `output` | [File](../builtins/File); required  The output file. |
-| `content` | [string](../core/string); or [Args](../builtins/Args); required  the contents of the file. May be a either a string or an [`actions.args()`](#args) object. |
-| `is_executable` | [bool](../core/bool); default is `False`  Whether the output file should be executable. |
\ No newline at end of file
+| `output` | [File](/versions/8.5.1/rules/lib/builtins/File); required  The output file. |
+| `content` | [string](/versions/8.5.1/rules/lib/core/string); or [Args](/versions/8.5.1/rules/lib/builtins/Args); required  the contents of the file. May be a either a string or an [`actions.args()`](#args) object. |
+| `is_executable` | [bool](/versions/8.5.1/rules/lib/core/bool); default is `False`  Whether the output file should be executable. |
\ No newline at end of file
diff --git a/versions/8.5.1/rules/lib/builtins/apple_platform.mdx b/versions/8.5.1/rules/lib/builtins/apple_platform.mdx
index ba2fc42e..44f32632 100644
--- a/versions/8.5.1/rules/lib/builtins/apple_platform.mdx
+++ b/versions/8.5.1/rules/lib/builtins/apple_platform.mdx
@@ -4,7 +4,7 @@ title: 'apple\_platform'
 
 Corresponds to Xcode's notion of a platform as would be found in `Xcode.app/Contents/Developer/Platforms`. Each platform represents an Apple platform type (such as iOS or tvOS) combined with one or more related CPU architectures. For example, the iOS simulator platform supports `x86_64` and `i386` architectures.
 
-Specific instances of this type can be retrieved from the fields of the [apple\_common.platform](../toplevel/apple_common#platform) struct:
+Specific instances of this type can be retrieved from the fields of the [apple\_common.platform](/versions/8.5.1/rules/lib/toplevel/apple_common#platform) struct:
 
 * `apple_common.platform.ios_device`
 * `apple_common.platform.ios_simulator`
@@ -14,7 +14,7 @@ Specific instances of this type can be retrieved from the fields of the [apple\_
 * `apple_common.platform.watchos_device`
 * `apple_common.platform.watchos_simulator`
 
-More commonly, however, the [apple](../fragments/apple) configuration fragment has fields/methods that allow rules to determine the platform for which a target is being built.
+More commonly, however, the [apple](/versions/8.5.1/rules/lib/fragments/apple) configuration fragment has fields/methods that allow rules to determine the platform for which a target is being built.
 
 Example:
 
diff --git a/versions/8.5.1/rules/lib/builtins/configuration.mdx b/versions/8.5.1/rules/lib/builtins/configuration.mdx
index b749bf90..fa7c8b8a 100644
--- a/versions/8.5.1/rules/lib/builtins/configuration.mdx
+++ b/versions/8.5.1/rules/lib/builtins/configuration.mdx
@@ -18,7 +18,7 @@ This object holds information about the environment in which the build is runnin
 bool configuration.coverage_enabled
 ```
 
-A boolean that tells whether code coverage is enabled for this run. Note that this does not compute whether a specific rule should be instrumented for code coverage data collection. For that, see the [`ctx.coverage_instrumented`](../builtins/ctx#coverage_instrumented) function.
+A boolean that tells whether code coverage is enabled for this run. Note that this does not compute whether a specific rule should be instrumented for code coverage data collection. For that, see the [`ctx.coverage_instrumented`](/versions/8.5.1/rules/lib/builtins/ctx#coverage_instrumented) function.
 
 ## default\_shell\_env
 
diff --git a/versions/8.5.1/rules/lib/builtins/ctx.mdx b/versions/8.5.1/rules/lib/builtins/ctx.mdx
index f70a7511..0b178921 100644
--- a/versions/8.5.1/rules/lib/builtins/ctx.mdx
+++ b/versions/8.5.1/rules/lib/builtins/ctx.mdx
@@ -66,7 +66,7 @@ A list of ids for all aspects applied to the target. Only available in aspect im
 struct ctx.attr
 ```
 
-A struct to access the values of the [attributes](https://bazel.build/versions/8.5.1/extending/rules#attributes). The values are provided by the user (if not, a default value is used). The attributes of the struct and the types of their values correspond to the keys and values of the [`attrs` dict](../globals/bzl#rule.attrs) provided to the [`rule` function](../globals/bzl#rule). [See example of use](https://github.com/bazelbuild/examples/blob/main/rules/attributes/printer.bzl).
+A struct to access the values of the [attributes](https://bazel.build/versions/8.5.1/extending/rules#attributes). The values are provided by the user (if not, a default value is used). The attributes of the struct and the types of their values correspond to the keys and values of the [`attrs` dict](/versions/8.5.1/rules/lib/globals/bzl#rule.attrs) provided to the [`rule` function](/versions/8.5.1/rules/lib/globals/bzl#rule). [See example of use](https://github.com/bazelbuild/examples/blob/main/rules/attributes/printer.bzl).
 
 ## bin\_dir
 
@@ -98,7 +98,7 @@ Value of the build setting represented by the current target. If this isn't the
 configuration ctx.configuration
 ```
 
-The default configuration. See the [configuration](../builtins/configuration) type for more details.
+The default configuration. See the [configuration](/versions/8.5.1/rules/lib/builtins/configuration) type for more details.
 
 ## coverage\_instrumented
 
@@ -106,13 +106,13 @@ The default configuration. See the [configuration](../builtins/configuration) ty
 bool ctx.coverage_instrumented(target=None)
 ```
 
-Returns whether code coverage instrumentation should be generated when performing compilation actions for this rule or, if `target` is provided, the rule specified by that Target. (If a non-rule or a Starlark rule Target is provided, this returns False.) Checks if the sources of the current rule (if no Target is provided) or the sources of Target should be instrumented based on the --instrumentation\_filter and --instrument\_test\_targets config settings. This differs from `coverage_enabled` in the [configuration](../builtins/configuration), which notes whether coverage data collection is enabled for the entire run, but not whether a specific target should be instrumented.
+Returns whether code coverage instrumentation should be generated when performing compilation actions for this rule or, if `target` is provided, the rule specified by that Target. (If a non-rule or a Starlark rule Target is provided, this returns False.) Checks if the sources of the current rule (if no Target is provided) or the sources of Target should be instrumented based on the --instrumentation\_filter and --instrument\_test\_targets config settings. This differs from `coverage_enabled` in the [configuration](/versions/8.5.1/rules/lib/builtins/configuration), which notes whether coverage data collection is enabled for the entire run, but not whether a specific target should be instrumented.
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `target` | [Target](../builtins/Target); or `None`; default is `None`  A Target specifying a rule. If not provided, defaults to the current rule. |
+| `target` | [Target](/versions/8.5.1/rules/lib/builtins/Target); or `None`; default is `None`  A Target specifying a rule. If not provided, defaults to the current rule. |
 
 ## created\_actions
 
@@ -120,7 +120,7 @@ Returns whether code coverage instrumentation should be generated when performin
 StarlarkValue ctx.created_actions()
 ```
 
-For rules with [\_skylark\_testable](../globals/bzl#rule._skylark_testable) set to `True`, this returns an `Actions` provider representing all actions created so far for the current rule. For all other rules, returns `None`. Note that the provider is not updated when subsequent actions are created, so you will have to call this function again if you wish to inspect them.
+For rules with [\_skylark\_testable](/versions/8.5.1/rules/lib/globals/bzl#rule._skylark_testable) set to `True`, this returns an `Actions` provider representing all actions created so far for the current rule. For all other rules, returns `None`. Note that the provider is not updated when subsequent actions are created, so you will have to call this function again if you wish to inspect them.
 
 This is intended to help write tests for rule-implementation helper functions, which may take in a `ctx` object and create actions on it.
 
@@ -146,7 +146,7 @@ A collection of the execution groups available for this rule, indexed by their n
 struct ctx.executable
 ```
 
-A `struct` containing executable files defined in [label type attributes](../toplevel/attr#label) marked as [`executable=True`](../toplevel/attr#label.executable). The struct fields correspond to the attribute names. Each value in the struct is either a [`File`](../builtins/File) or `None`. If an optional attribute is not specified in the rule then the corresponding struct value is `None`. If a label type is not marked as `executable=True`, no corresponding struct field is generated. [See example of use](https://github.com/bazelbuild/examples/blob/main/rules/actions_run/execute.bzl).
+A `struct` containing executable files defined in [label type attributes](/versions/8.5.1/rules/lib/toplevel/attr#label) marked as [`executable=True`](/versions/8.5.1/rules/lib/toplevel/attr#label.executable). The struct fields correspond to the attribute names. Each value in the struct is either a [`File`](/versions/8.5.1/rules/lib/builtins/File) or `None`. If an optional attribute is not specified in the rule then the corresponding struct value is `None`. If a label type is not marked as `executable=True`, no corresponding struct field is generated. [See example of use](https://github.com/bazelbuild/examples/blob/main/rules/actions_run/execute.bzl).
 
 ## expand\_location
 
@@ -164,8 +164,8 @@ This function is useful to let the user specify a command in a BUILD file (like
 
 | Parameter | Description |
 | --- | --- |
-| `input` | [string](../core/string); required  String to be expanded. |
-| `targets` | [sequence](../core/list) of [Target](../builtins/Target)s; default is `[]`  List of targets for additional lookup information. These are expanded as follows: A target with a single file in `DefaultInfo.files` expands to that file. Other targets expand to their `DefaultInfo.executable` file if set and if `--incompatible_locations_prefers_executable` is enabled, otherwise they expand to `DefaultInfo.files`. |
+| `input` | [string](/versions/8.5.1/rules/lib/core/string); required  String to be expanded. |
+| `targets` | [sequence](/versions/8.5.1/rules/lib/core/list) of [Target](/versions/8.5.1/rules/lib/builtins/Target)s; default is `[]`  List of targets for additional lookup information. These are expanded as follows: A target with a single file in `DefaultInfo.files` expands to that file. Other targets expand to their `DefaultInfo.executable` file if set and if `--incompatible_locations_prefers_executable` is enabled, otherwise they expand to `DefaultInfo.files`. |
 
 May return `None`.
 
@@ -175,7 +175,7 @@ May return `None`.
 string ctx.expand_make_variables(attribute_name, command, additional_substitutions)
 ```
 
-**Deprecated.** Use [ctx.var](../builtins/ctx#var) to access the variables instead.
+**Deprecated.** Use [ctx.var](/versions/8.5.1/rules/lib/builtins/ctx#var) to access the variables instead.
 Returns a string after expanding all references to "Make variables". The variables must have the following format: `$(VAR_NAME)`. Also, `$$VAR_NAME` expands to `$VAR_NAME`. Examples:
 
 ```
@@ -189,9 +189,9 @@ Additional variables may come from other places, such as configurations. Note th
 
 | Parameter | Description |
 | --- | --- |
-| `attribute_name` | [string](../core/string); required |
-| `command` | [string](../core/string); required  The expression to expand. It can contain references to "Make variables". |
-| `additional_substitutions` | [dict](../core/dict); required  Additional substitutions to make beyond the default make variables. |
+| `attribute_name` | [string](/versions/8.5.1/rules/lib/core/string); required |
+| `command` | [string](/versions/8.5.1/rules/lib/core/string); required  The expression to expand. It can contain references to "Make variables". |
+| `additional_substitutions` | [dict](/versions/8.5.1/rules/lib/core/dict); required  Additional substitutions to make beyond the default make variables. |
 
 ## features
 
@@ -207,7 +207,7 @@ The set of features that are explicitly enabled by the user for this rule. [See
 struct ctx.file
 ```
 
-A `struct` containing files defined in [label type attributes](../toplevel/attr#label) marked as [`allow_single_file`](../toplevel/attr#label.allow_single_file). The struct fields correspond to the attribute names. The struct value is always a [`File`](../builtins/File) or `None`. If an optional attribute is not specified in the rule then the corresponding struct value is `None`. If a label type is not marked as `allow_single_file`, no corresponding struct field is generated. It is a shortcut for:
+A `struct` containing files defined in [label type attributes](/versions/8.5.1/rules/lib/toplevel/attr#label) marked as [`allow_single_file`](/versions/8.5.1/rules/lib/toplevel/attr#label.allow_single_file). The struct fields correspond to the attribute names. The struct value is always a [`File`](/versions/8.5.1/rules/lib/builtins/File) or `None`. If an optional attribute is not specified in the rule then the corresponding struct value is `None`. If a label type is not marked as `allow_single_file`, no corresponding struct field is generated. It is a shortcut for:
 
 ```
 list(ctx.attr..files)[0]
@@ -221,7 +221,7 @@ In other words, use `file` to access the (singular) [default output](https://baz
 struct ctx.files
 ```
 
-A `struct` containing files defined in [label](../toplevel/attr#label) or [label list](../toplevel/attr#label_list) type attributes. The struct fields correspond to the attribute names. The struct values are `list` of [`File`](../builtins/File)s. It is a shortcut for:
+A `struct` containing files defined in [label](/versions/8.5.1/rules/lib/toplevel/attr#label) or [label list](/versions/8.5.1/rules/lib/toplevel/attr#label_list) type attributes. The struct fields correspond to the attribute names. The struct values are `list` of [`File`](/versions/8.5.1/rules/lib/builtins/File)s. It is a shortcut for:
 
 ```
 [f for t in ctx.attr. for f in t.files]
@@ -267,13 +267,13 @@ The label of the target currently being analyzed.
 structure ctx.outputs
 ```
 
-A pseudo-struct containing all the predeclared output files, represented by [`File`](../builtins/File) objects. See the [Rules page](https://bazel.build/versions/8.5.1/extending/rules#files) for more information and examples.
+A pseudo-struct containing all the predeclared output files, represented by [`File`](/versions/8.5.1/rules/lib/builtins/File) objects. See the [Rules page](https://bazel.build/versions/8.5.1/extending/rules#files) for more information and examples.
 
 This field does not exist on aspect contexts, since aspects do not have predeclared outputs.
 
 The fields of this object are defined as follows. It is an error if two outputs produce the same field name or have the same label.
 
-* If the rule declares an [`outputs`](../globals/bzl#rule.outputs) dict, then for every entry in the dict, there is a field whose name is the key and whose value is the corresponding `File`.* For every attribute of type [`attr.output`](../toplevel/attr#output) that the rule declares, there is a field whose name is the attribute's name. If the target specified a label for that attribute, then the field value is the corresponding `File`; otherwise the field value is `None`.* For every attribute of type [`attr.output_list`](../toplevel/attr#output_list) that the rule declares, there is a field whose name is the attribute's name. The field value is a list of `File` objects corresponding to the labels given for that attribute in the target, or an empty list if the attribute was not specified in the target.* **(Deprecated)** If the rule is marked [`executable`](../globals/bzl#rule.executable) or [`test`](../globals/bzl#rule.test), there is a field named `"executable"`, which is the default executable. It is recommended that instead of using this, you pass another file (either predeclared or not) to the `executable` arg of [`DefaultInfo`](../providers/DefaultInfo).
+* If the rule declares an [`outputs`](/versions/8.5.1/rules/lib/globals/bzl#rule.outputs) dict, then for every entry in the dict, there is a field whose name is the key and whose value is the corresponding `File`.* For every attribute of type [`attr.output`](/versions/8.5.1/rules/lib/toplevel/attr#output) that the rule declares, there is a field whose name is the attribute's name. If the target specified a label for that attribute, then the field value is the corresponding `File`; otherwise the field value is `None`.* For every attribute of type [`attr.output_list`](/versions/8.5.1/rules/lib/toplevel/attr#output_list) that the rule declares, there is a field whose name is the attribute's name. The field value is a list of `File` objects corresponding to the labels given for that attribute in the target, or an empty list if the attribute was not specified in the target.* **(Deprecated)** If the rule is marked [`executable`](/versions/8.5.1/rules/lib/globals/bzl#rule.executable) or [`test`](/versions/8.5.1/rules/lib/globals/bzl#rule.test), there is a field named `"executable"`, which is the default executable. It is recommended that instead of using this, you pass another file (either predeclared or not) to the `executable` arg of [`DefaultInfo`](/versions/8.5.1/rules/lib/providers/DefaultInfo).
 
 ## resolve\_command
 
@@ -288,13 +288,13 @@ tuple ctx.resolve_command(command='', attribute=None, expand_locations=False, ma
 
 | Parameter | Description |
 | --- | --- |
-| `command` | [string](../core/string); default is `''`  Command to resolve. |
-| `attribute` | [string](../core/string); or `None`; default is `None`  Name of the associated attribute for which to issue an error, or None. |
-| `expand_locations` | [bool](../core/bool); default is `False`  Shall we expand $(location) variables? See [ctx.expand\_location()](#expand_location) for more details. |
-| `make_variables` | [dict](../core/dict); or `None`; default is `None`  Make variables to expand, or None. |
-| `tools` | [sequence](../core/list) of [Target](../builtins/Target)s; default is `[]`  List of tools (list of targets). |
-| `label_dict` | [dict](../core/dict); default is `{}`  Dictionary of resolved labels and the corresponding list of Files (a dict of Label : list of Files). |
-| `execution_requirements` | [dict](../core/dict); default is `{}`  Information for scheduling the action to resolve this command. See [tags](/versions/8.5.1/reference/be/common-definitions#common.tags) for useful keys. |
+| `command` | [string](/versions/8.5.1/rules/lib/core/string); default is `''`  Command to resolve. |
+| `attribute` | [string](/versions/8.5.1/rules/lib/core/string); or `None`; default is `None`  Name of the associated attribute for which to issue an error, or None. |
+| `expand_locations` | [bool](/versions/8.5.1/rules/lib/core/bool); default is `False`  Shall we expand $(location) variables? See [ctx.expand\_location()](#expand_location) for more details. |
+| `make_variables` | [dict](/versions/8.5.1/rules/lib/core/dict); or `None`; default is `None`  Make variables to expand, or None. |
+| `tools` | [sequence](/versions/8.5.1/rules/lib/core/list) of [Target](/versions/8.5.1/rules/lib/builtins/Target)s; default is `[]`  List of tools (list of targets). |
+| `label_dict` | [dict](/versions/8.5.1/rules/lib/core/dict); default is `{}`  Dictionary of resolved labels and the corresponding list of Files (a dict of Label : list of Files). |
+| `execution_requirements` | [dict](/versions/8.5.1/rules/lib/core/dict); default is `{}`  Information for scheduling the action to resolve this command. See [tags](/versions/8.5.1/reference/be/common-definitions#common.tags) for useful keys. |
 
 ## resolve\_tools
 
@@ -310,7 +310,7 @@ In contrast to `ctx.resolve_command`, this method does not require that Bash be
 
 | Parameter | Description |
 | --- | --- |
-| `tools` | [sequence](../core/list) of [Target](../builtins/Target)s; default is `[]`  List of tools (list of targets). |
+| `tools` | [sequence](/versions/8.5.1/rules/lib/core/list) of [Target](/versions/8.5.1/rules/lib/builtins/Target)s; default is `[]`  List of tools (list of targets). |
 
 ## rule
 
@@ -332,12 +332,12 @@ Creates a runfiles object.
 
 | Parameter | Description |
 | --- | --- |
-| `files` | [sequence](../core/list) of [File](../builtins/File)s; default is `[]`  The list of files to be added to the runfiles. |
-| `transitive_files` | [depset](../builtins/depset) of [File](../builtins/File)s; or `None`; default is `None`  The (transitive) set of files to be added to the runfiles. The depset should use the `default` order (which, as the name implies, is the default). |
-| `collect_data` | [bool](../core/bool); default is `False`  **Use of this parameter is not recommended. See [runfiles guide](https://bazel.build/versions/8.5.1/extending/rules#runfiles)**. Whether to collect the data runfiles from the dependencies in srcs, data and deps attributes. |
-| `collect_default` | [bool](../core/bool); default is `False`  **Use of this parameter is not recommended. See [runfiles guide](https://bazel.build/versions/8.5.1/extending/rules#runfiles)**. Whether to collect the default runfiles from the dependencies in srcs, data and deps attributes. |
-| `symlinks` | [dict](../core/dict); or [depset](../builtins/depset) of [SymlinkEntry](../builtins/SymlinkEntry)s; default is `{}`  Either a SymlinkEntry depset or the map of symlinks to be added to the runfiles. Symlinks are always added under the main workspace's runfiles directory (e.g. `/_main/`, **not** the directory corresponding to the current target's repository. See [Runfiles symlinks](https://bazel.build/versions/8.5.1/extending/rules#runfiles_symlinks) in the rules guide. |
-| `root_symlinks` | [dict](../core/dict); or [depset](../builtins/depset) of [SymlinkEntry](../builtins/SymlinkEntry)s; default is `{}`  Either a SymlinkEntry depset or a map of symlinks to be added to the runfiles. See [Runfiles symlinks](https://bazel.build/versions/8.5.1/extending/rules#runfiles_symlinks) in the rules guide. |
+| `files` | [sequence](/versions/8.5.1/rules/lib/core/list) of [File](/versions/8.5.1/rules/lib/builtins/File)s; default is `[]`  The list of files to be added to the runfiles. |
+| `transitive_files` | [depset](/versions/8.5.1/rules/lib/builtins/depset) of [File](/versions/8.5.1/rules/lib/builtins/File)s; or `None`; default is `None`  The (transitive) set of files to be added to the runfiles. The depset should use the `default` order (which, as the name implies, is the default). |
+| `collect_data` | [bool](/versions/8.5.1/rules/lib/core/bool); default is `False`  **Use of this parameter is not recommended. See [runfiles guide](https://bazel.build/versions/8.5.1/extending/rules#runfiles)**. Whether to collect the data runfiles from the dependencies in srcs, data and deps attributes. |
+| `collect_default` | [bool](/versions/8.5.1/rules/lib/core/bool); default is `False`  **Use of this parameter is not recommended. See [runfiles guide](https://bazel.build/versions/8.5.1/extending/rules#runfiles)**. Whether to collect the default runfiles from the dependencies in srcs, data and deps attributes. |
+| `symlinks` | [dict](/versions/8.5.1/rules/lib/core/dict); or [depset](/versions/8.5.1/rules/lib/builtins/depset) of [SymlinkEntry](/versions/8.5.1/rules/lib/builtins/SymlinkEntry)s; default is `{}`  Either a SymlinkEntry depset or the map of symlinks to be added to the runfiles. Symlinks are always added under the main workspace's runfiles directory (e.g. `/_main/`, **not** the directory corresponding to the current target's repository. See [Runfiles symlinks](https://bazel.build/versions/8.5.1/extending/rules#runfiles_symlinks) in the rules guide. |
+| `root_symlinks` | [dict](/versions/8.5.1/rules/lib/core/dict); or [depset](/versions/8.5.1/rules/lib/builtins/depset) of [SymlinkEntry](/versions/8.5.1/rules/lib/builtins/SymlinkEntry)s; default is `{}`  Either a SymlinkEntry depset or a map of symlinks to be added to the runfiles. See [Runfiles symlinks](https://bazel.build/versions/8.5.1/extending/rules#runfiles_symlinks) in the rules guide. |
 
 ## split\_attr
 
@@ -367,7 +367,7 @@ Returns true if the given constraint value is part of the current target platfor
 
 | Parameter | Description |
 | --- | --- |
-| `constraintValue` | [ConstraintValueInfo](../providers/ConstraintValueInfo); required  The constraint value to check the target platform against. |
+| `constraintValue` | [ConstraintValueInfo](/versions/8.5.1/rules/lib/providers/ConstraintValueInfo); required  The constraint value to check the target platform against. |
 
 ## toolchains
 
diff --git a/versions/8.5.1/rules/lib/builtins/depset.mdx b/versions/8.5.1/rules/lib/builtins/depset.mdx
index b4ce0df7..f8699d33 100644
--- a/versions/8.5.1/rules/lib/builtins/depset.mdx
+++ b/versions/8.5.1/rules/lib/builtins/depset.mdx
@@ -6,7 +6,7 @@ A specialized data structure that supports efficient merge operations and has a
 
 The elements of a depset must be hashable and all of the same type (as defined by the built-in type(x) function), but depsets are not simply hash sets and do not support fast membership tests. If you need a general set datatype, you can simulate one using a dictionary where all keys map to `True`.
 
-Depsets are immutable. They should be created using their [constructor function](../globals/bzl#depset) and merged or augmented with other depsets via the `transitive` argument.
+Depsets are immutable. They should be created using their [constructor function](/versions/8.5.1/rules/lib/globals/bzl#depset) and merged or augmented with other depsets via the `transitive` argument.
 
 The `order` parameter determines the kind of traversal that is done to convert the depset to an iterable. There are four possible values:
 
diff --git a/versions/8.5.1/rules/lib/builtins/fragments.mdx b/versions/8.5.1/rules/lib/builtins/fragments.mdx
index ab0d4deb..727c1346 100644
--- a/versions/8.5.1/rules/lib/builtins/fragments.mdx
+++ b/versions/8.5.1/rules/lib/builtins/fragments.mdx
@@ -6,4 +6,4 @@ A collection of configuration fragments available in the current rule implementa
 
 Only configuration fragments which are declared in the rule definition may be accessed in this collection.
 
-See the [configuration fragment reference](../fragments) for a list of available fragments and the [rules documentation](https://bazel.build/versions/8.5.1/extending/rules#configuration_fragments) for how to use them.
\ No newline at end of file
+See the [configuration fragment reference](/versions/8.5.1/rules/lib/fragments) for a list of available fragments and the [rules documentation](https://bazel.build/versions/8.5.1/extending/rules#configuration_fragments) for how to use them.
\ No newline at end of file
diff --git a/versions/8.5.1/rules/lib/builtins/macro.mdx b/versions/8.5.1/rules/lib/builtins/macro.mdx
index dfa30f1c..15c21e69 100644
--- a/versions/8.5.1/rules/lib/builtins/macro.mdx
+++ b/versions/8.5.1/rules/lib/builtins/macro.mdx
@@ -3,7 +3,7 @@ title: 'macro'
 ---
 
 A callable Starlark value representing a symbolic macro; in other words, the return value of
-[`macro()`](../globals/bzl#macro). Invoking this value during package
+[`macro()`](/versions/8.5.1/rules/lib/globals/bzl#macro). Invoking this value during package
 construction time will instantiate the macro, and cause the macro's implementation function to be
 evaluated (in a separate context, different from the context in which the macro value was invoked),
 in most cases causing targets to be added to the package's target set. For more information, see
diff --git a/versions/8.5.1/rules/lib/builtins/module_ctx.mdx b/versions/8.5.1/rules/lib/builtins/module_ctx.mdx
index f8f3226c..e2e61c77 100644
--- a/versions/8.5.1/rules/lib/builtins/module_ctx.mdx
+++ b/versions/8.5.1/rules/lib/builtins/module_ctx.mdx
@@ -36,16 +36,16 @@ Downloads a file to the output path for the provided url and returns a struct co
 
 | Parameter | Description |
 | --- | --- |
-| `url` | [string](../core/string); or Iterable of [string](../core/string)s; required  List of mirror URLs referencing the same file. |
-| `output` | [string](../core/string); or [Label](../builtins/Label); or [path](../builtins/path); default is `''`  path to the output file, relative to the repository directory. |
-| `sha256` | [string](../core/string); default is `''`  The expected SHA-256 hash of the file downloaded. This must match the SHA-256 hash of the file downloaded. It is a security risk to omit the SHA-256 as remote files can change. At best omitting this field will make your build non-hermetic. It is optional to make development easier but should be set before shipping. If provided, the repository cache will first be checked for a file with the given hash; a download will only be attempted if the file was not found in the cache. After a successful download, the file will be added to the cache. |
-| `executable` | [bool](../core/bool); default is `False`  Set the executable flag on the created file, false by default. |
-| `allow_fail` | [bool](../core/bool); default is `False`  If set, indicate the error in the return value instead of raising an error for failed downloads. |
-| `canonical_id` | [string](../core/string); default is `''`  If set, restrict cache hits to those cases where the file was added to the cache with the same canonical id. By default caching uses the checksum (`sha256` or `integrity`). |
-| `auth` | [dict](../core/dict); default is `{}`  An optional dict specifying authentication information for some of the URLs. |
-| `headers` | [dict](../core/dict); default is `{}`  An optional dict specifying http headers for all URLs. |
-| `integrity` | [string](../core/string); default is `''`  Expected checksum of the file downloaded, in Subresource Integrity format. This must match the checksum of the file downloaded. It is a security risk to omit the checksum as remote files can change. At best omitting this field will make your build non-hermetic. It is optional to make development easier but should be set before shipping. If provided, the repository cache will first be checked for a file with the given checksum; a download will only be attempted if the file was not found in the cache. After a successful download, the file will be added to the cache. |
-| `block` | [bool](../core/bool); default is `True`  If set to false, the call returns immediately and instead of the regular return value, it returns a token with one single method, wait(), which blocks until the download is finished and returns the usual return value or throws as usual. |
+| `url` | [string](/versions/8.5.1/rules/lib/core/string); or Iterable of [string](/versions/8.5.1/rules/lib/core/string)s; required  List of mirror URLs referencing the same file. |
+| `output` | [string](/versions/8.5.1/rules/lib/core/string); or [Label](/versions/8.5.1/rules/lib/builtins/Label); or [path](/versions/8.5.1/rules/lib/builtins/path); default is `''`  path to the output file, relative to the repository directory. |
+| `sha256` | [string](/versions/8.5.1/rules/lib/core/string); default is `''`  The expected SHA-256 hash of the file downloaded. This must match the SHA-256 hash of the file downloaded. It is a security risk to omit the SHA-256 as remote files can change. At best omitting this field will make your build non-hermetic. It is optional to make development easier but should be set before shipping. If provided, the repository cache will first be checked for a file with the given hash; a download will only be attempted if the file was not found in the cache. After a successful download, the file will be added to the cache. |
+| `executable` | [bool](/versions/8.5.1/rules/lib/core/bool); default is `False`  Set the executable flag on the created file, false by default. |
+| `allow_fail` | [bool](/versions/8.5.1/rules/lib/core/bool); default is `False`  If set, indicate the error in the return value instead of raising an error for failed downloads. |
+| `canonical_id` | [string](/versions/8.5.1/rules/lib/core/string); default is `''`  If set, restrict cache hits to those cases where the file was added to the cache with the same canonical id. By default caching uses the checksum (`sha256` or `integrity`). |
+| `auth` | [dict](/versions/8.5.1/rules/lib/core/dict); default is `{}`  An optional dict specifying authentication information for some of the URLs. |
+| `headers` | [dict](/versions/8.5.1/rules/lib/core/dict); default is `{}`  An optional dict specifying http headers for all URLs. |
+| `integrity` | [string](/versions/8.5.1/rules/lib/core/string); default is `''`  Expected checksum of the file downloaded, in Subresource Integrity format. This must match the checksum of the file downloaded. It is a security risk to omit the checksum as remote files can change. At best omitting this field will make your build non-hermetic. It is optional to make development easier but should be set before shipping. If provided, the repository cache will first be checked for a file with the given checksum; a download will only be attempted if the file was not found in the cache. After a successful download, the file will be added to the cache. |
+| `block` | [bool](/versions/8.5.1/rules/lib/core/bool); default is `True`  If set to false, the call returns immediately and instead of the regular return value, it returns a token with one single method, wait(), which blocks until the download is finished and returns the usual return value or throws as usual. |
 
 ## download\_and\_extract
 
@@ -59,17 +59,17 @@ Downloads a file to the output path for the provided url, extracts it, and retur
 
 | Parameter | Description |
 | --- | --- |
-| `url` | [string](../core/string); or Iterable of [string](../core/string)s; required  List of mirror URLs referencing the same file. |
-| `output` | [string](../core/string); or [Label](../builtins/Label); or [path](../builtins/path); default is `''`  Path to the directory where the archive will be unpacked, relative to the repository directory. |
-| `sha256` | [string](../core/string); default is `''`  The expected SHA-256 hash of the file downloaded. This must match the SHA-256 hash of the file downloaded. It is a security risk to omit the SHA-256 as remote files can change. At best omitting this field will make your build non-hermetic. It is optional to make development easier but should be set before shipping. If provided, the repository cache will first be checked for a file with the given hash; a download will only be attempted if the file was not found in the cache. After a successful download, the file will be added to the cache. |
-| `type` | [string](../core/string); default is `''`  The archive type of the downloaded file. By default, the archive type is determined from the file extension of the URL. If the file has no extension, you can explicitly specify either "zip", "jar", "war", "aar", "nupkg", "whl", "tar", "tar.gz", "tgz", "tar.xz", "txz", ".tar.zst", ".tzst", "tar.bz2", ".tbz", ".ar", or ".deb" here. |
-| `strip_prefix` | [string](../core/string); default is `''`  A directory prefix to strip from the extracted files. Many archives contain a top-level directory that contains all files in the archive. Instead of needing to specify this prefix over and over in the `build_file`, this field can be used to strip it from extracted files. For compatibility, this parameter may also be used under the deprecated name `stripPrefix`. |
-| `allow_fail` | [bool](../core/bool); default is `False`  If set, indicate the error in the return value instead of raising an error for failed downloads. |
-| `canonical_id` | [string](../core/string); default is `''`  If set, restrict cache hits to those cases where the file was added to the cache with the same canonical id. By default caching uses the checksum" (`sha256` or `integrity`). |
-| `auth` | [dict](../core/dict); default is `{}`  An optional dict specifying authentication information for some of the URLs. |
-| `headers` | [dict](../core/dict); default is `{}`  An optional dict specifying http headers for all URLs. |
-| `integrity` | [string](../core/string); default is `''`  Expected checksum of the file downloaded, in Subresource Integrity format. This must match the checksum of the file downloaded. It is a security risk to omit the checksum as remote files can change. At best omitting this field will make your build non-hermetic. It is optional to make development easier but should be set before shipping. If provided, the repository cache will first be checked for a file with the given checksum; a download will only be attempted if the file was not found in the cache. After a successful download, the file will be added to the cache. |
-| `rename_files` | [dict](../core/dict); default is `{}`  An optional dict specifying files to rename during the extraction. Archive entries with names exactly matching a key will be renamed to the value, prior to any directory prefix adjustment. This can be used to extract archives that contain non-Unicode filenames, or which have files that would extract to the same path on case-insensitive filesystems. |
+| `url` | [string](/versions/8.5.1/rules/lib/core/string); or Iterable of [string](/versions/8.5.1/rules/lib/core/string)s; required  List of mirror URLs referencing the same file. |
+| `output` | [string](/versions/8.5.1/rules/lib/core/string); or [Label](/versions/8.5.1/rules/lib/builtins/Label); or [path](/versions/8.5.1/rules/lib/builtins/path); default is `''`  Path to the directory where the archive will be unpacked, relative to the repository directory. |
+| `sha256` | [string](/versions/8.5.1/rules/lib/core/string); default is `''`  The expected SHA-256 hash of the file downloaded. This must match the SHA-256 hash of the file downloaded. It is a security risk to omit the SHA-256 as remote files can change. At best omitting this field will make your build non-hermetic. It is optional to make development easier but should be set before shipping. If provided, the repository cache will first be checked for a file with the given hash; a download will only be attempted if the file was not found in the cache. After a successful download, the file will be added to the cache. |
+| `type` | [string](/versions/8.5.1/rules/lib/core/string); default is `''`  The archive type of the downloaded file. By default, the archive type is determined from the file extension of the URL. If the file has no extension, you can explicitly specify either "zip", "jar", "war", "aar", "nupkg", "whl", "tar", "tar.gz", "tgz", "tar.xz", "txz", ".tar.zst", ".tzst", "tar.bz2", ".tbz", ".ar", or ".deb" here. |
+| `strip_prefix` | [string](/versions/8.5.1/rules/lib/core/string); default is `''`  A directory prefix to strip from the extracted files. Many archives contain a top-level directory that contains all files in the archive. Instead of needing to specify this prefix over and over in the `build_file`, this field can be used to strip it from extracted files. For compatibility, this parameter may also be used under the deprecated name `stripPrefix`. |
+| `allow_fail` | [bool](/versions/8.5.1/rules/lib/core/bool); default is `False`  If set, indicate the error in the return value instead of raising an error for failed downloads. |
+| `canonical_id` | [string](/versions/8.5.1/rules/lib/core/string); default is `''`  If set, restrict cache hits to those cases where the file was added to the cache with the same canonical id. By default caching uses the checksum" (`sha256` or `integrity`). |
+| `auth` | [dict](/versions/8.5.1/rules/lib/core/dict); default is `{}`  An optional dict specifying authentication information for some of the URLs. |
+| `headers` | [dict](/versions/8.5.1/rules/lib/core/dict); default is `{}`  An optional dict specifying http headers for all URLs. |
+| `integrity` | [string](/versions/8.5.1/rules/lib/core/string); default is `''`  Expected checksum of the file downloaded, in Subresource Integrity format. This must match the checksum of the file downloaded. It is a security risk to omit the checksum as remote files can change. At best omitting this field will make your build non-hermetic. It is optional to make development easier but should be set before shipping. If provided, the repository cache will first be checked for a file with the given checksum; a download will only be attempted if the file was not found in the cache. After a successful download, the file will be added to the cache. |
+| `rename_files` | [dict](/versions/8.5.1/rules/lib/core/dict); default is `{}`  An optional dict specifying files to rename during the extraction. Archive entries with names exactly matching a key will be renamed to the value, prior to any directory prefix adjustment. This can be used to extract archives that contain non-Unicode filenames, or which have files that would extract to the same path on case-insensitive filesystems. |
 
 ## execute
 
@@ -83,11 +83,11 @@ Executes the command given by the list of arguments. The execution time of the c
 
 | Parameter | Description |
 | --- | --- |
-| `arguments` | [sequence](../core/list); required  List of arguments, the first element should be the path to the program to execute. |
-| `timeout` | [int](../core/int); default is `600`  Maximum duration of the command in seconds (default is 600 seconds). |
-| `environment` | [dict](../core/dict); default is `{}`  Force some environment variables to be set to be passed to the process. The value can be `None` to remove the environment variable. |
-| `quiet` | [bool](../core/bool); default is `True`  If stdout and stderr should be printed to the terminal. |
-| `working_directory` | [string](../core/string); default is `""`  Working directory for command execution. Can be relative to the repository root or absolute. The default is the repository root. |
+| `arguments` | [sequence](/versions/8.5.1/rules/lib/core/list); required  List of arguments, the first element should be the path to the program to execute. |
+| `timeout` | [int](/versions/8.5.1/rules/lib/core/int); default is `600`  Maximum duration of the command in seconds (default is 600 seconds). |
+| `environment` | [dict](/versions/8.5.1/rules/lib/core/dict); default is `{}`  Force some environment variables to be set to be passed to the process. The value can be `None` to remove the environment variable. |
+| `quiet` | [bool](/versions/8.5.1/rules/lib/core/bool); default is `True`  If stdout and stderr should be printed to the terminal. |
+| `working_directory` | [string](/versions/8.5.1/rules/lib/core/string); default is `""`  Working directory for command execution. Can be relative to the repository root or absolute. The default is the repository root. |
 
 ## extension\_metadata
 
@@ -101,10 +101,10 @@ Constructs an opaque object that can be returned from the module extension's imp
 
 | Parameter | Description |
 | --- | --- |
-| `root_module_direct_deps` | [sequence](../core/list) of [string](../core/string)s; or [string](../core/string); or `None`; default is `None`  The names of the repositories that the extension considers to be direct dependencies of the root module. If the root module imports additional repositories or does not import all of these repositories via [`use_repo`](../globals/module#use_repo), Bazel will print a warning when the extension is evaluated, instructing the user to run `bazel mod tidy` to fix the `use_repo` calls automatically. If one of `root_module_direct_deps` and will print a warning and a fixup command when the extension is evaluated. If one of `root_module_direct_deps` and `root_module_direct_dev_deps` is specified, the other has to be as well. The lists specified by these two parameters must be disjoint. Exactly one of `root_module_direct_deps` and `root_module_direct_dev_deps` can be set to the special value `"all"`, which is treated as if a list with the names of all repositories generated by the extension was specified as the value. |
-| `root_module_direct_dev_deps` | [sequence](../core/list) of [string](../core/string)s; or [string](../core/string); or `None`; default is `None`  The names of the repositories that the extension considers to be direct dev dependencies of the root module. If the root module imports additional repositories or does not import all of these repositories via [`use_repo`](../globals/module#use_repo) on an extension proxy created with `use_extension(..., dev_dependency = True)`, Bazel will print a warning when the extension is evaluated, instructing the user to run `bazel mod tidy` to fix the `use_repo` calls automatically. If one of `root_module_direct_deps` and `root_module_direct_dev_deps` is specified, the other has to be as well. The lists specified by these two parameters must be disjoint. Exactly one of `root_module_direct_deps` and `root_module_direct_dev_deps` can be set to the special value `"all"`, which is treated as if a list with the names of all repositories generated by the extension was specified as the value. |
-| `reproducible` | [bool](../core/bool); default is `False`  States that this module extension ensures complete reproducibility, thereby it should not be stored in the lockfile. |
-| `facts` | [dict](../core/dict) of [string](../core/string)s; default is `{}`  A JSON-like dict that is made available to future executions of this extension via the `module\_ctx.facts` property. This is useful for extensions that want to preserve universally true facts such as the hashes of artifacts in an immutable repository. Bazel may shallowly merge multiple facts dicts returned by different versions of the extension in order to resolve merge conflicts on the MODULE.bazel.lock file, as if by applying the `dict.update()` method or the `|` operator in Starlark. Extensions should use facts for key-value storage only and ensure that the key uniquely determines the value, although perhaps only via additional information and network access. An extension can opt out of this merging by providing a dict with a single, fixed top-level key and an arbitrary value. Note that the value provided here may be read back by a different version of the extension, so either include a version number or use a schema that is unlikely to result in ambiguities. |
+| `root_module_direct_deps` | [sequence](/versions/8.5.1/rules/lib/core/list) of [string](/versions/8.5.1/rules/lib/core/string)s; or [string](/versions/8.5.1/rules/lib/core/string); or `None`; default is `None`  The names of the repositories that the extension considers to be direct dependencies of the root module. If the root module imports additional repositories or does not import all of these repositories via [`use_repo`](/versions/8.5.1/rules/lib/globals/module#use_repo), Bazel will print a warning when the extension is evaluated, instructing the user to run `bazel mod tidy` to fix the `use_repo` calls automatically. If one of `root_module_direct_deps` and will print a warning and a fixup command when the extension is evaluated. If one of `root_module_direct_deps` and `root_module_direct_dev_deps` is specified, the other has to be as well. The lists specified by these two parameters must be disjoint. Exactly one of `root_module_direct_deps` and `root_module_direct_dev_deps` can be set to the special value `"all"`, which is treated as if a list with the names of all repositories generated by the extension was specified as the value. |
+| `root_module_direct_dev_deps` | [sequence](/versions/8.5.1/rules/lib/core/list) of [string](/versions/8.5.1/rules/lib/core/string)s; or [string](/versions/8.5.1/rules/lib/core/string); or `None`; default is `None`  The names of the repositories that the extension considers to be direct dev dependencies of the root module. If the root module imports additional repositories or does not import all of these repositories via [`use_repo`](/versions/8.5.1/rules/lib/globals/module#use_repo) on an extension proxy created with `use_extension(..., dev_dependency = True)`, Bazel will print a warning when the extension is evaluated, instructing the user to run `bazel mod tidy` to fix the `use_repo` calls automatically. If one of `root_module_direct_deps` and `root_module_direct_dev_deps` is specified, the other has to be as well. The lists specified by these two parameters must be disjoint. Exactly one of `root_module_direct_deps` and `root_module_direct_dev_deps` can be set to the special value `"all"`, which is treated as if a list with the names of all repositories generated by the extension was specified as the value. |
+| `reproducible` | [bool](/versions/8.5.1/rules/lib/core/bool); default is `False`  States that this module extension ensures complete reproducibility, thereby it should not be stored in the lockfile. |
+| `facts` | [dict](/versions/8.5.1/rules/lib/core/dict) of [string](/versions/8.5.1/rules/lib/core/string)s; default is `{}`  A JSON-like dict that is made available to future executions of this extension via the `module\_ctx.facts` property. This is useful for extensions that want to preserve universally true facts such as the hashes of artifacts in an immutable repository. Bazel may shallowly merge multiple facts dicts returned by different versions of the extension in order to resolve merge conflicts on the MODULE.bazel.lock file, as if by applying the `dict.update()` method or the `|` operator in Starlark. Extensions should use facts for key-value storage only and ensure that the key uniquely determines the value, although perhaps only via additional information and network access. An extension can opt out of this merging by providing a dict with a single, fixed top-level key and an arbitrary value. Note that the value provided here may be read back by a different version of the extension, so either include a version number or use a schema that is unlikely to result in ambiguities. |
 
 ## extract
 
@@ -118,11 +118,11 @@ Extract an archive to the repository directory.
 
 | Parameter | Description |
 | --- | --- |
-| `archive` | [string](../core/string); or [Label](../builtins/Label); or [path](../builtins/path); required  path to the archive that will be unpacked, relative to the repository directory. |
-| `output` | [string](../core/string); or [Label](../builtins/Label); or [path](../builtins/path); default is `''`  path to the directory where the archive will be unpacked, relative to the repository directory. |
-| `strip_prefix` | [string](../core/string); default is `''`  a directory prefix to strip from the extracted files. Many archives contain a top-level directory that contains all files in the archive. Instead of needing to specify this prefix over and over in the `build_file`, this field can be used to strip it from extracted files. For compatibility, this parameter may also be used under the deprecated name `stripPrefix`. |
-| `rename_files` | [dict](../core/dict); default is `{}`  An optional dict specifying files to rename during the extraction. Archive entries with names exactly matching a key will be renamed to the value, prior to any directory prefix adjustment. This can be used to extract archives that contain non-Unicode filenames, or which have files that would extract to the same path on case-insensitive filesystems. |
-| `watch_archive` | [string](../core/string); default is `'auto'`  whether to [watch](#watch) the archive file. Can be the string 'yes', 'no', or 'auto'. Passing 'yes' is equivalent to immediately invoking the [`watch()`](#watch) method; passing 'no' does not attempt to watch the file; passing 'auto' will only attempt to watch the file when it is legal to do so (see `watch()` docs for more information. |
+| `archive` | [string](/versions/8.5.1/rules/lib/core/string); or [Label](/versions/8.5.1/rules/lib/builtins/Label); or [path](/versions/8.5.1/rules/lib/builtins/path); required  path to the archive that will be unpacked, relative to the repository directory. |
+| `output` | [string](/versions/8.5.1/rules/lib/core/string); or [Label](/versions/8.5.1/rules/lib/builtins/Label); or [path](/versions/8.5.1/rules/lib/builtins/path); default is `''`  path to the directory where the archive will be unpacked, relative to the repository directory. |
+| `strip_prefix` | [string](/versions/8.5.1/rules/lib/core/string); default is `''`  a directory prefix to strip from the extracted files. Many archives contain a top-level directory that contains all files in the archive. Instead of needing to specify this prefix over and over in the `build_file`, this field can be used to strip it from extracted files. For compatibility, this parameter may also be used under the deprecated name `stripPrefix`. |
+| `rename_files` | [dict](/versions/8.5.1/rules/lib/core/dict); default is `{}`  An optional dict specifying files to rename during the extraction. Archive entries with names exactly matching a key will be renamed to the value, prior to any directory prefix adjustment. This can be used to extract archives that contain non-Unicode filenames, or which have files that would extract to the same path on case-insensitive filesystems. |
+| `watch_archive` | [string](/versions/8.5.1/rules/lib/core/string); default is `'auto'`  whether to [watch](#watch) the archive file. Can be the string 'yes', 'no', or 'auto'. Passing 'yes' is equivalent to immediately invoking the [`watch()`](#watch) method; passing 'no' does not attempt to watch the file; passing 'auto' will only attempt to watch the file when it is legal to do so (see `watch()` docs for more information. |
 
 ## facts
 
@@ -131,7 +131,7 @@ Facts module_ctx.facts
 ```
 
 The JSON-like dict returned by a previous execution of this extension in the `facts`
-parameter of [`extension\_metadata`](../builtins/module\_ctx#extension\_metadata) or else
+parameter of [`extension\_metadata`](/versions/8.5.1/rules/lib/builtins/module\_ctx#extension\_metadata) or else
 `{}`.
 This is useful for extensions that want to preserve universally true facts such as the
 hashes of artifacts in an immutable repository.
@@ -150,10 +150,10 @@ Generates a file in the repository directory with the provided content.
 
 | Parameter | Description |
 | --- | --- |
-| `path` | [string](../core/string); or [Label](../builtins/Label); or [path](../builtins/path); required  Path of the file to create, relative to the repository directory. |
-| `content` | [string](../core/string); default is `''`  The content of the file to create, empty by default. |
-| `executable` | [bool](../core/bool); default is `True`  Set the executable flag on the created file, true by default. |
-| `legacy_utf8` | [bool](../core/bool); default is `False`  No-op. This parameter is deprecated and will be removed in a future version of Bazel. |
+| `path` | [string](/versions/8.5.1/rules/lib/core/string); or [Label](/versions/8.5.1/rules/lib/builtins/Label); or [path](/versions/8.5.1/rules/lib/builtins/path); required  Path of the file to create, relative to the repository directory. |
+| `content` | [string](/versions/8.5.1/rules/lib/core/string); default is `''`  The content of the file to create, empty by default. |
+| `executable` | [bool](/versions/8.5.1/rules/lib/core/bool); default is `True`  Set the executable flag on the created file, true by default. |
+| `legacy_utf8` | [bool](/versions/8.5.1/rules/lib/core/bool); default is `False`  No-op. This parameter is deprecated and will be removed in a future version of Bazel. |
 
 ## getenv
 
@@ -169,8 +169,8 @@ When building incrementally, any change to the value of the variable named by `n
 
 | Parameter | Description |
 | --- | --- |
-| `name` | [string](../core/string); required  Name of desired environment variable. |
-| `default` | [string](../core/string); or `None`; default is `None`  Default value to return if `name` is not found. |
+| `name` | [string](/versions/8.5.1/rules/lib/core/string); required  Name of desired environment variable. |
+| `default` | [string](/versions/8.5.1/rules/lib/core/string); or `None`; default is `None`  Default value to return if `name` is not found. |
 
 May return `None`.
 
@@ -180,13 +180,13 @@ May return `None`.
 bool module_ctx.is_dev_dependency(tag)
 ```
 
-Returns whether the given tag was specified on the result of a [use\_extension](../globals/module#use_extension) call with `devDependency = True`.
+Returns whether the given tag was specified on the result of a [use\_extension](/versions/8.5.1/rules/lib/globals/module#use_extension) call with `devDependency = True`.
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `tag` | bazel\_module\_tag; required  A tag obtained from [bazel\_module.tags](../builtins/bazel_module#tags). |
+| `tag` | bazel\_module\_tag; required  A tag obtained from [bazel\_module.tags](/versions/8.5.1/rules/lib/builtins/bazel_module#tags). |
 
 ## modules
 
@@ -194,7 +194,7 @@ Returns whether the given tag was specified on the result of a [use\_extension](
 list module_ctx.modules
 ```
 
-A list of all the Bazel modules in the external dependency graph that use this module extension, each of which is a [bazel\_module](../builtins/bazel_module) object that exposes all the tags it specified for this extension. The iteration order of this dictionary is guaranteed to be the same as breadth-first search starting from the root module.
+A list of all the Bazel modules in the external dependency graph that use this module extension, each of which is a [bazel\_module](/versions/8.5.1/rules/lib/builtins/bazel_module) object that exposes all the tags it specified for this extension. The iteration order of this dictionary is guaranteed to be the same as breadth-first search starting from the root module.
 
 ## os
 
@@ -216,7 +216,7 @@ Returns a path from a string, label or path. If the path is relative, it will re
 
 | Parameter | Description |
 | --- | --- |
-| `path` | [string](../core/string); or [Label](../builtins/Label); or [path](../builtins/path); required  `string`, `Label` or `path` from which to create a path from. |
+| `path` | [string](/versions/8.5.1/rules/lib/core/string); or [Label](/versions/8.5.1/rules/lib/builtins/Label); or [path](/versions/8.5.1/rules/lib/builtins/path); required  `string`, `Label` or `path` from which to create a path from. |
 
 ## read
 
@@ -230,8 +230,8 @@ Reads the content of a file on the filesystem.
 
 | Parameter | Description |
 | --- | --- |
-| `path` | [string](../core/string); or [Label](../builtins/Label); or [path](../builtins/path); required  Path of the file to read from. |
-| `watch` | [string](../core/string); default is `'auto'`  Whether to [watch](#watch) the file. Can be the string 'yes', 'no', or 'auto'. Passing 'yes' is equivalent to immediately invoking the [`watch()`](#watch) method; passing 'no' does not attempt to watch the file; passing 'auto' will only attempt to watch the file when it is legal to do so (see `watch()` docs for more information. |
+| `path` | [string](/versions/8.5.1/rules/lib/core/string); or [Label](/versions/8.5.1/rules/lib/builtins/Label); or [path](/versions/8.5.1/rules/lib/builtins/path); required  Path of the file to read from. |
+| `watch` | [string](/versions/8.5.1/rules/lib/core/string); default is `'auto'`  Whether to [watch](#watch) the file. Can be the string 'yes', 'no', or 'auto'. Passing 'yes' is equivalent to immediately invoking the [`watch()`](#watch) method; passing 'no' does not attempt to watch the file; passing 'auto' will only attempt to watch the file when it is legal to do so (see `watch()` docs for more information. |
 
 ## report\_progress
 
@@ -245,7 +245,7 @@ Updates the progress status for the fetching of this repository or module extens
 
 | Parameter | Description |
 | --- | --- |
-| `status` | [string](../core/string); default is `''`  `string` describing the current status of the fetch progress. |
+| `status` | [string](/versions/8.5.1/rules/lib/core/string); default is `''`  `string` describing the current status of the fetch progress. |
 
 ## root\_module\_has\_non\_dev\_dependency
 
@@ -263,7 +263,7 @@ None module_ctx.watch(path)
 
 Tells Bazel to watch for changes to the given path, whether or not it exists, or whether it's a file or a directory. Any changes to the file or directory will invalidate this repository or module extension, and cause it to be refetched or re-evaluated next time.
 
-"Changes" include changes to the contents of the file (if the path is a file); if the path was a file but is now a directory, or vice versa; and if the path starts or stops existing. Notably, this does *not* include changes to any files under the directory if the path is a directory. For that, use [`path.readdir()`](path#readdir) instead.
+"Changes" include changes to the contents of the file (if the path is a file); if the path was a file but is now a directory, or vice versa; and if the path starts or stops existing. Notably, this does *not* include changes to any files under the directory if the path is a directory. For that, use [`path.readdir()`](/versions/8.5.1/rules/lib/builtins/path#readdir) instead.
 
 Note that attempting to watch paths inside the repo currently being fetched, or inside the working directory of the current module extension, will result in an error. A module extension attempting to watch a path outside the current Bazel workspace will also result in an error.
 
@@ -271,7 +271,7 @@ Note that attempting to watch paths inside the repo currently being fetched, or
 
 | Parameter | Description |
 | --- | --- |
-| `path` | [string](../core/string); or [Label](../builtins/Label); or [path](../builtins/path); required  Path of the file to watch. |
+| `path` | [string](/versions/8.5.1/rules/lib/core/string); or [Label](/versions/8.5.1/rules/lib/builtins/Label); or [path](/versions/8.5.1/rules/lib/builtins/path); required  Path of the file to watch. |
 
 ## which
 
@@ -285,6 +285,6 @@ Returns the `path` of the corresponding program or `None` if there is no such pr
 
 | Parameter | Description |
 | --- | --- |
-| `program` | [string](../core/string); required  Program to find in the path. |
+| `program` | [string](/versions/8.5.1/rules/lib/core/string); required  Program to find in the path. |
 
 May return `None`.
\ No newline at end of file
diff --git a/versions/8.5.1/rules/lib/builtins/path.mdx b/versions/8.5.1/rules/lib/builtins/path.mdx
index d200110e..366f4fdf 100644
--- a/versions/8.5.1/rules/lib/builtins/path.mdx
+++ b/versions/8.5.1/rules/lib/builtins/path.mdx
@@ -77,7 +77,7 @@ Returns the list of entries in the directory denoted by this path. Each entry is
 
 | Parameter | Description |
 | --- | --- |
-| `watch` | [string](../core/string); default is `'auto'`  whether Bazel should watch the list of entries in this directory and refetch the repository or re-evaluate the module extension next time when any changes are detected. Changes to detect include entry creation, deletion, and renaming. Note that this doesn't watch the *contents* of any entries in the directory. Can be the string 'yes', 'no', or 'auto'. If set to 'auto', Bazel will only watch this directory when it is legal to do so (see [`repository_ctx.watch()`](repository_ctx#watch) docs for more information). |
+| `watch` | [string](/versions/8.5.1/rules/lib/core/string); default is `'auto'`  whether Bazel should watch the list of entries in this directory and refetch the repository or re-evaluate the module extension next time when any changes are detected. Changes to detect include entry creation, deletion, and renaming. Note that this doesn't watch the *contents* of any entries in the directory. Can be the string 'yes', 'no', or 'auto'. If set to 'auto', Bazel will only watch this directory when it is legal to do so (see [`repository_ctx.watch()`](/versions/8.5.1/rules/lib/builtins/repository_ctx#watch) docs for more information). |
 
 ## realpath
 
diff --git a/versions/8.5.1/rules/lib/builtins/repo_metadata.mdx b/versions/8.5.1/rules/lib/builtins/repo_metadata.mdx
index 0b28cbac..786c0898 100644
--- a/versions/8.5.1/rules/lib/builtins/repo_metadata.mdx
+++ b/versions/8.5.1/rules/lib/builtins/repo_metadata.mdx
@@ -2,4 +2,4 @@
 title: 'repo\_metadata'
 ---
 
-See [`repository_ctx.repo_metadata`](repository_ctx#repo_metadata).
\ No newline at end of file
+See [`repository_ctx.repo_metadata`](/versions/8.5.1/rules/lib/builtins/repository_ctx#repo_metadata).
\ No newline at end of file
diff --git a/versions/8.5.1/rules/lib/builtins/repository_ctx.mdx b/versions/8.5.1/rules/lib/builtins/repository_ctx.mdx
index 44ab0025..ad751608 100644
--- a/versions/8.5.1/rules/lib/builtins/repository_ctx.mdx
+++ b/versions/8.5.1/rules/lib/builtins/repository_ctx.mdx
@@ -50,7 +50,7 @@ Deletes a file or a directory. Returns a bool, indicating whether the file or di
 
 | Parameter | Description |
 | --- | --- |
-| `path` | [string](../core/string); or [path](../builtins/path); required  Path of the file to delete, relative to the repository directory, or absolute. Can be a path or a string. |
+| `path` | [string](/versions/8.5.1/rules/lib/core/string); or [path](/versions/8.5.1/rules/lib/builtins/path); required  Path of the file to delete, relative to the repository directory, or absolute. Can be a path or a string. |
 
 ## download
 
@@ -64,16 +64,16 @@ Downloads a file to the output path for the provided url and returns a struct co
 
 | Parameter | Description |
 | --- | --- |
-| `url` | [string](../core/string); or Iterable of [string](../core/string)s; required  List of mirror URLs referencing the same file. |
-| `output` | [string](../core/string); or [Label](../builtins/Label); or [path](../builtins/path); default is `''`  path to the output file, relative to the repository directory. |
-| `sha256` | [string](../core/string); default is `''`  The expected SHA-256 hash of the file downloaded. This must match the SHA-256 hash of the file downloaded. It is a security risk to omit the SHA-256 as remote files can change. At best omitting this field will make your build non-hermetic. It is optional to make development easier but should be set before shipping. If provided, the repository cache will first be checked for a file with the given hash; a download will only be attempted if the file was not found in the cache. After a successful download, the file will be added to the cache. |
-| `executable` | [bool](../core/bool); default is `False`  Set the executable flag on the created file, false by default. |
-| `allow_fail` | [bool](../core/bool); default is `False`  If set, indicate the error in the return value instead of raising an error for failed downloads. |
-| `canonical_id` | [string](../core/string); default is `''`  If set, restrict cache hits to those cases where the file was added to the cache with the same canonical id. By default caching uses the checksum (`sha256` or `integrity`). |
-| `auth` | [dict](../core/dict); default is `{}`  An optional dict specifying authentication information for some of the URLs. |
-| `headers` | [dict](../core/dict); default is `{}`  An optional dict specifying http headers for all URLs. |
-| `integrity` | [string](../core/string); default is `''`  Expected checksum of the file downloaded, in Subresource Integrity format. This must match the checksum of the file downloaded. It is a security risk to omit the checksum as remote files can change. At best omitting this field will make your build non-hermetic. It is optional to make development easier but should be set before shipping. If provided, the repository cache will first be checked for a file with the given checksum; a download will only be attempted if the file was not found in the cache. After a successful download, the file will be added to the cache. |
-| `block` | [bool](../core/bool); default is `True`  If set to false, the call returns immediately and instead of the regular return value, it returns a token with one single method, wait(), which blocks until the download is finished and returns the usual return value or throws as usual. |
+| `url` | [string](/versions/8.5.1/rules/lib/core/string); or Iterable of [string](/versions/8.5.1/rules/lib/core/string)s; required  List of mirror URLs referencing the same file. |
+| `output` | [string](/versions/8.5.1/rules/lib/core/string); or [Label](/versions/8.5.1/rules/lib/builtins/Label); or [path](/versions/8.5.1/rules/lib/builtins/path); default is `''`  path to the output file, relative to the repository directory. |
+| `sha256` | [string](/versions/8.5.1/rules/lib/core/string); default is `''`  The expected SHA-256 hash of the file downloaded. This must match the SHA-256 hash of the file downloaded. It is a security risk to omit the SHA-256 as remote files can change. At best omitting this field will make your build non-hermetic. It is optional to make development easier but should be set before shipping. If provided, the repository cache will first be checked for a file with the given hash; a download will only be attempted if the file was not found in the cache. After a successful download, the file will be added to the cache. |
+| `executable` | [bool](/versions/8.5.1/rules/lib/core/bool); default is `False`  Set the executable flag on the created file, false by default. |
+| `allow_fail` | [bool](/versions/8.5.1/rules/lib/core/bool); default is `False`  If set, indicate the error in the return value instead of raising an error for failed downloads. |
+| `canonical_id` | [string](/versions/8.5.1/rules/lib/core/string); default is `''`  If set, restrict cache hits to those cases where the file was added to the cache with the same canonical id. By default caching uses the checksum (`sha256` or `integrity`). |
+| `auth` | [dict](/versions/8.5.1/rules/lib/core/dict); default is `{}`  An optional dict specifying authentication information for some of the URLs. |
+| `headers` | [dict](/versions/8.5.1/rules/lib/core/dict); default is `{}`  An optional dict specifying http headers for all URLs. |
+| `integrity` | [string](/versions/8.5.1/rules/lib/core/string); default is `''`  Expected checksum of the file downloaded, in Subresource Integrity format. This must match the checksum of the file downloaded. It is a security risk to omit the checksum as remote files can change. At best omitting this field will make your build non-hermetic. It is optional to make development easier but should be set before shipping. If provided, the repository cache will first be checked for a file with the given checksum; a download will only be attempted if the file was not found in the cache. After a successful download, the file will be added to the cache. |
+| `block` | [bool](/versions/8.5.1/rules/lib/core/bool); default is `True`  If set to false, the call returns immediately and instead of the regular return value, it returns a token with one single method, wait(), which blocks until the download is finished and returns the usual return value or throws as usual. |
 
 ## download\_and\_extract
 
@@ -87,17 +87,17 @@ Downloads a file to the output path for the provided url, extracts it, and retur
 
 | Parameter | Description |
 | --- | --- |
-| `url` | [string](../core/string); or Iterable of [string](../core/string)s; required  List of mirror URLs referencing the same file. |
-| `output` | [string](../core/string); or [Label](../builtins/Label); or [path](../builtins/path); default is `''`  Path to the directory where the archive will be unpacked, relative to the repository directory. |
-| `sha256` | [string](../core/string); default is `''`  The expected SHA-256 hash of the file downloaded. This must match the SHA-256 hash of the file downloaded. It is a security risk to omit the SHA-256 as remote files can change. At best omitting this field will make your build non-hermetic. It is optional to make development easier but should be set before shipping. If provided, the repository cache will first be checked for a file with the given hash; a download will only be attempted if the file was not found in the cache. After a successful download, the file will be added to the cache. |
-| `type` | [string](../core/string); default is `''`  The archive type of the downloaded file. By default, the archive type is determined from the file extension of the URL. If the file has no extension, you can explicitly specify either "zip", "jar", "war", "aar", "nupkg", "whl", "tar", "tar.gz", "tgz", "tar.xz", "txz", ".tar.zst", ".tzst", "tar.bz2", ".tbz", ".ar", or ".deb" here. |
-| `strip_prefix` | [string](../core/string); default is `''`  A directory prefix to strip from the extracted files. Many archives contain a top-level directory that contains all files in the archive. Instead of needing to specify this prefix over and over in the `build_file`, this field can be used to strip it from extracted files. For compatibility, this parameter may also be used under the deprecated name `stripPrefix`. |
-| `allow_fail` | [bool](../core/bool); default is `False`  If set, indicate the error in the return value instead of raising an error for failed downloads. |
-| `canonical_id` | [string](../core/string); default is `''`  If set, restrict cache hits to those cases where the file was added to the cache with the same canonical id. By default caching uses the checksum" (`sha256` or `integrity`). |
-| `auth` | [dict](../core/dict); default is `{}`  An optional dict specifying authentication information for some of the URLs. |
-| `headers` | [dict](../core/dict); default is `{}`  An optional dict specifying http headers for all URLs. |
-| `integrity` | [string](../core/string); default is `''`  Expected checksum of the file downloaded, in Subresource Integrity format. This must match the checksum of the file downloaded. It is a security risk to omit the checksum as remote files can change. At best omitting this field will make your build non-hermetic. It is optional to make development easier but should be set before shipping. If provided, the repository cache will first be checked for a file with the given checksum; a download will only be attempted if the file was not found in the cache. After a successful download, the file will be added to the cache. |
-| `rename_files` | [dict](../core/dict); default is `{}`  An optional dict specifying files to rename during the extraction. Archive entries with names exactly matching a key will be renamed to the value, prior to any directory prefix adjustment. This can be used to extract archives that contain non-Unicode filenames, or which have files that would extract to the same path on case-insensitive filesystems. |
+| `url` | [string](/versions/8.5.1/rules/lib/core/string); or Iterable of [string](/versions/8.5.1/rules/lib/core/string)s; required  List of mirror URLs referencing the same file. |
+| `output` | [string](/versions/8.5.1/rules/lib/core/string); or [Label](/versions/8.5.1/rules/lib/builtins/Label); or [path](/versions/8.5.1/rules/lib/builtins/path); default is `''`  Path to the directory where the archive will be unpacked, relative to the repository directory. |
+| `sha256` | [string](/versions/8.5.1/rules/lib/core/string); default is `''`  The expected SHA-256 hash of the file downloaded. This must match the SHA-256 hash of the file downloaded. It is a security risk to omit the SHA-256 as remote files can change. At best omitting this field will make your build non-hermetic. It is optional to make development easier but should be set before shipping. If provided, the repository cache will first be checked for a file with the given hash; a download will only be attempted if the file was not found in the cache. After a successful download, the file will be added to the cache. |
+| `type` | [string](/versions/8.5.1/rules/lib/core/string); default is `''`  The archive type of the downloaded file. By default, the archive type is determined from the file extension of the URL. If the file has no extension, you can explicitly specify either "zip", "jar", "war", "aar", "nupkg", "whl", "tar", "tar.gz", "tgz", "tar.xz", "txz", ".tar.zst", ".tzst", "tar.bz2", ".tbz", ".ar", or ".deb" here. |
+| `strip_prefix` | [string](/versions/8.5.1/rules/lib/core/string); default is `''`  A directory prefix to strip from the extracted files. Many archives contain a top-level directory that contains all files in the archive. Instead of needing to specify this prefix over and over in the `build_file`, this field can be used to strip it from extracted files. For compatibility, this parameter may also be used under the deprecated name `stripPrefix`. |
+| `allow_fail` | [bool](/versions/8.5.1/rules/lib/core/bool); default is `False`  If set, indicate the error in the return value instead of raising an error for failed downloads. |
+| `canonical_id` | [string](/versions/8.5.1/rules/lib/core/string); default is `''`  If set, restrict cache hits to those cases where the file was added to the cache with the same canonical id. By default caching uses the checksum" (`sha256` or `integrity`). |
+| `auth` | [dict](/versions/8.5.1/rules/lib/core/dict); default is `{}`  An optional dict specifying authentication information for some of the URLs. |
+| `headers` | [dict](/versions/8.5.1/rules/lib/core/dict); default is `{}`  An optional dict specifying http headers for all URLs. |
+| `integrity` | [string](/versions/8.5.1/rules/lib/core/string); default is `''`  Expected checksum of the file downloaded, in Subresource Integrity format. This must match the checksum of the file downloaded. It is a security risk to omit the checksum as remote files can change. At best omitting this field will make your build non-hermetic. It is optional to make development easier but should be set before shipping. If provided, the repository cache will first be checked for a file with the given checksum; a download will only be attempted if the file was not found in the cache. After a successful download, the file will be added to the cache. |
+| `rename_files` | [dict](/versions/8.5.1/rules/lib/core/dict); default is `{}`  An optional dict specifying files to rename during the extraction. Archive entries with names exactly matching a key will be renamed to the value, prior to any directory prefix adjustment. This can be used to extract archives that contain non-Unicode filenames, or which have files that would extract to the same path on case-insensitive filesystems. |
 
 ## execute
 
@@ -111,11 +111,11 @@ Executes the command given by the list of arguments. The execution time of the c
 
 | Parameter | Description |
 | --- | --- |
-| `arguments` | [sequence](../core/list); required  List of arguments, the first element should be the path to the program to execute. |
-| `timeout` | [int](../core/int); default is `600`  Maximum duration of the command in seconds (default is 600 seconds). |
-| `environment` | [dict](../core/dict); default is `{}`  Force some environment variables to be set to be passed to the process. The value can be `None` to remove the environment variable. |
-| `quiet` | [bool](../core/bool); default is `True`  If stdout and stderr should be printed to the terminal. |
-| `working_directory` | [string](../core/string); default is `""`  Working directory for command execution. Can be relative to the repository root or absolute. The default is the repository root. |
+| `arguments` | [sequence](/versions/8.5.1/rules/lib/core/list); required  List of arguments, the first element should be the path to the program to execute. |
+| `timeout` | [int](/versions/8.5.1/rules/lib/core/int); default is `600`  Maximum duration of the command in seconds (default is 600 seconds). |
+| `environment` | [dict](/versions/8.5.1/rules/lib/core/dict); default is `{}`  Force some environment variables to be set to be passed to the process. The value can be `None` to remove the environment variable. |
+| `quiet` | [bool](/versions/8.5.1/rules/lib/core/bool); default is `True`  If stdout and stderr should be printed to the terminal. |
+| `working_directory` | [string](/versions/8.5.1/rules/lib/core/string); default is `""`  Working directory for command execution. Can be relative to the repository root or absolute. The default is the repository root. |
 
 ## extract
 
@@ -129,11 +129,11 @@ Extract an archive to the repository directory.
 
 | Parameter | Description |
 | --- | --- |
-| `archive` | [string](../core/string); or [Label](../builtins/Label); or [path](../builtins/path); required  path to the archive that will be unpacked, relative to the repository directory. |
-| `output` | [string](../core/string); or [Label](../builtins/Label); or [path](../builtins/path); default is `''`  path to the directory where the archive will be unpacked, relative to the repository directory. |
-| `strip_prefix` | [string](../core/string); default is `''`  a directory prefix to strip from the extracted files. Many archives contain a top-level directory that contains all files in the archive. Instead of needing to specify this prefix over and over in the `build_file`, this field can be used to strip it from extracted files. For compatibility, this parameter may also be used under the deprecated name `stripPrefix`. |
-| `rename_files` | [dict](../core/dict); default is `{}`  An optional dict specifying files to rename during the extraction. Archive entries with names exactly matching a key will be renamed to the value, prior to any directory prefix adjustment. This can be used to extract archives that contain non-Unicode filenames, or which have files that would extract to the same path on case-insensitive filesystems. |
-| `watch_archive` | [string](../core/string); default is `'auto'`  whether to [watch](#watch) the archive file. Can be the string 'yes', 'no', or 'auto'. Passing 'yes' is equivalent to immediately invoking the [`watch()`](#watch) method; passing 'no' does not attempt to watch the file; passing 'auto' will only attempt to watch the file when it is legal to do so (see `watch()` docs for more information. |
+| `archive` | [string](/versions/8.5.1/rules/lib/core/string); or [Label](/versions/8.5.1/rules/lib/builtins/Label); or [path](/versions/8.5.1/rules/lib/builtins/path); required  path to the archive that will be unpacked, relative to the repository directory. |
+| `output` | [string](/versions/8.5.1/rules/lib/core/string); or [Label](/versions/8.5.1/rules/lib/builtins/Label); or [path](/versions/8.5.1/rules/lib/builtins/path); default is `''`  path to the directory where the archive will be unpacked, relative to the repository directory. |
+| `strip_prefix` | [string](/versions/8.5.1/rules/lib/core/string); default is `''`  a directory prefix to strip from the extracted files. Many archives contain a top-level directory that contains all files in the archive. Instead of needing to specify this prefix over and over in the `build_file`, this field can be used to strip it from extracted files. For compatibility, this parameter may also be used under the deprecated name `stripPrefix`. |
+| `rename_files` | [dict](/versions/8.5.1/rules/lib/core/dict); default is `{}`  An optional dict specifying files to rename during the extraction. Archive entries with names exactly matching a key will be renamed to the value, prior to any directory prefix adjustment. This can be used to extract archives that contain non-Unicode filenames, or which have files that would extract to the same path on case-insensitive filesystems. |
+| `watch_archive` | [string](/versions/8.5.1/rules/lib/core/string); default is `'auto'`  whether to [watch](#watch) the archive file. Can be the string 'yes', 'no', or 'auto'. Passing 'yes' is equivalent to immediately invoking the [`watch()`](#watch) method; passing 'no' does not attempt to watch the file; passing 'auto' will only attempt to watch the file when it is legal to do so (see `watch()` docs for more information. |
 
 ## file
 
@@ -147,10 +147,10 @@ Generates a file in the repository directory with the provided content.
 
 | Parameter | Description |
 | --- | --- |
-| `path` | [string](../core/string); or [Label](../builtins/Label); or [path](../builtins/path); required  Path of the file to create, relative to the repository directory. |
-| `content` | [string](../core/string); default is `''`  The content of the file to create, empty by default. |
-| `executable` | [bool](../core/bool); default is `True`  Set the executable flag on the created file, true by default. |
-| `legacy_utf8` | [bool](../core/bool); default is `False`  No-op. This parameter is deprecated and will be removed in a future version of Bazel. |
+| `path` | [string](/versions/8.5.1/rules/lib/core/string); or [Label](/versions/8.5.1/rules/lib/builtins/Label); or [path](/versions/8.5.1/rules/lib/builtins/path); required  Path of the file to create, relative to the repository directory. |
+| `content` | [string](/versions/8.5.1/rules/lib/core/string); default is `''`  The content of the file to create, empty by default. |
+| `executable` | [bool](/versions/8.5.1/rules/lib/core/bool); default is `True`  Set the executable flag on the created file, true by default. |
+| `legacy_utf8` | [bool](/versions/8.5.1/rules/lib/core/bool); default is `False`  No-op. This parameter is deprecated and will be removed in a future version of Bazel. |
 
 ## getenv
 
@@ -166,8 +166,8 @@ When building incrementally, any change to the value of the variable named by `n
 
 | Parameter | Description |
 | --- | --- |
-| `name` | [string](../core/string); required  Name of desired environment variable. |
-| `default` | [string](../core/string); or `None`; default is `None`  Default value to return if `name` is not found. |
+| `name` | [string](/versions/8.5.1/rules/lib/core/string); required  Name of desired environment variable. |
+| `default` | [string](/versions/8.5.1/rules/lib/core/string); or `None`; default is `None`  Default value to return if `name` is not found. |
 
 May return `None`.
 
@@ -207,9 +207,9 @@ Apply a patch file to the root directory of external repository. The patch file
 
 | Parameter | Description |
 | --- | --- |
-| `patch_file` | [string](../core/string); or [Label](../builtins/Label); or [path](../builtins/path); required  The patch file to apply, it can be label, relative path or absolute path. If it's a relative path, it will resolve to the repository directory. |
-| `strip` | [int](../core/int); default is `0`  Strip the specified number of leading components from file names. |
-| `watch_patch` | [string](../core/string); default is `'auto'`  Whether to [watch](#watch) the patch file. Can be the string 'yes', 'no', or 'auto'. Passing 'yes' is equivalent to immediately invoking the [`watch()`](#watch) method; passing 'no' does not attempt to watch the file; passing 'auto' will only attempt to watch the file when it is legal to do so (see `watch()` docs for more information. |
+| `patch_file` | [string](/versions/8.5.1/rules/lib/core/string); or [Label](/versions/8.5.1/rules/lib/builtins/Label); or [path](/versions/8.5.1/rules/lib/builtins/path); required  The patch file to apply, it can be label, relative path or absolute path. If it's a relative path, it will resolve to the repository directory. |
+| `strip` | [int](/versions/8.5.1/rules/lib/core/int); default is `0`  Strip the specified number of leading components from file names. |
+| `watch_patch` | [string](/versions/8.5.1/rules/lib/core/string); default is `'auto'`  Whether to [watch](#watch) the patch file. Can be the string 'yes', 'no', or 'auto'. Passing 'yes' is equivalent to immediately invoking the [`watch()`](#watch) method; passing 'no' does not attempt to watch the file; passing 'auto' will only attempt to watch the file when it is legal to do so (see `watch()` docs for more information. |
 
 ## path
 
@@ -223,7 +223,7 @@ Returns a path from a string, label or path. If the path is relative, it will re
 
 | Parameter | Description |
 | --- | --- |
-| `path` | [string](../core/string); or [Label](../builtins/Label); or [path](../builtins/path); required  `string`, `Label` or `path` from which to create a path from. |
+| `path` | [string](/versions/8.5.1/rules/lib/core/string); or [Label](/versions/8.5.1/rules/lib/builtins/Label); or [path](/versions/8.5.1/rules/lib/builtins/path); required  `string`, `Label` or `path` from which to create a path from. |
 
 ## read
 
@@ -237,8 +237,8 @@ Reads the content of a file on the filesystem.
 
 | Parameter | Description |
 | --- | --- |
-| `path` | [string](../core/string); or [Label](../builtins/Label); or [path](../builtins/path); required  Path of the file to read from. |
-| `watch` | [string](../core/string); default is `'auto'`  Whether to [watch](#watch) the file. Can be the string 'yes', 'no', or 'auto'. Passing 'yes' is equivalent to immediately invoking the [`watch()`](#watch) method; passing 'no' does not attempt to watch the file; passing 'auto' will only attempt to watch the file when it is legal to do so (see `watch()` docs for more information. |
+| `path` | [string](/versions/8.5.1/rules/lib/core/string); or [Label](/versions/8.5.1/rules/lib/builtins/Label); or [path](/versions/8.5.1/rules/lib/builtins/path); required  Path of the file to read from. |
+| `watch` | [string](/versions/8.5.1/rules/lib/core/string); default is `'auto'`  Whether to [watch](#watch) the file. Can be the string 'yes', 'no', or 'auto'. Passing 'yes' is equivalent to immediately invoking the [`watch()`](#watch) method; passing 'no' does not attempt to watch the file; passing 'auto' will only attempt to watch the file when it is legal to do so (see `watch()` docs for more information. |
 
 ## rename
 
@@ -253,8 +253,8 @@ already exists. Both paths must be located within the repository.
 
 | Parameter | Description |
 | --- | --- |
-| `src` | [string](../core/string); or [Label](../builtins/Label); or [path](../builtins/path); required  The path of the existing file or directory to rename, relative to the repository directory. |
-| `dst` | [string](../core/string); or [Label](../builtins/Label); or [path](../builtins/path); required  The new name to which the file or directory will be renamed to, relative to the repository directory. |
+| `src` | [string](/versions/8.5.1/rules/lib/core/string); or [Label](/versions/8.5.1/rules/lib/builtins/Label); or [path](/versions/8.5.1/rules/lib/builtins/path); required  The path of the existing file or directory to rename, relative to the repository directory. |
+| `dst` | [string](/versions/8.5.1/rules/lib/core/string); or [Label](/versions/8.5.1/rules/lib/builtins/Label); or [path](/versions/8.5.1/rules/lib/builtins/path); required  The new name to which the file or directory will be renamed to, relative to the repository directory. |
 
 ## repo\_metadata
 
@@ -268,8 +268,8 @@ Constructs an opaque object that can be returned from the repo rule's implementa
 
 | Parameter | Description |
 | --- | --- |
-| `reproducible` | [bool](../core/bool); default is `False`  States that this repo can be reproducibly refetched; that is, if it were fetched another time with exactly the same input attributes, repo rule definition, watched files and environment variables, etc., then exactly the same output would be produced. This property needs to hold even if other untracked conditions change, such as information from the internet, the path of the workspace root, output from running arbitrary executables, etc. If set to True, this allows the fetched repo contents to be cached across workspaces. Note that setting this to True does not guarantee caching in the repo contents cache; for example, local repo rules are never cached. |
-| `attrs_for_reproducibility` | [dict](../core/dict); default is `{}`  If `reproducible` is False, this can be specified to tell Bazel which attributes of the original repo rule to change to make it reproducible. |
+| `reproducible` | [bool](/versions/8.5.1/rules/lib/core/bool); default is `False`  States that this repo can be reproducibly refetched; that is, if it were fetched another time with exactly the same input attributes, repo rule definition, watched files and environment variables, etc., then exactly the same output would be produced. This property needs to hold even if other untracked conditions change, such as information from the internet, the path of the workspace root, output from running arbitrary executables, etc. If set to True, this allows the fetched repo contents to be cached across workspaces. Note that setting this to True does not guarantee caching in the repo contents cache; for example, local repo rules are never cached. |
+| `attrs_for_reproducibility` | [dict](/versions/8.5.1/rules/lib/core/dict); default is `{}`  If `reproducible` is False, this can be specified to tell Bazel which attributes of the original repo rule to change to make it reproducible. |
 
 ## report\_progress
 
@@ -283,7 +283,7 @@ Updates the progress status for the fetching of this repository or module extens
 
 | Parameter | Description |
 | --- | --- |
-| `status` | [string](../core/string); default is `''`  `string` describing the current status of the fetch progress. |
+| `status` | [string](/versions/8.5.1/rules/lib/core/string); default is `''`  `string` describing the current status of the fetch progress. |
 
 ## symlink
 
@@ -297,8 +297,8 @@ Creates a symlink on the filesystem.
 
 | Parameter | Description |
 | --- | --- |
-| `target` | [string](../core/string); or [Label](../builtins/Label); or [path](../builtins/path); required  The path that the symlink should point to. |
-| `link_name` | [string](../core/string); or [Label](../builtins/Label); or [path](../builtins/path); required  The path of the symlink to create. |
+| `target` | [string](/versions/8.5.1/rules/lib/core/string); or [Label](/versions/8.5.1/rules/lib/builtins/Label); or [path](/versions/8.5.1/rules/lib/builtins/path); required  The path that the symlink should point to. |
+| `link_name` | [string](/versions/8.5.1/rules/lib/core/string); or [Label](/versions/8.5.1/rules/lib/builtins/Label); or [path](/versions/8.5.1/rules/lib/builtins/path); required  The path of the symlink to create. |
 
 ## template
 
@@ -312,11 +312,11 @@ Generates a new file using a `template`. Every occurrence in `template` of a key
 
 | Parameter | Description |
 | --- | --- |
-| `path` | [string](../core/string); or [Label](../builtins/Label); or [path](../builtins/path); required  Path of the file to create, relative to the repository directory. |
-| `template` | [string](../core/string); or [Label](../builtins/Label); or [path](../builtins/path); required  Path to the template file. |
-| `substitutions` | [dict](../core/dict); default is `{}`  Substitutions to make when expanding the template. |
-| `executable` | [bool](../core/bool); default is `True`  Set the executable flag on the created file, true by default. |
-| `watch_template` | [string](../core/string); default is `'auto'`  Whether to [watch](#watch) the template file. Can be the string 'yes', 'no', or 'auto'. Passing 'yes' is equivalent to immediately invoking the [`watch()`](#watch) method; passing 'no' does not attempt to watch the file; passing 'auto' will only attempt to watch the file when it is legal to do so (see `watch()` docs for more information. |
+| `path` | [string](/versions/8.5.1/rules/lib/core/string); or [Label](/versions/8.5.1/rules/lib/builtins/Label); or [path](/versions/8.5.1/rules/lib/builtins/path); required  Path of the file to create, relative to the repository directory. |
+| `template` | [string](/versions/8.5.1/rules/lib/core/string); or [Label](/versions/8.5.1/rules/lib/builtins/Label); or [path](/versions/8.5.1/rules/lib/builtins/path); required  Path to the template file. |
+| `substitutions` | [dict](/versions/8.5.1/rules/lib/core/dict); default is `{}`  Substitutions to make when expanding the template. |
+| `executable` | [bool](/versions/8.5.1/rules/lib/core/bool); default is `True`  Set the executable flag on the created file, true by default. |
+| `watch_template` | [string](/versions/8.5.1/rules/lib/core/string); default is `'auto'`  Whether to [watch](#watch) the template file. Can be the string 'yes', 'no', or 'auto'. Passing 'yes' is equivalent to immediately invoking the [`watch()`](#watch) method; passing 'no' does not attempt to watch the file; passing 'auto' will only attempt to watch the file when it is legal to do so (see `watch()` docs for more information. |
 
 ## watch
 
@@ -326,7 +326,7 @@ None repository_ctx.watch(path)
 
 Tells Bazel to watch for changes to the given path, whether or not it exists, or whether it's a file or a directory. Any changes to the file or directory will invalidate this repository or module extension, and cause it to be refetched or re-evaluated next time.
 
-"Changes" include changes to the contents of the file (if the path is a file); if the path was a file but is now a directory, or vice versa; and if the path starts or stops existing. Notably, this does *not* include changes to any files under the directory if the path is a directory. For that, use [`path.readdir()`](path#readdir) instead.
+"Changes" include changes to the contents of the file (if the path is a file); if the path was a file but is now a directory, or vice versa; and if the path starts or stops existing. Notably, this does *not* include changes to any files under the directory if the path is a directory. For that, use [`path.readdir()`](/versions/8.5.1/rules/lib/builtins/path#readdir) instead.
 
 Note that attempting to watch paths inside the repo currently being fetched, or inside the working directory of the current module extension, will result in an error. A module extension attempting to watch a path outside the current Bazel workspace will also result in an error.
 
@@ -334,7 +334,7 @@ Note that attempting to watch paths inside the repo currently being fetched, or
 
 | Parameter | Description |
 | --- | --- |
-| `path` | [string](../core/string); or [Label](../builtins/Label); or [path](../builtins/path); required  Path of the file to watch. |
+| `path` | [string](/versions/8.5.1/rules/lib/core/string); or [Label](/versions/8.5.1/rules/lib/builtins/Label); or [path](/versions/8.5.1/rules/lib/builtins/path); required  Path of the file to watch. |
 
 ## watch\_tree
 
@@ -350,7 +350,7 @@ Note that attempting to watch paths inside the repo currently being fetched will
 
 | Parameter | Description |
 | --- | --- |
-| `path` | [string](../core/string); or [Label](../builtins/Label); or [path](../builtins/path); required  Path of the directory tree to watch. |
+| `path` | [string](/versions/8.5.1/rules/lib/core/string); or [Label](/versions/8.5.1/rules/lib/builtins/Label); or [path](/versions/8.5.1/rules/lib/builtins/path); required  Path of the directory tree to watch. |
 
 ## which
 
@@ -364,7 +364,7 @@ Returns the `path` of the corresponding program or `None` if there is no such pr
 
 | Parameter | Description |
 | --- | --- |
-| `program` | [string](../core/string); required  Program to find in the path. |
+| `program` | [string](/versions/8.5.1/rules/lib/core/string); required  Program to find in the path. |
 
 May return `None`.
 
diff --git a/versions/8.5.1/rules/lib/builtins/repository_rule.mdx b/versions/8.5.1/rules/lib/builtins/repository_rule.mdx
index ef5dac59..6d42e523 100644
--- a/versions/8.5.1/rules/lib/builtins/repository_rule.mdx
+++ b/versions/8.5.1/rules/lib/builtins/repository_rule.mdx
@@ -2,4 +2,4 @@
 title: 'repository\_rule'
 ---
 
-A callable value that may be invoked during evaluation of the WORKSPACE file or within the implementation function of a module extension to instantiate and return a repository rule. Created by [`repository_rule()`](../globals/bzl#repository_rule).
\ No newline at end of file
+A callable value that may be invoked during evaluation of the WORKSPACE file or within the implementation function of a module extension to instantiate and return a repository rule. Created by [`repository_rule()`](/versions/8.5.1/rules/lib/globals/bzl#repository_rule).
\ No newline at end of file
diff --git a/versions/8.5.1/rules/lib/builtins/rule.mdx b/versions/8.5.1/rules/lib/builtins/rule.mdx
index a240899f..1515baad 100644
--- a/versions/8.5.1/rules/lib/builtins/rule.mdx
+++ b/versions/8.5.1/rules/lib/builtins/rule.mdx
@@ -3,7 +3,7 @@ title: 'rule'
 ---
 
 A callable value representing the type of a native or Starlark rule (created by
-[`rule()`](../globals/bzl#rule)). Calling the value during
+[`rule()`](/versions/8.5.1/rules/lib/globals/bzl#rule)). Calling the value during
 evaluation of a package's BUILD file creates an instance of the rule and adds it to the
 package's target set. For more information, visit this page about
 [Rules](https://bazel.build/versions/8.5.1/extending/rules).
\ No newline at end of file
diff --git a/versions/8.5.1/rules/lib/builtins/rule_attributes.mdx b/versions/8.5.1/rules/lib/builtins/rule_attributes.mdx
index 5e85f75f..f9fcd814 100644
--- a/versions/8.5.1/rules/lib/builtins/rule_attributes.mdx
+++ b/versions/8.5.1/rules/lib/builtins/rule_attributes.mdx
@@ -20,7 +20,7 @@ Information about attributes of a rule an aspect is applied to.
 struct rule_attributes.attr
 ```
 
-A struct to access the values of the [attributes](https://bazel.build/versions/8.5.1/extending/rules#attributes). The values are provided by the user (if not, a default value is used). The attributes of the struct and the types of their values correspond to the keys and values of the [`attrs` dict](../globals/bzl#rule.attrs) provided to the [`rule` function](../globals/bzl#rule). [See example of use](https://github.com/bazelbuild/examples/blob/main/rules/attributes/printer.bzl).
+A struct to access the values of the [attributes](https://bazel.build/versions/8.5.1/extending/rules#attributes). The values are provided by the user (if not, a default value is used). The attributes of the struct and the types of their values correspond to the keys and values of the [`attrs` dict](/versions/8.5.1/rules/lib/globals/bzl#rule.attrs) provided to the [`rule` function](/versions/8.5.1/rules/lib/globals/bzl#rule). [See example of use](https://github.com/bazelbuild/examples/blob/main/rules/attributes/printer.bzl).
 
 ## exec\_groups
 
@@ -36,7 +36,7 @@ A collection of the execution groups available for the rule the aspect is applie
 struct rule_attributes.executable
 ```
 
-A `struct` containing executable files defined in [label type attributes](../toplevel/attr#label) marked as [`executable=True`](../toplevel/attr#label.executable). The struct fields correspond to the attribute names. Each value in the struct is either a [`File`](../builtins/File) or `None`. If an optional attribute is not specified in the rule then the corresponding struct value is `None`. If a label type is not marked as `executable=True`, no corresponding struct field is generated. [See example of use](https://github.com/bazelbuild/examples/blob/main/rules/actions_run/execute.bzl).
+A `struct` containing executable files defined in [label type attributes](/versions/8.5.1/rules/lib/toplevel/attr#label) marked as [`executable=True`](/versions/8.5.1/rules/lib/toplevel/attr#label.executable). The struct fields correspond to the attribute names. Each value in the struct is either a [`File`](/versions/8.5.1/rules/lib/builtins/File) or `None`. If an optional attribute is not specified in the rule then the corresponding struct value is `None`. If a label type is not marked as `executable=True`, no corresponding struct field is generated. [See example of use](https://github.com/bazelbuild/examples/blob/main/rules/actions_run/execute.bzl).
 
 ## file
 
@@ -44,7 +44,7 @@ A `struct` containing executable files defined in [label type attributes](../top
 struct rule_attributes.file
 ```
 
-A `struct` containing files defined in [label type attributes](../toplevel/attr#label) marked as [`allow_single_file`](../toplevel/attr#label.allow_single_file). The struct fields correspond to the attribute names. The struct value is always a [`File`](../builtins/File) or `None`. If an optional attribute is not specified in the rule then the corresponding struct value is `None`. If a label type is not marked as `allow_single_file`, no corresponding struct field is generated. It is a shortcut for:
+A `struct` containing files defined in [label type attributes](/versions/8.5.1/rules/lib/toplevel/attr#label) marked as [`allow_single_file`](/versions/8.5.1/rules/lib/toplevel/attr#label.allow_single_file). The struct fields correspond to the attribute names. The struct value is always a [`File`](/versions/8.5.1/rules/lib/builtins/File) or `None`. If an optional attribute is not specified in the rule then the corresponding struct value is `None`. If a label type is not marked as `allow_single_file`, no corresponding struct field is generated. It is a shortcut for:
 
 ```
 list(ctx.attr..files)[0]
@@ -58,7 +58,7 @@ In other words, use `file` to access the (singular) [default output](https://baz
 struct rule_attributes.files
 ```
 
-A `struct` containing files defined in [label](../toplevel/attr#label) or [label list](../toplevel/attr#label_list) type attributes. The struct fields correspond to the attribute names. The struct values are `list` of [`File`](../builtins/File)s. It is a shortcut for:
+A `struct` containing files defined in [label](/versions/8.5.1/rules/lib/toplevel/attr#label) or [label list](/versions/8.5.1/rules/lib/toplevel/attr#label_list) type attributes. The struct fields correspond to the attribute names. The struct values are `list` of [`File`](/versions/8.5.1/rules/lib/builtins/File)s. It is a shortcut for:
 
 ```
 [f for t in ctx.attr. for f in t.files]
diff --git a/versions/8.5.1/rules/lib/builtins/runfiles.mdx b/versions/8.5.1/rules/lib/builtins/runfiles.mdx
index ff13afbc..9c2bac52 100644
--- a/versions/8.5.1/rules/lib/builtins/runfiles.mdx
+++ b/versions/8.5.1/rules/lib/builtins/runfiles.mdx
@@ -2,7 +2,7 @@
 title: 'runfiles'
 ---
 
-A container of information regarding a set of files required at runtime execution. This object should be passed via [DefaultInfo](../providers/DefaultInfo) in order to tell the build system about the runfiles needed by the outputs produced by the rule.
+A container of information regarding a set of files required at runtime execution. This object should be passed via [DefaultInfo](/versions/8.5.1/rules/lib/providers/DefaultInfo) in order to tell the build system about the runfiles needed by the outputs produced by the rule.
 
 See [runfiles guide](https://bazel.build/versions/8.5.1/extending/rules#runfiles) for details.
 
@@ -45,7 +45,7 @@ Returns a new runfiles object that includes all the contents of this one and the
 
 | Parameter | Description |
 | --- | --- |
-| `other` | [runfiles](../builtins/runfiles); required  The runfiles object to merge into this. |
+| `other` | [runfiles](/versions/8.5.1/rules/lib/builtins/runfiles); required  The runfiles object to merge into this. |
 
 ## merge\_all
 
@@ -59,7 +59,7 @@ Returns a new runfiles object that includes all the contents of this one and of
 
 | Parameter | Description |
 | --- | --- |
-| `other` | [sequence](../core/list) of [runfiles](../builtins/runfiles)s; required  The sequence of runfiles objects to merge into this. |
+| `other` | [sequence](/versions/8.5.1/rules/lib/core/list) of [runfiles](/versions/8.5.1/rules/lib/builtins/runfiles)s; required  The sequence of runfiles objects to merge into this. |
 
 ## root\_symlinks
 
diff --git a/versions/8.5.1/rules/lib/builtins/tag_class.mdx b/versions/8.5.1/rules/lib/builtins/tag_class.mdx
index 7d4349d0..c16d564c 100644
--- a/versions/8.5.1/rules/lib/builtins/tag_class.mdx
+++ b/versions/8.5.1/rules/lib/builtins/tag_class.mdx
@@ -2,4 +2,4 @@
 title: 'tag\_class'
 ---
 
-Defines a schema of attributes for a tag, created by [`tag_class()`](../globals/bzl#tag_class).
\ No newline at end of file
+Defines a schema of attributes for a tag, created by [`tag_class()`](/versions/8.5.1/rules/lib/globals/bzl#tag_class).
\ No newline at end of file
diff --git a/versions/8.5.1/rules/lib/builtins/transition.mdx b/versions/8.5.1/rules/lib/builtins/transition.mdx
index 512d381c..91a524d5 100644
--- a/versions/8.5.1/rules/lib/builtins/transition.mdx
+++ b/versions/8.5.1/rules/lib/builtins/transition.mdx
@@ -39,5 +39,5 @@ For more details see [here](https://bazel.build/versions/8.5.1/rules/config#user
 | Parameter | Description |
 | --- | --- |
 | `implementation` | callable; required  The function implementing this transition. This function always has two parameters: `settings` and `attr`. The `settings` param is a dictionary whose set of keys is defined by the inputs parameter. So, for each build setting `--//foo=bar`, if `inputs` contains `//foo`, `settings` will have an entry `settings['//foo']='bar'`. The `attr` param is a reference to `ctx.attr`. This gives the implementation function access to the rule's attributes to make attribute-parameterized transitions possible. This function must return a `dict` from build setting identifier to build setting value; this represents the configuration transition: for each entry in the returned `dict`, the transition updates that setting to the new value. All other settings are unchanged. This function can also return a `list` of `dict`s or a `dict` of `dict`s in the case of a split transition. |
-| `inputs` | [sequence](../core/list) of [string](../core/string)s; required  List of build settings that can be read by this transition. This becomes the key set of the settings parameter of the implementation function parameter. |
-| `outputs` | [sequence](../core/list) of [string](../core/string)s; required  List of build settings that can be written by this transition. This must be a superset of the key set of the dictionary returned by this transition. |
\ No newline at end of file
+| `inputs` | [sequence](/versions/8.5.1/rules/lib/core/list) of [string](/versions/8.5.1/rules/lib/core/string)s; required  List of build settings that can be read by this transition. This becomes the key set of the settings parameter of the implementation function parameter. |
+| `outputs` | [sequence](/versions/8.5.1/rules/lib/core/list) of [string](/versions/8.5.1/rules/lib/core/string)s; required  List of build settings that can be written by this transition. This must be a superset of the key set of the dictionary returned by this transition. |
\ No newline at end of file
diff --git a/versions/8.5.1/rules/lib/core/bool.mdx b/versions/8.5.1/rules/lib/core/bool.mdx
index 52be3664..d8bfddf1 100644
--- a/versions/8.5.1/rules/lib/core/bool.mdx
+++ b/versions/8.5.1/rules/lib/core/bool.mdx
@@ -2,4 +2,4 @@
 title: 'bool'
 ---
 
-A type to represent booleans. There are only two possible values: True and False. Any value can be converted to a boolean using the [bool](../globals/all#bool) function.
\ No newline at end of file
+A type to represent booleans. There are only two possible values: True and False. Any value can be converted to a boolean using the [bool](/versions/8.5.1/rules/lib/globals/all#bool) function.
\ No newline at end of file
diff --git a/versions/8.5.1/rules/lib/core/dict.mdx b/versions/8.5.1/rules/lib/core/dict.mdx
index 9005668c..6369e8cc 100644
--- a/versions/8.5.1/rules/lib/core/dict.mdx
+++ b/versions/8.5.1/rules/lib/core/dict.mdx
@@ -22,7 +22,7 @@ There are four ways to construct a dictionary:
      {i: 2*i for i in range(3)}  # {0: 0, 1: 2, 2: 4}
      ```
 
-     - A call to the built-in [dict](../globals/all#dict) function returns a dictionary containing the specified entries, which are inserted in argument order, positional arguments before named. As with comprehensions, duplicate keys are permitted.- The union expression `x | y` yields a new dictionary by combining two existing dictionaries. If the two dictionaries have a key `k` in common, the right hand side dictionary's value of the key (in other words, `y[k]`) wins. The `|=` variant of the union operator modifies a dictionary in-place. Example:
+     - A call to the built-in [dict](/versions/8.5.1/rules/lib/globals/all#dict) function returns a dictionary containing the specified entries, which are inserted in argument order, positional arguments before named. As with comprehensions, duplicate keys are permitted.- The union expression `x | y` yields a new dictionary by combining two existing dictionaries. If the two dictionaries have a key `k` in common, the right hand side dictionary's value of the key (in other words, `y[k]`) wins. The `|=` variant of the union operator modifies a dictionary in-place. Example:
 
          ```
          d = {"foo": "FOO", "bar": "BAR"} | {"foo": "FOO2", "baz": "BAZ"}
diff --git a/versions/8.5.1/rules/lib/core/json.mdx b/versions/8.5.1/rules/lib/core/json.mdx
index 0bb00e3e..74016379 100644
--- a/versions/8.5.1/rules/lib/core/json.mdx
+++ b/versions/8.5.1/rules/lib/core/json.mdx
@@ -29,7 +29,7 @@ If `x` is not a valid JSON encoding and the optional `default` parameter is *not
 
 | Parameter | Description |
 | --- | --- |
-| `x` | [string](../core/string); required  JSON string to decode. |
+| `x` | [string](/versions/8.5.1/rules/lib/core/string); required  JSON string to decode. |
 | `default` | default is `unbound`  If specified, the value to return when `x` cannot be decoded. |
 
 ## encode
@@ -64,8 +64,8 @@ The encode\_indent function is equivalent to `json.indent(json.encode(x), ...)`.
 | Parameter | Description |
 | --- | --- |
 | `x` | required |
-| `prefix` | [string](../core/string); default is `''` |
-| `indent` | [string](../core/string); default is `'\t'` |
+| `prefix` | [string](/versions/8.5.1/rules/lib/core/string); default is `''` |
+| `indent` | [string](/versions/8.5.1/rules/lib/core/string); default is `'\t'` |
 
 ## indent
 
@@ -84,6 +84,6 @@ If the input is not valid, the function may fail or return invalid output.
 
 | Parameter | Description |
 | --- | --- |
-| `s` | [string](../core/string); required |
-| `prefix` | [string](../core/string); default is `''` |
-| `indent` | [string](../core/string); default is `'\t'` |
\ No newline at end of file
+| `s` | [string](/versions/8.5.1/rules/lib/core/string); required |
+| `prefix` | [string](/versions/8.5.1/rules/lib/core/string); default is `''` |
+| `indent` | [string](/versions/8.5.1/rules/lib/core/string); default is `'\t'` |
\ No newline at end of file
diff --git a/versions/8.5.1/rules/lib/core/list.mdx b/versions/8.5.1/rules/lib/core/list.mdx
index c19e9780..0dce0a4d 100644
--- a/versions/8.5.1/rules/lib/core/list.mdx
+++ b/versions/8.5.1/rules/lib/core/list.mdx
@@ -91,8 +91,8 @@ Returns the index in the list of the first item whose value is x. It is an error
 | Parameter | Description |
 | --- | --- |
 | `x` | required |
-| `start` | [int](../core/int); or `None`; default is `None`  The start index of the list portion to inspect. |
-| `end` | [int](../core/int); or `None`; default is `None`  The end index of the list portion to inspect. |
+| `start` | [int](/versions/8.5.1/rules/lib/core/int); or `None`; default is `None`  The start index of the list portion to inspect. |
+| `end` | [int](/versions/8.5.1/rules/lib/core/int); or `None`; default is `None`  The end index of the list portion to inspect. |
 
 ## insert
 
@@ -106,7 +106,7 @@ Inserts an item at a given position.
 
 | Parameter | Description |
 | --- | --- |
-| `index` | [int](../core/int); required  The index of the given position. |
+| `index` | [int](/versions/8.5.1/rules/lib/core/int); required  The index of the given position. |
 | `item` | required  The item. |
 
 ## pop
@@ -121,7 +121,7 @@ Removes the item at the given position in the list, and returns it. If no `index
 
 | Parameter | Description |
 | --- | --- |
-| `i` | [int](../core/int); or `None`; default is `-1`  The index of the item. |
+| `i` | [int](/versions/8.5.1/rules/lib/core/int); or `None`; default is `-1`  The index of the item. |
 
 ## remove
 
diff --git a/versions/8.5.1/rules/lib/core/set.mdx b/versions/8.5.1/rules/lib/core/set.mdx
index aeb3b202..f754d715 100644
--- a/versions/8.5.1/rules/lib/core/set.mdx
+++ b/versions/8.5.1/rules/lib/core/set.mdx
@@ -3,14 +3,14 @@ title: 'set'
 ---
 
 The built-in set type. A set is a mutable, iterable collection of unique values – the set's
-*elements*. The [type name](../globals/all#type) of a set is `"set"`.
+*elements*. The [type name](/versions/8.5.1/rules/lib/globals/all#type) of a set is `"set"`.
 
 Sets provide constant-time operations to insert, remove, or check for the presence of a value.
 Sets are implemented using a hash table, and therefore, just like keys of a
-[dictionary](../dict), elements of a set must be hashable. A value may be used as an
+[dictionary](/versions/8.5.1/rules/lib/core/dict), elements of a set must be hashable. A value may be used as an
 element of a set if and only if it may be used as a key of a dictionary.
 
-Sets may be constructed using the [`set()`](../globals/all#set) built-in
+Sets may be constructed using the [`set()`](/versions/8.5.1/rules/lib/globals/all#set) built-in
 function, which returns a new set containing the unique elements of its optional argument, which
 must be an iterable. Calling `set()` without an argument constructs an empty set. Sets
 have no literal syntax.
@@ -26,7 +26,7 @@ s = set(["a", "b", "c"])
 
 A set is iterable, and thus may be used as the operand of a `for` loop, a list
 comprehension, and the various built-in functions that operate on iterables. Its length can be
-retrieved using the [`len()`](../globals/all#len) built-in function, and the
+retrieved using the [`len()`](/versions/8.5.1/rules/lib/globals/all#len) built-in function, and the
 order of iteration is the order in which elements were first added to the set:
 
 ```
diff --git a/versions/8.5.1/rules/lib/core/string.mdx b/versions/8.5.1/rules/lib/core/string.mdx
index 1673c6e4..9afffa34 100644
--- a/versions/8.5.1/rules/lib/core/string.mdx
+++ b/versions/8.5.1/rules/lib/core/string.mdx
@@ -81,9 +81,9 @@ Returns the number of (non-overlapping) occurrences of substring `sub` in string
 
 | Parameter | Description |
 | --- | --- |
-| `sub` | [string](../core/string); required |
-| `start` | [int](../core/int); or `None`; default is `0` |
-| `end` | [int](../core/int); or `None`; default is `None`  optional position before which to restrict to search. |
+| `sub` | [string](/versions/8.5.1/rules/lib/core/string); required |
+| `start` | [int](/versions/8.5.1/rules/lib/core/int); or `None`; default is `0` |
+| `end` | [int](/versions/8.5.1/rules/lib/core/int); or `None`; default is `None`  optional position before which to restrict to search. |
 
 ## elems
 
@@ -105,9 +105,9 @@ Returns True if the string ends with `sub`, otherwise False, optionally restrict
 
 | Parameter | Description |
 | --- | --- |
-| `sub` | [string](../core/string); or [tuple](../core/tuple) of [string](../core/string)s; required  The suffix (or tuple of alternative suffixes) to match. |
-| `start` | [int](../core/int); or `None`; default is `0`  Test beginning at this position. |
-| `end` | [int](../core/int); or `None`; default is `None`  optional position at which to stop comparing. |
+| `sub` | [string](/versions/8.5.1/rules/lib/core/string); or [tuple](/versions/8.5.1/rules/lib/core/tuple) of [string](/versions/8.5.1/rules/lib/core/string)s; required  The suffix (or tuple of alternative suffixes) to match. |
+| `start` | [int](/versions/8.5.1/rules/lib/core/int); or `None`; default is `0`  Test beginning at this position. |
+| `end` | [int](/versions/8.5.1/rules/lib/core/int); or `None`; default is `None`  optional position at which to stop comparing. |
 
 ## find
 
@@ -121,9 +121,9 @@ Returns the first index where `sub` is found, or -1 if no such index exists, opt
 
 | Parameter | Description |
 | --- | --- |
-| `sub` | [string](../core/string); required  The substring to find. |
-| `start` | [int](../core/int); or `None`; default is `0`  Restrict to search from this position. |
-| `end` | [int](../core/int); or `None`; default is `None`  optional position before which to restrict to search. |
+| `sub` | [string](/versions/8.5.1/rules/lib/core/string); required  The substring to find. |
+| `start` | [int](/versions/8.5.1/rules/lib/core/int); or `None`; default is `0`  Restrict to search from this position. |
+| `end` | [int](/versions/8.5.1/rules/lib/core/int); or `None`; default is `None`  optional position before which to restrict to search. |
 
 ## format
 
@@ -131,7 +131,7 @@ Returns the first index where `sub` is found, or -1 if no such index exists, opt
 string string.format(*args, **kwargs)
 ```
 
-Perform string interpolation. Format strings contain replacement fields surrounded by curly braces `{}`. Anything that is not contained in braces is considered literal text, which is copied unchanged to the output.If you need to include a brace character in the literal text, it can be escaped by doubling: `{{` and `}}`A replacement field can be either a name, a number, or empty. Values are converted to strings using the [str](../globals/all#str) function.
+Perform string interpolation. Format strings contain replacement fields surrounded by curly braces `{}`. Anything that is not contained in braces is considered literal text, which is copied unchanged to the output.If you need to include a brace character in the literal text, it can be escaped by doubling: `{{` and `}}`A replacement field can be either a name, a number, or empty. Values are converted to strings using the [str](/versions/8.5.1/rules/lib/globals/all#str) function.
 
 ```
 # Access in order:
@@ -161,9 +161,9 @@ Returns the first index where `sub` is found, or raises an error if no such inde
 
 | Parameter | Description |
 | --- | --- |
-| `sub` | [string](../core/string); required  The substring to find. |
-| `start` | [int](../core/int); or `None`; default is `0`  Restrict to search from this position. |
-| `end` | [int](../core/int); or `None`; default is `None`  optional position before which to restrict to search. |
+| `sub` | [string](/versions/8.5.1/rules/lib/core/string); required  The substring to find. |
+| `start` | [int](/versions/8.5.1/rules/lib/core/int); or `None`; default is `0`  Restrict to search from this position. |
+| `end` | [int](/versions/8.5.1/rules/lib/core/int); or `None`; default is `None`  optional position before which to restrict to search. |
 
 ## isalnum
 
@@ -263,7 +263,7 @@ Returns a copy of the string where leading characters that appear in `chars` are
 
 | Parameter | Description |
 | --- | --- |
-| `chars` | [string](../core/string); or `None`; default is `None`  The characters to remove, or all whitespace if None. |
+| `chars` | [string](/versions/8.5.1/rules/lib/core/string); or `None`; default is `None`  The characters to remove, or all whitespace if None. |
 
 ## partition
 
@@ -277,7 +277,7 @@ Splits the input string at the first occurrence of the separator `sep` and retur
 
 | Parameter | Description |
 | --- | --- |
-| `sep` | [string](../core/string); required  The string to split on. |
+| `sep` | [string](/versions/8.5.1/rules/lib/core/string); required  The string to split on. |
 
 ## removeprefix
 
@@ -291,7 +291,7 @@ If the string starts with `prefix`, returns a new string with the prefix removed
 
 | Parameter | Description |
 | --- | --- |
-| `prefix` | [string](../core/string); required  The prefix to remove if present. |
+| `prefix` | [string](/versions/8.5.1/rules/lib/core/string); required  The prefix to remove if present. |
 
 ## removesuffix
 
@@ -305,7 +305,7 @@ If the string ends with `suffix`, returns a new string with the suffix removed.
 
 | Parameter | Description |
 | --- | --- |
-| `suffix` | [string](../core/string); required  The suffix to remove if present. |
+| `suffix` | [string](/versions/8.5.1/rules/lib/core/string); required  The suffix to remove if present. |
 
 ## replace
 
@@ -319,9 +319,9 @@ Returns a copy of the string in which the occurrences of `old` have been replace
 
 | Parameter | Description |
 | --- | --- |
-| `old` | [string](../core/string); required  The string to be replaced. |
-| `new` | [string](../core/string); required  The string to replace with. |
-| `count` | [int](../core/int); default is `-1`  The maximum number of replacements. If omitted, or if the value is negative, there is no limit. |
+| `old` | [string](/versions/8.5.1/rules/lib/core/string); required  The string to be replaced. |
+| `new` | [string](/versions/8.5.1/rules/lib/core/string); required  The string to replace with. |
+| `count` | [int](/versions/8.5.1/rules/lib/core/int); default is `-1`  The maximum number of replacements. If omitted, or if the value is negative, there is no limit. |
 
 ## rfind
 
@@ -335,9 +335,9 @@ Returns the last index where `sub` is found, or -1 if no such index exists, opti
 
 | Parameter | Description |
 | --- | --- |
-| `sub` | [string](../core/string); required  The substring to find. |
-| `start` | [int](../core/int); or `None`; default is `0`  Restrict to search from this position. |
-| `end` | [int](../core/int); or `None`; default is `None`  optional position before which to restrict to search. |
+| `sub` | [string](/versions/8.5.1/rules/lib/core/string); required  The substring to find. |
+| `start` | [int](/versions/8.5.1/rules/lib/core/int); or `None`; default is `0`  Restrict to search from this position. |
+| `end` | [int](/versions/8.5.1/rules/lib/core/int); or `None`; default is `None`  optional position before which to restrict to search. |
 
 ## rindex
 
@@ -351,9 +351,9 @@ Returns the last index where `sub` is found, or raises an error if no such index
 
 | Parameter | Description |
 | --- | --- |
-| `sub` | [string](../core/string); required  The substring to find. |
-| `start` | [int](../core/int); or `None`; default is `0`  Restrict to search from this position. |
-| `end` | [int](../core/int); or `None`; default is `None`  optional position before which to restrict to search. |
+| `sub` | [string](/versions/8.5.1/rules/lib/core/string); required  The substring to find. |
+| `start` | [int](/versions/8.5.1/rules/lib/core/int); or `None`; default is `0`  Restrict to search from this position. |
+| `end` | [int](/versions/8.5.1/rules/lib/core/int); or `None`; default is `None`  optional position before which to restrict to search. |
 
 ## rpartition
 
@@ -367,7 +367,7 @@ Splits the input string at the last occurrence of the separator `sep` and return
 
 | Parameter | Description |
 | --- | --- |
-| `sep` | [string](../core/string); required  The string to split on. |
+| `sep` | [string](/versions/8.5.1/rules/lib/core/string); required  The string to split on. |
 
 ## rsplit
 
@@ -381,8 +381,8 @@ Returns a list of all the words in the string, using `sep` as the separator, opt
 
 | Parameter | Description |
 | --- | --- |
-| `sep` | [string](../core/string); required  The string to split on. |
-| `maxsplit` | [int](../core/int); or `None`; default is `None`  The maximum number of splits. |
+| `sep` | [string](/versions/8.5.1/rules/lib/core/string); required  The string to split on. |
+| `maxsplit` | [int](/versions/8.5.1/rules/lib/core/int); or `None`; default is `None`  The maximum number of splits. |
 
 ## rstrip
 
@@ -400,7 +400,7 @@ Returns a copy of the string where trailing characters that appear in `chars` ar
 
 | Parameter | Description |
 | --- | --- |
-| `chars` | [string](../core/string); or `None`; default is `None`  The characters to remove, or all whitespace if None. |
+| `chars` | [string](/versions/8.5.1/rules/lib/core/string); or `None`; default is `None`  The characters to remove, or all whitespace if None. |
 
 ## split
 
@@ -414,8 +414,8 @@ Returns a list of all the words in the string, using `sep` as the separator, opt
 
 | Parameter | Description |
 | --- | --- |
-| `sep` | [string](../core/string); required  The string to split on. |
-| `maxsplit` | [int](../core/int); or `None`; default is `None`  The maximum number of splits. |
+| `sep` | [string](/versions/8.5.1/rules/lib/core/string); required  The string to split on. |
+| `maxsplit` | [int](/versions/8.5.1/rules/lib/core/int); or `None`; default is `None`  The maximum number of splits. |
 
 ## splitlines
 
@@ -429,7 +429,7 @@ Splits the string at line boundaries ('\n', '\r\n', '\r') and returns the result
 
 | Parameter | Description |
 | --- | --- |
-| `keepends` | [bool](../core/bool); default is `False`  Whether the line breaks should be included in the resulting list. |
+| `keepends` | [bool](/versions/8.5.1/rules/lib/core/bool); default is `False`  Whether the line breaks should be included in the resulting list. |
 
 ## startswith
 
@@ -443,9 +443,9 @@ Returns True if the string starts with `sub`, otherwise False, optionally restri
 
 | Parameter | Description |
 | --- | --- |
-| `sub` | [string](../core/string); or [tuple](../core/tuple) of [string](../core/string)s; required  The prefix (or tuple of alternative prefixes) to match. |
-| `start` | [int](../core/int); or `None`; default is `0`  Test beginning at this position. |
-| `end` | [int](../core/int); or `None`; default is `None`  Stop comparing at this position. |
+| `sub` | [string](/versions/8.5.1/rules/lib/core/string); or [tuple](/versions/8.5.1/rules/lib/core/tuple) of [string](/versions/8.5.1/rules/lib/core/string)s; required  The prefix (or tuple of alternative prefixes) to match. |
+| `start` | [int](/versions/8.5.1/rules/lib/core/int); or `None`; default is `0`  Test beginning at this position. |
+| `end` | [int](/versions/8.5.1/rules/lib/core/int); or `None`; default is `None`  Stop comparing at this position. |
 
 ## strip
 
@@ -463,7 +463,7 @@ Returns a copy of the string where leading or trailing characters that appear in
 
 | Parameter | Description |
 | --- | --- |
-| `chars` | [string](../core/string); or `None`; default is `None`  The characters to remove, or all whitespace if None. |
+| `chars` | [string](/versions/8.5.1/rules/lib/core/string); or `None`; default is `None`  The characters to remove, or all whitespace if None. |
 
 ## title
 
diff --git a/versions/8.5.1/rules/lib/fragments.mdx b/versions/8.5.1/rules/lib/fragments.mdx
index 4b44f966..e430b403 100644
--- a/versions/8.5.1/rules/lib/fragments.mdx
+++ b/versions/8.5.1/rules/lib/fragments.mdx
@@ -2,7 +2,7 @@
 title: 'Configuration Fragments'
 ---
 
-Configuration fragments give rules access to language-specific parts of [configuration](builtins/configuration).
+Configuration fragments give rules access to language-specific parts of [configuration](/versions/8.5.1/rules/lib/builtins/configuration).
 
 Rule implementations can get them using `ctx.fragments.[fragment name]`
 
diff --git a/versions/8.5.1/rules/lib/fragments/apple.mdx b/versions/8.5.1/rules/lib/fragments/apple.mdx
index f7e8daff..36ad0fc0 100644
--- a/versions/8.5.1/rules/lib/fragments/apple.mdx
+++ b/versions/8.5.1/rules/lib/fragments/apple.mdx
@@ -22,7 +22,7 @@ The platform of the current configuration for the given platform type. This shou
 
 | Parameter | Description |
 | --- | --- |
-| `platform_type` | [string](../core/string); required  The apple platform type. |
+| `platform_type` | [string](/versions/8.5.1/rules/lib/core/string); required  The apple platform type. |
 
 ## single\_arch\_cpu
 
diff --git a/versions/8.5.1/rules/lib/fragments/coverage.mdx b/versions/8.5.1/rules/lib/fragments/coverage.mdx
index 894ee502..8687bae4 100644
--- a/versions/8.5.1/rules/lib/fragments/coverage.mdx
+++ b/versions/8.5.1/rules/lib/fragments/coverage.mdx
@@ -14,7 +14,7 @@ A configuration fragment representing the coverage configuration.
 Label coverage.output_generator
 ```
 
-Returns the label pointed to by the [`--coverage_output_generator`](https://bazel.build/versions/8.5.1/reference/command-line-reference#flag--coverage_output_generator) option if coverage collection is enabled, otherwise returns `None`. Can be accessed with [`configuration_field`](../globals/bzl#configuration_field):
+Returns the label pointed to by the [`--coverage_output_generator`](https://bazel.build/versions/8.5.1/reference/command-line-reference#flag--coverage_output_generator) option if coverage collection is enabled, otherwise returns `None`. Can be accessed with [`configuration_field`](/versions/8.5.1/rules/lib/globals/bzl#configuration_field):
 
 ```
 attr.label(
diff --git a/versions/8.5.1/rules/lib/fragments/cpp.mdx b/versions/8.5.1/rules/lib/fragments/cpp.mdx
index 4c7cbcbc..32c61d58 100644
--- a/versions/8.5.1/rules/lib/fragments/cpp.mdx
+++ b/versions/8.5.1/rules/lib/fragments/cpp.mdx
@@ -46,7 +46,7 @@ The flags passed to Bazel by [`--copt`](/versions/8.5.1/docs/user-manual#flag--c
 Label cpp.custom_malloc
 ```
 
-Returns label pointed to by [`--custom_malloc`](/versions/8.5.1/docs/user-manual#flag--custom_malloc) option. Can be accessed with [`configuration_field`](../globals/bzl#configuration_field):
+Returns label pointed to by [`--custom_malloc`](/versions/8.5.1/docs/user-manual#flag--custom_malloc) option. Can be accessed with [`configuration_field`](/versions/8.5.1/rules/lib/globals/bzl#configuration_field):
 
 ```
 attr.label(
diff --git a/versions/8.5.1/rules/lib/globals/all.mdx b/versions/8.5.1/rules/lib/globals/all.mdx
index 45106d41..e86fc62a 100644
--- a/versions/8.5.1/rules/lib/globals/all.mdx
+++ b/versions/8.5.1/rules/lib/globals/all.mdx
@@ -50,7 +50,7 @@ abs(-2.3) == 2.3
 
 | Parameter | Description |
 | --- | --- |
-| `x` | [int](../core/int); or [float](../core/float); required  A number (int or float) |
+| `x` | [int](/versions/8.5.1/rules/lib/core/int); or [float](/versions/8.5.1/rules/lib/core/float); required  A number (int or float) |
 
 ## all
 
@@ -110,7 +110,7 @@ Constructor for the bool type. It returns `False` if the object is `None`, `Fals
 dict dict(pairs=[], **kwargs)
 ```
 
-Creates a [dictionary](../core/dict) from an optional positional argument and an optional set of keyword arguments. In the case where the same key is given multiple times, the last value will be used. Entries supplied via keyword arguments are considered to come after entries supplied via the positional argument.
+Creates a [dictionary](/versions/8.5.1/rules/lib/core/dict) from an optional positional argument and an optional set of keyword arguments. In the case where the same key is given multiple times, the last value will be used. Entries supplied via keyword arguments are considered to come after entries supplied via the positional argument.
 
 ### Parameters
 
@@ -150,7 +150,7 @@ enumerate([24, 21, 84]) == [(0, 24), (1, 21), (2, 84)]
 | Parameter | Description |
 | --- | --- |
 | `list` | required  input sequence. |
-| `start` | [int](../core/int); default is `0`  start index. |
+| `start` | [int](/versions/8.5.1/rules/lib/core/int); default is `0`  start index. |
 
 ## fail
 
@@ -165,8 +165,8 @@ Causes execution to fail with an error.
 | Parameter | Description |
 | --- | --- |
 | `msg` | default is `None`  Deprecated: use positional arguments instead. This argument acts like an implicit leading positional argument. |
-| `attr` | [string](../core/string); or `None`; default is `None`  Deprecated. Causes an optional prefix containing this string to be added to the error message. |
-| `sep` | [string](../core/string); default is `" "`  The separator string between the objects, default is space (" "). |
+| `attr` | [string](/versions/8.5.1/rules/lib/core/string); or `None`; default is `None`  Deprecated. Causes an optional prefix containing this string to be added to the error message. |
+| `sep` | [string](/versions/8.5.1/rules/lib/core/string); default is `" "`  The separator string between the objects, default is space (" "). |
 | `args` | required  A list of values, formatted with debugPrint (which is equivalent to str by default) and joined with sep (defaults to " "), that appear in the error message. |
 
 ## float
@@ -205,7 +205,7 @@ getattr(ctx.attr, "myattr", "mydefault")
 | Parameter | Description |
 | --- | --- |
 | `x` | required  The struct whose attribute is accessed. |
-| `name` | [string](../core/string); required  The name of the struct attribute. |
+| `name` | [string](/versions/8.5.1/rules/lib/core/string); required  The name of the struct attribute. |
 | `default` | default is `unbound`  The default value to return in case the struct doesn't have an attribute of the given name. |
 
 ## hasattr
@@ -225,7 +225,7 @@ hasattr(ctx.attr, "myattr")
 | Parameter | Description |
 | --- | --- |
 | `x` | required |
-| `name` | [string](../core/string); required  The name of the attribute. |
+| `name` | [string](/versions/8.5.1/rules/lib/core/string); required  The name of the attribute. |
 
 ## hash
 
@@ -245,7 +245,7 @@ Hashing of values besides strings is not currently supported.
 
 | Parameter | Description |
 | --- | --- |
-| `value` | [string](../core/string); required  String value to hash. |
+| `value` | [string](/versions/8.5.1/rules/lib/core/string); required  String value to hash. |
 
 ## int
 
@@ -372,7 +372,7 @@ Using `print` in production code is discouraged due to the spam it creates for u
 
 | Parameter | Description |
 | --- | --- |
-| `sep` | [string](../core/string); default is `" "`  The separator string between the objects, default is space (" "). |
+| `sep` | [string](/versions/8.5.1/rules/lib/core/string); default is `" "`  The separator string between the objects, default is space (" "). |
 | `args` | required  The objects to print. |
 
 ## range
@@ -393,9 +393,9 @@ range(3, 0, -1) == [3, 2, 1]
 
 | Parameter | Description |
 | --- | --- |
-| `start_or_stop` | [int](../core/int); required  Value of the start element if stop is provided, otherwise value of stop and the actual start is 0 |
-| `stop_or_none` | [int](../core/int); or `None`; default is `None`  optional index of the first item *not* to be included in the resulting list; generation of the list stops before `stop` is reached. |
-| `step` | [int](../core/int); default is `1`  The increment (default is 1). It may be negative. |
+| `start_or_stop` | [int](/versions/8.5.1/rules/lib/core/int); required  Value of the start element if stop is provided, otherwise value of stop and the actual start is 0 |
+| `stop_or_none` | [int](/versions/8.5.1/rules/lib/core/int); or `None`; default is `None`  optional index of the first item *not* to be included in the resulting list; generation of the list stops before `stop` is reached. |
+| `step` | [int](/versions/8.5.1/rules/lib/core/int); default is `1`  The increment (default is 1). It may be negative. |
 
 ## repr
 
@@ -439,7 +439,7 @@ reversed([3, 5, 4]) == [4, 5, 3]
 set set(elements=[])
 ```
 
-Creates a new [set](../core/set) containing the unique elements of a given
+Creates a new [set](/versions/8.5.1/rules/lib/core/set) containing the unique elements of a given
 iterable, preserving iteration order.
 
 If called with no argument, `set()` returns a new empty set.
@@ -479,7 +479,7 @@ sorted(["two", "three", "four"], key = len) == ["two", "four", "three"]  # sort
 | --- | --- |
 | `iterable` | iterable; required  The iterable sequence to sort. |
 | `key` | callable; or `None`; default is `None`  An optional function applied to each element before comparison. |
-| `reverse` | [bool](../core/bool); default is `False`  Return results in descending order. |
+| `reverse` | [bool](/versions/8.5.1/rules/lib/core/bool); default is `False`  Return results in descending order. |
 
 ## str
 
diff --git a/versions/8.5.1/rules/lib/globals/build.mdx b/versions/8.5.1/rules/lib/globals/build.mdx
index 74551a26..78561c34 100644
--- a/versions/8.5.1/rules/lib/globals/build.mdx
+++ b/versions/8.5.1/rules/lib/globals/build.mdx
@@ -28,7 +28,7 @@ Methods available in BUILD files. See also the Build Encyclopedia for extra [fun
 depset depset(direct=None, order="default", *, transitive=None)
 ```
 
-Creates a [depset](../builtins/depset). The `direct` parameter is a list of direct elements of the depset, and `transitive` parameter is a list of depsets whose elements become indirect elements of the created depset. The order in which elements are returned when the depset is converted to a list is specified by the `order` parameter. See the [Depsets overview](https://bazel.build/versions/8.5.1/extending/depsets) for more information.
+Creates a [depset](/versions/8.5.1/rules/lib/builtins/depset). The `direct` parameter is a list of direct elements of the depset, and `transitive` parameter is a list of depsets whose elements become indirect elements of the created depset. The order in which elements are returned when the depset is converted to a list is specified by the `order` parameter. See the [Depsets overview](https://bazel.build/versions/8.5.1/extending/depsets) for more information.
 
 All elements (direct and indirect) of a depset must be of the same type, as obtained by the expression `type(x)`.
 
@@ -42,9 +42,9 @@ The order of the created depset should be *compatible* with the order of its `tr
 
 | Parameter | Description |
 | --- | --- |
-| `direct` | [sequence](../core/list); or `None`; default is `None`  A list of *direct* elements of a depset. |
-| `order` | [string](../core/string); default is `"default"`  The traversal strategy for the new depset. See [here](../builtins/depset) for the possible values. |
-| `transitive` | [sequence](../core/list) of [depset](../builtins/depset)s; or `None`; default is `None`  A list of depsets whose elements will become indirect elements of the depset. |
+| `direct` | [sequence](/versions/8.5.1/rules/lib/core/list); or `None`; default is `None`  A list of *direct* elements of a depset. |
+| `order` | [string](/versions/8.5.1/rules/lib/core/string); default is `"default"`  The traversal strategy for the new depset. See [here](/versions/8.5.1/rules/lib/builtins/depset) for the possible values. |
+| `transitive` | [sequence](/versions/8.5.1/rules/lib/core/list) of [depset](/versions/8.5.1/rules/lib/builtins/depset)s; or `None`; default is `None`  A list of depsets whose elements will become indirect elements of the depset. |
 
 ## existing\_rule
 
@@ -72,7 +72,7 @@ If possible, avoid using this function. It makes BUILD files brittle and order-d
 
 | Parameter | Description |
 | --- | --- |
-| `name` | [string](../core/string); required  The name of the target. |
+| `name` | [string](/versions/8.5.1/rules/lib/core/string); required  The name of the target. |
 
 ## existing\_rules
 
@@ -98,9 +98,9 @@ Specifies a list of files belonging to this package that are exported to other p
 
 | Parameter | Description |
 | --- | --- |
-| `srcs` | [sequence](../core/list) of [string](../core/string)s; required  The list of files to export. |
-| `visibility` | [sequence](../core/list); or `None`; default is `None`  A visibility declaration can to be specified. The files will be visible to the targets specified. If no visibility is specified, the files will be visible to every package. |
-| `licenses` | [sequence](../core/list) of [string](../core/string)s; or `None`; default is `None`  Licenses to be specified. |
+| `srcs` | [sequence](/versions/8.5.1/rules/lib/core/list) of [string](/versions/8.5.1/rules/lib/core/string)s; required  The list of files to export. |
+| `visibility` | [sequence](/versions/8.5.1/rules/lib/core/list); or `None`; default is `None`  A visibility declaration can to be specified. The files will be visible to the targets specified. If no visibility is specified, the files will be visible to every package. |
+| `licenses` | [sequence](/versions/8.5.1/rules/lib/core/list) of [string](/versions/8.5.1/rules/lib/core/string)s; or `None`; default is `None`  Licenses to be specified. |
 
 ## glob
 
@@ -119,9 +119,9 @@ If the `exclude_directories` argument is enabled (set to `1`), files of type dir
 
 | Parameter | Description |
 | --- | --- |
-| `include` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  The list of glob patterns to include. |
-| `exclude` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  The list of glob patterns to exclude. |
-| `exclude_directories` | [int](../core/int); default is `1`  A flag whether to exclude directories or not. |
+| `include` | [sequence](/versions/8.5.1/rules/lib/core/list) of [string](/versions/8.5.1/rules/lib/core/string)s; default is `[]`  The list of glob patterns to include. |
+| `exclude` | [sequence](/versions/8.5.1/rules/lib/core/list) of [string](/versions/8.5.1/rules/lib/core/string)s; default is `[]`  The list of glob patterns to exclude. |
+| `exclude_directories` | [int](/versions/8.5.1/rules/lib/core/int); default is `1`  A flag whether to exclude directories or not. |
 | `allow_empty` | default is `unbound`  Whether we allow glob patterns to match nothing. If `allow\_empty` is False, each individual include pattern must match something and also the final result must be non-empty (after the matches of the `exclude` patterns are excluded). |
 
 ## module\_name
@@ -168,9 +168,9 @@ This function defines a set of packages and assigns a label to the group. The la
 
 | Parameter | Description |
 | --- | --- |
-| `name` | [string](../core/string); required  The unique name for this rule. |
-| `packages` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  A complete enumeration of packages in this group. |
-| `includes` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  Other package groups that are included in this one. |
+| `name` | [string](/versions/8.5.1/rules/lib/core/string); required  The unique name for this rule. |
+| `packages` | [sequence](/versions/8.5.1/rules/lib/core/list) of [string](/versions/8.5.1/rules/lib/core/string)s; default is `[]`  A complete enumeration of packages in this group. |
+| `includes` | [sequence](/versions/8.5.1/rules/lib/core/list) of [string](/versions/8.5.1/rules/lib/core/string)s; default is `[]`  Other package groups that are included in this one. |
 
 ## package\_name
 
@@ -186,19 +186,19 @@ The name of the package being evaluated, without the repository name. For exampl
 Label package_relative_label(input)
 ```
 
-Converts the input string into a [Label](../builtins/Label) object, in the context of the package currently being initialized (that is, the `BUILD` file for which the current macro is executing). If the input is already a `Label`, it is returned unchanged.
+Converts the input string into a [Label](/versions/8.5.1/rules/lib/builtins/Label) object, in the context of the package currently being initialized (that is, the `BUILD` file for which the current macro is executing). If the input is already a `Label`, it is returned unchanged.
 
 This function may only be called while evaluating a BUILD file and the macros it directly or indirectly calls; it may not be called in (for instance) a rule implementation function.
 
 The result of this function is the same `Label` value as would be produced by passing the given string to a label-valued attribute of a target declared in the BUILD file.
 
-*Usage note:* The difference between this function and [Label()](../builtins/Label#Label) is that `Label()` uses the context of the package of the `.bzl` file that called it, not the package of the `BUILD` file. Use `Label()` when you need to refer to a fixed target that is hardcoded into the macro, such as a compiler. Use `package_relative_label()` when you need to normalize a label string supplied by the BUILD file to a `Label` object. (There is no way to convert a string to a `Label` in the context of a package other than the BUILD file or the calling .bzl file. For that reason, outer macros should always prefer to pass Label objects to inner macros rather than label strings.)
+*Usage note:* The difference between this function and [Label()](/versions/8.5.1/rules/lib/builtins/Label#Label) is that `Label()` uses the context of the package of the `.bzl` file that called it, not the package of the `BUILD` file. Use `Label()` when you need to refer to a fixed target that is hardcoded into the macro, such as a compiler. Use `package_relative_label()` when you need to normalize a label string supplied by the BUILD file to a `Label` object. (There is no way to convert a string to a `Label` in the context of a package other than the BUILD file or the calling .bzl file. For that reason, outer macros should always prefer to pass Label objects to inner macros rather than label strings.)
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `input` | [string](../core/string); or [Label](../builtins/Label); required  The input label string or Label object. If a Label object is passed, it's returned as is. |
+| `input` | [string](/versions/8.5.1/rules/lib/core/string); or [Label](/versions/8.5.1/rules/lib/builtins/Label); required  The input label string or Label object. If a Label object is passed, it's returned as is. |
 
 ## repo\_name
 
@@ -231,8 +231,8 @@ unknown select(x, no_match_error='')
 
 | Parameter | Description |
 | --- | --- |
-| `x` | [dict](../core/dict); required |
-| `no_match_error` | [string](../core/string); default is `''`  Optional custom error to report if no condition matches. |
+| `x` | [dict](/versions/8.5.1/rules/lib/core/dict); required |
+| `no_match_error` | [string](/versions/8.5.1/rules/lib/core/string); default is `''`  Optional custom error to report if no condition matches. |
 
 ## subpackages
 
@@ -246,6 +246,6 @@ Returns a new mutable list of every direct subpackage of the current package, re
 
 | Parameter | Description |
 | --- | --- |
-| `include` | [sequence](../core/list) of [string](../core/string)s; required  The list of glob patterns to include in subpackages scan. |
-| `exclude` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  The list of glob patterns to exclude from subpackages scan. |
-| `allow_empty` | [bool](../core/bool); default is `False`  Whether we fail if the call returns an empty list. By default empty list indicates potential error in BUILD file where the call to subpackages() is superflous. Setting to true allows this function to succeed in that case. |*
\ No newline at end of file
+| `include` | [sequence](/versions/8.5.1/rules/lib/core/list) of [string](/versions/8.5.1/rules/lib/core/string)s; required  The list of glob patterns to include in subpackages scan. |
+| `exclude` | [sequence](/versions/8.5.1/rules/lib/core/list) of [string](/versions/8.5.1/rules/lib/core/string)s; default is `[]`  The list of glob patterns to exclude from subpackages scan. |
+| `allow_empty` | [bool](/versions/8.5.1/rules/lib/core/bool); default is `False`  Whether we fail if the call returns an empty list. By default empty list indicates potential error in BUILD file where the call to subpackages() is superflous. Setting to true allows this function to succeed in that case. |*
\ No newline at end of file
diff --git a/versions/8.5.1/rules/lib/globals/bzl.mdx b/versions/8.5.1/rules/lib/globals/bzl.mdx
index c027f167..b3c70ed8 100644
--- a/versions/8.5.1/rules/lib/globals/bzl.mdx
+++ b/versions/8.5.1/rules/lib/globals/bzl.mdx
@@ -28,7 +28,7 @@ Global methods available in all .bzl files.
 transition analysis_test_transition(settings)
 ```
 
-Creates a configuration transition to be applied on an analysis-test rule's dependencies. This transition may only be applied on attributes of rules with `analysis_test = True`. Such rules are restricted in capabilities (for example, the size of their dependency tree is limited), so transitions created using this function are limited in potential scope as compared to transitions created using [`transition()`](../builtins/transition).
+Creates a configuration transition to be applied on an analysis-test rule's dependencies. This transition may only be applied on attributes of rules with `analysis_test = True`. Such rules are restricted in capabilities (for example, the size of their dependency tree is limited), so transitions created using this function are limited in potential scope as compared to transitions created using [`transition()`](/versions/8.5.1/rules/lib/builtins/transition).
 
 This function is primarily designed to facilitate the [Analysis Test Framework](https://bazel.build/versions/8.5.1/rules/testing) core library. See its documentation (or its implementation) for best practices.
 
@@ -36,7 +36,7 @@ This function is primarily designed to facilitate the [Analysis Test Framework](
 
 | Parameter | Description |
 | --- | --- |
-| `settings` | [dict](../core/dict); required  A dictionary containing information about configuration settings which should be set by this configuration transition. Keys are build setting labels and values are their new post-transition values. All other settings are unchanged. Use this to declare specific configuration settings that an analysis test requires to be set in order to pass. |
+| `settings` | [dict](/versions/8.5.1/rules/lib/core/dict); required  A dictionary containing information about configuration settings which should be set by this configuration transition. Keys are build setting labels and values are their new post-transition values. All other settings are unchanged. Use this to declare specific configuration settings that an analysis test requires to be set in order to pass. |
 
 ## aspect
 
@@ -50,23 +50,23 @@ Creates a new aspect. The result of this function must be stored in a global val
 
 | Parameter | Description |
 | --- | --- |
-| `implementation` | [function](../core/function); required  A Starlark function that implements this aspect, with exactly two parameters: [Target](../builtins/Target) (the target to which the aspect is applied) and [ctx](../builtins/ctx) (the rule context which the target is created from). Attributes of the target are available via the `ctx.rule` field. This function is evaluated during the analysis phase for each application of an aspect to a target. |
-| `attr_aspects` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  List of attribute names. The aspect propagates along dependencies specified in the attributes of a target with these names. Common values here include `deps` and `exports`. The list can also contain a single string `"*"` to propagate along all dependencies of a target. |
-| `toolchains_aspects` | [sequence](../core/list); default is `[]`  List of toolchain types. The aspect propagates to target toolchains which match these toolchain types. |
-| `attrs` | [dict](../core/dict); default is `{}`  A dictionary declaring all the attributes of the aspect. It maps from an attribute name to an attribute object, like `attr.label` or `attr.string` (see [`attr`](../toplevel/attr) module). Aspect attributes are available to implementation function as fields of `ctx` parameter. Implicit attributes starting with `_` must have default values, and have type `label` or `label_list`.  Explicit attributes must have type `string`, and must use the `values` restriction. Explicit attributes restrict the aspect to only be used with rules that have attributes of the same name, type, and valid values according to the restriction.  Declared attributes will convert `None` to the default value. |
-| `required_providers` | [sequence](../core/list); default is `[]`  This attribute allows the aspect to limit its propagation to only the targets whose rules advertise its required providers. The value must be a list containing either individual providers or lists of providers but not both. For example, `[[FooInfo], [BarInfo], [BazInfo, QuxInfo]]` is a valid value while `[FooInfo, BarInfo, [BazInfo, QuxInfo]]` is not valid. An unnested list of providers will automatically be converted to a list containing one list of providers. That is, `[FooInfo, BarInfo]` will automatically be converted to `[[FooInfo, BarInfo]]`. To make some rule (e.g. `some_rule`) targets visible to an aspect, `some_rule` must advertise all providers from at least one of the required providers lists. For example, if the `required_providers` of an aspect are `[[FooInfo], [BarInfo], [BazInfo, QuxInfo]]`, this aspect can see `some_rule` targets if and only if `some_rule` provides `FooInfo`, *or* `BarInfo`, *or* both `BazInfo` *and* `QuxInfo`. |
-| `required_aspect_providers` | [sequence](../core/list); default is `[]`  This attribute allows this aspect to inspect other aspects. The value must be a list containing either individual providers or lists of providers but not both. For example, `[[FooInfo], [BarInfo], [BazInfo, QuxInfo]]` is a valid value while `[FooInfo, BarInfo, [BazInfo, QuxInfo]]` is not valid. An unnested list of providers will automatically be converted to a list containing one list of providers. That is, `[FooInfo, BarInfo]` will automatically be converted to `[[FooInfo, BarInfo]]`. To make another aspect (e.g. `other_aspect`) visible to this aspect, `other_aspect` must provide all providers from at least one of the lists. In the example of `[[FooInfo], [BarInfo], [BazInfo, QuxInfo]]`, this aspect can see `other_aspect` if and only if `other_aspect` provides `FooInfo`, *or* `BarInfo`, *or* both `BazInfo` *and* `QuxInfo`. |
-| `provides` | [sequence](../core/list); default is `[]`  A list of providers that the implementation function must return. It is an error if the implementation function omits any of the types of providers listed here from its return value. However, the implementation function may return additional providers not listed here. Each element of the list is an `*Info` object returned by [`provider()`](../globals/bzl#provider), except that a legacy provider is represented by its string name instead.When a target of the rule is used as a dependency for a target that declares a required provider, it is not necessary to specify that provider here. It is enough that the implementation function returns it. However, it is considered best practice to specify it, even though this is not required. The [`required_providers`](../globals/bzl#aspect.required_providers) field of an [aspect](../globals/bzl#aspect) does, however, require that providers are specified here. |
-| `requires` | [sequence](../core/list) of [Aspect](../builtins/Aspect)s; default is `[]`  List of aspects required to be propagated before this aspect. |
-| `fragments` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  List of names of configuration fragments that the aspect requires in target configuration. |
-| `host_fragments` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  List of names of configuration fragments that the aspect requires in host configuration. |
-| `toolchains` | [sequence](../core/list); default is `[]`  If set, the set of toolchains this aspect requires. The list can contain String, Label, or StarlarkToolchainTypeApi objects, in any combination. Toolchains will be found by checking the current platform, and provided to the aspect implementation via `ctx.toolchain`. |
-| `incompatible_use_toolchain_transition` | [bool](../core/bool); default is `False`  Deprecated, this is no longer in use and should be removed. |
-| `doc` | [string](../core/string); or `None`; default is `None`  A description of the aspect that can be extracted by documentation generating tools. |
-| `apply_to_generating_rules` | [bool](../core/bool); default is `False`  If true, the aspect will, when applied to an output file, instead apply to the output file's generating rule. For example, suppose an aspect propagates transitively through attribute `deps` and it is applied to target `alpha`. Suppose `alpha` has `deps = [':beta\_output']`, where `beta\_output` is a declared output of a target `beta`. Suppose `beta` has a target `charlie` as one of its `deps`. If `apply\_to\_generating\_rules=True` for the aspect, then the aspect will propagate through `alpha`, `beta`, and `charlie`. If False, then the aspect will propagate only to `alpha`.  False by default. |
-| `exec_compatible_with` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  A list of constraints on the execution platform that apply to all instances of this aspect. |
-| `exec_groups` | [dict](../core/dict); or `None`; default is `None`  Dict of execution group name (string) to [`exec_group`s](../globals/bzl#exec_group). If set, allows aspects to run actions on multiple execution platforms within a single instance. See [execution groups documentation](/versions/8.5.1/reference/exec-groups) for more info. |
-| `subrules` | [sequence](../core/list) of [Subrule](../builtins/Subrule)s; default is `[]`  Experimental: list of subrules used by this aspect. |
+| `implementation` | [function](/versions/8.5.1/rules/lib/core/function); required  A Starlark function that implements this aspect, with exactly two parameters: [Target](/versions/8.5.1/rules/lib/builtins/Target) (the target to which the aspect is applied) and [ctx](/versions/8.5.1/rules/lib/builtins/ctx) (the rule context which the target is created from). Attributes of the target are available via the `ctx.rule` field. This function is evaluated during the analysis phase for each application of an aspect to a target. |
+| `attr_aspects` | [sequence](/versions/8.5.1/rules/lib/core/list) of [string](/versions/8.5.1/rules/lib/core/string)s; default is `[]`  List of attribute names. The aspect propagates along dependencies specified in the attributes of a target with these names. Common values here include `deps` and `exports`. The list can also contain a single string `"*"` to propagate along all dependencies of a target. |
+| `toolchains_aspects` | [sequence](/versions/8.5.1/rules/lib/core/list); default is `[]`  List of toolchain types. The aspect propagates to target toolchains which match these toolchain types. |
+| `attrs` | [dict](/versions/8.5.1/rules/lib/core/dict); default is `{}`  A dictionary declaring all the attributes of the aspect. It maps from an attribute name to an attribute object, like `attr.label` or `attr.string` (see [`attr`](/versions/8.5.1/rules/lib/toplevel/attr) module). Aspect attributes are available to implementation function as fields of `ctx` parameter. Implicit attributes starting with `_` must have default values, and have type `label` or `label_list`.  Explicit attributes must have type `string`, and must use the `values` restriction. Explicit attributes restrict the aspect to only be used with rules that have attributes of the same name, type, and valid values according to the restriction.  Declared attributes will convert `None` to the default value. |
+| `required_providers` | [sequence](/versions/8.5.1/rules/lib/core/list); default is `[]`  This attribute allows the aspect to limit its propagation to only the targets whose rules advertise its required providers. The value must be a list containing either individual providers or lists of providers but not both. For example, `[[FooInfo], [BarInfo], [BazInfo, QuxInfo]]` is a valid value while `[FooInfo, BarInfo, [BazInfo, QuxInfo]]` is not valid. An unnested list of providers will automatically be converted to a list containing one list of providers. That is, `[FooInfo, BarInfo]` will automatically be converted to `[[FooInfo, BarInfo]]`. To make some rule (e.g. `some_rule`) targets visible to an aspect, `some_rule` must advertise all providers from at least one of the required providers lists. For example, if the `required_providers` of an aspect are `[[FooInfo], [BarInfo], [BazInfo, QuxInfo]]`, this aspect can see `some_rule` targets if and only if `some_rule` provides `FooInfo`, *or* `BarInfo`, *or* both `BazInfo` *and* `QuxInfo`. |
+| `required_aspect_providers` | [sequence](/versions/8.5.1/rules/lib/core/list); default is `[]`  This attribute allows this aspect to inspect other aspects. The value must be a list containing either individual providers or lists of providers but not both. For example, `[[FooInfo], [BarInfo], [BazInfo, QuxInfo]]` is a valid value while `[FooInfo, BarInfo, [BazInfo, QuxInfo]]` is not valid. An unnested list of providers will automatically be converted to a list containing one list of providers. That is, `[FooInfo, BarInfo]` will automatically be converted to `[[FooInfo, BarInfo]]`. To make another aspect (e.g. `other_aspect`) visible to this aspect, `other_aspect` must provide all providers from at least one of the lists. In the example of `[[FooInfo], [BarInfo], [BazInfo, QuxInfo]]`, this aspect can see `other_aspect` if and only if `other_aspect` provides `FooInfo`, *or* `BarInfo`, *or* both `BazInfo` *and* `QuxInfo`. |
+| `provides` | [sequence](/versions/8.5.1/rules/lib/core/list); default is `[]`  A list of providers that the implementation function must return. It is an error if the implementation function omits any of the types of providers listed here from its return value. However, the implementation function may return additional providers not listed here. Each element of the list is an `*Info` object returned by [`provider()`](/versions/8.5.1/rules/lib/globals/bzl#provider), except that a legacy provider is represented by its string name instead.When a target of the rule is used as a dependency for a target that declares a required provider, it is not necessary to specify that provider here. It is enough that the implementation function returns it. However, it is considered best practice to specify it, even though this is not required. The [`required_providers`](/versions/8.5.1/rules/lib/globals/bzl#aspect.required_providers) field of an [aspect](/versions/8.5.1/rules/lib/globals/bzl#aspect) does, however, require that providers are specified here. |
+| `requires` | [sequence](/versions/8.5.1/rules/lib/core/list) of [Aspect](/versions/8.5.1/rules/lib/builtins/Aspect)s; default is `[]`  List of aspects required to be propagated before this aspect. |
+| `fragments` | [sequence](/versions/8.5.1/rules/lib/core/list) of [string](/versions/8.5.1/rules/lib/core/string)s; default is `[]`  List of names of configuration fragments that the aspect requires in target configuration. |
+| `host_fragments` | [sequence](/versions/8.5.1/rules/lib/core/list) of [string](/versions/8.5.1/rules/lib/core/string)s; default is `[]`  List of names of configuration fragments that the aspect requires in host configuration. |
+| `toolchains` | [sequence](/versions/8.5.1/rules/lib/core/list); default is `[]`  If set, the set of toolchains this aspect requires. The list can contain String, Label, or StarlarkToolchainTypeApi objects, in any combination. Toolchains will be found by checking the current platform, and provided to the aspect implementation via `ctx.toolchain`. |
+| `incompatible_use_toolchain_transition` | [bool](/versions/8.5.1/rules/lib/core/bool); default is `False`  Deprecated, this is no longer in use and should be removed. |
+| `doc` | [string](/versions/8.5.1/rules/lib/core/string); or `None`; default is `None`  A description of the aspect that can be extracted by documentation generating tools. |
+| `apply_to_generating_rules` | [bool](/versions/8.5.1/rules/lib/core/bool); default is `False`  If true, the aspect will, when applied to an output file, instead apply to the output file's generating rule. For example, suppose an aspect propagates transitively through attribute `deps` and it is applied to target `alpha`. Suppose `alpha` has `deps = [':beta\_output']`, where `beta\_output` is a declared output of a target `beta`. Suppose `beta` has a target `charlie` as one of its `deps`. If `apply\_to\_generating\_rules=True` for the aspect, then the aspect will propagate through `alpha`, `beta`, and `charlie`. If False, then the aspect will propagate only to `alpha`.  False by default. |
+| `exec_compatible_with` | [sequence](/versions/8.5.1/rules/lib/core/list) of [string](/versions/8.5.1/rules/lib/core/string)s; default is `[]`  A list of constraints on the execution platform that apply to all instances of this aspect. |
+| `exec_groups` | [dict](/versions/8.5.1/rules/lib/core/dict); or `None`; default is `None`  Dict of execution group name (string) to [`exec_group`s](/versions/8.5.1/rules/lib/globals/bzl#exec_group). If set, allows aspects to run actions on multiple execution platforms within a single instance. See [execution groups documentation](/versions/8.5.1/reference/exec-groups) for more info. |
+| `subrules` | [sequence](/versions/8.5.1/rules/lib/core/list) of [Subrule](/versions/8.5.1/rules/lib/builtins/Subrule)s; default is `[]`  Experimental: list of subrules used by this aspect. |
 
 ## configuration\_field
 
@@ -74,7 +74,7 @@ Creates a new aspect. The result of this function must be stored in a global val
 LateBoundDefault configuration_field(fragment, name)
 ```
 
-References a late-bound default value for an attribute of type [label](../toplevel/attr#label). A value is 'late-bound' if it requires the configuration to be built before determining the value. Any attribute using this as a value must [be private](https://bazel.build/versions/8.5.1/extending/rules#private-attributes).
+References a late-bound default value for an attribute of type [label](/versions/8.5.1/rules/lib/toplevel/attr#label). A value is 'late-bound' if it requires the configuration to be built before determining the value. Any attribute using this as a value must [be private](https://bazel.build/versions/8.5.1/extending/rules#private-attributes).
 
 Example usage:
 
@@ -96,8 +96,8 @@ Accessing in rule implementation:
 
 | Parameter | Description |
 | --- | --- |
-| `fragment` | [string](../core/string); required |
-| `name` | [string](../core/string); required |
+| `fragment` | [string](/versions/8.5.1/rules/lib/core/string); required |
+| `name` | [string](/versions/8.5.1/rules/lib/core/string); required |
 
 ## depset
 
@@ -105,7 +105,7 @@ Accessing in rule implementation:
 depset depset(direct=None, order="default", *, transitive=None)
 ```
 
-Creates a [depset](../builtins/depset). The `direct` parameter is a list of direct elements of the depset, and `transitive` parameter is a list of depsets whose elements become indirect elements of the created depset. The order in which elements are returned when the depset is converted to a list is specified by the `order` parameter. See the [Depsets overview](https://bazel.build/versions/8.5.1/extending/depsets) for more information.
+Creates a [depset](/versions/8.5.1/rules/lib/builtins/depset). The `direct` parameter is a list of direct elements of the depset, and `transitive` parameter is a list of depsets whose elements become indirect elements of the created depset. The order in which elements are returned when the depset is converted to a list is specified by the `order` parameter. See the [Depsets overview](https://bazel.build/versions/8.5.1/extending/depsets) for more information.
 
 All elements (direct and indirect) of a depset must be of the same type, as obtained by the expression `type(x)`.
 
@@ -119,9 +119,9 @@ The order of the created depset should be *compatible* with the order of its `tr
 
 | Parameter | Description |
 | --- | --- |
-| `direct` | [sequence](../core/list); or `None`; default is `None`  A list of *direct* elements of a depset. |
-| `order` | [string](../core/string); default is `"default"`  The traversal strategy for the new depset. See [here](../builtins/depset) for the possible values. |
-| `transitive` | [sequence](../core/list) of [depset](../builtins/depset)s; or `None`; default is `None`  A list of depsets whose elements will become indirect elements of the depset. |
+| `direct` | [sequence](/versions/8.5.1/rules/lib/core/list); or `None`; default is `None`  A list of *direct* elements of a depset. |
+| `order` | [string](/versions/8.5.1/rules/lib/core/string); default is `"default"`  The traversal strategy for the new depset. See [here](/versions/8.5.1/rules/lib/builtins/depset) for the possible values. |
+| `transitive` | [sequence](/versions/8.5.1/rules/lib/core/list) of [depset](/versions/8.5.1/rules/lib/builtins/depset)s; or `None`; default is `None`  A list of depsets whose elements will become indirect elements of the depset. |
 
 ## exec\_group
 
@@ -135,8 +135,8 @@ Creates an [execution group](/versions/8.5.1/reference/exec-groups) which can be
 
 | Parameter | Description |
 | --- | --- |
-| `toolchains` | [sequence](../core/list); default is `[]`  The set of toolchains this execution group requires. The list can contain String, Label, or StarlarkToolchainTypeApi objects, in any combination. |
-| `exec_compatible_with` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  A list of constraints on the execution platform. |
+| `toolchains` | [sequence](/versions/8.5.1/rules/lib/core/list); default is `[]`  The set of toolchains this execution group requires. The list can contain String, Label, or StarlarkToolchainTypeApi objects, in any combination. |
+| `exec_compatible_with` | [sequence](/versions/8.5.1/rules/lib/core/list) of [string](/versions/8.5.1/rules/lib/core/string)s; default is `[]`  A list of constraints on the execution platform. |
 
 ## exec\_transition
 
@@ -144,15 +144,15 @@ Creates an [execution group](/versions/8.5.1/reference/exec-groups) which can be
 transition exec_transition(implementation, inputs, outputs)
 ```
 
-A specialized version of [`transition()`](../builtins/transition) used to define the exec transition. See its documentation (or its implementation) for best practices. Only usable from the Bazel builtins.
+A specialized version of [`transition()`](/versions/8.5.1/rules/lib/builtins/transition) used to define the exec transition. See its documentation (or its implementation) for best practices. Only usable from the Bazel builtins.
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
 | `implementation` | callable; required |
-| `inputs` | [sequence](../core/list) of [string](../core/string)s; required |
-| `outputs` | [sequence](../core/list) of [string](../core/string)s; required |
+| `inputs` | [sequence](/versions/8.5.1/rules/lib/core/list) of [string](/versions/8.5.1/rules/lib/core/string)s; required |
+| `outputs` | [sequence](/versions/8.5.1/rules/lib/core/list) of [string](/versions/8.5.1/rules/lib/core/string)s; required |
 
 ## macro
 
@@ -173,11 +173,11 @@ macros.
 
 | Parameter | Description |
 | --- | --- |
-| `implementation` | [function](../core/function); required  The Starlark function implementing this macro. The values of the macro's attributes are passed to the implementation function as keyword arguments. The implementation function must have at least two named parameters, `name` and `visibility`, and if the macro inherits attributes (see `inherit_attrs` below), it must have a `**kwargs` residual keyword parameter. By convention, the implementation function should have a named parameter for any attribute that the macro needs to examine, modify, or pass to non-"main" targets, while the "bulk" inherited attributes which will be passed to the "main" target unchanged are passed as `**kwargs`. The implementation function must not return a value. Instead, the implementation function *declares targets* by calling rule or macro symbols. The name of any target or inner symbolic macro declared by a symbolic macro (including by any Starlark function that the macro's implementation function transitively calls) must either equal `name` (this is referred to as the "main" target) or start with `name`, followed by a separator chracter (`"_"`, `"-"`, or `"."`) and a string suffix. (Targets violating this naming scheme are allowed to be declared, but cannot be built, configured, or depended upon.) By default, targets declared by a symbolic macro (including by any Starlark function that the macro's implementation function transitively calls) are visible only in the package containing the .bzl file defining the macro. To declare targets visible externally, *including to the caller of the symbolic macro*, the implementation function must set `visibility` appropriately – typically, by passing `visibility = visibility` to the rule or macro symbol being called. The following APIs are unavailable within a macro implementation function and any Starlark function it transitively calls:  * [`package()`, `licenses()`* `environment_group()`* [`native.glob()`](../toplevel/native#glob) – instead, you may pass       a glob into the macro via a label list attribute* [`native.subpackages()`](../toplevel/native#subpackages)* (allowed in rule finalizers only, see `finalizer` below)           [`native.existing_rules()`](../toplevel/native#existing_rules),           [`native.existing_rule()`](../toplevel/native#existing_rule)* (for `WORKSPACE` threads)             [`workspace()`](../globals/workspace#workspace),             [`register_toolchains()`](../globals/workspace#register_toolchains),             [`bind()`](../globals/workspace#bind), [`register_execution_platforms()`](../globals/workspace#register_execution_platforms), [repository rule instantiation](/versions/8.5.1/reference/be/functions#package) |
-| `attrs` | [dict](../core/dict); default is `{}`  A dictionary of the attributes this macro supports, analogous to [rule.attrs](#rule.attrs). Keys are attribute names, and values are either attribute objects like `attr.label_list(...)` (see the [attr](../toplevel/attr) module), or `None`. A `None` entry means that the macro does not have an attribute by that name, even if it would have otherwise inherited one via `inherit_attrs` (see below). The special `name` attribute is predeclared and must not be included in the dictionary. The `visibility` attribute name is reserved and must not be included in the dictionary. Attributes whose names start with `_` are private -- they cannot be passed at the call site of the rule. Such attributes can be assigned a default value (as in `attr.label(default="//pkg:foo")`) to create an implicit dependency on a label. To limit memory usage, there is a cap on the number of attributes that may be declared. |
-| `inherit_attrs` | [rule](../builtins/rule); or [macro](../builtins/macro); or [string](../core/string); or `None`; default is `None`  A rule symbol, macro symbol, or the name of a built-in common attribute list (see below) from which the macro should inherit attributes. If `inherit_attrs` is set to the string `"common"`, the macro will inherit [common rule attribute definitions](/versions/8.5.1/reference/be/common-definitions#common-attributes) used by all Starlark rules. Note that if the return value of `rule()` or `macro()` was not assigned to a global variable in a .bzl file, then such a value has not been registered as a rule or macro symbol, and therefore cannot be used for `inherit_attrs`. The inheritance mechanism works as follows:   1. The special `name` and `visibility` attributes are never inherited;- Hidden attributes (ones whose name starts with `"_"`) are never inherited;- Attributes whose names are already defined in the `attrs` dictionary are never        inherited (the entry in `attrs` takes precedence; note that an entry may be set to        `None` to ensure that no attribute by that name gets defined on the macro);- All other attributes are inherited from the rule or macro and effectively merged into the          `attrs` dict.   When a non-mandatory attribute is inherited, the default value of the attribute is overridden to be `None`, regardless of what it was specified in the original rule or macro. This ensures that when the macro forwards the attribute's value to an instance of the wrapped rule or macro – such as by passing in the unmodified `**kwargs` – a value that was absent from the outer macro's call will also be absent in the inner rule or macro's call (since passing `None` to an attribute is treated the same as omitting the attribute). This is important because omitting an attribute has subtly different semantics from passing its apparent default value. In particular, omitted attributes are not shown in some `bazel query` output formats, and computed defaults only execute when the value is omitted. If the macro needs to examine or modify an inherited attribute – for example, to add a value to an inherited `tags` attribute – you must make sure to handle the `None` case in the macro's implementation function. For example, the following macro inherits all attributes from `native.cc_library`, except for `cxxopts` (which is removed from the attribute list) and `copts` (which is given a new definition). It also takes care to checks for the default `None` value of the inherited `tags` attribute before appending an additional tag.  ``` def _my_cc_library_impl(name, visibility, tags, **kwargs):     # Append a tag; tags attr was inherited from native.cc_library, and     # therefore is None unless explicitly set by the caller of my_cc_library()     my_tags = (tags or []) + ["my_custom_tag"]     native.cc_library(         name = name,         visibility = visibility,         tags = my_tags,         **kwargs     )  my_cc_library = macro(     implementation = _my_cc_library_impl,     inherit_attrs = native.cc_library,     attrs = {         "cxxopts": None,         "copts": attr.string_list(default = ["-D_FOO"]),     }, ) ```   If `inherit_attrs` is set, the macro's implementation function *must* have a `**kwargs` residual keyword parameter. By convention, a macro should pass inherited, non-overridden attributes unchanged to the "main" rule or macro symbol which the macro is wrapping. Typically, most inherited attributes will not have a parameter in the implementation function's parameter list, and will simply be passed via `**kwargs`. It can be convenient for the implementation function to have explicit parameters for some inherited attributes (most commonly, `tags` and `testonly`) if the macro needs to pass those attributes to both "main" and non-"main" targets – but if the macro also needs to examine or manipulate those attributes, you must take care to handle the `None` default value of non-mandatory inherited attributes. |
-| `finalizer` | [bool](../core/bool); default is `False`  Whether this macro is a rule finalizer, which is a macro that, regardless of its position in a `BUILD` file, is evaluated at the end of package loading, after all non-finalizer targets have been defined. Unlike ordinary symbolic macros, rule finalizers may call [`native.existing_rule()`](../toplevel/native#existing_rule) and [`native.existing_rules()`](../toplevel/native#existing_rules) to query the set of *non-finalizer* rule targets defined in the current package. Note that `native.existing_rule()` and `native.existing_rules()` cannot access the targets defined by any rule finalizer, including this one. |
-| `doc` | [string](../core/string); or `None`; default is `None`  A description of the macro that can be extracted by documentation generating tools. |
+| `implementation` | [function](/versions/8.5.1/rules/lib/core/function); required  The Starlark function implementing this macro. The values of the macro's attributes are passed to the implementation function as keyword arguments. The implementation function must have at least two named parameters, `name` and `visibility`, and if the macro inherits attributes (see `inherit_attrs` below), it must have a `**kwargs` residual keyword parameter. By convention, the implementation function should have a named parameter for any attribute that the macro needs to examine, modify, or pass to non-"main" targets, while the "bulk" inherited attributes which will be passed to the "main" target unchanged are passed as `**kwargs`. The implementation function must not return a value. Instead, the implementation function *declares targets* by calling rule or macro symbols. The name of any target or inner symbolic macro declared by a symbolic macro (including by any Starlark function that the macro's implementation function transitively calls) must either equal `name` (this is referred to as the "main" target) or start with `name`, followed by a separator chracter (`"_"`, `"-"`, or `"."`) and a string suffix. (Targets violating this naming scheme are allowed to be declared, but cannot be built, configured, or depended upon.) By default, targets declared by a symbolic macro (including by any Starlark function that the macro's implementation function transitively calls) are visible only in the package containing the .bzl file defining the macro. To declare targets visible externally, *including to the caller of the symbolic macro*, the implementation function must set `visibility` appropriately – typically, by passing `visibility = visibility` to the rule or macro symbol being called. The following APIs are unavailable within a macro implementation function and any Starlark function it transitively calls:  * [`package()`, `licenses()`* `environment_group()`* [`native.glob()`](/versions/8.5.1/rules/lib/toplevel/native#glob) – instead, you may pass       a glob into the macro via a label list attribute* [`native.subpackages()`](/versions/8.5.1/rules/lib/toplevel/native#subpackages)* (allowed in rule finalizers only, see `finalizer` below)           [`native.existing_rules()`](/versions/8.5.1/rules/lib/toplevel/native#existing_rules),           [`native.existing_rule()`](/versions/8.5.1/rules/lib/toplevel/native#existing_rule)* (for `WORKSPACE` threads)             [`workspace()`](/versions/8.5.1/rules/lib/globals/workspace#workspace),             [`register_toolchains()`](/versions/8.5.1/rules/lib/globals/workspace#register_toolchains),             [`bind()`](/versions/8.5.1/rules/lib/globals/workspace#bind), [`register_execution_platforms()`](/versions/8.5.1/rules/lib/globals/workspace#register_execution_platforms), [repository rule instantiation](/versions/8.5.1/reference/be/functions#package) |
+| `attrs` | [dict](/versions/8.5.1/rules/lib/core/dict); default is `{}`  A dictionary of the attributes this macro supports, analogous to [rule.attrs](#rule.attrs). Keys are attribute names, and values are either attribute objects like `attr.label_list(...)` (see the [attr](/versions/8.5.1/rules/lib/toplevel/attr) module), or `None`. A `None` entry means that the macro does not have an attribute by that name, even if it would have otherwise inherited one via `inherit_attrs` (see below). The special `name` attribute is predeclared and must not be included in the dictionary. The `visibility` attribute name is reserved and must not be included in the dictionary. Attributes whose names start with `_` are private -- they cannot be passed at the call site of the rule. Such attributes can be assigned a default value (as in `attr.label(default="//pkg:foo")`) to create an implicit dependency on a label. To limit memory usage, there is a cap on the number of attributes that may be declared. |
+| `inherit_attrs` | [rule](/versions/8.5.1/rules/lib/builtins/rule); or [macro](/versions/8.5.1/rules/lib/builtins/macro); or [string](/versions/8.5.1/rules/lib/core/string); or `None`; default is `None`  A rule symbol, macro symbol, or the name of a built-in common attribute list (see below) from which the macro should inherit attributes. If `inherit_attrs` is set to the string `"common"`, the macro will inherit [common rule attribute definitions](/versions/8.5.1/reference/be/common-definitions#common-attributes) used by all Starlark rules. Note that if the return value of `rule()` or `macro()` was not assigned to a global variable in a .bzl file, then such a value has not been registered as a rule or macro symbol, and therefore cannot be used for `inherit_attrs`. The inheritance mechanism works as follows:   1. The special `name` and `visibility` attributes are never inherited;- Hidden attributes (ones whose name starts with `"_"`) are never inherited;- Attributes whose names are already defined in the `attrs` dictionary are never        inherited (the entry in `attrs` takes precedence; note that an entry may be set to        `None` to ensure that no attribute by that name gets defined on the macro);- All other attributes are inherited from the rule or macro and effectively merged into the          `attrs` dict.   When a non-mandatory attribute is inherited, the default value of the attribute is overridden to be `None`, regardless of what it was specified in the original rule or macro. This ensures that when the macro forwards the attribute's value to an instance of the wrapped rule or macro – such as by passing in the unmodified `**kwargs` – a value that was absent from the outer macro's call will also be absent in the inner rule or macro's call (since passing `None` to an attribute is treated the same as omitting the attribute). This is important because omitting an attribute has subtly different semantics from passing its apparent default value. In particular, omitted attributes are not shown in some `bazel query` output formats, and computed defaults only execute when the value is omitted. If the macro needs to examine or modify an inherited attribute – for example, to add a value to an inherited `tags` attribute – you must make sure to handle the `None` case in the macro's implementation function. For example, the following macro inherits all attributes from `native.cc_library`, except for `cxxopts` (which is removed from the attribute list) and `copts` (which is given a new definition). It also takes care to checks for the default `None` value of the inherited `tags` attribute before appending an additional tag.  ``` def _my_cc_library_impl(name, visibility, tags, **kwargs):     # Append a tag; tags attr was inherited from native.cc_library, and     # therefore is None unless explicitly set by the caller of my_cc_library()     my_tags = (tags or []) + ["my_custom_tag"]     native.cc_library(         name = name,         visibility = visibility,         tags = my_tags,         **kwargs     )  my_cc_library = macro(     implementation = _my_cc_library_impl,     inherit_attrs = native.cc_library,     attrs = {         "cxxopts": None,         "copts": attr.string_list(default = ["-D_FOO"]),     }, ) ```   If `inherit_attrs` is set, the macro's implementation function *must* have a `**kwargs` residual keyword parameter. By convention, a macro should pass inherited, non-overridden attributes unchanged to the "main" rule or macro symbol which the macro is wrapping. Typically, most inherited attributes will not have a parameter in the implementation function's parameter list, and will simply be passed via `**kwargs`. It can be convenient for the implementation function to have explicit parameters for some inherited attributes (most commonly, `tags` and `testonly`) if the macro needs to pass those attributes to both "main" and non-"main" targets – but if the macro also needs to examine or manipulate those attributes, you must take care to handle the `None` default value of non-mandatory inherited attributes. |
+| `finalizer` | [bool](/versions/8.5.1/rules/lib/core/bool); default is `False`  Whether this macro is a rule finalizer, which is a macro that, regardless of its position in a `BUILD` file, is evaluated at the end of package loading, after all non-finalizer targets have been defined. Unlike ordinary symbolic macros, rule finalizers may call [`native.existing_rule()`](/versions/8.5.1/rules/lib/toplevel/native#existing_rule) and [`native.existing_rules()`](/versions/8.5.1/rules/lib/toplevel/native#existing_rules) to query the set of *non-finalizer* rule targets defined in the current package. Note that `native.existing_rule()` and `native.existing_rules()` cannot access the targets defined by any rule finalizer, including this one. |
+| `doc` | [string](/versions/8.5.1/rules/lib/core/string); or `None`; default is `None`  A description of the macro that can be extracted by documentation generating tools. |
 
 ## module\_extension
 
@@ -192,11 +192,11 @@ Creates a new module extension. Store it in a global value, so that it can be ex
 | Parameter | Description |
 | --- | --- |
 | `implementation` | callable; required  The function that implements this module extension. Must take a single parameter, `module_ctx`. The function is called once at the beginning of a build to determine the set of available repos. |
-| `tag_classes` | [dict](../core/dict); default is `{}`  A dictionary to declare all the tag classes used by the extension. It maps from the name of the tag class to a `tag_class` object. |
-| `doc` | [string](../core/string); or `None`; default is `None`  A description of the module extension that can be extracted by documentation generating tools. |
-| `environ` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  Provides a list of environment variable that this module extension depends on. If an environment variable in that list changes, the extension will be re-evaluated. |
-| `os_dependent` | [bool](../core/bool); default is `False`  Indicates whether this extension is OS-dependent or not |
-| `arch_dependent` | [bool](../core/bool); default is `False`  Indicates whether this extension is architecture-dependent or not |
+| `tag_classes` | [dict](/versions/8.5.1/rules/lib/core/dict); default is `{}`  A dictionary to declare all the tag classes used by the extension. It maps from the name of the tag class to a `tag_class` object. |
+| `doc` | [string](/versions/8.5.1/rules/lib/core/string); or `None`; default is `None`  A description of the module extension that can be extracted by documentation generating tools. |
+| `environ` | [sequence](/versions/8.5.1/rules/lib/core/list) of [string](/versions/8.5.1/rules/lib/core/string)s; default is `[]`  Provides a list of environment variable that this module extension depends on. If an environment variable in that list changes, the extension will be re-evaluated. |
+| `os_dependent` | [bool](/versions/8.5.1/rules/lib/core/bool); default is `False`  Indicates whether this extension is OS-dependent or not |
+| `arch_dependent` | [bool](/versions/8.5.1/rules/lib/core/bool); default is `False`  Indicates whether this extension is architecture-dependent or not |
 
 ## provider
 
@@ -219,16 +219,16 @@ def _my_library_impl(ctx):
 
 See [Rules (Providers)](https://bazel.build/versions/8.5.1/extending/rules#providers) for a comprehensive guide on how to use providers.
 
-Returns a [`Provider`](../builtins/Provider) callable value if `init` is not specified.
+Returns a [`Provider`](/versions/8.5.1/rules/lib/builtins/Provider) callable value if `init` is not specified.
 
-If `init` is specified, returns a tuple of 2 elements: a [`Provider`](../builtins/Provider) callable value and a *raw constructor* callable value. See  [Rules (Custom initialization of custom providers)](https://bazel.build/versions/8.5.1/extending/rules#custom_initialization_of_providers) and the discussion of the `init` parameter below for details.
+If `init` is specified, returns a tuple of 2 elements: a [`Provider`](/versions/8.5.1/rules/lib/builtins/Provider) callable value and a *raw constructor* callable value. See  [Rules (Custom initialization of custom providers)](https://bazel.build/versions/8.5.1/extending/rules#custom_initialization_of_providers) and the discussion of the `init` parameter below for details.
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `doc` | [string](../core/string); or `None`; default is `None` |
-| `fields` | [sequence](../core/list) of [string](../core/string)s; or [dict](../core/dict); or `None`; default is `None`  If specified, restricts the set of allowed fields.  Possible values are:  * list of fields:     ```   provider(fields = ['a', 'b'])   ```     * dictionary field name -> documentation:       ```     provider(            fields = { 'a' : 'Documentation for a', 'b' : 'Documentation for b' })     ```  All fields are optional. |
+| `doc` | [string](/versions/8.5.1/rules/lib/core/string); or `None`; default is `None` |
+| `fields` | [sequence](/versions/8.5.1/rules/lib/core/list) of [string](/versions/8.5.1/rules/lib/core/string)s; or [dict](/versions/8.5.1/rules/lib/core/dict); or `None`; default is `None`  If specified, restricts the set of allowed fields.  Possible values are:  * list of fields:     ```   provider(fields = ['a', 'b'])   ```     * dictionary field name -> documentation:       ```     provider(            fields = { 'a' : 'Documentation for a', 'b' : 'Documentation for b' })     ```  All fields are optional. |
 | `init` | callable; or `None`; default is `None` |
 
 ## repository\_rule
@@ -237,19 +237,19 @@ If `init` is specified, returns a tuple of 2 elements: a [`Provider`](../builtin
 callable repository_rule(implementation, *, attrs=None, local=False, environ=[], configure=False, remotable=False, doc=None)
 ```
 
-Creates a new repository rule. Store it in a global value, so that it can be loaded and called from a [`module_extension()`](#module_extension) implementation function, or used by [`use_repo_rule()`](../globals/module#use_repo_rule).
+Creates a new repository rule. Store it in a global value, so that it can be loaded and called from a [`module_extension()`](#module_extension) implementation function, or used by [`use_repo_rule()`](/versions/8.5.1/rules/lib/globals/module#use_repo_rule).
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
 | `implementation` | callable; required |
-| `attrs` | [dict](../core/dict); or `None`; default is `None` |
-| `local` | [bool](../core/bool); default is `False`  Indicate that this rule fetches everything from the local system and should be reevaluated at every fetch. |
-| `environ` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  **Deprecated**. This parameter has been deprecated. Migrate to `repository_ctx.getenv` instead. Provides a list of environment variable that this repository rule depends on. If an environment variable in that list change, the repository will be refetched. |
-| `configure` | [bool](../core/bool); default is `False`  Indicate that the repository inspects the system for configuration purpose |
-| `remotable` | [bool](../core/bool); default is `False`  **Experimental**. This parameter is experimental and may change at any time. Please do not depend on it. It may be enabled on an experimental basis by setting `--experimental_repo_remote_exec`  Compatible with remote execution |
-| `doc` | [string](../core/string); or `None`; default is `None` |
+| `attrs` | [dict](/versions/8.5.1/rules/lib/core/dict); or `None`; default is `None` |
+| `local` | [bool](/versions/8.5.1/rules/lib/core/bool); default is `False`  Indicate that this rule fetches everything from the local system and should be reevaluated at every fetch. |
+| `environ` | [sequence](/versions/8.5.1/rules/lib/core/list) of [string](/versions/8.5.1/rules/lib/core/string)s; default is `[]`  **Deprecated**. This parameter has been deprecated. Migrate to `repository_ctx.getenv` instead. Provides a list of environment variable that this repository rule depends on. If an environment variable in that list change, the repository will be refetched. |
+| `configure` | [bool](/versions/8.5.1/rules/lib/core/bool); default is `False`  Indicate that the repository inspects the system for configuration purpose |
+| `remotable` | [bool](/versions/8.5.1/rules/lib/core/bool); default is `False`  **Experimental**. This parameter is experimental and may change at any time. Please do not depend on it. It may be enabled on an experimental basis by setting `--experimental_repo_remote_exec`  Compatible with remote execution |
+| `doc` | [string](/versions/8.5.1/rules/lib/core/string); or `None`; default is `None` |
 
 ## rule
 
@@ -267,29 +267,29 @@ Test rules are required to have a name ending in `_test`, while all other rules
 
 | Parameter | Description |
 | --- | --- |
-| `implementation` | [function](../core/function); required  the Starlark function implementing this rule, must have exactly one parameter: [ctx](../builtins/ctx). The function is called during the analysis phase for each instance of the rule. It can access the attributes provided by the user. It must create actions to generate all the declared outputs. |
-| `test` | [bool](../core/bool); default is `unbound`  Whether this rule is a test rule, that is, whether it may be the subject of a `blaze test` command. All test rules are automatically considered [executable](#rule.executable); it is unnecessary (and discouraged) to explicitly set `executable = True` for a test rule. The value defaults to `False`. See the  [Rules page](https://bazel.build/versions/8.5.1/extending/rules#executable_rules_and_test_rules) for more information. |
-| `attrs` | [dict](../core/dict); default is `{}`  A dictionary to declare all the attributes of the rule. It maps from an attribute name to an attribute object (see [`attr`](../toplevel/attr) module). Attributes starting with `_` are private, and can be used to add an implicit dependency on a label. The attribute `name` is implicitly added and must not be specified. Attributes `visibility`, `deprecation`, `tags`, `testonly`, and `features` are implicitly added and cannot be overridden. Most rules need only a handful of attributes. To limit memory usage, there is a cap on the number of attributes that may be declared. Declared attributes will convert `None` to the default value. |
-| `outputs` | [dict](../core/dict); or `None`; or [function](../core/function); default is `None`  **Deprecated**. This parameter is deprecated and will be removed soon. Please do not depend on it. It is *disabled* with `--incompatible_no_rule_outputs_param`. Use this flag to verify your code is compatible with its imminent removal.  This parameter has been deprecated. Migrate rules to use `OutputGroupInfo` or `attr.output` instead. A schema for defining predeclared outputs. Unlike [`output`](../toplevel/attr#output) and [`output_list`](../toplevel/attr#output_list) attributes, the user does not specify the labels for these files. See the [Rules page](https://bazel.build/versions/8.5.1/extending/rules#files) for more on predeclared outputs. The value of this argument is either a dictionary or a callback function that produces a dictionary. The callback works similar to computed dependency attributes: The function's parameter names are matched against the rule's attributes, so for example if you pass `outputs = _my_func` with the definition `def _my_func(srcs, deps): ...`, the function has access to the attributes `srcs` and `deps`. Whether the dictionary is specified directly or via a function, it is interpreted as follows. Each entry in the dictionary creates a predeclared output where the key is an identifier and the value is a string template that determines the output's label. In the rule's implementation function, the identifier becomes the field name used to access the output's [`File`](../builtins/File) in [`ctx.outputs`](../builtins/ctx#outputs). The output's label has the same package as the rule, and the part after the package is produced by substituting each placeholder of the form `"%{ATTR}"` with a string formed from the value of the attribute `ATTR`:  * String-typed attributes are substituted verbatim.* Label-typed attributes become the part of the label after the package, minus the file extension. For example, the label `"//pkg:a/b.c"` becomes `"a/b"`.* Output-typed attributes become the part of the label after the package, including the file extension (for the above example, `"a/b.c"`).* All list-typed attributes (for example, `attr.label_list`) used in placeholders are required to have *exactly one element*. Their conversion is the same as their non-list version (`attr.label`).* Other attribute types may not appear in placeholders.* The special non-attribute placeholders `%{dirname}` and `%{basename}` expand to those parts of the rule's label, excluding its package. For example, in `"//pkg:a/b.c"`, the dirname is `a` and the basename is `b.c`.   In practice, the most common substitution placeholder is `"%{name}"`. For example, for a target named "foo", the outputs dict `{"bin": "%{name}.exe"}` predeclares an output named `foo.exe` that is accessible in the implementation function as `ctx.outputs.bin`. |
-| `executable` | [bool](../core/bool); default is `unbound` |
-| `output_to_genfiles` | [bool](../core/bool); default is `False`  If true, the files will be generated in the genfiles directory instead of the bin directory. Unless you need it for compatibility with existing rules (e.g. when generating header files for C++), do not set this flag. |
-| `fragments` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  List of names of configuration fragments that the rule requires in target configuration. |
-| `host_fragments` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  List of names of configuration fragments that the rule requires in host configuration. |
-| `_skylark_testable` | [bool](../core/bool); default is `False`  *(Experimental)*  If true, this rule will expose its actions for inspection by rules that depend on it via an `Actions` provider. The provider is also available to the rule itself by calling [ctx.created\_actions()](../builtins/ctx#created_actions).  This should only be used for testing the analysis-time behavior of Starlark rules. This flag may be removed in the future. |
-| `toolchains` | [sequence](../core/list); default is `[]`  If set, the set of toolchains this rule requires. The list can contain String, Label, or StarlarkToolchainTypeApi objects, in any combination. Toolchains will be found by checking the current platform, and provided to the rule implementation via `ctx.toolchain`. |
-| `incompatible_use_toolchain_transition` | [bool](../core/bool); default is `False`  Deprecated, this is no longer in use and should be removed. |
-| `doc` | [string](../core/string); or `None`; default is `None`  A description of the rule that can be extracted by documentation generating tools. |
-| `provides` | [sequence](../core/list); default is `[]`  A list of providers that the implementation function must return. It is an error if the implementation function omits any of the types of providers listed here from its return value. However, the implementation function may return additional providers not listed here. Each element of the list is an `*Info` object returned by [`provider()`](../globals/bzl#provider), except that a legacy provider is represented by its string name instead.When a target of the rule is used as a dependency for a target that declares a required provider, it is not necessary to specify that provider here. It is enough that the implementation function returns it. However, it is considered best practice to specify it, even though this is not required. The [`required_providers`](../globals/bzl#aspect.required_providers) field of an [aspect](../globals/bzl#aspect) does, however, require that providers are specified here. |
-| `dependency_resolution_rule` | [bool](../core/bool); default is `False`  If set, the rule can be a dependency through attributes also marked as available in materializers. Every attribute of rules with this flag set must be marked as available in materializers also. This is so that rules so marked cannot depend on rules that are not so marked. |
-| `exec_compatible_with` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  A list of constraints on the execution platform that apply to all targets of this rule type. |
-| `analysis_test` | [bool](../core/bool); default is `False`  If true, then this rule is treated as an analysis test. Note: Analysis test rules are primarily defined using infrastructure provided in core Starlark libraries. See [Testing](https://bazel.build/versions/8.5.1/rules/testing#testing-rules) for guidance. If a rule is defined as an analysis test rule, it becomes allowed to use configuration transitions defined using [analysis\_test\_transition](#analysis_test_transition) on its attributes, but opts into some restrictions:  * Targets of this rule are limited in the number of transitive dependencies they may have.* The rule is considered a test rule (as if `test=True` were set). This supersedes the value of `test`   * The rule implementation function may not register actions. Instead, it must register a pass/fail result via providing [AnalysisTestResultInfo](../providers/AnalysisTestResultInfo). |
-| `build_setting` | [BuildSetting](../builtins/BuildSetting); or `None`; default is `None`  If set, describes what kind of [`build setting`](/versions/8.5.1/rules/config#user-defined-build-settings) this rule is. See the [`config`](../toplevel/config) module. If this is set, a mandatory attribute named "build\_setting\_default" is automatically added to this rule, with a type corresponding to the value passed in here. |
+| `implementation` | [function](/versions/8.5.1/rules/lib/core/function); required  the Starlark function implementing this rule, must have exactly one parameter: [ctx](/versions/8.5.1/rules/lib/builtins/ctx). The function is called during the analysis phase for each instance of the rule. It can access the attributes provided by the user. It must create actions to generate all the declared outputs. |
+| `test` | [bool](/versions/8.5.1/rules/lib/core/bool); default is `unbound`  Whether this rule is a test rule, that is, whether it may be the subject of a `blaze test` command. All test rules are automatically considered [executable](#rule.executable); it is unnecessary (and discouraged) to explicitly set `executable = True` for a test rule. The value defaults to `False`. See the  [Rules page](https://bazel.build/versions/8.5.1/extending/rules#executable_rules_and_test_rules) for more information. |
+| `attrs` | [dict](/versions/8.5.1/rules/lib/core/dict); default is `{}`  A dictionary to declare all the attributes of the rule. It maps from an attribute name to an attribute object (see [`attr`](/versions/8.5.1/rules/lib/toplevel/attr) module). Attributes starting with `_` are private, and can be used to add an implicit dependency on a label. The attribute `name` is implicitly added and must not be specified. Attributes `visibility`, `deprecation`, `tags`, `testonly`, and `features` are implicitly added and cannot be overridden. Most rules need only a handful of attributes. To limit memory usage, there is a cap on the number of attributes that may be declared. Declared attributes will convert `None` to the default value. |
+| `outputs` | [dict](/versions/8.5.1/rules/lib/core/dict); or `None`; or [function](/versions/8.5.1/rules/lib/core/function); default is `None`  **Deprecated**. This parameter is deprecated and will be removed soon. Please do not depend on it. It is *disabled* with `--incompatible_no_rule_outputs_param`. Use this flag to verify your code is compatible with its imminent removal.  This parameter has been deprecated. Migrate rules to use `OutputGroupInfo` or `attr.output` instead. A schema for defining predeclared outputs. Unlike [`output`](/versions/8.5.1/rules/lib/toplevel/attr#output) and [`output_list`](/versions/8.5.1/rules/lib/toplevel/attr#output_list) attributes, the user does not specify the labels for these files. See the [Rules page](https://bazel.build/versions/8.5.1/extending/rules#files) for more on predeclared outputs. The value of this argument is either a dictionary or a callback function that produces a dictionary. The callback works similar to computed dependency attributes: The function's parameter names are matched against the rule's attributes, so for example if you pass `outputs = _my_func` with the definition `def _my_func(srcs, deps): ...`, the function has access to the attributes `srcs` and `deps`. Whether the dictionary is specified directly or via a function, it is interpreted as follows. Each entry in the dictionary creates a predeclared output where the key is an identifier and the value is a string template that determines the output's label. In the rule's implementation function, the identifier becomes the field name used to access the output's [`File`](/versions/8.5.1/rules/lib/builtins/File) in [`ctx.outputs`](/versions/8.5.1/rules/lib/builtins/ctx#outputs). The output's label has the same package as the rule, and the part after the package is produced by substituting each placeholder of the form `"%{ATTR}"` with a string formed from the value of the attribute `ATTR`:  * String-typed attributes are substituted verbatim.* Label-typed attributes become the part of the label after the package, minus the file extension. For example, the label `"//pkg:a/b.c"` becomes `"a/b"`.* Output-typed attributes become the part of the label after the package, including the file extension (for the above example, `"a/b.c"`).* All list-typed attributes (for example, `attr.label_list`) used in placeholders are required to have *exactly one element*. Their conversion is the same as their non-list version (`attr.label`).* Other attribute types may not appear in placeholders.* The special non-attribute placeholders `%{dirname}` and `%{basename}` expand to those parts of the rule's label, excluding its package. For example, in `"//pkg:a/b.c"`, the dirname is `a` and the basename is `b.c`.   In practice, the most common substitution placeholder is `"%{name}"`. For example, for a target named "foo", the outputs dict `{"bin": "%{name}.exe"}` predeclares an output named `foo.exe` that is accessible in the implementation function as `ctx.outputs.bin`. |
+| `executable` | [bool](/versions/8.5.1/rules/lib/core/bool); default is `unbound` |
+| `output_to_genfiles` | [bool](/versions/8.5.1/rules/lib/core/bool); default is `False`  If true, the files will be generated in the genfiles directory instead of the bin directory. Unless you need it for compatibility with existing rules (e.g. when generating header files for C++), do not set this flag. |
+| `fragments` | [sequence](/versions/8.5.1/rules/lib/core/list) of [string](/versions/8.5.1/rules/lib/core/string)s; default is `[]`  List of names of configuration fragments that the rule requires in target configuration. |
+| `host_fragments` | [sequence](/versions/8.5.1/rules/lib/core/list) of [string](/versions/8.5.1/rules/lib/core/string)s; default is `[]`  List of names of configuration fragments that the rule requires in host configuration. |
+| `_skylark_testable` | [bool](/versions/8.5.1/rules/lib/core/bool); default is `False`  *(Experimental)*  If true, this rule will expose its actions for inspection by rules that depend on it via an `Actions` provider. The provider is also available to the rule itself by calling [ctx.created\_actions()](/versions/8.5.1/rules/lib/builtins/ctx#created_actions).  This should only be used for testing the analysis-time behavior of Starlark rules. This flag may be removed in the future. |
+| `toolchains` | [sequence](/versions/8.5.1/rules/lib/core/list); default is `[]`  If set, the set of toolchains this rule requires. The list can contain String, Label, or StarlarkToolchainTypeApi objects, in any combination. Toolchains will be found by checking the current platform, and provided to the rule implementation via `ctx.toolchain`. |
+| `incompatible_use_toolchain_transition` | [bool](/versions/8.5.1/rules/lib/core/bool); default is `False`  Deprecated, this is no longer in use and should be removed. |
+| `doc` | [string](/versions/8.5.1/rules/lib/core/string); or `None`; default is `None`  A description of the rule that can be extracted by documentation generating tools. |
+| `provides` | [sequence](/versions/8.5.1/rules/lib/core/list); default is `[]`  A list of providers that the implementation function must return. It is an error if the implementation function omits any of the types of providers listed here from its return value. However, the implementation function may return additional providers not listed here. Each element of the list is an `*Info` object returned by [`provider()`](/versions/8.5.1/rules/lib/globals/bzl#provider), except that a legacy provider is represented by its string name instead.When a target of the rule is used as a dependency for a target that declares a required provider, it is not necessary to specify that provider here. It is enough that the implementation function returns it. However, it is considered best practice to specify it, even though this is not required. The [`required_providers`](/versions/8.5.1/rules/lib/globals/bzl#aspect.required_providers) field of an [aspect](/versions/8.5.1/rules/lib/globals/bzl#aspect) does, however, require that providers are specified here. |
+| `dependency_resolution_rule` | [bool](/versions/8.5.1/rules/lib/core/bool); default is `False`  If set, the rule can be a dependency through attributes also marked as available in materializers. Every attribute of rules with this flag set must be marked as available in materializers also. This is so that rules so marked cannot depend on rules that are not so marked. |
+| `exec_compatible_with` | [sequence](/versions/8.5.1/rules/lib/core/list) of [string](/versions/8.5.1/rules/lib/core/string)s; default is `[]`  A list of constraints on the execution platform that apply to all targets of this rule type. |
+| `analysis_test` | [bool](/versions/8.5.1/rules/lib/core/bool); default is `False`  If true, then this rule is treated as an analysis test. Note: Analysis test rules are primarily defined using infrastructure provided in core Starlark libraries. See [Testing](https://bazel.build/versions/8.5.1/rules/testing#testing-rules) for guidance. If a rule is defined as an analysis test rule, it becomes allowed to use configuration transitions defined using [analysis\_test\_transition](#analysis_test_transition) on its attributes, but opts into some restrictions:  * Targets of this rule are limited in the number of transitive dependencies they may have.* The rule is considered a test rule (as if `test=True` were set). This supersedes the value of `test`   * The rule implementation function may not register actions. Instead, it must register a pass/fail result via providing [AnalysisTestResultInfo](/versions/8.5.1/rules/lib/providers/AnalysisTestResultInfo). |
+| `build_setting` | [BuildSetting](/versions/8.5.1/rules/lib/builtins/BuildSetting); or `None`; default is `None`  If set, describes what kind of [`build setting`](/versions/8.5.1/rules/config#user-defined-build-settings) this rule is. See the [`config`](/versions/8.5.1/rules/lib/toplevel/config) module. If this is set, a mandatory attribute named "build\_setting\_default" is automatically added to this rule, with a type corresponding to the value passed in here. |
 | `cfg` | default is `None`  If set, points to the configuration transition the rule will apply to its own configuration before analysis. |
-| `exec_groups` | [dict](../core/dict); or `None`; default is `None`  Dict of execution group name (string) to [`exec_group`s](../globals/bzl#exec_group). If set, allows rules to run actions on multiple execution platforms within a single target. See [execution groups documentation](/versions/8.5.1/reference/exec-groups) for more info. |
+| `exec_groups` | [dict](/versions/8.5.1/rules/lib/core/dict); or `None`; default is `None`  Dict of execution group name (string) to [`exec_group`s](/versions/8.5.1/rules/lib/globals/bzl#exec_group). If set, allows rules to run actions on multiple execution platforms within a single target. See [execution groups documentation](/versions/8.5.1/reference/exec-groups) for more info. |
 | `initializer` | default is `None`  Experimental: the Stalark function initializing the attributes of the rule. The function is called at load time for each instance of the rule. It's called with `name` and the values of public attributes defined by the rule (not with generic attributes, for example `tags`). It has to return a dictionary from the attribute names to the desired values. The attributes that are not returned are unaffected. Returning `None` as value results in using the default value specified in the attribute definition. Initializers are evaluated before the default values specified in an attribute definition. Consequently, if a parameter in the initializer's signature contains a default values, it overwrites the default from the attribute definition (except if returning `None`). Similarly, if a parameter in the initializer's signature doesn't have a default, the parameter will become mandatory. It's a good practice to omit default/mandatory settings on an attribute definition in such cases. It's a good practice to use `**kwargs` for attributes that are not handled. In case of extended rules, all initializers are called proceeding from child to ancestors. Each initializer is passed only the public attributes it knows about. |
 | `parent` | default is `None`  Experimental: the Stalark rule that is extended. When set the public attributes are merged as well as advertised providers. The rule matches `executable` and `test` from the parent. Values of `fragments`, `toolchains`, `exec_compatible_with`, and `exec_groups` are merged. Legacy or deprecated parameters may not be set. Incoming configuration transition `cfg` of parent is applied after thisrule's incoming configuration. |
-| `extendable` | [bool](../core/bool); or [Label](../builtins/Label); or [string](../core/string); or `None`; default is `None`  Experimental: A label of an allowlist defining which rules can extending this rule. It can be set also to True/False to always allow/disallow extending. Bazel defaults to always allowing extensions. |
-| `subrules` | [sequence](../core/list) of [Subrule](../builtins/Subrule)s; default is `[]`  Experimental: List of subrules used by this rule. |
+| `extendable` | [bool](/versions/8.5.1/rules/lib/core/bool); or [Label](/versions/8.5.1/rules/lib/builtins/Label); or [string](/versions/8.5.1/rules/lib/core/string); or `None`; default is `None`  Experimental: A label of an allowlist defining which rules can extending this rule. It can be set also to True/False to always allow/disallow extending. Bazel defaults to always allowing extensions. |
+| `subrules` | [sequence](/versions/8.5.1/rules/lib/core/list) of [Subrule](/versions/8.5.1/rules/lib/builtins/Subrule)s; default is `[]`  Experimental: List of subrules used by this rule. |
 
 ## select
 
@@ -303,8 +303,8 @@ unknown select(x, no_match_error='')
 
 | Parameter | Description |
 | --- | --- |
-| `x` | [dict](../core/dict); required  A dict that maps configuration conditions to values. Each key is a [Label](../builtins/Label) or a label string that identifies a config\_setting or constraint\_value instance. See the [documentation on macros](https://bazel.build/versions/8.5.1/extending/legacy-macros#label-resolution) for when to use a Label instead of a string. If `--incompatible_resolve_select_keys_eagerly` is enabled, the keys are resolved to `Label` objects relative to the package of the file that contains this call to `select`. |
-| `no_match_error` | [string](../core/string); default is `''`  Optional custom error to report if no condition matches. |
+| `x` | [dict](/versions/8.5.1/rules/lib/core/dict); required  A dict that maps configuration conditions to values. Each key is a [Label](/versions/8.5.1/rules/lib/builtins/Label) or a label string that identifies a config\_setting or constraint\_value instance. See the [documentation on macros](https://bazel.build/versions/8.5.1/extending/legacy-macros#label-resolution) for when to use a Label instead of a string. If `--incompatible_resolve_select_keys_eagerly` is enabled, the keys are resolved to `Label` objects relative to the package of the file that contains this call to `select`. |
+| `no_match_error` | [string](/versions/8.5.1/rules/lib/core/string); default is `''`  Optional custom error to report if no condition matches. |
 
 ## subrule
 
@@ -318,11 +318,11 @@ Constructs a new instance of a subrule. The result of this function must be stor
 
 | Parameter | Description |
 | --- | --- |
-| `implementation` | [function](../core/function); required  The Starlark function implementing this subrule |
-| `attrs` | [dict](../core/dict); default is `{}`  A dictionary to declare all the (private) attributes of the subrule.  Subrules may only have private attributes that are label-typed (i.e. label or label-list). The resolved values corresponding to these labels are automatically passed by Bazel to the subrule's implementation function as named arguments (thus the implementation function is required to accept named parameters matching the attribute names). The types of these values will be:  * `FilesToRunProvider` for label attributes with `executable=True` * `File` for label attributes with `allow_single_file=True` * `Target` for all other label attributes * `[Target]` for all label-list attributes |
-| `toolchains` | [sequence](../core/list); default is `[]`  If set, the set of toolchains this subrule requires. The list can contain String, Label, or StarlarkToolchainTypeApi objects, in any combination. Toolchains will be found by checking the current platform, and provided to the subrule implementation via `ctx.toolchains`. Note that AEGs need to be enabled on the consuming rule(s) if this parameter is set. In case you haven't migrated to AEGs yet, see https://bazel.build/extending/auto-exec-groups#migration-aegs. |
-| `fragments` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  List of names of configuration fragments that the subrule requires in target configuration. |
-| `subrules` | [sequence](../core/list) of [Subrule](../builtins/Subrule)s; default is `[]`  List of other subrules needed by this subrule. |
+| `implementation` | [function](/versions/8.5.1/rules/lib/core/function); required  The Starlark function implementing this subrule |
+| `attrs` | [dict](/versions/8.5.1/rules/lib/core/dict); default is `{}`  A dictionary to declare all the (private) attributes of the subrule.  Subrules may only have private attributes that are label-typed (i.e. label or label-list). The resolved values corresponding to these labels are automatically passed by Bazel to the subrule's implementation function as named arguments (thus the implementation function is required to accept named parameters matching the attribute names). The types of these values will be:  * `FilesToRunProvider` for label attributes with `executable=True` * `File` for label attributes with `allow_single_file=True` * `Target` for all other label attributes * `[Target]` for all label-list attributes |
+| `toolchains` | [sequence](/versions/8.5.1/rules/lib/core/list); default is `[]`  If set, the set of toolchains this subrule requires. The list can contain String, Label, or StarlarkToolchainTypeApi objects, in any combination. Toolchains will be found by checking the current platform, and provided to the subrule implementation via `ctx.toolchains`. Note that AEGs need to be enabled on the consuming rule(s) if this parameter is set. In case you haven't migrated to AEGs yet, see https://bazel.build/extending/auto-exec-groups#migration-aegs. |
+| `fragments` | [sequence](/versions/8.5.1/rules/lib/core/list) of [string](/versions/8.5.1/rules/lib/core/string)s; default is `[]`  List of names of configuration fragments that the subrule requires in target configuration. |
+| `subrules` | [sequence](/versions/8.5.1/rules/lib/core/list) of [Subrule](/versions/8.5.1/rules/lib/builtins/Subrule)s; default is `[]`  List of other subrules needed by this subrule. |
 
 ## tag\_class
 
@@ -336,8 +336,8 @@ Creates a new tag\_class object, which defines an attribute schema for a class o
 
 | Parameter | Description |
 | --- | --- |
-| `attrs` | [dict](../core/dict); default is `{}`  A dictionary to declare all the attributes of this tag class. It maps from an attribute name to an attribute object (see [attr](../toplevel/attr) module). Note that unlike [`rule()`](../globals/bzl#rule), [`aspect()`](../globals/bzl#aspect) and [`repository_rule()`](../globals/bzl#repository_rule), declared attributes will not convert `None` to the default value. For the default to be used, the attribute must be omitted entirely by the caller. |
-| `doc` | [string](../core/string); or `None`; default is `None`  A description of the tag class that can be extracted by documentation generating tools. |
+| `attrs` | [dict](/versions/8.5.1/rules/lib/core/dict); default is `{}`  A dictionary to declare all the attributes of this tag class. It maps from an attribute name to an attribute object (see [attr](/versions/8.5.1/rules/lib/toplevel/attr) module). Note that unlike [`rule()`](/versions/8.5.1/rules/lib/globals/bzl#rule), [`aspect()`](/versions/8.5.1/rules/lib/globals/bzl#aspect) and [`repository_rule()`](/versions/8.5.1/rules/lib/globals/bzl#repository_rule), declared attributes will not convert `None` to the default value. For the default to be used, the attribute must be omitted entirely by the caller. |
+| `doc` | [string](/versions/8.5.1/rules/lib/core/string); or `None`; default is `None`  A description of the tag class that can be extracted by documentation generating tools. |
 
 ## visibility
 
diff --git a/versions/8.5.1/rules/lib/globals/module.mdx b/versions/8.5.1/rules/lib/globals/module.mdx
index 97649c20..73a84a09 100644
--- a/versions/8.5.1/rules/lib/globals/module.mdx
+++ b/versions/8.5.1/rules/lib/globals/module.mdx
@@ -31,7 +31,7 @@ None archive_override(module_name, **kwargs)
 
 Specifies that this dependency should come from an archive file (zip, gzip, etc) at a
 certain location, instead of from a registry. Effectively, this dependency will be
-backed by an [`http_archive`](../repo/http#http_archive) rule.
+backed by an [`http_archive`](/versions/8.5.1/rules/lib/repo/http#http_archive) rule.
 
 This directive only takes effect in the root module; in other words, if a module is
 used as a dependency by others, its own overrides are ignored.
@@ -40,7 +40,7 @@ used as a dependency by others, its own overrides are ignored.
 
 | Parameter | Description |
 | --- | --- |
-| `module_name` | [string](../core/string); required  The name of the Bazel module dependency to apply this override to. |
+| `module_name` | [string](/versions/8.5.1/rules/lib/core/string); required  The name of the Bazel module dependency to apply this override to. |
 | `kwargs` | required  All other arguments are forwarded to the underlying `http_archive` repo rule. Note that the `name` attribute shouldn't be specified; use `module_name` instead. |
 
 ## bazel\_dep
@@ -55,11 +55,11 @@ Declares a direct dependency on another Bazel module.
 
 | Parameter | Description |
 | --- | --- |
-| `name` | [string](../core/string); required  The name of the module to be added as a direct dependency. |
-| `version` | [string](../core/string); default is `''`  The version of the module to be added as a direct dependency. |
-| `max_compatibility_level` | [int](../core/int); default is `-1`  The maximum `compatibility_level` supported for the module to be added as a direct dependency. The version of the module implies the minimum compatibility\_level supported, as well as the maximum if this attribute is not specified. |
-| `repo_name` | [string](../core/string); or `None`; default is `''`  The name of the external repo representing this dependency. This is by default the name of the module. Can be set to `None` to make this dependency a "*nodep*" dependency: in this case, this `bazel_dep` specification is only honored if the target module already exists in the dependency graph by some other means. |
-| `dev_dependency` | [bool](../core/bool); default is `False`  If true, this dependency will be ignored if the current module is not the root module or `--ignore_dev_dependency` is enabled. |
+| `name` | [string](/versions/8.5.1/rules/lib/core/string); required  The name of the module to be added as a direct dependency. |
+| `version` | [string](/versions/8.5.1/rules/lib/core/string); default is `''`  The version of the module to be added as a direct dependency. |
+| `max_compatibility_level` | [int](/versions/8.5.1/rules/lib/core/int); default is `-1`  The maximum `compatibility_level` supported for the module to be added as a direct dependency. The version of the module implies the minimum compatibility\_level supported, as well as the maximum if this attribute is not specified. |
+| `repo_name` | [string](/versions/8.5.1/rules/lib/core/string); or `None`; default is `''`  The name of the external repo representing this dependency. This is by default the name of the module. Can be set to `None` to make this dependency a "*nodep*" dependency: in this case, this `bazel_dep` specification is only honored if the target module already exists in the dependency graph by some other means. |
+| `dev_dependency` | [bool](/versions/8.5.1/rules/lib/core/bool); default is `False`  If true, this dependency will be ignored if the current module is not the root module or `--ignore_dev_dependency` is enabled. |
 
 ## flag\_alias
 
@@ -73,8 +73,8 @@ No-op for pre-Bazel 9.0 backward compatibility. See Bazel 9.0 docs for real func
 
 | Parameter | Description |
 | --- | --- |
-| `name` | [string](../core/string); required  The name of the flag. |
-| `starlark_flag` | [string](../core/string); required  The label of the Starlark flag to alias to. |
+| `name` | [string](/versions/8.5.1/rules/lib/core/string); required  The name of the flag. |
+| `starlark_flag` | [string](/versions/8.5.1/rules/lib/core/string); required  The label of the Starlark flag to alias to. |
 
 ## git\_override
 
@@ -84,7 +84,7 @@ None git_override(module_name, **kwargs)
 
 Specifies that this dependency should come from a certain commit in a Git repository,
 instead of from a registry. Effectively, this dependency will be backed by a
-[`git_repository`](../repo/git#git_repository) rule.
+[`git_repository`](/versions/8.5.1/rules/lib/repo/git#git_repository) rule.
 
 This directive only takes effect in the root module; in other words, if a module is
 used as a dependency by others, its own overrides are ignored.
@@ -93,7 +93,7 @@ used as a dependency by others, its own overrides are ignored.
 
 | Parameter | Description |
 | --- | --- |
-| `module_name` | [string](../core/string); required  The name of the Bazel module dependency to apply this override to. |
+| `module_name` | [string](/versions/8.5.1/rules/lib/core/string); required  The name of the Bazel module dependency to apply this override to. |
 | `kwargs` | required  All other arguments are forwarded to the underlying `git_repository` repo rule. Note that the `name` attribute shouldn't be specified; use `module_name` instead. |
 
 ## include
@@ -114,7 +114,7 @@ Only files in the current module's repo may be included.
 
 | Parameter | Description |
 | --- | --- |
-| `label` | [string](../core/string); required  The label pointing to the file to include. The label must point to a file in the main repo; in other words, it **must **start with double slashes (`//`). The name of the file must end with `.MODULE.bazel` and must not start with `.`.**** |
+| `label` | [string](/versions/8.5.1/rules/lib/core/string); required  The label pointing to the file to include. The label must point to a file in the main repo; in other words, it **must **start with double slashes (`//`). The name of the file must end with `.MODULE.bazel` and must not start with `.`.**** |
 
 ## inject\_repo
 
@@ -154,8 +154,8 @@ used as a dependency by others, its own overrides are ignored.
 
 | Parameter | Description |
 | --- | --- |
-| `module_name` | [string](../core/string); required  The name of the Bazel module dependency to apply this override to. |
-| `path` | [string](../core/string); required  The path to the directory where this module is. |
+| `module_name` | [string](/versions/8.5.1/rules/lib/core/string); required  The name of the Bazel module dependency to apply this override to. |
+| `path` | [string](/versions/8.5.1/rules/lib/core/string); required  The path to the directory where this module is. |
 
 ## module
 
@@ -171,11 +171,11 @@ It should be called at most once, and if called, it must be the very first direc
 
 | Parameter | Description |
 | --- | --- |
-| `name` | [string](../core/string); default is `''`  The name of the module. Can be omitted only if this module is the root module (as in, if it's not going to be depended on by another module). A valid module name must: 1) only contain lowercase letters (a-z), digits (0-9), dots (.), hyphens (-), and underscores (\_); 2) begin with a lowercase letter; 3) end with a lowercase letter or digit. |
-| `version` | [string](../core/string); default is `''`  The version of the module. Can be omitted only if this module is the root module (as in, if it's not going to be depended on by another module). The version must be in a relaxed SemVer format; see [the documentation](/versions/8.5.1/external/module#version_format) for more details. |
-| `compatibility_level` | [int](../core/int); default is `0`  The compatibility level of the module; this should be changed every time a major incompatible change is introduced. This is essentially the "major version" of the module in terms of SemVer, except that it's not embedded in the version string itself, but exists as a separate field. Modules with different compatibility levels participate in version resolution as if they're modules with different names, but the final dependency graph cannot contain multiple modules with the same name but different compatibility levels (unless `multiple_version_override` is in effect). See [the documentation](/versions/8.5.1/external/module#compatibility_level) for more details. |
-| `repo_name` | [string](../core/string); default is `''`  The name of the repository representing this module, as seen by the module itself. By default, the name of the repo is the name of the module. This can be specified to ease migration for projects that have been using a repo name for itself that differs from its module name. |
-| `bazel_compatibility` | Iterable of [string](../core/string)s; default is `[]`  A list of bazel versions that allows users to declare which Bazel versions are compatible with this module. It does NOT affect dependency resolution, but bzlmod will use this information to check if your current Bazel version is compatible. The format of this value is a string of some constraint values separated by comma. Three constraints are supported: \<=X.X.X: The Bazel version must be equal or older than X.X.X. Used when there is a known incompatible change in a newer version. >=X.X.X: The Bazel version must be equal or newer than X.X.X.Used when you depend on some features that are only available since X.X.X. -X.X.X: The Bazel version X.X.X is not compatible. Used when there is a bug in X.X.X that breaks you, but fixed in later versions. |
+| `name` | [string](/versions/8.5.1/rules/lib/core/string); default is `''`  The name of the module. Can be omitted only if this module is the root module (as in, if it's not going to be depended on by another module). A valid module name must: 1) only contain lowercase letters (a-z), digits (0-9), dots (.), hyphens (-), and underscores (\_); 2) begin with a lowercase letter; 3) end with a lowercase letter or digit. |
+| `version` | [string](/versions/8.5.1/rules/lib/core/string); default is `''`  The version of the module. Can be omitted only if this module is the root module (as in, if it's not going to be depended on by another module). The version must be in a relaxed SemVer format; see [the documentation](/versions/8.5.1/external/module#version_format) for more details. |
+| `compatibility_level` | [int](/versions/8.5.1/rules/lib/core/int); default is `0`  The compatibility level of the module; this should be changed every time a major incompatible change is introduced. This is essentially the "major version" of the module in terms of SemVer, except that it's not embedded in the version string itself, but exists as a separate field. Modules with different compatibility levels participate in version resolution as if they're modules with different names, but the final dependency graph cannot contain multiple modules with the same name but different compatibility levels (unless `multiple_version_override` is in effect). See [the documentation](/versions/8.5.1/external/module#compatibility_level) for more details. |
+| `repo_name` | [string](/versions/8.5.1/rules/lib/core/string); default is `''`  The name of the repository representing this module, as seen by the module itself. By default, the name of the repo is the name of the module. This can be specified to ease migration for projects that have been using a repo name for itself that differs from its module name. |
+| `bazel_compatibility` | Iterable of [string](/versions/8.5.1/rules/lib/core/string)s; default is `[]`  A list of bazel versions that allows users to declare which Bazel versions are compatible with this module. It does NOT affect dependency resolution, but bzlmod will use this information to check if your current Bazel version is compatible. The format of this value is a string of some constraint values separated by comma. Three constraints are supported: \<=X.X.X: The Bazel version must be equal or older than X.X.X. Used when there is a known incompatible change in a newer version. >=X.X.X: The Bazel version must be equal or newer than X.X.X.Used when you depend on some features that are only available since X.X.X. -X.X.X: The Bazel version X.X.X is not compatible. Used when there is a bug in X.X.X that breaks you, but fixed in later versions. |
 
 ## multiple\_version\_override
 
@@ -189,9 +189,9 @@ Specifies that a dependency should still come from a registry, but multiple vers
 
 | Parameter | Description |
 | --- | --- |
-| `module_name` | [string](../core/string); required  The name of the Bazel module dependency to apply this override to. |
-| `versions` | Iterable of [string](../core/string)s; required  Explicitly specifies the versions allowed to coexist. These versions must already be present in the dependency graph pre-selection. Dependencies on this module will be "upgraded" to the nearest higher allowed version at the same compatibility level, whereas dependencies that have a higher version than any allowed versions at the same compatibility level will cause an error. |
-| `registry` | [string](../core/string); default is `''`  Overrides the registry for this module; instead of finding this module from the default list of registries, the given registry should be used. |
+| `module_name` | [string](/versions/8.5.1/rules/lib/core/string); required  The name of the Bazel module dependency to apply this override to. |
+| `versions` | Iterable of [string](/versions/8.5.1/rules/lib/core/string)s; required  Explicitly specifies the versions allowed to coexist. These versions must already be present in the dependency graph pre-selection. Dependencies on this module will be "upgraded" to the nearest higher allowed version at the same compatibility level, whereas dependencies that have a higher version than any allowed versions at the same compatibility level will cause an error. |
+| `registry` | [string](/versions/8.5.1/rules/lib/core/string); default is `''`  Overrides the registry for this module; instead of finding this module from the default list of registries, the given registry should be used. |
 
 ## override\_repo
 
@@ -225,8 +225,8 @@ Specifies already-defined execution platforms to be registered when this module
 
 | Parameter | Description |
 | --- | --- |
-| `dev_dependency` | [bool](../core/bool); default is `False`  If true, the execution platforms will not be registered if the current module is not the root module or `--ignore\_dev\_dependency` is enabled. |
-| `platform_labels` | [sequence](../core/list) of [string](../core/string)s; required  The target patterns to register. |
+| `dev_dependency` | [bool](/versions/8.5.1/rules/lib/core/bool); default is `False`  If true, the execution platforms will not be registered if the current module is not the root module or `--ignore\_dev\_dependency` is enabled. |
+| `platform_labels` | [sequence](/versions/8.5.1/rules/lib/core/list) of [string](/versions/8.5.1/rules/lib/core/string)s; required  The target patterns to register. |
 
 ## register\_toolchains
 
@@ -240,8 +240,8 @@ Specifies already-defined toolchains to be registered when this module is select
 
 | Parameter | Description |
 | --- | --- |
-| `dev_dependency` | [bool](../core/bool); default is `False`  If true, the toolchains will not be registered if the current module is not the root module or `--ignore\_dev\_dependency` is enabled. |
-| `toolchain_labels` | [sequence](../core/list) of [string](../core/string)s; required  The target patterns to register. |
+| `dev_dependency` | [bool](/versions/8.5.1/rules/lib/core/bool); default is `False`  If true, the toolchains will not be registered if the current module is not the root module or `--ignore\_dev\_dependency` is enabled. |
+| `toolchain_labels` | [sequence](/versions/8.5.1/rules/lib/core/list) of [string](/versions/8.5.1/rules/lib/core/string)s; required  The target patterns to register. |
 
 ## single\_version\_override
 
@@ -255,12 +255,12 @@ Specifies that a dependency should still come from a registry, but its version s
 
 | Parameter | Description |
 | --- | --- |
-| `module_name` | [string](../core/string); required  The name of the Bazel module dependency to apply this override to. |
-| `version` | [string](../core/string); default is `''`  Overrides the declared version of this module in the dependency graph. In other words, this module will be "pinned" to this override version. This attribute can be omitted if all one wants to override is the registry or the patches. |
-| `registry` | [string](../core/string); default is `''`  Overrides the registry for this module; instead of finding this module from the default list of registries, the given registry should be used. |
-| `patches` | Iterable of [string](../core/string)s; default is `[]`  A list of labels pointing to patch files to apply for this module. The patch files must exist in the source tree of the top level project. They are applied in the list order. If a patch makes changes to the MODULE.bazel file, these changes will only be effective if the patch file is provided by the root module. |
-| `patch_cmds` | Iterable of [string](../core/string)s; default is `[]`  Sequence of Bash commands to be applied on Linux/Macos after patches are applied. Changes to the MODULE.bazel file will not be effective. |
-| `patch_strip` | [int](../core/int); default is `0`  Same as the --strip argument of Unix patch. |
+| `module_name` | [string](/versions/8.5.1/rules/lib/core/string); required  The name of the Bazel module dependency to apply this override to. |
+| `version` | [string](/versions/8.5.1/rules/lib/core/string); default is `''`  Overrides the declared version of this module in the dependency graph. In other words, this module will be "pinned" to this override version. This attribute can be omitted if all one wants to override is the registry or the patches. |
+| `registry` | [string](/versions/8.5.1/rules/lib/core/string); default is `''`  Overrides the registry for this module; instead of finding this module from the default list of registries, the given registry should be used. |
+| `patches` | Iterable of [string](/versions/8.5.1/rules/lib/core/string)s; default is `[]`  A list of labels pointing to patch files to apply for this module. The patch files must exist in the source tree of the top level project. They are applied in the list order. If a patch makes changes to the MODULE.bazel file, these changes will only be effective if the patch file is provided by the root module. |
+| `patch_cmds` | Iterable of [string](/versions/8.5.1/rules/lib/core/string)s; default is `[]`  Sequence of Bash commands to be applied on Linux/Macos after patches are applied. Changes to the MODULE.bazel file will not be effective. |
+| `patch_strip` | [int](/versions/8.5.1/rules/lib/core/int); default is `0`  Same as the --strip argument of Unix patch. |
 
 ## use\_extension
 
@@ -274,10 +274,10 @@ Returns a proxy object representing a module extension; its methods can be invok
 
 | Parameter | Description |
 | --- | --- |
-| `extension_bzl_file` | [string](../core/string); required  A label to the Starlark file defining the module extension. |
-| `extension_name` | [string](../core/string); required  The name of the module extension to use. A symbol with this name must be exported by the Starlark file. |
-| `dev_dependency` | [bool](../core/bool); default is `False`  If true, this usage of the module extension will be ignored if the current module is not the root module or `--ignore\_dev\_dependency` is enabled. |
-| `isolate` | [bool](../core/bool); default is `False`  **Experimental**. This parameter is experimental and may change at any time. Please do not depend on it. It may be enabled on an experimental basis by setting `--experimental_isolated_extension_usages`  If true, this usage of the module extension will be isolated from all other usages, both in this and other modules. Tags created for this usage do not affect other usages and the repositories generated by the extension for this usage will be distinct from all other repositories generated by the extension. This parameter is currently experimental and only available with the flag `--experimental_isolated_extension_usages`. |
+| `extension_bzl_file` | [string](/versions/8.5.1/rules/lib/core/string); required  A label to the Starlark file defining the module extension. |
+| `extension_name` | [string](/versions/8.5.1/rules/lib/core/string); required  The name of the module extension to use. A symbol with this name must be exported by the Starlark file. |
+| `dev_dependency` | [bool](/versions/8.5.1/rules/lib/core/bool); default is `False`  If true, this usage of the module extension will be ignored if the current module is not the root module or `--ignore\_dev\_dependency` is enabled. |
+| `isolate` | [bool](/versions/8.5.1/rules/lib/core/bool); default is `False`  **Experimental**. This parameter is experimental and may change at any time. Please do not depend on it. It may be enabled on an experimental basis by setting `--experimental_isolated_extension_usages`  If true, this usage of the module extension will be isolated from all other usages, both in this and other modules. Tags created for this usage do not affect other usages and the repositories generated by the extension for this usage will be distinct from all other repositories generated by the extension. This parameter is currently experimental and only available with the flag `--experimental_isolated_extension_usages`. |
 
 ## use\_repo
 
@@ -307,5 +307,5 @@ Returns a proxy value that can be directly invoked in the MODULE.bazel file as a
 
 | Parameter | Description |
 | --- | --- |
-| `repo_rule_bzl_file` | [string](../core/string); required  A label to the Starlark file defining the repo rule. |
-| `repo_rule_name` | [string](../core/string); required  The name of the repo rule to use. A symbol with this name must be exported by the Starlark file. |
\ No newline at end of file
+| `repo_rule_bzl_file` | [string](/versions/8.5.1/rules/lib/core/string); required  A label to the Starlark file defining the repo rule. |
+| `repo_rule_name` | [string](/versions/8.5.1/rules/lib/core/string); required  The name of the repo rule to use. A symbol with this name must be exported by the Starlark file. |
\ No newline at end of file
diff --git a/versions/8.5.1/rules/lib/globals/repo.mdx b/versions/8.5.1/rules/lib/globals/repo.mdx
index b7ae9a3d..4aa55d9f 100644
--- a/versions/8.5.1/rules/lib/globals/repo.mdx
+++ b/versions/8.5.1/rules/lib/globals/repo.mdx
@@ -23,7 +23,7 @@ This function takes a list of strings and a directory is ignored if any of the g
 
 | Parameter | Description |
 | --- | --- |
-| `dirs` | [sequence](../core/list) of [string](../core/string)s; required |
+| `dirs` | [sequence](/versions/8.5.1/rules/lib/core/list) of [string](/versions/8.5.1/rules/lib/core/string)s; required |
 
 ## repo
 
diff --git a/versions/8.5.1/rules/lib/globals/workspace.mdx b/versions/8.5.1/rules/lib/globals/workspace.mdx
index ca6a0c40..749027e0 100644
--- a/versions/8.5.1/rules/lib/globals/workspace.mdx
+++ b/versions/8.5.1/rules/lib/globals/workspace.mdx
@@ -25,8 +25,8 @@ Gives a target an alias in the `//external` package.
 
 | Parameter | Description |
 | --- | --- |
-| `name` | [string](../core/string); required  The label under '//external' to serve as the alias name |
-| `actual` | [string](../core/string); or `None`; default is `None`  The real label to be aliased |
+| `name` | [string](/versions/8.5.1/rules/lib/core/string); required  The label under '//external' to serve as the alias name |
+| `actual` | [string](/versions/8.5.1/rules/lib/core/string); or `None`; default is `None`  The real label to be aliased |
 
 ## register\_execution\_platforms
 
@@ -40,7 +40,7 @@ Specifies already-defined execution platforms to be registered. Should be absolu
 
 | Parameter | Description |
 | --- | --- |
-| `platform_labels` | [sequence](../core/list) of [string](../core/string)s; required  The target patterns to register. |
+| `platform_labels` | [sequence](/versions/8.5.1/rules/lib/core/list) of [string](/versions/8.5.1/rules/lib/core/string)s; required  The target patterns to register. |
 
 ## register\_toolchains
 
@@ -54,7 +54,7 @@ Specifies already-defined toolchains to be registered. Should be absolute [targe
 
 | Parameter | Description |
 | --- | --- |
-| `toolchain_labels` | [sequence](../core/list) of [string](../core/string)s; required  The target patterns to register. |
+| `toolchain_labels` | [sequence](/versions/8.5.1/rules/lib/core/list) of [string](/versions/8.5.1/rules/lib/core/string)s; required  The target patterns to register. |
 
 ## workspace
 
@@ -74,4 +74,4 @@ This name is used for the directory that the repository's runfiles are stored in
 
 | Parameter | Description |
 | --- | --- |
-| `name` | [string](../core/string); required  the name of the workspace. Names must start with a letter and can only contain letters, numbers, underscores, dashes, and dots. |
\ No newline at end of file
+| `name` | [string](/versions/8.5.1/rules/lib/core/string); required  the name of the workspace. Names must start with a letter and can only contain letters, numbers, underscores, dashes, and dots. |
\ No newline at end of file
diff --git a/versions/8.5.1/rules/lib/providers/AnalysisTestResultInfo.mdx b/versions/8.5.1/rules/lib/providers/AnalysisTestResultInfo.mdx
index 1edabb04..c2b197c7 100644
--- a/versions/8.5.1/rules/lib/providers/AnalysisTestResultInfo.mdx
+++ b/versions/8.5.1/rules/lib/providers/AnalysisTestResultInfo.mdx
@@ -22,8 +22,8 @@ The `AnalysisTestResultInfo` constructor.
 
 | Parameter | Description |
 | --- | --- |
-| `success` | [bool](../core/bool); required  If true, then the analysis-phase test represented by this target should pass. If false, the test should fail. |
-| `message` | [string](../core/string); required  A descriptive message containing information about the test and its success/failure. |
+| `success` | [bool](/versions/8.5.1/rules/lib/core/bool); required  If true, then the analysis-phase test represented by this target should pass. If false, the test should fail. |
+| `message` | [string](/versions/8.5.1/rules/lib/core/string); required  A descriptive message containing information about the test and its success/failure. |
 
 ## message
 
diff --git a/versions/8.5.1/rules/lib/providers/CcInfo.mdx b/versions/8.5.1/rules/lib/providers/CcInfo.mdx
index f3c0d961..b878b830 100644
--- a/versions/8.5.1/rules/lib/providers/CcInfo.mdx
+++ b/versions/8.5.1/rules/lib/providers/CcInfo.mdx
@@ -22,8 +22,8 @@ The `CcInfo` constructor.
 
 | Parameter | Description |
 | --- | --- |
-| `compilation_context` | [CompilationContext](../builtins/CompilationContext); or `None`; default is `None`  The `CompilationContext`. |
-| `linking_context` | [LinkingContext](../builtins/LinkingContext); or `None`; default is `None`  The `LinkingContext`. |
+| `compilation_context` | [CompilationContext](/versions/8.5.1/rules/lib/builtins/CompilationContext); or `None`; default is `None`  The `CompilationContext`. |
+| `linking_context` | [LinkingContext](/versions/8.5.1/rules/lib/builtins/LinkingContext); or `None`; default is `None`  The `LinkingContext`. |
 | `debug_context` | DebugContext; or `None`; default is `None`  The `DebugContext`. |
 
 ## compilation\_context
diff --git a/versions/8.5.1/rules/lib/providers/DebugPackageInfo.mdx b/versions/8.5.1/rules/lib/providers/DebugPackageInfo.mdx
index 296778f2..9694e1df 100644
--- a/versions/8.5.1/rules/lib/providers/DebugPackageInfo.mdx
+++ b/versions/8.5.1/rules/lib/providers/DebugPackageInfo.mdx
@@ -24,10 +24,10 @@ The `DebugPackageInfo` constructor.
 
 | Parameter | Description |
 | --- | --- |
-| `target_label` | [Label](../builtins/Label); required  The label for the \*\_binary target |
-| `stripped_file` | [File](../builtins/File); or `None`; default is `None`  The stripped file (the explicit ".stripped" target) |
-| `unstripped_file` | [File](../builtins/File); required  The unstripped file (the default executable target). |
-| `dwp_file` | [File](../builtins/File); or `None`; default is `None`  The .dwp file (for fission builds) or null if --fission=no. |
+| `target_label` | [Label](/versions/8.5.1/rules/lib/builtins/Label); required  The label for the \*\_binary target |
+| `stripped_file` | [File](/versions/8.5.1/rules/lib/builtins/File); or `None`; default is `None`  The stripped file (the explicit ".stripped" target) |
+| `unstripped_file` | [File](/versions/8.5.1/rules/lib/builtins/File); required  The unstripped file (the default executable target). |
+| `dwp_file` | [File](/versions/8.5.1/rules/lib/builtins/File); or `None`; default is `None`  The .dwp file (for fission builds) or null if --fission=no. |
 
 ## dwp\_file
 
diff --git a/versions/8.5.1/rules/lib/providers/DefaultInfo.mdx b/versions/8.5.1/rules/lib/providers/DefaultInfo.mdx
index 866f771b..7e4a595a 100644
--- a/versions/8.5.1/rules/lib/providers/DefaultInfo.mdx
+++ b/versions/8.5.1/rules/lib/providers/DefaultInfo.mdx
@@ -28,11 +28,11 @@ The `DefaultInfo` constructor.
 
 | Parameter | Description |
 | --- | --- |
-| `files` | [depset](../builtins/depset); or `None`; default is `None`  A [`depset`](../builtins/depset) of [`File`](../builtins/File) objects representing the default outputs to build when this target is specified on the bazel command line. By default it is all predeclared outputs. |
-| `runfiles` | [runfiles](../builtins/runfiles); or `None`; default is `None`  runfiles descriptor describing the files that this target needs when run (via the `run` command or as a tool dependency). |
-| `data_runfiles` | [runfiles](../builtins/runfiles); or `None`; default is `None`  **It is recommended that you avoid using this parameter (see ["runfiles features to avoid"](https://bazel.build/versions/8.5.1/extending/rules#runfiles_features_to_avoid))** runfiles descriptor describing the runfiles this target needs to run when it is a dependency via the `data` attribute. |
-| `default_runfiles` | [runfiles](../builtins/runfiles); or `None`; default is `None`  **It is recommended that you avoid using this parameter (see ["runfiles features to avoid"](https://bazel.build/versions/8.5.1/extending/rules#runfiles_features_to_avoid))** runfiles descriptor describing the runfiles this target needs to run when it is a dependency via any attribute other than the `data` attribute. |
-| `executable` | [File](../builtins/File); or `None`; default is `None`  If this rule is marked [`executable`](../globals/bzl#rule.executable) or [`test`](../globals/bzl#rule.test), this is a [`File`](../builtins/File) object representing the file that should be executed to run the target. By default it is the predeclared output `ctx.outputs.executable` but it is recommended to pass another file (either predeclared or not) explicitly. |
+| `files` | [depset](/versions/8.5.1/rules/lib/builtins/depset); or `None`; default is `None`  A [`depset`](/versions/8.5.1/rules/lib/builtins/depset) of [`File`](/versions/8.5.1/rules/lib/builtins/File) objects representing the default outputs to build when this target is specified on the bazel command line. By default it is all predeclared outputs. |
+| `runfiles` | [runfiles](/versions/8.5.1/rules/lib/builtins/runfiles); or `None`; default is `None`  runfiles descriptor describing the files that this target needs when run (via the `run` command or as a tool dependency). |
+| `data_runfiles` | [runfiles](/versions/8.5.1/rules/lib/builtins/runfiles); or `None`; default is `None`  **It is recommended that you avoid using this parameter (see ["runfiles features to avoid"](https://bazel.build/versions/8.5.1/extending/rules#runfiles_features_to_avoid))** runfiles descriptor describing the runfiles this target needs to run when it is a dependency via the `data` attribute. |
+| `default_runfiles` | [runfiles](/versions/8.5.1/rules/lib/builtins/runfiles); or `None`; default is `None`  **It is recommended that you avoid using this parameter (see ["runfiles features to avoid"](https://bazel.build/versions/8.5.1/extending/rules#runfiles_features_to_avoid))** runfiles descriptor describing the runfiles this target needs to run when it is a dependency via any attribute other than the `data` attribute. |
+| `executable` | [File](/versions/8.5.1/rules/lib/builtins/File); or `None`; default is `None`  If this rule is marked [`executable`](/versions/8.5.1/rules/lib/globals/bzl#rule.executable) or [`test`](/versions/8.5.1/rules/lib/globals/bzl#rule.test), this is a [`File`](/versions/8.5.1/rules/lib/builtins/File) object representing the file that should be executed to run the target. By default it is the predeclared output `ctx.outputs.executable` but it is recommended to pass another file (either predeclared or not) explicitly. |
 
 ## data\_runfiles
 
@@ -58,7 +58,7 @@ May return `None`.
 depset DefaultInfo.files
 ```
 
-A [`depset`](../builtins/depset) of [`File`](../builtins/File) objects representing the default outputs to build when this target is specified on the bazel command line. By default it is all predeclared outputs.
+A [`depset`](/versions/8.5.1/rules/lib/builtins/depset) of [`File`](/versions/8.5.1/rules/lib/builtins/File) objects representing the default outputs to build when this target is specified on the bazel command line. By default it is all predeclared outputs.
 May return `None`.
 
 ## files\_to\_run
@@ -67,5 +67,5 @@ May return `None`.
 FilesToRunProvider DefaultInfo.files_to_run
 ```
 
-A [`FilesToRunProvider`](../providers/FilesToRunProvider) object containing information about the executable and runfiles of the target.
+A [`FilesToRunProvider`](/versions/8.5.1/rules/lib/providers/FilesToRunProvider) object containing information about the executable and runfiles of the target.
 May return `None`.
\ No newline at end of file
diff --git a/versions/8.5.1/rules/lib/providers/ExecutionInfo.mdx b/versions/8.5.1/rules/lib/providers/ExecutionInfo.mdx
index d351095e..586d05db 100644
--- a/versions/8.5.1/rules/lib/providers/ExecutionInfo.mdx
+++ b/versions/8.5.1/rules/lib/providers/ExecutionInfo.mdx
@@ -22,8 +22,8 @@ Creates an instance.
 
 | Parameter | Description |
 | --- | --- |
-| `requirements` | [dict](../core/dict); default is `{}`  A dict indicating special execution requirements, such as hardware platforms. |
-| `exec_group` | [string](../core/string); default is `'test'`  The name of the exec group that is used to execute the test. |
+| `requirements` | [dict](/versions/8.5.1/rules/lib/core/dict); default is `{}`  A dict indicating special execution requirements, such as hardware platforms. |
+| `exec_group` | [string](/versions/8.5.1/rules/lib/core/string); default is `'test'`  The name of the exec group that is used to execute the test. |
 
 ## exec\_group
 
diff --git a/versions/8.5.1/rules/lib/providers/FeatureFlagInfo.mdx b/versions/8.5.1/rules/lib/providers/FeatureFlagInfo.mdx
index ebade07a..6bedbdb9 100644
--- a/versions/8.5.1/rules/lib/providers/FeatureFlagInfo.mdx
+++ b/versions/8.5.1/rules/lib/providers/FeatureFlagInfo.mdx
@@ -31,7 +31,7 @@ The value of the flag in the configuration used by the flag rule.
 
 | Parameter | Description |
 | --- | --- |
-| `value` | [string](../core/string); required  String, the value to check for validity for this flag. |
+| `value` | [string](/versions/8.5.1/rules/lib/core/string); required  String, the value to check for validity for this flag. |
 
 ## value
 
diff --git a/versions/8.5.1/rules/lib/providers/InstrumentedFilesInfo.mdx b/versions/8.5.1/rules/lib/providers/InstrumentedFilesInfo.mdx
index b190a2ca..f91c47cc 100644
--- a/versions/8.5.1/rules/lib/providers/InstrumentedFilesInfo.mdx
+++ b/versions/8.5.1/rules/lib/providers/InstrumentedFilesInfo.mdx
@@ -15,7 +15,7 @@ Contains information about source files and instrumentation metadata files for r
 depset InstrumentedFilesInfo.instrumented_files
 ```
 
-[`depset`](../builtins/depset) of [`File`](../builtins/File) objects representing instrumented source files for this target and its dependencies.
+[`depset`](/versions/8.5.1/rules/lib/builtins/depset) of [`File`](/versions/8.5.1/rules/lib/builtins/File) objects representing instrumented source files for this target and its dependencies.
 
 ## metadata\_files
 
@@ -23,4 +23,4 @@ depset InstrumentedFilesInfo.instrumented_files
 depset InstrumentedFilesInfo.metadata_files
 ```
 
-[`depset`](../builtins/depset) of [`File`](../builtins/File) objects representing coverage metadata files for this target and its dependencies. These files contain additional information required to generate LCOV-format coverage output after the code is executed, e.g. the `.gcno` files generated when `gcc` is run with `-ftest-coverage`.
\ No newline at end of file
+[`depset`](/versions/8.5.1/rules/lib/builtins/depset) of [`File`](/versions/8.5.1/rules/lib/builtins/File) objects representing coverage metadata files for this target and its dependencies. These files contain additional information required to generate LCOV-format coverage output after the code is executed, e.g. the `.gcno` files generated when `gcc` is run with `-ftest-coverage`.
\ No newline at end of file
diff --git a/versions/8.5.1/rules/lib/providers/PackageSpecificationInfo.mdx b/versions/8.5.1/rules/lib/providers/PackageSpecificationInfo.mdx
index 242a43e6..fde042b3 100644
--- a/versions/8.5.1/rules/lib/providers/PackageSpecificationInfo.mdx
+++ b/versions/8.5.1/rules/lib/providers/PackageSpecificationInfo.mdx
@@ -20,4 +20,4 @@ Checks if a target exists in a package group.
 
 | Parameter | Description |
 | --- | --- |
-| `target` | [Label](../builtins/Label); or [string](../core/string); required  A target which is checked if it exists inside the package group. |
\ No newline at end of file
+| `target` | [Label](/versions/8.5.1/rules/lib/builtins/Label); or [string](/versions/8.5.1/rules/lib/core/string); required  A target which is checked if it exists inside the package group. |
\ No newline at end of file
diff --git a/versions/8.5.1/rules/lib/providers/ProguardSpecProvider.mdx b/versions/8.5.1/rules/lib/providers/ProguardSpecProvider.mdx
index b7a337c2..18ce48ae 100644
--- a/versions/8.5.1/rules/lib/providers/ProguardSpecProvider.mdx
+++ b/versions/8.5.1/rules/lib/providers/ProguardSpecProvider.mdx
@@ -20,4 +20,4 @@ The `ProguardSpecProvider` constructor.
 
 | Parameter | Description |
 | --- | --- |
-| `specs` | [depset](../builtins/depset) of [File](../builtins/File)s; required  Transitive proguard specs. |
\ No newline at end of file
+| `specs` | [depset](/versions/8.5.1/rules/lib/builtins/depset) of [File](/versions/8.5.1/rules/lib/builtins/File)s; required  Transitive proguard specs. |
\ No newline at end of file
diff --git a/versions/8.5.1/rules/lib/repo/index.mdx b/versions/8.5.1/rules/lib/repo/index.mdx
index ab27e81c..af251e04 100644
--- a/versions/8.5.1/rules/lib/repo/index.mdx
+++ b/versions/8.5.1/rules/lib/repo/index.mdx
@@ -3,10 +3,10 @@
 title: 'Repository Rules'
 ---
 
-* [Rules related to git](git)
-* [Rules related to http](http)
-* [Rules related to local directories](local)
+* [Rules related to git](/versions/8.5.1/rules/lib/repo/git)
+* [Rules related to http](/versions/8.5.1/rules/lib/repo/http)
+* [Rules related to local directories](/versions/8.5.1/rules/lib/repo/local)
 
 # Generic functions for repository rule authors
 
-* [Utility functions on patching](utils)
+* [Utility functions on patching](/versions/8.5.1/rules/lib/repo/utils)
diff --git a/versions/8.5.1/rules/lib/toplevel/apple_common.mdx b/versions/8.5.1/rules/lib/toplevel/apple_common.mdx
index d26f9c22..e697c554 100644
--- a/versions/8.5.1/rules/lib/toplevel/apple_common.mdx
+++ b/versions/8.5.1/rules/lib/toplevel/apple_common.mdx
@@ -21,7 +21,7 @@ Functions for Starlark to access internals of the apple rule implementations.
 dict apple_common.apple_host_system_env(xcode_config)
 ```
 
-Returns a [dict](../core/dict) of environment variables that should be set for actions that need to run build tools on an Apple host system, such as the version of Xcode that should be used. The keys are variable names and the values are their corresponding values.
+Returns a [dict](/versions/8.5.1/rules/lib/core/dict) of environment variables that should be set for actions that need to run build tools on an Apple host system, such as the version of Xcode that should be used. The keys are variable names and the values are their corresponding values.
 
 ### Parameters
 
@@ -43,13 +43,13 @@ Utilities for resolving items from the apple toolchain.
 DottedVersion apple_common.dotted_version(version)
 ```
 
-Creates a new [DottedVersion](../builtins/DottedVersion) instance.
+Creates a new [DottedVersion](/versions/8.5.1/rules/lib/builtins/DottedVersion) instance.
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `version` | [string](../core/string); required  The string representation of the DottedVersion. |
+| `version` | [string](/versions/8.5.1/rules/lib/core/string); required  The string representation of the DottedVersion. |
 
 ## platform
 
@@ -69,7 +69,7 @@ An enum-like struct that contains the following fields corresponding to Apple pl
 * `watchos_device`
 * `watchos_simulator`
 
-These values can be passed to methods that expect a platform, like [XcodeVersionConfig.sdk\_version\_for\_platform](../providers/XcodeVersionConfig#sdk_version_for_platform).
+These values can be passed to methods that expect a platform, like [XcodeVersionConfig.sdk\_version\_for\_platform](/versions/8.5.1/rules/lib/providers/XcodeVersionConfig#sdk_version_for_platform).
 
 ## platform\_type
 
@@ -85,7 +85,7 @@ An enum-like struct that contains the following fields corresponding to Apple pl
 * `visionos`
 * `watchos`
 
-These values can be passed to methods that expect a platform type, like the 'apple' configuration fragment's [multi\_arch\_platform](../fragments/apple#multi_arch_platform) method.
+These values can be passed to methods that expect a platform type, like the 'apple' configuration fragment's [multi\_arch\_platform](/versions/8.5.1/rules/lib/fragments/apple#multi_arch_platform) method.
 
 Example:
 
diff --git a/versions/8.5.1/rules/lib/toplevel/attr.mdx b/versions/8.5.1/rules/lib/toplevel/attr.mdx
index ba352d9e..946117f7 100644
--- a/versions/8.5.1/rules/lib/toplevel/attr.mdx
+++ b/versions/8.5.1/rules/lib/toplevel/attr.mdx
@@ -2,7 +2,7 @@
 title: 'attr'
 ---
 
-This is a top-level module for defining the attribute schemas of a rule or aspect. Each function returns an object representing the schema of a single attribute. These objects are used as the values of the `attrs` dictionary argument of [`rule()`](../globals/bzl#rule), [`aspect()`](../globals/bzl#aspect), [`repository_rule()`](../globals/bzl#repository_rule) and [`tag_class()`](../globals/bzl#tag_class).
+This is a top-level module for defining the attribute schemas of a rule or aspect. Each function returns an object representing the schema of a single attribute. These objects are used as the values of the `attrs` dictionary argument of [`rule()`](/versions/8.5.1/rules/lib/globals/bzl#rule), [`aspect()`](/versions/8.5.1/rules/lib/globals/bzl#aspect), [`repository_rule()`](/versions/8.5.1/rules/lib/globals/bzl#repository_rule) and [`tag_class()`](/versions/8.5.1/rules/lib/globals/bzl#tag_class).
 
 See the Rules page for more on [defining](https://bazel.build/versions/8.5.1/extending/rules#attributes)
 and [using](https://bazel.build/versions/8.5.1/extending/rules#implementation_function) attributes.
@@ -29,16 +29,16 @@ and [using](https://bazel.build/versions/8.5.1/extending/rules#implementation_fu
 Attribute attr.bool(configurable=unbound, default=False, doc=None, mandatory=False)
 ```
 
-Creates a schema for a boolean attribute. The corresponding [`ctx.attr`](../builtins/ctx#attr) attribute will be of type [`bool`](../core/bool).
+Creates a schema for a boolean attribute. The corresponding [`ctx.attr`](/versions/8.5.1/rules/lib/builtins/ctx#attr) attribute will be of type [`bool`](/versions/8.5.1/rules/lib/core/bool).
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `configurable` | [bool](../core/bool); or unbound; default is `unbound`  This argument can only be specified for an attribute of a symbolic macro. If `configurable` is explicitly set to `False`, the symbolic macro attribute is non-configurable - in other words, it cannot take a `select()` value. If the `configurable` is either unbound or explicitly set to `True`, the attribute is configurable and can take a `select()` value. For an attribute of a rule or aspect, `configurable` must be left unbound. Most Starlark rule attributes are always configurable, with the exception of `attr.output()`, `attr.output_list()`, and `attr.license()` rule attributes, which are always non-configurable. |
-| `default` | [bool](../core/bool); default is `False`  A default value to use if no value for this attribute is given when instantiating the rule. |
-| `doc` | [string](../core/string); or `None`; default is `None`  A description of the attribute that can be extracted by documentation generating tools. |
-| `mandatory` | [bool](../core/bool); default is `False`  If true, the value must be specified explicitly (even if it has a `default`). |
+| `configurable` | [bool](/versions/8.5.1/rules/lib/core/bool); or unbound; default is `unbound`  This argument can only be specified for an attribute of a symbolic macro. If `configurable` is explicitly set to `False`, the symbolic macro attribute is non-configurable - in other words, it cannot take a `select()` value. If the `configurable` is either unbound or explicitly set to `True`, the attribute is configurable and can take a `select()` value. For an attribute of a rule or aspect, `configurable` must be left unbound. Most Starlark rule attributes are always configurable, with the exception of `attr.output()`, `attr.output_list()`, and `attr.license()` rule attributes, which are always non-configurable. |
+| `default` | [bool](/versions/8.5.1/rules/lib/core/bool); default is `False`  A default value to use if no value for this attribute is given when instantiating the rule. |
+| `doc` | [string](/versions/8.5.1/rules/lib/core/string); or `None`; default is `None`  A description of the attribute that can be extracted by documentation generating tools. |
+| `mandatory` | [bool](/versions/8.5.1/rules/lib/core/bool); default is `False`  If true, the value must be specified explicitly (even if it has a `default`). |
 
 ## int
 
@@ -46,17 +46,17 @@ Creates a schema for a boolean attribute. The corresponding [`ctx.attr`](../buil
 Attribute attr.int(configurable=unbound, default=0, doc=None, mandatory=False, values=[])
 ```
 
-Creates a schema for an integer attribute. The value must be in the signed 32-bit range. The corresponding [`ctx.attr`](../builtins/ctx#attr) attribute will be of type [`int`](../core/int).
+Creates a schema for an integer attribute. The value must be in the signed 32-bit range. The corresponding [`ctx.attr`](/versions/8.5.1/rules/lib/builtins/ctx#attr) attribute will be of type [`int`](/versions/8.5.1/rules/lib/core/int).
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `configurable` | [bool](../core/bool); or unbound; default is `unbound`  This argument can only be specified for an attribute of a symbolic macro. If `configurable` is explicitly set to `False`, the symbolic macro attribute is non-configurable - in other words, it cannot take a `select()` value. If the `configurable` is either unbound or explicitly set to `True`, the attribute is configurable and can take a `select()` value. For an attribute of a rule or aspect, `configurable` must be left unbound. Most Starlark rule attributes are always configurable, with the exception of `attr.output()`, `attr.output_list()`, and `attr.license()` rule attributes, which are always non-configurable. |
-| `default` | [int](../core/int); default is `0`  A default value to use if no value for this attribute is given when instantiating the rule. |
-| `doc` | [string](../core/string); or `None`; default is `None`  A description of the attribute that can be extracted by documentation generating tools. |
-| `mandatory` | [bool](../core/bool); default is `False`  If true, the value must be specified explicitly (even if it has a `default`). |
-| `values` | [sequence](../core/list) of [int](../core/int)s; default is `[]`  The list of allowed values for the attribute. An error is raised if any other value is given. |
+| `configurable` | [bool](/versions/8.5.1/rules/lib/core/bool); or unbound; default is `unbound`  This argument can only be specified for an attribute of a symbolic macro. If `configurable` is explicitly set to `False`, the symbolic macro attribute is non-configurable - in other words, it cannot take a `select()` value. If the `configurable` is either unbound or explicitly set to `True`, the attribute is configurable and can take a `select()` value. For an attribute of a rule or aspect, `configurable` must be left unbound. Most Starlark rule attributes are always configurable, with the exception of `attr.output()`, `attr.output_list()`, and `attr.license()` rule attributes, which are always non-configurable. |
+| `default` | [int](/versions/8.5.1/rules/lib/core/int); default is `0`  A default value to use if no value for this attribute is given when instantiating the rule. |
+| `doc` | [string](/versions/8.5.1/rules/lib/core/string); or `None`; default is `None`  A description of the attribute that can be extracted by documentation generating tools. |
+| `mandatory` | [bool](/versions/8.5.1/rules/lib/core/bool); default is `False`  If true, the value must be specified explicitly (even if it has a `default`). |
+| `values` | [sequence](/versions/8.5.1/rules/lib/core/list) of [int](/versions/8.5.1/rules/lib/core/int)s; default is `[]`  The list of allowed values for the attribute. An error is raised if any other value is given. |
 
 ## int\_list
 
@@ -70,11 +70,11 @@ Creates a schema for a list-of-integers attribute. Each element must be in the s
 
 | Parameter | Description |
 | --- | --- |
-| `mandatory` | [bool](../core/bool); default is `False`  If true, the value must be specified explicitly (even if it has a `default`). |
-| `allow_empty` | [bool](../core/bool); default is `True`  True if the attribute can be empty. |
-| `configurable` | [bool](../core/bool); or unbound; default is `unbound`  This argument can only be specified for an attribute of a symbolic macro. If `configurable` is explicitly set to `False`, the symbolic macro attribute is non-configurable - in other words, it cannot take a `select()` value. If the `configurable` is either unbound or explicitly set to `True`, the attribute is configurable and can take a `select()` value. For an attribute of a rule or aspect, `configurable` must be left unbound. Most Starlark rule attributes are always configurable, with the exception of `attr.output()`, `attr.output_list()`, and `attr.license()` rule attributes, which are always non-configurable. |
-| `default` | [sequence](../core/list) of [int](../core/int)s; default is `[]`  A default value to use if no value for this attribute is given when instantiating the rule. |
-| `doc` | [string](../core/string); or `None`; default is `None`  A description of the attribute that can be extracted by documentation generating tools. |
+| `mandatory` | [bool](/versions/8.5.1/rules/lib/core/bool); default is `False`  If true, the value must be specified explicitly (even if it has a `default`). |
+| `allow_empty` | [bool](/versions/8.5.1/rules/lib/core/bool); default is `True`  True if the attribute can be empty. |
+| `configurable` | [bool](/versions/8.5.1/rules/lib/core/bool); or unbound; default is `unbound`  This argument can only be specified for an attribute of a symbolic macro. If `configurable` is explicitly set to `False`, the symbolic macro attribute is non-configurable - in other words, it cannot take a `select()` value. If the `configurable` is either unbound or explicitly set to `True`, the attribute is configurable and can take a `select()` value. For an attribute of a rule or aspect, `configurable` must be left unbound. Most Starlark rule attributes are always configurable, with the exception of `attr.output()`, `attr.output_list()`, and `attr.license()` rule attributes, which are always non-configurable. |
+| `default` | [sequence](/versions/8.5.1/rules/lib/core/list) of [int](/versions/8.5.1/rules/lib/core/int)s; default is `[]`  A default value to use if no value for this attribute is given when instantiating the rule. |
+| `doc` | [string](/versions/8.5.1/rules/lib/core/string); or `None`; default is `None`  A description of the attribute that can be extracted by documentation generating tools. |
 
 ## label
 
@@ -84,9 +84,9 @@ Attribute attr.label(configurable=unbound, default=None, materializer=None, doc=
 
 Creates a schema for a label attribute. This is a dependency attribute.
 
-This attribute contains unique [`Label`](../builtins/Label) values. If a string is supplied in place of a `Label`, it will be converted using the [label constructor](../builtins/Label#Label). The relative parts of the label path, including the (possibly renamed) repository, are resolved with respect to the instantiated target's package.
+This attribute contains unique [`Label`](/versions/8.5.1/rules/lib/builtins/Label) values. If a string is supplied in place of a `Label`, it will be converted using the [label constructor](/versions/8.5.1/rules/lib/builtins/Label#Label). The relative parts of the label path, including the (possibly renamed) repository, are resolved with respect to the instantiated target's package.
 
-At analysis time (within the rule's implementation function), when retrieving the attribute value from `ctx.attr`, labels are replaced by the corresponding [`Target`](../builtins/Target)s. This allows you to access the providers of the current target's dependencies.
+At analysis time (within the rule's implementation function), when retrieving the attribute value from `ctx.attr`, labels are replaced by the corresponding [`Target`](/versions/8.5.1/rules/lib/builtins/Target)s. This allows you to access the providers of the current target's dependencies.
 
 In addition to ordinary source files, this kind of attribute is often used to refer to a tool -- for example, a compiler. Such tools are considered to be dependencies, just like source files. To avoid requiring users to specify the tool's label every time they use the rule in their BUILD files, you can hard-code the label of a canonical tool as the `default` value of this attribute. If you also want to prevent users from overriding this default, you can make the attribute private by giving it a name that starts with an underscore. See the [Rules](https://bazel.build/versions/8.5.1/extending/rules#private-attributes) page for more information.
 
@@ -94,21 +94,21 @@ In addition to ordinary source files, this kind of attribute is often used to re
 
 | Parameter | Description |
 | --- | --- |
-| `configurable` | [bool](../core/bool); or unbound; default is `unbound`  This argument can only be specified for an attribute of a symbolic macro. If `configurable` is explicitly set to `False`, the symbolic macro attribute is non-configurable - in other words, it cannot take a `select()` value. If the `configurable` is either unbound or explicitly set to `True`, the attribute is configurable and can take a `select()` value. For an attribute of a rule or aspect, `configurable` must be left unbound. Most Starlark rule attributes are always configurable, with the exception of `attr.output()`, `attr.output_list()`, and `attr.license()` rule attributes, which are always non-configurable. |
-| `default` | [Label](../builtins/Label); or [string](../core/string); or [LateBoundDefault](../builtins/LateBoundDefault); or NativeComputedDefault; or [function](../core/function); or `None`; default is `None`  A default value to use if no value for this attribute is given when instantiating the rule.Use a string or the [`Label`](../builtins/Label#Label) function to specify a default value, for example, `attr.label(default = "//a:b")`. |
-| `materializer` | [function](../core/function); default is `None`  **Experimental**. This parameter is experimental and may change at any time. Please do not depend on it. It may be enabled on an experimental basis by setting `--experimental_dormant_deps`  If set, the attribute materializes dormant dependencies from the transitive closure. The value of this parameter must be a functon that gets access to the values of the attributes of the rule that either are not dependencies or are marked as available for dependency resolution. It must return either a dormant dependency or a list of them depending on the type of the attribute |
-| `doc` | [string](../core/string); or `None`; default is `None` |
-| `executable` | [bool](../core/bool); default is `False`  True if the dependency has to be executable. This means the label must refer to an executable file, or to a rule that outputs an executable file. Access the label with `ctx.executable.`. |
-| `allow_files` | [bool](../core/bool); or [sequence](../core/list) of [string](../core/string)s; or `None`; default is `None`  Whether `File` targets are allowed. Can be `True`, `False` (default), or a list of file extensions that are allowed (for example, `[".cc", ".cpp"]`). |
-| `allow_single_file` | default is `None`  This is similar to `allow_files`, with the restriction that the label must correspond to a single [File](../builtins/File). Access it through `ctx.file.`. |
-| `mandatory` | [bool](../core/bool); default is `False`  If true, the value must be specified explicitly (even if it has a `default`). |
-| `skip_validations` | [bool](../core/bool); default is `False`  If true, validation actions of transitive dependencies from this attribute will not run. This is a temporary mitigation and WILL be removed in the future. |
-| `providers` | [sequence](../core/list); default is `[]`  The providers that must be given by any dependency appearing in this attribute. The format of this argument is a list of lists of providers -- `*Info` objects returned by [`provider()`](../globals/bzl#provider) (or in the case of a legacy provider, its string name). The dependency must return ALL providers mentioned in at least ONE of the inner lists. As a convenience, this argument may also be a single-level list of providers, in which case it is wrapped in an outer list with one element. It is NOT required that the rule of the dependency advertises those providers in its `provides` parameter, however, it is considered best practice. |
+| `configurable` | [bool](/versions/8.5.1/rules/lib/core/bool); or unbound; default is `unbound`  This argument can only be specified for an attribute of a symbolic macro. If `configurable` is explicitly set to `False`, the symbolic macro attribute is non-configurable - in other words, it cannot take a `select()` value. If the `configurable` is either unbound or explicitly set to `True`, the attribute is configurable and can take a `select()` value. For an attribute of a rule or aspect, `configurable` must be left unbound. Most Starlark rule attributes are always configurable, with the exception of `attr.output()`, `attr.output_list()`, and `attr.license()` rule attributes, which are always non-configurable. |
+| `default` | [Label](/versions/8.5.1/rules/lib/builtins/Label); or [string](/versions/8.5.1/rules/lib/core/string); or [LateBoundDefault](/versions/8.5.1/rules/lib/builtins/LateBoundDefault); or NativeComputedDefault; or [function](/versions/8.5.1/rules/lib/core/function); or `None`; default is `None`  A default value to use if no value for this attribute is given when instantiating the rule.Use a string or the [`Label`](/versions/8.5.1/rules/lib/builtins/Label#Label) function to specify a default value, for example, `attr.label(default = "//a:b")`. |
+| `materializer` | [function](/versions/8.5.1/rules/lib/core/function); default is `None`  **Experimental**. This parameter is experimental and may change at any time. Please do not depend on it. It may be enabled on an experimental basis by setting `--experimental_dormant_deps`  If set, the attribute materializes dormant dependencies from the transitive closure. The value of this parameter must be a functon that gets access to the values of the attributes of the rule that either are not dependencies or are marked as available for dependency resolution. It must return either a dormant dependency or a list of them depending on the type of the attribute |
+| `doc` | [string](/versions/8.5.1/rules/lib/core/string); or `None`; default is `None` |
+| `executable` | [bool](/versions/8.5.1/rules/lib/core/bool); default is `False`  True if the dependency has to be executable. This means the label must refer to an executable file, or to a rule that outputs an executable file. Access the label with `ctx.executable.`. |
+| `allow_files` | [bool](/versions/8.5.1/rules/lib/core/bool); or [sequence](/versions/8.5.1/rules/lib/core/list) of [string](/versions/8.5.1/rules/lib/core/string)s; or `None`; default is `None`  Whether `File` targets are allowed. Can be `True`, `False` (default), or a list of file extensions that are allowed (for example, `[".cc", ".cpp"]`). |
+| `allow_single_file` | default is `None`  This is similar to `allow_files`, with the restriction that the label must correspond to a single [File](/versions/8.5.1/rules/lib/builtins/File). Access it through `ctx.file.`. |
+| `mandatory` | [bool](/versions/8.5.1/rules/lib/core/bool); default is `False`  If true, the value must be specified explicitly (even if it has a `default`). |
+| `skip_validations` | [bool](/versions/8.5.1/rules/lib/core/bool); default is `False`  If true, validation actions of transitive dependencies from this attribute will not run. This is a temporary mitigation and WILL be removed in the future. |
+| `providers` | [sequence](/versions/8.5.1/rules/lib/core/list); default is `[]`  The providers that must be given by any dependency appearing in this attribute. The format of this argument is a list of lists of providers -- `*Info` objects returned by [`provider()`](/versions/8.5.1/rules/lib/globals/bzl#provider) (or in the case of a legacy provider, its string name). The dependency must return ALL providers mentioned in at least ONE of the inner lists. As a convenience, this argument may also be a single-level list of providers, in which case it is wrapped in an outer list with one element. It is NOT required that the rule of the dependency advertises those providers in its `provides` parameter, however, it is considered best practice. |
 | `for_dependency_resolution` | default is `unbound`  If this is set, the attribute is available for materializers. Only rules marked with the flag of the same name are allowed to be referenced through such attributes. |
-| `allow_rules` | [sequence](../core/list) of [string](../core/string)s; or `None`; default is `None`  Which rule targets (name of the classes) are allowed. This is deprecated (kept only for compatibility), use providers instead. |
+| `allow_rules` | [sequence](/versions/8.5.1/rules/lib/core/list) of [string](/versions/8.5.1/rules/lib/core/string)s; or `None`; default is `None`  Which rule targets (name of the classes) are allowed. This is deprecated (kept only for compatibility), use providers instead. |
 | `cfg` | default is `None`  [Configuration](https://bazel.build/versions/8.5.1/extending/rules#configurations) of the attribute. It can be either `"exec"`, which indicates that the dependency is built for the `execution platform`, or `"target"`, which indicates that the dependency is build for the `target platform`. A typical example of the difference is when building mobile apps, where the `target platform` is `Android` or `iOS` while the `execution platform` is `Linux`, `macOS`, or `Windows`. This parameter is required if `executable` is True to guard against accidentally building host tools in the target configuration. `"target"` has no semantic effect, so don't set it when `executable` is False unless it really helps clarify your intentions. |
-| `aspects` | [sequence](../core/list) of [Aspect](../builtins/Aspect)s; default is `[]`  Aspects that should be applied to the dependency or dependencies specified by this attribute. |
-| `flags` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  Deprecated, will be removed. |
+| `aspects` | [sequence](/versions/8.5.1/rules/lib/core/list) of [Aspect](/versions/8.5.1/rules/lib/builtins/Aspect)s; default is `[]`  Aspects that should be applied to the dependency or dependencies specified by this attribute. |
+| `flags` | [sequence](/versions/8.5.1/rules/lib/core/list) of [string](/versions/8.5.1/rules/lib/core/string)s; default is `[]`  Deprecated, will be removed. |
 
 ## label\_keyed\_string\_dict
 
@@ -118,26 +118,26 @@ Attribute attr.label_keyed_string_dict(allow_empty=True, *, configurable=unbound
 
 Creates a schema for an attribute holding a dictionary, where the keys are labels and the values are strings. This is a dependency attribute.
 
-This attribute contains unique [`Label`](../builtins/Label) values. If a string is supplied in place of a `Label`, it will be converted using the [label constructor](../builtins/Label#Label). The relative parts of the label path, including the (possibly renamed) repository, are resolved with respect to the instantiated target's package.
+This attribute contains unique [`Label`](/versions/8.5.1/rules/lib/builtins/Label) values. If a string is supplied in place of a `Label`, it will be converted using the [label constructor](/versions/8.5.1/rules/lib/builtins/Label#Label). The relative parts of the label path, including the (possibly renamed) repository, are resolved with respect to the instantiated target's package.
 
-At analysis time (within the rule's implementation function), when retrieving the attribute value from `ctx.attr`, labels are replaced by the corresponding [`Target`](../builtins/Target)s. This allows you to access the providers of the current target's dependencies.
+At analysis time (within the rule's implementation function), when retrieving the attribute value from `ctx.attr`, labels are replaced by the corresponding [`Target`](/versions/8.5.1/rules/lib/builtins/Target)s. This allows you to access the providers of the current target's dependencies.
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `allow_empty` | [bool](../core/bool); default is `True`  True if the attribute can be empty. |
-| `configurable` | [bool](../core/bool); or unbound; default is `unbound`  This argument can only be specified for an attribute of a symbolic macro. If `configurable` is explicitly set to `False`, the symbolic macro attribute is non-configurable - in other words, it cannot take a `select()` value. If the `configurable` is either unbound or explicitly set to `True`, the attribute is configurable and can take a `select()` value. For an attribute of a rule or aspect, `configurable` must be left unbound. Most Starlark rule attributes are always configurable, with the exception of `attr.output()`, `attr.output_list()`, and `attr.license()` rule attributes, which are always non-configurable. |
-| `default` | [dict](../core/dict); or [function](../core/function); default is `{}`  A default value to use if no value for this attribute is given when instantiating the rule.Use strings or the [`Label`](../builtins/Label#Label) function to specify default values, for example, `attr.label_keyed_string_dict(default = {"//a:b": "value", "//a:c": "string"})`. |
-| `doc` | [string](../core/string); or `None`; default is `None`  A description of the attribute that can be extracted by documentation generating tools. |
-| `allow_files` | [bool](../core/bool); or [sequence](../core/list) of [string](../core/string)s; or `None`; default is `None`  Whether `File` targets are allowed. Can be `True`, `False` (default), or a list of file extensions that are allowed (for example, `[".cc", ".cpp"]`). |
-| `allow_rules` | [sequence](../core/list) of [string](../core/string)s; or `None`; default is `None`  Which rule targets (name of the classes) are allowed. This is deprecated (kept only for compatibility), use providers instead. |
-| `providers` | [sequence](../core/list); default is `[]`  The providers that must be given by any dependency appearing in this attribute. The format of this argument is a list of lists of providers -- `*Info` objects returned by [`provider()`](../globals/bzl#provider) (or in the case of a legacy provider, its string name). The dependency must return ALL providers mentioned in at least ONE of the inner lists. As a convenience, this argument may also be a single-level list of providers, in which case it is wrapped in an outer list with one element. It is NOT required that the rule of the dependency advertises those providers in its `provides` parameter, however, it is considered best practice. |
+| `allow_empty` | [bool](/versions/8.5.1/rules/lib/core/bool); default is `True`  True if the attribute can be empty. |
+| `configurable` | [bool](/versions/8.5.1/rules/lib/core/bool); or unbound; default is `unbound`  This argument can only be specified for an attribute of a symbolic macro. If `configurable` is explicitly set to `False`, the symbolic macro attribute is non-configurable - in other words, it cannot take a `select()` value. If the `configurable` is either unbound or explicitly set to `True`, the attribute is configurable and can take a `select()` value. For an attribute of a rule or aspect, `configurable` must be left unbound. Most Starlark rule attributes are always configurable, with the exception of `attr.output()`, `attr.output_list()`, and `attr.license()` rule attributes, which are always non-configurable. |
+| `default` | [dict](/versions/8.5.1/rules/lib/core/dict); or [function](/versions/8.5.1/rules/lib/core/function); default is `{}`  A default value to use if no value for this attribute is given when instantiating the rule.Use strings or the [`Label`](/versions/8.5.1/rules/lib/builtins/Label#Label) function to specify default values, for example, `attr.label_keyed_string_dict(default = {"//a:b": "value", "//a:c": "string"})`. |
+| `doc` | [string](/versions/8.5.1/rules/lib/core/string); or `None`; default is `None`  A description of the attribute that can be extracted by documentation generating tools. |
+| `allow_files` | [bool](/versions/8.5.1/rules/lib/core/bool); or [sequence](/versions/8.5.1/rules/lib/core/list) of [string](/versions/8.5.1/rules/lib/core/string)s; or `None`; default is `None`  Whether `File` targets are allowed. Can be `True`, `False` (default), or a list of file extensions that are allowed (for example, `[".cc", ".cpp"]`). |
+| `allow_rules` | [sequence](/versions/8.5.1/rules/lib/core/list) of [string](/versions/8.5.1/rules/lib/core/string)s; or `None`; default is `None`  Which rule targets (name of the classes) are allowed. This is deprecated (kept only for compatibility), use providers instead. |
+| `providers` | [sequence](/versions/8.5.1/rules/lib/core/list); default is `[]`  The providers that must be given by any dependency appearing in this attribute. The format of this argument is a list of lists of providers -- `*Info` objects returned by [`provider()`](/versions/8.5.1/rules/lib/globals/bzl#provider) (or in the case of a legacy provider, its string name). The dependency must return ALL providers mentioned in at least ONE of the inner lists. As a convenience, this argument may also be a single-level list of providers, in which case it is wrapped in an outer list with one element. It is NOT required that the rule of the dependency advertises those providers in its `provides` parameter, however, it is considered best practice. |
 | `for_dependency_resolution` | default is `unbound`  If this is set, the attribute is available for materializers. Only rules marked with the flag of the same name are allowed to be referenced through such attributes. |
-| `flags` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  Deprecated, will be removed. |
-| `mandatory` | [bool](../core/bool); default is `False`  If true, the value must be specified explicitly (even if it has a `default`). |
+| `flags` | [sequence](/versions/8.5.1/rules/lib/core/list) of [string](/versions/8.5.1/rules/lib/core/string)s; default is `[]`  Deprecated, will be removed. |
+| `mandatory` | [bool](/versions/8.5.1/rules/lib/core/bool); default is `False`  If true, the value must be specified explicitly (even if it has a `default`). |
 | `cfg` | default is `None`  [Configuration](https://bazel.build/versions/8.5.1/extending/rules#configurations) of the attribute. It can be either `"exec"`, which indicates that the dependency is built for the `execution platform`, or `"target"`, which indicates that the dependency is build for the `target platform`. A typical example of the difference is when building mobile apps, where the `target platform` is `Android` or `iOS` while the `execution platform` is `Linux`, `macOS`, or `Windows`. |
-| `aspects` | [sequence](../core/list) of [Aspect](../builtins/Aspect)s; default is `[]`  Aspects that should be applied to the dependency or dependencies specified by this attribute. |
+| `aspects` | [sequence](/versions/8.5.1/rules/lib/core/list) of [Aspect](/versions/8.5.1/rules/lib/builtins/Aspect)s; default is `[]`  Aspects that should be applied to the dependency or dependencies specified by this attribute. |
 
 ## label\_list
 
@@ -145,30 +145,30 @@ At analysis time (within the rule's implementation function), when retrieving th
 Attribute attr.label_list(allow_empty=True, *, configurable=unbound, default=[], materializer=None, doc=None, allow_files=None, allow_rules=None, providers=[], for_dependency_resolution=unbound, flags=[], mandatory=False, skip_validations=False, cfg=None, aspects=[])
 ```
 
-Creates a schema for a list-of-labels attribute. This is a dependency attribute. The corresponding [`ctx.attr`](../builtins/ctx#attr) attribute will be of type [list](../core/list) of [`Target`s](../builtins/Target).
+Creates a schema for a list-of-labels attribute. This is a dependency attribute. The corresponding [`ctx.attr`](/versions/8.5.1/rules/lib/builtins/ctx#attr) attribute will be of type [list](/versions/8.5.1/rules/lib/core/list) of [`Target`s](/versions/8.5.1/rules/lib/builtins/Target).
 
-This attribute contains unique [`Label`](../builtins/Label) values. If a string is supplied in place of a `Label`, it will be converted using the [label constructor](../builtins/Label#Label). The relative parts of the label path, including the (possibly renamed) repository, are resolved with respect to the instantiated target's package.
+This attribute contains unique [`Label`](/versions/8.5.1/rules/lib/builtins/Label) values. If a string is supplied in place of a `Label`, it will be converted using the [label constructor](/versions/8.5.1/rules/lib/builtins/Label#Label). The relative parts of the label path, including the (possibly renamed) repository, are resolved with respect to the instantiated target's package.
 
-At analysis time (within the rule's implementation function), when retrieving the attribute value from `ctx.attr`, labels are replaced by the corresponding [`Target`](../builtins/Target)s. This allows you to access the providers of the current target's dependencies.
+At analysis time (within the rule's implementation function), when retrieving the attribute value from `ctx.attr`, labels are replaced by the corresponding [`Target`](/versions/8.5.1/rules/lib/builtins/Target)s. This allows you to access the providers of the current target's dependencies.
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `allow_empty` | [bool](../core/bool); default is `True`  True if the attribute can be empty. |
-| `configurable` | [bool](../core/bool); or unbound; default is `unbound`  This argument can only be specified for an attribute of a symbolic macro. If `configurable` is explicitly set to `False`, the symbolic macro attribute is non-configurable - in other words, it cannot take a `select()` value. If the `configurable` is either unbound or explicitly set to `True`, the attribute is configurable and can take a `select()` value. For an attribute of a rule or aspect, `configurable` must be left unbound. Most Starlark rule attributes are always configurable, with the exception of `attr.output()`, `attr.output_list()`, and `attr.license()` rule attributes, which are always non-configurable. |
-| `default` | [sequence](../core/list) of [Label](../builtins/Label)s; or [function](../core/function); default is `[]`  A default value to use if no value for this attribute is given when instantiating the rule.Use strings or the [`Label`](../builtins/Label#Label) function to specify default values, for example, `attr.label_list(default = ["//a:b", "//a:c"])`. |
-| `materializer` | [function](../core/function); default is `None`  **Experimental**. This parameter is experimental and may change at any time. Please do not depend on it. It may be enabled on an experimental basis by setting `--experimental_dormant_deps`  If set, the attribute materializes dormant dependencies from the transitive closure. The value of this parameter must be a functon that gets access to the values of the attributes of the rule that either are not dependencies or are marked as available for dependency resolution. It must return either a dormant dependency or a list of them depending on the type of the attribute |
-| `doc` | [string](../core/string); or `None`; default is `None` |
-| `allow_files` | [bool](../core/bool); or [sequence](../core/list) of [string](../core/string)s; or `None`; default is `None`  Whether `File` targets are allowed. Can be `True`, `False` (default), or a list of file extensions that are allowed (for example, `[".cc", ".cpp"]`). |
-| `allow_rules` | [sequence](../core/list) of [string](../core/string)s; or `None`; default is `None`  Which rule targets (name of the classes) are allowed. This is deprecated (kept only for compatibility), use providers instead. |
-| `providers` | [sequence](../core/list); default is `[]`  The providers that must be given by any dependency appearing in this attribute. The format of this argument is a list of lists of providers -- `*Info` objects returned by [`provider()`](../globals/bzl#provider) (or in the case of a legacy provider, its string name). The dependency must return ALL providers mentioned in at least ONE of the inner lists. As a convenience, this argument may also be a single-level list of providers, in which case it is wrapped in an outer list with one element. It is NOT required that the rule of the dependency advertises those providers in its `provides` parameter, however, it is considered best practice. |
+| `allow_empty` | [bool](/versions/8.5.1/rules/lib/core/bool); default is `True`  True if the attribute can be empty. |
+| `configurable` | [bool](/versions/8.5.1/rules/lib/core/bool); or unbound; default is `unbound`  This argument can only be specified for an attribute of a symbolic macro. If `configurable` is explicitly set to `False`, the symbolic macro attribute is non-configurable - in other words, it cannot take a `select()` value. If the `configurable` is either unbound or explicitly set to `True`, the attribute is configurable and can take a `select()` value. For an attribute of a rule or aspect, `configurable` must be left unbound. Most Starlark rule attributes are always configurable, with the exception of `attr.output()`, `attr.output_list()`, and `attr.license()` rule attributes, which are always non-configurable. |
+| `default` | [sequence](/versions/8.5.1/rules/lib/core/list) of [Label](/versions/8.5.1/rules/lib/builtins/Label)s; or [function](/versions/8.5.1/rules/lib/core/function); default is `[]`  A default value to use if no value for this attribute is given when instantiating the rule.Use strings or the [`Label`](/versions/8.5.1/rules/lib/builtins/Label#Label) function to specify default values, for example, `attr.label_list(default = ["//a:b", "//a:c"])`. |
+| `materializer` | [function](/versions/8.5.1/rules/lib/core/function); default is `None`  **Experimental**. This parameter is experimental and may change at any time. Please do not depend on it. It may be enabled on an experimental basis by setting `--experimental_dormant_deps`  If set, the attribute materializes dormant dependencies from the transitive closure. The value of this parameter must be a functon that gets access to the values of the attributes of the rule that either are not dependencies or are marked as available for dependency resolution. It must return either a dormant dependency or a list of them depending on the type of the attribute |
+| `doc` | [string](/versions/8.5.1/rules/lib/core/string); or `None`; default is `None` |
+| `allow_files` | [bool](/versions/8.5.1/rules/lib/core/bool); or [sequence](/versions/8.5.1/rules/lib/core/list) of [string](/versions/8.5.1/rules/lib/core/string)s; or `None`; default is `None`  Whether `File` targets are allowed. Can be `True`, `False` (default), or a list of file extensions that are allowed (for example, `[".cc", ".cpp"]`). |
+| `allow_rules` | [sequence](/versions/8.5.1/rules/lib/core/list) of [string](/versions/8.5.1/rules/lib/core/string)s; or `None`; default is `None`  Which rule targets (name of the classes) are allowed. This is deprecated (kept only for compatibility), use providers instead. |
+| `providers` | [sequence](/versions/8.5.1/rules/lib/core/list); default is `[]`  The providers that must be given by any dependency appearing in this attribute. The format of this argument is a list of lists of providers -- `*Info` objects returned by [`provider()`](/versions/8.5.1/rules/lib/globals/bzl#provider) (or in the case of a legacy provider, its string name). The dependency must return ALL providers mentioned in at least ONE of the inner lists. As a convenience, this argument may also be a single-level list of providers, in which case it is wrapped in an outer list with one element. It is NOT required that the rule of the dependency advertises those providers in its `provides` parameter, however, it is considered best practice. |
 | `for_dependency_resolution` | default is `unbound`  If this is set, the attribute is available for materializers. Only rules marked with the flag of the same name are allowed to be referenced through such attributes. |
-| `flags` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  Deprecated, will be removed. |
-| `mandatory` | [bool](../core/bool); default is `False`  If true, the value must be specified explicitly (even if it has a `default`). |
-| `skip_validations` | [bool](../core/bool); default is `False`  If true, validation actions of transitive dependencies from this attribute will not run. This is a temporary mitigation and WILL be removed in the future. |
+| `flags` | [sequence](/versions/8.5.1/rules/lib/core/list) of [string](/versions/8.5.1/rules/lib/core/string)s; default is `[]`  Deprecated, will be removed. |
+| `mandatory` | [bool](/versions/8.5.1/rules/lib/core/bool); default is `False`  If true, the value must be specified explicitly (even if it has a `default`). |
+| `skip_validations` | [bool](/versions/8.5.1/rules/lib/core/bool); default is `False`  If true, validation actions of transitive dependencies from this attribute will not run. This is a temporary mitigation and WILL be removed in the future. |
 | `cfg` | default is `None`  [Configuration](https://bazel.build/versions/8.5.1/extending/rules#configurations) of the attribute. It can be either `"exec"`, which indicates that the dependency is built for the `execution platform`, or `"target"`, which indicates that the dependency is build for the `target platform`. A typical example of the difference is when building mobile apps, where the `target platform` is `Android` or `iOS` while the `execution platform` is `Linux`, `macOS`, or `Windows`. |
-| `aspects` | [sequence](../core/list) of [Aspect](../builtins/Aspect)s; default is `[]`  Aspects that should be applied to the dependency or dependencies specified by this attribute. |
+| `aspects` | [sequence](/versions/8.5.1/rules/lib/core/list) of [Aspect](/versions/8.5.1/rules/lib/builtins/Aspect)s; default is `[]`  Aspects that should be applied to the dependency or dependencies specified by this attribute. |
 
 ## output
 
@@ -178,16 +178,16 @@ Attribute attr.output(doc=None, mandatory=False)
 
 Creates a schema for an output (label) attribute.
 
-This attribute contains unique [`Label`](../builtins/Label) values. If a string is supplied in place of a `Label`, it will be converted using the [label constructor](../builtins/Label#Label). The relative parts of the label path, including the (possibly renamed) repository, are resolved with respect to the instantiated target's package.
+This attribute contains unique [`Label`](/versions/8.5.1/rules/lib/builtins/Label) values. If a string is supplied in place of a `Label`, it will be converted using the [label constructor](/versions/8.5.1/rules/lib/builtins/Label#Label). The relative parts of the label path, including the (possibly renamed) repository, are resolved with respect to the instantiated target's package.
 
-At analysis time, the corresponding [`File`](../builtins/File) can be retrieved using [`ctx.outputs`](../builtins/ctx#outputs).
+At analysis time, the corresponding [`File`](/versions/8.5.1/rules/lib/builtins/File) can be retrieved using [`ctx.outputs`](/versions/8.5.1/rules/lib/builtins/ctx#outputs).
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `doc` | [string](../core/string); or `None`; default is `None`  A description of the attribute that can be extracted by documentation generating tools. |
-| `mandatory` | [bool](../core/bool); default is `False`  If true, the value must be specified explicitly (even if it has a `default`). |
+| `doc` | [string](/versions/8.5.1/rules/lib/core/string); or `None`; default is `None`  A description of the attribute that can be extracted by documentation generating tools. |
+| `mandatory` | [bool](/versions/8.5.1/rules/lib/core/bool); default is `False`  If true, the value must be specified explicitly (even if it has a `default`). |
 
 ## output\_list
 
@@ -197,17 +197,17 @@ Attribute attr.output_list(allow_empty=True, *, doc=None, mandatory=False)
 
 Creates a schema for a list-of-outputs attribute.
 
-This attribute contains unique [`Label`](../builtins/Label) values. If a string is supplied in place of a `Label`, it will be converted using the [label constructor](../builtins/Label#Label). The relative parts of the label path, including the (possibly renamed) repository, are resolved with respect to the instantiated target's package.
+This attribute contains unique [`Label`](/versions/8.5.1/rules/lib/builtins/Label) values. If a string is supplied in place of a `Label`, it will be converted using the [label constructor](/versions/8.5.1/rules/lib/builtins/Label#Label). The relative parts of the label path, including the (possibly renamed) repository, are resolved with respect to the instantiated target's package.
 
-At analysis time, the corresponding [`File`](../builtins/File) can be retrieved using [`ctx.outputs`](../builtins/ctx#outputs).
+At analysis time, the corresponding [`File`](/versions/8.5.1/rules/lib/builtins/File) can be retrieved using [`ctx.outputs`](/versions/8.5.1/rules/lib/builtins/ctx#outputs).
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `allow_empty` | [bool](../core/bool); default is `True`  True if the attribute can be empty. |
-| `doc` | [string](../core/string); or `None`; default is `None`  A description of the attribute that can be extracted by documentation generating tools. |
-| `mandatory` | [bool](../core/bool); default is `False`  If true, the value must be specified explicitly (even if it has a `default`). |
+| `allow_empty` | [bool](/versions/8.5.1/rules/lib/core/bool); default is `True`  True if the attribute can be empty. |
+| `doc` | [string](/versions/8.5.1/rules/lib/core/string); or `None`; default is `None`  A description of the attribute that can be extracted by documentation generating tools. |
+| `mandatory` | [bool](/versions/8.5.1/rules/lib/core/bool); default is `False`  If true, the value must be specified explicitly (even if it has a `default`). |
 
 ## string
 
@@ -215,17 +215,17 @@ At analysis time, the corresponding [`File`](../builtins/File) can be retrieved
 Attribute attr.string(configurable=unbound, default='', doc=None, mandatory=False, values=[])
 ```
 
-Creates a schema for a [string](../core/string#attr) attribute.
+Creates a schema for a [string](/versions/8.5.1/rules/lib/core/string#attr) attribute.
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `configurable` | [bool](../core/bool); or unbound; default is `unbound`  This argument can only be specified for an attribute of a symbolic macro. If `configurable` is explicitly set to `False`, the symbolic macro attribute is non-configurable - in other words, it cannot take a `select()` value. If the `configurable` is either unbound or explicitly set to `True`, the attribute is configurable and can take a `select()` value. For an attribute of a rule or aspect, `configurable` must be left unbound. Most Starlark rule attributes are always configurable, with the exception of `attr.output()`, `attr.output_list()`, and `attr.license()` rule attributes, which are always non-configurable. |
-| `default` | [string](../core/string); or NativeComputedDefault; default is `''`  A default value to use if no value for this attribute is given when instantiating the rule. |
-| `doc` | [string](../core/string); or `None`; default is `None`  A description of the attribute that can be extracted by documentation generating tools. |
-| `mandatory` | [bool](../core/bool); default is `False`  If true, the value must be specified explicitly (even if it has a `default`). |
-| `values` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  The list of allowed values for the attribute. An error is raised if any other value is given. |
+| `configurable` | [bool](/versions/8.5.1/rules/lib/core/bool); or unbound; default is `unbound`  This argument can only be specified for an attribute of a symbolic macro. If `configurable` is explicitly set to `False`, the symbolic macro attribute is non-configurable - in other words, it cannot take a `select()` value. If the `configurable` is either unbound or explicitly set to `True`, the attribute is configurable and can take a `select()` value. For an attribute of a rule or aspect, `configurable` must be left unbound. Most Starlark rule attributes are always configurable, with the exception of `attr.output()`, `attr.output_list()`, and `attr.license()` rule attributes, which are always non-configurable. |
+| `default` | [string](/versions/8.5.1/rules/lib/core/string); or NativeComputedDefault; default is `''`  A default value to use if no value for this attribute is given when instantiating the rule. |
+| `doc` | [string](/versions/8.5.1/rules/lib/core/string); or `None`; default is `None`  A description of the attribute that can be extracted by documentation generating tools. |
+| `mandatory` | [bool](/versions/8.5.1/rules/lib/core/bool); default is `False`  If true, the value must be specified explicitly (even if it has a `default`). |
+| `values` | [sequence](/versions/8.5.1/rules/lib/core/list) of [string](/versions/8.5.1/rules/lib/core/string)s; default is `[]`  The list of allowed values for the attribute. An error is raised if any other value is given. |
 
 ## string\_dict
 
@@ -239,11 +239,11 @@ Creates a schema for an attribute holding a dictionary, where the keys and value
 
 | Parameter | Description |
 | --- | --- |
-| `allow_empty` | [bool](../core/bool); default is `True`  True if the attribute can be empty. |
-| `configurable` | [bool](../core/bool); or unbound; default is `unbound`  This argument can only be specified for an attribute of a symbolic macro. If `configurable` is explicitly set to `False`, the symbolic macro attribute is non-configurable - in other words, it cannot take a `select()` value. If the `configurable` is either unbound or explicitly set to `True`, the attribute is configurable and can take a `select()` value. For an attribute of a rule or aspect, `configurable` must be left unbound. Most Starlark rule attributes are always configurable, with the exception of `attr.output()`, `attr.output_list()`, and `attr.license()` rule attributes, which are always non-configurable. |
-| `default` | [dict](../core/dict); default is `{}`  A default value to use if no value for this attribute is given when instantiating the rule. |
-| `doc` | [string](../core/string); or `None`; default is `None`  A description of the attribute that can be extracted by documentation generating tools. |
-| `mandatory` | [bool](../core/bool); default is `False`  If true, the value must be specified explicitly (even if it has a `default`). |
+| `allow_empty` | [bool](/versions/8.5.1/rules/lib/core/bool); default is `True`  True if the attribute can be empty. |
+| `configurable` | [bool](/versions/8.5.1/rules/lib/core/bool); or unbound; default is `unbound`  This argument can only be specified for an attribute of a symbolic macro. If `configurable` is explicitly set to `False`, the symbolic macro attribute is non-configurable - in other words, it cannot take a `select()` value. If the `configurable` is either unbound or explicitly set to `True`, the attribute is configurable and can take a `select()` value. For an attribute of a rule or aspect, `configurable` must be left unbound. Most Starlark rule attributes are always configurable, with the exception of `attr.output()`, `attr.output_list()`, and `attr.license()` rule attributes, which are always non-configurable. |
+| `default` | [dict](/versions/8.5.1/rules/lib/core/dict); default is `{}`  A default value to use if no value for this attribute is given when instantiating the rule. |
+| `doc` | [string](/versions/8.5.1/rules/lib/core/string); or `None`; default is `None`  A description of the attribute that can be extracted by documentation generating tools. |
+| `mandatory` | [bool](/versions/8.5.1/rules/lib/core/bool); default is `False`  If true, the value must be specified explicitly (even if it has a `default`). |
 
 ## string\_keyed\_label\_dict
 
@@ -253,26 +253,26 @@ Attribute attr.string_keyed_label_dict(allow_empty=True, *, configurable=unbound
 
 Creates a schema for an attribute whose value is a dictionary where the keys are strings and the values are labels. This is a dependency attribute.
 
-This attribute contains unique [`Label`](../builtins/Label) values. If a string is supplied in place of a `Label`, it will be converted using the [label constructor](../builtins/Label#Label). The relative parts of the label path, including the (possibly renamed) repository, are resolved with respect to the instantiated target's package.
+This attribute contains unique [`Label`](/versions/8.5.1/rules/lib/builtins/Label) values. If a string is supplied in place of a `Label`, it will be converted using the [label constructor](/versions/8.5.1/rules/lib/builtins/Label#Label). The relative parts of the label path, including the (possibly renamed) repository, are resolved with respect to the instantiated target's package.
 
-At analysis time (within the rule's implementation function), when retrieving the attribute value from `ctx.attr`, labels are replaced by the corresponding [`Target`](../builtins/Target)s. This allows you to access the providers of the current target's dependencies.
+At analysis time (within the rule's implementation function), when retrieving the attribute value from `ctx.attr`, labels are replaced by the corresponding [`Target`](/versions/8.5.1/rules/lib/builtins/Target)s. This allows you to access the providers of the current target's dependencies.
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `allow_empty` | [bool](../core/bool); default is `True`  True if the attribute can be empty. |
-| `configurable` | [bool](../core/bool); or unbound; default is `unbound`  This argument can only be specified for an attribute of a symbolic macro. If `configurable` is explicitly set to `False`, the symbolic macro attribute is non-configurable - in other words, it cannot take a `select()` value. If the `configurable` is either unbound or explicitly set to `True`, the attribute is configurable and can take a `select()` value. For an attribute of a rule or aspect, `configurable` must be left unbound. Most Starlark rule attributes are always configurable, with the exception of `attr.output()`, `attr.output_list()`, and `attr.license()` rule attributes, which are always non-configurable. |
-| `default` | [dict](../core/dict); or [function](../core/function); default is `{}`  A default value to use if no value for this attribute is given when instantiating the rule.Use strings or the [`Label`](../builtins/Label#Label) function to specify default values, for example, `attr.string_keyed_label_dict(default = {"foo": "//a:b", "bar": "//a:c"})`. |
-| `doc` | [string](../core/string); or `None`; default is `None`  A description of the attribute that can be extracted by documentation generating tools. |
-| `allow_files` | [bool](../core/bool); or [sequence](../core/list) of [string](../core/string)s; or `None`; default is `None`  Whether `File` targets are allowed. Can be `True`, `False` (default), or a list of file extensions that are allowed (for example, `[".cc", ".cpp"]`). |
-| `allow_rules` | [sequence](../core/list) of [string](../core/string)s; or `None`; default is `None`  Which rule targets (name of the classes) are allowed. This is deprecated (kept only for compatibility), use providers instead. |
-| `providers` | [sequence](../core/list); default is `[]`  The providers that must be given by any dependency appearing in this attribute. The format of this argument is a list of lists of providers -- `*Info` objects returned by [`provider()`](../globals/bzl#provider) (or in the case of a legacy provider, its string name). The dependency must return ALL providers mentioned in at least ONE of the inner lists. As a convenience, this argument may also be a single-level list of providers, in which case it is wrapped in an outer list with one element. It is NOT required that the rule of the dependency advertises those providers in its `provides` parameter, however, it is considered best practice. |
+| `allow_empty` | [bool](/versions/8.5.1/rules/lib/core/bool); default is `True`  True if the attribute can be empty. |
+| `configurable` | [bool](/versions/8.5.1/rules/lib/core/bool); or unbound; default is `unbound`  This argument can only be specified for an attribute of a symbolic macro. If `configurable` is explicitly set to `False`, the symbolic macro attribute is non-configurable - in other words, it cannot take a `select()` value. If the `configurable` is either unbound or explicitly set to `True`, the attribute is configurable and can take a `select()` value. For an attribute of a rule or aspect, `configurable` must be left unbound. Most Starlark rule attributes are always configurable, with the exception of `attr.output()`, `attr.output_list()`, and `attr.license()` rule attributes, which are always non-configurable. |
+| `default` | [dict](/versions/8.5.1/rules/lib/core/dict); or [function](/versions/8.5.1/rules/lib/core/function); default is `{}`  A default value to use if no value for this attribute is given when instantiating the rule.Use strings or the [`Label`](/versions/8.5.1/rules/lib/builtins/Label#Label) function to specify default values, for example, `attr.string_keyed_label_dict(default = {"foo": "//a:b", "bar": "//a:c"})`. |
+| `doc` | [string](/versions/8.5.1/rules/lib/core/string); or `None`; default is `None`  A description of the attribute that can be extracted by documentation generating tools. |
+| `allow_files` | [bool](/versions/8.5.1/rules/lib/core/bool); or [sequence](/versions/8.5.1/rules/lib/core/list) of [string](/versions/8.5.1/rules/lib/core/string)s; or `None`; default is `None`  Whether `File` targets are allowed. Can be `True`, `False` (default), or a list of file extensions that are allowed (for example, `[".cc", ".cpp"]`). |
+| `allow_rules` | [sequence](/versions/8.5.1/rules/lib/core/list) of [string](/versions/8.5.1/rules/lib/core/string)s; or `None`; default is `None`  Which rule targets (name of the classes) are allowed. This is deprecated (kept only for compatibility), use providers instead. |
+| `providers` | [sequence](/versions/8.5.1/rules/lib/core/list); default is `[]`  The providers that must be given by any dependency appearing in this attribute. The format of this argument is a list of lists of providers -- `*Info` objects returned by [`provider()`](/versions/8.5.1/rules/lib/globals/bzl#provider) (or in the case of a legacy provider, its string name). The dependency must return ALL providers mentioned in at least ONE of the inner lists. As a convenience, this argument may also be a single-level list of providers, in which case it is wrapped in an outer list with one element. It is NOT required that the rule of the dependency advertises those providers in its `provides` parameter, however, it is considered best practice. |
 | `for_dependency_resolution` | default is `unbound`  If this is set, the attribute is available for materializers. Only rules marked with the flag of the same name are allowed to be referenced through such attributes. |
-| `flags` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  Deprecated, will be removed. |
-| `mandatory` | [bool](../core/bool); default is `False`  If true, the value must be specified explicitly (even if it has a `default`). |
+| `flags` | [sequence](/versions/8.5.1/rules/lib/core/list) of [string](/versions/8.5.1/rules/lib/core/string)s; default is `[]`  Deprecated, will be removed. |
+| `mandatory` | [bool](/versions/8.5.1/rules/lib/core/bool); default is `False`  If true, the value must be specified explicitly (even if it has a `default`). |
 | `cfg` | default is `None`  [Configuration](https://bazel.build/versions/8.5.1/extending/rules#configurations) of the attribute. It can be either `"exec"`, which indicates that the dependency is built for the `execution platform`, or `"target"`, which indicates that the dependency is build for the `target platform`. A typical example of the difference is when building mobile apps, where the `target platform` is `Android` or `iOS` while the `execution platform` is `Linux`, `macOS`, or `Windows`. |
-| `aspects` | [sequence](../core/list) of [Aspect](../builtins/Aspect)s; default is `[]`  Aspects that should be applied to the dependency or dependencies specified by this attribute. |
+| `aspects` | [sequence](/versions/8.5.1/rules/lib/core/list) of [Aspect](/versions/8.5.1/rules/lib/builtins/Aspect)s; default is `[]`  Aspects that should be applied to the dependency or dependencies specified by this attribute. |
 
 ## string\_list
 
@@ -286,11 +286,11 @@ Creates a schema for a list-of-strings attribute.
 
 | Parameter | Description |
 | --- | --- |
-| `mandatory` | [bool](../core/bool); default is `False`  If true, the value must be specified explicitly (even if it has a `default`). |
-| `allow_empty` | [bool](../core/bool); default is `True`  True if the attribute can be empty. |
-| `configurable` | [bool](../core/bool); or unbound; default is `unbound`  This argument can only be specified for an attribute of a symbolic macro. If `configurable` is explicitly set to `False`, the symbolic macro attribute is non-configurable - in other words, it cannot take a `select()` value. If the `configurable` is either unbound or explicitly set to `True`, the attribute is configurable and can take a `select()` value. For an attribute of a rule or aspect, `configurable` must be left unbound. Most Starlark rule attributes are always configurable, with the exception of `attr.output()`, `attr.output_list()`, and `attr.license()` rule attributes, which are always non-configurable. |
-| `default` | [sequence](../core/list) of [string](../core/string)s; or NativeComputedDefault; default is `[]`  A default value to use if no value for this attribute is given when instantiating the rule. |
-| `doc` | [string](../core/string); or `None`; default is `None`  A description of the attribute that can be extracted by documentation generating tools. |
+| `mandatory` | [bool](/versions/8.5.1/rules/lib/core/bool); default is `False`  If true, the value must be specified explicitly (even if it has a `default`). |
+| `allow_empty` | [bool](/versions/8.5.1/rules/lib/core/bool); default is `True`  True if the attribute can be empty. |
+| `configurable` | [bool](/versions/8.5.1/rules/lib/core/bool); or unbound; default is `unbound`  This argument can only be specified for an attribute of a symbolic macro. If `configurable` is explicitly set to `False`, the symbolic macro attribute is non-configurable - in other words, it cannot take a `select()` value. If the `configurable` is either unbound or explicitly set to `True`, the attribute is configurable and can take a `select()` value. For an attribute of a rule or aspect, `configurable` must be left unbound. Most Starlark rule attributes are always configurable, with the exception of `attr.output()`, `attr.output_list()`, and `attr.license()` rule attributes, which are always non-configurable. |
+| `default` | [sequence](/versions/8.5.1/rules/lib/core/list) of [string](/versions/8.5.1/rules/lib/core/string)s; or NativeComputedDefault; default is `[]`  A default value to use if no value for this attribute is given when instantiating the rule. |
+| `doc` | [string](/versions/8.5.1/rules/lib/core/string); or `None`; default is `None`  A description of the attribute that can be extracted by documentation generating tools. |
 
 ## string\_list\_dict
 
@@ -304,8 +304,8 @@ Creates a schema for an attribute holding a dictionary, where the keys are strin
 
 | Parameter | Description |
 | --- | --- |
-| `allow_empty` | [bool](../core/bool); default is `True`  True if the attribute can be empty. |
-| `configurable` | [bool](../core/bool); or unbound; default is `unbound`  This argument can only be specified for an attribute of a symbolic macro. If `configurable` is explicitly set to `False`, the symbolic macro attribute is non-configurable - in other words, it cannot take a `select()` value. If the `configurable` is either unbound or explicitly set to `True`, the attribute is configurable and can take a `select()` value. For an attribute of a rule or aspect, `configurable` must be left unbound. Most Starlark rule attributes are always configurable, with the exception of `attr.output()`, `attr.output_list()`, and `attr.license()` rule attributes, which are always non-configurable. |
-| `default` | [dict](../core/dict); default is `{}`  A default value to use if no value for this attribute is given when instantiating the rule. |
-| `doc` | [string](../core/string); or `None`; default is `None`  A description of the attribute that can be extracted by documentation generating tools. |
-| `mandatory` | [bool](../core/bool); default is `False`  If true, the value must be specified explicitly (even if it has a `default`). |
\ No newline at end of file
+| `allow_empty` | [bool](/versions/8.5.1/rules/lib/core/bool); default is `True`  True if the attribute can be empty. |
+| `configurable` | [bool](/versions/8.5.1/rules/lib/core/bool); or unbound; default is `unbound`  This argument can only be specified for an attribute of a symbolic macro. If `configurable` is explicitly set to `False`, the symbolic macro attribute is non-configurable - in other words, it cannot take a `select()` value. If the `configurable` is either unbound or explicitly set to `True`, the attribute is configurable and can take a `select()` value. For an attribute of a rule or aspect, `configurable` must be left unbound. Most Starlark rule attributes are always configurable, with the exception of `attr.output()`, `attr.output_list()`, and `attr.license()` rule attributes, which are always non-configurable. |
+| `default` | [dict](/versions/8.5.1/rules/lib/core/dict); default is `{}`  A default value to use if no value for this attribute is given when instantiating the rule. |
+| `doc` | [string](/versions/8.5.1/rules/lib/core/string); or `None`; default is `None`  A description of the attribute that can be extracted by documentation generating tools. |
+| `mandatory` | [bool](/versions/8.5.1/rules/lib/core/bool); default is `False`  If true, the value must be specified explicitly (even if it has a `default`). |
\ No newline at end of file
diff --git a/versions/8.5.1/rules/lib/toplevel/cc_common.mdx b/versions/8.5.1/rules/lib/toplevel/cc_common.mdx
index 30849a65..13b44f2b 100644
--- a/versions/8.5.1/rules/lib/toplevel/cc_common.mdx
+++ b/versions/8.5.1/rules/lib/toplevel/cc_common.mdx
@@ -42,8 +42,8 @@ Returns True if given action\_config is enabled in the feature configuration.
 
 | Parameter | Description |
 | --- | --- |
-| `feature_configuration` | [FeatureConfiguration](../builtins/FeatureConfiguration); required  Feature configuration to be queried. |
-| `action_name` | [string](../core/string); required  Name of the action\_config. |
+| `feature_configuration` | [FeatureConfiguration](/versions/8.5.1/rules/lib/builtins/FeatureConfiguration); required  Feature configuration to be queried. |
+| `action_name` | [string](/versions/8.5.1/rules/lib/core/string); required  Name of the action\_config. |
 
 ## CcToolchainInfo
 
@@ -65,29 +65,29 @@ Should be used for C++ compilation. Returns tuple of (`CompilationContext`, `CcC
 
 | Parameter | Description |
 | --- | --- |
-| `actions` | [actions](../builtins/actions); required  `actions` object. |
-| `feature_configuration` | [FeatureConfiguration](../builtins/FeatureConfiguration); required  `feature_configuration` to be queried. |
+| `actions` | [actions](/versions/8.5.1/rules/lib/builtins/actions); required  `actions` object. |
+| `feature_configuration` | [FeatureConfiguration](/versions/8.5.1/rules/lib/builtins/FeatureConfiguration); required  `feature_configuration` to be queried. |
 | `cc_toolchain` | Info; required  `CcToolchainInfo` provider to be used. |
-| `srcs` | [sequence](../core/list); default is `[]`  The list of source files to be compiled. |
-| `public_hdrs` | [sequence](../core/list); default is `[]`  List of headers needed for compilation of srcs and may be included by dependent rules transitively. |
-| `private_hdrs` | [sequence](../core/list); default is `[]`  List of headers needed for compilation of srcs and NOT to be included by dependent rules. |
-| `includes` | [sequence](../core/list); or [depset](../builtins/depset); default is `[]`  Search paths for header files referenced both by angle bracket and quotes. Usually passed with -I. Propagated to dependents transitively. |
-| `quote_includes` | [sequence](../core/list); default is `[]`  Search paths for header files referenced by quotes, e.g. #include "foo/bar/header.h". They can be either relative to the exec root or absolute. Usually passed with -iquote. Propagated to dependents transitively. |
-| `system_includes` | [sequence](../core/list); default is `[]`  Search paths for header files referenced by angle brackets, e.g. #include <foo/bar/header.h>. They can be either relative to the exec root or absolute. Usually passed with -isystem. Propagated to dependents transitively. |
-| `framework_includes` | [sequence](../core/list); default is `[]`  Search paths for header files from Apple frameworks. They can be either relative to the exec root or absolute. Usually passed with -F. Propagated to dependents transitively. |
-| `defines` | [sequence](../core/list); default is `[]`  Set of defines needed to compile this target. Each define is a string. Propagated to dependents transitively. |
-| `local_defines` | [sequence](../core/list); default is `[]`  Set of defines needed to compile this target. Each define is a string. Not propagated to dependents transitively. |
-| `include_prefix` | [string](../core/string); default is `''`  The prefix to add to the paths of the headers of this rule. When set, the headers in the hdrs attribute of this rule are accessible at is the value of this attribute prepended to their repository-relative path. The prefix in the strip\_include\_prefix attribute is removed before this prefix is added. |
-| `strip_include_prefix` | [string](../core/string); default is `''`  The prefix to strip from the paths of the headers of this rule. When set, the headers in the hdrs attribute of this rule are accessible at their path with this prefix cut off. If it's a relative path, it's taken as a package-relative one. If it's an absolute one, it's understood as a repository-relative path. The prefix in the include\_prefix attribute is added after this prefix is stripped. |
-| `user_compile_flags` | [sequence](../core/list); default is `[]`  Additional list of compilation options. |
-| `conly_flags` | [sequence](../core/list); default is `[]`  Additional list of compilation options for C compiles. |
-| `cxx_flags` | [sequence](../core/list); default is `[]`  Additional list of compilation options for C++ compiles. |
-| `compilation_contexts` | [sequence](../core/list); default is `[]`  Headers from dependencies used for compilation. |
-| `name` | [string](../core/string); required  This is used for naming the output artifacts of actions created by this method. See also the `main\_output` arg. |
-| `disallow_pic_outputs` | [bool](../core/bool); default is `False`  Whether PIC outputs should be created. |
-| `disallow_nopic_outputs` | [bool](../core/bool); default is `False`  Whether NOPIC outputs should be created. |
-| `additional_inputs` | [sequence](../core/list); default is `[]`  List of additional files needed for compilation of srcs |
-| `module_interfaces` | [sequence](../core/list); default is `unbound`  The list of module interfaces source files to be compiled. Note: this is an experimental feature, only enabled with --experimental\_cpp\_modules |
+| `srcs` | [sequence](/versions/8.5.1/rules/lib/core/list); default is `[]`  The list of source files to be compiled. |
+| `public_hdrs` | [sequence](/versions/8.5.1/rules/lib/core/list); default is `[]`  List of headers needed for compilation of srcs and may be included by dependent rules transitively. |
+| `private_hdrs` | [sequence](/versions/8.5.1/rules/lib/core/list); default is `[]`  List of headers needed for compilation of srcs and NOT to be included by dependent rules. |
+| `includes` | [sequence](/versions/8.5.1/rules/lib/core/list); or [depset](/versions/8.5.1/rules/lib/builtins/depset); default is `[]`  Search paths for header files referenced both by angle bracket and quotes. Usually passed with -I. Propagated to dependents transitively. |
+| `quote_includes` | [sequence](/versions/8.5.1/rules/lib/core/list); default is `[]`  Search paths for header files referenced by quotes, e.g. #include "foo/bar/header.h". They can be either relative to the exec root or absolute. Usually passed with -iquote. Propagated to dependents transitively. |
+| `system_includes` | [sequence](/versions/8.5.1/rules/lib/core/list); default is `[]`  Search paths for header files referenced by angle brackets, e.g. #include <foo/bar/header.h>. They can be either relative to the exec root or absolute. Usually passed with -isystem. Propagated to dependents transitively. |
+| `framework_includes` | [sequence](/versions/8.5.1/rules/lib/core/list); default is `[]`  Search paths for header files from Apple frameworks. They can be either relative to the exec root or absolute. Usually passed with -F. Propagated to dependents transitively. |
+| `defines` | [sequence](/versions/8.5.1/rules/lib/core/list); default is `[]`  Set of defines needed to compile this target. Each define is a string. Propagated to dependents transitively. |
+| `local_defines` | [sequence](/versions/8.5.1/rules/lib/core/list); default is `[]`  Set of defines needed to compile this target. Each define is a string. Not propagated to dependents transitively. |
+| `include_prefix` | [string](/versions/8.5.1/rules/lib/core/string); default is `''`  The prefix to add to the paths of the headers of this rule. When set, the headers in the hdrs attribute of this rule are accessible at is the value of this attribute prepended to their repository-relative path. The prefix in the strip\_include\_prefix attribute is removed before this prefix is added. |
+| `strip_include_prefix` | [string](/versions/8.5.1/rules/lib/core/string); default is `''`  The prefix to strip from the paths of the headers of this rule. When set, the headers in the hdrs attribute of this rule are accessible at their path with this prefix cut off. If it's a relative path, it's taken as a package-relative one. If it's an absolute one, it's understood as a repository-relative path. The prefix in the include\_prefix attribute is added after this prefix is stripped. |
+| `user_compile_flags` | [sequence](/versions/8.5.1/rules/lib/core/list); default is `[]`  Additional list of compilation options. |
+| `conly_flags` | [sequence](/versions/8.5.1/rules/lib/core/list); default is `[]`  Additional list of compilation options for C compiles. |
+| `cxx_flags` | [sequence](/versions/8.5.1/rules/lib/core/list); default is `[]`  Additional list of compilation options for C++ compiles. |
+| `compilation_contexts` | [sequence](/versions/8.5.1/rules/lib/core/list); default is `[]`  Headers from dependencies used for compilation. |
+| `name` | [string](/versions/8.5.1/rules/lib/core/string); required  This is used for naming the output artifacts of actions created by this method. See also the `main\_output` arg. |
+| `disallow_pic_outputs` | [bool](/versions/8.5.1/rules/lib/core/bool); default is `False`  Whether PIC outputs should be created. |
+| `disallow_nopic_outputs` | [bool](/versions/8.5.1/rules/lib/core/bool); default is `False`  Whether NOPIC outputs should be created. |
+| `additional_inputs` | [sequence](/versions/8.5.1/rules/lib/core/list); default is `[]`  List of additional files needed for compilation of srcs |
+| `module_interfaces` | [sequence](/versions/8.5.1/rules/lib/core/list); default is `unbound`  The list of module interfaces source files to be compiled. Note: this is an experimental feature, only enabled with --experimental\_cpp\_modules |
 
 ## configure\_features
 
@@ -101,11 +101,11 @@ Creates a feature\_configuration instance. Requires the cpp configuration fragme
 
 | Parameter | Description |
 | --- | --- |
-| `ctx` | [ctx](../builtins/ctx); or `None`; default is `None`  The rule context. |
+| `ctx` | [ctx](/versions/8.5.1/rules/lib/builtins/ctx); or `None`; default is `None`  The rule context. |
 | `cc_toolchain` | Info; required  cc\_toolchain for which we configure features. |
-| `language` | [string](../core/string); or `None`; default is `None`  The language to configure for: either c++ or objc (default c++) |
-| `requested_features` | [sequence](../core/list); default is `[]`  List of features to be enabled. |
-| `unsupported_features` | [sequence](../core/list); default is `[]`  List of features that are unsupported by the current rule. |
+| `language` | [string](/versions/8.5.1/rules/lib/core/string); or `None`; default is `None`  The language to configure for: either c++ or objc (default c++) |
+| `requested_features` | [sequence](/versions/8.5.1/rules/lib/core/list); default is `[]`  List of features to be enabled. |
+| `unsupported_features` | [sequence](/versions/8.5.1/rules/lib/core/list); default is `[]`  List of features that are unsupported by the current rule. |
 
 ## create\_cc\_toolchain\_config\_info
 
@@ -119,22 +119,22 @@ Creates a `CcToolchainConfigInfo` provider
 
 | Parameter | Description |
 | --- | --- |
-| `ctx` | [ctx](../builtins/ctx); required  The rule context. |
-| `features` | [sequence](../core/list); default is `[]`  Contains all flag specifications for one feature. Arguments:  `name`: The feature's name. It is possible to introduce a feature without a change to Bazel by adding a 'feature' section to the toolchain and adding the corresponding string as feature in the `BUILD` file.  `enabled`: If 'True', this feature is enabled unless a rule type explicitly marks it as unsupported.  `flag_sets`: A FlagSet list. If the given feature is enabled, the flag sets will be applied for the actions are specified for.  `env_sets`: an EnvSet list. If the given feature is enabled, the env sets will be applied for the actions they are specified for.  `requires`: A list of feature sets defining when this feature is supported by the toolchain. The feature is supported if any of the feature sets fully apply, that is, when all features of a feature set are enabled. If `requires` is omitted, the feature is supported independently of which other features are enabled. Use this for example to filter flags depending on the build mode enabled (opt / fastbuild / dbg).  `implies`: A string list of features or action configs that are automatically enabled when this feature is enabled. If any of the implied features or action configs cannot be enabled, this feature will (silently) not be enabled either.  `provides`: A list of names this feature conflicts with. A feature cannot be enabled if:- `provides` contains the name of a different feature or action config that we want to enable.- `provides` contains the same value as a 'provides' in a different feature or action config that we want to enable. Use this in order to ensure that incompatible features cannot be accidentally activated at the same time, leading to hard to diagnose compiler errors. |
-| `action_configs` | [sequence](../core/list); default is `[]`  An action config corresponds to a Bazel action, and allows selection of a tool based on activated features. Action config activation occurs by the same semantics as features: a feature can 'require' or 'imply' an action config in the same way that it would another feature. Arguments:  `action_name`: The name of the Bazel action that this config applies to, e.g. 'c-compile' or 'c-module-compile'.  `enabled`: If 'True', this action is enabled unless a rule type explicitly marks it as unsupported.  `tools`: The tool applied to the action will be the first tool with a feature set that matches the feature configuration. An error will be thrown if no tool matches a provided feature configuration - for that reason, it's a good idea to provide a default tool with an empty feature set.  `flag_sets`: If the given action config is enabled, the flag sets will be applied to the corresponding action.  `implies`: A list of features or action configs that are automatically enabled when this action config is enabled. If any of the implied features or action configs cannot be enabled, this action config will (silently) not be enabled either. |
-| `artifact_name_patterns` | [sequence](../core/list); default is `[]`  The name for an artifact of a given category of input or output artifacts to an action. Arguments:  `category_name`: The category of artifacts that this selection applies to. This field is compared against a list of categories defined in Bazel. Example categories include "linked\_output" or the artifact for this selection. Together with the extension it is used to create an artifact name based on the target name.  `extension`: The extension for creating the artifact for this selection. Together with the prefix it is used to create an artifact name based on the target name. |
-| `cxx_builtin_include_directories` | [sequence](../core/list); default is `[]`  Built-in include directories for C++ compilation. These should be the exact paths used by the compiler, and are generally relative to the exec root.  The paths used by the compiler can be determined by 'gcc -E -xc++ - -v'.  We currently use the C++ paths also for C compilation, which is safe as long as there are no name clashes between C++ and C header files.  Relative paths are resolved relative to the configuration file directory.  If the compiler has --sysroot support, then these paths should use %sysroot% rather than the include path, and specify the sysroot attribute in order to give blaze the information necessary to make the correct replacements. |
-| `toolchain_identifier` | [string](../core/string); required  The unique identifier of the toolchain within the crosstool release. It must be possible to use this as a directory name in a path.  It has to match the following regex: [a-zA-Z\_][\.\- \w]\* |
-| `host_system_name` | [string](../core/string); or `None`; default is `None`  Ignored. |
-| `target_system_name` | [string](../core/string); or `None`; default is `None`  Deprecated. The GNU System Name. The string is exposed to CcToolchainInfo.target\_gnu\_system\_name. |
-| `target_cpu` | [string](../core/string); or `None`; default is `None`  Deprecated: Use cpu based constraints instead. If the string is "k8", `target\_cpu` will be omitted from the filename of raw FDO profile data. |
-| `target_libc` | [string](../core/string); or `None`; default is `None`  Deprecated: Use OS based constraints instead. The libc version string (e.g. "glibc-2.2.2"). If the string is "macosx", platform is assumed to be MacOS. Otherwise, Linux. The string is exposed to CcToolchainInfo.libc. |
-| `compiler` | [string](../core/string); required  The compiler string (e.g. "gcc"). The current toolchain's compiler is exposed to `@bazel\_tools//tools/cpp:compiler (compiler\_flag)` as a flag value. Targets that require compiler-specific flags can use the config\_settings in https://github.com/bazelbuild/rules\_cc/blob/main/cc/compiler/BUILD in select() statements or create custom config\_setting if the existing settings don't suffice. |
-| `abi_version` | [string](../core/string); or `None`; default is `None`  The abi in use, which is a gcc version. E.g.: "gcc-3.4". The string is set to C++ toolchain variable ABI. |
-| `abi_libc_version` | [string](../core/string); or `None`; default is `None`  The glibc version used by the abi we're using. The string is set to C++ toolchain variable ABI\_LIBC\_VERSION. |
-| `tool_paths` | [sequence](../core/list); default is `[]`  Tool locations. Arguments:  `name`: Name of the tool.  `path`: Location of the tool; Can be absolute path (in case of non hermetic toolchain), or path relative to the cc\_toolchain's package. |
-| `make_variables` | [sequence](../core/list); default is `[]`  A make variable that is made accessible to rules. |
-| `builtin_sysroot` | [string](../core/string); or `None`; default is `None`  The built-in sysroot. If this attribute is not present, Bazel does not allow using a different sysroot, i.e. through the --grte\_top option. |
+| `ctx` | [ctx](/versions/8.5.1/rules/lib/builtins/ctx); required  The rule context. |
+| `features` | [sequence](/versions/8.5.1/rules/lib/core/list); default is `[]`  Contains all flag specifications for one feature. Arguments:  `name`: The feature's name. It is possible to introduce a feature without a change to Bazel by adding a 'feature' section to the toolchain and adding the corresponding string as feature in the `BUILD` file.  `enabled`: If 'True', this feature is enabled unless a rule type explicitly marks it as unsupported.  `flag_sets`: A FlagSet list. If the given feature is enabled, the flag sets will be applied for the actions are specified for.  `env_sets`: an EnvSet list. If the given feature is enabled, the env sets will be applied for the actions they are specified for.  `requires`: A list of feature sets defining when this feature is supported by the toolchain. The feature is supported if any of the feature sets fully apply, that is, when all features of a feature set are enabled. If `requires` is omitted, the feature is supported independently of which other features are enabled. Use this for example to filter flags depending on the build mode enabled (opt / fastbuild / dbg).  `implies`: A string list of features or action configs that are automatically enabled when this feature is enabled. If any of the implied features or action configs cannot be enabled, this feature will (silently) not be enabled either.  `provides`: A list of names this feature conflicts with. A feature cannot be enabled if:- `provides` contains the name of a different feature or action config that we want to enable.- `provides` contains the same value as a 'provides' in a different feature or action config that we want to enable. Use this in order to ensure that incompatible features cannot be accidentally activated at the same time, leading to hard to diagnose compiler errors. |
+| `action_configs` | [sequence](/versions/8.5.1/rules/lib/core/list); default is `[]`  An action config corresponds to a Bazel action, and allows selection of a tool based on activated features. Action config activation occurs by the same semantics as features: a feature can 'require' or 'imply' an action config in the same way that it would another feature. Arguments:  `action_name`: The name of the Bazel action that this config applies to, e.g. 'c-compile' or 'c-module-compile'.  `enabled`: If 'True', this action is enabled unless a rule type explicitly marks it as unsupported.  `tools`: The tool applied to the action will be the first tool with a feature set that matches the feature configuration. An error will be thrown if no tool matches a provided feature configuration - for that reason, it's a good idea to provide a default tool with an empty feature set.  `flag_sets`: If the given action config is enabled, the flag sets will be applied to the corresponding action.  `implies`: A list of features or action configs that are automatically enabled when this action config is enabled. If any of the implied features or action configs cannot be enabled, this action config will (silently) not be enabled either. |
+| `artifact_name_patterns` | [sequence](/versions/8.5.1/rules/lib/core/list); default is `[]`  The name for an artifact of a given category of input or output artifacts to an action. Arguments:  `category_name`: The category of artifacts that this selection applies to. This field is compared against a list of categories defined in Bazel. Example categories include "linked\_output" or the artifact for this selection. Together with the extension it is used to create an artifact name based on the target name.  `extension`: The extension for creating the artifact for this selection. Together with the prefix it is used to create an artifact name based on the target name. |
+| `cxx_builtin_include_directories` | [sequence](/versions/8.5.1/rules/lib/core/list); default is `[]`  Built-in include directories for C++ compilation. These should be the exact paths used by the compiler, and are generally relative to the exec root.  The paths used by the compiler can be determined by 'gcc -E -xc++ - -v'.  We currently use the C++ paths also for C compilation, which is safe as long as there are no name clashes between C++ and C header files.  Relative paths are resolved relative to the configuration file directory.  If the compiler has --sysroot support, then these paths should use %sysroot% rather than the include path, and specify the sysroot attribute in order to give blaze the information necessary to make the correct replacements. |
+| `toolchain_identifier` | [string](/versions/8.5.1/rules/lib/core/string); required  The unique identifier of the toolchain within the crosstool release. It must be possible to use this as a directory name in a path.  It has to match the following regex: [a-zA-Z\_][\.\- \w]\* |
+| `host_system_name` | [string](/versions/8.5.1/rules/lib/core/string); or `None`; default is `None`  Ignored. |
+| `target_system_name` | [string](/versions/8.5.1/rules/lib/core/string); or `None`; default is `None`  Deprecated. The GNU System Name. The string is exposed to CcToolchainInfo.target\_gnu\_system\_name. |
+| `target_cpu` | [string](/versions/8.5.1/rules/lib/core/string); or `None`; default is `None`  Deprecated: Use cpu based constraints instead. If the string is "k8", `target\_cpu` will be omitted from the filename of raw FDO profile data. |
+| `target_libc` | [string](/versions/8.5.1/rules/lib/core/string); or `None`; default is `None`  Deprecated: Use OS based constraints instead. The libc version string (e.g. "glibc-2.2.2"). If the string is "macosx", platform is assumed to be MacOS. Otherwise, Linux. The string is exposed to CcToolchainInfo.libc. |
+| `compiler` | [string](/versions/8.5.1/rules/lib/core/string); required  The compiler string (e.g. "gcc"). The current toolchain's compiler is exposed to `@bazel\_tools//tools/cpp:compiler (compiler\_flag)` as a flag value. Targets that require compiler-specific flags can use the config\_settings in https://github.com/bazelbuild/rules\_cc/blob/main/cc/compiler/BUILD in select() statements or create custom config\_setting if the existing settings don't suffice. |
+| `abi_version` | [string](/versions/8.5.1/rules/lib/core/string); or `None`; default is `None`  The abi in use, which is a gcc version. E.g.: "gcc-3.4". The string is set to C++ toolchain variable ABI. |
+| `abi_libc_version` | [string](/versions/8.5.1/rules/lib/core/string); or `None`; default is `None`  The glibc version used by the abi we're using. The string is set to C++ toolchain variable ABI\_LIBC\_VERSION. |
+| `tool_paths` | [sequence](/versions/8.5.1/rules/lib/core/list); default is `[]`  Tool locations. Arguments:  `name`: Name of the tool.  `path`: Location of the tool; Can be absolute path (in case of non hermetic toolchain), or path relative to the cc\_toolchain's package. |
+| `make_variables` | [sequence](/versions/8.5.1/rules/lib/core/list); default is `[]`  A make variable that is made accessible to rules. |
+| `builtin_sysroot` | [string](/versions/8.5.1/rules/lib/core/string); or `None`; default is `None`  The built-in sysroot. If this attribute is not present, Bazel does not allow using a different sysroot, i.e. through the --grte\_top option. |
 
 ## create\_compilation\_context
 
@@ -168,8 +168,8 @@ Create compilation outputs object.
 
 | Parameter | Description |
 | --- | --- |
-| `objects` | [depset](../builtins/depset); or `None`; default is `None`  List of object files. |
-| `pic_objects` | [depset](../builtins/depset); or `None`; default is `None`  List of pic object files. |
+| `objects` | [depset](/versions/8.5.1/rules/lib/builtins/depset); or `None`; default is `None`  List of object files. |
+| `pic_objects` | [depset](/versions/8.5.1/rules/lib/builtins/depset); or `None`; default is `None`  List of pic object files. |
 
 ## create\_compile\_variables
 
@@ -184,21 +184,21 @@ Returns variables used for compilation actions.
 | Parameter | Description |
 | --- | --- |
 | `cc_toolchain` | Info; required  cc\_toolchain for which we are creating build variables. |
-| `feature_configuration` | [FeatureConfiguration](../builtins/FeatureConfiguration); required  Feature configuration to be queried. |
+| `feature_configuration` | [FeatureConfiguration](/versions/8.5.1/rules/lib/builtins/FeatureConfiguration); required  Feature configuration to be queried. |
 | `source_file` | default is `None`  Optional source file for the compilation. Please prefer passing source\_file here over appending it to the end of the command line generated from cc\_common.get\_memory\_inefficient\_command\_line, as then it's in the power of the toolchain author to properly specify and position compiler flags. |
 | `output_file` | default is `None`  Optional output file of the compilation. Please prefer passing output\_file here over appending it to the end of the command line generated from cc\_common.get\_memory\_inefficient\_command\_line, as then it's in the power of the toolchain author to properly specify and position compiler flags. |
-| `user_compile_flags` | [sequence](../core/list) of [string](../core/string)s; or `None`; default is `None`  List of additional compilation flags (copts). |
-| `include_directories` | [depset](../builtins/depset); or `None`; default is `None`  Depset of include directories. |
-| `quote_include_directories` | [depset](../builtins/depset); or `None`; default is `None`  Depset of quote include directories. |
-| `system_include_directories` | [depset](../builtins/depset); or `None`; default is `None`  Depset of system include directories. |
-| `framework_include_directories` | [depset](../builtins/depset); or `None`; default is `None`  Depset of framework include directories. |
-| `preprocessor_defines` | [depset](../builtins/depset); or `None`; default is `None`  Depset of preprocessor defines. |
-| `thinlto_index` | [string](../core/string); or `None`; default is `None`  LTO index file path. |
-| `thinlto_input_bitcode_file` | [string](../core/string); or `None`; default is `None`  Bitcode file that is input to LTO backend. |
-| `thinlto_output_object_file` | [string](../core/string); or `None`; default is `None`  Object file that is output by LTO backend. |
-| `use_pic` | [bool](../core/bool); default is `False`  When true the compilation will generate position independent code. |
-| `add_legacy_cxx_options` | [bool](../core/bool); default is `False`  Unused. |
-| `variables_extension` | [dict](../core/dict); default is `unbound`  A dictionary of additional variables used by compile actions. |
+| `user_compile_flags` | [sequence](/versions/8.5.1/rules/lib/core/list) of [string](/versions/8.5.1/rules/lib/core/string)s; or `None`; default is `None`  List of additional compilation flags (copts). |
+| `include_directories` | [depset](/versions/8.5.1/rules/lib/builtins/depset); or `None`; default is `None`  Depset of include directories. |
+| `quote_include_directories` | [depset](/versions/8.5.1/rules/lib/builtins/depset); or `None`; default is `None`  Depset of quote include directories. |
+| `system_include_directories` | [depset](/versions/8.5.1/rules/lib/builtins/depset); or `None`; default is `None`  Depset of system include directories. |
+| `framework_include_directories` | [depset](/versions/8.5.1/rules/lib/builtins/depset); or `None`; default is `None`  Depset of framework include directories. |
+| `preprocessor_defines` | [depset](/versions/8.5.1/rules/lib/builtins/depset); or `None`; default is `None`  Depset of preprocessor defines. |
+| `thinlto_index` | [string](/versions/8.5.1/rules/lib/core/string); or `None`; default is `None`  LTO index file path. |
+| `thinlto_input_bitcode_file` | [string](/versions/8.5.1/rules/lib/core/string); or `None`; default is `None`  Bitcode file that is input to LTO backend. |
+| `thinlto_output_object_file` | [string](/versions/8.5.1/rules/lib/core/string); or `None`; default is `None`  Object file that is output by LTO backend. |
+| `use_pic` | [bool](/versions/8.5.1/rules/lib/core/bool); default is `False`  When true the compilation will generate position independent code. |
+| `add_legacy_cxx_options` | [bool](/versions/8.5.1/rules/lib/core/bool); default is `False`  Unused. |
+| `variables_extension` | [dict](/versions/8.5.1/rules/lib/core/dict); default is `unbound`  A dictionary of additional variables used by compile actions. |
 
 ## create\_library\_to\_link
 
@@ -215,15 +215,15 @@ Creates `LibraryToLink`
 | `actions` | required  `actions` object. |
 | `feature_configuration` | default is `None`  `feature_configuration` to be queried. |
 | `cc_toolchain` | default is `None`  `CcToolchainInfo` provider to be used. |
-| `static_library` | [File](../builtins/File); or `None`; default is `None`  `File` of static library to be linked. |
-| `pic_static_library` | [File](../builtins/File); or `None`; default is `None`  `File` of pic static library to be linked. |
-| `dynamic_library` | [File](../builtins/File); or `None`; default is `None`  `File` of dynamic library to be linked. Always used for runtime and used for linking if `interface_library` is not passed. |
-| `interface_library` | [File](../builtins/File); or `None`; default is `None`  `File` of interface library to be linked. |
-| `pic_objects` | [sequence](../core/list) of [File](../builtins/File)s; default is `unbound`  Experimental, do not use |
-| `objects` | [sequence](../core/list) of [File](../builtins/File)s; default is `unbound`  Experimental, do not use |
-| `alwayslink` | [bool](../core/bool); default is `False`  Whether to link the static library/objects in the --whole\_archive block. |
-| `dynamic_library_symlink_path` | [string](../core/string); default is `''`  Override the default path of the dynamic library link in the solib directory. Empty string to use the default. |
-| `interface_library_symlink_path` | [string](../core/string); default is `''`  Override the default path of the interface library link in the solib directory. Empty string to use the default. |
+| `static_library` | [File](/versions/8.5.1/rules/lib/builtins/File); or `None`; default is `None`  `File` of static library to be linked. |
+| `pic_static_library` | [File](/versions/8.5.1/rules/lib/builtins/File); or `None`; default is `None`  `File` of pic static library to be linked. |
+| `dynamic_library` | [File](/versions/8.5.1/rules/lib/builtins/File); or `None`; default is `None`  `File` of dynamic library to be linked. Always used for runtime and used for linking if `interface_library` is not passed. |
+| `interface_library` | [File](/versions/8.5.1/rules/lib/builtins/File); or `None`; default is `None`  `File` of interface library to be linked. |
+| `pic_objects` | [sequence](/versions/8.5.1/rules/lib/core/list) of [File](/versions/8.5.1/rules/lib/builtins/File)s; default is `unbound`  Experimental, do not use |
+| `objects` | [sequence](/versions/8.5.1/rules/lib/core/list) of [File](/versions/8.5.1/rules/lib/builtins/File)s; default is `unbound`  Experimental, do not use |
+| `alwayslink` | [bool](/versions/8.5.1/rules/lib/core/bool); default is `False`  Whether to link the static library/objects in the --whole\_archive block. |
+| `dynamic_library_symlink_path` | [string](/versions/8.5.1/rules/lib/core/string); default is `''`  Override the default path of the dynamic library link in the solib directory. Empty string to use the default. |
+| `interface_library_symlink_path` | [string](/versions/8.5.1/rules/lib/core/string); default is `''`  Override the default path of the interface library link in the solib directory. Empty string to use the default. |
 
 ## create\_link\_variables
 
@@ -238,17 +238,17 @@ Returns link variables used for linking actions.
 | Parameter | Description |
 | --- | --- |
 | `cc_toolchain` | Info; required  cc\_toolchain for which we are creating build variables. |
-| `feature_configuration` | [FeatureConfiguration](../builtins/FeatureConfiguration); required  Feature configuration to be queried. |
-| `library_search_directories` | [depset](../builtins/depset); default is `[]`  Depset of directories where linker will look for libraries at link time. |
-| `runtime_library_search_directories` | [depset](../builtins/depset); default is `[]`  Depset of directories where loader will look for libraries at runtime. |
-| `user_link_flags` | [sequence](../core/list); default is `[]`  List of additional link flags (linkopts). |
+| `feature_configuration` | [FeatureConfiguration](/versions/8.5.1/rules/lib/builtins/FeatureConfiguration); required  Feature configuration to be queried. |
+| `library_search_directories` | [depset](/versions/8.5.1/rules/lib/builtins/depset); default is `[]`  Depset of directories where linker will look for libraries at link time. |
+| `runtime_library_search_directories` | [depset](/versions/8.5.1/rules/lib/builtins/depset); default is `[]`  Depset of directories where loader will look for libraries at runtime. |
+| `user_link_flags` | [sequence](/versions/8.5.1/rules/lib/core/list); default is `[]`  List of additional link flags (linkopts). |
 | `output_file` | default is `None`  Optional output file path. |
 | `param_file` | default is `None`  Optional param file path. |
-| `is_using_linker` | [bool](../core/bool); default is `True`  True when using linker, False when archiver. Caller is responsible for keeping this in sync with action name used (is\_using\_linker = True for linking executable or dynamic library, is\_using\_linker = False for archiving static library). |
-| `is_linking_dynamic_library` | [bool](../core/bool); default is `False`  True when creating dynamic library, False when executable or static library. Caller is responsible for keeping this in sync with action name used. This field will be removed once b/65151735 is fixed. |
-| `must_keep_debug` | [bool](../core/bool); default is `True`  When set to False, bazel will expose 'strip\_debug\_symbols' variable, which is usually used to use the linker to strip debug symbols from the output file. |
-| `use_test_only_flags` | [bool](../core/bool); default is `False`  When set to true, 'is\_cc\_test' variable will be set. |
-| `is_static_linking_mode` | [bool](../core/bool); default is `True`  Unused. |
+| `is_using_linker` | [bool](/versions/8.5.1/rules/lib/core/bool); default is `True`  True when using linker, False when archiver. Caller is responsible for keeping this in sync with action name used (is\_using\_linker = True for linking executable or dynamic library, is\_using\_linker = False for archiving static library). |
+| `is_linking_dynamic_library` | [bool](/versions/8.5.1/rules/lib/core/bool); default is `False`  True when creating dynamic library, False when executable or static library. Caller is responsible for keeping this in sync with action name used. This field will be removed once b/65151735 is fixed. |
+| `must_keep_debug` | [bool](/versions/8.5.1/rules/lib/core/bool); default is `True`  When set to False, bazel will expose 'strip\_debug\_symbols' variable, which is usually used to use the linker to strip debug symbols from the output file. |
+| `use_test_only_flags` | [bool](/versions/8.5.1/rules/lib/core/bool); default is `False`  When set to true, 'is\_cc\_test' variable will be set. |
+| `is_static_linking_mode` | [bool](/versions/8.5.1/rules/lib/core/bool); default is `True`  Unused. |
 
 ## create\_linker\_input
 
@@ -262,10 +262,10 @@ Creates a `LinkerInput`.
 
 | Parameter | Description |
 | --- | --- |
-| `owner` | [Label](../builtins/Label); required  The label of the target that produced all files used in this input. |
-| `libraries` | `None`; or [depset](../builtins/depset); default is `None`  List of `LibraryToLink`. |
-| `user_link_flags` | `None`; or [depset](../builtins/depset) of [string](../core/string)s; or [sequence](../core/list) of [string](../core/string)s; default is `None`  User link flags passed as strings. Accepts either [String], [[String]] or depset(String). The latter is discouraged as it's only kept for compatibility purposes, the depset is flattened. If you want to propagate user\_link\_flags via unflattened depsets() wrap them in a LinkerInput so that they are not flattened till the end. |
-| `additional_inputs` | `None`; or [depset](../builtins/depset); default is `None`  For additional inputs to the linking action, e.g.: linking scripts. |
+| `owner` | [Label](/versions/8.5.1/rules/lib/builtins/Label); required  The label of the target that produced all files used in this input. |
+| `libraries` | `None`; or [depset](/versions/8.5.1/rules/lib/builtins/depset); default is `None`  List of `LibraryToLink`. |
+| `user_link_flags` | `None`; or [depset](/versions/8.5.1/rules/lib/builtins/depset) of [string](/versions/8.5.1/rules/lib/core/string)s; or [sequence](/versions/8.5.1/rules/lib/core/list) of [string](/versions/8.5.1/rules/lib/core/string)s; default is `None`  User link flags passed as strings. Accepts either [String], [[String]] or depset(String). The latter is discouraged as it's only kept for compatibility purposes, the depset is flattened. If you want to propagate user\_link\_flags via unflattened depsets() wrap them in a LinkerInput so that they are not flattened till the end. |
+| `additional_inputs` | `None`; or [depset](/versions/8.5.1/rules/lib/builtins/depset); default is `None`  For additional inputs to the linking action, e.g.: linking scripts. |
 
 ## create\_linking\_context
 
@@ -279,10 +279,10 @@ Creates a `LinkingContext`.
 
 | Parameter | Description |
 | --- | --- |
-| `linker_inputs` | `None`; or [depset](../builtins/depset); default is `None`  Depset of `LinkerInput`. |
-| `libraries_to_link` | `None`; or [sequence](../core/list); default is `None`  **Deprecated**. This parameter is deprecated and will be removed soon. Please do not depend on it. It is *disabled* with `--incompatible_require_linker_input_cc_api`. Use this flag to verify your code is compatible with its imminent removal.  List of `LibraryToLink`. |
-| `user_link_flags` | `None`; or [sequence](../core/list); default is `None` |
-| `additional_inputs` | `None`; or [sequence](../core/list); default is `None` |
+| `linker_inputs` | `None`; or [depset](/versions/8.5.1/rules/lib/builtins/depset); default is `None`  Depset of `LinkerInput`. |
+| `libraries_to_link` | `None`; or [sequence](/versions/8.5.1/rules/lib/core/list); default is `None`  **Deprecated**. This parameter is deprecated and will be removed soon. Please do not depend on it. It is *disabled* with `--incompatible_require_linker_input_cc_api`. Use this flag to verify your code is compatible with its imminent removal.  List of `LibraryToLink`. |
+| `user_link_flags` | `None`; or [sequence](/versions/8.5.1/rules/lib/core/list); default is `None` |
+| `additional_inputs` | `None`; or [sequence](/versions/8.5.1/rules/lib/core/list); default is `None` |
 
 ## create\_linking\_context\_from\_compilation\_outputs
 
@@ -296,19 +296,19 @@ Should be used for creating library rules that can propagate information downstr
 
 | Parameter | Description |
 | --- | --- |
-| `actions` | [actions](../builtins/actions); required |
-| `name` | [string](../core/string); required  This is used for naming the output artifacts of actions created by this method. |
-| `feature_configuration` | [FeatureConfiguration](../builtins/FeatureConfiguration); required  `feature_configuration` to be queried. |
+| `actions` | [actions](/versions/8.5.1/rules/lib/builtins/actions); required |
+| `name` | [string](/versions/8.5.1/rules/lib/core/string); required  This is used for naming the output artifacts of actions created by this method. |
+| `feature_configuration` | [FeatureConfiguration](/versions/8.5.1/rules/lib/builtins/FeatureConfiguration); required  `feature_configuration` to be queried. |
 | `cc_toolchain` | Info; required  `CcToolchainInfo` provider to be used. |
-| `language` | [string](../core/string); default is `'c++'`  Only C++ supported for now. Do not use this parameter. |
-| `disallow_static_libraries` | [bool](../core/bool); default is `False`  Whether static libraries should be created. |
-| `disallow_dynamic_library` | [bool](../core/bool); default is `False`  Whether a dynamic library should be created. |
-| `compilation_outputs` | [CcCompilationOutputs](../builtins/CcCompilationOutputs); required  Compilation outputs containing object files to link. |
-| `linking_contexts` | [sequence](../core/list); default is `[]`  Libraries from dependencies. These libraries will be linked into the output artifact of the link() call, be it a binary or a library. |
-| `user_link_flags` | [sequence](../core/list); default is `[]`  Additional list of linking options. |
-| `alwayslink` | [bool](../core/bool); default is `False`  Whether this library should always be linked. |
-| `additional_inputs` | [sequence](../core/list); default is `[]`  For additional inputs to the linking action, e.g.: linking scripts. |
-| `variables_extension` | [dict](../core/dict); default is `unbound`  Additional variables to pass to the toolchain configuration when creating link command line. |
+| `language` | [string](/versions/8.5.1/rules/lib/core/string); default is `'c++'`  Only C++ supported for now. Do not use this parameter. |
+| `disallow_static_libraries` | [bool](/versions/8.5.1/rules/lib/core/bool); default is `False`  Whether static libraries should be created. |
+| `disallow_dynamic_library` | [bool](/versions/8.5.1/rules/lib/core/bool); default is `False`  Whether a dynamic library should be created. |
+| `compilation_outputs` | [CcCompilationOutputs](/versions/8.5.1/rules/lib/builtins/CcCompilationOutputs); required  Compilation outputs containing object files to link. |
+| `linking_contexts` | [sequence](/versions/8.5.1/rules/lib/core/list); default is `[]`  Libraries from dependencies. These libraries will be linked into the output artifact of the link() call, be it a binary or a library. |
+| `user_link_flags` | [sequence](/versions/8.5.1/rules/lib/core/list); default is `[]`  Additional list of linking options. |
+| `alwayslink` | [bool](/versions/8.5.1/rules/lib/core/bool); default is `False`  Whether this library should always be linked. |
+| `additional_inputs` | [sequence](/versions/8.5.1/rules/lib/core/list); default is `[]`  For additional inputs to the linking action, e.g.: linking scripts. |
+| `variables_extension` | [dict](/versions/8.5.1/rules/lib/core/dict); default is `unbound`  Additional variables to pass to the toolchain configuration when creating link command line. |
 
 ## create\_lto\_compilation\_context
 
@@ -322,7 +322,7 @@ Create LTO compilation context
 
 | Parameter | Description |
 | --- | --- |
-| `objects` | [dict](../core/dict); default is {}  map of full object to index object |
+| `objects` | [dict](/versions/8.5.1/rules/lib/core/dict); default is {}  map of full object to index object |
 
 ## do\_not\_use\_tools\_cpp\_compiler\_present
 
@@ -344,8 +344,8 @@ Returns environment variables to be set for given action.
 
 | Parameter | Description |
 | --- | --- |
-| `feature_configuration` | [FeatureConfiguration](../builtins/FeatureConfiguration); required  Feature configuration to be queried. |
-| `action_name` | [string](../core/string); required  Name of the action. Has to be one of the names in @bazel\_tools//tools/build\_defs/cc:action\_names.bzl (https://github.com/bazelbuild/bazel/blob/master/tools/build\_defs/cc/action\_names.bzl) |
+| `feature_configuration` | [FeatureConfiguration](/versions/8.5.1/rules/lib/builtins/FeatureConfiguration); required  Feature configuration to be queried. |
+| `action_name` | [string](/versions/8.5.1/rules/lib/core/string); required  Name of the action. Has to be one of the names in @bazel\_tools//tools/build\_defs/cc:action\_names.bzl (https://github.com/bazelbuild/bazel/blob/master/tools/build\_defs/cc/action\_names.bzl) |
 | `variables` | Variables; required  Build variables to be used for template expansion. |
 
 ## get\_execution\_requirements
@@ -360,8 +360,8 @@ Returns execution requirements for given action.
 
 | Parameter | Description |
 | --- | --- |
-| `feature_configuration` | [FeatureConfiguration](../builtins/FeatureConfiguration); required  Feature configuration to be queried. |
-| `action_name` | [string](../core/string); required  Name of the action. Has to be one of the names in @bazel\_tools//tools/build\_defs/cc:action\_names.bzl (https://github.com/bazelbuild/bazel/blob/master/tools/build\_defs/cc/action\_names.bzl) |
+| `feature_configuration` | [FeatureConfiguration](/versions/8.5.1/rules/lib/builtins/FeatureConfiguration); required  Feature configuration to be queried. |
+| `action_name` | [string](/versions/8.5.1/rules/lib/core/string); required  Name of the action. Has to be one of the names in @bazel\_tools//tools/build\_defs/cc:action\_names.bzl (https://github.com/bazelbuild/bazel/blob/master/tools/build\_defs/cc/action\_names.bzl) |
 
 ## get\_memory\_inefficient\_command\_line
 
@@ -375,8 +375,8 @@ Returns flattened command line flags for given action, using given variables for
 
 | Parameter | Description |
 | --- | --- |
-| `feature_configuration` | [FeatureConfiguration](../builtins/FeatureConfiguration); required  Feature configuration to be queried. |
-| `action_name` | [string](../core/string); required  Name of the action. Has to be one of the names in @bazel\_tools//tools/build\_defs/cc:action\_names.bzl (https://github.com/bazelbuild/bazel/blob/master/tools/build\_defs/cc/action\_names.bzl) |
+| `feature_configuration` | [FeatureConfiguration](/versions/8.5.1/rules/lib/builtins/FeatureConfiguration); required  Feature configuration to be queried. |
+| `action_name` | [string](/versions/8.5.1/rules/lib/core/string); required  Name of the action. Has to be one of the names in @bazel\_tools//tools/build\_defs/cc:action\_names.bzl (https://github.com/bazelbuild/bazel/blob/master/tools/build\_defs/cc/action\_names.bzl) |
 | `variables` | Variables; required  Build variables to be used for template expansions. |
 
 ## get\_tool\_for\_action
@@ -391,8 +391,8 @@ Returns tool path for given action.
 
 | Parameter | Description |
 | --- | --- |
-| `feature_configuration` | [FeatureConfiguration](../builtins/FeatureConfiguration); required  Feature configuration to be queried. |
-| `action_name` | [string](../core/string); required  Name of the action. Has to be one of the names in @bazel\_tools//tools/build\_defs/cc:action\_names.bzl (https://github.com/bazelbuild/bazel/blob/master/tools/build\_defs/cc/action\_names.bzl) |
+| `feature_configuration` | [FeatureConfiguration](/versions/8.5.1/rules/lib/builtins/FeatureConfiguration); required  Feature configuration to be queried. |
+| `action_name` | [string](/versions/8.5.1/rules/lib/core/string); required  Name of the action. Has to be one of the names in @bazel\_tools//tools/build\_defs/cc:action\_names.bzl (https://github.com/bazelbuild/bazel/blob/master/tools/build\_defs/cc/action\_names.bzl) |
 
 ## is\_enabled
 
@@ -406,8 +406,8 @@ Returns True if given feature is enabled in the feature configuration.
 
 | Parameter | Description |
 | --- | --- |
-| `feature_configuration` | [FeatureConfiguration](../builtins/FeatureConfiguration); required  Feature configuration to be queried. |
-| `feature_name` | [string](../core/string); required  Name of the feature. |
+| `feature_configuration` | [FeatureConfiguration](/versions/8.5.1/rules/lib/builtins/FeatureConfiguration); required  Feature configuration to be queried. |
+| `feature_name` | [string](/versions/8.5.1/rules/lib/core/string); required  Name of the feature. |
 
 ## link
 
@@ -421,20 +421,20 @@ Should be used for C++ transitive linking.
 
 | Parameter | Description |
 | --- | --- |
-| `actions` | [actions](../builtins/actions); required  `actions` object. |
-| `name` | [string](../core/string); required  This is used for naming the output artifacts of actions created by this method. |
-| `feature_configuration` | [FeatureConfiguration](../builtins/FeatureConfiguration); required  `feature_configuration` to be queried. |
+| `actions` | [actions](/versions/8.5.1/rules/lib/builtins/actions); required  `actions` object. |
+| `name` | [string](/versions/8.5.1/rules/lib/core/string); required  This is used for naming the output artifacts of actions created by this method. |
+| `feature_configuration` | [FeatureConfiguration](/versions/8.5.1/rules/lib/builtins/FeatureConfiguration); required  `feature_configuration` to be queried. |
 | `cc_toolchain` | Info; required  `CcToolchainInfo` provider to be used. |
-| `language` | [string](../core/string); default is `'c++'`  Only C++ supported for now. Do not use this parameter. |
-| `output_type` | [string](../core/string); default is `'executable'`  Can be either 'executable' or 'dynamic\_library'. |
-| `link_deps_statically` | [bool](../core/bool); default is `True`  True to link dependencies statically, False dynamically. |
-| `compilation_outputs` | [CcCompilationOutputs](../builtins/CcCompilationOutputs); or `None`; default is `None`  Compilation outputs containing object files to link. |
-| `linking_contexts` | [sequence](../core/list); default is `[]`  Linking contexts from dependencies to be linked into the linking context generated by this rule. |
-| `user_link_flags` | [sequence](../core/list); default is `[]`  Additional list of linker options. |
-| `stamp` | [int](../core/int); default is `0`  Whether to include build information in the linked executable, if output\_type is 'executable'. If 1, build information is always included. If 0 (the default build information is always excluded. If -1, uses the default behavior, which may be overridden by the --[no]stamp flag. This should be unset (or set to 0) when generating the executable output for test rules. |
-| `additional_inputs` | [sequence](../core/list); or [depset](../builtins/depset); default is `[]`  For additional inputs to the linking action, e.g.: linking scripts. |
-| `additional_outputs` | [sequence](../core/list); default is `[]`  For additional outputs to the linking action, e.g.: map files. |
-| `variables_extension` | [dict](../core/dict); default is {}  Additional variables to pass to the toolchain configuration when create link command line. |
+| `language` | [string](/versions/8.5.1/rules/lib/core/string); default is `'c++'`  Only C++ supported for now. Do not use this parameter. |
+| `output_type` | [string](/versions/8.5.1/rules/lib/core/string); default is `'executable'`  Can be either 'executable' or 'dynamic\_library'. |
+| `link_deps_statically` | [bool](/versions/8.5.1/rules/lib/core/bool); default is `True`  True to link dependencies statically, False dynamically. |
+| `compilation_outputs` | [CcCompilationOutputs](/versions/8.5.1/rules/lib/builtins/CcCompilationOutputs); or `None`; default is `None`  Compilation outputs containing object files to link. |
+| `linking_contexts` | [sequence](/versions/8.5.1/rules/lib/core/list); default is `[]`  Linking contexts from dependencies to be linked into the linking context generated by this rule. |
+| `user_link_flags` | [sequence](/versions/8.5.1/rules/lib/core/list); default is `[]`  Additional list of linker options. |
+| `stamp` | [int](/versions/8.5.1/rules/lib/core/int); default is `0`  Whether to include build information in the linked executable, if output\_type is 'executable'. If 1, build information is always included. If 0 (the default build information is always excluded. If -1, uses the default behavior, which may be overridden by the --[no]stamp flag. This should be unset (or set to 0) when generating the executable output for test rules. |
+| `additional_inputs` | [sequence](/versions/8.5.1/rules/lib/core/list); or [depset](/versions/8.5.1/rules/lib/builtins/depset); default is `[]`  For additional inputs to the linking action, e.g.: linking scripts. |
+| `additional_outputs` | [sequence](/versions/8.5.1/rules/lib/core/list); default is `[]`  For additional outputs to the linking action, e.g.: map files. |
+| `variables_extension` | [dict](/versions/8.5.1/rules/lib/core/dict); default is {}  Additional variables to pass to the toolchain configuration when create link command line. |
 
 ## merge\_compilation\_contexts
 
@@ -448,7 +448,7 @@ Merges multiple `CompilationContexts`s into one.
 
 | Parameter | Description |
 | --- | --- |
-| `compilation_contexts` | [sequence](../core/list); default is `[]`  List of `CompilationContexts`s to be merged. The headers of each context will be exported by the direct fields in the returned provider. |
+| `compilation_contexts` | [sequence](/versions/8.5.1/rules/lib/core/list); default is `[]`  List of `CompilationContexts`s to be merged. The headers of each context will be exported by the direct fields in the returned provider. |
 
 ## merge\_compilation\_outputs
 
@@ -462,4 +462,4 @@ Merge compilation outputs.
 
 | Parameter | Description |
 | --- | --- |
-| `compilation_outputs` | [sequence](../core/list); default is `[]` |
\ No newline at end of file
+| `compilation_outputs` | [sequence](/versions/8.5.1/rules/lib/core/list); default is `[]` |
\ No newline at end of file
diff --git a/versions/8.5.1/rules/lib/toplevel/config.mdx b/versions/8.5.1/rules/lib/toplevel/config.mdx
index 4b60c243..f601f4d7 100644
--- a/versions/8.5.1/rules/lib/toplevel/config.mdx
+++ b/versions/8.5.1/rules/lib/toplevel/config.mdx
@@ -36,7 +36,7 @@ A bool-typed build setting
 
 | Parameter | Description |
 | --- | --- |
-| `flag` | [bool](../core/bool); default is `False` |
+| `flag` | [bool](/versions/8.5.1/rules/lib/core/bool); default is `False` |
 
 ## exec
 
@@ -50,7 +50,7 @@ Creates an execution transition.
 
 | Parameter | Description |
 | --- | --- |
-| `exec_group` | [string](../core/string); or `None`; default is `None`  The name of the exec group whose execution platform this transition will use. If not provided, this exec transition will use the target's default execution platform. |
+| `exec_group` | [string](/versions/8.5.1/rules/lib/core/string); or `None`; default is `None`  The name of the exec group whose execution platform this transition will use. If not provided, this exec transition will use the target's default execution platform. |
 
 ## int
 
@@ -64,7 +64,7 @@ An integer-typed build setting
 
 | Parameter | Description |
 | --- | --- |
-| `flag` | [bool](../core/bool); default is `False`  Whether or not this build setting is callable on the command line. |
+| `flag` | [bool](/versions/8.5.1/rules/lib/core/bool); default is `False`  Whether or not this build setting is callable on the command line. |
 
 ## none
 
@@ -86,8 +86,8 @@ A string-typed build setting
 
 | Parameter | Description |
 | --- | --- |
-| `flag` | [bool](../core/bool); default is `False`  Whether or not this build setting is callable on the command line. |
-| `allow_multiple` | [bool](../core/bool); default is `False`  Deprecated, use a `string_list` setting with `repeatable = True` instead. If set, this flag is allowed to be set multiple times on the command line. The Value of the flag as accessed in transitions and build setting implementation function will be a list of strings. Insertion order and repeated values are both maintained. This list can be post-processed in the build setting implementation function if different behavior is desired. |
+| `flag` | [bool](/versions/8.5.1/rules/lib/core/bool); default is `False`  Whether or not this build setting is callable on the command line. |
+| `allow_multiple` | [bool](/versions/8.5.1/rules/lib/core/bool); default is `False`  Deprecated, use a `string_list` setting with `repeatable = True` instead. If set, this flag is allowed to be set multiple times on the command line. The Value of the flag as accessed in transitions and build setting implementation function will be a list of strings. Insertion order and repeated values are both maintained. This list can be post-processed in the build setting implementation function if different behavior is desired. |
 
 ## string\_list
 
@@ -101,8 +101,8 @@ A string list-typed build setting. On the command line pass a list using comma-s
 
 | Parameter | Description |
 | --- | --- |
-| `flag` | [bool](../core/bool); default is `False`  Whether or not this build setting is callable on the command line. |
-| `repeatable` | [bool](../core/bool); default is `False`  If set, instead of expecting a comma-separated value, this flag is allowed to be set multiple times on the command line with each individual value treated as a single string to add to the list value. Insertion order and repeated values are both maintained. This list can be post-processed in the build setting implementation function if different behavior is desired. |
+| `flag` | [bool](/versions/8.5.1/rules/lib/core/bool); default is `False`  Whether or not this build setting is callable on the command line. |
+| `repeatable` | [bool](/versions/8.5.1/rules/lib/core/bool); default is `False`  If set, instead of expecting a comma-separated value, this flag is allowed to be set multiple times on the command line with each individual value treated as a single string to add to the list value. Insertion order and repeated values are both maintained. This list can be post-processed in the build setting implementation function if different behavior is desired. |
 
 ## target
 
diff --git a/versions/8.5.1/rules/lib/toplevel/config_common.mdx b/versions/8.5.1/rules/lib/toplevel/config_common.mdx
index 9169b17a..eab8f4d9 100644
--- a/versions/8.5.1/rules/lib/toplevel/config_common.mdx
+++ b/versions/8.5.1/rules/lib/toplevel/config_common.mdx
@@ -29,5 +29,5 @@ Declare a rule's dependency on a toolchain type.
 
 | Parameter | Description |
 | --- | --- |
-| `name` | [string](../core/string); or [Label](../builtins/Label); required  The toolchain type that is required. |
-| `mandatory` | [bool](../core/bool); default is `True`  Whether the toolchain type is mandatory or optional. |
\ No newline at end of file
+| `name` | [string](/versions/8.5.1/rules/lib/core/string); or [Label](/versions/8.5.1/rules/lib/builtins/Label); required  The toolchain type that is required. |
+| `mandatory` | [bool](/versions/8.5.1/rules/lib/core/bool); default is `True`  Whether the toolchain type is mandatory or optional. |
\ No newline at end of file
diff --git a/versions/8.5.1/rules/lib/toplevel/coverage_common.mdx b/versions/8.5.1/rules/lib/toplevel/coverage_common.mdx
index e93e1226..9b377880 100644
--- a/versions/8.5.1/rules/lib/toplevel/coverage_common.mdx
+++ b/versions/8.5.1/rules/lib/toplevel/coverage_common.mdx
@@ -14,14 +14,14 @@ Helper functions to access coverage-related infrastructure.
 InstrumentedFilesInfo coverage_common.instrumented_files_info(ctx, *, source_attributes=[], dependency_attributes=[], extensions=None, metadata_files=[])
 ```
 
-Creates a new [InstrumentedFilesInfo](../providers/InstrumentedFilesInfo) instance. Use this provider to communicate coverage-related attributes of the current build rule.
+Creates a new [InstrumentedFilesInfo](/versions/8.5.1/rules/lib/providers/InstrumentedFilesInfo) instance. Use this provider to communicate coverage-related attributes of the current build rule.
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `ctx` | [ctx](../builtins/ctx); required  The rule context. |
-| `source_attributes` | [sequence](../core/list); default is `[]`  A list of attribute names which contain source files processed by this rule. |
-| `dependency_attributes` | [sequence](../core/list); default is `[]`  A list of attribute names which might provide runtime dependencies (either code dependencies or runfiles). |
-| `extensions` | [sequence](../core/list) of [string](../core/string)s; or `None`; default is `None`  File extensions used to filter files from source\_attributes. For example, 'js'. If not provided (or None), then all files from source\_attributes will be added to instrumented files, if an empty list is provided, then no files from source attributes will be added. |
-| `metadata_files` | [sequence](../core/list) of [File](../builtins/File)s; default is `[]`  Additional files required to generate coverage LCOV files after code execution. e.g. .gcno files for C++. |
\ No newline at end of file
+| `ctx` | [ctx](/versions/8.5.1/rules/lib/builtins/ctx); required  The rule context. |
+| `source_attributes` | [sequence](/versions/8.5.1/rules/lib/core/list); default is `[]`  A list of attribute names which contain source files processed by this rule. |
+| `dependency_attributes` | [sequence](/versions/8.5.1/rules/lib/core/list); default is `[]`  A list of attribute names which might provide runtime dependencies (either code dependencies or runfiles). |
+| `extensions` | [sequence](/versions/8.5.1/rules/lib/core/list) of [string](/versions/8.5.1/rules/lib/core/string)s; or `None`; default is `None`  File extensions used to filter files from source\_attributes. For example, 'js'. If not provided (or None), then all files from source\_attributes will be added to instrumented files, if an empty list is provided, then no files from source attributes will be added. |
+| `metadata_files` | [sequence](/versions/8.5.1/rules/lib/core/list) of [File](/versions/8.5.1/rules/lib/builtins/File)s; default is `[]`  Additional files required to generate coverage LCOV files after code execution. e.g. .gcno files for C++. |
\ No newline at end of file
diff --git a/versions/8.5.1/rules/lib/toplevel/java_common.mdx b/versions/8.5.1/rules/lib/toplevel/java_common.mdx
index d6a896dd..6d3121ea 100644
--- a/versions/8.5.1/rules/lib/toplevel/java_common.mdx
+++ b/versions/8.5.1/rules/lib/toplevel/java_common.mdx
@@ -35,33 +35,33 @@ Compiles Java source files/jars from the implementation of a Starlark rule and r
 
 | Parameter | Description |
 | --- | --- |
-| `ctx` | [ctx](../builtins/ctx); required  The rule context. |
-| `source_jars` | [sequence](../core/list) of [File](../builtins/File)s; default is `[]`  A list of the jars to be compiled. At least one of source\_jars or source\_files should be specified. |
-| `source_files` | [sequence](../core/list) of [File](../builtins/File)s; default is `[]`  A list of the Java source files to be compiled. At least one of source\_jars or source\_files should be specified. |
-| `output` | [File](../builtins/File); required |
-| `output_source_jar` | [File](../builtins/File); or `None`; default is `None`  The output source jar. Defaults to `{output\_jar}-src.jar` if unset. |
-| `javac_opts` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  A list of the desired javac options. |
-| `deps` | [sequence](../core/list) of [struct](../builtins/struct)s; default is `[]`  A list of dependencies. |
-| `runtime_deps` | [sequence](../core/list) of [struct](../builtins/struct)s; default is `[]`  A list of runtime dependencies. |
-| `exports` | [sequence](../core/list) of [struct](../builtins/struct)s; default is `[]`  A list of exports. |
-| `plugins` | [sequence](../core/list) of [struct](../builtins/struct)s; or [sequence](../core/list) of [struct](../builtins/struct)s; default is `[]`  A list of plugins. |
-| `exported_plugins` | [sequence](../core/list) of [struct](../builtins/struct)s; or [sequence](../core/list) of [struct](../builtins/struct)s; default is `[]`  A list of exported plugins. |
-| `native_libraries` | [sequence](../core/list) of [CcInfo](../providers/CcInfo)s; default is `[]`  CC native library dependencies that are needed for this library. |
-| `annotation_processor_additional_inputs` | [sequence](../core/list) of [File](../builtins/File)s; default is `[]`  A list of inputs that the Java compilation action will take in addition to the Java sources for annotation processing. |
-| `annotation_processor_additional_outputs` | [sequence](../core/list) of [File](../builtins/File)s; default is `[]`  A list of outputs that the Java compilation action will output in addition to the class jar from annotation processing. |
-| `strict_deps` | [string](../core/string); default is `'ERROR'`  A string that specifies how to handle strict deps. Possible values: 'OFF', 'ERROR', 'WARN' and 'DEFAULT'. For more details see [`--strict_java_deps flag`](/versions/8.5.1/docs/user-manual#flag--strict_java_deps). By default 'ERROR'. |
+| `ctx` | [ctx](/versions/8.5.1/rules/lib/builtins/ctx); required  The rule context. |
+| `source_jars` | [sequence](/versions/8.5.1/rules/lib/core/list) of [File](/versions/8.5.1/rules/lib/builtins/File)s; default is `[]`  A list of the jars to be compiled. At least one of source\_jars or source\_files should be specified. |
+| `source_files` | [sequence](/versions/8.5.1/rules/lib/core/list) of [File](/versions/8.5.1/rules/lib/builtins/File)s; default is `[]`  A list of the Java source files to be compiled. At least one of source\_jars or source\_files should be specified. |
+| `output` | [File](/versions/8.5.1/rules/lib/builtins/File); required |
+| `output_source_jar` | [File](/versions/8.5.1/rules/lib/builtins/File); or `None`; default is `None`  The output source jar. Defaults to `{output\_jar}-src.jar` if unset. |
+| `javac_opts` | [sequence](/versions/8.5.1/rules/lib/core/list) of [string](/versions/8.5.1/rules/lib/core/string)s; default is `[]`  A list of the desired javac options. |
+| `deps` | [sequence](/versions/8.5.1/rules/lib/core/list) of [struct](/versions/8.5.1/rules/lib/builtins/struct)s; default is `[]`  A list of dependencies. |
+| `runtime_deps` | [sequence](/versions/8.5.1/rules/lib/core/list) of [struct](/versions/8.5.1/rules/lib/builtins/struct)s; default is `[]`  A list of runtime dependencies. |
+| `exports` | [sequence](/versions/8.5.1/rules/lib/core/list) of [struct](/versions/8.5.1/rules/lib/builtins/struct)s; default is `[]`  A list of exports. |
+| `plugins` | [sequence](/versions/8.5.1/rules/lib/core/list) of [struct](/versions/8.5.1/rules/lib/builtins/struct)s; or [sequence](/versions/8.5.1/rules/lib/core/list) of [struct](/versions/8.5.1/rules/lib/builtins/struct)s; default is `[]`  A list of plugins. |
+| `exported_plugins` | [sequence](/versions/8.5.1/rules/lib/core/list) of [struct](/versions/8.5.1/rules/lib/builtins/struct)s; or [sequence](/versions/8.5.1/rules/lib/core/list) of [struct](/versions/8.5.1/rules/lib/builtins/struct)s; default is `[]`  A list of exported plugins. |
+| `native_libraries` | [sequence](/versions/8.5.1/rules/lib/core/list) of [CcInfo](/versions/8.5.1/rules/lib/providers/CcInfo)s; default is `[]`  CC native library dependencies that are needed for this library. |
+| `annotation_processor_additional_inputs` | [sequence](/versions/8.5.1/rules/lib/core/list) of [File](/versions/8.5.1/rules/lib/builtins/File)s; default is `[]`  A list of inputs that the Java compilation action will take in addition to the Java sources for annotation processing. |
+| `annotation_processor_additional_outputs` | [sequence](/versions/8.5.1/rules/lib/core/list) of [File](/versions/8.5.1/rules/lib/builtins/File)s; default is `[]`  A list of outputs that the Java compilation action will output in addition to the class jar from annotation processing. |
+| `strict_deps` | [string](/versions/8.5.1/rules/lib/core/string); default is `'ERROR'`  A string that specifies how to handle strict deps. Possible values: 'OFF', 'ERROR', 'WARN' and 'DEFAULT'. For more details see [`--strict_java_deps flag`](/versions/8.5.1/docs/user-manual#flag--strict_java_deps). By default 'ERROR'. |
 | `java_toolchain` | Info; required  A JavaToolchainInfo to be used for this compilation. Mandatory. |
 | `bootclasspath` | default is `None`  A BootClassPathInfo to be used for this compilation. If present, overrides the bootclasspath associated with the provided java\_toolchain. |
 | `host_javabase` | default is `None`  **Deprecated**. This parameter is deprecated and will be removed soon. Please do not depend on it. It is *disabled* with `--incompatible_java_common_parameters`. Use this flag to verify your code is compatible with its imminent removal.  Deprecated: You can drop this parameter (host\_javabase is provided with java\_toolchain) |
-| `sourcepath` | [sequence](../core/list) of [File](../builtins/File)s; default is `[]` |
-| `resources` | [sequence](../core/list) of [File](../builtins/File)s; default is `[]` |
-| `resource_jars` | [sequence](../core/list) of [File](../builtins/File)s; default is `[]` |
-| `classpath_resources` | [sequence](../core/list) of [File](../builtins/File)s; default is `[]` |
-| `neverlink` | [bool](../core/bool); default is `False` |
-| `enable_annotation_processing` | [bool](../core/bool); default is `True`  Disables annotation processing in this compilation, causing any annotation processors provided in plugins or in exported\_plugins of deps to be ignored. |
-| `enable_compile_jar_action` | [bool](../core/bool); default is `True`  Enables header compilation or ijar creation. If set to False, it forces use of the full class jar in the compilation classpaths of any dependants. Doing so is intended for use by non-library targets such as binaries that do not have dependants. |
-| `add_exports` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  Allow this library to access the given /. |
-| `add_opens` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  Allow this library to reflectively access the given /. |
+| `sourcepath` | [sequence](/versions/8.5.1/rules/lib/core/list) of [File](/versions/8.5.1/rules/lib/builtins/File)s; default is `[]` |
+| `resources` | [sequence](/versions/8.5.1/rules/lib/core/list) of [File](/versions/8.5.1/rules/lib/builtins/File)s; default is `[]` |
+| `resource_jars` | [sequence](/versions/8.5.1/rules/lib/core/list) of [File](/versions/8.5.1/rules/lib/builtins/File)s; default is `[]` |
+| `classpath_resources` | [sequence](/versions/8.5.1/rules/lib/core/list) of [File](/versions/8.5.1/rules/lib/builtins/File)s; default is `[]` |
+| `neverlink` | [bool](/versions/8.5.1/rules/lib/core/bool); default is `False` |
+| `enable_annotation_processing` | [bool](/versions/8.5.1/rules/lib/core/bool); default is `True`  Disables annotation processing in this compilation, causing any annotation processors provided in plugins or in exported\_plugins of deps to be ignored. |
+| `enable_compile_jar_action` | [bool](/versions/8.5.1/rules/lib/core/bool); default is `True`  Enables header compilation or ijar creation. If set to False, it forces use of the full class jar in the compilation classpaths of any dependants. Doing so is intended for use by non-library targets such as binaries that do not have dependants. |
+| `add_exports` | [sequence](/versions/8.5.1/rules/lib/core/list) of [string](/versions/8.5.1/rules/lib/core/string)s; default is `[]`  Allow this library to access the given /. |
+| `add_opens` | [sequence](/versions/8.5.1/rules/lib/core/list) of [string](/versions/8.5.1/rules/lib/core/string)s; default is `[]`  Allow this library to reflectively access the given /. |
 
 ## JavaRuntimeInfo
 
@@ -91,7 +91,7 @@ Merges the given providers into a single JavaInfo.
 
 | Parameter | Description |
 | --- | --- |
-| `providers` | [sequence](../core/list) of [struct](../builtins/struct)s; required  The list of providers to merge. |
+| `providers` | [sequence](/versions/8.5.1/rules/lib/core/list) of [struct](/versions/8.5.1/rules/lib/builtins/struct)s; required  The list of providers to merge. |
 
 ## pack\_sources
 
@@ -109,11 +109,11 @@ Packs sources and source jars into a single source jar file. The return value is
 
 | Parameter | Description |
 | --- | --- |
-| `actions` | [actions](../builtins/actions); required  ctx.actions |
-| `output_jar` | [File](../builtins/File); or `None`; default is `None`  **Deprecated**. This parameter is deprecated and will be removed soon. Please do not depend on it. It is *disabled* with `--incompatible_java_common_parameters`. Use this flag to verify your code is compatible with its imminent removal.  Deprecated: The output jar of the rule. Used to name the resulting source jar. The parameter sets output\_source\_jar parameter to `{output\_jar}-src.jar`.Use output\_source\_jar parameter directly instead. |
-| `output_source_jar` | [File](../builtins/File); or `None`; default is `None` |
-| `sources` | [sequence](../core/list) of [File](../builtins/File)s; default is `[]`  A list of Java source files to be packed into the source jar. |
-| `source_jars` | [sequence](../core/list) of [File](../builtins/File)s; default is `[]`  A list of source jars to be packed into the source jar. |
+| `actions` | [actions](/versions/8.5.1/rules/lib/builtins/actions); required  ctx.actions |
+| `output_jar` | [File](/versions/8.5.1/rules/lib/builtins/File); or `None`; default is `None`  **Deprecated**. This parameter is deprecated and will be removed soon. Please do not depend on it. It is *disabled* with `--incompatible_java_common_parameters`. Use this flag to verify your code is compatible with its imminent removal.  Deprecated: The output jar of the rule. Used to name the resulting source jar. The parameter sets output\_source\_jar parameter to `{output\_jar}-src.jar`.Use output\_source\_jar parameter directly instead. |
+| `output_source_jar` | [File](/versions/8.5.1/rules/lib/builtins/File); or `None`; default is `None` |
+| `sources` | [sequence](/versions/8.5.1/rules/lib/core/list) of [File](/versions/8.5.1/rules/lib/builtins/File)s; default is `[]`  A list of Java source files to be packed into the source jar. |
+| `source_jars` | [sequence](/versions/8.5.1/rules/lib/core/list) of [File](/versions/8.5.1/rules/lib/builtins/File)s; default is `[]`  A list of source jars to be packed into the source jar. |
 | `java_toolchain` | Info; required  A JavaToolchainInfo to used to find the ijar tool. |
 | `host_javabase` | default is `None`  **Deprecated**. This parameter is deprecated and will be removed soon. Please do not depend on it. It is *disabled* with `--incompatible_java_common_parameters`. Use this flag to verify your code is compatible with its imminent removal.  Deprecated: You can drop this parameter (host\_javabase is provided with java\_toolchain) |
 
@@ -129,9 +129,9 @@ Runs ijar on a jar, stripping it of its method bodies. This helps reduce rebuild
 
 | Parameter | Description |
 | --- | --- |
-| `actions` | [actions](../builtins/actions); required |
-| `jar` | [File](../builtins/File); required  The jar to run ijar on. |
-| `target_label` | [Label](../builtins/Label); or `None`; default is `None`  A target label to stamp the jar with. Used for `add_dep` support. Typically, you would pass `ctx.label` to stamp the jar with the current rule's label. |
+| `actions` | [actions](/versions/8.5.1/rules/lib/builtins/actions); required |
+| `jar` | [File](/versions/8.5.1/rules/lib/builtins/File); required  The jar to run ijar on. |
+| `target_label` | [Label](/versions/8.5.1/rules/lib/builtins/Label); or `None`; default is `None`  A target label to stamp the jar with. Used for `add_dep` support. Typically, you would pass `ctx.label` to stamp the jar with the current rule's label. |
 | `java_toolchain` | Info; required  A JavaToolchainInfo to used to find the ijar tool. |
 
 ## stamp\_jar
@@ -146,7 +146,7 @@ Stamps a jar with a target label for `add_dep` support. The return value is typi
 
 | Parameter | Description |
 | --- | --- |
-| `actions` | [actions](../builtins/actions); required  ctx.actions |
-| `jar` | [File](../builtins/File); required  The jar to run stamp\_jar on. |
-| `target_label` | [Label](../builtins/Label); required  A target label to stamp the jar with. Used for `add_dep` support. Typically, you would pass `ctx.label` to stamp the jar with the current rule's label. |
+| `actions` | [actions](/versions/8.5.1/rules/lib/builtins/actions); required  ctx.actions |
+| `jar` | [File](/versions/8.5.1/rules/lib/builtins/File); required  The jar to run stamp\_jar on. |
+| `target_label` | [Label](/versions/8.5.1/rules/lib/builtins/Label); required  A target label to stamp the jar with. Used for `add_dep` support. Typically, you would pass `ctx.label` to stamp the jar with the current rule's label. |
 | `java_toolchain` | Info; required  A JavaToolchainInfo to used to find the stamp\_jar tool. |
\ No newline at end of file
diff --git a/versions/8.5.1/rules/lib/toplevel/native.mdx b/versions/8.5.1/rules/lib/toplevel/native.mdx
index 204fb814..041a5caa 100644
--- a/versions/8.5.1/rules/lib/toplevel/native.mdx
+++ b/versions/8.5.1/rules/lib/toplevel/native.mdx
@@ -46,7 +46,7 @@ If possible, avoid using this function. It makes BUILD files brittle and order-d
 
 | Parameter | Description |
 | --- | --- |
-| `name` | [string](../core/string); required |
+| `name` | [string](/versions/8.5.1/rules/lib/core/string); required |
 
 ## existing\_rules
 
@@ -72,9 +72,9 @@ Specifies a list of files belonging to this package that are exported to other p
 
 | Parameter | Description |
 | --- | --- |
-| `srcs` | [sequence](../core/list) of [string](../core/string)s; required  The list of files to export. |
-| `visibility` | [sequence](../core/list); or `None`; default is `None`  A visibility declaration can to be specified. The files will be visible to the targets specified. If no visibility is specified, the files will be visible to every package. |
-| `licenses` | [sequence](../core/list) of [string](../core/string)s; or `None`; default is `None`  Licenses to be specified. |
+| `srcs` | [sequence](/versions/8.5.1/rules/lib/core/list) of [string](/versions/8.5.1/rules/lib/core/string)s; required  The list of files to export. |
+| `visibility` | [sequence](/versions/8.5.1/rules/lib/core/list); or `None`; default is `None`  A visibility declaration can to be specified. The files will be visible to the targets specified. If no visibility is specified, the files will be visible to every package. |
+| `licenses` | [sequence](/versions/8.5.1/rules/lib/core/list) of [string](/versions/8.5.1/rules/lib/core/string)s; or `None`; default is `None`  Licenses to be specified. |
 
 ## glob
 
@@ -93,9 +93,9 @@ If the `exclude_directories` argument is enabled (set to `1`), files of type dir
 
 | Parameter | Description |
 | --- | --- |
-| `include` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  The list of glob patterns to include. |
-| `exclude` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  The list of glob patterns to exclude. |
-| `exclude_directories` | [int](../core/int); default is `1`  A flag whether to exclude directories or not. |
+| `include` | [sequence](/versions/8.5.1/rules/lib/core/list) of [string](/versions/8.5.1/rules/lib/core/string)s; default is `[]`  The list of glob patterns to include. |
+| `exclude` | [sequence](/versions/8.5.1/rules/lib/core/list) of [string](/versions/8.5.1/rules/lib/core/string)s; default is `[]`  The list of glob patterns to exclude. |
+| `exclude_directories` | [int](/versions/8.5.1/rules/lib/core/int); default is `1`  A flag whether to exclude directories or not. |
 | `allow_empty` | default is `unbound`  Whether we allow glob patterns to match nothing. If `allow\_empty` is False, each individual include pattern must match something and also the final result must be non-empty (after the matches of the `exclude` patterns are excluded). |
 
 ## module\_name
@@ -128,9 +128,9 @@ This function defines a set of packages and assigns a label to the group. The la
 
 | Parameter | Description |
 | --- | --- |
-| `name` | [string](../core/string); required  The unique name for this rule. |
-| `packages` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  A complete enumeration of packages in this group. |
-| `includes` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  Other package groups that are included in this one. |
+| `name` | [string](/versions/8.5.1/rules/lib/core/string); required  The unique name for this rule. |
+| `packages` | [sequence](/versions/8.5.1/rules/lib/core/list) of [string](/versions/8.5.1/rules/lib/core/string)s; default is `[]`  A complete enumeration of packages in this group. |
+| `includes` | [sequence](/versions/8.5.1/rules/lib/core/list) of [string](/versions/8.5.1/rules/lib/core/string)s; default is `[]`  Other package groups that are included in this one. |
 
 ## package\_name
 
@@ -146,19 +146,19 @@ The name of the package being evaluated, without the repository name. For exampl
 Label native.package_relative_label(input)
 ```
 
-Converts the input string into a [Label](../builtins/Label) object, in the context of the package currently being initialized (that is, the `BUILD` file for which the current macro is executing). If the input is already a `Label`, it is returned unchanged.
+Converts the input string into a [Label](/versions/8.5.1/rules/lib/builtins/Label) object, in the context of the package currently being initialized (that is, the `BUILD` file for which the current macro is executing). If the input is already a `Label`, it is returned unchanged.
 
 This function may only be called while evaluating a BUILD file and the macros it directly or indirectly calls; it may not be called in (for instance) a rule implementation function.
 
 The result of this function is the same `Label` value as would be produced by passing the given string to a label-valued attribute of a target declared in the BUILD file.
 
-*Usage note:* The difference between this function and [Label()](../builtins/Label#Label) is that `Label()` uses the context of the package of the `.bzl` file that called it, not the package of the `BUILD` file. Use `Label()` when you need to refer to a fixed target that is hardcoded into the macro, such as a compiler. Use `package_relative_label()` when you need to normalize a label string supplied by the BUILD file to a `Label` object. (There is no way to convert a string to a `Label` in the context of a package other than the BUILD file or the calling .bzl file. For that reason, outer macros should always prefer to pass Label objects to inner macros rather than label strings.)
+*Usage note:* The difference between this function and [Label()](/versions/8.5.1/rules/lib/builtins/Label#Label) is that `Label()` uses the context of the package of the `.bzl` file that called it, not the package of the `BUILD` file. Use `Label()` when you need to refer to a fixed target that is hardcoded into the macro, such as a compiler. Use `package_relative_label()` when you need to normalize a label string supplied by the BUILD file to a `Label` object. (There is no way to convert a string to a `Label` in the context of a package other than the BUILD file or the calling .bzl file. For that reason, outer macros should always prefer to pass Label objects to inner macros rather than label strings.)
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `input` | [string](../core/string); or [Label](../builtins/Label); required  The input label string or Label object. If a Label object is passed, it's returned as is. |
+| `input` | [string](/versions/8.5.1/rules/lib/core/string); or [Label](/versions/8.5.1/rules/lib/builtins/Label); required  The input label string or Label object. If a Label object is passed, it's returned as is. |
 
 ## repo\_name
 
@@ -191,6 +191,6 @@ Returns a new mutable list of every direct subpackage of the current package, re
 
 | Parameter | Description |
 | --- | --- |
-| `include` | [sequence](../core/list) of [string](../core/string)s; required |
-| `exclude` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  The list of glob patterns to exclude from subpackages scan. |
-| `allow_empty` | [bool](../core/bool); default is `False`  Whether we fail if the call returns an empty list. By default empty list indicates potential error in BUILD file where the call to subpackages() is superflous. Setting to true allows this function to succeed in that case. |*
\ No newline at end of file
+| `include` | [sequence](/versions/8.5.1/rules/lib/core/list) of [string](/versions/8.5.1/rules/lib/core/string)s; required |
+| `exclude` | [sequence](/versions/8.5.1/rules/lib/core/list) of [string](/versions/8.5.1/rules/lib/core/string)s; default is `[]`  The list of glob patterns to exclude from subpackages scan. |
+| `allow_empty` | [bool](/versions/8.5.1/rules/lib/core/bool); default is `False`  Whether we fail if the call returns an empty list. By default empty list indicates potential error in BUILD file where the call to subpackages() is superflous. Setting to true allows this function to succeed in that case. |*
\ No newline at end of file
diff --git a/versions/8.5.1/rules/lib/toplevel/platform_common.mdx b/versions/8.5.1/rules/lib/toplevel/platform_common.mdx
index 17edc7c5..f6bfd960 100644
--- a/versions/8.5.1/rules/lib/toplevel/platform_common.mdx
+++ b/versions/8.5.1/rules/lib/toplevel/platform_common.mdx
@@ -18,7 +18,7 @@ Functions for Starlark to interact with the platform APIs.
 Provider platform_common.ConstraintSettingInfo
 ```
 
-The constructor/key for the [ConstraintSettingInfo](../providers/ConstraintSettingInfo) provider.
+The constructor/key for the [ConstraintSettingInfo](/versions/8.5.1/rules/lib/providers/ConstraintSettingInfo) provider.
 *Note: This API is experimental and may change at any time. It is disabled by default, but may be enabled with `--experimental_platforms_api`*
 
 ## ConstraintValueInfo
@@ -27,7 +27,7 @@ The constructor/key for the [ConstraintSettingInfo](../providers/ConstraintSetti
 Provider platform_common.ConstraintValueInfo
 ```
 
-The constructor/key for the [ConstraintValueInfo](../providers/ConstraintValueInfo) provider.
+The constructor/key for the [ConstraintValueInfo](/versions/8.5.1/rules/lib/providers/ConstraintValueInfo) provider.
 *Note: This API is experimental and may change at any time. It is disabled by default, but may be enabled with `--experimental_platforms_api`*
 
 ## PlatformInfo
@@ -36,7 +36,7 @@ The constructor/key for the [ConstraintValueInfo](../providers/ConstraintValueIn
 Provider platform_common.PlatformInfo
 ```
 
-The constructor/key for the [PlatformInfo](../providers/PlatformInfo) provider.
+The constructor/key for the [PlatformInfo](/versions/8.5.1/rules/lib/providers/PlatformInfo) provider.
 *Note: This API is experimental and may change at any time. It is disabled by default, but may be enabled with `--experimental_platforms_api`*
 
 ## TemplateVariableInfo
@@ -45,7 +45,7 @@ The constructor/key for the [PlatformInfo](../providers/PlatformInfo) provider.
 Provider platform_common.TemplateVariableInfo
 ```
 
-The constructor/key for the [TemplateVariableInfo](../providers/TemplateVariableInfo) provider.
+The constructor/key for the [TemplateVariableInfo](/versions/8.5.1/rules/lib/providers/TemplateVariableInfo) provider.
 
 ## ToolchainInfo
 
@@ -53,4 +53,4 @@ The constructor/key for the [TemplateVariableInfo](../providers/TemplateVariable
 Provider platform_common.ToolchainInfo
 ```
 
-The constructor/key for the [ToolchainInfo](../providers/ToolchainInfo) provider.
\ No newline at end of file
+The constructor/key for the [ToolchainInfo](/versions/8.5.1/rules/lib/providers/ToolchainInfo) provider.
\ No newline at end of file
diff --git a/versions/8.5.1/rules/lib/toplevel/testing.mdx b/versions/8.5.1/rules/lib/toplevel/testing.mdx
index 5489113c..804e5ea2 100644
--- a/versions/8.5.1/rules/lib/toplevel/testing.mdx
+++ b/versions/8.5.1/rules/lib/toplevel/testing.mdx
@@ -24,12 +24,12 @@ The number of transitive dependencies of the test are limited. The limit is cont
 
 | Parameter | Description |
 | --- | --- |
-| `name` | [string](../core/string); required  Name of the target. It should be a Starlark identifier, matching pattern '[A-Za-z\_][A-Za-z0-9\_]\*'. |
-| `implementation` | [function](../core/function); required  The Starlark function implementing this analysis test. It must have exactly one parameter: [ctx](../builtins/ctx). The function is called during the analysis phase. It can access the attributes declared by `attrs` and populated via `attr_values`. The implementation function may not register actions. Instead, it must register a pass/fail result via providing [AnalysisTestResultInfo](../providers/AnalysisTestResultInfo). |
-| `attrs` | [dict](../core/dict); default is `{}`  Dictionary declaring the attributes. See the [rule](../globals/bzl#rule) call. Attributes are allowed to use configuration transitions defined using [analysis\_test\_transition](../globals/bzl#analysis_test_transition). |
-| `fragments` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  List of configuration fragments that are available to the implementation of the analysis test. |
-| `toolchains` | [sequence](../core/list); default is `[]`  The set of toolchains the test requires. See the [rule](../globals/bzl#rule) call. |
-| `attr_values` | [dict](../core/dict) of [string](../core/string)s; default is `{}`  Dictionary of attribute values to pass to the implementation. |
+| `name` | [string](/versions/8.5.1/rules/lib/core/string); required  Name of the target. It should be a Starlark identifier, matching pattern '[A-Za-z\_][A-Za-z0-9\_]\*'. |
+| `implementation` | [function](/versions/8.5.1/rules/lib/core/function); required  The Starlark function implementing this analysis test. It must have exactly one parameter: [ctx](/versions/8.5.1/rules/lib/builtins/ctx). The function is called during the analysis phase. It can access the attributes declared by `attrs` and populated via `attr_values`. The implementation function may not register actions. Instead, it must register a pass/fail result via providing [AnalysisTestResultInfo](/versions/8.5.1/rules/lib/providers/AnalysisTestResultInfo). |
+| `attrs` | [dict](/versions/8.5.1/rules/lib/core/dict); default is `{}`  Dictionary declaring the attributes. See the [rule](/versions/8.5.1/rules/lib/globals/bzl#rule) call. Attributes are allowed to use configuration transitions defined using [analysis\_test\_transition](/versions/8.5.1/rules/lib/globals/bzl#analysis_test_transition). |
+| `fragments` | [sequence](/versions/8.5.1/rules/lib/core/list) of [string](/versions/8.5.1/rules/lib/core/string)s; default is `[]`  List of configuration fragments that are available to the implementation of the analysis test. |
+| `toolchains` | [sequence](/versions/8.5.1/rules/lib/core/list); default is `[]`  The set of toolchains the test requires. See the [rule](/versions/8.5.1/rules/lib/globals/bzl#rule) call. |
+| `attr_values` | [dict](/versions/8.5.1/rules/lib/core/dict) of [string](/versions/8.5.1/rules/lib/core/string)s; default is `{}`  Dictionary of attribute values to pass to the implementation. |
 
 ## ExecutionInfo
 
@@ -37,7 +37,7 @@ The number of transitive dependencies of the test are limited. The limit is cont
 ExecutionInfo testing.ExecutionInfo
 ```
 
-[testing.ExecutionInfo](../providers/ExecutionInfo) provider key/constructor
+[testing.ExecutionInfo](/versions/8.5.1/rules/lib/providers/ExecutionInfo) provider key/constructor
 
 ## TestEnvironment
 
@@ -51,5 +51,5 @@ RunEnvironmentInfo testing.TestEnvironment(environment, inherited_environment=[]
 
 | Parameter | Description |
 | --- | --- |
-| `environment` | [dict](../core/dict); required  A map of string keys and values that represent environment variables and their values. These will be made available during the test execution. |
-| `inherited_environment` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  A sequence of names of environment variables. These variables are made available during the test execution with their current value taken from the shell environment. If a variable is contained in both `environment` and `inherited_environment`, the value inherited from the shell environment will take precedence if set. |
\ No newline at end of file
+| `environment` | [dict](/versions/8.5.1/rules/lib/core/dict); required  A map of string keys and values that represent environment variables and their values. These will be made available during the test execution. |
+| `inherited_environment` | [sequence](/versions/8.5.1/rules/lib/core/list) of [string](/versions/8.5.1/rules/lib/core/string)s; default is `[]`  A sequence of names of environment variables. These variables are made available during the test execution with their current value taken from the shell environment. If a variable is contained in both `environment` and `inherited_environment`, the value inherited from the shell environment will take precedence if set. |
\ No newline at end of file
diff --git a/versions/8.5.1/rules/macro-tutorial.mdx b/versions/8.5.1/rules/macro-tutorial.mdx
index a9991e91..c48f637b 100644
--- a/versions/8.5.1/rules/macro-tutorial.mdx
+++ b/versions/8.5.1/rules/macro-tutorial.mdx
@@ -5,7 +5,7 @@ title: 'Creating a Symbolic Macro'
 IMPORTANT: This tutorial is for [*symbolic macros*](/versions/8.5.1/extending/macros) – the new
 macro system introduced in Bazel 8. If you need to support older Bazel versions,
 you will want to write a [legacy macro](/versions/8.5.1/extending/legacy-macros) instead; take
-a look at [Creating a Legacy Macro](../legacy-macro-tutorial).
+a look at [Creating a Legacy Macro](/versions/8.5.1/rules/legacy-macro-tutorial).
 
 Imagine that you need to run a tool as part of your build. For example, you
 may want to generate or preprocess a source file, or compress a binary. In this
diff --git a/versions/8.5.1/rules/performance.mdx b/versions/8.5.1/rules/performance.mdx
index 300dabd1..294234ab 100644
--- a/versions/8.5.1/rules/performance.mdx
+++ b/versions/8.5.1/rules/performance.mdx
@@ -15,7 +15,7 @@ widespread use.
 ## Use depsets {#use-depsets}
 
 Whenever you are rolling up information from rule dependencies you should use
-[depsets](lib/depset). Only use plain lists or dicts to publish information
+[depsets](/versions/8.5.1/rules/lib/builtins/depset). Only use plain lists or dicts to publish information
 local to the current rule.
 
 A depset represents information as a nested graph which enables sharing.
@@ -73,7 +73,7 @@ See the [depset overview](/versions/8.5.1/extending/depsets) page for more infor
 ### Avoid calling `depset.to_list()` {#avoid-depset-to-list}
 
 You can coerce a depset to a flat list using
-[`to_list()`](lib/depset#to_list), but doing so usually results in O(N^2)
+[`to_list()`](/versions/8.5.1/rules/lib/builtins/depset#to_list), but doing so usually results in O(N^2)
 cost. If at all possible, avoid any flattening of depsets except for debugging
 purposes.
 
@@ -115,7 +115,7 @@ x = depset(transitive = [i.deps for i in inputs])
 
 ## Use ctx.actions.args() for command lines {#ctx-actions-args}
 
-When building command lines you should use [ctx.actions.args()](lib/Args).
+When building command lines you should use [ctx.actions.args()](/versions/8.5.1/rules/lib/builtins/Args).
 This defers expansion of any depsets to the execution phase.
 
 Apart from being strictly faster, this will reduce the memory consumption of
@@ -126,11 +126,11 @@ Here are some tricks:
 * Pass depsets and lists directly as arguments, instead of flattening them
 yourself. They will get expanded by `ctx.actions.args()` for you.
 If you need any transformations on the depset contents, look at
-[ctx.actions.args#add](lib/Args#add) to see if anything fits the bill.
+[ctx.actions.args#add](/versions/8.5.1/rules/lib/builtins/Args#add) to see if anything fits the bill.
 
 * Are you passing `File#path` as arguments? No need. Any
-[File](lib/File) is automatically turned into its
-[path](lib/File#path), deferred to expansion time.
+[File](/versions/8.5.1/rules/lib/builtins/File) is automatically turned into its
+[path](/versions/8.5.1/rules/lib/builtins/File#path), deferred to expansion time.
 
 * Avoid constructing strings by concatenating them together.
 The best string argument is a constant as its memory will be shared between
@@ -138,10 +138,10 @@ all instances of your rule.
 
 * If the args are too long for the command line an `ctx.actions.args()` object
 can be conditionally or unconditionally written to a param file using
-[`ctx.actions.args#use_param_file`](lib/Args#use_param_file). This is
+[`ctx.actions.args#use_param_file`](/versions/8.5.1/rules/lib/builtins/Args#use_param_file). This is
 done behind the scenes when the action is executed. If you need to explicitly
 control the params file you can write it manually using
-[`ctx.actions.write`](lib/actions#write).
+[`ctx.actions.write`](/versions/8.5.1/rules/lib/builtins/actions#write).
 
 Example:
 
@@ -176,7 +176,7 @@ def _to_short_path(f):
 
 ## Transitive action inputs should be depsets {#transitive-action-inputs}
 
-When building an action using [ctx.actions.run](lib/actions?#run), do not
+When building an action using [ctx.actions.run](/versions/8.5.1/rules/lib/builtins/actions#run), do not
 forget that the `inputs` field accepts a depset. Use this whenever inputs are
 collected from dependencies transitively.
 
diff --git a/versions/8.5.1/rules/rules-tutorial.mdx b/versions/8.5.1/rules/rules-tutorial.mdx
index c6b7ce4d..a25398b9 100644
--- a/versions/8.5.1/rules/rules-tutorial.mdx
+++ b/versions/8.5.1/rules/rules-tutorial.mdx
@@ -31,9 +31,9 @@ foo_binary = rule(
 )
 ```
 
-When you call the [`rule`](lib/globals#rule) function, you
+When you call the [`rule`](/versions/8.5.1/rules/lib/globals#rule) function, you
 must define a callback function. The logic will go there, but you
-can leave the function empty for now. The [`ctx`](lib/ctx) argument
+can leave the function empty for now. The [`ctx`](/versions/8.5.1/rules/lib/builtins/ctx) argument
 provides information about the target.
 
 You can load the rule and use it from a `BUILD` file.
@@ -86,10 +86,10 @@ foo_binary(name = "bin1")
 foo_binary(name = "bin2")
 ```
 
-[`ctx.label`](lib/ctx#label)
+[`ctx.label`](/versions/8.5.1/rules/lib/builtins/ctx#label)
 corresponds to the label of the target being analyzed. The `ctx` object has
 many useful fields and methods; you can find an exhaustive list in the
-[API reference](lib/ctx).
+[API reference](/versions/8.5.1/rules/lib/builtins/ctx).
 
 Query the code:
 
@@ -145,7 +145,7 @@ bin2
 ```
 
 Whenever you declare a file, you have to tell Bazel how to generate it by
-creating an action. Use [`ctx.actions.write`](lib/actions#write),
+creating an action. Use [`ctx.actions.write`](/versions/8.5.1/rules/lib/builtins/actions#write),
 to create a file with the given content.
 
 ```python
@@ -200,7 +200,7 @@ You have successfully generated a file!
 ## Attributes
 
 To make the rule more useful, add new attributes using
-[the `attr` module](lib/attr) and update the rule definition.
+[the `attr` module](/versions/8.5.1/rules/lib/toplevel/attr) and update the rule definition.
 
 Add a string attribute called `username`:
 
@@ -236,22 +236,22 @@ def _foo_binary_impl(ctx):
 ```
 
 Note that you can make the attribute mandatory or set a default value. Look at
-the documentation of [`attr.string`](lib/attr#string).
-You may also use other types of attributes, such as [boolean](lib/attr#bool)
-or [list of integers](lib/attr#int_list).
+the documentation of [`attr.string`](/versions/8.5.1/rules/lib/toplevel/attr#string).
+You may also use other types of attributes, such as [boolean](/versions/8.5.1/rules/lib/toplevel/attr#bool)
+or [list of integers](/versions/8.5.1/rules/lib/toplevel/attr#int_list).
 
 ## Dependencies
 
-Dependency attributes, such as [`attr.label`](lib/attr#label)
-and [`attr.label_list`](lib/attr#label_list),
+Dependency attributes, such as [`attr.label`](/versions/8.5.1/rules/lib/toplevel/attr#label)
+and [`attr.label_list`](/versions/8.5.1/rules/lib/toplevel/attr#label_list),
 declare a dependency from the target that owns the attribute to the target whose
 label appears in the attribute's value. This kind of attribute forms the basis
 of the target graph.
 
 In the `BUILD` file, the target label appears as a string object, such as
 `//pkg:name`. In the implementation function, the target will be accessible as a
-[`Target`](lib/Target) object. For example, view the files returned
-by the target using [`Target.files`](lib/Target#modules.Target.files).
+[`Target`](/versions/8.5.1/rules/lib/builtins/Target) object. For example, view the files returned
+by the target using [`Target.files`](/versions/8.5.1/rules/lib/builtins/Target#modules.Target.files).
 
 ### Multiple files
 
@@ -294,7 +294,7 @@ implementation function, but this has two problems. First, as the template gets
 bigger, it becomes more memory efficient to put it in a separate file and avoid
 constructing large strings during the analysis phase. Second, using a separate
 file is more convenient for the user. Instead, use
-[`ctx.actions.expand_template`](lib/actions#expand_template),
+[`ctx.actions.expand_template`](/versions/8.5.1/rules/lib/builtins/actions#expand_template),
 which performs substitutions on a template file.
 
 Create a `template` attribute to declare a dependency on the template
diff --git a/versions/8.5.1/rules/testing.mdx b/versions/8.5.1/rules/testing.mdx
index 84bbc3f4..6b54a0fd 100644
--- a/versions/8.5.1/rules/testing.mdx
+++ b/versions/8.5.1/rules/testing.mdx
@@ -234,7 +234,7 @@ def _inspect_actions_test_impl(ctx):
 ```
 
 Note that `analysistest.target_actions(env)` returns a list of
-[`Action`](lib/Action) objects which represent actions registered by the
+[`Action`](/versions/8.5.1/rules/lib/builtins/Action) objects which represent actions registered by the
 target under test.
 
 ### Verifying rule behavior under different flags {#verifying-rule-behavior}
diff --git a/versions/8.5.1/rules/verbs-tutorial.mdx b/versions/8.5.1/rules/verbs-tutorial.mdx
index d10c8b69..c73aa518 100644
--- a/versions/8.5.1/rules/verbs-tutorial.mdx
+++ b/versions/8.5.1/rules/verbs-tutorial.mdx
@@ -49,8 +49,7 @@ This pattern can also be seen in the Angular project. The
 produces two targets. The first is a standard `nodejs_test` target which compares
 some generated output against a "golden" file (that is, a file containing the
 expected output). This can be built and run with a normal `bazel
-test` invocation. In `angular-cli`, you can run [one such
-target](https://github.com/angular/angular-cli/blob/e1269cb520871ee29b1a4eec6e6c0e4a94f0b5fc/etc/api/BUILD)
+test` invocation. In `angular-cli`, you can run [one such target](https://github.com/angular/angular-cli/blob/e1269cb520871ee29b1a4eec6e6c0e4a94f0b5fc/etc/api/BUILD)
 with `bazel test //etc/api:angular_devkit_core_api`.
 
 Over time, this golden file may need to be updated for legitimate reasons.
@@ -159,7 +158,7 @@ an imaginary `bazel publish` command.
 It's not immediately obvious what the implementation of the `_sphinx_publisher`
 rule might look like. Often, actions like this write a _launcher_ shell script.
 This method typically involves using
-[`ctx.actions.expand_template`](lib/actions#expand_template)
+[`ctx.actions.expand_template`](/versions/8.5.1/rules/lib/builtins/actions#expand_template)
 to write a very simple shell script, in this case invoking the publisher binary
 with a path to the output of the primary target. This way, the publisher
 implementation can remain generic, the `_sphinx_site` rule can just produce
diff --git a/versions/8.5.1/run/build.mdx b/versions/8.5.1/run/build.mdx
index ae6772ba..90af109a 100644
--- a/versions/8.5.1/run/build.mdx
+++ b/versions/8.5.1/run/build.mdx
@@ -633,8 +633,7 @@ Note: Hermeticity means that the action only uses its declared input
 files and no other files in the filesystem, and it only produces its declared
 output files. See [Hermeticity](/versions/8.5.1/basics/hermeticity) for more details.
 
-On some platforms such as [Google Kubernetes
-Engine](https://cloud.google.com/kubernetes-engine/) cluster nodes or Debian,
+On some platforms such as [Google Kubernetes Engine](https://cloud.google.com/kubernetes-engine/) cluster nodes or Debian,
 user namespaces are deactivated by default due to security
 concerns. This can be checked by looking at the file
 `/proc/sys/kernel/unprivileged_userns_clone`: if it exists and contains a 0,
diff --git a/versions/8.5.1/start/android-app.mdx b/versions/8.5.1/start/android-app.mdx
index 36dee1df..a1d32858 100644
--- a/versions/8.5.1/start/android-app.mdx
+++ b/versions/8.5.1/start/android-app.mdx
@@ -36,8 +36,7 @@ In this tutorial you learn how to:
 Before you begin the tutorial, install the following software:
 
 * **Bazel.** To install, follow the [installation instructions](/versions/8.5.1/install).
-* **Android Studio.** To install, follow the steps to [download Android
-  Studio](https://developer.android.com/sdk/index.html).
+* **Android Studio.** To install, follow the steps to [download Android Studio](https://developer.android.com/sdk/index.html).
   Execute the setup wizard to download the SDK and configure your environment.
 * (Optional) **Git.** Use `git` to download the Android app project.
 
@@ -52,8 +51,7 @@ This app has a single button that prints a greeting when clicked:
 
 **Figure 1.** Android app button greeting.
 
-Clone the repository with `git` (or [download the ZIP file
-directly](https://github.com/bazelbuild/examples/archive/master.zip)):
+Clone the repository with `git` (or [download the ZIP file directly](https://github.com/bazelbuild/examples/archive/master.zip)):
 
 ```posix-terminal
 git clone https://github.com/bazelbuild/examples
@@ -103,8 +101,7 @@ A [workspace](/versions/8.5.1/concepts/build-ref#workspace) is a directory that
 source files for one or more software projects, and has a `MODULE.bazel` file at
 its root.
 
-The `MODULE.bazel` file may be empty or may contain references to [external
-dependencies](/versions/8.5.1/external/overview) required to build your project.
+The `MODULE.bazel` file may be empty or may contain references to [external dependencies](/versions/8.5.1/external/overview) required to build your project.
 
 First, run the following command to create an empty `MODULE.bazel` file:
 
@@ -147,8 +144,7 @@ environment variable, and automatically detect the highest API level and the
 latest version of build tools installed within that location.
 
 You can set the `ANDROID_HOME` variable to the location of the Android SDK. Find
-the path to the installed SDK using Android Studio's [SDK
-Manager](https://developer.android.com/studio/intro/update#sdk-manager).
+the path to the installed SDK using Android Studio's [SDK Manager](https://developer.android.com/studio/intro/update#sdk-manager).
 Assuming the SDK is installed to default locations, you can use the following
 commands to set the `ANDROID_HOME` variable:
 
@@ -170,16 +166,14 @@ them permanent, run the following commands:
 | Windows (PowerShell)     | `[System.Environment]::SetEnvironmentVariable('ANDROID_HOME', "$env:LOCALAPPDATA\Android\Sdk", [System.EnvironmentVariableTarget]::User)` |
 
 **Optional:** If you want to compile native code into your Android app, you
-also need to download the [Android
-NDK](https://developer.android.com/ndk/downloads/index.html)
+also need to download the [Android NDK](https://developer.android.com/ndk/downloads/index.html)
 and use `rules_android_ndk` by adding the following line to your `MODULE.bazel` file:
 
 ```python
 bazel_dep(name = "rules_android_ndk", version = "0.1.2")
 ```
 
-For more information, read [Using the Android Native Development Kit with
-Bazel](/versions/8.5.1/docs/android-ndk).
+For more information, read [Using the Android Native Development Kit with Bazel](/versions/8.5.1/docs/android-ndk).
 
 It's not necessary to set the API levels to the same value for the SDK and NDK.
 [This page](https://developer.android.com/ndk/guides/stable_apis.html)
@@ -221,8 +215,7 @@ files or other dependencies. Bazel provides two build rules,
 build an Android app.
 
 For this tutorial, you'll first use the
-`android_library` rule to tell Bazel to build an [Android library
-module](http://developer.android.com/tools/projects/index.html#LibraryProjects)
+`android_library` rule to tell Bazel to build an [Android library module](http://developer.android.com/tools/projects/index.html#LibraryProjects)
 from the app source code and resource files. You'll then use the
 `android_binary` rule to tell Bazel how to build the Android application package.
 
@@ -337,11 +330,9 @@ file:
 ### Run the app
 
 You can now deploy the app to a connected Android device or emulator from the
-command line using the [`bazel
-mobile-install`](/versions/8.5.1/docs/user-manual#mobile-install) command. This command uses
+command line using the [`bazel mobile-install`](/versions/8.5.1/docs/user-manual#mobile-install) command. This command uses
 the Android Debug Bridge (`adb`) to communicate with the device. You must set up
-your device to use `adb` following the instructions in [Android Debug
-Bridge](http://developer.android.com/tools/help/adb.html) before deployment. You
+your device to use `adb` following the instructions in [Android Debug Bridge](http://developer.android.com/tools/help/adb.html) before deployment. You
 can also choose to install the app on the Android emulator included in Android
 Studio. Make sure the emulator is running before executing the command below.
 
diff --git a/versions/8.5.1/start/cpp.mdx b/versions/8.5.1/start/cpp.mdx
index 0a0cdd01..ef1920f3 100644
--- a/versions/8.5.1/start/cpp.mdx
+++ b/versions/8.5.1/start/cpp.mdx
@@ -19,8 +19,7 @@ Estimated completion time: 30 minutes.
 ### Prerequisites {#prerequisites}
 
 Start by [installing Bazel](https://bazel.build/versions/8.5.1/install), if you haven't
-already. This tutorial uses Git for source control, so for best results [install
-Git](https://git-scm.com/book/en/v2/Getting-Started-Installing-Git) as well.
+already. This tutorial uses Git for source control, so for best results [install Git](https://git-scm.com/book/en/v2/Getting-Started-Installing-Git) as well.
 
 Next, retrieve the sample project from Bazel's GitHub repository by running the
 following in your command-line tool of choice:
@@ -63,9 +62,7 @@ examples
 ```
 
 There are three sets of files, each set representing a stage in this tutorial.
-In the first stage, you will build a single [target]
-(https://bazel.build/reference/glossary#target) residing in a single [package]
-(https://bazel.build/reference/glossary#package). In the second stage, you will
+In the first stage, you will build a single [target](https://bazel.build/versions/8.5.1/reference/glossary#target) residing in a single [package](https://bazel.build/versions/8.5.1/reference/glossary#package). In the second stage, you will
 build both a binary and a library from a single package. In the third and final
 stage, you will build a project with multiple packages and build it with
 multiple targets.
@@ -86,8 +83,7 @@ It also contains these significant files:
 *   The `MODULE.bazel` file, which identifies the directory and its contents as
     a Bazel workspace and lives at the root of the project's directory
     structure. It's also where you specify your external dependencies.
-*   One or more [`BUILD`
-    files](https://bazel.build/reference/glossary#build-file), which tell Bazel
+*   One or more [`BUILD` files](https://bazel.build/versions/8.5.1/reference/glossary#build-file), which tell Bazel
     how to build different parts of the project. A directory within the
     workspace that contains a `BUILD` file is a
     [package](https://bazel.build/versions/8.5.1/reference/glossary#package). (More on packages
@@ -182,9 +178,7 @@ This results in a printed "`Hello world`" message.
 
 Here's the dependency graph of Stage 1:
 
-![Dependency graph for hello-world displays a single target with a single source
-file.](/versions/8.5.1/docs/images/cpp-tutorial-stage1.png "Dependency graph for hello-world
-displays a single target with a single source file.")
+![Dependency graph for hello-world displays a single target with a single source file.](/versions/8.5.1/docs/images/cpp-tutorial-stage1.png "Dependency graph for hello-world displays a single target with a single source file.")
 
 ### Summary: stage 1 {#summary-stage-1}
 
@@ -231,8 +225,7 @@ cc_binary(
 ```
 
 With this `BUILD` file, Bazel first builds the `hello-greet` library (using
-Bazel's built-in [`cc_library`
-rule](https://bazel.build/reference/be/c-cpp#cc_library)), then the
+Bazel's built-in [`cc_library` rule](https://bazel.build/versions/8.5.1/reference/be/c-cpp#cc_library)), then the
 `hello-world` binary. The `deps` attribute in the `hello-world` target tells
 Bazel that the `hello-greet` library is required to build the `hello-world`
 binary.
@@ -272,10 +265,7 @@ recompiles that file.
 Looking at the dependency graph, you can see that `hello-world` depends on an
 extra input named `hello-greet`:
 
-![Dependency graph for `hello-world` displays dependency changes after
-modification to the file.](/versions/8.5.1/docs/images/cpp-tutorial-stage2.png "Dependency
-graph for `hello-world` displays dependency changes after modification to the
-file.")
+![Dependency graph for `hello-world` displays dependency changes after modification to the file.](/versions/8.5.1/docs/images/cpp-tutorial-stage2.png "Dependency graph for `hello-world` displays dependency changes after modification to the file.")
 
 ### Summary: stage 2 {#summary-stage-2}
 
@@ -343,11 +333,7 @@ in the `lib` package (hence the target label `//lib:hello-time`) - Bazel knows
 this through the `deps` attribute. You can see this reflected in the dependency
 graph:
 
-![Dependency graph for `hello-world` displays how the target in the main package
-depends on the target in the `lib`
-package.](/versions/8.5.1/docs/images/cpp-tutorial-stage3.png "Dependency graph for
-`hello-world` displays how the target in the main package depends on the target
-in the `lib` package.")
+![Dependency graph for `hello-world` displays how the target in the main package depends on the target in the `lib` package.](/versions/8.5.1/docs/images/cpp-tutorial-stage3.png "Dependency graph for `hello-world` displays how the target in the main package depends on the target in the `lib` package.")
 
 For the build to succeed, you make the `//lib:hello-time` target in `lib/BUILD`
 explicitly visible to targets in `main/BUILD` using the visibility attribute.
@@ -395,15 +381,11 @@ Bazel journey.
 You've now completed your first basic build with Bazel, but this is just the
 start. Here are some more resources to continue learning with Bazel:
 
-*   To keep focusing on C++, read about common [C++ build use
-    cases](https://bazel.build/tutorials/cpp-use-cases).
+*   To keep focusing on C++, read about common [C++ build use cases](https://bazel.build/versions/8.5.1/tutorials/cpp-use-cases).
 *   To get started with building other applications with Bazel, see the
-    tutorials for [Java](https://bazel.build/versions/8.5.1/start/java), [Android
-    application](https://bazel.build/start/android-app), or [iOS
-    application](https://bazel.build/start/ios-app).
+    tutorials for [Java](https://bazel.build/versions/8.5.1/start/java), [Android application](https://bazel.build/versions/8.5.1/start/android-app), or [iOS application](https://bazel.build/versions/8.5.1/start/ios-app).
 *   To learn more about working with local and remote repositories, read about
     [external dependencies](https://bazel.build/versions/8.5.1/docs/external).
-*   To learn more about Bazel's other rules, see this [reference
-    guide](https://bazel.build/rules).
+*   To learn more about Bazel's other rules, see this [reference guide](https://bazel.build/versions/8.5.1/rules).
 
 Happy building!
\ No newline at end of file
diff --git a/versions/8.5.1/start/java.mdx b/versions/8.5.1/start/java.mdx
index 7799fd56..26fd02ea 100644
--- a/versions/8.5.1/start/java.mdx
+++ b/versions/8.5.1/start/java.mdx
@@ -241,8 +241,7 @@ recompiles that file.
 Looking at the dependency graph, you can see that `ProjectRunner` depends on the
 same inputs as it did before, but the structure of the build is different:
 
-![Dependency graph of the target 'ProjectRunner' after adding a dependency](
-/docs/images/tutorial_java_02.svg)
+![Dependency graph of the target 'ProjectRunner' after adding a dependency](/versions/8.5.1/docs/images/tutorial_java_02.svg)
 
 You've now built the project with two targets. The `ProjectRunner` target builds
 one source files and depends on one other target (`:greeter`), which builds
@@ -426,7 +425,7 @@ For more details, see:
 *  The [C++ build tutorial](/versions/8.5.1/start/cpp) to get started with building
    C++ projects with Bazel.
 
-*  The [Android application tutorial](/versions/8.5.1/start/android-app ) and
+*  The [Android application tutorial](/versions/8.5.1/start/android-app) and
    [iOS application tutorial](/versions/8.5.1/start/ios-app)) to get started with
    building mobile applications for Android and iOS with Bazel.
 
diff --git a/versions/8.5.1/tutorials/ccp-toolchain-config.mdx b/versions/8.5.1/tutorials/ccp-toolchain-config.mdx
index d5a25f6a..0e6e29fb 100644
--- a/versions/8.5.1/tutorials/ccp-toolchain-config.mdx
+++ b/versions/8.5.1/tutorials/ccp-toolchain-config.mdx
@@ -29,8 +29,7 @@ uses `clang version 16`, which you can install on your system.
 
 Set up your build environment as follows:
 
-1.  If you have not already done so, [download and install Bazel
-    7.0.2](https://bazel.build/install) or later.
+1.  If you have not already done so, [download and install Bazel 7.0.2](https://bazel.build/versions/8.5.1/install) or later.
 
 2.  Add an empty `MODULE.bazel` file at the root folder.
 
@@ -450,8 +449,7 @@ The key takeaways are:
 
 -   You need to specify a matching `platforms` flag in the command line for
     Bazel to resolve to the toolchain for the same constraint values on the
-    platform. The documentation holds more [information about language specific
-    configuration flags](/versions/8.5.1/concepts/platforms).
+    platform. The documentation holds more [information about language specific configuration flags](/versions/8.5.1/concepts/platforms).
 -   You have to let the toolchain know where the tools live. In this tutorial
     there is a simplified version where you access the tools from the system. If
     you are interested in a more self-contained approach, you can read about
@@ -464,5 +462,4 @@ The key takeaways are:
 
 ## Further reading {#further-reading}
 
-For more details, see [C++ toolchain
-configuration](/versions/8.5.1/docs/cc-toolchain-config-reference)
\ No newline at end of file
+For more details, see [C++ toolchain configuration](/versions/8.5.1/docs/cc-toolchain-config-reference)
\ No newline at end of file
diff --git a/versions/8.6.0/about/roadmap.mdx b/versions/8.6.0/about/roadmap.mdx
index eca79ea8..ab827814 100644
--- a/versions/8.6.0/about/roadmap.mdx
+++ b/versions/8.6.0/about/roadmap.mdx
@@ -13,8 +13,7 @@ projects.
 
 ## Bazel 8.0 Release
 
-We plan to bring Bazel 8.0 [long term support
-(LTS)](https://bazel.build/versions/8.6.0/release/versioning) to you in late 2024.
+We plan to bring Bazel 8.0 [long term support (LTS)](https://bazel.build/versions/8.6.0/release/versioning) to you in late 2024.
 The following features are planned to be implemented.
 
 ### Bzlmod: external dependency management system
@@ -29,8 +28,7 @@ support will be removed. Starting with Bazel 7.1, you can set
 `--noenable_workspace` to opt into the new behavior.
 
 Bazel 8.0 will contain a number of enhancements to
-[Bazel's external dependency management]
-(https://docs.google.com/document/d/1moQfNcEIttsk6vYanNKIy3ZuK53hQUFq1b1r0rmsYVg/edit#heading=h.lgyp7ubwxmjc)
+[Bazel's external dependency management](https://docs.google.com/document/d/1moQfNcEIttsk6vYanNKIy3ZuK53hQUFq1b1r0rmsYVg/edit#heading=h.lgyp7ubwxmjc)
 functionality, including:
 
 *   The new flag `--enable_workspace` can be set to `false` to completely
diff --git a/versions/8.6.0/basics/dependencies.mdx b/versions/8.6.0/basics/dependencies.mdx
index f8468dc5..f5c12ee0 100644
--- a/versions/8.6.0/basics/dependencies.mdx
+++ b/versions/8.6.0/basics/dependencies.mdx
@@ -65,8 +65,7 @@ targets, we’ve made some strides in mitigating the downside by investing in
 tooling to automatically manage `BUILD` files to avoid burdening developers.
 
 Some of these tools, such as `buildifier` and `buildozer`, are available with
-Bazel in the [`buildtools`
-directory](https://github.com/bazelbuild/buildtools).
+Bazel in the [`buildtools` directory](https://github.com/bazelbuild/buildtools).
 
 ## Minimizing Module Visibility
 
@@ -106,8 +105,7 @@ transitive dependencies (Figure 1). Suppose target A depends on target B, which
 depends on a common library target C. Should target A be able to use classes
 defined in target C?
 
-[![Transitive
-dependencies](/versions/8.6.0/images/transitive-dependencies.png)](/versions/8.6.0/images/transitive-dependencies.png)
+[![Transitive dependencies](/versions/8.6.0/images/transitive-dependencies.png)](/versions/8.6.0/images/transitive-dependencies.png)
 
 **Figure 1**. Transitive dependencies
 
@@ -141,9 +139,7 @@ dependencies and adding them to a `BUILD` files without any developer
 intervention. But even without such tools, we’ve found the trade-off to be well
 worth it as the codebase scales: explicitly adding a dependency to `BUILD` file
 is a one-time cost, but dealing with implicit transitive dependencies can cause
-ongoing problems as long as the build target exists. Bazel [enforces strict
-transitive
-dependencies](https://blog.bazel.build/2017/06/28/sjd-unused_deps.html)
+ongoing problems as long as the build target exists. Bazel [enforces strict transitive dependencies](https://blog.bazel.build/2017/06/28/sjd-unused_deps.html)
 on Java code by default.
 
 ### External dependencies
@@ -192,8 +188,7 @@ so in theory there’s no reason that different versions of the same external
 dependency couldn’t both be declared in the build system under different names.
 That way, each target could choose which version of the dependency it wanted to
 use. This causes a lot of problems in practice, so Google enforces a strict
-[One-Version
-Rule](https://opensource.google/docs/thirdparty/oneversion/) for
+[One-Version Rule](https://opensource.google/docs/thirdparty/oneversion/) for
 all third-party dependencies in our codebase.
 
 The biggest problem with allowing multiple versions is the diamond dependency
@@ -232,8 +227,7 @@ Bazel did not use to automatically download transitive dependencies. It used to
 employ a `WORKSPACE` file that required all transitive dependencies to be
 listed, which led to a lot of pain when managing external dependencies. Bazel
 has since added support for automatic transitive external dependency management
-in the form of the `MODULE.bazel` file. See [external dependency
-overview](/versions/8.6.0/external/overview) for more details.
+in the form of the `MODULE.bazel` file. See [external dependency overview](/versions/8.6.0/external/overview) for more details.
 
 Yet again, the choice here is one between convenience and scalability. Small
 projects might prefer not having to worry about managing transitive dependencies
diff --git a/versions/8.6.0/community/images/Bitrise.png b/versions/8.6.0/community/images/Bitrise.png
new file mode 100644
index 00000000..07f85f1e
Binary files /dev/null and b/versions/8.6.0/community/images/Bitrise.png differ
diff --git a/versions/8.6.0/community/images/Gradle.png b/versions/8.6.0/community/images/Gradle.png
new file mode 100644
index 00000000..1e5f5eb0
Binary files /dev/null and b/versions/8.6.0/community/images/Gradle.png differ
diff --git a/versions/8.6.0/community/images/Linkedin-Logo.png b/versions/8.6.0/community/images/Linkedin-Logo.png
new file mode 100644
index 00000000..9dd8715c
Binary files /dev/null and b/versions/8.6.0/community/images/Linkedin-Logo.png differ
diff --git a/versions/8.6.0/community/images/Lucid_Software-logo.svg b/versions/8.6.0/community/images/Lucid_Software-logo.svg
new file mode 100644
index 00000000..6c8591e0
--- /dev/null
+++ b/versions/8.6.0/community/images/Lucid_Software-logo.svg
@@ -0,0 +1,16 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/versions/8.6.0/community/images/acqio_logo.svg b/versions/8.6.0/community/images/acqio_logo.svg
new file mode 100644
index 00000000..8fa11bcd
--- /dev/null
+++ b/versions/8.6.0/community/images/acqio_logo.svg
@@ -0,0 +1,60 @@
+
+
+
+
+
+	
+		
+			
+				
+					
+					
+					
+					
+					
+				
+				
+					
+						
+							
+								
+							
+						
+					
+				
+				
+					
+						
+							
+								
+							
+						
+					
+				
+			
+		
+	
+
+
diff --git a/versions/8.6.0/community/images/aspect-logo-2.png b/versions/8.6.0/community/images/aspect-logo-2.png
new file mode 100644
index 00000000..dfebc4cb
Binary files /dev/null and b/versions/8.6.0/community/images/aspect-logo-2.png differ
diff --git a/versions/8.6.0/community/images/bitrise-logo.png b/versions/8.6.0/community/images/bitrise-logo.png
new file mode 100644
index 00000000..27037ce6
Binary files /dev/null and b/versions/8.6.0/community/images/bitrise-logo.png differ
diff --git a/versions/8.6.0/community/images/buildbuddy-logo.svg b/versions/8.6.0/community/images/buildbuddy-logo.svg
new file mode 100644
index 00000000..bdb72dc6
--- /dev/null
+++ b/versions/8.6.0/community/images/buildbuddy-logo.svg
@@ -0,0 +1,11 @@
+
+
+
+
+
+
+
+
+
+
+
diff --git a/versions/8.6.0/community/images/buildkite.svg b/versions/8.6.0/community/images/buildkite.svg
new file mode 100644
index 00000000..209a4ab1
--- /dev/null
+++ b/versions/8.6.0/community/images/buildkite.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/8.6.0/community/images/codethink-logo.svg b/versions/8.6.0/community/images/codethink-logo.svg
new file mode 100644
index 00000000..406005d8
--- /dev/null
+++ b/versions/8.6.0/community/images/codethink-logo.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/8.6.0/community/images/develocity.png b/versions/8.6.0/community/images/develocity.png
new file mode 100644
index 00000000..eb3eb65a
Binary files /dev/null and b/versions/8.6.0/community/images/develocity.png differ
diff --git a/versions/8.6.0/community/images/dropbox.png b/versions/8.6.0/community/images/dropbox.png
new file mode 100644
index 00000000..125476a6
Binary files /dev/null and b/versions/8.6.0/community/images/dropbox.png differ
diff --git a/versions/8.6.0/community/images/engflow-logo.svg b/versions/8.6.0/community/images/engflow-logo.svg
new file mode 100644
index 00000000..e5f0c343
--- /dev/null
+++ b/versions/8.6.0/community/images/engflow-logo.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/8.6.0/community/images/epam-logo.png b/versions/8.6.0/community/images/epam-logo.png
new file mode 100644
index 00000000..e6a5674c
Binary files /dev/null and b/versions/8.6.0/community/images/epam-logo.png differ
diff --git a/versions/8.6.0/community/images/flare-logo.png b/versions/8.6.0/community/images/flare-logo.png
new file mode 100644
index 00000000..84cb0e5b
Binary files /dev/null and b/versions/8.6.0/community/images/flare-logo.png differ
diff --git a/versions/8.6.0/community/images/hermetiq-logo.png b/versions/8.6.0/community/images/hermetiq-logo.png
new file mode 100644
index 00000000..90765d96
Binary files /dev/null and b/versions/8.6.0/community/images/hermetiq-logo.png differ
diff --git a/versions/8.6.0/community/images/jetbrains.svg b/versions/8.6.0/community/images/jetbrains.svg
new file mode 100644
index 00000000..cb3a2a0e
--- /dev/null
+++ b/versions/8.6.0/community/images/jetbrains.svg
@@ -0,0 +1,13 @@
+
+  
+    
+      
+      
+      
+    
+  
+  
+  
+  
+  
+
diff --git a/versions/8.6.0/community/images/liulishuo.png b/versions/8.6.0/community/images/liulishuo.png
new file mode 100644
index 00000000..a6758e5c
Binary files /dev/null and b/versions/8.6.0/community/images/liulishuo.png differ
diff --git a/versions/8.6.0/community/images/nativelink.svg b/versions/8.6.0/community/images/nativelink.svg
new file mode 100644
index 00000000..148fcdce
--- /dev/null
+++ b/versions/8.6.0/community/images/nativelink.svg
@@ -0,0 +1,1123 @@
+
+
+  
+    
+    
+      
+      
+    
+    
+      
+      
+    
+    
+    
+      
+      
+    
+    
+      
+      
+      
+      
+      
+      
+      
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+      
+      
+    
+    
+    
+    
+      
+      
+    
+    
+    
+    
+      
+      
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+      
+      
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+      
+      
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+      
+      
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+      
+      
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+      
+      
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+      
+      
+    
+  
+  
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+  
+  
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+  
+
diff --git a/versions/8.6.0/community/images/oasis-logo.png b/versions/8.6.0/community/images/oasis-logo.png
new file mode 100644
index 00000000..846a9cd5
Binary files /dev/null and b/versions/8.6.0/community/images/oasis-logo.png differ
diff --git a/versions/8.6.0/community/images/sumglobal-logo.png b/versions/8.6.0/community/images/sumglobal-logo.png
new file mode 100644
index 00000000..6736328d
Binary files /dev/null and b/versions/8.6.0/community/images/sumglobal-logo.png differ
diff --git a/versions/8.6.0/community/images/trunk-logo-dark.svg b/versions/8.6.0/community/images/trunk-logo-dark.svg
new file mode 100644
index 00000000..f25940af
--- /dev/null
+++ b/versions/8.6.0/community/images/trunk-logo-dark.svg
@@ -0,0 +1,22 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/versions/8.6.0/community/images/tweag-logo.png b/versions/8.6.0/community/images/tweag-logo.png
new file mode 100644
index 00000000..20210ed7
Binary files /dev/null and b/versions/8.6.0/community/images/tweag-logo.png differ
diff --git a/versions/8.6.0/community/images/typedb.png b/versions/8.6.0/community/images/typedb.png
new file mode 100644
index 00000000..48ce1056
Binary files /dev/null and b/versions/8.6.0/community/images/typedb.png differ
diff --git a/versions/8.6.0/community/images/virtuslab.svg b/versions/8.6.0/community/images/virtuslab.svg
new file mode 100644
index 00000000..6fba0316
--- /dev/null
+++ b/versions/8.6.0/community/images/virtuslab.svg
@@ -0,0 +1,20 @@
+
+
+  
+    
+  
+  
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+  
+
diff --git a/versions/8.6.0/community/roadmaps-configurability.mdx b/versions/8.6.0/community/roadmaps-configurability.mdx
index 9f44bdce..9b59928b 100644
--- a/versions/8.6.0/community/roadmaps-configurability.mdx
+++ b/versions/8.6.0/community/roadmaps-configurability.mdx
@@ -24,8 +24,7 @@ title: 'Bazel Configurability 2021 Roadmap'
 * Builds scale well, particularly w.r.t graph size and action caching.
 
 We also support
-[`cquery`](https://bazel.build/versions/8.6.0/query/cquery), [`Starlark
-configuration`](https://bazel.build/versions/8.6.0/extending/config),
+[`cquery`](https://bazel.build/versions/8.6.0/query/cquery), [`Starlark configuration`](https://bazel.build/versions/8.6.0/extending/config),
 and
 [`select()`](https://bazel.build/versions/8.6.0/docs/configurable-attributes).
 
@@ -39,15 +38,13 @@ interest of accurate expectations.
 ### Platforms
 
 

-Q3 2021**Android rules use the new [platforms
-API](https://bazel.build/versions/8.6.0/concepts/platforms)**
+Q3 2021**Android rules use the new [platforms API](https://bazel.build/versions/8.6.0/concepts/platforms)**
 IN PROGRESS ([#11749](https://github.com/bazelbuild/bazel/issues/11749))
 
 * This is our main priority for the beginning of 2021.
 
 

-Q3 2021**Builds support [multiple execution
-platforms](https://docs.google.com/document/d/1U9HzdDmtRnm244CaRM6JV-q2408mbNODAMewcGjnnbM/)**
+Q3 2021**Builds support [multiple execution platforms](https://docs.google.com/document/d/1U9HzdDmtRnm244CaRM6JV-q2408mbNODAMewcGjnnbM/)**
 IN PROGRESS ([#11748](https://github.com/bazelbuild/bazel/issues/11748))
 
 

diff --git a/versions/8.6.0/community/sig.mdx b/versions/8.6.0/community/sig.mdx
index a0750f8c..1665204d 100644
--- a/versions/8.6.0/community/sig.mdx
+++ b/versions/8.6.0/community/sig.mdx
@@ -3,8 +3,7 @@ title: 'Bazel Special Interest Groups'
 ---
 
 Bazel hosts Special Interest Groups (SIGs) to focus collaboration on particular
-areas and to support communication and coordination between [Bazel owners,
-maintainers, and contributors](/versions/8.6.0/contribute/policy). This policy
+areas and to support communication and coordination between [Bazel owners, maintainers, and contributors](/versions/8.6.0/contribute/policy). This policy
 applies to [`bazelbuild`](http://github.com/bazelbuild).
 
 SIGs do their work in public. The ideal scope for a SIG covers a well-defined
diff --git a/versions/8.6.0/community/users.mdx b/versions/8.6.0/community/users.mdx
index c8477097..fa45a7f5 100644
--- a/versions/8.6.0/community/users.mdx
+++ b/versions/8.6.0/community/users.mdx
@@ -304,11 +304,9 @@ safety systems_.
 Pigweed is an open-source solution for sustained, robust, and rapid embedded
 product development for large teams. Pigweed has shipped in millions of
 devices, including Google's suite of Pixel devices, Nest thermostats,
-[satellites](https://www.spinlaunch.com/), and [autonomous aerial
-drones](https://www.flyzipline.com/).
+[satellites](https://www.spinlaunch.com/), and [autonomous aerial drones](https://www.flyzipline.com/).
 
-Pigweed [uses Bazel as its primary build
-system](https://pigweed.dev/seed/0111-build-systems.html). The [Bazel for
+Pigweed [uses Bazel as its primary build system](https://pigweed.dev/seed/0111-build-systems.html). The [Bazel for
 Embedded][pw-bazel-great] blog post discusses why we think it's a great build
 system for embedded projects!
 
diff --git a/versions/8.6.0/concepts/build-ref.mdx b/versions/8.6.0/concepts/build-ref.mdx
index 128daa84..07f25559 100644
--- a/versions/8.6.0/concepts/build-ref.mdx
+++ b/versions/8.6.0/concepts/build-ref.mdx
@@ -17,8 +17,7 @@ its root; such a boundary marker file could be `MODULE.bazel`, `REPO.bazel`, or
 in legacy contexts, `WORKSPACE` or `WORKSPACE.bazel`.
 
 The repo in which the current Bazel command is being run is called the _main
-repo_. Other, (external) repos are defined by _repo rules_; see [external
-dependencies overview](/versions/8.6.0/external/overview) for more information.
+repo_. Other, (external) repos are defined by _repo rules_; see [external dependencies overview](/versions/8.6.0/external/overview) for more information.
 
 ## Workspace
 
@@ -95,5 +94,4 @@ have three properties: the list of packages they contain, their name, and other
 package groups they include. The only allowed ways to refer to them are from the
 `visibility` attribute of rules or from the `default_visibility` attribute of
 the `package` function; they do not generate or consume files. For more
-information, refer to the [`package_group`
-documentation](/versions/8.6.0/reference/be/functions#package_group).
+information, refer to the [`package_group` documentation](/versions/8.6.0/reference/be/functions#package_group).
diff --git a/versions/8.6.0/concepts/labels.mdx b/versions/8.6.0/concepts/labels.mdx
index d9d7b320..baf3b322 100644
--- a/versions/8.6.0/concepts/labels.mdx
+++ b/versions/8.6.0/concepts/labels.mdx
@@ -10,8 +10,7 @@ form looks like:
 ```
 
 The first part of the label is the repository name, `@@myrepo`. The double-`@`
-syntax signifies that this is a [*canonical* repo
-name](/versions/8.6.0/external/overview#canonical-repo-name), which is unique within
+syntax signifies that this is a [*canonical* repo name](/versions/8.6.0/external/overview#canonical-repo-name), which is unique within
 the workspace. Labels with canonical repo names unambiguously identify a target
 no matter which context they appear in.
 
diff --git a/versions/8.6.0/concepts/platforms.mdx b/versions/8.6.0/concepts/platforms.mdx
index d5dff662..5b417e96 100644
--- a/versions/8.6.0/concepts/platforms.mdx
+++ b/versions/8.6.0/concepts/platforms.mdx
@@ -77,8 +77,7 @@ To test your Android project with platforms, see
 for support.
 
 You can still use platform APIs with Apple builds (for example, when building
-with a mixture of Apple rules and pure C++) with [platform
-mappings](#platform-mappings).
+with a mixture of Apple rules and pure C++) with [platform mappings](#platform-mappings).
 
 ### Other languages
 
@@ -241,8 +240,7 @@ sets `--cpu`, `--crossstool_top`, or other legacy flags, rules that read
 
 When migrating your project to platforms, you must either convert changes like
 `return { "//command_line_option:cpu": "arm" }` to `return {
-"//command_line_option:platforms": "//:my_arm_platform" }` or use [platform
-mappings](#platform-mappings) to support both styles during migration.
+"//command_line_option:platforms": "//:my_arm_platform" }` or use [platform mappings](#platform-mappings) to support both styles during migration.
 window.
 
 ## Migrating your rule set
@@ -361,10 +359,8 @@ attributes declare a language's tools (like `compiler =
 this information to rules that need to build with these tools.
 
 Toolchains declare the `constraint_value`s of machines they can
-[target][target_compatible_with Attribute]
-(`target_compatible_with = ["@platforms//os:linux"]`) and machines their tools can
-[run on][exec_compatible_with Attribute]
-(`exec_compatible_with = ["@platforms//os:mac"]`).
+[target][target_compatible_with Attribute](`target_compatible_with = ["@platforms//os:linux"]`) and machines their tools can
+[run on][exec_compatible_with Attribute](`exec_compatible_with = ["@platforms//os:mac"]`).
 
 When building `$ bazel build //:myproject --platforms=//:myplatform`, Bazel
 automatically selects a toolchain that can run on the build machine and
diff --git a/versions/8.6.0/configure/attributes.mdx b/versions/8.6.0/configure/attributes.mdx
index 3d7793f0..b9fde83c 100644
--- a/versions/8.6.0/configure/attributes.mdx
+++ b/versions/8.6.0/configure/attributes.mdx
@@ -2,8 +2,7 @@
 title: 'Configurable Build Attributes'
 ---
 
-**_Configurable attributes_**, commonly known as [`select()`](
-/reference/be/functions#select), is a Bazel feature that lets users toggle the values
+**_Configurable attributes_**, commonly known as [`select()`](/versions/8.6.0/reference/be/functions#select), is a Bazel feature that lets users toggle the values
 of build rule attributes at the command line.
 
 This can be used, for example, for a multiplatform library that automatically
@@ -407,8 +406,7 @@ sh_library(
 )
 ```
 
-If you need a `select` to match when multiple conditions match, consider [AND
-chaining](#and-chaining).
+If you need a `select` to match when multiple conditions match, consider [AND chaining](#and-chaining).
 
 ## OR chaining
 
diff --git a/versions/8.6.0/configure/integrate-cpp.mdx b/versions/8.6.0/configure/integrate-cpp.mdx
index e623e085..2b4a6a71 100644
--- a/versions/8.6.0/configure/integrate-cpp.mdx
+++ b/versions/8.6.0/configure/integrate-cpp.mdx
@@ -33,8 +33,7 @@ This is because when writing our own actions, they must behave
 consistently with the C++ toolchain - for example, passing C++ command line
 flags to a tool that invokes the C++ compiler behind the scenes.
 
-C++ rules use a special way of constructing command lines based on [feature
-configuration](/versions/8.6.0/docs/cc-toolchain-config-reference). To construct a command line,
+C++ rules use a special way of constructing command lines based on [feature configuration](/versions/8.6.0/docs/cc-toolchain-config-reference). To construct a command line,
 you need the following:
 
 * `features` and `action_configs` - these come from the `CcToolchainConfigInfo`
diff --git a/versions/8.6.0/configure/windows.mdx b/versions/8.6.0/configure/windows.mdx
index 8de464a8..2658dc77 100644
--- a/versions/8.6.0/configure/windows.mdx
+++ b/versions/8.6.0/configure/windows.mdx
@@ -166,8 +166,7 @@ To build C++ targets with MSVC, you need:
         set BAZEL_VC=C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC
         ```
 
-*   The [Windows
-    SDK](https://developer.microsoft.com/en-us/windows/downloads/windows-10-sdk).
+*   The [Windows SDK](https://developer.microsoft.com/en-us/windows/downloads/windows-10-sdk).
 
     The Windows SDK contains header files and libraries you need when building
     Windows applications, including Bazel itself. By default, the latest Windows SDK installed will
@@ -186,8 +185,7 @@ To build C++ targets with MSVC, you need:
 
 If everything is set up, you can build a C++ target now!
 
-Try building a target from one of our [sample
-projects](https://github.com/bazelbuild/bazel/tree/master/examples):
+Try building a target from one of our [sample projects](https://github.com/bazelbuild/bazel/tree/master/examples):
 
 
 
 
-To build and use Dynamically Linked Libraries (DLL files), see [this
-example](https://github.com/bazelbuild/bazel/tree/master/examples/windows/dll).
+To build and use Dynamically Linked Libraries (DLL files), see [this example](https://github.com/bazelbuild/bazel/tree/master/examples/windows/dll).
 
 **Command Line Length Limit**: To prevent the
 [Windows command line length limit issue](https://github.com/bazelbuild/bazel/issues/5163),
@@ -292,8 +289,7 @@ On Windows, Bazel builds two output files for `java_binary` rules:
 *   a `.jar` file
 *   a `.exe` file that can set up the environment for the JVM and run the binary
 
-Try building a target from one of our [sample
-projects](https://github.com/bazelbuild/bazel/tree/master/examples):
+Try building a target from one of our [sample projects](https://github.com/bazelbuild/bazel/tree/master/examples):
 
 
   bazel build //examples/java-native/src/main/java/com/example/ myproject :hello-world
@@ -315,8 +311,7 @@ On Windows, Bazel builds two output files for `py_binary` rules:
 You can either run the executable file (it has a `.exe` extension) or you can run
 Python with the self-extracting zip file as the argument.
 
-Try building a target from one of our [sample
-projects](https://github.com/bazelbuild/bazel/tree/master/examples):
+Try building a target from one of our [sample projects](https://github.com/bazelbuild/bazel/tree/master/examples):
 
 
   
 
 If you are interested in details about how Bazel builds Python targets on
-Windows, check out this [design
-doc](https://github.com/bazelbuild/bazel-website/blob/master/designs/_posts/2016-09-05-build-python-on-windows.md).
+Windows, check out this [design doc](https://github.com/bazelbuild/bazel-website/blob/master/designs/_posts/2016-09-05-build-python-on-windows.md).
diff --git a/versions/8.6.0/contribute/breaking-changes.mdx b/versions/8.6.0/contribute/breaking-changes.mdx
index 1aca423c..cc97559d 100644
--- a/versions/8.6.0/contribute/breaking-changes.mdx
+++ b/versions/8.6.0/contribute/breaking-changes.mdx
@@ -67,7 +67,7 @@ should contain the URL of the GitHub issue. As the flag name starts with
 ```
 
 In the commit description, add a brief summary of the flag.
-Also add [`RELNOTES:`](release-notes.md) in the following form:
+Also add [`RELNOTES:`](/versions/8.6.0/contribute/release-notes) in the following form:
 `RELNOTES: --incompatible_name_of_flag has been added. See #xyz for details`
 
 The commit should also update the relevant documentation, so that there is no
diff --git a/versions/8.6.0/contribute/codebase.mdx b/versions/8.6.0/contribute/codebase.mdx
index 7e53f654..1ca571eb 100644
--- a/versions/8.6.0/contribute/codebase.mdx
+++ b/versions/8.6.0/contribute/codebase.mdx
@@ -227,8 +227,7 @@ repository", the others are called "external repositories".
 A repository is marked by a repo boundary file (`MODULE.bazel`, `REPO.bazel`, or
 in legacy contexts, `WORKSPACE` or `WORKSPACE.bazel`) in its root directory. The
 main repo is the source tree where you're invoking Bazel from. External repos
-are defined in various ways; see [external dependencies
-overview](/versions/8.6.0/external/overview) for more information.
+are defined in various ways; see [external dependencies overview](/versions/8.6.0/external/overview) for more information.
 
 Code of external repositories is symlinked or downloaded under
 `$OUTPUT_BASE/external`.
diff --git a/versions/8.6.0/contribute/design-documents.mdx b/versions/8.6.0/contribute/design-documents.mdx
index 49f8687a..dd0d1199 100644
--- a/versions/8.6.0/contribute/design-documents.mdx
+++ b/versions/8.6.0/contribute/design-documents.mdx
@@ -25,7 +25,7 @@ Here are some examples of significant changes:
 When you write a design document, you can coordinate with other Bazel developers
 and seek guidance from Bazel's core team. For example, when a proposal adds,
 removes, or modifies any function or object available in BUILD, MODULE.bazel, or
-bzl files, add the [Starlark team](maintainers-guide.md) as reviewers.
+bzl files, add the [Starlark team](/versions/8.6.0/contribute/maintainers-guide) as reviewers.
 Design documents are reviewed before submission because:
 
 *   Bazel is a very complex system; seemingly innocuous local changes can have
@@ -137,8 +137,7 @@ A lead reviewer should be a domain expert who is:
 *   Objective and capable of providing constructive feedback
 *   Available for the entire review period to lead the process
 
-Consider checking the contacts for various [team
-labels](/versions/8.6.0/contribute/maintainers-guide#team-labels).
+Consider checking the contacts for various [team labels](/versions/8.6.0/contribute/maintainers-guide#team-labels).
 
 ## Markdown vs Google Docs
 
@@ -168,12 +167,10 @@ Markdown for posterity.
 
 ### Using Google Docs
 
-For consistency, use the [Bazel design doc template](
-https://docs.google.com/document/d/1cE5zrjrR40RXNg64XtRFewSv6FrLV6slGkkqxBumS1w/edit).
+For consistency, use the [Bazel design doc template](https://docs.google.com/document/d/1cE5zrjrR40RXNg64XtRFewSv6FrLV6slGkkqxBumS1w/edit).
 It includes the necessary header and creates visual
 consistency with other Bazel related documents. To do that, click on **File** >
-**Make a copy** or click this link to [make a copy of the design doc
-template](https://docs.google.com/document/d/1cE5zrjrR40RXNg64XtRFewSv6FrLV6slGkkqxBumS1w/copy).
+**Make a copy** or click this link to [make a copy of the design doc template](https://docs.google.com/document/d/1cE5zrjrR40RXNg64XtRFewSv6FrLV6slGkkqxBumS1w/copy).
 
 To make your document readable to the world, click on
 **Share** > **Advanced** > **Change…**, and
diff --git a/versions/8.6.0/contribute/images/structured-concurrency-3d.svg b/versions/8.6.0/contribute/images/structured-concurrency-3d.svg
new file mode 100644
index 00000000..accbb42a
--- /dev/null
+++ b/versions/8.6.0/contribute/images/structured-concurrency-3d.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/8.6.0/contribute/images/structured-concurrency.svg b/versions/8.6.0/contribute/images/structured-concurrency.svg
new file mode 100644
index 00000000..0258d9a9
--- /dev/null
+++ b/versions/8.6.0/contribute/images/structured-concurrency.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/8.6.0/contribute/images/suspend-resume.svg b/versions/8.6.0/contribute/images/suspend-resume.svg
new file mode 100644
index 00000000..7de1218f
--- /dev/null
+++ b/versions/8.6.0/contribute/images/suspend-resume.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/8.6.0/contribute/images/unstructured-concurrency.svg b/versions/8.6.0/contribute/images/unstructured-concurrency.svg
new file mode 100644
index 00000000..0951639a
--- /dev/null
+++ b/versions/8.6.0/contribute/images/unstructured-concurrency.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/8.6.0/contribute/index.mdx b/versions/8.6.0/contribute/index.mdx
index ddb05621..45c2b05c 100644
--- a/versions/8.6.0/contribute/index.mdx
+++ b/versions/8.6.0/contribute/index.mdx
@@ -10,8 +10,7 @@ As you use Bazel, you may find things that can be improved.
 You can help by [reporting issues](http://github.com/bazelbuild/bazel/issues)
 when:
 
-   - Bazel crashes or you encounter a bug that can [only be resolved using `bazel
-     clean`](/versions/8.6.0/run/build#correct-incremental-rebuilds).
+   - Bazel crashes or you encounter a bug that can [only be resolved using `bazel clean`](/versions/8.6.0/run/build#correct-incremental-rebuilds).
    - The documentation is incomplete or unclear. You can also report issues
      from the page you are viewing by using the "Create issue"
      link at the top right corner of the page.
@@ -21,11 +20,9 @@ when:
 
 You can engage with the Bazel community by:
 
-   - Answering questions [on Stack Overflow](
-     https://stackoverflow.com/questions/tagged/bazel).
+   - Answering questions [on Stack Overflow](https://stackoverflow.com/questions/tagged/bazel).
    - Helping other users [on Slack](https://slack.bazel.build).
-   - Improving documentation or [contributing examples](
-     https://github.com/bazelbuild/examples).
+   - Improving documentation or [contributing examples](https://github.com/bazelbuild/examples).
    - Sharing your experience or your tips, for example, on a blog or social media.
 
 ## Contribute code
@@ -40,8 +37,7 @@ You can contribute to the Bazel ecosystem by:
    - Contributing to Bazel-related tools, for example, migration tools.
    - Improving Bazel integration with other IDEs and tools.
 
-Before making a change, [create a GitHub
-issue](http://github.com/bazelbuild/bazel/issues)
+Before making a change, [create a GitHub issue](http://github.com/bazelbuild/bazel/issues)
 or email [bazel-discuss@](mailto:bazel-discuss@googlegroups.com).
 
 The most helpful contributions fix bugs or add features (as opposed
diff --git a/versions/8.6.0/contribute/maintainers-guide.mdx b/versions/8.6.0/contribute/maintainers-guide.mdx
index 88ddab31..067262e8 100644
--- a/versions/8.6.0/contribute/maintainers-guide.mdx
+++ b/versions/8.6.0/contribute/maintainers-guide.mdx
@@ -4,8 +4,7 @@ title: 'Guide for Bazel Maintainers'
 
 This is a guide for the maintainers of the Bazel open source project.
 
-If you are looking to contribute to Bazel, please read [Contributing to
-Bazel](/versions/8.6.0/contribute) instead.
+If you are looking to contribute to Bazel, please read [Contributing to Bazel](/versions/8.6.0/contribute) instead.
 
 The objectives of this page are to:
 
@@ -37,8 +36,7 @@ repository.
 
 1. A user creates an issue by choosing one of the
 [issue templates](https://github.com/bazelbuild/bazel/issues/new/choose)
-   and it enters the pool of [unreviewed open
-   issues](https://github.com/bazelbuild/bazel/issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aopen+-label%3Auntriaged+-label%3Ap2+-label%3Ap1+-label%3Ap3+-label%3Ap4+-label%3Ateam-Starlark+-label%3Ateam-Rules-CPP+-label%3Ateam-Rules-Java+-label%3Ateam-XProduct+-label%3Ateam-Android+-label%3Ateam-Apple+-label%3Ateam-Configurability++-label%3Ateam-Performance+-label%3Ateam-Rules-Server+-label%3Ateam-Core+-label%3Ateam-Rules-Python+-label%3Ateam-Remote-Exec+-label%3Ateam-Local-Exec+-label%3Ateam-Bazel).
+   and it enters the pool of [unreviewed open issues](https://github.com/bazelbuild/bazel/issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aopen+-label%3Auntriaged+-label%3Ap2+-label%3Ap1+-label%3Ap3+-label%3Ap4+-label%3Ateam-Starlark+-label%3Ateam-Rules-CPP+-label%3Ateam-Rules-Java+-label%3Ateam-XProduct+-label%3Ateam-Android+-label%3Ateam-Apple+-label%3Ateam-Configurability++-label%3Ateam-Performance+-label%3Ateam-Rules-Server+-label%3Ateam-Core+-label%3Ateam-Rules-Python+-label%3Ateam-Remote-Exec+-label%3Ateam-Local-Exec+-label%3Ateam-Bazel).
 1. A member on the Developer Experience (DevEx) subteam rotation reviews the
    issue.
    1. If the issue is **not a bug** or a **feature request**, the DevEx member
@@ -58,21 +56,18 @@ repository.
 1. After reviewing the issue, the DevEx member decides if the issue requires
    immediate attention. If it does, they will assign the **P0**
    [priority](#priority) label and an owner from the list of team leads.
-1. The DevEx member assigns the `untriaged` label and exactly one [team
-   label](#team-labels) for routing.
+1. The DevEx member assigns the `untriaged` label and exactly one [team label](#team-labels) for routing.
 1. The DevEx member also assigns exactly one `type:` label, such as `type: bug`
    or `type: feature request`, according to the type of the issue.
 1. For platform-specific issues, the DevEx member assigns one `platform:` label,
    such as `platform:apple` for Mac-specific issues.
 1. If the issue is low priority and can be worked on by a new community
    contributor, the DevEx member assigns the `good first issue` label.
-At this stage, the issue enters the pool of [untriaged open
-issues](https://github.com/bazelbuild/bazel/issues?q=is%3Aissue+is%3Aopen+label%3Auntriaged).
+At this stage, the issue enters the pool of [untriaged open issues](https://github.com/bazelbuild/bazel/issues?q=is%3Aissue+is%3Aopen+label%3Auntriaged).
 
 Each Bazel subteam will triage all issues under labels they own, preferably on a
 weekly basis. The subteam will review and evaluate the issue and provide a
-resolution, if possible. If you are an owner of a team label, see [this section
-](#label-own) for more information.
+resolution, if possible. If you are an owner of a team label, see [this section](#label-own) for more information.
 
 When an issue is resolved, it can be closed.
 
@@ -111,8 +106,7 @@ preferably on a weekly basis.
      issue is either P0 or P1 we assume that is actively worked on.
 1. Remove the `untriaged` label.
 
-Note that you need to be in the [bazelbuild
-organization](https://github.com/bazelbuild) to be able to add or remove labels.
+Note that you need to be in the [bazelbuild organization](https://github.com/bazelbuild) to be able to add or remove labels.
 
 ### Pull Requests
 
@@ -138,8 +132,7 @@ issues.
   unusable, or a downed service that severely impacts development of the Bazel
   project. This includes regressions introduced in a new release that blocks a
   significant number of users, or an incompatible breaking change that was not
-  compliant to the [Breaking
-  Change](https://docs.google.com/document/d/1q5GGRxKrF_mnwtaPKI487P8OdDRh2nN7jX6U-FXnHL0/edit?pli=1#heading=h.ceof6vpkb3ik)
+  compliant to the [Breaking Change](https://docs.google.com/document/d/1q5GGRxKrF_mnwtaPKI487P8OdDRh2nN7jX6U-FXnHL0/edit?pli=1#heading=h.ceof6vpkb3ik)
   policy. No practical workaround exists.
 * [**P1**](https://github.com/bazelbuild/bazel/labels/P1) - Critical defect or
   feature which should be addressed in the next release, or a serious issue that
diff --git a/versions/8.6.0/contribute/naming.mdx b/versions/8.6.0/contribute/naming.mdx
index 33fe009a..f658ea83 100644
--- a/versions/8.6.0/contribute/naming.mdx
+++ b/versions/8.6.0/contribute/naming.mdx
@@ -4,8 +4,7 @@ title: 'Naming a Bazel related project'
 
 First, thank you for contributing to the Bazel ecosystem! Please reach out to
 the Bazel community on the
-[bazel-discuss mailing list](https://groups.google.com/forum/#!forum/bazel-discuss
-) to share your project and its suggested name.
+[bazel-discuss mailing list](https://groups.google.com/forum/#!forum/bazel-discuss) to share your project and its suggested name.
 
 If you are building a Bazel related tool or sharing your Skylark rules,
 we recommend following these guidelines for the name of your project:
diff --git a/versions/8.6.0/contribute/patch-acceptance.mdx b/versions/8.6.0/contribute/patch-acceptance.mdx
index 5cc10911..7055d86a 100644
--- a/versions/8.6.0/contribute/patch-acceptance.mdx
+++ b/versions/8.6.0/contribute/patch-acceptance.mdx
@@ -11,29 +11,24 @@ code base.
    need a corresponding issue for tracking.
 1. If you're proposing significant changes, write a
    [design document](/versions/8.6.0/contribute/design-documents).
-1. Ensure you've signed a [Contributor License
-   Agreement](https://cla.developers.google.com).
+1. Ensure you've signed a [Contributor License Agreement](https://cla.developers.google.com).
 1. Prepare a git commit that implements the feature. Don't forget to add tests
    and update the documentation. If your change has user-visible effects, please
    [add release notes](/versions/8.6.0/contribute/release-notes). If it is an incompatible change,
    read the [guide for rolling out breaking changes](/versions/8.6.0/contribute/breaking-changes).
 1. Create a pull request on
    [GitHub](https://github.com/bazelbuild/bazel/pulls). If you're new to GitHub,
-   read [about pull
-   requests](https://help.github.com/articles/about-pull-requests/). Note that
+   read [about pull requests](https://help.github.com/articles/about-pull-requests/). Note that
    we restrict permissions to create branches on the main Bazel repository, so
-   you will need to push your commit to [your own fork of the
-   repository](https://help.github.com/articles/working-with-forks/).
+   you will need to push your commit to [your own fork of the repository](https://help.github.com/articles/working-with-forks/).
 1. A Bazel maintainer should assign you a reviewer within two business days
    (excluding holidays in the USA and Germany). If you aren't assigned a
    reviewer in that time, you can request one by emailing
-   [bazel-discuss@googlegroups.com]
-   (mailto:bazel-discuss@googlegroups.com).
+   [bazel-discuss@googlegroups.com](mailto:bazel-discuss@googlegroups.com).
 1. Work with the reviewer to complete a code review. For each change, create a
    new commit and push it to make changes to your pull request. If the review
    takes too long (for instance, if the reviewer is unresponsive), send an email to
-   [bazel-discuss@googlegroups.com]
-   (mailto:bazel-discuss@googlegroups.com).
+   [bazel-discuss@googlegroups.com](mailto:bazel-discuss@googlegroups.com).
 1. After your review is complete, a Bazel maintainer applies your patch to
    Google's internal version control system.
 
diff --git a/versions/8.6.0/contribute/release-notes.mdx b/versions/8.6.0/contribute/release-notes.mdx
index 9b362325..f9cc9536 100644
--- a/versions/8.6.0/contribute/release-notes.mdx
+++ b/versions/8.6.0/contribute/release-notes.mdx
@@ -16,8 +16,7 @@ the release announcement.
 * If the change adds / removes / changes Bazel in a user-visible way, then it
   may be advantageous to mention it.
 
-If the change is significant, follow the [design document
-policy](/versions/8.6.0/contribute/design-documents) first.
+If the change is significant, follow the [design document policy](/versions/8.6.0/contribute/design-documents) first.
 
 ## Guidelines
 
@@ -60,10 +59,8 @@ change is about.
 
 ## Process
 
-As part of the [release
-process](https://github.com/bazelbuild/continuous-integration/blob/master/docs/release-playbook.md),
-we collect the `RELNOTES` tags of every commit. We copy everything in a [Google
-Doc](https://docs.google.com/document/d/1wDvulLlj4NAlPZamdlEVFORks3YXJonCjyuQMUQEmB0/edit)
+As part of the [release process](https://github.com/bazelbuild/continuous-integration/blob/master/docs/release-playbook.md),
+we collect the `RELNOTES` tags of every commit. We copy everything in a [Google Doc](https://docs.google.com/document/d/1wDvulLlj4NAlPZamdlEVFORks3YXJonCjyuQMUQEmB0/edit)
 where we review, edit, and organize the notes.
 
 The release manager sends an email to the
@@ -71,6 +68,4 @@ The release manager sends an email to the
 Bazel contributors are invited to contribute to the document and make sure
 their changes are correctly reflected in the announcement.
 
-Later, the announcement will be submitted to the [Bazel
-blog](https://blog.bazel.build/), using the [bazel-blog
-repository](https://github.com/bazelbuild/bazel-blog/tree/master/_posts).
+Later, the announcement will be submitted to the [Bazel blog](https://blog.bazel.build/), using the [bazel-blog repository](https://github.com/bazelbuild/bazel-blog/tree/master/_posts).
diff --git a/versions/8.6.0/contribute/statemachine-guide.mdx b/versions/8.6.0/contribute/statemachine-guide.mdx
index 2d44221a..b574e584 100644
--- a/versions/8.6.0/contribute/statemachine-guide.mdx
+++ b/versions/8.6.0/contribute/statemachine-guide.mdx
@@ -172,8 +172,7 @@ instead, batches[^4] as many lookups as possible before doing so. The value
 might not be immediately available, for example, requiring a Skyframe restart,
 so the caller specifies what to do with the resulting value using a callback.
 
-The `StateMachine` processor ([`Driver`s and bridging to
-SkyFrame](#drivers-and-bridging)) guarantees that the value is available before
+The `StateMachine` processor ([`Driver`s and bridging to SkyFrame](#drivers-and-bridging)) guarantees that the value is available before
 the next state begins. An example follows.
 
 ```
@@ -284,8 +283,7 @@ and solutions to certain control flow problems.
 ### Sequential states
 
 This is the most common and straightforward control flow pattern. An example of
-this is shown in [Stateful computations inside
-`SkyKeyComputeState`](#stateful-computations).
+this is shown in [Stateful computations inside `SkyKeyComputeState`](#stateful-computations).
 
 ### Branching
 
@@ -545,8 +543,7 @@ section describes the propagation of data values.
 
 ### Implementing `Tasks.lookUp` callbacks
 
-There’s an example of implementing a `Tasks.lookUp` callback in [SkyValue
-lookups](#skyvalue-lookups). This section provides rationale and suggests
+There’s an example of implementing a `Tasks.lookUp` callback in [SkyValue lookups](#skyvalue-lookups). This section provides rationale and suggests
 approaches for handling multiple SkyValues.
 
 #### `Tasks.lookUp` callbacks
@@ -710,8 +707,7 @@ class BarProducer implements StateMachine {
 Tip: It would be tempting to use the more concise signature void `accept(Bar
 value)` rather than the stuttery `void acceptBarValue(Bar value)` above.
 However, `Consumer` is a common overload of `void accept(Bar value)`,
-so doing this often leads to violations of the [Overloads: never
-split](https://google.github.io/styleguide/javaguide.html#s3.4.2-ordering-class-contents)
+so doing this often leads to violations of the [Overloads: never split](https://google.github.io/styleguide/javaguide.html#s3.4.2-ordering-class-contents)
 style-guide rule.
 
 Tip: Using a custom `ResultSink` type instead of a generic one from
@@ -774,14 +770,11 @@ pattern after accepting output from either a subtask or SkyValue lookup.
 Note that the implementation of `acceptBarError` eagerly forwards the result to
 the `Caller.ResultSink`, as required by [Error bubbling](#error-bubbling).
 
-Alternatives for top-level `StateMachine`s are described in [`Driver`s and
-bridging to SkyFunctions](#drivers-and-bridging).
+Alternatives for top-level `StateMachine`s are described in [`Driver`s and bridging to SkyFunctions](#drivers-and-bridging).
 
 ### Error handling
 
-There's a couple of examples of error handling already in [`Tasks.lookUp`
-callbacks](#tasks-lookup-callbacks) and [Propagating values between
-`StateMachines`](#propagating-values). Exceptions, other than
+There's a couple of examples of error handling already in [`Tasks.lookUp` callbacks](#tasks-lookup-callbacks) and [Propagating values between `StateMachines`](#propagating-values). Exceptions, other than
 `InterruptedException` are not thrown, but instead passed around through
 callbacks as values. Such callbacks often have exclusive-or semantics, with
 exactly one of a value or error being passed.
@@ -1184,8 +1177,7 @@ states. Where it is possible, local stack `step` variables are young generation
 variables and efficiently GC'd.
 
 For `StateMachine` variables, breaking things down into subtasks and following
-the recommended pattern for [Propagating values between
-`StateMachine`s](#propagating-values) is also helpful. Observe that when
+the recommended pattern for [Propagating values between `StateMachine`s](#propagating-values) is also helpful. Observe that when
 following the pattern, only child `StateMachine`s have references to parent
 `StateMachine`s and not vice versa. This means that as children complete and
 update the parents using result callbacks, the children naturally fall out of
@@ -1207,8 +1199,7 @@ potentially reflecting local behavior.
 
 ### Concurrency tree diagram
 
-The following is an alternative view of the diagram in [Structured
-concurrency](#structured-concurrency) that better depicts the tree structure.
+The following is an alternative view of the diagram in [Structured concurrency](#structured-concurrency) that better depicts the tree structure.
 The blocks form a small tree.
 
 ![Structured Concurrency 3D](/versions/8.6.0/contribute/images/structured-concurrency-3d.svg)
diff --git a/versions/8.6.0/docs/android-instrumentation-test.mdx b/versions/8.6.0/docs/android-instrumentation-test.mdx
index 520cbdf5..37adc455 100644
--- a/versions/8.6.0/docs/android-instrumentation-test.mdx
+++ b/versions/8.6.0/docs/android-instrumentation-test.mdx
@@ -2,8 +2,7 @@
 title: 'Android Instrumentation Tests'
 ---
 
-_If you're new to Bazel, start with the [Building Android with
-Bazel](/versions/8.6.0/start/android-app ) tutorial._
+_If you're new to Bazel, start with the [Building Android with Bazel](/versions/8.6.0/start/android-app) tutorial._
 
 ![Running Android instrumentation tests in parallel](/versions/8.6.0/docs/images/android_test.gif "Android instrumentation test")
 
@@ -18,9 +17,7 @@ emulators in a sandbox, ensuring that tests always run from a clean state. Each
 test gets an isolated emulator instance, allowing tests to run in parallel
 without passing states between them.
 
-For more information on Android instrumentation tests, check out the [Android
-developer
-documentation](https://developer.android.com/training/testing/unit-testing/instrumented-unit-tests.html).
+For more information on Android instrumentation tests, check out the [Android developer documentation](https://developer.android.com/training/testing/unit-testing/instrumented-unit-tests.html).
 
 Please file issues in the [GitHub issue tracker](https://github.com/bazelbuild/bazel/issues).
 
@@ -58,8 +55,7 @@ This results in output similar to the following:
 release 4.1.0
 ```
 
-- **KVM**. Bazel requires emulators to have [hardware
-  acceleration](https://developer.android.com/studio/run/emulator-acceleration.html#accel-check)
+- **KVM**. Bazel requires emulators to have [hardware acceleration](https://developer.android.com/studio/run/emulator-acceleration.html#accel-check)
   with KVM on Linux. You can follow these
   [installation instructions](https://help.ubuntu.com/community/KVM/Installation)
   for Ubuntu.
@@ -173,11 +169,9 @@ The main attributes of the rule `android_instrumentation_test` are:
 
 - `target_device`: An `android_device` target. This target describes the
   specifications of the Android emulator which Bazel uses to create, launch and
-  run the tests. See the [section on choosing an Android
-  device](#android-device-target) for more information.
+  run the tests. See the [section on choosing an Android device](#android-device-target) for more information.
 
-The test app's `AndroidManifest.xml` must include [an ``
-tag](https://developer.android.com/studio/test/#configure_instrumentation_manifest_settings).
+The test app's `AndroidManifest.xml` must include [an `` tag](https://developer.android.com/studio/test/#configure_instrumentation_manifest_settings).
 This tag must specify the attributes for the **package of the target app** and
 the **fully qualified class name of the instrumentation test runner**,
 `androidx.test.runner.AndroidJUnitRunner`.
@@ -214,8 +208,7 @@ repositories:
 - `@androidsdk`: The Android SDK. Download this through Android Studio.
 
 - `@android_test_support`: Hosts the test runner, emulator launcher, and
-  `android_device` targets. You can find the [latest release
-  here](https://github.com/android/android-test/releases).
+  `android_device` targets. You can find the [latest release here](https://github.com/android/android-test/releases).
 
 Enable these dependencies by adding the following lines to your `WORKSPACE`
 file:
@@ -240,8 +233,7 @@ android_test_repositories()
 
 ## Maven dependencies
 
-For managing dependencies on Maven artifacts from repositories, such as [Google
-Maven](https://maven.google.com) or [Maven Central](https://central.maven.org),
+For managing dependencies on Maven artifacts from repositories, such as [Google Maven](https://maven.google.com) or [Maven Central](https://central.maven.org),
 you should use a Maven resolver, such as
 [`rules_jvm_external`](https://github.com/bazelbuild/rules_jvm_external).
 
@@ -370,8 +362,7 @@ the device/emulator listed in `adb devices`.
 
 ## Sample projects
 
-If you are looking for canonical project samples, see the [Android testing
-samples](https://github.com/googlesamples/android-testing#experimental-bazel-support)
+If you are looking for canonical project samples, see the [Android testing samples](https://github.com/googlesamples/android-testing#experimental-bazel-support)
 for projects using Espresso and UIAutomator.
 
 ## Espresso setup
@@ -560,8 +551,7 @@ API_LEVELS = [
 
 ## Known issues
 
-- [Forked adb server processes are not terminated after
-  tests](https://github.com/bazelbuild/bazel/issues/4853)
+- [Forked adb server processes are not terminated after tests](https://github.com/bazelbuild/bazel/issues/4853)
 - While APK building works on all platforms (Linux, macOS, Windows), testing
   only works on Linux.
 - Even with `--config=local_adb`, users still need to specify
diff --git a/versions/8.6.0/docs/android-ndk.mdx b/versions/8.6.0/docs/android-ndk.mdx
index c628dc9a..f1b572a3 100644
--- a/versions/8.6.0/docs/android-ndk.mdx
+++ b/versions/8.6.0/docs/android-ndk.mdx
@@ -2,8 +2,7 @@
 title: 'Using the Android Native Development Kit with Bazel'
 ---
 
-_If you're new to Bazel, please start with the [Building Android with
-Bazel](/versions/8.6.0/start/android-app ) tutorial._
+_If you're new to Bazel, please start with the [Building Android with Bazel](/versions/8.6.0/start/android-app) tutorial._
 
 ## Overview
 
@@ -31,8 +30,7 @@ android_ndk_repository(
 )
 ```
 
-For more information about the `android_ndk_repository` rule, see the [Build
-Encyclopedia entry](/versions/8.6.0/reference/be/android#android_ndk_repository).
+For more information about the `android_ndk_repository` rule, see the [Build Encyclopedia entry](/versions/8.6.0/reference/be/android#android_ndk_repository).
 
 If you're using a recent version of the Android NDK (r22 and beyond), use the
 Starlark implementation of `android_ndk_repository`.
@@ -101,13 +99,11 @@ META-INF/MANIFEST.MF
 
 Bazel compiles all of the cc_libraries into a single shared object (`.so`) file,
 targeted for the `armeabi-v7a` ABI by default. To change this or build for
-multiple ABIs at the same time, see the section on [configuring the target
-ABI](#configuring-target-abi).
+multiple ABIs at the same time, see the section on [configuring the target ABI](#configuring-target-abi).
 
 ## Example setup
 
-This example is available in the [Bazel examples
-repository](https://github.com/bazelbuild/examples/tree/master/android/ndk).
+This example is available in the [Bazel examples repository](https://github.com/bazelbuild/examples/tree/master/android/ndk).
 
 In the `BUILD.bazel` file, three targets are defined with the `android_binary`,
 `android_library`, and `cc_library` rules.
diff --git a/versions/8.6.0/docs/bazel-and-android.mdx b/versions/8.6.0/docs/bazel-and-android.mdx
index 750a10c7..832ccd16 100644
--- a/versions/8.6.0/docs/bazel-and-android.mdx
+++ b/versions/8.6.0/docs/bazel-and-android.mdx
@@ -10,7 +10,7 @@ Android projects with Bazel.
 
 The following resources will help you work with Bazel on Android projects:
 
-*  [Tutorial: Building an Android app](/versions/8.6.0/start/android-app ). This
+*  [Tutorial: Building an Android app](/versions/8.6.0/start/android-app). This
    tutorial is a good place to start learning about Bazel commands and concepts,
    and how to build Android apps with Bazel.
 *  [Codelab: Building Android Apps with Bazel](https://developer.android.com/codelabs/bazel-android-intro#0).
diff --git a/versions/8.6.0/docs/configurable-attributes.mdx b/versions/8.6.0/docs/configurable-attributes.mdx
index a93dc87b..2049810e 100644
--- a/versions/8.6.0/docs/configurable-attributes.mdx
+++ b/versions/8.6.0/docs/configurable-attributes.mdx
@@ -2,8 +2,7 @@
 title: 'Configurable Build Attributes'
 ---
 
-**_Configurable attributes_**, commonly known as [`select()`](
-/reference/be/functions#select), is a Bazel feature that lets users toggle the values
+**_Configurable attributes_**, commonly known as [`select()`](/versions/8.6.0/reference/be/functions#select), is a Bazel feature that lets users toggle the values
 of build rule attributes at the command line.
 
 This can be used, for example, for a multiplatform library that automatically
@@ -407,8 +406,7 @@ sh_library(
 )
 ```
 
-If you need a `select` to match when multiple conditions match, consider [AND
-chaining](#and-chaining).
+If you need a `select` to match when multiple conditions match, consider [AND chaining](#and-chaining).
 
 ## OR chaining
 
diff --git a/versions/8.6.0/docs/images/a_b_a_c.svg b/versions/8.6.0/docs/images/a_b_a_c.svg
new file mode 100644
index 00000000..d38be075
--- /dev/null
+++ b/versions/8.6.0/docs/images/a_b_a_c.svg
@@ -0,0 +1,42 @@
+
+
+
+
+
+
+G
+
+
+
+a
+
+a
+
+
+
+b
+
+b
+
+
+
+a->b
+
+
+
+
+
+c
+
+c
+
+
+
+a->c
+
+
+
+
+
+
diff --git a/versions/8.6.0/docs/images/a_b_c.svg b/versions/8.6.0/docs/images/a_b_c.svg
new file mode 100644
index 00000000..acd948ab
--- /dev/null
+++ b/versions/8.6.0/docs/images/a_b_c.svg
@@ -0,0 +1,41 @@
+
+
+
+
+
+
+G
+
+
+
+a
+
+a
+
+
+
+b
+
+b
+
+
+
+a->b
+
+
+
+
+
+c
+
+c
+
+
+
+b->c
+
+
+
+
+
diff --git a/versions/8.6.0/docs/images/a_b_c_ac.svg b/versions/8.6.0/docs/images/a_b_c_ac.svg
new file mode 100644
index 00000000..b099c53e
--- /dev/null
+++ b/versions/8.6.0/docs/images/a_b_c_ac.svg
@@ -0,0 +1,47 @@
+
+
+
+
+
+
+G
+
+
+
+a
+
+a
+
+
+
+b
+
+b
+
+
+
+a->b
+
+
+
+
+
+c
+
+c
+
+
+
+a->c
+
+
+
+
+
+b->c
+
+
+
+
+
diff --git a/versions/8.6.0/docs/images/ab_c.svg b/versions/8.6.0/docs/images/ab_c.svg
new file mode 100644
index 00000000..bcc4563f
--- /dev/null
+++ b/versions/8.6.0/docs/images/ab_c.svg
@@ -0,0 +1,36 @@
+
+
+
+
+
+
+G
+
+
+
+a
+
+a
+
+
+
+b
+
+b
+
+
+
+a->b
+
+
+
+
+
+c
+
+c
+
+
+
+
diff --git a/versions/8.6.0/docs/images/allpaths.svg b/versions/8.6.0/docs/images/allpaths.svg
new file mode 100644
index 00000000..47d0ee33
--- /dev/null
+++ b/versions/8.6.0/docs/images/allpaths.svg
@@ -0,0 +1,141 @@
+
+
+
+
+
+
+allpaths
+
+
+
+n1
+
+
+
+
+n2
+
+
+
+
+n1->n2
+
+
+
+
+
+n3
+
+
+
+
+n2->n3
+
+
+
+
+
+n10
+
+
+
+
+n2->n10
+
+
+
+
+
+n3->n10
+
+
+
+
+
+n4
+
+E
+
+
+
+n5
+
+
+
+
+n6
+
+
+
+
+n5->n6
+
+
+
+
+
+n6->n4
+
+
+
+
+
+n9
+
+
+
+
+n6->n9
+
+
+
+
+
+n7
+
+S1
+
+
+
+n7->n2
+
+
+
+
+
+n7->n5
+
+
+
+
+
+n8
+
+S2
+
+
+
+n8->n6
+
+
+
+
+
+n10->n4
+
+
+
+
+
+n11
+
+
+
+
+n10->n11
+
+
+
+
+
diff --git a/versions/8.6.0/docs/images/android_instrumentation_test.png b/versions/8.6.0/docs/images/android_instrumentation_test.png
new file mode 100644
index 00000000..e4534fbd
Binary files /dev/null and b/versions/8.6.0/docs/images/android_instrumentation_test.png differ
diff --git a/versions/8.6.0/docs/images/android_ndk.png b/versions/8.6.0/docs/images/android_ndk.png
new file mode 100644
index 00000000..76b63cb3
Binary files /dev/null and b/versions/8.6.0/docs/images/android_ndk.png differ
diff --git a/versions/8.6.0/docs/images/android_tutorial_app.png b/versions/8.6.0/docs/images/android_tutorial_app.png
new file mode 100644
index 00000000..076be5b9
Binary files /dev/null and b/versions/8.6.0/docs/images/android_tutorial_app.png differ
diff --git a/versions/8.6.0/docs/images/android_tutorial_before.png b/versions/8.6.0/docs/images/android_tutorial_before.png
new file mode 100644
index 00000000..8e41d419
Binary files /dev/null and b/versions/8.6.0/docs/images/android_tutorial_before.png differ
diff --git a/versions/8.6.0/docs/images/bep-graph.png b/versions/8.6.0/docs/images/bep-graph.png
new file mode 100644
index 00000000..82da6715
Binary files /dev/null and b/versions/8.6.0/docs/images/bep-graph.png differ
diff --git a/versions/8.6.0/docs/images/bep-graph.svg b/versions/8.6.0/docs/images/bep-graph.svg
new file mode 100644
index 00000000..62b1480f
--- /dev/null
+++ b/versions/8.6.0/docs/images/bep-graph.svg
@@ -0,0 +1,4 @@
+
+
+
+
diff --git a/versions/8.6.0/docs/images/cpp-tutorial-stage1.png b/versions/8.6.0/docs/images/cpp-tutorial-stage1.png
new file mode 100644
index 00000000..c85fb303
Binary files /dev/null and b/versions/8.6.0/docs/images/cpp-tutorial-stage1.png differ
diff --git a/versions/8.6.0/docs/images/cpp-tutorial-stage2.png b/versions/8.6.0/docs/images/cpp-tutorial-stage2.png
new file mode 100644
index 00000000..80e202c9
Binary files /dev/null and b/versions/8.6.0/docs/images/cpp-tutorial-stage2.png differ
diff --git a/versions/8.6.0/docs/images/cpp-tutorial-stage3.png b/versions/8.6.0/docs/images/cpp-tutorial-stage3.png
new file mode 100644
index 00000000..54d82f31
Binary files /dev/null and b/versions/8.6.0/docs/images/cpp-tutorial-stage3.png differ
diff --git a/versions/8.6.0/docs/images/deps.svg b/versions/8.6.0/docs/images/deps.svg
new file mode 100644
index 00000000..4354222a
--- /dev/null
+++ b/versions/8.6.0/docs/images/deps.svg
@@ -0,0 +1,101 @@
+
+
+
+
+
+
+G1
+
+
+
+r1
+
+rule
+
+
+
+s1
+
+in
+
+
+
+r1->s1
+
+
+
+
+
+s2
+
+in
+
+
+
+r1->s2
+
+
+
+
+
+s3
+
+in
+
+
+
+r1->s3
+
+
+
+
+
+r2
+
+rule
+
+
+
+r2->r1
+
+
+
+
+
+s4
+
+in
+
+
+
+r2->s4
+
+
+
+
+
+o1
+
+out
+
+
+
+o1->r1
+
+
+
+
+
+o2
+
+out
+
+
+
+o2->r2
+
+
+
+
+
diff --git a/versions/8.6.0/docs/images/dyn-trace-alldynamic.png b/versions/8.6.0/docs/images/dyn-trace-alldynamic.png
new file mode 100644
index 00000000..fe36b253
Binary files /dev/null and b/versions/8.6.0/docs/images/dyn-trace-alldynamic.png differ
diff --git a/versions/8.6.0/docs/images/dyn-trace-javaconly.png b/versions/8.6.0/docs/images/dyn-trace-javaconly.png
new file mode 100644
index 00000000..2ae41e52
Binary files /dev/null and b/versions/8.6.0/docs/images/dyn-trace-javaconly.png differ
diff --git a/versions/8.6.0/docs/images/e4b-workflow.png b/versions/8.6.0/docs/images/e4b-workflow.png
new file mode 100644
index 00000000..412822da
Binary files /dev/null and b/versions/8.6.0/docs/images/e4b-workflow.png differ
diff --git a/versions/8.6.0/docs/images/e4b-workflow.svg b/versions/8.6.0/docs/images/e4b-workflow.svg
new file mode 100644
index 00000000..1de66e02
--- /dev/null
+++ b/versions/8.6.0/docs/images/e4b-workflow.svg
@@ -0,0 +1,4 @@
+
+
+
+
diff --git a/versions/8.6.0/docs/images/error_example_1.png b/versions/8.6.0/docs/images/error_example_1.png
new file mode 100644
index 00000000..07ba1358
Binary files /dev/null and b/versions/8.6.0/docs/images/error_example_1.png differ
diff --git a/versions/8.6.0/docs/images/error_example_2.png b/versions/8.6.0/docs/images/error_example_2.png
new file mode 100644
index 00000000..861171ee
Binary files /dev/null and b/versions/8.6.0/docs/images/error_example_2.png differ
diff --git a/versions/8.6.0/docs/images/error_example_3.png b/versions/8.6.0/docs/images/error_example_3.png
new file mode 100644
index 00000000..dc16eec4
Binary files /dev/null and b/versions/8.6.0/docs/images/error_example_3.png differ
diff --git a/versions/8.6.0/docs/images/error_example_4.png b/versions/8.6.0/docs/images/error_example_4.png
new file mode 100644
index 00000000..84383e63
Binary files /dev/null and b/versions/8.6.0/docs/images/error_example_4.png differ
diff --git a/versions/8.6.0/docs/images/graph_ex_1.svg b/versions/8.6.0/docs/images/graph_ex_1.svg
new file mode 100644
index 00000000..dd7427f4
--- /dev/null
+++ b/versions/8.6.0/docs/images/graph_ex_1.svg
@@ -0,0 +1,131 @@
+
+
+
+
+
+
+mygraph
+
+
+
+//net/proto_compiler:protocol-compiler
+
+//net/proto_compiler:protocol-compiler
+
+
+
+//net/proto_compiler:util
+
+//net/proto_compiler:util
+
+
+
+//net/proto_compiler:protocol-compiler->//net/proto_compiler:util
+
+
+
+
+
+//net/proto_compiler:protocol-compiler-lib
+
+//net/proto_compiler:protocol-compiler-lib
+
+
+
+//net/proto_compiler:protocol-compiler->//net/proto_compiler:protocol-compiler-lib
+
+
+
+
+
+//net/proto2/bridge/public:compiler_upgrader
+
+//net/proto2/bridge/public:compiler_upgrader
+
+
+
+//net/proto_compiler:protocol-compiler->//net/proto2/bridge/public:compiler_upgrader
+
+
+
+
+
+//net/proto_compiler:parser
+
+//net/proto_compiler:parser
+
+
+
+//net/proto_compiler:util->//net/proto_compiler:parser
+
+
+
+
+
+//net/proto_compiler:proto-min-lib
+
+//net/proto_compiler:proto-min-lib
+
+
+
+//net/proto_compiler:protocol-compiler-lib->//net/proto_compiler:proto-min-lib
+
+
+
+
+
+//net/proto_compiler:protocol-compiler-lib->//net/proto_compiler:parser
+
+
+
+
+
+//net/proto2/bridge/internal:compiler_upgrader
+
+//net/proto2/bridge/internal:compiler_upgrader
+
+
+
+//net/proto2/bridge/public:compiler_upgrader->//net/proto2/bridge/internal:compiler_upgrader
+
+
+
+
+
+//net/proto_compiler:proto-min-lib->//net/proto_compiler:parser
+
+
+
+
+
+//util/regexp:regexp
+
+//util/regexp:regexp
+
+
+
+//net/proto_compiler:proto-min-lib->//util/regexp:regexp
+
+
+
+
+
+//net/proto_compiler:parser->//util/regexp:regexp
+
+
+
+
+
+//net/proto2/bridge/internal:compiler_upgrader->//net/proto2/bridge/public:compiler_upgrader
+
+
+
+
+
+//net/proto2/bridge/internal:compiler_upgrader->//net/proto_compiler:parser
+
+
+
+
+
diff --git a/versions/8.6.0/docs/images/graph_hello-world.svg b/versions/8.6.0/docs/images/graph_hello-world.svg
new file mode 100644
index 00000000..93b61444
--- /dev/null
+++ b/versions/8.6.0/docs/images/graph_hello-world.svg
@@ -0,0 +1,70 @@
+
+
+
+
+
+
+mygraph
+
+
+//main:hello-world
+
+//main:hello-world
+
+
+//main:hello-time
+
+//main:hello-time
+
+
+//main:hello-world->//main:hello-time
+
+
+
+
+//main:hello-world.cc
+
+//main:hello-world.cc
+
+
+//main:hello-world->//main:hello-world.cc
+
+
+
+
+//lib:hello-greet
+
+//lib:hello-greet
+
+
+//main:hello-world->//lib:hello-greet
+
+
+
+
+//main:hello-time.cc\n//main:hello-time.h
+
+//main:hello-time.cc
+//main:hello-time.h
+
+
+//main:hello-time->//main:hello-time.cc\n//main:hello-time.h
+
+
+
+
+//lib:hello-greet.cc\n//lib:hello-greet.h
+
+//lib:hello-greet.cc
+//lib:hello-greet.h
+
+
+//lib:hello-greet->//lib:hello-greet.cc\n//lib:hello-greet.h
+
+
+
+
+
diff --git a/versions/8.6.0/docs/images/json-trace-profile-network-usage.png b/versions/8.6.0/docs/images/json-trace-profile-network-usage.png
new file mode 100644
index 00000000..8a7500a6
Binary files /dev/null and b/versions/8.6.0/docs/images/json-trace-profile-network-usage.png differ
diff --git a/versions/8.6.0/docs/images/json-trace-profile-system-load-average.png b/versions/8.6.0/docs/images/json-trace-profile-system-load-average.png
new file mode 100644
index 00000000..e71b420c
Binary files /dev/null and b/versions/8.6.0/docs/images/json-trace-profile-system-load-average.png differ
diff --git a/versions/8.6.0/docs/images/json-trace-profile-workers-memory-usage.png b/versions/8.6.0/docs/images/json-trace-profile-workers-memory-usage.png
new file mode 100644
index 00000000..806505f0
Binary files /dev/null and b/versions/8.6.0/docs/images/json-trace-profile-workers-memory-usage.png differ
diff --git a/versions/8.6.0/docs/images/json-trace-profile.png b/versions/8.6.0/docs/images/json-trace-profile.png
new file mode 100644
index 00000000..538382b2
Binary files /dev/null and b/versions/8.6.0/docs/images/json-trace-profile.png differ
diff --git a/versions/8.6.0/docs/images/mobile-install-performance.svg b/versions/8.6.0/docs/images/mobile-install-performance.svg
new file mode 100644
index 00000000..b139d658
--- /dev/null
+++ b/versions/8.6.0/docs/images/mobile-install-performance.svg
@@ -0,0 +1,86 @@
+
+
+
+  
+    
+      
+    
+  
+  
+  
+    Build times
+  
+  
+    
+    
+      
+      
+        adb install
+      
+      
+    
+    
+      
+      
+        mobile-install
+      
+      
+    
+  
+  
+    
+    
+      
+        
+        
+        
+        
+        
+      
+      
+        
+        
+        
+        
+        
+        
+      
+      
+        
+      
+    
+    
+    
+      
+        Google Maps
+      
+      
+        Google+
+      
+      
+        YouTube
+      
+      
+        0
+      
+      
+        75
+      
+      
+        150
+      
+      
+        225
+      
+      
+        300
+      
+    
+  
+  
+    
+      Seconds
+    
+  
+  
+
diff --git a/versions/8.6.0/docs/images/namedsetoffiles-bep-graph.png b/versions/8.6.0/docs/images/namedsetoffiles-bep-graph.png
new file mode 100644
index 00000000..ea1e10cc
Binary files /dev/null and b/versions/8.6.0/docs/images/namedsetoffiles-bep-graph.png differ
diff --git a/versions/8.6.0/docs/images/out-ranked.svg b/versions/8.6.0/docs/images/out-ranked.svg
new file mode 100644
index 00000000..07e96804
--- /dev/null
+++ b/versions/8.6.0/docs/images/out-ranked.svg
@@ -0,0 +1,71 @@
+
+
+
+
+
+
+mygraph
+
+
+
+//a:a
+
+//a:a
+
+
+
+//a:a.cc
+
+//a:a.cc
+
+
+
+//a:a->//a:a.cc
+
+
+
+
+
+//b:b
+
+//b:b
+
+
+
+//b:b->//a:a
+
+
+
+
+
+//b:b.cc
+
+//b:b.cc
+
+
+
+//b:b->//b:b.cc
+
+
+
+
+
+//c:c
+
+//c:c
+
+
+
+//c:c->//a:a
+
+
+
+
+
+//c:c->//b:b
+
+
+
+
+
diff --git a/versions/8.6.0/docs/images/rbe-ci-1.png b/versions/8.6.0/docs/images/rbe-ci-1.png
new file mode 100644
index 00000000..fbe76a85
Binary files /dev/null and b/versions/8.6.0/docs/images/rbe-ci-1.png differ
diff --git a/versions/8.6.0/docs/images/rbe-ci-2.png b/versions/8.6.0/docs/images/rbe-ci-2.png
new file mode 100644
index 00000000..07611889
Binary files /dev/null and b/versions/8.6.0/docs/images/rbe-ci-2.png differ
diff --git a/versions/8.6.0/docs/images/somepath1.svg b/versions/8.6.0/docs/images/somepath1.svg
new file mode 100644
index 00000000..5e5f8812
--- /dev/null
+++ b/versions/8.6.0/docs/images/somepath1.svg
@@ -0,0 +1,141 @@
+
+
+
+
+
+
+somepath1
+
+
+
+n1
+
+
+
+
+n2
+
+
+
+
+n1->n2
+
+
+
+
+
+n3
+
+
+
+
+n2->n3
+
+
+
+
+
+n10
+
+
+
+
+n2->n10
+
+
+
+
+
+n3->n10
+
+
+
+
+
+n4
+
+E
+
+
+
+n5
+
+
+
+
+n6
+
+
+
+
+n5->n6
+
+
+
+
+
+n6->n4
+
+
+
+
+
+n9
+
+
+
+
+n6->n9
+
+
+
+
+
+n7
+
+S1
+
+
+
+n7->n2
+
+
+
+
+
+n7->n5
+
+
+
+
+
+n8
+
+S2
+
+
+
+n8->n6
+
+
+
+
+
+n10->n4
+
+
+
+
+
+n11
+
+
+
+
+n10->n11
+
+
+
+
+
diff --git a/versions/8.6.0/docs/images/somepath2.svg b/versions/8.6.0/docs/images/somepath2.svg
new file mode 100644
index 00000000..911f2c9b
--- /dev/null
+++ b/versions/8.6.0/docs/images/somepath2.svg
@@ -0,0 +1,141 @@
+
+
+
+
+
+
+somepath2
+
+
+
+n1
+
+
+
+
+n2
+
+
+
+
+n1->n2
+
+
+
+
+
+n3
+
+
+
+
+n2->n3
+
+
+
+
+
+n10
+
+
+
+
+n2->n10
+
+
+
+
+
+n3->n10
+
+
+
+
+
+n4
+
+E
+
+
+
+n5
+
+
+
+
+n6
+
+
+
+
+n5->n6
+
+
+
+
+
+n6->n4
+
+
+
+
+
+n9
+
+
+
+
+n6->n9
+
+
+
+
+
+n7
+
+S1
+
+
+
+n7->n2
+
+
+
+
+
+n7->n5
+
+
+
+
+
+n8
+
+S2
+
+
+
+n8->n6
+
+
+
+
+
+n10->n4
+
+
+
+
+
+n11
+
+
+
+
+n10->n11
+
+
+
+
+
diff --git a/versions/8.6.0/docs/images/targets.svg b/versions/8.6.0/docs/images/targets.svg
new file mode 100644
index 00000000..82f47e74
--- /dev/null
+++ b/versions/8.6.0/docs/images/targets.svg
@@ -0,0 +1,113 @@
+
+
+
+
+
+
+G1
+
+
+
+Target
+
+Target
+
+
+
+Rule
+
+Rule
+
+
+
+Target->Rule
+
+
+
+
+
+File
+
+File
+
+
+
+Target->File
+
+
+
+
+
+Package group
+
+Package group
+
+
+
+Target->Package group
+
+
+
+
+
+cc_library
+
+cc_library
+
+
+
+Rule->cc_library
+
+
+
+
+
+java_test
+
+java_test
+
+
+
+Rule->java_test
+
+
+
+
+
+...
+
+...
+
+
+
+Rule->...
+
+
+
+
+
+Source
+
+Source
+
+
+
+File->Source
+
+
+
+
+
+Generated
+
+Generated
+
+
+
+File->Generated
+
+
+
+
+
diff --git a/versions/8.6.0/docs/images/tutorial_java_01.svg b/versions/8.6.0/docs/images/tutorial_java_01.svg
new file mode 100644
index 00000000..2fe72f36
--- /dev/null
+++ b/versions/8.6.0/docs/images/tutorial_java_01.svg
@@ -0,0 +1,29 @@
+
+
+
+
+
+
+mygraph
+
+
+//:ProjectRunner
+
+//:ProjectRunner
+
+
+//:src/main/java/com/example/Greeting.java\n//:src/main/java/com/example/ProjectRunner.java
+
+//:src/main/java/com/example/Greeting.java
+//:src/main/java/com/example/ProjectRunner.java
+
+
+//:ProjectRunner->//:src/main/java/com/example/Greeting.java\n//:src/main/java/com/example/ProjectRunner.java
+
+
+
+
+
diff --git a/versions/8.6.0/docs/images/tutorial_java_02.svg b/versions/8.6.0/docs/images/tutorial_java_02.svg
new file mode 100644
index 00000000..40cbb218
--- /dev/null
+++ b/versions/8.6.0/docs/images/tutorial_java_02.svg
@@ -0,0 +1,48 @@
+
+
+
+
+
+
+mygraph
+
+
+//:ProjectRunner
+
+//:ProjectRunner
+
+
+//:greeter
+
+//:greeter
+
+
+//:ProjectRunner->//:greeter
+
+
+
+
+//:src/main/java/com/example/ProjectRunner.java
+
+//:src/main/java/com/example/ProjectRunner.java
+
+
+//:ProjectRunner->//:src/main/java/com/example/ProjectRunner.java
+
+
+
+
+//:src/main/java/com/example/Greeting.java
+
+//:src/main/java/com/example/Greeting.java
+
+
+//:greeter->//:src/main/java/com/example/Greeting.java
+
+
+
+
+
diff --git a/versions/8.6.0/docs/images/tutorial_java_03.svg b/versions/8.6.0/docs/images/tutorial_java_03.svg
new file mode 100644
index 00000000..7d79041a
--- /dev/null
+++ b/versions/8.6.0/docs/images/tutorial_java_03.svg
@@ -0,0 +1,48 @@
+
+
+
+
+
+
+mygraph
+
+
+//src/main/java/com/example/cmdline:runner
+
+//src/main/java/com/example/cmdline:runner
+
+
+//src/main/java/com/example/cmdline:Runner.java
+
+//src/main/java/com/example/cmdline:Runner.java
+
+
+//src/main/java/com/example/cmdline:runner->//src/main/java/com/example/cmdline:Runner.java
+
+
+
+
+//:greeter
+
+//:greeter
+
+
+//src/main/java/com/example/cmdline:runner->//:greeter
+
+
+
+
+//:src/main/java/com/example/Greeting.java
+
+//:src/main/java/com/example/Greeting.java
+
+
+//:greeter->//:src/main/java/com/example/Greeting.java
+
+
+
+
+
diff --git a/versions/8.6.0/docs/images/workers-clean-chart.png b/versions/8.6.0/docs/images/workers-clean-chart.png
new file mode 100644
index 00000000..63526fc1
Binary files /dev/null and b/versions/8.6.0/docs/images/workers-clean-chart.png differ
diff --git a/versions/8.6.0/docs/images/workers-incremental-chart.png b/versions/8.6.0/docs/images/workers-incremental-chart.png
new file mode 100644
index 00000000..1c62d25c
Binary files /dev/null and b/versions/8.6.0/docs/images/workers-incremental-chart.png differ
diff --git a/versions/8.6.0/docs/images/ws-diamond.png b/versions/8.6.0/docs/images/ws-diamond.png
new file mode 100644
index 00000000..154a7440
Binary files /dev/null and b/versions/8.6.0/docs/images/ws-diamond.png differ
diff --git a/versions/8.6.0/docs/images/ws-line.png b/versions/8.6.0/docs/images/ws-line.png
new file mode 100644
index 00000000..e8bfe7a1
Binary files /dev/null and b/versions/8.6.0/docs/images/ws-line.png differ
diff --git a/versions/8.6.0/docs/images/ws-multiline.png b/versions/8.6.0/docs/images/ws-multiline.png
new file mode 100644
index 00000000..f07b43b1
Binary files /dev/null and b/versions/8.6.0/docs/images/ws-multiline.png differ
diff --git a/versions/8.6.0/docs/sandboxing.mdx b/versions/8.6.0/docs/sandboxing.mdx
index 782d6b0d..ca27276e 100644
--- a/versions/8.6.0/docs/sandboxing.mdx
+++ b/versions/8.6.0/docs/sandboxing.mdx
@@ -48,7 +48,7 @@ containers on Linux and `sandbox-exec` on macOS, to constrain the action within
 ## What sandbox strategy to use
 
 You can choose which kind of sandboxing to use, if any, with the
-[strategy flags](user-manual#strategy-options). Using the `sandboxed`
+[strategy flags](/versions/8.6.0/docs/user-manual#strategy-options). Using the `sandboxed`
 strategy makes Bazel pick one of the sandbox implementations listed below,
 preferring an OS-specific sandbox to the less hermetic generic one.
 [Persistent workers](/versions/8.6.0/remote/persistent) run in a generic sandbox if you pass
diff --git a/versions/8.6.0/extending/auto-exec-groups.mdx b/versions/8.6.0/extending/auto-exec-groups.mdx
index c6a8c624..bab0282a 100644
--- a/versions/8.6.0/extending/auto-exec-groups.mdx
+++ b/versions/8.6.0/extending/auto-exec-groups.mdx
@@ -27,9 +27,7 @@ doesn't detect that ([the error](#first-error-message) is raised), you can set
 
 If you need to use multiple toolchains on a single execution platform (an action
 uses executable or tools from two or more toolchains), you need to manually
-define [exec_groups][exec_groups] (check
-[When should I use a custom exec_group?][multiple_toolchains_exec_groups]
-section).
+define [exec_groups][exec_groups](check [When should I use a custom exec_group?][multiple_toolchains_exec_groups] section).
 
 ## History
 
@@ -42,8 +40,7 @@ my_rule = rule(
 )
 ```
 
-Rule `my_rule` registers two toolchain types. This means that the [Toolchain
-Resolution](https://bazel.build/versions/8.6.0/extending/toolchains#toolchain-resolution) used
+Rule `my_rule` registers two toolchain types. This means that the [Toolchain Resolution](https://bazel.build/versions/8.6.0/extending/toolchains#toolchain-resolution) used
 to find an execution platform which supports both toolchain types. The selected
 execution platform was used for each registered action inside the rule, unless
 specified differently with [exec_groups][exec_groups].
diff --git a/versions/8.6.0/extending/concepts.mdx b/versions/8.6.0/extending/concepts.mdx
index 9e26ff48..63c02194 100644
--- a/versions/8.6.0/extending/concepts.mdx
+++ b/versions/8.6.0/extending/concepts.mdx
@@ -21,16 +21,14 @@ Before learning the more advanced concepts, first:
 ## Macros and rules
 
 A macro is a function that instantiates rules. Macros come in two flavors:
-[symbolic macros](/versions/8.6.0/extending/macros) (new in Bazel 8) and [legacy
-macros](/versions/8.6.0/extending/legacy-macros). The two flavors of macros are defined
+[symbolic macros](/versions/8.6.0/extending/macros) (new in Bazel 8) and [legacy macros](/versions/8.6.0/extending/legacy-macros). The two flavors of macros are defined
 differently, but behave almost the same from the point of view of a user. A
 macro is useful when a `BUILD` file is getting too repetitive or too complex, as
 it lets you reuse some code. The function is evaluated as soon as the `BUILD`
 file is read. After the evaluation of the `BUILD` file, Bazel has little
 information about macros. If your macro generates a `genrule`, Bazel will
 behave *almost* as if you declared that `genrule` in the `BUILD` file. (The one
-exception is that targets declared in a symbolic macro have [special visibility
-semantics](/versions/8.6.0/extending/macros#visibility): a symbolic macro can hide its internal
+exception is that targets declared in a symbolic macro have [special visibility semantics](/versions/8.6.0/extending/macros#visibility): a symbolic macro can hide its internal
 targets from the rest of the package.)
 
 A [rule](/versions/8.6.0/extending/rules) is more powerful than a macro. It can access Bazel
@@ -77,8 +75,7 @@ they will not be executed.
 ## Creating extensions
 
 * [Create your first macro](/versions/8.6.0/rules/macro-tutorial) in order to reuse some code.
-  Then [learn more about macros](/versions/8.6.0/extending/macros) and [using them to create
-  "custom verbs"](/versions/8.6.0/rules/verbs-tutorial).
+  Then [learn more about macros](/versions/8.6.0/extending/macros) and [using them to create "custom verbs"](/versions/8.6.0/rules/verbs-tutorial).
 
 * [Follow the rules tutorial](/versions/8.6.0/rules/rules-tutorial) to get started with rules.
   Next, you can read more about the [rules concepts](/versions/8.6.0/extending/rules).
@@ -93,8 +90,7 @@ them within reach:
 ## Going further
 
 In addition to [macros](/versions/8.6.0/extending/macros) and [rules](/versions/8.6.0/extending/rules), you
-may want to write [aspects](/versions/8.6.0/extending/aspects) and [repository
-rules](/versions/8.6.0/extending/repo).
+may want to write [aspects](/versions/8.6.0/extending/aspects) and [repository rules](/versions/8.6.0/extending/repo).
 
 * Use [Buildifier](https://github.com/bazelbuild/buildtools)
   consistently to format and lint your code.
diff --git a/versions/8.6.0/extending/depsets.mdx b/versions/8.6.0/extending/depsets.mdx
index 43d9b038..82a37e7c 100644
--- a/versions/8.6.0/extending/depsets.mdx
+++ b/versions/8.6.0/extending/depsets.mdx
@@ -111,8 +111,7 @@ need to ensure that if `B` depends on `A`, then `A.o` comes before `B.o` on the
 linker’s command line. Other tools might have the opposite requirement.
 
 Three traversal orders are supported: `postorder`, `preorder`, and
-`topological`. The first two work exactly like [tree
-traversals](https://en.wikipedia.org/wiki/Tree_traversal#Depth-first_search)
+`topological`. The first two work exactly like [tree traversals](https://en.wikipedia.org/wiki/Tree_traversal#Depth-first_search)
 except that they operate on DAGs and skip already visited nodes. The third order
 works as a topological sort from root to leaves, essentially the same as
 preorder except that shared children are listed only after all of their parents.
diff --git a/versions/8.6.0/extending/exec-groups.mdx b/versions/8.6.0/extending/exec-groups.mdx
index 42e5524d..d802e04e 100644
--- a/versions/8.6.0/extending/exec-groups.mdx
+++ b/versions/8.6.0/extending/exec-groups.mdx
@@ -63,8 +63,7 @@ test rules.
 
 In the rule implementation, you can declare that actions should be run on the
 execution platform of an execution group. You can do this by using the `exec_group`
-param of action generating methods, specifically [`ctx.actions.run`]
-(/rules/lib/builtins/actions#run) and
+param of action generating methods, specifically [`ctx.actions.run`](/versions/8.6.0/rules/lib/builtins/actions#run) and
 [`ctx.actions.run_shell`](/versions/8.6.0/rules/lib/builtins/actions#run_shell).
 
 ```python
diff --git a/versions/8.6.0/extending/legacy-macros.mdx b/versions/8.6.0/extending/legacy-macros.mdx
index 85746622..09a0a5db 100644
--- a/versions/8.6.0/extending/legacy-macros.mdx
+++ b/versions/8.6.0/extending/legacy-macros.mdx
@@ -9,7 +9,7 @@ anymore, and Bazel sees only the concrete set of instantiated rules.
 
 ## Why you shouldn't use legacy macros (and should use Symbolic macros instead)
 
-Where possible you should use [symbolic macros](macros.md#macros).
+Where possible you should use [symbolic macros](/versions/8.6.0/extending/macros#macros).
 
 Symbolic macros
 
@@ -18,7 +18,7 @@ Symbolic macros
 *   Take typed attributes, which in turn means automatic label and select
     conversion.
 *   Are more readable
-*   Will soon have [lazy evaluation](macros.md/laziness)
+*   Will soon have [lazy evaluation](/versions/8.6.0/extending/macros#laziness)
 
 ## Usage
 
@@ -152,7 +152,7 @@ the macro), use the function
 ## Label resolution in macros
 
 Since legacy macros are evaluated in the
-[loading phase](concepts.md#evaluation-model), label strings such as
+[loading phase](/versions/8.6.0/extending/concepts#evaluation-model), label strings such as
 `"//foo:bar"` that occur in a legacy macro are interpreted relative to the
 `BUILD` file in which the macro is used rather than relative to the `.bzl` file
 in which it is defined. This behavior is generally undesirable for macros that
diff --git a/versions/8.6.0/extending/macros.mdx b/versions/8.6.0/extending/macros.mdx
index 636889f2..96ff0d09 100644
--- a/versions/8.6.0/extending/macros.mdx
+++ b/versions/8.6.0/extending/macros.mdx
@@ -10,7 +10,7 @@ Macros are mainly used for encapsulation and code reuse of existing rules and
 other macros.
 
 Macros come in two flavors: symbolic macros, which are described on this page,
-and [legacy macros](legacy-macros.md). Where possible, we recommend using
+and [legacy macros](/versions/8.6.0/extending/legacy-macros). Where possible, we recommend using
 symbolic macros for code clarity.
 
 Symbolic macros offer typed arguments (string to label conversion, relative to
@@ -31,8 +31,7 @@ two required parameters: `attrs` and `implementation`.
 
 ### Attributes
 
-`attrs` accepts a dictionary of attribute name to [attribute
-types](https://bazel.build/versions/8.6.0/rules/lib/toplevel/attr#members), which represents
+`attrs` accepts a dictionary of attribute name to [attribute types](https://bazel.build/versions/8.6.0/rules/lib/toplevel/attr#members), which represents
 the arguments to the macro. Two common attributes – `name` and `visibility` –
 are implicitly added to all macros and are not included in the dictionary passed
 to `attrs`.
@@ -66,9 +65,7 @@ To support this pattern, a macro can *inherit attributes* from a rule or another
 macro by passing the [rule](https://bazel.build/versions/8.6.0/rules/lib/builtins/rule) or
 [macro symbol](https://bazel.build/versions/8.6.0/rules/lib/builtins/macro) to `macro()`'s
 `inherit_attrs` argument. (You can also use the special string `"common"`
-instead of a rule or macro symbol to inherit the [common attributes defined for
-all Starlark build
-rules](https://bazel.build/versions/8.6.0/reference/be/common-definitions#common-attributes).)
+instead of a rule or macro symbol to inherit the [common attributes defined for all Starlark build rules](https://bazel.build/versions/8.6.0/reference/be/common-definitions#common-attributes).)
 Only public attributes get inherited, and the attributes in the macro's own
 `attrs` dictionary override inherited attributes with the same name. You can
 also *remove* inherited attributes by using `None` as a value in the `attrs`
diff --git a/versions/8.6.0/extending/platforms.mdx b/versions/8.6.0/extending/platforms.mdx
index 5970f174..d40b9fc2 100644
--- a/versions/8.6.0/extending/platforms.mdx
+++ b/versions/8.6.0/extending/platforms.mdx
@@ -245,8 +245,7 @@ cc_library(
 
 You can use the
 [`IncompatiblePlatformProvider`](/versions/8.6.0/rules/lib/providers/IncompatiblePlatformProvider)
-in `bazel cquery`'s [Starlark output
-format](/versions/8.6.0/query/cquery#output-format-definition) to distinguish
+in `bazel cquery`'s [Starlark output format](/versions/8.6.0/query/cquery#output-format-definition) to distinguish
 incompatible targets from compatible ones.
 
 This can be used to filter out incompatible targets. The example below will
@@ -266,5 +265,4 @@ $ bazel cquery //... --output=starlark --starlark:file=example.cquery
 
 ### Known Issues
 
-Incompatible targets [ignore visibility
-restrictions](https://github.com/bazelbuild/bazel/issues/16044).
+Incompatible targets [ignore visibility restrictions](https://github.com/bazelbuild/bazel/issues/16044).
diff --git a/versions/8.6.0/extending/repo.mdx b/versions/8.6.0/extending/repo.mdx
index 0ffa048e..608fb816 100644
--- a/versions/8.6.0/extending/repo.mdx
+++ b/versions/8.6.0/extending/repo.mdx
@@ -74,8 +74,7 @@ specified.
 
 The input parameter `repository_ctx` can be used to access attribute values, and
 non-hermetic functions (finding a binary, executing a binary, creating a file in
-the repository or downloading a file from the Internet). See [the API
-docs](/versions/8.6.0/rules/lib/builtins/repository_ctx) for more context. Example:
+the repository or downloading a file from the Internet). See [the API docs](/versions/8.6.0/rules/lib/builtins/repository_ctx) for more context. Example:
 
 ```python
 def _impl(repository_ctx):
@@ -144,8 +143,7 @@ definition has the `configure` attribute set, use `bazel fetch --force
 
 ## Examples
 
--   [C++ auto-configured
-    toolchain](https://cs.opensource.google/bazel/bazel/+/master:tools/cpp/cc_configure.bzl;drc=644b7d41748e09eff9e47cbab2be2263bb71f29a;l=176):
+-   [C++ auto-configured toolchain](https://cs.opensource.google/bazel/bazel/+/master:tools/cpp/cc_configure.bzl;drc=644b7d41748e09eff9e47cbab2be2263bb71f29a;l=176):
     it uses a repo rule to automatically create the C++ configuration files for
     Bazel by looking for the local C++ compiler, the environment and the flags
     the C++ compiler supports.
diff --git a/versions/8.6.0/extending/rules.mdx b/versions/8.6.0/extending/rules.mdx
index 1ab25d37..c83bd4a2 100644
--- a/versions/8.6.0/extending/rules.mdx
+++ b/versions/8.6.0/extending/rules.mdx
@@ -449,8 +449,7 @@ def _example_library_impl(ctx):
 
 If `DefaultInfo` is not returned by a rule implementation or the `files`
 parameter is not specified, `DefaultInfo.files` defaults to all
-*predeclared outputs* (generally, those created by [output
-attributes](#output_attributes)).
+*predeclared outputs* (generally, those created by [output attributes](#output_attributes)).
 
 Rules that perform actions should provide default outputs, even if those outputs
 are not expected to be directly used. Actions that are not in the graph of the
@@ -995,8 +994,7 @@ By using `configuration_field`, the dependency on the Java LCOV merger tool can
 be avoided as long as coverage is not requested.
 
 When the test is run, it should emit coverage information in the form of one or
-more [LCOV files]
-(https://manpages.debian.org/unstable/lcov/geninfo.1.en.html#TRACEFILE_FORMAT)
+more [LCOV files](https://manpages.debian.org/unstable/lcov/geninfo.1.en.html#TRACEFILE_FORMAT)
 with unique names into the directory specified by the `COVERAGE_DIR` environment
 variable. Bazel will then merge these files into a single LCOV file using the
 `_lcov_merger` tool. If present, it will also collect C/C++ coverage using the
diff --git a/versions/8.6.0/extending/toolchains.mdx b/versions/8.6.0/extending/toolchains.mdx
index 3ba5fb83..3bc96e5b 100644
--- a/versions/8.6.0/extending/toolchains.mdx
+++ b/versions/8.6.0/extending/toolchains.mdx
@@ -523,8 +523,7 @@ The set of available toolchains, in priority order, is created from
   4. Toolchains registered in the "WORKSPACE suffix"; this is only used by
      certain native rules bundled with the Bazel installation.
 
-**NOTE:** [Pseudo-targets like `:all`, `:*`, and
-`/...`](/versions/8.6.0/run/build#specifying-build-targets) are ordered by Bazel's package
+**NOTE:** [Pseudo-targets like `:all`, `:*`, and `/...`](/versions/8.6.0/run/build#specifying-build-targets) are ordered by Bazel's package
 loading mechanism, which uses a lexicographic ordering.
 
 The resolution steps are as follows.
diff --git a/versions/8.6.0/external/advanced.mdx b/versions/8.6.0/external/advanced.mdx
index 66b4d2f5..d7166333 100644
--- a/versions/8.6.0/external/advanced.mdx
+++ b/versions/8.6.0/external/advanced.mdx
@@ -4,10 +4,8 @@ title: 'Advanced topics on external dependencies'
 
 ## Shadowing dependencies in WORKSPACE
 
-Note: This section applies to the [WORKSPACE
-system](/versions/8.6.0/external/overview#workspace-system) only. For
-[Bzlmod](/versions/8.6.0/external/overview#bzlmod), use a [multiple-version
-override](/versions/8.6.0/external/module#multiple-version_override).
+Note: This section applies to the [WORKSPACE system](/versions/8.6.0/external/overview#workspace-system) only. For
+[Bzlmod](/versions/8.6.0/external/overview#bzlmod), use a [multiple-version override](/versions/8.6.0/external/module#multiple-version_override).
 
 Whenever possible, have a single version policy in your project, which is
 required for dependencies that you compile against and end up in your final
@@ -128,29 +126,24 @@ preferring IPv4 if enabled. In some situations, for example when the IPv4
 network cannot resolve/reach external addresses, this can cause `Network
 unreachable` exceptions and build failures. In these cases, you can override
 Bazel's behavior to prefer IPv6 by using the
-[`java.net.preferIPv6Addresses=true` system
-property](https://docs.oracle.com/javase/8/docs/api/java/net/doc-files/net-properties.html).
+[`java.net.preferIPv6Addresses=true` system property](https://docs.oracle.com/javase/8/docs/api/java/net/doc-files/net-properties.html).
 Specifically:
 
-*   Use `--host_jvm_args=-Djava.net.preferIPv6Addresses=true` [startup
-    option](/versions/8.6.0/docs/user-manual#startup-options), for example by adding the
+*   Use `--host_jvm_args=-Djava.net.preferIPv6Addresses=true` [startup option](/versions/8.6.0/docs/user-manual#startup-options), for example by adding the
     following line in your [`.bazelrc` file](/versions/8.6.0/run/bazelrc):
 
     `startup --host_jvm_args=-Djava.net.preferIPv6Addresses=true`
 
 *   When running Java build targets that need to connect to the internet (such
     as for integration tests), use the
-    `--jvmopt=-Djava.net.preferIPv6Addresses=true` [tool
-    flag](/versions/8.6.0/docs/user-manual#jvmopt). For example, include in your [`.bazelrc`
-    file](/versions/8.6.0/run/bazelrc):
+    `--jvmopt=-Djava.net.preferIPv6Addresses=true` [tool flag](/versions/8.6.0/docs/user-manual#jvmopt). For example, include in your [`.bazelrc` file](/versions/8.6.0/run/bazelrc):
 
     `build --jvmopt=-Djava.net.preferIPv6Addresses`
 
 *   If you are using [`rules_jvm_external`](https://github.com/bazelbuild/rules_jvm_external)
     for dependency version resolution, also add
     `-Djava.net.preferIPv6Addresses=true` to the `COURSIER_OPTS` environment
-    variable to [provide JVM options for
-    Coursier](https://github.com/bazelbuild/rules_jvm_external#provide-jvm-options-for-coursier-with-coursier_opts).
+    variable to [provide JVM options for Coursier](https://github.com/bazelbuild/rules_jvm_external#provide-jvm-options-for-coursier-with-coursier_opts).
 
 ## Offline builds
 
@@ -167,15 +160,12 @@ fetch a file with [`ctx.download`](/versions/8.6.0/rules/lib/builtins/repository
 providing a hash sum of the file needed, Bazel looks for a file matching the
 basename of the first URL, and uses the local copy if the hash matches.
 
-Bazel itself uses this technique to bootstrap offline from the [distribution
-artifact](https://github.com/bazelbuild/bazel-website/blob/master/designs/_posts/2016-10-11-distribution-artifact.md).
-It does so by [collecting all the needed external
-dependencies](https://github.com/bazelbuild/bazel/blob/5cfa0303d6ac3b5bd031ff60272ce80a704af8c2/WORKSPACE#L116)
+Bazel itself uses this technique to bootstrap offline from the [distribution artifact](https://github.com/bazelbuild/bazel-website/blob/master/designs/_posts/2016-10-11-distribution-artifact.md).
+It does so by [collecting all the needed external dependencies](https://github.com/bazelbuild/bazel/blob/5cfa0303d6ac3b5bd031ff60272ce80a704af8c2/WORKSPACE#L116)
 in an internal
 [`distdir_tar`](https://github.com/bazelbuild/bazel/blob/5cfa0303d6ac3b5bd031ff60272ce80a704af8c2/distdir.bzl#L44).
 
 Bazel allows execution of arbitrary commands in repository rules without knowing
 if they call out to the network, and so cannot enforce fully offline builds. To
 test if a build works correctly offline, manually block off the network (as
-Bazel does in its [bootstrap
-test](https://cs.opensource.google/bazel/bazel/+/master:src/test/shell/bazel/BUILD;l=1073;drc=88c426e73cc0eb0a41c0d7995e36acd94e7c9a48)).
\ No newline at end of file
+Bazel does in its [bootstrap test](https://cs.opensource.google/bazel/bazel/+/master:src/test/shell/bazel/BUILD;l=1073;drc=88c426e73cc0eb0a41c0d7995e36acd94e7c9a48)).
\ No newline at end of file
diff --git a/versions/8.6.0/external/images/mod_exampleBefore.svg b/versions/8.6.0/external/images/mod_exampleBefore.svg
new file mode 100644
index 00000000..66f01303
--- /dev/null
+++ b/versions/8.6.0/external/images/mod_exampleBefore.svg
@@ -0,0 +1,175 @@
+
+
+
+
+
+
+mygraph
+
+
+
+<root>
+
+<root> (my_project@1.0)
+
+
+
+bazel_skylib@1.1.1
+
+bazel_skylib@1.1.1
+
+
+
+<root>->bazel_skylib@1.1.1
+
+
+
+
+
+bazel_skylib@1.2.0
+
+bazel_skylib@1.2.0
+
+
+
+<root>->bazel_skylib@1.2.0
+
+
+
+
+
+rules_java@5.0.0
+
+rules_java@5.0.0
+
+
+
+<root>->rules_java@5.0.0
+
+
+
+
+
+stardoc@0.5.0
+
+stardoc@0.5.0
+
+
+
+<root>->stardoc@0.5.0
+
+
+
+
+
+platforms@0.0.4
+
+platforms@0.0.4
+
+
+
+bazel_skylib@1.1.1->platforms@0.0.4
+
+
+
+
+
+bazel_skylib@1.2.0->platforms@0.0.4
+
+
+
+
+
+rules_java@5.0.0->platforms@0.0.4
+
+
+
+
+
+rules_cc@0.0.1
+
+rules_cc@0.0.1
+
+
+
+rules_java@5.0.0->rules_cc@0.0.1
+
+
+
+
+
+rules_proto@4.0.0
+
+rules_proto@4.0.0
+
+
+
+rules_java@5.0.0->rules_proto@4.0.0
+
+
+
+
+
+bazel_skylib@1.0.3
+
+bazel_skylib@1.0.3
+
+
+
+stardoc@0.5.0->bazel_skylib@1.0.3
+
+
+
+
+
+rules_java@4.0.0
+
+rules_java@4.0.0
+
+
+
+stardoc@0.5.0->rules_java@4.0.0
+
+
+
+
+
+rules_cc@0.0.1->platforms@0.0.4
+
+
+
+
+
+rules_cc@0.0.1->bazel_skylib@1.0.3
+
+
+
+
+
+rules_proto@4.0.0->rules_cc@0.0.1
+
+
+
+
+
+rules_proto@4.0.0->bazel_skylib@1.0.3
+
+
+
+
+
+bazel_skylib@1.0.3->platforms@0.0.4
+
+
+
+
+
+rules_java@4.0.0->bazel_skylib@1.0.3
+
+
+
+
+
\ No newline at end of file
diff --git a/versions/8.6.0/external/images/mod_exampleResolved.svg b/versions/8.6.0/external/images/mod_exampleResolved.svg
new file mode 100644
index 00000000..224b694c
--- /dev/null
+++ b/versions/8.6.0/external/images/mod_exampleResolved.svg
@@ -0,0 +1,151 @@
+
+
+
+
+
+
+mygraph
+
+
+
+<root>
+
+<root> (my_project@1.0)
+
+
+
+bazel_skylib@1.1.1
+
+bazel_skylib@1.1.1
+
+
+
+<root>->bazel_skylib@1.1.1
+
+
+
+
+
+bazel_skylib@1.2.0
+
+bazel_skylib@1.2.0
+
+
+
+<root>->bazel_skylib@1.2.0
+
+
+
+
+
+rules_java@5.0.0
+
+rules_java@5.0.0
+
+
+
+<root>->rules_java@5.0.0
+
+
+
+
+
+stardoc@0.5.0
+
+stardoc@0.5.0
+
+
+
+<root>->stardoc@0.5.0
+
+
+
+
+
+platforms@0.0.4
+
+platforms@0.0.4
+
+
+
+bazel_skylib@1.1.1->platforms@0.0.4
+
+
+
+
+
+bazel_skylib@1.2.0->platforms@0.0.4
+
+
+
+
+
+rules_java@5.0.0->platforms@0.0.4
+
+
+
+
+
+rules_cc@0.0.1
+
+rules_cc@0.0.1
+
+
+
+rules_java@5.0.0->rules_cc@0.0.1
+
+
+
+
+
+rules_proto@4.0.0
+
+rules_proto@4.0.0
+
+
+
+rules_java@5.0.0->rules_proto@4.0.0
+
+
+
+
+
+stardoc@0.5.0->bazel_skylib@1.1.1
+
+
+
+
+
+stardoc@0.5.0->rules_java@5.0.0
+
+
+
+
+
+rules_cc@0.0.1->bazel_skylib@1.1.1
+
+
+
+
+
+rules_cc@0.0.1->platforms@0.0.4
+
+
+
+
+
+rules_proto@4.0.0->bazel_skylib@1.1.1
+
+
+
+
+
+rules_proto@4.0.0->rules_cc@0.0.1
+
+
+
+
+
\ No newline at end of file
diff --git a/versions/8.6.0/external/migration.mdx b/versions/8.6.0/external/migration.mdx
index 030c4f0f..dc775214 100644
--- a/versions/8.6.0/external/migration.mdx
+++ b/versions/8.6.0/external/migration.mdx
@@ -4,8 +4,7 @@ keywords: bzlmod
 title: 'Bzlmod Migration Guide'
 ---
 
-Due to the [shortcomings of
-WORKSPACE](/versions/8.6.0/external/overview#workspace-shortcomings), Bzlmod is going to
+Due to the [shortcomings of WORKSPACE](/versions/8.6.0/external/overview#workspace-shortcomings), Bzlmod is going to
 replace the legacy WORKSPACE system. The WORKSPACE file will be disabled by
 default in Bazel 8 (late 2024) and will be removed in Bazel 9 (late 2025).
 This guide helps you migrate your project to Bzlmod and drop WORKSPACE for
@@ -119,9 +118,7 @@ Bazel module when it also adopts Bzlmod.
 
 *   **Bzlmod**
 
-    With Bzlmod, as long as the your dependency is available in [Bazel Central
-    Registry](https://registry.bazel.build) or your custom [Bazel
-    registry](/versions/8.6.0/external/registry), you can simply depend on it with a
+    With Bzlmod, as long as the your dependency is available in [Bazel Central Registry](https://registry.bazel.build) or your custom [Bazel registry](/versions/8.6.0/external/registry), you can simply depend on it with a
     [`bazel_dep`](/versions/8.6.0/rules/lib/globals/module#bazel_dep) directive.
 
     ```python
@@ -152,8 +149,7 @@ repository.
 
 If your dependency is not a Bazel project or not yet available in any Bazel
 registry, you can introduce it using
-[`use_repo_rule`](/versions/8.6.0/external/module#use_repo_rule) or [module
-extensions](/versions/8.6.0/external/extension).
+[`use_repo_rule`](/versions/8.6.0/external/module#use_repo_rule) or [module extensions](/versions/8.6.0/external/extension).
 
 *   **WORKSPACE**
 
@@ -606,8 +602,7 @@ macros.
 Fortunately, the flag
 [`--experimental_repository_resolved_file`][resolved_file_flag]
 can help. This flag essentially generates a "lock file" of all fetched external
-dependencies in your last Bazel command. You can find more details in this [blog
-post](https://blog.bazel.build/2018/07/09/bazel-sync-and-resolved-file.html).
+dependencies in your last Bazel command. You can find more details in this [blog post](https://blog.bazel.build/2018/07/09/bazel-sync-and-resolved-file.html).
 
 [resolved_file_flag]: /reference/command-line-reference#flag--experimental_repository_resolved_file
 
@@ -648,11 +643,9 @@ You may also know `bazel query` can be used for inspecting repository rules with
 bazel query --output=build //external:
 ```
 
-While it is more convenient and much faster, [bazel query can lie about
-external dependency version](https://github.com/bazelbuild/bazel/issues/12947),
+While it is more convenient and much faster, [bazel query can lie about external dependency version](https://github.com/bazelbuild/bazel/issues/12947),
 so be careful using it! Querying and inspecting external
-dependencies with Bzlmod is going to achieved by a [new
-subcommand](https://github.com/bazelbuild/bazel/issues/15365).
+dependencies with Bzlmod is going to achieved by a [new subcommand](https://github.com/bazelbuild/bazel/issues/15365).
 
 #### Built-in default dependencies
 
@@ -699,8 +692,7 @@ Using the WORKSPACE.bzlmod file can make the migration easier because:
 #### Repository visibility
 
 Bzlmod is able to control which other repositories are visible from a given
-repository, check [repository names and strict
-deps](/versions/8.6.0/external/module#repository_names_and_strict_deps) for more details.
+repository, check [repository names and strict deps](/versions/8.6.0/external/module#repository_names_and_strict_deps) for more details.
 
 Here is a summary of repository visibilities from different types of
 repositories when also taking WORKSPACE into consideration.
@@ -713,8 +705,7 @@ repositories when also taking WORKSPACE into consideration.
 | WORKSPACE Repos | All visible | Not visible | Not visible | All visible |
 
 Note: For the root module, if a repository `@foo` is defined in WORKSPACE and
-`@foo` is also used as an [apparent repository
-name](/versions/8.6.0/external/overview#apparent-repo-name) in MODULE.bazel, then `@foo`
+`@foo` is also used as an [apparent repository name](/versions/8.6.0/external/overview#apparent-repo-name) in MODULE.bazel, then `@foo`
 refers to the one introduced in MODULE.bazel.
 
 Note: For a module extension generated repository `@bar`, if `@foo` is used as
@@ -789,9 +780,7 @@ the project. Take note of a few things when creating the source archive:
     GitHub isn't going to guarantee the checksum of source archives generated on
     demand. In short, URLs in the form of
     `https://github.com///releases/download/...` is considered stable
-    while `https://github.com///archive/...` is not. Check [GitHub
-    Archive Checksum
-    Outage](https://blog.bazel.build/2023/02/15/github-archive-checksum.html)
+    while `https://github.com///archive/...` is not. Check [GitHub Archive Checksum Outage](https://blog.bazel.build/2023/02/15/github-archive-checksum.html)
     for more context.
 
 *   **Make sure the source tree follows the layout of the original repository.**
@@ -820,8 +809,7 @@ Pull Request.
 
 [bcr_contrib_guide]: https://github.com/bazelbuild/bazel-central-registry/tree/main/docs#contribute-a-bazel-module
 
-It is **highly recommended** to set up the [Publish to
-BCR](https://github.com/bazel-contrib/publish-to-bcr) GitHub App for your
+It is **highly recommended** to set up the [Publish to BCR](https://github.com/bazel-contrib/publish-to-bcr) GitHub App for your
 repository to automate the process of submitting your module to the BCR.
 
 ## Best practices
diff --git a/versions/8.6.0/external/mod-command.mdx b/versions/8.6.0/external/mod-command.mdx
index 0effacfc..861ede54 100644
--- a/versions/8.6.0/external/mod-command.mdx
+++ b/versions/8.6.0/external/mod-command.mdx
@@ -64,11 +64,9 @@ The available subcommands and their respective required arguments are:
 
 *   ``: All present versions of the module ``.
 
-*   `@`: The repo with the given [apparent
-    name](overview#apparent-repo-name) in the context of the `--base_module`.
+*   `@`: The repo with the given [apparent name](/versions/8.6.0/external/overview#apparent-repo-name) in the context of the `--base_module`.
 
-*   `@@`: The repo with the given [canonical
-    name](overview#canonical-repo-name).
+*   `@@`: The repo with the given [canonical name](/versions/8.6.0/external/overview#canonical-repo-name).
 
 In a context requiring specifying modules, ``s referring to repos that
 correspond to modules (as opposed to extension-generated repos) can also be
@@ -92,8 +90,7 @@ The following options only affect the subcommands that print graphs (`graph`,
     information about the version resolution of each module. If the module
     version changed during resolution, show either which version replaced it or
     what was the original version, the reason it was replaced, and which modules
-    requested the new version if the reason was [Minimal Version
-    Selection](module#version-selection).
+    requested the new version if the reason was [Minimal Version Selection](/versions/8.6.0/external/module#version-selection).
 
 *   `--include_unused` *default: "false"*: Include in the output graph the
     modules which were originally present in the dependency graph, but became
@@ -168,16 +165,13 @@ The following options only affect the subcommands that print graphs (`graph`,
     *   `text` *(default)*: Display repository definitions in Starlark.
 
     *   `streamed_proto`: Prints a
-        [length-delimited](https://protobuf.dev/programming-guides/encoding/#siz
-        e-limit)
+        [length-delimited](https://protobuf.dev/programming-guides/encoding/#siz e-limit)
         stream of
-        [`Repository`](https://github.com/bazelbuild/bazel/blob/master/src/main/
-        protobuf/build.proto)
+        [`Repository`](https://github.com/bazelbuild/bazel/blob/master/src/main/ protobuf/build.proto)
         protocol buffers.
 
     *   `streamed_jsonproto`: Similar to `--output streamed_proto`, prints a
-        stream of [`Repository`](https://github.com/bazelbuild/bazel/blob/master
-        /src/main/protobuf/build.proto)
+        stream of [`Repository`](https://github.com/bazelbuild/bazel/blob/master /src/main/protobuf/build.proto)
         protocol buffers but in [NDJSON](https://github.com/ndjson/ndjson-spec)
         format.
 
diff --git a/versions/8.6.0/external/module.mdx b/versions/8.6.0/external/module.mdx
index 2466763e..ef6c6c57 100644
--- a/versions/8.6.0/external/module.mdx
+++ b/versions/8.6.0/external/module.mdx
@@ -105,8 +105,7 @@ serves multiple purposes:
     version, regardless of which versions of the dependency are requested in the
     dependency graph.
 *   With the `registry` attribute, you can force this dependency to come from a
-    specific registry, instead of following the normal [registry
-    selection](/versions/8.6.0/external/registry#selecting_registries) process.
+    specific registry, instead of following the normal [registry selection](/versions/8.6.0/external/registry#selecting_registries) process.
 *   With the `patch*` attributes, you can specify a set of patches to apply to
     the downloaded module.
 
@@ -151,13 +150,11 @@ With `bazel_dep`, you can define repos that represent other Bazel modules.
 Sometimes there is a need to define a repo that does _not_ represent a Bazel
 module; for example, one that contains a plain JSON file to be read as data.
 
-In this case, you could use the [`use_repo_rule`
-directive](/versions/8.6.0/rules/lib/globals/module#use_repo_rule) to directly define a repo
+In this case, you could use the [`use_repo_rule` directive](/versions/8.6.0/rules/lib/globals/module#use_repo_rule) to directly define a repo
 by invoking a repo rule. This repo will only be visible to the module it's
 defined in.
 
-Under the hood, this is implemented using the same mechanism as [module
-extensions](/versions/8.6.0/external/extension), which lets you define repos with more
+Under the hood, this is implemented using the same mechanism as [module extensions](/versions/8.6.0/external/extension), which lets you define repos with more
 flexibility.
 
 ## Repository names and strict deps
diff --git a/versions/8.6.0/external/overview.mdx b/versions/8.6.0/external/overview.mdx
index 2ef7a821..d6b1f241 100644
--- a/versions/8.6.0/external/overview.mdx
+++ b/versions/8.6.0/external/overview.mdx
@@ -128,8 +128,7 @@ for all build targets inside the repo.
 
 The syntax of a `REPO.bazel` file is similar to `BUILD` files, except that no
 `load` statements are supported, and only a single function, `repo()`, is
-available. `repo()` takes the same arguments as the [`package()`
-function](/versions/8.6.0/reference/be/functions#package) in `BUILD` files; whereas `package()`
+available. `repo()` takes the same arguments as the [`package()` function](/versions/8.6.0/reference/be/functions#package) in `BUILD` files; whereas `package()`
 specifies common attributes for all build targets inside the package, `repo()`
 analogously does so for all build targets inside the repo.
 
@@ -163,8 +162,7 @@ bazel_dep(name = "protobuf", version = "3.19.0")
 ```
 
 A module must only list its direct dependencies, which Bzlmod looks up in a
-[Bazel registry](/versions/8.6.0/external/registry) — by default, the [Bazel Central
-Registry](https://bcr.bazel.build/). The registry provides the
+[Bazel registry](/versions/8.6.0/external/registry) — by default, the [Bazel Central Registry](https://bcr.bazel.build/). The registry provides the
 dependencies' `MODULE.bazel` files, which allows Bazel to discover the entire
 transitive dependency graph before performing version resolution.
 
@@ -235,5 +233,4 @@ many pain points, including:
         `B` and `C`; `B` and `C` both depend on different versions of `D`).
 
 Due to the shortcomings of WORKSPACE, Bzlmod is going to replace the legacy
-WORKSPACE system in future Bazel releases. Please read the [Bzlmod migration
-guide](/versions/8.6.0/external/migration) on how to migrate to Bzlmod.
+WORKSPACE system in future Bazel releases. Please read the [Bzlmod migration guide](/versions/8.6.0/external/migration) on how to migrate to Bzlmod.
diff --git a/versions/8.6.0/external/registry.mdx b/versions/8.6.0/external/registry.mdx
index d31b2f8d..811146e1 100644
--- a/versions/8.6.0/external/registry.mdx
+++ b/versions/8.6.0/external/registry.mdx
@@ -42,8 +42,7 @@ An index registry must follow the format below:
             project
         *   `versions`: A list of all the versions of this module to be found in
             this registry
-        *   `yanked_versions`: A map of [*yanked*
-            versions](/versions/8.6.0/external/module#yanked_versions) of this module. The keys
+        *   `yanked_versions`: A map of [*yanked* versions](/versions/8.6.0/external/module#yanked_versions) of this module. The keys
             should be versions to yank and the values should be descriptions of
             why the version is yanked, ideally containing a link to more
             information
@@ -56,8 +55,7 @@ An index registry must follow the format below:
             *   `url`: The URL of the source archive
             *   `mirror_urls`: A list of string, the mirror URLs of the source archive.
                 The URLs are tried in order after `url` as backups.
-            *   `integrity`: The [Subresource
-                Integrity](https://w3c.github.io/webappsec-subresource-integrity/#integrity-metadata-description)
+            *   `integrity`: The [Subresource Integrity](https://w3c.github.io/webappsec-subresource-integrity/#integrity-metadata-description)
                 checksum of the archive
             *   `strip_prefix`: A directory prefix to strip when extracting the
                 source archive
@@ -105,8 +103,7 @@ You can browse its contents using the web frontend at
 ``.
 
 The Bazel community maintains the BCR, and contributors are welcome to submit
-pull requests. See the [BCR contribution
-guidelines](https://github.com/bazelbuild/bazel-central-registry/blob/main/docs/README.md).
+pull requests. See the [BCR contribution guidelines](https://github.com/bazelbuild/bazel-central-registry/blob/main/docs/README.md).
 
 In addition to following the format of a normal index registry, the BCR requires
 a `presubmit.yml` file for each module version
diff --git a/versions/8.6.0/external/vendor.mdx b/versions/8.6.0/external/vendor.mdx
index 00a54a81..2f5a1c52 100644
--- a/versions/8.6.0/external/vendor.mdx
+++ b/versions/8.6.0/external/vendor.mdx
@@ -23,9 +23,7 @@ absolute path.
 ## Vendor a specific external repository
 
 You can use the `vendor` command with the `--repo` flag to specify which repo
-to vendor, it accepts both [canonical repo
-name](/versions/8.6.0/external/overview#canonical-repo-name) and [apparent repo
-name](/versions/8.6.0/external/overview#apparent-repo-name).
+to vendor, it accepts both [canonical repo name](/versions/8.6.0/external/overview#canonical-repo-name) and [apparent repo name](/versions/8.6.0/external/overview#apparent-repo-name).
 
 For example, running:
 
diff --git a/versions/8.6.0/help.mdx b/versions/8.6.0/help.mdx
index 59095ff1..1a49798f 100644
--- a/versions/8.6.0/help.mdx
+++ b/versions/8.6.0/help.mdx
@@ -46,5 +46,4 @@ what level of support Bazel provides.
 
 ## File a bug
 
-If you encounter a bug or want to request a feature, file a [GitHub
-Issue](https://github.com/bazelbuild/bazel/issues).
+If you encounter a bug or want to request a feature, file a [GitHub Issue](https://github.com/bazelbuild/bazel/issues).
diff --git a/versions/8.6.0/images/about.svg b/versions/8.6.0/images/about.svg
new file mode 100644
index 00000000..f927298f
--- /dev/null
+++ b/versions/8.6.0/images/about.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/8.6.0/images/basics.svg b/versions/8.6.0/images/basics.svg
new file mode 100644
index 00000000..013ec519
--- /dev/null
+++ b/versions/8.6.0/images/basics.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/8.6.0/images/bazel_hero.svg b/versions/8.6.0/images/bazel_hero.svg
new file mode 100644
index 00000000..c48714d0
--- /dev/null
+++ b/versions/8.6.0/images/bazel_hero.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/8.6.0/images/community.svg b/versions/8.6.0/images/community.svg
new file mode 100644
index 00000000..29f87a76
--- /dev/null
+++ b/versions/8.6.0/images/community.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/8.6.0/images/distributed-build-remote-cache.png b/versions/8.6.0/images/distributed-build-remote-cache.png
new file mode 100644
index 00000000..99d8a915
Binary files /dev/null and b/versions/8.6.0/images/distributed-build-remote-cache.png differ
diff --git a/versions/8.6.0/images/essential_guide.svg b/versions/8.6.0/images/essential_guide.svg
new file mode 100644
index 00000000..4ee63ae9
--- /dev/null
+++ b/versions/8.6.0/images/essential_guide.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/8.6.0/images/essential_reference.svg b/versions/8.6.0/images/essential_reference.svg
new file mode 100644
index 00000000..4d29a8d5
--- /dev/null
+++ b/versions/8.6.0/images/essential_reference.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/8.6.0/images/essential_start.svg b/versions/8.6.0/images/essential_start.svg
new file mode 100644
index 00000000..c8f48f84
--- /dev/null
+++ b/versions/8.6.0/images/essential_start.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/8.6.0/images/extend.svg b/versions/8.6.0/images/extend.svg
new file mode 100644
index 00000000..77b2dd97
--- /dev/null
+++ b/versions/8.6.0/images/extend.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/8.6.0/images/guide.svg b/versions/8.6.0/images/guide.svg
new file mode 100644
index 00000000..23a5d35a
--- /dev/null
+++ b/versions/8.6.0/images/guide.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/8.6.0/images/high-level-build-system.png b/versions/8.6.0/images/high-level-build-system.png
new file mode 100644
index 00000000..462717fa
Binary files /dev/null and b/versions/8.6.0/images/high-level-build-system.png differ
diff --git a/versions/8.6.0/images/new_1.svg b/versions/8.6.0/images/new_1.svg
new file mode 100644
index 00000000..c4cd9dfd
--- /dev/null
+++ b/versions/8.6.0/images/new_1.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/8.6.0/images/new_2.svg b/versions/8.6.0/images/new_2.svg
new file mode 100644
index 00000000..c6b7021b
--- /dev/null
+++ b/versions/8.6.0/images/new_2.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/8.6.0/images/new_3.svg b/versions/8.6.0/images/new_3.svg
new file mode 100644
index 00000000..c2afb4ac
--- /dev/null
+++ b/versions/8.6.0/images/new_3.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/8.6.0/images/placeholder.png b/versions/8.6.0/images/placeholder.png
new file mode 100644
index 00000000..54f1fa0e
Binary files /dev/null and b/versions/8.6.0/images/placeholder.png differ
diff --git a/versions/8.6.0/images/reference.svg b/versions/8.6.0/images/reference.svg
new file mode 100644
index 00000000..7bbc9bea
--- /dev/null
+++ b/versions/8.6.0/images/reference.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/8.6.0/images/release_notes.svg b/versions/8.6.0/images/release_notes.svg
new file mode 100644
index 00000000..8a2e8b56
--- /dev/null
+++ b/versions/8.6.0/images/release_notes.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/8.6.0/images/remote-execution-system.png b/versions/8.6.0/images/remote-execution-system.png
new file mode 100644
index 00000000..8152fc0c
Binary files /dev/null and b/versions/8.6.0/images/remote-execution-system.png differ
diff --git a/versions/8.6.0/images/start.svg b/versions/8.6.0/images/start.svg
new file mode 100644
index 00000000..3bcebd7b
--- /dev/null
+++ b/versions/8.6.0/images/start.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/8.6.0/images/task-dependencies.png b/versions/8.6.0/images/task-dependencies.png
new file mode 100644
index 00000000..ae1f9c51
Binary files /dev/null and b/versions/8.6.0/images/task-dependencies.png differ
diff --git a/versions/8.6.0/images/test.png b/versions/8.6.0/images/test.png
new file mode 100644
index 00000000..243939da
Binary files /dev/null and b/versions/8.6.0/images/test.png differ
diff --git a/versions/8.6.0/images/transitive-dependencies.png b/versions/8.6.0/images/transitive-dependencies.png
new file mode 100644
index 00000000..ec641a08
Binary files /dev/null and b/versions/8.6.0/images/transitive-dependencies.png differ
diff --git a/versions/8.6.0/images/trunk-logo-dark.svg b/versions/8.6.0/images/trunk-logo-dark.svg
new file mode 100644
index 00000000..f25940af
--- /dev/null
+++ b/versions/8.6.0/images/trunk-logo-dark.svg
@@ -0,0 +1,22 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/versions/8.6.0/images/why_faq.svg b/versions/8.6.0/images/why_faq.svg
new file mode 100644
index 00000000..afec3f8f
--- /dev/null
+++ b/versions/8.6.0/images/why_faq.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/8.6.0/images/why_overview.svg b/versions/8.6.0/images/why_overview.svg
new file mode 100644
index 00000000..c10c363c
--- /dev/null
+++ b/versions/8.6.0/images/why_overview.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/8.6.0/images/why_vision.svg b/versions/8.6.0/images/why_vision.svg
new file mode 100644
index 00000000..739e415f
--- /dev/null
+++ b/versions/8.6.0/images/why_vision.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/8.6.0/install/bazelisk.mdx b/versions/8.6.0/install/bazelisk.mdx
index 551992ba..0adb4419 100644
--- a/versions/8.6.0/install/bazelisk.mdx
+++ b/versions/8.6.0/install/bazelisk.mdx
@@ -16,8 +16,7 @@ For more details, see
 ## Updating Bazel
 
 Bazel has a [backward compatibility policy](/versions/8.6.0/release/backward-compatibility)
-(see [guidance for rolling out incompatible
-changes](/versions/8.6.0/contribute/breaking-changes) if you
+(see [guidance for rolling out incompatible changes](/versions/8.6.0/contribute/breaking-changes) if you
 are the author of one). That page summarizes best practices on how to test and
 migrate your project with upcoming incompatible changes and how to provide
 feedback to the incompatible change authors.
diff --git a/versions/8.6.0/install/compile-source.mdx b/versions/8.6.0/install/compile-source.mdx
index c634a2ae..dbfc76db 100644
--- a/versions/8.6.0/install/compile-source.mdx
+++ b/versions/8.6.0/install/compile-source.mdx
@@ -45,8 +45,7 @@ it by typing `bazel` in a terminal.
 
 **Reason**: To build Bazel from a GitHub source tree, you need a pre-existing
 Bazel binary. You can install one from a package manager or download one from
-GitHub. See [Installing Bazel](/versions/8.6.0/install). (Or you can [build from
-scratch (bootstrap)](#bootstrap-bazel).)
+GitHub. See [Installing Bazel](/versions/8.6.0/install). (Or you can [build from scratch (bootstrap)](#bootstrap-bazel).)
 
 **Troubleshooting**:
 
@@ -239,8 +238,7 @@ For instructions for Unix-like systems, see
     ```
 
 *   **The Visual C++ compiler.** Install the Visual C++ compiler either as part
-    of Visual Studio 2015 or newer, or by installing the latest [Build Tools
-    for Visual Studio 2017](https://aka.ms/BuildTools).
+    of Visual Studio 2015 or newer, or by installing the latest [Build Tools for Visual Studio 2017](https://aka.ms/BuildTools).
 
 *   **JDK.** Version 21 is required.
 
diff --git a/versions/8.6.0/install/ide.mdx b/versions/8.6.0/install/ide.mdx
index b86f351c..bd456354 100644
--- a/versions/8.6.0/install/ide.mdx
+++ b/versions/8.6.0/install/ide.mdx
@@ -38,10 +38,8 @@ To install, go to the IDE's plugin browser and search for `Bazel`.
 To manually install older versions, download the zip files from JetBrains'
 Plugin Repository and install the zip file from the IDE's plugin browser:
 
-*  [Android Studio
-   plugin](https://plugins.jetbrains.com/plugin/9185-android-studio-with-bazel)
-*  [IntelliJ
-   plugin](https://plugins.jetbrains.com/plugin/8609-intellij-with-bazel)
+*  [Android Studio plugin](https://plugins.jetbrains.com/plugin/9185-android-studio-with-bazel)
+*  [IntelliJ plugin](https://plugins.jetbrains.com/plugin/8609-intellij-with-bazel)
 *  [CLion plugin](https://plugins.jetbrains.com/plugin/9554-clion-with-bazel)
 
 ### Xcode
@@ -61,8 +59,7 @@ Features:
 * Starlark debugger for `.bzl` files during a build (set breakpoints, step
   through code, inspect variables, and so on)
 
-Find [the plugin on the Visual Studio
-marketplace](https://marketplace.visualstudio.com/items?itemName=BazelBuild.vscode-bazel).
+Find [the plugin on the Visual Studio marketplace](https://marketplace.visualstudio.com/items?itemName=BazelBuild.vscode-bazel).
 The plugin is [open source](https://github.com/bazelbuild/vscode-bazel).
 
 See also: [Autocomplete for Source Code](#autocomplete-for-source-code)
@@ -82,8 +79,7 @@ See also: [Autocomplete for Source Code](#autocomplete-for-source-code)
 
 ### Emacs
 
-See [`bazelbuild/bazel-emacs-mode` on
-GitHub](https://github.com/bazelbuild/emacs-bazel-mode)
+See [`bazelbuild/bazel-emacs-mode` on GitHub](https://github.com/bazelbuild/emacs-bazel-mode)
 
 See also: [Autocomplete for Source Code](#autocomplete-for-source-code)
 
@@ -115,6 +111,5 @@ tool for building Bazel targets when source files change.
 
 ## Building your own IDE plugin
 
-Read the [**IDE support** blog
-post](https://blog.bazel.build/2016/06/10/ide-support.html) to learn more about
+Read the [**IDE support** blog post](https://blog.bazel.build/2016/06/10/ide-support.html) to learn more about
 the Bazel APIs to use when building an IDE plugin.
diff --git a/versions/8.6.0/install/images/bazelisk.svg b/versions/8.6.0/install/images/bazelisk.svg
new file mode 100644
index 00000000..c0ae9f54
--- /dev/null
+++ b/versions/8.6.0/install/images/bazelisk.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/8.6.0/install/images/cli.svg b/versions/8.6.0/install/images/cli.svg
new file mode 100644
index 00000000..01119280
--- /dev/null
+++ b/versions/8.6.0/install/images/cli.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/8.6.0/install/images/docker.svg b/versions/8.6.0/install/images/docker.svg
new file mode 100644
index 00000000..21190ce0
--- /dev/null
+++ b/versions/8.6.0/install/images/docker.svg
@@ -0,0 +1,6 @@
+
\ No newline at end of file
diff --git a/versions/8.6.0/install/images/github.svg b/versions/8.6.0/install/images/github.svg
new file mode 100644
index 00000000..aa05db9c
--- /dev/null
+++ b/versions/8.6.0/install/images/github.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/8.6.0/install/images/install.svg b/versions/8.6.0/install/images/install.svg
new file mode 100644
index 00000000..ae080865
--- /dev/null
+++ b/versions/8.6.0/install/images/install.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/8.6.0/install/images/mac.svg b/versions/8.6.0/install/images/mac.svg
new file mode 100644
index 00000000..3ee4fe28
--- /dev/null
+++ b/versions/8.6.0/install/images/mac.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/8.6.0/install/images/redhat.svg b/versions/8.6.0/install/images/redhat.svg
new file mode 100644
index 00000000..078b3387
--- /dev/null
+++ b/versions/8.6.0/install/images/redhat.svg
@@ -0,0 +1,69 @@
+
+
+  
+    
+      
+        image/svg+xml
+        
+        
+      
+    
+  
+  
+  
+    
+  
+  
+  
+
diff --git a/versions/8.6.0/install/images/suse.png b/versions/8.6.0/install/images/suse.png
new file mode 100644
index 00000000..6435b689
Binary files /dev/null and b/versions/8.6.0/install/images/suse.png differ
diff --git a/versions/8.6.0/install/images/tune.svg b/versions/8.6.0/install/images/tune.svg
new file mode 100644
index 00000000..8d7d63cb
--- /dev/null
+++ b/versions/8.6.0/install/images/tune.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/8.6.0/install/images/ubuntu.svg b/versions/8.6.0/install/images/ubuntu.svg
new file mode 100644
index 00000000..f217bc8d
--- /dev/null
+++ b/versions/8.6.0/install/images/ubuntu.svg
@@ -0,0 +1,8 @@
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/versions/8.6.0/install/images/windows.svg b/versions/8.6.0/install/images/windows.svg
new file mode 100644
index 00000000..120b0190
--- /dev/null
+++ b/versions/8.6.0/install/images/windows.svg
@@ -0,0 +1,5 @@
+
+
+
+
+
\ No newline at end of file
diff --git a/versions/8.6.0/install/windows.mdx b/versions/8.6.0/install/windows.mdx
index e5b015b1..2e981621 100644
--- a/versions/8.6.0/install/windows.mdx
+++ b/versions/8.6.0/install/windows.mdx
@@ -31,8 +31,7 @@ To check your Windows version:
 
 Alternatively you can:
 
-*   [Download the Bazel binary (`bazel-version-windows-x86_64.exe`) from
- GitHub](https://github.com/bazelbuild/bazel/releases).
+*   [Download the Bazel binary (`bazel-version-windows-x86_64.exe`) from GitHub](https://github.com/bazelbuild/bazel/releases).
 *   [Install Bazel from Chocolatey](#chocolately)
 *   [Install Bazel from Scoop](#scoop)
 *   [Build Bazel from source](/versions/8.6.0/install/compile-source)
@@ -208,8 +207,7 @@ If that doesn't help:
     its dependencies, such as the MSYS2 shell. This will not install Visual C++
     though.
 
-See [Chocolatey installation and package maintenance
-guide](/versions/8.6.0/contribute/windows-chocolatey-maintenance) for more
+See [Chocolatey installation and package maintenance guide](/versions/8.6.0/contribute/windows-chocolatey-maintenance) for more
 information about the Chocolatey package.
 
 ### Using Scoop
@@ -226,8 +224,7 @@ information about the Chocolatey package.
     scoop install bazel
     ```
 
-See [Scoop installation and package maintenance
-guide](/versions/8.6.0/contribute/windows-scoop-maintenance) for more
+See [Scoop installation and package maintenance guide](/versions/8.6.0/contribute/windows-scoop-maintenance) for more
 information about the Scoop package.
 
 ### Build from source
diff --git a/versions/8.6.0/migrate/maven.mdx b/versions/8.6.0/migrate/maven.mdx
index a150c589..4c7fb5fa 100644
--- a/versions/8.6.0/migrate/maven.mdx
+++ b/versions/8.6.0/migrate/maven.mdx
@@ -19,8 +19,7 @@ directly run by Bazel since there's no Maven compatibility layer.
 ## Before you begin
 
 *   [Install Bazel](/versions/8.6.0/install) if it's not yet installed.
-*   If you're new to Bazel, go through the tutorial [Introduction to Bazel:
-    Build Java](/versions/8.6.0/start/java) before you start migrating. The tutorial explains
+*   If you're new to Bazel, go through the tutorial [Introduction to Bazel: Build Java](/versions/8.6.0/start/java) before you start migrating. The tutorial explains
     Bazel's concepts, structure, and label syntax.
 
 ## Differences between Maven and Bazel
@@ -44,8 +43,7 @@ The steps below describe how to migrate your project to Bazel:
 3.  [Create more BUILD files](#3-build)
 4.  [Build using Bazel](#4-build)
 
-Examples below come from a migration of the [Guava
-project](https://github.com/google/guava) from Maven to Bazel. The
+Examples below come from a migration of the [Guava project](https://github.com/google/guava) from Maven to Bazel. The
 Guava project used is release `v31.1`. The examples using Guava do not walk
 through each step in the migration, but they do show the files and contents that
 are generated or added manually for the migration.
@@ -63,14 +61,12 @@ has no external dependencies, this file can be empty.
 If your project depends on files or packages that are not in one of the
 project's directories, specify these external dependencies in the MODULE.bazel
 file. You can use `rules_jvm_external` to manage dependencies from Maven. For
-instructions about using this ruleset, see [the
-README](https://github.com/bazelbuild/rules_jvm_external/#rules_jvm_external)
+instructions about using this ruleset, see [the README](https://github.com/bazelbuild/rules_jvm_external/#rules_jvm_external)
 .
 
 #### Guava project example: external dependencies
 
-You can list the external dependencies of the [Guava
-project](https://github.com/google/guava) with the
+You can list the external dependencies of the [Guava project](https://github.com/google/guava) with the
 [`rules_jvm_external`](https://github.com/bazelbuild/rules_jvm_external)
 ruleset.
 
@@ -164,8 +160,7 @@ your build by adding more `BUILD` files with more granular targets.
             *   `resources`: Use globbing to list all resources in your project.
             *   `deps`: You need to determine which external dependencies your
                 project needs.
-        *   Take a look at the [example below of this top-level BUILD
-            file](#guava-2) from the migration of the Guava project.
+        *   Take a look at the [example below of this top-level BUILD file](#guava-2) from the migration of the Guava project.
 
 3.  Now that you have a `BUILD` file at the root of your project, build your
     project to ensure that it works. On the command line, from your workspace
diff --git a/versions/8.6.0/migrate/xcode.mdx b/versions/8.6.0/migrate/xcode.mdx
index e5cc29b0..d5107586 100644
--- a/versions/8.6.0/migrate/xcode.mdx
+++ b/versions/8.6.0/migrate/xcode.mdx
@@ -32,8 +32,7 @@ Before you begin, do the following:
 
 1.  [Install Bazel](/versions/8.6.0/install) if you have not already done so.
 
-2.  If you're not familiar with Bazel and its concepts, complete the [iOS app
-    tutorial](/versions/8.6.0/start/ios-app)). You should understand the Bazel workspace,
+2.  If you're not familiar with Bazel and its concepts, complete the [iOS app tutorial](/versions/8.6.0/start/ios-app)). You should understand the Bazel workspace,
     including the `MODULE.bazel` and `BUILD` files, as well as the concepts of
     targets, build rules, and Bazel packages.
 
@@ -44,8 +43,7 @@ Before you begin, do the following:
 Unlike Xcode, Bazel requires you to explicitly declare all dependencies for
 every target in the `BUILD` file.
 
-For more information on external dependencies, see [Working with external
-dependencies](/versions/8.6.0/docs/external).
+For more information on external dependencies, see [Working with external dependencies](/versions/8.6.0/docs/external).
 
 ## Build or test an Xcode project with Bazel
 
@@ -84,8 +82,7 @@ Note: Place the project source code within the directory tree containing the
 
 To integrate SwiftPM dependencies into the Bazel workspace with
 [swift_bazel](https://github.com/cgrindel/swift_bazel), you must
-convert them into Bazel packages as described in the [following
-tutorial](https://chuckgrindel.com/swift-packages-in-bazel-using-swift_bazel/)
+convert them into Bazel packages as described in the [following tutorial](https://chuckgrindel.com/swift-packages-in-bazel-using-swift_bazel/)
 .
 
 Note: SwiftPM support is a manual process with many variables. SwiftPM
@@ -103,8 +100,7 @@ initial build of the project as follows:
 *   [Step 3b: (Optional) Add the test target(s)](#step-3b-optional-add-the-test-target-s)
 *   [Step 3c: Add the library target(s)](#step-3c-add-the-library-target-s)
 
-**Tip:** To learn more about packages and other Bazel concepts, see [Workspaces,
-packages, and targets](/versions/8.6.0/concepts/build-ref).
+**Tip:** To learn more about packages and other Bazel concepts, see [Workspaces, packages, and targets](/versions/8.6.0/concepts/build-ref).
 
 #### Step 3a: Add the application target
 
@@ -132,8 +128,7 @@ In the target, specify the following at the minimum:
 
 #### Step 3b: (Optional) Add the test target(s)
 
-Bazel's [Apple build
-rules](https://github.com/bazelbuild/rules_apple) support running
+Bazel's [Apple build rules](https://github.com/bazelbuild/rules_apple) support running
 unit and UI tests on all Apple platforms. Add test targets as follows:
 
 *   [`macos_unit_test`](https://github.com/bazelbuild/rules_apple/blob/master/doc/rules-macos.md#macos_unit_test)
@@ -181,8 +176,7 @@ all sources and/or headers of a certain type. Use it carefully as it might
 include files you do not want Bazel to build.
 
 You can browse existing examples for various types of applications directly in
-the [rules_apple examples
-directory](https://github.com/bazelbuild/rules_apple/tree/master/examples/). For
+the [rules_apple examples directory](https://github.com/bazelbuild/rules_apple/tree/master/examples/). For
 example:
 
 *   [macOS application targets](https://github.com/bazelbuild/rules_apple/tree/master/examples/macos)
@@ -191,8 +185,7 @@ example:
 
 *   [Multi platform applications (macOS, iOS, watchOS, tvOS)](https://github.com/bazelbuild/rules_apple/tree/master/examples/multi_platform)
 
-For more information on build rules, see [Apple Rules for
-Bazel](https://github.com/bazelbuild/rules_apple).
+For more information on build rules, see [Apple Rules for Bazel](https://github.com/bazelbuild/rules_apple).
 
 At this point, it is a good idea to test the build:
 
diff --git a/versions/8.6.0/query/cquery.mdx b/versions/8.6.0/query/cquery.mdx
index 9585a1e0..166ba199 100644
--- a/versions/8.6.0/query/cquery.mdx
+++ b/versions/8.6.0/query/cquery.mdx
@@ -6,8 +6,7 @@ title: ' Configurable Query (cquery)'
 [`select()`](/versions/8.6.0/docs/configurable-attributes) and build options' effects on the build
 graph.
 
-It achieves this by running over the results of Bazel's [analysis
-phase](/versions/8.6.0/extending/concepts#evaluation-model),
+It achieves this by running over the results of Bazel's [analysis phase](/versions/8.6.0/extending/concepts#evaluation-model),
 which integrates these effects. `query`, by contrast, runs over the results of
 Bazel's loading phase, before options are evaluated.
 
@@ -137,8 +136,7 @@ $ bazel cquery //foo --universe_scope=//foo,//genrule_with_foo_as_tool
 If you want to precisely declare which instance to query over, use
 the [`config`](#config) function.
 
-See `query`'s [target pattern
-documentation](/versions/8.6.0/query/language#target-patterns) for more information on target patterns.
+See `query`'s [target pattern documentation](/versions/8.6.0/query/language#target-patterns) for more information on target patterns.
 
 ## Functions
 
diff --git a/versions/8.6.0/query/images/query_graph1.png b/versions/8.6.0/query/images/query_graph1.png
new file mode 100644
index 00000000..7bc9a61a
Binary files /dev/null and b/versions/8.6.0/query/images/query_graph1.png differ
diff --git a/versions/8.6.0/query/images/query_graph2.png b/versions/8.6.0/query/images/query_graph2.png
new file mode 100644
index 00000000..a0da22ff
Binary files /dev/null and b/versions/8.6.0/query/images/query_graph2.png differ
diff --git a/versions/8.6.0/query/images/query_graph3.png b/versions/8.6.0/query/images/query_graph3.png
new file mode 100644
index 00000000..4418f193
Binary files /dev/null and b/versions/8.6.0/query/images/query_graph3.png differ
diff --git a/versions/8.6.0/query/language.mdx b/versions/8.6.0/query/language.mdx
index 80321497..e2cc1482 100644
--- a/versions/8.6.0/query/language.mdx
+++ b/versions/8.6.0/query/language.mdx
@@ -1120,8 +1120,7 @@ is being used.
 
 ### On the ordering of results
 
-Although query expressions always follow the "[law of
-conservation of graph order](#graph-order)", _presenting_ the results may be done
+Although query expressions always follow the "[law of conservation of graph order](#graph-order)", _presenting_ the results may be done
 in either a dependency-ordered or unordered manner. This does **not**
 influence the targets in the result set or how the query is computed. It only
 affects how the results are printed to stdout. Moreover, nodes that are
@@ -1267,8 +1266,7 @@ and `maxrank` output formats print the labels of each
 target in the resulting graph, but instead of appearing in
 topological order, they appear in rank order, preceded by their
 rank number. These are unaffected by the result ordering
-`--[no]order_results` flag (see [notes on
-the ordering of results](#result-order)).
+`--[no]order_results` flag (see [notes on the ordering of results](#result-order)).
 
 There are two variants of this format: `minrank` ranks
 each node by the length of the shortest path from a root node to it.
diff --git a/versions/8.6.0/query/quickstart.mdx b/versions/8.6.0/query/quickstart.mdx
index db06f7c6..6c79158b 100644
--- a/versions/8.6.0/query/quickstart.mdx
+++ b/versions/8.6.0/query/quickstart.mdx
@@ -205,7 +205,7 @@ dot -Tpng < graph.in > graph.png
 ```
 If you open up `graph.png`, you should see something like this. The graph below has been simplified to make the essential path details clearer in this guide.
 
-![Diagram showing a relationship from cafe to chef to the dishes: pizza and mac and cheese which diverges into the separate ingredients: cheese, tomatoes, dough, and macaroni.](images/query_graph1.png "Dependency graph")
+![Diagram showing a relationship from cafe to chef to the dishes: pizza and mac and cheese which diverges into the separate ingredients: cheese, tomatoes, dough, and macaroni.](/versions/8.6.0/query/images/query_graph1.png "Dependency graph")
 
 This helps when you want to see the outputs of the different query functions throughout this guide.
 
@@ -424,7 +424,7 @@ bazel query --noimplicit_deps 'deps(:runner)' --output graph > graph2.in
 dot -Tpng < graph2.in > graph2.png
 ```
 
-[![The same graph as the first one except now there is a spoke stemming from the chef target with smoothie which leads to banana and strawberry](images/query_graph2.png "Updated dependency graph")](images/query_graph2.png)
+[![The same graph as the first one except now there is a spoke stemming from the chef target with smoothie which leads to banana and strawberry](/versions/8.6.0/query/images/query_graph2.png "Updated dependency graph")](/query/images/query_graph2.png)
 
 Looking at `graph2.png`, you can see that `Smoothie` has no shared dependencies with other dishes but is just another target that the `Chef` relies on.
 
@@ -468,7 +468,7 @@ bazel query "allpaths(//src/main/java/com/example/restaurant/..., //src/main/jav
 //src/main/java/com/example/restaurant:chef
 ```
 
-![Output path of cafe to chef to pizza,mac and cheese to cheese](images/query_graph3.png "Output path for dependency")
+![Output path of cafe to chef to pizza,mac and cheese to cheese](/versions/8.6.0/query/images/query_graph3.png "Output path for dependency")
 
 The output of `allpaths()` is a little harder to read as it is a flattened list of the dependencies. Visualizing this graph using Graphviz makes the relationship clearer to understand.
 
diff --git a/versions/8.6.0/reference/be/be-nav.mdx b/versions/8.6.0/reference/be/be-nav.mdx
index 41a19e38..3200e352 100644
--- a/versions/8.6.0/reference/be/be-nav.mdx
+++ b/versions/8.6.0/reference/be/be-nav.mdx
@@ -1,21 +1,21 @@
 \*\*Build Encyclopedia\*\*
 
-* [Overview](/reference/be/overview)
+* [Overview](/versions/8.6.0/reference/be/overview)
 * [Concepts](#be-menu)
-  + [Common Definitions](/reference/be/common-definitions)
-  + ["Make" variables](/reference/be/make-variables)
+  + [Common Definitions](/versions/8.6.0/reference/be/common-definitions)
+  + ["Make" variables](/versions/8.6.0/reference/be/make-variables)
 * [Rules](#be-rules)
-  + [Functions](/reference/be/functions)
-  + [C / C++](/reference/be/c-cpp)
-  + [Java](/reference/be/java)
-  + [Objective-C](/reference/be/objective-c)
-  + [Protocol Buffer](/reference/be/protocol-buffer)
-  + [Python](/reference/be/python)
-  + [Shell](/reference/be/shell)
-  + [Extra Actions](/reference/be/extra-actions)
-  + [General](/reference/be/general)
-  + [Platforms and Toolchains](/reference/be/platforms-and-toolchains)
-  + [Workspace](/reference/be/workspace)
+  + [Functions](/versions/8.6.0/reference/be/functions)
+  + [C / C++](/versions/8.6.0/reference/be/c-cpp)
+  + [Java](/versions/8.6.0/reference/be/java)
+  + [Objective-C](/versions/8.6.0/reference/be/objective-c)
+  + [Protocol Buffer](/versions/8.6.0/reference/be/protocol-buffer)
+  + [Python](/versions/8.6.0/reference/be/python)
+  + [Shell](/versions/8.6.0/reference/be/shell)
+  + [Extra Actions](/versions/8.6.0/reference/be/extra-actions)
+  + [General](/versions/8.6.0/reference/be/general)
+  + [Platforms and Toolchains](/versions/8.6.0/reference/be/platforms-and-toolchains)
+  + [Workspace](/versions/8.6.0/reference/be/workspace)
   + [AppEngine](https://github.com/bazelbuild/rules_appengine)
   + [Apple (Swift, iOS, macOS, tvOS, visionOS, watchOS)](https://github.com/bazelbuild/rules_apple)
   + [C#](https://github.com/bazelbuild/rules_dotnet)
@@ -25,7 +25,7 @@
   + [Go](https://github.com/bazelbuild/rules_go)
   + [JavaScript (Closure)](https://github.com/bazelbuild/rules_closure)
   + [Jsonnet](https://github.com/bazelbuild/rules_jsonnet)
-  + [Packaging](/reference/be/pkg)
+  + [Packaging](/versions/8.6.0/reference/be/pkg)
   + [Rust](https://github.com/bazelbuild/rules_rust)
   + [Sass](https://github.com/bazelbuild/rules_sass)
   + [Scala](https://github.com/bazelbuild/rules_scala)
\ No newline at end of file
diff --git a/versions/8.6.0/reference/be/c-cpp.mdx b/versions/8.6.0/reference/be/c-cpp.mdx
index aaf13236..9ce03556 100644
--- a/versions/8.6.0/reference/be/c-cpp.mdx
+++ b/versions/8.6.0/reference/be/c-cpp.mdx
@@ -48,29 +48,29 @@ be `main`.
 
 | Attributes | |
 | --- | --- |
-| `name` | [Name](/concepts/labels#target-names); required  A unique name for this target. |
-| `deps` | List of [labels](/concepts/labels); default is `[]` The list of other libraries to be linked in to the binary target. These can be `cc_library` or `objc_library` targets. It is also allowed to put linker scripts (.lds) into deps, and reference them in [linkopts](#cc_binary.linkopts). |
-| `srcs` | List of [labels](/concepts/labels); default is `[]` The list of C and C++ files that are processed to create the library target. These are C/C++ source and header files, either non-generated (normal source code) or generated. All `.cc`, `.c`, and `.cpp` files will be compiled. These might be generated files: if a named file is in the `outs` of some other rule, this `cc_library` will automatically depend on that other rule.  Pure assembler files (.s, .asm) are not preprocessed and are typically built using the assembler. Preprocessed assembly files (.S) are preprocessed and are typically built using the C/C++ compiler.  A `.h` file will not be compiled, but will be available for inclusion by sources in this rule. Both `.cc` and `.h` files can directly include headers listed in these `srcs` or in the `hdrs` of this rule or any rule listed in the `deps` argument.  All `#include`d files must be mentioned in the `hdrs` attribute of this or referenced `cc_library` rules, or they should be listed in `srcs` if they are private to this library. See ["Header inclusion checking"](#hdrs) for a more detailed description.  `.so`, `.lo`, and `.a` files are pre-compiled files. Your library might have these as `srcs` if it uses third-party code for which we don't have source code.  If the `srcs` attribute includes the label of another rule, `cc_library` will use the output files of that rule as source files to compile. This is useful for one-off generation of source code (for more than occasional use, it's better to implement a Starlark rule class and use the `cc_common` API)  Permitted `srcs` file types:   * C and C++ source files: `.c`, `.cc`, `.cpp`,   `.cxx`, `.c++`, `.C` * C and C++ header files: `.h`, `.hh`, `.hpp`,   `.hxx`, `.inc`, `.inl`, `.H` * Assembler with C preprocessor: `.S` * Archive: `.a`, `.pic.a` * "Always link" library: `.lo`, `.pic.lo` * Shared library, versioned or unversioned: `.so`,   `.so.version` * Object file: `.o`, `.pic.o`   ... and any rules that produce those files (e.g. `cc_embed_data`). Different extensions denote different programming languages in accordance with gcc convention. |
-| `data` | List of [labels](/concepts/labels); default is `[]` The list of files needed by this library at runtime. See general comments about `data` at [Typical attributes defined by most build rules](/reference/be/common-definitions#typical-attributes). If a `data` is the name of a generated file, then this `cc_library` rule automatically depends on the generating rule.  If a `data` is a rule name, then this `cc_library` rule automatically depends on that rule, and that rule's `outs` are automatically added to this `cc_library`'s data files.  Your C++ code can access these data files like so:   ```   const std::string path = devtools_build::GetDataDependencyFilepath(       "my/test/data/file"); ``` |
-| `additional_linker_inputs` | List of [labels](/concepts/labels); default is `[]` Pass these files to the C++ linker command. For example, compiled Windows .res files can be provided here to be embedded in the binary target. |
-| `conlyopts` | List of strings; default is `[]` Add these options to the C compilation command. Subject to ["Make variable"](/reference/be/make-variables) substitution and [Bourne shell tokenization](/reference/be/common-definitions#sh-tokenization). |
-| `copts` | List of strings; default is `[]` Add these options to the C/C++ compilation command. Subject to ["Make variable"](/reference/be/make-variables) substitution and [Bourne shell tokenization](/reference/be/common-definitions#sh-tokenization). Each string in this attribute is added in the given order to `COPTS` before compiling the binary target. The flags take effect only for compiling this target, not its dependencies, so be careful about header files included elsewhere. All paths should be relative to the workspace, not to the current package. This attribute should not be needed outside of `third_party`.  If the package declares the [feature](/reference/be/functions#package.features) `no_copts_tokenization`, Bourne shell tokenization applies only to strings that consist of a single "Make" variable. |
-| `cxxopts` | List of strings; default is `[]` Add these options to the C++ compilation command. Subject to ["Make variable"](/reference/be/make-variables) substitution and [Bourne shell tokenization](/reference/be/common-definitions#sh-tokenization). |
-| `defines` | List of strings; default is `[]` List of defines to add to the compile line. Subject to ["Make" variable](/reference/be/make-variables) substitution and [Bourne shell tokenization](/reference/be/common-definitions#sh-tokenization). Each string, which must consist of a single Bourne shell token, is prepended with `-D` and added to the compile command line to this target, as well as to every rule that depends on it. Be very careful, since this may have far-reaching effects. When in doubt, add define values to [`local_defines`](#cc_binary.local_defines) instead. |
-| `dynamic_deps` | List of [labels](/concepts/labels); default is `[]` These are other `cc_shared_library` dependencies the current target depends on. The `cc_shared_library` implementation will use the list of `dynamic_deps` (transitively, i.e. also the `dynamic_deps` of the current target's `dynamic_deps`) to decide which `cc_libraries` in the transitive `deps` should not be linked in because they are already provided by a different `cc_shared_library`. |
+| `name` | [Name](/versions/8.6.0/concepts/labels#target-names); required  A unique name for this target. |
+| `deps` | List of [labels](/versions/8.6.0/concepts/labels); default is `[]` The list of other libraries to be linked in to the binary target. These can be `cc_library` or `objc_library` targets. It is also allowed to put linker scripts (.lds) into deps, and reference them in [linkopts](#cc_binary.linkopts). |
+| `srcs` | List of [labels](/versions/8.6.0/concepts/labels); default is `[]` The list of C and C++ files that are processed to create the library target. These are C/C++ source and header files, either non-generated (normal source code) or generated. All `.cc`, `.c`, and `.cpp` files will be compiled. These might be generated files: if a named file is in the `outs` of some other rule, this `cc_library` will automatically depend on that other rule.  Pure assembler files (.s, .asm) are not preprocessed and are typically built using the assembler. Preprocessed assembly files (.S) are preprocessed and are typically built using the C/C++ compiler.  A `.h` file will not be compiled, but will be available for inclusion by sources in this rule. Both `.cc` and `.h` files can directly include headers listed in these `srcs` or in the `hdrs` of this rule or any rule listed in the `deps` argument.  All `#include`d files must be mentioned in the `hdrs` attribute of this or referenced `cc_library` rules, or they should be listed in `srcs` if they are private to this library. See ["Header inclusion checking"](#hdrs) for a more detailed description.  `.so`, `.lo`, and `.a` files are pre-compiled files. Your library might have these as `srcs` if it uses third-party code for which we don't have source code.  If the `srcs` attribute includes the label of another rule, `cc_library` will use the output files of that rule as source files to compile. This is useful for one-off generation of source code (for more than occasional use, it's better to implement a Starlark rule class and use the `cc_common` API)  Permitted `srcs` file types:   * C and C++ source files: `.c`, `.cc`, `.cpp`,   `.cxx`, `.c++`, `.C` * C and C++ header files: `.h`, `.hh`, `.hpp`,   `.hxx`, `.inc`, `.inl`, `.H` * Assembler with C preprocessor: `.S` * Archive: `.a`, `.pic.a` * "Always link" library: `.lo`, `.pic.lo` * Shared library, versioned or unversioned: `.so`,   `.so.version` * Object file: `.o`, `.pic.o`   ... and any rules that produce those files (e.g. `cc_embed_data`). Different extensions denote different programming languages in accordance with gcc convention. |
+| `data` | List of [labels](/versions/8.6.0/concepts/labels); default is `[]` The list of files needed by this library at runtime. See general comments about `data` at [Typical attributes defined by most build rules](/versions/8.6.0/reference/be/common-definitions#typical-attributes). If a `data` is the name of a generated file, then this `cc_library` rule automatically depends on the generating rule.  If a `data` is a rule name, then this `cc_library` rule automatically depends on that rule, and that rule's `outs` are automatically added to this `cc_library`'s data files.  Your C++ code can access these data files like so:   ```   const std::string path = devtools_build::GetDataDependencyFilepath(       "my/test/data/file"); ``` |
+| `additional_linker_inputs` | List of [labels](/versions/8.6.0/concepts/labels); default is `[]` Pass these files to the C++ linker command. For example, compiled Windows .res files can be provided here to be embedded in the binary target. |
+| `conlyopts` | List of strings; default is `[]` Add these options to the C compilation command. Subject to ["Make variable"](/versions/8.6.0/reference/be/make-variables) substitution and [Bourne shell tokenization](/versions/8.6.0/reference/be/common-definitions#sh-tokenization). |
+| `copts` | List of strings; default is `[]` Add these options to the C/C++ compilation command. Subject to ["Make variable"](/versions/8.6.0/reference/be/make-variables) substitution and [Bourne shell tokenization](/versions/8.6.0/reference/be/common-definitions#sh-tokenization). Each string in this attribute is added in the given order to `COPTS` before compiling the binary target. The flags take effect only for compiling this target, not its dependencies, so be careful about header files included elsewhere. All paths should be relative to the workspace, not to the current package. This attribute should not be needed outside of `third_party`.  If the package declares the [feature](/versions/8.6.0/reference/be/functions#package.features) `no_copts_tokenization`, Bourne shell tokenization applies only to strings that consist of a single "Make" variable. |
+| `cxxopts` | List of strings; default is `[]` Add these options to the C++ compilation command. Subject to ["Make variable"](/versions/8.6.0/reference/be/make-variables) substitution and [Bourne shell tokenization](/versions/8.6.0/reference/be/common-definitions#sh-tokenization). |
+| `defines` | List of strings; default is `[]` List of defines to add to the compile line. Subject to ["Make" variable](/versions/8.6.0/reference/be/make-variables) substitution and [Bourne shell tokenization](/versions/8.6.0/reference/be/common-definitions#sh-tokenization). Each string, which must consist of a single Bourne shell token, is prepended with `-D` and added to the compile command line to this target, as well as to every rule that depends on it. Be very careful, since this may have far-reaching effects. When in doubt, add define values to [`local_defines`](#cc_binary.local_defines) instead. |
+| `dynamic_deps` | List of [labels](/versions/8.6.0/concepts/labels); default is `[]` These are other `cc_shared_library` dependencies the current target depends on. The `cc_shared_library` implementation will use the list of `dynamic_deps` (transitively, i.e. also the `dynamic_deps` of the current target's `dynamic_deps`) to decide which `cc_libraries` in the transitive `deps` should not be linked in because they are already provided by a different `cc_shared_library`. |
 | `hdrs_check` | String; default is `""` Deprecated, no-op. |
-| `includes` | List of strings; default is `[]` List of include dirs to be added to the compile line. Subject to ["Make variable"](/reference/be/make-variables) substitution. Each string is prepended with the package path and passed to the C++ toolchain for expansion via the "include_paths" CROSSTOOL feature. A toolchain running on a POSIX system with typical feature definitions will produce `-isystem path_to_package/include_entry`. This should only be used for third-party libraries that do not conform to the Google style of writing #include statements. Unlike [COPTS](#cc_binary.copts), these flags are added for this rule and every rule that depends on it. (Note: not the rules it depends upon!) Be very careful, since this may have far-reaching effects. When in doubt, add "-I" flags to [COPTS](#cc_binary.copts) instead. The added `include` paths will include generated files as well as files in the source tree. |
-| `link_extra_lib` | [Label](/concepts/labels); default is `"@bazel_tools//tools/cpp:link_extra_lib"` Control linking of extra libraries. By default, C++ binaries are linked against `//tools/cpp:link_extra_lib`, which by default depends on the label flag `//tools/cpp:link_extra_libs`. Without setting the flag, this library is empty by default. Setting the label flag allows linking optional dependencies, such as overrides for weak symbols, interceptors for shared library functions, or special runtime libraries (for malloc replacements, prefer `malloc` or `--custom_malloc`). Setting this attribute to `None` disables this behaviour. |
-| `linkopts` | List of strings; default is `[]` Add these flags to the C++ linker command. Subject to ["Make" variable](make-variables) substitution, [Bourne shell tokenization](common-definitions#sh-tokenization) and [label expansion](common-definitions#label-expansion). Each string in this attribute is added to `LINKOPTS` before linking the binary target. Each element of this list that does not start with `$` or `-` is assumed to be the label of a target in `deps`. The list of files generated by that target is appended to the linker options. An error is reported if the label is invalid, or is not declared in `deps`. |
+| `includes` | List of strings; default is `[]` List of include dirs to be added to the compile line. Subject to ["Make variable"](/versions/8.6.0/reference/be/make-variables) substitution. Each string is prepended with the package path and passed to the C++ toolchain for expansion via the "include_paths" CROSSTOOL feature. A toolchain running on a POSIX system with typical feature definitions will produce `-isystem path_to_package/include_entry`. This should only be used for third-party libraries that do not conform to the Google style of writing #include statements. Unlike [COPTS](#cc_binary.copts), these flags are added for this rule and every rule that depends on it. (Note: not the rules it depends upon!) Be very careful, since this may have far-reaching effects. When in doubt, add "-I" flags to [COPTS](#cc_binary.copts) instead. The added `include` paths will include generated files as well as files in the source tree. |
+| `link_extra_lib` | [Label](/versions/8.6.0/concepts/labels); default is `"@bazel_tools//tools/cpp:link_extra_lib"` Control linking of extra libraries. By default, C++ binaries are linked against `//tools/cpp:link_extra_lib`, which by default depends on the label flag `//tools/cpp:link_extra_libs`. Without setting the flag, this library is empty by default. Setting the label flag allows linking optional dependencies, such as overrides for weak symbols, interceptors for shared library functions, or special runtime libraries (for malloc replacements, prefer `malloc` or `--custom_malloc`). Setting this attribute to `None` disables this behaviour. |
+| `linkopts` | List of strings; default is `[]` Add these flags to the C++ linker command. Subject to ["Make" variable](/versions/8.6.0/reference/be/make-variables) substitution, [Bourne shell tokenization](/versions/8.6.0/reference/be/common-definitions#sh-tokenization) and [label expansion](/versions/8.6.0/reference/be/common-definitions#label-expansion). Each string in this attribute is added to `LINKOPTS` before linking the binary target. Each element of this list that does not start with `$` or `-` is assumed to be the label of a target in `deps`. The list of files generated by that target is appended to the linker options. An error is reported if the label is invalid, or is not declared in `deps`. |
 | `linkshared` | Boolean; default is `False` Create a shared library. To enable this attribute, include `linkshared=True` in your rule. By default this option is off. The presence of this flag means that linking occurs with the `-shared` flag to `gcc`, and the resulting shared library is suitable for loading into for example a Java program. However, for build purposes it will never be linked into the dependent binary, as it is assumed that shared libraries built with a [cc_binary](#cc_binary) rule are only loaded manually by other programs, so it should not be considered a substitute for the [cc_library](#cc_library) rule. For sake of scalability we recommend avoiding this approach altogether and simply letting `java_library` depend on `cc_library` rules instead.  If you specify both `linkopts=['-static']` and `linkshared=True`, you get a single completely self-contained unit. If you specify both `linkstatic=True` and `linkshared=True`, you get a single, mostly self-contained unit. |
-| `linkstatic` | Boolean; default is `True` For [`cc_binary`](/reference/be/c-cpp#cc_binary) and [`cc_test`](/reference/be/c-cpp#cc_test): link the binary in static mode. For `cc_library.link_static`: see below. By default this option is on for `cc_binary` and off for the rest.  If enabled and this is a binary or test, this option tells the build tool to link in `.a`'s instead of `.so`'s for user libraries whenever possible. System libraries such as libc (but *not* the C/C++ runtime libraries, see below) are still linked dynamically, as are libraries for which there is no static library. So the resulting executable will still be dynamically linked, hence only *mostly* static.  There are really three different ways to link an executable:   * STATIC with fully_static_link feature, in which everything is linked statically;   e.g. "`gcc -static foo.o libbar.a libbaz.a -lm`".    This mode is enabled by specifying `fully_static_link` in the   [`features`](/reference/be/common-definitions#features) attribute. * STATIC, in which all user libraries are linked statically (if a static   version is available), but where system libraries (excluding C/C++ runtime libraries)   are linked dynamically, e.g. "`gcc foo.o libfoo.a libbaz.a -lm`".    This mode is enabled by specifying `linkstatic=True`. * DYNAMIC, in which all libraries are linked dynamically (if a dynamic version is   available), e.g. "`gcc foo.o libfoo.so libbaz.so -lm`".    This mode is enabled by specifying `linkstatic=False`.   If the `linkstatic` attribute or `fully_static_link` in `features` is used outside of `//third_party` please include a comment near the rule to explain why.  The `linkstatic` attribute has a different meaning if used on a [`cc_library()`](/reference/be/c-cpp#cc_library) rule. For a C++ library, `linkstatic=True` indicates that only static linking is allowed, so no `.so` will be produced. linkstatic=False does not prevent static libraries from being created. The attribute is meant to control the creation of dynamic libraries.  There should be very little code built with `linkstatic=False` in production. If `linkstatic=False`, then the build tool will create symlinks to depended-upon shared libraries in the `*.runfiles` area. |
-| `local_defines` | List of strings; default is `[]` List of defines to add to the compile line. Subject to ["Make" variable](/reference/be/make-variables) substitution and [Bourne shell tokenization](/reference/be/common-definitions#sh-tokenization). Each string, which must consist of a single Bourne shell token, is prepended with `-D` and added to the compile command line for this target, but not to its dependents. |
-| `malloc` | [Label](/concepts/labels); default is `"@bazel_tools//tools/cpp:malloc"` Override the default dependency on malloc. By default, C++ binaries are linked against `//tools/cpp:malloc`, which is an empty library so the binary ends up using libc malloc. This label must refer to a `cc_library`. If compilation is for a non-C++ rule, this option has no effect. The value of this attribute is ignored if `linkshared=True` is specified. |
-| `module_interfaces` | List of [labels](/concepts/labels); default is `[]` The list of files are regarded as C++20 Modules Interface. C++ Standard has no restriction about module interface file extension  * Clang use cppm * GCC can use any source file extension * MSVC use ixx  The use is guarded by the flag `--experimental_cpp_modules`. |
-| `nocopts` | String; default is `""` Remove matching options from the C++ compilation command. Subject to ["Make" variable](/reference/be/make-variables) substitution. The value of this attribute is interpreted as a regular expression. Any preexisting `COPTS` that match this regular expression (including values explicitly specified in the rule's [copts](#cc_binary.copts) attribute) will be removed from `COPTS` for purposes of compiling this rule. This attribute should not be needed or used outside of `third_party`. The values are not preprocessed in any way other than the "Make" variable substitution. |
-| `reexport_deps` | List of [labels](/concepts/labels); default is `[]` |
-| `stamp` | Integer; default is `-1` Whether to encode build information into the binary. Possible values:  * `stamp = 1`: Always stamp the build information into the binary, even in   [`--nostamp`](/docs/user-manual#flag--stamp) builds. **This   setting should be avoided**, since it potentially kills remote caching for the   binary and any downstream actions that depend on it. * `stamp = 0`: Always replace build information by constant values. This   gives good build result caching. * `stamp = -1`: Embedding of build information is controlled by the   [`--[no]stamp`](/docs/user-manual#flag--stamp) flag.   Stamped binaries are *not* rebuilt unless their dependencies change. |
-| `win_def_file` | [Label](/concepts/labels); default is `None` The Windows DEF file to be passed to linker. This attribute should only be used when Windows is the target platform. It can be used to [export symbols](https://msdn.microsoft.com/en-us/library/d91k01sh.aspx) during linking a shared library. |
+| `linkstatic` | Boolean; default is `True` For [`cc_binary`](/versions/8.6.0/reference/be/c-cpp#cc_binary) and [`cc_test`](/versions/8.6.0/reference/be/c-cpp#cc_test): link the binary in static mode. For `cc_library.link_static`: see below. By default this option is on for `cc_binary` and off for the rest.  If enabled and this is a binary or test, this option tells the build tool to link in `.a`'s instead of `.so`'s for user libraries whenever possible. System libraries such as libc (but *not* the C/C++ runtime libraries, see below) are still linked dynamically, as are libraries for which there is no static library. So the resulting executable will still be dynamically linked, hence only *mostly* static.  There are really three different ways to link an executable:   * STATIC with fully_static_link feature, in which everything is linked statically;   e.g. "`gcc -static foo.o libbar.a libbaz.a -lm`".    This mode is enabled by specifying `fully_static_link` in the   [`features`](/versions/8.6.0/reference/be/common-definitions#features) attribute. * STATIC, in which all user libraries are linked statically (if a static   version is available), but where system libraries (excluding C/C++ runtime libraries)   are linked dynamically, e.g. "`gcc foo.o libfoo.a libbaz.a -lm`".    This mode is enabled by specifying `linkstatic=True`. * DYNAMIC, in which all libraries are linked dynamically (if a dynamic version is   available), e.g. "`gcc foo.o libfoo.so libbaz.so -lm`".    This mode is enabled by specifying `linkstatic=False`.   If the `linkstatic` attribute or `fully_static_link` in `features` is used outside of `//third_party` please include a comment near the rule to explain why.  The `linkstatic` attribute has a different meaning if used on a [`cc_library()`](/versions/8.6.0/reference/be/c-cpp#cc_library) rule. For a C++ library, `linkstatic=True` indicates that only static linking is allowed, so no `.so` will be produced. linkstatic=False does not prevent static libraries from being created. The attribute is meant to control the creation of dynamic libraries.  There should be very little code built with `linkstatic=False` in production. If `linkstatic=False`, then the build tool will create symlinks to depended-upon shared libraries in the `*.runfiles` area. |
+| `local_defines` | List of strings; default is `[]` List of defines to add to the compile line. Subject to ["Make" variable](/versions/8.6.0/reference/be/make-variables) substitution and [Bourne shell tokenization](/versions/8.6.0/reference/be/common-definitions#sh-tokenization). Each string, which must consist of a single Bourne shell token, is prepended with `-D` and added to the compile command line for this target, but not to its dependents. |
+| `malloc` | [Label](/versions/8.6.0/concepts/labels); default is `"@bazel_tools//tools/cpp:malloc"` Override the default dependency on malloc. By default, C++ binaries are linked against `//tools/cpp:malloc`, which is an empty library so the binary ends up using libc malloc. This label must refer to a `cc_library`. If compilation is for a non-C++ rule, this option has no effect. The value of this attribute is ignored if `linkshared=True` is specified. |
+| `module_interfaces` | List of [labels](/versions/8.6.0/concepts/labels); default is `[]` The list of files are regarded as C++20 Modules Interface. C++ Standard has no restriction about module interface file extension  * Clang use cppm * GCC can use any source file extension * MSVC use ixx  The use is guarded by the flag `--experimental_cpp_modules`. |
+| `nocopts` | String; default is `""` Remove matching options from the C++ compilation command. Subject to ["Make" variable](/versions/8.6.0/reference/be/make-variables) substitution. The value of this attribute is interpreted as a regular expression. Any preexisting `COPTS` that match this regular expression (including values explicitly specified in the rule's [copts](#cc_binary.copts) attribute) will be removed from `COPTS` for purposes of compiling this rule. This attribute should not be needed or used outside of `third_party`. The values are not preprocessed in any way other than the "Make" variable substitution. |
+| `reexport_deps` | List of [labels](/versions/8.6.0/concepts/labels); default is `[]` |
+| `stamp` | Integer; default is `-1` Whether to encode build information into the binary. Possible values:  * `stamp = 1`: Always stamp the build information into the binary, even in   [`--nostamp`](/versions/8.6.0/docs/user-manual#flag--stamp) builds. **This   setting should be avoided**, since it potentially kills remote caching for the   binary and any downstream actions that depend on it. * `stamp = 0`: Always replace build information by constant values. This   gives good build result caching. * `stamp = -1`: Embedding of build information is controlled by the   [`--[no]stamp`](/versions/8.6.0/docs/user-manual#flag--stamp) flag.   Stamped binaries are *not* rebuilt unless their dependencies change. |
+| `win_def_file` | [Label](/versions/8.6.0/concepts/labels); default is `None` The Windows DEF file to be passed to linker. This attribute should only be used when Windows is the target platform. It can be used to [export symbols](https://msdn.microsoft.com/en-us/library/d91k01sh.aspx) during linking a shared library. |
 
 ## cc_import
 
@@ -223,18 +223,18 @@ cc_import(
 
 | Attributes | |
 | --- | --- |
-| `name` | [Name](/concepts/labels#target-names); required  A unique name for this target. |
-| `deps` | List of [labels](/concepts/labels); default is `[]` The list of other libraries that the target depends upon. See general comments about `deps` at [Typical attributes defined by most build rules](/reference/be/common-definitions#typical-attributes). |
-| `hdrs` | List of [labels](/concepts/labels); default is `[]` The list of header files published by this precompiled library to be directly included by sources in dependent rules. |
+| `name` | [Name](/versions/8.6.0/concepts/labels#target-names); required  A unique name for this target. |
+| `deps` | List of [labels](/versions/8.6.0/concepts/labels); default is `[]` The list of other libraries that the target depends upon. See general comments about `deps` at [Typical attributes defined by most build rules](/versions/8.6.0/reference/be/common-definitions#typical-attributes). |
+| `hdrs` | List of [labels](/versions/8.6.0/concepts/labels); default is `[]` The list of header files published by this precompiled library to be directly included by sources in dependent rules. |
 | `alwayslink` | Boolean; default is `False` If 1, any binary that depends (directly or indirectly) on this C++ precompiled library will link in all the object files archived in the static library, even if some contain no symbols referenced by the binary. This is useful if your code isn't explicitly called by code in the binary, e.g., if your code registers to receive some callback provided by some service. If alwayslink doesn't work with VS 2017 on Windows, that is due to a [known issue](https://github.com/bazelbuild/bazel/issues/3949), please upgrade your VS 2017 to the latest version. |
-| `includes` | List of strings; default is `[]` List of include dirs to be added to the compile line. Subject to ["Make variable"](/reference/be/make-variables) substitution. Each string is prepended with the package path and passed to the C++ toolchain for expansion via the "include_paths" CROSSTOOL feature. A toolchain running on a POSIX system with typical feature definitions will produce `-isystem path_to_package/include_entry`. This should only be used for third-party libraries that do not conform to the Google style of writing #include statements. Unlike [COPTS](#cc_binary.copts), these flags are added for this rule and every rule that depends on it. (Note: not the rules it depends upon!) Be very careful, since this may have far-reaching effects. When in doubt, add "-I" flags to [COPTS](#cc_binary.copts) instead. The default `include` path doesn't include generated files. If you need to `#include` a generated header file, list it in the `srcs`. |
-| `interface_library` | [Label](/concepts/labels); default is `None` A single interface library for linking the shared library. Permitted file types: `.ifso`, `.tbd`, `.lib`, `.so` or `.dylib` |
-| `linkopts` | List of strings; default is `[]` Add these flags to the C++ linker command. Subject to ["Make" variable](make-variables) substitution, [Bourne shell tokenization](common-definitions#sh-tokenization) and [label expansion](common-definitions#label-expansion). Each string in this attribute is added to `LINKOPTS` before linking the binary target. Each element of this list that does not start with `$` or `-` is assumed to be the label of a target in `deps`. The list of files generated by that target is appended to the linker options. An error is reported if the label is invalid, or is not declared in `deps`. |
-| `objects` | List of [labels](/concepts/labels); default is `[]` |
-| `pic_objects` | List of [labels](/concepts/labels); default is `[]` |
-| `pic_static_library` | [Label](/concepts/labels); default is `None` |
-| `shared_library` | [Label](/concepts/labels); default is `None` A single precompiled shared library. Bazel ensures it is available to the binary that depends on it during runtime. Permitted file types: `.so`, `.dll` or `.dylib` |
-| `static_library` | [Label](/concepts/labels); default is `None` A single precompiled static library. Permitted file types: `.a`, `.pic.a` or `.lib` |
+| `includes` | List of strings; default is `[]` List of include dirs to be added to the compile line. Subject to ["Make variable"](/versions/8.6.0/reference/be/make-variables) substitution. Each string is prepended with the package path and passed to the C++ toolchain for expansion via the "include_paths" CROSSTOOL feature. A toolchain running on a POSIX system with typical feature definitions will produce `-isystem path_to_package/include_entry`. This should only be used for third-party libraries that do not conform to the Google style of writing #include statements. Unlike [COPTS](#cc_binary.copts), these flags are added for this rule and every rule that depends on it. (Note: not the rules it depends upon!) Be very careful, since this may have far-reaching effects. When in doubt, add "-I" flags to [COPTS](#cc_binary.copts) instead. The default `include` path doesn't include generated files. If you need to `#include` a generated header file, list it in the `srcs`. |
+| `interface_library` | [Label](/versions/8.6.0/concepts/labels); default is `None` A single interface library for linking the shared library. Permitted file types: `.ifso`, `.tbd`, `.lib`, `.so` or `.dylib` |
+| `linkopts` | List of strings; default is `[]` Add these flags to the C++ linker command. Subject to ["Make" variable](/versions/8.6.0/reference/be/make-variables) substitution, [Bourne shell tokenization](/versions/8.6.0/reference/be/common-definitions#sh-tokenization) and [label expansion](/versions/8.6.0/reference/be/common-definitions#label-expansion). Each string in this attribute is added to `LINKOPTS` before linking the binary target. Each element of this list that does not start with `$` or `-` is assumed to be the label of a target in `deps`. The list of files generated by that target is appended to the linker options. An error is reported if the label is invalid, or is not declared in `deps`. |
+| `objects` | List of [labels](/versions/8.6.0/concepts/labels); default is `[]` |
+| `pic_objects` | List of [labels](/versions/8.6.0/concepts/labels); default is `[]` |
+| `pic_static_library` | [Label](/versions/8.6.0/concepts/labels); default is `None` |
+| `shared_library` | [Label](/versions/8.6.0/concepts/labels); default is `None` A single precompiled shared library. Bazel ensures it is available to the binary that depends on it during runtime. Permitted file types: `.so`, `.dll` or `.dylib` |
+| `static_library` | [Label](/versions/8.6.0/concepts/labels); default is `None` A single precompiled static library. Permitted file types: `.a`, `.pic.a` or `.lib` |
 | `strip_include_prefix` | String; default is `""` The prefix to strip from the paths of the headers of this rule. When set, the headers in the `hdrs` attribute of this rule are accessible at their path with this prefix cut off. If it's a relative path, it's taken as a package-relative one. If it's an absolute one, it's understood as a repository-relative path. The prefix in the `include_prefix` attribute is added after this prefix is stripped. This attribute is only legal under `third_party`. |
 | `system_provided` | Boolean; default is `False` If 1, it indicates the shared library required at runtime is provided by the system. In this case, `interface_library` should be specified and `shared_library` should be empty. |
 
@@ -350,7 +350,7 @@ The `layering_check` feature has to be supported by the toolchain
 and requested explicitly, for example via the
 `--features=layering_check` command-line flag or the
 `features` parameter of the
-[`package`](/reference/be/functions#package) function. The toolchains
+[`package`](/versions/8.6.0/reference/be/functions#package) function. The toolchains
 provided by Bazel only support this feature with clang on Unix and macOS.
 
 #### Examples
@@ -438,23 +438,23 @@ cc_library(
 
 | Attributes | |
 | --- | --- |
-| `name` | [Name](/concepts/labels#target-names); required  A unique name for this target. |
-| `deps` | List of [labels](/concepts/labels); default is `[]` The list of other libraries that the library target depends upon. These can be `cc_library` or `objc_library` targets.  See general comments about `deps` at [Typical attributes defined by most build rules](/reference/be/common-definitions#typical-attributes).  These should be names of C++ library rules. When you build a binary that links this rule's library, you will also link the libraries in `deps`.  Despite the "deps" name, not all of this library's clients belong here. Run-time data dependencies belong in `data`. Source files generated by other rules belong in `srcs`.  To link in a pre-compiled third-party library, add its name to the `srcs` instead.  To depend on something without linking it to this library, add its name to the `data` instead. |
-| `srcs` | List of [labels](/concepts/labels); default is `[]` The list of C and C++ files that are processed to create the library target. These are C/C++ source and header files, either non-generated (normal source code) or generated. All `.cc`, `.c`, and `.cpp` files will be compiled. These might be generated files: if a named file is in the `outs` of some other rule, this `cc_library` will automatically depend on that other rule.  Pure assembler files (.s, .asm) are not preprocessed and are typically built using the assembler. Preprocessed assembly files (.S) are preprocessed and are typically built using the C/C++ compiler.  A `.h` file will not be compiled, but will be available for inclusion by sources in this rule. Both `.cc` and `.h` files can directly include headers listed in these `srcs` or in the `hdrs` of this rule or any rule listed in the `deps` argument.  All `#include`d files must be mentioned in the `hdrs` attribute of this or referenced `cc_library` rules, or they should be listed in `srcs` if they are private to this library. See ["Header inclusion checking"](#hdrs) for a more detailed description.  `.so`, `.lo`, and `.a` files are pre-compiled files. Your library might have these as `srcs` if it uses third-party code for which we don't have source code.  If the `srcs` attribute includes the label of another rule, `cc_library` will use the output files of that rule as source files to compile. This is useful for one-off generation of source code (for more than occasional use, it's better to implement a Starlark rule class and use the `cc_common` API)  Permitted `srcs` file types:   * C and C++ source files: `.c`, `.cc`, `.cpp`,   `.cxx`, `.c++`, `.C` * C and C++ header files: `.h`, `.hh`, `.hpp`,   `.hxx`, `.inc`, `.inl`, `.H` * Assembler with C preprocessor: `.S` * Archive: `.a`, `.pic.a` * "Always link" library: `.lo`, `.pic.lo` * Shared library, versioned or unversioned: `.so`,   `.so.version` * Object file: `.o`, `.pic.o`   ... and any rules that produce those files (e.g. `cc_embed_data`). Different extensions denote different programming languages in accordance with gcc convention. |
-| `data` | List of [labels](/concepts/labels); default is `[]` The list of files needed by this library at runtime. See general comments about `data` at [Typical attributes defined by most build rules](/reference/be/common-definitions#typical-attributes). If a `data` is the name of a generated file, then this `cc_library` rule automatically depends on the generating rule.  If a `data` is a rule name, then this `cc_library` rule automatically depends on that rule, and that rule's `outs` are automatically added to this `cc_library`'s data files.  Your C++ code can access these data files like so:   ```   const std::string path = devtools_build::GetDataDependencyFilepath(       "my/test/data/file"); ``` |
-| `hdrs` | List of [labels](/concepts/labels); default is `[]` The list of header files published by this library to be directly included by sources in dependent rules. This is the strongly preferred location for declaring header files that describe the interface for the library. These headers will be made available for inclusion by sources in this rule or in dependent rules. Headers not meant to be included by a client of this library should be listed in the `srcs` attribute instead, even if they are included by a published header. See ["Header inclusion checking"](#hdrs) for a more detailed description.  Permitted `headers` file types: `.h`, `.hh`, `.hpp`, `.hxx`. |
-| `additional_compiler_inputs` | List of [labels](/concepts/labels); default is `[]` Any additional files you might want to pass to the compiler command line, such as sanitizer ignorelists, for example. Files specified here can then be used in copts with the $(location) function. |
-| `additional_linker_inputs` | List of [labels](/concepts/labels); default is `[]` Pass these files to the C++ linker command. For example, compiled Windows .res files can be provided here to be embedded in the binary target. |
+| `name` | [Name](/versions/8.6.0/concepts/labels#target-names); required  A unique name for this target. |
+| `deps` | List of [labels](/versions/8.6.0/concepts/labels); default is `[]` The list of other libraries that the library target depends upon. These can be `cc_library` or `objc_library` targets.  See general comments about `deps` at [Typical attributes defined by most build rules](/versions/8.6.0/reference/be/common-definitions#typical-attributes).  These should be names of C++ library rules. When you build a binary that links this rule's library, you will also link the libraries in `deps`.  Despite the "deps" name, not all of this library's clients belong here. Run-time data dependencies belong in `data`. Source files generated by other rules belong in `srcs`.  To link in a pre-compiled third-party library, add its name to the `srcs` instead.  To depend on something without linking it to this library, add its name to the `data` instead. |
+| `srcs` | List of [labels](/versions/8.6.0/concepts/labels); default is `[]` The list of C and C++ files that are processed to create the library target. These are C/C++ source and header files, either non-generated (normal source code) or generated. All `.cc`, `.c`, and `.cpp` files will be compiled. These might be generated files: if a named file is in the `outs` of some other rule, this `cc_library` will automatically depend on that other rule.  Pure assembler files (.s, .asm) are not preprocessed and are typically built using the assembler. Preprocessed assembly files (.S) are preprocessed and are typically built using the C/C++ compiler.  A `.h` file will not be compiled, but will be available for inclusion by sources in this rule. Both `.cc` and `.h` files can directly include headers listed in these `srcs` or in the `hdrs` of this rule or any rule listed in the `deps` argument.  All `#include`d files must be mentioned in the `hdrs` attribute of this or referenced `cc_library` rules, or they should be listed in `srcs` if they are private to this library. See ["Header inclusion checking"](#hdrs) for a more detailed description.  `.so`, `.lo`, and `.a` files are pre-compiled files. Your library might have these as `srcs` if it uses third-party code for which we don't have source code.  If the `srcs` attribute includes the label of another rule, `cc_library` will use the output files of that rule as source files to compile. This is useful for one-off generation of source code (for more than occasional use, it's better to implement a Starlark rule class and use the `cc_common` API)  Permitted `srcs` file types:   * C and C++ source files: `.c`, `.cc`, `.cpp`,   `.cxx`, `.c++`, `.C` * C and C++ header files: `.h`, `.hh`, `.hpp`,   `.hxx`, `.inc`, `.inl`, `.H` * Assembler with C preprocessor: `.S` * Archive: `.a`, `.pic.a` * "Always link" library: `.lo`, `.pic.lo` * Shared library, versioned or unversioned: `.so`,   `.so.version` * Object file: `.o`, `.pic.o`   ... and any rules that produce those files (e.g. `cc_embed_data`). Different extensions denote different programming languages in accordance with gcc convention. |
+| `data` | List of [labels](/versions/8.6.0/concepts/labels); default is `[]` The list of files needed by this library at runtime. See general comments about `data` at [Typical attributes defined by most build rules](/versions/8.6.0/reference/be/common-definitions#typical-attributes). If a `data` is the name of a generated file, then this `cc_library` rule automatically depends on the generating rule.  If a `data` is a rule name, then this `cc_library` rule automatically depends on that rule, and that rule's `outs` are automatically added to this `cc_library`'s data files.  Your C++ code can access these data files like so:   ```   const std::string path = devtools_build::GetDataDependencyFilepath(       "my/test/data/file"); ``` |
+| `hdrs` | List of [labels](/versions/8.6.0/concepts/labels); default is `[]` The list of header files published by this library to be directly included by sources in dependent rules. This is the strongly preferred location for declaring header files that describe the interface for the library. These headers will be made available for inclusion by sources in this rule or in dependent rules. Headers not meant to be included by a client of this library should be listed in the `srcs` attribute instead, even if they are included by a published header. See ["Header inclusion checking"](#hdrs) for a more detailed description.  Permitted `headers` file types: `.h`, `.hh`, `.hpp`, `.hxx`. |
+| `additional_compiler_inputs` | List of [labels](/versions/8.6.0/concepts/labels); default is `[]` Any additional files you might want to pass to the compiler command line, such as sanitizer ignorelists, for example. Files specified here can then be used in copts with the $(location) function. |
+| `additional_linker_inputs` | List of [labels](/versions/8.6.0/concepts/labels); default is `[]` Pass these files to the C++ linker command. For example, compiled Windows .res files can be provided here to be embedded in the binary target. |
 | `alwayslink` | Boolean; default is `False` If 1, any binary that depends (directly or indirectly) on this C++ library will link in all the object files for the files listed in `srcs`, even if some contain no symbols referenced by the binary. This is useful if your code isn't explicitly called by code in the binary, e.g., if your code registers to receive some callback provided by some service. If alwayslink doesn't work with VS 2017 on Windows, that is due to a [known issue](https://github.com/bazelbuild/bazel/issues/3949), please upgrade your VS 2017 to the latest version. |
-| `conlyopts` | List of strings; default is `[]` Add these options to the C compilation command. Subject to ["Make variable"](/reference/be/make-variables) substitution and [Bourne shell tokenization](/reference/be/common-definitions#sh-tokenization). |
-| `copts` | List of strings; default is `[]` Add these options to the C/C++ compilation command. Subject to ["Make variable"](/reference/be/make-variables) substitution and [Bourne shell tokenization](/reference/be/common-definitions#sh-tokenization). Each string in this attribute is added in the given order to `COPTS` before compiling the binary target. The flags take effect only for compiling this target, not its dependencies, so be careful about header files included elsewhere. All paths should be relative to the workspace, not to the current package. This attribute should not be needed outside of `third_party`.  If the package declares the [feature](/reference/be/functions#package.features) `no_copts_tokenization`, Bourne shell tokenization applies only to strings that consist of a single "Make" variable. |
-| `cxxopts` | List of strings; default is `[]` Add these options to the C++ compilation command. Subject to ["Make variable"](/reference/be/make-variables) substitution and [Bourne shell tokenization](/reference/be/common-definitions#sh-tokenization). |
-| `defines` | List of strings; default is `[]` List of defines to add to the compile line. Subject to ["Make" variable](/reference/be/make-variables) substitution and [Bourne shell tokenization](/reference/be/common-definitions#sh-tokenization). Each string, which must consist of a single Bourne shell token, is prepended with `-D` and added to the compile command line to this target, as well as to every rule that depends on it. Be very careful, since this may have far-reaching effects. When in doubt, add define values to [`local_defines`](#cc_binary.local_defines) instead. |
+| `conlyopts` | List of strings; default is `[]` Add these options to the C compilation command. Subject to ["Make variable"](/versions/8.6.0/reference/be/make-variables) substitution and [Bourne shell tokenization](/versions/8.6.0/reference/be/common-definitions#sh-tokenization). |
+| `copts` | List of strings; default is `[]` Add these options to the C/C++ compilation command. Subject to ["Make variable"](/versions/8.6.0/reference/be/make-variables) substitution and [Bourne shell tokenization](/versions/8.6.0/reference/be/common-definitions#sh-tokenization). Each string in this attribute is added in the given order to `COPTS` before compiling the binary target. The flags take effect only for compiling this target, not its dependencies, so be careful about header files included elsewhere. All paths should be relative to the workspace, not to the current package. This attribute should not be needed outside of `third_party`.  If the package declares the [feature](/versions/8.6.0/reference/be/functions#package.features) `no_copts_tokenization`, Bourne shell tokenization applies only to strings that consist of a single "Make" variable. |
+| `cxxopts` | List of strings; default is `[]` Add these options to the C++ compilation command. Subject to ["Make variable"](/versions/8.6.0/reference/be/make-variables) substitution and [Bourne shell tokenization](/versions/8.6.0/reference/be/common-definitions#sh-tokenization). |
+| `defines` | List of strings; default is `[]` List of defines to add to the compile line. Subject to ["Make" variable](/versions/8.6.0/reference/be/make-variables) substitution and [Bourne shell tokenization](/versions/8.6.0/reference/be/common-definitions#sh-tokenization). Each string, which must consist of a single Bourne shell token, is prepended with `-D` and added to the compile command line to this target, as well as to every rule that depends on it. Be very careful, since this may have far-reaching effects. When in doubt, add define values to [`local_defines`](#cc_binary.local_defines) instead. |
 | `hdrs_check` | String; default is `""` Deprecated, no-op. |
-| `implementation_deps` | List of [labels](/concepts/labels); default is `[]` The list of other libraries that the library target depends on. Unlike with `deps`, the headers and include paths of these libraries (and all their transitive deps) are only used for compilation of this library, and not libraries that depend on it. Libraries specified with `implementation_deps` are still linked in binary targets that depend on this library. |
+| `implementation_deps` | List of [labels](/versions/8.6.0/concepts/labels); default is `[]` The list of other libraries that the library target depends on. Unlike with `deps`, the headers and include paths of these libraries (and all their transitive deps) are only used for compilation of this library, and not libraries that depend on it. Libraries specified with `implementation_deps` are still linked in binary targets that depend on this library. |
 | `include_prefix` | String; default is `""` The prefix to add to the paths of the headers of this rule. When set, the headers in the `hdrs` attribute of this rule are accessible at is the value of this attribute prepended to their repository-relative path. The prefix in the `strip_include_prefix` attribute is removed before this prefix is added. This attribute is only legal under `third_party`. |
-| `includes` | List of strings; default is `[]` List of include dirs to be added to the compile line. Subject to ["Make variable"](/reference/be/make-variables) substitution. Each string is prepended with the package path and passed to the C++ toolchain for expansion via the "include_paths" CROSSTOOL feature. A toolchain running on a POSIX system with typical feature definitions will produce `-isystem path_to_package/include_entry`. This should only be used for third-party libraries that do not conform to the Google style of writing #include statements. Unlike [COPTS](#cc_binary.copts), these flags are added for this rule and every rule that depends on it. (Note: not the rules it depends upon!) Be very careful, since this may have far-reaching effects. When in doubt, add "-I" flags to [COPTS](#cc_binary.copts) instead. The added `include` paths will include generated files as well as files in the source tree. |
-| `linkopts` | List of strings; default is `[]` See [`cc_binary.linkopts`](/reference/be/c-cpp#cc_binary.linkopts). The `linkopts` attribute is also applied to any target that depends, directly or indirectly, on this library via `deps` attributes (or via other attributes that are treated similarly: the [`malloc`](/reference/be/c-cpp#cc_binary.malloc) attribute of [`cc_binary`](/reference/be/c-cpp#cc_binary)). Dependency linkopts take precedence over dependent linkopts (i.e. dependency linkopts appear later in the command line). Linkopts specified in [`--linkopt`](../user-manual#flag--linkopt) take precedence over rule linkopts. |
+| `includes` | List of strings; default is `[]` List of include dirs to be added to the compile line. Subject to ["Make variable"](/versions/8.6.0/reference/be/make-variables) substitution. Each string is prepended with the package path and passed to the C++ toolchain for expansion via the "include_paths" CROSSTOOL feature. A toolchain running on a POSIX system with typical feature definitions will produce `-isystem path_to_package/include_entry`. This should only be used for third-party libraries that do not conform to the Google style of writing #include statements. Unlike [COPTS](#cc_binary.copts), these flags are added for this rule and every rule that depends on it. (Note: not the rules it depends upon!) Be very careful, since this may have far-reaching effects. When in doubt, add "-I" flags to [COPTS](#cc_binary.copts) instead. The added `include` paths will include generated files as well as files in the source tree. |
+| `linkopts` | List of strings; default is `[]` See [`cc_binary.linkopts`](/versions/8.6.0/reference/be/c-cpp#cc_binary.linkopts). The `linkopts` attribute is also applied to any target that depends, directly or indirectly, on this library via `deps` attributes (or via other attributes that are treated similarly: the [`malloc`](/versions/8.6.0/reference/be/c-cpp#cc_binary.malloc) attribute of [`cc_binary`](/versions/8.6.0/reference/be/c-cpp#cc_binary)). Dependency linkopts take precedence over dependent linkopts (i.e. dependency linkopts appear later in the command line). Linkopts specified in [`--linkopt`](/versions/8.6.0/reference/user-manual#flag--linkopt) take precedence over rule linkopts. |
 
 Note that the `linkopts` attribute only applies
 when creating `.so` files or executables, not
@@ -473,15 +473,15 @@ outside of the main repository, e.g. for manual use
 with `dlopen()` or `LD_PRELOAD`,
 it may be better to use a `cc_binary` rule
 with the `linkshared=True` attribute.
-See [`cc_binary.linkshared`](/reference/be/c-cpp#cc_binary.linkshared).
+See [`cc_binary.linkshared`](/versions/8.6.0/reference/be/c-cpp#cc_binary.linkshared).
 
-| `linkstamp` | [Label](/concepts/labels); default is `None` Simultaneously compiles and links the specified C++ source file into the final binary. This trickery is required to introduce timestamp information into binaries; if we compiled the source file to an object file in the usual way, the timestamp would be incorrect. A linkstamp compilation may not include any particular set of compiler flags and so should not depend on any particular header, compiler option, or other build variable. *This option should only be needed in the `base` package.* |
-| `linkstatic` | Boolean; default is `False` For [`cc_binary`](/reference/be/c-cpp#cc_binary) and [`cc_test`](/reference/be/c-cpp#cc_test): link the binary in static mode. For `cc_library.link_static`: see below. By default this option is on for `cc_binary` and off for the rest.  If enabled and this is a binary or test, this option tells the build tool to link in `.a`'s instead of `.so`'s for user libraries whenever possible. System libraries such as libc (but *not* the C/C++ runtime libraries, see below) are still linked dynamically, as are libraries for which there is no static library. So the resulting executable will still be dynamically linked, hence only *mostly* static.  There are really three different ways to link an executable:   * STATIC with fully_static_link feature, in which everything is linked statically;   e.g. "`gcc -static foo.o libbar.a libbaz.a -lm`".    This mode is enabled by specifying `fully_static_link` in the   [`features`](/reference/be/common-definitions#features) attribute. * STATIC, in which all user libraries are linked statically (if a static   version is available), but where system libraries (excluding C/C++ runtime libraries)   are linked dynamically, e.g. "`gcc foo.o libfoo.a libbaz.a -lm`".    This mode is enabled by specifying `linkstatic=True`. * DYNAMIC, in which all libraries are linked dynamically (if a dynamic version is   available), e.g. "`gcc foo.o libfoo.so libbaz.so -lm`".    This mode is enabled by specifying `linkstatic=False`.   If the `linkstatic` attribute or `fully_static_link` in `features` is used outside of `//third_party` please include a comment near the rule to explain why.  The `linkstatic` attribute has a different meaning if used on a [`cc_library()`](/reference/be/c-cpp#cc_library) rule. For a C++ library, `linkstatic=True` indicates that only static linking is allowed, so no `.so` will be produced. linkstatic=False does not prevent static libraries from being created. The attribute is meant to control the creation of dynamic libraries.  There should be very little code built with `linkstatic=False` in production. If `linkstatic=False`, then the build tool will create symlinks to depended-upon shared libraries in the `*.runfiles` area. |
-| `local_defines` | List of strings; default is `[]` List of defines to add to the compile line. Subject to ["Make" variable](/reference/be/make-variables) substitution and [Bourne shell tokenization](/reference/be/common-definitions#sh-tokenization). Each string, which must consist of a single Bourne shell token, is prepended with `-D` and added to the compile command line for this target, but not to its dependents. |
-| `module_interfaces` | List of [labels](/concepts/labels); default is `[]` The list of files are regarded as C++20 Modules Interface. C++ Standard has no restriction about module interface file extension  * Clang use cppm * GCC can use any source file extension * MSVC use ixx  The use is guarded by the flag `--experimental_cpp_modules`. |
+| `linkstamp` | [Label](/versions/8.6.0/concepts/labels); default is `None` Simultaneously compiles and links the specified C++ source file into the final binary. This trickery is required to introduce timestamp information into binaries; if we compiled the source file to an object file in the usual way, the timestamp would be incorrect. A linkstamp compilation may not include any particular set of compiler flags and so should not depend on any particular header, compiler option, or other build variable. *This option should only be needed in the `base` package.* |
+| `linkstatic` | Boolean; default is `False` For [`cc_binary`](/versions/8.6.0/reference/be/c-cpp#cc_binary) and [`cc_test`](/versions/8.6.0/reference/be/c-cpp#cc_test): link the binary in static mode. For `cc_library.link_static`: see below. By default this option is on for `cc_binary` and off for the rest.  If enabled and this is a binary or test, this option tells the build tool to link in `.a`'s instead of `.so`'s for user libraries whenever possible. System libraries such as libc (but *not* the C/C++ runtime libraries, see below) are still linked dynamically, as are libraries for which there is no static library. So the resulting executable will still be dynamically linked, hence only *mostly* static.  There are really three different ways to link an executable:   * STATIC with fully_static_link feature, in which everything is linked statically;   e.g. "`gcc -static foo.o libbar.a libbaz.a -lm`".    This mode is enabled by specifying `fully_static_link` in the   [`features`](/versions/8.6.0/reference/be/common-definitions#features) attribute. * STATIC, in which all user libraries are linked statically (if a static   version is available), but where system libraries (excluding C/C++ runtime libraries)   are linked dynamically, e.g. "`gcc foo.o libfoo.a libbaz.a -lm`".    This mode is enabled by specifying `linkstatic=True`. * DYNAMIC, in which all libraries are linked dynamically (if a dynamic version is   available), e.g. "`gcc foo.o libfoo.so libbaz.so -lm`".    This mode is enabled by specifying `linkstatic=False`.   If the `linkstatic` attribute or `fully_static_link` in `features` is used outside of `//third_party` please include a comment near the rule to explain why.  The `linkstatic` attribute has a different meaning if used on a [`cc_library()`](/versions/8.6.0/reference/be/c-cpp#cc_library) rule. For a C++ library, `linkstatic=True` indicates that only static linking is allowed, so no `.so` will be produced. linkstatic=False does not prevent static libraries from being created. The attribute is meant to control the creation of dynamic libraries.  There should be very little code built with `linkstatic=False` in production. If `linkstatic=False`, then the build tool will create symlinks to depended-upon shared libraries in the `*.runfiles` area. |
+| `local_defines` | List of strings; default is `[]` List of defines to add to the compile line. Subject to ["Make" variable](/versions/8.6.0/reference/be/make-variables) substitution and [Bourne shell tokenization](/versions/8.6.0/reference/be/common-definitions#sh-tokenization). Each string, which must consist of a single Bourne shell token, is prepended with `-D` and added to the compile command line for this target, but not to its dependents. |
+| `module_interfaces` | List of [labels](/versions/8.6.0/concepts/labels); default is `[]` The list of files are regarded as C++20 Modules Interface. C++ Standard has no restriction about module interface file extension  * Clang use cppm * GCC can use any source file extension * MSVC use ixx  The use is guarded by the flag `--experimental_cpp_modules`. |
 | `strip_include_prefix` | String; default is `""` The prefix to strip from the paths of the headers of this rule. When set, the headers in the `hdrs` attribute of this rule are accessible at their path with this prefix cut off. If it's a relative path, it's taken as a package-relative one. If it's an absolute one, it's understood as a repository-relative path. The prefix in the `include_prefix` attribute is added after this prefix is stripped. This attribute is only legal under `third_party`. |
-| `textual_hdrs` | List of [labels](/concepts/labels); default is `[]` The list of header files published by this library to be textually included by sources in dependent rules. This is the location for declaring header files that cannot be compiled on their own; that is, they always need to be textually included by other source files to build valid code. |
-| `win_def_file` | [Label](/concepts/labels); default is `None` The Windows DEF file to be passed to linker. This attribute should only be used when Windows is the target platform. It can be used to [export symbols](https://msdn.microsoft.com/en-us/library/d91k01sh.aspx) during linking a shared library. |
+| `textual_hdrs` | List of [labels](/versions/8.6.0/concepts/labels); default is `[]` The list of header files published by this library to be textually included by sources in dependent rules. This is the location for declaring header files that cannot be compiled on their own; that is, they always need to be textually included by other source files to build valid code. |
+| `win_def_file` | [Label](/versions/8.6.0/concepts/labels); default is `None` The Windows DEF file to be passed to linker. This attribute should only be used when Windows is the target platform. It can be used to [export symbols](https://msdn.microsoft.com/en-us/library/d91k01sh.aspx) during linking a shared library. |
 
 ## cc_shared_library
 
@@ -617,17 +617,17 @@ dependency or make sure that the `exports_filter` doesn't catch this target.
 
 | Attributes | |
 | --- | --- |
-| `name` | [Name](/concepts/labels#target-names); required  A unique name for this target. |
-| `deps` | List of [labels](/concepts/labels); default is `[]` Top level libraries that will unconditionally be statically linked into the shared library after being whole-archived. Any transitive library dependency of these direct deps will be linked into this shared library as long as they have not already been linked by a `cc_shared_library` in `dynamic_deps`.  During analysis, the rule implementation will consider any target listed in `deps` as being exported by the shared library in order to give errors when multiple `cc_shared_libraries` export the same targets. The rule implementation does not take care of informing the linker about which symbols should be exported by the shared object. The user should take care of this via linker scripts or visibility declarations in the source code.  The implementation will also trigger errors whenever the same library is linked statically into more than one `cc_shared_library`. This can be avoided by adding `"LINKABLE_MORE_THAN_ONCE"` to the `cc_library.tags` or by listing the `cc_library` as an export of one of the shared libraries so that one can be made a `dynamic_dep` of the other. |
-| `additional_linker_inputs` | List of [labels](/concepts/labels); default is `[]` Any additional files that you may want to pass to the linker, for example, linker scripts. You have to separately pass any linker flags that the linker needs in order to be aware of this file. You can do so via the `user_link_flags` attribute. |
-| `dynamic_deps` | List of [labels](/concepts/labels); default is `[]` These are other `cc_shared_library` dependencies the current target depends on. The `cc_shared_library` implementation will use the list of `dynamic_deps` (transitively, i.e. also the `dynamic_deps` of the current target's `dynamic_deps`) to decide which `cc_libraries` in the transitive `deps` should not be linked in because they are already provided by a different `cc_shared_library`. |
+| `name` | [Name](/versions/8.6.0/concepts/labels#target-names); required  A unique name for this target. |
+| `deps` | List of [labels](/versions/8.6.0/concepts/labels); default is `[]` Top level libraries that will unconditionally be statically linked into the shared library after being whole-archived. Any transitive library dependency of these direct deps will be linked into this shared library as long as they have not already been linked by a `cc_shared_library` in `dynamic_deps`.  During analysis, the rule implementation will consider any target listed in `deps` as being exported by the shared library in order to give errors when multiple `cc_shared_libraries` export the same targets. The rule implementation does not take care of informing the linker about which symbols should be exported by the shared object. The user should take care of this via linker scripts or visibility declarations in the source code.  The implementation will also trigger errors whenever the same library is linked statically into more than one `cc_shared_library`. This can be avoided by adding `"LINKABLE_MORE_THAN_ONCE"` to the `cc_library.tags` or by listing the `cc_library` as an export of one of the shared libraries so that one can be made a `dynamic_dep` of the other. |
+| `additional_linker_inputs` | List of [labels](/versions/8.6.0/concepts/labels); default is `[]` Any additional files that you may want to pass to the linker, for example, linker scripts. You have to separately pass any linker flags that the linker needs in order to be aware of this file. You can do so via the `user_link_flags` attribute. |
+| `dynamic_deps` | List of [labels](/versions/8.6.0/concepts/labels); default is `[]` These are other `cc_shared_library` dependencies the current target depends on. The `cc_shared_library` implementation will use the list of `dynamic_deps` (transitively, i.e. also the `dynamic_deps` of the current target's `dynamic_deps`) to decide which `cc_libraries` in the transitive `deps` should not be linked in because they are already provided by a different `cc_shared_library`. |
 | `experimental_disable_topo_sort_do_not_use_remove_before_7_0` | Boolean; default is `False` |
 | `exports_filter` | List of strings; default is `[]` This attribute contains a list of targets that are claimed to be exported by the current shared library. Any target `deps` is already understood to be exported by the shared library. This attribute should be used to list any targets that are exported by the shared library but are transitive dependencies of `deps`.  Note that this attribute is not actually adding a dependency edge to those targets, the dependency edge should instead be created by `deps`.The entries in this attribute are just strings. Keep in mind that when placing a target in this attribute, this is considered a claim that the shared library exports the symbols from that target. The `cc_shared_library` logic doesn't actually handle telling the linker which symbols should be exported.  The following syntax is allowed:  `//foo:__pkg__` to account for any target in foo/BUILD  `//foo:__subpackages__` to account for any target in foo/BUILD or any other package below foo/ like foo/bar/BUILD |
-| `roots` | List of [labels](/concepts/labels); default is `[]` |
+| `roots` | List of [labels](/versions/8.6.0/concepts/labels); default is `[]` |
 | `shared_lib_name` | String; default is `""` By default cc_shared_library will use a name for the shared library output file based on the target's name and the platform. This includes an extension and sometimes a prefix. Sometimes you may not want the default name, for example, when loading C++ shared libraries for Python the default lib\* prefix is often not desired, in which case you can use this attribute to choose a custom name. |
 | `static_deps` | List of strings; default is `[]` |
 | `user_link_flags` | List of strings; default is `[]` Any additional flags that you may want to pass to the linker. For example, to make the linker aware of a linker script passed via additional_linker_inputs you can use the following:  ```  cc_shared_library(     name = "foo_shared",     additional_linker_inputs = select({       "//src/conditions:linux": [         ":foo.lds",         ":additional_script.txt",       ],       "//conditions:default": []}),     user_link_flags = select({       "//src/conditions:linux": [         "-Wl,-rpath,kittens",         "-Wl,--version-script=$(location :foo.lds)",         "-Wl,--script=$(location :additional_script.txt)",       ],       "//conditions:default": []}),       ...  ) ``` |
-| `win_def_file` | [Label](/concepts/labels); default is `None` The Windows DEF file to be passed to linker. This attribute should only be used when Windows is the target platform. It can be used to [export symbols](https://msdn.microsoft.com/en-us/library/d91k01sh.aspx) during linking a shared library. |
+| `win_def_file` | [Label](/versions/8.6.0/concepts/labels); default is `None` The Windows DEF file to be passed to linker. This attribute should only be used when Windows is the target platform. It can be used to [export symbols](https://msdn.microsoft.com/en-us/library/d91k01sh.aspx) during linking a shared library. |
 
 ## cc_static_library
 
@@ -684,8 +684,8 @@ it in one of two ways:
 
 | Attributes | |
 | --- | --- |
-| `name` | [Name](/concepts/labels#target-names); required  A unique name for this target. |
-| `deps` | List of [labels](/concepts/labels); default is `[]` The list of targets to combine into a static library, including all their transitive dependencies. Dependencies that do not provide any object files are not included in the static library, but their labels are collected in the file provided by the `linkdeps` output group. |
+| `name` | [Name](/versions/8.6.0/concepts/labels#target-names); required  A unique name for this target. |
+| `deps` | List of [labels](/versions/8.6.0/concepts/labels); default is `[]` The list of targets to combine into a static library, including all their transitive dependencies. Dependencies that do not provide any object files are not included in the static library, but their labels are collected in the file provided by the `linkdeps` output group. |
 
 ## cc_test
 
@@ -700,7 +700,7 @@ is a binary wrapper around some testing code.
 
 *By default, C++ tests are dynamically linked.*
 To statically link a unit test, specify
-[`linkstatic=True`](/reference/be/c-cpp#cc_binary.linkstatic).
+[`linkstatic=True`](/versions/8.6.0/reference/be/c-cpp#cc_binary.linkstatic).
 It would probably be good to comment why your test needs
 `linkstatic`; this is probably not obvious.
 
@@ -715,37 +715,37 @@ It would probably be good to comment why your test needs
   information package file suitable for debugging remotely deployed binaries. Else: an
   empty file.
 
-See the [cc_binary()](/reference/be/c-cpp#cc_binary_args) arguments, except that
+See the [cc_binary()](/versions/8.6.0/reference/be/c-cpp#cc_binary_args) arguments, except that
 the `stamp` argument is set to 0 by default for tests and
-that `cc_test` has extra [attributes common to all test rules (\*\_test)](/reference/be/common-definitions#common-attributes-tests).
+that `cc_test` has extra [attributes common to all test rules (\*\_test)](/versions/8.6.0/reference/be/common-definitions#common-attributes-tests).
 
 ### Arguments
 
 | Attributes | |
 | --- | --- |
-| `name` | [Name](/concepts/labels#target-names); required  A unique name for this target. |
-| `deps` | List of [labels](/concepts/labels); default is `[]` The list of other libraries to be linked in to the binary target. These can be `cc_library` or `objc_library` targets. It is also allowed to put linker scripts (.lds) into deps, and reference them in [linkopts](#cc_binary.linkopts). |
-| `srcs` | List of [labels](/concepts/labels); default is `[]` The list of C and C++ files that are processed to create the library target. These are C/C++ source and header files, either non-generated (normal source code) or generated. All `.cc`, `.c`, and `.cpp` files will be compiled. These might be generated files: if a named file is in the `outs` of some other rule, this `cc_library` will automatically depend on that other rule.  Pure assembler files (.s, .asm) are not preprocessed and are typically built using the assembler. Preprocessed assembly files (.S) are preprocessed and are typically built using the C/C++ compiler.  A `.h` file will not be compiled, but will be available for inclusion by sources in this rule. Both `.cc` and `.h` files can directly include headers listed in these `srcs` or in the `hdrs` of this rule or any rule listed in the `deps` argument.  All `#include`d files must be mentioned in the `hdrs` attribute of this or referenced `cc_library` rules, or they should be listed in `srcs` if they are private to this library. See ["Header inclusion checking"](#hdrs) for a more detailed description.  `.so`, `.lo`, and `.a` files are pre-compiled files. Your library might have these as `srcs` if it uses third-party code for which we don't have source code.  If the `srcs` attribute includes the label of another rule, `cc_library` will use the output files of that rule as source files to compile. This is useful for one-off generation of source code (for more than occasional use, it's better to implement a Starlark rule class and use the `cc_common` API)  Permitted `srcs` file types:   * C and C++ source files: `.c`, `.cc`, `.cpp`,   `.cxx`, `.c++`, `.C` * C and C++ header files: `.h`, `.hh`, `.hpp`,   `.hxx`, `.inc`, `.inl`, `.H` * Assembler with C preprocessor: `.S` * Archive: `.a`, `.pic.a` * "Always link" library: `.lo`, `.pic.lo` * Shared library, versioned or unversioned: `.so`,   `.so.version` * Object file: `.o`, `.pic.o`   ... and any rules that produce those files (e.g. `cc_embed_data`). Different extensions denote different programming languages in accordance with gcc convention. |
-| `data` | List of [labels](/concepts/labels); default is `[]` The list of files needed by this library at runtime. See general comments about `data` at [Typical attributes defined by most build rules](/reference/be/common-definitions#typical-attributes). If a `data` is the name of a generated file, then this `cc_library` rule automatically depends on the generating rule.  If a `data` is a rule name, then this `cc_library` rule automatically depends on that rule, and that rule's `outs` are automatically added to this `cc_library`'s data files.  Your C++ code can access these data files like so:   ```   const std::string path = devtools_build::GetDataDependencyFilepath(       "my/test/data/file"); ``` |
-| `additional_linker_inputs` | List of [labels](/concepts/labels); default is `[]` Pass these files to the C++ linker command. For example, compiled Windows .res files can be provided here to be embedded in the binary target. |
-| `conlyopts` | List of strings; default is `[]` Add these options to the C compilation command. Subject to ["Make variable"](/reference/be/make-variables) substitution and [Bourne shell tokenization](/reference/be/common-definitions#sh-tokenization). |
-| `copts` | List of strings; default is `[]` Add these options to the C/C++ compilation command. Subject to ["Make variable"](/reference/be/make-variables) substitution and [Bourne shell tokenization](/reference/be/common-definitions#sh-tokenization). Each string in this attribute is added in the given order to `COPTS` before compiling the binary target. The flags take effect only for compiling this target, not its dependencies, so be careful about header files included elsewhere. All paths should be relative to the workspace, not to the current package. This attribute should not be needed outside of `third_party`.  If the package declares the [feature](/reference/be/functions#package.features) `no_copts_tokenization`, Bourne shell tokenization applies only to strings that consist of a single "Make" variable. |
-| `cxxopts` | List of strings; default is `[]` Add these options to the C++ compilation command. Subject to ["Make variable"](/reference/be/make-variables) substitution and [Bourne shell tokenization](/reference/be/common-definitions#sh-tokenization). |
-| `defines` | List of strings; default is `[]` List of defines to add to the compile line. Subject to ["Make" variable](/reference/be/make-variables) substitution and [Bourne shell tokenization](/reference/be/common-definitions#sh-tokenization). Each string, which must consist of a single Bourne shell token, is prepended with `-D` and added to the compile command line to this target, as well as to every rule that depends on it. Be very careful, since this may have far-reaching effects. When in doubt, add define values to [`local_defines`](#cc_binary.local_defines) instead. |
-| `dynamic_deps` | List of [labels](/concepts/labels); default is `[]` These are other `cc_shared_library` dependencies the current target depends on. The `cc_shared_library` implementation will use the list of `dynamic_deps` (transitively, i.e. also the `dynamic_deps` of the current target's `dynamic_deps`) to decide which `cc_libraries` in the transitive `deps` should not be linked in because they are already provided by a different `cc_shared_library`. |
+| `name` | [Name](/versions/8.6.0/concepts/labels#target-names); required  A unique name for this target. |
+| `deps` | List of [labels](/versions/8.6.0/concepts/labels); default is `[]` The list of other libraries to be linked in to the binary target. These can be `cc_library` or `objc_library` targets. It is also allowed to put linker scripts (.lds) into deps, and reference them in [linkopts](#cc_binary.linkopts). |
+| `srcs` | List of [labels](/versions/8.6.0/concepts/labels); default is `[]` The list of C and C++ files that are processed to create the library target. These are C/C++ source and header files, either non-generated (normal source code) or generated. All `.cc`, `.c`, and `.cpp` files will be compiled. These might be generated files: if a named file is in the `outs` of some other rule, this `cc_library` will automatically depend on that other rule.  Pure assembler files (.s, .asm) are not preprocessed and are typically built using the assembler. Preprocessed assembly files (.S) are preprocessed and are typically built using the C/C++ compiler.  A `.h` file will not be compiled, but will be available for inclusion by sources in this rule. Both `.cc` and `.h` files can directly include headers listed in these `srcs` or in the `hdrs` of this rule or any rule listed in the `deps` argument.  All `#include`d files must be mentioned in the `hdrs` attribute of this or referenced `cc_library` rules, or they should be listed in `srcs` if they are private to this library. See ["Header inclusion checking"](#hdrs) for a more detailed description.  `.so`, `.lo`, and `.a` files are pre-compiled files. Your library might have these as `srcs` if it uses third-party code for which we don't have source code.  If the `srcs` attribute includes the label of another rule, `cc_library` will use the output files of that rule as source files to compile. This is useful for one-off generation of source code (for more than occasional use, it's better to implement a Starlark rule class and use the `cc_common` API)  Permitted `srcs` file types:   * C and C++ source files: `.c`, `.cc`, `.cpp`,   `.cxx`, `.c++`, `.C` * C and C++ header files: `.h`, `.hh`, `.hpp`,   `.hxx`, `.inc`, `.inl`, `.H` * Assembler with C preprocessor: `.S` * Archive: `.a`, `.pic.a` * "Always link" library: `.lo`, `.pic.lo` * Shared library, versioned or unversioned: `.so`,   `.so.version` * Object file: `.o`, `.pic.o`   ... and any rules that produce those files (e.g. `cc_embed_data`). Different extensions denote different programming languages in accordance with gcc convention. |
+| `data` | List of [labels](/versions/8.6.0/concepts/labels); default is `[]` The list of files needed by this library at runtime. See general comments about `data` at [Typical attributes defined by most build rules](/versions/8.6.0/reference/be/common-definitions#typical-attributes). If a `data` is the name of a generated file, then this `cc_library` rule automatically depends on the generating rule.  If a `data` is a rule name, then this `cc_library` rule automatically depends on that rule, and that rule's `outs` are automatically added to this `cc_library`'s data files.  Your C++ code can access these data files like so:   ```   const std::string path = devtools_build::GetDataDependencyFilepath(       "my/test/data/file"); ``` |
+| `additional_linker_inputs` | List of [labels](/versions/8.6.0/concepts/labels); default is `[]` Pass these files to the C++ linker command. For example, compiled Windows .res files can be provided here to be embedded in the binary target. |
+| `conlyopts` | List of strings; default is `[]` Add these options to the C compilation command. Subject to ["Make variable"](/versions/8.6.0/reference/be/make-variables) substitution and [Bourne shell tokenization](/versions/8.6.0/reference/be/common-definitions#sh-tokenization). |
+| `copts` | List of strings; default is `[]` Add these options to the C/C++ compilation command. Subject to ["Make variable"](/versions/8.6.0/reference/be/make-variables) substitution and [Bourne shell tokenization](/versions/8.6.0/reference/be/common-definitions#sh-tokenization). Each string in this attribute is added in the given order to `COPTS` before compiling the binary target. The flags take effect only for compiling this target, not its dependencies, so be careful about header files included elsewhere. All paths should be relative to the workspace, not to the current package. This attribute should not be needed outside of `third_party`.  If the package declares the [feature](/versions/8.6.0/reference/be/functions#package.features) `no_copts_tokenization`, Bourne shell tokenization applies only to strings that consist of a single "Make" variable. |
+| `cxxopts` | List of strings; default is `[]` Add these options to the C++ compilation command. Subject to ["Make variable"](/versions/8.6.0/reference/be/make-variables) substitution and [Bourne shell tokenization](/versions/8.6.0/reference/be/common-definitions#sh-tokenization). |
+| `defines` | List of strings; default is `[]` List of defines to add to the compile line. Subject to ["Make" variable](/versions/8.6.0/reference/be/make-variables) substitution and [Bourne shell tokenization](/versions/8.6.0/reference/be/common-definitions#sh-tokenization). Each string, which must consist of a single Bourne shell token, is prepended with `-D` and added to the compile command line to this target, as well as to every rule that depends on it. Be very careful, since this may have far-reaching effects. When in doubt, add define values to [`local_defines`](#cc_binary.local_defines) instead. |
+| `dynamic_deps` | List of [labels](/versions/8.6.0/concepts/labels); default is `[]` These are other `cc_shared_library` dependencies the current target depends on. The `cc_shared_library` implementation will use the list of `dynamic_deps` (transitively, i.e. also the `dynamic_deps` of the current target's `dynamic_deps`) to decide which `cc_libraries` in the transitive `deps` should not be linked in because they are already provided by a different `cc_shared_library`. |
 | `hdrs_check` | String; default is `""` Deprecated, no-op. |
-| `includes` | List of strings; default is `[]` List of include dirs to be added to the compile line. Subject to ["Make variable"](/reference/be/make-variables) substitution. Each string is prepended with the package path and passed to the C++ toolchain for expansion via the "include_paths" CROSSTOOL feature. A toolchain running on a POSIX system with typical feature definitions will produce `-isystem path_to_package/include_entry`. This should only be used for third-party libraries that do not conform to the Google style of writing #include statements. Unlike [COPTS](#cc_binary.copts), these flags are added for this rule and every rule that depends on it. (Note: not the rules it depends upon!) Be very careful, since this may have far-reaching effects. When in doubt, add "-I" flags to [COPTS](#cc_binary.copts) instead. The added `include` paths will include generated files as well as files in the source tree. |
-| `link_extra_lib` | [Label](/concepts/labels); default is `"@bazel_tools//tools/cpp:link_extra_lib"` Control linking of extra libraries. By default, C++ binaries are linked against `//tools/cpp:link_extra_lib`, which by default depends on the label flag `//tools/cpp:link_extra_libs`. Without setting the flag, this library is empty by default. Setting the label flag allows linking optional dependencies, such as overrides for weak symbols, interceptors for shared library functions, or special runtime libraries (for malloc replacements, prefer `malloc` or `--custom_malloc`). Setting this attribute to `None` disables this behaviour. |
-| `linkopts` | List of strings; default is `[]` Add these flags to the C++ linker command. Subject to ["Make" variable](make-variables) substitution, [Bourne shell tokenization](common-definitions#sh-tokenization) and [label expansion](common-definitions#label-expansion). Each string in this attribute is added to `LINKOPTS` before linking the binary target. Each element of this list that does not start with `$` or `-` is assumed to be the label of a target in `deps`. The list of files generated by that target is appended to the linker options. An error is reported if the label is invalid, or is not declared in `deps`. |
+| `includes` | List of strings; default is `[]` List of include dirs to be added to the compile line. Subject to ["Make variable"](/versions/8.6.0/reference/be/make-variables) substitution. Each string is prepended with the package path and passed to the C++ toolchain for expansion via the "include_paths" CROSSTOOL feature. A toolchain running on a POSIX system with typical feature definitions will produce `-isystem path_to_package/include_entry`. This should only be used for third-party libraries that do not conform to the Google style of writing #include statements. Unlike [COPTS](#cc_binary.copts), these flags are added for this rule and every rule that depends on it. (Note: not the rules it depends upon!) Be very careful, since this may have far-reaching effects. When in doubt, add "-I" flags to [COPTS](#cc_binary.copts) instead. The added `include` paths will include generated files as well as files in the source tree. |
+| `link_extra_lib` | [Label](/versions/8.6.0/concepts/labels); default is `"@bazel_tools//tools/cpp:link_extra_lib"` Control linking of extra libraries. By default, C++ binaries are linked against `//tools/cpp:link_extra_lib`, which by default depends on the label flag `//tools/cpp:link_extra_libs`. Without setting the flag, this library is empty by default. Setting the label flag allows linking optional dependencies, such as overrides for weak symbols, interceptors for shared library functions, or special runtime libraries (for malloc replacements, prefer `malloc` or `--custom_malloc`). Setting this attribute to `None` disables this behaviour. |
+| `linkopts` | List of strings; default is `[]` Add these flags to the C++ linker command. Subject to ["Make" variable](/versions/8.6.0/reference/be/make-variables) substitution, [Bourne shell tokenization](/versions/8.6.0/reference/be/common-definitions#sh-tokenization) and [label expansion](/versions/8.6.0/reference/be/common-definitions#label-expansion). Each string in this attribute is added to `LINKOPTS` before linking the binary target. Each element of this list that does not start with `$` or `-` is assumed to be the label of a target in `deps`. The list of files generated by that target is appended to the linker options. An error is reported if the label is invalid, or is not declared in `deps`. |
 | `linkshared` | Boolean; default is `False` Create a shared library. To enable this attribute, include `linkshared=True` in your rule. By default this option is off. The presence of this flag means that linking occurs with the `-shared` flag to `gcc`, and the resulting shared library is suitable for loading into for example a Java program. However, for build purposes it will never be linked into the dependent binary, as it is assumed that shared libraries built with a [cc_binary](#cc_binary) rule are only loaded manually by other programs, so it should not be considered a substitute for the [cc_library](#cc_library) rule. For sake of scalability we recommend avoiding this approach altogether and simply letting `java_library` depend on `cc_library` rules instead.  If you specify both `linkopts=['-static']` and `linkshared=True`, you get a single completely self-contained unit. If you specify both `linkstatic=True` and `linkshared=True`, you get a single, mostly self-contained unit. |
-| `linkstatic` | Boolean; default is `False` For [`cc_binary`](/reference/be/c-cpp#cc_binary) and [`cc_test`](/reference/be/c-cpp#cc_test): link the binary in static mode. For `cc_library.link_static`: see below. By default this option is on for `cc_binary` and off for the rest.  If enabled and this is a binary or test, this option tells the build tool to link in `.a`'s instead of `.so`'s for user libraries whenever possible. System libraries such as libc (but *not* the C/C++ runtime libraries, see below) are still linked dynamically, as are libraries for which there is no static library. So the resulting executable will still be dynamically linked, hence only *mostly* static.  There are really three different ways to link an executable:   * STATIC with fully_static_link feature, in which everything is linked statically;   e.g. "`gcc -static foo.o libbar.a libbaz.a -lm`".    This mode is enabled by specifying `fully_static_link` in the   [`features`](/reference/be/common-definitions#features) attribute. * STATIC, in which all user libraries are linked statically (if a static   version is available), but where system libraries (excluding C/C++ runtime libraries)   are linked dynamically, e.g. "`gcc foo.o libfoo.a libbaz.a -lm`".    This mode is enabled by specifying `linkstatic=True`. * DYNAMIC, in which all libraries are linked dynamically (if a dynamic version is   available), e.g. "`gcc foo.o libfoo.so libbaz.so -lm`".    This mode is enabled by specifying `linkstatic=False`.   If the `linkstatic` attribute or `fully_static_link` in `features` is used outside of `//third_party` please include a comment near the rule to explain why.  The `linkstatic` attribute has a different meaning if used on a [`cc_library()`](/reference/be/c-cpp#cc_library) rule. For a C++ library, `linkstatic=True` indicates that only static linking is allowed, so no `.so` will be produced. linkstatic=False does not prevent static libraries from being created. The attribute is meant to control the creation of dynamic libraries.  There should be very little code built with `linkstatic=False` in production. If `linkstatic=False`, then the build tool will create symlinks to depended-upon shared libraries in the `*.runfiles` area. |
-| `local_defines` | List of strings; default is `[]` List of defines to add to the compile line. Subject to ["Make" variable](/reference/be/make-variables) substitution and [Bourne shell tokenization](/reference/be/common-definitions#sh-tokenization). Each string, which must consist of a single Bourne shell token, is prepended with `-D` and added to the compile command line for this target, but not to its dependents. |
-| `malloc` | [Label](/concepts/labels); default is `"@bazel_tools//tools/cpp:malloc"` Override the default dependency on malloc. By default, C++ binaries are linked against `//tools/cpp:malloc`, which is an empty library so the binary ends up using libc malloc. This label must refer to a `cc_library`. If compilation is for a non-C++ rule, this option has no effect. The value of this attribute is ignored if `linkshared=True` is specified. |
-| `module_interfaces` | List of [labels](/concepts/labels); default is `[]` The list of files are regarded as C++20 Modules Interface. C++ Standard has no restriction about module interface file extension  * Clang use cppm * GCC can use any source file extension * MSVC use ixx  The use is guarded by the flag `--experimental_cpp_modules`. |
-| `nocopts` | String; default is `""` Remove matching options from the C++ compilation command. Subject to ["Make" variable](/reference/be/make-variables) substitution. The value of this attribute is interpreted as a regular expression. Any preexisting `COPTS` that match this regular expression (including values explicitly specified in the rule's [copts](#cc_binary.copts) attribute) will be removed from `COPTS` for purposes of compiling this rule. This attribute should not be needed or used outside of `third_party`. The values are not preprocessed in any way other than the "Make" variable substitution. |
-| `reexport_deps` | List of [labels](/concepts/labels); default is `[]` |
-| `stamp` | Integer; default is `0` Whether to encode build information into the binary. Possible values:  * `stamp = 1`: Always stamp the build information into the binary, even in   [`--nostamp`](/docs/user-manual#flag--stamp) builds. **This   setting should be avoided**, since it potentially kills remote caching for the   binary and any downstream actions that depend on it. * `stamp = 0`: Always replace build information by constant values. This   gives good build result caching. * `stamp = -1`: Embedding of build information is controlled by the   [`--[no]stamp`](/docs/user-manual#flag--stamp) flag.   Stamped binaries are *not* rebuilt unless their dependencies change. |
-| `win_def_file` | [Label](/concepts/labels); default is `None` The Windows DEF file to be passed to linker. This attribute should only be used when Windows is the target platform. It can be used to [export symbols](https://msdn.microsoft.com/en-us/library/d91k01sh.aspx) during linking a shared library. |
+| `linkstatic` | Boolean; default is `False` For [`cc_binary`](/versions/8.6.0/reference/be/c-cpp#cc_binary) and [`cc_test`](/versions/8.6.0/reference/be/c-cpp#cc_test): link the binary in static mode. For `cc_library.link_static`: see below. By default this option is on for `cc_binary` and off for the rest.  If enabled and this is a binary or test, this option tells the build tool to link in `.a`'s instead of `.so`'s for user libraries whenever possible. System libraries such as libc (but *not* the C/C++ runtime libraries, see below) are still linked dynamically, as are libraries for which there is no static library. So the resulting executable will still be dynamically linked, hence only *mostly* static.  There are really three different ways to link an executable:   * STATIC with fully_static_link feature, in which everything is linked statically;   e.g. "`gcc -static foo.o libbar.a libbaz.a -lm`".    This mode is enabled by specifying `fully_static_link` in the   [`features`](/versions/8.6.0/reference/be/common-definitions#features) attribute. * STATIC, in which all user libraries are linked statically (if a static   version is available), but where system libraries (excluding C/C++ runtime libraries)   are linked dynamically, e.g. "`gcc foo.o libfoo.a libbaz.a -lm`".    This mode is enabled by specifying `linkstatic=True`. * DYNAMIC, in which all libraries are linked dynamically (if a dynamic version is   available), e.g. "`gcc foo.o libfoo.so libbaz.so -lm`".    This mode is enabled by specifying `linkstatic=False`.   If the `linkstatic` attribute or `fully_static_link` in `features` is used outside of `//third_party` please include a comment near the rule to explain why.  The `linkstatic` attribute has a different meaning if used on a [`cc_library()`](/versions/8.6.0/reference/be/c-cpp#cc_library) rule. For a C++ library, `linkstatic=True` indicates that only static linking is allowed, so no `.so` will be produced. linkstatic=False does not prevent static libraries from being created. The attribute is meant to control the creation of dynamic libraries.  There should be very little code built with `linkstatic=False` in production. If `linkstatic=False`, then the build tool will create symlinks to depended-upon shared libraries in the `*.runfiles` area. |
+| `local_defines` | List of strings; default is `[]` List of defines to add to the compile line. Subject to ["Make" variable](/versions/8.6.0/reference/be/make-variables) substitution and [Bourne shell tokenization](/versions/8.6.0/reference/be/common-definitions#sh-tokenization). Each string, which must consist of a single Bourne shell token, is prepended with `-D` and added to the compile command line for this target, but not to its dependents. |
+| `malloc` | [Label](/versions/8.6.0/concepts/labels); default is `"@bazel_tools//tools/cpp:malloc"` Override the default dependency on malloc. By default, C++ binaries are linked against `//tools/cpp:malloc`, which is an empty library so the binary ends up using libc malloc. This label must refer to a `cc_library`. If compilation is for a non-C++ rule, this option has no effect. The value of this attribute is ignored if `linkshared=True` is specified. |
+| `module_interfaces` | List of [labels](/versions/8.6.0/concepts/labels); default is `[]` The list of files are regarded as C++20 Modules Interface. C++ Standard has no restriction about module interface file extension  * Clang use cppm * GCC can use any source file extension * MSVC use ixx  The use is guarded by the flag `--experimental_cpp_modules`. |
+| `nocopts` | String; default is `""` Remove matching options from the C++ compilation command. Subject to ["Make" variable](/versions/8.6.0/reference/be/make-variables) substitution. The value of this attribute is interpreted as a regular expression. Any preexisting `COPTS` that match this regular expression (including values explicitly specified in the rule's [copts](#cc_binary.copts) attribute) will be removed from `COPTS` for purposes of compiling this rule. This attribute should not be needed or used outside of `third_party`. The values are not preprocessed in any way other than the "Make" variable substitution. |
+| `reexport_deps` | List of [labels](/versions/8.6.0/concepts/labels); default is `[]` |
+| `stamp` | Integer; default is `0` Whether to encode build information into the binary. Possible values:  * `stamp = 1`: Always stamp the build information into the binary, even in   [`--nostamp`](/versions/8.6.0/docs/user-manual#flag--stamp) builds. **This   setting should be avoided**, since it potentially kills remote caching for the   binary and any downstream actions that depend on it. * `stamp = 0`: Always replace build information by constant values. This   gives good build result caching. * `stamp = -1`: Embedding of build information is controlled by the   [`--[no]stamp`](/versions/8.6.0/docs/user-manual#flag--stamp) flag.   Stamped binaries are *not* rebuilt unless their dependencies change. |
+| `win_def_file` | [Label](/versions/8.6.0/concepts/labels); default is `None` The Windows DEF file to be passed to linker. This attribute should only be used when Windows is the target platform. It can be used to [export symbols](https://msdn.microsoft.com/en-us/library/d91k01sh.aspx) during linking a shared library. |
 
 ## cc_toolchain
 
@@ -768,7 +768,7 @@ This rule is responsible for:
 
 Use `toolchain_config` attribute to configure the C++ toolchain.
 See also this
-[page](https://bazel.build/docs/cc-toolchain-config-reference) for elaborate C++ toolchain configuration and toolchain selection documentation.
+[page](https://bazel.build/versions/8.6.0/docs/cc-toolchain-config-reference) for elaborate C++ toolchain configuration and toolchain selection documentation.
 
 Use `tags = ["manual"]` in order to prevent toolchains from being built and configured
 unnecessarily when invoking `bazel build //...`
@@ -777,26 +777,26 @@ unnecessarily when invoking `bazel build //...`
 
 | Attributes | |
 | --- | --- |
-| `name` | [Name](/concepts/labels#target-names); required  A unique name for this target. |
-| `all_files` | [Label](/concepts/labels); required Collection of all cc_toolchain artifacts. These artifacts will be added as inputs to all rules_cc related actions (with the exception of actions that are using more precise sets of artifacts from attributes below). Bazel assumes that `all_files` is a superset of all other artifact-providing attributes (e.g. linkstamp compilation needs both compile and link files, so it takes `all_files`). This is what `cc_toolchain.files` contains, and this is used by all Starlark rules using C++ toolchain. |
-| `ar_files` | [Label](/concepts/labels); default is `None` Collection of all cc_toolchain artifacts required for archiving actions. |
-| `as_files` | [Label](/concepts/labels); default is `None` Collection of all cc_toolchain artifacts required for assembly actions. |
-| `compiler_files` | [Label](/concepts/labels); required Collection of all cc_toolchain artifacts required for compile actions. |
-| `compiler_files_without_includes` | [Label](/concepts/labels); default is `None` Collection of all cc_toolchain artifacts required for compile actions in case when input discovery is supported (currently Google-only). |
-| `coverage_files` | [Label](/concepts/labels); default is `None` Collection of all cc_toolchain artifacts required for coverage actions. If not specified, all_files are used. |
-| `dwp_files` | [Label](/concepts/labels); required Collection of all cc_toolchain artifacts required for dwp actions. |
-| `dynamic_runtime_lib` | [Label](/concepts/labels); default is `None` Dynamic library artifact for the C++ runtime library (e.g. libstdc++.so). This will be used when 'static_link_cpp_runtimes' feature is enabled, and we're linking dependencies dynamically. |
+| `name` | [Name](/versions/8.6.0/concepts/labels#target-names); required  A unique name for this target. |
+| `all_files` | [Label](/versions/8.6.0/concepts/labels); required Collection of all cc_toolchain artifacts. These artifacts will be added as inputs to all rules_cc related actions (with the exception of actions that are using more precise sets of artifacts from attributes below). Bazel assumes that `all_files` is a superset of all other artifact-providing attributes (e.g. linkstamp compilation needs both compile and link files, so it takes `all_files`). This is what `cc_toolchain.files` contains, and this is used by all Starlark rules using C++ toolchain. |
+| `ar_files` | [Label](/versions/8.6.0/concepts/labels); default is `None` Collection of all cc_toolchain artifacts required for archiving actions. |
+| `as_files` | [Label](/versions/8.6.0/concepts/labels); default is `None` Collection of all cc_toolchain artifacts required for assembly actions. |
+| `compiler_files` | [Label](/versions/8.6.0/concepts/labels); required Collection of all cc_toolchain artifacts required for compile actions. |
+| `compiler_files_without_includes` | [Label](/versions/8.6.0/concepts/labels); default is `None` Collection of all cc_toolchain artifacts required for compile actions in case when input discovery is supported (currently Google-only). |
+| `coverage_files` | [Label](/versions/8.6.0/concepts/labels); default is `None` Collection of all cc_toolchain artifacts required for coverage actions. If not specified, all_files are used. |
+| `dwp_files` | [Label](/versions/8.6.0/concepts/labels); required Collection of all cc_toolchain artifacts required for dwp actions. |
+| `dynamic_runtime_lib` | [Label](/versions/8.6.0/concepts/labels); default is `None` Dynamic library artifact for the C++ runtime library (e.g. libstdc++.so). This will be used when 'static_link_cpp_runtimes' feature is enabled, and we're linking dependencies dynamically. |
 | `exec_transition_for_inputs` | Boolean; default is `False` Deprecated. No-op. |
-| `libc_top` | [Label](/concepts/labels); default is `None` A collection of artifacts for libc passed as inputs to compile/linking actions. |
-| `linker_files` | [Label](/concepts/labels); required Collection of all cc_toolchain artifacts required for linking actions. |
-| `module_map` | [Label](/concepts/labels); default is `None` Module map artifact to be used for modular builds. |
-| `objcopy_files` | [Label](/concepts/labels); required Collection of all cc_toolchain artifacts required for objcopy actions. |
+| `libc_top` | [Label](/versions/8.6.0/concepts/labels); default is `None` A collection of artifacts for libc passed as inputs to compile/linking actions. |
+| `linker_files` | [Label](/versions/8.6.0/concepts/labels); required Collection of all cc_toolchain artifacts required for linking actions. |
+| `module_map` | [Label](/versions/8.6.0/concepts/labels); default is `None` Module map artifact to be used for modular builds. |
+| `objcopy_files` | [Label](/versions/8.6.0/concepts/labels); required Collection of all cc_toolchain artifacts required for objcopy actions. |
 | `output_licenses` | List of strings; default is `[]` |
-| `static_runtime_lib` | [Label](/concepts/labels); default is `None` Static library artifact for the C++ runtime library (e.g. libstdc++.a). This will be used when 'static_link_cpp_runtimes' feature is enabled, and we're linking dependencies statically. |
-| `strip_files` | [Label](/concepts/labels); required Collection of all cc_toolchain artifacts required for strip actions. |
+| `static_runtime_lib` | [Label](/versions/8.6.0/concepts/labels); default is `None` Static library artifact for the C++ runtime library (e.g. libstdc++.a). This will be used when 'static_link_cpp_runtimes' feature is enabled, and we're linking dependencies statically. |
+| `strip_files` | [Label](/versions/8.6.0/concepts/labels); required Collection of all cc_toolchain artifacts required for strip actions. |
 | `supports_header_parsing` | Boolean; default is `False` Set to True when cc_toolchain supports header parsing actions. |
 | `supports_param_files` | Boolean; default is `True` Set to True when cc_toolchain supports using param files for linking actions. |
-| `toolchain_config` | [Label](/concepts/labels); required The label of the rule providing `cc_toolchain_config_info`. |
+| `toolchain_config` | [Label](/versions/8.6.0/concepts/labels); required The label of the rule providing `cc_toolchain_config_info`. |
 | `toolchain_identifier` | String; default is `""` The identifier used to match this cc_toolchain with the corresponding crosstool_config.toolchain. Until issue [#5380](https://github.com/bazelbuild/bazel/issues/5380) is fixed this is the recommended way of associating `cc_toolchain` with `CROSSTOOL.toolchain`. It will be replaced by the `toolchain_config` attribute ([#5380](https://github.com/bazelbuild/bazel/issues/5380)). |
 
 ## cc_toolchain_suite
@@ -813,7 +813,7 @@ Deprecated: the rule is a no-op and will be removed.
 
 | Attributes | |
 | --- | --- |
-| `name` | [Name](/concepts/labels#target-names); required  A unique name for this target. |
+| `name` | [Name](/versions/8.6.0/concepts/labels#target-names); required  A unique name for this target. |
 
 ## fdo_prefetch_hints
 
@@ -837,8 +837,8 @@ fdo_prefetch_hints(
 
 | Attributes | |
 | --- | --- |
-| `name` | [Name](/concepts/labels#target-names); required  A unique name for this target. |
-| `profile` | [Label](/concepts/labels); required Label of the hints profile. The hints file has the .afdo extension The label can also point to an fdo_absolute_path_profile rule. |
+| `name` | [Name](/versions/8.6.0/concepts/labels#target-names); required  A unique name for this target. |
+| `profile` | [Label](/versions/8.6.0/concepts/labels); required Label of the hints profile. The hints file has the .afdo extension The label can also point to an fdo_absolute_path_profile rule. |
 
 ## fdo_profile
 
@@ -862,10 +862,10 @@ fdo_profile(
 
 | Attributes | |
 | --- | --- |
-| `name` | [Name](/concepts/labels#target-names); required  A unique name for this target. |
-| `memprof_profile` | [Label](/concepts/labels); default is `None` Label of the MemProf profile. The profile is expected to have either a .profdata extension (for an indexed/symbolized memprof profile), or a .zip extension for a zipfile containing a memprof.profdata file. |
-| `profile` | [Label](/concepts/labels); required Label of the FDO profile or a rule which generates it. The FDO file can have one of the following extensions: .profraw for unindexed LLVM profile, .profdata for indexed LLVM profile, .zip that holds an LLVM profraw profile, .afdo for AutoFDO profile, .xfdo for XBinary profile. The label can also point to an fdo_absolute_path_profile rule. |
-| `proto_profile` | [Label](/concepts/labels); default is `None` Label of the protobuf profile. |
+| `name` | [Name](/versions/8.6.0/concepts/labels#target-names); required  A unique name for this target. |
+| `memprof_profile` | [Label](/versions/8.6.0/concepts/labels); default is `None` Label of the MemProf profile. The profile is expected to have either a .profdata extension (for an indexed/symbolized memprof profile), or a .zip extension for a zipfile containing a memprof.profdata file. |
+| `profile` | [Label](/versions/8.6.0/concepts/labels); required Label of the FDO profile or a rule which generates it. The FDO file can have one of the following extensions: .profraw for unindexed LLVM profile, .profdata for indexed LLVM profile, .zip that holds an LLVM profraw profile, .afdo for AutoFDO profile, .xfdo for XBinary profile. The label can also point to an fdo_absolute_path_profile rule. |
+| `proto_profile` | [Label](/versions/8.6.0/concepts/labels); default is `None` Label of the protobuf profile. |
 
 ## memprof_profile
 
@@ -889,8 +889,8 @@ memprof_profile(
 
 | Attributes | |
 | --- | --- |
-| `name` | [Name](/concepts/labels#target-names); required  A unique name for this target. |
-| `profile` | [Label](/concepts/labels); required Label of the MEMPROF profile. The profile is expected to have either a .profdata extension (for an indexed/symbolized memprof profile), or a .zip extension for a zipfile containing a memprof.profdata file. The label can also point to an fdo_absolute_path_profile rule. |
+| `name` | [Name](/versions/8.6.0/concepts/labels#target-names); required  A unique name for this target. |
+| `profile` | [Label](/versions/8.6.0/concepts/labels); required Label of the MEMPROF profile. The profile is expected to have either a .profdata extension (for an indexed/symbolized memprof profile), or a .zip extension for a zipfile containing a memprof.profdata file. The label can also point to an fdo_absolute_path_profile rule. |
 
 ## propeller_optimize
 
@@ -915,6 +915,6 @@ propeller_optimize(
 
 | Attributes | |
 | --- | --- |
-| `name` | [Name](/concepts/labels#target-names); required  A unique name for this target. |
-| `cc_profile` | [Label](/concepts/labels); required Label of the profile passed to the various compile actions. This file has the .txt extension. |
-| `ld_profile` | [Label](/concepts/labels); required Label of the profile passed to the link action. This file has the .txt extension. |
\ No newline at end of file
+| `name` | [Name](/versions/8.6.0/concepts/labels#target-names); required  A unique name for this target. |
+| `cc_profile` | [Label](/versions/8.6.0/concepts/labels); required Label of the profile passed to the various compile actions. This file has the .txt extension. |
+| `ld_profile` | [Label](/versions/8.6.0/concepts/labels); required Label of the profile passed to the link action. This file has the .txt extension. |
\ No newline at end of file
diff --git a/versions/8.6.0/reference/be/common-definitions.mdx b/versions/8.6.0/reference/be/common-definitions.mdx
index 477750fb..84ae5ff6 100644
--- a/versions/8.6.0/reference/be/common-definitions.mdx
+++ b/versions/8.6.0/reference/be/common-definitions.mdx
@@ -42,7 +42,7 @@ expansion: if those strings contain a valid label as a
 substring, such as `//mypkg:target`, and that label is a
 declared prerequisite of the current rule, it is expanded into the
 pathname of the file represented by the
-[target](https://bazel.build/reference/glossary#target)
+[target](https://bazel.build/versions/8.6.0/reference/glossary#target)
 `//mypkg:target`.
 
 Example attributes include `genrule.cmd` and
@@ -59,10 +59,10 @@ but not all.
 
 | Attribute | Description |
 | --- | --- |
-| `data` | List of [labels](/concepts/labels); default is `[]`  Files needed by this rule at runtime. May list file or rule targets. Generally allows any target.  The default outputs and runfiles of targets in the `data` attribute should appear in the `*.runfiles` area of any executable which is output by or has a runtime dependency on this target. This may include data files or binaries used when this target's [`srcs`](#typical.srcs) are executed. See the [data dependencies](/concepts/dependencies#data-dependencies) section for more information about how to depend on and use data files.  New rules should define a `data` attribute if they process inputs which might use other inputs at runtime. Rules' implementation functions must also [populate the target's runfiles](https://bazel.build/rules/rules#runfiles) from the outputs and runfiles of any `data` attribute, as well as runfiles from any dependency attribute which provides either source code or runtime dependencies. |
-| `deps` | List of [labels](/concepts/labels); default is `[]`  Dependencies for this target. Generally should only list rule targets. (Though some rules permit files to be listed directly in `deps`, this should be avoided when possible.)  Language-specific rules generally limit the listed targets to those with specific [providers](https://bazel.build/extending/rules#providers).  The precise semantics of what it means for a target to depend on another using `deps` are specific to the kind of rule, and the rule-specific documentation goes into more detail. For rules which process source code, `deps` generally specifies code dependencies used by the code in [`srcs`](#typical.srcs).  Most often, a `deps` dependency is used to allow one module to use symbols defined in another module written in the same programming language and separately compiled. Cross-language dependencies are also permitted in many cases: For example, a `java_library` target may depend on C++ code in a `cc_library` target, by listing the latter in the `deps` attribute. See the definition of [dependencies](/concepts/build-ref#deps) for more information. |
+| `data` | List of [labels](/versions/8.6.0/concepts/labels); default is `[]`  Files needed by this rule at runtime. May list file or rule targets. Generally allows any target.  The default outputs and runfiles of targets in the `data` attribute should appear in the `*.runfiles` area of any executable which is output by or has a runtime dependency on this target. This may include data files or binaries used when this target's [`srcs`](#typical.srcs) are executed. See the [data dependencies](/versions/8.6.0/concepts/dependencies#data-dependencies) section for more information about how to depend on and use data files.  New rules should define a `data` attribute if they process inputs which might use other inputs at runtime. Rules' implementation functions must also [populate the target's runfiles](https://bazel.build/versions/8.6.0/rules/rules#runfiles) from the outputs and runfiles of any `data` attribute, as well as runfiles from any dependency attribute which provides either source code or runtime dependencies. |
+| `deps` | List of [labels](/versions/8.6.0/concepts/labels); default is `[]`  Dependencies for this target. Generally should only list rule targets. (Though some rules permit files to be listed directly in `deps`, this should be avoided when possible.)  Language-specific rules generally limit the listed targets to those with specific [providers](https://bazel.build/versions/8.6.0/extending/rules#providers).  The precise semantics of what it means for a target to depend on another using `deps` are specific to the kind of rule, and the rule-specific documentation goes into more detail. For rules which process source code, `deps` generally specifies code dependencies used by the code in [`srcs`](#typical.srcs).  Most often, a `deps` dependency is used to allow one module to use symbols defined in another module written in the same programming language and separately compiled. Cross-language dependencies are also permitted in many cases: For example, a `java_library` target may depend on C++ code in a `cc_library` target, by listing the latter in the `deps` attribute. See the definition of [dependencies](/versions/8.6.0/concepts/build-ref#deps) for more information. |
 | `licenses` | List of strings; [nonconfigurable](#configurable-attributes); default is `["none"]`  A list of license-type strings to be used for this particular target. This is part of a deprecated licensing API that Bazel no longer uses. Don't use this. |
-| `srcs` | List of [labels](/concepts/labels); default is `[]`  Files processed or included by this rule. Generally lists files directly, but may list rule targets (like `filegroup` or `genrule`) to include their default outputs.  Language-specific rules often require that the listed files have particular file extensions. |
+| `srcs` | List of [labels](/versions/8.6.0/concepts/labels); default is `[]`  Files processed or included by this rule. Generally lists files directly, but may list rule targets (like `filegroup` or `genrule`) to include their default outputs.  Language-specific rules often require that the listed files have particular file extensions. |
 
 ## Attributes common to all build rules
 
@@ -71,18 +71,18 @@ rules.
 
 | Attribute | Description |
 | --- | --- |
-| `compatible_with` | List of [labels](/concepts/labels); [nonconfigurable](#configurable-attributes); default is `[]`  The list of environments this target can be built for, in addition to default-supported environments.  This is part of Bazel's constraint system, which lets users declare which targets can and cannot depend on each other. For example, externally deployable binaries shouldn't depend on libraries with company-secret code. See [ConstraintSemantics](https://github.com/bazelbuild/bazel/blob/master/src/main/java/com/google/devtools/build/lib/analysis/constraints/ConstraintSemantics.java#L46) for details. |
+| `compatible_with` | List of [labels](/versions/8.6.0/concepts/labels); [nonconfigurable](#configurable-attributes); default is `[]`  The list of environments this target can be built for, in addition to default-supported environments.  This is part of Bazel's constraint system, which lets users declare which targets can and cannot depend on each other. For example, externally deployable binaries shouldn't depend on libraries with company-secret code. See [ConstraintSemantics](https://github.com/bazelbuild/bazel/blob/master/src/main/java/com/google/devtools/build/lib/analysis/constraints/ConstraintSemantics.java#L46) for details. |
 | `deprecation` | String; [nonconfigurable](#configurable-attributes); default is `None`  An explanatory warning message associated with this target. Typically this is used to notify users that a target has become obsolete, or has become superseded by another rule, is private to a package, or is perhaps considered harmful for some reason. It is a good idea to include some reference (like a webpage, a bug number or example migration CLs) so that one can easily find out what changes are required to avoid the message. If there is a new target that can be used as a drop in replacement, it is a good idea to just migrate all users of the old target.  This attribute has no effect on the way things are built, but it may affect a build tool's diagnostic output. The build tool issues a warning when a rule with a `deprecation` attribute is depended upon by a target in another package.  Intra-package dependencies are exempt from this warning, so that, for example, building the tests of a deprecated rule does not encounter a warning.  If a deprecated target depends on another deprecated target, no warning message is issued.  Once people have stopped using it, the target can be removed. |
 | `distribs` | List of strings; [nonconfigurable](#configurable-attributes); default is `[]`  A list of distribution-method strings to be used for this particular target. This is part of a deprecated licensing API that Bazel no longer uses. Don't use this. |
-| `exec_compatible_with` | List of [labels](/concepts/labels); [nonconfigurable](#configurable-attributes); default is `[]`  A list of `constraint_values` that must be present in the execution platform for this target. This is in addition to any constraints already set by the rule type. Constraints are used to restrict the list of available execution platforms. For more details, see the description of [toolchain resolution](/docs/toolchains#toolchain-resolution). |
-| `exec_properties` | Dictionary of strings; default is `{}`  A dictionary of strings that will be added to the `exec_properties` of a platform selected for this target. See `exec_properties` of the [platform](platforms-and-toolchains#platform) rule.  If a key is present in both the platform and target-level properties, the value will be taken from the target. |
-| `features` | List of *feature* strings; default is `[]`  A feature is string tag that can be enabled or disabled on a target. The meaning of a feature depends on the rule itself.  This `features` attribute is combined with the [package](/reference/be/functions#package) level `features` attribute. For example, if the features ["a", "b"] are enabled on the package level, and a target's `features` attribute contains ["-a", "c"], the features enabled for the rule will be "b" and "c". [See example](https://github.com/bazelbuild/examples/blob/main/rules/features/BUILD). |
-| `restricted_to` | List of [labels](/concepts/labels); [nonconfigurable](#configurable-attributes); default is `[]`  The list of environments this target can be built for, *instead* of default-supported environments.  This is part of Bazel's constraint system. See `compatible_with` for details. |
-| `tags` | List of strings; [nonconfigurable](#configurable-attributes); default is `[]`  *Tags* can be used on any rule. *Tags* on test and `test_suite` rules are useful for categorizing the tests. *Tags* on non-test targets are used to control sandboxed execution of `genrule`s and [Starlark](/rules/concepts) actions, and for parsing by humans and/or external tools.  Bazel modifies the behavior of its sandboxing code if it finds the following keywords in the `tags` attribute of any test or `genrule` target, or the keys of `execution_requirements` for any Starlark action.   * `no-sandbox` keyword results in the action or test never being   sandboxed; it can still be cached or run remotely - use `no-cache`   or `no-remote` to prevent either or both of those. * `no-cache` keyword results in the action or test never being   cached (locally or remotely). Note: for the purposes of this tag, the disk cache   is considered a local cache, whereas the HTTP and gRPC caches are considered   remote. Other caches, such as Skyframe or the persistent action cache, are not   affected. * `no-remote-cache` keyword results in the action or test never being   cached remotely (but it may be cached locally; it may also be executed remotely).   Note: for the purposes of this tag, the disk cache is considered a local cache,   whereas the HTTP and gRPC caches are considered remote. Other caches, such as   Skyframe or the persistent action cache, are not affected.   If a combination of local disk cache and remote cache are used (combined cache),   it's treated as a remote cache and disabled entirely unless `--incompatible_remote_results_ignore_disk`   is set in which case the local components will be used. * `no-remote-exec` keyword results in the action or test never being   executed remotely (but it may be cached remotely). * `no-remote` keyword prevents the action or test from being executed remotely or   cached remotely. This is equivalent to using both   `no-remote-cache` and `no-remote-exec`. * `no-remote-cache-upload` keyword disables upload part of remote caching of a spawn.   it does not disable remote execution. * `local` keyword precludes the action or test from being remotely cached,   remotely executed, or run inside the sandbox.   For genrules and tests, marking the rule with the `local = True`   attribute has the same effect. * `requires-network` keyword allows access to the external   network from inside the sandbox. This tag only has an effect if sandboxing   is enabled. * `block-network` keyword blocks access to the external   network from inside the sandbox. In this case, only communication   with localhost is allowed. This tag only has an effect if sandboxing is   enabled. * `requires-fakeroot` runs the test or action as uid and gid 0 (i.e., the root   user). This is only supported on Linux. This tag takes precedence over the   `--sandbox_fake_username` command-line option.   *Tags* on tests are generally used to annotate a test's role in your debug and release process. Typically, tags are most useful for C++ and Python tests, which lack any runtime annotation ability. The use of tags and size elements gives flexibility in assembling suites of tests based around codebase check-in policy.  Bazel modifies test running behavior if it finds the following keywords in the `tags` attribute of the test rule:   * `exclusive` will force the test to be run in the   "exclusive" mode, ensuring that no other tests are running at the   same time. Such tests will be executed in serial fashion after all build   activity and non-exclusive tests have been completed. Remote execution is   disabled for such tests because Bazel doesn't have control over what's   running on a remote machine. * `exclusive-if-local` will force the test to be run in the   "exclusive" mode if it is executed locally, but will run the test in parallel if it's   executed remotely. * `manual` keyword will exclude the target from expansion of target pattern wildcards   (`...`, `:*`, `:all`, etc.) and `test_suite` rules   which do not list the test explicitly when computing the set of top-level targets to build/run   for the `build`, `test`, and `coverage` commands. It does not   affect target wildcard or test suite expansion in other contexts, including the   `query` command. Note that `manual` does not imply that a target should   not be built/run automatically by continuous build/test systems. For example, it may be   desirable to exclude a target from `bazel test ...` because it requires specific   Bazel flags, but still have it included in properly-configured presubmit or continuous test   runs. * `external` keyword will force test to be unconditionally   executed (regardless of `--cache_test_results`   value).  See [Tag Conventions](/reference/test-encyclopedia#tag-conventions) in the Test Encyclopedia for more conventions on tags attached to test targets. |
-| `target_compatible_with` | List of [labels](/concepts/labels); default is `[]`  A list of `constraint_value`s that must be present in the target platform for this target to be considered *compatible*. This is in addition to any constraints already set by the rule type. If the target platform does not satisfy all listed constraints then the target is considered *incompatible*. Incompatible targets are skipped for building and testing when the target pattern is expanded (e.g. `//...`, `:all`). When explicitly specified on the command line, incompatible targets cause Bazel to print an error and cause a build or test failure.  Targets that transitively depend on incompatible targets are themselves considered incompatible. They are also skipped for building and testing.  An empty list (which is the default) signifies that the target is compatible with all platforms. All rules other than [Workspace Rules](workspace) support this attribute. For some rules this attribute has no effect. For example, specifying `target_compatible_with` for a `cc_toolchain` is not useful. See the [Platforms](/docs/platforms#skipping-incompatible-targets) page for more information about incompatible target skipping. |
-| `testonly` | Boolean; [nonconfigurable](#configurable-attributes); default is `False` except for test and test suite targets  If `True`, only testonly targets (such as tests) can depend on this target.  Equivalently, a rule that is not `testonly` is not allowed to depend on any rule that is `testonly`.  Tests (`*_test` rules) and test suites ([test_suite](/reference/be/general#test_suite) rules) are `testonly` by default.  This attribute is intended to mean that the target should not be contained in binaries that are released to production.  Because testonly is enforced at build time, not run time, and propagates virally through the dependency tree, it should be applied judiciously. For example, stubs and fakes that are useful for unit tests may also be useful for integration tests involving the same binaries that will be released to production, and therefore should probably not be marked testonly. Conversely, rules that are dangerous to even link in, perhaps because they unconditionally override normal behavior, should definitely be marked testonly. |
-| `toolchains` | List of [labels](/concepts/labels); [nonconfigurable](#configurable-attributes); default is `[]`  The set of targets whose [Make variables](/reference/be/make-variables) this target is allowed to access. These targets are either instances of rules that provide `TemplateVariableInfo` or special targets for toolchain types built into Bazel. These include:  * `@bazel_tools//tools/cpp:current_cc_toolchain`* `@rules_java//toolchains:current_java_runtime`   Note that this is distinct from the concept of [toolchain resolution](/docs/toolchains#toolchain-resolution) that is used by rule implementations for platform-dependent configuration. You cannot use this attribute to determine which specific `cc_toolchain` or `java_toolchain` a target will use. |
-| `visibility` | List of [labels](/concepts/labels); [nonconfigurable](#configurable-attributes); default varies  The `visibility` attribute controls whether the target can be depended on by targets in other locations. See the documentation for [visibility](/concepts/visibility).  For targets declared directly in a BUILD file or in legacy macros called from a BUILD file, the default value is the package's `default_visibility` if specified, or else `["//visibility:private"]`. For targets declared in one or more symbolic macros, the default value is always just `["//visibility:private"]` (which makes it useable only within the package containing the macro's code). |
+| `exec_compatible_with` | List of [labels](/versions/8.6.0/concepts/labels); [nonconfigurable](#configurable-attributes); default is `[]`  A list of `constraint_values` that must be present in the execution platform for this target. This is in addition to any constraints already set by the rule type. Constraints are used to restrict the list of available execution platforms. For more details, see the description of [toolchain resolution](/versions/8.6.0/docs/toolchains#toolchain-resolution). |
+| `exec_properties` | Dictionary of strings; default is `{}`  A dictionary of strings that will be added to the `exec_properties` of a platform selected for this target. See `exec_properties` of the [platform](/versions/8.6.0/reference/be/platforms-and-toolchains#platform) rule.  If a key is present in both the platform and target-level properties, the value will be taken from the target. |
+| `features` | List of *feature* strings; default is `[]`  A feature is string tag that can be enabled or disabled on a target. The meaning of a feature depends on the rule itself.  This `features` attribute is combined with the [package](/versions/8.6.0/reference/be/functions#package) level `features` attribute. For example, if the features ["a", "b"] are enabled on the package level, and a target's `features` attribute contains ["-a", "c"], the features enabled for the rule will be "b" and "c". [See example](https://github.com/bazelbuild/examples/blob/main/rules/features/BUILD). |
+| `restricted_to` | List of [labels](/versions/8.6.0/concepts/labels); [nonconfigurable](#configurable-attributes); default is `[]`  The list of environments this target can be built for, *instead* of default-supported environments.  This is part of Bazel's constraint system. See `compatible_with` for details. |
+| `tags` | List of strings; [nonconfigurable](#configurable-attributes); default is `[]`  *Tags* can be used on any rule. *Tags* on test and `test_suite` rules are useful for categorizing the tests. *Tags* on non-test targets are used to control sandboxed execution of `genrule`s and [Starlark](/versions/8.6.0/rules/concepts) actions, and for parsing by humans and/or external tools.  Bazel modifies the behavior of its sandboxing code if it finds the following keywords in the `tags` attribute of any test or `genrule` target, or the keys of `execution_requirements` for any Starlark action.   * `no-sandbox` keyword results in the action or test never being   sandboxed; it can still be cached or run remotely - use `no-cache`   or `no-remote` to prevent either or both of those. * `no-cache` keyword results in the action or test never being   cached (locally or remotely). Note: for the purposes of this tag, the disk cache   is considered a local cache, whereas the HTTP and gRPC caches are considered   remote. Other caches, such as Skyframe or the persistent action cache, are not   affected. * `no-remote-cache` keyword results in the action or test never being   cached remotely (but it may be cached locally; it may also be executed remotely).   Note: for the purposes of this tag, the disk cache is considered a local cache,   whereas the HTTP and gRPC caches are considered remote. Other caches, such as   Skyframe or the persistent action cache, are not affected.   If a combination of local disk cache and remote cache are used (combined cache),   it's treated as a remote cache and disabled entirely unless `--incompatible_remote_results_ignore_disk`   is set in which case the local components will be used. * `no-remote-exec` keyword results in the action or test never being   executed remotely (but it may be cached remotely). * `no-remote` keyword prevents the action or test from being executed remotely or   cached remotely. This is equivalent to using both   `no-remote-cache` and `no-remote-exec`. * `no-remote-cache-upload` keyword disables upload part of remote caching of a spawn.   it does not disable remote execution. * `local` keyword precludes the action or test from being remotely cached,   remotely executed, or run inside the sandbox.   For genrules and tests, marking the rule with the `local = True`   attribute has the same effect. * `requires-network` keyword allows access to the external   network from inside the sandbox. This tag only has an effect if sandboxing   is enabled. * `block-network` keyword blocks access to the external   network from inside the sandbox. In this case, only communication   with localhost is allowed. This tag only has an effect if sandboxing is   enabled. * `requires-fakeroot` runs the test or action as uid and gid 0 (i.e., the root   user). This is only supported on Linux. This tag takes precedence over the   `--sandbox_fake_username` command-line option.   *Tags* on tests are generally used to annotate a test's role in your debug and release process. Typically, tags are most useful for C++ and Python tests, which lack any runtime annotation ability. The use of tags and size elements gives flexibility in assembling suites of tests based around codebase check-in policy.  Bazel modifies test running behavior if it finds the following keywords in the `tags` attribute of the test rule:   * `exclusive` will force the test to be run in the   "exclusive" mode, ensuring that no other tests are running at the   same time. Such tests will be executed in serial fashion after all build   activity and non-exclusive tests have been completed. Remote execution is   disabled for such tests because Bazel doesn't have control over what's   running on a remote machine. * `exclusive-if-local` will force the test to be run in the   "exclusive" mode if it is executed locally, but will run the test in parallel if it's   executed remotely. * `manual` keyword will exclude the target from expansion of target pattern wildcards   (`...`, `:*`, `:all`, etc.) and `test_suite` rules   which do not list the test explicitly when computing the set of top-level targets to build/run   for the `build`, `test`, and `coverage` commands. It does not   affect target wildcard or test suite expansion in other contexts, including the   `query` command. Note that `manual` does not imply that a target should   not be built/run automatically by continuous build/test systems. For example, it may be   desirable to exclude a target from `bazel test ...` because it requires specific   Bazel flags, but still have it included in properly-configured presubmit or continuous test   runs. * `external` keyword will force test to be unconditionally   executed (regardless of `--cache_test_results`   value).  See [Tag Conventions](/versions/8.6.0/reference/test-encyclopedia#tag-conventions) in the Test Encyclopedia for more conventions on tags attached to test targets. |
+| `target_compatible_with` | List of [labels](/versions/8.6.0/concepts/labels); default is `[]`  A list of `constraint_value`s that must be present in the target platform for this target to be considered *compatible*. This is in addition to any constraints already set by the rule type. If the target platform does not satisfy all listed constraints then the target is considered *incompatible*. Incompatible targets are skipped for building and testing when the target pattern is expanded (e.g. `//...`, `:all`). When explicitly specified on the command line, incompatible targets cause Bazel to print an error and cause a build or test failure.  Targets that transitively depend on incompatible targets are themselves considered incompatible. They are also skipped for building and testing.  An empty list (which is the default) signifies that the target is compatible with all platforms. All rules other than [Workspace Rules](/versions/8.6.0/reference/be/workspace) support this attribute. For some rules this attribute has no effect. For example, specifying `target_compatible_with` for a `cc_toolchain` is not useful. See the [Platforms](/versions/8.6.0/docs/platforms#skipping-incompatible-targets) page for more information about incompatible target skipping. |
+| `testonly` | Boolean; [nonconfigurable](#configurable-attributes); default is `False` except for test and test suite targets  If `True`, only testonly targets (such as tests) can depend on this target.  Equivalently, a rule that is not `testonly` is not allowed to depend on any rule that is `testonly`.  Tests (`*_test` rules) and test suites ([test_suite](/versions/8.6.0/reference/be/general#test_suite) rules) are `testonly` by default.  This attribute is intended to mean that the target should not be contained in binaries that are released to production.  Because testonly is enforced at build time, not run time, and propagates virally through the dependency tree, it should be applied judiciously. For example, stubs and fakes that are useful for unit tests may also be useful for integration tests involving the same binaries that will be released to production, and therefore should probably not be marked testonly. Conversely, rules that are dangerous to even link in, perhaps because they unconditionally override normal behavior, should definitely be marked testonly. |
+| `toolchains` | List of [labels](/versions/8.6.0/concepts/labels); [nonconfigurable](#configurable-attributes); default is `[]`  The set of targets whose [Make variables](/versions/8.6.0/reference/be/make-variables) this target is allowed to access. These targets are either instances of rules that provide `TemplateVariableInfo` or special targets for toolchain types built into Bazel. These include:  * `@bazel_tools//tools/cpp:current_cc_toolchain`* `@rules_java//toolchains:current_java_runtime`   Note that this is distinct from the concept of [toolchain resolution](/versions/8.6.0/docs/toolchains#toolchain-resolution) that is used by rule implementations for platform-dependent configuration. You cannot use this attribute to determine which specific `cc_toolchain` or `java_toolchain` a target will use. |
+| `visibility` | List of [labels](/versions/8.6.0/concepts/labels); [nonconfigurable](#configurable-attributes); default varies  The `visibility` attribute controls whether the target can be depended on by targets in other locations. See the documentation for [visibility](/versions/8.6.0/concepts/visibility).  For targets declared directly in a BUILD file or in legacy macros called from a BUILD file, the default value is the package's `default_visibility` if specified, or else `["//visibility:private"]`. For targets declared in one or more symbolic macros, the default value is always just `["//visibility:private"]` (which makes it useable only within the package containing the macro's code). |
 
 ## Attributes common to all test rules (\*\_test)
 
@@ -90,13 +90,13 @@ This section describes attributes that are common to all test rules.
 
 | Attribute | Description |
 | --- | --- |
-| `args` | List of strings; subject to [$(location)](/reference/be/make-variables#predefined_label_variables) and ["Make variable"](/reference/be/make-variables) substitution, and [Bourne shell tokenization](#sh-tokenization); default is `[]`  Command line arguments that Bazel passes to the target when it is executed with `bazel test`. These arguments are passed before any `--test_arg` values specified on the `bazel test` command line. |
-| `env` | Dictionary of strings; values are subject to [$(location)](/reference/be/make-variables#predefined_label_variables) and ["Make variable"](/reference/be/make-variables) substitution; default is `{}`  Specifies additional environment variables to set when the test is executed by `bazel test`.  This attribute only applies to native rules, like `cc_test`, `py_test`, and `sh_test`. It does not apply to Starlark-defined test rules. For your own Starlark rules, you can add an "env" attribute and use it to populate a [TestEnvironment](/rules/lib/toplevel/testing#TestEnvironment) Provider. |
+| `args` | List of strings; subject to [$(location)](/versions/8.6.0/reference/be/make-variables#predefined_label_variables) and ["Make variable"](/versions/8.6.0/reference/be/make-variables) substitution, and [Bourne shell tokenization](#sh-tokenization); default is `[]`  Command line arguments that Bazel passes to the target when it is executed with `bazel test`. These arguments are passed before any `--test_arg` values specified on the `bazel test` command line. |
+| `env` | Dictionary of strings; values are subject to [$(location)](/versions/8.6.0/reference/be/make-variables#predefined_label_variables) and ["Make variable"](/versions/8.6.0/reference/be/make-variables) substitution; default is `{}`  Specifies additional environment variables to set when the test is executed by `bazel test`.  This attribute only applies to native rules, like `cc_test`, `py_test`, and `sh_test`. It does not apply to Starlark-defined test rules. For your own Starlark rules, you can add an "env" attribute and use it to populate a [TestEnvironment](/versions/8.6.0/rules/lib/toplevel/testing#TestEnvironment) Provider. |
 | `env_inherit` | List of strings; default is `[]`  Specifies additional environment variables to inherit from the external environment when the test is executed by `bazel test`.  This attribute only applies to native rules, like `cc_test`, `py_test`, and `sh_test`. It does not apply to Starlark-defined test rules. |
 | `size` | String `"enormous"`, `"large"`, `"medium"`, or `"small"`; [nonconfigurable](#configurable-attributes); default is `"medium"`  Specifies a test target's "heaviness": how much time/resources it needs to run.  Unit tests are considered "small", integration tests "medium", and end-to-end tests "large" or "enormous". Bazel uses the size to determine a default timeout, which can be overridden using the `timeout` attribute. The timeout is for all tests in the BUILD target, not for each individual test. When the test is run locally, the `size` is additionally used for scheduling purposes: Bazel tries to respect `--local_{ram,cpu}_resources` and not overwhelm the local machine by running lots of heavy tests at the same time.  Test sizes correspond to the following default timeouts and assumed peak local resource usages:   | Size | RAM (in MB) | CPU (in CPU cores) | Default timeout | | --- | --- | --- | --- | | small | 20 | 1 | short (1 minute) | | medium | 100 | 1 | moderate (5 minutes) | | large | 300 | 1 | long (15 minutes) | | enormous | 800 | 1 | eternal (60 minutes) |   The environment variable `TEST_SIZE` will be set to the value of this attribute when spawning the test. |
 | `timeout` | String `"short"`, `"moderate"`, `"long"`, or `"eternal"`; [nonconfigurable](#configurable-attributes); default is derived from the test's `size` attribute  How long the test is expected to run before returning.  While a test's size attribute controls resource estimation, a test's timeout may be set independently. If not explicitly specified, the timeout is based on the [test's size](#test.size). The test timeout can be overridden with the `--test_timeout` flag, e.g. for running under certain conditions which are known to be slow. Test timeout values correspond to the following time periods:   | Timeout Value | Time Period | | --- | --- | | short | 1 minute | | moderate | 5 minutes | | long | 15 minutes | | eternal | 60 minutes |   For times other than the above, the test timeout can be overridden with the `--test_timeout` bazel flag, e.g. for manually running under conditions which are known to be slow. The `--test_timeout` values are in seconds. For example `--test_timeout=120` will set the test timeout to two minutes.  The environment variable `TEST_TIMEOUT` will be set to the test timeout (in seconds) when spawning the test. |
 | `flaky` | Boolean; [nonconfigurable](#configurable-attributes); default is `False`  Marks test as flaky.  If set, executes the test up to three times, marking it as failed only if it fails each time. By default, this attribute is set to False and the test is executed only once. Note, that use of this attribute is generally discouraged - tests should pass reliably when their assertions are upheld. |
-| `shard_count` | Non-negative integer less than or equal to 50; default is `-1`  Specifies the number of parallel shards to use to run the test.  If set, this value will override any heuristics used to determine the number of parallel shards with which to run the test. Note that for some test rules, this parameter may be required to enable sharding in the first place. Also see `--test_sharding_strategy`.  If test sharding is enabled, the environment variable `TEST_TOTAL_SHARDS` will be set to this value when spawning the test.  Sharding requires the test runner to support the test sharding protocol. If it does not, then it will most likely run every test in every shard, which is not what you want.  See [Test Sharding](/reference/test-encyclopedia#test-sharding) in the Test Encyclopedia for details on sharding. |
+| `shard_count` | Non-negative integer less than or equal to 50; default is `-1`  Specifies the number of parallel shards to use to run the test.  If set, this value will override any heuristics used to determine the number of parallel shards with which to run the test. Note that for some test rules, this parameter may be required to enable sharding in the first place. Also see `--test_sharding_strategy`.  If test sharding is enabled, the environment variable `TEST_TOTAL_SHARDS` will be set to this value when spawning the test.  Sharding requires the test runner to support the test sharding protocol. If it does not, then it will most likely run every test in every shard, which is not what you want.  See [Test Sharding](/versions/8.6.0/reference/test-encyclopedia#test-sharding) in the Test Encyclopedia for details on sharding. |
 | `local` | Boolean; [nonconfigurable](#configurable-attributes); default is `False`  Forces the test to be run locally, without sandboxing.  Setting this to True is equivalent to providing "local" as a tag (`tags=["local"]`). |
 
 ## Attributes common to all binary rules (\*\_binary)
@@ -105,8 +105,8 @@ This section describes attributes that are common to all binary rules.
 
 | Attribute | Description |
 | --- | --- |
-| `args` | List of strings; subject to [$(location)](/reference/be/make-variables#predefined_label_variables) and ["Make variable"](/reference/be/make-variables) substitution, and [Bourne shell tokenization](#sh-tokenization); [nonconfigurable](#configurable-attributes); default is `[]`  Command line arguments that Bazel will pass to the target when it is executed either by the `run` command or as a test. These arguments are passed before the ones that are specified on the `bazel run` or `bazel test` command line.  *NOTE: The arguments are not passed when you run the target outside of Bazel (for example, by manually executing the binary in `bazel-bin/`).* |
-| `env` | Dictionary of strings; values are subject to [$(location)](/reference/be/make-variables#predefined_label_variables) and ["Make variable"](/reference/be/make-variables) substitution; default is `{}`  Specifies additional environment variables to set when the target is executed by `bazel run`.  This attribute only applies to native rules, like `cc_binary`, `py_binary`, and `sh_binary`. It does not apply to Starlark-defined executable rules.  *NOTE: The environment variables are not set when you run the target outside of Bazel (for example, by manually executing the binary in `bazel-bin/`).* |
+| `args` | List of strings; subject to [$(location)](/versions/8.6.0/reference/be/make-variables#predefined_label_variables) and ["Make variable"](/versions/8.6.0/reference/be/make-variables) substitution, and [Bourne shell tokenization](#sh-tokenization); [nonconfigurable](#configurable-attributes); default is `[]`  Command line arguments that Bazel will pass to the target when it is executed either by the `run` command or as a test. These arguments are passed before the ones that are specified on the `bazel run` or `bazel test` command line.  *NOTE: The arguments are not passed when you run the target outside of Bazel (for example, by manually executing the binary in `bazel-bin/`).* |
+| `env` | Dictionary of strings; values are subject to [$(location)](/versions/8.6.0/reference/be/make-variables#predefined_label_variables) and ["Make variable"](/versions/8.6.0/reference/be/make-variables) substitution; default is `{}`  Specifies additional environment variables to set when the target is executed by `bazel run`.  This attribute only applies to native rules, like `cc_binary`, `py_binary`, and `sh_binary`. It does not apply to Starlark-defined executable rules.  *NOTE: The environment variables are not set when you run the target outside of Bazel (for example, by manually executing the binary in `bazel-bin/`).* |
 | `output_licenses` | List of strings; default is `[]`  The licenses of the output files that this binary generates. This is part of a deprecated licensing API that Bazel no longer uses. Don't use this. |
 
 ## Configurable attributes
@@ -140,20 +140,20 @@ config_setting(
 )
 ```
 
-The [`select()`](/reference/be/functions#select) function
+The [`select()`](/versions/8.6.0/reference/be/functions#select) function
 chooses among different alternative values for a configurable attribute based
-on which [`config_setting`](/reference/be/general#config_setting)
-or [`constraint_value`](/reference/be/platforms-and-toolchains#constraint_value)
+on which [`config_setting`](/versions/8.6.0/reference/be/general#config_setting)
+or [`constraint_value`](/versions/8.6.0/reference/be/platforms-and-toolchains#constraint_value)
 criteria the target's configuration satisfies.
 
 Bazel evaluates configurable attributes after processing macros and before
 processing rules (technically, between the
-[loading and analysis phases](https://bazel.build/rules/concepts#evaluation-model)).
+[loading and analysis phases](https://bazel.build/versions/8.6.0/rules/concepts#evaluation-model)).
 Any processing before `select()` evaluation doesn't know which
 branch the `select()` chooses. Macros, for example, can't change
 their behavior based on the chosen branch, and `bazel query` can
 only make conservative guesses about a target's configurable dependencies. See
-[this FAQ](https://bazel.build/docs/configurable-attributes#faq)
+[this FAQ](https://bazel.build/versions/8.6.0/docs/configurable-attributes#faq)
 for more on using `select()` with rules and macros.
 
 Attributes marked `nonconfigurable` in their documentation cannot
@@ -161,7 +161,7 @@ use this feature. Usually an attribute is nonconfigurable because Bazel
 internally needs to know its value before it can determine how to resolve a
 `select()`.
 
-See [Configurable Build Attributes](https://bazel.build/docs/configurable-attributes) for a detailed overview.
+See [Configurable Build Attributes](https://bazel.build/versions/8.6.0/docs/configurable-attributes) for a detailed overview.
 
 ## Implicit output targets
 
@@ -193,7 +193,7 @@ outputs entailed by a declaration of that kind of rule.
 
 An important but somewhat subtle distinction between the
 two namespaces used by the build system:
-[labels](/concepts/labels) identify *targets*,
+[labels](/versions/8.6.0/concepts/labels) identify *targets*,
 which may be rules or files, and file targets may be divided into
 either source (or input) file targets and derived (or output) file
 targets. These are the things you can mention in BUILD files,
@@ -206,4 +206,4 @@ example, `.o` object files produced during C++ compilation
 cannot be referenced from within BUILD files or from the command line.
 In this way, the build tool may hide certain implementation details of
 how it does its job. This is explained more fully in
-the [BUILD Concept Reference](/concepts/build-ref).
\ No newline at end of file
+the [BUILD Concept Reference](/versions/8.6.0/concepts/build-ref).
\ No newline at end of file
diff --git a/versions/8.6.0/reference/be/extra-actions.mdx b/versions/8.6.0/reference/be/extra-actions.mdx
index 8a293581..cb1f909f 100644
--- a/versions/8.6.0/reference/be/extra-actions.mdx
+++ b/versions/8.6.0/reference/be/extra-actions.mdx
@@ -16,20 +16,20 @@ action_listener(name, compatible_with, deprecation, distribs, exec_compatible_wi
 ```
 
 **WARNING:** Extra actions are deprecated. Use
-[aspects](https://bazel.build/rules/aspects)
+[aspects](https://bazel.build/versions/8.6.0/rules/aspects)
 instead.
 
 An `action_listener` rule doesn't produce any output itself.
 Instead, it allows tool developers to insert
-[`extra_action`](/reference/be/extra-actions#extra_action)s into the build system,
-by providing a mapping from action to [`extra_action`](/reference/be/extra-actions#extra_action).
+[`extra_action`](/versions/8.6.0/reference/be/extra-actions#extra_action)s into the build system,
+by providing a mapping from action to [`extra_action`](/versions/8.6.0/reference/be/extra-actions#extra_action).
 
 This rule's arguments map action mnemonics to
-[`extra_action`](/reference/be/extra-actions#extra_action) rules.
+[`extra_action`](/versions/8.6.0/reference/be/extra-actions#extra_action) rules.
 
-By specifying the option [`--experimental_action_listener=<label>`](/docs/user-manual#flag--experimental_action_listener),
+By specifying the option [`--experimental_action_listener=<label>`](/versions/8.6.0/docs/user-manual#flag--experimental_action_listener),
 the build will use the specified `action_listener` to insert
-[`extra_action`](/reference/be/extra-actions#extra_action)s into the build graph.
+[`extra_action`](/versions/8.6.0/reference/be/extra-actions#extra_action)s into the build graph.
 
 #### Example
 
@@ -62,8 +62,8 @@ extra_action(
 
 | Attributes | |
 | --- | --- |
-| `name` | [Name](/concepts/labels#target-names); required  A unique name for this target. |
-| `extra_actions` | List of [labels](/concepts/labels); required A list of `extra_action` targets this `action_listener` should add to the build graph. E.g. `[ "//my/tools:analyzer" ]`. |
+| `name` | [Name](/versions/8.6.0/concepts/labels#target-names); required  A unique name for this target. |
+| `extra_actions` | List of [labels](/versions/8.6.0/concepts/labels); required A list of `extra_action` targets this `action_listener` should add to the build graph. E.g. `[ "//my/tools:analyzer" ]`. |
 | `mnemonics` | List of strings; required A list of action mnemonics this `action_listener` should listen for, e.g. `[ "Javac" ]`. Mnemonics are not a public interface. There's no guarantee that the mnemonics and their actions don't change. |
 
 ## extra_action
@@ -75,14 +75,14 @@ extra_action(name, data, cmd, compatible_with, deprecation, distribs, exec_compa
 ```
 
 **WARNING:** Extra actions are deprecated. Use
-[aspects](https://bazel.build/rules/aspects)
+[aspects](https://bazel.build/versions/8.6.0/rules/aspects)
 instead.
 
 An `extra_action` rule doesn't produce any meaningful output
 when specified as a regular build target. Instead, it allows tool developers
 to insert additional actions into the build graph that shadow existing actions.
 
-See [`action_listener`](/reference/be/extra-actions#action_listener) for details
+See [`action_listener`](/versions/8.6.0/reference/be/extra-actions#action_listener) for details
 on how to enable `extra_action`s.
 
 The `extra_action`s run as a command-line. The command-line tool gets
@@ -99,8 +99,8 @@ Just like all other actions, extra actions are sandboxed, and should be designed
 
 | Attributes | |
 | --- | --- |
-| `name` | [Name](/concepts/labels#target-names); required  A unique name for this target. You may refer to this rule by `label` in the `extra_actions` argument of  [`action_listener`](/reference/be/extra-actions#action_listener) rules. |
-| `cmd` | String; required The command to run. Like [genrule cmd attribute](/reference/be/general#genrule.cmd) with the following differences:   1. No heuristic label expansion. Only labels using $(location ...) are expanded. 2. An additional pass is applied to the string to replace all    occurrences of the outputs created from the `out_templates`    attribute. All occurrences of `$(output out_template)`    are replaced with the path to the file denoted by `label`.  E.g. out_template `$(ACTION_ID).analysis`    can be matched with `$(output $(ACTION_ID).analysis)`.  In effect, this is the same substitution as `$(location)`    but with a different scope. |
+| `name` | [Name](/versions/8.6.0/concepts/labels#target-names); required  A unique name for this target. You may refer to this rule by `label` in the `extra_actions` argument of  [`action_listener`](/versions/8.6.0/reference/be/extra-actions#action_listener) rules. |
+| `cmd` | String; required The command to run. Like [genrule cmd attribute](/versions/8.6.0/reference/be/general#genrule.cmd) with the following differences:   1. No heuristic label expansion. Only labels using $(location ...) are expanded. 2. An additional pass is applied to the string to replace all    occurrences of the outputs created from the `out_templates`    attribute. All occurrences of `$(output out_template)`    are replaced with the path to the file denoted by `label`.  E.g. out_template `$(ACTION_ID).analysis`    can be matched with `$(output $(ACTION_ID).analysis)`.  In effect, this is the same substitution as `$(location)`    but with a different scope. |
 | `out_templates` | List of strings; default is `[]` A list of templates for files generated by the `extra_action` command. The template can use the following variables:  * $(ACTION_ID), an id uniquely identifying this `extra_action`.   Used to generate a unique output file. |
 | `requires_action_output` | Boolean; default is `False` Indicates this `extra_action` requires the output of the original action to be present as input to this `extra_action`. When true (default false), the extra_action can assume that the original action outputs are available as part of its inputs. |
-| `tools` | List of [labels](/concepts/labels); default is `[]` A list of `tool` dependencies for this rule. See the definition of [dependencies](/concepts/build-ref#deps) for more information.  The build system ensures these prerequisites are built before running the `extra_action` command; they are built using the [`exec`configuration](/docs/user-manual#configurations), since they must run as a tool during the build itself. The path of an individual `tools` target `//x:y` can be obtained using `$(location //x:y)`.  All tools and their data dependencies are consolidated into a single tree within which the command can use relative paths. The working directory will be the root of that unified tree. |
\ No newline at end of file
+| `tools` | List of [labels](/versions/8.6.0/concepts/labels); default is `[]` A list of `tool` dependencies for this rule. See the definition of [dependencies](/versions/8.6.0/concepts/build-ref#deps) for more information.  The build system ensures these prerequisites are built before running the `extra_action` command; they are built using the [`exec`configuration](/versions/8.6.0/docs/user-manual#configurations), since they must run as a tool during the build itself. The path of an individual `tools` target `//x:y` can be obtained using `$(location //x:y)`.  All tools and their data dependencies are consolidated into a single tree within which the command can use relative paths. The working directory will be the root of that unified tree. |
\ No newline at end of file
diff --git a/versions/8.6.0/reference/be/functions.mdx b/versions/8.6.0/reference/be/functions.mdx
index e7c75155..f1e82eae 100644
--- a/versions/8.6.0/reference/be/functions.mdx
+++ b/versions/8.6.0/reference/be/functions.mdx
@@ -22,7 +22,7 @@ package. It is used at most once within a package (BUILD file).
 
 For the counterpart that declares metadata applying to every rule in the whole
 *repository*, use the `repo()` function in the
-[`REPO.bazel` file](/external/overview#repo.bazel) at the root of your repo.
+[`REPO.bazel` file](/versions/8.6.0/external/overview#repo.bazel) at the root of your repo.
 The `repo()` function takes exactly the same arguments as `package()`.
 
 The package() function should be called right after all the load() statements at the top of the
@@ -33,10 +33,10 @@ file, before any rule.
 | Attribute | Description |
 | --- | --- |
 | `default_applicable_licenses` | Alias for [`default_package_metadata`](#package.default_package_metadata). |
-| `default_visibility` | List of [labels](/concepts/labels); default is `[]`  The default visibility of the top-level rule targets and symbolic macros in this package — that is, the targets and symbolic macros that are not themselves declared inside a symbolic macro. This attribute is ignored if the target or macro specifies a `visibility` value.  For detailed information about the syntax of this attribute, see the documentation of [visibility](/concepts/visibility). The package default visibility does not apply to [exports_files](#exports_files), which is public by default. |
-| `default_deprecation` | String; default is `""`  Sets the default [`deprecation`](common-definitions#common.deprecation) message for all rules in this package. |
-| `default_package_metadata` | List of [labels](/concepts/labels); default is `[]`  Sets a default list of metadata targets which apply to all other targets in the package. These are typically targets related to OSS package and license declarations. See [rules_license](https://github.com/bazelbuild/rules_license) for examples. |
-| `default_testonly` | Boolean; default is `False` except as noted  Sets the default [`testonly`](common-definitions#common.testonly) property for all rules in this package.  In packages under `javatests` the default value is `True`. |
+| `default_visibility` | List of [labels](/versions/8.6.0/concepts/labels); default is `[]`  The default visibility of the top-level rule targets and symbolic macros in this package — that is, the targets and symbolic macros that are not themselves declared inside a symbolic macro. This attribute is ignored if the target or macro specifies a `visibility` value.  For detailed information about the syntax of this attribute, see the documentation of [visibility](/versions/8.6.0/concepts/visibility). The package default visibility does not apply to [exports_files](#exports_files), which is public by default. |
+| `default_deprecation` | String; default is `""`  Sets the default [`deprecation`](/versions/8.6.0/reference/be/common-definitions#common.deprecation) message for all rules in this package. |
+| `default_package_metadata` | List of [labels](/versions/8.6.0/concepts/labels); default is `[]`  Sets a default list of metadata targets which apply to all other targets in the package. These are typically targets related to OSS package and license declarations. See [rules_license](https://github.com/bazelbuild/rules_license) for examples. |
+| `default_testonly` | Boolean; default is `False` except as noted  Sets the default [`testonly`](/versions/8.6.0/reference/be/common-definitions#common.testonly) property for all rules in this package.  In packages under `javatests` the default value is `True`. |
 | `features` | List strings; default is `[]`  Sets various flags that affect the semantics of this BUILD file.  This feature is mainly used by the people working on the build system to tag packages that need some kind of special handling. Do not use this unless explicitly requested by someone working on the build system. |
 
 ### Examples
@@ -56,7 +56,7 @@ package(default_visibility = ["//foo:target"])
 package_group(name, packages, includes)
 ```
 
-This function defines a set of [packages](/concepts/build-ref#packages)
+This function defines a set of [packages](/versions/8.6.0/concepts/build-ref#packages)
 and associates a label with the set. The label can be referenced in
 `visibility` attributes.
 
@@ -66,7 +66,7 @@ visible target can only be referenced within its own package (not subpackages).
 In between these extremes, a target may allow access to its own package plus any
 of the packages described by one or more package groups. For a more detailed
 explanation of the visibility system, see the
-[visibility](common-definitions#common.visibility)
+[visibility](/versions/8.6.0/reference/be/common-definitions#common.visibility)
 attribute.
 
 A given package is considered to be in the group if it either matches the
@@ -80,9 +80,9 @@ not themselves have any visibility protection.
 
 | Attribute | Description |
 | --- | --- |
-| `name` | [Name](/concepts/labels#target-names); required  A unique name for this target. |
+| `name` | [Name](/versions/8.6.0/concepts/labels#target-names); required  A unique name for this target. |
 | `packages` | List of strings; default is `[]`  A list of zero or more package specifications.  Each package specification string can have one of the following forms:   1. The full name of a package, without its repository, starting with a    double slash. For example, `//foo/bar` specifies the package    having that name and which lives in the same repository as the package    group.- As above, but with a trailing `/...`. For example, `//foo/...` specifies the set of `//foo` and all its      subpackages. `//...` specifies all packages in the current      repository.- The strings `public` or `private`, which        respectively specify every package or no package. (This form requires        the flag `--incompatible_package_group_has_public_syntax` to        be set.)   In addition, the first two kinds of package specifications may also be prefixed with `-` to indicate that they are negated.  The package group contains any package that matches at least one of its positive specifications and none of its negative specifications For instance, the value `[//foo/..., -//foo/tests/...]` includes all subpackages of `//foo` that are not also subpackages of `//foo/tests`. (`//foo` itself is included while //foo/tests itself is not.)  Aside from public visibility, there is no way to directly specify packages outside the current repository.  If this attribute is missing, it is the same as setting it to an empty list, which is also the same as setting it to a list containing only `private`. *Note:* Prior to Bazel 6.0, the specification `//...` had a legacy behavior of being the same as `public`. This behavior is fixed when `--incompatible_fix_package_group_reporoot_syntax` is enabled, which is the default after Bazel 6.0.  *Note:* Prior to Bazel 6.0, when this attribute is serialized as part of `bazel query --output=proto` (or `--output=xml`), the leading slashes are omitted. For instance, `//pkg/foo/...` will output as `\"pkg/foo/...\"`. This behavior is fixed when `--incompatible_package_group_includes_double_slash` is enabled, which is the default after Bazel 6.0. |
-| `includes` | List of [labels](/concepts/labels); default is `[]`  Other package groups that are included in this one.  The labels in this attribute must refer to other package groups. Packages in referenced package groups are taken to be part of this package group. This is transitive — if package group `a` includes package group `b`, and `b` includes package group `c`, then every package in `c` will also be a member of `a`.  When used together with negated package specifications, note that the set of packages for each group is first computed independently and the results are then unioned together. This means that negated specifications in one group have no effect on the specifications in another group. |
+| `includes` | List of [labels](/versions/8.6.0/concepts/labels); default is `[]`  Other package groups that are included in this one.  The labels in this attribute must refer to other package groups. Packages in referenced package groups are taken to be part of this package group. This is transitive — if package group `a` includes package group `b`, and `b` includes package group `c`, then every package in `c` will also be a member of `a`.  When used together with negated package specifications, note that the set of packages for each group is first computed independently and the results are then unioned together. This means that negated specifications in one group have no effect on the specifications in another group. |
 
 ### Examples
 
@@ -144,7 +144,7 @@ this package that are exported to other packages.
 The BUILD file for a package may only refer directly to source files belonging
 to another package if they are explicitly exported with an
 `exports_files()` statement. Read more about
-[visibility of files](/concepts/visibility#source-file-target-visibility).
+[visibility of files](/versions/8.6.0/concepts/visibility#source-file-target-visibility).
 
 As a legacy behaviour, also files mentioned as input to a rule are exported
 with the default visibility until the flag
@@ -159,7 +159,7 @@ visibility declaration can also be specified; in this case, the files will be
 visible to the targets specified. If no visibility is specified, the files
 will be visible to every package, even if a package default visibility was
 specified in the `package`
-function. The [licenses](common-definitions#common.licenses)
+function. The [licenses](/versions/8.6.0/reference/be/common-definitions#common.licenses)
 can also be specified.
 
 ### Example
@@ -262,8 +262,7 @@ There are several important limitations and caveats:
    package called "Foo.java" (which is allowed, though Bazel warns about it),
    then the consumer of the `glob()` will use the "Foo.java" rule
    (its outputs) instead of the "Foo.java" file. See
-   [GitHub
-   issue #10395](https://github.com/bazelbuild/bazel/issues/10395#issuecomment-583714657) for more details.
+   [GitHub issue #10395](https://github.com/bazelbuild/bazel/issues/10395#issuecomment-583714657) for more details.
 3. Globs may match files in subdirectories. And subdirectory names
    may be wildcarded. However...
 4. Labels are not allowed to cross the package boundary and glob does
@@ -277,7 +276,7 @@ There are several important limitations and caveats:
    existence of BUILD files — that is, the same glob expression would
    include `x/y/z.cc` if there was no package called
    `x/y` or it was marked as deleted using the
-   [--deleted_packages](/docs/user-manual#flag--deleted_packages)
+   [--deleted_packages](/versions/8.6.0/docs/user-manual#flag--deleted_packages)
    flag.
 5. The restriction above applies to all glob expressions,
    no matter which wildcards they use.
@@ -409,7 +408,7 @@ select(
 ```
 
 `select()` is the helper function that makes a rule attribute
-[configurable](common-definitions#configurable-attributes).
+[configurable](/versions/8.6.0/reference/be/common-definitions#configurable-attributes).
 It can replace the right-hand side of
 *almost*
 any attribute assignment so its value depends on command-line Bazel flags.
diff --git a/versions/8.6.0/reference/be/general.mdx b/versions/8.6.0/reference/be/general.mdx
index 8840693c..1ff2b0be 100644
--- a/versions/8.6.0/reference/be/general.mdx
+++ b/versions/8.6.0/reference/be/general.mdx
@@ -27,7 +27,7 @@ and `test_suite` cannot be aliased.
 
 Aliasing may be of help in large repositories where renaming a target would require making
 changes to lots of files. You can also use alias rule to store a
-[select](/reference/be/functions#select) function call if you want to reuse that logic for
+[select](/versions/8.6.0/reference/be/functions#select) function call if you want to reuse that logic for
 multiple targets.
 
 The alias rule has its own visibility declaration. In all other respects, it behaves
@@ -60,8 +60,8 @@ alias(
 
 | Attributes | |
 | --- | --- |
-| `name` | [Name](/concepts/labels#target-names); required  A unique name for this target. |
-| `actual` | [Label](/concepts/labels); required The target this alias refers to. It does not need to be a rule, it can also be an input file. |
+| `name` | [Name](/versions/8.6.0/concepts/labels#target-names); required  A unique name for this target. |
+| `actual` | [Label](/versions/8.6.0/concepts/labels); required The target this alias refers to. It does not need to be a rule, it can also be an input file. |
 
 ## config_setting
 
@@ -72,8 +72,8 @@ config_setting(name, constraint_values, define_values, deprecation, distribs, fe
 ```
 
 Matches an expected configuration state (expressed as build flags or platform constraints) for
-the purpose of triggering configurable attributes. See [select](/reference/be/functions#select) for
-how to consume this rule and [Configurable attributes](/reference/be/common-definitions#configurable-attributes) for an overview of the general feature.
+the purpose of triggering configurable attributes. See [select](/versions/8.6.0/reference/be/functions#select) for
+how to consume this rule and [Configurable attributes](/versions/8.6.0/reference/be/common-definitions#configurable-attributes) for an overview of the general feature.
 
 #### Examples
 
@@ -101,7 +101,7 @@ The following matches any build that targets ARM and applies the custom define
 ```
 
 The following matches any build that sets
-[user-defined flag](https://bazel.build/rules/config#user-defined-build-settings)
+[user-defined flag](https://bazel.build/versions/8.6.0/rules/config#user-defined-build-settings)
 `--//custom_flags:foo=1` (either explicitly at the command line or implicitly from
 .bazelrc files):
 
@@ -134,13 +134,13 @@ some build targets.
 
 #### Notes
 
-* See [select](/reference/be/functions#select) for what happens when multiple
+* See [select](/versions/8.6.0/reference/be/functions#select) for what happens when multiple
   `config_setting`s match the current configuration state.
 * For flags that support shorthand forms (e.g. `--compilation_mode` vs.
   `-c`), `values` definitions must use the full form. These automatically
   match invocations using either form.
 * If a flag takes multiple values (like `--copt=-Da --copt=-Db` or a list-typed
-  [Starlark flag](https://bazel.build/rules/config#user-defined-build-settings)), `values = { "flag": "a" }` matches if `"a"` is
+  [Starlark flag](https://bazel.build/versions/8.6.0/rules/config#user-defined-build-settings)), `values = { "flag": "a" }` matches if `"a"` is
   present *anywhere* in the actual list.
 
   `values = { "myflag": "a,b" }` works the same way: this matches
@@ -153,14 +153,14 @@ some build targets.
   *does*: `-ios_multi_cpus=a,b` and `ios_multi_cpus=a --ios_multi_cpus=b` both produce `["a", "b"]`. Check flag definitions and test your
   conditions carefully to verify exact expectations.
 * If you need to define conditions that aren't modeled by built-in build flags, use
-  [Starlark-defined flags](https://bazel.build/rules/config#user-defined-build-settings). You can also use `--define`, but this offers weaker
+  [Starlark-defined flags](https://bazel.build/versions/8.6.0/rules/config#user-defined-build-settings). You can also use `--define`, but this offers weaker
   support and is not recommended. See
-  [here](/reference/be/common-definitions#configurable-attributes) for more discussion.
+  [here](/versions/8.6.0/reference/be/common-definitions#configurable-attributes) for more discussion.
 * Avoid repeating identical `config_setting` definitions in different packages.
   Instead, reference a common `config_setting` that defined in a canonical package.
-* [`values`](general#config_setting.values),
-  [`define_values`](general#config_setting.define_values), and
-  [`constraint_values`](general#config_setting.constraint_values)
+* [`values`](/versions/8.6.0/reference/be/general#config_setting.values),
+  [`define_values`](/versions/8.6.0/reference/be/general#config_setting.define_values), and
+  [`constraint_values`](/versions/8.6.0/reference/be/general#config_setting.constraint_values)
   can be used in any combination in the same `config_setting` but at least one must
   be set for any given `config_setting`.
 
@@ -168,11 +168,11 @@ some build targets.
 
 | Attributes | |
 | --- | --- |
-| `name` | [Name](/concepts/labels#target-names); required  A unique name for this target. |
-| `constraint_values` | List of [labels](/concepts/labels); [nonconfigurable](common-definitions#configurable-attributes); default is `[]` The minimum set of `constraint_values` that the target platform must specify in order to match this `config_setting`. (The execution platform is not considered here.) Any additional constraint values that the platform has are ignored. See [Configurable Build Attributes](https://bazel.build/docs/configurable-attributes#platforms) for details. If two `config_setting`s match in the same `select` and one has all the same flags and `constraint_setting`s as the other plus additional ones, the one with more settings is chosen. This is known as "specialization". For example, a `config_setting` matching `x86` and `Linux` specializes a `config_setting` matching `x86`. If two `config_setting`s match and both have `constraint_value`s not present in the other, this is an error. |
-| `define_values` | Dictionary: String -> String; [nonconfigurable](common-definitions#configurable-attributes); default is `{}` The same as [`values`](/reference/be/general#config_setting.values) but specifically for the `--define` flag. `--define` is special because its syntax (`--define KEY=VAL`) means `KEY=VAL` is a *value* from a Bazel flag perspective.  That means:  ```             config_setting(                 name = "a_and_b",                 values = {                     "define": "a=1",                     "define": "b=2",                 }) ```   doesn't work because the same key (`define`) appears twice in the dictionary. This attribute solves that problem:  ```             config_setting(                 name = "a_and_b",                 define_values = {                     "a": "1",                     "b": "2",                 }) ```   correctly matches `bazel build //foo --define a=1 --define b=2`. `--define` can still appear in [`values`](/reference/be/general#config_setting.values) with normal flag syntax, and can be mixed freely with this attribute as long as dictionary keys remain distinct. |
-| `flag_values` | Dictionary: [label](/concepts/labels) -> String; [nonconfigurable](common-definitions#configurable-attributes); default is `{}` The same as [`values`](/reference/be/general#config_setting.values) but for [user-defined build flags](https://bazel.build/rules/config#user-defined-build-settings). This is a distinct attribute because user-defined flags are referenced as labels while built-in flags are referenced as arbitrary strings. |
-| `values` | Dictionary: String -> String; [nonconfigurable](common-definitions#configurable-attributes); default is `{}` The set of configuration values that match this rule (expressed as build flags) This rule inherits the configuration of the configured target that references it in a `select` statement. It is considered to "match" a Bazel invocation if, for every entry in the dictionary, its configuration matches the entry's expected value. For example `values = {"compilation_mode": "opt"}` matches the invocations `bazel build --compilation_mode=opt ...` and `bazel build -c opt ...` on target-configured rules.  For convenience's sake, configuration values are specified as build flags (without the preceding `"--"`). But keep in mind that the two are not the same. This is because targets can be built in multiple configurations within the same build. For example, an exec configuration's "cpu" matches the value of `--host_cpu`, not `--cpu`. So different instances of the same `config_setting` may match the same invocation differently depending on the configuration of the rule using them.  If a flag is not explicitly set at the command line, its default value is used. If a key appears multiple times in the dictionary, only the last instance is used. If a key references a flag that can be set multiple times on the command line (e.g. `bazel build --copt=foo --copt=bar --copt=baz ...`), a match occurs if *any* of those settings match. |
+| `name` | [Name](/versions/8.6.0/concepts/labels#target-names); required  A unique name for this target. |
+| `constraint_values` | List of [labels](/versions/8.6.0/concepts/labels); [nonconfigurable](/versions/8.6.0/reference/be/common-definitions#configurable-attributes); default is `[]` The minimum set of `constraint_values` that the target platform must specify in order to match this `config_setting`. (The execution platform is not considered here.) Any additional constraint values that the platform has are ignored. See [Configurable Build Attributes](https://bazel.build/versions/8.6.0/docs/configurable-attributes#platforms) for details. If two `config_setting`s match in the same `select` and one has all the same flags and `constraint_setting`s as the other plus additional ones, the one with more settings is chosen. This is known as "specialization". For example, a `config_setting` matching `x86` and `Linux` specializes a `config_setting` matching `x86`. If two `config_setting`s match and both have `constraint_value`s not present in the other, this is an error. |
+| `define_values` | Dictionary: String -> String; [nonconfigurable](/versions/8.6.0/reference/be/common-definitions#configurable-attributes); default is `{}` The same as [`values`](/versions/8.6.0/reference/be/general#config_setting.values) but specifically for the `--define` flag. `--define` is special because its syntax (`--define KEY=VAL`) means `KEY=VAL` is a *value* from a Bazel flag perspective.  That means:  ```             config_setting(                 name = "a_and_b",                 values = {                     "define": "a=1",                     "define": "b=2",                 }) ```   doesn't work because the same key (`define`) appears twice in the dictionary. This attribute solves that problem:  ```             config_setting(                 name = "a_and_b",                 define_values = {                     "a": "1",                     "b": "2",                 }) ```   correctly matches `bazel build //foo --define a=1 --define b=2`. `--define` can still appear in [`values`](/versions/8.6.0/reference/be/general#config_setting.values) with normal flag syntax, and can be mixed freely with this attribute as long as dictionary keys remain distinct. |
+| `flag_values` | Dictionary: [label](/versions/8.6.0/concepts/labels) -> String; [nonconfigurable](/versions/8.6.0/reference/be/common-definitions#configurable-attributes); default is `{}` The same as [`values`](/versions/8.6.0/reference/be/general#config_setting.values) but for [user-defined build flags](https://bazel.build/versions/8.6.0/rules/config#user-defined-build-settings). This is a distinct attribute because user-defined flags are referenced as labels while built-in flags are referenced as arbitrary strings. |
+| `values` | Dictionary: String -> String; [nonconfigurable](/versions/8.6.0/reference/be/common-definitions#configurable-attributes); default is `{}` The set of configuration values that match this rule (expressed as build flags) This rule inherits the configuration of the configured target that references it in a `select` statement. It is considered to "match" a Bazel invocation if, for every entry in the dictionary, its configuration matches the entry's expected value. For example `values = {"compilation_mode": "opt"}` matches the invocations `bazel build --compilation_mode=opt ...` and `bazel build -c opt ...` on target-configured rules.  For convenience's sake, configuration values are specified as build flags (without the preceding `"--"`). But keep in mind that the two are not the same. This is because targets can be built in multiple configurations within the same build. For example, an exec configuration's "cpu" matches the value of `--host_cpu`, not `--cpu`. So different instances of the same `config_setting` may match the same invocation differently depending on the configuration of the rule using them.  If a flag is not explicitly set at the command line, its default value is used. If a key appears multiple times in the dictionary, only the last instance is used. If a key references a flag that can be set multiple times on the command line (e.g. `bazel build --copt=foo --copt=bar --copt=baz ...`), a match occurs if *any* of those settings match. |
 
 ## filegroup
 
@@ -194,7 +194,7 @@ the `data` attribute of a \*\_binary rule.
 Using `filegroup` is encouraged instead of referencing directories directly.
 Directly referencing directories is discouraged because the build system does not have
 full knowledge of all files below the directory, so it may not rebuild when these files change.
-When combined with [glob](/reference/be/functions#glob), `filegroup` can ensure that all
+When combined with [glob](/versions/8.6.0/reference/be/functions#glob), `filegroup` can ensure that all
 files are explicitly known to the build system.
 
 #### Examples
@@ -241,9 +241,9 @@ cc_library(
 
 | Attributes | |
 | --- | --- |
-| `name` | [Name](/concepts/labels#target-names); required  A unique name for this target. |
-| `srcs` | List of [labels](/concepts/labels); default is `[]` The list of targets that are members of the file group. It is common to use the result of a [glob](/reference/be/functions#glob) expression for the value of the `srcs` attribute. |
-| `data` | List of [labels](/concepts/labels); default is `[]` The list of files needed by this rule at runtime. Targets named in the `data` attribute will be added to the `runfiles` of this `filegroup` rule. When the `filegroup` is referenced in the `data` attribute of another rule its `runfiles` will be added to the `runfiles` of the depending rule. See the [data dependencies](/concepts/dependencies#data-dependencies) section and [general documentation of `data`](/reference/be/common-definitions#common.data) for more information about how to depend on and use data files. |
+| `name` | [Name](/versions/8.6.0/concepts/labels#target-names); required  A unique name for this target. |
+| `srcs` | List of [labels](/versions/8.6.0/concepts/labels); default is `[]` The list of targets that are members of the file group. It is common to use the result of a [glob](/versions/8.6.0/reference/be/functions#glob) expression for the value of the `srcs` attribute. |
+| `data` | List of [labels](/versions/8.6.0/concepts/labels); default is `[]` The list of files needed by this rule at runtime. Targets named in the `data` attribute will be added to the `runfiles` of this `filegroup` rule. When the `filegroup` is referenced in the `data` attribute of another rule its `runfiles` will be added to the `runfiles` of the depending rule. See the [data dependencies](/versions/8.6.0/concepts/dependencies#data-dependencies) section and [general documentation of `data`](/versions/8.6.0/reference/be/common-definitions#common.data) for more information about how to depend on and use data files. |
 | `output_group` | String; default is `""` The output group from which to gather artifacts from sources. If this attribute is specified, artifacts from the specified output group of the dependencies will be exported instead of the default output group. An "output group" is a category of output artifacts of a target, specified in that rule's implementation. |
 
 ## genquery
@@ -255,7 +255,7 @@ genquery(name, deps, data, compatible_with, compressed_output, deprecation, dist
 ```
 
 `genquery()` runs a query specified in the
-[Bazel query language](/reference/query) and dumps the result
+[Bazel query language](/versions/8.6.0/reference/query) and dumps the result
 into a file.
 
 In order to keep the build consistent, the query is allowed only to visit
@@ -298,11 +298,11 @@ genquery(
 
 | Attributes | |
 | --- | --- |
-| `name` | [Name](/concepts/labels#target-names); required  A unique name for this target. |
+| `name` | [Name](/versions/8.6.0/concepts/labels#target-names); required  A unique name for this target. |
 | `compressed_output` | Boolean; default is `False` If `True`, query output is written in GZIP file format. This setting can be used to avoid spikes in Bazel's memory use when the query output is expected to be large. Bazel already internally compresses query outputs greater than 220 bytes regardless of the value of this setting, so setting this to `True` may not reduce retained heap. However, it allows Bazel to skip *decompression* when writing the output file, which can be memory-intensive. |
 | `expression` | String; required The query to be executed. In contrast to the command line and other places in BUILD files, labels here are resolved relative to the root directory of the workspace. For example, the label `:b` in this attribute in the file `a/BUILD` will refer to the target `//:b`. |
 | `opts` | List of strings; default is `[]` The options that are passed to the query engine. These correspond to the command line options that can be passed to `bazel query`. Some query options are not allowed here: `--keep_going`, `--query_file`, `--universe_scope`, `--order_results` and `--order_output`. Options not specified here will have their default values just like on the command line of `bazel query`. |
-| `scope` | List of [labels](/concepts/labels); required The scope of the query. The query is not allowed to touch targets outside the transitive closure of these targets. |
+| `scope` | List of [labels](/versions/8.6.0/concepts/labels); required The scope of the query. The query is not allowed to touch targets outside the transitive closure of these targets. |
 | `strict` | Boolean; default is `True` If true, targets whose queries escape the transitive closure of their scopes will fail to build. If false, Bazel will print a warning and skip whatever query path led it outside of the scope, while completing the rest of the query. |
 
 ## genrule
@@ -338,11 +338,11 @@ Do not use a genrule for running tests. There are special dispensations for test
 results, including caching policies and environment variables. Tests generally need to be run
 after the build is complete and on the target architecture, whereas genrules are executed during
 the build and on the exec architecture (the two may be different). If you need a general purpose
-testing rule, use [`sh_test`](/reference/be/shell#sh_test).
+testing rule, use [`sh_test`](/versions/8.6.0/reference/be/shell#sh_test).
 
 #### Cross-compilation Considerations
 
-*See [the user manual](/docs/user-manual#configurations) for more info about
+*See [the user manual](/versions/8.6.0/docs/user-manual#configurations) for more info about
 cross-compilation.*
 
 While genrules run during a build, their outputs are often used after the build, for deployment or
@@ -359,7 +359,7 @@ corresponding files into separate directories to avoid conflicts.
 For genrules, the build system ensures that dependencies are built appropriately:
 `srcs` are built (if necessary) for the *target* configuration,
 `tools` are built for the *exec* configuration, and the output is considered to
-be for the *target* configuration. It also provides ["Make" variables](/reference/be/make-variables) that genrule commands can pass to the corresponding tools.
+be for the *target* configuration. It also provides ["Make" variables](/versions/8.6.0/reference/be/make-variables) that genrule commands can pass to the corresponding tools.
 
 It is intentional that genrule defines no `deps` attribute: other built-in rules use
 language-dependent meta information passed between the rules to automatically determine how to
@@ -374,11 +374,11 @@ which is subsequently used by another genrule, the first one has to produce its
 exec configuration, because that's where the compiler will run in the other genrule. In this case,
 the build system does the right thing automatically: it builds the `srcs` and
 `outs` of the first genrule for the exec configuration instead of the target
-configuration. See [the user manual](/docs/user-manual#configurations) for more
+configuration. See [the user manual](/versions/8.6.0/docs/user-manual#configurations) for more
 info.
 
 *JDK & C++ Tooling*: to use a tool from the JDK or the C++ compiler suite, the build system
-provides a set of variables to use. See ["Make" variable](/reference/be/make-variables) for
+provides a set of variables to use. See ["Make" variable](/versions/8.6.0/reference/be/make-variables) for
 details.
 
 #### Genrule Environment
@@ -444,7 +444,7 @@ genrule(
 )
 ```
 
-The following example shows how to use a [`filegroup`](/reference/be/general#filegroup) and the outputs of another `genrule`. Note that using `$(SRCS)` instead
+The following example shows how to use a [`filegroup`](/versions/8.6.0/reference/be/general#filegroup) and the outputs of another `genrule`. Note that using `$(SRCS)` instead
 of explicit `$(location)` directives would also work; this example uses the latter for
 sake of demonstration.
 
@@ -464,10 +464,10 @@ genrule(
 
 | Attributes | |
 | --- | --- |
-| `name` | [Name](/concepts/labels#target-names); required  A unique name for this target.  You may refer to this rule by name in the `srcs` or `deps` section of other `BUILD` rules. If the rule generates source files, you should use the `srcs` attribute. |
-| `srcs` | List of [labels](/concepts/labels); default is `[]` A list of inputs for this rule, such as source files to process. *This attributes is not suitable to list tools executed by the `cmd`; use the [`tools`](/reference/be/general#genrule.tools) attribute for them instead.*  The build system ensures these prerequisites are built before running the genrule command; they are built using the same configuration as the original build request. The names of the files of these prerequisites are available to the command as a space-separated list in `$(SRCS)`; alternatively the path of an individual `srcs` target `//x:y` can be obtained using `$(location //x:y)`, or using `$<` provided it's the only entry in `srcs`. |
-| `outs` | List of [filenames](/concepts/build-ref#filename); [nonconfigurable](common-definitions#configurable-attributes); required A list of files generated by this rule. Output files must not cross package boundaries. Output filenames are interpreted as relative to the package.  If the `executable` flag is set, `outs` must contain exactly one label.  The genrule command is expected to create each output file at a predetermined location. The location is available in `cmd` using [genrule-specific "Make" variables](/reference/be/make-variables#predefined_genrule_variables) (`$@`, `$(OUTS)`, `$(@D)` or `$(RULEDIR)`) or using [`$(location)`](/reference/be/make-variables#predefined_label_variables) substitution. |
-| `cmd` | String; default is `""` The command to run. Subject to [`$(location)`](/reference/be/make-variables#predefined_label_variables) and ["Make" variable](/reference/be/make-variables) substitution.  1. First [`$(location)`](/reference/be/make-variables#predefined_label_variables) substitution is applied, replacing all occurrences of `$(location     label)` and of `$(locations label)` (and similar    constructions using related variables `execpath`, `execpaths`,    `rootpath` and `rootpaths`). 2. Next, ["Make" variables](/reference/be/make-variables) are expanded. Note that    predefined variables `$(JAVA)`, `$(JAVAC)` and    `$(JAVABASE)` expand under the *exec* configuration, so Java invocations    that run as part of a build step can correctly load shared libraries and other    dependencies. 3. Finally, the resulting command is executed using the Bash shell. If its exit code is    non-zero the command is considered to have failed.  This is the fallback of `cmd_bash`, `cmd_ps` and `cmd_bat`, if none of them are applicable. |
+| `name` | [Name](/versions/8.6.0/concepts/labels#target-names); required  A unique name for this target.  You may refer to this rule by name in the `srcs` or `deps` section of other `BUILD` rules. If the rule generates source files, you should use the `srcs` attribute. |
+| `srcs` | List of [labels](/versions/8.6.0/concepts/labels); default is `[]` A list of inputs for this rule, such as source files to process. *This attributes is not suitable to list tools executed by the `cmd`; use the [`tools`](/versions/8.6.0/reference/be/general#genrule.tools) attribute for them instead.*  The build system ensures these prerequisites are built before running the genrule command; they are built using the same configuration as the original build request. The names of the files of these prerequisites are available to the command as a space-separated list in `$(SRCS)`; alternatively the path of an individual `srcs` target `//x:y` can be obtained using `$(location //x:y)`, or using `$<` provided it's the only entry in `srcs`. |
+| `outs` | List of [filenames](/versions/8.6.0/concepts/build-ref#filename); [nonconfigurable](/versions/8.6.0/reference/be/common-definitions#configurable-attributes); required A list of files generated by this rule. Output files must not cross package boundaries. Output filenames are interpreted as relative to the package.  If the `executable` flag is set, `outs` must contain exactly one label.  The genrule command is expected to create each output file at a predetermined location. The location is available in `cmd` using [genrule-specific "Make" variables](/versions/8.6.0/reference/be/make-variables#predefined_genrule_variables) (`$@`, `$(OUTS)`, `$(@D)` or `$(RULEDIR)`) or using [`$(location)`](/versions/8.6.0/reference/be/make-variables#predefined_label_variables) substitution. |
+| `cmd` | String; default is `""` The command to run. Subject to [`$(location)`](/versions/8.6.0/reference/be/make-variables#predefined_label_variables) and ["Make" variable](/versions/8.6.0/reference/be/make-variables) substitution.  1. First [`$(location)`](/versions/8.6.0/reference/be/make-variables#predefined_label_variables) substitution is applied, replacing all occurrences of `$(location     label)` and of `$(locations label)` (and similar    constructions using related variables `execpath`, `execpaths`,    `rootpath` and `rootpaths`). 2. Next, ["Make" variables](/versions/8.6.0/reference/be/make-variables) are expanded. Note that    predefined variables `$(JAVA)`, `$(JAVAC)` and    `$(JAVABASE)` expand under the *exec* configuration, so Java invocations    that run as part of a build step can correctly load shared libraries and other    dependencies. 3. Finally, the resulting command is executed using the Bash shell. If its exit code is    non-zero the command is considered to have failed.  This is the fallback of `cmd_bash`, `cmd_ps` and `cmd_bat`, if none of them are applicable. |
 
 If the command line length exceeds the platform limit (64K on Linux/macOS, 8K on Windows),
 then genrule will write the command to a script and execute that script to work around. This
@@ -475,15 +475,15 @@ applies to all cmd attributes (`cmd`, `cmd_bash`, `cmd_ps`,
 `cmd_bat`).
 
 | `cmd_bash` | String; default is `""` The Bash command to run. This attribute has higher priority than `cmd`. The command is expanded and runs in the exact same way as the `cmd` attribute. |
-| `cmd_bat` | String; default is `""` The Batch command to run on Windows. This attribute has higher priority than `cmd` and `cmd_bash`. The command runs in the similar way as the `cmd` attribute, with the following differences:   * This attribute only applies on Windows. * The command runs with `cmd.exe /c` with the following default arguments:   + `/S` - strip first and last quotes and execute everything else as is.   + `/E:ON` - enable extended command set.   + `/V:ON` - enable delayed variable expansion   + `/D` - ignore AutoRun registry entries. * After [$(location)](/reference/be/make-variables#predefined_label_variables) and   ["Make" variable](/reference/be/make-variables) substitution, the paths will be   expanded to Windows style paths (with backslash). |
+| `cmd_bat` | String; default is `""` The Batch command to run on Windows. This attribute has higher priority than `cmd` and `cmd_bash`. The command runs in the similar way as the `cmd` attribute, with the following differences:   * This attribute only applies on Windows. * The command runs with `cmd.exe /c` with the following default arguments:   + `/S` - strip first and last quotes and execute everything else as is.   + `/E:ON` - enable extended command set.   + `/V:ON` - enable delayed variable expansion   + `/D` - ignore AutoRun registry entries. * After [$(location)](/versions/8.6.0/reference/be/make-variables#predefined_label_variables) and   ["Make" variable](/versions/8.6.0/reference/be/make-variables) substitution, the paths will be   expanded to Windows style paths (with backslash). |
 | `cmd_ps` | String; default is `""` The Powershell command to run on Windows. This attribute has higher priority than `cmd`, `cmd_bash` and `cmd_bat`. The command runs in the similar way as the `cmd` attribute, with the following differences:   * This attribute only applies on Windows. * The command runs with `powershell.exe /c`.   To make Powershell easier to use and less error-prone, we run the following commands to set up the environment before executing Powershell command in genrule.   * `Set-ExecutionPolicy -Scope CurrentUser RemoteSigned` - allow running   unsigned scripts. * `$errorActionPreference='Stop'` - In case there are multiple commands   separated by `;`, the action exits immediately if a Powershell CmdLet fails,   but this does **NOT** work for external command. * `$PSDefaultParameterValues['*:Encoding'] = 'utf8'` - change the default   encoding from utf-16 to utf-8. |
-| `executable` | Boolean; [nonconfigurable](common-definitions#configurable-attributes); default is `False` Declare output to be executable. Setting this flag to True means the output is an executable file and can be run using the `run` command. The genrule must produce exactly one output in this case. If this attribute is set, `run` will try executing the file regardless of its content.  Declaring data dependencies for the generated executable is not supported. |
+| `executable` | Boolean; [nonconfigurable](/versions/8.6.0/reference/be/common-definitions#configurable-attributes); default is `False` Declare output to be executable. Setting this flag to True means the output is an executable file and can be run using the `run` command. The genrule must produce exactly one output in this case. If this attribute is set, `run` will try executing the file regardless of its content.  Declaring data dependencies for the generated executable is not supported. |
 | `local` | Boolean; default is `False`  If set to True, this option forces this `genrule` to run using the "local" strategy, which means no remote execution, no sandboxing, no persistent workers.  This is equivalent to providing 'local' as a tag (`tags=["local"]`). |
 | `message` | String; default is `""` A progress message. A progress message that will be printed as this build step is executed. By default, the message is "Generating *output*" (or something equally bland) but you may provide a more specific one. Use this attribute instead of `echo` or other print statements in your `cmd` command, as this allows the build tool to control whether such progress messages are printed or not. |
-| `output_licenses` | Licence type; default is `["none"]` See [`common attributes`](/reference/be/common-definitions#binary.output_licenses) |
-| `output_to_bindir` | Boolean; [nonconfigurable](common-definitions#configurable-attributes); default is `False`  If set to True, this option causes output files to be written into the `bin` directory instead of the `genfiles` directory. |
-| `toolchains` | List of [labels](/concepts/labels); [nonconfigurable](common-definitions#configurable-attributes); default is `[]`  The set of targets whose [Make variables](/reference/be/make-variables) this genrule is allowed to access, or the [`toolchain_type`](/docs/toolchains) targets that this genrule will access.  Toolchains accessed via `toolchain_type` must also provide a `TemplateVariableInfo` provider, which the target can use to access toolchain details. |
-| `tools` | List of [labels](/concepts/labels); default is `[]` A list of *tool* dependencies for this rule. See the definition of [dependencies](/concepts/build-ref#deps) for more information.   The build system ensures these prerequisites are built before running the genrule command; they are built using the [*exec* configuration](/contribute/guide#configurations), since these tools are executed as part of the build. The path of an individual `tools` target `//x:y` can be obtained using `$(location //x:y)`.  Any `*_binary` or tool to be executed by `cmd` must appear in this list, not in `srcs`, to ensure they are built in the correct configuration. |
+| `output_licenses` | Licence type; default is `["none"]` See [`common attributes`](/versions/8.6.0/reference/be/common-definitions#binary.output_licenses) |
+| `output_to_bindir` | Boolean; [nonconfigurable](/versions/8.6.0/reference/be/common-definitions#configurable-attributes); default is `False`  If set to True, this option causes output files to be written into the `bin` directory instead of the `genfiles` directory. |
+| `toolchains` | List of [labels](/versions/8.6.0/concepts/labels); [nonconfigurable](/versions/8.6.0/reference/be/common-definitions#configurable-attributes); default is `[]`  The set of targets whose [Make variables](/versions/8.6.0/reference/be/make-variables) this genrule is allowed to access, or the [`toolchain_type`](/versions/8.6.0/docs/toolchains) targets that this genrule will access.  Toolchains accessed via `toolchain_type` must also provide a `TemplateVariableInfo` provider, which the target can use to access toolchain details. |
+| `tools` | List of [labels](/versions/8.6.0/concepts/labels); default is `[]` A list of *tool* dependencies for this rule. See the definition of [dependencies](/versions/8.6.0/concepts/build-ref#deps) for more information.   The build system ensures these prerequisites are built before running the genrule command; they are built using the [*exec* configuration](/versions/8.6.0/contribute/guide#configurations), since these tools are executed as part of the build. The path of an individual `tools` target `//x:y` can be obtained using `$(location //x:y)`.  Any `*_binary` or tool to be executed by `cmd` must appear in this list, not in `srcs`, to ensure they are built in the correct configuration. |
 
 ## starlark_doc_extract
 
@@ -514,9 +514,9 @@ internal use by [Stardoc](https://github.com/bazelbuild/stardoc).
 
 | Attributes | |
 | --- | --- |
-| `name` | [Name](/concepts/labels#target-names); required  A unique name for this target. |
-| `deps` | List of [labels](/concepts/labels); default is `[]` A list of targets wrapping the Starlark files which are `load()`-ed by `src`. These targets *should* under normal usage be [`bzl_library`](https://github.com/bazelbuild/bazel-skylib/blob/main/bzl_library.bzl) targets, but the `starlark_doc_extract` rule does not enforce that, and accepts any target which provides Starlark files in its `DefaultInfo`. Note that the wrapped Starlark files must be files in the source tree; Bazel cannot `load()` generated files. |
-| `src` | [Label](/concepts/labels); required A Starlark file from which to extract documentation. Note that this must be a file in the source tree; Bazel cannot `load()` generated files. |
+| `name` | [Name](/versions/8.6.0/concepts/labels#target-names); required  A unique name for this target. |
+| `deps` | List of [labels](/versions/8.6.0/concepts/labels); default is `[]` A list of targets wrapping the Starlark files which are `load()`-ed by `src`. These targets *should* under normal usage be [`bzl_library`](https://github.com/bazelbuild/bazel-skylib/blob/main/bzl_library.bzl) targets, but the `starlark_doc_extract` rule does not enforce that, and accepts any target which provides Starlark files in its `DefaultInfo`. Note that the wrapped Starlark files must be files in the source tree; Bazel cannot `load()` generated files. |
+| `src` | [Label](/versions/8.6.0/concepts/labels); required A Starlark file from which to extract documentation. Note that this must be a file in the source tree; Bazel cannot `load()` generated files. |
 | `render_main_repo_name` | Boolean; default is `False` If true, render labels in the main repository in emitted documentation with a repo component (in other words, `//foo:bar.bzl` will be emitted as `@main_repo_name//foo:bar.bzl`). The name to use for the main repository is obtained from `module(name = ...)` in the main repository's `MODULE.bazel` file (if Bzlmod is enabled), or from `workspace(name = ...)` in the main repository's `WORKSPACE` file. This attribute should be set to `False` when generating documentation for Starlark files which are intended to be used only within the same repository, and to `True` when generating documentation for Starlark files which are intended to be used from other repositories. |
 | `symbol_names` | List of strings; default is `[]` An optional list of qualified names of exported functions, rules, providers, or aspects (or structs in which they are nested) for which to extract documentation. Here, a *qualified name* means the name under which an entity is made available to a user of the module, including any structs in which the entity is nested for namespacing. `starlark_doc_extract` emits documentation for an entity if and only if  1. each component of the entity's qualified name is public (in other words, the first    character of each component of the qualified name is alphabetic, not `"_"`);    *and* 2. 1. *either* the `symbol_names` list is empty (which is the default       case), *or*    2. the entity's qualified name, or the qualified name of a struct in which the entity       is nested, is in the `symbol_names` list. |
 
@@ -571,6 +571,6 @@ test_suite(
 
 | Attributes | |
 | --- | --- |
-| `name` | [Name](/concepts/labels#target-names); required  A unique name for this target. |
-| `tags` | List of strings; [nonconfigurable](common-definitions#configurable-attributes); default is `[]` List of text tags such as "small" or "database" or "-flaky". Tags may be any valid string. Tags which begin with a "-" character are considered negative tags. The preceding "-" character is not considered part of the tag, so a suite tag of "-small" matches a test's "small" size. All other tags are considered positive tags.  Optionally, to make positive tags more explicit, tags may also begin with the "+" character, which will not be evaluated as part of the text of the tag. It merely makes the positive and negative distinction easier to read.  Only test rules that match **all** of the positive tags and **none** of the negative tags will be included in the test suite. Note that this does not mean that error checking for dependencies on tests that are filtered out is skipped; the dependencies on skipped tests still need to be legal (e.g. not blocked by visibility constraints).  The `manual` tag keyword is treated differently than the above by the "test_suite expansion" performed by the `bazel test` command on invocations involving wildcard [target patterns](https://bazel.build/docs/build#specifying-build-targets). There, `test_suite` targets tagged "manual" are filtered out (and thus not expanded). This behavior is consistent with how `bazel build` and `bazel test` handle wildcard target patterns in general. Note that this is explicitly different from how `bazel query 'tests(E)'` behaves, as suites are always expanded by the `tests` query function, regardless of the `manual` tag.  Note that a test's `size` is considered a tag for the purpose of filtering.  If you need a `test_suite` that contains tests with mutually exclusive tags (e.g. all small and medium tests), you'll have to create three `test_suite` rules: one for all small tests, one for all medium tests, and one that includes the previous two. |
-| `tests` | List of [labels](/concepts/labels); [nonconfigurable](common-definitions#configurable-attributes); default is `[]` A list of test suites and test targets of any language. Any `*_test` is accepted here, independent of the language. No `*_binary` targets are accepted however, even if they happen to run a test. Filtering by the specified `tags` is only done for tests listed directly in this attribute. If this attribute contains `test_suite`s, the tests inside those will not be filtered by this `test_suite` (they are considered to be filtered already).  If the `tests` attribute is unspecified or empty, the rule will default to including all test rules in the current BUILD file that are not tagged as `manual`. These rules are still subject to `tag` filtering. |
\ No newline at end of file
+| `name` | [Name](/versions/8.6.0/concepts/labels#target-names); required  A unique name for this target. |
+| `tags` | List of strings; [nonconfigurable](/versions/8.6.0/reference/be/common-definitions#configurable-attributes); default is `[]` List of text tags such as "small" or "database" or "-flaky". Tags may be any valid string. Tags which begin with a "-" character are considered negative tags. The preceding "-" character is not considered part of the tag, so a suite tag of "-small" matches a test's "small" size. All other tags are considered positive tags.  Optionally, to make positive tags more explicit, tags may also begin with the "+" character, which will not be evaluated as part of the text of the tag. It merely makes the positive and negative distinction easier to read.  Only test rules that match **all** of the positive tags and **none** of the negative tags will be included in the test suite. Note that this does not mean that error checking for dependencies on tests that are filtered out is skipped; the dependencies on skipped tests still need to be legal (e.g. not blocked by visibility constraints).  The `manual` tag keyword is treated differently than the above by the "test_suite expansion" performed by the `bazel test` command on invocations involving wildcard [target patterns](https://bazel.build/versions/8.6.0/docs/build#specifying-build-targets). There, `test_suite` targets tagged "manual" are filtered out (and thus not expanded). This behavior is consistent with how `bazel build` and `bazel test` handle wildcard target patterns in general. Note that this is explicitly different from how `bazel query 'tests(E)'` behaves, as suites are always expanded by the `tests` query function, regardless of the `manual` tag.  Note that a test's `size` is considered a tag for the purpose of filtering.  If you need a `test_suite` that contains tests with mutually exclusive tags (e.g. all small and medium tests), you'll have to create three `test_suite` rules: one for all small tests, one for all medium tests, and one that includes the previous two. |
+| `tests` | List of [labels](/versions/8.6.0/concepts/labels); [nonconfigurable](/versions/8.6.0/reference/be/common-definitions#configurable-attributes); default is `[]` A list of test suites and test targets of any language. Any `*_test` is accepted here, independent of the language. No `*_binary` targets are accepted however, even if they happen to run a test. Filtering by the specified `tags` is only done for tests listed directly in this attribute. If this attribute contains `test_suite`s, the tests inside those will not be filtered by this `test_suite` (they are considered to be filtered already).  If the `tests` attribute is unspecified or empty, the rule will default to including all test rules in the current BUILD file that are not tagged as `manual`. These rules are still subject to `tag` filtering. |
\ No newline at end of file
diff --git a/versions/8.6.0/reference/be/java.mdx b/versions/8.6.0/reference/be/java.mdx
index 9fe6ef85..67832769 100644
--- a/versions/8.6.0/reference/be/java.mdx
+++ b/versions/8.6.0/reference/be/java.mdx
@@ -15,7 +15,7 @@ title: 'Java Rules'
 
 ## java_binary
 
-[View rule sourceopen_in_new](@rules_java//java/bazel/rules/bazel_java_binary.bzl)
+[View rule sourceopen_in_new](/versions/8.6.0/reference/be/@rules_java//java/bazel/rules/bazel_java_binary.bzl)
 
 ```
 java_binary(name, deps, srcs, data, resources, add_exports, add_opens, args, bootclasspath, classpath_resources, compatible_with, create_executable, deploy_env, deploy_manifest_lines, deprecation, distribs, env, exec_compatible_with, exec_properties, features, javacopts, jvm_flags, launcher, licenses, main_class, neverlink, output_licenses, plugins, resource_strip_prefix, restricted_to, runtime_deps, stamp, tags, target_compatible_with, testonly, toolchains, use_launcher, use_testrunner, visibility)
@@ -101,33 +101,33 @@ java_binary(
 
 | Attributes | |
 | --- | --- |
-| `name` | [Name](/concepts/labels#target-names); required  A unique name for this target. |
-| `deps` | List of [labels](/concepts/labels); default is `[]` The list of other libraries to be linked in to the target. See general comments about `deps` at [Typical attributes defined by most build rules](common-definitions#typical-attributes). |
-| `srcs` | List of [labels](/concepts/labels); default is `[]` The list of source files that are processed to create the target. This attribute is almost always required; see exceptions below. Source files of type `.java` are compiled. In case of generated `.java` files it is generally advisable to put the generating rule's name here instead of the name of the file itself. This not only improves readability but makes the rule more resilient to future changes: if the generating rule generates different files in the future, you only need to fix one place: the `outs` of the generating rule. You should not list the generating rule in `deps` because it is a no-op.  Source files of type `.srcjar` are unpacked and compiled. (This is useful if you need to generate a set of `.java` files with a genrule.)  Rules: if the rule (typically `genrule` or `filegroup`) generates any of the files listed above, they will be used the same way as described for source files.  This argument is almost always required, except if a [`main_class`](#java_binary.main_class) attribute specifies a class on the runtime classpath or you specify the `runtime_deps` argument. |
-| `data` | List of [labels](/concepts/labels); default is `[]` The list of files needed by this library at runtime. See general comments about `data` at [Typical attributes defined by most build rules](/reference/be/common-definitions#typical-attributes). |
-| `resources` | List of [labels](/concepts/labels); default is `[]` A list of data files to include in a Java jar. Resources may be source files or generated files.  If resources are specified, they will be bundled in the jar along with the usual `.class` files produced by compilation. The location of the resources inside of the jar file is determined by the project structure. Bazel first looks for Maven's [standard directory layout](https://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html), (a "src" directory followed by a "resources" directory grandchild). If that is not found, Bazel then looks for the topmost directory named "java" or "javatests" (so, for example, if a resource is at `<workspace root>/x/java/y/java/z`, the path of the resource will be `y/java/z`. This heuristic cannot be overridden, however, the `resource_strip_prefix` attribute can be used to specify a specific alternative directory for resource files. |
+| `name` | [Name](/versions/8.6.0/concepts/labels#target-names); required  A unique name for this target. |
+| `deps` | List of [labels](/versions/8.6.0/concepts/labels); default is `[]` The list of other libraries to be linked in to the target. See general comments about `deps` at [Typical attributes defined by most build rules](/versions/8.6.0/reference/be/common-definitions#typical-attributes). |
+| `srcs` | List of [labels](/versions/8.6.0/concepts/labels); default is `[]` The list of source files that are processed to create the target. This attribute is almost always required; see exceptions below. Source files of type `.java` are compiled. In case of generated `.java` files it is generally advisable to put the generating rule's name here instead of the name of the file itself. This not only improves readability but makes the rule more resilient to future changes: if the generating rule generates different files in the future, you only need to fix one place: the `outs` of the generating rule. You should not list the generating rule in `deps` because it is a no-op.  Source files of type `.srcjar` are unpacked and compiled. (This is useful if you need to generate a set of `.java` files with a genrule.)  Rules: if the rule (typically `genrule` or `filegroup`) generates any of the files listed above, they will be used the same way as described for source files.  This argument is almost always required, except if a [`main_class`](#java_binary.main_class) attribute specifies a class on the runtime classpath or you specify the `runtime_deps` argument. |
+| `data` | List of [labels](/versions/8.6.0/concepts/labels); default is `[]` The list of files needed by this library at runtime. See general comments about `data` at [Typical attributes defined by most build rules](/versions/8.6.0/reference/be/common-definitions#typical-attributes). |
+| `resources` | List of [labels](/versions/8.6.0/concepts/labels); default is `[]` A list of data files to include in a Java jar. Resources may be source files or generated files.  If resources are specified, they will be bundled in the jar along with the usual `.class` files produced by compilation. The location of the resources inside of the jar file is determined by the project structure. Bazel first looks for Maven's [standard directory layout](https://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html), (a "src" directory followed by a "resources" directory grandchild). If that is not found, Bazel then looks for the topmost directory named "java" or "javatests" (so, for example, if a resource is at `<workspace root>/x/java/y/java/z`, the path of the resource will be `y/java/z`. This heuristic cannot be overridden, however, the `resource_strip_prefix` attribute can be used to specify a specific alternative directory for resource files. |
 | `add_exports` | List of strings; default is `[]` Allow this library to access the given `module` or `package`. This corresponds to the javac and JVM --add-exports= flags. |
 | `add_opens` | List of strings; default is `[]` Allow this library to reflectively access the given `module` or `package`. This corresponds to the javac and JVM --add-opens= flags. |
-| `bootclasspath` | [Label](/concepts/labels); default is `None` Restricted API, do not use! |
-| `classpath_resources` | List of [labels](/concepts/labels); default is `[]` *DO NOT USE THIS OPTION UNLESS THERE IS NO OTHER WAY)* A list of resources that must be located at the root of the java tree. This attribute's only purpose is to support third-party libraries that require that their resources be found on the classpath as exactly `"myconfig.xml"`. It is only allowed on binaries and not libraries, due to the danger of namespace conflicts. |
+| `bootclasspath` | [Label](/versions/8.6.0/concepts/labels); default is `None` Restricted API, do not use! |
+| `classpath_resources` | List of [labels](/versions/8.6.0/concepts/labels); default is `[]` *DO NOT USE THIS OPTION UNLESS THERE IS NO OTHER WAY)* A list of resources that must be located at the root of the java tree. This attribute's only purpose is to support third-party libraries that require that their resources be found on the classpath as exactly `"myconfig.xml"`. It is only allowed on binaries and not libraries, due to the danger of namespace conflicts. |
 | `create_executable` | Boolean; default is `True` Deprecated, use `java_single_jar` instead. |
-| `deploy_env` | List of [labels](/concepts/labels); default is `[]` A list of other `java_binary` targets which represent the deployment environment for this binary. Set this attribute when building a plugin which will be loaded by another `java_binary`.  Setting this attribute excludes all dependencies from the runtime classpath (and the deploy jar) of this binary that are shared between this binary and the targets specified in `deploy_env`. |
-| `deploy_manifest_lines` | List of strings; default is `[]` A list of lines to add to the `META-INF/manifest.mf` file generated for the `*_deploy.jar` target. The contents of this attribute are *not* subject to ["Make variable"](make-variables) substitution. |
-| `javacopts` | List of strings; default is `[]` Extra compiler options for this binary. Subject to ["Make variable"](make-variables) substitution and [Bourne shell tokenization](common-definitions#sh-tokenization). These compiler options are passed to javac after the global compiler options. |
-| `jvm_flags` | List of strings; default is `[]` A list of flags to embed in the wrapper script generated for running this binary. Subject to [$(location)](/reference/be/make-variables#location) and ["Make variable"](make-variables) substitution, and [Bourne shell tokenization](common-definitions#sh-tokenization). The wrapper script for a Java binary includes a CLASSPATH definition (to find all the dependent jars) and invokes the right Java interpreter. The command line generated by the wrapper script includes the name of the main class followed by a `"$@"` so you can pass along other arguments after the classname. However, arguments intended for parsing by the JVM must be specified *before* the classname on the command line. The contents of `jvm_flags` are added to the wrapper script before the classname is listed.  Note that this attribute has *no effect* on `*_deploy.jar` outputs. |
-| `launcher` | [Label](/concepts/labels); default is `None` Specify a binary that will be used to run your Java program instead of the normal `bin/java` program included with the JDK. The target must be a `cc_binary`. Any `cc_binary` that implements the [Java Invocation API](http://docs.oracle.com/javase/7/docs/technotes/guides/jni/spec/invocation.html) can be specified as a value for this attribute. By default, Bazel will use the normal JDK launcher (bin/java or java.exe).  The related [`--java_launcher`](/docs/user-manual#flag--java_launcher) Bazel flag affects only those `java_binary` and `java_test` targets that have *not* specified a `launcher` attribute.  Note that your native (C++, SWIG, JNI) dependencies will be built differently depending on whether you are using the JDK launcher or another launcher:   * If you are using the normal JDK launcher (the default), native dependencies are   built as a shared library named `{name}_nativedeps.so`, where   `{name}` is the `name` attribute of this java_binary rule.   Unused code is *not* removed by the linker in this configuration. * If you are using any other launcher, native (C++) dependencies are statically   linked into a binary named `{name}_nativedeps`, where `{name}`   is the `name` attribute of this java_binary rule. In this case,   the linker will remove any code it thinks is unused from the resulting binary,   which means any C++ code accessed only via JNI may not be linked in unless   that `cc_library` target specifies `alwayslink = True`.   When using any launcher other than the default JDK launcher, the format of the `*_deploy.jar` output changes. See the main [java_binary](#java_binary) docs for details. |
+| `deploy_env` | List of [labels](/versions/8.6.0/concepts/labels); default is `[]` A list of other `java_binary` targets which represent the deployment environment for this binary. Set this attribute when building a plugin which will be loaded by another `java_binary`.  Setting this attribute excludes all dependencies from the runtime classpath (and the deploy jar) of this binary that are shared between this binary and the targets specified in `deploy_env`. |
+| `deploy_manifest_lines` | List of strings; default is `[]` A list of lines to add to the `META-INF/manifest.mf` file generated for the `*_deploy.jar` target. The contents of this attribute are *not* subject to ["Make variable"](/versions/8.6.0/reference/be/make-variables) substitution. |
+| `javacopts` | List of strings; default is `[]` Extra compiler options for this binary. Subject to ["Make variable"](/versions/8.6.0/reference/be/make-variables) substitution and [Bourne shell tokenization](/versions/8.6.0/reference/be/common-definitions#sh-tokenization). These compiler options are passed to javac after the global compiler options. |
+| `jvm_flags` | List of strings; default is `[]` A list of flags to embed in the wrapper script generated for running this binary. Subject to [$(location)](/versions/8.6.0/reference/be/make-variables#location) and ["Make variable"](/versions/8.6.0/reference/be/make-variables) substitution, and [Bourne shell tokenization](/versions/8.6.0/reference/be/common-definitions#sh-tokenization). The wrapper script for a Java binary includes a CLASSPATH definition (to find all the dependent jars) and invokes the right Java interpreter. The command line generated by the wrapper script includes the name of the main class followed by a `"$@"` so you can pass along other arguments after the classname. However, arguments intended for parsing by the JVM must be specified *before* the classname on the command line. The contents of `jvm_flags` are added to the wrapper script before the classname is listed.  Note that this attribute has *no effect* on `*_deploy.jar` outputs. |
+| `launcher` | [Label](/versions/8.6.0/concepts/labels); default is `None` Specify a binary that will be used to run your Java program instead of the normal `bin/java` program included with the JDK. The target must be a `cc_binary`. Any `cc_binary` that implements the [Java Invocation API](http://docs.oracle.com/javase/7/docs/technotes/guides/jni/spec/invocation.html) can be specified as a value for this attribute. By default, Bazel will use the normal JDK launcher (bin/java or java.exe).  The related [`--java_launcher`](/versions/8.6.0/docs/user-manual#flag--java_launcher) Bazel flag affects only those `java_binary` and `java_test` targets that have *not* specified a `launcher` attribute.  Note that your native (C++, SWIG, JNI) dependencies will be built differently depending on whether you are using the JDK launcher or another launcher:   * If you are using the normal JDK launcher (the default), native dependencies are   built as a shared library named `{name}_nativedeps.so`, where   `{name}` is the `name` attribute of this java_binary rule.   Unused code is *not* removed by the linker in this configuration. * If you are using any other launcher, native (C++) dependencies are statically   linked into a binary named `{name}_nativedeps`, where `{name}`   is the `name` attribute of this java_binary rule. In this case,   the linker will remove any code it thinks is unused from the resulting binary,   which means any C++ code accessed only via JNI may not be linked in unless   that `cc_library` target specifies `alwayslink = True`.   When using any launcher other than the default JDK launcher, the format of the `*_deploy.jar` output changes. See the main [java_binary](#java_binary) docs for details. |
 | `main_class` | String; default is `""` Name of class with `main()` method to use as entry point. If a rule uses this option, it does not need a `srcs=[...]` list. Thus, with this attribute one can make an executable from a Java library that already contains one or more `main()` methods. The value of this attribute is a class name, not a source file. The class must be available at runtime: it may be compiled by this rule (from `srcs`) or provided by direct or transitive dependencies (through `runtime_deps` or `deps`). If the class is unavailable, the binary will fail at runtime; there is no build-time check. |
 | `neverlink` | Boolean; default is `False` |
-| `plugins` | List of [labels](/concepts/labels); default is `[]` Java compiler plugins to run at compile-time. Every `java_plugin` specified in this attribute will be run whenever this rule is built. A library may also inherit plugins from dependencies that use `exported_plugins`. Resources generated by the plugin will be included in the resulting jar of this rule. |
+| `plugins` | List of [labels](/versions/8.6.0/concepts/labels); default is `[]` Java compiler plugins to run at compile-time. Every `java_plugin` specified in this attribute will be run whenever this rule is built. A library may also inherit plugins from dependencies that use `exported_plugins`. Resources generated by the plugin will be included in the resulting jar of this rule. |
 | `resource_strip_prefix` | String; default is `""` The path prefix to strip from Java resources. If specified, this path prefix is stripped from every file in the `resources` attribute. It is an error for a resource file not to be under this directory. If not specified (the default), the path of resource file is determined according to the same logic as the Java package of source files. For example, a source file at `stuff/java/foo/bar/a.txt` will be located at `foo/bar/a.txt`. |
-| `runtime_deps` | List of [labels](/concepts/labels); default is `[]` Libraries to make available to the final binary or test at runtime only. Like ordinary `deps`, these will appear on the runtime classpath, but unlike them, not on the compile-time classpath. Dependencies needed only at runtime should be listed here. Dependency-analysis tools should ignore targets that appear in both `runtime_deps` and `deps`. |
-| `stamp` | Integer; default is `-1` Whether to encode build information into the binary. Possible values:  * `stamp = 1`: Always stamp the build information into the binary, even in   [`--nostamp`](/docs/user-manual#flag--stamp) builds. **This   setting should be avoided**, since it potentially kills remote caching for the   binary and any downstream actions that depend on it. * `stamp = 0`: Always replace build information by constant values. This   gives good build result caching. * `stamp = -1`: Embedding of build information is controlled by the   [`--[no]stamp`](/docs/user-manual#flag--stamp) flag.   Stamped binaries are *not* rebuilt unless their dependencies change. |
-| `use_launcher` | Boolean; default is `True` Whether the binary should use a custom launcher. If this attribute is set to false, the [launcher](/reference/be/java#java_binary.launcher) attribute and the related [`--java_launcher`](/docs/user-manual#flag--java_launcher) flag will be ignored for this target. |
+| `runtime_deps` | List of [labels](/versions/8.6.0/concepts/labels); default is `[]` Libraries to make available to the final binary or test at runtime only. Like ordinary `deps`, these will appear on the runtime classpath, but unlike them, not on the compile-time classpath. Dependencies needed only at runtime should be listed here. Dependency-analysis tools should ignore targets that appear in both `runtime_deps` and `deps`. |
+| `stamp` | Integer; default is `-1` Whether to encode build information into the binary. Possible values:  * `stamp = 1`: Always stamp the build information into the binary, even in   [`--nostamp`](/versions/8.6.0/docs/user-manual#flag--stamp) builds. **This   setting should be avoided**, since it potentially kills remote caching for the   binary and any downstream actions that depend on it. * `stamp = 0`: Always replace build information by constant values. This   gives good build result caching. * `stamp = -1`: Embedding of build information is controlled by the   [`--[no]stamp`](/versions/8.6.0/docs/user-manual#flag--stamp) flag.   Stamped binaries are *not* rebuilt unless their dependencies change. |
+| `use_launcher` | Boolean; default is `True` Whether the binary should use a custom launcher. If this attribute is set to false, the [launcher](/versions/8.6.0/reference/be/java#java_binary.launcher) attribute and the related [`--java_launcher`](/versions/8.6.0/docs/user-manual#flag--java_launcher) flag will be ignored for this target. |
 | `use_testrunner` | Boolean; default is `False` Use the test runner (by default `com.google.testing.junit.runner.BazelTestRunner`) class as the main entry point for a Java program, and provide the test class to the test runner as a value of `bazel.test_suite` system property.   You can use this to override the default behavior, which is to use test runner for `java_test` rules, and not use it for `java_binary` rules. It is unlikely you will want to do this. One use is for `AllTest` rules that are invoked by another rule (to set up a database before running the tests, for example). The `AllTest` rule must be declared as a `java_binary`, but should still use the test runner as its main entry point. The name of a test runner class can be overridden with `main_class` attribute. |
 
 ## java_import
 
-[View rule sourceopen_in_new](@rules_java//java/bazel/rules/bazel_java_import.bzl)
+[View rule sourceopen_in_new](/versions/8.6.0/reference/be/@rules_java//java/bazel/rules/bazel_java_import.bzl)
 
 ```
 java_import(name, deps, data, add_exports, add_opens, compatible_with, constraints, deprecation, distribs, exec_compatible_with, exec_properties, exports, features, jars, licenses, neverlink, proguard_specs, restricted_to, runtime_deps, srcjar, tags, target_compatible_with, testonly, toolchains, visibility)
@@ -154,22 +154,22 @@ libraries for `java_library` and
 
 | Attributes | |
 | --- | --- |
-| `name` | [Name](/concepts/labels#target-names); required  A unique name for this target. |
-| `deps` | List of [labels](/concepts/labels); default is `[]` The list of other libraries to be linked in to the target. See [java_library.deps](/reference/be/java#java_library.deps). |
-| `data` | List of [labels](/concepts/labels); default is `[]` The list of files needed by this rule at runtime. |
+| `name` | [Name](/versions/8.6.0/concepts/labels#target-names); required  A unique name for this target. |
+| `deps` | List of [labels](/versions/8.6.0/concepts/labels); default is `[]` The list of other libraries to be linked in to the target. See [java_library.deps](/versions/8.6.0/reference/be/java#java_library.deps). |
+| `data` | List of [labels](/versions/8.6.0/concepts/labels); default is `[]` The list of files needed by this rule at runtime. |
 | `add_exports` | List of strings; default is `[]` Allow this library to access the given `module` or `package`. This corresponds to the javac and JVM --add-exports= flags. |
 | `add_opens` | List of strings; default is `[]` Allow this library to reflectively access the given `module` or `package`. This corresponds to the javac and JVM --add-opens= flags. |
 | `constraints` | List of strings; default is `[]` Extra constraints imposed on this rule as a Java library. |
-| `exports` | List of [labels](/concepts/labels); default is `[]` Targets to make available to users of this rule. See [java_library.exports](/reference/be/java#java_library.exports). |
-| `jars` | List of [labels](/concepts/labels); required The list of JAR files provided to Java targets that depend on this target. |
+| `exports` | List of [labels](/versions/8.6.0/concepts/labels); default is `[]` Targets to make available to users of this rule. See [java_library.exports](/versions/8.6.0/reference/be/java#java_library.exports). |
+| `jars` | List of [labels](/versions/8.6.0/concepts/labels); required The list of JAR files provided to Java targets that depend on this target. |
 | `neverlink` | Boolean; default is `False` Only use this library for compilation and not at runtime. Useful if the library will be provided by the runtime environment during execution. Examples of libraries like this are IDE APIs for IDE plug-ins or `tools.jar` for anything running on a standard JDK. |
-| `proguard_specs` | List of [labels](/concepts/labels); default is `[]` Files to be used as Proguard specification. These will describe the set of specifications to be used by Proguard. If specified, they will be added to any `android_binary` target depending on this library. The files included here must only have idempotent rules, namely -dontnote, -dontwarn, assumenosideeffects, and rules that start with -keep. Other options can only appear in `android_binary`'s proguard_specs, to ensure non-tautological merges. |
-| `runtime_deps` | List of [labels](/concepts/labels); default is `[]` Libraries to make available to the final binary or test at runtime only. See [java_library.runtime_deps](/reference/be/java#java_library.runtime_deps). |
-| `srcjar` | [Label](/concepts/labels); default is `None` A JAR file that contains source code for the compiled JAR files. |
+| `proguard_specs` | List of [labels](/versions/8.6.0/concepts/labels); default is `[]` Files to be used as Proguard specification. These will describe the set of specifications to be used by Proguard. If specified, they will be added to any `android_binary` target depending on this library. The files included here must only have idempotent rules, namely -dontnote, -dontwarn, assumenosideeffects, and rules that start with -keep. Other options can only appear in `android_binary`'s proguard_specs, to ensure non-tautological merges. |
+| `runtime_deps` | List of [labels](/versions/8.6.0/concepts/labels); default is `[]` Libraries to make available to the final binary or test at runtime only. See [java_library.runtime_deps](/versions/8.6.0/reference/be/java#java_library.runtime_deps). |
+| `srcjar` | [Label](/versions/8.6.0/concepts/labels); default is `None` A JAR file that contains source code for the compiled JAR files. |
 
 ## java_library
 
-[View rule sourceopen_in_new](@rules_java//java/bazel/rules/bazel_java_library.bzl)
+[View rule sourceopen_in_new](/versions/8.6.0/reference/be/@rules_java//java/bazel/rules/bazel_java_library.bzl)
 
 ```
 java_library(name, deps, srcs, data, resources, add_exports, add_opens, bootclasspath, compatible_with, deprecation, distribs, exec_compatible_with, exec_properties, exported_plugins, exports, features, javabuilder_jvm_flags, javacopts, licenses, neverlink, plugins, proguard_specs, resource_strip_prefix, restricted_to, runtime_deps, tags, target_compatible_with, testonly, toolchains, visibility)
@@ -187,27 +187,27 @@ This rule compiles and links sources into a `.jar` file.
 
 | Attributes | |
 | --- | --- |
-| `name` | [Name](/concepts/labels#target-names); required  A unique name for this target. |
-| `deps` | List of [labels](/concepts/labels); default is `[]` The list of libraries to link into this library. See general comments about `deps` at [Typical attributes defined by most build rules](/reference/be/common-definitions#typical-attributes). The jars built by `java_library` rules listed in `deps` will be on the compile-time classpath of this rule. Furthermore the transitive closure of their `deps`, `runtime_deps` and `exports` will be on the runtime classpath.  By contrast, targets in the `data` attribute are included in the runfiles but on neither the compile-time nor runtime classpath. |
-| `srcs` | List of [labels](/concepts/labels); default is `[]` The list of source files that are processed to create the target. This attribute is almost always required; see exceptions below. Source files of type `.java` are compiled. In case of generated `.java` files it is generally advisable to put the generating rule's name here instead of the name of the file itself. This not only improves readability but makes the rule more resilient to future changes: if the generating rule generates different files in the future, you only need to fix one place: the `outs` of the generating rule. You should not list the generating rule in `deps` because it is a no-op.  Source files of type `.srcjar` are unpacked and compiled. (This is useful if you need to generate a set of `.java` files with a genrule.)  Rules: if the rule (typically `genrule` or `filegroup`) generates any of the files listed above, they will be used the same way as described for source files.  Source files of type `.properties` are treated as resources.  All other files are ignored, as long as there is at least one file of a file type described above. Otherwise an error is raised.  This argument is almost always required, except if you specify the `runtime_deps` argument. |
-| `data` | List of [labels](/concepts/labels); default is `[]` The list of files needed by this library at runtime. See general comments about `data` at [Typical attributes defined by most build rules](/reference/be/common-definitions#typical-attributes). When building a `java_library`, Bazel doesn't put these files anywhere; if the `data` files are generated files then Bazel generates them. When building a test that depends on this `java_library` Bazel copies or links the `data` files into the runfiles area. |
-| `resources` | List of [labels](/concepts/labels); default is `[]` A list of data files to include in a Java jar. Resources may be source files or generated files.  If resources are specified, they will be bundled in the jar along with the usual `.class` files produced by compilation. The location of the resources inside of the jar file is determined by the project structure. Bazel first looks for Maven's [standard directory layout](https://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html), (a "src" directory followed by a "resources" directory grandchild). If that is not found, Bazel then looks for the topmost directory named "java" or "javatests" (so, for example, if a resource is at `<workspace root>/x/java/y/java/z`, the path of the resource will be `y/java/z`. This heuristic cannot be overridden, however, the `resource_strip_prefix` attribute can be used to specify a specific alternative directory for resource files. |
+| `name` | [Name](/versions/8.6.0/concepts/labels#target-names); required  A unique name for this target. |
+| `deps` | List of [labels](/versions/8.6.0/concepts/labels); default is `[]` The list of libraries to link into this library. See general comments about `deps` at [Typical attributes defined by most build rules](/versions/8.6.0/reference/be/common-definitions#typical-attributes). The jars built by `java_library` rules listed in `deps` will be on the compile-time classpath of this rule. Furthermore the transitive closure of their `deps`, `runtime_deps` and `exports` will be on the runtime classpath.  By contrast, targets in the `data` attribute are included in the runfiles but on neither the compile-time nor runtime classpath. |
+| `srcs` | List of [labels](/versions/8.6.0/concepts/labels); default is `[]` The list of source files that are processed to create the target. This attribute is almost always required; see exceptions below. Source files of type `.java` are compiled. In case of generated `.java` files it is generally advisable to put the generating rule's name here instead of the name of the file itself. This not only improves readability but makes the rule more resilient to future changes: if the generating rule generates different files in the future, you only need to fix one place: the `outs` of the generating rule. You should not list the generating rule in `deps` because it is a no-op.  Source files of type `.srcjar` are unpacked and compiled. (This is useful if you need to generate a set of `.java` files with a genrule.)  Rules: if the rule (typically `genrule` or `filegroup`) generates any of the files listed above, they will be used the same way as described for source files.  Source files of type `.properties` are treated as resources.  All other files are ignored, as long as there is at least one file of a file type described above. Otherwise an error is raised.  This argument is almost always required, except if you specify the `runtime_deps` argument. |
+| `data` | List of [labels](/versions/8.6.0/concepts/labels); default is `[]` The list of files needed by this library at runtime. See general comments about `data` at [Typical attributes defined by most build rules](/versions/8.6.0/reference/be/common-definitions#typical-attributes). When building a `java_library`, Bazel doesn't put these files anywhere; if the `data` files are generated files then Bazel generates them. When building a test that depends on this `java_library` Bazel copies or links the `data` files into the runfiles area. |
+| `resources` | List of [labels](/versions/8.6.0/concepts/labels); default is `[]` A list of data files to include in a Java jar. Resources may be source files or generated files.  If resources are specified, they will be bundled in the jar along with the usual `.class` files produced by compilation. The location of the resources inside of the jar file is determined by the project structure. Bazel first looks for Maven's [standard directory layout](https://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html), (a "src" directory followed by a "resources" directory grandchild). If that is not found, Bazel then looks for the topmost directory named "java" or "javatests" (so, for example, if a resource is at `<workspace root>/x/java/y/java/z`, the path of the resource will be `y/java/z`. This heuristic cannot be overridden, however, the `resource_strip_prefix` attribute can be used to specify a specific alternative directory for resource files. |
 | `add_exports` | List of strings; default is `[]` Allow this library to access the given `module` or `package`. This corresponds to the javac and JVM --add-exports= flags. |
 | `add_opens` | List of strings; default is `[]` Allow this library to reflectively access the given `module` or `package`. This corresponds to the javac and JVM --add-opens= flags. |
-| `bootclasspath` | [Label](/concepts/labels); default is `None` Restricted API, do not use! |
-| `exported_plugins` | List of [labels](/concepts/labels); default is `[]` The list of `java_plugin`s (e.g. annotation processors) to export to libraries that directly depend on this library. The specified list of `java_plugin`s will be applied to any library which directly depends on this library, just as if that library had explicitly declared these labels in `plugins`. |
-| `exports` | List of [labels](/concepts/labels); default is `[]` Exported libraries. Listing rules here will make them available to parent rules, as if the parents explicitly depended on these rules. This is not true for regular (non-exported) `deps`.  Summary: a rule *X* can access the code in *Y* if there exists a dependency path between them that begins with a `deps` edge followed by zero or more `exports` edges. Let's see some examples to illustrate this.  Assume *A* depends on *B* and *B* depends on *C*. In this case C is a *transitive* dependency of A, so changing C's sources and rebuilding A will correctly rebuild everything. However A will not be able to use classes in C. To allow that, either A has to declare C in its `deps`, or B can make it easier for A (and anything that may depend on A) by declaring C in its (B's) `exports` attribute.  The closure of exported libraries is available to all direct parent rules. Take a slightly different example: A depends on B, B depends on C and D, and also exports C but not D. Now A has access to C but not to D. Now, if C and D exported some libraries, C' and D' respectively, A could only access C' but not D'.  Important: an exported rule is not a regular dependency. Sticking to the previous example, if B exports C and wants to also use C, it has to also list it in its own `deps`. |
+| `bootclasspath` | [Label](/versions/8.6.0/concepts/labels); default is `None` Restricted API, do not use! |
+| `exported_plugins` | List of [labels](/versions/8.6.0/concepts/labels); default is `[]` The list of `java_plugin`s (e.g. annotation processors) to export to libraries that directly depend on this library. The specified list of `java_plugin`s will be applied to any library which directly depends on this library, just as if that library had explicitly declared these labels in `plugins`. |
+| `exports` | List of [labels](/versions/8.6.0/concepts/labels); default is `[]` Exported libraries. Listing rules here will make them available to parent rules, as if the parents explicitly depended on these rules. This is not true for regular (non-exported) `deps`.  Summary: a rule *X* can access the code in *Y* if there exists a dependency path between them that begins with a `deps` edge followed by zero or more `exports` edges. Let's see some examples to illustrate this.  Assume *A* depends on *B* and *B* depends on *C*. In this case C is a *transitive* dependency of A, so changing C's sources and rebuilding A will correctly rebuild everything. However A will not be able to use classes in C. To allow that, either A has to declare C in its `deps`, or B can make it easier for A (and anything that may depend on A) by declaring C in its (B's) `exports` attribute.  The closure of exported libraries is available to all direct parent rules. Take a slightly different example: A depends on B, B depends on C and D, and also exports C but not D. Now A has access to C but not to D. Now, if C and D exported some libraries, C' and D' respectively, A could only access C' but not D'.  Important: an exported rule is not a regular dependency. Sticking to the previous example, if B exports C and wants to also use C, it has to also list it in its own `deps`. |
 | `javabuilder_jvm_flags` | List of strings; default is `[]` Restricted API, do not use! |
-| `javacopts` | List of strings; default is `[]` Extra compiler options for this library. Subject to ["Make variable"](make-variables) substitution and [Bourne shell tokenization](common-definitions#sh-tokenization). These compiler options are passed to javac after the global compiler options. |
+| `javacopts` | List of strings; default is `[]` Extra compiler options for this library. Subject to ["Make variable"](/versions/8.6.0/reference/be/make-variables) substitution and [Bourne shell tokenization](/versions/8.6.0/reference/be/common-definitions#sh-tokenization). These compiler options are passed to javac after the global compiler options. |
 | `neverlink` | Boolean; default is `False` Whether this library should only be used for compilation and not at runtime. Useful if the library will be provided by the runtime environment during execution. Examples of such libraries are the IDE APIs for IDE plug-ins or `tools.jar` for anything running on a standard JDK. Note that `neverlink = True` does not prevent the compiler from inlining material from this library into compilation targets that depend on it, as permitted by the Java Language Specification (e.g., `static final` constants of `String` or of primitive types). The preferred use case is therefore when the runtime library is identical to the compilation library.  If the runtime library differs from the compilation library then you must ensure that it differs only in places that the JLS forbids compilers to inline (and that must hold for all future versions of the JLS). |
-| `plugins` | List of [labels](/concepts/labels); default is `[]` Java compiler plugins to run at compile-time. Every `java_plugin` specified in this attribute will be run whenever this rule is built. A library may also inherit plugins from dependencies that use `exported_plugins`. Resources generated by the plugin will be included in the resulting jar of this rule. |
-| `proguard_specs` | List of [labels](/concepts/labels); default is `[]` Files to be used as Proguard specification. These will describe the set of specifications to be used by Proguard. If specified, they will be added to any `android_binary` target depending on this library. The files included here must only have idempotent rules, namely -dontnote, -dontwarn, assumenosideeffects, and rules that start with -keep. Other options can only appear in `android_binary`'s proguard_specs, to ensure non-tautological merges. |
+| `plugins` | List of [labels](/versions/8.6.0/concepts/labels); default is `[]` Java compiler plugins to run at compile-time. Every `java_plugin` specified in this attribute will be run whenever this rule is built. A library may also inherit plugins from dependencies that use `exported_plugins`. Resources generated by the plugin will be included in the resulting jar of this rule. |
+| `proguard_specs` | List of [labels](/versions/8.6.0/concepts/labels); default is `[]` Files to be used as Proguard specification. These will describe the set of specifications to be used by Proguard. If specified, they will be added to any `android_binary` target depending on this library. The files included here must only have idempotent rules, namely -dontnote, -dontwarn, assumenosideeffects, and rules that start with -keep. Other options can only appear in `android_binary`'s proguard_specs, to ensure non-tautological merges. |
 | `resource_strip_prefix` | String; default is `""` The path prefix to strip from Java resources. If specified, this path prefix is stripped from every file in the `resources` attribute. It is an error for a resource file not to be under this directory. If not specified (the default), the path of resource file is determined according to the same logic as the Java package of source files. For example, a source file at `stuff/java/foo/bar/a.txt` will be located at `foo/bar/a.txt`. |
-| `runtime_deps` | List of [labels](/concepts/labels); default is `[]` Libraries to make available to the final binary or test at runtime only. Like ordinary `deps`, these will appear on the runtime classpath, but unlike them, not on the compile-time classpath. Dependencies needed only at runtime should be listed here. Dependency-analysis tools should ignore targets that appear in both `runtime_deps` and `deps`. |
+| `runtime_deps` | List of [labels](/versions/8.6.0/concepts/labels); default is `[]` Libraries to make available to the final binary or test at runtime only. Like ordinary `deps`, these will appear on the runtime classpath, but unlike them, not on the compile-time classpath. Dependencies needed only at runtime should be listed here. Dependency-analysis tools should ignore targets that appear in both `runtime_deps` and `deps`. |
 
 ## java_test
 
-[View rule sourceopen_in_new](@rules_java//java/bazel/rules/bazel_java_test.bzl)
+[View rule sourceopen_in_new](/versions/8.6.0/reference/be/@rules_java//java/bazel/rules/bazel_java_test.bzl)
 
 ```
 java_test(name, deps, srcs, data, resources, add_exports, add_opens, args, bootclasspath, classpath_resources, compatible_with, create_executable, deploy_manifest_lines, deprecation, distribs, env, env_inherit, exec_compatible_with, exec_properties, features, flaky, javacopts, jvm_flags, launcher, licenses, local, main_class, neverlink, plugins, resource_strip_prefix, restricted_to, runtime_deps, shard_count, size, stamp, tags, target_compatible_with, test_class, testonly, timeout, toolchains, use_launcher, use_testrunner, visibility)
@@ -225,8 +225,7 @@ test code. The test runner's main method is invoked instead of the main class be
   [java_binary](#java_binary) for more details.
 
 See the section on `java_binary()` arguments. This rule also
-supports all [attributes common
-to all test rules (\*\_test)](https://bazel.build/reference/be/common-definitions#common-attributes-tests).
+supports all [attributes common to all test rules (\*\_test)](https://bazel.build/versions/8.6.0/reference/be/common-definitions#common-attributes-tests).
 
 #### Examples
 
@@ -254,33 +253,33 @@ java_test(
 
 | Attributes | |
 | --- | --- |
-| `name` | [Name](/concepts/labels#target-names); required  A unique name for this target. |
-| `deps` | List of [labels](/concepts/labels); default is `[]` The list of other libraries to be linked in to the target. See general comments about `deps` at [Typical attributes defined by most build rules](common-definitions#typical-attributes). |
-| `srcs` | List of [labels](/concepts/labels); default is `[]` The list of source files that are processed to create the target. This attribute is almost always required; see exceptions below. Source files of type `.java` are compiled. In case of generated `.java` files it is generally advisable to put the generating rule's name here instead of the name of the file itself. This not only improves readability but makes the rule more resilient to future changes: if the generating rule generates different files in the future, you only need to fix one place: the `outs` of the generating rule. You should not list the generating rule in `deps` because it is a no-op.  Source files of type `.srcjar` are unpacked and compiled. (This is useful if you need to generate a set of `.java` files with a genrule.)  Rules: if the rule (typically `genrule` or `filegroup`) generates any of the files listed above, they will be used the same way as described for source files.  This argument is almost always required, except if a [`main_class`](#java_binary.main_class) attribute specifies a class on the runtime classpath or you specify the `runtime_deps` argument. |
-| `data` | List of [labels](/concepts/labels); default is `[]` The list of files needed by this library at runtime. See general comments about `data` at [Typical attributes defined by most build rules](/reference/be/common-definitions#typical-attributes). |
-| `resources` | List of [labels](/concepts/labels); default is `[]` A list of data files to include in a Java jar. Resources may be source files or generated files.  If resources are specified, they will be bundled in the jar along with the usual `.class` files produced by compilation. The location of the resources inside of the jar file is determined by the project structure. Bazel first looks for Maven's [standard directory layout](https://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html), (a "src" directory followed by a "resources" directory grandchild). If that is not found, Bazel then looks for the topmost directory named "java" or "javatests" (so, for example, if a resource is at `<workspace root>/x/java/y/java/z`, the path of the resource will be `y/java/z`. This heuristic cannot be overridden, however, the `resource_strip_prefix` attribute can be used to specify a specific alternative directory for resource files. |
+| `name` | [Name](/versions/8.6.0/concepts/labels#target-names); required  A unique name for this target. |
+| `deps` | List of [labels](/versions/8.6.0/concepts/labels); default is `[]` The list of other libraries to be linked in to the target. See general comments about `deps` at [Typical attributes defined by most build rules](/versions/8.6.0/reference/be/common-definitions#typical-attributes). |
+| `srcs` | List of [labels](/versions/8.6.0/concepts/labels); default is `[]` The list of source files that are processed to create the target. This attribute is almost always required; see exceptions below. Source files of type `.java` are compiled. In case of generated `.java` files it is generally advisable to put the generating rule's name here instead of the name of the file itself. This not only improves readability but makes the rule more resilient to future changes: if the generating rule generates different files in the future, you only need to fix one place: the `outs` of the generating rule. You should not list the generating rule in `deps` because it is a no-op.  Source files of type `.srcjar` are unpacked and compiled. (This is useful if you need to generate a set of `.java` files with a genrule.)  Rules: if the rule (typically `genrule` or `filegroup`) generates any of the files listed above, they will be used the same way as described for source files.  This argument is almost always required, except if a [`main_class`](#java_binary.main_class) attribute specifies a class on the runtime classpath or you specify the `runtime_deps` argument. |
+| `data` | List of [labels](/versions/8.6.0/concepts/labels); default is `[]` The list of files needed by this library at runtime. See general comments about `data` at [Typical attributes defined by most build rules](/versions/8.6.0/reference/be/common-definitions#typical-attributes). |
+| `resources` | List of [labels](/versions/8.6.0/concepts/labels); default is `[]` A list of data files to include in a Java jar. Resources may be source files or generated files.  If resources are specified, they will be bundled in the jar along with the usual `.class` files produced by compilation. The location of the resources inside of the jar file is determined by the project structure. Bazel first looks for Maven's [standard directory layout](https://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html), (a "src" directory followed by a "resources" directory grandchild). If that is not found, Bazel then looks for the topmost directory named "java" or "javatests" (so, for example, if a resource is at `<workspace root>/x/java/y/java/z`, the path of the resource will be `y/java/z`. This heuristic cannot be overridden, however, the `resource_strip_prefix` attribute can be used to specify a specific alternative directory for resource files. |
 | `add_exports` | List of strings; default is `[]` Allow this library to access the given `module` or `package`. This corresponds to the javac and JVM --add-exports= flags. |
 | `add_opens` | List of strings; default is `[]` Allow this library to reflectively access the given `module` or `package`. This corresponds to the javac and JVM --add-opens= flags. |
-| `bootclasspath` | [Label](/concepts/labels); default is `None` Restricted API, do not use! |
-| `classpath_resources` | List of [labels](/concepts/labels); default is `[]` *DO NOT USE THIS OPTION UNLESS THERE IS NO OTHER WAY)* A list of resources that must be located at the root of the java tree. This attribute's only purpose is to support third-party libraries that require that their resources be found on the classpath as exactly `"myconfig.xml"`. It is only allowed on binaries and not libraries, due to the danger of namespace conflicts. |
+| `bootclasspath` | [Label](/versions/8.6.0/concepts/labels); default is `None` Restricted API, do not use! |
+| `classpath_resources` | List of [labels](/versions/8.6.0/concepts/labels); default is `[]` *DO NOT USE THIS OPTION UNLESS THERE IS NO OTHER WAY)* A list of resources that must be located at the root of the java tree. This attribute's only purpose is to support third-party libraries that require that their resources be found on the classpath as exactly `"myconfig.xml"`. It is only allowed on binaries and not libraries, due to the danger of namespace conflicts. |
 | `create_executable` | Boolean; default is `True` Deprecated, use `java_single_jar` instead. |
-| `deploy_manifest_lines` | List of strings; default is `[]` A list of lines to add to the `META-INF/manifest.mf` file generated for the `*_deploy.jar` target. The contents of this attribute are *not* subject to ["Make variable"](make-variables) substitution. |
-| `javacopts` | List of strings; default is `[]` Extra compiler options for this binary. Subject to ["Make variable"](make-variables) substitution and [Bourne shell tokenization](common-definitions#sh-tokenization). These compiler options are passed to javac after the global compiler options. |
-| `jvm_flags` | List of strings; default is `[]` A list of flags to embed in the wrapper script generated for running this binary. Subject to [$(location)](/reference/be/make-variables#location) and ["Make variable"](make-variables) substitution, and [Bourne shell tokenization](common-definitions#sh-tokenization). The wrapper script for a Java binary includes a CLASSPATH definition (to find all the dependent jars) and invokes the right Java interpreter. The command line generated by the wrapper script includes the name of the main class followed by a `"$@"` so you can pass along other arguments after the classname. However, arguments intended for parsing by the JVM must be specified *before* the classname on the command line. The contents of `jvm_flags` are added to the wrapper script before the classname is listed.  Note that this attribute has *no effect* on `*_deploy.jar` outputs. |
-| `launcher` | [Label](/concepts/labels); default is `None` Specify a binary that will be used to run your Java program instead of the normal `bin/java` program included with the JDK. The target must be a `cc_binary`. Any `cc_binary` that implements the [Java Invocation API](http://docs.oracle.com/javase/7/docs/technotes/guides/jni/spec/invocation.html) can be specified as a value for this attribute. By default, Bazel will use the normal JDK launcher (bin/java or java.exe).  The related [`--java_launcher`](/docs/user-manual#flag--java_launcher) Bazel flag affects only those `java_binary` and `java_test` targets that have *not* specified a `launcher` attribute.  Note that your native (C++, SWIG, JNI) dependencies will be built differently depending on whether you are using the JDK launcher or another launcher:   * If you are using the normal JDK launcher (the default), native dependencies are   built as a shared library named `{name}_nativedeps.so`, where   `{name}` is the `name` attribute of this java_binary rule.   Unused code is *not* removed by the linker in this configuration. * If you are using any other launcher, native (C++) dependencies are statically   linked into a binary named `{name}_nativedeps`, where `{name}`   is the `name` attribute of this java_binary rule. In this case,   the linker will remove any code it thinks is unused from the resulting binary,   which means any C++ code accessed only via JNI may not be linked in unless   that `cc_library` target specifies `alwayslink = True`.   When using any launcher other than the default JDK launcher, the format of the `*_deploy.jar` output changes. See the main [java_binary](#java_binary) docs for details. |
+| `deploy_manifest_lines` | List of strings; default is `[]` A list of lines to add to the `META-INF/manifest.mf` file generated for the `*_deploy.jar` target. The contents of this attribute are *not* subject to ["Make variable"](/versions/8.6.0/reference/be/make-variables) substitution. |
+| `javacopts` | List of strings; default is `[]` Extra compiler options for this binary. Subject to ["Make variable"](/versions/8.6.0/reference/be/make-variables) substitution and [Bourne shell tokenization](/versions/8.6.0/reference/be/common-definitions#sh-tokenization). These compiler options are passed to javac after the global compiler options. |
+| `jvm_flags` | List of strings; default is `[]` A list of flags to embed in the wrapper script generated for running this binary. Subject to [$(location)](/versions/8.6.0/reference/be/make-variables#location) and ["Make variable"](/versions/8.6.0/reference/be/make-variables) substitution, and [Bourne shell tokenization](/versions/8.6.0/reference/be/common-definitions#sh-tokenization). The wrapper script for a Java binary includes a CLASSPATH definition (to find all the dependent jars) and invokes the right Java interpreter. The command line generated by the wrapper script includes the name of the main class followed by a `"$@"` so you can pass along other arguments after the classname. However, arguments intended for parsing by the JVM must be specified *before* the classname on the command line. The contents of `jvm_flags` are added to the wrapper script before the classname is listed.  Note that this attribute has *no effect* on `*_deploy.jar` outputs. |
+| `launcher` | [Label](/versions/8.6.0/concepts/labels); default is `None` Specify a binary that will be used to run your Java program instead of the normal `bin/java` program included with the JDK. The target must be a `cc_binary`. Any `cc_binary` that implements the [Java Invocation API](http://docs.oracle.com/javase/7/docs/technotes/guides/jni/spec/invocation.html) can be specified as a value for this attribute. By default, Bazel will use the normal JDK launcher (bin/java or java.exe).  The related [`--java_launcher`](/versions/8.6.0/docs/user-manual#flag--java_launcher) Bazel flag affects only those `java_binary` and `java_test` targets that have *not* specified a `launcher` attribute.  Note that your native (C++, SWIG, JNI) dependencies will be built differently depending on whether you are using the JDK launcher or another launcher:   * If you are using the normal JDK launcher (the default), native dependencies are   built as a shared library named `{name}_nativedeps.so`, where   `{name}` is the `name` attribute of this java_binary rule.   Unused code is *not* removed by the linker in this configuration. * If you are using any other launcher, native (C++) dependencies are statically   linked into a binary named `{name}_nativedeps`, where `{name}`   is the `name` attribute of this java_binary rule. In this case,   the linker will remove any code it thinks is unused from the resulting binary,   which means any C++ code accessed only via JNI may not be linked in unless   that `cc_library` target specifies `alwayslink = True`.   When using any launcher other than the default JDK launcher, the format of the `*_deploy.jar` output changes. See the main [java_binary](#java_binary) docs for details. |
 | `main_class` | String; default is `""` Name of class with `main()` method to use as entry point. If a rule uses this option, it does not need a `srcs=[...]` list. Thus, with this attribute one can make an executable from a Java library that already contains one or more `main()` methods. The value of this attribute is a class name, not a source file. The class must be available at runtime: it may be compiled by this rule (from `srcs`) or provided by direct or transitive dependencies (through `runtime_deps` or `deps`). If the class is unavailable, the binary will fail at runtime; there is no build-time check. |
 | `neverlink` | Boolean; default is `False` |
-| `plugins` | List of [labels](/concepts/labels); default is `[]` Java compiler plugins to run at compile-time. Every `java_plugin` specified in this attribute will be run whenever this rule is built. A library may also inherit plugins from dependencies that use `exported_plugins`. Resources generated by the plugin will be included in the resulting jar of this rule. |
+| `plugins` | List of [labels](/versions/8.6.0/concepts/labels); default is `[]` Java compiler plugins to run at compile-time. Every `java_plugin` specified in this attribute will be run whenever this rule is built. A library may also inherit plugins from dependencies that use `exported_plugins`. Resources generated by the plugin will be included in the resulting jar of this rule. |
 | `resource_strip_prefix` | String; default is `""` The path prefix to strip from Java resources. If specified, this path prefix is stripped from every file in the `resources` attribute. It is an error for a resource file not to be under this directory. If not specified (the default), the path of resource file is determined according to the same logic as the Java package of source files. For example, a source file at `stuff/java/foo/bar/a.txt` will be located at `foo/bar/a.txt`. |
-| `runtime_deps` | List of [labels](/concepts/labels); default is `[]` Libraries to make available to the final binary or test at runtime only. Like ordinary `deps`, these will appear on the runtime classpath, but unlike them, not on the compile-time classpath. Dependencies needed only at runtime should be listed here. Dependency-analysis tools should ignore targets that appear in both `runtime_deps` and `deps`. |
-| `stamp` | Integer; default is `0` Whether to encode build information into the binary. Possible values:  * `stamp = 1`: Always stamp the build information into the binary, even in   [`--nostamp`](https://bazel.build/docs/user-manual#stamp) builds. **This   setting should be avoided**, since it potentially kills remote caching for the   binary and any downstream actions that depend on it. * `stamp = 0`: Always replace build information by constant values. This   gives good build result caching. * `stamp = -1`: Embedding of build information is controlled by the   [`--[no]stamp`](https://bazel.build/docs/user-manual#stamp) flag.   Stamped binaries are *not* rebuilt unless their dependencies change. |
+| `runtime_deps` | List of [labels](/versions/8.6.0/concepts/labels); default is `[]` Libraries to make available to the final binary or test at runtime only. Like ordinary `deps`, these will appear on the runtime classpath, but unlike them, not on the compile-time classpath. Dependencies needed only at runtime should be listed here. Dependency-analysis tools should ignore targets that appear in both `runtime_deps` and `deps`. |
+| `stamp` | Integer; default is `0` Whether to encode build information into the binary. Possible values:  * `stamp = 1`: Always stamp the build information into the binary, even in   [`--nostamp`](https://bazel.build/versions/8.6.0/docs/user-manual#stamp) builds. **This   setting should be avoided**, since it potentially kills remote caching for the   binary and any downstream actions that depend on it. * `stamp = 0`: Always replace build information by constant values. This   gives good build result caching. * `stamp = -1`: Embedding of build information is controlled by the   [`--[no]stamp`](https://bazel.build/versions/8.6.0/docs/user-manual#stamp) flag.   Stamped binaries are *not* rebuilt unless their dependencies change. |
 | `test_class` | String; default is `""` The Java class to be loaded by the test runner.  By default, if this argument is not defined then the legacy mode is used and the test arguments are used instead. Set the `--nolegacy_bazel_java_test` flag to not fallback on the first argument.  This attribute specifies the name of a Java class to be run by this test. It is rare to need to set this. If this argument is omitted, it will be inferred using the target's `name` and its source-root-relative path. If the test is located outside a known source root, Bazel will report an error if `test_class` is unset.  For JUnit3, the test class needs to either be a subclass of `junit.framework.TestCase` or it needs to have a public static `suite()` method that returns a `junit.framework.Test` (or a subclass of `Test`).  This attribute allows several `java_test` rules to share the same `Test` (`TestCase`, `TestSuite`, ...). Typically additional information is passed to it (e.g. via `jvm_flags=['-Dkey=value']`) so that its behavior differs in each case, such as running a different subset of the tests. This attribute also enables the use of Java tests outside the `javatests` tree. |
-| `use_launcher` | Boolean; default is `True` Whether the binary should use a custom launcher. If this attribute is set to false, the [launcher](/reference/be/java#java_binary.launcher) attribute and the related [`--java_launcher`](/docs/user-manual#flag--java_launcher) flag will be ignored for this target. |
+| `use_launcher` | Boolean; default is `True` Whether the binary should use a custom launcher. If this attribute is set to false, the [launcher](/versions/8.6.0/reference/be/java#java_binary.launcher) attribute and the related [`--java_launcher`](/versions/8.6.0/docs/user-manual#flag--java_launcher) flag will be ignored for this target. |
 | `use_testrunner` | Boolean; default is `True` Use the test runner (by default `com.google.testing.junit.runner.BazelTestRunner`) class as the main entry point for a Java program, and provide the test class to the test runner as a value of `bazel.test_suite` system property.   You can use this to override the default behavior, which is to use test runner for `java_test` rules, and not use it for `java_binary` rules. It is unlikely you will want to do this. One use is for `AllTest` rules that are invoked by another rule (to set up a database before running the tests, for example). The `AllTest` rule must be declared as a `java_binary`, but should still use the test runner as its main entry point. The name of a test runner class can be overridden with `main_class` attribute. |
 
 ## java_package_configuration
 
-[View rule sourceopen_in_new](@rules_java//java/common/rules/java_package_configuration.bzl)
+[View rule sourceopen_in_new](/versions/8.6.0/reference/be/@rules_java//java/common/rules/java_package_configuration.bzl)
 
 ```
 java_package_configuration(name, data, compatible_with, deprecation, distribs, exec_compatible_with, exec_properties, features, javacopts, output_licenses, packages, restricted_to, system, tags, target_compatible_with, testonly, toolchains, visibility)
@@ -319,16 +318,16 @@ java_toolchain(
 
 | Attributes | |
 | --- | --- |
-| `name` | [Name](/concepts/labels#target-names); required  A unique name for this target. |
-| `data` | List of [labels](/concepts/labels); default is `[]` The list of files needed by this configuration at runtime. |
+| `name` | [Name](/versions/8.6.0/concepts/labels#target-names); required  A unique name for this target. |
+| `data` | List of [labels](/versions/8.6.0/concepts/labels); default is `[]` The list of files needed by this configuration at runtime. |
 | `javacopts` | List of strings; default is `[]` Java compiler flags. |
 | `output_licenses` | List of strings; default is `[]` |
-| `packages` | List of [labels](/concepts/labels); default is `[]` The set of `package_group`s the configuration should be applied to. |
-| `system` | [Label](/concepts/labels); default is `None` Corresponds to javac's --system flag. |
+| `packages` | List of [labels](/versions/8.6.0/concepts/labels); default is `[]` The set of `package_group`s the configuration should be applied to. |
+| `system` | [Label](/versions/8.6.0/concepts/labels); default is `None` Corresponds to javac's --system flag. |
 
 ## java_plugin
 
-[View rule sourceopen_in_new](@rules_java//java/bazel/rules/bazel_java_plugin.bzl)
+[View rule sourceopen_in_new](/versions/8.6.0/reference/be/@rules_java//java/bazel/rules/bazel_java_plugin.bzl)
 
 ```
 java_plugin(name, deps, srcs, data, resources, add_exports, add_opens, bootclasspath, compatible_with, deprecation, distribs, exec_compatible_with, exec_properties, features, generates_api, javabuilder_jvm_flags, javacopts, licenses, neverlink, output_licenses, plugins, processor_class, proguard_specs, resource_strip_prefix, restricted_to, tags, target_compatible_with, testonly, toolchains, visibility)
@@ -346,7 +345,7 @@ directly depend on it using
 * `libname.jar`: A Java archive.
 
 Arguments are a subset of (and with identical semantics to) those of
-[java_library()](/reference/be/java#java_library),
+[java_library()](/versions/8.6.0/reference/be/java#java_library),
 except for the addition of the `processor_class` and
 `generates_api` arguments.
 
@@ -354,27 +353,27 @@ except for the addition of the `processor_class` and
 
 | Attributes | |
 | --- | --- |
-| `name` | [Name](/concepts/labels#target-names); required  A unique name for this target. |
-| `deps` | List of [labels](/concepts/labels); default is `[]` The list of libraries to link into this library. See general comments about `deps` at [Typical attributes defined by most build rules](/reference/be/common-definitions#typical-attributes). The jars built by `java_library` rules listed in `deps` will be on the compile-time classpath of this rule. Furthermore the transitive closure of their `deps`, `runtime_deps` and `exports` will be on the runtime classpath.  By contrast, targets in the `data` attribute are included in the runfiles but on neither the compile-time nor runtime classpath. |
-| `srcs` | List of [labels](/concepts/labels); default is `[]` The list of source files that are processed to create the target. This attribute is almost always required; see exceptions below. Source files of type `.java` are compiled. In case of generated `.java` files it is generally advisable to put the generating rule's name here instead of the name of the file itself. This not only improves readability but makes the rule more resilient to future changes: if the generating rule generates different files in the future, you only need to fix one place: the `outs` of the generating rule. You should not list the generating rule in `deps` because it is a no-op.  Source files of type `.srcjar` are unpacked and compiled. (This is useful if you need to generate a set of `.java` files with a genrule.)  Rules: if the rule (typically `genrule` or `filegroup`) generates any of the files listed above, they will be used the same way as described for source files.  Source files of type `.properties` are treated as resources.  All other files are ignored, as long as there is at least one file of a file type described above. Otherwise an error is raised.  This argument is almost always required, except if you specify the `runtime_deps` argument. |
-| `data` | List of [labels](/concepts/labels); default is `[]` The list of files needed by this library at runtime. See general comments about `data` at [Typical attributes defined by most build rules](/reference/be/common-definitions#typical-attributes). When building a `java_library`, Bazel doesn't put these files anywhere; if the `data` files are generated files then Bazel generates them. When building a test that depends on this `java_library` Bazel copies or links the `data` files into the runfiles area. |
-| `resources` | List of [labels](/concepts/labels); default is `[]` A list of data files to include in a Java jar. Resources may be source files or generated files.  If resources are specified, they will be bundled in the jar along with the usual `.class` files produced by compilation. The location of the resources inside of the jar file is determined by the project structure. Bazel first looks for Maven's [standard directory layout](https://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html), (a "src" directory followed by a "resources" directory grandchild). If that is not found, Bazel then looks for the topmost directory named "java" or "javatests" (so, for example, if a resource is at `<workspace root>/x/java/y/java/z`, the path of the resource will be `y/java/z`. This heuristic cannot be overridden, however, the `resource_strip_prefix` attribute can be used to specify a specific alternative directory for resource files. |
+| `name` | [Name](/versions/8.6.0/concepts/labels#target-names); required  A unique name for this target. |
+| `deps` | List of [labels](/versions/8.6.0/concepts/labels); default is `[]` The list of libraries to link into this library. See general comments about `deps` at [Typical attributes defined by most build rules](/versions/8.6.0/reference/be/common-definitions#typical-attributes). The jars built by `java_library` rules listed in `deps` will be on the compile-time classpath of this rule. Furthermore the transitive closure of their `deps`, `runtime_deps` and `exports` will be on the runtime classpath.  By contrast, targets in the `data` attribute are included in the runfiles but on neither the compile-time nor runtime classpath. |
+| `srcs` | List of [labels](/versions/8.6.0/concepts/labels); default is `[]` The list of source files that are processed to create the target. This attribute is almost always required; see exceptions below. Source files of type `.java` are compiled. In case of generated `.java` files it is generally advisable to put the generating rule's name here instead of the name of the file itself. This not only improves readability but makes the rule more resilient to future changes: if the generating rule generates different files in the future, you only need to fix one place: the `outs` of the generating rule. You should not list the generating rule in `deps` because it is a no-op.  Source files of type `.srcjar` are unpacked and compiled. (This is useful if you need to generate a set of `.java` files with a genrule.)  Rules: if the rule (typically `genrule` or `filegroup`) generates any of the files listed above, they will be used the same way as described for source files.  Source files of type `.properties` are treated as resources.  All other files are ignored, as long as there is at least one file of a file type described above. Otherwise an error is raised.  This argument is almost always required, except if you specify the `runtime_deps` argument. |
+| `data` | List of [labels](/versions/8.6.0/concepts/labels); default is `[]` The list of files needed by this library at runtime. See general comments about `data` at [Typical attributes defined by most build rules](/versions/8.6.0/reference/be/common-definitions#typical-attributes). When building a `java_library`, Bazel doesn't put these files anywhere; if the `data` files are generated files then Bazel generates them. When building a test that depends on this `java_library` Bazel copies or links the `data` files into the runfiles area. |
+| `resources` | List of [labels](/versions/8.6.0/concepts/labels); default is `[]` A list of data files to include in a Java jar. Resources may be source files or generated files.  If resources are specified, they will be bundled in the jar along with the usual `.class` files produced by compilation. The location of the resources inside of the jar file is determined by the project structure. Bazel first looks for Maven's [standard directory layout](https://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html), (a "src" directory followed by a "resources" directory grandchild). If that is not found, Bazel then looks for the topmost directory named "java" or "javatests" (so, for example, if a resource is at `<workspace root>/x/java/y/java/z`, the path of the resource will be `y/java/z`. This heuristic cannot be overridden, however, the `resource_strip_prefix` attribute can be used to specify a specific alternative directory for resource files. |
 | `add_exports` | List of strings; default is `[]` Allow this library to access the given `module` or `package`. This corresponds to the javac and JVM --add-exports= flags. |
 | `add_opens` | List of strings; default is `[]` Allow this library to reflectively access the given `module` or `package`. This corresponds to the javac and JVM --add-opens= flags. |
-| `bootclasspath` | [Label](/concepts/labels); default is `None` Restricted API, do not use! |
+| `bootclasspath` | [Label](/versions/8.6.0/concepts/labels); default is `None` Restricted API, do not use! |
 | `generates_api` | Boolean; default is `False` This attribute marks annotation processors that generate API code. If a rule uses an API-generating annotation processor, other rules depending on it can refer to the generated code only if their compilation actions are scheduled after the generating rule. This attribute instructs Bazel to introduce scheduling constraints when --java_header_compilation is enabled. *WARNING: This attribute affects build performance, use it only if necessary.* |
 | `javabuilder_jvm_flags` | List of strings; default is `[]` Restricted API, do not use! |
-| `javacopts` | List of strings; default is `[]` Extra compiler options for this library. Subject to ["Make variable"](make-variables) substitution and [Bourne shell tokenization](common-definitions#sh-tokenization). These compiler options are passed to javac after the global compiler options. |
+| `javacopts` | List of strings; default is `[]` Extra compiler options for this library. Subject to ["Make variable"](/versions/8.6.0/reference/be/make-variables) substitution and [Bourne shell tokenization](/versions/8.6.0/reference/be/common-definitions#sh-tokenization). These compiler options are passed to javac after the global compiler options. |
 | `neverlink` | Boolean; default is `False` Whether this library should only be used for compilation and not at runtime. Useful if the library will be provided by the runtime environment during execution. Examples of such libraries are the IDE APIs for IDE plug-ins or `tools.jar` for anything running on a standard JDK. Note that `neverlink = True` does not prevent the compiler from inlining material from this library into compilation targets that depend on it, as permitted by the Java Language Specification (e.g., `static final` constants of `String` or of primitive types). The preferred use case is therefore when the runtime library is identical to the compilation library.  If the runtime library differs from the compilation library then you must ensure that it differs only in places that the JLS forbids compilers to inline (and that must hold for all future versions of the JLS). |
 | `output_licenses` | List of strings; default is `[]` |
-| `plugins` | List of [labels](/concepts/labels); default is `[]` Java compiler plugins to run at compile-time. Every `java_plugin` specified in this attribute will be run whenever this rule is built. A library may also inherit plugins from dependencies that use `exported_plugins`. Resources generated by the plugin will be included in the resulting jar of this rule. |
+| `plugins` | List of [labels](/versions/8.6.0/concepts/labels); default is `[]` Java compiler plugins to run at compile-time. Every `java_plugin` specified in this attribute will be run whenever this rule is built. A library may also inherit plugins from dependencies that use `exported_plugins`. Resources generated by the plugin will be included in the resulting jar of this rule. |
 | `processor_class` | String; default is `""` The processor class is the fully qualified type of the class that the Java compiler should use as entry point to the annotation processor. If not specified, this rule will not contribute an annotation processor to the Java compiler's annotation processing, but its runtime classpath will still be included on the compiler's annotation processor path. (This is primarily intended for use by [Error Prone plugins](https://errorprone.info/docs/plugins), which are loaded from the annotation processor path using [java.util.ServiceLoader](https://docs.oracle.com/javase/8/docs/api/java/util/ServiceLoader.html).) |
-| `proguard_specs` | List of [labels](/concepts/labels); default is `[]` Files to be used as Proguard specification. These will describe the set of specifications to be used by Proguard. If specified, they will be added to any `android_binary` target depending on this library. The files included here must only have idempotent rules, namely -dontnote, -dontwarn, assumenosideeffects, and rules that start with -keep. Other options can only appear in `android_binary`'s proguard_specs, to ensure non-tautological merges. |
+| `proguard_specs` | List of [labels](/versions/8.6.0/concepts/labels); default is `[]` Files to be used as Proguard specification. These will describe the set of specifications to be used by Proguard. If specified, they will be added to any `android_binary` target depending on this library. The files included here must only have idempotent rules, namely -dontnote, -dontwarn, assumenosideeffects, and rules that start with -keep. Other options can only appear in `android_binary`'s proguard_specs, to ensure non-tautological merges. |
 | `resource_strip_prefix` | String; default is `""` The path prefix to strip from Java resources. If specified, this path prefix is stripped from every file in the `resources` attribute. It is an error for a resource file not to be under this directory. If not specified (the default), the path of resource file is determined according to the same logic as the Java package of source files. For example, a source file at `stuff/java/foo/bar/a.txt` will be located at `foo/bar/a.txt`. |
 
 ## java_runtime
 
-[View rule sourceopen_in_new](@rules_java//java/common/rules/java_runtime.bzl)
+[View rule sourceopen_in_new](/versions/8.6.0/reference/be/@rules_java//java/common/rules/java_runtime.bzl)
 
 ```
 java_runtime(name, srcs, compatible_with, default_cds, deprecation, distribs, exec_compatible_with, exec_properties, features, hermetic_srcs, hermetic_static_libs, java, java_home, lib_ct_sym, lib_modules, output_licenses, restricted_to, tags, target_compatible_with, testonly, toolchains, version, visibility)
@@ -396,21 +395,21 @@ java_runtime(
 
 | Attributes | |
 | --- | --- |
-| `name` | [Name](/concepts/labels#target-names); required  A unique name for this target. |
-| `srcs` | List of [labels](/concepts/labels); default is `[]` All files in the runtime. |
-| `default_cds` | [Label](/concepts/labels); default is `None` Default CDS archive for hermetic `java_runtime`. When hermetic is enabled for a `java_binary` target the `java_runtime` default CDS is packaged in the hermetic deploy JAR. |
-| `hermetic_srcs` | List of [labels](/concepts/labels); default is `[]` Files in the runtime needed for hermetic deployments. |
-| `hermetic_static_libs` | List of [labels](/concepts/labels); default is `[]` The libraries that are statically linked with the launcher for hermetic deployments |
-| `java` | [Label](/concepts/labels); default is `None` The path to the java executable. |
-| `java_home` | String; default is `""` The path to the root of the runtime. Subject to ["Make" variable](/reference/be/make-variables) substitution. If this path is absolute, the rule denotes a non-hermetic Java runtime with a well-known path. In that case, the `srcs` and `java` attributes must be empty. |
-| `lib_ct_sym` | [Label](/concepts/labels); default is `None` The lib/ct.sym file needed for compilation with `--release`. If not specified and there is exactly one file in `srcs` whose path ends with `/lib/ct.sym`, that file is used. |
-| `lib_modules` | [Label](/concepts/labels); default is `None` The lib/modules file needed for hermetic deployments. |
+| `name` | [Name](/versions/8.6.0/concepts/labels#target-names); required  A unique name for this target. |
+| `srcs` | List of [labels](/versions/8.6.0/concepts/labels); default is `[]` All files in the runtime. |
+| `default_cds` | [Label](/versions/8.6.0/concepts/labels); default is `None` Default CDS archive for hermetic `java_runtime`. When hermetic is enabled for a `java_binary` target the `java_runtime` default CDS is packaged in the hermetic deploy JAR. |
+| `hermetic_srcs` | List of [labels](/versions/8.6.0/concepts/labels); default is `[]` Files in the runtime needed for hermetic deployments. |
+| `hermetic_static_libs` | List of [labels](/versions/8.6.0/concepts/labels); default is `[]` The libraries that are statically linked with the launcher for hermetic deployments |
+| `java` | [Label](/versions/8.6.0/concepts/labels); default is `None` The path to the java executable. |
+| `java_home` | String; default is `""` The path to the root of the runtime. Subject to ["Make" variable](/versions/8.6.0/reference/be/make-variables) substitution. If this path is absolute, the rule denotes a non-hermetic Java runtime with a well-known path. In that case, the `srcs` and `java` attributes must be empty. |
+| `lib_ct_sym` | [Label](/versions/8.6.0/concepts/labels); default is `None` The lib/ct.sym file needed for compilation with `--release`. If not specified and there is exactly one file in `srcs` whose path ends with `/lib/ct.sym`, that file is used. |
+| `lib_modules` | [Label](/versions/8.6.0/concepts/labels); default is `None` The lib/modules file needed for hermetic deployments. |
 | `output_licenses` | List of strings; default is `[]` |
 | `version` | Integer; default is `0` The feature version of the Java runtime. I.e., the integer returned by `Runtime.version().feature()`. |
 
 ## java_toolchain
 
-[View rule sourceopen_in_new](@rules_java//java/common/rules/java_toolchain.bzl)
+[View rule sourceopen_in_new](/versions/8.6.0/reference/be/@rules_java//java/common/rules/java_toolchain.bzl)
 
 ```
 java_toolchain(name, android_lint_data, android_lint_jvm_opts, android_lint_opts, android_lint_package_configuration, android_lint_runner, bootclasspath, compatible_javacopts, compatible_with, deprecation, deps_checker, distribs, exec_compatible_with, exec_properties, features, forcibly_disable_header_compilation, genclass, header_compiler, header_compiler_builtin_processors, header_compiler_direct, ijar, jacocorunner, java_runtime, javabuilder, javabuilder_data, javabuilder_jvm_opts, javac_supports_multiplex_workers, javac_supports_worker_cancellation, javac_supports_worker_multiplex_sandboxing, javac_supports_workers, javacopts, jspecify_implicit_deps, jspecify_javacopts, jspecify_packages, jspecify_processor, jspecify_processor_class, jspecify_stubs, jvm_opts, licenses, misc, oneversion, oneversion_allowlist, oneversion_allowlist_for_tests, oneversion_whitelist, package_configuration, proguard_allowlister, reduced_classpath_incompatible_processors, restricted_to, singlejar, source_version, tags, target_compatible_with, target_version, testonly, timezone_data, toolchains, tools, turbine_data, turbine_jvm_opts, visibility, xlint)
@@ -440,51 +439,51 @@ java_toolchain(
 
 | Attributes | |
 | --- | --- |
-| `name` | [Name](/concepts/labels#target-names); required  A unique name for this target. |
-| `android_lint_data` | List of [labels](/concepts/labels); default is `[]` Labels of tools available for label-expansion in android_lint_jvm_opts. |
+| `name` | [Name](/versions/8.6.0/concepts/labels#target-names); required  A unique name for this target. |
+| `android_lint_data` | List of [labels](/versions/8.6.0/concepts/labels); default is `[]` Labels of tools available for label-expansion in android_lint_jvm_opts. |
 | `android_lint_jvm_opts` | List of strings; default is `[]` The list of arguments for the JVM when invoking Android Lint. |
 | `android_lint_opts` | List of strings; default is `[]` The list of Android Lint arguments. |
-| `android_lint_package_configuration` | List of [labels](/concepts/labels); default is `[]` Android Lint Configuration that should be applied to the specified package groups. |
-| `android_lint_runner` | [Label](/concepts/labels); default is `None` Label of the Android Lint runner, if any. |
-| `bootclasspath` | List of [labels](/concepts/labels); default is `[]` The Java target bootclasspath entries. Corresponds to javac's -bootclasspath flag. |
+| `android_lint_package_configuration` | List of [labels](/versions/8.6.0/concepts/labels); default is `[]` Android Lint Configuration that should be applied to the specified package groups. |
+| `android_lint_runner` | [Label](/versions/8.6.0/concepts/labels); default is `None` Label of the Android Lint runner, if any. |
+| `bootclasspath` | List of [labels](/versions/8.6.0/concepts/labels); default is `[]` The Java target bootclasspath entries. Corresponds to javac's -bootclasspath flag. |
 | `compatible_javacopts` | null; default is `{}` Internal API, do not use! |
-| `deps_checker` | [Label](/concepts/labels); default is `None` Label of the ImportDepsChecker deploy jar. |
+| `deps_checker` | [Label](/versions/8.6.0/concepts/labels); default is `None` Label of the ImportDepsChecker deploy jar. |
 | `forcibly_disable_header_compilation` | Boolean; default is `False` Overrides --java_header_compilation to disable header compilation on platforms that do not support it, e.g. JDK 7 Bazel. |
-| `genclass` | [Label](/concepts/labels); default is `None` Label of the GenClass deploy jar. |
-| `header_compiler` | [Label](/concepts/labels); default is `None` Label of the header compiler. Required if --java_header_compilation is enabled. |
+| `genclass` | [Label](/versions/8.6.0/concepts/labels); default is `None` Label of the GenClass deploy jar. |
+| `header_compiler` | [Label](/versions/8.6.0/concepts/labels); default is `None` Label of the header compiler. Required if --java_header_compilation is enabled. |
 | `header_compiler_builtin_processors` | List of strings; default is `[]` Internal API, do not use! |
-| `header_compiler_direct` | [Label](/concepts/labels); default is `None` Optional label of the header compiler to use for direct classpath actions that do not include any API-generating annotation processors. This tool does not support annotation processing. |
-| `ijar` | [Label](/concepts/labels); default is `None` Label of the ijar executable. |
-| `jacocorunner` | [Label](/concepts/labels); default is `None` Label of the JacocoCoverageRunner deploy jar. |
-| `java_runtime` | [Label](/concepts/labels); default is `None` The java_runtime to use with this toolchain. It defaults to java_runtime in execution configuration. |
-| `javabuilder` | [Label](/concepts/labels); default is `None` Label of the JavaBuilder deploy jar. |
-| `javabuilder_data` | List of [labels](/concepts/labels); default is `[]` Labels of data available for label-expansion in javabuilder_jvm_opts. |
+| `header_compiler_direct` | [Label](/versions/8.6.0/concepts/labels); default is `None` Optional label of the header compiler to use for direct classpath actions that do not include any API-generating annotation processors. This tool does not support annotation processing. |
+| `ijar` | [Label](/versions/8.6.0/concepts/labels); default is `None` Label of the ijar executable. |
+| `jacocorunner` | [Label](/versions/8.6.0/concepts/labels); default is `None` Label of the JacocoCoverageRunner deploy jar. |
+| `java_runtime` | [Label](/versions/8.6.0/concepts/labels); default is `None` The java_runtime to use with this toolchain. It defaults to java_runtime in execution configuration. |
+| `javabuilder` | [Label](/versions/8.6.0/concepts/labels); default is `None` Label of the JavaBuilder deploy jar. |
+| `javabuilder_data` | List of [labels](/versions/8.6.0/concepts/labels); default is `[]` Labels of data available for label-expansion in javabuilder_jvm_opts. |
 | `javabuilder_jvm_opts` | List of strings; default is `[]` The list of arguments for the JVM when invoking JavaBuilder. |
 | `javac_supports_multiplex_workers` | Boolean; default is `True` True if JavaBuilder supports running as a multiplex persistent worker, false if it doesn't. |
 | `javac_supports_worker_cancellation` | Boolean; default is `True` True if JavaBuilder supports cancellation of persistent workers, false if it doesn't. |
 | `javac_supports_worker_multiplex_sandboxing` | Boolean; default is `False` True if JavaBuilder supports running as a multiplex persistent worker with sandboxing, false if it doesn't. |
 | `javac_supports_workers` | Boolean; default is `True` True if JavaBuilder supports running as a persistent worker, false if it doesn't. |
 | `javacopts` | List of strings; default is `[]` The list of extra arguments for the Java compiler. Please refer to the Java compiler documentation for the extensive list of possible Java compiler flags. |
-| `jspecify_implicit_deps` | [Label](/concepts/labels); default is `None` Experimental, do not use! |
+| `jspecify_implicit_deps` | [Label](/versions/8.6.0/concepts/labels); default is `None` Experimental, do not use! |
 | `jspecify_javacopts` | List of strings; default is `[]` Experimental, do not use! |
-| `jspecify_packages` | List of [labels](/concepts/labels); default is `[]` Experimental, do not use! |
-| `jspecify_processor` | [Label](/concepts/labels); default is `None` Experimental, do not use! |
+| `jspecify_packages` | List of [labels](/versions/8.6.0/concepts/labels); default is `[]` Experimental, do not use! |
+| `jspecify_processor` | [Label](/versions/8.6.0/concepts/labels); default is `None` Experimental, do not use! |
 | `jspecify_processor_class` | String; default is `""` Experimental, do not use! |
-| `jspecify_stubs` | List of [labels](/concepts/labels); default is `[]` Experimental, do not use! |
+| `jspecify_stubs` | List of [labels](/versions/8.6.0/concepts/labels); default is `[]` Experimental, do not use! |
 | `jvm_opts` | List of strings; default is `[]` The list of arguments for the JVM when invoking the Java compiler. Please refer to the Java virtual machine documentation for the extensive list of possible flags for this option. |
 | `misc` | List of strings; default is `[]` Deprecated: use javacopts instead |
-| `oneversion` | [Label](/concepts/labels); default is `None` Label of the one-version enforcement binary. |
-| `oneversion_allowlist` | [Label](/concepts/labels); default is `None` Label of the one-version allowlist. |
-| `oneversion_allowlist_for_tests` | [Label](/concepts/labels); default is `None` Label of the one-version allowlist for tests. |
-| `oneversion_whitelist` | [Label](/concepts/labels); default is `None` Deprecated: use oneversion_allowlist instead |
-| `package_configuration` | List of [labels](/concepts/labels); default is `[]` Configuration that should be applied to the specified package groups. |
-| `proguard_allowlister` | [Label](/concepts/labels); default is `"@bazel_tools//tools/jdk:proguard_whitelister"` Label of the Proguard allowlister. |
+| `oneversion` | [Label](/versions/8.6.0/concepts/labels); default is `None` Label of the one-version enforcement binary. |
+| `oneversion_allowlist` | [Label](/versions/8.6.0/concepts/labels); default is `None` Label of the one-version allowlist. |
+| `oneversion_allowlist_for_tests` | [Label](/versions/8.6.0/concepts/labels); default is `None` Label of the one-version allowlist for tests. |
+| `oneversion_whitelist` | [Label](/versions/8.6.0/concepts/labels); default is `None` Deprecated: use oneversion_allowlist instead |
+| `package_configuration` | List of [labels](/versions/8.6.0/concepts/labels); default is `[]` Configuration that should be applied to the specified package groups. |
+| `proguard_allowlister` | [Label](/versions/8.6.0/concepts/labels); default is `"@bazel_tools//tools/jdk:proguard_whitelister"` Label of the Proguard allowlister. |
 | `reduced_classpath_incompatible_processors` | List of strings; default is `[]` Internal API, do not use! |
-| `singlejar` | [Label](/concepts/labels); default is `None` Label of the SingleJar deploy jar. |
+| `singlejar` | [Label](/versions/8.6.0/concepts/labels); default is `None` Label of the SingleJar deploy jar. |
 | `source_version` | String; default is `""` The Java source version (e.g., '6' or '7'). It specifies which set of code structures are allowed in the Java source code. |
 | `target_version` | String; default is `""` The Java target version (e.g., '6' or '7'). It specifies for which Java runtime the class should be build. |
-| `timezone_data` | [Label](/concepts/labels); default is `None` Label of a resource jar containing timezone data. If set, the timezone data is added as an implicitly runtime dependency of all java_binary rules. |
-| `tools` | List of [labels](/concepts/labels); default is `[]` Labels of tools available for label-expansion in jvm_opts. |
-| `turbine_data` | List of [labels](/concepts/labels); default is `[]` Labels of data available for label-expansion in turbine_jvm_opts. |
+| `timezone_data` | [Label](/versions/8.6.0/concepts/labels); default is `None` Label of a resource jar containing timezone data. If set, the timezone data is added as an implicitly runtime dependency of all java_binary rules. |
+| `tools` | List of [labels](/versions/8.6.0/concepts/labels); default is `[]` Labels of tools available for label-expansion in jvm_opts. |
+| `turbine_data` | List of [labels](/versions/8.6.0/concepts/labels); default is `[]` Labels of data available for label-expansion in turbine_jvm_opts. |
 | `turbine_jvm_opts` | List of strings; default is `[]` The list of arguments for the JVM when invoking turbine. |
 | `xlint` | List of strings; default is `[]` The list of warning to add or removes from default list. Precedes it with a dash to removes it. Please see the Javac documentation on the -Xlint options for more information. |
\ No newline at end of file
diff --git a/versions/8.6.0/reference/be/make-variables.mdx b/versions/8.6.0/reference/be/make-variables.mdx
index b527affb..6cd8624c 100644
--- a/versions/8.6.0/reference/be/make-variables.mdx
+++ b/versions/8.6.0/reference/be/make-variables.mdx
@@ -19,8 +19,7 @@ targets, and *custom* variables, which are defined in dependency targets
 and only available to targets that depend on them.
 
 The reason for the term "Make" is historical: the syntax and semantics of
-these variables were originally intended to match [GNU
-Make](https://www.gnu.org/software/make/manual/html_node/Using-Variables.html).
+these variables were originally intended to match [GNU Make](https://www.gnu.org/software/make/manual/html_node/Using-Variables.html).
 
 ## Use
 
@@ -64,8 +63,7 @@ and look at the top output lines with capital letters.
 **Toolchain option variables**
 
 * `COMPILATION_MODE`:
-  `fastbuild`, `dbg`, or `opt`. ([more
-  details](https://bazel.build/docs/user-manual#flag--compilation_mode))
+  `fastbuild`, `dbg`, or `opt`. ([more details](https://bazel.build/versions/8.6.0/docs/user-manual#flag--compilation_mode))
 
 **Path variables**
 
@@ -111,7 +109,7 @@ generally important for making that attribute work.
   `//my/pkg:my_genrule` this always ends in `my/pkg`,
   even if `//my/pkg:my_genrule`'s outputs are in subdirectories.
 * `@D`: The output directory. If
-  [outs](/reference/be/general#genrule.outs) has one entry,
+  [outs](/versions/8.6.0/reference/be/general#genrule.outs) has one entry,
   this expands to the directory containing that file. If it has multiple
   entries, this expands to the package's root directory in the
   `genfiles` tree, *even if all output files are in the same
@@ -143,7 +141,7 @@ For files that are outputs of rules, this is the file's *output path*
 [See an example of predefined path variables](https://github.com/bazelbuild/examples/tree/main/make-variables#predefined-path-variables).
 
 * `execpath`: Denotes the path beneath the
-  [execroot](/docs/output_directories)
+  [execroot](/versions/8.6.0/docs/output_directories)
   where Bazel runs build actions.
 
   In the above example, Bazel runs all build actions in the directory linked
@@ -171,7 +169,7 @@ For files that are outputs of rules, this is the file's *output path*
 * `rootpath`: Denotes the path that a built binary can use to
   find a dependency at runtime relative to the subdirectory of its runfiles
   directory corresponding to the main repository.
-  **Note:** This only works if [`--enable_runfiles`](/reference/command-line-reference#flag--enable_runfiles) is enabled, which is not the case on
+  **Note:** This only works if [`--enable_runfiles`](/versions/8.6.0/reference/command-line-reference#flag--enable_runfiles) is enabled, which is not the case on
   Windows by default. Use `rlocationpath` instead for
   cross-platform support.
 
@@ -253,7 +251,7 @@ lengths to ensure the correct inputs, outputs, and command-line flags are set
 on each of potentially multiple internally generated actions.
 
 These variables are a fallback mechanism to be used by language experts in
-rare cases. If you are tempted to use them, please [contact the Bazel devs](https://bazel.build/help) first.
+rare cases. If you are tempted to use them, please [contact the Bazel devs](https://bazel.build/versions/8.6.0/help) first.
 
 * `ABI`: The C++ ABI version.
 * `AR`: The "ar" command from crosstool.
@@ -289,7 +287,7 @@ than upstream tools can express, such as interface Jars, header interface
 Jars, and highly optimized Jar packaging and merging implementations.
 
 These variables are a fallback mechanism to be used by language experts in
-rare cases. If you are tempted to use them, please [contact the Bazel devs](https://bazel.build/help) first.
+rare cases. If you are tempted to use them, please [contact the Bazel devs](https://bazel.build/versions/8.6.0/help) first.
 
 * `JAVA`: The "java" command (a Java virtual
   machine). Avoid this, and use a `java_binary` rule
@@ -302,9 +300,9 @@ rare cases. If you are tempted to use them, please [contact the Bazel devs](http
 
 **Starlark-defined variables**
 
-Rule and [toolchain](/docs/toolchains) writers can define
+Rule and [toolchain](/versions/8.6.0/docs/toolchains) writers can define
 completely custom variables by returning a
-[TemplateVariableInfo](/rules/lib/TemplateVariableInfo)
+[TemplateVariableInfo](/versions/8.6.0/rules/lib/providers/TemplateVariableInfo)
 provider. Any rules depending on these through the
 `toolchains` attribute can then read their values:
 
diff --git a/versions/8.6.0/reference/be/objective-c.mdx b/versions/8.6.0/reference/be/objective-c.mdx
index 97ac34a5..9ea15cda 100644
--- a/versions/8.6.0/reference/be/objective-c.mdx
+++ b/versions/8.6.0/reference/be/objective-c.mdx
@@ -23,16 +23,16 @@ attributes supported by `objc_library`.
 
 | Attributes | |
 | --- | --- |
-| `name` | [Name](/concepts/labels#target-names); required  A unique name for this target. |
-| `deps` | List of [labels](/concepts/labels); default is `[]` The list of targets that this target depend on. |
-| `hdrs` | List of [labels](/concepts/labels); default is `[]` The list of C, C++, Objective-C, and Objective-C++ header files published by this library to be included by sources in dependent rules. These headers describe the public interface for the library and will be made available for inclusion by sources in this rule or in dependent rules. Headers not meant to be included by a client of this library should be listed in the srcs attribute instead. These will be compiled separately from the source if modules are enabled. |
+| `name` | [Name](/versions/8.6.0/concepts/labels#target-names); required  A unique name for this target. |
+| `deps` | List of [labels](/versions/8.6.0/concepts/labels); default is `[]` The list of targets that this target depend on. |
+| `hdrs` | List of [labels](/versions/8.6.0/concepts/labels); default is `[]` The list of C, C++, Objective-C, and Objective-C++ header files published by this library to be included by sources in dependent rules. These headers describe the public interface for the library and will be made available for inclusion by sources in this rule or in dependent rules. Headers not meant to be included by a client of this library should be listed in the srcs attribute instead. These will be compiled separately from the source if modules are enabled. |
 | `alwayslink` | Boolean; default is `False` If 1, any bundle or binary that depends (directly or indirectly) on this library will link in all the object files for the files listed in `srcs` and `non_arc_srcs`, even if some contain no symbols referenced by the binary. This is useful if your code isn't explicitly called by code in the binary, e.g., if your code registers to receive some callback provided by some service. |
-| `archives` | List of [labels](/concepts/labels); required The list of `.a` files provided to Objective-C targets that depend on this target. |
-| `includes` | List of strings; default is `[]` List of `#include/#import` search paths to add to this target and all depending targets. This is to support third party and open-sourced libraries that do not specify the entire workspace path in their `#import/#include` statements. The paths are interpreted relative to the package directory, and the genfiles and bin roots (e.g. `blaze-genfiles/pkg/includedir` and `blaze-out/pkg/includedir`) are included in addition to the actual client root. Unlike [COPTS](/reference/be/objective-c#objc_library.copts), these flags are added for this rule and every rule that depends on it. (Note: not the rules it depends upon!) Be very careful, since this may have far-reaching effects. When in doubt, add "-iquote" flags to [COPTS](/reference/be/objective-c#objc_library.copts) instead. |
+| `archives` | List of [labels](/versions/8.6.0/concepts/labels); required The list of `.a` files provided to Objective-C targets that depend on this target. |
+| `includes` | List of strings; default is `[]` List of `#include/#import` search paths to add to this target and all depending targets. This is to support third party and open-sourced libraries that do not specify the entire workspace path in their `#import/#include` statements. The paths are interpreted relative to the package directory, and the genfiles and bin roots (e.g. `blaze-genfiles/pkg/includedir` and `blaze-out/pkg/includedir`) are included in addition to the actual client root. Unlike [COPTS](/versions/8.6.0/reference/be/objective-c#objc_library.copts), these flags are added for this rule and every rule that depends on it. (Note: not the rules it depends upon!) Be very careful, since this may have far-reaching effects. When in doubt, add "-iquote" flags to [COPTS](/versions/8.6.0/reference/be/objective-c#objc_library.copts) instead. |
 | `sdk_dylibs` | List of strings; default is `[]` Names of SDK .dylib libraries to link with. For instance, "libz" or "libarchive". "libc++" is included automatically if the binary has any C++ or Objective-C++ sources in its dependency tree. When linking a binary, all libraries named in that binary's transitive dependency graph are used. |
 | `sdk_frameworks` | List of strings; default is `[]` Names of SDK frameworks to link with (e.g. "AddressBook", "QuartzCore"). When linking a top level Apple binary, all SDK frameworks listed in that binary's transitive dependency graph are linked. |
 | `sdk_includes` | List of strings; default is `[]` List of `#include/#import` search paths to add to this target and all depending targets, where each path is relative to `$(SDKROOT)/usr/include`. |
-| `textual_hdrs` | List of [labels](/concepts/labels); default is `[]` The list of C, C++, Objective-C, and Objective-C++ files that are included as headers by source files in this rule or by users of this library. Unlike hdrs, these will not be compiled separately from the sources. |
+| `textual_hdrs` | List of [labels](/versions/8.6.0/concepts/labels); default is `[]` The list of C, C++, Objective-C, and Objective-C++ files that are included as headers by source files in this rule or by users of this library. Unlike hdrs, these will not be compiled separately from the sources. |
 | `weak_sdk_frameworks` | List of strings; default is `[]` Names of SDK frameworks to weakly link with. For instance, "MediaAccessibility". In difference to regularly linked SDK frameworks, symbols from weakly linked frameworks do not cause an error if they are not present at runtime. |
 
 ## objc_library
@@ -49,26 +49,26 @@ This rule produces a static library from the given Objective-C source files.
 
 | Attributes | |
 | --- | --- |
-| `name` | [Name](/concepts/labels#target-names); required  A unique name for this target. |
-| `deps` | List of [labels](/concepts/labels); default is `[]` The list of targets that this target depend on. |
-| `srcs` | List of [labels](/concepts/labels); default is `[]` The list of C, C++, Objective-C, and Objective-C++ source and header files, and/or (`.s`, `.S`, or `.asm`) assembly source files, that are processed to create the library target. These are your checked-in files, plus any generated files. Source files are compiled into .o files with Clang. Header files may be included/imported by any source or header in the srcs attribute of this target, but not by headers in hdrs or any targets that depend on this rule. Additionally, precompiled .o files may be given as srcs. Be careful to ensure consistency in the architecture of provided .o files and that of the build to avoid missing symbol linker errors. |
-| `hdrs` | List of [labels](/concepts/labels); default is `[]` The list of C, C++, Objective-C, and Objective-C++ header files published by this library to be included by sources in dependent rules. These headers describe the public interface for the library and will be made available for inclusion by sources in this rule or in dependent rules. Headers not meant to be included by a client of this library should be listed in the srcs attribute instead. These will be compiled separately from the source if modules are enabled. |
+| `name` | [Name](/versions/8.6.0/concepts/labels#target-names); required  A unique name for this target. |
+| `deps` | List of [labels](/versions/8.6.0/concepts/labels); default is `[]` The list of targets that this target depend on. |
+| `srcs` | List of [labels](/versions/8.6.0/concepts/labels); default is `[]` The list of C, C++, Objective-C, and Objective-C++ source and header files, and/or (`.s`, `.S`, or `.asm`) assembly source files, that are processed to create the library target. These are your checked-in files, plus any generated files. Source files are compiled into .o files with Clang. Header files may be included/imported by any source or header in the srcs attribute of this target, but not by headers in hdrs or any targets that depend on this rule. Additionally, precompiled .o files may be given as srcs. Be careful to ensure consistency in the architecture of provided .o files and that of the build to avoid missing symbol linker errors. |
+| `hdrs` | List of [labels](/versions/8.6.0/concepts/labels); default is `[]` The list of C, C++, Objective-C, and Objective-C++ header files published by this library to be included by sources in dependent rules. These headers describe the public interface for the library and will be made available for inclusion by sources in this rule or in dependent rules. Headers not meant to be included by a client of this library should be listed in the srcs attribute instead. These will be compiled separately from the source if modules are enabled. |
 | `alwayslink` | Boolean; default is `False` If 1, any bundle or binary that depends (directly or indirectly) on this library will link in all the object files for the files listed in `srcs` and `non_arc_srcs`, even if some contain no symbols referenced by the binary. This is useful if your code isn't explicitly called by code in the binary, e.g., if your code registers to receive some callback provided by some service. |
-| `conlyopts` | List of strings; default is `[]` Extra flags to pass to the compiler for C files. Subject to ["Make variable"](/reference/be/make-variables) substitution and [Bourne shell tokenization](/reference/be/common-definitions#sh-tokenization). These flags will only apply to this target, and not those upon which it depends, or those which depend on it. Note that for the generated Xcode project, directory paths specified using "-I" flags in copts are parsed out, prepended with "$(WORKSPACE_ROOT)/" if they are relative paths, and added to the header search paths for the associated Xcode target. |
-| `copts` | List of strings; default is `[]` Extra flags to pass to the compiler. Subject to ["Make variable"](/reference/be/make-variables) substitution and [Bourne shell tokenization](/reference/be/common-definitions#sh-tokenization). These flags will only apply to this target, and not those upon which it depends, or those which depend on it. Note that for the generated Xcode project, directory paths specified using "-I" flags in copts are parsed out, prepended with "$(WORKSPACE_ROOT)/" if they are relative paths, and added to the header search paths for the associated Xcode target. |
-| `cxxopts` | List of strings; default is `[]` Extra flags to pass to the compiler for Objective-C++ and C++ files. Subject to ["Make variable"](/reference/be/make-variables) substitution and [Bourne shell tokenization](/reference/be/common-definitions#sh-tokenization). These flags will only apply to this target, and not those upon which it depends, or those which depend on it. Note that for the generated Xcode project, directory paths specified using "-I" flags in copts are parsed out, prepended with "$(WORKSPACE_ROOT)/" if they are relative paths, and added to the header search paths for the associated Xcode target. |
-| `defines` | List of strings; default is `[]` Extra `-D` flags to pass to the compiler. They should be in the form `KEY=VALUE` or simply `KEY` and are passed not only to the compiler for this target (as `copts` are) but also to all `objc_` dependers of this target. Subject to ["Make variable"](/reference/be/make-variables) substitution and [Bourne shell tokenization](/reference/be/common-definitions#sh-tokenization). |
+| `conlyopts` | List of strings; default is `[]` Extra flags to pass to the compiler for C files. Subject to ["Make variable"](/versions/8.6.0/reference/be/make-variables) substitution and [Bourne shell tokenization](/versions/8.6.0/reference/be/common-definitions#sh-tokenization). These flags will only apply to this target, and not those upon which it depends, or those which depend on it. Note that for the generated Xcode project, directory paths specified using "-I" flags in copts are parsed out, prepended with "$(WORKSPACE_ROOT)/" if they are relative paths, and added to the header search paths for the associated Xcode target. |
+| `copts` | List of strings; default is `[]` Extra flags to pass to the compiler. Subject to ["Make variable"](/versions/8.6.0/reference/be/make-variables) substitution and [Bourne shell tokenization](/versions/8.6.0/reference/be/common-definitions#sh-tokenization). These flags will only apply to this target, and not those upon which it depends, or those which depend on it. Note that for the generated Xcode project, directory paths specified using "-I" flags in copts are parsed out, prepended with "$(WORKSPACE_ROOT)/" if they are relative paths, and added to the header search paths for the associated Xcode target. |
+| `cxxopts` | List of strings; default is `[]` Extra flags to pass to the compiler for Objective-C++ and C++ files. Subject to ["Make variable"](/versions/8.6.0/reference/be/make-variables) substitution and [Bourne shell tokenization](/versions/8.6.0/reference/be/common-definitions#sh-tokenization). These flags will only apply to this target, and not those upon which it depends, or those which depend on it. Note that for the generated Xcode project, directory paths specified using "-I" flags in copts are parsed out, prepended with "$(WORKSPACE_ROOT)/" if they are relative paths, and added to the header search paths for the associated Xcode target. |
+| `defines` | List of strings; default is `[]` Extra `-D` flags to pass to the compiler. They should be in the form `KEY=VALUE` or simply `KEY` and are passed not only to the compiler for this target (as `copts` are) but also to all `objc_` dependers of this target. Subject to ["Make variable"](/versions/8.6.0/reference/be/make-variables) substitution and [Bourne shell tokenization](/versions/8.6.0/reference/be/common-definitions#sh-tokenization). |
 | `enable_modules` | Boolean; default is `False` Enables clang module support (via -fmodules). Setting this to 1 will allow you to @import system headers and other targets: @import UIKit; @import path_to_package_target; |
-| `implementation_deps` | List of [labels](/concepts/labels); default is `[]` The list of other libraries that the library target depends on. Unlike with `deps`, the headers and include paths of these libraries (and all their transitive deps) are only used for compilation of this library, and not libraries that depend on it. Libraries specified with `implementation_deps` are still linked in binary targets that depend on this library. |
-| `includes` | List of strings; default is `[]` List of `#include/#import` search paths to add to this target and all depending targets. This is to support third party and open-sourced libraries that do not specify the entire workspace path in their `#import/#include` statements. The paths are interpreted relative to the package directory, and the genfiles and bin roots (e.g. `blaze-genfiles/pkg/includedir` and `blaze-out/pkg/includedir`) are included in addition to the actual client root. Unlike [COPTS](/reference/be/objective-c#objc_library.copts), these flags are added for this rule and every rule that depends on it. (Note: not the rules it depends upon!) Be very careful, since this may have far-reaching effects. When in doubt, add "-iquote" flags to [COPTS](/reference/be/objective-c#objc_library.copts) instead. |
+| `implementation_deps` | List of [labels](/versions/8.6.0/concepts/labels); default is `[]` The list of other libraries that the library target depends on. Unlike with `deps`, the headers and include paths of these libraries (and all their transitive deps) are only used for compilation of this library, and not libraries that depend on it. Libraries specified with `implementation_deps` are still linked in binary targets that depend on this library. |
+| `includes` | List of strings; default is `[]` List of `#include/#import` search paths to add to this target and all depending targets. This is to support third party and open-sourced libraries that do not specify the entire workspace path in their `#import/#include` statements. The paths are interpreted relative to the package directory, and the genfiles and bin roots (e.g. `blaze-genfiles/pkg/includedir` and `blaze-out/pkg/includedir`) are included in addition to the actual client root. Unlike [COPTS](/versions/8.6.0/reference/be/objective-c#objc_library.copts), these flags are added for this rule and every rule that depends on it. (Note: not the rules it depends upon!) Be very careful, since this may have far-reaching effects. When in doubt, add "-iquote" flags to [COPTS](/versions/8.6.0/reference/be/objective-c#objc_library.copts) instead. |
 | `linkopts` | List of strings; default is `[]` Extra flags to pass to the linker. |
-| `module_map` | [Label](/concepts/labels); default is `None` custom Clang module map for this target. Use of a custom module map is discouraged. Most users should use module maps generated by Bazel. If specified, Bazel will not generate a module map for this target, but will pass the provided module map to the compiler. |
+| `module_map` | [Label](/versions/8.6.0/concepts/labels); default is `None` custom Clang module map for this target. Use of a custom module map is discouraged. Most users should use module maps generated by Bazel. If specified, Bazel will not generate a module map for this target, but will pass the provided module map to the compiler. |
 | `module_name` | String; default is `""` Sets the module name for this target. By default the module name is the target path with all special symbols replaced by \_, e.g. //foo/baz:bar can be imported as foo_baz_bar. |
-| `non_arc_srcs` | List of [labels](/concepts/labels); default is `[]` The list of Objective-C files that are processed to create the library target that DO NOT use ARC. The files in this attribute are treated very similar to those in the srcs attribute, but are compiled without ARC enabled. |
-| `pch` | [Label](/concepts/labels); default is `None` Header file to prepend to every source file being compiled (both arc and non-arc). Use of pch files is actively discouraged in BUILD files, and this should be considered deprecated. Since pch files are not actually precompiled this is not a build-speed enhancement, and instead is just a global dependency. From a build efficiency point of view you are actually better including what you need directly in your sources where you need it. |
+| `non_arc_srcs` | List of [labels](/versions/8.6.0/concepts/labels); default is `[]` The list of Objective-C files that are processed to create the library target that DO NOT use ARC. The files in this attribute are treated very similar to those in the srcs attribute, but are compiled without ARC enabled. |
+| `pch` | [Label](/versions/8.6.0/concepts/labels); default is `None` Header file to prepend to every source file being compiled (both arc and non-arc). Use of pch files is actively discouraged in BUILD files, and this should be considered deprecated. Since pch files are not actually precompiled this is not a build-speed enhancement, and instead is just a global dependency. From a build efficiency point of view you are actually better including what you need directly in your sources where you need it. |
 | `sdk_dylibs` | List of strings; default is `[]` Names of SDK .dylib libraries to link with. For instance, "libz" or "libarchive". "libc++" is included automatically if the binary has any C++ or Objective-C++ sources in its dependency tree. When linking a binary, all libraries named in that binary's transitive dependency graph are used. |
 | `sdk_frameworks` | List of strings; default is `[]` Names of SDK frameworks to link with (e.g. "AddressBook", "QuartzCore"). When linking a top level Apple binary, all SDK frameworks listed in that binary's transitive dependency graph are linked. |
 | `sdk_includes` | List of strings; default is `[]` List of `#include/#import` search paths to add to this target and all depending targets, where each path is relative to `$(SDKROOT)/usr/include`. |
 | `stamp` | Boolean; default is `False` |
-| `textual_hdrs` | List of [labels](/concepts/labels); default is `[]` The list of C, C++, Objective-C, and Objective-C++ files that are included as headers by source files in this rule or by users of this library. Unlike hdrs, these will not be compiled separately from the sources. |
+| `textual_hdrs` | List of [labels](/versions/8.6.0/concepts/labels); default is `[]` The list of C, C++, Objective-C, and Objective-C++ files that are included as headers by source files in this rule or by users of this library. Unlike hdrs, these will not be compiled separately from the sources. |
 | `weak_sdk_frameworks` | List of strings; default is `[]` Names of SDK frameworks to weakly link with. For instance, "MediaAccessibility". In difference to regularly linked SDK frameworks, symbols from weakly linked frameworks do not cause an error if they are not present at runtime. |
\ No newline at end of file
diff --git a/versions/8.6.0/reference/be/overview.mdx b/versions/8.6.0/reference/be/overview.mdx
index 4f84bccd..990eb4b4 100644
--- a/versions/8.6.0/reference/be/overview.mdx
+++ b/versions/8.6.0/reference/be/overview.mdx
@@ -4,26 +4,26 @@ title: 'Bazel BUILD Encyclopedia of Functions'
 
 ## Concepts and terminology
 
-* [Common definitions](/reference/be/common-definitions)
-  + [Bourne shell tokenization](/reference/be/common-definitions#sh-tokenization)
-  + [Label expansion](/reference/be/common-definitions#label-expansion)
-  + [Typical attributes for most rules](/reference/be/common-definitions#typical-attributes)
-  + [Common attributes for all rules](/reference/be/common-definitions#common-attributes)
-  + [Common attributes for tests](/reference/be/common-definitions#common-attributes-tests)
-  + [Common attributes for binaries](/reference/be/common-definitions#common-attributes-binaries)
-  + [Configurable attributes](/reference/be/common-definitions#configurable-attributes)
-  + [Implicit output targets](/reference/be/common-definitions#implicit-outputs)
-* ["Make" variables](/reference/be/make-variables)
-  + [Use](/reference/be/make-variables#use)
+* [Common definitions](/versions/8.6.0/reference/be/common-definitions)
+  + [Bourne shell tokenization](/versions/8.6.0/reference/be/common-definitions#sh-tokenization)
+  + [Label expansion](/versions/8.6.0/reference/be/common-definitions#label-expansion)
+  + [Typical attributes for most rules](/versions/8.6.0/reference/be/common-definitions#typical-attributes)
+  + [Common attributes for all rules](/versions/8.6.0/reference/be/common-definitions#common-attributes)
+  + [Common attributes for tests](/versions/8.6.0/reference/be/common-definitions#common-attributes-tests)
+  + [Common attributes for binaries](/versions/8.6.0/reference/be/common-definitions#common-attributes-binaries)
+  + [Configurable attributes](/versions/8.6.0/reference/be/common-definitions#configurable-attributes)
+  + [Implicit output targets](/versions/8.6.0/reference/be/common-definitions#implicit-outputs)
+* ["Make" variables](/versions/8.6.0/reference/be/make-variables)
+  + [Use](/versions/8.6.0/reference/be/make-variables#use)
 
 ## Functions
 
-* [package](/reference/be/functions#package)
-* [package_group](/reference/be/functions#package_group)
-* [exports_files](/reference/be/functions#exports_files)
-* [glob](/reference/be/functions#glob)
-* [select](/reference/be/functions#select)
-* [workspace](/rules/lib/globals/workspace#workspace)
+* [package](/versions/8.6.0/reference/be/functions#package)
+* [package_group](/versions/8.6.0/reference/be/functions#package_group)
+* [exports_files](/versions/8.6.0/reference/be/functions#exports_files)
+* [glob](/versions/8.6.0/reference/be/functions#glob)
+* [select](/versions/8.6.0/reference/be/functions#select)
+* [workspace](/versions/8.6.0/rules/lib/globals/workspace#workspace)
 
 ## Rules
 
@@ -31,24 +31,24 @@ Native rules ship with the Bazel binary and do not require a `load` statement.
 Native rules are available globally in BUILD files. In .bzl files, you can find them in
 the `native` module.
 For non-native Starlark rules that ship separately from Bazel, see the list of
-[recommended rules](/rules/rules#recommended-rules).
+[recommended rules](/versions/8.6.0/rules/rules#recommended-rules).
 
 ### Language-specific native rules
 
 | Language | Binary rules | Library rules | Test rules | Other rules |
 | --- | --- | --- | --- | --- |
-| C / C++ | [cc_binary](c-cpp#cc_binary) | [cc_import](c-cpp#cc_import)   [cc_library](c-cpp#cc_library)   [cc_shared_library](c-cpp#cc_shared_library)   [cc_static_library](c-cpp#cc_static_library) | [cc_test](c-cpp#cc_test) | [cc_toolchain](c-cpp#cc_toolchain)   [cc_toolchain_suite](c-cpp#cc_toolchain_suite)   [fdo_prefetch_hints](c-cpp#fdo_prefetch_hints)   [fdo_profile](c-cpp#fdo_profile)   [memprof_profile](c-cpp#memprof_profile)   [propeller_optimize](c-cpp#propeller_optimize) |
-| Java | [java_binary](java#java_binary) | [java_import](java#java_import)   [java_library](java#java_library) | [java_test](java#java_test) | [java_package_configuration](java#java_package_configuration)   [java_plugin](java#java_plugin)   [java_runtime](java#java_runtime)   [java_toolchain](java#java_toolchain) |
-| Objective-C |  | [objc_import](objective-c#objc_import)   [objc_library](objective-c#objc_library) |  |  |
-| Protocol Buffer |  | [cc_proto_library](protocol-buffer#cc_proto_library)   [java_lite_proto_library](protocol-buffer#java_lite_proto_library)   [java_proto_library](protocol-buffer#java_proto_library)   [proto_library](protocol-buffer#proto_library)   [py_proto_library](protocol-buffer#py_proto_library) |  | [proto_lang_toolchain](protocol-buffer#proto_lang_toolchain)   [proto_toolchain](protocol-buffer#proto_toolchain) |
-| Python | [py_binary](python#py_binary) | [py_library](python#py_library) | [py_test](python#py_test) | [py_runtime](python#py_runtime) |
-| Shell | [sh_binary](shell#sh_binary) | [sh_library](shell#sh_library) | [sh_test](shell#sh_test) |  |
+| C / C++ | [cc_binary](/versions/8.6.0/reference/be/c-cpp#cc_binary) | [cc_import](/versions/8.6.0/reference/be/c-cpp#cc_import)   [cc_library](/versions/8.6.0/reference/be/c-cpp#cc_library)   [cc_shared_library](/versions/8.6.0/reference/be/c-cpp#cc_shared_library)   [cc_static_library](/versions/8.6.0/reference/be/c-cpp#cc_static_library) | [cc_test](/versions/8.6.0/reference/be/c-cpp#cc_test) | [cc_toolchain](/versions/8.6.0/reference/be/c-cpp#cc_toolchain)   [cc_toolchain_suite](/versions/8.6.0/reference/be/c-cpp#cc_toolchain_suite)   [fdo_prefetch_hints](/versions/8.6.0/reference/be/c-cpp#fdo_prefetch_hints)   [fdo_profile](/versions/8.6.0/reference/be/c-cpp#fdo_profile)   [memprof_profile](/versions/8.6.0/reference/be/c-cpp#memprof_profile)   [propeller_optimize](/versions/8.6.0/reference/be/c-cpp#propeller_optimize) |
+| Java | [java_binary](/versions/8.6.0/reference/be/java#java_binary) | [java_import](/versions/8.6.0/reference/be/java#java_import)   [java_library](/versions/8.6.0/reference/be/java#java_library) | [java_test](/versions/8.6.0/reference/be/java#java_test) | [java_package_configuration](/versions/8.6.0/reference/be/java#java_package_configuration)   [java_plugin](/versions/8.6.0/reference/be/java#java_plugin)   [java_runtime](/versions/8.6.0/reference/be/java#java_runtime)   [java_toolchain](/versions/8.6.0/reference/be/java#java_toolchain) |
+| Objective-C |  | [objc_import](/versions/8.6.0/reference/be/objective-c#objc_import)   [objc_library](/versions/8.6.0/reference/be/objective-c#objc_library) |  |  |
+| Protocol Buffer |  | [cc_proto_library](/versions/8.6.0/reference/be/protocol-buffer#cc_proto_library)   [java_lite_proto_library](/versions/8.6.0/reference/be/protocol-buffer#java_lite_proto_library)   [java_proto_library](/versions/8.6.0/reference/be/protocol-buffer#java_proto_library)   [proto_library](/versions/8.6.0/reference/be/protocol-buffer#proto_library)   [py_proto_library](/versions/8.6.0/reference/be/protocol-buffer#py_proto_library) |  | [proto_lang_toolchain](/versions/8.6.0/reference/be/protocol-buffer#proto_lang_toolchain)   [proto_toolchain](/versions/8.6.0/reference/be/protocol-buffer#proto_toolchain) |
+| Python | [py_binary](/versions/8.6.0/reference/be/python#py_binary) | [py_library](/versions/8.6.0/reference/be/python#py_library) | [py_test](/versions/8.6.0/reference/be/python#py_test) | [py_runtime](/versions/8.6.0/reference/be/python#py_runtime) |
+| Shell | [sh_binary](/versions/8.6.0/reference/be/shell#sh_binary) | [sh_library](/versions/8.6.0/reference/be/shell#sh_library) | [sh_test](/versions/8.6.0/reference/be/shell#sh_test) |  |
 
 ### Language-agnostic native rules
 
 | Family | Rules |
 | --- | --- |
-| Extra Actions | * [action_listener](extra-actions#action_listener)* [extra_action](extra-actions#extra_action) |
-| General | * [alias](general#alias)* [config_setting](general#config_setting)* [filegroup](general#filegroup)* [genquery](general#genquery)* [genrule](general#genrule)* [starlark_doc_extract](general#starlark_doc_extract)* [test_suite](general#test_suite) |
-| Platforms and Toolchains | * [constraint_setting](platforms-and-toolchains#constraint_setting)* [constraint_value](platforms-and-toolchains#constraint_value)* [platform](platforms-and-toolchains#platform)* [toolchain](platforms-and-toolchains#toolchain)* [toolchain_type](platforms-and-toolchains#toolchain_type) |
-| Workspace | * [bind](workspace#bind)* [local_repository](workspace#local_repository)* [new_local_repository](workspace#new_local_repository) |
\ No newline at end of file
+| Extra Actions | * [action_listener](/versions/8.6.0/reference/be/extra-actions#action_listener)* [extra_action](/versions/8.6.0/reference/be/extra-actions#extra_action) |
+| General | * [alias](/versions/8.6.0/reference/be/general#alias)* [config_setting](/versions/8.6.0/reference/be/general#config_setting)* [filegroup](/versions/8.6.0/reference/be/general#filegroup)* [genquery](/versions/8.6.0/reference/be/general#genquery)* [genrule](/versions/8.6.0/reference/be/general#genrule)* [starlark_doc_extract](/versions/8.6.0/reference/be/general#starlark_doc_extract)* [test_suite](/versions/8.6.0/reference/be/general#test_suite) |
+| Platforms and Toolchains | * [constraint_setting](/versions/8.6.0/reference/be/platforms-and-toolchains#constraint_setting)* [constraint_value](/versions/8.6.0/reference/be/platforms-and-toolchains#constraint_value)* [platform](/versions/8.6.0/reference/be/platforms-and-toolchains#platform)* [toolchain](/versions/8.6.0/reference/be/platforms-and-toolchains#toolchain)* [toolchain_type](/versions/8.6.0/reference/be/platforms-and-toolchains#toolchain_type) |
+| Workspace | * [bind](/versions/8.6.0/reference/be/workspace#bind)* [local_repository](/versions/8.6.0/reference/be/workspace#local_repository)* [new_local_repository](/versions/8.6.0/reference/be/workspace#new_local_repository) |
\ No newline at end of file
diff --git a/versions/8.6.0/reference/be/platforms-and-toolchains.mdx b/versions/8.6.0/reference/be/platforms-and-toolchains.mdx
index 58d8f97f..4ce10d4e 100644
--- a/versions/8.6.0/reference/be/platforms-and-toolchains.mdx
+++ b/versions/8.6.0/reference/be/platforms-and-toolchains.mdx
@@ -4,7 +4,7 @@ title: 'Platforms and Toolchains Rules'
 
 This set of rules exists to allow you to model specific hardware platforms you are
 building for and specify the specific tools you may need to compile code for those platforms.
-The user should be familiar with the concepts explained [here](/extending/platforms).
+The user should be familiar with the concepts explained [here](/versions/8.6.0/extending/platforms).
 
 ## Rules
 
@@ -26,7 +26,7 @@ This rule is used to introduce a new constraint type for which a platform may sp
 For instance, you might define a `constraint_setting` named "glibc_version" to represent
 the capability for platforms to have different versions of the glibc library installed.
 For more details, see the
-[Platforms](https://bazel.build/docs/platforms) page.
+[Platforms](https://bazel.build/versions/8.6.0/docs/platforms) page.
 
 Each `constraint_setting` has an extensible set of associated
 `constraint_value`s. Usually these are defined in the same package, but sometimes a
@@ -38,8 +38,8 @@ define a platform targeting an obscure cpu architecture.
 
 | Attributes | |
 | --- | --- |
-| `name` | [Name](/concepts/labels#target-names); required  A unique name for this target. |
-| `default_constraint_value` | [Name](/concepts/labels#target-names); [nonconfigurable](common-definitions#configurable-attributes); default is `None` The label of the default value for this setting, to be used if no value is given. If this attribute is present, the `constraint_value` it points to must be defined in the same package as this `constraint_setting`. If a constraint setting has a default value, then whenever a platform does not include any constraint value for that setting, it is the same as if the platform had specified the default value. Otherwise, if there is no default value, the constraint setting is considered to be unspecified by that platform. In that case, the platform would not match against any constraint list (such as for a `config_setting`) that requires a particular value for that setting. |
+| `name` | [Name](/versions/8.6.0/concepts/labels#target-names); required  A unique name for this target. |
+| `default_constraint_value` | [Name](/versions/8.6.0/concepts/labels#target-names); [nonconfigurable](/versions/8.6.0/reference/be/common-definitions#configurable-attributes); default is `None` The label of the default value for this setting, to be used if no value is given. If this attribute is present, the `constraint_value` it points to must be defined in the same package as this `constraint_setting`. If a constraint setting has a default value, then whenever a platform does not include any constraint value for that setting, it is the same as if the platform had specified the default value. Otherwise, if there is no default value, the constraint setting is considered to be unspecified by that platform. In that case, the platform would not match against any constraint list (such as for a `config_setting`) that requires a particular value for that setting. |
 
 ## constraint_value
 
@@ -51,7 +51,7 @@ constraint_value(name, constraint_setting, deprecation, distribs, features, lice
 
 This rule introduces a new value for a given constraint type.
 For more details, see the
-[Platforms](https://bazel.build/docs/platforms) page.
+[Platforms](https://bazel.build/versions/8.6.0/docs/platforms) page.
 
 #### Example
 
@@ -72,8 +72,8 @@ Platforms can then declare that they have the `mips` architecture as an alternat
 
 | Attributes | |
 | --- | --- |
-| `name` | [Name](/concepts/labels#target-names); required  A unique name for this target. |
-| `constraint_setting` | [Label](/concepts/labels); [nonconfigurable](common-definitions#configurable-attributes); required The `constraint_setting` for which this `constraint_value` is a possible choice. |
+| `name` | [Name](/versions/8.6.0/concepts/labels#target-names); required  A unique name for this target. |
+| `constraint_setting` | [Label](/versions/8.6.0/concepts/labels); [nonconfigurable](/versions/8.6.0/reference/be/common-definitions#configurable-attributes); required The `constraint_setting` for which this `constraint_value` is a possible choice. |
 
 ## platform
 
@@ -86,7 +86,7 @@ platform(name, constraint_values, deprecation, distribs, exec_properties, featur
 This rule defines a new platform -- a named collection of constraint choices
 (such as cpu architecture or compiler version) describing an environment in
 which part of the build may run.
-For more details, see the [Platforms](/extending/platforms) page.
+For more details, see the [Platforms](/versions/8.6.0/extending/platforms) page.
 
 #### Example
 
@@ -277,14 +277,14 @@ In this example, the child platforms have the following properties:
 
 | Attributes | |
 | --- | --- |
-| `name` | [Name](/concepts/labels#target-names); required  A unique name for this target. |
-| `constraint_values` | List of [labels](/concepts/labels); [nonconfigurable](common-definitions#configurable-attributes); default is `[]` The combination of constraint choices that this platform comprises. In order for a platform to apply to a given environment, the environment must have at least the values in this list. Each `constraint_value` in this list must be for a different `constraint_setting`. For example, you cannot define a platform that requires the cpu architecture to be both `@platforms//cpu:x86_64` and `@platforms//cpu:arm`. |
-| `exec_properties` | Dictionary: String -> String; [nonconfigurable](common-definitions#configurable-attributes); default is `{}` A map of strings that affect the way actions are executed remotely. Bazel makes no attempt to interpret this, it is treated as opaque data that's forwarded via the Platform field of the [remote execution protocol](https://github.com/bazelbuild/remote-apis). This includes any data from the parent platform's `exec_properties` attributes. If the child and parent platform define the same keys, the child's values are kept. Any keys associated with a value that is an empty string are removed from the dictionary. This attribute is a full replacement for the deprecated `remote_execution_properties`. |
-| `flags` | List of strings; [nonconfigurable](common-definitions#configurable-attributes); default is `[]` A list of flags that will be enabled when this platform is used as the target platform in a configuration. Only flags that can be set in transitions are allowed to be used. |
-| `missing_toolchain_error` | String; [nonconfigurable](common-definitions#configurable-attributes); default is `"For more information on platforms or toolchains see https://bazel.build/concepts/platforms-intro."` A custom error message that is displayed when a mandatory toolchain requirement cannot be satisfied for this target platform. Intended to point to relevant documentation users can read to understand why their toolchains are misconfigured. Not inherited from parent platforms. |
-| `parents` | List of [labels](/concepts/labels); [nonconfigurable](common-definitions#configurable-attributes); default is `[]` The label of a `platform` target that this platform should inherit from. Although the attribute takes a list, there should be no more than one platform present. Any constraint_settings not set directly on this platform will be found in the parent platform. See the section on [Platform Inheritance](#platform_inheritance) for details. |
-| `remote_execution_properties` | String; [nonconfigurable](common-definitions#configurable-attributes); default is `""` DEPRECATED. Please use exec_properties attribute instead. A string used to configure a remote execution platform. Actual builds make no attempt to interpret this, it is treated as opaque data that can be used by a specific SpawnRunner. This can include data from the parent platform's "remote_execution_properties" attribute, by using the macro "{PARENT_REMOTE_EXECUTION_PROPERTIES}". See the section on [Platform Inheritance](#platform_inheritance) for details. |
-| `required_settings` | List of [labels](/concepts/labels); default is `[]` A list of `config_setting`s that must be satisfied by the target configuration in order for this platform to be used as an execution platform during toolchain resolution. Required settings are not inherited from parent platforms. |
+| `name` | [Name](/versions/8.6.0/concepts/labels#target-names); required  A unique name for this target. |
+| `constraint_values` | List of [labels](/versions/8.6.0/concepts/labels); [nonconfigurable](/versions/8.6.0/reference/be/common-definitions#configurable-attributes); default is `[]` The combination of constraint choices that this platform comprises. In order for a platform to apply to a given environment, the environment must have at least the values in this list. Each `constraint_value` in this list must be for a different `constraint_setting`. For example, you cannot define a platform that requires the cpu architecture to be both `@platforms//cpu:x86_64` and `@platforms//cpu:arm`. |
+| `exec_properties` | Dictionary: String -> String; [nonconfigurable](/versions/8.6.0/reference/be/common-definitions#configurable-attributes); default is `{}` A map of strings that affect the way actions are executed remotely. Bazel makes no attempt to interpret this, it is treated as opaque data that's forwarded via the Platform field of the [remote execution protocol](https://github.com/bazelbuild/remote-apis). This includes any data from the parent platform's `exec_properties` attributes. If the child and parent platform define the same keys, the child's values are kept. Any keys associated with a value that is an empty string are removed from the dictionary. This attribute is a full replacement for the deprecated `remote_execution_properties`. |
+| `flags` | List of strings; [nonconfigurable](/versions/8.6.0/reference/be/common-definitions#configurable-attributes); default is `[]` A list of flags that will be enabled when this platform is used as the target platform in a configuration. Only flags that can be set in transitions are allowed to be used. |
+| `missing_toolchain_error` | String; [nonconfigurable](/versions/8.6.0/reference/be/common-definitions#configurable-attributes); default is `"For more information on platforms or toolchains see https://bazel.build/concepts/platforms-intro."` A custom error message that is displayed when a mandatory toolchain requirement cannot be satisfied for this target platform. Intended to point to relevant documentation users can read to understand why their toolchains are misconfigured. Not inherited from parent platforms. |
+| `parents` | List of [labels](/versions/8.6.0/concepts/labels); [nonconfigurable](/versions/8.6.0/reference/be/common-definitions#configurable-attributes); default is `[]` The label of a `platform` target that this platform should inherit from. Although the attribute takes a list, there should be no more than one platform present. Any constraint_settings not set directly on this platform will be found in the parent platform. See the section on [Platform Inheritance](#platform_inheritance) for details. |
+| `remote_execution_properties` | String; [nonconfigurable](/versions/8.6.0/reference/be/common-definitions#configurable-attributes); default is `""` DEPRECATED. Please use exec_properties attribute instead. A string used to configure a remote execution platform. Actual builds make no attempt to interpret this, it is treated as opaque data that can be used by a specific SpawnRunner. This can include data from the parent platform's "remote_execution_properties" attribute, by using the macro "{PARENT_REMOTE_EXECUTION_PROPERTIES}". See the section on [Platform Inheritance](#platform_inheritance) for details. |
+| `required_settings` | List of [labels](/versions/8.6.0/concepts/labels); default is `[]` A list of `config_setting`s that must be satisfied by the target configuration in order for this platform to be used as an execution platform during toolchain resolution. Required settings are not inherited from parent platforms. |
 
 ## toolchain
 
@@ -296,20 +296,20 @@ toolchain(name, deprecation, distribs, exec_compatible_with, features, licenses,
 
 This rule declares a specific toolchain's type and constraints so that it can be selected
 during toolchain resolution. See the
-[Toolchains](https://bazel.build/docs/toolchains) page for more
+[Toolchains](https://bazel.build/versions/8.6.0/docs/toolchains) page for more
 details.
 
 ### Arguments
 
 | Attributes | |
 | --- | --- |
-| `name` | [Name](/concepts/labels#target-names); required  A unique name for this target. |
-| `exec_compatible_with` | List of [labels](/concepts/labels); [nonconfigurable](common-definitions#configurable-attributes); default is `[]` A list of `constraint_value`s that must be satisfied by an execution platform in order for this toolchain to be selected for a target building on that platform. |
-| `target_compatible_with` | List of [labels](/concepts/labels); [nonconfigurable](common-definitions#configurable-attributes); default is `[]` A list of `constraint_value`s that must be satisfied by the target platform in order for this toolchain to be selected for a target building for that platform. |
-| `target_settings` | List of [labels](/concepts/labels); default is `[]` A list of `config_setting`s that must be satisfied by the target configuration in order for this toolchain to be selected during toolchain resolution. |
-| `toolchain` | [Name](/concepts/labels#target-names); required The target representing the actual tool or tool suite that is made available when this toolchain is selected. |
-| `toolchain_type` | [Label](/concepts/labels); [nonconfigurable](common-definitions#configurable-attributes); required The label of a `toolchain_type` target that represents the role that this toolchain serves. |
-| `use_target_platform_constraints` | Boolean; [nonconfigurable](common-definitions#configurable-attributes); default is `False` If `True`, this toolchain behaves as if its `exec_compatible_with` and `target_compatible_with` constraints are set to those of the current target platform. `exec_compatible_with` and `target_compatible_with` must not be set in that case. |
+| `name` | [Name](/versions/8.6.0/concepts/labels#target-names); required  A unique name for this target. |
+| `exec_compatible_with` | List of [labels](/versions/8.6.0/concepts/labels); [nonconfigurable](/versions/8.6.0/reference/be/common-definitions#configurable-attributes); default is `[]` A list of `constraint_value`s that must be satisfied by an execution platform in order for this toolchain to be selected for a target building on that platform. |
+| `target_compatible_with` | List of [labels](/versions/8.6.0/concepts/labels); [nonconfigurable](/versions/8.6.0/reference/be/common-definitions#configurable-attributes); default is `[]` A list of `constraint_value`s that must be satisfied by the target platform in order for this toolchain to be selected for a target building for that platform. |
+| `target_settings` | List of [labels](/versions/8.6.0/concepts/labels); default is `[]` A list of `config_setting`s that must be satisfied by the target configuration in order for this toolchain to be selected during toolchain resolution. |
+| `toolchain` | [Name](/versions/8.6.0/concepts/labels#target-names); required The target representing the actual tool or tool suite that is made available when this toolchain is selected. |
+| `toolchain_type` | [Label](/versions/8.6.0/concepts/labels); [nonconfigurable](/versions/8.6.0/reference/be/common-definitions#configurable-attributes); required The label of a `toolchain_type` target that represents the role that this toolchain serves. |
+| `use_target_platform_constraints` | Boolean; [nonconfigurable](/versions/8.6.0/reference/be/common-definitions#configurable-attributes); default is `False` If `True`, this toolchain behaves as if its `exec_compatible_with` and `target_compatible_with` constraints are set to those of the current target platform. `exec_compatible_with` and `target_compatible_with` must not be set in that case. |
 
 ## toolchain_type
 
@@ -322,7 +322,7 @@ toolchain_type(name, compatible_with, deprecation, features, no_match_error, res
 This rule defines a new type of toolchain -- a simple target that represents a class of tools that
 serve the same role for different platforms.
 
-See the [Toolchains](/docs/toolchains) page for more details.
+See the [Toolchains](/versions/8.6.0/docs/toolchains) page for more details.
 
 #### Example
 
@@ -352,5 +352,5 @@ bar_binary = rule(
 
 | Attributes | |
 | --- | --- |
-| `name` | [Name](/concepts/labels#target-names); required  A unique name for this target. |
-| `no_match_error` | String; [nonconfigurable](common-definitions#configurable-attributes); default is `""` A custom error message to display when no matching toolchain is found for this type. |
\ No newline at end of file
+| `name` | [Name](/versions/8.6.0/concepts/labels#target-names); required  A unique name for this target. |
+| `no_match_error` | String; [nonconfigurable](/versions/8.6.0/reference/be/common-definitions#configurable-attributes); default is `""` A custom error message to display when no matching toolchain is found for this type. |
\ No newline at end of file
diff --git a/versions/8.6.0/reference/be/protocol-buffer.mdx b/versions/8.6.0/reference/be/protocol-buffer.mdx
index 17fdbcc2..a3c7f7c6 100644
--- a/versions/8.6.0/reference/be/protocol-buffer.mdx
+++ b/versions/8.6.0/reference/be/protocol-buffer.mdx
@@ -22,7 +22,7 @@ cc_proto_library(name, deps, compatible_with, deprecation, distribs, exec_compat
 
 `cc_proto_library` generates C++ code from `.proto` files.
 
-`deps` must point to [`proto_library`](protocol-buffer#proto_library) rules.
+`deps` must point to [`proto_library`](/versions/8.6.0/reference/be/protocol-buffer#proto_library) rules.
 
 Example:
 
@@ -46,8 +46,8 @@ proto_library(
 
 | Attributes | |
 | --- | --- |
-| `name` | [Name](/concepts/labels#target-names); required  A unique name for this target. |
-| `deps` | List of [labels](/concepts/labels); default is `[]` The list of [`proto_library`](protocol-buffer#proto_library) rules to generate C++ code for. |
+| `name` | [Name](/versions/8.6.0/concepts/labels#target-names); required  A unique name for this target. |
+| `deps` | List of [labels](/versions/8.6.0/concepts/labels); default is `[]` The list of [`proto_library`](/versions/8.6.0/reference/be/protocol-buffer#proto_library) rules to generate C++ code for. |
 
 ## java_lite_proto_library
 
@@ -59,7 +59,7 @@ java_lite_proto_library(name, deps, compatible_with, deprecation, distribs, exec
 
 `java_lite_proto_library` generates Java code from `.proto` files.
 
-`deps` must point to [`proto_library`](protocol-buffer#proto_library) rules.
+`deps` must point to [`proto_library`](/versions/8.6.0/reference/be/protocol-buffer#proto_library) rules.
 
 Example:
 
@@ -83,8 +83,8 @@ proto_library(
 
 | Attributes | |
 | --- | --- |
-| `name` | [Name](/concepts/labels#target-names); required  A unique name for this target. |
-| `deps` | List of [labels](/concepts/labels); default is `[]` The list of [`proto_library`](protocol-buffer#proto_library) rules to generate Java code for. |
+| `name` | [Name](/versions/8.6.0/concepts/labels#target-names); required  A unique name for this target. |
+| `deps` | List of [labels](/versions/8.6.0/concepts/labels); default is `[]` The list of [`proto_library`](/versions/8.6.0/reference/be/protocol-buffer#proto_library) rules to generate Java code for. |
 
 ## java_proto_library
 
@@ -96,7 +96,7 @@ java_proto_library(name, deps, compatible_with, deprecation, distribs, exec_comp
 
 `java_proto_library` generates Java code from `.proto` files.
 
-`deps` must point to [`proto_library`](protocol-buffer#proto_library) rules.
+`deps` must point to [`proto_library`](/versions/8.6.0/reference/be/protocol-buffer#proto_library) rules.
 
 Example:
 
@@ -120,8 +120,8 @@ proto_library(
 
 | Attributes | |
 | --- | --- |
-| `name` | [Name](/concepts/labels#target-names); required  A unique name for this target. |
-| `deps` | List of [labels](/concepts/labels); default is `[]` The list of [`proto_library`](protocol-buffer#proto_library) rules to generate Java code for. |
+| `name` | [Name](/versions/8.6.0/concepts/labels#target-names); required  A unique name for this target. |
+| `deps` | List of [labels](/versions/8.6.0/concepts/labels); default is `[]` The list of [`proto_library`](/versions/8.6.0/reference/be/protocol-buffer#proto_library) rules to generate Java code for. |
 
 ## proto_library
 
@@ -161,11 +161,11 @@ Recommended code organization:
 
 | Attributes | |
 | --- | --- |
-| `name` | [Name](/concepts/labels#target-names); required  A unique name for this target. |
-| `deps` | List of [labels](/concepts/labels); default is `[]` The list of other `proto_library` rules that the target depends upon. A `proto_library` may only depend on other `proto_library` targets. It may not depend on language-specific libraries. |
-| `srcs` | List of [labels](/concepts/labels); default is `[]` The list of `.proto` and `.protodevel` files that are processed to create the target. This is usually a non empty list. One usecase where `srcs` can be empty is an *alias-library*. This is a proto_library rule having one or more other proto_library in `deps`. This pattern can be used to e.g. export a public api under a persistent name. |
-| `allow_exports` | [Label](/concepts/labels); default is `None` An optional allowlist that prevents proto library to be reexported or used in lang_proto_library that is not in one of the listed packages. |
-| `exports` | List of [labels](/concepts/labels); default is `[]` List of proto_library targets that can be referenced via "import public" in the proto source. It's an error if you use "import public" but do not list the corresponding library in the exports attribute. Note that you have list the library both in deps and exports since not all lang_proto_library implementations have been changed yet. |
+| `name` | [Name](/versions/8.6.0/concepts/labels#target-names); required  A unique name for this target. |
+| `deps` | List of [labels](/versions/8.6.0/concepts/labels); default is `[]` The list of other `proto_library` rules that the target depends upon. A `proto_library` may only depend on other `proto_library` targets. It may not depend on language-specific libraries. |
+| `srcs` | List of [labels](/versions/8.6.0/concepts/labels); default is `[]` The list of `.proto` and `.protodevel` files that are processed to create the target. This is usually a non empty list. One usecase where `srcs` can be empty is an *alias-library*. This is a proto_library rule having one or more other proto_library in `deps`. This pattern can be used to e.g. export a public api under a persistent name. |
+| `allow_exports` | [Label](/versions/8.6.0/concepts/labels); default is `None` An optional allowlist that prevents proto library to be reexported or used in lang_proto_library that is not in one of the listed packages. |
+| `exports` | List of [labels](/versions/8.6.0/concepts/labels); default is `[]` List of proto_library targets that can be referenced via "import public" in the proto source. It's an error if you use "import public" but do not list the corresponding library in the exports attribute. Note that you have list the library both in deps and exports since not all lang_proto_library implementations have been changed yet. |
 | `import_prefix` | String; default is `""` The prefix to add to the paths of the .proto files in this rule. When set, the .proto source files in the `srcs` attribute of this rule are accessible at is the value of this attribute prepended to their repository-relative path. The prefix in the `strip_import_prefix` attribute is removed before this prefix is added. |
 | `strip_import_prefix` | String; default is `"/"` The prefix to strip from the paths of the .proto files in this rule. When set, .proto source files in the `srcs` attribute of this rule are accessible at their path with this prefix cut off. If it's a relative path (not starting with a slash), it's taken as a package-relative one. If it's an absolute one, it's understood as a repository-relative path. The prefix in the `import_prefix` attribute is added after this prefix is stripped. |
 
@@ -201,8 +201,8 @@ srcs = ["foo.proto"],
 
 | Attributes | |
 | --- | --- |
-| `name` | [Name](/concepts/labels#target-names); required  A unique name for this target. |
-| `deps` | List of [labels](/concepts/labels); default is `[]` The list of `proto_library` rules to generate Python libraries for. Usually this is just the one target: the proto library of interest. It can be any target providing `ProtoInfo`. |
+| `name` | [Name](/versions/8.6.0/concepts/labels#target-names); required  A unique name for this target. |
+| `deps` | List of [labels](/versions/8.6.0/concepts/labels); default is `[]` The list of `proto_library` rules to generate Python libraries for. Usually this is just the one target: the proto library of interest. It can be any target providing `ProtoInfo`. |
 
 ## proto_lang_toolchain
 
@@ -245,18 +245,18 @@ proto_lang_toolchain(
 
 | Attributes | |
 | --- | --- |
-| `name` | [Name](/concepts/labels#target-names); required  A unique name for this target. |
-| `allowlist_different_package` | [Label](/concepts/labels); default is `None` |
-| `blacklisted_protos` | List of [labels](/concepts/labels); default is `[]` No code will be generated for files in the `srcs` attribute of `blacklisted_protos`. This is used for .proto files that are already linked into proto runtimes, such as `any.proto`. |
+| `name` | [Name](/versions/8.6.0/concepts/labels#target-names); required  A unique name for this target. |
+| `allowlist_different_package` | [Label](/versions/8.6.0/concepts/labels); default is `None` |
+| `blacklisted_protos` | List of [labels](/versions/8.6.0/concepts/labels); default is `[]` No code will be generated for files in the `srcs` attribute of `blacklisted_protos`. This is used for .proto files that are already linked into proto runtimes, such as `any.proto`. |
 | `command_line` | String; required This value will be passed to proto-compiler to generate the code. Only include the parts specific to this code-generator/plugin (e.g., do not include -I parameters)  * `$(OUT)` is LANG_proto_library-specific. The rules are expected to define   how they interpret this variable. For Java, for example, $(OUT) will be replaced with   the src-jar filename to create. |
 | `mnemonic` | String; default is `"GenProto"` This value will be set as the mnemonic on protoc action. |
 | `output_files` | String; default is `"legacy"` Controls how `$(OUT)` in `command_line` is formatted, either by a path to a single file or output directory in case of multiple files. Possible values are: "single", "multiple". |
-| `plugin` | [Label](/concepts/labels); default is `None` If provided, will be made available to the action that calls the proto-compiler, and will be passed to the proto-compiler: `--plugin=protoc-gen-PLUGIN=<executable>.` |
+| `plugin` | [Label](/versions/8.6.0/concepts/labels); default is `None` If provided, will be made available to the action that calls the proto-compiler, and will be passed to the proto-compiler: `--plugin=protoc-gen-PLUGIN=<executable>.` |
 | `plugin_format_flag` | String; default is `""` If provided, this value will be passed to proto-compiler to use the plugin. The value must contain a single %s which is replaced with plugin executable. `--plugin=protoc-gen-PLUGIN=<executable>.` |
 | `progress_message` | String; default is `"Generating proto_library %{label}"` This value will be set as the progress message on protoc action. |
-| `protoc_minimal_do_not_use` | [Label](/concepts/labels); default is `None` |
-| `runtime` | [Label](/concepts/labels); default is `None` A language-specific library that the generated code is compiled against. The exact behavior is LANG_proto_library-specific. Java, for example, should compile against the runtime. |
-| `toolchain_type` | [Label](/concepts/labels); default is `None` |
+| `protoc_minimal_do_not_use` | [Label](/versions/8.6.0/concepts/labels); default is `None` |
+| `runtime` | [Label](/versions/8.6.0/concepts/labels); default is `None` A language-specific library that the generated code is compiled against. The exact behavior is LANG_proto_library-specific. Java, for example, should compile against the runtime. |
+| `toolchain_type` | [Label](/versions/8.6.0/concepts/labels); default is `None` |
 
 ## proto_toolchain
 
@@ -270,9 +270,9 @@ proto_toolchain(name, command_line, compatible_with, deprecation, distribs, exec
 
 | Attributes | |
 | --- | --- |
-| `name` | [Name](/concepts/labels#target-names); required  A unique name for this target. |
+| `name` | [Name](/versions/8.6.0/concepts/labels#target-names); required  A unique name for this target. |
 | `command_line` | String; default is `"--descriptor_set_out=%s"` |
 | `mnemonic` | String; default is `"GenProtoDescriptorSet"` |
 | `output_files` | String; default is `"single"` |
 | `progress_message` | String; default is `"Generating Descriptor Set proto_library %{label}"` |
-| `proto_compiler` | [Label](/concepts/labels); default is `None` |
\ No newline at end of file
+| `proto_compiler` | [Label](/versions/8.6.0/concepts/labels); default is `None` |
\ No newline at end of file
diff --git a/versions/8.6.0/reference/be/python.mdx b/versions/8.6.0/reference/be/python.mdx
index bbdb5471..32ee67b6 100644
--- a/versions/8.6.0/reference/be/python.mdx
+++ b/versions/8.6.0/reference/be/python.mdx
@@ -21,14 +21,14 @@ py_binary(name, deps, srcs, data, args, compatible_with, deprecation, distribs,
 
 | Attributes | |
 | --- | --- |
-| `name` | [Name](/concepts/labels#target-names); required  A unique name for this target. |
-| `deps` | List of [labels](/concepts/labels); default is `[]` List of additional libraries to be linked in to the target. See comments about the [`deps` attribute typically defined by rules](https://bazel.build/reference/be/common-definitions#typical-attributes). These are typically `py_library` rules. Targets that only provide data files used at runtime belong in the `data` attribute. |
-| `srcs` | List of [labels](/concepts/labels); required The list of Python source files that are processed to create the target. This includes all your checked-in code and may include generated source files. The `.py` files belong in `srcs` and library targets belong in `deps`. Other binary files that may be needed at run time belong in `data`. |
-| `data` | List of [labels](/concepts/labels); default is `[]` The list of files need by this library at runtime. See comments about the [`data` attribute typically defined by rules](https://bazel.build/reference/be/common-definitions#typical-attributes). There is no `py_embed_data` like there is `cc_embed_data` and `go_embed_data`. This is because Python has a concept of runtime resources. |
+| `name` | [Name](/versions/8.6.0/concepts/labels#target-names); required  A unique name for this target. |
+| `deps` | List of [labels](/versions/8.6.0/concepts/labels); default is `[]` List of additional libraries to be linked in to the target. See comments about the [`deps` attribute typically defined by rules](https://bazel.build/versions/8.6.0/reference/be/common-definitions#typical-attributes). These are typically `py_library` rules. Targets that only provide data files used at runtime belong in the `data` attribute. |
+| `srcs` | List of [labels](/versions/8.6.0/concepts/labels); required The list of Python source files that are processed to create the target. This includes all your checked-in code and may include generated source files. The `.py` files belong in `srcs` and library targets belong in `deps`. Other binary files that may be needed at run time belong in `data`. |
+| `data` | List of [labels](/versions/8.6.0/concepts/labels); default is `[]` The list of files need by this library at runtime. See comments about the [`data` attribute typically defined by rules](https://bazel.build/versions/8.6.0/reference/be/common-definitions#typical-attributes). There is no `py_embed_data` like there is `cc_embed_data` and `go_embed_data`. This is because Python has a concept of runtime resources. |
 | `imports` | List of strings; default is `[]` List of import directories to be added to the PYTHONPATH. Subject to "Make variable" substitution. These import directories will be added for this rule and all rules that depend on it (note: not the rules this rule depends on. Each directory will be added to `PYTHONPATH` by `py_binary` rules that depend on this rule. The strings are repo-runfiles-root relative, Absolute paths (paths that start with `/`) and paths that references a path above the execution root are not allowed and will result in an error. |
 | `legacy_create_init` | Integer; default is `-1` Whether to implicitly create empty `\__init\_\_.py` files in the runfiles tree. These are created in every directory containing Python source code or shared libraries, and every parent directory of those directories, excluding the repo root directory. The default, `-1` (auto), means true unless `--incompatible_default_to_explicit_init_py` is used. If false, the user is responsible for creating (possibly empty) `\__init\_\_.py` files and adding them to the `srcs` of Python targets as required. |
-| `main` | [Label](/concepts/labels); default is `None` Optional; the name of the source file that is the main entry point of the application. This file must also be listed in `srcs`. If left unspecified, `name`, with `.py` appended, is used instead. If `name` does not match any filename in `srcs`, `main` must be specified. |
-| `precompile` | String; default is `"inherit"` Whether py source files \*\*for this target\*\* should be precompiled. Values: \* `inherit`: Allow the downstream binary decide if precompiled files are used. \* `enabled`: Compile Python source files at build time. \* `disabled`: Don't compile Python source files at build time. :::{seealso} \* The {flag}`--precompile` flag, which can override this attribute in some cases and will affect all targets when building. \* The {obj}`pyc_collection` attribute for transitively enabling precompiling on a per-target basis. \* The [Precompiling](precompiling) docs for a guide about using precompiling. ::: |
+| `main` | [Label](/versions/8.6.0/concepts/labels); default is `None` Optional; the name of the source file that is the main entry point of the application. This file must also be listed in `srcs`. If left unspecified, `name`, with `.py` appended, is used instead. If `name` does not match any filename in `srcs`, `main` must be specified. |
+| `precompile` | String; default is `"inherit"` Whether py source files \*\*for this target\*\* should be precompiled. Values: \* `inherit`: Allow the downstream binary decide if precompiled files are used. \* `enabled`: Compile Python source files at build time. \* `disabled`: Don't compile Python source files at build time. :::{seealso} \* The {flag}`--precompile` flag, which can override this attribute in some cases and will affect all targets when building. \* The {obj}`pyc_collection` attribute for transitively enabling precompiling on a per-target basis. \* The [Precompiling](/versions/8.6.0/reference/be/precompiling) docs for a guide about using precompiling. ::: |
 | `precompile_invalidation_mode` | String; default is `"auto"` How precompiled files should be verified to be up-to-date with their associated source files. Possible values are: \* `auto`: The effective value will be automatically determined by other build settings. \* `checked_hash`: Use the pyc file if the hash of the source file matches the hash recorded in the pyc file. This is most useful when working with code that you may modify. \* `unchecked_hash`: Always use the pyc file; don't check the pyc's hash against the source file. This is most useful when the code won't be modified. For more information on pyc invalidation modes, see https://docs.python.org/3/library/py_compile.html#py_compile.PycInvalidationMode |
 | `precompile_optimize_level` | Integer; default is `0` The optimization level for precompiled files. For more information about optimization levels, see the `compile()` function's `optimize` arg docs at https://docs.python.org/3/library/functions.html#compile NOTE: The value `-1` means "current interpreter", which will be the interpreter used \_at build time when pycs are generated\_, not the interpreter used at runtime when the code actually runs. |
 | `precompile_source_retention` | String; default is `"inherit"` Determines, when a source file is compiled, if the source file is kept in the resulting output or not. Valid values are: \* `inherit`: Inherit the value from the {flag}`--precompile_source_retention` flag. \* `keep_source`: Include the original Python source. \* `omit_source`: Don't include the original py source. |
@@ -60,12 +60,12 @@ Source files are no longer added to the runfiles directly.
 
 | Attributes | |
 | --- | --- |
-| `name` | [Name](/concepts/labels#target-names); required  A unique name for this target. |
-| `deps` | List of [labels](/concepts/labels); default is `[]` List of additional libraries to be linked in to the target. See comments about the [`deps` attribute typically defined by rules](https://bazel.build/reference/be/common-definitions#typical-attributes). These are typically `py_library` rules. Targets that only provide data files used at runtime belong in the `data` attribute. |
-| `srcs` | List of [labels](/concepts/labels); default is `[]` The list of Python source files that are processed to create the target. This includes all your checked-in code and may include generated source files. The `.py` files belong in `srcs` and library targets belong in `deps`. Other binary files that may be needed at run time belong in `data`. |
-| `data` | List of [labels](/concepts/labels); default is `[]` The list of files need by this library at runtime. See comments about the [`data` attribute typically defined by rules](https://bazel.build/reference/be/common-definitions#typical-attributes). There is no `py_embed_data` like there is `cc_embed_data` and `go_embed_data`. This is because Python has a concept of runtime resources. |
+| `name` | [Name](/versions/8.6.0/concepts/labels#target-names); required  A unique name for this target. |
+| `deps` | List of [labels](/versions/8.6.0/concepts/labels); default is `[]` List of additional libraries to be linked in to the target. See comments about the [`deps` attribute typically defined by rules](https://bazel.build/versions/8.6.0/reference/be/common-definitions#typical-attributes). These are typically `py_library` rules. Targets that only provide data files used at runtime belong in the `data` attribute. |
+| `srcs` | List of [labels](/versions/8.6.0/concepts/labels); default is `[]` The list of Python source files that are processed to create the target. This includes all your checked-in code and may include generated source files. The `.py` files belong in `srcs` and library targets belong in `deps`. Other binary files that may be needed at run time belong in `data`. |
+| `data` | List of [labels](/versions/8.6.0/concepts/labels); default is `[]` The list of files need by this library at runtime. See comments about the [`data` attribute typically defined by rules](https://bazel.build/versions/8.6.0/reference/be/common-definitions#typical-attributes). There is no `py_embed_data` like there is `cc_embed_data` and `go_embed_data`. This is because Python has a concept of runtime resources. |
 | `imports` | List of strings; default is `[]` List of import directories to be added to the PYTHONPATH. Subject to "Make variable" substitution. These import directories will be added for this rule and all rules that depend on it (note: not the rules this rule depends on. Each directory will be added to `PYTHONPATH` by `py_binary` rules that depend on this rule. The strings are repo-runfiles-root relative, Absolute paths (paths that start with `/`) and paths that references a path above the execution root are not allowed and will result in an error. |
-| `precompile` | String; default is `"inherit"` Whether py source files \*\*for this target\*\* should be precompiled. Values: \* `inherit`: Allow the downstream binary decide if precompiled files are used. \* `enabled`: Compile Python source files at build time. \* `disabled`: Don't compile Python source files at build time. :::{seealso} \* The {flag}`--precompile` flag, which can override this attribute in some cases and will affect all targets when building. \* The {obj}`pyc_collection` attribute for transitively enabling precompiling on a per-target basis. \* The [Precompiling](precompiling) docs for a guide about using precompiling. ::: |
+| `precompile` | String; default is `"inherit"` Whether py source files \*\*for this target\*\* should be precompiled. Values: \* `inherit`: Allow the downstream binary decide if precompiled files are used. \* `enabled`: Compile Python source files at build time. \* `disabled`: Don't compile Python source files at build time. :::{seealso} \* The {flag}`--precompile` flag, which can override this attribute in some cases and will affect all targets when building. \* The {obj}`pyc_collection` attribute for transitively enabling precompiling on a per-target basis. \* The [Precompiling](/versions/8.6.0/reference/be/precompiling) docs for a guide about using precompiling. ::: |
 | `precompile_invalidation_mode` | String; default is `"auto"` How precompiled files should be verified to be up-to-date with their associated source files. Possible values are: \* `auto`: The effective value will be automatically determined by other build settings. \* `checked_hash`: Use the pyc file if the hash of the source file matches the hash recorded in the pyc file. This is most useful when working with code that you may modify. \* `unchecked_hash`: Always use the pyc file; don't check the pyc's hash against the source file. This is most useful when the code won't be modified. For more information on pyc invalidation modes, see https://docs.python.org/3/library/py_compile.html#py_compile.PycInvalidationMode |
 | `precompile_optimize_level` | Integer; default is `0` The optimization level for precompiled files. For more information about optimization levels, see the `compile()` function's `optimize` arg docs at https://docs.python.org/3/library/functions.html#compile NOTE: The value `-1` means "current interpreter", which will be the interpreter used \_at build time when pycs are generated\_, not the interpreter used at runtime when the code actually runs. |
 | `precompile_source_retention` | String; default is `"inherit"` Determines, when a source file is compiled, if the source file is kept in the resulting output or not. Valid values are: \* `inherit`: Inherit the value from the {flag}`--precompile_source_retention` flag. \* `keep_source`: Include the original Python source. \* `omit_source`: Don't include the original py source. |
@@ -83,14 +83,14 @@ py_test(name, deps, srcs, data, args, compatible_with, deprecation, distribs, en
 
 | Attributes | |
 | --- | --- |
-| `name` | [Name](/concepts/labels#target-names); required  A unique name for this target. |
-| `deps` | List of [labels](/concepts/labels); default is `[]` List of additional libraries to be linked in to the target. See comments about the [`deps` attribute typically defined by rules](https://bazel.build/reference/be/common-definitions#typical-attributes). These are typically `py_library` rules. Targets that only provide data files used at runtime belong in the `data` attribute. |
-| `srcs` | List of [labels](/concepts/labels); required The list of Python source files that are processed to create the target. This includes all your checked-in code and may include generated source files. The `.py` files belong in `srcs` and library targets belong in `deps`. Other binary files that may be needed at run time belong in `data`. |
-| `data` | List of [labels](/concepts/labels); default is `[]` The list of files need by this library at runtime. See comments about the [`data` attribute typically defined by rules](https://bazel.build/reference/be/common-definitions#typical-attributes). There is no `py_embed_data` like there is `cc_embed_data` and `go_embed_data`. This is because Python has a concept of runtime resources. |
+| `name` | [Name](/versions/8.6.0/concepts/labels#target-names); required  A unique name for this target. |
+| `deps` | List of [labels](/versions/8.6.0/concepts/labels); default is `[]` List of additional libraries to be linked in to the target. See comments about the [`deps` attribute typically defined by rules](https://bazel.build/versions/8.6.0/reference/be/common-definitions#typical-attributes). These are typically `py_library` rules. Targets that only provide data files used at runtime belong in the `data` attribute. |
+| `srcs` | List of [labels](/versions/8.6.0/concepts/labels); required The list of Python source files that are processed to create the target. This includes all your checked-in code and may include generated source files. The `.py` files belong in `srcs` and library targets belong in `deps`. Other binary files that may be needed at run time belong in `data`. |
+| `data` | List of [labels](/versions/8.6.0/concepts/labels); default is `[]` The list of files need by this library at runtime. See comments about the [`data` attribute typically defined by rules](https://bazel.build/versions/8.6.0/reference/be/common-definitions#typical-attributes). There is no `py_embed_data` like there is `cc_embed_data` and `go_embed_data`. This is because Python has a concept of runtime resources. |
 | `imports` | List of strings; default is `[]` List of import directories to be added to the PYTHONPATH. Subject to "Make variable" substitution. These import directories will be added for this rule and all rules that depend on it (note: not the rules this rule depends on. Each directory will be added to `PYTHONPATH` by `py_binary` rules that depend on this rule. The strings are repo-runfiles-root relative, Absolute paths (paths that start with `/`) and paths that references a path above the execution root are not allowed and will result in an error. |
 | `legacy_create_init` | Integer; default is `-1` Whether to implicitly create empty `\__init\_\_.py` files in the runfiles tree. These are created in every directory containing Python source code or shared libraries, and every parent directory of those directories, excluding the repo root directory. The default, `-1` (auto), means true unless `--incompatible_default_to_explicit_init_py` is used. If false, the user is responsible for creating (possibly empty) `\__init\_\_.py` files and adding them to the `srcs` of Python targets as required. |
-| `main` | [Label](/concepts/labels); default is `None` Optional; the name of the source file that is the main entry point of the application. This file must also be listed in `srcs`. If left unspecified, `name`, with `.py` appended, is used instead. If `name` does not match any filename in `srcs`, `main` must be specified. |
-| `precompile` | String; default is `"inherit"` Whether py source files \*\*for this target\*\* should be precompiled. Values: \* `inherit`: Allow the downstream binary decide if precompiled files are used. \* `enabled`: Compile Python source files at build time. \* `disabled`: Don't compile Python source files at build time. :::{seealso} \* The {flag}`--precompile` flag, which can override this attribute in some cases and will affect all targets when building. \* The {obj}`pyc_collection` attribute for transitively enabling precompiling on a per-target basis. \* The [Precompiling](precompiling) docs for a guide about using precompiling. ::: |
+| `main` | [Label](/versions/8.6.0/concepts/labels); default is `None` Optional; the name of the source file that is the main entry point of the application. This file must also be listed in `srcs`. If left unspecified, `name`, with `.py` appended, is used instead. If `name` does not match any filename in `srcs`, `main` must be specified. |
+| `precompile` | String; default is `"inherit"` Whether py source files \*\*for this target\*\* should be precompiled. Values: \* `inherit`: Allow the downstream binary decide if precompiled files are used. \* `enabled`: Compile Python source files at build time. \* `disabled`: Don't compile Python source files at build time. :::{seealso} \* The {flag}`--precompile` flag, which can override this attribute in some cases and will affect all targets when building. \* The {obj}`pyc_collection` attribute for transitively enabling precompiling on a per-target basis. \* The [Precompiling](/versions/8.6.0/reference/be/precompiling) docs for a guide about using precompiling. ::: |
 | `precompile_invalidation_mode` | String; default is `"auto"` How precompiled files should be verified to be up-to-date with their associated source files. Possible values are: \* `auto`: The effective value will be automatically determined by other build settings. \* `checked_hash`: Use the pyc file if the hash of the source file matches the hash recorded in the pyc file. This is most useful when working with code that you may modify. \* `unchecked_hash`: Always use the pyc file; don't check the pyc's hash against the source file. This is most useful when the code won't be modified. For more information on pyc invalidation modes, see https://docs.python.org/3/library/py_compile.html#py_compile.PycInvalidationMode |
 | `precompile_optimize_level` | Integer; default is `0` The optimization level for precompiled files. For more information about optimization levels, see the `compile()` function's `optimize` arg docs at https://docs.python.org/3/library/functions.html#compile NOTE: The value `-1` means "current interpreter", which will be the interpreter used \_at build time when pycs are generated\_, not the interpreter used at runtime when the code actually runs. |
 | `precompile_source_retention` | String; default is `"inherit"` Determines, when a source file is compiled, if the source file is kept in the resulting output or not. Valid values are: \* `inherit`: Inherit the value from the {flag}`--precompile_source_retention` flag. \* `keep_source`: Include the original Python source. \* `omit_source`: Don't include the original py source. |
@@ -137,17 +137,17 @@ interpreter_path = "/opt/pyenv/versions/3.6.0/bin/python",
 
 | Attributes | |
 | --- | --- |
-| `name` | [Name](/concepts/labels#target-names); required  A unique name for this target. |
+| `name` | [Name](/versions/8.6.0/concepts/labels#target-names); required  A unique name for this target. |
 | `abi_flags` | String; default is `""` The runtime's ABI flags, i.e. `sys.abiflags`. If not set, then it will be set based on flags. |
-| `bootstrap_template` | [Label](/concepts/labels); default is `"@rules_python//python/private:bootstrap_template"` The bootstrap script template file to use. Should have %python_binary%, %workspace_name%, %main%, and %imports%. This template, after expansion, becomes the executable file used to start the process, so it is responsible for initial bootstrapping actions such as finding the Python interpreter, runfiles, and constructing an environment to run the intended Python application. While this attribute is currently optional, it will become required when the Python rules are moved out of Bazel itself. The exact variable names expanded is an unstable API and is subject to change. The API will become more stable when the Python rules are moved out of Bazel itself. See @bazel_tools//tools/python:python_bootstrap_template.txt for more variables. |
-| `coverage_tool` | [Label](/concepts/labels); default is `None` This is a target to use for collecting code coverage information from {rule}`py_binary` and {rule}`py_test` targets. If set, the target must either produce a single file or be an executable target. The path to the single file, or the executable if the target is executable, determines the entry point for the python coverage tool. The target and its runfiles will be added to the runfiles when coverage is enabled. The entry point for the tool must be loadable by a Python interpreter (e.g. a `.py` or `.pyc` file). It must accept the command line arguments of [`coverage.py`](https://coverage.readthedocs.io), at least including the `run` and `lcov` subcommands. |
-| `files` | List of [labels](/concepts/labels); default is `[]` For an in-build runtime, this is the set of files comprising this runtime. These files will be added to the runfiles of Python binaries that use this runtime. For a platform runtime this attribute must not be set. |
+| `bootstrap_template` | [Label](/versions/8.6.0/concepts/labels); default is `"@rules_python//python/private:bootstrap_template"` The bootstrap script template file to use. Should have %python_binary%, %workspace_name%, %main%, and %imports%. This template, after expansion, becomes the executable file used to start the process, so it is responsible for initial bootstrapping actions such as finding the Python interpreter, runfiles, and constructing an environment to run the intended Python application. While this attribute is currently optional, it will become required when the Python rules are moved out of Bazel itself. The exact variable names expanded is an unstable API and is subject to change. The API will become more stable when the Python rules are moved out of Bazel itself. See @bazel_tools//tools/python:python_bootstrap_template.txt for more variables. |
+| `coverage_tool` | [Label](/versions/8.6.0/concepts/labels); default is `None` This is a target to use for collecting code coverage information from {rule}`py_binary` and {rule}`py_test` targets. If set, the target must either produce a single file or be an executable target. The path to the single file, or the executable if the target is executable, determines the entry point for the python coverage tool. The target and its runfiles will be added to the runfiles when coverage is enabled. The entry point for the tool must be loadable by a Python interpreter (e.g. a `.py` or `.pyc` file). It must accept the command line arguments of [`coverage.py`](https://coverage.readthedocs.io), at least including the `run` and `lcov` subcommands. |
+| `files` | List of [labels](/versions/8.6.0/concepts/labels); default is `[]` For an in-build runtime, this is the set of files comprising this runtime. These files will be added to the runfiles of Python binaries that use this runtime. For a platform runtime this attribute must not be set. |
 | `implementation_name` | String; default is `"cpython"` The Python implementation name (`sys.implementation.name`) |
-| `interpreter` | [Label](/concepts/labels); default is `None` For an in-build runtime, this is the target to invoke as the interpreter. It can be either of: \* A single file, which will be the interpreter binary. It's assumed such interpreters are either self-contained single-file executables or any supporting files are specified in `files`. \* An executable target. The target's executable will be the interpreter binary. Any other default outputs (`target.files`) and plain files runfiles (`runfiles.files`) will be automatically included as if specified in the `files` attribute. NOTE: the runfiles of the target may not yet be properly respected/propagated to consumers of the toolchain/interpreter, see bazelbuild/rules_python/issues/1612 For a platform runtime (i.e. `interpreter_path` being set) this attribute must not be set. |
+| `interpreter` | [Label](/versions/8.6.0/concepts/labels); default is `None` For an in-build runtime, this is the target to invoke as the interpreter. It can be either of: \* A single file, which will be the interpreter binary. It's assumed such interpreters are either self-contained single-file executables or any supporting files are specified in `files`. \* An executable target. The target's executable will be the interpreter binary. Any other default outputs (`target.files`) and plain files runfiles (`runfiles.files`) will be automatically included as if specified in the `files` attribute. NOTE: the runfiles of the target may not yet be properly respected/propagated to consumers of the toolchain/interpreter, see bazelbuild/rules_python/issues/1612 For a platform runtime (i.e. `interpreter_path` being set) this attribute must not be set. |
 | `interpreter_path` | String; default is `""` For a platform runtime, this is the absolute path of a Python interpreter on the target platform. For an in-build runtime this attribute must not be set. |
 | `interpreter_version_info` | Dictionary: String -> String; default is `{}` Version information about the interpreter this runtime provides. If not specified, uses {obj}`--python_version` The supported keys match the names for `sys.version_info`. While the input values are strings, most are converted to ints. The supported keys are: \* major: int, the major version number \* minor: int, the minor version number \* micro: optional int, the micro version number \* releaselevel: optional str, the release level \* serial: optional int, the serial number of the release :::{versionchanged} 0.36.0 {obj}`--python_version` determines the default value. ::: |
 | `pyc_tag` | String; default is `""` Optional string; the tag portion of a pyc filename, e.g. the `cpython-39` infix of `foo.cpython-39.pyc`. See PEP 3147. If not specified, it will be computed from `implementation_name` and `interpreter_version_info`. If no pyc_tag is available, then only source-less pyc generation will function correctly. |
 | `python_version` | String; default is `"PY3"` Whether this runtime is for Python major version 2 or 3. Valid values are `"PY2"` and `"PY3"`. The default value is controlled by the `--incompatible_py3_is_default` flag. However, in the future this attribute will be mandatory and have no default value. |
-| `stage2_bootstrap_template` | [Label](/concepts/labels); default is `"@rules_python//python/private:stage2_bootstrap_template"` The template to use when two stage bootstrapping is enabled :::{seealso} {obj}`PyRuntimeInfo.stage2_bootstrap_template` and {obj}`--bootstrap_impl` ::: |
+| `stage2_bootstrap_template` | [Label](/versions/8.6.0/concepts/labels); default is `"@rules_python//python/private:stage2_bootstrap_template"` The template to use when two stage bootstrapping is enabled :::{seealso} {obj}`PyRuntimeInfo.stage2_bootstrap_template` and {obj}`--bootstrap_impl` ::: |
 | `stub_shebang` | String; default is `"#!/usr/bin/env python3"` "Shebang" expression prepended to the bootstrapping Python stub script used when executing {rule}`py_binary` targets. See https://github.com/bazelbuild/bazel/issues/8685 for motivation. Does not apply to Windows. |
-| `zip_main_template` | [Label](/concepts/labels); default is `"@rules_python//python/private:zip_main_template"` The template to use for a zip's top-level `\__main\_\_.py` file. This becomes the entry point executed when `python foo.zip` is run. :::{seealso} The {obj}`PyRuntimeInfo.zip_main_template` field. ::: |
\ No newline at end of file
+| `zip_main_template` | [Label](/versions/8.6.0/concepts/labels); default is `"@rules_python//python/private:zip_main_template"` The template to use for a zip's top-level `\__main\_\_.py` file. This becomes the entry point executed when `python foo.zip` is run. :::{seealso} The {obj}`PyRuntimeInfo.zip_main_template` field. ::: |
\ No newline at end of file
diff --git a/versions/8.6.0/reference/be/shell.mdx b/versions/8.6.0/reference/be/shell.mdx
index 3dba5980..a9f45251 100644
--- a/versions/8.6.0/reference/be/shell.mdx
+++ b/versions/8.6.0/reference/be/shell.mdx
@@ -40,9 +40,9 @@ sh_binary(
 
 | Attributes | |
 | --- | --- |
-| `name` | [Name](/concepts/labels#target-names); required  A unique name for this target. |
-| `deps` | List of [labels](/concepts/labels); default is `[]` The list of "library" targets to be aggregated into this target. See general comments about `deps` at [Typical attributes defined by most build rules](/reference/be/common-definitions#typical.deps). This attribute should be used to list other `sh_library` rules that provide interpreted program source code depended on by the code in `srcs`. The files provided by these rules will be present among the `runfiles` of this target. |
-| `srcs` | List of [labels](/concepts/labels); default is `[]` The list of input files. This attribute should be used to list shell script source files that belong to this library. Scripts can load other scripts using the shell's `source` or `.` command. |
+| `name` | [Name](/versions/8.6.0/concepts/labels#target-names); required  A unique name for this target. |
+| `deps` | List of [labels](/versions/8.6.0/concepts/labels); default is `[]` The list of "library" targets to be aggregated into this target. See general comments about `deps` at [Typical attributes defined by most build rules](/versions/8.6.0/reference/be/common-definitions#typical.deps). This attribute should be used to list other `sh_library` rules that provide interpreted program source code depended on by the code in `srcs`. The files provided by these rules will be present among the `runfiles` of this target. |
+| `srcs` | List of [labels](/versions/8.6.0/concepts/labels); default is `[]` The list of input files. This attribute should be used to list shell script source files that belong to this library. Scripts can load other scripts using the shell's `source` or `.` command. |
 | `env_inherit` | List of strings; default is `[]` |
 
 ## sh_library
@@ -61,7 +61,7 @@ run-time. Such "libraries" can then be used from
 the `data` attribute of one or
 more `sh_binary` rules.
 
-You can use the [`filegroup`](/reference/be/general#filegroup) rule to aggregate data
+You can use the [`filegroup`](/versions/8.6.0/reference/be/general#filegroup) rule to aggregate data
 files.
 
 In interpreted programming languages, there's not always a clear
@@ -89,9 +89,9 @@ sh_library(
 
 | Attributes | |
 | --- | --- |
-| `name` | [Name](/concepts/labels#target-names); required  A unique name for this target. |
-| `deps` | List of [labels](/concepts/labels); default is `[]` The list of "library" targets to be aggregated into this target. See general comments about `deps` at [Typical attributes defined by most build rules](/reference/be/common-definitions#typical.deps). This attribute should be used to list other `sh_library` rules that provide interpreted program source code depended on by the code in `srcs`. The files provided by these rules will be present among the `runfiles` of this target. |
-| `srcs` | List of [labels](/concepts/labels); default is `[]` The list of input files. This attribute should be used to list shell script source files that belong to this library. Scripts can load other scripts using the shell's `source` or `.` command. |
+| `name` | [Name](/versions/8.6.0/concepts/labels#target-names); required  A unique name for this target. |
+| `deps` | List of [labels](/versions/8.6.0/concepts/labels); default is `[]` The list of "library" targets to be aggregated into this target. See general comments about `deps` at [Typical attributes defined by most build rules](/versions/8.6.0/reference/be/common-definitions#typical.deps). This attribute should be used to list other `sh_library` rules that provide interpreted program source code depended on by the code in `srcs`. The files provided by these rules will be present among the `runfiles` of this target. |
+| `srcs` | List of [labels](/versions/8.6.0/concepts/labels); default is `[]` The list of input files. This attribute should be used to list shell script source files that belong to this library. Scripts can load other scripts using the shell's `source` or `.` command. |
 
 ## sh_test
 
@@ -125,6 +125,6 @@ sh_binary(
 
 | Attributes | |
 | --- | --- |
-| `name` | [Name](/concepts/labels#target-names); required  A unique name for this target. |
-| `deps` | List of [labels](/concepts/labels); default is `[]` The list of "library" targets to be aggregated into this target. See general comments about `deps` at [Typical attributes defined by most build rules](/reference/be/common-definitions#typical.deps). This attribute should be used to list other `sh_library` rules that provide interpreted program source code depended on by the code in `srcs`. The files provided by these rules will be present among the `runfiles` of this target. |
-| `srcs` | List of [labels](/concepts/labels); default is `[]` The list of input files. This attribute should be used to list shell script source files that belong to this library. Scripts can load other scripts using the shell's `source` or `.` command. |
\ No newline at end of file
+| `name` | [Name](/versions/8.6.0/concepts/labels#target-names); required  A unique name for this target. |
+| `deps` | List of [labels](/versions/8.6.0/concepts/labels); default is `[]` The list of "library" targets to be aggregated into this target. See general comments about `deps` at [Typical attributes defined by most build rules](/versions/8.6.0/reference/be/common-definitions#typical.deps). This attribute should be used to list other `sh_library` rules that provide interpreted program source code depended on by the code in `srcs`. The files provided by these rules will be present among the `runfiles` of this target. |
+| `srcs` | List of [labels](/versions/8.6.0/concepts/labels); default is `[]` The list of input files. This attribute should be used to list shell script source files that belong to this library. Scripts can load other scripts using the shell's `source` or `.` command. |
\ No newline at end of file
diff --git a/versions/8.6.0/reference/be/workspace.mdx b/versions/8.6.0/reference/be/workspace.mdx
index 6fa7eec2..28d58eb3 100644
--- a/versions/8.6.0/reference/be/workspace.mdx
+++ b/versions/8.6.0/reference/be/workspace.mdx
@@ -2,11 +2,11 @@
 title: 'Workspace Rules'
 ---
 
-Workspace rules are used to pull in [external dependencies](/docs/external), typically
+Workspace rules are used to pull in [external dependencies](/versions/8.6.0/docs/external), typically
 source code located outside the main repository.
 
 *Note:* besides the native workspace rules, Bazel also embeds various
-[Starlark workspace rules](/rules/lib/repo/index), in particular those to deal
+[Starlark workspace rules](/versions/8.6.0/rules/lib/repo/index), in particular those to deal
 with git repositories or archives hosted on the web.
 
 ## Rules
@@ -25,10 +25,9 @@ bind(name, actual, compatible_with, deprecation, distribs, features, licenses, r
 
 *Warning: use of `bind()` is not recommended. See "[Consider removing bind](https://github.com/bazelbuild/bazel/issues/1952)" for a long
 discussion of its issues and alternatives. In particular, consider the use of
-[`repo_mapping`
-repository attributes](https://bazel.build/rules/repository_rules#attributes).*
+[`repo_mapping` repository attributes](https://bazel.build/versions/8.6.0/rules/repository_rules#attributes).*
 
-*Warning: `select()` cannot be used in `bind()`. See the [Configurable Attributes FAQ](/docs/configurable-attributes#bind-select) for
+*Warning: `select()` cannot be used in `bind()`. See the [Configurable Attributes FAQ](/versions/8.6.0/docs/configurable-attributes#bind-select) for
 details.*
 
 Gives a target an alias in the `//external` package.
@@ -102,8 +101,8 @@ Then `sign_in.cc`'s includes might look like this:
 
 | Attributes | |
 | --- | --- |
-| `name` | [Name](/concepts/labels#target-names); required  A unique name for this target. |
-| `actual` | [Label](/concepts/labels); default is `None` The target to be aliased. This target must exist, but can be any type of rule (including bind).  If this attribute is omitted, rules referring to this target in `//external` will simply not see this dependency edge. Note that this is different from omitting the `bind` rule completely: it is an error if an `//external` dependency does not have an associated `bind` rule. |
+| `name` | [Name](/versions/8.6.0/concepts/labels#target-names); required  A unique name for this target. |
+| `actual` | [Label](/versions/8.6.0/concepts/labels); default is `None` The target to be aliased. This target must exist, but can be any type of rule (including bind).  If this attribute is omitted, rules referring to this target in `//external` will simply not see this dependency edge. Note that this is different from omitting the `bind` rule completely: it is an error if an `//external` dependency does not have an associated `bind` rule. |
 
 ## local_repository
 
@@ -114,8 +113,7 @@ local_repository(name, path, repo_mapping)
 ```
 
 Allows targets from a local directory to be bound. This means that the current repository can
-use targets defined in this other directory. See the [bind
-section](/reference/be/workspace#bind_examples) for more details.
+use targets defined in this other directory. See the [bind section](/versions/8.6.0/reference/be/workspace#bind_examples) for more details.
 
 #### Examples
 
@@ -140,7 +138,7 @@ library.
 
 | Attributes | |
 | --- | --- |
-| `name` | [Name](/concepts/labels#target-names); required  A unique name for this target. |
+| `name` | [Name](/versions/8.6.0/concepts/labels#target-names); required  A unique name for this target. |
 | `path` | String; required The path to the local repository's directory. This must be a path to the directory containing the repository's *WORKSPACE* file. The path can be either absolute or relative to the main repository's *WORKSPACE* file. |
 | `repo_mapping` | Dictionary: String -> String; default is `{}` A dictionary from local repository name to global repository name. This allows controls over workspace dependency resolution for dependencies of this repository. For example, an entry `"@foo": "@bar"` declares that, for any time this repository depends on `"@foo"` (such as a dependency on `"@foo//some:target"`), it should actually resolve that dependency within globally-declared `"@bar"` (`"@bar//some:target"`). |
 
@@ -218,10 +216,10 @@ Then targets can depend on `@piano//:play-music` to use piano.jar.
 
 | Attributes | |
 | --- | --- |
-| `name` | [Name](/concepts/labels#target-names); required  A unique name for this target. |
-| `build_file` | [Name](/concepts/labels#target-names); default is `None` A file to use as a BUILD file for this directory. Either build_file or build_file_content must be specified.  This attribute is a label relative to the main workspace. The file does not need to be named BUILD, but can be. (Something like BUILD.new-repo-name may work well for distinguishing it from the repository's actual BUILD files.) |
+| `name` | [Name](/versions/8.6.0/concepts/labels#target-names); required  A unique name for this target. |
+| `build_file` | [Name](/versions/8.6.0/concepts/labels#target-names); default is `None` A file to use as a BUILD file for this directory. Either build_file or build_file_content must be specified.  This attribute is a label relative to the main workspace. The file does not need to be named BUILD, but can be. (Something like BUILD.new-repo-name may work well for distinguishing it from the repository's actual BUILD files.) |
 | `build_file_content` | String; default is `""` The content for the BUILD file for this repository. Either build_file or build_file_content must be specified. |
 | `path` | String; required A path on the local filesystem. This can be either absolute or relative to the main repository's WORKSPACE file. |
 | `repo_mapping` | Dictionary: String -> String; default is `{}` A dictionary from local repository name to global repository name. This allows controls over workspace dependency resolution for dependencies of this repository. For example, an entry `"@foo": "@bar"` declares that, for any time this repository depends on `"@foo"` (such as a dependency on `"@foo//some:target"`), it should actually resolve that dependency within globally-declared `"@bar"` (`"@bar//some:target"`). |
-| `workspace_file` | [Name](/concepts/labels#target-names); default is `None` The file to use as the WORKSPACE file for this repository. Either workspace_file or workspace_file_content can be specified, but not both.  This attribute is a label relative to the main workspace. The file does not need to be named WORKSPACE, but can be. (Something like WORKSPACE.new-repo-name may work well for distinguishing it from the repository's actual WORKSPACE files.) |
+| `workspace_file` | [Name](/versions/8.6.0/concepts/labels#target-names); default is `None` The file to use as the WORKSPACE file for this repository. Either workspace_file or workspace_file_content can be specified, but not both.  This attribute is a label relative to the main workspace. The file does not need to be named WORKSPACE, but can be. (Something like WORKSPACE.new-repo-name may work well for distinguishing it from the repository's actual WORKSPACE files.) |
 | `workspace_file_content` | String; default is `""` The content for the WORKSPACE file for this repository. Either workspace_file or workspace_file_content can be specified, but not both. |
\ No newline at end of file
diff --git a/versions/8.6.0/reference/command-line-reference.mdx b/versions/8.6.0/reference/command-line-reference.mdx
index 56fcf673..5525a8c1 100644
--- a/versions/8.6.0/reference/command-line-reference.mdx
+++ b/versions/8.6.0/reference/command-line-reference.mdx
@@ -12,7 +12,7 @@ or
 bazel []  [] -- []
 ```
 
-See the [User's Guide](/docs/build#specifying-build-targets) for the
+See the [User's Guide](/versions/8.6.0/docs/build#specifying-build-targets) for the
 target patterns syntax.
 
 ## Option Syntax
diff --git a/versions/8.6.0/reference/glossary.mdx b/versions/8.6.0/reference/glossary.mdx
index d3b310af..1f86ce03 100644
--- a/versions/8.6.0/reference/glossary.mdx
+++ b/versions/8.6.0/reference/glossary.mdx
@@ -24,8 +24,7 @@ An in-memory graph of [actions](#action) and the [artifacts](#artifact) that
 these actions read and generate. The graph might include artifacts that exist as
 source files (for example, in the file system) as well as generated
 intermediate/final artifacts that are not mentioned in `BUILD` files. Produced
-during the [analysis phase](#analysis-phase) and used during the [execution
-phase](#execution-phase).
+during the [analysis phase](#analysis-phase) and used during the [execution phase](#execution-phase).
 
 ### Action graph query (aquery)
 
@@ -43,8 +42,7 @@ invalidate individual actions deterministically.
 ### Analysis phase
 
 The second phase of a build. Processes the [target graph](#target-graph)
-specified in [`BUILD` files](#build-file) to produce an in-memory [action
-graph](#action-graph) that determines the order of actions to run during the
+specified in [`BUILD` files](#build-file) to produce an in-memory [action graph](#action-graph) that determines the order of actions to run during the
 [execution phase](#execution-phase). This is the phase in which rule
 implementations are evaluated.
 
@@ -92,8 +90,7 @@ attributes available for a given target depend on its rule type.
 
 ### .bazelrc
 
-Bazel’s configuration file used to change the default values for [startup
-flags](#startup-flags) and [command flags](#command-flags), and to define common
+Bazel’s configuration file used to change the default values for [startup flags](#startup-flags) and [command flags](#command-flags), and to define common
 groups of options that can then be set together on the Bazel command line using
 a `--config` flag. Bazel can combine settings from multiple bazelrc files
 (systemwide, per-workspace, per-user, or from a custom location), and a
@@ -123,8 +120,7 @@ directory.
 ### .bzl File
 
 A file that defines rules, [macros](#macro), and constants written in
-[Starlark](#starlark). These can then be imported into [`BUILD`
-files](#build-file) using the `load()` function.
+[Starlark](#starlark). These can then be imported into [`BUILD` files](#build-file) using the `load()` function.
 
 {/* TODO: ### Build event protocol */}
 
@@ -133,8 +129,7 @@ files](#build-file) using the `load()` function.
 ### Build graph
 
 The dependency graph that Bazel constructs and traverses to perform a build.
-Includes nodes like [targets](#target), [configured
-targets](#configured-target), [actions](#action), and [artifacts](#artifact). A
+Includes nodes like [targets](#target), [configured targets](#configured-target), [actions](#action), and [artifacts](#artifact). A
 build is considered complete when all [artifacts](#artifact) on which a set of
 requested targets depend are verified as up-to-date.
 
@@ -180,8 +175,7 @@ graphs and restart the [analysis phase](#analysis-phase).
 
 Information outside of [rule](#rule) definitions that impacts how rules generate
 [actions](#action). Every build has at least one configuration specifying the
-target platform, action environment variables, and command-line [build
-flags](#command-flags). [Transitions](#transition) may create additional
+target platform, action environment variables, and command-line [build flags](#command-flags). [Transitions](#transition) may create additional
 configurations, such as for host tools or cross-compilation.
 
 **See also:** [Configurations](/versions/8.6.0/extending/rules#configurations)
@@ -198,8 +192,7 @@ build cacheability.
 
 ### Configured query (cquery)
 
-A [query](#query-concept) tool that queries over [configured
-targets](#configured-target) (after the [analysis phase](#analysis-phase)
+A [query](#query-concept) tool that queries over [configured targets](#configured-target) (after the [analysis phase](#analysis-phase)
 completes). This means `select()` and [build flags](#command-flags) (such as
 `--platforms`) are accurately reflected in the results.
 
@@ -217,8 +210,7 @@ build, it has two configured targets: `` and ``.
 
 A build is correct when its output faithfully reflects the state of its
 transitive inputs. To achieve correct builds, Bazel strives to be
-[hermetic](#hermeticity), reproducible, and making [build
-analysis](#analysis-phase) and [action execution](#execution-phase)
+[hermetic](#hermeticity), reproducible, and making [build analysis](#analysis-phase) and [action execution](#execution-phase)
 deterministic.
 
 ### Dependency
@@ -266,8 +258,7 @@ incremental and clean build times.
 
 ### Execution phase
 
-The third phase of a build. Executes the [actions](#action) in the [action
-graph](#action-graph) created during the [analysis phase](#analysis-phase).
+The third phase of a build. Executes the [actions](#action) in the [action graph](#action-graph) created during the [analysis phase](#analysis-phase).
 These actions invoke executables (compilers, scripts) to read and write
 [artifacts](#artifact). *Spawn strategies* control how these actions are
 executed: locally, remotely, dynamically, sandboxed, docker, and so on.
@@ -323,8 +314,7 @@ syntax may be omitted.
 The first phase of a build where Bazel executes [`BUILD` files](#build-file) to
 create [packages](#package). [Macros](#macro) and certain functions like
 `glob()` are evaluated in this phase. Interleaved with the second phase of the
-build, the [analysis phase](#analysis-phase), to build up a [target
-graph](#target-graph).
+build, the [analysis phase](#analysis-phase), to build up a [target graph](#target-graph).
 
 ### Legacy macro
 
@@ -379,8 +369,7 @@ Module metadata is hosted in Bazel registries.
 ### Module Extension
 
 A piece of logic that can be run to generate [repos](#repository) by reading
-inputs from across the [module](#module) dependency graph and invoking [repo
-rules](#repository-rule). Module extensions have capabilities similar to repo
+inputs from across the [module](#module) dependency graph and invoking [repo rules](#repository-rule). Module extensions have capabilities similar to repo
 rules, allowing them to access the internet, perform file I/O, and so on.
 
 **See also:** [Module extensions](/versions/8.6.0/external/extension)
@@ -395,8 +384,7 @@ example, `native.cc_library` or `native.java_library`). User-defined rules
 ### Output base
 
 A [workspace](#workspace)-specific directory to store Bazel output files. Used
-to separate outputs from the *workspace*'s source tree (the [main
-repo](#repository)). Located in the [output user root](#output-user-root).
+to separate outputs from the *workspace*'s source tree (the [main repo](#repository)). Located in the [output user root](#output-user-root).
 
 ### Output groups
 
@@ -459,8 +447,7 @@ query variants: [query](#query-command), [cquery](#configured-query), and
 
 ### query (command)
 
-A [query](#query-concept) tool that operates over the build's post-[loading
-phase](#loading-phase) [target graph](#target-graph). This is relatively fast,
+A [query](#query-concept) tool that operates over the build's post-[loading phase](#loading-phase) [target graph](#target-graph). This is relatively fast,
 but can't analyze the effects of `select()`, [build flags](#command-flags),
 [artifacts](#artifact), or build [actions](#action).
 
@@ -479,8 +466,7 @@ repo; multiple such files can coexist in a directory.
 The *main repo* is the repo in which the current Bazel command is being run.
 
 *External repos* are defined by specifying [modules](#module) in `MODULE.bazel`
-files, or invoking [repo rules](#repository-rule) in [module
-extensions](#module-extension). They can be fetched on demand to a predetermined
+files, or invoking [repo rules](#repository-rule) in [module extensions](#module-extension). They can be fetched on demand to a predetermined
 "magical" location on disk.
 
 Each repo has a unique, constant *canonical* name, and potentially different
@@ -492,8 +478,7 @@ Each repo has a unique, constant *canonical* name, and potentially different
 
 A shared content-addressable cache of files downloaded by Bazel for builds,
 shareable across [workspaces](#workspace). Enables offline builds after the
-initial download. Commonly used to cache files downloaded through [repository
-rules](#repository-rule) like `http_archive` and repository rule APIs like
+initial download. Commonly used to cache files downloaded through [repository rules](#repository-rule) like `http_archive` and repository rule APIs like
 `repository_ctx.download`. Files are cached only if their SHA-256 checksums are
 specified for the download.
 
@@ -530,8 +515,7 @@ Rules are instantiated to produce rule targets in the
 [loading phase](#loading-phase). In the [analysis phase](#analysis-phase) rule
 targets communicate information to their downstream dependencies in the form of
 [providers](#provider), and register [actions](#action) describing how to
-generate their output artifacts. These actions are run in the [execution
-phase](#execution-phase).
+generate their output artifacts. These actions are run in the [execution phase](#execution-phase).
 
 Note: Historically the term "rule" has been used to refer to a rule target.
 This usage was inherited from tools like Make, but causes confusion and should
@@ -581,8 +565,7 @@ support the stamp attribute.
 
 The extension language for writing [rules](/versions/8.6.0/extending/rules) and [macros](#macro). A
 restricted subset of Python (syntactically and grammatically) aimed for the
-purpose of configuration, and for better performance. Uses the [`.bzl`
-file](#bzl-file) extension. [`BUILD` files](#build-file) use an even more
+purpose of configuration, and for better performance. Uses the [`.bzl` file](#bzl-file) extension. [`BUILD` files](#build-file) use an even more
 restricted version of Starlark (such as no `def` function definitions), formerly
 known as Skylark.
 
@@ -616,8 +599,7 @@ An object that is defined in a [`BUILD` file](#build-file) and identified by a
 [label](#label). Targets represent the buildable units of a workspace from
 the perspective of the end user.
 
-A target that is declared by instantiating a [rule](#rule) is called a [rule
-target](#rule-target). Depending on the rule, these may be runnable (like
+A target that is declared by instantiating a [rule](#rule) is called a [rule target](#rule-target). Depending on the rule, these may be runnable (like
 `cc_binary`) or testable (like `cc_test`). Rule targets typically depend on
 other targets via their [attributes](#attribute) (such as `deps`); these
 dependencies form the basis of the [target graph](#target-graph).
@@ -628,15 +610,12 @@ within a `BUILD` file. As a special case, the `BUILD` file of any package is
 always considered a source file target in that package.
 
 Targets are discovered during the [loading phase](#loading-phase). During the
-[analysis phase](#analysis-phase), targets are associated with [build
-configurations](#configuration) to form [configured
-targets](#configured-target).
+[analysis phase](#analysis-phase), targets are associated with [build configurations](#configuration) to form [configured targets](#configured-target).
 
 ### Target graph
 
 An in-memory graph of [targets](#target) and their dependencies. Produced during
-the [loading phase](#loading-phase) and used as an input to the [analysis
-phase](#analysis-phase).
+the [loading phase](#loading-phase) and used as an input to the [analysis phase](#analysis-phase).
 
 ### Target pattern
 
@@ -651,8 +630,7 @@ packages recursively from the root of the [workspace](#workspace).
 Rule [targets](#target) instantiated from test rules, and therefore contains a
 test executable. A return code of zero from the completion of the executable
 indicates test success. The exact contract between Bazel and tests (such as test
-environment variables, test result collection methods) is specified in the [Test
-Encyclopedia](/versions/8.6.0/reference/test-encyclopedia).
+environment variables, test result collection methods) is specified in the [Test Encyclopedia](/versions/8.6.0/reference/test-encyclopedia).
 
 ### Toolchain
 
@@ -668,8 +646,7 @@ A build [target](#target) is top-level if it’s requested on the Bazel command
 line. For example, if `//:foo` depends on `//:bar`, and `bazel build //:foo` is
 called, then for this build, `//:foo` is top-level, and `//:bar` isn’t
 top-level, although both targets will need to be built. An important difference
-between top-level and non-top-level targets is that [command
-flags](#command-flags) set on the Bazel command line (or via
+between top-level and non-top-level targets is that [command flags](#command-flags) set on the Bazel command line (or via
 [.bazelrc](#bazelrc)) will set the [configuration](#configuration) for top-level
 targets, but might be modified by a [transition](#transition) for non-top-level
 targets.
@@ -704,8 +681,7 @@ or `.bzl` file may load a given `.bzl` file. Without context, usually
 
 ### Workspace
 
-The environment shared by all Bazel commands run from the same [main
-repository](#repository).
+The environment shared by all Bazel commands run from the same [main repository](#repository).
 
 Note that historically the concepts of "repository" and "workspace" have been
 conflated; the term "workspace" has often been used to refer to the main
diff --git a/versions/8.6.0/release/backward-compatibility.mdx b/versions/8.6.0/release/backward-compatibility.mdx
index cc4467bb..fe6c3456 100644
--- a/versions/8.6.0/release/backward-compatibility.mdx
+++ b/versions/8.6.0/release/backward-compatibility.mdx
@@ -6,11 +6,9 @@ This page provides information about how to handle backward compatibility,
 including migrating from one release to another and how to communicate
 incompatible changes.
 
-Bazel is evolving. Minor versions released as part of an [LTS major
-version](/versions/8.6.0/release#bazel-versioning) are fully backward-compatible. New major LTS
+Bazel is evolving. Minor versions released as part of an [LTS major version](/versions/8.6.0/release#bazel-versioning) are fully backward-compatible. New major LTS
 releases may contain incompatible changes that require some migration effort.
-For more information about Bazel's release model, please check out the [Release
-Model](/versions/8.6.0/release) page.
+For more information about Bazel's release model, please check out the [Release Model](/versions/8.6.0/release) page.
 
 ## Summary
 
@@ -59,8 +57,7 @@ available.
 ## Communicating incompatible changes
 
 The primary source of information about incompatible changes are GitHub issues
-marked with an ["incompatible-change"
-label](https://github.com/bazelbuild/bazel/issues?q=label%3Aincompatible-change).
+marked with an ["incompatible-change" label](https://github.com/bazelbuild/bazel/issues?q=label%3Aincompatible-change).
 
 For every incompatible change, the issue specifies the following:
 
diff --git a/versions/8.6.0/release/index.mdx b/versions/8.6.0/release/index.mdx
index 4611db17..3bb90d98 100644
--- a/versions/8.6.0/release/index.mdx
+++ b/versions/8.6.0/release/index.mdx
@@ -2,8 +2,7 @@
 title: 'Release Model'
 ---
 
-As announced in [the original blog
-post](https://blog.bazel.build/2020/11/10/long-term-support-release.html), Bazel
+As announced in [the original blog post](https://blog.bazel.build/2020/11/10/long-term-support-release.html), Bazel
 4.0 and higher versions provides support for two release tracks: rolling
 releases and long term support (LTS) releases. This page covers the latest
 information about Bazel's release model.
@@ -19,8 +18,7 @@ information about Bazel's release model.
 | Bazel 5 | Maintenance | [5.4.1](https://github.com/bazelbuild/bazel/releases/tag/5.4.1) | Jan 2025 |
 | Bazel 4 | Deprecated | [4.2.4](https://github.com/bazelbuild/bazel/releases/tag/4.2.4) | Jan 2024 |
 
-All Bazel LTS releases can be found on the [release
-page](https://github.com/bazelbuild/bazel/releases) on GitHub.
+All Bazel LTS releases can be found on the [release page](https://github.com/bazelbuild/bazel/releases) on GitHub.
 
 Note: Bazel version older than Bazel 5 are no longer supported, Bazel users are
 recommended to upgrade to the latest LTS release or use rolling releases if you
@@ -28,8 +26,7 @@ want to keep up with the latest changes at HEAD.
 
 ## Release versioning
 
-Bazel uses a _major.minor.patch_ [Semantic
-Versioning](https://semver.org/) scheme.
+Bazel uses a _major.minor.patch_ [Semantic Versioning](https://semver.org/) scheme.
 
 *   A _major release_ contains features that are not backward compatible with
     the previous release. Each major Bazel version is an LTS release.
@@ -72,8 +69,7 @@ Bazel regularly publish releases for two release tracks.
     release.
 *   Rolling releases can ship incompatible changes. Incompatible flags are
     recommended for major breaking changes, rolling out incompatible changes
-    should follow our [backward compatibility
-    policy](/versions/8.6.0/release/backward-compatibility).
+    should follow our [backward compatibility policy](/versions/8.6.0/release/backward-compatibility).
 
 ### LTS releases
 
@@ -89,8 +85,7 @@ Bazel regularly publish releases for two release tracks.
 *   A Bazel LTS release enters the Deprecated stage after being in ​​the
     Maintenance stage for 2 years.
 
-For planned releases, please check our [release
-issues](https://github.com/bazelbuild/bazel/issues?q=is%3Aopen+is%3Aissue+label%3Arelease)
+For planned releases, please check our [release issues](https://github.com/bazelbuild/bazel/issues?q=is%3Aopen+is%3Aissue+label%3Arelease)
 on Github.
 
 ## Release procedure & policies
@@ -153,8 +148,7 @@ For LTS releases, the procedure and policies below are followed:
 1.  Identify release blockers and fix issues found on the release branch.
     *   The release branch is tested with the same test suite in
         [postsubmit](https://buildkite.com/bazel/bazel-bazel) and
-        [downstream test pipeline]
-        (https://buildkite.com/bazel/bazel-at-head-plus-downstream)
+        [downstream test pipeline](https://buildkite.com/bazel/bazel-at-head-plus-downstream)
         on Bazel CI. The Bazel team monitors testing results of the release
         branch and fixes any regressions found.
 1.  Create a new release candidate from the release branch when all known
@@ -210,5 +204,4 @@ feature.
 ## Rule compatibility
 
 If you are a rule authors and want to maintain compatibility with different
-Bazel versions, please check out the [Rule
-Compatibility](/versions/8.6.0/release/rule-compatibility) page.
+Bazel versions, please check out the [Rule Compatibility](/versions/8.6.0/release/rule-compatibility) page.
diff --git a/versions/8.6.0/release/rule-compatibility.mdx b/versions/8.6.0/release/rule-compatibility.mdx
index 419803cc..91f2d050 100644
--- a/versions/8.6.0/release/rule-compatibility.mdx
+++ b/versions/8.6.0/release/rule-compatibility.mdx
@@ -53,18 +53,15 @@ Bazel LTS release.
 As Bazel rules authors, you can ensure a manageable migration process for users
 by following these best practices:
 
-1.  The rule should follow [Semantic
-    Versioning](https://semver.org/): minor versions of the same
+1.  The rule should follow [Semantic Versioning](https://semver.org/): minor versions of the same
     major version are backward compatible.
 1.  The rule at HEAD should be compatible with the latest Bazel LTS release.
 1.  The rule at HEAD should be compatible with Bazel at HEAD. To achieve this,
     you can
     *   Set up your own CI testing with Bazel at HEAD
-    *   Add your project to [Bazel downstream
-        testing](https://github.com/bazelbuild/continuous-integration/blob/master/docs/downstream-testing.md);
+    *   Add your project to [Bazel downstream testing](https://github.com/bazelbuild/continuous-integration/blob/master/docs/downstream-testing.md);
         the Bazel team files issues to your project if breaking changes in Bazel
-        affect your project, and you must follow our [downstream project
-        policies](https://github.com/bazelbuild/continuous-integration/blob/master/docs/downstream-testing.md#downstream-project-policies)
+        affect your project, and you must follow our [downstream project policies](https://github.com/bazelbuild/continuous-integration/blob/master/docs/downstream-testing.md#downstream-project-policies)
         to address issues timely.
 1.  The latest major version of the rule must be compatible with the latest
     Bazel LTS release.
diff --git a/versions/8.6.0/remote/bep-glossary.mdx b/versions/8.6.0/remote/bep-glossary.mdx
index d38b4a05..f6b1c5f3 100644
--- a/versions/8.6.0/remote/bep-glossary.mdx
+++ b/versions/8.6.0/remote/bep-glossary.mdx
@@ -36,7 +36,7 @@ BEP contains an event like the following:
 ## ActionExecuted
 
 Provides details about the execution of a specific
-[Action](/versions/8.6.0/rules/lib/actions) in a build. By default, this event is
+[Action](/versions/8.6.0/rules/lib/builtins/actions) in a build. By default, this event is
 included in the BEP only for failed actions, to support identifying the root cause
 of build failures. Users may set the `--build_event_publish_all_actions` flag
 to include all `ActionExecuted` events.
@@ -410,5 +410,4 @@ workspace, such as the execution root.
 
 ## WorkspaceStatus
 
-A single `WorkspaceStatus` event contains the result of the [workspace status
-command](/versions/8.6.0/docs/user-manual#workspace-status).
+A single `WorkspaceStatus` event contains the result of the [workspace status command](/versions/8.6.0/docs/user-manual#workspace-status).
diff --git a/versions/8.6.0/remote/bep.mdx b/versions/8.6.0/remote/bep.mdx
index 32b7611e..3b5a7413 100644
--- a/versions/8.6.0/remote/bep.mdx
+++ b/versions/8.6.0/remote/bep.mdx
@@ -2,14 +2,12 @@
 title: 'Build Event Protocol'
 ---
 
-The [Build Event
-Protocol](https://github.com/bazelbuild/bazel/blob/master/src/main/java/com/google/devtools/build/lib/buildeventstream/proto/build_event_stream.proto)
+The [Build Event Protocol](https://github.com/bazelbuild/bazel/blob/master/src/main/java/com/google/devtools/build/lib/buildeventstream/proto/build_event_stream.proto)
 (BEP) allows third-party programs to gain insight into a Bazel invocation. For
 example, you could use the BEP to gather information for an IDE
 plugin or a dashboard that displays build results.
 
-The protocol is a set of [protocol
-buffer](https://developers.google.com/protocol-buffers/) messages with some
+The protocol is a set of [protocol buffer](https://developers.google.com/protocol-buffers/) messages with some
 semantics defined on top of it. It includes information about build and test
 results, build progress, the build configuration and much more. The BEP is
 intended to be consumed programmatically and makes parsing Bazel’s
@@ -20,16 +18,13 @@ build event is a protocol buffer message consisting of a build event identifier,
 a set of child event identifiers, and a payload.
 
 *  __Build Event Identifier:__ Depending on the kind of build event, it might be
-an [opaque
-string](https://github.com/bazelbuild/bazel/blob/7.1.0/src/main/java/com/google/devtools/build/lib/buildeventstream/proto/build_event_stream.proto#L131-L140)
-or [structured
-information](https://github.com/bazelbuild/bazel/blob/7.1.0/src/main/java/com/google/devtools/build/lib/buildeventstream/proto/build_event_stream.proto#L194-L205)
+an [opaque string](https://github.com/bazelbuild/bazel/blob/7.1.0/src/main/java/com/google/devtools/build/lib/buildeventstream/proto/build_event_stream.proto#L131-L140)
+or [structured information](https://github.com/bazelbuild/bazel/blob/7.1.0/src/main/java/com/google/devtools/build/lib/buildeventstream/proto/build_event_stream.proto#L194-L205)
 revealing more about the build event. A build event identifier is unique within
 a build.
 
 *  __Children:__ A build event may announce other build events, by including
-their build event identifiers in its [children
-field](https://github.com/bazelbuild/bazel/blob/7.1.0/src/main/java/com/google/devtools/build/lib/buildeventstream/proto/build_event_stream.proto#L1276).
+their build event identifiers in its [children field](https://github.com/bazelbuild/bazel/blob/7.1.0/src/main/java/com/google/devtools/build/lib/buildeventstream/proto/build_event_stream.proto#L1276).
 For example, the `PatternExpanded` build event announces the targets it expands
 to as children. The protocol guarantees that all events, except for the first
 event, are announced by a previous event.
@@ -91,8 +86,7 @@ human-readable formats, such as text and JSON:
 
 ## Build Event Service
 
-The [Build Event
-Service](https://github.com/googleapis/googleapis/blob/master/google/devtools/build/v1/publish_build_event.proto)
+The [Build Event Service](https://github.com/googleapis/googleapis/blob/master/google/devtools/build/v1/publish_build_event.proto)
 Protocol is a generic [gRPC](https://www.grpc.io) service for publishing build events. The Build Event
 Service protocol is independent of the BEP and treats BEP events as opaque bytes.
 Bazel ships with a gRPC client implementation of the Build Event Service protocol that
@@ -136,8 +130,7 @@ For a description of each of these flags, see the
 The BEP typically contains many references to log files (test.log, test.xml,
 etc. ) stored on the machine where Bazel is running. A remote BES server
 typically can't access these files as they are on different machines. A way to
-work around this issue is to use Bazel with [remote
-caching](/versions/8.6.0/remote/caching).
+work around this issue is to use Bazel with [remote caching](/versions/8.6.0/remote/caching).
 Bazel will upload all output files to the remote cache (including files
 referenced in the BEP) and the BES server can then fetch the referenced files
 from the cache.
diff --git a/versions/8.6.0/remote/cache-local.mdx b/versions/8.6.0/remote/cache-local.mdx
index e073bc31..28300aaf 100644
--- a/versions/8.6.0/remote/cache-local.mdx
+++ b/versions/8.6.0/remote/cache-local.mdx
@@ -18,8 +18,7 @@ execution. However, local execution presents some additional challenges.
 ## Checking your cache hit rate
 
 Successful remote cache hits will show up in the status line, similar to
-[Cache Hits rate with Remote
-Execution](/versions/8.6.0/remote/cache-remote#check-cache-hits).
+[Cache Hits rate with Remote Execution](/versions/8.6.0/remote/cache-remote#check-cache-hits).
 
 In the standard output of your Bazel run, you will see something like the
 following:
@@ -66,8 +65,7 @@ the steps in this section.
    message you see does not give you enough information, try adding
    `--verbose_failures`.
 
-2. Follow the steps from [Troubleshooting cache hits for remote
-   execution](/versions/8.6.0/remote/cache-remote#troubleshooting_cache_hits) to
+2. Follow the steps from [Troubleshooting cache hits for remote execution](/versions/8.6.0/remote/cache-remote#troubleshooting_cache_hits) to
    ensure that your cache-writing Bazel invocations are able to get cache hits
    on the same machine and across machines.
 
@@ -81,7 +79,6 @@ the steps in this section.
    b. Ensure your cache-reading Bazel invocations build the same targets as the
       cache-writing Bazel invocations.
 
-   c. Follow the same steps as to [ensure caching across
-      machines](/versions/8.6.0/remote/cache-remote#caching-across-machines),
+   c. Follow the same steps as to [ensure caching across machines](/versions/8.6.0/remote/cache-remote#caching-across-machines),
       to ensure caching from your cache-writing Bazel invocation to your
       cache-reading Bazel invocation.
diff --git a/versions/8.6.0/remote/caching.mdx b/versions/8.6.0/remote/caching.mdx
index 9f744a2d..6699e517 100644
--- a/versions/8.6.0/remote/caching.mdx
+++ b/versions/8.6.0/remote/caching.mdx
@@ -126,7 +126,7 @@ not provide technical support for bazel-remote.
 
 This cache stores contents on disk and also provides garbage collection
 to enforce an upper storage limit and clean unused artifacts. The cache is
-available as a [docker image] and its code is available on
+available as a [docker image](https://hub.docker.com/r/buchgr/bazel-remote-cache/) and its code is available on
 [GitHub](https://github.com/buchgr/bazel-remote/).
 Both the REST and gRPC remote cache APIs are supported.
 
@@ -308,8 +308,7 @@ or for the age of individual cache entries. Bazel will automatically garbage
 collect the disk cache while idling between builds; the idle timer can be set
 with `--experimental_disk_cache_gc_idle_delay` (defaulting to 5 minutes).
 
-As an alternative to automatic garbage collection, we also provide a [tool](
-https://github.com/bazelbuild/bazel/tree/master/src/tools/diskcache) to run a
+As an alternative to automatic garbage collection, we also provide a [tool](https://github.com/bazelbuild/bazel/tree/master/src/tools/diskcache) to run a
 garbage collection on demand.
 
 ## Known issues
diff --git a/versions/8.6.0/remote/dynamic.mdx b/versions/8.6.0/remote/dynamic.mdx
index f585b03d..6c09c7fc 100644
--- a/versions/8.6.0/remote/dynamic.mdx
+++ b/versions/8.6.0/remote/dynamic.mdx
@@ -12,8 +12,7 @@ alike.
 This page describes how to enable, tune, and debug dynamic execution. If you
 have both local and remote execution set up and are trying to adjust Bazel
 settings for better performance, this page is for you. If you don't already have
-remote execution set up, go to the Bazel [Remote Execution
-Overview](/versions/8.6.0/remote/rbe) first.
+remote execution set up, go to the Bazel [Remote Execution Overview](/versions/8.6.0/remote/rbe) first.
 
 ## Enabling dynamic execution?
 
@@ -44,14 +43,12 @@ are likely. The default value is 1000ms, but should be tuned to being just a bit
 longer than cache hits usually take. The actual time depends both on the remote
 system and on how long a round-trip takes. Usually, the value will be the same
 for all users of a given remote system, unless some of them are far enough away
-to add roundtrip latency. You can use the [Bazel profiling
-features](/versions/8.6.0/rules/performance#performance-profiling) to look at how long typical
+to add roundtrip latency. You can use the [Bazel profiling features](/versions/8.6.0/rules/performance#performance-profiling) to look at how long typical
 cache hits take.
 
 Dynamic execution can be used with local sandboxed strategy as well as with
 [persistent workers](/versions/8.6.0/remote/persistent). Persistent workers will automatically
-run with sandboxing when used with dynamic execution, and cannot use [multiplex
-workers](/versions/8.6.0/remote/multiplex). On Darwin and Windows systems, the sandboxed
+run with sandboxing when used with dynamic execution, and cannot use [multiplex workers](/versions/8.6.0/remote/multiplex). On Darwin and Windows systems, the sandboxed
 strategy can be slow; you can pass `--reuse_sandbox_directories` to reduce
 overhead of creating sandboxes on these systems.
 
@@ -67,8 +64,7 @@ entire action fails. This is an intentional choice to prevent differences
 between local and remote execution from going unnoticed.
 
 For more background on how dynamic execution and its locking works, see Julio
-Merino's excellent [blog
-posts](https://jmmv.dev/series/bazel-dynamic-execution/)
+Merino's excellent [blog posts](https://jmmv.dev/series/bazel-dynamic-execution/)
 
 ## When should I use dynamic execution?
 
diff --git a/versions/8.6.0/remote/output-directories.mdx b/versions/8.6.0/remote/output-directories.mdx
index 4dc4a4d2..d77462ca 100644
--- a/versions/8.6.0/remote/output-directories.mdx
+++ b/versions/8.6.0/remote/output-directories.mdx
@@ -25,7 +25,7 @@ The solution that's currently implemented:
 
 * Bazel must be invoked from a directory containing a repo boundary file, or a
   subdirectory thereof. In other words, Bazel must be invoked from inside a
-  [repository](../external/overview#repository). Otherwise, an error is
+  [repository](/versions/8.6.0/external/overview#repository). Otherwise, an error is
   reported.
 * The _outputRoot_ directory defaults to `~/.cache/bazel` on Linux,
   `/private/var/tmp` on macOS, and on Windows it defaults to `%HOME%` if
diff --git a/versions/8.6.0/remote/persistent.mdx b/versions/8.6.0/remote/persistent.mdx
index a1b539bc..7795e1b3 100644
--- a/versions/8.6.0/remote/persistent.mdx
+++ b/versions/8.6.0/remote/persistent.mdx
@@ -257,7 +257,6 @@ For more information on persistent workers, see:
 *   [Original persistent workers blog post](https://blog.bazel.build/2015/12/10/java-workers.html)
 *   [Haskell implementation description](https://www.tweag.io/blog/2019-09-25-bazel-ghc-persistent-worker-internship/)
 *   [Blog post by Mike Morearty](https://medium.com/@mmorearty/how-to-create-a-persistent-worker-for-bazel-7738bba2cabb)
-*   [Front End Development with Bazel: Angular/TypeScript and Persistent Workers
-    w/ Asana](https://www.youtube.com/watch?v=0pgERydGyqo)
+*   [Front End Development with Bazel: Angular/TypeScript and Persistent Workers w/ Asana](https://www.youtube.com/watch?v=0pgERydGyqo)
 *   [Bazel strategies explained](https://jmmv.dev/2019/12/bazel-strategies.html)
 *   [Informative worker strategy discussion on the bazel-discuss mailing list](https://groups.google.com/forum/#!msg/bazel-discuss/oAEnuhYOPm8/ol7hf4KWJgAJ)
diff --git a/versions/8.6.0/remote/rules.mdx b/versions/8.6.0/remote/rules.mdx
index 7740aecf..f25bd058 100644
--- a/versions/8.6.0/remote/rules.mdx
+++ b/versions/8.6.0/remote/rules.mdx
@@ -54,8 +54,7 @@ variables that may not be set to equivalent values (or at all) in the remote
 execution environment.
 
 Toolchain rules currently exist for Bazel build and test rules for
-[Scala](https://github.com/bazelbuild/rules_scala/blob/master/scala/scala_toolch
-ain.bzl),
+[Scala](https://github.com/bazelbuild/rules_scala/blob/master/scala/scala_toolch ain.bzl),
 [Rust](https://github.com/bazelbuild/rules_rust/blob/main/rust/toolchain.bzl),
 and [Go](https://github.com/bazelbuild/rules_go/blob/master/go/toolchains.rst),
 and new toolchain rules are under way for other languages and tools such as
diff --git a/versions/8.6.0/remote/workspace.mdx b/versions/8.6.0/remote/workspace.mdx
index 73908871..dca5bce1 100644
--- a/versions/8.6.0/remote/workspace.mdx
+++ b/versions/8.6.0/remote/workspace.mdx
@@ -11,8 +11,7 @@ on the host machine. If your workspace rules access information about the
 host machine for use during execution, your build is likely to break due to
 incompatibilities between the environments.
 
-As part of [adapting Bazel rules for remote
-execution](/versions/8.6.0/remote/rules), you need to find such workspace rules
+As part of [adapting Bazel rules for remote execution](/versions/8.6.0/remote/rules), you need to find such workspace rules
 and fix them. This page describes how to find potentially problematic workspace
 rules using the workspace log.
 
diff --git a/versions/8.6.0/rules/challenges.mdx b/versions/8.6.0/rules/challenges.mdx
index a3796a15..0ddd2ea3 100644
--- a/versions/8.6.0/rules/challenges.mdx
+++ b/versions/8.6.0/rules/challenges.mdx
@@ -208,7 +208,7 @@ Bazel is heavily affected by both of these scenarios, so we introduced a set of
 custom collection classes that effectively compress the information in memory by
 avoiding the copy at each step. Almost all of these data structures have set
 semantics, so we called it
-[depset](/versions/8.6.0/rules/lib/depset)
+[depset](/versions/8.6.0/rules/lib/builtins/depset)
 (also known as `NestedSet` in the internal implementation). The majority of
 changes to reduce Bazel's memory consumption over the past several years were
 changes to use depsets instead of whatever was previously used.
diff --git a/versions/8.6.0/rules/faq.mdx b/versions/8.6.0/rules/faq.mdx
index 04ca55b5..ea70b170 100644
--- a/versions/8.6.0/rules/faq.mdx
+++ b/versions/8.6.0/rules/faq.mdx
@@ -17,7 +17,7 @@ Bazel only executes the actions needed to produce the *requested* output files.
 
 * If you want the file to be built automatically whenever your target is
   mentioned on the command line, add it to your rule's default outputs by
-  returning a [`DefaultInfo`](lib/globals#DefaultInfo) provider.
+  returning a [`DefaultInfo`](/versions/8.6.0/rules/lib/globals#DefaultInfo) provider.
 
 See the [Rules page](/versions/8.6.0/extending/rules#requesting-output-files) for more information.
 
@@ -35,24 +35,24 @@ correct path.
 
 For actions, you declare inputs by passing them to the `ctx.actions.*` function
 that creates the action. The proper path for the file can be obtained using
-[`File.path`](lib/File#path).
+[`File.path`](/versions/8.6.0/rules/lib/builtins/File#path).
 
 For binaries (the executable outputs run by a `bazel run` or `bazel test`
 command), you declare inputs by including them in the
 [runfiles](/versions/8.6.0/extending/rules#runfiles). Instead of using the `path` field, use
-[`File.short_path`](lib/File#short_path), which is file's path relative to
+[`File.short_path`](/versions/8.6.0/rules/lib/builtins/File#short_path), which is file's path relative to
 the runfiles directory in which the binary executes.
 
 ## How can I control which files are built by `bazel build //pkg:mytarget`?
 
-Use the [`DefaultInfo`](lib/globals#DefaultInfo) provider to
+Use the [`DefaultInfo`](/versions/8.6.0/rules/lib/globals#DefaultInfo) provider to
 [set the default outputs](/versions/8.6.0/extending/rules#requesting-output-files).
 
 ## How can I run a program or do file I/O as part of my build?
 
 A tool can be declared as a target, just like any other part of your build, and
 run during the execution phase to help build other targets. To create an action
-that runs a tool, use [`ctx.actions.run`](lib/actions#run) and pass in the
+that runs a tool, use [`ctx.actions.run`](/versions/8.6.0/rules/lib/builtins/actions#run) and pass in the
 tool as the `executable` parameter.
 
 During the loading and analysis phases, a tool *cannot* run, nor can you perform
diff --git a/versions/8.6.0/rules/language.mdx b/versions/8.6.0/rules/language.mdx
index 3cf2942f..64580aea 100644
--- a/versions/8.6.0/rules/language.mdx
+++ b/versions/8.6.0/rules/language.mdx
@@ -35,19 +35,19 @@ Starlark's semantics can differ from Python, but behavioral differences are
 rare, except for cases where Starlark raises an error. The following Python
 types are supported:
 
-* [None](lib/globals#None)
-* [bool](lib/bool)
-* [dict](lib/dict)
-* [tuple](lib/tuple)
-* [function](lib/function)
-* [int](lib/int)
-* [list](lib/list)
-* [string](lib/string)
+* [None](/versions/8.6.0/rules/lib/globals#None)
+* [bool](/versions/8.6.0/rules/lib/core/bool)
+* [dict](/versions/8.6.0/rules/lib/core/dict)
+* [tuple](/versions/8.6.0/rules/lib/core/tuple)
+* [function](/versions/8.6.0/rules/lib/core/function)
+* [int](/versions/8.6.0/rules/lib/core/int)
+* [list](/versions/8.6.0/rules/lib/core/list)
+* [string](/versions/8.6.0/rules/lib/core/string)
 
 ## Mutability
 
 Starlark favors immutability. Two mutable data structures are available:
-[lists](lib/list) and [dicts](lib/dict). Changes to mutable
+[lists](/versions/8.6.0/rules/lib/core/list) and [dicts](/versions/8.6.0/rules/lib/core/dict). Changes to mutable
 data-structures, such as appending a value to a list or deleting an entry in a
 dictionary are valid only for objects created in the current context. After a
 context finishes, its values become immutable.
@@ -94,10 +94,8 @@ values returned by rules are immutable.
 `BUILD` files register targets via making calls to rules. `.bzl` files provide
 definitions for constants, rules, macros, and functions.
 
-[Native functions](/versions/8.6.0/reference/be/functions) and [native rules](
-/reference/be/overview#language-specific-native-rules) are global symbols in
-`BUILD` files. `bzl` files need to load them using the [`native` module](
-/rules/lib/toplevel/native).
+[Native functions](/versions/8.6.0/reference/be/functions) and [native rules](/versions/8.6.0/reference/be/overview#language-specific-native-rules) are global symbols in
+`BUILD` files. `bzl` files need to load them using the [`native` module](/versions/8.6.0/rules/lib/toplevel/native).
 
 There are two syntactic restrictions in `BUILD` files: 1) declaring functions is
 illegal, and 2) `*args` and `**kwargs` arguments are not allowed.
@@ -131,7 +129,7 @@ not defined across value types. In short: `5 < 'foo'` will throw an error and
   error: `{"a": 4, "b": 7, "a": 1}`.
 
 * Strings are represented with double-quotes (such as when you call
-  [repr](lib/globals#repr)).
+  [repr](/versions/8.6.0/rules/lib/globals#repr)).
 
 * Strings aren't iterable.
 
@@ -139,12 +137,12 @@ The following Python features are not supported:
 
 * implicit string concatenation (use explicit `+` operator).
 * Chained comparisons (such as `1 < x < 5`).
-* `class` (see [`struct`](lib/struct#struct) function).
+* `class` (see [`struct`](/versions/8.6.0/rules/lib/builtins/struct#struct) function).
 * `import` (see [`load`](/versions/8.6.0/extending/concepts#loading-an-extension) statement).
 * `while`, `yield`.
 * float and set types.
 * generators and generator expressions.
 * `is` (use `==` instead).
-* `try`, `raise`, `except`, `finally` (see [`fail`](lib/globals#fail) for fatal errors).
+* `try`, `raise`, `except`, `finally` (see [`fail`](/versions/8.6.0/rules/lib/globals#fail) for fatal errors).
 * `global`, `nonlocal`.
 * most builtin functions, most methods.
diff --git a/versions/8.6.0/rules/legacy-macro-tutorial.mdx b/versions/8.6.0/rules/legacy-macro-tutorial.mdx
index c2d9bd57..d49c6ddf 100644
--- a/versions/8.6.0/rules/legacy-macro-tutorial.mdx
+++ b/versions/8.6.0/rules/legacy-macro-tutorial.mdx
@@ -3,9 +3,7 @@ title: 'Creating a Legacy Macro'
 ---
 
 IMPORTANT: This tutorial is for [*legacy macros*](/versions/8.6.0/extending/legacy-macros). If
-you only need to support Bazel 8 or newer, we recommend using [symbolic
-macros](/versions/8.6.0/extending/macros) instead; take a look at [Creating a Symbolic
-Macro](../macro-tutorial).
+you only need to support Bazel 8 or newer, we recommend using [symbolic macros](/versions/8.6.0/extending/macros) instead; take a look at [Creating a Symbolic Macro](/versions/8.6.0/rules/macro-tutorial).
 
 Imagine that you need to run a tool as part of your build. For example, you
 may want to generate or preprocess a source file, or compress a binary. In this
diff --git a/versions/8.6.0/rules/lib/builtins.mdx b/versions/8.6.0/rules/lib/builtins.mdx
index 4f23dbbd..545028e1 100644
--- a/versions/8.6.0/rules/lib/builtins.mdx
+++ b/versions/8.6.0/rules/lib/builtins.mdx
@@ -4,61 +4,61 @@ title: 'Built-in Types'
 
 This section lists types of Starlark objects. With some exceptions, these type names are not valid Starlark symbols; instances of them may be acquired through different means.
 
-* [Action](/rules/lib/builtins/Action)
-* [actions](/rules/lib/builtins/actions)
-* [apple_platform](/rules/lib/builtins/apple_platform)
-* [Args](/rules/lib/builtins/Args)
-* [Aspect](/rules/lib/builtins/Aspect)
-* [Attribute](/rules/lib/builtins/Attribute)
-* [bazel_module](/rules/lib/builtins/bazel_module)
-* [bazel_module_tags](/rules/lib/builtins/bazel_module_tags)
-* [BuildSetting](/rules/lib/builtins/BuildSetting)
-* [CcCompilationOutputs](/rules/lib/builtins/CcCompilationOutputs)
-* [CcLinkingOutputs](/rules/lib/builtins/CcLinkingOutputs)
-* [CompilationContext](/rules/lib/builtins/CompilationContext)
-* [configuration](/rules/lib/builtins/configuration)
-* [ctx](/rules/lib/builtins/ctx)
-* [depset](/rules/lib/builtins/depset)
-* [DirectoryExpander](/rules/lib/builtins/DirectoryExpander)
-* [DottedVersion](/rules/lib/builtins/DottedVersion)
-* [exec_result](/rules/lib/builtins/exec_result)
-* [ExecGroupCollection](/rules/lib/builtins/ExecGroupCollection)
-* [ExecGroupContext](/rules/lib/builtins/ExecGroupContext)
-* [ExecTransitionFactory](/rules/lib/builtins/ExecTransitionFactory)
-* [extension_metadata](/rules/lib/builtins/extension_metadata)
-* [Facts](/rules/lib/builtins/Facts)
-* [FeatureConfiguration](/rules/lib/builtins/FeatureConfiguration)
-* [File](/rules/lib/builtins/File)
-* [fragments](/rules/lib/builtins/fragments)
-* [java_annotation_processing](/rules/lib/builtins/java_annotation_processing)
-* [Label](/rules/lib/builtins/Label)
-* [LateBoundDefault](/rules/lib/builtins/LateBoundDefault)
-* [LibraryToLink](/rules/lib/builtins/LibraryToLink)
-* [License](/rules/lib/builtins/License)
-* [LinkerInput](/rules/lib/builtins/LinkerInput)
-* [LinkingContext](/rules/lib/builtins/LinkingContext)
-* [macro](/rules/lib/builtins/macro)
-* [mapped_root](/rules/lib/builtins/mapped_root)
-* [module_ctx](/rules/lib/builtins/module_ctx)
-* [path](/rules/lib/builtins/path)
-* [Provider](/rules/lib/builtins/Provider)
-* [repo_metadata](/rules/lib/builtins/repo_metadata)
-* [repository_ctx](/rules/lib/builtins/repository_ctx)
-* [repository_os](/rules/lib/builtins/repository_os)
-* [repository_rule](/rules/lib/builtins/repository_rule)
-* [root](/rules/lib/builtins/root)
-* [rule](/rules/lib/builtins/rule)
-* [rule_attributes](/rules/lib/builtins/rule_attributes)
-* [runfiles](/rules/lib/builtins/runfiles)
-* [struct](/rules/lib/builtins/struct)
-* [Subrule](/rules/lib/builtins/Subrule)
-* [subrule_ctx](/rules/lib/builtins/subrule_ctx)
-* [SymlinkEntry](/rules/lib/builtins/SymlinkEntry)
-* [tag_class](/rules/lib/builtins/tag_class)
-* [Target](/rules/lib/builtins/Target)
-* [TemplateDict](/rules/lib/builtins/TemplateDict)
-* [toolchain_type](/rules/lib/builtins/toolchain_type)
-* [ToolchainContext](/rules/lib/builtins/ToolchainContext)
-* [transition](/rules/lib/builtins/transition)
-* [wasm_exec_result](/rules/lib/builtins/wasm_exec_result)
-* [wasm_module](/rules/lib/builtins/wasm_module)
\ No newline at end of file
+* [Action](/versions/8.6.0/rules/lib/builtins/Action)
+* [actions](/versions/8.6.0/rules/lib/builtins/actions)
+* [apple_platform](/versions/8.6.0/rules/lib/builtins/apple_platform)
+* [Args](/versions/8.6.0/rules/lib/builtins/Args)
+* [Aspect](/versions/8.6.0/rules/lib/builtins/Aspect)
+* [Attribute](/versions/8.6.0/rules/lib/builtins/Attribute)
+* [bazel_module](/versions/8.6.0/rules/lib/builtins/bazel_module)
+* [bazel_module_tags](/versions/8.6.0/rules/lib/builtins/bazel_module_tags)
+* [BuildSetting](/versions/8.6.0/rules/lib/builtins/BuildSetting)
+* [CcCompilationOutputs](/versions/8.6.0/rules/lib/builtins/CcCompilationOutputs)
+* [CcLinkingOutputs](/versions/8.6.0/rules/lib/builtins/CcLinkingOutputs)
+* [CompilationContext](/versions/8.6.0/rules/lib/builtins/CompilationContext)
+* [configuration](/versions/8.6.0/rules/lib/builtins/configuration)
+* [ctx](/versions/8.6.0/rules/lib/builtins/ctx)
+* [depset](/versions/8.6.0/rules/lib/builtins/depset)
+* [DirectoryExpander](/versions/8.6.0/rules/lib/builtins/DirectoryExpander)
+* [DottedVersion](/versions/8.6.0/rules/lib/builtins/DottedVersion)
+* [exec_result](/versions/8.6.0/rules/lib/builtins/exec_result)
+* [ExecGroupCollection](/versions/8.6.0/rules/lib/builtins/ExecGroupCollection)
+* [ExecGroupContext](/versions/8.6.0/rules/lib/builtins/ExecGroupContext)
+* [ExecTransitionFactory](/versions/8.6.0/rules/lib/builtins/ExecTransitionFactory)
+* [extension_metadata](/versions/8.6.0/rules/lib/builtins/extension_metadata)
+* [Facts](/versions/8.6.0/rules/lib/builtins/Facts)
+* [FeatureConfiguration](/versions/8.6.0/rules/lib/builtins/FeatureConfiguration)
+* [File](/versions/8.6.0/rules/lib/builtins/File)
+* [fragments](/versions/8.6.0/rules/lib/builtins/fragments)
+* [java_annotation_processing](/versions/8.6.0/rules/lib/builtins/java_annotation_processing)
+* [Label](/versions/8.6.0/rules/lib/builtins/Label)
+* [LateBoundDefault](/versions/8.6.0/rules/lib/builtins/LateBoundDefault)
+* [LibraryToLink](/versions/8.6.0/rules/lib/builtins/LibraryToLink)
+* [License](/versions/8.6.0/rules/lib/builtins/License)
+* [LinkerInput](/versions/8.6.0/rules/lib/builtins/LinkerInput)
+* [LinkingContext](/versions/8.6.0/rules/lib/builtins/LinkingContext)
+* [macro](/versions/8.6.0/rules/lib/builtins/macro)
+* [mapped_root](/versions/8.6.0/rules/lib/builtins/mapped_root)
+* [module_ctx](/versions/8.6.0/rules/lib/builtins/module_ctx)
+* [path](/versions/8.6.0/rules/lib/builtins/path)
+* [Provider](/versions/8.6.0/rules/lib/builtins/Provider)
+* [repo_metadata](/versions/8.6.0/rules/lib/builtins/repo_metadata)
+* [repository_ctx](/versions/8.6.0/rules/lib/builtins/repository_ctx)
+* [repository_os](/versions/8.6.0/rules/lib/builtins/repository_os)
+* [repository_rule](/versions/8.6.0/rules/lib/builtins/repository_rule)
+* [root](/versions/8.6.0/rules/lib/builtins/root)
+* [rule](/versions/8.6.0/rules/lib/builtins/rule)
+* [rule_attributes](/versions/8.6.0/rules/lib/builtins/rule_attributes)
+* [runfiles](/versions/8.6.0/rules/lib/builtins/runfiles)
+* [struct](/versions/8.6.0/rules/lib/builtins/struct)
+* [Subrule](/versions/8.6.0/rules/lib/builtins/Subrule)
+* [subrule_ctx](/versions/8.6.0/rules/lib/builtins/subrule_ctx)
+* [SymlinkEntry](/versions/8.6.0/rules/lib/builtins/SymlinkEntry)
+* [tag_class](/versions/8.6.0/rules/lib/builtins/tag_class)
+* [Target](/versions/8.6.0/rules/lib/builtins/Target)
+* [TemplateDict](/versions/8.6.0/rules/lib/builtins/TemplateDict)
+* [toolchain_type](/versions/8.6.0/rules/lib/builtins/toolchain_type)
+* [ToolchainContext](/versions/8.6.0/rules/lib/builtins/ToolchainContext)
+* [transition](/versions/8.6.0/rules/lib/builtins/transition)
+* [wasm_exec_result](/versions/8.6.0/rules/lib/builtins/wasm_exec_result)
+* [wasm_module](/versions/8.6.0/rules/lib/builtins/wasm_module)
\ No newline at end of file
diff --git a/versions/8.6.0/rules/lib/builtins/Action.mdx b/versions/8.6.0/rules/lib/builtins/Action.mdx
index 9ba2879b..031eb8df 100644
--- a/versions/8.6.0/rules/lib/builtins/Action.mdx
+++ b/versions/8.6.0/rules/lib/builtins/Action.mdx
@@ -4,7 +4,7 @@ title: 'Action'
 
 An action created during rule analysis.
 
-This object is visible for the purpose of testing, and may be obtained from an `Actions` provider. It is normally not necessary to access `Action` objects or their fields within a rule's implementation function. You may instead want to see the [Rules page](https://bazel.build/extending/rules#actions) for a general discussion of how to use actions when defining custom rules, or the [API reference](../builtins/actions) for creating actions.
+This object is visible for the purpose of testing, and may be obtained from an `Actions` provider. It is normally not necessary to access `Action` objects or their fields within a rule's implementation function. You may instead want to see the [Rules page](https://bazel.build/versions/8.6.0/extending/rules#actions) for a general discussion of how to use actions when defining custom rules, or the [API reference](/versions/8.6.0/rules/lib/builtins/actions) for creating actions.
 
 Some fields of this object are only applicable for certain kinds of actions. Fields that are inapplicable are set to `None`.
 
@@ -25,7 +25,7 @@ Some fields of this object are only applicable for certain kinds of actions. Fie
 sequence Action.args
 ```
 
-A list of frozen [Args](../builtins/Args) objects containing information about the action arguments. These objects contain accurate argument information, including arguments involving expanded action output directories. However, [Args](../builtins/Args) objects are not readable in the analysis phase. For a less accurate account of arguments which is available in the analysis phase, see [argv](#argv).
+A list of frozen [Args](/versions/8.6.0/rules/lib/builtins/Args) objects containing information about the action arguments. These objects contain accurate argument information, including arguments involving expanded action output directories. However, [Args](/versions/8.6.0/rules/lib/builtins/Args) objects are not readable in the analysis phase. For a less accurate account of arguments which is available in the analysis phase, see [argv](#argv).
 
 Note that some types of actions do not yet support exposure of this field. For such action types, this is `None`.
 May return `None`.
@@ -36,7 +36,7 @@ May return `None`.
 sequence Action.argv
 ```
 
-For actions created by [ctx.actions.run()](../builtins/actions#run) or [ctx.actions.run_shell()](../builtins/actions#run_shell) an immutable list of the arguments for the command line to be executed. Note that for shell actions the first two arguments will be the shell path and `"-c"`.
+For actions created by [ctx.actions.run()](/versions/8.6.0/rules/lib/builtins/actions#run) or [ctx.actions.run_shell()](/versions/8.6.0/rules/lib/builtins/actions#run_shell) an immutable list of the arguments for the command line to be executed. Note that for shell actions the first two arguments will be the shell path and `"-c"`.
 May return `None`.
 
 ## content
@@ -45,7 +45,7 @@ May return `None`.
 string Action.content
 ```
 
-For actions created by [ctx.actions.write()](../builtins/actions#write) or [ctx.actions.expand_template()](../builtins/actions#expand_template), the contents of the file to be written, if those contents can be computed during the analysis phase. The value is `None` if the contents cannot be determined until the execution phase, such as when a directory in an [Args](../builtins/Args) object needs to be expanded.
+For actions created by [ctx.actions.write()](/versions/8.6.0/rules/lib/builtins/actions#write) or [ctx.actions.expand_template()](/versions/8.6.0/rules/lib/builtins/actions#expand_template), the contents of the file to be written, if those contents can be computed during the analysis phase. The value is `None` if the contents cannot be determined until the execution phase, such as when a directory in an [Args](/versions/8.6.0/rules/lib/builtins/Args) object needs to be expanded.
 May return `None`.
 
 ## env
@@ -86,5 +86,5 @@ A set of the output files of this action.
 dict Action.substitutions
 ```
 
-For actions created by [ctx.actions.expand_template()](../builtins/actions#expand_template), an immutable dict holding the substitution mapping.
+For actions created by [ctx.actions.expand_template()](/versions/8.6.0/rules/lib/builtins/actions#expand_template), an immutable dict holding the substitution mapping.
 May return `None`.
\ No newline at end of file
diff --git a/versions/8.6.0/rules/lib/builtins/Args.mdx b/versions/8.6.0/rules/lib/builtins/Args.mdx
index 9410c3c0..4795dd2b 100644
--- a/versions/8.6.0/rules/lib/builtins/Args.mdx
+++ b/versions/8.6.0/rules/lib/builtins/Args.mdx
@@ -4,15 +4,15 @@ title: 'Args'
 
 An object that encapsulates, in a memory-efficient way, the data needed to build part or all of a command line.
 
-It often happens that an action requires a large command line containing values accumulated from transitive dependencies. For example, a linker command line might list every object file needed by all of the libraries being linked. It is best practice to store such transitive data in [`depset`](../builtins/depset)s, so that they can be shared by multiple targets. However, if the rule author had to convert these depsets into lists of strings in order to construct an action command line, it would defeat this memory-sharing optimization.
+It often happens that an action requires a large command line containing values accumulated from transitive dependencies. For example, a linker command line might list every object file needed by all of the libraries being linked. It is best practice to store such transitive data in [`depset`](/versions/8.6.0/rules/lib/builtins/depset)s, so that they can be shared by multiple targets. However, if the rule author had to convert these depsets into lists of strings in order to construct an action command line, it would defeat this memory-sharing optimization.
 
-For this reason, the action-constructing functions accept `Args` objects in addition to strings. Each `Args` object represents a concatenation of strings and depsets, with optional transformations for manipulating the data. `Args` objects do not process the depsets they encapsulate until the execution phase, when it comes time to calculate the command line. This helps defer any expensive copying until after the analysis phase is complete. See the [Optimizing Performance](https://bazel.build/rules/performance) page for more information.
+For this reason, the action-constructing functions accept `Args` objects in addition to strings. Each `Args` object represents a concatenation of strings and depsets, with optional transformations for manipulating the data. `Args` objects do not process the depsets they encapsulate until the execution phase, when it comes time to calculate the command line. This helps defer any expensive copying until after the analysis phase is complete. See the [Optimizing Performance](https://bazel.build/versions/8.6.0/rules/performance) page for more information.
 
-`Args` are constructed by calling [`ctx.actions.args()`](../builtins/actions#args). They can be passed as the `arguments` parameter of [`ctx.actions.run()`](../builtins/actions#run) or [`ctx.actions.run_shell()`](../builtins/actions#run_shell). Each mutation of an `Args` object appends values to the eventual command line.
+`Args` are constructed by calling [`ctx.actions.args()`](/versions/8.6.0/rules/lib/builtins/actions#args). They can be passed as the `arguments` parameter of [`ctx.actions.run()`](/versions/8.6.0/rules/lib/builtins/actions#run) or [`ctx.actions.run_shell()`](/versions/8.6.0/rules/lib/builtins/actions#run_shell). Each mutation of an `Args` object appends values to the eventual command line.
 
 The `map_each` feature allows you to customize how items are transformed into strings. If you do not provide a `map_each` function, the standard conversion is as follows:
 
-* Values that are already strings are left as-is.* [`File`](../builtins/File) objects are turned into their `File.path` values.* [`Label`](../builtins/Label) objects are turned into a string representation that resolves back to the same object when resolved in the context of the main repository. If possible, the string representation uses the apparent name of a repository in favor of the repository's canonical name, which makes this representation suited for use in BUILD files. While the exact form of the representation is not guaranteed, typical examples are `//foo:bar`, `@repo//foo:bar` and `@@canonical_name+//foo:bar.bzl`.* All other types are turned into strings in an *unspecified* manner. For this reason, you should avoid passing values that are not of string or `File` type to `add()`, and if you pass them to `add_all()` or `add_joined()` then you should provide a `map_each` function.
+* Values that are already strings are left as-is.* [`File`](/versions/8.6.0/rules/lib/builtins/File) objects are turned into their `File.path` values.* [`Label`](/versions/8.6.0/rules/lib/builtins/Label) objects are turned into a string representation that resolves back to the same object when resolved in the context of the main repository. If possible, the string representation uses the apparent name of a repository in favor of the repository's canonical name, which makes this representation suited for use in BUILD files. While the exact form of the representation is not guaranteed, typical examples are `//foo:bar`, `@repo//foo:bar` and `@@canonical_name+//foo:bar.bzl`.* All other types are turned into strings in an *unspecified* manner. For this reason, you should avoid passing values that are not of string or `File` type to `add()`, and if you pass them to `add_all()` or `add_joined()` then you should provide a `map_each` function.
 
 When using string formatting (`format`, `format_each`, and `format_joined` params of the `add*()` methods), the format template is interpreted in the same way as `%`-substitution on strings, except that the template must have exactly one substitution placeholder and it must be `%s`. Literal percents may be escaped as `%%`. Formatting is applied after the value is converted to a string as per the above.
 
@@ -64,7 +64,7 @@ Appends an argument to this command line.
 | --- | --- |
 | `arg_name_or_value` | required  If two positional parameters are passed this is interpreted as the arg name. The arg name is added before the value without any processing. If only one positional parameter is passed, it is interpreted as `value` (see below). |
 | `value` | default is `unbound`  The object to append. It will be converted to a string using the standard conversion mentioned above. Since there is no `map_each` parameter for this function, `value` should be either a string or a `File`. A list, tuple, depset, or directory `File` must be passed to [`add_all()` or [`add_joined()`](#add_joined) instead of this method.](#add_all) |
-| `format` | [string](../core/string); or `None`; default is `None`  A format string pattern, to be applied to the stringified version of `value`. |
+| `format` | [string](/versions/8.6.0/rules/lib/core/string); or `None`; default is `None`  A format string pattern, to be applied to the stringified version of `value`. |
 
 ## add_all
 
@@ -86,15 +86,15 @@ Note that empty strings are valid arguments that are subject to all these proces
 | Parameter | Description |
 | --- | --- |
 | `arg_name_or_values` | required  If two positional parameters are passed this is interpreted as the arg name. The arg name is added before the `values` as a separate argument without any processing. This arg name will not be added if `omit_if_empty` is true (the default) and no other items are appended (as happens if `values` is empty or all of its items are filtered). If only one positional parameter is passed, it is interpreted as `values` (see below). |
-| `values` | [sequence](../core/list); or [depset](../builtins/depset); default is `unbound`  The list, tuple, or depset whose items will be appended. |
-| `map_each` | callable; or `None`; default is `None`  A function that converts each item to zero or more strings, which may be further processed before appending. If this param is not provided, the standard conversion is used. The function is passed either one or two positional arguments: the item to convert, followed by an optional [`DirectoryExpander`](../builtins/DirectoryExpander). The second argument will be passed only if the supplied function is user-defined (not built-in) and declares more than one parameter. The return value's type depends on how many arguments are to be produced for the item:  * In the common case when each item turns into one string, the function should return that string.* If the item is to be filtered out entirely, the function should return `None`.* If the item turns into multiple strings, the function returns a list of those strings.  Returning a single string or `None` has the same effect as returning a list of length 1 or length 0 respectively. However, it is more efficient and readable to avoid creating a list where it is not needed. Ordinarily, items that are directories are automatically expanded to their contents when `expand_directories=True` is set. However, this will not expand directories contained inside other values -- for instance, when the items are structs that have directories as fields. In this situation, the `DirectoryExpander` argument can be applied to manually obtain the files of a given directory. To avoid unintended retention of large analysis-phase data structures into the execution phase, the `map_each` function must be declared by a top-level `def` statement; it may not be a nested function closure by default. *Warning:* [`print()`](../globals/all#print) statements that are executed during the call to `map_each` will not produce any visible output. |
-| `format_each` | [string](../core/string); or `None`; default is `None`  An optional format string pattern, applied to each string returned by the `map_each` function. The format string must have exactly one '%s' placeholder. |
-| `before_each` | [string](../core/string); or `None`; default is `None`  An optional argument to append before each argument derived from `values` is appended. |
-| `omit_if_empty` | [bool](../core/bool); default is `True`  If true, if there are no arguments derived from `values` to be appended, then all further processing is suppressed and the command line will be unchanged. If false, the arg name and `terminate_with`, if provided, will still be appended regardless of whether or not there are other arguments. |
-| `uniquify` | [bool](../core/bool); default is `False`  If true, duplicate arguments that are derived from `values` will be omitted. Only the first occurrence of each argument will remain. Usually this feature is not needed because depsets already omit duplicates, but it can be useful if `map_each` emits the same string for multiple items. |
-| `expand_directories` | [bool](../core/bool); default is `True`  If true, any directories in `values` will be expanded to a flat list of files. This happens before `map_each` is applied. |
-| `terminate_with` | [string](../core/string); or `None`; default is `None`  An optional argument to append after all other arguments. This argument will not be added if `omit_if_empty` is true (the default) and no other items are appended (as happens if `values` is empty or all of its items are filtered). |
-| `allow_closure` | [bool](../core/bool); default is `False`  If true, allows the use of closures in function parameters like `map_each`. Usually this isn't necessary and it risks retaining large analysis-phase data structures into the execution phase. |
+| `values` | [sequence](/versions/8.6.0/rules/lib/core/list); or [depset](/versions/8.6.0/rules/lib/builtins/depset); default is `unbound`  The list, tuple, or depset whose items will be appended. |
+| `map_each` | callable; or `None`; default is `None`  A function that converts each item to zero or more strings, which may be further processed before appending. If this param is not provided, the standard conversion is used. The function is passed either one or two positional arguments: the item to convert, followed by an optional [`DirectoryExpander`](/versions/8.6.0/rules/lib/builtins/DirectoryExpander). The second argument will be passed only if the supplied function is user-defined (not built-in) and declares more than one parameter. The return value's type depends on how many arguments are to be produced for the item:  * In the common case when each item turns into one string, the function should return that string.* If the item is to be filtered out entirely, the function should return `None`.* If the item turns into multiple strings, the function returns a list of those strings.  Returning a single string or `None` has the same effect as returning a list of length 1 or length 0 respectively. However, it is more efficient and readable to avoid creating a list where it is not needed. Ordinarily, items that are directories are automatically expanded to their contents when `expand_directories=True` is set. However, this will not expand directories contained inside other values -- for instance, when the items are structs that have directories as fields. In this situation, the `DirectoryExpander` argument can be applied to manually obtain the files of a given directory. To avoid unintended retention of large analysis-phase data structures into the execution phase, the `map_each` function must be declared by a top-level `def` statement; it may not be a nested function closure by default. *Warning:* [`print()`](/versions/8.6.0/rules/lib/globals/all#print) statements that are executed during the call to `map_each` will not produce any visible output. |
+| `format_each` | [string](/versions/8.6.0/rules/lib/core/string); or `None`; default is `None`  An optional format string pattern, applied to each string returned by the `map_each` function. The format string must have exactly one '%s' placeholder. |
+| `before_each` | [string](/versions/8.6.0/rules/lib/core/string); or `None`; default is `None`  An optional argument to append before each argument derived from `values` is appended. |
+| `omit_if_empty` | [bool](/versions/8.6.0/rules/lib/core/bool); default is `True`  If true, if there are no arguments derived from `values` to be appended, then all further processing is suppressed and the command line will be unchanged. If false, the arg name and `terminate_with`, if provided, will still be appended regardless of whether or not there are other arguments. |
+| `uniquify` | [bool](/versions/8.6.0/rules/lib/core/bool); default is `False`  If true, duplicate arguments that are derived from `values` will be omitted. Only the first occurrence of each argument will remain. Usually this feature is not needed because depsets already omit duplicates, but it can be useful if `map_each` emits the same string for multiple items. |
+| `expand_directories` | [bool](/versions/8.6.0/rules/lib/core/bool); default is `True`  If true, any directories in `values` will be expanded to a flat list of files. This happens before `map_each` is applied. |
+| `terminate_with` | [string](/versions/8.6.0/rules/lib/core/string); or `None`; default is `None`  An optional argument to append after all other arguments. This argument will not be added if `omit_if_empty` is true (the default) and no other items are appended (as happens if `values` is empty or all of its items are filtered). |
+| `allow_closure` | [bool](/versions/8.6.0/rules/lib/core/bool); default is `False`  If true, allows the use of closures in function parameters like `map_each`. Usually this isn't necessary and it risks retaining large analysis-phase data structures into the execution phase. |
 
 ## add_joined
 
@@ -113,15 +113,15 @@ If after filtering there are no strings to join into an argument, and if `omit_i
 | Parameter | Description |
 | --- | --- |
 | `arg_name_or_values` | required  If two positional parameters are passed this is interpreted as the arg name. The arg name is added before `values` without any processing. This arg will not be added if `omit_if_empty` is true (the default) and there are no strings derived from `values` to join together (which can happen if `values` is empty or all of its items are filtered). If only one positional parameter is passed, it is interpreted as `values` (see below). |
-| `values` | [sequence](../core/list); or [depset](../builtins/depset); default is `unbound`  The list, tuple, or depset whose items will be joined. |
-| `join_with` | [string](../core/string); required  A delimiter string used to join together the strings obtained from applying `map_each` and `format_each`, in the same manner as [`string.join()`](../core/string#join). |
+| `values` | [sequence](/versions/8.6.0/rules/lib/core/list); or [depset](/versions/8.6.0/rules/lib/builtins/depset); default is `unbound`  The list, tuple, or depset whose items will be joined. |
+| `join_with` | [string](/versions/8.6.0/rules/lib/core/string); required  A delimiter string used to join together the strings obtained from applying `map_each` and `format_each`, in the same manner as [`string.join()`](/versions/8.6.0/rules/lib/core/string#join). |
 | `map_each` | callable; or `None`; default is `None`  Same as for [`add_all`](#add_all.map_each). |
-| `format_each` | [string](../core/string); or `None`; default is `None`  Same as for [`add_all`](#add_all.format_each). |
-| `format_joined` | [string](../core/string); or `None`; default is `None`  An optional format string pattern applied to the joined string. The format string must have exactly one '%s' placeholder. |
-| `omit_if_empty` | [bool](../core/bool); default is `True`  If true, if there are no strings to join together (either because `values` is empty or all its items are filtered), then all further processing is suppressed and the command line will be unchanged. If false, then even if there are no strings to join together, two arguments will be appended: the arg name followed by an empty string (which is the logical join of zero strings). |
-| `uniquify` | [bool](../core/bool); default is `False`  Same as for [`add_all`](#add_all.uniquify). |
-| `expand_directories` | [bool](../core/bool); default is `True`  Same as for [`add_all`](#add_all.expand_directories). |
-| `allow_closure` | [bool](../core/bool); default is `False`  Same as for [`add_all`](#add_all.allow_closure). |
+| `format_each` | [string](/versions/8.6.0/rules/lib/core/string); or `None`; default is `None`  Same as for [`add_all`](#add_all.format_each). |
+| `format_joined` | [string](/versions/8.6.0/rules/lib/core/string); or `None`; default is `None`  An optional format string pattern applied to the joined string. The format string must have exactly one '%s' placeholder. |
+| `omit_if_empty` | [bool](/versions/8.6.0/rules/lib/core/bool); default is `True`  If true, if there are no strings to join together (either because `values` is empty or all its items are filtered), then all further processing is suppressed and the command line will be unchanged. If false, then even if there are no strings to join together, two arguments will be appended: the arg name followed by an empty string (which is the logical join of zero strings). |
+| `uniquify` | [bool](/versions/8.6.0/rules/lib/core/bool); default is `False`  Same as for [`add_all`](#add_all.uniquify). |
+| `expand_directories` | [bool](/versions/8.6.0/rules/lib/core/bool); default is `True`  Same as for [`add_all`](#add_all.expand_directories). |
+| `allow_closure` | [bool](/versions/8.6.0/rules/lib/core/bool); default is `False`  Same as for [`add_all`](#add_all.allow_closure). |
 
 ## set_param_file_format
 
@@ -135,7 +135,7 @@ Sets the format of the param file, if one is used
 
 | Parameter | Description |
 | --- | --- |
-| `format` | [string](../core/string); required  Must be one of:  * "multiline": Each item (argument name or value) is written verbatim to the param file with a newline character following it. * "shell": Same as "multiline", but the items are shell-quoted * "flag_per_line": Same as "multiline", but (1) only flags (beginning with '--') are written to the param file, and (2) the values of the flags, if any, are written on the same line with a '=' separator. This is the format expected by the Abseil flags library.   The format defaults to "shell" if not called. |
+| `format` | [string](/versions/8.6.0/rules/lib/core/string); required  Must be one of:  * "multiline": Each item (argument name or value) is written verbatim to the param file with a newline character following it. * "shell": Same as "multiline", but the items are shell-quoted * "flag_per_line": Same as "multiline", but (1) only flags (beginning with '--') are written to the param file, and (2) the values of the flags, if any, are written on the same line with a '=' separator. This is the format expected by the Abseil flags library.   The format defaults to "shell" if not called. |
 
 ## use_param_file
 
@@ -151,5 +151,5 @@ Bazel may choose to elide writing the params file to the output tree during exec
 
 | Parameter | Description |
 | --- | --- |
-| `param_file_arg` | [string](../core/string); required  A format string with a single "%s". If the args are spilled to a params file then they are replaced with an argument consisting of this string formatted with the path of the params file. For example, if the args are spilled to a params file "params.txt", then specifying "--file=%s" would cause the action command line to contain "--file=params.txt". |
-| `use_always` | [bool](../core/bool); default is `False`  Whether to always spill the args to a params file. If false, bazel will decide whether the arguments need to be spilled based on your system and arg length. |
\ No newline at end of file
+| `param_file_arg` | [string](/versions/8.6.0/rules/lib/core/string); required  A format string with a single "%s". If the args are spilled to a params file then they are replaced with an argument consisting of this string formatted with the path of the params file. For example, if the args are spilled to a params file "params.txt", then specifying "--file=%s" would cause the action command line to contain "--file=params.txt". |
+| `use_always` | [bool](/versions/8.6.0/rules/lib/core/bool); default is `False`  Whether to always spill the args to a params file. If false, bazel will decide whether the arguments need to be spilled based on your system and arg length. |
\ No newline at end of file
diff --git a/versions/8.6.0/rules/lib/builtins/Aspect.mdx b/versions/8.6.0/rules/lib/builtins/Aspect.mdx
index 5d111100..d6edd05a 100644
--- a/versions/8.6.0/rules/lib/builtins/Aspect.mdx
+++ b/versions/8.6.0/rules/lib/builtins/Aspect.mdx
@@ -3,4 +3,4 @@ title: 'Aspect'
 ---
 
 For more information about Aspects, please consult the
-[documentation of the aspect function](../globals/bzl#aspect) or the [introduction to Aspects](https://bazel.build/rules/aspects).
\ No newline at end of file
+[documentation of the aspect function](/versions/8.6.0/rules/lib/globals/bzl#aspect) or the [introduction to Aspects](https://bazel.build/versions/8.6.0/rules/aspects).
\ No newline at end of file
diff --git a/versions/8.6.0/rules/lib/builtins/Attribute.mdx b/versions/8.6.0/rules/lib/builtins/Attribute.mdx
index 18486c41..39d4b072 100644
--- a/versions/8.6.0/rules/lib/builtins/Attribute.mdx
+++ b/versions/8.6.0/rules/lib/builtins/Attribute.mdx
@@ -2,4 +2,4 @@
 title: 'Attribute'
 ---
 
-Representation of a definition of an attribute. Use the [attr](../toplevel/attr) module to create an Attribute. They are only for use with a [rule](../globals/bzl#rule) or an [aspect](../globals/bzl#aspect).
\ No newline at end of file
+Representation of a definition of an attribute. Use the [attr](/versions/8.6.0/rules/lib/toplevel/attr) module to create an Attribute. They are only for use with a [rule](/versions/8.6.0/rules/lib/globals/bzl#rule) or an [aspect](/versions/8.6.0/rules/lib/globals/bzl#aspect).
\ No newline at end of file
diff --git a/versions/8.6.0/rules/lib/builtins/DirectoryExpander.mdx b/versions/8.6.0/rules/lib/builtins/DirectoryExpander.mdx
index 8bf9ae69..3a5223d7 100644
--- a/versions/8.6.0/rules/lib/builtins/DirectoryExpander.mdx
+++ b/versions/8.6.0/rules/lib/builtins/DirectoryExpander.mdx
@@ -2,7 +2,7 @@
 title: 'DirectoryExpander'
 ---
 
-Expands directories created by [`ctx.actions.declare_directory`](../builtins/actions#declare_directory) during the execution phase. This is useful to expand directories in [`map_each`](../builtins/Args#add_all.map_each).
+Expands directories created by [`ctx.actions.declare_directory`](/versions/8.6.0/rules/lib/builtins/actions#declare_directory) during the execution phase. This is useful to expand directories in [`map_each`](/versions/8.6.0/rules/lib/builtins/Args#add_all.map_each).
 
 ## Members
 
@@ -20,4 +20,4 @@ If the given `File` is a directory, this returns a list of `File`s recursively u
 
 | Parameter | Description |
 | --- | --- |
-| `file` | [File](../builtins/File); required  The directory or file to expand. |
\ No newline at end of file
+| `file` | [File](/versions/8.6.0/rules/lib/builtins/File); required  The directory or file to expand. |
\ No newline at end of file
diff --git a/versions/8.6.0/rules/lib/builtins/DottedVersion.mdx b/versions/8.6.0/rules/lib/builtins/DottedVersion.mdx
index bf0133ff..4bdf9b04 100644
--- a/versions/8.6.0/rules/lib/builtins/DottedVersion.mdx
+++ b/versions/8.6.0/rules/lib/builtins/DottedVersion.mdx
@@ -20,4 +20,4 @@ Compares based on most significant (first) not-matching version component. So, f
 
 | Parameter | Description |
 | --- | --- |
-| `other` | [DottedVersion](../builtins/DottedVersion); required  The other dotted version. |
\ No newline at end of file
+| `other` | [DottedVersion](/versions/8.6.0/rules/lib/builtins/DottedVersion); required  The other dotted version. |
\ No newline at end of file
diff --git a/versions/8.6.0/rules/lib/builtins/Facts.mdx b/versions/8.6.0/rules/lib/builtins/Facts.mdx
index f88937d4..6ef706f7 100644
--- a/versions/8.6.0/rules/lib/builtins/Facts.mdx
+++ b/versions/8.6.0/rules/lib/builtins/Facts.mdx
@@ -24,5 +24,5 @@ Returns the value for `key` if it exists, or `default`.
 
 | Parameter | Description |
 | --- | --- |
-| `key` | [string](../core/string); required  The key to look up. |
+| `key` | [string](/versions/8.6.0/rules/lib/core/string); required  The key to look up. |
 | `default` | default is `None`  The value to return if `key` is not present. |
\ No newline at end of file
diff --git a/versions/8.6.0/rules/lib/builtins/File.mdx b/versions/8.6.0/rules/lib/builtins/File.mdx
index b5821c92..df7c4fa8 100644
--- a/versions/8.6.0/rules/lib/builtins/File.mdx
+++ b/versions/8.6.0/rules/lib/builtins/File.mdx
@@ -2,9 +2,9 @@
 title: 'File'
 ---
 
-This object is created during the analysis phase to represent a file or directory that will be read or written during the execution phase. It is not an open file handle, and cannot be used to directly read or write file contents. Rather, you use it to construct the action graph in a rule implementation function by passing it to action-creating functions. See the [Rules page](https://bazel.build/extending/rules#files) for more information.
+This object is created during the analysis phase to represent a file or directory that will be read or written during the execution phase. It is not an open file handle, and cannot be used to directly read or write file contents. Rather, you use it to construct the action graph in a rule implementation function by passing it to action-creating functions. See the [Rules page](https://bazel.build/versions/8.6.0/extending/rules#files) for more information.
 
-When a `File` is passed to an [`Args`](../builtins/Args) object without using a `map_each` function, it is converted to a string by taking the value of its `path` field.
+When a `File` is passed to an [`Args`](/versions/8.6.0/rules/lib/builtins/Args) object without using a `map_each` function, it is converted to a string by taking the value of its `path` field.
 
 ## Members
 
@@ -83,7 +83,7 @@ May return `None`.
 string File.path
 ```
 
-The execution path of this file, relative to the workspace's execution directory. It consists of two parts, an optional first part called the *root* (see also the [root](../builtins/root) module), and the second part which is the `short_path`. The root may be empty, which it usually is for non-generated files. For generated files it usually contains a configuration-specific path fragment that encodes things like the target CPU architecture that was used while building said file. Use the `short_path` for the path under which the file is mapped if it's in the runfiles of a binary.
+The execution path of this file, relative to the workspace's execution directory. It consists of two parts, an optional first part called the *root* (see also the [root](/versions/8.6.0/rules/lib/builtins/root) module), and the second part which is the `short_path`. The root may be empty, which it usually is for non-generated files. For generated files it usually contains a configuration-specific path fragment that encodes things like the target CPU architecture that was used while building said file. Use the `short_path` for the path under which the file is mapped if it's in the runfiles of a binary.
 
 ## root
 
@@ -107,4 +107,4 @@ The path of this file relative to its root. This excludes the aforementioned *ro
 string File.tree_relative_path
 ```
 
-The path of this file relative to the root of the ancestor's tree, if the ancestor's [is_directory](#is_directory) field is true. `tree_relative_path` is only available for expanded files of a directory in an action command, i.e. [Args.add_all()](../builtins/Args#add_all). For other types of files, it is an error to access this field.
\ No newline at end of file
+The path of this file relative to the root of the ancestor's tree, if the ancestor's [is_directory](#is_directory) field is true. `tree_relative_path` is only available for expanded files of a directory in an action command, i.e. [Args.add_all()](/versions/8.6.0/rules/lib/builtins/Args#add_all). For other types of files, it is an error to access this field.
\ No newline at end of file
diff --git a/versions/8.6.0/rules/lib/builtins/Label.mdx b/versions/8.6.0/rules/lib/builtins/Label.mdx
index 8e582ab5..a334fc90 100644
--- a/versions/8.6.0/rules/lib/builtins/Label.mdx
+++ b/versions/8.6.0/rules/lib/builtins/Label.mdx
@@ -6,7 +6,7 @@ A BUILD target identifier.
 
 For every `Label` instance `l`, the string representation `str(l)` has the property that `Label(str(l)) == l`, regardless of where the `Label()` call occurs.
 
-When passed as positional arguments to `print()` or `fail()`, `Label` use a string representation optimized for human readability instead. This representation uses an [apparent repository name](/external/overview#apparent-repo-name) from the perspective of the main repository if possible.
+When passed as positional arguments to `print()` or `fail()`, `Label` use a string representation optimized for human readability instead. This representation uses an [apparent repository name](/versions/8.6.0/external/overview#apparent-repo-name) from the perspective of the main repository if possible.
 
 ## Members
 
@@ -33,7 +33,7 @@ For macros, a related function, `native.package_relative_label()`, converts the
 
 | Parameter | Description |
 | --- | --- |
-| `input` | [string](../core/string); or [Label](../builtins/Label); required  The input label string or Label object. If a Label object is passed, it's returned as is. |
+| `input` | [string](/versions/8.6.0/rules/lib/core/string); or [Label](/versions/8.6.0/rules/lib/builtins/Label); required  The input label string or Label object. If a Label object is passed, it's returned as is. |
 
 ## name
 
@@ -66,7 +66,7 @@ Label Label.relative(relName)
 ```
 
 **Experimental**. This API is experimental and may change at any time. Please do not depend on it. It may be enabled on an experimental basis by setting `--+incompatible_enable_deprecated_label_apis`
-**Deprecated.** This method behaves surprisingly when used with an argument containing an apparent repo name. Prefer [`Label.same_package_label()`](#same_package_label), [`native.package_relative_label()`](../toplevel/native#package_relative_label), or [`Label()`](#Label) instead.
+**Deprecated.** This method behaves surprisingly when used with an argument containing an apparent repo name. Prefer [`Label.same_package_label()`](#same_package_label), [`native.package_relative_label()`](/versions/8.6.0/rules/lib/toplevel/native#package_relative_label), or [`Label()`](#Label) instead.
 
 Resolves a label that is either absolute (starts with `//`) or relative to the current package. If this label is in a remote repository, the argument will be resolved relative to that repository. If the argument contains a repository name, the current label is ignored and the argument is returned as-is, except that the repository name is rewritten if it is in the current repository mapping. Reserved labels will also be returned as-is.
 For example:
@@ -89,7 +89,7 @@ Label("@repo//foo/bar:baz").relative("@other//wiz:quux") == Label("@remapped//wi
 
 | Parameter | Description |
 | --- | --- |
-| `relName` | [string](../core/string); required |
+| `relName` | [string](/versions/8.6.0/rules/lib/core/string); required |
 
 ## repo_name
 
@@ -115,7 +115,7 @@ Creates a label in the same package as this label with the given target name.
 
 | Parameter | Description |
 | --- | --- |
-| `target_name` | [string](../core/string); required |
+| `target_name` | [string](/versions/8.6.0/rules/lib/core/string); required |
 
 ## workspace_name
 
diff --git a/versions/8.6.0/rules/lib/builtins/LateBoundDefault.mdx b/versions/8.6.0/rules/lib/builtins/LateBoundDefault.mdx
index c418408b..dbf7a953 100644
--- a/versions/8.6.0/rules/lib/builtins/LateBoundDefault.mdx
+++ b/versions/8.6.0/rules/lib/builtins/LateBoundDefault.mdx
@@ -4,4 +4,4 @@ title: 'LateBoundDefault'
 
 Represents a late-bound default attribute value of type 'Label'. The value of a LateBoundDefault is only resolvable in the context of a rule implementation function, and depends on the current build configuration. For example, a LateBoundDefault might represent the Label of the java toolchain in the current build configuration.
 
-See [configuration_field](../globals/bzl#configuration_field) for example usage.
\ No newline at end of file
+See [configuration_field](/versions/8.6.0/rules/lib/globals/bzl#configuration_field) for example usage.
\ No newline at end of file
diff --git a/versions/8.6.0/rules/lib/builtins/Provider.mdx b/versions/8.6.0/rules/lib/builtins/Provider.mdx
index 54b9cf36..a8c3b6e6 100644
--- a/versions/8.6.0/rules/lib/builtins/Provider.mdx
+++ b/versions/8.6.0/rules/lib/builtins/Provider.mdx
@@ -14,7 +14,7 @@ This value has a dual purpose:
   ```
 
   Note: Some providers, defined internally, do not allow instance creation
-* It is a *key* to access a provider instance on a [Target](../builtins/Target)
+* It is a *key* to access a provider instance on a [Target](/versions/8.6.0/rules/lib/builtins/Target)
 
   ```
   DataInfo = provider()
@@ -22,4 +22,4 @@ This value has a dual purpose:
     ... ctx.attr.dep[DataInfo]
   ```
 
-Create a new `Provider` using the [provider](../globals/bzl#provider) function.
\ No newline at end of file
+Create a new `Provider` using the [provider](/versions/8.6.0/rules/lib/globals/bzl#provider) function.
\ No newline at end of file
diff --git a/versions/8.6.0/rules/lib/builtins/Target.mdx b/versions/8.6.0/rules/lib/builtins/Target.mdx
index 6317a7ad..a519bd21 100644
--- a/versions/8.6.0/rules/lib/builtins/Target.mdx
+++ b/versions/8.6.0/rules/lib/builtins/Target.mdx
@@ -2,7 +2,7 @@
 title: 'Target'
 ---
 
-The BUILD target for a dependency. Appears in the fields of `ctx.attr` corresponding to [dependency attributes](https://bazel.build/extending/rules#dependency_attributes) (`label` or `label_list`). Has the following fields:
+The BUILD target for a dependency. Appears in the fields of `ctx.attr` corresponding to [dependency attributes](https://bazel.build/versions/8.6.0/extending/rules#dependency_attributes) (`label` or `label_list`). Has the following fields:
 
 * ### label
 
@@ -10,4 +10,4 @@ The BUILD target for a dependency. Appears in the fields of `ctx.attr` correspon
   The identifier of the target.
 * ### Providers
 
-  The [providers](https://bazel.build/extending/rules#providers) of a rule target can be accessed by type using index notation (`target[DefaultInfo]`). The presence of providers can be checked using the `in` operator (`SomeInfo in target`).
\ No newline at end of file
+  The [providers](https://bazel.build/versions/8.6.0/extending/rules#providers) of a rule target can be accessed by type using index notation (`target[DefaultInfo]`). The presence of providers can be checked using the `in` operator (`SomeInfo in target`).
\ No newline at end of file
diff --git a/versions/8.6.0/rules/lib/builtins/TemplateDict.mdx b/versions/8.6.0/rules/lib/builtins/TemplateDict.mdx
index 453f2e9d..5d5732e1 100644
--- a/versions/8.6.0/rules/lib/builtins/TemplateDict.mdx
+++ b/versions/8.6.0/rules/lib/builtins/TemplateDict.mdx
@@ -21,8 +21,8 @@ Add a String value
 
 | Parameter | Description |
 | --- | --- |
-| `key` | [string](../core/string); required  A String key |
-| `value` | [string](../core/string); required  A String value |
+| `key` | [string](/versions/8.6.0/rules/lib/core/string); required  A String key |
+| `value` | [string](/versions/8.6.0/rules/lib/core/string); required  A String value |
 
 ## add_joined
 
@@ -36,10 +36,10 @@ Add depset of values
 
 | Parameter | Description |
 | --- | --- |
-| `key` | [string](../core/string); required  A String key |
-| `values` | [depset](../builtins/depset); required  The depset whose items will be joined. |
-| `join_with` | [string](../core/string); required  A delimiter string used to join together the strings obtained from applying `map_each`, in the same manner as [`string.join()`](../core/string#join). |
+| `key` | [string](/versions/8.6.0/rules/lib/core/string); required  A String key |
+| `values` | [depset](/versions/8.6.0/rules/lib/builtins/depset); required  The depset whose items will be joined. |
+| `join_with` | [string](/versions/8.6.0/rules/lib/core/string); required  A delimiter string used to join together the strings obtained from applying `map_each`, in the same manner as [`string.join()`](/versions/8.6.0/rules/lib/core/string#join). |
 | `map_each` | callable; required  A Starlark function accepting a single argument and returning either a string, `None`, or a list of strings. This function is applied to each item of the depset specified in the `values` parameter |
-| `uniquify` | [bool](../core/bool); default is `False`  If true, duplicate strings derived from `values` will be omitted. Only the first occurrence of each string will remain. Usually this feature is not needed because depsets already omit duplicates, but it can be useful if `map_each` emits the same string for multiple items. |
-| `format_joined` | [string](../core/string); or `None`; default is `None`  An optional format string pattern applied to the joined string. The format string must have exactly one '%s' placeholder. |
-| `allow_closure` | [bool](../core/bool); default is `False`  If true, allows the use of closures in function parameters like `map_each`. Usually this isn't necessary and it risks retaining large analysis-phase data structures into the execution phase. |
\ No newline at end of file
+| `uniquify` | [bool](/versions/8.6.0/rules/lib/core/bool); default is `False`  If true, duplicate strings derived from `values` will be omitted. Only the first occurrence of each string will remain. Usually this feature is not needed because depsets already omit duplicates, but it can be useful if `map_each` emits the same string for multiple items. |
+| `format_joined` | [string](/versions/8.6.0/rules/lib/core/string); or `None`; default is `None`  An optional format string pattern applied to the joined string. The format string must have exactly one '%s' placeholder. |
+| `allow_closure` | [bool](/versions/8.6.0/rules/lib/core/bool); default is `False`  If true, allows the use of closures in function parameters like `map_each`. Usually this isn't necessary and it risks retaining large analysis-phase data structures into the execution phase. |
\ No newline at end of file
diff --git a/versions/8.6.0/rules/lib/builtins/actions.mdx b/versions/8.6.0/rules/lib/builtins/actions.mdx
index 38d0cf61..16a3c6e6 100644
--- a/versions/8.6.0/rules/lib/builtins/actions.mdx
+++ b/versions/8.6.0/rules/lib/builtins/actions.mdx
@@ -2,7 +2,7 @@
 title: 'actions'
 ---
 
-Module providing functions to create actions. Access this module using [`ctx.actions`](../builtins/ctx#actions).
+Module providing functions to create actions. Access this module using [`ctx.actions`](/versions/8.6.0/rules/lib/builtins/ctx#actions).
 
 ## Members
 
@@ -32,14 +32,14 @@ Returns an Args object that can be used to build memory-efficient command lines.
 File actions.declare_directory(filename, *, sibling=None)
 ```
 
-Declares that the rule or aspect creates a directory with the given name, in the current package. You must create an action that generates the directory. The contents of the directory are not directly accessible from Starlark, but can be expanded in an action command with [`Args.add_all()`](../builtins/Args#add_all). Only regular files and directories can be in the expanded contents of a declare_directory.
+Declares that the rule or aspect creates a directory with the given name, in the current package. You must create an action that generates the directory. The contents of the directory are not directly accessible from Starlark, but can be expanded in an action command with [`Args.add_all()`](/versions/8.6.0/rules/lib/builtins/Args#add_all). Only regular files and directories can be in the expanded contents of a declare_directory.
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `filename` | [string](../core/string); required  If no 'sibling' provided, path of the new directory, relative to the current package. Otherwise a base name for a file ('sibling' defines a directory). |
-| `sibling` | [File](../builtins/File); or `None`; default is `None`  A file that lives in the same directory as the newly declared directory. The file must be in the current package. |
+| `filename` | [string](/versions/8.6.0/rules/lib/core/string); required  If no 'sibling' provided, path of the new directory, relative to the current package. Otherwise a base name for a file ('sibling' defines a directory). |
+| `sibling` | [File](/versions/8.6.0/rules/lib/builtins/File); or `None`; default is `None`  A file that lives in the same directory as the newly declared directory. The file must be in the current package. |
 
 ## declare_file
 
@@ -51,14 +51,14 @@ Declares that the rule or aspect creates a file with the given filename. If `sib
 
 Remember that in addition to declaring a file, you must separately create an action that emits the file. Creating that action will require passing the returned `File` object to the action's construction function.
 
-Note that [predeclared output files](https://bazel.build/extending/rules#files) do not need to be (and cannot be) declared using this function. You can obtain their `File` objects from [`ctx.outputs`](../builtins/ctx#outputs) instead. [See example of use](https://github.com/bazelbuild/examples/tree/main/rules/computed_dependencies/hash.bzl).
+Note that [predeclared output files](https://bazel.build/versions/8.6.0/extending/rules#files) do not need to be (and cannot be) declared using this function. You can obtain their `File` objects from [`ctx.outputs`](/versions/8.6.0/rules/lib/builtins/ctx#outputs) instead. [See example of use](https://github.com/bazelbuild/examples/tree/main/rules/computed_dependencies/hash.bzl).
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `filename` | [string](../core/string); required  If no 'sibling' provided, path of the new file, relative to the current package. Otherwise a base name for a file ('sibling' determines a directory). |
-| `sibling` | [File](../builtins/File); or `None`; default is `None`  A file that lives in the same directory as the newly created file. The file must be in the current package. |
+| `filename` | [string](/versions/8.6.0/rules/lib/core/string); required  If no 'sibling' provided, path of the new file, relative to the current package. Otherwise a base name for a file ('sibling' determines a directory). |
+| `sibling` | [File](/versions/8.6.0/rules/lib/builtins/File); or `None`; default is `None`  A file that lives in the same directory as the newly created file. The file must be in the current package. |
 
 ## declare_symlink
 
@@ -72,8 +72,8 @@ Declares that the rule or aspect creates a symlink with the given name in the cu
 
 | Parameter | Description |
 | --- | --- |
-| `filename` | [string](../core/string); required  If no 'sibling' provided, path of the new symlink, relative to the current package. Otherwise a base name for a file ('sibling' defines a directory). |
-| `sibling` | [File](../builtins/File); or `None`; default is `None`  A file that lives in the same directory as the newly declared symlink. |
+| `filename` | [string](/versions/8.6.0/rules/lib/core/string); required  If no 'sibling' provided, path of the new symlink, relative to the current package. Otherwise a base name for a file ('sibling' defines a directory). |
+| `sibling` | [File](/versions/8.6.0/rules/lib/builtins/File); or `None`; default is `None`  A file that lives in the same directory as the newly declared symlink. |
 
 ## do_nothing
 
@@ -87,8 +87,8 @@ Creates an empty action that neither executes a command nor produces any output,
 
 | Parameter | Description |
 | --- | --- |
-| `mnemonic` | [string](../core/string); required  A one-word description of the action, for example, CppCompile or GoLink. |
-| `inputs` | [sequence](../core/list) of [File](../builtins/File)s; or [depset](../builtins/depset); default is `[]`  List of the input files of the action. |
+| `mnemonic` | [string](/versions/8.6.0/rules/lib/core/string); required  A one-word description of the action, for example, CppCompile or GoLink. |
+| `inputs` | [sequence](/versions/8.6.0/rules/lib/core/list) of [File](/versions/8.6.0/rules/lib/builtins/File)s; or [depset](/versions/8.6.0/rules/lib/builtins/depset); default is `[]`  List of the input files of the action. |
 
 ## expand_template
 
@@ -102,11 +102,11 @@ Creates a template expansion action. When the action is executed, it will genera
 
 | Parameter | Description |
 | --- | --- |
-| `template` | [File](../builtins/File); required  The template file, which is a UTF-8 encoded text file. |
-| `output` | [File](../builtins/File); required  The output file, which is a UTF-8 encoded text file. |
-| `substitutions` | [dict](../core/dict); default is `{}`  Substitutions to make when expanding the template. |
-| `is_executable` | [bool](../core/bool); default is `False`  Whether the output file should be executable. |
-| `computed_substitutions` | [TemplateDict](../builtins/TemplateDict); default is `unbound`  Substitutions to make when expanding the template. |
+| `template` | [File](/versions/8.6.0/rules/lib/builtins/File); required  The template file, which is a UTF-8 encoded text file. |
+| `output` | [File](/versions/8.6.0/rules/lib/builtins/File); required  The output file, which is a UTF-8 encoded text file. |
+| `substitutions` | [dict](/versions/8.6.0/rules/lib/core/dict); default is `{}`  Substitutions to make when expanding the template. |
+| `is_executable` | [bool](/versions/8.6.0/rules/lib/core/bool); default is `False`  Whether the output file should be executable. |
+| `computed_substitutions` | [TemplateDict](/versions/8.6.0/rules/lib/builtins/TemplateDict); default is `unbound`  Substitutions to make when expanding the template. |
 
 ## run
 
@@ -120,22 +120,22 @@ Creates an action that runs an executable. [See example of use](https://github.c
 
 | Parameter | Description |
 | --- | --- |
-| `outputs` | [sequence](../core/list) of [File](../builtins/File)s; required  List of the output files of the action. |
-| `inputs` | [sequence](../core/list) of [File](../builtins/File)s; or [depset](../builtins/depset); default is `[]`  List or depset of the input files of the action. |
-| `unused_inputs_list` | [File](../builtins/File); or `None`; default is `None`  File containing list of inputs unused by the action. The content of this file (generally one of the outputs of the action) corresponds to the list of input files that were not used during the whole action execution. Any change in those files must not affect in any way the outputs of the action. |
-| `executable` | [File](../builtins/File); or [string](../core/string); or [FilesToRunProvider](../providers/FilesToRunProvider); required  The executable file to be called by the action. |
-| `tools` | [sequence](../core/list); or [depset](../builtins/depset); default is `unbound`  List or depset of any tools needed by the action. Tools are inputs with additional runfiles that are automatically made available to the action. When a list is provided, it can be a heterogenous collection of Files, FilesToRunProvider instances, or depsets of Files. Files which are directly in the list and come from ctx.executable will have their runfiles automatically added. When a depset is provided, it must contain only Files. In both cases, files within depsets are not cross-referenced with ctx.executable for runfiles. |
-| `arguments` | [sequence](../core/list); default is `[]`  Command line arguments of the action. Must be a list of strings or [`actions.args()`](#args) objects. |
-| `mnemonic` | [string](../core/string); or `None`; default is `None`  A one-word description of the action, for example, CppCompile or GoLink. |
-| `progress_message` | [string](../core/string); or `None`; default is `None`  Progress message to show to the user during the build, for example, "Compiling foo.cc to create foo.o". The message may contain `%{label}`, `%{input}`, or `%{output}` patterns, which are substituted with label string, first input, or output's path, respectively. Prefer to use patterns instead of static strings, because the former are more efficient. |
-| `use_default_shell_env` | [bool](../core/bool); default is `False`  Whether the action should use the default shell environment, which consists of a few OS-dependent variables as well as variables set via [`--action_env`](/reference/command-line-reference#flag--action_env). If both `use_default_shell_env` and `env` are set to `True`, values set in `env` will overwrite the default shell environment if [`--incompatible_merge_fixed_and_default_shell_env`](/reference/command-line-reference#flag--incompatible_merge_fixed_and_default_shell_env) is enabled (default). If the flag is not enabled, `env` is ignored. |
-| `env` | [dict](../core/dict); or `None`; default is `None`  Sets the dictionary of environment variables. If both `use_default_shell_env` and `env` are set to `True`, values set in `env` will overwrite the default shell environment if [`--incompatible_merge_fixed_and_default_shell_env`](/reference/command-line-reference#flag--incompatible_merge_fixed_and_default_shell_env) is enabled (default). If the flag is not enabled, `env` is ignored. |
-| `execution_requirements` | [dict](../core/dict); or `None`; default is `None`  Information for scheduling the action. See [tags](/reference/be/common-definitions#common.tags) for useful keys. |
-| `input_manifests` | [sequence](../core/list); or `None`; default is `None`  Legacy argument. Ignored. |
-| `exec_group` | [string](../core/string); or `None`; default is `None`  Runs the action on the given exec group's execution platform. If none, uses the target's default execution platform. |
-| `shadowed_action` | [Action](../builtins/Action); default is `None`  Runs the action using the given shadowed action's inputs and environment added to the action's inputs list and environment. The action environment can overwrite any of the shadowed action's environment variables. If none, uses only the action's inputs and given environment. |
+| `outputs` | [sequence](/versions/8.6.0/rules/lib/core/list) of [File](/versions/8.6.0/rules/lib/builtins/File)s; required  List of the output files of the action. |
+| `inputs` | [sequence](/versions/8.6.0/rules/lib/core/list) of [File](/versions/8.6.0/rules/lib/builtins/File)s; or [depset](/versions/8.6.0/rules/lib/builtins/depset); default is `[]`  List or depset of the input files of the action. |
+| `unused_inputs_list` | [File](/versions/8.6.0/rules/lib/builtins/File); or `None`; default is `None`  File containing list of inputs unused by the action. The content of this file (generally one of the outputs of the action) corresponds to the list of input files that were not used during the whole action execution. Any change in those files must not affect in any way the outputs of the action. |
+| `executable` | [File](/versions/8.6.0/rules/lib/builtins/File); or [string](/versions/8.6.0/rules/lib/core/string); or [FilesToRunProvider](/versions/8.6.0/rules/lib/providers/FilesToRunProvider); required  The executable file to be called by the action. |
+| `tools` | [sequence](/versions/8.6.0/rules/lib/core/list); or [depset](/versions/8.6.0/rules/lib/builtins/depset); default is `unbound`  List or depset of any tools needed by the action. Tools are inputs with additional runfiles that are automatically made available to the action. When a list is provided, it can be a heterogenous collection of Files, FilesToRunProvider instances, or depsets of Files. Files which are directly in the list and come from ctx.executable will have their runfiles automatically added. When a depset is provided, it must contain only Files. In both cases, files within depsets are not cross-referenced with ctx.executable for runfiles. |
+| `arguments` | [sequence](/versions/8.6.0/rules/lib/core/list); default is `[]`  Command line arguments of the action. Must be a list of strings or [`actions.args()`](#args) objects. |
+| `mnemonic` | [string](/versions/8.6.0/rules/lib/core/string); or `None`; default is `None`  A one-word description of the action, for example, CppCompile or GoLink. |
+| `progress_message` | [string](/versions/8.6.0/rules/lib/core/string); or `None`; default is `None`  Progress message to show to the user during the build, for example, "Compiling foo.cc to create foo.o". The message may contain `%{label}`, `%{input}`, or `%{output}` patterns, which are substituted with label string, first input, or output's path, respectively. Prefer to use patterns instead of static strings, because the former are more efficient. |
+| `use_default_shell_env` | [bool](/versions/8.6.0/rules/lib/core/bool); default is `False`  Whether the action should use the default shell environment, which consists of a few OS-dependent variables as well as variables set via [`--action_env`](/versions/8.6.0/reference/command-line-reference#flag--action_env). If both `use_default_shell_env` and `env` are set to `True`, values set in `env` will overwrite the default shell environment if [`--incompatible_merge_fixed_and_default_shell_env`](/versions/8.6.0/reference/command-line-reference#flag--incompatible_merge_fixed_and_default_shell_env) is enabled (default). If the flag is not enabled, `env` is ignored. |
+| `env` | [dict](/versions/8.6.0/rules/lib/core/dict); or `None`; default is `None`  Sets the dictionary of environment variables. If both `use_default_shell_env` and `env` are set to `True`, values set in `env` will overwrite the default shell environment if [`--incompatible_merge_fixed_and_default_shell_env`](/versions/8.6.0/reference/command-line-reference#flag--incompatible_merge_fixed_and_default_shell_env) is enabled (default). If the flag is not enabled, `env` is ignored. |
+| `execution_requirements` | [dict](/versions/8.6.0/rules/lib/core/dict); or `None`; default is `None`  Information for scheduling the action. See [tags](/versions/8.6.0/reference/be/common-definitions#common.tags) for useful keys. |
+| `input_manifests` | [sequence](/versions/8.6.0/rules/lib/core/list); or `None`; default is `None`  Legacy argument. Ignored. |
+| `exec_group` | [string](/versions/8.6.0/rules/lib/core/string); or `None`; default is `None`  Runs the action on the given exec group's execution platform. If none, uses the target's default execution platform. |
+| `shadowed_action` | [Action](/versions/8.6.0/rules/lib/builtins/Action); default is `None`  Runs the action using the given shadowed action's inputs and environment added to the action's inputs list and environment. The action environment can overwrite any of the shadowed action's environment variables. If none, uses only the action's inputs and given environment. |
 | `resource_set` | callable; or `None`; default is `None`  A callback function that returns a resource set dictionary, used to estimate resource usage at execution time if this action is run locally. The function accepts two positional arguments: a string representing an OS name (e.g. "osx"), and an integer representing the number of inputs to the action. The returned dictionary may contain the following entries, each of which may be a float or an int:  * "cpu": number of CPUs; default 1* "memory": in MB; default 250* "local_test": number of local tests; default 1   If this parameter is set to `None` , the default values are used. The callback must be top-level (lambda and nested functions aren't allowed). |
-| `toolchain` | [Label](../builtins/Label); or [string](../core/string); or `None`; default is `unbound`  Toolchain type of the executable or tools used in this action.  If executable and tools are not coming from a toolchain, set this parameter to `None`.  If executable and tools are coming from a toolchain, toolchain type must be set so that the action executes on the correct execution platform.  Note that the rule which creates this action needs to define this toolchain inside its 'rule()' function.  When `toolchain` and `exec_group` parameters are both set, `exec_group` will be used. An error is raised in case the `exec_group` doesn't specify the same toolchain. |
+| `toolchain` | [Label](/versions/8.6.0/rules/lib/builtins/Label); or [string](/versions/8.6.0/rules/lib/core/string); or `None`; default is `unbound`  Toolchain type of the executable or tools used in this action.  If executable and tools are not coming from a toolchain, set this parameter to `None`.  If executable and tools are coming from a toolchain, toolchain type must be set so that the action executes on the correct execution platform.  Note that the rule which creates this action needs to define this toolchain inside its 'rule()' function.  When `toolchain` and `exec_group` parameters are both set, `exec_group` will be used. An error is raised in case the `exec_group` doesn't specify the same toolchain. |
 
 ## run_shell
 
@@ -149,21 +149,21 @@ Creates an action that runs a shell command. [See example of use](https://github
 
 | Parameter | Description |
 | --- | --- |
-| `outputs` | [sequence](../core/list) of [File](../builtins/File)s; required  List of the output files of the action. |
-| `inputs` | [sequence](../core/list) of [File](../builtins/File)s; or [depset](../builtins/depset); default is `[]`  List or depset of the input files of the action. |
-| `tools` | [sequence](../core/list) of [File](../builtins/File)s; or [depset](../builtins/depset); default is `unbound`  List or depset of any tools needed by the action. Tools are inputs with additional runfiles that are automatically made available to the action. The list can contain Files or FilesToRunProvider instances. |
-| `arguments` | [sequence](../core/list); default is `[]`  Command line arguments of the action. Must be a list of strings or [`actions.args()`](#args) objects. Bazel passes the elements in this attribute as arguments to the command.The command can access these arguments using shell variable substitutions such as `$1`, `$2`, etc. Note that since Args objects are flattened before indexing, if there is an Args object of unknown size then all subsequent strings will be at unpredictable indices. It may be useful to use `$@` (to retrieve all arguments) in conjunction with Args objects of indeterminate size. In the case where `command` is a list of strings, this parameter may not be used. |
-| `mnemonic` | [string](../core/string); or `None`; default is `None`  A one-word description of the action, for example, CppCompile or GoLink. |
-| `command` | [string](../core/string); or [sequence](../core/list) of [string](../core/string)s; required  Shell command to execute. This may either be a string (preferred) or a sequence of strings **(deprecated)**. If `command` is a string, then it is executed as if by `sh -c <command> "" <arguments>` -- that is, the elements in `arguments` are made available to the command as `$1`, `$2` (or `%1`, `%2` if using Windows batch), etc. If `arguments` contains any [`actions.args()`](#args) objects, their contents are appended one by one to the command line, so `$`*i* can refer to individual strings within an Args object. Note that if an Args object of unknown size is passed as part of `arguments`, then the strings will be at unknown indices; in this case the `$@` shell substitution (retrieve all arguments) may be useful. **(Deprecated)** If `command` is a sequence of strings, the first item is the executable to run and the remaining items are its arguments. If this form is used, the `arguments` parameter must not be supplied. *Note that this form is deprecated and will soon be removed. It is disabled with `--incompatible_run_shell_command_string`. Use this flag to verify your code is compatible.*  Bazel uses the same shell to execute the command as it does for genrules. |
-| `progress_message` | [string](../core/string); or `None`; default is `None`  Progress message to show to the user during the build, for example, "Compiling foo.cc to create foo.o". The message may contain `%{label}`, `%{input}`, or `%{output}` patterns, which are substituted with label string, first input, or output's path, respectively. Prefer to use patterns instead of static strings, because the former are more efficient. |
-| `use_default_shell_env` | [bool](../core/bool); default is `False`  Whether the action should use the default shell environment, which consists of a few OS-dependent variables as well as variables set via [`--action_env`](/reference/command-line-reference#flag--action_env). If both `use_default_shell_env` and `env` are set to `True`, values set in `env` will overwrite the default shell environment if [`--incompatible_merge_fixed_and_default_shell_env`](/reference/command-line-reference#flag--incompatible_merge_fixed_and_default_shell_env) is enabled (default). If the flag is not enabled, `env` is ignored. |
-| `env` | [dict](../core/dict); or `None`; default is `None`  Sets the dictionary of environment variables. If both `use_default_shell_env` and `env` are set to `True`, values set in `env` will overwrite the default shell environment if [`--incompatible_merge_fixed_and_default_shell_env`](/reference/command-line-reference#flag--incompatible_merge_fixed_and_default_shell_env) is enabled (default). If the flag is not enabled, `env` is ignored. |
-| `execution_requirements` | [dict](../core/dict); or `None`; default is `None`  Information for scheduling the action. See [tags](/reference/be/common-definitions#common.tags) for useful keys. |
-| `input_manifests` | [sequence](../core/list); or `None`; default is `None`  Legacy argument. Ignored. |
-| `exec_group` | [string](../core/string); or `None`; default is `None`  Runs the action on the given exec group's execution platform. If none, uses the target's default execution platform. |
-| `shadowed_action` | [Action](../builtins/Action); default is `None`  Runs the action using the given shadowed action's discovered inputs added to the action's inputs list. If none, uses only the action's inputs. |
+| `outputs` | [sequence](/versions/8.6.0/rules/lib/core/list) of [File](/versions/8.6.0/rules/lib/builtins/File)s; required  List of the output files of the action. |
+| `inputs` | [sequence](/versions/8.6.0/rules/lib/core/list) of [File](/versions/8.6.0/rules/lib/builtins/File)s; or [depset](/versions/8.6.0/rules/lib/builtins/depset); default is `[]`  List or depset of the input files of the action. |
+| `tools` | [sequence](/versions/8.6.0/rules/lib/core/list) of [File](/versions/8.6.0/rules/lib/builtins/File)s; or [depset](/versions/8.6.0/rules/lib/builtins/depset); default is `unbound`  List or depset of any tools needed by the action. Tools are inputs with additional runfiles that are automatically made available to the action. The list can contain Files or FilesToRunProvider instances. |
+| `arguments` | [sequence](/versions/8.6.0/rules/lib/core/list); default is `[]`  Command line arguments of the action. Must be a list of strings or [`actions.args()`](#args) objects. Bazel passes the elements in this attribute as arguments to the command.The command can access these arguments using shell variable substitutions such as `$1`, `$2`, etc. Note that since Args objects are flattened before indexing, if there is an Args object of unknown size then all subsequent strings will be at unpredictable indices. It may be useful to use `$@` (to retrieve all arguments) in conjunction with Args objects of indeterminate size. In the case where `command` is a list of strings, this parameter may not be used. |
+| `mnemonic` | [string](/versions/8.6.0/rules/lib/core/string); or `None`; default is `None`  A one-word description of the action, for example, CppCompile or GoLink. |
+| `command` | [string](/versions/8.6.0/rules/lib/core/string); or [sequence](/versions/8.6.0/rules/lib/core/list) of [string](/versions/8.6.0/rules/lib/core/string)s; required  Shell command to execute. This may either be a string (preferred) or a sequence of strings **(deprecated)**. If `command` is a string, then it is executed as if by `sh -c <command> "" <arguments>` -- that is, the elements in `arguments` are made available to the command as `$1`, `$2` (or `%1`, `%2` if using Windows batch), etc. If `arguments` contains any [`actions.args()`](#args) objects, their contents are appended one by one to the command line, so `$`*i* can refer to individual strings within an Args object. Note that if an Args object of unknown size is passed as part of `arguments`, then the strings will be at unknown indices; in this case the `$@` shell substitution (retrieve all arguments) may be useful. **(Deprecated)** If `command` is a sequence of strings, the first item is the executable to run and the remaining items are its arguments. If this form is used, the `arguments` parameter must not be supplied. *Note that this form is deprecated and will soon be removed. It is disabled with `--incompatible_run_shell_command_string`. Use this flag to verify your code is compatible.*  Bazel uses the same shell to execute the command as it does for genrules. |
+| `progress_message` | [string](/versions/8.6.0/rules/lib/core/string); or `None`; default is `None`  Progress message to show to the user during the build, for example, "Compiling foo.cc to create foo.o". The message may contain `%{label}`, `%{input}`, or `%{output}` patterns, which are substituted with label string, first input, or output's path, respectively. Prefer to use patterns instead of static strings, because the former are more efficient. |
+| `use_default_shell_env` | [bool](/versions/8.6.0/rules/lib/core/bool); default is `False`  Whether the action should use the default shell environment, which consists of a few OS-dependent variables as well as variables set via [`--action_env`](/versions/8.6.0/reference/command-line-reference#flag--action_env). If both `use_default_shell_env` and `env` are set to `True`, values set in `env` will overwrite the default shell environment if [`--incompatible_merge_fixed_and_default_shell_env`](/versions/8.6.0/reference/command-line-reference#flag--incompatible_merge_fixed_and_default_shell_env) is enabled (default). If the flag is not enabled, `env` is ignored. |
+| `env` | [dict](/versions/8.6.0/rules/lib/core/dict); or `None`; default is `None`  Sets the dictionary of environment variables. If both `use_default_shell_env` and `env` are set to `True`, values set in `env` will overwrite the default shell environment if [`--incompatible_merge_fixed_and_default_shell_env`](/versions/8.6.0/reference/command-line-reference#flag--incompatible_merge_fixed_and_default_shell_env) is enabled (default). If the flag is not enabled, `env` is ignored. |
+| `execution_requirements` | [dict](/versions/8.6.0/rules/lib/core/dict); or `None`; default is `None`  Information for scheduling the action. See [tags](/versions/8.6.0/reference/be/common-definitions#common.tags) for useful keys. |
+| `input_manifests` | [sequence](/versions/8.6.0/rules/lib/core/list); or `None`; default is `None`  Legacy argument. Ignored. |
+| `exec_group` | [string](/versions/8.6.0/rules/lib/core/string); or `None`; default is `None`  Runs the action on the given exec group's execution platform. If none, uses the target's default execution platform. |
+| `shadowed_action` | [Action](/versions/8.6.0/rules/lib/builtins/Action); default is `None`  Runs the action using the given shadowed action's discovered inputs added to the action's inputs list. If none, uses only the action's inputs. |
 | `resource_set` | callable; or `None`; default is `None`  A callback function for estimating resource usage if run locally. See[`ctx.actions.run()`](#run.resource_set). |
-| `toolchain` | [Label](../builtins/Label); or [string](../core/string); or `None`; default is `unbound`  Toolchain type of the executable or tools used in this action.  If executable and tools are not coming from a toolchain, set this parameter to `None`.  If executable and tools are coming from a toolchain, toolchain type must be set so that the action executes on the correct execution platform.  Note that the rule which creates this action needs to define this toolchain inside its 'rule()' function.  When `toolchain` and `exec_group` parameters are both set, `exec_group` will be used. An error is raised in case the `exec_group` doesn't specify the same toolchain. |
+| `toolchain` | [Label](/versions/8.6.0/rules/lib/builtins/Label); or [string](/versions/8.6.0/rules/lib/core/string); or `None`; default is `unbound`  Toolchain type of the executable or tools used in this action.  If executable and tools are not coming from a toolchain, set this parameter to `None`.  If executable and tools are coming from a toolchain, toolchain type must be set so that the action executes on the correct execution platform.  Note that the rule which creates this action needs to define this toolchain inside its 'rule()' function.  When `toolchain` and `exec_group` parameters are both set, `exec_group` will be used. An error is raised in case the `exec_group` doesn't specify the same toolchain. |
 
 ## symlink
 
@@ -183,12 +183,12 @@ Otherwise, when you use `target_path`, declare `output` with [`declare_symlink()
 
 | Parameter | Description |
 | --- | --- |
-| `output` | [File](../builtins/File); required  The output of this action. |
-| `target_file` | [File](../builtins/File); or `None`; default is `None`  The File that the output symlink will point to. |
-| `target_path` | [string](../core/string); or `None`; default is `None`  The exact path that the output symlink will point to. No normalization or other processing is applied. |
-| `target_type` | [string](../core/string); or `None`; default is `None`  May only be used with `target_path`, not `target_file`. If specified, it must be one of 'file' or 'directory', indicating the target path's expected type. On Windows, this determines which kind of filesystem object to create (junction for a directory, symlink for a file). It has no effect on other operating systems. |
-| `is_executable` | [bool](../core/bool); default is `False`  May only be used with `target_file`, not `target_path`. If true, when the action is executed, the `target_file`'s path is checked to confirm that it is executable, and an error is reported if it is not. Setting `is_executable` to False does not mean the target is not executable, just that no verification is done. This feature does not make sense for `target_path` because dangling symlinks might not exist at build time. |
-| `progress_message` | [string](../core/string); or `None`; default is `None`  Progress message to show to the user during the build. |
+| `output` | [File](/versions/8.6.0/rules/lib/builtins/File); required  The output of this action. |
+| `target_file` | [File](/versions/8.6.0/rules/lib/builtins/File); or `None`; default is `None`  The File that the output symlink will point to. |
+| `target_path` | [string](/versions/8.6.0/rules/lib/core/string); or `None`; default is `None`  The exact path that the output symlink will point to. No normalization or other processing is applied. |
+| `target_type` | [string](/versions/8.6.0/rules/lib/core/string); or `None`; default is `None`  May only be used with `target_path`, not `target_file`. If specified, it must be one of 'file' or 'directory', indicating the target path's expected type. On Windows, this determines which kind of filesystem object to create (junction for a directory, symlink for a file). It has no effect on other operating systems. |
+| `is_executable` | [bool](/versions/8.6.0/rules/lib/core/bool); default is `False`  May only be used with `target_file`, not `target_path`. If true, when the action is executed, the `target_file`'s path is checked to confirm that it is executable, and an error is reported if it is not. Setting `is_executable` to False does not mean the target is not executable, just that no verification is done. This feature does not make sense for `target_path` because dangling symlinks might not exist at build time. |
+| `progress_message` | [string](/versions/8.6.0/rules/lib/core/string); or `None`; default is `None`  Progress message to show to the user during the build. |
 
 ## template_dict
 
@@ -210,6 +210,6 @@ Creates a file write action. When the action is executed, it will write the give
 
 | Parameter | Description |
 | --- | --- |
-| `output` | [File](../builtins/File); required  The output file. |
-| `content` | [string](../core/string); or [Args](../builtins/Args); required  the contents of the file. May be a either a string or an [`actions.args()`](#args) object. |
-| `is_executable` | [bool](../core/bool); default is `False`  Whether the output file should be executable. |
\ No newline at end of file
+| `output` | [File](/versions/8.6.0/rules/lib/builtins/File); required  The output file. |
+| `content` | [string](/versions/8.6.0/rules/lib/core/string); or [Args](/versions/8.6.0/rules/lib/builtins/Args); required  the contents of the file. May be a either a string or an [`actions.args()`](#args) object. |
+| `is_executable` | [bool](/versions/8.6.0/rules/lib/core/bool); default is `False`  Whether the output file should be executable. |
\ No newline at end of file
diff --git a/versions/8.6.0/rules/lib/builtins/apple_platform.mdx b/versions/8.6.0/rules/lib/builtins/apple_platform.mdx
index 59225ef9..b430dc8b 100644
--- a/versions/8.6.0/rules/lib/builtins/apple_platform.mdx
+++ b/versions/8.6.0/rules/lib/builtins/apple_platform.mdx
@@ -4,7 +4,7 @@ title: 'apple_platform'
 
 Corresponds to Xcode's notion of a platform as would be found in `Xcode.app/Contents/Developer/Platforms`. Each platform represents an Apple platform type (such as iOS or tvOS) combined with one or more related CPU architectures. For example, the iOS simulator platform supports `x86_64` and `i386` architectures.
 
-Specific instances of this type can be retrieved from the fields of the [apple_common.platform](../toplevel/apple_common#platform) struct:
+Specific instances of this type can be retrieved from the fields of the [apple_common.platform](/versions/8.6.0/rules/lib/toplevel/apple_common#platform) struct:
 
 * `apple_common.platform.ios_device`
 * `apple_common.platform.ios_simulator`
@@ -14,7 +14,7 @@ Specific instances of this type can be retrieved from the fields of the [apple_c
 * `apple_common.platform.watchos_device`
 * `apple_common.platform.watchos_simulator`
 
-More commonly, however, the [apple](../fragments/apple) configuration fragment has fields/methods that allow rules to determine the platform for which a target is being built.
+More commonly, however, the [apple](/versions/8.6.0/rules/lib/fragments/apple) configuration fragment has fields/methods that allow rules to determine the platform for which a target is being built.
 
 Example:
 
diff --git a/versions/8.6.0/rules/lib/builtins/configuration.mdx b/versions/8.6.0/rules/lib/builtins/configuration.mdx
index 8dfe6b7b..64564763 100644
--- a/versions/8.6.0/rules/lib/builtins/configuration.mdx
+++ b/versions/8.6.0/rules/lib/builtins/configuration.mdx
@@ -2,7 +2,7 @@
 title: 'configuration'
 ---
 
-This object holds information about the environment in which the build is running. See the [Rules page](https://bazel.build/extending/rules#configurations) for more on the general concept of configurations.
+This object holds information about the environment in which the build is running. See the [Rules page](https://bazel.build/versions/8.6.0/extending/rules#configurations) for more on the general concept of configurations.
 
 ## Members
 
@@ -18,7 +18,7 @@ This object holds information about the environment in which the build is runnin
 bool configuration.coverage_enabled
 ```
 
-A boolean that tells whether code coverage is enabled for this run. Note that this does not compute whether a specific rule should be instrumented for code coverage data collection. For that, see the [`ctx.coverage_instrumented`](../builtins/ctx#coverage_instrumented) function.
+A boolean that tells whether code coverage is enabled for this run. Note that this does not compute whether a specific rule should be instrumented for code coverage data collection. For that, see the [`ctx.coverage_instrumented`](/versions/8.6.0/rules/lib/builtins/ctx#coverage_instrumented) function.
 
 ## default_shell_env
 
diff --git a/versions/8.6.0/rules/lib/builtins/ctx.mdx b/versions/8.6.0/rules/lib/builtins/ctx.mdx
index 21566c1a..1939ea82 100644
--- a/versions/8.6.0/rules/lib/builtins/ctx.mdx
+++ b/versions/8.6.0/rules/lib/builtins/ctx.mdx
@@ -6,7 +6,7 @@ A context object that is passed to the implementation function for a rule or asp
 
 In particular, it lets the implementation function access the current target's label, attributes, configuration, and the providers of its dependencies. It has methods for declaring output files and the actions that produce them.
 
-Context objects essentially live for the duration of the call to the implementation function. It is not useful to access these objects outside of their associated function. See the [Rules page](https://bazel.build/extending/rules#implementation_function) for more information.
+Context objects essentially live for the duration of the call to the implementation function. It is not useful to access these objects outside of their associated function. See the [Rules page](https://bazel.build/versions/8.6.0/extending/rules#implementation_function) for more information.
 
 ## Members
 
@@ -66,7 +66,7 @@ A list of ids for all aspects applied to the target. Only available in aspect im
 struct ctx.attr
 ```
 
-A struct to access the values of the [attributes](https://bazel.build/extending/rules#attributes). The values are provided by the user (if not, a default value is used). The attributes of the struct and the types of their values correspond to the keys and values of the [`attrs` dict](../globals/bzl#rule.attrs) provided to the [`rule` function](../globals/bzl#rule). [See example of use](https://github.com/bazelbuild/examples/blob/main/rules/attributes/printer.bzl).
+A struct to access the values of the [attributes](https://bazel.build/versions/8.6.0/extending/rules#attributes). The values are provided by the user (if not, a default value is used). The attributes of the struct and the types of their values correspond to the keys and values of the [`attrs` dict](/versions/8.6.0/rules/lib/globals/bzl#rule.attrs) provided to the [`rule` function](/versions/8.6.0/rules/lib/globals/bzl#rule). [See example of use](https://github.com/bazelbuild/examples/blob/main/rules/attributes/printer.bzl).
 
 ## bin_dir
 
@@ -90,7 +90,7 @@ Deprecated: Use `ctx.label.package + '/BUILD'`. The path to the BUILD file for t
 unknown ctx.build_setting_value
 ```
 
-Value of the build setting represented by the current target. If this isn't the context for an instance of a rule that sets the [`build_setting`](https://bazel.build/extending/config#rule-parameter) attribute, reading this is an error.
+Value of the build setting represented by the current target. If this isn't the context for an instance of a rule that sets the [`build_setting`](https://bazel.build/versions/8.6.0/extending/config#rule-parameter) attribute, reading this is an error.
 
 ## configuration
 
@@ -98,7 +98,7 @@ Value of the build setting represented by the current target. If this isn't the
 configuration ctx.configuration
 ```
 
-The default configuration. See the [configuration](../builtins/configuration) type for more details.
+The default configuration. See the [configuration](/versions/8.6.0/rules/lib/builtins/configuration) type for more details.
 
 ## coverage_instrumented
 
@@ -106,13 +106,13 @@ The default configuration. See the [configuration](../builtins/configuration) ty
 bool ctx.coverage_instrumented(target=None)
 ```
 
-Returns whether code coverage instrumentation should be generated when performing compilation actions for this rule or, if `target` is provided, the rule specified by that Target. (If a non-rule or a Starlark rule Target is provided, this returns False.) Checks if the sources of the current rule (if no Target is provided) or the sources of Target should be instrumented based on the --instrumentation_filter and --instrument_test_targets config settings. This differs from `coverage_enabled` in the [configuration](../builtins/configuration), which notes whether coverage data collection is enabled for the entire run, but not whether a specific target should be instrumented.
+Returns whether code coverage instrumentation should be generated when performing compilation actions for this rule or, if `target` is provided, the rule specified by that Target. (If a non-rule or a Starlark rule Target is provided, this returns False.) Checks if the sources of the current rule (if no Target is provided) or the sources of Target should be instrumented based on the --instrumentation_filter and --instrument_test_targets config settings. This differs from `coverage_enabled` in the [configuration](/versions/8.6.0/rules/lib/builtins/configuration), which notes whether coverage data collection is enabled for the entire run, but not whether a specific target should be instrumented.
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `target` | [Target](../builtins/Target); or `None`; default is `None`  A Target specifying a rule. If not provided, defaults to the current rule. |
+| `target` | [Target](/versions/8.6.0/rules/lib/builtins/Target); or `None`; default is `None`  A Target specifying a rule. If not provided, defaults to the current rule. |
 
 ## created_actions
 
@@ -120,7 +120,7 @@ Returns whether code coverage instrumentation should be generated when performin
 StarlarkValue ctx.created_actions()
 ```
 
-For rules with [\_skylark_testable](../globals/bzl#rule._skylark_testable) set to `True`, this returns an `Actions` provider representing all actions created so far for the current rule. For all other rules, returns `None`. Note that the provider is not updated when subsequent actions are created, so you will have to call this function again if you wish to inspect them.
+For rules with [\_skylark_testable](/versions/8.6.0/rules/lib/globals/bzl#rule._skylark_testable) set to `True`, this returns an `Actions` provider representing all actions created so far for the current rule. For all other rules, returns `None`. Note that the provider is not updated when subsequent actions are created, so you will have to call this function again if you wish to inspect them.
 
 This is intended to help write tests for rule-implementation helper functions, which may take in a `ctx` object and create actions on it.
 
@@ -146,7 +146,7 @@ A collection of the execution groups available for this rule, indexed by their n
 struct ctx.executable
 ```
 
-A `struct` containing executable files defined in [label type attributes](../toplevel/attr#label) marked as [`executable=True`](../toplevel/attr#label.executable). The struct fields correspond to the attribute names. Each value in the struct is either a [`File`](../builtins/File) or `None`. If an optional attribute is not specified in the rule then the corresponding struct value is `None`. If a label type is not marked as `executable=True`, no corresponding struct field is generated. [See example of use](https://github.com/bazelbuild/examples/blob/main/rules/actions_run/execute.bzl).
+A `struct` containing executable files defined in [label type attributes](/versions/8.6.0/rules/lib/toplevel/attr#label) marked as [`executable=True`](/versions/8.6.0/rules/lib/toplevel/attr#label.executable). The struct fields correspond to the attribute names. Each value in the struct is either a [`File`](/versions/8.6.0/rules/lib/builtins/File) or `None`. If an optional attribute is not specified in the rule then the corresponding struct value is `None`. If a label type is not marked as `executable=True`, no corresponding struct field is generated. [See example of use](https://github.com/bazelbuild/examples/blob/main/rules/actions_run/execute.bzl).
 
 ## expand_location
 
@@ -164,8 +164,8 @@ This function is useful to let the user specify a command in a BUILD file (like
 
 | Parameter | Description |
 | --- | --- |
-| `input` | [string](../core/string); required  String to be expanded. |
-| `targets` | [sequence](../core/list) of [Target](../builtins/Target)s; default is `[]`  List of targets for additional lookup information. These are expanded as follows: A target with a single file in `DefaultInfo.files` expands to that file. Other targets expand to their `DefaultInfo.executable` file if set and if `--incompatible_locations_prefers_executable` is enabled, otherwise they expand to `DefaultInfo.files`. |
+| `input` | [string](/versions/8.6.0/rules/lib/core/string); required  String to be expanded. |
+| `targets` | [sequence](/versions/8.6.0/rules/lib/core/list) of [Target](/versions/8.6.0/rules/lib/builtins/Target)s; default is `[]`  List of targets for additional lookup information. These are expanded as follows: A target with a single file in `DefaultInfo.files` expands to that file. Other targets expand to their `DefaultInfo.executable` file if set and if `--incompatible_locations_prefers_executable` is enabled, otherwise they expand to `DefaultInfo.files`. |
 
 May return `None`.
 
@@ -175,7 +175,7 @@ May return `None`.
 string ctx.expand_make_variables(attribute_name, command, additional_substitutions)
 ```
 
-**Deprecated.** Use [ctx.var](../builtins/ctx#var) to access the variables instead.
+**Deprecated.** Use [ctx.var](/versions/8.6.0/rules/lib/builtins/ctx#var) to access the variables instead.
 Returns a string after expanding all references to "Make variables". The variables must have the following format: `$(VAR_NAME)`. Also, `$$VAR_NAME` expands to `$VAR_NAME`. Examples:
 
 ```
@@ -189,9 +189,9 @@ Additional variables may come from other places, such as configurations. Note th
 
 | Parameter | Description |
 | --- | --- |
-| `attribute_name` | [string](../core/string); required |
-| `command` | [string](../core/string); required  The expression to expand. It can contain references to "Make variables". |
-| `additional_substitutions` | [dict](../core/dict); required  Additional substitutions to make beyond the default make variables. |
+| `attribute_name` | [string](/versions/8.6.0/rules/lib/core/string); required |
+| `command` | [string](/versions/8.6.0/rules/lib/core/string); required  The expression to expand. It can contain references to "Make variables". |
+| `additional_substitutions` | [dict](/versions/8.6.0/rules/lib/core/dict); required  Additional substitutions to make beyond the default make variables. |
 
 ## features
 
@@ -207,13 +207,13 @@ The set of features that are explicitly enabled by the user for this rule. [See
 struct ctx.file
 ```
 
-A `struct` containing files defined in [label type attributes](../toplevel/attr#label) marked as [`allow_single_file`](../toplevel/attr#label.allow_single_file). The struct fields correspond to the attribute names. The struct value is always a [`File`](../builtins/File) or `None`. If an optional attribute is not specified in the rule then the corresponding struct value is `None`. If a label type is not marked as `allow_single_file`, no corresponding struct field is generated. It is a shortcut for:
+A `struct` containing files defined in [label type attributes](/versions/8.6.0/rules/lib/toplevel/attr#label) marked as [`allow_single_file`](/versions/8.6.0/rules/lib/toplevel/attr#label.allow_single_file). The struct fields correspond to the attribute names. The struct value is always a [`File`](/versions/8.6.0/rules/lib/builtins/File) or `None`. If an optional attribute is not specified in the rule then the corresponding struct value is `None`. If a label type is not marked as `allow_single_file`, no corresponding struct field is generated. It is a shortcut for:
 
 ```
 list(ctx.attr..files)[0]
 ```
 
-In other words, use `file` to access the (singular) [default output](https://bazel.build/extending/rules#requesting_output_files) of a dependency. [See example of use](https://github.com/bazelbuild/examples/blob/main/rules/expand_template/hello.bzl).
+In other words, use `file` to access the (singular) [default output](https://bazel.build/versions/8.6.0/extending/rules#requesting_output_files) of a dependency. [See example of use](https://github.com/bazelbuild/examples/blob/main/rules/expand_template/hello.bzl).
 
 ## files
 
@@ -221,13 +221,13 @@ In other words, use `file` to access the (singular) [default output](https://baz
 struct ctx.files
 ```
 
-A `struct` containing files defined in [label](../toplevel/attr#label) or [label list](../toplevel/attr#label_list) type attributes. The struct fields correspond to the attribute names. The struct values are `list` of [`File`](../builtins/File)s. It is a shortcut for:
+A `struct` containing files defined in [label](/versions/8.6.0/rules/lib/toplevel/attr#label) or [label list](/versions/8.6.0/rules/lib/toplevel/attr#label_list) type attributes. The struct fields correspond to the attribute names. The struct values are `list` of [`File`](/versions/8.6.0/rules/lib/builtins/File)s. It is a shortcut for:
 
 ```
 [f for t in ctx.attr. for f in t.files]
 ```
 
-In other words, use `files` to access the  [default outputs](https://bazel.build/extending/rules#requesting_output_files) of a dependency. [See example of use](https://github.com/bazelbuild/examples/blob/main/rules/depsets/foo.bzl).
+In other words, use `files` to access the  [default outputs](https://bazel.build/versions/8.6.0/extending/rules#requesting_output_files) of a dependency. [See example of use](https://github.com/bazelbuild/examples/blob/main/rules/depsets/foo.bzl).
 
 ## fragments
 
@@ -267,13 +267,13 @@ The label of the target currently being analyzed.
 structure ctx.outputs
 ```
 
-A pseudo-struct containing all the predeclared output files, represented by [`File`](../builtins/File) objects. See the [Rules page](https://bazel.build/extending/rules#files) for more information and examples.
+A pseudo-struct containing all the predeclared output files, represented by [`File`](/versions/8.6.0/rules/lib/builtins/File) objects. See the [Rules page](https://bazel.build/versions/8.6.0/extending/rules#files) for more information and examples.
 
 This field does not exist on aspect contexts, since aspects do not have predeclared outputs.
 
 The fields of this object are defined as follows. It is an error if two outputs produce the same field name or have the same label.
 
-* If the rule declares an [`outputs`](../globals/bzl#rule.outputs) dict, then for every entry in the dict, there is a field whose name is the key and whose value is the corresponding `File`.* For every attribute of type [`attr.output`](../toplevel/attr#output) that the rule declares, there is a field whose name is the attribute's name. If the target specified a label for that attribute, then the field value is the corresponding `File`; otherwise the field value is `None`.* For every attribute of type [`attr.output_list`](../toplevel/attr#output_list) that the rule declares, there is a field whose name is the attribute's name. The field value is a list of `File` objects corresponding to the labels given for that attribute in the target, or an empty list if the attribute was not specified in the target.* **(Deprecated)** If the rule is marked [`executable`](../globals/bzl#rule.executable) or [`test`](../globals/bzl#rule.test), there is a field named `"executable"`, which is the default executable. It is recommended that instead of using this, you pass another file (either predeclared or not) to the `executable` arg of [`DefaultInfo`](../providers/DefaultInfo).
+* If the rule declares an [`outputs`](/versions/8.6.0/rules/lib/globals/bzl#rule.outputs) dict, then for every entry in the dict, there is a field whose name is the key and whose value is the corresponding `File`.* For every attribute of type [`attr.output`](/versions/8.6.0/rules/lib/toplevel/attr#output) that the rule declares, there is a field whose name is the attribute's name. If the target specified a label for that attribute, then the field value is the corresponding `File`; otherwise the field value is `None`.* For every attribute of type [`attr.output_list`](/versions/8.6.0/rules/lib/toplevel/attr#output_list) that the rule declares, there is a field whose name is the attribute's name. The field value is a list of `File` objects corresponding to the labels given for that attribute in the target, or an empty list if the attribute was not specified in the target.* **(Deprecated)** If the rule is marked [`executable`](/versions/8.6.0/rules/lib/globals/bzl#rule.executable) or [`test`](/versions/8.6.0/rules/lib/globals/bzl#rule.test), there is a field named `"executable"`, which is the default executable. It is recommended that instead of using this, you pass another file (either predeclared or not) to the `executable` arg of [`DefaultInfo`](/versions/8.6.0/rules/lib/providers/DefaultInfo).
 
 ## resolve_command
 
@@ -288,13 +288,13 @@ tuple ctx.resolve_command(command='', attribute=None, expand_locations=False, ma
 
 | Parameter | Description |
 | --- | --- |
-| `command` | [string](../core/string); default is `''`  Command to resolve. |
-| `attribute` | [string](../core/string); or `None`; default is `None`  Name of the associated attribute for which to issue an error, or None. |
-| `expand_locations` | [bool](../core/bool); default is `False`  Shall we expand $(location) variables? See [ctx.expand_location()](#expand_location) for more details. |
-| `make_variables` | [dict](../core/dict); or `None`; default is `None`  Make variables to expand, or None. |
-| `tools` | [sequence](../core/list) of [Target](../builtins/Target)s; default is `[]`  List of tools (list of targets). |
-| `label_dict` | [dict](../core/dict); default is `{}`  Dictionary of resolved labels and the corresponding list of Files (a dict of Label : list of Files). |
-| `execution_requirements` | [dict](../core/dict); default is `{}`  Information for scheduling the action to resolve this command. See [tags](/reference/be/common-definitions#common.tags) for useful keys. |
+| `command` | [string](/versions/8.6.0/rules/lib/core/string); default is `''`  Command to resolve. |
+| `attribute` | [string](/versions/8.6.0/rules/lib/core/string); or `None`; default is `None`  Name of the associated attribute for which to issue an error, or None. |
+| `expand_locations` | [bool](/versions/8.6.0/rules/lib/core/bool); default is `False`  Shall we expand $(location) variables? See [ctx.expand_location()](#expand_location) for more details. |
+| `make_variables` | [dict](/versions/8.6.0/rules/lib/core/dict); or `None`; default is `None`  Make variables to expand, or None. |
+| `tools` | [sequence](/versions/8.6.0/rules/lib/core/list) of [Target](/versions/8.6.0/rules/lib/builtins/Target)s; default is `[]`  List of tools (list of targets). |
+| `label_dict` | [dict](/versions/8.6.0/rules/lib/core/dict); default is `{}`  Dictionary of resolved labels and the corresponding list of Files (a dict of Label : list of Files). |
+| `execution_requirements` | [dict](/versions/8.6.0/rules/lib/core/dict); default is `{}`  Information for scheduling the action to resolve this command. See [tags](/versions/8.6.0/reference/be/common-definitions#common.tags) for useful keys. |
 
 ## resolve_tools
 
@@ -310,7 +310,7 @@ In contrast to `ctx.resolve_command`, this method does not require that Bash be
 
 | Parameter | Description |
 | --- | --- |
-| `tools` | [sequence](../core/list) of [Target](../builtins/Target)s; default is `[]`  List of tools (list of targets). |
+| `tools` | [sequence](/versions/8.6.0/rules/lib/core/list) of [Target](/versions/8.6.0/rules/lib/builtins/Target)s; default is `[]`  List of tools (list of targets). |
 
 ## rule
 
@@ -332,12 +332,12 @@ Creates a runfiles object.
 
 | Parameter | Description |
 | --- | --- |
-| `files` | [sequence](../core/list) of [File](../builtins/File)s; default is `[]`  The list of files to be added to the runfiles. |
-| `transitive_files` | [depset](../builtins/depset) of [File](../builtins/File)s; or `None`; default is `None`  The (transitive) set of files to be added to the runfiles. The depset should use the `default` order (which, as the name implies, is the default). |
-| `collect_data` | [bool](../core/bool); default is `False`  **Use of this parameter is not recommended. See [runfiles guide](https://bazel.build/extending/rules#runfiles)**. Whether to collect the data runfiles from the dependencies in srcs, data and deps attributes. |
-| `collect_default` | [bool](../core/bool); default is `False`  **Use of this parameter is not recommended. See [runfiles guide](https://bazel.build/extending/rules#runfiles)**. Whether to collect the default runfiles from the dependencies in srcs, data and deps attributes. |
-| `symlinks` | [dict](../core/dict); or [depset](../builtins/depset) of [SymlinkEntry](../builtins/SymlinkEntry)s; default is `{}`  Either a SymlinkEntry depset or the map of symlinks to be added to the runfiles. Symlinks are always added under the main workspace's runfiles directory (e.g. `<runfiles_root>/_main/<symlink_path>`, **not** the directory corresponding to the current target's repository. See [Runfiles symlinks](https://bazel.build/extending/rules#runfiles_symlinks) in the rules guide. |
-| `root_symlinks` | [dict](../core/dict); or [depset](../builtins/depset) of [SymlinkEntry](../builtins/SymlinkEntry)s; default is `{}`  Either a SymlinkEntry depset or a map of symlinks to be added to the runfiles. See [Runfiles symlinks](https://bazel.build/extending/rules#runfiles_symlinks) in the rules guide. |
+| `files` | [sequence](/versions/8.6.0/rules/lib/core/list) of [File](/versions/8.6.0/rules/lib/builtins/File)s; default is `[]`  The list of files to be added to the runfiles. |
+| `transitive_files` | [depset](/versions/8.6.0/rules/lib/builtins/depset) of [File](/versions/8.6.0/rules/lib/builtins/File)s; or `None`; default is `None`  The (transitive) set of files to be added to the runfiles. The depset should use the `default` order (which, as the name implies, is the default). |
+| `collect_data` | [bool](/versions/8.6.0/rules/lib/core/bool); default is `False`  **Use of this parameter is not recommended. See [runfiles guide](https://bazel.build/versions/8.6.0/extending/rules#runfiles)**. Whether to collect the data runfiles from the dependencies in srcs, data and deps attributes. |
+| `collect_default` | [bool](/versions/8.6.0/rules/lib/core/bool); default is `False`  **Use of this parameter is not recommended. See [runfiles guide](https://bazel.build/versions/8.6.0/extending/rules#runfiles)**. Whether to collect the default runfiles from the dependencies in srcs, data and deps attributes. |
+| `symlinks` | [dict](/versions/8.6.0/rules/lib/core/dict); or [depset](/versions/8.6.0/rules/lib/builtins/depset) of [SymlinkEntry](/versions/8.6.0/rules/lib/builtins/SymlinkEntry)s; default is `{}`  Either a SymlinkEntry depset or the map of symlinks to be added to the runfiles. Symlinks are always added under the main workspace's runfiles directory (e.g. `<runfiles_root>/_main/<symlink_path>`, **not** the directory corresponding to the current target's repository. See [Runfiles symlinks](https://bazel.build/versions/8.6.0/extending/rules#runfiles_symlinks) in the rules guide. |
+| `root_symlinks` | [dict](/versions/8.6.0/rules/lib/core/dict); or [depset](/versions/8.6.0/rules/lib/builtins/depset) of [SymlinkEntry](/versions/8.6.0/rules/lib/builtins/SymlinkEntry)s; default is `{}`  Either a SymlinkEntry depset or a map of symlinks to be added to the runfiles. See [Runfiles symlinks](https://bazel.build/versions/8.6.0/extending/rules#runfiles_symlinks) in the rules guide. |
 
 ## split_attr
 
@@ -367,7 +367,7 @@ Returns true if the given constraint value is part of the current target platfor
 
 | Parameter | Description |
 | --- | --- |
-| `constraintValue` | [ConstraintValueInfo](../providers/ConstraintValueInfo); required  The constraint value to check the target platform against. |
+| `constraintValue` | [ConstraintValueInfo](/versions/8.6.0/rules/lib/providers/ConstraintValueInfo); required  The constraint value to check the target platform against. |
 
 ## toolchains
 
diff --git a/versions/8.6.0/rules/lib/builtins/depset.mdx b/versions/8.6.0/rules/lib/builtins/depset.mdx
index 37ec4140..fb8b8c9c 100644
--- a/versions/8.6.0/rules/lib/builtins/depset.mdx
+++ b/versions/8.6.0/rules/lib/builtins/depset.mdx
@@ -2,11 +2,11 @@
 title: 'depset'
 ---
 
-A specialized data structure that supports efficient merge operations and has a defined traversal order. Commonly used for accumulating data from transitive dependencies in rules and aspects. For more information see [here](/extending/depsets).
+A specialized data structure that supports efficient merge operations and has a defined traversal order. Commonly used for accumulating data from transitive dependencies in rules and aspects. For more information see [here](/versions/8.6.0/extending/depsets).
 
 The elements of a depset must be hashable and all of the same type (as defined by the built-in type(x) function), but depsets are not simply hash sets and do not support fast membership tests. If you need a general set datatype, you can simulate one using a dictionary where all keys map to `True`.
 
-Depsets are immutable. They should be created using their [constructor function](../globals/bzl#depset) and merged or augmented with other depsets via the `transitive` argument.
+Depsets are immutable. They should be created using their [constructor function](/versions/8.6.0/rules/lib/globals/bzl#depset) and merged or augmented with other depsets via the `transitive` argument.
 
 The `order` parameter determines the kind of traversal that is done to convert the depset to an iterable. There are four possible values:
 
diff --git a/versions/8.6.0/rules/lib/builtins/fragments.mdx b/versions/8.6.0/rules/lib/builtins/fragments.mdx
index 30aa187b..e7be0526 100644
--- a/versions/8.6.0/rules/lib/builtins/fragments.mdx
+++ b/versions/8.6.0/rules/lib/builtins/fragments.mdx
@@ -6,4 +6,4 @@ A collection of configuration fragments available in the current rule implementa
 
 Only configuration fragments which are declared in the rule definition may be accessed in this collection.
 
-See the [configuration fragment reference](../fragments) for a list of available fragments and the [rules documentation](https://bazel.build/extending/rules#configuration_fragments) for how to use them.
\ No newline at end of file
+See the [configuration fragment reference](/versions/8.6.0/rules/lib/fragments) for a list of available fragments and the [rules documentation](https://bazel.build/versions/8.6.0/extending/rules#configuration_fragments) for how to use them.
\ No newline at end of file
diff --git a/versions/8.6.0/rules/lib/builtins/macro.mdx b/versions/8.6.0/rules/lib/builtins/macro.mdx
index 7ddb3a71..7429fff8 100644
--- a/versions/8.6.0/rules/lib/builtins/macro.mdx
+++ b/versions/8.6.0/rules/lib/builtins/macro.mdx
@@ -3,8 +3,8 @@ title: 'macro'
 ---
 
 A callable Starlark value representing a symbolic macro; in other words, the return value of
-[`macro()`](../globals/bzl#macro). Invoking this value during package
+[`macro()`](/versions/8.6.0/rules/lib/globals/bzl#macro). Invoking this value during package
 construction time will instantiate the macro, and cause the macro's implementation function to be
 evaluated (in a separate context, different from the context in which the macro value was invoked),
 in most cases causing targets to be added to the package's target set. For more information, see
-[Macros](https://bazel.build/extending/macros).
\ No newline at end of file
+[Macros](https://bazel.build/versions/8.6.0/extending/macros).
\ No newline at end of file
diff --git a/versions/8.6.0/rules/lib/builtins/module_ctx.mdx b/versions/8.6.0/rules/lib/builtins/module_ctx.mdx
index db076075..62182c52 100644
--- a/versions/8.6.0/rules/lib/builtins/module_ctx.mdx
+++ b/versions/8.6.0/rules/lib/builtins/module_ctx.mdx
@@ -30,22 +30,22 @@ The context of the module extension containing helper functions and information
 unknown module_ctx.download(url, output='', sha256='', executable=False, allow_fail=False, canonical_id='', auth={}, headers={}, *, integrity='', block=True)
 ```
 
-Downloads a file to the output path for the provided url and returns a struct containing `success`, a flag which is `true` if the download completed successfully, and if successful, a hash of the file with the fields `sha256` and `integrity`. When `sha256` or `integrity` is user specified, setting an explicit `canonical_id` is highly recommended. e.g. [`get_default_canonical_id`](/rules/lib/repo/cache#get_default_canonical_id)
+Downloads a file to the output path for the provided url and returns a struct containing `success`, a flag which is `true` if the download completed successfully, and if successful, a hash of the file with the fields `sha256` and `integrity`. When `sha256` or `integrity` is user specified, setting an explicit `canonical_id` is highly recommended. e.g. [`get_default_canonical_id`](/versions/8.6.0/rules/lib/repo/cache#get_default_canonical_id)
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `url` | [string](../core/string); or Iterable of [string](../core/string)s; required  List of mirror URLs referencing the same file. |
-| `output` | [string](../core/string); or [Label](../builtins/Label); or [path](../builtins/path); default is `''`  path to the output file, relative to the repository directory. |
-| `sha256` | [string](../core/string); default is `''`  The expected SHA-256 hash of the file downloaded. This must match the SHA-256 hash of the file downloaded. It is a security risk to omit the SHA-256 as remote files can change. At best omitting this field will make your build non-hermetic. It is optional to make development easier but should be set before shipping. If provided, the repository cache will first be checked for a file with the given hash; a download will only be attempted if the file was not found in the cache. After a successful download, the file will be added to the cache. |
-| `executable` | [bool](../core/bool); default is `False`  Set the executable flag on the created file, false by default. |
-| `allow_fail` | [bool](../core/bool); default is `False`  If set, indicate the error in the return value instead of raising an error for failed downloads. |
-| `canonical_id` | [string](../core/string); default is `''`  If set, restrict cache hits to those cases where the file was added to the cache with the same canonical id. By default caching uses the checksum (`sha256` or `integrity`). |
-| `auth` | [dict](../core/dict); default is `{}`  An optional dict specifying authentication information for some of the URLs. |
-| `headers` | [dict](../core/dict); default is `{}`  An optional dict specifying http headers for all URLs. |
-| `integrity` | [string](../core/string); default is `''`  Expected checksum of the file downloaded, in Subresource Integrity format. This must match the checksum of the file downloaded. It is a security risk to omit the checksum as remote files can change. At best omitting this field will make your build non-hermetic. It is optional to make development easier but should be set before shipping. If provided, the repository cache will first be checked for a file with the given checksum; a download will only be attempted if the file was not found in the cache. After a successful download, the file will be added to the cache. |
-| `block` | [bool](../core/bool); default is `True`  If set to false, the call returns immediately and instead of the regular return value, it returns a token with one single method, wait(), which blocks until the download is finished and returns the usual return value or throws as usual. |
+| `url` | [string](/versions/8.6.0/rules/lib/core/string); or Iterable of [string](/versions/8.6.0/rules/lib/core/string)s; required  List of mirror URLs referencing the same file. |
+| `output` | [string](/versions/8.6.0/rules/lib/core/string); or [Label](/versions/8.6.0/rules/lib/builtins/Label); or [path](/versions/8.6.0/rules/lib/builtins/path); default is `''`  path to the output file, relative to the repository directory. |
+| `sha256` | [string](/versions/8.6.0/rules/lib/core/string); default is `''`  The expected SHA-256 hash of the file downloaded. This must match the SHA-256 hash of the file downloaded. It is a security risk to omit the SHA-256 as remote files can change. At best omitting this field will make your build non-hermetic. It is optional to make development easier but should be set before shipping. If provided, the repository cache will first be checked for a file with the given hash; a download will only be attempted if the file was not found in the cache. After a successful download, the file will be added to the cache. |
+| `executable` | [bool](/versions/8.6.0/rules/lib/core/bool); default is `False`  Set the executable flag on the created file, false by default. |
+| `allow_fail` | [bool](/versions/8.6.0/rules/lib/core/bool); default is `False`  If set, indicate the error in the return value instead of raising an error for failed downloads. |
+| `canonical_id` | [string](/versions/8.6.0/rules/lib/core/string); default is `''`  If set, restrict cache hits to those cases where the file was added to the cache with the same canonical id. By default caching uses the checksum (`sha256` or `integrity`). |
+| `auth` | [dict](/versions/8.6.0/rules/lib/core/dict); default is `{}`  An optional dict specifying authentication information for some of the URLs. |
+| `headers` | [dict](/versions/8.6.0/rules/lib/core/dict); default is `{}`  An optional dict specifying http headers for all URLs. |
+| `integrity` | [string](/versions/8.6.0/rules/lib/core/string); default is `''`  Expected checksum of the file downloaded, in Subresource Integrity format. This must match the checksum of the file downloaded. It is a security risk to omit the checksum as remote files can change. At best omitting this field will make your build non-hermetic. It is optional to make development easier but should be set before shipping. If provided, the repository cache will first be checked for a file with the given checksum; a download will only be attempted if the file was not found in the cache. After a successful download, the file will be added to the cache. |
+| `block` | [bool](/versions/8.6.0/rules/lib/core/bool); default is `True`  If set to false, the call returns immediately and instead of the regular return value, it returns a token with one single method, wait(), which blocks until the download is finished and returns the usual return value or throws as usual. |
 
 ## download_and_extract
 
@@ -53,23 +53,23 @@ Downloads a file to the output path for the provided url and returns a struct co
 struct module_ctx.download_and_extract(url, output='', sha256='', type='', strip_prefix='', allow_fail=False, canonical_id='', auth={}, headers={}, *, integrity='', rename_files={})
 ```
 
-Downloads a file to the output path for the provided url, extracts it, and returns a struct containing `success`, a flag which is `true` if the download completed successfully, and if successful, a hash of the file with the fields `sha256` and `integrity`. When `sha256` or `integrity` is user specified, setting an explicit `canonical_id` is highly recommended. e.g. [`get_default_canonical_id`](/rules/lib/repo/cache#get_default_canonical_id)
+Downloads a file to the output path for the provided url, extracts it, and returns a struct containing `success`, a flag which is `true` if the download completed successfully, and if successful, a hash of the file with the fields `sha256` and `integrity`. When `sha256` or `integrity` is user specified, setting an explicit `canonical_id` is highly recommended. e.g. [`get_default_canonical_id`](/versions/8.6.0/rules/lib/repo/cache#get_default_canonical_id)
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `url` | [string](../core/string); or Iterable of [string](../core/string)s; required  List of mirror URLs referencing the same file. |
-| `output` | [string](../core/string); or [Label](../builtins/Label); or [path](../builtins/path); default is `''`  Path to the directory where the archive will be unpacked, relative to the repository directory. |
-| `sha256` | [string](../core/string); default is `''`  The expected SHA-256 hash of the file downloaded. This must match the SHA-256 hash of the file downloaded. It is a security risk to omit the SHA-256 as remote files can change. At best omitting this field will make your build non-hermetic. It is optional to make development easier but should be set before shipping. If provided, the repository cache will first be checked for a file with the given hash; a download will only be attempted if the file was not found in the cache. After a successful download, the file will be added to the cache. |
-| `type` | [string](../core/string); default is `''`  The archive type of the downloaded file. By default, the archive type is determined from the file extension of the URL. If the file has no extension, you can explicitly specify either "zip", "jar", "war", "aar", "nupkg", "whl", "tar", "tar.gz", "tgz", "tar.xz", "txz", ".tar.zst", ".tzst", "tar.bz2", ".tbz", ".ar", or ".deb" here. |
-| `strip_prefix` | [string](../core/string); default is `''`  A directory prefix to strip from the extracted files. Many archives contain a top-level directory that contains all files in the archive. Instead of needing to specify this prefix over and over in the `build_file`, this field can be used to strip it from extracted files. For compatibility, this parameter may also be used under the deprecated name `stripPrefix`. |
-| `allow_fail` | [bool](../core/bool); default is `False`  If set, indicate the error in the return value instead of raising an error for failed downloads. |
-| `canonical_id` | [string](../core/string); default is `''`  If set, restrict cache hits to those cases where the file was added to the cache with the same canonical id. By default caching uses the checksum" (`sha256` or `integrity`). |
-| `auth` | [dict](../core/dict); default is `{}`  An optional dict specifying authentication information for some of the URLs. |
-| `headers` | [dict](../core/dict); default is `{}`  An optional dict specifying http headers for all URLs. |
-| `integrity` | [string](../core/string); default is `''`  Expected checksum of the file downloaded, in Subresource Integrity format. This must match the checksum of the file downloaded. It is a security risk to omit the checksum as remote files can change. At best omitting this field will make your build non-hermetic. It is optional to make development easier but should be set before shipping. If provided, the repository cache will first be checked for a file with the given checksum; a download will only be attempted if the file was not found in the cache. After a successful download, the file will be added to the cache. |
-| `rename_files` | [dict](../core/dict); default is `{}`  An optional dict specifying files to rename during the extraction. Archive entries with names exactly matching a key will be renamed to the value, prior to any directory prefix adjustment. This can be used to extract archives that contain non-Unicode filenames, or which have files that would extract to the same path on case-insensitive filesystems. |
+| `url` | [string](/versions/8.6.0/rules/lib/core/string); or Iterable of [string](/versions/8.6.0/rules/lib/core/string)s; required  List of mirror URLs referencing the same file. |
+| `output` | [string](/versions/8.6.0/rules/lib/core/string); or [Label](/versions/8.6.0/rules/lib/builtins/Label); or [path](/versions/8.6.0/rules/lib/builtins/path); default is `''`  Path to the directory where the archive will be unpacked, relative to the repository directory. |
+| `sha256` | [string](/versions/8.6.0/rules/lib/core/string); default is `''`  The expected SHA-256 hash of the file downloaded. This must match the SHA-256 hash of the file downloaded. It is a security risk to omit the SHA-256 as remote files can change. At best omitting this field will make your build non-hermetic. It is optional to make development easier but should be set before shipping. If provided, the repository cache will first be checked for a file with the given hash; a download will only be attempted if the file was not found in the cache. After a successful download, the file will be added to the cache. |
+| `type` | [string](/versions/8.6.0/rules/lib/core/string); default is `''`  The archive type of the downloaded file. By default, the archive type is determined from the file extension of the URL. If the file has no extension, you can explicitly specify either "zip", "jar", "war", "aar", "nupkg", "whl", "tar", "tar.gz", "tgz", "tar.xz", "txz", ".tar.zst", ".tzst", "tar.bz2", ".tbz", ".ar", or ".deb" here. |
+| `strip_prefix` | [string](/versions/8.6.0/rules/lib/core/string); default is `''`  A directory prefix to strip from the extracted files. Many archives contain a top-level directory that contains all files in the archive. Instead of needing to specify this prefix over and over in the `build_file`, this field can be used to strip it from extracted files. For compatibility, this parameter may also be used under the deprecated name `stripPrefix`. |
+| `allow_fail` | [bool](/versions/8.6.0/rules/lib/core/bool); default is `False`  If set, indicate the error in the return value instead of raising an error for failed downloads. |
+| `canonical_id` | [string](/versions/8.6.0/rules/lib/core/string); default is `''`  If set, restrict cache hits to those cases where the file was added to the cache with the same canonical id. By default caching uses the checksum" (`sha256` or `integrity`). |
+| `auth` | [dict](/versions/8.6.0/rules/lib/core/dict); default is `{}`  An optional dict specifying authentication information for some of the URLs. |
+| `headers` | [dict](/versions/8.6.0/rules/lib/core/dict); default is `{}`  An optional dict specifying http headers for all URLs. |
+| `integrity` | [string](/versions/8.6.0/rules/lib/core/string); default is `''`  Expected checksum of the file downloaded, in Subresource Integrity format. This must match the checksum of the file downloaded. It is a security risk to omit the checksum as remote files can change. At best omitting this field will make your build non-hermetic. It is optional to make development easier but should be set before shipping. If provided, the repository cache will first be checked for a file with the given checksum; a download will only be attempted if the file was not found in the cache. After a successful download, the file will be added to the cache. |
+| `rename_files` | [dict](/versions/8.6.0/rules/lib/core/dict); default is `{}`  An optional dict specifying files to rename during the extraction. Archive entries with names exactly matching a key will be renamed to the value, prior to any directory prefix adjustment. This can be used to extract archives that contain non-Unicode filenames, or which have files that would extract to the same path on case-insensitive filesystems. |
 
 ## execute
 
@@ -83,11 +83,11 @@ Executes the command given by the list of arguments. The execution time of the c
 
 | Parameter | Description |
 | --- | --- |
-| `arguments` | [sequence](../core/list); required  List of arguments, the first element should be the path to the program to execute. |
-| `timeout` | [int](../core/int); default is `600`  Maximum duration of the command in seconds (default is 600 seconds). |
-| `environment` | [dict](../core/dict); default is `{}`  Force some environment variables to be set to be passed to the process. The value can be `None` to remove the environment variable. |
-| `quiet` | [bool](../core/bool); default is `True`  If stdout and stderr should be printed to the terminal. |
-| `working_directory` | [string](../core/string); default is `""`  Working directory for command execution. Can be relative to the repository root or absolute. The default is the repository root. |
+| `arguments` | [sequence](/versions/8.6.0/rules/lib/core/list); required  List of arguments, the first element should be the path to the program to execute. |
+| `timeout` | [int](/versions/8.6.0/rules/lib/core/int); default is `600`  Maximum duration of the command in seconds (default is 600 seconds). |
+| `environment` | [dict](/versions/8.6.0/rules/lib/core/dict); default is `{}`  Force some environment variables to be set to be passed to the process. The value can be `None` to remove the environment variable. |
+| `quiet` | [bool](/versions/8.6.0/rules/lib/core/bool); default is `True`  If stdout and stderr should be printed to the terminal. |
+| `working_directory` | [string](/versions/8.6.0/rules/lib/core/string); default is `""`  Working directory for command execution. Can be relative to the repository root or absolute. The default is the repository root. |
 
 ## extension_metadata
 
@@ -101,10 +101,10 @@ Constructs an opaque object that can be returned from the module extension's imp
 
 | Parameter | Description |
 | --- | --- |
-| `root_module_direct_deps` | [sequence](../core/list) of [string](../core/string)s; or [string](../core/string); or `None`; default is `None`  The names of the repositories that the extension considers to be direct dependencies of the root module. If the root module imports additional repositories or does not import all of these repositories via [`use_repo`](../globals/module#use_repo), Bazel will print a warning when the extension is evaluated, instructing the user to run `bazel mod tidy` to fix the `use_repo` calls automatically. If one of `root_module_direct_deps` and will print a warning and a fixup command when the extension is evaluated. If one of `root_module_direct_deps` and `root_module_direct_dev_deps` is specified, the other has to be as well. The lists specified by these two parameters must be disjoint. Exactly one of `root_module_direct_deps` and `root_module_direct_dev_deps` can be set to the special value `"all"`, which is treated as if a list with the names of all repositories generated by the extension was specified as the value. |
-| `root_module_direct_dev_deps` | [sequence](../core/list) of [string](../core/string)s; or [string](../core/string); or `None`; default is `None`  The names of the repositories that the extension considers to be direct dev dependencies of the root module. If the root module imports additional repositories or does not import all of these repositories via [`use_repo`](../globals/module#use_repo) on an extension proxy created with `use_extension(..., dev_dependency = True)`, Bazel will print a warning when the extension is evaluated, instructing the user to run `bazel mod tidy` to fix the `use_repo` calls automatically. If one of `root_module_direct_deps` and `root_module_direct_dev_deps` is specified, the other has to be as well. The lists specified by these two parameters must be disjoint. Exactly one of `root_module_direct_deps` and `root_module_direct_dev_deps` can be set to the special value `"all"`, which is treated as if a list with the names of all repositories generated by the extension was specified as the value. |
-| `reproducible` | [bool](../core/bool); default is `False`  States that this module extension ensures complete reproducibility, thereby it should not be stored in the lockfile. |
-| `facts` | [dict](../core/dict) of [string](../core/string)s; default is `{}`  A JSON-like dict that is made available to future executions of this extension via the `module_ctx.facts` property. This is useful for extensions that want to preserve universally true facts such as the hashes of artifacts in an immutable repository. Bazel may shallowly merge multiple facts dicts returned by different versions of the extension in order to resolve merge conflicts on the MODULE.bazel.lock file, as if by applying the `dict.update()` method or the `|` operator in Starlark. Extensions should use facts for key-value storage only and ensure that the key uniquely determines the value, although perhaps only via additional information and network access. An extension can opt out of this merging by providing a dict with a single, fixed top-level key and an arbitrary value. Note that the value provided here may be read back by a different version of the extension, so either include a version number or use a schema that is unlikely to result in ambiguities. |
+| `root_module_direct_deps` | [sequence](/versions/8.6.0/rules/lib/core/list) of [string](/versions/8.6.0/rules/lib/core/string)s; or [string](/versions/8.6.0/rules/lib/core/string); or `None`; default is `None`  The names of the repositories that the extension considers to be direct dependencies of the root module. If the root module imports additional repositories or does not import all of these repositories via [`use_repo`](/versions/8.6.0/rules/lib/globals/module#use_repo), Bazel will print a warning when the extension is evaluated, instructing the user to run `bazel mod tidy` to fix the `use_repo` calls automatically. If one of `root_module_direct_deps` and will print a warning and a fixup command when the extension is evaluated. If one of `root_module_direct_deps` and `root_module_direct_dev_deps` is specified, the other has to be as well. The lists specified by these two parameters must be disjoint. Exactly one of `root_module_direct_deps` and `root_module_direct_dev_deps` can be set to the special value `"all"`, which is treated as if a list with the names of all repositories generated by the extension was specified as the value. |
+| `root_module_direct_dev_deps` | [sequence](/versions/8.6.0/rules/lib/core/list) of [string](/versions/8.6.0/rules/lib/core/string)s; or [string](/versions/8.6.0/rules/lib/core/string); or `None`; default is `None`  The names of the repositories that the extension considers to be direct dev dependencies of the root module. If the root module imports additional repositories or does not import all of these repositories via [`use_repo`](/versions/8.6.0/rules/lib/globals/module#use_repo) on an extension proxy created with `use_extension(..., dev_dependency = True)`, Bazel will print a warning when the extension is evaluated, instructing the user to run `bazel mod tidy` to fix the `use_repo` calls automatically. If one of `root_module_direct_deps` and `root_module_direct_dev_deps` is specified, the other has to be as well. The lists specified by these two parameters must be disjoint. Exactly one of `root_module_direct_deps` and `root_module_direct_dev_deps` can be set to the special value `"all"`, which is treated as if a list with the names of all repositories generated by the extension was specified as the value. |
+| `reproducible` | [bool](/versions/8.6.0/rules/lib/core/bool); default is `False`  States that this module extension ensures complete reproducibility, thereby it should not be stored in the lockfile. |
+| `facts` | [dict](/versions/8.6.0/rules/lib/core/dict) of [string](/versions/8.6.0/rules/lib/core/string)s; default is `{}`  A JSON-like dict that is made available to future executions of this extension via the `module_ctx.facts` property. This is useful for extensions that want to preserve universally true facts such as the hashes of artifacts in an immutable repository. Bazel may shallowly merge multiple facts dicts returned by different versions of the extension in order to resolve merge conflicts on the MODULE.bazel.lock file, as if by applying the `dict.update()` method or the `|` operator in Starlark. Extensions should use facts for key-value storage only and ensure that the key uniquely determines the value, although perhaps only via additional information and network access. An extension can opt out of this merging by providing a dict with a single, fixed top-level key and an arbitrary value. Note that the value provided here may be read back by a different version of the extension, so either include a version number or use a schema that is unlikely to result in ambiguities. |
 
 ## extract
 
@@ -118,11 +118,11 @@ Extract an archive to the repository directory.
 
 | Parameter | Description |
 | --- | --- |
-| `archive` | [string](../core/string); or [Label](../builtins/Label); or [path](../builtins/path); required  path to the archive that will be unpacked, relative to the repository directory. |
-| `output` | [string](../core/string); or [Label](../builtins/Label); or [path](../builtins/path); default is `''`  path to the directory where the archive will be unpacked, relative to the repository directory. |
-| `strip_prefix` | [string](../core/string); default is `''`  a directory prefix to strip from the extracted files. Many archives contain a top-level directory that contains all files in the archive. Instead of needing to specify this prefix over and over in the `build_file`, this field can be used to strip it from extracted files. For compatibility, this parameter may also be used under the deprecated name `stripPrefix`. |
-| `rename_files` | [dict](../core/dict); default is `{}`  An optional dict specifying files to rename during the extraction. Archive entries with names exactly matching a key will be renamed to the value, prior to any directory prefix adjustment. This can be used to extract archives that contain non-Unicode filenames, or which have files that would extract to the same path on case-insensitive filesystems. |
-| `watch_archive` | [string](../core/string); default is `'auto'`  whether to [watch](#watch) the archive file. Can be the string 'yes', 'no', or 'auto'. Passing 'yes' is equivalent to immediately invoking the [`watch()`](#watch) method; passing 'no' does not attempt to watch the file; passing 'auto' will only attempt to watch the file when it is legal to do so (see `watch()` docs for more information. |
+| `archive` | [string](/versions/8.6.0/rules/lib/core/string); or [Label](/versions/8.6.0/rules/lib/builtins/Label); or [path](/versions/8.6.0/rules/lib/builtins/path); required  path to the archive that will be unpacked, relative to the repository directory. |
+| `output` | [string](/versions/8.6.0/rules/lib/core/string); or [Label](/versions/8.6.0/rules/lib/builtins/Label); or [path](/versions/8.6.0/rules/lib/builtins/path); default is `''`  path to the directory where the archive will be unpacked, relative to the repository directory. |
+| `strip_prefix` | [string](/versions/8.6.0/rules/lib/core/string); default is `''`  a directory prefix to strip from the extracted files. Many archives contain a top-level directory that contains all files in the archive. Instead of needing to specify this prefix over and over in the `build_file`, this field can be used to strip it from extracted files. For compatibility, this parameter may also be used under the deprecated name `stripPrefix`. |
+| `rename_files` | [dict](/versions/8.6.0/rules/lib/core/dict); default is `{}`  An optional dict specifying files to rename during the extraction. Archive entries with names exactly matching a key will be renamed to the value, prior to any directory prefix adjustment. This can be used to extract archives that contain non-Unicode filenames, or which have files that would extract to the same path on case-insensitive filesystems. |
+| `watch_archive` | [string](/versions/8.6.0/rules/lib/core/string); default is `'auto'`  whether to [watch](#watch) the archive file. Can be the string 'yes', 'no', or 'auto'. Passing 'yes' is equivalent to immediately invoking the [`watch()`](#watch) method; passing 'no' does not attempt to watch the file; passing 'auto' will only attempt to watch the file when it is legal to do so (see `watch()` docs for more information. |
 
 ## facts
 
@@ -131,7 +131,7 @@ Facts module_ctx.facts
 ```
 
 The JSON-like dict returned by a previous execution of this extension in the `facts`
-parameter of [`extension_metadata`](../builtins/module_ctx#extension_metadata) or else
+parameter of [`extension_metadata`](/versions/8.6.0/rules/lib/builtins/module_ctx#extension_metadata) or else
 `{}`.
 This is useful for extensions that want to preserve universally true facts such as the
 hashes of artifacts in an immutable repository.
@@ -150,10 +150,10 @@ Generates a file in the repository directory with the provided content.
 
 | Parameter | Description |
 | --- | --- |
-| `path` | [string](../core/string); or [Label](../builtins/Label); or [path](../builtins/path); required  Path of the file to create, relative to the repository directory. |
-| `content` | [string](../core/string); default is `''`  The content of the file to create, empty by default. |
-| `executable` | [bool](../core/bool); default is `True`  Set the executable flag on the created file, true by default. |
-| `legacy_utf8` | [bool](../core/bool); default is `False`  No-op. This parameter is deprecated and will be removed in a future version of Bazel. |
+| `path` | [string](/versions/8.6.0/rules/lib/core/string); or [Label](/versions/8.6.0/rules/lib/builtins/Label); or [path](/versions/8.6.0/rules/lib/builtins/path); required  Path of the file to create, relative to the repository directory. |
+| `content` | [string](/versions/8.6.0/rules/lib/core/string); default is `''`  The content of the file to create, empty by default. |
+| `executable` | [bool](/versions/8.6.0/rules/lib/core/bool); default is `True`  Set the executable flag on the created file, true by default. |
+| `legacy_utf8` | [bool](/versions/8.6.0/rules/lib/core/bool); default is `False`  No-op. This parameter is deprecated and will be removed in a future version of Bazel. |
 
 ## getenv
 
@@ -169,8 +169,8 @@ When building incrementally, any change to the value of the variable named by `n
 
 | Parameter | Description |
 | --- | --- |
-| `name` | [string](../core/string); required  Name of desired environment variable. |
-| `default` | [string](../core/string); or `None`; default is `None`  Default value to return if `name` is not found. |
+| `name` | [string](/versions/8.6.0/rules/lib/core/string); required  Name of desired environment variable. |
+| `default` | [string](/versions/8.6.0/rules/lib/core/string); or `None`; default is `None`  Default value to return if `name` is not found. |
 
 May return `None`.
 
@@ -180,13 +180,13 @@ May return `None`.
 bool module_ctx.is_dev_dependency(tag)
 ```
 
-Returns whether the given tag was specified on the result of a [use_extension](../globals/module#use_extension) call with `devDependency = True`.
+Returns whether the given tag was specified on the result of a [use_extension](/versions/8.6.0/rules/lib/globals/module#use_extension) call with `devDependency = True`.
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `tag` | bazel_module_tag; required  A tag obtained from [bazel_module.tags](../builtins/bazel_module#tags). |
+| `tag` | bazel_module_tag; required  A tag obtained from [bazel_module.tags](/versions/8.6.0/rules/lib/builtins/bazel_module#tags). |
 
 ## modules
 
@@ -194,7 +194,7 @@ Returns whether the given tag was specified on the result of a [use_extension](.
 list module_ctx.modules
 ```
 
-A list of all the Bazel modules in the external dependency graph that use this module extension, each of which is a [bazel_module](../builtins/bazel_module) object that exposes all the tags it specified for this extension. The iteration order of this dictionary is guaranteed to be the same as breadth-first search starting from the root module.
+A list of all the Bazel modules in the external dependency graph that use this module extension, each of which is a [bazel_module](/versions/8.6.0/rules/lib/builtins/bazel_module) object that exposes all the tags it specified for this extension. The iteration order of this dictionary is guaranteed to be the same as breadth-first search starting from the root module.
 
 ## os
 
@@ -216,7 +216,7 @@ Returns a path from a string, label or path. If the path is relative, it will re
 
 | Parameter | Description |
 | --- | --- |
-| `path` | [string](../core/string); or [Label](../builtins/Label); or [path](../builtins/path); required  `string`, `Label` or `path` from which to create a path from. |
+| `path` | [string](/versions/8.6.0/rules/lib/core/string); or [Label](/versions/8.6.0/rules/lib/builtins/Label); or [path](/versions/8.6.0/rules/lib/builtins/path); required  `string`, `Label` or `path` from which to create a path from. |
 
 ## read
 
@@ -230,8 +230,8 @@ Reads the content of a file on the filesystem.
 
 | Parameter | Description |
 | --- | --- |
-| `path` | [string](../core/string); or [Label](../builtins/Label); or [path](../builtins/path); required  Path of the file to read from. |
-| `watch` | [string](../core/string); default is `'auto'`  Whether to [watch](#watch) the file. Can be the string 'yes', 'no', or 'auto'. Passing 'yes' is equivalent to immediately invoking the [`watch()`](#watch) method; passing 'no' does not attempt to watch the file; passing 'auto' will only attempt to watch the file when it is legal to do so (see `watch()` docs for more information. |
+| `path` | [string](/versions/8.6.0/rules/lib/core/string); or [Label](/versions/8.6.0/rules/lib/builtins/Label); or [path](/versions/8.6.0/rules/lib/builtins/path); required  Path of the file to read from. |
+| `watch` | [string](/versions/8.6.0/rules/lib/core/string); default is `'auto'`  Whether to [watch](#watch) the file. Can be the string 'yes', 'no', or 'auto'. Passing 'yes' is equivalent to immediately invoking the [`watch()`](#watch) method; passing 'no' does not attempt to watch the file; passing 'auto' will only attempt to watch the file when it is legal to do so (see `watch()` docs for more information. |
 
 ## report_progress
 
@@ -245,7 +245,7 @@ Updates the progress status for the fetching of this repository or module extens
 
 | Parameter | Description |
 | --- | --- |
-| `status` | [string](../core/string); default is `''`  `string` describing the current status of the fetch progress. |
+| `status` | [string](/versions/8.6.0/rules/lib/core/string); default is `''`  `string` describing the current status of the fetch progress. |
 
 ## root_module_has_non_dev_dependency
 
@@ -263,7 +263,7 @@ None module_ctx.watch(path)
 
 Tells Bazel to watch for changes to the given path, whether or not it exists, or whether it's a file or a directory. Any changes to the file or directory will invalidate this repository or module extension, and cause it to be refetched or re-evaluated next time.
 
-"Changes" include changes to the contents of the file (if the path is a file); if the path was a file but is now a directory, or vice versa; and if the path starts or stops existing. Notably, this does *not* include changes to any files under the directory if the path is a directory. For that, use [`path.readdir()`](path#readdir) instead.
+"Changes" include changes to the contents of the file (if the path is a file); if the path was a file but is now a directory, or vice versa; and if the path starts or stops existing. Notably, this does *not* include changes to any files under the directory if the path is a directory. For that, use [`path.readdir()`](/versions/8.6.0/rules/lib/builtins/path#readdir) instead.
 
 Note that attempting to watch paths inside the repo currently being fetched, or inside the working directory of the current module extension, will result in an error. A module extension attempting to watch a path outside the current Bazel workspace will also result in an error.
 
@@ -271,7 +271,7 @@ Note that attempting to watch paths inside the repo currently being fetched, or
 
 | Parameter | Description |
 | --- | --- |
-| `path` | [string](../core/string); or [Label](../builtins/Label); or [path](../builtins/path); required  Path of the file to watch. |
+| `path` | [string](/versions/8.6.0/rules/lib/core/string); or [Label](/versions/8.6.0/rules/lib/builtins/Label); or [path](/versions/8.6.0/rules/lib/builtins/path); required  Path of the file to watch. |
 
 ## which
 
@@ -285,6 +285,6 @@ Returns the `path` of the corresponding program or `None` if there is no such pr
 
 | Parameter | Description |
 | --- | --- |
-| `program` | [string](../core/string); required  Program to find in the path. |
+| `program` | [string](/versions/8.6.0/rules/lib/core/string); required  Program to find in the path. |
 
 May return `None`.
\ No newline at end of file
diff --git a/versions/8.6.0/rules/lib/builtins/path.mdx b/versions/8.6.0/rules/lib/builtins/path.mdx
index 29c87648..9a174205 100644
--- a/versions/8.6.0/rules/lib/builtins/path.mdx
+++ b/versions/8.6.0/rules/lib/builtins/path.mdx
@@ -77,7 +77,7 @@ Returns the list of entries in the directory denoted by this path. Each entry is
 
 | Parameter | Description |
 | --- | --- |
-| `watch` | [string](../core/string); default is `'auto'`  whether Bazel should watch the list of entries in this directory and refetch the repository or re-evaluate the module extension next time when any changes are detected. Changes to detect include entry creation, deletion, and renaming. Note that this doesn't watch the *contents* of any entries in the directory. Can be the string 'yes', 'no', or 'auto'. If set to 'auto', Bazel will only watch this directory when it is legal to do so (see [`repository_ctx.watch()`](repository_ctx#watch) docs for more information). |
+| `watch` | [string](/versions/8.6.0/rules/lib/core/string); default is `'auto'`  whether Bazel should watch the list of entries in this directory and refetch the repository or re-evaluate the module extension next time when any changes are detected. Changes to detect include entry creation, deletion, and renaming. Note that this doesn't watch the *contents* of any entries in the directory. Can be the string 'yes', 'no', or 'auto'. If set to 'auto', Bazel will only watch this directory when it is legal to do so (see [`repository_ctx.watch()`](/versions/8.6.0/rules/lib/builtins/repository_ctx#watch) docs for more information). |
 
 ## realpath
 
diff --git a/versions/8.6.0/rules/lib/builtins/repo_metadata.mdx b/versions/8.6.0/rules/lib/builtins/repo_metadata.mdx
index 6e2cd8ef..b7c162c1 100644
--- a/versions/8.6.0/rules/lib/builtins/repo_metadata.mdx
+++ b/versions/8.6.0/rules/lib/builtins/repo_metadata.mdx
@@ -2,4 +2,4 @@
 title: 'repo_metadata'
 ---
 
-See [`repository_ctx.repo_metadata`](repository_ctx#repo_metadata).
\ No newline at end of file
+See [`repository_ctx.repo_metadata`](/versions/8.6.0/rules/lib/builtins/repository_ctx#repo_metadata).
\ No newline at end of file
diff --git a/versions/8.6.0/rules/lib/builtins/repository_ctx.mdx b/versions/8.6.0/rules/lib/builtins/repository_ctx.mdx
index 65146df1..d1951b5e 100644
--- a/versions/8.6.0/rules/lib/builtins/repository_ctx.mdx
+++ b/versions/8.6.0/rules/lib/builtins/repository_ctx.mdx
@@ -50,7 +50,7 @@ Deletes a file or a directory. Returns a bool, indicating whether the file or di
 
 | Parameter | Description |
 | --- | --- |
-| `path` | [string](../core/string); or [path](../builtins/path); required  Path of the file to delete, relative to the repository directory, or absolute. Can be a path or a string. |
+| `path` | [string](/versions/8.6.0/rules/lib/core/string); or [path](/versions/8.6.0/rules/lib/builtins/path); required  Path of the file to delete, relative to the repository directory, or absolute. Can be a path or a string. |
 
 ## download
 
@@ -58,22 +58,22 @@ Deletes a file or a directory. Returns a bool, indicating whether the file or di
 unknown repository_ctx.download(url, output='', sha256='', executable=False, allow_fail=False, canonical_id='', auth={}, headers={}, *, integrity='', block=True)
 ```
 
-Downloads a file to the output path for the provided url and returns a struct containing `success`, a flag which is `true` if the download completed successfully, and if successful, a hash of the file with the fields `sha256` and `integrity`. When `sha256` or `integrity` is user specified, setting an explicit `canonical_id` is highly recommended. e.g. [`get_default_canonical_id`](/rules/lib/repo/cache#get_default_canonical_id)
+Downloads a file to the output path for the provided url and returns a struct containing `success`, a flag which is `true` if the download completed successfully, and if successful, a hash of the file with the fields `sha256` and `integrity`. When `sha256` or `integrity` is user specified, setting an explicit `canonical_id` is highly recommended. e.g. [`get_default_canonical_id`](/versions/8.6.0/rules/lib/repo/cache#get_default_canonical_id)
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `url` | [string](../core/string); or Iterable of [string](../core/string)s; required  List of mirror URLs referencing the same file. |
-| `output` | [string](../core/string); or [Label](../builtins/Label); or [path](../builtins/path); default is `''`  path to the output file, relative to the repository directory. |
-| `sha256` | [string](../core/string); default is `''`  The expected SHA-256 hash of the file downloaded. This must match the SHA-256 hash of the file downloaded. It is a security risk to omit the SHA-256 as remote files can change. At best omitting this field will make your build non-hermetic. It is optional to make development easier but should be set before shipping. If provided, the repository cache will first be checked for a file with the given hash; a download will only be attempted if the file was not found in the cache. After a successful download, the file will be added to the cache. |
-| `executable` | [bool](../core/bool); default is `False`  Set the executable flag on the created file, false by default. |
-| `allow_fail` | [bool](../core/bool); default is `False`  If set, indicate the error in the return value instead of raising an error for failed downloads. |
-| `canonical_id` | [string](../core/string); default is `''`  If set, restrict cache hits to those cases where the file was added to the cache with the same canonical id. By default caching uses the checksum (`sha256` or `integrity`). |
-| `auth` | [dict](../core/dict); default is `{}`  An optional dict specifying authentication information for some of the URLs. |
-| `headers` | [dict](../core/dict); default is `{}`  An optional dict specifying http headers for all URLs. |
-| `integrity` | [string](../core/string); default is `''`  Expected checksum of the file downloaded, in Subresource Integrity format. This must match the checksum of the file downloaded. It is a security risk to omit the checksum as remote files can change. At best omitting this field will make your build non-hermetic. It is optional to make development easier but should be set before shipping. If provided, the repository cache will first be checked for a file with the given checksum; a download will only be attempted if the file was not found in the cache. After a successful download, the file will be added to the cache. |
-| `block` | [bool](../core/bool); default is `True`  If set to false, the call returns immediately and instead of the regular return value, it returns a token with one single method, wait(), which blocks until the download is finished and returns the usual return value or throws as usual. |
+| `url` | [string](/versions/8.6.0/rules/lib/core/string); or Iterable of [string](/versions/8.6.0/rules/lib/core/string)s; required  List of mirror URLs referencing the same file. |
+| `output` | [string](/versions/8.6.0/rules/lib/core/string); or [Label](/versions/8.6.0/rules/lib/builtins/Label); or [path](/versions/8.6.0/rules/lib/builtins/path); default is `''`  path to the output file, relative to the repository directory. |
+| `sha256` | [string](/versions/8.6.0/rules/lib/core/string); default is `''`  The expected SHA-256 hash of the file downloaded. This must match the SHA-256 hash of the file downloaded. It is a security risk to omit the SHA-256 as remote files can change. At best omitting this field will make your build non-hermetic. It is optional to make development easier but should be set before shipping. If provided, the repository cache will first be checked for a file with the given hash; a download will only be attempted if the file was not found in the cache. After a successful download, the file will be added to the cache. |
+| `executable` | [bool](/versions/8.6.0/rules/lib/core/bool); default is `False`  Set the executable flag on the created file, false by default. |
+| `allow_fail` | [bool](/versions/8.6.0/rules/lib/core/bool); default is `False`  If set, indicate the error in the return value instead of raising an error for failed downloads. |
+| `canonical_id` | [string](/versions/8.6.0/rules/lib/core/string); default is `''`  If set, restrict cache hits to those cases where the file was added to the cache with the same canonical id. By default caching uses the checksum (`sha256` or `integrity`). |
+| `auth` | [dict](/versions/8.6.0/rules/lib/core/dict); default is `{}`  An optional dict specifying authentication information for some of the URLs. |
+| `headers` | [dict](/versions/8.6.0/rules/lib/core/dict); default is `{}`  An optional dict specifying http headers for all URLs. |
+| `integrity` | [string](/versions/8.6.0/rules/lib/core/string); default is `''`  Expected checksum of the file downloaded, in Subresource Integrity format. This must match the checksum of the file downloaded. It is a security risk to omit the checksum as remote files can change. At best omitting this field will make your build non-hermetic. It is optional to make development easier but should be set before shipping. If provided, the repository cache will first be checked for a file with the given checksum; a download will only be attempted if the file was not found in the cache. After a successful download, the file will be added to the cache. |
+| `block` | [bool](/versions/8.6.0/rules/lib/core/bool); default is `True`  If set to false, the call returns immediately and instead of the regular return value, it returns a token with one single method, wait(), which blocks until the download is finished and returns the usual return value or throws as usual. |
 
 ## download_and_extract
 
@@ -81,23 +81,23 @@ Downloads a file to the output path for the provided url and returns a struct co
 struct repository_ctx.download_and_extract(url, output='', sha256='', type='', strip_prefix='', allow_fail=False, canonical_id='', auth={}, headers={}, *, integrity='', rename_files={})
 ```
 
-Downloads a file to the output path for the provided url, extracts it, and returns a struct containing `success`, a flag which is `true` if the download completed successfully, and if successful, a hash of the file with the fields `sha256` and `integrity`. When `sha256` or `integrity` is user specified, setting an explicit `canonical_id` is highly recommended. e.g. [`get_default_canonical_id`](/rules/lib/repo/cache#get_default_canonical_id)
+Downloads a file to the output path for the provided url, extracts it, and returns a struct containing `success`, a flag which is `true` if the download completed successfully, and if successful, a hash of the file with the fields `sha256` and `integrity`. When `sha256` or `integrity` is user specified, setting an explicit `canonical_id` is highly recommended. e.g. [`get_default_canonical_id`](/versions/8.6.0/rules/lib/repo/cache#get_default_canonical_id)
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `url` | [string](../core/string); or Iterable of [string](../core/string)s; required  List of mirror URLs referencing the same file. |
-| `output` | [string](../core/string); or [Label](../builtins/Label); or [path](../builtins/path); default is `''`  Path to the directory where the archive will be unpacked, relative to the repository directory. |
-| `sha256` | [string](../core/string); default is `''`  The expected SHA-256 hash of the file downloaded. This must match the SHA-256 hash of the file downloaded. It is a security risk to omit the SHA-256 as remote files can change. At best omitting this field will make your build non-hermetic. It is optional to make development easier but should be set before shipping. If provided, the repository cache will first be checked for a file with the given hash; a download will only be attempted if the file was not found in the cache. After a successful download, the file will be added to the cache. |
-| `type` | [string](../core/string); default is `''`  The archive type of the downloaded file. By default, the archive type is determined from the file extension of the URL. If the file has no extension, you can explicitly specify either "zip", "jar", "war", "aar", "nupkg", "whl", "tar", "tar.gz", "tgz", "tar.xz", "txz", ".tar.zst", ".tzst", "tar.bz2", ".tbz", ".ar", or ".deb" here. |
-| `strip_prefix` | [string](../core/string); default is `''`  A directory prefix to strip from the extracted files. Many archives contain a top-level directory that contains all files in the archive. Instead of needing to specify this prefix over and over in the `build_file`, this field can be used to strip it from extracted files. For compatibility, this parameter may also be used under the deprecated name `stripPrefix`. |
-| `allow_fail` | [bool](../core/bool); default is `False`  If set, indicate the error in the return value instead of raising an error for failed downloads. |
-| `canonical_id` | [string](../core/string); default is `''`  If set, restrict cache hits to those cases where the file was added to the cache with the same canonical id. By default caching uses the checksum" (`sha256` or `integrity`). |
-| `auth` | [dict](../core/dict); default is `{}`  An optional dict specifying authentication information for some of the URLs. |
-| `headers` | [dict](../core/dict); default is `{}`  An optional dict specifying http headers for all URLs. |
-| `integrity` | [string](../core/string); default is `''`  Expected checksum of the file downloaded, in Subresource Integrity format. This must match the checksum of the file downloaded. It is a security risk to omit the checksum as remote files can change. At best omitting this field will make your build non-hermetic. It is optional to make development easier but should be set before shipping. If provided, the repository cache will first be checked for a file with the given checksum; a download will only be attempted if the file was not found in the cache. After a successful download, the file will be added to the cache. |
-| `rename_files` | [dict](../core/dict); default is `{}`  An optional dict specifying files to rename during the extraction. Archive entries with names exactly matching a key will be renamed to the value, prior to any directory prefix adjustment. This can be used to extract archives that contain non-Unicode filenames, or which have files that would extract to the same path on case-insensitive filesystems. |
+| `url` | [string](/versions/8.6.0/rules/lib/core/string); or Iterable of [string](/versions/8.6.0/rules/lib/core/string)s; required  List of mirror URLs referencing the same file. |
+| `output` | [string](/versions/8.6.0/rules/lib/core/string); or [Label](/versions/8.6.0/rules/lib/builtins/Label); or [path](/versions/8.6.0/rules/lib/builtins/path); default is `''`  Path to the directory where the archive will be unpacked, relative to the repository directory. |
+| `sha256` | [string](/versions/8.6.0/rules/lib/core/string); default is `''`  The expected SHA-256 hash of the file downloaded. This must match the SHA-256 hash of the file downloaded. It is a security risk to omit the SHA-256 as remote files can change. At best omitting this field will make your build non-hermetic. It is optional to make development easier but should be set before shipping. If provided, the repository cache will first be checked for a file with the given hash; a download will only be attempted if the file was not found in the cache. After a successful download, the file will be added to the cache. |
+| `type` | [string](/versions/8.6.0/rules/lib/core/string); default is `''`  The archive type of the downloaded file. By default, the archive type is determined from the file extension of the URL. If the file has no extension, you can explicitly specify either "zip", "jar", "war", "aar", "nupkg", "whl", "tar", "tar.gz", "tgz", "tar.xz", "txz", ".tar.zst", ".tzst", "tar.bz2", ".tbz", ".ar", or ".deb" here. |
+| `strip_prefix` | [string](/versions/8.6.0/rules/lib/core/string); default is `''`  A directory prefix to strip from the extracted files. Many archives contain a top-level directory that contains all files in the archive. Instead of needing to specify this prefix over and over in the `build_file`, this field can be used to strip it from extracted files. For compatibility, this parameter may also be used under the deprecated name `stripPrefix`. |
+| `allow_fail` | [bool](/versions/8.6.0/rules/lib/core/bool); default is `False`  If set, indicate the error in the return value instead of raising an error for failed downloads. |
+| `canonical_id` | [string](/versions/8.6.0/rules/lib/core/string); default is `''`  If set, restrict cache hits to those cases where the file was added to the cache with the same canonical id. By default caching uses the checksum" (`sha256` or `integrity`). |
+| `auth` | [dict](/versions/8.6.0/rules/lib/core/dict); default is `{}`  An optional dict specifying authentication information for some of the URLs. |
+| `headers` | [dict](/versions/8.6.0/rules/lib/core/dict); default is `{}`  An optional dict specifying http headers for all URLs. |
+| `integrity` | [string](/versions/8.6.0/rules/lib/core/string); default is `''`  Expected checksum of the file downloaded, in Subresource Integrity format. This must match the checksum of the file downloaded. It is a security risk to omit the checksum as remote files can change. At best omitting this field will make your build non-hermetic. It is optional to make development easier but should be set before shipping. If provided, the repository cache will first be checked for a file with the given checksum; a download will only be attempted if the file was not found in the cache. After a successful download, the file will be added to the cache. |
+| `rename_files` | [dict](/versions/8.6.0/rules/lib/core/dict); default is `{}`  An optional dict specifying files to rename during the extraction. Archive entries with names exactly matching a key will be renamed to the value, prior to any directory prefix adjustment. This can be used to extract archives that contain non-Unicode filenames, or which have files that would extract to the same path on case-insensitive filesystems. |
 
 ## execute
 
@@ -111,11 +111,11 @@ Executes the command given by the list of arguments. The execution time of the c
 
 | Parameter | Description |
 | --- | --- |
-| `arguments` | [sequence](../core/list); required  List of arguments, the first element should be the path to the program to execute. |
-| `timeout` | [int](../core/int); default is `600`  Maximum duration of the command in seconds (default is 600 seconds). |
-| `environment` | [dict](../core/dict); default is `{}`  Force some environment variables to be set to be passed to the process. The value can be `None` to remove the environment variable. |
-| `quiet` | [bool](../core/bool); default is `True`  If stdout and stderr should be printed to the terminal. |
-| `working_directory` | [string](../core/string); default is `""`  Working directory for command execution. Can be relative to the repository root or absolute. The default is the repository root. |
+| `arguments` | [sequence](/versions/8.6.0/rules/lib/core/list); required  List of arguments, the first element should be the path to the program to execute. |
+| `timeout` | [int](/versions/8.6.0/rules/lib/core/int); default is `600`  Maximum duration of the command in seconds (default is 600 seconds). |
+| `environment` | [dict](/versions/8.6.0/rules/lib/core/dict); default is `{}`  Force some environment variables to be set to be passed to the process. The value can be `None` to remove the environment variable. |
+| `quiet` | [bool](/versions/8.6.0/rules/lib/core/bool); default is `True`  If stdout and stderr should be printed to the terminal. |
+| `working_directory` | [string](/versions/8.6.0/rules/lib/core/string); default is `""`  Working directory for command execution. Can be relative to the repository root or absolute. The default is the repository root. |
 
 ## extract
 
@@ -129,11 +129,11 @@ Extract an archive to the repository directory.
 
 | Parameter | Description |
 | --- | --- |
-| `archive` | [string](../core/string); or [Label](../builtins/Label); or [path](../builtins/path); required  path to the archive that will be unpacked, relative to the repository directory. |
-| `output` | [string](../core/string); or [Label](../builtins/Label); or [path](../builtins/path); default is `''`  path to the directory where the archive will be unpacked, relative to the repository directory. |
-| `strip_prefix` | [string](../core/string); default is `''`  a directory prefix to strip from the extracted files. Many archives contain a top-level directory that contains all files in the archive. Instead of needing to specify this prefix over and over in the `build_file`, this field can be used to strip it from extracted files. For compatibility, this parameter may also be used under the deprecated name `stripPrefix`. |
-| `rename_files` | [dict](../core/dict); default is `{}`  An optional dict specifying files to rename during the extraction. Archive entries with names exactly matching a key will be renamed to the value, prior to any directory prefix adjustment. This can be used to extract archives that contain non-Unicode filenames, or which have files that would extract to the same path on case-insensitive filesystems. |
-| `watch_archive` | [string](../core/string); default is `'auto'`  whether to [watch](#watch) the archive file. Can be the string 'yes', 'no', or 'auto'. Passing 'yes' is equivalent to immediately invoking the [`watch()`](#watch) method; passing 'no' does not attempt to watch the file; passing 'auto' will only attempt to watch the file when it is legal to do so (see `watch()` docs for more information. |
+| `archive` | [string](/versions/8.6.0/rules/lib/core/string); or [Label](/versions/8.6.0/rules/lib/builtins/Label); or [path](/versions/8.6.0/rules/lib/builtins/path); required  path to the archive that will be unpacked, relative to the repository directory. |
+| `output` | [string](/versions/8.6.0/rules/lib/core/string); or [Label](/versions/8.6.0/rules/lib/builtins/Label); or [path](/versions/8.6.0/rules/lib/builtins/path); default is `''`  path to the directory where the archive will be unpacked, relative to the repository directory. |
+| `strip_prefix` | [string](/versions/8.6.0/rules/lib/core/string); default is `''`  a directory prefix to strip from the extracted files. Many archives contain a top-level directory that contains all files in the archive. Instead of needing to specify this prefix over and over in the `build_file`, this field can be used to strip it from extracted files. For compatibility, this parameter may also be used under the deprecated name `stripPrefix`. |
+| `rename_files` | [dict](/versions/8.6.0/rules/lib/core/dict); default is `{}`  An optional dict specifying files to rename during the extraction. Archive entries with names exactly matching a key will be renamed to the value, prior to any directory prefix adjustment. This can be used to extract archives that contain non-Unicode filenames, or which have files that would extract to the same path on case-insensitive filesystems. |
+| `watch_archive` | [string](/versions/8.6.0/rules/lib/core/string); default is `'auto'`  whether to [watch](#watch) the archive file. Can be the string 'yes', 'no', or 'auto'. Passing 'yes' is equivalent to immediately invoking the [`watch()`](#watch) method; passing 'no' does not attempt to watch the file; passing 'auto' will only attempt to watch the file when it is legal to do so (see `watch()` docs for more information. |
 
 ## file
 
@@ -147,10 +147,10 @@ Generates a file in the repository directory with the provided content.
 
 | Parameter | Description |
 | --- | --- |
-| `path` | [string](../core/string); or [Label](../builtins/Label); or [path](../builtins/path); required  Path of the file to create, relative to the repository directory. |
-| `content` | [string](../core/string); default is `''`  The content of the file to create, empty by default. |
-| `executable` | [bool](../core/bool); default is `True`  Set the executable flag on the created file, true by default. |
-| `legacy_utf8` | [bool](../core/bool); default is `False`  No-op. This parameter is deprecated and will be removed in a future version of Bazel. |
+| `path` | [string](/versions/8.6.0/rules/lib/core/string); or [Label](/versions/8.6.0/rules/lib/builtins/Label); or [path](/versions/8.6.0/rules/lib/builtins/path); required  Path of the file to create, relative to the repository directory. |
+| `content` | [string](/versions/8.6.0/rules/lib/core/string); default is `''`  The content of the file to create, empty by default. |
+| `executable` | [bool](/versions/8.6.0/rules/lib/core/bool); default is `True`  Set the executable flag on the created file, true by default. |
+| `legacy_utf8` | [bool](/versions/8.6.0/rules/lib/core/bool); default is `False`  No-op. This parameter is deprecated and will be removed in a future version of Bazel. |
 
 ## getenv
 
@@ -166,8 +166,8 @@ When building incrementally, any change to the value of the variable named by `n
 
 | Parameter | Description |
 | --- | --- |
-| `name` | [string](../core/string); required  Name of desired environment variable. |
-| `default` | [string](../core/string); or `None`; default is `None`  Default value to return if `name` is not found. |
+| `name` | [string](/versions/8.6.0/rules/lib/core/string); required  Name of desired environment variable. |
+| `default` | [string](/versions/8.6.0/rules/lib/core/string); or `None`; default is `None`  Default value to return if `name` is not found. |
 
 May return `None`.
 
@@ -207,9 +207,9 @@ Apply a patch file to the root directory of external repository. The patch file
 
 | Parameter | Description |
 | --- | --- |
-| `patch_file` | [string](../core/string); or [Label](../builtins/Label); or [path](../builtins/path); required  The patch file to apply, it can be label, relative path or absolute path. If it's a relative path, it will resolve to the repository directory. |
-| `strip` | [int](../core/int); default is `0`  Strip the specified number of leading components from file names. |
-| `watch_patch` | [string](../core/string); default is `'auto'`  Whether to [watch](#watch) the patch file. Can be the string 'yes', 'no', or 'auto'. Passing 'yes' is equivalent to immediately invoking the [`watch()`](#watch) method; passing 'no' does not attempt to watch the file; passing 'auto' will only attempt to watch the file when it is legal to do so (see `watch()` docs for more information. |
+| `patch_file` | [string](/versions/8.6.0/rules/lib/core/string); or [Label](/versions/8.6.0/rules/lib/builtins/Label); or [path](/versions/8.6.0/rules/lib/builtins/path); required  The patch file to apply, it can be label, relative path or absolute path. If it's a relative path, it will resolve to the repository directory. |
+| `strip` | [int](/versions/8.6.0/rules/lib/core/int); default is `0`  Strip the specified number of leading components from file names. |
+| `watch_patch` | [string](/versions/8.6.0/rules/lib/core/string); default is `'auto'`  Whether to [watch](#watch) the patch file. Can be the string 'yes', 'no', or 'auto'. Passing 'yes' is equivalent to immediately invoking the [`watch()`](#watch) method; passing 'no' does not attempt to watch the file; passing 'auto' will only attempt to watch the file when it is legal to do so (see `watch()` docs for more information. |
 
 ## path
 
@@ -223,7 +223,7 @@ Returns a path from a string, label or path. If the path is relative, it will re
 
 | Parameter | Description |
 | --- | --- |
-| `path` | [string](../core/string); or [Label](../builtins/Label); or [path](../builtins/path); required  `string`, `Label` or `path` from which to create a path from. |
+| `path` | [string](/versions/8.6.0/rules/lib/core/string); or [Label](/versions/8.6.0/rules/lib/builtins/Label); or [path](/versions/8.6.0/rules/lib/builtins/path); required  `string`, `Label` or `path` from which to create a path from. |
 
 ## read
 
@@ -237,8 +237,8 @@ Reads the content of a file on the filesystem.
 
 | Parameter | Description |
 | --- | --- |
-| `path` | [string](../core/string); or [Label](../builtins/Label); or [path](../builtins/path); required  Path of the file to read from. |
-| `watch` | [string](../core/string); default is `'auto'`  Whether to [watch](#watch) the file. Can be the string 'yes', 'no', or 'auto'. Passing 'yes' is equivalent to immediately invoking the [`watch()`](#watch) method; passing 'no' does not attempt to watch the file; passing 'auto' will only attempt to watch the file when it is legal to do so (see `watch()` docs for more information. |
+| `path` | [string](/versions/8.6.0/rules/lib/core/string); or [Label](/versions/8.6.0/rules/lib/builtins/Label); or [path](/versions/8.6.0/rules/lib/builtins/path); required  Path of the file to read from. |
+| `watch` | [string](/versions/8.6.0/rules/lib/core/string); default is `'auto'`  Whether to [watch](#watch) the file. Can be the string 'yes', 'no', or 'auto'. Passing 'yes' is equivalent to immediately invoking the [`watch()`](#watch) method; passing 'no' does not attempt to watch the file; passing 'auto' will only attempt to watch the file when it is legal to do so (see `watch()` docs for more information. |
 
 ## rename
 
@@ -253,8 +253,8 @@ already exists. Both paths must be located within the repository.
 
 | Parameter | Description |
 | --- | --- |
-| `src` | [string](../core/string); or [Label](../builtins/Label); or [path](../builtins/path); required  The path of the existing file or directory to rename, relative to the repository directory. |
-| `dst` | [string](../core/string); or [Label](../builtins/Label); or [path](../builtins/path); required  The new name to which the file or directory will be renamed to, relative to the repository directory. |
+| `src` | [string](/versions/8.6.0/rules/lib/core/string); or [Label](/versions/8.6.0/rules/lib/builtins/Label); or [path](/versions/8.6.0/rules/lib/builtins/path); required  The path of the existing file or directory to rename, relative to the repository directory. |
+| `dst` | [string](/versions/8.6.0/rules/lib/core/string); or [Label](/versions/8.6.0/rules/lib/builtins/Label); or [path](/versions/8.6.0/rules/lib/builtins/path); required  The new name to which the file or directory will be renamed to, relative to the repository directory. |
 
 ## repo_metadata
 
@@ -268,8 +268,8 @@ Constructs an opaque object that can be returned from the repo rule's implementa
 
 | Parameter | Description |
 | --- | --- |
-| `reproducible` | [bool](../core/bool); default is `False`  States that this repo can be reproducibly refetched; that is, if it were fetched another time with exactly the same input attributes, repo rule definition, watched files and environment variables, etc., then exactly the same output would be produced. This property needs to hold even if other untracked conditions change, such as information from the internet, the path of the workspace root, output from running arbitrary executables, etc. If set to True, this allows the fetched repo contents to be cached across workspaces. Note that setting this to True does not guarantee caching in the repo contents cache; for example, local repo rules are never cached. |
-| `attrs_for_reproducibility` | [dict](../core/dict); default is `{}`  If `reproducible` is False, this can be specified to tell Bazel which attributes of the original repo rule to change to make it reproducible. |
+| `reproducible` | [bool](/versions/8.6.0/rules/lib/core/bool); default is `False`  States that this repo can be reproducibly refetched; that is, if it were fetched another time with exactly the same input attributes, repo rule definition, watched files and environment variables, etc., then exactly the same output would be produced. This property needs to hold even if other untracked conditions change, such as information from the internet, the path of the workspace root, output from running arbitrary executables, etc. If set to True, this allows the fetched repo contents to be cached across workspaces. Note that setting this to True does not guarantee caching in the repo contents cache; for example, local repo rules are never cached. |
+| `attrs_for_reproducibility` | [dict](/versions/8.6.0/rules/lib/core/dict); default is `{}`  If `reproducible` is False, this can be specified to tell Bazel which attributes of the original repo rule to change to make it reproducible. |
 
 ## report_progress
 
@@ -283,7 +283,7 @@ Updates the progress status for the fetching of this repository or module extens
 
 | Parameter | Description |
 | --- | --- |
-| `status` | [string](../core/string); default is `''`  `string` describing the current status of the fetch progress. |
+| `status` | [string](/versions/8.6.0/rules/lib/core/string); default is `''`  `string` describing the current status of the fetch progress. |
 
 ## symlink
 
@@ -297,8 +297,8 @@ Creates a symlink on the filesystem.
 
 | Parameter | Description |
 | --- | --- |
-| `target` | [string](../core/string); or [Label](../builtins/Label); or [path](../builtins/path); required  The path that the symlink should point to. |
-| `link_name` | [string](../core/string); or [Label](../builtins/Label); or [path](../builtins/path); required  The path of the symlink to create. |
+| `target` | [string](/versions/8.6.0/rules/lib/core/string); or [Label](/versions/8.6.0/rules/lib/builtins/Label); or [path](/versions/8.6.0/rules/lib/builtins/path); required  The path that the symlink should point to. |
+| `link_name` | [string](/versions/8.6.0/rules/lib/core/string); or [Label](/versions/8.6.0/rules/lib/builtins/Label); or [path](/versions/8.6.0/rules/lib/builtins/path); required  The path of the symlink to create. |
 
 ## template
 
@@ -312,11 +312,11 @@ Generates a new file using a `template`. Every occurrence in `template` of a key
 
 | Parameter | Description |
 | --- | --- |
-| `path` | [string](../core/string); or [Label](../builtins/Label); or [path](../builtins/path); required  Path of the file to create, relative to the repository directory. |
-| `template` | [string](../core/string); or [Label](../builtins/Label); or [path](../builtins/path); required  Path to the template file. |
-| `substitutions` | [dict](../core/dict); default is `{}`  Substitutions to make when expanding the template. |
-| `executable` | [bool](../core/bool); default is `True`  Set the executable flag on the created file, true by default. |
-| `watch_template` | [string](../core/string); default is `'auto'`  Whether to [watch](#watch) the template file. Can be the string 'yes', 'no', or 'auto'. Passing 'yes' is equivalent to immediately invoking the [`watch()`](#watch) method; passing 'no' does not attempt to watch the file; passing 'auto' will only attempt to watch the file when it is legal to do so (see `watch()` docs for more information. |
+| `path` | [string](/versions/8.6.0/rules/lib/core/string); or [Label](/versions/8.6.0/rules/lib/builtins/Label); or [path](/versions/8.6.0/rules/lib/builtins/path); required  Path of the file to create, relative to the repository directory. |
+| `template` | [string](/versions/8.6.0/rules/lib/core/string); or [Label](/versions/8.6.0/rules/lib/builtins/Label); or [path](/versions/8.6.0/rules/lib/builtins/path); required  Path to the template file. |
+| `substitutions` | [dict](/versions/8.6.0/rules/lib/core/dict); default is `{}`  Substitutions to make when expanding the template. |
+| `executable` | [bool](/versions/8.6.0/rules/lib/core/bool); default is `True`  Set the executable flag on the created file, true by default. |
+| `watch_template` | [string](/versions/8.6.0/rules/lib/core/string); default is `'auto'`  Whether to [watch](#watch) the template file. Can be the string 'yes', 'no', or 'auto'. Passing 'yes' is equivalent to immediately invoking the [`watch()`](#watch) method; passing 'no' does not attempt to watch the file; passing 'auto' will only attempt to watch the file when it is legal to do so (see `watch()` docs for more information. |
 
 ## watch
 
@@ -326,7 +326,7 @@ None repository_ctx.watch(path)
 
 Tells Bazel to watch for changes to the given path, whether or not it exists, or whether it's a file or a directory. Any changes to the file or directory will invalidate this repository or module extension, and cause it to be refetched or re-evaluated next time.
 
-"Changes" include changes to the contents of the file (if the path is a file); if the path was a file but is now a directory, or vice versa; and if the path starts or stops existing. Notably, this does *not* include changes to any files under the directory if the path is a directory. For that, use [`path.readdir()`](path#readdir) instead.
+"Changes" include changes to the contents of the file (if the path is a file); if the path was a file but is now a directory, or vice versa; and if the path starts or stops existing. Notably, this does *not* include changes to any files under the directory if the path is a directory. For that, use [`path.readdir()`](/versions/8.6.0/rules/lib/builtins/path#readdir) instead.
 
 Note that attempting to watch paths inside the repo currently being fetched, or inside the working directory of the current module extension, will result in an error. A module extension attempting to watch a path outside the current Bazel workspace will also result in an error.
 
@@ -334,7 +334,7 @@ Note that attempting to watch paths inside the repo currently being fetched, or
 
 | Parameter | Description |
 | --- | --- |
-| `path` | [string](../core/string); or [Label](../builtins/Label); or [path](../builtins/path); required  Path of the file to watch. |
+| `path` | [string](/versions/8.6.0/rules/lib/core/string); or [Label](/versions/8.6.0/rules/lib/builtins/Label); or [path](/versions/8.6.0/rules/lib/builtins/path); required  Path of the file to watch. |
 
 ## watch_tree
 
@@ -350,7 +350,7 @@ Note that attempting to watch paths inside the repo currently being fetched will
 
 | Parameter | Description |
 | --- | --- |
-| `path` | [string](../core/string); or [Label](../builtins/Label); or [path](../builtins/path); required  Path of the directory tree to watch. |
+| `path` | [string](/versions/8.6.0/rules/lib/core/string); or [Label](/versions/8.6.0/rules/lib/builtins/Label); or [path](/versions/8.6.0/rules/lib/builtins/path); required  Path of the directory tree to watch. |
 
 ## which
 
@@ -364,7 +364,7 @@ Returns the `path` of the corresponding program or `None` if there is no such pr
 
 | Parameter | Description |
 | --- | --- |
-| `program` | [string](../core/string); required  Program to find in the path. |
+| `program` | [string](/versions/8.6.0/rules/lib/core/string); required  Program to find in the path. |
 
 May return `None`.
 
diff --git a/versions/8.6.0/rules/lib/builtins/repository_rule.mdx b/versions/8.6.0/rules/lib/builtins/repository_rule.mdx
index fcb15fed..bf5e249c 100644
--- a/versions/8.6.0/rules/lib/builtins/repository_rule.mdx
+++ b/versions/8.6.0/rules/lib/builtins/repository_rule.mdx
@@ -2,4 +2,4 @@
 title: 'repository_rule'
 ---
 
-A callable value that may be invoked during evaluation of the WORKSPACE file or within the implementation function of a module extension to instantiate and return a repository rule. Created by [`repository_rule()`](../globals/bzl#repository_rule).
\ No newline at end of file
+A callable value that may be invoked during evaluation of the WORKSPACE file or within the implementation function of a module extension to instantiate and return a repository rule. Created by [`repository_rule()`](/versions/8.6.0/rules/lib/globals/bzl#repository_rule).
\ No newline at end of file
diff --git a/versions/8.6.0/rules/lib/builtins/rule.mdx b/versions/8.6.0/rules/lib/builtins/rule.mdx
index b8e7291b..b8501dfa 100644
--- a/versions/8.6.0/rules/lib/builtins/rule.mdx
+++ b/versions/8.6.0/rules/lib/builtins/rule.mdx
@@ -3,7 +3,7 @@ title: 'rule'
 ---
 
 A callable value representing the type of a native or Starlark rule (created by
-[`rule()`](../globals/bzl#rule)). Calling the value during
+[`rule()`](/versions/8.6.0/rules/lib/globals/bzl#rule)). Calling the value during
 evaluation of a package's BUILD file creates an instance of the rule and adds it to the
 package's target set. For more information, visit this page about
-[Rules](https://bazel.build/extending/rules).
\ No newline at end of file
+[Rules](https://bazel.build/versions/8.6.0/extending/rules).
\ No newline at end of file
diff --git a/versions/8.6.0/rules/lib/builtins/rule_attributes.mdx b/versions/8.6.0/rules/lib/builtins/rule_attributes.mdx
index 08501bba..f466758b 100644
--- a/versions/8.6.0/rules/lib/builtins/rule_attributes.mdx
+++ b/versions/8.6.0/rules/lib/builtins/rule_attributes.mdx
@@ -20,7 +20,7 @@ Information about attributes of a rule an aspect is applied to.
 struct rule_attributes.attr
 ```
 
-A struct to access the values of the [attributes](https://bazel.build/extending/rules#attributes). The values are provided by the user (if not, a default value is used). The attributes of the struct and the types of their values correspond to the keys and values of the [`attrs` dict](../globals/bzl#rule.attrs) provided to the [`rule` function](../globals/bzl#rule). [See example of use](https://github.com/bazelbuild/examples/blob/main/rules/attributes/printer.bzl).
+A struct to access the values of the [attributes](https://bazel.build/versions/8.6.0/extending/rules#attributes). The values are provided by the user (if not, a default value is used). The attributes of the struct and the types of their values correspond to the keys and values of the [`attrs` dict](/versions/8.6.0/rules/lib/globals/bzl#rule.attrs) provided to the [`rule` function](/versions/8.6.0/rules/lib/globals/bzl#rule). [See example of use](https://github.com/bazelbuild/examples/blob/main/rules/attributes/printer.bzl).
 
 ## exec_groups
 
@@ -36,7 +36,7 @@ A collection of the execution groups available for the rule the aspect is applie
 struct rule_attributes.executable
 ```
 
-A `struct` containing executable files defined in [label type attributes](../toplevel/attr#label) marked as [`executable=True`](../toplevel/attr#label.executable). The struct fields correspond to the attribute names. Each value in the struct is either a [`File`](../builtins/File) or `None`. If an optional attribute is not specified in the rule then the corresponding struct value is `None`. If a label type is not marked as `executable=True`, no corresponding struct field is generated. [See example of use](https://github.com/bazelbuild/examples/blob/main/rules/actions_run/execute.bzl).
+A `struct` containing executable files defined in [label type attributes](/versions/8.6.0/rules/lib/toplevel/attr#label) marked as [`executable=True`](/versions/8.6.0/rules/lib/toplevel/attr#label.executable). The struct fields correspond to the attribute names. Each value in the struct is either a [`File`](/versions/8.6.0/rules/lib/builtins/File) or `None`. If an optional attribute is not specified in the rule then the corresponding struct value is `None`. If a label type is not marked as `executable=True`, no corresponding struct field is generated. [See example of use](https://github.com/bazelbuild/examples/blob/main/rules/actions_run/execute.bzl).
 
 ## file
 
@@ -44,13 +44,13 @@ A `struct` containing executable files defined in [label type attributes](../top
 struct rule_attributes.file
 ```
 
-A `struct` containing files defined in [label type attributes](../toplevel/attr#label) marked as [`allow_single_file`](../toplevel/attr#label.allow_single_file). The struct fields correspond to the attribute names. The struct value is always a [`File`](../builtins/File) or `None`. If an optional attribute is not specified in the rule then the corresponding struct value is `None`. If a label type is not marked as `allow_single_file`, no corresponding struct field is generated. It is a shortcut for:
+A `struct` containing files defined in [label type attributes](/versions/8.6.0/rules/lib/toplevel/attr#label) marked as [`allow_single_file`](/versions/8.6.0/rules/lib/toplevel/attr#label.allow_single_file). The struct fields correspond to the attribute names. The struct value is always a [`File`](/versions/8.6.0/rules/lib/builtins/File) or `None`. If an optional attribute is not specified in the rule then the corresponding struct value is `None`. If a label type is not marked as `allow_single_file`, no corresponding struct field is generated. It is a shortcut for:
 
 ```
 list(ctx.attr..files)[0]
 ```
 
-In other words, use `file` to access the (singular) [default output](https://bazel.build/extending/rules#requesting_output_files) of a dependency. [See example of use](https://github.com/bazelbuild/examples/blob/main/rules/expand_template/hello.bzl).
+In other words, use `file` to access the (singular) [default output](https://bazel.build/versions/8.6.0/extending/rules#requesting_output_files) of a dependency. [See example of use](https://github.com/bazelbuild/examples/blob/main/rules/expand_template/hello.bzl).
 
 ## files
 
@@ -58,13 +58,13 @@ In other words, use `file` to access the (singular) [default output](https://baz
 struct rule_attributes.files
 ```
 
-A `struct` containing files defined in [label](../toplevel/attr#label) or [label list](../toplevel/attr#label_list) type attributes. The struct fields correspond to the attribute names. The struct values are `list` of [`File`](../builtins/File)s. It is a shortcut for:
+A `struct` containing files defined in [label](/versions/8.6.0/rules/lib/toplevel/attr#label) or [label list](/versions/8.6.0/rules/lib/toplevel/attr#label_list) type attributes. The struct fields correspond to the attribute names. The struct values are `list` of [`File`](/versions/8.6.0/rules/lib/builtins/File)s. It is a shortcut for:
 
 ```
 [f for t in ctx.attr. for f in t.files]
 ```
 
-In other words, use `files` to access the  [default outputs](https://bazel.build/extending/rules#requesting_output_files) of a dependency. [See example of use](https://github.com/bazelbuild/examples/blob/main/rules/depsets/foo.bzl).
+In other words, use `files` to access the  [default outputs](https://bazel.build/versions/8.6.0/extending/rules#requesting_output_files) of a dependency. [See example of use](https://github.com/bazelbuild/examples/blob/main/rules/depsets/foo.bzl).
 
 ## kind
 
diff --git a/versions/8.6.0/rules/lib/builtins/runfiles.mdx b/versions/8.6.0/rules/lib/builtins/runfiles.mdx
index 83142b9a..4b40ab60 100644
--- a/versions/8.6.0/rules/lib/builtins/runfiles.mdx
+++ b/versions/8.6.0/rules/lib/builtins/runfiles.mdx
@@ -2,9 +2,9 @@
 title: 'runfiles'
 ---
 
-A container of information regarding a set of files required at runtime execution. This object should be passed via [DefaultInfo](../providers/DefaultInfo) in order to tell the build system about the runfiles needed by the outputs produced by the rule.
+A container of information regarding a set of files required at runtime execution. This object should be passed via [DefaultInfo](/versions/8.6.0/rules/lib/providers/DefaultInfo) in order to tell the build system about the runfiles needed by the outputs produced by the rule.
 
-See [runfiles guide](https://bazel.build/extending/rules#runfiles) for details.
+See [runfiles guide](https://bazel.build/versions/8.6.0/extending/rules#runfiles) for details.
 
 ## Members
 
@@ -45,7 +45,7 @@ Returns a new runfiles object that includes all the contents of this one and the
 
 | Parameter | Description |
 | --- | --- |
-| `other` | [runfiles](../builtins/runfiles); required  The runfiles object to merge into this. |
+| `other` | [runfiles](/versions/8.6.0/rules/lib/builtins/runfiles); required  The runfiles object to merge into this. |
 
 ## merge_all
 
@@ -59,7 +59,7 @@ Returns a new runfiles object that includes all the contents of this one and of
 
 | Parameter | Description |
 | --- | --- |
-| `other` | [sequence](../core/list) of [runfiles](../builtins/runfiles)s; required  The sequence of runfiles objects to merge into this. |
+| `other` | [sequence](/versions/8.6.0/rules/lib/core/list) of [runfiles](/versions/8.6.0/rules/lib/builtins/runfiles)s; required  The sequence of runfiles objects to merge into this. |
 
 ## root_symlinks
 
diff --git a/versions/8.6.0/rules/lib/builtins/tag_class.mdx b/versions/8.6.0/rules/lib/builtins/tag_class.mdx
index f1ed6e2b..bc361499 100644
--- a/versions/8.6.0/rules/lib/builtins/tag_class.mdx
+++ b/versions/8.6.0/rules/lib/builtins/tag_class.mdx
@@ -2,4 +2,4 @@
 title: 'tag_class'
 ---
 
-Defines a schema of attributes for a tag, created by [`tag_class()`](../globals/bzl#tag_class).
\ No newline at end of file
+Defines a schema of attributes for a tag, created by [`tag_class()`](/versions/8.6.0/rules/lib/globals/bzl#tag_class).
\ No newline at end of file
diff --git a/versions/8.6.0/rules/lib/builtins/transition.mdx b/versions/8.6.0/rules/lib/builtins/transition.mdx
index 307dda93..fe9c3d75 100644
--- a/versions/8.6.0/rules/lib/builtins/transition.mdx
+++ b/versions/8.6.0/rules/lib/builtins/transition.mdx
@@ -32,12 +32,12 @@ build_in_debug_mode = transition(
 )
 ```
 
-For more details see [here](https://bazel.build/rules/config#user-defined-transitions).
+For more details see [here](https://bazel.build/versions/8.6.0/rules/config#user-defined-transitions).
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
 | `implementation` | callable; required  The function implementing this transition. This function always has two parameters: `settings` and `attr`. The `settings` param is a dictionary whose set of keys is defined by the inputs parameter. So, for each build setting `--//foo=bar`, if `inputs` contains `//foo`, `settings` will have an entry `settings['//foo']='bar'`. The `attr` param is a reference to `ctx.attr`. This gives the implementation function access to the rule's attributes to make attribute-parameterized transitions possible. This function must return a `dict` from build setting identifier to build setting value; this represents the configuration transition: for each entry in the returned `dict`, the transition updates that setting to the new value. All other settings are unchanged. This function can also return a `list` of `dict`s or a `dict` of `dict`s in the case of a split transition. |
-| `inputs` | [sequence](../core/list) of [string](../core/string)s; required  List of build settings that can be read by this transition. This becomes the key set of the settings parameter of the implementation function parameter. |
-| `outputs` | [sequence](../core/list) of [string](../core/string)s; required  List of build settings that can be written by this transition. This must be a superset of the key set of the dictionary returned by this transition. |
\ No newline at end of file
+| `inputs` | [sequence](/versions/8.6.0/rules/lib/core/list) of [string](/versions/8.6.0/rules/lib/core/string)s; required  List of build settings that can be read by this transition. This becomes the key set of the settings parameter of the implementation function parameter. |
+| `outputs` | [sequence](/versions/8.6.0/rules/lib/core/list) of [string](/versions/8.6.0/rules/lib/core/string)s; required  List of build settings that can be written by this transition. This must be a superset of the key set of the dictionary returned by this transition. |
\ No newline at end of file
diff --git a/versions/8.6.0/rules/lib/core.mdx b/versions/8.6.0/rules/lib/core.mdx
index cd4a5839..8209b26d 100644
--- a/versions/8.6.0/rules/lib/core.mdx
+++ b/versions/8.6.0/rules/lib/core.mdx
@@ -4,15 +4,15 @@ title: 'Core Starlark data types'
 
 This section lists the data types of the [Starlark core language](https://github.com/bazelbuild/starlark/blob/master/spec.md#built-in-constants-and-functions). With some exceptions, these type names are not valid Starlark symbols; instances of them may be acquired through different means.
 
-* [bool](/rules/lib/core/bool)
-* [builtin_function_or_method](/rules/lib/core/builtin_function_or_method)
-* [dict](/rules/lib/core/dict)
-* [float](/rules/lib/core/float)
-* [function](/rules/lib/core/function)
-* [int](/rules/lib/core/int)
-* [json](/rules/lib/core/json)
-* [list](/rules/lib/core/list)
-* [range](/rules/lib/core/range)
-* [set](/rules/lib/core/set)
-* [string](/rules/lib/core/string)
-* [tuple](/rules/lib/core/tuple)
\ No newline at end of file
+* [bool](/versions/8.6.0/rules/lib/core/bool)
+* [builtin_function_or_method](/versions/8.6.0/rules/lib/core/builtin_function_or_method)
+* [dict](/versions/8.6.0/rules/lib/core/dict)
+* [float](/versions/8.6.0/rules/lib/core/float)
+* [function](/versions/8.6.0/rules/lib/core/function)
+* [int](/versions/8.6.0/rules/lib/core/int)
+* [json](/versions/8.6.0/rules/lib/core/json)
+* [list](/versions/8.6.0/rules/lib/core/list)
+* [range](/versions/8.6.0/rules/lib/core/range)
+* [set](/versions/8.6.0/rules/lib/core/set)
+* [string](/versions/8.6.0/rules/lib/core/string)
+* [tuple](/versions/8.6.0/rules/lib/core/tuple)
\ No newline at end of file
diff --git a/versions/8.6.0/rules/lib/core/bool.mdx b/versions/8.6.0/rules/lib/core/bool.mdx
index 52be3664..bc524e4d 100644
--- a/versions/8.6.0/rules/lib/core/bool.mdx
+++ b/versions/8.6.0/rules/lib/core/bool.mdx
@@ -2,4 +2,4 @@
 title: 'bool'
 ---
 
-A type to represent booleans. There are only two possible values: True and False. Any value can be converted to a boolean using the [bool](../globals/all#bool) function.
\ No newline at end of file
+A type to represent booleans. There are only two possible values: True and False. Any value can be converted to a boolean using the [bool](/versions/8.6.0/rules/lib/globals/all#bool) function.
\ No newline at end of file
diff --git a/versions/8.6.0/rules/lib/core/dict.mdx b/versions/8.6.0/rules/lib/core/dict.mdx
index 43bf94f5..281e4992 100644
--- a/versions/8.6.0/rules/lib/core/dict.mdx
+++ b/versions/8.6.0/rules/lib/core/dict.mdx
@@ -22,7 +22,7 @@ There are four ways to construct a dictionary:
      {i: 2*i for i in range(3)}  # {0: 0, 1: 2, 2: 4}
      ```
 
-     - A call to the built-in [dict](../globals/all#dict) function returns a dictionary containing the specified entries, which are inserted in argument order, positional arguments before named. As with comprehensions, duplicate keys are permitted.- The union expression `x | y` yields a new dictionary by combining two existing dictionaries. If the two dictionaries have a key `k` in common, the right hand side dictionary's value of the key (in other words, `y[k]`) wins. The `|=` variant of the union operator modifies a dictionary in-place. Example:
+     - A call to the built-in [dict](/versions/8.6.0/rules/lib/globals/all#dict) function returns a dictionary containing the specified entries, which are inserted in argument order, positional arguments before named. As with comprehensions, duplicate keys are permitted.- The union expression `x | y` yields a new dictionary by combining two existing dictionaries. If the two dictionaries have a key `k` in common, the right hand side dictionary's value of the key (in other words, `y[k]`) wins. The `|=` variant of the union operator modifies a dictionary in-place. Example:
 
          ```
          d = {"foo": "FOO", "bar": "BAR"} | {"foo": "FOO2", "baz": "BAZ"}
diff --git a/versions/8.6.0/rules/lib/core/json.mdx b/versions/8.6.0/rules/lib/core/json.mdx
index c792d362..eecc689d 100644
--- a/versions/8.6.0/rules/lib/core/json.mdx
+++ b/versions/8.6.0/rules/lib/core/json.mdx
@@ -29,7 +29,7 @@ If `x` is not a valid JSON encoding and the optional `default` parameter is *not
 
 | Parameter | Description |
 | --- | --- |
-| `x` | [string](../core/string); required  JSON string to decode. |
+| `x` | [string](/versions/8.6.0/rules/lib/core/string); required  JSON string to decode. |
 | `default` | default is `unbound`  If specified, the value to return when `x` cannot be decoded. |
 
 ## encode
@@ -64,8 +64,8 @@ The encode_indent function is equivalent to `json.indent(json.encode(x), ...)`.
 | Parameter | Description |
 | --- | --- |
 | `x` | required |
-| `prefix` | [string](../core/string); default is `''` |
-| `indent` | [string](../core/string); default is `'\t'` |
+| `prefix` | [string](/versions/8.6.0/rules/lib/core/string); default is `''` |
+| `indent` | [string](/versions/8.6.0/rules/lib/core/string); default is `'\t'` |
 
 ## indent
 
@@ -84,6 +84,6 @@ If the input is not valid, the function may fail or return invalid output.
 
 | Parameter | Description |
 | --- | --- |
-| `s` | [string](../core/string); required |
-| `prefix` | [string](../core/string); default is `''` |
-| `indent` | [string](../core/string); default is `'\t'` |
\ No newline at end of file
+| `s` | [string](/versions/8.6.0/rules/lib/core/string); required |
+| `prefix` | [string](/versions/8.6.0/rules/lib/core/string); default is `''` |
+| `indent` | [string](/versions/8.6.0/rules/lib/core/string); default is `'\t'` |
\ No newline at end of file
diff --git a/versions/8.6.0/rules/lib/core/list.mdx b/versions/8.6.0/rules/lib/core/list.mdx
index c19e9780..8e14cb8b 100644
--- a/versions/8.6.0/rules/lib/core/list.mdx
+++ b/versions/8.6.0/rules/lib/core/list.mdx
@@ -91,8 +91,8 @@ Returns the index in the list of the first item whose value is x. It is an error
 | Parameter | Description |
 | --- | --- |
 | `x` | required |
-| `start` | [int](../core/int); or `None`; default is `None`  The start index of the list portion to inspect. |
-| `end` | [int](../core/int); or `None`; default is `None`  The end index of the list portion to inspect. |
+| `start` | [int](/versions/8.6.0/rules/lib/core/int); or `None`; default is `None`  The start index of the list portion to inspect. |
+| `end` | [int](/versions/8.6.0/rules/lib/core/int); or `None`; default is `None`  The end index of the list portion to inspect. |
 
 ## insert
 
@@ -106,7 +106,7 @@ Inserts an item at a given position.
 
 | Parameter | Description |
 | --- | --- |
-| `index` | [int](../core/int); required  The index of the given position. |
+| `index` | [int](/versions/8.6.0/rules/lib/core/int); required  The index of the given position. |
 | `item` | required  The item. |
 
 ## pop
@@ -121,7 +121,7 @@ Removes the item at the given position in the list, and returns it. If no `index
 
 | Parameter | Description |
 | --- | --- |
-| `i` | [int](../core/int); or `None`; default is `-1`  The index of the item. |
+| `i` | [int](/versions/8.6.0/rules/lib/core/int); or `None`; default is `-1`  The index of the item. |
 
 ## remove
 
diff --git a/versions/8.6.0/rules/lib/core/set.mdx b/versions/8.6.0/rules/lib/core/set.mdx
index de115855..3e980871 100644
--- a/versions/8.6.0/rules/lib/core/set.mdx
+++ b/versions/8.6.0/rules/lib/core/set.mdx
@@ -3,14 +3,14 @@ title: 'set'
 ---
 
 The built-in set type. A set is a mutable, iterable collection of unique values – the set's
-*elements*. The [type name](../globals/all#type) of a set is `"set"`.
+*elements*. The [type name](/versions/8.6.0/rules/lib/globals/all#type) of a set is `"set"`.
 
 Sets provide constant-time operations to insert, remove, or check for the presence of a value.
 Sets are implemented using a hash table, and therefore, just like keys of a
-[dictionary](../dict), elements of a set must be hashable. A value may be used as an
+[dictionary](/versions/8.6.0/rules/lib/core/dict), elements of a set must be hashable. A value may be used as an
 element of a set if and only if it may be used as a key of a dictionary.
 
-Sets may be constructed using the [`set()`](../globals/all#set) built-in
+Sets may be constructed using the [`set()`](/versions/8.6.0/rules/lib/globals/all#set) built-in
 function, which returns a new set containing the unique elements of its optional argument, which
 must be an iterable. Calling `set()` without an argument constructs an empty set. Sets
 have no literal syntax.
@@ -26,7 +26,7 @@ s = set(["a", "b", "c"])
 
 A set is iterable, and thus may be used as the operand of a `for` loop, a list
 comprehension, and the various built-in functions that operate on iterables. Its length can be
-retrieved using the [`len()`](../globals/all#len) built-in function, and the
+retrieved using the [`len()`](/versions/8.6.0/rules/lib/globals/all#len) built-in function, and the
 order of iteration is the order in which elements were first added to the set:
 
 ```
diff --git a/versions/8.6.0/rules/lib/core/string.mdx b/versions/8.6.0/rules/lib/core/string.mdx
index fe2f2032..0203ad77 100644
--- a/versions/8.6.0/rules/lib/core/string.mdx
+++ b/versions/8.6.0/rules/lib/core/string.mdx
@@ -81,9 +81,9 @@ Returns the number of (non-overlapping) occurrences of substring `sub` in string
 
 | Parameter | Description |
 | --- | --- |
-| `sub` | [string](../core/string); required |
-| `start` | [int](../core/int); or `None`; default is `0` |
-| `end` | [int](../core/int); or `None`; default is `None`  optional position before which to restrict to search. |
+| `sub` | [string](/versions/8.6.0/rules/lib/core/string); required |
+| `start` | [int](/versions/8.6.0/rules/lib/core/int); or `None`; default is `0` |
+| `end` | [int](/versions/8.6.0/rules/lib/core/int); or `None`; default is `None`  optional position before which to restrict to search. |
 
 ## elems
 
@@ -105,9 +105,9 @@ Returns True if the string ends with `sub`, otherwise False, optionally restrict
 
 | Parameter | Description |
 | --- | --- |
-| `sub` | [string](../core/string); or [tuple](../core/tuple) of [string](../core/string)s; required  The suffix (or tuple of alternative suffixes) to match. |
-| `start` | [int](../core/int); or `None`; default is `0`  Test beginning at this position. |
-| `end` | [int](../core/int); or `None`; default is `None`  optional position at which to stop comparing. |
+| `sub` | [string](/versions/8.6.0/rules/lib/core/string); or [tuple](/versions/8.6.0/rules/lib/core/tuple) of [string](/versions/8.6.0/rules/lib/core/string)s; required  The suffix (or tuple of alternative suffixes) to match. |
+| `start` | [int](/versions/8.6.0/rules/lib/core/int); or `None`; default is `0`  Test beginning at this position. |
+| `end` | [int](/versions/8.6.0/rules/lib/core/int); or `None`; default is `None`  optional position at which to stop comparing. |
 
 ## find
 
@@ -121,9 +121,9 @@ Returns the first index where `sub` is found, or -1 if no such index exists, opt
 
 | Parameter | Description |
 | --- | --- |
-| `sub` | [string](../core/string); required  The substring to find. |
-| `start` | [int](../core/int); or `None`; default is `0`  Restrict to search from this position. |
-| `end` | [int](../core/int); or `None`; default is `None`  optional position before which to restrict to search. |
+| `sub` | [string](/versions/8.6.0/rules/lib/core/string); required  The substring to find. |
+| `start` | [int](/versions/8.6.0/rules/lib/core/int); or `None`; default is `0`  Restrict to search from this position. |
+| `end` | [int](/versions/8.6.0/rules/lib/core/int); or `None`; default is `None`  optional position before which to restrict to search. |
 
 ## format
 
@@ -131,7 +131,7 @@ Returns the first index where `sub` is found, or -1 if no such index exists, opt
 string string.format(*args, **kwargs)
 ```
 
-Perform string interpolation. Format strings contain replacement fields surrounded by curly braces `{}`. Anything that is not contained in braces is considered literal text, which is copied unchanged to the output.If you need to include a brace character in the literal text, it can be escaped by doubling: `{{` and `}}`A replacement field can be either a name, a number, or empty. Values are converted to strings using the [str](../globals/all#str) function.
+Perform string interpolation. Format strings contain replacement fields surrounded by curly braces `{}`. Anything that is not contained in braces is considered literal text, which is copied unchanged to the output.If you need to include a brace character in the literal text, it can be escaped by doubling: `{{` and `}}`A replacement field can be either a name, a number, or empty. Values are converted to strings using the [str](/versions/8.6.0/rules/lib/globals/all#str) function.
 
 ```
 # Access in order:
@@ -161,9 +161,9 @@ Returns the first index where `sub` is found, or raises an error if no such inde
 
 | Parameter | Description |
 | --- | --- |
-| `sub` | [string](../core/string); required  The substring to find. |
-| `start` | [int](../core/int); or `None`; default is `0`  Restrict to search from this position. |
-| `end` | [int](../core/int); or `None`; default is `None`  optional position before which to restrict to search. |
+| `sub` | [string](/versions/8.6.0/rules/lib/core/string); required  The substring to find. |
+| `start` | [int](/versions/8.6.0/rules/lib/core/int); or `None`; default is `0`  Restrict to search from this position. |
+| `end` | [int](/versions/8.6.0/rules/lib/core/int); or `None`; default is `None`  optional position before which to restrict to search. |
 
 ## isalnum
 
@@ -263,7 +263,7 @@ Returns a copy of the string where leading characters that appear in `chars` are
 
 | Parameter | Description |
 | --- | --- |
-| `chars` | [string](../core/string); or `None`; default is `None`  The characters to remove, or all whitespace if None. |
+| `chars` | [string](/versions/8.6.0/rules/lib/core/string); or `None`; default is `None`  The characters to remove, or all whitespace if None. |
 
 ## partition
 
@@ -277,7 +277,7 @@ Splits the input string at the first occurrence of the separator `sep` and retur
 
 | Parameter | Description |
 | --- | --- |
-| `sep` | [string](../core/string); required  The string to split on. |
+| `sep` | [string](/versions/8.6.0/rules/lib/core/string); required  The string to split on. |
 
 ## removeprefix
 
@@ -291,7 +291,7 @@ If the string starts with `prefix`, returns a new string with the prefix removed
 
 | Parameter | Description |
 | --- | --- |
-| `prefix` | [string](../core/string); required  The prefix to remove if present. |
+| `prefix` | [string](/versions/8.6.0/rules/lib/core/string); required  The prefix to remove if present. |
 
 ## removesuffix
 
@@ -305,7 +305,7 @@ If the string ends with `suffix`, returns a new string with the suffix removed.
 
 | Parameter | Description |
 | --- | --- |
-| `suffix` | [string](../core/string); required  The suffix to remove if present. |
+| `suffix` | [string](/versions/8.6.0/rules/lib/core/string); required  The suffix to remove if present. |
 
 ## replace
 
@@ -319,9 +319,9 @@ Returns a copy of the string in which the occurrences of `old` have been replace
 
 | Parameter | Description |
 | --- | --- |
-| `old` | [string](../core/string); required  The string to be replaced. |
-| `new` | [string](../core/string); required  The string to replace with. |
-| `count` | [int](../core/int); default is `-1`  The maximum number of replacements. If omitted, or if the value is negative, there is no limit. |
+| `old` | [string](/versions/8.6.0/rules/lib/core/string); required  The string to be replaced. |
+| `new` | [string](/versions/8.6.0/rules/lib/core/string); required  The string to replace with. |
+| `count` | [int](/versions/8.6.0/rules/lib/core/int); default is `-1`  The maximum number of replacements. If omitted, or if the value is negative, there is no limit. |
 
 ## rfind
 
@@ -335,9 +335,9 @@ Returns the last index where `sub` is found, or -1 if no such index exists, opti
 
 | Parameter | Description |
 | --- | --- |
-| `sub` | [string](../core/string); required  The substring to find. |
-| `start` | [int](../core/int); or `None`; default is `0`  Restrict to search from this position. |
-| `end` | [int](../core/int); or `None`; default is `None`  optional position before which to restrict to search. |
+| `sub` | [string](/versions/8.6.0/rules/lib/core/string); required  The substring to find. |
+| `start` | [int](/versions/8.6.0/rules/lib/core/int); or `None`; default is `0`  Restrict to search from this position. |
+| `end` | [int](/versions/8.6.0/rules/lib/core/int); or `None`; default is `None`  optional position before which to restrict to search. |
 
 ## rindex
 
@@ -351,9 +351,9 @@ Returns the last index where `sub` is found, or raises an error if no such index
 
 | Parameter | Description |
 | --- | --- |
-| `sub` | [string](../core/string); required  The substring to find. |
-| `start` | [int](../core/int); or `None`; default is `0`  Restrict to search from this position. |
-| `end` | [int](../core/int); or `None`; default is `None`  optional position before which to restrict to search. |
+| `sub` | [string](/versions/8.6.0/rules/lib/core/string); required  The substring to find. |
+| `start` | [int](/versions/8.6.0/rules/lib/core/int); or `None`; default is `0`  Restrict to search from this position. |
+| `end` | [int](/versions/8.6.0/rules/lib/core/int); or `None`; default is `None`  optional position before which to restrict to search. |
 
 ## rpartition
 
@@ -367,7 +367,7 @@ Splits the input string at the last occurrence of the separator `sep` and return
 
 | Parameter | Description |
 | --- | --- |
-| `sep` | [string](../core/string); required  The string to split on. |
+| `sep` | [string](/versions/8.6.0/rules/lib/core/string); required  The string to split on. |
 
 ## rsplit
 
@@ -381,8 +381,8 @@ Returns a list of all the words in the string, using `sep` as the separator, opt
 
 | Parameter | Description |
 | --- | --- |
-| `sep` | [string](../core/string); required  The string to split on. |
-| `maxsplit` | [int](../core/int); or `None`; default is `None`  The maximum number of splits. |
+| `sep` | [string](/versions/8.6.0/rules/lib/core/string); required  The string to split on. |
+| `maxsplit` | [int](/versions/8.6.0/rules/lib/core/int); or `None`; default is `None`  The maximum number of splits. |
 
 ## rstrip
 
@@ -400,7 +400,7 @@ Returns a copy of the string where trailing characters that appear in `chars` ar
 
 | Parameter | Description |
 | --- | --- |
-| `chars` | [string](../core/string); or `None`; default is `None`  The characters to remove, or all whitespace if None. |
+| `chars` | [string](/versions/8.6.0/rules/lib/core/string); or `None`; default is `None`  The characters to remove, or all whitespace if None. |
 
 ## split
 
@@ -414,8 +414,8 @@ Returns a list of all the words in the string, using `sep` as the separator, opt
 
 | Parameter | Description |
 | --- | --- |
-| `sep` | [string](../core/string); required  The string to split on. |
-| `maxsplit` | [int](../core/int); or `None`; default is `None`  The maximum number of splits. |
+| `sep` | [string](/versions/8.6.0/rules/lib/core/string); required  The string to split on. |
+| `maxsplit` | [int](/versions/8.6.0/rules/lib/core/int); or `None`; default is `None`  The maximum number of splits. |
 
 ## splitlines
 
@@ -429,7 +429,7 @@ Splits the string at line boundaries ('\n', '\r\n', '\r') and returns the result
 
 | Parameter | Description |
 | --- | --- |
-| `keepends` | [bool](../core/bool); default is `False`  Whether the line breaks should be included in the resulting list. |
+| `keepends` | [bool](/versions/8.6.0/rules/lib/core/bool); default is `False`  Whether the line breaks should be included in the resulting list. |
 
 ## startswith
 
@@ -443,9 +443,9 @@ Returns True if the string starts with `sub`, otherwise False, optionally restri
 
 | Parameter | Description |
 | --- | --- |
-| `sub` | [string](../core/string); or [tuple](../core/tuple) of [string](../core/string)s; required  The prefix (or tuple of alternative prefixes) to match. |
-| `start` | [int](../core/int); or `None`; default is `0`  Test beginning at this position. |
-| `end` | [int](../core/int); or `None`; default is `None`  Stop comparing at this position. |
+| `sub` | [string](/versions/8.6.0/rules/lib/core/string); or [tuple](/versions/8.6.0/rules/lib/core/tuple) of [string](/versions/8.6.0/rules/lib/core/string)s; required  The prefix (or tuple of alternative prefixes) to match. |
+| `start` | [int](/versions/8.6.0/rules/lib/core/int); or `None`; default is `0`  Test beginning at this position. |
+| `end` | [int](/versions/8.6.0/rules/lib/core/int); or `None`; default is `None`  Stop comparing at this position. |
 
 ## strip
 
@@ -463,7 +463,7 @@ Returns a copy of the string where leading or trailing characters that appear in
 
 | Parameter | Description |
 | --- | --- |
-| `chars` | [string](../core/string); or `None`; default is `None`  The characters to remove, or all whitespace if None. |
+| `chars` | [string](/versions/8.6.0/rules/lib/core/string); or `None`; default is `None`  The characters to remove, or all whitespace if None. |
 
 ## title
 
diff --git a/versions/8.6.0/rules/lib/fragments.mdx b/versions/8.6.0/rules/lib/fragments.mdx
index e472c65d..8a6db018 100644
--- a/versions/8.6.0/rules/lib/fragments.mdx
+++ b/versions/8.6.0/rules/lib/fragments.mdx
@@ -2,18 +2,18 @@
 title: 'Configuration Fragments'
 ---
 
-Configuration fragments give rules access to language-specific parts of [configuration](builtins/configuration).
+Configuration fragments give rules access to language-specific parts of [configuration](/versions/8.6.0/rules/lib/builtins/configuration).
 
 Rule implementations can get them using `ctx.fragments.[fragment name]`
 
-* [apple](/rules/lib/fragments/apple)
-* [bazel_android](/rules/lib/fragments/bazel_android)
-* [bazel_py](/rules/lib/fragments/bazel_py)
-* [coverage](/rules/lib/fragments/coverage)
-* [cpp](/rules/lib/fragments/cpp)
-* [j2objc](/rules/lib/fragments/j2objc)
-* [java](/rules/lib/fragments/java)
-* [objc](/rules/lib/fragments/objc)
-* [platform](/rules/lib/fragments/platform)
-* [proto](/rules/lib/fragments/proto)
-* [py](/rules/lib/fragments/py)
\ No newline at end of file
+* [apple](/versions/8.6.0/rules/lib/fragments/apple)
+* [bazel_android](/versions/8.6.0/rules/lib/fragments/bazel_android)
+* [bazel_py](/versions/8.6.0/rules/lib/fragments/bazel_py)
+* [coverage](/versions/8.6.0/rules/lib/fragments/coverage)
+* [cpp](/versions/8.6.0/rules/lib/fragments/cpp)
+* [j2objc](/versions/8.6.0/rules/lib/fragments/j2objc)
+* [java](/versions/8.6.0/rules/lib/fragments/java)
+* [objc](/versions/8.6.0/rules/lib/fragments/objc)
+* [platform](/versions/8.6.0/rules/lib/fragments/platform)
+* [proto](/versions/8.6.0/rules/lib/fragments/proto)
+* [py](/versions/8.6.0/rules/lib/fragments/py)
\ No newline at end of file
diff --git a/versions/8.6.0/rules/lib/fragments/apple.mdx b/versions/8.6.0/rules/lib/fragments/apple.mdx
index 9d7d9512..e655f648 100644
--- a/versions/8.6.0/rules/lib/fragments/apple.mdx
+++ b/versions/8.6.0/rules/lib/fragments/apple.mdx
@@ -22,7 +22,7 @@ The platform of the current configuration for the given platform type. This shou
 
 | Parameter | Description |
 | --- | --- |
-| `platform_type` | [string](../core/string); required  The apple platform type. |
+| `platform_type` | [string](/versions/8.6.0/rules/lib/core/string); required  The apple platform type. |
 
 ## single_arch_cpu
 
diff --git a/versions/8.6.0/rules/lib/fragments/coverage.mdx b/versions/8.6.0/rules/lib/fragments/coverage.mdx
index 200a79ba..5e1a26b0 100644
--- a/versions/8.6.0/rules/lib/fragments/coverage.mdx
+++ b/versions/8.6.0/rules/lib/fragments/coverage.mdx
@@ -14,7 +14,7 @@ A configuration fragment representing the coverage configuration.
 Label coverage.output_generator
 ```
 
-Returns the label pointed to by the [`--coverage_output_generator`](https://bazel.build/reference/command-line-reference#flag--coverage_output_generator) option if coverage collection is enabled, otherwise returns `None`. Can be accessed with [`configuration_field`](../globals/bzl#configuration_field):
+Returns the label pointed to by the [`--coverage_output_generator`](https://bazel.build/versions/8.6.0/reference/command-line-reference#flag--coverage_output_generator) option if coverage collection is enabled, otherwise returns `None`. Can be accessed with [`configuration_field`](/versions/8.6.0/rules/lib/globals/bzl#configuration_field):
 
 ```
 attr.label(
diff --git a/versions/8.6.0/rules/lib/fragments/cpp.mdx b/versions/8.6.0/rules/lib/fragments/cpp.mdx
index c2214f33..44a717f3 100644
--- a/versions/8.6.0/rules/lib/fragments/cpp.mdx
+++ b/versions/8.6.0/rules/lib/fragments/cpp.mdx
@@ -30,7 +30,7 @@ Whether to generate Apple debug symbol(.dSYM) artifacts.
 list cpp.conlyopts
 ```
 
-The flags passed to Bazel by [`--conlyopt`](/docs/user-manual#flag--conlyopt) option.
+The flags passed to Bazel by [`--conlyopt`](/versions/8.6.0/docs/user-manual#flag--conlyopt) option.
 
 ## copts
 
@@ -38,7 +38,7 @@ The flags passed to Bazel by [`--conlyopt`](/docs/user-manual#flag--conlyopt) op
 list cpp.copts
 ```
 
-The flags passed to Bazel by [`--copt`](/docs/user-manual#flag--copt) option.
+The flags passed to Bazel by [`--copt`](/versions/8.6.0/docs/user-manual#flag--copt) option.
 
 ## custom_malloc
 
@@ -46,7 +46,7 @@ The flags passed to Bazel by [`--copt`](/docs/user-manual#flag--copt) option.
 Label cpp.custom_malloc
 ```
 
-Returns label pointed to by [`--custom_malloc`](/docs/user-manual#flag--custom_malloc) option. Can be accessed with [`configuration_field`](../globals/bzl#configuration_field):
+Returns label pointed to by [`--custom_malloc`](/versions/8.6.0/docs/user-manual#flag--custom_malloc) option. Can be accessed with [`configuration_field`](/versions/8.6.0/rules/lib/globals/bzl#configuration_field):
 
 ```
 attr.label(
@@ -65,7 +65,7 @@ May return `None`.
 list cpp.cxxopts
 ```
 
-The flags passed to Bazel by [`--cxxopt`](/docs/user-manual#flag--cxxopt) option.
+The flags passed to Bazel by [`--cxxopt`](/versions/8.6.0/docs/user-manual#flag--cxxopt) option.
 
 ## linkopts
 
@@ -73,7 +73,7 @@ The flags passed to Bazel by [`--cxxopt`](/docs/user-manual#flag--cxxopt) option
 list cpp.linkopts
 ```
 
-The flags passed to Bazel by [`--linkopt`](/docs/user-manual#flag--linkopt) option.
+The flags passed to Bazel by [`--linkopt`](/versions/8.6.0/docs/user-manual#flag--linkopt) option.
 
 ## objc_generate_linkmap
 
@@ -97,4 +97,4 @@ bool cpp.objc_should_strip_binary
 list cpp.objccopts
 ```
 
-The flags passed to Bazel by [`--objccopt`](/docs/user-manual#flag--objccopt) option.
\ No newline at end of file
+The flags passed to Bazel by [`--objccopt`](/versions/8.6.0/docs/user-manual#flag--objccopt) option.
\ No newline at end of file
diff --git a/versions/8.6.0/rules/lib/globals.mdx b/versions/8.6.0/rules/lib/globals.mdx
index 3ca78637..8f4a6280 100644
--- a/versions/8.6.0/rules/lib/globals.mdx
+++ b/versions/8.6.0/rules/lib/globals.mdx
@@ -4,10 +4,10 @@ title: 'Global functions'
 
 This section lists the global functions available in Starlark. The list of available functions differs depending on the file type (whether a BUILD file, or a .bzl file, etc).
 
-* [.bzl files](/rules/lib/globals/bzl)
-* [All Bazel files](/rules/lib/globals/all)
-* [BUILD files](/rules/lib/globals/build)
-* [MODULE.bazel files](/rules/lib/globals/module)
-* [REPO.bazel files](/rules/lib/globals/repo)
-* [VENDOR.bazel files](/rules/lib/globals/vendor)
-* [WORKSPACE files](/rules/lib/globals/workspace)
\ No newline at end of file
+* [.bzl files](/versions/8.6.0/rules/lib/globals/bzl)
+* [All Bazel files](/versions/8.6.0/rules/lib/globals/all)
+* [BUILD files](/versions/8.6.0/rules/lib/globals/build)
+* [MODULE.bazel files](/versions/8.6.0/rules/lib/globals/module)
+* [REPO.bazel files](/versions/8.6.0/rules/lib/globals/repo)
+* [VENDOR.bazel files](/versions/8.6.0/rules/lib/globals/vendor)
+* [WORKSPACE files](/versions/8.6.0/rules/lib/globals/workspace)
\ No newline at end of file
diff --git a/versions/8.6.0/rules/lib/globals/all.mdx b/versions/8.6.0/rules/lib/globals/all.mdx
index 79b73dd2..9c9ec13c 100644
--- a/versions/8.6.0/rules/lib/globals/all.mdx
+++ b/versions/8.6.0/rules/lib/globals/all.mdx
@@ -50,7 +50,7 @@ abs(-2.3) == 2.3
 
 | Parameter | Description |
 | --- | --- |
-| `x` | [int](../core/int); or [float](../core/float); required  A number (int or float) |
+| `x` | [int](/versions/8.6.0/rules/lib/core/int); or [float](/versions/8.6.0/rules/lib/core/float); required  A number (int or float) |
 
 ## all
 
@@ -110,7 +110,7 @@ Constructor for the bool type. It returns `False` if the object is `None`, `Fals
 dict dict(pairs=[], **kwargs)
 ```
 
-Creates a [dictionary](../core/dict) from an optional positional argument and an optional set of keyword arguments. In the case where the same key is given multiple times, the last value will be used. Entries supplied via keyword arguments are considered to come after entries supplied via the positional argument.
+Creates a [dictionary](/versions/8.6.0/rules/lib/core/dict) from an optional positional argument and an optional set of keyword arguments. In the case where the same key is given multiple times, the last value will be used. Entries supplied via keyword arguments are considered to come after entries supplied via the positional argument.
 
 ### Parameters
 
@@ -150,7 +150,7 @@ enumerate([24, 21, 84]) == [(0, 24), (1, 21), (2, 84)]
 | Parameter | Description |
 | --- | --- |
 | `list` | required  input sequence. |
-| `start` | [int](../core/int); default is `0`  start index. |
+| `start` | [int](/versions/8.6.0/rules/lib/core/int); default is `0`  start index. |
 
 ## fail
 
@@ -165,8 +165,8 @@ Causes execution to fail with an error.
 | Parameter | Description |
 | --- | --- |
 | `msg` | default is `None`  Deprecated: use positional arguments instead. This argument acts like an implicit leading positional argument. |
-| `attr` | [string](../core/string); or `None`; default is `None`  Deprecated. Causes an optional prefix containing this string to be added to the error message. |
-| `sep` | [string](../core/string); default is `" "`  The separator string between the objects, default is space (" "). |
+| `attr` | [string](/versions/8.6.0/rules/lib/core/string); or `None`; default is `None`  Deprecated. Causes an optional prefix containing this string to be added to the error message. |
+| `sep` | [string](/versions/8.6.0/rules/lib/core/string); default is `" "`  The separator string between the objects, default is space (" "). |
 | `args` | required  A list of values, formatted with debugPrint (which is equivalent to str by default) and joined with sep (defaults to " "), that appear in the error message. |
 
 ## float
@@ -205,7 +205,7 @@ getattr(ctx.attr, "myattr", "mydefault")
 | Parameter | Description |
 | --- | --- |
 | `x` | required  The struct whose attribute is accessed. |
-| `name` | [string](../core/string); required  The name of the struct attribute. |
+| `name` | [string](/versions/8.6.0/rules/lib/core/string); required  The name of the struct attribute. |
 | `default` | default is `unbound`  The default value to return in case the struct doesn't have an attribute of the given name. |
 
 ## hasattr
@@ -225,7 +225,7 @@ hasattr(ctx.attr, "myattr")
 | Parameter | Description |
 | --- | --- |
 | `x` | required |
-| `name` | [string](../core/string); required  The name of the attribute. |
+| `name` | [string](/versions/8.6.0/rules/lib/core/string); required  The name of the attribute. |
 
 ## hash
 
@@ -245,7 +245,7 @@ Hashing of values besides strings is not currently supported.
 
 | Parameter | Description |
 | --- | --- |
-| `value` | [string](../core/string); required  String value to hash. |
+| `value` | [string](/versions/8.6.0/rules/lib/core/string); required  String value to hash. |
 
 ## int
 
@@ -372,7 +372,7 @@ Using `print` in production code is discouraged due to the spam it creates for u
 
 | Parameter | Description |
 | --- | --- |
-| `sep` | [string](../core/string); default is `" "`  The separator string between the objects, default is space (" "). |
+| `sep` | [string](/versions/8.6.0/rules/lib/core/string); default is `" "`  The separator string between the objects, default is space (" "). |
 | `args` | required  The objects to print. |
 
 ## range
@@ -393,9 +393,9 @@ range(3, 0, -1) == [3, 2, 1]
 
 | Parameter | Description |
 | --- | --- |
-| `start_or_stop` | [int](../core/int); required  Value of the start element if stop is provided, otherwise value of stop and the actual start is 0 |
-| `stop_or_none` | [int](../core/int); or `None`; default is `None`  optional index of the first item *not* to be included in the resulting list; generation of the list stops before `stop` is reached. |
-| `step` | [int](../core/int); default is `1`  The increment (default is 1). It may be negative. |
+| `start_or_stop` | [int](/versions/8.6.0/rules/lib/core/int); required  Value of the start element if stop is provided, otherwise value of stop and the actual start is 0 |
+| `stop_or_none` | [int](/versions/8.6.0/rules/lib/core/int); or `None`; default is `None`  optional index of the first item *not* to be included in the resulting list; generation of the list stops before `stop` is reached. |
+| `step` | [int](/versions/8.6.0/rules/lib/core/int); default is `1`  The increment (default is 1). It may be negative. |
 
 ## repr
 
@@ -439,7 +439,7 @@ reversed([3, 5, 4]) == [4, 5, 3]
 set set(elements=[])
 ```
 
-Creates a new [set](../core/set) containing the unique elements of a given
+Creates a new [set](/versions/8.6.0/rules/lib/core/set) containing the unique elements of a given
 iterable, preserving iteration order.
 
 If called with no argument, `set()` returns a new empty set.
@@ -479,7 +479,7 @@ sorted(["two", "three", "four"], key = len) == ["two", "four", "three"]  # sort
 | --- | --- |
 | `iterable` | iterable; required  The iterable sequence to sort. |
 | `key` | callable; or `None`; default is `None`  An optional function applied to each element before comparison. |
-| `reverse` | [bool](../core/bool); default is `False`  Return results in descending order. |
+| `reverse` | [bool](/versions/8.6.0/rules/lib/core/bool); default is `False`  Return results in descending order. |
 
 ## str
 
diff --git a/versions/8.6.0/rules/lib/globals/build.mdx b/versions/8.6.0/rules/lib/globals/build.mdx
index 87687c6e..07623c2e 100644
--- a/versions/8.6.0/rules/lib/globals/build.mdx
+++ b/versions/8.6.0/rules/lib/globals/build.mdx
@@ -2,7 +2,7 @@
 title: 'BUILD files'
 ---
 
-Methods available in BUILD files. See also the Build Encyclopedia for extra [functions](/reference/be/functions) and build rules, which can also be used in BUILD files.
+Methods available in BUILD files. See also the Build Encyclopedia for extra [functions](/versions/8.6.0/reference/be/functions) and build rules, which can also be used in BUILD files.
 
 ## Members
 
@@ -28,7 +28,7 @@ Methods available in BUILD files. See also the Build Encyclopedia for extra [fun
 depset depset(direct=None, order="default", *, transitive=None)
 ```
 
-Creates a [depset](../builtins/depset). The `direct` parameter is a list of direct elements of the depset, and `transitive` parameter is a list of depsets whose elements become indirect elements of the created depset. The order in which elements are returned when the depset is converted to a list is specified by the `order` parameter. See the [Depsets overview](https://bazel.build/extending/depsets) for more information.
+Creates a [depset](/versions/8.6.0/rules/lib/builtins/depset). The `direct` parameter is a list of direct elements of the depset, and `transitive` parameter is a list of depsets whose elements become indirect elements of the created depset. The order in which elements are returned when the depset is converted to a list is specified by the `order` parameter. See the [Depsets overview](https://bazel.build/versions/8.6.0/extending/depsets) for more information.
 
 All elements (direct and indirect) of a depset must be of the same type, as obtained by the expression `type(x)`.
 
@@ -42,9 +42,9 @@ The order of the created depset should be *compatible* with the order of its `tr
 
 | Parameter | Description |
 | --- | --- |
-| `direct` | [sequence](../core/list); or `None`; default is `None`  A list of *direct* elements of a depset. |
-| `order` | [string](../core/string); default is `"default"`  The traversal strategy for the new depset. See [here](../builtins/depset) for the possible values. |
-| `transitive` | [sequence](../core/list) of [depset](../builtins/depset)s; or `None`; default is `None`  A list of depsets whose elements will become indirect elements of the depset. |
+| `direct` | [sequence](/versions/8.6.0/rules/lib/core/list); or `None`; default is `None`  A list of *direct* elements of a depset. |
+| `order` | [string](/versions/8.6.0/rules/lib/core/string); default is `"default"`  The traversal strategy for the new depset. See [here](/versions/8.6.0/rules/lib/builtins/depset) for the possible values. |
+| `transitive` | [sequence](/versions/8.6.0/rules/lib/core/list) of [depset](/versions/8.6.0/rules/lib/builtins/depset)s; or `None`; default is `None`  A list of depsets whose elements will become indirect elements of the depset. |
 
 ## existing_rule
 
@@ -72,7 +72,7 @@ If possible, avoid using this function. It makes BUILD files brittle and order-d
 
 | Parameter | Description |
 | --- | --- |
-| `name` | [string](../core/string); required  The name of the target. |
+| `name` | [string](/versions/8.6.0/rules/lib/core/string); required  The name of the target. |
 
 ## existing_rules
 
@@ -98,9 +98,9 @@ Specifies a list of files belonging to this package that are exported to other p
 
 | Parameter | Description |
 | --- | --- |
-| `srcs` | [sequence](../core/list) of [string](../core/string)s; required  The list of files to export. |
-| `visibility` | [sequence](../core/list); or `None`; default is `None`  A visibility declaration can to be specified. The files will be visible to the targets specified. If no visibility is specified, the files will be visible to every package. |
-| `licenses` | [sequence](../core/list) of [string](../core/string)s; or `None`; default is `None`  Licenses to be specified. |
+| `srcs` | [sequence](/versions/8.6.0/rules/lib/core/list) of [string](/versions/8.6.0/rules/lib/core/string)s; required  The list of files to export. |
+| `visibility` | [sequence](/versions/8.6.0/rules/lib/core/list); or `None`; default is `None`  A visibility declaration can to be specified. The files will be visible to the targets specified. If no visibility is specified, the files will be visible to every package. |
+| `licenses` | [sequence](/versions/8.6.0/rules/lib/core/list) of [string](/versions/8.6.0/rules/lib/core/string)s; or `None`; default is `None`  Licenses to be specified. |
 
 ## glob
 
@@ -119,9 +119,9 @@ If the `exclude_directories` argument is enabled (set to `1`), files of type dir
 
 | Parameter | Description |
 | --- | --- |
-| `include` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  The list of glob patterns to include. |
-| `exclude` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  The list of glob patterns to exclude. |
-| `exclude_directories` | [int](../core/int); default is `1`  A flag whether to exclude directories or not. |
+| `include` | [sequence](/versions/8.6.0/rules/lib/core/list) of [string](/versions/8.6.0/rules/lib/core/string)s; default is `[]`  The list of glob patterns to include. |
+| `exclude` | [sequence](/versions/8.6.0/rules/lib/core/list) of [string](/versions/8.6.0/rules/lib/core/string)s; default is `[]`  The list of glob patterns to exclude. |
+| `exclude_directories` | [int](/versions/8.6.0/rules/lib/core/int); default is `1`  A flag whether to exclude directories or not. |
 | `allow_empty` | default is `unbound`  Whether we allow glob patterns to match nothing. If `allow_empty` is False, each individual include pattern must match something and also the final result must be non-empty (after the matches of the `exclude` patterns are excluded). |
 
 ## module_name
@@ -154,7 +154,7 @@ Declares metadata that applies to every rule in the package. It must be called a
 
 | Parameter | Description |
 | --- | --- |
-| `kwargs` | required  See the [`package()`](/reference/be/functions#package) function in the Build Encyclopedia for applicable arguments. |
+| `kwargs` | required  See the [`package()`](/versions/8.6.0/reference/be/functions#package) function in the Build Encyclopedia for applicable arguments. |
 
 ## package_group
 
@@ -168,9 +168,9 @@ This function defines a set of packages and assigns a label to the group. The la
 
 | Parameter | Description |
 | --- | --- |
-| `name` | [string](../core/string); required  The unique name for this rule. |
-| `packages` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  A complete enumeration of packages in this group. |
-| `includes` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  Other package groups that are included in this one. |
+| `name` | [string](/versions/8.6.0/rules/lib/core/string); required  The unique name for this rule. |
+| `packages` | [sequence](/versions/8.6.0/rules/lib/core/list) of [string](/versions/8.6.0/rules/lib/core/string)s; default is `[]`  A complete enumeration of packages in this group. |
+| `includes` | [sequence](/versions/8.6.0/rules/lib/core/list) of [string](/versions/8.6.0/rules/lib/core/string)s; default is `[]`  Other package groups that are included in this one. |
 
 ## package_name
 
@@ -186,19 +186,19 @@ The name of the package being evaluated, without the repository name. For exampl
 Label package_relative_label(input)
 ```
 
-Converts the input string into a [Label](../builtins/Label) object, in the context of the package currently being initialized (that is, the `BUILD` file for which the current macro is executing). If the input is already a `Label`, it is returned unchanged.
+Converts the input string into a [Label](/versions/8.6.0/rules/lib/builtins/Label) object, in the context of the package currently being initialized (that is, the `BUILD` file for which the current macro is executing). If the input is already a `Label`, it is returned unchanged.
 
 This function may only be called while evaluating a BUILD file and the macros it directly or indirectly calls; it may not be called in (for instance) a rule implementation function.
 
 The result of this function is the same `Label` value as would be produced by passing the given string to a label-valued attribute of a target declared in the BUILD file.
 
-*Usage note:* The difference between this function and [Label()](../builtins/Label#Label) is that `Label()` uses the context of the package of the `.bzl` file that called it, not the package of the `BUILD` file. Use `Label()` when you need to refer to a fixed target that is hardcoded into the macro, such as a compiler. Use `package_relative_label()` when you need to normalize a label string supplied by the BUILD file to a `Label` object. (There is no way to convert a string to a `Label` in the context of a package other than the BUILD file or the calling .bzl file. For that reason, outer macros should always prefer to pass Label objects to inner macros rather than label strings.)
+*Usage note:* The difference between this function and [Label()](/versions/8.6.0/rules/lib/builtins/Label#Label) is that `Label()` uses the context of the package of the `.bzl` file that called it, not the package of the `BUILD` file. Use `Label()` when you need to refer to a fixed target that is hardcoded into the macro, such as a compiler. Use `package_relative_label()` when you need to normalize a label string supplied by the BUILD file to a `Label` object. (There is no way to convert a string to a `Label` in the context of a package other than the BUILD file or the calling .bzl file. For that reason, outer macros should always prefer to pass Label objects to inner macros rather than label strings.)
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `input` | [string](../core/string); or [Label](../builtins/Label); required  The input label string or Label object. If a Label object is passed, it's returned as is. |
+| `input` | [string](/versions/8.6.0/rules/lib/core/string); or [Label](/versions/8.6.0/rules/lib/builtins/Label); required  The input label string or Label object. If a Label object is passed, it's returned as is. |
 
 ## repo_name
 
@@ -225,14 +225,14 @@ The canonical name of the repository containing the package currently being eval
 unknown select(x, no_match_error='')
 ```
 
-`select()` is the helper function that makes a rule attribute [configurable](/reference/be/common-definitions#configurable-attributes). See [build encyclopedia](/reference/be/functions#select) for details.
+`select()` is the helper function that makes a rule attribute [configurable](/versions/8.6.0/reference/be/common-definitions#configurable-attributes). See [build encyclopedia](/versions/8.6.0/reference/be/functions#select) for details.
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `x` | [dict](../core/dict); required |
-| `no_match_error` | [string](../core/string); default is `''`  Optional custom error to report if no condition matches. |
+| `x` | [dict](/versions/8.6.0/rules/lib/core/dict); required |
+| `no_match_error` | [string](/versions/8.6.0/rules/lib/core/string); default is `''`  Optional custom error to report if no condition matches. |
 
 ## subpackages
 
@@ -246,6 +246,6 @@ Returns a new mutable list of every direct subpackage of the current package, re
 
 | Parameter | Description |
 | --- | --- |
-| `include` | [sequence](../core/list) of [string](../core/string)s; required  The list of glob patterns to include in subpackages scan. |
-| `exclude` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  The list of glob patterns to exclude from subpackages scan. |
-| `allow_empty` | [bool](../core/bool); default is `False`  Whether we fail if the call returns an empty list. By default empty list indicates potential error in BUILD file where the call to subpackages() is superflous. Setting to true allows this function to succeed in that case. |*
\ No newline at end of file
+| `include` | [sequence](/versions/8.6.0/rules/lib/core/list) of [string](/versions/8.6.0/rules/lib/core/string)s; required  The list of glob patterns to include in subpackages scan. |
+| `exclude` | [sequence](/versions/8.6.0/rules/lib/core/list) of [string](/versions/8.6.0/rules/lib/core/string)s; default is `[]`  The list of glob patterns to exclude from subpackages scan. |
+| `allow_empty` | [bool](/versions/8.6.0/rules/lib/core/bool); default is `False`  Whether we fail if the call returns an empty list. By default empty list indicates potential error in BUILD file where the call to subpackages() is superflous. Setting to true allows this function to succeed in that case. |*
\ No newline at end of file
diff --git a/versions/8.6.0/rules/lib/globals/bzl.mdx b/versions/8.6.0/rules/lib/globals/bzl.mdx
index b81d5c8d..ff9995bb 100644
--- a/versions/8.6.0/rules/lib/globals/bzl.mdx
+++ b/versions/8.6.0/rules/lib/globals/bzl.mdx
@@ -28,15 +28,15 @@ Global methods available in all .bzl files.
 transition analysis_test_transition(settings)
 ```
 
-Creates a configuration transition to be applied on an analysis-test rule's dependencies. This transition may only be applied on attributes of rules with `analysis_test = True`. Such rules are restricted in capabilities (for example, the size of their dependency tree is limited), so transitions created using this function are limited in potential scope as compared to transitions created using [`transition()`](../builtins/transition).
+Creates a configuration transition to be applied on an analysis-test rule's dependencies. This transition may only be applied on attributes of rules with `analysis_test = True`. Such rules are restricted in capabilities (for example, the size of their dependency tree is limited), so transitions created using this function are limited in potential scope as compared to transitions created using [`transition()`](/versions/8.6.0/rules/lib/builtins/transition).
 
-This function is primarily designed to facilitate the [Analysis Test Framework](https://bazel.build/rules/testing) core library. See its documentation (or its implementation) for best practices.
+This function is primarily designed to facilitate the [Analysis Test Framework](https://bazel.build/versions/8.6.0/rules/testing) core library. See its documentation (or its implementation) for best practices.
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `settings` | [dict](../core/dict); required  A dictionary containing information about configuration settings which should be set by this configuration transition. Keys are build setting labels and values are their new post-transition values. All other settings are unchanged. Use this to declare specific configuration settings that an analysis test requires to be set in order to pass. |
+| `settings` | [dict](/versions/8.6.0/rules/lib/core/dict); required  A dictionary containing information about configuration settings which should be set by this configuration transition. Keys are build setting labels and values are their new post-transition values. All other settings are unchanged. Use this to declare specific configuration settings that an analysis test requires to be set in order to pass. |
 
 ## aspect
 
@@ -44,29 +44,29 @@ This function is primarily designed to facilitate the [Analysis Test Framework](
 Aspect aspect(implementation, attr_aspects=[], toolchains_aspects=[], attrs={}, required_providers=[], required_aspect_providers=[], provides=[], requires=[], fragments=[], host_fragments=[], toolchains=[], incompatible_use_toolchain_transition=False, doc=None, *, apply_to_generating_rules=False, exec_compatible_with=[], exec_groups=None, subrules=[])
 ```
 
-Creates a new aspect. The result of this function must be stored in a global value. Please see the [introduction to Aspects](https://bazel.build/rules/aspects) for more details.
+Creates a new aspect. The result of this function must be stored in a global value. Please see the [introduction to Aspects](https://bazel.build/versions/8.6.0/rules/aspects) for more details.
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `implementation` | [function](../core/function); required  A Starlark function that implements this aspect, with exactly two parameters: [Target](../builtins/Target) (the target to which the aspect is applied) and [ctx](../builtins/ctx) (the rule context which the target is created from). Attributes of the target are available via the `ctx.rule` field. This function is evaluated during the analysis phase for each application of an aspect to a target. |
-| `attr_aspects` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  List of attribute names. The aspect propagates along dependencies specified in the attributes of a target with these names. Common values here include `deps` and `exports`. The list can also contain a single string `"*"` to propagate along all dependencies of a target. |
-| `toolchains_aspects` | [sequence](../core/list); default is `[]`  List of toolchain types. The aspect propagates to target toolchains which match these toolchain types. |
-| `attrs` | [dict](../core/dict); default is `{}`  A dictionary declaring all the attributes of the aspect. It maps from an attribute name to an attribute object, like `attr.label` or `attr.string` (see [`attr`](../toplevel/attr) module). Aspect attributes are available to implementation function as fields of `ctx` parameter. Implicit attributes starting with `_` must have default values, and have type `label` or `label_list`.  Explicit attributes must have type `string`, and must use the `values` restriction. Explicit attributes restrict the aspect to only be used with rules that have attributes of the same name, type, and valid values according to the restriction.  Declared attributes will convert `None` to the default value. |
-| `required_providers` | [sequence](../core/list); default is `[]`  This attribute allows the aspect to limit its propagation to only the targets whose rules advertise its required providers. The value must be a list containing either individual providers or lists of providers but not both. For example, `[[FooInfo], [BarInfo], [BazInfo, QuxInfo]]` is a valid value while `[FooInfo, BarInfo, [BazInfo, QuxInfo]]` is not valid. An unnested list of providers will automatically be converted to a list containing one list of providers. That is, `[FooInfo, BarInfo]` will automatically be converted to `[[FooInfo, BarInfo]]`. To make some rule (e.g. `some_rule`) targets visible to an aspect, `some_rule` must advertise all providers from at least one of the required providers lists. For example, if the `required_providers` of an aspect are `[[FooInfo], [BarInfo], [BazInfo, QuxInfo]]`, this aspect can see `some_rule` targets if and only if `some_rule` provides `FooInfo`, *or* `BarInfo`, *or* both `BazInfo` *and* `QuxInfo`. |
-| `required_aspect_providers` | [sequence](../core/list); default is `[]`  This attribute allows this aspect to inspect other aspects. The value must be a list containing either individual providers or lists of providers but not both. For example, `[[FooInfo], [BarInfo], [BazInfo, QuxInfo]]` is a valid value while `[FooInfo, BarInfo, [BazInfo, QuxInfo]]` is not valid. An unnested list of providers will automatically be converted to a list containing one list of providers. That is, `[FooInfo, BarInfo]` will automatically be converted to `[[FooInfo, BarInfo]]`. To make another aspect (e.g. `other_aspect`) visible to this aspect, `other_aspect` must provide all providers from at least one of the lists. In the example of `[[FooInfo], [BarInfo], [BazInfo, QuxInfo]]`, this aspect can see `other_aspect` if and only if `other_aspect` provides `FooInfo`, *or* `BarInfo`, *or* both `BazInfo` *and* `QuxInfo`. |
-| `provides` | [sequence](../core/list); default is `[]`  A list of providers that the implementation function must return. It is an error if the implementation function omits any of the types of providers listed here from its return value. However, the implementation function may return additional providers not listed here. Each element of the list is an `*Info` object returned by [`provider()`](../globals/bzl#provider), except that a legacy provider is represented by its string name instead.When a target of the rule is used as a dependency for a target that declares a required provider, it is not necessary to specify that provider here. It is enough that the implementation function returns it. However, it is considered best practice to specify it, even though this is not required. The [`required_providers`](../globals/bzl#aspect.required_providers) field of an [aspect](../globals/bzl#aspect) does, however, require that providers are specified here. |
-| `requires` | [sequence](../core/list) of [Aspect](../builtins/Aspect)s; default is `[]`  List of aspects required to be propagated before this aspect. |
-| `fragments` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  List of names of configuration fragments that the aspect requires in target configuration. |
-| `host_fragments` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  List of names of configuration fragments that the aspect requires in host configuration. |
-| `toolchains` | [sequence](../core/list); default is `[]`  If set, the set of toolchains this aspect requires. The list can contain String, Label, or StarlarkToolchainTypeApi objects, in any combination. Toolchains will be found by checking the current platform, and provided to the aspect implementation via `ctx.toolchain`. |
-| `incompatible_use_toolchain_transition` | [bool](../core/bool); default is `False`  Deprecated, this is no longer in use and should be removed. |
-| `doc` | [string](../core/string); or `None`; default is `None`  A description of the aspect that can be extracted by documentation generating tools. |
-| `apply_to_generating_rules` | [bool](../core/bool); default is `False`  If true, the aspect will, when applied to an output file, instead apply to the output file's generating rule. For example, suppose an aspect propagates transitively through attribute `deps` and it is applied to target `alpha`. Suppose `alpha` has `deps = [':beta_output']`, where `beta_output` is a declared output of a target `beta`. Suppose `beta` has a target `charlie` as one of its `deps`. If `apply_to_generating_rules=True` for the aspect, then the aspect will propagate through `alpha`, `beta`, and `charlie`. If False, then the aspect will propagate only to `alpha`.  False by default. |
-| `exec_compatible_with` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  A list of constraints on the execution platform that apply to all instances of this aspect. |
-| `exec_groups` | [dict](../core/dict); or `None`; default is `None`  Dict of execution group name (string) to [`exec_group`s](../globals/bzl#exec_group). If set, allows aspects to run actions on multiple execution platforms within a single instance. See [execution groups documentation](/reference/exec-groups) for more info. |
-| `subrules` | [sequence](../core/list) of [Subrule](../builtins/Subrule)s; default is `[]`  Experimental: list of subrules used by this aspect. |
+| `implementation` | [function](/versions/8.6.0/rules/lib/core/function); required  A Starlark function that implements this aspect, with exactly two parameters: [Target](/versions/8.6.0/rules/lib/builtins/Target) (the target to which the aspect is applied) and [ctx](/versions/8.6.0/rules/lib/builtins/ctx) (the rule context which the target is created from). Attributes of the target are available via the `ctx.rule` field. This function is evaluated during the analysis phase for each application of an aspect to a target. |
+| `attr_aspects` | [sequence](/versions/8.6.0/rules/lib/core/list) of [string](/versions/8.6.0/rules/lib/core/string)s; default is `[]`  List of attribute names. The aspect propagates along dependencies specified in the attributes of a target with these names. Common values here include `deps` and `exports`. The list can also contain a single string `"*"` to propagate along all dependencies of a target. |
+| `toolchains_aspects` | [sequence](/versions/8.6.0/rules/lib/core/list); default is `[]`  List of toolchain types. The aspect propagates to target toolchains which match these toolchain types. |
+| `attrs` | [dict](/versions/8.6.0/rules/lib/core/dict); default is `{}`  A dictionary declaring all the attributes of the aspect. It maps from an attribute name to an attribute object, like `attr.label` or `attr.string` (see [`attr`](/versions/8.6.0/rules/lib/toplevel/attr) module). Aspect attributes are available to implementation function as fields of `ctx` parameter. Implicit attributes starting with `_` must have default values, and have type `label` or `label_list`.  Explicit attributes must have type `string`, and must use the `values` restriction. Explicit attributes restrict the aspect to only be used with rules that have attributes of the same name, type, and valid values according to the restriction.  Declared attributes will convert `None` to the default value. |
+| `required_providers` | [sequence](/versions/8.6.0/rules/lib/core/list); default is `[]`  This attribute allows the aspect to limit its propagation to only the targets whose rules advertise its required providers. The value must be a list containing either individual providers or lists of providers but not both. For example, `[[FooInfo], [BarInfo], [BazInfo, QuxInfo]]` is a valid value while `[FooInfo, BarInfo, [BazInfo, QuxInfo]]` is not valid. An unnested list of providers will automatically be converted to a list containing one list of providers. That is, `[FooInfo, BarInfo]` will automatically be converted to `[[FooInfo, BarInfo]]`. To make some rule (e.g. `some_rule`) targets visible to an aspect, `some_rule` must advertise all providers from at least one of the required providers lists. For example, if the `required_providers` of an aspect are `[[FooInfo], [BarInfo], [BazInfo, QuxInfo]]`, this aspect can see `some_rule` targets if and only if `some_rule` provides `FooInfo`, *or* `BarInfo`, *or* both `BazInfo` *and* `QuxInfo`. |
+| `required_aspect_providers` | [sequence](/versions/8.6.0/rules/lib/core/list); default is `[]`  This attribute allows this aspect to inspect other aspects. The value must be a list containing either individual providers or lists of providers but not both. For example, `[[FooInfo], [BarInfo], [BazInfo, QuxInfo]]` is a valid value while `[FooInfo, BarInfo, [BazInfo, QuxInfo]]` is not valid. An unnested list of providers will automatically be converted to a list containing one list of providers. That is, `[FooInfo, BarInfo]` will automatically be converted to `[[FooInfo, BarInfo]]`. To make another aspect (e.g. `other_aspect`) visible to this aspect, `other_aspect` must provide all providers from at least one of the lists. In the example of `[[FooInfo], [BarInfo], [BazInfo, QuxInfo]]`, this aspect can see `other_aspect` if and only if `other_aspect` provides `FooInfo`, *or* `BarInfo`, *or* both `BazInfo` *and* `QuxInfo`. |
+| `provides` | [sequence](/versions/8.6.0/rules/lib/core/list); default is `[]`  A list of providers that the implementation function must return. It is an error if the implementation function omits any of the types of providers listed here from its return value. However, the implementation function may return additional providers not listed here. Each element of the list is an `*Info` object returned by [`provider()`](/versions/8.6.0/rules/lib/globals/bzl#provider), except that a legacy provider is represented by its string name instead.When a target of the rule is used as a dependency for a target that declares a required provider, it is not necessary to specify that provider here. It is enough that the implementation function returns it. However, it is considered best practice to specify it, even though this is not required. The [`required_providers`](/versions/8.6.0/rules/lib/globals/bzl#aspect.required_providers) field of an [aspect](/versions/8.6.0/rules/lib/globals/bzl#aspect) does, however, require that providers are specified here. |
+| `requires` | [sequence](/versions/8.6.0/rules/lib/core/list) of [Aspect](/versions/8.6.0/rules/lib/builtins/Aspect)s; default is `[]`  List of aspects required to be propagated before this aspect. |
+| `fragments` | [sequence](/versions/8.6.0/rules/lib/core/list) of [string](/versions/8.6.0/rules/lib/core/string)s; default is `[]`  List of names of configuration fragments that the aspect requires in target configuration. |
+| `host_fragments` | [sequence](/versions/8.6.0/rules/lib/core/list) of [string](/versions/8.6.0/rules/lib/core/string)s; default is `[]`  List of names of configuration fragments that the aspect requires in host configuration. |
+| `toolchains` | [sequence](/versions/8.6.0/rules/lib/core/list); default is `[]`  If set, the set of toolchains this aspect requires. The list can contain String, Label, or StarlarkToolchainTypeApi objects, in any combination. Toolchains will be found by checking the current platform, and provided to the aspect implementation via `ctx.toolchain`. |
+| `incompatible_use_toolchain_transition` | [bool](/versions/8.6.0/rules/lib/core/bool); default is `False`  Deprecated, this is no longer in use and should be removed. |
+| `doc` | [string](/versions/8.6.0/rules/lib/core/string); or `None`; default is `None`  A description of the aspect that can be extracted by documentation generating tools. |
+| `apply_to_generating_rules` | [bool](/versions/8.6.0/rules/lib/core/bool); default is `False`  If true, the aspect will, when applied to an output file, instead apply to the output file's generating rule. For example, suppose an aspect propagates transitively through attribute `deps` and it is applied to target `alpha`. Suppose `alpha` has `deps = [':beta_output']`, where `beta_output` is a declared output of a target `beta`. Suppose `beta` has a target `charlie` as one of its `deps`. If `apply_to_generating_rules=True` for the aspect, then the aspect will propagate through `alpha`, `beta`, and `charlie`. If False, then the aspect will propagate only to `alpha`.  False by default. |
+| `exec_compatible_with` | [sequence](/versions/8.6.0/rules/lib/core/list) of [string](/versions/8.6.0/rules/lib/core/string)s; default is `[]`  A list of constraints on the execution platform that apply to all instances of this aspect. |
+| `exec_groups` | [dict](/versions/8.6.0/rules/lib/core/dict); or `None`; default is `None`  Dict of execution group name (string) to [`exec_group`s](/versions/8.6.0/rules/lib/globals/bzl#exec_group). If set, allows aspects to run actions on multiple execution platforms within a single instance. See [execution groups documentation](/versions/8.6.0/reference/exec-groups) for more info. |
+| `subrules` | [sequence](/versions/8.6.0/rules/lib/core/list) of [Subrule](/versions/8.6.0/rules/lib/builtins/Subrule)s; default is `[]`  Experimental: list of subrules used by this aspect. |
 
 ## configuration_field
 
@@ -74,7 +74,7 @@ Creates a new aspect. The result of this function must be stored in a global val
 LateBoundDefault configuration_field(fragment, name)
 ```
 
-References a late-bound default value for an attribute of type [label](../toplevel/attr#label). A value is 'late-bound' if it requires the configuration to be built before determining the value. Any attribute using this as a value must [be private](https://bazel.build/extending/rules#private-attributes).
+References a late-bound default value for an attribute of type [label](/versions/8.6.0/rules/lib/toplevel/attr#label). A value is 'late-bound' if it requires the configuration to be built before determining the value. Any attribute using this as a value must [be private](https://bazel.build/versions/8.6.0/extending/rules#private-attributes).
 
 Example usage:
 
@@ -96,8 +96,8 @@ Accessing in rule implementation:
 
 | Parameter | Description |
 | --- | --- |
-| `fragment` | [string](../core/string); required |
-| `name` | [string](../core/string); required |
+| `fragment` | [string](/versions/8.6.0/rules/lib/core/string); required |
+| `name` | [string](/versions/8.6.0/rules/lib/core/string); required |
 
 ## depset
 
@@ -105,7 +105,7 @@ Accessing in rule implementation:
 depset depset(direct=None, order="default", *, transitive=None)
 ```
 
-Creates a [depset](../builtins/depset). The `direct` parameter is a list of direct elements of the depset, and `transitive` parameter is a list of depsets whose elements become indirect elements of the created depset. The order in which elements are returned when the depset is converted to a list is specified by the `order` parameter. See the [Depsets overview](https://bazel.build/extending/depsets) for more information.
+Creates a [depset](/versions/8.6.0/rules/lib/builtins/depset). The `direct` parameter is a list of direct elements of the depset, and `transitive` parameter is a list of depsets whose elements become indirect elements of the created depset. The order in which elements are returned when the depset is converted to a list is specified by the `order` parameter. See the [Depsets overview](https://bazel.build/versions/8.6.0/extending/depsets) for more information.
 
 All elements (direct and indirect) of a depset must be of the same type, as obtained by the expression `type(x)`.
 
@@ -119,9 +119,9 @@ The order of the created depset should be *compatible* with the order of its `tr
 
 | Parameter | Description |
 | --- | --- |
-| `direct` | [sequence](../core/list); or `None`; default is `None`  A list of *direct* elements of a depset. |
-| `order` | [string](../core/string); default is `"default"`  The traversal strategy for the new depset. See [here](../builtins/depset) for the possible values. |
-| `transitive` | [sequence](../core/list) of [depset](../builtins/depset)s; or `None`; default is `None`  A list of depsets whose elements will become indirect elements of the depset. |
+| `direct` | [sequence](/versions/8.6.0/rules/lib/core/list); or `None`; default is `None`  A list of *direct* elements of a depset. |
+| `order` | [string](/versions/8.6.0/rules/lib/core/string); default is `"default"`  The traversal strategy for the new depset. See [here](/versions/8.6.0/rules/lib/builtins/depset) for the possible values. |
+| `transitive` | [sequence](/versions/8.6.0/rules/lib/core/list) of [depset](/versions/8.6.0/rules/lib/builtins/depset)s; or `None`; default is `None`  A list of depsets whose elements will become indirect elements of the depset. |
 
 ## exec_group
 
@@ -129,14 +129,14 @@ The order of the created depset should be *compatible* with the order of its `tr
 exec_group exec_group(toolchains=[], exec_compatible_with=[])
 ```
 
-Creates an [execution group](/reference/exec-groups) which can be used to create actions for a specific execution platform during rule implementation.
+Creates an [execution group](/versions/8.6.0/reference/exec-groups) which can be used to create actions for a specific execution platform during rule implementation.
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `toolchains` | [sequence](../core/list); default is `[]`  The set of toolchains this execution group requires. The list can contain String, Label, or StarlarkToolchainTypeApi objects, in any combination. |
-| `exec_compatible_with` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  A list of constraints on the execution platform. |
+| `toolchains` | [sequence](/versions/8.6.0/rules/lib/core/list); default is `[]`  The set of toolchains this execution group requires. The list can contain String, Label, or StarlarkToolchainTypeApi objects, in any combination. |
+| `exec_compatible_with` | [sequence](/versions/8.6.0/rules/lib/core/list) of [string](/versions/8.6.0/rules/lib/core/string)s; default is `[]`  A list of constraints on the execution platform. |
 
 ## exec_transition
 
@@ -144,15 +144,15 @@ Creates an [execution group](/reference/exec-groups) which can be used to create
 transition exec_transition(implementation, inputs, outputs)
 ```
 
-A specialized version of [`transition()`](../builtins/transition) used to define the exec transition. See its documentation (or its implementation) for best practices. Only usable from the Bazel builtins.
+A specialized version of [`transition()`](/versions/8.6.0/rules/lib/builtins/transition) used to define the exec transition. See its documentation (or its implementation) for best practices. Only usable from the Bazel builtins.
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
 | `implementation` | callable; required |
-| `inputs` | [sequence](../core/list) of [string](../core/string)s; required |
-| `outputs` | [sequence](../core/list) of [string](../core/string)s; required |
+| `inputs` | [sequence](/versions/8.6.0/rules/lib/core/list) of [string](/versions/8.6.0/rules/lib/core/string)s; required |
+| `outputs` | [sequence](/versions/8.6.0/rules/lib/core/list) of [string](/versions/8.6.0/rules/lib/core/string)s; required |
 
 ## macro
 
@@ -166,18 +166,18 @@ symbolic) to define targets – possibly multiple ones.
 The value returned by `macro(...)` must be assigned to a global variable in a .bzl
 file; the name of the global variable will be the macro symbol's name.
 
-See [Macros](/extending/macros) for a comprehensive guide on how to use symbolic
+See [Macros](/versions/8.6.0/extending/macros) for a comprehensive guide on how to use symbolic
 macros.
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `implementation` | [function](../core/function); required  The Starlark function implementing this macro. The values of the macro's attributes are passed to the implementation function as keyword arguments. The implementation function must have at least two named parameters, `name` and `visibility`, and if the macro inherits attributes (see `inherit_attrs` below), it must have a `**kwargs` residual keyword parameter. By convention, the implementation function should have a named parameter for any attribute that the macro needs to examine, modify, or pass to non-"main" targets, while the "bulk" inherited attributes which will be passed to the "main" target unchanged are passed as `**kwargs`. The implementation function must not return a value. Instead, the implementation function *declares targets* by calling rule or macro symbols. The name of any target or inner symbolic macro declared by a symbolic macro (including by any Starlark function that the macro's implementation function transitively calls) must either equal `name` (this is referred to as the "main" target) or start with `name`, followed by a separator chracter (`"_"`, `"-"`, or `"."`) and a string suffix. (Targets violating this naming scheme are allowed to be declared, but cannot be built, configured, or depended upon.) By default, targets declared by a symbolic macro (including by any Starlark function that the macro's implementation function transitively calls) are visible only in the package containing the .bzl file defining the macro. To declare targets visible externally, *including to the caller of the symbolic macro*, the implementation function must set `visibility` appropriately – typically, by passing `visibility = visibility` to the rule or macro symbol being called. The following APIs are unavailable within a macro implementation function and any Starlark function it transitively calls:  * [`package()`, `licenses()`* `environment_group()`* [`native.glob()`](../toplevel/native#glob) – instead, you may pass       a glob into the macro via a label list attribute* [`native.subpackages()`](../toplevel/native#subpackages)* (allowed in rule finalizers only, see `finalizer` below) [`native.existing_rules()`](../toplevel/native#existing_rules), [`native.existing_rule()`](../toplevel/native#existing_rule)* (for `WORKSPACE` threads) [`workspace()`](../globals/workspace#workspace), [`register_toolchains()`](../globals/workspace#register_toolchains), [`bind()`](../globals/workspace#bind), [`register_execution_platforms()`](../globals/workspace#register_execution_platforms), [repository rule instantiation](/reference/be/functions#package) |
-| `attrs` | [dict](../core/dict); default is `{}`  A dictionary of the attributes this macro supports, analogous to [rule.attrs](#rule.attrs). Keys are attribute names, and values are either attribute objects like `attr.label_list(...)` (see the [attr](../toplevel/attr) module), or `None`. A `None` entry means that the macro does not have an attribute by that name, even if it would have otherwise inherited one via `inherit_attrs` (see below). The special `name` attribute is predeclared and must not be included in the dictionary. The `visibility` attribute name is reserved and must not be included in the dictionary. Attributes whose names start with `_` are private -- they cannot be passed at the call site of the rule. Such attributes can be assigned a default value (as in `attr.label(default="//pkg:foo")`) to create an implicit dependency on a label. To limit memory usage, there is a cap on the number of attributes that may be declared. |
-| `inherit_attrs` | [rule](../builtins/rule); or [macro](../builtins/macro); or [string](../core/string); or `None`; default is `None`  A rule symbol, macro symbol, or the name of a built-in common attribute list (see below) from which the macro should inherit attributes. If `inherit_attrs` is set to the string `"common"`, the macro will inherit [common rule attribute definitions](/reference/be/common-definitions#common-attributes) used by all Starlark rules. Note that if the return value of `rule()` or `macro()` was not assigned to a global variable in a .bzl file, then such a value has not been registered as a rule or macro symbol, and therefore cannot be used for `inherit_attrs`. The inheritance mechanism works as follows:   1. The special `name` and `visibility` attributes are never inherited;- Hidden attributes (ones whose name starts with `"_"`) are never inherited;- Attributes whose names are already defined in the `attrs` dictionary are never        inherited (the entry in `attrs` takes precedence; note that an entry may be set to        `None` to ensure that no attribute by that name gets defined on the macro);- All other attributes are inherited from the rule or macro and effectively merged into the          `attrs` dict.   When a non-mandatory attribute is inherited, the default value of the attribute is overridden to be `None`, regardless of what it was specified in the original rule or macro. This ensures that when the macro forwards the attribute's value to an instance of the wrapped rule or macro – such as by passing in the unmodified `**kwargs` – a value that was absent from the outer macro's call will also be absent in the inner rule or macro's call (since passing `None` to an attribute is treated the same as omitting the attribute). This is important because omitting an attribute has subtly different semantics from passing its apparent default value. In particular, omitted attributes are not shown in some `bazel query` output formats, and computed defaults only execute when the value is omitted. If the macro needs to examine or modify an inherited attribute – for example, to add a value to an inherited `tags` attribute – you must make sure to handle the `None` case in the macro's implementation function. For example, the following macro inherits all attributes from `native.cc_library`, except for `cxxopts` (which is removed from the attribute list) and `copts` (which is given a new definition). It also takes care to checks for the default `None` value of the inherited `tags` attribute before appending an additional tag.  ``` def _my_cc_library_impl(name, visibility, tags, **kwargs):     # Append a tag; tags attr was inherited from native.cc_library, and     # therefore is None unless explicitly set by the caller of my_cc_library()     my_tags = (tags or []) + ["my_custom_tag"]     native.cc_library(         name = name,         visibility = visibility,         tags = my_tags,         **kwargs     )  my_cc_library = macro(     implementation = _my_cc_library_impl,     inherit_attrs = native.cc_library,     attrs = {         "cxxopts": None,         "copts": attr.string_list(default = ["-D_FOO"]),     }, ) ```   If `inherit_attrs` is set, the macro's implementation function *must* have a `**kwargs` residual keyword parameter. By convention, a macro should pass inherited, non-overridden attributes unchanged to the "main" rule or macro symbol which the macro is wrapping. Typically, most inherited attributes will not have a parameter in the implementation function's parameter list, and will simply be passed via `**kwargs`. It can be convenient for the implementation function to have explicit parameters for some inherited attributes (most commonly, `tags` and `testonly`) if the macro needs to pass those attributes to both "main" and non-"main" targets – but if the macro also needs to examine or manipulate those attributes, you must take care to handle the `None` default value of non-mandatory inherited attributes. |
-| `finalizer` | [bool](../core/bool); default is `False`  Whether this macro is a rule finalizer, which is a macro that, regardless of its position in a `BUILD` file, is evaluated at the end of package loading, after all non-finalizer targets have been defined. Unlike ordinary symbolic macros, rule finalizers may call [`native.existing_rule()`](../toplevel/native#existing_rule) and [`native.existing_rules()`](../toplevel/native#existing_rules) to query the set of *non-finalizer* rule targets defined in the current package. Note that `native.existing_rule()` and `native.existing_rules()` cannot access the targets defined by any rule finalizer, including this one. |
-| `doc` | [string](../core/string); or `None`; default is `None`  A description of the macro that can be extracted by documentation generating tools. |
+| `implementation` | [function](/versions/8.6.0/rules/lib/core/function); required  The Starlark function implementing this macro. The values of the macro's attributes are passed to the implementation function as keyword arguments. The implementation function must have at least two named parameters, `name` and `visibility`, and if the macro inherits attributes (see `inherit_attrs` below), it must have a `**kwargs` residual keyword parameter. By convention, the implementation function should have a named parameter for any attribute that the macro needs to examine, modify, or pass to non-"main" targets, while the "bulk" inherited attributes which will be passed to the "main" target unchanged are passed as `**kwargs`. The implementation function must not return a value. Instead, the implementation function *declares targets* by calling rule or macro symbols. The name of any target or inner symbolic macro declared by a symbolic macro (including by any Starlark function that the macro's implementation function transitively calls) must either equal `name` (this is referred to as the "main" target) or start with `name`, followed by a separator chracter (`"_"`, `"-"`, or `"."`) and a string suffix. (Targets violating this naming scheme are allowed to be declared, but cannot be built, configured, or depended upon.) By default, targets declared by a symbolic macro (including by any Starlark function that the macro's implementation function transitively calls) are visible only in the package containing the .bzl file defining the macro. To declare targets visible externally, *including to the caller of the symbolic macro*, the implementation function must set `visibility` appropriately – typically, by passing `visibility = visibility` to the rule or macro symbol being called. The following APIs are unavailable within a macro implementation function and any Starlark function it transitively calls:  * [`package()`, `licenses()`* `environment_group()`* [`native.glob()`](/versions/8.6.0/rules/lib/toplevel/native#glob) – instead, you may pass       a glob into the macro via a label list attribute* [`native.subpackages()`](/versions/8.6.0/rules/lib/toplevel/native#subpackages)* (allowed in rule finalizers only, see `finalizer` below) [`native.existing_rules()`](/versions/8.6.0/rules/lib/toplevel/native#existing_rules), [`native.existing_rule()`](/versions/8.6.0/rules/lib/toplevel/native#existing_rule)* (for `WORKSPACE` threads) [`workspace()`](/versions/8.6.0/rules/lib/globals/workspace#workspace), [`register_toolchains()`](/versions/8.6.0/rules/lib/globals/workspace#register_toolchains), [`bind()`](/versions/8.6.0/rules/lib/globals/workspace#bind), [`register_execution_platforms()`](/versions/8.6.0/rules/lib/globals/workspace#register_execution_platforms), [repository rule instantiation](/versions/8.6.0/reference/be/functions#package) |
+| `attrs` | [dict](/versions/8.6.0/rules/lib/core/dict); default is `{}`  A dictionary of the attributes this macro supports, analogous to [rule.attrs](#rule.attrs). Keys are attribute names, and values are either attribute objects like `attr.label_list(...)` (see the [attr](/versions/8.6.0/rules/lib/toplevel/attr) module), or `None`. A `None` entry means that the macro does not have an attribute by that name, even if it would have otherwise inherited one via `inherit_attrs` (see below). The special `name` attribute is predeclared and must not be included in the dictionary. The `visibility` attribute name is reserved and must not be included in the dictionary. Attributes whose names start with `_` are private -- they cannot be passed at the call site of the rule. Such attributes can be assigned a default value (as in `attr.label(default="//pkg:foo")`) to create an implicit dependency on a label. To limit memory usage, there is a cap on the number of attributes that may be declared. |
+| `inherit_attrs` | [rule](/versions/8.6.0/rules/lib/builtins/rule); or [macro](/versions/8.6.0/rules/lib/builtins/macro); or [string](/versions/8.6.0/rules/lib/core/string); or `None`; default is `None`  A rule symbol, macro symbol, or the name of a built-in common attribute list (see below) from which the macro should inherit attributes. If `inherit_attrs` is set to the string `"common"`, the macro will inherit [common rule attribute definitions](/versions/8.6.0/reference/be/common-definitions#common-attributes) used by all Starlark rules. Note that if the return value of `rule()` or `macro()` was not assigned to a global variable in a .bzl file, then such a value has not been registered as a rule or macro symbol, and therefore cannot be used for `inherit_attrs`. The inheritance mechanism works as follows:   1. The special `name` and `visibility` attributes are never inherited;- Hidden attributes (ones whose name starts with `"_"`) are never inherited;- Attributes whose names are already defined in the `attrs` dictionary are never        inherited (the entry in `attrs` takes precedence; note that an entry may be set to        `None` to ensure that no attribute by that name gets defined on the macro);- All other attributes are inherited from the rule or macro and effectively merged into the          `attrs` dict.   When a non-mandatory attribute is inherited, the default value of the attribute is overridden to be `None`, regardless of what it was specified in the original rule or macro. This ensures that when the macro forwards the attribute's value to an instance of the wrapped rule or macro – such as by passing in the unmodified `**kwargs` – a value that was absent from the outer macro's call will also be absent in the inner rule or macro's call (since passing `None` to an attribute is treated the same as omitting the attribute). This is important because omitting an attribute has subtly different semantics from passing its apparent default value. In particular, omitted attributes are not shown in some `bazel query` output formats, and computed defaults only execute when the value is omitted. If the macro needs to examine or modify an inherited attribute – for example, to add a value to an inherited `tags` attribute – you must make sure to handle the `None` case in the macro's implementation function. For example, the following macro inherits all attributes from `native.cc_library`, except for `cxxopts` (which is removed from the attribute list) and `copts` (which is given a new definition). It also takes care to checks for the default `None` value of the inherited `tags` attribute before appending an additional tag.  ``` def _my_cc_library_impl(name, visibility, tags, **kwargs):     # Append a tag; tags attr was inherited from native.cc_library, and     # therefore is None unless explicitly set by the caller of my_cc_library()     my_tags = (tags or []) + ["my_custom_tag"]     native.cc_library(         name = name,         visibility = visibility,         tags = my_tags,         **kwargs     )  my_cc_library = macro(     implementation = _my_cc_library_impl,     inherit_attrs = native.cc_library,     attrs = {         "cxxopts": None,         "copts": attr.string_list(default = ["-D_FOO"]),     }, ) ```   If `inherit_attrs` is set, the macro's implementation function *must* have a `**kwargs` residual keyword parameter. By convention, a macro should pass inherited, non-overridden attributes unchanged to the "main" rule or macro symbol which the macro is wrapping. Typically, most inherited attributes will not have a parameter in the implementation function's parameter list, and will simply be passed via `**kwargs`. It can be convenient for the implementation function to have explicit parameters for some inherited attributes (most commonly, `tags` and `testonly`) if the macro needs to pass those attributes to both "main" and non-"main" targets – but if the macro also needs to examine or manipulate those attributes, you must take care to handle the `None` default value of non-mandatory inherited attributes. |
+| `finalizer` | [bool](/versions/8.6.0/rules/lib/core/bool); default is `False`  Whether this macro is a rule finalizer, which is a macro that, regardless of its position in a `BUILD` file, is evaluated at the end of package loading, after all non-finalizer targets have been defined. Unlike ordinary symbolic macros, rule finalizers may call [`native.existing_rule()`](/versions/8.6.0/rules/lib/toplevel/native#existing_rule) and [`native.existing_rules()`](/versions/8.6.0/rules/lib/toplevel/native#existing_rules) to query the set of *non-finalizer* rule targets defined in the current package. Note that `native.existing_rule()` and `native.existing_rules()` cannot access the targets defined by any rule finalizer, including this one. |
+| `doc` | [string](/versions/8.6.0/rules/lib/core/string); or `None`; default is `None`  A description of the macro that can be extracted by documentation generating tools. |
 
 ## module_extension
 
@@ -192,11 +192,11 @@ Creates a new module extension. Store it in a global value, so that it can be ex
 | Parameter | Description |
 | --- | --- |
 | `implementation` | callable; required  The function that implements this module extension. Must take a single parameter, `module_ctx`. The function is called once at the beginning of a build to determine the set of available repos. |
-| `tag_classes` | [dict](../core/dict); default is `{}`  A dictionary to declare all the tag classes used by the extension. It maps from the name of the tag class to a `tag_class` object. |
-| `doc` | [string](../core/string); or `None`; default is `None`  A description of the module extension that can be extracted by documentation generating tools. |
-| `environ` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  **Deprecated**. This parameter has been deprecated. Migrate to `module_ctx.getenv` instead.  Provides a list of environment variable that this module extension depends on. If an environment variable in that list changes, the extension will be re-evaluated.  See also `--experimental_strict_repo_env`. |
-| `os_dependent` | [bool](../core/bool); default is `False`  Indicates whether this extension is OS-dependent or not |
-| `arch_dependent` | [bool](../core/bool); default is `False`  Indicates whether this extension is architecture-dependent or not |
+| `tag_classes` | [dict](/versions/8.6.0/rules/lib/core/dict); default is `{}`  A dictionary to declare all the tag classes used by the extension. It maps from the name of the tag class to a `tag_class` object. |
+| `doc` | [string](/versions/8.6.0/rules/lib/core/string); or `None`; default is `None`  A description of the module extension that can be extracted by documentation generating tools. |
+| `environ` | [sequence](/versions/8.6.0/rules/lib/core/list) of [string](/versions/8.6.0/rules/lib/core/string)s; default is `[]`  **Deprecated**. This parameter has been deprecated. Migrate to `module_ctx.getenv` instead.  Provides a list of environment variable that this module extension depends on. If an environment variable in that list changes, the extension will be re-evaluated.  See also `--experimental_strict_repo_env`. |
+| `os_dependent` | [bool](/versions/8.6.0/rules/lib/core/bool); default is `False`  Indicates whether this extension is OS-dependent or not |
+| `arch_dependent` | [bool](/versions/8.6.0/rules/lib/core/bool); default is `False`  Indicates whether this extension is architecture-dependent or not |
 
 ## provider
 
@@ -217,18 +217,18 @@ def _my_library_impl(ctx):
     ...
 ```
 
-See [Rules (Providers)](https://bazel.build/extending/rules#providers) for a comprehensive guide on how to use providers.
+See [Rules (Providers)](https://bazel.build/versions/8.6.0/extending/rules#providers) for a comprehensive guide on how to use providers.
 
-Returns a [`Provider`](../builtins/Provider) callable value if `init` is not specified.
+Returns a [`Provider`](/versions/8.6.0/rules/lib/builtins/Provider) callable value if `init` is not specified.
 
-If `init` is specified, returns a tuple of 2 elements: a [`Provider`](../builtins/Provider) callable value and a *raw constructor* callable value. See  [Rules (Custom initialization of custom providers)](https://bazel.build/extending/rules#custom_initialization_of_providers) and the discussion of the `init` parameter below for details.
+If `init` is specified, returns a tuple of 2 elements: a [`Provider`](/versions/8.6.0/rules/lib/builtins/Provider) callable value and a *raw constructor* callable value. See  [Rules (Custom initialization of custom providers)](https://bazel.build/versions/8.6.0/extending/rules#custom_initialization_of_providers) and the discussion of the `init` parameter below for details.
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `doc` | [string](../core/string); or `None`; default is `None` |
-| `fields` | [sequence](../core/list) of [string](../core/string)s; or [dict](../core/dict); or `None`; default is `None`  If specified, restricts the set of allowed fields.  Possible values are:  * list of fields:     ```   provider(fields = ['a', 'b'])   ```     * dictionary field name -> documentation:       ```     provider(            fields = { 'a' : 'Documentation for a', 'b' : 'Documentation for b' })     ```  All fields are optional. |
+| `doc` | [string](/versions/8.6.0/rules/lib/core/string); or `None`; default is `None` |
+| `fields` | [sequence](/versions/8.6.0/rules/lib/core/list) of [string](/versions/8.6.0/rules/lib/core/string)s; or [dict](/versions/8.6.0/rules/lib/core/dict); or `None`; default is `None`  If specified, restricts the set of allowed fields.  Possible values are:  * list of fields:     ```   provider(fields = ['a', 'b'])   ```     * dictionary field name -> documentation:       ```     provider(            fields = { 'a' : 'Documentation for a', 'b' : 'Documentation for b' })     ```  All fields are optional. |
 | `init` | callable; or `None`; default is `None` |
 
 ## repository_rule
@@ -237,19 +237,19 @@ If `init` is specified, returns a tuple of 2 elements: a [`Provider`](../builtin
 callable repository_rule(implementation, *, attrs=None, local=False, environ=[], configure=False, remotable=False, doc=None)
 ```
 
-Creates a new repository rule. Store it in a global value, so that it can be loaded and called from a [`module_extension()`](#module_extension) implementation function, or used by [`use_repo_rule()`](../globals/module#use_repo_rule).
+Creates a new repository rule. Store it in a global value, so that it can be loaded and called from a [`module_extension()`](#module_extension) implementation function, or used by [`use_repo_rule()`](/versions/8.6.0/rules/lib/globals/module#use_repo_rule).
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
 | `implementation` | callable; required |
-| `attrs` | [dict](../core/dict); or `None`; default is `None` |
-| `local` | [bool](../core/bool); default is `False`  Indicate that this rule fetches everything from the local system and should be reevaluated at every fetch. |
-| `environ` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  **Deprecated**. This parameter has been deprecated. Migrate to `repository_ctx.getenv` instead.  Provides a list of environment variable that this repository rule depends on. If an environment variable in that list change, the repository will be refetched.  See also `--experimental_strict_repo_env`. |
-| `configure` | [bool](../core/bool); default is `False`  Indicate that the repository inspects the system for configuration purpose |
-| `remotable` | [bool](../core/bool); default is `False`  **Experimental**. This parameter is experimental and may change at any time. Please do not depend on it. It may be enabled on an experimental basis by setting `--experimental_repo_remote_exec`  Compatible with remote execution |
-| `doc` | [string](../core/string); or `None`; default is `None` |
+| `attrs` | [dict](/versions/8.6.0/rules/lib/core/dict); or `None`; default is `None` |
+| `local` | [bool](/versions/8.6.0/rules/lib/core/bool); default is `False`  Indicate that this rule fetches everything from the local system and should be reevaluated at every fetch. |
+| `environ` | [sequence](/versions/8.6.0/rules/lib/core/list) of [string](/versions/8.6.0/rules/lib/core/string)s; default is `[]`  **Deprecated**. This parameter has been deprecated. Migrate to `repository_ctx.getenv` instead.  Provides a list of environment variable that this repository rule depends on. If an environment variable in that list change, the repository will be refetched.  See also `--experimental_strict_repo_env`. |
+| `configure` | [bool](/versions/8.6.0/rules/lib/core/bool); default is `False`  Indicate that the repository inspects the system for configuration purpose |
+| `remotable` | [bool](/versions/8.6.0/rules/lib/core/bool); default is `False`  **Experimental**. This parameter is experimental and may change at any time. Please do not depend on it. It may be enabled on an experimental basis by setting `--experimental_repo_remote_exec`  Compatible with remote execution |
+| `doc` | [string](/versions/8.6.0/rules/lib/core/string); or `None`; default is `None` |
 
 ## rule
 
@@ -267,29 +267,29 @@ Test rules are required to have a name ending in `_test`, while all other rules
 
 | Parameter | Description |
 | --- | --- |
-| `implementation` | [function](../core/function); required  the Starlark function implementing this rule, must have exactly one parameter: [ctx](../builtins/ctx). The function is called during the analysis phase for each instance of the rule. It can access the attributes provided by the user. It must create actions to generate all the declared outputs. |
-| `test` | [bool](../core/bool); default is `unbound`  Whether this rule is a test rule, that is, whether it may be the subject of a `blaze test` command. All test rules are automatically considered [executable](#rule.executable); it is unnecessary (and discouraged) to explicitly set `executable = True` for a test rule. The value defaults to `False`. See the  [Rules page](https://bazel.build/extending/rules#executable_rules_and_test_rules) for more information. |
-| `attrs` | [dict](../core/dict); default is `{}`  A dictionary to declare all the attributes of the rule. It maps from an attribute name to an attribute object (see [`attr`](../toplevel/attr) module). Attributes starting with `_` are private, and can be used to add an implicit dependency on a label. The attribute `name` is implicitly added and must not be specified. Attributes `visibility`, `deprecation`, `tags`, `testonly`, and `features` are implicitly added and cannot be overridden. Most rules need only a handful of attributes. To limit memory usage, there is a cap on the number of attributes that may be declared. Declared attributes will convert `None` to the default value. |
-| `outputs` | [dict](../core/dict); or `None`; or [function](../core/function); default is `None`  **Deprecated**. This parameter is deprecated and will be removed soon. Please do not depend on it. It is *disabled* with `--incompatible_no_rule_outputs_param`. Use this flag to verify your code is compatible with its imminent removal.  This parameter has been deprecated. Migrate rules to use `OutputGroupInfo` or `attr.output` instead. A schema for defining predeclared outputs. Unlike [`output`](../toplevel/attr#output) and [`output_list`](../toplevel/attr#output_list) attributes, the user does not specify the labels for these files. See the [Rules page](https://bazel.build/extending/rules#files) for more on predeclared outputs. The value of this argument is either a dictionary or a callback function that produces a dictionary. The callback works similar to computed dependency attributes: The function's parameter names are matched against the rule's attributes, so for example if you pass `outputs = _my_func` with the definition `def _my_func(srcs, deps): ...`, the function has access to the attributes `srcs` and `deps`. Whether the dictionary is specified directly or via a function, it is interpreted as follows. Each entry in the dictionary creates a predeclared output where the key is an identifier and the value is a string template that determines the output's label. In the rule's implementation function, the identifier becomes the field name used to access the output's [`File`](../builtins/File) in [`ctx.outputs`](../builtins/ctx#outputs). The output's label has the same package as the rule, and the part after the package is produced by substituting each placeholder of the form `"%{ATTR}"` with a string formed from the value of the attribute `ATTR`:  * String-typed attributes are substituted verbatim.* Label-typed attributes become the part of the label after the package, minus the file extension. For example, the label `"//pkg:a/b.c"` becomes `"a/b"`.* Output-typed attributes become the part of the label after the package, including the file extension (for the above example, `"a/b.c"`).* All list-typed attributes (for example, `attr.label_list`) used in placeholders are required to have *exactly one element*. Their conversion is the same as their non-list version (`attr.label`).* Other attribute types may not appear in placeholders.* The special non-attribute placeholders `%{dirname}` and `%{basename}` expand to those parts of the rule's label, excluding its package. For example, in `"//pkg:a/b.c"`, the dirname is `a` and the basename is `b.c`.   In practice, the most common substitution placeholder is `"%{name}"`. For example, for a target named "foo", the outputs dict `{"bin": "%{name}.exe"}` predeclares an output named `foo.exe` that is accessible in the implementation function as `ctx.outputs.bin`. |
-| `executable` | [bool](../core/bool); default is `unbound` |
-| `output_to_genfiles` | [bool](../core/bool); default is `False`  If true, the files will be generated in the genfiles directory instead of the bin directory. Unless you need it for compatibility with existing rules (e.g. when generating header files for C++), do not set this flag. |
-| `fragments` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  List of names of configuration fragments that the rule requires in target configuration. |
-| `host_fragments` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  List of names of configuration fragments that the rule requires in host configuration. |
-| `_skylark_testable` | [bool](../core/bool); default is `False`  *(Experimental)*  If true, this rule will expose its actions for inspection by rules that depend on it via an `Actions` provider. The provider is also available to the rule itself by calling [ctx.created_actions()](../builtins/ctx#created_actions).  This should only be used for testing the analysis-time behavior of Starlark rules. This flag may be removed in the future. |
-| `toolchains` | [sequence](../core/list); default is `[]`  If set, the set of toolchains this rule requires. The list can contain String, Label, or StarlarkToolchainTypeApi objects, in any combination. Toolchains will be found by checking the current platform, and provided to the rule implementation via `ctx.toolchain`. |
-| `incompatible_use_toolchain_transition` | [bool](../core/bool); default is `False`  Deprecated, this is no longer in use and should be removed. |
-| `doc` | [string](../core/string); or `None`; default is `None`  A description of the rule that can be extracted by documentation generating tools. |
-| `provides` | [sequence](../core/list); default is `[]`  A list of providers that the implementation function must return. It is an error if the implementation function omits any of the types of providers listed here from its return value. However, the implementation function may return additional providers not listed here. Each element of the list is an `*Info` object returned by [`provider()`](../globals/bzl#provider), except that a legacy provider is represented by its string name instead.When a target of the rule is used as a dependency for a target that declares a required provider, it is not necessary to specify that provider here. It is enough that the implementation function returns it. However, it is considered best practice to specify it, even though this is not required. The [`required_providers`](../globals/bzl#aspect.required_providers) field of an [aspect](../globals/bzl#aspect) does, however, require that providers are specified here. |
-| `dependency_resolution_rule` | [bool](../core/bool); default is `False`  If set, the rule can be a dependency through attributes also marked as available in materializers. Every attribute of rules with this flag set must be marked as available in materializers also. This is so that rules so marked cannot depend on rules that are not so marked. |
-| `exec_compatible_with` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  A list of constraints on the execution platform that apply to all targets of this rule type. |
-| `analysis_test` | [bool](../core/bool); default is `False`  If true, then this rule is treated as an analysis test. Note: Analysis test rules are primarily defined using infrastructure provided in core Starlark libraries. See [Testing](https://bazel.build/rules/testing#testing-rules) for guidance. If a rule is defined as an analysis test rule, it becomes allowed to use configuration transitions defined using [analysis_test_transition](#analysis_test_transition) on its attributes, but opts into some restrictions:  * Targets of this rule are limited in the number of transitive dependencies they may have.* The rule is considered a test rule (as if `test=True` were set). This supersedes the value of `test`   * The rule implementation function may not register actions. Instead, it must register a pass/fail result via providing [AnalysisTestResultInfo](../providers/AnalysisTestResultInfo). |
-| `build_setting` | [BuildSetting](../builtins/BuildSetting); or `None`; default is `None`  If set, describes what kind of [`build setting`](/rules/config#user-defined-build-settings) this rule is. See the [`config`](../toplevel/config) module. If this is set, a mandatory attribute named "build_setting_default" is automatically added to this rule, with a type corresponding to the value passed in here. |
+| `implementation` | [function](/versions/8.6.0/rules/lib/core/function); required  the Starlark function implementing this rule, must have exactly one parameter: [ctx](/versions/8.6.0/rules/lib/builtins/ctx). The function is called during the analysis phase for each instance of the rule. It can access the attributes provided by the user. It must create actions to generate all the declared outputs. |
+| `test` | [bool](/versions/8.6.0/rules/lib/core/bool); default is `unbound`  Whether this rule is a test rule, that is, whether it may be the subject of a `blaze test` command. All test rules are automatically considered [executable](#rule.executable); it is unnecessary (and discouraged) to explicitly set `executable = True` for a test rule. The value defaults to `False`. See the  [Rules page](https://bazel.build/versions/8.6.0/extending/rules#executable_rules_and_test_rules) for more information. |
+| `attrs` | [dict](/versions/8.6.0/rules/lib/core/dict); default is `{}`  A dictionary to declare all the attributes of the rule. It maps from an attribute name to an attribute object (see [`attr`](/versions/8.6.0/rules/lib/toplevel/attr) module). Attributes starting with `_` are private, and can be used to add an implicit dependency on a label. The attribute `name` is implicitly added and must not be specified. Attributes `visibility`, `deprecation`, `tags`, `testonly`, and `features` are implicitly added and cannot be overridden. Most rules need only a handful of attributes. To limit memory usage, there is a cap on the number of attributes that may be declared. Declared attributes will convert `None` to the default value. |
+| `outputs` | [dict](/versions/8.6.0/rules/lib/core/dict); or `None`; or [function](/versions/8.6.0/rules/lib/core/function); default is `None`  **Deprecated**. This parameter is deprecated and will be removed soon. Please do not depend on it. It is *disabled* with `--incompatible_no_rule_outputs_param`. Use this flag to verify your code is compatible with its imminent removal.  This parameter has been deprecated. Migrate rules to use `OutputGroupInfo` or `attr.output` instead. A schema for defining predeclared outputs. Unlike [`output`](/versions/8.6.0/rules/lib/toplevel/attr#output) and [`output_list`](/versions/8.6.0/rules/lib/toplevel/attr#output_list) attributes, the user does not specify the labels for these files. See the [Rules page](https://bazel.build/versions/8.6.0/extending/rules#files) for more on predeclared outputs. The value of this argument is either a dictionary or a callback function that produces a dictionary. The callback works similar to computed dependency attributes: The function's parameter names are matched against the rule's attributes, so for example if you pass `outputs = _my_func` with the definition `def _my_func(srcs, deps): ...`, the function has access to the attributes `srcs` and `deps`. Whether the dictionary is specified directly or via a function, it is interpreted as follows. Each entry in the dictionary creates a predeclared output where the key is an identifier and the value is a string template that determines the output's label. In the rule's implementation function, the identifier becomes the field name used to access the output's [`File`](/versions/8.6.0/rules/lib/builtins/File) in [`ctx.outputs`](/versions/8.6.0/rules/lib/builtins/ctx#outputs). The output's label has the same package as the rule, and the part after the package is produced by substituting each placeholder of the form `"%{ATTR}"` with a string formed from the value of the attribute `ATTR`:  * String-typed attributes are substituted verbatim.* Label-typed attributes become the part of the label after the package, minus the file extension. For example, the label `"//pkg:a/b.c"` becomes `"a/b"`.* Output-typed attributes become the part of the label after the package, including the file extension (for the above example, `"a/b.c"`).* All list-typed attributes (for example, `attr.label_list`) used in placeholders are required to have *exactly one element*. Their conversion is the same as their non-list version (`attr.label`).* Other attribute types may not appear in placeholders.* The special non-attribute placeholders `%{dirname}` and `%{basename}` expand to those parts of the rule's label, excluding its package. For example, in `"//pkg:a/b.c"`, the dirname is `a` and the basename is `b.c`.   In practice, the most common substitution placeholder is `"%{name}"`. For example, for a target named "foo", the outputs dict `{"bin": "%{name}.exe"}` predeclares an output named `foo.exe` that is accessible in the implementation function as `ctx.outputs.bin`. |
+| `executable` | [bool](/versions/8.6.0/rules/lib/core/bool); default is `unbound` |
+| `output_to_genfiles` | [bool](/versions/8.6.0/rules/lib/core/bool); default is `False`  If true, the files will be generated in the genfiles directory instead of the bin directory. Unless you need it for compatibility with existing rules (e.g. when generating header files for C++), do not set this flag. |
+| `fragments` | [sequence](/versions/8.6.0/rules/lib/core/list) of [string](/versions/8.6.0/rules/lib/core/string)s; default is `[]`  List of names of configuration fragments that the rule requires in target configuration. |
+| `host_fragments` | [sequence](/versions/8.6.0/rules/lib/core/list) of [string](/versions/8.6.0/rules/lib/core/string)s; default is `[]`  List of names of configuration fragments that the rule requires in host configuration. |
+| `_skylark_testable` | [bool](/versions/8.6.0/rules/lib/core/bool); default is `False`  *(Experimental)*  If true, this rule will expose its actions for inspection by rules that depend on it via an `Actions` provider. The provider is also available to the rule itself by calling [ctx.created_actions()](/versions/8.6.0/rules/lib/builtins/ctx#created_actions).  This should only be used for testing the analysis-time behavior of Starlark rules. This flag may be removed in the future. |
+| `toolchains` | [sequence](/versions/8.6.0/rules/lib/core/list); default is `[]`  If set, the set of toolchains this rule requires. The list can contain String, Label, or StarlarkToolchainTypeApi objects, in any combination. Toolchains will be found by checking the current platform, and provided to the rule implementation via `ctx.toolchain`. |
+| `incompatible_use_toolchain_transition` | [bool](/versions/8.6.0/rules/lib/core/bool); default is `False`  Deprecated, this is no longer in use and should be removed. |
+| `doc` | [string](/versions/8.6.0/rules/lib/core/string); or `None`; default is `None`  A description of the rule that can be extracted by documentation generating tools. |
+| `provides` | [sequence](/versions/8.6.0/rules/lib/core/list); default is `[]`  A list of providers that the implementation function must return. It is an error if the implementation function omits any of the types of providers listed here from its return value. However, the implementation function may return additional providers not listed here. Each element of the list is an `*Info` object returned by [`provider()`](/versions/8.6.0/rules/lib/globals/bzl#provider), except that a legacy provider is represented by its string name instead.When a target of the rule is used as a dependency for a target that declares a required provider, it is not necessary to specify that provider here. It is enough that the implementation function returns it. However, it is considered best practice to specify it, even though this is not required. The [`required_providers`](/versions/8.6.0/rules/lib/globals/bzl#aspect.required_providers) field of an [aspect](/versions/8.6.0/rules/lib/globals/bzl#aspect) does, however, require that providers are specified here. |
+| `dependency_resolution_rule` | [bool](/versions/8.6.0/rules/lib/core/bool); default is `False`  If set, the rule can be a dependency through attributes also marked as available in materializers. Every attribute of rules with this flag set must be marked as available in materializers also. This is so that rules so marked cannot depend on rules that are not so marked. |
+| `exec_compatible_with` | [sequence](/versions/8.6.0/rules/lib/core/list) of [string](/versions/8.6.0/rules/lib/core/string)s; default is `[]`  A list of constraints on the execution platform that apply to all targets of this rule type. |
+| `analysis_test` | [bool](/versions/8.6.0/rules/lib/core/bool); default is `False`  If true, then this rule is treated as an analysis test. Note: Analysis test rules are primarily defined using infrastructure provided in core Starlark libraries. See [Testing](https://bazel.build/versions/8.6.0/rules/testing#testing-rules) for guidance. If a rule is defined as an analysis test rule, it becomes allowed to use configuration transitions defined using [analysis_test_transition](#analysis_test_transition) on its attributes, but opts into some restrictions:  * Targets of this rule are limited in the number of transitive dependencies they may have.* The rule is considered a test rule (as if `test=True` were set). This supersedes the value of `test`   * The rule implementation function may not register actions. Instead, it must register a pass/fail result via providing [AnalysisTestResultInfo](/versions/8.6.0/rules/lib/providers/AnalysisTestResultInfo). |
+| `build_setting` | [BuildSetting](/versions/8.6.0/rules/lib/builtins/BuildSetting); or `None`; default is `None`  If set, describes what kind of [`build setting`](/versions/8.6.0/rules/config#user-defined-build-settings) this rule is. See the [`config`](/versions/8.6.0/rules/lib/toplevel/config) module. If this is set, a mandatory attribute named "build_setting_default" is automatically added to this rule, with a type corresponding to the value passed in here. |
 | `cfg` | default is `None`  If set, points to the configuration transition the rule will apply to its own configuration before analysis. |
-| `exec_groups` | [dict](../core/dict); or `None`; default is `None`  Dict of execution group name (string) to [`exec_group`s](../globals/bzl#exec_group). If set, allows rules to run actions on multiple execution platforms within a single target. See [execution groups documentation](/reference/exec-groups) for more info. |
+| `exec_groups` | [dict](/versions/8.6.0/rules/lib/core/dict); or `None`; default is `None`  Dict of execution group name (string) to [`exec_group`s](/versions/8.6.0/rules/lib/globals/bzl#exec_group). If set, allows rules to run actions on multiple execution platforms within a single target. See [execution groups documentation](/versions/8.6.0/reference/exec-groups) for more info. |
 | `initializer` | default is `None`  Experimental: the Stalark function initializing the attributes of the rule. The function is called at load time for each instance of the rule. It's called with `name` and the values of public attributes defined by the rule (not with generic attributes, for example `tags`). It has to return a dictionary from the attribute names to the desired values. The attributes that are not returned are unaffected. Returning `None` as value results in using the default value specified in the attribute definition. Initializers are evaluated before the default values specified in an attribute definition. Consequently, if a parameter in the initializer's signature contains a default values, it overwrites the default from the attribute definition (except if returning `None`). Similarly, if a parameter in the initializer's signature doesn't have a default, the parameter will become mandatory. It's a good practice to omit default/mandatory settings on an attribute definition in such cases. It's a good practice to use `**kwargs` for attributes that are not handled. In case of extended rules, all initializers are called proceeding from child to ancestors. Each initializer is passed only the public attributes it knows about. |
 | `parent` | default is `None`  Experimental: the Stalark rule that is extended. When set the public attributes are merged as well as advertised providers. The rule matches `executable` and `test` from the parent. Values of `fragments`, `toolchains`, `exec_compatible_with`, and `exec_groups` are merged. Legacy or deprecated parameters may not be set. Incoming configuration transition `cfg` of parent is applied after thisrule's incoming configuration. |
-| `extendable` | [bool](../core/bool); or [Label](../builtins/Label); or [string](../core/string); or `None`; default is `None`  Experimental: A label of an allowlist defining which rules can extending this rule. It can be set also to True/False to always allow/disallow extending. Bazel defaults to always allowing extensions. |
-| `subrules` | [sequence](../core/list) of [Subrule](../builtins/Subrule)s; default is `[]`  Experimental: List of subrules used by this rule. |
+| `extendable` | [bool](/versions/8.6.0/rules/lib/core/bool); or [Label](/versions/8.6.0/rules/lib/builtins/Label); or [string](/versions/8.6.0/rules/lib/core/string); or `None`; default is `None`  Experimental: A label of an allowlist defining which rules can extending this rule. It can be set also to True/False to always allow/disallow extending. Bazel defaults to always allowing extensions. |
+| `subrules` | [sequence](/versions/8.6.0/rules/lib/core/list) of [Subrule](/versions/8.6.0/rules/lib/builtins/Subrule)s; default is `[]`  Experimental: List of subrules used by this rule. |
 
 ## select
 
@@ -297,14 +297,14 @@ Test rules are required to have a name ending in `_test`, while all other rules
 unknown select(x, no_match_error='')
 ```
 
-`select()` is the helper function that makes a rule attribute [configurable](/reference/be/common-definitions#configurable-attributes). See [build encyclopedia](/reference/be/functions#select) for details.
+`select()` is the helper function that makes a rule attribute [configurable](/versions/8.6.0/reference/be/common-definitions#configurable-attributes). See [build encyclopedia](/versions/8.6.0/reference/be/functions#select) for details.
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `x` | [dict](../core/dict); required  A dict that maps configuration conditions to values. Each key is a [Label](../builtins/Label) or a label string that identifies a config_setting or constraint_value instance. See the [documentation on macros](https://bazel.build/extending/legacy-macros#label-resolution) for when to use a Label instead of a string. If `--incompatible_resolve_select_keys_eagerly` is enabled, the keys are resolved to `Label` objects relative to the package of the file that contains this call to `select`. |
-| `no_match_error` | [string](../core/string); default is `''`  Optional custom error to report if no condition matches. |
+| `x` | [dict](/versions/8.6.0/rules/lib/core/dict); required  A dict that maps configuration conditions to values. Each key is a [Label](/versions/8.6.0/rules/lib/builtins/Label) or a label string that identifies a config_setting or constraint_value instance. See the [documentation on macros](https://bazel.build/versions/8.6.0/extending/legacy-macros#label-resolution) for when to use a Label instead of a string. If `--incompatible_resolve_select_keys_eagerly` is enabled, the keys are resolved to `Label` objects relative to the package of the file that contains this call to `select`. |
+| `no_match_error` | [string](/versions/8.6.0/rules/lib/core/string); default is `''`  Optional custom error to report if no condition matches. |
 
 ## subrule
 
@@ -318,11 +318,11 @@ Constructs a new instance of a subrule. The result of this function must be stor
 
 | Parameter | Description |
 | --- | --- |
-| `implementation` | [function](../core/function); required  The Starlark function implementing this subrule |
-| `attrs` | [dict](../core/dict); default is `{}`  A dictionary to declare all the (private) attributes of the subrule.  Subrules may only have private attributes that are label-typed (i.e. label or label-list). The resolved values corresponding to these labels are automatically passed by Bazel to the subrule's implementation function as named arguments (thus the implementation function is required to accept named parameters matching the attribute names). The types of these values will be:  * `FilesToRunProvider` for label attributes with `executable=True` * `File` for label attributes with `allow_single_file=True` * `Target` for all other label attributes * `[Target]` for all label-list attributes |
-| `toolchains` | [sequence](../core/list); default is `[]`  If set, the set of toolchains this subrule requires. The list can contain String, Label, or StarlarkToolchainTypeApi objects, in any combination. Toolchains will be found by checking the current platform, and provided to the subrule implementation via `ctx.toolchains`. Note that AEGs need to be enabled on the consuming rule(s) if this parameter is set. In case you haven't migrated to AEGs yet, see https://bazel.build/extending/auto-exec-groups#migration-aegs. |
-| `fragments` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  List of names of configuration fragments that the subrule requires in target configuration. |
-| `subrules` | [sequence](../core/list) of [Subrule](../builtins/Subrule)s; default is `[]`  List of other subrules needed by this subrule. |
+| `implementation` | [function](/versions/8.6.0/rules/lib/core/function); required  The Starlark function implementing this subrule |
+| `attrs` | [dict](/versions/8.6.0/rules/lib/core/dict); default is `{}`  A dictionary to declare all the (private) attributes of the subrule.  Subrules may only have private attributes that are label-typed (i.e. label or label-list). The resolved values corresponding to these labels are automatically passed by Bazel to the subrule's implementation function as named arguments (thus the implementation function is required to accept named parameters matching the attribute names). The types of these values will be:  * `FilesToRunProvider` for label attributes with `executable=True` * `File` for label attributes with `allow_single_file=True` * `Target` for all other label attributes * `[Target]` for all label-list attributes |
+| `toolchains` | [sequence](/versions/8.6.0/rules/lib/core/list); default is `[]`  If set, the set of toolchains this subrule requires. The list can contain String, Label, or StarlarkToolchainTypeApi objects, in any combination. Toolchains will be found by checking the current platform, and provided to the subrule implementation via `ctx.toolchains`. Note that AEGs need to be enabled on the consuming rule(s) if this parameter is set. In case you haven't migrated to AEGs yet, see https://bazel.build/extending/auto-exec-groups#migration-aegs. |
+| `fragments` | [sequence](/versions/8.6.0/rules/lib/core/list) of [string](/versions/8.6.0/rules/lib/core/string)s; default is `[]`  List of names of configuration fragments that the subrule requires in target configuration. |
+| `subrules` | [sequence](/versions/8.6.0/rules/lib/core/list) of [Subrule](/versions/8.6.0/rules/lib/builtins/Subrule)s; default is `[]`  List of other subrules needed by this subrule. |
 
 ## tag_class
 
@@ -336,8 +336,8 @@ Creates a new tag_class object, which defines an attribute schema for a class of
 
 | Parameter | Description |
 | --- | --- |
-| `attrs` | [dict](../core/dict); default is `{}`  A dictionary to declare all the attributes of this tag class. It maps from an attribute name to an attribute object (see [attr](../toplevel/attr) module). Note that unlike [`rule()`](../globals/bzl#rule), [`aspect()`](../globals/bzl#aspect) and [`repository_rule()`](../globals/bzl#repository_rule), declared attributes will not convert `None` to the default value. For the default to be used, the attribute must be omitted entirely by the caller. |
-| `doc` | [string](../core/string); or `None`; default is `None`  A description of the tag class that can be extracted by documentation generating tools. |
+| `attrs` | [dict](/versions/8.6.0/rules/lib/core/dict); default is `{}`  A dictionary to declare all the attributes of this tag class. It maps from an attribute name to an attribute object (see [attr](/versions/8.6.0/rules/lib/toplevel/attr) module). Note that unlike [`rule()`](/versions/8.6.0/rules/lib/globals/bzl#rule), [`aspect()`](/versions/8.6.0/rules/lib/globals/bzl#aspect) and [`repository_rule()`](/versions/8.6.0/rules/lib/globals/bzl#repository_rule), declared attributes will not convert `None` to the default value. For the default to be used, the attribute must be omitted entirely by the caller. |
+| `doc` | [string](/versions/8.6.0/rules/lib/core/string); or `None`; default is `None`  A description of the tag class that can be extracted by documentation generating tools. |
 
 ## visibility
 
diff --git a/versions/8.6.0/rules/lib/globals/module.mdx b/versions/8.6.0/rules/lib/globals/module.mdx
index bbab2479..a4188ca2 100644
--- a/versions/8.6.0/rules/lib/globals/module.mdx
+++ b/versions/8.6.0/rules/lib/globals/module.mdx
@@ -31,7 +31,7 @@ None archive_override(module_name, **kwargs)
 
 Specifies that this dependency should come from an archive file (zip, gzip, etc) at a
 certain location, instead of from a registry. Effectively, this dependency will be
-backed by an [`http_archive`](../repo/http#http_archive) rule.
+backed by an [`http_archive`](/versions/8.6.0/rules/lib/repo/http#http_archive) rule.
 
 This directive only takes effect in the root module; in other words, if a module is
 used as a dependency by others, its own overrides are ignored.
@@ -40,7 +40,7 @@ used as a dependency by others, its own overrides are ignored.
 
 | Parameter | Description |
 | --- | --- |
-| `module_name` | [string](../core/string); required  The name of the Bazel module dependency to apply this override to. |
+| `module_name` | [string](/versions/8.6.0/rules/lib/core/string); required  The name of the Bazel module dependency to apply this override to. |
 | `kwargs` | required  All other arguments are forwarded to the underlying `http_archive` repo rule. Note that the `name` attribute shouldn't be specified; use `module_name` instead. |
 
 ## bazel_dep
@@ -55,11 +55,11 @@ Declares a direct dependency on another Bazel module.
 
 | Parameter | Description |
 | --- | --- |
-| `name` | [string](../core/string); required  The name of the module to be added as a direct dependency. |
-| `version` | [string](../core/string); default is `''`  The version of the module to be added as a direct dependency. |
-| `max_compatibility_level` | [int](../core/int); default is `-1`  Deprecated. This is now a no-op and has no effect. |
-| `repo_name` | [string](../core/string); or `None`; default is `''`  The name of the external repo representing this dependency. This is by default the name of the module. Can be set to `None` to make this dependency a "*nodep*" dependency: in this case, this `bazel_dep` specification is only honored if the target module already exists in the dependency graph by some other means. |
-| `dev_dependency` | [bool](../core/bool); default is `False`  If true, this dependency will be ignored if the current module is not the root module or `--ignore_dev_dependency` is enabled. |
+| `name` | [string](/versions/8.6.0/rules/lib/core/string); required  The name of the module to be added as a direct dependency. |
+| `version` | [string](/versions/8.6.0/rules/lib/core/string); default is `''`  The version of the module to be added as a direct dependency. |
+| `max_compatibility_level` | [int](/versions/8.6.0/rules/lib/core/int); default is `-1`  Deprecated. This is now a no-op and has no effect. |
+| `repo_name` | [string](/versions/8.6.0/rules/lib/core/string); or `None`; default is `''`  The name of the external repo representing this dependency. This is by default the name of the module. Can be set to `None` to make this dependency a "*nodep*" dependency: in this case, this `bazel_dep` specification is only honored if the target module already exists in the dependency graph by some other means. |
+| `dev_dependency` | [bool](/versions/8.6.0/rules/lib/core/bool); default is `False`  If true, this dependency will be ignored if the current module is not the root module or `--ignore_dev_dependency` is enabled. |
 
 ## flag_alias
 
@@ -73,8 +73,8 @@ No-op for pre-Bazel 9.0 backward compatibility. See Bazel 9.0 docs for real func
 
 | Parameter | Description |
 | --- | --- |
-| `name` | [string](../core/string); required  The name of the flag. |
-| `starlark_flag` | [string](../core/string); required  The label of the Starlark flag to alias to. |
+| `name` | [string](/versions/8.6.0/rules/lib/core/string); required  The name of the flag. |
+| `starlark_flag` | [string](/versions/8.6.0/rules/lib/core/string); required  The label of the Starlark flag to alias to. |
 
 ## git_override
 
@@ -84,7 +84,7 @@ None git_override(module_name, **kwargs)
 
 Specifies that this dependency should come from a certain commit in a Git repository,
 instead of from a registry. Effectively, this dependency will be backed by a
-[`git_repository`](../repo/git#git_repository) rule.
+[`git_repository`](/versions/8.6.0/rules/lib/repo/git#git_repository) rule.
 
 This directive only takes effect in the root module; in other words, if a module is
 used as a dependency by others, its own overrides are ignored.
@@ -93,7 +93,7 @@ used as a dependency by others, its own overrides are ignored.
 
 | Parameter | Description |
 | --- | --- |
-| `module_name` | [string](../core/string); required  The name of the Bazel module dependency to apply this override to. |
+| `module_name` | [string](/versions/8.6.0/rules/lib/core/string); required  The name of the Bazel module dependency to apply this override to. |
 | `kwargs` | required  All other arguments are forwarded to the underlying `git_repository` repo rule. Note that the `name` attribute shouldn't be specified; use `module_name` instead. |
 
 ## include
@@ -114,7 +114,7 @@ Only files in the current module's repo may be included.
 
 | Parameter | Description |
 | --- | --- |
-| `label` | [string](../core/string); required  The label pointing to the file to include. The label must point to a file in the main repo; in other words, it **must **start with double slashes (`//`). The name of the file must end with `.MODULE.bazel` and must not start with `.`.**** |
+| `label` | [string](/versions/8.6.0/rules/lib/core/string); required  The label pointing to the file to include. The label must point to a file in the main repo; in other words, it **must **start with double slashes (`//`). The name of the file must end with `.MODULE.bazel` and must not start with `.`.**** |
 
 ## inject_repo
 
@@ -154,8 +154,8 @@ used as a dependency by others, its own overrides are ignored.
 
 | Parameter | Description |
 | --- | --- |
-| `module_name` | [string](../core/string); required  The name of the Bazel module dependency to apply this override to. |
-| `path` | [string](../core/string); required  The path to the directory where this module is. |
+| `module_name` | [string](/versions/8.6.0/rules/lib/core/string); required  The name of the Bazel module dependency to apply this override to. |
+| `path` | [string](/versions/8.6.0/rules/lib/core/string); required  The path to the directory where this module is. |
 
 ## module
 
@@ -171,11 +171,11 @@ It should be called at most once, and if called, it must be the very first direc
 
 | Parameter | Description |
 | --- | --- |
-| `name` | [string](../core/string); default is `''`  The name of the module. Can be omitted only if this module is the root module (as in, if it's not going to be depended on by another module). A valid module name must: 1) only contain lowercase letters (a-z), digits (0-9), dots (.), hyphens (-), and underscores (\_); 2) begin with a lowercase letter; 3) end with a lowercase letter or digit. |
-| `version` | [string](../core/string); default is `''`  The version of the module. Can be omitted only if this module is the root module (as in, if it's not going to be depended on by another module). The version must be in a relaxed SemVer format; see [the documentation](/external/module#version_format) for more details. |
-| `compatibility_level` | [int](../core/int); default is `-1`  Deprecated. This is now a no-op and has no effect. |
-| `repo_name` | [string](../core/string); default is `''`  The name of the repository representing this module, as seen by the module itself. By default, the name of the repo is the name of the module. This can be specified to ease migration for projects that have been using a repo name for itself that differs from its module name. |
-| `bazel_compatibility` | Iterable of [string](../core/string)s; default is `[]`  A list of bazel versions that allows users to declare which Bazel versions are compatible with this module. It does NOT affect dependency resolution, but bzlmod will use this information to check if your current Bazel version is compatible. The format of this value is a string of some constraint values separated by comma. Three constraints are supported: <=X.X.X: The Bazel version must be equal or older than X.X.X. Used when there is a known incompatible change in a newer version. >=X.X.X: The Bazel version must be equal or newer than X.X.X.Used when you depend on some features that are only available since X.X.X. -X.X.X: The Bazel version X.X.X is not compatible. Used when there is a bug in X.X.X that breaks you, but fixed in later versions. |
+| `name` | [string](/versions/8.6.0/rules/lib/core/string); default is `''`  The name of the module. Can be omitted only if this module is the root module (as in, if it's not going to be depended on by another module). A valid module name must: 1) only contain lowercase letters (a-z), digits (0-9), dots (.), hyphens (-), and underscores (\_); 2) begin with a lowercase letter; 3) end with a lowercase letter or digit. |
+| `version` | [string](/versions/8.6.0/rules/lib/core/string); default is `''`  The version of the module. Can be omitted only if this module is the root module (as in, if it's not going to be depended on by another module). The version must be in a relaxed SemVer format; see [the documentation](/versions/8.6.0/external/module#version_format) for more details. |
+| `compatibility_level` | [int](/versions/8.6.0/rules/lib/core/int); default is `-1`  Deprecated. This is now a no-op and has no effect. |
+| `repo_name` | [string](/versions/8.6.0/rules/lib/core/string); default is `''`  The name of the repository representing this module, as seen by the module itself. By default, the name of the repo is the name of the module. This can be specified to ease migration for projects that have been using a repo name for itself that differs from its module name. |
+| `bazel_compatibility` | Iterable of [string](/versions/8.6.0/rules/lib/core/string)s; default is `[]`  A list of bazel versions that allows users to declare which Bazel versions are compatible with this module. It does NOT affect dependency resolution, but bzlmod will use this information to check if your current Bazel version is compatible. The format of this value is a string of some constraint values separated by comma. Three constraints are supported: <=X.X.X: The Bazel version must be equal or older than X.X.X. Used when there is a known incompatible change in a newer version. >=X.X.X: The Bazel version must be equal or newer than X.X.X.Used when you depend on some features that are only available since X.X.X. -X.X.X: The Bazel version X.X.X is not compatible. Used when there is a bug in X.X.X that breaks you, but fixed in later versions. |
 
 ## multiple_version_override
 
@@ -183,15 +183,15 @@ It should be called at most once, and if called, it must be the very first direc
 None multiple_version_override(module_name, versions, registry='')
 ```
 
-Specifies that a dependency should still come from a registry, but multiple versions of it should be allowed to coexist. See [the documentation](/external/module#multiple-version_override) for more details. This directive only takes effect in the root module; in other words, if a module is used as a dependency by others, its own overrides are ignored.
+Specifies that a dependency should still come from a registry, but multiple versions of it should be allowed to coexist. See [the documentation](/versions/8.6.0/external/module#multiple-version_override) for more details. This directive only takes effect in the root module; in other words, if a module is used as a dependency by others, its own overrides are ignored.
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `module_name` | [string](../core/string); required  The name of the Bazel module dependency to apply this override to. |
-| `versions` | Iterable of [string](../core/string)s; required  Explicitly specifies the versions allowed to coexist. These versions must already be present in the dependency graph pre-selection. Dependencies on this module will be "upgraded" to the nearest higher allowed version at the same compatibility level, whereas dependencies that have a higher version than any allowed versions at the same compatibility level will cause an error. |
-| `registry` | [string](../core/string); default is `''`  Overrides the registry for this module; instead of finding this module from the default list of registries, the given registry should be used. |
+| `module_name` | [string](/versions/8.6.0/rules/lib/core/string); required  The name of the Bazel module dependency to apply this override to. |
+| `versions` | Iterable of [string](/versions/8.6.0/rules/lib/core/string)s; required  Explicitly specifies the versions allowed to coexist. These versions must already be present in the dependency graph pre-selection. Dependencies on this module will be "upgraded" to the nearest higher allowed version at the same compatibility level, whereas dependencies that have a higher version than any allowed versions at the same compatibility level will cause an error. |
+| `registry` | [string](/versions/8.6.0/rules/lib/core/string); default is `''`  Overrides the registry for this module; instead of finding this module from the default list of registries, the given registry should be used. |
 
 ## override_repo
 
@@ -219,14 +219,14 @@ Use [`inject_repo`](#inject_repo) instead to add a new repo.
 None register_execution_platforms(dev_dependency=False, *platform_labels)
 ```
 
-Specifies already-defined execution platforms to be registered when this module is selected. Should be absolute [target patterns](https://bazel.build/reference/glossary#target-pattern) (ie. beginning with either `@` or `//`). See [toolchain resolution](/docs/toolchains) for more information. Patterns that expand to multiple targets, such as `:all`, will be registered in lexicographical order by name.
+Specifies already-defined execution platforms to be registered when this module is selected. Should be absolute [target patterns](https://bazel.build/versions/8.6.0/reference/glossary#target-pattern) (ie. beginning with either `@` or `//`). See [toolchain resolution](/versions/8.6.0/docs/toolchains) for more information. Patterns that expand to multiple targets, such as `:all`, will be registered in lexicographical order by name.
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `dev_dependency` | [bool](../core/bool); default is `False`  If true, the execution platforms will not be registered if the current module is not the root module or `--ignore_dev_dependency` is enabled. |
-| `platform_labels` | [sequence](../core/list) of [string](../core/string)s; required  The target patterns to register. |
+| `dev_dependency` | [bool](/versions/8.6.0/rules/lib/core/bool); default is `False`  If true, the execution platforms will not be registered if the current module is not the root module or `--ignore_dev_dependency` is enabled. |
+| `platform_labels` | [sequence](/versions/8.6.0/rules/lib/core/list) of [string](/versions/8.6.0/rules/lib/core/string)s; required  The target patterns to register. |
 
 ## register_toolchains
 
@@ -234,14 +234,14 @@ Specifies already-defined execution platforms to be registered when this module
 None register_toolchains(dev_dependency=False, *toolchain_labels)
 ```
 
-Specifies already-defined toolchains to be registered when this module is selected. Should be absolute [target patterns](https://bazel.build/reference/glossary#target-pattern) (ie. beginning with either `@` or `//`). See [toolchain resolution](/docs/toolchains) for more information. Patterns that expand to multiple targets, such as `:all`, will be registered in lexicographical order by target name (not the name of the toolchain implementation).
+Specifies already-defined toolchains to be registered when this module is selected. Should be absolute [target patterns](https://bazel.build/versions/8.6.0/reference/glossary#target-pattern) (ie. beginning with either `@` or `//`). See [toolchain resolution](/versions/8.6.0/docs/toolchains) for more information. Patterns that expand to multiple targets, such as `:all`, will be registered in lexicographical order by target name (not the name of the toolchain implementation).
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `dev_dependency` | [bool](../core/bool); default is `False`  If true, the toolchains will not be registered if the current module is not the root module or `--ignore_dev_dependency` is enabled. |
-| `toolchain_labels` | [sequence](../core/list) of [string](../core/string)s; required  The target patterns to register. |
+| `dev_dependency` | [bool](/versions/8.6.0/rules/lib/core/bool); default is `False`  If true, the toolchains will not be registered if the current module is not the root module or `--ignore_dev_dependency` is enabled. |
+| `toolchain_labels` | [sequence](/versions/8.6.0/rules/lib/core/list) of [string](/versions/8.6.0/rules/lib/core/string)s; required  The target patterns to register. |
 
 ## single_version_override
 
@@ -255,12 +255,12 @@ Specifies that a dependency should still come from a registry, but its version s
 
 | Parameter | Description |
 | --- | --- |
-| `module_name` | [string](../core/string); required  The name of the Bazel module dependency to apply this override to. |
-| `version` | [string](../core/string); default is `''`  Overrides the declared version of this module in the dependency graph. In other words, this module will be "pinned" to this override version. This attribute can be omitted if all one wants to override is the registry or the patches. |
-| `registry` | [string](../core/string); default is `''`  Overrides the registry for this module; instead of finding this module from the default list of registries, the given registry should be used. |
-| `patches` | Iterable of [string](../core/string)s; default is `[]`  A list of labels pointing to patch files to apply for this module. The patch files must exist in the source tree of the top level project. They are applied in the list order. If a patch makes changes to the MODULE.bazel file, these changes will only be effective if the patch file is provided by the root module. |
-| `patch_cmds` | Iterable of [string](../core/string)s; default is `[]`  Sequence of Bash commands to be applied on Linux/Macos after patches are applied. Changes to the MODULE.bazel file will not be effective. |
-| `patch_strip` | [int](../core/int); default is `0`  Same as the --strip argument of Unix patch. |
+| `module_name` | [string](/versions/8.6.0/rules/lib/core/string); required  The name of the Bazel module dependency to apply this override to. |
+| `version` | [string](/versions/8.6.0/rules/lib/core/string); default is `''`  Overrides the declared version of this module in the dependency graph. In other words, this module will be "pinned" to this override version. This attribute can be omitted if all one wants to override is the registry or the patches. |
+| `registry` | [string](/versions/8.6.0/rules/lib/core/string); default is `''`  Overrides the registry for this module; instead of finding this module from the default list of registries, the given registry should be used. |
+| `patches` | Iterable of [string](/versions/8.6.0/rules/lib/core/string)s; default is `[]`  A list of labels pointing to patch files to apply for this module. The patch files must exist in the source tree of the top level project. They are applied in the list order. If a patch makes changes to the MODULE.bazel file, these changes will only be effective if the patch file is provided by the root module. |
+| `patch_cmds` | Iterable of [string](/versions/8.6.0/rules/lib/core/string)s; default is `[]`  Sequence of Bash commands to be applied on Linux/Macos after patches are applied. Changes to the MODULE.bazel file will not be effective. |
+| `patch_strip` | [int](/versions/8.6.0/rules/lib/core/int); default is `0`  Same as the --strip argument of Unix patch. |
 
 ## use_extension
 
@@ -274,10 +274,10 @@ Returns a proxy object representing a module extension; its methods can be invok
 
 | Parameter | Description |
 | --- | --- |
-| `extension_bzl_file` | [string](../core/string); required  A label to the Starlark file defining the module extension. |
-| `extension_name` | [string](../core/string); required  The name of the module extension to use. A symbol with this name must be exported by the Starlark file. |
-| `dev_dependency` | [bool](../core/bool); default is `False`  If true, this usage of the module extension will be ignored if the current module is not the root module or `--ignore_dev_dependency` is enabled. |
-| `isolate` | [bool](../core/bool); default is `False`  **Experimental**. This parameter is experimental and may change at any time. Please do not depend on it. It may be enabled on an experimental basis by setting `--experimental_isolated_extension_usages`  If true, this usage of the module extension will be isolated from all other usages, both in this and other modules. Tags created for this usage do not affect other usages and the repositories generated by the extension for this usage will be distinct from all other repositories generated by the extension. This parameter is currently experimental and only available with the flag `--experimental_isolated_extension_usages`. |
+| `extension_bzl_file` | [string](/versions/8.6.0/rules/lib/core/string); required  A label to the Starlark file defining the module extension. |
+| `extension_name` | [string](/versions/8.6.0/rules/lib/core/string); required  The name of the module extension to use. A symbol with this name must be exported by the Starlark file. |
+| `dev_dependency` | [bool](/versions/8.6.0/rules/lib/core/bool); default is `False`  If true, this usage of the module extension will be ignored if the current module is not the root module or `--ignore_dev_dependency` is enabled. |
+| `isolate` | [bool](/versions/8.6.0/rules/lib/core/bool); default is `False`  **Experimental**. This parameter is experimental and may change at any time. Please do not depend on it. It may be enabled on an experimental basis by setting `--experimental_isolated_extension_usages`  If true, this usage of the module extension will be isolated from all other usages, both in this and other modules. Tags created for this usage do not affect other usages and the repositories generated by the extension for this usage will be distinct from all other repositories generated by the extension. This parameter is currently experimental and only available with the flag `--experimental_isolated_extension_usages`. |
 
 ## use_repo
 
@@ -307,5 +307,5 @@ Returns a proxy value that can be directly invoked in the MODULE.bazel file as a
 
 | Parameter | Description |
 | --- | --- |
-| `repo_rule_bzl_file` | [string](../core/string); required  A label to the Starlark file defining the repo rule. |
-| `repo_rule_name` | [string](../core/string); required  The name of the repo rule to use. A symbol with this name must be exported by the Starlark file. |
\ No newline at end of file
+| `repo_rule_bzl_file` | [string](/versions/8.6.0/rules/lib/core/string); required  A label to the Starlark file defining the repo rule. |
+| `repo_rule_name` | [string](/versions/8.6.0/rules/lib/core/string); required  The name of the repo rule to use. A symbol with this name must be exported by the Starlark file. |
\ No newline at end of file
diff --git a/versions/8.6.0/rules/lib/globals/repo.mdx b/versions/8.6.0/rules/lib/globals/repo.mdx
index afeb9519..b502713c 100644
--- a/versions/8.6.0/rules/lib/globals/repo.mdx
+++ b/versions/8.6.0/rules/lib/globals/repo.mdx
@@ -23,7 +23,7 @@ This function takes a list of strings and a directory is ignored if any of the g
 
 | Parameter | Description |
 | --- | --- |
-| `dirs` | [sequence](../core/list) of [string](../core/string)s; required |
+| `dirs` | [sequence](/versions/8.6.0/rules/lib/core/list) of [string](/versions/8.6.0/rules/lib/core/string)s; required |
 
 ## repo
 
@@ -37,4 +37,4 @@ Declares metadata that applies to every rule in the repository. It must be calle
 
 | Parameter | Description |
 | --- | --- |
-| `kwargs` | required  The `repo()` function accepts exactly the same arguments as the [`package()`](/reference/be/functions#package) function in BUILD files. |
\ No newline at end of file
+| `kwargs` | required  The `repo()` function accepts exactly the same arguments as the [`package()`](/versions/8.6.0/reference/be/functions#package) function in BUILD files. |
\ No newline at end of file
diff --git a/versions/8.6.0/rules/lib/globals/workspace.mdx b/versions/8.6.0/rules/lib/globals/workspace.mdx
index 83347209..b8745fc9 100644
--- a/versions/8.6.0/rules/lib/globals/workspace.mdx
+++ b/versions/8.6.0/rules/lib/globals/workspace.mdx
@@ -25,8 +25,8 @@ Gives a target an alias in the `//external` package.
 
 | Parameter | Description |
 | --- | --- |
-| `name` | [string](../core/string); required  The label under '//external' to serve as the alias name |
-| `actual` | [string](../core/string); or `None`; default is `None`  The real label to be aliased |
+| `name` | [string](/versions/8.6.0/rules/lib/core/string); required  The label under '//external' to serve as the alias name |
+| `actual` | [string](/versions/8.6.0/rules/lib/core/string); or `None`; default is `None`  The real label to be aliased |
 
 ## register_execution_platforms
 
@@ -34,13 +34,13 @@ Gives a target an alias in the `//external` package.
 None register_execution_platforms(*platform_labels)
 ```
 
-Specifies already-defined execution platforms to be registered. Should be absolute [target patterns](https://bazel.build/reference/glossary#target-pattern) (ie. beginning with either `@` or `//`). See [toolchain resolution](/docs/toolchains) for more information. Patterns that expand to multiple targets, such as `:all`, will be registered in lexicographical order by name.
+Specifies already-defined execution platforms to be registered. Should be absolute [target patterns](https://bazel.build/versions/8.6.0/reference/glossary#target-pattern) (ie. beginning with either `@` or `//`). See [toolchain resolution](/versions/8.6.0/docs/toolchains) for more information. Patterns that expand to multiple targets, such as `:all`, will be registered in lexicographical order by name.
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `platform_labels` | [sequence](../core/list) of [string](../core/string)s; required  The target patterns to register. |
+| `platform_labels` | [sequence](/versions/8.6.0/rules/lib/core/list) of [string](/versions/8.6.0/rules/lib/core/string)s; required  The target patterns to register. |
 
 ## register_toolchains
 
@@ -48,13 +48,13 @@ Specifies already-defined execution platforms to be registered. Should be absolu
 None register_toolchains(*toolchain_labels)
 ```
 
-Specifies already-defined toolchains to be registered. Should be absolute [target patterns](https://bazel.build/reference/glossary#target-pattern) (ie. beginning with either `@` or `//`). See [toolchain resolution](/docs/toolchains) for more information. Patterns that expand to multiple targets, such as `:all`, will be registered in lexicographical order by target name (not the name of the toolchain implementation).
+Specifies already-defined toolchains to be registered. Should be absolute [target patterns](https://bazel.build/versions/8.6.0/reference/glossary#target-pattern) (ie. beginning with either `@` or `//`). See [toolchain resolution](/versions/8.6.0/docs/toolchains) for more information. Patterns that expand to multiple targets, such as `:all`, will be registered in lexicographical order by target name (not the name of the toolchain implementation).
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `toolchain_labels` | [sequence](../core/list) of [string](../core/string)s; required  The target patterns to register. |
+| `toolchain_labels` | [sequence](/versions/8.6.0/rules/lib/core/list) of [string](/versions/8.6.0/rules/lib/core/string)s; required  The target patterns to register. |
 
 ## workspace
 
@@ -68,10 +68,10 @@ Sets the name for this workspace. Workspace names should be a Java-package-style
 
 This name is used for the directory that the repository's runfiles are stored in. For example, if there is a runfile `foo/bar` in the local repository and the WORKSPACE file contains `workspace(name = 'baz')`, then the runfile will be available under `mytarget.runfiles/baz/foo/bar`. If no workspace name is specified, then the runfile will be symlinked to `bar.runfiles/foo/bar`.
 
-[Remote repository](/docs/external) rule names must be valid workspace names. For example, you could have `maven_jar(name = 'foo')`, but not `maven_jar(name = 'foo%bar')`, as Bazel would attempt to write a WORKSPACE file for the `maven_jar` containing `workspace(name = 'foo%bar')`.
+[Remote repository](/versions/8.6.0/docs/external) rule names must be valid workspace names. For example, you could have `maven_jar(name = 'foo')`, but not `maven_jar(name = 'foo%bar')`, as Bazel would attempt to write a WORKSPACE file for the `maven_jar` containing `workspace(name = 'foo%bar')`.
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `name` | [string](../core/string); required  the name of the workspace. Names must start with a letter and can only contain letters, numbers, underscores, dashes, and dots. |
\ No newline at end of file
+| `name` | [string](/versions/8.6.0/rules/lib/core/string); required  the name of the workspace. Names must start with a letter and can only contain letters, numbers, underscores, dashes, and dots. |
\ No newline at end of file
diff --git a/versions/8.6.0/rules/lib/overview.mdx b/versions/8.6.0/rules/lib/overview.mdx
index 92369625..87856a36 100644
--- a/versions/8.6.0/rules/lib/overview.mdx
+++ b/versions/8.6.0/rules/lib/overview.mdx
@@ -2,149 +2,149 @@
 title: 'One-Page Overview'
 ---
 
-## [Global functions](/rules/lib/globals)
+## [Global functions](/versions/8.6.0/rules/lib/globals)
 
-* [.bzl files](/rules/lib/globals/bzl)
-* [All Bazel files](/rules/lib/globals/all)
-* [BUILD files](/rules/lib/globals/build)
-* [MODULE.bazel files](/rules/lib/globals/module)
-* [REPO.bazel files](/rules/lib/globals/repo)
-* [VENDOR.bazel files](/rules/lib/globals/vendor)
-* [WORKSPACE files](/rules/lib/globals/workspace)
+* [.bzl files](/versions/8.6.0/rules/lib/globals/bzl)
+* [All Bazel files](/versions/8.6.0/rules/lib/globals/all)
+* [BUILD files](/versions/8.6.0/rules/lib/globals/build)
+* [MODULE.bazel files](/versions/8.6.0/rules/lib/globals/module)
+* [REPO.bazel files](/versions/8.6.0/rules/lib/globals/repo)
+* [VENDOR.bazel files](/versions/8.6.0/rules/lib/globals/vendor)
+* [WORKSPACE files](/versions/8.6.0/rules/lib/globals/workspace)
 
-## [Configuration Fragments](/rules/lib/fragments)
+## [Configuration Fragments](/versions/8.6.0/rules/lib/fragments)
 
-* [apple](/rules/lib/fragments/apple)
-* [bazel_android](/rules/lib/fragments/bazel_android)
-* [bazel_py](/rules/lib/fragments/bazel_py)
-* [coverage](/rules/lib/fragments/coverage)
-* [cpp](/rules/lib/fragments/cpp)
-* [j2objc](/rules/lib/fragments/j2objc)
-* [java](/rules/lib/fragments/java)
-* [objc](/rules/lib/fragments/objc)
-* [platform](/rules/lib/fragments/platform)
-* [proto](/rules/lib/fragments/proto)
-* [py](/rules/lib/fragments/py)
+* [apple](/versions/8.6.0/rules/lib/fragments/apple)
+* [bazel_android](/versions/8.6.0/rules/lib/fragments/bazel_android)
+* [bazel_py](/versions/8.6.0/rules/lib/fragments/bazel_py)
+* [coverage](/versions/8.6.0/rules/lib/fragments/coverage)
+* [cpp](/versions/8.6.0/rules/lib/fragments/cpp)
+* [j2objc](/versions/8.6.0/rules/lib/fragments/j2objc)
+* [java](/versions/8.6.0/rules/lib/fragments/java)
+* [objc](/versions/8.6.0/rules/lib/fragments/objc)
+* [platform](/versions/8.6.0/rules/lib/fragments/platform)
+* [proto](/versions/8.6.0/rules/lib/fragments/proto)
+* [py](/versions/8.6.0/rules/lib/fragments/py)
 
-## [Providers](/rules/lib/providers)
+## [Providers](/versions/8.6.0/rules/lib/providers)
 
-* [AnalysisTestResultInfo](/rules/lib/providers/AnalysisTestResultInfo)
-* [CcInfo](/rules/lib/providers/CcInfo)
-* [CcToolchainConfigInfo](/rules/lib/providers/CcToolchainConfigInfo)
-* [CcToolchainInfo](/rules/lib/providers/CcToolchainInfo)
-* [ConstraintCollection](/rules/lib/providers/ConstraintCollection)
-* [ConstraintSettingInfo](/rules/lib/providers/ConstraintSettingInfo)
-* [ConstraintValueInfo](/rules/lib/providers/ConstraintValueInfo)
-* [DebugPackageInfo](/rules/lib/providers/DebugPackageInfo)
-* [DefaultInfo](/rules/lib/providers/DefaultInfo)
-* [ExecutionInfo](/rules/lib/providers/ExecutionInfo)
-* [FeatureFlagInfo](/rules/lib/providers/FeatureFlagInfo)
-* [file_provider](/rules/lib/providers/file_provider)
-* [FilesToRunProvider](/rules/lib/providers/FilesToRunProvider)
-* [IncompatiblePlatformProvider](/rules/lib/providers/IncompatiblePlatformProvider)
-* [InstrumentedFilesInfo](/rules/lib/providers/InstrumentedFilesInfo)
-* [java_compilation_info](/rules/lib/providers/java_compilation_info)
-* [java_output_jars](/rules/lib/providers/java_output_jars)
-* [JavaRuntimeInfo](/rules/lib/providers/JavaRuntimeInfo)
-* [JavaToolchainInfo](/rules/lib/providers/JavaToolchainInfo)
-* [ObjcProvider](/rules/lib/providers/ObjcProvider)
-* [OutputGroupInfo](/rules/lib/providers/OutputGroupInfo)
-* [PackageSpecificationInfo](/rules/lib/providers/PackageSpecificationInfo)
-* [PlatformInfo](/rules/lib/providers/PlatformInfo)
-* [ProguardSpecProvider](/rules/lib/providers/ProguardSpecProvider)
-* [ProtoRegistryProvider](/rules/lib/providers/ProtoRegistryProvider)
-* [RunEnvironmentInfo](/rules/lib/providers/RunEnvironmentInfo)
-* [TemplateVariableInfo](/rules/lib/providers/TemplateVariableInfo)
-* [ToolchainInfo](/rules/lib/providers/ToolchainInfo)
-* [ToolchainTypeInfo](/rules/lib/providers/ToolchainTypeInfo)
+* [AnalysisTestResultInfo](/versions/8.6.0/rules/lib/providers/AnalysisTestResultInfo)
+* [CcInfo](/versions/8.6.0/rules/lib/providers/CcInfo)
+* [CcToolchainConfigInfo](/versions/8.6.0/rules/lib/providers/CcToolchainConfigInfo)
+* [CcToolchainInfo](/versions/8.6.0/rules/lib/providers/CcToolchainInfo)
+* [ConstraintCollection](/versions/8.6.0/rules/lib/providers/ConstraintCollection)
+* [ConstraintSettingInfo](/versions/8.6.0/rules/lib/providers/ConstraintSettingInfo)
+* [ConstraintValueInfo](/versions/8.6.0/rules/lib/providers/ConstraintValueInfo)
+* [DebugPackageInfo](/versions/8.6.0/rules/lib/providers/DebugPackageInfo)
+* [DefaultInfo](/versions/8.6.0/rules/lib/providers/DefaultInfo)
+* [ExecutionInfo](/versions/8.6.0/rules/lib/providers/ExecutionInfo)
+* [FeatureFlagInfo](/versions/8.6.0/rules/lib/providers/FeatureFlagInfo)
+* [file_provider](/versions/8.6.0/rules/lib/providers/file_provider)
+* [FilesToRunProvider](/versions/8.6.0/rules/lib/providers/FilesToRunProvider)
+* [IncompatiblePlatformProvider](/versions/8.6.0/rules/lib/providers/IncompatiblePlatformProvider)
+* [InstrumentedFilesInfo](/versions/8.6.0/rules/lib/providers/InstrumentedFilesInfo)
+* [java_compilation_info](/versions/8.6.0/rules/lib/providers/java_compilation_info)
+* [java_output_jars](/versions/8.6.0/rules/lib/providers/java_output_jars)
+* [JavaRuntimeInfo](/versions/8.6.0/rules/lib/providers/JavaRuntimeInfo)
+* [JavaToolchainInfo](/versions/8.6.0/rules/lib/providers/JavaToolchainInfo)
+* [ObjcProvider](/versions/8.6.0/rules/lib/providers/ObjcProvider)
+* [OutputGroupInfo](/versions/8.6.0/rules/lib/providers/OutputGroupInfo)
+* [PackageSpecificationInfo](/versions/8.6.0/rules/lib/providers/PackageSpecificationInfo)
+* [PlatformInfo](/versions/8.6.0/rules/lib/providers/PlatformInfo)
+* [ProguardSpecProvider](/versions/8.6.0/rules/lib/providers/ProguardSpecProvider)
+* [ProtoRegistryProvider](/versions/8.6.0/rules/lib/providers/ProtoRegistryProvider)
+* [RunEnvironmentInfo](/versions/8.6.0/rules/lib/providers/RunEnvironmentInfo)
+* [TemplateVariableInfo](/versions/8.6.0/rules/lib/providers/TemplateVariableInfo)
+* [ToolchainInfo](/versions/8.6.0/rules/lib/providers/ToolchainInfo)
+* [ToolchainTypeInfo](/versions/8.6.0/rules/lib/providers/ToolchainTypeInfo)
 
-## [Built-in Types](/rules/lib/builtins)
+## [Built-in Types](/versions/8.6.0/rules/lib/builtins)
 
-* [Action](/rules/lib/builtins/Action)
-* [actions](/rules/lib/builtins/actions)
-* [apple_platform](/rules/lib/builtins/apple_platform)
-* [Args](/rules/lib/builtins/Args)
-* [Aspect](/rules/lib/builtins/Aspect)
-* [Attribute](/rules/lib/builtins/Attribute)
-* [bazel_module](/rules/lib/builtins/bazel_module)
-* [bazel_module_tags](/rules/lib/builtins/bazel_module_tags)
-* [BuildSetting](/rules/lib/builtins/BuildSetting)
-* [CcCompilationOutputs](/rules/lib/builtins/CcCompilationOutputs)
-* [CcLinkingOutputs](/rules/lib/builtins/CcLinkingOutputs)
-* [CompilationContext](/rules/lib/builtins/CompilationContext)
-* [configuration](/rules/lib/builtins/configuration)
-* [ctx](/rules/lib/builtins/ctx)
-* [depset](/rules/lib/builtins/depset)
-* [DirectoryExpander](/rules/lib/builtins/DirectoryExpander)
-* [DottedVersion](/rules/lib/builtins/DottedVersion)
-* [exec_result](/rules/lib/builtins/exec_result)
-* [ExecGroupCollection](/rules/lib/builtins/ExecGroupCollection)
-* [ExecGroupContext](/rules/lib/builtins/ExecGroupContext)
-* [ExecTransitionFactory](/rules/lib/builtins/ExecTransitionFactory)
-* [extension_metadata](/rules/lib/builtins/extension_metadata)
-* [Facts](/rules/lib/builtins/Facts)
-* [FeatureConfiguration](/rules/lib/builtins/FeatureConfiguration)
-* [File](/rules/lib/builtins/File)
-* [fragments](/rules/lib/builtins/fragments)
-* [java_annotation_processing](/rules/lib/builtins/java_annotation_processing)
-* [Label](/rules/lib/builtins/Label)
-* [LateBoundDefault](/rules/lib/builtins/LateBoundDefault)
-* [LibraryToLink](/rules/lib/builtins/LibraryToLink)
-* [License](/rules/lib/builtins/License)
-* [LinkerInput](/rules/lib/builtins/LinkerInput)
-* [LinkingContext](/rules/lib/builtins/LinkingContext)
-* [macro](/rules/lib/builtins/macro)
-* [mapped_root](/rules/lib/builtins/mapped_root)
-* [module_ctx](/rules/lib/builtins/module_ctx)
-* [path](/rules/lib/builtins/path)
-* [Provider](/rules/lib/builtins/Provider)
-* [repo_metadata](/rules/lib/builtins/repo_metadata)
-* [repository_ctx](/rules/lib/builtins/repository_ctx)
-* [repository_os](/rules/lib/builtins/repository_os)
-* [repository_rule](/rules/lib/builtins/repository_rule)
-* [root](/rules/lib/builtins/root)
-* [rule](/rules/lib/builtins/rule)
-* [rule_attributes](/rules/lib/builtins/rule_attributes)
-* [runfiles](/rules/lib/builtins/runfiles)
-* [struct](/rules/lib/builtins/struct)
-* [Subrule](/rules/lib/builtins/Subrule)
-* [subrule_ctx](/rules/lib/builtins/subrule_ctx)
-* [SymlinkEntry](/rules/lib/builtins/SymlinkEntry)
-* [tag_class](/rules/lib/builtins/tag_class)
-* [Target](/rules/lib/builtins/Target)
-* [TemplateDict](/rules/lib/builtins/TemplateDict)
-* [toolchain_type](/rules/lib/builtins/toolchain_type)
-* [ToolchainContext](/rules/lib/builtins/ToolchainContext)
-* [transition](/rules/lib/builtins/transition)
-* [wasm_exec_result](/rules/lib/builtins/wasm_exec_result)
-* [wasm_module](/rules/lib/builtins/wasm_module)
+* [Action](/versions/8.6.0/rules/lib/builtins/Action)
+* [actions](/versions/8.6.0/rules/lib/builtins/actions)
+* [apple_platform](/versions/8.6.0/rules/lib/builtins/apple_platform)
+* [Args](/versions/8.6.0/rules/lib/builtins/Args)
+* [Aspect](/versions/8.6.0/rules/lib/builtins/Aspect)
+* [Attribute](/versions/8.6.0/rules/lib/builtins/Attribute)
+* [bazel_module](/versions/8.6.0/rules/lib/builtins/bazel_module)
+* [bazel_module_tags](/versions/8.6.0/rules/lib/builtins/bazel_module_tags)
+* [BuildSetting](/versions/8.6.0/rules/lib/builtins/BuildSetting)
+* [CcCompilationOutputs](/versions/8.6.0/rules/lib/builtins/CcCompilationOutputs)
+* [CcLinkingOutputs](/versions/8.6.0/rules/lib/builtins/CcLinkingOutputs)
+* [CompilationContext](/versions/8.6.0/rules/lib/builtins/CompilationContext)
+* [configuration](/versions/8.6.0/rules/lib/builtins/configuration)
+* [ctx](/versions/8.6.0/rules/lib/builtins/ctx)
+* [depset](/versions/8.6.0/rules/lib/builtins/depset)
+* [DirectoryExpander](/versions/8.6.0/rules/lib/builtins/DirectoryExpander)
+* [DottedVersion](/versions/8.6.0/rules/lib/builtins/DottedVersion)
+* [exec_result](/versions/8.6.0/rules/lib/builtins/exec_result)
+* [ExecGroupCollection](/versions/8.6.0/rules/lib/builtins/ExecGroupCollection)
+* [ExecGroupContext](/versions/8.6.0/rules/lib/builtins/ExecGroupContext)
+* [ExecTransitionFactory](/versions/8.6.0/rules/lib/builtins/ExecTransitionFactory)
+* [extension_metadata](/versions/8.6.0/rules/lib/builtins/extension_metadata)
+* [Facts](/versions/8.6.0/rules/lib/builtins/Facts)
+* [FeatureConfiguration](/versions/8.6.0/rules/lib/builtins/FeatureConfiguration)
+* [File](/versions/8.6.0/rules/lib/builtins/File)
+* [fragments](/versions/8.6.0/rules/lib/builtins/fragments)
+* [java_annotation_processing](/versions/8.6.0/rules/lib/builtins/java_annotation_processing)
+* [Label](/versions/8.6.0/rules/lib/builtins/Label)
+* [LateBoundDefault](/versions/8.6.0/rules/lib/builtins/LateBoundDefault)
+* [LibraryToLink](/versions/8.6.0/rules/lib/builtins/LibraryToLink)
+* [License](/versions/8.6.0/rules/lib/builtins/License)
+* [LinkerInput](/versions/8.6.0/rules/lib/builtins/LinkerInput)
+* [LinkingContext](/versions/8.6.0/rules/lib/builtins/LinkingContext)
+* [macro](/versions/8.6.0/rules/lib/builtins/macro)
+* [mapped_root](/versions/8.6.0/rules/lib/builtins/mapped_root)
+* [module_ctx](/versions/8.6.0/rules/lib/builtins/module_ctx)
+* [path](/versions/8.6.0/rules/lib/builtins/path)
+* [Provider](/versions/8.6.0/rules/lib/builtins/Provider)
+* [repo_metadata](/versions/8.6.0/rules/lib/builtins/repo_metadata)
+* [repository_ctx](/versions/8.6.0/rules/lib/builtins/repository_ctx)
+* [repository_os](/versions/8.6.0/rules/lib/builtins/repository_os)
+* [repository_rule](/versions/8.6.0/rules/lib/builtins/repository_rule)
+* [root](/versions/8.6.0/rules/lib/builtins/root)
+* [rule](/versions/8.6.0/rules/lib/builtins/rule)
+* [rule_attributes](/versions/8.6.0/rules/lib/builtins/rule_attributes)
+* [runfiles](/versions/8.6.0/rules/lib/builtins/runfiles)
+* [struct](/versions/8.6.0/rules/lib/builtins/struct)
+* [Subrule](/versions/8.6.0/rules/lib/builtins/Subrule)
+* [subrule_ctx](/versions/8.6.0/rules/lib/builtins/subrule_ctx)
+* [SymlinkEntry](/versions/8.6.0/rules/lib/builtins/SymlinkEntry)
+* [tag_class](/versions/8.6.0/rules/lib/builtins/tag_class)
+* [Target](/versions/8.6.0/rules/lib/builtins/Target)
+* [TemplateDict](/versions/8.6.0/rules/lib/builtins/TemplateDict)
+* [toolchain_type](/versions/8.6.0/rules/lib/builtins/toolchain_type)
+* [ToolchainContext](/versions/8.6.0/rules/lib/builtins/ToolchainContext)
+* [transition](/versions/8.6.0/rules/lib/builtins/transition)
+* [wasm_exec_result](/versions/8.6.0/rules/lib/builtins/wasm_exec_result)
+* [wasm_module](/versions/8.6.0/rules/lib/builtins/wasm_module)
 
-## [Top-level Modules](/rules/lib/toplevel)
+## [Top-level Modules](/versions/8.6.0/rules/lib/toplevel)
 
-* [apple_common](/rules/lib/toplevel/apple_common)
-* [attr](/rules/lib/toplevel/attr)
-* [cc_common](/rules/lib/toplevel/cc_common)
-* [config](/rules/lib/toplevel/config)
-* [config_common](/rules/lib/toplevel/config_common)
-* [coverage_common](/rules/lib/toplevel/coverage_common)
-* [java_common](/rules/lib/toplevel/java_common)
-* [native](/rules/lib/toplevel/native)
-* [platform_common](/rules/lib/toplevel/platform_common)
-* [proto](/rules/lib/toplevel/proto)
-* [proto_common](/rules/lib/toplevel/proto_common)
-* [testing](/rules/lib/toplevel/testing)
+* [apple_common](/versions/8.6.0/rules/lib/toplevel/apple_common)
+* [attr](/versions/8.6.0/rules/lib/toplevel/attr)
+* [cc_common](/versions/8.6.0/rules/lib/toplevel/cc_common)
+* [config](/versions/8.6.0/rules/lib/toplevel/config)
+* [config_common](/versions/8.6.0/rules/lib/toplevel/config_common)
+* [coverage_common](/versions/8.6.0/rules/lib/toplevel/coverage_common)
+* [java_common](/versions/8.6.0/rules/lib/toplevel/java_common)
+* [native](/versions/8.6.0/rules/lib/toplevel/native)
+* [platform_common](/versions/8.6.0/rules/lib/toplevel/platform_common)
+* [proto](/versions/8.6.0/rules/lib/toplevel/proto)
+* [proto_common](/versions/8.6.0/rules/lib/toplevel/proto_common)
+* [testing](/versions/8.6.0/rules/lib/toplevel/testing)
 
-## [Core Starlark data types](/rules/lib/core)
+## [Core Starlark data types](/versions/8.6.0/rules/lib/core)
 
-* [bool](/rules/lib/core/bool)
-* [builtin_function_or_method](/rules/lib/core/builtin_function_or_method)
-* [dict](/rules/lib/core/dict)
-* [float](/rules/lib/core/float)
-* [function](/rules/lib/core/function)
-* [int](/rules/lib/core/int)
-* [json](/rules/lib/core/json)
-* [list](/rules/lib/core/list)
-* [range](/rules/lib/core/range)
-* [set](/rules/lib/core/set)
-* [string](/rules/lib/core/string)
-* [tuple](/rules/lib/core/tuple)
\ No newline at end of file
+* [bool](/versions/8.6.0/rules/lib/core/bool)
+* [builtin_function_or_method](/versions/8.6.0/rules/lib/core/builtin_function_or_method)
+* [dict](/versions/8.6.0/rules/lib/core/dict)
+* [float](/versions/8.6.0/rules/lib/core/float)
+* [function](/versions/8.6.0/rules/lib/core/function)
+* [int](/versions/8.6.0/rules/lib/core/int)
+* [json](/versions/8.6.0/rules/lib/core/json)
+* [list](/versions/8.6.0/rules/lib/core/list)
+* [range](/versions/8.6.0/rules/lib/core/range)
+* [set](/versions/8.6.0/rules/lib/core/set)
+* [string](/versions/8.6.0/rules/lib/core/string)
+* [tuple](/versions/8.6.0/rules/lib/core/tuple)
\ No newline at end of file
diff --git a/versions/8.6.0/rules/lib/providers.mdx b/versions/8.6.0/rules/lib/providers.mdx
index 6538b900..d64a3f06 100644
--- a/versions/8.6.0/rules/lib/providers.mdx
+++ b/versions/8.6.0/rules/lib/providers.mdx
@@ -2,34 +2,34 @@
 title: 'Providers'
 ---
 
-This section lists providers available on built-in rules. See the [Rules page](https://bazel.build/extending/rules#providers) for more on providers. These symbols are available only in .bzl files.
+This section lists providers available on built-in rules. See the [Rules page](https://bazel.build/versions/8.6.0/extending/rules#providers) for more on providers. These symbols are available only in .bzl files.
 
-* [AnalysisTestResultInfo](/rules/lib/providers/AnalysisTestResultInfo)
-* [CcInfo](/rules/lib/providers/CcInfo)
-* [CcToolchainConfigInfo](/rules/lib/providers/CcToolchainConfigInfo)
-* [CcToolchainInfo](/rules/lib/providers/CcToolchainInfo)
-* [ConstraintCollection](/rules/lib/providers/ConstraintCollection)
-* [ConstraintSettingInfo](/rules/lib/providers/ConstraintSettingInfo)
-* [ConstraintValueInfo](/rules/lib/providers/ConstraintValueInfo)
-* [DebugPackageInfo](/rules/lib/providers/DebugPackageInfo)
-* [DefaultInfo](/rules/lib/providers/DefaultInfo)
-* [ExecutionInfo](/rules/lib/providers/ExecutionInfo)
-* [FeatureFlagInfo](/rules/lib/providers/FeatureFlagInfo)
-* [file_provider](/rules/lib/providers/file_provider)
-* [FilesToRunProvider](/rules/lib/providers/FilesToRunProvider)
-* [IncompatiblePlatformProvider](/rules/lib/providers/IncompatiblePlatformProvider)
-* [InstrumentedFilesInfo](/rules/lib/providers/InstrumentedFilesInfo)
-* [java_compilation_info](/rules/lib/providers/java_compilation_info)
-* [java_output_jars](/rules/lib/providers/java_output_jars)
-* [JavaRuntimeInfo](/rules/lib/providers/JavaRuntimeInfo)
-* [JavaToolchainInfo](/rules/lib/providers/JavaToolchainInfo)
-* [ObjcProvider](/rules/lib/providers/ObjcProvider)
-* [OutputGroupInfo](/rules/lib/providers/OutputGroupInfo)
-* [PackageSpecificationInfo](/rules/lib/providers/PackageSpecificationInfo)
-* [PlatformInfo](/rules/lib/providers/PlatformInfo)
-* [ProguardSpecProvider](/rules/lib/providers/ProguardSpecProvider)
-* [ProtoRegistryProvider](/rules/lib/providers/ProtoRegistryProvider)
-* [RunEnvironmentInfo](/rules/lib/providers/RunEnvironmentInfo)
-* [TemplateVariableInfo](/rules/lib/providers/TemplateVariableInfo)
-* [ToolchainInfo](/rules/lib/providers/ToolchainInfo)
-* [ToolchainTypeInfo](/rules/lib/providers/ToolchainTypeInfo)
\ No newline at end of file
+* [AnalysisTestResultInfo](/versions/8.6.0/rules/lib/providers/AnalysisTestResultInfo)
+* [CcInfo](/versions/8.6.0/rules/lib/providers/CcInfo)
+* [CcToolchainConfigInfo](/versions/8.6.0/rules/lib/providers/CcToolchainConfigInfo)
+* [CcToolchainInfo](/versions/8.6.0/rules/lib/providers/CcToolchainInfo)
+* [ConstraintCollection](/versions/8.6.0/rules/lib/providers/ConstraintCollection)
+* [ConstraintSettingInfo](/versions/8.6.0/rules/lib/providers/ConstraintSettingInfo)
+* [ConstraintValueInfo](/versions/8.6.0/rules/lib/providers/ConstraintValueInfo)
+* [DebugPackageInfo](/versions/8.6.0/rules/lib/providers/DebugPackageInfo)
+* [DefaultInfo](/versions/8.6.0/rules/lib/providers/DefaultInfo)
+* [ExecutionInfo](/versions/8.6.0/rules/lib/providers/ExecutionInfo)
+* [FeatureFlagInfo](/versions/8.6.0/rules/lib/providers/FeatureFlagInfo)
+* [file_provider](/versions/8.6.0/rules/lib/providers/file_provider)
+* [FilesToRunProvider](/versions/8.6.0/rules/lib/providers/FilesToRunProvider)
+* [IncompatiblePlatformProvider](/versions/8.6.0/rules/lib/providers/IncompatiblePlatformProvider)
+* [InstrumentedFilesInfo](/versions/8.6.0/rules/lib/providers/InstrumentedFilesInfo)
+* [java_compilation_info](/versions/8.6.0/rules/lib/providers/java_compilation_info)
+* [java_output_jars](/versions/8.6.0/rules/lib/providers/java_output_jars)
+* [JavaRuntimeInfo](/versions/8.6.0/rules/lib/providers/JavaRuntimeInfo)
+* [JavaToolchainInfo](/versions/8.6.0/rules/lib/providers/JavaToolchainInfo)
+* [ObjcProvider](/versions/8.6.0/rules/lib/providers/ObjcProvider)
+* [OutputGroupInfo](/versions/8.6.0/rules/lib/providers/OutputGroupInfo)
+* [PackageSpecificationInfo](/versions/8.6.0/rules/lib/providers/PackageSpecificationInfo)
+* [PlatformInfo](/versions/8.6.0/rules/lib/providers/PlatformInfo)
+* [ProguardSpecProvider](/versions/8.6.0/rules/lib/providers/ProguardSpecProvider)
+* [ProtoRegistryProvider](/versions/8.6.0/rules/lib/providers/ProtoRegistryProvider)
+* [RunEnvironmentInfo](/versions/8.6.0/rules/lib/providers/RunEnvironmentInfo)
+* [TemplateVariableInfo](/versions/8.6.0/rules/lib/providers/TemplateVariableInfo)
+* [ToolchainInfo](/versions/8.6.0/rules/lib/providers/ToolchainInfo)
+* [ToolchainTypeInfo](/versions/8.6.0/rules/lib/providers/ToolchainTypeInfo)
\ No newline at end of file
diff --git a/versions/8.6.0/rules/lib/providers/AnalysisTestResultInfo.mdx b/versions/8.6.0/rules/lib/providers/AnalysisTestResultInfo.mdx
index 1edabb04..0dfad0b0 100644
--- a/versions/8.6.0/rules/lib/providers/AnalysisTestResultInfo.mdx
+++ b/versions/8.6.0/rules/lib/providers/AnalysisTestResultInfo.mdx
@@ -22,8 +22,8 @@ The `AnalysisTestResultInfo` constructor.
 
 | Parameter | Description |
 | --- | --- |
-| `success` | [bool](../core/bool); required  If true, then the analysis-phase test represented by this target should pass. If false, the test should fail. |
-| `message` | [string](../core/string); required  A descriptive message containing information about the test and its success/failure. |
+| `success` | [bool](/versions/8.6.0/rules/lib/core/bool); required  If true, then the analysis-phase test represented by this target should pass. If false, the test should fail. |
+| `message` | [string](/versions/8.6.0/rules/lib/core/string); required  A descriptive message containing information about the test and its success/failure. |
 
 ## message
 
diff --git a/versions/8.6.0/rules/lib/providers/CcInfo.mdx b/versions/8.6.0/rules/lib/providers/CcInfo.mdx
index c1b82ab4..1e4791f1 100644
--- a/versions/8.6.0/rules/lib/providers/CcInfo.mdx
+++ b/versions/8.6.0/rules/lib/providers/CcInfo.mdx
@@ -22,8 +22,8 @@ The `CcInfo` constructor.
 
 | Parameter | Description |
 | --- | --- |
-| `compilation_context` | [CompilationContext](../builtins/CompilationContext); or `None`; default is `None`  The `CompilationContext`. |
-| `linking_context` | [LinkingContext](../builtins/LinkingContext); or `None`; default is `None`  The `LinkingContext`. |
+| `compilation_context` | [CompilationContext](/versions/8.6.0/rules/lib/builtins/CompilationContext); or `None`; default is `None`  The `CompilationContext`. |
+| `linking_context` | [LinkingContext](/versions/8.6.0/rules/lib/builtins/LinkingContext); or `None`; default is `None`  The `LinkingContext`. |
 | `debug_context` | DebugContext; or `None`; default is `None`  The `DebugContext`. |
 
 ## compilation_context
diff --git a/versions/8.6.0/rules/lib/providers/ConstraintSettingInfo.mdx b/versions/8.6.0/rules/lib/providers/ConstraintSettingInfo.mdx
index 571aeb22..5b1f6b1e 100644
--- a/versions/8.6.0/rules/lib/providers/ConstraintSettingInfo.mdx
+++ b/versions/8.6.0/rules/lib/providers/ConstraintSettingInfo.mdx
@@ -2,7 +2,7 @@
 title: 'ConstraintSettingInfo'
 ---
 
-A specific constraint setting that may be used to define a platform. See [Defining Constraints and Platforms](/docs/platforms#constraints-platforms) for more information.
+A specific constraint setting that may be used to define a platform. See [Defining Constraints and Platforms](/versions/8.6.0/docs/platforms#constraints-platforms) for more information.
 *Note: This API is experimental and may change at any time. It is disabled by default, but may be enabled with `--experimental_platforms_api`*
 
 ## Members
diff --git a/versions/8.6.0/rules/lib/providers/ConstraintValueInfo.mdx b/versions/8.6.0/rules/lib/providers/ConstraintValueInfo.mdx
index 5c1b4275..f17416b7 100644
--- a/versions/8.6.0/rules/lib/providers/ConstraintValueInfo.mdx
+++ b/versions/8.6.0/rules/lib/providers/ConstraintValueInfo.mdx
@@ -2,5 +2,5 @@
 title: 'ConstraintValueInfo'
 ---
 
-A value for a constraint setting that can be used to define a platform. See [Defining Constraints and Platforms](/docs/platforms#constraints-platforms) for more information.
+A value for a constraint setting that can be used to define a platform. See [Defining Constraints and Platforms](/versions/8.6.0/docs/platforms#constraints-platforms) for more information.
 *Note: This API is experimental and may change at any time. It is disabled by default, but may be enabled with `--experimental_platforms_api`*
\ No newline at end of file
diff --git a/versions/8.6.0/rules/lib/providers/DebugPackageInfo.mdx b/versions/8.6.0/rules/lib/providers/DebugPackageInfo.mdx
index 580c1e19..e50f5f6b 100644
--- a/versions/8.6.0/rules/lib/providers/DebugPackageInfo.mdx
+++ b/versions/8.6.0/rules/lib/providers/DebugPackageInfo.mdx
@@ -24,10 +24,10 @@ The `DebugPackageInfo` constructor.
 
 | Parameter | Description |
 | --- | --- |
-| `target_label` | [Label](../builtins/Label); required  The label for the \*\_binary target |
-| `stripped_file` | [File](../builtins/File); or `None`; default is `None`  The stripped file (the explicit ".stripped" target) |
-| `unstripped_file` | [File](../builtins/File); required  The unstripped file (the default executable target). |
-| `dwp_file` | [File](../builtins/File); or `None`; default is `None`  The .dwp file (for fission builds) or null if --fission=no. |
+| `target_label` | [Label](/versions/8.6.0/rules/lib/builtins/Label); required  The label for the \*\_binary target |
+| `stripped_file` | [File](/versions/8.6.0/rules/lib/builtins/File); or `None`; default is `None`  The stripped file (the explicit ".stripped" target) |
+| `unstripped_file` | [File](/versions/8.6.0/rules/lib/builtins/File); required  The unstripped file (the default executable target). |
+| `dwp_file` | [File](/versions/8.6.0/rules/lib/builtins/File); or `None`; default is `None`  The .dwp file (for fission builds) or null if --fission=no. |
 
 ## dwp_file
 
diff --git a/versions/8.6.0/rules/lib/providers/DefaultInfo.mdx b/versions/8.6.0/rules/lib/providers/DefaultInfo.mdx
index 2be23f06..b81d9bff 100644
--- a/versions/8.6.0/rules/lib/providers/DefaultInfo.mdx
+++ b/versions/8.6.0/rules/lib/providers/DefaultInfo.mdx
@@ -6,7 +6,7 @@ A provider that gives general information about a target's direct and transitive
 
 * `files`* `files_to_run`* `data_runfiles`* `default_runfiles`
 
-See the [rules](https://bazel.build/extending/rules) page for extensive guides on how to use this provider.
+See the [rules](https://bazel.build/versions/8.6.0/extending/rules) page for extensive guides on how to use this provider.
 
 ## Members
 
@@ -28,11 +28,11 @@ The `DefaultInfo` constructor.
 
 | Parameter | Description |
 | --- | --- |
-| `files` | [depset](../builtins/depset); or `None`; default is `None`  A [`depset`](../builtins/depset) of [`File`](../builtins/File) objects representing the default outputs to build when this target is specified on the bazel command line. By default it is all predeclared outputs. |
-| `runfiles` | [runfiles](../builtins/runfiles); or `None`; default is `None`  runfiles descriptor describing the files that this target needs when run (via the `run` command or as a tool dependency). |
-| `data_runfiles` | [runfiles](../builtins/runfiles); or `None`; default is `None`  **It is recommended that you avoid using this parameter (see ["runfiles features to avoid"](https://bazel.build/extending/rules#runfiles_features_to_avoid))** runfiles descriptor describing the runfiles this target needs to run when it is a dependency via the `data` attribute. |
-| `default_runfiles` | [runfiles](../builtins/runfiles); or `None`; default is `None`  **It is recommended that you avoid using this parameter (see ["runfiles features to avoid"](https://bazel.build/extending/rules#runfiles_features_to_avoid))** runfiles descriptor describing the runfiles this target needs to run when it is a dependency via any attribute other than the `data` attribute. |
-| `executable` | [File](../builtins/File); or `None`; default is `None`  If this rule is marked [`executable`](../globals/bzl#rule.executable) or [`test`](../globals/bzl#rule.test), this is a [`File`](../builtins/File) object representing the file that should be executed to run the target. By default it is the predeclared output `ctx.outputs.executable` but it is recommended to pass another file (either predeclared or not) explicitly. |
+| `files` | [depset](/versions/8.6.0/rules/lib/builtins/depset); or `None`; default is `None`  A [`depset`](/versions/8.6.0/rules/lib/builtins/depset) of [`File`](/versions/8.6.0/rules/lib/builtins/File) objects representing the default outputs to build when this target is specified on the bazel command line. By default it is all predeclared outputs. |
+| `runfiles` | [runfiles](/versions/8.6.0/rules/lib/builtins/runfiles); or `None`; default is `None`  runfiles descriptor describing the files that this target needs when run (via the `run` command or as a tool dependency). |
+| `data_runfiles` | [runfiles](/versions/8.6.0/rules/lib/builtins/runfiles); or `None`; default is `None`  **It is recommended that you avoid using this parameter (see ["runfiles features to avoid"](https://bazel.build/versions/8.6.0/extending/rules#runfiles_features_to_avoid))** runfiles descriptor describing the runfiles this target needs to run when it is a dependency via the `data` attribute. |
+| `default_runfiles` | [runfiles](/versions/8.6.0/rules/lib/builtins/runfiles); or `None`; default is `None`  **It is recommended that you avoid using this parameter (see ["runfiles features to avoid"](https://bazel.build/versions/8.6.0/extending/rules#runfiles_features_to_avoid))** runfiles descriptor describing the runfiles this target needs to run when it is a dependency via any attribute other than the `data` attribute. |
+| `executable` | [File](/versions/8.6.0/rules/lib/builtins/File); or `None`; default is `None`  If this rule is marked [`executable`](/versions/8.6.0/rules/lib/globals/bzl#rule.executable) or [`test`](/versions/8.6.0/rules/lib/globals/bzl#rule.test), this is a [`File`](/versions/8.6.0/rules/lib/builtins/File) object representing the file that should be executed to run the target. By default it is the predeclared output `ctx.outputs.executable` but it is recommended to pass another file (either predeclared or not) explicitly. |
 
 ## data_runfiles
 
@@ -40,7 +40,7 @@ The `DefaultInfo` constructor.
 runfiles DefaultInfo.data_runfiles
 ```
 
-runfiles descriptor describing the files that this target needs when run in the condition that it is a `data` dependency attribute. Under most circumstances, use the `default_runfiles` parameter instead. See ["runfiles features to avoid"](https://bazel.build/extending/rules#runfiles_features_to_avoid) for details.
+runfiles descriptor describing the files that this target needs when run in the condition that it is a `data` dependency attribute. Under most circumstances, use the `default_runfiles` parameter instead. See ["runfiles features to avoid"](https://bazel.build/versions/8.6.0/extending/rules#runfiles_features_to_avoid) for details.
 May return `None`.
 
 ## default_runfiles
@@ -58,7 +58,7 @@ May return `None`.
 depset DefaultInfo.files
 ```
 
-A [`depset`](../builtins/depset) of [`File`](../builtins/File) objects representing the default outputs to build when this target is specified on the bazel command line. By default it is all predeclared outputs.
+A [`depset`](/versions/8.6.0/rules/lib/builtins/depset) of [`File`](/versions/8.6.0/rules/lib/builtins/File) objects representing the default outputs to build when this target is specified on the bazel command line. By default it is all predeclared outputs.
 May return `None`.
 
 ## files_to_run
@@ -67,5 +67,5 @@ May return `None`.
 FilesToRunProvider DefaultInfo.files_to_run
 ```
 
-A [`FilesToRunProvider`](../providers/FilesToRunProvider) object containing information about the executable and runfiles of the target.
+A [`FilesToRunProvider`](/versions/8.6.0/rules/lib/providers/FilesToRunProvider) object containing information about the executable and runfiles of the target.
 May return `None`.
\ No newline at end of file
diff --git a/versions/8.6.0/rules/lib/providers/ExecutionInfo.mdx b/versions/8.6.0/rules/lib/providers/ExecutionInfo.mdx
index 5f46846a..a48efc98 100644
--- a/versions/8.6.0/rules/lib/providers/ExecutionInfo.mdx
+++ b/versions/8.6.0/rules/lib/providers/ExecutionInfo.mdx
@@ -22,8 +22,8 @@ Creates an instance.
 
 | Parameter | Description |
 | --- | --- |
-| `requirements` | [dict](../core/dict); default is `{}`  A dict indicating special execution requirements, such as hardware platforms. |
-| `exec_group` | [string](../core/string); default is `'test'`  The name of the exec group that is used to execute the test. |
+| `requirements` | [dict](/versions/8.6.0/rules/lib/core/dict); default is `{}`  A dict indicating special execution requirements, such as hardware platforms. |
+| `exec_group` | [string](/versions/8.6.0/rules/lib/core/string); default is `'test'`  The name of the exec group that is used to execute the test. |
 
 ## exec_group
 
diff --git a/versions/8.6.0/rules/lib/providers/FeatureFlagInfo.mdx b/versions/8.6.0/rules/lib/providers/FeatureFlagInfo.mdx
index 971fcbb2..0ba9c81a 100644
--- a/versions/8.6.0/rules/lib/providers/FeatureFlagInfo.mdx
+++ b/versions/8.6.0/rules/lib/providers/FeatureFlagInfo.mdx
@@ -31,7 +31,7 @@ The value of the flag in the configuration used by the flag rule.
 
 | Parameter | Description |
 | --- | --- |
-| `value` | [string](../core/string); required  String, the value to check for validity for this flag. |
+| `value` | [string](/versions/8.6.0/rules/lib/core/string); required  String, the value to check for validity for this flag. |
 
 ## value
 
diff --git a/versions/8.6.0/rules/lib/providers/IncompatiblePlatformProvider.mdx b/versions/8.6.0/rules/lib/providers/IncompatiblePlatformProvider.mdx
index fed57015..d29a6a9b 100644
--- a/versions/8.6.0/rules/lib/providers/IncompatiblePlatformProvider.mdx
+++ b/versions/8.6.0/rules/lib/providers/IncompatiblePlatformProvider.mdx
@@ -2,4 +2,4 @@
 title: 'IncompatiblePlatformProvider'
 ---
 
-A provider for targets that are incompatible with the target platform. See [Detecting incompatible targets using `bazel cquery`](/docs/platforms#detecting-incompatible-targets-using-bazel-cquery) for more information.
\ No newline at end of file
+A provider for targets that are incompatible with the target platform. See [Detecting incompatible targets using `bazel cquery`](/versions/8.6.0/docs/platforms#detecting-incompatible-targets-using-bazel-cquery) for more information.
\ No newline at end of file
diff --git a/versions/8.6.0/rules/lib/providers/InstrumentedFilesInfo.mdx b/versions/8.6.0/rules/lib/providers/InstrumentedFilesInfo.mdx
index a944c94b..64e0a40f 100644
--- a/versions/8.6.0/rules/lib/providers/InstrumentedFilesInfo.mdx
+++ b/versions/8.6.0/rules/lib/providers/InstrumentedFilesInfo.mdx
@@ -2,7 +2,7 @@
 title: 'InstrumentedFilesInfo'
 ---
 
-Contains information about source files and instrumentation metadata files for rule targets matched by [`--instrumentation_filter`](https://bazel.build/reference/command-line-reference#flag--instrumentation_filter) for purposes of [code coverage data collection](https://bazel.build/extending/rules#code_coverage). When coverage data collection is enabled, a manifest containing the combined paths in [`instrumented_files`](#instrumented_files) and [`metadata_files`](#metadata_files) are passed to the test action as inputs, with the manifest's path noted in the environment variable `COVERAGE_MANIFEST`. The metadata files, but not the source files, are also passed to the test action as inputs. When `InstrumentedFilesInfo` is returned by an [aspect](https://bazel.build/rules/aspects)'s implementation function, any `InstrumentedFilesInfo` from the base rule target is ignored.
+Contains information about source files and instrumentation metadata files for rule targets matched by [`--instrumentation_filter`](https://bazel.build/versions/8.6.0/reference/command-line-reference#flag--instrumentation_filter) for purposes of [code coverage data collection](https://bazel.build/versions/8.6.0/extending/rules#code_coverage). When coverage data collection is enabled, a manifest containing the combined paths in [`instrumented_files`](#instrumented_files) and [`metadata_files`](#metadata_files) are passed to the test action as inputs, with the manifest's path noted in the environment variable `COVERAGE_MANIFEST`. The metadata files, but not the source files, are also passed to the test action as inputs. When `InstrumentedFilesInfo` is returned by an [aspect](https://bazel.build/versions/8.6.0/rules/aspects)'s implementation function, any `InstrumentedFilesInfo` from the base rule target is ignored.
 
 ## Members
 
@@ -15,7 +15,7 @@ Contains information about source files and instrumentation metadata files for r
 depset InstrumentedFilesInfo.instrumented_files
 ```
 
-[`depset`](../builtins/depset) of [`File`](../builtins/File) objects representing instrumented source files for this target and its dependencies.
+[`depset`](/versions/8.6.0/rules/lib/builtins/depset) of [`File`](/versions/8.6.0/rules/lib/builtins/File) objects representing instrumented source files for this target and its dependencies.
 
 ## metadata_files
 
@@ -23,4 +23,4 @@ depset InstrumentedFilesInfo.instrumented_files
 depset InstrumentedFilesInfo.metadata_files
 ```
 
-[`depset`](../builtins/depset) of [`File`](../builtins/File) objects representing coverage metadata files for this target and its dependencies. These files contain additional information required to generate LCOV-format coverage output after the code is executed, e.g. the `.gcno` files generated when `gcc` is run with `-ftest-coverage`.
\ No newline at end of file
+[`depset`](/versions/8.6.0/rules/lib/builtins/depset) of [`File`](/versions/8.6.0/rules/lib/builtins/File) objects representing coverage metadata files for this target and its dependencies. These files contain additional information required to generate LCOV-format coverage output after the code is executed, e.g. the `.gcno` files generated when `gcc` is run with `-ftest-coverage`.
\ No newline at end of file
diff --git a/versions/8.6.0/rules/lib/providers/OutputGroupInfo.mdx b/versions/8.6.0/rules/lib/providers/OutputGroupInfo.mdx
index 2d3430fb..ad87f84f 100644
--- a/versions/8.6.0/rules/lib/providers/OutputGroupInfo.mdx
+++ b/versions/8.6.0/rules/lib/providers/OutputGroupInfo.mdx
@@ -3,7 +3,7 @@ title: 'OutputGroupInfo'
 ---
 
 A provider that indicates what output groups a rule has.
-See [Requesting output files](https://bazel.build/extending/rules#requesting_output_files) for more information.
+See [Requesting output files](https://bazel.build/versions/8.6.0/extending/rules#requesting_output_files) for more information.
 
 ## Members
 
@@ -21,7 +21,7 @@ Instantiate this provider with
 OutputGroupInfo(group1 = , group2 = ...)
 ```
 
-See [Requesting output files](https://bazel.build/extending/rules#requesting_output_files)  for more information.
+See [Requesting output files](https://bazel.build/versions/8.6.0/extending/rules#requesting_output_files)  for more information.
 
 ### Parameters
 
diff --git a/versions/8.6.0/rules/lib/providers/PackageSpecificationInfo.mdx b/versions/8.6.0/rules/lib/providers/PackageSpecificationInfo.mdx
index 242a43e6..e38578ae 100644
--- a/versions/8.6.0/rules/lib/providers/PackageSpecificationInfo.mdx
+++ b/versions/8.6.0/rules/lib/providers/PackageSpecificationInfo.mdx
@@ -20,4 +20,4 @@ Checks if a target exists in a package group.
 
 | Parameter | Description |
 | --- | --- |
-| `target` | [Label](../builtins/Label); or [string](../core/string); required  A target which is checked if it exists inside the package group. |
\ No newline at end of file
+| `target` | [Label](/versions/8.6.0/rules/lib/builtins/Label); or [string](/versions/8.6.0/rules/lib/core/string); required  A target which is checked if it exists inside the package group. |
\ No newline at end of file
diff --git a/versions/8.6.0/rules/lib/providers/PlatformInfo.mdx b/versions/8.6.0/rules/lib/providers/PlatformInfo.mdx
index 016507b7..7f90dae5 100644
--- a/versions/8.6.0/rules/lib/providers/PlatformInfo.mdx
+++ b/versions/8.6.0/rules/lib/providers/PlatformInfo.mdx
@@ -2,5 +2,5 @@
 title: 'PlatformInfo'
 ---
 
-Provides access to data about a specific platform. See [Defining Constraints and Platforms](/docs/platforms#constraints-platforms) for more information.
+Provides access to data about a specific platform. See [Defining Constraints and Platforms](/versions/8.6.0/docs/platforms#constraints-platforms) for more information.
 *Note: This API is experimental and may change at any time. It is disabled by default, but may be enabled with `--experimental_platforms_api`*
\ No newline at end of file
diff --git a/versions/8.6.0/rules/lib/providers/ProguardSpecProvider.mdx b/versions/8.6.0/rules/lib/providers/ProguardSpecProvider.mdx
index b7a337c2..0c4066ea 100644
--- a/versions/8.6.0/rules/lib/providers/ProguardSpecProvider.mdx
+++ b/versions/8.6.0/rules/lib/providers/ProguardSpecProvider.mdx
@@ -20,4 +20,4 @@ The `ProguardSpecProvider` constructor.
 
 | Parameter | Description |
 | --- | --- |
-| `specs` | [depset](../builtins/depset) of [File](../builtins/File)s; required  Transitive proguard specs. |
\ No newline at end of file
+| `specs` | [depset](/versions/8.6.0/rules/lib/builtins/depset) of [File](/versions/8.6.0/rules/lib/builtins/File)s; required  Transitive proguard specs. |
\ No newline at end of file
diff --git a/versions/8.6.0/rules/lib/providers/ToolchainInfo.mdx b/versions/8.6.0/rules/lib/providers/ToolchainInfo.mdx
index 7e34d4a2..78b3245d 100644
--- a/versions/8.6.0/rules/lib/providers/ToolchainInfo.mdx
+++ b/versions/8.6.0/rules/lib/providers/ToolchainInfo.mdx
@@ -2,4 +2,4 @@
 title: 'ToolchainInfo'
 ---
 
-Provider returned by [toolchain rules](/docs/toolchains#defining-toolchains) to share data with [rules which depend on toolchains](/docs/toolchains#writing-rules-that-use-toolchains). Read about [toolchains](/docs/toolchains) for more information.
\ No newline at end of file
+Provider returned by [toolchain rules](/versions/8.6.0/docs/toolchains#defining-toolchains) to share data with [rules which depend on toolchains](/versions/8.6.0/docs/toolchains#writing-rules-that-use-toolchains). Read about [toolchains](/versions/8.6.0/docs/toolchains) for more information.
\ No newline at end of file
diff --git a/versions/8.6.0/rules/lib/repo/git.mdx b/versions/8.6.0/rules/lib/repo/git.mdx
index af1cd9e1..02b631f7 100644
--- a/versions/8.6.0/rules/lib/repo/git.mdx
+++ b/versions/8.6.0/rules/lib/repo/git.mdx
@@ -35,14 +35,14 @@ Bazel will first try to perform a shallow fetch of only the specified commit.
 If that fails (usually due to missing server support), it will fall back to a
 full fetch of the repository.
 
-Prefer [`http_archive`](/rules/lib/repo/http#http_archive) to `git_repository`.
+Prefer [`http_archive`](/versions/8.6.0/rules/lib/repo/http#http_archive) to `git_repository`.
 The reasons are:
 
 * Git repository rules depend on system `git(1)` whereas the HTTP downloader is built
   into Bazel and has no system dependencies.
 * `http_archive` supports a list of `urls` as mirrors, and `git_repository` supports only
   a single `remote`.
-* `http_archive` works with the [repository cache](/run/build#repository-cache), but not
+* `http_archive` works with the [repository cache](/versions/8.6.0/run/build#repository-cache), but not
   `git_repository`. See
    [#5116](https://github.com/bazelbuild/bazel/issues/5116) for more information.
 
@@ -58,7 +58,7 @@ The reasons are:
 
name
 
 
-Name; required
+Name; required
 
 

 
@@ -84,7 +84,7 @@ branch in the remote repository to checked out. Precisely one of branch, tag, or
 
build_file
 
 
-Label; optional
+Label; optional
 
 

 
@@ -201,7 +201,7 @@ The patch(1) utility to use. If this is specified, Bazel will use the specified
 
patches
 
 
-List of labels; optional
+List of labels; optional
 
 

 
@@ -266,7 +266,7 @@ For internal use only.
 
repo_mapping
 
 
-Dictionary: String -> String; optional
+Dictionary: String -> String; optional
 
 

 
@@ -296,7 +296,7 @@ an optional date, not after the specified commit; the argument is not allowed if
 
sparse_checkout_file
 
 
-Label; optional
+Label; optional
 
 

 
@@ -356,7 +356,7 @@ Boolean; optional
 
workspace_file
 
 
-Label; optional
+Label; optional
 
 

 
@@ -409,14 +409,14 @@ Bazel will first try to perform a shallow fetch of only the specified commit.
 If that fails (usually due to missing server support), it will fall back to a
 full fetch of the repository.
 
-Prefer [`http_archive`](/rules/lib/repo/http#http_archive) to `git_repository`.
+Prefer [`http_archive`](/versions/8.6.0/rules/lib/repo/http#http_archive) to `git_repository`.
 The reasons are:
 
 * Git repository rules depend on system `git(1)` whereas the HTTP downloader is built
   into Bazel and has no system dependencies.
 * `http_archive` supports a list of `urls` as mirrors, and `git_repository` supports only
   a single `remote`.
-* `http_archive` works with the [repository cache](/run/build#repository-cache), but not
+* `http_archive` works with the [repository cache](/versions/8.6.0/run/build#repository-cache), but not
   `git_repository`. See
    [#5116](https://github.com/bazelbuild/bazel/issues/5116) for more information.
 
@@ -432,7 +432,7 @@ The reasons are:
 
name
 
 
-Name; required
+Name; required
 
 

 
@@ -458,7 +458,7 @@ branch in the remote repository to checked out. Precisely one of branch, tag, or
 
build_file
 
 
-Label; optional
+Label; optional
 
 

 
@@ -575,7 +575,7 @@ The patch(1) utility to use. If this is specified, Bazel will use the specified
 
patches
 
 
-List of labels; optional
+List of labels; optional
 
 

 
@@ -640,7 +640,7 @@ For internal use only.
 
repo_mapping
 
 
-Dictionary: String -> String; optional
+Dictionary: String -> String; optional
 
 

 
@@ -670,7 +670,7 @@ an optional date, not after the specified commit; the argument is not allowed if
 
sparse_checkout_file
 
 
-Label; optional
+Label; optional
 
 

 
@@ -730,7 +730,7 @@ Boolean; optional
 
workspace_file
 
 
-Label; optional
+Label; optional
 
 

 
diff --git a/versions/8.6.0/rules/lib/repo/http.mdx b/versions/8.6.0/rules/lib/repo/http.mdx
index f6719f23..8befd359 100644
--- a/versions/8.6.0/rules/lib/repo/http.mdx
+++ b/versions/8.6.0/rules/lib/repo/http.mdx
@@ -102,7 +102,7 @@ Examples:
 
name
 
 
-Name; required
+Name; required
 
 

 
@@ -133,7 +133,7 @@ and `strip_prefix = "foo-1.2.3"`.
 
auth_patterns
 
 
-Dictionary: String -> String; optional
+Dictionary: String -> String; optional
 
 

 
@@ -176,7 +176,7 @@ Authorization: Bearer RANDOM-TOKEN
 
build_file
 
 
-Label; optional
+Label; optional
 
 

 
@@ -336,7 +336,7 @@ The patch(1) utility to use. If this is specified, Bazel will use the specified
 
patches
 
 
-List of labels; optional
+List of labels; optional
 
 

 
@@ -349,7 +349,7 @@ A list of files that are to be applied as patches after extracting the archive.
 
remote_file_integrity
 
 
-Dictionary: String -> String; optional
+Dictionary: String -> String; optional
 
 

 
@@ -362,7 +362,7 @@ A map of file relative paths (key) to its integrity value (value). These relativ
 
remote_file_urls
 
 
-Dictionary: String -> List of strings; optional
+Dictionary: String -> List of strings; optional
 
 

 
@@ -419,7 +419,7 @@ The number of leading slashes to be stripped from the file name in the remote pa
 
remote_patches
 
 
-Dictionary: String -> String; optional
+Dictionary: String -> String; optional
 
 

 
@@ -432,7 +432,7 @@ A map of patch file URL to its integrity value, they are applied after extractin
 
repo_mapping
 
 
-Dictionary: String -> String; optional
+Dictionary: String -> String; optional
 
 

 
@@ -553,7 +553,7 @@ If all downloads fail, the rule will fail.
 
workspace_file
 
 
-Label; optional
+Label; optional
 
 

 
@@ -627,7 +627,7 @@ Examples:
 
name
 
 
-Name; required
+Name; required
 
 

 
@@ -640,7 +640,7 @@ A unique name for this repository.
 
auth_patterns
 
 
-Dictionary: String -> String; optional
+Dictionary: String -> String; optional
 
 

 
@@ -762,7 +762,7 @@ Location of the .netrc file to use for authentication
 
repo_mapping
 
 
-Dictionary: String -> String; optional
+Dictionary: String -> String; optional
 
 

 
@@ -892,7 +892,7 @@ Examples:
 
name
 
 
-Name; required
+Name; required
 
 

 
@@ -905,7 +905,7 @@ A unique name for this repository.
 
auth_patterns
 
 
-Dictionary: String -> String; optional
+Dictionary: String -> String; optional
 
 

 
@@ -1014,7 +1014,7 @@ Location of the .netrc file to use for authentication
 
repo_mapping
 
 
-Dictionary: String -> String; optional
+Dictionary: String -> String; optional
 
 

 
diff --git a/versions/8.6.0/rules/lib/repo/index.mdx b/versions/8.6.0/rules/lib/repo/index.mdx
index 8b364d2d..da4e3e27 100644
--- a/versions/8.6.0/rules/lib/repo/index.mdx
+++ b/versions/8.6.0/rules/lib/repo/index.mdx
@@ -2,10 +2,10 @@
 title: 'Repository Rules'
 ---
 
-* [Rules related to git](git)
-* [Rules related to http](http)
-* [Rules related to local directories](local)
+* [Rules related to git](/versions/8.6.0/rules/lib/repo/git)
+* [Rules related to http](/versions/8.6.0/rules/lib/repo/http)
+* [Rules related to local directories](/versions/8.6.0/rules/lib/repo/local)
 
 # Generic functions for repository rule authors
 
-* [Utility functions on patching](utils)
+* [Utility functions on patching](/versions/8.6.0/rules/lib/repo/utils)
diff --git a/versions/8.6.0/rules/lib/repo/local.mdx b/versions/8.6.0/rules/lib/repo/local.mdx
index 1220e3a8..9138c881 100644
--- a/versions/8.6.0/rules/lib/repo/local.mdx
+++ b/versions/8.6.0/rules/lib/repo/local.mdx
@@ -53,7 +53,7 @@ Makes a local directory that already contains Bazel files available as a repo. T
 
name
 
 
-Name; required
+Name; required
 
 

 
@@ -81,7 +81,7 @@ The path can be either absolute, or relative to the workspace root.
 
repo_mapping
 
 
-Dictionary: String -> String; optional
+Dictionary: String -> String; optional
 
 

 
@@ -121,7 +121,7 @@ Makes a local directory that doesn't contain Bazel files available as a repo. Th
 
name
 
 
-Name; required
+Name; required
 
 

 
@@ -134,7 +134,7 @@ A unique name for this repository.
 
build_file
 
 
-Label; optional
+Label; optional
 
 

 
@@ -181,7 +181,7 @@ The path can be either absolute, or relative to the workspace root.
 
repo_mapping
 
 
-Dictionary: String -> String; optional
+Dictionary: String -> String; optional
 
 

 
diff --git a/versions/8.6.0/rules/lib/toplevel.mdx b/versions/8.6.0/rules/lib/toplevel.mdx
index 9e7ee1e8..1df60e0e 100644
--- a/versions/8.6.0/rules/lib/toplevel.mdx
+++ b/versions/8.6.0/rules/lib/toplevel.mdx
@@ -4,15 +4,15 @@ title: 'Top-level Modules'
 
 This section lists top-level modules. These symbols are available only in .bzl files.
 
-* [apple_common](/rules/lib/toplevel/apple_common)
-* [attr](/rules/lib/toplevel/attr)
-* [cc_common](/rules/lib/toplevel/cc_common)
-* [config](/rules/lib/toplevel/config)
-* [config_common](/rules/lib/toplevel/config_common)
-* [coverage_common](/rules/lib/toplevel/coverage_common)
-* [java_common](/rules/lib/toplevel/java_common)
-* [native](/rules/lib/toplevel/native)
-* [platform_common](/rules/lib/toplevel/platform_common)
-* [proto](/rules/lib/toplevel/proto)
-* [proto_common](/rules/lib/toplevel/proto_common)
-* [testing](/rules/lib/toplevel/testing)
\ No newline at end of file
+* [apple_common](/versions/8.6.0/rules/lib/toplevel/apple_common)
+* [attr](/versions/8.6.0/rules/lib/toplevel/attr)
+* [cc_common](/versions/8.6.0/rules/lib/toplevel/cc_common)
+* [config](/versions/8.6.0/rules/lib/toplevel/config)
+* [config_common](/versions/8.6.0/rules/lib/toplevel/config_common)
+* [coverage_common](/versions/8.6.0/rules/lib/toplevel/coverage_common)
+* [java_common](/versions/8.6.0/rules/lib/toplevel/java_common)
+* [native](/versions/8.6.0/rules/lib/toplevel/native)
+* [platform_common](/versions/8.6.0/rules/lib/toplevel/platform_common)
+* [proto](/versions/8.6.0/rules/lib/toplevel/proto)
+* [proto_common](/versions/8.6.0/rules/lib/toplevel/proto_common)
+* [testing](/versions/8.6.0/rules/lib/toplevel/testing)
\ No newline at end of file
diff --git a/versions/8.6.0/rules/lib/toplevel/apple_common.mdx b/versions/8.6.0/rules/lib/toplevel/apple_common.mdx
index 0024fb88..845dad9a 100644
--- a/versions/8.6.0/rules/lib/toplevel/apple_common.mdx
+++ b/versions/8.6.0/rules/lib/toplevel/apple_common.mdx
@@ -21,7 +21,7 @@ Functions for Starlark to access internals of the apple rule implementations.
 dict apple_common.apple_host_system_env(xcode_config)
 ```
 
-Returns a [dict](../core/dict) of environment variables that should be set for actions that need to run build tools on an Apple host system, such as the version of Xcode that should be used. The keys are variable names and the values are their corresponding values.
+Returns a [dict](/versions/8.6.0/rules/lib/core/dict) of environment variables that should be set for actions that need to run build tools on an Apple host system, such as the version of Xcode that should be used. The keys are variable names and the values are their corresponding values.
 
 ### Parameters
 
@@ -43,13 +43,13 @@ Utilities for resolving items from the apple toolchain.
 DottedVersion apple_common.dotted_version(version)
 ```
 
-Creates a new [DottedVersion](../builtins/DottedVersion) instance.
+Creates a new [DottedVersion](/versions/8.6.0/rules/lib/builtins/DottedVersion) instance.
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `version` | [string](../core/string); required  The string representation of the DottedVersion. |
+| `version` | [string](/versions/8.6.0/rules/lib/core/string); required  The string representation of the DottedVersion. |
 
 ## platform
 
@@ -69,7 +69,7 @@ An enum-like struct that contains the following fields corresponding to Apple pl
 * `watchos_device`
 * `watchos_simulator`
 
-These values can be passed to methods that expect a platform, like [XcodeVersionConfig.sdk_version_for_platform](../providers/XcodeVersionConfig#sdk_version_for_platform).
+These values can be passed to methods that expect a platform, like [XcodeVersionConfig.sdk_version_for_platform](/versions/8.6.0/rules/lib/providers/XcodeVersionConfig#sdk_version_for_platform).
 
 ## platform_type
 
@@ -85,7 +85,7 @@ An enum-like struct that contains the following fields corresponding to Apple pl
 * `visionos`
 * `watchos`
 
-These values can be passed to methods that expect a platform type, like the 'apple' configuration fragment's [multi_arch_platform](../fragments/apple#multi_arch_platform) method.
+These values can be passed to methods that expect a platform type, like the 'apple' configuration fragment's [multi_arch_platform](/versions/8.6.0/rules/lib/fragments/apple#multi_arch_platform) method.
 
 Example:
 
diff --git a/versions/8.6.0/rules/lib/toplevel/attr.mdx b/versions/8.6.0/rules/lib/toplevel/attr.mdx
index dc830a07..80219051 100644
--- a/versions/8.6.0/rules/lib/toplevel/attr.mdx
+++ b/versions/8.6.0/rules/lib/toplevel/attr.mdx
@@ -2,10 +2,10 @@
 title: 'attr'
 ---
 
-This is a top-level module for defining the attribute schemas of a rule or aspect. Each function returns an object representing the schema of a single attribute. These objects are used as the values of the `attrs` dictionary argument of [`rule()`](../globals/bzl#rule), [`aspect()`](../globals/bzl#aspect), [`repository_rule()`](../globals/bzl#repository_rule) and [`tag_class()`](../globals/bzl#tag_class).
+This is a top-level module for defining the attribute schemas of a rule or aspect. Each function returns an object representing the schema of a single attribute. These objects are used as the values of the `attrs` dictionary argument of [`rule()`](/versions/8.6.0/rules/lib/globals/bzl#rule), [`aspect()`](/versions/8.6.0/rules/lib/globals/bzl#aspect), [`repository_rule()`](/versions/8.6.0/rules/lib/globals/bzl#repository_rule) and [`tag_class()`](/versions/8.6.0/rules/lib/globals/bzl#tag_class).
 
-See the Rules page for more on [defining](https://bazel.build/extending/rules#attributes)
-and [using](https://bazel.build/extending/rules#implementation_function) attributes.
+See the Rules page for more on [defining](https://bazel.build/versions/8.6.0/extending/rules#attributes)
+and [using](https://bazel.build/versions/8.6.0/extending/rules#implementation_function) attributes.
 
 ## Members
 
@@ -29,16 +29,16 @@ and [using](https://bazel.build/extending/rules#implementation_function) attribu
 Attribute attr.bool(configurable=unbound, default=False, doc=None, mandatory=False)
 ```
 
-Creates a schema for a boolean attribute. The corresponding [`ctx.attr`](../builtins/ctx#attr) attribute will be of type [`bool`](../core/bool).
+Creates a schema for a boolean attribute. The corresponding [`ctx.attr`](/versions/8.6.0/rules/lib/builtins/ctx#attr) attribute will be of type [`bool`](/versions/8.6.0/rules/lib/core/bool).
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `configurable` | [bool](../core/bool); or unbound; default is `unbound`  This argument can only be specified for an attribute of a symbolic macro. If `configurable` is explicitly set to `False`, the symbolic macro attribute is non-configurable - in other words, it cannot take a `select()` value. If the `configurable` is either unbound or explicitly set to `True`, the attribute is configurable and can take a `select()` value. For an attribute of a rule or aspect, `configurable` must be left unbound. Most Starlark rule attributes are always configurable, with the exception of `attr.output()`, `attr.output_list()`, and `attr.license()` rule attributes, which are always non-configurable. |
-| `default` | [bool](../core/bool); default is `False`  A default value to use if no value for this attribute is given when instantiating the rule. |
-| `doc` | [string](../core/string); or `None`; default is `None`  A description of the attribute that can be extracted by documentation generating tools. |
-| `mandatory` | [bool](../core/bool); default is `False`  If true, the value must be specified explicitly (even if it has a `default`). |
+| `configurable` | [bool](/versions/8.6.0/rules/lib/core/bool); or unbound; default is `unbound`  This argument can only be specified for an attribute of a symbolic macro. If `configurable` is explicitly set to `False`, the symbolic macro attribute is non-configurable - in other words, it cannot take a `select()` value. If the `configurable` is either unbound or explicitly set to `True`, the attribute is configurable and can take a `select()` value. For an attribute of a rule or aspect, `configurable` must be left unbound. Most Starlark rule attributes are always configurable, with the exception of `attr.output()`, `attr.output_list()`, and `attr.license()` rule attributes, which are always non-configurable. |
+| `default` | [bool](/versions/8.6.0/rules/lib/core/bool); default is `False`  A default value to use if no value for this attribute is given when instantiating the rule. |
+| `doc` | [string](/versions/8.6.0/rules/lib/core/string); or `None`; default is `None`  A description of the attribute that can be extracted by documentation generating tools. |
+| `mandatory` | [bool](/versions/8.6.0/rules/lib/core/bool); default is `False`  If true, the value must be specified explicitly (even if it has a `default`). |
 
 ## int
 
@@ -46,17 +46,17 @@ Creates a schema for a boolean attribute. The corresponding [`ctx.attr`](../buil
 Attribute attr.int(configurable=unbound, default=0, doc=None, mandatory=False, values=[])
 ```
 
-Creates a schema for an integer attribute. The value must be in the signed 32-bit range. The corresponding [`ctx.attr`](../builtins/ctx#attr) attribute will be of type [`int`](../core/int).
+Creates a schema for an integer attribute. The value must be in the signed 32-bit range. The corresponding [`ctx.attr`](/versions/8.6.0/rules/lib/builtins/ctx#attr) attribute will be of type [`int`](/versions/8.6.0/rules/lib/core/int).
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `configurable` | [bool](../core/bool); or unbound; default is `unbound`  This argument can only be specified for an attribute of a symbolic macro. If `configurable` is explicitly set to `False`, the symbolic macro attribute is non-configurable - in other words, it cannot take a `select()` value. If the `configurable` is either unbound or explicitly set to `True`, the attribute is configurable and can take a `select()` value. For an attribute of a rule or aspect, `configurable` must be left unbound. Most Starlark rule attributes are always configurable, with the exception of `attr.output()`, `attr.output_list()`, and `attr.license()` rule attributes, which are always non-configurable. |
-| `default` | [int](../core/int); default is `0`  A default value to use if no value for this attribute is given when instantiating the rule. |
-| `doc` | [string](../core/string); or `None`; default is `None`  A description of the attribute that can be extracted by documentation generating tools. |
-| `mandatory` | [bool](../core/bool); default is `False`  If true, the value must be specified explicitly (even if it has a `default`). |
-| `values` | [sequence](../core/list) of [int](../core/int)s; default is `[]`  The list of allowed values for the attribute. An error is raised if any other value is given. |
+| `configurable` | [bool](/versions/8.6.0/rules/lib/core/bool); or unbound; default is `unbound`  This argument can only be specified for an attribute of a symbolic macro. If `configurable` is explicitly set to `False`, the symbolic macro attribute is non-configurable - in other words, it cannot take a `select()` value. If the `configurable` is either unbound or explicitly set to `True`, the attribute is configurable and can take a `select()` value. For an attribute of a rule or aspect, `configurable` must be left unbound. Most Starlark rule attributes are always configurable, with the exception of `attr.output()`, `attr.output_list()`, and `attr.license()` rule attributes, which are always non-configurable. |
+| `default` | [int](/versions/8.6.0/rules/lib/core/int); default is `0`  A default value to use if no value for this attribute is given when instantiating the rule. |
+| `doc` | [string](/versions/8.6.0/rules/lib/core/string); or `None`; default is `None`  A description of the attribute that can be extracted by documentation generating tools. |
+| `mandatory` | [bool](/versions/8.6.0/rules/lib/core/bool); default is `False`  If true, the value must be specified explicitly (even if it has a `default`). |
+| `values` | [sequence](/versions/8.6.0/rules/lib/core/list) of [int](/versions/8.6.0/rules/lib/core/int)s; default is `[]`  The list of allowed values for the attribute. An error is raised if any other value is given. |
 
 ## int_list
 
@@ -70,11 +70,11 @@ Creates a schema for a list-of-integers attribute. Each element must be in the s
 
 | Parameter | Description |
 | --- | --- |
-| `mandatory` | [bool](../core/bool); default is `False`  If true, the value must be specified explicitly (even if it has a `default`). |
-| `allow_empty` | [bool](../core/bool); default is `True`  True if the attribute can be empty. |
-| `configurable` | [bool](../core/bool); or unbound; default is `unbound`  This argument can only be specified for an attribute of a symbolic macro. If `configurable` is explicitly set to `False`, the symbolic macro attribute is non-configurable - in other words, it cannot take a `select()` value. If the `configurable` is either unbound or explicitly set to `True`, the attribute is configurable and can take a `select()` value. For an attribute of a rule or aspect, `configurable` must be left unbound. Most Starlark rule attributes are always configurable, with the exception of `attr.output()`, `attr.output_list()`, and `attr.license()` rule attributes, which are always non-configurable. |
-| `default` | [sequence](../core/list) of [int](../core/int)s; default is `[]`  A default value to use if no value for this attribute is given when instantiating the rule. |
-| `doc` | [string](../core/string); or `None`; default is `None`  A description of the attribute that can be extracted by documentation generating tools. |
+| `mandatory` | [bool](/versions/8.6.0/rules/lib/core/bool); default is `False`  If true, the value must be specified explicitly (even if it has a `default`). |
+| `allow_empty` | [bool](/versions/8.6.0/rules/lib/core/bool); default is `True`  True if the attribute can be empty. |
+| `configurable` | [bool](/versions/8.6.0/rules/lib/core/bool); or unbound; default is `unbound`  This argument can only be specified for an attribute of a symbolic macro. If `configurable` is explicitly set to `False`, the symbolic macro attribute is non-configurable - in other words, it cannot take a `select()` value. If the `configurable` is either unbound or explicitly set to `True`, the attribute is configurable and can take a `select()` value. For an attribute of a rule or aspect, `configurable` must be left unbound. Most Starlark rule attributes are always configurable, with the exception of `attr.output()`, `attr.output_list()`, and `attr.license()` rule attributes, which are always non-configurable. |
+| `default` | [sequence](/versions/8.6.0/rules/lib/core/list) of [int](/versions/8.6.0/rules/lib/core/int)s; default is `[]`  A default value to use if no value for this attribute is given when instantiating the rule. |
+| `doc` | [string](/versions/8.6.0/rules/lib/core/string); or `None`; default is `None`  A description of the attribute that can be extracted by documentation generating tools. |
 
 ## label
 
@@ -84,31 +84,31 @@ Attribute attr.label(configurable=unbound, default=None, materializer=None, doc=
 
 Creates a schema for a label attribute. This is a dependency attribute.
 
-This attribute contains unique [`Label`](../builtins/Label) values. If a string is supplied in place of a `Label`, it will be converted using the [label constructor](../builtins/Label#Label). The relative parts of the label path, including the (possibly renamed) repository, are resolved with respect to the instantiated target's package.
+This attribute contains unique [`Label`](/versions/8.6.0/rules/lib/builtins/Label) values. If a string is supplied in place of a `Label`, it will be converted using the [label constructor](/versions/8.6.0/rules/lib/builtins/Label#Label). The relative parts of the label path, including the (possibly renamed) repository, are resolved with respect to the instantiated target's package.
 
-At analysis time (within the rule's implementation function), when retrieving the attribute value from `ctx.attr`, labels are replaced by the corresponding [`Target`](../builtins/Target)s. This allows you to access the providers of the current target's dependencies.
+At analysis time (within the rule's implementation function), when retrieving the attribute value from `ctx.attr`, labels are replaced by the corresponding [`Target`](/versions/8.6.0/rules/lib/builtins/Target)s. This allows you to access the providers of the current target's dependencies.
 
-In addition to ordinary source files, this kind of attribute is often used to refer to a tool -- for example, a compiler. Such tools are considered to be dependencies, just like source files. To avoid requiring users to specify the tool's label every time they use the rule in their BUILD files, you can hard-code the label of a canonical tool as the `default` value of this attribute. If you also want to prevent users from overriding this default, you can make the attribute private by giving it a name that starts with an underscore. See the [Rules](https://bazel.build/extending/rules#private-attributes) page for more information.
+In addition to ordinary source files, this kind of attribute is often used to refer to a tool -- for example, a compiler. Such tools are considered to be dependencies, just like source files. To avoid requiring users to specify the tool's label every time they use the rule in their BUILD files, you can hard-code the label of a canonical tool as the `default` value of this attribute. If you also want to prevent users from overriding this default, you can make the attribute private by giving it a name that starts with an underscore. See the [Rules](https://bazel.build/versions/8.6.0/extending/rules#private-attributes) page for more information.
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `configurable` | [bool](../core/bool); or unbound; default is `unbound`  This argument can only be specified for an attribute of a symbolic macro. If `configurable` is explicitly set to `False`, the symbolic macro attribute is non-configurable - in other words, it cannot take a `select()` value. If the `configurable` is either unbound or explicitly set to `True`, the attribute is configurable and can take a `select()` value. For an attribute of a rule or aspect, `configurable` must be left unbound. Most Starlark rule attributes are always configurable, with the exception of `attr.output()`, `attr.output_list()`, and `attr.license()` rule attributes, which are always non-configurable. |
-| `default` | [Label](../builtins/Label); or [string](../core/string); or [LateBoundDefault](../builtins/LateBoundDefault); or NativeComputedDefault; or [function](../core/function); or `None`; default is `None`  A default value to use if no value for this attribute is given when instantiating the rule.Use a string or the [`Label`](../builtins/Label#Label) function to specify a default value, for example, `attr.label(default = "//a:b")`. |
-| `materializer` | [function](../core/function); default is `None`  **Experimental**. This parameter is experimental and may change at any time. Please do not depend on it. It may be enabled on an experimental basis by setting `--experimental_dormant_deps`  If set, the attribute materializes dormant dependencies from the transitive closure. The value of this parameter must be a functon that gets access to the values of the attributes of the rule that either are not dependencies or are marked as available for dependency resolution. It must return either a dormant dependency or a list of them depending on the type of the attribute |
-| `doc` | [string](../core/string); or `None`; default is `None` |
-| `executable` | [bool](../core/bool); default is `False`  True if the dependency has to be executable. This means the label must refer to an executable file, or to a rule that outputs an executable file. Access the label with `ctx.executable.<attribute_name>`. |
-| `allow_files` | [bool](../core/bool); or [sequence](../core/list) of [string](../core/string)s; or `None`; default is `None`  Whether `File` targets are allowed. Can be `True`, `False` (default), or a list of file extensions that are allowed (for example, `[".cc", ".cpp"]`). |
-| `allow_single_file` | default is `None`  This is similar to `allow_files`, with the restriction that the label must correspond to a single [File](../builtins/File). Access it through `ctx.file.<attribute_name>`. |
-| `mandatory` | [bool](../core/bool); default is `False`  If true, the value must be specified explicitly (even if it has a `default`). |
-| `skip_validations` | [bool](../core/bool); default is `False`  If true, validation actions of transitive dependencies from this attribute will not run. This is a temporary mitigation and WILL be removed in the future. |
-| `providers` | [sequence](../core/list); default is `[]`  The providers that must be given by any dependency appearing in this attribute. The format of this argument is a list of lists of providers -- `*Info` objects returned by [`provider()`](../globals/bzl#provider) (or in the case of a legacy provider, its string name). The dependency must return ALL providers mentioned in at least ONE of the inner lists. As a convenience, this argument may also be a single-level list of providers, in which case it is wrapped in an outer list with one element. It is NOT required that the rule of the dependency advertises those providers in its `provides` parameter, however, it is considered best practice. |
+| `configurable` | [bool](/versions/8.6.0/rules/lib/core/bool); or unbound; default is `unbound`  This argument can only be specified for an attribute of a symbolic macro. If `configurable` is explicitly set to `False`, the symbolic macro attribute is non-configurable - in other words, it cannot take a `select()` value. If the `configurable` is either unbound or explicitly set to `True`, the attribute is configurable and can take a `select()` value. For an attribute of a rule or aspect, `configurable` must be left unbound. Most Starlark rule attributes are always configurable, with the exception of `attr.output()`, `attr.output_list()`, and `attr.license()` rule attributes, which are always non-configurable. |
+| `default` | [Label](/versions/8.6.0/rules/lib/builtins/Label); or [string](/versions/8.6.0/rules/lib/core/string); or [LateBoundDefault](/versions/8.6.0/rules/lib/builtins/LateBoundDefault); or NativeComputedDefault; or [function](/versions/8.6.0/rules/lib/core/function); or `None`; default is `None`  A default value to use if no value for this attribute is given when instantiating the rule.Use a string or the [`Label`](/versions/8.6.0/rules/lib/builtins/Label#Label) function to specify a default value, for example, `attr.label(default = "//a:b")`. |
+| `materializer` | [function](/versions/8.6.0/rules/lib/core/function); default is `None`  **Experimental**. This parameter is experimental and may change at any time. Please do not depend on it. It may be enabled on an experimental basis by setting `--experimental_dormant_deps`  If set, the attribute materializes dormant dependencies from the transitive closure. The value of this parameter must be a functon that gets access to the values of the attributes of the rule that either are not dependencies or are marked as available for dependency resolution. It must return either a dormant dependency or a list of them depending on the type of the attribute |
+| `doc` | [string](/versions/8.6.0/rules/lib/core/string); or `None`; default is `None` |
+| `executable` | [bool](/versions/8.6.0/rules/lib/core/bool); default is `False`  True if the dependency has to be executable. This means the label must refer to an executable file, or to a rule that outputs an executable file. Access the label with `ctx.executable.<attribute_name>`. |
+| `allow_files` | [bool](/versions/8.6.0/rules/lib/core/bool); or [sequence](/versions/8.6.0/rules/lib/core/list) of [string](/versions/8.6.0/rules/lib/core/string)s; or `None`; default is `None`  Whether `File` targets are allowed. Can be `True`, `False` (default), or a list of file extensions that are allowed (for example, `[".cc", ".cpp"]`). |
+| `allow_single_file` | default is `None`  This is similar to `allow_files`, with the restriction that the label must correspond to a single [File](/versions/8.6.0/rules/lib/builtins/File). Access it through `ctx.file.<attribute_name>`. |
+| `mandatory` | [bool](/versions/8.6.0/rules/lib/core/bool); default is `False`  If true, the value must be specified explicitly (even if it has a `default`). |
+| `skip_validations` | [bool](/versions/8.6.0/rules/lib/core/bool); default is `False`  If true, validation actions of transitive dependencies from this attribute will not run. This is a temporary mitigation and WILL be removed in the future. |
+| `providers` | [sequence](/versions/8.6.0/rules/lib/core/list); default is `[]`  The providers that must be given by any dependency appearing in this attribute. The format of this argument is a list of lists of providers -- `*Info` objects returned by [`provider()`](/versions/8.6.0/rules/lib/globals/bzl#provider) (or in the case of a legacy provider, its string name). The dependency must return ALL providers mentioned in at least ONE of the inner lists. As a convenience, this argument may also be a single-level list of providers, in which case it is wrapped in an outer list with one element. It is NOT required that the rule of the dependency advertises those providers in its `provides` parameter, however, it is considered best practice. |
 | `for_dependency_resolution` | default is `unbound`  If this is set, the attribute is available for materializers. Only rules marked with the flag of the same name are allowed to be referenced through such attributes. |
-| `allow_rules` | [sequence](../core/list) of [string](../core/string)s; or `None`; default is `None`  Which rule targets (name of the classes) are allowed. This is deprecated (kept only for compatibility), use providers instead. |
-| `cfg` | default is `None`  [Configuration](https://bazel.build/extending/rules#configurations) of the attribute. It can be either `"exec"`, which indicates that the dependency is built for the `execution platform`, or `"target"`, which indicates that the dependency is build for the `target platform`. A typical example of the difference is when building mobile apps, where the `target platform` is `Android` or `iOS` while the `execution platform` is `Linux`, `macOS`, or `Windows`. This parameter is required if `executable` is True to guard against accidentally building host tools in the target configuration. `"target"` has no semantic effect, so don't set it when `executable` is False unless it really helps clarify your intentions. |
-| `aspects` | [sequence](../core/list) of [Aspect](../builtins/Aspect)s; default is `[]`  Aspects that should be applied to the dependency or dependencies specified by this attribute. |
-| `flags` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  Deprecated, will be removed. |
+| `allow_rules` | [sequence](/versions/8.6.0/rules/lib/core/list) of [string](/versions/8.6.0/rules/lib/core/string)s; or `None`; default is `None`  Which rule targets (name of the classes) are allowed. This is deprecated (kept only for compatibility), use providers instead. |
+| `cfg` | default is `None`  [Configuration](https://bazel.build/versions/8.6.0/extending/rules#configurations) of the attribute. It can be either `"exec"`, which indicates that the dependency is built for the `execution platform`, or `"target"`, which indicates that the dependency is build for the `target platform`. A typical example of the difference is when building mobile apps, where the `target platform` is `Android` or `iOS` while the `execution platform` is `Linux`, `macOS`, or `Windows`. This parameter is required if `executable` is True to guard against accidentally building host tools in the target configuration. `"target"` has no semantic effect, so don't set it when `executable` is False unless it really helps clarify your intentions. |
+| `aspects` | [sequence](/versions/8.6.0/rules/lib/core/list) of [Aspect](/versions/8.6.0/rules/lib/builtins/Aspect)s; default is `[]`  Aspects that should be applied to the dependency or dependencies specified by this attribute. |
+| `flags` | [sequence](/versions/8.6.0/rules/lib/core/list) of [string](/versions/8.6.0/rules/lib/core/string)s; default is `[]`  Deprecated, will be removed. |
 
 ## label_keyed_string_dict
 
@@ -118,26 +118,26 @@ Attribute attr.label_keyed_string_dict(allow_empty=True, *, configurable=unbound
 
 Creates a schema for an attribute holding a dictionary, where the keys are labels and the values are strings. This is a dependency attribute.
 
-This attribute contains unique [`Label`](../builtins/Label) values. If a string is supplied in place of a `Label`, it will be converted using the [label constructor](../builtins/Label#Label). The relative parts of the label path, including the (possibly renamed) repository, are resolved with respect to the instantiated target's package.
+This attribute contains unique [`Label`](/versions/8.6.0/rules/lib/builtins/Label) values. If a string is supplied in place of a `Label`, it will be converted using the [label constructor](/versions/8.6.0/rules/lib/builtins/Label#Label). The relative parts of the label path, including the (possibly renamed) repository, are resolved with respect to the instantiated target's package.
 
-At analysis time (within the rule's implementation function), when retrieving the attribute value from `ctx.attr`, labels are replaced by the corresponding [`Target`](../builtins/Target)s. This allows you to access the providers of the current target's dependencies.
+At analysis time (within the rule's implementation function), when retrieving the attribute value from `ctx.attr`, labels are replaced by the corresponding [`Target`](/versions/8.6.0/rules/lib/builtins/Target)s. This allows you to access the providers of the current target's dependencies.
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `allow_empty` | [bool](../core/bool); default is `True`  True if the attribute can be empty. |
-| `configurable` | [bool](../core/bool); or unbound; default is `unbound`  This argument can only be specified for an attribute of a symbolic macro. If `configurable` is explicitly set to `False`, the symbolic macro attribute is non-configurable - in other words, it cannot take a `select()` value. If the `configurable` is either unbound or explicitly set to `True`, the attribute is configurable and can take a `select()` value. For an attribute of a rule or aspect, `configurable` must be left unbound. Most Starlark rule attributes are always configurable, with the exception of `attr.output()`, `attr.output_list()`, and `attr.license()` rule attributes, which are always non-configurable. |
-| `default` | [dict](../core/dict); or [function](../core/function); default is `{}`  A default value to use if no value for this attribute is given when instantiating the rule.Use strings or the [`Label`](../builtins/Label#Label) function to specify default values, for example, `attr.label_keyed_string_dict(default = {"//a:b": "value", "//a:c": "string"})`. |
-| `doc` | [string](../core/string); or `None`; default is `None`  A description of the attribute that can be extracted by documentation generating tools. |
-| `allow_files` | [bool](../core/bool); or [sequence](../core/list) of [string](../core/string)s; or `None`; default is `None`  Whether `File` targets are allowed. Can be `True`, `False` (default), or a list of file extensions that are allowed (for example, `[".cc", ".cpp"]`). |
-| `allow_rules` | [sequence](../core/list) of [string](../core/string)s; or `None`; default is `None`  Which rule targets (name of the classes) are allowed. This is deprecated (kept only for compatibility), use providers instead. |
-| `providers` | [sequence](../core/list); default is `[]`  The providers that must be given by any dependency appearing in this attribute. The format of this argument is a list of lists of providers -- `*Info` objects returned by [`provider()`](../globals/bzl#provider) (or in the case of a legacy provider, its string name). The dependency must return ALL providers mentioned in at least ONE of the inner lists. As a convenience, this argument may also be a single-level list of providers, in which case it is wrapped in an outer list with one element. It is NOT required that the rule of the dependency advertises those providers in its `provides` parameter, however, it is considered best practice. |
+| `allow_empty` | [bool](/versions/8.6.0/rules/lib/core/bool); default is `True`  True if the attribute can be empty. |
+| `configurable` | [bool](/versions/8.6.0/rules/lib/core/bool); or unbound; default is `unbound`  This argument can only be specified for an attribute of a symbolic macro. If `configurable` is explicitly set to `False`, the symbolic macro attribute is non-configurable - in other words, it cannot take a `select()` value. If the `configurable` is either unbound or explicitly set to `True`, the attribute is configurable and can take a `select()` value. For an attribute of a rule or aspect, `configurable` must be left unbound. Most Starlark rule attributes are always configurable, with the exception of `attr.output()`, `attr.output_list()`, and `attr.license()` rule attributes, which are always non-configurable. |
+| `default` | [dict](/versions/8.6.0/rules/lib/core/dict); or [function](/versions/8.6.0/rules/lib/core/function); default is `{}`  A default value to use if no value for this attribute is given when instantiating the rule.Use strings or the [`Label`](/versions/8.6.0/rules/lib/builtins/Label#Label) function to specify default values, for example, `attr.label_keyed_string_dict(default = {"//a:b": "value", "//a:c": "string"})`. |
+| `doc` | [string](/versions/8.6.0/rules/lib/core/string); or `None`; default is `None`  A description of the attribute that can be extracted by documentation generating tools. |
+| `allow_files` | [bool](/versions/8.6.0/rules/lib/core/bool); or [sequence](/versions/8.6.0/rules/lib/core/list) of [string](/versions/8.6.0/rules/lib/core/string)s; or `None`; default is `None`  Whether `File` targets are allowed. Can be `True`, `False` (default), or a list of file extensions that are allowed (for example, `[".cc", ".cpp"]`). |
+| `allow_rules` | [sequence](/versions/8.6.0/rules/lib/core/list) of [string](/versions/8.6.0/rules/lib/core/string)s; or `None`; default is `None`  Which rule targets (name of the classes) are allowed. This is deprecated (kept only for compatibility), use providers instead. |
+| `providers` | [sequence](/versions/8.6.0/rules/lib/core/list); default is `[]`  The providers that must be given by any dependency appearing in this attribute. The format of this argument is a list of lists of providers -- `*Info` objects returned by [`provider()`](/versions/8.6.0/rules/lib/globals/bzl#provider) (or in the case of a legacy provider, its string name). The dependency must return ALL providers mentioned in at least ONE of the inner lists. As a convenience, this argument may also be a single-level list of providers, in which case it is wrapped in an outer list with one element. It is NOT required that the rule of the dependency advertises those providers in its `provides` parameter, however, it is considered best practice. |
 | `for_dependency_resolution` | default is `unbound`  If this is set, the attribute is available for materializers. Only rules marked with the flag of the same name are allowed to be referenced through such attributes. |
-| `flags` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  Deprecated, will be removed. |
-| `mandatory` | [bool](../core/bool); default is `False`  If true, the value must be specified explicitly (even if it has a `default`). |
-| `cfg` | default is `None`  [Configuration](https://bazel.build/extending/rules#configurations) of the attribute. It can be either `"exec"`, which indicates that the dependency is built for the `execution platform`, or `"target"`, which indicates that the dependency is build for the `target platform`. A typical example of the difference is when building mobile apps, where the `target platform` is `Android` or `iOS` while the `execution platform` is `Linux`, `macOS`, or `Windows`. |
-| `aspects` | [sequence](../core/list) of [Aspect](../builtins/Aspect)s; default is `[]`  Aspects that should be applied to the dependency or dependencies specified by this attribute. |
+| `flags` | [sequence](/versions/8.6.0/rules/lib/core/list) of [string](/versions/8.6.0/rules/lib/core/string)s; default is `[]`  Deprecated, will be removed. |
+| `mandatory` | [bool](/versions/8.6.0/rules/lib/core/bool); default is `False`  If true, the value must be specified explicitly (even if it has a `default`). |
+| `cfg` | default is `None`  [Configuration](https://bazel.build/versions/8.6.0/extending/rules#configurations) of the attribute. It can be either `"exec"`, which indicates that the dependency is built for the `execution platform`, or `"target"`, which indicates that the dependency is build for the `target platform`. A typical example of the difference is when building mobile apps, where the `target platform` is `Android` or `iOS` while the `execution platform` is `Linux`, `macOS`, or `Windows`. |
+| `aspects` | [sequence](/versions/8.6.0/rules/lib/core/list) of [Aspect](/versions/8.6.0/rules/lib/builtins/Aspect)s; default is `[]`  Aspects that should be applied to the dependency or dependencies specified by this attribute. |
 
 ## label_list
 
@@ -145,30 +145,30 @@ At analysis time (within the rule's implementation function), when retrieving th
 Attribute attr.label_list(allow_empty=True, *, configurable=unbound, default=[], materializer=None, doc=None, allow_files=None, allow_rules=None, providers=[], for_dependency_resolution=unbound, flags=[], mandatory=False, skip_validations=False, cfg=None, aspects=[])
 ```
 
-Creates a schema for a list-of-labels attribute. This is a dependency attribute. The corresponding [`ctx.attr`](../builtins/ctx#attr) attribute will be of type [list](../core/list) of [`Target`s](../builtins/Target).
+Creates a schema for a list-of-labels attribute. This is a dependency attribute. The corresponding [`ctx.attr`](/versions/8.6.0/rules/lib/builtins/ctx#attr) attribute will be of type [list](/versions/8.6.0/rules/lib/core/list) of [`Target`s](/versions/8.6.0/rules/lib/builtins/Target).
 
-This attribute contains unique [`Label`](../builtins/Label) values. If a string is supplied in place of a `Label`, it will be converted using the [label constructor](../builtins/Label#Label). The relative parts of the label path, including the (possibly renamed) repository, are resolved with respect to the instantiated target's package.
+This attribute contains unique [`Label`](/versions/8.6.0/rules/lib/builtins/Label) values. If a string is supplied in place of a `Label`, it will be converted using the [label constructor](/versions/8.6.0/rules/lib/builtins/Label#Label). The relative parts of the label path, including the (possibly renamed) repository, are resolved with respect to the instantiated target's package.
 
-At analysis time (within the rule's implementation function), when retrieving the attribute value from `ctx.attr`, labels are replaced by the corresponding [`Target`](../builtins/Target)s. This allows you to access the providers of the current target's dependencies.
+At analysis time (within the rule's implementation function), when retrieving the attribute value from `ctx.attr`, labels are replaced by the corresponding [`Target`](/versions/8.6.0/rules/lib/builtins/Target)s. This allows you to access the providers of the current target's dependencies.
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `allow_empty` | [bool](../core/bool); default is `True`  True if the attribute can be empty. |
-| `configurable` | [bool](../core/bool); or unbound; default is `unbound`  This argument can only be specified for an attribute of a symbolic macro. If `configurable` is explicitly set to `False`, the symbolic macro attribute is non-configurable - in other words, it cannot take a `select()` value. If the `configurable` is either unbound or explicitly set to `True`, the attribute is configurable and can take a `select()` value. For an attribute of a rule or aspect, `configurable` must be left unbound. Most Starlark rule attributes are always configurable, with the exception of `attr.output()`, `attr.output_list()`, and `attr.license()` rule attributes, which are always non-configurable. |
-| `default` | [sequence](../core/list) of [Label](../builtins/Label)s; or [function](../core/function); default is `[]`  A default value to use if no value for this attribute is given when instantiating the rule.Use strings or the [`Label`](../builtins/Label#Label) function to specify default values, for example, `attr.label_list(default = ["//a:b", "//a:c"])`. |
-| `materializer` | [function](../core/function); default is `None`  **Experimental**. This parameter is experimental and may change at any time. Please do not depend on it. It may be enabled on an experimental basis by setting `--experimental_dormant_deps`  If set, the attribute materializes dormant dependencies from the transitive closure. The value of this parameter must be a functon that gets access to the values of the attributes of the rule that either are not dependencies or are marked as available for dependency resolution. It must return either a dormant dependency or a list of them depending on the type of the attribute |
-| `doc` | [string](../core/string); or `None`; default is `None` |
-| `allow_files` | [bool](../core/bool); or [sequence](../core/list) of [string](../core/string)s; or `None`; default is `None`  Whether `File` targets are allowed. Can be `True`, `False` (default), or a list of file extensions that are allowed (for example, `[".cc", ".cpp"]`). |
-| `allow_rules` | [sequence](../core/list) of [string](../core/string)s; or `None`; default is `None`  Which rule targets (name of the classes) are allowed. This is deprecated (kept only for compatibility), use providers instead. |
-| `providers` | [sequence](../core/list); default is `[]`  The providers that must be given by any dependency appearing in this attribute. The format of this argument is a list of lists of providers -- `*Info` objects returned by [`provider()`](../globals/bzl#provider) (or in the case of a legacy provider, its string name). The dependency must return ALL providers mentioned in at least ONE of the inner lists. As a convenience, this argument may also be a single-level list of providers, in which case it is wrapped in an outer list with one element. It is NOT required that the rule of the dependency advertises those providers in its `provides` parameter, however, it is considered best practice. |
+| `allow_empty` | [bool](/versions/8.6.0/rules/lib/core/bool); default is `True`  True if the attribute can be empty. |
+| `configurable` | [bool](/versions/8.6.0/rules/lib/core/bool); or unbound; default is `unbound`  This argument can only be specified for an attribute of a symbolic macro. If `configurable` is explicitly set to `False`, the symbolic macro attribute is non-configurable - in other words, it cannot take a `select()` value. If the `configurable` is either unbound or explicitly set to `True`, the attribute is configurable and can take a `select()` value. For an attribute of a rule or aspect, `configurable` must be left unbound. Most Starlark rule attributes are always configurable, with the exception of `attr.output()`, `attr.output_list()`, and `attr.license()` rule attributes, which are always non-configurable. |
+| `default` | [sequence](/versions/8.6.0/rules/lib/core/list) of [Label](/versions/8.6.0/rules/lib/builtins/Label)s; or [function](/versions/8.6.0/rules/lib/core/function); default is `[]`  A default value to use if no value for this attribute is given when instantiating the rule.Use strings or the [`Label`](/versions/8.6.0/rules/lib/builtins/Label#Label) function to specify default values, for example, `attr.label_list(default = ["//a:b", "//a:c"])`. |
+| `materializer` | [function](/versions/8.6.0/rules/lib/core/function); default is `None`  **Experimental**. This parameter is experimental and may change at any time. Please do not depend on it. It may be enabled on an experimental basis by setting `--experimental_dormant_deps`  If set, the attribute materializes dormant dependencies from the transitive closure. The value of this parameter must be a functon that gets access to the values of the attributes of the rule that either are not dependencies or are marked as available for dependency resolution. It must return either a dormant dependency or a list of them depending on the type of the attribute |
+| `doc` | [string](/versions/8.6.0/rules/lib/core/string); or `None`; default is `None` |
+| `allow_files` | [bool](/versions/8.6.0/rules/lib/core/bool); or [sequence](/versions/8.6.0/rules/lib/core/list) of [string](/versions/8.6.0/rules/lib/core/string)s; or `None`; default is `None`  Whether `File` targets are allowed. Can be `True`, `False` (default), or a list of file extensions that are allowed (for example, `[".cc", ".cpp"]`). |
+| `allow_rules` | [sequence](/versions/8.6.0/rules/lib/core/list) of [string](/versions/8.6.0/rules/lib/core/string)s; or `None`; default is `None`  Which rule targets (name of the classes) are allowed. This is deprecated (kept only for compatibility), use providers instead. |
+| `providers` | [sequence](/versions/8.6.0/rules/lib/core/list); default is `[]`  The providers that must be given by any dependency appearing in this attribute. The format of this argument is a list of lists of providers -- `*Info` objects returned by [`provider()`](/versions/8.6.0/rules/lib/globals/bzl#provider) (or in the case of a legacy provider, its string name). The dependency must return ALL providers mentioned in at least ONE of the inner lists. As a convenience, this argument may also be a single-level list of providers, in which case it is wrapped in an outer list with one element. It is NOT required that the rule of the dependency advertises those providers in its `provides` parameter, however, it is considered best practice. |
 | `for_dependency_resolution` | default is `unbound`  If this is set, the attribute is available for materializers. Only rules marked with the flag of the same name are allowed to be referenced through such attributes. |
-| `flags` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  Deprecated, will be removed. |
-| `mandatory` | [bool](../core/bool); default is `False`  If true, the value must be specified explicitly (even if it has a `default`). |
-| `skip_validations` | [bool](../core/bool); default is `False`  If true, validation actions of transitive dependencies from this attribute will not run. This is a temporary mitigation and WILL be removed in the future. |
-| `cfg` | default is `None`  [Configuration](https://bazel.build/extending/rules#configurations) of the attribute. It can be either `"exec"`, which indicates that the dependency is built for the `execution platform`, or `"target"`, which indicates that the dependency is build for the `target platform`. A typical example of the difference is when building mobile apps, where the `target platform` is `Android` or `iOS` while the `execution platform` is `Linux`, `macOS`, or `Windows`. |
-| `aspects` | [sequence](../core/list) of [Aspect](../builtins/Aspect)s; default is `[]`  Aspects that should be applied to the dependency or dependencies specified by this attribute. |
+| `flags` | [sequence](/versions/8.6.0/rules/lib/core/list) of [string](/versions/8.6.0/rules/lib/core/string)s; default is `[]`  Deprecated, will be removed. |
+| `mandatory` | [bool](/versions/8.6.0/rules/lib/core/bool); default is `False`  If true, the value must be specified explicitly (even if it has a `default`). |
+| `skip_validations` | [bool](/versions/8.6.0/rules/lib/core/bool); default is `False`  If true, validation actions of transitive dependencies from this attribute will not run. This is a temporary mitigation and WILL be removed in the future. |
+| `cfg` | default is `None`  [Configuration](https://bazel.build/versions/8.6.0/extending/rules#configurations) of the attribute. It can be either `"exec"`, which indicates that the dependency is built for the `execution platform`, or `"target"`, which indicates that the dependency is build for the `target platform`. A typical example of the difference is when building mobile apps, where the `target platform` is `Android` or `iOS` while the `execution platform` is `Linux`, `macOS`, or `Windows`. |
+| `aspects` | [sequence](/versions/8.6.0/rules/lib/core/list) of [Aspect](/versions/8.6.0/rules/lib/builtins/Aspect)s; default is `[]`  Aspects that should be applied to the dependency or dependencies specified by this attribute. |
 
 ## output
 
@@ -178,16 +178,16 @@ Attribute attr.output(doc=None, mandatory=False)
 
 Creates a schema for an output (label) attribute.
 
-This attribute contains unique [`Label`](../builtins/Label) values. If a string is supplied in place of a `Label`, it will be converted using the [label constructor](../builtins/Label#Label). The relative parts of the label path, including the (possibly renamed) repository, are resolved with respect to the instantiated target's package.
+This attribute contains unique [`Label`](/versions/8.6.0/rules/lib/builtins/Label) values. If a string is supplied in place of a `Label`, it will be converted using the [label constructor](/versions/8.6.0/rules/lib/builtins/Label#Label). The relative parts of the label path, including the (possibly renamed) repository, are resolved with respect to the instantiated target's package.
 
-At analysis time, the corresponding [`File`](../builtins/File) can be retrieved using [`ctx.outputs`](../builtins/ctx#outputs).
+At analysis time, the corresponding [`File`](/versions/8.6.0/rules/lib/builtins/File) can be retrieved using [`ctx.outputs`](/versions/8.6.0/rules/lib/builtins/ctx#outputs).
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `doc` | [string](../core/string); or `None`; default is `None`  A description of the attribute that can be extracted by documentation generating tools. |
-| `mandatory` | [bool](../core/bool); default is `False`  If true, the value must be specified explicitly (even if it has a `default`). |
+| `doc` | [string](/versions/8.6.0/rules/lib/core/string); or `None`; default is `None`  A description of the attribute that can be extracted by documentation generating tools. |
+| `mandatory` | [bool](/versions/8.6.0/rules/lib/core/bool); default is `False`  If true, the value must be specified explicitly (even if it has a `default`). |
 
 ## output_list
 
@@ -197,17 +197,17 @@ Attribute attr.output_list(allow_empty=True, *, doc=None, mandatory=False)
 
 Creates a schema for a list-of-outputs attribute.
 
-This attribute contains unique [`Label`](../builtins/Label) values. If a string is supplied in place of a `Label`, it will be converted using the [label constructor](../builtins/Label#Label). The relative parts of the label path, including the (possibly renamed) repository, are resolved with respect to the instantiated target's package.
+This attribute contains unique [`Label`](/versions/8.6.0/rules/lib/builtins/Label) values. If a string is supplied in place of a `Label`, it will be converted using the [label constructor](/versions/8.6.0/rules/lib/builtins/Label#Label). The relative parts of the label path, including the (possibly renamed) repository, are resolved with respect to the instantiated target's package.
 
-At analysis time, the corresponding [`File`](../builtins/File) can be retrieved using [`ctx.outputs`](../builtins/ctx#outputs).
+At analysis time, the corresponding [`File`](/versions/8.6.0/rules/lib/builtins/File) can be retrieved using [`ctx.outputs`](/versions/8.6.0/rules/lib/builtins/ctx#outputs).
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `allow_empty` | [bool](../core/bool); default is `True`  True if the attribute can be empty. |
-| `doc` | [string](../core/string); or `None`; default is `None`  A description of the attribute that can be extracted by documentation generating tools. |
-| `mandatory` | [bool](../core/bool); default is `False`  If true, the value must be specified explicitly (even if it has a `default`). |
+| `allow_empty` | [bool](/versions/8.6.0/rules/lib/core/bool); default is `True`  True if the attribute can be empty. |
+| `doc` | [string](/versions/8.6.0/rules/lib/core/string); or `None`; default is `None`  A description of the attribute that can be extracted by documentation generating tools. |
+| `mandatory` | [bool](/versions/8.6.0/rules/lib/core/bool); default is `False`  If true, the value must be specified explicitly (even if it has a `default`). |
 
 ## string
 
@@ -215,17 +215,17 @@ At analysis time, the corresponding [`File`](../builtins/File) can be retrieved
 Attribute attr.string(configurable=unbound, default='', doc=None, mandatory=False, values=[])
 ```
 
-Creates a schema for a [string](../core/string#attr) attribute.
+Creates a schema for a [string](/versions/8.6.0/rules/lib/core/string#attr) attribute.
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `configurable` | [bool](../core/bool); or unbound; default is `unbound`  This argument can only be specified for an attribute of a symbolic macro. If `configurable` is explicitly set to `False`, the symbolic macro attribute is non-configurable - in other words, it cannot take a `select()` value. If the `configurable` is either unbound or explicitly set to `True`, the attribute is configurable and can take a `select()` value. For an attribute of a rule or aspect, `configurable` must be left unbound. Most Starlark rule attributes are always configurable, with the exception of `attr.output()`, `attr.output_list()`, and `attr.license()` rule attributes, which are always non-configurable. |
-| `default` | [string](../core/string); or NativeComputedDefault; default is `''`  A default value to use if no value for this attribute is given when instantiating the rule. |
-| `doc` | [string](../core/string); or `None`; default is `None`  A description of the attribute that can be extracted by documentation generating tools. |
-| `mandatory` | [bool](../core/bool); default is `False`  If true, the value must be specified explicitly (even if it has a `default`). |
-| `values` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  The list of allowed values for the attribute. An error is raised if any other value is given. |
+| `configurable` | [bool](/versions/8.6.0/rules/lib/core/bool); or unbound; default is `unbound`  This argument can only be specified for an attribute of a symbolic macro. If `configurable` is explicitly set to `False`, the symbolic macro attribute is non-configurable - in other words, it cannot take a `select()` value. If the `configurable` is either unbound or explicitly set to `True`, the attribute is configurable and can take a `select()` value. For an attribute of a rule or aspect, `configurable` must be left unbound. Most Starlark rule attributes are always configurable, with the exception of `attr.output()`, `attr.output_list()`, and `attr.license()` rule attributes, which are always non-configurable. |
+| `default` | [string](/versions/8.6.0/rules/lib/core/string); or NativeComputedDefault; default is `''`  A default value to use if no value for this attribute is given when instantiating the rule. |
+| `doc` | [string](/versions/8.6.0/rules/lib/core/string); or `None`; default is `None`  A description of the attribute that can be extracted by documentation generating tools. |
+| `mandatory` | [bool](/versions/8.6.0/rules/lib/core/bool); default is `False`  If true, the value must be specified explicitly (even if it has a `default`). |
+| `values` | [sequence](/versions/8.6.0/rules/lib/core/list) of [string](/versions/8.6.0/rules/lib/core/string)s; default is `[]`  The list of allowed values for the attribute. An error is raised if any other value is given. |
 
 ## string_dict
 
@@ -239,11 +239,11 @@ Creates a schema for an attribute holding a dictionary, where the keys and value
 
 | Parameter | Description |
 | --- | --- |
-| `allow_empty` | [bool](../core/bool); default is `True`  True if the attribute can be empty. |
-| `configurable` | [bool](../core/bool); or unbound; default is `unbound`  This argument can only be specified for an attribute of a symbolic macro. If `configurable` is explicitly set to `False`, the symbolic macro attribute is non-configurable - in other words, it cannot take a `select()` value. If the `configurable` is either unbound or explicitly set to `True`, the attribute is configurable and can take a `select()` value. For an attribute of a rule or aspect, `configurable` must be left unbound. Most Starlark rule attributes are always configurable, with the exception of `attr.output()`, `attr.output_list()`, and `attr.license()` rule attributes, which are always non-configurable. |
-| `default` | [dict](../core/dict); default is `{}`  A default value to use if no value for this attribute is given when instantiating the rule. |
-| `doc` | [string](../core/string); or `None`; default is `None`  A description of the attribute that can be extracted by documentation generating tools. |
-| `mandatory` | [bool](../core/bool); default is `False`  If true, the value must be specified explicitly (even if it has a `default`). |
+| `allow_empty` | [bool](/versions/8.6.0/rules/lib/core/bool); default is `True`  True if the attribute can be empty. |
+| `configurable` | [bool](/versions/8.6.0/rules/lib/core/bool); or unbound; default is `unbound`  This argument can only be specified for an attribute of a symbolic macro. If `configurable` is explicitly set to `False`, the symbolic macro attribute is non-configurable - in other words, it cannot take a `select()` value. If the `configurable` is either unbound or explicitly set to `True`, the attribute is configurable and can take a `select()` value. For an attribute of a rule or aspect, `configurable` must be left unbound. Most Starlark rule attributes are always configurable, with the exception of `attr.output()`, `attr.output_list()`, and `attr.license()` rule attributes, which are always non-configurable. |
+| `default` | [dict](/versions/8.6.0/rules/lib/core/dict); default is `{}`  A default value to use if no value for this attribute is given when instantiating the rule. |
+| `doc` | [string](/versions/8.6.0/rules/lib/core/string); or `None`; default is `None`  A description of the attribute that can be extracted by documentation generating tools. |
+| `mandatory` | [bool](/versions/8.6.0/rules/lib/core/bool); default is `False`  If true, the value must be specified explicitly (even if it has a `default`). |
 
 ## string_keyed_label_dict
 
@@ -253,26 +253,26 @@ Attribute attr.string_keyed_label_dict(allow_empty=True, *, configurable=unbound
 
 Creates a schema for an attribute whose value is a dictionary where the keys are strings and the values are labels. This is a dependency attribute.
 
-This attribute contains unique [`Label`](../builtins/Label) values. If a string is supplied in place of a `Label`, it will be converted using the [label constructor](../builtins/Label#Label). The relative parts of the label path, including the (possibly renamed) repository, are resolved with respect to the instantiated target's package.
+This attribute contains unique [`Label`](/versions/8.6.0/rules/lib/builtins/Label) values. If a string is supplied in place of a `Label`, it will be converted using the [label constructor](/versions/8.6.0/rules/lib/builtins/Label#Label). The relative parts of the label path, including the (possibly renamed) repository, are resolved with respect to the instantiated target's package.
 
-At analysis time (within the rule's implementation function), when retrieving the attribute value from `ctx.attr`, labels are replaced by the corresponding [`Target`](../builtins/Target)s. This allows you to access the providers of the current target's dependencies.
+At analysis time (within the rule's implementation function), when retrieving the attribute value from `ctx.attr`, labels are replaced by the corresponding [`Target`](/versions/8.6.0/rules/lib/builtins/Target)s. This allows you to access the providers of the current target's dependencies.
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `allow_empty` | [bool](../core/bool); default is `True`  True if the attribute can be empty. |
-| `configurable` | [bool](../core/bool); or unbound; default is `unbound`  This argument can only be specified for an attribute of a symbolic macro. If `configurable` is explicitly set to `False`, the symbolic macro attribute is non-configurable - in other words, it cannot take a `select()` value. If the `configurable` is either unbound or explicitly set to `True`, the attribute is configurable and can take a `select()` value. For an attribute of a rule or aspect, `configurable` must be left unbound. Most Starlark rule attributes are always configurable, with the exception of `attr.output()`, `attr.output_list()`, and `attr.license()` rule attributes, which are always non-configurable. |
-| `default` | [dict](../core/dict); or [function](../core/function); default is `{}`  A default value to use if no value for this attribute is given when instantiating the rule.Use strings or the [`Label`](../builtins/Label#Label) function to specify default values, for example, `attr.string_keyed_label_dict(default = {"foo": "//a:b", "bar": "//a:c"})`. |
-| `doc` | [string](../core/string); or `None`; default is `None`  A description of the attribute that can be extracted by documentation generating tools. |
-| `allow_files` | [bool](../core/bool); or [sequence](../core/list) of [string](../core/string)s; or `None`; default is `None`  Whether `File` targets are allowed. Can be `True`, `False` (default), or a list of file extensions that are allowed (for example, `[".cc", ".cpp"]`). |
-| `allow_rules` | [sequence](../core/list) of [string](../core/string)s; or `None`; default is `None`  Which rule targets (name of the classes) are allowed. This is deprecated (kept only for compatibility), use providers instead. |
-| `providers` | [sequence](../core/list); default is `[]`  The providers that must be given by any dependency appearing in this attribute. The format of this argument is a list of lists of providers -- `*Info` objects returned by [`provider()`](../globals/bzl#provider) (or in the case of a legacy provider, its string name). The dependency must return ALL providers mentioned in at least ONE of the inner lists. As a convenience, this argument may also be a single-level list of providers, in which case it is wrapped in an outer list with one element. It is NOT required that the rule of the dependency advertises those providers in its `provides` parameter, however, it is considered best practice. |
+| `allow_empty` | [bool](/versions/8.6.0/rules/lib/core/bool); default is `True`  True if the attribute can be empty. |
+| `configurable` | [bool](/versions/8.6.0/rules/lib/core/bool); or unbound; default is `unbound`  This argument can only be specified for an attribute of a symbolic macro. If `configurable` is explicitly set to `False`, the symbolic macro attribute is non-configurable - in other words, it cannot take a `select()` value. If the `configurable` is either unbound or explicitly set to `True`, the attribute is configurable and can take a `select()` value. For an attribute of a rule or aspect, `configurable` must be left unbound. Most Starlark rule attributes are always configurable, with the exception of `attr.output()`, `attr.output_list()`, and `attr.license()` rule attributes, which are always non-configurable. |
+| `default` | [dict](/versions/8.6.0/rules/lib/core/dict); or [function](/versions/8.6.0/rules/lib/core/function); default is `{}`  A default value to use if no value for this attribute is given when instantiating the rule.Use strings or the [`Label`](/versions/8.6.0/rules/lib/builtins/Label#Label) function to specify default values, for example, `attr.string_keyed_label_dict(default = {"foo": "//a:b", "bar": "//a:c"})`. |
+| `doc` | [string](/versions/8.6.0/rules/lib/core/string); or `None`; default is `None`  A description of the attribute that can be extracted by documentation generating tools. |
+| `allow_files` | [bool](/versions/8.6.0/rules/lib/core/bool); or [sequence](/versions/8.6.0/rules/lib/core/list) of [string](/versions/8.6.0/rules/lib/core/string)s; or `None`; default is `None`  Whether `File` targets are allowed. Can be `True`, `False` (default), or a list of file extensions that are allowed (for example, `[".cc", ".cpp"]`). |
+| `allow_rules` | [sequence](/versions/8.6.0/rules/lib/core/list) of [string](/versions/8.6.0/rules/lib/core/string)s; or `None`; default is `None`  Which rule targets (name of the classes) are allowed. This is deprecated (kept only for compatibility), use providers instead. |
+| `providers` | [sequence](/versions/8.6.0/rules/lib/core/list); default is `[]`  The providers that must be given by any dependency appearing in this attribute. The format of this argument is a list of lists of providers -- `*Info` objects returned by [`provider()`](/versions/8.6.0/rules/lib/globals/bzl#provider) (or in the case of a legacy provider, its string name). The dependency must return ALL providers mentioned in at least ONE of the inner lists. As a convenience, this argument may also be a single-level list of providers, in which case it is wrapped in an outer list with one element. It is NOT required that the rule of the dependency advertises those providers in its `provides` parameter, however, it is considered best practice. |
 | `for_dependency_resolution` | default is `unbound`  If this is set, the attribute is available for materializers. Only rules marked with the flag of the same name are allowed to be referenced through such attributes. |
-| `flags` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  Deprecated, will be removed. |
-| `mandatory` | [bool](../core/bool); default is `False`  If true, the value must be specified explicitly (even if it has a `default`). |
-| `cfg` | default is `None`  [Configuration](https://bazel.build/extending/rules#configurations) of the attribute. It can be either `"exec"`, which indicates that the dependency is built for the `execution platform`, or `"target"`, which indicates that the dependency is build for the `target platform`. A typical example of the difference is when building mobile apps, where the `target platform` is `Android` or `iOS` while the `execution platform` is `Linux`, `macOS`, or `Windows`. |
-| `aspects` | [sequence](../core/list) of [Aspect](../builtins/Aspect)s; default is `[]`  Aspects that should be applied to the dependency or dependencies specified by this attribute. |
+| `flags` | [sequence](/versions/8.6.0/rules/lib/core/list) of [string](/versions/8.6.0/rules/lib/core/string)s; default is `[]`  Deprecated, will be removed. |
+| `mandatory` | [bool](/versions/8.6.0/rules/lib/core/bool); default is `False`  If true, the value must be specified explicitly (even if it has a `default`). |
+| `cfg` | default is `None`  [Configuration](https://bazel.build/versions/8.6.0/extending/rules#configurations) of the attribute. It can be either `"exec"`, which indicates that the dependency is built for the `execution platform`, or `"target"`, which indicates that the dependency is build for the `target platform`. A typical example of the difference is when building mobile apps, where the `target platform` is `Android` or `iOS` while the `execution platform` is `Linux`, `macOS`, or `Windows`. |
+| `aspects` | [sequence](/versions/8.6.0/rules/lib/core/list) of [Aspect](/versions/8.6.0/rules/lib/builtins/Aspect)s; default is `[]`  Aspects that should be applied to the dependency or dependencies specified by this attribute. |
 
 ## string_list
 
@@ -286,11 +286,11 @@ Creates a schema for a list-of-strings attribute.
 
 | Parameter | Description |
 | --- | --- |
-| `mandatory` | [bool](../core/bool); default is `False`  If true, the value must be specified explicitly (even if it has a `default`). |
-| `allow_empty` | [bool](../core/bool); default is `True`  True if the attribute can be empty. |
-| `configurable` | [bool](../core/bool); or unbound; default is `unbound`  This argument can only be specified for an attribute of a symbolic macro. If `configurable` is explicitly set to `False`, the symbolic macro attribute is non-configurable - in other words, it cannot take a `select()` value. If the `configurable` is either unbound or explicitly set to `True`, the attribute is configurable and can take a `select()` value. For an attribute of a rule or aspect, `configurable` must be left unbound. Most Starlark rule attributes are always configurable, with the exception of `attr.output()`, `attr.output_list()`, and `attr.license()` rule attributes, which are always non-configurable. |
-| `default` | [sequence](../core/list) of [string](../core/string)s; or NativeComputedDefault; default is `[]`  A default value to use if no value for this attribute is given when instantiating the rule. |
-| `doc` | [string](../core/string); or `None`; default is `None`  A description of the attribute that can be extracted by documentation generating tools. |
+| `mandatory` | [bool](/versions/8.6.0/rules/lib/core/bool); default is `False`  If true, the value must be specified explicitly (even if it has a `default`). |
+| `allow_empty` | [bool](/versions/8.6.0/rules/lib/core/bool); default is `True`  True if the attribute can be empty. |
+| `configurable` | [bool](/versions/8.6.0/rules/lib/core/bool); or unbound; default is `unbound`  This argument can only be specified for an attribute of a symbolic macro. If `configurable` is explicitly set to `False`, the symbolic macro attribute is non-configurable - in other words, it cannot take a `select()` value. If the `configurable` is either unbound or explicitly set to `True`, the attribute is configurable and can take a `select()` value. For an attribute of a rule or aspect, `configurable` must be left unbound. Most Starlark rule attributes are always configurable, with the exception of `attr.output()`, `attr.output_list()`, and `attr.license()` rule attributes, which are always non-configurable. |
+| `default` | [sequence](/versions/8.6.0/rules/lib/core/list) of [string](/versions/8.6.0/rules/lib/core/string)s; or NativeComputedDefault; default is `[]`  A default value to use if no value for this attribute is given when instantiating the rule. |
+| `doc` | [string](/versions/8.6.0/rules/lib/core/string); or `None`; default is `None`  A description of the attribute that can be extracted by documentation generating tools. |
 
 ## string_list_dict
 
@@ -304,8 +304,8 @@ Creates a schema for an attribute holding a dictionary, where the keys are strin
 
 | Parameter | Description |
 | --- | --- |
-| `allow_empty` | [bool](../core/bool); default is `True`  True if the attribute can be empty. |
-| `configurable` | [bool](../core/bool); or unbound; default is `unbound`  This argument can only be specified for an attribute of a symbolic macro. If `configurable` is explicitly set to `False`, the symbolic macro attribute is non-configurable - in other words, it cannot take a `select()` value. If the `configurable` is either unbound or explicitly set to `True`, the attribute is configurable and can take a `select()` value. For an attribute of a rule or aspect, `configurable` must be left unbound. Most Starlark rule attributes are always configurable, with the exception of `attr.output()`, `attr.output_list()`, and `attr.license()` rule attributes, which are always non-configurable. |
-| `default` | [dict](../core/dict); default is `{}`  A default value to use if no value for this attribute is given when instantiating the rule. |
-| `doc` | [string](../core/string); or `None`; default is `None`  A description of the attribute that can be extracted by documentation generating tools. |
-| `mandatory` | [bool](../core/bool); default is `False`  If true, the value must be specified explicitly (even if it has a `default`). |
\ No newline at end of file
+| `allow_empty` | [bool](/versions/8.6.0/rules/lib/core/bool); default is `True`  True if the attribute can be empty. |
+| `configurable` | [bool](/versions/8.6.0/rules/lib/core/bool); or unbound; default is `unbound`  This argument can only be specified for an attribute of a symbolic macro. If `configurable` is explicitly set to `False`, the symbolic macro attribute is non-configurable - in other words, it cannot take a `select()` value. If the `configurable` is either unbound or explicitly set to `True`, the attribute is configurable and can take a `select()` value. For an attribute of a rule or aspect, `configurable` must be left unbound. Most Starlark rule attributes are always configurable, with the exception of `attr.output()`, `attr.output_list()`, and `attr.license()` rule attributes, which are always non-configurable. |
+| `default` | [dict](/versions/8.6.0/rules/lib/core/dict); default is `{}`  A default value to use if no value for this attribute is given when instantiating the rule. |
+| `doc` | [string](/versions/8.6.0/rules/lib/core/string); or `None`; default is `None`  A description of the attribute that can be extracted by documentation generating tools. |
+| `mandatory` | [bool](/versions/8.6.0/rules/lib/core/bool); default is `False`  If true, the value must be specified explicitly (even if it has a `default`). |
\ No newline at end of file
diff --git a/versions/8.6.0/rules/lib/toplevel/cc_common.mdx b/versions/8.6.0/rules/lib/toplevel/cc_common.mdx
index c28063ce..fe97e1fd 100644
--- a/versions/8.6.0/rules/lib/toplevel/cc_common.mdx
+++ b/versions/8.6.0/rules/lib/toplevel/cc_common.mdx
@@ -42,8 +42,8 @@ Returns True if given action_config is enabled in the feature configuration.
 
 | Parameter | Description |
 | --- | --- |
-| `feature_configuration` | [FeatureConfiguration](../builtins/FeatureConfiguration); required  Feature configuration to be queried. |
-| `action_name` | [string](../core/string); required  Name of the action_config. |
+| `feature_configuration` | [FeatureConfiguration](/versions/8.6.0/rules/lib/builtins/FeatureConfiguration); required  Feature configuration to be queried. |
+| `action_name` | [string](/versions/8.6.0/rules/lib/core/string); required  Name of the action_config. |
 
 ## CcToolchainInfo
 
@@ -65,29 +65,29 @@ Should be used for C++ compilation. Returns tuple of (`CompilationContext`, `CcC
 
 | Parameter | Description |
 | --- | --- |
-| `actions` | [actions](../builtins/actions); required  `actions` object. |
-| `feature_configuration` | [FeatureConfiguration](../builtins/FeatureConfiguration); required  `feature_configuration` to be queried. |
+| `actions` | [actions](/versions/8.6.0/rules/lib/builtins/actions); required  `actions` object. |
+| `feature_configuration` | [FeatureConfiguration](/versions/8.6.0/rules/lib/builtins/FeatureConfiguration); required  `feature_configuration` to be queried. |
 | `cc_toolchain` | Info; required  `CcToolchainInfo` provider to be used. |
-| `srcs` | [sequence](../core/list); default is `[]`  The list of source files to be compiled. |
-| `public_hdrs` | [sequence](../core/list); default is `[]`  List of headers needed for compilation of srcs and may be included by dependent rules transitively. |
-| `private_hdrs` | [sequence](../core/list); default is `[]`  List of headers needed for compilation of srcs and NOT to be included by dependent rules. |
-| `includes` | [sequence](../core/list); or [depset](../builtins/depset); default is `[]`  Search paths for header files referenced both by angle bracket and quotes. Usually passed with -I. Propagated to dependents transitively. |
-| `quote_includes` | [sequence](../core/list); default is `[]`  Search paths for header files referenced by quotes, e.g. #include "foo/bar/header.h". They can be either relative to the exec root or absolute. Usually passed with -iquote. Propagated to dependents transitively. |
-| `system_includes` | [sequence](../core/list); default is `[]`  Search paths for header files referenced by angle brackets, e.g. #include <foo/bar/header.h>. They can be either relative to the exec root or absolute. Usually passed with -isystem. Propagated to dependents transitively. |
-| `framework_includes` | [sequence](../core/list); default is `[]`  Search paths for header files from Apple frameworks. They can be either relative to the exec root or absolute. Usually passed with -F. Propagated to dependents transitively. |
-| `defines` | [sequence](../core/list); default is `[]`  Set of defines needed to compile this target. Each define is a string. Propagated to dependents transitively. |
-| `local_defines` | [sequence](../core/list); default is `[]`  Set of defines needed to compile this target. Each define is a string. Not propagated to dependents transitively. |
-| `include_prefix` | [string](../core/string); default is `''`  The prefix to add to the paths of the headers of this rule. When set, the headers in the hdrs attribute of this rule are accessible at is the value of this attribute prepended to their repository-relative path. The prefix in the strip_include_prefix attribute is removed before this prefix is added. |
-| `strip_include_prefix` | [string](../core/string); default is `''`  The prefix to strip from the paths of the headers of this rule. When set, the headers in the hdrs attribute of this rule are accessible at their path with this prefix cut off. If it's a relative path, it's taken as a package-relative one. If it's an absolute one, it's understood as a repository-relative path. The prefix in the include_prefix attribute is added after this prefix is stripped. |
-| `user_compile_flags` | [sequence](../core/list); default is `[]`  Additional list of compilation options. |
-| `conly_flags` | [sequence](../core/list); default is `[]`  Additional list of compilation options for C compiles. |
-| `cxx_flags` | [sequence](../core/list); default is `[]`  Additional list of compilation options for C++ compiles. |
-| `compilation_contexts` | [sequence](../core/list); default is `[]`  Headers from dependencies used for compilation. |
-| `name` | [string](../core/string); required  This is used for naming the output artifacts of actions created by this method. See also the `main_output` arg. |
-| `disallow_pic_outputs` | [bool](../core/bool); default is `False`  Whether PIC outputs should be created. |
-| `disallow_nopic_outputs` | [bool](../core/bool); default is `False`  Whether NOPIC outputs should be created. |
-| `additional_inputs` | [sequence](../core/list); default is `[]`  List of additional files needed for compilation of srcs |
-| `module_interfaces` | [sequence](../core/list); default is `unbound`  The list of module interfaces source files to be compiled. Note: this is an experimental feature, only enabled with --experimental_cpp_modules |
+| `srcs` | [sequence](/versions/8.6.0/rules/lib/core/list); default is `[]`  The list of source files to be compiled. |
+| `public_hdrs` | [sequence](/versions/8.6.0/rules/lib/core/list); default is `[]`  List of headers needed for compilation of srcs and may be included by dependent rules transitively. |
+| `private_hdrs` | [sequence](/versions/8.6.0/rules/lib/core/list); default is `[]`  List of headers needed for compilation of srcs and NOT to be included by dependent rules. |
+| `includes` | [sequence](/versions/8.6.0/rules/lib/core/list); or [depset](/versions/8.6.0/rules/lib/builtins/depset); default is `[]`  Search paths for header files referenced both by angle bracket and quotes. Usually passed with -I. Propagated to dependents transitively. |
+| `quote_includes` | [sequence](/versions/8.6.0/rules/lib/core/list); default is `[]`  Search paths for header files referenced by quotes, e.g. #include "foo/bar/header.h". They can be either relative to the exec root or absolute. Usually passed with -iquote. Propagated to dependents transitively. |
+| `system_includes` | [sequence](/versions/8.6.0/rules/lib/core/list); default is `[]`  Search paths for header files referenced by angle brackets, e.g. #include <foo/bar/header.h>. They can be either relative to the exec root or absolute. Usually passed with -isystem. Propagated to dependents transitively. |
+| `framework_includes` | [sequence](/versions/8.6.0/rules/lib/core/list); default is `[]`  Search paths for header files from Apple frameworks. They can be either relative to the exec root or absolute. Usually passed with -F. Propagated to dependents transitively. |
+| `defines` | [sequence](/versions/8.6.0/rules/lib/core/list); default is `[]`  Set of defines needed to compile this target. Each define is a string. Propagated to dependents transitively. |
+| `local_defines` | [sequence](/versions/8.6.0/rules/lib/core/list); default is `[]`  Set of defines needed to compile this target. Each define is a string. Not propagated to dependents transitively. |
+| `include_prefix` | [string](/versions/8.6.0/rules/lib/core/string); default is `''`  The prefix to add to the paths of the headers of this rule. When set, the headers in the hdrs attribute of this rule are accessible at is the value of this attribute prepended to their repository-relative path. The prefix in the strip_include_prefix attribute is removed before this prefix is added. |
+| `strip_include_prefix` | [string](/versions/8.6.0/rules/lib/core/string); default is `''`  The prefix to strip from the paths of the headers of this rule. When set, the headers in the hdrs attribute of this rule are accessible at their path with this prefix cut off. If it's a relative path, it's taken as a package-relative one. If it's an absolute one, it's understood as a repository-relative path. The prefix in the include_prefix attribute is added after this prefix is stripped. |
+| `user_compile_flags` | [sequence](/versions/8.6.0/rules/lib/core/list); default is `[]`  Additional list of compilation options. |
+| `conly_flags` | [sequence](/versions/8.6.0/rules/lib/core/list); default is `[]`  Additional list of compilation options for C compiles. |
+| `cxx_flags` | [sequence](/versions/8.6.0/rules/lib/core/list); default is `[]`  Additional list of compilation options for C++ compiles. |
+| `compilation_contexts` | [sequence](/versions/8.6.0/rules/lib/core/list); default is `[]`  Headers from dependencies used for compilation. |
+| `name` | [string](/versions/8.6.0/rules/lib/core/string); required  This is used for naming the output artifacts of actions created by this method. See also the `main_output` arg. |
+| `disallow_pic_outputs` | [bool](/versions/8.6.0/rules/lib/core/bool); default is `False`  Whether PIC outputs should be created. |
+| `disallow_nopic_outputs` | [bool](/versions/8.6.0/rules/lib/core/bool); default is `False`  Whether NOPIC outputs should be created. |
+| `additional_inputs` | [sequence](/versions/8.6.0/rules/lib/core/list); default is `[]`  List of additional files needed for compilation of srcs |
+| `module_interfaces` | [sequence](/versions/8.6.0/rules/lib/core/list); default is `unbound`  The list of module interfaces source files to be compiled. Note: this is an experimental feature, only enabled with --experimental_cpp_modules |
 
 ## configure_features
 
@@ -101,11 +101,11 @@ Creates a feature_configuration instance. Requires the cpp configuration fragmen
 
 | Parameter | Description |
 | --- | --- |
-| `ctx` | [ctx](../builtins/ctx); or `None`; default is `None`  The rule context. |
+| `ctx` | [ctx](/versions/8.6.0/rules/lib/builtins/ctx); or `None`; default is `None`  The rule context. |
 | `cc_toolchain` | Info; required  cc_toolchain for which we configure features. |
-| `language` | [string](../core/string); or `None`; default is `None`  The language to configure for: either c++ or objc (default c++) |
-| `requested_features` | [sequence](../core/list); default is `[]`  List of features to be enabled. |
-| `unsupported_features` | [sequence](../core/list); default is `[]`  List of features that are unsupported by the current rule. |
+| `language` | [string](/versions/8.6.0/rules/lib/core/string); or `None`; default is `None`  The language to configure for: either c++ or objc (default c++) |
+| `requested_features` | [sequence](/versions/8.6.0/rules/lib/core/list); default is `[]`  List of features to be enabled. |
+| `unsupported_features` | [sequence](/versions/8.6.0/rules/lib/core/list); default is `[]`  List of features that are unsupported by the current rule. |
 
 ## create_cc_toolchain_config_info
 
@@ -119,22 +119,22 @@ Creates a `CcToolchainConfigInfo` provider
 
 | Parameter | Description |
 | --- | --- |
-| `ctx` | [ctx](../builtins/ctx); required  The rule context. |
-| `features` | [sequence](../core/list); default is `[]`  Contains all flag specifications for one feature. Arguments:  `name`: The feature's name. It is possible to introduce a feature without a change to Bazel by adding a 'feature' section to the toolchain and adding the corresponding string as feature in the `BUILD` file.  `enabled`: If 'True', this feature is enabled unless a rule type explicitly marks it as unsupported.  `flag_sets`: A FlagSet list. If the given feature is enabled, the flag sets will be applied for the actions are specified for.  `env_sets`: an EnvSet list. If the given feature is enabled, the env sets will be applied for the actions they are specified for.  `requires`: A list of feature sets defining when this feature is supported by the toolchain. The feature is supported if any of the feature sets fully apply, that is, when all features of a feature set are enabled. If `requires` is omitted, the feature is supported independently of which other features are enabled. Use this for example to filter flags depending on the build mode enabled (opt / fastbuild / dbg).  `implies`: A string list of features or action configs that are automatically enabled when this feature is enabled. If any of the implied features or action configs cannot be enabled, this feature will (silently) not be enabled either.  `provides`: A list of names this feature conflicts with. A feature cannot be enabled if:- `provides` contains the name of a different feature or action config that we want to enable.- `provides` contains the same value as a 'provides' in a different feature or action config that we want to enable. Use this in order to ensure that incompatible features cannot be accidentally activated at the same time, leading to hard to diagnose compiler errors. |
-| `action_configs` | [sequence](../core/list); default is `[]`  An action config corresponds to a Bazel action, and allows selection of a tool based on activated features. Action config activation occurs by the same semantics as features: a feature can 'require' or 'imply' an action config in the same way that it would another feature. Arguments:  `action_name`: The name of the Bazel action that this config applies to, e.g. 'c-compile' or 'c-module-compile'.  `enabled`: If 'True', this action is enabled unless a rule type explicitly marks it as unsupported.  `tools`: The tool applied to the action will be the first tool with a feature set that matches the feature configuration. An error will be thrown if no tool matches a provided feature configuration - for that reason, it's a good idea to provide a default tool with an empty feature set.  `flag_sets`: If the given action config is enabled, the flag sets will be applied to the corresponding action.  `implies`: A list of features or action configs that are automatically enabled when this action config is enabled. If any of the implied features or action configs cannot be enabled, this action config will (silently) not be enabled either. |
-| `artifact_name_patterns` | [sequence](../core/list); default is `[]`  The name for an artifact of a given category of input or output artifacts to an action. Arguments:  `category_name`: The category of artifacts that this selection applies to. This field is compared against a list of categories defined in Bazel. Example categories include "linked_output" or the artifact for this selection. Together with the extension it is used to create an artifact name based on the target name.  `extension`: The extension for creating the artifact for this selection. Together with the prefix it is used to create an artifact name based on the target name. |
-| `cxx_builtin_include_directories` | [sequence](../core/list); default is `[]`  Built-in include directories for C++ compilation. These should be the exact paths used by the compiler, and are generally relative to the exec root.  The paths used by the compiler can be determined by 'gcc -E -xc++ - -v'.  We currently use the C++ paths also for C compilation, which is safe as long as there are no name clashes between C++ and C header files.  Relative paths are resolved relative to the configuration file directory.  If the compiler has --sysroot support, then these paths should use %sysroot% rather than the include path, and specify the sysroot attribute in order to give blaze the information necessary to make the correct replacements. |
-| `toolchain_identifier` | [string](../core/string); required  The unique identifier of the toolchain within the crosstool release. It must be possible to use this as a directory name in a path.  It has to match the following regex: [a-zA-Z\_][\.\- \w]\* |
-| `host_system_name` | [string](../core/string); or `None`; default is `None`  Ignored. |
-| `target_system_name` | [string](../core/string); or `None`; default is `None`  Deprecated. The GNU System Name. The string is exposed to CcToolchainInfo.target_gnu_system_name. |
-| `target_cpu` | [string](../core/string); or `None`; default is `None`  Deprecated: Use cpu based constraints instead. If the string is "k8", `target_cpu` will be omitted from the filename of raw FDO profile data. |
-| `target_libc` | [string](../core/string); or `None`; default is `None`  Deprecated: Use OS based constraints instead. The libc version string (e.g. "glibc-2.2.2"). If the string is "macosx", platform is assumed to be MacOS. Otherwise, Linux. The string is exposed to CcToolchainInfo.libc. |
-| `compiler` | [string](../core/string); required  The compiler string (e.g. "gcc"). The current toolchain's compiler is exposed to `@bazel_tools//tools/cpp:compiler (compiler_flag)` as a flag value. Targets that require compiler-specific flags can use the config_settings in https://github.com/bazelbuild/rules_cc/blob/main/cc/compiler/BUILD in select() statements or create custom config_setting if the existing settings don't suffice. |
-| `abi_version` | [string](../core/string); or `None`; default is `None`  The abi in use, which is a gcc version. E.g.: "gcc-3.4". The string is set to C++ toolchain variable ABI. |
-| `abi_libc_version` | [string](../core/string); or `None`; default is `None`  The glibc version used by the abi we're using. The string is set to C++ toolchain variable ABI_LIBC_VERSION. |
-| `tool_paths` | [sequence](../core/list); default is `[]`  Tool locations. Arguments:  `name`: Name of the tool.  `path`: Location of the tool; Can be absolute path (in case of non hermetic toolchain), or path relative to the cc_toolchain's package. |
-| `make_variables` | [sequence](../core/list); default is `[]`  A make variable that is made accessible to rules. |
-| `builtin_sysroot` | [string](../core/string); or `None`; default is `None`  The built-in sysroot. If this attribute is not present, Bazel does not allow using a different sysroot, i.e. through the --grte_top option. |
+| `ctx` | [ctx](/versions/8.6.0/rules/lib/builtins/ctx); required  The rule context. |
+| `features` | [sequence](/versions/8.6.0/rules/lib/core/list); default is `[]`  Contains all flag specifications for one feature. Arguments:  `name`: The feature's name. It is possible to introduce a feature without a change to Bazel by adding a 'feature' section to the toolchain and adding the corresponding string as feature in the `BUILD` file.  `enabled`: If 'True', this feature is enabled unless a rule type explicitly marks it as unsupported.  `flag_sets`: A FlagSet list. If the given feature is enabled, the flag sets will be applied for the actions are specified for.  `env_sets`: an EnvSet list. If the given feature is enabled, the env sets will be applied for the actions they are specified for.  `requires`: A list of feature sets defining when this feature is supported by the toolchain. The feature is supported if any of the feature sets fully apply, that is, when all features of a feature set are enabled. If `requires` is omitted, the feature is supported independently of which other features are enabled. Use this for example to filter flags depending on the build mode enabled (opt / fastbuild / dbg).  `implies`: A string list of features or action configs that are automatically enabled when this feature is enabled. If any of the implied features or action configs cannot be enabled, this feature will (silently) not be enabled either.  `provides`: A list of names this feature conflicts with. A feature cannot be enabled if:- `provides` contains the name of a different feature or action config that we want to enable.- `provides` contains the same value as a 'provides' in a different feature or action config that we want to enable. Use this in order to ensure that incompatible features cannot be accidentally activated at the same time, leading to hard to diagnose compiler errors. |
+| `action_configs` | [sequence](/versions/8.6.0/rules/lib/core/list); default is `[]`  An action config corresponds to a Bazel action, and allows selection of a tool based on activated features. Action config activation occurs by the same semantics as features: a feature can 'require' or 'imply' an action config in the same way that it would another feature. Arguments:  `action_name`: The name of the Bazel action that this config applies to, e.g. 'c-compile' or 'c-module-compile'.  `enabled`: If 'True', this action is enabled unless a rule type explicitly marks it as unsupported.  `tools`: The tool applied to the action will be the first tool with a feature set that matches the feature configuration. An error will be thrown if no tool matches a provided feature configuration - for that reason, it's a good idea to provide a default tool with an empty feature set.  `flag_sets`: If the given action config is enabled, the flag sets will be applied to the corresponding action.  `implies`: A list of features or action configs that are automatically enabled when this action config is enabled. If any of the implied features or action configs cannot be enabled, this action config will (silently) not be enabled either. |
+| `artifact_name_patterns` | [sequence](/versions/8.6.0/rules/lib/core/list); default is `[]`  The name for an artifact of a given category of input or output artifacts to an action. Arguments:  `category_name`: The category of artifacts that this selection applies to. This field is compared against a list of categories defined in Bazel. Example categories include "linked_output" or the artifact for this selection. Together with the extension it is used to create an artifact name based on the target name.  `extension`: The extension for creating the artifact for this selection. Together with the prefix it is used to create an artifact name based on the target name. |
+| `cxx_builtin_include_directories` | [sequence](/versions/8.6.0/rules/lib/core/list); default is `[]`  Built-in include directories for C++ compilation. These should be the exact paths used by the compiler, and are generally relative to the exec root.  The paths used by the compiler can be determined by 'gcc -E -xc++ - -v'.  We currently use the C++ paths also for C compilation, which is safe as long as there are no name clashes between C++ and C header files.  Relative paths are resolved relative to the configuration file directory.  If the compiler has --sysroot support, then these paths should use %sysroot% rather than the include path, and specify the sysroot attribute in order to give blaze the information necessary to make the correct replacements. |
+| `toolchain_identifier` | [string](/versions/8.6.0/rules/lib/core/string); required  The unique identifier of the toolchain within the crosstool release. It must be possible to use this as a directory name in a path.  It has to match the following regex: [a-zA-Z\_][\.\- \w]\* |
+| `host_system_name` | [string](/versions/8.6.0/rules/lib/core/string); or `None`; default is `None`  Ignored. |
+| `target_system_name` | [string](/versions/8.6.0/rules/lib/core/string); or `None`; default is `None`  Deprecated. The GNU System Name. The string is exposed to CcToolchainInfo.target_gnu_system_name. |
+| `target_cpu` | [string](/versions/8.6.0/rules/lib/core/string); or `None`; default is `None`  Deprecated: Use cpu based constraints instead. If the string is "k8", `target_cpu` will be omitted from the filename of raw FDO profile data. |
+| `target_libc` | [string](/versions/8.6.0/rules/lib/core/string); or `None`; default is `None`  Deprecated: Use OS based constraints instead. The libc version string (e.g. "glibc-2.2.2"). If the string is "macosx", platform is assumed to be MacOS. Otherwise, Linux. The string is exposed to CcToolchainInfo.libc. |
+| `compiler` | [string](/versions/8.6.0/rules/lib/core/string); required  The compiler string (e.g. "gcc"). The current toolchain's compiler is exposed to `@bazel_tools//tools/cpp:compiler (compiler_flag)` as a flag value. Targets that require compiler-specific flags can use the config_settings in https://github.com/bazelbuild/rules_cc/blob/main/cc/compiler/BUILD in select() statements or create custom config_setting if the existing settings don't suffice. |
+| `abi_version` | [string](/versions/8.6.0/rules/lib/core/string); or `None`; default is `None`  The abi in use, which is a gcc version. E.g.: "gcc-3.4". The string is set to C++ toolchain variable ABI. |
+| `abi_libc_version` | [string](/versions/8.6.0/rules/lib/core/string); or `None`; default is `None`  The glibc version used by the abi we're using. The string is set to C++ toolchain variable ABI_LIBC_VERSION. |
+| `tool_paths` | [sequence](/versions/8.6.0/rules/lib/core/list); default is `[]`  Tool locations. Arguments:  `name`: Name of the tool.  `path`: Location of the tool; Can be absolute path (in case of non hermetic toolchain), or path relative to the cc_toolchain's package. |
+| `make_variables` | [sequence](/versions/8.6.0/rules/lib/core/list); default is `[]`  A make variable that is made accessible to rules. |
+| `builtin_sysroot` | [string](/versions/8.6.0/rules/lib/core/string); or `None`; default is `None`  The built-in sysroot. If this attribute is not present, Bazel does not allow using a different sysroot, i.e. through the --grte_top option. |
 
 ## create_compilation_context
 
@@ -168,8 +168,8 @@ Create compilation outputs object.
 
 | Parameter | Description |
 | --- | --- |
-| `objects` | [depset](../builtins/depset); or `None`; default is `None`  List of object files. |
-| `pic_objects` | [depset](../builtins/depset); or `None`; default is `None`  List of pic object files. |
+| `objects` | [depset](/versions/8.6.0/rules/lib/builtins/depset); or `None`; default is `None`  List of object files. |
+| `pic_objects` | [depset](/versions/8.6.0/rules/lib/builtins/depset); or `None`; default is `None`  List of pic object files. |
 
 ## create_compile_variables
 
@@ -184,21 +184,21 @@ Returns variables used for compilation actions.
 | Parameter | Description |
 | --- | --- |
 | `cc_toolchain` | Info; required  cc_toolchain for which we are creating build variables. |
-| `feature_configuration` | [FeatureConfiguration](../builtins/FeatureConfiguration); required  Feature configuration to be queried. |
+| `feature_configuration` | [FeatureConfiguration](/versions/8.6.0/rules/lib/builtins/FeatureConfiguration); required  Feature configuration to be queried. |
 | `source_file` | default is `None`  Optional source file for the compilation. Please prefer passing source_file here over appending it to the end of the command line generated from cc_common.get_memory_inefficient_command_line, as then it's in the power of the toolchain author to properly specify and position compiler flags. |
 | `output_file` | default is `None`  Optional output file of the compilation. Please prefer passing output_file here over appending it to the end of the command line generated from cc_common.get_memory_inefficient_command_line, as then it's in the power of the toolchain author to properly specify and position compiler flags. |
-| `user_compile_flags` | [sequence](../core/list) of [string](../core/string)s; or `None`; default is `None`  List of additional compilation flags (copts). |
-| `include_directories` | [depset](../builtins/depset); or `None`; default is `None`  Depset of include directories. |
-| `quote_include_directories` | [depset](../builtins/depset); or `None`; default is `None`  Depset of quote include directories. |
-| `system_include_directories` | [depset](../builtins/depset); or `None`; default is `None`  Depset of system include directories. |
-| `framework_include_directories` | [depset](../builtins/depset); or `None`; default is `None`  Depset of framework include directories. |
-| `preprocessor_defines` | [depset](../builtins/depset); or `None`; default is `None`  Depset of preprocessor defines. |
-| `thinlto_index` | [string](../core/string); or `None`; default is `None`  LTO index file path. |
-| `thinlto_input_bitcode_file` | [string](../core/string); or `None`; default is `None`  Bitcode file that is input to LTO backend. |
-| `thinlto_output_object_file` | [string](../core/string); or `None`; default is `None`  Object file that is output by LTO backend. |
-| `use_pic` | [bool](../core/bool); default is `False`  When true the compilation will generate position independent code. |
-| `add_legacy_cxx_options` | [bool](../core/bool); default is `False`  Unused. |
-| `variables_extension` | [dict](../core/dict); default is `unbound`  A dictionary of additional variables used by compile actions. |
+| `user_compile_flags` | [sequence](/versions/8.6.0/rules/lib/core/list) of [string](/versions/8.6.0/rules/lib/core/string)s; or `None`; default is `None`  List of additional compilation flags (copts). |
+| `include_directories` | [depset](/versions/8.6.0/rules/lib/builtins/depset); or `None`; default is `None`  Depset of include directories. |
+| `quote_include_directories` | [depset](/versions/8.6.0/rules/lib/builtins/depset); or `None`; default is `None`  Depset of quote include directories. |
+| `system_include_directories` | [depset](/versions/8.6.0/rules/lib/builtins/depset); or `None`; default is `None`  Depset of system include directories. |
+| `framework_include_directories` | [depset](/versions/8.6.0/rules/lib/builtins/depset); or `None`; default is `None`  Depset of framework include directories. |
+| `preprocessor_defines` | [depset](/versions/8.6.0/rules/lib/builtins/depset); or `None`; default is `None`  Depset of preprocessor defines. |
+| `thinlto_index` | [string](/versions/8.6.0/rules/lib/core/string); or `None`; default is `None`  LTO index file path. |
+| `thinlto_input_bitcode_file` | [string](/versions/8.6.0/rules/lib/core/string); or `None`; default is `None`  Bitcode file that is input to LTO backend. |
+| `thinlto_output_object_file` | [string](/versions/8.6.0/rules/lib/core/string); or `None`; default is `None`  Object file that is output by LTO backend. |
+| `use_pic` | [bool](/versions/8.6.0/rules/lib/core/bool); default is `False`  When true the compilation will generate position independent code. |
+| `add_legacy_cxx_options` | [bool](/versions/8.6.0/rules/lib/core/bool); default is `False`  Unused. |
+| `variables_extension` | [dict](/versions/8.6.0/rules/lib/core/dict); default is `unbound`  A dictionary of additional variables used by compile actions. |
 
 ## create_library_to_link
 
@@ -215,15 +215,15 @@ Creates `LibraryToLink`
 | `actions` | required  `actions` object. |
 | `feature_configuration` | default is `None`  `feature_configuration` to be queried. |
 | `cc_toolchain` | default is `None`  `CcToolchainInfo` provider to be used. |
-| `static_library` | [File](../builtins/File); or `None`; default is `None`  `File` of static library to be linked. |
-| `pic_static_library` | [File](../builtins/File); or `None`; default is `None`  `File` of pic static library to be linked. |
-| `dynamic_library` | [File](../builtins/File); or `None`; default is `None`  `File` of dynamic library to be linked. Always used for runtime and used for linking if `interface_library` is not passed. |
-| `interface_library` | [File](../builtins/File); or `None`; default is `None`  `File` of interface library to be linked. |
-| `pic_objects` | [sequence](../core/list) of [File](../builtins/File)s; default is `unbound`  Experimental, do not use |
-| `objects` | [sequence](../core/list) of [File](../builtins/File)s; default is `unbound`  Experimental, do not use |
-| `alwayslink` | [bool](../core/bool); default is `False`  Whether to link the static library/objects in the --whole_archive block. |
-| `dynamic_library_symlink_path` | [string](../core/string); default is `''`  Override the default path of the dynamic library link in the solib directory. Empty string to use the default. |
-| `interface_library_symlink_path` | [string](../core/string); default is `''`  Override the default path of the interface library link in the solib directory. Empty string to use the default. |
+| `static_library` | [File](/versions/8.6.0/rules/lib/builtins/File); or `None`; default is `None`  `File` of static library to be linked. |
+| `pic_static_library` | [File](/versions/8.6.0/rules/lib/builtins/File); or `None`; default is `None`  `File` of pic static library to be linked. |
+| `dynamic_library` | [File](/versions/8.6.0/rules/lib/builtins/File); or `None`; default is `None`  `File` of dynamic library to be linked. Always used for runtime and used for linking if `interface_library` is not passed. |
+| `interface_library` | [File](/versions/8.6.0/rules/lib/builtins/File); or `None`; default is `None`  `File` of interface library to be linked. |
+| `pic_objects` | [sequence](/versions/8.6.0/rules/lib/core/list) of [File](/versions/8.6.0/rules/lib/builtins/File)s; default is `unbound`  Experimental, do not use |
+| `objects` | [sequence](/versions/8.6.0/rules/lib/core/list) of [File](/versions/8.6.0/rules/lib/builtins/File)s; default is `unbound`  Experimental, do not use |
+| `alwayslink` | [bool](/versions/8.6.0/rules/lib/core/bool); default is `False`  Whether to link the static library/objects in the --whole_archive block. |
+| `dynamic_library_symlink_path` | [string](/versions/8.6.0/rules/lib/core/string); default is `''`  Override the default path of the dynamic library link in the solib directory. Empty string to use the default. |
+| `interface_library_symlink_path` | [string](/versions/8.6.0/rules/lib/core/string); default is `''`  Override the default path of the interface library link in the solib directory. Empty string to use the default. |
 
 ## create_link_variables
 
@@ -238,17 +238,17 @@ Returns link variables used for linking actions.
 | Parameter | Description |
 | --- | --- |
 | `cc_toolchain` | Info; required  cc_toolchain for which we are creating build variables. |
-| `feature_configuration` | [FeatureConfiguration](../builtins/FeatureConfiguration); required  Feature configuration to be queried. |
-| `library_search_directories` | [depset](../builtins/depset); default is `[]`  Depset of directories where linker will look for libraries at link time. |
-| `runtime_library_search_directories` | [depset](../builtins/depset); default is `[]`  Depset of directories where loader will look for libraries at runtime. |
-| `user_link_flags` | [sequence](../core/list); default is `[]`  List of additional link flags (linkopts). |
+| `feature_configuration` | [FeatureConfiguration](/versions/8.6.0/rules/lib/builtins/FeatureConfiguration); required  Feature configuration to be queried. |
+| `library_search_directories` | [depset](/versions/8.6.0/rules/lib/builtins/depset); default is `[]`  Depset of directories where linker will look for libraries at link time. |
+| `runtime_library_search_directories` | [depset](/versions/8.6.0/rules/lib/builtins/depset); default is `[]`  Depset of directories where loader will look for libraries at runtime. |
+| `user_link_flags` | [sequence](/versions/8.6.0/rules/lib/core/list); default is `[]`  List of additional link flags (linkopts). |
 | `output_file` | default is `None`  Optional output file path. |
 | `param_file` | default is `None`  Optional param file path. |
-| `is_using_linker` | [bool](../core/bool); default is `True`  True when using linker, False when archiver. Caller is responsible for keeping this in sync with action name used (is_using_linker = True for linking executable or dynamic library, is_using_linker = False for archiving static library). |
-| `is_linking_dynamic_library` | [bool](../core/bool); default is `False`  True when creating dynamic library, False when executable or static library. Caller is responsible for keeping this in sync with action name used. This field will be removed once b/65151735 is fixed. |
-| `must_keep_debug` | [bool](../core/bool); default is `True`  When set to False, bazel will expose 'strip_debug_symbols' variable, which is usually used to use the linker to strip debug symbols from the output file. |
-| `use_test_only_flags` | [bool](../core/bool); default is `False`  When set to true, 'is_cc_test' variable will be set. |
-| `is_static_linking_mode` | [bool](../core/bool); default is `True`  Unused. |
+| `is_using_linker` | [bool](/versions/8.6.0/rules/lib/core/bool); default is `True`  True when using linker, False when archiver. Caller is responsible for keeping this in sync with action name used (is_using_linker = True for linking executable or dynamic library, is_using_linker = False for archiving static library). |
+| `is_linking_dynamic_library` | [bool](/versions/8.6.0/rules/lib/core/bool); default is `False`  True when creating dynamic library, False when executable or static library. Caller is responsible for keeping this in sync with action name used. This field will be removed once b/65151735 is fixed. |
+| `must_keep_debug` | [bool](/versions/8.6.0/rules/lib/core/bool); default is `True`  When set to False, bazel will expose 'strip_debug_symbols' variable, which is usually used to use the linker to strip debug symbols from the output file. |
+| `use_test_only_flags` | [bool](/versions/8.6.0/rules/lib/core/bool); default is `False`  When set to true, 'is_cc_test' variable will be set. |
+| `is_static_linking_mode` | [bool](/versions/8.6.0/rules/lib/core/bool); default is `True`  Unused. |
 
 ## create_linker_input
 
@@ -262,10 +262,10 @@ Creates a `LinkerInput`.
 
 | Parameter | Description |
 | --- | --- |
-| `owner` | [Label](../builtins/Label); required  The label of the target that produced all files used in this input. |
-| `libraries` | `None`; or [depset](../builtins/depset); default is `None`  List of `LibraryToLink`. |
-| `user_link_flags` | `None`; or [depset](../builtins/depset) of [string](../core/string)s; or [sequence](../core/list) of [string](../core/string)s; default is `None`  User link flags passed as strings. Accepts either [String], [[String]] or depset(String). The latter is discouraged as it's only kept for compatibility purposes, the depset is flattened. If you want to propagate user_link_flags via unflattened depsets() wrap them in a LinkerInput so that they are not flattened till the end. |
-| `additional_inputs` | `None`; or [depset](../builtins/depset); default is `None`  For additional inputs to the linking action, e.g.: linking scripts. |
+| `owner` | [Label](/versions/8.6.0/rules/lib/builtins/Label); required  The label of the target that produced all files used in this input. |
+| `libraries` | `None`; or [depset](/versions/8.6.0/rules/lib/builtins/depset); default is `None`  List of `LibraryToLink`. |
+| `user_link_flags` | `None`; or [depset](/versions/8.6.0/rules/lib/builtins/depset) of [string](/versions/8.6.0/rules/lib/core/string)s; or [sequence](/versions/8.6.0/rules/lib/core/list) of [string](/versions/8.6.0/rules/lib/core/string)s; default is `None`  User link flags passed as strings. Accepts either [String], [[String]] or depset(String). The latter is discouraged as it's only kept for compatibility purposes, the depset is flattened. If you want to propagate user_link_flags via unflattened depsets() wrap them in a LinkerInput so that they are not flattened till the end. |
+| `additional_inputs` | `None`; or [depset](/versions/8.6.0/rules/lib/builtins/depset); default is `None`  For additional inputs to the linking action, e.g.: linking scripts. |
 
 ## create_linking_context
 
@@ -279,10 +279,10 @@ Creates a `LinkingContext`.
 
 | Parameter | Description |
 | --- | --- |
-| `linker_inputs` | `None`; or [depset](../builtins/depset); default is `None`  Depset of `LinkerInput`. |
-| `libraries_to_link` | `None`; or [sequence](../core/list); default is `None`  **Deprecated**. This parameter is deprecated and will be removed soon. Please do not depend on it. It is *disabled* with `--incompatible_require_linker_input_cc_api`. Use this flag to verify your code is compatible with its imminent removal.  List of `LibraryToLink`. |
-| `user_link_flags` | `None`; or [sequence](../core/list); default is `None` |
-| `additional_inputs` | `None`; or [sequence](../core/list); default is `None` |
+| `linker_inputs` | `None`; or [depset](/versions/8.6.0/rules/lib/builtins/depset); default is `None`  Depset of `LinkerInput`. |
+| `libraries_to_link` | `None`; or [sequence](/versions/8.6.0/rules/lib/core/list); default is `None`  **Deprecated**. This parameter is deprecated and will be removed soon. Please do not depend on it. It is *disabled* with `--incompatible_require_linker_input_cc_api`. Use this flag to verify your code is compatible with its imminent removal.  List of `LibraryToLink`. |
+| `user_link_flags` | `None`; or [sequence](/versions/8.6.0/rules/lib/core/list); default is `None` |
+| `additional_inputs` | `None`; or [sequence](/versions/8.6.0/rules/lib/core/list); default is `None` |
 
 ## create_linking_context_from_compilation_outputs
 
@@ -296,19 +296,19 @@ Should be used for creating library rules that can propagate information downstr
 
 | Parameter | Description |
 | --- | --- |
-| `actions` | [actions](../builtins/actions); required |
-| `name` | [string](../core/string); required  This is used for naming the output artifacts of actions created by this method. |
-| `feature_configuration` | [FeatureConfiguration](../builtins/FeatureConfiguration); required  `feature_configuration` to be queried. |
+| `actions` | [actions](/versions/8.6.0/rules/lib/builtins/actions); required |
+| `name` | [string](/versions/8.6.0/rules/lib/core/string); required  This is used for naming the output artifacts of actions created by this method. |
+| `feature_configuration` | [FeatureConfiguration](/versions/8.6.0/rules/lib/builtins/FeatureConfiguration); required  `feature_configuration` to be queried. |
 | `cc_toolchain` | Info; required  `CcToolchainInfo` provider to be used. |
-| `language` | [string](../core/string); default is `'c++'`  Only C++ supported for now. Do not use this parameter. |
-| `disallow_static_libraries` | [bool](../core/bool); default is `False`  Whether static libraries should be created. |
-| `disallow_dynamic_library` | [bool](../core/bool); default is `False`  Whether a dynamic library should be created. |
-| `compilation_outputs` | [CcCompilationOutputs](../builtins/CcCompilationOutputs); required  Compilation outputs containing object files to link. |
-| `linking_contexts` | [sequence](../core/list); default is `[]`  Libraries from dependencies. These libraries will be linked into the output artifact of the link() call, be it a binary or a library. |
-| `user_link_flags` | [sequence](../core/list); default is `[]`  Additional list of linking options. |
-| `alwayslink` | [bool](../core/bool); default is `False`  Whether this library should always be linked. |
-| `additional_inputs` | [sequence](../core/list); default is `[]`  For additional inputs to the linking action, e.g.: linking scripts. |
-| `variables_extension` | [dict](../core/dict); default is `unbound`  Additional variables to pass to the toolchain configuration when creating link command line. |
+| `language` | [string](/versions/8.6.0/rules/lib/core/string); default is `'c++'`  Only C++ supported for now. Do not use this parameter. |
+| `disallow_static_libraries` | [bool](/versions/8.6.0/rules/lib/core/bool); default is `False`  Whether static libraries should be created. |
+| `disallow_dynamic_library` | [bool](/versions/8.6.0/rules/lib/core/bool); default is `False`  Whether a dynamic library should be created. |
+| `compilation_outputs` | [CcCompilationOutputs](/versions/8.6.0/rules/lib/builtins/CcCompilationOutputs); required  Compilation outputs containing object files to link. |
+| `linking_contexts` | [sequence](/versions/8.6.0/rules/lib/core/list); default is `[]`  Libraries from dependencies. These libraries will be linked into the output artifact of the link() call, be it a binary or a library. |
+| `user_link_flags` | [sequence](/versions/8.6.0/rules/lib/core/list); default is `[]`  Additional list of linking options. |
+| `alwayslink` | [bool](/versions/8.6.0/rules/lib/core/bool); default is `False`  Whether this library should always be linked. |
+| `additional_inputs` | [sequence](/versions/8.6.0/rules/lib/core/list); default is `[]`  For additional inputs to the linking action, e.g.: linking scripts. |
+| `variables_extension` | [dict](/versions/8.6.0/rules/lib/core/dict); default is `unbound`  Additional variables to pass to the toolchain configuration when creating link command line. |
 
 ## create_lto_compilation_context
 
@@ -322,7 +322,7 @@ Create LTO compilation context
 
 | Parameter | Description |
 | --- | --- |
-| `objects` | [dict](../core/dict); default is `{}`  map of full object to index object |
+| `objects` | [dict](/versions/8.6.0/rules/lib/core/dict); default is `{}`  map of full object to index object |
 
 ## do_not_use_tools_cpp_compiler_present
 
@@ -344,8 +344,8 @@ Returns environment variables to be set for given action.
 
 | Parameter | Description |
 | --- | --- |
-| `feature_configuration` | [FeatureConfiguration](../builtins/FeatureConfiguration); required  Feature configuration to be queried. |
-| `action_name` | [string](../core/string); required  Name of the action. Has to be one of the names in @bazel_tools//tools/build_defs/cc:action_names.bzl (https://github.com/bazelbuild/bazel/blob/master/tools/build_defs/cc/action_names.bzl) |
+| `feature_configuration` | [FeatureConfiguration](/versions/8.6.0/rules/lib/builtins/FeatureConfiguration); required  Feature configuration to be queried. |
+| `action_name` | [string](/versions/8.6.0/rules/lib/core/string); required  Name of the action. Has to be one of the names in @bazel_tools//tools/build_defs/cc:action_names.bzl (https://github.com/bazelbuild/bazel/blob/master/tools/build_defs/cc/action_names.bzl) |
 | `variables` | Variables; required  Build variables to be used for template expansion. |
 
 ## get_execution_requirements
@@ -360,8 +360,8 @@ Returns execution requirements for given action.
 
 | Parameter | Description |
 | --- | --- |
-| `feature_configuration` | [FeatureConfiguration](../builtins/FeatureConfiguration); required  Feature configuration to be queried. |
-| `action_name` | [string](../core/string); required  Name of the action. Has to be one of the names in @bazel_tools//tools/build_defs/cc:action_names.bzl (https://github.com/bazelbuild/bazel/blob/master/tools/build_defs/cc/action_names.bzl) |
+| `feature_configuration` | [FeatureConfiguration](/versions/8.6.0/rules/lib/builtins/FeatureConfiguration); required  Feature configuration to be queried. |
+| `action_name` | [string](/versions/8.6.0/rules/lib/core/string); required  Name of the action. Has to be one of the names in @bazel_tools//tools/build_defs/cc:action_names.bzl (https://github.com/bazelbuild/bazel/blob/master/tools/build_defs/cc/action_names.bzl) |
 
 ## get_memory_inefficient_command_line
 
@@ -375,8 +375,8 @@ Returns flattened command line flags for given action, using given variables for
 
 | Parameter | Description |
 | --- | --- |
-| `feature_configuration` | [FeatureConfiguration](../builtins/FeatureConfiguration); required  Feature configuration to be queried. |
-| `action_name` | [string](../core/string); required  Name of the action. Has to be one of the names in @bazel_tools//tools/build_defs/cc:action_names.bzl (https://github.com/bazelbuild/bazel/blob/master/tools/build_defs/cc/action_names.bzl) |
+| `feature_configuration` | [FeatureConfiguration](/versions/8.6.0/rules/lib/builtins/FeatureConfiguration); required  Feature configuration to be queried. |
+| `action_name` | [string](/versions/8.6.0/rules/lib/core/string); required  Name of the action. Has to be one of the names in @bazel_tools//tools/build_defs/cc:action_names.bzl (https://github.com/bazelbuild/bazel/blob/master/tools/build_defs/cc/action_names.bzl) |
 | `variables` | Variables; required  Build variables to be used for template expansions. |
 
 ## get_tool_for_action
@@ -391,8 +391,8 @@ Returns tool path for given action.
 
 | Parameter | Description |
 | --- | --- |
-| `feature_configuration` | [FeatureConfiguration](../builtins/FeatureConfiguration); required  Feature configuration to be queried. |
-| `action_name` | [string](../core/string); required  Name of the action. Has to be one of the names in @bazel_tools//tools/build_defs/cc:action_names.bzl (https://github.com/bazelbuild/bazel/blob/master/tools/build_defs/cc/action_names.bzl) |
+| `feature_configuration` | [FeatureConfiguration](/versions/8.6.0/rules/lib/builtins/FeatureConfiguration); required  Feature configuration to be queried. |
+| `action_name` | [string](/versions/8.6.0/rules/lib/core/string); required  Name of the action. Has to be one of the names in @bazel_tools//tools/build_defs/cc:action_names.bzl (https://github.com/bazelbuild/bazel/blob/master/tools/build_defs/cc/action_names.bzl) |
 
 ## is_enabled
 
@@ -406,8 +406,8 @@ Returns True if given feature is enabled in the feature configuration.
 
 | Parameter | Description |
 | --- | --- |
-| `feature_configuration` | [FeatureConfiguration](../builtins/FeatureConfiguration); required  Feature configuration to be queried. |
-| `feature_name` | [string](../core/string); required  Name of the feature. |
+| `feature_configuration` | [FeatureConfiguration](/versions/8.6.0/rules/lib/builtins/FeatureConfiguration); required  Feature configuration to be queried. |
+| `feature_name` | [string](/versions/8.6.0/rules/lib/core/string); required  Name of the feature. |
 
 ## link
 
@@ -421,20 +421,20 @@ Should be used for C++ transitive linking.
 
 | Parameter | Description |
 | --- | --- |
-| `actions` | [actions](../builtins/actions); required  `actions` object. |
-| `name` | [string](../core/string); required  This is used for naming the output artifacts of actions created by this method. |
-| `feature_configuration` | [FeatureConfiguration](../builtins/FeatureConfiguration); required  `feature_configuration` to be queried. |
+| `actions` | [actions](/versions/8.6.0/rules/lib/builtins/actions); required  `actions` object. |
+| `name` | [string](/versions/8.6.0/rules/lib/core/string); required  This is used for naming the output artifacts of actions created by this method. |
+| `feature_configuration` | [FeatureConfiguration](/versions/8.6.0/rules/lib/builtins/FeatureConfiguration); required  `feature_configuration` to be queried. |
 | `cc_toolchain` | Info; required  `CcToolchainInfo` provider to be used. |
-| `language` | [string](../core/string); default is `'c++'`  Only C++ supported for now. Do not use this parameter. |
-| `output_type` | [string](../core/string); default is `'executable'`  Can be either 'executable' or 'dynamic_library'. |
-| `link_deps_statically` | [bool](../core/bool); default is `True`  True to link dependencies statically, False dynamically. |
-| `compilation_outputs` | [CcCompilationOutputs](../builtins/CcCompilationOutputs); or `None`; default is `None`  Compilation outputs containing object files to link. |
-| `linking_contexts` | [sequence](../core/list); default is `[]`  Linking contexts from dependencies to be linked into the linking context generated by this rule. |
-| `user_link_flags` | [sequence](../core/list); default is `[]`  Additional list of linker options. |
-| `stamp` | [int](../core/int); default is `0`  Whether to include build information in the linked executable, if output_type is 'executable'. If 1, build information is always included. If 0 (the default build information is always excluded. If -1, uses the default behavior, which may be overridden by the --[no]stamp flag. This should be unset (or set to 0) when generating the executable output for test rules. |
-| `additional_inputs` | [sequence](../core/list); or [depset](../builtins/depset); default is `[]`  For additional inputs to the linking action, e.g.: linking scripts. |
-| `additional_outputs` | [sequence](../core/list); default is `[]`  For additional outputs to the linking action, e.g.: map files. |
-| `variables_extension` | [dict](../core/dict); default is `{}`  Additional variables to pass to the toolchain configuration when create link command line. |
+| `language` | [string](/versions/8.6.0/rules/lib/core/string); default is `'c++'`  Only C++ supported for now. Do not use this parameter. |
+| `output_type` | [string](/versions/8.6.0/rules/lib/core/string); default is `'executable'`  Can be either 'executable' or 'dynamic_library'. |
+| `link_deps_statically` | [bool](/versions/8.6.0/rules/lib/core/bool); default is `True`  True to link dependencies statically, False dynamically. |
+| `compilation_outputs` | [CcCompilationOutputs](/versions/8.6.0/rules/lib/builtins/CcCompilationOutputs); or `None`; default is `None`  Compilation outputs containing object files to link. |
+| `linking_contexts` | [sequence](/versions/8.6.0/rules/lib/core/list); default is `[]`  Linking contexts from dependencies to be linked into the linking context generated by this rule. |
+| `user_link_flags` | [sequence](/versions/8.6.0/rules/lib/core/list); default is `[]`  Additional list of linker options. |
+| `stamp` | [int](/versions/8.6.0/rules/lib/core/int); default is `0`  Whether to include build information in the linked executable, if output_type is 'executable'. If 1, build information is always included. If 0 (the default build information is always excluded. If -1, uses the default behavior, which may be overridden by the --[no]stamp flag. This should be unset (or set to 0) when generating the executable output for test rules. |
+| `additional_inputs` | [sequence](/versions/8.6.0/rules/lib/core/list); or [depset](/versions/8.6.0/rules/lib/builtins/depset); default is `[]`  For additional inputs to the linking action, e.g.: linking scripts. |
+| `additional_outputs` | [sequence](/versions/8.6.0/rules/lib/core/list); default is `[]`  For additional outputs to the linking action, e.g.: map files. |
+| `variables_extension` | [dict](/versions/8.6.0/rules/lib/core/dict); default is `{}`  Additional variables to pass to the toolchain configuration when create link command line. |
 
 ## merge_compilation_contexts
 
@@ -448,7 +448,7 @@ Merges multiple `CompilationContexts`s into one.
 
 | Parameter | Description |
 | --- | --- |
-| `compilation_contexts` | [sequence](../core/list); default is `[]`  List of `CompilationContexts`s to be merged. The headers of each context will be exported by the direct fields in the returned provider. |
+| `compilation_contexts` | [sequence](/versions/8.6.0/rules/lib/core/list); default is `[]`  List of `CompilationContexts`s to be merged. The headers of each context will be exported by the direct fields in the returned provider. |
 
 ## merge_compilation_outputs
 
@@ -462,4 +462,4 @@ Merge compilation outputs.
 
 | Parameter | Description |
 | --- | --- |
-| `compilation_outputs` | [sequence](../core/list); default is `[]` |
\ No newline at end of file
+| `compilation_outputs` | [sequence](/versions/8.6.0/rules/lib/core/list); default is `[]` |
\ No newline at end of file
diff --git a/versions/8.6.0/rules/lib/toplevel/config.mdx b/versions/8.6.0/rules/lib/toplevel/config.mdx
index f767ed53..5b84301a 100644
--- a/versions/8.6.0/rules/lib/toplevel/config.mdx
+++ b/versions/8.6.0/rules/lib/toplevel/config.mdx
@@ -36,7 +36,7 @@ A bool-typed build setting
 
 | Parameter | Description |
 | --- | --- |
-| `flag` | [bool](../core/bool); default is `False` |
+| `flag` | [bool](/versions/8.6.0/rules/lib/core/bool); default is `False` |
 
 ## exec
 
@@ -50,7 +50,7 @@ Creates an execution transition.
 
 | Parameter | Description |
 | --- | --- |
-| `exec_group` | [string](../core/string); or `None`; default is `None`  The name of the exec group whose execution platform this transition will use. If not provided, this exec transition will use the target's default execution platform. |
+| `exec_group` | [string](/versions/8.6.0/rules/lib/core/string); or `None`; default is `None`  The name of the exec group whose execution platform this transition will use. If not provided, this exec transition will use the target's default execution platform. |
 
 ## int
 
@@ -64,7 +64,7 @@ An integer-typed build setting
 
 | Parameter | Description |
 | --- | --- |
-| `flag` | [bool](../core/bool); default is `False`  Whether or not this build setting is callable on the command line. |
+| `flag` | [bool](/versions/8.6.0/rules/lib/core/bool); default is `False`  Whether or not this build setting is callable on the command line. |
 
 ## none
 
@@ -86,8 +86,8 @@ A string-typed build setting
 
 | Parameter | Description |
 | --- | --- |
-| `flag` | [bool](../core/bool); default is `False`  Whether or not this build setting is callable on the command line. |
-| `allow_multiple` | [bool](../core/bool); default is `False`  Deprecated, use a `string_list` setting with `repeatable = True` instead. If set, this flag is allowed to be set multiple times on the command line. The Value of the flag as accessed in transitions and build setting implementation function will be a list of strings. Insertion order and repeated values are both maintained. This list can be post-processed in the build setting implementation function if different behavior is desired. |
+| `flag` | [bool](/versions/8.6.0/rules/lib/core/bool); default is `False`  Whether or not this build setting is callable on the command line. |
+| `allow_multiple` | [bool](/versions/8.6.0/rules/lib/core/bool); default is `False`  Deprecated, use a `string_list` setting with `repeatable = True` instead. If set, this flag is allowed to be set multiple times on the command line. The Value of the flag as accessed in transitions and build setting implementation function will be a list of strings. Insertion order and repeated values are both maintained. This list can be post-processed in the build setting implementation function if different behavior is desired. |
 
 ## string_list
 
@@ -101,8 +101,8 @@ A string list-typed build setting. On the command line pass a list using comma-s
 
 | Parameter | Description |
 | --- | --- |
-| `flag` | [bool](../core/bool); default is `False`  Whether or not this build setting is callable on the command line. |
-| `repeatable` | [bool](../core/bool); default is `False`  If set, instead of expecting a comma-separated value, this flag is allowed to be set multiple times on the command line with each individual value treated as a single string to add to the list value. Insertion order and repeated values are both maintained. This list can be post-processed in the build setting implementation function if different behavior is desired. |
+| `flag` | [bool](/versions/8.6.0/rules/lib/core/bool); default is `False`  Whether or not this build setting is callable on the command line. |
+| `repeatable` | [bool](/versions/8.6.0/rules/lib/core/bool); default is `False`  If set, instead of expecting a comma-separated value, this flag is allowed to be set multiple times on the command line with each individual value treated as a single string to add to the list value. Insertion order and repeated values are both maintained. This list can be post-processed in the build setting implementation function if different behavior is desired. |
 
 ## target
 
diff --git a/versions/8.6.0/rules/lib/toplevel/config_common.mdx b/versions/8.6.0/rules/lib/toplevel/config_common.mdx
index ffdab483..f9829f0e 100644
--- a/versions/8.6.0/rules/lib/toplevel/config_common.mdx
+++ b/versions/8.6.0/rules/lib/toplevel/config_common.mdx
@@ -29,5 +29,5 @@ Declare a rule's dependency on a toolchain type.
 
 | Parameter | Description |
 | --- | --- |
-| `name` | [string](../core/string); or [Label](../builtins/Label); required  The toolchain type that is required. |
-| `mandatory` | [bool](../core/bool); default is `True`  Whether the toolchain type is mandatory or optional. |
\ No newline at end of file
+| `name` | [string](/versions/8.6.0/rules/lib/core/string); or [Label](/versions/8.6.0/rules/lib/builtins/Label); required  The toolchain type that is required. |
+| `mandatory` | [bool](/versions/8.6.0/rules/lib/core/bool); default is `True`  Whether the toolchain type is mandatory or optional. |
\ No newline at end of file
diff --git a/versions/8.6.0/rules/lib/toplevel/coverage_common.mdx b/versions/8.6.0/rules/lib/toplevel/coverage_common.mdx
index 161aa720..4c8955e1 100644
--- a/versions/8.6.0/rules/lib/toplevel/coverage_common.mdx
+++ b/versions/8.6.0/rules/lib/toplevel/coverage_common.mdx
@@ -14,14 +14,14 @@ Helper functions to access coverage-related infrastructure.
 InstrumentedFilesInfo coverage_common.instrumented_files_info(ctx, *, source_attributes=[], dependency_attributes=[], extensions=None, metadata_files=[])
 ```
 
-Creates a new [InstrumentedFilesInfo](../providers/InstrumentedFilesInfo) instance. Use this provider to communicate coverage-related attributes of the current build rule.
+Creates a new [InstrumentedFilesInfo](/versions/8.6.0/rules/lib/providers/InstrumentedFilesInfo) instance. Use this provider to communicate coverage-related attributes of the current build rule.
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `ctx` | [ctx](../builtins/ctx); required  The rule context. |
-| `source_attributes` | [sequence](../core/list); default is `[]`  A list of attribute names which contain source files processed by this rule. |
-| `dependency_attributes` | [sequence](../core/list); default is `[]`  A list of attribute names which might provide runtime dependencies (either code dependencies or runfiles). |
-| `extensions` | [sequence](../core/list) of [string](../core/string)s; or `None`; default is `None`  File extensions used to filter files from source_attributes. For example, 'js'. If not provided (or None), then all files from source_attributes will be added to instrumented files, if an empty list is provided, then no files from source attributes will be added. |
-| `metadata_files` | [sequence](../core/list) of [File](../builtins/File)s; default is `[]`  Additional files required to generate coverage LCOV files after code execution. e.g. .gcno files for C++. |
\ No newline at end of file
+| `ctx` | [ctx](/versions/8.6.0/rules/lib/builtins/ctx); required  The rule context. |
+| `source_attributes` | [sequence](/versions/8.6.0/rules/lib/core/list); default is `[]`  A list of attribute names which contain source files processed by this rule. |
+| `dependency_attributes` | [sequence](/versions/8.6.0/rules/lib/core/list); default is `[]`  A list of attribute names which might provide runtime dependencies (either code dependencies or runfiles). |
+| `extensions` | [sequence](/versions/8.6.0/rules/lib/core/list) of [string](/versions/8.6.0/rules/lib/core/string)s; or `None`; default is `None`  File extensions used to filter files from source_attributes. For example, 'js'. If not provided (or None), then all files from source_attributes will be added to instrumented files, if an empty list is provided, then no files from source attributes will be added. |
+| `metadata_files` | [sequence](/versions/8.6.0/rules/lib/core/list) of [File](/versions/8.6.0/rules/lib/builtins/File)s; default is `[]`  Additional files required to generate coverage LCOV files after code execution. e.g. .gcno files for C++. |
\ No newline at end of file
diff --git a/versions/8.6.0/rules/lib/toplevel/java_common.mdx b/versions/8.6.0/rules/lib/toplevel/java_common.mdx
index 8d7291cc..27d4ba96 100644
--- a/versions/8.6.0/rules/lib/toplevel/java_common.mdx
+++ b/versions/8.6.0/rules/lib/toplevel/java_common.mdx
@@ -35,33 +35,33 @@ Compiles Java source files/jars from the implementation of a Starlark rule and r
 
 | Parameter | Description |
 | --- | --- |
-| `ctx` | [ctx](../builtins/ctx); required  The rule context. |
-| `source_jars` | [sequence](../core/list) of [File](../builtins/File)s; default is `[]`  A list of the jars to be compiled. At least one of source_jars or source_files should be specified. |
-| `source_files` | [sequence](../core/list) of [File](../builtins/File)s; default is `[]`  A list of the Java source files to be compiled. At least one of source_jars or source_files should be specified. |
-| `output` | [File](../builtins/File); required |
-| `output_source_jar` | [File](../builtins/File); or `None`; default is `None`  The output source jar. Defaults to `{output_jar}-src.jar` if unset. |
-| `javac_opts` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  A list of the desired javac options. |
-| `deps` | [sequence](../core/list) of [struct](../builtins/struct)s; default is `[]`  A list of dependencies. |
-| `runtime_deps` | [sequence](../core/list) of [struct](../builtins/struct)s; default is `[]`  A list of runtime dependencies. |
-| `exports` | [sequence](../core/list) of [struct](../builtins/struct)s; default is `[]`  A list of exports. |
-| `plugins` | [sequence](../core/list) of [struct](../builtins/struct)s; or [sequence](../core/list) of [struct](../builtins/struct)s; default is `[]`  A list of plugins. |
-| `exported_plugins` | [sequence](../core/list) of [struct](../builtins/struct)s; or [sequence](../core/list) of [struct](../builtins/struct)s; default is `[]`  A list of exported plugins. |
-| `native_libraries` | [sequence](../core/list) of [CcInfo](../providers/CcInfo)s; default is `[]`  CC native library dependencies that are needed for this library. |
-| `annotation_processor_additional_inputs` | [sequence](../core/list) of [File](../builtins/File)s; default is `[]`  A list of inputs that the Java compilation action will take in addition to the Java sources for annotation processing. |
-| `annotation_processor_additional_outputs` | [sequence](../core/list) of [File](../builtins/File)s; default is `[]`  A list of outputs that the Java compilation action will output in addition to the class jar from annotation processing. |
-| `strict_deps` | [string](../core/string); default is `'ERROR'`  A string that specifies how to handle strict deps. Possible values: 'OFF', 'ERROR', 'WARN' and 'DEFAULT'. For more details see [`--strict_java_deps flag`](/docs/user-manual#flag--strict_java_deps). By default 'ERROR'. |
+| `ctx` | [ctx](/versions/8.6.0/rules/lib/builtins/ctx); required  The rule context. |
+| `source_jars` | [sequence](/versions/8.6.0/rules/lib/core/list) of [File](/versions/8.6.0/rules/lib/builtins/File)s; default is `[]`  A list of the jars to be compiled. At least one of source_jars or source_files should be specified. |
+| `source_files` | [sequence](/versions/8.6.0/rules/lib/core/list) of [File](/versions/8.6.0/rules/lib/builtins/File)s; default is `[]`  A list of the Java source files to be compiled. At least one of source_jars or source_files should be specified. |
+| `output` | [File](/versions/8.6.0/rules/lib/builtins/File); required |
+| `output_source_jar` | [File](/versions/8.6.0/rules/lib/builtins/File); or `None`; default is `None`  The output source jar. Defaults to `{output_jar}-src.jar` if unset. |
+| `javac_opts` | [sequence](/versions/8.6.0/rules/lib/core/list) of [string](/versions/8.6.0/rules/lib/core/string)s; default is `[]`  A list of the desired javac options. |
+| `deps` | [sequence](/versions/8.6.0/rules/lib/core/list) of [struct](/versions/8.6.0/rules/lib/builtins/struct)s; default is `[]`  A list of dependencies. |
+| `runtime_deps` | [sequence](/versions/8.6.0/rules/lib/core/list) of [struct](/versions/8.6.0/rules/lib/builtins/struct)s; default is `[]`  A list of runtime dependencies. |
+| `exports` | [sequence](/versions/8.6.0/rules/lib/core/list) of [struct](/versions/8.6.0/rules/lib/builtins/struct)s; default is `[]`  A list of exports. |
+| `plugins` | [sequence](/versions/8.6.0/rules/lib/core/list) of [struct](/versions/8.6.0/rules/lib/builtins/struct)s; or [sequence](/versions/8.6.0/rules/lib/core/list) of [struct](/versions/8.6.0/rules/lib/builtins/struct)s; default is `[]`  A list of plugins. |
+| `exported_plugins` | [sequence](/versions/8.6.0/rules/lib/core/list) of [struct](/versions/8.6.0/rules/lib/builtins/struct)s; or [sequence](/versions/8.6.0/rules/lib/core/list) of [struct](/versions/8.6.0/rules/lib/builtins/struct)s; default is `[]`  A list of exported plugins. |
+| `native_libraries` | [sequence](/versions/8.6.0/rules/lib/core/list) of [CcInfo](/versions/8.6.0/rules/lib/providers/CcInfo)s; default is `[]`  CC native library dependencies that are needed for this library. |
+| `annotation_processor_additional_inputs` | [sequence](/versions/8.6.0/rules/lib/core/list) of [File](/versions/8.6.0/rules/lib/builtins/File)s; default is `[]`  A list of inputs that the Java compilation action will take in addition to the Java sources for annotation processing. |
+| `annotation_processor_additional_outputs` | [sequence](/versions/8.6.0/rules/lib/core/list) of [File](/versions/8.6.0/rules/lib/builtins/File)s; default is `[]`  A list of outputs that the Java compilation action will output in addition to the class jar from annotation processing. |
+| `strict_deps` | [string](/versions/8.6.0/rules/lib/core/string); default is `'ERROR'`  A string that specifies how to handle strict deps. Possible values: 'OFF', 'ERROR', 'WARN' and 'DEFAULT'. For more details see [`--strict_java_deps flag`](/versions/8.6.0/docs/user-manual#flag--strict_java_deps). By default 'ERROR'. |
 | `java_toolchain` | Info; required  A JavaToolchainInfo to be used for this compilation. Mandatory. |
 | `bootclasspath` | default is `None`  A BootClassPathInfo to be used for this compilation. If present, overrides the bootclasspath associated with the provided java_toolchain. |
 | `host_javabase` | default is `None`  **Deprecated**. This parameter is deprecated and will be removed soon. Please do not depend on it. It is *disabled* with `--incompatible_java_common_parameters`. Use this flag to verify your code is compatible with its imminent removal.  Deprecated: You can drop this parameter (host_javabase is provided with java_toolchain) |
-| `sourcepath` | [sequence](../core/list) of [File](../builtins/File)s; default is `[]` |
-| `resources` | [sequence](../core/list) of [File](../builtins/File)s; default is `[]` |
-| `resource_jars` | [sequence](../core/list) of [File](../builtins/File)s; default is `[]` |
-| `classpath_resources` | [sequence](../core/list) of [File](../builtins/File)s; default is `[]` |
-| `neverlink` | [bool](../core/bool); default is `False` |
-| `enable_annotation_processing` | [bool](../core/bool); default is `True`  Disables annotation processing in this compilation, causing any annotation processors provided in plugins or in exported_plugins of deps to be ignored. |
-| `enable_compile_jar_action` | [bool](../core/bool); default is `True`  Enables header compilation or ijar creation. If set to False, it forces use of the full class jar in the compilation classpaths of any dependants. Doing so is intended for use by non-library targets such as binaries that do not have dependants. |
-| `add_exports` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  Allow this library to access the given /. |
-| `add_opens` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  Allow this library to reflectively access the given /. |
+| `sourcepath` | [sequence](/versions/8.6.0/rules/lib/core/list) of [File](/versions/8.6.0/rules/lib/builtins/File)s; default is `[]` |
+| `resources` | [sequence](/versions/8.6.0/rules/lib/core/list) of [File](/versions/8.6.0/rules/lib/builtins/File)s; default is `[]` |
+| `resource_jars` | [sequence](/versions/8.6.0/rules/lib/core/list) of [File](/versions/8.6.0/rules/lib/builtins/File)s; default is `[]` |
+| `classpath_resources` | [sequence](/versions/8.6.0/rules/lib/core/list) of [File](/versions/8.6.0/rules/lib/builtins/File)s; default is `[]` |
+| `neverlink` | [bool](/versions/8.6.0/rules/lib/core/bool); default is `False` |
+| `enable_annotation_processing` | [bool](/versions/8.6.0/rules/lib/core/bool); default is `True`  Disables annotation processing in this compilation, causing any annotation processors provided in plugins or in exported_plugins of deps to be ignored. |
+| `enable_compile_jar_action` | [bool](/versions/8.6.0/rules/lib/core/bool); default is `True`  Enables header compilation or ijar creation. If set to False, it forces use of the full class jar in the compilation classpaths of any dependants. Doing so is intended for use by non-library targets such as binaries that do not have dependants. |
+| `add_exports` | [sequence](/versions/8.6.0/rules/lib/core/list) of [string](/versions/8.6.0/rules/lib/core/string)s; default is `[]`  Allow this library to access the given /. |
+| `add_opens` | [sequence](/versions/8.6.0/rules/lib/core/list) of [string](/versions/8.6.0/rules/lib/core/string)s; default is `[]`  Allow this library to reflectively access the given /. |
 
 ## JavaRuntimeInfo
 
@@ -91,7 +91,7 @@ Merges the given providers into a single JavaInfo.
 
 | Parameter | Description |
 | --- | --- |
-| `providers` | [sequence](../core/list) of [struct](../builtins/struct)s; required  The list of providers to merge. |
+| `providers` | [sequence](/versions/8.6.0/rules/lib/core/list) of [struct](/versions/8.6.0/rules/lib/builtins/struct)s; required  The list of providers to merge. |
 
 ## pack_sources
 
@@ -109,11 +109,11 @@ Packs sources and source jars into a single source jar file. The return value is
 
 | Parameter | Description |
 | --- | --- |
-| `actions` | [actions](../builtins/actions); required  ctx.actions |
-| `output_jar` | [File](../builtins/File); or `None`; default is `None`  **Deprecated**. This parameter is deprecated and will be removed soon. Please do not depend on it. It is *disabled* with `--incompatible_java_common_parameters`. Use this flag to verify your code is compatible with its imminent removal.  Deprecated: The output jar of the rule. Used to name the resulting source jar. The parameter sets output_source_jar parameter to `{output_jar}-src.jar`.Use output_source_jar parameter directly instead. |
-| `output_source_jar` | [File](../builtins/File); or `None`; default is `None` |
-| `sources` | [sequence](../core/list) of [File](../builtins/File)s; default is `[]`  A list of Java source files to be packed into the source jar. |
-| `source_jars` | [sequence](../core/list) of [File](../builtins/File)s; default is `[]`  A list of source jars to be packed into the source jar. |
+| `actions` | [actions](/versions/8.6.0/rules/lib/builtins/actions); required  ctx.actions |
+| `output_jar` | [File](/versions/8.6.0/rules/lib/builtins/File); or `None`; default is `None`  **Deprecated**. This parameter is deprecated and will be removed soon. Please do not depend on it. It is *disabled* with `--incompatible_java_common_parameters`. Use this flag to verify your code is compatible with its imminent removal.  Deprecated: The output jar of the rule. Used to name the resulting source jar. The parameter sets output_source_jar parameter to `{output_jar}-src.jar`.Use output_source_jar parameter directly instead. |
+| `output_source_jar` | [File](/versions/8.6.0/rules/lib/builtins/File); or `None`; default is `None` |
+| `sources` | [sequence](/versions/8.6.0/rules/lib/core/list) of [File](/versions/8.6.0/rules/lib/builtins/File)s; default is `[]`  A list of Java source files to be packed into the source jar. |
+| `source_jars` | [sequence](/versions/8.6.0/rules/lib/core/list) of [File](/versions/8.6.0/rules/lib/builtins/File)s; default is `[]`  A list of source jars to be packed into the source jar. |
 | `java_toolchain` | Info; required  A JavaToolchainInfo to used to find the ijar tool. |
 | `host_javabase` | default is `None`  **Deprecated**. This parameter is deprecated and will be removed soon. Please do not depend on it. It is *disabled* with `--incompatible_java_common_parameters`. Use this flag to verify your code is compatible with its imminent removal.  Deprecated: You can drop this parameter (host_javabase is provided with java_toolchain) |
 
@@ -129,9 +129,9 @@ Runs ijar on a jar, stripping it of its method bodies. This helps reduce rebuild
 
 | Parameter | Description |
 | --- | --- |
-| `actions` | [actions](../builtins/actions); required |
-| `jar` | [File](../builtins/File); required  The jar to run ijar on. |
-| `target_label` | [Label](../builtins/Label); or `None`; default is `None`  A target label to stamp the jar with. Used for `add_dep` support. Typically, you would pass `ctx.label` to stamp the jar with the current rule's label. |
+| `actions` | [actions](/versions/8.6.0/rules/lib/builtins/actions); required |
+| `jar` | [File](/versions/8.6.0/rules/lib/builtins/File); required  The jar to run ijar on. |
+| `target_label` | [Label](/versions/8.6.0/rules/lib/builtins/Label); or `None`; default is `None`  A target label to stamp the jar with. Used for `add_dep` support. Typically, you would pass `ctx.label` to stamp the jar with the current rule's label. |
 | `java_toolchain` | Info; required  A JavaToolchainInfo to used to find the ijar tool. |
 
 ## stamp_jar
@@ -146,7 +146,7 @@ Stamps a jar with a target label for `add_dep` support. The return value is typi
 
 | Parameter | Description |
 | --- | --- |
-| `actions` | [actions](../builtins/actions); required  ctx.actions |
-| `jar` | [File](../builtins/File); required  The jar to run stamp_jar on. |
-| `target_label` | [Label](../builtins/Label); required  A target label to stamp the jar with. Used for `add_dep` support. Typically, you would pass `ctx.label` to stamp the jar with the current rule's label. |
+| `actions` | [actions](/versions/8.6.0/rules/lib/builtins/actions); required  ctx.actions |
+| `jar` | [File](/versions/8.6.0/rules/lib/builtins/File); required  The jar to run stamp_jar on. |
+| `target_label` | [Label](/versions/8.6.0/rules/lib/builtins/Label); required  A target label to stamp the jar with. Used for `add_dep` support. Typically, you would pass `ctx.label` to stamp the jar with the current rule's label. |
 | `java_toolchain` | Info; required  A JavaToolchainInfo to used to find the stamp_jar tool. |
\ No newline at end of file
diff --git a/versions/8.6.0/rules/lib/toplevel/native.mdx b/versions/8.6.0/rules/lib/toplevel/native.mdx
index ddd88fb5..53eb2e9a 100644
--- a/versions/8.6.0/rules/lib/toplevel/native.mdx
+++ b/versions/8.6.0/rules/lib/toplevel/native.mdx
@@ -46,7 +46,7 @@ If possible, avoid using this function. It makes BUILD files brittle and order-d
 
 | Parameter | Description |
 | --- | --- |
-| `name` | [string](../core/string); required |
+| `name` | [string](/versions/8.6.0/rules/lib/core/string); required |
 
 ## existing_rules
 
@@ -72,9 +72,9 @@ Specifies a list of files belonging to this package that are exported to other p
 
 | Parameter | Description |
 | --- | --- |
-| `srcs` | [sequence](../core/list) of [string](../core/string)s; required  The list of files to export. |
-| `visibility` | [sequence](../core/list); or `None`; default is `None`  A visibility declaration can to be specified. The files will be visible to the targets specified. If no visibility is specified, the files will be visible to every package. |
-| `licenses` | [sequence](../core/list) of [string](../core/string)s; or `None`; default is `None`  Licenses to be specified. |
+| `srcs` | [sequence](/versions/8.6.0/rules/lib/core/list) of [string](/versions/8.6.0/rules/lib/core/string)s; required  The list of files to export. |
+| `visibility` | [sequence](/versions/8.6.0/rules/lib/core/list); or `None`; default is `None`  A visibility declaration can to be specified. The files will be visible to the targets specified. If no visibility is specified, the files will be visible to every package. |
+| `licenses` | [sequence](/versions/8.6.0/rules/lib/core/list) of [string](/versions/8.6.0/rules/lib/core/string)s; or `None`; default is `None`  Licenses to be specified. |
 
 ## glob
 
@@ -93,9 +93,9 @@ If the `exclude_directories` argument is enabled (set to `1`), files of type dir
 
 | Parameter | Description |
 | --- | --- |
-| `include` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  The list of glob patterns to include. |
-| `exclude` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  The list of glob patterns to exclude. |
-| `exclude_directories` | [int](../core/int); default is `1`  A flag whether to exclude directories or not. |
+| `include` | [sequence](/versions/8.6.0/rules/lib/core/list) of [string](/versions/8.6.0/rules/lib/core/string)s; default is `[]`  The list of glob patterns to include. |
+| `exclude` | [sequence](/versions/8.6.0/rules/lib/core/list) of [string](/versions/8.6.0/rules/lib/core/string)s; default is `[]`  The list of glob patterns to exclude. |
+| `exclude_directories` | [int](/versions/8.6.0/rules/lib/core/int); default is `1`  A flag whether to exclude directories or not. |
 | `allow_empty` | default is `unbound`  Whether we allow glob patterns to match nothing. If `allow_empty` is False, each individual include pattern must match something and also the final result must be non-empty (after the matches of the `exclude` patterns are excluded). |
 
 ## module_name
@@ -128,9 +128,9 @@ This function defines a set of packages and assigns a label to the group. The la
 
 | Parameter | Description |
 | --- | --- |
-| `name` | [string](../core/string); required  The unique name for this rule. |
-| `packages` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  A complete enumeration of packages in this group. |
-| `includes` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  Other package groups that are included in this one. |
+| `name` | [string](/versions/8.6.0/rules/lib/core/string); required  The unique name for this rule. |
+| `packages` | [sequence](/versions/8.6.0/rules/lib/core/list) of [string](/versions/8.6.0/rules/lib/core/string)s; default is `[]`  A complete enumeration of packages in this group. |
+| `includes` | [sequence](/versions/8.6.0/rules/lib/core/list) of [string](/versions/8.6.0/rules/lib/core/string)s; default is `[]`  Other package groups that are included in this one. |
 
 ## package_name
 
@@ -146,19 +146,19 @@ The name of the package being evaluated, without the repository name. For exampl
 Label native.package_relative_label(input)
 ```
 
-Converts the input string into a [Label](../builtins/Label) object, in the context of the package currently being initialized (that is, the `BUILD` file for which the current macro is executing). If the input is already a `Label`, it is returned unchanged.
+Converts the input string into a [Label](/versions/8.6.0/rules/lib/builtins/Label) object, in the context of the package currently being initialized (that is, the `BUILD` file for which the current macro is executing). If the input is already a `Label`, it is returned unchanged.
 
 This function may only be called while evaluating a BUILD file and the macros it directly or indirectly calls; it may not be called in (for instance) a rule implementation function.
 
 The result of this function is the same `Label` value as would be produced by passing the given string to a label-valued attribute of a target declared in the BUILD file.
 
-*Usage note:* The difference between this function and [Label()](../builtins/Label#Label) is that `Label()` uses the context of the package of the `.bzl` file that called it, not the package of the `BUILD` file. Use `Label()` when you need to refer to a fixed target that is hardcoded into the macro, such as a compiler. Use `package_relative_label()` when you need to normalize a label string supplied by the BUILD file to a `Label` object. (There is no way to convert a string to a `Label` in the context of a package other than the BUILD file or the calling .bzl file. For that reason, outer macros should always prefer to pass Label objects to inner macros rather than label strings.)
+*Usage note:* The difference between this function and [Label()](/versions/8.6.0/rules/lib/builtins/Label#Label) is that `Label()` uses the context of the package of the `.bzl` file that called it, not the package of the `BUILD` file. Use `Label()` when you need to refer to a fixed target that is hardcoded into the macro, such as a compiler. Use `package_relative_label()` when you need to normalize a label string supplied by the BUILD file to a `Label` object. (There is no way to convert a string to a `Label` in the context of a package other than the BUILD file or the calling .bzl file. For that reason, outer macros should always prefer to pass Label objects to inner macros rather than label strings.)
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `input` | [string](../core/string); or [Label](../builtins/Label); required  The input label string or Label object. If a Label object is passed, it's returned as is. |
+| `input` | [string](/versions/8.6.0/rules/lib/core/string); or [Label](/versions/8.6.0/rules/lib/builtins/Label); required  The input label string or Label object. If a Label object is passed, it's returned as is. |
 
 ## repo_name
 
@@ -191,6 +191,6 @@ Returns a new mutable list of every direct subpackage of the current package, re
 
 | Parameter | Description |
 | --- | --- |
-| `include` | [sequence](../core/list) of [string](../core/string)s; required |
-| `exclude` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  The list of glob patterns to exclude from subpackages scan. |
-| `allow_empty` | [bool](../core/bool); default is `False`  Whether we fail if the call returns an empty list. By default empty list indicates potential error in BUILD file where the call to subpackages() is superflous. Setting to true allows this function to succeed in that case. |*
\ No newline at end of file
+| `include` | [sequence](/versions/8.6.0/rules/lib/core/list) of [string](/versions/8.6.0/rules/lib/core/string)s; required |
+| `exclude` | [sequence](/versions/8.6.0/rules/lib/core/list) of [string](/versions/8.6.0/rules/lib/core/string)s; default is `[]`  The list of glob patterns to exclude from subpackages scan. |
+| `allow_empty` | [bool](/versions/8.6.0/rules/lib/core/bool); default is `False`  Whether we fail if the call returns an empty list. By default empty list indicates potential error in BUILD file where the call to subpackages() is superflous. Setting to true allows this function to succeed in that case. |*
\ No newline at end of file
diff --git a/versions/8.6.0/rules/lib/toplevel/platform_common.mdx b/versions/8.6.0/rules/lib/toplevel/platform_common.mdx
index 098f56fb..d97c60bb 100644
--- a/versions/8.6.0/rules/lib/toplevel/platform_common.mdx
+++ b/versions/8.6.0/rules/lib/toplevel/platform_common.mdx
@@ -18,7 +18,7 @@ Functions for Starlark to interact with the platform APIs.
 Provider platform_common.ConstraintSettingInfo
 ```
 
-The constructor/key for the [ConstraintSettingInfo](../providers/ConstraintSettingInfo) provider.
+The constructor/key for the [ConstraintSettingInfo](/versions/8.6.0/rules/lib/providers/ConstraintSettingInfo) provider.
 *Note: This API is experimental and may change at any time. It is disabled by default, but may be enabled with `--experimental_platforms_api`*
 
 ## ConstraintValueInfo
@@ -27,7 +27,7 @@ The constructor/key for the [ConstraintSettingInfo](../providers/ConstraintSetti
 Provider platform_common.ConstraintValueInfo
 ```
 
-The constructor/key for the [ConstraintValueInfo](../providers/ConstraintValueInfo) provider.
+The constructor/key for the [ConstraintValueInfo](/versions/8.6.0/rules/lib/providers/ConstraintValueInfo) provider.
 *Note: This API is experimental and may change at any time. It is disabled by default, but may be enabled with `--experimental_platforms_api`*
 
 ## PlatformInfo
@@ -36,7 +36,7 @@ The constructor/key for the [ConstraintValueInfo](../providers/ConstraintValueIn
 Provider platform_common.PlatformInfo
 ```
 
-The constructor/key for the [PlatformInfo](../providers/PlatformInfo) provider.
+The constructor/key for the [PlatformInfo](/versions/8.6.0/rules/lib/providers/PlatformInfo) provider.
 *Note: This API is experimental and may change at any time. It is disabled by default, but may be enabled with `--experimental_platforms_api`*
 
 ## TemplateVariableInfo
@@ -45,7 +45,7 @@ The constructor/key for the [PlatformInfo](../providers/PlatformInfo) provider.
 Provider platform_common.TemplateVariableInfo
 ```
 
-The constructor/key for the [TemplateVariableInfo](../providers/TemplateVariableInfo) provider.
+The constructor/key for the [TemplateVariableInfo](/versions/8.6.0/rules/lib/providers/TemplateVariableInfo) provider.
 
 ## ToolchainInfo
 
@@ -53,4 +53,4 @@ The constructor/key for the [TemplateVariableInfo](../providers/TemplateVariable
 Provider platform_common.ToolchainInfo
 ```
 
-The constructor/key for the [ToolchainInfo](../providers/ToolchainInfo) provider.
\ No newline at end of file
+The constructor/key for the [ToolchainInfo](/versions/8.6.0/rules/lib/providers/ToolchainInfo) provider.
\ No newline at end of file
diff --git a/versions/8.6.0/rules/lib/toplevel/testing.mdx b/versions/8.6.0/rules/lib/toplevel/testing.mdx
index 0b70d61b..895bd458 100644
--- a/versions/8.6.0/rules/lib/toplevel/testing.mdx
+++ b/versions/8.6.0/rules/lib/toplevel/testing.mdx
@@ -24,12 +24,12 @@ The number of transitive dependencies of the test are limited. The limit is cont
 
 | Parameter | Description |
 | --- | --- |
-| `name` | [string](../core/string); required  Name of the target. It should be a Starlark identifier, matching pattern '[A-Za-z\_][A-Za-z0-9\_]\*'. |
-| `implementation` | [function](../core/function); required  The Starlark function implementing this analysis test. It must have exactly one parameter: [ctx](../builtins/ctx). The function is called during the analysis phase. It can access the attributes declared by `attrs` and populated via `attr_values`. The implementation function may not register actions. Instead, it must register a pass/fail result via providing [AnalysisTestResultInfo](../providers/AnalysisTestResultInfo). |
-| `attrs` | [dict](../core/dict); default is `{}`  Dictionary declaring the attributes. See the [rule](../globals/bzl#rule) call. Attributes are allowed to use configuration transitions defined using [analysis_test_transition](../globals/bzl#analysis_test_transition). |
-| `fragments` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  List of configuration fragments that are available to the implementation of the analysis test. |
-| `toolchains` | [sequence](../core/list); default is `[]`  The set of toolchains the test requires. See the [rule](../globals/bzl#rule) call. |
-| `attr_values` | [dict](../core/dict) of [string](../core/string)s; default is `{}`  Dictionary of attribute values to pass to the implementation. |
+| `name` | [string](/versions/8.6.0/rules/lib/core/string); required  Name of the target. It should be a Starlark identifier, matching pattern '[A-Za-z\_][A-Za-z0-9\_]\*'. |
+| `implementation` | [function](/versions/8.6.0/rules/lib/core/function); required  The Starlark function implementing this analysis test. It must have exactly one parameter: [ctx](/versions/8.6.0/rules/lib/builtins/ctx). The function is called during the analysis phase. It can access the attributes declared by `attrs` and populated via `attr_values`. The implementation function may not register actions. Instead, it must register a pass/fail result via providing [AnalysisTestResultInfo](/versions/8.6.0/rules/lib/providers/AnalysisTestResultInfo). |
+| `attrs` | [dict](/versions/8.6.0/rules/lib/core/dict); default is `{}`  Dictionary declaring the attributes. See the [rule](/versions/8.6.0/rules/lib/globals/bzl#rule) call. Attributes are allowed to use configuration transitions defined using [analysis_test_transition](/versions/8.6.0/rules/lib/globals/bzl#analysis_test_transition). |
+| `fragments` | [sequence](/versions/8.6.0/rules/lib/core/list) of [string](/versions/8.6.0/rules/lib/core/string)s; default is `[]`  List of configuration fragments that are available to the implementation of the analysis test. |
+| `toolchains` | [sequence](/versions/8.6.0/rules/lib/core/list); default is `[]`  The set of toolchains the test requires. See the [rule](/versions/8.6.0/rules/lib/globals/bzl#rule) call. |
+| `attr_values` | [dict](/versions/8.6.0/rules/lib/core/dict) of [string](/versions/8.6.0/rules/lib/core/string)s; default is `{}`  Dictionary of attribute values to pass to the implementation. |
 
 ## ExecutionInfo
 
@@ -37,7 +37,7 @@ The number of transitive dependencies of the test are limited. The limit is cont
 ExecutionInfo testing.ExecutionInfo
 ```
 
-[testing.ExecutionInfo](../providers/ExecutionInfo) provider key/constructor
+[testing.ExecutionInfo](/versions/8.6.0/rules/lib/providers/ExecutionInfo) provider key/constructor
 
 ## TestEnvironment
 
@@ -51,5 +51,5 @@ RunEnvironmentInfo testing.TestEnvironment(environment, inherited_environment=[]
 
 | Parameter | Description |
 | --- | --- |
-| `environment` | [dict](../core/dict); required  A map of string keys and values that represent environment variables and their values. These will be made available during the test execution. |
-| `inherited_environment` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  A sequence of names of environment variables. These variables are made available during the test execution with their current value taken from the shell environment. If a variable is contained in both `environment` and `inherited_environment`, the value inherited from the shell environment will take precedence if set. |
\ No newline at end of file
+| `environment` | [dict](/versions/8.6.0/rules/lib/core/dict); required  A map of string keys and values that represent environment variables and their values. These will be made available during the test execution. |
+| `inherited_environment` | [sequence](/versions/8.6.0/rules/lib/core/list) of [string](/versions/8.6.0/rules/lib/core/string)s; default is `[]`  A sequence of names of environment variables. These variables are made available during the test execution with their current value taken from the shell environment. If a variable is contained in both `environment` and `inherited_environment`, the value inherited from the shell environment will take precedence if set. |
\ No newline at end of file
diff --git a/versions/8.6.0/rules/macro-tutorial.mdx b/versions/8.6.0/rules/macro-tutorial.mdx
index b572c7a4..8b9da671 100644
--- a/versions/8.6.0/rules/macro-tutorial.mdx
+++ b/versions/8.6.0/rules/macro-tutorial.mdx
@@ -5,7 +5,7 @@ title: 'Creating a Symbolic Macro'
 IMPORTANT: This tutorial is for [*symbolic macros*](/versions/8.6.0/extending/macros) – the new
 macro system introduced in Bazel 8. If you need to support older Bazel versions,
 you will want to write a [legacy macro](/versions/8.6.0/extending/legacy-macros) instead; take
-a look at [Creating a Legacy Macro](../legacy-macro-tutorial).
+a look at [Creating a Legacy Macro](/versions/8.6.0/rules/legacy-macro-tutorial).
 
 Imagine that you need to run a tool as part of your build. For example, you
 may want to generate or preprocess a source file, or compress a binary. In this
diff --git a/versions/8.6.0/rules/performance.mdx b/versions/8.6.0/rules/performance.mdx
index 4ea7aa76..c44717a7 100644
--- a/versions/8.6.0/rules/performance.mdx
+++ b/versions/8.6.0/rules/performance.mdx
@@ -15,7 +15,7 @@ widespread use.
 ## Use depsets
 
 Whenever you are rolling up information from rule dependencies you should use
-[depsets](lib/depset). Only use plain lists or dicts to publish information
+[depsets](/versions/8.6.0/rules/lib/builtins/depset). Only use plain lists or dicts to publish information
 local to the current rule.
 
 A depset represents information as a nested graph which enables sharing.
@@ -73,7 +73,7 @@ See the [depset overview](/versions/8.6.0/extending/depsets) page for more infor
 ### Avoid calling `depset.to_list()`
 
 You can coerce a depset to a flat list using
-[`to_list()`](lib/depset#to_list), but doing so usually results in O(N^2)
+[`to_list()`](/versions/8.6.0/rules/lib/builtins/depset#to_list), but doing so usually results in O(N^2)
 cost. If at all possible, avoid any flattening of depsets except for debugging
 purposes.
 
@@ -115,7 +115,7 @@ x = depset(transitive = [i.deps for i in inputs])
 
 ## Use ctx.actions.args() for command lines
 
-When building command lines you should use [ctx.actions.args()](lib/Args).
+When building command lines you should use [ctx.actions.args()](/versions/8.6.0/rules/lib/builtins/Args).
 This defers expansion of any depsets to the execution phase.
 
 Apart from being strictly faster, this will reduce the memory consumption of
@@ -126,11 +126,11 @@ Here are some tricks:
 * Pass depsets and lists directly as arguments, instead of flattening them
 yourself. They will get expanded by `ctx.actions.args()` for you.
 If you need any transformations on the depset contents, look at
-[ctx.actions.args#add](lib/Args#add) to see if anything fits the bill.
+[ctx.actions.args#add](/versions/8.6.0/rules/lib/builtins/Args#add) to see if anything fits the bill.
 
 * Are you passing `File#path` as arguments? No need. Any
-[File](lib/File) is automatically turned into its
-[path](lib/File#path), deferred to expansion time.
+[File](/versions/8.6.0/rules/lib/builtins/File) is automatically turned into its
+[path](/versions/8.6.0/rules/lib/builtins/File#path), deferred to expansion time.
 
 * Avoid constructing strings by concatenating them together.
 The best string argument is a constant as its memory will be shared between
@@ -138,10 +138,10 @@ all instances of your rule.
 
 * If the args are too long for the command line an `ctx.actions.args()` object
 can be conditionally or unconditionally written to a param file using
-[`ctx.actions.args#use_param_file`](lib/Args#use_param_file). This is
+[`ctx.actions.args#use_param_file`](/versions/8.6.0/rules/lib/builtins/Args#use_param_file). This is
 done behind the scenes when the action is executed. If you need to explicitly
 control the params file you can write it manually using
-[`ctx.actions.write`](lib/actions#write).
+[`ctx.actions.write`](/versions/8.6.0/rules/lib/builtins/actions#write).
 
 Example:
 
@@ -176,7 +176,7 @@ def _to_short_path(f):
 
 ## Transitive action inputs should be depsets
 
-When building an action using [ctx.actions.run](lib/actions?#run), do not
+When building an action using [ctx.actions.run](/versions/8.6.0/rules/lib/builtins/actions#run), do not
 forget that the `inputs` field accepts a depset. Use this whenever inputs are
 collected from dependencies transitively.
 
diff --git a/versions/8.6.0/rules/rules-tutorial.mdx b/versions/8.6.0/rules/rules-tutorial.mdx
index f45cb5cb..54264796 100644
--- a/versions/8.6.0/rules/rules-tutorial.mdx
+++ b/versions/8.6.0/rules/rules-tutorial.mdx
@@ -32,9 +32,9 @@ foo_binary = rule(
 )
 ```
 
-When you call the [`rule`](lib/globals#rule) function, you
+When you call the [`rule`](/versions/8.6.0/rules/lib/globals#rule) function, you
 must define a callback function. The logic will go there, but you
-can leave the function empty for now. The [`ctx`](lib/ctx) argument
+can leave the function empty for now. The [`ctx`](/versions/8.6.0/rules/lib/builtins/ctx) argument
 provides information about the target.
 
 You can load the rule and use it from a `BUILD` file.
@@ -87,10 +87,10 @@ foo_binary(name = "bin1")
 foo_binary(name = "bin2")
 ```
 
-[`ctx.label`](lib/ctx#label)
+[`ctx.label`](/versions/8.6.0/rules/lib/builtins/ctx#label)
 corresponds to the label of the target being analyzed. The `ctx` object has
 many useful fields and methods; you can find an exhaustive list in the
-[API reference](lib/ctx).
+[API reference](/versions/8.6.0/rules/lib/builtins/ctx).
 
 Query the code:
 
@@ -146,7 +146,7 @@ bin2
 ```
 
 Whenever you declare a file, you have to tell Bazel how to generate it by
-creating an action. Use [`ctx.actions.write`](lib/actions#write),
+creating an action. Use [`ctx.actions.write`](/versions/8.6.0/rules/lib/builtins/actions#write),
 to create a file with the given content.
 
 ```python
@@ -201,7 +201,7 @@ You have successfully generated a file!
 ## Attributes
 
 To make the rule more useful, add new attributes using
-[the `attr` module](lib/attr) and update the rule definition.
+[the `attr` module](/versions/8.6.0/rules/lib/toplevel/attr) and update the rule definition.
 
 Add a string attribute called `username`:
 
@@ -237,22 +237,22 @@ def _foo_binary_impl(ctx):
 ```
 
 Note that you can make the attribute mandatory or set a default value. Look at
-the documentation of [`attr.string`](lib/attr#string).
-You may also use other types of attributes, such as [boolean](lib/attr#bool)
-or [list of integers](lib/attr#int_list).
+the documentation of [`attr.string`](/versions/8.6.0/rules/lib/toplevel/attr#string).
+You may also use other types of attributes, such as [boolean](/versions/8.6.0/rules/lib/toplevel/attr#bool)
+or [list of integers](/versions/8.6.0/rules/lib/toplevel/attr#int_list).
 
 ## Dependencies
 
-Dependency attributes, such as [`attr.label`](lib/attr#label)
-and [`attr.label_list`](lib/attr#label_list),
+Dependency attributes, such as [`attr.label`](/versions/8.6.0/rules/lib/toplevel/attr#label)
+and [`attr.label_list`](/versions/8.6.0/rules/lib/toplevel/attr#label_list),
 declare a dependency from the target that owns the attribute to the target whose
 label appears in the attribute's value. This kind of attribute forms the basis
 of the target graph.
 
 In the `BUILD` file, the target label appears as a string object, such as
 `//pkg:name`. In the implementation function, the target will be accessible as a
-[`Target`](lib/Target) object. For example, view the files returned
-by the target using [`Target.files`](lib/Target#modules.Target.files).
+[`Target`](/versions/8.6.0/rules/lib/builtins/Target) object. For example, view the files returned
+by the target using [`Target.files`](/versions/8.6.0/rules/lib/builtins/Target#modules.Target.files).
 
 ### Multiple files
 
@@ -295,7 +295,7 @@ implementation function, but this has two problems. First, as the template gets
 bigger, it becomes more memory efficient to put it in a separate file and avoid
 constructing large strings during the analysis phase. Second, using a separate
 file is more convenient for the user. Instead, use
-[`ctx.actions.expand_template`](lib/actions#expand_template),
+[`ctx.actions.expand_template`](/versions/8.6.0/rules/lib/builtins/actions#expand_template),
 which performs substitutions on a template file.
 
 Create a `template` attribute to declare a dependency on the template
diff --git a/versions/8.6.0/rules/testing.mdx b/versions/8.6.0/rules/testing.mdx
index 8487464e..3a9dfe31 100644
--- a/versions/8.6.0/rules/testing.mdx
+++ b/versions/8.6.0/rules/testing.mdx
@@ -234,7 +234,7 @@ def _inspect_actions_test_impl(ctx):
 ```
 
 Note that `analysistest.target_actions(env)` returns a list of
-[`Action`](lib/Action) objects which represent actions registered by the
+[`Action`](/versions/8.6.0/rules/lib/builtins/Action) objects which represent actions registered by the
 target under test.
 
 ### Verifying rule behavior under different flags
diff --git a/versions/8.6.0/rules/verbs-tutorial.mdx b/versions/8.6.0/rules/verbs-tutorial.mdx
index 7deffbe3..65755bad 100644
--- a/versions/8.6.0/rules/verbs-tutorial.mdx
+++ b/versions/8.6.0/rules/verbs-tutorial.mdx
@@ -49,8 +49,7 @@ This pattern can also be seen in the Angular project. The
 produces two targets. The first is a standard `nodejs_test` target which compares
 some generated output against a "golden" file (that is, a file containing the
 expected output). This can be built and run with a normal `bazel
-test` invocation. In `angular-cli`, you can run [one such
-target](https://github.com/angular/angular-cli/blob/e1269cb520871ee29b1a4eec6e6c0e4a94f0b5fc/etc/api/BUILD)
+test` invocation. In `angular-cli`, you can run [one such target](https://github.com/angular/angular-cli/blob/e1269cb520871ee29b1a4eec6e6c0e4a94f0b5fc/etc/api/BUILD)
 with `bazel test //etc/api:angular_devkit_core_api`.
 
 Over time, this golden file may need to be updated for legitimate reasons.
@@ -159,7 +158,7 @@ an imaginary `bazel publish` command.
 It's not immediately obvious what the implementation of the `_sphinx_publisher`
 rule might look like. Often, actions like this write a _launcher_ shell script.
 This method typically involves using
-[`ctx.actions.expand_template`](lib/actions#expand_template)
+[`ctx.actions.expand_template`](/versions/8.6.0/rules/lib/builtins/actions#expand_template)
 to write a very simple shell script, in this case invoking the publisher binary
 with a path to the output of the primary target. This way, the publisher
 implementation can remain generic, the `_sphinx_site` rule can just produce
diff --git a/versions/8.6.0/run/build.mdx b/versions/8.6.0/run/build.mdx
index c3d6a7c9..ddb1586a 100644
--- a/versions/8.6.0/run/build.mdx
+++ b/versions/8.6.0/run/build.mdx
@@ -633,8 +633,7 @@ Note: Hermeticity means that the action only uses its declared input
 files and no other files in the filesystem, and it only produces its declared
 output files. See [Hermeticity](/versions/8.6.0/basics/hermeticity) for more details.
 
-On some platforms such as [Google Kubernetes
-Engine](https://cloud.google.com/kubernetes-engine/) cluster nodes or Debian,
+On some platforms such as [Google Kubernetes Engine](https://cloud.google.com/kubernetes-engine/) cluster nodes or Debian,
 user namespaces are deactivated by default due to security
 concerns. This can be checked by looking at the file
 `/proc/sys/kernel/unprivileged_userns_clone`: if it exists and contains a 0,
diff --git a/versions/8.6.0/start/android-app.mdx b/versions/8.6.0/start/android-app.mdx
index 08e09bf0..636ee60a 100644
--- a/versions/8.6.0/start/android-app.mdx
+++ b/versions/8.6.0/start/android-app.mdx
@@ -36,8 +36,7 @@ In this tutorial you learn how to:
 Before you begin the tutorial, install the following software:
 
 * **Bazel.** To install, follow the [installation instructions](/versions/8.6.0/install).
-* **Android Studio.** To install, follow the steps to [download Android
-  Studio](https://developer.android.com/sdk/index.html).
+* **Android Studio.** To install, follow the steps to [download Android Studio](https://developer.android.com/sdk/index.html).
   Execute the setup wizard to download the SDK and configure your environment.
 * (Optional) **Git.** Use `git` to download the Android app project.
 
@@ -52,8 +51,7 @@ This app has a single button that prints a greeting when clicked:
 
 **Figure 1.** Android app button greeting.
 
-Clone the repository with `git` (or [download the ZIP file
-directly](https://github.com/bazelbuild/examples/archive/master.zip)):
+Clone the repository with `git` (or [download the ZIP file directly](https://github.com/bazelbuild/examples/archive/master.zip)):
 
 ```posix-terminal
 git clone https://github.com/bazelbuild/examples
@@ -103,8 +101,7 @@ A [workspace](/versions/8.6.0/concepts/build-ref#workspace) is a directory that
 source files for one or more software projects, and has a `MODULE.bazel` file at
 its root.
 
-The `MODULE.bazel` file may be empty or may contain references to [external
-dependencies](/versions/8.6.0/external/overview) required to build your project.
+The `MODULE.bazel` file may be empty or may contain references to [external dependencies](/versions/8.6.0/external/overview) required to build your project.
 
 First, run the following command to create an empty `MODULE.bazel` file:
 
@@ -147,8 +144,7 @@ environment variable, and automatically detect the highest API level and the
 latest version of build tools installed within that location.
 
 You can set the `ANDROID_HOME` variable to the location of the Android SDK. Find
-the path to the installed SDK using Android Studio's [SDK
-Manager](https://developer.android.com/studio/intro/update#sdk-manager).
+the path to the installed SDK using Android Studio's [SDK Manager](https://developer.android.com/studio/intro/update#sdk-manager).
 Assuming the SDK is installed to default locations, you can use the following
 commands to set the `ANDROID_HOME` variable:
 
@@ -170,16 +166,14 @@ them permanent, run the following commands:
 | Windows (PowerShell)     | `[System.Environment]::SetEnvironmentVariable('ANDROID_HOME', "$env:LOCALAPPDATA\Android\Sdk", [System.EnvironmentVariableTarget]::User)` |
 
 **Optional:** If you want to compile native code into your Android app, you
-also need to download the [Android
-NDK](https://developer.android.com/ndk/downloads/index.html)
+also need to download the [Android NDK](https://developer.android.com/ndk/downloads/index.html)
 and use `rules_android_ndk` by adding the following line to your `MODULE.bazel` file:
 
 ```python
 bazel_dep(name = "rules_android_ndk", version = "0.1.2")
 ```
 
-For more information, read [Using the Android Native Development Kit with
-Bazel](/versions/8.6.0/docs/android-ndk).
+For more information, read [Using the Android Native Development Kit with Bazel](/versions/8.6.0/docs/android-ndk).
 
 It's not necessary to set the API levels to the same value for the SDK and NDK.
 [This page](https://developer.android.com/ndk/guides/stable_apis.html)
@@ -221,8 +215,7 @@ files or other dependencies. Bazel provides two build rules,
 build an Android app.
 
 For this tutorial, you'll first use the
-`android_library` rule to tell Bazel to build an [Android library
-module](http://developer.android.com/tools/projects/index.html#LibraryProjects)
+`android_library` rule to tell Bazel to build an [Android library module](http://developer.android.com/tools/projects/index.html#LibraryProjects)
 from the app source code and resource files. You'll then use the
 `android_binary` rule to tell Bazel how to build the Android application package.
 
@@ -337,11 +330,9 @@ file:
 ### Run the app
 
 You can now deploy the app to a connected Android device or emulator from the
-command line using the [`bazel
-mobile-install`](/versions/8.6.0/docs/user-manual#mobile-install) command. This command uses
+command line using the [`bazel mobile-install`](/versions/8.6.0/docs/user-manual#mobile-install) command. This command uses
 the Android Debug Bridge (`adb`) to communicate with the device. You must set up
-your device to use `adb` following the instructions in [Android Debug
-Bridge](http://developer.android.com/tools/help/adb.html) before deployment. You
+your device to use `adb` following the instructions in [Android Debug Bridge](http://developer.android.com/tools/help/adb.html) before deployment. You
 can also choose to install the app on the Android emulator included in Android
 Studio. Make sure the emulator is running before executing the command below.
 
diff --git a/versions/8.6.0/start/cpp.mdx b/versions/8.6.0/start/cpp.mdx
index c586a1ac..1d9683c5 100644
--- a/versions/8.6.0/start/cpp.mdx
+++ b/versions/8.6.0/start/cpp.mdx
@@ -19,8 +19,7 @@ Estimated completion time: 30 minutes.
 ### Prerequisites
 
 Start by [installing Bazel](https://bazel.build/versions/8.6.0/install), if you haven't
-already. This tutorial uses Git for source control, so for best results [install
-Git](https://git-scm.com/book/en/v2/Getting-Started-Installing-Git) as well.
+already. This tutorial uses Git for source control, so for best results [install Git](https://git-scm.com/book/en/v2/Getting-Started-Installing-Git) as well.
 
 Next, retrieve the sample project from Bazel's GitHub repository by running the
 following in your command-line tool of choice:
@@ -63,9 +62,7 @@ examples
 ```
 
 There are three sets of files, each set representing a stage in this tutorial.
-In the first stage, you will build a single [target]
-(https://bazel.build/versions/8.6.0/reference/glossary#target) residing in a single [package]
-(https://bazel.build/versions/8.6.0/reference/glossary#package). In the second stage, you will
+In the first stage, you will build a single [target](https://bazel.build/versions/8.6.0/reference/glossary#target) residing in a single [package](https://bazel.build/versions/8.6.0/reference/glossary#package). In the second stage, you will
 build both a binary and a library from a single package. In the third and final
 stage, you will build a project with multiple packages and build it with
 multiple targets.
@@ -86,8 +83,7 @@ It also contains these significant files:
 *   The `MODULE.bazel` file, which identifies the directory and its contents as
     a Bazel workspace and lives at the root of the project's directory
     structure. It's also where you specify your external dependencies.
-*   One or more [`BUILD`
-    files](https://bazel.build/versions/8.6.0/reference/glossary#build-file), which tell Bazel
+*   One or more [`BUILD` files](https://bazel.build/versions/8.6.0/reference/glossary#build-file), which tell Bazel
     how to build different parts of the project. A directory within the
     workspace that contains a `BUILD` file is a
     [package](https://bazel.build/versions/8.6.0/reference/glossary#package). (More on packages
@@ -182,9 +178,7 @@ This results in a printed "`Hello world`" message.
 
 Here's the dependency graph of Stage 1:
 
-![Dependency graph for hello-world displays a single target with a single source
-file.](/versions/8.6.0/docs/images/cpp-tutorial-stage1.png "Dependency graph for hello-world
-displays a single target with a single source file.")
+![Dependency graph for hello-world displays a single target with a single source file.](/versions/8.6.0/docs/images/cpp-tutorial-stage1.png "Dependency graph for hello-world displays a single target with a single source file.")
 
 ### Summary: stage 1
 
@@ -231,8 +225,7 @@ cc_binary(
 ```
 
 With this `BUILD` file, Bazel first builds the `hello-greet` library (using
-Bazel's built-in [`cc_library`
-rule](https://bazel.build/versions/8.6.0/reference/be/c-cpp#cc_library)), then the
+Bazel's built-in [`cc_library` rule](https://bazel.build/versions/8.6.0/reference/be/c-cpp#cc_library)), then the
 `hello-world` binary. The `deps` attribute in the `hello-world` target tells
 Bazel that the `hello-greet` library is required to build the `hello-world`
 binary.
@@ -272,10 +265,7 @@ recompiles that file.
 Looking at the dependency graph, you can see that `hello-world` depends on an
 extra input named `hello-greet`:
 
-![Dependency graph for `hello-world` displays dependency changes after
-modification to the file.](/versions/8.6.0/docs/images/cpp-tutorial-stage2.png "Dependency
-graph for `hello-world` displays dependency changes after modification to the
-file.")
+![Dependency graph for `hello-world` displays dependency changes after modification to the file.](/versions/8.6.0/docs/images/cpp-tutorial-stage2.png "Dependency graph for `hello-world` displays dependency changes after modification to the file.")
 
 ### Summary: stage 2
 
@@ -343,11 +333,7 @@ in the `lib` package (hence the target label `//lib:hello-time`) - Bazel knows
 this through the `deps` attribute. You can see this reflected in the dependency
 graph:
 
-![Dependency graph for `hello-world` displays how the target in the main package
-depends on the target in the `lib`
-package.](/versions/8.6.0/docs/images/cpp-tutorial-stage3.png "Dependency graph for
-`hello-world` displays how the target in the main package depends on the target
-in the `lib` package.")
+![Dependency graph for `hello-world` displays how the target in the main package depends on the target in the `lib` package.](/versions/8.6.0/docs/images/cpp-tutorial-stage3.png "Dependency graph for `hello-world` displays how the target in the main package depends on the target in the `lib` package.")
 
 For the build to succeed, you make the `//lib:hello-time` target in `lib/BUILD`
 explicitly visible to targets in `main/BUILD` using the visibility attribute.
@@ -395,15 +381,11 @@ Bazel journey.
 You've now completed your first basic build with Bazel, but this is just the
 start. Here are some more resources to continue learning with Bazel:
 
-*   To keep focusing on C++, read about common [C++ build use
-    cases](https://bazel.build/versions/8.6.0/tutorials/cpp-use-cases).
+*   To keep focusing on C++, read about common [C++ build use cases](https://bazel.build/versions/8.6.0/tutorials/cpp-use-cases).
 *   To get started with building other applications with Bazel, see the
-    tutorials for [Java](https://bazel.build/versions/8.6.0/start/java), [Android
-    application](https://bazel.build/versions/8.6.0/start/android-app), or [iOS
-    application](https://bazel.build/versions/8.6.0/start/ios-app).
+    tutorials for [Java](https://bazel.build/versions/8.6.0/start/java), [Android application](https://bazel.build/versions/8.6.0/start/android-app), or [iOS application](https://bazel.build/versions/8.6.0/start/ios-app).
 *   To learn more about working with local and remote repositories, read about
     [external dependencies](https://bazel.build/versions/8.6.0/docs/external).
-*   To learn more about Bazel's other rules, see this [reference
-    guide](https://bazel.build/versions/8.6.0/rules).
+*   To learn more about Bazel's other rules, see this [reference guide](https://bazel.build/versions/8.6.0/rules).
 
 Happy building!
\ No newline at end of file
diff --git a/versions/8.6.0/start/java.mdx b/versions/8.6.0/start/java.mdx
index 74ca8c8b..365aaf23 100644
--- a/versions/8.6.0/start/java.mdx
+++ b/versions/8.6.0/start/java.mdx
@@ -241,8 +241,7 @@ recompiles that file.
 Looking at the dependency graph, you can see that `ProjectRunner` depends on the
 same inputs as it did before, but the structure of the build is different:
 
-![Dependency graph of the target 'ProjectRunner' after adding a dependency](
-/docs/images/tutorial_java_02.svg)
+![Dependency graph of the target 'ProjectRunner' after adding a dependency](/versions/8.6.0/docs/images/tutorial_java_02.svg)
 
 You've now built the project with two targets. The `ProjectRunner` target builds
 one source files and depends on one other target (`:greeter`), which builds
@@ -426,7 +425,7 @@ For more details, see:
 *  The [C++ build tutorial](/versions/8.6.0/start/cpp) to get started with building
    C++ projects with Bazel.
 
-*  The [Android application tutorial](/versions/8.6.0/start/android-app ) and
+*  The [Android application tutorial](/versions/8.6.0/start/android-app) and
    [iOS application tutorial](/versions/8.6.0/start/ios-app)) to get started with
    building mobile applications for Android and iOS with Bazel.
 
diff --git a/versions/8.6.0/tutorials/ccp-toolchain-config.mdx b/versions/8.6.0/tutorials/ccp-toolchain-config.mdx
index 7895860d..5c5e0885 100644
--- a/versions/8.6.0/tutorials/ccp-toolchain-config.mdx
+++ b/versions/8.6.0/tutorials/ccp-toolchain-config.mdx
@@ -29,8 +29,7 @@ uses `clang version 16`, which you can install on your system.
 
 Set up your build environment as follows:
 
-1.  If you have not already done so, [download and install Bazel
-    7.0.2](https://bazel.build/versions/8.6.0/install) or later.
+1.  If you have not already done so, [download and install Bazel 7.0.2](https://bazel.build/versions/8.6.0/install) or later.
 
 2.  Add an empty `MODULE.bazel` file at the root folder.
 
@@ -450,8 +449,7 @@ The key takeaways are:
 
 -   You need to specify a matching `platforms` flag in the command line for
     Bazel to resolve to the toolchain for the same constraint values on the
-    platform. The documentation holds more [information about language specific
-    configuration flags](/versions/8.6.0/concepts/platforms).
+    platform. The documentation holds more [information about language specific configuration flags](/versions/8.6.0/concepts/platforms).
 -   You have to let the toolchain know where the tools live. In this tutorial
     there is a simplified version where you access the tools from the system. If
     you are interested in a more self-contained approach, you can read about
@@ -464,5 +462,4 @@ The key takeaways are:
 
 ## Further reading
 
-For more details, see [C++ toolchain
-configuration](/versions/8.6.0/docs/cc-toolchain-config-reference)
\ No newline at end of file
+For more details, see [C++ toolchain configuration](/versions/8.6.0/docs/cc-toolchain-config-reference)
\ No newline at end of file
diff --git a/versions/9.0.0/basics/dependencies.mdx b/versions/9.0.0/basics/dependencies.mdx
index d762c4f3..83787edd 100644
--- a/versions/9.0.0/basics/dependencies.mdx
+++ b/versions/9.0.0/basics/dependencies.mdx
@@ -65,8 +65,7 @@ targets, we’ve made some strides in mitigating the downside by investing in
 tooling to automatically manage `BUILD` files to avoid burdening developers.
 
 Some of these tools, such as `buildifier` and `buildozer`, are available with
-Bazel in the [`buildtools`
-directory](https://github.com/bazelbuild/buildtools).
+Bazel in the [`buildtools` directory](https://github.com/bazelbuild/buildtools).
 
 ## Minimizing Module Visibility
 
@@ -106,8 +105,7 @@ transitive dependencies (Figure 1). Suppose target A depends on target B, which
 depends on a common library target C. Should target A be able to use classes
 defined in target C?
 
-[![Transitive
-dependencies](/versions/9.0.0/images/transitive-dependencies.png)](/versions/9.0.0/images/transitive-dependencies.png)
+[![Transitive dependencies](/versions/9.0.0/images/transitive-dependencies.png)](/versions/9.0.0/images/transitive-dependencies.png)
 
 **Figure 1**. Transitive dependencies
 
@@ -141,9 +139,7 @@ dependencies and adding them to a `BUILD` files without any developer
 intervention. But even without such tools, we’ve found the trade-off to be well
 worth it as the codebase scales: explicitly adding a dependency to `BUILD` file
 is a one-time cost, but dealing with implicit transitive dependencies can cause
-ongoing problems as long as the build target exists. Bazel [enforces strict
-transitive
-dependencies](https://blog.bazel.build/2017/06/28/sjd-unused_deps.html)
+ongoing problems as long as the build target exists. Bazel [enforces strict transitive dependencies](https://blog.bazel.build/2017/06/28/sjd-unused_deps.html)
 on Java code by default.
 
 ### External dependencies
@@ -192,8 +188,7 @@ so in theory there’s no reason that different versions of the same external
 dependency couldn’t both be declared in the build system under different names.
 That way, each target could choose which version of the dependency it wanted to
 use. This causes a lot of problems in practice, so Google enforces a strict
-[One-Version
-Rule](https://opensource.google/docs/thirdparty/oneversion/) for
+[One-Version Rule](https://opensource.google/docs/thirdparty/oneversion/) for
 all third-party dependencies in our codebase.
 
 The biggest problem with allowing multiple versions is the diamond dependency
@@ -232,8 +227,7 @@ Bazel did not use to automatically download transitive dependencies. It used to
 employ a `WORKSPACE` file that required all transitive dependencies to be
 listed, which led to a lot of pain when managing external dependencies. Bazel
 has since added support for automatic transitive external dependency management
-in the form of the `MODULE.bazel` file. See [external dependency
-overview](/versions/9.0.0/external/overview) for more details.
+in the form of the `MODULE.bazel` file. See [external dependency overview](/versions/9.0.0/external/overview) for more details.
 
 Yet again, the choice here is one between convenience and scalability. Small
 projects might prefer not having to worry about managing transitive dependencies
diff --git a/versions/9.0.0/community/images/Bitrise.png b/versions/9.0.0/community/images/Bitrise.png
new file mode 100644
index 00000000..07f85f1e
Binary files /dev/null and b/versions/9.0.0/community/images/Bitrise.png differ
diff --git a/versions/9.0.0/community/images/Gradle.png b/versions/9.0.0/community/images/Gradle.png
new file mode 100644
index 00000000..1e5f5eb0
Binary files /dev/null and b/versions/9.0.0/community/images/Gradle.png differ
diff --git a/versions/9.0.0/community/images/Linkedin-Logo.png b/versions/9.0.0/community/images/Linkedin-Logo.png
new file mode 100644
index 00000000..9dd8715c
Binary files /dev/null and b/versions/9.0.0/community/images/Linkedin-Logo.png differ
diff --git a/versions/9.0.0/community/images/Lucid_Software-logo.svg b/versions/9.0.0/community/images/Lucid_Software-logo.svg
new file mode 100644
index 00000000..6c8591e0
--- /dev/null
+++ b/versions/9.0.0/community/images/Lucid_Software-logo.svg
@@ -0,0 +1,16 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/versions/9.0.0/community/images/acqio_logo.svg b/versions/9.0.0/community/images/acqio_logo.svg
new file mode 100644
index 00000000..8fa11bcd
--- /dev/null
+++ b/versions/9.0.0/community/images/acqio_logo.svg
@@ -0,0 +1,60 @@
+
+
+
+
+
+	
+		
+			
+				
+					
+					
+					
+					
+					
+				
+				
+					
+						
+							
+								
+							
+						
+					
+				
+				
+					
+						
+							
+								
+							
+						
+					
+				
+			
+		
+	
+
+
diff --git a/versions/9.0.0/community/images/aspect-logo-2.png b/versions/9.0.0/community/images/aspect-logo-2.png
new file mode 100644
index 00000000..dfebc4cb
Binary files /dev/null and b/versions/9.0.0/community/images/aspect-logo-2.png differ
diff --git a/versions/9.0.0/community/images/bitrise-logo.png b/versions/9.0.0/community/images/bitrise-logo.png
new file mode 100644
index 00000000..27037ce6
Binary files /dev/null and b/versions/9.0.0/community/images/bitrise-logo.png differ
diff --git a/versions/9.0.0/community/images/buildbuddy-logo.svg b/versions/9.0.0/community/images/buildbuddy-logo.svg
new file mode 100644
index 00000000..bdb72dc6
--- /dev/null
+++ b/versions/9.0.0/community/images/buildbuddy-logo.svg
@@ -0,0 +1,11 @@
+
+
+
+
+
+
+
+
+
+
+
diff --git a/versions/9.0.0/community/images/buildkite.svg b/versions/9.0.0/community/images/buildkite.svg
new file mode 100644
index 00000000..209a4ab1
--- /dev/null
+++ b/versions/9.0.0/community/images/buildkite.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/9.0.0/community/images/codethink-logo.svg b/versions/9.0.0/community/images/codethink-logo.svg
new file mode 100644
index 00000000..406005d8
--- /dev/null
+++ b/versions/9.0.0/community/images/codethink-logo.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/9.0.0/community/images/develocity.png b/versions/9.0.0/community/images/develocity.png
new file mode 100644
index 00000000..eb3eb65a
Binary files /dev/null and b/versions/9.0.0/community/images/develocity.png differ
diff --git a/versions/9.0.0/community/images/dropbox.png b/versions/9.0.0/community/images/dropbox.png
new file mode 100644
index 00000000..125476a6
Binary files /dev/null and b/versions/9.0.0/community/images/dropbox.png differ
diff --git a/versions/9.0.0/community/images/engflow-logo.svg b/versions/9.0.0/community/images/engflow-logo.svg
new file mode 100644
index 00000000..e5f0c343
--- /dev/null
+++ b/versions/9.0.0/community/images/engflow-logo.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/9.0.0/community/images/epam-logo.png b/versions/9.0.0/community/images/epam-logo.png
new file mode 100644
index 00000000..e6a5674c
Binary files /dev/null and b/versions/9.0.0/community/images/epam-logo.png differ
diff --git a/versions/9.0.0/community/images/flare-logo.png b/versions/9.0.0/community/images/flare-logo.png
new file mode 100644
index 00000000..84cb0e5b
Binary files /dev/null and b/versions/9.0.0/community/images/flare-logo.png differ
diff --git a/versions/9.0.0/community/images/hermetiq-logo.png b/versions/9.0.0/community/images/hermetiq-logo.png
new file mode 100644
index 00000000..90765d96
Binary files /dev/null and b/versions/9.0.0/community/images/hermetiq-logo.png differ
diff --git a/versions/9.0.0/community/images/jetbrains.svg b/versions/9.0.0/community/images/jetbrains.svg
new file mode 100644
index 00000000..cb3a2a0e
--- /dev/null
+++ b/versions/9.0.0/community/images/jetbrains.svg
@@ -0,0 +1,13 @@
+
+  
+    
+      
+      
+      
+    
+  
+  
+  
+  
+  
+
diff --git a/versions/9.0.0/community/images/liulishuo.png b/versions/9.0.0/community/images/liulishuo.png
new file mode 100644
index 00000000..a6758e5c
Binary files /dev/null and b/versions/9.0.0/community/images/liulishuo.png differ
diff --git a/versions/9.0.0/community/images/nativelink.svg b/versions/9.0.0/community/images/nativelink.svg
new file mode 100644
index 00000000..148fcdce
--- /dev/null
+++ b/versions/9.0.0/community/images/nativelink.svg
@@ -0,0 +1,1123 @@
+
+
+  
+    
+    
+      
+      
+    
+    
+      
+      
+    
+    
+    
+      
+      
+    
+    
+      
+      
+      
+      
+      
+      
+      
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+      
+      
+    
+    
+    
+    
+      
+      
+    
+    
+    
+    
+      
+      
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+      
+      
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+      
+      
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+      
+      
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+      
+      
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+      
+      
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+      
+      
+    
+  
+  
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+  
+  
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+  
+
diff --git a/versions/9.0.0/community/images/oasis-logo.png b/versions/9.0.0/community/images/oasis-logo.png
new file mode 100644
index 00000000..846a9cd5
Binary files /dev/null and b/versions/9.0.0/community/images/oasis-logo.png differ
diff --git a/versions/9.0.0/community/images/sumglobal-logo.png b/versions/9.0.0/community/images/sumglobal-logo.png
new file mode 100644
index 00000000..6736328d
Binary files /dev/null and b/versions/9.0.0/community/images/sumglobal-logo.png differ
diff --git a/versions/9.0.0/community/images/trunk-logo-dark.svg b/versions/9.0.0/community/images/trunk-logo-dark.svg
new file mode 100644
index 00000000..f25940af
--- /dev/null
+++ b/versions/9.0.0/community/images/trunk-logo-dark.svg
@@ -0,0 +1,22 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/versions/9.0.0/community/images/tweag-logo.png b/versions/9.0.0/community/images/tweag-logo.png
new file mode 100644
index 00000000..20210ed7
Binary files /dev/null and b/versions/9.0.0/community/images/tweag-logo.png differ
diff --git a/versions/9.0.0/community/images/typedb.png b/versions/9.0.0/community/images/typedb.png
new file mode 100644
index 00000000..48ce1056
Binary files /dev/null and b/versions/9.0.0/community/images/typedb.png differ
diff --git a/versions/9.0.0/community/images/virtuslab.svg b/versions/9.0.0/community/images/virtuslab.svg
new file mode 100644
index 00000000..6fba0316
--- /dev/null
+++ b/versions/9.0.0/community/images/virtuslab.svg
@@ -0,0 +1,20 @@
+
+
+  
+    
+  
+  
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+  
+
diff --git a/versions/9.0.0/community/sig.mdx b/versions/9.0.0/community/sig.mdx
index 314ac7bf..786eaf38 100644
--- a/versions/9.0.0/community/sig.mdx
+++ b/versions/9.0.0/community/sig.mdx
@@ -3,8 +3,7 @@ title: 'Bazel Special Interest Groups'
 ---
 
 Bazel hosts Special Interest Groups (SIGs) to focus collaboration on particular
-areas and to support communication and coordination between [Bazel owners,
-maintainers, and contributors](/versions/9.0.0/contribute/policy). This policy
+areas and to support communication and coordination between [Bazel owners, maintainers, and contributors](/versions/9.0.0/contribute/policy). This policy
 applies to [`bazelbuild`](http://github.com/bazelbuild).
 
 SIGs do their work in public. The ideal scope for a SIG covers a well-defined
diff --git a/versions/9.0.0/community/users.mdx b/versions/9.0.0/community/users.mdx
index 948b0892..f19117a2 100644
--- a/versions/9.0.0/community/users.mdx
+++ b/versions/9.0.0/community/users.mdx
@@ -304,11 +304,9 @@ safety systems_.
 Pigweed is an open-source solution for sustained, robust, and rapid embedded
 product development for large teams. Pigweed has shipped in millions of
 devices, including Google's suite of Pixel devices, Nest thermostats,
-[satellites](https://www.spinlaunch.com/), and [autonomous aerial
-drones](https://www.flyzipline.com/).
+[satellites](https://www.spinlaunch.com/), and [autonomous aerial drones](https://www.flyzipline.com/).
 
-Pigweed [uses Bazel as its primary build
-system](https://pigweed.dev/seed/0111-build-systems.html). The [Bazel for
+Pigweed [uses Bazel as its primary build system](https://pigweed.dev/seed/0111-build-systems.html). The [Bazel for
 Embedded][pw-bazel-great] blog post discusses why we think it's a great build
 system for embedded projects!
 
diff --git a/versions/9.0.0/concepts/build-ref.mdx b/versions/9.0.0/concepts/build-ref.mdx
index df9ae0e8..b9cb0c85 100644
--- a/versions/9.0.0/concepts/build-ref.mdx
+++ b/versions/9.0.0/concepts/build-ref.mdx
@@ -17,8 +17,7 @@ its root; such a boundary marker file could be `MODULE.bazel`, `REPO.bazel`, or
 in legacy contexts, `WORKSPACE` or `WORKSPACE.bazel`.
 
 The repo in which the current Bazel command is being run is called the _main
-repo_. Other, (external) repos are defined by _repo rules_; see [external
-dependencies overview](/versions/9.0.0/external/overview) for more information.
+repo_. Other, (external) repos are defined by _repo rules_; see [external dependencies overview](/versions/9.0.0/external/overview) for more information.
 
 ## Workspace {#workspace}
 
@@ -95,5 +94,4 @@ have three properties: the list of packages they contain, their name, and other
 package groups they include. The only allowed ways to refer to them are from the
 `visibility` attribute of rules or from the `default_visibility` attribute of
 the `package` function; they do not generate or consume files. For more
-information, refer to the [`package_group`
-documentation](/versions/9.0.0/reference/be/functions#package_group).
+information, refer to the [`package_group` documentation](/versions/9.0.0/reference/be/functions#package_group).
diff --git a/versions/9.0.0/concepts/labels.mdx b/versions/9.0.0/concepts/labels.mdx
index fbd95b70..6b3215b8 100644
--- a/versions/9.0.0/concepts/labels.mdx
+++ b/versions/9.0.0/concepts/labels.mdx
@@ -10,8 +10,7 @@ form looks like:
 ```
 
 The first part of the label is the repository name, `@@myrepo`. The double-`@`
-syntax signifies that this is a [*canonical* repo
-name](/versions/9.0.0/external/overview#canonical-repo-name), which is unique within
+syntax signifies that this is a [*canonical* repo name](/versions/9.0.0/external/overview#canonical-repo-name), which is unique within
 the workspace. Labels with canonical repo names unambiguously identify a target
 no matter which context they appear in.
 
diff --git a/versions/9.0.0/concepts/platforms.mdx b/versions/9.0.0/concepts/platforms.mdx
index 7b8488ee..9ec48e28 100644
--- a/versions/9.0.0/concepts/platforms.mdx
+++ b/versions/9.0.0/concepts/platforms.mdx
@@ -77,8 +77,7 @@ To test your Android project with platforms, see
 for support.
 
 You can still use platform APIs with Apple builds (for example, when building
-with a mixture of Apple rules and pure C++) with [platform
-mappings](#platform-mappings).
+with a mixture of Apple rules and pure C++) with [platform mappings](#platform-mappings).
 
 ### Other languages {#other-languages}
 
@@ -241,8 +240,7 @@ sets `--cpu`, `--crossstool_top`, or other legacy flags, rules that read
 
 When migrating your project to platforms, you must either convert changes like
 `return { "//command_line_option:cpu": "arm" }` to `return {
-"//command_line_option:platforms": "//:my_arm_platform" }` or use [platform
-mappings](#platform-mappings) to support both styles during migration.
+"//command_line_option:platforms": "//:my_arm_platform" }` or use [platform mappings](#platform-mappings) to support both styles during migration.
 window.
 
 ## Migrating your rule set {#migrating-your-rule-set}
@@ -361,10 +359,8 @@ attributes declare a language's tools (like `compiler =
 this information to rules that need to build with these tools.
 
 Toolchains declare the `constraint_value`s of machines they can
-[target][target_compatible_with Attribute]
-(`target_compatible_with = ["@platforms//os:linux"]`) and machines their tools can
-[run on][exec_compatible_with Attribute]
-(`exec_compatible_with = ["@platforms//os:mac"]`).
+[target][target_compatible_with Attribute](`target_compatible_with = ["@platforms//os:linux"]`) and machines their tools can
+[run on][exec_compatible_with Attribute](`exec_compatible_with = ["@platforms//os:mac"]`).
 
 When building `$ bazel build //:myproject --platforms=//:myplatform`, Bazel
 automatically selects a toolchain that can run on the build machine and
diff --git a/versions/9.0.0/configure/attributes.mdx b/versions/9.0.0/configure/attributes.mdx
index 7827c192..8bcd5bc2 100644
--- a/versions/9.0.0/configure/attributes.mdx
+++ b/versions/9.0.0/configure/attributes.mdx
@@ -2,8 +2,7 @@
 title: 'Configurable Build Attributes'
 ---
 
-**_Configurable attributes_**, commonly known as [`select()`](
-/reference/be/functions#select), is a Bazel feature that lets users toggle the values
+**_Configurable attributes_**, commonly known as [`select()`](/versions/9.0.0/reference/be/functions#select), is a Bazel feature that lets users toggle the values
 of build rule attributes at the command line.
 
 This can be used, for example, for a multiplatform library that automatically
@@ -407,8 +406,7 @@ sh_library(
 )
 ```
 
-If you need a `select` to match when multiple conditions match, consider [AND
-chaining](#and-chaining).
+If you need a `select` to match when multiple conditions match, consider [AND chaining](#and-chaining).
 
 ## OR chaining {#or-chaining}
 
diff --git a/versions/9.0.0/configure/integrate-cpp.mdx b/versions/9.0.0/configure/integrate-cpp.mdx
index cb104c7d..78a5c11a 100644
--- a/versions/9.0.0/configure/integrate-cpp.mdx
+++ b/versions/9.0.0/configure/integrate-cpp.mdx
@@ -14,8 +14,7 @@ To depend on a C++ toolchain in your rule, set the `toolchains` parameter to
 `use_cc_toolchain()`. Then, in the rule implementation, use
 `find_cpp_toolchain(ctx)` to get the
 [`CcToolchainInfo`](/versions/9.0.0/rules/lib/providers/CcToolchainInfo). A complete working
-example can be found [in the rules_cc
-examples](https://github.com/bazelbuild/rules_cc/blob/main/examples/write_cc_toolchain_cpu/write_cc_toolchain_cpu.bzl).
+example can be found [in the rules_cc examples](https://github.com/bazelbuild/rules_cc/blob/main/examples/write_cc_toolchain_cpu/write_cc_toolchain_cpu.bzl).
 
 ## Generating command lines and environment variables using the C++ toolchain {#generate-command-lines-toolchain}
 
@@ -25,8 +24,7 @@ This is because when writing our own actions, they must behave
 consistently with the C++ toolchain - for example, passing C++ command line
 flags to a tool that invokes the C++ compiler behind the scenes.
 
-C++ rules use a special way of constructing command lines based on [feature
-configuration](/versions/9.0.0/docs/cc-toolchain-config-reference). To construct a command line,
+C++ rules use a special way of constructing command lines based on [feature configuration](/versions/9.0.0/docs/cc-toolchain-config-reference). To construct a command line,
 you need the following:
 
 * `features` and `action_configs` - these come from the `CcToolchainConfigInfo`
diff --git a/versions/9.0.0/configure/windows.mdx b/versions/9.0.0/configure/windows.mdx
index 2a1da390..34e2516d 100644
--- a/versions/9.0.0/configure/windows.mdx
+++ b/versions/9.0.0/configure/windows.mdx
@@ -160,8 +160,7 @@ To build C++ targets with MSVC, you need:
         set BAZEL_VC=C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC
         ```
 
-*   The [Windows
-    SDK](https://developer.microsoft.com/en-us/windows/downloads/windows-10-sdk).
+*   The [Windows SDK](https://developer.microsoft.com/en-us/windows/downloads/windows-10-sdk).
 
     The Windows SDK contains header files and libraries you need when building
     Windows applications, including Bazel itself. By default, the latest Windows SDK installed will
@@ -180,8 +179,7 @@ To build C++ targets with MSVC, you need:
 
 If everything is set up, you can build a C++ target now!
 
-Try building a target from one of our [sample
-projects](https://github.com/bazelbuild/bazel/tree/master/examples):
+Try building a target from one of our [sample projects](https://github.com/bazelbuild/bazel/tree/master/examples):
 
 
 
   
   
 
 If you are interested in details about how Bazel builds Python targets on
-Windows, check out this [design
-doc](https://github.com/bazelbuild/bazel-website/blob/master/designs/_posts/2016-09-05-build-python-on-windows.md).
+Windows, check out this [design doc](https://github.com/bazelbuild/bazel-website/blob/master/designs/_posts/2016-09-05-build-python-on-windows.md).
diff --git a/versions/9.0.0/contribute/breaking-changes.mdx b/versions/9.0.0/contribute/breaking-changes.mdx
index 48d51839..7c51dfe1 100644
--- a/versions/9.0.0/contribute/breaking-changes.mdx
+++ b/versions/9.0.0/contribute/breaking-changes.mdx
@@ -67,7 +67,7 @@ should contain the URL of the GitHub issue. As the flag name starts with
 ```
 
 In the commit description, add a brief summary of the flag.
-Also add [`RELNOTES:`](release-notes.md) in the following form:
+Also add [`RELNOTES:`](/versions/9.0.0/contribute/release-notes) in the following form:
 `RELNOTES: --incompatible_name_of_flag has been added. See #xyz for details`
 
 The commit should also update the relevant documentation, so that there is no
diff --git a/versions/9.0.0/contribute/codebase.mdx b/versions/9.0.0/contribute/codebase.mdx
index 7d05f598..8042618f 100644
--- a/versions/9.0.0/contribute/codebase.mdx
+++ b/versions/9.0.0/contribute/codebase.mdx
@@ -237,8 +237,7 @@ repository", the others are called "external repositories".
 A repository is marked by a repo boundary file (`MODULE.bazel`, `REPO.bazel`, or
 in legacy contexts, `WORKSPACE` or `WORKSPACE.bazel`) in its root directory. The
 main repo is the source tree where you're invoking Bazel from. External repos
-are defined in various ways; see [external dependencies
-overview](/versions/9.0.0/external/overview) for more information.
+are defined in various ways; see [external dependencies overview](/versions/9.0.0/external/overview) for more information.
 
 Code of external repositories is symlinked or downloaded under
 `$OUTPUT_BASE/external`.
diff --git a/versions/9.0.0/contribute/design-documents.mdx b/versions/9.0.0/contribute/design-documents.mdx
index b56dbd73..cd61497b 100644
--- a/versions/9.0.0/contribute/design-documents.mdx
+++ b/versions/9.0.0/contribute/design-documents.mdx
@@ -25,7 +25,7 @@ Here are some examples of significant changes:
 When you write a design document, you can coordinate with other Bazel developers
 and seek guidance from Bazel's core team. For example, when a proposal adds,
 removes, or modifies any function or object available in BUILD, MODULE.bazel, or
-bzl files, add the [Starlark team](maintainers-guide.md) as reviewers.
+bzl files, add the [Starlark team](/versions/9.0.0/contribute/maintainers-guide) as reviewers.
 Design documents are reviewed before submission because:
 
 *   Bazel is a very complex system; seemingly innocuous local changes can have
@@ -137,8 +137,7 @@ A lead reviewer should be a domain expert who is:
 *   Objective and capable of providing constructive feedback
 *   Available for the entire review period to lead the process
 
-Consider checking the contacts for various [team
-labels](/versions/9.0.0/contribute/maintainers-guide#team-labels).
+Consider checking the contacts for various [team labels](/versions/9.0.0/contribute/maintainers-guide#team-labels).
 
 ## Markdown vs Google Docs {#markdown-versus-gdocs}
 
@@ -168,12 +167,10 @@ Markdown for posterity.
 
 ### Using Google Docs {#gdocs}
 
-For consistency, use the [Bazel design doc template](
-https://docs.google.com/document/d/1cE5zrjrR40RXNg64XtRFewSv6FrLV6slGkkqxBumS1w/edit).
+For consistency, use the [Bazel design doc template](https://docs.google.com/document/d/1cE5zrjrR40RXNg64XtRFewSv6FrLV6slGkkqxBumS1w/edit).
 It includes the necessary header and creates visual
 consistency with other Bazel related documents. To do that, click on **File** >
-**Make a copy** or click this link to [make a copy of the design doc
-template](https://docs.google.com/document/d/1cE5zrjrR40RXNg64XtRFewSv6FrLV6slGkkqxBumS1w/copy).
+**Make a copy** or click this link to [make a copy of the design doc template](https://docs.google.com/document/d/1cE5zrjrR40RXNg64XtRFewSv6FrLV6slGkkqxBumS1w/copy).
 
 To make your document readable to the world, click on
 **Share** > **Advanced** > **Change…**, and
diff --git a/versions/9.0.0/contribute/images/structured-concurrency-3d.svg b/versions/9.0.0/contribute/images/structured-concurrency-3d.svg
new file mode 100644
index 00000000..accbb42a
--- /dev/null
+++ b/versions/9.0.0/contribute/images/structured-concurrency-3d.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/9.0.0/contribute/images/structured-concurrency.svg b/versions/9.0.0/contribute/images/structured-concurrency.svg
new file mode 100644
index 00000000..0258d9a9
--- /dev/null
+++ b/versions/9.0.0/contribute/images/structured-concurrency.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/9.0.0/contribute/images/suspend-resume.svg b/versions/9.0.0/contribute/images/suspend-resume.svg
new file mode 100644
index 00000000..7de1218f
--- /dev/null
+++ b/versions/9.0.0/contribute/images/suspend-resume.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/9.0.0/contribute/images/unstructured-concurrency.svg b/versions/9.0.0/contribute/images/unstructured-concurrency.svg
new file mode 100644
index 00000000..0951639a
--- /dev/null
+++ b/versions/9.0.0/contribute/images/unstructured-concurrency.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/9.0.0/contribute/index.mdx b/versions/9.0.0/contribute/index.mdx
index 8c0fc403..a18cbc0f 100644
--- a/versions/9.0.0/contribute/index.mdx
+++ b/versions/9.0.0/contribute/index.mdx
@@ -10,8 +10,7 @@ As you use Bazel, you may find things that can be improved.
 You can help by [reporting issues](http://github.com/bazelbuild/bazel/issues)
 when:
 
-   - Bazel crashes or you encounter a bug that can [only be resolved using `bazel
-     clean`](/versions/9.0.0/run/build#correct-incremental-rebuilds).
+   - Bazel crashes or you encounter a bug that can [only be resolved using `bazel clean`](/versions/9.0.0/run/build#correct-incremental-rebuilds).
    - The documentation is incomplete or unclear. You can also report issues
      from the page you are viewing by using the "Create issue"
      link at the top right corner of the page.
@@ -21,11 +20,9 @@ when:
 
 You can engage with the Bazel community by:
 
-   - Answering questions [on Stack Overflow](
-     https://stackoverflow.com/questions/tagged/bazel).
+   - Answering questions [on Stack Overflow](https://stackoverflow.com/questions/tagged/bazel).
    - Helping other users [on Slack](https://slack.bazel.build).
-   - Improving documentation or [contributing examples](
-     https://github.com/bazelbuild/examples).
+   - Improving documentation or [contributing examples](https://github.com/bazelbuild/examples).
    - Sharing your experience or your tips, for example, on a blog or social media.
 
 ## Contribute code {#contribute-code}
@@ -40,8 +37,7 @@ You can contribute to the Bazel ecosystem by:
    - Contributing to Bazel-related tools, for example, migration tools.
    - Improving Bazel integration with other IDEs and tools.
 
-Before making a change, [create a GitHub
-issue](http://github.com/bazelbuild/bazel/issues)
+Before making a change, [create a GitHub issue](http://github.com/bazelbuild/bazel/issues)
 or email [bazel-discuss@](mailto:bazel-discuss@googlegroups.com).
 
 The most helpful contributions fix bugs or add features (as opposed
diff --git a/versions/9.0.0/contribute/maintainers-guide.mdx b/versions/9.0.0/contribute/maintainers-guide.mdx
index d2208c86..9734e378 100644
--- a/versions/9.0.0/contribute/maintainers-guide.mdx
+++ b/versions/9.0.0/contribute/maintainers-guide.mdx
@@ -4,8 +4,7 @@ title: 'Guide for Bazel Maintainers'
 
 This is a guide for the maintainers of the Bazel open source project.
 
-If you are looking to contribute to Bazel, please read [Contributing to
-Bazel](/versions/9.0.0/contribute) instead.
+If you are looking to contribute to Bazel, please read [Contributing to Bazel](/versions/9.0.0/contribute) instead.
 
 The objectives of this page are to:
 
@@ -37,8 +36,7 @@ repository.
 
 1. A user creates an issue by choosing one of the
 [issue templates](https://github.com/bazelbuild/bazel/issues/new/choose)
-   and it enters the pool of [unreviewed open
-   issues](https://github.com/bazelbuild/bazel/issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aopen+-label%3Auntriaged+-label%3Ap2+-label%3Ap1+-label%3Ap3+-label%3Ap4+-label%3Ateam-Starlark+-label%3Ateam-Rules-CPP+-label%3Ateam-Rules-Java+-label%3Ateam-XProduct+-label%3Ateam-Android+-label%3Ateam-Apple+-label%3Ateam-Configurability++-label%3Ateam-Performance+-label%3Ateam-Rules-Server+-label%3Ateam-Core+-label%3Ateam-Rules-Python+-label%3Ateam-Remote-Exec+-label%3Ateam-Local-Exec+-label%3Ateam-Bazel).
+   and it enters the pool of [unreviewed open issues](https://github.com/bazelbuild/bazel/issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aopen+-label%3Auntriaged+-label%3Ap2+-label%3Ap1+-label%3Ap3+-label%3Ap4+-label%3Ateam-Starlark+-label%3Ateam-Rules-CPP+-label%3Ateam-Rules-Java+-label%3Ateam-XProduct+-label%3Ateam-Android+-label%3Ateam-Apple+-label%3Ateam-Configurability++-label%3Ateam-Performance+-label%3Ateam-Rules-Server+-label%3Ateam-Core+-label%3Ateam-Rules-Python+-label%3Ateam-Remote-Exec+-label%3Ateam-Local-Exec+-label%3Ateam-Bazel).
 1. A member on the Developer Experience (DevEx) subteam rotation reviews the
    issue.
    1. If the issue is **not a bug** or a **feature request**, the DevEx member
@@ -58,21 +56,18 @@ repository.
 1. After reviewing the issue, the DevEx member decides if the issue requires
    immediate attention. If it does, they will assign the **P0**
    [priority](#priority) label and an owner from the list of team leads.
-1. The DevEx member assigns the `untriaged` label and exactly one [team
-   label](#team-labels) for routing.
+1. The DevEx member assigns the `untriaged` label and exactly one [team label](#team-labels) for routing.
 1. The DevEx member also assigns exactly one `type:` label, such as `type: bug`
    or `type: feature request`, according to the type of the issue.
 1. For platform-specific issues, the DevEx member assigns one `platform:` label,
    such as `platform:apple` for Mac-specific issues.
 1. If the issue is low priority and can be worked on by a new community
    contributor, the DevEx member assigns the `good first issue` label.
-At this stage, the issue enters the pool of [untriaged open
-issues](https://github.com/bazelbuild/bazel/issues?q=is%3Aissue+is%3Aopen+label%3Auntriaged).
+At this stage, the issue enters the pool of [untriaged open issues](https://github.com/bazelbuild/bazel/issues?q=is%3Aissue+is%3Aopen+label%3Auntriaged).
 
 Each Bazel subteam will triage all issues under labels they own, preferably on a
 weekly basis. The subteam will review and evaluate the issue and provide a
-resolution, if possible. If you are an owner of a team label, see [this section
-](#label-own) for more information.
+resolution, if possible. If you are an owner of a team label, see [this section](#label-own) for more information.
 
 When an issue is resolved, it can be closed.
 
@@ -111,8 +106,7 @@ preferably on a weekly basis.
      issue is either P0 or P1 we assume that is actively worked on.
 1. Remove the `untriaged` label.
 
-Note that you need to be in the [bazelbuild
-organization](https://github.com/bazelbuild) to be able to add or remove labels.
+Note that you need to be in the [bazelbuild organization](https://github.com/bazelbuild) to be able to add or remove labels.
 
 ### Pull Requests {#pull-requests}
 
@@ -138,8 +132,7 @@ issues.
   unusable, or a downed service that severely impacts development of the Bazel
   project. This includes regressions introduced in a new release that blocks a
   significant number of users, or an incompatible breaking change that was not
-  compliant to the [Breaking
-  Change](https://docs.google.com/document/d/1q5GGRxKrF_mnwtaPKI487P8OdDRh2nN7jX6U-FXnHL0/edit?pli=1#heading=h.ceof6vpkb3ik)
+  compliant to the [Breaking Change](https://docs.google.com/document/d/1q5GGRxKrF_mnwtaPKI487P8OdDRh2nN7jX6U-FXnHL0/edit?pli=1#heading=h.ceof6vpkb3ik)
   policy. No practical workaround exists.
 * [**P1**](https://github.com/bazelbuild/bazel/labels/P1) - Critical defect or
   feature which should be addressed in the next release, or a serious issue that
diff --git a/versions/9.0.0/contribute/naming.mdx b/versions/9.0.0/contribute/naming.mdx
index 41c92fc5..d579ea4a 100644
--- a/versions/9.0.0/contribute/naming.mdx
+++ b/versions/9.0.0/contribute/naming.mdx
@@ -4,8 +4,7 @@ title: 'Naming a Bazel related project'
 
 First, thank you for contributing to the Bazel ecosystem! Please reach out to
 the Bazel community on the
-[bazel-discuss mailing list](https://groups.google.com/forum/#!forum/bazel-discuss
-) to share your project and its suggested name.
+[bazel-discuss mailing list](https://groups.google.com/forum/#!forum/bazel-discuss) to share your project and its suggested name.
 
 If you are building a Bazel related tool or sharing your Skylark rules,
 we recommend following these guidelines for the name of your project:
diff --git a/versions/9.0.0/contribute/patch-acceptance.mdx b/versions/9.0.0/contribute/patch-acceptance.mdx
index 58c5a4fd..1603c24f 100644
--- a/versions/9.0.0/contribute/patch-acceptance.mdx
+++ b/versions/9.0.0/contribute/patch-acceptance.mdx
@@ -11,29 +11,24 @@ code base.
    need a corresponding issue for tracking.
 1. If you're proposing significant changes, write a
    [design document](/versions/9.0.0/contribute/design-documents).
-1. Ensure you've signed a [Contributor License
-   Agreement](https://cla.developers.google.com).
+1. Ensure you've signed a [Contributor License Agreement](https://cla.developers.google.com).
 1. Prepare a git commit that implements the feature. Don't forget to add tests
    and update the documentation. If your change has user-visible effects, please
    [add release notes](/versions/9.0.0/contribute/release-notes). If it is an incompatible change,
    read the [guide for rolling out breaking changes](/versions/9.0.0/contribute/breaking-changes).
 1. Create a pull request on
    [GitHub](https://github.com/bazelbuild/bazel/pulls). If you're new to GitHub,
-   read [about pull
-   requests](https://help.github.com/articles/about-pull-requests/). Note that
+   read [about pull requests](https://help.github.com/articles/about-pull-requests/). Note that
    we restrict permissions to create branches on the main Bazel repository, so
-   you will need to push your commit to [your own fork of the
-   repository](https://help.github.com/articles/working-with-forks/).
+   you will need to push your commit to [your own fork of the repository](https://help.github.com/articles/working-with-forks/).
 1. A Bazel maintainer should assign you a reviewer within two business days
    (excluding holidays in the USA and Germany). If you aren't assigned a
    reviewer in that time, you can request one by emailing
-   [bazel-discuss@googlegroups.com]
-   (mailto:bazel-discuss@googlegroups.com).
+   [bazel-discuss@googlegroups.com](mailto:bazel-discuss@googlegroups.com).
 1. Work with the reviewer to complete a code review. For each change, create a
    new commit and push it to make changes to your pull request. If the review
    takes too long (for instance, if the reviewer is unresponsive), send an email to
-   [bazel-discuss@googlegroups.com]
-   (mailto:bazel-discuss@googlegroups.com).
+   [bazel-discuss@googlegroups.com](mailto:bazel-discuss@googlegroups.com).
 1. After your review is complete, a Bazel maintainer applies your patch to
    Google's internal version control system.
 
diff --git a/versions/9.0.0/contribute/release-notes.mdx b/versions/9.0.0/contribute/release-notes.mdx
index f423378d..b15e8fc0 100644
--- a/versions/9.0.0/contribute/release-notes.mdx
+++ b/versions/9.0.0/contribute/release-notes.mdx
@@ -16,8 +16,7 @@ the release announcement.
 * If the change adds / removes / changes Bazel in a user-visible way, then it
   may be advantageous to mention it.
 
-If the change is significant, follow the [design document
-policy](/versions/9.0.0/contribute/design-documents) first.
+If the change is significant, follow the [design document policy](/versions/9.0.0/contribute/design-documents) first.
 
 ## Guidelines {#guidelines}
 
@@ -60,10 +59,8 @@ change is about.
 
 ## Process {#process}
 
-As part of the [release
-process](https://github.com/bazelbuild/continuous-integration/blob/master/docs/release-playbook.md),
-we collect the `RELNOTES` tags of every commit. We copy everything in a [Google
-Doc](https://docs.google.com/document/d/1wDvulLlj4NAlPZamdlEVFORks3YXJonCjyuQMUQEmB0/edit)
+As part of the [release process](https://github.com/bazelbuild/continuous-integration/blob/master/docs/release-playbook.md),
+we collect the `RELNOTES` tags of every commit. We copy everything in a [Google Doc](https://docs.google.com/document/d/1wDvulLlj4NAlPZamdlEVFORks3YXJonCjyuQMUQEmB0/edit)
 where we review, edit, and organize the notes.
 
 The release manager sends an email to the
@@ -71,6 +68,4 @@ The release manager sends an email to the
 Bazel contributors are invited to contribute to the document and make sure
 their changes are correctly reflected in the announcement.
 
-Later, the announcement will be submitted to the [Bazel
-blog](https://blog.bazel.build/), using the [bazel-blog
-repository](https://github.com/bazelbuild/bazel-blog/tree/master/_posts).
+Later, the announcement will be submitted to the [Bazel blog](https://blog.bazel.build/), using the [bazel-blog repository](https://github.com/bazelbuild/bazel-blog/tree/master/_posts).
diff --git a/versions/9.0.0/contribute/statemachine-guide.mdx b/versions/9.0.0/contribute/statemachine-guide.mdx
index e4fdbe31..068f0242 100644
--- a/versions/9.0.0/contribute/statemachine-guide.mdx
+++ b/versions/9.0.0/contribute/statemachine-guide.mdx
@@ -172,8 +172,7 @@ instead, batches[^4] as many lookups as possible before doing so. The value
 might not be immediately available, for example, requiring a Skyframe restart,
 so the caller specifies what to do with the resulting value using a callback.
 
-The `StateMachine` processor ([`Driver`s and bridging to
-SkyFrame](#drivers-and-bridging)) guarantees that the value is available before
+The `StateMachine` processor ([`Driver`s and bridging to SkyFrame](#drivers-and-bridging)) guarantees that the value is available before
 the next state begins. An example follows.
 
 ```
@@ -284,8 +283,7 @@ and solutions to certain control flow problems.
 ### Sequential states
 
 This is the most common and straightforward control flow pattern. An example of
-this is shown in [Stateful computations inside
-`SkyKeyComputeState`](#stateful-computations).
+this is shown in [Stateful computations inside `SkyKeyComputeState`](#stateful-computations).
 
 ### Branching
 
@@ -545,8 +543,7 @@ section describes the propagation of data values.
 
 ### Implementing `Tasks.lookUp` callbacks
 
-There’s an example of implementing a `Tasks.lookUp` callback in [SkyValue
-lookups](#skyvalue-lookups). This section provides rationale and suggests
+There’s an example of implementing a `Tasks.lookUp` callback in [SkyValue lookups](#skyvalue-lookups). This section provides rationale and suggests
 approaches for handling multiple SkyValues.
 
 #### `Tasks.lookUp` callbacks {#tasks-lookup-callbacks}
@@ -710,8 +707,7 @@ class BarProducer implements StateMachine {
 Tip: It would be tempting to use the more concise signature void `accept(Bar
 value)` rather than the stuttery `void acceptBarValue(Bar value)` above.
 However, `Consumer` is a common overload of `void accept(Bar value)`,
-so doing this often leads to violations of the [Overloads: never
-split](https://google.github.io/styleguide/javaguide.html#s3.4.2-ordering-class-contents)
+so doing this often leads to violations of the [Overloads: never split](https://google.github.io/styleguide/javaguide.html#s3.4.2-ordering-class-contents)
 style-guide rule.
 
 Tip: Using a custom `ResultSink` type instead of a generic one from
@@ -774,14 +770,11 @@ pattern after accepting output from either a subtask or SkyValue lookup.
 Note that the implementation of `acceptBarError` eagerly forwards the result to
 the `Caller.ResultSink`, as required by [Error bubbling](#error-bubbling).
 
-Alternatives for top-level `StateMachine`s are described in [`Driver`s and
-bridging to SkyFunctions](#drivers-and-bridging).
+Alternatives for top-level `StateMachine`s are described in [`Driver`s and bridging to SkyFunctions](#drivers-and-bridging).
 
 ### Error handling {#error-handling}
 
-There's a couple of examples of error handling already in [`Tasks.lookUp`
-callbacks](#tasks-lookup-callbacks) and [Propagating values between
-`StateMachines`](#propagating-values). Exceptions, other than
+There's a couple of examples of error handling already in [`Tasks.lookUp` callbacks](#tasks-lookup-callbacks) and [Propagating values between `StateMachines`](#propagating-values). Exceptions, other than
 `InterruptedException` are not thrown, but instead passed around through
 callbacks as values. Such callbacks often have exclusive-or semantics, with
 exactly one of a value or error being passed.
@@ -1184,8 +1177,7 @@ states. Where it is possible, local stack `step` variables are young generation
 variables and efficiently GC'd.
 
 For `StateMachine` variables, breaking things down into subtasks and following
-the recommended pattern for [Propagating values between
-`StateMachine`s](#propagating-values) is also helpful. Observe that when
+the recommended pattern for [Propagating values between `StateMachine`s](#propagating-values) is also helpful. Observe that when
 following the pattern, only child `StateMachine`s have references to parent
 `StateMachine`s and not vice versa. This means that as children complete and
 update the parents using result callbacks, the children naturally fall out of
@@ -1207,8 +1199,7 @@ potentially reflecting local behavior.
 
 ### Concurrency tree diagram {#concurrency-tree-diagram}
 
-The following is an alternative view of the diagram in [Structured
-concurrency](#structured-concurrency) that better depicts the tree structure.
+The following is an alternative view of the diagram in [Structured concurrency](#structured-concurrency) that better depicts the tree structure.
 The blocks form a small tree.
 
 ![Structured Concurrency 3D](/versions/9.0.0/contribute/images/structured-concurrency-3d.svg)
diff --git a/versions/9.0.0/docs/android-instrumentation-test.mdx b/versions/9.0.0/docs/android-instrumentation-test.mdx
index fa25a42b..78aa17a2 100644
--- a/versions/9.0.0/docs/android-instrumentation-test.mdx
+++ b/versions/9.0.0/docs/android-instrumentation-test.mdx
@@ -2,8 +2,7 @@
 title: 'Android Instrumentation Tests'
 ---
 
-_If you're new to Bazel, start with the [Building Android with
-Bazel](/versions/9.0.0/start/android-app ) tutorial._
+_If you're new to Bazel, start with the [Building Android with Bazel](/versions/9.0.0/start/android-app) tutorial._
 
 ![Running Android instrumentation tests in parallel](/versions/9.0.0/docs/images/android_test.gif "Android instrumentation test")
 
@@ -18,9 +17,7 @@ emulators in a sandbox, ensuring that tests always run from a clean state. Each
 test gets an isolated emulator instance, allowing tests to run in parallel
 without passing states between them.
 
-For more information on Android instrumentation tests, check out the [Android
-developer
-documentation](https://developer.android.com/training/testing/unit-testing/instrumented-unit-tests.html).
+For more information on Android instrumentation tests, check out the [Android developer documentation](https://developer.android.com/training/testing/unit-testing/instrumented-unit-tests.html).
 
 Please file issues in the [GitHub issue tracker](https://github.com/bazelbuild/bazel/issues).
 
@@ -58,8 +55,7 @@ This results in output similar to the following:
 release 4.1.0
 ```
 
-- **KVM**. Bazel requires emulators to have [hardware
-  acceleration](https://developer.android.com/studio/run/emulator-acceleration.html#accel-check)
+- **KVM**. Bazel requires emulators to have [hardware acceleration](https://developer.android.com/studio/run/emulator-acceleration.html#accel-check)
   with KVM on Linux. You can follow these
   [installation instructions](https://help.ubuntu.com/community/KVM/Installation)
   for Ubuntu.
@@ -173,11 +169,9 @@ The main attributes of the rule `android_instrumentation_test` are:
 
 - `target_device`: An `android_device` target. This target describes the
   specifications of the Android emulator which Bazel uses to create, launch and
-  run the tests. See the [section on choosing an Android
-  device](#android-device-target) for more information.
+  run the tests. See the [section on choosing an Android device](#android-device-target) for more information.
 
-The test app's `AndroidManifest.xml` must include [an ``
-tag](https://developer.android.com/studio/test/#configure_instrumentation_manifest_settings).
+The test app's `AndroidManifest.xml` must include [an `` tag](https://developer.android.com/studio/test/#configure_instrumentation_manifest_settings).
 This tag must specify the attributes for the **package of the target app** and
 the **fully qualified class name of the instrumentation test runner**,
 `androidx.test.runner.AndroidJUnitRunner`.
@@ -214,8 +208,7 @@ repositories:
 - `@androidsdk`: The Android SDK. Download this through Android Studio.
 
 - `@android_test_support`: Hosts the test runner, emulator launcher, and
-  `android_device` targets. You can find the [latest release
-  here](https://github.com/android/android-test/releases).
+  `android_device` targets. You can find the [latest release here](https://github.com/android/android-test/releases).
 
 Enable these dependencies by adding the following lines to your `WORKSPACE`
 file:
@@ -240,8 +233,7 @@ android_test_repositories()
 
 ## Maven dependencies {#maven-dependencies}
 
-For managing dependencies on Maven artifacts from repositories, such as [Google
-Maven](https://maven.google.com) or [Maven Central](https://central.maven.org),
+For managing dependencies on Maven artifacts from repositories, such as [Google Maven](https://maven.google.com) or [Maven Central](https://central.maven.org),
 you should use a Maven resolver, such as
 [`rules_jvm_external`](https://github.com/bazelbuild/rules_jvm_external).
 
@@ -370,8 +362,7 @@ the device/emulator listed in `adb devices`.
 
 ## Sample projects {#sample-projects}
 
-If you are looking for canonical project samples, see the [Android testing
-samples](https://github.com/googlesamples/android-testing#experimental-bazel-support)
+If you are looking for canonical project samples, see the [Android testing samples](https://github.com/googlesamples/android-testing#experimental-bazel-support)
 for projects using Espresso and UIAutomator.
 
 ## Espresso setup {#espresso-setup}
@@ -560,8 +551,7 @@ API_LEVELS = [
 
 ## Known issues {#known-issues}
 
-- [Forked adb server processes are not terminated after
-  tests](https://github.com/bazelbuild/bazel/issues/4853)
+- [Forked adb server processes are not terminated after tests](https://github.com/bazelbuild/bazel/issues/4853)
 - While APK building works on all platforms (Linux, macOS, Windows), testing
   only works on Linux.
 - Even with `--config=local_adb`, users still need to specify
diff --git a/versions/9.0.0/docs/android-ndk.mdx b/versions/9.0.0/docs/android-ndk.mdx
index cbf846c7..4f0b1f43 100644
--- a/versions/9.0.0/docs/android-ndk.mdx
+++ b/versions/9.0.0/docs/android-ndk.mdx
@@ -2,8 +2,7 @@
 title: 'Using the Android Native Development Kit with Bazel'
 ---
 
-_If you're new to Bazel, please start with the [Building Android with
-Bazel](/versions/9.0.0/start/android-app ) tutorial._
+_If you're new to Bazel, please start with the [Building Android with Bazel](/versions/9.0.0/start/android-app) tutorial._
 
 ## Overview {#overview}
 
@@ -155,8 +154,7 @@ more details.
 
 ## Example setup {#example-setup}
 
-This example is available in the [Bazel examples
-repository](https://github.com/bazelbuild/examples/tree/master/android/ndk).
+This example is available in the [Bazel examples repository](https://github.com/bazelbuild/examples/tree/master/android/ndk).
 
 In the `BUILD.bazel` file, three targets are defined with the `android_binary`,
 `android_library`, and `cc_library` rules.
diff --git a/versions/9.0.0/docs/bazel-and-android.mdx b/versions/9.0.0/docs/bazel-and-android.mdx
index 2c579c52..0bc38f39 100644
--- a/versions/9.0.0/docs/bazel-and-android.mdx
+++ b/versions/9.0.0/docs/bazel-and-android.mdx
@@ -10,7 +10,7 @@ Android projects with Bazel.
 
 The following resources will help you work with Bazel on Android projects:
 
-*  [Tutorial: Building an Android app](/versions/9.0.0/start/android-app ). This
+*  [Tutorial: Building an Android app](/versions/9.0.0/start/android-app). This
    tutorial is a good place to start learning about Bazel commands and concepts,
    and how to build Android apps with Bazel.
 *  [Codelab: Building Android Apps with Bazel](https://developer.android.com/codelabs/bazel-android-intro#0).
diff --git a/versions/9.0.0/docs/configurable-attributes.mdx b/versions/9.0.0/docs/configurable-attributes.mdx
index 42b009f6..ba33ddb0 100644
--- a/versions/9.0.0/docs/configurable-attributes.mdx
+++ b/versions/9.0.0/docs/configurable-attributes.mdx
@@ -2,8 +2,7 @@
 title: 'Configurable Build Attributes'
 ---
 
-**_Configurable attributes_**, commonly known as [`select()`](
-/reference/be/functions#select), is a Bazel feature that lets users toggle the values
+**_Configurable attributes_**, commonly known as [`select()`](/versions/9.0.0/reference/be/functions#select), is a Bazel feature that lets users toggle the values
 of build rule attributes at the command line.
 
 This can be used, for example, for a multiplatform library that automatically
@@ -408,8 +407,7 @@ sh_library(
 )
 ```
 
-If you need a `select` to match when multiple conditions match, consider [AND
-chaining](#and-chaining).
+If you need a `select` to match when multiple conditions match, consider [AND chaining](#and-chaining).
 
 ## OR chaining {#or-chaining}
 
diff --git a/versions/9.0.0/docs/images/a_b_a_c.svg b/versions/9.0.0/docs/images/a_b_a_c.svg
new file mode 100644
index 00000000..d38be075
--- /dev/null
+++ b/versions/9.0.0/docs/images/a_b_a_c.svg
@@ -0,0 +1,42 @@
+
+
+
+
+
+
+G
+
+
+
+a
+
+a
+
+
+
+b
+
+b
+
+
+
+a->b
+
+
+
+
+
+c
+
+c
+
+
+
+a->c
+
+
+
+
+
+
diff --git a/versions/9.0.0/docs/images/a_b_c.svg b/versions/9.0.0/docs/images/a_b_c.svg
new file mode 100644
index 00000000..acd948ab
--- /dev/null
+++ b/versions/9.0.0/docs/images/a_b_c.svg
@@ -0,0 +1,41 @@
+
+
+
+
+
+
+G
+
+
+
+a
+
+a
+
+
+
+b
+
+b
+
+
+
+a->b
+
+
+
+
+
+c
+
+c
+
+
+
+b->c
+
+
+
+
+
diff --git a/versions/9.0.0/docs/images/a_b_c_ac.svg b/versions/9.0.0/docs/images/a_b_c_ac.svg
new file mode 100644
index 00000000..b099c53e
--- /dev/null
+++ b/versions/9.0.0/docs/images/a_b_c_ac.svg
@@ -0,0 +1,47 @@
+
+
+
+
+
+
+G
+
+
+
+a
+
+a
+
+
+
+b
+
+b
+
+
+
+a->b
+
+
+
+
+
+c
+
+c
+
+
+
+a->c
+
+
+
+
+
+b->c
+
+
+
+
+
diff --git a/versions/9.0.0/docs/images/ab_c.svg b/versions/9.0.0/docs/images/ab_c.svg
new file mode 100644
index 00000000..bcc4563f
--- /dev/null
+++ b/versions/9.0.0/docs/images/ab_c.svg
@@ -0,0 +1,36 @@
+
+
+
+
+
+
+G
+
+
+
+a
+
+a
+
+
+
+b
+
+b
+
+
+
+a->b
+
+
+
+
+
+c
+
+c
+
+
+
+
diff --git a/versions/9.0.0/docs/images/allpaths.svg b/versions/9.0.0/docs/images/allpaths.svg
new file mode 100644
index 00000000..47d0ee33
--- /dev/null
+++ b/versions/9.0.0/docs/images/allpaths.svg
@@ -0,0 +1,141 @@
+
+
+
+
+
+
+allpaths
+
+
+
+n1
+
+
+
+
+n2
+
+
+
+
+n1->n2
+
+
+
+
+
+n3
+
+
+
+
+n2->n3
+
+
+
+
+
+n10
+
+
+
+
+n2->n10
+
+
+
+
+
+n3->n10
+
+
+
+
+
+n4
+
+E
+
+
+
+n5
+
+
+
+
+n6
+
+
+
+
+n5->n6
+
+
+
+
+
+n6->n4
+
+
+
+
+
+n9
+
+
+
+
+n6->n9
+
+
+
+
+
+n7
+
+S1
+
+
+
+n7->n2
+
+
+
+
+
+n7->n5
+
+
+
+
+
+n8
+
+S2
+
+
+
+n8->n6
+
+
+
+
+
+n10->n4
+
+
+
+
+
+n11
+
+
+
+
+n10->n11
+
+
+
+
+
diff --git a/versions/9.0.0/docs/images/android_instrumentation_test.png b/versions/9.0.0/docs/images/android_instrumentation_test.png
new file mode 100644
index 00000000..e4534fbd
Binary files /dev/null and b/versions/9.0.0/docs/images/android_instrumentation_test.png differ
diff --git a/versions/9.0.0/docs/images/android_ndk.png b/versions/9.0.0/docs/images/android_ndk.png
new file mode 100644
index 00000000..76b63cb3
Binary files /dev/null and b/versions/9.0.0/docs/images/android_ndk.png differ
diff --git a/versions/9.0.0/docs/images/android_tutorial_app.png b/versions/9.0.0/docs/images/android_tutorial_app.png
new file mode 100644
index 00000000..076be5b9
Binary files /dev/null and b/versions/9.0.0/docs/images/android_tutorial_app.png differ
diff --git a/versions/9.0.0/docs/images/android_tutorial_before.png b/versions/9.0.0/docs/images/android_tutorial_before.png
new file mode 100644
index 00000000..8e41d419
Binary files /dev/null and b/versions/9.0.0/docs/images/android_tutorial_before.png differ
diff --git a/versions/9.0.0/docs/images/bep-graph.png b/versions/9.0.0/docs/images/bep-graph.png
new file mode 100644
index 00000000..82da6715
Binary files /dev/null and b/versions/9.0.0/docs/images/bep-graph.png differ
diff --git a/versions/9.0.0/docs/images/bep-graph.svg b/versions/9.0.0/docs/images/bep-graph.svg
new file mode 100644
index 00000000..62b1480f
--- /dev/null
+++ b/versions/9.0.0/docs/images/bep-graph.svg
@@ -0,0 +1,4 @@
+
+
+
+
diff --git a/versions/9.0.0/docs/images/cpp-tutorial-stage1.png b/versions/9.0.0/docs/images/cpp-tutorial-stage1.png
new file mode 100644
index 00000000..c85fb303
Binary files /dev/null and b/versions/9.0.0/docs/images/cpp-tutorial-stage1.png differ
diff --git a/versions/9.0.0/docs/images/cpp-tutorial-stage2.png b/versions/9.0.0/docs/images/cpp-tutorial-stage2.png
new file mode 100644
index 00000000..80e202c9
Binary files /dev/null and b/versions/9.0.0/docs/images/cpp-tutorial-stage2.png differ
diff --git a/versions/9.0.0/docs/images/cpp-tutorial-stage3.png b/versions/9.0.0/docs/images/cpp-tutorial-stage3.png
new file mode 100644
index 00000000..54d82f31
Binary files /dev/null and b/versions/9.0.0/docs/images/cpp-tutorial-stage3.png differ
diff --git a/versions/9.0.0/docs/images/deps.svg b/versions/9.0.0/docs/images/deps.svg
new file mode 100644
index 00000000..4354222a
--- /dev/null
+++ b/versions/9.0.0/docs/images/deps.svg
@@ -0,0 +1,101 @@
+
+
+
+
+
+
+G1
+
+
+
+r1
+
+rule
+
+
+
+s1
+
+in
+
+
+
+r1->s1
+
+
+
+
+
+s2
+
+in
+
+
+
+r1->s2
+
+
+
+
+
+s3
+
+in
+
+
+
+r1->s3
+
+
+
+
+
+r2
+
+rule
+
+
+
+r2->r1
+
+
+
+
+
+s4
+
+in
+
+
+
+r2->s4
+
+
+
+
+
+o1
+
+out
+
+
+
+o1->r1
+
+
+
+
+
+o2
+
+out
+
+
+
+o2->r2
+
+
+
+
+
diff --git a/versions/9.0.0/docs/images/dyn-trace-alldynamic.png b/versions/9.0.0/docs/images/dyn-trace-alldynamic.png
new file mode 100644
index 00000000..fe36b253
Binary files /dev/null and b/versions/9.0.0/docs/images/dyn-trace-alldynamic.png differ
diff --git a/versions/9.0.0/docs/images/dyn-trace-javaconly.png b/versions/9.0.0/docs/images/dyn-trace-javaconly.png
new file mode 100644
index 00000000..2ae41e52
Binary files /dev/null and b/versions/9.0.0/docs/images/dyn-trace-javaconly.png differ
diff --git a/versions/9.0.0/docs/images/e4b-workflow.png b/versions/9.0.0/docs/images/e4b-workflow.png
new file mode 100644
index 00000000..412822da
Binary files /dev/null and b/versions/9.0.0/docs/images/e4b-workflow.png differ
diff --git a/versions/9.0.0/docs/images/e4b-workflow.svg b/versions/9.0.0/docs/images/e4b-workflow.svg
new file mode 100644
index 00000000..1de66e02
--- /dev/null
+++ b/versions/9.0.0/docs/images/e4b-workflow.svg
@@ -0,0 +1,4 @@
+
+
+
+
diff --git a/versions/9.0.0/docs/images/error_example_1.png b/versions/9.0.0/docs/images/error_example_1.png
new file mode 100644
index 00000000..07ba1358
Binary files /dev/null and b/versions/9.0.0/docs/images/error_example_1.png differ
diff --git a/versions/9.0.0/docs/images/error_example_2.png b/versions/9.0.0/docs/images/error_example_2.png
new file mode 100644
index 00000000..861171ee
Binary files /dev/null and b/versions/9.0.0/docs/images/error_example_2.png differ
diff --git a/versions/9.0.0/docs/images/error_example_3.png b/versions/9.0.0/docs/images/error_example_3.png
new file mode 100644
index 00000000..dc16eec4
Binary files /dev/null and b/versions/9.0.0/docs/images/error_example_3.png differ
diff --git a/versions/9.0.0/docs/images/error_example_4.png b/versions/9.0.0/docs/images/error_example_4.png
new file mode 100644
index 00000000..84383e63
Binary files /dev/null and b/versions/9.0.0/docs/images/error_example_4.png differ
diff --git a/versions/9.0.0/docs/images/graph_ex_1.svg b/versions/9.0.0/docs/images/graph_ex_1.svg
new file mode 100644
index 00000000..dd7427f4
--- /dev/null
+++ b/versions/9.0.0/docs/images/graph_ex_1.svg
@@ -0,0 +1,131 @@
+
+
+
+
+
+
+mygraph
+
+
+
+//net/proto_compiler:protocol-compiler
+
+//net/proto_compiler:protocol-compiler
+
+
+
+//net/proto_compiler:util
+
+//net/proto_compiler:util
+
+
+
+//net/proto_compiler:protocol-compiler->//net/proto_compiler:util
+
+
+
+
+
+//net/proto_compiler:protocol-compiler-lib
+
+//net/proto_compiler:protocol-compiler-lib
+
+
+
+//net/proto_compiler:protocol-compiler->//net/proto_compiler:protocol-compiler-lib
+
+
+
+
+
+//net/proto2/bridge/public:compiler_upgrader
+
+//net/proto2/bridge/public:compiler_upgrader
+
+
+
+//net/proto_compiler:protocol-compiler->//net/proto2/bridge/public:compiler_upgrader
+
+
+
+
+
+//net/proto_compiler:parser
+
+//net/proto_compiler:parser
+
+
+
+//net/proto_compiler:util->//net/proto_compiler:parser
+
+
+
+
+
+//net/proto_compiler:proto-min-lib
+
+//net/proto_compiler:proto-min-lib
+
+
+
+//net/proto_compiler:protocol-compiler-lib->//net/proto_compiler:proto-min-lib
+
+
+
+
+
+//net/proto_compiler:protocol-compiler-lib->//net/proto_compiler:parser
+
+
+
+
+
+//net/proto2/bridge/internal:compiler_upgrader
+
+//net/proto2/bridge/internal:compiler_upgrader
+
+
+
+//net/proto2/bridge/public:compiler_upgrader->//net/proto2/bridge/internal:compiler_upgrader
+
+
+
+
+
+//net/proto_compiler:proto-min-lib->//net/proto_compiler:parser
+
+
+
+
+
+//util/regexp:regexp
+
+//util/regexp:regexp
+
+
+
+//net/proto_compiler:proto-min-lib->//util/regexp:regexp
+
+
+
+
+
+//net/proto_compiler:parser->//util/regexp:regexp
+
+
+
+
+
+//net/proto2/bridge/internal:compiler_upgrader->//net/proto2/bridge/public:compiler_upgrader
+
+
+
+
+
+//net/proto2/bridge/internal:compiler_upgrader->//net/proto_compiler:parser
+
+
+
+
+
diff --git a/versions/9.0.0/docs/images/graph_hello-world.svg b/versions/9.0.0/docs/images/graph_hello-world.svg
new file mode 100644
index 00000000..93b61444
--- /dev/null
+++ b/versions/9.0.0/docs/images/graph_hello-world.svg
@@ -0,0 +1,70 @@
+
+
+
+
+
+
+mygraph
+
+
+//main:hello-world
+
+//main:hello-world
+
+
+//main:hello-time
+
+//main:hello-time
+
+
+//main:hello-world->//main:hello-time
+
+
+
+
+//main:hello-world.cc
+
+//main:hello-world.cc
+
+
+//main:hello-world->//main:hello-world.cc
+
+
+
+
+//lib:hello-greet
+
+//lib:hello-greet
+
+
+//main:hello-world->//lib:hello-greet
+
+
+
+
+//main:hello-time.cc\n//main:hello-time.h
+
+//main:hello-time.cc
+//main:hello-time.h
+
+
+//main:hello-time->//main:hello-time.cc\n//main:hello-time.h
+
+
+
+
+//lib:hello-greet.cc\n//lib:hello-greet.h
+
+//lib:hello-greet.cc
+//lib:hello-greet.h
+
+
+//lib:hello-greet->//lib:hello-greet.cc\n//lib:hello-greet.h
+
+
+
+
+
diff --git a/versions/9.0.0/docs/images/json-trace-profile-network-usage.png b/versions/9.0.0/docs/images/json-trace-profile-network-usage.png
new file mode 100644
index 00000000..8a7500a6
Binary files /dev/null and b/versions/9.0.0/docs/images/json-trace-profile-network-usage.png differ
diff --git a/versions/9.0.0/docs/images/json-trace-profile-system-load-average.png b/versions/9.0.0/docs/images/json-trace-profile-system-load-average.png
new file mode 100644
index 00000000..e71b420c
Binary files /dev/null and b/versions/9.0.0/docs/images/json-trace-profile-system-load-average.png differ
diff --git a/versions/9.0.0/docs/images/json-trace-profile-workers-memory-usage.png b/versions/9.0.0/docs/images/json-trace-profile-workers-memory-usage.png
new file mode 100644
index 00000000..806505f0
Binary files /dev/null and b/versions/9.0.0/docs/images/json-trace-profile-workers-memory-usage.png differ
diff --git a/versions/9.0.0/docs/images/json-trace-profile.png b/versions/9.0.0/docs/images/json-trace-profile.png
new file mode 100644
index 00000000..538382b2
Binary files /dev/null and b/versions/9.0.0/docs/images/json-trace-profile.png differ
diff --git a/versions/9.0.0/docs/images/mobile-install-performance.svg b/versions/9.0.0/docs/images/mobile-install-performance.svg
new file mode 100644
index 00000000..b139d658
--- /dev/null
+++ b/versions/9.0.0/docs/images/mobile-install-performance.svg
@@ -0,0 +1,86 @@
+
+
+
+  
+    
+      
+    
+  
+  
+  
+    Build times
+  
+  
+    
+    
+      
+      
+        adb install
+      
+      
+    
+    
+      
+      
+        mobile-install
+      
+      
+    
+  
+  
+    
+    
+      
+        
+        
+        
+        
+        
+      
+      
+        
+        
+        
+        
+        
+        
+      
+      
+        
+      
+    
+    
+    
+      
+        Google Maps
+      
+      
+        Google+
+      
+      
+        YouTube
+      
+      
+        0
+      
+      
+        75
+      
+      
+        150
+      
+      
+        225
+      
+      
+        300
+      
+    
+  
+  
+    
+      Seconds
+    
+  
+  
+
diff --git a/versions/9.0.0/docs/images/namedsetoffiles-bep-graph.png b/versions/9.0.0/docs/images/namedsetoffiles-bep-graph.png
new file mode 100644
index 00000000..ea1e10cc
Binary files /dev/null and b/versions/9.0.0/docs/images/namedsetoffiles-bep-graph.png differ
diff --git a/versions/9.0.0/docs/images/out-ranked.svg b/versions/9.0.0/docs/images/out-ranked.svg
new file mode 100644
index 00000000..07e96804
--- /dev/null
+++ b/versions/9.0.0/docs/images/out-ranked.svg
@@ -0,0 +1,71 @@
+
+
+
+
+
+
+mygraph
+
+
+
+//a:a
+
+//a:a
+
+
+
+//a:a.cc
+
+//a:a.cc
+
+
+
+//a:a->//a:a.cc
+
+
+
+
+
+//b:b
+
+//b:b
+
+
+
+//b:b->//a:a
+
+
+
+
+
+//b:b.cc
+
+//b:b.cc
+
+
+
+//b:b->//b:b.cc
+
+
+
+
+
+//c:c
+
+//c:c
+
+
+
+//c:c->//a:a
+
+
+
+
+
+//c:c->//b:b
+
+
+
+
+
diff --git a/versions/9.0.0/docs/images/rbe-ci-1.png b/versions/9.0.0/docs/images/rbe-ci-1.png
new file mode 100644
index 00000000..fbe76a85
Binary files /dev/null and b/versions/9.0.0/docs/images/rbe-ci-1.png differ
diff --git a/versions/9.0.0/docs/images/rbe-ci-2.png b/versions/9.0.0/docs/images/rbe-ci-2.png
new file mode 100644
index 00000000..07611889
Binary files /dev/null and b/versions/9.0.0/docs/images/rbe-ci-2.png differ
diff --git a/versions/9.0.0/docs/images/somepath1.svg b/versions/9.0.0/docs/images/somepath1.svg
new file mode 100644
index 00000000..5e5f8812
--- /dev/null
+++ b/versions/9.0.0/docs/images/somepath1.svg
@@ -0,0 +1,141 @@
+
+
+
+
+
+
+somepath1
+
+
+
+n1
+
+
+
+
+n2
+
+
+
+
+n1->n2
+
+
+
+
+
+n3
+
+
+
+
+n2->n3
+
+
+
+
+
+n10
+
+
+
+
+n2->n10
+
+
+
+
+
+n3->n10
+
+
+
+
+
+n4
+
+E
+
+
+
+n5
+
+
+
+
+n6
+
+
+
+
+n5->n6
+
+
+
+
+
+n6->n4
+
+
+
+
+
+n9
+
+
+
+
+n6->n9
+
+
+
+
+
+n7
+
+S1
+
+
+
+n7->n2
+
+
+
+
+
+n7->n5
+
+
+
+
+
+n8
+
+S2
+
+
+
+n8->n6
+
+
+
+
+
+n10->n4
+
+
+
+
+
+n11
+
+
+
+
+n10->n11
+
+
+
+
+
diff --git a/versions/9.0.0/docs/images/somepath2.svg b/versions/9.0.0/docs/images/somepath2.svg
new file mode 100644
index 00000000..911f2c9b
--- /dev/null
+++ b/versions/9.0.0/docs/images/somepath2.svg
@@ -0,0 +1,141 @@
+
+
+
+
+
+
+somepath2
+
+
+
+n1
+
+
+
+
+n2
+
+
+
+
+n1->n2
+
+
+
+
+
+n3
+
+
+
+
+n2->n3
+
+
+
+
+
+n10
+
+
+
+
+n2->n10
+
+
+
+
+
+n3->n10
+
+
+
+
+
+n4
+
+E
+
+
+
+n5
+
+
+
+
+n6
+
+
+
+
+n5->n6
+
+
+
+
+
+n6->n4
+
+
+
+
+
+n9
+
+
+
+
+n6->n9
+
+
+
+
+
+n7
+
+S1
+
+
+
+n7->n2
+
+
+
+
+
+n7->n5
+
+
+
+
+
+n8
+
+S2
+
+
+
+n8->n6
+
+
+
+
+
+n10->n4
+
+
+
+
+
+n11
+
+
+
+
+n10->n11
+
+
+
+
+
diff --git a/versions/9.0.0/docs/images/targets.svg b/versions/9.0.0/docs/images/targets.svg
new file mode 100644
index 00000000..82f47e74
--- /dev/null
+++ b/versions/9.0.0/docs/images/targets.svg
@@ -0,0 +1,113 @@
+
+
+
+
+
+
+G1
+
+
+
+Target
+
+Target
+
+
+
+Rule
+
+Rule
+
+
+
+Target->Rule
+
+
+
+
+
+File
+
+File
+
+
+
+Target->File
+
+
+
+
+
+Package group
+
+Package group
+
+
+
+Target->Package group
+
+
+
+
+
+cc_library
+
+cc_library
+
+
+
+Rule->cc_library
+
+
+
+
+
+java_test
+
+java_test
+
+
+
+Rule->java_test
+
+
+
+
+
+...
+
+...
+
+
+
+Rule->...
+
+
+
+
+
+Source
+
+Source
+
+
+
+File->Source
+
+
+
+
+
+Generated
+
+Generated
+
+
+
+File->Generated
+
+
+
+
+
diff --git a/versions/9.0.0/docs/images/tutorial_java_01.svg b/versions/9.0.0/docs/images/tutorial_java_01.svg
new file mode 100644
index 00000000..2fe72f36
--- /dev/null
+++ b/versions/9.0.0/docs/images/tutorial_java_01.svg
@@ -0,0 +1,29 @@
+
+
+
+
+
+
+mygraph
+
+
+//:ProjectRunner
+
+//:ProjectRunner
+
+
+//:src/main/java/com/example/Greeting.java\n//:src/main/java/com/example/ProjectRunner.java
+
+//:src/main/java/com/example/Greeting.java
+//:src/main/java/com/example/ProjectRunner.java
+
+
+//:ProjectRunner->//:src/main/java/com/example/Greeting.java\n//:src/main/java/com/example/ProjectRunner.java
+
+
+
+
+
diff --git a/versions/9.0.0/docs/images/tutorial_java_02.svg b/versions/9.0.0/docs/images/tutorial_java_02.svg
new file mode 100644
index 00000000..40cbb218
--- /dev/null
+++ b/versions/9.0.0/docs/images/tutorial_java_02.svg
@@ -0,0 +1,48 @@
+
+
+
+
+
+
+mygraph
+
+
+//:ProjectRunner
+
+//:ProjectRunner
+
+
+//:greeter
+
+//:greeter
+
+
+//:ProjectRunner->//:greeter
+
+
+
+
+//:src/main/java/com/example/ProjectRunner.java
+
+//:src/main/java/com/example/ProjectRunner.java
+
+
+//:ProjectRunner->//:src/main/java/com/example/ProjectRunner.java
+
+
+
+
+//:src/main/java/com/example/Greeting.java
+
+//:src/main/java/com/example/Greeting.java
+
+
+//:greeter->//:src/main/java/com/example/Greeting.java
+
+
+
+
+
diff --git a/versions/9.0.0/docs/images/tutorial_java_03.svg b/versions/9.0.0/docs/images/tutorial_java_03.svg
new file mode 100644
index 00000000..7d79041a
--- /dev/null
+++ b/versions/9.0.0/docs/images/tutorial_java_03.svg
@@ -0,0 +1,48 @@
+
+
+
+
+
+
+mygraph
+
+
+//src/main/java/com/example/cmdline:runner
+
+//src/main/java/com/example/cmdline:runner
+
+
+//src/main/java/com/example/cmdline:Runner.java
+
+//src/main/java/com/example/cmdline:Runner.java
+
+
+//src/main/java/com/example/cmdline:runner->//src/main/java/com/example/cmdline:Runner.java
+
+
+
+
+//:greeter
+
+//:greeter
+
+
+//src/main/java/com/example/cmdline:runner->//:greeter
+
+
+
+
+//:src/main/java/com/example/Greeting.java
+
+//:src/main/java/com/example/Greeting.java
+
+
+//:greeter->//:src/main/java/com/example/Greeting.java
+
+
+
+
+
diff --git a/versions/9.0.0/docs/images/workers-clean-chart.png b/versions/9.0.0/docs/images/workers-clean-chart.png
new file mode 100644
index 00000000..63526fc1
Binary files /dev/null and b/versions/9.0.0/docs/images/workers-clean-chart.png differ
diff --git a/versions/9.0.0/docs/images/workers-incremental-chart.png b/versions/9.0.0/docs/images/workers-incremental-chart.png
new file mode 100644
index 00000000..1c62d25c
Binary files /dev/null and b/versions/9.0.0/docs/images/workers-incremental-chart.png differ
diff --git a/versions/9.0.0/docs/images/ws-diamond.png b/versions/9.0.0/docs/images/ws-diamond.png
new file mode 100644
index 00000000..154a7440
Binary files /dev/null and b/versions/9.0.0/docs/images/ws-diamond.png differ
diff --git a/versions/9.0.0/docs/images/ws-line.png b/versions/9.0.0/docs/images/ws-line.png
new file mode 100644
index 00000000..e8bfe7a1
Binary files /dev/null and b/versions/9.0.0/docs/images/ws-line.png differ
diff --git a/versions/9.0.0/docs/images/ws-multiline.png b/versions/9.0.0/docs/images/ws-multiline.png
new file mode 100644
index 00000000..f07b43b1
Binary files /dev/null and b/versions/9.0.0/docs/images/ws-multiline.png differ
diff --git a/versions/9.0.0/docs/sandboxing.mdx b/versions/9.0.0/docs/sandboxing.mdx
index eca0df55..1fb19c84 100644
--- a/versions/9.0.0/docs/sandboxing.mdx
+++ b/versions/9.0.0/docs/sandboxing.mdx
@@ -48,7 +48,7 @@ containers on Linux and `sandbox-exec` on macOS, to constrain the action within
 ## What sandbox strategy to use {#sandboxing-strategies}
 
 You can choose which kind of sandboxing to use, if any, with the
-[strategy flags](user-manual#strategy-options). Using the `sandboxed`
+[strategy flags](/versions/9.0.0/docs/user-manual#strategy-options). Using the `sandboxed`
 strategy makes Bazel pick one of the sandbox implementations listed below,
 preferring an OS-specific sandbox to the less hermetic generic one.
 [Persistent workers](/versions/9.0.0/remote/persistent) run in a generic sandbox if you pass
diff --git a/versions/9.0.0/docs/user-manual.mdx b/versions/9.0.0/docs/user-manual.mdx
index ff599f90..a2086e86 100644
--- a/versions/9.0.0/docs/user-manual.mdx
+++ b/versions/9.0.0/docs/user-manual.mdx
@@ -1146,12 +1146,12 @@ during execution can be examined.
 This option causes Bazel's execution phase to print the full command line
 for each command prior to executing it.
 
-
-  >>>>> # //examples/cpp:hello-world [action 'Linking examples/cpp/hello-world']
+```
+  >>>> # //examples/cpp:hello-world [action 'Linking examples/cpp/hello-world']
   (cd /home/johndoe/.cache/bazel/_bazel_johndoe/4c084335afceb392cfbe7c31afee3a9f/bazel && \
     exec env - \
     /usr/bin/gcc -o bazel-out/local-fastbuild/bin/examples/cpp/hello-world -B/usr/bin/ -Wl,-z,relro,-z,now -no-canonical-prefixes -pass-exit-codes -Wl,-S -Wl,@bazel-out/local_linux-fastbuild/bin/examples/cpp/hello-world-2.params)
-

+```
 
 Where possible, commands are printed in a Bourne shell compatible syntax,
 so that they can be easily copied and pasted to a shell command prompt.
diff --git a/versions/9.0.0/extending/auto-exec-groups.mdx b/versions/9.0.0/extending/auto-exec-groups.mdx
index e3b23c54..9b6d2d36 100644
--- a/versions/9.0.0/extending/auto-exec-groups.mdx
+++ b/versions/9.0.0/extending/auto-exec-groups.mdx
@@ -27,9 +27,7 @@ doesn't detect that ([the error](#first-error-message) is raised), you can set
 
 If you need to use multiple toolchains on a single execution platform (an action
 uses executable or tools from two or more toolchains), you need to manually
-define [exec_groups][exec_groups] (check
-[When should I use a custom exec_group?][multiple_toolchains_exec_groups]
-section).
+define [exec_groups][exec_groups](check [When should I use a custom exec_group?][multiple_toolchains_exec_groups] section).
 
 ## History {#history}
 
@@ -42,8 +40,7 @@ my_rule = rule(
 )
 ```
 
-Rule `my_rule` registers two toolchain types. This means that the [Toolchain
-Resolution](https://bazel.build/extending/toolchains#toolchain-resolution) used
+Rule `my_rule` registers two toolchain types. This means that the [Toolchain Resolution](https://bazel.build/versions/9.0.0/extending/toolchains#toolchain-resolution) used
 to find an execution platform which supports both toolchain types. The selected
 execution platform was used for each registered action inside the rule, unless
 specified differently with [exec_groups][exec_groups].
diff --git a/versions/9.0.0/extending/concepts.mdx b/versions/9.0.0/extending/concepts.mdx
index 56dcdc1d..b5be9a11 100644
--- a/versions/9.0.0/extending/concepts.mdx
+++ b/versions/9.0.0/extending/concepts.mdx
@@ -20,16 +20,14 @@ Before learning the more advanced concepts, first:
 ## Macros and rules {#macros-and-rules}
 
 A macro is a function that instantiates rules. Macros come in two flavors:
-[symbolic macros](/versions/9.0.0/extending/macros) (new in Bazel 8) and [legacy
-macros](/versions/9.0.0/extending/legacy-macros). The two flavors of macros are defined
+[symbolic macros](/versions/9.0.0/extending/macros) (new in Bazel 8) and [legacy macros](/versions/9.0.0/extending/legacy-macros). The two flavors of macros are defined
 differently, but behave almost the same from the point of view of a user. A
 macro is useful when a `BUILD` file is getting too repetitive or too complex, as
 it lets you reuse some code. The function is evaluated as soon as the `BUILD`
 file is read. After the evaluation of the `BUILD` file, Bazel has little
 information about macros. If your macro generates a `genrule`, Bazel will
 behave *almost* as if you declared that `genrule` in the `BUILD` file. (The one
-exception is that targets declared in a symbolic macro have [special visibility
-semantics](/versions/9.0.0/extending/macros#visibility): a symbolic macro can hide its internal
+exception is that targets declared in a symbolic macro have [special visibility semantics](/versions/9.0.0/extending/macros#visibility): a symbolic macro can hide its internal
 targets from the rest of the package.)
 
 A [rule](/versions/9.0.0/extending/rules) is more powerful than a macro. It can access Bazel
@@ -76,8 +74,7 @@ they will not be executed.
 ## Creating extensions
 
 * [Create your first macro](/versions/9.0.0/rules/macro-tutorial) in order to reuse some code.
-  Then [learn more about macros](/versions/9.0.0/extending/macros) and [using them to create
-  "custom verbs"](/versions/9.0.0/rules/verbs-tutorial).
+  Then [learn more about macros](/versions/9.0.0/extending/macros) and [using them to create "custom verbs"](/versions/9.0.0/rules/verbs-tutorial).
 
 * [Follow the rules tutorial](/versions/9.0.0/rules/rules-tutorial) to get started with rules.
   Next, you can read more about the [rules concepts](/versions/9.0.0/extending/rules).
@@ -92,8 +89,7 @@ them within reach:
 ## Going further
 
 In addition to [macros](/versions/9.0.0/extending/macros) and [rules](/versions/9.0.0/extending/rules), you
-may want to write [aspects](/versions/9.0.0/extending/aspects) and [repository
-rules](/versions/9.0.0/external/repo).
+may want to write [aspects](/versions/9.0.0/extending/aspects) and [repository rules](/versions/9.0.0/external/repo).
 
 * Use [Buildifier](https://github.com/bazelbuild/buildtools)
   consistently to format and lint your code.
diff --git a/versions/9.0.0/extending/depsets.mdx b/versions/9.0.0/extending/depsets.mdx
index 7326a9d5..0da23426 100644
--- a/versions/9.0.0/extending/depsets.mdx
+++ b/versions/9.0.0/extending/depsets.mdx
@@ -111,8 +111,7 @@ need to ensure that if `B` depends on `A`, then `A.o` comes before `B.o` on the
 linker’s command line. Other tools might have the opposite requirement.
 
 Three traversal orders are supported: `postorder`, `preorder`, and
-`topological`. The first two work exactly like [tree
-traversals](https://en.wikipedia.org/wiki/Tree_traversal#Depth-first_search)
+`topological`. The first two work exactly like [tree traversals](https://en.wikipedia.org/wiki/Tree_traversal#Depth-first_search)
 except that they operate on DAGs and skip already visited nodes. The third order
 works as a topological sort from root to leaves, essentially the same as
 preorder except that shared children are listed only after all of their parents.
diff --git a/versions/9.0.0/extending/exec-groups.mdx b/versions/9.0.0/extending/exec-groups.mdx
index 9c1b6b22..65fe89de 100644
--- a/versions/9.0.0/extending/exec-groups.mdx
+++ b/versions/9.0.0/extending/exec-groups.mdx
@@ -70,8 +70,7 @@ test rules.
 
 In the rule implementation, you can declare that actions should be run on the
 execution platform of an execution group. You can do this by using the `exec_group`
-param of action generating methods, specifically [`ctx.actions.run`]
-(/rules/lib/builtins/actions#run) and
+param of action generating methods, specifically [`ctx.actions.run`](/versions/9.0.0/rules/lib/builtins/actions#run) and
 [`ctx.actions.run_shell`](/versions/9.0.0/rules/lib/builtins/actions#run_shell).
 
 ```python
diff --git a/versions/9.0.0/extending/legacy-macros.mdx b/versions/9.0.0/extending/legacy-macros.mdx
index af9ffa80..1710dfe7 100644
--- a/versions/9.0.0/extending/legacy-macros.mdx
+++ b/versions/9.0.0/extending/legacy-macros.mdx
@@ -9,7 +9,7 @@ anymore, and Bazel sees only the concrete set of instantiated rules.
 
 ## Why you shouldn't use legacy macros (and should use Symbolic macros instead) {#no-legacy-macros}
 
-Where possible you should use [symbolic macros](macros.md#macros).
+Where possible you should use [symbolic macros](/versions/9.0.0/extending/macros#macros).
 
 Symbolic macros
 
@@ -18,7 +18,7 @@ Symbolic macros
 *   Take typed attributes, which in turn means automatic label and select
     conversion.
 *   Are more readable
-*   Will soon have [lazy evaluation](macros.md#laziness)
+*   Will soon have [lazy evaluation](/versions/9.0.0/extending/macros#laziness)
 
 ## Usage {#usage}
 
@@ -152,7 +152,7 @@ the macro), use the function
 ## Label resolution in macros {#label-resolution}
 
 Since legacy macros are evaluated in the
-[loading phase](concepts.md#evaluation-model), label strings such as
+[loading phase](/versions/9.0.0/extending/concepts#evaluation-model), label strings such as
 `"//foo:bar"` that occur in a legacy macro are interpreted relative to the
 `BUILD` file in which the macro is used rather than relative to the `.bzl` file
 in which it is defined. This behavior is generally undesirable for macros that
diff --git a/versions/9.0.0/extending/macros.mdx b/versions/9.0.0/extending/macros.mdx
index 66e06a43..94a87ff7 100644
--- a/versions/9.0.0/extending/macros.mdx
+++ b/versions/9.0.0/extending/macros.mdx
@@ -10,7 +10,7 @@ Macros are mainly used for encapsulation and code reuse of existing rules and
 other macros.
 
 Macros come in two flavors: symbolic macros, which are described on this page,
-and [legacy macros](legacy-macros.md). Where possible, we recommend using
+and [legacy macros](/versions/9.0.0/extending/legacy-macros). Where possible, we recommend using
 symbolic macros for code clarity.
 
 Symbolic macros offer typed arguments (string to label conversion, relative to
@@ -31,8 +31,7 @@ two required parameters: `attrs` and `implementation`.
 
 ### Attributes {#attributes}
 
-`attrs` accepts a dictionary of attribute name to [attribute
-types](https://bazel.build/rules/lib/toplevel/attr#members), which represents
+`attrs` accepts a dictionary of attribute name to [attribute types](https://bazel.build/versions/9.0.0/rules/lib/toplevel/attr#members), which represents
 the arguments to the macro. Two common attributes – `name` and `visibility` –
 are implicitly added to all macros and are not included in the dictionary passed
 to `attrs`.
@@ -66,9 +65,7 @@ To support this pattern, a macro can *inherit attributes* from a rule or another
 macro by passing the [rule](https://bazel.build/versions/9.0.0/rules/lib/builtins/rule) or
 [macro symbol](https://bazel.build/versions/9.0.0/rules/lib/builtins/macro) to `macro()`'s
 `inherit_attrs` argument. (You can also use the special string `"common"`
-instead of a rule or macro symbol to inherit the [common attributes defined for
-all Starlark build
-rules](https://bazel.build/reference/be/common-definitions#common-attributes).)
+instead of a rule or macro symbol to inherit the [common attributes defined for all Starlark build rules](https://bazel.build/versions/9.0.0/reference/be/common-definitions#common-attributes).)
 Only public attributes get inherited, and the attributes in the macro's own
 `attrs` dictionary override inherited attributes with the same name. You can
 also *remove* inherited attributes by using `None` as a value in the `attrs`
diff --git a/versions/9.0.0/extending/platforms.mdx b/versions/9.0.0/extending/platforms.mdx
index 27b2d6ee..09b850e2 100644
--- a/versions/9.0.0/extending/platforms.mdx
+++ b/versions/9.0.0/extending/platforms.mdx
@@ -254,8 +254,7 @@ cc_library(
 
 You can use the
 [`IncompatiblePlatformProvider`](/versions/9.0.0/rules/lib/providers/IncompatiblePlatformProvider)
-in `bazel cquery`'s [Starlark output
-format](/versions/9.0.0/query/cquery#output-format-definition) to distinguish
+in `bazel cquery`'s [Starlark output format](/versions/9.0.0/query/cquery#output-format-definition) to distinguish
 incompatible targets from compatible ones.
 
 This can be used to filter out incompatible targets. The example below will
@@ -275,5 +274,4 @@ $ bazel cquery //... --output=starlark --starlark:file=example.cquery
 
 ### Known Issues
 
-Incompatible targets [ignore visibility
-restrictions](https://github.com/bazelbuild/bazel/issues/16044).
+Incompatible targets [ignore visibility restrictions](https://github.com/bazelbuild/bazel/issues/16044).
diff --git a/versions/9.0.0/extending/rules.mdx b/versions/9.0.0/extending/rules.mdx
index 8a56e6e1..57d4aeed 100644
--- a/versions/9.0.0/extending/rules.mdx
+++ b/versions/9.0.0/extending/rules.mdx
@@ -449,8 +449,7 @@ def _example_library_impl(ctx):
 
 If `DefaultInfo` is not returned by a rule implementation or the `files`
 parameter is not specified, `DefaultInfo.files` defaults to all
-*predeclared outputs* (generally, those created by [output
-attributes](#output_attributes)).
+*predeclared outputs* (generally, those created by [output attributes](#output_attributes)).
 
 Rules that perform actions should provide default outputs, even if those outputs
 are not expected to be directly used. Actions that are not in the graph of the
@@ -993,8 +992,7 @@ By using `configuration_field`, the dependency on the Java LCOV merger tool can
 be avoided as long as coverage is not requested.
 
 When the test is run, it should emit coverage information in the form of one or
-more [LCOV files]
-(https://manpages.debian.org/unstable/lcov/geninfo.1.en.html#TRACEFILE_FORMAT)
+more [LCOV files](https://manpages.debian.org/unstable/lcov/geninfo.1.en.html#TRACEFILE_FORMAT)
 with unique names into the directory specified by the `COVERAGE_DIR` environment
 variable. Bazel will then merge these files into a single LCOV file using the
 `_lcov_merger` tool. If present, it will also collect C/C++ coverage using the
diff --git a/versions/9.0.0/extending/toolchains.mdx b/versions/9.0.0/extending/toolchains.mdx
index 6d8e88c6..20dc4ab8 100644
--- a/versions/9.0.0/extending/toolchains.mdx
+++ b/versions/9.0.0/extending/toolchains.mdx
@@ -581,8 +581,7 @@ The set of available toolchains, in priority order, is created from
   4. Toolchains registered in the "WORKSPACE suffix"; this is only used by
      certain native rules bundled with the Bazel installation.
 
-**NOTE:** [Pseudo-targets like `:all`, `:*`, and
-`/...`](/versions/9.0.0/run/build#specifying-build-targets) are ordered by Bazel's package
+**NOTE:** [Pseudo-targets like `:all`, `:*`, and `/...`](/versions/9.0.0/run/build#specifying-build-targets) are ordered by Bazel's package
 loading mechanism, which uses a lexicographic ordering.
 
 The resolution steps are as follows.
diff --git a/versions/9.0.0/external/extension.mdx b/versions/9.0.0/external/extension.mdx
index 0334020a..037eea94 100644
--- a/versions/9.0.0/external/extension.mdx
+++ b/versions/9.0.0/external/extension.mdx
@@ -4,8 +4,7 @@ title: 'Module extensions'
 
 Module extensions allow users to extend the module system by reading input data
 from modules across the dependency graph, performing necessary logic to resolve
-dependencies, and finally creating repos by calling [repo
-rules](/versions/9.0.0/external/repo). These extensions have capabilities similar to repo
+dependencies, and finally creating repos by calling [repo rules](/versions/9.0.0/external/repo). These extensions have capabilities similar to repo
 rules, which enables them to perform file I/O, send network requests, and so on.
 Among other things, they allow Bazel to interact with other package management
 systems while also respecting the dependency graph built out of Bazel modules.
diff --git a/versions/9.0.0/external/faq.mdx b/versions/9.0.0/external/faq.mdx
index eaa160e3..ee5e0034 100644
--- a/versions/9.0.0/external/faq.mdx
+++ b/versions/9.0.0/external/faq.mdx
@@ -61,7 +61,7 @@ expected when sorting (the empty string is treated as the highest version).
 
 ### When should I increment the compatibility level?
 
-The [`compatibility_level`](module.md#compatibility_level) of a Bazel module
+The [`compatibility_level`](/versions/9.0.0/external/module#compatibility_level) of a Bazel module
 should be incremented _in the same commit_ that introduces a backwards
 incompatible ("breaking") change.
 
@@ -99,7 +99,7 @@ generally interested in, and they can be solved without `load`s:
     `load`s in MODULE.bazel files, `include` cannot be used in non-root modules.
 *   Users of the old WORKSPACE system might remember declaring a repo, and then
     immediately `load`ing from that repo to perform complex logic. This
-    capability has been replaced by [module extensions](extension).
+    capability has been replaced by [module extensions](/versions/9.0.0/external/extension).
 
 ### Can I specify a SemVer range for a `bazel_dep`? {#can-i-specify-a-semver-range-for-a-bazel-dep}
 
@@ -108,20 +108,18 @@ support version ranges (implicitly or explicitly), and this often requires a
 constraint solver (making the output harder to predict for users) and makes
 version resolution nonreproducible without a lockfile.
 
-Bazel instead uses [Minimal Version Selection](module#version-selection) like
+Bazel instead uses [Minimal Version Selection](/versions/9.0.0/external/module#version-selection) like
 Go, which in contrast makes the output easy to predict and guarantees
 reproducibility. This is a tradeoff that matches Bazel's design goals.
 
-Furthermore, Bazel module versions are [a superset of
-SemVer](module#version-format), so what makes sense in a strict SemVer
+Furthermore, Bazel module versions are [a superset of SemVer](/versions/9.0.0/external/module#version-format), so what makes sense in a strict SemVer
 environment doesn't always carry over to Bazel module versions.
 
 ### Can I automatically get the latest version for a `bazel_dep`? {#can-i-automatically-get-the-latest-version-for-a-bazel-dep}
 
 Some users occasionally ask for the ability to specify `bazel_dep(name = "foo",
 version = "latest")` to automatically get the latest version of a dep. This is
-similar to [the question about SemVer
-ranges](#can-i-specify-a-semver-range-for-a-bazel-dep), and the answer is also
+similar to [the question about SemVer ranges](#can-i-specify-a-semver-range-for-a-bazel-dep), and the answer is also
 no.
 
 The recommended solution here is to have automation take care of this. For
@@ -179,8 +177,7 @@ wonder which system is consulted first. The short answer is that MODULE.bazel
 
 The long answer is that "which evaluates first" is not the right question to
 ask; rather, the right question to ask is: in the context of the repo with
-[canonical name](overview#canonical-repo-name) `@@foo`, what does the [apparent
-repo name](overview#apparent-repo-name) `@bar` resolve to? Alternatively, what
+[canonical name](/versions/9.0.0/external/overview#canonical-repo-name) `@@foo`, what does the [apparent repo name](/versions/9.0.0/external/overview#apparent-repo-name) `@bar` resolve to? Alternatively, what
 is the repo mapping of `@@base`?
 
 Labels with apparent repo names (a single leading `@`) can refer to different
@@ -189,8 +186,7 @@ things based on the context they're resolved from. When you see a label
 what the context repo is: for example, if the label is in a BUILD file located
 in the repo `@@foo`, then the context repo is `@@foo`.
 
-Then, depending on what the context repo is, the ["repository
-visibility" table](migration#repository-visibility) in the migration guide can
+Then, depending on what the context repo is, the ["repository visibility" table](/versions/9.0.0/external/migration#repository-visibility) in the migration guide can
 be used to find out which repo an apparent name actually resolves to.
 
 *   If the context repo is the main repo (`@@`):
@@ -242,8 +238,7 @@ as the context repo.
 
 Use the `bazel fetch` command to prefetch repos. You can use the `--repo` flag
 (like `bazel fetch --repo @foo`) to fetch only the repo `@foo` (resolved in the
-context of the main repo, see [question
-above](#which-is-evaluated-first-module-bazel-or-workspace)), or use a target
+context of the main repo, see [question above](#which-is-evaluated-first-module-bazel-or-workspace)), or use a target
 pattern (like `bazel fetch @foo//:bar`) to fetch all transitive dependencies of
 `@foo//:bar` (this is equivalent to `bazel build --nobuild @foo//:bar`).
 
@@ -251,7 +246,7 @@ The make sure no fetches happen during a build, use `--nofetch`. More precisely,
 this makes any attempt to run a non-local repository rule fail.
 
 If you want to fetch repos _and_ modify them to test locally, consider using
-the [`bazel vendor`](vendor) command.
+the [`bazel vendor`](/versions/9.0.0/external/vendor) command.
 
 ### How do I use HTTP proxies? {#how-do-i-use-http-proxies}
 
@@ -267,21 +262,17 @@ preferring IPv4 if enabled. In some situations, for example when the IPv4
 network cannot resolve/reach external addresses, this can cause `Network
 unreachable` exceptions and build failures. In these cases, you can override
 Bazel's behavior to prefer IPv6 by using the
-[`java.net.preferIPv6Addresses=true` system
-property](https://docs.oracle.com/javase/8/docs/api/java/net/doc-files/net-properties.html).
+[`java.net.preferIPv6Addresses=true` system property](https://docs.oracle.com/javase/8/docs/api/java/net/doc-files/net-properties.html).
 Specifically:
 
-*   Use `--host_jvm_args=-Djava.net.preferIPv6Addresses=true` [startup
-    option](/versions/9.0.0/docs/user-manual#startup-options), for example by adding the
+*   Use `--host_jvm_args=-Djava.net.preferIPv6Addresses=true` [startup option](/versions/9.0.0/docs/user-manual#startup-options), for example by adding the
     following line in your [`.bazelrc` file](/versions/9.0.0/run/bazelrc):
 
     `startup --host_jvm_args=-Djava.net.preferIPv6Addresses=true`
 
 *   When running Java build targets that need to connect to the internet (such
     as for integration tests), use the
-    `--jvmopt=-Djava.net.preferIPv6Addresses=true` [tool
-    flag](/versions/9.0.0/docs/user-manual#jvmopt). For example, include in your [`.bazelrc`
-    file](/versions/9.0.0/run/bazelrc):
+    `--jvmopt=-Djava.net.preferIPv6Addresses=true` [tool flag](/versions/9.0.0/docs/user-manual#jvmopt). For example, include in your [`.bazelrc` file](/versions/9.0.0/run/bazelrc):
 
     `build --jvmopt=-Djava.net.preferIPv6Addresses`
 
@@ -289,8 +280,7 @@ Specifically:
     [`rules_jvm_external`](https://github.com/bazelbuild/rules_jvm_external) for
     dependency version resolution, also add
     `-Djava.net.preferIPv6Addresses=true` to the `COURSIER_OPTS` environment
-    variable to [provide JVM options for
-    Coursier](https://github.com/bazelbuild/rules_jvm_external#provide-jvm-options-for-coursier-with-coursier_opts).
+    variable to [provide JVM options for Coursier](https://github.com/bazelbuild/rules_jvm_external#provide-jvm-options-for-coursier-with-coursier_opts).
 
 ### Can repo rules be run remotely with remote execution? {#can-repo-rules-be-run-remotely-with-remote-execution}
 
@@ -315,9 +305,7 @@ build rules, which would naturally allow them to be run remotely, but conversely
 raise new architectural concerns (for example, the `query` commands would
 potentially need to run actions, complicating their design).
 
-For more previous discussion on this topic, see [A way to support repositories
-that need Bazel for being
-fetched](https://github.com/bazelbuild/bazel/discussions/20464).
+For more previous discussion on this topic, see [A way to support repositories that need Bazel for being fetched](https://github.com/bazelbuild/bazel/discussions/20464).
 
 [npm-semver]: https://docs.npmjs.com/about-semantic-versioning
 [cargo-semver]: https://doc.rust-lang.org/cargo/reference/specifying-dependencies.html#version-requirement-syntax
diff --git a/versions/9.0.0/external/images/mod_exampleBefore.svg b/versions/9.0.0/external/images/mod_exampleBefore.svg
new file mode 100644
index 00000000..66f01303
--- /dev/null
+++ b/versions/9.0.0/external/images/mod_exampleBefore.svg
@@ -0,0 +1,175 @@
+
+
+
+
+
+
+mygraph
+
+
+
+<root>
+
+<root> (my_project@1.0)
+
+
+
+bazel_skylib@1.1.1
+
+bazel_skylib@1.1.1
+
+
+
+<root>->bazel_skylib@1.1.1
+
+
+
+
+
+bazel_skylib@1.2.0
+
+bazel_skylib@1.2.0
+
+
+
+<root>->bazel_skylib@1.2.0
+
+
+
+
+
+rules_java@5.0.0
+
+rules_java@5.0.0
+
+
+
+<root>->rules_java@5.0.0
+
+
+
+
+
+stardoc@0.5.0
+
+stardoc@0.5.0
+
+
+
+<root>->stardoc@0.5.0
+
+
+
+
+
+platforms@0.0.4
+
+platforms@0.0.4
+
+
+
+bazel_skylib@1.1.1->platforms@0.0.4
+
+
+
+
+
+bazel_skylib@1.2.0->platforms@0.0.4
+
+
+
+
+
+rules_java@5.0.0->platforms@0.0.4
+
+
+
+
+
+rules_cc@0.0.1
+
+rules_cc@0.0.1
+
+
+
+rules_java@5.0.0->rules_cc@0.0.1
+
+
+
+
+
+rules_proto@4.0.0
+
+rules_proto@4.0.0
+
+
+
+rules_java@5.0.0->rules_proto@4.0.0
+
+
+
+
+
+bazel_skylib@1.0.3
+
+bazel_skylib@1.0.3
+
+
+
+stardoc@0.5.0->bazel_skylib@1.0.3
+
+
+
+
+
+rules_java@4.0.0
+
+rules_java@4.0.0
+
+
+
+stardoc@0.5.0->rules_java@4.0.0
+
+
+
+
+
+rules_cc@0.0.1->platforms@0.0.4
+
+
+
+
+
+rules_cc@0.0.1->bazel_skylib@1.0.3
+
+
+
+
+
+rules_proto@4.0.0->rules_cc@0.0.1
+
+
+
+
+
+rules_proto@4.0.0->bazel_skylib@1.0.3
+
+
+
+
+
+bazel_skylib@1.0.3->platforms@0.0.4
+
+
+
+
+
+rules_java@4.0.0->bazel_skylib@1.0.3
+
+
+
+
+
\ No newline at end of file
diff --git a/versions/9.0.0/external/images/mod_exampleResolved.svg b/versions/9.0.0/external/images/mod_exampleResolved.svg
new file mode 100644
index 00000000..224b694c
--- /dev/null
+++ b/versions/9.0.0/external/images/mod_exampleResolved.svg
@@ -0,0 +1,151 @@
+
+
+
+
+
+
+mygraph
+
+
+
+<root>
+
+<root> (my_project@1.0)
+
+
+
+bazel_skylib@1.1.1
+
+bazel_skylib@1.1.1
+
+
+
+<root>->bazel_skylib@1.1.1
+
+
+
+
+
+bazel_skylib@1.2.0
+
+bazel_skylib@1.2.0
+
+
+
+<root>->bazel_skylib@1.2.0
+
+
+
+
+
+rules_java@5.0.0
+
+rules_java@5.0.0
+
+
+
+<root>->rules_java@5.0.0
+
+
+
+
+
+stardoc@0.5.0
+
+stardoc@0.5.0
+
+
+
+<root>->stardoc@0.5.0
+
+
+
+
+
+platforms@0.0.4
+
+platforms@0.0.4
+
+
+
+bazel_skylib@1.1.1->platforms@0.0.4
+
+
+
+
+
+bazel_skylib@1.2.0->platforms@0.0.4
+
+
+
+
+
+rules_java@5.0.0->platforms@0.0.4
+
+
+
+
+
+rules_cc@0.0.1
+
+rules_cc@0.0.1
+
+
+
+rules_java@5.0.0->rules_cc@0.0.1
+
+
+
+
+
+rules_proto@4.0.0
+
+rules_proto@4.0.0
+
+
+
+rules_java@5.0.0->rules_proto@4.0.0
+
+
+
+
+
+stardoc@0.5.0->bazel_skylib@1.1.1
+
+
+
+
+
+stardoc@0.5.0->rules_java@5.0.0
+
+
+
+
+
+rules_cc@0.0.1->bazel_skylib@1.1.1
+
+
+
+
+
+rules_cc@0.0.1->platforms@0.0.4
+
+
+
+
+
+rules_proto@4.0.0->bazel_skylib@1.1.1
+
+
+
+
+
+rules_proto@4.0.0->rules_cc@0.0.1
+
+
+
+
+
\ No newline at end of file
diff --git a/versions/9.0.0/external/migration.mdx b/versions/9.0.0/external/migration.mdx
index bfba0eb3..2c7a2c73 100644
--- a/versions/9.0.0/external/migration.mdx
+++ b/versions/9.0.0/external/migration.mdx
@@ -2,15 +2,14 @@
 title: 'Bzlmod Migration Guide'
 ---
 
-Due to the [shortcomings of
-WORKSPACE](/versions/9.0.0/external/overview#workspace-shortcomings), Bzlmod is replacing the
+Due to the [shortcomings of WORKSPACE](/versions/9.0.0/external/overview#workspace-shortcomings), Bzlmod is replacing the
 legacy WORKSPACE system. The WORKSPACE file is already disabled in Bazel 8 (late
 2024) and will be removed in Bazel 9 (late 2025). This guide helps you migrate
 your project to Bzlmod and drop WORKSPACE for managing external dependencies.
 
 ## Why migrate to Bzlmod? {#why-migrate-to-bzlmod}
 
-*   There are many [advantages](overview#benefits) compared to the legacy
+*   There are many [advantages](/versions/9.0.0/external/overview#benefits) compared to the legacy
     WORKSPACE system, which helps to ensure a healthy growth of the Bazel
     ecosystem.
 
@@ -29,8 +28,7 @@ Recommended migration process:
     streamline the migration process as much as possible.
 2.  If there are errors left after using the migration tool, resolve them
     manually. For understanding the main differences between concepts inside
-    `WORKSPACE` and `MODULE.bazel` files, check [WORKSPACE versus
-    Bzlmod](#workspace-vs-bzlmod) section.
+    `WORKSPACE` and `MODULE.bazel` files, check [WORKSPACE versus Bzlmod](#workspace-vs-bzlmod) section.
 
 ## WORKSPACE vs Bzlmod {#workspace-vs-bzlmod}
 
@@ -140,9 +138,7 @@ Bazel module when it also adopts Bzlmod.
 
 *   **Bzlmod**
 
-    With Bzlmod, as long as your dependency is available in [Bazel Central
-    Registry](https://registry.bazel.build) or your custom [Bazel
-    registry](/versions/9.0.0/external/registry), you can simply depend on it with a
+    With Bzlmod, as long as your dependency is available in [Bazel Central Registry](https://registry.bazel.build) or your custom [Bazel registry](/versions/9.0.0/external/registry), you can simply depend on it with a
     [`bazel_dep`](/versions/9.0.0/rules/lib/globals/module#bazel_dep) directive.
 
     ```python
@@ -173,8 +169,7 @@ repository.
 
 If your dependency is not a Bazel project or not yet available in any Bazel
 registry, you can introduce it using
-[`use_repo_rule`](/versions/9.0.0/external/module#use_repo_rule) or [module
-extensions](/versions/9.0.0/external/extension).
+[`use_repo_rule`](/versions/9.0.0/external/module#use_repo_rule) or [module extensions](/versions/9.0.0/external/extension).
 
 *   **WORKSPACE**
 
@@ -615,8 +610,7 @@ flag after fetching all repos needed for a build.
 ## Manual migration {#manual-migration}
 
 This section provides useful information and guidance for your **manual** Bzlmod
-migration process. For more automatized migration process, check [recommended
-migration process](#how-migrate-to-bzlmod) section.
+migration process. For more automatized migration process, check [recommended migration process](#how-migrate-to-bzlmod) section.
 
 ### Know your dependencies in WORKSPACE {#know-deps-in-workspace}
 
@@ -630,8 +624,7 @@ macros.
 Fortunately, the flag
 [`--experimental_repository_resolved_file`][resolved_file_flag]
 can help. This flag essentially generates a "lock file" of all fetched external
-dependencies in your last Bazel command. You can find more details in this [blog
-post](https://blog.bazel.build/2018/07/09/bazel-sync-and-resolved-file.html).
+dependencies in your last Bazel command. You can find more details in this [blog post](https://blog.bazel.build/2018/07/09/bazel-sync-and-resolved-file.html).
 
 [resolved_file_flag]: /reference/command-line-reference#flag--experimental_repository_resolved_file
 
@@ -672,11 +665,9 @@ You may also know `bazel query` can be used for inspecting repository rules with
 bazel query --output=build //external:
 ```
 
-While it is more convenient and much faster, [bazel query can lie about
-external dependency version](https://github.com/bazelbuild/bazel/issues/12947),
+While it is more convenient and much faster, [bazel query can lie about external dependency version](https://github.com/bazelbuild/bazel/issues/12947),
 so be careful using it! Querying and inspecting external
-dependencies with Bzlmod is going to achieved by a [new
-subcommand](https://github.com/bazelbuild/bazel/issues/15365).
+dependencies with Bzlmod is going to achieved by a [new subcommand](https://github.com/bazelbuild/bazel/issues/15365).
 
 #### Built-in default dependencies {#builtin-default-deps}
 
@@ -723,8 +714,7 @@ Using the WORKSPACE.bzlmod file can make the migration easier because:
 #### Repository visibility {#repository-visibility}
 
 Bzlmod is able to control which other repositories are visible from a given
-repository, check [repository names and strict
-deps](/versions/9.0.0/external/module#repository_names_and_strict_deps) for more details.
+repository, check [repository names and strict deps](/versions/9.0.0/external/module#repository_names_and_strict_deps) for more details.
 
 Here is a summary of repository visibilities from different types of
 repositories when also taking WORKSPACE into consideration.
@@ -737,8 +727,7 @@ repositories when also taking WORKSPACE into consideration.
 | WORKSPACE Repos | All visible | Not visible | Not visible | All visible |
 
 Note: For the root module, if a repository `@foo` is defined in WORKSPACE and
-`@foo` is also used as an [apparent repository
-name](/versions/9.0.0/external/overview#apparent-repo-name) in MODULE.bazel, then `@foo`
+`@foo` is also used as an [apparent repository name](/versions/9.0.0/external/overview#apparent-repo-name) in MODULE.bazel, then `@foo`
 refers to the one introduced in MODULE.bazel.
 
 Note: For a module extension generated repository `@bar`, if `@foo` is used as
@@ -783,9 +772,7 @@ the project. Take note of a few things when creating the source archive:
     GitHub isn't going to guarantee the checksum of source archives generated on
     demand. In short, URLs in the form of
     `https://github.com///releases/download/...` is considered stable
-    while `https://github.com///archive/...` is not. Check [GitHub
-    Archive Checksum
-    Outage](https://blog.bazel.build/2023/02/15/github-archive-checksum.html)
+    while `https://github.com///archive/...` is not. Check [GitHub Archive Checksum Outage](https://blog.bazel.build/2023/02/15/github-archive-checksum.html)
     for more context.
 
 *   **Make sure the source tree follows the layout of the original repository.**
@@ -814,8 +801,7 @@ Pull Request.
 
 [bcr_contrib_guide]: https://github.com/bazelbuild/bazel-central-registry/tree/main/docs#contribute-a-bazel-module
 
-It is **highly recommended** to set up the [Publish to
-BCR](https://github.com/bazel-contrib/publish-to-bcr) GitHub App for your
+It is **highly recommended** to set up the [Publish to BCR](https://github.com/bazel-contrib/publish-to-bcr) GitHub App for your
 repository to automate the process of submitting your module to the BCR.
 
 ## Best practices {#best-practices}
diff --git a/versions/9.0.0/external/migration_tool.mdx b/versions/9.0.0/external/migration_tool.mdx
index e2e5dee0..3cdaaf34 100644
--- a/versions/9.0.0/external/migration_tool.mdx
+++ b/versions/9.0.0/external/migration_tool.mdx
@@ -100,8 +100,7 @@ migrate2bzlmod -t <targets>
     script.
 *   `extension_for_XXX` - A file containing a module extension
     definition. The migration tool generates these files for dependencies that
-    are not standard Bazel modules but can be managed using Bzlmod's [module
-    extensions](/versions/9.0.0/external/extension).
+    are not standard Bazel modules but can be managed using Bzlmod's [module extensions](/versions/9.0.0/external/extension).
 
 ### Flags {#migration-script-flags}
 
@@ -298,8 +297,7 @@ def my_custom_macro(name):
 The end goal is to have `MODULE.bazel` file and delete the `WORKSPACE` file,
 without impacting the user experience.
 
-The first step is to follow [How to Use the Migration
-Tool](#migration-tool-how-to-use), which mostly is checking the bazel version
+The first step is to follow [How to Use the Migration Tool](#migration-tool-how-to-use), which mostly is checking the bazel version
 (it must be Bazel 7) and adding an alias to the migration script.
 
 Then, running `migrate2bzlmod -t=//...` outputs:
@@ -632,8 +630,7 @@ may arise during the Bzlmod migration.
 ### Migration Report Generation {#migration-tool-report-generation}
 
 This file is updated with each run of the migration script or it's generated
-from scratch if it's the first run or if the [`--i`
-flag](#migration-script-flags) is used. The report contains:
+from scratch if it's the first run or if the [`--i` flag](#migration-script-flags) is used. The report contains:
 
 *   Command for local testing.
 *   List of direct dependencies (at least the ones which are directly used in
diff --git a/versions/9.0.0/external/mod-command.mdx b/versions/9.0.0/external/mod-command.mdx
index 580533ec..6452bd61 100644
--- a/versions/9.0.0/external/mod-command.mdx
+++ b/versions/9.0.0/external/mod-command.mdx
@@ -61,11 +61,9 @@ The available subcommands and their respective required arguments are:
 
 *   ``: All present versions of the module ``.
 
-*   `@`: The repo with the given [apparent
-    name](overview#apparent-repo-name) in the context of the `--base_module`.
+*   `@`: The repo with the given [apparent name](/versions/9.0.0/external/overview#apparent-repo-name) in the context of the `--base_module`.
 
-*   `@@`: The repo with the given [canonical
-    name](overview#canonical-repo-name).
+*   `@@`: The repo with the given [canonical name](/versions/9.0.0/external/overview#canonical-repo-name).
 
 In a context requiring specifying modules, ``s referring to repos that
 correspond to modules (as opposed to extension-generated repos) can also be
@@ -89,8 +87,7 @@ The following options only affect the subcommands that print graphs (`graph`,
     information about the version resolution of each module. If the module
     version changed during resolution, show either which version replaced it or
     what was the original version, the reason it was replaced, and which modules
-    requested the new version if the reason was [Minimal Version
-    Selection](module#version-selection).
+    requested the new version if the reason was [Minimal Version Selection](/versions/9.0.0/external/module#version-selection).
 
 *   `--include_unused` *default: "false"*: Include in the output graph the
     modules which were originally present in the dependency graph, but became
@@ -210,7 +207,7 @@ use_repo(toolchains, my_jdk="remotejdk17_linux")
   

     
       

-        Graph Before Resolution
+        Graph Before Resolution
         
Graph Before Resolution

       

 {/* digraph mygraph {
@@ -240,7 +237,7 @@ use_repo(toolchains, my_jdk="remotejdk17_linux")
     		
     
       

-        Graph After Resolution
+        Graph After Resolution
        
Graph After Resolution

       

 {/* digraph mygraph {
diff --git a/versions/9.0.0/external/module.mdx b/versions/9.0.0/external/module.mdx
index 233f93ca..1a73040c 100644
--- a/versions/9.0.0/external/module.mdx
+++ b/versions/9.0.0/external/module.mdx
@@ -55,8 +55,7 @@ Any valid SemVer version is a valid Bazel module version. Additionally, two
 SemVer versions `a` and `b` compare `a < b` if and only if the same holds when
 they're compared as Bazel module versions.
 
-Finally, to learn more about module versioning, [see the `MODULE.bazel`
-FAQ](faq#module-versioning-best-practices).
+Finally, to learn more about module versioning, [see the `MODULE.bazel` FAQ](/versions/9.0.0/external/faq#module-versioning-best-practices).
 
 ## Version selection {#version-selection}
 
@@ -107,8 +106,7 @@ Bazel can throw an error if it detects that versions of the _same module_ with
 _different compatibility levels_ exist in the resolved dependency graph.
 
 Finally, incrementing the compatibility level can be disruptive to the users.
-To learn more about when and how to increment it, [check the `MODULE.bazel`
-FAQ](faq#incrementing-compatibility-level).
+To learn more about when and how to increment it, [check the `MODULE.bazel` FAQ](/versions/9.0.0/external/faq#incrementing-compatibility-level).
 
 ## Overrides
 
@@ -130,8 +128,7 @@ serves multiple purposes:
     version, regardless of which versions of the dependency are requested in the
     dependency graph.
 *   With the `registry` attribute, you can force this dependency to come from a
-    specific registry, instead of following the normal [registry
-    selection](/versions/9.0.0/external/registry#selecting_registries) process.
+    specific registry, instead of following the normal [registry selection](/versions/9.0.0/external/registry#selecting_registries) process.
 *   With the `patch*` attributes, you can specify a set of patches to apply to
     the downloaded module.
 
@@ -180,8 +177,7 @@ Bazel supports the following non-registry overrides:
 
 Note that setting a version value in the source archive `MODULE.bazel` can have
 downsides when the module is being overridden with a non-registry override. To
-learn more about this [see the `MODULE.bazel`
-FAQ](faq#module-versioning-best-practices).
+learn more about this [see the `MODULE.bazel` FAQ](/versions/9.0.0/external/faq#module-versioning-best-practices).
 
 ## Define repos that don't represent Bazel modules {#use_repo_rule}
 
@@ -189,13 +185,11 @@ With `bazel_dep`, you can define repos that represent other Bazel modules.
 Sometimes there is a need to define a repo that does _not_ represent a Bazel
 module; for example, one that contains a plain JSON file to be read as data.
 
-In this case, you could use the [`use_repo_rule`
-directive](/versions/9.0.0/rules/lib/globals/module#use_repo_rule) to directly define a repo
+In this case, you could use the [`use_repo_rule` directive](/versions/9.0.0/rules/lib/globals/module#use_repo_rule) to directly define a repo
 by invoking a repo rule. This repo will only be visible to the module it's
 defined in.
 
-Under the hood, this is implemented using the same mechanism as [module
-extensions](/versions/9.0.0/external/extension), which lets you define repos with more
+Under the hood, this is implemented using the same mechanism as [module extensions](/versions/9.0.0/external/extension), which lets you define repos with more
 flexibility.
 
 ## Repository names and strict deps
diff --git a/versions/9.0.0/external/overview.mdx b/versions/9.0.0/external/overview.mdx
index 67607c30..8db5f856 100644
--- a/versions/9.0.0/external/overview.mdx
+++ b/versions/9.0.0/external/overview.mdx
@@ -12,8 +12,7 @@ concepts in more detail.
 
 ## Overview of the system {#overview}
 
-Bazel's external dependency system works on the basis of [*Bazel
-modules*](#module), each of which is a versioned Bazel project, and
+Bazel's external dependency system works on the basis of [*Bazel modules*](#module), each of which is a versioned Bazel project, and
 [*repositories*](#repository) (or repos), which are directory trees containing
 source files.
 
@@ -30,8 +29,7 @@ bazel_dep(name = "platforms", version = "0.0.11")
 ```
 
 From there, Bazel looks up all transitive dependency modules in a
-[*Bazel registry*](registry) — by default, the [Bazel Central
-Registry](https://bcr.bazel.build/). The registry provides the
+[*Bazel registry*](/versions/9.0.0/external/registry) — by default, the [Bazel Central Registry](https://bcr.bazel.build/). The registry provides the
 dependencies' `MODULE.bazel` files, which allows Bazel to discover the entire
 transitive dependency graph before performing version resolution.
 
@@ -41,7 +39,7 @@ Bazel consults the registry again to learn how to define a repo for each module
 of the time, these are just archives downloaded from the internet and extracted.
 
 Modules can also specify customized pieces of data called *tags*, which are
-consumed by [*module extensions*](extension) after module resolution
+consumed by [*module extensions*](/versions/9.0.0/external/extension) after module resolution
 to define additional repos. These extensions can perform actions like file I/O
 and sending network requests. Among other things, they allow Bazel to interact
 with other package management systems while also respecting the dependency graph
@@ -60,12 +58,12 @@ Bazel's external dependency system offers a wide range of benefits.
 ### Automatic Dependency Resolution {#automatic-dependency-resolution}
 
 -   **Deterministic Version Resolution**: Bazel adopts the deterministic
-    [MVS](module#version-selection) version resolution algorithm,
+    [MVS](/versions/9.0.0/external/module#version-selection) version resolution algorithm,
     minimizing conflicts and addressing diamond dependency issues.
 -   **Simplified Dependency Management**: `MODULE.bazel` declares only direct
     dependencies, while transitive dependencies are automatically resolved,
     providing a clearer overview of the project's dependencies.
--   **[Strict Dependency visibility](module#repository_names_and_strict_deps)**:
+-   **[Strict Dependency visibility](/versions/9.0.0/external/module#repository_names_and_strict_deps)**:
     Only direct dependencies are visible, ensuring correctness and
     predictability.
 
@@ -92,19 +90,18 @@ Bazel's external dependency system offers a wide range of benefits.
 
 ### Advanced Features {#advanced-features}
 
--   **[Module Extensions](extension)**: The
+-   **[Module Extensions](/versions/9.0.0/external/extension)**: The
     [`use_repo_rule`](/versions/9.0.0/rules/lib/globals/module#use_repo_rule) and module
     extension features allow flexible use of custom repository rules and
     resolution logic to introduce any non-Bazel dependencies.
--   **[`bazel mod` Command](mod-command)**: The sub-command offers
+-   **[`bazel mod` Command](/versions/9.0.0/external/mod-command)**: The sub-command offers
     powerful ways to inspect external dependencies. You know exactly how an
     external dependency is defined and where it comes from.
--   **[Vendor Mode](vendor)**: Pre-fetch the exact external dependencies you
+-   **[Vendor Mode](/versions/9.0.0/external/vendor)**: Pre-fetch the exact external dependencies you
     need to facilitate offline builds.
--   **[Lockfile](lockfile)**: The lockfile improves build reproducibility and
+-   **[Lockfile](/versions/9.0.0/external/lockfile)**: The lockfile improves build reproducibility and
     accelerates dependency resolution.
--   **(Upcoming) [BCR Provenance
-    Attestations](https://github.com/bazelbuild/bazel-central-registry/discussions/2721)**:
+-   **(Upcoming) [BCR Provenance Attestations](https://github.com/bazelbuild/bazel-central-registry/discussions/2721)**:
     Strengthen supply chain security by ensuring verified provenance of
     dependencies.
 
@@ -119,7 +116,7 @@ dependencies on other modules.
 
 In a local Bazel workspace, a module is represented by a repository.
 
-For more details, see [Bazel modules](module).
+For more details, see [Bazel modules](/versions/9.0.0/external/module).
 
 ### Repository {#repository}
 
@@ -177,7 +174,7 @@ and extract it", or "fetch a certain Maven artifact and make it available as a
 `java_import` target", or simply "symlink a local directory". Every repo is
 **defined** by calling a repo rule with an appropriate number of arguments.
 
-See [Repository rules](repo) for more information about how to write
+See [Repository rules](/versions/9.0.0/external/repo) for more information about how to write
 your own repository rules.
 
 The most common repo rules by far are
@@ -228,8 +225,7 @@ contain anything to serve as a repo boundary file; however, it can also be used
 to specify some common attributes for all build targets inside the repo.
 
 The syntax of a `REPO.bazel` file is similar to `BUILD` files, except that no
-`load` statements are supported. The `repo()` function takes the same arguments as the [`package()`
-function](/versions/9.0.0/reference/be/functions#package) in `BUILD` files; whereas `package()`
+`load` statements are supported. The `repo()` function takes the same arguments as the [`package()` function](/versions/9.0.0/reference/be/functions#package) in `BUILD` files; whereas `package()`
 specifies common attributes for all build targets inside the package, `repo()`
 analogously does so for all build targets inside the repo.
 
@@ -290,7 +286,7 @@ pain points, including:
 
 Due to the shortcomings of WORKSPACE, the new module-based system (codenamed
 "Bzlmod") gradually replaced the legacy WORKSPACE system between Bazel 6 and 9.
-Read the [Bzlmod migration guide](migration) on how to migrate
+Read the [Bzlmod migration guide](/versions/9.0.0/external/migration) on how to migrate
 to Bzlmod.
 
 ### External links on Bzlmod {#external-links}
diff --git a/versions/9.0.0/external/registry.mdx b/versions/9.0.0/external/registry.mdx
index 4068f500..b9565eec 100644
--- a/versions/9.0.0/external/registry.mdx
+++ b/versions/9.0.0/external/registry.mdx
@@ -21,17 +21,15 @@ An index registry must have the following format:
 *   `/modules`: A directory containing a subdirectory for each module in this
     registry
 *   `/modules/$MODULE`: A directory containing a subdirectory for each version
-    of the module named `$MODULE`, as well as the [`metadata.json`
-    file](#metadata-json) containing metadata for this module.
+    of the module named `$MODULE`, as well as the [`metadata.json` file](#metadata-json) containing metadata for this module.
 *   `/modules/$MODULE/$VERSION`: A directory containing the following files:
     *   `MODULE.bazel`: The `MODULE.bazel` file of this module version. Note
         that this is the `MODULE.bazel` file read during Bazel's external
         dependency resolution, _not_ the one from the source archive (unless
-        there's a [non-registry
-        override](/versions/9.0.0/external/module#non-registry_overrides)). Also note that it's
+        there's a [non-registry override](/versions/9.0.0/external/module#non-registry_overrides)). Also note that it's
         best to use this file to set the version of a release and avoid doing so
         in the source archive `MODULE.bazel` file. To learn more about module
-        versioning, [see the FAQ](faq.md#module-versioning-best-practices).
+        versioning, [see the FAQ](/versions/9.0.0/external/faq#module-versioning-best-practices).
     *   [`source.json`](#source-json): A JSON file containing information on how
         to fetch the source of this module version
     *   `patches/`: An optional directory containing patch files, only used when
@@ -65,8 +63,7 @@ module, with the following fields:
 *   `versions`: An array of strings, each denoting a version of the module
     available in this registry. This array should match the children of the
     module directory.
-*   `yanked_versions`: A JSON object specifying the [*yanked*
-    versions](/versions/9.0.0/external/module#yanked_versions) of this module. The keys
+*   `yanked_versions`: A JSON object specifying the [*yanked* versions](/versions/9.0.0/external/module#yanked_versions) of this module. The keys
     should be versions to yank, and the values should be descriptions of
     why the version is yanked, ideally containing a link to more
     information.
diff --git a/versions/9.0.0/external/repo.mdx b/versions/9.0.0/external/repo.mdx
index 69b9db3d..35bc61a9 100644
--- a/versions/9.0.0/external/repo.mdx
+++ b/versions/9.0.0/external/repo.mdx
@@ -74,8 +74,7 @@ specified.
 
 The input parameter `repository_ctx` can be used to access attribute values, and
 non-hermetic functions (finding a binary, executing a binary, creating a file in
-the repository or downloading a file from the Internet). See [the API
-docs](/versions/9.0.0/rules/lib/builtins/repository_ctx) for more context. Example:
+the repository or downloading a file from the Internet). See [the API docs](/versions/9.0.0/rules/lib/builtins/repository_ctx) for more context. Example:
 
 ```python
 def _impl(repository_ctx):
@@ -144,8 +143,7 @@ definition has the `configure` attribute set, use `bazel fetch --force
 
 ## Examples
 
--   [C++ auto-configured
-    toolchain](https://cs.opensource.google/bazel/bazel/+/master:tools/cpp/cc_configure.bzl;drc=644b7d41748e09eff9e47cbab2be2263bb71f29a;l=176):
+-   [C++ auto-configured toolchain](https://cs.opensource.google/bazel/bazel/+/master:tools/cpp/cc_configure.bzl;drc=644b7d41748e09eff9e47cbab2be2263bb71f29a;l=176):
     it uses a repo rule to automatically create the C++ configuration files for
     Bazel by looking for the local C++ compiler, the environment and the flags
     the C++ compiler supports.
diff --git a/versions/9.0.0/external/vendor.mdx b/versions/9.0.0/external/vendor.mdx
index 24458591..ffbd4cc4 100644
--- a/versions/9.0.0/external/vendor.mdx
+++ b/versions/9.0.0/external/vendor.mdx
@@ -23,9 +23,7 @@ absolute path.
 ## Vendor a specific external repository {#vendor-specific-repository}
 
 You can use the `vendor` command with the `--repo` flag to specify which repo
-to vendor, it accepts both [canonical repo
-name](/versions/9.0.0/external/overview#canonical-repo-name) and [apparent repo
-name](/versions/9.0.0/external/overview#apparent-repo-name).
+to vendor, it accepts both [canonical repo name](/versions/9.0.0/external/overview#canonical-repo-name) and [apparent repo name](/versions/9.0.0/external/overview#apparent-repo-name).
 
 For example, running:
 
diff --git a/versions/9.0.0/help.mdx b/versions/9.0.0/help.mdx
index ff04941b..290b401d 100644
--- a/versions/9.0.0/help.mdx
+++ b/versions/9.0.0/help.mdx
@@ -47,5 +47,4 @@ what level of support Bazel provides.
 
 ## File a bug {#file-bug}
 
-If you encounter a bug or want to request a feature, file a [GitHub
-Issue](https://github.com/bazelbuild/bazel/issues).
+If you encounter a bug or want to request a feature, file a [GitHub Issue](https://github.com/bazelbuild/bazel/issues).
diff --git a/versions/9.0.0/images/about.svg b/versions/9.0.0/images/about.svg
new file mode 100644
index 00000000..f927298f
--- /dev/null
+++ b/versions/9.0.0/images/about.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/9.0.0/images/basics.svg b/versions/9.0.0/images/basics.svg
new file mode 100644
index 00000000..013ec519
--- /dev/null
+++ b/versions/9.0.0/images/basics.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/9.0.0/images/bazel_hero.svg b/versions/9.0.0/images/bazel_hero.svg
new file mode 100644
index 00000000..c48714d0
--- /dev/null
+++ b/versions/9.0.0/images/bazel_hero.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/9.0.0/images/community.svg b/versions/9.0.0/images/community.svg
new file mode 100644
index 00000000..29f87a76
--- /dev/null
+++ b/versions/9.0.0/images/community.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/9.0.0/images/distributed-build-remote-cache.png b/versions/9.0.0/images/distributed-build-remote-cache.png
new file mode 100644
index 00000000..99d8a915
Binary files /dev/null and b/versions/9.0.0/images/distributed-build-remote-cache.png differ
diff --git a/versions/9.0.0/images/essential_guide.svg b/versions/9.0.0/images/essential_guide.svg
new file mode 100644
index 00000000..4ee63ae9
--- /dev/null
+++ b/versions/9.0.0/images/essential_guide.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/9.0.0/images/essential_reference.svg b/versions/9.0.0/images/essential_reference.svg
new file mode 100644
index 00000000..4d29a8d5
--- /dev/null
+++ b/versions/9.0.0/images/essential_reference.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/9.0.0/images/essential_start.svg b/versions/9.0.0/images/essential_start.svg
new file mode 100644
index 00000000..c8f48f84
--- /dev/null
+++ b/versions/9.0.0/images/essential_start.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/9.0.0/images/extend.svg b/versions/9.0.0/images/extend.svg
new file mode 100644
index 00000000..77b2dd97
--- /dev/null
+++ b/versions/9.0.0/images/extend.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/9.0.0/images/guide.svg b/versions/9.0.0/images/guide.svg
new file mode 100644
index 00000000..23a5d35a
--- /dev/null
+++ b/versions/9.0.0/images/guide.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/9.0.0/images/high-level-build-system.png b/versions/9.0.0/images/high-level-build-system.png
new file mode 100644
index 00000000..462717fa
Binary files /dev/null and b/versions/9.0.0/images/high-level-build-system.png differ
diff --git a/versions/9.0.0/images/new_1.svg b/versions/9.0.0/images/new_1.svg
new file mode 100644
index 00000000..c4cd9dfd
--- /dev/null
+++ b/versions/9.0.0/images/new_1.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/9.0.0/images/new_2.svg b/versions/9.0.0/images/new_2.svg
new file mode 100644
index 00000000..c6b7021b
--- /dev/null
+++ b/versions/9.0.0/images/new_2.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/9.0.0/images/new_3.svg b/versions/9.0.0/images/new_3.svg
new file mode 100644
index 00000000..c2afb4ac
--- /dev/null
+++ b/versions/9.0.0/images/new_3.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/9.0.0/images/placeholder.png b/versions/9.0.0/images/placeholder.png
new file mode 100644
index 00000000..54f1fa0e
Binary files /dev/null and b/versions/9.0.0/images/placeholder.png differ
diff --git a/versions/9.0.0/images/reference.svg b/versions/9.0.0/images/reference.svg
new file mode 100644
index 00000000..7bbc9bea
--- /dev/null
+++ b/versions/9.0.0/images/reference.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/9.0.0/images/release_notes.svg b/versions/9.0.0/images/release_notes.svg
new file mode 100644
index 00000000..8a2e8b56
--- /dev/null
+++ b/versions/9.0.0/images/release_notes.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/9.0.0/images/remote-execution-system.png b/versions/9.0.0/images/remote-execution-system.png
new file mode 100644
index 00000000..8152fc0c
Binary files /dev/null and b/versions/9.0.0/images/remote-execution-system.png differ
diff --git a/versions/9.0.0/images/start.svg b/versions/9.0.0/images/start.svg
new file mode 100644
index 00000000..3bcebd7b
--- /dev/null
+++ b/versions/9.0.0/images/start.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/9.0.0/images/task-dependencies.png b/versions/9.0.0/images/task-dependencies.png
new file mode 100644
index 00000000..ae1f9c51
Binary files /dev/null and b/versions/9.0.0/images/task-dependencies.png differ
diff --git a/versions/9.0.0/images/test.png b/versions/9.0.0/images/test.png
new file mode 100644
index 00000000..243939da
Binary files /dev/null and b/versions/9.0.0/images/test.png differ
diff --git a/versions/9.0.0/images/transitive-dependencies.png b/versions/9.0.0/images/transitive-dependencies.png
new file mode 100644
index 00000000..ec641a08
Binary files /dev/null and b/versions/9.0.0/images/transitive-dependencies.png differ
diff --git a/versions/9.0.0/images/trunk-logo-dark.svg b/versions/9.0.0/images/trunk-logo-dark.svg
new file mode 100644
index 00000000..f25940af
--- /dev/null
+++ b/versions/9.0.0/images/trunk-logo-dark.svg
@@ -0,0 +1,22 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/versions/9.0.0/images/why_faq.svg b/versions/9.0.0/images/why_faq.svg
new file mode 100644
index 00000000..afec3f8f
--- /dev/null
+++ b/versions/9.0.0/images/why_faq.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/9.0.0/images/why_overview.svg b/versions/9.0.0/images/why_overview.svg
new file mode 100644
index 00000000..c10c363c
--- /dev/null
+++ b/versions/9.0.0/images/why_overview.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/9.0.0/images/why_vision.svg b/versions/9.0.0/images/why_vision.svg
new file mode 100644
index 00000000..739e415f
--- /dev/null
+++ b/versions/9.0.0/images/why_vision.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/9.0.0/install/bazelisk.mdx b/versions/9.0.0/install/bazelisk.mdx
index 404ab21b..6fb861bb 100644
--- a/versions/9.0.0/install/bazelisk.mdx
+++ b/versions/9.0.0/install/bazelisk.mdx
@@ -16,8 +16,7 @@ For more details, see
 ## Updating Bazel
 
 Bazel has a [backward compatibility policy](/versions/9.0.0/release/backward-compatibility)
-(see [guidance for rolling out incompatible
-changes](/versions/9.0.0/contribute/breaking-changes) if you
+(see [guidance for rolling out incompatible changes](/versions/9.0.0/contribute/breaking-changes) if you
 are the author of one). That page summarizes best practices on how to test and
 migrate your project with upcoming incompatible changes and how to provide
 feedback to the incompatible change authors.
diff --git a/versions/9.0.0/install/compile-source.mdx b/versions/9.0.0/install/compile-source.mdx
index f1624168..f8e84b02 100644
--- a/versions/9.0.0/install/compile-source.mdx
+++ b/versions/9.0.0/install/compile-source.mdx
@@ -45,8 +45,7 @@ it by typing `bazel` in a terminal.
 
 **Reason**: To build Bazel from a GitHub source tree, you need a pre-existing
 Bazel binary. You can install one from a package manager or download one from
-GitHub. See [Installing Bazel](/versions/9.0.0/install). (Or you can [build from
-scratch (bootstrap)](#bootstrap-bazel).)
+GitHub. See [Installing Bazel](/versions/9.0.0/install). (Or you can [build from scratch (bootstrap)](#bootstrap-bazel).)
 
 **Troubleshooting**:
 
@@ -238,8 +237,7 @@ For instructions for Unix-like systems, see
     ```
 
 *   **The Visual C++ compiler.** Install the Visual C++ compiler either as part
-    of Visual Studio 2015 or newer, or by installing the latest [Build Tools
-    for Visual Studio 2017](https://aka.ms/BuildTools).
+    of Visual Studio 2015 or newer, or by installing the latest [Build Tools for Visual Studio 2017](https://aka.ms/BuildTools).
 
 *   **JDK.** Version 21 is required.
 
diff --git a/versions/9.0.0/install/ide.mdx b/versions/9.0.0/install/ide.mdx
index a22ff004..25380854 100644
--- a/versions/9.0.0/install/ide.mdx
+++ b/versions/9.0.0/install/ide.mdx
@@ -38,10 +38,8 @@ To install, go to the IDE's plugin browser and search for `Bazel`.
 To manually install older versions, download the zip files from JetBrains'
 Plugin Repository and install the zip file from the IDE's plugin browser:
 
-*  [Android Studio
-   plugin](https://plugins.jetbrains.com/plugin/9185-android-studio-with-bazel)
-*  [IntelliJ
-   plugin](https://plugins.jetbrains.com/plugin/8609-intellij-with-bazel)
+*  [Android Studio plugin](https://plugins.jetbrains.com/plugin/9185-android-studio-with-bazel)
+*  [IntelliJ plugin](https://plugins.jetbrains.com/plugin/8609-intellij-with-bazel)
 *  [CLion plugin](https://plugins.jetbrains.com/plugin/9554-clion-with-bazel)
 
 ### Xcode {#xcode}
@@ -61,8 +59,7 @@ Features:
 * Starlark debugger for `.bzl` files during a build (set breakpoints, step
   through code, inspect variables, and so on)
 
-Find [the plugin on the Visual Studio
-marketplace](https://marketplace.visualstudio.com/items?itemName=BazelBuild.vscode-bazel)
+Find [the plugin on the Visual Studio marketplace](https://marketplace.visualstudio.com/items?itemName=BazelBuild.vscode-bazel)
 or the [OpenVSX marketplace](https://open-vsx.org/extension/BazelBuild/vscode-bazel).
 The plugin is [open source](https://github.com/bazelbuild/vscode-bazel).
 
@@ -83,8 +80,7 @@ See also: [Autocomplete for Source Code](#autocomplete-for-source-code)
 
 ### Emacs {#emacs}
 
-See [`bazelbuild/bazel-emacs-mode` on
-GitHub](https://github.com/bazelbuild/emacs-bazel-mode)
+See [`bazelbuild/bazel-emacs-mode` on GitHub](https://github.com/bazelbuild/emacs-bazel-mode)
 
 See also: [Autocomplete for Source Code](#autocomplete-for-source-code)
 
@@ -122,6 +118,5 @@ tool for building Bazel targets when source files change.
 
 ## Building your own IDE plugin {#build-own-plugin}
 
-Read the [**IDE support** blog
-post](https://blog.bazel.build/2016/06/10/ide-support.html) to learn more about
+Read the [**IDE support** blog post](https://blog.bazel.build/2016/06/10/ide-support.html) to learn more about
 the Bazel APIs to use when building an IDE plugin.
diff --git a/versions/9.0.0/install/images/bazelisk.svg b/versions/9.0.0/install/images/bazelisk.svg
new file mode 100644
index 00000000..c0ae9f54
--- /dev/null
+++ b/versions/9.0.0/install/images/bazelisk.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/9.0.0/install/images/cli.svg b/versions/9.0.0/install/images/cli.svg
new file mode 100644
index 00000000..01119280
--- /dev/null
+++ b/versions/9.0.0/install/images/cli.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/9.0.0/install/images/docker.svg b/versions/9.0.0/install/images/docker.svg
new file mode 100644
index 00000000..21190ce0
--- /dev/null
+++ b/versions/9.0.0/install/images/docker.svg
@@ -0,0 +1,6 @@
+
\ No newline at end of file
diff --git a/versions/9.0.0/install/images/github.svg b/versions/9.0.0/install/images/github.svg
new file mode 100644
index 00000000..aa05db9c
--- /dev/null
+++ b/versions/9.0.0/install/images/github.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/9.0.0/install/images/install.svg b/versions/9.0.0/install/images/install.svg
new file mode 100644
index 00000000..ae080865
--- /dev/null
+++ b/versions/9.0.0/install/images/install.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/9.0.0/install/images/mac.svg b/versions/9.0.0/install/images/mac.svg
new file mode 100644
index 00000000..3ee4fe28
--- /dev/null
+++ b/versions/9.0.0/install/images/mac.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/9.0.0/install/images/redhat.svg b/versions/9.0.0/install/images/redhat.svg
new file mode 100644
index 00000000..078b3387
--- /dev/null
+++ b/versions/9.0.0/install/images/redhat.svg
@@ -0,0 +1,69 @@
+
+
+  
+    
+      
+        image/svg+xml
+        
+        
+      
+    
+  
+  
+  
+    
+  
+  
+  
+
diff --git a/versions/9.0.0/install/images/suse.png b/versions/9.0.0/install/images/suse.png
new file mode 100644
index 00000000..6435b689
Binary files /dev/null and b/versions/9.0.0/install/images/suse.png differ
diff --git a/versions/9.0.0/install/images/tune.svg b/versions/9.0.0/install/images/tune.svg
new file mode 100644
index 00000000..8d7d63cb
--- /dev/null
+++ b/versions/9.0.0/install/images/tune.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versions/9.0.0/install/images/ubuntu.svg b/versions/9.0.0/install/images/ubuntu.svg
new file mode 100644
index 00000000..f217bc8d
--- /dev/null
+++ b/versions/9.0.0/install/images/ubuntu.svg
@@ -0,0 +1,8 @@
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/versions/9.0.0/install/images/windows.svg b/versions/9.0.0/install/images/windows.svg
new file mode 100644
index 00000000..120b0190
--- /dev/null
+++ b/versions/9.0.0/install/images/windows.svg
@@ -0,0 +1,5 @@
+
+
+
+
+
\ No newline at end of file
diff --git a/versions/9.0.0/install/windows.mdx b/versions/9.0.0/install/windows.mdx
index d82f8572..2d111eee 100644
--- a/versions/9.0.0/install/windows.mdx
+++ b/versions/9.0.0/install/windows.mdx
@@ -31,8 +31,7 @@ To check your Windows version:
 
 Alternatively you can:
 
-*   [Download the Bazel binary (`bazel-version-windows-x86_64.exe`) from
- GitHub](https://github.com/bazelbuild/bazel/releases).
+*   [Download the Bazel binary (`bazel-version-windows-x86_64.exe`) from GitHub](https://github.com/bazelbuild/bazel/releases).
 *   [Install Bazel from Chocolatey](#chocolately)
 *   [Install Bazel from Scoop](#scoop)
 *   [Build Bazel from source](/versions/9.0.0/install/compile-source)
@@ -208,8 +207,7 @@ If that doesn't help:
     its dependencies, such as the MSYS2 shell. This will not install Visual C++
     though.
 
-See [Chocolatey installation and package maintenance
-guide](/versions/9.0.0/contribute/windows-chocolatey-maintenance) for more
+See [Chocolatey installation and package maintenance guide](/versions/9.0.0/contribute/windows-chocolatey-maintenance) for more
 information about the Chocolatey package.
 
 ### Using Scoop {#scoop}
@@ -226,8 +224,7 @@ information about the Chocolatey package.
     scoop install bazel
     ```
 
-See [Scoop installation and package maintenance
-guide](/versions/9.0.0/contribute/windows-scoop-maintenance) for more
+See [Scoop installation and package maintenance guide](/versions/9.0.0/contribute/windows-scoop-maintenance) for more
 information about the Scoop package.
 
 ### Build from source {#build-from-source}
diff --git a/versions/9.0.0/migrate/maven.mdx b/versions/9.0.0/migrate/maven.mdx
index aa856ebd..53d05787 100644
--- a/versions/9.0.0/migrate/maven.mdx
+++ b/versions/9.0.0/migrate/maven.mdx
@@ -19,8 +19,7 @@ directly run by Bazel since there's no Maven compatibility layer.
 ## Before you begin {#before-you-begin}
 
 *   [Install Bazel](/versions/9.0.0/install) if it's not yet installed.
-*   If you're new to Bazel, go through the tutorial [Introduction to Bazel:
-    Build Java](/versions/9.0.0/start/java) before you start migrating. The tutorial explains
+*   If you're new to Bazel, go through the tutorial [Introduction to Bazel: Build Java](/versions/9.0.0/start/java) before you start migrating. The tutorial explains
     Bazel's concepts, structure, and label syntax.
 
 ## Differences between Maven and Bazel {#dif-maven-bazel}
@@ -44,8 +43,7 @@ The steps below describe how to migrate your project to Bazel:
 3.  [Create more BUILD files](#3-build)
 4.  [Build using Bazel](#4-build)
 
-Examples below come from a migration of the [Guava
-project](https://github.com/google/guava) from Maven to Bazel. The
+Examples below come from a migration of the [Guava project](https://github.com/google/guava) from Maven to Bazel. The
 Guava project used is release `v31.1`. The examples using Guava do not walk
 through each step in the migration, but they do show the files and contents that
 are generated or added manually for the migration.
@@ -63,14 +61,12 @@ has no external dependencies, this file can be empty.
 If your project depends on files or packages that are not in one of the
 project's directories, specify these external dependencies in the MODULE.bazel
 file. You can use `rules_jvm_external` to manage dependencies from Maven. For
-instructions about using this ruleset, see [the
-README](https://github.com/bazelbuild/rules_jvm_external/#rules_jvm_external)
+instructions about using this ruleset, see [the README](https://github.com/bazelbuild/rules_jvm_external/#rules_jvm_external)
 .
 
 #### Guava project example: external dependencies {#guava-1}
 
-You can list the external dependencies of the [Guava
-project](https://github.com/google/guava) with the
+You can list the external dependencies of the [Guava project](https://github.com/google/guava) with the
 [`rules_jvm_external`](https://github.com/bazelbuild/rules_jvm_external)
 ruleset.
 
@@ -164,8 +160,7 @@ your build by adding more `BUILD` files with more granular targets.
             *   `resources`: Use globbing to list all resources in your project.
             *   `deps`: You need to determine which external dependencies your
                 project needs.
-        *   Take a look at the [example below of this top-level BUILD
-            file](#guava-2) from the migration of the Guava project.
+        *   Take a look at the [example below of this top-level BUILD file](#guava-2) from the migration of the Guava project.
 
 3.  Now that you have a `BUILD` file at the root of your project, build your
     project to ensure that it works. On the command line, from your workspace
diff --git a/versions/9.0.0/migrate/xcode.mdx b/versions/9.0.0/migrate/xcode.mdx
index f5889ec4..53f514b1 100644
--- a/versions/9.0.0/migrate/xcode.mdx
+++ b/versions/9.0.0/migrate/xcode.mdx
@@ -32,8 +32,7 @@ Before you begin, do the following:
 
 1.  [Install Bazel](/versions/9.0.0/install) if you have not already done so.
 
-2.  If you're not familiar with Bazel and its concepts, complete the [iOS app
-    tutorial](/versions/9.0.0/start/ios-app)). You should understand the Bazel workspace,
+2.  If you're not familiar with Bazel and its concepts, complete the [iOS app tutorial](/versions/9.0.0/start/ios-app)). You should understand the Bazel workspace,
     including the `MODULE.bazel` and `BUILD` files, as well as the concepts of
     targets, build rules, and Bazel packages.
 
@@ -44,8 +43,7 @@ Before you begin, do the following:
 Unlike Xcode, Bazel requires you to explicitly declare all dependencies for
 every target in the `BUILD` file.
 
-For more information on external dependencies, see [Working with external
-dependencies](/versions/9.0.0/docs/external).
+For more information on external dependencies, see [Working with external dependencies](/versions/9.0.0/docs/external).
 
 ## Build or test an Xcode project with Bazel {#build-xcode-project}
 
@@ -84,8 +82,7 @@ Note: Place the project source code within the directory tree containing the
 
 To integrate SwiftPM dependencies into the Bazel workspace with
 [swift_bazel](https://github.com/cgrindel/swift_bazel), you must
-convert them into Bazel packages as described in the [following
-tutorial](https://chuckgrindel.com/swift-packages-in-bazel-using-swift_bazel/)
+convert them into Bazel packages as described in the [following tutorial](https://chuckgrindel.com/swift-packages-in-bazel-using-swift_bazel/)
 .
 
 Note: SwiftPM support is a manual process with many variables. SwiftPM
@@ -103,8 +100,7 @@ initial build of the project as follows:
 *   [Step 3b: (Optional) Add the test target(s)](#step-3b-optional-add-the-test-target-s)
 *   [Step 3c: Add the library target(s)](#step-3c-add-the-library-target-s)
 
-**Tip:** To learn more about packages and other Bazel concepts, see [Workspaces,
-packages, and targets](/versions/9.0.0/concepts/build-ref).
+**Tip:** To learn more about packages and other Bazel concepts, see [Workspaces, packages, and targets](/versions/9.0.0/concepts/build-ref).
 
 #### Step 3a: Add the application target {#add-app-target}
 
@@ -132,8 +128,7 @@ In the target, specify the following at the minimum:
 
 #### Step 3b: (Optional) Add the test target(s) {#add-test-target}
 
-Bazel's [Apple build
-rules](https://github.com/bazelbuild/rules_apple) support running
+Bazel's [Apple build rules](https://github.com/bazelbuild/rules_apple) support running
 unit and UI tests on all Apple platforms. Add test targets as follows:
 
 *   [`macos_unit_test`](https://github.com/bazelbuild/rules_apple/blob/master/doc/rules-macos.md#macos_unit_test)
@@ -181,8 +176,7 @@ all sources and/or headers of a certain type. Use it carefully as it might
 include files you do not want Bazel to build.
 
 You can browse existing examples for various types of applications directly in
-the [rules_apple examples
-directory](https://github.com/bazelbuild/rules_apple/tree/master/examples/). For
+the [rules_apple examples directory](https://github.com/bazelbuild/rules_apple/tree/master/examples/). For
 example:
 
 *   [macOS application targets](https://github.com/bazelbuild/rules_apple/tree/master/examples/macos)
@@ -191,8 +185,7 @@ example:
 
 *   [Multi platform applications (macOS, iOS, watchOS, tvOS)](https://github.com/bazelbuild/rules_apple/tree/master/examples/multi_platform)
 
-For more information on build rules, see [Apple Rules for
-Bazel](https://github.com/bazelbuild/rules_apple).
+For more information on build rules, see [Apple Rules for Bazel](https://github.com/bazelbuild/rules_apple).
 
 At this point, it is a good idea to test the build:
 
diff --git a/versions/9.0.0/query/cquery.mdx b/versions/9.0.0/query/cquery.mdx
index 6a9bf682..ba8d4c37 100644
--- a/versions/9.0.0/query/cquery.mdx
+++ b/versions/9.0.0/query/cquery.mdx
@@ -6,8 +6,7 @@ title: 'Configurable Query (cquery)'
 [`select()`](/versions/9.0.0/docs/configurable-attributes) and build options' effects on the
 build graph.
 
-It achieves this by running over the results of Bazel's [analysis
-phase](/versions/9.0.0/extending/concepts#evaluation-model),
+It achieves this by running over the results of Bazel's [analysis phase](/versions/9.0.0/extending/concepts#evaluation-model),
 which integrates these effects. `query`, by contrast, runs over the results of
 Bazel's loading phase, before options are evaluated.
 
@@ -137,8 +136,7 @@ $ bazel cquery //foo --universe_scope=//foo,//genrule_with_foo_as_tool
 If you want to precisely declare which instance to query over, use
 the [`config`](#config) function.
 
-See `query`'s [target pattern
-documentation](/versions/9.0.0/query/language#target-patterns) for more information on target
+See `query`'s [target pattern documentation](/versions/9.0.0/query/language#target-patterns) for more information on target
 patterns.
 
 ## Functions {#functions}
@@ -539,8 +537,7 @@ different niches. Consider the following to decide which is right for you:
 It's therefore prone to picking up results from past queries.
 
 For example, `genrule` exerts an exec transition on its `tools` attribute -
-that is, it configures its tools in the [exec configuration]
-(https://bazel.build/rules/rules#configurations).
+that is, it configures its tools in the [exec configuration](https://bazel.build/versions/9.0.0/rules/rules#configurations).
 
 You can see the lingering effects of that transition below.
 
diff --git a/versions/9.0.0/query/images/query_graph1.png b/versions/9.0.0/query/images/query_graph1.png
new file mode 100644
index 00000000..7bc9a61a
Binary files /dev/null and b/versions/9.0.0/query/images/query_graph1.png differ
diff --git a/versions/9.0.0/query/images/query_graph2.png b/versions/9.0.0/query/images/query_graph2.png
new file mode 100644
index 00000000..a0da22ff
Binary files /dev/null and b/versions/9.0.0/query/images/query_graph2.png differ
diff --git a/versions/9.0.0/query/images/query_graph3.png b/versions/9.0.0/query/images/query_graph3.png
new file mode 100644
index 00000000..4418f193
Binary files /dev/null and b/versions/9.0.0/query/images/query_graph3.png differ
diff --git a/versions/9.0.0/query/language.mdx b/versions/9.0.0/query/language.mdx
index 68c55b0a..8dcb1c01 100644
--- a/versions/9.0.0/query/language.mdx
+++ b/versions/9.0.0/query/language.mdx
@@ -1129,8 +1129,7 @@ is being used.
 
 ### On the ordering of results {#results-ordering}
 
-Although query expressions always follow the "[law of
-conservation of graph order](#graph-order)", _presenting_ the results may be done
+Although query expressions always follow the "[law of conservation of graph order](#graph-order)", _presenting_ the results may be done
 in either a dependency-ordered or unordered manner. This does **not**
 influence the targets in the result set or how the query is computed. It only
 affects how the results are printed to stdout. Moreover, nodes that are
@@ -1276,8 +1275,7 @@ and `maxrank` output formats print the labels of each
 target in the resulting graph, but instead of appearing in
 topological order, they appear in rank order, preceded by their
 rank number. These are unaffected by the result ordering
-`--[no]order_results` flag (see [notes on
-the ordering of results](#result-order)).
+`--[no]order_results` flag (see [notes on the ordering of results](#result-order)).
 
 There are two variants of this format: `minrank` ranks
 each node by the length of the shortest path from a root node to it.
diff --git a/versions/9.0.0/query/quickstart.mdx b/versions/9.0.0/query/quickstart.mdx
index 9ec987d2..b2ced14a 100644
--- a/versions/9.0.0/query/quickstart.mdx
+++ b/versions/9.0.0/query/quickstart.mdx
@@ -205,7 +205,7 @@ dot -Tpng < graph.in > graph.png
 ```
 If you open up `graph.png`, you should see something like this. The graph below has been simplified to make the essential path details clearer in this guide.
 
-![Diagram showing a relationship from cafe to chef to the dishes: pizza and mac and cheese which diverges into the separate ingredients: cheese, tomatoes, dough, and macaroni.](images/query_graph1.png "Dependency graph")
+![Diagram showing a relationship from cafe to chef to the dishes: pizza and mac and cheese which diverges into the separate ingredients: cheese, tomatoes, dough, and macaroni.](/versions/9.0.0/query/images/query_graph1.png "Dependency graph")
 
 This helps when you want to see the outputs of the different query functions throughout this guide.
 
@@ -421,7 +421,7 @@ bazel query --noimplicit_deps 'deps(:runner)' --output graph > graph2.in
 dot -Tpng < graph2.in > graph2.png
 ```
 
-[![The same graph as the first one except now there is a spoke stemming from the chef target with smoothie which leads to banana and strawberry](images/query_graph2.png "Updated dependency graph")](images/query_graph2.png)
+[![The same graph as the first one except now there is a spoke stemming from the chef target with smoothie which leads to banana and strawberry](/versions/9.0.0/query/images/query_graph2.png "Updated dependency graph")](/query/images/query_graph2.png)
 
 Looking at `graph2.png`, you can see that `Smoothie` has no shared dependencies with other dishes but is just another target that the `Chef` relies on.
 
@@ -465,7 +465,7 @@ bazel query "allpaths(//src/main/java/com/example/restaurant/..., //src/main/jav
 //src/main/java/com/example/restaurant:chef
 ```
 
-![Output path of cafe to chef to pizza,mac and cheese to cheese](images/query_graph3.png "Output path for dependency")
+![Output path of cafe to chef to pizza,mac and cheese to cheese](/versions/9.0.0/query/images/query_graph3.png "Output path for dependency")
 
 The output of `allpaths()` is a little harder to read as it is a flattened list of the dependencies. Visualizing this graph using Graphviz makes the relationship clearer to understand.
 
diff --git a/versions/9.0.0/reference/be/c-cpp.mdx b/versions/9.0.0/reference/be/c-cpp.mdx
index 324e97e8..a24c58e9 100644
--- a/versions/9.0.0/reference/be/c-cpp.mdx
+++ b/versions/9.0.0/reference/be/c-cpp.mdx
@@ -60,7 +60,7 @@ be `main`.
 | `hdrs_check` | String; default is `""` Deprecated, no-op. |
 | `includes` | List of strings; default is `[]` List of include dirs to be added to the compile line. Subject to ["Make variable"](/versions/9.0.0/reference/be/make-variables) substitution. Each string is prepended with the package path and passed to the C++ toolchain for expansion via the "include\_paths" CROSSTOOL feature. A toolchain running on a POSIX system with typical feature definitions will produce `-isystem path_to_package/include_entry`. This should only be used for third-party libraries that do not conform to the Google style of writing #include statements. Unlike [COPTS](#cc_binary.copts), these flags are added for this rule and every rule that depends on it. (Note: not the rules it depends upon!) Be very careful, since this may have far-reaching effects. When in doubt, add "-I" flags to [COPTS](#cc_binary.copts) instead. The added `include` paths will include generated files as well as files in the source tree. |
 | `link_extra_lib` | [Label](/versions/9.0.0/concepts/labels); default is `"@bazel_tools//tools/cpp:link_extra_lib"` Control linking of extra libraries. By default, C++ binaries are linked against `//tools/cpp:link_extra_lib`, which by default depends on the label flag `//tools/cpp:link_extra_libs`. Without setting the flag, this library is empty by default. Setting the label flag allows linking optional dependencies, such as overrides for weak symbols, interceptors for shared library functions, or special runtime libraries (for malloc replacements, prefer `malloc` or `--custom_malloc`). Setting this attribute to `None` disables this behaviour. |
-| `linkopts` | List of strings; default is `[]` Add these flags to the C++ linker command. Subject to ["Make" variable](make-variables) substitution, [Bourne shell tokenization](common-definitions#sh-tokenization) and [label expansion](common-definitions#label-expansion). Each string in this attribute is added to `LINKOPTS` before linking the binary target. Each element of this list that does not start with `$` or `-` is assumed to be the label of a target in `deps`. The list of files generated by that target is appended to the linker options. An error is reported if the label is invalid, or is not declared in `deps`. |
+| `linkopts` | List of strings; default is `[]` Add these flags to the C++ linker command. Subject to ["Make" variable](/versions/9.0.0/reference/be/make-variables) substitution, [Bourne shell tokenization](/versions/9.0.0/reference/be/common-definitions#sh-tokenization) and [label expansion](/versions/9.0.0/reference/be/common-definitions#label-expansion). Each string in this attribute is added to `LINKOPTS` before linking the binary target. Each element of this list that does not start with `$` or `-` is assumed to be the label of a target in `deps`. The list of files generated by that target is appended to the linker options. An error is reported if the label is invalid, or is not declared in `deps`. |
 | `linkshared` | Boolean; default is `False` Create a shared library. To enable this attribute, include `linkshared=True` in your rule. By default this option is off. The presence of this flag means that linking occurs with the `-shared` flag to `gcc`, and the resulting shared library is suitable for loading into for example a Java program. However, for build purposes it will never be linked into the dependent binary, as it is assumed that shared libraries built with a [cc\_binary](#cc_binary) rule are only loaded manually by other programs, so it should not be considered a substitute for the [cc\_library](#cc_library) rule. For sake of scalability we recommend avoiding this approach altogether and simply letting `java_library` depend on `cc_library` rules instead.  If you specify both `linkopts=['-static']` and `linkshared=True`, you get a single completely self-contained unit. If you specify both `linkstatic=True` and `linkshared=True`, you get a single, mostly self-contained unit. |
 | `linkstatic` | Boolean; default is `True` For [`cc_binary`](/versions/9.0.0/reference/be/c-cpp#cc_binary) and [`cc_test`](/versions/9.0.0/reference/be/c-cpp#cc_test): link the binary in static mode. For `cc_library.link_static`: see below. By default this option is on for `cc_binary` and off for the rest.  If enabled and this is a binary or test, this option tells the build tool to link in `.a`'s instead of `.so`'s for user libraries whenever possible. System libraries such as libc (but *not* the C/C++ runtime libraries, see below) are still linked dynamically, as are libraries for which there is no static library. So the resulting executable will still be dynamically linked, hence only *mostly* static.  There are really three different ways to link an executable:   * STATIC with fully\_static\_link feature, in which everything is linked statically;   e.g. "`gcc -static foo.o libbar.a libbaz.a -lm`".    This mode is enabled by specifying `fully_static_link` in the   [`features`](/versions/9.0.0/reference/be/common-definitions#features) attribute. * STATIC, in which all user libraries are linked statically (if a static   version is available), but where system libraries (excluding C/C++ runtime libraries)   are linked dynamically, e.g. "`gcc foo.o libfoo.a libbaz.a -lm`".    This mode is enabled by specifying `linkstatic=True`. * DYNAMIC, in which all libraries are linked dynamically (if a dynamic version is   available), e.g. "`gcc foo.o libfoo.so libbaz.so -lm`".    This mode is enabled by specifying `linkstatic=False`.   If the `linkstatic` attribute or `fully_static_link` in `features` is used outside of `//third_party` please include a comment near the rule to explain why.  The `linkstatic` attribute has a different meaning if used on a [`cc_library()`](/versions/9.0.0/reference/be/c-cpp#cc_library) rule. For a C++ library, `linkstatic=True` indicates that only static linking is allowed, so no `.so` will be produced. linkstatic=False does not prevent static libraries from being created. The attribute is meant to control the creation of dynamic libraries.  There should be very little code built with `linkstatic=False` in production. If `linkstatic=False`, then the build tool will create symlinks to depended-upon shared libraries in the `*.runfiles` area. |
 | `local_defines` | List of strings; default is `[]` List of defines to add to the compile line. Subject to ["Make" variable](/versions/9.0.0/reference/be/make-variables) substitution and [Bourne shell tokenization](/versions/9.0.0/reference/be/common-definitions#sh-tokenization). Each string, which must consist of a single Bourne shell token, is prepended with `-D` and added to the compile command line for this target, but not to its dependents. |
@@ -228,7 +228,7 @@ cc_import(
 | `alwayslink` | Boolean; default is `False` If 1, any binary that depends (directly or indirectly) on this C++ precompiled library will link in all the object files archived in the static library, even if some contain no symbols referenced by the binary. This is useful if your code isn't explicitly called by code in the binary, e.g., if your code registers to receive some callback provided by some service. If alwayslink doesn't work with VS 2017 on Windows, that is due to a [known issue](https://github.com/bazelbuild/bazel/issues/3949), please upgrade your VS 2017 to the latest version. |
 | `includes` | List of strings; default is `[]` List of include dirs to be added to the compile line. Subject to ["Make variable"](/versions/9.0.0/reference/be/make-variables) substitution. Each string is prepended with the package path and passed to the C++ toolchain for expansion via the "include\_paths" CROSSTOOL feature. A toolchain running on a POSIX system with typical feature definitions will produce `-isystem path_to_package/include_entry`. This should only be used for third-party libraries that do not conform to the Google style of writing #include statements. Unlike [COPTS](#cc_binary.copts), these flags are added for this rule and every rule that depends on it. (Note: not the rules it depends upon!) Be very careful, since this may have far-reaching effects. When in doubt, add "-I" flags to [COPTS](#cc_binary.copts) instead. The default `include` path doesn't include generated files. If you need to `#include` a generated header file, list it in the `srcs`. |
 | `interface_library` | [Label](/versions/9.0.0/concepts/labels); default is `None` A single interface library for linking the shared library. Permitted file types: `.ifso`, `.tbd`, `.lib`, `.so` or `.dylib` |
-| `linkopts` | List of strings; default is `[]` Add these flags to the C++ linker command. Subject to ["Make" variable](make-variables) substitution, [Bourne shell tokenization](common-definitions#sh-tokenization) and [label expansion](common-definitions#label-expansion). Each string in this attribute is added to `LINKOPTS` before linking the binary target. Each element of this list that does not start with `$` or `-` is assumed to be the label of a target in `deps`. The list of files generated by that target is appended to the linker options. An error is reported if the label is invalid, or is not declared in `deps`. |
+| `linkopts` | List of strings; default is `[]` Add these flags to the C++ linker command. Subject to ["Make" variable](/versions/9.0.0/reference/be/make-variables) substitution, [Bourne shell tokenization](/versions/9.0.0/reference/be/common-definitions#sh-tokenization) and [label expansion](/versions/9.0.0/reference/be/common-definitions#label-expansion). Each string in this attribute is added to `LINKOPTS` before linking the binary target. Each element of this list that does not start with `$` or `-` is assumed to be the label of a target in `deps`. The list of files generated by that target is appended to the linker options. An error is reported if the label is invalid, or is not declared in `deps`. |
 | `objects` | List of [labels](/versions/9.0.0/concepts/labels); default is `[]` |
 | `pic_objects` | List of [labels](/versions/9.0.0/concepts/labels); default is `[]` |
 | `pic_static_library` | [Label](/versions/9.0.0/concepts/labels); default is `None` |
@@ -453,7 +453,7 @@ cc_library(
 | `implementation_deps` | List of [labels](/versions/9.0.0/concepts/labels); default is `[]` The list of other libraries that the library target depends on. Unlike with `deps`, the headers and include paths of these libraries (and all their transitive deps) are only used for compilation of this library, and not libraries that depend on it. Libraries specified with `implementation_deps` are still linked in binary targets that depend on this library. |
 | `include_prefix` | String; default is `""` The prefix to add to the paths of the headers of this rule. When set, the headers in the `hdrs` attribute of this rule are accessible at is the value of this attribute prepended to their repository-relative path. The prefix in the `strip_include_prefix` attribute is removed before this prefix is added. This attribute is only legal under `third_party`. |
 | `includes` | List of strings; default is `[]` List of include dirs to be added to the compile line. Subject to ["Make variable"](/versions/9.0.0/reference/be/make-variables) substitution. Each string is prepended with the package path and passed to the C++ toolchain for expansion via the "include\_paths" CROSSTOOL feature. A toolchain running on a POSIX system with typical feature definitions will produce `-isystem path_to_package/include_entry`. This should only be used for third-party libraries that do not conform to the Google style of writing #include statements. Unlike [COPTS](#cc_binary.copts), these flags are added for this rule and every rule that depends on it. (Note: not the rules it depends upon!) Be very careful, since this may have far-reaching effects. When in doubt, add "-I" flags to [COPTS](#cc_binary.copts) instead. The added `include` paths will include generated files as well as files in the source tree. |
-| `linkopts` | List of strings; default is `[]` See [`cc_binary.linkopts`](/versions/9.0.0/reference/be/c-cpp#cc_binary.linkopts). The `linkopts` attribute is also applied to any target that depends, directly or indirectly, on this library via `deps` attributes (or via other attributes that are treated similarly: the [`malloc`](/versions/9.0.0/reference/be/c-cpp#cc_binary.malloc) attribute of [`cc_binary`](/versions/9.0.0/reference/be/c-cpp#cc_binary)). Dependency linkopts take precedence over dependent linkopts (i.e. dependency linkopts appear later in the command line). Linkopts specified in [`--linkopt`](../user-manual#flag--linkopt) take precedence over rule linkopts. |
+| `linkopts` | List of strings; default is `[]` See [`cc_binary.linkopts`](/versions/9.0.0/reference/be/c-cpp#cc_binary.linkopts). The `linkopts` attribute is also applied to any target that depends, directly or indirectly, on this library via `deps` attributes (or via other attributes that are treated similarly: the [`malloc`](/versions/9.0.0/reference/be/c-cpp#cc_binary.malloc) attribute of [`cc_binary`](/versions/9.0.0/reference/be/c-cpp#cc_binary)). Dependency linkopts take precedence over dependent linkopts (i.e. dependency linkopts appear later in the command line). Linkopts specified in [`--linkopt`](/versions/9.0.0/reference/user-manual#flag--linkopt) take precedence over rule linkopts. |
 
 Note that the `linkopts` attribute only applies
 when creating `.so` files or executables, not
@@ -736,7 +736,7 @@ that `cc_test` has extra [attributes common to all test rules (\*\_test)](/versi
 | `hdrs_check` | String; default is `""` Deprecated, no-op. |
 | `includes` | List of strings; default is `[]` List of include dirs to be added to the compile line. Subject to ["Make variable"](/versions/9.0.0/reference/be/make-variables) substitution. Each string is prepended with the package path and passed to the C++ toolchain for expansion via the "include\_paths" CROSSTOOL feature. A toolchain running on a POSIX system with typical feature definitions will produce `-isystem path_to_package/include_entry`. This should only be used for third-party libraries that do not conform to the Google style of writing #include statements. Unlike [COPTS](#cc_binary.copts), these flags are added for this rule and every rule that depends on it. (Note: not the rules it depends upon!) Be very careful, since this may have far-reaching effects. When in doubt, add "-I" flags to [COPTS](#cc_binary.copts) instead. The added `include` paths will include generated files as well as files in the source tree. |
 | `link_extra_lib` | [Label](/versions/9.0.0/concepts/labels); default is `"@bazel_tools//tools/cpp:link_extra_lib"` Control linking of extra libraries. By default, C++ binaries are linked against `//tools/cpp:link_extra_lib`, which by default depends on the label flag `//tools/cpp:link_extra_libs`. Without setting the flag, this library is empty by default. Setting the label flag allows linking optional dependencies, such as overrides for weak symbols, interceptors for shared library functions, or special runtime libraries (for malloc replacements, prefer `malloc` or `--custom_malloc`). Setting this attribute to `None` disables this behaviour. |
-| `linkopts` | List of strings; default is `[]` Add these flags to the C++ linker command. Subject to ["Make" variable](make-variables) substitution, [Bourne shell tokenization](common-definitions#sh-tokenization) and [label expansion](common-definitions#label-expansion). Each string in this attribute is added to `LINKOPTS` before linking the binary target. Each element of this list that does not start with `$` or `-` is assumed to be the label of a target in `deps`. The list of files generated by that target is appended to the linker options. An error is reported if the label is invalid, or is not declared in `deps`. |
+| `linkopts` | List of strings; default is `[]` Add these flags to the C++ linker command. Subject to ["Make" variable](/versions/9.0.0/reference/be/make-variables) substitution, [Bourne shell tokenization](/versions/9.0.0/reference/be/common-definitions#sh-tokenization) and [label expansion](/versions/9.0.0/reference/be/common-definitions#label-expansion). Each string in this attribute is added to `LINKOPTS` before linking the binary target. Each element of this list that does not start with `$` or `-` is assumed to be the label of a target in `deps`. The list of files generated by that target is appended to the linker options. An error is reported if the label is invalid, or is not declared in `deps`. |
 | `linkshared` | Boolean; default is `False` Create a shared library. To enable this attribute, include `linkshared=True` in your rule. By default this option is off. The presence of this flag means that linking occurs with the `-shared` flag to `gcc`, and the resulting shared library is suitable for loading into for example a Java program. However, for build purposes it will never be linked into the dependent binary, as it is assumed that shared libraries built with a [cc\_binary](#cc_binary) rule are only loaded manually by other programs, so it should not be considered a substitute for the [cc\_library](#cc_library) rule. For sake of scalability we recommend avoiding this approach altogether and simply letting `java_library` depend on `cc_library` rules instead.  If you specify both `linkopts=['-static']` and `linkshared=True`, you get a single completely self-contained unit. If you specify both `linkstatic=True` and `linkshared=True`, you get a single, mostly self-contained unit. |
 | `linkstatic` | Boolean; default is `False` For [`cc_binary`](/versions/9.0.0/reference/be/c-cpp#cc_binary) and [`cc_test`](/versions/9.0.0/reference/be/c-cpp#cc_test): link the binary in static mode. For `cc_library.link_static`: see below. By default this option is on for `cc_binary` and off for the rest.  If enabled and this is a binary or test, this option tells the build tool to link in `.a`'s instead of `.so`'s for user libraries whenever possible. System libraries such as libc (but *not* the C/C++ runtime libraries, see below) are still linked dynamically, as are libraries for which there is no static library. So the resulting executable will still be dynamically linked, hence only *mostly* static.  There are really three different ways to link an executable:   * STATIC with fully\_static\_link feature, in which everything is linked statically;   e.g. "`gcc -static foo.o libbar.a libbaz.a -lm`".    This mode is enabled by specifying `fully_static_link` in the   [`features`](/versions/9.0.0/reference/be/common-definitions#features) attribute. * STATIC, in which all user libraries are linked statically (if a static   version is available), but where system libraries (excluding C/C++ runtime libraries)   are linked dynamically, e.g. "`gcc foo.o libfoo.a libbaz.a -lm`".    This mode is enabled by specifying `linkstatic=True`. * DYNAMIC, in which all libraries are linked dynamically (if a dynamic version is   available), e.g. "`gcc foo.o libfoo.so libbaz.so -lm`".    This mode is enabled by specifying `linkstatic=False`.   If the `linkstatic` attribute or `fully_static_link` in `features` is used outside of `//third_party` please include a comment near the rule to explain why.  The `linkstatic` attribute has a different meaning if used on a [`cc_library()`](/versions/9.0.0/reference/be/c-cpp#cc_library) rule. For a C++ library, `linkstatic=True` indicates that only static linking is allowed, so no `.so` will be produced. linkstatic=False does not prevent static libraries from being created. The attribute is meant to control the creation of dynamic libraries.  There should be very little code built with `linkstatic=False` in production. If `linkstatic=False`, then the build tool will create symlinks to depended-upon shared libraries in the `*.runfiles` area. |
 | `local_defines` | List of strings; default is `[]` List of defines to add to the compile line. Subject to ["Make" variable](/versions/9.0.0/reference/be/make-variables) substitution and [Bourne shell tokenization](/versions/9.0.0/reference/be/common-definitions#sh-tokenization). Each string, which must consist of a single Bourne shell token, is prepended with `-D` and added to the compile command line for this target, but not to its dependents. |
diff --git a/versions/9.0.0/reference/be/common-definitions.mdx b/versions/9.0.0/reference/be/common-definitions.mdx
index c1079a44..1270c505 100644
--- a/versions/9.0.0/reference/be/common-definitions.mdx
+++ b/versions/9.0.0/reference/be/common-definitions.mdx
@@ -76,12 +76,12 @@ rules.
 | `deprecation` | String; [nonconfigurable](#configurable-attributes); default is `None`  An explanatory warning message associated with this target. Typically this is used to notify users that a target has become obsolete, or has become superseded by another rule, is private to a package, or is perhaps considered harmful for some reason. It is a good idea to include some reference (like a webpage, a bug number or example migration CLs) so that one can easily find out what changes are required to avoid the message. If there is a new target that can be used as a drop in replacement, it is a good idea to just migrate all users of the old target.  This attribute has no effect on the way things are built, but it may affect a build tool's diagnostic output. The build tool issues a warning when a rule with a `deprecation` attribute is depended upon by a target in another package.  Intra-package dependencies are exempt from this warning, so that, for example, building the tests of a deprecated rule does not encounter a warning.  If a deprecated target depends on another deprecated target, no warning message is issued.  Once people have stopped using it, the target can be removed. |
 | `exec_compatible_with` | List of [labels](/versions/9.0.0/concepts/labels); [nonconfigurable](#configurable-attributes); default is `[]`  A list of `constraint_values` that must be present in the execution platform of this target's default exec group. This is in addition to any constraints already set by the rule type. Constraints are used to restrict the list of available execution platforms. For more details, see the description of [toolchain resolution](/versions/9.0.0/docs/toolchains#toolchain-resolution). and [exec groups](/versions/9.0.0/extending/exec-groups) |
 | `exec_group_compatible_with` | Dictionary of strings to lists of [labels](/versions/9.0.0/concepts/labels); [nonconfigurable](#configurable-attributes); default is `{}`  A dictionary of exec group names to lists of `constraint_values` that must be present in the execution platform for the given exec group. This is in addition to any constraints already set on the exec group's definition. Constraints are used to restrict the list of available execution platforms. For more details, see the description of [toolchain resolution](/versions/9.0.0/docs/toolchains#toolchain-resolution). and [exec groups](/versions/9.0.0/extending/exec-groups) |
-| `exec_properties` | Dictionary of strings; default is `{}`  A dictionary of strings that will be added to the `exec_properties` of a platform selected for this target. See `exec_properties` of the [platform](platforms-and-toolchains#platform) rule.  If a key is present in both the platform and target-level properties, the value will be taken from the target.  Keys can be prefixed with the name of an execution group followed by a `.` to apply them only to that particular exec group. |
+| `exec_properties` | Dictionary of strings; default is `{}`  A dictionary of strings that will be added to the `exec_properties` of a platform selected for this target. See `exec_properties` of the [platform](/versions/9.0.0/reference/be/platforms-and-toolchains#platform) rule.  If a key is present in both the platform and target-level properties, the value will be taken from the target.  Keys can be prefixed with the name of an execution group followed by a `.` to apply them only to that particular exec group. |
 | `features` | List of *feature* strings; default is `[]`  A feature is string tag that can be enabled or disabled on a target. The meaning of a feature depends on the rule itself.  This `features` attribute is combined with the [package](/versions/9.0.0/reference/be/functions#package) level `features` attribute. For example, if the features ["a", "b"] are enabled on the package level, and a target's `features` attribute contains ["-a", "c"], the features enabled for the rule will be "b" and "c". [See example](https://github.com/bazelbuild/examples/blob/main/rules/features/BUILD). |
 | `package_metadata` | List of [labels](/versions/9.0.0/concepts/labels); [nonconfigurable](#configurable-attributes); default is the package's `default_package_metadata`  A list of labels that are associated metadata about this target. Typically, the labels are simple rules that return a provider of constant values. Rules and aspects may use these labels to perform some additional analysis on the build graph.  The canonical use case is that of [rules\_license](https://github.com/bazelbuild/rules_license). For that use case, `package_metadata` and `default_package_metadata` is used to attach information about a package's licence or version to targets. An aspect applied to a top-level binary can be used to gather those and produce compliance reports. |
 | `restricted_to` | List of [labels](/versions/9.0.0/concepts/labels); [nonconfigurable](#configurable-attributes); default is `[]`  The list of environments this target can be built for, *instead* of default-supported environments.  This is part of Bazel's constraint system. See `compatible_with` for details. |
 | `tags` | List of strings; [nonconfigurable](#configurable-attributes); default is `[]`  *Tags* can be used on any rule. *Tags* on test and `test_suite` rules are useful for categorizing the tests. *Tags* on non-test targets are used to control sandboxed execution of `genrule`s and [Starlark](/versions/9.0.0/rules/concepts) actions, and for parsing by humans and/or external tools.  Bazel modifies the behavior of its sandboxing code if it finds the following keywords in the `tags` attribute of any test or `genrule` target, or the keys of `execution_requirements` for any Starlark action.   * `no-sandbox` keyword results in the action or test never being   sandboxed; it can still be cached or run remotely - use `no-cache`   or `no-remote` to prevent either or both of those. * `no-cache` keyword results in the action or test never being   cached (locally or remotely). Note: for the purposes of this tag, the disk cache   is considered a local cache, whereas the HTTP and gRPC caches are considered   remote. Other caches, such as Skyframe or the persistent action cache, are not   affected. * `no-remote-cache` keyword results in the action or test never being   cached remotely (but it may be cached locally; it may also be executed remotely).   Note: for the purposes of this tag, the disk cache is considered a local cache,   whereas the HTTP and gRPC caches are considered remote. Other caches, such as   Skyframe or the persistent action cache, are not affected.   If a combination of local disk cache and remote cache are used (combined cache),   it's treated as a remote cache and disabled entirely unless `--incompatible_remote_results_ignore_disk`   is set in which case the local components will be used. * `no-remote-exec` keyword results in the action or test never being   executed remotely (but it may be cached remotely). * `no-remote` keyword prevents the action or test from being executed remotely or   cached remotely. This is equivalent to using both   `no-remote-cache` and `no-remote-exec`. * `no-remote-cache-upload` keyword disables upload part of remote caching of a spawn.   it does not disable remote execution. * `local` keyword precludes the action or test from being remotely cached,   remotely executed, or run inside the sandbox.   For genrules and tests, marking the rule with the `local = True`   attribute has the same effect. * `requires-network` keyword allows access to the external   network from inside the sandbox. This tag only has an effect if sandboxing   is enabled. * `block-network` keyword blocks access to the external   network from inside the sandbox. In this case, only communication   with localhost is allowed. This tag only has an effect if sandboxing is   enabled. * `requires-fakeroot` runs the test or action as uid and gid 0 (i.e., the root   user). This is only supported on Linux. This tag takes precedence over the   `--sandbox_fake_username` command-line option.   *Tags* on tests are generally used to annotate a test's role in your debug and release process. Typically, tags are most useful for C++ and Python tests, which lack any runtime annotation ability. The use of tags and size elements gives flexibility in assembling suites of tests based around codebase check-in policy.  Bazel modifies test running behavior if it finds the following keywords in the `tags` attribute of the test rule:   * `exclusive` will force the test to be run in the   "exclusive" mode, ensuring that no other tests are running at the   same time. Such tests will be executed in serial fashion after all build   activity and non-exclusive tests have been completed. Remote execution is   disabled for such tests because Bazel doesn't have control over what's   running on a remote machine. * `exclusive-if-local` will force the test to be run in the   "exclusive" mode if it is executed locally, but will run the test in parallel if it's   executed remotely. * `manual` keyword will exclude the target from expansion of target pattern wildcards   (`...`, `:*`, `:all`, etc.) and `test_suite` rules   which do not list the test explicitly when computing the set of top-level targets to build/run   for the `build`, `test`, and `coverage` commands. It does not   affect target wildcard or test suite expansion in other contexts, including the   `query` command. Note that `manual` does not imply that a target should   not be built/run automatically by continuous build/test systems. For example, it may be   desirable to exclude a target from `bazel test ...` because it requires specific   Bazel flags, but still have it included in properly-configured presubmit or continuous test   runs. * `external` keyword will force test to be unconditionally   executed (regardless of `--cache_test_results`   value).  See [Tag Conventions](/versions/9.0.0/reference/test-encyclopedia#tag-conventions) in the Test Encyclopedia for more conventions on tags attached to test targets. |
-| `target_compatible_with` | List of [labels](/versions/9.0.0/concepts/labels); default is `[]`  A list of `constraint_value`s that must be present in the target platform for this target to be considered *compatible*. This is in addition to any constraints already set by the rule type. If the target platform does not satisfy all listed constraints then the target is considered *incompatible*. Incompatible targets are skipped for building and testing when the target pattern is expanded (e.g. `//...`, `:all`). When explicitly specified on the command line, incompatible targets cause Bazel to print an error and cause a build or test failure.  Targets that transitively depend on incompatible targets are themselves considered incompatible. They are also skipped for building and testing.  An empty list (which is the default) signifies that the target is compatible with all platforms. All rules other than [Workspace Rules](workspace) support this attribute. For some rules this attribute has no effect. For example, specifying `target_compatible_with` for a `cc_toolchain` is not useful. See the [Platforms](/versions/9.0.0/docs/platforms#skipping-incompatible-targets) page for more information about incompatible target skipping. |
+| `target_compatible_with` | List of [labels](/versions/9.0.0/concepts/labels); default is `[]`  A list of `constraint_value`s that must be present in the target platform for this target to be considered *compatible*. This is in addition to any constraints already set by the rule type. If the target platform does not satisfy all listed constraints then the target is considered *incompatible*. Incompatible targets are skipped for building and testing when the target pattern is expanded (e.g. `//...`, `:all`). When explicitly specified on the command line, incompatible targets cause Bazel to print an error and cause a build or test failure.  Targets that transitively depend on incompatible targets are themselves considered incompatible. They are also skipped for building and testing.  An empty list (which is the default) signifies that the target is compatible with all platforms. All rules other than [Workspace Rules](/versions/9.0.0/reference/be/workspace) support this attribute. For some rules this attribute has no effect. For example, specifying `target_compatible_with` for a `cc_toolchain` is not useful. See the [Platforms](/versions/9.0.0/docs/platforms#skipping-incompatible-targets) page for more information about incompatible target skipping. |
 | `testonly` | Boolean; [nonconfigurable](#configurable-attributes); default is `False` except for test and test suite targets  If `True`, only testonly targets (such as tests) can depend on this target.  Equivalently, a rule that is not `testonly` is not allowed to depend on any rule that is `testonly`.  Tests (`*_test` rules) and test suites ([test\_suite](/versions/9.0.0/reference/be/general#test_suite) rules) are `testonly` by default.  This attribute is intended to mean that the target should not be contained in binaries that are released to production.  Because testonly is enforced at build time, not run time, and propagates virally through the dependency tree, it should be applied judiciously. For example, stubs and fakes that are useful for unit tests may also be useful for integration tests involving the same binaries that will be released to production, and therefore should probably not be marked testonly. Conversely, rules that are dangerous to even link in, perhaps because they unconditionally override normal behavior, should definitely be marked testonly. |
 | `toolchains` | List of [labels](/versions/9.0.0/concepts/labels); [nonconfigurable](#configurable-attributes); default is `[]`  The set of targets whose [Make variables](/versions/9.0.0/reference/be/make-variables) this target is allowed to access. These targets are either instances of rules that provide `TemplateVariableInfo` or special targets for toolchain types built into Bazel. These include:  * `@bazel_tools//tools/cpp:toolchain_type`* `@rules_java//toolchains:current_java_runtime`   Note that this is distinct from the concept of [toolchain resolution](/versions/9.0.0/docs/toolchains#toolchain-resolution) that is used by rule implementations for platform-dependent configuration. You cannot use this attribute to determine which specific `cc_toolchain` or `java_toolchain` a target will use. |
 | `visibility` | List of [labels](/versions/9.0.0/concepts/labels); [nonconfigurable](#configurable-attributes); default varies  The `visibility` attribute controls whether the target can be depended on by targets in other locations. See the documentation for [visibility](/versions/9.0.0/concepts/visibility).  For targets declared directly in a BUILD file or in legacy macros called from a BUILD file, the default value is the package's `default_visibility` if specified, or else `["//visibility:private"]`. For targets declared in one or more symbolic macros, the default value is always just `["//visibility:private"]` (which makes it useable only within the package containing the macro's code). |
diff --git a/versions/9.0.0/reference/be/functions.mdx b/versions/9.0.0/reference/be/functions.mdx
index 5e3eff6e..793adf58 100644
--- a/versions/9.0.0/reference/be/functions.mdx
+++ b/versions/9.0.0/reference/be/functions.mdx
@@ -34,9 +34,9 @@ file, before any rule.
 | --- | --- |
 | `default_applicable_licenses` | Alias for [`default_package_metadata`](#package.default_package_metadata). |
 | `default_visibility` | List of [labels](/versions/9.0.0/concepts/labels); default is `[]`  The default visibility of the top-level rule targets and symbolic macros in this package — that is, the targets and symbolic macros that are not themselves declared inside a symbolic macro. This attribute is ignored if the target or macro specifies a `visibility` value.  For detailed information about the syntax of this attribute, see the documentation of [visibility](/versions/9.0.0/concepts/visibility). The package default visibility does not apply to [exports\_files](#exports_files), which is public by default. |
-| `default_deprecation` | String; default is `""`  Sets the default [`deprecation`](common-definitions#common.deprecation) message for all rules in this package. |
+| `default_deprecation` | String; default is `""`  Sets the default [`deprecation`](/versions/9.0.0/reference/be/common-definitions#common.deprecation) message for all rules in this package. |
 | `default_package_metadata` | List of [labels](/versions/9.0.0/concepts/labels); default is `[]`  Sets a default list of metadata targets which apply to all other targets in the package. These are typically targets related to OSS package and license declarations. See [rules\_license](https://github.com/bazelbuild/rules_license) for examples. |
-| `default_testonly` | Boolean; default is `False` except as noted  Sets the default [`testonly`](common-definitions#common.testonly) property for all rules in this package.  In packages under `javatests` the default value is `True`. |
+| `default_testonly` | Boolean; default is `False` except as noted  Sets the default [`testonly`](/versions/9.0.0/reference/be/common-definitions#common.testonly) property for all rules in this package.  In packages under `javatests` the default value is `True`. |
 | `features` | List strings; default is `[]`  Sets various flags that affect the semantics of this BUILD file.  This feature is mainly used by the people working on the build system to tag packages that need some kind of special handling. Do not use this unless explicitly requested by someone working on the build system. |
 
 ### Examples
@@ -66,7 +66,7 @@ visible target can only be referenced within its own package (not subpackages).
 In between these extremes, a target may allow access to its own package plus any
 of the packages described by one or more package groups. For a more detailed
 explanation of the visibility system, see the
-[visibility](common-definitions#common.visibility)
+[visibility](/versions/9.0.0/reference/be/common-definitions#common.visibility)
 attribute.
 
 A given package is considered to be in the group if it either matches the
@@ -159,7 +159,7 @@ visibility declaration can also be specified; in this case, the files will be
 visible to the targets specified. If no visibility is specified, the files
 will be visible to every package, even if a package default visibility was
 specified in the `package`
-function. The [licenses](common-definitions#common.licenses)
+function. The [licenses](/versions/9.0.0/reference/be/common-definitions#common.licenses)
 can also be specified.
 
 ### Example
@@ -262,8 +262,7 @@ There are several important limitations and caveats:
    package called "Foo.java" (which is allowed, though Bazel warns about it),
    then the consumer of the `glob()` will use the "Foo.java" rule
    (its outputs) instead of the "Foo.java" file. See
-   [GitHub
-   issue #10395](https://github.com/bazelbuild/bazel/issues/10395#issuecomment-583714657) for more details.
+   [GitHub issue #10395](https://github.com/bazelbuild/bazel/issues/10395#issuecomment-583714657) for more details.
 3. Globs may match files in subdirectories. And subdirectory names
    may be wildcarded. However...
 4. Labels are not allowed to cross the package boundary and glob does
@@ -409,7 +408,7 @@ select(
 ```
 
 `select()` is the helper function that makes a rule attribute
-[configurable](common-definitions#configurable-attributes).
+[configurable](/versions/9.0.0/reference/be/common-definitions#configurable-attributes).
 It can replace the right-hand side of
 *almost*
 any attribute assignment so its value depends on command-line Bazel flags.
diff --git a/versions/9.0.0/reference/be/general.mdx b/versions/9.0.0/reference/be/general.mdx
index 1383257f..90bb4684 100644
--- a/versions/9.0.0/reference/be/general.mdx
+++ b/versions/9.0.0/reference/be/general.mdx
@@ -158,9 +158,9 @@ some build targets.
   [here](/versions/9.0.0/reference/be/common-definitions#configurable-attributes) for more discussion.
 * Avoid repeating identical `config_setting` definitions in different packages.
   Instead, reference a common `config_setting` that defined in a canonical package.
-* [`values`](general#config_setting.values),
-  [`define_values`](general#config_setting.define_values), and
-  [`constraint_values`](general#config_setting.constraint_values)
+* [`values`](/versions/9.0.0/reference/be/general#config_setting.values),
+  [`define_values`](/versions/9.0.0/reference/be/general#config_setting.define_values), and
+  [`constraint_values`](/versions/9.0.0/reference/be/general#config_setting.constraint_values)
   can be used in any combination in the same `config_setting` but at least one must
   be set for any given `config_setting`.
 
@@ -169,10 +169,10 @@ some build targets.
 | Attributes | |
 | --- | --- |
 | `name` | [Name](/versions/9.0.0/concepts/labels#target-names); required  A unique name for this target. |
-| `constraint_values` | List of [labels](/versions/9.0.0/concepts/labels); [nonconfigurable](common-definitions#configurable-attributes); default is `[]` The minimum set of `constraint_values` that the target platform must specify in order to match this `config_setting`. (The execution platform is not considered here.) Any additional constraint values that the platform has are ignored. See [Configurable Build Attributes](https://bazel.build/versions/9.0.0/docs/configurable-attributes#platforms) for details. If two `config_setting`s match in the same `select` and one has all the same flags and `constraint_setting`s as the other plus additional ones, the one with more settings is chosen. This is known as "specialization". For example, a `config_setting` matching `x86` and `Linux` specializes a `config_setting` matching `x86`. If two `config_setting`s match and both have `constraint_value`s not present in the other, this is an error. |
-| `define_values` | Dictionary: String -> String; [nonconfigurable](common-definitions#configurable-attributes); default is `{}` The same as [`values`](/versions/9.0.0/reference/be/general#config_setting.values) but specifically for the `--define` flag. `--define` is special because its syntax (`--define KEY=VAL`) means `KEY=VAL` is a *value* from a Bazel flag perspective.  That means:  ```             config_setting(                 name = "a_and_b",                 values = {                     "define": "a=1",                     "define": "b=2",                 }) ```   doesn't work because the same key (`define`) appears twice in the dictionary. This attribute solves that problem:  ```             config_setting(                 name = "a_and_b",                 define_values = {                     "a": "1",                     "b": "2",                 }) ```   correctly matches `bazel build //foo --define a=1 --define b=2`. `--define` can still appear in [`values`](/versions/9.0.0/reference/be/general#config_setting.values) with normal flag syntax, and can be mixed freely with this attribute as long as dictionary keys remain distinct. |
-| `flag_values` | Dictionary: [label](/versions/9.0.0/concepts/labels) -> String; [nonconfigurable](common-definitions#configurable-attributes); default is `{}` The same as [`values`](/versions/9.0.0/reference/be/general#config_setting.values) but for [user-defined build flags](https://bazel.build/versions/9.0.0/rules/config#user-defined-build-settings). This is a distinct attribute because user-defined flags are referenced as labels while built-in flags are referenced as arbitrary strings. |
-| `values` | Dictionary: String -> String; [nonconfigurable](common-definitions#configurable-attributes); default is `{}` The set of configuration values that match this rule (expressed as build flags) This rule inherits the configuration of the configured target that references it in a `select` statement. It is considered to "match" a Bazel invocation if, for every entry in the dictionary, its configuration matches the entry's expected value. For example `values = {"compilation_mode": "opt"}` matches the invocations `bazel build --compilation_mode=opt ...` and `bazel build -c opt ...` on target-configured rules.  For convenience's sake, configuration values are specified as build flags (without the preceding `"--"`). But keep in mind that the two are not the same. This is because targets can be built in multiple configurations within the same build. For example, an exec configuration's "cpu" matches the value of `--host_cpu`, not `--cpu`. So different instances of the same `config_setting` may match the same invocation differently depending on the configuration of the rule using them.  If a flag is not explicitly set at the command line, its default value is used. If a key appears multiple times in the dictionary, only the last instance is used. If a key references a flag that can be set multiple times on the command line (e.g. `bazel build --copt=foo --copt=bar --copt=baz ...`), a match occurs if *any* of those settings match. |
+| `constraint_values` | List of [labels](/versions/9.0.0/concepts/labels); [nonconfigurable](/versions/9.0.0/reference/be/common-definitions#configurable-attributes); default is `[]` The minimum set of `constraint_values` that the target platform must specify in order to match this `config_setting`. (The execution platform is not considered here.) Any additional constraint values that the platform has are ignored. See [Configurable Build Attributes](https://bazel.build/versions/9.0.0/docs/configurable-attributes#platforms) for details. If two `config_setting`s match in the same `select` and one has all the same flags and `constraint_setting`s as the other plus additional ones, the one with more settings is chosen. This is known as "specialization". For example, a `config_setting` matching `x86` and `Linux` specializes a `config_setting` matching `x86`. If two `config_setting`s match and both have `constraint_value`s not present in the other, this is an error. |
+| `define_values` | Dictionary: String -> String; [nonconfigurable](/versions/9.0.0/reference/be/common-definitions#configurable-attributes); default is `{}` The same as [`values`](/versions/9.0.0/reference/be/general#config_setting.values) but specifically for the `--define` flag. `--define` is special because its syntax (`--define KEY=VAL`) means `KEY=VAL` is a *value* from a Bazel flag perspective.  That means:  ```             config_setting(                 name = "a_and_b",                 values = {                     "define": "a=1",                     "define": "b=2",                 }) ```   doesn't work because the same key (`define`) appears twice in the dictionary. This attribute solves that problem:  ```             config_setting(                 name = "a_and_b",                 define_values = {                     "a": "1",                     "b": "2",                 }) ```   correctly matches `bazel build //foo --define a=1 --define b=2`. `--define` can still appear in [`values`](/versions/9.0.0/reference/be/general#config_setting.values) with normal flag syntax, and can be mixed freely with this attribute as long as dictionary keys remain distinct. |
+| `flag_values` | Dictionary: [label](/versions/9.0.0/concepts/labels) -> String; [nonconfigurable](/versions/9.0.0/reference/be/common-definitions#configurable-attributes); default is `{}` The same as [`values`](/versions/9.0.0/reference/be/general#config_setting.values) but for [user-defined build flags](https://bazel.build/versions/9.0.0/rules/config#user-defined-build-settings). This is a distinct attribute because user-defined flags are referenced as labels while built-in flags are referenced as arbitrary strings. |
+| `values` | Dictionary: String -> String; [nonconfigurable](/versions/9.0.0/reference/be/common-definitions#configurable-attributes); default is `{}` The set of configuration values that match this rule (expressed as build flags) This rule inherits the configuration of the configured target that references it in a `select` statement. It is considered to "match" a Bazel invocation if, for every entry in the dictionary, its configuration matches the entry's expected value. For example `values = {"compilation_mode": "opt"}` matches the invocations `bazel build --compilation_mode=opt ...` and `bazel build -c opt ...` on target-configured rules.  For convenience's sake, configuration values are specified as build flags (without the preceding `"--"`). But keep in mind that the two are not the same. This is because targets can be built in multiple configurations within the same build. For example, an exec configuration's "cpu" matches the value of `--host_cpu`, not `--cpu`. So different instances of the same `config_setting` may match the same invocation differently depending on the configuration of the rule using them.  If a flag is not explicitly set at the command line, its default value is used. If a key appears multiple times in the dictionary, only the last instance is used. If a key references a flag that can be set multiple times on the command line (e.g. `bazel build --copt=foo --copt=bar --copt=baz ...`), a match occurs if *any* of those settings match. |
 
 ## filegroup
 
@@ -466,7 +466,7 @@ genrule(
 | --- | --- |
 | `name` | [Name](/versions/9.0.0/concepts/labels#target-names); required  A unique name for this target.  You may refer to this rule by name in the `srcs` or `deps` section of other `BUILD` rules. If the rule generates source files, you should use the `srcs` attribute. |
 | `srcs` | List of [labels](/versions/9.0.0/concepts/labels); default is `[]` A list of inputs for this rule, such as source files to process. *This attributes is not suitable to list tools executed by the `cmd`; use the [`tools`](/versions/9.0.0/reference/be/general#genrule.tools) attribute for them instead.*  The build system ensures these prerequisites are built before running the genrule command; they are built using the same configuration as the original build request. The names of the files of these prerequisites are available to the command as a space-separated list in `$(SRCS)`; alternatively the path of an individual `srcs` target `//x:y` can be obtained using `$(location //x:y)`, or using `$<` provided it's the only entry in `srcs`. |
-| `outs` | List of [filenames](/versions/9.0.0/concepts/build-ref#filename); [nonconfigurable](common-definitions#configurable-attributes); required A list of files generated by this rule. Output files must not cross package boundaries. Output filenames are interpreted as relative to the package.  If the `executable` flag is set, `outs` must contain exactly one label.  The genrule command is expected to create each output file at a predetermined location. The location is available in `cmd` using [genrule-specific "Make" variables](/versions/9.0.0/reference/be/make-variables#predefined_genrule_variables) (`$@`, `$(OUTS)`, `$(@D)` or `$(RULEDIR)`) or using [`$(location)`](/versions/9.0.0/reference/be/make-variables#predefined_label_variables) substitution. |
+| `outs` | List of [filenames](/versions/9.0.0/concepts/build-ref#filename); [nonconfigurable](/versions/9.0.0/reference/be/common-definitions#configurable-attributes); required A list of files generated by this rule. Output files must not cross package boundaries. Output filenames are interpreted as relative to the package.  If the `executable` flag is set, `outs` must contain exactly one label.  The genrule command is expected to create each output file at a predetermined location. The location is available in `cmd` using [genrule-specific "Make" variables](/versions/9.0.0/reference/be/make-variables#predefined_genrule_variables) (`$@`, `$(OUTS)`, `$(@D)` or `$(RULEDIR)`) or using [`$(location)`](/versions/9.0.0/reference/be/make-variables#predefined_label_variables) substitution. |
 | `cmd` | String; default is `""` The command to run. Subject to [`$(location)`](/versions/9.0.0/reference/be/make-variables#predefined_label_variables) and ["Make" variable](/versions/9.0.0/reference/be/make-variables) substitution.  1. First [`$(location)`](/versions/9.0.0/reference/be/make-variables#predefined_label_variables) substitution is applied, replacing all occurrences of `$(location     label)` and of `$(locations label)` (and similar    constructions using related variables `execpath`, `execpaths`,    `rootpath` and `rootpaths`). 2. Next, ["Make" variables](/versions/9.0.0/reference/be/make-variables) are expanded. Note that    predefined variables `$(JAVA)`, `$(JAVAC)` and    `$(JAVABASE)` expand under the *exec* configuration, so Java invocations    that run as part of a build step can correctly load shared libraries and other    dependencies. 3. Finally, the resulting command is executed using the Bash shell. If its exit code is    non-zero the command is considered to have failed.  This is the fallback of `cmd_bash`, `cmd_ps` and `cmd_bat`, if none of them are applicable. |
 
 If the command line length exceeds the platform limit (64K on Linux/macOS, 8K on Windows),
@@ -477,12 +477,12 @@ applies to all cmd attributes (`cmd`, `cmd_bash`, `cmd_ps`,
 | `cmd_bash` | String; default is `""` The Bash command to run. This attribute has higher priority than `cmd`. The command is expanded and runs in the exact same way as the `cmd` attribute. |
 | `cmd_bat` | String; default is `""` The Batch command to run on Windows. This attribute has higher priority than `cmd` and `cmd_bash`. The command runs in the similar way as the `cmd` attribute, with the following differences:   * This attribute only applies on Windows. * The command runs with `cmd.exe /c` with the following default arguments:   + `/S` - strip first and last quotes and execute everything else as is.   + `/E:ON` - enable extended command set.   + `/V:ON` - enable delayed variable expansion   + `/D` - ignore AutoRun registry entries. * After [$(location)](/versions/9.0.0/reference/be/make-variables#predefined_label_variables) and   ["Make" variable](/versions/9.0.0/reference/be/make-variables) substitution, the paths will be   expanded to Windows style paths (with backslash). |
 | `cmd_ps` | String; default is `""` The Powershell command to run on Windows. This attribute has higher priority than `cmd`, `cmd_bash` and `cmd_bat`. The command runs in the similar way as the `cmd` attribute, with the following differences:   * This attribute only applies on Windows. * The command runs with `powershell.exe /c`.   To make Powershell easier to use and less error-prone, we run the following commands to set up the environment before executing Powershell command in genrule.   * `Set-ExecutionPolicy -Scope CurrentUser RemoteSigned` - allow running   unsigned scripts. * `$errorActionPreference='Stop'` - In case there are multiple commands   separated by `;`, the action exits immediately if a Powershell CmdLet fails,   but this does **NOT** work for external command. * `$PSDefaultParameterValues['*:Encoding'] = 'utf8'` - change the default   encoding from utf-16 to utf-8. |
-| `executable` | Boolean; [nonconfigurable](common-definitions#configurable-attributes); default is `False` Declare output to be executable. Setting this flag to True means the output is an executable file and can be run using the `run` command. The genrule must produce exactly one output in this case. If this attribute is set, `run` will try executing the file regardless of its content.  Declaring data dependencies for the generated executable is not supported. |
+| `executable` | Boolean; [nonconfigurable](/versions/9.0.0/reference/be/common-definitions#configurable-attributes); default is `False` Declare output to be executable. Setting this flag to True means the output is an executable file and can be run using the `run` command. The genrule must produce exactly one output in this case. If this attribute is set, `run` will try executing the file regardless of its content.  Declaring data dependencies for the generated executable is not supported. |
 | `local` | Boolean; default is `False`  If set to True, this option forces this `genrule` to run using the "local" strategy, which means no remote execution, no sandboxing, no persistent workers.  This is equivalent to providing 'local' as a tag (`tags=["local"]`). |
 | `message` | String; default is `""` A progress message. A progress message that will be printed as this build step is executed. By default, the message is "Generating *output*" (or something equally bland) but you may provide a more specific one. Use this attribute instead of `echo` or other print statements in your `cmd` command, as this allows the build tool to control whether such progress messages are printed or not. |
 | `output_licenses` | List of strings; default is `[]` See [`common attributes`](/versions/9.0.0/reference/be/common-definitions#binary.output_licenses) |
-| `output_to_bindir` | Boolean; [nonconfigurable](common-definitions#configurable-attributes); default is `False`  If set to True, this option causes output files to be written into the `bin` directory instead of the `genfiles` directory. |
-| `toolchains` | List of [labels](/versions/9.0.0/concepts/labels); [nonconfigurable](common-definitions#configurable-attributes); default is `[]`  The set of targets whose [Make variables](/versions/9.0.0/reference/be/make-variables) this genrule is allowed to access, or the [`toolchain_type`](/versions/9.0.0/docs/toolchains) targets that this genrule will access.  Toolchains accessed via `toolchain_type` must also provide a `TemplateVariableInfo` provider, which the target can use to access toolchain details. |
+| `output_to_bindir` | Boolean; [nonconfigurable](/versions/9.0.0/reference/be/common-definitions#configurable-attributes); default is `False`  If set to True, this option causes output files to be written into the `bin` directory instead of the `genfiles` directory. |
+| `toolchains` | List of [labels](/versions/9.0.0/concepts/labels); [nonconfigurable](/versions/9.0.0/reference/be/common-definitions#configurable-attributes); default is `[]`  The set of targets whose [Make variables](/versions/9.0.0/reference/be/make-variables) this genrule is allowed to access, or the [`toolchain_type`](/versions/9.0.0/docs/toolchains) targets that this genrule will access.  Toolchains accessed via `toolchain_type` must also provide a `TemplateVariableInfo` provider, which the target can use to access toolchain details. |
 | `tools` | List of [labels](/versions/9.0.0/concepts/labels); default is `[]` A list of *tool* dependencies for this rule. See the definition of [dependencies](/versions/9.0.0/concepts/build-ref#deps) for more information.   The build system ensures these prerequisites are built before running the genrule command; they are built using the [*exec* configuration](/versions/9.0.0/contribute/guide#configurations), since these tools are executed as part of the build. The path of an individual `tools` target `//x:y` can be obtained using `$(location //x:y)`.  Any `*_binary` or tool to be executed by `cmd` must appear in this list, not in `srcs`, to ensure they are built in the correct configuration. |
 
 ## starlark\_doc\_extract
@@ -576,5 +576,5 @@ test_suite(
 | Attributes | |
 | --- | --- |
 | `name` | [Name](/versions/9.0.0/concepts/labels#target-names); required  A unique name for this target. |
-| `tags` | List of strings; [nonconfigurable](common-definitions#configurable-attributes); default is `[]` List of text tags such as "small" or "database" or "-flaky". Tags may be any valid string. Tags which begin with a "-" character are considered negative tags. The preceding "-" character is not considered part of the tag, so a suite tag of "-small" matches a test's "small" size. All other tags are considered positive tags.  Optionally, to make positive tags more explicit, tags may also begin with the "+" character, which will not be evaluated as part of the text of the tag. It merely makes the positive and negative distinction easier to read.  Only test rules that match **all** of the positive tags and **none** of the negative tags will be included in the test suite. Note that this does not mean that error checking for dependencies on tests that are filtered out is skipped; the dependencies on skipped tests still need to be legal (e.g. not blocked by visibility constraints).  The `manual` tag keyword is treated differently than the above by the "test\_suite expansion" performed by the `bazel test` command on invocations involving wildcard [target patterns](https://bazel.build/versions/9.0.0/docs/build#specifying-build-targets). There, `test_suite` targets tagged "manual" are filtered out (and thus not expanded). This behavior is consistent with how `bazel build` and `bazel test` handle wildcard target patterns in general. Note that this is explicitly different from how `bazel query 'tests(E)'` behaves, as suites are always expanded by the `tests` query function, regardless of the `manual` tag.  Note that a test's `size` is considered a tag for the purpose of filtering.  If you need a `test_suite` that contains tests with mutually exclusive tags (e.g. all small and medium tests), you'll have to create three `test_suite` rules: one for all small tests, one for all medium tests, and one that includes the previous two. |
-| `tests` | List of [labels](/versions/9.0.0/concepts/labels); [nonconfigurable](common-definitions#configurable-attributes); default is `[]` A list of test suites and test targets of any language. Any `*_test` is accepted here, independent of the language. No `*_binary` targets are accepted however, even if they happen to run a test. Filtering by the specified `tags` is only done for tests listed directly in this attribute. If this attribute contains `test_suite`s, the tests inside those will not be filtered by this `test_suite` (they are considered to be filtered already).  If the `tests` attribute is unspecified or empty, the rule will default to including all test rules in the current BUILD file that are not tagged as `manual`. These rules are still subject to `tag` filtering. |
\ No newline at end of file
+| `tags` | List of strings; [nonconfigurable](/versions/9.0.0/reference/be/common-definitions#configurable-attributes); default is `[]` List of text tags such as "small" or "database" or "-flaky". Tags may be any valid string. Tags which begin with a "-" character are considered negative tags. The preceding "-" character is not considered part of the tag, so a suite tag of "-small" matches a test's "small" size. All other tags are considered positive tags.  Optionally, to make positive tags more explicit, tags may also begin with the "+" character, which will not be evaluated as part of the text of the tag. It merely makes the positive and negative distinction easier to read.  Only test rules that match **all** of the positive tags and **none** of the negative tags will be included in the test suite. Note that this does not mean that error checking for dependencies on tests that are filtered out is skipped; the dependencies on skipped tests still need to be legal (e.g. not blocked by visibility constraints).  The `manual` tag keyword is treated differently than the above by the "test\_suite expansion" performed by the `bazel test` command on invocations involving wildcard [target patterns](https://bazel.build/versions/9.0.0/docs/build#specifying-build-targets). There, `test_suite` targets tagged "manual" are filtered out (and thus not expanded). This behavior is consistent with how `bazel build` and `bazel test` handle wildcard target patterns in general. Note that this is explicitly different from how `bazel query 'tests(E)'` behaves, as suites are always expanded by the `tests` query function, regardless of the `manual` tag.  Note that a test's `size` is considered a tag for the purpose of filtering.  If you need a `test_suite` that contains tests with mutually exclusive tags (e.g. all small and medium tests), you'll have to create three `test_suite` rules: one for all small tests, one for all medium tests, and one that includes the previous two. |
+| `tests` | List of [labels](/versions/9.0.0/concepts/labels); [nonconfigurable](/versions/9.0.0/reference/be/common-definitions#configurable-attributes); default is `[]` A list of test suites and test targets of any language. Any `*_test` is accepted here, independent of the language. No `*_binary` targets are accepted however, even if they happen to run a test. Filtering by the specified `tags` is only done for tests listed directly in this attribute. If this attribute contains `test_suite`s, the tests inside those will not be filtered by this `test_suite` (they are considered to be filtered already).  If the `tests` attribute is unspecified or empty, the rule will default to including all test rules in the current BUILD file that are not tagged as `manual`. These rules are still subject to `tag` filtering. |
\ No newline at end of file
diff --git a/versions/9.0.0/reference/be/java.mdx b/versions/9.0.0/reference/be/java.mdx
index 456be8b8..55028b9a 100644
--- a/versions/9.0.0/reference/be/java.mdx
+++ b/versions/9.0.0/reference/be/java.mdx
@@ -103,7 +103,7 @@ java_binary(
 | Attributes | |
 | --- | --- |
 | `name` | [Name](/versions/9.0.0/concepts/labels#target-names); required  A unique name for this target. |
-| `deps` | List of [labels](/versions/9.0.0/concepts/labels); default is `[]` The list of other libraries to be linked in to the target. See general comments about `deps` at [Typical attributes defined by most build rules](common-definitions#typical-attributes). |
+| `deps` | List of [labels](/versions/9.0.0/concepts/labels); default is `[]` The list of other libraries to be linked in to the target. See general comments about `deps` at [Typical attributes defined by most build rules](/versions/9.0.0/reference/be/common-definitions#typical-attributes). |
 | `srcs` | List of [labels](/versions/9.0.0/concepts/labels); default is `[]` The list of source files that are processed to create the target. This attribute is almost always required; see exceptions below. Source files of type `.java` are compiled. In case of generated `.java` files it is generally advisable to put the generating rule's name here instead of the name of the file itself. This not only improves readability but makes the rule more resilient to future changes: if the generating rule generates different files in the future, you only need to fix one place: the `outs` of the generating rule. You should not list the generating rule in `deps` because it is a no-op.  Source files of type `.srcjar` are unpacked and compiled. (This is useful if you need to generate a set of `.java` files with a genrule.)  Rules: if the rule (typically `genrule` or `filegroup`) generates any of the files listed above, they will be used the same way as described for source files.  This argument is almost always required, except if a [`main_class`](#java_binary.main_class) attribute specifies a class on the runtime classpath or you specify the `runtime_deps` argument. |
 | `data` | List of [labels](/versions/9.0.0/concepts/labels); default is `[]` The list of files needed by this library at runtime. See general comments about `data` at [Typical attributes defined by most build rules](/versions/9.0.0/reference/be/common-definitions#typical-attributes). |
 | `resources` | List of [labels](/versions/9.0.0/concepts/labels); default is `[]` A list of data files to include in a Java jar. Resources may be source files or generated files.  If resources are specified, they will be bundled in the jar along with the usual `.class` files produced by compilation. The location of the resources inside of the jar file is determined by the project structure. Bazel first looks for Maven's [standard directory layout](https://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html), (a "src" directory followed by a "resources" directory grandchild). If that is not found, Bazel then looks for the topmost directory named "java" or "javatests" (so, for example, if a resource is at `/x/java/y/java/z`, the path of the resource will be `y/java/z`. This heuristic cannot be overridden, however, the `resource_strip_prefix` attribute can be used to specify a specific alternative directory for resource files. |
@@ -113,9 +113,9 @@ java_binary(
 | `classpath_resources` | List of [labels](/versions/9.0.0/concepts/labels); default is `[]` *DO NOT USE THIS OPTION UNLESS THERE IS NO OTHER WAY)* A list of resources that must be located at the root of the java tree. This attribute's only purpose is to support third-party libraries that require that their resources be found on the classpath as exactly `"myconfig.xml"`. It is only allowed on binaries and not libraries, due to the danger of namespace conflicts. |
 | `create_executable` | Boolean; default is `True` Deprecated, use `java_single_jar` instead. |
 | `deploy_env` | List of [labels](/versions/9.0.0/concepts/labels); default is `[]` A list of other `java_binary` targets which represent the deployment environment for this binary. Set this attribute when building a plugin which will be loaded by another `java_binary`.  Setting this attribute excludes all dependencies from the runtime classpath (and the deploy jar) of this binary that are shared between this binary and the targets specified in `deploy_env`. |
-| `deploy_manifest_lines` | List of strings; default is `[]` A list of lines to add to the `META-INF/manifest.mf` file generated for the `*_deploy.jar` target. The contents of this attribute are *not* subject to ["Make variable"](make-variables) substitution. |
-| `javacopts` | List of strings; default is `[]` Extra compiler options for this binary. Subject to ["Make variable"](make-variables) substitution and [Bourne shell tokenization](common-definitions#sh-tokenization). These compiler options are passed to javac after the global compiler options. |
-| `jvm_flags` | List of strings; default is `[]` A list of flags to embed in the wrapper script generated for running this binary. Subject to [$(location)](/versions/9.0.0/reference/be/make-variables#location) and ["Make variable"](make-variables) substitution, and [Bourne shell tokenization](common-definitions#sh-tokenization). The wrapper script for a Java binary includes a CLASSPATH definition (to find all the dependent jars) and invokes the right Java interpreter. The command line generated by the wrapper script includes the name of the main class followed by a `"$@"` so you can pass along other arguments after the classname. However, arguments intended for parsing by the JVM must be specified *before* the classname on the command line. The contents of `jvm_flags` are added to the wrapper script before the classname is listed.  Note that this attribute has *no effect* on `*_deploy.jar` outputs. |
+| `deploy_manifest_lines` | List of strings; default is `[]` A list of lines to add to the `META-INF/manifest.mf` file generated for the `*_deploy.jar` target. The contents of this attribute are *not* subject to ["Make variable"](/versions/9.0.0/reference/be/make-variables) substitution. |
+| `javacopts` | List of strings; default is `[]` Extra compiler options for this binary. Subject to ["Make variable"](/versions/9.0.0/reference/be/make-variables) substitution and [Bourne shell tokenization](/versions/9.0.0/reference/be/common-definitions#sh-tokenization). These compiler options are passed to javac after the global compiler options. |
+| `jvm_flags` | List of strings; default is `[]` A list of flags to embed in the wrapper script generated for running this binary. Subject to [$(location)](/versions/9.0.0/reference/be/make-variables#location) and ["Make variable"](/versions/9.0.0/reference/be/make-variables) substitution, and [Bourne shell tokenization](/versions/9.0.0/reference/be/common-definitions#sh-tokenization). The wrapper script for a Java binary includes a CLASSPATH definition (to find all the dependent jars) and invokes the right Java interpreter. The command line generated by the wrapper script includes the name of the main class followed by a `"$@"` so you can pass along other arguments after the classname. However, arguments intended for parsing by the JVM must be specified *before* the classname on the command line. The contents of `jvm_flags` are added to the wrapper script before the classname is listed.  Note that this attribute has *no effect* on `*_deploy.jar` outputs. |
 | `launcher` | [Label](/versions/9.0.0/concepts/labels); default is `None` Specify a binary that will be used to run your Java program instead of the normal `bin/java` program included with the JDK. The target must be a `cc_binary`. Any `cc_binary` that implements the [Java Invocation API](http://docs.oracle.com/javase/7/docs/technotes/guides/jni/spec/invocation.html) can be specified as a value for this attribute. By default, Bazel will use the normal JDK launcher (bin/java or java.exe).  The related [`--java_launcher`](/versions/9.0.0/docs/user-manual#flag--java_launcher) Bazel flag affects only those `java_binary` and `java_test` targets that have *not* specified a `launcher` attribute.  Note that your native (C++, SWIG, JNI) dependencies will be built differently depending on whether you are using the JDK launcher or another launcher:   * If you are using the normal JDK launcher (the default), native dependencies are   built as a shared library named `{name}_nativedeps.so`, where   `{name}` is the `name` attribute of this java\_binary rule.   Unused code is *not* removed by the linker in this configuration. * If you are using any other launcher, native (C++) dependencies are statically   linked into a binary named `{name}_nativedeps`, where `{name}`   is the `name` attribute of this java\_binary rule. In this case,   the linker will remove any code it thinks is unused from the resulting binary,   which means any C++ code accessed only via JNI may not be linked in unless   that `cc_library` target specifies `alwayslink = True`.   When using any launcher other than the default JDK launcher, the format of the `*_deploy.jar` output changes. See the main [java\_binary](#java_binary) docs for details. |
 | `main_class` | String; default is `""` Name of class with `main()` method to use as entry point. If a rule uses this option, it does not need a `srcs=[...]` list. Thus, with this attribute one can make an executable from a Java library that already contains one or more `main()` methods. The value of this attribute is a class name, not a source file. The class must be available at runtime: it may be compiled by this rule (from `srcs`) or provided by direct or transitive dependencies (through `runtime_deps` or `deps`). If the class is unavailable, the binary will fail at runtime; there is no build-time check. |
 | `neverlink` | Boolean; default is `False` |
@@ -199,7 +199,7 @@ This rule compiles and links sources into a `.jar` file.
 | `exported_plugins` | List of [labels](/versions/9.0.0/concepts/labels); default is `[]` The list of `java_plugin`s (e.g. annotation processors) to export to libraries that directly depend on this library. The specified list of `java_plugin`s will be applied to any library which directly depends on this library, just as if that library had explicitly declared these labels in `plugins`. |
 | `exports` | List of [labels](/versions/9.0.0/concepts/labels); default is `[]` Exported libraries. Listing rules here will make them available to parent rules, as if the parents explicitly depended on these rules. This is not true for regular (non-exported) `deps`.  Summary: a rule *X* can access the code in *Y* if there exists a dependency path between them that begins with a `deps` edge followed by zero or more `exports` edges. Let's see some examples to illustrate this.  Assume *A* depends on *B* and *B* depends on *C*. In this case C is a *transitive* dependency of A, so changing C's sources and rebuilding A will correctly rebuild everything. However A will not be able to use classes in C. To allow that, either A has to declare C in its `deps`, or B can make it easier for A (and anything that may depend on A) by declaring C in its (B's) `exports` attribute.  The closure of exported libraries is available to all direct parent rules. Take a slightly different example: A depends on B, B depends on C and D, and also exports C but not D. Now A has access to C but not to D. Now, if C and D exported some libraries, C' and D' respectively, A could only access C' but not D'.  Important: an exported rule is not a regular dependency. Sticking to the previous example, if B exports C and wants to also use C, it has to also list it in its own `deps`. |
 | `javabuilder_jvm_flags` | List of strings; default is `[]` Restricted API, do not use! |
-| `javacopts` | List of strings; default is `[]` Extra compiler options for this library. Subject to ["Make variable"](make-variables) substitution and [Bourne shell tokenization](common-definitions#sh-tokenization). These compiler options are passed to javac after the global compiler options. |
+| `javacopts` | List of strings; default is `[]` Extra compiler options for this library. Subject to ["Make variable"](/versions/9.0.0/reference/be/make-variables) substitution and [Bourne shell tokenization](/versions/9.0.0/reference/be/common-definitions#sh-tokenization). These compiler options are passed to javac after the global compiler options. |
 | `neverlink` | Boolean; default is `False` Whether this library should only be used for compilation and not at runtime. Useful if the library will be provided by the runtime environment during execution. Examples of such libraries are the IDE APIs for IDE plug-ins or `tools.jar` for anything running on a standard JDK. Note that `neverlink = True` does not prevent the compiler from inlining material from this library into compilation targets that depend on it, as permitted by the Java Language Specification (e.g., `static final` constants of `String` or of primitive types). The preferred use case is therefore when the runtime library is identical to the compilation library.  If the runtime library differs from the compilation library then you must ensure that it differs only in places that the JLS forbids compilers to inline (and that must hold for all future versions of the JLS). |
 | `plugins` | List of [labels](/versions/9.0.0/concepts/labels); default is `[]` Java compiler plugins to run at compile-time. Every `java_plugin` specified in this attribute will be run whenever this rule is built. A library may also inherit plugins from dependencies that use `exported_plugins`. Resources generated by the plugin will be included in the resulting jar of this rule. |
 | `proguard_specs` | List of [labels](/versions/9.0.0/concepts/labels); default is `[]` Files to be used as Proguard specification. These will describe the set of specifications to be used by Proguard. If specified, they will be added to any `android_binary` target depending on this library. The files included here must only have idempotent rules, namely -dontnote, -dontwarn, assumenosideeffects, and rules that start with -keep. Other options can only appear in `android_binary`'s proguard\_specs, to ensure non-tautological merges. |
@@ -226,8 +226,7 @@ test code. The test runner's main method is invoked instead of the main class be
   [java\_binary](#java_binary) for more details.
 
 See the section on `java_binary()` arguments. This rule also
-supports all [attributes common
-to all test rules (\*\_test)](https://bazel.build/reference/be/common-definitions#common-attributes-tests).
+supports all [attributes common to all test rules (\*\_test)](https://bazel.build/versions/9.0.0/reference/be/common-definitions#common-attributes-tests).
 
 #### Examples
 
@@ -256,7 +255,7 @@ java_test(
 | Attributes | |
 | --- | --- |
 | `name` | [Name](/versions/9.0.0/concepts/labels#target-names); required  A unique name for this target. |
-| `deps` | List of [labels](/versions/9.0.0/concepts/labels); default is `[]` The list of other libraries to be linked in to the target. See general comments about `deps` at [Typical attributes defined by most build rules](common-definitions#typical-attributes). |
+| `deps` | List of [labels](/versions/9.0.0/concepts/labels); default is `[]` The list of other libraries to be linked in to the target. See general comments about `deps` at [Typical attributes defined by most build rules](/versions/9.0.0/reference/be/common-definitions#typical-attributes). |
 | `srcs` | List of [labels](/versions/9.0.0/concepts/labels); default is `[]` The list of source files that are processed to create the target. This attribute is almost always required; see exceptions below. Source files of type `.java` are compiled. In case of generated `.java` files it is generally advisable to put the generating rule's name here instead of the name of the file itself. This not only improves readability but makes the rule more resilient to future changes: if the generating rule generates different files in the future, you only need to fix one place: the `outs` of the generating rule. You should not list the generating rule in `deps` because it is a no-op.  Source files of type `.srcjar` are unpacked and compiled. (This is useful if you need to generate a set of `.java` files with a genrule.)  Rules: if the rule (typically `genrule` or `filegroup`) generates any of the files listed above, they will be used the same way as described for source files.  This argument is almost always required, except if a [`main_class`](#java_binary.main_class) attribute specifies a class on the runtime classpath or you specify the `runtime_deps` argument. |
 | `data` | List of [labels](/versions/9.0.0/concepts/labels); default is `[]` The list of files needed by this library at runtime. See general comments about `data` at [Typical attributes defined by most build rules](/versions/9.0.0/reference/be/common-definitions#typical-attributes). |
 | `resources` | List of [labels](/versions/9.0.0/concepts/labels); default is `[]` A list of data files to include in a Java jar. Resources may be source files or generated files.  If resources are specified, they will be bundled in the jar along with the usual `.class` files produced by compilation. The location of the resources inside of the jar file is determined by the project structure. Bazel first looks for Maven's [standard directory layout](https://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html), (a "src" directory followed by a "resources" directory grandchild). If that is not found, Bazel then looks for the topmost directory named "java" or "javatests" (so, for example, if a resource is at `/x/java/y/java/z`, the path of the resource will be `y/java/z`. This heuristic cannot be overridden, however, the `resource_strip_prefix` attribute can be used to specify a specific alternative directory for resource files. |
@@ -265,9 +264,9 @@ java_test(
 | `bootclasspath` | [Label](/versions/9.0.0/concepts/labels); default is `None` Restricted API, do not use! |
 | `classpath_resources` | List of [labels](/versions/9.0.0/concepts/labels); default is `[]` *DO NOT USE THIS OPTION UNLESS THERE IS NO OTHER WAY)* A list of resources that must be located at the root of the java tree. This attribute's only purpose is to support third-party libraries that require that their resources be found on the classpath as exactly `"myconfig.xml"`. It is only allowed on binaries and not libraries, due to the danger of namespace conflicts. |
 | `create_executable` | Boolean; default is `True` Deprecated, use `java_single_jar` instead. |
-| `deploy_manifest_lines` | List of strings; default is `[]` A list of lines to add to the `META-INF/manifest.mf` file generated for the `*_deploy.jar` target. The contents of this attribute are *not* subject to ["Make variable"](make-variables) substitution. |
-| `javacopts` | List of strings; default is `[]` Extra compiler options for this binary. Subject to ["Make variable"](make-variables) substitution and [Bourne shell tokenization](common-definitions#sh-tokenization). These compiler options are passed to javac after the global compiler options. |
-| `jvm_flags` | List of strings; default is `[]` A list of flags to embed in the wrapper script generated for running this binary. Subject to [$(location)](/versions/9.0.0/reference/be/make-variables#location) and ["Make variable"](make-variables) substitution, and [Bourne shell tokenization](common-definitions#sh-tokenization). The wrapper script for a Java binary includes a CLASSPATH definition (to find all the dependent jars) and invokes the right Java interpreter. The command line generated by the wrapper script includes the name of the main class followed by a `"$@"` so you can pass along other arguments after the classname. However, arguments intended for parsing by the JVM must be specified *before* the classname on the command line. The contents of `jvm_flags` are added to the wrapper script before the classname is listed.  Note that this attribute has *no effect* on `*_deploy.jar` outputs. |
+| `deploy_manifest_lines` | List of strings; default is `[]` A list of lines to add to the `META-INF/manifest.mf` file generated for the `*_deploy.jar` target. The contents of this attribute are *not* subject to ["Make variable"](/versions/9.0.0/reference/be/make-variables) substitution. |
+| `javacopts` | List of strings; default is `[]` Extra compiler options for this binary. Subject to ["Make variable"](/versions/9.0.0/reference/be/make-variables) substitution and [Bourne shell tokenization](/versions/9.0.0/reference/be/common-definitions#sh-tokenization). These compiler options are passed to javac after the global compiler options. |
+| `jvm_flags` | List of strings; default is `[]` A list of flags to embed in the wrapper script generated for running this binary. Subject to [$(location)](/versions/9.0.0/reference/be/make-variables#location) and ["Make variable"](/versions/9.0.0/reference/be/make-variables) substitution, and [Bourne shell tokenization](/versions/9.0.0/reference/be/common-definitions#sh-tokenization). The wrapper script for a Java binary includes a CLASSPATH definition (to find all the dependent jars) and invokes the right Java interpreter. The command line generated by the wrapper script includes the name of the main class followed by a `"$@"` so you can pass along other arguments after the classname. However, arguments intended for parsing by the JVM must be specified *before* the classname on the command line. The contents of `jvm_flags` are added to the wrapper script before the classname is listed.  Note that this attribute has *no effect* on `*_deploy.jar` outputs. |
 | `launcher` | [Label](/versions/9.0.0/concepts/labels); default is `None` Specify a binary that will be used to run your Java program instead of the normal `bin/java` program included with the JDK. The target must be a `cc_binary`. Any `cc_binary` that implements the [Java Invocation API](http://docs.oracle.com/javase/7/docs/technotes/guides/jni/spec/invocation.html) can be specified as a value for this attribute. By default, Bazel will use the normal JDK launcher (bin/java or java.exe).  The related [`--java_launcher`](/versions/9.0.0/docs/user-manual#flag--java_launcher) Bazel flag affects only those `java_binary` and `java_test` targets that have *not* specified a `launcher` attribute.  Note that your native (C++, SWIG, JNI) dependencies will be built differently depending on whether you are using the JDK launcher or another launcher:   * If you are using the normal JDK launcher (the default), native dependencies are   built as a shared library named `{name}_nativedeps.so`, where   `{name}` is the `name` attribute of this java\_binary rule.   Unused code is *not* removed by the linker in this configuration. * If you are using any other launcher, native (C++) dependencies are statically   linked into a binary named `{name}_nativedeps`, where `{name}`   is the `name` attribute of this java\_binary rule. In this case,   the linker will remove any code it thinks is unused from the resulting binary,   which means any C++ code accessed only via JNI may not be linked in unless   that `cc_library` target specifies `alwayslink = True`.   When using any launcher other than the default JDK launcher, the format of the `*_deploy.jar` output changes. See the main [java\_binary](#java_binary) docs for details. |
 | `main_class` | String; default is `""` Name of class with `main()` method to use as entry point. If a rule uses this option, it does not need a `srcs=[...]` list. Thus, with this attribute one can make an executable from a Java library that already contains one or more `main()` methods. The value of this attribute is a class name, not a source file. The class must be available at runtime: it may be compiled by this rule (from `srcs`) or provided by direct or transitive dependencies (through `runtime_deps` or `deps`). If the class is unavailable, the binary will fail at runtime; there is no build-time check. |
 | `neverlink` | Boolean; default is `False` |
@@ -365,7 +364,7 @@ except for the addition of the `processor_class` and
 | `bootclasspath` | [Label](/versions/9.0.0/concepts/labels); default is `None` Restricted API, do not use! |
 | `generates_api` | Boolean; default is `False` This attribute marks annotation processors that generate API code. If a rule uses an API-generating annotation processor, other rules depending on it can refer to the generated code only if their compilation actions are scheduled after the generating rule. This attribute instructs Bazel to introduce scheduling constraints when --java\_header\_compilation is enabled. *WARNING: This attribute affects build performance, use it only if necessary.* |
 | `javabuilder_jvm_flags` | List of strings; default is `[]` Restricted API, do not use! |
-| `javacopts` | List of strings; default is `[]` Extra compiler options for this library. Subject to ["Make variable"](make-variables) substitution and [Bourne shell tokenization](common-definitions#sh-tokenization). These compiler options are passed to javac after the global compiler options. |
+| `javacopts` | List of strings; default is `[]` Extra compiler options for this library. Subject to ["Make variable"](/versions/9.0.0/reference/be/make-variables) substitution and [Bourne shell tokenization](/versions/9.0.0/reference/be/common-definitions#sh-tokenization). These compiler options are passed to javac after the global compiler options. |
 | `neverlink` | Boolean; default is `False` Whether this library should only be used for compilation and not at runtime. Useful if the library will be provided by the runtime environment during execution. Examples of such libraries are the IDE APIs for IDE plug-ins or `tools.jar` for anything running on a standard JDK. Note that `neverlink = True` does not prevent the compiler from inlining material from this library into compilation targets that depend on it, as permitted by the Java Language Specification (e.g., `static final` constants of `String` or of primitive types). The preferred use case is therefore when the runtime library is identical to the compilation library.  If the runtime library differs from the compilation library then you must ensure that it differs only in places that the JLS forbids compilers to inline (and that must hold for all future versions of the JLS). |
 | `output_licenses` | List of strings; default is `[]` |
 | `plugins` | List of [labels](/versions/9.0.0/concepts/labels); default is `[]` Java compiler plugins to run at compile-time. Every `java_plugin` specified in this attribute will be run whenever this rule is built. A library may also inherit plugins from dependencies that use `exported_plugins`. Resources generated by the plugin will be included in the resulting jar of this rule. |
diff --git a/versions/9.0.0/reference/be/make-variables.mdx b/versions/9.0.0/reference/be/make-variables.mdx
index fe369f00..1d078122 100644
--- a/versions/9.0.0/reference/be/make-variables.mdx
+++ b/versions/9.0.0/reference/be/make-variables.mdx
@@ -19,8 +19,7 @@ targets, and *custom* variables, which are defined in dependency targets
 and only available to targets that depend on them.
 
 The reason for the term "Make" is historical: the syntax and semantics of
-these variables were originally intended to match [GNU
-Make](https://www.gnu.org/software/make/manual/html_node/Using-Variables.html).
+these variables were originally intended to match [GNU Make](https://www.gnu.org/software/make/manual/html_node/Using-Variables.html).
 
 ## Use
 
@@ -64,8 +63,7 @@ and look at the top output lines with capital letters.
 **Toolchain option variables**
 
 * `COMPILATION_MODE`:
-  `fastbuild`, `dbg`, or `opt`. ([more
-  details](https://bazel.build/docs/user-manual#flag--compilation_mode))
+  `fastbuild`, `dbg`, or `opt`. ([more details](https://bazel.build/versions/9.0.0/docs/user-manual#flag--compilation_mode))
 
 **Path variables**
 
@@ -324,7 +322,7 @@ rare cases. If you are tempted to use them, please [contact the Bazel devs](http
 
 Rule and [toolchain](/versions/9.0.0/docs/toolchains) writers can define
 completely custom variables by returning a
-[TemplateVariableInfo](/versions/9.0.0/rules/lib/TemplateVariableInfo)
+[TemplateVariableInfo](/versions/9.0.0/rules/lib/providers/TemplateVariableInfo)
 provider. Any rules depending on these through the
 `toolchains` attribute can then read their values:
 
diff --git a/versions/9.0.0/reference/be/overview.mdx b/versions/9.0.0/reference/be/overview.mdx
index ddde99d2..26d3cf20 100644
--- a/versions/9.0.0/reference/be/overview.mdx
+++ b/versions/9.0.0/reference/be/overview.mdx
@@ -37,17 +37,17 @@ For non-native Starlark rules that ship separately from Bazel, see the list of
 
 | Language | Flags | Binary rules | Library rules | Test rules | Other rules |
 | --- | --- | --- | --- | --- | --- |
-| C / C++ |  | [cc\_binary](c-cpp#cc_binary) | [cc\_import](c-cpp#cc_import)   [cc\_library](c-cpp#cc_library)   [cc\_shared\_library](c-cpp#cc_shared_library)   [cc\_static\_library](c-cpp#cc_static_library) | [cc\_test](c-cpp#cc_test) | [cc\_toolchain](c-cpp#cc_toolchain)   [fdo\_prefetch\_hints](c-cpp#fdo_prefetch_hints)   [fdo\_profile](c-cpp#fdo_profile)   [memprof\_profile](c-cpp#memprof_profile)   [propeller\_optimize](c-cpp#propeller_optimize) |
-| Java |  | [java\_binary](java#java_binary) | [java\_import](java#java_import)   [java\_library](java#java_library) | [java\_test](java#java_test) | [java\_package\_configuration](java#java_package_configuration)   [java\_plugin](java#java_plugin)   [java\_runtime](java#java_runtime)   [java\_single\_jar](java#java_single_jar)   [java\_toolchain](java#java_toolchain) |
-| Objective-C |  |  | [objc\_import](objective-c#objc_import)   [objc\_library](objective-c#objc_library) |  |  |
-| Protocol Buffer |  |  | [cc\_proto\_library](protocol-buffer#cc_proto_library)   [java\_lite\_proto\_library](protocol-buffer#java_lite_proto_library)   [java\_proto\_library](protocol-buffer#java_proto_library)   [proto\_library](protocol-buffer#proto_library)   [py\_proto\_library](protocol-buffer#py_proto_library) |  | [proto\_lang\_toolchain](protocol-buffer#proto_lang_toolchain)   [proto\_toolchain](protocol-buffer#proto_toolchain) |
-| Python |  | [py\_binary](python#py_binary) | [py\_library](python#py_library) | [py\_test](python#py_test) | [py\_runtime](python#py_runtime) |
-| Shell |  | [sh\_binary](shell#sh_binary) | [sh\_library](shell#sh_library) | [sh\_test](shell#sh_test) |  |
+| C / C++ |  | [cc\_binary](/versions/9.0.0/reference/be/c-cpp#cc_binary) | [cc\_import](/versions/9.0.0/reference/be/c-cpp#cc_import)   [cc\_library](/versions/9.0.0/reference/be/c-cpp#cc_library)   [cc\_shared\_library](/versions/9.0.0/reference/be/c-cpp#cc_shared_library)   [cc\_static\_library](/versions/9.0.0/reference/be/c-cpp#cc_static_library) | [cc\_test](/versions/9.0.0/reference/be/c-cpp#cc_test) | [cc\_toolchain](/versions/9.0.0/reference/be/c-cpp#cc_toolchain)   [fdo\_prefetch\_hints](/versions/9.0.0/reference/be/c-cpp#fdo_prefetch_hints)   [fdo\_profile](/versions/9.0.0/reference/be/c-cpp#fdo_profile)   [memprof\_profile](/versions/9.0.0/reference/be/c-cpp#memprof_profile)   [propeller\_optimize](/versions/9.0.0/reference/be/c-cpp#propeller_optimize) |
+| Java |  | [java\_binary](/versions/9.0.0/reference/be/java#java_binary) | [java\_import](/versions/9.0.0/reference/be/java#java_import)   [java\_library](/versions/9.0.0/reference/be/java#java_library) | [java\_test](/versions/9.0.0/reference/be/java#java_test) | [java\_package\_configuration](/versions/9.0.0/reference/be/java#java_package_configuration)   [java\_plugin](/versions/9.0.0/reference/be/java#java_plugin)   [java\_runtime](/versions/9.0.0/reference/be/java#java_runtime)   [java\_single\_jar](/versions/9.0.0/reference/be/java#java_single_jar)   [java\_toolchain](/versions/9.0.0/reference/be/java#java_toolchain) |
+| Objective-C |  |  | [objc\_import](/versions/9.0.0/reference/be/objective-c#objc_import)   [objc\_library](/versions/9.0.0/reference/be/objective-c#objc_library) |  |  |
+| Protocol Buffer |  |  | [cc\_proto\_library](/versions/9.0.0/reference/be/protocol-buffer#cc_proto_library)   [java\_lite\_proto\_library](/versions/9.0.0/reference/be/protocol-buffer#java_lite_proto_library)   [java\_proto\_library](/versions/9.0.0/reference/be/protocol-buffer#java_proto_library)   [proto\_library](/versions/9.0.0/reference/be/protocol-buffer#proto_library)   [py\_proto\_library](/versions/9.0.0/reference/be/protocol-buffer#py_proto_library) |  | [proto\_lang\_toolchain](/versions/9.0.0/reference/be/protocol-buffer#proto_lang_toolchain)   [proto\_toolchain](/versions/9.0.0/reference/be/protocol-buffer#proto_toolchain) |
+| Python |  | [py\_binary](/versions/9.0.0/reference/be/python#py_binary) | [py\_library](/versions/9.0.0/reference/be/python#py_library) | [py\_test](/versions/9.0.0/reference/be/python#py_test) | [py\_runtime](/versions/9.0.0/reference/be/python#py_runtime) |
+| Shell |  | [sh\_binary](/versions/9.0.0/reference/be/shell#sh_binary) | [sh\_library](/versions/9.0.0/reference/be/shell#sh_library) | [sh\_test](/versions/9.0.0/reference/be/shell#sh_test) |  |
 
 ### Language-agnostic native rules
 
 | Family | Rules |
 | --- | --- |
-| Extra Actions | * [action\_listener](extra-actions#action_listener)* [extra\_action](extra-actions#extra_action) |
-| General | * [alias](general#alias)* [config\_setting](general#config_setting)* [filegroup](general#filegroup)* [genquery](general#genquery)* [genrule](general#genrule)* [starlark\_doc\_extract](general#starlark_doc_extract)* [test\_suite](general#test_suite) |
-| Platforms and Toolchains | * [constraint\_setting](platforms-and-toolchains#constraint_setting)* [constraint\_value](platforms-and-toolchains#constraint_value)* [platform](platforms-and-toolchains#platform)* [toolchain](platforms-and-toolchains#toolchain)* [toolchain\_type](platforms-and-toolchains#toolchain_type) |
\ No newline at end of file
+| Extra Actions | * [action\_listener](/versions/9.0.0/reference/be/extra-actions#action_listener)* [extra\_action](/versions/9.0.0/reference/be/extra-actions#extra_action) |
+| General | * [alias](/versions/9.0.0/reference/be/general#alias)* [config\_setting](/versions/9.0.0/reference/be/general#config_setting)* [filegroup](/versions/9.0.0/reference/be/general#filegroup)* [genquery](/versions/9.0.0/reference/be/general#genquery)* [genrule](/versions/9.0.0/reference/be/general#genrule)* [starlark\_doc\_extract](/versions/9.0.0/reference/be/general#starlark_doc_extract)* [test\_suite](/versions/9.0.0/reference/be/general#test_suite) |
+| Platforms and Toolchains | * [constraint\_setting](/versions/9.0.0/reference/be/platforms-and-toolchains#constraint_setting)* [constraint\_value](/versions/9.0.0/reference/be/platforms-and-toolchains#constraint_value)* [platform](/versions/9.0.0/reference/be/platforms-and-toolchains#platform)* [toolchain](/versions/9.0.0/reference/be/platforms-and-toolchains#toolchain)* [toolchain\_type](/versions/9.0.0/reference/be/platforms-and-toolchains#toolchain_type) |
\ No newline at end of file
diff --git a/versions/9.0.0/reference/be/platforms-and-toolchains.mdx b/versions/9.0.0/reference/be/platforms-and-toolchains.mdx
index b70a40a5..0e1f8e3a 100644
--- a/versions/9.0.0/reference/be/platforms-and-toolchains.mdx
+++ b/versions/9.0.0/reference/be/platforms-and-toolchains.mdx
@@ -39,7 +39,7 @@ define a platform targeting an obscure cpu architecture.
 | Attributes | |
 | --- | --- |
 | `name` | [Name](/versions/9.0.0/concepts/labels#target-names); required  A unique name for this target. |
-| `default_constraint_value` | [Name](/versions/9.0.0/concepts/labels#target-names); [nonconfigurable](common-definitions#configurable-attributes); default is `None` The label of the default value for this setting, to be used if no value is given. If this attribute is present, the `constraint_value` it points to must be defined in the same package as this `constraint_setting`. If a constraint setting has a default value, then whenever a platform does not include any constraint value for that setting, it is the same as if the platform had specified the default value. Otherwise, if there is no default value, the constraint setting is considered to be unspecified by that platform. In that case, the platform would not match against any constraint list (such as for a `config_setting`) that requires a particular value for that setting. |
+| `default_constraint_value` | [Name](/versions/9.0.0/concepts/labels#target-names); [nonconfigurable](/versions/9.0.0/reference/be/common-definitions#configurable-attributes); default is `None` The label of the default value for this setting, to be used if no value is given. If this attribute is present, the `constraint_value` it points to must be defined in the same package as this `constraint_setting`. If a constraint setting has a default value, then whenever a platform does not include any constraint value for that setting, it is the same as if the platform had specified the default value. Otherwise, if there is no default value, the constraint setting is considered to be unspecified by that platform. In that case, the platform would not match against any constraint list (such as for a `config_setting`) that requires a particular value for that setting. |
 
 ## constraint\_value
 
@@ -73,7 +73,7 @@ Platforms can then declare that they have the `mips` architecture as an alternat
 | Attributes | |
 | --- | --- |
 | `name` | [Name](/versions/9.0.0/concepts/labels#target-names); required  A unique name for this target. |
-| `constraint_setting` | [Label](/versions/9.0.0/concepts/labels); [nonconfigurable](common-definitions#configurable-attributes); required The `constraint_setting` for which this `constraint_value` is a possible choice. |
+| `constraint_setting` | [Label](/versions/9.0.0/concepts/labels); [nonconfigurable](/versions/9.0.0/reference/be/common-definitions#configurable-attributes); required The `constraint_setting` for which this `constraint_value` is a possible choice. |
 
 ## platform
 
@@ -278,12 +278,12 @@ In this example, the child platforms have the following properties:
 | Attributes | |
 | --- | --- |
 | `name` | [Name](/versions/9.0.0/concepts/labels#target-names); required  A unique name for this target. |
-| `constraint_values` | List of [labels](/versions/9.0.0/concepts/labels); [nonconfigurable](common-definitions#configurable-attributes); default is `[]` The combination of constraint choices that this platform comprises. In order for a platform to apply to a given environment, the environment must have at least the values in this list. Each `constraint_value` in this list must be for a different `constraint_setting`. For example, you cannot define a platform that requires the cpu architecture to be both `@platforms//cpu:x86_64` and `@platforms//cpu:arm`. |
-| `exec_properties` | Dictionary: String -> String; [nonconfigurable](common-definitions#configurable-attributes); default is `{}` A map of strings that affect the way actions are executed remotely. Bazel makes no attempt to interpret this, it is treated as opaque data that's forwarded via the Platform field of the [remote execution protocol](https://github.com/bazelbuild/remote-apis). This includes any data from the parent platform's `exec_properties` attributes. If the child and parent platform define the same keys, the child's values are kept. Any keys associated with a value that is an empty string are removed from the dictionary. This attribute is a full replacement for the deprecated `remote_execution_properties`. |
-| `flags` | List of strings; [nonconfigurable](common-definitions#configurable-attributes); default is `[]` A list of flags that will be enabled when this platform is used as the target platform in a configuration. Only flags that are part of the configuration can be set, such as those that can be used in transitions, or the `--define` flag. |
-| `missing_toolchain_error` | String; [nonconfigurable](common-definitions#configurable-attributes); default is `"For more information on platforms or toolchains see https://bazel.build/concepts/platforms-intro."` A custom error message that is displayed when a mandatory toolchain requirement cannot be satisfied for this target platform. Intended to point to relevant documentation users can read to understand why their toolchains are misconfigured. Not inherited from parent platforms. |
-| `parents` | List of [labels](/versions/9.0.0/concepts/labels); [nonconfigurable](common-definitions#configurable-attributes); default is `[]` The label of a `platform` target that this platform should inherit from. Although the attribute takes a list, there should be no more than one platform present. Any constraint\_settings not set directly on this platform will be found in the parent platform. See the section on [Platform Inheritance](#platform_inheritance) for details. |
-| `remote_execution_properties` | String; [nonconfigurable](common-definitions#configurable-attributes); default is `""` DEPRECATED. Please use exec\_properties attribute instead. A string used to configure a remote execution platform. Actual builds make no attempt to interpret this, it is treated as opaque data that can be used by a specific SpawnRunner. This can include data from the parent platform's "remote\_execution\_properties" attribute, by using the macro "{PARENT\_REMOTE\_EXECUTION\_PROPERTIES}". See the section on [Platform Inheritance](#platform_inheritance) for details. |
+| `constraint_values` | List of [labels](/versions/9.0.0/concepts/labels); [nonconfigurable](/versions/9.0.0/reference/be/common-definitions#configurable-attributes); default is `[]` The combination of constraint choices that this platform comprises. In order for a platform to apply to a given environment, the environment must have at least the values in this list. Each `constraint_value` in this list must be for a different `constraint_setting`. For example, you cannot define a platform that requires the cpu architecture to be both `@platforms//cpu:x86_64` and `@platforms//cpu:arm`. |
+| `exec_properties` | Dictionary: String -> String; [nonconfigurable](/versions/9.0.0/reference/be/common-definitions#configurable-attributes); default is `{}` A map of strings that affect the way actions are executed remotely. Bazel makes no attempt to interpret this, it is treated as opaque data that's forwarded via the Platform field of the [remote execution protocol](https://github.com/bazelbuild/remote-apis). This includes any data from the parent platform's `exec_properties` attributes. If the child and parent platform define the same keys, the child's values are kept. Any keys associated with a value that is an empty string are removed from the dictionary. This attribute is a full replacement for the deprecated `remote_execution_properties`. |
+| `flags` | List of strings; [nonconfigurable](/versions/9.0.0/reference/be/common-definitions#configurable-attributes); default is `[]` A list of flags that will be enabled when this platform is used as the target platform in a configuration. Only flags that are part of the configuration can be set, such as those that can be used in transitions, or the `--define` flag. |
+| `missing_toolchain_error` | String; [nonconfigurable](/versions/9.0.0/reference/be/common-definitions#configurable-attributes); default is `"For more information on platforms or toolchains see https://bazel.build/concepts/platforms-intro."` A custom error message that is displayed when a mandatory toolchain requirement cannot be satisfied for this target platform. Intended to point to relevant documentation users can read to understand why their toolchains are misconfigured. Not inherited from parent platforms. |
+| `parents` | List of [labels](/versions/9.0.0/concepts/labels); [nonconfigurable](/versions/9.0.0/reference/be/common-definitions#configurable-attributes); default is `[]` The label of a `platform` target that this platform should inherit from. Although the attribute takes a list, there should be no more than one platform present. Any constraint\_settings not set directly on this platform will be found in the parent platform. See the section on [Platform Inheritance](#platform_inheritance) for details. |
+| `remote_execution_properties` | String; [nonconfigurable](/versions/9.0.0/reference/be/common-definitions#configurable-attributes); default is `""` DEPRECATED. Please use exec\_properties attribute instead. A string used to configure a remote execution platform. Actual builds make no attempt to interpret this, it is treated as opaque data that can be used by a specific SpawnRunner. This can include data from the parent platform's "remote\_execution\_properties" attribute, by using the macro "{PARENT\_REMOTE\_EXECUTION\_PROPERTIES}". See the section on [Platform Inheritance](#platform_inheritance) for details. |
 | `required_settings` | List of [labels](/versions/9.0.0/concepts/labels); default is `[]` A list of `config_setting`s that must be satisfied by the target configuration in order for this platform to be used as an execution platform during toolchain resolution. Required settings are not inherited from parent platforms. |
 
 ## toolchain
@@ -304,12 +304,12 @@ details.
 | Attributes | |
 | --- | --- |
 | `name` | [Name](/versions/9.0.0/concepts/labels#target-names); required  A unique name for this target. |
-| `exec_compatible_with` | List of [labels](/versions/9.0.0/concepts/labels); [nonconfigurable](common-definitions#configurable-attributes); default is `[]` A list of `constraint_value`s that must be satisfied by an execution platform in order for this toolchain to be selected for a target building on that platform. |
-| `target_compatible_with` | List of [labels](/versions/9.0.0/concepts/labels); [nonconfigurable](common-definitions#configurable-attributes); default is `[]` A list of `constraint_value`s that must be satisfied by the target platform in order for this toolchain to be selected for a target building for that platform. |
+| `exec_compatible_with` | List of [labels](/versions/9.0.0/concepts/labels); [nonconfigurable](/versions/9.0.0/reference/be/common-definitions#configurable-attributes); default is `[]` A list of `constraint_value`s that must be satisfied by an execution platform in order for this toolchain to be selected for a target building on that platform. |
+| `target_compatible_with` | List of [labels](/versions/9.0.0/concepts/labels); [nonconfigurable](/versions/9.0.0/reference/be/common-definitions#configurable-attributes); default is `[]` A list of `constraint_value`s that must be satisfied by the target platform in order for this toolchain to be selected for a target building for that platform. |
 | `target_settings` | List of [labels](/versions/9.0.0/concepts/labels); default is `[]` A list of `config_setting`s that must be satisfied by the target configuration in order for this toolchain to be selected during toolchain resolution. |
 | `toolchain` | [Name](/versions/9.0.0/concepts/labels#target-names); required The target representing the actual tool or tool suite that is made available when this toolchain is selected. |
-| `toolchain_type` | [Label](/versions/9.0.0/concepts/labels); [nonconfigurable](common-definitions#configurable-attributes); required The label of a `toolchain_type` target that represents the role that this toolchain serves. |
-| `use_target_platform_constraints` | Boolean; [nonconfigurable](common-definitions#configurable-attributes); default is `False` If `True`, this toolchain behaves as if its `exec_compatible_with` and `target_compatible_with` constraints are set to those of the current target platform. `exec_compatible_with` and `target_compatible_with` must not be set in that case. |
+| `toolchain_type` | [Label](/versions/9.0.0/concepts/labels); [nonconfigurable](/versions/9.0.0/reference/be/common-definitions#configurable-attributes); required The label of a `toolchain_type` target that represents the role that this toolchain serves. |
+| `use_target_platform_constraints` | Boolean; [nonconfigurable](/versions/9.0.0/reference/be/common-definitions#configurable-attributes); default is `False` If `True`, this toolchain behaves as if its `exec_compatible_with` and `target_compatible_with` constraints are set to those of the current target platform. `exec_compatible_with` and `target_compatible_with` must not be set in that case. |
 
 ## toolchain\_type
 
@@ -353,4 +353,4 @@ bar_binary = rule(
 | Attributes | |
 | --- | --- |
 | `name` | [Name](/versions/9.0.0/concepts/labels#target-names); required  A unique name for this target. |
-| `no_match_error` | String; [nonconfigurable](common-definitions#configurable-attributes); default is `""` A custom error message to display when no matching toolchain is found for this type. |
\ No newline at end of file
+| `no_match_error` | String; [nonconfigurable](/versions/9.0.0/reference/be/common-definitions#configurable-attributes); default is `""` A custom error message to display when no matching toolchain is found for this type. |
\ No newline at end of file
diff --git a/versions/9.0.0/reference/be/protocol-buffer.mdx b/versions/9.0.0/reference/be/protocol-buffer.mdx
index 42149892..672f5e1c 100644
--- a/versions/9.0.0/reference/be/protocol-buffer.mdx
+++ b/versions/9.0.0/reference/be/protocol-buffer.mdx
@@ -22,7 +22,7 @@ cc_proto_library(name, deps, aspect_hints, compatible_with, deprecation, exec_co
 
 `cc_proto_library` generates C++ code from `.proto` files.
 
-`deps` must point to [`proto_library`](protocol-buffer#proto_library) rules.
+`deps` must point to [`proto_library`](/versions/9.0.0/reference/be/protocol-buffer#proto_library) rules.
 
 Example:
 
@@ -47,7 +47,7 @@ proto_library(
 | Attributes | |
 | --- | --- |
 | `name` | [Name](/versions/9.0.0/concepts/labels#target-names); required  A unique name for this target. |
-| `deps` | List of [labels](/versions/9.0.0/concepts/labels); default is `[]` The list of [`proto_library`](protocol-buffer#proto_library) rules to generate C++ code for. |
+| `deps` | List of [labels](/versions/9.0.0/concepts/labels); default is `[]` The list of [`proto_library`](/versions/9.0.0/reference/be/protocol-buffer#proto_library) rules to generate C++ code for. |
 
 ## java\_lite\_proto\_library
 
@@ -59,7 +59,7 @@ java_lite_proto_library(name, deps, aspect_hints, compatible_with, deprecation,
 
 `java_lite_proto_library` generates Java code from `.proto` files.
 
-`deps` must point to [`proto_library`](protocol-buffer#proto_library) rules.
+`deps` must point to [`proto_library`](/versions/9.0.0/reference/be/protocol-buffer#proto_library) rules.
 
 Example:
 
@@ -84,7 +84,7 @@ proto_library(
 | Attributes | |
 | --- | --- |
 | `name` | [Name](/versions/9.0.0/concepts/labels#target-names); required  A unique name for this target. |
-| `deps` | List of [labels](/versions/9.0.0/concepts/labels); default is `[]` The list of [`proto_library`](protocol-buffer#proto_library) rules to generate Java code for. |
+| `deps` | List of [labels](/versions/9.0.0/concepts/labels); default is `[]` The list of [`proto_library`](/versions/9.0.0/reference/be/protocol-buffer#proto_library) rules to generate Java code for. |
 
 ## java\_proto\_library
 
@@ -96,7 +96,7 @@ java_proto_library(name, deps, aspect_hints, compatible_with, deprecation, exec_
 
 `java_proto_library` generates Java code from `.proto` files.
 
-`deps` must point to [`proto_library`](protocol-buffer#proto_library) rules.
+`deps` must point to [`proto_library`](/versions/9.0.0/reference/be/protocol-buffer#proto_library) rules.
 
 Example:
 
@@ -121,7 +121,7 @@ proto_library(
 | Attributes | |
 | --- | --- |
 | `name` | [Name](/versions/9.0.0/concepts/labels#target-names); required  A unique name for this target. |
-| `deps` | List of [labels](/versions/9.0.0/concepts/labels); default is `[]` The list of [`proto_library`](protocol-buffer#proto_library) rules to generate Java code for. |
+| `deps` | List of [labels](/versions/9.0.0/concepts/labels); default is `[]` The list of [`proto_library`](/versions/9.0.0/reference/be/protocol-buffer#proto_library) rules to generate Java code for. |
 
 ## proto\_library
 
diff --git a/versions/9.0.0/reference/be/python.mdx b/versions/9.0.0/reference/be/python.mdx
index 1149887d..2f669e87 100644
--- a/versions/9.0.0/reference/be/python.mdx
+++ b/versions/9.0.0/reference/be/python.mdx
@@ -32,7 +32,7 @@ py_binary(name, deps, srcs, data, args, aspect_hints, compatible_with, config_se
 | `legacy_create_init` | Integer; default is `-1` Whether to implicitly create empty `\_\_init\_\_.py` files in the runfiles tree. These are created in every directory containing Python source code or shared libraries, and every parent directory of those directories, excluding the repo root directory. The default, `-1` (auto), means true unless `--incompatible\_default\_to\_explicit\_init\_py` is used. If false, the user is responsible for creating (possibly empty) `\_\_init\_\_.py` files and adding them to the `srcs` of Python targets as required. |
 | `main` | [Label](/versions/9.0.0/concepts/labels); default is `None` Optional; the name of the source file that is the main entry point of the application. This file must also be listed in `srcs`. If left unspecified, `name`, with `.py` appended, is used instead. If `name` does not match any filename in `srcs`, `main` must be specified. This is mutually exclusive with {obj}`main\_module`. |
 | `main_module` | String; default is `""` Module name to execute as the main program. When set, `srcs` is not required, and it is assumed the module is provided by a dependency. See https://docs.python.org/3/using/cmdline.html#cmdoption-m for more information about running modules as the main program. This is mutually exclusive with {obj}`main`. :::{versionadded} 1.3.0 ::: :::{versionchanged} 1.7.0 Support added for {obj}`--bootstrap\_impl=system\_python`. ::: |
-| `precompile` | String; default is `"inherit"` Whether py source files \*\*for this target\*\* should be precompiled. Values: \* `inherit`: Allow the downstream binary decide if precompiled files are used. \* `enabled`: Compile Python source files at build time. \* `disabled`: Don't compile Python source files at build time. :::{seealso} \* The {flag}`--precompile` flag, which can override this attribute in some cases and will affect all targets when building. \* The {obj}`pyc\_collection` attribute for transitively enabling precompiling on a per-target basis. \* The [Precompiling](precompiling) docs for a guide about using precompiling. ::: |
+| `precompile` | String; default is `"inherit"` Whether py source files \*\*for this target\*\* should be precompiled. Values: \* `inherit`: Allow the downstream binary decide if precompiled files are used. \* `enabled`: Compile Python source files at build time. \* `disabled`: Don't compile Python source files at build time. :::{seealso} \* The {flag}`--precompile` flag, which can override this attribute in some cases and will affect all targets when building. \* The {obj}`pyc\_collection` attribute for transitively enabling precompiling on a per-target basis. \* The [Precompiling](/versions/9.0.0/reference/be/precompiling) docs for a guide about using precompiling. ::: |
 | `precompile_invalidation_mode` | String; default is `"auto"` How precompiled files should be verified to be up-to-date with their associated source files. Possible values are: \* `auto`: The effective value will be automatically determined by other build settings. \* `checked\_hash`: Use the pyc file if the hash of the source file matches the hash recorded in the pyc file. This is most useful when working with code that you may modify. \* `unchecked\_hash`: Always use the pyc file; don't check the pyc's hash against the source file. This is most useful when the code won't be modified. For more information on pyc invalidation modes, see https://docs.python.org/3/library/py\_compile.html#py\_compile.PycInvalidationMode |
 | `precompile_optimize_level` | Integer; default is `0` The optimization level for precompiled files. For more information about optimization levels, see the `compile()` function's `optimize` arg docs at https://docs.python.org/3/library/functions.html#compile NOTE: The value `-1` means "current interpreter", which will be the interpreter used \_at build time when pycs are generated\_, not the interpreter used at runtime when the code actually runs. |
 | `precompile_source_retention` | String; default is `"inherit"` Determines, when a source file is compiled, if the source file is kept in the resulting output or not. Valid values are: \* `inherit`: Inherit the value from the {flag}`--precompile\_source\_retention` flag. \* `keep\_source`: Include the original Python source. \* `omit\_source`: Don't include the original py source. |
@@ -73,7 +73,7 @@ Source files are no longer added to the runfiles directly.
 | `distribs` | List of strings; default is `[]` |
 | `experimental_venvs_site_packages` | [Label](/versions/9.0.0/concepts/labels); default is `None` \*\*INTERNAL ATTRIBUTE. SHOULD ONLY BE SET BY rules\_python-INTERNAL CODE.\*\* :::{include} /\_includes/experimental\_api.md ::: A flag that decides whether the library should treat its sources as a site-packages layout. When the flag is `yes`, then the `srcs` files are treated as a site-packages layout that is relative to the `imports` attribute. The `imports` attribute can have only a single element. It is a repo-relative runfiles path. For example, in the `my/pkg/BUILD.bazel` file, given `srcs=["site-packages/foo/bar.py"]`, specifying `imports=["my/pkg/site-packages"]` means `foo/bar.py` is the file path under the binary's venv site-packages directory that should be made available (i.e. `import foo.bar` will work). `\_\_init\_\_.py` files are treated specially to provide basic support for [implicit namespace packages]( https://packaging.python.org/en/latest/guides/packaging-namespace-packages/#native-namespace-packages). However, the \*content\* of the files cannot be taken into account, merely their presence or absence. Stated another way: [pkgutil-style namespace packages]( https://packaging.python.org/en/latest/guides/packaging-namespace-packages/#pkgutil-style-namespace-packages) won't be understood as namespace packages; they'll be seen as regular packages. This will likely lead to conflicts with other targets that contribute to the namespace. :::{seealso} This attributes populates {obj}`PyInfo.venv\_symlinks`. ::: :::{versionadded} 1.4.0 ::: :::{versionchanged} 1.5.0 The topological order has been removed and if 2 different versions of the same PyPI package are observed, the behaviour has no guarantees except that it is deterministic and that only one package version will be included. ::: |
 | `imports` | List of strings; default is `[]` List of import directories to be added to the PYTHONPATH. Subject to "Make variable" substitution. These import directories will be added for this rule and all rules that depend on it (note: not the rules this rule depends on. Each directory will be added to `PYTHONPATH` by `py\_binary` rules that depend on this rule. The strings are repo-runfiles-root relative, Absolute paths (paths that start with `/`) and paths that references a path above the execution root are not allowed and will result in an error. |
-| `precompile` | String; default is `"inherit"` Whether py source files \*\*for this target\*\* should be precompiled. Values: \* `inherit`: Allow the downstream binary decide if precompiled files are used. \* `enabled`: Compile Python source files at build time. \* `disabled`: Don't compile Python source files at build time. :::{seealso} \* The {flag}`--precompile` flag, which can override this attribute in some cases and will affect all targets when building. \* The {obj}`pyc\_collection` attribute for transitively enabling precompiling on a per-target basis. \* The [Precompiling](precompiling) docs for a guide about using precompiling. ::: |
+| `precompile` | String; default is `"inherit"` Whether py source files \*\*for this target\*\* should be precompiled. Values: \* `inherit`: Allow the downstream binary decide if precompiled files are used. \* `enabled`: Compile Python source files at build time. \* `disabled`: Don't compile Python source files at build time. :::{seealso} \* The {flag}`--precompile` flag, which can override this attribute in some cases and will affect all targets when building. \* The {obj}`pyc\_collection` attribute for transitively enabling precompiling on a per-target basis. \* The [Precompiling](/versions/9.0.0/reference/be/precompiling) docs for a guide about using precompiling. ::: |
 | `precompile_invalidation_mode` | String; default is `"auto"` How precompiled files should be verified to be up-to-date with their associated source files. Possible values are: \* `auto`: The effective value will be automatically determined by other build settings. \* `checked\_hash`: Use the pyc file if the hash of the source file matches the hash recorded in the pyc file. This is most useful when working with code that you may modify. \* `unchecked\_hash`: Always use the pyc file; don't check the pyc's hash against the source file. This is most useful when the code won't be modified. For more information on pyc invalidation modes, see https://docs.python.org/3/library/py\_compile.html#py\_compile.PycInvalidationMode |
 | `precompile_optimize_level` | Integer; default is `0` The optimization level for precompiled files. For more information about optimization levels, see the `compile()` function's `optimize` arg docs at https://docs.python.org/3/library/functions.html#compile NOTE: The value `-1` means "current interpreter", which will be the interpreter used \_at build time when pycs are generated\_, not the interpreter used at runtime when the code actually runs. |
 | `precompile_source_retention` | String; default is `"inherit"` Determines, when a source file is compiled, if the source file is kept in the resulting output or not. Valid values are: \* `inherit`: Inherit the value from the {flag}`--precompile\_source\_retention` flag. \* `keep\_source`: Include the original Python source. \* `omit\_source`: Don't include the original py source. |
@@ -104,7 +104,7 @@ py_test(name, deps, srcs, data, args, aspect_hints, compatible_with, config_sett
 | `legacy_create_init` | Integer; default is `-1` Whether to implicitly create empty `\_\_init\_\_.py` files in the runfiles tree. These are created in every directory containing Python source code or shared libraries, and every parent directory of those directories, excluding the repo root directory. The default, `-1` (auto), means true unless `--incompatible\_default\_to\_explicit\_init\_py` is used. If false, the user is responsible for creating (possibly empty) `\_\_init\_\_.py` files and adding them to the `srcs` of Python targets as required. |
 | `main` | [Label](/versions/9.0.0/concepts/labels); default is `None` Optional; the name of the source file that is the main entry point of the application. This file must also be listed in `srcs`. If left unspecified, `name`, with `.py` appended, is used instead. If `name` does not match any filename in `srcs`, `main` must be specified. This is mutually exclusive with {obj}`main\_module`. |
 | `main_module` | String; default is `""` Module name to execute as the main program. When set, `srcs` is not required, and it is assumed the module is provided by a dependency. See https://docs.python.org/3/using/cmdline.html#cmdoption-m for more information about running modules as the main program. This is mutually exclusive with {obj}`main`. :::{versionadded} 1.3.0 ::: :::{versionchanged} 1.7.0 Support added for {obj}`--bootstrap\_impl=system\_python`. ::: |
-| `precompile` | String; default is `"inherit"` Whether py source files \*\*for this target\*\* should be precompiled. Values: \* `inherit`: Allow the downstream binary decide if precompiled files are used. \* `enabled`: Compile Python source files at build time. \* `disabled`: Don't compile Python source files at build time. :::{seealso} \* The {flag}`--precompile` flag, which can override this attribute in some cases and will affect all targets when building. \* The {obj}`pyc\_collection` attribute for transitively enabling precompiling on a per-target basis. \* The [Precompiling](precompiling) docs for a guide about using precompiling. ::: |
+| `precompile` | String; default is `"inherit"` Whether py source files \*\*for this target\*\* should be precompiled. Values: \* `inherit`: Allow the downstream binary decide if precompiled files are used. \* `enabled`: Compile Python source files at build time. \* `disabled`: Don't compile Python source files at build time. :::{seealso} \* The {flag}`--precompile` flag, which can override this attribute in some cases and will affect all targets when building. \* The {obj}`pyc\_collection` attribute for transitively enabling precompiling on a per-target basis. \* The [Precompiling](/versions/9.0.0/reference/be/precompiling) docs for a guide about using precompiling. ::: |
 | `precompile_invalidation_mode` | String; default is `"auto"` How precompiled files should be verified to be up-to-date with their associated source files. Possible values are: \* `auto`: The effective value will be automatically determined by other build settings. \* `checked\_hash`: Use the pyc file if the hash of the source file matches the hash recorded in the pyc file. This is most useful when working with code that you may modify. \* `unchecked\_hash`: Always use the pyc file; don't check the pyc's hash against the source file. This is most useful when the code won't be modified. For more information on pyc invalidation modes, see https://docs.python.org/3/library/py\_compile.html#py\_compile.PycInvalidationMode |
 | `precompile_optimize_level` | Integer; default is `0` The optimization level for precompiled files. For more information about optimization levels, see the `compile()` function's `optimize` arg docs at https://docs.python.org/3/library/functions.html#compile NOTE: The value `-1` means "current interpreter", which will be the interpreter used \_at build time when pycs are generated\_, not the interpreter used at runtime when the code actually runs. |
 | `precompile_source_retention` | String; default is `"inherit"` Determines, when a source file is compiled, if the source file is kept in the resulting output or not. Valid values are: \* `inherit`: Inherit the value from the {flag}`--precompile\_source\_retention` flag. \* `keep\_source`: Include the original Python source. \* `omit\_source`: Don't include the original py source. |
diff --git a/versions/9.0.0/reference/glossary.mdx b/versions/9.0.0/reference/glossary.mdx
index 8493e05e..9a2b51f2 100644
--- a/versions/9.0.0/reference/glossary.mdx
+++ b/versions/9.0.0/reference/glossary.mdx
@@ -21,8 +21,7 @@ An in-memory graph of [actions](#action) and the [artifacts](#artifact) that
 these actions read and generate. The graph might include artifacts that exist as
 source files (for example, in the file system) as well as generated
 intermediate/final artifacts that are not mentioned in `BUILD` files. Produced
-during the [analysis phase](#analysis-phase) and used during the [execution
-phase](#execution-phase).
+during the [analysis phase](#analysis-phase) and used during the [execution phase](#execution-phase).
 
 ### Action graph query (aquery) {#action-graph-query}
 A [query](#query-concept) tool that can query over build [actions](#action).
@@ -37,8 +36,7 @@ invalidate individual actions deterministically.
 
 ### Analysis phase {#analysis-phase}
 The second phase of a build. Processes the [target graph](#target-graph)
-specified in [`BUILD` files](#build-file) to produce an in-memory [action
-graph](#action-graph) that determines the order of actions to run during the
+specified in [`BUILD` files](#build-file) to produce an in-memory [action graph](#action-graph) that determines the order of actions to run during the
 [execution phase](#execution-phase). This is the phase in which rule
 implementations are evaluated.
 
@@ -81,8 +79,7 @@ target's source files, dependencies, and custom compiler options. The particular
 attributes available for a given target depend on its rule type.
 
 ### .bazelrc {#bazelrc}
-Bazel’s configuration file used to change the default values for [startup
-flags](#startup-flags) and [command flags](#command-flags), and to define common
+Bazel’s configuration file used to change the default values for [startup flags](#startup-flags) and [command flags](#command-flags), and to define common
 groups of options that can then be set together on the Bazel command line using
 a `--config` flag. Bazel can combine settings from multiple bazelrc files
 (systemwide, per-workspace, per-user, or from a custom location), and a
@@ -108,8 +105,7 @@ directory.
 
 ### .bzl File {#bzl-file}
 A file that defines rules, [macros](#macro), and constants written in
-[Starlark](#starlark). These can then be imported into [`BUILD`
-files](#build-file) using the `load()` function.
+[Starlark](#starlark). These can then be imported into [`BUILD` files](#build-file) using the `load()` function.
 
 {/* TODO: ### Build event protocol */}
 
@@ -117,8 +113,7 @@ files](#build-file) using the `load()` function.
 
 ### Build graph {#build-graph}
 The dependency graph that Bazel constructs and traverses to perform a build.
-Includes nodes like [targets](#target), [configured
-targets](#configured-target), [actions](#action), and [artifacts](#artifact). A
+Includes nodes like [targets](#target), [configured targets](#configured-target), [actions](#action), and [artifacts](#artifact). A
 build is considered complete when all [artifacts](#artifact) on which a set of
 requested targets depend are verified as up-to-date.
 
@@ -158,8 +153,7 @@ graphs and restart the [analysis phase](#analysis-phase).
 ### Configuration {#configuration}
 Information outside of [rule](#rule) definitions that impacts how rules generate
 [actions](#action). Every build has at least one configuration specifying the
-target platform, action environment variables, and command-line [build
-flags](#command-flags). [Transitions](#transition) may create additional
+target platform, action environment variables, and command-line [build flags](#command-flags). [Transitions](#transition) may create additional
 configurations, such as for host tools or cross-compilation.
 
 **See also:** [Configurations](/versions/9.0.0/extending/rules#configurations)
@@ -174,8 +168,7 @@ configuration of `//:c` because changing `--javacopt` unnecessarily breaks C++
 build cacheability.
 
 ### Configured query (cquery) {#configured-query}
-A [query](#query-concept) tool that queries over [configured
-targets](#configured-target) (after the [analysis phase](#analysis-phase)
+A [query](#query-concept) tool that queries over [configured targets](#configured-target) (after the [analysis phase](#analysis-phase)
 completes). This means `select()` and [build flags](#command-flags) (such as
 `--platforms`) are accurately reflected in the results.
 
@@ -191,8 +184,7 @@ build, it has two configured targets: `` and ``.
 ### Correctness {#correctness}
 A build is correct when its output faithfully reflects the state of its
 transitive inputs. To achieve correct builds, Bazel strives to be
-[hermetic](#hermeticity), reproducible, and making [build
-analysis](#analysis-phase) and [action execution](#execution-phase)
+[hermetic](#hermeticity), reproducible, and making [build analysis](#analysis-phase) and [action execution](#execution-phase)
 deterministic.
 
 ### Dependency {#dependency}
@@ -234,8 +226,7 @@ compilation). A dynamic execution strategy can provide the best possible
 incremental and clean build times.
 
 ### Execution phase {#execution-phase}
-The third phase of a build. Executes the [actions](#action) in the [action
-graph](#action-graph) created during the [analysis phase](#analysis-phase).
+The third phase of a build. Executes the [actions](#action) in the [action graph](#action-graph) created during the [analysis phase](#analysis-phase).
 These actions invoke executables (compilers, scripts) to read and write
 [artifacts](#artifact). *Spawn strategies* control how these actions are
 executed: locally, remotely, dynamically, sandboxed, docker, and so on.
@@ -285,8 +276,7 @@ syntax may be omitted.
 The first phase of a build where Bazel executes [`BUILD` files](#build-file) to
 create [packages](#package). [Macros](#macro) and certain functions like
 `glob()` are evaluated in this phase. Interleaved with the second phase of the
-build, the [analysis phase](#analysis-phase), to build up a [target
-graph](#target-graph).
+build, the [analysis phase](#analysis-phase), to build up a [target graph](#target-graph).
 
 ### Legacy macro {#legacy-macro}
 A flavor of [macro](#macro) which is declared as an ordinary
@@ -336,8 +326,7 @@ Module metadata is hosted in Bazel registries.
 
 ### Module Extension {#module-extension}
 A piece of logic that can be run to generate [repos](#repository) by reading
-inputs from across the [module](#module) dependency graph and invoking [repo
-rules](#repository-rule). Module extensions have capabilities similar to repo
+inputs from across the [module](#module) dependency graph and invoking [repo rules](#repository-rule). Module extensions have capabilities similar to repo
 rules, allowing them to access the internet, perform file I/O, and so on.
 
 **See also:** [Module extensions](/versions/9.0.0/external/extension)
@@ -350,8 +339,7 @@ example, `native.cc_library` or `native.java_library`). User-defined rules
 
 ### Output base {#output-base}
 A [workspace](#workspace)-specific directory to store Bazel output files. Used
-to separate outputs from the *workspace*'s source tree (the [main
-repo](#repository)). Located in the [output user root](#output-user-root).
+to separate outputs from the *workspace*'s source tree (the [main repo](#repository)). Located in the [output user root](#output-user-root).
 
 ### Output groups {#output-groups}
 A group of files that is expected to be built when Bazel finishes building a
@@ -406,8 +394,7 @@ query variants: [query](#query-command), [cquery](#configured-query), and
 [aquery](#action-graph-query).
 
 ### query (command) {#query-command}
-A [query](#query-concept) tool that operates over the build's post-[loading
-phase](#loading-phase) [target graph](#target-graph). This is relatively fast,
+A [query](#query-concept) tool that operates over the build's post-[loading phase](#loading-phase) [target graph](#target-graph). This is relatively fast,
 but can't analyze the effects of `select()`, [build flags](#command-flags),
 [artifacts](#artifact), or build [actions](#action).
 
@@ -425,8 +412,7 @@ repo; multiple such files can coexist in a directory.
 The *main repo* is the repo in which the current Bazel command is being run.
 
 *External repos* are defined by specifying [modules](#module) in `MODULE.bazel`
-files, or invoking [repo rules](#repository-rule) in [module
-extensions](#module-extension). They can be fetched on demand to a predetermined
+files, or invoking [repo rules](#repository-rule) in [module extensions](#module-extension). They can be fetched on demand to a predetermined
 "magical" location on disk.
 
 Each repo has a unique, constant *canonical* name, and potentially different
@@ -437,8 +423,7 @@ Each repo has a unique, constant *canonical* name, and potentially different
 ### Repository cache {#repo-cache}
 A shared content-addressable cache of files downloaded by Bazel for builds,
 shareable across [workspaces](#workspace). Enables offline builds after the
-initial download. Commonly used to cache files downloaded through [repository
-rules](#repository-rule) like `http_archive` and repository rule APIs like
+initial download. Commonly used to cache files downloaded through [repository rules](#repository-rule) like `http_archive` and repository rule APIs like
 `repository_ctx.download`. Files are cached only if their SHA-256 checksums are
 specified for the download.
 
@@ -472,8 +457,7 @@ Rules are instantiated to produce rule targets in the
 [loading phase](#loading-phase). In the [analysis phase](#analysis-phase) rule
 targets communicate information to their downstream dependencies in the form of
 [providers](#provider), and register [actions](#action) describing how to
-generate their output artifacts. These actions are run in the [execution
-phase](#execution-phase).
+generate their output artifacts. These actions are run in the [execution phase](#execution-phase).
 
 Note: Historically the term "rule" has been used to refer to a rule target.
 This usage was inherited from tools like Make, but causes confusion and should
@@ -517,8 +501,7 @@ support the stamp attribute.
 ### Starlark {#starlark}
 The extension language for writing [rules](/versions/9.0.0/extending/rules) and [macros](#macro). A
 restricted subset of Python (syntactically and grammatically) aimed for the
-purpose of configuration, and for better performance. Uses the [`.bzl`
-file](#bzl-file) extension. [`BUILD` files](#build-file) use an even more
+purpose of configuration, and for better performance. Uses the [`.bzl` file](#bzl-file) extension. [`BUILD` files](#build-file) use an even more
 restricted version of Starlark (such as no `def` function definitions), formerly
 known as Skylark.
 
@@ -549,8 +532,7 @@ An object that is defined in a [`BUILD` file](#build-file) and identified by a
 [label](#label). Targets represent the buildable units of a workspace from
 the perspective of the end user.
 
-A target that is declared by instantiating a [rule](#rule) is called a [rule
-target](#rule-target). Depending on the rule, these may be runnable (like
+A target that is declared by instantiating a [rule](#rule) is called a [rule target](#rule-target). Depending on the rule, these may be runnable (like
 `cc_binary`) or testable (like `cc_test`). Rule targets typically depend on
 other targets via their [attributes](#attribute) (such as `deps`); these
 dependencies form the basis of the [target graph](#target-graph).
@@ -561,14 +543,11 @@ within a `BUILD` file. As a special case, the `BUILD` file of any package is
 always considered a source file target in that package.
 
 Targets are discovered during the [loading phase](#loading-phase). During the
-[analysis phase](#analysis-phase), targets are associated with [build
-configurations](#configuration) to form [configured
-targets](#configured-target).
+[analysis phase](#analysis-phase), targets are associated with [build configurations](#configuration) to form [configured targets](#configured-target).
 
 ### Target graph {#target-graph}
 An in-memory graph of [targets](#target) and their dependencies. Produced during
-the [loading phase](#loading-phase) and used as an input to the [analysis
-phase](#analysis-phase).
+the [loading phase](#loading-phase) and used as an input to the [analysis phase](#analysis-phase).
 
 ### Target pattern {#target-pattern}
 A way to specify a group of [targets](#target) on the command line. Commonly
@@ -581,8 +560,7 @@ packages recursively from the root of the [workspace](#workspace).
 Rule [targets](#target) instantiated from test rules, and therefore contains a
 test executable. A return code of zero from the completion of the executable
 indicates test success. The exact contract between Bazel and tests (such as test
-environment variables, test result collection methods) is specified in the [Test
-Encyclopedia](/versions/9.0.0/reference/test-encyclopedia).
+environment variables, test result collection methods) is specified in the [Test Encyclopedia](/versions/9.0.0/reference/test-encyclopedia).
 
 ### Toolchain {#toolchain}
 A set of tools to build outputs for a language. Typically, a toolchain includes
@@ -596,8 +574,7 @@ A build [target](#target) is top-level if it’s requested on the Bazel command
 line. For example, if `//:foo` depends on `//:bar`, and `bazel build //:foo` is
 called, then for this build, `//:foo` is top-level, and `//:bar` isn’t
 top-level, although both targets will need to be built. An important difference
-between top-level and non-top-level targets is that [command
-flags](#command-flags) set on the Bazel command line (or via
+between top-level and non-top-level targets is that [command flags](#command-flags) set on the Bazel command line (or via
 [.bazelrc](#bazelrc)) will set the [configuration](#configuration) for top-level
 targets, but might be modified by a [transition](#transition) for non-top-level
 targets.
@@ -628,8 +605,7 @@ or `.bzl` file may load a given `.bzl` file. Without context, usually
 **See also:** [Visibility documentation](/versions/9.0.0/concepts/visibility)
 
 ### Workspace {#workspace}
-The environment shared by all Bazel commands run from the same [main
-repository](#repository).
+The environment shared by all Bazel commands run from the same [main repository](#repository).
 
 Note that historically the concepts of "repository" and "workspace" have been
 conflated; the term "workspace" has often been used to refer to the main
diff --git a/versions/9.0.0/reference/test-encyclopedia.mdx b/versions/9.0.0/reference/test-encyclopedia.mdx
index f04cd672..dc8baddd 100644
--- a/versions/9.0.0/reference/test-encyclopedia.mdx
+++ b/versions/9.0.0/reference/test-encyclopedia.mdx
@@ -685,8 +685,7 @@ mark it as having failed.
 ## Execution platform {#execution-platform}
 The [execution platform](/versions/9.0.0/extending/platforms) for a test action is determined
 via [toolchain resolution](/versions/9.0.0/extending/toolchains#toolchain-resolution), just
-like for any other action. Each test rule has an implicitly defined [
-`test` exec group](/versions/9.0.0/extending/exec-groups#exec-groups-for-native-rules) that,
+like for any other action. Each test rule has an implicitly defined [`test` exec group](/versions/9.0.0/extending/exec-groups#exec-groups-for-native-rules) that,
 unless overridden, has a mandatory toolchain requirement on
 `@bazel_tools//tools/test:default_test_toolchain_type`.
 
@@ -726,8 +725,7 @@ a default toolchain for it.
 ## Tag conventions {#tag-conventions}
 Some tags in the test rules have a special meaning.
 See also the
-[Bazel Build Encyclopedia on the `tags` attribute]
-(/reference/be/common-definitions#common.tags).
+[Bazel Build Encyclopedia on the `tags` attribute](/versions/9.0.0/reference/be/common-definitions#common.tags).
 
 
diff --git a/versions/9.0.0/release/backward-compatibility.mdx b/versions/9.0.0/release/backward-compatibility.mdx
index f11f07f2..0562f0d6 100644
--- a/versions/9.0.0/release/backward-compatibility.mdx
+++ b/versions/9.0.0/release/backward-compatibility.mdx
@@ -6,11 +6,9 @@ This page provides information about how to handle backward compatibility,
 including migrating from one release to another and how to communicate
 incompatible changes.
 
-Bazel is evolving. Minor versions released as part of an [LTS major
-version](/versions/9.0.0/release#bazel-versioning) are fully backward-compatible. New major LTS
+Bazel is evolving. Minor versions released as part of an [LTS major version](/versions/9.0.0/release#bazel-versioning) are fully backward-compatible. New major LTS
 releases may contain incompatible changes that require some migration effort.
-For more information about Bazel's release model, please check out the [Release
-Model](/versions/9.0.0/release) page.
+For more information about Bazel's release model, please check out the [Release Model](/versions/9.0.0/release) page.
 
 ## Summary {#summary}
 
@@ -59,8 +57,7 @@ available.
 ## Communicating incompatible changes {#communicating-incompatible-changes}
 
 The primary source of information about incompatible changes are GitHub issues
-marked with an ["incompatible-change"
-label](https://github.com/bazelbuild/bazel/issues?q=label%3Aincompatible-change).
+marked with an ["incompatible-change" label](https://github.com/bazelbuild/bazel/issues?q=label%3Aincompatible-change).
 
 For every incompatible change, the issue specifies the following:
 
diff --git a/versions/9.0.0/release/index.mdx b/versions/9.0.0/release/index.mdx
index 95d58c35..4d6173f1 100644
--- a/versions/9.0.0/release/index.mdx
+++ b/versions/9.0.0/release/index.mdx
@@ -2,8 +2,7 @@
 title: 'Release Model'
 ---
 
-As announced in [the original blog
-post](https://blog.bazel.build/2020/11/10/long-term-support-release.html), Bazel
+As announced in [the original blog post](https://blog.bazel.build/2020/11/10/long-term-support-release.html), Bazel
 4.0 and higher versions provides support for two release tracks: rolling
 releases and long term support (LTS) releases. This page covers the latest
 information about Bazel's release model.
@@ -19,8 +18,7 @@ information about Bazel's release model.
 | Bazel 5 | Deprecated | [5.4.1](https://github.com/bazelbuild/bazel/releases/tag/5.4.1) | Jan 2025 |
 | Bazel 4 | Deprecated | [4.2.4](https://github.com/bazelbuild/bazel/releases/tag/4.2.4) | Jan 2024 |
 
-All Bazel LTS releases can be found on the [release
-page](https://github.com/bazelbuild/bazel/releases) on GitHub.
+All Bazel LTS releases can be found on the [release page](https://github.com/bazelbuild/bazel/releases) on GitHub.
 
 Note: Bazel version older than Bazel 5 are no longer supported, Bazel users are
 recommended to upgrade to the latest LTS release or use rolling releases if you
@@ -28,8 +26,7 @@ want to keep up with the latest changes at HEAD.
 
 ## Release versioning {#bazel-versioning}
 
-Bazel uses a _major.minor.patch_ [Semantic
-Versioning](https://semver.org/) scheme.
+Bazel uses a _major.minor.patch_ [Semantic Versioning](https://semver.org/) scheme.
 
 *   A _major release_ contains features that are not backward compatible with
     the previous release. Each major Bazel version is an LTS release.
@@ -72,8 +69,7 @@ Bazel regularly publish releases for two release tracks.
     release.
 *   Rolling releases can ship incompatible changes. Incompatible flags are
     recommended for major breaking changes, rolling out incompatible changes
-    should follow our [backward compatibility
-    policy](/versions/9.0.0/release/backward-compatibility).
+    should follow our [backward compatibility policy](/versions/9.0.0/release/backward-compatibility).
 
 ### LTS releases {#lts-releases}
 
@@ -89,8 +85,7 @@ Bazel regularly publish releases for two release tracks.
 *   A Bazel LTS release enters the Deprecated stage after being in ​​the
     Maintenance stage for 2 years.
 
-For planned releases, please check our [release
-issues](https://github.com/bazelbuild/bazel/issues?q=is%3Aopen+is%3Aissue+label%3Arelease)
+For planned releases, please check our [release issues](https://github.com/bazelbuild/bazel/issues?q=is%3Aopen+is%3Aissue+label%3Arelease)
 on Github.
 
 ## Release procedure & policies {#release-procedure-policies}
@@ -153,8 +148,7 @@ For LTS releases, the procedure and policies below are followed:
 1.  Identify release blockers and fix issues found on the release branch.
     *   The release branch is tested with the same test suite in
         [postsubmit](https://buildkite.com/bazel/bazel-bazel) and
-        [downstream test pipeline]
-        (https://buildkite.com/bazel/bazel-at-head-plus-downstream)
+        [downstream test pipeline](https://buildkite.com/bazel/bazel-at-head-plus-downstream)
         on Bazel CI. The Bazel team monitors testing results of the release
         branch and fixes any regressions found.
 1.  Create a new release candidate from the release branch when all known
@@ -210,5 +204,4 @@ feature.
 ## Rule compatibility {#rule-compatibility}
 
 If you are a rule authors and want to maintain compatibility with different
-Bazel versions, please check out the [Rule
-Compatibility](/versions/9.0.0/release/rule-compatibility) page.
+Bazel versions, please check out the [Rule Compatibility](/versions/9.0.0/release/rule-compatibility) page.
diff --git a/versions/9.0.0/release/rule-compatibility.mdx b/versions/9.0.0/release/rule-compatibility.mdx
index 140cdfd2..a5be3b0c 100644
--- a/versions/9.0.0/release/rule-compatibility.mdx
+++ b/versions/9.0.0/release/rule-compatibility.mdx
@@ -53,18 +53,15 @@ Bazel LTS release.
 As Bazel rules authors, you can ensure a manageable migration process for users
 by following these best practices:
 
-1.  The rule should follow [Semantic
-    Versioning](https://semver.org/): minor versions of the same
+1.  The rule should follow [Semantic Versioning](https://semver.org/): minor versions of the same
     major version are backward compatible.
 1.  The rule at HEAD should be compatible with the latest Bazel LTS release.
 1.  The rule at HEAD should be compatible with Bazel at HEAD. To achieve this,
     you can
     *   Set up your own CI testing with Bazel at HEAD
-    *   Add your project to [Bazel downstream
-        testing](https://github.com/bazelbuild/continuous-integration/blob/master/docs/downstream-testing.md);
+    *   Add your project to [Bazel downstream testing](https://github.com/bazelbuild/continuous-integration/blob/master/docs/downstream-testing.md);
         the Bazel team files issues to your project if breaking changes in Bazel
-        affect your project, and you must follow our [downstream project
-        policies](https://github.com/bazelbuild/continuous-integration/blob/master/docs/downstream-testing.md#downstream-project-policies)
+        affect your project, and you must follow our [downstream project policies](https://github.com/bazelbuild/continuous-integration/blob/master/docs/downstream-testing.md#downstream-project-policies)
         to address issues timely.
 1.  The latest major version of the rule must be compatible with the latest
     Bazel LTS release.
diff --git a/versions/9.0.0/remote/bep-glossary.mdx b/versions/9.0.0/remote/bep-glossary.mdx
index 026acdc4..3c0c5222 100644
--- a/versions/9.0.0/remote/bep-glossary.mdx
+++ b/versions/9.0.0/remote/bep-glossary.mdx
@@ -36,7 +36,7 @@ BEP contains an event like the following:
 ## ActionExecuted {#actionexecuted}
 
 Provides details about the execution of a specific
-[Action](/versions/9.0.0/rules/lib/actions) in a build. By default, this event is
+[Action](/versions/9.0.0/rules/lib/builtins/actions) in a build. By default, this event is
 included in the BEP only for failed actions, to support identifying the root cause
 of build failures. Users may set the `--build_event_publish_all_actions` flag
 to include all `ActionExecuted` events.
@@ -410,5 +410,4 @@ workspace, such as the execution root.
 
 ## WorkspaceStatus {#workspacestatus}
 
-A single `WorkspaceStatus` event contains the result of the [workspace status
-command](/versions/9.0.0/docs/user-manual#workspace-status).
+A single `WorkspaceStatus` event contains the result of the [workspace status command](/versions/9.0.0/docs/user-manual#workspace-status).
diff --git a/versions/9.0.0/remote/bep.mdx b/versions/9.0.0/remote/bep.mdx
index 14bb2251..396c26a6 100644
--- a/versions/9.0.0/remote/bep.mdx
+++ b/versions/9.0.0/remote/bep.mdx
@@ -2,14 +2,12 @@
 title: 'Build Event Protocol'
 ---
 
-The [Build Event
-Protocol](https://github.com/bazelbuild/bazel/blob/master/src/main/java/com/google/devtools/build/lib/buildeventstream/proto/build_event_stream.proto)
+The [Build Event Protocol](https://github.com/bazelbuild/bazel/blob/master/src/main/java/com/google/devtools/build/lib/buildeventstream/proto/build_event_stream.proto)
 (BEP) allows third-party programs to gain insight into a Bazel invocation. For
 example, you could use the BEP to gather information for an IDE
 plugin or a dashboard that displays build results.
 
-The protocol is a set of [protocol
-buffer](https://developers.google.com/protocol-buffers/) messages with some
+The protocol is a set of [protocol buffer](https://developers.google.com/protocol-buffers/) messages with some
 semantics defined on top of it. It includes information about build and test
 results, build progress, the build configuration and much more. The BEP is
 intended to be consumed programmatically and makes parsing Bazel’s
@@ -20,16 +18,13 @@ build event is a protocol buffer message consisting of a build event identifier,
 a set of child event identifiers, and a payload.
 
 *  __Build Event Identifier:__ Depending on the kind of build event, it might be
-an [opaque
-string](https://github.com/bazelbuild/bazel/blob/7.1.0/src/main/java/com/google/devtools/build/lib/buildeventstream/proto/build_event_stream.proto#L131-L140)
-or [structured
-information](https://github.com/bazelbuild/bazel/blob/7.1.0/src/main/java/com/google/devtools/build/lib/buildeventstream/proto/build_event_stream.proto#L194-L205)
+an [opaque string](https://github.com/bazelbuild/bazel/blob/7.1.0/src/main/java/com/google/devtools/build/lib/buildeventstream/proto/build_event_stream.proto#L131-L140)
+or [structured information](https://github.com/bazelbuild/bazel/blob/7.1.0/src/main/java/com/google/devtools/build/lib/buildeventstream/proto/build_event_stream.proto#L194-L205)
 revealing more about the build event. A build event identifier is unique within
 a build.
 
 *  __Children:__ A build event may announce other build events, by including
-their build event identifiers in its [children
-field](https://github.com/bazelbuild/bazel/blob/7.1.0/src/main/java/com/google/devtools/build/lib/buildeventstream/proto/build_event_stream.proto#L1276).
+their build event identifiers in its [children field](https://github.com/bazelbuild/bazel/blob/7.1.0/src/main/java/com/google/devtools/build/lib/buildeventstream/proto/build_event_stream.proto#L1276).
 For example, the `PatternExpanded` build event announces the targets it expands
 to as children. The protocol guarantees that all events, except for the first
 event, are announced by a previous event.
@@ -91,8 +86,7 @@ human-readable formats, such as text and JSON:
 
 ## Build Event Service {#build-event-service}
 
-The [Build Event
-Service](https://github.com/googleapis/googleapis/blob/master/google/devtools/build/v1/publish_build_event.proto)
+The [Build Event Service](https://github.com/googleapis/googleapis/blob/master/google/devtools/build/v1/publish_build_event.proto)
 Protocol is a generic [gRPC](https://www.grpc.io) service for publishing build events. The Build Event
 Service protocol is independent of the BEP and treats BEP events as opaque bytes.
 Bazel ships with a gRPC client implementation of the Build Event Service protocol that
@@ -136,8 +130,7 @@ For a description of each of these flags, see the
 The BEP typically contains many references to log files (test.log, test.xml,
 etc. ) stored on the machine where Bazel is running. A remote BES server
 typically can't access these files as they are on different machines. A way to
-work around this issue is to use Bazel with [remote
-caching](/versions/9.0.0/remote/caching).
+work around this issue is to use Bazel with [remote caching](/versions/9.0.0/remote/caching).
 Bazel will upload all output files to the remote cache (including files
 referenced in the BEP) and the BES server can then fetch the referenced files
 from the cache.
diff --git a/versions/9.0.0/remote/cache-local.mdx b/versions/9.0.0/remote/cache-local.mdx
index 2e7adc1d..6046c4ca 100644
--- a/versions/9.0.0/remote/cache-local.mdx
+++ b/versions/9.0.0/remote/cache-local.mdx
@@ -18,8 +18,7 @@ execution. However, local execution presents some additional challenges.
 ## Checking your cache hit rate {#cache-hits}
 
 Successful remote cache hits will show up in the status line, similar to
-[Cache Hits rate with Remote
-Execution](/versions/9.0.0/remote/cache-remote#check-cache-hits).
+[Cache Hits rate with Remote Execution](/versions/9.0.0/remote/cache-remote#check-cache-hits).
 
 In the standard output of your Bazel run, you will see something like the
 following:
@@ -66,8 +65,7 @@ the steps in this section.
    message you see does not give you enough information, try adding
    `--verbose_failures`.
 
-2. Follow the steps from [Troubleshooting cache hits for remote
-   execution](/versions/9.0.0/remote/cache-remote#troubleshooting_cache_hits) to
+2. Follow the steps from [Troubleshooting cache hits for remote execution](/versions/9.0.0/remote/cache-remote#troubleshooting_cache_hits) to
    ensure that your cache-writing Bazel invocations are able to get cache hits
    on the same machine and across machines.
 
@@ -81,7 +79,6 @@ the steps in this section.
    b. Ensure your cache-reading Bazel invocations build the same targets as the
       cache-writing Bazel invocations.
 
-   c. Follow the same steps as to [ensure caching across
-      machines](/versions/9.0.0/remote/cache-remote#caching-across-machines),
+   c. Follow the same steps as to [ensure caching across machines](/versions/9.0.0/remote/cache-remote#caching-across-machines),
       to ensure caching from your cache-writing Bazel invocation to your
       cache-reading Bazel invocation.
diff --git a/versions/9.0.0/remote/caching.mdx b/versions/9.0.0/remote/caching.mdx
index 78784ed6..8f743534 100644
--- a/versions/9.0.0/remote/caching.mdx
+++ b/versions/9.0.0/remote/caching.mdx
@@ -126,7 +126,7 @@ not provide technical support for bazel-remote.
 
 This cache stores contents on disk and also provides garbage collection
 to enforce an upper storage limit and clean unused artifacts. The cache is
-available as a [docker image] and its code is available on
+available as a [docker image](https://hub.docker.com/r/buchgr/bazel-remote-cache/) and its code is available on
 [GitHub](https://github.com/buchgr/bazel-remote/).
 Both the REST and gRPC remote cache APIs are supported.
 
@@ -308,8 +308,7 @@ or for the age of individual cache entries. Bazel will automatically garbage
 collect the disk cache while idling between builds; the idle timer can be set
 with `--experimental_disk_cache_gc_idle_delay` (defaulting to 5 minutes).
 
-As an alternative to automatic garbage collection, we also provide a [tool](
-https://github.com/bazelbuild/bazel/tree/master/src/tools/diskcache) to run a
+As an alternative to automatic garbage collection, we also provide a [tool](https://github.com/bazelbuild/bazel/tree/master/src/tools/diskcache) to run a
 garbage collection on demand.
 
 ## Known issues {#known-issues}
diff --git a/versions/9.0.0/remote/dynamic.mdx b/versions/9.0.0/remote/dynamic.mdx
index 4db5dc16..f71ad8ba 100644
--- a/versions/9.0.0/remote/dynamic.mdx
+++ b/versions/9.0.0/remote/dynamic.mdx
@@ -12,8 +12,7 @@ alike.
 This page describes how to enable, tune, and debug dynamic execution. If you
 have both local and remote execution set up and are trying to adjust Bazel
 settings for better performance, this page is for you. If you don't already have
-remote execution set up, go to the Bazel [Remote Execution
-Overview](/versions/9.0.0/remote/rbe) first.
+remote execution set up, go to the Bazel [Remote Execution Overview](/versions/9.0.0/remote/rbe) first.
 
 ## Enabling dynamic execution? {#enabling-dynamic-execution}
 
@@ -44,14 +43,12 @@ are likely. The default value is 1000ms, but should be tuned to being just a bit
 longer than cache hits usually take. The actual time depends both on the remote
 system and on how long a round-trip takes. Usually, the value will be the same
 for all users of a given remote system, unless some of them are far enough away
-to add roundtrip latency. You can use the [Bazel profiling
-features](/versions/9.0.0/rules/performance#performance-profiling) to look at how long typical
+to add roundtrip latency. You can use the [Bazel profiling features](/versions/9.0.0/rules/performance#performance-profiling) to look at how long typical
 cache hits take.
 
 Dynamic execution can be used with local sandboxed strategy as well as with
 [persistent workers](/versions/9.0.0/remote/persistent). Persistent workers will automatically
-run with sandboxing when used with dynamic execution, and cannot use [multiplex
-workers](/versions/9.0.0/remote/multiplex). On Darwin and Windows systems, the sandboxed
+run with sandboxing when used with dynamic execution, and cannot use [multiplex workers](/versions/9.0.0/remote/multiplex). On Darwin and Windows systems, the sandboxed
 strategy can be slow; you can pass `--reuse_sandbox_directories` to reduce
 overhead of creating sandboxes on these systems.
 
@@ -67,8 +64,7 @@ entire action fails. This is an intentional choice to prevent differences
 between local and remote execution from going unnoticed.
 
 For more background on how dynamic execution and its locking works, see Julio
-Merino's excellent [blog
-posts](https://jmmv.dev/series/bazel-dynamic-execution/)
+Merino's excellent [blog posts](https://jmmv.dev/series/bazel-dynamic-execution/)
 
 ## When should I use dynamic execution? {#when-to-use}
 
diff --git a/versions/9.0.0/remote/output-directories.mdx b/versions/9.0.0/remote/output-directories.mdx
index 681a9ada..8cc4b4a9 100644
--- a/versions/9.0.0/remote/output-directories.mdx
+++ b/versions/9.0.0/remote/output-directories.mdx
@@ -25,7 +25,7 @@ The solution that's currently implemented:
 
 * Bazel must be invoked from a directory containing a repo boundary file, or a
   subdirectory thereof. In other words, Bazel must be invoked from inside a
-  [repository](../external/overview#repository). Otherwise, an error is
+  [repository](/versions/9.0.0/external/overview#repository). Otherwise, an error is
   reported.
 * The _outputRoot_ directory defaults to ~/.cache/bazel on Linux,
   `~/Library/Caches/bazel` on macOS (when using Bazel 9 and newer),
diff --git a/versions/9.0.0/remote/persistent.mdx b/versions/9.0.0/remote/persistent.mdx
index 562b1abc..b2948364 100644
--- a/versions/9.0.0/remote/persistent.mdx
+++ b/versions/9.0.0/remote/persistent.mdx
@@ -257,7 +257,6 @@ For more information on persistent workers, see:
 *   [Original persistent workers blog post](https://blog.bazel.build/2015/12/10/java-workers.html)
 *   [Haskell implementation description](https://www.tweag.io/blog/2019-09-25-bazel-ghc-persistent-worker-internship/)
 *   [Blog post by Mike Morearty](https://medium.com/@mmorearty/how-to-create-a-persistent-worker-for-bazel-7738bba2cabb)
-*   [Front End Development with Bazel: Angular/TypeScript and Persistent Workers
-    w/ Asana](https://www.youtube.com/watch?v=0pgERydGyqo)
+*   [Front End Development with Bazel: Angular/TypeScript and Persistent Workers w/ Asana](https://www.youtube.com/watch?v=0pgERydGyqo)
 *   [Bazel strategies explained](https://jmmv.dev/2019/12/bazel-strategies.html)
 *   [Informative worker strategy discussion on the bazel-discuss mailing list](https://groups.google.com/forum/#!msg/bazel-discuss/oAEnuhYOPm8/ol7hf4KWJgAJ)
diff --git a/versions/9.0.0/remote/rules.mdx b/versions/9.0.0/remote/rules.mdx
index 98943b15..31e17392 100644
--- a/versions/9.0.0/remote/rules.mdx
+++ b/versions/9.0.0/remote/rules.mdx
@@ -54,8 +54,7 @@ variables that may not be set to equivalent values (or at all) in the remote
 execution environment.
 
 Toolchain rules currently exist for Bazel build and test rules for
-[Scala](https://github.com/bazelbuild/rules_scala/blob/master/scala/scala_toolch
-ain.bzl),
+[Scala](https://github.com/bazelbuild/rules_scala/blob/master/scala/scala_toolch ain.bzl),
 [Rust](https://github.com/bazelbuild/rules_rust/blob/main/rust/toolchain.bzl),
 and [Go](https://github.com/bazelbuild/rules_go/blob/master/go/toolchains.rst),
 and new toolchain rules are under way for other languages and tools such as
diff --git a/versions/9.0.0/remote/workspace.mdx b/versions/9.0.0/remote/workspace.mdx
index 4ecd4222..14caceb9 100644
--- a/versions/9.0.0/remote/workspace.mdx
+++ b/versions/9.0.0/remote/workspace.mdx
@@ -11,8 +11,7 @@ on the host machine. If your workspace rules access information about the
 host machine for use during execution, your build is likely to break due to
 incompatibilities between the environments.
 
-As part of [adapting Bazel rules for remote
-execution](/versions/9.0.0/remote/rules), you need to find such workspace rules
+As part of [adapting Bazel rules for remote execution](/versions/9.0.0/remote/rules), you need to find such workspace rules
 and fix them. This page describes how to find potentially problematic workspace
 rules using the workspace log.
 
diff --git a/versions/9.0.0/rules/challenges.mdx b/versions/9.0.0/rules/challenges.mdx
index 06ecee0b..3eb3ed4c 100644
--- a/versions/9.0.0/rules/challenges.mdx
+++ b/versions/9.0.0/rules/challenges.mdx
@@ -208,7 +208,7 @@ Bazel is heavily affected by both of these scenarios, so we introduced a set of
 custom collection classes that effectively compress the information in memory by
 avoiding the copy at each step. Almost all of these data structures have set
 semantics, so we called it
-[depset](/versions/9.0.0/rules/lib/depset)
+[depset](/versions/9.0.0/rules/lib/builtins/depset)
 (also known as `NestedSet` in the internal implementation). The majority of
 changes to reduce Bazel's memory consumption over the past several years were
 changes to use depsets instead of whatever was previously used.
diff --git a/versions/9.0.0/rules/faq.mdx b/versions/9.0.0/rules/faq.mdx
index 9c176642..69fa7094 100644
--- a/versions/9.0.0/rules/faq.mdx
+++ b/versions/9.0.0/rules/faq.mdx
@@ -17,7 +17,7 @@ Bazel only executes the actions needed to produce the *requested* output files.
 
 * If you want the file to be built automatically whenever your target is
   mentioned on the command line, add it to your rule's default outputs by
-  returning a [`DefaultInfo`](lib/globals#DefaultInfo) provider.
+  returning a [`DefaultInfo`](/versions/9.0.0/rules/lib/globals#DefaultInfo) provider.
 
 See the [Rules page](/versions/9.0.0/extending/rules#requesting-output-files) for more information.
 
@@ -35,24 +35,24 @@ correct path.
 
 For actions, you declare inputs by passing them to the `ctx.actions.*` function
 that creates the action. The proper path for the file can be obtained using
-[`File.path`](lib/File#path).
+[`File.path`](/versions/9.0.0/rules/lib/builtins/File#path).
 
 For binaries (the executable outputs run by a `bazel run` or `bazel test`
 command), you declare inputs by including them in the
 [runfiles](/versions/9.0.0/extending/rules#runfiles). Instead of using the `path` field, use
-[`File.short_path`](lib/File#short_path), which is file's path relative to
+[`File.short_path`](/versions/9.0.0/rules/lib/builtins/File#short_path), which is file's path relative to
 the runfiles directory in which the binary executes.
 
 ## How can I control which files are built by `bazel build //pkg:mytarget`?
 
-Use the [`DefaultInfo`](lib/globals#DefaultInfo) provider to
+Use the [`DefaultInfo`](/versions/9.0.0/rules/lib/globals#DefaultInfo) provider to
 [set the default outputs](/versions/9.0.0/extending/rules#requesting-output-files).
 
 ## How can I run a program or do file I/O as part of my build?
 
 A tool can be declared as a target, just like any other part of your build, and
 run during the execution phase to help build other targets. To create an action
-that runs a tool, use [`ctx.actions.run`](lib/actions#run) and pass in the
+that runs a tool, use [`ctx.actions.run`](/versions/9.0.0/rules/lib/builtins/actions#run) and pass in the
 tool as the `executable` parameter.
 
 During the loading and analysis phases, a tool *cannot* run, nor can you perform
diff --git a/versions/9.0.0/rules/language.mdx b/versions/9.0.0/rules/language.mdx
index 87553d18..f9692c49 100644
--- a/versions/9.0.0/rules/language.mdx
+++ b/versions/9.0.0/rules/language.mdx
@@ -34,14 +34,14 @@ Starlark's semantics can differ from Python, but behavioral differences are
 rare, except for cases where Starlark raises an error. The following Python
 types are supported:
 
-* [None](lib/globals#None)
-* [bool](lib/bool)
-* [dict](lib/dict)
-* [tuple](lib/tuple)
-* [function](lib/function)
-* [int](lib/int)
-* [list](lib/list)
-* [string](lib/string)
+* [None](/versions/9.0.0/rules/lib/globals#None)
+* [bool](/versions/9.0.0/rules/lib/core/bool)
+* [dict](/versions/9.0.0/rules/lib/core/dict)
+* [tuple](/versions/9.0.0/rules/lib/core/tuple)
+* [function](/versions/9.0.0/rules/lib/core/function)
+* [int](/versions/9.0.0/rules/lib/core/int)
+* [list](/versions/9.0.0/rules/lib/core/list)
+* [string](/versions/9.0.0/rules/lib/core/string)
 
 ## Type annotations {#StarlarkTypes}
 
@@ -60,7 +60,7 @@ with a syntax inspired by [PEP 484](https://peps.python.org/pep-0484/).
 ## Mutability
 
 Starlark favors immutability. Two mutable data structures are available:
-[lists](lib/list) and [dicts](lib/dict). Changes to mutable
+[lists](/versions/9.0.0/rules/lib/core/list) and [dicts](/versions/9.0.0/rules/lib/core/dict). Changes to mutable
 data-structures, such as appending a value to a list or deleting an entry in a
 dictionary are valid only for objects created in the current context. After a
 context finishes, its values become immutable.
@@ -107,10 +107,8 @@ values returned by rules are immutable.
 `BUILD` files register targets via making calls to rules. `.bzl` files provide
 definitions for constants, rules, macros, and functions.
 
-[Native functions](/versions/9.0.0/reference/be/functions) and [native rules](
-/reference/be/overview#language-specific-native-rules) are global symbols in
-`BUILD` files. `bzl` files need to load them using the [`native` module](
-/rules/lib/toplevel/native).
+[Native functions](/versions/9.0.0/reference/be/functions) and [native rules](/versions/9.0.0/reference/be/overview#language-specific-native-rules) are global symbols in
+`BUILD` files. `bzl` files need to load them using the [`native` module](/versions/9.0.0/rules/lib/toplevel/native).
 
 There are two syntactic restrictions in `BUILD` files: 1) declaring functions is
 illegal, and 2) `*args` and `**kwargs` arguments are not allowed.
@@ -144,7 +142,7 @@ not defined across value types. In short: `5 < 'foo'` will throw an error and
   error: `{"a": 4, "b": 7, "a": 1}`.
 
 * Strings are represented with double-quotes (such as when you call
-  [repr](lib/globals#repr)).
+  [repr](/versions/9.0.0/rules/lib/globals#repr)).
 
 * Strings aren't iterable.
 
@@ -152,12 +150,12 @@ The following Python features are not supported:
 
 * implicit string concatenation (use explicit `+` operator).
 * Chained comparisons (such as `1 < x < 5`).
-* `class` (see [`struct`](lib/struct#struct) function).
+* `class` (see [`struct`](/versions/9.0.0/rules/lib/builtins/struct#struct) function).
 * `import` (see [`load`](/versions/9.0.0/extending/concepts#loading-an-extension) statement).
 * `while`, `yield`.
 * float and set types.
 * generators and generator expressions.
 * `is` (use `==` instead).
-* `try`, `raise`, `except`, `finally` (see [`fail`](lib/globals#fail) for fatal errors).
+* `try`, `raise`, `except`, `finally` (see [`fail`](/versions/9.0.0/rules/lib/globals#fail) for fatal errors).
 * `global`, `nonlocal`.
 * most builtin functions, most methods.
diff --git a/versions/9.0.0/rules/legacy-macro-tutorial.mdx b/versions/9.0.0/rules/legacy-macro-tutorial.mdx
index 9280231d..f9706b8f 100644
--- a/versions/9.0.0/rules/legacy-macro-tutorial.mdx
+++ b/versions/9.0.0/rules/legacy-macro-tutorial.mdx
@@ -3,9 +3,7 @@ title: 'Creating a Legacy Macro'
 ---
 
 IMPORTANT: This tutorial is for [*legacy macros*](/versions/9.0.0/extending/legacy-macros). If
-you only need to support Bazel 8 or newer, we recommend using [symbolic
-macros](/versions/9.0.0/extending/macros) instead; take a look at [Creating a Symbolic
-Macro](macro-tutorial).
+you only need to support Bazel 8 or newer, we recommend using [symbolic macros](/versions/9.0.0/extending/macros) instead; take a look at [Creating a Symbolic Macro](/versions/9.0.0/rules/macro-tutorial).
 
 Imagine that you need to run a tool as part of your build. For example, you
 may want to generate or preprocess a source file, or compress a binary. In this
diff --git a/versions/9.0.0/rules/lib/builtins/Action.mdx b/versions/9.0.0/rules/lib/builtins/Action.mdx
index dbf0603c..dd033fe6 100644
--- a/versions/9.0.0/rules/lib/builtins/Action.mdx
+++ b/versions/9.0.0/rules/lib/builtins/Action.mdx
@@ -4,7 +4,7 @@ title: 'Action'
 
 An action created during rule analysis.
 
-This object is visible for the purpose of testing, and may be obtained from an `Actions` provider. It is normally not necessary to access `Action` objects or their fields within a rule's implementation function. You may instead want to see the [Rules page](https://bazel.build/versions/9.0.0/extending/rules#actions) for a general discussion of how to use actions when defining custom rules, or the [API reference](../builtins/actions) for creating actions.
+This object is visible for the purpose of testing, and may be obtained from an `Actions` provider. It is normally not necessary to access `Action` objects or their fields within a rule's implementation function. You may instead want to see the [Rules page](https://bazel.build/versions/9.0.0/extending/rules#actions) for a general discussion of how to use actions when defining custom rules, or the [API reference](/versions/9.0.0/rules/lib/builtins/actions) for creating actions.
 
 Some fields of this object are only applicable for certain kinds of actions. Fields that are inapplicable are set to `None`.
 
@@ -25,7 +25,7 @@ Some fields of this object are only applicable for certain kinds of actions. Fie
 sequence Action.args
 ```
 
-A list of frozen [Args](../builtins/Args) objects containing information about the action arguments. These objects contain accurate argument information, including arguments involving expanded action output directories. However, [Args](../builtins/Args) objects are not readable in the analysis phase. For a less accurate account of arguments which is available in the analysis phase, see [argv](#argv).
+A list of frozen [Args](/versions/9.0.0/rules/lib/builtins/Args) objects containing information about the action arguments. These objects contain accurate argument information, including arguments involving expanded action output directories. However, [Args](/versions/9.0.0/rules/lib/builtins/Args) objects are not readable in the analysis phase. For a less accurate account of arguments which is available in the analysis phase, see [argv](#argv).
 
 Note that some types of actions do not yet support exposure of this field. For such action types, this is `None`.
 May return `None`.
@@ -36,7 +36,7 @@ May return `None`.
 sequence Action.argv
 ```
 
-For actions created by [ctx.actions.run()](../builtins/actions#run) or [ctx.actions.run\_shell()](../builtins/actions#run_shell) an immutable list of the arguments for the command line to be executed. Note that for shell actions the first two arguments will be the shell path and `"-c"`.
+For actions created by [ctx.actions.run()](/versions/9.0.0/rules/lib/builtins/actions#run) or [ctx.actions.run\_shell()](/versions/9.0.0/rules/lib/builtins/actions#run_shell) an immutable list of the arguments for the command line to be executed. Note that for shell actions the first two arguments will be the shell path and `"-c"`.
 May return `None`.
 
 ## content
@@ -45,7 +45,7 @@ May return `None`.
 string Action.content
 ```
 
-For actions created by [ctx.actions.write()](../builtins/actions#write) or [ctx.actions.expand\_template()](../builtins/actions#expand_template), the contents of the file to be written, if those contents can be computed during the analysis phase. The value is `None` if the contents cannot be determined until the execution phase, such as when a directory in an [Args](../builtins/Args) object needs to be expanded.
+For actions created by [ctx.actions.write()](/versions/9.0.0/rules/lib/builtins/actions#write) or [ctx.actions.expand\_template()](/versions/9.0.0/rules/lib/builtins/actions#expand_template), the contents of the file to be written, if those contents can be computed during the analysis phase. The value is `None` if the contents cannot be determined until the execution phase, such as when a directory in an [Args](/versions/9.0.0/rules/lib/builtins/Args) object needs to be expanded.
 May return `None`.
 
 ## env
@@ -86,5 +86,5 @@ A set of the output files of this action.
 dict Action.substitutions
 ```
 
-For actions created by [ctx.actions.expand\_template()](../builtins/actions#expand_template), an immutable dict holding the substitution mapping.
+For actions created by [ctx.actions.expand\_template()](/versions/9.0.0/rules/lib/builtins/actions#expand_template), an immutable dict holding the substitution mapping.
 May return `None`.
\ No newline at end of file
diff --git a/versions/9.0.0/rules/lib/builtins/Args.mdx b/versions/9.0.0/rules/lib/builtins/Args.mdx
index d7056eea..2627db21 100644
--- a/versions/9.0.0/rules/lib/builtins/Args.mdx
+++ b/versions/9.0.0/rules/lib/builtins/Args.mdx
@@ -4,15 +4,15 @@ title: 'Args'
 
 An object that encapsulates, in a memory-efficient way, the data needed to build part or all of a command line.
 
-It often happens that an action requires a large command line containing values accumulated from transitive dependencies. For example, a linker command line might list every object file needed by all of the libraries being linked. It is best practice to store such transitive data in [`depset`](../builtins/depset)s, so that they can be shared by multiple targets. However, if the rule author had to convert these depsets into lists of strings in order to construct an action command line, it would defeat this memory-sharing optimization.
+It often happens that an action requires a large command line containing values accumulated from transitive dependencies. For example, a linker command line might list every object file needed by all of the libraries being linked. It is best practice to store such transitive data in [`depset`](/versions/9.0.0/rules/lib/builtins/depset)s, so that they can be shared by multiple targets. However, if the rule author had to convert these depsets into lists of strings in order to construct an action command line, it would defeat this memory-sharing optimization.
 
 For this reason, the action-constructing functions accept `Args` objects in addition to strings. Each `Args` object represents a concatenation of strings and depsets, with optional transformations for manipulating the data. `Args` objects do not process the depsets they encapsulate until the execution phase, when it comes time to calculate the command line. This helps defer any expensive copying until after the analysis phase is complete. See the [Optimizing Performance](https://bazel.build/versions/9.0.0/rules/performance) page for more information.
 
-`Args` are constructed by calling [`ctx.actions.args()`](../builtins/actions#args). They can be passed as the `arguments` parameter of [`ctx.actions.run()`](../builtins/actions#run) or [`ctx.actions.run_shell()`](../builtins/actions#run_shell). Each mutation of an `Args` object appends values to the eventual command line.
+`Args` are constructed by calling [`ctx.actions.args()`](/versions/9.0.0/rules/lib/builtins/actions#args). They can be passed as the `arguments` parameter of [`ctx.actions.run()`](/versions/9.0.0/rules/lib/builtins/actions#run) or [`ctx.actions.run_shell()`](/versions/9.0.0/rules/lib/builtins/actions#run_shell). Each mutation of an `Args` object appends values to the eventual command line.
 
 The `map_each` feature allows you to customize how items are transformed into strings. If you do not provide a `map_each` function, the standard conversion is as follows:
 
-* Values that are already strings are left as-is.* [`File`](../builtins/File) objects are turned into their `File.path` values.* [`Label`](../builtins/Label) objects are turned into a string representation that resolves back to the same object when resolved in the context of the main repository. If possible, the string representation uses the apparent name of a repository in favor of the repository's canonical name, which makes this representation suited for use in BUILD files. While the exact form of the representation is not guaranteed, typical examples are `//foo:bar`, `@repo//foo:bar` and `@@canonical_name+//foo:bar.bzl`.* All other types are turned into strings in an *unspecified* manner. For this reason, you should avoid passing values that are not of string or `File` type to `add()`, and if you pass them to `add_all()` or `add_joined()` then you should provide a `map_each` function.
+* Values that are already strings are left as-is.* [`File`](/versions/9.0.0/rules/lib/builtins/File) objects are turned into their `File.path` values.* [`Label`](/versions/9.0.0/rules/lib/builtins/Label) objects are turned into a string representation that resolves back to the same object when resolved in the context of the main repository. If possible, the string representation uses the apparent name of a repository in favor of the repository's canonical name, which makes this representation suited for use in BUILD files. While the exact form of the representation is not guaranteed, typical examples are `//foo:bar`, `@repo//foo:bar` and `@@canonical_name+//foo:bar.bzl`.* All other types are turned into strings in an *unspecified* manner. For this reason, you should avoid passing values that are not of string or `File` type to `add()`, and if you pass them to `add_all()` or `add_joined()` then you should provide a `map_each` function.
 
 When using string formatting (`format`, `format_each`, and `format_joined` params of the `add*()` methods), the format template is interpreted in the same way as `%`-substitution on strings, except that the template must have exactly one substitution placeholder and it must be `%s`. Literal percents may be escaped as `%%`. Formatting is applied after the value is converted to a string as per the above.
 
@@ -64,7 +64,7 @@ Appends an argument to this command line.
 | --- | --- |
 | `arg_name_or_value` | required  If two positional parameters are passed this is interpreted as the arg name. The arg name is added before the value without any processing. If only one positional parameter is passed, it is interpreted as `value` (see below). |
 | `value` | default is `unbound`  The object to append. It will be converted to a string using the standard conversion mentioned above. Since there is no `map_each` parameter for this function, `value` should be either a string or a `File`. A list, tuple, depset, or directory `File` must be passed to [`add_all()` or [`add_joined()`](#add_joined) instead of this method.](#add_all) |
-| `format` | [string](../core/string); or `None`; default is `None`  A format string pattern, to be applied to the stringified version of `value`. |
+| `format` | [string](/versions/9.0.0/rules/lib/core/string); or `None`; default is `None`  A format string pattern, to be applied to the stringified version of `value`. |
 
 ## add\_all
 
@@ -86,15 +86,15 @@ Note that empty strings are valid arguments that are subject to all these proces
 | Parameter | Description |
 | --- | --- |
 | `arg_name_or_values` | required  If two positional parameters are passed this is interpreted as the arg name. The arg name is added before the `values` as a separate argument without any processing. This arg name will not be added if `omit_if_empty` is true (the default) and no other items are appended (as happens if `values` is empty or all of its items are filtered). If only one positional parameter is passed, it is interpreted as `values` (see below). |
-| `values` | [sequence](../core/list); or [depset](../builtins/depset); default is `unbound`  The list, tuple, or depset whose items will be appended. |
-| `map_each` | callable; or `None`; default is `None`  A function that converts each item to zero or more strings, which may be further processed before appending. If this param is not provided, the standard conversion is used. The function is passed either one or two positional arguments: the item to convert, followed by an optional [`DirectoryExpander`](../builtins/DirectoryExpander). The second argument will be passed only if the supplied function is user-defined (not built-in) and declares more than one parameter. The return value's type depends on how many arguments are to be produced for the item:  * In the common case when each item turns into one string, the function should return that string.* If the item is to be filtered out entirely, the function should return `None`.* If the item turns into multiple strings, the function returns a list of those strings.  Returning a single string or `None` has the same effect as returning a list of length 1 or length 0 respectively. However, it is more efficient and readable to avoid creating a list where it is not needed. Ordinarily, items that are directories are automatically expanded to their contents when `expand_directories=True` is set. However, this will not expand directories contained inside other values -- for instance, when the items are structs that have directories as fields. In this situation, the `DirectoryExpander` argument can be applied to manually obtain the files of a given directory. To avoid unintended retention of large analysis-phase data structures into the execution phase, the `map_each` function must be declared by a top-level `def` statement; it may not be a nested function closure by default. *Warning:* [`print()`](../globals/all#print) statements that are executed during the call to `map_each` will not produce any visible output. |
-| `format_each` | [string](../core/string); or `None`; default is `None`  An optional format string pattern, applied to each string returned by the `map_each` function. The format string must have exactly one '%s' placeholder. |
-| `before_each` | [string](../core/string); or `None`; default is `None`  An optional argument to append before each argument derived from `values` is appended. |
-| `omit_if_empty` | [bool](../core/bool); default is `True`  If true, if there are no arguments derived from `values` to be appended, then all further processing is suppressed and the command line will be unchanged. If false, the arg name and `terminate_with`, if provided, will still be appended regardless of whether or not there are other arguments. |
-| `uniquify` | [bool](../core/bool); default is `False`  If true, duplicate arguments that are derived from `values` will be omitted. Only the first occurrence of each argument will remain. Usually this feature is not needed because depsets already omit duplicates, but it can be useful if `map_each` emits the same string for multiple items. |
-| `expand_directories` | [bool](../core/bool); default is `True`  If true, any directories in `values` will be expanded to a flat list of files. This happens before `map_each` is applied. |
-| `terminate_with` | [string](../core/string); or `None`; default is `None`  An optional argument to append after all other arguments. This argument will not be added if `omit_if_empty` is true (the default) and no other items are appended (as happens if `values` is empty or all of its items are filtered). |
-| `allow_closure` | [bool](../core/bool); default is `False`  If true, allows the use of closures in function parameters like `map_each`. Usually this isn't necessary and it risks retaining large analysis-phase data structures into the execution phase. |
+| `values` | [sequence](/versions/9.0.0/rules/lib/core/list); or [depset](/versions/9.0.0/rules/lib/builtins/depset); default is `unbound`  The list, tuple, or depset whose items will be appended. |
+| `map_each` | callable; or `None`; default is `None`  A function that converts each item to zero or more strings, which may be further processed before appending. If this param is not provided, the standard conversion is used. The function is passed either one or two positional arguments: the item to convert, followed by an optional [`DirectoryExpander`](/versions/9.0.0/rules/lib/builtins/DirectoryExpander). The second argument will be passed only if the supplied function is user-defined (not built-in) and declares more than one parameter. The return value's type depends on how many arguments are to be produced for the item:  * In the common case when each item turns into one string, the function should return that string.* If the item is to be filtered out entirely, the function should return `None`.* If the item turns into multiple strings, the function returns a list of those strings.  Returning a single string or `None` has the same effect as returning a list of length 1 or length 0 respectively. However, it is more efficient and readable to avoid creating a list where it is not needed. Ordinarily, items that are directories are automatically expanded to their contents when `expand_directories=True` is set. However, this will not expand directories contained inside other values -- for instance, when the items are structs that have directories as fields. In this situation, the `DirectoryExpander` argument can be applied to manually obtain the files of a given directory. To avoid unintended retention of large analysis-phase data structures into the execution phase, the `map_each` function must be declared by a top-level `def` statement; it may not be a nested function closure by default. *Warning:* [`print()`](/versions/9.0.0/rules/lib/globals/all#print) statements that are executed during the call to `map_each` will not produce any visible output. |
+| `format_each` | [string](/versions/9.0.0/rules/lib/core/string); or `None`; default is `None`  An optional format string pattern, applied to each string returned by the `map_each` function. The format string must have exactly one '%s' placeholder. |
+| `before_each` | [string](/versions/9.0.0/rules/lib/core/string); or `None`; default is `None`  An optional argument to append before each argument derived from `values` is appended. |
+| `omit_if_empty` | [bool](/versions/9.0.0/rules/lib/core/bool); default is `True`  If true, if there are no arguments derived from `values` to be appended, then all further processing is suppressed and the command line will be unchanged. If false, the arg name and `terminate_with`, if provided, will still be appended regardless of whether or not there are other arguments. |
+| `uniquify` | [bool](/versions/9.0.0/rules/lib/core/bool); default is `False`  If true, duplicate arguments that are derived from `values` will be omitted. Only the first occurrence of each argument will remain. Usually this feature is not needed because depsets already omit duplicates, but it can be useful if `map_each` emits the same string for multiple items. |
+| `expand_directories` | [bool](/versions/9.0.0/rules/lib/core/bool); default is `True`  If true, any directories in `values` will be expanded to a flat list of files. This happens before `map_each` is applied. |
+| `terminate_with` | [string](/versions/9.0.0/rules/lib/core/string); or `None`; default is `None`  An optional argument to append after all other arguments. This argument will not be added if `omit_if_empty` is true (the default) and no other items are appended (as happens if `values` is empty or all of its items are filtered). |
+| `allow_closure` | [bool](/versions/9.0.0/rules/lib/core/bool); default is `False`  If true, allows the use of closures in function parameters like `map_each`. Usually this isn't necessary and it risks retaining large analysis-phase data structures into the execution phase. |
 
 ## add\_joined
 
@@ -113,15 +113,15 @@ If after filtering there are no strings to join into an argument, and if `omit_i
 | Parameter | Description |
 | --- | --- |
 | `arg_name_or_values` | required  If two positional parameters are passed this is interpreted as the arg name. The arg name is added before `values` without any processing. This arg will not be added if `omit_if_empty` is true (the default) and there are no strings derived from `values` to join together (which can happen if `values` is empty or all of its items are filtered). If only one positional parameter is passed, it is interpreted as `values` (see below). |
-| `values` | [sequence](../core/list); or [depset](../builtins/depset); default is `unbound`  The list, tuple, or depset whose items will be joined. |
-| `join_with` | [string](../core/string); required  A delimiter string used to join together the strings obtained from applying `map_each` and `format_each`, in the same manner as [`string.join()`](../core/string#join). |
+| `values` | [sequence](/versions/9.0.0/rules/lib/core/list); or [depset](/versions/9.0.0/rules/lib/builtins/depset); default is `unbound`  The list, tuple, or depset whose items will be joined. |
+| `join_with` | [string](/versions/9.0.0/rules/lib/core/string); required  A delimiter string used to join together the strings obtained from applying `map_each` and `format_each`, in the same manner as [`string.join()`](/versions/9.0.0/rules/lib/core/string#join). |
 | `map_each` | callable; or `None`; default is `None`  Same as for [`add_all`](#add_all.map_each). |
-| `format_each` | [string](../core/string); or `None`; default is `None`  Same as for [`add_all`](#add_all.format_each). |
-| `format_joined` | [string](../core/string); or `None`; default is `None`  An optional format string pattern applied to the joined string. The format string must have exactly one '%s' placeholder. |
-| `omit_if_empty` | [bool](../core/bool); default is `True`  If true, if there are no strings to join together (either because `values` is empty or all its items are filtered), then all further processing is suppressed and the command line will be unchanged. If false, then even if there are no strings to join together, two arguments will be appended: the arg name followed by an empty string (which is the logical join of zero strings). |
-| `uniquify` | [bool](../core/bool); default is `False`  Same as for [`add_all`](#add_all.uniquify). |
-| `expand_directories` | [bool](../core/bool); default is `True`  Same as for [`add_all`](#add_all.expand_directories). |
-| `allow_closure` | [bool](../core/bool); default is `False`  Same as for [`add_all`](#add_all.allow_closure). |
+| `format_each` | [string](/versions/9.0.0/rules/lib/core/string); or `None`; default is `None`  Same as for [`add_all`](#add_all.format_each). |
+| `format_joined` | [string](/versions/9.0.0/rules/lib/core/string); or `None`; default is `None`  An optional format string pattern applied to the joined string. The format string must have exactly one '%s' placeholder. |
+| `omit_if_empty` | [bool](/versions/9.0.0/rules/lib/core/bool); default is `True`  If true, if there are no strings to join together (either because `values` is empty or all its items are filtered), then all further processing is suppressed and the command line will be unchanged. If false, then even if there are no strings to join together, two arguments will be appended: the arg name followed by an empty string (which is the logical join of zero strings). |
+| `uniquify` | [bool](/versions/9.0.0/rules/lib/core/bool); default is `False`  Same as for [`add_all`](#add_all.uniquify). |
+| `expand_directories` | [bool](/versions/9.0.0/rules/lib/core/bool); default is `True`  Same as for [`add_all`](#add_all.expand_directories). |
+| `allow_closure` | [bool](/versions/9.0.0/rules/lib/core/bool); default is `False`  Same as for [`add_all`](#add_all.allow_closure). |
 
 ## set\_param\_file\_format
 
@@ -135,7 +135,7 @@ Sets the format of the param file, if one is used
 
 | Parameter | Description |
 | --- | --- |
-| `format` | [string](../core/string); required  Must be one of:  * "multiline": Each item (argument name or value) is written verbatim to the param file with a newline character following it. * "shell": Same as "multiline", but the items are shell-quoted * "flag\_per\_line": Same as "multiline", but (1) only flags (beginning with '--') are written to the param file, and (2) the values of the flags, if any, are written on the same line with a '=' separator. This is the format expected by the Abseil flags library.   The format defaults to "shell" if not called. |
+| `format` | [string](/versions/9.0.0/rules/lib/core/string); required  Must be one of:  * "multiline": Each item (argument name or value) is written verbatim to the param file with a newline character following it. * "shell": Same as "multiline", but the items are shell-quoted * "flag\_per\_line": Same as "multiline", but (1) only flags (beginning with '--') are written to the param file, and (2) the values of the flags, if any, are written on the same line with a '=' separator. This is the format expected by the Abseil flags library.   The format defaults to "shell" if not called. |
 
 ## use\_param\_file
 
@@ -151,5 +151,5 @@ Bazel may choose to elide writing the params file to the output tree during exec
 
 | Parameter | Description |
 | --- | --- |
-| `param_file_arg` | [string](../core/string); required  A format string with a single "%s". If the args are spilled to a params file then they are replaced with an argument consisting of this string formatted with the path of the params file. For example, if the args are spilled to a params file "params.txt", then specifying "--file=%s" would cause the action command line to contain "--file=params.txt". |
-| `use_always` | [bool](../core/bool); default is `False`  Whether to always spill the args to a params file. If false, bazel will decide whether the arguments need to be spilled based on your system and arg length. |
\ No newline at end of file
+| `param_file_arg` | [string](/versions/9.0.0/rules/lib/core/string); required  A format string with a single "%s". If the args are spilled to a params file then they are replaced with an argument consisting of this string formatted with the path of the params file. For example, if the args are spilled to a params file "params.txt", then specifying "--file=%s" would cause the action command line to contain "--file=params.txt". |
+| `use_always` | [bool](/versions/9.0.0/rules/lib/core/bool); default is `False`  Whether to always spill the args to a params file. If false, bazel will decide whether the arguments need to be spilled based on your system and arg length. |
\ No newline at end of file
diff --git a/versions/9.0.0/rules/lib/builtins/Aspect.mdx b/versions/9.0.0/rules/lib/builtins/Aspect.mdx
index ab32564c..bffc7de2 100644
--- a/versions/9.0.0/rules/lib/builtins/Aspect.mdx
+++ b/versions/9.0.0/rules/lib/builtins/Aspect.mdx
@@ -3,4 +3,4 @@ title: 'Aspect'
 ---
 
 For more information about Aspects, please consult the
-[documentation of the aspect function](../globals/bzl#aspect) or the [introduction to Aspects](https://bazel.build/versions/9.0.0/extending/aspects).
\ No newline at end of file
+[documentation of the aspect function](/versions/9.0.0/rules/lib/globals/bzl#aspect) or the [introduction to Aspects](https://bazel.build/versions/9.0.0/extending/aspects).
\ No newline at end of file
diff --git a/versions/9.0.0/rules/lib/builtins/Attribute.mdx b/versions/9.0.0/rules/lib/builtins/Attribute.mdx
index 18486c41..ff43b141 100644
--- a/versions/9.0.0/rules/lib/builtins/Attribute.mdx
+++ b/versions/9.0.0/rules/lib/builtins/Attribute.mdx
@@ -2,4 +2,4 @@
 title: 'Attribute'
 ---
 
-Representation of a definition of an attribute. Use the [attr](../toplevel/attr) module to create an Attribute. They are only for use with a [rule](../globals/bzl#rule) or an [aspect](../globals/bzl#aspect).
\ No newline at end of file
+Representation of a definition of an attribute. Use the [attr](/versions/9.0.0/rules/lib/toplevel/attr) module to create an Attribute. They are only for use with a [rule](/versions/9.0.0/rules/lib/globals/bzl#rule) or an [aspect](/versions/9.0.0/rules/lib/globals/bzl#aspect).
\ No newline at end of file
diff --git a/versions/9.0.0/rules/lib/builtins/DirectoryExpander.mdx b/versions/9.0.0/rules/lib/builtins/DirectoryExpander.mdx
index 8bf9ae69..01af5b79 100644
--- a/versions/9.0.0/rules/lib/builtins/DirectoryExpander.mdx
+++ b/versions/9.0.0/rules/lib/builtins/DirectoryExpander.mdx
@@ -2,7 +2,7 @@
 title: 'DirectoryExpander'
 ---
 
-Expands directories created by [`ctx.actions.declare_directory`](../builtins/actions#declare_directory) during the execution phase. This is useful to expand directories in [`map_each`](../builtins/Args#add_all.map_each).
+Expands directories created by [`ctx.actions.declare_directory`](/versions/9.0.0/rules/lib/builtins/actions#declare_directory) during the execution phase. This is useful to expand directories in [`map_each`](/versions/9.0.0/rules/lib/builtins/Args#add_all.map_each).
 
 ## Members
 
@@ -20,4 +20,4 @@ If the given `File` is a directory, this returns a list of `File`s recursively u
 
 | Parameter | Description |
 | --- | --- |
-| `file` | [File](../builtins/File); required  The directory or file to expand. |
\ No newline at end of file
+| `file` | [File](/versions/9.0.0/rules/lib/builtins/File); required  The directory or file to expand. |
\ No newline at end of file
diff --git a/versions/9.0.0/rules/lib/builtins/DottedVersion.mdx b/versions/9.0.0/rules/lib/builtins/DottedVersion.mdx
index f17cea85..40b8a563 100644
--- a/versions/9.0.0/rules/lib/builtins/DottedVersion.mdx
+++ b/versions/9.0.0/rules/lib/builtins/DottedVersion.mdx
@@ -20,4 +20,4 @@ Compares based on most significant (first) not-matching version component. So, f
 
 | Parameter | Description |
 | --- | --- |
-| `other` | [DottedVersion](../builtins/DottedVersion); required  The other dotted version. |
\ No newline at end of file
+| `other` | [DottedVersion](/versions/9.0.0/rules/lib/builtins/DottedVersion); required  The other dotted version. |
\ No newline at end of file
diff --git a/versions/9.0.0/rules/lib/builtins/Facts.mdx b/versions/9.0.0/rules/lib/builtins/Facts.mdx
index f88937d4..091937a8 100644
--- a/versions/9.0.0/rules/lib/builtins/Facts.mdx
+++ b/versions/9.0.0/rules/lib/builtins/Facts.mdx
@@ -24,5 +24,5 @@ Returns the value for `key` if it exists, or `default`.
 
 | Parameter | Description |
 | --- | --- |
-| `key` | [string](../core/string); required  The key to look up. |
+| `key` | [string](/versions/9.0.0/rules/lib/core/string); required  The key to look up. |
 | `default` | default is `None`  The value to return if `key` is not present. |
\ No newline at end of file
diff --git a/versions/9.0.0/rules/lib/builtins/File.mdx b/versions/9.0.0/rules/lib/builtins/File.mdx
index 9811a175..f5025c37 100644
--- a/versions/9.0.0/rules/lib/builtins/File.mdx
+++ b/versions/9.0.0/rules/lib/builtins/File.mdx
@@ -4,7 +4,7 @@ title: 'File'
 
 This object is created during the analysis phase to represent a file or directory that will be read or written during the execution phase. It is not an open file handle, and cannot be used to directly read or write file contents. Rather, you use it to construct the action graph in a rule implementation function by passing it to action-creating functions. See the [Rules page](https://bazel.build/versions/9.0.0/extending/rules#files) for more information.
 
-When a `File` is passed to an [`Args`](../builtins/Args) object without using a `map_each` function, it is converted to a string by taking the value of its `path` field.
+When a `File` is passed to an [`Args`](/versions/9.0.0/rules/lib/builtins/Args) object without using a `map_each` function, it is converted to a string by taking the value of its `path` field.
 
 ## Members
 
@@ -83,7 +83,7 @@ May return `None`.
 string File.path
 ```
 
-The execution path of this file, relative to the workspace's execution directory. It consists of two parts, an optional first part called the *root* (see also the [root](../builtins/root) module), and the second part which is the `short_path`. The root may be empty, which it usually is for non-generated files. For generated files it usually contains a configuration-specific path fragment that encodes things like the target CPU architecture that was used while building said file. Use the `short_path` for the path under which the file is mapped if it's in the runfiles of a binary.
+The execution path of this file, relative to the workspace's execution directory. It consists of two parts, an optional first part called the *root* (see also the [root](/versions/9.0.0/rules/lib/builtins/root) module), and the second part which is the `short_path`. The root may be empty, which it usually is for non-generated files. For generated files it usually contains a configuration-specific path fragment that encodes things like the target CPU architecture that was used while building said file. Use the `short_path` for the path under which the file is mapped if it's in the runfiles of a binary.
 
 ## root
 
@@ -107,4 +107,4 @@ The path of this file relative to its root. This excludes the aforementioned *ro
 string File.tree_relative_path
 ```
 
-The path of this file relative to the root of the ancestor's tree, if the ancestor's [is\_directory](#is_directory) field is true. `tree_relative_path` is only available for expanded files of a directory in an action command, i.e. [Args.add\_all()](../builtins/Args#add_all). For other types of files, it is an error to access this field.
\ No newline at end of file
+The path of this file relative to the root of the ancestor's tree, if the ancestor's [is\_directory](#is_directory) field is true. `tree_relative_path` is only available for expanded files of a directory in an action command, i.e. [Args.add\_all()](/versions/9.0.0/rules/lib/builtins/Args#add_all). For other types of files, it is an error to access this field.
\ No newline at end of file
diff --git a/versions/9.0.0/rules/lib/builtins/Label.mdx b/versions/9.0.0/rules/lib/builtins/Label.mdx
index 40ed3347..14ff1a9c 100644
--- a/versions/9.0.0/rules/lib/builtins/Label.mdx
+++ b/versions/9.0.0/rules/lib/builtins/Label.mdx
@@ -27,13 +27,13 @@ Label Label(input)
 
 Converts a label string into a `Label` object, in the context of the package where the calling `.bzl` source file lives. If the given value is already a `Label`, it is returned unchanged.
 
-For macros, a related function, `native.package_relative_label()`, converts the input into a `Label` in the context of the package currently being constructed. For rule and aspect implementation functions, [`ctx.package_relative_label()`](ctx#package_relative_label) can be used for the same purpose. Use these functions to mimic the string-to-label conversion that is automatically done by label-valued rule attributes.
+For macros, a related function, `native.package_relative_label()`, converts the input into a `Label` in the context of the package currently being constructed. For rule and aspect implementation functions, [`ctx.package_relative_label()`](/versions/9.0.0/rules/lib/builtins/ctx#package_relative_label) can be used for the same purpose. Use these functions to mimic the string-to-label conversion that is automatically done by label-valued rule attributes.
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `input` | [string](../core/string); or [Label](../builtins/Label); required  The input label string or Label object. If a Label object is passed, it's returned as is. |
+| `input` | [string](/versions/9.0.0/rules/lib/core/string); or [Label](/versions/9.0.0/rules/lib/builtins/Label); required  The input label string or Label object. If a Label object is passed, it's returned as is. |
 
 ## name
 
@@ -66,7 +66,7 @@ Label Label.relative(relName)
 ```
 
 **Experimental**. This API is experimental and may change at any time. Please do not depend on it. It may be enabled on an experimental basis by setting `--+incompatible_enable_deprecated_label_apis`
-**Deprecated.** This method behaves surprisingly when used with an argument containing an apparent repo name. Prefer [`Label.same_package_label()`](#same_package_label), [`native.package_relative_label()`](../toplevel/native#package_relative_label), [`ctx.package_relative_label()`](ctx#package_relative_label), or [`Label()`](#Label) instead.
+**Deprecated.** This method behaves surprisingly when used with an argument containing an apparent repo name. Prefer [`Label.same_package_label()`](#same_package_label), [`native.package_relative_label()`](/versions/9.0.0/rules/lib/toplevel/native#package_relative_label), [`ctx.package_relative_label()`](/versions/9.0.0/rules/lib/builtins/ctx#package_relative_label), or [`Label()`](#Label) instead.
 
 Resolves a label that is either absolute (starts with `//`) or relative to the current package. If this label is in a remote repository, the argument will be resolved relative to that repository. If the argument contains a repository name, the current label is ignored and the argument is returned as-is, except that the repository name is rewritten if it is in the current repository mapping. Reserved labels will also be returned as-is.
 For example:
@@ -89,7 +89,7 @@ Label("@repo//foo/bar:baz").relative("@other//wiz:quux") == Label("@remapped//wi
 
 | Parameter | Description |
 | --- | --- |
-| `relName` | [string](../core/string); required |
+| `relName` | [string](/versions/9.0.0/rules/lib/core/string); required |
 
 ## repo\_name
 
@@ -115,7 +115,7 @@ Creates a label in the same package as this label with the given target name.
 
 | Parameter | Description |
 | --- | --- |
-| `target_name` | [string](../core/string); required |
+| `target_name` | [string](/versions/9.0.0/rules/lib/core/string); required |
 
 ## workspace\_name
 
diff --git a/versions/9.0.0/rules/lib/builtins/LateBoundDefault.mdx b/versions/9.0.0/rules/lib/builtins/LateBoundDefault.mdx
index edd0010c..0d493749 100644
--- a/versions/9.0.0/rules/lib/builtins/LateBoundDefault.mdx
+++ b/versions/9.0.0/rules/lib/builtins/LateBoundDefault.mdx
@@ -4,4 +4,4 @@ title: 'LateBoundDefault'
 
 Represents a late-bound default attribute value of type 'Label'. The value of a LateBoundDefault is only resolvable in the context of a rule implementation function, and depends on the current build configuration. For example, a LateBoundDefault might represent the Label of the java toolchain in the current build configuration.
 
-See [configuration\_field](../globals/bzl#configuration_field) for example usage.
\ No newline at end of file
+See [configuration\_field](/versions/9.0.0/rules/lib/globals/bzl#configuration_field) for example usage.
\ No newline at end of file
diff --git a/versions/9.0.0/rules/lib/builtins/Provider.mdx b/versions/9.0.0/rules/lib/builtins/Provider.mdx
index 54b9cf36..cb55f51f 100644
--- a/versions/9.0.0/rules/lib/builtins/Provider.mdx
+++ b/versions/9.0.0/rules/lib/builtins/Provider.mdx
@@ -14,7 +14,7 @@ This value has a dual purpose:
   ```
 
   Note: Some providers, defined internally, do not allow instance creation
-* It is a *key* to access a provider instance on a [Target](../builtins/Target)
+* It is a *key* to access a provider instance on a [Target](/versions/9.0.0/rules/lib/builtins/Target)
 
   ```
   DataInfo = provider()
@@ -22,4 +22,4 @@ This value has a dual purpose:
     ... ctx.attr.dep[DataInfo]
   ```
 
-Create a new `Provider` using the [provider](../globals/bzl#provider) function.
\ No newline at end of file
+Create a new `Provider` using the [provider](/versions/9.0.0/rules/lib/globals/bzl#provider) function.
\ No newline at end of file
diff --git a/versions/9.0.0/rules/lib/builtins/TemplateDict.mdx b/versions/9.0.0/rules/lib/builtins/TemplateDict.mdx
index 5f18fd44..8d55cfa9 100644
--- a/versions/9.0.0/rules/lib/builtins/TemplateDict.mdx
+++ b/versions/9.0.0/rules/lib/builtins/TemplateDict.mdx
@@ -21,8 +21,8 @@ Add a String value
 
 | Parameter | Description |
 | --- | --- |
-| `key` | [string](../core/string); required  A String key |
-| `value` | [string](../core/string); required  A String value |
+| `key` | [string](/versions/9.0.0/rules/lib/core/string); required  A String key |
+| `value` | [string](/versions/9.0.0/rules/lib/core/string); required  A String value |
 
 ## add\_joined
 
@@ -36,10 +36,10 @@ Add depset of values
 
 | Parameter | Description |
 | --- | --- |
-| `key` | [string](../core/string); required  A String key |
-| `values` | [depset](../builtins/depset); required  The depset whose items will be joined. |
-| `join_with` | [string](../core/string); required  A delimiter string used to join together the strings obtained from applying `map_each`, in the same manner as [`string.join()`](../core/string#join). |
+| `key` | [string](/versions/9.0.0/rules/lib/core/string); required  A String key |
+| `values` | [depset](/versions/9.0.0/rules/lib/builtins/depset); required  The depset whose items will be joined. |
+| `join_with` | [string](/versions/9.0.0/rules/lib/core/string); required  A delimiter string used to join together the strings obtained from applying `map_each`, in the same manner as [`string.join()`](/versions/9.0.0/rules/lib/core/string#join). |
 | `map_each` | callable; required  A Starlark function accepting a single argument and returning either a string, `None`, or a list of strings. This function is applied to each item of the depset specified in the `values` parameter |
-| `uniquify` | [bool](../core/bool); default is `False`  If true, duplicate strings derived from `values` will be omitted. Only the first occurrence of each string will remain. Usually this feature is not needed because depsets already omit duplicates, but it can be useful if `map_each` emits the same string for multiple items. |
-| `format_joined` | [string](../core/string); or `None`; default is `None`  An optional format string pattern applied to the joined string. The format string must have exactly one '%s' placeholder. |
-| `allow_closure` | [bool](../core/bool); default is `False`  If true, allows the use of closures in function parameters like `map_each`. Usually this isn't necessary and it risks retaining large analysis-phase data structures into the execution phase. |
\ No newline at end of file
+| `uniquify` | [bool](/versions/9.0.0/rules/lib/core/bool); default is `False`  If true, duplicate strings derived from `values` will be omitted. Only the first occurrence of each string will remain. Usually this feature is not needed because depsets already omit duplicates, but it can be useful if `map_each` emits the same string for multiple items. |
+| `format_joined` | [string](/versions/9.0.0/rules/lib/core/string); or `None`; default is `None`  An optional format string pattern applied to the joined string. The format string must have exactly one '%s' placeholder. |
+| `allow_closure` | [bool](/versions/9.0.0/rules/lib/core/bool); default is `False`  If true, allows the use of closures in function parameters like `map_each`. Usually this isn't necessary and it risks retaining large analysis-phase data structures into the execution phase. |
\ No newline at end of file
diff --git a/versions/9.0.0/rules/lib/builtins/actions.mdx b/versions/9.0.0/rules/lib/builtins/actions.mdx
index 5ecfedba..e236ed98 100644
--- a/versions/9.0.0/rules/lib/builtins/actions.mdx
+++ b/versions/9.0.0/rules/lib/builtins/actions.mdx
@@ -2,7 +2,7 @@
 title: 'actions'
 ---
 
-Module providing functions to create actions. Access this module using [`ctx.actions`](../builtins/ctx#actions).
+Module providing functions to create actions. Access this module using [`ctx.actions`](/versions/9.0.0/rules/lib/builtins/ctx#actions).
 
 ## Members
 
@@ -33,14 +33,14 @@ Returns an Args object that can be used to build memory-efficient command lines.
 File actions.declare_directory(filename, *, sibling=None)
 ```
 
-Declares that the rule or aspect creates a directory with the given name, in the current package. You must create an action that generates the directory. The contents of the directory are not directly accessible from Starlark, but can be expanded in an action command with [`Args.add_all()`](../builtins/Args#add_all). Only regular files and directories can be in the expanded contents of a declare\_directory.
+Declares that the rule or aspect creates a directory with the given name, in the current package. You must create an action that generates the directory. The contents of the directory are not directly accessible from Starlark, but can be expanded in an action command with [`Args.add_all()`](/versions/9.0.0/rules/lib/builtins/Args#add_all). Only regular files and directories can be in the expanded contents of a declare\_directory.
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `filename` | [string](../core/string); required  If no 'sibling' provided, path of the new directory, relative to the current package. Otherwise a base name for a file ('sibling' defines a directory). |
-| `sibling` | [File](../builtins/File); or `None`; default is `None`  A file that lives in the same directory as the newly declared directory. The file must be in the current package. |
+| `filename` | [string](/versions/9.0.0/rules/lib/core/string); required  If no 'sibling' provided, path of the new directory, relative to the current package. Otherwise a base name for a file ('sibling' defines a directory). |
+| `sibling` | [File](/versions/9.0.0/rules/lib/builtins/File); or `None`; default is `None`  A file that lives in the same directory as the newly declared directory. The file must be in the current package. |
 
 ## declare\_file
 
@@ -52,14 +52,14 @@ Declares that the rule or aspect creates a file with the given filename. If `sib
 
 Remember that in addition to declaring a file, you must separately create an action that emits the file. Creating that action will require passing the returned `File` object to the action's construction function.
 
-Note that [predeclared output files](https://bazel.build/versions/9.0.0/extending/rules#files) do not need to be (and cannot be) declared using this function. You can obtain their `File` objects from [`ctx.outputs`](../builtins/ctx#outputs) instead. [See example of use](https://github.com/bazelbuild/examples/tree/main/rules/computed_dependencies/hash.bzl).
+Note that [predeclared output files](https://bazel.build/versions/9.0.0/extending/rules#files) do not need to be (and cannot be) declared using this function. You can obtain their `File` objects from [`ctx.outputs`](/versions/9.0.0/rules/lib/builtins/ctx#outputs) instead. [See example of use](https://github.com/bazelbuild/examples/tree/main/rules/computed_dependencies/hash.bzl).
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `filename` | [string](../core/string); required  If no 'sibling' provided, path of the new file, relative to the current package. Otherwise a base name for a file ('sibling' determines a directory). |
-| `sibling` | [File](../builtins/File); or `None`; default is `None`  A file that lives in the same directory as the newly created file. The file must be in the current package. |
+| `filename` | [string](/versions/9.0.0/rules/lib/core/string); required  If no 'sibling' provided, path of the new file, relative to the current package. Otherwise a base name for a file ('sibling' determines a directory). |
+| `sibling` | [File](/versions/9.0.0/rules/lib/builtins/File); or `None`; default is `None`  A file that lives in the same directory as the newly created file. The file must be in the current package. |
 
 ## declare\_symlink
 
@@ -73,8 +73,8 @@ Declares that the rule or aspect creates a symlink with the given name in the cu
 
 | Parameter | Description |
 | --- | --- |
-| `filename` | [string](../core/string); required  If no 'sibling' provided, path of the new symlink, relative to the current package. Otherwise a base name for a file ('sibling' defines a directory). |
-| `sibling` | [File](../builtins/File); or `None`; default is `None`  A file that lives in the same directory as the newly declared symlink. |
+| `filename` | [string](/versions/9.0.0/rules/lib/core/string); required  If no 'sibling' provided, path of the new symlink, relative to the current package. Otherwise a base name for a file ('sibling' defines a directory). |
+| `sibling` | [File](/versions/9.0.0/rules/lib/builtins/File); or `None`; default is `None`  A file that lives in the same directory as the newly declared symlink. |
 
 ## do\_nothing
 
@@ -88,8 +88,8 @@ Creates an empty action that neither executes a command nor produces any output,
 
 | Parameter | Description |
 | --- | --- |
-| `mnemonic` | [string](../core/string); required  A one-word description of the action, for example, CppCompile or GoLink. |
-| `inputs` | [sequence](../core/list) of [File](../builtins/File)s; or [depset](../builtins/depset); default is `[]`  List of the input files of the action. |
+| `mnemonic` | [string](/versions/9.0.0/rules/lib/core/string); required  A one-word description of the action, for example, CppCompile or GoLink. |
+| `inputs` | [sequence](/versions/9.0.0/rules/lib/core/list) of [File](/versions/9.0.0/rules/lib/builtins/File)s; or [depset](/versions/9.0.0/rules/lib/builtins/depset); default is `[]`  List of the input files of the action. |
 
 ## expand\_template
 
@@ -103,11 +103,11 @@ Creates a template expansion action. When the action is executed, it will genera
 
 | Parameter | Description |
 | --- | --- |
-| `template` | [File](../builtins/File); required  The template file, which is a UTF-8 encoded text file. |
-| `output` | [File](../builtins/File); required  The output file, which is a UTF-8 encoded text file. |
-| `substitutions` | [dict](../core/dict); default is `{}`  Substitutions to make when expanding the template. |
-| `is_executable` | [bool](../core/bool); default is `False`  Whether the output file should be executable. |
-| `computed_substitutions` | [TemplateDict](../builtins/TemplateDict); default is `unbound`  Substitutions to make when expanding the template. |
+| `template` | [File](/versions/9.0.0/rules/lib/builtins/File); required  The template file, which is a UTF-8 encoded text file. |
+| `output` | [File](/versions/9.0.0/rules/lib/builtins/File); required  The output file, which is a UTF-8 encoded text file. |
+| `substitutions` | [dict](/versions/9.0.0/rules/lib/core/dict); default is `{}`  Substitutions to make when expanding the template. |
+| `is_executable` | [bool](/versions/9.0.0/rules/lib/core/bool); default is `False`  Whether the output file should be executable. |
+| `computed_substitutions` | [TemplateDict](/versions/9.0.0/rules/lib/builtins/TemplateDict); default is `unbound`  Substitutions to make when expanding the template. |
 
 ## map\_directory
 
@@ -121,18 +121,18 @@ Creates multiple actions based on the files within one or more input directories
 
 | Parameter | Description |
 | --- | --- |
-| `input_directories` | [dict](../core/dict) of [File](../builtins/File)s; required  A dictionary mapping of strings to input directories, as declared by `ctx.actions.declare_directory()` (only directories are allowed as values here). The values specify the directories that we want expanded to access their files in the implementation function. The keys (strings) act as identifiers to easily reference a specific directory in the implementation function. |
-| `additional_inputs` | [dict](../core/dict); default is `{}`  A dictionary of mapping of strings to additional inputs (only files, FilesToRunProvider(s) and Depset(s) are allowed here). The values specify any additional inputs that we want to make accessible to actions created by the implementation function. The keys (strings) act as identifiers to easily reference a specific input from within the implementation function. |
-| `output_directories` | [dict](../core/dict) of [File](../builtins/File)s; required  A dictionary mapping of strings to output directories, as declared by `ctx.actions.declare_directory()`. The values specify the output directories that we want to generate by the actions created by the implementation function. The keys (strings) act as identifiers to easily reference a specific output directory from within the implementation function. |
-| `tools` | [dict](../core/dict); required  A dictionary mapping of strings to tools (only files, FilesToRunProvider(s) and Depset(s) are allowed here). The values specify the tools that we want to make accessible to actions created by the implementation function. The keys (strings) act as identifiers to easily reference a specific tool from within the implementation function. |
-| `additional_params` | [dict](../core/dict); default is `{}`  A dictionary mapping of strings to additional parameters (only string, boolean and integer values are allowed here). The values specify any additional parameters that we want to make accessible to the implementation function that could be used to influence its behavior. The keys (strings) act as identifiers to easily reference a specific parameter from within the implementation function. |
-| `execution_requirements` | [dict](../core/dict); or `None`; default is `None`  Information for scheduling the created actions. See [tags](/versions/9.0.0/reference/be/common-definitions#common.tags) for useful keys. |
-| `exec_group` | [string](../core/string); or `None`; default is `None`  Run the created actions on the given exec group's execution platform. If none, uses the target's default execution platform. |
-| `toolchain` | [Label](../builtins/Label); or [string](../core/string); or `None`; default is `None`  Toolchain type of the executable or tools used by the created actions.  If executable and tools are not coming from a toolchain, set this parameter to `None`.  If executable and tools are coming from a toolchain, toolchain type must be set so that the created actions execute on the correct execution platform.  Note that the rule which creates these actions needs to define this toolchain inside its 'rule()' function.  When `toolchain` and `exec_group` parameters are both set, `exec_group` will be used. An error is raised in case the `exec_group` doesn't specify the same toolchain. |
-| `use_default_shell_env` | [bool](../core/bool); default is `False`  Whether the created actions should use the default shell environment, which consists of a few OS-dependent variables as well as variables set via [`--action_env`](/versions/9.0.0/reference/command-line-reference#flag--action_env). If both `use_default_shell_env` and `env` are set to `True`, values set in `env` will overwrite the default shell environment. |
-| `env` | [dict](../core/dict); or `None`; default is `None`  Sets the dictionary of environment variables. If both `use_default_shell_env` and `env` are set to `True`, values set in `env` will overwrite the default shell environment. |
-| `mnemonic` | [string](../core/string); or `None`; default is `None`  A one-word description of the created actions, for example, CppCompile or GoLink. |
-| `implementation` | [function](../core/function); required  A Starlark function that gets called after input directories have been built to generate actions that output files to the specified output directories. This function is passed the following arguments:  * `template_ctx` (positional): A [`template_ctx`](../builtins/template_ctx) object that can be used to   create actions. * `input_directories` (keyword-only): A dictionary mapping from the string keys of   the `input_directories` argument of `actions.map_directory()` to their   values' corresponding [`ExpandedDirectory`](../builtins/File)   objects. * `output_directories` (keyword-only): The value of the   `output_directories` argument of `actions.map_directory()`; a   dictionary mapping from strings to output directories. * `additional_inputs` (keyword-only): The value of the   `additional_inputs` argument of `actions.map_directory()`; a   dictionary mapping from strings to input files. * `tools` (keyword-only): The value of the `tools` argument of   `actions.map_directory()`; a dictionary mapping from strings to tools. * `additional_params` (keyword-only): The value of the   `additional_params` argument of `actions.map_directory()`; a   dictionary mapping from strings to strings, booleans, or integers.  This function must be top-level, i.e. lambdas and nested functions are not allowed. |
+| `input_directories` | [dict](/versions/9.0.0/rules/lib/core/dict) of [File](/versions/9.0.0/rules/lib/builtins/File)s; required  A dictionary mapping of strings to input directories, as declared by `ctx.actions.declare_directory()` (only directories are allowed as values here). The values specify the directories that we want expanded to access their files in the implementation function. The keys (strings) act as identifiers to easily reference a specific directory in the implementation function. |
+| `additional_inputs` | [dict](/versions/9.0.0/rules/lib/core/dict); default is `{}`  A dictionary of mapping of strings to additional inputs (only files, FilesToRunProvider(s) and Depset(s) are allowed here). The values specify any additional inputs that we want to make accessible to actions created by the implementation function. The keys (strings) act as identifiers to easily reference a specific input from within the implementation function. |
+| `output_directories` | [dict](/versions/9.0.0/rules/lib/core/dict) of [File](/versions/9.0.0/rules/lib/builtins/File)s; required  A dictionary mapping of strings to output directories, as declared by `ctx.actions.declare_directory()`. The values specify the output directories that we want to generate by the actions created by the implementation function. The keys (strings) act as identifiers to easily reference a specific output directory from within the implementation function. |
+| `tools` | [dict](/versions/9.0.0/rules/lib/core/dict); required  A dictionary mapping of strings to tools (only files, FilesToRunProvider(s) and Depset(s) are allowed here). The values specify the tools that we want to make accessible to actions created by the implementation function. The keys (strings) act as identifiers to easily reference a specific tool from within the implementation function. |
+| `additional_params` | [dict](/versions/9.0.0/rules/lib/core/dict); default is `{}`  A dictionary mapping of strings to additional parameters (only string, boolean and integer values are allowed here). The values specify any additional parameters that we want to make accessible to the implementation function that could be used to influence its behavior. The keys (strings) act as identifiers to easily reference a specific parameter from within the implementation function. |
+| `execution_requirements` | [dict](/versions/9.0.0/rules/lib/core/dict); or `None`; default is `None`  Information for scheduling the created actions. See [tags](/versions/9.0.0/reference/be/common-definitions#common.tags) for useful keys. |
+| `exec_group` | [string](/versions/9.0.0/rules/lib/core/string); or `None`; default is `None`  Run the created actions on the given exec group's execution platform. If none, uses the target's default execution platform. |
+| `toolchain` | [Label](/versions/9.0.0/rules/lib/builtins/Label); or [string](/versions/9.0.0/rules/lib/core/string); or `None`; default is `None`  Toolchain type of the executable or tools used by the created actions.  If executable and tools are not coming from a toolchain, set this parameter to `None`.  If executable and tools are coming from a toolchain, toolchain type must be set so that the created actions execute on the correct execution platform.  Note that the rule which creates these actions needs to define this toolchain inside its 'rule()' function.  When `toolchain` and `exec_group` parameters are both set, `exec_group` will be used. An error is raised in case the `exec_group` doesn't specify the same toolchain. |
+| `use_default_shell_env` | [bool](/versions/9.0.0/rules/lib/core/bool); default is `False`  Whether the created actions should use the default shell environment, which consists of a few OS-dependent variables as well as variables set via [`--action_env`](/versions/9.0.0/reference/command-line-reference#flag--action_env). If both `use_default_shell_env` and `env` are set to `True`, values set in `env` will overwrite the default shell environment. |
+| `env` | [dict](/versions/9.0.0/rules/lib/core/dict); or `None`; default is `None`  Sets the dictionary of environment variables. If both `use_default_shell_env` and `env` are set to `True`, values set in `env` will overwrite the default shell environment. |
+| `mnemonic` | [string](/versions/9.0.0/rules/lib/core/string); or `None`; default is `None`  A one-word description of the created actions, for example, CppCompile or GoLink. |
+| `implementation` | [function](/versions/9.0.0/rules/lib/core/function); required  A Starlark function that gets called after input directories have been built to generate actions that output files to the specified output directories. This function is passed the following arguments:  * `template_ctx` (positional): A [`template_ctx`](/versions/9.0.0/rules/lib/builtins/template_ctx) object that can be used to   create actions. * `input_directories` (keyword-only): A dictionary mapping from the string keys of   the `input_directories` argument of `actions.map_directory()` to their   values' corresponding [`ExpandedDirectory`](/versions/9.0.0/rules/lib/builtins/File)   objects. * `output_directories` (keyword-only): The value of the   `output_directories` argument of `actions.map_directory()`; a   dictionary mapping from strings to output directories. * `additional_inputs` (keyword-only): The value of the   `additional_inputs` argument of `actions.map_directory()`; a   dictionary mapping from strings to input files. * `tools` (keyword-only): The value of the `tools` argument of   `actions.map_directory()`; a dictionary mapping from strings to tools. * `additional_params` (keyword-only): The value of the   `additional_params` argument of `actions.map_directory()`; a   dictionary mapping from strings to strings, booleans, or integers.  This function must be top-level, i.e. lambdas and nested functions are not allowed. |
 
 ## run
 
@@ -146,22 +146,22 @@ Creates an action that runs an executable. [See example of use](https://github.c
 
 | Parameter | Description |
 | --- | --- |
-| `outputs` | [sequence](../core/list) of [File](../builtins/File)s; required  List of the output files of the action. |
-| `inputs` | [sequence](../core/list) of [File](../builtins/File)s; or [depset](../builtins/depset); default is `[]`  List or depset of the input files of the action. |
-| `unused_inputs_list` | [File](../builtins/File); or `None`; default is `None`  File containing list of inputs unused by the action. The content of this file (generally one of the outputs of the action) corresponds to the list of input files that were not used during the whole action execution. Any change in those files must not affect in any way the outputs of the action. |
-| `executable` | [File](../builtins/File); or [string](../core/string); or [FilesToRunProvider](../providers/FilesToRunProvider); required  The executable file to be called by the action. |
-| `tools` | [sequence](../core/list); or [depset](../builtins/depset); default is `unbound`  List or [`depset`](../builtins/depset) of any tools needed by the action. Tools are executable inputs that may have their own runfiles which are automatically made available to the action. When a list is provided, it can be a heterogenous collection of:  * `File`s * `FilesToRunProvider` instances * `depset`s of `File`s  `File`s from [`ctx.executable`](../builtins/ctx#executable) and `FilesToRunProvider`s which are directly in the list will have their runfiles automatically added. All tools are implicitly added as inputs. |
-| `arguments` | [sequence](../core/list); default is `[]`  Command line arguments of the action. Must be a list of strings or [`actions.args()`](#args) objects. |
-| `mnemonic` | [string](../core/string); or `None`; default is `None`  A one-word description of the action, for example, CppCompile or GoLink. |
-| `progress_message` | [string](../core/string); or `None`; default is `None`  Progress message to show to the user during the build, for example, "Compiling foo.cc to create foo.o". The message may contain `%{label}`, `%{input}`, or `%{output}` patterns, which are substituted with label string, first input, or output's path, respectively. Prefer to use patterns instead of static strings, because the former are more efficient. |
-| `use_default_shell_env` | [bool](../core/bool); default is `False`  Whether the action should use the default shell environment, which consists of a few OS-dependent variables as well as variables set via [`--action_env`](/versions/9.0.0/reference/command-line-reference#flag--action_env). If both `use_default_shell_env` and `env` are set to `True`, values set in `env` will overwrite the default shell environment. |
-| `env` | [dict](../core/dict); or `None`; default is `None`  Sets the dictionary of environment variables. If both `use_default_shell_env` and `env` are set to `True`, values set in `env` will overwrite the default shell environment. |
-| `execution_requirements` | [dict](../core/dict); or `None`; default is `None`  Information for scheduling the action. See [tags](/versions/9.0.0/reference/be/common-definitions#common.tags) for useful keys. |
-| `input_manifests` | [sequence](../core/list); or `None`; default is `None`  Legacy argument. Ignored. |
-| `exec_group` | [string](../core/string); or `None`; default is `None`  Runs the action on the given exec group's execution platform. If none, uses the target's default execution platform. |
-| `shadowed_action` | [Action](../builtins/Action); default is `None`  Runs the action using the given shadowed action's inputs and environment added to the action's inputs list and environment. The action environment can overwrite any of the shadowed action's environment variables. If none, uses only the action's inputs and given environment. |
+| `outputs` | [sequence](/versions/9.0.0/rules/lib/core/list) of [File](/versions/9.0.0/rules/lib/builtins/File)s; required  List of the output files of the action. |
+| `inputs` | [sequence](/versions/9.0.0/rules/lib/core/list) of [File](/versions/9.0.0/rules/lib/builtins/File)s; or [depset](/versions/9.0.0/rules/lib/builtins/depset); default is `[]`  List or depset of the input files of the action. |
+| `unused_inputs_list` | [File](/versions/9.0.0/rules/lib/builtins/File); or `None`; default is `None`  File containing list of inputs unused by the action. The content of this file (generally one of the outputs of the action) corresponds to the list of input files that were not used during the whole action execution. Any change in those files must not affect in any way the outputs of the action. |
+| `executable` | [File](/versions/9.0.0/rules/lib/builtins/File); or [string](/versions/9.0.0/rules/lib/core/string); or [FilesToRunProvider](/versions/9.0.0/rules/lib/providers/FilesToRunProvider); required  The executable file to be called by the action. |
+| `tools` | [sequence](/versions/9.0.0/rules/lib/core/list); or [depset](/versions/9.0.0/rules/lib/builtins/depset); default is `unbound`  List or [`depset`](/versions/9.0.0/rules/lib/builtins/depset) of any tools needed by the action. Tools are executable inputs that may have their own runfiles which are automatically made available to the action. When a list is provided, it can be a heterogenous collection of:  * `File`s * `FilesToRunProvider` instances * `depset`s of `File`s  `File`s from [`ctx.executable`](/versions/9.0.0/rules/lib/builtins/ctx#executable) and `FilesToRunProvider`s which are directly in the list will have their runfiles automatically added. All tools are implicitly added as inputs. |
+| `arguments` | [sequence](/versions/9.0.0/rules/lib/core/list); default is `[]`  Command line arguments of the action. Must be a list of strings or [`actions.args()`](#args) objects. |
+| `mnemonic` | [string](/versions/9.0.0/rules/lib/core/string); or `None`; default is `None`  A one-word description of the action, for example, CppCompile or GoLink. |
+| `progress_message` | [string](/versions/9.0.0/rules/lib/core/string); or `None`; default is `None`  Progress message to show to the user during the build, for example, "Compiling foo.cc to create foo.o". The message may contain `%{label}`, `%{input}`, or `%{output}` patterns, which are substituted with label string, first input, or output's path, respectively. Prefer to use patterns instead of static strings, because the former are more efficient. |
+| `use_default_shell_env` | [bool](/versions/9.0.0/rules/lib/core/bool); default is `False`  Whether the action should use the default shell environment, which consists of a few OS-dependent variables as well as variables set via [`--action_env`](/versions/9.0.0/reference/command-line-reference#flag--action_env). If both `use_default_shell_env` and `env` are set to `True`, values set in `env` will overwrite the default shell environment. |
+| `env` | [dict](/versions/9.0.0/rules/lib/core/dict); or `None`; default is `None`  Sets the dictionary of environment variables. If both `use_default_shell_env` and `env` are set to `True`, values set in `env` will overwrite the default shell environment. |
+| `execution_requirements` | [dict](/versions/9.0.0/rules/lib/core/dict); or `None`; default is `None`  Information for scheduling the action. See [tags](/versions/9.0.0/reference/be/common-definitions#common.tags) for useful keys. |
+| `input_manifests` | [sequence](/versions/9.0.0/rules/lib/core/list); or `None`; default is `None`  Legacy argument. Ignored. |
+| `exec_group` | [string](/versions/9.0.0/rules/lib/core/string); or `None`; default is `None`  Runs the action on the given exec group's execution platform. If none, uses the target's default execution platform. |
+| `shadowed_action` | [Action](/versions/9.0.0/rules/lib/builtins/Action); default is `None`  Runs the action using the given shadowed action's inputs and environment added to the action's inputs list and environment. The action environment can overwrite any of the shadowed action's environment variables. If none, uses only the action's inputs and given environment. |
 | `resource_set` | callable; or `None`; default is `None`  A callback function that returns a resource set dictionary, used to estimate resource usage at execution time if this action is run locally. The function accepts two positional arguments: a string representing an OS name (e.g. "osx"), and an integer representing the number of inputs to the action. The returned dictionary may contain the following entries, each of which may be a float or an int:  * "cpu": number of CPUs; default 1* "memory": in MB; default 250* "local\_test": number of local tests; default 1   If this parameter is set to `None` , the default values are used. The callback must be top-level (lambda and nested functions aren't allowed). |
-| `toolchain` | [Label](../builtins/Label); or [string](../core/string); or `None`; default is `unbound`  Toolchain type of the executable or tools used in this action.  If executable and tools are not coming from a toolchain, set this parameter to `None`.  If executable and tools are coming from a toolchain, toolchain type must be set so that the action executes on the correct execution platform.  Note that the rule which creates this action needs to define this toolchain inside its 'rule()' function.  When `toolchain` and `exec\_group` parameters are both set, `exec\_group` will be used. An error is raised in case the `exec\_group` doesn't specify the same toolchain. |
+| `toolchain` | [Label](/versions/9.0.0/rules/lib/builtins/Label); or [string](/versions/9.0.0/rules/lib/core/string); or `None`; default is `unbound`  Toolchain type of the executable or tools used in this action.  If executable and tools are not coming from a toolchain, set this parameter to `None`.  If executable and tools are coming from a toolchain, toolchain type must be set so that the action executes on the correct execution platform.  Note that the rule which creates this action needs to define this toolchain inside its 'rule()' function.  When `toolchain` and `exec\_group` parameters are both set, `exec\_group` will be used. An error is raised in case the `exec\_group` doesn't specify the same toolchain. |
 
 ## run\_shell
 
@@ -175,21 +175,21 @@ Creates an action that runs a shell command. [See example of use](https://github
 
 | Parameter | Description |
 | --- | --- |
-| `outputs` | [sequence](../core/list) of [File](../builtins/File)s; required  List of the output files of the action. |
-| `inputs` | [sequence](../core/list) of [File](../builtins/File)s; or [depset](../builtins/depset); default is `[]`  List or depset of the input files of the action. |
-| `tools` | [sequence](../core/list) of [File](../builtins/File)s; or [depset](../builtins/depset); default is `unbound`  List or [`depset`](../builtins/depset) of any tools needed by the action. Tools are executable inputs that may have their own runfiles which are automatically made available to the action. When a list is provided, it can be a heterogenous collection of:  * `File`s * `FilesToRunProvider` instances * `depset`s of `File`s  `File`s from [`ctx.executable`](../builtins/ctx#executable) and `FilesToRunProvider`s which are directly in the list will have their runfiles automatically added. All tools are implicitly added as inputs. |
-| `arguments` | [sequence](../core/list); default is `[]`  Command line arguments of the action. Must be a list of strings or [`actions.args()`](#args) objects. Bazel passes the elements in this attribute as arguments to the command.The command can access these arguments using shell variable substitutions such as `$1`, `$2`, etc. Note that since Args objects are flattened before indexing, if there is an Args object of unknown size then all subsequent strings will be at unpredictable indices. It may be useful to use `$@` (to retrieve all arguments) in conjunction with Args objects of indeterminate size. In the case where `command` is a list of strings, this parameter may not be used. |
-| `mnemonic` | [string](../core/string); or `None`; default is `None`  A one-word description of the action, for example, CppCompile or GoLink. |
-| `command` | [string](../core/string); or [sequence](../core/list) of [string](../core/string)s; required  Shell command to execute. This may either be a string (preferred) or a sequence of strings **(deprecated)**. If `command` is a string, then it is executed as if by `sh -c  "" ` -- that is, the elements in `arguments` are made available to the command as `$1`, `$2` (or `%1`, `%2` if using Windows batch), etc. If `arguments` contains any [`actions.args()`](#args) objects, their contents are appended one by one to the command line, so `$`*i* can refer to individual strings within an Args object. Note that if an Args object of unknown size is passed as part of `arguments`, then the strings will be at unknown indices; in this case the `$@` shell substitution (retrieve all arguments) may be useful. **(Deprecated)** If `command` is a sequence of strings, the first item is the executable to run and the remaining items are its arguments. If this form is used, the `arguments` parameter must not be supplied. *Note that this form is deprecated and will soon be removed. It is disabled with `--incompatible\_run\_shell\_command\_string`. Use this flag to verify your code is compatible.*  Bazel uses the same shell to execute the command as it does for genrules. |
-| `progress_message` | [string](../core/string); or `None`; default is `None`  Progress message to show to the user during the build, for example, "Compiling foo.cc to create foo.o". The message may contain `%{label}`, `%{input}`, or `%{output}` patterns, which are substituted with label string, first input, or output's path, respectively. Prefer to use patterns instead of static strings, because the former are more efficient. |
-| `use_default_shell_env` | [bool](../core/bool); default is `False`  Whether the action should use the default shell environment, which consists of a few OS-dependent variables as well as variables set via [`--action_env`](/versions/9.0.0/reference/command-line-reference#flag--action_env). If both `use_default_shell_env` and `env` are set to `True`, values set in `env` will overwrite the default shell environment. |
-| `env` | [dict](../core/dict); or `None`; default is `None`  Sets the dictionary of environment variables. If both `use_default_shell_env` and `env` are set to `True`, values set in `env` will overwrite the default shell environment. |
-| `execution_requirements` | [dict](../core/dict); or `None`; default is `None`  Information for scheduling the action. See [tags](/versions/9.0.0/reference/be/common-definitions#common.tags) for useful keys. |
-| `input_manifests` | [sequence](../core/list); or `None`; default is `None`  Legacy argument. Ignored. |
-| `exec_group` | [string](../core/string); or `None`; default is `None`  Runs the action on the given exec group's execution platform. If none, uses the target's default execution platform. |
-| `shadowed_action` | [Action](../builtins/Action); default is `None`  Runs the action using the given shadowed action's discovered inputs added to the action's inputs list. If none, uses only the action's inputs. |
+| `outputs` | [sequence](/versions/9.0.0/rules/lib/core/list) of [File](/versions/9.0.0/rules/lib/builtins/File)s; required  List of the output files of the action. |
+| `inputs` | [sequence](/versions/9.0.0/rules/lib/core/list) of [File](/versions/9.0.0/rules/lib/builtins/File)s; or [depset](/versions/9.0.0/rules/lib/builtins/depset); default is `[]`  List or depset of the input files of the action. |
+| `tools` | [sequence](/versions/9.0.0/rules/lib/core/list) of [File](/versions/9.0.0/rules/lib/builtins/File)s; or [depset](/versions/9.0.0/rules/lib/builtins/depset); default is `unbound`  List or [`depset`](/versions/9.0.0/rules/lib/builtins/depset) of any tools needed by the action. Tools are executable inputs that may have their own runfiles which are automatically made available to the action. When a list is provided, it can be a heterogenous collection of:  * `File`s * `FilesToRunProvider` instances * `depset`s of `File`s  `File`s from [`ctx.executable`](/versions/9.0.0/rules/lib/builtins/ctx#executable) and `FilesToRunProvider`s which are directly in the list will have their runfiles automatically added. All tools are implicitly added as inputs. |
+| `arguments` | [sequence](/versions/9.0.0/rules/lib/core/list); default is `[]`  Command line arguments of the action. Must be a list of strings or [`actions.args()`](#args) objects. Bazel passes the elements in this attribute as arguments to the command.The command can access these arguments using shell variable substitutions such as `$1`, `$2`, etc. Note that since Args objects are flattened before indexing, if there is an Args object of unknown size then all subsequent strings will be at unpredictable indices. It may be useful to use `$@` (to retrieve all arguments) in conjunction with Args objects of indeterminate size. In the case where `command` is a list of strings, this parameter may not be used. |
+| `mnemonic` | [string](/versions/9.0.0/rules/lib/core/string); or `None`; default is `None`  A one-word description of the action, for example, CppCompile or GoLink. |
+| `command` | [string](/versions/9.0.0/rules/lib/core/string); or [sequence](/versions/9.0.0/rules/lib/core/list) of [string](/versions/9.0.0/rules/lib/core/string)s; required  Shell command to execute. This may either be a string (preferred) or a sequence of strings **(deprecated)**. If `command` is a string, then it is executed as if by `sh -c  "" ` -- that is, the elements in `arguments` are made available to the command as `$1`, `$2` (or `%1`, `%2` if using Windows batch), etc. If `arguments` contains any [`actions.args()`](#args) objects, their contents are appended one by one to the command line, so `$`*i* can refer to individual strings within an Args object. Note that if an Args object of unknown size is passed as part of `arguments`, then the strings will be at unknown indices; in this case the `$@` shell substitution (retrieve all arguments) may be useful. **(Deprecated)** If `command` is a sequence of strings, the first item is the executable to run and the remaining items are its arguments. If this form is used, the `arguments` parameter must not be supplied. *Note that this form is deprecated and will soon be removed. It is disabled with `--incompatible\_run\_shell\_command\_string`. Use this flag to verify your code is compatible.*  Bazel uses the same shell to execute the command as it does for genrules. |
+| `progress_message` | [string](/versions/9.0.0/rules/lib/core/string); or `None`; default is `None`  Progress message to show to the user during the build, for example, "Compiling foo.cc to create foo.o". The message may contain `%{label}`, `%{input}`, or `%{output}` patterns, which are substituted with label string, first input, or output's path, respectively. Prefer to use patterns instead of static strings, because the former are more efficient. |
+| `use_default_shell_env` | [bool](/versions/9.0.0/rules/lib/core/bool); default is `False`  Whether the action should use the default shell environment, which consists of a few OS-dependent variables as well as variables set via [`--action_env`](/versions/9.0.0/reference/command-line-reference#flag--action_env). If both `use_default_shell_env` and `env` are set to `True`, values set in `env` will overwrite the default shell environment. |
+| `env` | [dict](/versions/9.0.0/rules/lib/core/dict); or `None`; default is `None`  Sets the dictionary of environment variables. If both `use_default_shell_env` and `env` are set to `True`, values set in `env` will overwrite the default shell environment. |
+| `execution_requirements` | [dict](/versions/9.0.0/rules/lib/core/dict); or `None`; default is `None`  Information for scheduling the action. See [tags](/versions/9.0.0/reference/be/common-definitions#common.tags) for useful keys. |
+| `input_manifests` | [sequence](/versions/9.0.0/rules/lib/core/list); or `None`; default is `None`  Legacy argument. Ignored. |
+| `exec_group` | [string](/versions/9.0.0/rules/lib/core/string); or `None`; default is `None`  Runs the action on the given exec group's execution platform. If none, uses the target's default execution platform. |
+| `shadowed_action` | [Action](/versions/9.0.0/rules/lib/builtins/Action); default is `None`  Runs the action using the given shadowed action's discovered inputs added to the action's inputs list. If none, uses only the action's inputs. |
 | `resource_set` | callable; or `None`; default is `None`  A callback function for estimating resource usage if run locally. See[`ctx.actions.run()`](#run.resource_set). |
-| `toolchain` | [Label](../builtins/Label); or [string](../core/string); or `None`; default is `unbound`  Toolchain type of the executable or tools used in this action.  If executable and tools are not coming from a toolchain, set this parameter to `None`.  If executable and tools are coming from a toolchain, toolchain type must be set so that the action executes on the correct execution platform.  Note that the rule which creates this action needs to define this toolchain inside its 'rule()' function.  When `toolchain` and `exec\_group` parameters are both set, `exec\_group` will be used. An error is raised in case the `exec\_group` doesn't specify the same toolchain. |
+| `toolchain` | [Label](/versions/9.0.0/rules/lib/builtins/Label); or [string](/versions/9.0.0/rules/lib/core/string); or `None`; default is `unbound`  Toolchain type of the executable or tools used in this action.  If executable and tools are not coming from a toolchain, set this parameter to `None`.  If executable and tools are coming from a toolchain, toolchain type must be set so that the action executes on the correct execution platform.  Note that the rule which creates this action needs to define this toolchain inside its 'rule()' function.  When `toolchain` and `exec\_group` parameters are both set, `exec\_group` will be used. An error is raised in case the `exec\_group` doesn't specify the same toolchain. |
 
 ## symlink
 
@@ -209,12 +209,12 @@ Otherwise, when you use `target_path`, declare `output` with [`declare_symlink()
 
 | Parameter | Description |
 | --- | --- |
-| `output` | [File](../builtins/File); required  The output of this action. |
-| `target_file` | [File](../builtins/File); or `None`; default is `None`  The File that the output symlink will point to. |
-| `target_path` | [string](../core/string); or `None`; default is `None`  The exact path that the output symlink will point to. No normalization or other processing is applied. |
-| `target_type` | [string](../core/string); or `None`; default is `None`  May only be used with `target_path`, not `target_file`. If specified, it must be one of 'file' or 'directory', indicating the target path's expected type. On Windows, this determines which kind of filesystem object to create (junction for a directory, symlink for a file). It has no effect on other operating systems. |
-| `is_executable` | [bool](../core/bool); default is `False`  May only be used with `target_file`, not `target_path`. If true, when the action is executed, the `target_file`'s path is checked to confirm that it is executable, and an error is reported if it is not. Setting `is_executable` to False does not mean the target is not executable, just that no verification is done. This feature does not make sense for `target_path` because dangling symlinks might not exist at build time. |
-| `progress_message` | [string](../core/string); or `None`; default is `None`  Progress message to show to the user during the build. |
+| `output` | [File](/versions/9.0.0/rules/lib/builtins/File); required  The output of this action. |
+| `target_file` | [File](/versions/9.0.0/rules/lib/builtins/File); or `None`; default is `None`  The File that the output symlink will point to. |
+| `target_path` | [string](/versions/9.0.0/rules/lib/core/string); or `None`; default is `None`  The exact path that the output symlink will point to. No normalization or other processing is applied. |
+| `target_type` | [string](/versions/9.0.0/rules/lib/core/string); or `None`; default is `None`  May only be used with `target_path`, not `target_file`. If specified, it must be one of 'file' or 'directory', indicating the target path's expected type. On Windows, this determines which kind of filesystem object to create (junction for a directory, symlink for a file). It has no effect on other operating systems. |
+| `is_executable` | [bool](/versions/9.0.0/rules/lib/core/bool); default is `False`  May only be used with `target_file`, not `target_path`. If true, when the action is executed, the `target_file`'s path is checked to confirm that it is executable, and an error is reported if it is not. Setting `is_executable` to False does not mean the target is not executable, just that no verification is done. This feature does not make sense for `target_path` because dangling symlinks might not exist at build time. |
+| `progress_message` | [string](/versions/9.0.0/rules/lib/core/string); or `None`; default is `None`  Progress message to show to the user during the build. |
 
 ## template\_dict
 
@@ -236,7 +236,7 @@ Creates a file write action. When the action is executed, it will write the give
 
 | Parameter | Description |
 | --- | --- |
-| `output` | [File](../builtins/File); required  The output file. |
-| `content` | [string](../core/string); or [Args](../builtins/Args); required  the contents of the file. May be a either a string or an [`actions.args()`](#args) object. |
-| `is_executable` | [bool](../core/bool); default is `False`  Whether the output file should be executable. |
-| `mnemonic` | [string](../core/string); or `None`; default is `None`  A one-word description of the action, for example, CppCompile or GoLink. |
\ No newline at end of file
+| `output` | [File](/versions/9.0.0/rules/lib/builtins/File); required  The output file. |
+| `content` | [string](/versions/9.0.0/rules/lib/core/string); or [Args](/versions/9.0.0/rules/lib/builtins/Args); required  the contents of the file. May be a either a string or an [`actions.args()`](#args) object. |
+| `is_executable` | [bool](/versions/9.0.0/rules/lib/core/bool); default is `False`  Whether the output file should be executable. |
+| `mnemonic` | [string](/versions/9.0.0/rules/lib/core/string); or `None`; default is `None`  A one-word description of the action, for example, CppCompile or GoLink. |
\ No newline at end of file
diff --git a/versions/9.0.0/rules/lib/builtins/apple_platform.mdx b/versions/9.0.0/rules/lib/builtins/apple_platform.mdx
index ba2fc42e..7db0e012 100644
--- a/versions/9.0.0/rules/lib/builtins/apple_platform.mdx
+++ b/versions/9.0.0/rules/lib/builtins/apple_platform.mdx
@@ -4,7 +4,7 @@ title: 'apple\_platform'
 
 Corresponds to Xcode's notion of a platform as would be found in `Xcode.app/Contents/Developer/Platforms`. Each platform represents an Apple platform type (such as iOS or tvOS) combined with one or more related CPU architectures. For example, the iOS simulator platform supports `x86_64` and `i386` architectures.
 
-Specific instances of this type can be retrieved from the fields of the [apple\_common.platform](../toplevel/apple_common#platform) struct:
+Specific instances of this type can be retrieved from the fields of the [apple\_common.platform](/versions/9.0.0/rules/lib/toplevel/apple_common#platform) struct:
 
 * `apple_common.platform.ios_device`
 * `apple_common.platform.ios_simulator`
@@ -14,7 +14,7 @@ Specific instances of this type can be retrieved from the fields of the [apple\_
 * `apple_common.platform.watchos_device`
 * `apple_common.platform.watchos_simulator`
 
-More commonly, however, the [apple](../fragments/apple) configuration fragment has fields/methods that allow rules to determine the platform for which a target is being built.
+More commonly, however, the [apple](/versions/9.0.0/rules/lib/fragments/apple) configuration fragment has fields/methods that allow rules to determine the platform for which a target is being built.
 
 Example:
 
diff --git a/versions/9.0.0/rules/lib/builtins/configuration.mdx b/versions/9.0.0/rules/lib/builtins/configuration.mdx
index 4fc6786a..e1c71278 100644
--- a/versions/9.0.0/rules/lib/builtins/configuration.mdx
+++ b/versions/9.0.0/rules/lib/builtins/configuration.mdx
@@ -18,7 +18,7 @@ This object holds information about the environment in which the build is runnin
 bool configuration.coverage_enabled
 ```
 
-A boolean that tells whether code coverage is enabled for this run. Note that this does not compute whether a specific rule should be instrumented for code coverage data collection. For that, see the [`ctx.coverage_instrumented`](../builtins/ctx#coverage_instrumented) function.
+A boolean that tells whether code coverage is enabled for this run. Note that this does not compute whether a specific rule should be instrumented for code coverage data collection. For that, see the [`ctx.coverage_instrumented`](/versions/9.0.0/rules/lib/builtins/ctx#coverage_instrumented) function.
 
 ## default\_shell\_env
 
diff --git a/versions/9.0.0/rules/lib/builtins/ctx.mdx b/versions/9.0.0/rules/lib/builtins/ctx.mdx
index e602f13a..c5425248 100644
--- a/versions/9.0.0/rules/lib/builtins/ctx.mdx
+++ b/versions/9.0.0/rules/lib/builtins/ctx.mdx
@@ -67,7 +67,7 @@ A list of ids for all aspects applied to the target. Only available in aspect im
 struct ctx.attr
 ```
 
-A struct to access the values of the [attributes](https://bazel.build/versions/9.0.0/extending/rules#attributes). The values are provided by the user (if not, a default value is used). The attributes of the struct and the types of their values correspond to the keys and values of the [`attrs` dict](../globals/bzl#rule.attrs) provided to the [`rule` function](../globals/bzl#rule). [See example of use](https://github.com/bazelbuild/examples/blob/main/rules/attributes/printer.bzl).
+A struct to access the values of the [attributes](https://bazel.build/versions/9.0.0/extending/rules#attributes). The values are provided by the user (if not, a default value is used). The attributes of the struct and the types of their values correspond to the keys and values of the [`attrs` dict](/versions/9.0.0/rules/lib/globals/bzl#rule.attrs) provided to the [`rule` function](/versions/9.0.0/rules/lib/globals/bzl#rule). [See example of use](https://github.com/bazelbuild/examples/blob/main/rules/attributes/printer.bzl).
 
 ## bin\_dir
 
@@ -99,7 +99,7 @@ Value of the build setting represented by the current target. If this isn't the
 configuration ctx.configuration
 ```
 
-The default configuration. See the [configuration](../builtins/configuration) type for more details.
+The default configuration. See the [configuration](/versions/9.0.0/rules/lib/builtins/configuration) type for more details.
 
 ## coverage\_instrumented
 
@@ -107,13 +107,13 @@ The default configuration. See the [configuration](../builtins/configuration) ty
 bool ctx.coverage_instrumented(target=None)
 ```
 
-Returns whether code coverage instrumentation should be generated when performing compilation actions for this rule or, if `target` is provided, the rule specified by that Target. (If a non-rule or a Starlark rule Target is provided, this returns False.) Checks if the sources of the current rule (if no Target is provided) or the sources of Target should be instrumented based on the --instrumentation\_filter and --instrument\_test\_targets config settings. This differs from `coverage_enabled` in the [configuration](../builtins/configuration), which notes whether coverage data collection is enabled for the entire run, but not whether a specific target should be instrumented.
+Returns whether code coverage instrumentation should be generated when performing compilation actions for this rule or, if `target` is provided, the rule specified by that Target. (If a non-rule or a Starlark rule Target is provided, this returns False.) Checks if the sources of the current rule (if no Target is provided) or the sources of Target should be instrumented based on the --instrumentation\_filter and --instrument\_test\_targets config settings. This differs from `coverage_enabled` in the [configuration](/versions/9.0.0/rules/lib/builtins/configuration), which notes whether coverage data collection is enabled for the entire run, but not whether a specific target should be instrumented.
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `target` | [Target](../builtins/Target); or `None`; default is `None`  A Target specifying a rule. If not provided, defaults to the current rule. |
+| `target` | [Target](/versions/9.0.0/rules/lib/builtins/Target); or `None`; default is `None`  A Target specifying a rule. If not provided, defaults to the current rule. |
 
 ## created\_actions
 
@@ -121,7 +121,7 @@ Returns whether code coverage instrumentation should be generated when performin
 StarlarkValue ctx.created_actions()
 ```
 
-For rules with [\_skylark\_testable](../globals/bzl#rule._skylark_testable) set to `True`, this returns an `Actions` provider representing all actions created so far for the current rule. For all other rules, returns `None`. Note that the provider is not updated when subsequent actions are created, so you will have to call this function again if you wish to inspect them.
+For rules with [\_skylark\_testable](/versions/9.0.0/rules/lib/globals/bzl#rule._skylark_testable) set to `True`, this returns an `Actions` provider representing all actions created so far for the current rule. For all other rules, returns `None`. Note that the provider is not updated when subsequent actions are created, so you will have to call this function again if you wish to inspect them.
 
 This is intended to help write tests for rule-implementation helper functions, which may take in a `ctx` object and create actions on it.
 
@@ -147,7 +147,7 @@ A collection of the execution groups available for this rule, indexed by their n
 struct ctx.executable
 ```
 
-A `struct` containing executable files defined in [label type attributes](../toplevel/attr#label) marked as [`executable=True`](../toplevel/attr#label.executable). The struct fields correspond to the attribute names. Each value in the struct is either a [`File`](../builtins/File) or `None`. If an optional attribute is not specified in the rule then the corresponding struct value is `None`. If a label type is not marked as `executable=True`, no corresponding struct field is generated. [See example of use](https://github.com/bazelbuild/examples/blob/main/rules/actions_run/execute.bzl).
+A `struct` containing executable files defined in [label type attributes](/versions/9.0.0/rules/lib/toplevel/attr#label) marked as [`executable=True`](/versions/9.0.0/rules/lib/toplevel/attr#label.executable). The struct fields correspond to the attribute names. Each value in the struct is either a [`File`](/versions/9.0.0/rules/lib/builtins/File) or `None`. If an optional attribute is not specified in the rule then the corresponding struct value is `None`. If a label type is not marked as `executable=True`, no corresponding struct field is generated. [See example of use](https://github.com/bazelbuild/examples/blob/main/rules/actions_run/execute.bzl).
 
 ## expand\_location
 
@@ -165,8 +165,8 @@ This function is useful to let the user specify a command in a BUILD file (like
 
 | Parameter | Description |
 | --- | --- |
-| `input` | [string](../core/string); required  String to be expanded. |
-| `targets` | [sequence](../core/list) of [Target](../builtins/Target)s; default is `[]`  List of targets for additional lookup information. These are expanded as follows: A target with a single file in `DefaultInfo.files` expands to that file. Other targets expand to their `DefaultInfo.executable` file if set and if `--incompatible_locations_prefers_executable` is enabled, otherwise they expand to `DefaultInfo.files`. |
+| `input` | [string](/versions/9.0.0/rules/lib/core/string); required  String to be expanded. |
+| `targets` | [sequence](/versions/9.0.0/rules/lib/core/list) of [Target](/versions/9.0.0/rules/lib/builtins/Target)s; default is `[]`  List of targets for additional lookup information. These are expanded as follows: A target with a single file in `DefaultInfo.files` expands to that file. Other targets expand to their `DefaultInfo.executable` file if set and if `--incompatible_locations_prefers_executable` is enabled, otherwise they expand to `DefaultInfo.files`. |
 
 May return `None`.
 
@@ -176,7 +176,7 @@ May return `None`.
 string ctx.expand_make_variables(attribute_name, command, additional_substitutions)
 ```
 
-**Deprecated.** Use [ctx.var](../builtins/ctx#var) to access the variables instead.
+**Deprecated.** Use [ctx.var](/versions/9.0.0/rules/lib/builtins/ctx#var) to access the variables instead.
 Returns a string after expanding all references to "Make variables". The variables must have the following format: `$(VAR_NAME)`. Also, `$$VAR_NAME` expands to `$VAR_NAME`. Examples:
 
 ```
@@ -190,9 +190,9 @@ Additional variables may come from other places, such as configurations. Note th
 
 | Parameter | Description |
 | --- | --- |
-| `attribute_name` | [string](../core/string); required |
-| `command` | [string](../core/string); required  The expression to expand. It can contain references to "Make variables". |
-| `additional_substitutions` | [dict](../core/dict); required  Additional substitutions to make beyond the default make variables. |
+| `attribute_name` | [string](/versions/9.0.0/rules/lib/core/string); required |
+| `command` | [string](/versions/9.0.0/rules/lib/core/string); required  The expression to expand. It can contain references to "Make variables". |
+| `additional_substitutions` | [dict](/versions/9.0.0/rules/lib/core/dict); required  Additional substitutions to make beyond the default make variables. |
 
 ## features
 
@@ -208,7 +208,7 @@ The set of features that are explicitly enabled by the user for this rule. [See
 struct ctx.file
 ```
 
-A `struct` containing files defined in [label type attributes](../toplevel/attr#label) marked as [`allow_single_file`](../toplevel/attr#label.allow_single_file). The struct fields correspond to the attribute names. The struct value is always a [`File`](../builtins/File) or `None`. If an optional attribute is not specified in the rule then the corresponding struct value is `None`. If a label type is not marked as `allow_single_file`, no corresponding struct field is generated. It is a shortcut for:
+A `struct` containing files defined in [label type attributes](/versions/9.0.0/rules/lib/toplevel/attr#label) marked as [`allow_single_file`](/versions/9.0.0/rules/lib/toplevel/attr#label.allow_single_file). The struct fields correspond to the attribute names. The struct value is always a [`File`](/versions/9.0.0/rules/lib/builtins/File) or `None`. If an optional attribute is not specified in the rule then the corresponding struct value is `None`. If a label type is not marked as `allow_single_file`, no corresponding struct field is generated. It is a shortcut for:
 
 ```
 list(ctx.attr..files)[0]
@@ -222,7 +222,7 @@ In other words, use `file` to access the (singular) [default output](https://baz
 struct ctx.files
 ```
 
-A `struct` containing files defined in [label](../toplevel/attr#label) or [label list](../toplevel/attr#label_list) type attributes. The struct fields correspond to the attribute names. The struct values are `list` of [`File`](../builtins/File)s. It is a shortcut for:
+A `struct` containing files defined in [label](/versions/9.0.0/rules/lib/toplevel/attr#label) or [label list](/versions/9.0.0/rules/lib/toplevel/attr#label_list) type attributes. The struct fields correspond to the attribute names. The struct values are `list` of [`File`](/versions/9.0.0/rules/lib/builtins/File)s. It is a shortcut for:
 
 ```
 [f for t in ctx.attr. for f in t.files]
@@ -268,13 +268,13 @@ The label of the target currently being analyzed.
 structure ctx.outputs
 ```
 
-A pseudo-struct containing all the predeclared output files, represented by [`File`](../builtins/File) objects. See the [Rules page](https://bazel.build/versions/9.0.0/extending/rules#files) for more information and examples.
+A pseudo-struct containing all the predeclared output files, represented by [`File`](/versions/9.0.0/rules/lib/builtins/File) objects. See the [Rules page](https://bazel.build/versions/9.0.0/extending/rules#files) for more information and examples.
 
 This field does not exist on aspect contexts, since aspects do not have predeclared outputs.
 
 The fields of this object are defined as follows. It is an error if two outputs produce the same field name or have the same label.
 
-* If the rule declares an [`outputs`](../globals/bzl#rule.outputs) dict, then for every entry in the dict, there is a field whose name is the key and whose value is the corresponding `File`.* For every attribute of type [`attr.output`](../toplevel/attr#output) that the rule declares, there is a field whose name is the attribute's name. If the target specified a label for that attribute, then the field value is the corresponding `File`; otherwise the field value is `None`.* For every attribute of type [`attr.output_list`](../toplevel/attr#output_list) that the rule declares, there is a field whose name is the attribute's name. The field value is a list of `File` objects corresponding to the labels given for that attribute in the target, or an empty list if the attribute was not specified in the target.* **(Deprecated)** If the rule is marked [`executable`](../globals/bzl#rule.executable) or [`test`](../globals/bzl#rule.test), there is a field named `"executable"`, which is the default executable. It is recommended that instead of using this, you pass another file (either predeclared or not) to the `executable` arg of [`DefaultInfo`](../providers/DefaultInfo).
+* If the rule declares an [`outputs`](/versions/9.0.0/rules/lib/globals/bzl#rule.outputs) dict, then for every entry in the dict, there is a field whose name is the key and whose value is the corresponding `File`.* For every attribute of type [`attr.output`](/versions/9.0.0/rules/lib/toplevel/attr#output) that the rule declares, there is a field whose name is the attribute's name. If the target specified a label for that attribute, then the field value is the corresponding `File`; otherwise the field value is `None`.* For every attribute of type [`attr.output_list`](/versions/9.0.0/rules/lib/toplevel/attr#output_list) that the rule declares, there is a field whose name is the attribute's name. The field value is a list of `File` objects corresponding to the labels given for that attribute in the target, or an empty list if the attribute was not specified in the target.* **(Deprecated)** If the rule is marked [`executable`](/versions/9.0.0/rules/lib/globals/bzl#rule.executable) or [`test`](/versions/9.0.0/rules/lib/globals/bzl#rule.test), there is a field named `"executable"`, which is the default executable. It is recommended that instead of using this, you pass another file (either predeclared or not) to the `executable` arg of [`DefaultInfo`](/versions/9.0.0/rules/lib/providers/DefaultInfo).
 
 ## package\_relative\_label
 
@@ -282,17 +282,17 @@ The fields of this object are defined as follows. It is an error if two outputs
 Label ctx.package_relative_label(input)
 ```
 
-Converts the input string into a [Label](../builtins/Label) object, in the context of the package of the target currently being analyzed. If the input is already a `Label`, it is returned unchanged.
+Converts the input string into a [Label](/versions/9.0.0/rules/lib/builtins/Label) object, in the context of the package of the target currently being analyzed. If the input is already a `Label`, it is returned unchanged.
 
-The result of this function is the same `Label` value as would be produced by passing the given string to a label-valued attribute of the rule and accessing the corresponding [`Target.label`](../builtins/Target#label) field.
-
Usage note: The difference between this function and [`Label()`](../builtins/Label) is that `Label()` uses the context of the package of the `.bzl` file that called it, not the package of the target currently being analyzed. This function has the same behavior as [`native.package_relative_label()`](../toplevel/native#package_relative_label), which cannot be used in a rule or
+The result of this function is the same `Label` value as would be produced by passing the given string to a label-valued attribute of the rule and accessing the corresponding [`Target.label`](/versions/9.0.0/rules/lib/builtins/Target#label) field.
+
Usage note: The difference between this function and [`Label()`](/versions/9.0.0/rules/lib/builtins/Label) is that `Label()` uses the context of the package of the `.bzl` file that called it, not the package of the target currently being analyzed. This function has the same behavior as [`native.package_relative_label()`](/versions/9.0.0/rules/lib/toplevel/native#package_relative_label), which cannot be used in a rule or
 aspect implementation function.

 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `input` | [string](../core/string); or [Label](../builtins/Label); required  The input label string or Label object. If a Label object is passed, it's returned as is. |
+| `input` | [string](/versions/9.0.0/rules/lib/core/string); or [Label](/versions/9.0.0/rules/lib/builtins/Label); required  The input label string or Label object. If a Label object is passed, it's returned as is. |
 
 ## resolve\_command
 
@@ -307,13 +307,13 @@ tuple ctx.resolve_command(*, command='', attribute=None, expand_locations=False,
 
 | Parameter | Description |
 | --- | --- |
-| `command` | [string](../core/string); default is `''`  Command to resolve. |
-| `attribute` | [string](../core/string); or `None`; default is `None`  Name of the associated attribute for which to issue an error, or None. |
-| `expand_locations` | [bool](../core/bool); default is `False`  Shall we expand $(location) variables? See [ctx.expand\_location()](#expand_location) for more details. |
-| `make_variables` | [dict](../core/dict); or `None`; default is `None`  Make variables to expand, or None. |
-| `tools` | [sequence](../core/list) of [Target](../builtins/Target)s; default is `[]`  List of tools (list of targets). |
-| `label_dict` | [dict](../core/dict); default is `{}`  Dictionary of resolved labels and the corresponding list of Files (a dict of Label : list of Files). |
-| `execution_requirements` | [dict](../core/dict); default is `{}`  Information for scheduling the action to resolve this command. See [tags](/versions/9.0.0/reference/be/common-definitions#common.tags) for useful keys. |
+| `command` | [string](/versions/9.0.0/rules/lib/core/string); default is `''`  Command to resolve. |
+| `attribute` | [string](/versions/9.0.0/rules/lib/core/string); or `None`; default is `None`  Name of the associated attribute for which to issue an error, or None. |
+| `expand_locations` | [bool](/versions/9.0.0/rules/lib/core/bool); default is `False`  Shall we expand $(location) variables? See [ctx.expand\_location()](#expand_location) for more details. |
+| `make_variables` | [dict](/versions/9.0.0/rules/lib/core/dict); or `None`; default is `None`  Make variables to expand, or None. |
+| `tools` | [sequence](/versions/9.0.0/rules/lib/core/list) of [Target](/versions/9.0.0/rules/lib/builtins/Target)s; default is `[]`  List of tools (list of targets). |
+| `label_dict` | [dict](/versions/9.0.0/rules/lib/core/dict); default is `{}`  Dictionary of resolved labels and the corresponding list of Files (a dict of Label : list of Files). |
+| `execution_requirements` | [dict](/versions/9.0.0/rules/lib/core/dict); default is `{}`  Information for scheduling the action to resolve this command. See [tags](/versions/9.0.0/reference/be/common-definitions#common.tags) for useful keys. |
 
 ## resolve\_tools
 
@@ -329,7 +329,7 @@ In contrast to `ctx.resolve_command`, this method does not require that Bash be
 
 | Parameter | Description |
 | --- | --- |
-| `tools` | [sequence](../core/list) of [Target](../builtins/Target)s; default is `[]`  List of tools (list of targets). |
+| `tools` | [sequence](/versions/9.0.0/rules/lib/core/list) of [Target](/versions/9.0.0/rules/lib/builtins/Target)s; default is `[]`  List of tools (list of targets). |
 
 ## rule
 
@@ -351,12 +351,12 @@ Creates a runfiles object.
 
 | Parameter | Description |
 | --- | --- |
-| `files` | [sequence](../core/list) of [File](../builtins/File)s; default is `[]`  The list of files to be added to the runfiles. |
-| `transitive_files` | [depset](../builtins/depset) of [File](../builtins/File)s; or `None`; default is `None`  The (transitive) set of files to be added to the runfiles. The depset should use the `default` order (which, as the name implies, is the default). |
-| `collect_data` | [bool](../core/bool); default is `False`  **Use of this parameter is not recommended. See [runfiles guide](https://bazel.build/versions/9.0.0/extending/rules#runfiles)**. Whether to collect the data runfiles from the dependencies in srcs, data and deps attributes. |
-| `collect_default` | [bool](../core/bool); default is `False`  **Use of this parameter is not recommended. See [runfiles guide](https://bazel.build/versions/9.0.0/extending/rules#runfiles)**. Whether to collect the default runfiles from the dependencies in srcs, data and deps attributes. |
-| `symlinks` | [dict](../core/dict); or [depset](../builtins/depset) of [SymlinkEntry](../builtins/SymlinkEntry)s; default is `{}`  Either a SymlinkEntry depset or the map of symlinks to be added to the runfiles. Symlinks are always added under the main workspace's runfiles directory (e.g. `/_main/`, **not** the directory corresponding to the current target's repository. See [Runfiles symlinks](https://bazel.build/versions/9.0.0/extending/rules#runfiles_symlinks) in the rules guide. |
-| `root_symlinks` | [dict](../core/dict); or [depset](../builtins/depset) of [SymlinkEntry](../builtins/SymlinkEntry)s; default is `{}`  Either a SymlinkEntry depset or a map of symlinks to be added to the runfiles. See [Runfiles symlinks](https://bazel.build/versions/9.0.0/extending/rules#runfiles_symlinks) in the rules guide. |
+| `files` | [sequence](/versions/9.0.0/rules/lib/core/list) of [File](/versions/9.0.0/rules/lib/builtins/File)s; default is `[]`  The list of files to be added to the runfiles. |
+| `transitive_files` | [depset](/versions/9.0.0/rules/lib/builtins/depset) of [File](/versions/9.0.0/rules/lib/builtins/File)s; or `None`; default is `None`  The (transitive) set of files to be added to the runfiles. The depset should use the `default` order (which, as the name implies, is the default). |
+| `collect_data` | [bool](/versions/9.0.0/rules/lib/core/bool); default is `False`  **Use of this parameter is not recommended. See [runfiles guide](https://bazel.build/versions/9.0.0/extending/rules#runfiles)**. Whether to collect the data runfiles from the dependencies in srcs, data and deps attributes. |
+| `collect_default` | [bool](/versions/9.0.0/rules/lib/core/bool); default is `False`  **Use of this parameter is not recommended. See [runfiles guide](https://bazel.build/versions/9.0.0/extending/rules#runfiles)**. Whether to collect the default runfiles from the dependencies in srcs, data and deps attributes. |
+| `symlinks` | [dict](/versions/9.0.0/rules/lib/core/dict); or [depset](/versions/9.0.0/rules/lib/builtins/depset) of [SymlinkEntry](/versions/9.0.0/rules/lib/builtins/SymlinkEntry)s; default is `{}`  Either a SymlinkEntry depset or the map of symlinks to be added to the runfiles. Symlinks are always added under the main workspace's runfiles directory (e.g. `/_main/`, **not** the directory corresponding to the current target's repository. See [Runfiles symlinks](https://bazel.build/versions/9.0.0/extending/rules#runfiles_symlinks) in the rules guide. |
+| `root_symlinks` | [dict](/versions/9.0.0/rules/lib/core/dict); or [depset](/versions/9.0.0/rules/lib/builtins/depset) of [SymlinkEntry](/versions/9.0.0/rules/lib/builtins/SymlinkEntry)s; default is `{}`  Either a SymlinkEntry depset or a map of symlinks to be added to the runfiles. See [Runfiles symlinks](https://bazel.build/versions/9.0.0/extending/rules#runfiles_symlinks) in the rules guide. |
 
 ## split\_attr
 
@@ -386,7 +386,7 @@ Returns true if the given constraint value is part of the current target platfor
 
 | Parameter | Description |
 | --- | --- |
-| `constraintValue` | [ConstraintValueInfo](../providers/ConstraintValueInfo); required  The constraint value to check the target platform against. |
+| `constraintValue` | [ConstraintValueInfo](/versions/9.0.0/rules/lib/providers/ConstraintValueInfo); required  The constraint value to check the target platform against. |
 
 ## toolchains
 
diff --git a/versions/9.0.0/rules/lib/builtins/depset.mdx b/versions/9.0.0/rules/lib/builtins/depset.mdx
index 16d084ec..74710433 100644
--- a/versions/9.0.0/rules/lib/builtins/depset.mdx
+++ b/versions/9.0.0/rules/lib/builtins/depset.mdx
@@ -7,9 +7,9 @@ order. Commonly used for accumulating data from transitive dependencies in rules
 more information see [here](/versions/9.0.0/extending/depsets).
 
 The elements of a depset must be hashable and all of the same type (as defined by the built-in
-[`type(x)`](../globals/all#type) function), but depsets are not simply hash
+[`type(x)`](/versions/9.0.0/rules/lib/globals/all#type) function), but depsets are not simply hash
 sets and do not support fast membership tests. If you need a general set datatype, use the core
-[Starlark set](../core/set) type (available since Bazel 8.1); if your .bzl file needs to
+[Starlark set](/versions/9.0.0/rules/lib/core/set) type (available since Bazel 8.1); if your .bzl file needs to
 be compatible with older Bazel releases, you can simulate a set by using a dictionary where all keys
 map to `True`.
 
@@ -18,7 +18,7 @@ When tested for truth (that is, when used in a Boolean context such as `if d:` w
 operation.
 
 Depsets are immutable. They should be created using their
-[constructor function](../globals/bzl#depset) and merged or augmented with other
+[constructor function](/versions/9.0.0/rules/lib/globals/bzl#depset) and merged or augmented with other
 depsets via the `transitive` argument.
 
 The `order` parameter determines the kind of traversal that is done to convert the
diff --git a/versions/9.0.0/rules/lib/builtins/fragments.mdx b/versions/9.0.0/rules/lib/builtins/fragments.mdx
index 99676d84..eb5fcb04 100644
--- a/versions/9.0.0/rules/lib/builtins/fragments.mdx
+++ b/versions/9.0.0/rules/lib/builtins/fragments.mdx
@@ -6,4 +6,4 @@ A collection of configuration fragments available in the current rule implementa
 
 Only configuration fragments which are declared in the rule definition may be accessed in this collection.
 
-See the [configuration fragment reference](../fragments) for a list of available fragments and the [rules documentation](https://bazel.build/versions/9.0.0/extending/rules#configuration_fragments) for how to use them.
\ No newline at end of file
+See the [configuration fragment reference](/versions/9.0.0/rules/lib/fragments) for a list of available fragments and the [rules documentation](https://bazel.build/versions/9.0.0/extending/rules#configuration_fragments) for how to use them.
\ No newline at end of file
diff --git a/versions/9.0.0/rules/lib/builtins/macro.mdx b/versions/9.0.0/rules/lib/builtins/macro.mdx
index f99caf00..bc09360c 100644
--- a/versions/9.0.0/rules/lib/builtins/macro.mdx
+++ b/versions/9.0.0/rules/lib/builtins/macro.mdx
@@ -3,7 +3,7 @@ title: 'macro'
 ---
 
 A callable Starlark value representing a symbolic macro; in other words, the return value of
-[`macro()`](../globals/bzl#macro). Invoking this value during package
+[`macro()`](/versions/9.0.0/rules/lib/globals/bzl#macro). Invoking this value during package
 construction time will instantiate the macro, and cause the macro's implementation function to be
 evaluated (in a separate context, different from the context in which the macro value was invoked),
 in most cases causing targets to be added to the package's target set. For more information, see
diff --git a/versions/9.0.0/rules/lib/builtins/module_ctx.mdx b/versions/9.0.0/rules/lib/builtins/module_ctx.mdx
index 519f27e1..8c62cd8d 100644
--- a/versions/9.0.0/rules/lib/builtins/module_ctx.mdx
+++ b/versions/9.0.0/rules/lib/builtins/module_ctx.mdx
@@ -36,16 +36,16 @@ Downloads a file to the output path for the provided url and returns a struct co
 
 | Parameter | Description |
 | --- | --- |
-| `url` | [string](../core/string); or Iterable of [string](../core/string)s; required  List of mirror URLs referencing the same file. |
-| `output` | [string](../core/string); or [Label](../builtins/Label); or [path](../builtins/path); default is `''`  path to the output file, relative to the repository directory. |
-| `sha256` | [string](../core/string); default is `''`  The expected SHA-256 hash of the file downloaded. This must match the SHA-256 hash of the file downloaded. It is a security risk to omit the SHA-256 as remote files can change. At best omitting this field will make your build non-hermetic. It is optional to make development easier but should be set before shipping. If provided, the repository cache will first be checked for a file with the given hash; a download will only be attempted if the file was not found in the cache. After a successful download, the file will be added to the cache. |
-| `executable` | [bool](../core/bool); default is `False`  Set the executable flag on the created file, false by default. |
-| `allow_fail` | [bool](../core/bool); default is `False`  If set, indicate the error in the return value instead of raising an error for failed downloads. |
-| `canonical_id` | [string](../core/string); default is `''`  If set, restrict cache hits to those cases where the file was added to the cache with the same canonical id. By default caching uses the checksum (`sha256` or `integrity`). |
-| `auth` | [dict](../core/dict); default is `{}`  An optional dict specifying authentication information for some of the URLs. |
-| `headers` | [dict](../core/dict); default is `{}`  An optional dict specifying http headers for all URLs. |
-| `integrity` | [string](../core/string); default is `''`  Expected checksum of the file downloaded, in Subresource Integrity format. This must match the checksum of the file downloaded. It is a security risk to omit the checksum as remote files can change. At best omitting this field will make your build non-hermetic. It is optional to make development easier but should be set before shipping. If provided, the repository cache will first be checked for a file with the given checksum; a download will only be attempted if the file was not found in the cache. After a successful download, the file will be added to the cache. |
-| `block` | [bool](../core/bool); default is `True`  If set to false, the call returns immediately and instead of the regular return value, it returns a token with one single method, wait(), which blocks until the download is finished and returns the usual return value or throws as usual. |
+| `url` | [string](/versions/9.0.0/rules/lib/core/string); or Iterable of [string](/versions/9.0.0/rules/lib/core/string)s; required  List of mirror URLs referencing the same file. |
+| `output` | [string](/versions/9.0.0/rules/lib/core/string); or [Label](/versions/9.0.0/rules/lib/builtins/Label); or [path](/versions/9.0.0/rules/lib/builtins/path); default is `''`  path to the output file, relative to the repository directory. |
+| `sha256` | [string](/versions/9.0.0/rules/lib/core/string); default is `''`  The expected SHA-256 hash of the file downloaded. This must match the SHA-256 hash of the file downloaded. It is a security risk to omit the SHA-256 as remote files can change. At best omitting this field will make your build non-hermetic. It is optional to make development easier but should be set before shipping. If provided, the repository cache will first be checked for a file with the given hash; a download will only be attempted if the file was not found in the cache. After a successful download, the file will be added to the cache. |
+| `executable` | [bool](/versions/9.0.0/rules/lib/core/bool); default is `False`  Set the executable flag on the created file, false by default. |
+| `allow_fail` | [bool](/versions/9.0.0/rules/lib/core/bool); default is `False`  If set, indicate the error in the return value instead of raising an error for failed downloads. |
+| `canonical_id` | [string](/versions/9.0.0/rules/lib/core/string); default is `''`  If set, restrict cache hits to those cases where the file was added to the cache with the same canonical id. By default caching uses the checksum (`sha256` or `integrity`). |
+| `auth` | [dict](/versions/9.0.0/rules/lib/core/dict); default is `{}`  An optional dict specifying authentication information for some of the URLs. |
+| `headers` | [dict](/versions/9.0.0/rules/lib/core/dict); default is `{}`  An optional dict specifying http headers for all URLs. |
+| `integrity` | [string](/versions/9.0.0/rules/lib/core/string); default is `''`  Expected checksum of the file downloaded, in Subresource Integrity format. This must match the checksum of the file downloaded. It is a security risk to omit the checksum as remote files can change. At best omitting this field will make your build non-hermetic. It is optional to make development easier but should be set before shipping. If provided, the repository cache will first be checked for a file with the given checksum; a download will only be attempted if the file was not found in the cache. After a successful download, the file will be added to the cache. |
+| `block` | [bool](/versions/9.0.0/rules/lib/core/bool); default is `True`  If set to false, the call returns immediately and instead of the regular return value, it returns a token with one single method, wait(), which blocks until the download is finished and returns the usual return value or throws as usual. |
 
 ## download\_and\_extract
 
@@ -59,17 +59,17 @@ Downloads a file to the output path for the provided url, extracts it, and retur
 
 | Parameter | Description |
 | --- | --- |
-| `url` | [string](../core/string); or Iterable of [string](../core/string)s; required  List of mirror URLs referencing the same file. |
-| `output` | [string](../core/string); or [Label](../builtins/Label); or [path](../builtins/path); default is `''`  Path to the directory where the archive will be unpacked, relative to the repository directory. |
-| `sha256` | [string](../core/string); default is `''`  The expected SHA-256 hash of the file downloaded. This must match the SHA-256 hash of the file downloaded. It is a security risk to omit the SHA-256 as remote files can change. At best omitting this field will make your build non-hermetic. It is optional to make development easier but should be set before shipping. If provided, the repository cache will first be checked for a file with the given hash; a download will only be attempted if the file was not found in the cache. After a successful download, the file will be added to the cache. |
-| `type` | [string](../core/string); default is `''`  The archive type of the downloaded file. By default, the archive type is determined from the file extension of the URL. If the file has no extension, you can explicitly specify either "zip", "jar", "war", "aar", "nupkg", "whl", "tar", "tar.gz", "tgz", "gz", "tar.xz", "txz", "xz", "tar.zst", "tzst", "zst", "tar.bz2", "tbz", "bz2", "ar", "deb" or "7z" here. |
-| `strip_prefix` | [string](../core/string); default is `''`  A directory prefix to strip from the extracted files. Many archives contain a top-level directory that contains all files in the archive. Instead of needing to specify this prefix over and over in the `build_file`, this field can be used to strip it from extracted files. For compatibility, this parameter may also be used under the deprecated name `stripPrefix`. |
-| `allow_fail` | [bool](../core/bool); default is `False`  If set, indicate the error in the return value instead of raising an error for failed downloads. |
-| `canonical_id` | [string](../core/string); default is `''`  If set, restrict cache hits to those cases where the file was added to the cache with the same canonical id. By default caching uses the checksum (`sha256` or `integrity`). |
-| `auth` | [dict](../core/dict); default is `{}`  An optional dict specifying authentication information for some of the URLs. |
-| `headers` | [dict](../core/dict); default is `{}`  An optional dict specifying http headers for all URLs. |
-| `integrity` | [string](../core/string); default is `''`  Expected checksum of the file downloaded, in Subresource Integrity format. This must match the checksum of the file downloaded. It is a security risk to omit the checksum as remote files can change. At best omitting this field will make your build non-hermetic. It is optional to make development easier but should be set before shipping. If provided, the repository cache will first be checked for a file with the given checksum; a download will only be attempted if the file was not found in the cache. After a successful download, the file will be added to the cache. |
-| `rename_files` | [dict](../core/dict); default is `{}`  An optional dict specifying files to rename during the extraction. Archive entries with names exactly matching a key will be renamed to the value, prior to any directory prefix adjustment. This can be used to extract archives that contain non-Unicode filenames, or which have files that would extract to the same path on case-insensitive filesystems. |
+| `url` | [string](/versions/9.0.0/rules/lib/core/string); or Iterable of [string](/versions/9.0.0/rules/lib/core/string)s; required  List of mirror URLs referencing the same file. |
+| `output` | [string](/versions/9.0.0/rules/lib/core/string); or [Label](/versions/9.0.0/rules/lib/builtins/Label); or [path](/versions/9.0.0/rules/lib/builtins/path); default is `''`  Path to the directory where the archive will be unpacked, relative to the repository directory. |
+| `sha256` | [string](/versions/9.0.0/rules/lib/core/string); default is `''`  The expected SHA-256 hash of the file downloaded. This must match the SHA-256 hash of the file downloaded. It is a security risk to omit the SHA-256 as remote files can change. At best omitting this field will make your build non-hermetic. It is optional to make development easier but should be set before shipping. If provided, the repository cache will first be checked for a file with the given hash; a download will only be attempted if the file was not found in the cache. After a successful download, the file will be added to the cache. |
+| `type` | [string](/versions/9.0.0/rules/lib/core/string); default is `''`  The archive type of the downloaded file. By default, the archive type is determined from the file extension of the URL. If the file has no extension, you can explicitly specify either "zip", "jar", "war", "aar", "nupkg", "whl", "tar", "tar.gz", "tgz", "gz", "tar.xz", "txz", "xz", "tar.zst", "tzst", "zst", "tar.bz2", "tbz", "bz2", "ar", "deb" or "7z" here. |
+| `strip_prefix` | [string](/versions/9.0.0/rules/lib/core/string); default is `''`  A directory prefix to strip from the extracted files. Many archives contain a top-level directory that contains all files in the archive. Instead of needing to specify this prefix over and over in the `build_file`, this field can be used to strip it from extracted files. For compatibility, this parameter may also be used under the deprecated name `stripPrefix`. |
+| `allow_fail` | [bool](/versions/9.0.0/rules/lib/core/bool); default is `False`  If set, indicate the error in the return value instead of raising an error for failed downloads. |
+| `canonical_id` | [string](/versions/9.0.0/rules/lib/core/string); default is `''`  If set, restrict cache hits to those cases where the file was added to the cache with the same canonical id. By default caching uses the checksum (`sha256` or `integrity`). |
+| `auth` | [dict](/versions/9.0.0/rules/lib/core/dict); default is `{}`  An optional dict specifying authentication information for some of the URLs. |
+| `headers` | [dict](/versions/9.0.0/rules/lib/core/dict); default is `{}`  An optional dict specifying http headers for all URLs. |
+| `integrity` | [string](/versions/9.0.0/rules/lib/core/string); default is `''`  Expected checksum of the file downloaded, in Subresource Integrity format. This must match the checksum of the file downloaded. It is a security risk to omit the checksum as remote files can change. At best omitting this field will make your build non-hermetic. It is optional to make development easier but should be set before shipping. If provided, the repository cache will first be checked for a file with the given checksum; a download will only be attempted if the file was not found in the cache. After a successful download, the file will be added to the cache. |
+| `rename_files` | [dict](/versions/9.0.0/rules/lib/core/dict); default is `{}`  An optional dict specifying files to rename during the extraction. Archive entries with names exactly matching a key will be renamed to the value, prior to any directory prefix adjustment. This can be used to extract archives that contain non-Unicode filenames, or which have files that would extract to the same path on case-insensitive filesystems. |
 
 ## execute
 
@@ -83,11 +83,11 @@ Executes the command given by the list of arguments. The execution time of the c
 
 | Parameter | Description |
 | --- | --- |
-| `arguments` | [sequence](../core/list); required  List of arguments, the first element should be the path to the program to execute. |
-| `timeout` | [int](../core/int); default is `600`  Maximum duration of the command in seconds (default is 600 seconds). |
-| `environment` | [dict](../core/dict); default is `{}`  Force some environment variables to be set to be passed to the process. The value can be `None` to remove the environment variable. |
-| `quiet` | [bool](../core/bool); default is `True`  If stdout and stderr should be printed to the terminal. |
-| `working_directory` | [string](../core/string); default is `""`  Working directory for command execution. Can be relative to the repository root or absolute. The default is the repository root. |
+| `arguments` | [sequence](/versions/9.0.0/rules/lib/core/list); required  List of arguments, the first element should be the path to the program to execute. |
+| `timeout` | [int](/versions/9.0.0/rules/lib/core/int); default is `600`  Maximum duration of the command in seconds (default is 600 seconds). |
+| `environment` | [dict](/versions/9.0.0/rules/lib/core/dict); default is `{}`  Force some environment variables to be set to be passed to the process. The value can be `None` to remove the environment variable. |
+| `quiet` | [bool](/versions/9.0.0/rules/lib/core/bool); default is `True`  If stdout and stderr should be printed to the terminal. |
+| `working_directory` | [string](/versions/9.0.0/rules/lib/core/string); default is `""`  Working directory for command execution. Can be relative to the repository root or absolute. The default is the repository root. |
 
 ## extension\_metadata
 
@@ -101,10 +101,10 @@ Constructs an opaque object that can be returned from the module extension's imp
 
 | Parameter | Description |
 | --- | --- |
-| `root_module_direct_deps` | [sequence](../core/list) of [string](../core/string)s; or [string](../core/string); or `None`; default is `None`  The names of the repositories that the extension considers to be direct dependencies of the root module. If the root module imports additional repositories or does not import all of these repositories via [`use_repo`](../globals/module#use_repo), Bazel will print a warning when the extension is evaluated, instructing the user to run `bazel mod tidy` to fix the `use_repo` calls automatically. If one of `root_module_direct_deps` and will print a warning and a fixup command when the extension is evaluated. If one of `root_module_direct_deps` and `root_module_direct_dev_deps` is specified, the other has to be as well. The lists specified by these two parameters must be disjoint. Exactly one of `root_module_direct_deps` and `root_module_direct_dev_deps` can be set to the special value `"all"`, which is treated as if a list with the names of all repositories generated by the extension was specified as the value. |
-| `root_module_direct_dev_deps` | [sequence](../core/list) of [string](../core/string)s; or [string](../core/string); or `None`; default is `None`  The names of the repositories that the extension considers to be direct dev dependencies of the root module. If the root module imports additional repositories or does not import all of these repositories via [`use_repo`](../globals/module#use_repo) on an extension proxy created with `use_extension(..., dev_dependency = True)`, Bazel will print a warning when the extension is evaluated, instructing the user to run `bazel mod tidy` to fix the `use_repo` calls automatically. If one of `root_module_direct_deps` and `root_module_direct_dev_deps` is specified, the other has to be as well. The lists specified by these two parameters must be disjoint. Exactly one of `root_module_direct_deps` and `root_module_direct_dev_deps` can be set to the special value `"all"`, which is treated as if a list with the names of all repositories generated by the extension was specified as the value. |
-| `reproducible` | [bool](../core/bool); default is `False`  States that this module extension ensures complete reproducibility, thereby it should not be stored in the lockfile. |
-| `facts` | [dict](../core/dict) of [string](../core/string)s; default is `{}`  A JSON-like dict that is made available to future executions of this extension via the `module\_ctx.facts` property. This is useful for extensions that want to preserve universally true facts such as the hashes of artifacts in an immutable repository. Bazel may shallowly merge multiple facts dicts returned by different versions of the extension in order to resolve merge conflicts on the MODULE.bazel.lock file, as if by applying the `dict.update()` method or the `|` operator in Starlark. Extensions should use facts for key-value storage only and ensure that the key uniquely determines the value, although perhaps only via additional information and network access. An extension can opt out of this merging by providing a dict with a single, fixed top-level key and an arbitrary value. Note that the value provided here may be read back by a different version of the extension, so either include a version number or use a schema that is unlikely to result in ambiguities. |
+| `root_module_direct_deps` | [sequence](/versions/9.0.0/rules/lib/core/list) of [string](/versions/9.0.0/rules/lib/core/string)s; or [string](/versions/9.0.0/rules/lib/core/string); or `None`; default is `None`  The names of the repositories that the extension considers to be direct dependencies of the root module. If the root module imports additional repositories or does not import all of these repositories via [`use_repo`](/versions/9.0.0/rules/lib/globals/module#use_repo), Bazel will print a warning when the extension is evaluated, instructing the user to run `bazel mod tidy` to fix the `use_repo` calls automatically. If one of `root_module_direct_deps` and will print a warning and a fixup command when the extension is evaluated. If one of `root_module_direct_deps` and `root_module_direct_dev_deps` is specified, the other has to be as well. The lists specified by these two parameters must be disjoint. Exactly one of `root_module_direct_deps` and `root_module_direct_dev_deps` can be set to the special value `"all"`, which is treated as if a list with the names of all repositories generated by the extension was specified as the value. |
+| `root_module_direct_dev_deps` | [sequence](/versions/9.0.0/rules/lib/core/list) of [string](/versions/9.0.0/rules/lib/core/string)s; or [string](/versions/9.0.0/rules/lib/core/string); or `None`; default is `None`  The names of the repositories that the extension considers to be direct dev dependencies of the root module. If the root module imports additional repositories or does not import all of these repositories via [`use_repo`](/versions/9.0.0/rules/lib/globals/module#use_repo) on an extension proxy created with `use_extension(..., dev_dependency = True)`, Bazel will print a warning when the extension is evaluated, instructing the user to run `bazel mod tidy` to fix the `use_repo` calls automatically. If one of `root_module_direct_deps` and `root_module_direct_dev_deps` is specified, the other has to be as well. The lists specified by these two parameters must be disjoint. Exactly one of `root_module_direct_deps` and `root_module_direct_dev_deps` can be set to the special value `"all"`, which is treated as if a list with the names of all repositories generated by the extension was specified as the value. |
+| `reproducible` | [bool](/versions/9.0.0/rules/lib/core/bool); default is `False`  States that this module extension ensures complete reproducibility, thereby it should not be stored in the lockfile. |
+| `facts` | [dict](/versions/9.0.0/rules/lib/core/dict) of [string](/versions/9.0.0/rules/lib/core/string)s; default is `{}`  A JSON-like dict that is made available to future executions of this extension via the `module\_ctx.facts` property. This is useful for extensions that want to preserve universally true facts such as the hashes of artifacts in an immutable repository. Bazel may shallowly merge multiple facts dicts returned by different versions of the extension in order to resolve merge conflicts on the MODULE.bazel.lock file, as if by applying the `dict.update()` method or the `|` operator in Starlark. Extensions should use facts for key-value storage only and ensure that the key uniquely determines the value, although perhaps only via additional information and network access. An extension can opt out of this merging by providing a dict with a single, fixed top-level key and an arbitrary value. Note that the value provided here may be read back by a different version of the extension, so either include a version number or use a schema that is unlikely to result in ambiguities. |
 
 ## extract
 
@@ -118,12 +118,12 @@ Extract an archive to the repository directory.
 
 | Parameter | Description |
 | --- | --- |
-| `archive` | [string](../core/string); or [Label](../builtins/Label); or [path](../builtins/path); required  path to the archive that will be unpacked, relative to the repository directory. |
-| `output` | [string](../core/string); or [Label](../builtins/Label); or [path](../builtins/path); default is `''`  path to the directory where the archive will be unpacked, relative to the repository directory. |
-| `strip_prefix` | [string](../core/string); default is `''`  a directory prefix to strip from the extracted files. Many archives contain a top-level directory that contains all files in the archive. Instead of needing to specify this prefix over and over in the `build_file`, this field can be used to strip it from extracted files. For compatibility, this parameter may also be used under the deprecated name `stripPrefix`. |
-| `rename_files` | [dict](../core/dict); default is `{}`  An optional dict specifying files to rename during the extraction. Archive entries with names exactly matching a key will be renamed to the value, prior to any directory prefix adjustment. This can be used to extract archives that contain non-Unicode filenames, or which have files that would extract to the same path on case-insensitive filesystems. |
-| `watch_archive` | [string](../core/string); default is `'auto'`  whether to [watch](#watch) the archive file. Can be the string 'yes', 'no', or 'auto'. Passing 'yes' is equivalent to immediately invoking the [`watch()`](#watch) method; passing 'no' does not attempt to watch the file; passing 'auto' will only attempt to watch the file when it is legal to do so (see `watch()` docs for more information. |
-| `type` | [string](../core/string); default is `''`  The archive type of the downloaded file. By default, the archive type is determined from the file extension of the URL. If the file has no extension, you can explicitly specify either "zip", "jar", "war", "aar", "nupkg", "whl", "tar", "tar.gz", "tgz", "gz", "tar.xz", "txz", "xz", "tar.zst", "tzst", "zst", "tar.bz2", "tbz", "bz2", "ar", "deb" or "7z" here. |
+| `archive` | [string](/versions/9.0.0/rules/lib/core/string); or [Label](/versions/9.0.0/rules/lib/builtins/Label); or [path](/versions/9.0.0/rules/lib/builtins/path); required  path to the archive that will be unpacked, relative to the repository directory. |
+| `output` | [string](/versions/9.0.0/rules/lib/core/string); or [Label](/versions/9.0.0/rules/lib/builtins/Label); or [path](/versions/9.0.0/rules/lib/builtins/path); default is `''`  path to the directory where the archive will be unpacked, relative to the repository directory. |
+| `strip_prefix` | [string](/versions/9.0.0/rules/lib/core/string); default is `''`  a directory prefix to strip from the extracted files. Many archives contain a top-level directory that contains all files in the archive. Instead of needing to specify this prefix over and over in the `build_file`, this field can be used to strip it from extracted files. For compatibility, this parameter may also be used under the deprecated name `stripPrefix`. |
+| `rename_files` | [dict](/versions/9.0.0/rules/lib/core/dict); default is `{}`  An optional dict specifying files to rename during the extraction. Archive entries with names exactly matching a key will be renamed to the value, prior to any directory prefix adjustment. This can be used to extract archives that contain non-Unicode filenames, or which have files that would extract to the same path on case-insensitive filesystems. |
+| `watch_archive` | [string](/versions/9.0.0/rules/lib/core/string); default is `'auto'`  whether to [watch](#watch) the archive file. Can be the string 'yes', 'no', or 'auto'. Passing 'yes' is equivalent to immediately invoking the [`watch()`](#watch) method; passing 'no' does not attempt to watch the file; passing 'auto' will only attempt to watch the file when it is legal to do so (see `watch()` docs for more information. |
+| `type` | [string](/versions/9.0.0/rules/lib/core/string); default is `''`  The archive type of the downloaded file. By default, the archive type is determined from the file extension of the URL. If the file has no extension, you can explicitly specify either "zip", "jar", "war", "aar", "nupkg", "whl", "tar", "tar.gz", "tgz", "gz", "tar.xz", "txz", "xz", "tar.zst", "tzst", "zst", "tar.bz2", "tbz", "bz2", "ar", "deb" or "7z" here. |
 
 ## facts
 
@@ -132,7 +132,7 @@ Facts module_ctx.facts
 ```
 
 The JSON-like dict returned by a previous execution of this extension in the `facts`
-parameter of [`extension\_metadata`](../builtins/module\_ctx#extension\_metadata) or else
+parameter of [`extension\_metadata`](/versions/9.0.0/rules/lib/builtins/module\_ctx#extension\_metadata) or else
 `{}`.
 This is useful for extensions that want to preserve universally true facts such as the
 hashes of artifacts in an immutable repository.
@@ -151,10 +151,10 @@ Generates a file in the repository directory with the provided content.
 
 | Parameter | Description |
 | --- | --- |
-| `path` | [string](../core/string); or [Label](../builtins/Label); or [path](../builtins/path); required  Path of the file to create, relative to the repository directory. |
-| `content` | [string](../core/string); default is `''`  The content of the file to create, empty by default. |
-| `executable` | [bool](../core/bool); default is `True`  Set the executable flag on the created file, true by default. |
-| `legacy_utf8` | [bool](../core/bool); default is `False`  No-op. This parameter is deprecated and will be removed in a future version of Bazel. |
+| `path` | [string](/versions/9.0.0/rules/lib/core/string); or [Label](/versions/9.0.0/rules/lib/builtins/Label); or [path](/versions/9.0.0/rules/lib/builtins/path); required  Path of the file to create, relative to the repository directory. |
+| `content` | [string](/versions/9.0.0/rules/lib/core/string); default is `''`  The content of the file to create, empty by default. |
+| `executable` | [bool](/versions/9.0.0/rules/lib/core/bool); default is `True`  Set the executable flag on the created file, true by default. |
+| `legacy_utf8` | [bool](/versions/9.0.0/rules/lib/core/bool); default is `False`  No-op. This parameter is deprecated and will be removed in a future version of Bazel. |
 
 ## getenv
 
@@ -170,8 +170,8 @@ When building incrementally, any change to the value of the variable named by `n
 
 | Parameter | Description |
 | --- | --- |
-| `name` | [string](../core/string); required  Name of desired environment variable. |
-| `default` | [string](../core/string); or `None`; default is `None`  Default value to return if `name` is not found. |
+| `name` | [string](/versions/9.0.0/rules/lib/core/string); required  Name of desired environment variable. |
+| `default` | [string](/versions/9.0.0/rules/lib/core/string); or `None`; default is `None`  Default value to return if `name` is not found. |
 
 May return `None`.
 
@@ -181,13 +181,13 @@ May return `None`.
 bool module_ctx.is_dev_dependency(tag)
 ```
 
-Returns whether the given tag was specified on the result of a [use\_extension](../globals/module#use_extension) call with `devDependency = True`.
+Returns whether the given tag was specified on the result of a [use\_extension](/versions/9.0.0/rules/lib/globals/module#use_extension) call with `devDependency = True`.
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `tag` | bazel\_module\_tag; required  A tag obtained from [bazel\_module.tags](../builtins/bazel_module#tags). |
+| `tag` | bazel\_module\_tag; required  A tag obtained from [bazel\_module.tags](/versions/9.0.0/rules/lib/builtins/bazel_module#tags). |
 
 ## modules
 
@@ -195,7 +195,7 @@ Returns whether the given tag was specified on the result of a [use\_extension](
 list module_ctx.modules
 ```
 
-A list of all the Bazel modules in the external dependency graph that use this module extension, each of which is a [bazel\_module](../builtins/bazel_module) object that exposes all the tags it specified for this extension. The iteration order of this dictionary is guaranteed to be the same as breadth-first search starting from the root module.
+A list of all the Bazel modules in the external dependency graph that use this module extension, each of which is a [bazel\_module](/versions/9.0.0/rules/lib/builtins/bazel_module) object that exposes all the tags it specified for this extension. The iteration order of this dictionary is guaranteed to be the same as breadth-first search starting from the root module.
 
 ## os
 
@@ -217,7 +217,7 @@ Returns a path from a string, label, or path. If this context is a `repository_c
 
 | Parameter | Description |
 | --- | --- |
-| `path` | [string](../core/string); or [Label](../builtins/Label); or [path](../builtins/path); required  `string`, `Label` or `path` from which to create a path from. |
+| `path` | [string](/versions/9.0.0/rules/lib/core/string); or [Label](/versions/9.0.0/rules/lib/builtins/Label); or [path](/versions/9.0.0/rules/lib/builtins/path); required  `string`, `Label` or `path` from which to create a path from. |
 
 ## read
 
@@ -231,8 +231,8 @@ Reads the content of a file on the filesystem.
 
 | Parameter | Description |
 | --- | --- |
-| `path` | [string](../core/string); or [Label](../builtins/Label); or [path](../builtins/path); required  Path of the file to read from. |
-| `watch` | [string](../core/string); default is `'auto'`  Whether to [watch](#watch) the file. Can be the string 'yes', 'no', or 'auto'. Passing 'yes' is equivalent to immediately invoking the [`watch()`](#watch) method; passing 'no' does not attempt to watch the file; passing 'auto' will only attempt to watch the file when it is legal to do so (see `watch()` docs for more information. |
+| `path` | [string](/versions/9.0.0/rules/lib/core/string); or [Label](/versions/9.0.0/rules/lib/builtins/Label); or [path](/versions/9.0.0/rules/lib/builtins/path); required  Path of the file to read from. |
+| `watch` | [string](/versions/9.0.0/rules/lib/core/string); default is `'auto'`  Whether to [watch](#watch) the file. Can be the string 'yes', 'no', or 'auto'. Passing 'yes' is equivalent to immediately invoking the [`watch()`](#watch) method; passing 'no' does not attempt to watch the file; passing 'auto' will only attempt to watch the file when it is legal to do so (see `watch()` docs for more information. |
 
 ## report\_progress
 
@@ -246,7 +246,7 @@ Updates the progress status for the fetching of this repository or module extens
 
 | Parameter | Description |
 | --- | --- |
-| `status` | [string](../core/string); default is `''`  `string` describing the current status of the fetch progress. |
+| `status` | [string](/versions/9.0.0/rules/lib/core/string); default is `''`  `string` describing the current status of the fetch progress. |
 
 ## root\_module\_has\_non\_dev\_dependency
 
@@ -264,7 +264,7 @@ None module_ctx.watch(path)
 
 Tells Bazel to watch for changes to the given path, whether or not it exists, or whether it's a file or a directory. Any changes to the file or directory will invalidate this repository or module extension, and cause it to be refetched or re-evaluated next time.
 
-"Changes" include changes to the contents of the file (if the path is a file); if the path was a file but is now a directory, or vice versa; and if the path starts or stops existing. Notably, this does *not* include changes to any files under the directory if the path is a directory. For that, use [`path.readdir()`](path#readdir) instead.
+"Changes" include changes to the contents of the file (if the path is a file); if the path was a file but is now a directory, or vice versa; and if the path starts or stops existing. Notably, this does *not* include changes to any files under the directory if the path is a directory. For that, use [`path.readdir()`](/versions/9.0.0/rules/lib/builtins/path#readdir) instead.
 
 Note that attempting to watch paths inside the repo currently being fetched, or inside the working directory of the current module extension, will result in an error. A module extension attempting to watch a path outside the current Bazel workspace will also result in an error.
 
@@ -272,7 +272,7 @@ Note that attempting to watch paths inside the repo currently being fetched, or
 
 | Parameter | Description |
 | --- | --- |
-| `path` | [string](../core/string); or [Label](../builtins/Label); or [path](../builtins/path); required  Path of the file to watch. |
+| `path` | [string](/versions/9.0.0/rules/lib/core/string); or [Label](/versions/9.0.0/rules/lib/builtins/Label); or [path](/versions/9.0.0/rules/lib/builtins/path); required  Path of the file to watch. |
 
 ## which
 
@@ -286,6 +286,6 @@ Returns the `path` of the corresponding program or `None` if there is no such pr
 
 | Parameter | Description |
 | --- | --- |
-| `program` | [string](../core/string); required  Program to find in the path. |
+| `program` | [string](/versions/9.0.0/rules/lib/core/string); required  Program to find in the path. |
 
 May return `None`.
\ No newline at end of file
diff --git a/versions/9.0.0/rules/lib/builtins/path.mdx b/versions/9.0.0/rules/lib/builtins/path.mdx
index 4fdf07f2..33b4363b 100644
--- a/versions/9.0.0/rules/lib/builtins/path.mdx
+++ b/versions/9.0.0/rules/lib/builtins/path.mdx
@@ -77,7 +77,7 @@ Returns the list of entries in the directory denoted by this path. Each entry is
 
 | Parameter | Description |
 | --- | --- |
-| `watch` | [string](../core/string); default is `'auto'`  whether Bazel should watch the list of entries in this directory and refetch the repository or re-evaluate the module extension next time when any changes are detected. Changes to detect include entry creation, deletion, and renaming. Note that this doesn't watch the *contents* of any entries in the directory. Can be the string 'yes', 'no', or 'auto'. If set to 'auto', Bazel will only watch this directory when it is legal to do so (see [`repository_ctx.watch()`](repository_ctx#watch) docs for more information). |
+| `watch` | [string](/versions/9.0.0/rules/lib/core/string); default is `'auto'`  whether Bazel should watch the list of entries in this directory and refetch the repository or re-evaluate the module extension next time when any changes are detected. Changes to detect include entry creation, deletion, and renaming. Note that this doesn't watch the *contents* of any entries in the directory. Can be the string 'yes', 'no', or 'auto'. If set to 'auto', Bazel will only watch this directory when it is legal to do so (see [`repository_ctx.watch()`](/versions/9.0.0/rules/lib/builtins/repository_ctx#watch) docs for more information). |
 
 ## realpath
 
diff --git a/versions/9.0.0/rules/lib/builtins/repo_metadata.mdx b/versions/9.0.0/rules/lib/builtins/repo_metadata.mdx
index 0b28cbac..fdbd7f90 100644
--- a/versions/9.0.0/rules/lib/builtins/repo_metadata.mdx
+++ b/versions/9.0.0/rules/lib/builtins/repo_metadata.mdx
@@ -2,4 +2,4 @@
 title: 'repo\_metadata'
 ---
 
-See [`repository_ctx.repo_metadata`](repository_ctx#repo_metadata).
\ No newline at end of file
+See [`repository_ctx.repo_metadata`](/versions/9.0.0/rules/lib/builtins/repository_ctx#repo_metadata).
\ No newline at end of file
diff --git a/versions/9.0.0/rules/lib/builtins/repository_ctx.mdx b/versions/9.0.0/rules/lib/builtins/repository_ctx.mdx
index 314e3a87..894f5b5e 100644
--- a/versions/9.0.0/rules/lib/builtins/repository_ctx.mdx
+++ b/versions/9.0.0/rules/lib/builtins/repository_ctx.mdx
@@ -50,7 +50,7 @@ Deletes a file or a directory. Returns a bool, indicating whether the file or di
 
 | Parameter | Description |
 | --- | --- |
-| `path` | [string](../core/string); or [path](../builtins/path); required  Path of the file to delete, relative to the repository directory, or absolute. Can be a path or a string. |
+| `path` | [string](/versions/9.0.0/rules/lib/core/string); or [path](/versions/9.0.0/rules/lib/builtins/path); required  Path of the file to delete, relative to the repository directory, or absolute. Can be a path or a string. |
 
 ## download
 
@@ -64,16 +64,16 @@ Downloads a file to the output path for the provided url and returns a struct co
 
 | Parameter | Description |
 | --- | --- |
-| `url` | [string](../core/string); or Iterable of [string](../core/string)s; required  List of mirror URLs referencing the same file. |
-| `output` | [string](../core/string); or [Label](../builtins/Label); or [path](../builtins/path); default is `''`  path to the output file, relative to the repository directory. |
-| `sha256` | [string](../core/string); default is `''`  The expected SHA-256 hash of the file downloaded. This must match the SHA-256 hash of the file downloaded. It is a security risk to omit the SHA-256 as remote files can change. At best omitting this field will make your build non-hermetic. It is optional to make development easier but should be set before shipping. If provided, the repository cache will first be checked for a file with the given hash; a download will only be attempted if the file was not found in the cache. After a successful download, the file will be added to the cache. |
-| `executable` | [bool](../core/bool); default is `False`  Set the executable flag on the created file, false by default. |
-| `allow_fail` | [bool](../core/bool); default is `False`  If set, indicate the error in the return value instead of raising an error for failed downloads. |
-| `canonical_id` | [string](../core/string); default is `''`  If set, restrict cache hits to those cases where the file was added to the cache with the same canonical id. By default caching uses the checksum (`sha256` or `integrity`). |
-| `auth` | [dict](../core/dict); default is `{}`  An optional dict specifying authentication information for some of the URLs. |
-| `headers` | [dict](../core/dict); default is `{}`  An optional dict specifying http headers for all URLs. |
-| `integrity` | [string](../core/string); default is `''`  Expected checksum of the file downloaded, in Subresource Integrity format. This must match the checksum of the file downloaded. It is a security risk to omit the checksum as remote files can change. At best omitting this field will make your build non-hermetic. It is optional to make development easier but should be set before shipping. If provided, the repository cache will first be checked for a file with the given checksum; a download will only be attempted if the file was not found in the cache. After a successful download, the file will be added to the cache. |
-| `block` | [bool](../core/bool); default is `True`  If set to false, the call returns immediately and instead of the regular return value, it returns a token with one single method, wait(), which blocks until the download is finished and returns the usual return value or throws as usual. |
+| `url` | [string](/versions/9.0.0/rules/lib/core/string); or Iterable of [string](/versions/9.0.0/rules/lib/core/string)s; required  List of mirror URLs referencing the same file. |
+| `output` | [string](/versions/9.0.0/rules/lib/core/string); or [Label](/versions/9.0.0/rules/lib/builtins/Label); or [path](/versions/9.0.0/rules/lib/builtins/path); default is `''`  path to the output file, relative to the repository directory. |
+| `sha256` | [string](/versions/9.0.0/rules/lib/core/string); default is `''`  The expected SHA-256 hash of the file downloaded. This must match the SHA-256 hash of the file downloaded. It is a security risk to omit the SHA-256 as remote files can change. At best omitting this field will make your build non-hermetic. It is optional to make development easier but should be set before shipping. If provided, the repository cache will first be checked for a file with the given hash; a download will only be attempted if the file was not found in the cache. After a successful download, the file will be added to the cache. |
+| `executable` | [bool](/versions/9.0.0/rules/lib/core/bool); default is `False`  Set the executable flag on the created file, false by default. |
+| `allow_fail` | [bool](/versions/9.0.0/rules/lib/core/bool); default is `False`  If set, indicate the error in the return value instead of raising an error for failed downloads. |
+| `canonical_id` | [string](/versions/9.0.0/rules/lib/core/string); default is `''`  If set, restrict cache hits to those cases where the file was added to the cache with the same canonical id. By default caching uses the checksum (`sha256` or `integrity`). |
+| `auth` | [dict](/versions/9.0.0/rules/lib/core/dict); default is `{}`  An optional dict specifying authentication information for some of the URLs. |
+| `headers` | [dict](/versions/9.0.0/rules/lib/core/dict); default is `{}`  An optional dict specifying http headers for all URLs. |
+| `integrity` | [string](/versions/9.0.0/rules/lib/core/string); default is `''`  Expected checksum of the file downloaded, in Subresource Integrity format. This must match the checksum of the file downloaded. It is a security risk to omit the checksum as remote files can change. At best omitting this field will make your build non-hermetic. It is optional to make development easier but should be set before shipping. If provided, the repository cache will first be checked for a file with the given checksum; a download will only be attempted if the file was not found in the cache. After a successful download, the file will be added to the cache. |
+| `block` | [bool](/versions/9.0.0/rules/lib/core/bool); default is `True`  If set to false, the call returns immediately and instead of the regular return value, it returns a token with one single method, wait(), which blocks until the download is finished and returns the usual return value or throws as usual. |
 
 ## download\_and\_extract
 
@@ -87,17 +87,17 @@ Downloads a file to the output path for the provided url, extracts it, and retur
 
 | Parameter | Description |
 | --- | --- |
-| `url` | [string](../core/string); or Iterable of [string](../core/string)s; required  List of mirror URLs referencing the same file. |
-| `output` | [string](../core/string); or [Label](../builtins/Label); or [path](../builtins/path); default is `''`  Path to the directory where the archive will be unpacked, relative to the repository directory. |
-| `sha256` | [string](../core/string); default is `''`  The expected SHA-256 hash of the file downloaded. This must match the SHA-256 hash of the file downloaded. It is a security risk to omit the SHA-256 as remote files can change. At best omitting this field will make your build non-hermetic. It is optional to make development easier but should be set before shipping. If provided, the repository cache will first be checked for a file with the given hash; a download will only be attempted if the file was not found in the cache. After a successful download, the file will be added to the cache. |
-| `type` | [string](../core/string); default is `''`  The archive type of the downloaded file. By default, the archive type is determined from the file extension of the URL. If the file has no extension, you can explicitly specify either "zip", "jar", "war", "aar", "nupkg", "whl", "tar", "tar.gz", "tgz", "gz", "tar.xz", "txz", "xz", "tar.zst", "tzst", "zst", "tar.bz2", "tbz", "bz2", "ar", "deb" or "7z" here. |
-| `strip_prefix` | [string](../core/string); default is `''`  A directory prefix to strip from the extracted files. Many archives contain a top-level directory that contains all files in the archive. Instead of needing to specify this prefix over and over in the `build_file`, this field can be used to strip it from extracted files. For compatibility, this parameter may also be used under the deprecated name `stripPrefix`. |
-| `allow_fail` | [bool](../core/bool); default is `False`  If set, indicate the error in the return value instead of raising an error for failed downloads. |
-| `canonical_id` | [string](../core/string); default is `''`  If set, restrict cache hits to those cases where the file was added to the cache with the same canonical id. By default caching uses the checksum (`sha256` or `integrity`). |
-| `auth` | [dict](../core/dict); default is `{}`  An optional dict specifying authentication information for some of the URLs. |
-| `headers` | [dict](../core/dict); default is `{}`  An optional dict specifying http headers for all URLs. |
-| `integrity` | [string](../core/string); default is `''`  Expected checksum of the file downloaded, in Subresource Integrity format. This must match the checksum of the file downloaded. It is a security risk to omit the checksum as remote files can change. At best omitting this field will make your build non-hermetic. It is optional to make development easier but should be set before shipping. If provided, the repository cache will first be checked for a file with the given checksum; a download will only be attempted if the file was not found in the cache. After a successful download, the file will be added to the cache. |
-| `rename_files` | [dict](../core/dict); default is `{}`  An optional dict specifying files to rename during the extraction. Archive entries with names exactly matching a key will be renamed to the value, prior to any directory prefix adjustment. This can be used to extract archives that contain non-Unicode filenames, or which have files that would extract to the same path on case-insensitive filesystems. |
+| `url` | [string](/versions/9.0.0/rules/lib/core/string); or Iterable of [string](/versions/9.0.0/rules/lib/core/string)s; required  List of mirror URLs referencing the same file. |
+| `output` | [string](/versions/9.0.0/rules/lib/core/string); or [Label](/versions/9.0.0/rules/lib/builtins/Label); or [path](/versions/9.0.0/rules/lib/builtins/path); default is `''`  Path to the directory where the archive will be unpacked, relative to the repository directory. |
+| `sha256` | [string](/versions/9.0.0/rules/lib/core/string); default is `''`  The expected SHA-256 hash of the file downloaded. This must match the SHA-256 hash of the file downloaded. It is a security risk to omit the SHA-256 as remote files can change. At best omitting this field will make your build non-hermetic. It is optional to make development easier but should be set before shipping. If provided, the repository cache will first be checked for a file with the given hash; a download will only be attempted if the file was not found in the cache. After a successful download, the file will be added to the cache. |
+| `type` | [string](/versions/9.0.0/rules/lib/core/string); default is `''`  The archive type of the downloaded file. By default, the archive type is determined from the file extension of the URL. If the file has no extension, you can explicitly specify either "zip", "jar", "war", "aar", "nupkg", "whl", "tar", "tar.gz", "tgz", "gz", "tar.xz", "txz", "xz", "tar.zst", "tzst", "zst", "tar.bz2", "tbz", "bz2", "ar", "deb" or "7z" here. |
+| `strip_prefix` | [string](/versions/9.0.0/rules/lib/core/string); default is `''`  A directory prefix to strip from the extracted files. Many archives contain a top-level directory that contains all files in the archive. Instead of needing to specify this prefix over and over in the `build_file`, this field can be used to strip it from extracted files. For compatibility, this parameter may also be used under the deprecated name `stripPrefix`. |
+| `allow_fail` | [bool](/versions/9.0.0/rules/lib/core/bool); default is `False`  If set, indicate the error in the return value instead of raising an error for failed downloads. |
+| `canonical_id` | [string](/versions/9.0.0/rules/lib/core/string); default is `''`  If set, restrict cache hits to those cases where the file was added to the cache with the same canonical id. By default caching uses the checksum (`sha256` or `integrity`). |
+| `auth` | [dict](/versions/9.0.0/rules/lib/core/dict); default is `{}`  An optional dict specifying authentication information for some of the URLs. |
+| `headers` | [dict](/versions/9.0.0/rules/lib/core/dict); default is `{}`  An optional dict specifying http headers for all URLs. |
+| `integrity` | [string](/versions/9.0.0/rules/lib/core/string); default is `''`  Expected checksum of the file downloaded, in Subresource Integrity format. This must match the checksum of the file downloaded. It is a security risk to omit the checksum as remote files can change. At best omitting this field will make your build non-hermetic. It is optional to make development easier but should be set before shipping. If provided, the repository cache will first be checked for a file with the given checksum; a download will only be attempted if the file was not found in the cache. After a successful download, the file will be added to the cache. |
+| `rename_files` | [dict](/versions/9.0.0/rules/lib/core/dict); default is `{}`  An optional dict specifying files to rename during the extraction. Archive entries with names exactly matching a key will be renamed to the value, prior to any directory prefix adjustment. This can be used to extract archives that contain non-Unicode filenames, or which have files that would extract to the same path on case-insensitive filesystems. |
 
 ## execute
 
@@ -111,11 +111,11 @@ Executes the command given by the list of arguments. The execution time of the c
 
 | Parameter | Description |
 | --- | --- |
-| `arguments` | [sequence](../core/list); required  List of arguments, the first element should be the path to the program to execute. |
-| `timeout` | [int](../core/int); default is `600`  Maximum duration of the command in seconds (default is 600 seconds). |
-| `environment` | [dict](../core/dict); default is `{}`  Force some environment variables to be set to be passed to the process. The value can be `None` to remove the environment variable. |
-| `quiet` | [bool](../core/bool); default is `True`  If stdout and stderr should be printed to the terminal. |
-| `working_directory` | [string](../core/string); default is `""`  Working directory for command execution. Can be relative to the repository root or absolute. The default is the repository root. |
+| `arguments` | [sequence](/versions/9.0.0/rules/lib/core/list); required  List of arguments, the first element should be the path to the program to execute. |
+| `timeout` | [int](/versions/9.0.0/rules/lib/core/int); default is `600`  Maximum duration of the command in seconds (default is 600 seconds). |
+| `environment` | [dict](/versions/9.0.0/rules/lib/core/dict); default is `{}`  Force some environment variables to be set to be passed to the process. The value can be `None` to remove the environment variable. |
+| `quiet` | [bool](/versions/9.0.0/rules/lib/core/bool); default is `True`  If stdout and stderr should be printed to the terminal. |
+| `working_directory` | [string](/versions/9.0.0/rules/lib/core/string); default is `""`  Working directory for command execution. Can be relative to the repository root or absolute. The default is the repository root. |
 
 ## extract
 
@@ -129,12 +129,12 @@ Extract an archive to the repository directory.
 
 | Parameter | Description |
 | --- | --- |
-| `archive` | [string](../core/string); or [Label](../builtins/Label); or [path](../builtins/path); required  path to the archive that will be unpacked, relative to the repository directory. |
-| `output` | [string](../core/string); or [Label](../builtins/Label); or [path](../builtins/path); default is `''`  path to the directory where the archive will be unpacked, relative to the repository directory. |
-| `strip_prefix` | [string](../core/string); default is `''`  a directory prefix to strip from the extracted files. Many archives contain a top-level directory that contains all files in the archive. Instead of needing to specify this prefix over and over in the `build_file`, this field can be used to strip it from extracted files. For compatibility, this parameter may also be used under the deprecated name `stripPrefix`. |
-| `rename_files` | [dict](../core/dict); default is `{}`  An optional dict specifying files to rename during the extraction. Archive entries with names exactly matching a key will be renamed to the value, prior to any directory prefix adjustment. This can be used to extract archives that contain non-Unicode filenames, or which have files that would extract to the same path on case-insensitive filesystems. |
-| `watch_archive` | [string](../core/string); default is `'auto'`  whether to [watch](#watch) the archive file. Can be the string 'yes', 'no', or 'auto'. Passing 'yes' is equivalent to immediately invoking the [`watch()`](#watch) method; passing 'no' does not attempt to watch the file; passing 'auto' will only attempt to watch the file when it is legal to do so (see `watch()` docs for more information. |
-| `type` | [string](../core/string); default is `''`  The archive type of the downloaded file. By default, the archive type is determined from the file extension of the URL. If the file has no extension, you can explicitly specify either "zip", "jar", "war", "aar", "nupkg", "whl", "tar", "tar.gz", "tgz", "gz", "tar.xz", "txz", "xz", "tar.zst", "tzst", "zst", "tar.bz2", "tbz", "bz2", "ar", "deb" or "7z" here. |
+| `archive` | [string](/versions/9.0.0/rules/lib/core/string); or [Label](/versions/9.0.0/rules/lib/builtins/Label); or [path](/versions/9.0.0/rules/lib/builtins/path); required  path to the archive that will be unpacked, relative to the repository directory. |
+| `output` | [string](/versions/9.0.0/rules/lib/core/string); or [Label](/versions/9.0.0/rules/lib/builtins/Label); or [path](/versions/9.0.0/rules/lib/builtins/path); default is `''`  path to the directory where the archive will be unpacked, relative to the repository directory. |
+| `strip_prefix` | [string](/versions/9.0.0/rules/lib/core/string); default is `''`  a directory prefix to strip from the extracted files. Many archives contain a top-level directory that contains all files in the archive. Instead of needing to specify this prefix over and over in the `build_file`, this field can be used to strip it from extracted files. For compatibility, this parameter may also be used under the deprecated name `stripPrefix`. |
+| `rename_files` | [dict](/versions/9.0.0/rules/lib/core/dict); default is `{}`  An optional dict specifying files to rename during the extraction. Archive entries with names exactly matching a key will be renamed to the value, prior to any directory prefix adjustment. This can be used to extract archives that contain non-Unicode filenames, or which have files that would extract to the same path on case-insensitive filesystems. |
+| `watch_archive` | [string](/versions/9.0.0/rules/lib/core/string); default is `'auto'`  whether to [watch](#watch) the archive file. Can be the string 'yes', 'no', or 'auto'. Passing 'yes' is equivalent to immediately invoking the [`watch()`](#watch) method; passing 'no' does not attempt to watch the file; passing 'auto' will only attempt to watch the file when it is legal to do so (see `watch()` docs for more information. |
+| `type` | [string](/versions/9.0.0/rules/lib/core/string); default is `''`  The archive type of the downloaded file. By default, the archive type is determined from the file extension of the URL. If the file has no extension, you can explicitly specify either "zip", "jar", "war", "aar", "nupkg", "whl", "tar", "tar.gz", "tgz", "gz", "tar.xz", "txz", "xz", "tar.zst", "tzst", "zst", "tar.bz2", "tbz", "bz2", "ar", "deb" or "7z" here. |
 
 ## file
 
@@ -148,10 +148,10 @@ Generates a file in the repository directory with the provided content.
 
 | Parameter | Description |
 | --- | --- |
-| `path` | [string](../core/string); or [Label](../builtins/Label); or [path](../builtins/path); required  Path of the file to create, relative to the repository directory. |
-| `content` | [string](../core/string); default is `''`  The content of the file to create, empty by default. |
-| `executable` | [bool](../core/bool); default is `True`  Set the executable flag on the created file, true by default. |
-| `legacy_utf8` | [bool](../core/bool); default is `False`  No-op. This parameter is deprecated and will be removed in a future version of Bazel. |
+| `path` | [string](/versions/9.0.0/rules/lib/core/string); or [Label](/versions/9.0.0/rules/lib/builtins/Label); or [path](/versions/9.0.0/rules/lib/builtins/path); required  Path of the file to create, relative to the repository directory. |
+| `content` | [string](/versions/9.0.0/rules/lib/core/string); default is `''`  The content of the file to create, empty by default. |
+| `executable` | [bool](/versions/9.0.0/rules/lib/core/bool); default is `True`  Set the executable flag on the created file, true by default. |
+| `legacy_utf8` | [bool](/versions/9.0.0/rules/lib/core/bool); default is `False`  No-op. This parameter is deprecated and will be removed in a future version of Bazel. |
 
 ## getenv
 
@@ -167,8 +167,8 @@ When building incrementally, any change to the value of the variable named by `n
 
 | Parameter | Description |
 | --- | --- |
-| `name` | [string](../core/string); required  Name of desired environment variable. |
-| `default` | [string](../core/string); or `None`; default is `None`  Default value to return if `name` is not found. |
+| `name` | [string](/versions/9.0.0/rules/lib/core/string); required  Name of desired environment variable. |
+| `default` | [string](/versions/9.0.0/rules/lib/core/string); or `None`; default is `None`  Default value to return if `name` is not found. |
 
 May return `None`.
 
@@ -208,9 +208,9 @@ Apply a patch file to the root directory of external repository. The patch file
 
 | Parameter | Description |
 | --- | --- |
-| `patch_file` | [string](../core/string); or [Label](../builtins/Label); or [path](../builtins/path); required  The patch file to apply, it can be label, relative path or absolute path. If it's a relative path, it will resolve to the repository directory. |
-| `strip` | [int](../core/int); default is `0`  Strip the specified number of leading components from file names. |
-| `watch_patch` | [string](../core/string); default is `'auto'`  Whether to [watch](#watch) the patch file. Can be the string 'yes', 'no', or 'auto'. Passing 'yes' is equivalent to immediately invoking the [`watch()`](#watch) method; passing 'no' does not attempt to watch the file; passing 'auto' will only attempt to watch the file when it is legal to do so (see `watch()` docs for more information. |
+| `patch_file` | [string](/versions/9.0.0/rules/lib/core/string); or [Label](/versions/9.0.0/rules/lib/builtins/Label); or [path](/versions/9.0.0/rules/lib/builtins/path); required  The patch file to apply, it can be label, relative path or absolute path. If it's a relative path, it will resolve to the repository directory. |
+| `strip` | [int](/versions/9.0.0/rules/lib/core/int); default is `0`  Strip the specified number of leading components from file names. |
+| `watch_patch` | [string](/versions/9.0.0/rules/lib/core/string); default is `'auto'`  Whether to [watch](#watch) the patch file. Can be the string 'yes', 'no', or 'auto'. Passing 'yes' is equivalent to immediately invoking the [`watch()`](#watch) method; passing 'no' does not attempt to watch the file; passing 'auto' will only attempt to watch the file when it is legal to do so (see `watch()` docs for more information. |
 
 ## path
 
@@ -224,7 +224,7 @@ Returns a path from a string, label, or path. If this context is a `repository_c
 
 | Parameter | Description |
 | --- | --- |
-| `path` | [string](../core/string); or [Label](../builtins/Label); or [path](../builtins/path); required  `string`, `Label` or `path` from which to create a path from. |
+| `path` | [string](/versions/9.0.0/rules/lib/core/string); or [Label](/versions/9.0.0/rules/lib/builtins/Label); or [path](/versions/9.0.0/rules/lib/builtins/path); required  `string`, `Label` or `path` from which to create a path from. |
 
 ## read
 
@@ -238,8 +238,8 @@ Reads the content of a file on the filesystem.
 
 | Parameter | Description |
 | --- | --- |
-| `path` | [string](../core/string); or [Label](../builtins/Label); or [path](../builtins/path); required  Path of the file to read from. |
-| `watch` | [string](../core/string); default is `'auto'`  Whether to [watch](#watch) the file. Can be the string 'yes', 'no', or 'auto'. Passing 'yes' is equivalent to immediately invoking the [`watch()`](#watch) method; passing 'no' does not attempt to watch the file; passing 'auto' will only attempt to watch the file when it is legal to do so (see `watch()` docs for more information. |
+| `path` | [string](/versions/9.0.0/rules/lib/core/string); or [Label](/versions/9.0.0/rules/lib/builtins/Label); or [path](/versions/9.0.0/rules/lib/builtins/path); required  Path of the file to read from. |
+| `watch` | [string](/versions/9.0.0/rules/lib/core/string); default is `'auto'`  Whether to [watch](#watch) the file. Can be the string 'yes', 'no', or 'auto'. Passing 'yes' is equivalent to immediately invoking the [`watch()`](#watch) method; passing 'no' does not attempt to watch the file; passing 'auto' will only attempt to watch the file when it is legal to do so (see `watch()` docs for more information. |
 
 ## rename
 
@@ -254,8 +254,8 @@ already exists. Both paths must be located within the repository.
 
 | Parameter | Description |
 | --- | --- |
-| `src` | [string](../core/string); or [Label](../builtins/Label); or [path](../builtins/path); required  The path of the existing file or directory to rename, relative to the repository directory. |
-| `dst` | [string](../core/string); or [Label](../builtins/Label); or [path](../builtins/path); required  The new name to which the file or directory will be renamed to, relative to the repository directory. |
+| `src` | [string](/versions/9.0.0/rules/lib/core/string); or [Label](/versions/9.0.0/rules/lib/builtins/Label); or [path](/versions/9.0.0/rules/lib/builtins/path); required  The path of the existing file or directory to rename, relative to the repository directory. |
+| `dst` | [string](/versions/9.0.0/rules/lib/core/string); or [Label](/versions/9.0.0/rules/lib/builtins/Label); or [path](/versions/9.0.0/rules/lib/builtins/path); required  The new name to which the file or directory will be renamed to, relative to the repository directory. |
 
 ## repo\_metadata
 
@@ -269,8 +269,8 @@ Constructs an opaque object that can be returned from the repo rule's implementa
 
 | Parameter | Description |
 | --- | --- |
-| `reproducible` | [bool](../core/bool); default is `False`  States that this repo can be reproducibly refetched; that is, if it were fetched another time with exactly the same input attributes, repo rule definition, watched files and environment variables, etc., then exactly the same output would be produced. This property needs to hold even if other untracked conditions change, such as information from the internet, the path of the workspace root, output from running arbitrary executables, etc. If set to True, this allows the fetched repo contents to be cached across workspaces. Note that setting this to True does not guarantee caching in the repo contents cache; for example, local repo rules are never cached. |
-| `attrs_for_reproducibility` | [dict](../core/dict); default is `{}`  If `reproducible` is False, this can be specified to tell Bazel which attributes of the original repo rule to change to make it reproducible. |
+| `reproducible` | [bool](/versions/9.0.0/rules/lib/core/bool); default is `False`  States that this repo can be reproducibly refetched; that is, if it were fetched another time with exactly the same input attributes, repo rule definition, watched files and environment variables, etc., then exactly the same output would be produced. This property needs to hold even if other untracked conditions change, such as information from the internet, the path of the workspace root, output from running arbitrary executables, etc. If set to True, this allows the fetched repo contents to be cached across workspaces. Note that setting this to True does not guarantee caching in the repo contents cache; for example, local repo rules are never cached. |
+| `attrs_for_reproducibility` | [dict](/versions/9.0.0/rules/lib/core/dict); default is `{}`  If `reproducible` is False, this can be specified to tell Bazel which attributes of the original repo rule to change to make it reproducible. |
 
 ## report\_progress
 
@@ -284,7 +284,7 @@ Updates the progress status for the fetching of this repository or module extens
 
 | Parameter | Description |
 | --- | --- |
-| `status` | [string](../core/string); default is `''`  `string` describing the current status of the fetch progress. |
+| `status` | [string](/versions/9.0.0/rules/lib/core/string); default is `''`  `string` describing the current status of the fetch progress. |
 
 ## symlink
 
@@ -298,8 +298,8 @@ Creates a symlink on the filesystem.
 
 | Parameter | Description |
 | --- | --- |
-| `target` | [string](../core/string); or [Label](../builtins/Label); or [path](../builtins/path); required  The path that the symlink should point to. |
-| `link_name` | [string](../core/string); or [Label](../builtins/Label); or [path](../builtins/path); required  The path of the symlink to create. |
+| `target` | [string](/versions/9.0.0/rules/lib/core/string); or [Label](/versions/9.0.0/rules/lib/builtins/Label); or [path](/versions/9.0.0/rules/lib/builtins/path); required  The path that the symlink should point to. |
+| `link_name` | [string](/versions/9.0.0/rules/lib/core/string); or [Label](/versions/9.0.0/rules/lib/builtins/Label); or [path](/versions/9.0.0/rules/lib/builtins/path); required  The path of the symlink to create. |
 
 ## template
 
@@ -313,11 +313,11 @@ Generates a new file using a `template`. Every occurrence in `template` of a key
 
 | Parameter | Description |
 | --- | --- |
-| `path` | [string](../core/string); or [Label](../builtins/Label); or [path](../builtins/path); required  Path of the file to create, relative to the repository directory. |
-| `template` | [string](../core/string); or [Label](../builtins/Label); or [path](../builtins/path); required  Path to the template file. |
-| `substitutions` | [dict](../core/dict); default is `{}`  Substitutions to make when expanding the template. |
-| `executable` | [bool](../core/bool); default is `True`  Set the executable flag on the created file, true by default. |
-| `watch_template` | [string](../core/string); default is `'auto'`  Whether to [watch](#watch) the template file. Can be the string 'yes', 'no', or 'auto'. Passing 'yes' is equivalent to immediately invoking the [`watch()`](#watch) method; passing 'no' does not attempt to watch the file; passing 'auto' will only attempt to watch the file when it is legal to do so (see `watch()` docs for more information. |
+| `path` | [string](/versions/9.0.0/rules/lib/core/string); or [Label](/versions/9.0.0/rules/lib/builtins/Label); or [path](/versions/9.0.0/rules/lib/builtins/path); required  Path of the file to create, relative to the repository directory. |
+| `template` | [string](/versions/9.0.0/rules/lib/core/string); or [Label](/versions/9.0.0/rules/lib/builtins/Label); or [path](/versions/9.0.0/rules/lib/builtins/path); required  Path to the template file. |
+| `substitutions` | [dict](/versions/9.0.0/rules/lib/core/dict); default is `{}`  Substitutions to make when expanding the template. |
+| `executable` | [bool](/versions/9.0.0/rules/lib/core/bool); default is `True`  Set the executable flag on the created file, true by default. |
+| `watch_template` | [string](/versions/9.0.0/rules/lib/core/string); default is `'auto'`  Whether to [watch](#watch) the template file. Can be the string 'yes', 'no', or 'auto'. Passing 'yes' is equivalent to immediately invoking the [`watch()`](#watch) method; passing 'no' does not attempt to watch the file; passing 'auto' will only attempt to watch the file when it is legal to do so (see `watch()` docs for more information. |
 
 ## watch
 
@@ -327,7 +327,7 @@ None repository_ctx.watch(path)
 
 Tells Bazel to watch for changes to the given path, whether or not it exists, or whether it's a file or a directory. Any changes to the file or directory will invalidate this repository or module extension, and cause it to be refetched or re-evaluated next time.
 
-"Changes" include changes to the contents of the file (if the path is a file); if the path was a file but is now a directory, or vice versa; and if the path starts or stops existing. Notably, this does *not* include changes to any files under the directory if the path is a directory. For that, use [`path.readdir()`](path#readdir) instead.
+"Changes" include changes to the contents of the file (if the path is a file); if the path was a file but is now a directory, or vice versa; and if the path starts or stops existing. Notably, this does *not* include changes to any files under the directory if the path is a directory. For that, use [`path.readdir()`](/versions/9.0.0/rules/lib/builtins/path#readdir) instead.
 
 Note that attempting to watch paths inside the repo currently being fetched, or inside the working directory of the current module extension, will result in an error. A module extension attempting to watch a path outside the current Bazel workspace will also result in an error.
 
@@ -335,7 +335,7 @@ Note that attempting to watch paths inside the repo currently being fetched, or
 
 | Parameter | Description |
 | --- | --- |
-| `path` | [string](../core/string); or [Label](../builtins/Label); or [path](../builtins/path); required  Path of the file to watch. |
+| `path` | [string](/versions/9.0.0/rules/lib/core/string); or [Label](/versions/9.0.0/rules/lib/builtins/Label); or [path](/versions/9.0.0/rules/lib/builtins/path); required  Path of the file to watch. |
 
 ## watch\_tree
 
@@ -351,7 +351,7 @@ Note that attempting to watch paths inside the repo currently being fetched will
 
 | Parameter | Description |
 | --- | --- |
-| `path` | [string](../core/string); or [Label](../builtins/Label); or [path](../builtins/path); required  Path of the directory tree to watch. |
+| `path` | [string](/versions/9.0.0/rules/lib/core/string); or [Label](/versions/9.0.0/rules/lib/builtins/Label); or [path](/versions/9.0.0/rules/lib/builtins/path); required  Path of the directory tree to watch. |
 
 ## which
 
@@ -365,7 +365,7 @@ Returns the `path` of the corresponding program or `None` if there is no such pr
 
 | Parameter | Description |
 | --- | --- |
-| `program` | [string](../core/string); required  Program to find in the path. |
+| `program` | [string](/versions/9.0.0/rules/lib/core/string); required  Program to find in the path. |
 
 May return `None`.
 
diff --git a/versions/9.0.0/rules/lib/builtins/repository_rule.mdx b/versions/9.0.0/rules/lib/builtins/repository_rule.mdx
index 4fe58461..a6536775 100644
--- a/versions/9.0.0/rules/lib/builtins/repository_rule.mdx
+++ b/versions/9.0.0/rules/lib/builtins/repository_rule.mdx
@@ -2,4 +2,4 @@
 title: 'repository\_rule'
 ---
 
-A callable value that may be invoked within the implementation function of a module extension to instantiate and return a repository rule. Created by [`repository_rule()`](../globals/bzl#repository_rule).
\ No newline at end of file
+A callable value that may be invoked within the implementation function of a module extension to instantiate and return a repository rule. Created by [`repository_rule()`](/versions/9.0.0/rules/lib/globals/bzl#repository_rule).
\ No newline at end of file
diff --git a/versions/9.0.0/rules/lib/builtins/rule.mdx b/versions/9.0.0/rules/lib/builtins/rule.mdx
index 44df8e3a..c3efa721 100644
--- a/versions/9.0.0/rules/lib/builtins/rule.mdx
+++ b/versions/9.0.0/rules/lib/builtins/rule.mdx
@@ -3,7 +3,7 @@ title: 'rule'
 ---
 
 A callable value representing the type of a native or Starlark rule (created by
-[`rule()`](../globals/bzl#rule)). Calling the value during
+[`rule()`](/versions/9.0.0/rules/lib/globals/bzl#rule)). Calling the value during
 evaluation of a package's BUILD file creates an instance of the rule and adds it to the
 package's target set. For more information, visit this page about
 [Rules](https://bazel.build/versions/9.0.0/extending/rules).
\ No newline at end of file
diff --git a/versions/9.0.0/rules/lib/builtins/rule_attributes.mdx b/versions/9.0.0/rules/lib/builtins/rule_attributes.mdx
index 3a57bfed..a541d465 100644
--- a/versions/9.0.0/rules/lib/builtins/rule_attributes.mdx
+++ b/versions/9.0.0/rules/lib/builtins/rule_attributes.mdx
@@ -21,7 +21,7 @@ Information about attributes of a rule an aspect is applied to.
 struct rule_attributes.attr
 ```
 
-A struct to access the values of the [attributes](https://bazel.build/versions/9.0.0/extending/rules#attributes). The values are provided by the user (if not, a default value is used). The attributes of the struct and the types of their values correspond to the keys and values of the [`attrs` dict](../globals/bzl#rule.attrs) provided to the [`rule` function](../globals/bzl#rule). [See example of use](https://github.com/bazelbuild/examples/blob/main/rules/attributes/printer.bzl).
+A struct to access the values of the [attributes](https://bazel.build/versions/9.0.0/extending/rules#attributes). The values are provided by the user (if not, a default value is used). The attributes of the struct and the types of their values correspond to the keys and values of the [`attrs` dict](/versions/9.0.0/rules/lib/globals/bzl#rule.attrs) provided to the [`rule` function](/versions/9.0.0/rules/lib/globals/bzl#rule). [See example of use](https://github.com/bazelbuild/examples/blob/main/rules/attributes/printer.bzl).
 
 ## exec\_groups
 
@@ -37,7 +37,7 @@ A collection of the execution groups available for the rule the aspect is applie
 struct rule_attributes.executable
 ```
 
-A `struct` containing executable files defined in [label type attributes](../toplevel/attr#label) marked as [`executable=True`](../toplevel/attr#label.executable). The struct fields correspond to the attribute names. Each value in the struct is either a [`File`](../builtins/File) or `None`. If an optional attribute is not specified in the rule then the corresponding struct value is `None`. If a label type is not marked as `executable=True`, no corresponding struct field is generated. [See example of use](https://github.com/bazelbuild/examples/blob/main/rules/actions_run/execute.bzl).
+A `struct` containing executable files defined in [label type attributes](/versions/9.0.0/rules/lib/toplevel/attr#label) marked as [`executable=True`](/versions/9.0.0/rules/lib/toplevel/attr#label.executable). The struct fields correspond to the attribute names. Each value in the struct is either a [`File`](/versions/9.0.0/rules/lib/builtins/File) or `None`. If an optional attribute is not specified in the rule then the corresponding struct value is `None`. If a label type is not marked as `executable=True`, no corresponding struct field is generated. [See example of use](https://github.com/bazelbuild/examples/blob/main/rules/actions_run/execute.bzl).
 
 ## file
 
@@ -45,7 +45,7 @@ A `struct` containing executable files defined in [label type attributes](../top
 struct rule_attributes.file
 ```
 
-A `struct` containing files defined in [label type attributes](../toplevel/attr#label) marked as [`allow_single_file`](../toplevel/attr#label.allow_single_file). The struct fields correspond to the attribute names. The struct value is always a [`File`](../builtins/File) or `None`. If an optional attribute is not specified in the rule then the corresponding struct value is `None`. If a label type is not marked as `allow_single_file`, no corresponding struct field is generated. It is a shortcut for:
+A `struct` containing files defined in [label type attributes](/versions/9.0.0/rules/lib/toplevel/attr#label) marked as [`allow_single_file`](/versions/9.0.0/rules/lib/toplevel/attr#label.allow_single_file). The struct fields correspond to the attribute names. The struct value is always a [`File`](/versions/9.0.0/rules/lib/builtins/File) or `None`. If an optional attribute is not specified in the rule then the corresponding struct value is `None`. If a label type is not marked as `allow_single_file`, no corresponding struct field is generated. It is a shortcut for:
 
 ```
 list(ctx.attr..files)[0]
@@ -59,7 +59,7 @@ In other words, use `file` to access the (singular) [default output](https://baz
 struct rule_attributes.files
 ```
 
-A `struct` containing files defined in [label](../toplevel/attr#label) or [label list](../toplevel/attr#label_list) type attributes. The struct fields correspond to the attribute names. The struct values are `list` of [`File`](../builtins/File)s. It is a shortcut for:
+A `struct` containing files defined in [label](/versions/9.0.0/rules/lib/toplevel/attr#label) or [label list](/versions/9.0.0/rules/lib/toplevel/attr#label_list) type attributes. The struct fields correspond to the attribute names. The struct values are `list` of [`File`](/versions/9.0.0/rules/lib/builtins/File)s. It is a shortcut for:
 
 ```
 [f for t in ctx.attr. for f in t.files]
diff --git a/versions/9.0.0/rules/lib/builtins/runfiles.mdx b/versions/9.0.0/rules/lib/builtins/runfiles.mdx
index 15e6dc23..6a259b92 100644
--- a/versions/9.0.0/rules/lib/builtins/runfiles.mdx
+++ b/versions/9.0.0/rules/lib/builtins/runfiles.mdx
@@ -2,7 +2,7 @@
 title: 'runfiles'
 ---
 
-A container of information regarding a set of files required at runtime by an executable. This object should be passed via [`DefaultInfo`](../providers/DefaultInfo) in order to tell the build system about the runfiles needed by the outputs produced by the rule.
+A container of information regarding a set of files required at runtime by an executable. This object should be passed via [`DefaultInfo`](/versions/9.0.0/rules/lib/providers/DefaultInfo) in order to tell the build system about the runfiles needed by the outputs produced by the rule.
 
 See [runfiles guide](https://bazel.build/versions/9.0.0/extending/rules#runfiles) for details.
 
@@ -45,7 +45,7 @@ Returns a new runfiles object that includes all the contents of this one and the
 
 | Parameter | Description |
 | --- | --- |
-| `other` | [runfiles](../builtins/runfiles); required  The runfiles object to merge into this. |
+| `other` | [runfiles](/versions/9.0.0/rules/lib/builtins/runfiles); required  The runfiles object to merge into this. |
 
 ## merge\_all
 
@@ -59,7 +59,7 @@ Returns a new runfiles object that includes all the contents of this one and of
 
 | Parameter | Description |
 | --- | --- |
-| `other` | [sequence](../core/list) of [runfiles](../builtins/runfiles)s; required  The sequence of runfiles objects to merge into this. |
+| `other` | [sequence](/versions/9.0.0/rules/lib/core/list) of [runfiles](/versions/9.0.0/rules/lib/builtins/runfiles)s; required  The sequence of runfiles objects to merge into this. |
 
 ## root\_symlinks
 
diff --git a/versions/9.0.0/rules/lib/builtins/tag_class.mdx b/versions/9.0.0/rules/lib/builtins/tag_class.mdx
index 7d4349d0..921b8aec 100644
--- a/versions/9.0.0/rules/lib/builtins/tag_class.mdx
+++ b/versions/9.0.0/rules/lib/builtins/tag_class.mdx
@@ -2,4 +2,4 @@
 title: 'tag\_class'
 ---
 
-Defines a schema of attributes for a tag, created by [`tag_class()`](../globals/bzl#tag_class).
\ No newline at end of file
+Defines a schema of attributes for a tag, created by [`tag_class()`](/versions/9.0.0/rules/lib/globals/bzl#tag_class).
\ No newline at end of file
diff --git a/versions/9.0.0/rules/lib/builtins/template_ctx.mdx b/versions/9.0.0/rules/lib/builtins/template_ctx.mdx
index e207b172..a4cb7f6a 100644
--- a/versions/9.0.0/rules/lib/builtins/template_ctx.mdx
+++ b/versions/9.0.0/rules/lib/builtins/template_ctx.mdx
@@ -32,8 +32,8 @@ Remember that in addition to declaring a file, you must separately create an act
 
 | Parameter | Description |
 | --- | --- |
-| `filename` | [string](../core/string); required  The relative path of the file within the directory. |
-| `directory` | [File](../builtins/File); required  The directory in which the file should be created. |
+| `filename` | [string](/versions/9.0.0/rules/lib/core/string); required  The relative path of the file within the directory. |
+| `directory` | [File](/versions/9.0.0/rules/lib/builtins/File); required  The directory in which the file should be created. |
 
 ## run
 
@@ -47,9 +47,9 @@ Creates an action that runs an executable.
 
 | Parameter | Description |
 | --- | --- |
-| `outputs` | [sequence](../core/list) of [File](../builtins/File)s; required  List of the output files of the action. |
-| `inputs` | [sequence](../core/list) of [File](../builtins/File)s; or [depset](../builtins/depset); default is `[]`  List or depset of the input files of the action. |
-| `executable` | [File](../builtins/File); or [string](../core/string); or [FilesToRunProvider](../providers/FilesToRunProvider); required  The executable file to be called by the action. |
-| `tools` | [sequence](../core/list); or [depset](../builtins/depset); or `None`; default is `None`  List or [`depset`](../builtins/depset) of any tools needed by the action. Tools are executable inputs that may have their own runfiles which are automatically made available to the action. When a list is provided, it can be a heterogenous collection of:  * `File`s * `FilesToRunProvider` instances * `depset`s of `File`s  `File`s from [`ctx.executable`](../builtins/ctx#executable) and `FilesToRunProvider`s which are directly in the list will have their runfiles automatically added. All tools are implicitly added as inputs. |
-| `arguments` | [sequence](../core/list); default is `[]`  Command line arguments of the action. Must be a list of strings or [`actions.args()`](#args) objects. |
-| `progress_message` | [string](../core/string); or `None`; default is `None`  Progress message to show to the user during the build. |
\ No newline at end of file
+| `outputs` | [sequence](/versions/9.0.0/rules/lib/core/list) of [File](/versions/9.0.0/rules/lib/builtins/File)s; required  List of the output files of the action. |
+| `inputs` | [sequence](/versions/9.0.0/rules/lib/core/list) of [File](/versions/9.0.0/rules/lib/builtins/File)s; or [depset](/versions/9.0.0/rules/lib/builtins/depset); default is `[]`  List or depset of the input files of the action. |
+| `executable` | [File](/versions/9.0.0/rules/lib/builtins/File); or [string](/versions/9.0.0/rules/lib/core/string); or [FilesToRunProvider](/versions/9.0.0/rules/lib/providers/FilesToRunProvider); required  The executable file to be called by the action. |
+| `tools` | [sequence](/versions/9.0.0/rules/lib/core/list); or [depset](/versions/9.0.0/rules/lib/builtins/depset); or `None`; default is `None`  List or [`depset`](/versions/9.0.0/rules/lib/builtins/depset) of any tools needed by the action. Tools are executable inputs that may have their own runfiles which are automatically made available to the action. When a list is provided, it can be a heterogenous collection of:  * `File`s * `FilesToRunProvider` instances * `depset`s of `File`s  `File`s from [`ctx.executable`](/versions/9.0.0/rules/lib/builtins/ctx#executable) and `FilesToRunProvider`s which are directly in the list will have their runfiles automatically added. All tools are implicitly added as inputs. |
+| `arguments` | [sequence](/versions/9.0.0/rules/lib/core/list); default is `[]`  Command line arguments of the action. Must be a list of strings or [`actions.args()`](#args) objects. |
+| `progress_message` | [string](/versions/9.0.0/rules/lib/core/string); or `None`; default is `None`  Progress message to show to the user during the build. |
\ No newline at end of file
diff --git a/versions/9.0.0/rules/lib/builtins/transition.mdx b/versions/9.0.0/rules/lib/builtins/transition.mdx
index 0d14fa79..20548488 100644
--- a/versions/9.0.0/rules/lib/builtins/transition.mdx
+++ b/versions/9.0.0/rules/lib/builtins/transition.mdx
@@ -39,5 +39,5 @@ For more details see [here](https://bazel.build/versions/9.0.0/rules/config#user
 | Parameter | Description |
 | --- | --- |
 | `implementation` | callable; required  The function implementing this transition. This function always has two parameters: `settings` and `attr`. The `settings` param is a dictionary whose set of keys is defined by the inputs parameter. So, for each build setting `--//foo=bar`, if `inputs` contains `//foo`, `settings` will have an entry `settings['//foo']='bar'`. The `attr` param is a reference to `ctx.attr`. This gives the implementation function access to the rule's attributes to make attribute-parameterized transitions possible. This function must return a `dict` from build setting identifier to build setting value; this represents the configuration transition: for each entry in the returned `dict`, the transition updates that setting to the new value. All other settings are unchanged. This function can also return a `list` of `dict`s or a `dict` of `dict`s in the case of a split transition. |
-| `inputs` | [sequence](../core/list) of [string](../core/string)s; required  List of build settings that can be read by this transition. This becomes the key set of the settings parameter of the implementation function parameter. |
-| `outputs` | [sequence](../core/list) of [string](../core/string)s; required  List of build settings that can be written by this transition. This must be a superset of the key set of the dictionary returned by this transition. |
\ No newline at end of file
+| `inputs` | [sequence](/versions/9.0.0/rules/lib/core/list) of [string](/versions/9.0.0/rules/lib/core/string)s; required  List of build settings that can be read by this transition. This becomes the key set of the settings parameter of the implementation function parameter. |
+| `outputs` | [sequence](/versions/9.0.0/rules/lib/core/list) of [string](/versions/9.0.0/rules/lib/core/string)s; required  List of build settings that can be written by this transition. This must be a superset of the key set of the dictionary returned by this transition. |
\ No newline at end of file
diff --git a/versions/9.0.0/rules/lib/core/bool.mdx b/versions/9.0.0/rules/lib/core/bool.mdx
index 52be3664..7951e9a0 100644
--- a/versions/9.0.0/rules/lib/core/bool.mdx
+++ b/versions/9.0.0/rules/lib/core/bool.mdx
@@ -2,4 +2,4 @@
 title: 'bool'
 ---
 
-A type to represent booleans. There are only two possible values: True and False. Any value can be converted to a boolean using the [bool](../globals/all#bool) function.
\ No newline at end of file
+A type to represent booleans. There are only two possible values: True and False. Any value can be converted to a boolean using the [bool](/versions/9.0.0/rules/lib/globals/all#bool) function.
\ No newline at end of file
diff --git a/versions/9.0.0/rules/lib/core/dict.mdx b/versions/9.0.0/rules/lib/core/dict.mdx
index 9005668c..26809552 100644
--- a/versions/9.0.0/rules/lib/core/dict.mdx
+++ b/versions/9.0.0/rules/lib/core/dict.mdx
@@ -22,7 +22,7 @@ There are four ways to construct a dictionary:
      {i: 2*i for i in range(3)}  # {0: 0, 1: 2, 2: 4}
      ```
 
-     - A call to the built-in [dict](../globals/all#dict) function returns a dictionary containing the specified entries, which are inserted in argument order, positional arguments before named. As with comprehensions, duplicate keys are permitted.- The union expression `x | y` yields a new dictionary by combining two existing dictionaries. If the two dictionaries have a key `k` in common, the right hand side dictionary's value of the key (in other words, `y[k]`) wins. The `|=` variant of the union operator modifies a dictionary in-place. Example:
+     - A call to the built-in [dict](/versions/9.0.0/rules/lib/globals/all#dict) function returns a dictionary containing the specified entries, which are inserted in argument order, positional arguments before named. As with comprehensions, duplicate keys are permitted.- The union expression `x | y` yields a new dictionary by combining two existing dictionaries. If the two dictionaries have a key `k` in common, the right hand side dictionary's value of the key (in other words, `y[k]`) wins. The `|=` variant of the union operator modifies a dictionary in-place. Example:
 
          ```
          d = {"foo": "FOO", "bar": "BAR"} | {"foo": "FOO2", "baz": "BAZ"}
diff --git a/versions/9.0.0/rules/lib/core/json.mdx b/versions/9.0.0/rules/lib/core/json.mdx
index 54c117b4..8f1e7a9f 100644
--- a/versions/9.0.0/rules/lib/core/json.mdx
+++ b/versions/9.0.0/rules/lib/core/json.mdx
@@ -29,7 +29,7 @@ If `x` is not a valid JSON encoding and the optional `default` parameter is *not
 
 | Parameter | Description |
 | --- | --- |
-| `x` | [string](../core/string); required  JSON string to decode. |
+| `x` | [string](/versions/9.0.0/rules/lib/core/string); required  JSON string to decode. |
 | `default` | default is `unbound`  If specified, the value to return when `x` cannot be decoded. |
 
 ## encode
@@ -64,8 +64,8 @@ The encode\_indent function is equivalent to `json.indent(json.encode(x), ...)`.
 | Parameter | Description |
 | --- | --- |
 | `x` | required |
-| `prefix` | [string](../core/string); default is `''` |
-| `indent` | [string](../core/string); default is `'\t'` |
+| `prefix` | [string](/versions/9.0.0/rules/lib/core/string); default is `''` |
+| `indent` | [string](/versions/9.0.0/rules/lib/core/string); default is `'\t'` |
 
 ## indent
 
@@ -84,6 +84,6 @@ If the input is not valid, the function may fail or return invalid output.
 
 | Parameter | Description |
 | --- | --- |
-| `s` | [string](../core/string); required |
-| `prefix` | [string](../core/string); default is `''` |
-| `indent` | [string](../core/string); default is `'\t'` |
\ No newline at end of file
+| `s` | [string](/versions/9.0.0/rules/lib/core/string); required |
+| `prefix` | [string](/versions/9.0.0/rules/lib/core/string); default is `''` |
+| `indent` | [string](/versions/9.0.0/rules/lib/core/string); default is `'\t'` |
\ No newline at end of file
diff --git a/versions/9.0.0/rules/lib/core/list.mdx b/versions/9.0.0/rules/lib/core/list.mdx
index d93545eb..bc864a82 100644
--- a/versions/9.0.0/rules/lib/core/list.mdx
+++ b/versions/9.0.0/rules/lib/core/list.mdx
@@ -91,8 +91,8 @@ Returns the index in the list of the first item whose value is x. It is an error
 | Parameter | Description |
 | --- | --- |
 | `x` | required |
-| `start` | [int](../core/int); default is `unbound`  The start index of the list portion to inspect. |
-| `end` | [int](../core/int); default is `unbound`  The end index of the list portion to inspect. |
+| `start` | [int](/versions/9.0.0/rules/lib/core/int); default is `unbound`  The start index of the list portion to inspect. |
+| `end` | [int](/versions/9.0.0/rules/lib/core/int); default is `unbound`  The end index of the list portion to inspect. |
 
 ## insert
 
@@ -106,7 +106,7 @@ Inserts an item at a given position.
 
 | Parameter | Description |
 | --- | --- |
-| `index` | [int](../core/int); required  The index of the given position. |
+| `index` | [int](/versions/9.0.0/rules/lib/core/int); required  The index of the given position. |
 | `item` | required  The item. |
 
 ## pop
@@ -121,7 +121,7 @@ Removes the item at the given position in the list, and returns it. If no `index
 
 | Parameter | Description |
 | --- | --- |
-| `i` | [int](../core/int); default is `-1`  The index of the item. |
+| `i` | [int](/versions/9.0.0/rules/lib/core/int); default is `-1`  The index of the item. |
 
 ## remove
 
diff --git a/versions/9.0.0/rules/lib/core/set.mdx b/versions/9.0.0/rules/lib/core/set.mdx
index 860c4362..f74f19f5 100644
--- a/versions/9.0.0/rules/lib/core/set.mdx
+++ b/versions/9.0.0/rules/lib/core/set.mdx
@@ -3,14 +3,14 @@ title: 'set'
 ---
 
 The built-in set type. A set is a mutable collection of unique values – the set's
-*elements*. The [type name](../globals/all#type) of a set is `"set"`.
+*elements*. The [type name](/versions/9.0.0/rules/lib/globals/all#type) of a set is `"set"`.
 
 Sets provide constant-time operations to insert, remove, or check for the presence of a value.
 Sets are implemented using a hash table, and therefore, just like keys of a
-[dictionary](../dict), elements of a set must be hashable. A value may be used as an
+[dictionary](/versions/9.0.0/rules/lib/core/dict), elements of a set must be hashable. A value may be used as an
 element of a set if and only if it may be used as a key of a dictionary.
 
-Sets may be constructed using the [`set()`](../globals/all#set) built-in
+Sets may be constructed using the [`set()`](/versions/9.0.0/rules/lib/globals/all#set) built-in
 function, which returns a new set containing the unique elements of its optional argument, which
 must be an iterable. Calling `set()` without an argument constructs an empty set. Sets
 have no literal syntax.
@@ -26,7 +26,7 @@ s = set(["a", "b", "c"])
 
 A set is iterable, and thus may be used as the operand of a `for` loop, a list
 comprehension, and the various built-in functions that operate on iterables. Its length can be
-retrieved using the [`len()`](../globals/all#len) built-in function, and the
+retrieved using the [`len()`](/versions/9.0.0/rules/lib/globals/all#len) built-in function, and the
 order of iteration is the order in which elements were first added to the set:
 
 ```
diff --git a/versions/9.0.0/rules/lib/core/string.mdx b/versions/9.0.0/rules/lib/core/string.mdx
index 691cd545..99ea1913 100644
--- a/versions/9.0.0/rules/lib/core/string.mdx
+++ b/versions/9.0.0/rules/lib/core/string.mdx
@@ -82,9 +82,9 @@ Returns the number of (non-overlapping) occurrences of substring `sub` in string
 
 | Parameter | Description |
 | --- | --- |
-| `sub` | [string](../core/string); required |
-| `start` | [int](../core/int); or `None`; default is `0` |
-| `end` | [int](../core/int); or `None`; default is `None`  optional position before which to restrict to search. |
+| `sub` | [string](/versions/9.0.0/rules/lib/core/string); required |
+| `start` | [int](/versions/9.0.0/rules/lib/core/int); or `None`; default is `0` |
+| `end` | [int](/versions/9.0.0/rules/lib/core/int); or `None`; default is `None`  optional position before which to restrict to search. |
 
 ## elems
 
@@ -106,9 +106,9 @@ Returns True if the string ends with `sub`, otherwise False, optionally restrict
 
 | Parameter | Description |
 | --- | --- |
-| `sub` | [string](../core/string); or [tuple](../core/tuple) of [string](../core/string)s; required  The suffix (or tuple of alternative suffixes) to match. |
-| `start` | [int](../core/int); or `None`; default is `0`  Test beginning at this position. |
-| `end` | [int](../core/int); or `None`; default is `None`  optional position at which to stop comparing. |
+| `sub` | [string](/versions/9.0.0/rules/lib/core/string); or [tuple](/versions/9.0.0/rules/lib/core/tuple) of [string](/versions/9.0.0/rules/lib/core/string)s; required  The suffix (or tuple of alternative suffixes) to match. |
+| `start` | [int](/versions/9.0.0/rules/lib/core/int); or `None`; default is `0`  Test beginning at this position. |
+| `end` | [int](/versions/9.0.0/rules/lib/core/int); or `None`; default is `None`  optional position at which to stop comparing. |
 
 ## find
 
@@ -122,9 +122,9 @@ Returns the first index where `sub` is found, or -1 if no such index exists, opt
 
 | Parameter | Description |
 | --- | --- |
-| `sub` | [string](../core/string); required  The substring to find. |
-| `start` | [int](../core/int); or `None`; default is `0`  Restrict to search from this position. |
-| `end` | [int](../core/int); or `None`; default is `None`  optional position before which to restrict to search. |
+| `sub` | [string](/versions/9.0.0/rules/lib/core/string); required  The substring to find. |
+| `start` | [int](/versions/9.0.0/rules/lib/core/int); or `None`; default is `0`  Restrict to search from this position. |
+| `end` | [int](/versions/9.0.0/rules/lib/core/int); or `None`; default is `None`  optional position before which to restrict to search. |
 
 ## format
 
@@ -132,7 +132,7 @@ Returns the first index where `sub` is found, or -1 if no such index exists, opt
 string string.format(*args, **kwargs)
 ```
 
-Perform string interpolation. Format strings contain replacement fields surrounded by curly braces `{}`. Anything that is not contained in braces is considered literal text, which is copied unchanged to the output.If you need to include a brace character in the literal text, it can be escaped by doubling: `{{` and `}}`A replacement field can be either a name, a number, or empty. Values are converted to strings using the [str](../globals/all#str) function.
+Perform string interpolation. Format strings contain replacement fields surrounded by curly braces `{}`. Anything that is not contained in braces is considered literal text, which is copied unchanged to the output.If you need to include a brace character in the literal text, it can be escaped by doubling: `{{` and `}}`A replacement field can be either a name, a number, or empty. Values are converted to strings using the [str](/versions/9.0.0/rules/lib/globals/all#str) function.
 
 ```
 # Access in order:
@@ -162,9 +162,9 @@ Returns the first index where `sub` is found, or raises an error if no such inde
 
 | Parameter | Description |
 | --- | --- |
-| `sub` | [string](../core/string); required  The substring to find. |
-| `start` | [int](../core/int); or `None`; default is `0`  Restrict to search from this position. |
-| `end` | [int](../core/int); or `None`; default is `None`  optional position before which to restrict to search. |
+| `sub` | [string](/versions/9.0.0/rules/lib/core/string); required  The substring to find. |
+| `start` | [int](/versions/9.0.0/rules/lib/core/int); or `None`; default is `0`  Restrict to search from this position. |
+| `end` | [int](/versions/9.0.0/rules/lib/core/int); or `None`; default is `None`  optional position before which to restrict to search. |
 
 ## isalnum
 
@@ -238,7 +238,7 @@ Returns a string in which the string elements of the argument have been joined b
 
 | Parameter | Description |
 | --- | --- |
-| `elements` | iterable of [string](../core/string)s; required |
+| `elements` | iterable of [string](/versions/9.0.0/rules/lib/core/string)s; required |
 
 ## lower
 
@@ -264,7 +264,7 @@ Returns a copy of the string where leading characters that appear in `chars` are
 
 | Parameter | Description |
 | --- | --- |
-| `chars` | [string](../core/string); or `None`; default is `None`  The characters to remove, or all whitespace if None. |
+| `chars` | [string](/versions/9.0.0/rules/lib/core/string); or `None`; default is `None`  The characters to remove, or all whitespace if None. |
 
 ## partition
 
@@ -278,7 +278,7 @@ Splits the input string at the first occurrence of the separator `sep` and retur
 
 | Parameter | Description |
 | --- | --- |
-| `sep` | [string](../core/string); required  The string to split on. |
+| `sep` | [string](/versions/9.0.0/rules/lib/core/string); required  The string to split on. |
 
 ## removeprefix
 
@@ -292,7 +292,7 @@ If the string starts with `prefix`, returns a new string with the prefix removed
 
 | Parameter | Description |
 | --- | --- |
-| `prefix` | [string](../core/string); required  The prefix to remove if present. |
+| `prefix` | [string](/versions/9.0.0/rules/lib/core/string); required  The prefix to remove if present. |
 
 ## removesuffix
 
@@ -306,7 +306,7 @@ If the string ends with `suffix`, returns a new string with the suffix removed.
 
 | Parameter | Description |
 | --- | --- |
-| `suffix` | [string](../core/string); required  The suffix to remove if present. |
+| `suffix` | [string](/versions/9.0.0/rules/lib/core/string); required  The suffix to remove if present. |
 
 ## replace
 
@@ -320,9 +320,9 @@ Returns a copy of the string in which the occurrences of `old` have been replace
 
 | Parameter | Description |
 | --- | --- |
-| `old` | [string](../core/string); required  The string to be replaced. |
-| `new` | [string](../core/string); required  The string to replace with. |
-| `count` | [int](../core/int); default is `-1`  The maximum number of replacements. If omitted, or if the value is negative, there is no limit. |
+| `old` | [string](/versions/9.0.0/rules/lib/core/string); required  The string to be replaced. |
+| `new` | [string](/versions/9.0.0/rules/lib/core/string); required  The string to replace with. |
+| `count` | [int](/versions/9.0.0/rules/lib/core/int); default is `-1`  The maximum number of replacements. If omitted, or if the value is negative, there is no limit. |
 
 ## rfind
 
@@ -336,9 +336,9 @@ Returns the last index where `sub` is found, or -1 if no such index exists, opti
 
 | Parameter | Description |
 | --- | --- |
-| `sub` | [string](../core/string); required  The substring to find. |
-| `start` | [int](../core/int); or `None`; default is `0`  Restrict to search from this position. |
-| `end` | [int](../core/int); or `None`; default is `None`  optional position before which to restrict to search. |
+| `sub` | [string](/versions/9.0.0/rules/lib/core/string); required  The substring to find. |
+| `start` | [int](/versions/9.0.0/rules/lib/core/int); or `None`; default is `0`  Restrict to search from this position. |
+| `end` | [int](/versions/9.0.0/rules/lib/core/int); or `None`; default is `None`  optional position before which to restrict to search. |
 
 ## rindex
 
@@ -352,9 +352,9 @@ Returns the last index where `sub` is found, or raises an error if no such index
 
 | Parameter | Description |
 | --- | --- |
-| `sub` | [string](../core/string); required  The substring to find. |
-| `start` | [int](../core/int); or `None`; default is `0`  Restrict to search from this position. |
-| `end` | [int](../core/int); or `None`; default is `None`  optional position before which to restrict to search. |
+| `sub` | [string](/versions/9.0.0/rules/lib/core/string); required  The substring to find. |
+| `start` | [int](/versions/9.0.0/rules/lib/core/int); or `None`; default is `0`  Restrict to search from this position. |
+| `end` | [int](/versions/9.0.0/rules/lib/core/int); or `None`; default is `None`  optional position before which to restrict to search. |
 
 ## rpartition
 
@@ -368,7 +368,7 @@ Splits the input string at the last occurrence of the separator `sep` and return
 
 | Parameter | Description |
 | --- | --- |
-| `sep` | [string](../core/string); required  The string to split on. |
+| `sep` | [string](/versions/9.0.0/rules/lib/core/string); required  The string to split on. |
 
 ## rsplit
 
@@ -382,8 +382,8 @@ Returns a list of all the words in the string, using `sep` as the separator, opt
 
 | Parameter | Description |
 | --- | --- |
-| `sep` | [string](../core/string); required  The string to split on. |
-| `maxsplit` | [int](../core/int); default is `unbound`  The maximum number of splits. |
+| `sep` | [string](/versions/9.0.0/rules/lib/core/string); required  The string to split on. |
+| `maxsplit` | [int](/versions/9.0.0/rules/lib/core/int); default is `unbound`  The maximum number of splits. |
 
 ## rstrip
 
@@ -401,7 +401,7 @@ Returns a copy of the string where trailing characters that appear in `chars` ar
 
 | Parameter | Description |
 | --- | --- |
-| `chars` | [string](../core/string); or `None`; default is `None`  The characters to remove, or all whitespace if None. |
+| `chars` | [string](/versions/9.0.0/rules/lib/core/string); or `None`; default is `None`  The characters to remove, or all whitespace if None. |
 
 ## split
 
@@ -415,8 +415,8 @@ Returns a list of all the words in the string, using `sep` as the separator, opt
 
 | Parameter | Description |
 | --- | --- |
-| `sep` | [string](../core/string); required  The string to split on. |
-| `maxsplit` | [int](../core/int); default is `unbound`  The maximum number of splits. |
+| `sep` | [string](/versions/9.0.0/rules/lib/core/string); required  The string to split on. |
+| `maxsplit` | [int](/versions/9.0.0/rules/lib/core/int); default is `unbound`  The maximum number of splits. |
 
 ## splitlines
 
@@ -430,7 +430,7 @@ Splits the string at line boundaries ('\n', '\r\n', '\r') and returns the result
 
 | Parameter | Description |
 | --- | --- |
-| `keepends` | [bool](../core/bool); default is `False`  Whether the line breaks should be included in the resulting list. |
+| `keepends` | [bool](/versions/9.0.0/rules/lib/core/bool); default is `False`  Whether the line breaks should be included in the resulting list. |
 
 ## startswith
 
@@ -444,9 +444,9 @@ Returns True if the string starts with `sub`, otherwise False, optionally restri
 
 | Parameter | Description |
 | --- | --- |
-| `sub` | [string](../core/string); or [tuple](../core/tuple) of [string](../core/string)s; required  The prefix (or tuple of alternative prefixes) to match. |
-| `start` | [int](../core/int); or `None`; default is `0`  Test beginning at this position. |
-| `end` | [int](../core/int); or `None`; default is `None`  Stop comparing at this position. |
+| `sub` | [string](/versions/9.0.0/rules/lib/core/string); or [tuple](/versions/9.0.0/rules/lib/core/tuple) of [string](/versions/9.0.0/rules/lib/core/string)s; required  The prefix (or tuple of alternative prefixes) to match. |
+| `start` | [int](/versions/9.0.0/rules/lib/core/int); or `None`; default is `0`  Test beginning at this position. |
+| `end` | [int](/versions/9.0.0/rules/lib/core/int); or `None`; default is `None`  Stop comparing at this position. |
 
 ## strip
 
@@ -464,7 +464,7 @@ Returns a copy of the string where leading or trailing characters that appear in
 
 | Parameter | Description |
 | --- | --- |
-| `chars` | [string](../core/string); or `None`; default is `None`  The characters to remove, or all whitespace if None. |
+| `chars` | [string](/versions/9.0.0/rules/lib/core/string); or `None`; default is `None`  The characters to remove, or all whitespace if None. |
 
 ## title
 
diff --git a/versions/9.0.0/rules/lib/fragments.mdx b/versions/9.0.0/rules/lib/fragments.mdx
index ae9317b5..9ae2e529 100644
--- a/versions/9.0.0/rules/lib/fragments.mdx
+++ b/versions/9.0.0/rules/lib/fragments.mdx
@@ -2,7 +2,7 @@
 title: 'Configuration Fragments'
 ---
 
-Configuration fragments give rules access to language-specific parts of [configuration](builtins/configuration).
+Configuration fragments give rules access to language-specific parts of [configuration](/versions/9.0.0/rules/lib/builtins/configuration).
 
 Rule implementations can get them using `ctx.fragments.[fragment name]`
 
diff --git a/versions/9.0.0/rules/lib/fragments/coverage.mdx b/versions/9.0.0/rules/lib/fragments/coverage.mdx
index 0f053aa4..9b36f21c 100644
--- a/versions/9.0.0/rules/lib/fragments/coverage.mdx
+++ b/versions/9.0.0/rules/lib/fragments/coverage.mdx
@@ -14,7 +14,7 @@ A configuration fragment representing the coverage configuration.
 Label coverage.output_generator
 ```
 
-Returns the label pointed to by the [`--coverage_output_generator`](https://bazel.build/versions/9.0.0/reference/command-line-reference#flag--coverage_output_generator) option if coverage collection is enabled, otherwise returns `None`. Can be accessed with [`configuration_field`](../globals/bzl#configuration_field):
+Returns the label pointed to by the [`--coverage_output_generator`](https://bazel.build/versions/9.0.0/reference/command-line-reference#flag--coverage_output_generator) option if coverage collection is enabled, otherwise returns `None`. Can be accessed with [`configuration_field`](/versions/9.0.0/rules/lib/globals/bzl#configuration_field):
 
 ```
 attr.label(
diff --git a/versions/9.0.0/rules/lib/fragments/cpp.mdx b/versions/9.0.0/rules/lib/fragments/cpp.mdx
index 7fc3c93f..94f07309 100644
--- a/versions/9.0.0/rules/lib/fragments/cpp.mdx
+++ b/versions/9.0.0/rules/lib/fragments/cpp.mdx
@@ -46,7 +46,7 @@ The flags passed to Bazel by [`--copt`](/versions/9.0.0/docs/user-manual#flag--c
 Label cpp.custom_malloc
 ```
 
-Returns label pointed to by [`--custom_malloc`](/versions/9.0.0/docs/user-manual#flag--custom_malloc) option. Can be accessed with [`configuration_field`](../globals/bzl#configuration_field):
+Returns label pointed to by [`--custom_malloc`](/versions/9.0.0/docs/user-manual#flag--custom_malloc) option. Can be accessed with [`configuration_field`](/versions/9.0.0/rules/lib/globals/bzl#configuration_field):
 
 ```
 attr.label(
diff --git a/versions/9.0.0/rules/lib/globals/all.mdx b/versions/9.0.0/rules/lib/globals/all.mdx
index 6178179d..531ecdbf 100644
--- a/versions/9.0.0/rules/lib/globals/all.mdx
+++ b/versions/9.0.0/rules/lib/globals/all.mdx
@@ -50,7 +50,7 @@ abs(-2.3) == 2.3
 
 | Parameter | Description |
 | --- | --- |
-| `x` | [int](../core/int); or [float](../core/float); required  A number (int or float) |
+| `x` | [int](/versions/9.0.0/rules/lib/core/int); or [float](/versions/9.0.0/rules/lib/core/float); required  A number (int or float) |
 
 ## all
 
@@ -110,7 +110,7 @@ Constructor for the bool type. It returns `False` if the object is `None`, `Fals
 dict dict(pairs=[], **kwargs)
 ```
 
-Creates a [dictionary](../core/dict) from an optional positional argument and an optional set of keyword arguments. In the case where the same key is given multiple times, the last value will be used. Entries supplied via keyword arguments are considered to come after entries supplied via the positional argument.
+Creates a [dictionary](/versions/9.0.0/rules/lib/core/dict) from an optional positional argument and an optional set of keyword arguments. In the case where the same key is given multiple times, the last value will be used. Entries supplied via keyword arguments are considered to come after entries supplied via the positional argument.
 
 ### Parameters
 
@@ -150,7 +150,7 @@ enumerate([24, 21, 84]) == [(0, 24), (1, 21), (2, 84)]
 | Parameter | Description |
 | --- | --- |
 | `list` | required  input sequence. |
-| `start` | [int](../core/int); default is `0`  start index. |
+| `start` | [int](/versions/9.0.0/rules/lib/core/int); default is `0`  start index. |
 
 ## fail
 
@@ -165,8 +165,8 @@ Causes execution to fail with an error.
 | Parameter | Description |
 | --- | --- |
 | `msg` | default is `None`  Deprecated: use positional arguments instead. This argument acts like an implicit leading positional argument. |
-| `attr` | [string](../core/string); or `None`; default is `None`  Deprecated. Causes an optional prefix containing this string to be added to the error message. |
-| `sep` | [string](../core/string); default is `" "`  The separator string between the objects, default is space (" "). |
+| `attr` | [string](/versions/9.0.0/rules/lib/core/string); or `None`; default is `None`  Deprecated. Causes an optional prefix containing this string to be added to the error message. |
+| `sep` | [string](/versions/9.0.0/rules/lib/core/string); default is `" "`  The separator string between the objects, default is space (" "). |
 | `args` | required  A list of values, formatted with debugPrint (which is equivalent to str by default) and joined with sep (defaults to " "), that appear in the error message. |
 
 ## float
@@ -185,7 +185,7 @@ Any other value causes an error. With no argument, `float()` returns 0.0.
 
 | Parameter | Description |
 | --- | --- |
-| `x` | [string](../core/string); or [bool](../core/bool); or [int](../core/int); or [float](../core/float); default is `unbound`  The value to convert. |
+| `x` | [string](/versions/9.0.0/rules/lib/core/string); or [bool](/versions/9.0.0/rules/lib/core/bool); or [int](/versions/9.0.0/rules/lib/core/int); or [float](/versions/9.0.0/rules/lib/core/float); default is `unbound`  The value to convert. |
 
 ## getattr
 
@@ -205,7 +205,7 @@ getattr(ctx.attr, "myattr", "mydefault")
 | Parameter | Description |
 | --- | --- |
 | `x` | required  The struct whose attribute is accessed. |
-| `name` | [string](../core/string); required  The name of the struct attribute. |
+| `name` | [string](/versions/9.0.0/rules/lib/core/string); required  The name of the struct attribute. |
 | `default` | default is `unbound`  The default value to return in case the struct doesn't have an attribute of the given name. |
 
 ## hasattr
@@ -225,7 +225,7 @@ hasattr(ctx.attr, "myattr")
 | Parameter | Description |
 | --- | --- |
 | `x` | required |
-| `name` | [string](../core/string); required  The name of the attribute. |
+| `name` | [string](/versions/9.0.0/rules/lib/core/string); required  The name of the attribute. |
 
 ## hash
 
@@ -245,7 +245,7 @@ Hashing of values besides strings is not currently supported.
 
 | Parameter | Description |
 | --- | --- |
-| `value` | [string](../core/string); required  String value to hash. |
+| `value` | [string](/versions/9.0.0/rules/lib/core/string); required  String value to hash. |
 
 ## int
 
@@ -277,8 +277,8 @@ int("123.456") == 123
 
 | Parameter | Description |
 | --- | --- |
-| `x` | [string](../core/string); or [bool](../core/bool); or [int](../core/int); or [float](../core/float); required  The string to convert. |
-| `base` | [int](../core/int); default is `unbound`  The base used to interpret a string value; defaults to 10. Must be between 2 and 36 (inclusive), or 0 to detect the base as if `x` were an integer literal. This parameter must not be supplied if the value is not a string. |
+| `x` | [string](/versions/9.0.0/rules/lib/core/string); or [bool](/versions/9.0.0/rules/lib/core/bool); or [int](/versions/9.0.0/rules/lib/core/int); or [float](/versions/9.0.0/rules/lib/core/float); required  The string to convert. |
+| `base` | [int](/versions/9.0.0/rules/lib/core/int); default is `unbound`  The base used to interpret a string value; defaults to 10. Must be between 2 and 36 (inclusive), or 0 to detect the base as if `x` were an integer literal. This parameter must not be supplied if the value is not a string. |
 
 ## len
 
@@ -292,7 +292,7 @@ Returns the length of a string, sequence (such as a list or tuple), dict, set, o
 
 | Parameter | Description |
 | --- | --- |
-| `x` | iterable; or [string](../core/string); required  The value whose length to report. |
+| `x` | iterable; or [string](/versions/9.0.0/rules/lib/core/string); required  The value whose length to report. |
 
 ## list
 
@@ -372,7 +372,7 @@ Using `print` in production code is discouraged due to the spam it creates for u
 
 | Parameter | Description |
 | --- | --- |
-| `sep` | [string](../core/string); default is `" "`  The separator string between the objects, default is space (" "). |
+| `sep` | [string](/versions/9.0.0/rules/lib/core/string); default is `" "`  The separator string between the objects, default is space (" "). |
 | `args` | required  The objects to print. |
 
 ## range
@@ -393,9 +393,9 @@ range(3, 0, -1) == [3, 2, 1]
 
 | Parameter | Description |
 | --- | --- |
-| `start_or_stop` | [int](../core/int); required  Value of the start element if stop is provided, otherwise value of stop and the actual start is 0 |
-| `stop` | [int](../core/int); default is `unbound`  optional index of the first item *not* to be included in the resulting list; generation of the list stops before `stop` is reached. |
-| `step` | [int](../core/int); default is `1`  The increment (default is 1). It may be negative. |
+| `start_or_stop` | [int](/versions/9.0.0/rules/lib/core/int); required  Value of the start element if stop is provided, otherwise value of stop and the actual start is 0 |
+| `stop` | [int](/versions/9.0.0/rules/lib/core/int); default is `unbound`  optional index of the first item *not* to be included in the resulting list; generation of the list stops before `stop` is reached. |
+| `step` | [int](/versions/9.0.0/rules/lib/core/int); default is `1`  The increment (default is 1). It may be negative. |
 
 ## repr
 
@@ -439,7 +439,7 @@ reversed([3, 5, 4]) == [4, 5, 3]
 set set(elements=[])
 ```
 
-Creates a new [set](../core/set) containing the unique elements of a given
+Creates a new [set](/versions/9.0.0/rules/lib/core/set) containing the unique elements of a given
 iterable, preserving iteration order.
 
 If called with no argument, `set()` returns a new empty set.
@@ -479,7 +479,7 @@ sorted(["two", "three", "four"], key = len) == ["two", "four", "three"]  # sort
 | --- | --- |
 | `iterable` | iterable; required  The iterable sequence to sort. |
 | `key` | callable; or `None`; default is `None`  An optional function applied to each element before comparison. |
-| `reverse` | [bool](../core/bool); default is `False`  Return results in descending order. |
+| `reverse` | [bool](/versions/9.0.0/rules/lib/core/bool); default is `False`  Return results in descending order. |
 
 ## str
 
diff --git a/versions/9.0.0/rules/lib/globals/build.mdx b/versions/9.0.0/rules/lib/globals/build.mdx
index 13afdcc9..38054339 100644
--- a/versions/9.0.0/rules/lib/globals/build.mdx
+++ b/versions/9.0.0/rules/lib/globals/build.mdx
@@ -29,9 +29,9 @@ Methods available in BUILD files. See also the Build Encyclopedia for extra [fun
 depset depset(direct=None, order="default", *, transitive=None)
 ```
 
-Creates a [depset](../builtins/depset). The `direct` parameter is a list of direct elements of the depset, and `transitive` parameter is a list of depsets whose elements become indirect elements of the created depset. The order in which elements are returned when the depset is converted to a list is specified by the `order` parameter. See the [Depsets overview](https://bazel.build/versions/9.0.0/extending/depsets) for more information.
+Creates a [depset](/versions/9.0.0/rules/lib/builtins/depset). The `direct` parameter is a list of direct elements of the depset, and `transitive` parameter is a list of depsets whose elements become indirect elements of the created depset. The order in which elements are returned when the depset is converted to a list is specified by the `order` parameter. See the [Depsets overview](https://bazel.build/versions/9.0.0/extending/depsets) for more information.
 
-All elements (direct and indirect) of a depset must be of the same type, as obtained by the expression [`type(x)`](../globals/all#type).
+All elements (direct and indirect) of a depset must be of the same type, as obtained by the expression [`type(x)`](/versions/9.0.0/rules/lib/globals/all#type).
 
 Because a hash-based set is used to eliminate duplicates during iteration, all elements of a depset should be hashable. However, this invariant is not currently checked consistently in all constructors. Use the --incompatible\_always\_check\_depset\_elements flag to enable consistent checking; this will be the default behavior in future releases; see [Issue 10313](https://github.com/bazelbuild/bazel/issues/10313).
 
@@ -43,9 +43,9 @@ The order of the created depset should be *compatible* with the order of its `tr
 
 | Parameter | Description |
 | --- | --- |
-| `direct` | [sequence](../core/list); or `None`; default is `None`  A list of *direct* elements of a depset. |
-| `order` | [string](../core/string); default is `"default"`  The traversal strategy for the new depset. See [here](../builtins/depset) for the possible values. |
-| `transitive` | [sequence](../core/list) of [depset](../builtins/depset)s; or `None`; default is `None`  A list of depsets whose elements will become indirect elements of the depset. |
+| `direct` | [sequence](/versions/9.0.0/rules/lib/core/list); or `None`; default is `None`  A list of *direct* elements of a depset. |
+| `order` | [string](/versions/9.0.0/rules/lib/core/string); default is `"default"`  The traversal strategy for the new depset. See [here](/versions/9.0.0/rules/lib/builtins/depset) for the possible values. |
+| `transitive` | [sequence](/versions/9.0.0/rules/lib/core/list) of [depset](/versions/9.0.0/rules/lib/builtins/depset)s; or `None`; default is `None`  A list of depsets whose elements will become indirect elements of the depset. |
 
 ## existing\_rule
 
@@ -73,7 +73,7 @@ If possible, use this function only in [implementation functions of rule finaliz
 
 | Parameter | Description |
 | --- | --- |
-| `name` | [string](../core/string); required  The name of the target. |
+| `name` | [string](/versions/9.0.0/rules/lib/core/string); required  The name of the target. |
 
 ## existing\_rules
 
@@ -99,9 +99,9 @@ Specifies a list of files belonging to this package that are exported to other p
 
 | Parameter | Description |
 | --- | --- |
-| `srcs` | [sequence](../core/list) of [string](../core/string)s; required  The list of files to export. |
-| `visibility` | [sequence](../core/list); or `None`; default is `None`  A visibility declaration can to be specified. The files will be visible to the targets specified. If no visibility is specified, the files will be visible to every package. |
-| `licenses` | [sequence](../core/list) of [string](../core/string)s; or `None`; default is `None`  Licenses to be specified. |
+| `srcs` | [sequence](/versions/9.0.0/rules/lib/core/list) of [string](/versions/9.0.0/rules/lib/core/string)s; required  The list of files to export. |
+| `visibility` | [sequence](/versions/9.0.0/rules/lib/core/list); or `None`; default is `None`  A visibility declaration can to be specified. The files will be visible to the targets specified. If no visibility is specified, the files will be visible to every package. |
+| `licenses` | [sequence](/versions/9.0.0/rules/lib/core/list) of [string](/versions/9.0.0/rules/lib/core/string)s; or `None`; default is `None`  Licenses to be specified. |
 
 ## glob
 
@@ -120,9 +120,9 @@ If the `exclude_directories` argument is enabled (set to `1`), files of type dir
 
 | Parameter | Description |
 | --- | --- |
-| `include` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  The list of glob patterns to include. |
-| `exclude` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  The list of glob patterns to exclude. |
-| `exclude_directories` | [int](../core/int); default is `1`  A flag whether to exclude directories or not. |
+| `include` | [sequence](/versions/9.0.0/rules/lib/core/list) of [string](/versions/9.0.0/rules/lib/core/string)s; default is `[]`  The list of glob patterns to include. |
+| `exclude` | [sequence](/versions/9.0.0/rules/lib/core/list) of [string](/versions/9.0.0/rules/lib/core/string)s; default is `[]`  The list of glob patterns to exclude. |
+| `exclude_directories` | [int](/versions/9.0.0/rules/lib/core/int); default is `1`  A flag whether to exclude directories or not. |
 | `allow_empty` | default is `unbound`  Whether we allow glob patterns to match nothing. If `allow\_empty` is False, each individual include pattern must match something and also the final result must be non-empty (after the matches of the `exclude` patterns are excluded). |
 
 ## module\_name
@@ -177,9 +177,9 @@ This function defines a set of packages and assigns a label to the group. The la
 
 | Parameter | Description |
 | --- | --- |
-| `name` | [string](../core/string); required  The unique name for this rule. |
-| `packages` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  A complete enumeration of packages in this group. |
-| `includes` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  Other package groups that are included in this one. |
+| `name` | [string](/versions/9.0.0/rules/lib/core/string); required  The unique name for this rule. |
+| `packages` | [sequence](/versions/9.0.0/rules/lib/core/list) of [string](/versions/9.0.0/rules/lib/core/string)s; default is `[]`  A complete enumeration of packages in this group. |
+| `includes` | [sequence](/versions/9.0.0/rules/lib/core/list) of [string](/versions/9.0.0/rules/lib/core/string)s; default is `[]`  Other package groups that are included in this one. |
 
 ## package\_name
 
@@ -195,19 +195,19 @@ The name of the package being evaluated, without the repository name. For exampl
 Label package_relative_label(input)
 ```
 
-Converts the input string into a [Label](../builtins/Label) object, in the context of the package currently being initialized (that is, the `BUILD` file for which the current macro is executing). If the input is already a `Label`, it is returned unchanged.
+Converts the input string into a [Label](/versions/9.0.0/rules/lib/builtins/Label) object, in the context of the package currently being initialized (that is, the `BUILD` file for which the current macro is executing). If the input is already a `Label`, it is returned unchanged.
 
 This function may only be called while evaluating a BUILD file and the macros it directly or indirectly calls; it may not be called in (for instance) a rule implementation function.
 
 The result of this function is the same `Label` value as would be produced by passing the given string to a label-valued attribute of a target declared in the BUILD file.
 
-*Usage note:* The difference between this function and [Label()](../builtins/Label#Label) is that `Label()` uses the context of the package of the `.bzl` file that called it, not the package of the `BUILD` file. Use `Label()` when you need to refer to a fixed target that is hardcoded into the macro, such as a compiler. Use `package_relative_label()` when you need to normalize a label string supplied by the BUILD file to a `Label` object. (There is no way to convert a string to a `Label` in the context of a package other than the BUILD file or the calling .bzl file. For that reason, outer macros should always prefer to pass Label objects to inner macros rather than label strings.)[`ctx.package_relative_label()`](ctx#package_relative_label) provides the same functionality within a rule or aspect implementation function.
+*Usage note:* The difference between this function and [Label()](/versions/9.0.0/rules/lib/builtins/Label#Label) is that `Label()` uses the context of the package of the `.bzl` file that called it, not the package of the `BUILD` file. Use `Label()` when you need to refer to a fixed target that is hardcoded into the macro, such as a compiler. Use `package_relative_label()` when you need to normalize a label string supplied by the BUILD file to a `Label` object. (There is no way to convert a string to a `Label` in the context of a package other than the BUILD file or the calling .bzl file. For that reason, outer macros should always prefer to pass Label objects to inner macros rather than label strings.)[`ctx.package_relative_label()`](/versions/9.0.0/rules/lib/globals/ctx#package_relative_label) provides the same functionality within a rule or aspect implementation function.
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `input` | [string](../core/string); or [Label](../builtins/Label); required  The input label string or Label object. If a Label object is passed, it's returned as is. |
+| `input` | [string](/versions/9.0.0/rules/lib/core/string); or [Label](/versions/9.0.0/rules/lib/builtins/Label); required  The input label string or Label object. If a Label object is passed, it's returned as is. |
 
 ## repo\_name
 
@@ -240,8 +240,8 @@ unknown select(x, no_match_error='')
 
 | Parameter | Description |
 | --- | --- |
-| `x` | [dict](../core/dict); required |
-| `no_match_error` | [string](../core/string); default is `''`  Optional custom error to report if no condition matches. |
+| `x` | [dict](/versions/9.0.0/rules/lib/core/dict); required |
+| `no_match_error` | [string](/versions/9.0.0/rules/lib/core/string); default is `''`  Optional custom error to report if no condition matches. |
 
 ## subpackages
 
@@ -255,6 +255,6 @@ Returns a new mutable list of every direct subpackage of the current package, re
 
 | Parameter | Description |
 | --- | --- |
-| `include` | [sequence](../core/list) of [string](../core/string)s; required  The list of glob patterns to include in subpackages scan. |
-| `exclude` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  The list of glob patterns to exclude from subpackages scan. |
-| `allow_empty` | [bool](../core/bool); default is `False`  Whether we fail if the call returns an empty list. By default empty list indicates potential error in BUILD file where the call to subpackages() is superflous. Setting to true allows this function to succeed in that case. |
\ No newline at end of file
+| `include` | [sequence](/versions/9.0.0/rules/lib/core/list) of [string](/versions/9.0.0/rules/lib/core/string)s; required  The list of glob patterns to include in subpackages scan. |
+| `exclude` | [sequence](/versions/9.0.0/rules/lib/core/list) of [string](/versions/9.0.0/rules/lib/core/string)s; default is `[]`  The list of glob patterns to exclude from subpackages scan. |
+| `allow_empty` | [bool](/versions/9.0.0/rules/lib/core/bool); default is `False`  Whether we fail if the call returns an empty list. By default empty list indicates potential error in BUILD file where the call to subpackages() is superflous. Setting to true allows this function to succeed in that case. |
\ No newline at end of file
diff --git a/versions/9.0.0/rules/lib/globals/bzl.mdx b/versions/9.0.0/rules/lib/globals/bzl.mdx
index 88b75aa6..854e8a4e 100644
--- a/versions/9.0.0/rules/lib/globals/bzl.mdx
+++ b/versions/9.0.0/rules/lib/globals/bzl.mdx
@@ -29,7 +29,7 @@ Global methods available in all .bzl files.
 transition analysis_test_transition(*, settings)
 ```
 
-Creates a configuration transition to be applied on an analysis-test rule's dependencies. This transition may only be applied on attributes of rules with `analysis_test = True`. Such rules are restricted in capabilities (for example, the size of their dependency tree is limited), so transitions created using this function are limited in potential scope as compared to transitions created using [`transition()`](../builtins/transition).
+Creates a configuration transition to be applied on an analysis-test rule's dependencies. This transition may only be applied on attributes of rules with `analysis_test = True`. Such rules are restricted in capabilities (for example, the size of their dependency tree is limited), so transitions created using this function are limited in potential scope as compared to transitions created using [`transition()`](/versions/9.0.0/rules/lib/builtins/transition).
 
 This function is primarily designed to facilitate the [Analysis Test Framework](https://bazel.build/versions/9.0.0/rules/testing) core library. See its documentation (or its implementation) for best practices.
 
@@ -37,7 +37,7 @@ This function is primarily designed to facilitate the [Analysis Test Framework](
 
 | Parameter | Description |
 | --- | --- |
-| `settings` | [dict](../core/dict); required  A dictionary containing information about configuration settings which should be set by this configuration transition. Keys are build setting labels and values are their new post-transition values. All other settings are unchanged. Use this to declare specific configuration settings that an analysis test requires to be set in order to pass. |
+| `settings` | [dict](/versions/9.0.0/rules/lib/core/dict); required  A dictionary containing information about configuration settings which should be set by this configuration transition. Keys are build setting labels and values are their new post-transition values. All other settings are unchanged. Use this to declare specific configuration settings that an analysis test requires to be set in order to pass. |
 
 ## aspect
 
@@ -51,23 +51,23 @@ Creates a new aspect. The result of this function must be stored in a global val
 
 | Parameter | Description |
 | --- | --- |
-| `implementation` | [function](../core/function); required  A Starlark function that implements this aspect, with exactly two parameters: [Target](../builtins/Target) (the target to which the aspect is applied) and [ctx](../builtins/ctx) (the rule context which the target is created from). Attributes of the target are available via the `ctx.rule` field. This function is evaluated during the analysis phase for each application of an aspect to a target. |
-| `attr_aspects` | [sequence](../core/list) of [string](../core/string)s; or [function](../core/function); default is `[]`  Accepts a list of attribute names or [Experimental] a function that returns the list of attribute names. The aspect propagates along dependencies specified in the attributes of a target with these names. Common values here include `deps` and `exports`. The list can also contain a single string `"*"` to propagate along all dependencies of a target. |
-| `toolchains_aspects` | [sequence](../core/list); or [function](../core/function); default is `[]`  Accepts a list of toolchain types or [Experimental] a function that returns the list of toolchain types. The aspect propagates to target toolchains which match these toolchain types. |
-| `attrs` | [dict](../core/dict); default is `{}`  A dictionary declaring all the attributes of the aspect. It maps from an attribute name to an attribute object, like `attr.label` or `attr.string` (see [`attr`](../toplevel/attr) module). Aspect attributes are available to implementation function as fields of `ctx` parameter. Implicit attributes starting with `_` must have default values, and have type `label` or `label_list`.  Explicit attributes must have type `string`, and must use the `values` restriction. Explicit attributes restrict the aspect to only be used with rules that have attributes of the same name, type, and valid values according to the restriction.  Declared attributes will convert `None` to the default value. |
-| `required_providers` | [sequence](../core/list); default is `[]`  This attribute allows the aspect to limit its propagation to only the targets whose rules advertise its required providers. The value must be a list containing either individual providers or lists of providers but not both. For example, `[[FooInfo], [BarInfo], [BazInfo, QuxInfo]]` is a valid value while `[FooInfo, BarInfo, [BazInfo, QuxInfo]]` is not valid. An unnested list of providers will automatically be converted to a list containing one list of providers. That is, `[FooInfo, BarInfo]` will automatically be converted to `[[FooInfo, BarInfo]]`. To make some rule (e.g. `some_rule`) targets visible to an aspect, `some_rule` must advertise all providers from at least one of the required providers lists. For example, if the `required_providers` of an aspect are `[[FooInfo], [BarInfo], [BazInfo, QuxInfo]]`, this aspect can see `some_rule` targets if and only if `some_rule` provides `FooInfo`, *or* `BarInfo`, *or* both `BazInfo` *and* `QuxInfo`. |
-| `required_aspect_providers` | [sequence](../core/list); default is `[]`  This attribute allows this aspect to inspect other aspects. The value must be a list containing either individual providers or lists of providers but not both. For example, `[[FooInfo], [BarInfo], [BazInfo, QuxInfo]]` is a valid value while `[FooInfo, BarInfo, [BazInfo, QuxInfo]]` is not valid. An unnested list of providers will automatically be converted to a list containing one list of providers. That is, `[FooInfo, BarInfo]` will automatically be converted to `[[FooInfo, BarInfo]]`. To make another aspect (e.g. `other_aspect`) visible to this aspect, `other_aspect` must provide all providers from at least one of the lists. In the example of `[[FooInfo], [BarInfo], [BazInfo, QuxInfo]]`, this aspect can see `other_aspect` if and only if `other_aspect` provides `FooInfo`, *or* `BarInfo`, *or* both `BazInfo` *and* `QuxInfo`. |
-| `provides` | [sequence](../core/list); default is `[]`  A list of providers that the implementation function must return. It is an error if the implementation function omits any of the types of providers listed here from its return value. However, the implementation function may return additional providers not listed here. Each element of the list is an `*Info` object returned by [`provider()`](../globals/bzl#provider). When a target of the rule is used as a dependency for a target that declares a required provider, it is not necessary to specify that provider here. It is enough that the implementation function returns it. However, it is considered best practice to specify it, even though this is not required. The [`required_providers`](../globals/bzl#aspect.required_providers) field of an [aspect](../globals/bzl#aspect) does, however, require that providers are specified here. |
-| `requires` | [sequence](../core/list) of [Aspect](../builtins/Aspect)s; default is `[]`  List of aspects required to be propagated before this aspect. |
-| `propagation_predicate` | [function](../core/function); or `None`; default is `None`  Experimental: a function that returns a boolean value indicating whether the aspect should be propagated to a target. |
-| `fragments` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  List of names of configuration fragments that the aspect requires in target configuration. |
-| `host_fragments` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  List of names of configuration fragments that the aspect requires in host configuration. |
-| `toolchains` | [sequence](../core/list); default is `[]`  If set, the set of toolchains this aspect requires. The list can contain String, Label, or StarlarkToolchainTypeApi objects, in any combination. Toolchains will be found by checking the current platform, and provided to the aspect implementation via `ctx.toolchain`. |
-| `doc` | [string](../core/string); or `None`; default is `None`  A description of the aspect that can be extracted by documentation generating tools. |
-| `apply_to_generating_rules` | [bool](../core/bool); default is `False`  If true, the aspect will, when applied to an output file, instead apply to the output file's generating rule. For example, suppose an aspect propagates transitively through attribute `deps` and it is applied to target `alpha`. Suppose `alpha` has `deps = [':beta\_output']`, where `beta\_output` is a declared output of a target `beta`. Suppose `beta` has a target `charlie` as one of its `deps`. If `apply\_to\_generating\_rules=True` for the aspect, then the aspect will propagate through `alpha`, `beta`, and `charlie`. If False, then the aspect will propagate only to `alpha`.  False by default. |
-| `exec_compatible_with` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  A list of constraints on the execution platform that apply to all instances of this aspect. |
-| `exec_groups` | [dict](../core/dict); or `None`; default is `None`  Dict of execution group name (string) to [`exec_group`s](../globals/bzl#exec_group). If set, allows aspects to run actions on multiple execution platforms within a single instance. See [execution groups documentation](/versions/9.0.0/reference/exec-groups) for more info. |
-| `subrules` | [sequence](../core/list) of [Subrule](../builtins/Subrule)s; default is `[]`  Experimental: list of subrules used by this aspect. |
+| `implementation` | [function](/versions/9.0.0/rules/lib/core/function); required  A Starlark function that implements this aspect, with exactly two parameters: [Target](/versions/9.0.0/rules/lib/builtins/Target) (the target to which the aspect is applied) and [ctx](/versions/9.0.0/rules/lib/builtins/ctx) (the rule context which the target is created from). Attributes of the target are available via the `ctx.rule` field. This function is evaluated during the analysis phase for each application of an aspect to a target. |
+| `attr_aspects` | [sequence](/versions/9.0.0/rules/lib/core/list) of [string](/versions/9.0.0/rules/lib/core/string)s; or [function](/versions/9.0.0/rules/lib/core/function); default is `[]`  Accepts a list of attribute names or [Experimental] a function that returns the list of attribute names. The aspect propagates along dependencies specified in the attributes of a target with these names. Common values here include `deps` and `exports`. The list can also contain a single string `"*"` to propagate along all dependencies of a target. |
+| `toolchains_aspects` | [sequence](/versions/9.0.0/rules/lib/core/list); or [function](/versions/9.0.0/rules/lib/core/function); default is `[]`  Accepts a list of toolchain types or [Experimental] a function that returns the list of toolchain types. The aspect propagates to target toolchains which match these toolchain types. |
+| `attrs` | [dict](/versions/9.0.0/rules/lib/core/dict); default is `{}`  A dictionary declaring all the attributes of the aspect. It maps from an attribute name to an attribute object, like `attr.label` or `attr.string` (see [`attr`](/versions/9.0.0/rules/lib/toplevel/attr) module). Aspect attributes are available to implementation function as fields of `ctx` parameter. Implicit attributes starting with `_` must have default values, and have type `label` or `label_list`.  Explicit attributes must have type `string`, and must use the `values` restriction. Explicit attributes restrict the aspect to only be used with rules that have attributes of the same name, type, and valid values according to the restriction.  Declared attributes will convert `None` to the default value. |
+| `required_providers` | [sequence](/versions/9.0.0/rules/lib/core/list); default is `[]`  This attribute allows the aspect to limit its propagation to only the targets whose rules advertise its required providers. The value must be a list containing either individual providers or lists of providers but not both. For example, `[[FooInfo], [BarInfo], [BazInfo, QuxInfo]]` is a valid value while `[FooInfo, BarInfo, [BazInfo, QuxInfo]]` is not valid. An unnested list of providers will automatically be converted to a list containing one list of providers. That is, `[FooInfo, BarInfo]` will automatically be converted to `[[FooInfo, BarInfo]]`. To make some rule (e.g. `some_rule`) targets visible to an aspect, `some_rule` must advertise all providers from at least one of the required providers lists. For example, if the `required_providers` of an aspect are `[[FooInfo], [BarInfo], [BazInfo, QuxInfo]]`, this aspect can see `some_rule` targets if and only if `some_rule` provides `FooInfo`, *or* `BarInfo`, *or* both `BazInfo` *and* `QuxInfo`. |
+| `required_aspect_providers` | [sequence](/versions/9.0.0/rules/lib/core/list); default is `[]`  This attribute allows this aspect to inspect other aspects. The value must be a list containing either individual providers or lists of providers but not both. For example, `[[FooInfo], [BarInfo], [BazInfo, QuxInfo]]` is a valid value while `[FooInfo, BarInfo, [BazInfo, QuxInfo]]` is not valid. An unnested list of providers will automatically be converted to a list containing one list of providers. That is, `[FooInfo, BarInfo]` will automatically be converted to `[[FooInfo, BarInfo]]`. To make another aspect (e.g. `other_aspect`) visible to this aspect, `other_aspect` must provide all providers from at least one of the lists. In the example of `[[FooInfo], [BarInfo], [BazInfo, QuxInfo]]`, this aspect can see `other_aspect` if and only if `other_aspect` provides `FooInfo`, *or* `BarInfo`, *or* both `BazInfo` *and* `QuxInfo`. |
+| `provides` | [sequence](/versions/9.0.0/rules/lib/core/list); default is `[]`  A list of providers that the implementation function must return. It is an error if the implementation function omits any of the types of providers listed here from its return value. However, the implementation function may return additional providers not listed here. Each element of the list is an `*Info` object returned by [`provider()`](/versions/9.0.0/rules/lib/globals/bzl#provider). When a target of the rule is used as a dependency for a target that declares a required provider, it is not necessary to specify that provider here. It is enough that the implementation function returns it. However, it is considered best practice to specify it, even though this is not required. The [`required_providers`](/versions/9.0.0/rules/lib/globals/bzl#aspect.required_providers) field of an [aspect](/versions/9.0.0/rules/lib/globals/bzl#aspect) does, however, require that providers are specified here. |
+| `requires` | [sequence](/versions/9.0.0/rules/lib/core/list) of [Aspect](/versions/9.0.0/rules/lib/builtins/Aspect)s; default is `[]`  List of aspects required to be propagated before this aspect. |
+| `propagation_predicate` | [function](/versions/9.0.0/rules/lib/core/function); or `None`; default is `None`  Experimental: a function that returns a boolean value indicating whether the aspect should be propagated to a target. |
+| `fragments` | [sequence](/versions/9.0.0/rules/lib/core/list) of [string](/versions/9.0.0/rules/lib/core/string)s; default is `[]`  List of names of configuration fragments that the aspect requires in target configuration. |
+| `host_fragments` | [sequence](/versions/9.0.0/rules/lib/core/list) of [string](/versions/9.0.0/rules/lib/core/string)s; default is `[]`  List of names of configuration fragments that the aspect requires in host configuration. |
+| `toolchains` | [sequence](/versions/9.0.0/rules/lib/core/list); default is `[]`  If set, the set of toolchains this aspect requires. The list can contain String, Label, or StarlarkToolchainTypeApi objects, in any combination. Toolchains will be found by checking the current platform, and provided to the aspect implementation via `ctx.toolchain`. |
+| `doc` | [string](/versions/9.0.0/rules/lib/core/string); or `None`; default is `None`  A description of the aspect that can be extracted by documentation generating tools. |
+| `apply_to_generating_rules` | [bool](/versions/9.0.0/rules/lib/core/bool); default is `False`  If true, the aspect will, when applied to an output file, instead apply to the output file's generating rule. For example, suppose an aspect propagates transitively through attribute `deps` and it is applied to target `alpha`. Suppose `alpha` has `deps = [':beta\_output']`, where `beta\_output` is a declared output of a target `beta`. Suppose `beta` has a target `charlie` as one of its `deps`. If `apply\_to\_generating\_rules=True` for the aspect, then the aspect will propagate through `alpha`, `beta`, and `charlie`. If False, then the aspect will propagate only to `alpha`.  False by default. |
+| `exec_compatible_with` | [sequence](/versions/9.0.0/rules/lib/core/list) of [string](/versions/9.0.0/rules/lib/core/string)s; default is `[]`  A list of constraints on the execution platform that apply to all instances of this aspect. |
+| `exec_groups` | [dict](/versions/9.0.0/rules/lib/core/dict); or `None`; default is `None`  Dict of execution group name (string) to [`exec_group`s](/versions/9.0.0/rules/lib/globals/bzl#exec_group). If set, allows aspects to run actions on multiple execution platforms within a single instance. See [execution groups documentation](/versions/9.0.0/reference/exec-groups) for more info. |
+| `subrules` | [sequence](/versions/9.0.0/rules/lib/core/list) of [Subrule](/versions/9.0.0/rules/lib/builtins/Subrule)s; default is `[]`  Experimental: list of subrules used by this aspect. |
 
 ## configuration\_field
 
@@ -75,7 +75,7 @@ Creates a new aspect. The result of this function must be stored in a global val
 LateBoundDefault configuration_field(fragment, name)
 ```
 
-References a late-bound default value for an attribute of type [label](../toplevel/attr#label). A value is 'late-bound' if it requires the configuration to be built before determining the value. Any attribute using this as a value must [be private](https://bazel.build/versions/9.0.0/extending/rules#private-attributes).
+References a late-bound default value for an attribute of type [label](/versions/9.0.0/rules/lib/toplevel/attr#label). A value is 'late-bound' if it requires the configuration to be built before determining the value. Any attribute using this as a value must [be private](https://bazel.build/versions/9.0.0/extending/rules#private-attributes).
 
 Example usage:
 
@@ -97,8 +97,8 @@ Accessing in rule implementation:
 
 | Parameter | Description |
 | --- | --- |
-| `fragment` | [string](../core/string); required |
-| `name` | [string](../core/string); required |
+| `fragment` | [string](/versions/9.0.0/rules/lib/core/string); required |
+| `name` | [string](/versions/9.0.0/rules/lib/core/string); required |
 
 ## depset
 
@@ -106,9 +106,9 @@ Accessing in rule implementation:
 depset depset(direct=None, order="default", *, transitive=None)
 ```
 
-Creates a [depset](../builtins/depset). The `direct` parameter is a list of direct elements of the depset, and `transitive` parameter is a list of depsets whose elements become indirect elements of the created depset. The order in which elements are returned when the depset is converted to a list is specified by the `order` parameter. See the [Depsets overview](https://bazel.build/versions/9.0.0/extending/depsets) for more information.
+Creates a [depset](/versions/9.0.0/rules/lib/builtins/depset). The `direct` parameter is a list of direct elements of the depset, and `transitive` parameter is a list of depsets whose elements become indirect elements of the created depset. The order in which elements are returned when the depset is converted to a list is specified by the `order` parameter. See the [Depsets overview](https://bazel.build/versions/9.0.0/extending/depsets) for more information.
 
-All elements (direct and indirect) of a depset must be of the same type, as obtained by the expression [`type(x)`](../globals/all#type).
+All elements (direct and indirect) of a depset must be of the same type, as obtained by the expression [`type(x)`](/versions/9.0.0/rules/lib/globals/all#type).
 
 Because a hash-based set is used to eliminate duplicates during iteration, all elements of a depset should be hashable. However, this invariant is not currently checked consistently in all constructors. Use the --incompatible\_always\_check\_depset\_elements flag to enable consistent checking; this will be the default behavior in future releases; see [Issue 10313](https://github.com/bazelbuild/bazel/issues/10313).
 
@@ -120,9 +120,9 @@ The order of the created depset should be *compatible* with the order of its `tr
 
 | Parameter | Description |
 | --- | --- |
-| `direct` | [sequence](../core/list); or `None`; default is `None`  A list of *direct* elements of a depset. |
-| `order` | [string](../core/string); default is `"default"`  The traversal strategy for the new depset. See [here](../builtins/depset) for the possible values. |
-| `transitive` | [sequence](../core/list) of [depset](../builtins/depset)s; or `None`; default is `None`  A list of depsets whose elements will become indirect elements of the depset. |
+| `direct` | [sequence](/versions/9.0.0/rules/lib/core/list); or `None`; default is `None`  A list of *direct* elements of a depset. |
+| `order` | [string](/versions/9.0.0/rules/lib/core/string); default is `"default"`  The traversal strategy for the new depset. See [here](/versions/9.0.0/rules/lib/builtins/depset) for the possible values. |
+| `transitive` | [sequence](/versions/9.0.0/rules/lib/core/list) of [depset](/versions/9.0.0/rules/lib/builtins/depset)s; or `None`; default is `None`  A list of depsets whose elements will become indirect elements of the depset. |
 
 ## exec\_group
 
@@ -136,8 +136,8 @@ Creates an [execution group](/versions/9.0.0/reference/exec-groups) which can be
 
 | Parameter | Description |
 | --- | --- |
-| `toolchains` | [sequence](../core/list); default is `[]`  The set of toolchains this execution group requires. The list can contain String, Label, or StarlarkToolchainTypeApi objects, in any combination. |
-| `exec_compatible_with` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  A list of constraints on the execution platform. |
+| `toolchains` | [sequence](/versions/9.0.0/rules/lib/core/list); default is `[]`  The set of toolchains this execution group requires. The list can contain String, Label, or StarlarkToolchainTypeApi objects, in any combination. |
+| `exec_compatible_with` | [sequence](/versions/9.0.0/rules/lib/core/list) of [string](/versions/9.0.0/rules/lib/core/string)s; default is `[]`  A list of constraints on the execution platform. |
 
 ## exec\_transition
 
@@ -145,15 +145,15 @@ Creates an [execution group](/versions/9.0.0/reference/exec-groups) which can be
 transition exec_transition(*, implementation, inputs, outputs)
 ```
 
-A specialized version of [`transition()`](../builtins/transition) used to define the exec transition. See its documentation (or its implementation) for best practices. Only usable from the Bazel builtins.
+A specialized version of [`transition()`](/versions/9.0.0/rules/lib/builtins/transition) used to define the exec transition. See its documentation (or its implementation) for best practices. Only usable from the Bazel builtins.
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
 | `implementation` | callable; required |
-| `inputs` | [sequence](../core/list) of [string](../core/string)s; required |
-| `outputs` | [sequence](../core/list) of [string](../core/string)s; required |
+| `inputs` | [sequence](/versions/9.0.0/rules/lib/core/list) of [string](/versions/9.0.0/rules/lib/core/string)s; required |
+| `outputs` | [sequence](/versions/9.0.0/rules/lib/core/list) of [string](/versions/9.0.0/rules/lib/core/string)s; required |
 
 ## macro
 
@@ -174,11 +174,11 @@ macros.
 
 | Parameter | Description |
 | --- | --- |
-| `implementation` | [function](../core/function); required  The Starlark function implementing this macro. The values of the macro's attributes are passed to the implementation function as keyword arguments. The implementation function must have at least two named parameters, `name` and `visibility`, and if the macro inherits attributes (see `inherit_attrs` below), it must have a `**kwargs` residual keyword parameter. By convention, the implementation function should have a named parameter for any attribute that the macro needs to examine, modify, or pass to non-"main" targets, while the "bulk" inherited attributes which will be passed to the "main" target unchanged are passed as `**kwargs`. The implementation function must not return a value. Instead, the implementation function *declares targets* by calling rule or macro symbols. The name of any target or inner symbolic macro declared by a symbolic macro (including by any Starlark function that the macro's implementation function transitively calls) must either equal `name` (this is referred to as the "main" target) or start with `name`, followed by a separator chracter (`"_"`, `"-"`, or `"."`) and a string suffix. (Targets violating this naming scheme are allowed to be declared, but cannot be built, configured, or depended upon.) By default, targets declared by a symbolic macro (including by any Starlark function that the macro's implementation function transitively calls) are visible only in the package containing the .bzl file defining the macro. To declare targets visible externally, *including to the caller of the symbolic macro*, the implementation function must set `visibility` appropriately – typically, by passing `visibility = visibility` to the rule or macro symbol being called. The following APIs are unavailable within a macro implementation function and any Starlark function it transitively calls:  * [`package()`, `licenses()`* `environment_group()`* [`native.glob()`](../toplevel/native#glob) – instead, you may pass       a glob into the macro via a label list attribute* [`native.subpackages()`](../toplevel/native#subpackages)* (allowed in rule finalizers only, see `finalizer` below)           [`native.existing_rules()`](../toplevel/native#existing_rules),           [`native.existing_rule()`](../toplevel/native#existing_rule)* (for `WORKSPACE` threads)             [`workspace()`](../globals/module#workspace), [`register_toolchains()`](../globals/module#register_toolchains), [`bind()`](../globals/module#bind), [`register_execution_platforms()`](../globals/module#register_execution_platforms), repository rule instantiation](/versions/9.0.0/reference/be/functions#package) |
-| `attrs` | [dict](../core/dict); default is `{}`  A dictionary of the attributes this macro supports, analogous to [rule.attrs](#rule.attrs). Keys are attribute names, and values are either attribute objects like `attr.label_list(...)` (see the [attr](../toplevel/attr) module), or `None`. A `None` entry means that the macro does not have an attribute by that name, even if it would have otherwise inherited one via `inherit_attrs` (see below). The special `name` attribute is predeclared and must not be included in the dictionary. The `visibility` attribute name is reserved and must not be included in the dictionary. Attributes whose names start with `_` are private -- they cannot be passed at the call site of the rule. Such attributes can be assigned a default value (as in `attr.label(default="//pkg:foo")`) to create an implicit dependency on a label. To limit memory usage, there is a cap on the number of attributes that may be declared. |
-| `inherit_attrs` | [rule](../builtins/rule); or [macro](../builtins/macro); or [string](../core/string); or `None`; default is `None`  A rule symbol, macro symbol, or the name of a built-in common attribute list (see below) from which the macro should inherit attributes. If `inherit_attrs` is set to the string `"common"`, the macro will inherit [common rule attribute definitions](/versions/9.0.0/reference/be/common-definitions#common-attributes) used by all Starlark rules. Note that if the return value of `rule()` or `macro()` was not assigned to a global variable in a .bzl file, then such a value has not been registered as a rule or macro symbol, and therefore cannot be used for `inherit_attrs`. The inheritance mechanism works as follows:   1. The special `name` and `visibility` attributes are never inherited;- Hidden attributes (ones whose name starts with `"_"`) are never inherited;- Attributes whose names are already defined in the `attrs` dictionary are never        inherited (the entry in `attrs` takes precedence; note that an entry may be set to        `None` to ensure that no attribute by that name gets defined on the macro);- All other attributes are inherited from the rule or macro and effectively merged into the          `attrs` dict.   When a non-mandatory attribute is inherited, the default value of the attribute is overridden to be `None`, regardless of what it was specified in the original rule or macro. This ensures that when the macro forwards the attribute's value to an instance of the wrapped rule or macro – such as by passing in the unmodified `**kwargs` – a value that was absent from the outer macro's call will also be absent in the inner rule or macro's call (since passing `None` to an attribute is treated the same as omitting the attribute). This is important because omitting an attribute has subtly different semantics from passing its apparent default value. In particular, omitted attributes are not shown in some `bazel query` output formats, and computed defaults only execute when the value is omitted. If the macro needs to examine or modify an inherited attribute – for example, to add a value to an inherited `tags` attribute – you must make sure to handle the `None` case in the macro's implementation function. For example, the following macro inherits all attributes from `native.cc_library`, except for `cxxopts` (which is removed from the attribute list) and `copts` (which is given a new definition). It also takes care to checks for the default `None` value of the inherited `tags` attribute before appending an additional tag.  ``` def _my_cc_library_impl(name, visibility, tags, **kwargs):     # Append a tag; tags attr was inherited from native.cc_library, and     # therefore is None unless explicitly set by the caller of my_cc_library()     my_tags = (tags or []) + ["my_custom_tag"]     native.cc_library(         name = name,         visibility = visibility,         tags = my_tags,         **kwargs     )  my_cc_library = macro(     implementation = _my_cc_library_impl,     inherit_attrs = native.cc_library,     attrs = {         "cxxopts": None,         "copts": attr.string_list(default = ["-D_FOO"]),     }, ) ```   If `inherit_attrs` is set, the macro's implementation function *must* have a `**kwargs` residual keyword parameter. By convention, a macro should pass inherited, non-overridden attributes unchanged to the "main" rule or macro symbol which the macro is wrapping. Typically, most inherited attributes will not have a parameter in the implementation function's parameter list, and will simply be passed via `**kwargs`. It can be convenient for the implementation function to have explicit parameters for some inherited attributes (most commonly, `tags` and `testonly`) if the macro needs to pass those attributes to both "main" and non-"main" targets – but if the macro also needs to examine or manipulate those attributes, you must take care to handle the `None` default value of non-mandatory inherited attributes. |
-| `finalizer` | [bool](../core/bool); default is `False`  Whether this macro is a rule finalizer, which is a macro that, regardless of its position in a `BUILD` file, is evaluated at the end of package loading, after all non-finalizer targets have been defined. Unlike ordinary symbolic macros, rule finalizers may call [`native.existing_rule()`](../toplevel/native#existing_rule) and [`native.existing_rules()`](../toplevel/native#existing_rules) to query the set of *non-finalizer* rule targets defined in the current package. Note that `native.existing_rule()` and `native.existing_rules()` cannot access the targets defined by any rule finalizer, including this one. |
-| `doc` | [string](../core/string); or `None`; default is `None`  A description of the macro that can be extracted by documentation generating tools. |
+| `implementation` | [function](/versions/9.0.0/rules/lib/core/function); required  The Starlark function implementing this macro. The values of the macro's attributes are passed to the implementation function as keyword arguments. The implementation function must have at least two named parameters, `name` and `visibility`, and if the macro inherits attributes (see `inherit_attrs` below), it must have a `**kwargs` residual keyword parameter. By convention, the implementation function should have a named parameter for any attribute that the macro needs to examine, modify, or pass to non-"main" targets, while the "bulk" inherited attributes which will be passed to the "main" target unchanged are passed as `**kwargs`. The implementation function must not return a value. Instead, the implementation function *declares targets* by calling rule or macro symbols. The name of any target or inner symbolic macro declared by a symbolic macro (including by any Starlark function that the macro's implementation function transitively calls) must either equal `name` (this is referred to as the "main" target) or start with `name`, followed by a separator chracter (`"_"`, `"-"`, or `"."`) and a string suffix. (Targets violating this naming scheme are allowed to be declared, but cannot be built, configured, or depended upon.) By default, targets declared by a symbolic macro (including by any Starlark function that the macro's implementation function transitively calls) are visible only in the package containing the .bzl file defining the macro. To declare targets visible externally, *including to the caller of the symbolic macro*, the implementation function must set `visibility` appropriately – typically, by passing `visibility = visibility` to the rule or macro symbol being called. The following APIs are unavailable within a macro implementation function and any Starlark function it transitively calls:  * [`package()`, `licenses()`* `environment_group()`* [`native.glob()`](/versions/9.0.0/rules/lib/toplevel/native#glob) – instead, you may pass       a glob into the macro via a label list attribute* [`native.subpackages()`](/versions/9.0.0/rules/lib/toplevel/native#subpackages)* (allowed in rule finalizers only, see `finalizer` below)           [`native.existing_rules()`](/versions/9.0.0/rules/lib/toplevel/native#existing_rules),           [`native.existing_rule()`](/versions/9.0.0/rules/lib/toplevel/native#existing_rule)* (for `WORKSPACE` threads)             [`workspace()`](/versions/9.0.0/rules/lib/globals/module#workspace), [`register_toolchains()`](/versions/9.0.0/rules/lib/globals/module#register_toolchains), [`bind()`](/versions/9.0.0/rules/lib/globals/module#bind), [`register_execution_platforms()`](/versions/9.0.0/rules/lib/globals/module#register_execution_platforms), repository rule instantiation](/versions/9.0.0/reference/be/functions#package) |
+| `attrs` | [dict](/versions/9.0.0/rules/lib/core/dict); default is `{}`  A dictionary of the attributes this macro supports, analogous to [rule.attrs](#rule.attrs). Keys are attribute names, and values are either attribute objects like `attr.label_list(...)` (see the [attr](/versions/9.0.0/rules/lib/toplevel/attr) module), or `None`. A `None` entry means that the macro does not have an attribute by that name, even if it would have otherwise inherited one via `inherit_attrs` (see below). The special `name` attribute is predeclared and must not be included in the dictionary. The `visibility` attribute name is reserved and must not be included in the dictionary. Attributes whose names start with `_` are private -- they cannot be passed at the call site of the rule. Such attributes can be assigned a default value (as in `attr.label(default="//pkg:foo")`) to create an implicit dependency on a label. To limit memory usage, there is a cap on the number of attributes that may be declared. |
+| `inherit_attrs` | [rule](/versions/9.0.0/rules/lib/builtins/rule); or [macro](/versions/9.0.0/rules/lib/builtins/macro); or [string](/versions/9.0.0/rules/lib/core/string); or `None`; default is `None`  A rule symbol, macro symbol, or the name of a built-in common attribute list (see below) from which the macro should inherit attributes. If `inherit_attrs` is set to the string `"common"`, the macro will inherit [common rule attribute definitions](/versions/9.0.0/reference/be/common-definitions#common-attributes) used by all Starlark rules. Note that if the return value of `rule()` or `macro()` was not assigned to a global variable in a .bzl file, then such a value has not been registered as a rule or macro symbol, and therefore cannot be used for `inherit_attrs`. The inheritance mechanism works as follows:   1. The special `name` and `visibility` attributes are never inherited;- Hidden attributes (ones whose name starts with `"_"`) are never inherited;- Attributes whose names are already defined in the `attrs` dictionary are never        inherited (the entry in `attrs` takes precedence; note that an entry may be set to        `None` to ensure that no attribute by that name gets defined on the macro);- All other attributes are inherited from the rule or macro and effectively merged into the          `attrs` dict.   When a non-mandatory attribute is inherited, the default value of the attribute is overridden to be `None`, regardless of what it was specified in the original rule or macro. This ensures that when the macro forwards the attribute's value to an instance of the wrapped rule or macro – such as by passing in the unmodified `**kwargs` – a value that was absent from the outer macro's call will also be absent in the inner rule or macro's call (since passing `None` to an attribute is treated the same as omitting the attribute). This is important because omitting an attribute has subtly different semantics from passing its apparent default value. In particular, omitted attributes are not shown in some `bazel query` output formats, and computed defaults only execute when the value is omitted. If the macro needs to examine or modify an inherited attribute – for example, to add a value to an inherited `tags` attribute – you must make sure to handle the `None` case in the macro's implementation function. For example, the following macro inherits all attributes from `native.cc_library`, except for `cxxopts` (which is removed from the attribute list) and `copts` (which is given a new definition). It also takes care to checks for the default `None` value of the inherited `tags` attribute before appending an additional tag.  ``` def _my_cc_library_impl(name, visibility, tags, **kwargs):     # Append a tag; tags attr was inherited from native.cc_library, and     # therefore is None unless explicitly set by the caller of my_cc_library()     my_tags = (tags or []) + ["my_custom_tag"]     native.cc_library(         name = name,         visibility = visibility,         tags = my_tags,         **kwargs     )  my_cc_library = macro(     implementation = _my_cc_library_impl,     inherit_attrs = native.cc_library,     attrs = {         "cxxopts": None,         "copts": attr.string_list(default = ["-D_FOO"]),     }, ) ```   If `inherit_attrs` is set, the macro's implementation function *must* have a `**kwargs` residual keyword parameter. By convention, a macro should pass inherited, non-overridden attributes unchanged to the "main" rule or macro symbol which the macro is wrapping. Typically, most inherited attributes will not have a parameter in the implementation function's parameter list, and will simply be passed via `**kwargs`. It can be convenient for the implementation function to have explicit parameters for some inherited attributes (most commonly, `tags` and `testonly`) if the macro needs to pass those attributes to both "main" and non-"main" targets – but if the macro also needs to examine or manipulate those attributes, you must take care to handle the `None` default value of non-mandatory inherited attributes. |
+| `finalizer` | [bool](/versions/9.0.0/rules/lib/core/bool); default is `False`  Whether this macro is a rule finalizer, which is a macro that, regardless of its position in a `BUILD` file, is evaluated at the end of package loading, after all non-finalizer targets have been defined. Unlike ordinary symbolic macros, rule finalizers may call [`native.existing_rule()`](/versions/9.0.0/rules/lib/toplevel/native#existing_rule) and [`native.existing_rules()`](/versions/9.0.0/rules/lib/toplevel/native#existing_rules) to query the set of *non-finalizer* rule targets defined in the current package. Note that `native.existing_rule()` and `native.existing_rules()` cannot access the targets defined by any rule finalizer, including this one. |
+| `doc` | [string](/versions/9.0.0/rules/lib/core/string); or `None`; default is `None`  A description of the macro that can be extracted by documentation generating tools. |
 
 ## materializer\_rule
 
@@ -194,10 +194,10 @@ Materializer targets are used to dynamically select dependencies at analysis tim
 
 | Parameter | Description |
 | --- | --- |
-| `implementation` | [function](../core/function); required  The Starlark function implementing this materializer rule. It must have exactly one parameter: [ctx](../builtins/ctx). This function is called during the analysis phase for each instance of the rule. Materializer rules return exactly one and only one MaterializedDepsInfo provider which specifies the dependencies to materialize in place of any instance of this rule in the attributes of another target. |
-| `attrs` | [dict](../core/dict); default is `{}`  A dictionary to declare all the attributes of the rule. It maps from an attribute name to an attribute object (see [`attr`](../toplevel/attr) module). Attributes starting with `_` are private, and can be used to add an implicit dependency on a label. The attribute `name` is implicitly added and must not be specified. Attributes `visibility`, `deprecation`, `tags`, `testonly`, and `features` are implicitly added and cannot be overridden. Most rules need only a handful of attributes. To limit memory usage, there is a cap on the number of attributes that may be declared. Declared attributes will convert `None` to the default value. |
-| `doc` | [string](../core/string); or `None`; default is `None`  A description of the rule that can be extracted by documentation generating tools. |
-| `allow_real_deps` | [bool](../core/bool); default is `False`  Whether to allow instances of this materializer rule to have real dependencies (non-dormant deps / non-for\_dependency\_resolution). Subject to allowlist. |
+| `implementation` | [function](/versions/9.0.0/rules/lib/core/function); required  The Starlark function implementing this materializer rule. It must have exactly one parameter: [ctx](/versions/9.0.0/rules/lib/builtins/ctx). This function is called during the analysis phase for each instance of the rule. Materializer rules return exactly one and only one MaterializedDepsInfo provider which specifies the dependencies to materialize in place of any instance of this rule in the attributes of another target. |
+| `attrs` | [dict](/versions/9.0.0/rules/lib/core/dict); default is `{}`  A dictionary to declare all the attributes of the rule. It maps from an attribute name to an attribute object (see [`attr`](/versions/9.0.0/rules/lib/toplevel/attr) module). Attributes starting with `_` are private, and can be used to add an implicit dependency on a label. The attribute `name` is implicitly added and must not be specified. Attributes `visibility`, `deprecation`, `tags`, `testonly`, and `features` are implicitly added and cannot be overridden. Most rules need only a handful of attributes. To limit memory usage, there is a cap on the number of attributes that may be declared. Declared attributes will convert `None` to the default value. |
+| `doc` | [string](/versions/9.0.0/rules/lib/core/string); or `None`; default is `None`  A description of the rule that can be extracted by documentation generating tools. |
+| `allow_real_deps` | [bool](/versions/9.0.0/rules/lib/core/bool); default is `False`  Whether to allow instances of this materializer rule to have real dependencies (non-dormant deps / non-for\_dependency\_resolution). Subject to allowlist. |
 
 ## module\_extension
 
@@ -212,11 +212,11 @@ Creates a new module extension. Store it in a global value, so that it can be ex
 | Parameter | Description |
 | --- | --- |
 | `implementation` | callable; required  The function that implements this module extension. Must take a single parameter, `module_ctx`. The function is called once at the beginning of a build to determine the set of available repos. |
-| `tag_classes` | [dict](../core/dict); default is `{}`  A dictionary to declare all the tag classes used by the extension. It maps from the name of the tag class to a `tag_class` object. |
-| `doc` | [string](../core/string); or `None`; default is `None`  A description of the module extension that can be extracted by documentation generating tools. |
-| `environ` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  **Deprecated**. This parameter has been deprecated. Migrate to `module_ctx.getenv` instead.  Provides a list of environment variable that this module extension depends on. If an environment variable in that list changes, the extension will be re-evaluated.  See also `--experimental_strict_repo_env`. |
-| `os_dependent` | [bool](../core/bool); default is `False`  Indicates whether this extension is OS-dependent or not |
-| `arch_dependent` | [bool](../core/bool); default is `False`  Indicates whether this extension is architecture-dependent or not |
+| `tag_classes` | [dict](/versions/9.0.0/rules/lib/core/dict); default is `{}`  A dictionary to declare all the tag classes used by the extension. It maps from the name of the tag class to a `tag_class` object. |
+| `doc` | [string](/versions/9.0.0/rules/lib/core/string); or `None`; default is `None`  A description of the module extension that can be extracted by documentation generating tools. |
+| `environ` | [sequence](/versions/9.0.0/rules/lib/core/list) of [string](/versions/9.0.0/rules/lib/core/string)s; default is `[]`  **Deprecated**. This parameter has been deprecated. Migrate to `module_ctx.getenv` instead.  Provides a list of environment variable that this module extension depends on. If an environment variable in that list changes, the extension will be re-evaluated.  See also `--experimental_strict_repo_env`. |
+| `os_dependent` | [bool](/versions/9.0.0/rules/lib/core/bool); default is `False`  Indicates whether this extension is OS-dependent or not |
+| `arch_dependent` | [bool](/versions/9.0.0/rules/lib/core/bool); default is `False`  Indicates whether this extension is architecture-dependent or not |
 
 ## provider
 
@@ -239,16 +239,16 @@ def _my_library_impl(ctx):
 
 See [Rules (Providers)](https://bazel.build/versions/9.0.0/extending/rules#providers) for a comprehensive guide on how to use providers.
 
-Returns a [`Provider`](../builtins/Provider) callable value if `init` is not specified.
+Returns a [`Provider`](/versions/9.0.0/rules/lib/builtins/Provider) callable value if `init` is not specified.
 
-If `init` is specified, returns a tuple of 2 elements: a [`Provider`](../builtins/Provider) callable value and a *raw constructor* callable value. See  [Rules (Custom initialization of custom providers)](https://bazel.build/versions/9.0.0/extending/rules#custom_initialization_of_providers) and the discussion of the `init` parameter below for details.
+If `init` is specified, returns a tuple of 2 elements: a [`Provider`](/versions/9.0.0/rules/lib/builtins/Provider) callable value and a *raw constructor* callable value. See  [Rules (Custom initialization of custom providers)](https://bazel.build/versions/9.0.0/extending/rules#custom_initialization_of_providers) and the discussion of the `init` parameter below for details.
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `doc` | [string](../core/string); or `None`; default is `None` |
-| `fields` | [sequence](../core/list) of [string](../core/string)s; or [dict](../core/dict); or `None`; default is `None`  If specified, restricts the set of allowed fields.  Possible values are:  * list of fields:     ```   provider(fields = ['a', 'b'])   ```     * dictionary field name -> documentation:       ```     provider(            fields = { 'a' : 'Documentation for a', 'b' : 'Documentation for b' })     ```  All fields are optional. |
+| `doc` | [string](/versions/9.0.0/rules/lib/core/string); or `None`; default is `None` |
+| `fields` | [sequence](/versions/9.0.0/rules/lib/core/list) of [string](/versions/9.0.0/rules/lib/core/string)s; or [dict](/versions/9.0.0/rules/lib/core/dict); or `None`; default is `None`  If specified, restricts the set of allowed fields.  Possible values are:  * list of fields:     ```   provider(fields = ['a', 'b'])   ```     * dictionary field name -> documentation:       ```     provider(            fields = { 'a' : 'Documentation for a', 'b' : 'Documentation for b' })     ```  All fields are optional. |
 | `init` | callable; or `None`; default is `None` |
 
 ## repository\_rule
@@ -257,19 +257,19 @@ If `init` is specified, returns a tuple of 2 elements: a [`Provider`](../builtin
 callable repository_rule(implementation, *, attrs=None, local=False, environ=[], configure=False, remotable=False, doc=None)
 ```
 
-Creates a new repository rule. Store it in a global value, so that it can be loaded and called from a [`module_extension()`](#module_extension) implementation function, or used by [`use_repo_rule()`](../globals/module#use_repo_rule).
+Creates a new repository rule. Store it in a global value, so that it can be loaded and called from a [`module_extension()`](#module_extension) implementation function, or used by [`use_repo_rule()`](/versions/9.0.0/rules/lib/globals/module#use_repo_rule).
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
 | `implementation` | callable; required |
-| `attrs` | [dict](../core/dict); or `None`; default is `None` |
-| `local` | [bool](../core/bool); default is `False`  Indicate that this rule fetches everything from the local system and should be reevaluated at every fetch. |
-| `environ` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  **Deprecated**. This parameter has been deprecated. Migrate to `repository_ctx.getenv` instead.  Provides a list of environment variable that this repository rule depends on. If an environment variable in that list change, the repository will be refetched.  See also `--experimental_strict_repo_env`. |
-| `configure` | [bool](../core/bool); default is `False`  Indicate that the repository inspects the system for configuration purpose |
-| `remotable` | [bool](../core/bool); default is `False`  **Experimental**. This parameter is experimental and may change at any time. Please do not depend on it. It may be enabled on an experimental basis by setting `--experimental_repo_remote_exec`  Compatible with remote execution |
-| `doc` | [string](../core/string); or `None`; default is `None` |
+| `attrs` | [dict](/versions/9.0.0/rules/lib/core/dict); or `None`; default is `None` |
+| `local` | [bool](/versions/9.0.0/rules/lib/core/bool); default is `False`  Indicate that this rule fetches everything from the local system and should be reevaluated at every fetch. |
+| `environ` | [sequence](/versions/9.0.0/rules/lib/core/list) of [string](/versions/9.0.0/rules/lib/core/string)s; default is `[]`  **Deprecated**. This parameter has been deprecated. Migrate to `repository_ctx.getenv` instead.  Provides a list of environment variable that this repository rule depends on. If an environment variable in that list change, the repository will be refetched.  See also `--experimental_strict_repo_env`. |
+| `configure` | [bool](/versions/9.0.0/rules/lib/core/bool); default is `False`  Indicate that the repository inspects the system for configuration purpose |
+| `remotable` | [bool](/versions/9.0.0/rules/lib/core/bool); default is `False`  **Experimental**. This parameter is experimental and may change at any time. Please do not depend on it. It may be enabled on an experimental basis by setting `--experimental_repo_remote_exec`  Compatible with remote execution |
+| `doc` | [string](/versions/9.0.0/rules/lib/core/string); or `None`; default is `None` |
 
 ## rule
 
@@ -287,28 +287,28 @@ Test rules are required to have a name ending in `_test`, while all other rules
 
 | Parameter | Description |
 | --- | --- |
-| `implementation` | [function](../core/function); required  the Starlark function implementing this rule, must have exactly one parameter: [ctx](../builtins/ctx). The function is called during the analysis phase for each instance of the rule. It can access the attributes provided by the user. It must create actions to generate all the declared outputs. |
-| `test` | [bool](../core/bool); default is `unbound`  Whether this rule is a test rule, that is, whether it may be the subject of a `bazel test` command. All test rules are automatically considered [executable](#rule.executable); it is unnecessary (and discouraged) to explicitly set `executable = True` for a test rule. The value defaults to `False`. See the  [Rules page](https://bazel.build/versions/9.0.0/extending/rules#executable_rules_and_test_rules) for more information. |
-| `attrs` | [dict](../core/dict); default is `{}`  A dictionary to declare all the attributes of the rule. It maps from an attribute name to an attribute object (see [`attr`](../toplevel/attr) module). Attributes starting with `_` are private, and can be used to add an implicit dependency on a label. The attribute `name` is implicitly added and must not be specified. Attributes `visibility`, `deprecation`, `tags`, `testonly`, and `features` are implicitly added and cannot be overridden. Most rules need only a handful of attributes. To limit memory usage, there is a cap on the number of attributes that may be declared. Declared attributes will convert `None` to the default value. |
-| `outputs` | [dict](../core/dict); or `None`; or [function](../core/function); default is `None`  **Deprecated**. This parameter is deprecated and will be removed soon. Please do not depend on it. It is *disabled* with `--incompatible_no_rule_outputs_param`. Use this flag to verify your code is compatible with its imminent removal.  This parameter has been deprecated. Migrate rules to use `OutputGroupInfo` or `attr.output` instead. A schema for defining predeclared outputs. Unlike [`output`](../toplevel/attr#output) and [`output_list`](../toplevel/attr#output_list) attributes, the user does not specify the labels for these files. See the [Rules page](https://bazel.build/versions/9.0.0/extending/rules#files) for more on predeclared outputs. The value of this argument is either a dictionary or a callback function that produces a dictionary. The callback works similar to computed dependency attributes: The function's parameter names are matched against the rule's attributes, so for example if you pass `outputs = _my_func` with the definition `def _my_func(srcs, deps): ...`, the function has access to the attributes `srcs` and `deps`. Whether the dictionary is specified directly or via a function, it is interpreted as follows. Each entry in the dictionary creates a predeclared output where the key is an identifier and the value is a string template that determines the output's label. In the rule's implementation function, the identifier becomes the field name used to access the output's [`File`](../builtins/File) in [`ctx.outputs`](../builtins/ctx#outputs). The output's label has the same package as the rule, and the part after the package is produced by substituting each placeholder of the form `"%{ATTR}"` with a string formed from the value of the attribute `ATTR`:  * String-typed attributes are substituted verbatim.* Label-typed attributes become the part of the label after the package, minus the file extension. For example, the label `"//pkg:a/b.c"` becomes `"a/b"`.* Output-typed attributes become the part of the label after the package, including the file extension (for the above example, `"a/b.c"`).* All list-typed attributes (for example, `attr.label_list`) used in placeholders are required to have *exactly one element*. Their conversion is the same as their non-list version (`attr.label`).* Other attribute types may not appear in placeholders.* The special non-attribute placeholders `%{dirname}` and `%{basename}` expand to those parts of the rule's label, excluding its package. For example, in `"//pkg:a/b.c"`, the dirname is `a` and the basename is `b.c`.   In practice, the most common substitution placeholder is `"%{name}"`. For example, for a target named "foo", the outputs dict `{"bin": "%{name}.exe"}` predeclares an output named `foo.exe` that is accessible in the implementation function as `ctx.outputs.bin`. |
-| `executable` | [bool](../core/bool); default is `unbound` |
-| `output_to_genfiles` | [bool](../core/bool); default is `False`  If true, the files will be generated in the genfiles directory instead of the bin directory. Unless you need it for compatibility with existing rules (e.g. when generating header files for C++), do not set this flag. |
-| `fragments` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  List of names of configuration fragments that the rule requires in target configuration. |
-| `host_fragments` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  List of names of configuration fragments that the rule requires in host configuration. |
-| `_skylark_testable` | [bool](../core/bool); default is `False`  *(Experimental)*  If true, this rule will expose its actions for inspection by rules that depend on it via an `Actions` provider. The provider is also available to the rule itself by calling [ctx.created\_actions()](../builtins/ctx#created_actions).  This should only be used for testing the analysis-time behavior of Starlark rules. This flag may be removed in the future. |
-| `toolchains` | [sequence](../core/list); default is `[]`  If set, the set of toolchains this rule requires. The list can contain String, Label, or StarlarkToolchainTypeApi objects, in any combination. Toolchains will be found by checking the current platform, and provided to the rule implementation via `ctx.toolchain`. |
-| `doc` | [string](../core/string); or `None`; default is `None`  A description of the rule that can be extracted by documentation generating tools. |
-| `provides` | [sequence](../core/list); default is `[]`  A list of providers that the implementation function must return. It is an error if the implementation function omits any of the types of providers listed here from its return value. However, the implementation function may return additional providers not listed here. Each element of the list is an `*Info` object returned by [`provider()`](../globals/bzl#provider). When a target of the rule is used as a dependency for a target that declares a required provider, it is not necessary to specify that provider here. It is enough that the implementation function returns it. However, it is considered best practice to specify it, even though this is not required. The [`required_providers`](../globals/bzl#aspect.required_providers) field of an [aspect](../globals/bzl#aspect) does, however, require that providers are specified here. |
-| `dependency_resolution_rule` | [bool](../core/bool); default is `False`  If set, the rule can be a dependency through attributes also marked as available in materializers. Every attribute of rules with this flag set must be marked as available in materializers also. This is so that rules so marked cannot depend on rules that are not so marked. |
-| `exec_compatible_with` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  A list of constraints on the execution platform that apply to all targets of this rule type. |
-| `analysis_test` | [bool](../core/bool); default is `False`  If true, then this rule is treated as an analysis test. Note: Analysis test rules are primarily defined using infrastructure provided in core Starlark libraries. See [Testing](https://bazel.build/versions/9.0.0/rules/testing#testing-rules) for guidance. If a rule is defined as an analysis test rule, it becomes allowed to use configuration transitions defined using [analysis\_test\_transition](#analysis_test_transition) on its attributes, but opts into some restrictions:  * Targets of this rule are limited in the number of transitive dependencies they may have.* The rule is considered a test rule (as if `test=True` were set). This supersedes the value of `test`   * The rule implementation function may not register actions. Instead, it must register a pass/fail result via providing [AnalysisTestResultInfo](../providers/AnalysisTestResultInfo). |
-| `build_setting` | [BuildSetting](../builtins/BuildSetting); or `None`; default is `None`  If set, describes what kind of [`build setting`](/versions/9.0.0/rules/config#user-defined-build-settings) this rule is. See the [`config`](../toplevel/config) module. If this is set, a mandatory attribute named "build\_setting\_default" is automatically added to this rule, with a type corresponding to the value passed in here. |
+| `implementation` | [function](/versions/9.0.0/rules/lib/core/function); required  the Starlark function implementing this rule, must have exactly one parameter: [ctx](/versions/9.0.0/rules/lib/builtins/ctx). The function is called during the analysis phase for each instance of the rule. It can access the attributes provided by the user. It must create actions to generate all the declared outputs. |
+| `test` | [bool](/versions/9.0.0/rules/lib/core/bool); default is `unbound`  Whether this rule is a test rule, that is, whether it may be the subject of a `bazel test` command. All test rules are automatically considered [executable](#rule.executable); it is unnecessary (and discouraged) to explicitly set `executable = True` for a test rule. The value defaults to `False`. See the  [Rules page](https://bazel.build/versions/9.0.0/extending/rules#executable_rules_and_test_rules) for more information. |
+| `attrs` | [dict](/versions/9.0.0/rules/lib/core/dict); default is `{}`  A dictionary to declare all the attributes of the rule. It maps from an attribute name to an attribute object (see [`attr`](/versions/9.0.0/rules/lib/toplevel/attr) module). Attributes starting with `_` are private, and can be used to add an implicit dependency on a label. The attribute `name` is implicitly added and must not be specified. Attributes `visibility`, `deprecation`, `tags`, `testonly`, and `features` are implicitly added and cannot be overridden. Most rules need only a handful of attributes. To limit memory usage, there is a cap on the number of attributes that may be declared. Declared attributes will convert `None` to the default value. |
+| `outputs` | [dict](/versions/9.0.0/rules/lib/core/dict); or `None`; or [function](/versions/9.0.0/rules/lib/core/function); default is `None`  **Deprecated**. This parameter is deprecated and will be removed soon. Please do not depend on it. It is *disabled* with `--incompatible_no_rule_outputs_param`. Use this flag to verify your code is compatible with its imminent removal.  This parameter has been deprecated. Migrate rules to use `OutputGroupInfo` or `attr.output` instead. A schema for defining predeclared outputs. Unlike [`output`](/versions/9.0.0/rules/lib/toplevel/attr#output) and [`output_list`](/versions/9.0.0/rules/lib/toplevel/attr#output_list) attributes, the user does not specify the labels for these files. See the [Rules page](https://bazel.build/versions/9.0.0/extending/rules#files) for more on predeclared outputs. The value of this argument is either a dictionary or a callback function that produces a dictionary. The callback works similar to computed dependency attributes: The function's parameter names are matched against the rule's attributes, so for example if you pass `outputs = _my_func` with the definition `def _my_func(srcs, deps): ...`, the function has access to the attributes `srcs` and `deps`. Whether the dictionary is specified directly or via a function, it is interpreted as follows. Each entry in the dictionary creates a predeclared output where the key is an identifier and the value is a string template that determines the output's label. In the rule's implementation function, the identifier becomes the field name used to access the output's [`File`](/versions/9.0.0/rules/lib/builtins/File) in [`ctx.outputs`](/versions/9.0.0/rules/lib/builtins/ctx#outputs). The output's label has the same package as the rule, and the part after the package is produced by substituting each placeholder of the form `"%{ATTR}"` with a string formed from the value of the attribute `ATTR`:  * String-typed attributes are substituted verbatim.* Label-typed attributes become the part of the label after the package, minus the file extension. For example, the label `"//pkg:a/b.c"` becomes `"a/b"`.* Output-typed attributes become the part of the label after the package, including the file extension (for the above example, `"a/b.c"`).* All list-typed attributes (for example, `attr.label_list`) used in placeholders are required to have *exactly one element*. Their conversion is the same as their non-list version (`attr.label`).* Other attribute types may not appear in placeholders.* The special non-attribute placeholders `%{dirname}` and `%{basename}` expand to those parts of the rule's label, excluding its package. For example, in `"//pkg:a/b.c"`, the dirname is `a` and the basename is `b.c`.   In practice, the most common substitution placeholder is `"%{name}"`. For example, for a target named "foo", the outputs dict `{"bin": "%{name}.exe"}` predeclares an output named `foo.exe` that is accessible in the implementation function as `ctx.outputs.bin`. |
+| `executable` | [bool](/versions/9.0.0/rules/lib/core/bool); default is `unbound` |
+| `output_to_genfiles` | [bool](/versions/9.0.0/rules/lib/core/bool); default is `False`  If true, the files will be generated in the genfiles directory instead of the bin directory. Unless you need it for compatibility with existing rules (e.g. when generating header files for C++), do not set this flag. |
+| `fragments` | [sequence](/versions/9.0.0/rules/lib/core/list) of [string](/versions/9.0.0/rules/lib/core/string)s; default is `[]`  List of names of configuration fragments that the rule requires in target configuration. |
+| `host_fragments` | [sequence](/versions/9.0.0/rules/lib/core/list) of [string](/versions/9.0.0/rules/lib/core/string)s; default is `[]`  List of names of configuration fragments that the rule requires in host configuration. |
+| `_skylark_testable` | [bool](/versions/9.0.0/rules/lib/core/bool); default is `False`  *(Experimental)*  If true, this rule will expose its actions for inspection by rules that depend on it via an `Actions` provider. The provider is also available to the rule itself by calling [ctx.created\_actions()](/versions/9.0.0/rules/lib/builtins/ctx#created_actions).  This should only be used for testing the analysis-time behavior of Starlark rules. This flag may be removed in the future. |
+| `toolchains` | [sequence](/versions/9.0.0/rules/lib/core/list); default is `[]`  If set, the set of toolchains this rule requires. The list can contain String, Label, or StarlarkToolchainTypeApi objects, in any combination. Toolchains will be found by checking the current platform, and provided to the rule implementation via `ctx.toolchain`. |
+| `doc` | [string](/versions/9.0.0/rules/lib/core/string); or `None`; default is `None`  A description of the rule that can be extracted by documentation generating tools. |
+| `provides` | [sequence](/versions/9.0.0/rules/lib/core/list); default is `[]`  A list of providers that the implementation function must return. It is an error if the implementation function omits any of the types of providers listed here from its return value. However, the implementation function may return additional providers not listed here. Each element of the list is an `*Info` object returned by [`provider()`](/versions/9.0.0/rules/lib/globals/bzl#provider). When a target of the rule is used as a dependency for a target that declares a required provider, it is not necessary to specify that provider here. It is enough that the implementation function returns it. However, it is considered best practice to specify it, even though this is not required. The [`required_providers`](/versions/9.0.0/rules/lib/globals/bzl#aspect.required_providers) field of an [aspect](/versions/9.0.0/rules/lib/globals/bzl#aspect) does, however, require that providers are specified here. |
+| `dependency_resolution_rule` | [bool](/versions/9.0.0/rules/lib/core/bool); default is `False`  If set, the rule can be a dependency through attributes also marked as available in materializers. Every attribute of rules with this flag set must be marked as available in materializers also. This is so that rules so marked cannot depend on rules that are not so marked. |
+| `exec_compatible_with` | [sequence](/versions/9.0.0/rules/lib/core/list) of [string](/versions/9.0.0/rules/lib/core/string)s; default is `[]`  A list of constraints on the execution platform that apply to all targets of this rule type. |
+| `analysis_test` | [bool](/versions/9.0.0/rules/lib/core/bool); default is `False`  If true, then this rule is treated as an analysis test. Note: Analysis test rules are primarily defined using infrastructure provided in core Starlark libraries. See [Testing](https://bazel.build/versions/9.0.0/rules/testing#testing-rules) for guidance. If a rule is defined as an analysis test rule, it becomes allowed to use configuration transitions defined using [analysis\_test\_transition](#analysis_test_transition) on its attributes, but opts into some restrictions:  * Targets of this rule are limited in the number of transitive dependencies they may have.* The rule is considered a test rule (as if `test=True` were set). This supersedes the value of `test`   * The rule implementation function may not register actions. Instead, it must register a pass/fail result via providing [AnalysisTestResultInfo](/versions/9.0.0/rules/lib/providers/AnalysisTestResultInfo). |
+| `build_setting` | [BuildSetting](/versions/9.0.0/rules/lib/builtins/BuildSetting); or `None`; default is `None`  If set, describes what kind of [`build setting`](/versions/9.0.0/rules/config#user-defined-build-settings) this rule is. See the [`config`](/versions/9.0.0/rules/lib/toplevel/config) module. If this is set, a mandatory attribute named "build\_setting\_default" is automatically added to this rule, with a type corresponding to the value passed in here. |
 | `cfg` | default is `None`  If set, points to the configuration transition the rule will apply to its own configuration before analysis. |
-| `exec_groups` | [dict](../core/dict); or `None`; default is `None`  Dict of execution group name (string) to [`exec_group`s](../globals/bzl#exec_group). If set, allows rules to run actions on multiple execution platforms within a single target. See [execution groups documentation](/versions/9.0.0/reference/exec-groups) for more info. |
+| `exec_groups` | [dict](/versions/9.0.0/rules/lib/core/dict); or `None`; default is `None`  Dict of execution group name (string) to [`exec_group`s](/versions/9.0.0/rules/lib/globals/bzl#exec_group). If set, allows rules to run actions on multiple execution platforms within a single target. See [execution groups documentation](/versions/9.0.0/reference/exec-groups) for more info. |
 | `initializer` | default is `None`  Experimental: the Stalark function initializing the attributes of the rule. The function is called at load time for each instance of the rule. It's called with `name` and the values of public attributes defined by the rule (not with generic attributes, for example `tags`). It has to return a dictionary from the attribute names to the desired values. The attributes that are not returned are unaffected. Returning `None` as value results in using the default value specified in the attribute definition. Initializers are evaluated before the default values specified in an attribute definition. Consequently, if a parameter in the initializer's signature contains a default values, it overwrites the default from the attribute definition (except if returning `None`). Similarly, if a parameter in the initializer's signature doesn't have a default, the parameter will become mandatory. It's a good practice to omit default/mandatory settings on an attribute definition in such cases. It's a good practice to use `**kwargs` for attributes that are not handled. In case of extended rules, all initializers are called proceeding from child to ancestors. Each initializer is passed only the public attributes it knows about. |
 | `parent` | default is `None`  Experimental: the Stalark rule that is extended. When set the public attributes are merged as well as advertised providers. The rule matches `executable` and `test` from the parent. Values of `fragments`, `toolchains`, `exec_compatible_with`, and `exec_groups` are merged. Legacy or deprecated parameters may not be set. Incoming configuration transition `cfg` of parent is applied after thisrule's incoming configuration. |
-| `extendable` | [bool](../core/bool); or [Label](../builtins/Label); or [string](../core/string); or `None`; default is `None`  Experimental: A label of an allowlist defining which rules can extending this rule. It can be set also to True/False to always allow/disallow extending. Bazel defaults to always allowing extensions. |
-| `subrules` | [sequence](../core/list) of [Subrule](../builtins/Subrule)s; default is `[]`  Experimental: List of subrules used by this rule. |
+| `extendable` | [bool](/versions/9.0.0/rules/lib/core/bool); or [Label](/versions/9.0.0/rules/lib/builtins/Label); or [string](/versions/9.0.0/rules/lib/core/string); or `None`; default is `None`  Experimental: A label of an allowlist defining which rules can extending this rule. It can be set also to True/False to always allow/disallow extending. Bazel defaults to always allowing extensions. |
+| `subrules` | [sequence](/versions/9.0.0/rules/lib/core/list) of [Subrule](/versions/9.0.0/rules/lib/builtins/Subrule)s; default is `[]`  Experimental: List of subrules used by this rule. |
 
 ## select
 
@@ -322,8 +322,8 @@ unknown select(x, no_match_error='')
 
 | Parameter | Description |
 | --- | --- |
-| `x` | [dict](../core/dict); required  A dict that maps configuration conditions to values. Each key is a [Label](../builtins/Label) or a label string that identifies a config\_setting or constraint\_value instance. See the [documentation on macros](https://bazel.build/versions/9.0.0/extending/legacy-macros#label-resolution) for when to use a Label instead of a string. If `--incompatible_resolve_select_keys_eagerly` is enabled, the keys are resolved to `Label` objects relative to the package of the file that contains this call to `select`. |
-| `no_match_error` | [string](../core/string); default is `''`  Optional custom error to report if no condition matches. |
+| `x` | [dict](/versions/9.0.0/rules/lib/core/dict); required  A dict that maps configuration conditions to values. Each key is a [Label](/versions/9.0.0/rules/lib/builtins/Label) or a label string that identifies a config\_setting or constraint\_value instance. See the [documentation on macros](https://bazel.build/versions/9.0.0/extending/legacy-macros#label-resolution) for when to use a Label instead of a string. If `--incompatible_resolve_select_keys_eagerly` is enabled, the keys are resolved to `Label` objects relative to the package of the file that contains this call to `select`. |
+| `no_match_error` | [string](/versions/9.0.0/rules/lib/core/string); default is `''`  Optional custom error to report if no condition matches. |
 
 ## subrule
 
@@ -337,11 +337,11 @@ Constructs a new instance of a subrule. The result of this function must be stor
 
 | Parameter | Description |
 | --- | --- |
-| `implementation` | [function](../core/function); required  The Starlark function implementing this subrule |
-| `attrs` | [dict](../core/dict); default is `{}`  A dictionary to declare all the (private) attributes of the subrule.  Subrules may only have private attributes that are label-typed (i.e. label or label-list). The resolved values corresponding to these labels are automatically passed by Bazel to the subrule's implementation function as named arguments (thus the implementation function is required to accept named parameters matching the attribute names). The types of these values will be:  * `FilesToRunProvider` for label attributes with `executable=True` * `File` for label attributes with `allow_single_file=True` * `Target` for all other label attributes * `[Target]` for all label-list attributes |
-| `toolchains` | [sequence](../core/list); default is `[]`  If set, the set of toolchains this subrule requires. The list can contain String, Label, or StarlarkToolchainTypeApi objects, in any combination. Toolchains will be found by checking the current platform, and provided to the subrule implementation via `ctx.toolchains`. Note that AEGs need to be enabled on the consuming rule(s) if this parameter is set. In case you haven't migrated to AEGs yet, see https://bazel.build/extending/auto-exec-groups#migration-aegs. |
-| `fragments` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  List of names of configuration fragments that the subrule requires in target configuration. |
-| `subrules` | [sequence](../core/list) of [Subrule](../builtins/Subrule)s; default is `[]`  List of other subrules needed by this subrule. |
+| `implementation` | [function](/versions/9.0.0/rules/lib/core/function); required  The Starlark function implementing this subrule |
+| `attrs` | [dict](/versions/9.0.0/rules/lib/core/dict); default is `{}`  A dictionary to declare all the (private) attributes of the subrule.  Subrules may only have private attributes that are label-typed (i.e. label or label-list). The resolved values corresponding to these labels are automatically passed by Bazel to the subrule's implementation function as named arguments (thus the implementation function is required to accept named parameters matching the attribute names). The types of these values will be:  * `FilesToRunProvider` for label attributes with `executable=True` * `File` for label attributes with `allow_single_file=True` * `Target` for all other label attributes * `[Target]` for all label-list attributes |
+| `toolchains` | [sequence](/versions/9.0.0/rules/lib/core/list); default is `[]`  If set, the set of toolchains this subrule requires. The list can contain String, Label, or StarlarkToolchainTypeApi objects, in any combination. Toolchains will be found by checking the current platform, and provided to the subrule implementation via `ctx.toolchains`. Note that AEGs need to be enabled on the consuming rule(s) if this parameter is set. In case you haven't migrated to AEGs yet, see https://bazel.build/extending/auto-exec-groups#migration-aegs. |
+| `fragments` | [sequence](/versions/9.0.0/rules/lib/core/list) of [string](/versions/9.0.0/rules/lib/core/string)s; default is `[]`  List of names of configuration fragments that the subrule requires in target configuration. |
+| `subrules` | [sequence](/versions/9.0.0/rules/lib/core/list) of [Subrule](/versions/9.0.0/rules/lib/builtins/Subrule)s; default is `[]`  List of other subrules needed by this subrule. |
 
 ## tag\_class
 
@@ -355,8 +355,8 @@ Creates a new tag\_class object, which defines an attribute schema for a class o
 
 | Parameter | Description |
 | --- | --- |
-| `attrs` | [dict](../core/dict); default is `{}`  A dictionary to declare all the attributes of this tag class. It maps from an attribute name to an attribute object (see [attr](../toplevel/attr) module). Note that unlike [`rule()`](../globals/bzl#rule), [`aspect()`](../globals/bzl#aspect) and [`repository_rule()`](../globals/bzl#repository_rule), declared attributes will not convert `None` to the default value. For the default to be used, the attribute must be omitted entirely by the caller. |
-| `doc` | [string](../core/string); or `None`; default is `None`  A description of the tag class that can be extracted by documentation generating tools. |
+| `attrs` | [dict](/versions/9.0.0/rules/lib/core/dict); default is `{}`  A dictionary to declare all the attributes of this tag class. It maps from an attribute name to an attribute object (see [attr](/versions/9.0.0/rules/lib/toplevel/attr) module). Note that unlike [`rule()`](/versions/9.0.0/rules/lib/globals/bzl#rule), [`aspect()`](/versions/9.0.0/rules/lib/globals/bzl#aspect) and [`repository_rule()`](/versions/9.0.0/rules/lib/globals/bzl#repository_rule), declared attributes will not convert `None` to the default value. For the default to be used, the attribute must be omitted entirely by the caller. |
+| `doc` | [string](/versions/9.0.0/rules/lib/core/string); or `None`; default is `None`  A description of the tag class that can be extracted by documentation generating tools. |
 
 ## visibility
 
diff --git a/versions/9.0.0/rules/lib/globals/module.mdx b/versions/9.0.0/rules/lib/globals/module.mdx
index 7160f871..4b7d81f7 100644
--- a/versions/9.0.0/rules/lib/globals/module.mdx
+++ b/versions/9.0.0/rules/lib/globals/module.mdx
@@ -31,7 +31,7 @@ None archive_override(*, module_name, **kwargs)
 
 Specifies that this dependency should come from an archive file (zip, gzip, etc) at a
 certain location, instead of from a registry. Effectively, this dependency will be
-backed by an [`http_archive`](../repo/http#http_archive) rule.
+backed by an [`http_archive`](/versions/9.0.0/rules/lib/repo/http#http_archive) rule.
 
 This directive only takes effect in the root module; in other words, if a module is
 used as a dependency by others, its own overrides are ignored.
@@ -40,7 +40,7 @@ used as a dependency by others, its own overrides are ignored.
 
 | Parameter | Description |
 | --- | --- |
-| `module_name` | [string](../core/string); required  The name of the Bazel module dependency to apply this override to. |
+| `module_name` | [string](/versions/9.0.0/rules/lib/core/string); required  The name of the Bazel module dependency to apply this override to. |
 | `kwargs` | required  All other arguments are forwarded to the underlying `http_archive` repo rule. Note that the `name` attribute shouldn't be specified; use `module_name` instead. |
 
 ## bazel\_dep
@@ -55,11 +55,11 @@ Declares a direct dependency on another Bazel module.
 
 | Parameter | Description |
 | --- | --- |
-| `name` | [string](../core/string); required  The name of the module to be added as a direct dependency. |
-| `version` | [string](../core/string); default is `''`  The version of the module to be added as a direct dependency. |
-| `max_compatibility_level` | [int](../core/int); default is `-1`  The maximum `compatibility_level` supported for the module to be added as a direct dependency. The version of the module implies the minimum compatibility\_level supported, as well as the maximum if this attribute is not specified. |
-| `repo_name` | [string](../core/string); or `None`; default is `''`  The name of the external repo representing this dependency. This is by default the name of the module. Can be set to `None` to make this dependency a "*nodep*" dependency: in this case, this `bazel_dep` specification is only honored if the target module already exists in the dependency graph by some other means. |
-| `dev_dependency` | [bool](../core/bool); default is `False`  If true, this dependency will be ignored if the current module is not the root module or `--ignore_dev_dependency` is enabled. |
+| `name` | [string](/versions/9.0.0/rules/lib/core/string); required  The name of the module to be added as a direct dependency. |
+| `version` | [string](/versions/9.0.0/rules/lib/core/string); default is `''`  The version of the module to be added as a direct dependency. |
+| `max_compatibility_level` | [int](/versions/9.0.0/rules/lib/core/int); default is `-1`  The maximum `compatibility_level` supported for the module to be added as a direct dependency. The version of the module implies the minimum compatibility\_level supported, as well as the maximum if this attribute is not specified. |
+| `repo_name` | [string](/versions/9.0.0/rules/lib/core/string); or `None`; default is `''`  The name of the external repo representing this dependency. This is by default the name of the module. Can be set to `None` to make this dependency a "*nodep*" dependency: in this case, this `bazel_dep` specification is only honored if the target module already exists in the dependency graph by some other means. |
+| `dev_dependency` | [bool](/versions/9.0.0/rules/lib/core/bool); default is `False`  If true, this dependency will be ignored if the current module is not the root module or `--ignore_dev_dependency` is enabled. |
 
 ## flag\_alias
 
@@ -74,8 +74,8 @@ instances of $ bazel build //target --foo to $ bazel build //target --@repo//def
 
 | Parameter | Description |
 | --- | --- |
-| `name` | [string](../core/string); required  The name of the flag. |
-| `starlark_flag` | [string](../core/string); required  The label of the Starlark flag to alias to. |
+| `name` | [string](/versions/9.0.0/rules/lib/core/string); required  The name of the flag. |
+| `starlark_flag` | [string](/versions/9.0.0/rules/lib/core/string); required  The label of the Starlark flag to alias to. |
 
 ## git\_override
 
@@ -85,7 +85,7 @@ None git_override(*, module_name, **kwargs)
 
 Specifies that this dependency should come from a certain commit in a Git repository,
 instead of from a registry. Effectively, this dependency will be backed by a
-[`git_repository`](../repo/git#git_repository) rule.
+[`git_repository`](/versions/9.0.0/rules/lib/repo/git#git_repository) rule.
 
 This directive only takes effect in the root module; in other words, if a module is
 used as a dependency by others, its own overrides are ignored.
@@ -94,7 +94,7 @@ used as a dependency by others, its own overrides are ignored.
 
 | Parameter | Description |
 | --- | --- |
-| `module_name` | [string](../core/string); required  The name of the Bazel module dependency to apply this override to. |
+| `module_name` | [string](/versions/9.0.0/rules/lib/core/string); required  The name of the Bazel module dependency to apply this override to. |
 | `kwargs` | required  All other arguments are forwarded to the underlying `git_repository` repo rule. Note that the `name` attribute shouldn't be specified; use `module_name` instead. |
 
 ## include
@@ -115,7 +115,7 @@ Only files in the current module's repo may be included.
 
 | Parameter | Description |
 | --- | --- |
-| `label` | [string](../core/string); required  The label pointing to the file to include. The label must point to a file in the main repo; in other words, it **must **start with double slashes (`//`). The name of the file must end with `.MODULE.bazel` and must not start with `.`.**** |
+| `label` | [string](/versions/9.0.0/rules/lib/core/string); required  The label pointing to the file to include. The label must point to a file in the main repo; in other words, it **must **start with double slashes (`//`). The name of the file must end with `.MODULE.bazel` and must not start with `.`.**** |
 
 ## inject\_repo
 
@@ -146,7 +146,7 @@ None local_path_override(*, module_name, path)
 
 Specifies that this dependency should come from a certain directory on local disk,
 instead of from a registry. Effectively, this dependency will be backed by a
-[`local_repository`](../repo/local#local_repository) rule.
+[`local_repository`](/versions/9.0.0/rules/lib/repo/local#local_repository) rule.
 
 This directive only takes effect in the root module; in other words, if a module is
 used as a dependency by others, its own overrides are ignored.
@@ -155,8 +155,8 @@ used as a dependency by others, its own overrides are ignored.
 
 | Parameter | Description |
 | --- | --- |
-| `module_name` | [string](../core/string); required  The name of the Bazel module dependency to apply this override to. |
-| `path` | [string](../core/string); required  The path to the directory where this module is. |
+| `module_name` | [string](/versions/9.0.0/rules/lib/core/string); required  The name of the Bazel module dependency to apply this override to. |
+| `path` | [string](/versions/9.0.0/rules/lib/core/string); required  The path to the directory where this module is. |
 
 ## module
 
@@ -172,11 +172,11 @@ It should be called at most once, and if called, it must be the very first direc
 
 | Parameter | Description |
 | --- | --- |
-| `name` | [string](../core/string); default is `''`  The name of the module. Can be omitted only if this module is the root module (as in, if it's not going to be depended on by another module). A valid module name must: 1) only contain lowercase letters (a-z), digits (0-9), dots (.), hyphens (-), and underscores (\_); 2) begin with a lowercase letter; 3) end with a lowercase letter or digit. |
-| `version` | [string](../core/string); default is `''`  The version of the module. Can be omitted only if this module is the root module (as in, if it's not going to be depended on by another module). The version must be in a relaxed SemVer format; see [the documentation](/versions/9.0.0/external/module#version_format) for more details. |
-| `compatibility_level` | [int](../core/int); default is `0`  The compatibility level of the module; this should be changed every time a major incompatible change is introduced. This is essentially the "major version" of the module in terms of SemVer, except that it's not embedded in the version string itself, but exists as a separate field. Modules with different compatibility levels participate in version resolution as if they're modules with different names, but the final dependency graph cannot contain multiple modules with the same name but different compatibility levels (unless `multiple_version_override` is in effect). See [the documentation](/versions/9.0.0/external/module#compatibility_level) for more details. |
-| `repo_name` | [string](../core/string); default is `''`  The name of the repository representing this module, as seen by the module itself. By default, the name of the repo is the name of the module. This can be specified to ease migration for projects that have been using a repo name for itself that differs from its module name. |
-| `bazel_compatibility` | Iterable of [string](../core/string)s; default is `[]`  A list of bazel versions that allows users to declare which Bazel versions are compatible with this module. It does NOT affect dependency resolution, but bzlmod will use this information to check if your current Bazel version is compatible. The format of this value is a string of some constraint values separated by comma. Three constraints are supported: <=X.X.X: The Bazel version must be equal or older than X.X.X. Used when there is a known incompatible change in a newer version. >=X.X.X: The Bazel version must be equal or newer than X.X.X.Used when you depend on some features that are only available since X.X.X. -X.X.X: The Bazel version X.X.X is not compatible. Used when there is a bug in X.X.X that breaks you, but fixed in later versions. |
+| `name` | [string](/versions/9.0.0/rules/lib/core/string); default is `''`  The name of the module. Can be omitted only if this module is the root module (as in, if it's not going to be depended on by another module). A valid module name must: 1) only contain lowercase letters (a-z), digits (0-9), dots (.), hyphens (-), and underscores (\_); 2) begin with a lowercase letter; 3) end with a lowercase letter or digit. |
+| `version` | [string](/versions/9.0.0/rules/lib/core/string); default is `''`  The version of the module. Can be omitted only if this module is the root module (as in, if it's not going to be depended on by another module). The version must be in a relaxed SemVer format; see [the documentation](/versions/9.0.0/external/module#version_format) for more details. |
+| `compatibility_level` | [int](/versions/9.0.0/rules/lib/core/int); default is `0`  The compatibility level of the module; this should be changed every time a major incompatible change is introduced. This is essentially the "major version" of the module in terms of SemVer, except that it's not embedded in the version string itself, but exists as a separate field. Modules with different compatibility levels participate in version resolution as if they're modules with different names, but the final dependency graph cannot contain multiple modules with the same name but different compatibility levels (unless `multiple_version_override` is in effect). See [the documentation](/versions/9.0.0/external/module#compatibility_level) for more details. |
+| `repo_name` | [string](/versions/9.0.0/rules/lib/core/string); default is `''`  The name of the repository representing this module, as seen by the module itself. By default, the name of the repo is the name of the module. This can be specified to ease migration for projects that have been using a repo name for itself that differs from its module name. |
+| `bazel_compatibility` | Iterable of [string](/versions/9.0.0/rules/lib/core/string)s; default is `[]`  A list of bazel versions that allows users to declare which Bazel versions are compatible with this module. It does NOT affect dependency resolution, but bzlmod will use this information to check if your current Bazel version is compatible. The format of this value is a string of some constraint values separated by comma. Three constraints are supported: <=X.X.X: The Bazel version must be equal or older than X.X.X. Used when there is a known incompatible change in a newer version. >=X.X.X: The Bazel version must be equal or newer than X.X.X.Used when you depend on some features that are only available since X.X.X. -X.X.X: The Bazel version X.X.X is not compatible. Used when there is a bug in X.X.X that breaks you, but fixed in later versions. |
 
 ## multiple\_version\_override
 
@@ -190,9 +190,9 @@ Specifies that a dependency should still come from a registry, but multiple vers
 
 | Parameter | Description |
 | --- | --- |
-| `module_name` | [string](../core/string); required  The name of the Bazel module dependency to apply this override to. |
-| `versions` | Iterable of [string](../core/string)s; required  Explicitly specifies the versions allowed to coexist. These versions must already be present in the dependency graph pre-selection. Dependencies on this module will be "upgraded" to the nearest higher allowed version at the same compatibility level, whereas dependencies that have a higher version than any allowed versions at the same compatibility level will cause an error. |
-| `registry` | [string](../core/string); default is `''`  Overrides the registry for this module; instead of finding this module from the default list of registries, the given registry should be used. |
+| `module_name` | [string](/versions/9.0.0/rules/lib/core/string); required  The name of the Bazel module dependency to apply this override to. |
+| `versions` | Iterable of [string](/versions/9.0.0/rules/lib/core/string)s; required  Explicitly specifies the versions allowed to coexist. These versions must already be present in the dependency graph pre-selection. Dependencies on this module will be "upgraded" to the nearest higher allowed version at the same compatibility level, whereas dependencies that have a higher version than any allowed versions at the same compatibility level will cause an error. |
+| `registry` | [string](/versions/9.0.0/rules/lib/core/string); default is `''`  Overrides the registry for this module; instead of finding this module from the default list of registries, the given registry should be used. |
 
 ## override\_repo
 
@@ -226,8 +226,8 @@ Specifies already-defined execution platforms to be registered when this module
 
 | Parameter | Description |
 | --- | --- |
-| `dev_dependency` | [bool](../core/bool); default is `False`  If true, the execution platforms will not be registered if the current module is not the root module or `--ignore\_dev\_dependency` is enabled. |
-| `platform_labels` | [sequence](../core/list) of [string](../core/string)s; required  The target patterns to register. |
+| `dev_dependency` | [bool](/versions/9.0.0/rules/lib/core/bool); default is `False`  If true, the execution platforms will not be registered if the current module is not the root module or `--ignore\_dev\_dependency` is enabled. |
+| `platform_labels` | [sequence](/versions/9.0.0/rules/lib/core/list) of [string](/versions/9.0.0/rules/lib/core/string)s; required  The target patterns to register. |
 
 ## register\_toolchains
 
@@ -241,8 +241,8 @@ Specifies already-defined toolchains to be registered when this module is select
 
 | Parameter | Description |
 | --- | --- |
-| `dev_dependency` | [bool](../core/bool); default is `False`  If true, the toolchains will not be registered if the current module is not the root module or `--ignore\_dev\_dependency` is enabled. |
-| `toolchain_labels` | [sequence](../core/list) of [string](../core/string)s; required  The target patterns to register. |
+| `dev_dependency` | [bool](/versions/9.0.0/rules/lib/core/bool); default is `False`  If true, the toolchains will not be registered if the current module is not the root module or `--ignore\_dev\_dependency` is enabled. |
+| `toolchain_labels` | [sequence](/versions/9.0.0/rules/lib/core/list) of [string](/versions/9.0.0/rules/lib/core/string)s; required  The target patterns to register. |
 
 ## single\_version\_override
 
@@ -256,12 +256,12 @@ Specifies that a dependency should still come from a registry, but its version s
 
 | Parameter | Description |
 | --- | --- |
-| `module_name` | [string](../core/string); required  The name of the Bazel module dependency to apply this override to. |
-| `version` | [string](../core/string); default is `''`  Overrides the declared version of this module in the dependency graph. In other words, this module will be "pinned" to this override version. This attribute can be omitted if all one wants to override is the registry or the patches. |
-| `registry` | [string](../core/string); default is `''`  Overrides the registry for this module; instead of finding this module from the default list of registries, the given registry should be used. |
-| `patches` | Iterable of [string](../core/string)s; default is `[]`  A list of labels pointing to patch files to apply for this module. The patch files must exist in the source tree of the top level project. They are applied in the list order. If a patch makes changes to the MODULE.bazel file, these changes will only be effective if the patch file is provided by the root module. |
-| `patch_cmds` | Iterable of [string](../core/string)s; default is `[]`  Sequence of Bash commands to be applied on Linux/Macos after patches are applied. Changes to the MODULE.bazel file will not be effective. |
-| `patch_strip` | [int](../core/int); default is `0`  Same as the --strip argument of Unix patch. |
+| `module_name` | [string](/versions/9.0.0/rules/lib/core/string); required  The name of the Bazel module dependency to apply this override to. |
+| `version` | [string](/versions/9.0.0/rules/lib/core/string); default is `''`  Overrides the declared version of this module in the dependency graph. In other words, this module will be "pinned" to this override version. This attribute can be omitted if all one wants to override is the registry or the patches. |
+| `registry` | [string](/versions/9.0.0/rules/lib/core/string); default is `''`  Overrides the registry for this module; instead of finding this module from the default list of registries, the given registry should be used. |
+| `patches` | Iterable of [string](/versions/9.0.0/rules/lib/core/string)s; default is `[]`  A list of labels pointing to patch files to apply for this module. The patch files must exist in the source tree of the top level project. They are applied in the list order. If a patch makes changes to the MODULE.bazel file, these changes will only be effective if the patch file is provided by the root module. |
+| `patch_cmds` | Iterable of [string](/versions/9.0.0/rules/lib/core/string)s; default is `[]`  Sequence of Bash commands to be applied on Linux/Macos after patches are applied. Changes to the MODULE.bazel file will not be effective. |
+| `patch_strip` | [int](/versions/9.0.0/rules/lib/core/int); default is `0`  Same as the --strip argument of Unix patch. |
 
 ## use\_extension
 
@@ -275,10 +275,10 @@ Returns a proxy object representing a module extension; its methods can be invok
 
 | Parameter | Description |
 | --- | --- |
-| `extension_bzl_file` | [string](../core/string); required  A label to the Starlark file defining the module extension. |
-| `extension_name` | [string](../core/string); required  The name of the module extension to use. A symbol with this name must be exported by the Starlark file. |
-| `dev_dependency` | [bool](../core/bool); default is `False`  If true, this usage of the module extension will be ignored if the current module is not the root module or `--ignore\_dev\_dependency` is enabled. |
-| `isolate` | [bool](../core/bool); default is `False`  **Experimental**. This parameter is experimental and may change at any time. Please do not depend on it. It may be enabled on an experimental basis by setting `--experimental_isolated_extension_usages`  If true, this usage of the module extension will be isolated from all other usages, both in this and other modules. Tags created for this usage do not affect other usages and the repositories generated by the extension for this usage will be distinct from all other repositories generated by the extension. This parameter is currently experimental and only available with the flag `--experimental_isolated_extension_usages`. |
+| `extension_bzl_file` | [string](/versions/9.0.0/rules/lib/core/string); required  A label to the Starlark file defining the module extension. |
+| `extension_name` | [string](/versions/9.0.0/rules/lib/core/string); required  The name of the module extension to use. A symbol with this name must be exported by the Starlark file. |
+| `dev_dependency` | [bool](/versions/9.0.0/rules/lib/core/bool); default is `False`  If true, this usage of the module extension will be ignored if the current module is not the root module or `--ignore\_dev\_dependency` is enabled. |
+| `isolate` | [bool](/versions/9.0.0/rules/lib/core/bool); default is `False`  **Experimental**. This parameter is experimental and may change at any time. Please do not depend on it. It may be enabled on an experimental basis by setting `--experimental_isolated_extension_usages`  If true, this usage of the module extension will be isolated from all other usages, both in this and other modules. Tags created for this usage do not affect other usages and the repositories generated by the extension for this usage will be distinct from all other repositories generated by the extension. This parameter is currently experimental and only available with the flag `--experimental_isolated_extension_usages`. |
 
 ## use\_repo
 
@@ -308,5 +308,5 @@ Returns a proxy value that can be directly invoked in the MODULE.bazel file as a
 
 | Parameter | Description |
 | --- | --- |
-| `repo_rule_bzl_file` | [string](../core/string); required  A label to the Starlark file defining the repo rule. |
-| `repo_rule_name` | [string](../core/string); required  The name of the repo rule to use. A symbol with this name must be exported by the Starlark file. |
\ No newline at end of file
+| `repo_rule_bzl_file` | [string](/versions/9.0.0/rules/lib/core/string); required  A label to the Starlark file defining the repo rule. |
+| `repo_rule_name` | [string](/versions/9.0.0/rules/lib/core/string); required  The name of the repo rule to use. A symbol with this name must be exported by the Starlark file. |
\ No newline at end of file
diff --git a/versions/9.0.0/rules/lib/globals/repo.mdx b/versions/9.0.0/rules/lib/globals/repo.mdx
index 4a02faf2..eefedcce 100644
--- a/versions/9.0.0/rules/lib/globals/repo.mdx
+++ b/versions/9.0.0/rules/lib/globals/repo.mdx
@@ -23,7 +23,7 @@ This function takes a list of strings and a directory is ignored if any of the g
 
 | Parameter | Description |
 | --- | --- |
-| `dirs` | [sequence](../core/list) of [string](../core/string)s; required |
+| `dirs` | [sequence](/versions/9.0.0/rules/lib/core/list) of [string](/versions/9.0.0/rules/lib/core/string)s; required |
 
 ## repo
 
diff --git a/versions/9.0.0/rules/lib/providers/AnalysisTestResultInfo.mdx b/versions/9.0.0/rules/lib/providers/AnalysisTestResultInfo.mdx
index 1edabb04..1ae7fe82 100644
--- a/versions/9.0.0/rules/lib/providers/AnalysisTestResultInfo.mdx
+++ b/versions/9.0.0/rules/lib/providers/AnalysisTestResultInfo.mdx
@@ -22,8 +22,8 @@ The `AnalysisTestResultInfo` constructor.
 
 | Parameter | Description |
 | --- | --- |
-| `success` | [bool](../core/bool); required  If true, then the analysis-phase test represented by this target should pass. If false, the test should fail. |
-| `message` | [string](../core/string); required  A descriptive message containing information about the test and its success/failure. |
+| `success` | [bool](/versions/9.0.0/rules/lib/core/bool); required  If true, then the analysis-phase test represented by this target should pass. If false, the test should fail. |
+| `message` | [string](/versions/9.0.0/rules/lib/core/string); required  A descriptive message containing information about the test and its success/failure. |
 
 ## message
 
diff --git a/versions/9.0.0/rules/lib/providers/CcInfo.mdx b/versions/9.0.0/rules/lib/providers/CcInfo.mdx
index 407f2755..0c9aa6fe 100644
--- a/versions/9.0.0/rules/lib/providers/CcInfo.mdx
+++ b/versions/9.0.0/rules/lib/providers/CcInfo.mdx
@@ -22,9 +22,9 @@ The `CcInfo` constructor.
 
 | Parameter | Description |
 | --- | --- |
-| `compilation_context` | [CompilationContext](../builtins/CompilationContext); or `None`; default is `None`  The `CompilationContext`. |
-| `linking_context` | [struct](../builtins/struct); or `None`; default is `None`  The `LinkingContext`. |
-| `debug_context` | [struct](../builtins/struct); or `None`; default is `None`  The `DebugContext`. |
+| `compilation_context` | [CompilationContext](/versions/9.0.0/rules/lib/builtins/CompilationContext); or `None`; default is `None`  The `CompilationContext`. |
+| `linking_context` | [struct](/versions/9.0.0/rules/lib/builtins/struct); or `None`; default is `None`  The `LinkingContext`. |
+| `debug_context` | [struct](/versions/9.0.0/rules/lib/builtins/struct); or `None`; default is `None`  The `DebugContext`. |
 
 ## compilation\_context
 
diff --git a/versions/9.0.0/rules/lib/providers/DebugPackageInfo.mdx b/versions/9.0.0/rules/lib/providers/DebugPackageInfo.mdx
index b89dd0d2..1427b2dd 100644
--- a/versions/9.0.0/rules/lib/providers/DebugPackageInfo.mdx
+++ b/versions/9.0.0/rules/lib/providers/DebugPackageInfo.mdx
@@ -24,10 +24,10 @@ The `DebugPackageInfo` constructor.
 
 | Parameter | Description |
 | --- | --- |
-| `target_label` | [Label](../builtins/Label); required  The label for the \*\_binary target |
-| `stripped_file` | [File](../builtins/File); or `None`; default is `None`  The stripped file (the explicit ".stripped" target) |
-| `unstripped_file` | [File](../builtins/File); required  The unstripped file (the default executable target). |
-| `dwp_file` | [File](../builtins/File); or `None`; default is `None`  The .dwp file (for fission builds) or null if --fission=no. |
+| `target_label` | [Label](/versions/9.0.0/rules/lib/builtins/Label); required  The label for the \*\_binary target |
+| `stripped_file` | [File](/versions/9.0.0/rules/lib/builtins/File); or `None`; default is `None`  The stripped file (the explicit ".stripped" target) |
+| `unstripped_file` | [File](/versions/9.0.0/rules/lib/builtins/File); required  The unstripped file (the default executable target). |
+| `dwp_file` | [File](/versions/9.0.0/rules/lib/builtins/File); or `None`; default is `None`  The .dwp file (for fission builds) or null if --fission=no. |
 
 ## dwp\_file
 
diff --git a/versions/9.0.0/rules/lib/providers/DefaultInfo.mdx b/versions/9.0.0/rules/lib/providers/DefaultInfo.mdx
index d532fcd6..308562b3 100644
--- a/versions/9.0.0/rules/lib/providers/DefaultInfo.mdx
+++ b/versions/9.0.0/rules/lib/providers/DefaultInfo.mdx
@@ -26,11 +26,11 @@ The `DefaultInfo` constructor.
 
 | Parameter | Description |
 | --- | --- |
-| `files` | [depset](../builtins/depset); or `None`; default is `None`  A [`depset`](../builtins/depset) of [`File`](../builtins/File) objects representing the default outputs to build when this target is specified on the bazel command line. By default it is all predeclared outputs. |
-| `runfiles` | [runfiles](../builtins/runfiles); or `None`; default is `None`  [`runfiles`](../builtins/runfiles) descriptor describing the files that this target needs when run (e.g. via the `run` command or as a tool dependency for an action). |
-| `data_runfiles` | [runfiles](../builtins/runfiles); or `None`; default is `None`  **It is recommended that you avoid using this parameter (see ["runfiles features to avoid"](https://bazel.build/versions/9.0.0/extending/rules#runfiles_features_to_avoid))** runfiles descriptor describing the runfiles this target needs to run when it is a dependency via the `data` attribute. |
-| `default_runfiles` | [runfiles](../builtins/runfiles); or `None`; default is `None`  **It is recommended that you avoid using this parameter (see ["runfiles features to avoid"](https://bazel.build/versions/9.0.0/extending/rules#runfiles_features_to_avoid))** runfiles descriptor describing the runfiles this target needs to run when it is a dependency via any attribute other than the `data` attribute. |
-| `executable` | [File](../builtins/File); or `None`; default is `None`  If this rule is marked [`executable`](../globals/bzl#rule.executable) or [`test`](../globals/bzl#rule.test), this is a [`File`](../builtins/File) object representing the file that should be executed to run the target. By default it is the predeclared output `ctx.outputs.executable` but it is recommended to pass another file (either predeclared or not) explicitly. |
+| `files` | [depset](/versions/9.0.0/rules/lib/builtins/depset); or `None`; default is `None`  A [`depset`](/versions/9.0.0/rules/lib/builtins/depset) of [`File`](/versions/9.0.0/rules/lib/builtins/File) objects representing the default outputs to build when this target is specified on the bazel command line. By default it is all predeclared outputs. |
+| `runfiles` | [runfiles](/versions/9.0.0/rules/lib/builtins/runfiles); or `None`; default is `None`  [`runfiles`](/versions/9.0.0/rules/lib/builtins/runfiles) descriptor describing the files that this target needs when run (e.g. via the `run` command or as a tool dependency for an action). |
+| `data_runfiles` | [runfiles](/versions/9.0.0/rules/lib/builtins/runfiles); or `None`; default is `None`  **It is recommended that you avoid using this parameter (see ["runfiles features to avoid"](https://bazel.build/versions/9.0.0/extending/rules#runfiles_features_to_avoid))** runfiles descriptor describing the runfiles this target needs to run when it is a dependency via the `data` attribute. |
+| `default_runfiles` | [runfiles](/versions/9.0.0/rules/lib/builtins/runfiles); or `None`; default is `None`  **It is recommended that you avoid using this parameter (see ["runfiles features to avoid"](https://bazel.build/versions/9.0.0/extending/rules#runfiles_features_to_avoid))** runfiles descriptor describing the runfiles this target needs to run when it is a dependency via any attribute other than the `data` attribute. |
+| `executable` | [File](/versions/9.0.0/rules/lib/builtins/File); or `None`; default is `None`  If this rule is marked [`executable`](/versions/9.0.0/rules/lib/globals/bzl#rule.executable) or [`test`](/versions/9.0.0/rules/lib/globals/bzl#rule.test), this is a [`File`](/versions/9.0.0/rules/lib/builtins/File) object representing the file that should be executed to run the target. By default it is the predeclared output `ctx.outputs.executable` but it is recommended to pass another file (either predeclared or not) explicitly. |
 
 ## data\_runfiles
 
@@ -56,7 +56,7 @@ May return `None`.
 depset DefaultInfo.files
 ```
 
-A [`depset`](../builtins/depset) of [`File`](../builtins/File) objects representing the default outputs to build when this target is specified on the bazel command line. By default it is all predeclared outputs.
+A [`depset`](/versions/9.0.0/rules/lib/builtins/depset) of [`File`](/versions/9.0.0/rules/lib/builtins/File) objects representing the default outputs to build when this target is specified on the bazel command line. By default it is all predeclared outputs.
 May return `None`.
 
 ## files\_to\_run
@@ -65,5 +65,5 @@ May return `None`.
 FilesToRunProvider DefaultInfo.files_to_run
 ```
 
-A [`FilesToRunProvider`](../providers/FilesToRunProvider) object containing information about the executable and runfiles of the target.
+A [`FilesToRunProvider`](/versions/9.0.0/rules/lib/providers/FilesToRunProvider) object containing information about the executable and runfiles of the target.
 May return `None`.
\ No newline at end of file
diff --git a/versions/9.0.0/rules/lib/providers/ExecutionInfo.mdx b/versions/9.0.0/rules/lib/providers/ExecutionInfo.mdx
index d351095e..c9ebc4fb 100644
--- a/versions/9.0.0/rules/lib/providers/ExecutionInfo.mdx
+++ b/versions/9.0.0/rules/lib/providers/ExecutionInfo.mdx
@@ -22,8 +22,8 @@ Creates an instance.
 
 | Parameter | Description |
 | --- | --- |
-| `requirements` | [dict](../core/dict); default is `{}`  A dict indicating special execution requirements, such as hardware platforms. |
-| `exec_group` | [string](../core/string); default is `'test'`  The name of the exec group that is used to execute the test. |
+| `requirements` | [dict](/versions/9.0.0/rules/lib/core/dict); default is `{}`  A dict indicating special execution requirements, such as hardware platforms. |
+| `exec_group` | [string](/versions/9.0.0/rules/lib/core/string); default is `'test'`  The name of the exec group that is used to execute the test. |
 
 ## exec\_group
 
diff --git a/versions/9.0.0/rules/lib/providers/FeatureFlagInfo.mdx b/versions/9.0.0/rules/lib/providers/FeatureFlagInfo.mdx
index ebade07a..e4ba051e 100644
--- a/versions/9.0.0/rules/lib/providers/FeatureFlagInfo.mdx
+++ b/versions/9.0.0/rules/lib/providers/FeatureFlagInfo.mdx
@@ -31,7 +31,7 @@ The value of the flag in the configuration used by the flag rule.
 
 | Parameter | Description |
 | --- | --- |
-| `value` | [string](../core/string); required  String, the value to check for validity for this flag. |
+| `value` | [string](/versions/9.0.0/rules/lib/core/string); required  String, the value to check for validity for this flag. |
 
 ## value
 
diff --git a/versions/9.0.0/rules/lib/providers/FilesToRunProvider.mdx b/versions/9.0.0/rules/lib/providers/FilesToRunProvider.mdx
index cb4bbb70..f542ab21 100644
--- a/versions/9.0.0/rules/lib/providers/FilesToRunProvider.mdx
+++ b/versions/9.0.0/rules/lib/providers/FilesToRunProvider.mdx
@@ -2,7 +2,7 @@
 title: 'FilesToRunProvider'
 ---
 
-Contains information about executables produced by a target and the files needed to run it. This provider can not be created directly, it is an implicit output of executable targets accessible via [`DefaultInfo.files_to_run`](../providers/DefaultInfo#files_to_run).
+Contains information about executables produced by a target and the files needed to run it. This provider can not be created directly, it is an implicit output of executable targets accessible via [`DefaultInfo.files_to_run`](/versions/9.0.0/rules/lib/providers/DefaultInfo#files_to_run).
 
 ## Members
 
diff --git a/versions/9.0.0/rules/lib/providers/InstrumentedFilesInfo.mdx b/versions/9.0.0/rules/lib/providers/InstrumentedFilesInfo.mdx
index 4a3b7577..53cd7dbe 100644
--- a/versions/9.0.0/rules/lib/providers/InstrumentedFilesInfo.mdx
+++ b/versions/9.0.0/rules/lib/providers/InstrumentedFilesInfo.mdx
@@ -15,7 +15,7 @@ Contains information about source files and instrumentation metadata files for r
 depset InstrumentedFilesInfo.instrumented_files
 ```
 
-[`depset`](../builtins/depset) of [`File`](../builtins/File) objects representing instrumented source files for this target and its dependencies.
+[`depset`](/versions/9.0.0/rules/lib/builtins/depset) of [`File`](/versions/9.0.0/rules/lib/builtins/File) objects representing instrumented source files for this target and its dependencies.
 
 ## metadata\_files
 
@@ -23,4 +23,4 @@ depset InstrumentedFilesInfo.instrumented_files
 depset InstrumentedFilesInfo.metadata_files
 ```
 
-[`depset`](../builtins/depset) of [`File`](../builtins/File) objects representing coverage metadata files for this target and its dependencies. These files contain additional information required to generate LCOV-format coverage output after the code is executed, e.g. the `.gcno` files generated when `gcc` is run with `-ftest-coverage`.
\ No newline at end of file
+[`depset`](/versions/9.0.0/rules/lib/builtins/depset) of [`File`](/versions/9.0.0/rules/lib/builtins/File) objects representing coverage metadata files for this target and its dependencies. These files contain additional information required to generate LCOV-format coverage output after the code is executed, e.g. the `.gcno` files generated when `gcc` is run with `-ftest-coverage`.
\ No newline at end of file
diff --git a/versions/9.0.0/rules/lib/providers/PackageSpecificationInfo.mdx b/versions/9.0.0/rules/lib/providers/PackageSpecificationInfo.mdx
index 242a43e6..f9ecfddb 100644
--- a/versions/9.0.0/rules/lib/providers/PackageSpecificationInfo.mdx
+++ b/versions/9.0.0/rules/lib/providers/PackageSpecificationInfo.mdx
@@ -20,4 +20,4 @@ Checks if a target exists in a package group.
 
 | Parameter | Description |
 | --- | --- |
-| `target` | [Label](../builtins/Label); or [string](../core/string); required  A target which is checked if it exists inside the package group. |
\ No newline at end of file
+| `target` | [Label](/versions/9.0.0/rules/lib/builtins/Label); or [string](/versions/9.0.0/rules/lib/core/string); required  A target which is checked if it exists inside the package group. |
\ No newline at end of file
diff --git a/versions/9.0.0/rules/lib/repo/index.mdx b/versions/9.0.0/rules/lib/repo/index.mdx
index 8b364d2d..ef8715b9 100644
--- a/versions/9.0.0/rules/lib/repo/index.mdx
+++ b/versions/9.0.0/rules/lib/repo/index.mdx
@@ -2,10 +2,10 @@
 title: 'Repository Rules'
 ---
 
-* [Rules related to git](git)
-* [Rules related to http](http)
-* [Rules related to local directories](local)
+* [Rules related to git](/versions/9.0.0/rules/lib/repo/git)
+* [Rules related to http](/versions/9.0.0/rules/lib/repo/http)
+* [Rules related to local directories](/versions/9.0.0/rules/lib/repo/local)
 
 # Generic functions for repository rule authors
 
-* [Utility functions on patching](utils)
+* [Utility functions on patching](/versions/9.0.0/rules/lib/repo/utils)
diff --git a/versions/9.0.0/rules/lib/toplevel/apple_common.mdx b/versions/9.0.0/rules/lib/toplevel/apple_common.mdx
index f220a6f1..969538d4 100644
--- a/versions/9.0.0/rules/lib/toplevel/apple_common.mdx
+++ b/versions/9.0.0/rules/lib/toplevel/apple_common.mdx
@@ -21,7 +21,7 @@ Functions for Starlark to access internals of the apple rule implementations.
 dict apple_common.apple_host_system_env(xcode_config)
 ```
 
-Returns a [dict](../core/dict) of environment variables that should be set for actions that need to run build tools on an Apple host system, such as the version of Xcode that should be used. The keys are variable names and the values are their corresponding values.
+Returns a [dict](/versions/9.0.0/rules/lib/core/dict) of environment variables that should be set for actions that need to run build tools on an Apple host system, such as the version of Xcode that should be used. The keys are variable names and the values are their corresponding values.
 
 ### Parameters
 
@@ -43,13 +43,13 @@ Utilities for resolving items from the apple toolchain.
 DottedVersion apple_common.dotted_version(version)
 ```
 
-Creates a new [DottedVersion](../builtins/DottedVersion) instance.
+Creates a new [DottedVersion](/versions/9.0.0/rules/lib/builtins/DottedVersion) instance.
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `version` | [string](../core/string); required  The string representation of the DottedVersion. |
+| `version` | [string](/versions/9.0.0/rules/lib/core/string); required  The string representation of the DottedVersion. |
 
 ## platform
 
@@ -69,7 +69,7 @@ An enum-like struct that contains the following fields corresponding to Apple pl
 * `watchos_device`
 * `watchos_simulator`
 
-These values can be passed to methods that expect a platform, like [XcodeVersionConfig.sdk\_version\_for\_platform](../providers/XcodeVersionConfig#sdk_version_for_platform).
+These values can be passed to methods that expect a platform, like [XcodeVersionConfig.sdk\_version\_for\_platform](/versions/9.0.0/rules/lib/providers/XcodeVersionConfig#sdk_version_for_platform).
 
 ## platform\_type
 
diff --git a/versions/9.0.0/rules/lib/toplevel/attr.mdx b/versions/9.0.0/rules/lib/toplevel/attr.mdx
index cda46596..56ecc074 100644
--- a/versions/9.0.0/rules/lib/toplevel/attr.mdx
+++ b/versions/9.0.0/rules/lib/toplevel/attr.mdx
@@ -2,7 +2,7 @@
 title: 'attr'
 ---
 
-This is a top-level module for defining the attribute schemas of a rule or aspect. Each function returns an object representing the schema of a single attribute. These objects are used as the values of the `attrs` dictionary argument of [`rule()`](../globals/bzl#rule), [`aspect()`](../globals/bzl#aspect), [`repository_rule()`](../globals/bzl#repository_rule) and [`tag_class()`](../globals/bzl#tag_class).
+This is a top-level module for defining the attribute schemas of a rule or aspect. Each function returns an object representing the schema of a single attribute. These objects are used as the values of the `attrs` dictionary argument of [`rule()`](/versions/9.0.0/rules/lib/globals/bzl#rule), [`aspect()`](/versions/9.0.0/rules/lib/globals/bzl#aspect), [`repository_rule()`](/versions/9.0.0/rules/lib/globals/bzl#repository_rule) and [`tag_class()`](/versions/9.0.0/rules/lib/globals/bzl#tag_class).
 
 See the Rules page for more on [defining](https://bazel.build/versions/9.0.0/extending/rules#attributes)
 and [using](https://bazel.build/versions/9.0.0/extending/rules#implementation_function) attributes.
@@ -30,16 +30,16 @@ and [using](https://bazel.build/versions/9.0.0/extending/rules#implementation_fu
 Attribute attr.bool(*, configurable=unbound, default=False, doc=None, mandatory=False)
 ```
 
-Creates a schema for a boolean attribute. The corresponding [`ctx.attr`](../builtins/ctx#attr) attribute will be of type [`bool`](../core/bool).
+Creates a schema for a boolean attribute. The corresponding [`ctx.attr`](/versions/9.0.0/rules/lib/builtins/ctx#attr) attribute will be of type [`bool`](/versions/9.0.0/rules/lib/core/bool).
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `configurable` | [bool](../core/bool); or unbound; default is `unbound`  This argument can only be specified for an attribute of a symbolic macro. If `configurable` is explicitly set to `False`, the symbolic macro attribute is non-configurable - in other words, it cannot take a `select()` value. If the `configurable` is either unbound or explicitly set to `True`, the attribute is configurable and can take a `select()` value. For an attribute of a rule or aspect, `configurable` must be left unbound. Most Starlark rule attributes are always configurable, with the exception of `attr.output()`, `attr.output_list()`, and `attr.license()` rule attributes, which are always non-configurable. |
-| `default` | [bool](../core/bool); default is `False`  A default value to use if no value for this attribute is given when instantiating the rule. |
-| `doc` | [string](../core/string); or `None`; default is `None`  A description of the attribute that can be extracted by documentation generating tools. |
-| `mandatory` | [bool](../core/bool); default is `False`  If true, the value must be specified explicitly (even if it has a `default`). |
+| `configurable` | [bool](/versions/9.0.0/rules/lib/core/bool); or unbound; default is `unbound`  This argument can only be specified for an attribute of a symbolic macro. If `configurable` is explicitly set to `False`, the symbolic macro attribute is non-configurable - in other words, it cannot take a `select()` value. If the `configurable` is either unbound or explicitly set to `True`, the attribute is configurable and can take a `select()` value. For an attribute of a rule or aspect, `configurable` must be left unbound. Most Starlark rule attributes are always configurable, with the exception of `attr.output()`, `attr.output_list()`, and `attr.license()` rule attributes, which are always non-configurable. |
+| `default` | [bool](/versions/9.0.0/rules/lib/core/bool); default is `False`  A default value to use if no value for this attribute is given when instantiating the rule. |
+| `doc` | [string](/versions/9.0.0/rules/lib/core/string); or `None`; default is `None`  A description of the attribute that can be extracted by documentation generating tools. |
+| `mandatory` | [bool](/versions/9.0.0/rules/lib/core/bool); default is `False`  If true, the value must be specified explicitly (even if it has a `default`). |
 
 ## int
 
@@ -47,17 +47,17 @@ Creates a schema for a boolean attribute. The corresponding [`ctx.attr`](../buil
 Attribute attr.int(*, configurable=unbound, default=0, doc=None, mandatory=False, values=[])
 ```
 
-Creates a schema for an integer attribute. The value must be in the signed 32-bit range. The corresponding [`ctx.attr`](../builtins/ctx#attr) attribute will be of type [`int`](../core/int).
+Creates a schema for an integer attribute. The value must be in the signed 32-bit range. The corresponding [`ctx.attr`](/versions/9.0.0/rules/lib/builtins/ctx#attr) attribute will be of type [`int`](/versions/9.0.0/rules/lib/core/int).
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `configurable` | [bool](../core/bool); or unbound; default is `unbound`  This argument can only be specified for an attribute of a symbolic macro. If `configurable` is explicitly set to `False`, the symbolic macro attribute is non-configurable - in other words, it cannot take a `select()` value. If the `configurable` is either unbound or explicitly set to `True`, the attribute is configurable and can take a `select()` value. For an attribute of a rule or aspect, `configurable` must be left unbound. Most Starlark rule attributes are always configurable, with the exception of `attr.output()`, `attr.output_list()`, and `attr.license()` rule attributes, which are always non-configurable. |
-| `default` | [int](../core/int); default is `0`  A default value to use if no value for this attribute is given when instantiating the rule. |
-| `doc` | [string](../core/string); or `None`; default is `None`  A description of the attribute that can be extracted by documentation generating tools. |
-| `mandatory` | [bool](../core/bool); default is `False`  If true, the value must be specified explicitly (even if it has a `default`). |
-| `values` | [sequence](../core/list) of [int](../core/int)s; default is `[]`  The list of allowed values for the attribute. An error is raised if any other value is given. |
+| `configurable` | [bool](/versions/9.0.0/rules/lib/core/bool); or unbound; default is `unbound`  This argument can only be specified for an attribute of a symbolic macro. If `configurable` is explicitly set to `False`, the symbolic macro attribute is non-configurable - in other words, it cannot take a `select()` value. If the `configurable` is either unbound or explicitly set to `True`, the attribute is configurable and can take a `select()` value. For an attribute of a rule or aspect, `configurable` must be left unbound. Most Starlark rule attributes are always configurable, with the exception of `attr.output()`, `attr.output_list()`, and `attr.license()` rule attributes, which are always non-configurable. |
+| `default` | [int](/versions/9.0.0/rules/lib/core/int); default is `0`  A default value to use if no value for this attribute is given when instantiating the rule. |
+| `doc` | [string](/versions/9.0.0/rules/lib/core/string); or `None`; default is `None`  A description of the attribute that can be extracted by documentation generating tools. |
+| `mandatory` | [bool](/versions/9.0.0/rules/lib/core/bool); default is `False`  If true, the value must be specified explicitly (even if it has a `default`). |
+| `values` | [sequence](/versions/9.0.0/rules/lib/core/list) of [int](/versions/9.0.0/rules/lib/core/int)s; default is `[]`  The list of allowed values for the attribute. An error is raised if any other value is given. |
 
 ## int\_list
 
@@ -71,11 +71,11 @@ Creates a schema for a list-of-integers attribute. Each element must be in the s
 
 | Parameter | Description |
 | --- | --- |
-| `mandatory` | [bool](../core/bool); default is `False`  If true, the value must be specified explicitly (even if it has a `default`). |
-| `allow_empty` | [bool](../core/bool); default is `True`  True if the attribute can be empty. |
-| `configurable` | [bool](../core/bool); or unbound; default is `unbound`  This argument can only be specified for an attribute of a symbolic macro. If `configurable` is explicitly set to `False`, the symbolic macro attribute is non-configurable - in other words, it cannot take a `select()` value. If the `configurable` is either unbound or explicitly set to `True`, the attribute is configurable and can take a `select()` value. For an attribute of a rule or aspect, `configurable` must be left unbound. Most Starlark rule attributes are always configurable, with the exception of `attr.output()`, `attr.output_list()`, and `attr.license()` rule attributes, which are always non-configurable. |
-| `default` | [sequence](../core/list) of [int](../core/int)s; default is `[]`  A default value to use if no value for this attribute is given when instantiating the rule. |
-| `doc` | [string](../core/string); or `None`; default is `None`  A description of the attribute that can be extracted by documentation generating tools. |
+| `mandatory` | [bool](/versions/9.0.0/rules/lib/core/bool); default is `False`  If true, the value must be specified explicitly (even if it has a `default`). |
+| `allow_empty` | [bool](/versions/9.0.0/rules/lib/core/bool); default is `True`  True if the attribute can be empty. |
+| `configurable` | [bool](/versions/9.0.0/rules/lib/core/bool); or unbound; default is `unbound`  This argument can only be specified for an attribute of a symbolic macro. If `configurable` is explicitly set to `False`, the symbolic macro attribute is non-configurable - in other words, it cannot take a `select()` value. If the `configurable` is either unbound or explicitly set to `True`, the attribute is configurable and can take a `select()` value. For an attribute of a rule or aspect, `configurable` must be left unbound. Most Starlark rule attributes are always configurable, with the exception of `attr.output()`, `attr.output_list()`, and `attr.license()` rule attributes, which are always non-configurable. |
+| `default` | [sequence](/versions/9.0.0/rules/lib/core/list) of [int](/versions/9.0.0/rules/lib/core/int)s; default is `[]`  A default value to use if no value for this attribute is given when instantiating the rule. |
+| `doc` | [string](/versions/9.0.0/rules/lib/core/string); or `None`; default is `None`  A description of the attribute that can be extracted by documentation generating tools. |
 
 ## label
 
@@ -85,9 +85,9 @@ Attribute attr.label(*, configurable=unbound, default=None, materializer=None, d
 
 Creates a schema for a label attribute. This is a dependency attribute.
 
-This attribute contains unique [`Label`](../builtins/Label) values. If a string is supplied in place of a `Label`, it will be converted using the [label constructor](../builtins/Label#Label). The relative parts of the label path, including the (possibly renamed) repository, are resolved with respect to the instantiated target's package.
+This attribute contains unique [`Label`](/versions/9.0.0/rules/lib/builtins/Label) values. If a string is supplied in place of a `Label`, it will be converted using the [label constructor](/versions/9.0.0/rules/lib/builtins/Label#Label). The relative parts of the label path, including the (possibly renamed) repository, are resolved with respect to the instantiated target's package.
 
-At analysis time (within the rule's implementation function), when retrieving the attribute value from `ctx.attr`, labels are replaced by the corresponding [`Target`](../builtins/Target)s. This allows you to access the providers of the current target's dependencies.
+At analysis time (within the rule's implementation function), when retrieving the attribute value from `ctx.attr`, labels are replaced by the corresponding [`Target`](/versions/9.0.0/rules/lib/builtins/Target)s. This allows you to access the providers of the current target's dependencies.
 
 In addition to ordinary source files, this kind of attribute is often used to refer to a tool -- for example, a compiler. Such tools are considered to be dependencies, just like source files. To avoid requiring users to specify the tool's label every time they use the rule in their BUILD files, you can hard-code the label of a canonical tool as the `default` value of this attribute. If you also want to prevent users from overriding this default, you can make the attribute private by giving it a name that starts with an underscore. See the [Rules](https://bazel.build/versions/9.0.0/extending/rules#private-attributes) page for more information.
 
@@ -95,21 +95,21 @@ In addition to ordinary source files, this kind of attribute is often used to re
 
 | Parameter | Description |
 | --- | --- |
-| `configurable` | [bool](../core/bool); or unbound; default is `unbound`  This argument can only be specified for an attribute of a symbolic macro. If `configurable` is explicitly set to `False`, the symbolic macro attribute is non-configurable - in other words, it cannot take a `select()` value. If the `configurable` is either unbound or explicitly set to `True`, the attribute is configurable and can take a `select()` value. For an attribute of a rule or aspect, `configurable` must be left unbound. Most Starlark rule attributes are always configurable, with the exception of `attr.output()`, `attr.output_list()`, and `attr.license()` rule attributes, which are always non-configurable. |
-| `default` | [Label](../builtins/Label); or [string](../core/string); or [LateBoundDefault](../builtins/LateBoundDefault); or NativeComputedDefault; or [function](../core/function); or `None`; default is `None`  A default value to use if no value for this attribute is given when instantiating the rule.Use a string or the [`Label`](../builtins/Label#Label) function to specify a default value, for example, `attr.label(default = "//a:b")`. |
-| `materializer` | [function](../core/function); default is `None`  **Experimental**. This parameter is experimental and may change at any time. Please do not depend on it. It may be enabled on an experimental basis by setting `--experimental_dormant_deps`  If set, the attribute materializes dormant dependencies from the transitive closure. The value of this parameter must be a functon that gets access to the values of the attributes of the rule that either are not dependencies or are marked as available for dependency resolution. It must return either a dormant dependency or a list of them depending on the type of the attribute |
-| `doc` | [string](../core/string); or `None`; default is `None` |
-| `executable` | [bool](../core/bool); default is `False`  True if the dependency has to be executable. This means the label must refer to an executable file, or to a rule that outputs an executable file. Access the label with `ctx.executable.`. |
-| `allow_files` | [bool](../core/bool); or [sequence](../core/list) of [string](../core/string)s; or `None`; default is `None`  Whether `File` targets are allowed. Can be `True`, `False` (default), or a list of file extensions that are allowed (for example, `[".cc", ".cpp"]`). |
-| `allow_single_file` | default is `None`  This is similar to `allow_files`, with the restriction that the label must correspond to a single [File](../builtins/File). Access it through `ctx.file.`. |
-| `mandatory` | [bool](../core/bool); default is `False`  If true, the value must be specified explicitly (even if it has a `default`). |
-| `skip_validations` | [bool](../core/bool); default is `False`  If true, validation actions of transitive dependencies from this attribute will not run. This is a temporary mitigation and WILL be removed in the future. |
-| `providers` | [sequence](../core/list); default is `[]`  The providers that must be given by any dependency appearing in this attribute. The format of this argument is a list of lists of providers -- `*Info` objects returned by [`provider()`](../globals/bzl#provider) (or in the case of a legacy provider, its string name). The dependency must return ALL providers mentioned in at least ONE of the inner lists. As a convenience, this argument may also be a single-level list of providers, in which case it is wrapped in an outer list with one element (i.e. `[A, B]` means `[[A, B]]`). It is NOT required that the rule of the dependency advertises those providers in its `provides` parameter, however, it is considered best practice. |
+| `configurable` | [bool](/versions/9.0.0/rules/lib/core/bool); or unbound; default is `unbound`  This argument can only be specified for an attribute of a symbolic macro. If `configurable` is explicitly set to `False`, the symbolic macro attribute is non-configurable - in other words, it cannot take a `select()` value. If the `configurable` is either unbound or explicitly set to `True`, the attribute is configurable and can take a `select()` value. For an attribute of a rule or aspect, `configurable` must be left unbound. Most Starlark rule attributes are always configurable, with the exception of `attr.output()`, `attr.output_list()`, and `attr.license()` rule attributes, which are always non-configurable. |
+| `default` | [Label](/versions/9.0.0/rules/lib/builtins/Label); or [string](/versions/9.0.0/rules/lib/core/string); or [LateBoundDefault](/versions/9.0.0/rules/lib/builtins/LateBoundDefault); or NativeComputedDefault; or [function](/versions/9.0.0/rules/lib/core/function); or `None`; default is `None`  A default value to use if no value for this attribute is given when instantiating the rule.Use a string or the [`Label`](/versions/9.0.0/rules/lib/builtins/Label#Label) function to specify a default value, for example, `attr.label(default = "//a:b")`. |
+| `materializer` | [function](/versions/9.0.0/rules/lib/core/function); default is `None`  **Experimental**. This parameter is experimental and may change at any time. Please do not depend on it. It may be enabled on an experimental basis by setting `--experimental_dormant_deps`  If set, the attribute materializes dormant dependencies from the transitive closure. The value of this parameter must be a functon that gets access to the values of the attributes of the rule that either are not dependencies or are marked as available for dependency resolution. It must return either a dormant dependency or a list of them depending on the type of the attribute |
+| `doc` | [string](/versions/9.0.0/rules/lib/core/string); or `None`; default is `None` |
+| `executable` | [bool](/versions/9.0.0/rules/lib/core/bool); default is `False`  True if the dependency has to be executable. This means the label must refer to an executable file, or to a rule that outputs an executable file. Access the label with `ctx.executable.`. |
+| `allow_files` | [bool](/versions/9.0.0/rules/lib/core/bool); or [sequence](/versions/9.0.0/rules/lib/core/list) of [string](/versions/9.0.0/rules/lib/core/string)s; or `None`; default is `None`  Whether `File` targets are allowed. Can be `True`, `False` (default), or a list of file extensions that are allowed (for example, `[".cc", ".cpp"]`). |
+| `allow_single_file` | default is `None`  This is similar to `allow_files`, with the restriction that the label must correspond to a single [File](/versions/9.0.0/rules/lib/builtins/File). Access it through `ctx.file.`. |
+| `mandatory` | [bool](/versions/9.0.0/rules/lib/core/bool); default is `False`  If true, the value must be specified explicitly (even if it has a `default`). |
+| `skip_validations` | [bool](/versions/9.0.0/rules/lib/core/bool); default is `False`  If true, validation actions of transitive dependencies from this attribute will not run. This is a temporary mitigation and WILL be removed in the future. |
+| `providers` | [sequence](/versions/9.0.0/rules/lib/core/list); default is `[]`  The providers that must be given by any dependency appearing in this attribute. The format of this argument is a list of lists of providers -- `*Info` objects returned by [`provider()`](/versions/9.0.0/rules/lib/globals/bzl#provider) (or in the case of a legacy provider, its string name). The dependency must return ALL providers mentioned in at least ONE of the inner lists. As a convenience, this argument may also be a single-level list of providers, in which case it is wrapped in an outer list with one element (i.e. `[A, B]` means `[[A, B]]`). It is NOT required that the rule of the dependency advertises those providers in its `provides` parameter, however, it is considered best practice. |
 | `for_dependency_resolution` | default is `unbound`  If this is set, the attribute is available for materializers. Only rules marked with the flag of the same name are allowed to be referenced through such attributes. |
-| `allow_rules` | [sequence](../core/list) of [string](../core/string)s; or `None`; default is `None`  Which rule targets (name of the classes) are allowed. This is deprecated (kept only for compatibility), use providers instead. |
+| `allow_rules` | [sequence](/versions/9.0.0/rules/lib/core/list) of [string](/versions/9.0.0/rules/lib/core/string)s; or `None`; default is `None`  Which rule targets (name of the classes) are allowed. This is deprecated (kept only for compatibility), use providers instead. |
 | `cfg` | default is `None`  [Configuration](https://bazel.build/versions/9.0.0/extending/rules#configurations) of the attribute. It can be either `"exec"`, which indicates that the dependency is built for the `execution platform`, or `"target"`, which indicates that the dependency is build for the `target platform`. A typical example of the difference is when building mobile apps, where the `target platform` is `Android` or `iOS` while the `execution platform` is `Linux`, `macOS`, or `Windows`. This parameter is required if `executable` is True to guard against accidentally building host tools in the target configuration. `"target"` has no semantic effect, so don't set it when `executable` is False unless it really helps clarify your intentions. |
-| `aspects` | [sequence](../core/list) of [Aspect](../builtins/Aspect)s; default is `[]`  Aspects that should be applied to the dependency or dependencies specified by this attribute. |
-| `flags` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  Deprecated, will be removed. |
+| `aspects` | [sequence](/versions/9.0.0/rules/lib/core/list) of [Aspect](/versions/9.0.0/rules/lib/builtins/Aspect)s; default is `[]`  Aspects that should be applied to the dependency or dependencies specified by this attribute. |
+| `flags` | [sequence](/versions/9.0.0/rules/lib/core/list) of [string](/versions/9.0.0/rules/lib/core/string)s; default is `[]`  Deprecated, will be removed. |
 
 ## label\_keyed\_string\_dict
 
@@ -119,27 +119,27 @@ Attribute attr.label_keyed_string_dict(allow_empty=True, *, configurable=unbound
 
 Creates a schema for an attribute holding a dictionary, where the keys are labels and the values are strings. This is a dependency attribute.
 
-This attribute contains unique [`Label`](../builtins/Label) values. If a string is supplied in place of a `Label`, it will be converted using the [label constructor](../builtins/Label#Label). The relative parts of the label path, including the (possibly renamed) repository, are resolved with respect to the instantiated target's package.
+This attribute contains unique [`Label`](/versions/9.0.0/rules/lib/builtins/Label) values. If a string is supplied in place of a `Label`, it will be converted using the [label constructor](/versions/9.0.0/rules/lib/builtins/Label#Label). The relative parts of the label path, including the (possibly renamed) repository, are resolved with respect to the instantiated target's package.
 
-At analysis time (within the rule's implementation function), when retrieving the attribute value from `ctx.attr`, labels are replaced by the corresponding [`Target`](../builtins/Target)s. This allows you to access the providers of the current target's dependencies.
+At analysis time (within the rule's implementation function), when retrieving the attribute value from `ctx.attr`, labels are replaced by the corresponding [`Target`](/versions/9.0.0/rules/lib/builtins/Target)s. This allows you to access the providers of the current target's dependencies.
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `allow_empty` | [bool](../core/bool); default is `True`  True if the attribute can be empty. |
-| `configurable` | [bool](../core/bool); or unbound; default is `unbound`  This argument can only be specified for an attribute of a symbolic macro. If `configurable` is explicitly set to `False`, the symbolic macro attribute is non-configurable - in other words, it cannot take a `select()` value. If the `configurable` is either unbound or explicitly set to `True`, the attribute is configurable and can take a `select()` value. For an attribute of a rule or aspect, `configurable` must be left unbound. Most Starlark rule attributes are always configurable, with the exception of `attr.output()`, `attr.output_list()`, and `attr.license()` rule attributes, which are always non-configurable. |
-| `default` | [dict](../core/dict); or [function](../core/function); default is `{}`  A default value to use if no value for this attribute is given when instantiating the rule.Use strings or the [`Label`](../builtins/Label#Label) function to specify default values, for example, `attr.label_keyed_string_dict(default = {"//a:b": "value", "//a:c": "string"})`. |
-| `doc` | [string](../core/string); or `None`; default is `None`  A description of the attribute that can be extracted by documentation generating tools. |
-| `allow_files` | [bool](../core/bool); or [sequence](../core/list) of [string](../core/string)s; or `None`; default is `None`  Whether `File` targets are allowed. Can be `True`, `False` (default), or a list of file extensions that are allowed (for example, `[".cc", ".cpp"]`). |
-| `allow_rules` | [sequence](../core/list) of [string](../core/string)s; or `None`; default is `None`  Which rule targets (name of the classes) are allowed. This is deprecated (kept only for compatibility), use providers instead. |
-| `providers` | [sequence](../core/list); default is `[]`  The providers that must be given by any dependency appearing in this attribute. The format of this argument is a list of lists of providers -- `*Info` objects returned by [`provider()`](../globals/bzl#provider) (or in the case of a legacy provider, its string name). The dependency must return ALL providers mentioned in at least ONE of the inner lists. As a convenience, this argument may also be a single-level list of providers, in which case it is wrapped in an outer list with one element (i.e. `[A, B]` means `[[A, B]]`). It is NOT required that the rule of the dependency advertises those providers in its `provides` parameter, however, it is considered best practice. |
+| `allow_empty` | [bool](/versions/9.0.0/rules/lib/core/bool); default is `True`  True if the attribute can be empty. |
+| `configurable` | [bool](/versions/9.0.0/rules/lib/core/bool); or unbound; default is `unbound`  This argument can only be specified for an attribute of a symbolic macro. If `configurable` is explicitly set to `False`, the symbolic macro attribute is non-configurable - in other words, it cannot take a `select()` value. If the `configurable` is either unbound or explicitly set to `True`, the attribute is configurable and can take a `select()` value. For an attribute of a rule or aspect, `configurable` must be left unbound. Most Starlark rule attributes are always configurable, with the exception of `attr.output()`, `attr.output_list()`, and `attr.license()` rule attributes, which are always non-configurable. |
+| `default` | [dict](/versions/9.0.0/rules/lib/core/dict); or [function](/versions/9.0.0/rules/lib/core/function); default is `{}`  A default value to use if no value for this attribute is given when instantiating the rule.Use strings or the [`Label`](/versions/9.0.0/rules/lib/builtins/Label#Label) function to specify default values, for example, `attr.label_keyed_string_dict(default = {"//a:b": "value", "//a:c": "string"})`. |
+| `doc` | [string](/versions/9.0.0/rules/lib/core/string); or `None`; default is `None`  A description of the attribute that can be extracted by documentation generating tools. |
+| `allow_files` | [bool](/versions/9.0.0/rules/lib/core/bool); or [sequence](/versions/9.0.0/rules/lib/core/list) of [string](/versions/9.0.0/rules/lib/core/string)s; or `None`; default is `None`  Whether `File` targets are allowed. Can be `True`, `False` (default), or a list of file extensions that are allowed (for example, `[".cc", ".cpp"]`). |
+| `allow_rules` | [sequence](/versions/9.0.0/rules/lib/core/list) of [string](/versions/9.0.0/rules/lib/core/string)s; or `None`; default is `None`  Which rule targets (name of the classes) are allowed. This is deprecated (kept only for compatibility), use providers instead. |
+| `providers` | [sequence](/versions/9.0.0/rules/lib/core/list); default is `[]`  The providers that must be given by any dependency appearing in this attribute. The format of this argument is a list of lists of providers -- `*Info` objects returned by [`provider()`](/versions/9.0.0/rules/lib/globals/bzl#provider) (or in the case of a legacy provider, its string name). The dependency must return ALL providers mentioned in at least ONE of the inner lists. As a convenience, this argument may also be a single-level list of providers, in which case it is wrapped in an outer list with one element (i.e. `[A, B]` means `[[A, B]]`). It is NOT required that the rule of the dependency advertises those providers in its `provides` parameter, however, it is considered best practice. |
 | `for_dependency_resolution` | default is `unbound`  If this is set, the attribute is available for materializers. Only rules marked with the flag of the same name are allowed to be referenced through such attributes. |
-| `flags` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  Deprecated, will be removed. |
-| `mandatory` | [bool](../core/bool); default is `False`  If true, the value must be specified explicitly (even if it has a `default`). |
-| `skip_validations` | [bool](../core/bool); default is `False`  If true, validation actions of transitive dependencies from this attribute will not run. This is a temporary mitigation and WILL be removed in the future. |
+| `flags` | [sequence](/versions/9.0.0/rules/lib/core/list) of [string](/versions/9.0.0/rules/lib/core/string)s; default is `[]`  Deprecated, will be removed. |
+| `mandatory` | [bool](/versions/9.0.0/rules/lib/core/bool); default is `False`  If true, the value must be specified explicitly (even if it has a `default`). |
+| `skip_validations` | [bool](/versions/9.0.0/rules/lib/core/bool); default is `False`  If true, validation actions of transitive dependencies from this attribute will not run. This is a temporary mitigation and WILL be removed in the future. |
 | `cfg` | default is `None`  [Configuration](https://bazel.build/versions/9.0.0/extending/rules#configurations) of the attribute. It can be either `"exec"`, which indicates that the dependency is built for the `execution platform`, or `"target"`, which indicates that the dependency is build for the `target platform`. A typical example of the difference is when building mobile apps, where the `target platform` is `Android` or `iOS` while the `execution platform` is `Linux`, `macOS`, or `Windows`. |
-| `aspects` | [sequence](../core/list) of [Aspect](../builtins/Aspect)s; default is `[]`  Aspects that should be applied to the dependency or dependencies specified by this attribute. |
+| `aspects` | [sequence](/versions/9.0.0/rules/lib/core/list) of [Aspect](/versions/9.0.0/rules/lib/builtins/Aspect)s; default is `[]`  Aspects that should be applied to the dependency or dependencies specified by this attribute. |
 
 ## label\_list
 
@@ -147,30 +147,30 @@ At analysis time (within the rule's implementation function), when retrieving th
 Attribute attr.label_list(allow_empty=True, *, configurable=unbound, default=[], materializer=None, doc=None, allow_files=None, allow_rules=None, providers=[], for_dependency_resolution=unbound, flags=[], mandatory=False, skip_validations=False, cfg=None, aspects=[])
 ```
 
-Creates a schema for a list-of-labels attribute. This is a dependency attribute. The corresponding [`ctx.attr`](../builtins/ctx#attr) attribute will be of type [list](../core/list) of [`Target`s](../builtins/Target).
+Creates a schema for a list-of-labels attribute. This is a dependency attribute. The corresponding [`ctx.attr`](/versions/9.0.0/rules/lib/builtins/ctx#attr) attribute will be of type [list](/versions/9.0.0/rules/lib/core/list) of [`Target`s](/versions/9.0.0/rules/lib/builtins/Target).
 
-This attribute contains unique [`Label`](../builtins/Label) values. If a string is supplied in place of a `Label`, it will be converted using the [label constructor](../builtins/Label#Label). The relative parts of the label path, including the (possibly renamed) repository, are resolved with respect to the instantiated target's package.
+This attribute contains unique [`Label`](/versions/9.0.0/rules/lib/builtins/Label) values. If a string is supplied in place of a `Label`, it will be converted using the [label constructor](/versions/9.0.0/rules/lib/builtins/Label#Label). The relative parts of the label path, including the (possibly renamed) repository, are resolved with respect to the instantiated target's package.
 
-At analysis time (within the rule's implementation function), when retrieving the attribute value from `ctx.attr`, labels are replaced by the corresponding [`Target`](../builtins/Target)s. This allows you to access the providers of the current target's dependencies.
+At analysis time (within the rule's implementation function), when retrieving the attribute value from `ctx.attr`, labels are replaced by the corresponding [`Target`](/versions/9.0.0/rules/lib/builtins/Target)s. This allows you to access the providers of the current target's dependencies.
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `allow_empty` | [bool](../core/bool); default is `True`  True if the attribute can be empty. |
-| `configurable` | [bool](../core/bool); or unbound; default is `unbound`  This argument can only be specified for an attribute of a symbolic macro. If `configurable` is explicitly set to `False`, the symbolic macro attribute is non-configurable - in other words, it cannot take a `select()` value. If the `configurable` is either unbound or explicitly set to `True`, the attribute is configurable and can take a `select()` value. For an attribute of a rule or aspect, `configurable` must be left unbound. Most Starlark rule attributes are always configurable, with the exception of `attr.output()`, `attr.output_list()`, and `attr.license()` rule attributes, which are always non-configurable. |
-| `default` | [sequence](../core/list) of [Label](../builtins/Label)s; or [function](../core/function); default is `[]`  A default value to use if no value for this attribute is given when instantiating the rule.Use strings or the [`Label`](../builtins/Label#Label) function to specify default values, for example, `attr.label_list(default = ["//a:b", "//a:c"])`. |
-| `materializer` | [function](../core/function); default is `None`  **Experimental**. This parameter is experimental and may change at any time. Please do not depend on it. It may be enabled on an experimental basis by setting `--experimental_dormant_deps`  If set, the attribute materializes dormant dependencies from the transitive closure. The value of this parameter must be a functon that gets access to the values of the attributes of the rule that either are not dependencies or are marked as available for dependency resolution. It must return either a dormant dependency or a list of them depending on the type of the attribute |
-| `doc` | [string](../core/string); or `None`; default is `None` |
-| `allow_files` | [bool](../core/bool); or [sequence](../core/list) of [string](../core/string)s; or `None`; default is `None`  Whether `File` targets are allowed. Can be `True`, `False` (default), or a list of file extensions that are allowed (for example, `[".cc", ".cpp"]`). |
-| `allow_rules` | [sequence](../core/list) of [string](../core/string)s; or `None`; default is `None`  Which rule targets (name of the classes) are allowed. This is deprecated (kept only for compatibility), use providers instead. |
-| `providers` | [sequence](../core/list); default is `[]`  The providers that must be given by any dependency appearing in this attribute. The format of this argument is a list of lists of providers -- `*Info` objects returned by [`provider()`](../globals/bzl#provider) (or in the case of a legacy provider, its string name). The dependency must return ALL providers mentioned in at least ONE of the inner lists. As a convenience, this argument may also be a single-level list of providers, in which case it is wrapped in an outer list with one element (i.e. `[A, B]` means `[[A, B]]`). It is NOT required that the rule of the dependency advertises those providers in its `provides` parameter, however, it is considered best practice. |
+| `allow_empty` | [bool](/versions/9.0.0/rules/lib/core/bool); default is `True`  True if the attribute can be empty. |
+| `configurable` | [bool](/versions/9.0.0/rules/lib/core/bool); or unbound; default is `unbound`  This argument can only be specified for an attribute of a symbolic macro. If `configurable` is explicitly set to `False`, the symbolic macro attribute is non-configurable - in other words, it cannot take a `select()` value. If the `configurable` is either unbound or explicitly set to `True`, the attribute is configurable and can take a `select()` value. For an attribute of a rule or aspect, `configurable` must be left unbound. Most Starlark rule attributes are always configurable, with the exception of `attr.output()`, `attr.output_list()`, and `attr.license()` rule attributes, which are always non-configurable. |
+| `default` | [sequence](/versions/9.0.0/rules/lib/core/list) of [Label](/versions/9.0.0/rules/lib/builtins/Label)s; or [function](/versions/9.0.0/rules/lib/core/function); default is `[]`  A default value to use if no value for this attribute is given when instantiating the rule.Use strings or the [`Label`](/versions/9.0.0/rules/lib/builtins/Label#Label) function to specify default values, for example, `attr.label_list(default = ["//a:b", "//a:c"])`. |
+| `materializer` | [function](/versions/9.0.0/rules/lib/core/function); default is `None`  **Experimental**. This parameter is experimental and may change at any time. Please do not depend on it. It may be enabled on an experimental basis by setting `--experimental_dormant_deps`  If set, the attribute materializes dormant dependencies from the transitive closure. The value of this parameter must be a functon that gets access to the values of the attributes of the rule that either are not dependencies or are marked as available for dependency resolution. It must return either a dormant dependency or a list of them depending on the type of the attribute |
+| `doc` | [string](/versions/9.0.0/rules/lib/core/string); or `None`; default is `None` |
+| `allow_files` | [bool](/versions/9.0.0/rules/lib/core/bool); or [sequence](/versions/9.0.0/rules/lib/core/list) of [string](/versions/9.0.0/rules/lib/core/string)s; or `None`; default is `None`  Whether `File` targets are allowed. Can be `True`, `False` (default), or a list of file extensions that are allowed (for example, `[".cc", ".cpp"]`). |
+| `allow_rules` | [sequence](/versions/9.0.0/rules/lib/core/list) of [string](/versions/9.0.0/rules/lib/core/string)s; or `None`; default is `None`  Which rule targets (name of the classes) are allowed. This is deprecated (kept only for compatibility), use providers instead. |
+| `providers` | [sequence](/versions/9.0.0/rules/lib/core/list); default is `[]`  The providers that must be given by any dependency appearing in this attribute. The format of this argument is a list of lists of providers -- `*Info` objects returned by [`provider()`](/versions/9.0.0/rules/lib/globals/bzl#provider) (or in the case of a legacy provider, its string name). The dependency must return ALL providers mentioned in at least ONE of the inner lists. As a convenience, this argument may also be a single-level list of providers, in which case it is wrapped in an outer list with one element (i.e. `[A, B]` means `[[A, B]]`). It is NOT required that the rule of the dependency advertises those providers in its `provides` parameter, however, it is considered best practice. |
 | `for_dependency_resolution` | default is `unbound`  If this is set, the attribute is available for materializers. Only rules marked with the flag of the same name are allowed to be referenced through such attributes. |
-| `flags` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  Deprecated, will be removed. |
-| `mandatory` | [bool](../core/bool); default is `False`  If true, the value must be specified explicitly (even if it has a `default`). |
-| `skip_validations` | [bool](../core/bool); default is `False`  If true, validation actions of transitive dependencies from this attribute will not run. This is a temporary mitigation and WILL be removed in the future. |
+| `flags` | [sequence](/versions/9.0.0/rules/lib/core/list) of [string](/versions/9.0.0/rules/lib/core/string)s; default is `[]`  Deprecated, will be removed. |
+| `mandatory` | [bool](/versions/9.0.0/rules/lib/core/bool); default is `False`  If true, the value must be specified explicitly (even if it has a `default`). |
+| `skip_validations` | [bool](/versions/9.0.0/rules/lib/core/bool); default is `False`  If true, validation actions of transitive dependencies from this attribute will not run. This is a temporary mitigation and WILL be removed in the future. |
 | `cfg` | default is `None`  [Configuration](https://bazel.build/versions/9.0.0/extending/rules#configurations) of the attribute. It can be either `"exec"`, which indicates that the dependency is built for the `execution platform`, or `"target"`, which indicates that the dependency is build for the `target platform`. A typical example of the difference is when building mobile apps, where the `target platform` is `Android` or `iOS` while the `execution platform` is `Linux`, `macOS`, or `Windows`. |
-| `aspects` | [sequence](../core/list) of [Aspect](../builtins/Aspect)s; default is `[]`  Aspects that should be applied to the dependency or dependencies specified by this attribute. |
+| `aspects` | [sequence](/versions/9.0.0/rules/lib/core/list) of [Aspect](/versions/9.0.0/rules/lib/builtins/Aspect)s; default is `[]`  Aspects that should be applied to the dependency or dependencies specified by this attribute. |
 
 ## label\_list\_dict
 
@@ -180,27 +180,27 @@ Attribute attr.label_list_dict(allow_empty=True, *, configurable=unbound, defaul
 
 Creates a schema for an attribute holding a dictionary, where the keys are strings and the values are list of labels. This is a dependency attribute.
 
-This attribute contains unique [`Label`](../builtins/Label) values. If a string is supplied in place of a `Label`, it will be converted using the [label constructor](../builtins/Label#Label). The relative parts of the label path, including the (possibly renamed) repository, are resolved with respect to the instantiated target's package.
+This attribute contains unique [`Label`](/versions/9.0.0/rules/lib/builtins/Label) values. If a string is supplied in place of a `Label`, it will be converted using the [label constructor](/versions/9.0.0/rules/lib/builtins/Label#Label). The relative parts of the label path, including the (possibly renamed) repository, are resolved with respect to the instantiated target's package.
 
-At analysis time (within the rule's implementation function), when retrieving the attribute value from `ctx.attr`, labels are replaced by the corresponding [`Target`](../builtins/Target)s. This allows you to access the providers of the current target's dependencies.
+At analysis time (within the rule's implementation function), when retrieving the attribute value from `ctx.attr`, labels are replaced by the corresponding [`Target`](/versions/9.0.0/rules/lib/builtins/Target)s. This allows you to access the providers of the current target's dependencies.
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `allow_empty` | [bool](../core/bool); default is `True`  True if the attribute can be empty. |
-| `configurable` | [bool](../core/bool); or unbound; default is `unbound`  This argument can only be specified for an attribute of a symbolic macro. If `configurable` is explicitly set to `False`, the symbolic macro attribute is non-configurable - in other words, it cannot take a `select()` value. If the `configurable` is either unbound or explicitly set to `True`, the attribute is configurable and can take a `select()` value. For an attribute of a rule or aspect, `configurable` must be left unbound. Most Starlark rule attributes are always configurable, with the exception of `attr.output()`, `attr.output_list()`, and `attr.license()` rule attributes, which are always non-configurable. |
-| `default` | [dict](../core/dict); default is `{}`  A default value to use if no value for this attribute is given when instantiating the rule.Use strings or the [`Label`](../builtins/Label#Label) function to specify default values, for example, `attr.label_list_dict(default = {"key1": ["//a:b", "//a:c"], "key2": [Label("@my_repo//d:e")]})`. |
-| `doc` | [string](../core/string); or `None`; default is `None`  A description of the attribute that can be extracted by documentation generating tools. |
-| `allow_files` | [bool](../core/bool); or [sequence](../core/list) of [string](../core/string)s; or `None`; default is `None`  Whether `File` targets are allowed. Can be `True`, `False` (default), or a list of file extensions that are allowed (for example, `[".cc", ".cpp"]`). |
-| `allow_rules` | [sequence](../core/list) of [string](../core/string)s; or `None`; default is `None`  Which rule targets (name of the classes) are allowed. This is deprecated (kept only for compatibility), use providers instead. |
-| `providers` | [sequence](../core/list); default is `[]`  The providers that must be given by any dependency appearing in this attribute. The format of this argument is a list of lists of providers -- `*Info` objects returned by [`provider()`](../globals/bzl#provider) (or in the case of a legacy provider, its string name). The dependency must return ALL providers mentioned in at least ONE of the inner lists. As a convenience, this argument may also be a single-level list of providers, in which case it is wrapped in an outer list with one element (i.e. `[A, B]` means `[[A, B]]`). It is NOT required that the rule of the dependency advertises those providers in its `provides` parameter, however, it is considered best practice. |
+| `allow_empty` | [bool](/versions/9.0.0/rules/lib/core/bool); default is `True`  True if the attribute can be empty. |
+| `configurable` | [bool](/versions/9.0.0/rules/lib/core/bool); or unbound; default is `unbound`  This argument can only be specified for an attribute of a symbolic macro. If `configurable` is explicitly set to `False`, the symbolic macro attribute is non-configurable - in other words, it cannot take a `select()` value. If the `configurable` is either unbound or explicitly set to `True`, the attribute is configurable and can take a `select()` value. For an attribute of a rule or aspect, `configurable` must be left unbound. Most Starlark rule attributes are always configurable, with the exception of `attr.output()`, `attr.output_list()`, and `attr.license()` rule attributes, which are always non-configurable. |
+| `default` | [dict](/versions/9.0.0/rules/lib/core/dict); default is `{}`  A default value to use if no value for this attribute is given when instantiating the rule.Use strings or the [`Label`](/versions/9.0.0/rules/lib/builtins/Label#Label) function to specify default values, for example, `attr.label_list_dict(default = {"key1": ["//a:b", "//a:c"], "key2": [Label("@my_repo//d:e")]})`. |
+| `doc` | [string](/versions/9.0.0/rules/lib/core/string); or `None`; default is `None`  A description of the attribute that can be extracted by documentation generating tools. |
+| `allow_files` | [bool](/versions/9.0.0/rules/lib/core/bool); or [sequence](/versions/9.0.0/rules/lib/core/list) of [string](/versions/9.0.0/rules/lib/core/string)s; or `None`; default is `None`  Whether `File` targets are allowed. Can be `True`, `False` (default), or a list of file extensions that are allowed (for example, `[".cc", ".cpp"]`). |
+| `allow_rules` | [sequence](/versions/9.0.0/rules/lib/core/list) of [string](/versions/9.0.0/rules/lib/core/string)s; or `None`; default is `None`  Which rule targets (name of the classes) are allowed. This is deprecated (kept only for compatibility), use providers instead. |
+| `providers` | [sequence](/versions/9.0.0/rules/lib/core/list); default is `[]`  The providers that must be given by any dependency appearing in this attribute. The format of this argument is a list of lists of providers -- `*Info` objects returned by [`provider()`](/versions/9.0.0/rules/lib/globals/bzl#provider) (or in the case of a legacy provider, its string name). The dependency must return ALL providers mentioned in at least ONE of the inner lists. As a convenience, this argument may also be a single-level list of providers, in which case it is wrapped in an outer list with one element (i.e. `[A, B]` means `[[A, B]]`). It is NOT required that the rule of the dependency advertises those providers in its `provides` parameter, however, it is considered best practice. |
 | `for_dependency_resolution` | default is `unbound`  If this is set, the attribute is available for materializers. Only rules marked with the flag of the same name are allowed to be referenced through such attributes. |
-| `flags` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  Deprecated, will be removed. |
-| `mandatory` | [bool](../core/bool); default is `False`  If true, the value must be specified explicitly (even if it has a `default`). |
-| `skip_validations` | [bool](../core/bool); default is `False`  If true, validation actions of transitive dependencies from this attribute will not run. This is a temporary mitigation and WILL be removed in the future. |
+| `flags` | [sequence](/versions/9.0.0/rules/lib/core/list) of [string](/versions/9.0.0/rules/lib/core/string)s; default is `[]`  Deprecated, will be removed. |
+| `mandatory` | [bool](/versions/9.0.0/rules/lib/core/bool); default is `False`  If true, the value must be specified explicitly (even if it has a `default`). |
+| `skip_validations` | [bool](/versions/9.0.0/rules/lib/core/bool); default is `False`  If true, validation actions of transitive dependencies from this attribute will not run. This is a temporary mitigation and WILL be removed in the future. |
 | `cfg` | default is `None`  [Configuration](https://bazel.build/versions/9.0.0/extending/rules#configurations) of the attribute. It can be either `"exec"`, which indicates that the dependency is built for the `execution platform`, or `"target"`, which indicates that the dependency is build for the `target platform`. A typical example of the difference is when building mobile apps, where the `target platform` is `Android` or `iOS` while the `execution platform` is `Linux`, `macOS`, or `Windows`. |
-| `aspects` | [sequence](../core/list) of [Aspect](../builtins/Aspect)s; default is `[]`  Aspects that should be applied to the dependency or dependencies specified by this attribute. |
+| `aspects` | [sequence](/versions/9.0.0/rules/lib/core/list) of [Aspect](/versions/9.0.0/rules/lib/builtins/Aspect)s; default is `[]`  Aspects that should be applied to the dependency or dependencies specified by this attribute. |
 
 ## output
 
@@ -210,16 +210,16 @@ Attribute attr.output(*, doc=None, mandatory=False)
 
 Creates a schema for an output (label) attribute.
 
-This attribute contains unique [`Label`](../builtins/Label) values. If a string is supplied in place of a `Label`, it will be converted using the [label constructor](../builtins/Label#Label). The relative parts of the label path, including the (possibly renamed) repository, are resolved with respect to the instantiated target's package.
+This attribute contains unique [`Label`](/versions/9.0.0/rules/lib/builtins/Label) values. If a string is supplied in place of a `Label`, it will be converted using the [label constructor](/versions/9.0.0/rules/lib/builtins/Label#Label). The relative parts of the label path, including the (possibly renamed) repository, are resolved with respect to the instantiated target's package.
 
-At analysis time, the corresponding [`File`](../builtins/File) can be retrieved using [`ctx.outputs`](../builtins/ctx#outputs).
+At analysis time, the corresponding [`File`](/versions/9.0.0/rules/lib/builtins/File) can be retrieved using [`ctx.outputs`](/versions/9.0.0/rules/lib/builtins/ctx#outputs).
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `doc` | [string](../core/string); or `None`; default is `None`  A description of the attribute that can be extracted by documentation generating tools. |
-| `mandatory` | [bool](../core/bool); default is `False`  If true, the value must be specified explicitly (even if it has a `default`). |
+| `doc` | [string](/versions/9.0.0/rules/lib/core/string); or `None`; default is `None`  A description of the attribute that can be extracted by documentation generating tools. |
+| `mandatory` | [bool](/versions/9.0.0/rules/lib/core/bool); default is `False`  If true, the value must be specified explicitly (even if it has a `default`). |
 
 ## output\_list
 
@@ -229,17 +229,17 @@ Attribute attr.output_list(allow_empty=True, *, doc=None, mandatory=False)
 
 Creates a schema for a list-of-outputs attribute.
 
-This attribute contains unique [`Label`](../builtins/Label) values. If a string is supplied in place of a `Label`, it will be converted using the [label constructor](../builtins/Label#Label). The relative parts of the label path, including the (possibly renamed) repository, are resolved with respect to the instantiated target's package.
+This attribute contains unique [`Label`](/versions/9.0.0/rules/lib/builtins/Label) values. If a string is supplied in place of a `Label`, it will be converted using the [label constructor](/versions/9.0.0/rules/lib/builtins/Label#Label). The relative parts of the label path, including the (possibly renamed) repository, are resolved with respect to the instantiated target's package.
 
-At analysis time, the corresponding [`File`](../builtins/File) can be retrieved using [`ctx.outputs`](../builtins/ctx#outputs).
+At analysis time, the corresponding [`File`](/versions/9.0.0/rules/lib/builtins/File) can be retrieved using [`ctx.outputs`](/versions/9.0.0/rules/lib/builtins/ctx#outputs).
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `allow_empty` | [bool](../core/bool); default is `True`  True if the attribute can be empty. |
-| `doc` | [string](../core/string); or `None`; default is `None`  A description of the attribute that can be extracted by documentation generating tools. |
-| `mandatory` | [bool](../core/bool); default is `False`  If true, the value must be specified explicitly (even if it has a `default`). |
+| `allow_empty` | [bool](/versions/9.0.0/rules/lib/core/bool); default is `True`  True if the attribute can be empty. |
+| `doc` | [string](/versions/9.0.0/rules/lib/core/string); or `None`; default is `None`  A description of the attribute that can be extracted by documentation generating tools. |
+| `mandatory` | [bool](/versions/9.0.0/rules/lib/core/bool); default is `False`  If true, the value must be specified explicitly (even if it has a `default`). |
 
 ## string
 
@@ -247,17 +247,17 @@ At analysis time, the corresponding [`File`](../builtins/File) can be retrieved
 Attribute attr.string(*, configurable=unbound, default='', doc=None, mandatory=False, values=[])
 ```
 
-Creates a schema for a [string](../core/string#attr) attribute.
+Creates a schema for a [string](/versions/9.0.0/rules/lib/core/string#attr) attribute.
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `configurable` | [bool](../core/bool); or unbound; default is `unbound`  This argument can only be specified for an attribute of a symbolic macro. If `configurable` is explicitly set to `False`, the symbolic macro attribute is non-configurable - in other words, it cannot take a `select()` value. If the `configurable` is either unbound or explicitly set to `True`, the attribute is configurable and can take a `select()` value. For an attribute of a rule or aspect, `configurable` must be left unbound. Most Starlark rule attributes are always configurable, with the exception of `attr.output()`, `attr.output_list()`, and `attr.license()` rule attributes, which are always non-configurable. |
-| `default` | [string](../core/string); or NativeComputedDefault; default is `''`  A default value to use if no value for this attribute is given when instantiating the rule. |
-| `doc` | [string](../core/string); or `None`; default is `None`  A description of the attribute that can be extracted by documentation generating tools. |
-| `mandatory` | [bool](../core/bool); default is `False`  If true, the value must be specified explicitly (even if it has a `default`). |
-| `values` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  The list of allowed values for the attribute. An error is raised if any other value is given. |
+| `configurable` | [bool](/versions/9.0.0/rules/lib/core/bool); or unbound; default is `unbound`  This argument can only be specified for an attribute of a symbolic macro. If `configurable` is explicitly set to `False`, the symbolic macro attribute is non-configurable - in other words, it cannot take a `select()` value. If the `configurable` is either unbound or explicitly set to `True`, the attribute is configurable and can take a `select()` value. For an attribute of a rule or aspect, `configurable` must be left unbound. Most Starlark rule attributes are always configurable, with the exception of `attr.output()`, `attr.output_list()`, and `attr.license()` rule attributes, which are always non-configurable. |
+| `default` | [string](/versions/9.0.0/rules/lib/core/string); or NativeComputedDefault; default is `''`  A default value to use if no value for this attribute is given when instantiating the rule. |
+| `doc` | [string](/versions/9.0.0/rules/lib/core/string); or `None`; default is `None`  A description of the attribute that can be extracted by documentation generating tools. |
+| `mandatory` | [bool](/versions/9.0.0/rules/lib/core/bool); default is `False`  If true, the value must be specified explicitly (even if it has a `default`). |
+| `values` | [sequence](/versions/9.0.0/rules/lib/core/list) of [string](/versions/9.0.0/rules/lib/core/string)s; default is `[]`  The list of allowed values for the attribute. An error is raised if any other value is given. |
 
 ## string\_dict
 
@@ -271,11 +271,11 @@ Creates a schema for an attribute holding a dictionary, where the keys and value
 
 | Parameter | Description |
 | --- | --- |
-| `allow_empty` | [bool](../core/bool); default is `True`  True if the attribute can be empty. |
-| `configurable` | [bool](../core/bool); or unbound; default is `unbound`  This argument can only be specified for an attribute of a symbolic macro. If `configurable` is explicitly set to `False`, the symbolic macro attribute is non-configurable - in other words, it cannot take a `select()` value. If the `configurable` is either unbound or explicitly set to `True`, the attribute is configurable and can take a `select()` value. For an attribute of a rule or aspect, `configurable` must be left unbound. Most Starlark rule attributes are always configurable, with the exception of `attr.output()`, `attr.output_list()`, and `attr.license()` rule attributes, which are always non-configurable. |
-| `default` | [dict](../core/dict); default is `{}`  A default value to use if no value for this attribute is given when instantiating the rule. |
-| `doc` | [string](../core/string); or `None`; default is `None`  A description of the attribute that can be extracted by documentation generating tools. |
-| `mandatory` | [bool](../core/bool); default is `False`  If true, the value must be specified explicitly (even if it has a `default`). |
+| `allow_empty` | [bool](/versions/9.0.0/rules/lib/core/bool); default is `True`  True if the attribute can be empty. |
+| `configurable` | [bool](/versions/9.0.0/rules/lib/core/bool); or unbound; default is `unbound`  This argument can only be specified for an attribute of a symbolic macro. If `configurable` is explicitly set to `False`, the symbolic macro attribute is non-configurable - in other words, it cannot take a `select()` value. If the `configurable` is either unbound or explicitly set to `True`, the attribute is configurable and can take a `select()` value. For an attribute of a rule or aspect, `configurable` must be left unbound. Most Starlark rule attributes are always configurable, with the exception of `attr.output()`, `attr.output_list()`, and `attr.license()` rule attributes, which are always non-configurable. |
+| `default` | [dict](/versions/9.0.0/rules/lib/core/dict); default is `{}`  A default value to use if no value for this attribute is given when instantiating the rule. |
+| `doc` | [string](/versions/9.0.0/rules/lib/core/string); or `None`; default is `None`  A description of the attribute that can be extracted by documentation generating tools. |
+| `mandatory` | [bool](/versions/9.0.0/rules/lib/core/bool); default is `False`  If true, the value must be specified explicitly (even if it has a `default`). |
 
 ## string\_keyed\_label\_dict
 
@@ -285,26 +285,26 @@ Attribute attr.string_keyed_label_dict(allow_empty=True, *, configurable=unbound
 
 Creates a schema for an attribute whose value is a dictionary where the keys are strings and the values are labels. This is a dependency attribute.
 
-This attribute contains unique [`Label`](../builtins/Label) values. If a string is supplied in place of a `Label`, it will be converted using the [label constructor](../builtins/Label#Label). The relative parts of the label path, including the (possibly renamed) repository, are resolved with respect to the instantiated target's package.
+This attribute contains unique [`Label`](/versions/9.0.0/rules/lib/builtins/Label) values. If a string is supplied in place of a `Label`, it will be converted using the [label constructor](/versions/9.0.0/rules/lib/builtins/Label#Label). The relative parts of the label path, including the (possibly renamed) repository, are resolved with respect to the instantiated target's package.
 
-At analysis time (within the rule's implementation function), when retrieving the attribute value from `ctx.attr`, labels are replaced by the corresponding [`Target`](../builtins/Target)s. This allows you to access the providers of the current target's dependencies.
+At analysis time (within the rule's implementation function), when retrieving the attribute value from `ctx.attr`, labels are replaced by the corresponding [`Target`](/versions/9.0.0/rules/lib/builtins/Target)s. This allows you to access the providers of the current target's dependencies.
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `allow_empty` | [bool](../core/bool); default is `True`  True if the attribute can be empty. |
-| `configurable` | [bool](../core/bool); or unbound; default is `unbound`  This argument can only be specified for an attribute of a symbolic macro. If `configurable` is explicitly set to `False`, the symbolic macro attribute is non-configurable - in other words, it cannot take a `select()` value. If the `configurable` is either unbound or explicitly set to `True`, the attribute is configurable and can take a `select()` value. For an attribute of a rule or aspect, `configurable` must be left unbound. Most Starlark rule attributes are always configurable, with the exception of `attr.output()`, `attr.output_list()`, and `attr.license()` rule attributes, which are always non-configurable. |
-| `default` | [dict](../core/dict); or [function](../core/function); default is `{}`  A default value to use if no value for this attribute is given when instantiating the rule.Use strings or the [`Label`](../builtins/Label#Label) function to specify default values, for example, `attr.string_keyed_label_dict(default = {"foo": "//a:b", "bar": "//a:c"})`. |
-| `doc` | [string](../core/string); or `None`; default is `None`  A description of the attribute that can be extracted by documentation generating tools. |
-| `allow_files` | [bool](../core/bool); or [sequence](../core/list) of [string](../core/string)s; or `None`; default is `None`  Whether `File` targets are allowed. Can be `True`, `False` (default), or a list of file extensions that are allowed (for example, `[".cc", ".cpp"]`). |
-| `allow_rules` | [sequence](../core/list) of [string](../core/string)s; or `None`; default is `None`  Which rule targets (name of the classes) are allowed. This is deprecated (kept only for compatibility), use providers instead. |
-| `providers` | [sequence](../core/list); default is `[]`  The providers that must be given by any dependency appearing in this attribute. The format of this argument is a list of lists of providers -- `*Info` objects returned by [`provider()`](../globals/bzl#provider) (or in the case of a legacy provider, its string name). The dependency must return ALL providers mentioned in at least ONE of the inner lists. As a convenience, this argument may also be a single-level list of providers, in which case it is wrapped in an outer list with one element (i.e. `[A, B]` means `[[A, B]]`). It is NOT required that the rule of the dependency advertises those providers in its `provides` parameter, however, it is considered best practice. |
+| `allow_empty` | [bool](/versions/9.0.0/rules/lib/core/bool); default is `True`  True if the attribute can be empty. |
+| `configurable` | [bool](/versions/9.0.0/rules/lib/core/bool); or unbound; default is `unbound`  This argument can only be specified for an attribute of a symbolic macro. If `configurable` is explicitly set to `False`, the symbolic macro attribute is non-configurable - in other words, it cannot take a `select()` value. If the `configurable` is either unbound or explicitly set to `True`, the attribute is configurable and can take a `select()` value. For an attribute of a rule or aspect, `configurable` must be left unbound. Most Starlark rule attributes are always configurable, with the exception of `attr.output()`, `attr.output_list()`, and `attr.license()` rule attributes, which are always non-configurable. |
+| `default` | [dict](/versions/9.0.0/rules/lib/core/dict); or [function](/versions/9.0.0/rules/lib/core/function); default is `{}`  A default value to use if no value for this attribute is given when instantiating the rule.Use strings or the [`Label`](/versions/9.0.0/rules/lib/builtins/Label#Label) function to specify default values, for example, `attr.string_keyed_label_dict(default = {"foo": "//a:b", "bar": "//a:c"})`. |
+| `doc` | [string](/versions/9.0.0/rules/lib/core/string); or `None`; default is `None`  A description of the attribute that can be extracted by documentation generating tools. |
+| `allow_files` | [bool](/versions/9.0.0/rules/lib/core/bool); or [sequence](/versions/9.0.0/rules/lib/core/list) of [string](/versions/9.0.0/rules/lib/core/string)s; or `None`; default is `None`  Whether `File` targets are allowed. Can be `True`, `False` (default), or a list of file extensions that are allowed (for example, `[".cc", ".cpp"]`). |
+| `allow_rules` | [sequence](/versions/9.0.0/rules/lib/core/list) of [string](/versions/9.0.0/rules/lib/core/string)s; or `None`; default is `None`  Which rule targets (name of the classes) are allowed. This is deprecated (kept only for compatibility), use providers instead. |
+| `providers` | [sequence](/versions/9.0.0/rules/lib/core/list); default is `[]`  The providers that must be given by any dependency appearing in this attribute. The format of this argument is a list of lists of providers -- `*Info` objects returned by [`provider()`](/versions/9.0.0/rules/lib/globals/bzl#provider) (or in the case of a legacy provider, its string name). The dependency must return ALL providers mentioned in at least ONE of the inner lists. As a convenience, this argument may also be a single-level list of providers, in which case it is wrapped in an outer list with one element (i.e. `[A, B]` means `[[A, B]]`). It is NOT required that the rule of the dependency advertises those providers in its `provides` parameter, however, it is considered best practice. |
 | `for_dependency_resolution` | default is `unbound`  If this is set, the attribute is available for materializers. Only rules marked with the flag of the same name are allowed to be referenced through such attributes. |
-| `flags` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  Deprecated, will be removed. |
-| `mandatory` | [bool](../core/bool); default is `False`  If true, the value must be specified explicitly (even if it has a `default`). |
+| `flags` | [sequence](/versions/9.0.0/rules/lib/core/list) of [string](/versions/9.0.0/rules/lib/core/string)s; default is `[]`  Deprecated, will be removed. |
+| `mandatory` | [bool](/versions/9.0.0/rules/lib/core/bool); default is `False`  If true, the value must be specified explicitly (even if it has a `default`). |
 | `cfg` | default is `None`  [Configuration](https://bazel.build/versions/9.0.0/extending/rules#configurations) of the attribute. It can be either `"exec"`, which indicates that the dependency is built for the `execution platform`, or `"target"`, which indicates that the dependency is build for the `target platform`. A typical example of the difference is when building mobile apps, where the `target platform` is `Android` or `iOS` while the `execution platform` is `Linux`, `macOS`, or `Windows`. |
-| `aspects` | [sequence](../core/list) of [Aspect](../builtins/Aspect)s; default is `[]`  Aspects that should be applied to the dependency or dependencies specified by this attribute. |
+| `aspects` | [sequence](/versions/9.0.0/rules/lib/core/list) of [Aspect](/versions/9.0.0/rules/lib/builtins/Aspect)s; default is `[]`  Aspects that should be applied to the dependency or dependencies specified by this attribute. |
 
 ## string\_list
 
@@ -318,11 +318,11 @@ Creates a schema for a list-of-strings attribute.
 
 | Parameter | Description |
 | --- | --- |
-| `mandatory` | [bool](../core/bool); default is `False`  If true, the value must be specified explicitly (even if it has a `default`). |
-| `allow_empty` | [bool](../core/bool); default is `True`  True if the attribute can be empty. |
-| `configurable` | [bool](../core/bool); or unbound; default is `unbound`  This argument can only be specified for an attribute of a symbolic macro. If `configurable` is explicitly set to `False`, the symbolic macro attribute is non-configurable - in other words, it cannot take a `select()` value. If the `configurable` is either unbound or explicitly set to `True`, the attribute is configurable and can take a `select()` value. For an attribute of a rule or aspect, `configurable` must be left unbound. Most Starlark rule attributes are always configurable, with the exception of `attr.output()`, `attr.output_list()`, and `attr.license()` rule attributes, which are always non-configurable. |
-| `default` | [sequence](../core/list) of [string](../core/string)s; or NativeComputedDefault; default is `[]`  A default value to use if no value for this attribute is given when instantiating the rule. |
-| `doc` | [string](../core/string); or `None`; default is `None`  A description of the attribute that can be extracted by documentation generating tools. |
+| `mandatory` | [bool](/versions/9.0.0/rules/lib/core/bool); default is `False`  If true, the value must be specified explicitly (even if it has a `default`). |
+| `allow_empty` | [bool](/versions/9.0.0/rules/lib/core/bool); default is `True`  True if the attribute can be empty. |
+| `configurable` | [bool](/versions/9.0.0/rules/lib/core/bool); or unbound; default is `unbound`  This argument can only be specified for an attribute of a symbolic macro. If `configurable` is explicitly set to `False`, the symbolic macro attribute is non-configurable - in other words, it cannot take a `select()` value. If the `configurable` is either unbound or explicitly set to `True`, the attribute is configurable and can take a `select()` value. For an attribute of a rule or aspect, `configurable` must be left unbound. Most Starlark rule attributes are always configurable, with the exception of `attr.output()`, `attr.output_list()`, and `attr.license()` rule attributes, which are always non-configurable. |
+| `default` | [sequence](/versions/9.0.0/rules/lib/core/list) of [string](/versions/9.0.0/rules/lib/core/string)s; or NativeComputedDefault; default is `[]`  A default value to use if no value for this attribute is given when instantiating the rule. |
+| `doc` | [string](/versions/9.0.0/rules/lib/core/string); or `None`; default is `None`  A description of the attribute that can be extracted by documentation generating tools. |
 
 ## string\_list\_dict
 
@@ -336,8 +336,8 @@ Creates a schema for an attribute holding a dictionary, where the keys are strin
 
 | Parameter | Description |
 | --- | --- |
-| `allow_empty` | [bool](../core/bool); default is `True`  True if the attribute can be empty. |
-| `configurable` | [bool](../core/bool); or unbound; default is `unbound`  This argument can only be specified for an attribute of a symbolic macro. If `configurable` is explicitly set to `False`, the symbolic macro attribute is non-configurable - in other words, it cannot take a `select()` value. If the `configurable` is either unbound or explicitly set to `True`, the attribute is configurable and can take a `select()` value. For an attribute of a rule or aspect, `configurable` must be left unbound. Most Starlark rule attributes are always configurable, with the exception of `attr.output()`, `attr.output_list()`, and `attr.license()` rule attributes, which are always non-configurable. |
-| `default` | [dict](../core/dict); default is `{}`  A default value to use if no value for this attribute is given when instantiating the rule. |
-| `doc` | [string](../core/string); or `None`; default is `None`  A description of the attribute that can be extracted by documentation generating tools. |
-| `mandatory` | [bool](../core/bool); default is `False`  If true, the value must be specified explicitly (even if it has a `default`). |
\ No newline at end of file
+| `allow_empty` | [bool](/versions/9.0.0/rules/lib/core/bool); default is `True`  True if the attribute can be empty. |
+| `configurable` | [bool](/versions/9.0.0/rules/lib/core/bool); or unbound; default is `unbound`  This argument can only be specified for an attribute of a symbolic macro. If `configurable` is explicitly set to `False`, the symbolic macro attribute is non-configurable - in other words, it cannot take a `select()` value. If the `configurable` is either unbound or explicitly set to `True`, the attribute is configurable and can take a `select()` value. For an attribute of a rule or aspect, `configurable` must be left unbound. Most Starlark rule attributes are always configurable, with the exception of `attr.output()`, `attr.output_list()`, and `attr.license()` rule attributes, which are always non-configurable. |
+| `default` | [dict](/versions/9.0.0/rules/lib/core/dict); default is `{}`  A default value to use if no value for this attribute is given when instantiating the rule. |
+| `doc` | [string](/versions/9.0.0/rules/lib/core/string); or `None`; default is `None`  A description of the attribute that can be extracted by documentation generating tools. |
+| `mandatory` | [bool](/versions/9.0.0/rules/lib/core/bool); default is `False`  If true, the value must be specified explicitly (even if it has a `default`). |
\ No newline at end of file
diff --git a/versions/9.0.0/rules/lib/toplevel/cc_common.mdx b/versions/9.0.0/rules/lib/toplevel/cc_common.mdx
index b3e034b4..b3422042 100644
--- a/versions/9.0.0/rules/lib/toplevel/cc_common.mdx
+++ b/versions/9.0.0/rules/lib/toplevel/cc_common.mdx
@@ -43,8 +43,8 @@ Returns True if given action\_config is enabled in the feature configuration.
 
 | Parameter | Description |
 | --- | --- |
-| `feature_configuration` | [FeatureConfiguration](../builtins/FeatureConfiguration); required  Feature configuration to be queried. |
-| `action_name` | [string](../core/string); required  Name of the action\_config. |
+| `feature_configuration` | [FeatureConfiguration](/versions/9.0.0/rules/lib/builtins/FeatureConfiguration); required  Feature configuration to be queried. |
+| `action_name` | [string](/versions/9.0.0/rules/lib/core/string); required  Name of the action\_config. |
 
 ## CcToolchainInfo
 
@@ -66,29 +66,29 @@ Should be used for C++ compilation. Returns tuple of (`CompilationContext`, `CcC
 
 | Parameter | Description |
 | --- | --- |
-| `actions` | [actions](../builtins/actions); required  `actions` object. |
-| `feature_configuration` | [FeatureConfiguration](../builtins/FeatureConfiguration); required  `feature_configuration` to be queried. |
+| `actions` | [actions](/versions/9.0.0/rules/lib/builtins/actions); required  `actions` object. |
+| `feature_configuration` | [FeatureConfiguration](/versions/9.0.0/rules/lib/builtins/FeatureConfiguration); required  `feature_configuration` to be queried. |
 | `cc_toolchain` | Info; required  `CcToolchainInfo` provider to be used. |
-| `srcs` | [sequence](../core/list); default is `[]`  The list of source files to be compiled. |
-| `public_hdrs` | [sequence](../core/list); default is `[]`  List of headers needed for compilation of srcs and may be included by dependent rules transitively. |
-| `private_hdrs` | [sequence](../core/list); default is `[]`  List of headers needed for compilation of srcs and NOT to be included by dependent rules. |
-| `includes` | [sequence](../core/list); or [depset](../builtins/depset); default is `[]`  Search paths for header files referenced both by angle bracket and quotes. Usually passed with -I. Propagated to dependents transitively. |
-| `quote_includes` | [sequence](../core/list); default is `[]`  Search paths for header files referenced by quotes, e.g. #include "foo/bar/header.h". They can be either relative to the exec root or absolute. Usually passed with -iquote. Propagated to dependents transitively. |
-| `system_includes` | [sequence](../core/list); default is `[]`  Search paths for header files referenced by angle brackets, e.g. #include <foo/bar/header.h>. They can be either relative to the exec root or absolute. Usually passed with -isystem. Propagated to dependents transitively. |
-| `framework_includes` | [sequence](../core/list); default is `[]`  Search paths for header files from Apple frameworks. They can be either relative to the exec root or absolute. Usually passed with -F. Propagated to dependents transitively. |
-| `defines` | [sequence](../core/list); default is `[]`  Set of defines needed to compile this target. Each define is a string. Propagated to dependents transitively. |
-| `local_defines` | [sequence](../core/list); default is `[]`  Set of defines needed to compile this target. Each define is a string. Not propagated to dependents transitively. |
-| `include_prefix` | [string](../core/string); default is `''`  The prefix to add to the paths of the headers of this rule. When set, the headers in the hdrs attribute of this rule are accessible at is the value of this attribute prepended to their repository-relative path. The prefix in the strip\_include\_prefix attribute is removed before this prefix is added. |
-| `strip_include_prefix` | [string](../core/string); default is `''`  The prefix to strip from the paths of the headers of this rule. When set, the headers in the hdrs attribute of this rule are accessible at their path with this prefix cut off. If it's a relative path, it's taken as a package-relative one. If it's an absolute one, it's understood as a repository-relative path. The prefix in the include\_prefix attribute is added after this prefix is stripped. |
-| `user_compile_flags` | [sequence](../core/list); default is `[]`  Additional list of compilation options. |
-| `conly_flags` | [sequence](../core/list); default is `[]`  Additional list of compilation options for C compiles. |
-| `cxx_flags` | [sequence](../core/list); default is `[]`  Additional list of compilation options for C++ compiles. |
-| `compilation_contexts` | [sequence](../core/list); default is `[]`  Headers from dependencies used for compilation. |
-| `name` | [string](../core/string); required  This is used for naming the output artifacts of actions created by this method. See also the `main\_output` arg. |
-| `disallow_pic_outputs` | [bool](../core/bool); default is `False`  Whether PIC outputs should be created. |
-| `disallow_nopic_outputs` | [bool](../core/bool); default is `False`  Whether NOPIC outputs should be created. |
-| `additional_inputs` | [sequence](../core/list); default is `[]`  List of additional files needed for compilation of srcs |
-| `module_interfaces` | [sequence](../core/list); default is `unbound`  The list of module interfaces source files to be compiled. Note: this is an experimental feature, only enabled with --experimental\_cpp\_modules |
+| `srcs` | [sequence](/versions/9.0.0/rules/lib/core/list); default is `[]`  The list of source files to be compiled. |
+| `public_hdrs` | [sequence](/versions/9.0.0/rules/lib/core/list); default is `[]`  List of headers needed for compilation of srcs and may be included by dependent rules transitively. |
+| `private_hdrs` | [sequence](/versions/9.0.0/rules/lib/core/list); default is `[]`  List of headers needed for compilation of srcs and NOT to be included by dependent rules. |
+| `includes` | [sequence](/versions/9.0.0/rules/lib/core/list); or [depset](/versions/9.0.0/rules/lib/builtins/depset); default is `[]`  Search paths for header files referenced both by angle bracket and quotes. Usually passed with -I. Propagated to dependents transitively. |
+| `quote_includes` | [sequence](/versions/9.0.0/rules/lib/core/list); default is `[]`  Search paths for header files referenced by quotes, e.g. #include "foo/bar/header.h". They can be either relative to the exec root or absolute. Usually passed with -iquote. Propagated to dependents transitively. |
+| `system_includes` | [sequence](/versions/9.0.0/rules/lib/core/list); default is `[]`  Search paths for header files referenced by angle brackets, e.g. #include <foo/bar/header.h>. They can be either relative to the exec root or absolute. Usually passed with -isystem. Propagated to dependents transitively. |
+| `framework_includes` | [sequence](/versions/9.0.0/rules/lib/core/list); default is `[]`  Search paths for header files from Apple frameworks. They can be either relative to the exec root or absolute. Usually passed with -F. Propagated to dependents transitively. |
+| `defines` | [sequence](/versions/9.0.0/rules/lib/core/list); default is `[]`  Set of defines needed to compile this target. Each define is a string. Propagated to dependents transitively. |
+| `local_defines` | [sequence](/versions/9.0.0/rules/lib/core/list); default is `[]`  Set of defines needed to compile this target. Each define is a string. Not propagated to dependents transitively. |
+| `include_prefix` | [string](/versions/9.0.0/rules/lib/core/string); default is `''`  The prefix to add to the paths of the headers of this rule. When set, the headers in the hdrs attribute of this rule are accessible at is the value of this attribute prepended to their repository-relative path. The prefix in the strip\_include\_prefix attribute is removed before this prefix is added. |
+| `strip_include_prefix` | [string](/versions/9.0.0/rules/lib/core/string); default is `''`  The prefix to strip from the paths of the headers of this rule. When set, the headers in the hdrs attribute of this rule are accessible at their path with this prefix cut off. If it's a relative path, it's taken as a package-relative one. If it's an absolute one, it's understood as a repository-relative path. The prefix in the include\_prefix attribute is added after this prefix is stripped. |
+| `user_compile_flags` | [sequence](/versions/9.0.0/rules/lib/core/list); default is `[]`  Additional list of compilation options. |
+| `conly_flags` | [sequence](/versions/9.0.0/rules/lib/core/list); default is `[]`  Additional list of compilation options for C compiles. |
+| `cxx_flags` | [sequence](/versions/9.0.0/rules/lib/core/list); default is `[]`  Additional list of compilation options for C++ compiles. |
+| `compilation_contexts` | [sequence](/versions/9.0.0/rules/lib/core/list); default is `[]`  Headers from dependencies used for compilation. |
+| `name` | [string](/versions/9.0.0/rules/lib/core/string); required  This is used for naming the output artifacts of actions created by this method. See also the `main\_output` arg. |
+| `disallow_pic_outputs` | [bool](/versions/9.0.0/rules/lib/core/bool); default is `False`  Whether PIC outputs should be created. |
+| `disallow_nopic_outputs` | [bool](/versions/9.0.0/rules/lib/core/bool); default is `False`  Whether NOPIC outputs should be created. |
+| `additional_inputs` | [sequence](/versions/9.0.0/rules/lib/core/list); default is `[]`  List of additional files needed for compilation of srcs |
+| `module_interfaces` | [sequence](/versions/9.0.0/rules/lib/core/list); default is `unbound`  The list of module interfaces source files to be compiled. Note: this is an experimental feature, only enabled with --experimental\_cpp\_modules |
 
 ## configure\_features
 
@@ -102,11 +102,11 @@ Creates a feature\_configuration instance. Requires the cpp configuration fragme
 
 | Parameter | Description |
 | --- | --- |
-| `ctx` | [ctx](../builtins/ctx); required  The rule context. |
+| `ctx` | [ctx](/versions/9.0.0/rules/lib/builtins/ctx); required  The rule context. |
 | `cc_toolchain` | Info; required  cc\_toolchain for which we configure features. |
-| `language` | [string](../core/string); or `None`; default is `None`  The language to configure for: either c++ or objc (default c++) |
-| `requested_features` | [sequence](../core/list); default is `[]`  List of features to be enabled. |
-| `unsupported_features` | [sequence](../core/list); default is `[]`  List of features that are unsupported by the current rule. |
+| `language` | [string](/versions/9.0.0/rules/lib/core/string); or `None`; default is `None`  The language to configure for: either c++ or objc (default c++) |
+| `requested_features` | [sequence](/versions/9.0.0/rules/lib/core/list); default is `[]`  List of features to be enabled. |
+| `unsupported_features` | [sequence](/versions/9.0.0/rules/lib/core/list); default is `[]`  List of features that are unsupported by the current rule. |
 
 ## create\_cc\_toolchain\_config\_info
 
@@ -120,22 +120,22 @@ Creates a `CcToolchainConfigInfo` provider
 
 | Parameter | Description |
 | --- | --- |
-| `ctx` | [ctx](../builtins/ctx); required  The rule context. |
-| `features` | [sequence](../core/list); default is `[]`  Contains all flag specifications for one feature. Arguments:  `name`: The feature's name. It is possible to introduce a feature without a change to Bazel by adding a 'feature' section to the toolchain and adding the corresponding string as feature in the `BUILD` file.  `enabled`: If 'True', this feature is enabled unless a rule type explicitly marks it as unsupported.  `flag_sets`: A FlagSet list. If the given feature is enabled, the flag sets will be applied for the actions are specified for.  `env_sets`: an EnvSet list. If the given feature is enabled, the env sets will be applied for the actions they are specified for.  `requires`: A list of feature sets defining when this feature is supported by the toolchain. The feature is supported if any of the feature sets fully apply, that is, when all features of a feature set are enabled. If `requires` is omitted, the feature is supported independently of which other features are enabled. Use this for example to filter flags depending on the build mode enabled (opt / fastbuild / dbg).  `implies`: A string list of features or action configs that are automatically enabled when this feature is enabled. If any of the implied features or action configs cannot be enabled, this feature will (silently) not be enabled either.  `provides`: A list of names this feature conflicts with. A feature cannot be enabled if:- `provides` contains the name of a different feature or action config that we want to enable.- `provides` contains the same value as a 'provides' in a different feature or action config that we want to enable. Use this in order to ensure that incompatible features cannot be accidentally activated at the same time, leading to hard to diagnose compiler errors. |
-| `action_configs` | [sequence](../core/list); default is `[]`  An action config corresponds to a Bazel action, and allows selection of a tool based on activated features. Action config activation occurs by the same semantics as features: a feature can 'require' or 'imply' an action config in the same way that it would another feature. Arguments:  `action_name`: The name of the Bazel action that this config applies to, e.g. 'c-compile' or 'c-module-compile'.  `enabled`: If 'True', this action is enabled unless a rule type explicitly marks it as unsupported.  `tools`: The tool applied to the action will be the first tool with a feature set that matches the feature configuration. An error will be thrown if no tool matches a provided feature configuration - for that reason, it's a good idea to provide a default tool with an empty feature set.  `flag_sets`: If the given action config is enabled, the flag sets will be applied to the corresponding action.  `implies`: A list of features or action configs that are automatically enabled when this action config is enabled. If any of the implied features or action configs cannot be enabled, this action config will (silently) not be enabled either. |
-| `artifact_name_patterns` | [sequence](../core/list); default is `[]`  The name for an artifact of a given category of input or output artifacts to an action. Arguments:  `category_name`: The category of artifacts that this selection applies to. This field is compared against a list of categories defined in Bazel. Example categories include "linked\_output" or the artifact for this selection. Together with the extension it is used to create an artifact name based on the target name.  `extension`: The extension for creating the artifact for this selection. Together with the prefix it is used to create an artifact name based on the target name. |
-| `cxx_builtin_include_directories` | [sequence](../core/list); default is `[]`  Built-in include directories for C++ compilation. These should be the exact paths used by the compiler, and are generally relative to the exec root.  The paths used by the compiler can be determined by 'gcc -E -xc++ - -v'.  We currently use the C++ paths also for C compilation, which is safe as long as there are no name clashes between C++ and C header files.  Relative paths are resolved relative to the configuration file directory.  If the compiler has --sysroot support, then these paths should use %sysroot% rather than the include path, and specify the sysroot attribute in order to give blaze the information necessary to make the correct replacements. |
-| `toolchain_identifier` | [string](../core/string); required  The unique identifier of the toolchain within the crosstool release. It must be possible to use this as a directory name in a path.  It has to match the following regex: [a-zA-Z\_][\.\- \w]\* |
-| `host_system_name` | [string](../core/string); or `None`; default is `None`  Ignored. |
-| `target_system_name` | [string](../core/string); or `None`; default is `None`  Deprecated. The GNU System Name. The string is exposed to CcToolchainInfo.target\_gnu\_system\_name. |
-| `target_cpu` | [string](../core/string); or `None`; default is `None`  Deprecated: Use cpu based constraints instead. If the string is "k8", `target\_cpu` will be omitted from the filename of raw FDO profile data. |
-| `target_libc` | [string](../core/string); or `None`; default is `None`  Deprecated: Use OS based constraints instead. The libc version string (e.g. "glibc-2.2.2"). If the string is "macosx", platform is assumed to be MacOS. Otherwise, Linux. The string is exposed to CcToolchainInfo.libc. |
-| `compiler` | [string](../core/string); required  The compiler string (e.g. "gcc"). The current toolchain's compiler is exposed to `@bazel\_tools//tools/cpp:compiler (compiler\_flag)` as a flag value. Targets that require compiler-specific flags can use the config\_settings in https://github.com/bazelbuild/rules\_cc/blob/main/cc/compiler/BUILD in select() statements or create custom config\_setting if the existing settings don't suffice. |
-| `abi_version` | [string](../core/string); or `None`; default is `None`  The abi in use, which is a gcc version. E.g.: "gcc-3.4". The string is set to C++ toolchain variable ABI. |
-| `abi_libc_version` | [string](../core/string); or `None`; default is `None`  The glibc version used by the abi we're using. The string is set to C++ toolchain variable ABI\_LIBC\_VERSION. |
-| `tool_paths` | [sequence](../core/list); default is `[]`  Tool locations. Arguments:  `name`: Name of the tool.  `path`: Location of the tool; Can be absolute path (in case of non hermetic toolchain), or path relative to the cc\_toolchain's package. |
-| `make_variables` | [sequence](../core/list); default is `[]`  A make variable that is made accessible to rules. |
-| `builtin_sysroot` | [string](../core/string); or `None`; default is `None`  The built-in sysroot. If this attribute is not present, Bazel does not allow using a different sysroot, i.e. through the --grte\_top option. |
+| `ctx` | [ctx](/versions/9.0.0/rules/lib/builtins/ctx); required  The rule context. |
+| `features` | [sequence](/versions/9.0.0/rules/lib/core/list); default is `[]`  Contains all flag specifications for one feature. Arguments:  `name`: The feature's name. It is possible to introduce a feature without a change to Bazel by adding a 'feature' section to the toolchain and adding the corresponding string as feature in the `BUILD` file.  `enabled`: If 'True', this feature is enabled unless a rule type explicitly marks it as unsupported.  `flag_sets`: A FlagSet list. If the given feature is enabled, the flag sets will be applied for the actions are specified for.  `env_sets`: an EnvSet list. If the given feature is enabled, the env sets will be applied for the actions they are specified for.  `requires`: A list of feature sets defining when this feature is supported by the toolchain. The feature is supported if any of the feature sets fully apply, that is, when all features of a feature set are enabled. If `requires` is omitted, the feature is supported independently of which other features are enabled. Use this for example to filter flags depending on the build mode enabled (opt / fastbuild / dbg).  `implies`: A string list of features or action configs that are automatically enabled when this feature is enabled. If any of the implied features or action configs cannot be enabled, this feature will (silently) not be enabled either.  `provides`: A list of names this feature conflicts with. A feature cannot be enabled if:- `provides` contains the name of a different feature or action config that we want to enable.- `provides` contains the same value as a 'provides' in a different feature or action config that we want to enable. Use this in order to ensure that incompatible features cannot be accidentally activated at the same time, leading to hard to diagnose compiler errors. |
+| `action_configs` | [sequence](/versions/9.0.0/rules/lib/core/list); default is `[]`  An action config corresponds to a Bazel action, and allows selection of a tool based on activated features. Action config activation occurs by the same semantics as features: a feature can 'require' or 'imply' an action config in the same way that it would another feature. Arguments:  `action_name`: The name of the Bazel action that this config applies to, e.g. 'c-compile' or 'c-module-compile'.  `enabled`: If 'True', this action is enabled unless a rule type explicitly marks it as unsupported.  `tools`: The tool applied to the action will be the first tool with a feature set that matches the feature configuration. An error will be thrown if no tool matches a provided feature configuration - for that reason, it's a good idea to provide a default tool with an empty feature set.  `flag_sets`: If the given action config is enabled, the flag sets will be applied to the corresponding action.  `implies`: A list of features or action configs that are automatically enabled when this action config is enabled. If any of the implied features or action configs cannot be enabled, this action config will (silently) not be enabled either. |
+| `artifact_name_patterns` | [sequence](/versions/9.0.0/rules/lib/core/list); default is `[]`  The name for an artifact of a given category of input or output artifacts to an action. Arguments:  `category_name`: The category of artifacts that this selection applies to. This field is compared against a list of categories defined in Bazel. Example categories include "linked\_output" or the artifact for this selection. Together with the extension it is used to create an artifact name based on the target name.  `extension`: The extension for creating the artifact for this selection. Together with the prefix it is used to create an artifact name based on the target name. |
+| `cxx_builtin_include_directories` | [sequence](/versions/9.0.0/rules/lib/core/list); default is `[]`  Built-in include directories for C++ compilation. These should be the exact paths used by the compiler, and are generally relative to the exec root.  The paths used by the compiler can be determined by 'gcc -E -xc++ - -v'.  We currently use the C++ paths also for C compilation, which is safe as long as there are no name clashes between C++ and C header files.  Relative paths are resolved relative to the configuration file directory.  If the compiler has --sysroot support, then these paths should use %sysroot% rather than the include path, and specify the sysroot attribute in order to give blaze the information necessary to make the correct replacements. |
+| `toolchain_identifier` | [string](/versions/9.0.0/rules/lib/core/string); required  The unique identifier of the toolchain within the crosstool release. It must be possible to use this as a directory name in a path.  It has to match the following regex: [a-zA-Z\_][\.\- \w]\* |
+| `host_system_name` | [string](/versions/9.0.0/rules/lib/core/string); or `None`; default is `None`  Ignored. |
+| `target_system_name` | [string](/versions/9.0.0/rules/lib/core/string); or `None`; default is `None`  Deprecated. The GNU System Name. The string is exposed to CcToolchainInfo.target\_gnu\_system\_name. |
+| `target_cpu` | [string](/versions/9.0.0/rules/lib/core/string); or `None`; default is `None`  Deprecated: Use cpu based constraints instead. If the string is "k8", `target\_cpu` will be omitted from the filename of raw FDO profile data. |
+| `target_libc` | [string](/versions/9.0.0/rules/lib/core/string); or `None`; default is `None`  Deprecated: Use OS based constraints instead. The libc version string (e.g. "glibc-2.2.2"). If the string is "macosx", platform is assumed to be MacOS. Otherwise, Linux. The string is exposed to CcToolchainInfo.libc. |
+| `compiler` | [string](/versions/9.0.0/rules/lib/core/string); required  The compiler string (e.g. "gcc"). The current toolchain's compiler is exposed to `@bazel\_tools//tools/cpp:compiler (compiler\_flag)` as a flag value. Targets that require compiler-specific flags can use the config\_settings in https://github.com/bazelbuild/rules\_cc/blob/main/cc/compiler/BUILD in select() statements or create custom config\_setting if the existing settings don't suffice. |
+| `abi_version` | [string](/versions/9.0.0/rules/lib/core/string); or `None`; default is `None`  The abi in use, which is a gcc version. E.g.: "gcc-3.4". The string is set to C++ toolchain variable ABI. |
+| `abi_libc_version` | [string](/versions/9.0.0/rules/lib/core/string); or `None`; default is `None`  The glibc version used by the abi we're using. The string is set to C++ toolchain variable ABI\_LIBC\_VERSION. |
+| `tool_paths` | [sequence](/versions/9.0.0/rules/lib/core/list); default is `[]`  Tool locations. Arguments:  `name`: Name of the tool.  `path`: Location of the tool; Can be absolute path (in case of non hermetic toolchain), or path relative to the cc\_toolchain's package. |
+| `make_variables` | [sequence](/versions/9.0.0/rules/lib/core/list); default is `[]`  A make variable that is made accessible to rules. |
+| `builtin_sysroot` | [string](/versions/9.0.0/rules/lib/core/string); or `None`; default is `None`  The built-in sysroot. If this attribute is not present, Bazel does not allow using a different sysroot, i.e. through the --grte\_top option. |
 
 ## create\_compilation\_context
 
@@ -169,8 +169,8 @@ Create compilation outputs object.
 
 | Parameter | Description |
 | --- | --- |
-| `objects` | [depset](../builtins/depset); or `None`; default is `None`  List of object files. |
-| `pic_objects` | [depset](../builtins/depset); or `None`; default is `None`  List of pic object files. |
+| `objects` | [depset](/versions/9.0.0/rules/lib/builtins/depset); or `None`; default is `None`  List of object files. |
+| `pic_objects` | [depset](/versions/9.0.0/rules/lib/builtins/depset); or `None`; default is `None`  List of pic object files. |
 
 ## create\_compile\_variables
 
@@ -185,21 +185,21 @@ Returns variables used for compilation actions.
 | Parameter | Description |
 | --- | --- |
 | `cc_toolchain` | Info; required  cc\_toolchain for which we are creating build variables. |
-| `feature_configuration` | [FeatureConfiguration](../builtins/FeatureConfiguration); required  Feature configuration to be queried. |
-| `source_file` | [File](../builtins/File); or [string](../core/string); or `None`; default is `None`  Optional source file path for the compilation. Please prefer passing source\_file here over appending it to the end of the command line generated from cc\_common.get\_memory\_inefficient\_command\_line, as then it's in the power of the toolchain author to properly specify and position compiler flags. |
-| `output_file` | [File](../builtins/File); or [string](../core/string); or `None`; default is `None`  Optional output file path of the compilation. Please prefer passing output\_file here over appending it to the end of the command line generated from cc\_common.get\_memory\_inefficient\_command\_line, as then it's in the power of the toolchain author to properly specify and position compiler flags. |
-| `user_compile_flags` | [sequence](../core/list) of [string](../core/string)s; or `None`; default is `None`  List of additional compilation flags (copts). |
-| `include_directories` | [depset](../builtins/depset); or `None`; default is `None`  Depset of include directories. |
-| `quote_include_directories` | [depset](../builtins/depset); or `None`; default is `None`  Depset of quote include directories. |
-| `system_include_directories` | [depset](../builtins/depset); or `None`; default is `None`  Depset of system include directories. |
-| `framework_include_directories` | [depset](../builtins/depset); or `None`; default is `None`  Depset of framework include directories. |
-| `preprocessor_defines` | [depset](../builtins/depset); or `None`; default is `None`  Depset of preprocessor defines. |
-| `thinlto_index` | [string](../core/string); or `None`; default is `None`  LTO index file path. |
-| `thinlto_input_bitcode_file` | [string](../core/string); or `None`; default is `None`  Bitcode file that is input to LTO backend. |
-| `thinlto_output_object_file` | [string](../core/string); or `None`; default is `None`  Object file that is output by LTO backend. |
-| `use_pic` | [bool](../core/bool); default is `False`  When true the compilation will generate position independent code. |
-| `add_legacy_cxx_options` | [bool](../core/bool); default is `False`  Unused. |
-| `variables_extension` | [dict](../core/dict); default is `unbound`  A dictionary of additional variables used by compile actions. |
+| `feature_configuration` | [FeatureConfiguration](/versions/9.0.0/rules/lib/builtins/FeatureConfiguration); required  Feature configuration to be queried. |
+| `source_file` | [File](/versions/9.0.0/rules/lib/builtins/File); or [string](/versions/9.0.0/rules/lib/core/string); or `None`; default is `None`  Optional source file path for the compilation. Please prefer passing source\_file here over appending it to the end of the command line generated from cc\_common.get\_memory\_inefficient\_command\_line, as then it's in the power of the toolchain author to properly specify and position compiler flags. |
+| `output_file` | [File](/versions/9.0.0/rules/lib/builtins/File); or [string](/versions/9.0.0/rules/lib/core/string); or `None`; default is `None`  Optional output file path of the compilation. Please prefer passing output\_file here over appending it to the end of the command line generated from cc\_common.get\_memory\_inefficient\_command\_line, as then it's in the power of the toolchain author to properly specify and position compiler flags. |
+| `user_compile_flags` | [sequence](/versions/9.0.0/rules/lib/core/list) of [string](/versions/9.0.0/rules/lib/core/string)s; or `None`; default is `None`  List of additional compilation flags (copts). |
+| `include_directories` | [depset](/versions/9.0.0/rules/lib/builtins/depset); or `None`; default is `None`  Depset of include directories. |
+| `quote_include_directories` | [depset](/versions/9.0.0/rules/lib/builtins/depset); or `None`; default is `None`  Depset of quote include directories. |
+| `system_include_directories` | [depset](/versions/9.0.0/rules/lib/builtins/depset); or `None`; default is `None`  Depset of system include directories. |
+| `framework_include_directories` | [depset](/versions/9.0.0/rules/lib/builtins/depset); or `None`; default is `None`  Depset of framework include directories. |
+| `preprocessor_defines` | [depset](/versions/9.0.0/rules/lib/builtins/depset); or `None`; default is `None`  Depset of preprocessor defines. |
+| `thinlto_index` | [string](/versions/9.0.0/rules/lib/core/string); or `None`; default is `None`  LTO index file path. |
+| `thinlto_input_bitcode_file` | [string](/versions/9.0.0/rules/lib/core/string); or `None`; default is `None`  Bitcode file that is input to LTO backend. |
+| `thinlto_output_object_file` | [string](/versions/9.0.0/rules/lib/core/string); or `None`; default is `None`  Object file that is output by LTO backend. |
+| `use_pic` | [bool](/versions/9.0.0/rules/lib/core/bool); default is `False`  When true the compilation will generate position independent code. |
+| `add_legacy_cxx_options` | [bool](/versions/9.0.0/rules/lib/core/bool); default is `False`  Unused. |
+| `variables_extension` | [dict](/versions/9.0.0/rules/lib/core/dict); default is `unbound`  A dictionary of additional variables used by compile actions. |
 
 ## create\_library\_to\_link
 
@@ -216,15 +216,15 @@ Creates `LibraryToLink`
 | `actions` | required  `actions` object. |
 | `feature_configuration` | default is `None`  `feature_configuration` to be queried. |
 | `cc_toolchain` | default is `None`  `CcToolchainInfo` provider to be used. |
-| `static_library` | [File](../builtins/File); or `None`; default is `None`  `File` of static library to be linked. |
-| `pic_static_library` | [File](../builtins/File); or `None`; default is `None`  `File` of pic static library to be linked. |
-| `dynamic_library` | [File](../builtins/File); or `None`; default is `None`  `File` of dynamic library to be linked. Always used for runtime and used for linking if `interface_library` is not passed. |
-| `interface_library` | [File](../builtins/File); or `None`; default is `None`  `File` of interface library to be linked. |
-| `pic_objects` | [sequence](../core/list) of [File](../builtins/File)s; default is `unbound`  Experimental, do not use |
-| `objects` | [sequence](../core/list) of [File](../builtins/File)s; default is `unbound`  Experimental, do not use |
-| `alwayslink` | [bool](../core/bool); default is `False`  Whether to link the static library/objects in the --whole\_archive block. |
-| `dynamic_library_symlink_path` | [string](../core/string); default is `''`  Override the default path of the dynamic library link in the solib directory. Empty string to use the default. |
-| `interface_library_symlink_path` | [string](../core/string); default is `''`  Override the default path of the interface library link in the solib directory. Empty string to use the default. |
+| `static_library` | [File](/versions/9.0.0/rules/lib/builtins/File); or `None`; default is `None`  `File` of static library to be linked. |
+| `pic_static_library` | [File](/versions/9.0.0/rules/lib/builtins/File); or `None`; default is `None`  `File` of pic static library to be linked. |
+| `dynamic_library` | [File](/versions/9.0.0/rules/lib/builtins/File); or `None`; default is `None`  `File` of dynamic library to be linked. Always used for runtime and used for linking if `interface_library` is not passed. |
+| `interface_library` | [File](/versions/9.0.0/rules/lib/builtins/File); or `None`; default is `None`  `File` of interface library to be linked. |
+| `pic_objects` | [sequence](/versions/9.0.0/rules/lib/core/list) of [File](/versions/9.0.0/rules/lib/builtins/File)s; default is `unbound`  Experimental, do not use |
+| `objects` | [sequence](/versions/9.0.0/rules/lib/core/list) of [File](/versions/9.0.0/rules/lib/builtins/File)s; default is `unbound`  Experimental, do not use |
+| `alwayslink` | [bool](/versions/9.0.0/rules/lib/core/bool); default is `False`  Whether to link the static library/objects in the --whole\_archive block. |
+| `dynamic_library_symlink_path` | [string](/versions/9.0.0/rules/lib/core/string); default is `''`  Override the default path of the dynamic library link in the solib directory. Empty string to use the default. |
+| `interface_library_symlink_path` | [string](/versions/9.0.0/rules/lib/core/string); default is `''`  Override the default path of the interface library link in the solib directory. Empty string to use the default. |
 
 ## create\_link\_variables
 
@@ -239,17 +239,17 @@ Returns link variables used for linking actions.
 | Parameter | Description |
 | --- | --- |
 | `cc_toolchain` | Info; required  cc\_toolchain for which we are creating build variables. |
-| `feature_configuration` | [FeatureConfiguration](../builtins/FeatureConfiguration); required  Feature configuration to be queried. |
-| `library_search_directories` | [depset](../builtins/depset); default is `[]`  Depset of directories where linker will look for libraries at link time. |
-| `runtime_library_search_directories` | [depset](../builtins/depset); default is `[]`  Depset of directories where loader will look for libraries at runtime. |
-| `user_link_flags` | [sequence](../core/list); default is `[]`  List of additional link flags (linkopts). |
+| `feature_configuration` | [FeatureConfiguration](/versions/9.0.0/rules/lib/builtins/FeatureConfiguration); required  Feature configuration to be queried. |
+| `library_search_directories` | [depset](/versions/9.0.0/rules/lib/builtins/depset); default is `[]`  Depset of directories where linker will look for libraries at link time. |
+| `runtime_library_search_directories` | [depset](/versions/9.0.0/rules/lib/builtins/depset); default is `[]`  Depset of directories where loader will look for libraries at runtime. |
+| `user_link_flags` | [sequence](/versions/9.0.0/rules/lib/core/list); default is `[]`  List of additional link flags (linkopts). |
 | `output_file` | default is `None`  Optional output file path. |
 | `param_file` | default is `None`  Optional param file path. |
-| `is_using_linker` | [bool](../core/bool); default is `True`  True when using linker, False when archiver. Caller is responsible for keeping this in sync with action name used (is\_using\_linker = True for linking executable or dynamic library, is\_using\_linker = False for archiving static library). |
-| `is_linking_dynamic_library` | [bool](../core/bool); default is `False`  True when creating dynamic library, False when executable or static library. Caller is responsible for keeping this in sync with action name used. This field will be removed once b/65151735 is fixed. |
-| `must_keep_debug` | [bool](../core/bool); default is `True`  When set to False, bazel will expose 'strip\_debug\_symbols' variable, which is usually used to use the linker to strip debug symbols from the output file. |
-| `use_test_only_flags` | [bool](../core/bool); default is `False`  When set to true, 'is\_cc\_test' variable will be set. |
-| `is_static_linking_mode` | [bool](../core/bool); default is `True`  Unused. |
+| `is_using_linker` | [bool](/versions/9.0.0/rules/lib/core/bool); default is `True`  True when using linker, False when archiver. Caller is responsible for keeping this in sync with action name used (is\_using\_linker = True for linking executable or dynamic library, is\_using\_linker = False for archiving static library). |
+| `is_linking_dynamic_library` | [bool](/versions/9.0.0/rules/lib/core/bool); default is `False`  True when creating dynamic library, False when executable or static library. Caller is responsible for keeping this in sync with action name used. This field will be removed once b/65151735 is fixed. |
+| `must_keep_debug` | [bool](/versions/9.0.0/rules/lib/core/bool); default is `True`  When set to False, bazel will expose 'strip\_debug\_symbols' variable, which is usually used to use the linker to strip debug symbols from the output file. |
+| `use_test_only_flags` | [bool](/versions/9.0.0/rules/lib/core/bool); default is `False`  When set to true, 'is\_cc\_test' variable will be set. |
+| `is_static_linking_mode` | [bool](/versions/9.0.0/rules/lib/core/bool); default is `True`  Unused. |
 
 ## create\_linker\_input
 
@@ -263,10 +263,10 @@ Creates a `LinkerInput`.
 
 | Parameter | Description |
 | --- | --- |
-| `owner` | [Label](../builtins/Label); required  The label of the target that produced all files used in this input. |
-| `libraries` | `None`; or [depset](../builtins/depset); default is `None`  List of `LibraryToLink`. |
-| `user_link_flags` | `None`; or [depset](../builtins/depset) of [string](../core/string)s; or [sequence](../core/list) of [string](../core/string)s; default is `None`  User link flags passed as strings. Accepts either [String], [[String]] or depset(String). The latter is discouraged as it's only kept for compatibility purposes, the depset is flattened. If you want to propagate user\_link\_flags via unflattened depsets() wrap them in a LinkerInput so that they are not flattened till the end. |
-| `additional_inputs` | `None`; or [depset](../builtins/depset); default is `None`  For additional inputs to the linking action, e.g.: linking scripts. |
+| `owner` | [Label](/versions/9.0.0/rules/lib/builtins/Label); required  The label of the target that produced all files used in this input. |
+| `libraries` | `None`; or [depset](/versions/9.0.0/rules/lib/builtins/depset); default is `None`  List of `LibraryToLink`. |
+| `user_link_flags` | `None`; or [depset](/versions/9.0.0/rules/lib/builtins/depset) of [string](/versions/9.0.0/rules/lib/core/string)s; or [sequence](/versions/9.0.0/rules/lib/core/list) of [string](/versions/9.0.0/rules/lib/core/string)s; default is `None`  User link flags passed as strings. Accepts either [String], [[String]] or depset(String). The latter is discouraged as it's only kept for compatibility purposes, the depset is flattened. If you want to propagate user\_link\_flags via unflattened depsets() wrap them in a LinkerInput so that they are not flattened till the end. |
+| `additional_inputs` | `None`; or [depset](/versions/9.0.0/rules/lib/builtins/depset); default is `None`  For additional inputs to the linking action, e.g.: linking scripts. |
 
 ## create\_linking\_context
 
@@ -280,7 +280,7 @@ Creates a `LinkingContext`.
 
 | Parameter | Description |
 | --- | --- |
-| `linker_inputs` | [depset](../builtins/depset); required  Depset of `LinkerInput`. |
+| `linker_inputs` | [depset](/versions/9.0.0/rules/lib/builtins/depset); required  Depset of `LinkerInput`. |
 
 ## create\_linking\_context\_from\_compilation\_outputs
 
@@ -294,19 +294,19 @@ Should be used for creating library rules that can propagate information downstr
 
 | Parameter | Description |
 | --- | --- |
-| `actions` | [actions](../builtins/actions); required  `actions` object. |
-| `name` | [string](../core/string); required  This is used for naming the output artifacts of actions created by this method. |
-| `feature_configuration` | [FeatureConfiguration](../builtins/FeatureConfiguration); required  `feature_configuration` to be queried. |
+| `actions` | [actions](/versions/9.0.0/rules/lib/builtins/actions); required  `actions` object. |
+| `name` | [string](/versions/9.0.0/rules/lib/core/string); required  This is used for naming the output artifacts of actions created by this method. |
+| `feature_configuration` | [FeatureConfiguration](/versions/9.0.0/rules/lib/builtins/FeatureConfiguration); required  `feature_configuration` to be queried. |
 | `cc_toolchain` | Info; required  `CcToolchainInfo` provider to be used. |
-| `language` | [string](../core/string); default is `'c++'`  Only C++ supported for now. Do not use this parameter. |
-| `disallow_static_libraries` | [bool](../core/bool); default is `False`  Whether static libraries should be created. |
-| `disallow_dynamic_library` | [bool](../core/bool); default is `False`  Whether a dynamic library should be created. |
-| `compilation_outputs` | [CcCompilationOutputs](../builtins/CcCompilationOutputs); required  Compilation outputs containing object files to link. |
-| `linking_contexts` | [sequence](../core/list); default is `[]`  Libraries from dependencies. These libraries will be linked into the output artifact of the link() call, be it a binary or a library. |
-| `user_link_flags` | [sequence](../core/list); default is `[]`  Additional list of linking options. |
-| `alwayslink` | [bool](../core/bool); default is `False`  Whether this library should always be linked. |
-| `additional_inputs` | [sequence](../core/list); default is `[]`  For additional inputs to the linking action, e.g.: linking scripts. |
-| `variables_extension` | [dict](../core/dict); default is `unbound`  Additional variables to pass to the toolchain configuration when creating link command line. |
+| `language` | [string](/versions/9.0.0/rules/lib/core/string); default is `'c++'`  Only C++ supported for now. Do not use this parameter. |
+| `disallow_static_libraries` | [bool](/versions/9.0.0/rules/lib/core/bool); default is `False`  Whether static libraries should be created. |
+| `disallow_dynamic_library` | [bool](/versions/9.0.0/rules/lib/core/bool); default is `False`  Whether a dynamic library should be created. |
+| `compilation_outputs` | [CcCompilationOutputs](/versions/9.0.0/rules/lib/builtins/CcCompilationOutputs); required  Compilation outputs containing object files to link. |
+| `linking_contexts` | [sequence](/versions/9.0.0/rules/lib/core/list); default is `[]`  Libraries from dependencies. These libraries will be linked into the output artifact of the link() call, be it a binary or a library. |
+| `user_link_flags` | [sequence](/versions/9.0.0/rules/lib/core/list); default is `[]`  Additional list of linking options. |
+| `alwayslink` | [bool](/versions/9.0.0/rules/lib/core/bool); default is `False`  Whether this library should always be linked. |
+| `additional_inputs` | [sequence](/versions/9.0.0/rules/lib/core/list); default is `[]`  For additional inputs to the linking action, e.g.: linking scripts. |
+| `variables_extension` | [dict](/versions/9.0.0/rules/lib/core/dict); default is `unbound`  Additional variables to pass to the toolchain configuration when creating link command line. |
 
 ## create\_lto\_compilation\_context
 
@@ -320,7 +320,7 @@ Create LTO compilation context
 
 | Parameter | Description |
 | --- | --- |
-| `objects` | [dict](../core/dict); default is `{}`  map of full object to index object |
+| `objects` | [dict](/versions/9.0.0/rules/lib/core/dict); default is `{}`  map of full object to index object |
 
 ## do\_not\_use\_tools\_cpp\_compiler\_present
 
@@ -342,8 +342,8 @@ Returns environment variables to be set for given action.
 
 | Parameter | Description |
 | --- | --- |
-| `feature_configuration` | [FeatureConfiguration](../builtins/FeatureConfiguration); required  Feature configuration to be queried. |
-| `action_name` | [string](../core/string); required  Name of the action. Has to be one of the names in @bazel\_tools//tools/build\_defs/cc:action\_names.bzl (https://github.com/bazelbuild/bazel/blob/master/tools/build\_defs/cc/action\_names.bzl) |
+| `feature_configuration` | [FeatureConfiguration](/versions/9.0.0/rules/lib/builtins/FeatureConfiguration); required  Feature configuration to be queried. |
+| `action_name` | [string](/versions/9.0.0/rules/lib/core/string); required  Name of the action. Has to be one of the names in @bazel\_tools//tools/build\_defs/cc:action\_names.bzl (https://github.com/bazelbuild/bazel/blob/master/tools/build\_defs/cc/action\_names.bzl) |
 | `variables` | Variables; required  Build variables to be used for template expansion. |
 
 ## get\_execution\_requirements
@@ -358,8 +358,8 @@ Returns execution requirements for given action.
 
 | Parameter | Description |
 | --- | --- |
-| `feature_configuration` | [FeatureConfiguration](../builtins/FeatureConfiguration); required  Feature configuration to be queried. |
-| `action_name` | [string](../core/string); required  Name of the action. Has to be one of the names in @bazel\_tools//tools/build\_defs/cc:action\_names.bzl (https://github.com/bazelbuild/bazel/blob/master/tools/build\_defs/cc/action\_names.bzl) |
+| `feature_configuration` | [FeatureConfiguration](/versions/9.0.0/rules/lib/builtins/FeatureConfiguration); required  Feature configuration to be queried. |
+| `action_name` | [string](/versions/9.0.0/rules/lib/core/string); required  Name of the action. Has to be one of the names in @bazel\_tools//tools/build\_defs/cc:action\_names.bzl (https://github.com/bazelbuild/bazel/blob/master/tools/build\_defs/cc/action\_names.bzl) |
 
 ## get\_memory\_inefficient\_command\_line
 
@@ -373,8 +373,8 @@ Returns flattened command line flags for given action, using given variables for
 
 | Parameter | Description |
 | --- | --- |
-| `feature_configuration` | [FeatureConfiguration](../builtins/FeatureConfiguration); required  Feature configuration to be queried. |
-| `action_name` | [string](../core/string); required  Name of the action. Has to be one of the names in @bazel\_tools//tools/build\_defs/cc:action\_names.bzl (https://github.com/bazelbuild/bazel/blob/master/tools/build\_defs/cc/action\_names.bzl) |
+| `feature_configuration` | [FeatureConfiguration](/versions/9.0.0/rules/lib/builtins/FeatureConfiguration); required  Feature configuration to be queried. |
+| `action_name` | [string](/versions/9.0.0/rules/lib/core/string); required  Name of the action. Has to be one of the names in @bazel\_tools//tools/build\_defs/cc:action\_names.bzl (https://github.com/bazelbuild/bazel/blob/master/tools/build\_defs/cc/action\_names.bzl) |
 | `variables` | Variables; required  Build variables to be used for template expansions. |
 
 ## get\_tool\_for\_action
@@ -389,8 +389,8 @@ Returns tool path for given action.
 
 | Parameter | Description |
 | --- | --- |
-| `feature_configuration` | [FeatureConfiguration](../builtins/FeatureConfiguration); required  Feature configuration to be queried. |
-| `action_name` | [string](../core/string); required  Name of the action. Has to be one of the names in @bazel\_tools//tools/build\_defs/cc:action\_names.bzl (https://github.com/bazelbuild/bazel/blob/master/tools/build\_defs/cc/action\_names.bzl) |
+| `feature_configuration` | [FeatureConfiguration](/versions/9.0.0/rules/lib/builtins/FeatureConfiguration); required  Feature configuration to be queried. |
+| `action_name` | [string](/versions/9.0.0/rules/lib/core/string); required  Name of the action. Has to be one of the names in @bazel\_tools//tools/build\_defs/cc:action\_names.bzl (https://github.com/bazelbuild/bazel/blob/master/tools/build\_defs/cc/action\_names.bzl) |
 
 ## is\_enabled
 
@@ -404,8 +404,8 @@ Returns True if given feature is enabled in the feature configuration.
 
 | Parameter | Description |
 | --- | --- |
-| `feature_configuration` | [FeatureConfiguration](../builtins/FeatureConfiguration); required  Feature configuration to be queried. |
-| `feature_name` | [string](../core/string); required  Name of the feature. |
+| `feature_configuration` | [FeatureConfiguration](/versions/9.0.0/rules/lib/builtins/FeatureConfiguration); required  Feature configuration to be queried. |
+| `feature_name` | [string](/versions/9.0.0/rules/lib/core/string); required  Name of the feature. |
 
 ## link
 
@@ -419,20 +419,20 @@ Should be used for C++ transitive linking.
 
 | Parameter | Description |
 | --- | --- |
-| `actions` | [actions](../builtins/actions); required  `actions` object. |
-| `name` | [string](../core/string); required  This is used for naming the output artifacts of actions created by this method. |
-| `feature_configuration` | [FeatureConfiguration](../builtins/FeatureConfiguration); required  `feature_configuration` to be queried. |
+| `actions` | [actions](/versions/9.0.0/rules/lib/builtins/actions); required  `actions` object. |
+| `name` | [string](/versions/9.0.0/rules/lib/core/string); required  This is used for naming the output artifacts of actions created by this method. |
+| `feature_configuration` | [FeatureConfiguration](/versions/9.0.0/rules/lib/builtins/FeatureConfiguration); required  `feature_configuration` to be queried. |
 | `cc_toolchain` | Info; required  `CcToolchainInfo` provider to be used. |
-| `language` | [string](../core/string); default is `'c++'`  Only C++ supported for now. Do not use this parameter. |
-| `output_type` | [string](../core/string); default is `'executable'`  Can be either 'executable' or 'dynamic\_library'. |
-| `link_deps_statically` | [bool](../core/bool); default is `True`  True to link dependencies statically, False dynamically. |
-| `compilation_outputs` | [CcCompilationOutputs](../builtins/CcCompilationOutputs); or `None`; default is `None`  Compilation outputs containing object files to link. |
-| `linking_contexts` | [sequence](../core/list); default is `[]`  Linking contexts from dependencies to be linked into the linking context generated by this rule. |
-| `user_link_flags` | [sequence](../core/list); default is `[]`  Additional list of linker options. |
-| `stamp` | [int](../core/int); default is `0`  Whether to include build information in the linked executable, if output\_type is 'executable'. If 1, build information is always included. If 0 (the default build information is always excluded. If -1, uses the default behavior, which may be overridden by the --[no]stamp flag. This should be unset (or set to 0) when generating the executable output for test rules. |
-| `additional_inputs` | [sequence](../core/list); or [depset](../builtins/depset); default is `[]`  For additional inputs to the linking action, e.g.: linking scripts. |
-| `additional_outputs` | [sequence](../core/list); default is `[]`  For additional outputs to the linking action, e.g.: map files. |
-| `variables_extension` | [dict](../core/dict); default is `{}`  Additional variables to pass to the toolchain configuration when create link command line. |
+| `language` | [string](/versions/9.0.0/rules/lib/core/string); default is `'c++'`  Only C++ supported for now. Do not use this parameter. |
+| `output_type` | [string](/versions/9.0.0/rules/lib/core/string); default is `'executable'`  Can be either 'executable' or 'dynamic\_library'. |
+| `link_deps_statically` | [bool](/versions/9.0.0/rules/lib/core/bool); default is `True`  True to link dependencies statically, False dynamically. |
+| `compilation_outputs` | [CcCompilationOutputs](/versions/9.0.0/rules/lib/builtins/CcCompilationOutputs); or `None`; default is `None`  Compilation outputs containing object files to link. |
+| `linking_contexts` | [sequence](/versions/9.0.0/rules/lib/core/list); default is `[]`  Linking contexts from dependencies to be linked into the linking context generated by this rule. |
+| `user_link_flags` | [sequence](/versions/9.0.0/rules/lib/core/list); default is `[]`  Additional list of linker options. |
+| `stamp` | [int](/versions/9.0.0/rules/lib/core/int); default is `0`  Whether to include build information in the linked executable, if output\_type is 'executable'. If 1, build information is always included. If 0 (the default build information is always excluded. If -1, uses the default behavior, which may be overridden by the --[no]stamp flag. This should be unset (or set to 0) when generating the executable output for test rules. |
+| `additional_inputs` | [sequence](/versions/9.0.0/rules/lib/core/list); or [depset](/versions/9.0.0/rules/lib/builtins/depset); default is `[]`  For additional inputs to the linking action, e.g.: linking scripts. |
+| `additional_outputs` | [sequence](/versions/9.0.0/rules/lib/core/list); default is `[]`  For additional outputs to the linking action, e.g.: map files. |
+| `variables_extension` | [dict](/versions/9.0.0/rules/lib/core/dict); default is `{}`  Additional variables to pass to the toolchain configuration when create link command line. |
 
 ## merge\_cc\_infos
 
@@ -446,8 +446,8 @@ Merges multiple `CcInfo`s into one.
 
 | Parameter | Description |
 | --- | --- |
-| `direct_cc_infos` | [sequence](../core/list); default is `[]`  List of `CcInfo`s to be merged, whose headers will be exported by the direct fields in the returned provider. |
-| `cc_infos` | [sequence](../core/list); default is `[]`  List of `CcInfo`s to be merged, whose headers will not be exported by the direct fields in the returned provider. |
+| `direct_cc_infos` | [sequence](/versions/9.0.0/rules/lib/core/list); default is `[]`  List of `CcInfo`s to be merged, whose headers will be exported by the direct fields in the returned provider. |
+| `cc_infos` | [sequence](/versions/9.0.0/rules/lib/core/list); default is `[]`  List of `CcInfo`s to be merged, whose headers will not be exported by the direct fields in the returned provider. |
 
 ## merge\_compilation\_contexts
 
@@ -461,7 +461,7 @@ Merges multiple `CompilationContexts`s into one.
 
 | Parameter | Description |
 | --- | --- |
-| `compilation_contexts` | [sequence](../core/list); default is `[]`  List of `CompilationContexts`s to be merged. The headers of each context will be exported by the direct fields in the returned provider. |
+| `compilation_contexts` | [sequence](/versions/9.0.0/rules/lib/core/list); default is `[]`  List of `CompilationContexts`s to be merged. The headers of each context will be exported by the direct fields in the returned provider. |
 
 ## merge\_compilation\_outputs
 
@@ -475,4 +475,4 @@ Merge compilation outputs.
 
 | Parameter | Description |
 | --- | --- |
-| `compilation_outputs` | [sequence](../core/list); default is `[]` |
\ No newline at end of file
+| `compilation_outputs` | [sequence](/versions/9.0.0/rules/lib/core/list); default is `[]` |
\ No newline at end of file
diff --git a/versions/9.0.0/rules/lib/toplevel/config.mdx b/versions/9.0.0/rules/lib/toplevel/config.mdx
index 3817d34e..506271a2 100644
--- a/versions/9.0.0/rules/lib/toplevel/config.mdx
+++ b/versions/9.0.0/rules/lib/toplevel/config.mdx
@@ -37,7 +37,7 @@ A bool-typed build setting
 
 | Parameter | Description |
 | --- | --- |
-| `flag` | [bool](../core/bool); default is `False` |
+| `flag` | [bool](/versions/9.0.0/rules/lib/core/bool); default is `False` |
 
 ## exec
 
@@ -51,7 +51,7 @@ Creates an execution transition.
 
 | Parameter | Description |
 | --- | --- |
-| `exec_group` | [string](../core/string); or `None`; default is `None`  The name of the exec group whose execution platform this transition will use. If not provided, this exec transition will use the target's default execution platform. |
+| `exec_group` | [string](/versions/9.0.0/rules/lib/core/string); or `None`; default is `None`  The name of the exec group whose execution platform this transition will use. If not provided, this exec transition will use the target's default execution platform. |
 
 ## int
 
@@ -65,7 +65,7 @@ An integer-typed build setting
 
 | Parameter | Description |
 | --- | --- |
-| `flag` | [bool](../core/bool); default is `False`  Whether or not this build setting is callable on the command line. |
+| `flag` | [bool](/versions/9.0.0/rules/lib/core/bool); default is `False`  Whether or not this build setting is callable on the command line. |
 
 ## none
 
@@ -87,8 +87,8 @@ A string-typed build setting
 
 | Parameter | Description |
 | --- | --- |
-| `flag` | [bool](../core/bool); default is `False`  Whether or not this build setting is callable on the command line. |
-| `allow_multiple` | [bool](../core/bool); default is `False`  Deprecated, use a `string_list` setting with `repeatable = True` instead. If set, this flag is allowed to be set multiple times on the command line. The Value of the flag as accessed in transitions and build setting implementation function will be a list of strings. Insertion order and repeated values are both maintained. This list can be post-processed in the build setting implementation function if different behavior is desired. |
+| `flag` | [bool](/versions/9.0.0/rules/lib/core/bool); default is `False`  Whether or not this build setting is callable on the command line. |
+| `allow_multiple` | [bool](/versions/9.0.0/rules/lib/core/bool); default is `False`  Deprecated, use a `string_list` setting with `repeatable = True` instead. If set, this flag is allowed to be set multiple times on the command line. The Value of the flag as accessed in transitions and build setting implementation function will be a list of strings. Insertion order and repeated values are both maintained. This list can be post-processed in the build setting implementation function if different behavior is desired. |
 
 ## string\_list
 
@@ -102,8 +102,8 @@ A string list-typed build setting. On the command line pass a list using comma-s
 
 | Parameter | Description |
 | --- | --- |
-| `flag` | [bool](../core/bool); default is `False`  Whether or not this build setting is callable on the command line. |
-| `repeatable` | [bool](../core/bool); default is `False`  If set, instead of expecting a comma-separated value, this flag is allowed to be set multiple times on the command line with each individual value treated as a single string to add to the list value. Insertion order and repeated values are both maintained. This list can be post-processed in the build setting implementation function if different behavior is desired. |
+| `flag` | [bool](/versions/9.0.0/rules/lib/core/bool); default is `False`  Whether or not this build setting is callable on the command line. |
+| `repeatable` | [bool](/versions/9.0.0/rules/lib/core/bool); default is `False`  If set, instead of expecting a comma-separated value, this flag is allowed to be set multiple times on the command line with each individual value treated as a single string to add to the list value. Insertion order and repeated values are both maintained. This list can be post-processed in the build setting implementation function if different behavior is desired. |
 
 ## string\_set
 
@@ -119,8 +119,8 @@ Unlike with a `string_list`, the order of the elements doesn't matter and only a
 
 | Parameter | Description |
 | --- | --- |
-| `flag` | [bool](../core/bool); default is `False`  Whether or not this build setting is callable on the command line. |
-| `repeatable` | [bool](../core/bool); default is `False`  If set, instead of expecting a comma-separated value, this flag is allowed to be set multiple times on the command line with each individual value treated as a single string to add to the set value. Only a single instance of repeated values is maintained and the insertion order does not matter. |
+| `flag` | [bool](/versions/9.0.0/rules/lib/core/bool); default is `False`  Whether or not this build setting is callable on the command line. |
+| `repeatable` | [bool](/versions/9.0.0/rules/lib/core/bool); default is `False`  If set, instead of expecting a comma-separated value, this flag is allowed to be set multiple times on the command line with each individual value treated as a single string to add to the set value. Only a single instance of repeated values is maintained and the insertion order does not matter. |
 
 ## target
 
diff --git a/versions/9.0.0/rules/lib/toplevel/config_common.mdx b/versions/9.0.0/rules/lib/toplevel/config_common.mdx
index 9169b17a..c92853f1 100644
--- a/versions/9.0.0/rules/lib/toplevel/config_common.mdx
+++ b/versions/9.0.0/rules/lib/toplevel/config_common.mdx
@@ -29,5 +29,5 @@ Declare a rule's dependency on a toolchain type.
 
 | Parameter | Description |
 | --- | --- |
-| `name` | [string](../core/string); or [Label](../builtins/Label); required  The toolchain type that is required. |
-| `mandatory` | [bool](../core/bool); default is `True`  Whether the toolchain type is mandatory or optional. |
\ No newline at end of file
+| `name` | [string](/versions/9.0.0/rules/lib/core/string); or [Label](/versions/9.0.0/rules/lib/builtins/Label); required  The toolchain type that is required. |
+| `mandatory` | [bool](/versions/9.0.0/rules/lib/core/bool); default is `True`  Whether the toolchain type is mandatory or optional. |
\ No newline at end of file
diff --git a/versions/9.0.0/rules/lib/toplevel/coverage_common.mdx b/versions/9.0.0/rules/lib/toplevel/coverage_common.mdx
index d29ebc2a..5a9ed053 100644
--- a/versions/9.0.0/rules/lib/toplevel/coverage_common.mdx
+++ b/versions/9.0.0/rules/lib/toplevel/coverage_common.mdx
@@ -14,15 +14,15 @@ Helper functions to access coverage-related infrastructure.
 InstrumentedFilesInfo coverage_common.instrumented_files_info(ctx, *, source_attributes=[], dependency_attributes=[], extensions=None, metadata_files=[], baseline_coverage_files=None)
 ```
 
-Creates a new [InstrumentedFilesInfo](../providers/InstrumentedFilesInfo) instance. Use this provider to communicate coverage-related attributes of the current build rule.
+Creates a new [InstrumentedFilesInfo](/versions/9.0.0/rules/lib/providers/InstrumentedFilesInfo) instance. Use this provider to communicate coverage-related attributes of the current build rule.
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `ctx` | [ctx](../builtins/ctx); required  The rule context. |
-| `source_attributes` | [sequence](../core/list); default is `[]`  A list of attribute names which contain source files processed by this rule. |
-| `dependency_attributes` | [sequence](../core/list); default is `[]`  A list of attribute names which might provide runtime dependencies (either code dependencies or runfiles). |
-| `extensions` | [sequence](../core/list) of [string](../core/string)s; or `None`; default is `None`  File extensions used to filter files from source\_attributes. For example, 'js'. If not provided (or None), then all files from source\_attributes will be added to instrumented files, if an empty list is provided, then no files from source attributes will be added. |
-| `metadata_files` | [sequence](../core/list) of [File](../builtins/File)s; default is `[]`  Additional files required to generate coverage LCOV files after code execution. e.g. .gcno files for C++. |
-| `baseline_coverage_files` | [sequence](../core/list) of [File](../builtins/File)s; or `None`; default is `None` |
\ No newline at end of file
+| `ctx` | [ctx](/versions/9.0.0/rules/lib/builtins/ctx); required  The rule context. |
+| `source_attributes` | [sequence](/versions/9.0.0/rules/lib/core/list); default is `[]`  A list of attribute names which contain source files processed by this rule. |
+| `dependency_attributes` | [sequence](/versions/9.0.0/rules/lib/core/list); default is `[]`  A list of attribute names which might provide runtime dependencies (either code dependencies or runfiles). |
+| `extensions` | [sequence](/versions/9.0.0/rules/lib/core/list) of [string](/versions/9.0.0/rules/lib/core/string)s; or `None`; default is `None`  File extensions used to filter files from source\_attributes. For example, 'js'. If not provided (or None), then all files from source\_attributes will be added to instrumented files, if an empty list is provided, then no files from source attributes will be added. |
+| `metadata_files` | [sequence](/versions/9.0.0/rules/lib/core/list) of [File](/versions/9.0.0/rules/lib/builtins/File)s; default is `[]`  Additional files required to generate coverage LCOV files after code execution. e.g. .gcno files for C++. |
+| `baseline_coverage_files` | [sequence](/versions/9.0.0/rules/lib/core/list) of [File](/versions/9.0.0/rules/lib/builtins/File)s; or `None`; default is `None` |
\ No newline at end of file
diff --git a/versions/9.0.0/rules/lib/toplevel/java_common.mdx b/versions/9.0.0/rules/lib/toplevel/java_common.mdx
index 7410f994..88f5513c 100644
--- a/versions/9.0.0/rules/lib/toplevel/java_common.mdx
+++ b/versions/9.0.0/rules/lib/toplevel/java_common.mdx
@@ -35,32 +35,32 @@ Compiles Java source files/jars from the implementation of a Starlark rule and r
 
 | Parameter | Description |
 | --- | --- |
-| `ctx` | [ctx](../builtins/ctx); required  The rule context. |
-| `source_jars` | [sequence](../core/list) of [File](../builtins/File)s; default is `[]`  A list of the jars to be compiled. At least one of source\_jars or source\_files should be specified. |
-| `source_files` | [sequence](../core/list) of [File](../builtins/File)s; default is `[]`  A list of the Java source files to be compiled. At least one of source\_jars or source\_files should be specified. |
-| `output` | [File](../builtins/File); required |
-| `output_source_jar` | [File](../builtins/File); or `None`; default is `None`  The output source jar. Defaults to `{output\_jar}-src.jar` if unset. |
-| `javac_opts` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  A list of the desired javac options. |
-| `deps` | [sequence](../core/list) of [struct](../builtins/struct)s; default is `[]`  A list of dependencies. |
-| `runtime_deps` | [sequence](../core/list) of [struct](../builtins/struct)s; default is `[]`  A list of runtime dependencies. |
-| `exports` | [sequence](../core/list) of [struct](../builtins/struct)s; default is `[]`  A list of exports. |
-| `plugins` | [sequence](../core/list) of [struct](../builtins/struct)s; or [sequence](../core/list) of [struct](../builtins/struct)s; default is `[]`  A list of plugins. |
-| `exported_plugins` | [sequence](../core/list) of [struct](../builtins/struct)s; or [sequence](../core/list) of [struct](../builtins/struct)s; default is `[]`  A list of exported plugins. |
-| `native_libraries` | [sequence](../core/list) of [CcInfo](../providers/CcInfo)s; default is `[]`  CC native library dependencies that are needed for this library. |
-| `annotation_processor_additional_inputs` | [sequence](../core/list) of [File](../builtins/File)s; default is `[]`  A list of inputs that the Java compilation action will take in addition to the Java sources for annotation processing. |
-| `annotation_processor_additional_outputs` | [sequence](../core/list) of [File](../builtins/File)s; default is `[]`  A list of outputs that the Java compilation action will output in addition to the class jar from annotation processing. |
-| `strict_deps` | [string](../core/string); default is `'ERROR'`  A string that specifies how to handle strict deps. Possible values: 'OFF', 'ERROR', 'WARN' and 'DEFAULT'. For more details see [`--strict_java_deps flag`](/versions/9.0.0/docs/user-manual#flag--strict_java_deps). By default 'ERROR'. |
+| `ctx` | [ctx](/versions/9.0.0/rules/lib/builtins/ctx); required  The rule context. |
+| `source_jars` | [sequence](/versions/9.0.0/rules/lib/core/list) of [File](/versions/9.0.0/rules/lib/builtins/File)s; default is `[]`  A list of the jars to be compiled. At least one of source\_jars or source\_files should be specified. |
+| `source_files` | [sequence](/versions/9.0.0/rules/lib/core/list) of [File](/versions/9.0.0/rules/lib/builtins/File)s; default is `[]`  A list of the Java source files to be compiled. At least one of source\_jars or source\_files should be specified. |
+| `output` | [File](/versions/9.0.0/rules/lib/builtins/File); required |
+| `output_source_jar` | [File](/versions/9.0.0/rules/lib/builtins/File); or `None`; default is `None`  The output source jar. Defaults to `{output\_jar}-src.jar` if unset. |
+| `javac_opts` | [sequence](/versions/9.0.0/rules/lib/core/list) of [string](/versions/9.0.0/rules/lib/core/string)s; default is `[]`  A list of the desired javac options. |
+| `deps` | [sequence](/versions/9.0.0/rules/lib/core/list) of [struct](/versions/9.0.0/rules/lib/builtins/struct)s; default is `[]`  A list of dependencies. |
+| `runtime_deps` | [sequence](/versions/9.0.0/rules/lib/core/list) of [struct](/versions/9.0.0/rules/lib/builtins/struct)s; default is `[]`  A list of runtime dependencies. |
+| `exports` | [sequence](/versions/9.0.0/rules/lib/core/list) of [struct](/versions/9.0.0/rules/lib/builtins/struct)s; default is `[]`  A list of exports. |
+| `plugins` | [sequence](/versions/9.0.0/rules/lib/core/list) of [struct](/versions/9.0.0/rules/lib/builtins/struct)s; or [sequence](/versions/9.0.0/rules/lib/core/list) of [struct](/versions/9.0.0/rules/lib/builtins/struct)s; default is `[]`  A list of plugins. |
+| `exported_plugins` | [sequence](/versions/9.0.0/rules/lib/core/list) of [struct](/versions/9.0.0/rules/lib/builtins/struct)s; or [sequence](/versions/9.0.0/rules/lib/core/list) of [struct](/versions/9.0.0/rules/lib/builtins/struct)s; default is `[]`  A list of exported plugins. |
+| `native_libraries` | [sequence](/versions/9.0.0/rules/lib/core/list) of [CcInfo](/versions/9.0.0/rules/lib/providers/CcInfo)s; default is `[]`  CC native library dependencies that are needed for this library. |
+| `annotation_processor_additional_inputs` | [sequence](/versions/9.0.0/rules/lib/core/list) of [File](/versions/9.0.0/rules/lib/builtins/File)s; default is `[]`  A list of inputs that the Java compilation action will take in addition to the Java sources for annotation processing. |
+| `annotation_processor_additional_outputs` | [sequence](/versions/9.0.0/rules/lib/core/list) of [File](/versions/9.0.0/rules/lib/builtins/File)s; default is `[]`  A list of outputs that the Java compilation action will output in addition to the class jar from annotation processing. |
+| `strict_deps` | [string](/versions/9.0.0/rules/lib/core/string); default is `'ERROR'`  A string that specifies how to handle strict deps. Possible values: 'OFF', 'ERROR', 'WARN' and 'DEFAULT'. For more details see [`--strict_java_deps flag`](/versions/9.0.0/docs/user-manual#flag--strict_java_deps). By default 'ERROR'. |
 | `java_toolchain` | Info; required  A JavaToolchainInfo to be used for this compilation. Mandatory. |
 | `bootclasspath` | default is `None`  A BootClassPathInfo to be used for this compilation. If present, overrides the bootclasspath associated with the provided java\_toolchain. |
-| `sourcepath` | [sequence](../core/list) of [File](../builtins/File)s; default is `[]` |
-| `resources` | [sequence](../core/list) of [File](../builtins/File)s; default is `[]` |
-| `resource_jars` | [sequence](../core/list) of [File](../builtins/File)s; default is `[]` |
-| `classpath_resources` | [sequence](../core/list) of [File](../builtins/File)s; default is `[]` |
-| `neverlink` | [bool](../core/bool); default is `False` |
-| `enable_annotation_processing` | [bool](../core/bool); default is `True`  Disables annotation processing in this compilation, causing any annotation processors provided in plugins or in exported\_plugins of deps to be ignored. |
-| `enable_compile_jar_action` | [bool](../core/bool); default is `True`  Enables header compilation or ijar creation. If set to False, it forces use of the full class jar in the compilation classpaths of any dependants. Doing so is intended for use by non-library targets such as binaries that do not have dependants. |
-| `add_exports` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  Allow this library to access the given /. |
-| `add_opens` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  Allow this library to reflectively access the given /. |
+| `sourcepath` | [sequence](/versions/9.0.0/rules/lib/core/list) of [File](/versions/9.0.0/rules/lib/builtins/File)s; default is `[]` |
+| `resources` | [sequence](/versions/9.0.0/rules/lib/core/list) of [File](/versions/9.0.0/rules/lib/builtins/File)s; default is `[]` |
+| `resource_jars` | [sequence](/versions/9.0.0/rules/lib/core/list) of [File](/versions/9.0.0/rules/lib/builtins/File)s; default is `[]` |
+| `classpath_resources` | [sequence](/versions/9.0.0/rules/lib/core/list) of [File](/versions/9.0.0/rules/lib/builtins/File)s; default is `[]` |
+| `neverlink` | [bool](/versions/9.0.0/rules/lib/core/bool); default is `False` |
+| `enable_annotation_processing` | [bool](/versions/9.0.0/rules/lib/core/bool); default is `True`  Disables annotation processing in this compilation, causing any annotation processors provided in plugins or in exported\_plugins of deps to be ignored. |
+| `enable_compile_jar_action` | [bool](/versions/9.0.0/rules/lib/core/bool); default is `True`  Enables header compilation or ijar creation. If set to False, it forces use of the full class jar in the compilation classpaths of any dependants. Doing so is intended for use by non-library targets such as binaries that do not have dependants. |
+| `add_exports` | [sequence](/versions/9.0.0/rules/lib/core/list) of [string](/versions/9.0.0/rules/lib/core/string)s; default is `[]`  Allow this library to access the given /. |
+| `add_opens` | [sequence](/versions/9.0.0/rules/lib/core/list) of [string](/versions/9.0.0/rules/lib/core/string)s; default is `[]`  Allow this library to reflectively access the given /. |
 
 ## JavaRuntimeInfo
 
@@ -90,7 +90,7 @@ Merges the given providers into a single JavaInfo.
 
 | Parameter | Description |
 | --- | --- |
-| `providers` | [sequence](../core/list) of [struct](../builtins/struct)s; required  The list of providers to merge. |
+| `providers` | [sequence](/versions/9.0.0/rules/lib/core/list) of [struct](/versions/9.0.0/rules/lib/builtins/struct)s; required  The list of providers to merge. |
 
 ## pack\_sources
 
@@ -108,10 +108,10 @@ Packs sources and source jars into a single source jar file. The return value is
 
 | Parameter | Description |
 | --- | --- |
-| `actions` | [actions](../builtins/actions); required  ctx.actions |
-| `output_source_jar` | [File](../builtins/File); or `None`; default is `None`  The output source jar. |
-| `sources` | [sequence](../core/list) of [File](../builtins/File)s; default is `[]`  A list of Java source files to be packed into the source jar. |
-| `source_jars` | [sequence](../core/list) of [File](../builtins/File)s; default is `[]`  A list of source jars to be packed into the source jar. |
+| `actions` | [actions](/versions/9.0.0/rules/lib/builtins/actions); required  ctx.actions |
+| `output_source_jar` | [File](/versions/9.0.0/rules/lib/builtins/File); or `None`; default is `None`  The output source jar. |
+| `sources` | [sequence](/versions/9.0.0/rules/lib/core/list) of [File](/versions/9.0.0/rules/lib/builtins/File)s; default is `[]`  A list of Java source files to be packed into the source jar. |
+| `source_jars` | [sequence](/versions/9.0.0/rules/lib/core/list) of [File](/versions/9.0.0/rules/lib/builtins/File)s; default is `[]`  A list of source jars to be packed into the source jar. |
 | `java_toolchain` | Info; required  A JavaToolchainInfo to used to find the ijar tool. |
 
 ## run\_ijar
@@ -126,9 +126,9 @@ Runs ijar on a jar, stripping it of its method bodies. This helps reduce rebuild
 
 | Parameter | Description |
 | --- | --- |
-| `actions` | [actions](../builtins/actions); required  ctx.actions |
-| `jar` | [File](../builtins/File); required  The jar to run ijar on. |
-| `target_label` | [Label](../builtins/Label); or `None`; default is `None`  A target label to stamp the jar with. Used for `add_dep` support. Typically, you would pass `ctx.label` to stamp the jar with the current rule's label. |
+| `actions` | [actions](/versions/9.0.0/rules/lib/builtins/actions); required  ctx.actions |
+| `jar` | [File](/versions/9.0.0/rules/lib/builtins/File); required  The jar to run ijar on. |
+| `target_label` | [Label](/versions/9.0.0/rules/lib/builtins/Label); or `None`; default is `None`  A target label to stamp the jar with. Used for `add_dep` support. Typically, you would pass `ctx.label` to stamp the jar with the current rule's label. |
 | `java_toolchain` | Info; required  A JavaToolchainInfo to used to find the ijar tool. |
 
 ## stamp\_jar
@@ -143,7 +143,7 @@ Stamps a jar with a target label for `add_dep` support. The return value is typi
 
 | Parameter | Description |
 | --- | --- |
-| `actions` | [actions](../builtins/actions); required  ctx.actions |
-| `jar` | [File](../builtins/File); required  The jar to run stamp\_jar on. |
-| `target_label` | [Label](../builtins/Label); required  A target label to stamp the jar with. Used for `add_dep` support. Typically, you would pass `ctx.label` to stamp the jar with the current rule's label. |
+| `actions` | [actions](/versions/9.0.0/rules/lib/builtins/actions); required  ctx.actions |
+| `jar` | [File](/versions/9.0.0/rules/lib/builtins/File); required  The jar to run stamp\_jar on. |
+| `target_label` | [Label](/versions/9.0.0/rules/lib/builtins/Label); required  A target label to stamp the jar with. Used for `add_dep` support. Typically, you would pass `ctx.label` to stamp the jar with the current rule's label. |
 | `java_toolchain` | Info; required  A JavaToolchainInfo to used to find the stamp\_jar tool. |
\ No newline at end of file
diff --git a/versions/9.0.0/rules/lib/toplevel/native.mdx b/versions/9.0.0/rules/lib/toplevel/native.mdx
index 508daca9..803ad73c 100644
--- a/versions/9.0.0/rules/lib/toplevel/native.mdx
+++ b/versions/9.0.0/rules/lib/toplevel/native.mdx
@@ -47,7 +47,7 @@ If possible, use this function only in [implementation functions of rule finaliz
 
 | Parameter | Description |
 | --- | --- |
-| `name` | [string](../core/string); required |
+| `name` | [string](/versions/9.0.0/rules/lib/core/string); required |
 
 ## existing\_rules
 
@@ -73,9 +73,9 @@ Specifies a list of files belonging to this package that are exported to other p
 
 | Parameter | Description |
 | --- | --- |
-| `srcs` | [sequence](../core/list) of [string](../core/string)s; required  The list of files to export. |
-| `visibility` | [sequence](../core/list); or `None`; default is `None`  A visibility declaration can to be specified. The files will be visible to the targets specified. If no visibility is specified, the files will be visible to every package. |
-| `licenses` | [sequence](../core/list) of [string](../core/string)s; or `None`; default is `None`  Licenses to be specified. |
+| `srcs` | [sequence](/versions/9.0.0/rules/lib/core/list) of [string](/versions/9.0.0/rules/lib/core/string)s; required  The list of files to export. |
+| `visibility` | [sequence](/versions/9.0.0/rules/lib/core/list); or `None`; default is `None`  A visibility declaration can to be specified. The files will be visible to the targets specified. If no visibility is specified, the files will be visible to every package. |
+| `licenses` | [sequence](/versions/9.0.0/rules/lib/core/list) of [string](/versions/9.0.0/rules/lib/core/string)s; or `None`; default is `None`  Licenses to be specified. |
 
 ## glob
 
@@ -94,9 +94,9 @@ If the `exclude_directories` argument is enabled (set to `1`), files of type dir
 
 | Parameter | Description |
 | --- | --- |
-| `include` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  The list of glob patterns to include. |
-| `exclude` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  The list of glob patterns to exclude. |
-| `exclude_directories` | [int](../core/int); default is `1`  A flag whether to exclude directories or not. |
+| `include` | [sequence](/versions/9.0.0/rules/lib/core/list) of [string](/versions/9.0.0/rules/lib/core/string)s; default is `[]`  The list of glob patterns to include. |
+| `exclude` | [sequence](/versions/9.0.0/rules/lib/core/list) of [string](/versions/9.0.0/rules/lib/core/string)s; default is `[]`  The list of glob patterns to exclude. |
+| `exclude_directories` | [int](/versions/9.0.0/rules/lib/core/int); default is `1`  A flag whether to exclude directories or not. |
 | `allow_empty` | default is `unbound`  Whether we allow glob patterns to match nothing. If `allow\_empty` is False, each individual include pattern must match something and also the final result must be non-empty (after the matches of the `exclude` patterns are excluded). |
 
 ## module\_name
@@ -137,9 +137,9 @@ This function defines a set of packages and assigns a label to the group. The la
 
 | Parameter | Description |
 | --- | --- |
-| `name` | [string](../core/string); required  The unique name for this rule. |
-| `packages` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  A complete enumeration of packages in this group. |
-| `includes` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  Other package groups that are included in this one. |
+| `name` | [string](/versions/9.0.0/rules/lib/core/string); required  The unique name for this rule. |
+| `packages` | [sequence](/versions/9.0.0/rules/lib/core/list) of [string](/versions/9.0.0/rules/lib/core/string)s; default is `[]`  A complete enumeration of packages in this group. |
+| `includes` | [sequence](/versions/9.0.0/rules/lib/core/list) of [string](/versions/9.0.0/rules/lib/core/string)s; default is `[]`  Other package groups that are included in this one. |
 
 ## package\_name
 
@@ -155,19 +155,19 @@ The name of the package being evaluated, without the repository name. For exampl
 Label native.package_relative_label(input)
 ```
 
-Converts the input string into a [Label](../builtins/Label) object, in the context of the package currently being initialized (that is, the `BUILD` file for which the current macro is executing). If the input is already a `Label`, it is returned unchanged.
+Converts the input string into a [Label](/versions/9.0.0/rules/lib/builtins/Label) object, in the context of the package currently being initialized (that is, the `BUILD` file for which the current macro is executing). If the input is already a `Label`, it is returned unchanged.
 
 This function may only be called while evaluating a BUILD file and the macros it directly or indirectly calls; it may not be called in (for instance) a rule implementation function.
 
 The result of this function is the same `Label` value as would be produced by passing the given string to a label-valued attribute of a target declared in the BUILD file.
 
-*Usage note:* The difference between this function and [Label()](../builtins/Label#Label) is that `Label()` uses the context of the package of the `.bzl` file that called it, not the package of the `BUILD` file. Use `Label()` when you need to refer to a fixed target that is hardcoded into the macro, such as a compiler. Use `package_relative_label()` when you need to normalize a label string supplied by the BUILD file to a `Label` object. (There is no way to convert a string to a `Label` in the context of a package other than the BUILD file or the calling .bzl file. For that reason, outer macros should always prefer to pass Label objects to inner macros rather than label strings.)[`ctx.package_relative_label()`](ctx#package_relative_label) provides the same functionality within a rule or aspect implementation function.
+*Usage note:* The difference between this function and [Label()](/versions/9.0.0/rules/lib/builtins/Label#Label) is that `Label()` uses the context of the package of the `.bzl` file that called it, not the package of the `BUILD` file. Use `Label()` when you need to refer to a fixed target that is hardcoded into the macro, such as a compiler. Use `package_relative_label()` when you need to normalize a label string supplied by the BUILD file to a `Label` object. (There is no way to convert a string to a `Label` in the context of a package other than the BUILD file or the calling .bzl file. For that reason, outer macros should always prefer to pass Label objects to inner macros rather than label strings.)[`ctx.package_relative_label()`](/versions/9.0.0/rules/lib/toplevel/ctx#package_relative_label) provides the same functionality within a rule or aspect implementation function.
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `input` | [string](../core/string); or [Label](../builtins/Label); required  The input label string or Label object. If a Label object is passed, it's returned as is. |
+| `input` | [string](/versions/9.0.0/rules/lib/core/string); or [Label](/versions/9.0.0/rules/lib/builtins/Label); required  The input label string or Label object. If a Label object is passed, it's returned as is. |
 
 ## repo\_name
 
@@ -200,6 +200,6 @@ Returns a new mutable list of every direct subpackage of the current package, re
 
 | Parameter | Description |
 | --- | --- |
-| `include` | [sequence](../core/list) of [string](../core/string)s; required |
-| `exclude` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  The list of glob patterns to exclude from subpackages scan. |
-| `allow_empty` | [bool](../core/bool); default is `False`  Whether we fail if the call returns an empty list. By default empty list indicates potential error in BUILD file where the call to subpackages() is superflous. Setting to true allows this function to succeed in that case. |
\ No newline at end of file
+| `include` | [sequence](/versions/9.0.0/rules/lib/core/list) of [string](/versions/9.0.0/rules/lib/core/string)s; required |
+| `exclude` | [sequence](/versions/9.0.0/rules/lib/core/list) of [string](/versions/9.0.0/rules/lib/core/string)s; default is `[]`  The list of glob patterns to exclude from subpackages scan. |
+| `allow_empty` | [bool](/versions/9.0.0/rules/lib/core/bool); default is `False`  Whether we fail if the call returns an empty list. By default empty list indicates potential error in BUILD file where the call to subpackages() is superflous. Setting to true allows this function to succeed in that case. |
\ No newline at end of file
diff --git a/versions/9.0.0/rules/lib/toplevel/platform_common.mdx b/versions/9.0.0/rules/lib/toplevel/platform_common.mdx
index 17edc7c5..c549f833 100644
--- a/versions/9.0.0/rules/lib/toplevel/platform_common.mdx
+++ b/versions/9.0.0/rules/lib/toplevel/platform_common.mdx
@@ -18,7 +18,7 @@ Functions for Starlark to interact with the platform APIs.
 Provider platform_common.ConstraintSettingInfo
 ```
 
-The constructor/key for the [ConstraintSettingInfo](../providers/ConstraintSettingInfo) provider.
+The constructor/key for the [ConstraintSettingInfo](/versions/9.0.0/rules/lib/providers/ConstraintSettingInfo) provider.
 *Note: This API is experimental and may change at any time. It is disabled by default, but may be enabled with `--experimental_platforms_api`*
 
 ## ConstraintValueInfo
@@ -27,7 +27,7 @@ The constructor/key for the [ConstraintSettingInfo](../providers/ConstraintSetti
 Provider platform_common.ConstraintValueInfo
 ```
 
-The constructor/key for the [ConstraintValueInfo](../providers/ConstraintValueInfo) provider.
+The constructor/key for the [ConstraintValueInfo](/versions/9.0.0/rules/lib/providers/ConstraintValueInfo) provider.
 *Note: This API is experimental and may change at any time. It is disabled by default, but may be enabled with `--experimental_platforms_api`*
 
 ## PlatformInfo
@@ -36,7 +36,7 @@ The constructor/key for the [ConstraintValueInfo](../providers/ConstraintValueIn
 Provider platform_common.PlatformInfo
 ```
 
-The constructor/key for the [PlatformInfo](../providers/PlatformInfo) provider.
+The constructor/key for the [PlatformInfo](/versions/9.0.0/rules/lib/providers/PlatformInfo) provider.
 *Note: This API is experimental and may change at any time. It is disabled by default, but may be enabled with `--experimental_platforms_api`*
 
 ## TemplateVariableInfo
@@ -45,7 +45,7 @@ The constructor/key for the [PlatformInfo](../providers/PlatformInfo) provider.
 Provider platform_common.TemplateVariableInfo
 ```
 
-The constructor/key for the [TemplateVariableInfo](../providers/TemplateVariableInfo) provider.
+The constructor/key for the [TemplateVariableInfo](/versions/9.0.0/rules/lib/providers/TemplateVariableInfo) provider.
 
 ## ToolchainInfo
 
@@ -53,4 +53,4 @@ The constructor/key for the [TemplateVariableInfo](../providers/TemplateVariable
 Provider platform_common.ToolchainInfo
 ```
 
-The constructor/key for the [ToolchainInfo](../providers/ToolchainInfo) provider.
\ No newline at end of file
+The constructor/key for the [ToolchainInfo](/versions/9.0.0/rules/lib/providers/ToolchainInfo) provider.
\ No newline at end of file
diff --git a/versions/9.0.0/rules/lib/toplevel/testing.mdx b/versions/9.0.0/rules/lib/toplevel/testing.mdx
index 5489113c..dd6de3ee 100644
--- a/versions/9.0.0/rules/lib/toplevel/testing.mdx
+++ b/versions/9.0.0/rules/lib/toplevel/testing.mdx
@@ -24,12 +24,12 @@ The number of transitive dependencies of the test are limited. The limit is cont
 
 | Parameter | Description |
 | --- | --- |
-| `name` | [string](../core/string); required  Name of the target. It should be a Starlark identifier, matching pattern '[A-Za-z\_][A-Za-z0-9\_]\*'. |
-| `implementation` | [function](../core/function); required  The Starlark function implementing this analysis test. It must have exactly one parameter: [ctx](../builtins/ctx). The function is called during the analysis phase. It can access the attributes declared by `attrs` and populated via `attr_values`. The implementation function may not register actions. Instead, it must register a pass/fail result via providing [AnalysisTestResultInfo](../providers/AnalysisTestResultInfo). |
-| `attrs` | [dict](../core/dict); default is `{}`  Dictionary declaring the attributes. See the [rule](../globals/bzl#rule) call. Attributes are allowed to use configuration transitions defined using [analysis\_test\_transition](../globals/bzl#analysis_test_transition). |
-| `fragments` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  List of configuration fragments that are available to the implementation of the analysis test. |
-| `toolchains` | [sequence](../core/list); default is `[]`  The set of toolchains the test requires. See the [rule](../globals/bzl#rule) call. |
-| `attr_values` | [dict](../core/dict) of [string](../core/string)s; default is `{}`  Dictionary of attribute values to pass to the implementation. |
+| `name` | [string](/versions/9.0.0/rules/lib/core/string); required  Name of the target. It should be a Starlark identifier, matching pattern '[A-Za-z\_][A-Za-z0-9\_]\*'. |
+| `implementation` | [function](/versions/9.0.0/rules/lib/core/function); required  The Starlark function implementing this analysis test. It must have exactly one parameter: [ctx](/versions/9.0.0/rules/lib/builtins/ctx). The function is called during the analysis phase. It can access the attributes declared by `attrs` and populated via `attr_values`. The implementation function may not register actions. Instead, it must register a pass/fail result via providing [AnalysisTestResultInfo](/versions/9.0.0/rules/lib/providers/AnalysisTestResultInfo). |
+| `attrs` | [dict](/versions/9.0.0/rules/lib/core/dict); default is `{}`  Dictionary declaring the attributes. See the [rule](/versions/9.0.0/rules/lib/globals/bzl#rule) call. Attributes are allowed to use configuration transitions defined using [analysis\_test\_transition](/versions/9.0.0/rules/lib/globals/bzl#analysis_test_transition). |
+| `fragments` | [sequence](/versions/9.0.0/rules/lib/core/list) of [string](/versions/9.0.0/rules/lib/core/string)s; default is `[]`  List of configuration fragments that are available to the implementation of the analysis test. |
+| `toolchains` | [sequence](/versions/9.0.0/rules/lib/core/list); default is `[]`  The set of toolchains the test requires. See the [rule](/versions/9.0.0/rules/lib/globals/bzl#rule) call. |
+| `attr_values` | [dict](/versions/9.0.0/rules/lib/core/dict) of [string](/versions/9.0.0/rules/lib/core/string)s; default is `{}`  Dictionary of attribute values to pass to the implementation. |
 
 ## ExecutionInfo
 
@@ -37,7 +37,7 @@ The number of transitive dependencies of the test are limited. The limit is cont
 ExecutionInfo testing.ExecutionInfo
 ```
 
-[testing.ExecutionInfo](../providers/ExecutionInfo) provider key/constructor
+[testing.ExecutionInfo](/versions/9.0.0/rules/lib/providers/ExecutionInfo) provider key/constructor
 
 ## TestEnvironment
 
@@ -51,5 +51,5 @@ RunEnvironmentInfo testing.TestEnvironment(environment, inherited_environment=[]
 
 | Parameter | Description |
 | --- | --- |
-| `environment` | [dict](../core/dict); required  A map of string keys and values that represent environment variables and their values. These will be made available during the test execution. |
-| `inherited_environment` | [sequence](../core/list) of [string](../core/string)s; default is `[]`  A sequence of names of environment variables. These variables are made available during the test execution with their current value taken from the shell environment. If a variable is contained in both `environment` and `inherited_environment`, the value inherited from the shell environment will take precedence if set. |
\ No newline at end of file
+| `environment` | [dict](/versions/9.0.0/rules/lib/core/dict); required  A map of string keys and values that represent environment variables and their values. These will be made available during the test execution. |
+| `inherited_environment` | [sequence](/versions/9.0.0/rules/lib/core/list) of [string](/versions/9.0.0/rules/lib/core/string)s; default is `[]`  A sequence of names of environment variables. These variables are made available during the test execution with their current value taken from the shell environment. If a variable is contained in both `environment` and `inherited_environment`, the value inherited from the shell environment will take precedence if set. |
\ No newline at end of file
diff --git a/versions/9.0.0/rules/macro-tutorial.mdx b/versions/9.0.0/rules/macro-tutorial.mdx
index 95c67ca9..1088e0cd 100644
--- a/versions/9.0.0/rules/macro-tutorial.mdx
+++ b/versions/9.0.0/rules/macro-tutorial.mdx
@@ -5,7 +5,7 @@ title: 'Creating a Symbolic Macro'
 IMPORTANT: This tutorial is for [*symbolic macros*](/versions/9.0.0/extending/macros) – the new
 macro system introduced in Bazel 8. If you need to support older Bazel versions,
 you will want to write a [legacy macro](/versions/9.0.0/extending/legacy-macros) instead; take
-a look at [Creating a Legacy Macro](legacy-macro-tutorial).
+a look at [Creating a Legacy Macro](/versions/9.0.0/rules/legacy-macro-tutorial).
 
 Imagine that you need to run a tool as part of your build. For example, you
 may want to generate or preprocess a source file, or compress a binary. In this
diff --git a/versions/9.0.0/rules/performance.mdx b/versions/9.0.0/rules/performance.mdx
index b0c98336..960ccd79 100644
--- a/versions/9.0.0/rules/performance.mdx
+++ b/versions/9.0.0/rules/performance.mdx
@@ -15,7 +15,7 @@ widespread use.
 ## Use depsets {#use-depsets}
 
 Whenever you are rolling up information from rule dependencies you should use
-[depsets](lib/depset). Only use plain lists or dicts to publish information
+[depsets](/versions/9.0.0/rules/lib/builtins/depset). Only use plain lists or dicts to publish information
 local to the current rule.
 
 A depset represents information as a nested graph which enables sharing.
@@ -73,7 +73,7 @@ See the [depset overview](/versions/9.0.0/extending/depsets) page for more infor
 ### Avoid calling `depset.to_list()` {#avoid-depset-to-list}
 
 You can coerce a depset to a flat list using
-[`to_list()`](lib/depset#to_list), but doing so usually results in O(N^2)
+[`to_list()`](/versions/9.0.0/rules/lib/builtins/depset#to_list), but doing so usually results in O(N^2)
 cost. If at all possible, avoid any flattening of depsets except for debugging
 purposes.
 
@@ -115,7 +115,7 @@ x = depset(transitive = [i.deps for i in inputs])
 
 ## Use ctx.actions.args() for command lines {#ctx-actions-args}
 
-When building command lines you should use [ctx.actions.args()](lib/Args).
+When building command lines you should use [ctx.actions.args()](/versions/9.0.0/rules/lib/builtins/Args).
 This defers expansion of any depsets to the execution phase.
 
 Apart from being strictly faster, this will reduce the memory consumption of
@@ -126,11 +126,11 @@ Here are some tricks:
 * Pass depsets and lists directly as arguments, instead of flattening them
 yourself. They will get expanded by `ctx.actions.args()` for you.
 If you need any transformations on the depset contents, look at
-[ctx.actions.args#add](lib/Args#add) to see if anything fits the bill.
+[ctx.actions.args#add](/versions/9.0.0/rules/lib/builtins/Args#add) to see if anything fits the bill.
 
 * Are you passing `File#path` as arguments? No need. Any
-[File](lib/File) is automatically turned into its
-[path](lib/File#path), deferred to expansion time.
+[File](/versions/9.0.0/rules/lib/builtins/File) is automatically turned into its
+[path](/versions/9.0.0/rules/lib/builtins/File#path), deferred to expansion time.
 
 * Avoid constructing strings by concatenating them together.
 The best string argument is a constant as its memory will be shared between
@@ -138,10 +138,10 @@ all instances of your rule.
 
 * If the args are too long for the command line an `ctx.actions.args()` object
 can be conditionally or unconditionally written to a param file using
-[`ctx.actions.args#use_param_file`](lib/Args#use_param_file). This is
+[`ctx.actions.args#use_param_file`](/versions/9.0.0/rules/lib/builtins/Args#use_param_file). This is
 done behind the scenes when the action is executed. If you need to explicitly
 control the params file you can write it manually using
-[`ctx.actions.write`](lib/actions#write).
+[`ctx.actions.write`](/versions/9.0.0/rules/lib/builtins/actions#write).
 
 Example:
 
@@ -176,7 +176,7 @@ def _to_short_path(f):
 
 ## Transitive action inputs should be depsets {#transitive-action-inputs}
 
-When building an action using [ctx.actions.run](lib/actions?#run), do not
+When building an action using [ctx.actions.run](/versions/9.0.0/rules/lib/builtins/actions#run), do not
 forget that the `inputs` field accepts a depset. Use this whenever inputs are
 collected from dependencies transitively.
 
diff --git a/versions/9.0.0/rules/rules-tutorial.mdx b/versions/9.0.0/rules/rules-tutorial.mdx
index 23c86962..9ec7e32b 100644
--- a/versions/9.0.0/rules/rules-tutorial.mdx
+++ b/versions/9.0.0/rules/rules-tutorial.mdx
@@ -31,9 +31,9 @@ foo_binary = rule(
 )
 ```
 
-When you call the [`rule`](lib/globals#rule) function, you
+When you call the [`rule`](/versions/9.0.0/rules/lib/globals#rule) function, you
 must define a callback function. The logic will go there, but you
-can leave the function empty for now. The [`ctx`](lib/ctx) argument
+can leave the function empty for now. The [`ctx`](/versions/9.0.0/rules/lib/builtins/ctx) argument
 provides information about the target.
 
 You can load the rule and use it from a `BUILD` file.
@@ -86,10 +86,10 @@ foo_binary(name = "bin1")
 foo_binary(name = "bin2")
 ```
 
-[`ctx.label`](lib/ctx#label)
+[`ctx.label`](/versions/9.0.0/rules/lib/builtins/ctx#label)
 corresponds to the label of the target being analyzed. The `ctx` object has
 many useful fields and methods; you can find an exhaustive list in the
-[API reference](lib/ctx).
+[API reference](/versions/9.0.0/rules/lib/builtins/ctx).
 
 Query the code:
 
@@ -145,7 +145,7 @@ bin2
 ```
 
 Whenever you declare a file, you have to tell Bazel how to generate it by
-creating an action. Use [`ctx.actions.write`](lib/actions#write),
+creating an action. Use [`ctx.actions.write`](/versions/9.0.0/rules/lib/builtins/actions#write),
 to create a file with the given content.
 
 ```python
@@ -200,7 +200,7 @@ You have successfully generated a file!
 ## Attributes
 
 To make the rule more useful, add new attributes using
-[the `attr` module](lib/attr) and update the rule definition.
+[the `attr` module](/versions/9.0.0/rules/lib/toplevel/attr) and update the rule definition.
 
 Add a string attribute called `username`:
 
@@ -236,22 +236,22 @@ def _foo_binary_impl(ctx):
 ```
 
 Note that you can make the attribute mandatory or set a default value. Look at
-the documentation of [`attr.string`](lib/attr#string).
-You may also use other types of attributes, such as [boolean](lib/attr#bool)
-or [list of integers](lib/attr#int_list).
+the documentation of [`attr.string`](/versions/9.0.0/rules/lib/toplevel/attr#string).
+You may also use other types of attributes, such as [boolean](/versions/9.0.0/rules/lib/toplevel/attr#bool)
+or [list of integers](/versions/9.0.0/rules/lib/toplevel/attr#int_list).
 
 ## Dependencies
 
-Dependency attributes, such as [`attr.label`](lib/attr#label)
-and [`attr.label_list`](lib/attr#label_list),
+Dependency attributes, such as [`attr.label`](/versions/9.0.0/rules/lib/toplevel/attr#label)
+and [`attr.label_list`](/versions/9.0.0/rules/lib/toplevel/attr#label_list),
 declare a dependency from the target that owns the attribute to the target whose
 label appears in the attribute's value. This kind of attribute forms the basis
 of the target graph.
 
 In the `BUILD` file, the target label appears as a string object, such as
 `//pkg:name`. In the implementation function, the target will be accessible as a
-[`Target`](lib/Target) object. For example, view the files returned
-by the target using [`Target.files`](lib/Target#modules.Target.files).
+[`Target`](/versions/9.0.0/rules/lib/builtins/Target) object. For example, view the files returned
+by the target using [`Target.files`](/versions/9.0.0/rules/lib/builtins/Target#modules.Target.files).
 
 ### Multiple files
 
@@ -294,7 +294,7 @@ implementation function, but this has two problems. First, as the template gets
 bigger, it becomes more memory efficient to put it in a separate file and avoid
 constructing large strings during the analysis phase. Second, using a separate
 file is more convenient for the user. Instead, use
-[`ctx.actions.expand_template`](lib/actions#expand_template),
+[`ctx.actions.expand_template`](/versions/9.0.0/rules/lib/builtins/actions#expand_template),
 which performs substitutions on a template file.
 
 Create a `template` attribute to declare a dependency on the template
diff --git a/versions/9.0.0/rules/testing.mdx b/versions/9.0.0/rules/testing.mdx
index f1cc3671..00ea5bc2 100644
--- a/versions/9.0.0/rules/testing.mdx
+++ b/versions/9.0.0/rules/testing.mdx
@@ -234,7 +234,7 @@ def _inspect_actions_test_impl(ctx):
 ```
 
 Note that `analysistest.target_actions(env)` returns a list of
-[`Action`](lib/Action) objects which represent actions registered by the
+[`Action`](/versions/9.0.0/rules/lib/builtins/Action) objects which represent actions registered by the
 target under test.
 
 ### Verifying rule behavior under different flags {#verifying-rule-behavior}
diff --git a/versions/9.0.0/rules/verbs-tutorial.mdx b/versions/9.0.0/rules/verbs-tutorial.mdx
index 2d1f249a..fd227e16 100644
--- a/versions/9.0.0/rules/verbs-tutorial.mdx
+++ b/versions/9.0.0/rules/verbs-tutorial.mdx
@@ -49,8 +49,7 @@ This pattern can also be seen in the Angular project. The
 produces two targets. The first is a standard `nodejs_test` target which compares
 some generated output against a "golden" file (that is, a file containing the
 expected output). This can be built and run with a normal `bazel
-test` invocation. In `angular-cli`, you can run [one such
-target](https://github.com/angular/angular-cli/blob/e1269cb520871ee29b1a4eec6e6c0e4a94f0b5fc/etc/api/BUILD)
+test` invocation. In `angular-cli`, you can run [one such target](https://github.com/angular/angular-cli/blob/e1269cb520871ee29b1a4eec6e6c0e4a94f0b5fc/etc/api/BUILD)
 with `bazel test //etc/api:angular_devkit_core_api`.
 
 Over time, this golden file may need to be updated for legitimate reasons.
@@ -159,7 +158,7 @@ an imaginary `bazel publish` command.
 It's not immediately obvious what the implementation of the `_sphinx_publisher`
 rule might look like. Often, actions like this write a _launcher_ shell script.
 This method typically involves using
-[`ctx.actions.expand_template`](lib/actions#expand_template)
+[`ctx.actions.expand_template`](/versions/9.0.0/rules/lib/builtins/actions#expand_template)
 to write a very simple shell script, in this case invoking the publisher binary
 with a path to the output of the primary target. This way, the publisher
 implementation can remain generic, the `_sphinx_site` rule can just produce
diff --git a/versions/9.0.0/run/build.mdx b/versions/9.0.0/run/build.mdx
index 76b4ce41..535cadeb 100644
--- a/versions/9.0.0/run/build.mdx
+++ b/versions/9.0.0/run/build.mdx
@@ -626,8 +626,7 @@ Note: Hermeticity means that the action only uses its declared input
 files and no other files in the filesystem, and it only produces its declared
 output files. See [Hermeticity](/versions/9.0.0/basics/hermeticity) for more details.
 
-On some platforms such as [Google Kubernetes
-Engine](https://cloud.google.com/kubernetes-engine/) cluster nodes or Debian,
+On some platforms such as [Google Kubernetes Engine](https://cloud.google.com/kubernetes-engine/) cluster nodes or Debian,
 user namespaces are deactivated by default due to security
 concerns. This can be checked by looking at the file
 `/proc/sys/kernel/unprivileged_userns_clone`: if it exists and contains a 0,
diff --git a/versions/9.0.0/start/android-app.mdx b/versions/9.0.0/start/android-app.mdx
index 4a2cea88..b1ab1f49 100644
--- a/versions/9.0.0/start/android-app.mdx
+++ b/versions/9.0.0/start/android-app.mdx
@@ -39,8 +39,7 @@ In this tutorial you learn how to:
 Before you begin the tutorial, install the following software:
 
 * **Bazel.** To install, follow the [installation instructions](/versions/9.0.0/install).
-* **Android Studio.** To install, follow the steps to [download Android
-  Studio](https://developer.android.com/sdk/index.html).
+* **Android Studio.** To install, follow the steps to [download Android Studio](https://developer.android.com/sdk/index.html).
   Execute the setup wizard to download the SDK and configure your environment.
 * (Optional) **Git.** Use `git` to download the Android app project.
 
@@ -55,8 +54,7 @@ This app has a single button that prints a greeting when clicked:
 
 **Figure 1.** Android app button greeting.
 
-Clone the repository with `git` (or [download the ZIP file
-directly](https://github.com/bazelbuild/examples/archive/master.zip)):
+Clone the repository with `git` (or [download the ZIP file directly](https://github.com/bazelbuild/examples/archive/master.zip)):
 
 ```posix-terminal
 git clone https://github.com/bazelbuild/examples
@@ -106,8 +104,7 @@ A [workspace](/versions/9.0.0/concepts/build-ref#workspace) is a directory that
 source files for one or more software projects, and has a `MODULE.bazel` file at
 its root.
 
-The `MODULE.bazel` file may be empty or may contain references to [external
-dependencies](/versions/9.0.0/external/overview) required to build your project.
+The `MODULE.bazel` file may be empty or may contain references to [external dependencies](/versions/9.0.0/external/overview) required to build your project.
 
 First, run the following command to create an empty `MODULE.bazel` file:
 
@@ -158,8 +155,7 @@ environment variable, and automatically detect the highest API level and the
 latest version of build tools installed within that location.
 
 You can set the `ANDROID_HOME` variable to the location of the Android SDK. Find
-the path to the installed SDK using Android Studio's [SDK
-Manager](https://developer.android.com/studio/intro/update#sdk-manager).
+the path to the installed SDK using Android Studio's [SDK Manager](https://developer.android.com/studio/intro/update#sdk-manager).
 Assuming the SDK is installed to default locations, you can use the following
 commands to set the `ANDROID_HOME` variable:
 
@@ -181,16 +177,14 @@ them permanent, run the following commands:
 | Windows (PowerShell)     | `[System.Environment]::SetEnvironmentVariable('ANDROID_HOME', "$env:LOCALAPPDATA\Android\Sdk", [System.EnvironmentVariableTarget]::User)` |
 
 **Optional:** If you want to compile native code into your Android app, you
-also need to download the [Android
-NDK](https://developer.android.com/ndk/downloads/index.html)
+also need to download the [Android NDK](https://developer.android.com/ndk/downloads/index.html)
 and use `rules_android_ndk` by adding the following line to your `MODULE.bazel` file:
 
 ```python
 bazel_dep(name = "rules_android_ndk", version = "0.1.3")
 ```
 
-For more information, read [Using the Android Native Development Kit with
-Bazel](/versions/9.0.0/docs/android-ndk).
+For more information, read [Using the Android Native Development Kit with Bazel](/versions/9.0.0/docs/android-ndk).
 
 It's not necessary to set the API levels to the same value for the SDK and NDK.
 [This page](https://developer.android.com/ndk/guides/stable_apis.html)
@@ -232,8 +226,7 @@ files or other dependencies. Bazel provides two build rules,
 build an Android app.
 
 For this tutorial, you'll first use the
-`android_library` rule to tell Bazel to build an [Android library
-module](http://developer.android.com/tools/projects/index.html#LibraryProjects)
+`android_library` rule to tell Bazel to build an [Android library module](http://developer.android.com/tools/projects/index.html#LibraryProjects)
 from the app source code and resource files. You'll then use the
 `android_binary` rule to tell Bazel how to build the Android application package.
 
diff --git a/versions/9.0.0/start/cpp.mdx b/versions/9.0.0/start/cpp.mdx
index 7c0dee96..e294d79d 100644
--- a/versions/9.0.0/start/cpp.mdx
+++ b/versions/9.0.0/start/cpp.mdx
@@ -19,8 +19,7 @@ Estimated completion time: 30 minutes.
 ### Prerequisites {#prerequisites}
 
 Start by [installing Bazel](https://bazel.build/versions/9.0.0/install), if you haven't
-already. This tutorial uses Git for source control, so for best results [install
-Git](https://git-scm.com/book/en/v2/Getting-Started-Installing-Git) as well.
+already. This tutorial uses Git for source control, so for best results [install Git](https://git-scm.com/book/en/v2/Getting-Started-Installing-Git) as well.
 
 Next, retrieve the sample project from Bazel's GitHub repository by running the
 following in your command-line tool of choice:
@@ -63,9 +62,7 @@ examples
 ```
 
 There are three sets of files, each set representing a stage in this tutorial.
-In the first stage, you will build a single [target]
-(https://bazel.build/reference/glossary#target) residing in a single [package]
-(https://bazel.build/reference/glossary#package). In the second stage, you will
+In the first stage, you will build a single [target](https://bazel.build/versions/9.0.0/reference/glossary#target) residing in a single [package](https://bazel.build/versions/9.0.0/reference/glossary#package). In the second stage, you will
 build both a binary and a library from a single package. In the third and final
 stage, you will build a project with multiple packages and build it with
 multiple targets.
@@ -86,8 +83,7 @@ It also contains these significant files:
 *   The `MODULE.bazel` file, which identifies the directory and its contents as
     a Bazel workspace and lives at the root of the project's directory
     structure. It's also where you specify your external dependencies.
-*   One or more [`BUILD`
-    files](https://bazel.build/reference/glossary#build-file), which tell Bazel
+*   One or more [`BUILD` files](https://bazel.build/versions/9.0.0/reference/glossary#build-file), which tell Bazel
     how to build different parts of the project. A directory within the
     workspace that contains a `BUILD` file is a
     [package](https://bazel.build/versions/9.0.0/reference/glossary#package). (More on packages
@@ -182,9 +178,7 @@ This results in a printed "`Hello world`" message.
 
 Here's the dependency graph of Stage 1:
 
-![Dependency graph for hello-world displays a single target with a single source
-file.](/versions/9.0.0/docs/images/cpp-tutorial-stage1.png "Dependency graph for hello-world
-displays a single target with a single source file.")
+![Dependency graph for hello-world displays a single target with a single source file.](/versions/9.0.0/docs/images/cpp-tutorial-stage1.png "Dependency graph for hello-world displays a single target with a single source file.")
 
 ### Summary: stage 1 {#summary-stage-1}
 
@@ -231,8 +225,7 @@ cc_binary(
 ```
 
 With this `BUILD` file, Bazel first builds the `hello-greet` library (using
-Bazel's built-in [`cc_library`
-rule](https://bazel.build/reference/be/c-cpp#cc_library)), then the
+Bazel's built-in [`cc_library` rule](https://bazel.build/versions/9.0.0/reference/be/c-cpp#cc_library)), then the
 `hello-world` binary. The `deps` attribute in the `hello-world` target tells
 Bazel that the `hello-greet` library is required to build the `hello-world`
 binary.
@@ -272,10 +265,7 @@ recompiles that file.
 Looking at the dependency graph, you can see that `hello-world` depends on an
 extra input named `hello-greet`:
 
-![Dependency graph for `hello-world` displays dependency changes after
-modification to the file.](/versions/9.0.0/docs/images/cpp-tutorial-stage2.png "Dependency
-graph for `hello-world` displays dependency changes after modification to the
-file.")
+![Dependency graph for `hello-world` displays dependency changes after modification to the file.](/versions/9.0.0/docs/images/cpp-tutorial-stage2.png "Dependency graph for `hello-world` displays dependency changes after modification to the file.")
 
 ### Summary: stage 2 {#summary-stage-2}
 
@@ -343,11 +333,7 @@ in the `lib` package (hence the target label `//lib:hello-time`) - Bazel knows
 this through the `deps` attribute. You can see this reflected in the dependency
 graph:
 
-![Dependency graph for `hello-world` displays how the target in the main package
-depends on the target in the `lib`
-package.](/versions/9.0.0/docs/images/cpp-tutorial-stage3.png "Dependency graph for
-`hello-world` displays how the target in the main package depends on the target
-in the `lib` package.")
+![Dependency graph for `hello-world` displays how the target in the main package depends on the target in the `lib` package.](/versions/9.0.0/docs/images/cpp-tutorial-stage3.png "Dependency graph for `hello-world` displays how the target in the main package depends on the target in the `lib` package.")
 
 For the build to succeed, you make the `//lib:hello-time` target in `lib/BUILD`
 explicitly visible to targets in `main/BUILD` using the visibility attribute.
@@ -395,15 +381,11 @@ Bazel journey.
 You've now completed your first basic build with Bazel, but this is just the
 start. Here are some more resources to continue learning with Bazel:
 
-*   To keep focusing on C++, read about common [C++ build use
-    cases](https://bazel.build/tutorials/cpp-use-cases).
+*   To keep focusing on C++, read about common [C++ build use cases](https://bazel.build/versions/9.0.0/tutorials/cpp-use-cases).
 *   To get started with building other applications with Bazel, see the
-    tutorials for [Java](https://bazel.build/versions/9.0.0/start/java), [Android
-    application](https://bazel.build/start/android-app), or [iOS
-    application](https://bazel.build/start/ios-app).
+    tutorials for [Java](https://bazel.build/versions/9.0.0/start/java), [Android application](https://bazel.build/versions/9.0.0/start/android-app), or [iOS application](https://bazel.build/versions/9.0.0/start/ios-app).
 *   To learn more about working with local and remote repositories, read about
     [external dependencies](https://bazel.build/versions/9.0.0/docs/external).
-*   To learn more about Bazel's other rules, see this [reference
-    guide](https://bazel.build/rules).
+*   To learn more about Bazel's other rules, see this [reference guide](https://bazel.build/versions/9.0.0/rules).
 
 Happy building!
\ No newline at end of file
diff --git a/versions/9.0.0/start/go.mdx b/versions/9.0.0/start/go.mdx
index 54c9eb72..4f8a315c 100644
--- a/versions/9.0.0/start/go.mdx
+++ b/versions/9.0.0/start/go.mdx
@@ -32,8 +32,7 @@ You can check if Go is installed by running `go version` in any directory.
 
 ### Get the sample project {#get-sample}
 
-The Bazel examples are stored in a Git repository, so you'll need to [install
-Git](https://git-scm.com/book/en/v2/Getting-Started-Installing-Git) if you
+The Bazel examples are stored in a Git repository, so you'll need to [install Git](https://git-scm.com/book/en/v2/Getting-Started-Installing-Git) if you
 haven't already. To download the examples repository, run this command:
 
 ```posix-terminal
@@ -171,10 +170,8 @@ rule. Each rule defines [actions](https://bazel.build/versions/9.0.0/reference/g
 Go compile and link actions that produce an executable output file.
 
 Bazel has built-in rules for a few languages like Java and C++. You can find
-their [documentation in the Build
-Encyclopedia](https://bazel.build/reference/be/overview#rules). You can find
-rule sets for many other languages and tools on the [Bazel Central Registry
-(BCR)](https://registry.bazel.build/).
+their [documentation in the Build Encyclopedia](https://bazel.build/versions/9.0.0/reference/be/overview#rules). You can find
+rule sets for many other languages and tools on the [Bazel Central Registry (BCR)](https://registry.bazel.build/).
 
 ## Add a library {#add-library}
 
@@ -448,11 +445,9 @@ learned some core Bazel concepts along the way.
     languages.
 -   For more information on Go, see the
     [rules_go](https://github.com/bazel-contrib/rules_go) module, especially the
-    [Core Go
-    rules](https://github.com/bazel-contrib/rules_go/blob/master/docs/go/core/rules.md)
+    [Core Go rules](https://github.com/bazel-contrib/rules_go/blob/master/docs/go/core/rules.md)
     documentation.
 -   To learn more about working with Bazel modules outside your project, see
     [external dependencies](/versions/9.0.0/docs/external). In particular, for information on
     how to depend on Go modules and toolchains through Bazel's module system,
-    see [Go with
-    bzlmod](https://github.com/bazel-contrib/rules_go/tree/master/docs/go/core/bzlmod.md).
\ No newline at end of file
+    see [Go with bzlmod](https://github.com/bazel-contrib/rules_go/tree/master/docs/go/core/bzlmod.md).
\ No newline at end of file
diff --git a/versions/9.0.0/start/java.mdx b/versions/9.0.0/start/java.mdx
index b5f23c27..43571c07 100644
--- a/versions/9.0.0/start/java.mdx
+++ b/versions/9.0.0/start/java.mdx
@@ -241,8 +241,7 @@ recompiles that file.
 Looking at the dependency graph, you can see that `ProjectRunner` depends on the
 same inputs as it did before, but the structure of the build is different:
 
-![Dependency graph of the target 'ProjectRunner' after adding a dependency](
-/docs/images/tutorial_java_02.svg)
+![Dependency graph of the target 'ProjectRunner' after adding a dependency](/versions/9.0.0/docs/images/tutorial_java_02.svg)
 
 You've now built the project with two targets. The `ProjectRunner` target builds
 one source files and depends on one other target (`:greeter`), which builds
@@ -426,7 +425,7 @@ For more details, see:
 *  The [C++ build tutorial](/versions/9.0.0/start/cpp) to get started with building
    C++ projects with Bazel.
 
-*  The [Android application tutorial](/versions/9.0.0/start/android-app ) and
+*  The [Android application tutorial](/versions/9.0.0/start/android-app) and
    [iOS application tutorial](/versions/9.0.0/start/ios-app)) to get started with
    building mobile applications for Android and iOS with Bazel.
 
diff --git a/versions/9.0.0/tutorials/ccp-toolchain-config.mdx b/versions/9.0.0/tutorials/ccp-toolchain-config.mdx
index 14b05139..d5fc40db 100644
--- a/versions/9.0.0/tutorials/ccp-toolchain-config.mdx
+++ b/versions/9.0.0/tutorials/ccp-toolchain-config.mdx
@@ -29,8 +29,7 @@ uses `clang version 19`, which you can install on your system.
 
 Set up your build environment as follows:
 
-1.  If you have not already done so, [download and install Bazel
-    7.0.2](https://bazel.build/install) or later.
+1.  If you have not already done so, [download and install Bazel 7.0.2](https://bazel.build/versions/9.0.0/install) or later.
 
 2.  Add an empty `MODULE.bazel` file at the root folder.
 
@@ -454,8 +453,7 @@ The key takeaways are:
 
 -   You need to specify a matching `platforms` flag in the command line for
     Bazel to resolve to the toolchain for the same constraint values on the
-    platform. The documentation holds more [information about language specific
-    configuration flags](/versions/9.0.0/concepts/platforms).
+    platform. The documentation holds more [information about language specific configuration flags](/versions/9.0.0/concepts/platforms).
 -   You have to let the toolchain know where the tools live. In this tutorial
     there is a simplified version where you access the tools from the system. If
     you are interested in a more self-contained approach, you can read about
@@ -468,5 +466,4 @@ The key takeaways are:
 
 ## Further reading {#further-reading}
 
-For more details, see [C++ toolchain
-configuration](/versions/9.0.0/docs/cc-toolchain-config-reference)
+For more details, see [C++ toolchain configuration](/versions/9.0.0/docs/cc-toolchain-config-reference)
diff --git a/versions/9.1.0/about/faq.mdx b/versions/9.1.0/about/faq.mdx
new file mode 100644
index 00000000..68fb8234
--- /dev/null
+++ b/versions/9.1.0/about/faq.mdx
@@ -0,0 +1,206 @@
+---
+title: 'FAQ'
+---
+
+If you have questions or need support, see [Getting Help](/versions/9.1.0/help).
+
+## What is Bazel?
+
+Bazel is a tool that automates software builds and tests. Supported build tasks include running compilers and linkers to produce executable programs and libraries, and assembling deployable packages for Android, iOS and other target environments. Bazel is similar to other tools like Make, Ant, Gradle, Buck, Pants and Maven.
+
+## What is special about Bazel?
+
+Bazel was designed to fit the way software is developed at Google. It has the following features:
+
+*   Multi-language support: Bazel supports [many languages](/versions/9.1.0/reference/be/overview), and can be extended to support arbitrary programming languages.
+*   High-level build language: Projects are described in the `BUILD` language, a concise text format that describes a project as sets of small interconnected libraries, binaries and tests. In contrast, with tools like Make, you have to describe individual files and compiler invocations.
+*   Multi-platform support: The same tool and the same `BUILD` files can be used to build software for different architectures, and even different platforms. At Google, we use Bazel to build everything from server applications running on systems in our data centers to client apps running on mobile phones.
+*   Reproducibility: In `BUILD` files, each library, test and binary must specify its direct dependencies completely. Bazel uses this dependency information to know what must be rebuilt when you make changes to a source file, and which tasks can run in parallel. This means that all builds are incremental and will always produce the same result.
+*   Scalable: Bazel can handle large builds; at Google, it is common for a server binary to have 100k source files, and builds where no files were changed take about ~200ms.
+
+## Why doesn’t Google use...?
+
+*   Make, Ninja: These tools give very exact control over what commands get invoked to build files, but it’s up to the user to write rules that are correct.
+    * Users interact with Bazel on a higher level. For example, Bazel has built-in rules for “Java test”, “C++ binary”, and notions such as “target platform” and “host platform”. These rules have been battle tested to be foolproof.
+*   Ant and Maven: Ant and Maven are primarily geared toward Java, while Bazel handles multiple languages. Bazel encourages subdividing codebases in smaller reusable units, and can rebuild only ones that need rebuilding. This speeds up development when working with larger codebases.
+*   Gradle: Bazel configuration files are much more structured than Gradle’s, letting Bazel understand exactly what each action does. This allows for more parallelism and better reproducibility.
+*   Pants, Buck: Both tools were created and developed by ex-Googlers at Twitter and Foursquare, and Facebook respectively. They have been modeled after Bazel, but their feature sets are different, so they aren’t viable alternatives for us.
+
+## Where did Bazel come from?
+
+Bazel is a flavor of the tool that Google uses to build its server software internally. It has expanded to build other software as well, like mobile apps (iOS, Android) that connect to our servers.
+
+## Did you rewrite your internal tool as open-source? Is it a fork?
+
+Bazel shares most of its code with the internal tool and its rules are used for millions of builds every day.
+
+## Why did Google build Bazel?
+
+A long time ago, Google built its software using large, generated Makefiles. These led to slow and unreliable builds, which began to interfere with our developers’ productivity and the company’s agility. Bazel was a way to solve these problems.
+
+## Does Bazel require a build cluster?
+
+Bazel runs build operations locally by default. However, Bazel can also connect to a build cluster for even faster builds and tests. See our documentation on [remote execution and caching](/versions/9.1.0/remote/rbe) and [remote caching](/versions/9.1.0/remote/caching) for further details.
+
+## How does the Google development process work?
+
+For our server code base, we use the following development workflow:
+
+*   All our server code is in a single, gigantic version control system.
+*   Everybody builds their software with Bazel.
+*   Different teams own different parts of the source tree, and make their components available as `BUILD` targets.
+*   Branching is primarily used for managing releases, so everybody develops their software at the head revision.
+
+Bazel is a cornerstone of this philosophy: since Bazel requires all dependencies to be fully specified, we can predict which programs and tests are affected by a change, and vet them before submission.
+
+More background on the development process at Google can be found on the [eng tools blog](http://google-engtools.blogspot.com/).
+
+## Why did you open up Bazel?
+
+Building software should be fun and easy. Slow and unpredictable builds take the fun out of programming.
+
+## Why would I want to use Bazel?
+
+*   Bazel may give you faster build times because it can recompile only the files that need to be recompiled. Similarly, it can skip re-running tests that it knows haven’t changed.
+*   Bazel produces deterministic results. This eliminates skew between incremental and clean builds, laptop and CI system, etc.
+*   Bazel can build different client and server apps with the same tool from the same workspace. For example, you can change a client/server protocol in a single commit, and test that the updated mobile app works with the updated server, building both with the same tool, reaping all the aforementioned benefits of Bazel.
+
+## Can I see examples?
+
+Yes; see a [simple example](https://github.com/bazelbuild/bazel/blob/master/examples/cpp/BUILD)
+or read the [Bazel source code](https://github.com/bazelbuild/bazel/blob/master/src/BUILD) for a more complex example.
+
+## What is Bazel best at?
+
+Bazel shines at building and testing projects with the following properties:
+
+*   Projects with a large codebase
+*   Projects written in (multiple) compiled languages
+*   Projects that deploy on multiple platforms
+*   Projects that have extensive tests
+
+## Where can I run Bazel?
+
+Bazel runs on Linux, macOS (OS X), and Windows.
+
+Porting to other UNIX platforms should be relatively easy, as long as a JDK is available for the platform.
+
+## What should I not use Bazel for?
+
+*   Bazel tries to be smart about caching. This means that it is not good for running build operations whose outputs should not be cached. For example, the following steps should not be run from Bazel:
+    *   A compilation step that fetches data from the internet.
+    *   A test step that connects to the QA instance of your site.
+    *   A deployment step that changes your site’s cloud configuration.
+*   If your build consists of a few long, sequential steps, Bazel may not be able to help much. You’ll get more speed by breaking long steps into smaller, discrete targets that Bazel can run in parallel.
+
+## How stable is Bazel’s feature set?
+
+The core features (C++, Java, and shell rules) have extensive use inside Google, so they are thoroughly tested and have very little churn. Similarly, we test new versions of Bazel across hundreds of thousands of targets every day to find regressions, and we release new versions multiple times every month.
+
+In short, except for features marked as experimental, Bazel should Just Work. Changes to non-experimental rules will be backward compatible. A more detailed list of feature support statuses can be found in our [support document](/versions/9.1.0/contribute/support).
+
+## How stable is Bazel as a binary?
+
+Inside Google, we make sure that Bazel crashes are very rare. This should also hold for our open source codebase.
+
+## How can I start using Bazel?
+
+See [Getting Started](/versions/9.1.0/start/).
+
+## Doesn’t Docker solve the reproducibility problems?
+
+With Docker you can easily create sandboxes with fixed OS releases, for example, Ubuntu 12.04, Fedora 21. This solves the problem of reproducibility for the system environment – that is, “which version of /usr/bin/c++ do I need?”
+
+Docker does not address reproducibility with regard to changes in the source code. Running Make with an imperfectly written Makefile inside a Docker container can still yield unpredictable results.
+
+Inside Google, we check tools into source control for reproducibility. In this way, we can vet changes to tools (“upgrade GCC to 4.6.1”) with the same mechanism as changes to base libraries (“fix bounds check in OpenSSL”).
+
+## Can I build binaries for deployment on Docker?
+
+With Bazel, you can build standalone, statically linked binaries in C/C++, and self-contained jar files for Java. These run with few dependencies on normal UNIX systems, and as such should be simple to install inside a Docker container.
+
+Bazel has conventions for structuring more complex programs, for example, a Java program that consumes a set of data files, or runs another program as subprocess. It is possible to package up such environments as standalone archives, so they can be deployed on different systems, including Docker images.
+
+## Can I build Docker images with Bazel?
+
+Yes, you can use our [Docker rules](https://github.com/bazelbuild/rules_docker) to build reproducible Docker images.
+
+## Will Bazel make my builds reproducible automatically?
+
+For Java and C++ binaries, yes, assuming you do not change the toolchain. If you have build steps that involve custom recipes (for example, executing binaries through a shell script inside a rule), you will need to take some extra care:
+
+*   Do not use dependencies that were not declared. Sandboxed execution (–spawn\_strategy=sandboxed, only on Linux) can help find undeclared dependencies.
+*   Avoid storing timestamps and user-IDs in generated files. ZIP files and other archives are especially prone to this.
+*   Avoid connecting to the network. Sandboxed execution can help here too.
+*   Avoid processes that use random numbers, in particular, dictionary traversal is randomized in many programming languages.
+
+## Do you have binary releases?
+
+Yes, you can find the latest [release binaries](https://github.com/bazelbuild/bazel/releases/latest) and review our [release policy](/versions/9.1.0/release/)
+
+## I use Eclipse/IntelliJ/XCode. How does Bazel interoperate with IDEs?
+
+For IntelliJ, check out the [IntelliJ with Bazel plugin](https://ij.bazel.build/).
+
+For XCode, check out [Tulsi](http://tulsi.bazel.build/).
+
+For Eclipse, check out [E4B plugin](https://github.com/bazelbuild/e4b).
+
+For other IDEs, check out the [blog post](https://blog.bazel.build/2016/06/10/ide-support.html) on how these plugins work.
+
+## I use Jenkins/CircleCI/TravisCI. How does Bazel interoperate with CI systems?
+
+Bazel returns a non-zero exit code if the build or test invocation fails, and this should be enough for basic CI integration. Since Bazel does not need clean builds for correctness, the CI system should not be configured to clean before starting a build/test run.
+
+Further details on exit codes are in the [User Manual](/versions/9.1.0/docs/user-manual).
+
+## What future features can we expect in Bazel?
+
+See our [Roadmaps](/versions/9.1.0/about/roadmap).
+
+## Can I use Bazel for my INSERT LANGUAGE HERE project?
+
+Bazel is extensible. Anyone can add support for new languages. Many languages are supported: see the [build encyclopedia](/versions/9.1.0/reference/be/overview) for a list of recommendations and [awesomebazel.com](https://awesomebazel.com/) for a more comprehensive list.
+
+If you would like to develop extensions or learn how they work, see the documentation for [extending Bazel](/versions/9.1.0/extending/concepts).
+
+## Can I contribute to the Bazel code base?
+
+See our [contribution guidelines](/versions/9.1.0/contribute/).
+
+## Why isn’t all development done in the open?
+
+We still have to refactor the interfaces between the public code in Bazel and our internal extensions frequently. This makes it hard to do much development in the open.
+
+## Are you done open sourcing Bazel?
+
+Open sourcing Bazel is a work-in-progress. In particular, we’re still working on open sourcing:
+
+*   Many of our unit and integration tests (which should make contributing patches easier).
+*   Full IDE integration.
+
+Beyond code, we’d like to eventually have all code reviews, bug tracking, and design decisions happen publicly, with the Bazel community involved. We are not there yet, so some changes will simply appear in the Bazel repository without clear explanation. Despite this lack of transparency, we want to support external developers and collaborate. Thus, we are opening up the code, even though some of the development is still happening internal to Google. Please let us know if anything seems unclear or unjustified as we transition to an open model.
+
+## Are there parts of Bazel that will never be open sourced?
+
+Yes, some of the code base either integrates with Google-specific technology or we have been looking for an excuse to get rid of (or is some combination of the two). These parts of the code base are not available on GitHub and probably never will be.
+
+## How do I contact the team?
+
+We are reachable at bazel-discuss@googlegroups.com.
+
+## Where do I report bugs?
+
+Open an issue [on GitHub](https://github.com/bazelbuild/bazel/issues).
+
+## What’s up with the word “Blaze” in the codebase?
+
+This is an internal name for the tool. Please refer to Blaze as Bazel.
+
+## Why do other Google projects (Android, Chrome) use other build tools?
+
+Until the first (Alpha) release, Bazel was not available externally, so open source projects such as Chromium and Android could not use it. In addition, the original lack of Windows support was a problem for building Windows applications, such as Chrome. Since the project has matured and become more stable, the [Android Open Source Project](https://source.android.com/) is in the process of migrating to Bazel.
+
+## How do you pronounce “Bazel”?
+
+The same way as “basil” (the herb) in US English: “BAY-zel”. It rhymes with “hazel”. IPA: /ˈbeɪzˌəl/
diff --git a/versions/9.1.0/about/intro.mdx b/versions/9.1.0/about/intro.mdx
new file mode 100644
index 00000000..aa24e810
--- /dev/null
+++ b/versions/9.1.0/about/intro.mdx
@@ -0,0 +1,109 @@
+---
+title: 'Intro to Bazel'
+---
+
+Bazel is an open-source build and test tool similar to Make, Maven, and Gradle.
+It uses a human-readable, high-level build language. Bazel supports projects in
+multiple languages and builds outputs for multiple platforms. Bazel supports
+large codebases across multiple repositories, and large numbers of users.
+
+## Benefits {#benefits}
+
+Bazel offers the following advantages:
+
+*   **High-level build language.** Bazel uses an abstract, human-readable
+    language to describe the build properties of your project at a high
+    semantical level. Unlike other tools, Bazel operates on the *concepts*
+    of libraries, binaries, scripts, and data sets, shielding you from the
+    complexity of writing individual calls to tools such as compilers and
+    linkers.
+
+*   **Bazel is fast and reliable.** Bazel caches all previously done work and
+    tracks changes to both file content and build commands. This way, Bazel
+    knows when something needs to be rebuilt, and rebuilds only that. To further
+    speed up your builds, you can set up your project to build in a  highly
+    parallel and incremental fashion.
+
+*   **Bazel is multi-platform.** Bazel runs on Linux, macOS, and Windows. Bazel
+    can build binaries and deployable packages for multiple platforms, including
+    desktop, server, and mobile, from the same project.
+
+*   **Bazel scales.** Bazel maintains agility while handling builds with 100k+
+    source files. It works with multiple repositories and user bases in the tens
+    of thousands.
+
+*   **Bazel is extensible.** Many [languages](/versions/9.1.0/rules) are
+    supported, and you can extend Bazel to support any other language or
+    framework.
+
+## Using Bazel {#using-bazel}
+
+To build or test a project with Bazel, you typically do the following:
+
+1.  **Set up Bazel.** Download and [install Bazel](/versions/9.1.0/install).
+
+2.  **Set up a project [workspace](/versions/9.1.0/concepts/build-ref#workspaces)**, which is a
+    directory where Bazel looks for build inputs and `BUILD` files, and where it
+    stores build outputs.
+
+3.  **Write a `BUILD` file**, which tells Bazel what to build and how to
+    build it.
+
+    You write your `BUILD` file by declaring build targets using
+    [Starlark](/versions/9.1.0/rules/language), a domain-specific language. (See example
+    [here](https://github.com/bazelbuild/bazel/blob/master/examples/cpp/BUILD).)
+
+    A build target specifies a set of input artifacts that Bazel will build plus
+    their dependencies, the build rule Bazel will use to build it, and options
+    that configure the build rule.
+
+    A build rule specifies the build tools Bazel will use, such as compilers and
+    linkers, and their configurations. Bazel ships with a number of build rules
+    covering the most common artifact types in the supported languages on
+    supported platforms.
+
+4. **Run Bazel** from the [command line](/versions/9.1.0/reference/command-line-reference). Bazel
+   places your outputs within the workspace.
+
+In addition to building, you can also use Bazel to run
+[tests](/versions/9.1.0/reference/test-encyclopedia) and [query](/versions/9.1.0/query/guide) the build
+to trace dependencies in your code.
+
+## Bazel build process {#bazel-build-process}
+
+When running a build or a test, Bazel does the following:
+
+1.  **Loads** the `BUILD` files relevant to the target.
+
+2.  **Analyzes** the inputs and their
+    [dependencies](/versions/9.1.0/concepts/dependencies), applies the specified build
+    rules, and produces an [action](/versions/9.1.0/extending/concepts#evaluation-model)
+    graph.
+
+3.  **Executes** the build actions on the inputs until the final build outputs
+    are produced.
+
+Since all previous build work is cached, Bazel can identify and reuse cached
+artifacts and only rebuild or retest what's changed. To further enforce
+correctness, you can set up Bazel to run builds and tests
+[hermetically](/versions/9.1.0/basics/hermeticity) through sandboxing, minimizing skew
+and maximizing [reproducibility](/versions/9.1.0/run/build#correct-incremental-rebuilds).
+
+### Action graph {#action-graph}
+
+The action graph represents the build artifacts, the relationships between them,
+and the build actions that Bazel will perform. Thanks to this graph, Bazel can
+[track](/versions/9.1.0/run/build#build-consistency) changes to
+file content as well as changes to actions, such as build or test commands, and
+know what build work has previously been done. The graph also enables you to
+easily [trace dependencies](/versions/9.1.0/query/guide) in your code.
+
+## Getting started tutorials {#getting-started-tutorials}
+
+To get started with Bazel, see [Getting Started](/versions/9.1.0/start/) or jump
+directly to the Bazel tutorials:
+
+*   [Tutorial: Build a C++ Project](/versions/9.1.0/start/cpp)
+*   [Tutorial: Build a Java Project](/versions/9.1.0/start/java)
+*   [Tutorial: Build an Android Application](/versions/9.1.0/start/android-app)
+*   [Tutorial: Build an iOS Application](/versions/9.1.0/start/ios-app)
diff --git a/versions/9.1.0/about/roadmap.mdx b/versions/9.1.0/about/roadmap.mdx
new file mode 100644
index 00000000..cc9ff666
--- /dev/null
+++ b/versions/9.1.0/about/roadmap.mdx
@@ -0,0 +1,97 @@
+---
+title: 'Bazel roadmap'
+---
+
+As Bazel continues to evolve in response to your needs, we want to share our
+2025 roadmap update.
+
+We plan to bring Bazel 9.0
+[long term support (LTS)](https://bazel.build/versions/9.1.0/release/versioning) to you in late
+2025.
+
+## Full transition to Bzlmod
+
+[Bzlmod](https://bazel.build/versions/9.1.0/docs/bzlmod) has been the standard external
+dependency system in Bazel since Bazel 7, replacing the legacy WORKSPACE system.
+As of March 2025, the [Bazel Central Registry](https://registry.bazel.build/)
+hosts more than 650 modules.
+
+With Bazel 9, we will completely remove WORKSPACE functionality, and Bzlmod will
+be the only way to introduce external dependencies in Bazel. To minimize the
+migration cost for the community, we'll focus on further improving our migration
+[guide](https://bazel.build/versions/9.1.0/external/migration) and
+[tool](https://github.com/bazelbuild/bazel-central-registry/tree/main/tools#migrate_to_bzlmodpy).
+
+Additionally, we aim to implement an improved shared repository cache (see
+[#12227](https://github.com/bazelbuild/bazel/issues/12227))
+with garbage collection, and may backport it to Bazel 8. The Bazel Central
+Registry will also support verifying SLSA attestations.
+
+## Migration of Android, C++, Java, Python, and Proto rules
+
+With Bazel 8, we have migrated support for Android, Java, Python, and Proto
+rules out of the Bazel codebase into Starlark rules in their corresponding
+repositories. To ease the migration, we implemented the autoload features in
+Bazel, which can be controlled with
+[--incompatible_autoload_externally](https://github.com/bazelbuild/bazel/issues/23043)
+and [--incompatible_disable_autoloads_in_main_repo](https://github.com/bazelbuild/bazel/issues/25755)
+flags.
+
+With Bazel 9, we aim to disable autoloads by default and require every project
+to explicitly load required rules in BUILD files.
+
+We will rewrite most of C++ language support to Starlark, detach it from Bazel
+binary and move it into the [/rules_cc](https://github.com/bazelbuild/rules_cc)
+repository. This is the last remaining major language support that is still part
+of Bazel.
+
+We're also porting unit tests for C++, Java, and Proto rules to Starlark, moving
+them to repositories next to the implementation to increase velocity of rule
+authors.
+
+## Starlark improvements
+
+Bazel will have the ability to evaluate symbolic macros lazily. This means that
+a symbolic macro won't run if the targets it declares are not requested,
+improving performance for very large packages.
+
+Starlark will have an experimental type system, similar to Python's type
+annotations. We expect the type system to stabilize _after_ Bazel 9 is launched.
+
+## Configurability
+
+Our main focus is reducing the cost and confusion of build flags.
+
+We're [experimenting](https://github.com/bazelbuild/bazel/issues/24839) with a
+new project configuration model that doesn't make users have to know which build
+and test flags to set where. So `$ bazel test //foo` automatically sets the
+right flags based on `foo`'s project's policy. This will likely remain
+experimental in 9.0 but guiding feedback is welcome.
+
+[Flag scoping](https://github.com/bazelbuild/bazel/issues/24042) lets you strip
+out Starlark flags when they leave project boundaries, so they don't break
+caching on transitive dependencies that don't need them. This makes builds that
+use [transitions](https://bazel.build/versions/9.1.0/extending/config#user-defined-transitions)
+cheaper and faster.
+[Here's](https://github.com/gregestren/snippets/tree/master/project_scoped_flags)
+an example. We're extending the idea to control which flags propagate to
+[exec configurations](https://bazel.build/versions/9.1.0/extending/rules#configurations) and
+are considering even more flexible support like custom Starlark to determine
+which dependency edges should propagate flags.
+
+We're up-prioritizing effort to move built-in language flags out of Bazel and
+into Starlark, where they can live with related rule definitions.
+
+## Remote execution improvements
+
+We plan to add support for asynchronous execution, speeding up remote execution
+by increasing parallelism.
+
+---
+
+To follow updates to the roadmap and discuss planned features, join the
+community Slack server at [slack.bazel.build](https://slack.bazel.build/).
+
+*This roadmap is intended to help inform the community about the team's
+intentions for Bazel 9.0. Priorities are subject to change in response to
+developer and customer feedback, or to new market opportunities.*
diff --git a/versions/9.1.0/about/vision.mdx b/versions/9.1.0/about/vision.mdx
new file mode 100644
index 00000000..1d6b3411
--- /dev/null
+++ b/versions/9.1.0/about/vision.mdx
@@ -0,0 +1,95 @@
+---
+title: 'Bazel Vision'
+---
+
+Any software developer can efficiently build, test, and package
+any project, of any size or complexity, with tooling that's easy to adopt and
+extend.
+
+*   **Engineers can take build fundamentals for granted.** Software developers
+    focus on the creative process of authoring code because the mechanical
+    process of build and test is solved. When customizing the build system to
+    support new languages or unique organizational needs, users focus on the
+    aspects of extensibility that are unique to their use case, without having
+    to reinvent the basic plumbing.
+
+*   **Engineers can easily contribute to any project.** A developer who wants to
+    start working on a new project can simply clone the project and run the
+    build. There's no need for local configuration - it just works. With
+    cross-platform remote execution, they can work on any machine anywhere and
+    fully test their changes against all platforms the project targets.
+    Engineers can quickly configure the build for a new project or incrementally
+    migrate an existing build.
+
+*   **Projects can scale to any size codebase, any size team.** Fast,
+    incremental testing allows teams to fully validate every change before it is
+    committed. This remains true even as repos grow, projects span multiple
+    repos, and multiple languages are introduced. Infrastructure does not force
+    developers to trade test coverage for build speed.
+
+**We believe Bazel has the potential to fulfill this vision.**
+
+Bazel was built from the ground up to enable builds that are reproducible (a
+given set of inputs will always produce the same outputs) and portable (a build
+can be run on any machine without affecting the output).
+
+These characteristics support safe incrementality (rebuilding only changed
+inputs doesn't introduce the risk of corruption) and distributability (build
+actions are isolated and can be offloaded). By minimizing the work needed to do
+a correct build and parallelizing that work across multiple cores and remote
+systems, Bazel can make any build fast.
+
+Bazel's abstraction layer — instructions specific to languages, platforms, and
+toolchains implemented in a simple extensibility language — allows it to be
+easily applied to any context.
+
+## Bazel core competencies {#bazel-core-competencies}
+
+1.  Bazel supports **multi-language, multi-platform** builds and tests. You can
+    run a single command to build and test your entire source tree, no matter
+    which combination of languages and platforms you target.
+1.  Bazel builds are **fast and correct**. Every build and test run is
+    incremental, on your developers' machines and on CI.
+1.  Bazel provides a **uniform, extensible language** to define builds for any
+    language or platform.
+1.  Bazel allows your builds **to scale** by connecting to remote execution and
+    caching services.
+1.  Bazel works across **all major development platforms** (Linux, MacOS, and
+    Windows).
+1.  We accept that adopting Bazel requires effort, but **gradual adoption** is
+    possible. Bazel interfaces with de-facto standard tools for a given
+    language/platform.
+
+## Serving language communities {#language-communities}
+
+Software engineering evolves in the context of language communities — typically,
+self-organizing groups of people who use common tools and practices.
+
+To be of use to members of a language community, high-quality Bazel rules must be
+available that integrate with the workflows and conventions of that community.
+
+Bazel is committed to be extensible and open, and to support good rulesets for
+any language.
+
+### Requirements of a good ruleset {#ruleset-requirements}
+
+1.  The rules need to support efficient **building and testing** for the
+    language, including code coverage.
+1.  The rules need to **interface with a widely-used "package manager"** for the
+    language (such as Maven for Java), and support incremental migration paths
+    from other widely-used build systems.
+1.  The rules need to be **extensible and interoperable**, following
+    ["Bazel sandwich"](https://github.com/bazelbuild/bazel-website/blob/master/designs/_posts/2016-08-04-extensibility-for-native-rules.md)
+    principles.
+1.  The rules need to be **remote-execution ready**. In practice, this means
+    **configurable using the [toolchains](/versions/9.1.0/extending/toolchains) mechanism**.
+1.  The rules (and Bazel) need to interface with a **widely-used IDE** for the
+    language, if there is one.
+1.  The rules need to have **thorough, usable documentation,** with introductory
+    material for new users, comprehensive docs for expert users.
+
+Each of these items is essential and only together do they deliver on Bazel's
+competencies for their particular ecosystem.
+
+They are also, by and large, sufficient - once all are fulfilled, Bazel fully
+delivers its value to members of that language community.
diff --git a/versions/9.1.0/about/why.mdx b/versions/9.1.0/about/why.mdx
new file mode 100644
index 00000000..b3516ac2
--- /dev/null
+++ b/versions/9.1.0/about/why.mdx
@@ -0,0 +1,83 @@
+---
+title: 'Why Bazel?'
+---
+
+Bazel is a [fast](#fast), [correct](#correct), and [extensible](#extensible)
+build tool with [integrated testing](#integrated-testing) that supports multiple
+[languages](#multi-language), [repositories](#multi-repository), and
+[platforms](#multi-platform) in an industry-leading [ecosystem](#ecosystem).
+
+## Bazel is fast {#fast}
+
+Bazel knows exactly what input files each build command needs, avoiding
+unnecessary work by re-running only when the set of input files have
+changed between each build.
+It runs build commands with as much parallelism as possible, either within the
+same computer or on [remote build nodes](/versions/9.1.0/remote/rbe). If the structure of build
+allows for it, it can run thousands of build or test commands at the same time.
+
+This is supported by multiple caching layers, in memory, on disk and on the
+remote build farm, if available. At Google, we routinely achieve cache hit rates
+north of 99%.
+
+## Bazel is correct {#correct}
+
+Bazel ensures that your binaries are built *only* from your own
+source code. Bazel actions run in individual sandboxes and Bazel tracks
+every input file of the build, only and always re-running build
+commands when it needs to. This keeps your binaries up-to-date so that the
+[same source code always results in the same binary](/versions/9.1.0/basics/hermeticity), bit
+by bit.
+
+Say goodbye to endless `make clean` invocations and to chasing phantom bugs
+that were in fact resolved in source code that never got built.
+
+## Bazel is extensible {#extensible}
+
+Harness the full power of Bazel by writing your own rules and macros to
+customize Bazel for your specific needs across a wide range of projects.
+
+Bazel rules are written in [Starlark](/versions/9.1.0/rules/language), our
+in-house programming language that's a subset of Python. Starlark makes
+rule-writing accessible to most developers, while also creating rules that can
+be used across the ecosystem.
+
+## Integrated testing {#integrated-testing}
+
+Bazel's [integrated test runner](/versions/9.1.0/docs/user-manual#running-tests)
+knows and runs only those tests needing to be re-run, using remote execution
+(if available) to run them in parallel. Detect flakes early by using remote
+execution to quickly run a test thousands of times.
+
+Bazel [provides facilities](/versions/9.1.0/remote/bep) to upload test results to a central
+location, thereby facilitating efficient communication of test outcomes, be it
+on CI or by individual developers.
+
+## Multi-language support {#multi-language}
+
+Bazel supports many common programming languages including C++, Java,
+Kotlin, Python, Go, and Rust. You can build multiple binaries (for example,
+backend, web UI and mobile app) in the same Bazel invocation without being
+constrained to one language's idiomatic build tool.
+
+## Multi-repository support {#multi-repository}
+
+Bazel can [gather source code from multiple locations](/versions/9.1.0/external/overview): you
+don't need to vendor your dependencies (but you can!), you can instead point
+Bazel to the location of your source code or prebuilt artifacts (e.g. a git
+repository or Maven Central), and it takes care of the rest.
+
+## Multi-platform support {#multi-platform}
+
+Bazel can simultaneously build projects for multiple platforms including Linux,
+macOS, Windows, and Android. It also provides powerful
+[cross-compilation capabilities](/versions/9.1.0/extending/platforms) to build code for one
+platform while running the build on another.
+
+## Wide ecosystem {#ecosystem}
+
+[Industry leaders](/versions/9.1.0/community/users) love Bazel, building a large
+community of developers who use and contribute to Bazel. Find a tools, services
+and documentation, including [consulting and SaaS offerings](/versions/9.1.0/community/experts)
+Bazel can use. Explore extensions like support for programming languages in
+our [open source software repositories](/versions/9.1.0/rules).
\ No newline at end of file
diff --git a/versions/9.1.0/advanced/performance/build-performance-breakdown.mdx b/versions/9.1.0/advanced/performance/build-performance-breakdown.mdx
new file mode 100644
index 00000000..73bfd25f
--- /dev/null
+++ b/versions/9.1.0/advanced/performance/build-performance-breakdown.mdx
@@ -0,0 +1,231 @@
+---
+title: 'Breaking down build performance'
+---
+
+Bazel is complex and does a lot of different things over the course of a build,
+some of which can have an impact on build performance. This page attempts to map
+some of these Bazel concepts to their implications on build performance. While
+not extensive, we have included some examples of how to detect build performance
+issues through [extracting metrics](/versions/9.1.0/configure/build-performance-metrics)
+and what you can do to fix them. With this, we hope you can apply these concepts
+when investigating build performance regressions.
+
+### Clean vs Incremental builds
+
+A clean build is one that builds everything from scratch, while an incremental
+build reuses some already completed work.
+
+We suggest looking at clean and incremental builds separately, especially when
+you are collecting / aggregating metrics that are dependent on the state of
+Bazel’s caches (for example
+[build request size metrics](#deterministic-build-metrics-as-a-proxy-for-build-performance)
+). They also represent two different user experiences. As compared to starting
+a clean build from scratch (which takes longer due to a cold cache), incremental
+builds happen far more frequently as developers iterate on code (typically
+faster since the cache is usually already warm).
+
+You can use the `CumulativeMetrics.num_analyses` field in the BEP to classify
+builds. If `num_analyses <= 1`, it is a clean build; otherwise, we can broadly
+categorize it to likely be an incremental build - the user could have switched
+to different flags or different targets causing an effectively clean build. Any
+more rigorous definition of incrementality will likely have to come in the form
+of a heuristic, for example looking at the number of packages loaded
+(`PackageMetrics.packages_loaded`).
+
+### Deterministic build metrics as a proxy for build performance
+
+Measuring build performance can be difficult due to the non-deterministic nature
+of certain metrics (for example Bazel’s CPU time or queue times on a remote
+cluster). As such, it can be useful to use deterministic metrics as a proxy for
+the amount of work done by Bazel, which in turn affects its performance.
+
+The size of a build request can have a significant implication on build
+performance. A larger build could represent more work in analyzing and
+constructing the build graphs. Organic growth of builds comes naturally with
+development, as more dependencies are added/created, and thus grow in complexity
+and become more expensive to build.
+
+We can slice this problem into the various build phases, and use the following
+metrics as proxy metrics for work done at each phase:
+
+1. `PackageMetrics.packages_loaded`: the number of packages successfully loaded.
+  A regression here represents more work that needs to be done to read and parse
+  each additional BUILD file in the loading phase.
+   - This is often due to the addition of dependencies and having to load their
+     transitive closure.
+   - Use [query](/versions/9.1.0/query/quickstart) / [cquery](/versions/9.1.0/query/cquery) to find
+     where new dependencies might have been added.
+
+2. `TargetMetrics.targets_configured`: representing the number of targets and
+  aspects configured in the build. A regression represents more work in
+  constructing and traversing the configured target graph.
+   - This is often due to the addition of dependencies and having to construct
+     the graph of their transitive closure.
+   - Use [cquery](/versions/9.1.0/query/cquery) to find where new
+     dependencies might have been added.
+
+3. `ActionSummary.actions_created`: represents the actions created in the build,
+  and a regression represents more work in constructing the action graph. Note
+  that this also includes unused actions that might not have been executed.
+   - Use [aquery](/versions/9.1.0/query/aquery) for debugging regressions;
+     we suggest starting with
+     [`--output=summary`](/versions/9.1.0/reference/command-line-reference#flag--output)
+     before further drilling down with
+     [`--skyframe_state`](/versions/9.1.0/reference/command-line-reference#flag--skyframe_state).
+
+4. `ActionSummary.actions_executed`: the number of actions executed, a
+  regression directly represents more work in executing these actions.
+   - The [BEP](/versions/9.1.0/remote/bep) writes out the action statistics
+     `ActionData` that shows the most executed action types. By default, it
+     collects the top 20 action types, but you can pass in the
+     [`--experimental_record_metrics_for_all_mnemonics`](/versions/9.1.0/reference/command-line-reference#flag--experimental_record_metrics_for_all_mnemonics)
+     to collect this data for all action types that were executed.
+   - This should help you to figure out what kind of actions were executed
+     (additionally).
+
+5. `BuildGraphSummary.outputArtifactCount`: the number of artifacts created by
+  the executed actions.
+   - If the number of actions executed did not increase, then it is likely that
+     a rule implementation was changed.
+
+These metrics are all affected by the state of the local cache, hence you will
+want to ensure that the builds you extract these metrics from are
+**clean builds**.
+
+We have noted that a regression in any of these metrics can be accompanied by
+regressions in wall time, cpu time and memory usage.
+
+### Usage of local resources
+
+Bazel consumes a variety of resources on your local machine (both for analyzing
+the build graph and driving the execution, and for running local actions), this
+can affect the performance / availability of your machine in performing the
+build, and also other tasks.
+
+#### Time spent
+
+Perhaps the metrics most susceptible to noise (and can vary greatly from build
+to build) is time; in particular - wall time, cpu time and system time. You can
+use [bazel-bench](https://github.com/bazelbuild/bazel-bench) to get
+a benchmark for these metrics, and with a sufficient number of `--runs`, you can
+increase the statistical significance of your measurement.
+
+- **Wall time** is the real world time elapsed.
+   - If _only_ wall time regresses, we suggest collecting a
+     [JSON trace profile](/versions/9.1.0/advanced/performance/json-trace-profile) and looking
+     for differences. Otherwise, it would likely be more efficient to
+     investigate other regressed metrics as they could have affected the wall
+     time.
+
+- **CPU time** is the time spent by the CPU executing user code.
+   - If the CPU time regresses across two project commits, we suggest collecting
+     a Starlark CPU profile. You should probably also use `--nobuild` to
+     restrict the build to the analysis phase since that is where most of the
+     CPU heavy work is done.
+
+- System time is the time spent by the CPU in the kernel.
+   - If system time regresses, it is mostly correlated with I/O when Bazel reads
+     files from your file system.
+
+#### System-wide load profiling
+
+Using the
+[`--experimental_collect_load_average_in_profiler`](https://github.com/bazelbuild/bazel/blob/6.0.0/src/main/java/com/google/devtools/build/lib/runtime/CommonCommandOptions.java#L306-L312)
+flag introduced in Bazel 6.0, the
+[JSON trace profiler](/versions/9.1.0/advanced/performance/json-trace-profile) collects the
+system load average during the invocation.
+
+![Profile that includes system load average](/versions/9.1.0/docs/images/json-trace-profile-system-load-average.png "Profile that includes system load average")
+
+**Figure 1.** Profile that includes system load average.
+
+A high load during a Bazel invocation can be an indication that Bazel schedules
+too many local actions in parallel for your machine. You might want to look into
+adjusting
+[`--local_cpu_resources`](/versions/9.1.0/reference/command-line-reference#flag--local_cpu_resources)
+and [`--local_ram_resources`](/versions/9.1.0/reference/command-line-reference#flag--local_ram_resources),
+especially in container environments (at least until
+[#16512](https://github.com/bazelbuild/bazel/pull/16512) is merged).
+
+#### Monitoring Bazel memory usage
+
+There are two main sources to get Bazel’s memory usage, Bazel `info` and the
+[BEP](/versions/9.1.0/remote/bep).
+
+- `bazel info used-heap-size-after-gc`: The amount of used memory in bytes after
+  a call to `System.gc()`.
+   - [Bazel bench](https://github.com/bazelbuild/bazel-bench)
+     provides benchmarks for this metric as well.
+   - Additionally, there are `peak-heap-size`, `max-heap-size`, `used-heap-size`
+     and `committed-heap-size` (see
+     [documentation](/versions/9.1.0/docs/user-manual#configuration-independent-data)), but are
+     less relevant.
+
+- [BEP](/versions/9.1.0/remote/bep)’s
+  `MemoryMetrics.peak_post_gc_heap_size`: Size of the peak JVM heap size in
+  bytes post GC (requires setting
+  [`--memory_profile`](/versions/9.1.0/reference/command-line-reference#flag--memory_profile)
+  that attempts to force a full GC).
+
+A regression in memory usage is usually a result of a regression in
+[build request size metrics](#deterministic_build_metrics_as_a_proxy_for_build_performance),
+which are often due to addition of dependencies or a change in the rule
+implementation.
+
+To analyze Bazel’s memory footprint on a more granular level, we recommend using
+the [built-in memory profiler](/versions/9.1.0/rules/performance#memory-profiling)
+for rules.
+
+#### Memory profiling of persistent workers
+
+While [persistent workers](/versions/9.1.0/remote/persistent) can help to speed up builds
+significantly (especially for interpreted languages) their memory footprint can
+be problematic. Bazel collects metrics on its workers, in particular, the
+`WorkerMetrics.WorkerStats.worker_memory_in_kb` field tells how much memory
+workers use (by mnemonic).
+
+The [JSON trace profiler](/versions/9.1.0/advanced/performance/json-trace-profile) also
+collects persistent worker memory usage during the invocation by passing in the
+[`--experimental_collect_system_network_usage`](https://github.com/bazelbuild/bazel/blob/6.0.0/src/main/java/com/google/devtools/build/lib/runtime/CommonCommandOptions.java#L314-L320)
+flag (new in Bazel 6.0).
+
+![Profile that includes workers memory usage](/versions/9.1.0/docs/images/json-trace-profile-workers-memory-usage.png "Profile that includes workers memory usage")
+
+**Figure 2.** Profile that includes workers memory usage.
+
+Lowering the value of
+[`--worker_max_instances`](/versions/9.1.0/reference/command-line-reference#flag--worker_max_instances)
+(default 4) might help to reduce
+the amount of memory used by persistent workers. We are actively working on
+making Bazel’s resource manager and scheduler smarter so that such fine tuning
+will be required less often in the future.
+
+### Monitoring network traffic for remote builds
+
+In remote execution, Bazel downloads artifacts that were built as a result of
+executing actions. As such, your network bandwidth can affect the performance
+of your build.
+
+If you are using remote execution for your builds, you might want to consider
+monitoring the network traffic during the invocation using the
+`NetworkMetrics.SystemNetworkStats` proto from the [BEP](/versions/9.1.0/remote/bep)
+(requires passing `--experimental_collect_system_network_usage`).
+
+Furthermore, [JSON trace profiles](/versions/9.1.0/advanced/performance/json-trace-profile)
+allow you to view system-wide network usage throughout the course of the build
+by passing the `--experimental_collect_system_network_usage` flag (new in Bazel
+6.0).
+
+![Profile that includes system-wide network usage](/versions/9.1.0/docs/images/json-trace-profile-network-usage.png "Profile that includes system-wide network usage")
+
+**Figure 3.** Profile that includes system-wide network usage.
+
+A high but rather flat network usage when using remote execution might indicate
+that network is the bottleneck in your build; if you are not using it already,
+consider turning on Build without the Bytes by passing
+[`--remote_download_minimal`](/versions/9.1.0/reference/command-line-reference#flag--remote_download_minimal).
+This will speed up your builds by avoiding the download of unnecessary intermediate artifacts.
+
+Another option is to configure a local
+[disk cache](/versions/9.1.0/reference/command-line-reference#flag--disk_cache) to save on
+download bandwidth.
diff --git a/versions/9.1.0/advanced/performance/build-performance-metrics.mdx b/versions/9.1.0/advanced/performance/build-performance-metrics.mdx
new file mode 100644
index 00000000..cb799f0f
--- /dev/null
+++ b/versions/9.1.0/advanced/performance/build-performance-metrics.mdx
@@ -0,0 +1,95 @@
+---
+title: 'Extracting build performance metrics'
+---
+
+Probably every Bazel user has experienced builds that were slow or slower than
+anticipated. Improving the performance of individual builds has particular value
+for targets with significant impact, such as:
+
+1. Core developer targets that are frequently iterated on and (re)built.
+
+2. Common libraries widely depended upon by other targets.
+
+3. A representative target from a class of targets (e.g. custom rules),
+  diagnosing and fixing issues in one build might help to resolve issues at the
+  larger scale.
+
+An important step to improving the performance of builds is to understand where
+resources are spent. This page lists different metrics you can collect.
+[Breaking down build performance](/versions/9.1.0/configure/build-performance-breakdown) showcases
+how you can use these metrics to detect and fix build performance issues.
+
+There are a few main ways to extract metrics from your Bazel builds, namely:
+
+## Build Event Protocol (BEP) {#build-event-protocol}
+
+Bazel outputs a variety of protocol buffers
+[`build_event_stream.proto`](https://github.com/bazelbuild/bazel/blob/master/src/main/java/com/google/devtools/build/lib/buildeventstream/proto/build_event_stream.proto)
+through the [Build Event Protocol (BEP)](/versions/9.1.0/remote/bep), which
+can be aggregated by a backend specified by you. Depending on your use cases,
+you might decide to aggregate the metrics in various ways, but here we will go
+over some concepts and proto fields that would be useful in general to consider.
+
+## Bazel’s query / cquery / aquery commands {#bazel-commands-query-cquery-aquery}
+
+Bazel provides 3 different query modes ([query](/versions/9.1.0/query/quickstart),
+[cquery](/versions/9.1.0/query/cquery) and [aquery](/versions/9.1.0/query/aquery)) that allow users
+to query the target graph, configured target graph and action graph
+respectively. The query language provides a
+[suite of functions](/versions/9.1.0/query/language#functions) usable across the different
+query modes, that allows you to customize your queries according to your needs.
+
+## JSON Trace Profiles {#json-trace-profiles}
+
+For every build-like Bazel invocation, Bazel writes a trace profile in JSON
+format. The [JSON trace profile](/versions/9.1.0/advanced/performance/json-trace-profile) can
+be very useful to quickly understand what Bazel spent time on during the
+invocation.
+
+## Execution Log {#execution-log}
+
+The [execution log](/versions/9.1.0/remote/cache-remote) can help you to troubleshoot and fix
+missing remote cache hits due to machine and environment differences or
+non-deterministic actions. If you pass the flag
+[`--experimental_execution_log_spawn_metrics`](/versions/9.1.0/reference/command-line-reference#flag--experimental_execution_log_spawn_metrics)
+(available from Bazel 5.2) it will also contain detailed spawn metrics, both for
+locally and remotely executed actions. You can use these metrics for example to
+make comparisons between local and remote machine performance or to find out
+which part of the spawn execution is consistently slower than expected (for
+example due to queuing).
+
+## Execution Graph Log {#execution-graph-log}
+
+While the JSON trace profile contains the critical path information, sometimes
+you need additional information on the dependency graph of the executed actions.
+Starting with Bazel 6.0, you can pass the flags
+`--experimental_execution_graph_log` and
+`--experimental_execution_graph_log_dep_type=all` to write out a log about the
+executed actions and their inter-dependencies.
+
+This information can be used to understand the drag that is added by a node on
+the critical path. The drag is the amount of time that can potentially be saved
+by removing a particular node from the execution graph.
+
+The data helps you predict the impact of changes to the build and action graph
+before you actually do them.
+
+## Benchmarking with bazel-bench {#bazel-bench}
+
+[Bazel bench](https://github.com/bazelbuild/bazel-bench) is a
+benchmarking tool for Git projects to benchmark build performance in the
+following cases:
+
+* **Project benchmark:** Benchmarking two git commits against each other at a
+ single Bazel version. Used to detect regressions in your build (often through
+ the addition of dependencies).
+
+* **Bazel benchmark:** Benchmarking two versions of Bazel against each other at
+ a single git commit. Used to detect regressions within Bazel itself (if you
+ happen to maintain / fork Bazel).
+
+Benchmarks monitor wall time, CPU  time and system time and Bazel’s retained
+heap size.
+
+It is also recommended to run Bazel bench on dedicated, physical machines that
+are not running other processes so as to reduce sources of variability.
diff --git a/versions/9.1.0/advanced/performance/iteration-speed.mdx b/versions/9.1.0/advanced/performance/iteration-speed.mdx
new file mode 100644
index 00000000..27321ef7
--- /dev/null
+++ b/versions/9.1.0/advanced/performance/iteration-speed.mdx
@@ -0,0 +1,91 @@
+---
+title: 'Optimize Iteration Speed'
+---
+
+This page describes how to optimize Bazel's build performance when running Bazel
+repeatedly.
+
+## Bazel's Runtime State {#bazel-runtime-state}
+
+A Bazel invocation involves several interacting parts.
+
+*   The `bazel` command line interface (CLI) is the user-facing front-end tool
+    and receives commands from the user.
+
+*   The CLI tool starts a [*Bazel server*](https://bazel.build/versions/9.1.0/run/client-server)
+    for each distinct [output base](https://bazel.build/versions/9.1.0/remote/output-directories).
+    The Bazel server is generally persistent, but will shut down after some idle
+    time so as to not waste resources.
+
+*   The Bazel server performs the loading and analysis steps for a given command
+    (`build`, `run`, `cquery`, etc.), in which it constructs the necessary parts
+    of the build graph in memory. The resulting data structures are retained in
+    the Bazel server as part of the *analysis cache*.
+
+*   The Bazel server can also perform the action execution, or it can send
+    actions off for remote execution if it is set up to do so. The results of
+    action executions are also cached, namely in the *action cache* (or
+    *execution cache*, which may be either local or remote, and it may be shared
+    among Bazel servers).
+
+*   The result of the Bazel invocation is made available in the output tree.
+
+## Running Bazel Iteratively {#run-iteratively}
+
+In a typical developer workflow, it is common to build (or run) a piece of code
+repeatedly, often at a very high frequency (e.g. to resolve some compilation
+error or investigate a failing test). In this situation, it is important that
+repeated invocations of `bazel` have as little overhead as possible relative to
+the underlying, repeated action (e.g. invoking a compiler, or executing a test).
+
+With this in mind, we take another look at Bazel's runtime state:
+
+The analysis cache is a critical piece of data. A significant amount of time can
+be spent just on the loading and analysis phases of a cold run (i.e. a run just
+after the Bazel server was started or when the analysis cache was discarded).
+For a single, successful cold build (e.g. for a production release) this cost is
+bearable, but for repeatedly building the same target it is important that this
+cost be amortized and not repeated on each invocation.
+
+The analysis cache is rather volatile. First off, it is part of the in-process
+state of the Bazel server, so losing the server loses the cache. But the cache
+is also *invalidated* very easily: for example, many `bazel` command line flags
+cause the cache to be discarded. This is because many flags affect the build
+graph (e.g. because of
+[configurable attributes](https://bazel.build/versions/9.1.0/configure/attributes)). Some flag
+changes can also cause the Bazel server to be restarted (e.g. changing
+[startup options](https://bazel.build/versions/9.1.0/docs/user-manual#startup-options)).
+
+A good execution cache is also valuable for build performance. An execution
+cache can be kept locally
+[on disk](https://bazel.build/versions/9.1.0/remote/caching#disk-cache), or
+[remotely](https://bazel.build/versions/9.1.0/remote/caching). The cache can be shared among
+Bazel servers, and indeed among developers.
+
+## Avoid discarding the analysis cache {#avoid-discarding-cache}
+
+Bazel will print a warning if either the analysis cache was discarded or the
+server was restarted. Either of these should be avoided during iterative use:
+
+*   Be mindful of changing `bazel` flags in the middle of an iterative
+    workflow. For example, mixing a `bazel build -c opt` with a `bazel cquery`
+    causes each command to discard the analysis cache of the other. In general,
+    try to use a fixed set of flags for the duration of a particular workflow.
+
+*   Losing the Bazel server loses the analysis cache. The Bazel server has a
+    [configurable](https://bazel.build/versions/9.1.0/docs/user-manual#max-idle-secs) idle
+    time, after which it shuts down. You can configure this time via your
+    bazelrc file to suit your needs. The server also restarted when startup
+    flags change, so, again, avoid changing those flags if possible.
+
+*   Beware that the Bazel server is killed if you press
+    Ctrl-C repeatedly while Bazel is running. It is tempting to try to save time
+    by interrupting a running build that is no longer needed, but only press
+    Ctrl-C once to request a graceful end of the current invocation.
+
+*   If you want to use multiple sets of flags from the same workspace, you can
+    use multiple, distinct output bases, switched with the `--output_base`
+    flag. Each output base gets its own Bazel server.
+
+To make this condition an error rather than a warning, you can use the
+`--noallow_analysis_cache_discard` flag (introduced in Bazel 6.4.0)
diff --git a/versions/9.1.0/advanced/performance/json-trace-profile.mdx b/versions/9.1.0/advanced/performance/json-trace-profile.mdx
new file mode 100644
index 00000000..375f583b
--- /dev/null
+++ b/versions/9.1.0/advanced/performance/json-trace-profile.mdx
@@ -0,0 +1,157 @@
+---
+title: 'JSON Trace Profile'
+---
+
+The JSON trace profile can be very useful to quickly understand what Bazel spent
+time on during the invocation.
+
+By default, for all build-like commands and query, Bazel writes a profile into
+the output base named `command-$INVOCATION_ID.profile.gz`, where
+`$INVOCATION_ID` is the invocation identifier of the command. Bazel also creates
+a symlink called `command.profile.gz` in the output base that points the profile
+of the latest command. You can configure whether a profile is written with the
+[`--generate_json_trace_profile`](/versions/9.1.0/reference/command-line-reference#flag--generate_json_trace_profile)
+flag, and the location it is written to with the
+[`--profile`](/versions/9.1.0/docs/user-manual#profile) flag. Locations ending with `.gz` are
+compressed with GZIP. Bazel keeps the last 5 profiles, configurable by
+[`--profiles_to_retain`](/versions/9.1.0/reference/command-line-reference#flag--generate_json_trace_profile),
+in the output base by default for post-build analysis. Explicitly passing a
+profile path with `--profile` disables automatic garbage collection.
+
+## Tools
+
+You can load this profile into `chrome://tracing` or analyze and
+post-process it with other tools.
+
+### `chrome://tracing`
+
+To visualize the profile, open `chrome://tracing` in a Chrome browser tab,
+click "Load" and pick the (potentially compressed) profile file. For more
+detailed results, click the boxes in the lower left corner.
+
+Example profile:
+
+![Example profile](/versions/9.1.0/docs/images/json-trace-profile.png "Example profile")
+
+**Figure 1.** Example profile.
+
+You can use these keyboard controls to navigate:
+
+*   Press `1` for "select" mode. In this mode, you can select
+    particular boxes to inspect the event details (see lower left corner).
+    Select multiple events to get a summary and aggregated statistics.
+*   Press `2` for "pan" mode. Then drag the mouse to move the view. You
+    can also use `a`/`d` to move left/right.
+*   Press `3` for "zoom" mode. Then drag the mouse to zoom. You can
+    also use `w`/`s` to zoom in/out.
+*   Press `4` for "timing" mode where you can measure the distance
+    between two events.
+*   Press `?` to learn about all controls.
+
+### Bazel Invocation Analyzer
+
+The open-source
+[Bazel Invocation Analyzer](https://github.com/EngFlow/bazel_invocation_analyzer)
+consumes a profile format and prints suggestions on how to improve
+the build’s performance. This analysis can be performed using its CLI or on
+[https://analyzer.engflow.com](https://analyzer.engflow.com).
+
+### `jq`
+
+`jq` is like `sed` for JSON data. An example usage of `jq` to extract all
+durations of the sandbox creation step in local action execution:
+
+```
+$ zcat $(../bazel-6.0.0rc1-linux-x86_64 info output_base)/command.profile.gz | jq '.traceEvents | .[] | select(.name == "sandbox.createFileSystem") | .dur'
+6378
+7247
+11850
+13756
+6555
+7445
+8487
+15520
+[...]
+```
+
+## Profile information {#profile-information}
+
+The profile contains multiple rows. Usually the bulk of rows represent Bazel
+threads and their corresponding events, but some special rows are also included.
+
+The special rows included depend on the version of Bazel invoked when the
+profile was created, and may be customized by different flags.
+
+Figure 1 shows a profile created with Bazel v5.3.1 and includes these rows:
+
+*   `action count`: Displays how many concurrent actions were in flight. Click
+    on it to see the actual value. Should go up to the value of
+    [`--jobs`](/versions/9.1.0/reference/command-line-reference#flag--jobs) in clean
+    builds.
+*   `CPU usage (Bazel)`: For each second of the build, displays the amount of
+    CPU that was used by Bazel (a value of 1 equals one core being 100% busy).
+*   `Critical Path`: Displays one block for each action on the critical path.
+*   `Main Thread`: Bazel’s main thread. Useful to get a high-level picture of
+    what Bazel is doing, for example "Launch Blaze", "evaluateTargetPatterns",
+    and "runAnalysisPhase".
+*   `Garbage Collector`: Displays minor and major Garbage Collection (GC)
+    pauses.
+
+## Common performance issues {#common-performance-issues}
+
+When analyzing performance profiles, look for:
+
+*   Slower than expected analysis phase (`runAnalysisPhase`), especially on
+    incremental builds. This can be a sign of a poor rule implementation, for
+    example one that flattens depsets. Package loading can be slow by an
+    excessive amount of targets, complex macros or recursive globs.
+*   Individual slow actions, especially those on the critical path. It might be
+    possible to split large actions into multiple smaller actions or reduce the
+    set of (transitive) dependencies to speed them up. Also check for an unusual
+    high non-`PROCESS_TIME` (such as `REMOTE_SETUP` or `FETCH`).
+*   Bottlenecks, that is a small number of threads is busy while all others are
+    idling / waiting for the result (see around 22s and 29s in Figure 1).
+    Optimizing this will most likely require touching the rule implementations
+    or Bazel itself to introduce more parallelism. This can also happen when
+    there is an unusual amount of GC.
+
+## Profile file format {#profile-file-format}
+
+The top-level object contains metadata (`otherData`) and the actual tracing data
+(`traceEvents`). The metadata contains extra info, for example the invocation ID
+and date of the Bazel invocation.
+
+Example:
+
+```json
+{
+  "otherData": {
+    "build_id": "101bff9a-7243-4c1a-8503-9dc6ae4c3b05",
+    "date": "Wed Oct 26 08:22:35 CEST 2022",
+    "profile_finish_ts": "1677666095162000",
+    "output_base": "/usr/local/google/_bazel_johndoe/573d4be77eaa72b91a3dfaa497bf8cd0"
+  },
+  "traceEvents": [
+    {"name":"thread_name","ph":"M","pid":1,"tid":0,"args":{"name":"Critical Path"}},
+    ...
+    {"cat":"build phase marker","name":"Launch Blaze","ph":"X","ts":-1306000,"dur":1306000,"pid":1,"tid":21},
+    ...
+    {"cat":"package creation","name":"foo","ph":"X","ts":2685358,"dur":784,"pid":1,"tid":246},
+    ...
+    {"name":"thread_name","ph":"M","pid":1,"tid":11,"args":{"name":"Garbage Collector"}},
+    {"cat":"gc notification","name":"minor GC","ph":"X","ts":825986,"dur":11000,"pid":1,"tid":11},
+    ...
+    {"cat":"action processing","name":"Compiling foo/bar.c","ph":"X","ts":54413389,"dur":357594,"pid":1,"args":{"mnemonic":"CppCompile"},"tid":341},
+ ]
+}
+```
+
+Timestamps (`ts`) and durations (`dur`) in the trace events are given in
+microseconds. The category (`cat`) is one of enum values of `ProfilerTask`.
+Note that some events are merged together if they are very short and close to
+each other; pass
+[`--noslim_profile`](/versions/9.1.0/reference/command-line-reference#flag--slim_profile)
+if you would like to prevent event merging.
+
+See also the
+[Chrome Trace Event Format Specification](https://docs.google.com/document/d/1CvAClvFfyA5R-PhYUmn5OOQtYMH4h6I0nSsKchNAySU/preview).
diff --git a/versions/9.1.0/advanced/performance/memory.mdx b/versions/9.1.0/advanced/performance/memory.mdx
new file mode 100644
index 00000000..de7f5f44
--- /dev/null
+++ b/versions/9.1.0/advanced/performance/memory.mdx
@@ -0,0 +1,95 @@
+---
+title: 'Optimize Memory'
+---
+
+This page describes how to limit and reduce the memory Bazel uses.
+
+## Running Bazel with Limited RAM {#running-bazel}
+
+In certain situations, you may want Bazel to use minimal memory. You can set the
+maximum heap via the startup flag
+[`--host_jvm_args`](/versions/9.1.0/docs/user-manual#host-jvm-args),
+like `--host_jvm_args=-Xmx2g`.
+
+### Trade incremental build speeds for memory {#trade-incremental}
+
+If your builds are too big, Bazel may throw an `OutOfMemoryError` (OOM) when
+it doesn't have enough memory. You can make Bazel use less memory, at the cost
+of slower incremental builds, by passing the following command flags:
+[`--discard_analysis_cache`](/versions/9.1.0/docs/user-manual#discard-analysis-cache),
+[`--nokeep_state_after_build`](/versions/9.1.0/reference/command-line-reference#flag--keep_state_after_build),
+and
+[`--notrack_incremental_state`](/versions/9.1.0/reference/command-line-reference#flag--track_incremental_state).
+
+These flags will minimize the memory that Bazel uses in a build, at the cost of
+making future builds slower than a standard incremental build would be.
+
+You can also pass any one of these flags individually:
+
+ * `--discard_analysis_cache` will reduce the memory used during execution (not
+analysis). Incremental builds will not have to redo package loading, but will
+have to redo analysis and execution (although the on-disk action cache can
+prevent most re-execution).
+ * `--notrack_incremental_state` will not store any edges in Bazel's internal
+ dependency graph, so that it is unusable for incremental builds. The next build
+ will discard that data, but it is preserved until then, for internal debugging,
+ unless `--nokeep_state_after_build` is specified.
+ * `--nokeep_state_after_build` will discard all data after the build, so that
+ incremental builds have to build from scratch (except for the on-disk action
+ cache). Alone, it does not affect the high-water mark of the current build.
+
+### Trade build flexibility for memory with Skyfocus (Experimental) {#trade-flexibility}
+
+If you want to make Bazel use less memory *and* retain incremental build speeds,
+you can tell Bazel the working set of files that you will be modifying, and
+Bazel will only keep state needed to correctly incrementally rebuild changes to
+those files. This feature is called **Skyfocus**.
+
+To use Skyfocus, pass the `--experimental_enable_skyfocus` flag:
+
+```sh
+bazel build //pkg:target --experimental_enable_skyfocus
+```
+
+By default, the working set will be the set of files next to the target being
+built. In the example, all files in `//pkg` will be kept in the working set, and
+changes to files outside of the working set will be disallowed, until you issue
+`bazel clean` or restart the Bazel server.
+
+If you want to specify an exact set of files or directories, use the
+`--experimental_working_set` flag, like so:
+
+```sh
+bazel build //pkg:target --experimental_enable_skyfocus
+--experimental_working_set=path/to/another/dir,path/to/tests/dir
+```
+
+You can also pass `--experimental_skyfocus_dump_post_gc_stats` to show the
+memory reduction amount:
+
+Putting it altogether, you should see something like this:
+
+```none
+$ bazel test //pkg:target //tests/... --experimental_enable_skyfocus --experimental_working_set dir1,dir2,dir3/subdir --experimental_skyfocus_dump_post_gc_stats
+INFO: --experimental_enable_skyfocus is enabled. Blaze will reclaim memory not needed to build the working set. Run 'blaze dump --skyframe=working_set' to show the working set, after this command.
+WARNING: Changes outside of the working set will cause a build error.
+INFO: Analyzed 149 targets (4533 packages loaded, 169438 targets configured).
+INFO: Found 25 targets and 124 test targets...
+INFO: Updated working set successfully.
+INFO: Focusing on 334 roots, 3 leafs... (use --experimental_skyfocus_dump_keys to show them)
+INFO: Heap: 1237MB -> 676MB (-45.31%)
+INFO: Elapsed time: 192.670s ...
+INFO: Build completed successfully, 62303 total actions
+```
+
+For this example, using Skyfocus allowed Bazel to drop 561MB (45%) of memory,
+and incremental builds to handle changes to files under `dir1`, `dir2`, and
+`dir3/subdir` will retain their fast speeds, with the tradeoff that Bazel cannot
+rebuild changed files outside of these directories.
+
+## Memory Profiling {#memory-profiling}
+
+Bazel comes with a built-in memory profiler that can help you check your rule’s
+memory use. Read more about this process on the
+[Memory Profiling section](/versions/9.1.0/rules/performance#memory-profiling) of our
+documentation on how to improve the performance of custom rules.
\ No newline at end of file
diff --git a/versions/9.1.0/basics/artifact-based-builds.mdx b/versions/9.1.0/basics/artifact-based-builds.mdx
new file mode 100644
index 00000000..965865e4
--- /dev/null
+++ b/versions/9.1.0/basics/artifact-based-builds.mdx
@@ -0,0 +1,277 @@
+---
+title: 'Artifact-Based Build Systems'
+---
+
+This page covers artifact-based build systems and the philosophy behind their
+creation. Bazel is an artifact-based build system. While task-based build
+systems are good step above build scripts, they give too much power to
+individual engineers by letting them define their own tasks.
+
+Artifact-based build systems have a small number of tasks defined by the system
+that engineers can configure in a limited way. Engineers still tell the system
+**what** to build, but the build system determines **how** to build it. As with
+task-based build systems, artifact-based build systems, such as Bazel, still
+have buildfiles, but the contents of those buildfiles are very different. Rather
+than being an imperative set of commands in a Turing-complete scripting language
+describing how to produce an output, buildfiles in Bazel are a declarative
+manifest describing a set of artifacts to build, their dependencies, and a
+limited set of options that affect how they’re built. When engineers run `bazel`
+on the command line, they specify a set of targets to build (the **what**), and
+Bazel is responsible for configuring, running, and scheduling the compilation
+steps (the **how**). Because the build system now has full control over what
+tools to run when, it can make much stronger guarantees that allow it to be far
+more efficient while still guaranteeing correctness.
+
+## A functional perspective
+
+It’s easy to make an analogy between artifact-based build systems and functional
+programming. Traditional imperative programming languages (such as, Java, C, and
+Python) specify lists of statements to be executed one after another, in the
+same way that task-based build systems let programmers define a series of steps
+to execute. Functional programming languages (such as, Haskell and ML), in
+contrast, are structured more like a series of mathematical equations. In
+functional languages, the programmer describes a computation to perform, but
+leaves the details of when and exactly how that computation is executed to the
+compiler.
+
+This maps to the idea of declaring a manifest in an artifact-based build system
+and letting the system figure out how to execute the build. Many problems can't
+be easily expressed using functional programming, but the ones that do benefit
+greatly from it: the language is often able to trivially parallelize such
+programs and make strong guarantees about their correctness that would be
+impossible in an imperative language. The easiest problems to express using
+functional programming are the ones that simply involve transforming one piece
+of data into another using a series of rules or functions. And that’s exactly
+what a build system is: the whole system is effectively a mathematical function
+that takes source files (and tools like the compiler) as inputs and produces
+binaries as outputs. So, it’s not surprising that it works well to base a build
+system around the tenets of functional programming.
+
+## Understanding artifact-based build systems
+
+Google's build system, Blaze, was the first artifact-based build system. Bazel
+is the open-sourced version of Blaze.
+
+Here’s what a buildfile (normally named `BUILD`) looks like in Bazel:
+
+```python
+java_binary(
+    name = "MyBinary",
+    srcs = ["MyBinary.java"],
+    deps = [
+        ":mylib",
+    ],
+)
+java_library(
+    name = "mylib",
+    srcs = ["MyLibrary.java", "MyHelper.java"],
+    visibility = ["//java/com/example/myproduct:__subpackages__"],
+    deps = [
+        "//java/com/example/common",
+        "//java/com/example/myproduct/otherlib",
+    ],
+)
+```
+
+In Bazel, `BUILD` files define targets—the two types of targets here are
+`java_binary` and `java_library`. Every target corresponds to an artifact that
+can be created by the system: binary targets produce binaries that can be
+executed directly, and library targets produce libraries that can be used by
+binaries or other libraries. Every target has:
+
+*   `name`: how the target is referenced on the command line and by other
+    targets
+*   `srcs`: the source files to be compiled to create the artifact for the target
+*   `deps`: other targets that must be built before this target and linked into
+    it
+
+Dependencies can either be within the same package (such as `MyBinary`’s
+dependency on `:mylib`) or on a different package in the same source hierarchy
+(such as `mylib`’s dependency on `//java/com/example/common`).
+
+As with task-based build systems, you perform builds using Bazel’s command-line
+tool. To build the `MyBinary` target, you run `bazel build :MyBinary`. After
+entering that command for the first time in a clean repository, Bazel:
+
+1.  Parses every `BUILD` file in the workspace to create a graph of dependencies
+    among artifacts.
+1.  Uses the graph to determine the transitive dependencies of `MyBinary`; that
+    is, every target that `MyBinary` depends on and every target that those
+    targets depend on, recursively.
+1.  Builds each of those dependencies, in order. Bazel starts by building each
+    target that has no other dependencies and keeps track of which dependencies
+    still need to be built for each target. As soon as all of a target’s
+    dependencies are built, Bazel starts building that target. This process
+    continues until every one of `MyBinary`’s transitive dependencies have been
+    built.
+1.  Builds `MyBinary` to produce a final executable binary that links in all of
+    the dependencies that were built in step 3.
+
+Fundamentally, it might not seem like what’s happening here is that much
+different than what happened when using a task-based build system. Indeed, the
+end result is the same binary, and the process for producing it involved
+analyzing a bunch of steps to find dependencies among them, and then running
+those steps in order. But there are critical differences. The first one appears
+in step 3: because Bazel knows that each target only produces a Java library, it
+knows that all it has to do is run the Java compiler rather than an arbitrary
+user-defined script, so it knows that it’s safe to run these steps in parallel.
+This can produce an order of magnitude performance improvement over building
+targets one at a time on a multicore machine, and is only possible because the
+artifact-based approach leaves the build system in charge of its own execution
+strategy so that it can make stronger guarantees about parallelism.
+
+The benefits extend beyond parallelism, though. The next thing that this
+approach gives us becomes apparent when the developer types `bazel
+build :MyBinary` a second time without making any changes: Bazel exits in less
+than a second with a message saying that the target is up to date. This is
+possible due to the functional programming paradigm we talked about
+earlier—Bazel knows that each target is the result only of running a Java
+compiler, and it knows that the output from the Java compiler depends only on
+its inputs, so as long as the inputs haven’t changed, the output can be reused.
+And this analysis works at every level; if `MyBinary.java` changes, Bazel knows
+to rebuild `MyBinary` but reuse `mylib`. If a source file for
+`//java/com/example/common` changes, Bazel knows to rebuild that library,
+`mylib`, and `MyBinary`, but reuse `//java/com/example/myproduct/otherlib`.
+Because Bazel knows about the properties of the tools it runs at every step,
+it’s able to rebuild only the minimum set of artifacts each time while
+guaranteeing that it won’t produce stale builds.
+
+Reframing the build process in terms of artifacts rather than tasks is subtle
+but powerful. By reducing the flexibility exposed to the programmer, the build
+system can know more about what is being done at every step of the build. It can
+use this knowledge to make the build far more efficient by parallelizing build
+processes and reusing their outputs. But this is really just the first step, and
+these building blocks of parallelism and reuse form the basis for a distributed
+and highly scalable build system.
+
+## Other nifty Bazel tricks
+
+Artifact-based build systems fundamentally solve the problems with parallelism
+and reuse that are inherent in task-based build systems. But there are still a
+few problems that came up earlier that we haven’t addressed. Bazel has clever
+ways of solving each of these, and we should discuss them before moving on.
+
+### Tools as dependencies
+
+One problem we ran into earlier was that builds depended on the tools installed
+on our machine, and reproducing builds across systems could be difficult due to
+different tool versions or locations. The problem becomes even more difficult
+when your project uses languages that require different tools based on which
+platform they’re being built on or compiled for (such as, Windows versus Linux),
+and each of those platforms requires a slightly different set of tools to do the
+same job.
+
+Bazel solves the first part of this problem by treating tools as dependencies to
+each target. Every `java_library` in the workspace implicitly depends on a Java
+compiler, which defaults to a well-known compiler. Whenever Bazel builds a
+`java_library`, it checks to make sure that the specified compiler is available
+at a known location. Just like any other dependency, if the Java compiler
+changes, every artifact that depends on it is rebuilt.
+
+Bazel solves the second part of the problem, platform independence, by setting
+[build configurations](/versions/9.1.0/run/build#build-config-cross-compilation). Rather than
+targets depending directly on their tools, they depend on types of configurations:
+
+*   **Host configuration**: building tools that run during the build
+*   **Target configuration**: building the binary you ultimately requested
+
+### Extending the build system
+
+Bazel comes with targets for several popular programming languages out of the
+box, but engineers will always want to do more—part of the benefit of task-based
+systems is their flexibility in supporting any kind of build process, and it
+would be better not to give that up in an artifact-based build system.
+Fortunately, Bazel allows its supported target types to be extended by
+[adding custom rules](/versions/9.1.0/extending/rules).
+
+To define a rule in Bazel, the rule author declares the inputs that the rule
+requires (in the form of attributes passed in the `BUILD` file) and the fixed
+set of outputs that the rule produces. The author also defines the actions that
+will be generated by that rule. Each action declares its inputs and outputs,
+runs a particular executable or writes a particular string to a file, and can be
+connected to other actions via its inputs and outputs. This means that actions
+are the lowest-level composable unit in the build system—an action can do
+whatever it wants so long as it uses only its declared inputs and outputs, and
+Bazel takes care of scheduling actions and caching their results as appropriate.
+
+The system isn’t foolproof given that there’s no way to stop an action developer
+from doing something like introducing a nondeterministic process as part of
+their action. But this doesn’t happen very often in practice, and pushing the
+possibilities for abuse all the way down to the action level greatly decreases
+opportunities for errors. Rules supporting many common languages and tools are
+widely available online, and most projects will never need to define their own
+rules. Even for those that do, rule definitions only need to be defined in one
+central place in the repository, meaning most engineers will be able to use
+those rules without ever having to worry about their implementation.
+
+### Isolating the environment
+
+Actions sound like they might run into the same problems as tasks in other
+systems—isn’t it still possible to write actions that both write to the same
+file and end up conflicting with one another? Actually, Bazel makes these
+conflicts impossible by using _[sandboxing](/versions/9.1.0/docs/sandboxing)_. On supported
+systems, every action is isolated from every other action via a filesystem
+sandbox. Effectively, each action can see only a restricted view of the
+filesystem that includes the inputs it has declared and any outputs it has
+produced. This is enforced by systems such as LXC on Linux, the same technology
+behind Docker. This means that it’s impossible for actions to conflict with one
+another because they are unable to read any files they don’t declare, and any
+files that they write but don’t declare will be thrown away when the action
+finishes. Bazel also uses sandboxes to restrict actions from communicating via
+the network.
+
+### Making external dependencies deterministic
+
+There’s still one problem remaining: build systems often need to download
+dependencies (whether tools or libraries) from external sources rather than
+directly building them. This can be seen in the example via the
+`@com_google_common_guava_guava//jar` dependency, which downloads a `JAR` file
+from Maven.
+
+Depending on files outside of the current workspace is risky. Those files could
+change at any time, potentially requiring the build system to constantly check
+whether they’re fresh. If a remote file changes without a corresponding change
+in the workspace source code, it can also lead to unreproducible builds—a build
+might work one day and fail the next for no obvious reason due to an unnoticed
+dependency change. Finally, an external dependency can introduce a huge security
+risk when it is owned by a third party: if an attacker is able to infiltrate
+that third-party server, they can replace the dependency file with something of
+their own design, potentially giving them full control over your build
+environment and its output.
+
+The fundamental problem is that we want the build system to be aware of these
+files without having to check them into source control. Updating a dependency
+should be a conscious choice, but that choice should be made once in a central
+place rather than managed by individual engineers or automatically by the
+system. This is because even with a “Live at Head” model, we still want builds
+to be deterministic, which implies that if you check out a commit from last
+week, you should see your dependencies as they were then rather than as they are
+now.
+
+Bazel and some other build systems address this problem by requiring a
+workspacewide manifest file that lists a _cryptographic hash_ for every external
+dependency in the workspace. The hash is a concise way to uniquely represent the
+file without checking the entire file into source control. Whenever a new
+external dependency is referenced from a workspace, that dependency’s hash is
+added to the manifest, either manually or automatically. When Bazel runs a
+build, it checks the actual hash of its cached dependency against the expected
+hash defined in the manifest and redownloads the file only if the hash differs.
+
+If the artifact we download has a different hash than the one declared in the
+manifest, the build will fail unless the hash in the manifest is updated. This
+can be done automatically, but that change must be approved and checked into
+source control before the build will accept the new dependency. This means that
+there’s always a record of when a dependency was updated, and an external
+dependency can’t change without a corresponding change in the workspace source.
+It also means that, when checking out an older version of the source code, the
+build is guaranteed to use the same dependencies that it was using at the point
+when that version was checked in (or else it will fail if those dependencies are
+no longer available).
+
+Of course, it can still be a problem if a remote server becomes unavailable or
+starts serving corrupt data—this can cause all of your builds to begin failing
+if you don’t have another copy of that dependency available. To avoid this
+problem, we recommend that, for any nontrivial project, you mirror all of its
+dependencies onto servers or services that you trust and control. Otherwise you
+will always be at the mercy of a third party for your build system’s
+availability, even if the checked-in hashes guarantee its security.
diff --git a/versions/9.1.0/basics/build-systems.mdx b/versions/9.1.0/basics/build-systems.mdx
new file mode 100644
index 00000000..938caf78
--- /dev/null
+++ b/versions/9.1.0/basics/build-systems.mdx
@@ -0,0 +1,125 @@
+---
+title: 'Why a Build System?'
+---
+
+This page discusses what build systems are, what they do, why you should use a
+build system, and why compilers and build scripts aren't the best choice as your
+organization starts to scale. It's intended for developers who don't have much
+experience with a build system.
+
+## What is a build system?
+
+Fundamentally, all build systems have a straightforward purpose: they transform
+the source code written by engineers into executable binaries that can be read
+by machines. Build systems aren't just for human-authored code; they also allow
+machines to create builds automatically, whether for testing or for releases to
+production. In an organization with thousands of engineers, it's common that
+most builds are triggered automatically rather than directly by engineers.
+
+### Can't I just use a compiler?
+
+The need for a build system might not be immediately obvious. Most engineers
+don't use a build system while learning to code: most start by invoking tools
+like `gcc` or `javac` directly from the command line, or the equivalent in an
+integrated development environment (IDE). As long as all the source code is in
+the same directory, a command like this works fine:
+
+```posix-terminal
+javac *.java
+```
+
+This instructs the Java compiler to take every Java source file in the current
+directory and turn it into a binary class file. In the simplest case, this is
+all you need.
+
+However, as soon as code expands, the complications begin. `javac` is smart
+enough to look in subdirectories of the current directory to find code to
+import. But it has no way of finding code stored in _other parts_ of the
+filesystem (perhaps a library shared by several projects). It also only knows
+how to build Java code. Large systems often involve different pieces written in
+a variety of programming languages with webs of dependencies among those pieces,
+meaning no compiler for a single language can possibly build the entire system.
+
+Once you're dealing with code from multiple languages or multiple compilation
+units, building code is no longer a one-step process. Now you must evaluate what
+your code depends on and build those pieces in the proper order, possibly using
+a different set of tools for each piece. If any dependencies change, you must
+repeat this process to avoid depending on stale binaries. For a codebase of even
+moderate size, this process quickly becomes tedious and error-prone.
+
+The compiler also doesn’t know anything about how to handle external
+dependencies, such as third-party `JAR` files in Java. Without a build system,
+you could manage this by downloading the dependency from the internet, sticking
+it in a `lib` folder on the hard drive, and configuring the compiler to read
+libraries from that directory. Over time, it's difficult to maintain the
+updates, versions, and source of these external dependencies.
+
+### What about shell scripts?
+
+Suppose that your hobby project starts out simple enough that you can build it
+using just a compiler, but you begin running into some of the problems described
+previously. Maybe you still don’t think you need a build system and can automate
+away the tedious parts using some simple shell scripts that take care of
+building things in the correct order. This helps out for a while, but pretty
+soon you start running into even more problems:
+
+*   It becomes tedious. As your system grows more complex, you begin spending
+    almost as much time working on your build scripts as on real code. Debugging
+    shell scripts is painful, with more and more hacks being layered on top of
+    one another.
+
+*   It’s slow. To make sure you weren’t accidentally relying on stale libraries,
+    you have your build script build every dependency in order every time you
+    run it. You think about adding some logic to detect which parts need to be
+    rebuilt, but that sounds awfully complex and error prone for a script. Or
+    you think about specifying which parts need to be rebuilt each time, but
+    then you’re back to square one.
+
+*   Good news: it’s time for a release! Better go figure out all the arguments
+    you need to pass to the jar command to make your final build. And remember
+    how to upload it and push it out to the central repository. And build and
+    push the documentation updates, and send out a notification to users. Hmm,
+    maybe this calls for another script...
+
+*   Disaster! Your hard drive crashes, and now you need to recreate your entire
+    system. You were smart enough to keep all of your source files in version
+    control, but what about those libraries you downloaded? Can you find them
+    all again and make sure they were the same version as when you first
+    downloaded them? Your scripts probably depended on particular tools being
+    installed in particular places—can you restore that same environment so that
+    the scripts work again? What about all those environment variables you set a
+    long time ago to get the compiler working just right and then forgot about?
+
+*   Despite the problems, your project is successful enough that you’re able to
+    begin hiring more engineers. Now you realize that it doesn’t take a disaster
+    for the previous problems to arise—you need to go through the same painful
+    bootstrapping process every time a new developer joins your team. And
+    despite your best efforts, there are still small differences in each
+    person’s system. Frequently, what works on one person’s machine doesn’t work
+    on another’s, and each time it takes a few hours of debugging tool paths or
+    library versions to figure out where the difference is.
+
+*   You decide that you need to automate your build system. In theory, this is
+    as simple as getting a new computer and setting it up to run your build
+    script every night using cron. You still need to go through the painful
+    setup process, but now you don’t have the benefit of a human brain being
+    able to detect and resolve minor problems. Now, every morning when you get
+    in, you see that last night’s build failed because yesterday a developer
+    made a change that worked on their system but didn’t work on the automated
+    build system. Each time it’s a simple fix, but it happens so often that you
+    end up spending a lot of time each day discovering and applying these simple
+    fixes.
+
+*   Builds become slower and slower as the project grows. One day, while waiting
+    for a build to complete, you gaze mournfully at the idle desktop of your
+    coworker, who is on vacation, and wish there were a way to take advantage of
+    all that wasted computational power.
+
+You’ve run into a classic problem of scale. For a single developer working on at
+most a couple hundred lines of code for at most a week or two (which might have
+been the entire experience thus far of a junior developer who just graduated
+university), a compiler is all you need. Scripts can maybe take you a little bit
+farther. But as soon as you need to coordinate across multiple developers and
+their machines, even a perfect build script isn’t enough because it becomes very
+difficult to account for the minor differences in those machines. At this point,
+this simple approach breaks down and it’s time to invest in a real build system.
diff --git a/versions/9.1.0/basics/dependencies.mdx b/versions/9.1.0/basics/dependencies.mdx
new file mode 100644
index 00000000..907dc672
--- /dev/null
+++ b/versions/9.1.0/basics/dependencies.mdx
@@ -0,0 +1,299 @@
+---
+title: 'Dependency Management'
+---
+
+In looking through the previous pages, one theme repeats over and over: managing
+your own code is fairly straightforward, but managing its dependencies is much
+more difficult. There are all sorts of dependencies: sometimes there’s a
+dependency on a task (such as “push the documentation before I mark a release as
+complete”), and sometimes there’s a dependency on an artifact (such as “I need
+to have the latest version of the computer vision library to build my code”).
+Sometimes, you have internal dependencies on another part of your codebase, and
+sometimes you have external dependencies on code or data owned by another team
+(either in your organization or a third party). But in any case, the idea of “I
+need that before I can have this” is something that recurs repeatedly in the
+design of build systems, and managing dependencies is perhaps the most
+fundamental job of a build system.
+
+## Dealing with Modules and Dependencies
+
+Projects that use artifact-based build systems like Bazel are broken into a set
+of modules, with modules expressing dependencies on one another via `BUILD`
+files. Proper organization of these modules and dependencies can have a huge
+effect on both the performance of the build system and how much work it takes to
+maintain.
+
+## Using Fine-Grained Modules and the 1:1:1 Rule
+
+The first question that comes up when structuring an artifact-based build is
+deciding how much functionality an individual module should encompass. In Bazel,
+a _module_ is represented by a target specifying a buildable unit like a
+`java_library` or a `go_binary`. At one extreme, the entire project could be
+contained in a single module by putting one `BUILD` file at the root and
+recursively globbing together all of that project’s source files. At the other
+extreme, nearly every source file could be made into its own module, effectively
+requiring each file to list in a `BUILD` file every other file it depends on.
+
+Most projects fall somewhere between these extremes, and the choice involves a
+trade-off between performance and maintainability. Using a single module for the
+entire project might mean that you never need to touch the `BUILD` file except
+when adding an external dependency, but it means that the build system must
+always build the entire project all at once. This means that it won’t be able to
+parallelize or distribute parts of the build, nor will it be able to cache parts
+that it’s already built. One-module-per-file is the opposite: the build system
+has the maximum flexibility in caching and scheduling steps of the build, but
+engineers need to expend more effort maintaining lists of dependencies whenever
+they change which files reference which.
+
+Though the exact granularity varies by language (and often even within
+language), Google tends to favor significantly smaller modules than one might
+typically write in a task-based build system. A typical production binary at
+Google often depends on tens of thousands of targets, and even a moderate-sized
+team can own several hundred targets within its codebase. For languages like
+Java that have a strong built-in notion of packaging, each directory usually
+contains a single package, target, and `BUILD` file (Pants, another build system
+based on Bazel, calls this the 1:1:1 rule). Languages with weaker packaging
+conventions frequently define multiple targets per `BUILD` file.
+
+The benefits of smaller build targets really begin to show at scale because they
+lead to faster distributed builds and a less frequent need to rebuild targets.
+The advantages become even more compelling after testing enters the picture, as
+finer-grained targets mean that the build system can be much smarter about
+running only a limited subset of tests that could be affected by any given
+change. Because Google believes in the systemic benefits of using smaller
+targets, we’ve made some strides in mitigating the downside by investing in
+tooling to automatically manage `BUILD` files to avoid burdening developers.
+
+Some of these tools, such as `buildifier` and `buildozer`, are available with
+Bazel in the [`buildtools`
+directory](https://github.com/bazelbuild/buildtools).
+
+## Minimizing Module Visibility
+
+Bazel and other build systems allow each target to specify a visibility — a
+property that determines which other targets may depend on it. A private target
+can only be referenced within its own `BUILD` file. A target may grant broader
+visibility to the targets of an explicitly defined list of `BUILD` files, or, in
+the case of public visibility, to every target in the workspace.
+
+As with most programming languages, it is usually best to minimize visibility as
+much as possible. Generally, teams at Google will make targets public only if
+those targets represent widely used libraries available to any team at Google.
+Teams that require others to coordinate with them before using their code will
+maintain an allowlist of customer targets as their target’s visibility. Each
+team’s internal implementation targets will be restricted to only directories
+owned by the team, and most `BUILD` files will have only one target that isn’t
+private.
+
+## Managing Dependencies
+
+Modules need to be able to refer to one another. The downside of breaking a
+codebase into fine-grained modules is that you need to manage the dependencies
+among those modules (though tools can help automate this). Expressing these
+dependencies usually ends up being the bulk of the content in a `BUILD` file.
+
+### Internal dependencies
+
+In a large project broken into fine-grained modules, most dependencies are
+likely to be internal; that is, on another target defined and built in the same
+source repository. Internal dependencies differ from external dependencies in
+that they are built from source rather than downloaded as a prebuilt artifact
+while running the build. This also means that there’s no notion of “version” for
+internal dependencies—a target and all of its internal dependencies are always
+built at the same commit/revision in the repository. One issue that should be
+handled carefully with regard to internal dependencies is how to treat
+transitive dependencies (Figure 1). Suppose target A depends on target B, which
+depends on a common library target C. Should target A be able to use classes
+defined in target C?
+
+[![Transitive
+dependencies](/versions/9.1.0/images/transitive-dependencies.png)](/versions/9.1.0/images/transitive-dependencies.png)
+
+**Figure 1**. Transitive dependencies
+
+As far as the underlying tools are concerned, there’s no problem with this; both
+B and C will be linked into target A when it is built, so any symbols defined in
+C are known to A. Bazel allowed this for many years, but as Google grew, we
+began to see problems. Suppose that B was refactored such that it no longer
+needed to depend on C. If B’s dependency on C was then removed, A and any other
+target that used C via a dependency on B would break. Effectively, a target’s
+dependencies became part of its public contract and could never be safely
+changed. This meant that dependencies accumulated over time and builds at Google
+started to slow down.
+
+Google eventually solved this issue by introducing a “strict transitive
+dependency mode” in Bazel. In this mode, Bazel detects whether a target tries to
+reference a symbol without depending on it directly and, if so, fails with an
+error and a shell command that can be used to automatically insert the
+dependency. Rolling this change out across Google’s entire codebase and
+refactoring every one of our millions of build targets to explicitly list their
+dependencies was a multiyear effort, but it was well worth it. Our builds are
+now much faster given that targets have fewer unnecessary dependencies, and
+engineers are empowered to remove dependencies they don’t need without worrying
+about breaking targets that depend on them.
+
+As usual, enforcing strict transitive dependencies involved a trade-off. It made
+build files more verbose, as frequently used libraries now need to be listed
+explicitly in many places rather than pulled in incidentally, and engineers
+needed to spend more effort adding dependencies to `BUILD` files. We’ve since
+developed tools that reduce this toil by automatically detecting many missing
+dependencies and adding them to a `BUILD` files without any developer
+intervention. But even without such tools, we’ve found the trade-off to be well
+worth it as the codebase scales: explicitly adding a dependency to `BUILD` file
+is a one-time cost, but dealing with implicit transitive dependencies can cause
+ongoing problems as long as the build target exists. Bazel [enforces strict
+transitive
+dependencies](https://blog.bazel.build/2017/06/28/sjd-unused_deps.html)
+on Java code by default.
+
+### External dependencies
+
+If a dependency isn’t internal, it must be external. External dependencies are
+those on artifacts that are built and stored outside of the build system. The
+dependency is imported directly from an artifact repository (typically accessed
+over the internet) and used as-is rather than being built from source. One of
+the biggest differences between external and internal dependencies is that
+external dependencies have versions, and those versions exist independently of
+the project’s source code.
+
+### Automatic versus manual dependency management
+
+Build systems can allow the versions of external dependencies to be managed
+either manually or automatically. When managed manually, the buildfile
+explicitly lists the version it wants to download from the artifact repository,
+often using a [semantic version string](https://semver.org/) such
+as `1.1.4`. When managed automatically, the source file specifies a range of
+acceptable versions, and the build system always downloads the latest one. For
+example, Gradle allows a dependency version to be declared as “1.+” to specify
+that any minor or patch version of a dependency is acceptable so long as the
+major version is 1.
+
+Automatically managed dependencies can be convenient for small projects, but
+they’re usually a recipe for disaster on projects of nontrivial size or that are
+being worked on by more than one engineer. The problem with automatically
+managed dependencies is that you have no control over when the version is
+updated. There’s no way to guarantee that external parties won’t make breaking
+updates (even when they claim to use semantic versioning), so a build that
+worked one day might be broken the next with no easy way to detect what changed
+or to roll it back to a working state. Even if the build doesn’t break, there
+can be subtle behavior or performance changes that are impossible to track down.
+
+In contrast, because manually managed dependencies require a change in source
+control, they can be easily discovered and rolled back, and it’s possible to
+check out an older version of the repository to build with older dependencies.
+Bazel requires that versions of all dependencies be specified manually. At even
+moderate scales, the overhead of manual version management is well worth it for
+the stability it provides.
+
+### The One-Version Rule
+
+Different versions of a library are usually represented by different artifacts,
+so in theory there’s no reason that different versions of the same external
+dependency couldn’t both be declared in the build system under different names.
+That way, each target could choose which version of the dependency it wanted to
+use. This causes a lot of problems in practice, so Google enforces a strict
+[One-Version
+Rule](https://opensource.google/docs/thirdparty/oneversion/) for
+all third-party dependencies in our codebase.
+
+The biggest problem with allowing multiple versions is the diamond dependency
+issue. Suppose that target A depends on target B and on v1 of an external
+library. If target B is later refactored to add a dependency on v2 of the same
+external library, target A will break because it now depends implicitly on two
+different versions of the same library. Effectively, it’s never safe to add a
+new dependency from a target to any third-party library with multiple versions,
+because any of that target’s users could already be depending on a different
+version. Following the One-Version Rule makes this conflict impossible—if a
+target adds a dependency on a third-party library, any existing dependencies
+will already be on that same version, so they can happily coexist.
+
+### Transitive external dependencies
+
+Dealing with the transitive dependencies of an external dependency can be
+particularly difficult. Many artifact repositories such as Maven Central, allow
+artifacts to specify dependencies on particular versions of other artifacts in
+the repository. Build tools like Maven or Gradle often recursively download each
+transitive dependency by default, meaning that adding a single dependency in
+your project could potentially cause dozens of artifacts to be downloaded in
+total.
+
+This is very convenient: when adding a dependency on a new library, it would be
+a big pain to have to track down each of that library’s transitive dependencies
+and add them all manually. But there’s also a huge downside: because different
+libraries can depend on different versions of the same third-party library, this
+strategy necessarily violates the One-Version Rule and leads to the diamond
+dependency problem. If your target depends on two external libraries that use
+different versions of the same dependency, there’s no telling which one you’ll
+get. This also means that updating an external dependency could cause seemingly
+unrelated failures throughout the codebase if the new version begins pulling in
+conflicting versions of some of its dependencies.
+
+Bazel did not use to automatically download transitive dependencies. It used to
+employ a `WORKSPACE` file that required all transitive dependencies to be
+listed, which led to a lot of pain when managing external dependencies. Bazel
+has since added support for automatic transitive external dependency management
+in the form of the `MODULE.bazel` file. See [external dependency
+overview](/versions/9.1.0/external/overview) for more details.
+
+Yet again, the choice here is one between convenience and scalability. Small
+projects might prefer not having to worry about managing transitive dependencies
+themselves and might be able to get away with using automatic transitive
+dependencies. This strategy becomes less and less appealing as the organization
+and codebase grows, and conflicts and unexpected results become more and more
+frequent. At larger scales, the cost of manually managing dependencies is much
+less than the cost of dealing with issues caused by automatic dependency
+management.
+
+### Caching build results using external dependencies
+
+External dependencies are most often provided by third parties that release
+stable versions of libraries, perhaps without providing source code. Some
+organizations might also choose to make some of their own code available as
+artifacts, allowing other pieces of code to depend on them as third-party rather
+than internal dependencies. This can theoretically speed up builds if artifacts
+are slow to build but quick to download.
+
+However, this also introduces a lot of overhead and complexity: someone needs to
+be responsible for building each of those artifacts and uploading them to the
+artifact repository, and clients need to ensure that they stay up to date with
+the latest version. Debugging also becomes much more difficult because different
+parts of the system will have been built from different points in the
+repository, and there is no longer a consistent view of the source tree.
+
+A better way to solve the problem of artifacts taking a long time to build is to
+use a build system that supports remote caching, as described earlier. Such a
+build system saves the resulting artifacts from every build to a location that
+is shared across engineers, so if a developer depends on an artifact that was
+recently built by someone else, the build system automatically downloads it
+instead of building it. This provides all of the performance benefits of
+depending directly on artifacts while still ensuring that builds are as
+consistent as if they were always built from the same source. This is the
+strategy used internally by Google, and Bazel can be configured to use a remote
+cache.
+
+### Security and reliability of external dependencies
+
+Depending on artifacts from third-party sources is inherently risky. There’s an
+availability risk if the third-party source (such as an artifact repository)
+goes down, because your entire build might grind to a halt if it’s unable to
+download an external dependency. There’s also a security risk: if the
+third-party system is compromised by an attacker, the attacker could replace the
+referenced artifact with one of their own design, allowing them to inject
+arbitrary code into your build. Both problems can be mitigated by mirroring any
+artifacts you depend on onto servers you control and blocking your build system
+from accessing third-party artifact repositories like Maven Central. The
+trade-off is that these mirrors take effort and resources to maintain, so the
+choice of whether to use them often depends on the scale of the project. The
+security issue can also be completely prevented with little overhead by
+requiring the hash of each third-party artifact to be specified in the source
+repository, causing the build to fail if the artifact is tampered with. Another
+alternative that completely sidesteps the issue is to vendor your project’s
+dependencies. When a project vendors its dependencies, it checks them into
+source control alongside the project’s source code, either as source or as
+binaries. This effectively means that all of the project’s external dependencies
+are converted to internal dependencies. Google uses this approach internally,
+checking every third-party library referenced throughout Google into a
+`third_party` directory at the root of Google’s source tree. However, this works
+at Google only because Google’s source control system is custom built to handle
+an extremely large monorepo, so vendoring might not be an option for all
+organizations.
\ No newline at end of file
diff --git a/versions/9.1.0/basics/distributed-builds.mdx b/versions/9.1.0/basics/distributed-builds.mdx
new file mode 100644
index 00000000..2df895a5
--- /dev/null
+++ b/versions/9.1.0/basics/distributed-builds.mdx
@@ -0,0 +1,135 @@
+---
+title: 'Distributed Builds'
+---
+
+When you have a large codebase, chains of dependencies can become very deep.
+Even simple binaries can often depend on tens of thousands of build targets. At
+this scale, it’s simply impossible to complete a build in a reasonable amount
+of time on a single machine: no build system can get around the fundamental
+laws of physics imposed on a machine’s hardware. The only way to make this work
+is with a build system that supports distributed builds wherein the units of
+work being done by the system are spread across an arbitrary and scalable
+number of machines. Assuming we’ve broken the system’s work into small enough
+units (more on this later), this would allow us to complete any build of any
+size as quickly as we’re willing to pay for. This scalability is the holy grail
+we’ve been working toward by defining an artifact-based build system.
+
+## Remote caching
+
+The simplest type of distributed build is one that only leverages _remote
+caching_, which is shown in Figure 1.
+
+[![Distributed build with remote caching](/versions/9.1.0/images/distributed-build-remote-cache.png)](/images/distributed-build-remote-cache.png)
+
+**Figure 1**. A distributed build showing remote caching
+
+Every system that performs builds, including both developer workstations and
+continuous integration systems, shares a reference to a common remote cache
+service. This service might be a fast and local short-term storage system like
+Redis or a cloud service like Google Cloud Storage. Whenever a user needs to
+build an artifact, whether directly or as a dependency, the system first checks
+with the remote cache to see if that artifact already exists there. If so, it
+can download the artifact instead of building it. If not, the system builds the
+artifact itself and uploads the result back to the cache. This means that
+low-level dependencies that don’t change very often can be built once and shared
+across users rather than having to be rebuilt by each user. At Google, many
+artifacts are served from a cache rather than built from scratch, vastly
+reducing the cost of running our build system.
+
+For a remote caching system to work, the build system must guarantee that builds
+are completely reproducible. That is, for any build target, it must be possible
+to determine the set of inputs to that target such that the same set of inputs
+will produce exactly the same output on any machine. This is the only way to
+ensure that the results of downloading an artifact are the same as the results
+of building it oneself. Note that this requires that each artifact in the cache
+be keyed on both its target and a hash of its inputs—that way, different
+engineers could make different modifications to the same target at the same
+time, and the remote cache would store all of the resulting artifacts and serve
+them appropriately without conflict.
+
+Of course, for there to be any benefit from a remote cache, downloading an
+artifact needs to be faster than building it. This is not always the case,
+especially if the cache server is far from the machine doing the build. Google’s
+network and build system is carefully tuned to be able to quickly share build
+results.
+
+## Remote execution
+
+Remote caching isn’t a true distributed build. If the cache is lost or if you
+make a low-level change that requires everything to be rebuilt, you still need
+to perform the entire build locally on your machine. The true goal is to support
+remote execution, in which the actual work of doing the build can be spread
+across any number of workers. Figure 2 depicts a remote execution system.
+
+[![Remote execution system](/versions/9.1.0/images/remote-execution-system.png)](/images/remote-execution-system.png)
+
+**Figure 2**. A remote execution system
+
+The build tool running on each user’s machine (where users are either human
+engineers or automated build systems) sends requests to a central build master.
+The build master breaks the requests into their component actions and schedules
+the execution of those actions over a scalable pool of workers. Each worker
+performs the actions asked of it with the inputs specified by the user and
+writes out the resulting artifacts. These artifacts are shared across the other
+machines executing actions that require them until the final output can be
+produced and sent to the user.
+
+The trickiest part of implementing such a system is managing the communication
+between the workers, the master, and the user’s local machine. Workers might
+depend on intermediate artifacts produced by other workers, and the final output
+needs to be sent back to the user’s local machine. To do this, we can build on
+top of the distributed cache described previously by having each worker write
+its results to and read its dependencies from the cache. The master blocks
+workers from proceeding until everything they depend on has finished, in which
+case they’ll be able to read their inputs from the cache. The final product is
+also cached, allowing the local machine to download it. Note that we also need a
+separate means of exporting the local changes in the user’s source tree so that
+workers can apply those changes before building.
+
+For this to work, all of the parts of the artifact-based build systems described
+earlier need to come together. Build environments must be completely
+self-describing so that we can spin up workers without human intervention. Build
+processes themselves must be completely self-contained because each step might
+be executed on a different machine. Outputs must be completely deterministic so
+that each worker can trust the results it receives from other workers. Such
+guarantees are extremely difficult for a task-based system to provide, which
+makes it nigh-impossible to build a reliable remote execution system on top of
+one.
+
+## Distributed builds at Google
+
+Since 2008, Google has been using a distributed build system that employs both
+remote caching and remote execution, which is illustrated in Figure 3.
+
+[![High-level build system](/versions/9.1.0/images/high-level-build-system.png)](/images/high-level-build-system.png)
+
+**Figure 3**. Google’s distributed build system
+
+Google’s remote cache is called ObjFS. It consists of a backend that stores
+build outputs in Bigtables distributed throughout our fleet of production
+machines and a frontend FUSE daemon named objfsd that runs on each developer’s
+machine. The FUSE daemon allows engineers to browse build outputs as if they
+were normal files stored on the workstation, but with the file content
+downloaded on-demand only for the few files that are directly requested by the
+user. Serving file contents on-demand greatly reduces both network and disk
+usage, and the system is able to build twice as fast compared to when we stored
+all build output on the developer’s local disk.
+
+Google’s remote execution system is called Forge. A Forge client in Blaze
+(Bazel's internal equivalent) called
+the Distributor sends requests for each action to a job running in our
+datacenters called the Scheduler. The Scheduler maintains a cache of action
+results, allowing it to return a response immediately if the action has already
+been created by any other user of the system. If not, it places the action into
+a queue. A large pool of Executor jobs continually read actions from this queue,
+execute them, and store the results directly in the ObjFS Bigtables. These
+results are available to the executors for future actions, or to be downloaded
+by the end user via objfsd.
+
+The end result is a system that scales to efficiently support all builds
+performed at Google. And the scale of Google’s builds is truly massive: Google
+runs millions of builds executing millions of test cases and producing petabytes
+of build outputs from billions of lines of source code every day. Not only does
+such a system let our engineers build complex codebases quickly, it also allows
+us to implement a huge number of automated tools and systems that rely on our
+build.
diff --git a/versions/9.1.0/basics/hermeticity.mdx b/versions/9.1.0/basics/hermeticity.mdx
new file mode 100644
index 00000000..5827d960
--- /dev/null
+++ b/versions/9.1.0/basics/hermeticity.mdx
@@ -0,0 +1,107 @@
+---
+title: 'Hermeticity'
+---
+
+This page covers hermeticity, the benefits of using hermetic builds, and
+strategies for identifying non-hermetic behavior in your builds.
+
+## Overview {#overview}
+
+When given the same input source code and product configuration, a hermetic
+build system always returns the same output by isolating the build from changes
+to the host system.
+
+In order to isolate the build, hermetic builds are insensitive to libraries and
+other software installed on the local or remote host machine. They depend on
+specific versions of build tools, such as compilers, and dependencies, such as
+libraries. This makes the build process self-contained as it doesn't rely on
+services external to the build environment.
+
+The two important aspects of hermeticity are:
+
+* **Isolation**: Hermetic build systems treat tools as source code. They
+  download copies of tools and manage their storage and use inside managed file
+  trees. This creates isolation between the host machine and local user,
+  including installed versions of languages.
+* **Source identity**: Hermetic build systems try to ensure the sameness of
+  inputs. Code repositories, such as Git, identify sets of code mutations with a
+  unique hash code. Hermetic build systems use this hash to identify changes to
+  the build's input.
+
+## Benefits {#benefits}
+
+The major benefits of hermetic builds are:
+
+* **Speed**: The output of an action can be cached, and the action need not be
+  run again unless inputs change.
+* **Parallel execution**: For given input and output, the build system can
+  construct a graph of all actions to calculate efficient and parallel
+  execution. The build system loads the rules and calculates an action graph
+  and hash inputs to look up in the cache.
+* **Multiple builds**: You can build multiple hermetic builds on the same
+  machine, each build using different tools and versions.
+* **Reproducibility**: Hermetic builds are good for troubleshooting because you
+  know the exact conditions that produced the build.
+
+## Identifying non-hermeticity {#nonhermeticity}
+
+If you are preparing to switch to Bazel, migration is easier if you improve
+your existing builds' hermeticity in advance. Some common sources of
+non-hermeticity in builds are:
+
+* Arbitrary processing in `.mk` files
+* Actions or tooling that create files non-deterministically, usually involving
+  build IDs or timestamps
+* System binaries that differ across hosts (such as `/usr/bin` binaries, absolute
+  paths, system C++ compilers for native C++ rules autoconfiguration)
+* Writing to the source tree during the build. This prevents the same source
+  tree from being used for another target. The first build writes to the source
+  tree, fixing the source tree for target A. Then trying to build target B may
+  fail.
+
+## Troubleshooting non-hermetic builds {#troubleshooting-nonhermeticity}
+
+Starting with local execution, issues that affect local cache hits reveal
+non-hermetic actions.
+
+* Ensure null sequential builds: If you run `make` and get a successful build,
+  running the build again should not rebuild any targets. If you run each build
+  step twice or on different systems, compare a hash of the file contents and
+  get results that differ, the build is not reproducible.
+* Run steps to
+  [debug local cache hits](/versions/9.1.0/remote/cache-remote#troubleshooting-cache-hits)
+  from a variety of potential client machines to ensure that you catch any
+  cases of client environment leaking into the actions.
+* Execute a build within a docker container that contains nothing but the
+  checked-out source tree and explicit list of host tools. Build breakages and
+  error messages will catch implicit system dependencies.
+* Discover and fix hermeticity problems using
+  [remote execution rules](/versions/9.1.0/remote/rules#overview).
+* Enable strict [sandboxing](/versions/9.1.0/docs/sandboxing)
+  at the per-action level, since actions in a build can be stateful and affect
+  the build or the output.
+* [Workspace rules](/versions/9.1.0/remote/workspace)
+  allow developers to add dependencies to external workspaces, but they are
+  rich enough to allow arbitrary processing to happen in the process. You can
+  get a log of some potentially non-hermetic actions in Bazel workspace rules by
+  adding the flag
+  `--experimental_workspace_rules_log_file=PATH` to
+  your Bazel command.
+
+Note: Make your build fully hermetic when mixing remote and local execution,
+using Bazel’s “dynamic strategy” functionality. Running Bazel inside the remote
+Docker container will enable the build to execute the same in both environments.
+
+## Hermeticity with Bazel {#hermeticity-bazel}
+
+For more information about how other projects have had success using hermetic
+builds with Bazel, see these  BazelCon talks:
+
+*   [Building Real-time Systems with Bazel](https://www.youtube.com/watch?v=t_3bckhV_YI) (SpaceX)
+*   [Bazel Remote Execution and Remote Caching](https://www.youtube.com/watch?v=_bPyEbAyC0s) (Uber and TwoSigma)
+*   [Faster Builds With Remote Execution and Caching](https://www.youtube.com/watch?v=MyuJRUwT5LI)
+*   [Fusing Bazel: Faster Incremental Builds](https://www.youtube.com/watch?v=rQd9Zd1ONOw)
+*   [Remote Execution vs Local Execution](https://www.youtube.com/watch?v=C8wHmIln--g)
+*   [Improving the Usability of Remote Caching](https://www.youtube.com/watch?v=u5m7V3ZRHLA) (IBM)
+*   [Building Self Driving Cars with Bazel](https://www.youtube.com/watch?v=Gh4SJuYUoQI&list=PLxNYxgaZ8Rsf-7g43Z8LyXct9ax6egdSj&index=4&t=0s) (BMW)
+*   [Building Self Driving Cars with Bazel + Q&A](https://www.youtube.com/watch?v=fjfFe98LTm8&list=PLxNYxgaZ8Rsf-7g43Z8LyXct9ax6egdSj&index=29) (GM Cruise)
diff --git a/versions/9.1.0/basics/index.mdx b/versions/9.1.0/basics/index.mdx
new file mode 100644
index 00000000..ece40834
--- /dev/null
+++ b/versions/9.1.0/basics/index.mdx
@@ -0,0 +1,55 @@
+---
+title: 'Build Basics'
+---
+
+A build system is one of the most important parts of an engineering organization
+because each developer interacts with it potentially dozens or hundreds of times
+per day. A fully featured build system is necessary to enable developer
+productivity as an organization scales. For individual developers, it's
+straightforward to just compile your code and so a build system might seem
+excessive. But at a larger scale, having a build system helps with managing
+shared dependencies, such as relying on another part of the code base, or an
+external resource, such as a library. Build systems help to make sure that you
+have everything you need to build your code before it starts building. Build
+systems also increase velocity when they're set up to help engineers share
+resources and results.
+
+This section covers some history and basics of building and build systems,
+including design decisions that went into making Bazel. If you're
+familiar with artifact-based build systems, such as Bazel, Buck, and Pants, you
+can skip this section, but it's a helpful overview to understand why
+artifact-based build systems are excellent at enabling scale.
+
+Note: Much of this section's content comes from the _Build Systems and
+Build Philosophy_ chapter of the
+[_Software Engineering at Google_ book](https://abseil.io/resources/swe-book/html/ch18.html).
+Thank you to the original author, Erik Kuefler, for allowing its reuse and
+modification here!
+
+*   **[Why a Build System?](/versions/9.1.0/basics/build-systems)**
+
+    If you haven't used a build system before, start here. This page covers why
+    you should use a build system, and why compilers and build scripts aren't
+    the best choice once your organization starts to scale beyond a few
+    developers.
+
+*   **[Task-Based Build Systems](/versions/9.1.0/basics/task-based-builds)**
+
+    This page discusses task-based build systems (such as Make, Maven, and
+    Gradle) and some of their challenges.
+
+*   **[Artifact-Based Build Systems](/versions/9.1.0/basics/artifact-based-builds)**
+
+    This page discusses artifact-based build systems in response to the pain
+    points of task-based build systems.
+
+*   **[Distributed Builds](/versions/9.1.0/basics/distributed-builds)**
+
+    This page covers distributed builds, or builds that are executed outside of
+    your local machine. This requires more robust infrastructure to share
+    resources and build results (and is where the true wizardry happens!)
+
+*   **[Dependency Management](/versions/9.1.0/basics/dependencies)**
+
+    This page covers some complications of dependencies at a large scale and
+    strategies to counteract those complications.
diff --git a/versions/9.1.0/basics/task-based-builds.mdx b/versions/9.1.0/basics/task-based-builds.mdx
new file mode 100644
index 00000000..a0fe9fb2
--- /dev/null
+++ b/versions/9.1.0/basics/task-based-builds.mdx
@@ -0,0 +1,213 @@
+---
+title: 'Task-Based Build Systems'
+---
+
+This page covers task-based build systems, how they work and some of the
+complications that can occur with task-based systems. After shell scripts,
+task-based build systems are the next logical evolution of building.
+
+## Understanding task-based build systems
+
+In a task-based build system, the fundamental unit of work is the task. Each
+task is a script that can execute any sort of logic, and tasks specify other
+tasks as dependencies that must run before them. Most major build systems in use
+today, such as Ant, Maven, Gradle, Grunt, and Rake, are task based. Instead of
+shell scripts, most modern build systems require engineers to create build files
+that describe how to perform the build.
+
+Take this example from the
+[Ant manual](https://ant.apache.org/manual/using.html):
+
+```xml
+
+   
+     simple example build file
+   
+   
+   
+   
+   
+
+   
+     
+     
+     
+     
+   
+   
+     
+     
+   
+   
+     
+     
+     
+     
+   
+   
+     
+     
+     
+   
+
+```
+
+The buildfile is written in XML and defines some simple metadata about the build
+along with a list of tasks (the `` tags in the XML). (Ant uses the word
+_target_ to represent a _task_, and it uses the word _task_ to refer to
+_commands_.) Each task executes a list of possible commands defined by Ant,
+which here include creating and deleting directories, running `javac`, and
+creating a JAR file. This set of commands can be extended by user-provided
+plug-ins to cover any sort of logic. Each task can also define the tasks it
+depends on via the depends attribute. These dependencies form an acyclic graph,
+as seen in Figure 1.
+
+[![Acrylic graph showing dependencies](/versions/9.1.0/images/task-dependencies.png)](/images/task-dependencies.png)
+
+Figure 1. An acyclic graph showing dependencies
+
+Users perform builds by providing tasks to Ant’s command-line tool. For example,
+when a user types `ant dist`, Ant takes the following steps:
+
+1.  Loads a file named `build.xml` in the current directory and parses it to
+    create the graph structure shown in Figure 1.
+1.  Looks for the task named `dist` that was provided on the command line and
+    discovers that it has a dependency on the task named `compile`.
+1.  Looks for the task named `compile` and discovers that it has a dependency on
+    the task named `init`.
+1.  Looks for the task named `init` and discovers that it has no dependencies.
+1.  Executes the commands defined in the `init` task.
+1.  Executes the commands defined in the `compile` task given that all of that
+    task’s dependencies have been run.
+1.  Executes the commands defined in the `dist` task given that all of that
+    task’s dependencies have been run.
+
+In the end, the code executed by Ant when running the `dist` task is equivalent
+to the following shell script:
+
+```posix-terminal
+./createTimestamp.sh
+
+mkdir build/
+
+javac src/* -d build/
+
+mkdir -p dist/lib/
+
+jar cf dist/lib/MyProject-$(date --iso-8601).jar build/*
+```
+
+When the syntax is stripped away, the buildfile and the build script actually
+aren’t too different. But we’ve already gained a lot by doing this. We can
+create new buildfiles in other directories and link them together. We can easily
+add new tasks that depend on existing tasks in arbitrary and complex ways. We
+need only pass the name of a single task to the `ant` command-line tool, and it
+determines everything that needs to be run.
+
+Ant is an old piece of software, originally released in 2000. Other tools like
+Maven and Gradle have improved on Ant in the intervening years and essentially
+replaced it by adding features like automatic management of external
+dependencies and a cleaner syntax without any XML. But the nature of these newer
+systems remains the same: they allow engineers to write build scripts in a
+principled and modular way as tasks and provide tools for executing those tasks
+and managing dependencies among them.
+
+## The dark side of task-based build systems
+
+Because these tools essentially let engineers define any script as a task, they
+are extremely powerful, allowing you to do pretty much anything you can imagine
+with them. But that power comes with drawbacks, and task-based build systems can
+become difficult to work with as their build scripts grow more complex. The
+problem with such systems is that they actually end up giving _too much power to
+engineers and not enough power to the system_. Because the system has no idea
+what the scripts are doing, performance suffers, as it must be very conservative
+in how it schedules and executes build steps. And there’s no way for the system
+to confirm that each script is doing what it should, so scripts tend to grow in
+complexity and end up being another thing that needs debugging.
+
+### Difficulty of parallelizing build steps
+
+Modern development workstations are quite powerful, with multiple cores that are
+capable of executing several build steps in parallel. But task-based systems are
+often unable to parallelize task execution even when it seems like they should
+be able to. Suppose that task A depends on tasks B and C. Because tasks B and C
+have no dependency on each other, is it safe to run them at the same time so
+that the system can more quickly get to task A? Maybe, if they don’t touch any
+of the same resources. But maybe not—perhaps both use the same file to track
+their statuses and running them at the same time causes a conflict. There’s no
+way in general for the system to know, so either it has to risk these conflicts
+(leading to rare but very difficult-to-debug build problems), or it has to
+restrict the entire build to running on a single thread in a single process.
+This can be a huge waste of a powerful developer machine, and it completely
+rules out the possibility of distributing the build across multiple machines.
+
+### Difficulty performing incremental builds
+
+A good build system allows engineers to perform reliable incremental builds such
+that a small change doesn’t require the entire codebase to be rebuilt from
+scratch. This is especially important if the build system is slow and unable to
+parallelize build steps for the aforementioned reasons. But unfortunately,
+task-based build systems struggle here, too. Because tasks can do anything,
+there’s no way in general to check whether they’ve already been done. Many tasks
+simply take a set of source files and run a compiler to create a set of
+binaries; thus, they don’t need to be rerun if the underlying source files
+haven’t changed. But without additional information, the system can’t say this
+for sure—maybe the task downloads a file that could have changed, or maybe it
+writes a timestamp that could be different on each run. To guarantee
+correctness, the system typically must rerun every task during each build. Some
+build systems try to enable incremental builds by letting engineers specify the
+conditions under which a task needs to be rerun. Sometimes this is feasible, but
+often it’s a much trickier problem than it appears. For example, in languages
+like C++ that allow files to be included directly by other files, it’s
+impossible to determine the entire set of files that must be watched for changes
+without parsing the input sources. Engineers often end up taking shortcuts, and
+these shortcuts can lead to rare and frustrating problems where a task result is
+reused even when it shouldn’t be. When this happens frequently, engineers get
+into the habit of running clean before every build to get a fresh state,
+completely defeating the purpose of having an incremental build in the first
+place. Figuring out when a task needs to be rerun is surprisingly subtle, and is
+a job better handled by machines than humans.
+
+### Difficulty maintaining and debugging scripts
+
+Finally, the build scripts imposed by task-based build systems are often just
+difficult to work with. Though they often receive less scrutiny, build scripts
+are code just like the system being built, and are easy places for bugs to hide.
+Here are some examples of bugs that are very common when working with a
+task-based build system:
+
+*   Task A depends on task B to produce a particular file as output. The owner
+    of task B doesn’t realize that other tasks rely on it, so they change it to
+    produce output in a different location. This can’t be detected until someone
+    tries to run task A and finds that it fails.
+*   Task A depends on task B, which depends on task C, which is producing a
+    particular file as output that’s needed by task A. The owner of task B
+    decides that it doesn’t need to depend on task C any more, which causes task
+    A to fail even though task B doesn’t care about task C at all!
+*   The developer of a new task accidentally makes an assumption about the
+    machine running the task, such as the location of a tool or the value of
+    particular environment variables. The task works on their machine, but fails
+    whenever another developer tries it.
+*   A task contains a nondeterministic component, such as downloading a file
+    from the internet or adding a timestamp to a build. Now, people get
+    potentially different results each time they run the build, meaning that
+    engineers won’t always be able to reproduce and fix one another’s failures
+    or failures that occur on an automated build system.
+*   Tasks with multiple dependencies can create race conditions. If task A
+    depends on both task B and task C, and task B and C both modify the same
+    file, task A gets a different result depending on which one of tasks B and C
+    finishes first.
+
+There’s no general-purpose way to solve these performance, correctness, or
+maintainability problems within the task-based framework laid out here. So long
+as engineers can write arbitrary code that runs during the build, the system
+can’t have enough information to always be able to run builds quickly and
+correctly. To solve the problem, we need to take some power out of the hands of
+engineers and put it back in the hands of the system and reconceptualize the
+role of the system not as running tasks, but as producing artifacts.
+
+This approach led to the creation of artifact-based build systems, like Blaze
+and Bazel.
diff --git a/versions/9.1.0/brand/index.mdx b/versions/9.1.0/brand/index.mdx
new file mode 100644
index 00000000..a2d44cc7
--- /dev/null
+++ b/versions/9.1.0/brand/index.mdx
@@ -0,0 +1,86 @@
+---
+title: 'Bazel Brand Guidelines'
+---
+
+The Bazel trademark and logo ("Bazel Trademarks") are trademarks of Google, and
+are treated separately from the copyright or patent license grants contained in
+the Apache-licensed Bazel repositories on GitHub. Any use of the Bazel
+Trademarks other than those permitted in these guidelines must be approved in
+advance.
+
+## Purpose of the Brand Guidelines {#purpose-brand}
+
+These guidelines exist to ensure that the Bazel project can share its technology
+under open source licenses while making sure that the "Bazel" brand is protected
+as a meaningful source identifier in a way that's consistent with trademark law.
+By adhering to these guidelines, you help to promote the freedom to use and
+develop high-quality Bazel technology.
+
+## Acceptable Uses {#acceptable-uses}
+
+Given the open nature of Bazel, you may use the Bazel trademark to refer to the
+project without prior written permission. Examples of these approved references
+include the following:
+
+*   To refer to the Bazel Project itself;
+*   To link to bazel.build;
+*   To refer to unmodified source code or other files shared by the Bazel
+    repositories on GitHub;
+*   In blog posts, news articles, or educational materials about Bazel;
+*   To accurately identify that your design or implementation is based on, is
+    for use with, or is compatible with Bazel technology.
+
+Examples:
+
+*   \[Your Product\] for Bazel
+*   \[Your Product\] is compatible with Bazel
+*   \[XYZ\] Conference for Bazel Users
+
+## General Guidelines {#general-guidelines}
+
+*   The Bazel name may never be used or registered in a manner that would cause
+    confusion as to Google's sponsorship, affiliation, or endorsement.
+*   Don't use the Bazel name as part of your company name, product name, domain
+    name, or social media profile.
+*   Other than as permitted by these guidelines, the Bazel name should not be
+    combined with other trademarks, terms, or source identifiers.
+*   Don't remove, distort or alter any element of the Bazel Trademarks. That
+    includes modifying the Bazel Trademark, for example, through hyphenation,
+    combination or abbreviation. Do not shorten, abbreviate, or create acronyms
+    out of the Bazel Trademarks.
+*   Don't display the word Bazel using any different stylization, color, or font
+    from the surrounding text.
+*   Don't use the term Bazel as a verb or use it in possessive form.
+*   Don't use the Bazel logo on any website, product UI, or promotional
+    materials without prior written permission from
+    [product@bazel.build](mailto:product@bazel.build).
+
+## Usage for Events and Community Groups {#usage-events}
+
+The Bazel word mark may be used referentially in events, community groups, or
+other gatherings related to the Bazel build system, but it may not be used in a
+manner that implies official status or endorsement.
+
+Examples of appropriate naming conventions are:
+
+*   \[XYZ\] Bazel User Group
+*   Bazel Community Day at \[XYZ\]
+*   \[XYZ\] Conference for Bazel Users
+
+where \[XYZ\] represents the location and optionally other wordings.
+
+Any naming convention that may imply official status or endorsement requires
+review for approval from [product@bazel.build](mailto:product@bazel.build).
+
+Examples of naming conventions that require prior written permission:
+
+*   BazelCon
+*   Bazel Conference
+
+## Contact Us {#contact-us}
+
+Please do not hesitate to contact us at
+[product@bazel.build](mailto:product@bazel.build) if you are unsure whether your
+intended use of the Bazel Trademarks is in compliance with these guidelines, or
+to ask for permission to use the Bazel Trademarks, clearly describing the
+intended usage and duration.
\ No newline at end of file
diff --git a/versions/9.1.0/build/share-variables.mdx b/versions/9.1.0/build/share-variables.mdx
new file mode 100644
index 00000000..b9f6c4bf
--- /dev/null
+++ b/versions/9.1.0/build/share-variables.mdx
@@ -0,0 +1,83 @@
+---
+title: 'Sharing Variables'
+---
+
+`BUILD` files are intended to be simple and declarative. They will typically
+consist of a series of target declarations. As your code base and your `BUILD`
+files get larger, you will probably notice some duplication, such as:
+
+``` python
+cc_library(
+  name = "foo",
+  copts = ["-DVERSION=5"],
+  srcs = ["foo.cc"],
+)
+
+cc_library(
+  name = "bar",
+  copts = ["-DVERSION=5"],
+  srcs = ["bar.cc"],
+  deps = [":foo"],
+)
+```
+
+Code duplication in `BUILD` files is usually fine. This can make the file more
+readable: each declaration can be read and understood without any context. This
+is important, not only for humans, but also for external tools. For example, a
+tool might be able to read and update `BUILD` files to add missing dependencies.
+Code refactoring and code reuse might prevent this kind of automated
+modification.
+
+If it is useful to share values (for example, if values must be kept in sync),
+you can introduce a variable:
+
+``` python
+COPTS = ["-DVERSION=5"]
+
+cc_library(
+  name = "foo",
+  copts = COPTS,
+  srcs = ["foo.cc"],
+)
+
+cc_library(
+  name = "bar",
+  copts = COPTS,
+  srcs = ["bar.cc"],
+  deps = [":foo"],
+)
+```
+
+Multiple declarations now use the value `COPTS`. By convention, use uppercase
+letters to name global constants.
+
+## Sharing variables across multiple BUILD files
+
+If you need to share a value across multiple `BUILD` files, you have to put it
+in a `.bzl` file. `.bzl` files contain definitions (variables and functions)
+that can be used in `BUILD` files.
+
+In `path/to/variables.bzl`, write:
+
+``` python
+COPTS = ["-DVERSION=5"]
+```
+
+Then, you can update your `BUILD` files to access the variable:
+
+``` python
+load("//path/to:variables.bzl", "COPTS")
+
+cc_library(
+  name = "foo",
+  copts = COPTS,
+  srcs = ["foo.cc"],
+)
+
+cc_library(
+  name = "bar",
+  copts = COPTS,
+  srcs = ["bar.cc"],
+  deps = [":foo"],
+)
+```
diff --git a/versions/9.1.0/build/style-guide.mdx b/versions/9.1.0/build/style-guide.mdx
new file mode 100644
index 00000000..15d2b285
--- /dev/null
+++ b/versions/9.1.0/build/style-guide.mdx
@@ -0,0 +1,401 @@
+---
+title: 'BUILD Style Guide'
+---
+
+## Prefer DAMP BUILD files over DRY {#prefer-damp-build-files-over-dry}
+
+The DRY principle — "Don't Repeat Yourself" — encourages uniqueness by
+introducing abstractions such as variables and functions to avoid redundancy in
+code.
+
+In contrast, the DAMP principle — "Descriptive and Meaningful Phrases" —
+encourages readability over uniqueness to make files easier to understand and
+maintain.
+
+`BUILD` files aren't code, they are configurations. They aren't tested like
+code, but do need to be maintained by people and tools. That makes DAMP better
+for them than DRY.
+
+## BUILD.bazel file formatting {#formatting}
+
+`BUILD` file formatting follows the same approach as Go, where a standardized
+tool takes care of most formatting issues.
+[Buildifier](https://github.com/bazelbuild/buildifier) is a tool that parses and
+emits the source code in a standard style. Every `BUILD` file is therefore
+formatted in the same automated way, which makes formatting a non-issue during
+code reviews. It also makes it easier for tools to understand, edit, and
+generate `BUILD` files.
+
+`BUILD` file formatting must match the output of `buildifier`.
+
+### Formatting example {#formatting-example}
+
+```python
+# Test code implementing the Foo controller.
+package(default_testonly = True)
+
+py_test(
+    name = "foo_test",
+    srcs = glob(["*.py"]),
+    data = [
+        "//data/production/foo:startfoo",
+        "//foo",
+        "//third_party/java/jdk:jdk-k8",
+    ],
+    flaky = True,
+    deps = [
+        ":check_bar_lib",
+        ":foo_data_check",
+        ":pick_foo_port",
+        "//pyglib",
+        "//testing/pybase",
+    ],
+)
+```
+
+## File structure {#file-structure}
+
+**Recommendation**: Use the following order (every element is optional):
+
+*   Package description (a comment)
+
+*   All `load()` statements
+
+*   The `package()` function.
+
+*   Calls to rules and macros
+
+Buildifier makes a distinction between a standalone comment and a comment
+attached to an element. If a comment is not attached to a specific element, use
+an empty line after it. The distinction is important when doing automated
+changes (for example, to keep or remove a comment when deleting a rule).
+
+```python
+# Standalone comment (such as to make a section in a file)
+
+# Comment for the cc_library below
+cc_library(name = "cc")
+```
+
+## References to targets in the current package {#targets-current-package}
+
+Files should be referred to by their paths relative to the package directory
+(without ever using up-references, such as `..`). Generated files should be
+prefixed with "`:`" to indicate that they are not sources. Source files
+should not be prefixed with `:`. Rules should be prefixed with `:`. For
+example, assuming `x.cc` is a source file:
+
+```python
+cc_library(
+    name = "lib",
+    srcs = ["x.cc"],
+    hdrs = [":gen_header"],
+)
+
+genrule(
+    name = "gen_header",
+    srcs = [],
+    outs = ["x.h"],
+    cmd = "echo 'int x();' > $@",
+)
+```
+
+## Target naming {#target-naming}
+
+Target names should be descriptive. If a target contains one source file,
+the target should generally have a name derived from that source (for example, a
+`cc_library` for `chat.cc` could be named `chat`, or a `java_library` for
+`DirectMessage.java` could be named `direct_message`).
+
+The eponymous target for a package (the target with the same name as the
+containing directory) should provide the functionality described by the
+directory name. If there is no such target, do not create an eponymous
+target.
+
+Prefer using the short name when referring to an eponymous target (`//x`
+instead of `//x:x`). If you are in the same package, prefer the local
+reference (`:x` instead of `//x`).
+
+Avoid using "reserved" target names which have special meaning. This includes
+`all`, `__pkg__`, and `__subpackages__`, these names have special
+semantics and can cause confusion and unexpected behaviors when they are used.
+
+In the absence of a prevailing team convention these are some non-binding
+recommendations that are broadly used at Google:
+
+* In general, use ["snake_case"](https://en.wikipedia.org/wiki/Snake_case)
+    * For a `java_library` with one `src` this means using a name that is not
+      the same as the filename without the extension
+    * For Java `*_binary` and `*_test` rules, use
+      ["Upper CamelCase"](https://en.wikipedia.org/wiki/Camel_case).
+      This allows for the target name to match one of the `src`s. For
+      `java_test`, this makes it possible for the `test_class` attribute to be
+      inferred from the name of the target.
+* If there are multiple variants of a particular target then add a suffix to
+  disambiguate (such as. `:foo_dev`, `:foo_prod` or `:bar_x86`, `:bar_x64`)
+* Suffix `_test` targets with `_test`, `_unittest`, `Test`, or `Tests`
+* Avoid meaningless suffixes like `_lib` or `_library` (unless necessary to
+  avoid conflicts between a `_library` target and its corresponding `_binary`)
+* For proto related targets:
+    * `proto_library` targets should have names ending in `_proto`
+    * Languages specific `*_proto_library` rules should match the underlying
+      proto but replace `_proto` with a language specific suffix such as:
+         * **`cc_proto_library`**: `_cc_proto`
+         * **`java_proto_library`**: `_java_proto`
+         * **`java_lite_proto_library`**: `_java_proto_lite`
+
+## Visibility {#visibility}
+
+Visibility should be scoped as tightly as possible, while still allowing access
+by tests and reverse dependencies. Use `__pkg__` and `__subpackages__` as
+appropriate.
+
+Avoid setting package `default_visibility` to `//visibility:public`.
+`//visibility:public` should be individually set only for targets in the
+project's public API. These could be libraries that are designed to be depended
+on by external projects or binaries that could be used by an external project's
+build process.
+
+## Dependencies {#dependencies}
+
+Dependencies should be restricted to direct dependencies (dependencies
+needed by the sources listed in the rule). Do not list transitive dependencies.
+
+Package-local dependencies should be listed first and referred to in a way
+compatible with the
+[References to targets in the current package](#targets-current-package)
+section above (not by their absolute package name).
+
+Prefer to list dependencies directly, as a single list. Putting the "common"
+dependencies of several targets into a variable reduces maintainability, makes
+it impossible for tools to change the dependencies of a target, and can lead to
+unused dependencies.
+
+## Globs {#globs}
+
+Indicate "no targets" with `[]`. Do not use a glob that matches nothing: it
+is more error-prone and less obvious than an empty list.
+
+### Recursive {#recursive}
+
+Do not use recursive globs to match source files (for example,
+`glob(["**/*.java"])`).
+
+Recursive globs make `BUILD` files difficult to reason about because they skip
+subdirectories containing `BUILD` files.
+
+Recursive globs are generally less efficient than having a `BUILD` file per
+directory with a dependency graph defined between them as this enables better
+remote caching and parallelism.
+
+It is good practice to author a `BUILD` file in each directory and define a
+dependency graph between them.
+
+### Non-recursive {#non-recursive}
+
+Non-recursive globs are generally acceptable.
+
+## Avoid list comprehensions {#list-comprehensions}
+
+Avoid using list comprehensions at the top level of a `BUILD.bazel` file.
+Automate repetitive calls by creating each named target with a separate
+top-level rule or macro call. Give each a short `name` parameter for clarity.
+
+List comprehension reduces the following:
+
+*   Maintainability. It's difficult or impossible for human maintainers and
+    large scale automated changes to update list comprehensions correctly.
+*   Discoverability. Since the pattern doesn't have `name` parameters,
+    it's hard to find the rule by name.
+
+A common application of the list comprehension pattern is to generate tests. For
+example:
+
+```build {.bad}
+[[java_test(
+    name = "test_%s_%s" % (backend, count),
+    srcs = [ ... ],
+    deps = [ ... ],
+    ...
+) for backend in [
+    "fake",
+    "mock",
+]] for count in [
+    1,
+    10,
+]]
+```
+
+We recommend using simpler alternatives. For example, define a macro that
+generates one test and invoke it for each top-level `name`:
+
+```build
+my_java_test(name = "test_fake_1",
+    ...)
+my_java_test(name = "test_fake_10",
+    ...)
+...
+```
+
+## Don't use deps variables {#no-dep-vars}
+
+Don't use list variables to encapsulate common dependencies:
+
+```build {.bad}
+COMMON_DEPS = [
+  "//d:e",
+  "//x/y:z",
+]
+
+cc_library(name = "a",
+    srcs = ["a.cc"],
+    deps = COMMON_DEPS + [ ... ],
+)
+
+cc_library(name = "b",
+    srcs = ["b.cc"],
+    deps = COMMON_DEPS + [ ... ],
+)
+```
+
+Similarly, don't use a library target with
+[`exports`](/versions/9.1.0/reference/be/java#java_library.exports) to group dependencies.
+
+Instead, list the dependencies separately for each target:
+
+```build {.good}
+cc_library(name = "a",
+    srcs = ["a.cc"],
+    deps = [
+      "//a:b",
+      "//x/y:z",
+      ...
+    ],
+)
+
+cc_library(name = "b",
+    srcs = ["b.cc"],
+    deps = [
+      "//a:b",
+      "//x/y:z",
+      ...
+    ],
+)
+```
+
+Let [Gazelle](https://github.com/bazel-contrib/bazel-gazelle) and other tools
+maintain them. There will be repetition, but you won't have to think about how
+to manage the dependencies.
+
+## Prefer literal strings {#literal-strings}
+
+Although Starlark provides string operators for concatenation (`+`) and
+formatting (`%`), use them with caution. It is tempting to factor out common
+string parts to make expressions more concise or break long lines. However,
+
+*   It is harder to read broken-up string values at a glance.
+
+*   Automated tools such as
+    [buildozer][buildozer] and Code Search have trouble finding values and
+    updating them correctly when the values broken up.
+
+*   In `BUILD` files, readability is more important than avoiding repetition
+    (see [DAMP versus DRY](#prefer-damp-build-files-over-dry)).
+
+*   This Style Guide
+    [warns against splitting label-valued strings](#other-conventions)
+    and
+    [explicitly permits long lines](#differences-python-style-guide).
+
+*   Buildifier automatically fuses concatenated strings when it detects that
+    they are labels.
+
+Therefore, prefer explicit, literal strings over concatenated or formatted
+strings, especially in label-type attributes such as `name` and `deps`. For
+example, this `BUILD` fragment:
+
+```build {.bad}
+NAME = "foo"
+PACKAGE = "//a/b"
+
+proto_library(
+  name = "%s_proto" % NAME,
+  deps = [PACKAGE + ":other_proto"],
+  alt_dep = "//surprisingly/long/chain/of/package/names:" +
+            "extravagantly_long_target_name",
+)
+```
+
+would be better rewritten as
+
+```build {.good}
+proto_library(
+  name = "foo_proto",
+  deps = ["//a/b:other_proto"],
+  alt_dep = "//surprisingly/long/chain/of/package/names:extravagantly_long_target_name",
+)
+```
+
+[buildozer]: https://github.com/bazelbuild/buildtools/blob/main/buildozer/README.md
+
+## Limit the symbols exported by each `.bzl` file {#limit-symbols}
+
+Minimize the number of symbols (rules, macros, constants, functions) exported by
+each public `.bzl` (Starlark) file. We recommend that a file should export
+multiple symbols only if they are certain to be used together. Otherwise, split
+it into multiple `.bzl` files, each with its own [bzl_library][bzl_library].
+
+Excessive symbols can cause `.bzl` files to grow into broad "libraries" of
+symbols, causing changes to single files to force Bazel to rebuild many targets.
+
+[bzl_library]: https://github.com/bazelbuild/bazel-skylib/blob/main/README.md#bzl_library
+
+## Other conventions {#other-conventions}
+
+ * Use uppercase and underscores to declare constants (such as `GLOBAL_CONSTANT`),
+   use lowercase and underscores to declare variables (such as `my_variable`).
+
+ * Labels should never be split, even if they are longer than 79 characters.
+   Labels should be string literals whenever possible. *Rationale*: It makes
+   find and replace easy. It also improves readability.
+
+ * The value of the name attribute should be a literal constant string (except
+   in macros). *Rationale*: External tools use the name attribute to refer a
+   rule. They need to find rules without having to interpret code.
+
+ * When setting boolean-type attributes, use boolean values, not integer values.
+   For legacy reasons, rules still convert integers to booleans as needed,
+   but this is discouraged. *Rationale*: `flaky = 1` could be misread as saying
+   "deflake this target by rerunning it once". `flaky = True` unambiguously says
+   "this test is flaky".
+
+## Differences with Python style guide {#differences-python-style-guide}
+
+Although compatibility with
+[Python style guide](https://www.python.org/dev/peps/pep-0008/)
+is a goal, there are a few differences:
+
+ * No strict line length limit. Long comments and long strings are often split
+   to 79 columns, but it is not required. It should not be enforced in code
+   reviews or presubmit scripts. *Rationale*: Labels can be long and exceed this
+   limit. It is common for `BUILD` files to be generated or edited by tools,
+   which does not go well with a line length limit.
+
+ * Implicit string concatenation is not supported. Use the `+` operator.
+   *Rationale*: `BUILD` files contain many string lists. It is easy to forget a
+   comma, which leads to a complete different result. This has created many bugs
+   in the past. [See also this discussion.](https://lwn.net/Articles/551438/)
+
+ * Use spaces around the `=` sign for keywords arguments in rules. *Rationale*:
+   Named arguments are much more frequent than in Python and are always on a
+   separate line. Spaces improve readability. This convention has been around
+   for a long time, and it is not worth modifying all existing `BUILD` files.
+
+ * By default, use double quotation marks for strings. *Rationale*: This is not
+   specified in the Python style guide, but it recommends consistency. So we
+   decided to use only double-quoted strings. Many languages use double-quotes
+   for string literals.
+
+ * Use a single blank line between two top-level definitions. *Rationale*: The
+   structure of a `BUILD` file is not like a typical Python file. It has only
+   top-level statements. Using a single-blank line makes `BUILD` files shorter.
diff --git a/versions/9.1.0/community/recommended-rules.mdx b/versions/9.1.0/community/recommended-rules.mdx
new file mode 100644
index 00000000..d6fed316
--- /dev/null
+++ b/versions/9.1.0/community/recommended-rules.mdx
@@ -0,0 +1,52 @@
+---
+title: 'Recommended Rules'
+---
+
+In the documentation, we provide a list of
+[recommended rules](/versions/9.1.0/rules).
+
+This is a set of high quality rules, which will provide a good experience to our
+users. We make a distinction between the supported rules, and the hundreds of
+rules you can find on the Internet.
+
+## Nomination {#nomination}
+
+If a ruleset meets the requirements below, a rule maintainer can nominate it
+to be part of the _recommended rules_ by filing a
+[GitHub issue](https://github.com/bazelbuild/bazel/).
+
+After a review by the [Bazel core team](/versions/9.1.0/contribute/policy), it
+will be recommended on the Bazel website.
+
+## Requirements for the rule maintainers {#requirements-rule-maintainers}
+
+*   The ruleset provides an important feature, useful to a large number of Bazel
+    users (for example, support for a widely popular language).
+*   The ruleset is well maintained. There must be at least two active maintainers.
+*   The ruleset is well documented, with examples, and easy to use.
+*   The ruleset follows the best practices and is performant (see
+    [the performance guide](/versions/9.1.0/rules/performance)).
+*   The ruleset has sufficient test coverage.
+*   The ruleset is tested on
+    [BuildKite](https://github.com/bazelbuild/continuous-integration/blob/master/buildkite/README.md)
+    with the latest version of Bazel. Tests should always pass (when used as a
+    presubmit check).
+*   The ruleset is also tested with the upcoming incompatible changes. Breakages
+    should be fixed within two weeks. Migration issues should be reported to the
+    Bazel team quickly.
+
+## Requirements for Bazel developers {#requirements-dev}
+
+*   Recommended rules are frequently tested with Bazel at head (at least once a
+    day).
+*   No change in Bazel may break a recommended rule (with the default set of
+    flags). If it happens, the change should be fixed or rolled back.
+
+## Demotion {#demotion}
+
+If there is a concern that a particular ruleset is no longer meeting the
+requirements, a [GitHub issue](https://github.com/bazelbuild/bazel/) should be
+filed.
+
+Rule maintainers will be contacted and need to respond in 2 weeks. Based on the
+outcome, Bazel core team might make a decision to demote the rule set.
diff --git a/versions/9.1.0/community/remote-execution-services.mdx b/versions/9.1.0/community/remote-execution-services.mdx
new file mode 100644
index 00000000..8d07efe4
--- /dev/null
+++ b/versions/9.1.0/community/remote-execution-services.mdx
@@ -0,0 +1,27 @@
+---
+title: 'Remote Execution Services'
+---
+
+Use the following services to run Bazel with remote execution:
+
+*   Manual
+
+    * Use the [gRPC protocol](https://github.com/bazelbuild/remote-apis)
+      directly to create your own remote execution service.
+
+*   Self-service
+
+    * [Buildbarn](https://github.com/buildbarn)
+    * [Buildfarm](https://github.com/bazelbuild/bazel-buildfarm)
+    * [BuildGrid](https://gitlab.com/BuildGrid/buildgrid)
+    * [NativeLink](https://github.com/TraceMachina/nativelink)
+
+*   Commercial
+
+    * [Aspect Build](https://www.aspect.build/) – Self-hosted remote cache and remote execution services.
+    * [Bitrise](https://bitrise.io/why/features/mobile-build-caching-for-better-build-test-performance) - Providing the world's leading mobile-first CI/CD and remote build caching platform.
+    * [BuildBuddy](https://www.buildbuddy.io) - Remote build execution,
+      caching, and results UI.
+    * [EngFlow Remote Execution](https://www.engflow.com) - Remote execution
+      and remote caching service with Build and Test UI. Can be self-hosted or hosted.
+    * [NativeLink](https://github.com/TraceMachina/nativelink) - Remote build execution, caching, analytics, and simulation.
diff --git a/versions/9.1.0/community/sig.mdx b/versions/9.1.0/community/sig.mdx
new file mode 100644
index 00000000..0de8f8ee
--- /dev/null
+++ b/versions/9.1.0/community/sig.mdx
@@ -0,0 +1,156 @@
+---
+title: 'Bazel Special Interest Groups'
+---
+
+Bazel hosts Special Interest Groups (SIGs) to focus collaboration on particular
+areas and to support communication and coordination between [Bazel owners,
+maintainers, and contributors](/versions/9.1.0/contribute/policy). This policy
+applies to [`bazelbuild`](http://github.com/bazelbuild).
+
+SIGs do their work in public. The ideal scope for a SIG covers a well-defined
+domain, where the majority of participation is from the community. SIGs may
+focus on community maintained repositories in `bazelbuild` (such as language
+rules) or focus on areas of code in the Bazel repository (such as Remote
+Execution).
+
+While not all SIGs will have the same level of energy, breadth of scope, or
+governance models, there should be sufficient evidence that there are community
+members willing to engage and contribute should the interest group be
+established. Before joining, review the group's work, and then get in touch
+with the SIG leader. Membership policies vary on a per-SIG basis.
+
+See the complete list of
+[Bazel SIGs](https://github.com/bazelbuild/community/tree/main/sigs).
+
+### Non-goals: What a SIG is not
+
+SIGs are intended to facilitate collaboration on shared work. A SIG is
+therefore:
+
+-   *Not a support forum:* a mailing list and a SIG is not the same thing
+-   *Not immediately required:* early on in a project's life, you may not know
+    if you have shared work or collaborators
+-   *Not free labor:* energy is required to grow and coordinate the work
+    collaboratively
+
+Bazel Owners take a conservative approach to SIG creation—thanks to the ease of
+starting projects on GitHub, there are many avenues where collaboration can
+happen without the need for a SIG.
+
+## SIG lifecycle
+
+This section covers how to create a SIG.
+
+### Research and consultation
+
+To propose a new SIG group, first gather evidence for approval, as specified
+below. Some possible avenues to consider are:
+
+-   A well-defined problem or set of problems the group would solve
+-   Consultation with community members who would benefit, assessing both the
+    benefit and their willingness to commit
+-   For existing projects, evidence from issues and PRs that contributors care
+    about the topic
+-   Potential goals for the group to achieve
+-   Resource requirements of running the group
+
+Even if the need for a SIG seems self-evident, the research and consultation is
+still important to the success of the group.
+
+### Create the new group
+
+The new group should follow the below process for chartering. In particular, it
+must demonstrate:
+
+-   A clear purpose and benefit to Bazel (either around a sub-project or
+    application area)
+-   Two or more contributors willing to act as group leads, existence of other
+    contributors, and evidence of demand for the group
+-   Each group needs to use at least one publicly accessible mailing list. A SIG
+    may reuse one of the public lists, such as
+    [bazel-discuss](https://groups.google.com/g/bazel-discuss), ask for a list
+    for @bazel.build, or create their own list
+-   Resources the SIG initially requires (usually, mailing list and regular
+    video call.)
+-   SIGs can serve documents and files from their directory in
+    [`bazelbuild/community`](https://github.com/bazelbuild/community)
+    or from their own repository in the
+    [`bazelbuild`](https://github.com/bazelbuild) GitHub
+    organization. SIGs may link to external resources if they choose to organize
+    their work outside of the `bazelbuild` GitHub organization
+-   Bazel Owners approve or reject SIG applications and consult other
+    stakeholders as necessary
+
+Before entering the formal parts of the process, you should consult with
+the Bazel product team, at product@bazel.build. Most SIGs require conversation
+and iteration before approval.
+
+The formal request for the new group is done by submitting a charter as a PR to
+[`bazelbuild/community`](https://github.com/bazelbuild/community),
+and including the request in the comments on the PR following the template
+below. On approval, the PR for the group is merged and the required resources
+created.
+
+### Template Request for New SIG
+
+To request a new SIG, use the template in the community repo:
+[SIG-request-template.md](https://github.com/bazelbuild/community/blob/main/governance/SIG-request-template.md).
+
+### Chartering
+
+To establish a group, you need a charter and must follow the Bazel
+[code of conduct](https://github.com/bazelbuild/bazel/blob/HEAD/CODE_OF_CONDUCT.md).
+Archives of the group will be public. Membership may either be open to all
+without approval, or available on request, pending approval of the group
+administrator.
+
+The charter must nominate an administrator. As well as an administrator, the
+group must include at least one person as lead (these may be the same person),
+who serves as point of contact for coordination as required with the Bazel
+product team.
+
+Group creators must post their charter to the group mailing list. The community
+repository in the Bazel GitHub organization archives such documents and
+policies. As groups evolve their practices and conventions, they should update
+their charters within the relevant part of the community repository.
+
+### Collaboration and inclusion
+
+While not mandated, the group should choose to make use of collaboration
+via scheduled conference calls or chat channels to conduct meetings. Any such
+meetings should be advertised on the mailing list, and notes posted to the
+mailing list afterwards. Regular meetings help drive accountability and progress
+in a SIG.
+
+Bazel product team members may proactively monitor and encourage the group to
+discussion and action as appropriate.
+
+### Launch a SIG
+
+Required activities:
+
+-   Notify Bazel general discussion groups
+    ([bazel-discuss](https://groups.google.com/g/bazel-discuss),
+    [bazel-dev](https://groups.google.com/g/bazel-dev)).
+
+Optional activities:
+
+-   Create a blog post for the Bazel blog
+
+### Health and termination of SIGs
+
+The Bazel owners make a best effort to ensure the health of SIGs. Bazel owners
+occasionally request the SIG lead to report on the SIG's work, to inform the
+broader Bazel community of the group's activity.
+
+If a SIG no longer has a useful purpose or interested community, it may be
+archived and cease operation. The Bazel product team reserves the right to
+archive such inactive SIGs to maintain the overall health of the project,
+though it is a less preferable outcome. A SIG may also opt to disband if
+it recognizes it has reached the end of its useful life.
+
+## Note
+
+*This content has been adopted from Tensorflow’s
+[SIG playbook](https://www.tensorflow.org/community/sig_playbook)
+with modifications.*
diff --git a/versions/9.1.0/community/users.mdx b/versions/9.1.0/community/users.mdx
new file mode 100644
index 00000000..7c72399d
--- /dev/null
+++ b/versions/9.1.0/community/users.mdx
@@ -0,0 +1,745 @@
+---
+title: 'Who's Using Bazel'
+---
+
+Note: Using Bazel? You can add your company on
+[StackShare](https://stackshare.io/bazel). To add yourself to this page,
+contact [product@bazel.build](mailto:product@bazel.build).
+
+This page lists companies and OSS projects that are known to use Bazel.
+This does not constitute an endorsement.
+
+## Companies using Bazel {:#companies-using-bazel}
+
+### [acqio](https://acqio.com.br){: .external}
+
+
+
+Acqio is a Fintech that provides payment products and services for small and
+medium merchants. Acqio has a handful of monorepos and uses Bazel along with
+Kubernetes to deliver fast and reliable microservices.
+
+### [Adobe](https://www.adobe.com/){: .external}
+
+
+
+Adobe has released Bazel [rules](https://github.com/adobe/rules_gitops){: .external} for
+continuous, GitOps driven Kubernetes deployments.
+
+### [Asana](https://asana.com){: .external}
+
+
+
+Asana is a web and mobile application designed to help teams track their work.
+In their own words:
+
+> Bazel has increased reliability, stability, and speed for all of builds/tests
+at Asana. We no longer need to clean because of incorrect caches.
+
+### [Ascend.io](https://ascend.io)
+
+Ascend is a Palo Alto startup that offers solutions for large data sets
+analysis. Their motto is _Big data is hard. We make it easy_.
+
+### [ASML](https://asml.com){: .external}
+
+
+
+ASML is an innovation leader in the semiconductor industry. We provide chipmakers
+with everything they need – hardware, software and services – to mass produce
+patterns on silicon through lithography.
+
+### [Beeswax](https://www.beeswax.com/){: .external}
+
+> Beeswax is a New York based startup that provides real time bidding as
+service. Bazel powers their Jenkins based continuous integration and deployment
+framework. Beeswax loves Bazel because it is blazingly fast, correct and well
+supported across many languages and platforms.
+
+### [Braintree](https://www.braintreepayments.com){: .external}
+
+
+
+Braintree, a PayPal subsidiary, develops payment solutions for websites and
+applications. They use Bazel for parts of their internal build and Paul Gross
+even posted a
+[nice piece about how their switch to Bazel went](https://www.pgrs.net/2015/09/01/migrating-from-gradle-to-bazel/).
+
+### [Canva](https://www.canva.com/){: .external}
+
+
+Canva leverages Bazel to manage its large polyglot codebase, which includes
+Java, TypeScript, Scala, Python, and more. Migration to Bazel has delivered
+significant developer and compute infrastructure efficiencies, for example 5-6x
+decreases in average CI build times, and it continues to become the foundation
+of fast, reproducible, and standardised software builds at the company.
+
+### [CarGurus](https://www.cargurus.com){: .external}
+
+
+CarGurus is on a mission to build the world's most trusted and transparent
+automotive marketplace and uses Bazel to build their polyglot monorepo.
+
+### [Compass](https://www.compass.com){: .external}
+
+Compass is a tech-driven real estate platform. With an elite team of real
+estate, technology and business professionals, we aim to be the best and most
+trusted source for home seekers.
+
+### [Databricks](https://databricks.com){: .external}
+
+
+Databricks provides cloud-based integrated workspaces based on Apache Spark™.
+
+> The Databricks codebase is a Monorepo, containing the Scala code that powers
+most of our services, Javascript for front-end UI, Python for scripting,
+Jsonnet to configure our infrastructure, and much more [...] Even though our
+monorepo contains a million lines of Scala, working with code within is fast
+and snappy.
+([Speedy Scala Builds with Bazel at Databricks](https://databricks.com/blog/2019/02/27/speedy-scala-builds-with-bazel-at-databricks.html))
+
+### [Dataform](https://dataform.co){: .external}
+
+Dataform provides scalable analytics for data teams. They maintain a handful of
+NPM packages and a documentation site in one single monorepo and they do it all
+with Bazel.
+
+After the migration to Bazel, they
+[reported many benefits](https://github.com/bazelbuild/rules_nodejs#user-testimonials){: .external},
+including:
+
+> * Faster CI: we enabled the remote build caching which has reduced our average build time from 30 minutes to 5 (for the entire repository).
+> * Improvements to local development: no more random bash scripts that you forget to run, incremental builds reduced to seconds from minutes
+> * Developer setup time: New engineers can build all our code with just 3 dependencies - bazel, docker and the JVM. The last engineer to join our team managed to build all our code in < 30 minutes on a brand new, empty laptop
+
+### [Deep Silver FISHLABS](https://www.dsfishlabs.com){: .external}
+Deep Silver FISHLABS is a developer of high-end 3D games. They use Bazel with
+C++/Python/Go/C as a base for their internal build tooling and especially for
+baking and deploying all their 3D Assets.
+
+### [Dropbox](https://www.dropbox.com/){: .external}
+
+At Dropbox, Bazel is a key component to our distributed build and test
+environment. We use Bazel to combine TypeScript/Python/Go/C/Rust into reliable
+production releases.
+
+### [Engel & Völkers](https://www.engelvoelkers.com){: .external}
+
+Engel & Völkers AG is a privately owned German company that, via a series of
+franchised offices, provides services related to real estate transactions.
+
+> One of our internal project has seen a decrease of compilation time from 11
+minutes to roughly 1 minute, this was an impressive achievement and we are
+currently working on bringing Bazel to more projects.
+([Experimenting with Google Cloud Build and Bazel](https://www.engelvoelkers.com/en/tech/engineering/software-engineering/experimenting-with-google-cloud-build-and-bazel/)){: .external}
+
+### [Etsy](https://www.etsy.com/){: .external}
+
+
+Etsy is an e-commerce website focused on handmade or vintage items and supplies,
+as well as unique factory-manufactured items.
+
+They use Bazel to build and test its Java-based search platform. Bazel produces
+both packages for bare metal servers and repeatable Docker images.
+
+### [Evertz.io](https://www.evertz.io/){: .external}
+
+Evertz.io is a multi-tenant, serverless SaaS platform for offering cost
+effective, multi-regional services worldwide to the Broadcast Media Industry,
+created by [Evertz Microsystems](https://en.wikipedia.org/wiki/Evertz_Microsystems).
+
+The website is fully built and deployed with an Angular and Bazel workflow
+([source](https://twitter.com/MattMackay/status/1113947685508341762){: .external}).
+
+### [FINDMINE](http://www.findmine.com){: .external}
+
+
+FINDMINE is a automation technology for the retail industry that uses machine
+learning to scale the currently manual and tedious process of product curation.
+We use Bazel to mechanize our entire python package building, testing, and
+deployment process.
+
+### [Flexport](https://www.flexport.com/){: .external}
+
+Flexport is a tech-enabled global freight forwarder; our mission is to make
+global trade easier for everyone. At Flexport, we use Bazel to build/test our
+Java/JavaScript services and client libraries and to generate Java and Ruby
+code from protobuf definitions.
+[Read about how we run individual JUnit 5 tests in isolation with Bazel.](https://flexport.engineering/connecting-bazel-and-junit5-by-transforming-arguments-46440c6ea068)
+
+### [Foursquare](https://foursquare.com){: .external}
+
+
+Foursquare's mission is to create technology that constructs meaningful
+bridges between digital spaces and physical places. We manage millions of
+lines of primarily Scala and Python code powering data-intensive
+applications, including complex codegen and container build processes, with
+Bazel.
+
+### [GermanTechJobs](https://germantechjobs.de){: .external}
+
+
+Bazel has simplified our workflows 10-fold and enabled shipping features at
+scale.
+
+### [Google](https://google.com){: .external}
+
+
+Bazel was designed to be able to scale to Google's needs and meet Google's
+requirements of reproducibility and platform/language support. All software at
+Google is built using Bazel. Google uses Bazel and its rules for millions of
+builds every day.
+
+### [Huawei](http://www.huawei.com/){: .external}
+
+> Huawei Technologies is using Bazel in about 30 projects, they are Java/Scala/Go
+projects, except for Go projects, others originally were built by Maven. We
+write a simple tool to translate a Maven-built project into Bazel-built one.
+More and more projects will use Bazel in recent future.
+
+### [IMC Trading](https://imc.com){: .external}
+
+
+> IMC is a global proprietary trading firm and market maker headquarted in
+Amsterdam. We are using Bazel to continuously build and test our
+Java/C++/Python/SystemVerilog projects.
+
+### [Improbable.io](https://improbable.io/){: .external}
+
+Improbable.io develops SpatialOS, a distributed operating system that enables
+creating huge simulations inhabited by millions of complex entities.
+
+### [Interaxon](https://www.choosemuse.com/){: .external}
+
+InteraXon is a thought-controlled computing firm that creates hardware and
+software platforms to convert brainwaves into digital signals.
+
+### [Jupiter](https://jupiter.co/){: .external}
+
+Jupiter is a company that provides delivery of groceries and household
+essentials every week.
+
+They use Bazel in their backend code, specifically to compile protos and Kotlin
+to JVM binaries, using remote caching.
+([source](https://starship.jupiter.co/jupiter-stack/))
+
+### [Just](https://gojust.com/){: .external}
+
+Just is an enterprise financial technology company, headquartered in Norway,
+creating software solutions to transform how global corporate treasurers manage
+risk and liquidity. Their entire application stack is built with Bazel.
+
+### [Line](https://line.me/)
+
+Line provides an app for instant communications, which is the most popular
+messaging application in Japan.
+They use Bazel on their codebase consisting of about 60% Swift and 40%
+C/C++/Objective-C/Objective-C++
+([source](https://twitter.com/thi_dt/status/1253334262020886532){: .external}).
+
+> After switching to Bazel, we were able to achieve a huge improvement in the
+build times. This brought a significant improvement in the turn-around time
+during a QA period. Distributing a new build to our testers no longer means
+another hour waiting for building and testing.
+([Improving Build Performance of LINE for iOS with Bazel](https://engineering.linecorp.com/en/blog/improving-build-performance-line-ios-bazel/){: .external})
+
+### [LingoChamp](https://www.liulishuo.com/en){: .external}
+
+
+LingoChamp provides professional solutions to English learners. We use Bazel
+for our go, java and python projects.
+
+### [LinkedIn](https://linkedin.com/){: .external}
+
+
+LinkedIn, a subsidiary of Microsoft, is the world’s largest professional social
+network. LinkedIn uses Bazel for building its iOS Apps.
+
+### [Lucid Software](https://lucid.co/){: .external}
+
+
+
+Lucid Software is a leader in visual collaboration, helping teams see and build the
+future from idea to reality. With its products—[Lucidchart](https://www.lucidchart.com/),
+[Lucidspark](https://lucidspark.com/), and [Lucidscale](https://lucidscale.com/)—teams
+can align around a shared vision, clarify complexity, and collaborate visually, no
+matter where they’re located.
+
+Lucid uses Bazel to build millions of lines of Scala and TypeScript.
+Migrating to Bazel has tremendously sped up its builds, reduced external
+dependencies on the build environment, and simplified developers' experience
+with the build system. Bazel has improved developer productivity at Lucid and
+unlocked further growth.
+
+### [Lyft](https://www.lyft.com/){: .external}
+
+Lyft is using Bazel for their iOS ([source](https://twitter.com/SmileyKeith/status/1116486751806033920)) and Android Apps.
+
+### [Meetup](http://www.meetup.com/){: .external}
+
+Meetup is an online social networking portal that facilitates offline group
+meetings.
+The Meetup engineering team contributes to
+[rules_scala](https://github.com/bazelbuild/rules_scala){: .external} and is the
+maintainer of [rules_avro](https://github.com/meetup/rules_avro){: .external}
+and [rules_openapi](https://github.com/meetup/rules_openapi){: .external}.
+
+### [Nvidia](https://www.nvidia.com/){: .external}
+
+> At Nvidia we have been using dazel(docker bazel) for python to work around
+some of bazel's python short comings. Everything else runs in normal bazel
+(Mostly Go / Scala/ C++/ Cuda)
+([source](https://twitter.com/rwhitcomb/status/1080887723433447424){: .external})
+
+### [Peloton Technology](http://www.peloton-tech.com){: .external}
+
+Peloton Technology is an automated vehicle technology company that tackles truck
+accidents and fuel use. They use Bazel to _enable reliable builds for automotive
+safety systems_.
+
+### [Pigweed](https://pigweed.dev){: .external}
+
+
+
+Pigweed is an open-source solution for sustained, robust, and rapid embedded
+product development for large teams. Pigweed has shipped in millions of
+devices, including Google's suite of Pixel devices, Nest thermostats,
+[satellites](https://www.spinlaunch.com/), and [autonomous aerial
+drones](https://www.flyzipline.com/).
+
+Pigweed [uses Bazel as its primary build
+system](https://pigweed.dev/seed/0111-build-systems.html). The [Bazel for
+Embedded][pw-bazel-great] blog post discusses why we think it's a great build
+system for embedded projects!
+
+[pw-bazel-great]: https://blog.bazel.build/2024/08/08/bazel-for-embedded.html#why-bazel-for-embedded
+
+### [Pinterest](https://www.pinterest.com/){: .external}
+
+
+
+Pinterest is the world’s catalog of ideas. They use Bazel to build various
+backend services (Java/C++) and the iOS application (Objective-C/C++).
+
+> We identified Bazel was the best fit for our goals to build a foundation for
+an order of magnitude improvement in performance, eliminate variability in
+build environments and adopt incrementally. As a result, we’re now shipping all
+our iOS releases using Bazel.
+[Developing fast & reliable iOS builds at Pinterest](https://medium.com/@Pinterest_Engineering/developing-fast-reliable-ios-builds-at-pinterest-part-one-cb1810407b92)
+
+### [PubRef](https://github.com/pubref){: .external}
+
+PubRef is an emerging scientific publishing platform.  They use Bazel with
+[rules_closure](https://github.com/bazelbuild/rules_closure){: .external} to build the
+frontend, native java rules to build the main backend,
+[rules_go](https://github.com/bazelbuild/rules_go){: .external},
+[rules_node](https://github.com/pubref/rules_node){: .external}, and
+[rules_kotlin](https://github.com/pubref/rules_kotlin){: .external} to build assorted
+backend services.  [rules_protobuf](https://github.com/pubref/rules_protobuf){: .external} is
+used to assist with gRPC-based communication between backend services.
+PubRef.org is based in Boulder, CO.
+
+### [Redfin](https://redfin.com/){: .external}
+Redfin is a next-generation real estate brokerage with full-service local
+agents. They use Bazel to build and deploy the website and various backend
+services.
+
+> With the conversion mostly behind us, things are greatly improved! Our CI
+builds are faster (*way* faster: they used to take 40–90 minutes, and now dev
+builds average 5–6 minutes). Reliability is far higher, too. This is harder to
+quantify, but the shift from unexplained build failures being something that
+“just happens” to being viewed as real problems to be solved has put us on a
+virtuous cycle of ever-increasing reliability.
+([We Switched from Maven to Bazel and Builds Got 10x Faster](https://redfin.engineering/we-switched-from-maven-to-bazel-and-builds-got-10x-faster-b265a7845854))
+
+### [Ritual](https://ritual.co){: .external}
+
+
+Ritual is a mobile pick up app, connecting restaurants with customers to offer
+a simple, time-saving tool to get the food and beverages they want, without the
+wait. Ritual uses Bazel for their backend services.
+
+### [Snap](https://www.snap.com/en-US/){: .external}
+
+Snap, the developer of Snapchat messaging app, has migrated from Buck to Bazel
+in 2020 ([source](https://twitter.com/wew/status/1326957862816509953){: .external}). For more
+details about their process, see their [engineering blog](https://eng.snap.com/blog/){: .external}.
+
+### [Stripe](https://stripe.com){: .external}
+
+
+Stripe provides mobile payment solutions. They use Bazel in their build and test pipelines, as detailed in their [engineering blog](https://stripe.com/blog/fast-secure-builds-choose-two){: .external}.
+
+### [Tinder](https://tinder.com){: .external}
+
+
+Tinder migrated its iOS app from CocoaPods to Bazel
+in 2021 ([source](https://medium.com/tinder/bazel-hermetic-toolchain-and-tooling-migration-c244dc0d3ae){: .external}).
+
+### [Tink](https://tink.com/){: .external}
+
+
+Tink is a european fintech, building the best way to connect to banks across
+Europe.
+
+They are using Bazel to build their backend services from a polyglot monorepo.
+Engineers at Tink are organizing the [bazel build //stockholm/...](https://www.meetup.com/BazelSTHLM/)
+meetup group.
+
+### [Tokopedia](https://www.tokopedia.com/){: .external}
+
+Tokopedia is an Indonesian technology company specializing in e-commerce, with
+over 90 million monthly active users and over 7 million merchants on the
+platform.
+
+They wrote the article
+[How Tokopedia Achieved 1000% Faster iOS Build Time](https://medium.com/tokopedia-engineering/how-tokopedia-achieved-1000-faster-ios-build-time-7664b2d8ae5),
+where they explain how Bazel sped up their builds. The build duration went from
+55 minutes to 10 minutes by using Bazel, and down to 5 minutes with remote
+caching.
+
+### [Trunk.io](https://trunk.io/merge/trunk-merge-and-bazel){: .external}
+
+
+Trunk is a San Francisco-based company backed by Andreessen Horowitz and Initialized Capital. Trunk offers a powerful pull request merge service with first-class support for the Bazel build system. By leveraging Bazel's understanding of dependencies within a codebase, Trunk's merge service intelligently creates parallel merge lanes, allowing independent changes to be tested and merged simultaneously.
+
+> Trunk’s internal monorepo builds modern C++ 20 and typescript all while leveraging bazel graph knowledge to selectively test and merge code.
+
+### [Twitter](https://twitter.com/){: .external}
+
+Twitter has made the decision to migrate from Pants to Bazel as their primary
+build tool
+([source](https://groups.google.com/forum/#!msg/pants-devel/PHVIbVDLhx8/LpSKIP5cAwAJ)).
+
+### [Two Sigma](https://www.twosigma.com/){: .external}
+
+
+Two Sigma is a New York-headquartered technology company dedicated to finding
+value in the world’s data.
+
+### [TypeDB](https://typedb.com){: .external}
+TypeDB Logo
+
+TypeDB is a database technology that can be used to intuitively model
+interconnected data. Through its type-theoretic and polymorphic query language,
+TypeQL, the data can be accessed with simple, human-readable queries that run at
+lightspeed.
+
+Bazel enables the TypeDB team to build a highly-orchestrated CI and distribution
+pipeline that manages many repositories in a wide variety of languages, and
+deploys to numerous platforms seamlessly. The TypeDB team has also released
+Bazel rules for assembling and deploying software distributions.
+
+### [Uber](https://www.uber.com){: .external}
+
+Uber is a ride-hailing company. With 900 active developers, Uber’s Go monorepo
+is likely one of the largest Go repositories using Bazel. See the article
+[Building Uber’s Go Monorepo with Bazel](https://eng.uber.com/go-monorepo-bazel/)
+to learn more about their experience.
+
+### [Uber Advanced Technologies Group](https://www.uber.com/info/atg/){: .external}
+
+
+Uber Advanced Technologies Group is focused on autonomous vehicle efforts at
+Uber, including trucking/freight and autonomous ride sharing. The organization
+uses Bazel as its primary build system.
+
+### [Vistar Media](http://vistarmedia.com){: .external}
+Vistar Media is an advertising platform that enables brands to reach consumers
+based on their behavior in the physical world. Their engineering team is
+primarily based out of Philadelphia and is using Bazel for builds, deploys, to
+speed up testing, and to consolidate repositories written with a variety of
+different technologies.
+
+### [VMware](https://www.vmware.com/){: .external}
+VMware uses Bazel to produce deterministic, reliable builds while developing
+innovative products for their customers.
+
+### [Wix](https://www.wix.com/){: .external}
+
+Wix is a cloud-based web development platform. Their backend uses Java and Scala
+code. They use remote execution with Google Cloud Build.
+
+> We have seen about 5 times faster clean builds when running with bazel remote
+execution which utilizes bazel’s great build/test parallelism capabilities when
+it dispatches build/test actions to a worker farm. Average build times are more
+than 10 times faster due to the utilization of bazel’s aggressive caching
+mechanism.
+([Migrating to Bazel from Maven or Gradle? 5 crucial questions you should ask yourself](https://medium.com/wix-engineering/migrating-to-bazel-from-maven-or-gradle-5-crucial-questions-you-should-ask-yourself-f23ac6bca070){: .external})
+
+### [Zenly](https://zen.ly/){: .external}
+
+Zenly is a live map of your friends and family. It’s the most fun way to meet up
+— or just see what’s up! — so you can feel together, even when you're apart.
+
+***
+
+## Open source projects using Bazel {:#open-source-projects-using-Bazel}
+
+### [Abseil](https://abseil.io/){: .external}
+
+Abseil is an open-source collection of C++ code (compliant to C++11) designed
+to augment the C++ standard library.
+
+### [Angular](https://angular.io){: .external}
+
+
+
+Angular is a popular web framework.
+Angular is [built with Bazel](https://github.com/angular/angular/blob/master/docs/BAZEL.md).
+
+### [Apollo](https://github.com/ApolloAuto/apollo)
+
+Apollo is a high performance, flexible architecture which accelerates the
+development, testing, and deployment of Autonomous Vehicles.
+
+### [brpc](https://github.com/brpc/brpc){: .external}
+
+An industrial-grade RPC framework used throughout Baidu, with 1,000,000+
+instances(not counting clients) and thousands kinds of services, called
+"baidu-rpc" inside Baidu.
+
+### [cert-manager](https://github.com/jetstack/cert-manager){: .external}
+
+cert-manager is a Kubernetes add-on to automate the management and issuance of
+TLS certificates from various issuing sources. It will ensure certificates are
+valid and up to date periodically, and attempt to renew certificates at an
+appropriate time before expiry.
+
+### [CallBuilder](https://github.com/google/CallBuilder){: .external}
+
+A Java code generator that allows you to create a builder by writing one
+function.
+
+### [CPPItertools](https://github.com/ryanhaining/cppitertools){: .external}
+
+C++ library providing range-based for loop add-ons inspired by the Python
+builtins and itertools library. Like itertools and the Python3 builtins, this
+library uses lazy evaluation wherever possible.
+
+### [Copybara](https://github.com/google/copybara){: .external}
+
+Copybara is a tool for transforming and moving code between repositories.
+
+### [Dagger](https://google.github.io/dagger/){: .external}
+
+Dagger is a fully static, compile-time dependency injection framework for both
+Java and Android.
+
+### [DAML](https://github.com/digital-asset/daml){: .external}
+
+DAML is a smart contract language for building future-proof distributed
+applications on a safe, privacy-aware runtime.
+
+### [DeepMind Lab](https://github.com/deepmind/lab){: .external}
+
+A customisable 3D platform for agent-based AI research.
+
+### [Drake](https://github.com/RobotLocomotion/drake){: .external}
+
+Drake is a C++ toolbox started at MIT and now led by the Toyota Research
+Institute. It is a collection of tools for analyzing the dynamics of our robots
+and building control systems for them, with a heavy emphasis on
+optimization-based design/analysis.
+
+### [Envoy](https://github.com/lyft/envoy){: .external}
+
+C++ L7 proxy and communication bus
+
+### [Error Prone](https://github.com/google/error-prone){: .external}
+
+Catches common Java mistakes as compile-time errors. (Migration to Bazel is in
+progress.)
+
+### [Extensible Service Proxy](https://github.com/cloudendpoints/esp){: .external}
+
+Extensible Service Proxy, a.k.a. ESP is a proxy which enables API management
+capabilities for JSON/REST or gRPC API services. The current implementation is
+based on an NGINX HTTP reverse proxy server.
+
+### [FFruit](https://gitlab.com/perezd/ffruit/){: .external}
+
+FFruit is a free & open source Android application to the popular service
+[Falling Fruit](https://fallingfruit.org){: .external}.
+
+### [Gerrit Code Review](https://gerritcodereview.com){: .external}
+
+Gerrit is a code review and project management tool for Git based projects.
+
+### [Gitiles](https://gerrit.googlesource.com/gitiles/){: .external}
+
+Gitiles is a simple repository browser for Git repositories, built on JGit.
+
+### [Grakn](https://github.com/graknlabs/grakn){: .external}
+
+Grakn (https://grakn.ai/) is the knowledge graph engine to organise complex
+networks of data and make it queryable.
+
+### [GRPC](http://www.grpc.io){: .external}
+A language-and-platform-neutral remote procedure call system.
+(Bazel is a supported, although not primary, build system.)
+
+### [gVisor](https://github.com/google/gvisor){: .external}
+gVisor is a container runtime sandbox.
+
+### [Guetzli](https://github.com/google/guetzli/){: .external}
+
+Guetzli is a JPEG encoder that aims for excellent compression density at high
+visual quality.
+
+### [Gulava](http://www.github.com/google/gulava/){: .external}
+
+A Java code generator that lets you write Prolog-style predicates and use them
+seamlessly from normal Java code.
+
+### [Heron](https://github.com/apache/incubator-heron){: .external}
+
+Heron is a realtime, distributed, fault-tolerant stream processing engine from
+Twitter.
+
+### [Internet Computer Protocol](https://internetcomputer.org/){: .external}
+
+
+
+The Internet Computer Protocol is a publicly available blockchain network that
+enables replicated execution of general-purpose computation, serving hundreds
+of thousands of applications and their users.
+
+### [Jazzer](https://github.com/CodeIntelligenceTesting/jazzer){: .external}
+
+
+
+Jazzer is a fuzzer for Java and other JVM-based languages that integrates with JUnit 5.
+
+### [JGit](https://eclipse.org/jgit/){: .external}
+
+JGit is a lightweight, pure Java library implementing the Git version control
+system.
+
+### [Jsonnet](https://jsonnet.org/){: .external}
+
+An elegant, formally-specified config generation language for JSON.
+(Bazel is a supported build system.)
+
+### [Kubernetes](https://github.com/kubernetes/kubernetes){: .external}
+
+
+Kubernetes is an open source system for managing containerized applications
+across multiple hosts, providing basic mechanisms for deployment, maintenance,
+and scaling of applications.
+
+### [Kythe](https://github.com/google/kythe){: .external}
+
+An ecosystem for building tools that work with code.
+
+### [ls-lint](https://github.com/loeffel-io/ls-lint){: .external}
+
+
+
+An extremely fast directory and filename linter - Bring some structure to your
+project file system.
+
+### [Nomulus](https://github.com/google/nomulus){: .external}
+
+Top-level domain name registry service on Google App Engine.
+
+### [ONOS : Open Network Operating System](https://github.com/opennetworkinglab/onos){: .external}
+
+
+ONOS is the only SDN controller platform that supports the transition from
+legacy “brown field” networks to SDN “green field” networks. This enables
+exciting new capabilities, and disruptive deployment and operational cost points
+for network operators.
+
+### [PetitParser for Java](https://github.com/petitparser/java-petitparser){: .external}
+
+Grammars for programming languages are traditionally specified statically.
+They are hard to compose and reuse due to ambiguities that inevitably arise.
+PetitParser combines ideas from scannnerless parsing, parser combinators,
+parsing expression grammars and packrat parsers to model grammars and parsers
+as objects that can be reconfigured dynamically.
+
+### [PlaidML](https://github.com/plaidml/plaidml){: .external}
+
+PlaidML is a framework for making deep learning work everywhere.
+
+### [Project V](https://www.v2ray.com/){: .external}
+
+
+Project V is a set of tools to help you build your own privacy network over
+internet.
+
+### [Prysmatic Labs Ethereum 2.0 Implementation](https://github.com/prysmaticlabs/prysm){: .external}
+
+Prysm is a sharding client for Ethereum 2.0, a blockchain-based distributed
+computing platform.
+
+### [Ray](https://github.com/ray-project/ray){: .external}
+
+Ray is a flexible, high-performance distributed execution framework.
+
+### [Resty](https://github.com/go-resty/resty){: .external}
+
+Resty is a Simple HTTP and REST client library for Go (inspired by Ruby
+rest-client).
+
+### [Roughtime](https://roughtime.googlesource.com/roughtime){: .external}
+
+Roughtime is a project that aims to provide secure time synchronisation.
+
+### [Selenium](https://github.com/SeleniumHQ/selenium){: .external}
+
+Selenium is a portable framework for testing web applications.
+
+### [Semantic](https://github.com/github/semantic){: .external}
+
+Semantic is a Haskell library and command line tool for parsing, analyzing, and
+comparing source code. It is developed by GitHub (and used for example for the
+code navigation).
+
+### [Served](https://github.com/meltwater/served){: .external}
+
+Served is a C++ library for building high performance RESTful web servers.
+
+### [Sonnet](https://github.com/deepmind/sonnet){: .external}
+
+Sonnet is a library built on top of TensorFlow for building complex neural
+networks.
+
+### [Sorbet](https://github.com/sorbet/sorbet){: .external}
+
+Sorbet is a fast, powerful type checker for a subset of Ruby. It scales to
+codebases with millions of lines of code and can be adopted incrementally.
+
+### [Spotify](https://spotify.com){: .external}
+
+Spotify is using Bazel to build their iOS and Android Apps ([source](https://twitter.com/BalestraPatrick/status/1573355078995566594)).
+
+### [Tink](https://github.com/google/tink){: .external}
+
+Tink is a multi-language, cross-platform, open source library that provides
+cryptographic APIs that are secure, easy to use correctly, and hard(er) to
+misuse.
+
+### [TensorFlow](http://tensorflow.org){: .external}
+
+
+An open source software library for machine intelligence.
+
+### [Turbo Santa](https://github.com/turbo-santa/turbo-santa-common){: .external}
+
+A platform-independent GameBoy emulator.
+
+### [Wycheproof](https://github.com/google/wycheproof){: .external}
+
+Project Wycheproof tests crypto libraries against known attacks.
+
+### [XIOSim](https://github.com/s-kanev/XIOSim){: .external}
+
+XIOSim is a detailed user-mode microarchitectural simulator for the x86
+architecture.
+
+### [ZhihuDailyPurify](https://github.com/izzyleung/ZhihuDailyPurify){: .external}
+
+ZhihuDailyPurify is a light weight version of Zhihu Daily, a Chinese
+question-and-answer webs.
\ No newline at end of file
diff --git a/versions/9.1.0/concepts/build-files.mdx b/versions/9.1.0/concepts/build-files.mdx
new file mode 100644
index 00000000..882107b2
--- /dev/null
+++ b/versions/9.1.0/concepts/build-files.mdx
@@ -0,0 +1,150 @@
+---
+title: 'BUILD files'
+---
+
+The previous sections described packages, targets and labels, and the
+build dependency graph abstractly. This section describes the concrete syntax
+used to define a package.
+
+By definition, every package contains a `BUILD` file, which is a short
+program.
+
+Note: The `BUILD` file can be named either `BUILD` or `BUILD.bazel`. If both
+files exist, `BUILD.bazel` takes precedence over `BUILD`.
+For simplicity's sake, the documentation refers to these files simply as `BUILD`
+files.
+
+`BUILD` files are evaluated using an imperative language,
+[Starlark](https://github.com/bazelbuild/starlark/){: .external}.
+
+They are interpreted as a sequential list of statements.
+
+In general, order does matter: variables must be defined before they are
+used, for example. However, most `BUILD` files consist only of declarations of
+build rules, and the relative order of these statements is immaterial; all
+that matters is _which_ rules were declared, and with what values, by the
+time package evaluation completes.
+
+When a build rule function, such as `cc_library`, is executed, it creates a
+new target in the graph. This target can later be referred using a label.
+
+In simple `BUILD` files, rule declarations can be re-ordered freely without
+changing the behavior.
+
+To encourage a clean separation between code and data, `BUILD` files cannot
+contain function definitions, `for` statements or `if` statements (but list
+comprehensions and `if` expressions are allowed). Functions can be declared in
+`.bzl` files instead. Additionally, `*args` and `**kwargs` arguments are not
+allowed in `BUILD` files; instead list all the arguments explicitly.
+
+Crucially, programs in Starlark can't perform arbitrary I/O. This invariant
+makes the interpretation of `BUILD` files hermetic — dependent only on a known
+set of inputs, which is essential for ensuring that builds are reproducible.
+For more details, see [Hermeticity](/versions/9.1.0/basics/hermeticity).
+
+Because `BUILD` files need to be updated whenever the dependencies of the
+underlying code change, they are typically maintained by multiple people on a
+team. `BUILD` file authors should comment liberally to document the role
+of each build target, whether or not it is intended for public use, and to
+document the role of the package itself.
+
+## Loading an extension {:#load}
+
+Bazel extensions are files ending in `.bzl`. Use the `load` statement to import
+a symbol from an extension.
+
+```
+load("//foo/bar:file.bzl", "some_library")
+```
+
+This code loads the file `foo/bar/file.bzl` and adds the `some_library` symbol
+to the environment. This can be used to load new rules, functions, or constants
+(for example, a string or a list). Multiple symbols can be imported by using
+additional arguments to the call to `load`. Arguments must be string literals
+(no variable) and `load` statements must appear at top-level — they cannot be
+in a function body.
+
+The first argument of `load` is a [label](/versions/9.1.0/concepts/labels) identifying a
+`.bzl` file. If it's a relative label, it is resolved with respect to the
+package (not directory) containing the current `bzl` file. Relative labels in
+`load` statements should use a leading `:`.
+
+`load` also supports aliases, therefore, you can assign different names to the
+imported symbols.
+
+```
+load("//foo/bar:file.bzl", library_alias = "some_library")
+```
+
+You can define multiple aliases within one `load` statement. Moreover, the
+argument list can contain both aliases and regular symbol names. The following
+example is perfectly legal (please note when to use quotation marks).
+
+```
+load(":my_rules.bzl", "some_rule", nice_alias = "some_other_rule")
+```
+
+In a `.bzl` file, symbols starting with `_` are not exported and cannot be
+loaded from another file.
+
+You can use [load visibility](/versions/9.1.0/concepts/visibility#load-visibility) to restrict
+who may load a `.bzl` file.
+
+## Types of build rules {:#types-of-build-rules}
+
+The majority of build rules come in families, grouped together by
+language. For example, `cc_binary`, `cc_library`
+and `cc_test` are the build rules for C++ binaries,
+libraries, and tests, respectively. Other languages use the same
+naming scheme, with a different prefix, such as `java_*` for
+Java. Some of these functions are documented in the
+[Build Encyclopedia](/versions/9.1.0/reference/be/overview), but it is possible
+for anyone to create new rules.
+
+* `*_binary` rules build executable programs in a given language. After a
+  build, the executable will reside in the build tool's binary
+  output tree at the corresponding name for the rule's label,
+  so `//my:program` would appear at (for example) `$(BINDIR)/my/program`.
+
+  In some languages, such rules also create a runfiles directory
+  containing all the files mentioned in a `data`
+  attribute belonging to the rule, or any rule in its transitive
+  closure of dependencies; this set of files is gathered together in
+  one place for ease of deployment to production.
+
+* `*_test` rules are a specialization of a `*_binary` rule, used for automated
+  testing. Tests are simply programs that return zero on success.
+
+  Like binaries, tests also have runfiles trees, and the files
+  beneath it are the only files that a test may legitimately open
+  at runtime. For example, a program `cc_test(name='x',
+  data=['//foo:bar'])` may open and read `$TEST_SRCDIR/workspace/foo/bar` during execution.
+  (Each programming language has its own utility function for
+  accessing the value of `$TEST_SRCDIR`, but they are all
+  equivalent to using the environment variable directly.)
+  Failure to observe the rule will cause the test to fail when it is
+  executed on a remote testing host.
+
+* `*_library` rules specify separately-compiled modules in the given
+    programming language. Libraries can depend on other libraries,
+    and binaries and tests can depend on libraries, with the expected
+    separate-compilation behavior.
+
+

   

+  
+    
+    
+  
+

+        Labels
+    
+        Dependencies
+    

+
+## File encoding
+
+`BUILD` and `.bzl` files should be encoded in UTF-8, of which ASCII is a valid
+subset. Arbitrary byte sequences are currently allowed, but may stop being
+supported in the future.
diff --git a/versions/9.1.0/concepts/build-ref.mdx b/versions/9.1.0/concepts/build-ref.mdx
new file mode 100644
index 00000000..7418a0db
--- /dev/null
+++ b/versions/9.1.0/concepts/build-ref.mdx
@@ -0,0 +1,103 @@
+---
+title: 'Repositories, workspaces, packages, and targets'
+---
+
+Bazel builds software from source code organized in directory trees called
+repositories. A defined set of repositories comprises the workspace. Source
+files in repositories are organized in a nested hierarchy of packages, where
+each package is a directory that contains a set of related source files and one
+`BUILD` file. The `BUILD` file specifies what software outputs can be built from
+the source.
+
+### Repositories {#repositories}
+
+Source files used in a Bazel build are organized in _repositories_ (often
+shortened to _repos_). A repo is a directory tree with a boundary marker file at
+its root; such a boundary marker file could be `MODULE.bazel`, `REPO.bazel`, or
+in legacy contexts, `WORKSPACE` or `WORKSPACE.bazel`.
+
+The repo in which the current Bazel command is being run is called the _main
+repo_. Other, (external) repos are defined by _repo rules_; see [external
+dependencies overview](/versions/9.1.0/external/overview) for more information.
+
+## Workspace {#workspace}
+
+A _workspace_ is the environment shared by all Bazel commands run from the same
+main repo. It encompasses the main repo and the set of all defined external
+repos.
+
+Note that historically the concepts of "repository" and "workspace" have been
+conflated; the term "workspace" has often been used to refer to the main
+repository, and sometimes even used as a synonym of "repository".
+
+## Packages {#packages}
+
+The primary unit of code organization in a repository is the _package_. A
+package is a collection of related files and a specification of how they can be
+used to produce output artifacts.
+
+A package is defined as a directory containing a
+[`BUILD` file](/versions/9.1.0/concepts/build-files) named either `BUILD` or `BUILD.bazel`. A
+package includes all files in its directory, plus all subdirectories beneath it,
+except those which themselves contain a `BUILD` file. From this definition, no
+file or directory may be a part of two different packages.
+
+For example, in the following directory tree there are two packages, `my/app`,
+and the subpackage `my/app/tests`. Note that `my/app/data` is not a package, but
+a directory belonging to package `my/app`.
+
+```
+src/my/app/BUILD
+src/my/app/app.cc
+src/my/app/data/input.txt
+src/my/app/tests/BUILD
+src/my/app/tests/test.cc
+```
+
+## Targets {#targets}
+
+A package is a container of _targets_, which are defined in the package's
+`BUILD` file. Most targets are one of two principal kinds, _files_ and _rules_.
+
+Files are further divided into two kinds. _Source files_ are usually written by
+the efforts of people, and checked in to the repository. _Generated files_,
+sometimes called derived files or output files, are not checked in, but are
+generated from source files.
+
+The second kind of target is declared with a _rule_. Each rule instance
+specifies the relationship between a set of input and a set of output files. The
+inputs to a rule may be source files, but they also may be the outputs of other
+rules.
+
+Whether the input to a rule is a source file or a generated file is in most
+cases immaterial; what matters is only the contents of that file. This fact
+makes it easy to replace a complex source file with a generated file produced by
+a rule, such as happens when the burden of manually maintaining a highly
+structured file becomes too tiresome, and someone writes a program to derive it.
+No change is required to the consumers of that file. Conversely, a generated
+file may easily be replaced by a source file with only local changes.
+
+The inputs to a rule may also include _other rules_. The precise meaning of such
+relationships is often quite complex and language- or rule-dependent, but
+intuitively it is simple: a C++ library rule A might have another C++ library
+rule B for an input. The effect of this dependency is that B's header files are
+available to A during compilation, B's symbols are available to A during
+linking, and B's runtime data is available to A during execution.
+
+An invariant of all rules is that the files generated by a rule always belong to
+the same package as the rule itself; it is not possible to generate files into
+another package. It is not uncommon for a rule's inputs to come from another
+package, though.
+
+Package groups are sets of packages whose purpose is to limit accessibility of
+certain rules. Package groups are defined by the `package_group` function. They
+have three properties: the list of packages they contain, their name, and other
+package groups they include. The only allowed ways to refer to them are from the
+`visibility` attribute of rules or from the `default_visibility` attribute of
+the `package` function; they do not generate or consume files. For more
+information, refer to the [`package_group`
+documentation](/versions/9.1.0/reference/be/functions#package_group).
+
+
+  Labels
+
\ No newline at end of file
diff --git a/versions/9.1.0/concepts/dependencies.mdx b/versions/9.1.0/concepts/dependencies.mdx
new file mode 100644
index 00000000..4cbd73ba
--- /dev/null
+++ b/versions/9.1.0/concepts/dependencies.mdx
@@ -0,0 +1,373 @@
+---
+title: 'Dependencies'
+---
+
+A target `A` _depends upon_ a target `B` if `B` is needed by `A` at build or
+execution time. The _depends upon_ relation induces a
+[Directed Acyclic Graph](https://en.wikipedia.org/wiki/Directed_acyclic_graph){: .external}
+(DAG) over targets, and it is called a _dependency graph_.
+
+A target's _direct_ dependencies are those other targets reachable by a path
+of length 1 in the dependency graph. A target's _transitive_ dependencies are
+those targets upon which it depends via a path of any length through the graph.
+
+In fact, in the context of builds, there are two dependency graphs, the graph
+of _actual dependencies_ and the graph of _declared dependencies_. Most of the
+time, the two graphs are so similar that this distinction need not be made, but
+it is useful for the discussion below.
+
+## Actual and declared dependencies {:#actual-and-declared-dependencies}
+
+A target `X` is _actually dependent_ on target `Y` if `Y` must be present,
+built, and up-to-date in order for `X` to be built correctly. _Built_ could
+mean generated, processed, compiled, linked, archived, compressed, executed, or
+any of the other kinds of tasks that routinely occur during a build.
+
+A target `X` has a _declared dependency_ on target `Y` if there is a dependency
+edge from `X` to `Y` in the package of `X`.
+
+For correct builds, the graph of actual dependencies _A_ must be a subgraph of
+the graph of declared dependencies _D_. That is, every pair of
+directly-connected nodes `x --> y` in _A_ must also be directly connected in
+_D_. It can be said that _D_ is an _overapproximation_ of _A_.
+
+Important: _D_ should not be too much of an overapproximation of _A_ because
+redundant declared dependencies can make builds slower and binaries larger.
+
+`BUILD` file writers must explicitly declare all of the actual direct
+dependencies for every rule to the build system, and no more.
+
+Failure to observe this principle causes undefined behavior: the build may fail,
+but worse, the build may depend on some prior operations, or upon transitive
+declared dependencies the target happens to have. Bazel checks for missing
+dependencies and report errors, but it's not possible for this checking to be
+complete in all cases.
+
+You need not (and should not) attempt to list everything indirectly imported,
+even if it is _needed_ by `A` at execution time.
+
+During a build of target `X`, the build tool inspects the entire transitive
+closure of dependencies of `X` to ensure that any changes in those targets are
+reflected in the final result, rebuilding intermediates as needed.
+
+The transitive nature of dependencies leads to a common mistake. Sometimes,
+code in one file may use code provided by an _indirect_ dependency — a
+transitive but not direct edge in the declared dependency graph. Indirect
+dependencies don't appear in the `BUILD` file. Because the rule doesn't
+directly depend on the provider, there is no way to track changes, as shown in
+the following example timeline:
+
+### 1. Declared dependencies match actual dependencies {:#this-is-fine}
+
+At first, everything works. The code in package `a` uses code in package `b`.
+The code in package `b` uses code in package `c`, and thus `a` transitively
+depends on `c`.
+
+
+  
+    
+    
+  
+  
+    
+    
+  
+  
+    
+    
+  
+  
+    
+    
+  
+  
+    
+    
+  
+
a/BUILDb/BUILD

+      
rule(
+    name = "a",
+    srcs = "a.in",
+    deps = "//b:b",
+)
+      

+    		
+      
+rule(
+    name = "b",
+    srcs = "b.in",
+    deps = "//c:c",
+)
+      

+    
a / a.inb / b.in
+import b;
+b.foo();
+    

+    		
+      
+import c;
+function foo() {
+  c.bar();
+}
+      

+    

+      

+        Declared dependency graph with arrows connecting a, b, and c
+        
Declared dependency graph

+      

+    		
+      

+        Actual dependency graph that matches the declared dependency
+                  graph with arrows connecting a, b, and c
+        
Actual dependency graph

+      

+    

+
+The declared dependencies overapproximate the actual dependencies. All is well.
+
+### 2. Adding an undeclared dependency {:#undeclared-dependency}
+
+A latent hazard is introduced when someone adds code to `a` that creates a
+direct _actual_ dependency on `c`, but forgets to declare it in the build file
+`a/BUILD`.
+
+
+  
+    
+    
+  
+  
+    
+    
+  
+  
+    
+    
+  
+
a / a.in 

+      
+        import b;
+        import c;
+        b.foo();
+        c.garply();
+      

+    		 

+      

+        Declared dependency graph with arrows connecting a, b, and c
+        
Declared dependency graph

+      

+    		
+      

+        Actual dependency graph with arrows connecting a, b, and c. An
+                  arrow now connects A to C as well. This does not match the
+                  declared dependency graph
+        
Actual dependency graph

+      

+    

+
+The declared dependencies no longer overapproximate the actual dependencies.
+This may build ok, because the transitive closures of the two graphs are equal,
+but masks a problem: `a` has an actual but undeclared dependency on `c`.
+
+### 3. Divergence between declared and actual dependency graphs {:#divergence}
+
+The hazard is revealed when someone refactors `b` so that it no longer depends on
+`c`, inadvertently breaking `a` through no
+fault of their own.
+
+
+  
+    
+    
+  
+  
+    
+    
+  
+  
+    
+    
+  
+  
+    
+    
+  
+  
+    
+    
+  
+
 b/BUILD
 
+      
rule(
+    name = "b",
+    srcs = "b.in",
+    deps = "//d:d",
+)
+      

+    
 b / b.in
 
+      
+      import d;
+      function foo() {
+        d.baz();
+      }
+      

+    

+      

+        Declared dependency graph with arrows connecting a and b.
+                  b no longer connects to c, which breaks a's connection to c
+        
Declared dependency graph

+      

+    		
+      

+        Actual dependency graph that shows a connecting to b and c,
+                  but b no longer connects to c
+        
Actual dependency graph

+      

+    

+
+The declared dependency graph is now an underapproximation of the actual
+dependencies, even when transitively closed; the build is likely to fail.
+
+The problem could have been averted by ensuring that the actual dependency from
+`a` to `c` introduced in Step 2 was properly declared in the `BUILD` file.
+
+## Types of dependencies {:#types-of-dependencies}
+
+Most build rules have three attributes for specifying different kinds of
+generic dependencies: `srcs`, `deps` and `data`. These are explained below. For
+more details, see
+[Attributes common to all rules](/versions/9.1.0/reference/be/common-definitions).
+
+Many rules also have additional attributes for rule-specific kinds of
+dependencies, for example, `compiler` or `resources`. These are detailed in the
+[Build Encyclopedia](/versions/9.1.0/reference/be/).
+
+### `srcs` dependencies {:#srcs-dependencies}
+
+Files consumed directly by the rule or rules that output source files.
+
+### `deps` dependencies {:#deps-dependencies}
+
+Rule pointing to separately-compiled modules providing header files,
+symbols, libraries, data, etc.
+
+### `data` dependencies {:#data-dependencies}
+
+A build target might need some data files to run correctly. These data files
+aren't source code: they don't affect how the target is built. For example, a
+unit test might compare a function's output to the contents of a file. When you
+build the unit test you don't need the file, but you do need it when you run
+the test. The same applies to tools that are launched during execution.
+
+The build system runs tests in an isolated directory where only files listed as
+`data` are available. Thus, if a binary/library/test needs some files to run,
+specify them (or a build rule containing them) in `data`. For example:
+
+```
+# I need a config file from a directory named env:
+java_binary(
+    name = "setenv",
+    ...
+    data = [":env/default_env.txt"],
+)
+
+# I need test data from another directory
+sh_test(
+    name = "regtest",
+    srcs = ["regtest.sh"],
+    data = [
+        "//data:file1.txt",
+        "//data:file2.txt",
+        ...
+    ],
+)
+```
+
+These files are available using the relative path `path/to/data/file`. In tests,
+you can refer to these files by joining the paths of the test's source
+directory and the workspace-relative path, for example,
+`${TEST_SRCDIR}/workspace/path/to/data/file`.
+
+## Using labels to reference directories {:#using-labels-reference-directories}
+
+As you look over our `BUILD` files, you might notice that some `data` labels
+refer to directories. These labels end with `/.` or `/` like these examples,
+which you should not use:
+
+
Not recommended —
+  data = ["//data/regression:unittest/."]
+

+
+
Not recommended —
+  data = ["testdata/."]
+

+
+
Not recommended —
+  data = ["testdata/"]
+

+
+This seems convenient, particularly for tests because it allows a test to
+use all the data files in the directory.
+
+But try not to do this. In order to ensure correct incremental rebuilds (and
+re-execution of tests) after a change, the build system must be aware of the
+complete set of files that are inputs to the build (or test). When you specify
+a directory, the build system performs a rebuild only when the directory itself
+changes (due to addition or deletion of files), but won't be able to detect
+edits to individual files as those changes don't affect the enclosing directory.
+Rather than specifying directories as inputs to the build system, you should
+enumerate the set of files contained within them, either explicitly or using the
+[`glob()`](/versions/9.1.0/reference/be/functions#glob) function. (Use `**` to force the
+`glob()` to be recursive.)
+
+
Recommended —
+  data = glob(["testdata/**"])
+

+
+Unfortunately, there are some scenarios where directory labels must be used.
+For example, if the `testdata` directory contains files whose names don't
+conform to the [label syntax](/versions/9.1.0/concepts/labels#labels-lexical-specification),
+then explicit enumeration of files, or use of the
+[`glob()`](/versions/9.1.0/reference/be/functions#glob) function produces an invalid labels
+error. You must use directory labels in this case, but beware of the
+associated risk of incorrect rebuilds described above.
+
+If you must use directory labels, keep in mind that you can't refer to the
+parent package with a relative `../` path; instead, use an absolute path like
+`//data/regression:unittest/.`.
+
+Note: Directory labels are only valid for data dependencies. If you try to use
+a directory as a label in an argument other than `data`, it will fail and you
+will get a (probably cryptic) error message.
+
+Any external rule, such as a test, that needs to use multiple files must
+explicitly declare its dependence on all of them. You can use `filegroup()` to
+group files together in the `BUILD` file:
+
+```
+filegroup(
+        name = 'my_data',
+        srcs = glob(['my_unittest_data/*'])
+)
+```
+
+You can then reference the label `my_data` as the data dependency in your test.
+
+
+  
+    
+    
+  
+

+        BUILD files
+    
+        Visibility
+    

+
diff --git a/versions/9.1.0/concepts/labels.mdx b/versions/9.1.0/concepts/labels.mdx
new file mode 100644
index 00000000..f0a2ff28
--- /dev/null
+++ b/versions/9.1.0/concepts/labels.mdx
@@ -0,0 +1,254 @@
+---
+title: 'Labels'
+---
+
+A **label** is an identifier for a target. A typical label in its full canonical
+form looks like:
+
+```none
+@@myrepo//my/app/main:app_binary
+```
+
+The first part of the label is the repository name, `@@myrepo`. The double-`@`
+syntax signifies that this is a [*canonical* repo
+name](/versions/9.1.0/external/overview#canonical-repo-name), which is unique within
+the workspace. Labels with canonical repo names unambiguously identify a target
+no matter which context they appear in.
+
+Often the canonical repo name is an arcane string that looks like
+`@@rules_java++toolchains+local_jdk`. What is much more commonly seen is
+labels with an [*apparent* repo name](/versions/9.1.0/external/overview#apparent-repo-name),
+which looks like:
+
+```
+@myrepo//my/app/main:app_binary
+```
+
+The only difference is the repo name being prefixed with one `@` instead of two.
+This refers to a repo with the apparent name `myrepo`, which could be different
+based on the context this label appears in.
+
+In the typical case that a label refers to the same repository from which
+it is used, the repo name part may be omitted.  So, inside `@@myrepo` the first
+label is usually written as
+
+```
+//my/app/main:app_binary
+```
+
+The second part of the label is the un-qualified package name
+`my/app/main`, the path to the package
+relative to the repository root.  Together, the repository name and the
+un-qualified package name form the fully-qualified package name
+`@@myrepo//my/app/main`. When the label refers to the same
+package it is used in, the package name (and optionally, the colon)
+may be omitted.  So, inside `@@myrepo//my/app/main`,
+this label may be written either of the following ways:
+
+```
+app_binary
+:app_binary
+```
+
+It is a matter of convention that the colon is omitted for files,
+but retained for rules, but it is not otherwise significant.
+
+The part of the label after the colon, `app_binary` is the un-qualified target
+name. When it matches the last component of the package path, it, and the
+colon, may be omitted.  So, these two labels are equivalent:
+
+```
+//my/app/lib
+//my/app/lib:lib
+```
+
+The name of a file target in a subdirectory of the package is the file's path
+relative to the package root (the directory containing the `BUILD` file). So,
+this file is in the `my/app/main/testdata` subdirectory of the repository:
+
+```
+//my/app/main:testdata/input.txt
+```
+
+Strings like `//my/app` and `@@some_repo//my/app` have two meanings depending on
+the context in which they are used: when Bazel expects a label, they mean
+`//my/app:app` and `@@some_repo//my/app:app`, respectively. But, when Bazel
+expects a package (e.g. in `package_group` specifications), they reference the
+package that contains that label.
+
+A common mistake in `BUILD` files is using `//my/app` to refer to a package, or
+to *all* targets in a package--it does not.  Remember, it is
+equivalent to `//my/app:app`, so it names the `app` target in the `my/app`
+package of the current repository.
+
+However, the use of `//my/app` to refer to a package is encouraged in the
+specification of a `package_group` or in `.bzl` files, because it clearly
+communicates that the package name is absolute and rooted in the top-level
+directory of the workspace.
+
+Relative labels cannot be used to refer to targets in other packages; the
+repository identifier and package name must always be specified in this case.
+For example, if the source tree contains both the package `my/app` and the
+package `my/app/testdata` (each of these two directories has its own
+`BUILD` file), the latter package contains a file named `testdepot.zip`. Here
+are two ways (one wrong, one correct) to refer to this file within
+`//my/app:BUILD`:
+
+
Wrong — testdata is a different package, so you can't use a relative path

+
testdata/testdepot.zip

+
+
Correct — refer to testdata with its full path

+
+
//my/app/testdata:testdepot.zip

+
+
+Labels starting with `@@//` are references to the main
+repository, which will still work even from external repositories.
+Therefore `@@//a/b/c` is different from
+`//a/b/c` when referenced from an external repository.
+The former refers back to the main repository, while the latter
+looks for `//a/b/c` in the external repository itself.
+This is especially relevant when writing rules in the main
+repository that refer to targets in the main repository, and will be
+used from external repositories.
+
+For information about the different ways you can refer to targets, see
+[target patterns](/versions/9.1.0/run/build#specifying-build-targets).
+
+### Lexical specification of a label {:#labels-lexical-specification}
+
+Label syntax discourages use of metacharacters that have special meaning to the
+shell. This helps to avoid inadvertent quoting problems, and makes it easier to
+construct tools and scripts that manipulate labels, such as the
+[Bazel Query Language](/versions/9.1.0/query/language).
+
+The precise details of allowed target names are below.
+
+### Target names — `{{ "" }}package-name{{ "" }}:target-name` {:#target-names}
+
+`target-name` is the name of the target within the package. The name of a rule
+is the value of the `name` attribute in the rule's declaration in a `BUILD`
+file; the name of a file is its pathname relative to the directory containing
+the `BUILD` file.
+
+Target names must be composed entirely of characters drawn from the set `a`–`z`,
+`A`–`Z`, `0`–`9`, and the punctuation symbols `!%-@^_"#$&'()*-+,;<=>?[]{|}~/.`.
+
+Filenames must be relative pathnames in normal form, which means they must
+neither start nor end with a slash (for example, `/foo` and `foo/` are
+forbidden) nor contain multiple consecutive slashes as path separators
+(for example, `foo//bar`). Similarly, up-level references (`..`) and
+current-directory references (`./`) are forbidden.
+
+
Wrong — Do not use .. to refer to files in other packages

+
+
Correct — Use
+  //{{ "" }}package-name{{ "" }}:{{ "" }}filename{{ "" }}

+
+While it is common to use `/` in the name of a file target, avoid the use of
+`/` in the names of rules. Especially when the shorthand form of a label is
+used, it may confuse the reader. The label `//foo/bar/wiz` is always a shorthand
+for `//foo/bar/wiz:wiz`, even if there is no such package `foo/bar/wiz`; it
+never refers to `//foo:bar/wiz`, even if that target exists.
+
+However, there are some situations where use of a slash is convenient, or
+sometimes even necessary. For example, the name of certain rules must match
+their principal source file, which may reside in a subdirectory of the package.
+
+### Package names — `//package-name:{{ "" }}target-name{{ "" }}` {:#package-names}
+
+The name of a package is the name of the directory containing its `BUILD` file,
+relative to the top-level directory of the containing repository.
+For example: `my/app`.
+
+On a technical level, Bazel enforces the following:
+
+* Allowed characters in package names are the lowercase letters `a` through `z`,
+  the uppercase letters `A` through `Z`, the digits `0` through `9`, the
+  characters ``! \"#$%&'()*+,-.;<=>?@[]^_`{|}`` (yes, there's a space character
+  in there!), and of course forward slash `/` (since it's the directory
+  separator).
+* Package names may not start or end with a forward slash character `/`.
+* Package names may not contain the substring `//`. This wouldn't make
+  sense---what would the corresponding directory path be?
+* Package names may not contain the substring `/./` or `/../` or `/.../` etc.
+  This enforcement is done to avoid confusion when translating between a logical
+  package name and a physical directory name, given the semantic meaning of the
+  dot character in path strings.
+
+On a practical level:
+
+* For a language with a directory structure that is significant to its module
+  system (for example, Java), it's important to choose directory names that are
+  valid identifiers in the language. For example, don't start with a leading
+  digit and avoid special characters, especially underscores and hyphens.
+* Although Bazel supports targets in the workspace's root package (for example,
+  `//:foo`), it's best to leave that package empty so all meaningful packages
+  have descriptive names.
+
+## Rules {:#rules}
+
+A rule specifies the relationship between inputs and outputs, and the
+steps to build the outputs. Rules can be of one of many different
+kinds (sometimes called the _rule class_), which produce compiled
+executables and libraries, test executables and other supported
+outputs as described in the [Build Encyclopedia](/versions/9.1.0/reference/be/overview).
+
+`BUILD` files declare _targets_ by invoking _rules_.
+
+In the example below, we see the declaration of the target `my_app`
+using the `cc_binary` rule.
+
+```python
+cc_binary(
+    name = "my_app",
+    srcs = ["my_app.cc"],
+    deps = [
+        "//absl/base",
+        "//absl/strings",
+    ],
+)
+```
+
+Every rule invocation has a `name` attribute (which must be a valid
+[target name](#target-names)), that declares a target within the package
+of the `BUILD` file.
+
+Every rule has a set of _attributes_; the applicable attributes for a given
+rule, and the significance and semantics of each attribute are a function of
+the rule's kind; see the [Build Encyclopedia](/versions/9.1.0/reference/be/overview) for a
+list of rules and their corresponding attributes. Each attribute has a name and
+a type. Some of the common types an attribute can have are integer, label, list
+of labels, string, list of strings, output label, list of output labels. Not
+all attributes need to be specified in every rule. Attributes thus form a
+dictionary from keys (names) to optional, typed values.
+
+The `srcs` attribute present in many rules has type "list of labels"; its
+value, if present, is a list of labels, each being the name of a target that is
+an input to this rule.
+
+In some cases, the name of the rule kind is somewhat arbitrary, and more
+interesting are the names of the files generated by the rule, and this is true
+of genrules. For more information, see
+[General Rules: genrule](/versions/9.1.0/reference/be/general#genrule).
+
+In other cases, the name is significant: for `*_binary` and `*_test` rules,
+for example, the rule name determines the name of the executable produced by
+the build.
+
+This directed acyclic graph over targets is called the _target graph_ or
+_build dependency graph_, and is the domain over which the
+[Bazel Query tool](/versions/9.1.0/query/guide) operates.
+
+
+  
+    
+    
+  
+

+        Targets
+    
+        BUILD files
+    

diff --git a/versions/9.1.0/concepts/platforms.mdx b/versions/9.1.0/concepts/platforms.mdx
new file mode 100644
index 00000000..d87d4a77
--- /dev/null
+++ b/versions/9.1.0/concepts/platforms.mdx
@@ -0,0 +1,426 @@
+---
+title: 'Migrating to Platforms'
+---
+
+Bazel has sophisticated [support](#background) for modeling
+[platforms][Platforms] and [toolchains][Toolchains] for multi-architecture and
+cross-compiled builds.
+
+This page summarizes the state of this support.
+
+Key Point: Bazel's platform and toolchain APIs are available today. Not all
+languages support them. Use these APIs with your project if you can. Bazel is
+migrating all major languages so eventually all builds will be platform-based.
+
+See also:
+
+* [Platforms][Platforms]
+* [Toolchains][Toolchains]
+* [Background][Background]
+
+## Status {#status}
+
+### C++ {#cxx}
+
+C++ rules use platforms to select toolchains when
+`--incompatible_enable_cc_toolchain_resolution` is set.
+
+This means you can configure a C++ project with:
+
+```posix-terminal
+bazel build //:my_cpp_project --platforms=//:myplatform
+```
+
+instead of the legacy:
+
+```posix-terminal
+bazel build //:my_cpp_project` --cpu=... --crosstool_top=...  --compiler=...
+```
+
+This will be enabled by default in Bazel 7.0 ([#7260](https://github.com/bazelbuild/bazel/issues/7260)).
+
+To test your C++ project with platforms, see
+[Migrating Your Project](#migrating-your-project) and
+[Configuring C++ toolchains].
+
+### Java {#java}
+
+Java rules use platforms to select toolchains.
+
+This replaces legacy flags `--java_toolchain`, `--host_java_toolchain`,
+`--javabase`, and `--host_javabase`.
+
+See [Java and Bazel](/versions/9.1.0/docs/bazel-and-java) for details.
+
+### Android {#android}
+
+Android rules use platforms to select toolchains when
+`--incompatible_enable_android_toolchain_resolution` is set.
+
+This means you can configure an Android project with:
+
+```posix-terminal
+bazel build //:my_android_project --android_platforms=//:my_android_platform
+```
+
+instead of with legacy flags like  `--android_crosstool_top`, `--android_cpu`,
+and `--fat_apk_cpu`.
+
+This will be enabled by default in Bazel 7.0 ([#16285](https://github.com/bazelbuild/bazel/issues/16285)).
+
+To test your Android project with platforms, see
+[Migrating Your Project](#migrating-your-project).
+
+### Apple {#apple}
+
+[Apple rules] do not support platforms and are not yet scheduled
+for support.
+
+You can still use platform APIs with Apple builds (for example, when building
+with a mixture of Apple rules and pure C++) with [platform
+mappings](#platform-mappings).
+
+### Other languages {#other-languages}
+
+* [Go rules] fully support platforms
+* [Rust rules] fully support platforms.
+
+If you own a language rule set, see [Migrating your rule set] for adding
+support.
+
+## Background {#background}
+
+*Platforms* and *toolchains* were introduced to standardize how software
+projects target different architectures and cross-compile.
+
+This was
+[inspired][Inspiration]
+by the observation that language maintainers were already doing this in ad
+hoc, incompatible ways. For example, C++ rules used `--cpu` and
+ `--crosstool_top` to declare a target CPU and toolchain. Neither of these
+correctly models a "platform". This produced awkward and incorrect builds.
+
+Java, Android, and other languages evolved their own flags for similar purposes,
+none of which interoperated with each other. This made cross-language builds
+confusing and complicated.
+
+Bazel is intended for large, multi-language, multi-platform projects. This
+demands more principled support for these concepts, including a clear
+standard API.
+
+### Need for migration {#migration}
+
+Upgrading to the new API requires two efforts: releasing the API and upgrading
+rule logic to use it.
+
+The first is done but the second is ongoing. This consists of ensuring
+language-specific platforms and toolchains are defined, language logic reads
+toolchains through the new API instead of old flags like `--crosstool_top`, and
+`config_setting`s select on the new API instead of old flags.
+
+This work is straightforward but requires a distinct effort for each language,
+plus fair warning for project owners to test against upcoming changes.
+
+This is why this is an ongoing migration.
+
+### Goal {#goal}
+
+This migration is complete when all projects build with the form:
+
+```posix-terminal
+bazel build //:myproject --platforms=//:myplatform
+```
+
+This implies:
+
+1. Your project's rules choose the right toolchains for `//:myplatform`.
+1. Your project's dependencies choose the right toolchains for `//:myplatform`.
+1. `//:myplatform` references
+[common declarations][Common Platform Declarations]
+of `CPU`, `OS`, and other generic, language-independent properties
+1. All relevant [`select()`s][select()] properly match `//:myplatform`.
+1. `//:myplatform` is defined in a clear, accessible place: in your project's
+repo if the platform is unique to your project, or some common place all
+consuming projects can find it
+
+Old flags like `--cpu`, `--crosstool_top`, and `--fat_apk_cpu` will be
+deprecated and removed as soon as it's safe to do so.
+
+Ultimately, this will be the *sole* way to configure architectures.
+
+## Migrating your project {#migrating-your-project}
+
+If you build with languages that support platforms, your build should already
+work with an invocation like:
+
+```posix-terminal
+bazel build //:myproject --platforms=//:myplatform
+```
+
+See [Status](#status) and your language's documentation for precise details.
+
+If a language requires a flag to enable platform support, you also need to set
+that flag. See [Status](#status) for details.
+
+For your project to build, you need to check the following:
+
+1. `//:myplatform` must exist. It's generally the project owner's responsibility
+   to define platforms because different projects target different machines.
+   See [Default platforms](#default-platforms).
+
+1. The toolchains you want to use must exist. If using stock toolchains, the
+   language owners should include instructions for how to register them. If
+   writing your own custom toolchains, you need to [register](https://bazel.build/versions/9.1.0/extending/toolchains#registering-building-toolchains) them in your
+   `MODULE.bazel` file or with [`--extra_toolchains`](https://bazel.build/versions/9.1.0/reference/command-line-reference#flag--extra_toolchains).
+
+1. `select()`s and [configuration transitions][Starlark transitions] must
+  resolve properly. See [select()](#select) and [Transitions](#transitions).
+
+1. If your build mixes languages that do and don't support platforms, you may
+   need platform mappings to help the legacy languages work with the new API.
+   See [Platform mappings](#platform-mappings) for details.
+
+If you still have problems, [reach out](#questions) for support.
+
+### Default platforms {#default-platforms}
+
+Project owners should define explicit
+[platforms][Defining Constraints and Platforms] to describe the architectures
+they want to build for. These are then triggered with `--platforms`.
+
+When `--platforms` isn't set, Bazel defaults to a `platform` representing the
+local build machine. This is auto-generated at `@platforms//host` (aliased as
+`@bazel_tools//tools:host_platform`)
+so there's no need to explicitly define it. It maps the local machine's `OS`
+and `CPU` with `constraint_value`s declared in
+[`@platforms`](https://github.com/bazelbuild/platforms).
+
+### `select()` {#select}
+
+Projects can [`select()`][select()] on
+[`constraint_value` targets][constraint_value Rule] but not complete
+platforms. This is intentional so `select()` supports as wide a variety of
+machines as possible. A library with `ARM`-specific sources should support *all*
+`ARM`-powered machines unless there's reason to be more specific.
+
+To select on one or more `constraint_value`s, use:
+
+```python
+config_setting(
+    name = "is_arm",
+    constraint_values = [
+        "@platforms//cpu:arm",
+    ],
+)
+```
+
+This is equivalent to traditionally selecting on `--cpu`:
+
+```python
+config_setting(
+    name = "is_arm",
+    values = {
+        "cpu": "arm",
+    },
+)
+```
+
+More details [here][select() Platforms].
+
+`select`s on `--cpu`, `--crosstool_top`, etc. don't understand `--platforms`.
+When migrating your project to platforms, you must either convert them to
+`constraint_values` or use [platform mappings](#platform-mappings) to support
+both styles during migration.
+
+### Transitions {#transitions}
+
+[Starlark transitions][Starlark transitions] change
+flags down parts of your build graph. If your project uses a transition that
+sets `--cpu`, `--crossstool_top`, or other legacy flags, rules that read
+`--platforms` won't see these changes.
+
+When migrating your project to platforms, you must either convert changes like
+`return { "//command_line_option:cpu": "arm" }` to `return {
+"//command_line_option:platforms": "//:my_arm_platform" }` or use [platform
+mappings](#platform-mappings) to support both styles during migration.
+window.
+
+## Migrating your rule set {#migrating-your-rule-set}
+
+If you own a rule set and want to support platforms, you need to:
+
+1. Have rule logic resolve toolchains with the toolchain API. See
+   [toolchain API][Toolchains] (`ctx.toolchains`).
+
+1. Optional: define an `--incompatible_enable_platforms_for_my_language` flag so
+   rule logic alternately resolves toolchains through the new API or old flags
+   like `--crosstool_top` during migration testing.
+
+1. Define the relevant properties that make up platform components. See
+   [Common platform properties](#common-platform-properties)
+
+1. Define standard toolchains and make them accessible to users through your
+   rule's registration instructions ([details](https://bazel.build/versions/9.1.0/extending/toolchains#registering-building-toolchains))
+
+1. Ensure [`select()`s](#select) and
+   [configuration transitions](#transitions) support platforms. This is the
+   biggest challenge. It's particularly challenging for multi-language projects
+   (which may fail if *all* languages can't read `--platforms`).
+
+If you need to mix with rules that don't support platforms, you may need
+[platform mappings](#platform-mappings) to bridge the gap.
+
+### Common platform properties {#common-platform-properties}
+
+Common, cross-language platform properties like `OS` and `CPU` should be
+declared in [`@platforms`](https://github.com/bazelbuild/platforms).
+This encourages sharing, standardization, and cross-language compatibility.
+
+Properties unique to your rules should be declared in your rule's repo. This
+lets you maintain clear ownership over the specific concepts your rules are
+responsible for.
+
+If your rules use custom-purpose OSes or CPUs, these should be declared in your
+rule's repo vs.
+[`@platforms`](https://github.com/bazelbuild/platforms).
+
+## Platform mappings {#platform-mappings}
+
+*Platform mappings* is a temporary API that lets platform-aware logic mix with
+legacy logic in the same build. This is a blunt tool that's only intended to
+smooth incompatibilities with different migration timeframes.
+
+Caution: Only use this if necessary, and expect to eventually  eliminate it.
+
+A platform mapping is a map of either a `platform()` to a
+corresponding set of legacy flags or the reverse. For example:
+
+```python
+platforms:
+  # Maps "--platforms=//platforms:ios" to "--ios_multi_cpus=x86_64 --apple_platform_type=ios".
+  //platforms:ios
+    --ios_multi_cpus=x86_64
+    --apple_platform_type=ios
+
+flags:
+  # Maps "--ios_multi_cpus=x86_64 --apple_platform_type=ios" to "--platforms=//platforms:ios".
+  --ios_multi_cpus=x86_64
+  --apple_platform_type=ios
+    //platforms:ios
+
+  # Maps "--cpu=darwin_x86_64 --apple_platform_type=macos" to "//platform:macos".
+  --cpu=darwin_x86_64
+  --apple_platform_type=macos
+    //platforms:macos
+```
+
+Bazel uses this to guarantee all settings, both platform-based and
+legacy, are consistently applied throughout the build, including through
+[transitions](#transitions).
+
+By default Bazel reads mappings from the `platform_mappings` file in your
+workspace root. You can also set
+`--platform_mappings=//:my_custom_mapping`.
+
+See the [platform mappings design] for details.
+
+## API review {#api-review}
+
+A [`platform`][platform Rule] is a collection of
+[`constraint_value` targets][constraint_value Rule]:
+
+```python
+platform(
+    name = "myplatform",
+    constraint_values = [
+        "@platforms//os:linux",
+        "@platforms//cpu:arm",
+    ],
+)
+```
+
+A [`constraint_value`][constraint_value Rule] is a machine
+property. Values of the same "kind" are grouped under a common
+[`constraint_setting`][constraint_setting Rule]:
+
+```python
+constraint_setting(name = "os")
+constraint_value(
+    name = "linux",
+    constraint_setting = ":os",
+)
+constraint_value(
+    name = "mac",
+    constraint_setting = ":os",
+)
+```
+
+A [`toolchain`][Toolchains] is a [Starlark rule][Starlark rule]. Its
+attributes declare a language's tools (like `compiler =
+"//mytoolchain:custom_gcc"`). Its [providers][Starlark Provider] pass
+this information to rules that need to build with these tools.
+
+Toolchains declare the `constraint_value`s of machines they can
+[target][target_compatible_with Attribute]
+(`target_compatible_with = ["@platforms//os:linux"]`) and machines their tools can
+[run on][exec_compatible_with Attribute]
+(`exec_compatible_with = ["@platforms//os:mac"]`).
+
+When building `$ bazel build //:myproject --platforms=//:myplatform`, Bazel
+automatically selects a toolchain that can run on the build machine and
+build binaries for `//:myplatform`. This is known as *toolchain resolution*.
+
+The set of available toolchains can be registered in the `MODULE.bazel` file
+with [`register_toolchains`][register_toolchains Function] or at the
+command line with [`--extra_toolchains`][extra_toolchains Flag].
+
+For more information see [here][Toolchains].
+
+## Questions {#questions}
+
+For general support and questions about the migration timeline, contact
+[bazel-discuss] or the owners of the appropriate rules.
+
+For discussions on the design and evolution of the platform/toolchain APIs,
+contact [bazel-dev].
+
+## See also {#see-also}
+
+* [Configurable Builds - Part 1]
+* [Platforms]
+* [Toolchains]
+* [Bazel Platforms Cookbook]
+* [Platforms examples]
+* [Example C++ toolchain]
+
+[Android Rules]: /docs/bazel-and-android
+[Apple Rules]: https://github.com/bazelbuild/rules_apple
+[Background]: #background
+[Bazel platforms Cookbook]: https://docs.google.com/document/d/1UZaVcL08wePB41ATZHcxQV4Pu1YfA1RvvWm8FbZHuW8/
+[bazel-dev]: https://groups.google.com/forum/#!forum/bazel-dev
+[bazel-discuss]: https://groups.google.com/forum/#!forum/bazel-discuss
+[Common Platform Declarations]: https://github.com/bazelbuild/platforms
+[constraint_setting Rule]: /reference/be/platforms-and-toolchains#constraint_setting
+[constraint_value Rule]: /reference/be/platforms-and-toolchains#constraint_value
+[Configurable Builds - Part 1]: https://blog.bazel.build/2019/02/11/configurable-builds-part-1.html
+[Configuring C++ toolchains]: /tutorials/ccp-toolchain-config
+[Defining Constraints and Platforms]: /extending/platforms#constraints-platforms
+[Example C++ toolchain]: https://github.com/gregestren/snippets/tree/master/custom_cc_toolchain_with_platforms
+[exec_compatible_with Attribute]: /reference/be/platforms-and-toolchains#toolchain.exec_compatible_with
+[extra_toolchains Flag]: /reference/command-line-reference#flag--extra_toolchains
+[Go Rules]: https://github.com/bazelbuild/rules_go
+[Inspiration]: https://blog.bazel.build/2019/02/11/configurable-builds-part-1.html
+[Migrating your rule set]: #migrating-your-rule-set
+[Platforms]: /extending/platforms
+[Platforms examples]: https://github.com/hlopko/bazel_platforms_examples
+[platform mappings design]: https://docs.google.com/document/d/1Vg_tPgiZbSrvXcJ403vZVAGlsWhH9BUDrAxMOYnO0Ls/edit
+[platform Rule]: /reference/be/platforms-and-toolchains#platform
+[register_toolchains Function]: /rules/lib/globals/module#register_toolchains
+[Rust rules]: https://github.com/bazelbuild/rules_rust
+[select()]: /docs/configurable-attributes
+[select() Platforms]: /docs/configurable-attributes#platforms
+[Starlark provider]: /extending/rules#providers
+[Starlark rule]: /extending/rules
+[Starlark transitions]: /extending/config#user-defined-transitions
+[target_compatible_with Attribute]: /reference/be/platforms-and-toolchains#toolchain.target_compatible_with
+[Toolchains]: /extending/toolchains
diff --git a/versions/9.1.0/concepts/visibility.mdx b/versions/9.1.0/concepts/visibility.mdx
new file mode 100644
index 00000000..d44ea0f9
--- /dev/null
+++ b/versions/9.1.0/concepts/visibility.mdx
@@ -0,0 +1,608 @@
+---
+title: 'Visibility'
+---
+
+This page covers Bazel's two visibility systems:
+[target visibility](#target-visibility) and [load visibility](#load-visibility).
+
+Both types of visibility help other developers distinguish between your
+library's public API and its implementation details, and help enforce structure
+as your workspace grows. You can also use visibility when deprecating a public
+API to allow current users while denying new ones.
+
+## Target visibility {:#target-visibility}
+
+**Target visibility** controls who may depend on your target — that is, who may
+use your target's label inside an attribute such as `deps`. A target will fail
+to build during the [analysis](/versions/9.1.0/reference/glossary#analysis-phase) phase if it
+violates the visibility of one of its dependencies.
+
+Generally, a target `A` is visible to a target `B` if they are in the same
+location, or if `A` grants visibility to `B`'s location. In the absence of
+[symbolic macros](/versions/9.1.0/extending/macros), the term "location" can be simplified
+to just "package"; see [below](#symbolic-macros) for more on symbolic macros.
+
+Visibility is specified by listing allowed packages. Allowing a package does not
+necessarily mean that its subpackages are also allowed. For more details on
+packages and subpackages, see [Concepts and terminology](/versions/9.1.0/concepts/build-ref).
+
+For prototyping, you can disable target visibility enforcement by setting the
+flag `--check_visibility=false`. This shouldn't be done for production usage in
+submitted code.
+
+The primary way to control visibility is with a rule's
+[`visibility`](/versions/9.1.0/reference/be/common-definitions#common.visibility) attribute.
+The following subsections describe the attribute's format, how to apply it to
+various kinds of targets, and the interaction between the visibility system and
+symbolic macros.
+
+### Visibility specifications {:#visibility-specifications}
+
+All rule targets have a `visibility` attribute that takes a list of labels. Each
+label has one of the following forms. With the exception of the last form, these
+are just syntactic placeholders that don't correspond to any actual target.
+
+*   `"//visibility:public"`: Grants access to all packages.
+
+*   `"//visibility:private"`: Does not grant any additional access; only targets
+    in this location's package can use this target.
+
+*   `"//foo/bar:__pkg__"`: Grants access to `//foo/bar` (but not its
+    subpackages).
+
+*   `"//foo/bar:__subpackages__"`: Grants access to `//foo/bar` and all of its
+    direct and indirect subpackages.
+
+*   `"//some_pkg:my_package_group"`: Grants access to all of the packages that
+    are part of the given [`package_group`](/versions/9.1.0/reference/be/functions#package_group).
+
+    *   Package groups use a
+        [different syntax](/versions/9.1.0/reference/be/functions#package_group.packages) for
+        specifying packages. Within a package group, the forms
+        `"//foo/bar:__pkg__"` and `"//foo/bar:__subpackages__"` are respectively
+        replaced by `"//foo/bar"` and `"//foo/bar/..."`. Likewise,
+        `"//visibility:public"` and `"//visibility:private"` are just `"public"`
+        and `"private"`.
+
+For example, if `//some/package:mytarget` has its `visibility` set to
+`[":__subpackages__", "//tests:__pkg__"]`, then it could be used by any target
+that is part of the `//some/package/...` source tree, as well as targets
+declared in `//tests/BUILD`, but not by targets defined in
+`//tests/integration/BUILD`.
+
+**Best practice:** To make several targets visible to the same set
+of packages, use a `package_group` instead of repeating the list in each
+target's `visibility` attribute. This increases readability and prevents the
+lists from getting out of sync.
+
+**Best practice:** When granting visibility to another team's project, prefer
+`__subpackages__` over `__pkg__` to avoid needless visibility churn as that
+project evolves and adds new subpackages.
+
+Note: The `visibility` attribute may not specify non-`package_group` targets.
+Doing so triggers a "Label does not refer to a package group" or "Cycle in
+dependency graph" error.
+
+### Rule target visibility {:#rule-target-visibility}
+
+A rule target's visibility is determined by taking its `visibility` attribute
+-- or a suitable default if not given -- and appending the location where the
+target was declared. For targets not declared in a symbolic macro, if the
+package specifies a [`default_visibility`](/versions/9.1.0/reference/be/functions#package.default_visibility),
+this default is used; for all other packages and for targets declared in a
+symbolic macro, the default is just `["//visibility:private"]`.
+
+```starlark
+# //mypkg/BUILD
+
+package(default_visibility = ["//friend:__pkg__"])
+
+cc_library(
+    name = "t1",
+    ...
+    # No visibility explicitly specified.
+    # Effective visibility is ["//friend:__pkg__", "//mypkg:__pkg__"].
+    # If no default_visibility were given in package(...), the visibility would
+    # instead default to ["//visibility:private"], and the effective visibility
+    # would be ["//mypkg:__pkg__"].
+)
+
+cc_library(
+    name = "t2",
+    ...
+    visibility = [":clients"],
+    # Effective visibility is ["//mypkg:clients, "//mypkg:__pkg__"], which will
+    # expand to ["//another_friend:__subpackages__", "//mypkg:__pkg__"].
+)
+
+cc_library(
+    name = "t3",
+    ...
+    visibility = ["//visibility:private"],
+    # Effective visibility is ["//mypkg:__pkg__"]
+)
+
+package_group(
+    name = "clients",
+    packages = ["//another_friend/..."],
+)
+```
+
+**Best practice:** Avoid setting `default_visibility` to public. It may be
+convenient for prototyping or in small codebases, but the risk of inadvertently
+creating public targets increases as the codebase grows. It's better to be
+explicit about which targets are part of a package's public interface.
+
+### Generated file target visibility {:#generated-file-target-visibility}
+
+A generated file target has the same visibility as the rule target that
+generates it.
+
+```starlark
+# //mypkg/BUILD
+
+java_binary(
+    name = "foo",
+    ...
+    visibility = ["//friend:__pkg__"],
+)
+```
+
+```starlark
+# //friend/BUILD
+
+some_rule(
+    name = "bar",
+    deps = [
+        # Allowed directly by visibility of foo.
+        "//mypkg:foo",
+        # Also allowed. The java_binary's "_deploy.jar" implicit output file
+        # target the same visibility as the rule target itself.
+        "//mypkg:foo_deploy.jar",
+    ]
+    ...
+)
+```
+
+### Source file target visibility {:#source-file-target-visibility}
+
+Source file targets can either be explicitly declared using
+[`exports_files`](/versions/9.1.0/reference/be/functions#exports_files), or implicitly created
+by referring to their filename in a label attribute of a rule (outside of a
+symbolic macro). As with rule targets, the location of the call to
+`exports_files`, or the BUILD file that referred to the input file, is always
+automatically appended to the file's visibility.
+
+Files declared by `exports_files` can have their visibility set by the
+`visibility` parameter to that function. If this parameter is not given, the visibility is public.
+
+Note: `exports_files` may not be used to override the visibility of a generated
+file.
+
+For files that do not appear in a call to `exports_files`, the visibility
+depends on the value of the flag
+[`--incompatible_no_implicit_file_export`](https://github.com/bazelbuild/bazel/issues/10225){: .external}:
+
+*   If the flag is true, the visibility is private.
+
+*   Else, the legacy behavior applies: The visibility is the same as the
+    `BUILD` file's `default_visibility`, or private if a default visibility is
+    not specified.
+
+Avoid relying on the legacy behavior. Always write an `exports_files`
+declaration whenever a source file target needs non-private visibility.
+
+**Best practice:** When possible, prefer to expose a rule target rather than a
+source file. For example, instead of calling `exports_files` on a `.java` file,
+wrap the file in a non-private `java_library` target. Generally, rule targets
+should only directly reference source files that live in the same package.
+
+#### Example {:#source-file-visibility-example}
+
+File `//frobber/data/BUILD`:
+
+```starlark
+exports_files(["readme.txt"])
+```
+
+File `//frobber/bin/BUILD`:
+
+```starlark
+cc_binary(
+  name = "my-program",
+  data = ["//frobber/data:readme.txt"],
+)
+```
+
+### Config setting visibility {:#config-setting-visibility}
+
+Historically, Bazel has not enforced visibility for
+[`config_setting`](/versions/9.1.0/reference/be/general#config_setting) targets that are
+referenced in the keys of a [`select()`](/versions/9.1.0/reference/be/functions#select). There
+are two flags to remove this legacy behavior:
+
+*   [`--incompatible_enforce_config_setting_visibility`](https://github.com/bazelbuild/bazel/issues/12932){: .external}
+    enables visibility checking for these targets. To assist with migration, it
+    also causes any `config_setting` that does not specify a `visibility` to be
+    considered public (regardless of package-level `default_visibility`).
+
+*   [`--incompatible_config_setting_private_default_visibility`](https://github.com/bazelbuild/bazel/issues/12933){: .external}
+    causes `config_setting`s that do not specify a `visibility` to respect the
+    package's `default_visibility` and to fallback on private visibility, just
+    like any other rule target. It is a no-op if
+    `--incompatible_enforce_config_setting_visibility` is not set.
+
+Avoid relying on the legacy behavior. Any `config_setting` that is intended to
+be used outside the current package should have an explicit `visibility`, if the
+package does not already specify a suitable `default_visibility`.
+
+### Package group target visibility {:#package-group-target-visibility}
+
+`package_group` targets do not have a `visibility` attribute. They are always
+publicly visible.
+
+### Visibility of implicit dependencies {:#visibility-implicit-dependencies}
+
+Some rules have [implicit dependencies](/versions/9.1.0/extending/rules#private_attributes_and_implicit_dependencies) —
+dependencies that are not spelled out in a `BUILD` file but are inherent to
+every instance of that rule. For example, a `cc_library` rule might create an
+implicit dependency from each of its rule targets to an executable target
+representing a C++ compiler.
+
+The visibility of such an implicit dependency is checked with respect to the
+package containing the `.bzl` file in which the rule (or aspect) is defined. In
+our example, the C++ compiler could be private so long as it lives in the same
+package as the definition of the `cc_library` rule. As a fallback, if the
+implicit dependency is not visible from the definition, it is checked with
+respect to the `cc_library` target.
+
+If you want to restrict the usage of a rule to certain packages, use
+[load visibility](#load-visibility) instead.
+
+### Visibility and symbolic macros {:#symbolic-macros}
+
+This section describes how the visibility system interacts with
+[symbolic macros](/versions/9.1.0/extending/macros).
+
+#### Locations within symbolic macros {:#locations-within-symbolic-macros}
+
+A key detail of the visibility system is how we determine the location of a
+declaration. For targets that are not declared in a symbolic macro, the location
+is just the package where the target lives -- the package of the `BUILD` file.
+But for targets created in a symbolic macro, the location is the package
+containing the `.bzl` file where the macro's definition (the
+`my_macro = macro(...)` statement) appears. When a target is created inside
+multiple nested targets, it is always the innermost symbolic macro's definition
+that is used.
+
+The same system is used to determine what location to check against a given
+dependency's visibility. If the consuming target was created inside a macro, we
+look at the innermost macro's definition rather than the package the consuming
+target lives in.
+
+This means that all macros whose code is defined in the same package are
+automatically "friends" with one another. Any target directly created by a macro
+defined in `//lib:defs.bzl` can be seen from any other macro defined in `//lib`,
+regardless of what packages the macros are actually instantiated in. Likewise,
+they can see, and can be seen by, targets declared directly in `//lib/BUILD` and
+its legacy macros. Conversely, targets that live in the same package cannot
+necessarily see one another if at least one of them is created by a symbolic
+macro.
+
+Within a symbolic macro's implementation function, the `visibility` parameter
+has the effective value of the macro's `visibility` attribute after appending
+the location where the macro was called. The standard way for a macro to export
+one of its targets to its caller is to forward this value along to the target's
+declaration, as in `some_rule(..., visibility = visibility)`. Targets that omit
+this attribute won't be visible to the caller of the macro unless the caller
+happens to be in the same package as the macro definition. This behavior
+composes, in the sense that a chain of nested calls to submacros may each pass
+`visibility = visibility`, re-exporting the inner macro's exported targets to
+the caller at each level, without exposing any of the macros' implementation
+details.
+
+#### Delegating privileges to a submacro {:#delegating-privileges-to-a-submacro}
+
+The visibility model has a special feature to allow a macro to delegate its
+permissions to a submacro. This is important for factoring and composing macros.
+
+Suppose you have a macro `my_macro` that creates a dependency edge using a rule
+`some_library` from another package:
+
+```starlark
+# //macro/defs.bzl
+load("//lib:defs.bzl", "some_library")
+
+def _impl(name, visibility, ...):
+    ...
+    native.genrule(
+        name = name + "_dependency"
+        ...
+    )
+    some_library(
+        name = name + "_consumer",
+        deps = [name + "_dependency"],
+        ...
+    )
+
+my_macro = macro(implementation = _impl, ...)
+```
+
+```starlark
+# //pkg/BUILD
+
+load("//macro:defs.bzl", "my_macro")
+
+my_macro(name = "foo", ...)
+```
+
+The `//pkg:foo_dependency` target has no `visibility` specified, so it is only
+visible within `//macro`, which works fine for the consuming target. Now, what
+happens if the author of `//lib` refactors `some_library` to instead be
+implemented using a macro?
+
+```starlark
+# //lib:defs.bzl
+
+def _impl(name, visibility, deps, ...):
+    some_rule(
+        # Main target, exported.
+        name = name,
+        visibility = visibility,
+        deps = deps,
+        ...)
+
+some_library = macro(implementation = _impl, ...)
+```
+
+With this change, `//pkg:foo_consumer`'s location is now `//lib` rather than
+`//macro`, so its usage of `//pkg:foo_dependency` violates the dependency's
+visibility. The author of `my_macro` can't be expected to pass
+`visibility = ["//lib"]` to the declaration of the dependency just to work
+around this implementation detail.
+
+For this reason, when a dependency of a target is also an attribute value of the
+macro that declared the target, we check the dependency's visibility against the
+location of the macro instead of the location of the consuming target.
+
+In this example, to validate whether `//pkg:foo_consumer` can see
+`//pkg:foo_dependency`, we see that `//pkg:foo_dependency` was also passed as an
+input to the call to `some_library` inside of `my_macro`, and instead check the
+dependency's visibility against the location of this call, `//macro`.
+
+This process can repeat recursively, as long as a target or macro declaration is
+inside of another symbolic macro taking the dependency's label in one of its
+label-typed attributes.
+
+Note: Visibility delegation does not work for labels that were not passed into
+the macro, such as labels derived by string manipulation.
+
+#### Finalizers {:#finalizers}
+
+Targets declared in a rule finalizer (a symbolic macro with `finalizer = True`),
+in addition to seeing targets following the usual symbolic macro visibility
+rules, can *also* see all targets which are visible to the finalizer target's
+package.
+
+In other words, if you migrate a `native.existing_rules()`-based legacy macro to
+a finalizer, the targets declared by the finalizer will still be able to see
+their old dependencies.
+
+It is possible to define targets that a finalizer can introspect using
+`native.existing_rules()`, but which it cannot use as dependencies under the
+visibility system. For example, if a macro-defined target is not visible to its
+own package or to the finalizer macro's definition, and is not delegated to the
+finalizer, the finalizer cannot see such a target. Note, however, that a
+`native.existing_rules()`-based legacy macro will also be unable to see such a
+target.
+
+## Load visibility {:#load-visibility}
+
+**Load visibility** controls whether a `.bzl` file may be loaded from other
+`BUILD` or `.bzl` files outside the current package.
+
+In the same way that target visibility protects source code that is encapsulated
+by targets, load visibility protects build logic that is encapsulated by `.bzl`
+files. For instance, a `BUILD` file author might wish to factor some repetitive
+target declarations into a macro in a `.bzl` file. Without the protection of
+load visibility, they might find their macro reused by other collaborators in
+the same workspace, so that modifying the macro breaks other teams' builds.
+
+Note that a `.bzl` file may or may not have a corresponding source file target.
+If it does, there is no guarantee that the load visibility and the target
+visibility coincide. That is, the same `BUILD` file might be able to load the
+`.bzl` file but not list it in the `srcs` of a [`filegroup`](/versions/9.1.0/reference/be/general#filegroup),
+or vice versa. This can sometimes cause problems for rules that wish to consume
+`.bzl` files as source code, such as for documentation generation or testing.
+
+For prototyping, you may disable load visibility enforcement by setting
+`--check_bzl_visibility=false`. As with `--check_visibility=false`, this should
+not be done for submitted code.
+
+Load visibility is available as of Bazel 6.0.
+
+### Declaring load visibility {:#declaring-load-visibility}
+
+To set the load visibility of a `.bzl` file, call the
+[`visibility()`](/versions/9.1.0/rules/lib/globals/bzl#visibility) function from within the file.
+The argument to `visibility()` is a list of package specifications, just like
+the [`packages`](/versions/9.1.0/reference/be/functions#package_group.packages) attribute of
+`package_group`. However, `visibility()` does not accept negative package
+specifications.
+
+The call to `visibility()` must only occur once per file, at the top level (not
+inside a function), and ideally immediately following the `load()` statements.
+
+Unlike target visibility, the default load visibility is always public. Files
+that do not call `visibility()` are always loadable from anywhere in the
+workspace. It is a good idea to add `visibility("private")` to the top of any
+new `.bzl` file that is not specifically intended for use outside the package.
+
+### Example {:#load-visibility-example}
+
+```starlark
+# //mylib/internal_defs.bzl
+
+# Available to subpackages and to mylib's tests.
+visibility(["//mylib/...", "//tests/mylib/..."])
+
+def helper(...):
+    ...
+```
+
+```starlark
+# //mylib/rules.bzl
+
+load(":internal_defs.bzl", "helper")
+# Set visibility explicitly, even though public is the default.
+# Note the [] can be omitted when there's only one entry.
+visibility("public")
+
+myrule = rule(
+    ...
+)
+```
+
+```starlark
+# //someclient/BUILD
+
+load("//mylib:rules.bzl", "myrule")          # ok
+load("//mylib:internal_defs.bzl", "helper")  # error
+
+...
+```
+
+### Load visibility practices {:#load-visibility-practices}
+
+This section describes tips for managing load visibility declarations.
+
+#### Factoring visibilities {:#factoring-visibilities}
+
+When multiple `.bzl` files should have the same visibility, it can be helpful to
+factor their package specifications into a common list. For example:
+
+```starlark
+# //mylib/internal_defs.bzl
+
+visibility("private")
+
+clients = [
+    "//foo",
+    "//bar/baz/...",
+    ...
+]
+```
+
+```starlark
+# //mylib/feature_A.bzl
+
+load(":internal_defs.bzl", "clients")
+visibility(clients)
+
+...
+```
+
+```starlark
+# //mylib/feature_B.bzl
+
+load(":internal_defs.bzl", "clients")
+visibility(clients)
+
+...
+```
+
+This helps prevent accidental skew between the various `.bzl` files'
+visibilities. It also is more readable when the `clients` list is large.
+
+#### Composing visibilities {:#composing-visibilities}
+
+Sometimes a `.bzl` file might need to be visible to an allowlist that is
+composed of multiple smaller allowlists. This is analogous to how a
+`package_group` can incorporate other `package_group`s via its
+[`includes`](/versions/9.1.0/reference/be/functions#package_group.includes) attribute.
+
+Suppose you are deprecating a widely used macro. You want it to be visible only
+to existing users and to the packages owned by your own team. You might write:
+
+```starlark
+# //mylib/macros.bzl
+
+load(":internal_defs.bzl", "our_packages")
+load("//some_big_client:defs.bzl", "their_remaining_uses")
+
+# List concatenation. Duplicates are fine.
+visibility(our_packages + their_remaining_uses)
+```
+
+#### Deduplicating with package groups {:#deduplicating-with-package-groups}
+
+Unlike target visibility, you cannot define a load visibility in terms of a
+`package_group`. If you want to reuse the same allowlist for both target
+visibility and load visibility, it's best to move the list of package
+specifications into a .bzl file, where both kinds of declarations may refer to
+it. Building off the example in [Factoring visibilities](#factoring-visibilities)
+above, you might write:
+
+```starlark
+# //mylib/BUILD
+
+load(":internal_defs", "clients")
+
+package_group(
+    name = "my_pkg_grp",
+    packages = clients,
+)
+```
+
+This only works if the list does not contain any negative package
+specifications.
+
+#### Protecting individual symbols {:#protecting-individual-symbols}
+
+Any Starlark symbol whose name begins with an underscore cannot be loaded from
+another file. This makes it easy to create private symbols, but does not allow
+you to share these symbols with a limited set of trusted files. On the other
+hand, load visibility gives you control over what other packages may see your
+`.bzl file`, but does not allow you to prevent any non-underscored symbol from
+being loaded.
+
+Luckily, you can combine these two features to get fine-grained control.
+
+```starlark
+# //mylib/internal_defs.bzl
+
+# Can't be public, because internal_helper shouldn't be exposed to the world.
+visibility("private")
+
+# Can't be underscore-prefixed, because this is
+# needed by other .bzl files in mylib.
+def internal_helper(...):
+    ...
+
+def public_util(...):
+    ...
+```
+
+```starlark
+# //mylib/defs.bzl
+
+load(":internal_defs", "internal_helper", _public_util="public_util")
+visibility("public")
+
+# internal_helper, as a loaded symbol, is available for use in this file but
+# can't be imported by clients who load this file.
+...
+
+# Re-export public_util from this file by assigning it to a global variable.
+# We needed to import it under a different name ("_public_util") in order for
+# this assignment to be legal.
+public_util = _public_util
+```
+
+#### bzl-visibility Buildifier lint {:#bzl-visibility-buildifier-lint}
+
+There is a [Buildifier lint](https://github.com/bazelbuild/buildtools/blob/master/WARNINGS.md#bzl-visibility)
+that provides a warning if users load a file from a directory named `internal`
+or `private`, when the user's file is not itself underneath the parent of that
+directory. This lint predates the load visibility feature and is unnecessary in
+workspaces where `.bzl` files declare visibilities.
diff --git a/versions/9.1.0/configure/attributes.mdx b/versions/9.1.0/configure/attributes.mdx
new file mode 100644
index 00000000..61e430a1
--- /dev/null
+++ b/versions/9.1.0/configure/attributes.mdx
@@ -0,0 +1,1092 @@
+---
+title: 'Configurable Build Attributes'
+---
+
+**_Configurable attributes_**, commonly known as [`select()`](/versions/9.1.0//reference/be/functions#select), is a Bazel feature that lets users toggle the values
+of build rule attributes at the command line.
+
+This can be used, for example, for a multiplatform library that automatically
+chooses the appropriate implementation for the architecture, or for a
+feature-configurable binary that can be customized at build time.
+
+## Example {#configurable-build-example}
+
+```python
+# myapp/BUILD
+
+cc_binary(
+    name = "mybinary",
+    srcs = ["main.cc"],
+    deps = select({
+        ":arm_build": [":arm_lib"],
+        ":x86_debug_build": [":x86_dev_lib"],
+        "//conditions:default": [":generic_lib"],
+    }),
+)
+
+config_setting(
+    name = "arm_build",
+    values = {"cpu": "arm"},
+)
+
+config_setting(
+    name = "x86_debug_build",
+    values = {
+        "cpu": "x86",
+        "compilation_mode": "dbg",
+    },
+)
+```
+
+This declares a `cc_binary` that "chooses" its deps based on the flags at the
+command line. Specifically, `deps` becomes:
+
+
+  
+    
+    
+  
+  
+    
+    
+  
+  
+    
+    
+  
+  
+    
+    
+  
+  
+    
+    
+  
+
Commanddeps =
bazel build //myapp:mybinary --cpu=arm[":arm_lib"]
bazel build //myapp:mybinary -c dbg --cpu=x86[":x86_dev_lib"]
bazel build //myapp:mybinary --cpu=ppc[":generic_lib"]
bazel build //myapp:mybinary -c dbg --cpu=ppc[":generic_lib"]

+
+`select()` serves as a placeholder for a value that will be chosen based on
+*configuration conditions*, which are labels referencing [`config_setting`](/versions/9.1.0/reference/be/general#config_setting)
+targets. By using `select()` in a configurable attribute, the attribute
+effectively adopts different values when different conditions hold.
+
+Matches must be unambiguous: if multiple conditions match then either
+*  They all resolve to the same value. For example, when running on linux x86, this is unambiguous
+   `{"@platforms//os:linux": "Hello", "@platforms//cpu:x86_64": "Hello"}` because both branches resolve to "hello".
+*  One's `values` is a strict superset of all others'. For example, `values = {"cpu": "x86", "compilation_mode": "dbg"}`
+   is an unambiguous specialization of `values = {"cpu": "x86"}`.
+
+The built-in condition [`//conditions:default`](#default-condition) automatically matches when
+nothing else does.
+
+While this example uses `deps`, `select()` works just as well on `srcs`,
+`resources`, `cmd`, and most other attributes. Only a small number of attributes
+are *non-configurable*, and these are clearly annotated. For example,
+`config_setting`'s own
+[`values`](/versions/9.1.0/reference/be/general#config_setting.values) attribute is non-configurable.
+
+## `select()` and dependencies {#select-and-dependencies}
+
+Certain attributes change the build parameters for all transitive dependencies
+under a target. For example, `genrule`'s `tools` changes `--cpu` to the CPU of
+the machine running Bazel (which, thanks to cross-compilation, may be different
+than the CPU the target is built for). This is known as a
+[configuration transition](/versions/9.1.0/reference/glossary#transition).
+
+Given
+
+```python
+#myapp/BUILD
+
+config_setting(
+    name = "arm_cpu",
+    values = {"cpu": "arm"},
+)
+
+config_setting(
+    name = "x86_cpu",
+    values = {"cpu": "x86"},
+)
+
+genrule(
+    name = "my_genrule",
+    srcs = select({
+        ":arm_cpu": ["g_arm.src"],
+        ":x86_cpu": ["g_x86.src"],
+    }),
+    tools = select({
+        ":arm_cpu": [":tool1"],
+        ":x86_cpu": [":tool2"],
+    }),
+)
+
+cc_binary(
+    name = "tool1",
+    srcs = select({
+        ":arm_cpu": ["armtool.cc"],
+        ":x86_cpu": ["x86tool.cc"],
+    }),
+)
+```
+
+running
+
+```sh
+$ bazel build //myapp:my_genrule --cpu=arm
+```
+
+on an `x86` developer machine binds the build to `g_arm.src`, `tool1`, and
+`x86tool.cc`. Both of the `select`s attached to `my_genrule` use `my_genrule`'s
+build parameters, which include `--cpu=arm`. The `tools` attribute changes
+`--cpu` to `x86` for `tool1` and its transitive dependencies. The `select` on
+`tool1` uses `tool1`'s build parameters, which include `--cpu=x86`.
+
+## Configuration conditions {#configuration-conditions}
+
+Each key in a configurable attribute is a label reference to a
+[`config_setting`](/versions/9.1.0/reference/be/general#config_setting) or
+[`constraint_value`](/versions/9.1.0/reference/be/platforms-and-toolchains#constraint_value).
+
+`config_setting` is just a collection of
+expected command line flag settings. By encapsulating these in a target, it's
+easy to maintain "standard" conditions users can reference from multiple places.
+
+`constraint_value` provides support for [multi-platform behavior](#platforms).
+
+### Built-in flags {#built-in-flags}
+
+Flags like `--cpu` are built into Bazel: the build tool natively understands
+them for all builds in all projects. These are specified with
+[`config_setting`](/versions/9.1.0/reference/be/general#config_setting)'s
+[`values`](/versions/9.1.0/reference/be/general#config_setting.values) attribute:
+
+```python
+config_setting(
+    name = "meaningful_condition_name",
+    values = {
+        "flag1": "value1",
+        "flag2": "value2",
+        ...
+    },
+)
+```
+
+`flagN` is a flag name (without `--`, so `"cpu"` instead of `"--cpu"`). `valueN`
+is the expected value for that flag. `:meaningful_condition_name` matches if
+*every* entry in `values` matches. Order is irrelevant.
+
+`valueN` is parsed as if it was set on the command line. This means:
+
+*  `values = { "compilation_mode": "opt" }` matches `bazel build -c opt`
+*  `values = { "force_pic": "true" }` matches `bazel build --force_pic=1`
+*  `values = { "force_pic": "0" }` matches `bazel build --noforce_pic`
+
+`config_setting` only supports flags that affect target behavior. For example,
+[`--show_progress`](/versions/9.1.0/docs/user-manual#show-progress) isn't allowed because
+it only affects how Bazel reports progress to the user. Targets can't use that
+flag to construct their results. The exact set of supported flags isn't
+documented. In practice, most flags that "make sense" work.
+
+### Custom flags {#custom-flags}
+
+You can model your own project-specific flags with
+[Starlark build settings][BuildSettings]. Unlike built-in flags, these are
+defined as build targets, so Bazel references them with target labels.
+
+These are triggered with [`config_setting`](/versions/9.1.0/reference/be/general#config_setting)'s
+[`flag_values`](/versions/9.1.0/reference/be/general#config_setting.flag_values)
+attribute:
+
+```python
+config_setting(
+    name = "meaningful_condition_name",
+    flag_values = {
+        "//myflags:flag1": "value1",
+        "//myflags:flag2": "value2",
+        ...
+    },
+)
+```
+
+Behavior is the same as for [built-in flags](#built-in-flags). See [here](https://github.com/bazelbuild/examples/tree/HEAD/configurations/select_on_build_setting)
+for a working example.
+
+[`--define`](/versions/9.1.0/reference/command-line-reference#flag--define)
+is an alternative legacy syntax for custom flags (for example
+`--define foo=bar`). This can be expressed either in the
+[values](/versions/9.1.0/reference/be/general#config_setting.values) attribute
+(`values = {"define": "foo=bar"}`) or the
+[define_values](/versions/9.1.0/reference/be/general#config_setting.define_values) attribute
+(`define_values = {"foo": "bar"}`). `--define` is only supported for backwards
+compatibility. Prefer Starlark build settings whenever possible.
+
+`values`, `flag_values`, and `define_values` evaluate independently. The
+`config_setting` matches if all values across all of them match.
+
+## The default condition {#default-condition}
+
+The built-in condition `//conditions:default` matches when no other condition
+matches.
+
+Because of the "exactly one match" rule, a configurable attribute with no match
+and no default condition emits a `"no matching conditions"` error. This can
+protect against silent failures from unexpected settings:
+
+```python
+# myapp/BUILD
+
+config_setting(
+    name = "x86_cpu",
+    values = {"cpu": "x86"},
+)
+
+cc_library(
+    name = "x86_only_lib",
+    srcs = select({
+        ":x86_cpu": ["lib.cc"],
+    }),
+)
+```
+
+```sh
+$ bazel build //myapp:x86_only_lib --cpu=arm
+ERROR: Configurable attribute "srcs" doesn't match this configuration (would
+a default condition help?).
+Conditions checked:
+  //myapp:x86_cpu
+```
+
+For even clearer errors, you can set custom messages with `select()`'s
+[`no_match_error`](#custom-error-messages) attribute.
+
+## Platforms {#platforms}
+
+While the ability to specify multiple flags on the command line provides
+flexibility, it can also be burdensome to individually set each one every time
+you want to build a target.
+   [Platforms](/versions/9.1.0/extending/platforms)
+let you consolidate these into simple bundles.
+
+```python
+# myapp/BUILD
+
+sh_binary(
+    name = "my_rocks",
+    srcs = select({
+        ":basalt": ["pyroxene.sh"],
+        ":marble": ["calcite.sh"],
+        "//conditions:default": ["feldspar.sh"],
+    }),
+)
+
+config_setting(
+    name = "basalt",
+    constraint_values = [
+        ":black",
+        ":igneous",
+    ],
+)
+
+config_setting(
+    name = "marble",
+    constraint_values = [
+        ":white",
+        ":metamorphic",
+    ],
+)
+
+# constraint_setting acts as an enum type, and constraint_value as an enum value.
+constraint_setting(name = "color")
+constraint_value(name = "black", constraint_setting = "color")
+constraint_value(name = "white", constraint_setting = "color")
+constraint_setting(name = "texture")
+constraint_value(name = "smooth", constraint_setting = "texture")
+constraint_setting(name = "type")
+constraint_value(name = "igneous", constraint_setting = "type")
+constraint_value(name = "metamorphic", constraint_setting = "type")
+
+platform(
+    name = "basalt_platform",
+    constraint_values = [
+        ":black",
+        ":igneous",
+    ],
+)
+
+platform(
+    name = "marble_platform",
+    constraint_values = [
+        ":white",
+        ":smooth",
+        ":metamorphic",
+    ],
+)
+```
+
+The platform can be specified on the command line. It activates the
+`config_setting`s that contain a subset of the platform's `constraint_values`,
+allowing those `config_setting`s to match in `select()` expressions.
+
+For example, in order to set the `srcs` attribute of `my_rocks` to `calcite.sh`,
+you can simply run
+
+```sh
+bazel build //my_app:my_rocks --platforms=//myapp:marble_platform
+```
+
+Without platforms, this might look something like
+
+```sh
+bazel build //my_app:my_rocks --define color=white --define texture=smooth --define type=metamorphic
+```
+
+`select()` can also directly read `constraint_value`s:
+
+```python
+constraint_setting(name = "type")
+constraint_value(name = "igneous", constraint_setting = "type")
+constraint_value(name = "metamorphic", constraint_setting = "type")
+sh_binary(
+    name = "my_rocks",
+    srcs = select({
+        ":igneous": ["igneous.sh"],
+        ":metamorphic" ["metamorphic.sh"],
+    }),
+)
+```
+
+This saves the need for boilerplate `config_setting`s when you only need to
+check against single values.
+
+Platforms are still under development. See the
+[documentation](/versions/9.1.0/concepts/platforms) for details.
+
+## Combining `select()`s {#combining-selects}
+
+`select` can appear multiple times in the same attribute:
+
+```python
+sh_binary(
+    name = "my_target",
+    srcs = ["always_include.sh"] +
+           select({
+               ":armeabi_mode": ["armeabi_src.sh"],
+               ":x86_mode": ["x86_src.sh"],
+           }) +
+           select({
+               ":opt_mode": ["opt_extras.sh"],
+               ":dbg_mode": ["dbg_extras.sh"],
+           }),
+)
+```
+
+Note: Some restrictions apply on what can be combined in the `select`s values:
+ - Duplicate labels can appear in different paths of the same `select`.
+ - Duplicate labels can *not* appear within the same path of a `select`.
+ - Duplicate labels can *not* appear across multiple combined `select`s (no matter what path)
+
+`select` cannot appear inside another `select`. If you need to nest `selects`
+and your attribute takes other targets as values, use an intermediate target:
+
+```python
+sh_binary(
+    name = "my_target",
+    srcs = ["always_include.sh"],
+    deps = select({
+        ":armeabi_mode": [":armeabi_lib"],
+        ...
+    }),
+)
+
+sh_library(
+    name = "armeabi_lib",
+    srcs = select({
+        ":opt_mode": ["armeabi_with_opt.sh"],
+        ...
+    }),
+)
+```
+
+If you need a `select` to match when multiple conditions match, consider [AND
+chaining](#and-chaining).
+
+## OR chaining {#or-chaining}
+
+Consider the following:
+
+```python
+sh_binary(
+    name = "my_target",
+    srcs = ["always_include.sh"],
+    deps = select({
+        ":config1": [":standard_lib"],
+        ":config2": [":standard_lib"],
+        ":config3": [":standard_lib"],
+        ":config4": [":special_lib"],
+    }),
+)
+```
+
+Most conditions evaluate to the same dep. But this syntax is hard to read and
+maintain. It would be nice to not have to repeat `[":standard_lib"]` multiple
+times.
+
+One option is to predefine the value as a BUILD variable:
+
+```python
+STANDARD_DEP = [":standard_lib"]
+
+sh_binary(
+    name = "my_target",
+    srcs = ["always_include.sh"],
+    deps = select({
+        ":config1": STANDARD_DEP,
+        ":config2": STANDARD_DEP,
+        ":config3": STANDARD_DEP,
+        ":config4": [":special_lib"],
+    }),
+)
+```
+
+This makes it easier to manage the dependency. But it still causes unnecessary
+duplication.
+
+For more direct support, use one of the following:
+
+### `selects.with_or` {#selects-with-or}
+
+The
+[with_or](https://github.com/bazelbuild/bazel-skylib/blob/main/docs/selects_doc.md#selectswith_or)
+macro in [Skylib](https://github.com/bazelbuild/bazel-skylib)'s
+[`selects`](https://github.com/bazelbuild/bazel-skylib/blob/main/docs/selects_doc.md)
+module supports `OR`ing conditions directly inside a `select`:
+
+```python
+load("@bazel_skylib//lib:selects.bzl", "selects")
+```
+
+```python
+sh_binary(
+    name = "my_target",
+    srcs = ["always_include.sh"],
+    deps = selects.with_or({
+        (":config1", ":config2", ":config3"): [":standard_lib"],
+        ":config4": [":special_lib"],
+    }),
+)
+```
+
+### `selects.config_setting_group` {#selects-config-setting-or-group}
+
+The
+[config_setting_group](https://github.com/bazelbuild/bazel-skylib/blob/main/docs/selects_doc.md#selectsconfig_setting_group)
+macro in [Skylib](https://github.com/bazelbuild/bazel-skylib)'s
+[`selects`](https://github.com/bazelbuild/bazel-skylib/blob/main/docs/selects_doc.md)
+module supports `OR`ing multiple `config_setting`s:
+
+```python
+load("@bazel_skylib//lib:selects.bzl", "selects")
+```
+
+```python
+config_setting(
+    name = "config1",
+    values = {"cpu": "arm"},
+)
+config_setting(
+    name = "config2",
+    values = {"compilation_mode": "dbg"},
+)
+selects.config_setting_group(
+    name = "config1_or_2",
+    match_any = [":config1", ":config2"],
+)
+sh_binary(
+    name = "my_target",
+    srcs = ["always_include.sh"],
+    deps = select({
+        ":config1_or_2": [":standard_lib"],
+        "//conditions:default": [":other_lib"],
+    }),
+)
+```
+
+Unlike `selects.with_or`, different targets can share `:config1_or_2` across
+different attributes.
+
+It's an error for multiple conditions to match unless one is an unambiguous
+"specialization" of the others or they all resolve to the same value. See [here](#configurable-build-example) for details.
+
+## AND chaining {#and-chaining}
+
+If you need a `select` branch to match when multiple conditions match, use the
+[Skylib](https://github.com/bazelbuild/bazel-skylib) macro
+[config_setting_group](https://github.com/bazelbuild/bazel-skylib/blob/main/docs/selects_doc.md#selectsconfig_setting_group):
+
+```python
+config_setting(
+    name = "config1",
+    values = {"cpu": "arm"},
+)
+config_setting(
+    name = "config2",
+    values = {"compilation_mode": "dbg"},
+)
+selects.config_setting_group(
+    name = "config1_and_2",
+    match_all = [":config1", ":config2"],
+)
+sh_binary(
+    name = "my_target",
+    srcs = ["always_include.sh"],
+    deps = select({
+        ":config1_and_2": [":standard_lib"],
+        "//conditions:default": [":other_lib"],
+    }),
+)
+```
+
+Unlike OR chaining, existing `config_setting`s can't be directly `AND`ed
+inside a `select`. You have to explicitly wrap them in a `config_setting_group`.
+
+## Custom error messages {#custom-error-messages}
+
+By default, when no condition matches, the target the `select()` is attached to
+fails with the error:
+
+```sh
+ERROR: Configurable attribute "deps" doesn't match this configuration (would
+a default condition help?).
+Conditions checked:
+  //tools/cc_target_os:darwin
+  //tools/cc_target_os:android
+```
+
+This can be customized with the [`no_match_error`](/versions/9.1.0/reference/be/functions#select)
+attribute:
+
+```python
+cc_library(
+    name = "my_lib",
+    deps = select(
+        {
+            "//tools/cc_target_os:android": [":android_deps"],
+            "//tools/cc_target_os:windows": [":windows_deps"],
+        },
+        no_match_error = "Please build with an Android or Windows toolchain",
+    ),
+)
+```
+
+```sh
+$ bazel build //myapp:my_lib
+ERROR: Configurable attribute "deps" doesn't match this configuration: Please
+build with an Android or Windows toolchain
+```
+
+## Rules compatibility {#rules-compatibility}
+
+Rule implementations receive the *resolved values* of configurable
+attributes. For example, given:
+
+```python
+# myapp/BUILD
+
+some_rule(
+    name = "my_target",
+    some_attr = select({
+        ":foo_mode": [":foo"],
+        ":bar_mode": [":bar"],
+    }),
+)
+```
+
+```sh
+$ bazel build //myapp/my_target --define mode=foo
+```
+
+Rule implementation code sees `ctx.attr.some_attr` as `[":foo"]`.
+
+Macros can accept `select()` clauses and pass them through to native
+rules. But *they cannot directly manipulate them*. For example, there's no way
+for a macro to convert
+
+```python
+select({"foo": "val"}, ...)
+```
+
+to
+
+```python
+select({"foo": "val_with_suffix"}, ...)
+```
+
+This is for two reasons.
+
+First, macros that need to know which path a `select` will choose *cannot work*
+because macros are evaluated in Bazel's [loading phase](/versions/9.1.0/run/build#loading),
+which occurs before flag values are known.
+This is a core Bazel design restriction that's unlikely to change any time soon.
+
+Second, macros that just need to iterate over *all* `select` paths, while
+technically feasible, lack a coherent UI. Further design is necessary to change
+this.
+
+## Bazel query and cquery {#query-and-cquery}
+
+Bazel [`query`](/versions/9.1.0/query/guide) operates over Bazel's
+[loading phase](/versions/9.1.0/reference/glossary#loading-phase).
+This means it doesn't know what command line flags a target uses since those
+flags aren't evaluated until later in the build (in the
+[analysis phase](/versions/9.1.0/reference/glossary#analysis-phase)).
+So it can't determine which `select()` branches are chosen.
+
+Bazel [`cquery`](/versions/9.1.0/query/cquery) operates after Bazel's analysis phase, so it has
+all this information and can accurately resolve `select()`s.
+
+Consider:
+
+```python
+load("@bazel_skylib//rules:common_settings.bzl", "string_flag")
+```
+```python
+# myapp/BUILD
+
+string_flag(
+    name = "dog_type",
+    build_setting_default = "cat"
+)
+
+cc_library(
+    name = "my_lib",
+    deps = select({
+        ":long": [":foo_dep"],
+        ":short": [":bar_dep"],
+    }),
+)
+
+config_setting(
+    name = "long",
+    flag_values = {":dog_type": "dachshund"},
+)
+
+config_setting(
+    name = "short",
+    flag_values = {":dog_type": "pug"},
+)
+```
+
+`query` overapproximates `:my_lib`'s dependencies:
+
+```sh
+$ bazel query 'deps(//myapp:my_lib)'
+//myapp:my_lib
+//myapp:foo_dep
+//myapp:bar_dep
+```
+
+while `cquery` shows its exact dependencies:
+
+```sh
+$ bazel cquery 'deps(//myapp:my_lib)' --//myapp:dog_type=pug
+//myapp:my_lib
+//myapp:bar_dep
+```
+
+## FAQ {#faq}
+
+### Why doesn't select() work in macros? {#faq-select-macro}
+
+select() *does* work in rules! See [Rules compatibility](#rules-compatibility) for
+details.
+
+The key issue this question usually means is that select() doesn't work in
+*macros*. These are different than *rules*. See the
+documentation on [rules](/versions/9.1.0/extending/rules) and [macros](/versions/9.1.0/extending/macros)
+to understand the difference.
+Here's an end-to-end example:
+
+Define a rule and macro:
+
+```python
+# myapp/defs.bzl
+
+# Rule implementation: when an attribute is read, all select()s have already
+# been resolved. So it looks like a plain old attribute just like any other.
+def _impl(ctx):
+    name = ctx.attr.name
+    allcaps = ctx.attr.my_config_string.upper()  # This works fine on all values.
+    print("My name is " + name + " with custom message: " + allcaps)
+
+# Rule declaration:
+my_custom_bazel_rule = rule(
+    implementation = _impl,
+    attrs = {"my_config_string": attr.string()},
+)
+
+# Macro declaration:
+def my_custom_bazel_macro(name, my_config_string):
+    allcaps = my_config_string.upper()  # This line won't work with select(s).
+    print("My name is " + name + " with custom message: " + allcaps)
+```
+
+Instantiate the rule and macro:
+
+```python
+# myapp/BUILD
+
+load("//myapp:defs.bzl", "my_custom_bazel_rule")
+load("//myapp:defs.bzl", "my_custom_bazel_macro")
+
+my_custom_bazel_rule(
+    name = "happy_rule",
+    my_config_string = select({
+        "//third_party/bazel_platforms/cpu:x86_32": "first string",
+        "//third_party/bazel_platforms/cpu:ppc": "second string",
+    }),
+)
+
+my_custom_bazel_macro(
+    name = "happy_macro",
+    my_config_string = "fixed string",
+)
+
+my_custom_bazel_macro(
+    name = "sad_macro",
+    my_config_string = select({
+        "//third_party/bazel_platforms/cpu:x86_32": "first string",
+        "//third_party/bazel_platforms/cpu:ppc": "other string",
+    }),
+)
+```
+
+Building fails because `sad_macro` can't process the `select()`:
+
+```sh
+$ bazel build //myapp:all
+ERROR: /myworkspace/myapp/BUILD:17:1: Traceback
+  (most recent call last):
+File "/myworkspace/myapp/BUILD", line 17
+my_custom_bazel_macro(name = "sad_macro", my_config_stri..."}))
+File "/myworkspace/myapp/defs.bzl", line 4, in
+  my_custom_bazel_macro
+my_config_string.upper()
+type 'select' has no method upper().
+ERROR: error loading package 'myapp': Package 'myapp' contains errors.
+```
+
+Building succeeds when you comment out `sad_macro`:
+
+```sh
+# Comment out sad_macro so it doesn't mess up the build.
+$ bazel build //myapp:all
+DEBUG: /myworkspace/myapp/defs.bzl:5:3: My name is happy_macro with custom message: FIXED STRING.
+DEBUG: /myworkspace/myapp/hi.bzl:15:3: My name is happy_rule with custom message: FIRST STRING.
+```
+
+This is impossible to change because *by definition* macros are evaluated before
+Bazel reads the build's command line flags. That means there isn't enough
+information to evaluate select()s.
+
+Macros can, however, pass `select()`s as opaque blobs to rules:
+
+```python
+# myapp/defs.bzl
+
+def my_custom_bazel_macro(name, my_config_string):
+    print("Invoking macro " + name)
+    my_custom_bazel_rule(
+        name = name + "_as_target",
+        my_config_string = my_config_string,
+    )
+```
+
+```sh
+$ bazel build //myapp:sad_macro_less_sad
+DEBUG: /myworkspace/myapp/defs.bzl:23:3: Invoking macro sad_macro_less_sad.
+DEBUG: /myworkspace/myapp/defs.bzl:15:3: My name is sad_macro_less_sad with custom message: FIRST STRING.
+```
+
+### Why does select() always return true? {#faq-boolean-select}
+
+Because *macros* (but not rules) by definition
+[can't evaluate `select()`s](#faq-select-macro), any attempt to do so
+usually produces an error:
+
+```sh
+ERROR: /myworkspace/myapp/BUILD:17:1: Traceback
+  (most recent call last):
+File "/myworkspace/myapp/BUILD", line 17
+my_custom_bazel_macro(name = "sad_macro", my_config_stri..."}))
+File "/myworkspace/myapp/defs.bzl", line 4, in
+  my_custom_bazel_macro
+my_config_string.upper()
+type 'select' has no method upper().
+```
+
+Booleans are a special case that fail silently, so you should be particularly
+vigilant with them:
+
+```sh
+$ cat myapp/defs.bzl
+def my_boolean_macro(boolval):
+  print("TRUE" if boolval else "FALSE")
+
+$ cat myapp/BUILD
+load("//myapp:defs.bzl", "my_boolean_macro")
+my_boolean_macro(
+    boolval = select({
+        "//third_party/bazel_platforms/cpu:x86_32": True,
+        "//third_party/bazel_platforms/cpu:ppc": False,
+    }),
+)
+
+$ bazel build //myapp:all --cpu=x86
+DEBUG: /myworkspace/myapp/defs.bzl:4:3: TRUE.
+$ bazel build //mypro:all --cpu=ppc
+DEBUG: /myworkspace/myapp/defs.bzl:4:3: TRUE.
+```
+
+This happens because macros don't understand the contents of `select()`.
+So what they're really evaluting is the `select()` object itself. According to
+[Pythonic](https://docs.python.org/release/2.5.2/lib/truth.html) design
+standards, all objects aside from a very small number of exceptions
+automatically return true.
+
+### Can I read select() like a dict? {#faq-inspectable-select}
+
+Macros [can't](#faq-select-macro) evaluate select(s) because macros evaluate before
+Bazel knows what the build's command line parameters are. Can they at least read
+the `select()`'s dictionary to, for example, add a suffix to each value?
+
+Conceptually this is possible, but it isn't yet a Bazel feature.
+What you *can* do today is prepare a straight dictionary, then feed it into a
+`select()`:
+
+```sh
+$ cat myapp/defs.bzl
+def selecty_genrule(name, select_cmd):
+  for key in select_cmd.keys():
+    select_cmd[key] += " WITH SUFFIX"
+  native.genrule(
+      name = name,
+      outs = [name + ".out"],
+      srcs = [],
+      cmd = "echo " + select(select_cmd + {"//conditions:default": "default"})
+        + " > $@"
+  )
+
+$ cat myapp/BUILD
+selecty_genrule(
+    name = "selecty",
+    select_cmd = {
+        "//third_party/bazel_platforms/cpu:x86_32": "x86 mode",
+    },
+)
+
+$ bazel build //testapp:selecty --cpu=x86 && cat bazel-genfiles/testapp/selecty.out
+x86 mode WITH SUFFIX
+```
+
+If you'd like to support both `select()` and native types, you can do this:
+
+```sh
+$ cat myapp/defs.bzl
+def selecty_genrule(name, select_cmd):
+    cmd_suffix = ""
+    if type(select_cmd) == "string":
+        cmd_suffix = select_cmd + " WITH SUFFIX"
+    elif type(select_cmd) == "dict":
+        for key in select_cmd.keys():
+            select_cmd[key] += " WITH SUFFIX"
+        cmd_suffix = select(select_cmd + {"//conditions:default": "default"})
+
+    native.genrule(
+        name = name,
+        outs = [name + ".out"],
+        srcs = [],
+        cmd = "echo " + cmd_suffix + "> $@",
+    )
+```
+
+### Why doesn't select() work with bind()? {#faq-select-bind}
+
+First of all, do not use `bind()`. It is deprecated in favor of `alias()`.
+
+The technical answer is that [`bind()`](/versions/9.1.0/reference/be/workspace#bind) is a repo
+rule, not a BUILD rule.
+
+Repo rules do not have a specific configuration, and aren't evaluated in
+the same way as BUILD rules. Therefore, a `select()` in a `bind()` can't
+actually evaluate to any specific branch.
+
+Instead, you should use [`alias()`](/versions/9.1.0/reference/be/general#alias), with a `select()` in
+the `actual` attribute, to perform this type of run-time determination. This
+works correctly, since `alias()` is a BUILD rule, and is evaluated with a
+specific configuration.
+
+```sh
+$ cat WORKSPACE
+workspace(name = "myapp")
+bind(name = "openssl", actual = "//:ssl")
+http_archive(name = "alternative", ...)
+http_archive(name = "boringssl", ...)
+
+$ cat BUILD
+config_setting(
+    name = "alt_ssl",
+    define_values = {
+        "ssl_library": "alternative",
+    },
+)
+
+alias(
+    name = "ssl",
+    actual = select({
+        "//:alt_ssl": "@alternative//:ssl",
+        "//conditions:default": "@boringssl//:ssl",
+    }),
+)
+```
+
+With this setup, you can pass `--define ssl_library=alternative`, and any target
+that depends on either `//:ssl` or `//external:ssl` will see the alternative
+located at `@alternative//:ssl`.
+
+But really, stop using `bind()`.
+
+### Why doesn't my select() choose what I expect? {#faq-select-choose-condition}
+
+If `//myapp:foo` has a `select()` that doesn't choose the condition you expect,
+use [cquery](/versions/9.1.0/query/cquery) and `bazel config` to debug:
+
+If `//myapp:foo` is the top-level target you're building, run:
+
+```sh
+$ bazel cquery //myapp:foo 
+//myapp:foo (12e23b9a2b534a)
+```
+
+If you're building some other target `//bar` that depends on
+//myapp:foo somewhere in its subgraph, run:
+
+```sh
+$ bazel cquery 'somepath(//bar, //myapp:foo)' 
+//bar:bar   (3ag3193fee94a2)
+//bar:intermediate_dep (12e23b9a2b534a)
+//myapp:foo (12e23b9a2b534a)
+```
+
+The `(12e23b9a2b534a)` next to `//myapp:foo` is a *hash* of the
+configuration that resolves `//myapp:foo`'s `select()`. You can inspect its
+values with `bazel config`:
+
+```sh
+$ bazel config 12e23b9a2b534a
+BuildConfigurationValue 12e23b9a2b534a
+Fragment com.google.devtools.build.lib.analysis.config.CoreOptions {
+  cpu: darwin
+  compilation_mode: fastbuild
+  ...
+}
+Fragment com.google.devtools.build.lib.rules.cpp.CppOptions {
+  linkopt: [-Dfoo=bar]
+  ...
+}
+...
+```
+
+Then compare this output against the settings expected by each `config_setting`.
+
+`//myapp:foo` may exist in different configurations in the same build. See the
+[cquery docs](/versions/9.1.0/query/cquery) for guidance on using `somepath` to get the right
+one.
+
+Caution: To prevent restarting the Bazel server, invoke `bazel config` with the
+same command line flags as the `bazel cquery`. The `config` command relies on
+the configuration nodes from the still-running server of the previous command.
+
+### Why doesn't `select()` work with platforms? {#faq-select-platforms}
+
+Bazel doesn't support configurable attributes checking whether a given platform
+is the target platform because the semantics are unclear.
+
+For example:
+
+```py
+platform(
+    name = "x86_linux_platform",
+    constraint_values = [
+        "@platforms//cpu:x86",
+        "@platforms//os:linux",
+    ],
+)
+
+cc_library(
+    name = "lib",
+    srcs = [...],
+    linkopts = select({
+        ":x86_linux_platform": ["--enable_x86_optimizations"],
+        "//conditions:default": [],
+    }),
+)
+```
+
+In this `BUILD` file, which `select()` should be used if the target platform has both the
+`@platforms//cpu:x86` and `@platforms//os:linux` constraints, but is **not** the
+`:x86_linux_platform` defined here? The author of the `BUILD` file and the user
+who defined the separate platform may have different ideas.
+
+#### What should I do instead?
+
+Instead, define a `config_setting` that matches **any** platform with
+these constraints:
+
+```py
+config_setting(
+    name = "is_x86_linux",
+    constraint_values = [
+        "@platforms//cpu:x86",
+        "@platforms//os:linux",
+    ],
+)
+
+cc_library(
+    name = "lib",
+    srcs = [...],
+    linkopts = select({
+        ":is_x86_linux": ["--enable_x86_optimizations"],
+        "//conditions:default": [],
+    }),
+)
+```
+
+This process defines specific semantics, making it clearer to users what
+platforms meet the desired conditions.
+
+#### What if I really, really want to `select` on the platform?
+
+If your build requirements specifically require checking the platform, you
+can flip the value of the `--platforms` flag in a `config_setting`:
+
+```py
+config_setting(
+    name = "is_specific_x86_linux_platform",
+    values = {
+        "platforms": ["//package:x86_linux_platform"],
+    },
+)
+
+cc_library(
+    name = "lib",
+    srcs = [...],
+    linkopts = select({
+        ":is_specific_x86_linux_platform": ["--enable_x86_optimizations"],
+        "//conditions:default": [],
+    }),
+)
+```
+
+The Bazel team doesn't endorse doing this; it overly constrains your build and
+confuses users when the expected condition does not match.
+
+[BuildSettings]: /extending/config#user-defined-build-settings
diff --git a/versions/9.1.0/configure/best-practices.mdx b/versions/9.1.0/configure/best-practices.mdx
new file mode 100644
index 00000000..9122c67e
--- /dev/null
+++ b/versions/9.1.0/configure/best-practices.mdx
@@ -0,0 +1,92 @@
+---
+title: 'Best Practices'
+---
+
+This page assumes you are familiar with Bazel and provides guidelines and
+advice on structuring your projects to take full advantage of Bazel's features.
+
+The overall goals are:
+
+- To use fine-grained dependencies to allow parallelism and incrementality.
+- To keep dependencies well-encapsulated.
+- To make code well-structured and testable.
+- To create a build configuration that is easy to understand and maintain.
+
+These guidelines are not requirements: few projects will be able to adhere to
+all of them.  As the man page for lint says, "A special reward will be presented
+to the first person to produce a real program that produces no errors with
+strict checking." However, incorporating as many of these principles as possible
+should make a project more readable, less error-prone, and faster to build.
+
+This page uses the requirement levels described in
+[this RFC](https://www.ietf.org/rfc/rfc2119.txt).
+
+## Running builds and tests {#running-builds-tests}
+
+A project should always be able to run `bazel build //...` and
+`bazel test //...` successfully on its stable branch. Targets that are necessary
+but do not build under certain circumstances (such as,require specific build
+flags, don't build on a certain platform, require license agreements) should be
+tagged as specifically as possible (for example, "`requires-osx`"). This
+tagging allows targets to be filtered at a more fine-grained level than the
+"manual" tag and allows someone inspecting the `BUILD` file to understand what
+a target's restrictions are.
+
+## Third-party dependencies {#third-party-dependencies}
+
+You may declare third-party dependencies:
+
+*   Either declare them as remote repositories in the `MODULE.bazel` file.
+*   Or put them in a directory called `third_party/` under your workspace directory.
+
+## Depending on binaries {#binaries}
+
+Everything should be built from source whenever possible. Generally this means
+that, instead of depending on a library `some-library.so`, you'd create a
+`BUILD` file and build `some-library.so` from its sources, then depend on that
+target.
+
+Always building from source ensures that a build is not using a library that
+was built with incompatible flags or a different architecture. There are also
+some features like coverage, static analysis, or dynamic analysis that only
+work on the source.
+
+## Versioning {#versioning}
+
+Prefer building all code from head whenever possible. When versions must be
+used, avoid including the version in the target name (for example, `//guava`,
+not `//guava-20.0`). This naming makes the library easier to update (only one
+target needs to be updated). It's also more resilient to diamond dependency
+issues: if one library depends on `guava-19.0` and one depends on `guava-20.0`,
+you could end up with a library that tries to depend on two different versions.
+If you created a misleading alias to point both targets to one `guava` library,
+then the `BUILD` files are misleading.
+
+## Using the `.bazelrc` file {#bazelrc-file}
+
+For project-specific options, use the configuration file your
+`WORKSPACE/.bazelrc` (see [bazelrc format](/versions/9.1.0/run/bazelrc)).
+
+If you want to support per-user options for your project that you **do not**
+want to check into source control, include the line:
+
+```
+try-import %workspace%/user.bazelrc
+```
+(or any other file name) in your `WORKSPACE/.bazelrc`
+and add `user.bazelrc` to your `.gitignore`.
+
+The open-source
+[bazelrc-preset.bzl](https://github.com/bazel-contrib/bazelrc-preset.bzl)
+
+generates a custom bazelrc file that matches your Bazel version and provides a
+preset of recommended flags.
+
+## Packages {#packages}
+
+Every directory that contains buildable files should be a package. If a `BUILD`
+file refers to files in subdirectories (such as, `srcs = ["a/b/C.java"]`) it's
+a sign that a `BUILD` file should be added to that subdirectory. The longer
+this structure exists, the more likely circular dependencies will be
+inadvertently created, a target's scope will creep, and an increasing number
+of reverse dependencies will have to be updated.
diff --git a/versions/9.1.0/configure/coverage.mdx b/versions/9.1.0/configure/coverage.mdx
new file mode 100644
index 00000000..ba9002e2
--- /dev/null
+++ b/versions/9.1.0/configure/coverage.mdx
@@ -0,0 +1,128 @@
+---
+title: 'Code coverage with Bazel'
+---
+
+Bazel features a `coverage` sub-command to produce code coverage
+reports on repositories that can be tested with `bazel coverage`. Due
+to the idiosyncrasies of the various language ecosystems, it is not
+always trivial to make this work for a given project.
+
+This page documents the general process for creating and viewing
+coverage reports, and also features some language-specific notes for
+languages whose configuration is well-known. It is best read by first
+reading [the general section](#creating-a-coverage-report), and then
+reading about the requirements for a specific language. Note also the
+[remote execution section](#remote-execution), which requires some
+additional considerations.
+
+While a lot of customization is possible, this document focuses on
+producing and consuming [`lcov`][lcov] reports, which is currently the
+most well-supported route.
+
+## Creating a coverage report {#creating-a-coverage-report}
+
+### Preparation
+
+The basic workflow for creating coverage reports requires the
+following:
+
+- A basic repository with test targets
+- A toolchain with the language-specific code coverage tools installed
+- A correct "instrumentation" configuration
+
+The former two are language-specific and mostly straightforward,
+however the latter can be more difficult for complex projects.
+
+"Instrumentation" in this case refers to the coverage tools that are
+used for a specific target. Bazel allows turning this on for a
+specific subset of files using the
+[`--instrumentation_filter`](/versions/9.1.0/reference/command-line-reference#flag--instrumentation_filter)
+flag, which specifies a filter for targets that are tested with the
+instrumentation enabled. To enable instrumentation for tests, the
+[`--instrument_test_targets`](/versions/9.1.0/reference/command-line-reference#flag--instrument_test_targets)
+flag is required.
+
+By default, bazel tries to match the target package(s), and prints the
+relevant filter as an `INFO` message.
+
+### Running coverage
+
+To produce a coverage report, use [`bazel coverage
+--combined_report=lcov
+[target]`](/versions/9.1.0/reference/command-line-reference#coverage). This runs the
+tests for the target, generating coverage reports in the lcov format
+for each file.
+
+Once finished, bazel runs an action that collects all the produced
+coverage files, and merges them into one, which is then finally
+created under `$(bazel info
+output_path)/_coverage/_coverage_report.dat`.
+
+Coverage reports are also produced if tests fail, though note that
+this does not extend to the failed tests - only passing tests are
+reported.
+
+### Viewing coverage
+
+The coverage report is only output in the non-human-readable `lcov`
+format. From this, we can use the `genhtml` utility (part of [the lcov
+project][lcov]) to produce a report that can be viewed in a web
+browser:
+
+```console
+genhtml --branch-coverage --output genhtml "$(bazel info output_path)/_coverage/_coverage_report.dat"
+```
+
+Note that `genhtml` reads the source code as well, to annotate missing
+coverage in these files. For this to work, it is expected that
+`genhtml` is executed in the root of the bazel project.
+
+To view the result, simply open the `index.html` file produced in the
+`genhtml` directory in any web browser.
+
+For further help and information around the `genhtml` tool, or the
+`lcov` coverage format, see [the lcov project][lcov].
+
+## Remote execution {#remote-execution}
+
+Running with remote test execution currently has a few caveats:
+
+- The report combination action cannot yet run remotely. This is
+  because Bazel does not consider the coverage output files as part of
+  its graph (see [this issue][remote_report_issue]), and can therefore
+  not correctly treat them as inputs to the combination action. To
+  work around this, use `--strategy=CoverageReport=local`.
+  - Note: It may be necessary to specify something like
+    `--strategy=CoverageReport=local,remote` instead, if Bazel is set
+    up to try `local,remote`, due to how Bazel resolves strategies.
+- `--remote_download_minimal` and similar flags can also not be used
+  as a consequence of the former.
+- Bazel will currently fail to create coverage information if tests
+  have been cached previously. To work around this,
+  `--nocache_test_results` can be set specifically for coverage runs,
+  although this of course incurs a heavy cost in terms of test times.
+- `--experimental_split_coverage_postprocessing` and
+  `--experimental_fetch_all_coverage_outputs`
+  - Usually coverage is run as part of the test action, and so by
+    default, we don't get all coverage back as outputs of the remote
+    execution by default. These flags override the default and obtain
+    the coverage data. See [this issue][split_coverage_issue] for more
+    details.
+
+## Language-specific configuration
+
+### Java
+
+Java should work out-of-the-box with the default configuration. The
+[bazel toolchains][bazel_toolchains] contain everything necessary for
+remote execution, as well, including JUnit.
+
+### Python
+
+See the [`rules_python` coverage docs](https://rules-python.readthedocs.io/en/latest/coverage.html)
+for additional steps needed to enable coverage support in Python.
+
+[lcov]: https://github.com/linux-test-project/lcov
+[bazel_toolchains]: https://github.com/bazelbuild/bazel-toolchains
+[remote_report_issue]: https://github.com/bazelbuild/bazel/issues/4685
+[split_coverage_issue]: https://github.com/bazelbuild/bazel/issues/4685
diff --git a/versions/9.1.0/configure/integrate-cpp.mdx b/versions/9.1.0/configure/integrate-cpp.mdx
new file mode 100644
index 00000000..2b892922
--- /dev/null
+++ b/versions/9.1.0/configure/integrate-cpp.mdx
@@ -0,0 +1,74 @@
+---
+title: 'Integrating with C++ Rules'
+---
+
+This page describes how to integrate with C++ rules on various levels.
+
+## Accessing the C++ toolchain {#access-c-toolchain}
+
+You should use the helper functions available at
+[`@rules_cc//cc:find_cc_toolchain.bzl`](https://github.com/bazelbuild/rules_cc/blob/main/cc/find_cc_toolchain.bzl)
+to depend on a CC toolchain from a Starlark rule.
+
+To depend on a C++ toolchain in your rule, set the `toolchains` parameter to
+`use_cc_toolchain()`. Then, in the rule implementation, use
+`find_cpp_toolchain(ctx)` to get the
+[`CcToolchainInfo`](/versions/9.1.0/rules/lib/providers/CcToolchainInfo). A complete working
+example can be found [in the rules_cc
+examples](https://github.com/bazelbuild/rules_cc/blob/main/examples/write_cc_toolchain_cpu/write_cc_toolchain_cpu.bzl).
+
+## Generating command lines and environment variables using the C++ toolchain {#generate-command-lines-toolchain}
+
+Typically, you would integrate with the C++ toolchain to have the same
+command line flags as C++ rules do, but without using C++ actions directly.
+This is because when writing our own actions, they must behave
+consistently with the C++ toolchain - for example, passing C++ command line
+flags to a tool that invokes the C++ compiler behind the scenes.
+
+C++ rules use a special way of constructing command lines based on [feature
+configuration](/versions/9.1.0/docs/cc-toolchain-config-reference). To construct a command line,
+you need the following:
+
+* `features` and `action_configs` - these come from the `CcToolchainConfigInfo`
+  and encapsulated in `CcToolchainInfo`
+* `FeatureConfiguration` - returned by [cc_common.configure_features](/versions/9.1.0/rules/lib/toplevel/cc_common#configure_features)
+* cc toolchain config variables - returned by
+  [cc_common.create_compile_variables](/versions/9.1.0/rules/lib/toplevel/cc_common#create_compile_variables)
+  or
+  [cc_common.create_link_variables](/versions/9.1.0/rules/lib/toplevel/cc_common#create_link_variables).
+
+There still are tool-specific getters, such as
+[compiler_executable](/versions/9.1.0/rules/lib/providers/CcToolchainInfo#compiler_executable).
+Prefer `get_tool_for_action` over these, as tool-specific getters will
+eventually be removed.
+
+A complete working example can be found
+[in the rules_cc examples](https://github.com/bazelbuild/rules_cc/blob/main/examples/my_c_compile/my_c_compile.bzl).
+
+## Implementing Starlark rules that depend on C++ rules and/or that C++ rules can depend on {#implement-starlark-rules}
+
+Most C++ rules provide
+[`CcInfo`](/versions/9.1.0/rules/lib/providers/CcInfo),
+a provider containing [`CompilationContext`](/versions/9.1.0/rules/lib/builtins/CompilationContext)
+and
+[`LinkingContext`](/versions/9.1.0/rules/lib/builtins/LinkingContext).
+Through these it is possible to access information such as all transitive headers
+or libraries to link. From `CcInfo` and from the `CcToolchainInfo` custom
+Starlark rules should be able to get all the information they need.
+
+If a custom Starlark rule provides `CcInfo`, it's a signal to the C++ rules that
+they can also depend on it. Be careful, however - if you only need to propagate
+`CcInfo` through the graph to the binary rule that then makes use of it, wrap
+`CcInfo` in a different provider. For example, if `java_library` rule wanted
+to propagate native dependencies up to the `java_binary`, it shouldn't provide
+`CcInfo` directly (`cc_binary` depending on `java_library` doesn't make sense),
+it should wrap it in, for example, `JavaCcInfo`.
+
+A complete working example can be found
+[in the rules_cc examples](https://github.com/bazelbuild/rules_cc/blob/main/examples/my_c_archive/my_c_archive.bzl).
+
+## Reusing logic and actions of C++ rules {#reuse-logic-c-rules}
+
+_Not stable yet; This section will be updated once the API stabilizes. Follow
+[#4570](https://github.com/bazelbuild/bazel/issues/4570) for up-to-date
+information._
diff --git a/versions/9.1.0/configure/windows.mdx b/versions/9.1.0/configure/windows.mdx
new file mode 100644
index 00000000..d95591f5
--- /dev/null
+++ b/versions/9.1.0/configure/windows.mdx
@@ -0,0 +1,313 @@
+---
+title: 'Using Bazel on Windows'
+---
+
+This page covers Best Practices for using Bazel on Windows. For installation
+instructions, see [Install Bazel on Windows](/versions/9.1.0/install/windows).
+
+## Known issues {#known-issues}
+
+Windows-related Bazel issues are marked with the "area-Windows" label on GitHub.
+[GitHub-Windows].
+
+[GitHub-Windows]: https://github.com/bazelbuild/bazel/issues?q=is%3Aopen+is%3Aissue+label%3Aarea-Windows
+
+## Best practices {#best-practices}
+
+### Avoid long path issues {#long-path-issues}
+
+Some tools have the [Maximum Path Length Limitation](https://docs.microsoft.com/en-us/windows/win32/fileio/naming-a-file#maximum-path-length-limitation) on Windows, including the MSVC compiler.
+To avoid hitting this issue, you can specify a short output directory for Bazel by the [\-\-output_user_root](/versions/9.1.0/reference/command-line-reference#flag--output_user_root) flag.
+
+For example, add the following line to your bazelrc file:
+
+```none
+startup --output_user_root=C:/tmp
+```
+
+### Enable symlink support {#symlink}
+
+Some features require Bazel to be able to create file symlinks on Windows,
+either by enabling
+[Developer Mode](https://docs.microsoft.com/en-us/windows/uwp/get-started/enable-your-device-for-development)
+(on Windows 10 version 1703 or newer), or by running Bazel as an administrator.
+This enables the following features:
+
+* [\-\-windows_enable_symlinks](/versions/9.1.0/reference/command-line-reference#flag--windows_enable_symlinks)
+* [\-\-enable_runfiles](/versions/9.1.0/reference/command-line-reference#flag--enable_runfiles)
+
+To make it easier, add the following lines to your bazelrc file:
+
+```none
+startup --windows_enable_symlinks
+
+build --enable_runfiles
+```
+
+**Note**: Creating symlinks on Windows is an expensive operation. The `--enable_runfiles` flag can potentially create a large amount of file symlinks. Only enable this feature when you need it.
+
+{/* TODO(pcloudy): https://github.com/bazelbuild/bazel/issues/6402
+                    Write a doc about runfiles library and add a link to it here */}
+
+### Running Bazel: MSYS2 shell vs. command prompt vs. PowerShell {#running-bazel-shells}
+
+**Recommendation:** Run Bazel from the command prompt (`cmd.exe`) or from
+PowerShell.
+
+As of 2020-01-15, **do not** run Bazel from `bash` -- either
+from MSYS2 shell, or Git Bash, or Cygwin, or any other Bash variant. While Bazel
+may work for most use cases, some things are broken, like
+[interrupting the build with Ctrl+C from MSYS2](https://github.com/bazelbuild/bazel/issues/10573)).
+Also, if you choose to run under MSYS2, you need to disable MSYS2's
+automatic path conversion, otherwise MSYS will convert command line arguments
+that _look like_ Unix paths (such as `//foo:bar`) into Windows paths. See
+[this StackOverflow answer](https://stackoverflow.com/a/49004265/7778502)
+for details.
+
+### Using Bazel without Bash (MSYS2) {#using-bazel-without-bash}
+
+#### Using bazel build without Bash {#bazel-build-without-bash}
+
+Bazel versions before 1.0 used to require Bash to build some rules.
+
+Starting with Bazel 1.0, you can build any rule without Bash unless it is a:
+
+- `genrule`, because genrules execute Bash commands
+- `sh_binary` or `sh_test` rule, because these inherently need Bash
+- Starlark rule that uses `ctx.actions.run_shell()` or `ctx.resolve_command()`
+
+However, `genrule` is often used for simple tasks like
+[copying a file](https://github.com/bazelbuild/bazel-skylib/blob/main/rules/copy_file.bzl)
+or [writing a text file](https://github.com/bazelbuild/bazel-skylib/blob/main/rules/write_file.bzl).
+Instead of using `genrule` (and depending on Bash) you may find a suitable rule
+in the
+[bazel-skylib repository](https://github.com/bazelbuild/bazel-skylib/tree/main/rules).
+When built on Windows, **these rules do not require Bash**.
+
+#### Using bazel test without Bash {#bazel-test-without-bash}
+
+Bazel versions before 1.0 used to require Bash to `bazel test` anything.
+
+Starting with Bazel 1.0, you can test any rule without Bash, except when:
+
+- you use `--run_under`
+- the test rule itself requires Bash (because its executable is a shell script)
+
+#### Using bazel run without Bash {#bazel-run-without-bash}
+
+Bazel versions before 1.0 used to require Bash to `bazel run` anything.
+
+Starting with Bazel 1.0, you can run any rule without Bash, except when:
+
+- you use `--run_under` or `--script_path`
+- the test rule itself requires Bash (because its executable is a shell script)
+
+#### Using sh\_binary and sh\_* rules, and ctx.actions.run_shell() without Bash {#sh-rules-without-bash}
+
+You need Bash to build and test `sh_*` rules, and to build and test Starlark
+rules that use `ctx.actions.run_shell()` and `ctx.resolve_command()`. This
+applies not only to rules in your project, but to rules in any of the external
+repositories your project depends on (even transitively).
+
+In the future, there may be an option to use Windows Subsystem for
+Linux (WSL) to build these rules, but currently it is not a priority for
+the Bazel-on-Windows subteam.
+
+### Setting environment variables {#set-environment-variables}
+
+Environment variables you set in the Windows Command Prompt (`cmd.exe`) are only
+set in that command prompt session. If you start a new `cmd.exe`, you need to
+set the variables again. To always set the variables when `cmd.exe` starts, you
+can add them to the User variables or System variables in the `Control Panel >
+System Properties > Advanced > Environment Variables...` dialog box.
+
+## Build on Windows {#using}
+
+### Build C++ with MSVC {#build_cpp}
+
+To build C++ targets with MSVC, you need:
+
+*   [The Visual C++ compiler](/versions/9.1.0/install/windows#install-vc).
+
+*   (Optional) The `BAZEL_VC` and `BAZEL_VC_FULL_VERSION` environment variable.
+
+    Bazel automatically detects the Visual C++ compiler on your system.
+    To tell Bazel to use a specific VC installation, you can set the
+    following environment variables:
+
+    For Visual Studio 2017 and 2019, set one of `BAZEL_VC`. Additionally you may also set `BAZEL_VC_FULL_VERSION`.
+
+    *   `BAZEL_VC` the Visual C++ Build Tools installation directory
+
+        ```
+        set BAZEL_VC=C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\VC
+        ```
+
+    *   `BAZEL_VC_FULL_VERSION` (Optional) Only for Visual Studio 2017 and 2019, the full version
+        number of your Visual C++ Build Tools. You can choose the exact Visual C++ Build Tools
+        version via `BAZEL_VC_FULL_VERSION` if more than one version are installed, otherwise Bazel
+        will choose the latest version.
+
+        ```
+        set BAZEL_VC_FULL_VERSION=14.16.27023
+        ```
+
+    For Visual Studio 2015 or older, set `BAZEL_VC`. (`BAZEL_VC_FULL_VERSION` is not supported.)
+
+    *   `BAZEL_VC` the Visual C++ Build Tools installation directory
+
+        ```
+        set BAZEL_VC=C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC
+        ```
+
+*   The [Windows
+    SDK](https://developer.microsoft.com/en-us/windows/downloads/windows-10-sdk).
+
+    The Windows SDK contains header files and libraries you need when building
+    Windows applications, including Bazel itself. By default, the latest Windows SDK installed will
+    be used. You also can specify Windows SDK version by setting `BAZEL_WINSDK_FULL_VERSION`. You
+    can use a full Windows 10 SDK number such as 10.0.10240.0, or specify 8.1 to use the Windows 8.1
+    SDK (only one version of Windows 8.1 SDK is available). Please make sure you have the specified
+    Windows SDK installed.
+
+    **Requirement**: This is supported with VC 2017 and 2019. The standalone VC 2015 Build Tools doesn't
+    support selecting Windows SDK, you'll need the full Visual Studio 2015 installation, otherwise
+    `BAZEL_WINSDK_FULL_VERSION` will be ignored.
+
+    ```
+    set BAZEL_WINSDK_FULL_VERSION=10.0.10240.0
+    ```
+
+If everything is set up, you can build a C++ target now!
+
+Try building a target from one of our [sample
+projects](https://github.com/bazelbuild/bazel/tree/master/examples):
+
+
+bazel build //examples/cpp:hello-world
+bazel-bin\examples\cpp\hello-world.exe
+

+
+By default, the built binaries target x64 architecture. To build for ARM64
+architecture, use
+
+```none
+--platforms=//:windows_arm64  --extra_toolchains=@local_config_cc//:cc-toolchain-arm64_windows
+```
+
+You can introduce `@local_config_cc` in `MODULE.bazel` with
+
+```python
+bazel_dep(name = "rules_cc", version = "0.1.1")
+cc_configure = use_extension("@rules_cc//cc:extensions.bzl", "cc_configure_extension")
+use_repo(cc_configure, "local_config_cc")
+```
+
+To build and use Dynamically Linked Libraries (DLL files), see [this
+example](https://github.com/bazelbuild/bazel/tree/master/examples/windows/dll).
+
+**Command Line Length Limit**: To prevent the
+[Windows command line length limit issue](https://github.com/bazelbuild/bazel/issues/5163),
+enable the compiler parameter file feature via `--features=compiler_param_file`.
+
+### Build C++ with Clang {#clang}
+
+From 0.29.0, Bazel supports building with LLVM's MSVC-compatible compiler driver (`clang-cl.exe`).
+
+**Requirement**: To build with Clang, you have to install **both**
+[LLVM](http://releases.llvm.org/download.html) and Visual C++ Build tools,
+because although you use `clang-cl.exe` as compiler, you still need to link to
+Visual C++ libraries.
+
+Bazel can automatically detect LLVM installation on your system, or you can explicitly tell
+Bazel where LLVM is installed by `BAZEL_LLVM`.
+
+*   `BAZEL_LLVM` the LLVM installation directory
+
+    ```posix-terminal
+    set BAZEL_LLVM=C:\Program Files\LLVM
+    ```
+
+To enable the Clang toolchain for building C++, there are several situations.
+
+* In Bazel 7.0.0 and newer: Add a platform target to your `BUILD file` (eg. the
+  top level `BUILD` file):
+
+    ```
+    platform(
+        name = "x64_windows-clang-cl",
+        constraint_values = [
+            "@platforms//cpu:x86_64",
+            "@platforms//os:windows",
+            "@bazel_tools//tools/cpp:clang-cl",
+        ],
+    )
+    ```
+
+    Then enable the Clang toolchain by specifying the following build flags:
+
+    ```
+    --extra_toolchains=@local_config_cc//:cc-toolchain-x64_windows-clang-cl --extra_execution_platforms=//:x64_windows-clang-cl
+    ```
+
+* In Bazel older than 7.0.0 but newer than 0.28: Enable the Clang toolchain by
+  a build flag `--compiler=clang-cl`.
+
+  If your build sets the flag
+  [\-\-incompatible_enable_cc_toolchain_resolution]
+  (https://github.com/bazelbuild/bazel/issues/7260)
+  to `true`, then use the approach for Bazel 7.0.0.
+
+* In Bazel 0.28 and older: Clang is not supported.
+
+### Build Java {#java}
+
+To build Java targets, you need:
+
+*   [The Java SE Development Kit](/versions/9.1.0/install/windows#install-jdk)
+
+On Windows, Bazel builds two output files for `java_binary` rules:
+
+*   a `.jar` file
+*   a `.exe` file that can set up the environment for the JVM and run the binary
+
+Try building a target from one of our [sample
+projects](https://github.com/bazelbuild/bazel/tree/master/examples):
+
+```
+C:\projects\bazel> bazel build //examples/java-native/src/main/java/com/example/myproject:hello-world
+C:\projects\bazel> bazel-bin\examples\java-native\src\main\java\com\example\myproject\hello-world.exe
+```
+
+### Build Python {#python}
+
+To build Python targets, you need:
+
+*   The [Python interpreter](/versions/9.1.0/install/windows#install-python)
+
+On Windows, Bazel builds two output files for `py_binary` rules:
+
+*   a self-extracting zip file
+*   an executable file that can launch the Python interpreter with the
+    self-extracting zip file as the argument
+
+You can either run the executable file (it has a `.exe` extension) or you can run
+Python with the self-extracting zip file as the argument.
+
+Try building a target from one of our [sample
+projects](https://github.com/bazelbuild/bazel/tree/master/examples):
+
+
+  bazel build //examples/py_native:bin
+  bazel-bin\examples\py_native\bin.exe
+  python bazel-bin\examples\py_native\bin.zip
+

+
+If you are interested in details about how Bazel builds Python targets on
+Windows, check out this [design
+doc](https://github.com/bazelbuild/bazel-website/blob/master/designs/_posts/2016-09-05-build-python-on-windows.md).
diff --git a/versions/9.1.0/contribute/breaking-changes.mdx b/versions/9.1.0/contribute/breaking-changes.mdx
new file mode 100644
index 00000000..c6021d9e
--- /dev/null
+++ b/versions/9.1.0/contribute/breaking-changes.mdx
@@ -0,0 +1,145 @@
+---
+title: 'Guide for rolling out breaking changes'
+---
+
+It is inevitable that we will make breaking changes to Bazel. We will have to
+change our designs and fix the things that do not quite work. However, we need
+to make sure that community and Bazel ecosystem can follow along. To that end,
+Bazel project has adopted a
+[backward compatibility policy](/versions/9.1.0/release/backward-compatibility).
+This document describes the process for Bazel contributors to make a breaking
+change in Bazel to adhere to this policy.
+
+1. Follow the [design document policy](/versions/9.1.0/contribute/design-documents).
+
+1. [File a GitHub issue.](#github-issue)
+
+1. [Implement the change.](#implementation)
+
+1. [Update labels.](#labels)
+
+1. [Update repositories.](#update-repos)
+
+1. [Flip the incompatible flag.](#flip-flag)
+
+## GitHub issue {#github-issue}
+
+[File a GitHub issue](https://github.com/bazelbuild/bazel/issues)
+in the Bazel repository.
+[See example.](https://github.com/bazelbuild/bazel/issues/6611)
+
+We recommend that:
+
+* The title starts with the name of the flag (the flag name will start with
+  `incompatible_`).
+
+* You add the label
+  [`incompatible-change`](https://github.com/bazelbuild/bazel/labels/incompatible-change).
+
+* The description contains a description of the change and a link to relevant
+  design documents.
+
+* The description contains a migration recipe, to explain users how they should
+  update their code. Ideally, when the change is mechanical, include a link to a
+  migration tool.
+
+* The description includes an example of the error message users will get if
+  they don't migrate. This will make the GitHub issue more discoverable from
+  search engines. Make sure that the error message is helpful and actionable.
+  When possible, the error message should include the name of the incompatible
+  flag.
+
+For the migration tool, consider contributing to
+[Buildifier](https://github.com/bazelbuild/buildtools/blob/master/buildifier/README.md).
+It is able to apply automated fixes to `BUILD`, `WORKSPACE`, and `.bzl` files.
+It may also report warnings.
+
+## Implementation {#implementation}
+
+Create a new flag in Bazel. The default value must be false. The help text
+should contain the URL of the GitHub issue. As the flag name starts with
+`incompatible_`, it needs metadata tags:
+
+```java
+      metadataTags = {
+        OptionMetadataTag.INCOMPATIBLE_CHANGE,
+      },
+```
+
+In the commit description, add a brief summary of the flag.
+Also add [`RELNOTES:`](/versions/9.1.0/contribute/release-notes) in the following form:
+`RELNOTES: --incompatible_name_of_flag has been added. See #xyz for details`
+
+The commit should also update the relevant documentation, so that there is no
+window of commits in which the code is inconsistent with the docs. Since our
+documentation is versioned, changes to the docs will not be inadvertently
+released prematurely.
+
+## Labels {#labels}
+
+Once the commit is merged and the incompatible change is ready to be adopted, add the label
+[`migration-ready`](https://github.com/bazelbuild/bazel/labels/migration-ready)
+to the GitHub issue.
+
+If a problem is found with the flag and users are not expected to migrate yet:
+remove the flags `migration-ready`.
+
+If you plan to flip the flag in the next major release, add label `breaking-change-X.0" to the issue.
+
+## Updating repositories {#update-repos}
+
+Bazel CI tests a list of important projects at
+[Bazel@HEAD + Downstream](https://buildkite.com/bazel/bazel-at-head-plus-downstream). Most of them are often
+dependencies of other Bazel projects, therefore it's important to migrate them to unblock the migration for the broader community. To monitor the migration status of those projects, you can use the [`bazelisk-plus-incompatible-flags` pipeline](https://buildkite.com/bazel/bazelisk-plus-incompatible-flags).
+Check how this pipeline works [here](https://github.com/bazelbuild/continuous-integration/tree/master/buildkite#checking-incompatible-changes-status-for-downstream-projects).
+
+Our dev support team monitors the [`migration-ready`](https://github.com/bazelbuild/bazel/labels/migration-ready) label. Once you add this label to the GitHub issue, they will handle the following:
+
+1. Create a comment in the GitHub issue to track the list of failures and downstream projects that need to be migrated ([see example](https://github.com/bazelbuild/bazel/issues/17032#issuecomment-1353077469))
+
+1. File Github issues to notify the owners of every downstream project broken by your incompatible change ([see example](https://github.com/bazelbuild/intellij/issues/4208))
+
+1. Follow up to make sure all issues are addressed before the target release date
+
+Migrating projects in the downstream pipeline is NOT entirely the responsibility of the incompatible change author, but you can do the following to accelerate the migration and make life easier for both Bazel users and the Bazel Green Team.
+
+1. Send PRs to fix downstream projects.
+
+1. Reach out to the Bazel community for help on migration (e.g. [Bazel Rules Authors SIG](https://bazel-contrib.github.io/SIG-rules-authors/)).
+
+## Flipping the flag {#flip-flag}
+
+Before flipping the default value of the flag to true, please make sure that:
+
+* Core repositories in the ecosystem are migrated.
+
+    On the [`bazelisk-plus-incompatible-flags` pipeline](https://buildkite.com/bazel/bazelisk-plus-incompatible-flags),
+    the flag should appear under `The following flags didn't break any passing Bazel team owned/co-owned projects`.
+
+* All issues in the checklist are marked as fixed/closed.
+
+* User concerns and questions have been resolved.
+
+When the flag is ready to flip in Bazel, but blocked on internal migration at Google, please consider setting the flag value to false in the internal `blazerc` file to unblock the flag flip. By doing this, we can ensure Bazel users depend on the new behaviour by default as early as possible.
+
+When changing the flag default to true, please:
+
+* Use `RELNOTES[INC]` in the commit description, with the
+    following format:
+    `RELNOTES[INC]: --incompatible_name_of_flag is flipped to true. See #xyz for
+    details`
+    You can include additional information in the rest of the commit description.
+* Use `Fixes #xyz` in the description, so that the GitHub issue gets closed
+    when the commit is merged.
+* Review and update documentation if needed.
+* File a new issue `#abc` to track the removal of the flag.
+
+## Removing the flag {#remove-flag}
+
+After the flag is flipped at HEAD, it should be removed from Bazel eventually.
+When you plan to remove the incompatible flag:
+
+* Consider leaving more time for users to migrate if it's a major incompatible change.
+  Ideally, the flag  should be available in at least one major release.
+* For the commit that removes the flag, use `Fixes #abc` in the description
+  so that the GitHub issue gets closed when the commit is merged.
diff --git a/versions/9.1.0/contribute/codebase.mdx b/versions/9.1.0/contribute/codebase.mdx
new file mode 100644
index 00000000..7086b4b1
--- /dev/null
+++ b/versions/9.1.0/contribute/codebase.mdx
@@ -0,0 +1,1661 @@
+---
+title: 'The Bazel codebase'
+---
+
+This document is a description of the codebase and how Bazel is structured. It
+is intended for people willing to contribute to Bazel, not for end-users.
+
+## Introduction {#introduction}
+
+The codebase of Bazel is large (~350KLOC production code and ~260 KLOC test
+code) and no one is familiar with the whole landscape: everyone knows their
+particular valley very well, but few know what lies over the hills in every
+direction.
+
+In order for people midway upon the journey not to find themselves within a
+forest dark with the straightforward pathway being lost, this document tries to
+give an overview of the codebase so that it's easier to get started with
+working on it.
+
+The public version of the source code of Bazel lives on GitHub at
+[github.com/bazelbuild/bazel](http://github.com/bazelbuild/bazel). This is not
+the "source of truth"; it's derived from a Google-internal source tree that
+contains additional functionality that is not useful outside Google. The
+long-term goal is to make GitHub the source of truth.
+
+Contributions are accepted through the regular GitHub pull request mechanism,
+and manually imported by a Googler into the internal source tree, then
+re-exported back out to GitHub.
+
+## Client/server architecture {#client-architecture}
+
+The bulk of Bazel resides in a server process that stays in RAM between builds.
+This allows Bazel to maintain state between builds.
+
+This is why the Bazel command line has two kinds of options: startup and
+command. In a command line like this:
+
+```
+    bazel --host_jvm_args=-Xmx8G build -c opt //foo:bar
+```
+
+Some options (`--host_jvm_args=`) are before the name of the command to be run
+and some are after (`-c opt`); the former kind is called a "startup option" and
+affects the server process as a whole, whereas the latter kind, the "command
+option", only affects a single command.
+
+Each server instance has a single associated workspace (collection of source
+trees known as "repositories") and each workspace usually has a single active
+server instance. This can be circumvented by specifying a custom output base
+(see the "Directory layout" section for more information).
+
+Bazel is distributed as a single ELF executable that is also a valid .zip file.
+When you type `bazel`, the above ELF executable implemented in C++ (the
+"client") gets control. It sets up an appropriate server process using the
+following steps:
+
+1.  Checks whether it has already extracted itself. If not, it does that. This
+    is where the implementation of the server comes from.
+2.  Checks whether there is an active server instance that works: it is running,
+    it has the right startup options and uses the right workspace directory. It
+    finds the running server by looking at the directory `$OUTPUT_BASE/server`
+    where there is a lock file with the port the server is listening on.
+3.  If needed, kills the old server process
+4.  If needed, starts up a new server process
+
+After a suitable server process is ready, the command that needs to be run is
+communicated to it over a gRPC interface, then the output of Bazel is piped back
+to the terminal. Only one command can be running at the same time. This is
+implemented using an elaborate locking mechanism with parts in C++ and parts in
+Java. There is some infrastructure for running multiple commands in parallel,
+since the inability to run `bazel version` in parallel with another command
+is somewhat embarrassing. The main blocker is the life cycle of `BlazeModule`s
+and some state in `BlazeRuntime`.
+
+At the end of a command, the Bazel server transmits the exit code the client
+should return. An interesting wrinkle is the implementation of `bazel run`: the
+job of this command is to run something Bazel just built, but it can't do that
+from the server process because it doesn't have a terminal. So instead it tells
+the client what binary it should `exec()` and with what arguments.
+
+When one presses Ctrl-C, the client translates it to a Cancel call on the gRPC
+connection, which tries to terminate the command as soon as possible. After the
+third Ctrl-C, the client sends a SIGKILL to the server instead.
+
+The source code of the client is under `src/main/cpp` and the protocol used to
+communicate with the server is in `src/main/protobuf/command_server.proto` .
+
+The main entry point of the server is `BlazeRuntime.main()` and the gRPC calls
+from the client are handled by `GrpcServerImpl.run()`.
+
+## Directory layout {#directory-layout}
+
+Bazel creates a somewhat complicated set of directories during a build. A full
+description is available in [Output directory layout](/versions/9.1.0/remote/output-directories).
+
+The "main repo" is the source tree Bazel is run in. It usually corresponds to
+something you checked out from source control. The root of this directory is
+known as the "workspace root".
+
+Bazel puts all of its data under the "output user root". This is usually
+`$HOME/.cache/bazel/_bazel_${USER}`, but can be overridden using the
+`--output_user_root` startup option.
+
+The "install base" is where Bazel is extracted to. This is done automatically
+and each Bazel version gets a subdirectory based on its checksum under the
+install base. It's at `$OUTPUT_USER_ROOT/install` by default and can be changed
+using the `--install_base` command line option.
+
+The "output base" is the place where the Bazel instance attached to a specific
+workspace writes to. Each output base has at most one Bazel server instance
+running at any time. It's usually at `$OUTPUT_USER_ROOT/`. It can be changed using the `--output_base` startup option,
+which is, among other things, useful for getting around the limitation that only
+one Bazel instance can be running in any workspace at any given time.
+
+The output directory contains, among other things:
+
+*   The fetched external repositories at `$OUTPUT_BASE/external`.
+*   The exec root, a directory that contains symlinks to all the source
+    code for the current build. It's located at `$OUTPUT_BASE/execroot`. During
+    the build, the working directory is `$EXECROOT/`. We are planning to change this to `$EXECROOT`, although it's a
+    long term plan because it's a very incompatible change.
+*   Files built during the build.
+
+## The process of executing a command {#command-process}
+
+Once the Bazel server gets control and is informed about a command it needs to
+execute, the following sequence of events happens:
+
+1.  `BlazeCommandDispatcher` is informed about the new request. It decides
+    whether the command needs a workspace to run in (almost every command except
+    for ones that don't have anything to do with source code, such as version or
+    help) and whether another command is running.
+
+2.  The right command is found. Each command must implement the interface
+    `BlazeCommand` and must have the `@Command` annotation (this is a bit of an
+    antipattern, it would be nice if all the metadata a command needs was
+    described by methods on `BlazeCommand`)
+
+3.  The command line options are parsed. Each command has different command line
+    options, which are described in the `@Command` annotation.
+
+4.  An event bus is created. The event bus is a stream for events that happen
+    during the build. Some of these are exported to outside of Bazel under the
+    aegis of the Build Event Protocol in order to tell the world how the build
+    goes.
+
+5.  The command gets control. The most interesting commands are those that run a
+    build: build, test, run, coverage and so on: this functionality is
+    implemented by `BuildTool`.
+
+6.  The set of target patterns on the command line is parsed and wildcards like
+    `//pkg:all` and `//pkg/...` are resolved. This is implemented in
+    `AnalysisPhaseRunner.evaluateTargetPatterns()` and reified in Skyframe as
+    `TargetPatternPhaseValue`.
+
+7.  The loading/analysis phase is run to produce the action graph (a directed
+    acyclic graph of commands that need to be executed for the build).
+
+8.  The execution phase is run. This means running every action required to
+    build the top-level targets that are requested are run.
+
+## Command line options {#command-options}
+
+The command line options for a Bazel invocation are parsed into an
+`OptionsParsingResult` object, which holds instances of `OptionsBase`
+subclasses populated with the parsed values. An "option class" is a subclass
+of `OptionsBase` and groups related command line options together.
+
+There are two main kinds of option classes:
+
+1.  **Configuration options:** These options affect how targets are built,
+    for example, defining the target platform or compilation mode. They are
+    defined in subclasses of `FragmentOptions` (e.g., `CppOptions`,
+    `JavaOptions`), which is itself a subclass of `OptionsBase`.
+    `FragmentOptions` instances are collected into a `BuildOptions` object,
+    which is used to create the `BuildConfiguration` for a configured target.
+    These options are available during the analysis phase via
+    `RuleContext.getFragment()` in Java or `ctx.fragments` in Starlark.
+2.  **Other command options:** These options affect other aspects of Bazel's
+    behavior. They are defined in classes that extend `OptionsBase` directly,
+    but are not `FragmentOptions`. Examples include `ExecutionOptions`, which
+    influences how actions are executed, and `CommonCommandOptions`, which
+    contains options applicable to many commands. These are not part of
+    `BuildOptions`.
+
+Some configuration options (for example, whether to do C++ include scanning with
+`--cc_include_scanning`) are read in the execution phase. But that always
+requires explicit plumbing since `BuildConfiguration` is not available then. For
+more information, see the section "Configurations".
+
+**WARNING:** We like to pretend that `OptionsBase` instances are immutable and
+use them that way (such as a part of `SkyKeys`). This is not the case and
+modifying them is a really good way to break Bazel in subtle ways that are hard
+to debug. Unfortunately, making them actually immutable is a large endeavor.
+(Modifying a `FragmentOptions` immediately after construction before anyone else
+gets a chance to keep a reference to it and before `equals()` or `hashCode()` is
+called on it is okay.)
+
+Bazel learns about option classes in the following ways:
+
+1.  Some are hard-wired into Bazel (`CommonCommandOptions`).
+2.  From the `@Command` annotation on each Bazel command, which
+    lists option classes applicable to that command.
+3.  From `ConfiguredRuleClassProvider` (these are `FragmentOptions` for
+    individual programming languages that become part of `BuildOptions`).
+4.  Starlark rules can also define their own options, known as build settings
+    (see [here](/versions/9.1.0/extending/config)).
+
+Each option (excluding Starlark-defined options) is a member variable of an
+`OptionsBase` subclass that has the `@Option` annotation, which specifies
+the name and the type of the command line option along with some help text.
+
+The Java type of the value of a command line option is usually something simple
+(a string, an integer, a Boolean, a label, etc.). However, we also support
+options of more complicated types; in this case, the job of converting from the
+command line string to the data type falls to an implementation of
+`com.google.devtools.common.options.Converter`.
+
+## The source tree, as seen by Bazel {#source-tree}
+
+Bazel is in the business of building software, which happens by reading and
+interpreting the source code. The totality of the source code Bazel operates on
+is called "the workspace" and it is structured into repositories, packages and
+rules.
+
+### Repositories {#repositories}
+
+A "repository" is a source tree on which a developer works; it usually
+represents a single project. Bazel's ancestor, Blaze, operated on a monorepo,
+that is, a single source tree that contains all source code used to run the build.
+Bazel, in contrast, supports projects whose source code spans multiple
+repositories. The repository from which Bazel is invoked is called the "main
+repository", the others are called "external repositories".
+
+A repository is marked by a repo boundary file (`MODULE.bazel`, `REPO.bazel`, or
+in legacy contexts, `WORKSPACE` or `WORKSPACE.bazel`) in its root directory. The
+main repo is the source tree where you're invoking Bazel from. External repos
+are defined in various ways; see [external dependencies
+overview](/versions/9.1.0/external/overview) for more information.
+
+Code of external repositories is symlinked or downloaded under
+`$OUTPUT_BASE/external`.
+
+When running the build, the whole source tree needs to be pieced together; this
+is done by `SymlinkForest`, which symlinks every package in the main repository
+to `$EXECROOT` and every external repository to either `$EXECROOT/external` or
+`$EXECROOT/..`.
+
+### Packages {#packages}
+
+Every repository is composed of packages, a collection of related files and
+a specification of the dependencies. These are specified by a file called
+`BUILD` or `BUILD.bazel`. If both exist, Bazel prefers `BUILD.bazel`; the reason
+why `BUILD` files are still accepted is that Bazel's ancestor, Blaze, used this
+file name. However, it turned out to be a commonly used path segment, especially
+on Windows, where file names are case-insensitive.
+
+Packages are independent of each other: changes to the `BUILD` file of a package
+cannot cause other packages to change. The addition or removal of `BUILD` files
+_can _change other packages, since recursive globs stop at package boundaries
+and thus the presence of a `BUILD` file stops the recursion.
+
+The evaluation of a `BUILD` file is called "package loading". It's implemented
+in the class `PackageFactory`, works by calling the Starlark interpreter and
+requires knowledge of the set of available rule classes. The result of package
+loading is a `Package` object. It's mostly a map from a string (the name of a
+target) to the target itself.
+
+A large chunk of complexity during package loading is globbing: Bazel does not
+require every source file to be explicitly listed and instead can run globs
+(such as `glob(["**/*.java"])`). Unlike the shell, it supports recursive globs that
+descend into subdirectories (but not into subpackages). This requires access to
+the file system and since that can be slow, we implement all sorts of tricks to
+make it run in parallel and as efficiently as possible.
+
+Globbing is implemented in the following classes:
+
+*   `LegacyGlobber`, a fast and blissfully Skyframe-unaware globber
+*   `SkyframeHybridGlobber`, a version that uses Skyframe and reverts back to
+    the legacy globber in order to avoid "Skyframe restarts" (described below)
+
+The `Package` class itself contains some members that are exclusively used to
+parse the "external" package (related to external dependencies) and which do not
+make sense for real packages. This is
+a design flaw because objects describing regular packages should not contain
+fields that describe something else. These include:
+
+*   The repository mappings
+*   The registered toolchains
+*   The registered execution platforms
+
+Ideally, there would be more separation between parsing the "external" package
+from parsing regular packages so that `Package` does not need to cater for the
+needs of both. This is unfortunately difficult to do because the two are
+intertwined quite deeply.
+
+### Labels, Targets, and Rules {#labels-targets-rules}
+
+Packages are composed of targets, which have the following types:
+
+1.  **Files:** things that are either the input or the output of the build. In
+    Bazel parlance, we call them _artifacts_ (discussed elsewhere). Not all
+    files created during the build are targets; it's common for an output of
+    Bazel not to have an associated label.
+2.  **Rules:** these describe steps to derive its outputs from its inputs. They
+    are generally associated with a programming language (such as `cc_library`,
+    `java_library` or `py_library`), but there are some language-agnostic ones
+    (such as `genrule` or `filegroup`)
+3.  **Package groups:** discussed in the [Visibility](#visibility) section.
+
+The name of a target is called a _Label_. The syntax of labels is
+`@repo//pac/kage:name`, where `repo` is the name of the repository the Label is
+in, `pac/kage` is the directory its `BUILD` file is in and `name` is the path of
+the file (if the label refers to a source file) relative to the directory of the
+package. When referring to a target on the command line, some parts of the label
+can be omitted:
+
+1.  If the repository is omitted, the label is taken to be in the main
+    repository.
+2.  If the package part is omitted (such as `name` or `:name`), the label is taken
+    to be in the package of the current working directory (relative paths
+    containing uplevel references (..) are not allowed)
+
+A kind of a rule (such as "C++ library") is called a "rule class". Rule classes may
+be implemented either in Starlark (the `rule()` function) or in Java (so called
+"native rules", type `RuleClass`). In the long term, every language-specific
+rule will be implemented in Starlark, but some legacy rule families (such as Java
+or C++) are still in Java for the time being.
+
+Starlark rule classes need to be imported at the beginning of `BUILD` files
+using the `load()` statement, whereas Java rule classes are "innately" known by
+Bazel, by virtue of being registered with the `ConfiguredRuleClassProvider`.
+
+Rule classes contain information such as:
+
+1.  Its attributes (such as `srcs`, `deps`): their types, default values,
+    constraints, etc.
+2.  The configuration transitions and aspects attached to each attribute, if any
+3.  The implementation of the rule
+4.  The transitive info providers the rule "usually" creates
+
+**Terminology note:** In the codebase, we often use "Rule" to mean the target
+created by a rule class. But in Starlark and in user-facing documentation,
+"Rule" should be used exclusively to refer to the rule class itself; the target
+is just a "target". Also note that despite `RuleClass` having "class" in its
+name, there is no Java inheritance relationship between a rule class and targets
+of that type.
+
+## Skyframe {#skyframe}
+
+The evaluation framework underlying Bazel is called Skyframe. Its model is that
+everything that needs to be built during a build is organized into a directed
+acyclic graph with edges pointing from any pieces of data to its dependencies,
+that is, other pieces of data that need to be known to construct it.
+
+The nodes in the graph are called `SkyValue`s and their names are called
+`SkyKey`s. Both are deeply immutable; only immutable objects should be
+reachable from them. This invariant almost always holds, and in case it doesn't
+(such as for the individual options classes `BuildOptions`, which is a member of
+`BuildConfigurationValue` and its `SkyKey`) we try really hard not to change
+them or to change them in only ways that are not observable from the outside.
+From this it follows that everything that is computed within Skyframe (such as
+configured targets) must also be immutable.
+
+The most convenient way to observe the Skyframe graph is to run `bazel dump
+--skyframe=deps`, which dumps the graph, one `SkyValue` per line. It's best
+to do it for tiny builds, since it can get pretty large.
+
+Skyframe lives in the `com.google.devtools.build.skyframe` package. The
+similarly-named package `com.google.devtools.build.lib.skyframe` contains the
+implementation of Bazel on top of Skyframe. More information about Skyframe is
+available [here](/versions/9.1.0/reference/skyframe).
+
+To evaluate a given `SkyKey` into a `SkyValue`, Skyframe will invoke the
+`SkyFunction` corresponding to the type of the key. During the function's
+evaluation, it may request other dependencies from Skyframe by calling the
+various overloads of `SkyFunction.Environment.getValue()`. This has the
+side-effect of registering those dependencies into Skyframe's internal graph, so
+that Skyframe will know to re-evaluate the function when any of its dependencies
+change. In other words, Skyframe's caching and incremental computation work at
+the granularity of `SkyFunction`s and `SkyValue`s.
+
+Whenever a `SkyFunction` requests a dependency that is unavailable, `getValue()`
+will return null. The function should then yield control back to Skyframe by
+itself returning null. At some later point, Skyframe will evaluate the
+unavailable dependency, then restart the function from the beginning — only this
+time the `getValue()` call will succeed with a non-null result.
+
+A consequence of this is that any computation performed inside the `SkyFunction`
+prior to the restart must be repeated. But this does not include work done to
+evaluate dependency `SkyValues`, which are cached. Therefore, we commonly work
+around this issue by:
+
+1.  Declaring dependencies in batches (by using `getValuesAndExceptions()`) to
+    limit the number of restarts.
+2.  Breaking up a `SkyValue` into separate pieces computed by different
+    `SkyFunction`s, so that they can be computed and cached independently. This
+    should be done strategically, since it has the potential to increases memory
+    usage.
+3.  Storing state between restarts, either using
+    `SkyFunction.Environment.getState()`, or keeping an ad hoc static cache
+    "behind the back of Skyframe". With complex SkyFunctions, state management
+    between restarts can get tricky, so
+    [`StateMachine`s](/versions/9.1.0/contribute/statemachine-guide) were introduced for a
+    structured approach to logical concurrency, including hooks to suspend and
+    resume hierarchical computations within a `SkyFunction`. Example:
+    [`DependencyResolver#computeDependencies`][statemachine_example]
+    uses a `StateMachine` with `getState()` to compute the potentially huge set
+    of direct dependencies of a configured target, which otherwise can result in
+    expensive restarts.
+
+[statemachine_example]: https://developers.google.com/devsite/reference/markdown/links#reference_links
+
+Fundamentally, Bazel need these types of workarounds because hundreds of
+thousands of in-flight Skyframe nodes is common, and Java's support of
+lightweight threads [does not outperform][virtual_threads] the
+`StateMachine` implementation as of 2023.
+
+[virtual_threads]: /contribute/statemachine-guide#epilogue_eventually_removing_callbacks
+
+## Starlark {#starlark}
+
+Starlark is the domain-specific language people use to configure and extend
+Bazel. It's conceived as a restricted subset of Python that has far fewer types,
+more restrictions on control flow, and most importantly, strong immutability
+guarantees to enable concurrent reads. It is not Turing-complete, which
+discourages some (but not all) users from trying to accomplish general
+programming tasks within the language.
+
+Starlark is implemented in the `net.starlark.java` package.
+It also has an independent Go implementation
+[here](https://github.com/google/starlark-go). The Java
+implementation used in Bazel is currently an interpreter.
+
+Starlark is used in several contexts, including:
+
+1.  **`BUILD` files.** This is where new build targets are defined. Starlark
+    code running in this context only has access to the contents of the `BUILD`
+    file itself and `.bzl` files loaded by it.
+2.  **The `MODULE.bazel` file.** This is where external dependencies are
+    defined. Starlark code running in this context only has very limited access
+    to a few predefined directives.
+3.  **`.bzl` files.** This is where new build rules, repo rules, module
+    extensions are defined. Starlark code here can define new functions and load
+    from other `.bzl` files.
+
+The dialects available for `BUILD` and `.bzl` files are slightly different
+because they express different things. A list of differences is available
+[here](/versions/9.1.0/rules/language#differences-between-build-and-bzl-files).
+
+More information about Starlark is available [here](/versions/9.1.0/rules/language).
+
+## The loading/analysis phase {#loading-phase}
+
+The loading/analysis phase is where Bazel determines what actions are needed to
+build a particular rule. Its basic unit is a "configured target", which is,
+quite sensibly, a (target, configuration) pair.
+
+It's called the "loading/analysis phase" because it can be split into two
+distinct parts, which used to be serialized, but they can now overlap in time:
+
+1.  Loading packages, that is, turning `BUILD` files into the `Package` objects
+    that represent them
+2.  Analyzing configured targets, that is, running the implementation of the
+    rules to produce the action graph
+
+Each configured target in the transitive closure of the configured targets
+requested on the command line must be analyzed bottom-up; that is, leaf nodes
+first, then up to the ones on the command line. The inputs to the analysis of
+a single configured target are:
+
+1.  **The configuration.** ("how" to build that rule; for example, the target
+    platform but also things like command line options the user wants to be
+    passed to the C++ compiler)
+2.  **The direct dependencies.** Their transitive info providers are available
+    to the rule being analyzed. They are called like that because they provide a
+    "roll-up" of the information in the transitive closure of the configured
+    target, such as all the .jar files on the classpath or all the .o files that
+    need to be linked into a C++ binary)
+3.  **The target itself**. This is the result of loading the package the target
+    is in. For rules, this includes its attributes, which is usually what
+    matters.
+4.  **The implementation of the configured target.** For rules, this can either
+    be in Starlark or in Java. All non-rule configured targets are implemented
+    in Java.
+
+The output of analyzing a configured target is:
+
+1.  The transitive info providers that configured targets that depend on it can
+    access
+2.  The artifacts it can create and the actions that produce them.
+
+The API offered to Java rules is `RuleContext`, which is the equivalent of the
+`ctx` argument of Starlark rules. Its API is more powerful, but at the same
+time, it's easier to do Bad Things™, for example to write code whose time or
+space complexity is quadratic (or worse), to make the Bazel server crash with a
+Java exception or to violate invariants (such as by inadvertently modifying an
+`Options` instance or by making a configured target mutable)
+
+The algorithm that determines the direct dependencies of a configured target
+lives in `DependencyResolver.dependentNodeMap()`.
+
+### Configurations {#configurations}
+
+Configurations are the "how" of building a target: for what platform, with what
+command line options, etc.
+
+The same target can be built for multiple configurations in the same build. This
+is useful, for example, when the same code is used for a tool that's run during
+the build and for the target code and we are cross-compiling or when we are
+building a fat Android app (one that contains native code for multiple CPU
+architectures)
+
+Conceptually, the configuration is a `BuildOptions` instance. However, in
+practice, `BuildOptions` is wrapped by `BuildConfiguration` that provides
+additional sundry pieces of functionality. It propagates from the top of the
+dependency graph to the bottom. If it changes, the build needs to be
+re-analyzed.
+
+This results in anomalies like having to re-analyze the whole build if, for
+example, the number of requested test runs changes, even though that only
+affects test targets (we have plans to "trim" configurations so that this is
+not the case, but it's not ready yet).
+
+When a rule implementation needs part of the configuration, it needs to declare
+it in its definition using `RuleClass.Builder.requiresConfigurationFragments()`
+. This is both to avoid mistakes (such as Python rules using the Java fragment) and
+to facilitate configuration trimming so that such as if Python options change, C++
+targets don't need to be re-analyzed.
+
+The configuration of a rule is not necessarily the same as that of its "parent"
+rule. The process of changing the configuration in a dependency edge is called a
+"configuration transition". It can happen in two places:
+
+1.  On a dependency edge. These transitions are specified in
+    `Attribute.Builder.cfg()` and are functions from a `Rule` (where the
+    transition happens) and a `BuildOptions` (the original configuration) to one
+    or more `BuildOptions` (the output configuration).
+2.  On any incoming edge to a configured target. These are specified in
+    `RuleClass.Builder.cfg()`.
+
+The relevant classes are `TransitionFactory` and `ConfigurationTransition`.
+
+Configuration transitions are used, for example:
+
+1.  To declare that a particular dependency is used during the build and it
+    should thus be built in the execution architecture
+2.  To declare that a particular dependency must be built for multiple
+    architectures (such as for native code in fat Android APKs)
+
+If a configuration transition results in multiple configurations, it's called a
+_split transition._
+
+Configuration transitions can also be implemented in Starlark (documentation
+[here](/versions/9.1.0/extending/config))
+
+### Transitive info providers {#transitive-info-providers}
+
+Transitive info providers are a way (and the _only _way) for configured targets
+to learn things about other configured targets that they depend on, and the only
+way to tell things about themselves to other configured targets that depend on
+them. The reason why "transitive" is in their name is that this is usually some
+sort of roll-up of the transitive closure of a configured target.
+
+There is generally a 1:1 correspondence between Java transitive info providers
+and Starlark ones (the exception is `DefaultInfo` which is an amalgamation of
+`FileProvider`, `FilesToRunProvider` and `RunfilesProvider` because that API was
+deemed to be more Starlark-ish than a direct transliteration of the Java one).
+Their key is one of the following things:
+
+1.  A Java Class object. This is only available for providers that are not
+    accessible from Starlark. These providers are a subclass of
+    `TransitiveInfoProvider`.
+2.  A string. This is legacy and heavily discouraged since it's susceptible to
+    name clashes. Such transitive info providers are direct subclasses of
+    `build.lib.packages.Info` .
+3.  A provider symbol. This can be created from Starlark using the `provider()`
+    function and is the recommended way to create new providers. The symbol is
+    represented by a `Provider.Key` instance in Java.
+
+New providers implemented in Java should be implemented using `BuiltinProvider`.
+`NativeProvider` is deprecated (we haven't had time to remove it yet) and
+`TransitiveInfoProvider` subclasses cannot be accessed from Starlark.
+
+### Configured targets {#configured-targets}
+
+Configured targets are implemented as `RuleConfiguredTargetFactory`. There is a
+subclass for each rule class implemented in Java. Starlark configured targets
+are created through `StarlarkRuleConfiguredTargetUtil.buildRule()` .
+
+Configured target factories should use `RuleConfiguredTargetBuilder` to
+construct their return value. It consists of the following things:
+
+1.  Their `filesToBuild`, the hazy concept of "the set of files this rule
+    represents." These are the files that get built when the configured target
+    is on the command line or in the srcs of a genrule.
+2.  Their runfiles, regular and data.
+3.  Their output groups. These are various "other sets of files" the rule can
+    build. They can be accessed using the output\_group attribute of the
+    filegroup rule in BUILD and using the `OutputGroupInfo` provider in Java.
+
+### Runfiles {#runfiles}
+
+Some binaries need data files to run. A prominent example is tests that need
+input files. This is represented in Bazel by the concept of "runfiles". A
+"runfiles tree" is a directory tree of the data files for a particular binary.
+It is created in the file system as a symlink tree with individual symlinks
+pointing to the files in the source or output trees.
+
+A set of runfiles is represented as a `Runfiles` instance. It is conceptually a
+map from the path of a file in the runfiles tree to the `Artifact` instance that
+represents it. It's a little more complicated than a single `Map` for two
+reasons:
+
+*   Most of the time, the runfiles path of a file is the same as its execpath.
+    We use this to save some RAM.
+*   There are various legacy kinds of entries in runfiles trees, which also need
+    to be represented.
+
+Runfiles are collected using `RunfilesProvider`: an instance of this class
+represents the runfiles a configured target (such as a library) and its transitive
+closure needs and they are gathered like a nested set (in fact, they are
+implemented using nested sets under the cover): each target unions the runfiles
+of its dependencies, adds some of its own, then sends the resulting set upwards
+in the dependency graph. A `RunfilesProvider` instance contains two `Runfiles`
+instances, one for when the rule is depended on through the "data" attribute and
+one for every other kind of incoming dependency. This is because a target
+sometimes presents different runfiles when depended on through a data attribute
+than otherwise. This is undesired legacy behavior that we haven't gotten around
+removing yet.
+
+Runfiles of binaries are represented as an instance of `RunfilesSupport`. This
+is different from `Runfiles` because `RunfilesSupport` has the capability of
+actually being built (unlike `Runfiles`, which is just a mapping). This
+necessitates the following additional components:
+
+*   **The input runfiles manifest.** This is a serialized description of the
+    runfiles tree. It is used as a proxy for the contents of the runfiles tree
+    and Bazel assumes that the runfiles tree changes if and only if the contents
+    of the manifest change.
+*   **The output runfiles manifest.** This is used by runtime libraries that
+    handle runfiles trees, notably on Windows, which sometimes doesn't support
+    symbolic links.
+*   **Command line arguments** for running the binary whose runfiles the
+    `RunfilesSupport` object represents.
+
+### Aspects {#aspects}
+
+Aspects are a way to "propagate computation down the dependency graph". They are
+described for users of Bazel
+[here](/versions/9.1.0/extending/aspects). A good
+motivating example is protocol buffers: a `proto_library` rule should not know
+about any particular language, but building the implementation of a protocol
+buffer message (the "basic unit" of protocol buffers) in any programming
+language should be coupled to the `proto_library` rule so that if two targets in
+the same language depend on the same protocol buffer, it gets built only once.
+
+Just like configured targets, they are represented in Skyframe as a `SkyValue`
+and the way they are constructed is very similar to how configured targets are
+built: they have a factory class called `ConfiguredAspectFactory` that has
+access to a `RuleContext`, but unlike configured target factories, it also knows
+about the configured target it is attached to and its providers.
+
+The set of aspects propagated down the dependency graph is specified for each
+attribute using the `Attribute.Builder.aspects()` function. There are a few
+confusingly-named classes that participate in the process:
+
+1.  `AspectClass` is the implementation of the aspect. It can be either in Java
+    (in which case it's a subclass) or in Starlark (in which case it's an
+    instance of `StarlarkAspectClass`). It's analogous to
+    `RuleConfiguredTargetFactory`.
+2.  `AspectDefinition` is the definition of the aspect; it includes the
+    providers it requires, the providers it provides and contains a reference to
+    its implementation, such as the appropriate `AspectClass` instance. It's
+    analogous to `RuleClass`.
+3.  `AspectParameters` is a way to parametrize an aspect that is propagated down
+    the dependency graph. It's currently a string to string map. A good example
+    of why it's useful is protocol buffers: if a language has multiple APIs, the
+    information as to which API the protocol buffers should be built for should
+    be propagated down the dependency graph.
+4.  `Aspect` represents all the data that's needed to compute an aspect that
+    propagates down the dependency graph. It consists of the aspect class, its
+    definition and its parameters.
+5.  `RuleAspect` is the function that determines which aspects a particular rule
+    should propagate. It's a `Rule` -> `Aspect` function.
+
+A somewhat unexpected complication is that aspects can attach to other aspects;
+for example, an aspect collecting the classpath for a Java IDE will probably
+want to know about all the .jar files on the classpath, but some of them are
+protocol buffers. In that case, the IDE aspect will want to attach to the
+(`proto_library` rule + Java proto aspect) pair.
+
+The complexity of aspects on aspects is captured in the class
+`AspectCollection`.
+
+### Platforms and toolchains {#platforms-toolchains}
+
+Bazel supports multi-platform builds, that is, builds where there may be
+multiple architectures where build actions run and multiple architectures for
+which code is built. These architectures are referred to as _platforms_ in Bazel
+parlance (full documentation
+[here](/versions/9.1.0/extending/platforms))
+
+A platform is described by a key-value mapping from _constraint settings_ (such as
+the concept of "CPU architecture") to _constraint values_ (such as a particular CPU
+like x86\_64). We have a "dictionary" of the most commonly used constraint
+settings and values in the `@platforms` repository.
+
+The concept of _toolchain_ comes from the fact that depending on what platforms
+the build is running on and what platforms are targeted, one may need to use
+different compilers; for example, a particular C++ toolchain may run on a
+specific OS and be able to target some other OSes. Bazel must determine the C++
+compiler that is used based on the set execution and target platform
+(documentation for toolchains
+[here](/versions/9.1.0/extending/toolchains)).
+
+In order to do this, toolchains are annotated with the set of execution and
+target platform constraints they support. In order to do this, the definition of
+a toolchain are split into two parts:
+
+1.  A `toolchain()` rule that describes the set of execution and target
+    constraints a toolchain supports and tells what kind (such as C++ or Java) of
+    toolchain it is (the latter is represented by the `toolchain_type()` rule)
+2.  A language-specific rule that describes the actual toolchain (such as
+    `cc_toolchain()`)
+
+This is done in this way because we need to know the constraints for every
+toolchain in order to do toolchain resolution and language-specific
+`*_toolchain()` rules contain much more information than that, so they take more
+time to load.
+
+Execution platforms are specified in one of the following ways:
+
+1.  In the MODULE.bazel file using the `register_execution_platforms()` function
+2.  On the command line using the --extra\_execution\_platforms command line
+    option
+
+The set of available execution platforms is computed in
+`RegisteredExecutionPlatformsFunction` .
+
+The target platform for a configured target is determined by
+`PlatformOptions.computeTargetPlatform()` . It's a list of platforms because we
+eventually want to support multiple target platforms, but it's not implemented
+yet.
+
+The set of toolchains to be used for a configured target is determined by
+`ToolchainResolutionFunction`. It is a function of:
+
+*   The set of registered toolchains (in the MODULE.bazel file and the
+    configuration)
+*   The desired execution and target platforms (in the configuration)
+*   The set of toolchain types that are required by the configured target (in
+    `UnloadedToolchainContextKey)`
+*   The set of execution platform constraints of the configured target (the
+    `exec_compatible_with` attribute), in `UnloadedToolchainContextKey`
+
+Its result is an `UnloadedToolchainContext`, which is essentially a map from
+toolchain type (represented as a `ToolchainTypeInfo` instance) to the label of
+the selected toolchain. It's called "unloaded" because it does not contain the
+toolchains themselves, only their labels.
+
+Then the toolchains are actually loaded using `ResolvedToolchainContext.load()`
+and used by the implementation of the configured target that requested them.
+
+We also have a legacy system that relies on there being one single "host"
+configuration and target configurations being represented by various
+configuration flags, such as `--cpu` . We are gradually transitioning to the above
+system. In order to handle cases where people rely on the legacy configuration
+values, we have implemented
+[platform mappings](https://docs.google.com/document/d/1Vg_tPgiZbSrvXcJ403vZVAGlsWhH9BUDrAxMOYnO0Ls)
+to translate between the legacy flags and the new-style platform constraints.
+Their code is in `PlatformMappingFunction` and uses a non-Starlark "little
+language".
+
+### Constraints {#constraints}
+
+Sometimes one wants to designate a target as being compatible with only a few
+platforms. Bazel has (unfortunately) multiple mechanisms to achieve this end:
+
+*   Rule-specific constraints
+*   `environment_group()` / `environment()`
+*   Platform constraints
+
+Rule-specific constraints are mostly used within Google for Java rules; they are
+on their way out and they are not available in Bazel, but the source code may
+contain references to it. The attribute that governs this is called
+`constraints=` .
+
+#### environment_group() and environment() {#environment-rule}
+
+These rules are a legacy mechanism and are not widely used.
+
+All build rules can declare which "environments" they can be built for, where an
+"environment" is an instance of the `environment()` rule.
+
+There are various ways supported environments can be specified for a rule:
+
+1.  Through the `restricted_to=` attribute. This is the most direct form of
+    specification; it declares the exact set of environments the rule supports.
+2.  Through the `compatible_with=` attribute. This declares environments a rule
+    supports in addition to "standard" environments that are supported by
+    default.
+3.  Through the package-level attributes `default_restricted_to=` and
+    `default_compatible_with=`.
+4.  Through default specifications in `environment_group()` rules. Every
+    environment belongs to a group of thematically related peers (such as "CPU
+    architectures", "JDK versions" or "mobile operating systems"). The
+    definition of an environment group includes which of these environments
+    should be supported by "default" if not otherwise specified by the
+    `restricted_to=` / `environment()` attributes. A rule with no such
+    attributes inherits all defaults.
+5.  Through a rule class default. This overrides global defaults for all
+    instances of the given rule class. This can be used, for example, to make
+    all `*_test` rules testable without each instance having to explicitly
+    declare this capability.
+
+`environment()` is implemented as a regular rule whereas `environment_group()`
+is both a subclass of `Target` but not `Rule` (`EnvironmentGroup`) and a
+function that is available by default from Starlark
+(`StarlarkLibrary.environmentGroup()`) which eventually creates an eponymous
+target. This is to avoid a cyclic dependency that would arise because each
+environment needs to declare the environment group it belongs to and each
+environment group needs to declare its default environments.
+
+A build can be restricted to a certain environment with the
+`--target_environment` command line option.
+
+The implementation of the constraint check is in
+`RuleContextConstraintSemantics` and `TopLevelConstraintSemantics`.
+
+#### Platform constraints {#platform-constraints}
+
+The current "official" way to describe what platforms a target is compatible
+with is by using the same constraints used to describe toolchains and platforms.
+It was implemented in pull request
+[#10945](https://github.com/bazelbuild/bazel/pull/10945).
+
+### Visibility {#visibility}
+
+If you work on a large codebase with a lot of developers (like at Google), you
+want to take care to prevent everyone else from arbitrarily depending on your
+code. Otherwise, as per [Hyrum's law](https://www.hyrumslaw.com/),
+people _will_ come to rely on behaviors that you considered to be implementation
+details.
+
+Bazel supports this by the mechanism called _visibility_: you can limit which
+targets can depend on a particular target using the
+[visibility](/versions/9.1.0/reference/be/common-definitions#common-attributes) attribute. This
+attribute is a little special because, although it holds a list of labels, these
+labels may encode a pattern over package names rather than a pointer to any
+particular target. (Yes, this is a design flaw.)
+
+This is implemented in the following places:
+
+*   The `RuleVisibility` interface represents a visibility declaration. It can
+    be either a constant (fully public or fully private) or a list of labels.
+*   Labels can refer to either package groups (predefined list of packages), to
+    packages directly (`//pkg:__pkg__`) or subtrees of packages
+    (`//pkg:__subpackages__`). This is different from the command line syntax,
+    which uses `//pkg:*` or `//pkg/...`.
+*   Package groups are implemented as their own target (`PackageGroup`) and
+    configured target (`PackageGroupConfiguredTarget`). We could probably
+    replace these with simple rules if we wanted to. Their logic is implemented
+    with the help of: `PackageSpecification`, which corresponds to a
+    single pattern like `//pkg/...`; `PackageGroupContents`, which corresponds
+    to a single `package_group`'s `packages` attribute; and
+    `PackageSpecificationProvider`, which aggregates over a `package_group` and
+    its transitive `includes`.
+*   The conversion from visibility label lists to dependencies is done in
+    `DependencyResolver.visitTargetVisibility` and a few other miscellaneous
+    places.
+*   The actual check is done in
+    `CommonPrerequisiteValidator.validateDirectPrerequisiteVisibility()`
+
+### Nested sets {#nested-sets}
+
+Oftentimes, a configured target aggregates a set of files from its dependencies,
+adds its own, and wraps the aggregate set into a transitive info provider so
+that configured targets that depend on it can do the same. Examples:
+
+*   The C++ header files used for a build
+*   The object files that represent the transitive closure of a `cc_library`
+*   The set of .jar files that need to be on the classpath for a Java rule to
+    compile or run
+*   The set of Python files in the transitive closure of a Python rule
+
+If we did this the naive way by using, for example, `List` or `Set`, we'd end up with
+quadratic memory usage: if there is a chain of N rules and each rule adds a
+file, we'd have 1+2+...+N collection members.
+
+In order to get around this problem, we came up with the concept of a
+`NestedSet`. It's a data structure that is composed of other `NestedSet`
+instances and some members of its own, thereby forming a directed acyclic graph
+of sets. They are immutable and their members can be iterated over. We define
+multiple iteration order (`NestedSet.Order`): preorder, postorder, topological
+(a node always comes after its ancestors) and "don't care, but it should be the
+same each time".
+
+The same data structure is called `depset` in Starlark.
+
+### Artifacts and Actions {#artifacts}
+
+The actual build consists of a set of commands that need to be run to produce
+the output the user wants. The commands are represented as instances of the
+class `Action` and the files are represented as instances of the class
+`Artifact`. They are arranged in a bipartite, directed, acyclic graph called the
+"action graph".
+
+Artifacts come in two kinds: source artifacts (ones that are available
+before Bazel starts executing) and derived artifacts (ones that need to be
+built). Derived artifacts can themselves be multiple kinds:
+
+1.  **Regular artifacts.** These are checked for up-to-dateness by computing
+    their checksum, with mtime as a shortcut; we don't checksum the file if its
+    ctime hasn't changed.
+2.  **Unresolved symlink artifacts.** These are checked for up-to-dateness by
+    calling readlink(). Unlike regular artifacts, these can be dangling
+    symlinks. Usually used in cases where one then packs up some files into an
+    archive of some sort.
+3.  **Tree artifacts.** These are not single files, but directory trees. They
+    are checked for up-to-dateness by checking the set of files in it and their
+    contents. They are represented as a `TreeArtifact`.
+4.  **Constant metadata artifacts.** Changes to these artifacts don't trigger a
+    rebuild. This is used exclusively for build stamp information: we don't want
+    to do a rebuild just because the current time changed.
+
+There is no fundamental reason why source artifacts cannot be tree artifacts or
+unresolved symlink artifacts; it's just that we haven't implemented it yet. At
+the moment, source symlinks are always resolved, and while source directories
+are supported, their contents are entirely opaque to build rules and thus don't
+support the same kind of lazy command line expansion as tree artifacts do.
+
+Actions are best understood as a command that needs to be run, the environment
+it needs and the set of outputs it produces. The following things are the main
+components of the description of an action:
+
+*   The command line that needs to be run
+*   The input artifacts it needs
+*   The environment variables that need to be set
+*   Annotations that describe the environment (such as platform) it needs to run in
+    \
+
+There are also a few other special cases, like writing a file whose content is
+known to Bazel. They are a subclass of `AbstractAction`. Most of the actions are
+a `SpawnAction` or a `StarlarkAction` (the same, they should arguably not be
+separate classes), although Java and C++ have their own action types
+(`JavaCompileAction`, `CppCompileAction` and `CppLinkAction`).
+
+We eventually want to move everything to `SpawnAction`; `JavaCompileAction` is
+pretty close, but C++ is a bit of a special-case due to .d file parsing and
+include scanning.
+
+The action graph is mostly "embedded" into the Skyframe graph: conceptually, the
+execution of an action is represented as an invocation of
+`ActionExecutionFunction`. The mapping from an action graph dependency edge to a
+Skyframe dependency edge is described in
+`ActionExecutionFunction.getInputDeps()` and `Artifact.key()` and has a few
+optimizations in order to keep the number of Skyframe edges low:
+
+*   Derived artifacts do not have their own `SkyValue`s. Instead,
+    `Artifact.getGeneratingActionKey()` is used to find out the key for the
+    action that generates it
+*   Nested sets have their own Skyframe key.
+
+### Shared actions {#shared-actions}
+
+Some actions are generated by multiple configured targets; Starlark rules are
+more limited since they are only allowed to put their derived actions into a
+directory determined by their configuration and their package (but even so,
+rules in the same package can conflict), but rules implemented in Java can put
+derived artifacts anywhere.
+
+This is considered to be a misfeature, but getting rid of it is really hard
+because it produces significant savings in execution time when, for example, a
+source file needs to be processed somehow and that file is referenced by
+multiple rules (handwave-handwave). This comes at the cost of some RAM: each
+instance of a shared action needs to be stored in memory separately.
+
+If two actions generate the same output file, they must be exactly the same:
+have the same inputs, the same outputs and run the same command line. This
+equivalence relation is implemented in `Actions.canBeShared()` and it is
+verified between the analysis and execution phases by looking at every Action.
+This is implemented in `SkyframeActionExecutor.findAndStoreArtifactConflicts()`
+and is one of the few places in Bazel that requires a "global" view of the
+build.
+
+## The execution phase {#execution-phase}
+
+This is when Bazel actually starts running build actions, such as commands that
+produce outputs.
+
+The first thing Bazel does after the analysis phase is to determine what
+Artifacts need to be built. The logic for this is encoded in
+`TopLevelArtifactHelper`; roughly speaking, it's the `filesToBuild` of the
+configured targets on the command line and the contents of a special output
+group for the explicit purpose of expressing "if this target is on the command
+line, build these artifacts".
+
+The next step is creating the execution root. Since Bazel has the option to read
+source packages from different locations in the file system (`--package_path`),
+it needs to provide locally executed actions with a full source tree. This is
+handled by the class `SymlinkForest` and works by taking note of every target
+used in the analysis phase and building up a single directory tree that symlinks
+every package with a used target from its actual location. An alternative would
+be to pass the correct paths to commands (taking `--package_path` into account).
+This is undesirable because:
+
+*   It changes action command lines when a package is moved from a package path
+    entry to another (used to be a common occurrence)
+*   It results in different command lines if an action is run remotely than if
+    it's run locally
+*   It requires a command line transformation specific to the tool in use
+    (consider the difference between such as Java classpaths and C++ include paths)
+*   Changing the command line of an action invalidates its action cache entry
+*   `--package_path` is slowly and steadily being deprecated
+
+Then, Bazel starts traversing the action graph (the bipartite, directed graph
+composed of actions and their input and output artifacts) and running actions.
+The execution of each action is represented by an instance of the `SkyValue`
+class `ActionExecutionValue`.
+
+Since running an action is expensive, we have a few layers of caching that can
+be hit behind Skyframe:
+
+*   `ActionExecutionFunction.stateMap` contains data to make Skyframe restarts
+    of `ActionExecutionFunction` cheap
+*   The local action cache contains data about the state of the file system
+*   Remote execution systems usually also contain their own cache
+
+### The local action cache {#cache}
+
+This cache is another layer that sits behind Skyframe; even if an action is
+re-executed in Skyframe, it can still be a hit in the local action cache. It
+represents the state of the local file system and it's serialized to disk which
+means that when one starts up a new Bazel server, one can get local action cache
+hits even though the Skyframe graph is empty.
+
+This cache is checked for hits using the method
+`ActionCacheChecker.getTokenIfNeedToExecute()` .
+
+Contrary to its name, it's a map from the path of a derived artifact to the
+action that emitted it. The action is described as:
+
+1.  The set of its input and output files and their checksum
+2.  Its "action key", which is usually the command line that was executed, but
+    in general, represents everything that's not captured by the checksum of the
+    input files (such as for `FileWriteAction`, it's the checksum of the data
+    that's written)
+
+There is also a highly experimental "top-down action cache" that is still under
+development, which uses transitive hashes to avoid going to the cache as many
+times.
+
+### Input discovery and input pruning {#input-discovery}
+
+Some actions are more complicated than just having a set of inputs. Changes to
+the set of inputs of an action come in two forms:
+
+*   An action may discover new inputs before its execution or decide that some
+    of its inputs are not actually necessary. The canonical example is C++,
+    where it's better to make an educated guess about what header files a C++
+    file uses from its transitive closure so that we don't heed to send every
+    file to remote executors; therefore, we have an option not to register every
+    header file as an "input", but scan the source file for transitively
+    included headers and only mark those header files as inputs that are
+    mentioned in `#include` statements (we overestimate so that we don't need to
+    implement a full C preprocessor) This option is currently hard-wired to
+    "false" in Bazel and is only used at Google.
+*   An action may realize that some files were not used during its execution. In
+    C++, this is called ".d files": the compiler tells which header files were
+    used after the fact, and in order to avoid the embarrassment of having worse
+    incrementality than Make, Bazel makes use of this fact. This offers a better
+    estimate than the include scanner because it relies on the compiler.
+
+These are implemented using methods on Action:
+
+1.  `Action.discoverInputs()` is called. It should return a nested set of
+    Artifacts that are determined to be required. These must be source artifacts
+    so that there are no dependency edges in the action graph that don't have an
+    equivalent in the configured target graph.
+2.  The action is executed by calling `Action.execute()`.
+3.  At the end of `Action.execute()`, the action can call
+    `Action.updateInputs()` to tell Bazel that not all of its inputs were
+    needed. This can result in incorrect incremental builds if a used input is
+    reported as unused.
+
+When an action cache returns a hit on a fresh Action instance (such as created
+after a server restart), Bazel calls `updateInputs()` itself so that the set of
+inputs reflects the result of input discovery and pruning done before.
+
+Starlark actions can make use of the facility to declare some inputs as unused
+using the `unused_inputs_list=` argument of
+`ctx.actions.run()`.
+
+### Various ways to run actions: Strategies/ActionContexts {#options-run-actions}
+
+Some actions can be run in different ways. For example, a command line can be
+executed locally, locally but in various kinds of sandboxes, or remotely. The
+concept that embodies this is called an `ActionContext` (or `Strategy`, since we
+successfully went only halfway with a rename...)
+
+The life cycle of an action context is as follows:
+
+1.  When the execution phase is started, `BlazeModule` instances are asked what
+    action contexts they have. This happens in the constructor of
+    `ExecutionTool`. Action context types are identified by a Java `Class`
+    instance that refers to a sub-interface of `ActionContext` and which
+    interface the action context must implement.
+2.  The appropriate action context is selected from the available ones and is
+    forwarded to `ActionExecutionContext` and `BlazeExecutor` .
+3.  Actions request contexts using `ActionExecutionContext.getContext()` and
+    `BlazeExecutor.getStrategy()` (there should really be only one way to do
+    it…)
+
+Strategies are free to call other strategies to do their jobs; this is used, for
+example, in the dynamic strategy that starts actions both locally and remotely,
+then uses whichever finishes first.
+
+One notable strategy is the one that implements persistent worker processes
+(`WorkerSpawnStrategy`). The idea is that some tools have a long startup time
+and should therefore be reused between actions instead of starting one anew for
+every action (This does represent a potential correctness issue, since Bazel
+relies on the promise of the worker process that it doesn't carry observable
+state between individual requests)
+
+If the tool changes, the worker process needs to be restarted. Whether a worker
+can be reused is determined by computing a checksum for the tool used using
+`WorkerFilesHash`. It relies on knowing which inputs of the action represent
+part of the tool and which represent inputs; this is determined by the creator
+of the Action: `Spawn.getToolFiles()` and the runfiles of the `Spawn` are
+counted as parts of the tool.
+
+More information about strategies (or action contexts!):
+
+*   Information about various strategies for running actions is available
+    [here](https://jmmv.dev/2019/12/bazel-strategies.html).
+*   Information about the dynamic strategy, one where we run an action both
+    locally and remotely to see whichever finishes first is available
+    [here](https://jmmv.dev/series.html#Bazel%20dynamic%20execution).
+*   Information about the intricacies of executing actions locally is available
+    [here](https://jmmv.dev/2019/11/bazel-process-wrapper.html).
+
+### The local resource manager {#resource-manager}
+
+Bazel _can_ run many actions in parallel. The number of local actions that
+_should_ be run in parallel differs from action to action: the more resources an
+action requires, the less instances should be running at the same time to avoid
+overloading the local machine.
+
+This is implemented in the class `ResourceManager`: each action has to be
+annotated with an estimate of the local resources it requires in the form of a
+`ResourceSet` instance (CPU and RAM). Then when action contexts do something
+that requires local resources, they call `ResourceManager.acquireResources()`
+and are blocked until the required resources are available.
+
+A more detailed description of local resource management is available
+[here](https://jmmv.dev/2019/12/bazel-local-resources.html).
+
+### The structure of the output directory {#output-directory}
+
+Each action requires a separate place in the output directory where it places
+its outputs. The location of derived artifacts is usually as follows:
+
+```
+$EXECROOT/bazel-out//bin//
+```
+
+How is the name of the directory that is associated with a particular
+configuration determined? There are two conflicting desirable properties:
+
+1.  If two configurations can occur in the same build, they should have
+    different directories so that both can have their own version of the same
+    action; otherwise, if the two configurations disagree about such as the command
+    line of an action producing the same output file, Bazel doesn't know which
+    action to choose (an "action conflict")
+2.  If two configurations represent "roughly" the same thing, they should have
+    the same name so that actions executed in one can be reused for the other if
+    the command lines match: for example, changes to the command line options to
+    the Java compiler should not result in C++ compile actions being re-run.
+
+So far, we have not come up with a principled way of solving this problem, which
+has similarities to the problem of configuration trimming. A longer discussion
+of options is available
+[here](https://docs.google.com/document/d/1fZI7wHoaS-vJvZy9SBxaHPitIzXE_nL9v4sS4mErrG4/edit).
+The main problematic areas are Starlark rules (whose authors usually aren't
+intimately familiar with Bazel) and aspects, which add another dimension to the
+space of things that can produce the "same" output file.
+
+The current approach is that the path segment for the configuration is
+`-` with various suffixes added so that configuration
+transitions implemented in Java don't result in action conflicts. In addition, a
+checksum of the set of Starlark configuration transitions is added so that users
+can't cause action conflicts. It is far from perfect. This is implemented in
+`OutputDirectories.buildMnemonic()` and relies on each configuration fragment
+adding its own part to the name of the output directory.
+
+## Tests {#tests}
+
+Bazel has rich support for running tests. It supports:
+
+*   Running tests remotely (if a remote execution backend is available)
+*   Running tests multiple times in parallel (for deflaking or gathering timing
+    data)
+*   Sharding tests (splitting test cases in same test over multiple processes
+    for speed)
+*   Re-running flaky tests
+*   Grouping tests into test suites
+
+Tests are regular configured targets that have a TestProvider, which describes
+how the test should be run:
+
+*   The artifacts whose building result in the test being run. This is a "cache
+    status" file that contains a serialized `TestResultData` message
+*   The number of times the test should be run
+*   The number of shards the test should be split into
+*   Some parameters about how the test should be run (such as the test timeout)
+
+### Determining which tests to run {#determine-test-run}
+
+Determining which tests are run is an elaborate process.
+
+First, during target pattern parsing, test suites are recursively expanded. The
+expansion is implemented in `TestsForTargetPatternFunction`. A somewhat
+surprising wrinkle is that if a test suite declares no tests, it refers to
+_every_ test in its package. This is implemented in `Package.beforeBuild()` by
+adding an implicit attribute called `$implicit_tests` to test suite rules.
+
+Then, tests are filtered for size, tags, timeout and language according to the
+command line options. This is implemented in `TestFilter` and is called from
+`TargetPatternPhaseFunction.determineTests()` during target parsing and the
+result is put into `TargetPatternPhaseValue.getTestsToRunLabels()`. The reason
+why rule attributes which can be filtered for are not configurable is that this
+happens before the analysis phase, therefore, the configuration is not
+available.
+
+This is then processed further in `BuildView.createResult()`: targets whose
+analysis failed are filtered out and tests are split into exclusive and
+non-exclusive tests. It's then put into `AnalysisResult`, which is how
+`ExecutionTool` knows which tests to run.
+
+In order to lend some transparency to this elaborate process, the `tests()`
+query operator (implemented in `TestsFunction`) is available to tell which tests
+are run when a particular target is specified on the command line. It's
+unfortunately a reimplementation, so it probably deviates from the above in
+multiple subtle ways.
+
+### Running tests {#run-tests}
+
+The way the tests are run is by requesting cache status artifacts. This then
+results in the execution of a `TestRunnerAction`, which eventually calls the
+`TestActionContext` chosen by the `--test_strategy` command line option that
+runs the test in the requested way.
+
+Tests are run according to an elaborate protocol that uses environment variables
+to tell tests what's expected from them. A detailed description of what Bazel
+expects from tests and what tests can expect from Bazel is available
+[here](/versions/9.1.0/reference/test-encyclopedia). At the
+simplest, an exit code of 0 means success, anything else means failure.
+
+In addition to the cache status file, each test process emits a number of other
+files. They are put in the "test log directory" which is the subdirectory called
+`testlogs` of the output directory of the target configuration:
+
+*   `test.xml`, a JUnit-style XML file detailing the individual test cases in
+    the test shard
+*   `test.log`, the console output of the test. stdout and stderr are not
+    separated.
+*   `test.outputs`, the "undeclared outputs directory"; this is used by tests
+    that want to output files in addition to what they print to the terminal.
+
+There are two things that can happen during test execution that cannot during
+building regular targets: exclusive test execution and output streaming.
+
+Some tests need to be executed in exclusive mode, for example not in parallel with
+other tests. This can be elicited either by adding `tags=["exclusive"]` to the
+test rule or running the test with `--test_strategy=exclusive` . Each exclusive
+test is run by a separate Skyframe invocation requesting the execution of the
+test after the "main" build. This is implemented in
+`SkyframeExecutor.runExclusiveTest()`.
+
+Unlike regular actions, whose terminal output is dumped when the action
+finishes, the user can request the output of tests to be streamed so that they
+get informed about the progress of a long-running test. This is specified by the
+`--test_output=streamed` command line option and implies exclusive test
+execution so that outputs of different tests are not interspersed.
+
+This is implemented in the aptly-named `StreamedTestOutput` class and works by
+polling changes to the `test.log` file of the test in question and dumping new
+bytes to the terminal where Bazel rules.
+
+Results of the executed tests are available on the event bus by observing
+various events (such as `TestAttempt`, `TestResult` or `TestingCompleteEvent`).
+They are dumped to the Build Event Protocol and they are emitted to the console
+by `AggregatingTestListener`.
+
+### Coverage collection {#coverage-collection}
+
+Coverage is reported by the tests in LCOV format in the files
+`bazel-testlogs/$PACKAGE/$TARGET/coverage.dat` .
+
+To collect coverage, each test execution is wrapped in a script called
+`collect_coverage.sh` .
+
+This script sets up the environment of the test to enable coverage collection
+and determine where the coverage files are written by the coverage runtime(s).
+It then runs the test. A test may itself run multiple subprocesses and consist
+of parts written in multiple different programming languages (with separate
+coverage collection runtimes). The wrapper script is responsible for converting
+the resulting files to LCOV format if necessary, and merges them into a single
+file.
+
+The interposition of `collect_coverage.sh` is done by the test strategies and
+requires `collect_coverage.sh` to be on the inputs of the test. This is
+accomplished by the implicit attribute `:coverage_support` which is resolved to
+the value of the configuration flag `--coverage_support` (see
+`TestConfiguration.TestOptions.coverageSupport`)
+
+Some languages do offline instrumentation, meaning that the coverage
+instrumentation is added at compile time (such as C++) and others do online
+instrumentation, meaning that coverage instrumentation is added at execution
+time.
+
+Another core concept is _baseline coverage_. This is the coverage of a library,
+binary, or test if no code in it was run. The problem it solves is that if you
+want to compute the test coverage for a binary, it is not enough to merge the
+coverage of all of the tests because there may be code in the binary that is not
+linked into any test. Therefore, what we do is to emit a coverage file for every
+binary which contains only the files we collect coverage for with no covered
+lines. The default baseline coverage file for a target is at
+`bazel-testlogs/$PACKAGE/$TARGET/baseline_coverage.dat`, but rules are
+encouraged to generate their own baseline coverage files with more meaningful
+content than just the names of the source files.
+
+We track two groups of files for coverage collection for each rule: the set of
+instrumented files and the set of instrumentation metadata files.
+
+The set of instrumented files is just that, a set of files to instrument. For
+online coverage runtimes, this can be used at runtime to decide which files to
+instrument. It is also used to implement baseline coverage.
+
+The set of instrumentation metadata files is the set of extra files a test needs
+to generate the LCOV files Bazel requires from it. In practice, this consists of
+runtime-specific files; for example, gcc emits .gcno files during compilation.
+These are added to the set of inputs of test actions if coverage mode is
+enabled.
+
+Whether or not coverage is being collected is stored in the
+`BuildConfiguration`. This is handy because it is an easy way to change the test
+action and the action graph depending on this bit, but it also means that if
+this bit is flipped, all targets need to be re-analyzed (some languages, such as
+C++ require different compiler options to emit code that can collect coverage,
+which mitigates this issue somewhat, since then a re-analysis is needed anyway).
+
+The coverage support files are depended on through labels in an implicit
+dependency so that they can be overridden by the invocation policy, which allows
+them to differ between the different versions of Bazel. Ideally, these
+differences would be removed, and we standardized on one of them.
+
+We also generate a "coverage report" which merges the coverage collected for
+every test in a Bazel invocation. This is handled by
+`CoverageReportActionFactory` and is called from `BuildView.createResult()` . It
+gets access to the tools it needs by looking at the `:coverage_report_generator`
+attribute of the first test that is executed.
+
+## The query engine {#query-engine}
+
+Bazel has a
+[little language](/versions/9.1.0/query/guide)
+used to ask it various things about various graphs. The following query kinds
+are provided:
+
+*   `bazel query` is used to investigate the target graph
+*   `bazel cquery` is used to investigate the configured target graph
+*   `bazel aquery` is used to investigate the action graph
+
+Each of these is implemented by subclassing `AbstractBlazeQueryEnvironment`.
+Additional additional query functions can be done by subclassing `QueryFunction`
+. In order to allow streaming query results, instead of collecting them to some
+data structure, a `query2.engine.Callback` is passed to `QueryFunction`, which
+calls it for results it wants to return.
+
+The result of a query can be emitted in various ways: labels, labels and rule
+classes, XML, protobuf and so on. These are implemented as subclasses of
+`OutputFormatter`.
+
+A subtle requirement of some query output formats (proto, definitely) is that
+Bazel needs to emit _all _the information that package loading provides so that
+one can diff the output and determine whether a particular target has changed.
+As a consequence, attribute values need to be serializable, which is why there
+are only so few attribute types without any attributes having complex Starlark
+values. The usual workaround is to use a label, and attach the complex
+information to the rule with that label. It's not a very satisfying workaround
+and it would be very nice to lift this requirement.
+
+## The module system {#module-system}
+
+Bazel can be extended by adding modules to it. Each module must subclass
+`BlazeModule` (the name is a relic of the history of Bazel when it used to be
+called Blaze) and gets information about various events during the execution of
+a command.
+
+They are mostly used to implement various pieces of "non-core" functionality
+that only some versions of Bazel (such as the one we use at Google) need:
+
+*   Interfaces to remote execution systems
+*   New commands
+
+The set of extension points `BlazeModule` offers is somewhat haphazard. Don't
+use it as an example of good design principles.
+
+## The event bus {#event-bus}
+
+The main way BlazeModules communicate with the rest of Bazel is by an event bus
+(`EventBus`): a new instance is created for every build, various parts of Bazel
+can post events to it and modules can register listeners for the events they are
+interested in. For example, the following things are represented as events:
+
+*   The list of build targets to be built has been determined
+    (`TargetParsingCompleteEvent`)
+*   The top-level configurations have been determined
+    (`BuildConfigurationEvent`)
+*   A target was built, successfully or not (`TargetCompleteEvent`)
+*   A test was run (`TestAttempt`, `TestSummary`)
+
+Some of these events are represented outside of Bazel in the
+[Build Event Protocol](/versions/9.1.0/remote/bep)
+(they are `BuildEvent`s). This allows not only `BlazeModule`s, but also things
+outside the Bazel process to observe the build. They are accessible either as a
+file that contains protocol messages or Bazel can connect to a server (called
+the Build Event Service) to stream events.
+
+This is implemented in the `build.lib.buildeventservice` and
+`build.lib.buildeventstream` Java packages.
+
+## External repositories {#external-repos}
+
+Note: The information in this section is out of date, as code in this area has
+undergone extensive change in the past couple of years. Please refer to
+[external dependencies overview](/versions/9.1.0/external/overview) for more up-to-date
+information.
+
+Whereas Bazel was originally designed to be used in a monorepo (a single source
+tree containing everything one needs to build), Bazel lives in a world where
+this is not necessarily true. "External repositories" are an abstraction used to
+bridge these two worlds: they represent code that is necessary for the build but
+is not in the main source tree.
+
+### The WORKSPACE file {#workspace-file}
+
+The set of external repositories is determined by parsing the WORKSPACE file.
+For example, a declaration like this:
+
+```
+    local_repository(name="foo", path="/foo/bar")
+```
+
+Results in the repository called `@foo` being available. Where this gets
+complicated is that one can define new repository rules in Starlark files, which
+can then be used to load new Starlark code, which can be used to define new
+repository rules and so on…
+
+To handle this case, the parsing of the WORKSPACE file (in
+`WorkspaceFileFunction`) is split up into chunks delineated by `load()`
+statements. The chunk index is indicated by `WorkspaceFileKey.getIndex()` and
+computing `WorkspaceFileFunction` until index X means evaluating it until the
+Xth `load()` statement.
+
+### Fetching repositories {#fetch-repos}
+
+Before the code of the repository is available to Bazel, it needs to be
+_fetched_. This results in Bazel creating a directory under
+`$OUTPUT_BASE/external/`.
+
+Fetching the repository happens in the following steps:
+
+1.  `PackageLookupFunction` realizes that it needs a repository and creates a
+    `RepositoryName` as a `SkyKey`, which invokes `RepositoryLoaderFunction`
+2.  `RepositoryLoaderFunction` forwards the request to
+    `RepositoryDelegatorFunction` for unclear reasons (the code says it's to
+    avoid re-downloading things in case of Skyframe restarts, but it's not a
+    very solid reasoning)
+3.  `RepositoryDelegatorFunction` finds out the repository rule it's asked to
+    fetch by iterating over the chunks of the WORKSPACE file until the requested
+    repository is found
+4.  The appropriate `RepositoryFunction` is found that implements the repository
+    fetching; it's either the Starlark implementation of the repository or a
+    hard-coded map for repositories that are implemented in Java.
+
+There are various layers of caching since fetching a repository can be very
+expensive:
+
+1.  There is a cache for downloaded files that is keyed by their checksum
+    (`RepositoryCache`). This requires the checksum to be available in the
+    WORKSPACE file, but that's good for hermeticity anyway. This is shared by
+    every Bazel server instance on the same workstation, regardless of which
+    workspace or output base they are running in.
+2.  A "marker file" is written for each repository under `$OUTPUT_BASE/external`
+    that contains a checksum of the rule that was used to fetch it. If the Bazel
+    server restarts but the checksum does not change, it's not re-fetched. This
+    is implemented in `RepositoryDelegatorFunction.DigestWriter` .
+3.  The `--distdir` command line option designates another cache that is used to
+    look up artifacts to be downloaded. This is useful in enterprise settings
+    where Bazel should not fetch random things from the Internet. This is
+    implemented by `DownloadManager` .
+
+Once a repository is downloaded, the artifacts in it are treated as source
+artifacts. This poses a problem because Bazel usually checks for up-to-dateness
+of source artifacts by calling stat() on them, and these artifacts are also
+invalidated when the definition of the repository they are in changes. Thus,
+`FileStateValue`s for an artifact in an external repository need to depend on
+their external repository. This is handled by `ExternalFilesHelper`.
+
+### Repository mappings {#repo-mappings}
+
+It can happen that multiple repositories want to depend on the same repository,
+but in different versions (this is an instance of the "diamond dependency
+problem"). For example, if two binaries in separate repositories in the build
+want to depend on Guava, they will presumably both refer to Guava with labels
+starting `@guava//` and expect that to mean different versions of it.
+
+Therefore, Bazel allows one to re-map external repository labels so that the
+string `@guava//` can refer to one Guava repository (such as `@guava1//`) in the
+repository of one binary and another Guava repository (such as `@guava2//`) the
+repository of the other.
+
+Alternatively, this can also be used to **join** diamonds. If a repository
+depends on `@guava1//`, and another depends on `@guava2//`, repository mapping
+allows one to re-map both repositories to use a canonical `@guava//` repository.
+
+The mapping is specified in the WORKSPACE file as the `repo_mapping` attribute
+of individual repository definitions. It then appears in Skyframe as a member of
+`WorkspaceFileValue`, where it is plumbed to:
+
+*   `Package.Builder.repositoryMapping` which is used to transform label-valued
+    attributes of rules in the package by
+    `RuleClass.populateRuleAttributeValues()`
+*   `Package.repositoryMapping` which is used in the analysis phase (for
+    resolving things like `$(location)` which are not parsed in the loading
+    phase)
+*   `BzlLoadFunction` for resolving labels in load() statements
+
+## JNI bits {#jni-bits}
+
+The server of Bazel is _mostly_ written in Java. The exception is the parts that
+Java cannot do by itself or couldn't do by itself when we implemented it. This
+is mostly limited to interaction with the file system, process control and
+various other low-level things.
+
+The C++ code lives under src/main/native and the Java classes with native
+methods are:
+
+*   `NativePosixFiles` and `NativePosixFileSystem`
+*   `ProcessUtils`
+*   `WindowsFileOperations` and `WindowsFileProcesses`
+*   `com.google.devtools.build.lib.platform`
+
+## Console output {#console-output}
+
+Emitting console output seems like a simple thing, but the confluence of running
+multiple processes (sometimes remotely), fine-grained caching, the desire to
+have a nice and colorful terminal output and having a long-running server makes
+it non-trivial.
+
+Right after the RPC call comes in from the client, two `RpcOutputStream`
+instances are created (for stdout and stderr) that forward the data printed into
+them to the client. These are then wrapped in an `OutErr` (an (stdout, stderr)
+pair). Anything that needs to be printed on the console goes through these
+streams. Then these streams are handed over to
+`BlazeCommandDispatcher.execExclusively()`.
+
+Output is by default printed with ANSI escape sequences. When these are not
+desired (`--color=no`), they are stripped by an `AnsiStrippingOutputStream`. In
+addition, `System.out` and `System.err` are redirected to these output streams.
+This is so that debugging information can be printed using
+`System.err.println()` and still end up in the terminal output of the client
+(which is different from that of the server). Care is taken that if a process
+produces binary output (such as `bazel query --output=proto`), no munging of stdout
+takes place.
+
+Short messages (errors, warnings and the like) are expressed through the
+`EventHandler` interface. Notably, these are different from what one posts to
+the `EventBus` (this is confusing). Each `Event` has an `EventKind` (error,
+warning, info, and a few others) and they may have a `Location` (the place in
+the source code that caused the event to happen).
+
+Some `EventHandler` implementations store the events they received. This is used
+to replay information to the UI caused by various kinds of cached processing,
+for example, the warnings emitted by a cached configured target.
+
+Some `EventHandler`s also allow posting events that eventually find their way to
+the event bus (regular `Event`s do _not _appear there). These are
+implementations of `ExtendedEventHandler` and their main use is to replay cached
+`EventBus` events. These `EventBus` events all implement `Postable`, but not
+everything that is posted to `EventBus` necessarily implements this interface;
+only those that are cached by an `ExtendedEventHandler` (it would be nice and
+most of the things do; it's not enforced, though)
+
+Terminal output is _mostly_ emitted through `UiEventHandler`, which is
+responsible for all the fancy output formatting and progress reporting Bazel
+does. It has two inputs:
+
+*   The event bus
+*   The event stream piped into it through Reporter
+
+The only direct connection the command execution machinery (for example the rest of
+Bazel) has to the RPC stream to the client is through `Reporter.getOutErr()`,
+which allows direct access to these streams. It's only used when a command needs
+to dump large amounts of possible binary data (such as `bazel query`).
+
+## Profiling Bazel {#profile-bazel}
+
+Bazel is fast. Bazel is also slow, because builds tend to grow until just the
+edge of what's bearable. For this reason, Bazel includes a profiler which can be
+used to profile builds and Bazel itself. It's implemented in a class that's
+aptly named `Profiler`. It's turned on by default, although it records only
+abridged data so that its overhead is tolerable; The command line
+`--record_full_profiler_data` makes it record everything it can.
+
+It emits a profile in the Chrome profiler format; it's best viewed in Chrome.
+It's data model is that of task stacks: one can start tasks and end tasks and
+they are supposed to be neatly nested within each other. Each Java thread gets
+its own task stack. **TODO:** How does this work with actions and
+continuation-passing style?
+
+The profiler is started and stopped in `BlazeRuntime.initProfiler()` and
+`BlazeRuntime.afterCommand()` respectively and attempts to be live for as long
+as possible so that we can profile everything. To add something to the profile,
+call `Profiler.instance().profile()`. It returns a `Closeable`, whose closure
+represents the end of the task. It's best used with try-with-resources
+statements.
+
+We also do rudimentary memory profiling in `MemoryProfiler`. It's also always on
+and it mostly records maximum heap sizes and GC behavior.
+
+## Testing Bazel {#bazel-tests}
+
+Bazel has two main kinds of tests: ones that observe Bazel as a "black box" and
+ones that only run the analysis phase. We call the former "integration tests"
+and the latter "unit tests", although they are more like integration tests that
+are, well, less integrated. We also have some actual unit tests, where they are
+necessary.
+
+Of integration tests, we have two kinds:
+
+1.  Ones implemented using a very elaborate bash test framework under
+    `src/test/shell`
+2.  Ones implemented in Java. These are implemented as subclasses of
+    `BuildIntegrationTestCase`
+
+`BuildIntegrationTestCase` is the preferred integration testing framework as it
+is well-equipped for most testing scenarios. As it is a Java framework, it
+provides debuggability and seamless integration with many common development
+tools. There are many examples of `BuildIntegrationTestCase` classes in the
+Bazel repository.
+
+Analysis tests are implemented as subclasses of `BuildViewTestCase`. There is a
+scratch file system you can use to write `BUILD` files, then various helper
+methods can request configured targets, change the configuration and assert
+various things about the result of the analysis.
diff --git a/versions/9.1.0/contribute/design-documents.mdx b/versions/9.1.0/contribute/design-documents.mdx
new file mode 100644
index 00000000..402a8b31
--- /dev/null
+++ b/versions/9.1.0/contribute/design-documents.mdx
@@ -0,0 +1,252 @@
+---
+title: 'Design Documents'
+---
+
+If you're planning to add, change, or remove a user-facing feature, or make a
+*significant architectural change* to Bazel, you **must** write a design
+document and have it reviewed before you can submit the change.
+
+Here are some examples of significant changes:
+
+*   Addition or deletion of native build rules
+*   Breaking-changes to native rules
+*   Changes to a native build rule semantics that affect the behavior of more
+    than a single rule
+*   Changes to Bazel's rule definition API
+*   Changes to the APIs that Bazel uses to connect to other systems
+*   Changes to the Starlark language, semantics, or APIs
+*   Changes that could have a pervasive effect on Bazel performance or memory
+    usage (for better or for worse)
+*   Changes to widely used internal APIs
+*   Changes to flags and command-line interface.
+
+## Reasons for design reviews {#design-reviews}
+
+When you write a design document, you can coordinate with other Bazel developers
+and seek guidance from Bazel's core team. For example, when a proposal adds,
+removes, or modifies any function or object available in BUILD, MODULE.bazel, or
+bzl files, add the [Starlark team](/versions/9.1.0/contribute/maintainers-guide) as reviewers.
+Design documents are reviewed before submission because:
+
+*   Bazel is a very complex system; seemingly innocuous local changes can have
+    significant global consequences.
+*   The team gets many feature requests from users; such requests need to be
+    evaluated not only for technical feasibility but importance with regards to
+    other feature requests.
+*   Bazel features are frequently implemented by people outside the core team;
+    such contributors have widely varying levels of Bazel expertise.
+*   The Bazel team itself has varying levels of expertise; no single team member
+    has a complete understanding of every corner of Bazel.
+*   Changes to Bazel must account for backward compatibility and avoid breaking
+    changes.
+
+Bazel's design review policy helps to maximize the likelihood that:
+
+*   all feature requests get a baseline level of scrutiny.
+*   the right people will weigh in on designs before we've invested in an
+    implementation that may not work.
+
+To help you get started, take a look at the design documents in the
+[Bazel Proposals Repository](https://github.com/bazelbuild/proposals).
+Designs are works in progress, so implementation details can change over time
+and with feedback. The published design documents capture the initial design,
+and *not* the ongoing changes as designs are implemented. Always go to the
+documentation for descriptions of current Bazel functionality.
+
+## Contributor Workflow {#contributor-workflow}
+
+As a contributor, you can write a design document, send pull requests and
+request reviewers for your proposal.
+
+### Write the design document {#write-design-doc}
+
+All design documents must have a header that includes:
+
+*   author
+*   date of last major change
+*   list of reviewers, including one (and only one)
+    [lead reviewer](#lead-reviewer)
+*   current status (_draft_, _in review_, _approved_, _rejected_,
+    _being implemented_, _implemented_)
+*   link to discussion thread (_to be added after the announcement_)
+
+The document can be written either [as a world-readable Google Doc](#gdocs)
+or [using Markdown](#markdown). Read below about for a
+[Markdown / Google Docs comparison](#markdown-versus-gdocs).
+
+Proposals that have a user-visible impact must have a section documenting the
+impact on backward compatibility (and a rollout plan if needed).
+
+### Create a Pull Request {#pull-request}
+
+Share your design doc by creating a pull request (PR) to add the document to
+[the design index](https://github.com/bazelbuild/proposals). Add
+your markdown file or a document link to your PR.
+
+When possible, [choose a lead reviewer](#lead-reviewer).
+and cc other reviewers. If you don't choose a lead reviewer, a Bazel
+maintainer will assign one to your PR.
+
+After you create your PR, reviewers can make preliminary comments during the
+code review. For example, the lead reviewer can suggest extra reviewers, or
+point out missing information. The lead reviewer approves the PR when they
+believe the review process can start. This doesn't mean the proposal is perfect
+or will be approved; it means that the proposal contains enough information to
+start the discussion.
+
+### Announce the new proposal {#new-proposal}
+
+Send an announcement to
+[bazel-dev](https://groups.google.com/forum/#!forum/bazel-dev) when
+the PR is submitted.
+
+You may copy other groups (for example,
+[bazel-discuss](https://groups.google.com/forum/#!forum/bazel-discuss),
+to get feedback from Bazel end-users).
+
+### Iterate with reviewers {#reviewers}
+
+Anyone interested can comment on your proposal. Try to answer questions,
+clarify the proposal, and address concerns.
+
+Discussion should happen on the announcement thread. If the proposal is in a
+Google Doc, comments may be used instead (Note that anonymous comments are
+allowed).
+
+### Update the status {#update-status}
+
+Create a new PR to update the status of the proposal, when iteration is
+complete. Send the PR to the same lead reviewer and cc the other reviewers.
+
+To officially accept the proposal, the lead reviewer approves the PR after
+ensuring that the other reviewers agree with the decision.
+
+There must be at least 1 week between the first announcement and the approval of
+a proposal. This ensures that users had enough time to read the document and
+share their concerns.
+
+Implementation can begin before the proposal is accepted, for example as a
+proof-of-concept or an experimentation. However, you cannot submit the change
+before the review is complete.
+
+### Choosing a lead reviewer {#lead-reviewer}
+
+A lead reviewer should be a domain expert who is:
+
+*   Knowledgeable of the relevant subsystems
+*   Objective and capable of providing constructive feedback
+*   Available for the entire review period to lead the process
+
+Consider checking the contacts for various [team
+labels](/versions/9.1.0/contribute/maintainers-guide#team-labels).
+
+## Markdown vs Google Docs {#markdown-versus-gdocs}
+
+Decide what works best for you, since both are accepted.
+
+Benefits of using Google Docs:
+
+* Effective for brainstorming, since it is easy to get started with.
+* Collaborative editing.
+* Quick iteration.
+* Easy way to suggest edits.
+
+Benefits of using Markdown files:
+
+*   Clean URLs for linking.
+*   Explicit record of revisions.
+*   No forgetting to set up access rights before publicizing a link.
+*   Easily searchable with search engines.
+*   Future-proof: Plain text is not at the mercy of any specific tool
+    and doesn't require an Internet connection.
+*   It is possible to update them even if the author is not around anymore.
+*   They can be processed automatically (update/detect dead links, fetch
+    list of authors, etc.).
+
+You can choose to first iterate on a Google Doc, and then convert it to
+Markdown for posterity.
+
+### Using Google Docs {#gdocs}
+
+For consistency, use the [Bazel design doc template](
+https://docs.google.com/document/d/1cE5zrjrR40RXNg64XtRFewSv6FrLV6slGkkqxBumS1w/edit).
+It includes the necessary header and creates visual
+consistency with other Bazel related documents. To do that, click on **File** >
+**Make a copy** or click this link to [make a copy of the design doc
+template](https://docs.google.com/document/d/1cE5zrjrR40RXNg64XtRFewSv6FrLV6slGkkqxBumS1w/copy).
+
+To make your document readable to the world, click on
+**Share** > **Advanced** > **Change…**, and
+choose "On - Anyone with the link".  If you allow comments on the document,
+anyone can comment anonymously, even without a Google account.
+
+### Using Markdown {#markdown}
+
+Documents are stored on GitHub and use the
+[GitHub flavor of Markdown](https://guides.github.com/features/mastering-markdown/)
+([Specification](https://github.github.com/gfm/)).
+
+Create a PR to update an existing document. Significant changes should be
+reviewed by the document reviewers. Trivial changes (such as typos, formatting)
+can be approved by anyone.
+
+## Reviewer workflow {#reviewer-workflow}
+
+A reviewer comments, reviews and approves design documents.
+
+### General reviewer responsibilities {#reviewer-responsibilities}
+
+You're responsible for reviewing design documents, asking for additional
+information if needed, and approving a design that passes the review process.
+
+#### When you receive a new proposal {#receive-new-proposal}
+
+1.  Take a quick look at the document.
+1.  Comment if critical information is missing, or if the design doesn't fit
+    with the goals of the project.
+1.  Suggest additional reviewers.
+1.  Approve the PR when it is ready for review.
+
+#### During the review process {#during-process}
+
+1. Engage in a dialogue with the design author about issues that are problematic
+   or require clarification.
+1. If appropriate, invite comments from non-reviewers who should be aware of
+   the design.
+1. Decide which comments must be addressed by the author as a prerequisite to
+   approval.
+1. Write "LGTM" (_Looks Good To Me_) in the discussion thread when you are
+   happy with the current state of the proposal.
+
+Follow this process for all design review requests. Do not approve designs
+affecting Bazel if they are not in the
+[design index](https://github.com/bazelbuild/proposals).
+
+### Lead reviewer responsibilities {#lead-reviewer-responsibilities}
+
+You're responsible for making the go / no-go decision on implementation
+of a pending design. If you're not able to do this, you should identify a
+suitable delegate (reassign the PR to the delegate), or reassign the bug to a
+Bazel manager for further disposition.
+
+#### During the review process {#during-process}
+
+1.  Ensure that the comment and design iteration process moves forward
+    constructively.
+1.  Prior to approval, ensure that concerns from other reviewers have been
+    resolved.
+
+#### After approval by all reviewers {#after-approval}
+
+1.  Make sure there has been at least 1 week since the announcement on the
+    mailing list.
+1.  Make sure the PR updates the status.
+1.  Approve the PR sent by the proposal author.
+
+#### Rejecting designs {#reject-designs}
+
+1.  Make sure the PR author sends a PR; or send them a PR.
+1.  The PR updates the status of the document.
+1.  Add a comment to the document explaining why the design can't be approved in
+    its current state, and outlining next steps, if any (such as "revisit invalid
+    assumptions and resubmit").
diff --git a/versions/9.1.0/contribute/docs-style-guide.mdx b/versions/9.1.0/contribute/docs-style-guide.mdx
new file mode 100644
index 00000000..9c7b7a9b
--- /dev/null
+++ b/versions/9.1.0/contribute/docs-style-guide.mdx
@@ -0,0 +1,215 @@
+---
+title: 'Bazel docs style guide'
+---
+
+Thank you for contributing to Bazel's documentation. This serves as a quick
+documentation style guide to get you started. For any style questions not
+answered by this guide, follow the
+[Google developer documentation style guide](https://developers.google.com/style).
+
+## Defining principles {#principles}
+
+Bazel docs should uphold these principles:
+
+-  **Concise.** Use as few words as possible.
+-  **Clear.** Use plain language. Write without jargon for a fifth-grade
+   reading level.
+-  **Consistent.** Use the same words or phrases for repeated concepts
+   throughout the docs.
+-  **Correct.** Write in a way where the content stays correct for as long as
+   possible by avoiding time-based information and promises for the future.
+
+## Writing {#writing-tips}
+
+This section contains basic writing tips.
+
+### Headings {#headings}
+
+-  Page-level headings start at H2. (H1 headings are used as page titles.)
+-  Make headers as short as is sensible. This way, they fit in the TOC
+   without wrapping.
+
+   -  Yes: Permissions
+   -  No: A brief note on permissions
+
+-  Use sentence case for headings
+
+   -  Yes: Set up your workspace
+   -  No: Set Up Your Workspace
+
+-  Try to make headings task-based or actionable. If headings are conceptual,
+   it may be based around understanding, but write to what the user does.
+
+   -  Yes: Preserving graph order
+   -  No: On the preservation of graph order
+
+### Names {#names}
+
+-  Capitalize proper nouns, such as Bazel and Starlark.
+
+   -  Yes: At the end of the build, Bazel prints the requested targets.
+   -  No: At the end of the build, bazel prints the requested targets.
+
+-  Keep it consistent. Don't introduce new names for existing concepts. Where
+   applicable, use the term defined in the
+   [Glossary](/versions/9.1.0/reference/glossary).
+
+   -  For example, if you're writing about issuing commands on a
+      terminal, don't use both terminal and command line on the page.
+
+### Page scope {#page-scope}
+
+-  Each page should have one purpose and that should be defined at the
+   beginning. This helps readers find what they need quicker.
+
+   -  Yes: This page covers how to install Bazel on Windows.
+   -  No: (No introductory sentence.)
+
+-  At the end of the page, tell the reader what to do next. For pages where
+   there is no clear action, you can include links to similar concepts,
+   examples, or other avenues for exploration.
+
+### Subject {#subject}
+
+In Bazel documentation, the audience should primarily be users—the people using
+Bazel to build their software.
+
+-  Address your reader as "you". (If for some reason you can't use "you",
+   use gender-neutral language, such as they.)
+   -  Yes: To build Java code using Bazel,
+      you must install a JDK.
+   -  **MAYBE:** For users to build Java code with Bazel, they must install a JDK.
+   -  No: For a user to build Java code with
+      Bazel, he or she must install a JDK.
+
+-  If your audience is NOT general Bazel users, define the audience at the
+   beginning of the page or in the section. Other audiences can include
+   maintainers, contributors, migrators, or other roles.
+-  Avoid "we". In user docs, there is no author; just tell people what's
+   possible.
+   -  Yes: As Bazel evolves, you should update your code base to maintain
+      compatibility.
+   -  No: Bazel is evolving, and we will make changes to Bazel that at
+      times will be incompatible and require some changes from Bazel users.
+
+### Temporal {#temporal}
+
+Where possible, avoid terms that orient things in time, such as referencing
+specific dates (Q2 2022) or saying "now", "currently", or "soon."  These go
+stale quickly and could be incorrect if it's a future projection. Instead,
+specify a version level instead, such as "Bazel X.x and higher supports
+\ or a GitHub issue link.
+
+-  Yes: Bazel 0.10.0 or later supports
+   remote caching.
+-  No: Bazel will soon support remote
+   caching, likely in October 2017.
+
+### Tense {#tense}
+
+-  Use present tense. Avoid past or future tense unless absolutely necessary
+   for clarity.
+   -  Yes: Bazel issues an error when it
+      finds dependencies that don't conform to this rule.
+   -  No:  If Bazel finds a dependency that
+      does not conform to this rule, Bazel will issue an error.
+
+-  Where possible, use active voice (where a subject acts upon an object) not
+   passive voice (where an object is acted upon by a subject). Generally,
+   active voice makes sentences clearer because it shows who is responsible. If
+   using active voice detracts from clarity, use passive voice.
+   -  Yes: Bazel initiates X and uses the
+      output to build Y.
+   -  No: X is initiated by Bazel and then
+      afterward Y will be built with the output.
+
+### Tone {#tone}
+
+Write with a business friendly tone.
+
+-  Avoid colloquial language. It's harder to translate phrases that are
+   specific to English.
+   -  Yes: Good rulesets
+   -  No: So what is a good ruleset?
+
+-  Avoid overly formal language. Write as though you're explaining the
+   concept to someone who is curious about tech, but doesn't know the details.
+
+## Formatting {#format}
+
+### File type {#file-type}
+
+For readability, wrap lines at 80 characters. Long links or code snippets
+may be longer, but should start on a new line. For example:
+
+Note: Where possible, use Markdown instead of HTML in your files. Follow the
+[GitHub Markdown Syntax Guide](https://guides.github.com/features/mastering-markdown/#syntax)
+for recommended Markdown style.
+
+### Links {#links}
+
+-  Use descriptive link text instead of "here" or "below". This practice
+   makes it easier to scan a doc and is better for screen readers.
+   -  Yes: For more details, see [Installing Bazel].
+   -  No: For more details, see [here].
+
+-  End the sentence with the link, if possible.
+   -  Yes: For more details, see [link].
+   -  No: See [link] for more information.
+
+### Lists {#lists}
+
+-  Use an ordered list to describe how to accomplish a task with steps
+-  Use an unordered list to list things that aren't task based. (There should
+   still be an order of sorts, such as alphabetical, importance, etc.)
+-  Write with parallel structure. For example:
+   1. Make all the list items sentences.
+   1. Start with verbs that are the same tense.
+   1. Use an ordered list if there are steps to follow.
+
+### Placeholders {#placeholders}
+
+-  Use angle brackets to denote a variable that users should change.
+   In Markdown, escape the angle brackets with a back slash: `\`.
+   -  Yes: `bazel help `: Prints
+      help and options for ``
+   -  No: bazel help _command_: Prints help
+      and options for "command"
+
+-  Especially for complicated code samples, use placeholders that make sense
+   in context.
+
+### Table of contents {#toc}
+
+Use the auto-generated TOC supported by the site. Don't add a manual TOC.
+
+## Code {#code}
+
+Code samples are developers' best friends. You probably know how to write these
+already, but here are a few tips.
+
+If you're referencing a small snippet of code, you can embed it in a sentence.
+If you want the reader to use the code, such as copying a command, use a code
+block.
+
+### Code blocks {#code-blocks}
+
+-  Keep it short. Eliminate all redundant or unnecessary text from a code
+   sample.
+-  In Markdown, specify the type of code block by adding the sample's language.
+
+```
+```shell
+...
+```
+
+-  Separate commands and output into different code blocks.
+
+### Inline code formatting {#code-format}
+
+-  Use code style for filenames, directories, paths, and small bits of code.
+-  Use inline code styling instead of _italics_, "quotes," or **bolding**.
+   -  Yes: `bazel help `: Prints
+      help and options for ``
+   -  No: bazel help _command_: Prints help
+      and options for "command"
diff --git a/versions/9.1.0/contribute/docs.mdx b/versions/9.1.0/contribute/docs.mdx
new file mode 100644
index 00000000..845e5762
--- /dev/null
+++ b/versions/9.1.0/contribute/docs.mdx
@@ -0,0 +1,40 @@
+---
+title: 'Contribute to Bazel documentation'
+---
+
+Thank you for contributing to Bazel's documentation! There are a few ways to
+help create better docs for our community.
+
+## Documentation types
+
+This site includes a few types of content.
+
+ - *Narrative documentation*, which is written by technical writers and
+   engineers. Most of this site is narrative documentation that covers
+   conceptual and task-based guides.
+ - *Reference documentation*, which is generated documentation from code comments.
+   You can't make changes to the reference doc pages directly, but instead need
+   to change their source.
+
+## Documentation infrastructure
+
+Bazel documentation is served from Google and the source files are mirrored in
+Bazel's GitHub repository. You can make changes to the source files in GitHub.
+If approved, you can merge the changes and a Bazel maintainer will update the
+website source to publish your updates.
+
+## Small changes
+
+You can approach small changes, such as fixing errors or typos, in a couple of
+ways.
+
+ - **Pull request**. You can create a pull request in GitHub with the
+   [web-based editor](https://docs.github.com/repositories/working-with-files/managing-files/editing-files) or on a branch.
+ - **Bug**. You can file a bug with details and suggested changes and the Bazel
+   documentation owners will make the update.
+
+## Large changes
+
+If you want to make substantial changes to existing documentation or propose
+new documentation, you can either create a pull request or start with a Google
+doc and contact the Bazel Owners to collaborate.
diff --git a/versions/9.1.0/contribute/index.mdx b/versions/9.1.0/contribute/index.mdx
new file mode 100644
index 00000000..fdf7c5fb
--- /dev/null
+++ b/versions/9.1.0/contribute/index.mdx
@@ -0,0 +1,79 @@
+---
+title: 'Contributing to Bazel'
+---
+
+There are many ways to help the Bazel project and ecosystem.
+
+## Provide feedback {#feedback}
+
+As you use Bazel, you may find things that can be improved.
+You can help by [reporting issues](http://github.com/bazelbuild/bazel/issues)
+when:
+
+   - Bazel crashes or you encounter a bug that can [only be resolved using `bazel
+     clean`](/versions/9.1.0/run/build#correct-incremental-rebuilds).
+   - The documentation is incomplete or unclear. You can also report issues
+     from the page you are viewing by using the "Create issue"
+     link at the top right corner of the page.
+   - An error message could be improved.
+
+## Participate in the community {#community}
+
+You can engage with the Bazel community by:
+
+   - Answering questions [on Stack Overflow](
+     https://stackoverflow.com/questions/tagged/bazel).
+   - Helping other users [on Slack](https://slack.bazel.build).
+   - Improving documentation or [contributing examples](
+     https://github.com/bazelbuild/examples).
+   - Sharing your experience or your tips, for example, on a blog or social media.
+
+## Contribute code {#contribute-code}
+
+Bazel is a large project and making a change to the Bazel source code
+can be difficult.
+
+You can contribute to the Bazel ecosystem by:
+
+   - Helping rules maintainers by contributing pull requests.
+   - Creating new rules and open-sourcing them.
+   - Contributing to Bazel-related tools, for example, migration tools.
+   - Improving Bazel integration with other IDEs and tools.
+
+Before making a change, [create a GitHub
+issue](http://github.com/bazelbuild/bazel/issues)
+or email [bazel-discuss@](mailto:bazel-discuss@googlegroups.com).
+
+The most helpful contributions fix bugs or add features (as opposed
+to stylistic, refactoring, or "cleanup" changes). Your change should
+include tests and documentation, keeping in mind backward-compatibility,
+portability, and the impact on memory usage and performance.
+
+To learn about how to submit a change, see the
+[patch acceptance process](/versions/9.1.0/contribute/patch-acceptance).
+
+## Bazel's code description {#code-description}
+
+Bazel has a large codebase with code in multiple locations. See the [codebase guide](/versions/9.1.0/contribute/codebase) for more details.
+
+Bazel is organized as follows:
+
+*  Client code is in `src/main/cpp` and provides the command-line interface.
+*  Protocol buffers are in `src/main/protobuf`.
+*  Server code is in `src/main/java` and `src/test/java`.
+   *  Core code which is mostly composed of [SkyFrame](/versions/9.1.0/reference/skyframe)
+      and some utilities.
+   *  Built-in rules are in `com.google.devtools.build.lib.rules` and in
+     `com.google.devtools.build.lib.bazel.rules`. You might want to read about
+     the [Challenges of Writing Rules](/versions/9.1.0/rules/challenges) first.
+*  Java native interfaces are in `src/main/native`.
+*  Various tooling for language support are described in the list in the
+   [compiling Bazel](/versions/9.1.0/install/compile-source) section.
+
+### Searching Bazel's source code {#search-code}
+
+To quickly search through Bazel's source code, use
+[Bazel Code Search](https://source.bazel.build/). You can navigate Bazel's
+repositories, branches, and files. You can also view history, diffs, and blame
+information. To learn more, see the
+[Bazel Code Search User Guide](/versions/9.1.0/contribute/search).
diff --git a/versions/9.1.0/contribute/maintainers-guide.mdx b/versions/9.1.0/contribute/maintainers-guide.mdx
new file mode 100644
index 00000000..420dd2fa
--- /dev/null
+++ b/versions/9.1.0/contribute/maintainers-guide.mdx
@@ -0,0 +1,203 @@
+---
+title: 'Guide for Bazel Maintainers'
+---
+
+This is a guide for the maintainers of the Bazel open source project.
+
+If you are looking to contribute to Bazel, please read [Contributing to
+Bazel](/versions/9.1.0/contribute) instead.
+
+The objectives of this page are to:
+
+1. Serve as the maintainers' source of truth for the project’s contribution
+   process.
+1. Set expectations between the community contributors and the project
+   maintainers.
+
+Bazel's [core group of contributors](/versions/9.1.0/contribute/policy) has dedicated
+subteams to manage aspects of the open source project. These are:
+
+* **Release Process**: Manage Bazel's release process.
+* **Green Team**: Grow a healthy ecosystem of rules and tools.
+* **Developer Experience Gardeners**: Encourage external contributions, review
+  issues and pull requests, and make our development workflow more open.
+
+## Releases {#releases}
+
+* [Release Playbook](https://github.com/bazelbuild/continuous-integration/blob/master/docs/release-playbook.md)
+* [Testing local changes with downstream projects](https://github.com/bazelbuild/continuous-integration/blob/master/docs/downstream-testing.md)
+
+## Continuous Integration {#integration}
+
+Read the Green team's guide to Bazel's CI infrastructure on the
+[bazelbuild/continuous-integration](https://github.com/bazelbuild/continuous-integration/blob/master/buildkite/README.md)
+repository.
+
+## Lifecycle of an Issue {#lifecycle-issue}
+
+1. A user creates an issue by choosing one of the
+[issue templates](https://github.com/bazelbuild/bazel/issues/new/choose)
+   and it enters the pool of [unreviewed open
+   issues](https://github.com/bazelbuild/bazel/issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aopen+-label%3Auntriaged+-label%3Ap2+-label%3Ap1+-label%3Ap3+-label%3Ap4+-label%3Ateam-Starlark+-label%3Ateam-Rules-CPP+-label%3Ateam-Rules-Java+-label%3Ateam-XProduct+-label%3Ateam-Android+-label%3Ateam-Apple+-label%3Ateam-Configurability++-label%3Ateam-Performance+-label%3Ateam-Rules-Server+-label%3Ateam-Core+-label%3Ateam-Rules-Python+-label%3Ateam-Remote-Exec+-label%3Ateam-Local-Exec+-label%3Ateam-Bazel).
+1. A member on the Developer Experience (DevEx) subteam rotation reviews the
+   issue.
+   1. If the issue is **not a bug** or a **feature request**, the DevEx member
+      will usually close the issue and redirect the user to
+      [StackOverflow](https://stackoverflow.com/questions/tagged/bazel) and
+      [bazel-discuss](https://groups.google.com/forum/#!forum/bazel-discuss) for
+      higher visibility on the question.
+   1. If the issue belongs in one of the rules repositories owned by the
+      community, like [rules_apple](https://github.com.bazelbuild/rules_apple),
+      the DevEx member will [transfer this issue](https://docs.github.com/en/free-pro-team@latest/github/managing-your-work-on-github/transferring-an-issue-to-another-repository)
+      to the correct repository.
+   1. If the issue is vague or has missing information, the DevEx member will
+      assign the issue back to the user to request for more information before
+      continuing. This usually occurs when the user does not choose the right
+      [issue template](https://github.com/bazelbuild/bazel/issues/new/choose)
+       or provides incomplete information.
+1. After reviewing the issue, the DevEx member decides if the issue requires
+   immediate attention. If it does, they will assign the **P0**
+   [priority](#priority) label and an owner from the list of team leads.
+1. The DevEx member assigns the `untriaged` label and exactly one [team
+   label](#team-labels) for routing.
+1. The DevEx member also assigns exactly one `type:` label, such as `type: bug`
+   or `type: feature request`, according to the type of the issue.
+1. For platform-specific issues, the DevEx member assigns one `platform:` label,
+   such as `platform:apple` for Mac-specific issues.
+1. If the issue is low priority and can be worked on by a new community
+   contributor, the DevEx member assigns the `good first issue` label.
+At this stage, the issue enters the pool of [untriaged open
+issues](https://github.com/bazelbuild/bazel/issues?q=is%3Aissue+is%3Aopen+label%3Auntriaged).
+
+Each Bazel subteam will triage all issues under labels they own, preferably on a
+weekly basis. The subteam will review and evaluate the issue and provide a
+resolution, if possible. If you are an owner of a team label, see [this section
+](#label-own) for more information.
+
+When an issue is resolved, it can be closed.
+
+## Lifecycle of a Pull Request {#lifecycle-pull-request}
+
+1. A user creates a pull request.
+1. If you a member of a Bazel team and sending a PR against your own area,
+   you are responsible for assigning your team label and finding the best
+   reviewer.
+1. Otherwise, during daily triage, a DevEx member assigns one
+   [team label](#team-labels) and the team's technical lead (TL) for routing.
+   1. The TL may optionally assign someone else to review the PR.
+1. The assigned reviewer reviews the PR and works with the author until it is
+   approved or dropped.
+1. If approved, the reviewer **imports** the PR's commit(s) into Google's
+   internal version control system for further tests. As Bazel is the same build
+   system used internally at Google, we need to test all PR commits against the
+   internal test suite. This is the reason why we do not merge PRs directly.
+1. If the imported commit passes all internal tests, the commit will be squashed
+   and exported back out to GitHub.
+1. When the commit merges into master, GitHub automatically closes the PR.
+
+## My team owns a label. What should I do? {#label-own}
+
+Subteams need to triage all issues in the [labels they own](#team-labels),
+preferably on a weekly basis.
+
+### Issues {#issues}
+
+1. Filter the list of issues by your team label **and** the `untriaged` label.
+1. Review the issue.
+1. Identify a [priority level](#priority) and assign the label.
+  1. The issue may have already been prioritized by the DevEx subteam if it's a
+     P0. Re-prioritize if needed.
+  1. Each issue needs to have exactly one [priority label](#priority). If an
+     issue is either P0 or P1 we assume that is actively worked on.
+1. Remove the `untriaged` label.
+
+Note that you need to be in the [bazelbuild
+organization](https://github.com/bazelbuild) to be able to add or remove labels.
+
+### Pull Requests {#pull-requests}
+
+1. Filter the list of pull requests by your team label.
+1. Review open pull requests.
+  1. **Optional**: If you are assigned for the review but is not the right fit
+  for it, re-assign the appropriate reviewer to perform a code review.
+1. Work with the pull request creator to complete a code review.
+1. Approve the PR.
+1. Ensure that all tests pass.
+1. Import the patch to the internal version control system and run the internal
+   presubmits.
+1. Submit the internal patch. If the patch submits and exports successfully, the
+   PR will be closed automatically by GitHub.
+
+## Priority {#priority}
+
+The following definitions for priority will be used by the maintainers to triage
+issues.
+
+* [**P0**](https://github.com/bazelbuild/bazel/labels/P0) - Major broken
+  functionality that causes a Bazel release (minus release candidates) to be
+  unusable, or a downed service that severely impacts development of the Bazel
+  project. This includes regressions introduced in a new release that blocks a
+  significant number of users, or an incompatible breaking change that was not
+  compliant to the [Breaking
+  Change](https://docs.google.com/document/d/1q5GGRxKrF_mnwtaPKI487P8OdDRh2nN7jX6U-FXnHL0/edit?pli=1#heading=h.ceof6vpkb3ik)
+  policy. No practical workaround exists.
+* [**P1**](https://github.com/bazelbuild/bazel/labels/P1) - Critical defect or
+  feature which should be addressed in the next release, or a serious issue that
+  impacts many users (including the development of the Bazel project), but a
+  practical workaround exists. Typically does not require immediate action. In
+  high demand and planned in the current quarter's roadmap.
+* [**P2**](https://github.com/bazelbuild/bazel/labels/P2) - Defect or feature
+  that should be addressed but we don't currently work on. Moderate live issue
+  in a released Bazel version that is inconvenient for a user that needs to be
+  addressed in an future release and/or an easy workaround exists.
+* [**P3**](https://github.com/bazelbuild/bazel/labels/P3) - Desirable minor bug
+  fix or enhancement with small impact. Not prioritized into Bazel roadmaps or
+  any imminent release, however community contributions are encouraged.
+* [**P4**](https://github.com/bazelbuild/bazel/labels/P4) - Low priority defect
+  or feature request that is unlikely to get closed. Can also be kept open for a
+  potential re-prioritization if more users are impacted.
+
+## Team labels {#team-labels}
+
+*   [`team-Android`](https://github.com/bazelbuild/bazel/labels/team-Android): Issues for Android team
+    *   Contact: [ahumesky](https://github.com/ahumesky)
+*   [`team-Bazel`](https://github.com/bazelbuild/bazel/labels/team-Bazel): General Bazel product/strategy issues
+    * Contact: [meisterT](https://github.com/meisterT)
+*   [`team-CLI`](https://github.com/bazelbuild/bazel/labels/team-CLI): Console UI
+    * Contact: [meisterT](https://github.com/meisterT)
+*   [`team-Configurability`](https://github.com/bazelbuild/bazel/labels/team-Configurability): Issues for Configurability team. Includes: Core build configuration and transition system. Does *not* include: Changes to new or existing flags
+    * Contact: [gregestren](https://github.com/gregestren)
+*   [`team-Core`](https://github.com/bazelbuild/bazel/labels/team-Core): Skyframe, bazel query, BEP, options parsing, bazelrc
+    * Contact: [haxorz](https://github.com/haxorz)
+*   [`team-Documentation`](https://github.com/bazelbuild/bazel/labels/team-Documentation): Issues for Documentation team
+*   [`team-ExternalDeps`](https://github.com/bazelbuild/bazel/labels/team-ExternalDeps): External dependency handling, Bzlmod, remote repositories, WORKSPACE file
+    * Contact: [meteorcloudy](https://github.com/meteorcloudy)
+*   [`team-Loading-API`](https://github.com/bazelbuild/bazel/labels/team-Loading-API): BUILD file and macro processing: labels, package(), visibility, glob
+    * Contact: [brandjon](https://github.com/brandjon)
+*   [`team-Local-Exec`](https://github.com/bazelbuild/bazel/labels/team-Local-Exec): Issues for Execution (Local) team
+    * Contact: [meisterT](https://github.com/meisterT)
+*   [`team-OSS`](https://github.com/bazelbuild/bazel/labels/team-OSS): Issues for Bazel OSS team: installation, release process, Bazel packaging, website, docs infrastructure
+    * Contact: [meteorcloudy](https://github.com/meteorcloudy)
+*   [`team-Performance`](https://github.com/bazelbuild/bazel/labels/team-Performance): Issues for Bazel Performance team
+    * Contact: [meisterT](https://github.com/meisterT)
+*   [`team-Remote-Exec`](https://github.com/bazelbuild/bazel/labels/team-Remote-Exec): Issues for Execution (Remote) team
+    * Contact: [coeuvre](https://github.com/coeuvre)
+*   [`team-Rules-API`](https://github.com/bazelbuild/bazel/labels/team-Rules-API): API for writing rules/aspects: providers, runfiles, actions, artifacts
+    * Contact: [comius](https://github.com/comius)
+*   [`team-Rules-CPP`](https://github.com/bazelbuild/bazel/labels/team-Rules-CPP) / [`team-Rules-ObjC`](https://github.com/bazelbuild/bazel/labels/team-Rules-ObjC): Issues for C++/Objective-C rules, including native Apple rule logic
+    * Contact: [pzembrod](https://github.com/pzembrod)
+*   [`team-Rules-Java`](https://github.com/bazelbuild/bazel/labels/team-Rules-Java): Issues for Java rules
+    * Contact: [hvadehra](https://github.com/hvadehra)
+*   [`team-Rules-Python`](https://github.com/bazelbuild/bazel/labels/team-Rules-Python): Issues for the native Python rules
+    * Contact: [rickeylev](https://github.com/rickeylev)
+*   [`team-Rules-Server`](https://github.com/bazelbuild/bazel/labels/team-Rules-Server): Issues for server-side rules included with Bazel
+    * Contact: [comius](https://github.com/comius)
+*   [`team-Starlark-Integration`](https://github.com/bazelbuild/bazel/labels/team-Starlark-Integration): Non-API Bazel + Starlark integration. Includes: how Bazel triggers the Starlark interpreter, Stardoc, builtins injection, character encoding.  Does *not* include: BUILD or .bzl language issues.
+    * Contact: [brandjon](https://github.com/brandjon)
+*   [`team-Starlark-Interpreter`](https://github.com/bazelbuild/bazel/labels/team-Starlark-Interpreter): Issues for the Starlark interpreter (anything in [java.net.starlark](https://github.com/bazelbuild/bazel/tree/master/src/main/java/net/starlark/java)). BUILD and .bzl API issues (which represent Bazel's *integration* with Starlark) go in `team-Build-Language`.
+    * Contact: [brandjon](https://github.com/brandjon)
+
+For new issues, we deprecated the `category: *` labels in favor of the team
+labels.
+
+See the full list of labels [here](https://github.com/bazelbuild/bazel/labels).
diff --git a/versions/9.1.0/contribute/naming.mdx b/versions/9.1.0/contribute/naming.mdx
new file mode 100644
index 00000000..92d11da5
--- /dev/null
+++ b/versions/9.1.0/contribute/naming.mdx
@@ -0,0 +1,70 @@
+---
+title: 'Naming a Bazel related project'
+---
+
+First, thank you for contributing to the Bazel ecosystem! Please reach out to
+the Bazel community on the
+[bazel-discuss mailing list](https://groups.google.com/forum/#!forum/bazel-discuss
+) to share your project and its suggested name.
+
+If you are building a Bazel related tool or sharing your Skylark rules,
+we recommend following these guidelines for the name of your project:
+
+## Naming Starlark rules {#name-starlark-rules}
+
+See [Deploying new Starlark rules](/versions/9.1.0/rules/deploying)
+in the docs.
+
+## Naming other Bazel related tools {#name-related-tools}
+
+This section applies if you are building a tool to enrich the Bazel ecosystem.
+For example, a new IDE plugin or a new build system migrator.
+
+Picking a good name for your tool can be hard. If we’re not careful and use too
+many codenames, the Bazel ecosystem could become very difficult to understand
+for newcomers.
+
+Follow these guidelines for naming Bazel tools:
+
+1. Prefer **not introducing a new brand name**: "*Bazel*" is already a new brand
+for our users, we should avoid confusing them with too many new names.
+
+2. Prefer **using a name that includes "Bazel"**: This helps to express that it
+is a Bazel related tool, it also helps people find it with a search engine.
+
+3. Prefer **using names that are descriptive about what the tool is doing**:
+Ideally, the name should not need a subtitle for users to have a first good
+guess at what the tool does. Using english words separated by spaces is a good
+way to achieve this.
+
+4. **It is not a requirement to use a floral or food theme**: Bazel evokes
+[basil](https://en.wikipedia.org/wiki/Basil), the plant. You do not need to
+look for a name that is a plant, food or that relates to "basil."
+
+5. **If your tool relates to another third party brand, use it only as a
+descriptor**: For example, use "Bazel migrator for Cmake" instead of
+"Cmake Bazel migrator".
+
+These guidelines also apply to the GitHub repository URL. Reading the repository
+URL should help people understand what the tool does. Of course, the repository
+name can be shorter and must use dashes instead of spaces and lower case letters.
+
+Examples of good names:
+
+* *Bazel for Eclipse*: Users will understand that if they want to use Bazel
+  with Eclipse, this is where they should be looking. It uses a third party brand
+  as a descriptor.
+* *Bazel buildfarm*: A "buildfarm" is a
+  [compile farm](https://en.wikipedia.org/wiki/Compile_farm). Users
+  will understand that this project relates to building on servers.
+
+Examples of names to avoid:
+
+* *Ocimum*: The [scientific name of basil](https://en.wikipedia.org/wiki/Ocimum)
+  does not relate enough to the Bazel project.
+* *Bazelizer*: The tool behind this name could do a lot of things, this name is
+   not descriptive enough.
+
+Note that these recommendations are aligned with the
+[guidelines](https://opensource.google.com/docs/releasing/preparing/#name)
+Google uses when open sourcing a project.
diff --git a/versions/9.1.0/contribute/patch-acceptance.mdx b/versions/9.1.0/contribute/patch-acceptance.mdx
new file mode 100644
index 00000000..da46be0e
--- /dev/null
+++ b/versions/9.1.0/contribute/patch-acceptance.mdx
@@ -0,0 +1,50 @@
+---
+title: 'Patch Acceptance Process'
+---
+
+This page outlines how contributors can propose and make changes to the Bazel
+code base.
+
+1. Read the [Bazel Contribution policy](/versions/9.1.0/contribute/policy).
+1. Create a [GitHub issue](https://github.com/bazelbuild/bazel/) to
+   discuss your plan and design. Pull requests that change or add behavior
+   need a corresponding issue for tracking.
+1. If you're proposing significant changes, write a
+   [design document](/versions/9.1.0/contribute/design-documents).
+1. Ensure you've signed a [Contributor License
+   Agreement](https://cla.developers.google.com).
+1. Prepare a git commit that implements the feature. Don't forget to add tests
+   and update the documentation. If your change has user-visible effects, please
+   [add release notes](/versions/9.1.0/contribute/release-notes). If it is an incompatible change,
+   read the [guide for rolling out breaking changes](/versions/9.1.0/contribute/breaking-changes).
+1. Create a pull request on
+   [GitHub](https://github.com/bazelbuild/bazel/pulls). If you're new to GitHub,
+   read [about pull
+   requests](https://help.github.com/articles/about-pull-requests/). Note that
+   we restrict permissions to create branches on the main Bazel repository, so
+   you will need to push your commit to [your own fork of the
+   repository](https://help.github.com/articles/working-with-forks/).
+1. A Bazel maintainer should assign you a reviewer within two business days
+   (excluding holidays in the USA and Germany). If you aren't assigned a
+   reviewer in that time, you can request one by emailing
+   [bazel-discuss@googlegroups.com]
+   (mailto:bazel-discuss@googlegroups.com).
+1. Work with the reviewer to complete a code review. For each change, create a
+   new commit and push it to make changes to your pull request. If the review
+   takes too long (for instance, if the reviewer is unresponsive), send an email to
+   [bazel-discuss@googlegroups.com]
+   (mailto:bazel-discuss@googlegroups.com).
+1. After your review is complete, a Bazel maintainer applies your patch to
+   Google's internal version control system.
+
+   This triggers internal presubmit checks
+   that may suggest more changes. If you haven't expressed a preference, the
+   maintainer submitting your change  adds "trivial" changes (such as
+   [linting](https://en.wikipedia.org/wiki/Lint_(software))) that don't affect
+   design. If deeper changes are required or you'd prefer to apply
+   changes directly, you and the reviewer should communicate preferences
+   clearly in review comments.
+
+   After internal submission, the patch is exported as a Git commit,
+   at which point the GitHub pull request is closed. All final changes
+   are attributed to you.
diff --git a/versions/9.1.0/contribute/policy.mdx b/versions/9.1.0/contribute/policy.mdx
new file mode 100644
index 00000000..717d299f
--- /dev/null
+++ b/versions/9.1.0/contribute/policy.mdx
@@ -0,0 +1,77 @@
+translation: human
+page_type: lcat
+
+---
+title: 'Contribution policy'
+---
+
+This page covers Bazel's governance model and contribution policy.
+
+## Governance model
+
+The [Bazel project](https://github.com/bazelbuild) is led and managed by Google
+and has a large community of contributors outside of Google. Some Bazel
+components (such as specific rules repositories under the
+[bazelbuild](https://github.com/bazelbuild) organization) are led,
+maintained, and managed by members of the community. The Google Bazel team
+reviews suggestions to add community-owned repositories (such as rules) to the
+[bazelbuild](https://github.com/bazelbuild) GitHub organization.
+
+### Contributor roles
+
+Here are outlines of the roles in the Bazel project, including their
+responsibilities:
+
+*   **Owners**: The Google Bazel team. Owners are responsible for:
+    *   Strategy, maintenance, and leadership of the Bazel project.
+    *   Building and maintaining Bazel's core functionality.
+    *   Appointing Maintainers and approving new repositories.
+*   **Maintainers**: The Google Bazel team and designated GitHub users.
+    Maintainers are responsible for:
+    *   Building and maintaining the primary functionality of their repository.
+    *   Reviewing and approving contributions to areas of the Bazel code base.
+    *   Supporting users and contributors with timely and transparent issue
+        management, PR review, and documentation.
+    *   Releasing, testing and collaborating with Bazel Owners.
+*   **Contributors**: All users who contribute code or documentation to the
+    Bazel project.
+    *   Creating well-written PRs to contribute to Bazel's codebase and
+        documentation.
+    *   Using standard channels, such as GitHub Issues, to propose changes and
+        report issues.
+
+### Becoming a Maintainer
+
+Bazel Owners may appoint Maintainers to lead well-defined areas of code, such as
+rule sets. Contributors with a record of consistent, responsible past
+contributions who are planning major contributions in the future could be
+considered to become qualified Maintainers.
+
+## Contribution policy {#contribution-policy}
+
+The Bazel project accepts contributions from external contributors. Here are the
+contribution policies for Google-managed and Community-managed areas of code.
+
+*   **Licensing**. All Maintainers and Contributors must sign the
+    [Google’s Contributor License Agreement](https://cla.developers.google.com/clas).
+*   **Contributions**. Owners and Maintainers should make every effort to accept
+    worthwhile contributions. All contributions must be:
+    *   Well written and well tested
+    *   Discussed and approved by the Maintainers of the relevant area of code.
+        Discussions and approvals happen on GitHub Issues and in GitHub PRs.
+        Larger contributions require a
+        [design review](/versions/9.1.0/contribute/design-documents).
+    *   Added to Bazel's Continuous Integration system if not already present.
+    *   Supportable and aligned with Bazel product direction
+*   **Code review**. All changes in all `bazelbuild` repositories require
+    review:
+    *   All PRs must be approved by an Owner or Maintainer.
+    *   Only Owners and Maintainers can merge PRs.
+*   **Compatibility**. Owners may need to reject or request modifications to PRs
+    in the unlikely event that the change requires substantial modifications to
+    internal Google systems.
+*   **Documentation**. Where relevant, feature contributions should include
+    documentation updates.
+
+For more details on contributing to Bazel, see our
+[contribution guidelines](/versions/9.1.0/contribute/).
diff --git a/versions/9.1.0/contribute/release-notes.mdx b/versions/9.1.0/contribute/release-notes.mdx
new file mode 100644
index 00000000..cd32e141
--- /dev/null
+++ b/versions/9.1.0/contribute/release-notes.mdx
@@ -0,0 +1,76 @@
+---
+title: 'Writing release notes'
+---
+
+This document is targeted at Bazel contributors.
+
+Commit descriptions in Bazel include a `RELNOTES:` tag followed by a release
+note. This is used by the Bazel team to track changes in each release and write
+the release announcement.
+
+## Overview {#overview}
+
+* Is your change a bugfix? In that case, you don't need a release note. Please
+  include a reference to the GitHub issue.
+
+* If the change adds / removes / changes Bazel in a user-visible way, then it
+  may be advantageous to mention it.
+
+If the change is significant, follow the [design document
+policy](/versions/9.1.0/contribute/design-documents) first.
+
+## Guidelines {#guidelines}
+
+The release notes will be read by our users, so it should be short (ideally one
+sentence), avoid jargon (Bazel-internal terminology), should focus on what the
+change is about.
+
+* Include a link to the relevant documentation. Almost any release note should
+  contain a link. If the description mentions a flag, a feature, a command name,
+  users will probably want to know more about it.
+
+* Use backquotes around code, symbols, flags, or any word containing an
+  underscore.
+
+* Do not just copy and paste bug descriptions. They are often cryptic and only
+  make sense to us and leave the user scratching their head. Release notes are
+  meant to explain what has changed and why in user-understandable language.
+
+* Always use present tense and the format "Bazel now supports Y" or "X now does
+  Z." We don't want our release notes to sound like bug entries. All release
+  note entries should be informative and use a consistent style and language.
+
+* If something has been deprecated or removed, use "X has been deprecated" or "X
+  has been removed." Not "is removed" or "was removed."
+
+* If Bazel now does something differently, use "X now $newBehavior instead of
+  $oldBehavior" in present tense. This lets the user know in detail what to
+  expect when they use the new release.
+
+* If Bazel now supports or no longer supports something, use "Bazel now supports
+  / no longer supports X".
+
+* Explain why something has been removed / deprecated / changed. One sentence is
+  enough but we want the user to be able to evaluate impact on their builds.
+
+* Do NOT make any promises about future functionality. Avoid "this flag will be
+  removed" or "this will be changed." It introduces uncertainty. The first thing
+  the user will wonder is "when?" and we don't want them to start worrying about
+  their current builds breaking at some unknown time.
+
+## Process {#process}
+
+As part of the [release
+process](https://github.com/bazelbuild/continuous-integration/blob/master/docs/release-playbook.md),
+we collect the `RELNOTES` tags of every commit. We copy everything in a [Google
+Doc](https://docs.google.com/document/d/1wDvulLlj4NAlPZamdlEVFORks3YXJonCjyuQMUQEmB0/edit)
+where we review, edit, and organize the notes.
+
+The release manager sends an email to the
+[bazel-dev](https://groups.google.com/forum/#!forum/bazel-dev) mailing-list.
+Bazel contributors are invited to contribute to the document and make sure
+their changes are correctly reflected in the announcement.
+
+Later, the announcement will be submitted to the [Bazel
+blog](https://blog.bazel.build/), using the [bazel-blog
+repository](https://github.com/bazelbuild/bazel-blog/tree/master/_posts).
diff --git a/versions/9.1.0/contribute/search.mdx b/versions/9.1.0/contribute/search.mdx
new file mode 100644
index 00000000..c5b8cb84
--- /dev/null
+++ b/versions/9.1.0/contribute/search.mdx
@@ -0,0 +1,276 @@
+---
+title: 'Searching the codebase'
+---
+
+## Product overview {:#product-overview}
+
+Bazel's [code search and source browsing interface](https://source.bazel.build)
+is a web-based tool for browsing Bazel source code repositories. You can
+use these features to navigate among different repositories, branches, and
+files. You can also view history, diffs, and blame information.
+
+## Getting started {:#getting-started}
+
+Note: For the best experience, use the latest version of Chrome, Safari, or
+Firefox.
+
+To access the code search and source browsing interface, open
+[https://source.bazel.build](https://source.bazel.build) in your web browser.
+
+The main screen appears. This screen contains the following components:
+
+1. The Breadcrumb toolbar. This toolbar displays your current location in the
+repository and allows you to move quickly to another location such as another
+repository, or another location within a repository, such as a file, branch, or
+commit.
+
+1. A list of repositories that you can browse.
+
+At the top of the screen is a search box. You can use this box to search for
+specific files and code.
+
+## Working with repositories {:#working-with-repositories}
+
+### Opening a repository {:#opening-a-repository}
+
+To open a repository, click its name from the main screen.
+
+Alternatively, you can use the Breadcrumb toolbar to browse for a
+specificrepository. This toolbar displays your current location in the
+repository and allows you to move quickly to another location such as another
+repository, or another location within a repository, such as a file, branch, or
+commit.
+
+### Switch repositories {:#switch-repositories}
+
+To switch to a different repository, select the repository from the Breadcrumb toolbar.
+
+### View a repository at a specific commit {:#view-a-repository-at-a-specific-commit}
+
+To view a repository at a specific commit:
+
+1. From the view of the repository, select the file.
+1. From the Breadcrumb toolbar, open the **Branch** menu.
+1. In the submenu that appears, click **Commit**.
+1. Select the commit you want to view.
+
+The interface now shows the repository as it existed at that commit.
+
+### Open a branch, commit, or tag {:#open-a-branch-commit-or-tag}
+
+By default, the code search and source browsing interface opens a repository to
+the default branch.  To open a different branch, from the Breadcrumb toolbar,
+click the **Branch/Commit/Tag** menu. A submenu opens, allowing you to select a
+branch using a branch name, a tag name, or through a search box.
+
+*  To select a branch using a branch name, select **Branch** and then click the
+   name of the branch.
+*  To select a branch using a tag name, select **Tag** and
+   then click the tag name.
+*  To select a branch using a commit id, select **Commit** and then click the
+   commit id.
+*  To search for a branch, commit, or tag, select the corresponding item and
+   type a search term in the search box.
+
+## Working with files {:#working-with-files}
+
+When you select a repository from the main screen, the screen changes to display
+a view of that repository. If a README file exists, its contents appear in the
+file pane, located on the right side of the screen. Otherwise, a list of
+repository's files and folders appear.  On the left side of the screen is a tree
+view of the repository's files and folders. You can use this tree to browse and
+open specific files.
+
+Notice that, when you are viewing a repository, the Breadcrumb toolbar now has
+three components:
+
+*  A **Repository** menu, from which you can select different repositories
+*  A **Branch/Commit/Tag** menu, from which you can select specific branches,
+   tags, or commits
+*  A **File path** box, which displays the name of the current file or folder
+   and its corresponding path
+
+### Open a file {:#open-a-file}
+
+You can open a file by browsing to its directory and selecting it. The view of
+the repository updates to show the contents of the file in the file pane, and
+its location in the repository in the tree pane.
+
+### View file changes {:#view-file-changes}
+
+To view file changes:
+
+1. From the view of the repository, select the file.
+1. Click **BLAME**, located in the upper-right corner.
+
+The file pane updates to display who made changes to the file and when.
+
+### View change history {:#view-change-history}
+
+To view the change history of a file:
+
+1.  From the view of the repository, select the file.
+1.  Click **HISTORY**, located in the upper-right corner.
+    The **Change history** pane appears, showing the commits for this file.
+
+### View code reviews {:#view-code-reviews}
+
+For Gerrit code reviews, you can open the tool directly from the Change History pane.
+
+To view the code review for a file:
+
+1. From the view of the repository, select the file.
+1. Click **HISTORY**, located in the upper-right corner. The Change History pane
+   appears, showing the commits for this file.
+1. Hover over a commit. A **More** button (three vertical dots) appears.
+1. Click the **More** button.
+1. Select **View code review**.
+
+The Gerrit Code Review tool opens in a new browser window.
+
+### Open a file at a specific commit {:#open-a-file-at-a-specific-commit}
+
+To open a file at a specific commit:
+
+1. From the view of the repository, select the file.
+1. Click **HISTORY**, located in the upper-right corner. The Change History pane
+   appears, showing the commits for this file.
+1. Hover over a commit. A **VIEW** button appears.
+1. Click the **VIEW** button.
+
+### Compare a file to a different commit {:#compare-a-file-to-a-different-commit}
+
+To compare a file at a different commit:
+
+1. From the view of the repository, select the file. To compare from two
+   different commits, first open the file at that commit.
+1. Hover over a commit. A **DIFF** button appears.
+1. Click the **DIFF** button.
+
+The file pane updates to display a side-by-side comparison between the two
+files. The oldest of the two commits is always on the left.
+
+In the Change History pane, both commits are highlighted, and a label indicates
+if the commit is displayed on the left or the right.
+
+To change either file, hover over the commit in the Change History pane. Then,
+click either the **Left** or **Right** button to have the open the commit on the
+left or right side of the diff.
+
+### Browsing cross references {:#browsing-cross-references}
+
+Another way to browse source repositories is through the use of cross
+references. These references appear automatically as hyperlinks within a given
+source file.
+
+To make cross references easier to identify, click **Cross References**,
+located in the upper-right corner. This option displays an underline below all
+cross references in a file.
+
+**Note:** If **Cross References** is grayed out, it indicates that
+cross references are not available for that file.
+
+Click a cross reference to open the Cross Reference pane. This pane contains
+two sections:
+
+* A **Definition** section, which lists the file or files that define the
+  reference
+* A **References** section, which lists the files in which the reference also
+  appears
+
+Both sections display the name of the file, as well as the line or lines
+that contains the reference. To open a file from the Cross Reference pane,
+click the line number entry. The file appears in a new section of the pane,
+allowing you to continue to browse the file while keeping the original file
+in view.
+
+You can continue to browse cross references using the Cross Reference pane, just
+as you can in the File pane. When you do, the pane displays a breadcrumb trail,
+which you can use to navigate between different cross references.
+
+## Searching for code {:#search}
+
+You can search for specific files or code snippets using the search box located
+at the top of the screen. Searches are always against the default branch.
+
+All searches use [RE2 regular expressions](https://github.com/google/re2/wiki/Syntax){: .external}
+by default. If you do not want to use regular expressions, enclose your search
+in double quotes ( " ).
+
+**Note:** To quickly search for a specific file, either add a backslash in front
+of the period, or enclose the entire file name in quotes.
+
+```
+foo\.java
+"foo.java"
+```
+
+You can refine your search using the following filters.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
FilterOther optionsDescriptionExample
lang:language:Perform an exact match by file language.lang:java test
file:filepath:

+path:

+f:
case:yesMake the search case sensitive. By default, searches are not case-sensitive.case:yes Hello World
class:Search for a class name.class:MainClass
function:func:Search for a function name.function:print
-Negates the term from the search.hello -world
\Escapes special characters, such as ., \, or (.run\(\)
"[term]"Perform a literal search."class:main"

+
+## Additional Support {:#additional-support}
+
+To report an issue, click the **Feedback** button that appears in the top
+right-hand corner of the screen and enter your feedback in the provided form.
diff --git a/versions/9.1.0/contribute/statemachine-guide.mdx b/versions/9.1.0/contribute/statemachine-guide.mdx
new file mode 100644
index 00000000..57f877cb
--- /dev/null
+++ b/versions/9.1.0/contribute/statemachine-guide.mdx
@@ -0,0 +1,1234 @@
+---
+title: 'A Guide to Skyframe `StateMachine`s'
+---
+
+## Overview
+
+A Skyframe `StateMachine` is a *deconstructed* function-object that resides on
+the heap. It supports flexible and evaluation without redundancy[^1] when
+required values are not immediately available but computed asynchronously. The
+`StateMachine` cannot tie up a thread resource while waiting, but instead has to
+be suspended and resumed. The deconstruction thus exposes explicit re-entry
+points so that prior computations can be skipped.
+
+`StateMachine`s can be used to express sequences, branching, structured logical
+concurrency and are tailored specifically for Skyframe interaction.
+`StateMachine`s can be composed into larger `StateMachine`s and share
+sub-`StateMachine`s. Concurrency is always hierarchical by construction and
+purely logical. Every concurrent subtask runs in the single shared parent
+SkyFunction thread.
+
+## Introduction
+
+This section briefly motivates and introduces `StateMachine`s, found in the
+[`java.com.google.devtools.build.skyframe.state`](https://github.com/bazelbuild/bazel/tree/master/src/main/java/com/google/devtools/build/skyframe/state)
+package.
+
+### A brief introduction to Skyframe restarts
+
+Skyframe is a framework that performs parallel evaluation of dependency graphs.
+Each node in the graph corresponds with the evaluation of a SkyFunction with a
+SkyKey specifying its parameters and SkyValue specifying its result. The
+computational model is such that a SkyFunction may lookup SkyValues by SkyKey,
+triggering recursive, parallel evaluation of additional SkyFunctions. Instead of
+blocking, which would tie up a thread, when a requested SkyValue is not yet
+ready because some subgraph of computation is incomplete, the requesting
+SkyFunction observes a `null` `getValue` response and should return `null`
+instead of a SkyValue, signaling that it is incomplete due to missing inputs.
+Skyframe *restarts* the SkyFunctions when all previously requested SkyValues
+become available.
+
+Before the introduction of `SkyKeyComputeState`, the traditional way of handling
+a restart was to fully rerun the computation. Although this has quadratic
+complexity, functions written this way eventually complete because each rerun,
+fewer lookups return `null`. With `SkyKeyComputeState` it is possible to
+associate hand-specified check-point data with a SkyFunction, saving significant
+recomputation.
+
+`StateMachine`s are objects that live inside `SkyKeyComputeState` and eliminate
+virtually all recomputation when a SkyFunction restarts (assuming that
+`SkyKeyComputeState` does not fall out of cache) by exposing suspend and resume
+execution hooks.
+
+### Stateful computations inside `SkyKeyComputeState` {#stateful-computations}
+
+From an object-oriented design standpoint, it makes sense to consider storing
+computational objects inside `SkyKeyComputeState` instead of pure data values.
+In *Java*, the bare minimum description of a behavior carrying object is a
+*functional interface* and it turns out to be sufficient. A `StateMachine` has
+the following, curiously recursive, definition[^2].
+
+```
+@FunctionalInterface
+public interface StateMachine {
+  StateMachine step(Tasks tasks) throws InterruptedException;
+}
+```
+
+The `Tasks` interface is analogous to `SkyFunction.Environment` but it is
+designed for asynchrony and adds support for logically concurrent subtasks[^3].
+
+The return value of `step` is another `StateMachine`, allowing the specification
+of a sequence of steps, inductively. `step` returns `DONE` when the
+`StateMachine` is done. For example:
+
+```
+class HelloWorld implements StateMachine {
+  @Override
+  public StateMachine step(Tasks tasks) {
+    System.out.println("hello");
+    return this::step2;  // The next step is HelloWorld.step2.
+  }
+
+  private StateMachine step2(Tasks tasks) {
+     System.out.println("world");
+     // DONE is special value defined in the `StateMachine` interface signaling
+     // that the computation is done.
+     return DONE;
+  }
+}
+```
+
+describes a `StateMachine` with the following output.
+
+```
+hello
+world
+```
+
+Note that the method reference `this::step2` is also a `StateMachine` due to
+`step2` satisfying `StateMachine`'s functional interface definition. Method
+references are the most common way to specify the next state in a
+`StateMachine`.
+
+![Suspending and resuming](/versions/9.1.0/contribute/images/suspend-resume.svg)
+
+Intuitively, breaking a computation down into `StateMachine` steps, instead of a
+monolithic function, provides the hooks needed to *suspend* and *resume* a
+computation. When `StateMachine.step` returns, there is an explicit *suspension*
+point. The continuation specified by the returned `StateMachine` value is an
+explicit *resume* point. Recomputation can thus be avoided because the
+computation can be picked up exactly where it left off.
+
+### Callbacks, continuations and asynchronous computation
+
+In technical terms, a `StateMachine` serves as a *continuation*, determining the
+subsequent computation to be executed. Instead of blocking, a `StateMachine` can
+voluntarily *suspend* by returning from the `step` function, which transfers
+control back to a [`Driver`](#drivers-and-bridging) instance. The `Driver` can
+then switch to a ready `StateMachine` or relinquish control back to Skyframe.
+
+Traditionally, *callbacks* and *continuations* are conflated into one concept.
+However, `StateMachine`s maintain a distinction between the two.
+
+*   *Callback* - describes where to store the result of an asynchronous
+    computation.
+*   *Continuation* - specifies the next execution state.
+
+Callbacks are required when invoking an asynchronous operation, which means that
+the actual operation doesn't occur immediately upon calling the method, as in
+the case of a SkyValue lookup. Callbacks should be kept as simple as possible.
+
+Caution: A common pitfall of callbacks is that the asynchronous computation must
+ensure the callback is called by the end of every reachable path. It's possible
+to overlook some branches and the compiler doesn't give warnings about this.
+
+*Continuations* are the `StateMachine` return values of `StateMachine`s and
+encapsulate the complex execution that follows once all asynchronous
+computations resolve. This structured approach helps to keep the complexity of
+callbacks manageable.
+
+## Tasks
+
+The `Tasks` interface provides `StateMachine`s with an API to lookup SkyValues
+by SkyKey and to schedule concurrent subtasks.
+
+```
+interface Tasks {
+  void enqueue(StateMachine subtask);
+
+  void lookUp(SkyKey key, Consumer sink);
+
+  
+  void lookUp(SkyKey key, Class exceptionClass, ValueOrExceptionSink sink);
+
+  // lookUp overloads for 2 and 3 exception types exist, but are elided here.
+}
+```
+
+Tip: When any state uses the `Tasks` interface to perform lookups or create
+subtasks, those lookups and subtasks will complete before the next state begins.
+
+Tip: (Corollary) If subtasks are complex `StateMachine`s or recursively create
+subtasks, they all *transitively* complete before the next state begins.
+
+### SkyValue lookups {#skyvalue-lookups}
+
+`StateMachine`s use `Tasks.lookUp` overloads to look up SkyValues. They are
+analogous to `SkyFunction.Environment.getValue` and
+`SkyFunction.Environment.getValueOrThrow` and have similar exception handling
+semantics. The implementation does not immediately perform the lookup, but
+instead, batches[^4] as many lookups as possible before doing so. The value
+might not be immediately available, for example, requiring a Skyframe restart,
+so the caller specifies what to do with the resulting value using a callback.
+
+The `StateMachine` processor ([`Driver`s and bridging to
+SkyFrame](#drivers-and-bridging)) guarantees that the value is available before
+the next state begins. An example follows.
+
+```
+class DoesLookup implements StateMachine, Consumer {
+  private Value value;
+
+  @Override
+  public StateMachine step(Tasks tasks) {
+    tasks.lookUp(new Key(), (Consumer) this);
+    return this::processValue;
+  }
+
+  // The `lookUp` call in `step` causes this to be called before `processValue`.
+  @Override  // Implementation of Consumer.
+  public void accept(SkyValue value) {
+    this.value = (Value)value;
+  }
+
+  private StateMachine processValue(Tasks tasks) {
+    System.out.println(value);  // Prints the string representation of `value`.
+    return DONE;
+  }
+}
+```
+
+In the above example, the first step does a lookup for `new Key()`, passing
+`this` as the consumer. That is possible because `DoesLookup` implements
+`Consumer`.
+
+Tip: When passing `this` as a value sink, it's helpful to readers to upcast it
+to the receiver type to narrow down the purpose of passing `this`. The example
+passes `(Consumer) this`.
+
+By contract, before the next state `DoesLookup.processValue` begins, all the
+lookups of `DoesLookup.step` are complete. Therefore `value` is available when
+it is accessed in `processValue`.
+
+### Subtasks
+
+`Tasks.enqueue` requests the execution of logically concurrent subtasks.
+Subtasks are also `StateMachine`s and can do anything regular `StateMachine`s
+can do, including recursively creating more subtasks or looking up SkyValues.
+Much like `lookUp`, the state machine driver ensures that all subtasks are
+complete before proceeding to the next step. An example follows.
+
+```
+class Subtasks implements StateMachine {
+  private int i = 0;
+
+  @Override
+  public StateMachine step(Tasks tasks) {
+    tasks.enqueue(new Subtask1());
+    tasks.enqueue(new Subtask2());
+    // The next step is Subtasks.processResults. It won't be called until both
+    // Subtask1 and Subtask 2 are complete.
+    return this::processResults;
+  }
+
+  private StateMachine processResults(Tasks tasks) {
+    System.out.println(i);  // Prints "3".
+    return DONE;  // Subtasks is done.
+  }
+
+  private class Subtask1 implements StateMachine {
+    @Override
+    public StateMachine step(Tasks tasks) {
+      i += 1;
+      return DONE;  // Subtask1 is done.
+    }
+  }
+
+  private class Subtask2 implements StateMachine {
+    @Override
+    public StateMachine step(Tasks tasks) {
+      i += 2;
+      return DONE;  // Subtask2 is done.
+    }
+  }
+}
+```
+
+Though `Subtask1` and `Subtask2` are logically concurrent, everything runs in a
+single thread so the "concurrent" update of `i` does not need any
+synchronization.
+
+### Structured concurrency {#structured-concurrency}
+
+Since every `lookUp` and `enqueue` must resolve before advancing to the next
+state, it means that concurrency is naturally limited to tree-structures. It's
+possible to create hierarchical[^5] concurrency as shown in the following
+example.
+
+![Structured Concurrency](/versions/9.1.0/contribute/images/structured-concurrency.svg)
+
+It's hard to tell from the *UML* that the concurrency structure forms a tree.
+There's an [alternate view](#concurrency-tree-diagram) that better shows the
+tree structure.
+
+![Unstructured Concurrency](/versions/9.1.0/contribute/images/unstructured-concurrency.svg)
+
+Structured concurrency is much easier to reason about.
+
+## Composition and control flow patterns
+
+This section presents examples for how multiple `StateMachine`s can be composed
+and solutions to certain control flow problems.
+
+### Sequential states
+
+This is the most common and straightforward control flow pattern. An example of
+this is shown in [Stateful computations inside
+`SkyKeyComputeState`](#stateful-computations).
+
+### Branching
+
+Branching states in `StateMachine`s can be achieved by returning different
+values using regular *Java* control flow, as shown in the following example.
+
+```
+class Branch implements StateMachine {
+  @Override
+  public StateMachine step(Tasks tasks) {
+    // Returns different state machines, depending on condition.
+    if (shouldUseA()) {
+      return this::performA;
+    }
+    return this::performB;
+  }
+  …
+}
+```
+
+It’s very common for certain branches to return `DONE`, for early completion.
+
+### Advanced sequential composition
+
+Since the `StateMachine` control structure is memoryless, sharing `StateMachine`
+definitions as subtasks can sometimes be awkward. Let *M1* and
+*M2* be `StateMachine` instances that share a `StateMachine`, *S*,
+with *M1* and *M2* being the sequences *<A, S, B>* and
+*<X, S, Y>* respectively. The problem is that *S* doesn’t know whether to
+continue to *B* or *Y* after it completes and `StateMachine`s don't quite keep a
+call stack. This section reviews some techniques for achieving this.
+
+#### `StateMachine` as terminal sequence element
+
+This doesn’t solve the initial problem posed. It only demonstrates sequential
+composition when the shared `StateMachine` is terminal in the sequence.
+
+```
+// S is the shared state machine.
+class S implements StateMachine { … }
+
+class M1 implements StateMachine {
+  @Override
+  public StateMachine step(Tasks tasks) {
+    performA();
+    return new S();
+  }
+}
+
+class M2 implements StateMachine {
+  @Override
+  public StateMachine step(Tasks tasks) {
+    performX();
+    return new S();
+  }
+}
+```
+
+This works even if *S* is itself a complex state machine.
+
+#### Subtask for sequential composition
+
+Since enqueued subtasks are guaranteed to complete before the next state, it’s
+sometimes possible to slightly abuse[^6] the subtask mechanism.
+
+```
+class M1 implements StateMachine {
+  @Override
+  public StateMachine step(Tasks tasks) {
+    performA();
+    // S starts after `step` returns and by contract must complete before `doB`
+    // begins. It is effectively sequential, inducing the sequence < A, S, B >.
+    tasks.enqueue(new S());
+    return this::doB;
+  }
+
+  private StateMachine doB(Tasks tasks) {
+    performB();
+    return DONE;
+  }
+}
+
+class M2 implements StateMachine {
+  @Override
+  public StateMachine step(Tasks tasks) {
+    performX();
+    // Similarly, this induces the sequence < X, S, Y>.
+    tasks.enqueue(new S());
+    return this::doY;
+  }
+
+  private StateMachine doY(Tasks tasks) {
+    performY();
+    return DONE;
+  }
+}
+```
+
+#### `runAfter` injection {#runafter-injection}
+
+Sometimes, abusing `Tasks.enqueue` is impossible because there are other
+parallel subtasks or `Tasks.lookUp` calls that must be completed before *S*
+executes. In this case, injecting a `runAfter` parameter into *S* can be used to
+inform *S* of what to do next.
+
+```
+class S implements StateMachine {
+  // Specifies what to run after S completes.
+  private final StateMachine runAfter;
+
+  @Override
+  public StateMachine step(Tasks tasks) {
+    … // Performs some computations.
+    return this::processResults;
+  }
+
+  @Nullable
+  private StateMachine processResults(Tasks tasks) {
+    … // Does some additional processing.
+
+    // Executes the state machine defined by `runAfter` after S completes.
+    return runAfter;
+  }
+}
+
+class M1 implements StateMachine {
+  @Override
+  public StateMachine step(Tasks tasks) {
+    performA();
+    // Passes `this::doB` as the `runAfter` parameter of S, resulting in the
+    // sequence < A, S, B >.
+    return new S(/* runAfter= */ this::doB);
+  }
+
+  private StateMachine doB(Tasks tasks) {
+    performB();
+    return DONE;
+  }
+}
+
+class M2 implements StateMachine {
+  @Override
+  public StateMachine step(Tasks tasks) {
+    performX();
+    // Passes `this::doY` as the `runAfter` parameter of S, resulting in the
+    // sequence < X, S, Y >.
+    return new S(/* runAfter= */ this::doY);
+  }
+
+  private StateMachine doY(Tasks tasks) {
+    performY();
+    return DONE;
+  }
+}
+```
+
+This approach is cleaner than abusing subtasks. However, applying this too
+liberally, for example, by nesting multiple `StateMachine`s with `runAfter`, is
+the road to [Callback Hell](#callback-hell). It’s better to break up sequential
+`runAfter`s with ordinary sequential states instead.
+
+```
+  return new S(/* runAfter= */ new T(/* runAfter= */ this::nextStep))
+```
+
+can be replaced with the following.
+
+```
+  private StateMachine step1(Tasks tasks) {
+     doStep1();
+     return new S(/* runAfter= */ this::intermediateStep);
+  }
+
+  private StateMachine intermediateStep(Tasks tasks) {
+    return new T(/* runAfter= */ this::nextStep);
+  }
+```
+
+Note: It's possible to pass `DONE` as the `runAfter` parameter when there's
+nothing to run afterwards.
+
+Tip: When using `runAfter`, always annotate the parameter with `/* runAfter= */`
+to let the reader know the meaning at the callsite.
+
+#### *Forbidden* alternative: `runAfterUnlessError`
+
+In an earlier draft, we had considered a `runAfterUnlessError` that would abort
+early on errors. This was motivated by the fact that errors often end up getting
+checked twice, once by the `StateMachine` that has a `runAfter` reference and
+once by the `runAfter` machine itself.
+
+After some deliberation, we decided that uniformity of the code is more
+important than deduplicating the error checking. It would be confusing if the
+`runAfter` mechanism did not work in a consistent manner with the
+`tasks.enqueue` mechanism, which always requires error checking.
+
+Warning: When using `runAfter`, the machine that has the injected `runAfter`
+should invoke it unconditionally at completion, even on error, for consistency.
+
+### Direct delegation
+
+Each time there is a formal state transition, the main `Driver` loop advances.
+As per contract, advancing states means that all previously enqueued SkyValue
+lookups and subtasks resolve before the next state executes. Sometimes the logic
+of a delegate `StateMachine` makes a phase advance unnecessary or
+counterproductive. For example, if the first `step` of the delegate performs
+SkyKey lookups that could be parallelized with lookups of the delegating state
+then a phase advance would make them sequential. It could make more sense to
+perform direct delegation, as shown in the example below.
+
+```
+class Parent implements StateMachine {
+  @Override
+  public StateMachine step(Tasks tasks ) {
+    tasks.lookUp(new Key1(), this);
+    // Directly delegates to `Delegate`.
+    //
+    // The (valid) alternative:
+    //   return new Delegate(this::afterDelegation);
+    // would cause `Delegate.step` to execute after `step` completes which would
+    // cause lookups of `Key1` and `Key2` to be sequential instead of parallel.
+    return new Delegate(this::afterDelegation).step(tasks);
+  }
+
+  private StateMachine afterDelegation(Tasks tasks) {
+    …
+  }
+}
+
+class Delegate implements StateMachine {
+  private final StateMachine runAfter;
+
+  Delegate(StateMachine runAfter) {
+    this.runAfter = runAfter;
+  }
+
+  @Override
+  public StateMachine step(Tasks tasks) {
+    tasks.lookUp(new Key2(), this);
+    return …;
+  }
+
+  // Rest of implementation.
+  …
+
+  private StateMachine complete(Tasks tasks) {
+    …
+    return runAfter;
+  }
+}
+```
+
+## Data flow
+
+The focus of the previous discussion has been on managing control flow. This
+section describes the propagation of data values.
+
+### Implementing `Tasks.lookUp` callbacks
+
+There’s an example of implementing a `Tasks.lookUp` callback in [SkyValue
+lookups](#skyvalue-lookups). This section provides rationale and suggests
+approaches for handling multiple SkyValues.
+
+#### `Tasks.lookUp` callbacks {#tasks-lookup-callbacks}
+
+The `Tasks.lookUp` method takes a callback, `sink`, as a parameter.
+
+```
+  void lookUp(SkyKey key, Consumer sink);
+```
+
+The idiomatic approach would be to use a *Java* lambda to implement this:
+
+```
+  tasks.lookUp(key, value -> myValue = (MyValueClass)value);
+```
+
+with `myValue` being a member variable of the `StateMachine` instance doing the
+lookup. However, the lambda requires an extra memory allocation compared to
+implementing the `Consumer` interface in the `StateMachine`
+implementation. The lambda is still useful when there are multiple lookups that
+would be ambiguous.
+
+Note: Bikeshed warning. There is a noticeable difference of approximately 1%
+end-to-end CPU usage when implementing callbacks systematically in
+`StateMachine` implementations compared to using lambdas, which makes this
+recommendation debatable. To avoid unnecessary debates, it is advised to leave
+the decision up to the individual implementing the solution.
+
+There are also error handling overloads of `Tasks.lookUp`, that are analogous to
+`SkyFunction.Environment.getValueOrThrow`.
+
+```
+   void lookUp(
+      SkyKey key, Class exceptionClass, ValueOrExceptionSink sink);
+
+  interface ValueOrExceptionSink {
+    void acceptValueOrException(@Nullable SkyValue value, @Nullable E exception);
+  }
+```
+
+An example implementation is shown below.
+
+```
+class PerformLookupWithError extends StateMachine, ValueOrExceptionSink {
+  private MyValue value;
+  private MyException error;
+
+  @Override
+  public StateMachine step(Tasks tasks) {
+    tasks.lookUp(new MyKey(), MyException.class, ValueOrExceptionSink) this);
+    return this::processResult;
+  }
+
+  @Override
+  public acceptValueOrException(@Nullable SkyValue value, @Nullable MyException exception) {
+    if (value != null) {
+      this.value = (MyValue)value;
+      return;
+    }
+    if (exception != null) {
+      this.error = exception;
+      return;
+    }
+    throw new IllegalArgumentException("Both parameters were unexpectedly null.");
+  }
+
+  private StateMachine processResult(Tasks tasks) {
+    if (exception != null) {
+      // Handles the error.
+      …
+      return DONE;
+    }
+    // Processes `value`, which is non-null.
+    …
+  }
+}
+```
+
+As with lookups without error handling, having the `StateMachine` class directly
+implement the callback saves a memory allocation for the lamba.
+
+[Error handling](#error-handling) provides a bit more detail, but essentially,
+there's not much difference between the propagation of errors and normal values.
+
+#### Consuming multiple SkyValues
+
+Multiple SkyValue lookups are often required. An approach that works much of the
+time is to switch on the type of SkyValue. The following is an example that has
+been simplified from prototype production code.
+
+```
+  @Nullable
+  private StateMachine fetchConfigurationAndPackage(Tasks tasks) {
+    var configurationKey = configuredTarget.getConfigurationKey();
+    if (configurationKey != null) {
+      tasks.lookUp(configurationKey, (Consumer) this);
+    }
+
+    var packageId = configuredTarget.getLabel().getPackageIdentifier();
+    tasks.lookUp(PackageValue.key(packageId), (Consumer) this);
+
+    return this::constructResult;
+  }
+
+  @Override  // Implementation of `Consumer`.
+  public void accept(SkyValue value) {
+    if (value instanceof BuildConfigurationValue) {
+      this.configurationValue = (BuildConfigurationValue) value;
+      return;
+    }
+    if (value instanceof PackageValue) {
+      this.pkg = ((PackageValue) value).getPackage();
+      return;
+    }
+    throw new IllegalArgumentException("unexpected value: " + value);
+  }
+```
+
+The `Consumer` callback implementation can be shared unambiguously
+because the value types are different. When that’s not the case, falling back to
+lambda-based implementations or full inner-class instances that implement the
+appropriate callbacks is viable.
+
+### Propagating values between `StateMachine`s {#propagating-values}
+
+So far, this document has only explained how to arrange work in a subtask, but
+subtasks also need to report a values back to the caller. Since subtasks are
+logically asynchronous, their results are communicated back to the caller using
+a *callback*. To make this work, the subtask defines a sink interface that is
+injected via its constructor.
+
+```
+class BarProducer implements StateMachine {
+  // Callers of BarProducer implement the following interface to accept its
+  // results. Exactly one of the two methods will be called by the time
+  // BarProducer completes.
+  interface ResultSink {
+    void acceptBarValue(Bar value);
+    void acceptBarError(BarException exception);
+  }
+
+  private final ResultSink sink;
+
+  BarProducer(ResultSink sink) {
+     this.sink = sink;
+  }
+
+  … // StateMachine steps that end with this::complete.
+
+  private StateMachine complete(Tasks tasks) {
+    if (hasError()) {
+      sink.acceptBarError(getError());
+      return DONE;
+    }
+    sink.acceptBarValue(getValue());
+    return DONE;
+  }
+}
+```
+
+Tip: It would be tempting to use the more concise signature void `accept(Bar
+value)` rather than the stuttery `void acceptBarValue(Bar value)` above.
+However, `Consumer` is a common overload of `void accept(Bar value)`,
+so doing this often leads to violations of the [Overloads: never
+split](https://google.github.io/styleguide/javaguide.html#s3.4.2-ordering-class-contents)
+style-guide rule.
+
+Tip: Using a custom `ResultSink` type instead of a generic one from
+`java.util.function` makes it easy to find implementations in the code base,
+improving readability.
+
+A caller `StateMachine` would then look like the following.
+
+```
+class Caller implements StateMachine, BarProducer.ResultSink {
+  interface ResultSink {
+    void acceptCallerValue(Bar value);
+    void acceptCallerError(BarException error);
+  }
+
+  private final ResultSink sink;
+
+  private Bar value;
+
+  Caller(ResultSink sink) {
+    this.sink = sink;
+  }
+
+  @Override
+  @Nullable
+  public StateMachine step(Tasks tasks) {
+    tasks.enqueue(new BarProducer((BarProducer.ResultSink) this));
+    return this::processResult;
+  }
+
+  @Override
+  public void acceptBarValue(Bar value) {
+    this.value = value;
+  }
+
+  @Override
+  public void acceptBarError(BarException error) {
+    sink.acceptCallerError(error);
+  }
+
+  private StateMachine processResult(Tasks tasks) {
+    // Since all enqueued subtasks resolve before `processResult` starts, one of
+    // the `BarResultSink` callbacks must have been called by this point.
+    if (value == null) {
+      return DONE;  // There was a previously reported error.
+    }
+    var finalResult = computeResult(value);
+    sink.acceptCallerValue(finalResult);
+    return DONE;
+  }
+}
+```
+
+The preceding example demonstrates a few things. `Caller` has to propagate its
+results back and defines its own `Caller.ResultSink`. `Caller` implements the
+`BarProducer.ResultSink` callbacks. Upon resumption, `processResult` checks if
+`value` is null to determine if an error occurred. This is a common behavior
+pattern after accepting output from either a subtask or SkyValue lookup.
+
+Note that the implementation of `acceptBarError` eagerly forwards the result to
+the `Caller.ResultSink`, as required by [Error bubbling](#error-bubbling).
+
+Alternatives for top-level `StateMachine`s are described in [`Driver`s and
+bridging to SkyFunctions](#drivers-and-bridging).
+
+### Error handling {#error-handling}
+
+There's a couple of examples of error handling already in [`Tasks.lookUp`
+callbacks](#tasks-lookup-callbacks) and [Propagating values between
+`StateMachines`](#propagating-values). Exceptions, other than
+`InterruptedException` are not thrown, but instead passed around through
+callbacks as values. Such callbacks often have exclusive-or semantics, with
+exactly one of a value or error being passed.
+
+The next section describes a a subtle, but important interaction with Skyframe
+error handling.
+
+#### Error bubbling (--nokeep\_going) {#error-bubbling}
+
+Warning: Errors need to be eagerly propagated all the way back to the
+SkyFunction for error bubbling to function correctly.
+
+During error bubbling, a SkyFunction may be restarted even if not all requested
+SkyValues are available. In such cases, the subsequent state will never be
+reached due to the `Tasks` API contract. However, the `StateMachine` should
+still propagate the exception.
+
+Since propagation must occur regardless of whether the next state is reached,
+the error handling callback must perform this task. For an inner `StateMachine`,
+this is achieved by invoking the parent callback.
+
+At the top-level `StateMachine`, which interfaces with the SkyFunction, this can
+be done by calling the `setException` method of `ValueOrExceptionProducer`.
+`ValueOrExceptionProducer.tryProduceValue` will then throw the exception, even
+if there are missing SkyValues.
+
+If a `Driver` is being utilized directly, it is essential to check for
+propagated errors from the SkyFunction, even if the machine has not finished
+processing.
+
+### Event Handling {#event-handling}
+
+For SkyFunctions that need to emit events, a `StoredEventHandler` is injected
+into SkyKeyComputeState and further injected into `StateMachine`s that require
+them. Historically, the `StoredEventHandler` was needed due to Skyframe dropping
+certain events unless they are replayed but this was subsequently fixed.
+`StoredEventHandler` injection is preserved because it simplifies the
+implementation of events emitted from error handling callbacks.
+
+## `Driver`s and bridging to SkyFunctions {#drivers-and-bridging}
+
+A `Driver` is responsible for managing the execution of `StateMachine`s,
+beginning with a specified root `StateMachine`. As `StateMachine`s can
+recursively enqueue subtask `StateMachine`s, a single `Driver` can manage
+numerous subtasks. These subtasks create a tree structure, a result of
+[Structured concurrency](#structured-concurrency). The `Driver` batches SkyValue
+lookups across subtasks for improved efficiency.
+
+There are a number of classes built around the `Driver`, with the following API.
+
+```
+public final class Driver {
+  public Driver(StateMachine root);
+  public boolean drive(SkyFunction.Environment env) throws InterruptedException;
+}
+```
+
+`Driver` takes a single root `StateMachine` as a parameter. Calling
+`Driver.drive` executes the `StateMachine` as far as it can go without a
+Skyframe restart. It returns true when the `StateMachine` completes and false
+otherwise, indicating that not all values were available.
+
+`Driver` maintains the concurrent state of the `StateMachine` and it is well
+suited for embedding in `SkyKeyComputeState`.
+
+### Directly instantiating `Driver`
+
+`StateMachine` implementations conventionally communicate their results via
+callbacks. It's possible to directly instantiate a `Driver` as shown in the
+following example.
+
+The `Driver` is embedded in the `SkyKeyComputeState` implementation along with
+an implementation of the corresponding `ResultSink` to be defined a bit further
+down. At the top level, the `State` object is an appropriate receiver for the
+result of the computation as it is guaranteed to outlive `Driver`.
+
+```
+class State implements SkyKeyComputeState, ResultProducer.ResultSink {
+  // The `Driver` instance, containing the full tree of all `StateMachine`
+  // states. Responsible for calling `StateMachine.step` implementations when
+  // asynchronous values are available and performing batched SkyFrame lookups.
+  //
+  // Non-null while `result` is being computed.
+  private Driver resultProducer;
+
+  // Variable for storing the result of the `StateMachine`
+  //
+  // Will be non-null after the computation completes.
+  //
+  private ResultType result;
+
+  // Implements `ResultProducer.ResultSink`.
+  //
+  // `ResultProducer` propagates its final value through a callback that is
+  // implemented here.
+  @Override
+  public void acceptResult(ResultType result) {
+    this.result = result;
+  }
+}
+```
+
+The code below sketches the `ResultProducer`.
+
+```
+class ResultProducer implements StateMachine {
+  interface ResultSink {
+    void acceptResult(ResultType value);
+  }
+
+  private final Parameters parameters;
+  private final ResultSink sink;
+
+  … // Other internal state.
+
+  ResultProducer(Parameters parameters, ResultSink sink) {
+    this.parameters = parameters;
+    this.sink = sink;
+  }
+
+  @Override
+  public StateMachine step(Tasks tasks) {
+    …  // Implementation.
+    return this::complete;
+  }
+
+  private StateMachine complete(Tasks tasks) {
+    sink.acceptResult(getResult());
+    return DONE;
+  }
+}
+```
+
+Then the code for lazily computing the result could look like the following.
+
+```
+@Nullable
+private Result computeResult(State state, Skyfunction.Environment env)
+    throws InterruptedException {
+  if (state.result != null) {
+    return state.result;
+  }
+  if (state.resultProducer == null) {
+    state.resultProducer = new Driver(new ResultProducer(
+      new Parameters(), (ResultProducer.ResultSink)state));
+  }
+  if (state.resultProducer.drive(env)) {
+    // Clears the `Driver` instance as it is no longer needed.
+    state.resultProducer = null;
+  }
+  return state.result;
+}
+```
+
+### Embedding `Driver` {#embedding-driver}
+
+If the `StateMachine` produces a value and raises no exceptions, embedding
+`Driver` is another possible implementation, as shown in the following example.
+
+```
+class ResultProducer implements StateMachine {
+  private final Parameters parameters;
+  private final Driver driver;
+
+  private ResultType result;
+
+  ResultProducer(Parameters parameters) {
+    this.parameters = parameters;
+    this.driver = new Driver(this);
+  }
+
+  @Nullable  // Null when a Skyframe restart is needed.
+  public ResultType tryProduceValue( SkyFunction.Environment env)
+      throws InterruptedException {
+    if (!driver.drive(env)) {
+      return null;
+    }
+    return result;
+  }
+
+  @Override
+  public StateMachine step(Tasks tasks) {
+    …  // Implementation.
+}
+```
+
+The SkyFunction may have code that looks like the following (where `State` is
+the function specific type of `SkyKeyComputeState`).
+
+```
+@Nullable  // Null when a Skyframe restart is needed.
+Result computeResult(SkyFunction.Environment env, State state)
+    throws InterruptedException {
+  if (state.result != null) {
+    return state.result;
+  }
+  if (state.resultProducer == null) {
+    state.resultProducer = new ResultProducer(new Parameters());
+  }
+  var result = state.resultProducer.tryProduceValue(env);
+  if (result == null) {
+    return null;
+  }
+  state.resultProducer = null;
+  return state.result = result;
+}
+```
+
+Embedding `Driver` in the `StateMachine` implementation is a better fit for
+Skyframe's synchronous coding style.
+
+### StateMachines that may produce exceptions
+
+Otherwise, there are `SkyKeyComputeState`-embeddable `ValueOrExceptionProducer`
+and `ValueOrException2Producer` classes that have synchronous APIs to match
+synchronous SkyFunction code.
+
+The `ValueOrExceptionProducer` abstract class includes the following methods.
+
+```
+public abstract class ValueOrExceptionProducer
+    implements StateMachine {
+  @Nullable
+  public final V tryProduceValue(Environment env)
+      throws InterruptedException, E {
+    …  // Implementation.
+  }
+
+  protected final void setValue(V value)  {  … // Implementation. }
+  protected final void setException(E exception) {  … // Implementation. }
+}
+```
+
+It includes an embedded `Driver` instance and closely resembles the
+`ResultProducer` class in [Embedding driver](#embedding-driver) and interfaces
+with the SkyFunction in a similar manner. Instead of defining a `ResultSink`,
+implementations call `setValue` or `setException` when either of those occur.
+When both occur, the exception takes priority. The `tryProduceValue` method
+bridges the asynchronous callback code to synchronous code and throws an
+exception when one is set.
+
+As previously noted, during error bubbling, it's possible for an error to occur
+even if the machine is not yet done because not all inputs are available. To
+accommodate this, `tryProduceValue` throws any set exceptions, even before the
+machine is done.
+
+## Epilogue: Eventually removing callbacks
+
+`StateMachine`s are a highly efficient, but boilerplate intensive way to perform
+asynchronous computation. Continuations (particularly in the form of `Runnable`s
+passed to `ListenableFuture`) are widespread in certain parts of *Bazel* code,
+but aren't prevalent in analysis SkyFunctions. Analysis is mostly CPU bound and
+there are no efficient asynchronous APIs for disk I/O. Eventually, it would be
+good to optimize away callbacks as they have a learning curve and impede
+readability.
+
+One of the most promising alternatives is *Java* virtual threads. Instead of
+having to write callbacks, everything is replaced with synchronous, blocking
+calls. This is possible because tying up a virtual thread resource, unlike a
+platform thread, is supposed to be cheap. However, even with virtual threads,
+replacing simple synchronous operations with thread creation and synchronization
+primitives is too expensive. We performed a migration from `StateMachine`s to
+*Java* virtual threads and they were orders of magnitude slower, leading to
+almost a 3x increase in end-to-end analysis latency. Since virtual threads are
+still a preview feature, it's possible that this migration can be performed at a
+later date when performance improves.
+
+Another approach to consider is waiting for *Loom* coroutines, if they ever
+become available. The advantage here is that it might be possible to reduce
+synchronization overhead by using cooperative multitasking.
+
+If all else fails, low-level bytecode rewriting could also be a viable
+alternative. With enough optimization, it might be possible to achieve
+performance that approaches hand-written callback code.
+
+## Appendix
+
+### Callback Hell {#callback-hell}
+
+Callback hell is an infamous problem in asynchronous code that uses callbacks.
+It stems from the fact that the continuation for a subsequent step is nested
+within the previous step. If there are many steps, this nesting can be extremely
+deep. If coupled with control flow the code becomes unmanageable.
+
+```
+class CallbackHell implements StateMachine {
+  @Override
+  public StateMachine step(Tasks task) {
+    doA();
+    return (t, l) -> {
+      doB();
+      return (t1, l2) -> {
+        doC();
+        return DONE;
+      };
+    };
+  }
+}
+```
+
+One of the advantages of nested implementations is that the stack frame of the
+outer step can be preserved. In *Java*, captured lambda variables must be
+effectively final so using such variables can be cumbersome. Deep nesting is
+avoided by returning method references as continuations instead of lambdas as
+shown as follows.
+
+```
+class CallbackHellAvoided implements StateMachine {
+  @Override
+  public StateMachine step(Tasks task) {
+    doA();
+    return this::step2;
+  }
+
+  private StateMachine step2(Tasks tasks) {
+    doB();
+    return this::step3;
+  }
+
+  private StateMachine step3(Tasks tasks) {
+    doC();
+    return DONE;
+  }
+}
+```
+
+Callback hell may also occur if the [`runAfter` injection](#runafter-injection)
+pattern is used too densely, but this can be avoided by interspersing injections
+with sequential steps.
+
+#### Example: Chained SkyValue lookups {#chained-skyvalue-lookups}
+
+It is often the case that the application logic requires dependent chains of
+SkyValue lookups, for example, if a second SkyKey depends on the first SkyValue.
+Thinking about this naively, this would result in a complex, deeply nested
+callback structure.
+
+```
+private ValueType1 value1;
+private ValueType2 value2;
+
+private StateMachine step1(...) {
+  tasks.lookUp(key1, (Consumer) this);  // key1 has type KeyType1.
+  return this::step2;
+}
+
+@Override
+public void accept(SkyValue value) {
+  this.value1 = (ValueType1) value;
+}
+
+private StateMachine step2(...) {
+  KeyType2 key2 = computeKey(value1);
+  tasks.lookup(key2, this::acceptValueType2);
+  return this::step3;
+}
+
+private void acceptValueType2(SkyValue value) {
+  this.value2 = (ValueType2) value;
+}
+```
+
+However, since continuations are specified as method references, the code looks
+procedural across state transitions: `step2` follows `step1`. Note that here, a
+lambda is used to assign `value2`. This makes the ordering of the code match the
+ordering of the computation from top-to-bottom.
+
+### Miscellaneous Tips
+
+#### Readability: Execution Ordering
+
+To improve readability, strive to keep the `StateMachine.step` implementations
+in execution order and callback implementations immediately following where they
+are passed in the code. This isn't always possible where the control flow
+branches. Additional comments might be helpful in such cases.
+
+In [Example: Chained SkyValue lookups](#chained-skyvalue-lookups), an
+intermediate method reference is created to achieve this. This trades a small
+amount of performance for readability, which is likely worthwhile here.
+
+#### Generational Hypothesis
+
+Medium-lived *Java* objects break the generational hypothesis of the *Java*
+garbage collector, which is designed to handle objects that live for a very
+short time or objects that live forever. By definition, objects in
+`SkyKeyComputeState` violate this hypothesis. Such objects, containing the
+constructed tree of all still-running `StateMachine`s, rooted at `Driver` have
+an intermediate lifespan as they suspend, waiting for asynchronous computations
+to complete.
+
+It seems less bad in JDK19, but when using `StateMachine`s, it's sometimes
+possible to observe an increase in GC time, even with dramatic decreases in
+actual garbage generated. Since `StateMachine`s have an intermediate lifespan
+they could be promoted to old gen, causing it to fill up more quickly, thus
+necessitating more expensive major or full GCs to clean up.
+
+The initial precaution is to minimize the use of `StateMachine` variables, but
+it is not always feasible, for example, if a value is needed across multiple
+states. Where it is possible, local stack `step` variables are young generation
+variables and efficiently GC'd.
+
+For `StateMachine` variables, breaking things down into subtasks and following
+the recommended pattern for [Propagating values between
+`StateMachine`s](#propagating-values) is also helpful. Observe that when
+following the pattern, only child `StateMachine`s have references to parent
+`StateMachine`s and not vice versa. This means that as children complete and
+update the parents using result callbacks, the children naturally fall out of
+scope and become eligible for GC.
+
+Finally, in some cases, a `StateMachine` variable is needed in earlier states
+but not in later states. It can be beneficial to null out references of large
+objects once it is known that they are no longer needed.
+
+#### Naming states
+
+When naming a method, it's usually possible to name a method for the behavior
+that happens within that method. It's less clear how to do this in
+`StateMachine`s because there is no stack. For example, suppose method `foo`
+calls a sub-method `bar`. In a `StateMachine`, this could be translated into the
+state sequence `foo`, followed by `bar`. `foo` no longer includes the behavior
+`bar`. As a result, method names for states tend to be narrower in scope,
+potentially reflecting local behavior.
+
+### Concurrency tree diagram {#concurrency-tree-diagram}
+
+The following is an alternative view of the diagram in [Structured
+concurrency](#structured-concurrency) that better depicts the tree structure.
+The blocks form a small tree.
+
+![Structured Concurrency 3D](/versions/9.1.0/contribute/images/structured-concurrency-3d.svg)
+
+[^1]: In contrast to Skyframe's convention of restarting from the beginning when
+ values are not available.
+[^2]: Note that `step` is permitted to throw `InterruptedException`, but the
+ examples omit this. There are a few low methods in *Bazel* code that throw
+ this exception and it propagates up to the `Driver`, to be described later,
+ that runs the `StateMachine`. It's fine to not declare it to be thrown when
+ unneeded.
+[^3]: Concurrent subtasks were motivated by the `ConfiguredTargetFunction` which
+ performs *independent* work for each dependency. Instead of manipulating
+ complex data structures that process all the dependencies at once,
+ introducing inefficiencies, each dependency has its own independent
+ `StateMachine`.
+[^4]: Multiple `tasks.lookUp` calls within a single step are batched together.
+ Additional batching can be created by lookups occurring within concurrent
+ subtasks.
+[^5]: This is conceptually similar to Java’s structured concurrency
+ [jeps/428](https://openjdk.org/jeps/428).
+[^6]: Doing this is similar to spawning a thread and joining it to achieve
+ sequential composition.
\ No newline at end of file
diff --git a/versions/9.1.0/contribute/windows-chocolatey-maintenance.mdx b/versions/9.1.0/contribute/windows-chocolatey-maintenance.mdx
new file mode 100644
index 00000000..2e7f90bf
--- /dev/null
+++ b/versions/9.1.0/contribute/windows-chocolatey-maintenance.mdx
@@ -0,0 +1,70 @@
+---
+title: 'Maintaining Bazel Chocolatey package on Windows'
+---
+
+Note: The Chocolatey package is experimental; please provide feedback
+(`@petemounce` in issue tracker).
+
+## Prerequisites {#prerequisites}
+
+You need:
+
+*    [chocolatey package manager](https://chocolatey.org) installed
+*    (to publish) a chocolatey API key granting you permission to publish the
+     `bazel` package
+     * [@petemounce](https://github.com/petemounce) currently
+     maintains this unofficial package.
+*    (to publish) to have set up that API key for the chocolatey source locally
+     via `choco apikey -k  -s https://chocolatey.org/`
+
+## Build {#build}
+
+Compile bazel with msys2 shell and `compile.sh`.
+
+```powershell
+pushd scripts/packages/chocolatey
+  ./build.ps1 -version 0.3.2 -mode local
+popd
+```
+
+Should result in `scripts/packages/chocolatey/bazel..nupkg` being
+created.
+
+The `build.ps1` script supports `mode` values `local`, `rc` and `release`.
+
+## Test {#test}
+
+0. Build the package (with `-mode local`)
+
+    * run a webserver (`python -m SimpleHTTPServer` in
+      `scripts/packages/chocolatey` is convenient and starts one on
+      `http://localhost:8000`)
+
+0. Test the install
+
+    The `test.ps1` should install the package cleanly (and error if it did not
+    install cleanly), then tell you what to do next.
+
+0. Test the uninstall
+
+    ```sh
+    choco uninstall bazel
+    # should remove bazel from the system
+    ```
+
+Chocolatey's moderation process automates checks here as well.
+
+## Release {#release}
+
+Modify `tools/parameters.json` for the new release's URI and checksum once the
+release has been published to github releases.
+
+```powershell
+./build.ps1 -version  -isRelease
+./test.ps1 -version 
+# if the test.ps1 passes
+choco push bazel.x.y.z.nupkg --source https://chocolatey.org/
+```
+
+Chocolatey.org will then run automated checks and respond to the push via email
+to the maintainers.
diff --git a/versions/9.1.0/contribute/windows-scoop-maintenance.mdx b/versions/9.1.0/contribute/windows-scoop-maintenance.mdx
new file mode 100644
index 00000000..3fc8ce3a
--- /dev/null
+++ b/versions/9.1.0/contribute/windows-scoop-maintenance.mdx
@@ -0,0 +1,53 @@
+---
+title: 'Maintaining Bazel Scoop package on Windows'
+---
+
+Note: The Scoop package is experimental. To provide feedback, go to
+`@excitoon` in issue tracker.
+
+## Prerequisites {#prerequisites}
+
+You need:
+
+*    [Scoop package manager](https://scoop.sh/) installed
+*    GitHub account in order to publish and create pull requests to
+     [scoopinstaller/scoop-main](https://github.com/scoopinstaller/scoop-main)
+     * [@excitoon](https://github.com/excitoon) currently maintains this
+       unofficial package. Feel free to ask questions by
+       [e-mail](mailto:vladimir.chebotarev@gmail.com) or
+       [Telegram](http://telegram.me/excitoon).
+
+## Release process {#release-process}
+
+Scoop packages are very easy to maintain. Once you have the URL of released
+Bazel, you need to make appropriate changes in
+[this file](https://github.com/scoopinstaller/scoop-main/blob/master/bucket/bazel.json):
+
+- update version
+- update dependencies if needed
+- update URL
+- update hash (`sha256` by default)
+
+In your filesystem, `bazel.json` is located in the directory
+`%UserProfile%/scoop/buckets/main/bucket` by default. This directory belongs to
+your clone of a Git repository
+[scoopinstaller/scoop-main](https://github.com/scoopinstaller/scoop-main).
+
+Test the result:
+
+```
+scoop uninstall bazel
+scoop install bazel
+bazel version
+bazel something_else
+```
+
+The first time, make a fork of
+[scoopinstaller/scoop-main](https://github.com/scoopinstaller/scoop-main) and
+specify it as your own remote for `%UserProfile%/scoop/buckets/main`:
+
+```
+git remote add mine FORK_URL
+```
+
+Push your changes to your fork and create a pull request.
diff --git a/versions/9.1.0/docs/android-build-performance.mdx b/versions/9.1.0/docs/android-build-performance.mdx
new file mode 100644
index 00000000..b5357320
--- /dev/null
+++ b/versions/9.1.0/docs/android-build-performance.mdx
@@ -0,0 +1,95 @@
+---
+title: 'Android Build Performance'
+---
+
+This page contains information on optimizing build performance for Android
+apps specifically. For general build performance optimization with Bazel, see
+[Optimizing Performance](/versions/9.1.0/rules/performance).
+
+## Recommended flags {#recommended-flags}
+
+The flags are in the
+[`bazelrc` configuration syntax](/versions/9.1.0/run/bazelrc#bazelrc-syntax-semantics), so
+they can be pasted directly into a `bazelrc` file and invoked with
+`--config=` on the command line.
+
+**Profiling performance**
+
+Bazel writes a JSON trace profile by default to a file called
+`command.profile.gz` in Bazel's output base.
+See the [JSON Profile documentation](/versions/9.1.0/rules/performance#performance-profiling) for
+how to read and interact with the profile.
+
+**Persistent workers for Android build actions**.
+
+A subset of Android build actions has support for
+[persistent workers](https://blog.bazel.build/2015/12/10/java-workers.html).
+
+These actions' mnemonics are:
+
+*   DexBuilder
+*   Javac
+*   Desugar
+*   AaptPackage
+*   AndroidResourceParser
+*   AndroidResourceValidator
+*   AndroidResourceCompiler
+*   RClassGenerator
+*   AndroidResourceLink
+*   AndroidAapt2
+*   AndroidAssetMerger
+*   AndroidResourceMerger
+*   AndroidCompiledResourceMerger
+
+Enabling workers can result in better build performance by saving on JVM
+startup costs from invoking each of these tools, but at the cost of increased
+memory usage on the system by persisting them.
+
+To enable workers for these actions, apply these flags with
+`--config=android_workers` on the command line:
+
+```
+build:android_workers --strategy=DexBuilder=worker
+build:android_workers --strategy=Javac=worker
+build:android_workers --strategy=Desugar=worker
+
+# A wrapper flag for these resource processing actions:
+# - AndroidResourceParser
+# - AndroidResourceValidator
+# - AndroidResourceCompiler
+# - RClassGenerator
+# - AndroidResourceLink
+# - AndroidAapt2
+# - AndroidAssetMerger
+# - AndroidResourceMerger
+# - AndroidCompiledResourceMerger
+build:android_workers --persistent_android_resource_processor
+```
+
+The default number of persistent workers created per action is `4`. We have
+[measured improved build performance](https://github.com/bazelbuild/bazel/issues/8586#issuecomment-500070549)
+by capping the number of instances for each action to `1` or `2`, although this
+may vary depending on the system Bazel is running on, and the project being
+built.
+
+To cap the number of instances for an action, apply these flags:
+
+```
+build:android_workers --worker_max_instances=DexBuilder=2
+build:android_workers --worker_max_instances=Javac=2
+build:android_workers --worker_max_instances=Desugar=2
+build:android_workers --worker_max_instances=AaptPackage=2
+# .. and so on for each action you're interested in.
+```
+
+**Using AAPT2**
+
+[`aapt2`](https://developer.android.com/studio/command-line/aapt2) has improved
+performance over `aapt` and also creates smaller APKs. To use `aapt2`, use the
+`--android_aapt=aapt2` flag or set `aapt2` on the `aapt_version` on
+`android_binary` and `android_local_test`.
+
+**SSD optimizations**
+
+The `--experimental_multi_threaded_digest` flag is useful for optimizing digest
+computation on SSDs.
diff --git a/versions/9.1.0/docs/android-instrumentation-test.mdx b/versions/9.1.0/docs/android-instrumentation-test.mdx
new file mode 100644
index 00000000..70d87610
--- /dev/null
+++ b/versions/9.1.0/docs/android-instrumentation-test.mdx
@@ -0,0 +1,576 @@
+---
+title: 'Android Instrumentation Tests'
+---
+
+_If you're new to Bazel, start with the [Building Android with
+Bazel](/versions/9.1.0/start/android-app) tutorial._
+
+![Running Android instrumentation tests in parallel](/versions/9.1.0/docs/images/android_test.gif "Android instrumentation test")
+
+**Figure 1.** Running parallel Android instrumentation tests.
+
+[`android_instrumentation_test`](/versions/9.1.0/reference/be/android#android_instrumentation_test)
+allows developers to test their apps on Android emulators and devices.
+It utilizes real Android framework APIs and the Android Test Library.
+
+For hermeticity and reproducibility, Bazel creates and launches Android
+emulators in a sandbox, ensuring that tests always run from a clean state. Each
+test gets an isolated emulator instance, allowing tests to run in parallel
+without passing states between them.
+
+For more information on Android instrumentation tests, check out the [Android
+developer
+documentation](https://developer.android.com/training/testing/unit-testing/instrumented-unit-tests.html).
+
+Please file issues in the [GitHub issue tracker](https://github.com/bazelbuild/bazel/issues).
+
+## How it works {#how-it-works}
+
+When you run `bazel test` on an `android_instrumentation_test` target for the
+first time, Bazel performs the following steps:
+
+1. Builds the test APK, APK under test, and their transitive dependencies
+2. Creates, boots, and caches clean emulator states
+3. Starts the emulator
+4. Installs the APKs
+5. Runs tests utilizing the [Android Test Orchestrator](https://developer.android.com/training/testing/junit-runner.html#using-android-test-orchestrator)
+6. Shuts down the emulator
+7. Reports the results
+
+In subsequent test runs, Bazel boots the emulator from the clean, cached state
+created in step 2, so there are no leftover states from previous runs. Caching
+emulator state also speeds up test runs.
+
+## Prerequisites {#prerequisites}
+
+Ensure your environment satisfies the following prerequisites:
+
+- **Linux**. Tested on Ubuntu 16.04, and 18.04.
+
+- **Bazel 0.12.0** or later. Verify the version by running `bazel info release`.
+
+```posix-terminal
+bazel info release
+```
+This results in output similar to the following:
+
+```none {:.devsite-disable-click-to-copy}
+release 4.1.0
+```
+
+- **KVM**. Bazel requires emulators to have [hardware
+  acceleration](https://developer.android.com/studio/run/emulator-acceleration.html#accel-check)
+  with KVM on Linux. You can follow these
+  [installation instructions](https://help.ubuntu.com/community/KVM/Installation)
+  for Ubuntu.
+
+To verify that KVM has the correct configuration, run:
+
+```posix-terminal
+apt-get install cpu-checker && kvm-ok
+```
+
+If it prints the following message, you have the correct configuration:
+
+```none {:.devsite-disable-click-to-copy}
+INFO: /dev/kvm exists
+KVM acceleration can be used
+```
+
+- **Xvfb**. To run headless tests (for example, on CI servers), Bazel requires
+  the [X virtual framebuffer](https://www.x.org/archive/X11R7.6/doc/man/man1/Xvfb.1.xhtml).
+
+To install it, run:
+
+```posix-terminal
+apt-get install xvfb
+```
+Verify that `Xvfb` is installed correctly and is installed at `/usr/bin/Xvfb`
+by running:
+
+```posix-terminal
+which Xvfb
+```
+The output is the following:
+
+```{:.devsite-disable-click-to-copy}
+/usr/bin/Xvfb
+```
+
+- **32-bit Libraries**. Some of the binaries used by the test infrastructure are
+  32-bit, so on 64-bit machines, ensure that 32-bit binaries can be run. For
+  Ubuntu, install these 32-bit libraries:
+
+```posix-terminal
+sudo apt-get install libc6:i386 libncurses5:i386 libstdc++6:i386 lib32z1 libbz2-1.0:i386
+```
+
+## Getting started {#getting-started}
+
+Here is a typical target dependency graph of an `android_instrumentation_test`:
+
+![The target dependency graph on an Android instrumentation test](/versions/9.1.0/docs/images/android_instrumentation_test.png "Target dependency graph")
+
+**Figure 2.** Target dependency graph of an `android_instrumentation_test`.
+
+### BUILD file {#build-file}
+
+The graph translates into a `BUILD` file like this:
+
+```python
+android_instrumentation_test(
+    name = "my_test",
+    test_app = ":my_test_app",
+    target_device = "@android_test_support//tools/android/emulated_devices/generic_phone:android_23_x86",
+)
+
+# Test app and library
+android_binary(
+    name = "my_test_app",
+    instruments = ":my_app",
+    manifest = "AndroidTestManifest.xml",
+    deps = [":my_test_lib"],
+    # ...
+)
+
+android_library(
+    name = "my_test_lib",
+    srcs = glob(["javatest/**/*.java"]),
+    deps = [
+        ":my_app_lib",
+        "@maven//:androidx_test_core",
+        "@maven//:androidx_test_runner",
+        "@maven//:androidx_test_espresso_espresso_core",
+    ],
+    # ...
+)
+
+# Target app and library under test
+android_binary(
+    name = "my_app",
+    manifest = "AndroidManifest.xml",
+    deps = [":my_app_lib"],
+    # ...
+)
+
+android_library(
+    name = "my_app_lib",
+    srcs = glob(["java/**/*.java"]),
+    deps = [
+        "@maven//:androidx_appcompat_appcompat",
+        "@maven//:androidx_annotation_annotation",
+    ]
+    # ...
+)
+```
+
+The main attributes of the rule `android_instrumentation_test` are:
+
+- `test_app`: An `android_binary` target. This target contains test code and
+  dependencies like Espresso and UIAutomator. The selected `android_binary`
+  target is required to specify an `instruments` attribute pointing to another
+  `android_binary`, which is the app under test.
+
+- `target_device`: An `android_device` target. This target describes the
+  specifications of the Android emulator which Bazel uses to create, launch and
+  run the tests. See the [section on choosing an Android
+  device](#android-device-target) for more information.
+
+The test app's `AndroidManifest.xml` must include [an ``
+tag](https://developer.android.com/studio/test/#configure_instrumentation_manifest_settings).
+This tag must specify the attributes for the **package of the target app** and
+the **fully qualified class name of the instrumentation test runner**,
+`androidx.test.runner.AndroidJUnitRunner`.
+
+Here is an example `AndroidTestManifest.xml` for the test app:
+
+```xml
+
+
+
+    
+
+    
+
+    
+       
+    
+
+```
+
+### WORKSPACE dependencies {#workspace-dependencies}
+
+In order to use this rule, your project needs to depend on these external
+repositories:
+
+- `@androidsdk`: The Android SDK. Download this through Android Studio.
+
+- `@android_test_support`: Hosts the test runner, emulator launcher, and
+  `android_device` targets. You can find the [latest release
+  here](https://github.com/android/android-test/releases).
+
+Enable these dependencies by adding the following lines to your `WORKSPACE`
+file:
+
+```python
+# Android SDK
+android_sdk_repository(
+    name = "androidsdk",
+    path = "/path/to/sdk", # or set ANDROID_HOME
+)
+
+# Android Test Support
+ATS_COMMIT = "$COMMIT_HASH"
+http_archive(
+    name = "android_test_support",
+    strip_prefix = "android-test-%s" % ATS_COMMIT,
+    urls = ["https://github.com/android/android-test/archive/%s.tar.gz" % ATS_COMMIT],
+)
+load("@android_test_support//:repo.bzl", "android_test_repositories")
+android_test_repositories()
+```
+
+## Maven dependencies {#maven-dependencies}
+
+For managing dependencies on Maven artifacts from repositories, such as [Google
+Maven](https://maven.google.com) or [Maven Central](https://central.maven.org),
+you should use a Maven resolver, such as
+[`rules_jvm_external`](https://github.com/bazelbuild/rules_jvm_external).
+
+The rest of this page shows how to use `rules_jvm_external` to
+resolve and fetch dependencies from Maven repositories.
+
+## Choosing an android_device target {#android-device-target}
+
+`android_instrumentation_test.target_device` specifies which Android device to
+run the tests on. These `android_device` targets are defined in
+[`@android_test_support`](https://github.com/google/android-testing-support-library/tree/master/tools/android/emulated_devices).
+
+For example, you can query for the sources for a particular target by running:
+
+```posix-terminal
+bazel query --output=build @android_test_support//tools/android/emulated_devices/generic_phone:android_23_x86
+```
+Which results in output that looks similar to:
+
+```python
+# .../external/android_test_support/tools/android/emulated_devices/generic_phone/BUILD:43:1
+android_device(
+  name = "android_23_x86",
+  visibility = ["//visibility:public"],
+  tags = ["requires-kvm"],
+  generator_name = "generic_phone",
+  generator_function = "make_device",
+  generator_location = "tools/android/emulated_devices/generic_phone/BUILD:43",
+  vertical_resolution = 800,
+  horizontal_resolution = 480,
+  ram = 2048,
+  screen_density = 240,
+  cache = 32,
+  vm_heap = 256,
+  system_image = "@android_test_support//tools/android/emulated_devices/generic_phone:android_23_x86_images",
+  default_properties = "@android_test_support//tools/android/emulated_devices/generic_phone:_android_23_x86_props",
+)
+```
+
+The device target names use this template:
+
+```
+@android_test_support//tools/android/emulated_devices/`device_type`:`system`_`api_level`_x86_qemu2
+```
+
+In order to launch an `android_device`, the `system_image` for the selected API
+level is required. To download the system image, use Android SDK's
+`tools/bin/sdkmanager`. For example, to download the system image for
+`generic_phone:android_23_x86`, run `$sdk/tools/bin/sdkmanager
+"system-images;android-23;default;x86"`.
+
+To see the full list of supported `android_device` targets in
+`@android_test_support`, run the following command:
+
+```posix-terminal
+bazel query 'filter("x86_qemu2$", kind(android_device, @android_test_support//tools/android/emulated_devices/...:*))'
+```
+
+Bazel currently supports x86-based emulators only. For better performance, use
+`QEMU2` `android_device` targets instead of `QEMU` ones.
+
+## Running tests {#running-tests}
+
+To run tests, add these lines to your project's
+`PROJECT_ROOT/.bazelrc` file.
+
+```
+# Configurations for testing with Bazel
+# Select a configuration by running
+# `bazel test //my:target --config={headless, gui, local_device}`
+
+# Headless instrumentation tests (No GUI)
+test:headless --test_arg=--enable_display=false
+
+# Graphical instrumentation tests. Ensure that $DISPLAY is set.
+test:gui --test_env=DISPLAY
+test:gui --test_arg=--enable_display=true
+
+# Testing with a local emulator or device. Ensure that `adb devices` lists the
+# device.
+# Run tests serially.
+test:local_device --test_strategy=exclusive
+# Use the local device broker type, as opposed to WRAPPED_EMULATOR.
+test:local_device --test_arg=--device_broker_type=LOCAL_ADB_SERVER
+# Uncomment and set $device_id if there is more than one connected device.
+# test:local_device --test_arg=--device_serial_number=$device_id
+```
+
+Then, use one of the configurations to run tests:
+
+- `bazel test //my/test:target --config=gui`
+- `bazel test //my/test:target --config=headless`
+- `bazel test //my/test:target --config=local_device`
+
+Use __only one configuration__ or tests will fail.
+
+### Headless testing {#headless-testing}
+
+With `Xvfb`, it is possible to test with emulators without the graphical
+interface, also known as headless testing. To disable the graphical interface
+when running tests, pass the test argument `--enable_display=false` to Bazel:
+
+```posix-terminal
+bazel test //my/test:target --test_arg=--enable_display=false
+```
+
+### GUI testing {#gui-testing}
+
+If the `$DISPLAY` environment variable is set, it's possible to enable the
+graphical interface of the emulator while the test is running. To do this, pass
+these test arguments to Bazel:
+
+```posix-terminal
+bazel test //my/test:target --test_arg=--enable_display=true --test_env=DISPLAY
+```
+
+### Testing with a local emulator or device {#testing-local-emulator}
+
+Bazel also supports testing directly on a locally launched emulator or connected
+device. Pass the flags
+`--test_strategy=exclusive` and
+`--test_arg=--device_broker_type=LOCAL_ADB_SERVER` to enable local testing mode.
+If there is more than one connected device, pass the flag
+`--test_arg=--device_serial_number=$device_id` where `$device_id` is the id of
+the device/emulator listed in `adb devices`.
+
+## Sample projects {#sample-projects}
+
+If you are looking for canonical project samples, see the [Android testing
+samples](https://github.com/googlesamples/android-testing#experimental-bazel-support)
+for projects using Espresso and UIAutomator.
+
+## Espresso setup {#espresso-setup}
+
+If you write UI tests with [Espresso](https://developer.android.com/training/testing/espresso/)
+(`androidx.test.espresso`), you can use the following snippets to set up your
+Bazel workspace with the list of commonly used Espresso artifacts and their
+dependencies:
+
+```
+androidx.test.espresso:espresso-core
+androidx.test:rules
+androidx.test:runner
+javax.inject:javax.inject
+org.hamcrest:java-hamcrest
+junit:junit
+```
+
+One way to organize these dependencies is to create a `//:test_deps` shared
+library in your ``project root`/BUILD.bazel` file:
+
+```python
+java_library(
+    name = "test_deps",
+    visibility = ["//visibility:public"],
+    exports = [
+        "@maven//:androidx_test_espresso_espresso_core",
+        "@maven//:androidx_test_rules",
+        "@maven//:androidx_test_runner",
+        "@maven//:javax_inject_javax_inject"
+        "@maven//:org_hamcrest_java_hamcrest",
+        "@maven//:junit_junit",
+    ],
+)
+```
+
+Then, add the required dependencies in ``project root`/WORKSPACE`:
+
+```python
+load("@bazel_tools//tools/build_defs/repo:http.bzl", "http_archive")
+
+RULES_JVM_EXTERNAL_TAG = "2.8"
+RULES_JVM_EXTERNAL_SHA = "79c9850690d7614ecdb72d68394f994fef7534b292c4867ce5e7dec0aa7bdfad"
+
+http_archive(
+    name = "rules_jvm_external",
+    strip_prefix = "rules_jvm_external-%s" % RULES_JVM_EXTERNAL_TAG,
+    sha256 = RULES_JVM_EXTERNAL_SHA,
+    url = "https://github.com/bazelbuild/rules_jvm_external/archive/%s.zip" % RULES_JVM_EXTERNAL_TAG,
+)
+
+load("@rules_jvm_external//:defs.bzl", "maven_install")
+
+maven_install(
+    artifacts = [
+        "junit:junit:4.12",
+        "javax.inject:javax.inject:1",
+        "org.hamcrest:java-hamcrest:2.0.0.0"
+        "androidx.test.espresso:espresso-core:3.1.1",
+        "androidx.test:rules:aar:1.1.1",
+        "androidx.test:runner:aar:1.1.1",
+    ],
+    repositories = [
+        "https://maven.google.com",
+        "https://repo1.maven.org/maven2",
+    ],
+)
+```
+
+Finally, in your test `android_binary` target, add the `//:test_deps`
+dependency:
+
+```python
+android_binary(
+    name = "my_test_app",
+    instruments = "//path/to:app",
+    deps = [
+        "//:test_deps",
+        # ...
+    ],
+    # ...
+)
+```
+
+## Tips {#tips}
+
+### Reading test logs {#reading-test-logs}
+
+Use `--test_output=errors` to print logs for failing tests, or
+`--test_output=all` to print all test output. If you're looking for an
+individual test log, go to
+`$PROJECT_ROOT/bazel-testlogs/path/to/InstrumentationTestTargetName`.
+
+For example, the test logs for `BasicSample` canonical project are in
+`bazel-testlogs/ui/espresso/BasicSample/BasicSampleInstrumentationTest`, run:
+
+```posix-terminal
+tree bazel-testlogs/ui/espresso/BasicSample/BasicSampleInstrumentationTest
+```
+This results in the following output:
+
+```none
+
+$ tree bazel-testlogs/ui/espresso/BasicSample/BasicSampleInstrumentationTest
+.
+├── adb.409923.log
+├── broker_logs
+│   ├── aapt_binary.10.ok.txt
+│   ├── aapt_binary.11.ok.txt
+│   ├── adb.12.ok.txt
+│   ├── adb.13.ok.txt
+│   ├── adb.14.ok.txt
+│   ├── adb.15.fail.txt
+│   ├── adb.16.ok.txt
+│   ├── adb.17.fail.txt
+│   ├── adb.18.ok.txt
+│   ├── adb.19.fail.txt
+│   ├── adb.20.ok.txt
+│   ├── adb.21.ok.txt
+│   ├── adb.22.ok.txt
+│   ├── adb.23.ok.txt
+│   ├── adb.24.fail.txt
+│   ├── adb.25.ok.txt
+│   ├── adb.26.fail.txt
+│   ├── adb.27.ok.txt
+│   ├── adb.28.fail.txt
+│   ├── adb.29.ok.txt
+│   ├── adb.2.ok.txt
+│   ├── adb.30.ok.txt
+│   ├── adb.3.ok.txt
+│   ├── adb.4.ok.txt
+│   ├── adb.5.ok.txt
+│   ├── adb.6.ok.txt
+│   ├── adb.7.ok.txt
+│   ├── adb.8.ok.txt
+│   ├── adb.9.ok.txt
+│   ├── android_23_x86.1.ok.txt
+│   └── exec-1
+│       ├── adb-2.txt
+│       ├── emulator-2.txt
+│       └── mksdcard-1.txt
+├── device_logcat
+│   └── logcat1635880625641751077.txt
+├── emulator_itCqtc.log
+├── outputs.zip
+├── pipe.log.txt
+├── telnet_pipe.log.txt
+└── tmpuRh4cy
+    ├── watchdog.err
+    └── watchdog.out
+
+4 directories, 41 files
+```
+
+### Reading emulator logs {#reading-emulator-logs}
+
+The emulator logs for `android_device` targets are stored in the `/tmp/`
+directory with the name `emulator_xxxxx.log`, where `xxxxx` is a
+randomly-generated sequence of characters.
+
+Use this command to find the latest emulator log:
+
+```posix-terminal
+ls -1t /tmp/emulator_*.log | head -n 1
+```
+
+### Testing against multiple API levels {#testing-multiple-apis}
+
+If you would like to test against multiple API levels, you can use a list
+comprehension to create test targets for each API level. For example:
+
+```python
+API_LEVELS = [
+    "19",
+    "20",
+    "21",
+    "22",
+]
+
+[android_instrumentation_test(
+    name = "my_test_%s" % API_LEVEL,
+    test_app = ":my_test_app",
+    target_device = "@android_test_support//tools/android/emulated_devices/generic_phone:android_%s_x86_qemu2" % API_LEVEL,
+) for API_LEVEL in API_LEVELS]
+```
+
+## Known issues {#known-issues}
+
+- [Forked adb server processes are not terminated after
+  tests](https://github.com/bazelbuild/bazel/issues/4853)
+- While APK building works on all platforms (Linux, macOS, Windows), testing
+  only works on Linux.
+- Even with `--config=local_adb`, users still need to specify
+  `android_instrumentation_test.target_device`.
+- If using a local device or emulator, Bazel does not uninstall the APKs after
+  the test. Clean the packages by running this command:
+
+```posix-terminal
+adb shell pm list
+packages com.example.android.testing | cut -d ':' -f 2 | tr -d '\r' | xargs
+-L1 -t adb uninstall
+```
diff --git a/versions/9.1.0/docs/android-ndk.mdx b/versions/9.1.0/docs/android-ndk.mdx
new file mode 100644
index 00000000..04984145
--- /dev/null
+++ b/versions/9.1.0/docs/android-ndk.mdx
@@ -0,0 +1,339 @@
+---
+title: 'Using the Android Native Development Kit with Bazel'
+---
+
+_If you're new to Bazel, please start with the [Building Android with
+Bazel](/versions/9.1.0/start/android-app) tutorial._
+
+## Overview {#overview}
+
+Bazel can run in many different build configurations, including several that use
+the Android Native Development Kit (NDK) toolchain. This means that normal
+`cc_library` and `cc_binary` rules can be compiled for Android directly within
+Bazel. Bazel accomplishes this by using the `android_ndk_repository` repository
+rule and its related bzlmod extension.
+
+For general Android
+compilation, use [`rules_android`](https://github.com/bazelbuild/rules_android).
+This tutorial demonstrates how to integrate C++ library dependencies into
+Android apps and uses
+[`rules_android_ndk`](https://github.com/bazelbuild/rules_android_ndk) for NDK
+toolchain discovery and registration.
+
+## Prerequisites {#prerequisites}
+
+Please ensure that you have installed the Android SDK and NDK.
+
+### NDK and SDK setup {#ndk-sdk-setup}
+
+External repository setup varies depending on whether you are using WORKSPACE
+or bzlmod (MODULE.bazel). *Bzlmod is the preferred solution for Bazel 7+.*
+Note that the MODULE.bazel and WORKSPACE setup stanzas are independent of
+each other.
+If you are using one dependency management solution, you don't need to add
+the boilerplate for the other.
+
+#### Bzlmod MODULE.bazel setup {#ndk-sdk-setup-bzlmod}
+
+Add the following snippet to your MODULE.bazel:
+
+```python
+# NDK
+bazel_dep(name = "rules_android_ndk", version = "0.1.3")
+android_ndk_repository_extension = use_extension("@rules_android_ndk//:extension.bzl", "android_ndk_repository_extension")
+use_repo(android_ndk_repository_extension, "androidndk")
+register_toolchains("@androidndk//:all")
+
+# SDK
+bazel_dep(name = "rules_android", version = "0.6.6")
+register_toolchains(
+    "@rules_android//toolchains/android:android_default_toolchain",
+    "@rules_android//toolchains/android_sdk:android_sdk_tools",
+)
+android_sdk_repository_extension = use_extension("@rules_android//rules/android_sdk_repository:rule.bzl", "android_sdk_repository_extension")
+use_repo(android_sdk_repository_extension, "androidsdk")
+register_toolchains("@androidsdk//:sdk-toolchain", "@androidsdk//:all")
+```
+
+#### Legacy WORKSPACE setup {#ndk-sdk-setup-workspace}
+
+Add the following snippet to your `WORKSPACE`:
+
+```python
+load("@rules_android//rules:rules.bzl", "android_sdk_repository")
+android_sdk_repository(
+    name = "androidsdk", # Required. Name *must* be "androidsdk".
+    path = "/path/to/sdk", # Optional. Can be omitted if `ANDROID_HOME` environment variable is set.
+)
+
+load("@rules_android_ndk//:rules.bzl", "android_ndk_repository")
+android_ndk_repository(
+    name = "androidndk", # Required. Name *must* be "androidndk".
+    path = "/path/to/ndk", # Optional. Can be omitted if `ANDROID_NDK_HOME` environment variable is set.
+)
+```
+
+Compatibility notes for WORKSPACE:
+
+* Both `rules_android` and `rules_android_ndk` rules require extra
+  boilerplate not depicted in the WORKSPACE snippet above. For an up-to-date
+  and fully-formed instantiation stanza, see the [WORKSPACE](https://github.com/bazelbuild/rules_android_ndk/blob/main/examples/basic/WORKSPACE)
+  file of `rules_android_ndk`'s basic example app.
+
+For more information about the `android_ndk_repository` rule, see its
+[docstring](https://github.com/bazelbuild/rules_android_ndk/blob/7b4300f6d731139ca097f3332a5aebae5b0d91d0/rules.bzl#L18-L25).
+
+## Quick start {#quick-start}
+
+To build C++ for Android, simply add `cc_library` dependencies to your
+`android_binary` or `android_library` rules.
+
+For example, given the following `BUILD` file for an Android app:
+
+```python
+# In /app/src/main/BUILD.bazel
+load("@rules_cc//cc:cc_library.bzl", "cc_library")
+load("@rules_android//rules:rules.bzl", "android_binary", "android_library")
+
+cc_library(
+    name = "jni_lib",
+    srcs = ["cpp/native-lib.cpp"],
+)
+
+android_library(
+    name = "lib",
+    srcs = ["java/com/example/android/bazel/MainActivity.java"],
+    resource_files = glob(["res/**/*"]),
+    custom_package = "com.example.android.bazel",
+    manifest = "LibraryManifest.xml",
+    deps = [":jni_lib"],
+)
+
+android_binary(
+    name = "app",
+    deps = [":lib"],
+    manifest = "AndroidManifest.xml",
+)
+```
+
+This `BUILD` file results in the following target graph:
+
+![Example results](/versions/9.1.0/docs/images/android_ndk.png "Build graph results")
+
+**Figure 1.** Build graph of Android project with cc_library dependencies.
+
+To build the app, simply run:
+
+```posix-terminal
+bazel build //app/src/main:app --android_platforms=
+```
+
+Note that if you don't specify `--android_platforms`, your build will fail with
+errors about missing JNI headers.
+
+The `bazel build` command compiles the Java files, Android resource files, and
+`cc_library` rules, and packages everything into an APK:
+
+```posix-terminal
+$ zipinfo -1 bazel-bin/app/src/main/app.apk
+nativedeps
+lib/armeabi-v7a/libapp.so
+classes.dex
+AndroidManifest.xml
+...
+res/...
+...
+META-INF/CERT.SF
+META-INF/CERT.RSA
+META-INF/MANIFEST.MF
+```
+
+Bazel compiles all of the cc_libraries into a single shared object (`.so`) file,
+targeted the architectures specified by `--android_platforms`.
+See the section on [configuring the target ABI](#configuring-target-abi) for
+more details.
+
+## Example setup {#example-setup}
+
+This example is available in the [Bazel examples
+repository](https://github.com/bazelbuild/examples/tree/master/android/ndk).
+
+In the `BUILD.bazel` file, three targets are defined with the `android_binary`,
+`android_library`, and `cc_library` rules.
+
+The `android_binary` top-level target builds the APK.
+
+The `cc_library` target contains a single C++ source file with a JNI function
+implementation:
+
+```c++
+#include 
+#include 
+
+extern "C"
+JNIEXPORT jstring
+
+JNICALL
+Java_com_example_android_bazel_MainActivity_stringFromJNI(
+        JNIEnv *env,
+        jobject /* this */) {
+    std::string hello = "Hello from C++";
+    return env->NewStringUTF(hello.c_str());
+}
+```
+
+The `android_library` target specifies the Java sources, resource files, and the
+dependency on a `cc_library` target. For this example, `MainActivity.java` loads
+the shared object file `libapp.so`, and defines the method signature for the JNI
+function:
+
+```java
+public class MainActivity extends AppCompatActivity {
+
+    static {
+        System.loadLibrary("app");
+    }
+
+    @Override
+    protected void onCreate(Bundle savedInstanceState) {
+       // ...
+    }
+
+    public native String stringFromJNI();
+
+}
+```
+
+Note: The name of the native library is derived from the name of the top
+level `android_binary` target. In this example, it is `app`.
+
+## Configuring the target ABI {#configuring-target-abi}
+
+To configure the target ABI, use the `--android_platforms` flag as follows:
+
+```posix-terminal
+bazel build //:app --android_platforms=`comma-separated list of platforms`
+```
+
+Just like the `--platforms` flag, the values passed to `--android_platforms` are
+the labels of [`platform`](https://bazel.build/versions/9.1.0/reference/be/platforms-and-toolchains#platform)
+targets, using standard constraint values to describe your device.
+
+For example, for an Android device with a 64-bit ARM processor, you'd define
+your platform like this:
+
+```py
+platform(
+    name = "android_arm64",
+    constraint_values = [
+        "@platforms//os:android",
+        "@platforms//cpu:arm64",
+    ],
+)
+```
+
+Every Android `platform` should use the [`@platforms//os:android`](https://github.com/bazelbuild/platforms/blob/33a3b209f94856193266871b1545054afb90bb28/os/BUILD#L36)
+OS constraint. To migrate the CPU constraint, check this chart:
+
+CPU Value     | Platform
+------------- | ------------------------------------------
+`armeabi-v7a` | `@platforms//cpu:armv7`
+`arm64-v8a`   | `@platforms//cpu:arm64`
+`x86`         | `@platforms//cpu:x86_32`
+`x86_64`      | `@platforms//cpu:x86_64`
+
+And, of course, for a multi-architecture APK, you pass multiple labels, for
+example: `--android_platforms=//:arm64,//:x86_64` (assuming you defined those in
+your top-level `BUILD.bazel` file).
+
+Bazel is unable to select a default Android platform, so one must be defined and
+specified with `--android_platforms`.
+
+Depending on the NDK revision and Android API level, the following ABIs are
+available:
+
+| NDK revision | ABIs                                                        |
+|--------------|-------------------------------------------------------------|
+| 16 and lower | armeabi, armeabi-v7a, arm64-v8a, mips, mips64, x86, x86\_64 |
+| 17 and above | armeabi-v7a, arm64-v8a, x86, x86\_64                        |
+
+See [the NDK docs](https://developer.android.com/ndk/guides/abis.html)
+for more information on these ABIs.
+
+Multi-ABI Fat APKs are not recommended for release builds since they increase
+the size of the APK, but can be useful for development and QA builds.
+
+## Selecting a C++ standard {#selecting-c-standard}
+
+Use the following flags to build according to a C++ standard:
+
+| C++ Standard | Flag                    |
+|--------------|-------------------------|
+| C++98        | Default, no flag needed |
+| C++11        | `--cxxopt=-std=c++11`   |
+| C++14        | `--cxxopt=-std=c++14`   |
+| C++17        | `--cxxopt=-std=c++17`   |
+
+For example:
+
+```posix-terminal
+bazel build //:app --cxxopt=-std=c++11
+```
+
+Read more about passing compiler and linker flags with `--cxxopt`, `--copt`, and
+`--linkopt` in the [User Manual](/versions/9.1.0/docs/user-manual#cxxopt).
+
+Compiler and linker flags can also be specified as attributes in `cc_library`
+using `copts` and `linkopts`. For example:
+
+```python
+cc_library(
+    name = "jni_lib",
+    srcs = ["cpp/native-lib.cpp"],
+    copts = ["-std=c++11"],
+    linkopts = ["-ldl"], # link against libdl
+)
+```
+
+## Building a `cc_library` for Android without using `android_binary` {#cclibrary-android}
+
+To build a standalone `cc_binary` or `cc_library` for Android without using an
+`android_binary`, use the `--platforms` flag.
+
+For example, assuming you have defined Android platforms in
+`my/platforms/BUILD`:
+
+```posix-terminal
+bazel build //my/cc/jni:target \
+      --platforms=//my/platforms:x86_64
+```
+
+With this approach, the entire build tree is affected.
+
+Note: All of the targets on the command line must be compatible with
+building for Android when specifying these flags, which may make it difficult to
+use [Bazel wild-cards](/versions/9.1.0/run/build#specifying-build-targets) like
+`/...` and `:all`.
+
+These flags can be put into a `bazelrc` config (one for each ABI), in
+`PROJECT/.bazelrc`:
+
+```
+common:android_x86 --platforms=//my/platforms:x86
+
+common:android_armeabi-v7a --platforms=//my/platforms:armeabi-v7a
+
+# In general
+common:android_ --platforms=//my/platforms:
+```
+
+Then, to build a `cc_library` for `x86` for example, run:
+
+```posix-terminal
+bazel build //my/cc/jni:target --config=android_x86
+```
+
+In general, use this method for low-level targets (like `cc_library`) or when
+you know exactly what you're building; rely on the automatic configuration
+transitions from `android_binary` for high-level targets where you're expecting
+to build a lot of targets you don't control.
diff --git a/versions/9.1.0/docs/bazel-and-android.mdx b/versions/9.1.0/docs/bazel-and-android.mdx
new file mode 100644
index 00000000..c449867b
--- /dev/null
+++ b/versions/9.1.0/docs/bazel-and-android.mdx
@@ -0,0 +1,43 @@
+---
+title: 'Android and Bazel'
+---
+
+This page contains resources that help you use Bazel with Android projects. It
+links to a tutorial, build rules, and other information specific to building
+Android projects with Bazel.
+
+## Getting started {#getting-started}
+
+The following resources will help you work with Bazel on Android projects:
+
+*  [Tutorial: Building an Android app](/versions/9.1.0/start/android-app). This
+   tutorial is a good place to start learning about Bazel commands and concepts,
+   and how to build Android apps with Bazel.
+*  [Codelab: Building Android Apps with Bazel](https://developer.android.com/codelabs/bazel-android-intro#0).
+   This codelab explains how to build Android apps with Bazel.
+
+## Features {#features}
+
+Bazel has Android rules for building and testing Android apps, integrating with
+the SDK/NDK, and creating emulator images. There are also Bazel plugins for
+Android Studio and IntelliJ.
+
+*  [Android rules](/versions/9.1.0/reference/be/android). The Build Encyclopedia describes the rules
+   for building and testing Android apps with Bazel.
+*  [Integration with Android Studio](/versions/9.1.0/install/ide). Bazel is compatible with
+   Android Studio using the [Android Studio with Bazel](https://ij.bazel.build/)
+   plugin.
+*  [`mobile-install` for Android](/versions/9.1.0/docs/mobile-install). Bazel's `mobile-install`
+   feature provides automated build-and-deploy functionality for building and
+   testing Android apps directly on Android devices and emulators.
+*  [Android instrumentation testing](/versions/9.1.0/docs/android-instrumentation-test) on
+   emulators and devices.
+*  [Android NDK integration](/versions/9.1.0/docs/android-ndk). Bazel supports compiling to
+   native code through direct NDK integration and the C++ rules.
+*  [Android build performance](/versions/9.1.0/docs/android-build-performance). This page
+   provides information on optimizing build performance for Android apps.
+
+## Further reading {#further-reading}
+
+*  Integrating with dependencies from Google Maven and Maven Central with [rules_jvm_external](https://github.com/bazelbuild/rules_jvm_external).
+*  Learn [How Android Builds Work in Bazel](https://blog.bazel.build/2018/02/14/how-android-builds-work-in-bazel.html).
diff --git a/versions/9.1.0/docs/bazel-and-apple.mdx b/versions/9.1.0/docs/bazel-and-apple.mdx
new file mode 100644
index 00000000..b91c183f
--- /dev/null
+++ b/versions/9.1.0/docs/bazel-and-apple.mdx
@@ -0,0 +1,84 @@
+---
+title: 'Apple Apps and Bazel'
+---
+
+This page contains resources that help you use Bazel to build macOS and iOS
+projects. It links to a tutorial, build rules, and other information specific to
+using Bazel to build and test for those platforms.
+
+## Working with Bazel {#working-with-bazel}
+
+The following resources will help you work with Bazel on macOS and iOS projects:
+
+*  [Tutorial: Building an iOS app](/versions/9.1.0/start/ios-app)
+*  [Objective-C build rules](/versions/9.1.0/reference/be/objective-c)
+*  [General Apple rules](https://github.com/bazelbuild/rules_apple)
+*  [Integration with Xcode](/versions/9.1.0/install/ide)
+
+## Migrating to Bazel {#migrating-to-bazel}
+
+If you currently build your macOS and iOS projects with Xcode, follow the steps
+in the migration guide to start building them with Bazel:
+
+*  [Migrating from Xcode to Bazel](/versions/9.1.0/migrate/xcode)
+
+## Apple apps and new rules {#apple-apps-new-rules}
+
+**Note**: Creating new rules is for advanced build and test scenarios.
+You do not need it when getting started with Bazel.
+
+The following modules, configuration fragments, and providers will help you
+[extend Bazel's capabilities](/versions/9.1.0/extending/concepts)
+when building your macOS and iOS projects:
+
+*  Modules:
+
+   *  [`apple_bitcode_mode`](/versions/9.1.0/rules/lib/builtins/apple_bitcode_mode)
+   *  [`apple_common`](/versions/9.1.0/rules/lib/toplevel/apple_common)
+   *  [`apple_platform`](/versions/9.1.0/rules/lib/builtins/apple_platform)
+   *  [`apple_platform_type`](/versions/9.1.0/rules/lib/builtins/apple_platform_type)
+   *  [`apple_toolchain`](/versions/9.1.0/rules/lib/builtins/apple_toolchain)
+
+*  Configuration fragments:
+
+   *  [`apple`](/versions/9.1.0/rules/lib/fragments/apple)
+
+*  Providers:
+
+   *  [`ObjcProvider`](/versions/9.1.0/rules/lib/providers/ObjcProvider)
+   *  [`XcodeVersionConfig`](/versions/9.1.0/rules/lib/providers/XcodeVersionConfig)
+
+## Xcode selection {#xcode-selection}
+
+If your build requires Xcode, Bazel will select an appropriate version based on
+the `--xcode_config` and `--xcode_version` flags. The `--xcode_config` consumes
+the set of available Xcode versions and sets a default version if
+`--xcode_version` is not passed. This default is overridden by the
+`--xcode_version` flag, as long as it is set to an Xcode version that is
+represented in the `--xcode_config` target.
+
+If you do not pass `--xcode_config`, Bazel will use the autogenerated
+[`XcodeVersionConfig`](/versions/9.1.0/rules/lib/providers/XcodeVersionConfig) that represents the
+Xcode versions available on your host machine. The default version is
+the newest available Xcode version. This is appropriate for local execution.
+
+If you are performing remote builds, you should set `--xcode_config` to an
+[`xcode_config`](/versions/9.1.0/reference/be/objective-c#xcode_config)
+target whose `versions` attribute is a list of remotely available
+[`xcode_version`](/versions/9.1.0/reference/be/objective-c#xcode_version)
+targets, and whose `default` attribute is one of these
+[`xcode_versions`](/versions/9.1.0/reference/be/objective-c#xcode_version).
+
+If you are using dynamic execution, you should set `--xcode_config` to an
+[`xcode_config`](/versions/9.1.0/reference/be/objective-c#xcode_config)
+target whose `remote_versions` attribute is an
+[`available_xcodes`](/versions/9.1.0/reference/be/workspace#available_xcodes)
+target containing the remotely available Xcode versions, and whose
+`local_versions` attribute is an
+[`available_xcodes`](/versions/9.1.0/reference/be/workspace#available_xcodes)
+target containing the locally available Xcode versions. For `local_versions`,
+you probably want to use the autogenerated
+`@local_config_xcode//:host_available_xcodes`. The default Xcode version is the
+newest mutually available version, if there is one, otherwise the default of the
+`local_versions` target. If you prefer to use the `local_versions` default
+as the default, you can pass `--experimental_prefer_mutual_default=false`.
diff --git a/versions/9.1.0/docs/bazel-and-cpp.mdx b/versions/9.1.0/docs/bazel-and-cpp.mdx
new file mode 100644
index 00000000..38d379e7
--- /dev/null
+++ b/versions/9.1.0/docs/bazel-and-cpp.mdx
@@ -0,0 +1,100 @@
+---
+title: 'C++ and Bazel'
+---
+
+This page contains resources that help you use Bazel with C++ projects. It links
+to a tutorial, build rules, and other information specific to building C++
+projects with Bazel.
+
+## Working with Bazel {#working-with-bazel}
+
+The following resources will help you work with Bazel on C++ projects:
+
+*  [Tutorial: Building a C++ project](/versions/9.1.0/start/cpp)
+*  [C++ common use cases](/versions/9.1.0/tutorials/cpp-use-cases)
+*  [C/C++ rules](/versions/9.1.0/reference/be/c-cpp)
+*  Essential Libraries
+   -  [Abseil](https://abseil.io/docs/cpp/quickstart)
+   -  [Boost](https://github.com/nelhage/rules_boost)
+   -  [HTTPS Requests: CPR and libcurl](https://github.com/hedronvision/bazel-make-cc-https-easy)
+*  [C++ toolchain configuration](/versions/9.1.0/docs/cc-toolchain-config-reference)
+*  [Tutorial: Configuring C++ toolchains](/versions/9.1.0/tutorials/ccp-toolchain-config)
+*  [Integrating with C++ rules](/versions/9.1.0/configure/integrate-cpp)
+
+## Best practices {#best-practices}
+
+In addition to [general Bazel best practices](/versions/9.1.0/configure/best-practices), below are
+best practices specific to C++ projects.
+
+### BUILD files {#build-files}
+
+Follow the guidelines below when creating your BUILD files:
+
+*  Each `BUILD` file should contain one [`cc_library`](/versions/9.1.0/reference/be/c-cpp#cc_library)
+   rule target per compilation unit in the directory.
+
+*  You should granularize your C++ libraries as much as
+   possible to maximize incrementality and parallelize the build.
+
+*  If there is a single source file in `srcs`, name the library the same as
+   that C++ file's name. This library should contain C++ file(s), any matching
+   header file(s), and the library's direct dependencies. For example:
+
+   ```python
+   cc_library(
+       name = "mylib",
+       srcs = ["mylib.cc"],
+       hdrs = ["mylib.h"],
+       deps = [":lower-level-lib"]
+   )
+   ```
+
+*  Use one `cc_test` rule target per `cc_library` target in the file. Name the
+   target `[library-name]_test` and the source file `[library-name]_test.cc`.
+   For example, a test target for the `mylib` library target shown above would
+   look like this:
+
+   ```python
+   cc_test(
+       name = "mylib_test",
+       srcs = ["mylib_test.cc"],
+       deps = [":mylib"]
+   )
+   ```
+
+### Include paths {#include-paths}
+
+Follow these guidelines for include paths:
+
+*  Make all include paths relative to the workspace directory.
+
+*  Use quoted includes (`#include "foo/bar/baz.h"`) for non-system headers, not
+   angle-brackets (`#include `).
+
+*  Avoid using UNIX directory shortcuts, such as `.` (current directory) or `..`
+   (parent directory).
+
+*  For legacy or `third_party` code that requires includes pointing outside the
+   project repository, such as external repository includes requiring a prefix,
+   use the [`include_prefix`](/versions/9.1.0/reference/be/c-cpp#cc_library.include_prefix) and
+   [`strip_include_prefix`](/versions/9.1.0/reference/be/c-cpp#cc_library.strip_include_prefix)
+   arguments on the `cc_library` rule target.
+
+### Toolchain features {#toolchain-features}
+
+The following optional [features](/versions/9.1.0/docs/cc-toolchain-config-reference#features)
+can improve the hygiene of a C++ project. They can be enabled using the
+`--features` command-line flag or the `features` attribute of
+[`repo`](/versions/9.1.0/external/overview#repo.bazel),
+[`package`](/versions/9.1.0/reference/be/functions#package) or `cc_*` rules:
+
+* The `parse_headers` feature makes it so that the C++ compiler is used to parse
+  (but not compile) all header files in the built targets and their dependencies
+  when using the
+  [`--process_headers_in_dependencies`](/versions/9.1.0/reference/command-line-reference#flag--process_headers_in_dependencies)
+  flag. This can help catch issues in header-only libraries and ensure that
+  headers are self-contained and independent of the order in which they are
+  included.
+* The `layering_check` feature enforces that targets only include headers
+  provided by their direct dependencies. The default toolchain supports this
+  feature on Linux with `clang` as the compiler.
diff --git a/versions/9.1.0/docs/bazel-and-java.mdx b/versions/9.1.0/docs/bazel-and-java.mdx
new file mode 100644
index 00000000..9033045e
--- /dev/null
+++ b/versions/9.1.0/docs/bazel-and-java.mdx
@@ -0,0 +1,347 @@
+---
+title: 'Java and Bazel'
+---
+
+This page contains resources that help you use Bazel with Java projects. It
+links to a tutorial, build rules, and other information specific to building
+Java projects with Bazel.
+
+## Working with Bazel {#working-with-bazel}
+
+The following resources will help you work with Bazel on Java projects:
+
+*   [Tutorial: Building a Java Project](/versions/9.1.0/start/java)
+*   [Java rules](/versions/9.1.0/reference/be/java)
+
+## Migrating to Bazel {#migrating-to-bazel}
+
+If you currently build your Java projects with Maven, follow the steps in the
+migration guide to start building your Maven projects with Bazel:
+
+*   [Migrating from Maven to Bazel](/versions/9.1.0/migrate/maven)
+
+## Java versions {#java-versions}
+
+There are two relevant versions of Java that are set with configuration flags:
+
+*   the version of the source files in the repository
+*   the version of the Java runtime that is used to execute the code and to test
+    it
+
+### Configuring the version of the source code in your repository {#config-source-code}
+
+Without an additional configuration, Bazel assumes all Java source files in the
+repository are written in a single Java version. To specify the version of the
+sources in the repository add `build --java_language_version={ver}` to
+`.bazelrc` file, where `{ver}` is for example `11`. Bazel repository owners
+should set this flag so that Bazel and its users can reference the source code's
+Java version number. For more details, see
+[Java language version flag](/versions/9.1.0/docs/user-manual#java-language-version).
+
+### Configuring the JVM used to execute and test the code {#config-jvm}
+
+Bazel uses one JDK for compilation and another JVM to execute and test the code.
+
+By default Bazel compiles the code using a JDK it downloads and it executes and
+tests the code with the JVM installed on the local machine. Bazel searches for
+the JVM using `JAVA_HOME` or path.
+
+The resulting binaries are compatible with locally installed JVM in system
+libraries, which means the resulting binaries depend on what is installed on the
+machine.
+
+To configure the JVM used for execution and testing use `--java_runtime_version`
+flag. The default value is `local_jdk`.
+
+### Hermetic testing and compilation {#hermetic-testing}
+
+To create a hermetic compile, you can use command line flag
+`--java_runtime_version=remotejdk_11`. The code is compiled for, executed, and
+tested on the JVM downloaded from a remote repository. For more details, see
+[Java runtime version flag](/versions/9.1.0/docs/user-manual#java_runtime_version).
+
+### Configuring compilation and execution of build tools in Java {#config-build-tools-java}
+
+There is a second pair of JDK and JVM used to build and execute tools, which are
+used in the build process, but are not in the build results. That JDK and JVM
+are controlled using `--tool_java_language_version` and
+`--tool_java_runtime_version`. Default values are `11` and `remotejdk_11`,
+respectively.
+
+#### Compiling using locally installed JDK {#compile-using-jdk}
+
+Bazel by default compiles using remote JDK, because it is overriding JDK's
+internals. The compilation toolchains using locally installed JDK are configured,
+however not used.
+
+To compile using locally installed JDK, that is use the compilation toolchains
+for local JDK, use additional flag `--extra_toolchains=@local_jdk//:all`,
+however, mind that this may not work on JDK of arbitrary vendors.
+
+For more details, see
+[configuring Java toolchains](#config-java-toolchains).
+
+## Best practices {#best-practices}
+
+In addition to [general Bazel best practices](/versions/9.1.0/configure/best-practices), below are
+best practices specific to Java projects.
+
+### Directory structure {#directory-structure}
+
+Prefer Maven's standard directory layout (sources under `src/main/java`, tests
+under `src/test/java`).
+
+### BUILD files {#build-files}
+
+Follow these guidelines when creating your `BUILD` files:
+
+*   Use one `BUILD` file per directory containing Java sources, because this
+    improves build performance.
+
+*   Every `BUILD` file should contain one `java_library` rule that looks like
+    this:
+
+    ```python
+    java_library(
+        name = "directory-name",
+        srcs = glob(["*.java"]),
+        deps = [...],
+    )
+    ```
+
+*   The name of the library should be the name of the directory containing the
+    `BUILD` file. This makes the label of the library shorter, that is use
+    `"//package"` instead of `"//package:package"`.
+
+*   The sources should be a non-recursive [`glob`](/versions/9.1.0/reference/be/functions#glob) of
+    all Java files in the directory.
+
+*   Tests should be in a matching directory under `src/test` and depend on this
+    library.
+
+## Creating new rules for advanced Java builds {#rules-advanced-java-builds}
+
+**Note**: Creating new rules is for advanced build and test scenarios. You do
+not need it when getting started with Bazel.
+
+The following modules, configuration fragments, and providers will help you
+[extend Bazel's capabilities](/versions/9.1.0/extending/concepts) when building your Java
+projects:
+
+*   Main Java module: [`java_common`](/versions/9.1.0/rules/lib/toplevel/java_common)
+*   Main Java provider: [`JavaInfo`](/versions/9.1.0/rules/lib/providers/JavaInfo)
+*   Configuration fragment: [`java`](/versions/9.1.0/rules/lib/fragments/java)
+*   Other modules:
+
+    *   [`java_annotation_processing`](/versions/9.1.0/rules/lib/builtins/java_annotation_processing)
+    *   [`java_compilation_info`](/versions/9.1.0/rules/lib/providers/java_compilation_info)
+    *   [`java_output_jars`](/versions/9.1.0/rules/lib/providers/java_output_jars)
+    *   [`JavaRuntimeInfo`](/versions/9.1.0/rules/lib/providers/JavaRuntimeInfo)
+    *   [`JavaToolchainInfo`](/versions/9.1.0/rules/lib/providers/JavaToolchainInfo)
+
+## Configuring the Java toolchains {#config-java-toolchains}
+
+Bazel uses two types of Java toolchains:
+
+* execution, used to execute and test Java binaries, controlled with the
+  `--java_runtime_version` flag
+* compilation, used to compile Java sources, controlled with the
+  `--java_language_version` flag
+
+### Configuring additional execution toolchains {#config-execution-toolchains}
+
+Execution toolchain is the JVM, either local or from a repository, with some
+additional information about its version, operating system, and CPU
+architecture.
+
+Java execution toolchains may added using the `local_java_repository` or
+`remote_java_repository` repo rules in a module extension. Adding the rule makes
+the JVM available using a flag. When multiple definitions for the same operating
+system and CPU architecture are given, the first one is used.
+
+Example configuration of local JVM in MODULE.bazel:
+
+```python
+custom_jdk = use_extension("@rules_java//java:extensions.bzl", "java_repository")
+
+custom_jdk.local(
+  name = "additionaljdk",          # Can be used with --java_runtime_version=additionaljdk, --java_runtime_version=11 or --java_runtime_version=additionaljdk_11
+  version = "11",                  # Optional, if not set it is autodetected
+  java_home = "/usr/lib/jdk-15/",  # Path to directory containing bin/java
+)
+use_repo(custom_jdk, "additionaljdk")
+register_toolchains("@additionaljdk//:all")
+```
+
+Example configuration of remote JVM:
+
+```python
+custom_jdk = use_extension("@rules_java//java:extensions.bzl", "java_repository")
+
+custom_jdk.remote(
+  name = "openjdk_canary_linux_arm",
+  prefix = "openjdk_canary", # Can be used with --java_runtime_version=openjdk_canary_11
+  version = "11",            # or --java_runtime_version=11
+  target_compatible_with = [ # Specifies constraints this JVM is compatible with
+    "@platforms//cpu:arm",
+    "@platforms//os:linux",
+  ],
+  urls = ...,               # Other parameters are from http_repository rule.
+  sha256 = ...,
+  strip_prefix = ...
+)
+use_repo(custom_jdk, "openjdk_canary_linux_arm", "openjdk_canary_linux_arm_toolchain_config_repo")
+
+register_toolchains("@openjdk_canary_linux_arm_toolchain_config_repo//:all")
+```
+
+### Configuring additional compilation toolchains {#config-compilation-toolchains}
+
+Compilation toolchain is composed of JDK and multiple tools that Bazel uses
+during the compilation and that provides additional features, such as: Error
+Prone, strict Java dependencies, header compilation, Android desugaring,
+coverage instrumentation, and genclass handling for IDEs.
+
+JavaBuilder is a Bazel-bundled tool that executes compilation, and provides the
+aforementioned features. Actual compilation is executed using the internal
+compiler by the JDK. The JDK used for compilation is specified by `java_runtime`
+attribute of the toolchain.
+
+Bazel overrides some JDK internals. In case of JDK version > 9,
+`java.compiler` and `jdk.compiler` modules are patched using JDK's flag
+`--patch_module`. In case of JDK version 8, the Java compiler is patched using
+`-Xbootclasspath` flag.
+
+VanillaJavaBuilder is a second implementation of JavaBuilder,
+which does not modify JDK's internal compiler and does not have any of the
+additional features. VanillaJavaBuilder is not used by any of the built-in
+toolchains.
+
+In addition to JavaBuilder, Bazel uses several other tools during compilation.
+
+The `ijar` tool processes `jar` files to remove everything except call
+signatures. Resulting jars are called header jars. They are used to improve the
+compilation incrementality by only recompiling downstream dependents when the
+body of a function changes.
+
+The `singlejar` tool packs together multiple `jar` files into a single one.
+
+The `genclass` tool post-processes the output of a Java compilation, and produces
+a `jar` containing only the class files for sources that were generated by
+annotation processors.
+
+The `JacocoRunner` tool runs Jacoco over instrumented files and outputs results in
+LCOV format.
+
+The `TestRunner` tool executes JUnit 4 tests in a controlled environment.
+
+You can reconfigure the compilation by adding `default_java_toolchain` macro to
+a `BUILD` file and registering it either by adding `register_toolchains` rule to
+the `MODULE.bazel` file or by using
+[`--extra_toolchains`](/versions/9.1.0/docs/user-manual#extra-toolchains) flag.
+
+The toolchain is only used when the `source_version` attribute matches the
+value specified by `--java_language_version` flag.
+
+Example toolchain configuration:
+
+```python
+load(
+  "@rules_java//toolchains:default_java_toolchain.bzl",
+  "default_java_toolchain", "DEFAULT_TOOLCHAIN_CONFIGURATION", "BASE_JDK9_JVM_OPTS", "DEFAULT_JAVACOPTS"
+)
+
+default_java_toolchain(
+  name = "repository_default_toolchain",
+  configuration = DEFAULT_TOOLCHAIN_CONFIGURATION,        # One of predefined configurations
+                                                          # Other parameters are from java_toolchain rule:
+  java_runtime = "@rules_java//toolchains:remote_jdk11", # JDK to use for compilation and toolchain's tools execution
+  jvm_opts = BASE_JDK9_JVM_OPTS + ["--enable_preview"],   # Additional JDK options
+  javacopts = DEFAULT_JAVACOPTS + ["--enable_preview"],   # Additional javac options
+  source_version = "9",
+)
+```
+
+which can be used using `--extra_toolchains=//:repository_default_toolchain_definition`
+or by adding `register_toolchains("//:repository_default_toolchain_definition")`
+to the workpace.
+
+Predefined configurations:
+
+-   `DEFAULT_TOOLCHAIN_CONFIGURATION`: all features, supports JDK versions >= 9
+-   `VANILLA_TOOLCHAIN_CONFIGURATION`: no additional features, supports JDKs of
+    arbitrary vendors.
+-   `PREBUILT_TOOLCHAIN_CONFIGURATION`: same as default, but only use prebuilt
+    tools (`ijar`, `singlejar`)
+-   `NONPREBUILT_TOOLCHAIN_CONFIGURATION`: same as default, but all tools are
+    built from sources (this may be useful on operating system with different
+    libc)
+
+#### Configuring JVM and Java compiler flags {#config-jvm-flags}
+
+You may configure JVM and javac flags either with flags or with
+ `default_java_toolchain` attributes.
+
+The relevant flags are `--jvmopt`, `--host_jvmopt`, `--javacopt`,  and
+`--host_javacopt`.
+
+The relevant `default_java_toolchain` attributes are `javacopts`, `jvm_opts`,
+`javabuilder_jvm_opts`, and `turbine_jvm_opts`.
+
+#### Package specific Java compiler flags configuration {#package-java-compiler-flags}
+
+You can configure different Java compiler flags for specific source
+files using `package_configuration` attribute of `default_java_toolchain`.
+Please refer to the example below.
+
+```python
+load("@rules_java//toolchains:default_java_toolchain.bzl", "default_java_toolchain")
+
+# This is a convenience macro that inherits values from Bazel's default java_toolchain
+default_java_toolchain(
+    name = "toolchain",
+    package_configuration = [
+        ":error_prone",
+    ],
+    visibility = ["//visibility:public"],
+)
+
+# This associates a set of javac flags with a set of packages
+java_package_configuration(
+    name = "error_prone",
+    javacopts = [
+        "-Xep:MissingOverride:ERROR",
+    ],
+    packages = ["error_prone_packages"],
+)
+
+# This is a regular package_group, which is used to specify a set of packages to apply flags to
+package_group(
+    name = "error_prone_packages",
+    packages = [
+        "//foo/...",
+        "-//foo/bar/...", # this is an exclusion
+    ],
+)
+```
+
+#### Multiple versions of Java source code in a single repository {#java-source-single-repo}
+
+Bazel only supports compiling a single version of Java sources in a build.
+build. This means that when building a Java test or an application, all
+ dependencies are built against the same Java version.
+
+However, separate builds may be executed using different flags.
+
+To make the task of using different flags easier, sets of flags for a specific
+version may be grouped with `.bazelrc` configs":
+
+```python
+build:java8 --java_language_version=8
+build:java8 --java_runtime_version=local_jdk_8
+build:java11 --java_language_version=11
+build:java11 --java_runtime_version=remotejdk_11
+```
+
+These configs can be used with the `--config` flag, for example
+`bazel test --config=java11 //:java11_test`.
diff --git a/versions/9.1.0/docs/bazel-and-javascript.mdx b/versions/9.1.0/docs/bazel-and-javascript.mdx
new file mode 100644
index 00000000..f6e75a0b
--- /dev/null
+++ b/versions/9.1.0/docs/bazel-and-javascript.mdx
@@ -0,0 +1,22 @@
+---
+title: 'JavaScript and Bazel'
+---
+
+This page contains resources that help you use Bazel with JavaScript projects.
+It links to build rules and other information specific to building JavaScript
+with Bazel.
+
+The following resources will help you work with Bazel on JavaScript projects:
+
+*  [NodeJS toolchain](https://github.com/bazelbuild/rules_nodejs)
+*  [rules_js](https://github.com/aspect-build/rules_js) - Bazel rules for building JavaScript programs
+*  [rules_esbuild](https://github.com/aspect-build/rules_esbuild) - Bazel rules for [esbuild](https://esbuild.github.io) JS bundler
+*  [rules_terser](https://github.com/aspect-build/rules_terser) - Bazel rules for [Terser](https://terser.org) - a JavaScript minifier
+*  [rules_swc](https://github.com/aspect-build/rules_swc) - Bazel rules for [swc](https://swc.rs)
+*  [rules_ts](https://github.com/aspect-build/rules_ts) - Bazel rules for [TypeScript](http://typescriptlang.org)
+*  [rules_webpack](https://github.com/aspect-build/rules_webpack) - Bazel rules for [Webpack](https://webpack.js.org)
+*  [rules_rollup](https://github.com/aspect-build/rules_rollup) - Bazel rules for [Rollup](https://rollupjs.org) - a JavaScript bundler
+*  [rules_jest](https://github.com/aspect-build/rules_jest) - Bazel rules to run tests using [Jest](https://jestjs.io)
+*  [rules_jasmine](https://github.com/aspect-build/rules_jasmine) - Bazel rules to run tests using [Jasmine](https://jasmine.github.io/)
+*  [rules_cypress](https://github.com/aspect-build/rules_cypress) - Bazel rules to run tests using [Cypress](https://cypress.io)
+*  [rules_deno](https://github.com/aspect-build/rules_deno) - Bazel rules for [Deno](http://deno.land)
diff --git a/versions/9.1.0/docs/cc-toolchain-config-reference.mdx b/versions/9.1.0/docs/cc-toolchain-config-reference.mdx
new file mode 100644
index 00000000..5c6f3e29
--- /dev/null
+++ b/versions/9.1.0/docs/cc-toolchain-config-reference.mdx
@@ -0,0 +1,1150 @@
+---
+title: 'C++ Toolchain Configuration'
+---
+
+## Overview {:#overview}
+
+To invoke the compiler with the right options, Bazel needs some knowledge about
+the compiler internals, such as include directories and important flags.
+In other words, Bazel needs a simplified model of the compiler to understand its
+workings.
+
+Bazel needs to know the following:
+
+* Whether the compiler supports thinLTO, modules, dynamic linking, or PIC
+  (position independent code).
+* Paths to the required tools such as gcc, ld, ar, objcopy, and so on.
+* The built-in system include directories. Bazel needs these to validate that
+  all headers that were included in the source file were properly declared in
+  the `BUILD` file.
+* The default sysroot.
+* Which flags to use for compilation, linking, archiving.
+* Which flags to use for the supported compilation modes (opt, dbg, fastbuild).
+* Make variables specifically required by the compiler.
+
+If the compiler has support for multiple architectures, Bazel needs to configure
+them separately.
+
+[`CcToolchainConfigInfo`](/versions/9.1.0/rules/lib/providers/CcToolchainConfigInfo) is a provider that provides the necessary level of
+granularity for configuring the behavior of Bazel's C++ rules. By default,
+Bazel automatically configures `CcToolchainConfigInfo` for your build, but you
+have the option to configure it manually. For that, you need a Starlark rule
+that provides the `CcToolchainConfigInfo` and you need to point the
+[`toolchain_config`](/versions/9.1.0/reference/be/c-cpp#cc_toolchain.toolchain_config) attribute of the
+[`cc_toolchain`](/versions/9.1.0/reference/be/c-cpp#cc_toolchain) to your rule.
+You can create the `CcToolchainConfigInfo` by calling
+[`cc_common.create_cc_toolchain_config_info()`](/versions/9.1.0/rules/lib/toplevel/cc_common#create_cc_toolchain_config_info).
+You can find Starlark constructors for all structs you'll need in the process in
+[`@rules_cc//cc:cc_toolchain_config_lib.bzl`](https://github.com/bazelbuild/rules_cc/blob/master/cc/cc_toolchain_config_lib.bzl){: .external}.
+
+When a C++ target enters the analysis phase, Bazel selects the appropriate
+`cc_toolchain` target based on the `BUILD` file, and obtains the
+`CcToolchainConfigInfo` provider from the target specified in the
+`cc_toolchain.toolchain_config` attribute. The `cc_toolchain` target
+passes this information to the C++ target through a `CcToolchainProvider`.
+
+For example, a compile or link action, instantiated by a rule such as
+`cc_binary` or `cc_library`, needs the following information:
+
+*   The compiler or linker to use
+*   Command-line flags for the compiler/linker
+*   Configuration flags passed through the `--copt/--linkopt` options
+*   Environment variables
+*   Artifacts needed in the sandbox in which the action executes
+
+All of the above information except the artifacts required in the sandbox is
+specified in the Starlark target that the `cc_toolchain` points to.
+
+The artifacts to be shipped to the sandbox are declared in the `cc_toolchain`
+target. For example, with the `cc_toolchain.linker_files` attribute you can
+specify the linker binary and toolchain libraries to ship into the sandbox.
+
+## Toolchain selection {:#toolchain-selection}
+
+The toolchain selection logic operates as follows:
+
+1.  User specifies a `cc_toolchain_suite` target in the `BUILD` file and points
+    Bazel to the target using the
+    [`--crosstool_top` option](/versions/9.1.0/docs/user-manual#flag--crosstool_top).
+
+2.  The `cc_toolchain_suite` target references multiple toolchains. The
+    values of the `--cpu` and `--compiler` flags determine which of those
+    toolchains is selected, either based only on the `--cpu` flag value, or
+    based on a joint `--cpu | --compiler` value. The selection process is as
+    follows:
+
+  * If the `--compiler` option is specified, Bazel selects the
+        corresponding entry from the `cc_toolchain_suite.toolchains`
+        attribute with `--cpu | --compiler`. If Bazel does not find
+        a corresponding entry, it throws an error.
+
+  * If the `--compiler` option is not specified, Bazel selects
+    the corresponding entry from the `cc_toolchain_suite.toolchains`
+    attribute with just `--cpu`.
+
+  * If no flags are specified, Bazel inspects the host system and selects a
+    `--cpu` value based on its findings. See the
+    [inspection mechanism code](https://source.bazel.build/bazel/+/1b73bc37e184e71651eb631223dcce321ba16211:src/main/java/com/google/devtools/build/lib/analysis/config/AutoCpuConverter.java).
+
+Once a toolchain has been selected, corresponding `feature` and `action_config`
+objects in the Starlark rule govern the configuration of the build (that is,
+items described later). These messages allow the implementation of
+fully fledged C++ features in Bazel without modifying the
+Bazel binary. C++ rules support multiple unique actions documented in detail
+[in the Bazel source code](https://source.bazel.build/bazel/+/4f547a7ea86df80e4c76145ffdbb0c8b75ba3afa:tools/build_defs/cc/action_names.bzl).
+
+## Features {:#features}
+
+A feature is an entity that requires command-line flags, actions,
+constraints on the execution environment, or dependency alterations. A feature
+can be something as simple as allowing `BUILD` files to select configurations of
+flags, such as `treat_warnings_as_errors`, or interact with the C++ rules and
+include new compile actions and inputs to the compilation, such as
+`header_modules` or `thin_lto`.
+
+Ideally, `CcToolchainConfigInfo` contains a list of features, where each
+feature consists of one or more flag groups, each defining a list of flags
+that apply to specific Bazel actions.
+
+A feature is specified by name, which allows full decoupling of the Starlark
+rule configuration from Bazel releases. In other words, a Bazel release does not
+affect the behavior of `CcToolchainConfigInfo` configurations as long as those
+configurations do not require the use of new features.
+
+A feature is enabled in one of the following ways:
+
+*  The feature's `enabled` field is set to `true`.
+*  Bazel or the rule owner explicitly enable it.
+*  The user enables it through the `--feature` Bazel option or `features` rule
+   attribute.
+
+Features can have interdependencies, depend on command line flags, `BUILD` file
+settings, and other variables.
+
+### Feature relationships {:#feature-relationships}
+
+Dependencies are typically managed directly with Bazel, which simply enforces
+the requirements and manages conflicts intrinsic to the nature of the features
+defined in the build. The toolchain specification allows for more granular
+constraints for use directly within the Starlark rule that govern feature
+support and expansion. These are:
+
+
+  +  +  
+   
+   
+  
+  
+   
+   
+  
+  
+   
+   
+  
+  
+   
+   
+  
+  
+   
+   
+  
+



Constraint
+   Description
+   
requires = [
+   feature_set (features = [
+       'feature-name-1',
+       'feature-name-2'
+   ]),
+]

+   		Feature-level. The feature is supported only if the specified required
+       features are enabled. For example, when a feature is only supported in
+       certain build modes (opt, dbg, or
+       fastbuild). If `requires` contains multiple `feature_set`s
+       the feature is supported if any of the `feature_set`s is satisfied
+       (when all specified features are enabled).
+   
implies = ['feature']

+   
Feature-level. This feature implies the specified feature(s).
+       Enabling a feature also implicitly enables all features implied by it
+       (that is, it functions recursively).

+       
Also provides the ability to factor common subsets of functionality out of
+       a set of features, such as the common parts of sanitizers. Implied
+       features cannot be disabled.

+   
provides = ['feature']

+   
Feature-level. Indicates that this feature is one of several mutually
+       exclusive alternate features. For example, all of the sanitizers could
+       specify provides = ["sanitizer"].

+       
This improves error handling by listing the alternatives if the user asks
+       for two or more mutually exclusive features at once.

+   
with_features = [
+  with_feature_set(
+    features = ['feature-1'],
+    not_features = ['feature-2'],
+  ),
+]

+   		Flag set-level. A feature can specify multiple flag sets with multiple.
+     When with_features is specified, the flag set will only expand
+     to the build command if there is at least one with_feature_set
+     for which all of the features in the specified features set
+     are enabled, and all the features specified in not_features
+     set are disabled.
+     If with_features is not specified, the flag set will be
+     applied unconditionally for every action specified.
+   

+
+## Actions {:#actions}
+
+Actions provide the flexibility to modify the circumstances under
+which an action executes without assuming how the action will be run. An
+`action_config` specifies the tool binary that an action invokes, while a
+`feature` specifies the configuration (flags) that determine how that tool
+behaves when the action is invoked.
+
+[Features](#features) reference actions to signal which Bazel actions
+they affect since actions can modify the Bazel action graph. The
+`CcToolchainConfigInfo` provider contains actions that have flags and tools
+associated with them, such as `c++-compile`. Flags are assigned to each action
+by associating them with a feature.
+
+Each action name represents a single type of action performed by Bazel, such as
+compiling or linking. There is, however, a many-to-one relationship between
+actions and Bazel action types, where a Bazel action type refers to a Java class
+that implements an action (such as `CppCompileAction`). In particular, the
+"assembler actions" and "compiler actions" in the table below are
+`CppCompileAction`, while the link actions are `CppLinkAction`.
+
+### Assembler actions {:#assembler-actions}
+
+
+  +  +  
+   
+   
+  
+  
+   
+   
+  
+  
+   
+   
+  
+



Action
+   Description
+   
preprocess-assemble
+   Assemble with preprocessing. Typically for .S files.
+   
assemble
+   Assemble without preprocessing. Typically for .s files.
+   

+
+### Compiler actions {:#compiler-actions}
+
+
+  +  +  
+   
+   
+  
+  
+   
+   
+  
+  
+   
+   
+  
+  
+   
+   
+  
+  
+   
+   
+  
+



Action
+   Description
+   
cc-flags-make-variable
+   Propagates CC_FLAGS to genrules.
+   
c-compile
+   Compile as C.
+   
c++-compile
+   Compile as C++.
+   
c++-header-parsing
+   Run the compiler's parser on a header file to ensure that the header is
+     self-contained, as it will otherwise produce compilation errors. Applies
+     only to toolchains that support modules.
+   

+
+### Link actions {:#link-actions}
+
+
+  +  +  
+   
+   
+  
+  
+   
+   
+  
+  
+   
+   
+  
+  
+   
+   
+  
+



Action
+   Description
+   
c++-link-dynamic-library
+   Link a shared library containing all of its dependencies.
+   
c++-link-nodeps-dynamic-library
+   Link a shared library only containing cc_library sources.
+   
c++-link-executable
+   Link a final ready-to-run library.
+   

+
+### AR actions {:#ar-actions}
+
+AR actions assemble object files into archive libraries (`.a` files) via `ar`
+and encode some semantics into the name.
+
+
+  +  +  
+   
+   
+  
+  
+   
+   
+  
+



Action
+   Description
+   
c++-link-static-library
+   Create a static library (archive).
+   

+
+### LTO actions {:#lto-actions}
+
+
+  +  +  
+   
+   
+  
+  
+   
+   
+  
+  
+   
+   
+  
+



Action
+   Description
+   
lto-backend
+   ThinLTO action compiling bitcodes into native objects.
+   
lto-index
+   ThinLTO action generating global index.
+   

+
+## Using action_config {:#using-action-config}
+
+The `action_config` is a Starlark struct that describes a Bazel
+action by specifying the tool (binary) to invoke during the action and sets of
+flags, defined by features. These flags apply constraints to the action's
+execution.
+
+The `action_config()` constructor has the following parameters:
+
+
+  +  +  
+   
+   
+  
+  
+   
+    
+  
+  
+   
+   
+  
+  
+   
+   
+  
+  
+   
+   
+  
+



Attribute
+   Description
+   
action_name
+   The Bazel action to which this action corresponds.
+        Bazel uses this attribute to discover per-action tool and execution
+        requirements.
+   
tools
+   The executable to invoke. The tool applied to the action will be the
+       first tool in the list with a feature set that matches the feature
+       configuration. Default value must be provided.
+   
flag_sets
+   A list of flags that applies to a group of actions. Same as for a
+       feature.
+   
env_sets
+   A list of environment constraints that applies to a group of actions.
+       Same as for a feature.
+   

+
+An `action_config` can require and imply other features and
+action_configs as dictated by the
+[feature relationships](#feature-relationships) described earlier. This behavior
+is similar to that of a feature.
+
+The last two attributes are redundant against the corresponding attributes on
+features and are included because some Bazel actions require certain flags or
+environment variables and the goal is to avoid unnecessary `action_config`+`feature`
+pairs. Typically, sharing a single feature across multiple `action_config`s is
+preferred.
+
+You can not define more than one `action_config` with the same `action_name`
+within the same toolchain. This prevents ambiguity in tool paths
+and enforces the intention behind `action_config` - that an action's properties
+are clearly described in a single place in the toolchain.
+
+### Using tool constructor {:#using-tool-constructor}
+
+An`action_config` can specify a set of tools via its `tools` parameter.
+The `tool()` constructor takes in the following parameters:
+
+
+  +  +  
+   
+   
+  
+  
+   
+   
+  
+  
+   
+   
+  
+



Field
+   Description
+   
path
+   Path to the tool in question (relative to the current location).
+   
with_features
+   A list of feature sets out of which at least one must be satisfied
+       for this tool to apply.
+   

+
+For a given `action_config`, only a single `tool` applies
+its tool path and execution requirements to the Bazel action. A tool is selected
+by iterating through the `tools` attribute on an `action_config` until a tool
+with a `with_feature` set matching the feature configuration is found
+(see [Feature relationships](#feature-relationships) earlier on this page
+for more information). You should end your tool lists with a default
+tool that corresponds to an empty feature configuration.
+
+### Example usage {:#example-usage}
+
+Features and actions can be used together to implement Bazel actions
+with diverse cross-platform semantics. For example, debug symbol generation on
+macOS requires generating symbols in the compile action, then invoking a
+specialized tool during the link action to create  compressed dsym archive, and
+then decompressing that archive to produce the application bundle and `.plist`
+files consumable by Xcode.
+
+With Bazel, this process can instead be implemented as follows, with
+`unbundle-debuginfo` being a Bazel action:
+
+    load("@rules_cc//cc:defs.bzl", "ACTION_NAMES")
+
+    action_configs = [
+        action_config (
+            action_name = ACTION_NAMES.cpp_link_executable,
+            tools = [
+                tool(
+                    with_features = [
+                        with_feature(features=["generate-debug-symbols"]),
+                    ],
+                    path = "toolchain/mac/ld-with-dsym-packaging",
+                ),
+                tool (path = "toolchain/mac/ld"),
+            ],
+        ),
+    ]
+
+    features = [
+        feature(
+            name = "generate-debug-symbols",
+            flag_sets = [
+                flag_set (
+                    actions = [
+                        ACTION_NAMES.c_compile,
+                        ACTION_NAMES.cpp_compile
+                    ],
+                    flag_groups = [
+                        flag_group(
+                            flags = ["-g"],
+                        ),
+                    ],
+                )
+            ],
+            implies = ["unbundle-debuginfo"],
+       ),
+    ]
+
+This same feature can be implemented entirely differently for Linux, which uses
+`fission`, or for Windows, which produces `.pdb` files. For example, the
+implementation for `fission`-based debug symbol generation might look as
+follows:
+
+    load("@rules_cc//cc:defs.bzl", "ACTION_NAMES")
+
+    action_configs = [
+        action_config (
+            name = ACTION_NAMES.cpp_compile,
+            tools = [
+                tool(
+                    path = "toolchain/bin/gcc",
+                ),
+            ],
+        ),
+    ]
+
+    features = [
+        feature (
+            name = "generate-debug-symbols",
+            requires = [with_feature_set(features = ["dbg"])],
+            flag_sets = [
+                flag_set(
+                    actions = [ACTION_NAMES.cpp_compile],
+                    flag_groups = [
+                        flag_group(
+                            flags = ["-gsplit-dwarf"],
+                        ),
+                    ],
+                ),
+                flag_set(
+                    actions = [ACTION_NAMES.cpp_link_executable],
+                    flag_groups = [
+                        flag_group(
+                            flags = ["-Wl", "--gdb-index"],
+                        ),
+                    ],
+                ),
+          ],
+        ),
+    ]
+
+### Flag groups {:#flag-groups}
+
+`CcToolchainConfigInfo` allows you to bundle flags into groups that serve a
+specific purpose. You can specify a flag within using pre-defined variables
+within the flag value, which the compiler expands when adding the flag to the
+build command. For example:
+
+    flag_group (
+        flags = ["%{output_execpath}"],
+    )
+
+In this case, the contents of the flag will be replaced by the output file path
+of the action.
+
+Flag groups are expanded to the build command in the order in which they appear
+in the list, top-to-bottom, left-to-right.
+
+For flags that need to repeat with different values when added to the build
+command, the flag group can iterate variables of type `list`. For example, the
+variable `include_path` of type `list`:
+
+    flag_group (
+        iterate_over = "include_paths",
+        flags = ["-I%{include_paths}"],
+    )
+
+expands to `-I` for each path element in the `include_paths` list. All
+flags (or `flag_group`s) in the body of a flag group declaration are expanded as
+a unit. For example:
+
+    flag_group (
+        iterate_over = "include_paths",
+        flags = ["-I", "%{include_paths}"],
+    )
+
+expands to `-I ` for each path element in the `include_paths` list.
+
+A variable can repeat multiple times. For example:
+
+    flag_group (
+        iterate_over = "include_paths",
+        flags = ["-iprefix=%{include_paths}", "-isystem=%{include_paths}"],
+    )
+
+expands to:
+
+    -iprefix= -isystem= -iprefix= -isystem=
+
+Variables can correspond to structures accessible using dot-notation. For
+example:
+
+    flag_group (
+        flags = ["-l%{libraries_to_link.name}"],
+    )
+
+Structures can be nested and may also contain sequences. To prevent name clashes
+and to be explicit, you must specify the full path through the fields. For
+example:
+
+    flag_group (
+        iterate_over = "libraries_to_link",
+        flag_groups = [
+            flag_group (
+                iterate_over = "libraries_to_link.shared_libraries",
+                flags = ["-l%{libraries_to_link.shared_libraries.name}"],
+            ),
+        ],
+    )
+
+### Conditional expansion {:#conditional-expansion}
+
+Flag groups support conditional expansion based on the presence of a particular
+variable or its field using the `expand_if_available`, `expand_if_not_available`,
+`expand_if_true`, `expand_if_false`, or `expand_if_equal` attributes. For example:
+
+    flag_group (
+        iterate_over = "libraries_to_link",
+        flag_groups = [
+            flag_group (
+                iterate_over = "libraries_to_link.shared_libraries",
+                flag_groups = [
+                    flag_group (
+                        expand_if_available = "libraries_to_link.shared_libraries.is_whole_archive",
+                        flags = ["--whole_archive"],
+                    ),
+                    flag_group (
+                        flags = ["-l%{libraries_to_link.shared_libraries.name}"],
+                    ),
+                    flag_group (
+                        expand_if_available = "libraries_to_link.shared_libraries.is_whole_archive",
+                        flags = ["--no_whole_archive"],
+                    ),
+                ],
+            ),
+        ],
+    )
+
+Note: The `--whole_archive` and `--no_whole_archive` options are added to
+the build command only when a currently iterated library has an
+`is_whole_archive` field.
+
+## CcToolchainConfigInfo reference {:#cctoolchainconfiginfo-reference}
+
+This section provides a reference of build variables, features, and other
+information required to successfully configure C++ rules.
+
+### CcToolchainConfigInfo build variables {:#cctoolchainconfiginfo-build-variables}
+
+The following is a reference of `CcToolchainConfigInfo` build variables.
+
+Note: The **Action** column indicates the relevant action type, if applicable.
+
+
+  
+   
+   
+   
+  
+  
+   
+   
+   
+  
+  
+   
+   
+   
+  
+  
+   
+   
+   
+  
+  
+   
+   
+   
+  
+  
+   
+   
+   
+  
+  
+   
+   
+   
+  
+  
+   
+   
+   
+  
+  
+   
+   
+   
+  
+  
+   
+   
+   
+  
+  
+   
+   
+   
+  
+  
+   
+   
+   
+  
+  
+   
+   
+   
+  
+  
+   
+   
+   
+  
+  
+   
+   
+   
+  
+  
+   
+   
+   
+  
+  
+   
+   
+   
+  
+  
+   
+   
+   
+  
+  
+   
+   
+   
+  
+  
+   
+   
+   
+  
+  
+   
+   
+   
+  
+  
+   
+   
+   
+  
+  
+   
+   
+   
+  
+  
+   
+   
+   
+  
+  
+   
+   
+   
+  
+  
+   
+   
+   
+  
+  
+   
+   
+   
+  
+  
+   
+   
+   
+  
+  
+   
+   
+   
+  
+  
+   
+   
+   
+  
+  
+   
+   
+   
+  
+  
+   
+   
+   
+  
+  
+   
+   
+   
+  
+  
+   
+   
+   
+  
+  
+   
+   
+   
+  
+  
+   
+   
+   
+  
+  
+   
+   
+   
+  
+  
+   
+   
+   
+  
+  
+   
+   
+   
+  
+  
+   
+   
+   
+  
+  
+   
+   
+   
+  
+
Variable
+   Action
+   Description
+   
source_file
+   compileSource file to compile.
+   
input_file
+   stripArtifact to strip.
+   
output_file
+   compile, stripCompilation output.
+   
output_assembly_file
+   compileEmitted assembly file. Applies only when the
+       compile action emits assembly text, typically when using the
+       --save_temps flag. The contents are the same as for
+       output_file.
+   
output_preprocess_file
+   compilePreprocessed output. Applies only to compile
+       actions that only preprocess the source files, typically when using the
+     --save_temps flag. The contents are the same as for
+     output_file.
+   
includes
+   compileSequence of files the compiler must
+       unconditionally include in the compiled source.
+   
include_paths
+   compileSequence directories in which the compiler
+       searches for headers included using #include<foo.h>
+       and #include "foo.h".
+   
quote_include_paths
+   compileSequence of -iquote includes -
+       directories in which the compiler searches for headers included using
+       #include "foo.h".
+   
system_include_paths
+   compileSequence of -isystem includes -
+       directories in which the compiler searches for headers included using
+       #include <foo.h>.
+   
dependency_file
+   compileThe .d dependency file generated by the compiler.
+   
preprocessor_defines
+   compileSequence of defines, such as --DDEBUG.
+   
pic
+   compileCompiles the output as position-independent code.
+   
gcov_gcno_file
+   compileThe gcov coverage file.
+   
per_object_debug_info_file
+   compileThe per-object debug info (.dwp) file.
+   
stripopts
+   stripSequence of stripopts.
+   
legacy_compile_flags
+   compileSequence of flags from legacy
+       CROSSTOOL fields such as compiler_flag,
+       optional_compiler_flag, cxx_flag, and
+       optional_cxx_flag.
+   
user_compile_flags
+   compileSequence of flags from either the
+       copt rule attribute or the --copt,
+       --cxxopt, and --conlyopt flags.
+   
unfiltered_compile_flags
+   compileSequence of flags from the
+     unfiltered_cxx_flag legacy CROSSTOOL field or the
+       unfiltered_compile_flags feature. These are not filtered by
+       the nocopts rule attribute.
+   
sysroot
+   The sysroot.
+   
runtime_library_search_directories
+   linkEntries in the linker runtime search path (usually
+       set with the -rpath flag).
+   
library_search_directories
+   linkEntries in the linker search path (usually set with
+       the -L flag).
+   
libraries_to_link
+   linkFlags providing files to link as inputs in the linker invocation.
+   
def_file_path
+   linkLocation of def file used on Windows with MSVC.
+   
linker_param_file
+   linkLocation of linker param file created by bazel to
+       overcome command line length limit.
+   
output_execpath
+   linkExecpath of the output of the linker.
+   
generate_interface_library
+   link"yes" or "no" depending on whether interface library should
+       be generated.
+   
interface_library_builder_path
+   linkPath to the interface library builder tool.
+   
interface_library_input_path
+   linkInput for the interface library ifso builder tool.
+   
interface_library_output_path
+   linkPath where to generate interface library using the ifso builder tool.
+   
legacy_link_flags
+   linkLinker flags coming from the legacy CROSSTOOL fields.
+   
user_link_flags
+   linkLinker flags coming from the --linkopt
+       or linkopts attribute.
+   
linkstamp_paths
+   linkA build variable giving linkstamp paths.
+   
force_pic
+   linkPresence of this variable indicates that PIC/PIE code should
+     be generated (Bazel option `--force_pic` was passed).
+   
strip_debug_symbols
+   linkPresence of this variable indicates that the debug
+       symbols should be stripped.
+   
is_cc_test
+   linkTruthy when current action is a cc_test
+       linking action, false otherwise.
+   
is_using_fission
+   compile, linkPresence of this variable indicates that fission (per-object debug info)
+     is activated. Debug info will be in .dwo files instead
+       of .o files and the compiler and linker need to know this.
+   
fdo_instrument_path
+   compile, link Path to the directory that stores FDO instrumentation profile.
+   
fdo_profile_path
+   compile Path to FDO profile.
+   
fdo_prefetch_hints_path
+   compile Path to the cache prefetch profile.
+   
cs_fdo_instrument_path
+   compile, link Path to the directory that stores context sensitive FDO
+        instrumentation profile.
+   

+
+### Well-known features {:#wellknown-features}
+
+The following is a reference of features and their activation
+conditions.
+
+
+  +  +  
+   
+   
+  
+  
+   
+   
+  
+  
+   
+   
+  
+  
+   
+    
+  
+  
+   
+   
+  
+  
+   
+   
+  
+  
+   
+   
+  
+  
+   
+   
+  
+  
+   
+   
+  
+  
+    
+    
+  
+  
+     
+     
+    
+  
+     
+     
+    
+



Feature
+   Documentation
+   
opt | dbg | fastbuild
+   Enabled by default based on compilation mode.
+   
static_linking_mode | dynamic_linking_mode
+   Enabled by default based on linking mode.
+   
per_object_debug_info
+   Enabled if the supports_fission feature is specified and
+        enabled and the current compilation mode is specified in the
+        --fission flag.
+   
supports_start_end_lib
+   If enabled (and the option --start_end_lib is set), Bazel
+     will not link against static libraries but instead use the
+     --start-lib/--end-lib linker options to link against objects
+     directly. This speeds up the build since Bazel doesn't have to build
+     static libraries.
+   
supports_interface_shared_libraries
+   If enabled (and the option --interface_shared_objects is
+     set), Bazel will link targets that have linkstatic set to
+     False (cc_tests by default) against interface shared
+     libraries. This makes incremental relinking faster.
+   
supports_dynamic_linker
+   If enabled, C++ rules will know the toolchain can produce shared
+     libraries.
+   
static_link_cpp_runtimes
+   If enabled, Bazel will link the C++ runtime statically in static linking
+     mode and dynamically in dynamic linking mode. Artifacts
+     specified in the cc_toolchain.static_runtime_lib or
+     cc_toolchain.dynamic_runtime_lib attribute (depending on the
+     linking mode) will be added to the linking actions.
+   
supports_pic
+   If enabled, toolchain will know to use PIC objects for dynamic libraries.
+     The `pic` variable is present whenever PIC compilation is needed. If not enabled
+     by default, and `--force_pic` is passed, Bazel will request `supports_pic` and
+     validate that the feature is enabled. If the feature is missing, or couldn't
+      be enabled, `--force_pic` cannot be used.
+   

+      static_linking_mode | dynamic_linking_mode
+    Enabled by default based on linking mode.
no_legacy_features
+     
+       Prevents Bazel from adding legacy features to
+       the C++ configuration when present. See the complete list of
+       features below.
+     
shorten_virtual_includes
+     
+       If enabled, virtual include header files are linked under bin/_virtual_includes/<hash of target path> instead of bin/<target package path>/_virtual_includes/<target name>. Useful on Windows to avoid long path issue with MSVC.
+     

+
+#### Legacy features patching logic {:#legacy-features-patching-logic}
+
+

+  Bazel applies the following changes to the toolchain's features for backwards
+  compatibility:
+
+  
    
+    
  • Moves legacy_compile_flags feature to the top of the toolchain
    • 
+    
  • Moves default_compile_flags feature to the top of the toolchain
    • 
+    
  • Adds dependency_file (if not present) feature to the top of the toolchain
    • 
+    
  • Adds pic (if not present) feature to the top of the toolchain
    • 
+    
  • Adds per_object_debug_info (if not present) feature to the top of the toolchain
    • 
+    
  • Adds preprocessor_defines (if not present) feature to the top of the toolchain
    • 
+    
  • Adds includes (if not present) feature to the top of the toolchain
    • 
+    
  • Adds include_paths (if not present) feature to the top of the toolchain
    • 
+    
  • Adds fdo_instrument (if not present) feature to the top of the toolchain
    • 
+    
  • Adds fdo_optimize (if not present) feature to the top of the toolchain
    • 
+    
  • Adds cs_fdo_instrument (if not present) feature to the top of the toolchain
    • 
+    
  • Adds cs_fdo_optimize (if not present) feature to the top of the toolchain
    • 
+    
  • Adds fdo_prefetch_hints (if not present) feature to the top of the toolchain
    • 
+    
  • Adds autofdo (if not present) feature to the top of the toolchain
    • 
+    
  • Adds build_interface_libraries (if not present) feature to the top of the toolchain
    • 
+    
  • Adds dynamic_library_linker_tool (if not present) feature to the top of the toolchain
    • 
+    
  • Adds shared_flag (if not present) feature to the top of the toolchain
    • 
+    
  • Adds linkstamps (if not present) feature to the top of the toolchain
    • 
+    
  • Adds output_execpath_flags (if not present) feature to the top of the toolchain
    • 
+    
  • Adds runtime_library_search_directories (if not present) feature to the top of the toolchain
    • 
+    
  • Adds library_search_directories (if not present) feature to the top of the toolchain
    • 
+    
  • Adds archiver_flags (if not present) feature to the top of the toolchain
    • 
+    
  • Adds libraries_to_link (if not present) feature to the top of the toolchain
    • 
+    
  • Adds force_pic_flags (if not present) feature to the top of the toolchain
    • 
+    
  • Adds user_link_flags (if not present) feature to the top of the toolchain
    • 
+    
  • Adds legacy_link_flags (if not present) feature to the top of the toolchain
    • 
+    
  • Adds static_libgcc (if not present) feature to the top of the toolchain
    • 
+    
  • Adds fission_support (if not present) feature to the top of the toolchain
    • 
+    
  • Adds strip_debug_symbols (if not present) feature to the top of the toolchain
    • 
+    
  • Adds coverage (if not present) feature to the top of the toolchain
    • 
+    
  • Adds llvm_coverage_map_format (if not present) feature to the top of the toolchain
    • 
+    
  • Adds gcc_coverage_map_format (if not present) feature to the top of the toolchain
    • 
+    
  • Adds fully_static_link (if not present) feature to the bottom of the toolchain
    • 
+    
  • Adds user_compile_flags (if not present) feature to the bottom of the toolchain
    • 
+    
  • Adds sysroot (if not present) feature to the bottom of the toolchain
    • 
+    
  • Adds unfiltered_compile_flags (if not present) feature to the bottom of the toolchain
    • 
+    
  • Adds linker_param_file (if not present) feature to the bottom of the toolchain
    • 
+    
  • Adds compiler_input_flags (if not present) feature to the bottom of the toolchain
    • 
+    
  • Adds compiler_output_flags (if not present) feature to the bottom of the toolchain
    • 
+  

+

+
+This is a long list of features. The plan is to get rid of them once
+[Crosstool in Starlark](https://github.com/bazelbuild/bazel/issues/5380){: .external} is
+done. For the curious reader see the implementation in
+[CppActionConfigs](https://source.bazel.build/bazel/+/master:src/main/java/com/google/devtools/build/lib/rules/cpp/CppActionConfigs.java?q=cppactionconfigs&ss=bazel),
+and for production toolchains consider adding `no_legacy_features` to make
+the toolchain more standalone.
+
diff --git a/versions/9.1.0/docs/configurable-attributes.mdx b/versions/9.1.0/docs/configurable-attributes.mdx
new file mode 100644
index 00000000..c1400eca
--- /dev/null
+++ b/versions/9.1.0/docs/configurable-attributes.mdx
@@ -0,0 +1,1095 @@
+---
+title: 'Configurable Build Attributes'
+---
+
+**_Configurable attributes_**, commonly known as [`select()`](/versions/9.1.0//reference/be/functions#select), is a Bazel feature that lets users toggle the values
+of build rule attributes at the command line.
+
+This can be used, for example, for a multiplatform library that automatically
+chooses the appropriate implementation for the architecture, or for a
+feature-configurable binary that can be customized at build time.
+
+## Example {#configurable-build-example}
+
+```python
+# myapp/BUILD
+
+cc_binary(
+    name = "mybinary",
+    srcs = ["main.cc"],
+    deps = select({
+        ":arm_build": [":arm_lib"],
+        ":x86_debug_build": [":x86_dev_lib"],
+        "//conditions:default": [":generic_lib"],
+    }),
+)
+
+config_setting(
+    name = "arm_build",
+    values = {"cpu": "arm"},
+)
+
+config_setting(
+    name = "x86_debug_build",
+    values = {
+        "cpu": "x86",
+        "compilation_mode": "dbg",
+    },
+)
+```
+
+This declares a `cc_binary` that "chooses" its deps based on the flags at the
+command line. Specifically, `deps` becomes:
+
+
+  
+    
+    
+  
+  
+    
+    
+  
+  
+    
+    
+  
+  
+    
+    
+  
+  
+    
+    
+  
+
Commanddeps =
bazel build //myapp:mybinary --cpu=arm[":arm_lib"]
bazel build //myapp:mybinary -c dbg --cpu=x86[":x86_dev_lib"]
bazel build //myapp:mybinary --cpu=ppc[":generic_lib"]
bazel build //myapp:mybinary -c dbg --cpu=ppc[":generic_lib"]

+
+`select()` serves as a placeholder for a value that will be chosen based on
+*configuration conditions*, which are labels referencing [`config_setting`](/versions/9.1.0/reference/be/general#config_setting)
+targets. By using `select()` in a configurable attribute, the attribute
+effectively adopts different values when different conditions hold.
+
+Matches must be unambiguous: if multiple conditions match then either:
+
+*  They all resolve to the same value. For example, when running on linux x86, this is unambiguous
+   `{"@platforms//os:linux": "Hello", "@platforms//cpu:x86_64": "Hello"}` because both branches resolve to "hello".
+*  One's `values` is a strict superset of all others'. For example, `values = {"cpu": "x86", "compilation_mode": "dbg"}`
+   is an unambiguous specialization of `values = {"cpu": "x86"}`.
+
+The built-in condition [`//conditions:default`](#default-condition) automatically matches when
+nothing else does.
+
+While this example uses `deps`, `select()` works just as well on `srcs`,
+`resources`, `cmd`, and most other attributes. Only a small number of attributes
+are *non-configurable*, and these are clearly annotated. For example,
+`config_setting`'s own
+[`values`](/versions/9.1.0/reference/be/general#config_setting.values) attribute is non-configurable.
+
+## `select()` and dependencies {#select-and-dependencies}
+
+Certain attributes change the build parameters for all transitive dependencies
+under a target. For example, `genrule`'s `tools` changes `--cpu` to the CPU of
+the machine running Bazel (which, thanks to cross-compilation, may be different
+than the CPU the target is built for). This is known as a
+[configuration transition](/versions/9.1.0/reference/glossary#transition).
+
+Given
+
+```python
+#myapp/BUILD
+
+config_setting(
+    name = "arm_cpu",
+    values = {"cpu": "arm"},
+)
+
+config_setting(
+    name = "x86_cpu",
+    values = {"cpu": "x86"},
+)
+
+genrule(
+    name = "my_genrule",
+    srcs = select({
+        ":arm_cpu": ["g_arm.src"],
+        ":x86_cpu": ["g_x86.src"],
+    }),
+    tools = select({
+        ":arm_cpu": [":tool1"],
+        ":x86_cpu": [":tool2"],
+    }),
+)
+
+cc_binary(
+    name = "tool1",
+    srcs = select({
+        ":arm_cpu": ["armtool.cc"],
+        ":x86_cpu": ["x86tool.cc"],
+    }),
+)
+```
+
+running
+
+```sh
+$ bazel build //myapp:my_genrule --cpu=arm
+```
+
+on an `x86` developer machine binds the build to `g_arm.src`, `tool1`, and
+`x86tool.cc`. Both of the `select`s attached to `my_genrule` use `my_genrule`'s
+build parameters, which include `--cpu=arm`. The `tools` attribute changes
+`--cpu` to `x86` for `tool1` and its transitive dependencies. The `select` on
+`tool1` uses `tool1`'s build parameters, which include `--cpu=x86`.
+
+## Configuration conditions {#configuration-conditions}
+
+Each key in a configurable attribute is a label reference to a
+[`config_setting`](/versions/9.1.0/reference/be/general#config_setting) or
+[`constraint_value`](/versions/9.1.0/reference/be/platforms-and-toolchains#constraint_value).
+
+`config_setting` is just a collection of
+expected command line flag settings. By encapsulating these in a target, it's
+easy to maintain "standard" conditions users can reference from multiple places.
+
+`constraint_value` provides support for [multi-platform behavior](#platforms).
+
+### Built-in flags {#built-in-flags}
+
+Flags like `--cpu` are built into Bazel: the build tool natively understands
+them for all builds in all projects. These are specified with
+[`config_setting`](/versions/9.1.0/reference/be/general#config_setting)'s
+[`values`](/versions/9.1.0/reference/be/general#config_setting.values) attribute:
+
+```python
+config_setting(
+    name = "meaningful_condition_name",
+    values = {
+        "flag1": "value1",
+        "flag2": "value2",
+        ...
+    },
+)
+```
+
+`flagN` is a flag name (without `--`, so `"cpu"` instead of `"--cpu"`). `valueN`
+is the expected value for that flag. `:meaningful_condition_name` matches if
+*every* entry in `values` matches. Order is irrelevant.
+
+`valueN` is parsed as if it was set on the command line. This means:
+
+*  `values = { "compilation_mode": "opt" }` matches `bazel build -c opt`
+*  `values = { "force_pic": "true" }` matches `bazel build --force_pic=1`
+*  `values = { "force_pic": "0" }` matches `bazel build --noforce_pic`
+
+`config_setting` only supports flags that affect target behavior. For example,
+[`--show_progress`](/versions/9.1.0/docs/user-manual#show-progress) isn't allowed because
+it only affects how Bazel reports progress to the user. Targets can't use that
+flag to construct their results. The exact set of supported flags isn't
+documented. In practice, most flags that "make sense" work.
+
+### Custom flags {#custom-flags}
+
+You can model your own project-specific flags with
+[Starlark build settings][BuildSettings]. Unlike built-in flags, these are
+defined as build targets, so Bazel references them with target labels.
+
+These are triggered with [`config_setting`](/versions/9.1.0/reference/be/general#config_setting)'s
+[`flag_values`](/versions/9.1.0/reference/be/general#config_setting.flag_values)
+attribute:
+
+```python
+config_setting(
+    name = "meaningful_condition_name",
+    flag_values = {
+        "//myflags:flag1": "value1",
+        "//myflags:flag2": "value2",
+        ...
+    },
+)
+```
+
+Behavior is the same as for [built-in flags](#built-in-flags). See [here](https://github.com/bazelbuild/examples/tree/HEAD/configurations/select_on_build_setting)
+for a working example.
+
+[`--define`](/versions/9.1.0/reference/command-line-reference#flag--define)
+is an alternative legacy syntax for custom flags (for example
+`--define foo=bar`). This can be expressed either in the
+[values](/versions/9.1.0/reference/be/general#config_setting.values) attribute
+(`values = {"define": "foo=bar"}`) or the
+[define_values](/versions/9.1.0/reference/be/general#config_setting.define_values) attribute
+(`define_values = {"foo": "bar"}`). `--define` is only supported for backwards
+compatibility. Prefer Starlark build settings whenever possible.
+
+`values`, `flag_values`, and `define_values` evaluate independently. The
+`config_setting` matches if all values across all of them match.
+
+## The default condition {#default-condition}
+
+The built-in condition `//conditions:default` matches when no other condition
+matches.
+
+Because of the "exactly one match" rule, a configurable attribute with no match
+and no default condition emits a `"no matching conditions"` error. This can
+protect against silent failures from unexpected settings:
+
+```python
+# myapp/BUILD
+
+config_setting(
+    name = "x86_cpu",
+    values = {"cpu": "x86"},
+)
+
+cc_library(
+    name = "x86_only_lib",
+    srcs = select({
+        ":x86_cpu": ["lib.cc"],
+    }),
+)
+```
+
+```sh
+$ bazel build //myapp:x86_only_lib --cpu=arm
+ERROR: Configurable attribute "srcs" doesn't match this configuration (would
+a default condition help?).
+Conditions checked:
+  //myapp:x86_cpu
+```
+
+For even clearer errors, you can set custom messages with `select()`'s
+[`no_match_error`](#custom-error-messages) attribute.
+
+## Platforms {#platforms}
+
+While the ability to specify multiple flags on the command line provides
+flexibility, it can also be burdensome to individually set each one every time
+you want to build a target.
+   [Platforms](/versions/9.1.0/extending/platforms)
+let you consolidate these into simple bundles.
+
+```python
+# myapp/BUILD
+
+sh_binary(
+    name = "my_rocks",
+    srcs = select({
+        ":basalt": ["pyroxene.sh"],
+        ":marble": ["calcite.sh"],
+        "//conditions:default": ["feldspar.sh"],
+    }),
+)
+
+config_setting(
+    name = "basalt",
+    constraint_values = [
+        ":black",
+        ":igneous",
+    ],
+)
+
+config_setting(
+    name = "marble",
+    constraint_values = [
+        ":white",
+        ":metamorphic",
+    ],
+)
+
+# constraint_setting acts as an enum type, and constraint_value as an enum value.
+constraint_setting(name = "color")
+constraint_value(name = "black", constraint_setting = "color")
+constraint_value(name = "white", constraint_setting = "color")
+constraint_setting(name = "texture")
+constraint_value(name = "smooth", constraint_setting = "texture")
+constraint_setting(name = "type")
+constraint_value(name = "igneous", constraint_setting = "type")
+constraint_value(name = "metamorphic", constraint_setting = "type")
+
+platform(
+    name = "basalt_platform",
+    constraint_values = [
+        ":black",
+        ":igneous",
+    ],
+)
+
+platform(
+    name = "marble_platform",
+    constraint_values = [
+        ":white",
+        ":smooth",
+        ":metamorphic",
+    ],
+)
+```
+
+The platform can be specified on the command line. It activates the
+`config_setting`s that contain a subset of the platform's `constraint_values`,
+allowing those `config_setting`s to match in `select()` expressions.
+
+For example, in order to set the `srcs` attribute of `my_rocks` to `calcite.sh`,
+you can simply run
+
+```sh
+bazel build //my_app:my_rocks --platforms=//myapp:marble_platform
+```
+
+Without platforms, this might look something like
+
+```sh
+bazel build //my_app:my_rocks --define color=white --define texture=smooth --define type=metamorphic
+```
+
+`select()` can also directly read `constraint_value`s:
+
+```python
+constraint_setting(name = "type")
+constraint_value(name = "igneous", constraint_setting = "type")
+constraint_value(name = "metamorphic", constraint_setting = "type")
+sh_binary(
+    name = "my_rocks",
+    srcs = select({
+        ":igneous": ["igneous.sh"],
+        ":metamorphic" ["metamorphic.sh"],
+    }),
+)
+```
+
+This saves the need for boilerplate `config_setting`s when you only need to
+check against single values.
+
+Platforms are still under development. See the
+[documentation](/versions/9.1.0/concepts/platforms) for details.
+
+## Combining `select()`s {#combining-selects}
+
+`select` can appear multiple times in the same attribute:
+
+```python
+sh_binary(
+    name = "my_target",
+    srcs = ["always_include.sh"] +
+           select({
+               ":armeabi_mode": ["armeabi_src.sh"],
+               ":x86_mode": ["x86_src.sh"],
+           }) +
+           select({
+               ":opt_mode": ["opt_extras.sh"],
+               ":dbg_mode": ["dbg_extras.sh"],
+           }),
+)
+```
+
+Note: Some restrictions apply on what can be combined in the `select`s values:
+ - Duplicate labels can appear in different paths of the same `select`.
+ - Duplicate labels can *not* appear within the same path of a `select`.
+ - Duplicate labels can *not* appear across multiple combined `select`s (no matter what path)
+
+`select` cannot appear inside another `select`. If you need to nest `selects`
+and your attribute takes other targets as values, use an intermediate target:
+
+```python
+sh_binary(
+    name = "my_target",
+    srcs = ["always_include.sh"],
+    deps = select({
+        ":armeabi_mode": [":armeabi_lib"],
+        ...
+    }),
+)
+
+sh_library(
+    name = "armeabi_lib",
+    srcs = select({
+        ":opt_mode": ["armeabi_with_opt.sh"],
+        ...
+    }),
+)
+```
+
+If you need a `select` to match when multiple conditions match, consider [AND
+chaining](#and-chaining).
+
+## OR chaining {#or-chaining}
+
+Consider the following:
+
+```python
+sh_binary(
+    name = "my_target",
+    srcs = ["always_include.sh"],
+    deps = select({
+        ":config1": [":standard_lib"],
+        ":config2": [":standard_lib"],
+        ":config3": [":standard_lib"],
+        ":config4": [":special_lib"],
+    }),
+)
+```
+
+Most conditions evaluate to the same dep. But this syntax is hard to read and
+maintain. It would be nice to not have to repeat `[":standard_lib"]` multiple
+times.
+
+One option is to predefine the value as a BUILD variable:
+
+```python
+STANDARD_DEP = [":standard_lib"]
+
+sh_binary(
+    name = "my_target",
+    srcs = ["always_include.sh"],
+    deps = select({
+        ":config1": STANDARD_DEP,
+        ":config2": STANDARD_DEP,
+        ":config3": STANDARD_DEP,
+        ":config4": [":special_lib"],
+    }),
+)
+```
+
+This makes it easier to manage the dependency. But it still causes unnecessary
+duplication.
+
+For more direct support, use one of the following:
+
+### `selects.with_or` {#selects-with-or}
+
+The
+[with_or](https://github.com/bazelbuild/bazel-skylib/blob/main/docs/selects_doc.md#selectswith_or)
+macro in [Skylib](https://github.com/bazelbuild/bazel-skylib)'s
+[`selects`](https://github.com/bazelbuild/bazel-skylib/blob/main/docs/selects_doc.md)
+module supports `OR`ing conditions directly inside a `select`:
+
+```python
+load("@bazel_skylib//lib:selects.bzl", "selects")
+```
+
+```python
+sh_binary(
+    name = "my_target",
+    srcs = ["always_include.sh"],
+    deps = selects.with_or({
+        (":config1", ":config2", ":config3"): [":standard_lib"],
+        ":config4": [":special_lib"],
+    }),
+)
+```
+
+### `selects.config_setting_group` {#selects-config-setting-or-group}
+
+The
+[config_setting_group](https://github.com/bazelbuild/bazel-skylib/blob/main/docs/selects_doc.md#selectsconfig_setting_group)
+macro in [Skylib](https://github.com/bazelbuild/bazel-skylib)'s
+[`selects`](https://github.com/bazelbuild/bazel-skylib/blob/main/docs/selects_doc.md)
+module supports `OR`ing multiple `config_setting`s:
+
+```python
+load("@bazel_skylib//lib:selects.bzl", "selects")
+```
+
+```python
+config_setting(
+    name = "config1",
+    values = {"cpu": "arm"},
+)
+config_setting(
+    name = "config2",
+    values = {"compilation_mode": "dbg"},
+)
+selects.config_setting_group(
+    name = "config1_or_2",
+    match_any = [":config1", ":config2"],
+)
+sh_binary(
+    name = "my_target",
+    srcs = ["always_include.sh"],
+    deps = select({
+        ":config1_or_2": [":standard_lib"],
+        "//conditions:default": [":other_lib"],
+    }),
+)
+```
+
+Unlike `selects.with_or`, different targets can share `:config1_or_2` across
+different attributes.
+
+It's an error for multiple conditions to match unless one is an unambiguous
+"specialization" of the others or they all resolve to the same value. See [here](#configurable-build-example) for details.
+
+## AND chaining {#and-chaining}
+
+If you need a `select` branch to match when multiple conditions match, use the
+[Skylib](https://github.com/bazelbuild/bazel-skylib) macro
+[config_setting_group](https://github.com/bazelbuild/bazel-skylib/blob/main/docs/selects_doc.md#selectsconfig_setting_group):
+
+```python
+config_setting(
+    name = "config1",
+    values = {"cpu": "arm"},
+)
+config_setting(
+    name = "config2",
+    values = {"compilation_mode": "dbg"},
+)
+selects.config_setting_group(
+    name = "config1_and_2",
+    match_all = [":config1", ":config2"],
+)
+sh_binary(
+    name = "my_target",
+    srcs = ["always_include.sh"],
+    deps = select({
+        ":config1_and_2": [":standard_lib"],
+        "//conditions:default": [":other_lib"],
+    }),
+)
+```
+
+Unlike OR chaining, existing `config_setting`s can't be directly `AND`ed
+inside a `select`. You have to explicitly wrap them in a `config_setting_group`.
+
+## Custom error messages {#custom-error-messages}
+
+By default, when no condition matches, the target the `select()` is attached to
+fails with the error:
+
+```sh
+ERROR: Configurable attribute "deps" doesn't match this configuration (would
+a default condition help?).
+Conditions checked:
+  //tools/cc_target_os:darwin
+  //tools/cc_target_os:android
+```
+
+This can be customized with the [`no_match_error`](/versions/9.1.0/reference/be/functions#select)
+attribute:
+
+```python
+cc_library(
+    name = "my_lib",
+    deps = select(
+        {
+            "//tools/cc_target_os:android": [":android_deps"],
+            "//tools/cc_target_os:windows": [":windows_deps"],
+        },
+        no_match_error = "Please build with an Android or Windows toolchain",
+    ),
+)
+```
+
+```sh
+$ bazel build //myapp:my_lib
+ERROR: Configurable attribute "deps" doesn't match this configuration: Please
+build with an Android or Windows toolchain
+```
+
+## Rules compatibility {#rules-compatibility}
+
+Rule implementations receive the *resolved values* of configurable
+attributes. For example, given:
+
+```python
+# myapp/BUILD
+
+some_rule(
+    name = "my_target",
+    some_attr = select({
+        ":foo_mode": [":foo"],
+        ":bar_mode": [":bar"],
+    }),
+)
+```
+
+```sh
+$ bazel build //myapp/my_target --define mode=foo
+```
+
+Rule implementation code sees `ctx.attr.some_attr` as `[":foo"]`.
+
+Macros can accept `select()` clauses and pass them through to native
+rules. But *they cannot directly manipulate them*. For example, there's no way
+for a macro to convert
+
+```python
+select({"foo": "val"}, ...)
+```
+
+to
+
+```python
+select({"foo": "val_with_suffix"}, ...)
+```
+
+This is for two reasons.
+
+First, macros that need to know which path a `select` will choose *cannot work*
+because macros are evaluated in Bazel's [loading phase](/versions/9.1.0/run/build#loading),
+which occurs before flag values are known.
+This is a core Bazel design restriction that's unlikely to change any time soon.
+
+Second, macros that just need to iterate over *all* `select` paths, while
+technically feasible, lack a coherent UI. Further design is necessary to change
+this.
+
+## Bazel query and cquery {#query-and-cquery}
+
+Bazel [`query`](/versions/9.1.0/query/guide) operates over Bazel's
+[loading phase](/versions/9.1.0/reference/glossary#loading-phase).
+This means it doesn't know what command line flags a target uses since those
+flags aren't evaluated until later in the build (in the
+[analysis phase](/versions/9.1.0/reference/glossary#analysis-phase)).
+So it can't determine which `select()` branches are chosen.
+
+Bazel [`cquery`](/versions/9.1.0/query/cquery) operates after Bazel's analysis phase, so it has
+all this information and can accurately resolve `select()`s.
+
+Consider:
+
+```python
+load("@bazel_skylib//rules:common_settings.bzl", "string_flag")
+```
+```python
+# myapp/BUILD
+
+string_flag(
+    name = "dog_type",
+    build_setting_default = "cat"
+)
+
+cc_library(
+    name = "my_lib",
+    deps = select({
+        ":long": [":foo_dep"],
+        ":short": [":bar_dep"],
+    }),
+)
+
+config_setting(
+    name = "long",
+    flag_values = {":dog_type": "dachshund"},
+)
+
+config_setting(
+    name = "short",
+    flag_values = {":dog_type": "pug"},
+)
+```
+
+`query` overapproximates `:my_lib`'s dependencies:
+
+```sh
+$ bazel query 'deps(//myapp:my_lib)'
+//myapp:my_lib
+//myapp:foo_dep
+//myapp:bar_dep
+```
+
+while `cquery` shows its exact dependencies:
+
+```sh
+$ bazel cquery 'deps(//myapp:my_lib)' --//myapp:dog_type=pug
+//myapp:my_lib
+//myapp:bar_dep
+```
+
+## FAQ {#faq}
+
+### Why doesn't select() work in macros? {#faq-select-macro}
+
+select() *does* work in rules! See [Rules compatibility](#rules-compatibility) for
+details.
+
+The key issue this question usually means is that select() doesn't work in
+*macros*. These are different than *rules*. See the
+documentation on [rules](/versions/9.1.0/extending/rules) and [macros](/versions/9.1.0/extending/macros)
+to understand the difference.
+Here's an end-to-end example:
+
+Define a rule and macro:
+
+```python
+# myapp/defs.bzl
+
+# Rule implementation: when an attribute is read, all select()s have already
+# been resolved. So it looks like a plain old attribute just like any other.
+def _impl(ctx):
+    name = ctx.attr.name
+    allcaps = ctx.attr.my_config_string.upper()  # This works fine on all values.
+    print("My name is " + name + " with custom message: " + allcaps)
+
+# Rule declaration:
+my_custom_bazel_rule = rule(
+    implementation = _impl,
+    attrs = {"my_config_string": attr.string()},
+)
+
+# Macro declaration:
+def my_custom_bazel_macro(name, my_config_string):
+    allcaps = my_config_string.upper()  # This line won't work with select(s).
+    print("My name is " + name + " with custom message: " + allcaps)
+```
+
+Instantiate the rule and macro:
+
+```python
+# myapp/BUILD
+
+load("//myapp:defs.bzl", "my_custom_bazel_rule")
+load("//myapp:defs.bzl", "my_custom_bazel_macro")
+
+my_custom_bazel_rule(
+    name = "happy_rule",
+    my_config_string = select({
+        "//third_party/bazel_platforms/cpu:x86_32": "first string",
+        "//third_party/bazel_platforms/cpu:ppc": "second string",
+    }),
+)
+
+my_custom_bazel_macro(
+    name = "happy_macro",
+    my_config_string = "fixed string",
+)
+
+my_custom_bazel_macro(
+    name = "sad_macro",
+    my_config_string = select({
+        "//third_party/bazel_platforms/cpu:x86_32": "first string",
+        "//third_party/bazel_platforms/cpu:ppc": "other string",
+    }),
+)
+```
+
+Building fails because `sad_macro` can't process the `select()`:
+
+```sh
+$ bazel build //myapp:all
+ERROR: /myworkspace/myapp/BUILD:17:1: Traceback
+  (most recent call last):
+File "/myworkspace/myapp/BUILD", line 17
+my_custom_bazel_macro(name = "sad_macro", my_config_stri..."}))
+File "/myworkspace/myapp/defs.bzl", line 4, in
+  my_custom_bazel_macro
+my_config_string.upper()
+type 'select' has no method upper().
+ERROR: error loading package 'myapp': Package 'myapp' contains errors.
+```
+
+Building succeeds when you comment out `sad_macro`:
+
+```sh
+# Comment out sad_macro so it doesn't mess up the build.
+$ bazel build //myapp:all
+DEBUG: /myworkspace/myapp/defs.bzl:5:3: My name is happy_macro with custom message: FIXED STRING.
+DEBUG: /myworkspace/myapp/hi.bzl:15:3: My name is happy_rule with custom message: FIRST STRING.
+```
+
+This is impossible to change because *by definition* macros are evaluated before
+Bazel reads the build's command line flags. That means there isn't enough
+information to evaluate select()s.
+
+Macros can, however, pass `select()`s as opaque blobs to rules:
+
+```python
+# myapp/defs.bzl
+
+def my_custom_bazel_macro(name, my_config_string):
+    print("Invoking macro " + name)
+    my_custom_bazel_rule(
+        name = name + "_as_target",
+        my_config_string = my_config_string,
+    )
+```
+
+```sh
+$ bazel build //myapp:sad_macro_less_sad
+DEBUG: /myworkspace/myapp/defs.bzl:23:3: Invoking macro sad_macro_less_sad.
+DEBUG: /myworkspace/myapp/defs.bzl:15:3: My name is sad_macro_less_sad with custom message: FIRST STRING.
+```
+
+### Why does select() always return true? {#faq-boolean-select}
+
+Because *macros* (but not rules) by definition
+[can't evaluate `select()`s](#faq-select-macro), any attempt to do so
+usually produces an error:
+
+```sh
+ERROR: /myworkspace/myapp/BUILD:17:1: Traceback
+  (most recent call last):
+File "/myworkspace/myapp/BUILD", line 17
+my_custom_bazel_macro(name = "sad_macro", my_config_stri..."}))
+File "/myworkspace/myapp/defs.bzl", line 4, in
+  my_custom_bazel_macro
+my_config_string.upper()
+type 'select' has no method upper().
+```
+
+Booleans are a special case that fail silently, so you should be particularly
+vigilant with them:
+
+```sh
+$ cat myapp/defs.bzl
+def my_boolean_macro(boolval):
+  print("TRUE" if boolval else "FALSE")
+
+$ cat myapp/BUILD
+load("//myapp:defs.bzl", "my_boolean_macro")
+my_boolean_macro(
+    boolval = select({
+        "//third_party/bazel_platforms/cpu:x86_32": True,
+        "//third_party/bazel_platforms/cpu:ppc": False,
+    }),
+)
+
+$ bazel build //myapp:all --cpu=x86
+DEBUG: /myworkspace/myapp/defs.bzl:4:3: TRUE.
+$ bazel build //mypro:all --cpu=ppc
+DEBUG: /myworkspace/myapp/defs.bzl:4:3: TRUE.
+```
+
+This happens because macros don't understand the contents of `select()`.
+So what they're really evaluting is the `select()` object itself. According to
+[Pythonic](https://docs.python.org/release/2.5.2/lib/truth.html) design
+standards, all objects aside from a very small number of exceptions
+automatically return true.
+
+### Can I read select() like a dict? {#faq-inspectable-select}
+
+Macros [can't](#faq-select-macro) evaluate select(s) because macros evaluate before
+Bazel knows what the build's command line parameters are. Can they at least read
+the `select()`'s dictionary to, for example, add a suffix to each value?
+
+Conceptually this is possible, but [it isn't yet a Bazel feature](https://github.com/bazelbuild/bazel/issues/8419).
+What you *can* do today is prepare a straight dictionary, then feed it into a
+`select()`:
+
+```sh
+$ cat myapp/defs.bzl
+def selecty_genrule(name, select_cmd):
+  for key in select_cmd.keys():
+    select_cmd[key] += " WITH SUFFIX"
+  native.genrule(
+      name = name,
+      outs = [name + ".out"],
+      srcs = [],
+      cmd = "echo " + select(select_cmd + {"//conditions:default": "default"})
+        + " > $@"
+  )
+
+$ cat myapp/BUILD
+selecty_genrule(
+    name = "selecty",
+    select_cmd = {
+        "//third_party/bazel_platforms/cpu:x86_32": "x86 mode",
+    },
+)
+
+$ bazel build //testapp:selecty --cpu=x86 && cat bazel-genfiles/testapp/selecty.out
+x86 mode WITH SUFFIX
+```
+
+If you'd like to support both `select()` and native types, you can do this:
+
+```sh
+$ cat myapp/defs.bzl
+def selecty_genrule(name, select_cmd):
+    cmd_suffix = ""
+    if type(select_cmd) == "string":
+        cmd_suffix = select_cmd + " WITH SUFFIX"
+    elif type(select_cmd) == "dict":
+        for key in select_cmd.keys():
+            select_cmd[key] += " WITH SUFFIX"
+        cmd_suffix = select(select_cmd + {"//conditions:default": "default"})
+
+    native.genrule(
+        name = name,
+        outs = [name + ".out"],
+        srcs = [],
+        cmd = "echo " + cmd_suffix + "> $@",
+    )
+```
+
+### Why doesn't select() work with bind()? {#faq-select-bind}
+
+First of all, do not use `bind()`. It is deprecated in favor of `alias()`.
+
+The technical answer is that [`bind()`](/versions/9.1.0/reference/be/workspace#bind) is a repo
+rule, not a BUILD rule.
+
+Repo rules do not have a specific configuration, and aren't evaluated in
+the same way as BUILD rules. Therefore, a `select()` in a `bind()` can't
+actually evaluate to any specific branch.
+
+Instead, you should use [`alias()`](/versions/9.1.0/reference/be/general#alias), with a `select()` in
+the `actual` attribute, to perform this type of run-time determination. This
+works correctly, since `alias()` is a BUILD rule, and is evaluated with a
+specific configuration.
+
+You can even have a `bind()` target point to an `alias()`, if needed.
+
+```sh
+$ cat WORKSPACE
+workspace(name = "myapp")
+bind(name = "openssl", actual = "//:ssl")
+http_archive(name = "alternative", ...)
+http_archive(name = "boringssl", ...)
+
+$ cat BUILD
+config_setting(
+    name = "alt_ssl",
+    define_values = {
+        "ssl_library": "alternative",
+    },
+)
+
+alias(
+    name = "ssl",
+    actual = select({
+        "//:alt_ssl": "@alternative//:ssl",
+        "//conditions:default": "@boringssl//:ssl",
+    }),
+)
+```
+
+With this setup, you can pass `--define ssl_library=alternative`, and any target
+that depends on either `//:ssl` or `//external:ssl` will see the alternative
+located at `@alternative//:ssl`.
+
+But really, stop using `bind()`.
+
+### Why doesn't my select() choose what I expect? {#faq-select-choose-condition}
+
+If `//myapp:foo` has a `select()` that doesn't choose the condition you expect,
+use [cquery](/versions/9.1.0/query/cquery) and `bazel config` to debug:
+
+If `//myapp:foo` is the top-level target you're building, run:
+
+```sh
+$ bazel cquery //myapp:foo 
+//myapp:foo (12e23b9a2b534a)
+```
+
+If you're building some other target `//bar` that depends on
+//myapp:foo somewhere in its subgraph, run:
+
+```sh
+$ bazel cquery 'somepath(//bar, //myapp:foo)' 
+//bar:bar   (3ag3193fee94a2)
+//bar:intermediate_dep (12e23b9a2b534a)
+//myapp:foo (12e23b9a2b534a)
+```
+
+The `(12e23b9a2b534a)` next to `//myapp:foo` is a *hash* of the
+configuration that resolves `//myapp:foo`'s `select()`. You can inspect its
+values with `bazel config`:
+
+```sh
+$ bazel config 12e23b9a2b534a
+BuildConfigurationValue 12e23b9a2b534a
+Fragment com.google.devtools.build.lib.analysis.config.CoreOptions {
+  cpu: darwin
+  compilation_mode: fastbuild
+  ...
+}
+Fragment com.google.devtools.build.lib.rules.cpp.CppOptions {
+  linkopt: [-Dfoo=bar]
+  ...
+}
+...
+```
+
+Then compare this output against the settings expected by each `config_setting`.
+
+`//myapp:foo` may exist in different configurations in the same build. See the
+[cquery docs](/versions/9.1.0/query/cquery) for guidance on using `somepath` to get the right
+one.
+
+Caution: To prevent restarting the Bazel server, invoke `bazel config` with the
+same command line flags as the `bazel cquery`. The `config` command relies on
+the configuration nodes from the still-running server of the previous command.
+
+### Why doesn't `select()` work with platforms? {#faq-select-platforms}
+
+Bazel doesn't support configurable attributes checking whether a given platform
+is the target platform because the semantics are unclear.
+
+For example:
+
+```py
+platform(
+    name = "x86_linux_platform",
+    constraint_values = [
+        "@platforms//cpu:x86",
+        "@platforms//os:linux",
+    ],
+)
+
+cc_library(
+    name = "lib",
+    srcs = [...],
+    linkopts = select({
+        ":x86_linux_platform": ["--enable_x86_optimizations"],
+        "//conditions:default": [],
+    }),
+)
+```
+
+In this `BUILD` file, which `select()` should be used if the target platform has both the
+`@platforms//cpu:x86` and `@platforms//os:linux` constraints, but is **not** the
+`:x86_linux_platform` defined here? The author of the `BUILD` file and the user
+who defined the separate platform may have different ideas.
+
+#### What should I do instead?
+
+Instead, define a `config_setting` that matches **any** platform with
+these constraints:
+
+```py
+config_setting(
+    name = "is_x86_linux",
+    constraint_values = [
+        "@platforms//cpu:x86",
+        "@platforms//os:linux",
+    ],
+)
+
+cc_library(
+    name = "lib",
+    srcs = [...],
+    linkopts = select({
+        ":is_x86_linux": ["--enable_x86_optimizations"],
+        "//conditions:default": [],
+    }),
+)
+```
+
+This process defines specific semantics, making it clearer to users what
+platforms meet the desired conditions.
+
+#### What if I really, really want to `select` on the platform?
+
+If your build requirements specifically require checking the platform, you
+can flip the value of the `--platforms` flag in a `config_setting`:
+
+```py
+config_setting(
+    name = "is_specific_x86_linux_platform",
+    values = {
+        "platforms": ["//package:x86_linux_platform"],
+    },
+)
+
+cc_library(
+    name = "lib",
+    srcs = [...],
+    linkopts = select({
+        ":is_specific_x86_linux_platform": ["--enable_x86_optimizations"],
+        "//conditions:default": [],
+    }),
+)
+```
+
+The Bazel team doesn't endorse doing this; it overly constrains your build and
+confuses users when the expected condition does not match.
+
+[BuildSettings]: /extending/config#user-defined-build-settings
diff --git a/versions/9.1.0/docs/mobile-install.mdx b/versions/9.1.0/docs/mobile-install.mdx
new file mode 100644
index 00000000..3fb89182
--- /dev/null
+++ b/versions/9.1.0/docs/mobile-install.mdx
@@ -0,0 +1,202 @@
+---
+title: 'bazel mobile-install'
+---
+
+
+
+
Fast iterative development for Android

+
+This page describes how `bazel mobile-install` makes iterative development
+for Android much faster. It describes the benefits of this approach versus the
+drawbacks of separate build and install steps.
+
+## Summary {#summary}
+
+To install small changes to an Android app very quickly, do the following:
+
+ 1. Find the `android_binary` rule of the app you want to install.
+ 2. Connect your device to `adb`.
+ 3. Run `bazel mobile-install :your_target`. App startup will be a little
+    slower than usual.
+ 4. Edit the code or Android resources.
+ 5. Run `bazel mobile-install :your_target`.
+ 6. Enjoy a fast and minimal incremental installation!
+
+Some command line options to Bazel that may be useful:
+
+ - `--adb` tells Bazel which adb binary to use
+ - `--adb_arg` can be used to add extra arguments to the command line of `adb`.
+   One useful application of this is to select which device you want to install
+   to if you have multiple devices connected to your workstation:
+   `bazel mobile-install :your_target -- --adb_arg=-s --adb_arg=`
+
+When in doubt, look at the
+[example](https://github.com/bazelbuild/rules_android/tree/main/examples/basicapp),
+contact us on [Google Groups](https://groups.google.com/forum/#!forum/bazel-discuss),
+or [file a GitHub issue](https://github.com/bazelbuild/rules_android/issues)
+
+## Introduction {#introduction}
+
+One of the most important attributes of a developer's toolchain is speed: there
+is a world of difference between changing the code and seeing it run within a
+second and having to wait minutes, sometimes hours, before you get any feedback
+on whether your changes do what you expect them to.
+
+Unfortunately, the traditional Android toolchain for building an .apk entails
+many monolithic, sequential steps and all of these have to be done in order to
+build an Android app. At Google, waiting five minutes to build a single-line
+change was not unusual on larger projects like Google Maps.
+
+`bazel mobile-install` makes iterative development for Android much faster by
+using a combination of change pruning, work sharding, and clever manipulation of
+Android internals, all without changing any of your app's code.
+
+## Problems with traditional app installation {#problems-app-install}
+
+Building an Android app has some issues, including:
+
+- Dexing. By default, the Dexer tool (historically `dx`, now `d8` or `r8`)
+is invoked exactly once in the build and it does not know how to reuse work from
+previous builds: it dexes every method again, even though only one method was
+changed.
+
+- Uploading data to the device. adb does not use the full bandwidth of a USB 2.0
+connection, and larger apps can take a lot of time to upload. The entire app is
+uploaded, even if only small parts have changed, for example, a resource or a
+single method, so this can be a major bottleneck.
+
+- Compilation to native code. Android L introduced ART, a new Android runtime,
+which compiles apps ahead-of-time rather than compiling them just-in-time like
+Dalvik. This makes apps much faster at the cost of longer installation
+time. This is a good tradeoff for users because they typically install an app
+once and use it many times, but results in slower development where an app is
+installed many times and each version is run at most a handful of times.
+
+## The approach of `bazel mobile-install` {#approach-mobile-install}
+
+`bazel mobile-install `makes the following improvements:
+
+ - Sharded desugaring and dexing. After building the app's Java code, Bazel
+   shards the class files into approximately equal-sized parts and invokes `d8`
+   separately on them. `d8` is not invoked on shards that did not change since
+   the last build. These shards are then compiled into separate sharded APKs.
+
+ - Incremental file transfer. Android resources, .dex files, and native
+   libraries are removed from the main .apk and are stored in under a separate
+   mobile-install directory. This makes it possible to update code and Android
+   resources independently without reinstalling the whole app. Thus,
+   transferring the files takes less time and only the .dex files that have
+   changed are recompiled on-device.
+
+ - Sharded installation. Mobile-install uses Android Studio's
+   [`apkdeployer`](https://maven.google.com/web/index.html?q=deployer#com.android.tools.apkdeployer:apkdeployer)
+   tool to combine sharded APKs on the connected device and provide a cohesive
+   experience.
+
+### Sharded Dexing {#sharded-dexing}
+
+Sharded dexing is reasonably straightforward: once the .jar files are built, a
+[tool](https://github.com/bazelbuild/rules_android/blob/main/src/tools/java/com/google/devtools/build/android/ziputils/DexMapper.java)
+shards them into separate .jar files of approximately equal size, then invokes
+`d8` on those that were changed since the previous build. The logic that
+determines which shards to dex is not specific to Android: it just uses the
+general change pruning algorithm of Bazel.
+
+The first version of the sharding algorithm simply ordered the .class files
+alphabetically, then cut the list up into equal-sized parts, but this proved to
+be suboptimal: if a class was added or removed (even a nested or an anonymous
+one), it would cause all the classes alphabetically after it to shift by one,
+resulting in dexing those shards again. Thus, it was decided to shard Java
+packages rather than individual classes. Of course, this still results in
+dexing many shards if a new package is added or removed, but that is much less
+frequent than adding or removing a single class.
+
+The number of shards is controlled by command-line configuration, using the
+`--define=num_dex_shards=N` flag. In an ideal world, Bazel would
+automatically determine how many shards are best, but Bazel currently must know
+the set of actions (for example, commands to be executed during the build) before
+executing any of them, so it cannot determine the optimal number of shards
+because it doesn't know how many Java classes there will eventually be in the
+app. Generally speaking, the more shards, the faster the build and the
+installation will be, but the slower app startup becomes, because the dynamic
+linker has to do more work. The sweet spot is usually between 10 and 50 shards.
+
+### Incremental deployment {#incremental-deployment}
+
+Incremental APK shard transfer and installation is now handled by the
+`apkdeployer` utility described in ["The approach of mobile-install"](#approach-mobile-install).
+Whereas earlier (native) versions of mobile-install required manually tracking
+first-time installations and selectively apply the `--incremental`
+flag on subsequent installation, the most recent version in [`rules_android`](https://github.com/bazelbuild/rules_android/tree/main/mobile_install)
+has been greatly simplified. The same mobile-install
+invocation can be used regardless of how many times the app has been installed
+or reinstalled.
+
+At a high level, the `apkdeployer` tool is a wrapper around various `adb`
+sub-commands. The main entrypoint logic can be found in the
+[`com.android.tools.deployer.Deployer`](https://cs.android.com/android-studio/platform/tools/base/+/mirror-goog-studio-main:deploy/deployer/src/main/java/com/android/tools/deployer/Deployer.java)
+class, with other utility classes colocated in the same package.
+The `Deployer` class ingests, among other things, a list of paths to split
+APKs and a protobuf with information about the installation, and leverages
+deployment features for [Android app bundles](https://developer.android.com/guide/app-bundle)
+in order to create an install session and incrementally deploy app splits.
+See the [`ApkPreInstaller`](https://cs.android.com/android-studio/platform/tools/base/+/mirror-goog-studio-main:deploy/deployer/src/main/java/com/android/tools/deployer/ApkPreInstaller.java)
+and [`ApkInstaller`](https://cs.android.com/android-studio/platform/tools/base/+/mirror-goog-studio-main:deploy/deployer/src/main/java/com/android/tools/deployer/ApkInstaller.java)
+classes for implementation details.
+
+## Results {#results}
+
+### Performance {#performance}
+
+In general, `bazel mobile-install` results in a 4x to 10x speedup of building
+and installing large apps after a small change.
+
+The following numbers were computed for a few Google products:
+
+
+
+This, of course, depends on the nature of the change: recompilation after
+changing a base library takes more time.
+
+### Limitations {#limitations}
+
+The tricks the stub application plays don't work in every case.
+The following cases highlight where it does not work as expected:
+
+ - Mobile-install is only supported via the Starlark rules of `rules_android`.
+   See the ["brief history of mobile-install"](#mobile-install-history) for
+   more detail.
+
+ - Only devices running ART are supported. Mobile-install uses API and runtime features
+   that only exist on devices running ART, not Dalvik. Any Android runtime more
+   recent than Android L (API 21+) should be compatible.
+
+ - Bazel itself must be run with a tool Java runtime _and_ language version
+   of 17 or higher.
+
+ - Bazel versions prior to 8.4.0 must specify some additional flags for
+   mobile-install. See [the Bazel Android tutorial](/versions/9.1.0/start/android-app). These
+   flags inform Bazel where the Starlark mobile-install aspect is and which
+   rules are supported.
+
+### A brief history of mobile-install {#mobile-install-history}
+Earlier Bazel versions _natively_ included built-in build and test rules for
+popular languages and ecosystems such as C++, Java, and Android. These rules
+were therefore referred to as _native_ rules. Bazel 8 (released in 2024) removed
+support for these rules because many of them had been migrated to the
+[Starlark](/versions/9.1.0/rules/language) language. See the ["Bazel 8.0 LTS blog post"](https://blog.bazel.build/2024/12/09/bazel-8-release.html)
+for more details.
+
+The legacy native Android rules also supported a legacy _native_ version of
+mobile-install functionality. This is referred to as "mobile-install v1" or
+"native mobile-install" now. This functionality was deleted in Bazel 8, along
+with the built-in Android rules.
+
+Now, all mobile-install functionality, as well as all Android build and test
+rules, are implemented in Starlark and reside in the `rules_android` GitHub
+repository. The latest version is known as "mobile-install v3" or "MIv3".
+
+_Naming note_: There was a "mobile-install **v2**" available only internally
+at Google at one point, but this was never published externally, and only v3
+continues to be used for both Google-internal and OSS rules_android deployment.
+
diff --git a/versions/9.1.0/docs/sandboxing.mdx b/versions/9.1.0/docs/sandboxing.mdx
new file mode 100644
index 00000000..f55c992f
--- /dev/null
+++ b/versions/9.1.0/docs/sandboxing.mdx
@@ -0,0 +1,172 @@
+---
+title: 'Sandboxing'
+---
+
+This article covers sandboxing in Bazel and debugging your sandboxing
+environment.
+
+*Sandboxing* is a permission restricting strategy that isolates processes from
+each other or from resources in a system. For Bazel, this means restricting file
+system access.
+
+Bazel's file system sandbox runs processes in a working directory that only
+contains known inputs, such that compilers and other tools don't see source
+files they should not access, unless they know the absolute paths to them.
+
+Sandboxing doesn't hide the host environment in any way. Processes can freely
+access all files on the file system. However, on platforms that support user
+namespaces, processes can't modify any files outside their working directory.
+This ensures that the build graph doesn't have hidden dependencies that could
+affect the reproducibility of the build.
+
+More specifically, Bazel constructs an `execroot/` directory for each action,
+which acts as the action's work directory at execution time. `execroot/`
+contains all input files to the action and serves as the container for any
+generated outputs. Bazel then uses an operating-system-provided technique,
+containers on Linux and `sandbox-exec` on macOS, to constrain the action within
+`execroot/`.
+
+## Reasons for sandboxing {#sandboxing-reasons}
+
+-   Without action sandboxing, Bazel doesn't know if a tool uses undeclared
+    input files (files that are not explicitly listed in the dependencies of an
+    action). When one of the undeclared input files changes, Bazel still
+    believes that the build is up-to-date and won’t rebuild the action. This can
+    result in an incorrect incremental build.
+
+-   Incorrect reuse of cache entries creates problems during remote caching. A
+    bad cache entry in a shared cache affects every developer on the project,
+    and wiping the entire remote cache is not a feasible solution.
+
+-   Sandboxing mimics the behavior of remote execution — if a build works well
+    with sandboxing, it will likely also work with remote execution. By making
+    remote execution upload all necessary files (including local tools), you can
+    significantly reduce maintenance costs for compile clusters compared to
+    having to install the tools on every machine in the cluster every time you
+    want to try out a new compiler or make a change to an existing tool.
+
+## What sandbox strategy to use {#sandboxing-strategies}
+
+You can choose which kind of sandboxing to use, if any, with the
+[strategy flags](/versions/9.1.0/docs/user-manual#strategy-options). Using the `sandboxed`
+strategy makes Bazel pick one of the sandbox implementations listed below,
+preferring an OS-specific sandbox to the less hermetic generic one.
+[Persistent workers](/versions/9.1.0/remote/persistent) run in a generic sandbox if you pass
+the `--worker_sandboxing` flag.
+
+The `local` (a.k.a. `standalone`) strategy does not do any kind of sandboxing.
+It simply executes the action's command line with the working directory set to
+the execroot of your workspace.
+
+`processwrapper-sandbox` is a sandboxing strategy that does not require any
+"advanced" features - it should work on any POSIX system out of the box. It
+builds a sandbox directory consisting of symlinks that point to the original
+source files, executes the action's command line with the working directory set
+to this directory instead of the execroot, then moves the known output artifacts
+out of the sandbox into the execroot and deletes the sandbox. This prevents the
+action from accidentally using any input files that are not declared and from
+littering the execroot with unknown output files.
+
+`linux-sandbox` goes one step further and builds on top of the
+`processwrapper-sandbox`. Similar to what Docker does under the hood, it uses
+Linux Namespaces (User, Mount, PID, Network and IPC namespaces) to isolate the
+action from the host. That is, it makes the entire filesystem read-only except
+for the sandbox directory, so the action cannot accidentally modify anything on
+the host filesystem. This prevents situations like a buggy test accidentally rm
+-rf'ing your $HOME directory. Optionally, you can also prevent the action from
+accessing the network. `linux-sandbox` uses PID namespaces to prevent the action
+from seeing any other processes and to reliably kill all processes (even daemons
+spawned by the action) at the end.
+
+`darwin-sandbox` is similar, but for macOS. It uses Apple's `sandbox-exec` tool
+to achieve roughly the same as the Linux sandbox.
+
+Both the `linux-sandbox` and the `darwin-sandbox` do not work in a "nested"
+scenario due to restrictions in the mechanisms provided by the operating
+systems. Because Docker also uses Linux namespaces for its container magic, you
+cannot easily run `linux-sandbox` inside a Docker container, unless you use
+`docker run --privileged`. On macOS, you cannot run `sandbox-exec` inside a
+process that's already being sandboxed. Thus, in these cases, Bazel
+automatically falls back to using `processwrapper-sandbox`.
+
+If you would rather get a build error — such as to not accidentally build with a
+less strict execution strategy — explicitly modify the list of execution
+strategies that Bazel tries to use (for example, `bazel build
+--spawn_strategy=worker,linux-sandbox`).
+
+Dynamic execution usually requires sandboxing for local execution. To opt out,
+pass the `--experimental_local_lockfree_output` flag. Dynamic execution silently
+sandboxes [persistent workers](/versions/9.1.0/remote/persistent).
+
+## Downsides to sandboxing {#sandboxing_downsides}
+
+-   Sandboxing incurs extra setup and teardown cost. How big this cost is
+    depends on many factors, including the shape of the build and the
+    performance of the host OS. For Linux, sandboxed builds are rarely more than
+    a few percent slower. Setting `--reuse_sandbox_directories` can
+    mitigate the setup and teardown cost.
+
+-   Sandboxing effectively disables any cache the tool may have. You can
+    mitigate this by using [persistent workers](/versions/9.1.0/remote/persistent), at
+    the cost of weaker sandbox guarantees.
+
+-   [Multiplex workers](/versions/9.1.0/remote/multiplex) require explicit worker support
+    to be sandboxed. Workers that do not support multiplex sandboxing run as
+    singleplex workers under dynamic execution, which can cost extra memory.
+
+## Debugging {#debugging}
+
+Follow the strategies below to debug issues with sandboxing.
+
+### Deactivated namespaces {#deactivated-namespaces}
+
+On some platforms, such as
+[Google Kubernetes Engine](https://cloud.google.com/kubernetes-engine/)
+cluster nodes or Debian, user namespaces are deactivated by default due to
+security concerns. If the `/proc/sys/kernel/unprivileged_userns_clone` file
+exists and contains a 0, you can activate user namespaces by running:
+
+```posix-terminal
+   sudo sysctl kernel.unprivileged_userns_clone=1
+```
+
+### Rule execution failures {#rule-failures}
+
+The sandbox may fail to execute rules because of the system setup. If you see a
+message like `namespace-sandbox.c:633: execvp(argv[0], argv): No such file or
+directory`, try to deactivate the sandbox with `--strategy=Genrule=local` for
+genrules, and `--spawn_strategy=local` for other rules.
+
+### Detailed debugging for build failures {#debugging-build-failures}
+
+If your build failed, use `--verbose_failures` and `--sandbox_debug` to make
+Bazel show the exact command it ran when your build failed, including the part
+that sets up the sandbox.
+
+Example error message:
+
+```
+ERROR: path/to/your/project/BUILD:1:1: compilation of rule
+'//path/to/your/project:all' failed:
+
+Sandboxed execution failed, which may be legitimate (such as a compiler error),
+or due to missing dependencies. To enter the sandbox environment for easier
+debugging, run the following command in parentheses. On command failure, a bash
+shell running inside the sandbox will then automatically be spawned
+
+namespace-sandbox failed: error executing command
+  (cd /some/path && \
+  exec env - \
+    LANG=en_US \
+    PATH=/some/path/bin:/bin:/usr/bin \
+    PYTHONPATH=/usr/local/some/path \
+  /some/path/namespace-sandbox @/sandbox/root/path/this-sandbox-name.params --
+  /some/path/to/your/some-compiler --some-params some-target)
+```
+
+You can now inspect the generated sandbox directory and see which files Bazel
+created and run the command again to see how it behaves.
+
+Note that Bazel does not delete the sandbox directory when you use
+`--sandbox_debug`. Unless you are actively debugging, you should disable
+`--sandbox_debug` because it fills up your disk over time.
diff --git a/versions/9.1.0/docs/user-manual.mdx b/versions/9.1.0/docs/user-manual.mdx
new file mode 100644
index 00000000..0b60502e
--- /dev/null
+++ b/versions/9.1.0/docs/user-manual.mdx
@@ -0,0 +1,2497 @@
+---
+title: 'Commands and Options'
+---
+
+This page covers the options that are available with various Bazel commands,
+such as `bazel build`, `bazel run`, and `bazel test`. This page is a companion
+to the list of Bazel's commands in [Build with Bazel](/versions/9.1.0/run/build).
+
+## Target syntax {:#target-syntax}
+
+Some commands, like `build` or `test`, can operate on a list of targets. They
+use a syntax more flexible than labels, which is documented in
+[Specifying targets to build](/versions/9.1.0/run/build#specifying-build-targets).
+
+## Options {:#build-options}
+
+The following sections describe the options available during a
+build. When `--long` is used on a help command, the on-line
+help messages provide summary information about the meaning, type and
+default value for each option.
+
+Most options can only be specified once. When specified multiple times, the
+last instance wins. Options that can be specified multiple times are
+identified in the on-line help with the text 'may be used multiple times'.
+
+### Package location {:#package-location}
+
+#### `--package_path` {:#package-path}
+
+**WARNING:** The `--package_path` option is deprecated. Bazel prefers packages
+in the main repository to be under the workspace root.
+
+This option specifies the set of directories that are searched to
+find the BUILD file for a given package.
+
+Bazel finds its packages by searching the package path. This is a colon
+separated ordered list of bazel directories, each being the root of a
+partial source tree.
+
+_To specify a custom package path_ using the `--package_path` option:
+
+
+  % bazel build --package_path %workspace%:/some/other/root
+

+
+Package path elements may be specified in three formats:
+
+1.  If the first character is `/`, the path is absolute.
+2.  If the path starts with `%workspace%`, the path is taken relative
+    to the nearest enclosing bazel directory.
+    For instance, if your working directory
+    is `/home/bob/clients/bob_client/bazel/foo`, then the
+    string `%workspace%` in the package-path is expanded
+    to `/home/bob/clients/bob_client/bazel`.
+3.  Anything else is taken relative to the working directory.
+    This is usually not what you mean to do,
+    and may behave unexpectedly if you use Bazel from directories below the bazel workspace.
+    For instance, if you use the package-path element `.`,
+    and then cd into the directory
+    `/home/bob/clients/bob_client/bazel/foo`, packages
+    will be resolved from the
+    `/home/bob/clients/bob_client/bazel/foo` directory.
+
+If you use a non-default package path, specify it in your
+[Bazel configuration file](/versions/9.1.0/run/bazelrc) for convenience.
+
+_Bazel doesn't require any packages to be in the
+current directory_, so you can do a build from an empty bazel
+workspace if all the necessary packages can be found somewhere else
+on the package path.
+
+Example: Building from an empty client
+
+
+  % mkdir -p foo/bazel
+  % cd foo/bazel
+  % touch MODULE.bazel
+  % bazel build --package_path /some/other/path //foo
+

+
+#### `--deleted_packages` {:flag--deleted_packages}
+
+This option specifies a comma-separated list of packages which Bazel
+should consider deleted, and not attempt to load from any directory
+on the package path. This can be used to simulate the deletion of packages without
+actually deleting them. This option can be passed multiple times, in which case
+the individual lists are concatenated.
+
+### Error checking {:#error-checking}
+
+These options control Bazel's error-checking and/or warnings.
+
+#### `--[no]check_visibility` {:#check-visibility}
+
+If this option is set to false, visibility checks are demoted to warnings.
+The default value of this option is true, so that by default, visibility
+checking is done.
+
+#### `--output_filter={{ "" }}regex{{ "" }}` {:#output-filter}
+
+The `--output_filter` option will only show build and compilation
+warnings for targets that match the regular expression. If a target does not
+match the given regular expression and its execution succeeds, its standard
+output and standard error are thrown away.
+
+Here are some typical values for this option:
+
+
+  
+    
+    
+  
+  
+    
+    
+  
+  
+    
+    
+  
+  
+    
+    
+  
+
`--output_filter='^//(first/project|second/project):'`Show the output for the specified packages.
`--output_filter='^//((?!(first/bad_project|second/bad_project):).)*$'`Don't show output for the specified packages.
`--output_filter=`Show everything.
+    
`--output_filter=DONT_MATCH_ANYTHING`Show nothing.
+    

+
+### Tool flags {:#tool-flags}
+
+These options control which options Bazel will pass to other tools.
+
+#### `--copt={{ "" }}cc-option{{ "" }}` {:#copt}
+
+This option takes an argument which is to be passed to the compiler.
+The argument will be passed to the compiler whenever it is invoked
+for preprocessing, compiling, and/or assembling C, C++, or
+assembler code. It will not be passed when linking.
+
+This option can be used multiple times. For example:
+
+
+  % bazel build --copt="-g0" --copt="-fpic" //foo
+

+
+will compile the `foo` library without debug tables, generating
+position-independent code.
+
+Note: Changing `--copt` settings will force a recompilation
+of all affected object files. Also note that copts values listed in specific
+cc_library or cc_binary build rules will be placed on the compiler command line
+_after_ these options.
+
+Warning: C++-specific options (such as `-fno-implicit-templates`)
+should be specified in `--cxxopt`, not in
+`--copt`. Likewise, C-specific options (such as -Wstrict-prototypes)
+should be specified in `--conlyopt`, not in `copt`.
+Similarly, compiler options that only have an
+effect at link time (such as `-l`) should be specified in
+`--linkopt`, not in `--copt`.
+
+#### `--host_copt={{ "" }}cc-option{{ "" }}` {:#host-copt}
+
+This option takes an argument which is to be passed to the compiler for source files
+that are compiled in the exec configuration. This is analogous to
+the [`--copt`](#copt) option, but applies only to the
+exec configuration.
+
+#### `--host_conlyopt={{ "" }}cc-option{{ "" }}` {:#host-conlyopt}
+
+This option takes an argument which is to be passed to the compiler for C source files
+that are compiled in the exec configuration. This is analogous to
+the [`--conlyopt`](#cconlyopt) option, but applies only
+to the exec configuration.
+
+#### `--host_cxxopt={{ "" }}cc-option{{ "" }}` {:#host-cxxopt}
+
+This option takes an argument which is to be passed to the compiler for C++ source files
+that are compiled in the exec configuration. This is analogous to
+the [`--cxxopt`](#cxxopt) option, but applies only to the
+exec configuration.
+
+#### `--host_linkopt={{ "" }}linker-option{{ "" }}` {:#host-linkopt}
+
+This option takes an argument which is to be passed to the linker for source files
+that are compiled in the exec configuration. This is analogous to
+the [`--linkopt`](#linkopt) option, but applies only to
+the exec configuration.
+
+#### `--conlyopt={{ "" }}cc-option{{ "" }}` {:#cconlyopt}
+
+This option takes an argument which is to be passed to the compiler when compiling C source files.
+
+This is similar to `--copt`, but only applies to C compilation,
+not to C++ compilation or linking. So you can pass C-specific options
+(such as `-Wno-pointer-sign`) using `--conlyopt`.
+
+Note: copts parameters listed in specific cc_library or cc_binary build rules
+are placed on the compiler command line _after_ these options.
+
+#### `--cxxopt={{ "" }}cc-option{{ "" }}` {:#cxxopt}
+
+This option takes an argument which is to be passed to the compiler when
+compiling C++ source files.
+
+This is similar to `--copt`, but only applies to C++ compilation,
+not to C compilation or linking. So you can pass C++-specific options
+(such as `-fpermissive` or `-fno-implicit-templates`) using `--cxxopt`.
+
+For example:
+
+
+  % bazel build --cxxopt="-fpermissive" --cxxopt="-Wno-error" //foo/cruddy_code
+

+
+Note: copts parameters listed in specific cc_library or cc_binary build rules
+are placed on the compiler command line _after_ these options.
+
+#### `--linkopt={{ "" }}linker-option{{ "" }}` {:#linkopt}
+
+This option takes an argument which is to be passed to the compiler when linking.
+
+This is similar to `--copt`, but only applies to linking,
+not to compilation. So you can pass compiler options that only make sense
+at link time (such as `-lssp` or `-Wl,--wrap,abort`)
+using `--linkopt`. For example:
+
+
+  % bazel build --copt="-fmudflap" --linkopt="-lmudflap" //foo/buggy_code
+

+
+Build rules can also specify link options in their attributes. This option's
+settings always take precedence. Also see
+[cc_library.linkopts](/versions/9.1.0/reference/be/c-cpp#cc_library.linkopts).
+
+#### `--strip (always|never|sometimes)` {:#strip}
+
+This option determines whether Bazel will strip debugging information from
+all binaries and shared libraries, by invoking the linker with the `-Wl,--strip-debug` option.
+`--strip=always` means always strip debugging information.
+`--strip=never` means never strip debugging information.
+The default value of `--strip=sometimes` means strip if the `--compilation_mode`
+is `fastbuild`.
+
+
+  % bazel build --strip=always //foo:bar
+

+
+will compile the target while stripping debugging information from all generated
+binaries.
+
+Note: If you want debugging information, it's not enough to disable stripping;
+you also need to make sure that the debugging information was generated by the
+compiler, which you can do by using either `-c dbg` or `--copt -g`.
+
+Bazel's `--strip` option corresponds with ld's `--strip-debug` option:
+it only strips debugging information. If for some reason you want to strip _all_ symbols,
+not just _debug_ symbols, you would need to use ld's `--strip-all` option,
+which you can do by passing `--linkopt=-Wl,--strip-all` to Bazel. Also be
+aware that setting Bazel's `--strip` flag will override
+`--linkopt=-Wl,--strip-all`, so you should only set one or the other.
+
+If you are only building a single binary and want all symbols stripped, you could also
+pass `--stripopt=--strip-all` and explicitly build the
+`//foo:bar.stripped` version of the target. As described in the section on
+`--stripopt`, this applies a strip action after the final binary is
+linked rather than including stripping in all of the build's link actions.
+
+#### `--stripopt={{ "" }}strip-option{{ "" }}` {:#stripopt}
+
+This is an additional option to pass to the `strip` command when generating
+a [`*.stripped` binary](/versions/9.1.0/reference/be/c-cpp#cc_binary_implicit_outputs). The default
+is `-S -p`. This option can be used multiple times.
+
+Note: `--stripopt` does not apply to the stripping of the main
+binary with `[--strip](#flag--strip)=(always|sometimes)`.
+
+#### `--fdo_instrument={{ "" }}profile-output-dir{{ "" }}` {:#fdo-instrument}
+
+The `--fdo_instrument` option enables the generation of
+FDO (feedback directed optimization) profile output when the
+built C/C++ binary is executed. For GCC, the argument provided is used as a
+directory prefix for a per-object file directory tree of .gcda files
+containing profile information for each .o file.
+
+Once the profile data tree has been generated, the profile tree
+should be zipped up, and provided to the
+`--fdo_optimize={{ "" }}profile-zip{{ "" }}`
+Bazel option to enable the FDO-optimized compilation.
+
+For the LLVM compiler the argument is also the directory under which the raw LLVM profile
+data file(s) is dumped. For example:
+`--fdo_instrument={{ "" }}/path/to/rawprof/dir/{{ "" }}`.
+
+The options `--fdo_instrument` and `--fdo_optimize` cannot be used at the same time.
+
+#### `--fdo_optimize={{ "" }}profile-zip{{ "" }}` {:#fdo-optimize}
+
+The `--fdo_optimize` option enables the use of the
+per-object file profile information to perform FDO (feedback
+directed optimization) optimizations when compiling. For GCC, the argument
+provided is the zip file containing the previously-generated file tree
+of .gcda files containing profile information for each .o file.
+
+Alternatively, the argument provided can point to an auto profile
+identified by the extension .afdo.
+
+Note: This option also accepts labels that resolve to source files. You
+may need to add an `exports_files` directive to the corresponding package to
+make the file visible to Bazel.
+
+For the LLVM compiler the argument provided should point to the indexed LLVM
+profile output file prepared by the llvm-profdata tool, and should have a .profdata
+extension.
+
+The options `--fdo_instrument` and `--fdo_optimize` cannot be used at the same time.
+
+#### `--java_language_version={{ "" }}version{{ "" }}` {:#java-language-version}
+
+This option specifies the version of Java sources. For example:
+
+
+  % bazel build --java_language_version=8 java/com/example/common/foo:all
+

+
+compiles and allows only constructs compatible with Java 8 specification.
+Default value is 11. -->
+Possible values are: 8, 9, 10, 11, 17, and 21 and may be extended by
+registering custom Java toolchains using `default_java_toolchain`.
+
+#### `--tool_java_language_version={{ "" }}version{{ "" }}` {:#tool-java-language-version}
+
+The Java language version used to build tools that are executed during a build.
+Default value is 11.
+
+#### `--java_runtime_version={{ "" }}version{{ "" }}` {:#java-runtime-version}
+
+This option specifies the version of JVM to use to execute the code and run the tests. For
+example:
+
+
+  % bazel run --java_runtime_version=remotejdk_11 java/com/example/common/foo:java_application
+

+
+downloads JDK 11 from a remote repository and run the Java application using it.
+
+Default value is `local_jdk`.
+Possible values are: `local_jdk`, `local_jdk_{{ "" }}version{{ "" }}`,
+`remotejdk_11`, `remotejdk_17`, and `remotejdk_21`.
+You can extend the values by registering custom JVM using either
+`local_java_repository` or `remote_java_repository` repository rules.
+
+#### `--tool_java_runtime_version={{ "" }}version{{ "" }}` {:#tool-java-runtime-version}
+
+The version of JVM used to execute tools that are needed during a build.
+Default value is `remotejdk_11`.
+
+#### `--jvmopt={{ "" }}jvm-option{{ "" }}` {:#jvmopt}
+
+This option allows option arguments to be passed to the Java VM. It can be used
+with one big argument, or multiple times with individual arguments. For example:
+
+
+  % bazel build --jvmopt="-server -Xms256m" java/com/example/common/foo:all
+

+
+will use the server VM for launching all Java binaries and set the
+startup heap size for the VM to 256 MB.
+
+#### `--javacopt={{ "" }}javac-option{{ "" }}` {:#javacopt}
+
+This option allows option arguments to be passed to javac. It can be used
+with one big argument, or multiple times with individual arguments. For example:
+
+
+  % bazel build --javacopt="-g:source,lines" //myprojects:prog
+

+
+will rebuild a java_binary with the javac default debug info
+(instead of the bazel default).
+
+The option is passed to javac after the Bazel built-in default options for
+javac and before the per-rule options. The last specification of
+any option to javac wins. The default options for javac are:
+
+
+  -source 8 -target 8 -encoding UTF-8
+

+
+Note: Changing `--javacopt` settings will force a recompilation
+of all affected classes. Also note that javacopts parameters listed in
+specific java_library or java_binary build rules will be placed on the javac
+command line _after_ these options.
+
+#### `--strict_java_deps (default|strict|off|warn|error)` {:#strict-java-deps}
+
+This option controls whether javac checks for missing direct dependencies.
+Java targets must explicitly declare all directly used targets as
+dependencies. This flag instructs javac to determine the jars actually used
+for type checking each java file, and warn/error if they are not the output
+of a direct dependency of the current target.
+
+* `off` means checking is disabled.
+* `warn` means javac will generate standard java warnings of
+  type `[strict]` for each missing direct dependency.
+* `default`, `strict` and `error` all
+  mean javac will generate errors instead of warnings, causing the current
+  target to fail to build if any missing direct dependencies are found.
+  This is also the default behavior when the flag is unspecified.
+
+### Build semantics {:#build-semantics}
+
+These options affect the build commands and/or the output file contents.
+
+#### `--compilation_mode (fastbuild|opt|dbg)` (-c) {:#compilation-mode}
+
+The `--compilation_mode` option (often shortened to `-c`,
+especially `-c opt`) takes an argument of `fastbuild`, `dbg`
+or `opt`, and affects various C/C++ code-generation
+options, such as the level of optimization and the completeness of
+debug tables. Bazel uses a different output directory for each
+different compilation mode, so you can switch between modes without
+needing to do a full rebuild _every_ time.
+
+* `fastbuild` means build as fast as possible:
+  generate minimal debugging information (`-gmlt
+  -Wl,-S`), and don't optimize. This is the
+  default. Note: `-DNDEBUG` will **not** be set.
+* `dbg` means build with debugging enabled (`-g`),
+  so that you can use gdb (or another debugger).
+* `opt` means build with optimization enabled and
+  with `assert()` calls disabled (`-O2 -DNDEBUG`).
+  Debugging information will not be generated in `opt` mode
+  unless you also pass `--copt -g`.
+
+#### `--cpu={{ "" }}cpu{{ "" }}` {:#cpu}
+
+This option specifies the target CPU architecture to be used for
+the compilation of binaries during the build.
+
+Note: A particular combination of crosstool version, compiler version,
+and target CPU is allowed only if it has been specified in the currently
+used CROSSTOOL file.
+
+#### `--action_env={{ "" }}VAR=VALUE{{ "" }}` {:#action-env}
+
+Specifies the set of environment variables available during the execution of all actions.
+Variables can be either specified by name, in which case the value will be taken from the
+invocation environment, or by the `name=value` pair which sets the value independent of the
+invocation environment.
+
+This `--action_env` flag can be specified multiple times. If a value is assigned to the same
+variable across multiple `--action_env` flags, the latest assignment wins.
+
+#### `--experimental_action_listener={{ "" }}label{{ "" }}` {:#experimental-action-listener}
+
+Warning: Extra actions are deprecated. Use
+[aspects](/versions/9.1.0/extending/aspects)
+instead.
+
+The `experimental_action_listener` option instructs Bazel to use
+details from the [`action_listener`](/versions/9.1.0/reference/be/extra-actions#action_listener) rule specified by {{ "" }}label{{ "" }} to
+insert [`extra_actions`](/versions/9.1.0/reference/be/extra-actions#extra_action) into the build graph.
+
+#### `--[no]experimental_extra_action_top_level_only` {:experimental-extra-action-top-level-only}
+
+Warning: Extra actions are deprecated. Use
+[aspects](/versions/9.1.0/extending/aspects) instead.
+
+If this option is set to true, extra actions specified by the
+[ `--experimental_action_listener`](#experimental-action-listener) command
+line option will only be scheduled for top level targets.
+
+#### `--experimental_extra_action_filter={{ "" }}regex{{ "" }}` {:#experimental-extra-action-filter}
+
+Warning: Extra actions are deprecated. Use
+[aspects](/versions/9.1.0/extending/aspects) instead.
+
+The `experimental_extra_action_filter` option instructs Bazel to
+filter the set of targets to schedule `extra_actions` for.
+
+This flag is only applicable in combination with the
+[`--experimental_action_listener`](#experimental-action-listener) flag.
+
+By default all `extra_actions` in the transitive closure of the
+requested targets-to-build get scheduled for execution.
+`--experimental_extra_action_filter` will restrict scheduling to
+`extra_actions` of which the owner's label matches the specified
+regular expression.
+
+The following example will limit scheduling of `extra_actions`
+to only apply to actions of which the owner's label contains '/bar/':
+
+
% bazel build --experimental_action_listener=//test:al //foo/... \
+  --experimental_extra_action_filter=.*/bar/.*
+

+
+#### `--host_cpu={{ "" }}cpu{{ "" }}` {:#host-cpu}
+
+This option specifies the name of the CPU architecture that should be
+used to build host tools.
+
+#### `--android_platforms={{ "" }}platform[,platform]*{{ "" }}` {:#android-platforms}
+
+The platforms to build the transitive `deps` of
+`android_binary` rules (specifically for native dependencies like C++). For
+example, if a `cc_library` appears in the transitive `deps` of an
+`android_binary` rule it is be built once for each platform specified with
+`--android_platforms` for the `android_binary` rule, and included in the final
+output.
+
+There is no default value for this flag: a custom Android platform must be
+defined and used.
+
+One `.so` file is created and packaged in the APK for each platform specified
+with `--android_platforms`. The `.so` file's name prefixes the name of the
+`android_binary` rule with "lib". For example, if the name of the
+`android_binary` is "foo", then the file is `libfoo.so`.
+
+#### `--per_file_copt={{ "" }}[+-]regex[,[+-]regex]...@option[,option]...{{ "" }}` {:#per-file-copt}
+
+When present, any C++ file with a label or an execution path matching one of the inclusion regex
+expressions and not matching any of the exclusion expressions will be built
+with the given options. The label matching uses the canonical form of the label
+(i.e //`package`:`label_name`).
+
+The execution path is the relative path to your workspace directory including the base name
+(including extension) of the C++ file. It also includes any platform dependent prefixes.
+
+Note: If only one of the label or the execution path matches the options will be used.
+
+To match the generated files (such as genrule outputs)
+Bazel can only use the execution path. In this case the regexp shouldn't start with '//'
+since that doesn't match any execution paths. Package names can be used like this:
+`--per_file_copt=base/.*\.pb\.cc@-g0`. This will match every
+`.pb.cc` file under a directory called `base`.
+
+This option can be used multiple times.
+
+The option is applied regardless of the compilation mode used. For example, it is possible
+to compile with `--compilation_mode=opt` and selectively compile some
+files with stronger optimization turned on, or with optimization disabled.
+
+**Caveat**: If some files are selectively compiled with debug symbols the symbols
+might be stripped during linking. This can be prevented by setting
+`--strip=never`.
+
+**Syntax**: `[+-]regex[,[+-]regex]...@option[,option]...` Where
+`regex` stands for a regular expression that can be prefixed with
+a `+` to identify include patterns and with `-` to identify
+exclude patterns. `option` stands for an arbitrary option that is passed
+to the C++ compiler. If an option contains a `,` it has to be quoted like so
+`\,`. Options can also contain `@`, since only the first
+`@` is used to separate regular expressions from options.
+
+**Example**:
+`--per_file_copt=//foo:.*\.cc,-//foo:file\.cc@-O0,-fprofile-arcs`
+adds the `-O0` and the `-fprofile-arcs` options to the command
+line of the C++ compiler for all `.cc` files in `//foo/` except `file.cc`.
+
+#### `--dynamic_mode={{ "" }}mode{{ "" }}` {:#dynamic-mode}
+
+Determines whether C++ binaries will be linked dynamically, interacting with
+the [linkstatic attribute](/versions/9.1.0/reference/be/c-cpp#cc_binary.linkstatic) on build rules.
+
+Modes:
+
+* `default`: Allows bazel to choose whether to link dynamically.
+  See [linkstatic](/versions/9.1.0/reference/be/c-cpp#cc_binary.linkstatic) for more
+  information.
+* `fully`: Links all targets dynamically. This will speed up
+  linking time, and reduce the size of the resulting binaries.
+* `off`: Links all targets in
+  [mostly static](/versions/9.1.0/reference/be/c-cpp#cc_binary.linkstatic) mode.
+  If `-static` is set in linkopts, targets will change to fully static.
+
+#### `--fission (yes|no|[dbg][,opt][,fastbuild])` {:#fission}
+
+Enables [Fission](https://gcc.gnu.org/wiki/DebugFission){: .external},
+which writes C++ debug information to dedicated .dwo files instead of .o files, where it would
+otherwise go. This substantially reduces the input size to links and can reduce link times.
+
+When set to `[dbg][,opt][,fastbuild]` (example:
+`--fission=dbg,fastbuild`), Fission is enabled
+only for the specified set of compilation modes. This is useful for bazelrc
+settings. When set to `yes`, Fission is enabled
+universally. When set to `no`, Fission is disabled
+universally. Default is no.
+
+#### `--force_ignore_dash_static` {:#force-ignore-dash-static}
+
+If this flag is set, any `-static` options in linkopts of
+`cc_*` rules BUILD files are ignored. This is only intended as a
+workaround for C++ hardening builds.
+
+#### `--[no]force_pic` {:#force-pic}
+
+If enabled, all C++ compilations produce position-independent code ("-fPIC"),
+links prefer PIC pre-built libraries over non-PIC libraries, and links produce
+position-independent executables ("-pie"). Default is disabled.
+
+Note: Dynamically linked binaries (for example `--dynamic_mode fully`)
+generate PIC code regardless of this flag's setting. So this flag is for cases
+where users want PIC code explicitly generated for static links.
+
+#### `--android_resource_shrinking` {:#flag--android_resource_shrinking}
+
+Selects whether to perform resource shrinking for android_binary rules. Sets the default for the
+[shrink_resources attribute](/versions/9.1.0/reference/be/android#android_binary.shrink_resources) on
+android_binary rules; see the documentation for that rule for further details. Defaults to off.
+
+#### `--custom_malloc={{ "" }}malloc-library-target{{ "" }}` {:#custom-malloc}
+
+When specified, always use the given malloc implementation, overriding all
+`malloc="target"` attributes, including in those targets that use the
+default (by not specifying any `malloc`).
+
+#### `--crosstool_top={{ "" }}label{{ "" }}` {:#crosstool-top}
+
+This option specifies the location of the crosstool compiler suite
+to be used for all C++ compilation during a build. Bazel will look in that
+location for a CROSSTOOL file and uses that to automatically determine
+settings for `--compiler`.
+
+#### `--host_crosstool_top={{ "" }}label{{ "" }}` {:#host-crosstool-top}
+
+If not specified, Bazel uses the value of `--crosstool_top` to compile
+code in the exec configuration, such as tools run during the build. The main purpose of this flag
+is to enable cross-compilation.
+
+#### `--apple_crosstool_top={{ "" }}label{{ "" }}` {:#apple-crosstool-top}
+
+The crosstool to use for compiling C/C++ rules in the transitive `deps` of
+objc_*, ios__*, and apple_* rules. For those targets, this flag overwrites
+`--crosstool_top`.
+
+#### `--compiler={{ "" }}version{{ "" }}` {:#compiler}
+
+This option specifies the C/C++ compiler version (such as `gcc-4.1.0`)
+to be used for the compilation of binaries during the build. If you want to
+build with a custom crosstool, you should use a CROSSTOOL file instead of
+specifying this flag.
+
+Note: Only certain combinations of crosstool version, compiler version,
+and target CPU are allowed.
+
+#### `--android_sdk={{ "" }}label{{ "" }}` {:#android-sdk}
+
+Deprecated. This shouldn't be directly specified.
+
+This option specifies the Android SDK/platform toolchain
+and Android runtime library that will be used to build any Android-related
+rule.
+
+The Android SDK will be automatically selected if an `android_sdk_repository`
+rule is defined in the WORKSPACE file.
+
+#### `--java_toolchain={{ "" }}label{{ "" }}` {:#java-toolchain}
+
+No-op. Kept only for backwards compatibility.
+
+#### `--host_java_toolchain={{ "" }}label{{ "" }}` {:#host-java-toolchain}
+
+No-op. Kept only for backwards compatibility.
+
+#### `--javabase=({{ "" }}label{{ "" }})` {:#javabase}
+
+No-op. Kept only for backwards compatibility.
+
+#### `--host_javabase={{ "" }}label{{ "" }}` {:#host-javabase}
+
+No-op. Kept only for backwards compatibility.
+
+### Execution strategy {:#execution-strategy}
+
+These options affect how Bazel will execute the build.
+They should not have any significant effect on the output files
+generated by the build. Typically their main effect is on the
+speed of the build.
+
+#### `--spawn_strategy={{ "" }}strategy{{ "" }}` {:#spawn-strategy}
+
+This option controls where and how commands are executed.
+
+* `standalone` causes commands to be executed as local subprocesses. This value is
+  deprecated. Please use `local` instead.
+* `sandboxed` causes commands to be executed inside a sandbox on the local machine.
+  This requires that all input files, data dependencies and tools are listed as direct
+  dependencies in the `srcs`, `data` and `tools` attributes.
+  Bazel enables local sandboxing by default, on systems that support sandboxed execution.
+* `local` causes commands to be executed as local subprocesses.
+* `worker` causes commands to be executed using a persistent worker, if available.
+* `docker` causes commands to be executed inside a docker sandbox on the local machine.
+  This requires that docker is installed.
+* `remote` causes commands to be executed remotely; this is only available if a
+  remote executor has been configured separately.
+
+#### `--strategy {{ "" }}mnemonic{{ "" }}={{ "" }}strategy{{ "" }}` {:#strategy}
+
+This option controls where and how commands are executed, overriding the
+[--spawn_strategy](#spawn-strategy) (and
+[--genrule_strategy](#genrule-strategy) with mnemonic
+Genrule) on a per-mnemonic basis. See
+[--spawn_strategy](#spawn-strategy) for the supported
+strategies and their effects.
+
+#### `--strategy_regexp={{ "" }}={{ "" }}` {:#strategy-regexp}
+
+This option specifies which strategy should be used to execute commands that have descriptions
+matching a certain `regex_filter`. See
+[--per_file_copt](#per-file-copt) for details on
+regex_filter matching. See
+[--spawn_strategy](#spawn-strategy) for the supported
+strategies and their effects.
+
+The last `regex_filter` that matches the description is used. This option overrides
+other flags for specifying strategy.
+
+* Example: `--strategy_regexp=//foo.*\\.cc,-//foo/bar=local` means to run actions using
+  `local` strategy if their descriptions match //foo.*.cc but not //foo/bar.
+* Example:
+  `--strategy_regexp='Compiling.*/bar=local' --strategy_regexp=Compiling=sandboxed`
+  runs 'Compiling //foo/bar/baz' with the `sandboxed` strategy, but reversing
+  the order runs it with `local`.
+* Example: `--strategy_regexp='Compiling.*/bar=local,sandboxed'` runs
+  'Compiling //foo/bar/baz' with the `local` strategy and falls back to
+  `sandboxed` if it fails.
+
+#### `--genrule_strategy={{ "" }}strategy{{ "" }}` {:#genrule-strategy}
+
+This is a deprecated short-hand for `--strategy=Genrule={{ "" }}strategy{{ "" }}`.
+
+#### `--jobs={{ "" }}n{{ "" }}` (-j) {:#jobs}
+
+This option, which takes an integer argument, specifies a limit on
+the number of jobs that should be executed concurrently during the
+execution phase of the build.
+
+Note : The number of concurrent jobs that Bazel will run
+is determined not only by the `--jobs` setting, but also
+by Bazel's scheduler, which tries to avoid running concurrent jobs
+that will use up more resources (RAM or CPU) than are available,
+based on some (very crude) estimates of the resource consumption
+of each job. The behavior of the scheduler can be controlled by
+the `--local_resources` option.
+
+#### `--progress_report_interval={{ "" }}n{{ "" }}` {:progress-report-interval}
+
+Bazel periodically prints a progress report on jobs that are not
+finished yet (such as long running tests). This option sets the
+reporting frequency, progress will be printed every `n`
+seconds.
+
+The default is 0, that means an incremental algorithm: the first
+report will be printed after 10 seconds, then 30 seconds and after
+that progress is reported once every minute.
+
+When bazel is using cursor control, as specified by
+[`--curses`](#curses), progress is reported every second.
+
+#### `--local_resources {{ "" }}resources or resource expression{{ "" }}` {:#local-resources}
+
+These options specify the amount of local resources (RAM in MB and number of CPU logical cores)
+that Bazel can take into consideration when scheduling build and test activities to run locally. They take
+an float, or a keyword (HOST_RAM or HOST_CPUS) optionally followed by `[-|*`float`]`
+(for example, `--local_resources=cpu=2`, `--local_resources=memory=HOST_RAM*.5`,
+`--local_resources=cpu=HOST_CPUS-1`).
+The flags are independent; one or both may be set. By default, Bazel estimates
+the amount of RAM and number of CPU cores directly from the local system's configuration.
+
+#### `--[no]build_runfile_links` {:#build-runfile-links}
+
+This option, which is enabled by default, specifies whether the runfiles
+symlinks for tests and binaries should be built in the output directory.
+Using `--nobuild_runfile_links` can be useful
+to validate if all targets compile without incurring the overhead
+for building the runfiles trees.
+
+When tests (or applications) are executed, their run-time data
+dependencies are gathered together in one place. Within Bazel's
+output tree, this "runfiles" tree is typically rooted as a sibling of
+the corresponding binary or test.
+During test execution, runfiles may be accessed using paths of the form
+`$TEST_SRCDIR/{{ "" }}canonical_repo_name{{ "" }}/{{ "" }}packagename{{ "" }}/{{ "" }}filename{{ "" }}`.
+The runfiles tree ensures that tests have access to all the files
+upon which they have a declared dependence, and nothing more. By
+default, the runfiles tree is implemented by constructing a set of
+symbolic links to the required files. As the set of links grows, so
+does the cost of this operation, and for some large builds it can
+contribute significantly to overall build time, particularly because
+each individual test (or application) requires its own runfiles tree.
+
+#### `--[no]build_runfile_manifests` {:#build-runfile-manifests}
+
+This option, which is enabled by default, specifies whether runfiles manifests
+should be written to the output tree.
+Disabling it implies `--nobuild_runfile_links`.
+
+It can be disabled when executing tests remotely, as runfiles trees will
+be created remotely from in-memory manifests.
+
+#### `--[no]discard_analysis_cache` {:#discard-analysis-cache}
+
+When this option is enabled, Bazel will discard the analysis cache
+right before execution starts, thus freeing up additional memory
+(around 10%) for the [execution phase](/versions/9.1.0/run/build#execution).
+The drawback is that further incremental builds will be slower. See also
+[memory-saving mode](/versions/9.1.0/configure/memory).
+
+#### `--[no]keep_going`  (-k) {:#keep-going}
+
+As in GNU Make, the execution phase of a build stops when the first
+error is encountered. Sometimes it is useful to try to build as
+much as possible even in the face of errors. This option enables
+that behavior, and when it is specified, the build will attempt to
+build every target whose prerequisites were successfully built, but
+will ignore errors.
+
+While this option is usually associated with the execution phase of
+a build, it also affects the analysis phase: if several targets are
+specified in a build command, but only some of them can be
+successfully analyzed, the build will stop with an error
+unless `--keep_going` is specified, in which case the
+build will proceed to the execution phase, but only for the targets
+that were successfully analyzed.
+
+#### `--[no]use_ijars` {:#use-ijars}
+
+This option changes the way `java_library` targets are
+compiled by Bazel. Instead of using the output of a
+`java_library` for compiling dependent
+`java_library` targets, Bazel will create interface jars
+that contain only the signatures of non-private members (public,
+protected, and default (package) access methods and fields) and use
+the interface jars to compile the dependent targets. This makes it
+possible to avoid recompilation when changes are only made to
+method bodies or private members of a class.
+
+Note: Using `--use_ijars` might give you a different
+error message when you are accidentally referring to a non visible
+member of another class: Instead of getting an error that the member
+is not visible you will get an error that the member does not exist.
+Changing the `--use_ijars` setting will force a recompilation of all affected
+classes.
+
+#### `--[no]interface_shared_objects` {:#interface-shared-objects}
+
+This option enables _interface shared objects_, which makes binaries and
+other shared libraries depend on the _interface_ of a shared object,
+rather than its implementation. When only the implementation changes, Bazel
+can avoid rebuilding targets that depend on the changed shared library
+unnecessarily.
+
+### Output selection {:#output-selection}
+
+These options determine what to build or test.
+
+#### `--[no]build` {:#build}
+
+This option causes the execution phase of the build to occur; it is
+on by default. When it is switched off, the execution phase is
+skipped, and only the first two phases, loading and analysis, occur.
+
+This option can be useful for validating BUILD files and detecting
+errors in the inputs, without actually building anything.
+
+#### `--[no]build_tests_only` {:#build-tests-only}
+
+If specified, Bazel will build only what is necessary to run the `*_test`
+and `test_suite` rules that were not filtered due to their
+[size](#test-size-filters),
+[timeout](#test-timeout-filters),
+[tag](#test-tag-filters), or
+[language](#test-lang-filters).
+If specified, Bazel will ignore other targets specified on the command line.
+By default, this option is disabled and Bazel will build everything
+requested, including `*_test` and `test_suite` rules that are filtered out from
+testing. This is useful because running
+`bazel test --build_tests_only foo/...` may not detect all build
+breakages in the `foo` tree.
+
+#### `--[no]check_up_to_date` {:#check-up-to-date}
+
+This option causes Bazel not to perform a build, but merely check
+whether all specified targets are up-to-date. If so, the build
+completes successfully, as usual. However, if any files are out of
+date, instead of being built, an error is reported and the build
+fails. This option may be useful to determine whether a build has
+been performed more recently than a source edit (for example, for pre-submit
+checks) without incurring the cost of a build.
+
+See also [`--check_tests_up_to_date`](#check-tests-up-to-date).
+
+#### `--[no]compile_one_dependency` {:#compile-one-dependency}
+
+Compile a single dependency of the argument files. This is useful for
+syntax checking source files in IDEs, for example, by rebuilding a single
+target that depends on the source file to detect errors as early as
+possible in the edit/build/test cycle. This argument affects the way all
+non-flag arguments are interpreted: each argument must be a
+file target label or a plain filename relative to the current working
+directory, and one rule that depends on each source filename is built. For
+C++ and Java
+sources, rules in the same language space are preferentially chosen. For
+multiple rules with the same preference, the one that appears first in the
+BUILD file is chosen. An explicitly named target pattern which does not
+reference a source file results in an error.
+
+#### `--save_temps` {:#save-temps}
+
+The `--save_temps` option causes temporary outputs from the compiler to be
+saved. These include .s files (assembler code), .i (preprocessed C) and .ii
+(preprocessed C++) files. These outputs are often useful for debugging. Temps will only be
+generated for the set of targets specified on the command line.
+
+Note: The implementation of `--save_temps` does not use the compiler's
+`-save-temps` flag. Instead, there are two passes, one with `-S`
+and one with `-E`. A consequence of this is that if your build fails,
+Bazel may not yet have produced the ".i" or ".ii" and ".s" files.
+If you're trying to use `--save_temps` to debug a failed compilation,
+you may need to also use `--keep_going` so that Bazel will still try to
+produce the preprocessed files after the compilation fails.
+
+The `--save_temps` flag currently works only for cc_* rules.
+
+To ensure that Bazel prints the location of the additional output files, check that
+your [`--show_result {{ "" }}n{{ "" }}`](#show-result)
+setting is high enough.
+
+#### `--build_tag_filters={{ "" }}tag[,tag]*{{ "" }}` {:#build-tag-filters}
+
+If specified, Bazel will build only targets that have at least one required tag
+(if any of them are specified) and does not have any excluded tags. Build tag
+filter is specified as comma delimited list of tag keywords, optionally
+preceded with '-' sign used to denote excluded tags. Required tags may also
+have a preceding '+' sign.
+
+When running tests, Bazel ignores `--build_tag_filters` for test targets,
+which are built and run even if they do not match this filter. To avoid building them, filter
+test targets using `--test_tag_filters` or by explicitly excluding them.
+
+#### `--test_size_filters={{ "" }}size[,size]*{{ "" }}` {:#test-size-filters}
+
+If specified, Bazel will test (or build if `--build_tests_only`
+is also specified) only test targets with the given size. Test size filter
+is specified as comma delimited list of allowed test size values (small,
+medium, large or enormous), optionally preceded with '-' sign used to denote
+excluded test sizes. For example,
+
+
+  % bazel test --test_size_filters=small,medium //foo:all
+

+
+and
+
+
+  % bazel test --test_size_filters=-large,-enormous //foo:all
+

+
+will test only small and medium tests inside //foo.
+
+By default, test size filtering is not applied.
+
+#### `--test_timeout_filters={{ "" }}timeout[,timeout]*{{ "" }}` {:#test-timeout-filters}
+
+If specified, Bazel will test (or build if `--build_tests_only`
+is also specified) only test targets with the given timeout. Test timeout filter
+is specified as comma delimited list of allowed test timeout values (short,
+moderate, long or eternal), optionally preceded with '-' sign used to denote
+excluded test timeouts. See [--test_size_filters](#test-size-filters)
+for example syntax.
+
+By default, test timeout filtering is not applied.
+
+#### `--test_tag_filters={{ "" }}tag[,tag]*{{ "" }}` {:#test-tag-filters}
+
+If specified, Bazel will test (or build if `--build_tests_only`
+is also specified) only test targets that have at least one required tag
+(if any of them are specified) and does not have any excluded tags. Test tag
+filter is specified as comma delimited list of tag keywords, optionally
+preceded with '-' sign used to denote excluded tags. Required tags may also
+have a preceding '+' sign.
+
+For example,
+
+
+  % bazel test --test_tag_filters=performance,stress,-flaky //myproject:all
+

+
+will test targets that are tagged with either `performance` or
+`stress` tag but are **not** tagged with the `flaky` tag.
+
+By default, test tag filtering is not applied. Note that you can also filter
+on test's `size` and `local` tags in
+this manner.
+
+#### `--test_lang_filters={{ "" }}string[,string]*{{ "" }}` {:#test-lang-filters}
+
+Specifies a comma-separated list of strings referring to names of test rule
+classes. To refer to the rule class `foo_test`, use the string "foo". Bazel will
+test (or build if `--build_tests_only` is also specified) only
+targets of the referenced rule classes. To instead exclude those targets, use
+the string "-foo". For example,
+
+

+
+  % bazel test --test_lang_filters=foo,bar //baz/...
+

+

+  will test only targets that are instances of `foo_test` or `bar_test` in
+  `//baz/...`, while
+

+
+  % bazel test --test_lang_filters=-foo,-bar //baz/...
+

+

+  will test all the targets in `//baz/...` except for the `foo_test` and
+  `bar_test` instances.
+

+
+Tip: You can use `bazel query --output=label_kind "//p:t"` to
+learn the rule class name of the target `//p:t`. And you can
+look at the pair of instantiation stacks in the output of
+`bazel query --output=build "//p:t"` to learn why that target
+is an instance of that rule class.
+
+Warning: The option name "--test_lang_filter" is vestigal and is therefore
+unfortunately misleading; don't make assumptions about the semantics based on
+the name.
+
+#### `--test_filter={{ "" }}filter-expression{{ "" }}` {:#test-filter}
+
+Specifies a filter that the test runner may use to pick a subset of tests for
+running. All targets specified in the invocation are built, but depending on
+the expression only some of them may be executed; in some cases, only certain
+test methods are run.
+
+The particular interpretation of {{ "" }}filter-expression{{ "" }} is up to
+the test framework responsible for running the test. It may be a glob,
+substring, or regexp. `--test_filter` is a convenience
+over passing different `--test_arg` filter arguments,
+but not all frameworks support it.
+
+### Verbosity {:#verbosity}
+
+These options control the verbosity of Bazel's output,
+either to the terminal, or to additional log files.
+
+#### `--explain={{ "" }}logfile{{ "" }}` {:#explain}
+
+This option, which requires a filename argument, causes the
+dependency checker in `bazel build`'s execution phase to
+explain, for each build step, either why it is being executed, or
+that it is up-to-date. The explanation is written
+to _logfile_.
+
+If you are encountering unexpected rebuilds, this option can help to
+understand the reason. Add it to your `.bazelrc` so that
+logging occurs for all subsequent builds, and then inspect the log
+when you see an execution step executed unexpectedly. This option
+may carry a small performance penalty, so you might want to remove
+it when it is no longer needed.
+
+#### `--verbose_explanations` {:#verbose-explanations}
+
+This option increases the verbosity of the explanations generated
+when the [--explain](#explain) option is enabled.
+
+In particular, if verbose explanations are enabled,
+and an output file is rebuilt because the command used to
+build it has changed, then the output in the explanation file will
+include the full details of the new command (at least for most
+commands).
+
+Using this option may significantly increase the length of the
+generated explanation file and the performance penalty of using
+`--explain`.
+
+If `--explain` is not enabled, then
+`--verbose_explanations` has no effect.
+
+#### `--profile={{ "" }}file{{ "" }}` {:#profile}
+
+This option, which takes a filename argument, causes Bazel to write
+profiling data into a file. The data then can be analyzed or parsed using the
+`bazel analyze-profile` command. The Build profile can be useful in
+understanding where Bazel's `build` command is spending its time.
+
+#### `--[no]show_loading_progress` {:#show-loading-progress}
+
+This option causes Bazel to output package-loading progress
+messages. If it is disabled, the messages won't be shown.
+
+#### `--[no]show_progress` {:#show-progress}
+
+This option causes progress messages to be displayed; it is on by
+default. When disabled, progress messages are suppressed.
+
+#### `--show_progress_rate_limit={{ "" }}n{{ "" }}` {:#show-progress-rate}
+
+This option causes bazel to display at most one progress message per `n` seconds,
+where {{ "" }}n{{ "" }} is a real number.
+The default value for this option is 0.02, meaning bazel will limit the progress
+messages to one per every 0.02 seconds.
+
+#### `--show_result={{ "" }}n{{ "" }}` {:#show-result}
+
+This option controls the printing of result information at the end
+of a `bazel build` command. By default, if a single
+build target was specified, Bazel prints a message stating whether
+or not the target was successfully brought up-to-date, and if so,
+the list of output files that the target created. If multiple
+targets were specified, result information is not displayed.
+
+While the result information may be useful for builds of a single
+target or a few targets, for large builds (such as an entire top-level
+project tree), this information can be overwhelming and distracting;
+this option allows it to be controlled. `--show_result`
+takes an integer argument, which is the maximum number of targets
+for which full result information should be printed. By default,
+the value is 1. Above this threshold, no result information is
+shown for individual targets. Thus zero causes the result
+information to be suppressed always, and a very large value causes
+the result to be printed always.
+
+Users may wish to choose a value in-between if they regularly
+alternate between building a small group of targets (for example,
+during the compile-edit-test cycle) and a large group of targets
+(for example, when establishing a new workspace or running
+regression tests). In the former case, the result information is
+very useful whereas in the latter case it is less so. As with all
+options, this can be specified implicitly via
+the [`.bazelrc`](/versions/9.1.0/run/bazelrc) file.
+
+The files are printed so as to make it easy to copy and paste the
+filename to the shell, to run built executables. The "up-to-date"
+or "failed" messages for each target can be easily parsed by scripts
+which drive a build.
+
+#### `--sandbox_debug` {:#sandbox-debug}
+
+This option causes Bazel to print extra debugging information when using sandboxing for action
+execution. This option also preserves sandbox directories, so that the files visible to actions
+during execution can be examined.
+
+#### `--subcommands` (`-s`) {:#subcommands}
+
+This option causes Bazel's execution phase to print the full command line
+for each command prior to executing it.
+
+
+  >>>>> # //examples/cpp:hello-world [action 'Linking examples/cpp/hello-world']
+  (cd /home/johndoe/.cache/bazel/_bazel_johndoe/4c084335afceb392cfbe7c31afee3a9f/bazel && \
+    exec env - \
+    /usr/bin/gcc -o bazel-out/local-fastbuild/bin/examples/cpp/hello-world -B/usr/bin/ -Wl,-z,relro,-z,now -no-canonical-prefixes -pass-exit-codes -Wl,-S -Wl,@bazel-out/local_linux-fastbuild/bin/examples/cpp/hello-world-2.params)
+

+
+Where possible, commands are printed in a Bourne shell compatible syntax,
+so that they can be easily copied and pasted to a shell command prompt.
+(The surrounding parentheses are provided to protect your shell from the
+`cd` and `exec` calls; be sure to copy them!)
+However some commands are implemented internally within Bazel, such as
+creating symlink trees. For these there's no command line to display.
+
+`--subcommands=pretty_print` may be passed to print
+the arguments of the command as a list rather than as a single line. This may
+help make long command lines more readable.
+
+See also [--verbose_failures](#verbose-failures), below.
+
+For logging subcommands to a file in a tool-friendly format, see
+[--execution_log_json_file](/versions/9.1.0/reference/command-line-reference#flag--execution_log_json_file)
+and
+[--execution_log_binary_file](/versions/9.1.0/reference/command-line-reference#flag--execution_log_binary_file).
+
+#### `--verbose_failures` {:#verbose-failures}
+
+This option causes Bazel's execution phase to print the full command line
+for commands that failed. This can be invaluable for debugging a
+failing build.
+
+Failing commands are printed in a Bourne shell compatible syntax, suitable
+for copying and pasting to a shell prompt.
+
+### Workspace status {:#workspace-status}
+
+Use these options to "stamp" Bazel-built binaries: to embed additional information into the
+binaries, such as the source control revision or other workspace-related information. You can use
+this mechanism with rules that support the `stamp` attribute, such as
+`genrule`, `cc_binary`, and more.
+
+#### `--workspace_status_command={{ "" }}program{{ "" }}` {:#workspace-status-command}
+
+This flag lets you specify a binary that Bazel runs before each build. The program can report
+information about the status of the workspace, such as the current source control revision.
+
+The flag's value must be a path to a native program. On Linux/macOS this may be any executable.
+On Windows this must be a native binary, typically an ".exe", ".bat", or a ".cmd" file.
+
+The program should print zero or more key/value pairs to standard output, one entry on each line,
+then exit with zero (otherwise the build fails). The key names can be anything but they may only
+use upper case letters and underscores. The first space after the key name separates it from the
+value. The value is the rest of the line (including additional whitespaces). Neither the key nor
+the value may span multiple lines. Keys must not be duplicated.
+
+Bazel partitions the keys into two buckets: "stable" and "volatile". (The names "stable" and
+"volatile" are a bit counter-intuitive, so don't think much about them.)
+
+Bazel then writes the key-value pairs into two files:
+
+*   `bazel-out/stable-status.txt`
+    contains all keys and values where the key's name starts with `STABLE_`
+*   `bazel-out/volatile-status.txt`
+    contains the rest of the keys and their values
+
+The contract is:
+
+*   "stable" keys' values should change rarely, if possible. If the contents of
+    `bazel-out/stable-status.txt`
+      change, Bazel invalidates the actions that depend on them. In
+      other words, if a stable key's value changes, Bazel will rerun stamped actions.
+      Therefore the stable status should not contain things like timestamps, because they change all
+      the time, and would make Bazel rerun stamped actions with each build.
+
+    Bazel always outputs the following stable keys:
+    *   `BUILD_EMBED_LABEL`: value of `--embed_label`
+    *   `BUILD_HOST`: the name of the host machine that Bazel is running on
+    *   `BUILD_USER`: the name of the user that Bazel is running as
+*   "volatile" keys' values may change often. Bazel expects them to change all the time, like
+      timestamps do, and duly updates the
+    `bazel-out/volatile-status.txt`
+      file. In order to avoid
+      rerunning stamped actions all the time though, **Bazel pretends that the volatile file never
+      changes**. In other words, if the volatile status file is the only file whose contents has
+      changed, Bazel will not invalidate actions that depend on it. If other inputs of the actions
+      have changed, then Bazel reruns that action, and the action will see the updated volatile
+      status, but just the volatile status changing alone will not invalidate the action.
+
+    Bazel always outputs the following volatile keys:
+      *   `BUILD_TIMESTAMP`: time of the build in seconds since the Unix Epoch (the value
+        of `System.currentTimeMillis()` divided by a thousand)
+      *   `FORMATTED_DATE`: time of the build Formatted as
+        `yyyy MMM d HH mm ss EEE`(for example 2023 Jun 2 01 44 29 Fri) in UTC.
+
+On Linux/macOS you can pass `--workspace_status_command=/bin/true` to
+disable retrieving workspace status, because `true` does nothing, successfully (exits
+with zero) and prints no output. On Windows you can pass the path of MSYS's `true.exe`
+for the same effect.
+
+If the workspace status command fails (exits non-zero) for any reason, the build will fail.
+
+Example program on Linux using Git:
+
+
+#!/bin/bash
+echo "CURRENT_TIME $(date +%s)"
+echo "RANDOM_HASH $(cat /proc/sys/kernel/random/uuid)"
+echo "STABLE_GIT_COMMIT $(git rev-parse HEAD)"
+echo "STABLE_USER_NAME $USER"
+

+
+Pass this program's path with `--workspace_status_command`, and the stable status file
+will include the STABLE lines and the volatile status file will include the rest of the lines.
+
+#### `--[no]stamp` {:#stamp}
+
+This option, in conjunction with the `stamp` rule attribute, controls whether to
+embed build information in binaries.
+
+Stamping can be enabled or disabled explicitly on a per-rule basis using the
+`stamp` attribute. Please refer to the Build Encyclopedia for details. When
+a rule sets `stamp = -1` (the default for `*_binary` rules), this option
+determines whether stamping is enabled.
+
+Bazel never stamps binaries that are built for the exec configuration,
+regardless of this option or the `stamp` attribute. For rules that set `stamp =
+0` (the default for `*_test` rules), stamping is disabled regardless of
+`--[no]stamp`. Specifying `--stamp` does not force targets to be rebuilt if
+their dependencies have not changed.
+
+Setting `--nostamp` is generally desireable for build performance, as it
+reduces input volatility and maximizes build caching.
+
+### Platform {:#platform}
+
+Use these options to control the host and target platforms that configure how builds work, and to
+control what execution platforms and toolchains are available to Bazel rules.
+
+Please see background information on [Platforms](/versions/9.1.0/extending/platforms) and [Toolchains](/versions/9.1.0/extending/toolchains).
+
+#### `--platforms={{ "" }}labels{{ "" }}` {:#platforms}
+
+The labels of the platform rules describing the target platforms for the
+current command.
+
+#### `--host_platform={{ "" }}label{{ "" }}` {:#host-platform}
+
+The label of a platform rule that describes the host system.
+
+#### `--extra_execution_platforms={{ "" }}labels{{ "" }}` {:#extra-execution-platforms}
+
+The platforms that are available as execution platforms to run actions.
+Platforms can be specified by exact target, or as a target pattern. These
+platforms will be considered before those declared in MODULE.bazel files by
+[register_execution_platforms()](/versions/9.1.0/rules/lib/globals/module#register_execution_platforms).
+This option accepts a comma-separated list of platforms in order of priority.
+If the flag is passed multiple times, the most recent overrides.
+
+#### `--extra_toolchains={{ "" }}labels{{ "" }}` {:#extra-toolchains}
+
+The toolchain rules to be considered during toolchain resolution. Toolchains
+can be specified by exact target, or as a target pattern. These toolchains will
+be considered before those declared in MODULE.bazel files by
+[register_toolchains()](/versions/9.1.0/rules/lib/globals/module#register_toolchains).
+
+#### `--toolchain_resolution_debug={{ "" }}regex{{ "" }}` {:#toolchain-resolution-debug}
+
+Print debug information while finding toolchains if the toolchain type matches
+the regex. Multiple regexes can be separated by commas. The regex can be
+negated by using a `-` at the beginning. This might help developers
+of Bazel or Starlark rules with debugging failures due to missing toolchains.
+
+### Miscellaneous {:#miscellaneous}
+
+#### `--flag_alias={{ "" }}alias_name=target_path{{ "" }}` {:#flag-alias}
+
+A convenience flag used to bind longer Starlark build settings to a shorter name. For more
+details, see the
+[Starlark Configurations](/versions/9.1.0/extending/config#using-build-setting-aliases).
+
+#### `--symlink_prefix={{ "" }}string{{ "" }}` {:#symlink-prefix}
+
+Changes the prefix of the generated convenience symlinks. The
+default value for the symlink prefix is `bazel-` which
+will create the symlinks `bazel-bin`, `bazel-testlogs`, and
+`bazel-genfiles`.
+
+If the symbolic links cannot be created for any reason, a warning is
+issued but the build is still considered a success. In particular,
+this allows you to build in a read-only directory or one that you have no
+permission to write into. Any paths printed in informational
+messages at the conclusion of a build will only use the
+symlink-relative short form if the symlinks point to the expected
+location; in other words, you can rely on the correctness of those
+paths, even if you cannot rely on the symlinks being created.
+
+Some common values of this option:
+
+*   **Suppress symlink creation:**
+      `--symlink_prefix=/` will cause Bazel to not
+      create or update any symlinks, including the `bazel-out` and
+      `bazel-`
+      symlinks. Use this option to suppress symlink creation entirely.
+
+*   **Reduce clutter:**
+      `--symlink_prefix=.bazel/` will cause Bazel to create
+      symlinks called `bin` (etc) inside a hidden directory `.bazel`.
+
+#### `--platform_suffix={{ "" }}string{{ "" }}` {:#platform-suffix}
+
+Adds a suffix to the configuration short name, which is used to determine the
+output directory. Setting this option to different values puts the files into
+different directories, for example to improve cache hit rates for builds that
+otherwise clobber each others output files, or to keep the output files around
+for comparisons.
+
+#### `--default_visibility={{ "" }}(private|public){{ "" }}` {:#default-visibility}
+
+Temporary flag for testing bazel default visibility changes. Not intended for general use
+but documented for completeness' sake.
+
+#### `--starlark_cpu_profile=_file_` {:#starlark-cpu-profile}
+
+This flag, whose value is the name of a file, causes Bazel to gather
+statistics about CPU usage by all Starlark threads,
+and write the profile, in [pprof](https://github.com/google/pprof){: .external} format,
+to the named file.
+
+Use this option to help identify Starlark functions that
+make loading and analysis slow due to excessive computation. For example:
+
+
+$ bazel build --nobuild --starlark_cpu_profile=/tmp/pprof.gz my/project/...
+$ pprof /tmp/pprof.gz
+(pprof) top
+Type: CPU
+Time: Feb 6, 2020 at 12:06pm (PST)
+Duration: 5.26s, Total samples = 3.34s (63.55%)
+Showing nodes accounting for 3.34s, 100% of 3.34s total
+      flat  flat%   sum%        cum   cum%
+     1.86s 55.69% 55.69%      1.86s 55.69%  sort_source_files
+     1.02s 30.54% 86.23%      1.02s 30.54%  expand_all_combinations
+     0.44s 13.17% 99.40%      0.44s 13.17%  range
+     0.02s   0.6%   100%      3.34s   100%  sorted
+         0     0%   100%      1.38s 41.32%  my/project/main/BUILD
+         0     0%   100%      1.96s 58.68%  my/project/library.bzl
+         0     0%   100%      3.34s   100%  main
+

+
+For different views of the same data, try the `pprof` commands `svg`,
+`web`, and `list`.
+
+## Using Bazel for releases {:#bazel-for-releases}
+
+Bazel is used both by software engineers during the development
+cycle, and by release engineers when preparing binaries for deployment
+to production. This section provides a list of tips for release
+engineers using Bazel.
+
+### Significant options {:#significant-options}
+
+When using Bazel for release builds, the same issues arise as for other scripts
+that perform a build. For more details, see
+[Call Bazel from scripts](/versions/9.1.0/run/scripts). In particular, the following options
+are strongly recommended:
+
+*   [`--bazelrc=/dev/null`](/versions/9.1.0/run/bazelrc)
+*   [`--nokeep_state_after_build`](/versions/9.1.0/reference/command-line-reference#common_options-flag--keep_state_after_build)
+
+These options are also important:
+
+*   [`--package_path`](#package-path)
+*   [`--symlink_prefix`](#symlink-prefix):
+    for managing builds for multiple configurations,
+    it may be convenient to distinguish each build
+    with a distinct identifier, such as "64bit" vs. "32bit". This option
+    differentiates the `bazel-bin` (etc.) symlinks.
+
+## Running tests {:#running-tests}
+
+To build and run tests with bazel, type `bazel test` followed by
+the name of the test targets.
+
+By default, this command performs simultaneous build and test
+activity, building all specified targets (including any non-test
+targets specified on the command line) and testing
+`*_test` and `test_suite` targets as soon as
+their prerequisites are built, meaning that test execution is
+interleaved with building. Doing so usually results in significant
+speed gains.
+
+### Options for `bazel test` {:#bazel-test-options}
+
+#### `--cache_test_results=(yes|no|auto)` (`-t`) {:#cache-test-results}
+
+If this option is set to 'auto' (the default) then Bazel will only rerun a test if any of the
+following conditions applies:
+
+*   Bazel detects changes in the test or its dependencies
+*   the test is marked as `external`
+*   multiple test runs were requested with `--runs_per_test`
+*   the test failed.
+
+If 'no', all tests will be executed unconditionally.
+
+If 'yes', the caching behavior will be the same as auto
+except that it may cache test failures and test runs with
+`--runs_per_test`.
+
+Note: Test results are _always_ saved in Bazel's output tree,
+regardless of whether this option is enabled, so
+you needn't have used `--cache_test_results` on the
+prior run(s) of `bazel test` in order to get cache hits.
+The option only affects whether Bazel will _use_ previously
+saved results, not whether it will save results of the current run.
+
+Users who have enabled this option by default in
+their `.bazelrc` file may find the
+abbreviations `-t` (on) or `-t-` (off)
+convenient for overriding the default on a particular run.
+
+#### `--check_tests_up_to_date` {:#check-tests-up-to-date}
+
+This option tells Bazel not to run the tests, but to merely check and report
+the cached test results. If there are any tests which have not been
+previously built and run, or whose tests results are out-of-date (for example, because
+the source code or the build options have changed), then Bazel will report
+an error message ("test result is not up-to-date"), will record the test's
+status as "NO STATUS" (in red, if color output is enabled), and will return
+a non-zero exit code.
+
+This option also implies
+[`--check_up_to_date`](#check-up-to-date) behavior.
+
+This option may be useful for pre-submit checks.
+
+#### `--test_verbose_timeout_warnings` {:#test-verbose-timeout-warnings}
+
+This option tells Bazel to explicitly warn the user if a test's timeout is
+significantly longer than the test's actual execution time. While a test's
+timeout should be set such that it is not flaky, a test that has a highly
+over-generous timeout can hide real problems that crop up unexpectedly.
+
+For instance, a test that normally executes in a minute or two should not have
+a timeout of ETERNAL or LONG as these are much, much too generous.
+
+This option is useful to help users decide on a good timeout value or
+sanity check existing timeout values.
+
+Note: Each test shard is allotted the timeout of the entire
+`XX_test` target. Using this option does not affect a test's timeout
+value, merely warns if Bazel thinks the timeout could be restricted further.
+
+#### `--[no]test_keep_going` {:#test-keep-going}
+
+By default, all tests are run to completion. If this flag is disabled,
+however, the build is aborted on any non-passing test. Subsequent build steps
+and test invocations are not run, and in-flight invocations are canceled.
+Do not specify both `--notest_keep_going` and `--keep_going`.
+
+#### `--flaky_test_attempts={{ "" }}attempts{{ "" }}` {:#flaky-test-attempts}
+
+This option specifies the maximum number of times a test should be attempted
+if it fails for any reason. A test that initially fails but eventually
+succeeds is reported as `FLAKY` on the test summary. It is,
+however, considered to be passed when it comes to identifying Bazel exit code
+or total number of passed tests. Tests that fail all allowed attempts are
+considered to be failed.
+
+By default (when this option is not specified, or when it is set to
+default), only a single attempt is allowed for regular tests, and
+3 for test rules with the `flaky` attribute set. You can specify
+an integer value to override the maximum limit of test attempts. Bazel allows
+a maximum of 10 test attempts in order to prevent abuse of the system.
+
+#### `--runs_per_test={{ "" }}[regex@]number{{ "" }}` {:#runs-per-test}
+
+This option specifies the number of times each test should be executed. All
+test executions are treated as separate tests (fallback functionality
+will apply to each of them independently).
+
+The status of a target with failing runs depends on the value of the
+`--runs_per_test_detects_flakes` flag:
+
+*  If absent, any failing run causes the entire test to fail.
+*  If present and two runs from the same shard return PASS and FAIL, the test
+   will receive a status of flaky (unless other failing runs cause it to
+   fail).
+
+If a single number is specified, all tests will run that many times.
+Alternatively, a regular expression may be specified using the syntax
+regex@number. This constrains the effect of `--runs_per_test` to targets
+which match the regex (`--runs_per_test=^//pizza:.*@4` runs all tests
+under `//pizza/` 4 times).
+This form of `--runs_per_test` may be specified more than once.
+
+#### `--[no]runs_per_test_detects_flakes` {:#run-per-test-detects-flakes}
+
+If this option is specified (by default it is not), Bazel will detect flaky
+test shards through `--runs_per_test`. If one or more runs for a single shard
+fail and one or more runs for the same shard pass, the target will be
+considered flaky with the flag. If unspecified, the target will report a
+failing status.
+
+#### `--test_summary={{ "" }}output_style{{ "" }}` {:#test-summary}
+
+Specifies how the test result summary should be displayed.
+
+*   `short` prints the results of each test along with the name of
+    the file containing the test output if the test failed. This is the default
+    value.
+*   `terse` like `short`, but even shorter: only print
+    information about tests which did not pass.
+*   `detailed` prints each individual test case that failed, not
+    only each test. The names of test output files are omitted.
+*   `none` does not print test summary.
+
+#### `--test_output={{ "" }}output_style{{ "" }}` {:#test-output}
+
+Specifies how test output should be displayed:
+
+*   `summary` shows a summary of whether each test passed or
+    failed. Also shows the output log file name for failed tests. The summary
+    will be printed at the end of the build (during the build, one would see
+    just simple progress messages when tests start, pass or fail).
+    This is the default behavior.
+*   `errors` sends combined stdout/stderr output from failed tests
+    only into the stdout immediately after test is completed, ensuring that
+    test output from simultaneous tests is not interleaved with each other.
+    Prints a summary at the build as per summary output above.
+*   `all` is similar to `errors` but prints output for
+    all tests, including those which passed.
+*   `streamed` streams stdout/stderr output from each test in
+    real-time.
+
+#### `--java_debug` {:#java-debug}
+
+This option causes the Java virtual machine of a java test to wait for a connection from a
+JDWP-compliant debugger before starting the test. This option implies `--test_output=streamed`.
+
+#### `--[no]verbose_test_summary` {:#verbose-test-summary}
+
+By default this option is enabled, causing test times and other additional
+information (such as test attempts) to be printed to the test summary. If
+`--noverbose_test_summary` is specified, test summary will
+include only test name, test status and cached test indicator and will
+be formatted to stay within 80 characters when possible.
+
+#### `--test_tmpdir={{ "" }}path{{ "" }}` {:#test-tmpdir}
+
+Specifies temporary directory for tests executed locally. Each test will be
+executed in a separate subdirectory inside this directory. The directory will
+be cleaned at the beginning of the each `bazel test` command.
+By default, bazel will place this directory under Bazel output base directory.
+
+Note: This is a directory for running tests, not storing test results
+(those are always stored under the `bazel-out` directory).
+
+#### `--test_timeout={{ "" }}seconds{{ "" }}` OR `--test_timeout={{ "" }}seconds{{ "" }},{{ "" }}seconds{{ "" }},{{ "" }}seconds{{ "" }},{{ "" }}seconds{{ "" }}` {:#test-timeout}
+
+Overrides the timeout value for all tests by using specified number of
+seconds as a new timeout value. If only one value is provided, then it will
+be used for all test timeout categories.
+
+Alternatively, four comma-separated values may be provided, specifying
+individual timeouts for short, moderate, long and eternal tests (in that
+order).
+In either form, zero or a negative value for any of the test sizes will
+be substituted by the default timeout for the given timeout categories as
+defined by the page [Writing Tests](/versions/9.1.0/reference/test-encyclopedia).
+By default, Bazel will use these timeouts for all tests by
+inferring the timeout limit from the test's size whether the size is
+implicitly or explicitly set.
+
+Tests which explicitly state their timeout category as distinct from their
+size will receive the same value as if that timeout had been implicitly set by
+the size tag. So a test of size 'small' which declares a 'long' timeout will
+have the same effective timeout that a 'large' tests has with no explicit
+timeout.
+
+#### `--test_arg={{ "" }}arg{{ "" }}` {:#test-arg}
+
+Passes command-line options/flags/arguments to each test process. This
+option can be used multiple times to pass several arguments. For example,
+`--test_arg=--logtostderr --test_arg=--v=3`.
+
+Note that, unlike the `bazel run` command, you can't pass test arguments
+directly as in `bazel test -- target --logtostderr --v=3`. That's because
+extraneous arguments passed to `bazel test` are interpreted as additional test
+targets. That is, `--logtostderr` and `--v=3` would each be interpreted as a
+test target. This ambiguity doesn't exist for a `bazel run` command, which only
+accepts one target.
+
+`--test_arg` can be passed to a `bazel run` command, but it's ignored unless the
+target being run is a test target. (As with any other flag, if it's passed in a
+`bazel run` command after a `--` token, it's not processed by Bazel but
+forwarded verbatim to the executed target.)
+
+#### `--test_env={{ "" }}variable{{ "" }}=_value_` OR `--test_env={{ "" }}variable{{ "" }}` {:#test-env}
+
+Specifies additional variables that must be injected into the test
+environment for each test. If {{ "" }}value{{ "" }} is not specified it will be
+inherited from the shell environment used to start the `bazel test`
+command.
+
+The environment can be accessed from within a test by using
+`System.getenv("var")` (Java), `getenv("var")` (C or C++),
+
+#### `--run_under={{ "" }}command-prefix{{ "" }}` {:#test-run-under}
+
+This specifies a prefix that the test runner will insert in front
+of the test command before running it. The
+{{ "" }}command-prefix{{ "" }} is split into words using Bourne shell
+tokenization rules, and then the list of words is prepended to the
+command that will be executed.
+
+If the first word is a fully-qualified label (starts with
+`//`) it is built. Then the label is substituted by the
+corresponding executable location that is prepended to the command
+that will be executed along with the other words.
+
+Some caveats apply:
+
+*   The PATH used for running tests may be different than the PATH in your environment,
+    so you may need to use an **absolute path** for the `--run_under`
+    command (the first word in {{ "" }}command-prefix{{ "" }}).
+*   **`stdin` is not connected**, so `--run_under`
+    can't be used for interactive commands.
+
+Examples:
+
+
+        --run_under=/usr/bin/strace
+        --run_under='/usr/bin/strace -c'
+        --run_under=/usr/bin/valgrind
+        --run_under='/usr/bin/valgrind --quiet --num-callers=20'
+

+
+#### Test selection {:#test-selection}
+
+As documented under [Output selection options](#output-selection),
+you can filter tests by [size](#test-size-filters),
+[timeout](#test-timeout-filters),
+[tag](#test-tag-filters), or
+[language](#test-lang-filters). A convenience
+[general name filter](#test-filter) can forward particular
+filter args to the test runner.
+
+#### Other options for `bazel test` {:#bazel-test-other-options}
+
+The syntax and the remaining options are exactly like
+[`bazel build`](/versions/9.1.0/run/build).
+
+## Running executables {:#running-executables}
+
+The `bazel run` command is similar to `bazel build`, except
+it is used to build _and run_ a single target. Here is a typical session
+(`//java/myapp:myapp` says hello and prints out its args):
+
+
+  % bazel run java/myapp:myapp -- --arg1 --arg2
+  INFO: Analyzed target //java/myapp:myapp (13 packages loaded, 27 targets configured).
+  INFO: Found 1 target...
+  Target //java/myapp:myapp up-to-date:
+    bazel-bin/java/myapp/myapp
+  INFO: Elapsed time: 14.290s, Critical Path: 5.54s, ...
+  INFO: Build completed successfully, 4 total actions
+  INFO: Running command line: bazel-bin/java/myapp/myapp <args omitted>
+  Hello there
+  $EXEC_ROOT/java/myapp/myapp
+  --arg1
+  --arg2
+

+
+Note: `--` is needed so that Bazel
+does not interpret `--arg1` and `--arg2` as
+Bazel options, but rather as part of the command line for running the binary.
+Additionally, Bazel will avoid logging these arguments to the console in case
+they contain sensitive information.
+
+`bazel run` is similar, but not identical, to directly invoking
+the binary built by Bazel and its behavior is different depending on whether the
+binary to be invoked is a test or not.
+
+When the binary is not a test, the current working directory will be the
+runfiles tree of the binary.
+
+When the binary is a test, the current working directory will be the exec root
+and a good-faith attempt is made to replicate the environment tests are usually
+run in. The emulation is not perfect, though, and tests that have multiple
+shards cannot be run this way (the
+`--test_sharding_strategy=disabled` command line option can be used
+to work around this)
+
+The following extra environment variables are also available to the binary:
+
+*   `BUILD_WORKSPACE_DIRECTORY`: the root of the workspace where the
+    build was run.
+*   `BUILD_WORKING_DIRECTORY`: the current working directory where
+    Bazel was run from.
+*   `BUILD_ID`: the build ID of the `bazel run` invocation. This is usually
+    unique, except if Bazel was run with `--script_path` and the resulting
+    script is re-used.
+*   `BUILD_EXECROOT`: the execution root of the `bazel run` invocation.
+
+These can be used, for example, to interpret file names on the command line in
+a user-friendly way.
+
+### Options for `bazel run` {:#bazel-run-options}
+
+#### `--run_under={{ "" }}command-prefix{{ "" }}` {:#run-run-under}
+
+This has the same effect as the `--run_under` option for
+`bazel test` ([see above](#test-run-under)),
+except that it applies to the command being run by `bazel
+run` rather than to the tests being run by `bazel test`
+and cannot run under label.
+
+#### Filtering logging outputs from Bazel
+
+When invoking a binary with `bazel run`, Bazel prints logging output from Bazel
+itself and the binary under invocation. To make the logs less noisy, you can
+suppress the outputs from Bazel itself with the `--ui_event_filters` and
+`--noshow_progress` flags.
+
+For example:
+`bazel run --ui_event_filters=-info,-stdout,-stderr --noshow_progress //java/myapp:myapp`
+
+### Executing tests {:#executing-tests}
+
+`bazel run` can also execute test binaries, which has the effect of
+running the test in a close approximation of the environment described at
+[Writing Tests](/versions/9.1.0/reference/test-encyclopedia). Note that none of the
+`--test_*` arguments have an effect when running a test in this manner except
+`--test_arg` .
+
+## Cleaning build outputs {:#cleaning-build-outputs}
+
+### The `clean` command {:#clean}
+
+Bazel has a `clean` command, analogous to that of Make.
+It deletes the output directories for all build configurations performed
+by this Bazel instance, or the entire working tree created by this
+Bazel instance, and resets internal caches. If executed without any
+command-line options, then the output directory for all configurations
+will be cleaned.
+
+Recall that each Bazel instance is associated with a single workspace, thus the
+`clean` command will delete all outputs from all builds you've done
+with that Bazel instance in that workspace.
+
+To completely remove the entire working tree created by a Bazel
+instance,  you can specify the `--expunge` option. When
+executed with `--expunge`, the clean command simply
+removes the entire output base tree which, in addition to the build
+output, contains all temp files created by Bazel. It also
+stops the Bazel server after the clean, equivalent to the [`shutdown`](#shutdown) command. For example, to
+clean up all disk and memory traces of a Bazel instance, you could
+specify:
+
+
+  % bazel clean --expunge
+

+
+Alternatively, you can expunge in the background by using
+`--expunge_async`. It is safe to invoke a Bazel command
+in the same client while the asynchronous expunge continues to run.
+
+Note: This may introduce IO contention.
+
+The `clean` command is provided primarily as a means of
+reclaiming disk space for workspaces that are no longer needed.
+Bazel's incremental rebuilds may not be
+perfect so `clean` can be used to recover a consistent
+state when problems arise.
+
+Bazel's design is such that these problems are fixable and
+these bugs are a high priority to be fixed. If you
+ever find an incorrect incremental build, file a bug report, and report bugs in the tools
+rather than using `clean`.
+
+## Querying the dependency graph {:#querying-dependency-graph}
+
+Bazel includes a query language for asking questions about the
+dependency graph used during the build. The query language is used
+by two commands: query and cquery. The major difference between the
+two commands is that query runs after the [loading phase](/versions/9.1.0/run/build#loading)
+and cquery runs after the [analysis phase](/versions/9.1.0/run/build#analysis). These tools are an
+invaluable aid to many software engineering tasks.
+
+The query language is based on the idea of
+algebraic operations over graphs; it is documented in detail in
+
+[Bazel Query Reference](/versions/9.1.0/query/language).
+Please refer to that document for reference, for
+examples, and for query-specific command-line options.
+
+The query tool accepts several command-line
+option. `--output` selects the output format.
+`--[no]keep_going` (disabled by default) causes the query
+tool to continue to make progress upon errors; this behavior may be
+disabled if an incomplete result is not acceptable in case of errors.
+
+The `--[no]tool_deps` option,
+enabled by default, causes dependencies in non-target configurations to be included in the
+dependency graph over which the query operates.
+
+The `--[no]implicit_deps` option, enabled by default, causes
+implicit dependencies to be included in the dependency graph over which the query operates. An
+implicit dependency is one that is not explicitly specified in the BUILD file
+but added by bazel.
+
+Example: "Show the locations of the definitions (in BUILD files) of
+all genrules required to build all the tests in the PEBL tree."
+
+
+  bazel query --output location 'kind(genrule, deps(kind(".*_test rule", foo/bar/pebl/...)))'
+

+
+## Querying the action graph {:#aquery}
+
+Caution: The aquery command is still experimental and its API will change.
+
+The `aquery` command allows you to query for actions in your build graph.
+It operates on the post-analysis configured target graph and exposes
+information about actions, artifacts and their relationships.
+
+The tool accepts several command-line options.
+`--output` selects the output format. The default output format
+(`text`) is human-readable, use `proto` or `textproto` for
+machine-readable format.
+Notably, the aquery command runs on top of a regular Bazel build and inherits
+the set of options available during a build.
+
+It supports the same set of functions that is also available to traditional
+`query` but `siblings`, `buildfiles` and
+`tests`.
+
+For more details, see [Action Graph Query](/versions/9.1.0/query/aquery).
+
+## Miscellaneous commands and options {:#misc-commands-options}
+
+### `help` {:#help}
+
+The `help` command provides on-line help. By default, it
+shows a summary of available commands and help topics, as shown in
+[Building with Bazel](/versions/9.1.0/run/build#quickstart).
+Specifying an argument displays detailed help for a particular
+topic. Most topics are Bazel commands, such as `build`
+or `query`, but there are some additional help topics
+that do not correspond to commands.
+
+#### `--[no]long` (`-l`) {:#long}
+
+By default, `bazel help [{{ "" }}topic{{ "" }}]` prints only a
+summary of the relevant options for a topic. If
+the `--long` option is specified, the type, default value
+and full description of each option is also printed.
+
+### `shutdown` {:#shutdown}
+
+Bazel server processes may be stopped by using the `shutdown`
+command. This command causes the Bazel server to exit as soon as it
+becomes idle (for example, after the completion of any builds or other
+commands that are currently in progress). For more details, see
+[Client/server implementation](/versions/9.1.0/run/client-server).
+
+Bazel servers stop themselves after an idle timeout, so this command
+is rarely necessary; however, it can be useful in scripts when it is
+known that no further builds will occur in a given workspace.
+
+`shutdown` accepts one
+option, `--iff_heap_size_greater_than _n_`, which
+requires an integer argument (in MB). If specified, this makes the shutdown
+conditional on the amount of memory already consumed. This is
+useful for scripts that initiate a lot of builds, as any memory
+leaks in the Bazel server could cause it to crash spuriously on
+occasion; performing a conditional restart preempts this condition.
+
+### `info` {:#info}
+
+The `info` command prints various values associated with
+the Bazel server instance, or with a specific build configuration.
+(These may be used by scripts that drive a build.)
+
+The `info` command also permits a single (optional)
+argument, which is the name of one of the keys in the list below.
+In this case, `bazel info {{ "" }}key{{ "" }}` will print only
+the value for that one key. (This is especially convenient when
+scripting Bazel, as it avoids the need to pipe the result
+through `sed -ne /key:/s/key://p`:
+
+#### Configuration-independent data {:#configuration-independent-data}
+
+*   `release`: the release label for this Bazel
+    instance, or "development version" if this is not a released
+    binary.
+*   `workspace` the absolute path to the base workspace
+    directory.
+*   `install_base`: the absolute path to the installation
+    directory used by this Bazel instance for the current user. Bazel
+    installs its internally required executables below this directory.
+
+*   `output_base`: the absolute path to the base output
+    directory used by this Bazel instance for the current user and
+    workspace combination. Bazel puts all of its scratch and build
+    output below this directory.
+*   `execution_root`: the absolute path to the execution
+    root directory under output_base. This directory is the root for all files
+    accessible to commands executed during the build, and is the working
+    directory for those commands. If the workspace directory is writable, a
+    symlink named `bazel-`
+    is placed there pointing to this directory.
+*   `output_path`: the absolute path to the output
+    directory beneath the execution root used for all files actually
+    generated as a result of build commands. If the workspace directory is
+    writable, a symlink named `bazel-out` is placed there pointing
+    to this directory.
+*   `server_pid`: the process ID of the Bazel server
+     process.
+*   `server_log`: the absolute path to the Bazel server's debug log file.
+    This file contains debugging information for all commands over the lifetime of the
+    Bazel server, and is intended for human consumption by Bazel developers and power users.
+*   `command_log`: the absolute path to the command log file;
+    this contains the interleaved stdout and stderr streams of the most recent
+    Bazel command. Note that running `bazel info` will overwrite the
+    contents of this file, since it then becomes the most recent Bazel command.
+    However, the location of the command log file will not change unless you
+    change the setting of the `--output_base` or
+    `--output_user_root` options.
+*   `used-heap-size`,
+      `committed-heap-size`,
+      `max-heap-size`: reports various JVM heap size
+    parameters. Respectively: memory currently used, memory currently
+    guaranteed to be available to the JVM from the system, maximum
+    possible allocation.
+*   `gc-count`, `gc-time`: The cumulative count of
+    garbage collections since the start of this Bazel server and the time spent
+    to perform them. Note that these values are not reset at the start of every
+    build.
+*   `package_path`: A colon-separated list of paths which would be
+    searched for packages by bazel. Has the same format as the
+    `--package_path` build command line argument.
+
+Example: the process ID of the Bazel server.
+
+
% bazel info server_pid
+1285
+

+
+#### Configuration-specific data {:#configuration-specific-data}
+
+These data may be affected by the configuration options passed
+to `bazel info`, for
+example `--cpu`, `--compilation_mode`,
+etc. The `info` command accepts all
+the options that control dependency
+analysis, since some of these determine the location of the
+output directory of a build, the choice of compiler, etc.
+
+*   `bazel-bin`, `bazel-testlogs`,
+    `bazel-genfiles`: reports the absolute path to
+    the `bazel-*` directories in which programs generated by the
+    build are located. This is usually, though not always, the same as
+    the `bazel-*` symlinks created in the base workspace directory after a
+    successful build. However, if the workspace directory is read-only,
+    no `bazel-*` symlinks can be created. Scripts that use
+    the value reported by `bazel info`, instead of assuming the
+    existence of the symlink, will be more robust.
+*   The complete
+    ["Make" environment](/versions/9.1.0/reference/be/make-variables). If the `--show_make_env` flag is
+    specified, all variables in the current configuration's "Make" environment
+    are also displayed (such as `CC`, `GLIBC_VERSION`, etc).
+    These are the variables accessed using the `$(CC)`
+    or `varref("CC")` syntax inside BUILD files.
+
+Example: the C++ compiler for the current configuration.
+This is the `$(CC)` variable in the "Make" environment,
+so the `--show_make_env` flag is needed.
+
+
+  % bazel info --show_make_env -c opt COMPILATION_MODE
+  opt
+

+
+Example: the `bazel-bin` output directory for the current
+configuration. This is guaranteed to be correct even in cases where
+the `bazel-bin` symlink cannot be created for some reason
+(such as if you are building from a read-only directory).
+
+
% bazel info --cpu=piii bazel-bin
+/var/tmp/_bazel_johndoe/fbd0e8a34f61ce5d491e3da69d959fe6/execroot/io_bazel/bazel-out/piii-opt/bin
+% bazel info --cpu=k8 bazel-bin
+/var/tmp/_bazel_johndoe/fbd0e8a34f61ce5d491e3da69d959fe6/execroot/io_bazel/bazel-out/k8-opt/bin
+

+
+### `version` and `--version` {:#version}
+
+The version command prints version details about the built Bazel
+binary, including the changelist at which it was built and the date.
+These are particularly useful in determining if you have the latest
+Bazel, or if you are reporting bugs. Some of the interesting values
+are:
+
+*   `changelist`: the changelist at which this version of
+    Bazel was released.
+*   `label`: the release label for this Bazel
+    instance, or "development version" if this is not a released
+    binary. Very useful when reporting bugs.
+
+`bazel --version`, with no other args, will emit the same output as
+`bazel version --gnu_format`, except without the side-effect of potentially starting
+a Bazel server or unpacking the server archive. `bazel --version` can be run from
+anywhere - it does not require a workspace directory.
+
+### `mobile-install` {:#mobile-install}
+
+The `mobile-install` command installs apps to mobile devices.
+Currently only Android devices running ART are supported.
+
+See [bazel mobile-install](/versions/9.1.0/docs/mobile-install) for more information.
+
+Note: This command does not install the same thing that
+`bazel build` produces: Bazel tweaks the app so that it can be
+built, installed and re-installed quickly. This should, however, be mostly
+transparent to the app.
+
+The following options are supported:
+
+#### `--incremental` {:#incremental}
+
+If set, Bazel tries to install the app incrementally, that is, only those
+parts that have changed since the last build. This cannot update resources
+referenced from `AndroidManifest.xml`, native code or Java
+resources (such as those referenced by `Class.getResource()`). If these
+things change, this option must be omitted. Contrary to the spirit of Bazel
+and due to limitations of the Android platform, it is the
+**responsibility of the user** to know when this command is good enough and
+when a full install is needed.
+
+If you are using a device with Marshmallow or later, consider the
+[`--split_apks`](#split-apks) flag.
+
+#### `--split_apks` {:#split-apks}
+
+Whether to use split apks to install and update the application on the device.
+Works only with devices with Marshmallow or later. Note that the
+[`--incremental`](#incremental) flag
+is not necessary when using `--split_apks`.
+
+#### `--start_app` {:#start-app}
+
+Starts the app in a clean state after installing. Equivalent to `--start=COLD`.
+
+#### `--debug_app` {:#debug-app}
+
+Waits for debugger to be attached before starting the app in a clean state after installing.
+Equivalent to `--start=DEBUG`.
+
+#### `--start=_start_type_` {:#start}
+
+How the app should be started after installing it. Supported _start_type_s are:
+
+*   `NO` Does not start the app. This is the default.
+*   `COLD` Starts the app from a clean state after install.
+*   `WARM` Preserves and restores the application state on incremental installs.
+*   `DEBUG` Waits for the debugger before starting the app in a clean state after
+    install.
+
+Note: If more than one of `--start=_start_type_`, `--start_app` or
+`--debug_app` is set, the last value is used.
+
+#### `--adb={{ "" }}path{{ "" }}` {:#adb}
+
+Indicates the `adb` binary to be used.
+
+The default is to use the adb in the Android SDK specified by
+[`--android_sdk`](#android-sdk).
+
+#### `--adb_arg={{ "" }}serial{{ "" }}` {:#adb-arg}
+
+Extra arguments to `adb`. These come before the subcommand in the
+command line and are typically used to specify which device to install to.
+For example, to select the Android device or emulator to use:
+
+
% bazel mobile-install --adb_arg=-s --adb_arg=deadbeef
+

+
+invokes `adb` as
+
+
+adb -s deadbeef install ...
+

+
+#### `--incremental_install_verbosity={{ "" }}number{{ "" }}` {:#incremental-install-verbosity}
+
+The verbosity for incremental install. Set to 1 for debug logging to be
+printed to the console.
+
+### `dump` {:#dump}
+
+The `dump` command prints to stdout a dump of the
+internal state of the Bazel server. This command is intended
+primarily for use by Bazel developers, so the output of this command
+is not specified, and is subject to change.
+
+By default, command will just print help message outlining possible
+options to dump specific areas of the Bazel state. In order to dump
+internal state, at least one of the options must be specified.
+
+Following options are supported:
+
+*   `--action_cache` dumps action cache content.
+*   `--packages` dumps package cache content.
+*   `--skyframe` dumps state of internal Bazel dependency graph.
+*   `--rules` dumps rule summary for each rule and aspect class,
+    including counts and action counts. This includes both native and Starlark rules.
+    If memory tracking is enabled, then the rules' memory consumption is also printed.
+*   `--skylark_memory` dumps a
+    [pprof](https://github.com/google/pprof) compatible .gz file to the specified path.
+    You must enable memory tracking for this to work.
+
+#### Memory tracking {:#memory-tracking}
+
+Some `dump` commands require memory tracking. To turn this on, you have to pass
+startup flags to Bazel:
+
+*   `--host_jvm_args=-javaagent:$BAZEL/third_party/allocation_instrumenter/java-allocation-instrumenter-3.3.4.jar`
+*   `--host_jvm_args=-DRULE_MEMORY_TRACKER=1`
+
+The java-agent is checked into Bazel at
+`third_party/allocation_instrumenter/java-allocation-instrumenter-3.3.4.jar`, so
+make sure you adjust `$BAZEL` for where you keep your Bazel repository.
+
+Do not forget to keep passing these options to Bazel for every command or the server will
+restart.
+
+Example:
+
+
+    % bazel --host_jvm_args=-javaagent:$BAZEL/third_party/allocation_instrumenter/java-allocation-instrumenter-3.3.4.jar \
+    --host_jvm_args=-DRULE_MEMORY_TRACKER=1 \
+    build --nobuild <targets>
+
+    # Dump rules
+    % bazel --host_jvm_args=-javaagent:$BAZEL/third_party/allocation_instrumenter/java-allocation-instrumenter-3.3.4.jar \
+    --host_jvm_args=-DRULE_MEMORY_TRACKER=1 \
+    dump --rules
+
+    # Dump Starlark heap and analyze it with pprof
+    % bazel --host_jvm_args=-javaagent:$BAZEL/third_party/allocation_instrumenter/java-allocation-instrumenter-3.3.4.jar \
+    --host_jvm_args=-DRULE_MEMORY_TRACKER=1 \
+    dump --skylark_memory=$HOME/prof.gz
+    % pprof -flame $HOME/prof.gz
+

+
+### `analyze-profile` {:#analyze-profile}
+
+The `analyze-profile` command analyzes a
+[JSON trace profile](/versions/9.1.0/advanced/performance/json-trace-profile) previously
+gathered during a Bazel invocation.
+
+### `canonicalize-flags` {:#canonicalize-flags}
+
+The [`canonicalize-flags`](/versions/9.1.0/reference/command-line-reference#canonicalize-flags-options)
+command, which takes a list of options for a Bazel command and returns a list of
+options that has the same effect. The new list of options is canonical. For example,
+two lists of options with the same effect are canonicalized to the same new list.
+
+The `--for_command` option can be used to select between different
+commands. At this time, only `build` and `test` are
+supported. Options that the given command does not support cause an error.
+
+Note: A small number of options cannot be reordered, because Bazel cannot
+ensure that the effect is identical. Also note that this command
+_does not_ expand flags from `--config`.
+
+As an example:
+
+
+  % bazel canonicalize-flags -- --config=any_name --test_tag_filters="-lint"
+  --config=any_name
+  --test_tag_filters=-lint
+

+
+### Startup options {:#startup-options}
+
+The options described in this section affect the startup of the Java
+virtual machine used by Bazel server process, and they apply to all
+subsequent commands handled by that server. If there is an already
+running Bazel server and the startup options do not match, it will
+be restarted.
+
+All of the options described in this section must be specified using the
+`--key=value` or `--key value`
+syntax. Also, these options must appear _before_ the name of the Bazel
+command. Use `startup --key=value` to list these in a `.bazelrc` file.
+
+#### `--output_base={{ "" }}dir{{ "" }}` {:#output-base}
+
+This option requires a path argument, which must specify a
+writable directory. Bazel will use this location to write all its
+output. The output base is also the key by which the client locates
+the Bazel server. By changing the output base, you change the server
+which will handle the command.
+
+By default, the output base is derived from the user's login name,
+and the name of the workspace directory (actually, its MD5 digest),
+so a typical value looks like:
+`/var/tmp/google/_bazel_johndoe/d41d8cd98f00b204e9800998ecf8427e`.
+
+Note: The client uses the output base to find the Bazel server
+instance, so if you specify a different output base in a Bazel
+command, a different server will be found (or started) to handle the
+request. It's possible to perform two concurrent builds in the same
+workspace directory by varying the output base.
+
+For example:
+
+
+ OUTPUT_BASE=/var/tmp/google/_bazel_johndoe/custom_output_base
+% bazel --output_base ${OUTPUT_BASE}1 build //foo  &  bazel --output_base ${OUTPUT_BASE}2 build //bar
+

+
+In this command, the two Bazel commands run concurrently (because of
+the shell `&` operator), each using a different Bazel
+server instance (because of the different output bases).
+In contrast, if the default output base was used in both commands,
+then both requests would be sent to the same server, which would
+handle them sequentially: building `//foo` first, followed
+by an incremental build of `//bar`.
+
+Note: We recommend you do not use an NFS or similar networked file system for the root
+directory, as the higher access latency will cause noticeably slower builds.
+
+#### `--output_user_root={{ "" }}dir{{ "" }}` {:#output-user-root}
+
+Points to the root directory where output and install bases are created. The directory
+must either not exist or be owned by the calling user. In the past,
+this was allowed to point to a directory shared among various users
+but it's not allowed any longer. This may be allowed once
+[issue #11100](https://github.com/bazelbuild/bazel/issues/11100){: .external} is addressed.
+
+If the `--output_base` option is specified, it overrides
+using `--output_user_root` to calculate the output base.
+
+The install base location is calculated based on
+`--output_user_root`, plus the MD5 identity of the Bazel embedded
+binaries.
+
+You can use the `--output_user_root` option to choose an
+alternate base location for all of Bazel's output (install base and output
+base) if there is a better location in your filesystem layout.
+
+Note: We recommend you do not use an NFS or similar networked file system for the root
+directory, as the higher access latency will cause noticeably slower builds.
+
+#### `--server_javabase={{ "" }}dir{{ "" }}` {:#server-javabase}
+
+Specifies the Java virtual machine in which _Bazel itself_ runs. The value must be a path to
+the directory containing a JDK or JRE. It should not be a label.
+This option should appear before any Bazel command, for example:
+
+
+  % bazel --server_javabase=/usr/local/buildtools/java/jdk build //foo
+

+
+This flag does _not_ affect the JVMs used by Bazel subprocesses such as applications, tests,
+tools, and so on. Use build options [--javabase](#javabase) or
+[--host_javabase](#host-javabase) instead.
+
+This flag was previously named `--host_javabase` (sometimes referred to as the
+'left-hand side' `--host_javabase`), but was renamed to avoid confusion with the
+build flag [--host_javabase](#host-javabase) (sometimes referred to as the
+'right-hand side' `--host_javabase`).
+
+#### `--host_jvm_args={{ "" }}string{{ "" }}` {:#host-jvm-args}
+
+Specifies a startup option to be passed to the Java virtual machine in which _Bazel itself_
+runs. This can be used to set the stack size, for example:
+
+
+  % bazel --host_jvm_args="-Xss256K" build //foo
+

+
+This option can be used multiple times with individual arguments. Note that
+setting this flag should rarely be needed. You can also pass a space-separated list of strings,
+each of which will be interpreted as a separate JVM argument, but this feature will soon be
+deprecated.
+
+That this does _not_ affect any JVMs used by
+subprocesses of Bazel: applications, tests, tools, and so on. To pass
+JVM options to executable Java programs, whether run by `bazel
+run` or on the command-line, you should use
+the `--jvm_flags` argument which
+all `java_binary` and `java_test` programs
+support. Alternatively for tests, use `bazel test --test_arg=--jvm_flags=foo ...`.
+
+#### `--host_jvm_debug` {:#host-java-debug}
+
+This option causes the Java virtual machine to wait for a connection
+from a JDWP-compliant debugger before
+calling the main method of _Bazel itself_. This is primarily
+intended for use by Bazel developers.
+
+Note: This does _not_ affect any JVMs used by subprocesses of Bazel:
+applications, tests, tools, etc.
+
+#### `--autodetect_server_javabase` {:#autodetect-server-javabase}
+
+This option causes Bazel to automatically search for an installed JDK on startup,
+and to fall back to the installed JRE if the embedded JRE isn't available.
+`--explicit_server_javabase` can be used to pick an explicit JRE to
+run Bazel with.
+
+#### `--batch` {:#batch}
+
+Batch mode causes Bazel to not use the
+[standard client/server mode](/versions/9.1.0/run/client-server), but instead runs a bazel
+java process for a single command, which has been used for more predictable
+semantics with respect to signal handling, job control, and environment
+variable inheritance, and is necessary for running bazel in a chroot jail.
+
+Batch mode retains proper queueing semantics within the same output_base.
+That is, simultaneous invocations will be processed in order, without overlap.
+If a batch mode Bazel is run on a client with a running server, it first
+kills the server before processing the command.
+
+Bazel will run slower in batch mode, or with the alternatives described above.
+This is because, among other things, the build file cache is memory-resident, so it is not
+preserved between sequential batch invocations.
+Therefore, using batch mode often makes more sense in cases where performance
+is less critical, such as continuous builds.
+
+Warning: `--batch` is sufficiently slower than standard
+client/server mode. Additionally it might not support all of the features and optimizations which
+are made possible by a persistent Bazel server. If you're using `--batch`
+for the purpose of build isolation, you should use the command option
+`--nokeep_state_after_build`, which guarantees that no incremental
+in-memory state is kept between builds. In order to restart the Bazel server and JVM after a
+build, please explicitly do so using the "shutdown" command.
+
+#### `--max_idle_secs={{ "" }}n{{ "" }}` {:#max-idle-secs}
+
+This option specifies how long, in seconds, the Bazel server process
+should wait after the last client request, before it exits. The
+default value is 10800 (3 hours). `--max_idle_secs=0` will cause the
+Bazel server process to persist indefinitely.
+
+Note: this flag is only read if Bazel needs
+to start a new server. Changing this option will not cause the server to restart.
+
+Note: system sleep time where a build is not running is counted as idle time.
+
+This option may be used by scripts that invoke Bazel to ensure that
+they do not leave Bazel server processes on a user's machine when they
+would not be running otherwise.
+For example, a presubmit script might wish to
+invoke `bazel query` to ensure that a user's pending
+change does not introduce unwanted dependencies. However, if the
+user has not done a recent build in that workspace, it would be
+undesirable for the presubmit script to start a Bazel server just
+for it to remain idle for the rest of the day.
+By specifying a small value of `--max_idle_secs` in the
+query request, the script can ensure that _if_ it caused a new
+server to start, that server will exit promptly, but if instead
+there was already a server running, that server will continue to run
+until it has been idle for the usual time. Of course, the existing
+server's idle timer will be reset.
+
+#### `--[no]shutdown_on_low_sys_mem` {:#shutdown-on-low-sys-mem}
+
+If enabled and `--max_idle_secs` is set to a positive duration,
+after the build server has been idle for a while, shut down the server when the system is
+low on memory. Linux only.
+
+In addition to running an idle check corresponding to max_idle_secs, the build server will
+starts monitoring available system memory after the server has been idle for some time.
+If the available system memory becomes critically low, the server will exit.
+
+#### `--[no]block_for_lock` {:#block-for-lock}
+
+If enabled, Bazel will wait for other Bazel commands holding the
+server lock to complete before progressing. If disabled, Bazel will
+exit in error if it cannot immediately acquire the lock and
+proceed.
+
+Developers might use this in presubmit checks to avoid long waits caused
+by another Bazel command in the same client.
+
+#### `--io_nice_level={{ "" }}n{{ "" }}` {:#io-nice-level}
+
+Sets a level from 0-7 for best-effort IO scheduling. 0 is highest priority,
+7 is lowest. The anticipatory scheduler may only honor up to priority 4.
+Negative values are ignored.
+
+#### `--batch_cpu_scheduling` {:#batch-cpu-scheduling}
+
+Use `batch` CPU scheduling for Bazel. This policy is useful for
+workloads that are non-interactive, but do not want to lower their nice value.
+See 'man 2 sched_setscheduler'. This policy may provide for better system
+interactivity at the expense of Bazel throughput.
+
+### Miscellaneous options {:#misc-options}
+
+#### `--[no]announce_rc` {:#announce-rc}
+
+Controls whether Bazel announces startup options and command options read from
+the bazelrc files when starting up.
+
+#### `--color (yes|no|auto)` {:#color}
+
+This option determines whether Bazel will use colors to highlight
+its output on the screen.
+
+If this option is set to `yes`, color output is enabled.
+If this option is set to `auto`, Bazel will use color output only if
+the output is being sent to a terminal and the TERM environment variable
+is set to a value other than `dumb`, `emacs`, or `xterm-mono`.
+If this option is set to `no`, color output is disabled,
+regardless of whether the output is going to a terminal and regardless
+of the setting of the TERM environment variable.
+
+#### `--config={{ "" }}name{{ "" }}` {:#config}
+
+Selects additional config section from
+[the rc files](/versions/9.1.0/run/bazelrc#bazelrc-file-locations); for the current `command`,
+it also pulls in the options from `command:name` if such a section exists. Can be
+specified multiple times to add flags from several config sections. Expansions can refer to other
+definitions (for example, expansions can be chained).
+
+#### `--curses (yes|no|auto)` {:#curses}
+
+This option determines whether Bazel will use cursor controls
+in its screen output. This results in less scrolling data, and a more
+compact, easy-to-read stream of output from Bazel. This works well with
+`--color`.
+
+If this option is set to `yes`, use of cursor controls is enabled.
+If this option is set to `no`, use of cursor controls is disabled.
+If this option is set to `auto`, use of cursor controls will be
+enabled under the same conditions as for `--color=auto`.
+
+#### `--[no]show_timestamps` {:#show-timestamps}
+
+If specified, a timestamp is added to each message generated by
+Bazel specifying the time at which the message was displayed.
diff --git a/versions/9.1.0/extending/aspects.mdx b/versions/9.1.0/extending/aspects.mdx
new file mode 100644
index 00000000..71ff9172
--- /dev/null
+++ b/versions/9.1.0/extending/aspects.mdx
@@ -0,0 +1,419 @@
+---
+title: 'Aspects'
+---
+
+This page explains the basics and benefits of using
+[aspects](/versions/9.1.0/rules/lib/globals/bzl#aspect) and provides simple and advanced
+examples.
+
+Aspects allow augmenting build dependency graphs with additional information
+and actions. Some typical scenarios when aspects can be useful:
+
+*   IDEs that integrate Bazel can use aspects to collect information about the
+    project.
+*   Code generation tools can leverage aspects to execute on their inputs in
+    *target-agnostic* manner. As an example, `BUILD` files can specify a hierarchy
+    of [protobuf](https://developers.google.com/protocol-buffers/) library
+    definitions, and language-specific rules can use aspects to attach
+    actions generating protobuf support code for a particular language.
+
+## Aspect basics
+
+`BUILD` files provide a description of a project’s source code: what source
+files are part of the project, what artifacts (_targets_) should be built from
+those files, what the dependencies between those files are, etc. Bazel uses
+this information to perform a build, that is, it figures out the set of actions
+needed to produce the artifacts (such as running compiler or linker) and
+executes those actions. Bazel accomplishes this by constructing a _dependency
+graph_ between targets and visiting this graph to collect those actions.
+
+Consider the following `BUILD` file:
+
+```python
+java_library(name = 'W', ...)
+java_library(name = 'Y', deps = [':W'], ...)
+java_library(name = 'Z', deps = [':W'], ...)
+java_library(name = 'Q', ...)
+java_library(name = 'T', deps = [':Q'], ...)
+java_library(name = 'X', deps = [':Y',':Z'], runtime_deps = [':T'], ...)
+```
+
+This `BUILD` file defines a dependency graph shown in the following figure:
+
+![Build graph](/versions/9.1.0/rules/build-graph.png "Build graph")
+
+**Figure 1.** `BUILD` file dependency graph.
+
+Bazel analyzes this dependency graph by calling an implementation function of
+the corresponding [rule](/versions/9.1.0/extending/rules) (in this case "java_library") for every
+target in the above example. Rule implementation functions generate actions that
+build artifacts, such as `.jar` files, and pass information, such as locations
+and names of those artifacts, to the reverse dependencies of those targets in
+[providers](/versions/9.1.0/extending/rules#providers).
+
+Aspects are similar to rules in that they have an implementation function that
+generates actions and returns providers. However, their power comes from
+the way the dependency graph is built for them. An aspect has an implementation
+and a list of all attributes it propagates along. Consider an aspect A that
+propagates along attributes named "deps". This aspect can be applied to
+a target X, yielding an aspect application node A(X). During its application,
+aspect A is applied recursively to all targets that X refers to in its "deps"
+attribute (all attributes in A's propagation list).
+
+Thus a single act of applying aspect A to a target X yields a "shadow graph" of
+the original dependency graph of targets shown in the following figure:
+
+![Build Graph with Aspect](/versions/9.1.0/rules/build-graph-aspects.png "Build graph with aspects")
+
+**Figure 2.** Build graph with aspects.
+
+The only edges that are shadowed are the edges along the attributes in
+the propagation set, thus the `runtime_deps` edge is not shadowed in this
+example. An aspect implementation function is then invoked on all nodes in
+the shadow graph similar to how rule implementations are invoked on the nodes
+of the original graph.
+
+## Simple example
+
+This example demonstrates how to recursively print the source files for a
+rule and all of its dependencies that have a `deps` attribute. It shows
+an aspect implementation, an aspect definition, and how to invoke the aspect
+from the Bazel command line.
+
+```python
+def _print_aspect_impl(target, ctx):
+    # Make sure the rule has a srcs attribute.
+    if hasattr(ctx.rule.attr, 'srcs'):
+        # Iterate through the files that make up the sources and
+        # print their paths.
+        for src in ctx.rule.attr.srcs:
+            for f in src.files.to_list():
+                print(f.path)
+    return []
+
+print_aspect = aspect(
+    implementation = _print_aspect_impl,
+    attr_aspects = ['deps'],
+    required_providers = [CcInfo],
+)
+```
+
+Let's break the example up into its parts and examine each one individually.
+
+### Aspect definition
+
+```python
+print_aspect = aspect(
+    implementation = _print_aspect_impl,
+    attr_aspects = ['deps'],
+    required_providers = [CcInfo],
+)
+```
+Aspect definitions are similar to rule definitions, and defined using
+the [`aspect`](/versions/9.1.0/rules/lib/globals/bzl#aspect) function.
+
+Just like a rule, an aspect has an implementation function which in this case is
+``_print_aspect_impl``.
+
+``attr_aspects`` is a list of rule attributes along which the aspect propagates.
+In this case, the aspect will propagate along the ``deps`` attribute of the
+rules that it is applied to.
+
+Another common argument for `attr_aspects` is `['*']` which would propagate the
+aspect to all attributes of a rule.
+
+``required_providers`` is a list of providers that allows the aspect to limit
+its propagation to only the targets whose rules advertise its required
+providers. For more details consult
+[the documentation of the aspect function](/versions/9.1.0/rules/lib/globals/bzl#aspect).
+In this case, the aspect will only apply on targets that declare `CcInfo`
+provider.
+
+### Aspect implementation
+
+```python
+def _print_aspect_impl(target, ctx):
+    # Make sure the rule has a srcs attribute.
+    if hasattr(ctx.rule.attr, 'srcs'):
+        # Iterate through the files that make up the sources and
+        # print their paths.
+        for src in ctx.rule.attr.srcs:
+            for f in src.files.to_list():
+                print(f.path)
+    return []
+```
+
+Aspect implementation functions are similar to the rule implementation
+functions. They return [providers](/versions/9.1.0/extending/rules#providers), can generate
+[actions](/versions/9.1.0/extending/rules#actions), and take two arguments:
+
+*  `target`: the [target](/versions/9.1.0/rules/lib/builtins/Target) the aspect is being applied to.
+*   `ctx`: [`ctx`](/versions/9.1.0/rules/lib/builtins/ctx) object that can be used to access attributes
+    and generate outputs and actions.
+
+The implementation function can access the attributes of the target rule via
+[`ctx.rule.attr`](/versions/9.1.0/rules/lib/builtins/ctx#rule). It can examine providers that are
+provided by the target to which it is applied (via the `target` argument).
+
+Aspects are required to return a list of providers. In this example, the aspect
+does not provide anything, so it returns an empty list.
+
+### Invoking the aspect using the command line
+
+The simplest way to apply an aspect is from the command line using the
+[`--aspects`](/versions/9.1.0/reference/command-line-reference#flag--aspects)
+argument. Assuming the aspect above were defined in a file named `print.bzl`
+this:
+
+```bash
+bazel build //MyExample:example --aspects print.bzl%print_aspect
+```
+
+would apply the `print_aspect` to the target `example` and all of the
+target rules that are accessible recursively via the `deps` attribute.
+
+The `--aspects` flag takes one argument, which is a specification of the aspect
+in the format `%`.
+
+## Advanced example
+
+The following example demonstrates using an aspect from a target rule
+that counts files in targets, potentially filtering them by extension.
+It shows how to use a provider to return values, how to use parameters to pass
+an argument into an aspect implementation, and how to invoke an aspect from a rule.
+
+Note: Aspects added in rules' attributes are called *rule-propagated aspects* as
+opposed to *command-line aspects* that are specified using the ``--aspects``
+flag.
+
+`file_count.bzl` file:
+
+```python
+FileCountInfo = provider(
+    fields = {
+        'count' : 'number of files'
+    }
+)
+
+def _file_count_aspect_impl(target, ctx):
+    count = 0
+    # Make sure the rule has a srcs attribute.
+    if hasattr(ctx.rule.attr, 'srcs'):
+        # Iterate through the sources counting files
+        for src in ctx.rule.attr.srcs:
+            for f in src.files.to_list():
+                if ctx.attr.extension == '*' or ctx.attr.extension == f.extension:
+                    count = count + 1
+    # Get the counts from our dependencies.
+    for dep in ctx.rule.attr.deps:
+        count = count + dep[FileCountInfo].count
+    return [FileCountInfo(count = count)]
+
+file_count_aspect = aspect(
+    implementation = _file_count_aspect_impl,
+    attr_aspects = ['deps'],
+    attrs = {
+        'extension' : attr.string(values = ['*', 'h', 'cc']),
+    }
+)
+
+def _file_count_rule_impl(ctx):
+    for dep in ctx.attr.deps:
+        print(dep[FileCountInfo].count)
+
+file_count_rule = rule(
+    implementation = _file_count_rule_impl,
+    attrs = {
+        'deps' : attr.label_list(aspects = [file_count_aspect]),
+        'extension' : attr.string(default = '*'),
+    },
+)
+```
+
+`BUILD.bazel` file:
+
+```python
+load('//:file_count.bzl', 'file_count_rule')
+
+cc_library(
+    name = 'lib',
+    srcs = [
+        'lib.h',
+        'lib.cc',
+    ],
+)
+
+cc_binary(
+    name = 'app',
+    srcs = [
+        'app.h',
+        'app.cc',
+        'main.cc',
+    ],
+    deps = ['lib'],
+)
+
+file_count_rule(
+    name = 'file_count',
+    deps = ['app'],
+    extension = 'h',
+)
+```
+
+### Aspect definition
+
+```python
+file_count_aspect = aspect(
+    implementation = _file_count_aspect_impl,
+    attr_aspects = ['deps'],
+    attrs = {
+        'extension' : attr.string(values = ['*', 'h', 'cc']),
+    }
+)
+```
+
+This example shows how the aspect propagates through the ``deps`` attribute.
+
+``attrs`` defines a set of attributes for an aspect. Public aspect attributes
+define parameters and can only be of types ``bool``, ``int`` or ``string``.
+For rule-propagated aspects, ``int`` and ``string`` parameters must have
+``values`` specified on them. This example has a parameter called ``extension``
+that is allowed to have '``*``', '``h``', or '``cc``' as a value.
+
+For rule-propagated aspects, parameter values are taken from the rule requesting
+the aspect, using the attribute of the rule that has the same name and type.
+(see the definition of ``file_count_rule``).
+
+For command-line aspects, the parameters values can be passed using
+[``--aspects_parameters``](/versions/9.1.0/reference/command-line-reference#flag--aspects_parameters)
+flag. The ``values`` restriction of ``int`` and ``string`` parameters may be
+omitted.
+
+Aspects are also allowed to have private attributes of types ``label`` or
+``label_list``. Private label attributes can be used to specify dependencies on
+tools or libraries that are needed for actions generated by aspects. There is not
+a private attribute defined in this example, but the following code snippet
+demonstrates how you could pass in a tool to an aspect:
+
+```python
+...
+    attrs = {
+        '_protoc' : attr.label(
+            default = Label('//tools:protoc'),
+            executable = True,
+            cfg = "exec"
+        )
+    }
+...
+```
+
+### Aspect implementation
+
+```python
+FileCountInfo = provider(
+    fields = {
+        'count' : 'number of files'
+    }
+)
+
+def _file_count_aspect_impl(target, ctx):
+    count = 0
+    # Make sure the rule has a srcs attribute.
+    if hasattr(ctx.rule.attr, 'srcs'):
+        # Iterate through the sources counting files
+        for src in ctx.rule.attr.srcs:
+            for f in src.files.to_list():
+                if ctx.attr.extension == '*' or ctx.attr.extension == f.extension:
+                    count = count + 1
+    # Get the counts from our dependencies.
+    for dep in ctx.rule.attr.deps:
+        count = count + dep[FileCountInfo].count
+    return [FileCountInfo(count = count)]
+```
+
+Just like a rule implementation function, an aspect implementation function
+returns a struct of providers that are accessible to its dependencies.
+
+In this example, the ``FileCountInfo`` is defined as a provider that has one
+field ``count``. It is best practice to explicitly define the fields of a
+provider using the ``fields`` attribute.
+
+The set of providers for an aspect application A(X) is the union of providers
+that come from the implementation of a rule for target X and from the
+implementation of aspect A. The providers that a rule implementation propagates
+are created and frozen before aspects are applied and cannot be modified from an
+aspect. It is an error if a target and an aspect that is applied to it each
+provide a provider with the same type, with the exceptions of
+[`OutputGroupInfo`](/versions/9.1.0/rules/lib/providers/OutputGroupInfo)
+(which is merged, so long as the
+rule and aspect specify different output groups) and
+[`InstrumentedFilesInfo`](/versions/9.1.0/rules/lib/providers/InstrumentedFilesInfo)
+(which is taken from the aspect). This means that aspect implementations may
+never return [`DefaultInfo`](/versions/9.1.0/rules/lib/providers/DefaultInfo).
+
+The parameters and private attributes are passed in the attributes of the
+``ctx``. This example references the ``extension`` parameter and determines
+what files to count.
+
+For returning providers, the values of attributes along which
+the aspect is propagated (from the `attr_aspects` list) are replaced with
+the results of an application of the aspect to them. For example, if target
+X has Y and Z in its deps, `ctx.rule.attr.deps` for A(X) will be [A(Y), A(Z)].
+In this example, ``ctx.rule.attr.deps`` are Target objects that are the
+results of applying the aspect to the 'deps' of the original target to which
+the aspect has been applied.
+
+In the example, the aspect accesses the ``FileCountInfo`` provider from the
+target's dependencies to accumulate the total transitive number of files.
+
+### Invoking the aspect from a rule
+
+```python
+def _file_count_rule_impl(ctx):
+    for dep in ctx.attr.deps:
+        print(dep[FileCountInfo].count)
+
+file_count_rule = rule(
+    implementation = _file_count_rule_impl,
+    attrs = {
+        'deps' : attr.label_list(aspects = [file_count_aspect]),
+        'extension' : attr.string(default = '*'),
+    },
+)
+```
+
+The rule implementation demonstrates how to access the ``FileCountInfo``
+via the ``ctx.attr.deps``.
+
+The rule definition demonstrates how to define a parameter (``extension``)
+and give it a default value (``*``). Note that having a default value that
+was not one of '``cc``', '``h``', or '``*``' would be an error due to the
+restrictions placed on the parameter in the aspect definition.
+
+### Invoking an aspect through a target rule
+
+```python
+load('//:file_count.bzl', 'file_count_rule')
+
+cc_binary(
+    name = 'app',
+...
+)
+
+file_count_rule(
+    name = 'file_count',
+    deps = ['app'],
+    extension = 'h',
+)
+```
+
+This demonstrates how to pass the ``extension`` parameter into the aspect
+via the rule. Since the ``extension`` parameter has a default value in the
+rule implementation, ``extension`` would be considered an optional parameter.
+
+When the ``file_count`` target is built, our aspect will be evaluated for
+itself, and all of the targets accessible recursively via ``deps``.
+
+## References
+
+* [`aspect` API reference](/versions/9.1.0/rules/lib/globals/bzl#aspect)
diff --git a/versions/9.1.0/extending/auto-exec-groups.mdx b/versions/9.1.0/extending/auto-exec-groups.mdx
new file mode 100644
index 00000000..88cf866d
--- /dev/null
+++ b/versions/9.1.0/extending/auto-exec-groups.mdx
@@ -0,0 +1,181 @@
+---
+title: 'Automatic Execution Groups (AEGs)'
+---
+
+Automatic execution groups select an [execution platform][exec_platform]
+for each toolchain type. In other words, one target can have multiple
+execution platforms without defining execution groups.
+
+## Quick summary {#quick-summary}
+
+Automatic execution groups are closely connected to toolchains. If you are using
+toolchains, you need to set them on the affected actions (actions which use an
+executable or a tool from a toolchain) by adding `toolchain` parameter. For
+example:
+
+```python
+ctx.actions.run(
+    ...,
+    executable = ctx.toolchain['@bazel_tools//tools/jdk:toolchain_type'].tool,
+    ...,
+    toolchain = '@bazel_tools//tools/jdk:toolchain_type',
+)
+```
+If the action does not use a tool or executable from a toolchain, and Blaze
+doesn't detect that ([the error](#first-error-message) is raised), you can set
+`toolchain = None`.
+
+If you need to use multiple toolchains on a single execution platform (an action
+uses executable or tools from two or more toolchains), you need to manually
+define [exec_groups][exec_groups] (check
+[When should I use a custom exec_group?][multiple_toolchains_exec_groups]
+section).
+
+## History {#history}
+
+Before AEGs, the execution platform was selected on a rule level. For example:
+
+```python
+my_rule = rule(
+    _impl,
+    toolchains = ['//tools:toolchain_type_1', '//tools:toolchain_type_2'],
+)
+```
+
+Rule `my_rule` registers two toolchain types. This means that the [Toolchain
+Resolution](https://bazel.build/versions/9.1.0/extending/toolchains#toolchain-resolution) used
+to find an execution platform which supports both toolchain types. The selected
+execution platform was used for each registered action inside the rule, unless
+specified differently with [exec_groups][exec_groups].
+In other words, all actions inside the rule used to have a single execution
+platform even if they used tools from different toolchains (execution platform
+is selected for each target). This resulted in failures when there was no
+execution platform supporting all toolchains.
+
+## Current state {#current-state}
+
+With AEGs, the execution platform is selected for each toolchain type. The
+implementation function of the earlier example, `my_rule`, would look like:
+
+```python
+def _impl(ctx):
+    ctx.actions.run(
+      mnemonic = "First action",
+      executable = ctx.toolchain['//tools:toolchain_type_1'].tool,
+      toolchain = '//tools:toolchain_type_1',
+    )
+
+    ctx.actions.run(
+      mnemonic = "Second action",
+      executable = ctx.toolchain['//tools:toolchain_type_2'].tool,
+      toolchain = '//tools:toolchain_type_2',
+    )
+```
+
+This rule creates two actions, the `First action` which uses executable from a
+`//tools:toolchain_type_1` and the `Second action` which uses executable from a
+`//tools:toolchain_type_2`. Before AEGs, both of these actions would be executed
+on a single execution platform which supports both toolchain types. With AEGs,
+by adding the `toolchain` parameter inside the actions, each action executes on
+the execution platform that provides the toolchain. The actions may be executed
+on different execution platforms.
+
+The same is effective with [ctx.actions.run_shell][run_shell] where `toolchain`
+parameter should be added when `tools` are from a toolchain.
+
+## Difference between custom exec groups and automatic exec groups {#difference-custom}
+
+As the name suggests, AEGs are exec groups created automatically for each
+toolchain type registered on a rule. There is no need to manually specify them,
+unlike the "classic" exec groups. Moreover, name of AEG is automatically set to
+its toolchain type (e.g. `//tools:toolchain_type_1`).
+
+### When should I use a custom exec_group? {#when-should-use-exec-groups}
+
+Custom exec_groups are needed only in case where multiple toolchains need to
+execute on a single execution platform. In all other cases there's no need to
+define custom exec_groups. For example:
+
+```python
+def _impl(ctx):
+    ctx.actions.run(
+      ...,
+      executable = ctx.toolchain['//tools:toolchain_type_1'].tool,
+      tools = [ctx.toolchain['//tools:toolchain_type_2'].tool],
+      exec_group = 'two_toolchains',
+    )
+```
+
+```python
+my_rule = rule(
+    _impl,
+    exec_groups = {
+        "two_toolchains": exec_group(
+            toolchains = ['//tools:toolchain_type_1', '//tools:toolchain_type_2'],
+        ),
+    }
+)
+```
+
+## Migration of AEGs {#migration-aegs}
+
+Internally in google3, Blaze is already using AEGs.
+Externally for Bazel, migration is in the process. Some rules are already using
+this feature (e.g. Java and C++ rules).
+
+### Which Bazel versions support this migration? {#which-bazel}
+
+AEGs are fully supported from Bazel 7.
+
+### How to enable AEGs? {#how-enable}
+
+Set `--incompatible_auto_exec_groups` to true. More information about the flag
+on [the GitHub issue][github_flag].
+
+### How to enable AEGs inside a particular rule? {#how-enable-particular-rule}
+
+Set the `_use_auto_exec_groups` attribute on a rule.
+
+```python
+my_rule = rule(
+    _impl,
+    attrs = {
+      "_use_auto_exec_groups": attr.bool(default = True),
+    }
+)
+```
+This enables AEGs only in `my_rule` and its actions start using the new logic
+when selecting the execution platform. Incompatible flag is overridden with this
+attribute.
+
+### How to disable AEGs in case of an error? {#how-disable}
+
+Set `--incompatible_auto_exec_groups` to false to completely disable AEGs in
+your project ([flag's GitHub issue][github_flag]), or disable a particular rule
+by setting `_use_auto_exec_groups` attribute to `False`
+([more details about the attribute](#how-enable-particular-rule)).
+
+### Error messages while migrating to AEGs {#potential-problems}
+
+#### Couldn't identify if tools are from implicit dependencies or a toolchain. Please set the toolchain parameter. If you're not using a toolchain, set it to 'None'. {#first-error-message}
+  * In this case you get a stack of calls before the error happened and you can
+    clearly see which exact action needs the toolchain parameter. Check which
+    toolchain is used for the action and set it with the toolchain param. If no
+    toolchain is used inside the action for tools or executable, set it to
+    `None`.
+
+#### Action declared for non-existent toolchain '[toolchain_type]'.
+  * This means that you've set the toolchain parameter on the action but didn't
+register it on the rule. Register the toolchain or set `None` inside the action.
+
+## Additional material {#additional-material}
+
+For more information, check design document:
+[Automatic exec groups for toolchains][aegs_design_doc].
+
+[exec_platform]: https://bazel.build/extending/platforms#:~:text=Execution%20%2D%20a%20platform%20on%20which%20build%20tools%20execute%20build%20actions%20to%20produce%20intermediate%20and%20final%20outputs.
+[exec_groups]: https://bazel.build/extending/exec-groups
+[github_flag]: https://github.com/bazelbuild/bazel/issues/17134
+[aegs_design_doc]: https://docs.google.com/document/d/1-rbP_hmKs9D639YWw5F_JyxPxL2bi6dSmmvj_WXak9M/edit#heading=h.5mcn15i0e1ch
+[run_shell]: https://bazel.build/rules/lib/builtins/actions#run_shell
+[multiple_toolchains_exec_groups]: /extending/auto-exec-groups#when-should-use-exec-groups
\ No newline at end of file
diff --git a/versions/9.1.0/extending/concepts.mdx b/versions/9.1.0/extending/concepts.mdx
new file mode 100644
index 00000000..904eb946
--- /dev/null
+++ b/versions/9.1.0/extending/concepts.mdx
@@ -0,0 +1,110 @@
+---
+title: 'Extension Overview'
+---
+
+{/* [TOC] */}
+
+This page describes how to extend the BUILD language using macros
+and rules.
+
+Bazel extensions are files ending in `.bzl`. Use a
+[load statement](/versions/9.1.0/concepts/build-files#load) to import a symbol from an extension.
+
+Before learning the more advanced concepts, first:
+
+* Read about the [Starlark language](/versions/9.1.0/rules/language), used in both the
+  `BUILD` and `.bzl` files.
+
+* Learn how you can [share variables](/versions/9.1.0/build/share-variables)
+  between two `BUILD` files.
+
+## Macros and rules {#macros-and-rules}
+
+A macro is a function that instantiates rules. Macros come in two flavors:
+[symbolic macros](/versions/9.1.0/extending/macros) (new in Bazel 8) and [legacy
+macros](/versions/9.1.0/extending/legacy-macros). The two flavors of macros are defined
+differently, but behave almost the same from the point of view of a user. A
+macro is useful when a `BUILD` file is getting too repetitive or too complex, as
+it lets you reuse some code. The function is evaluated as soon as the `BUILD`
+file is read. After the evaluation of the `BUILD` file, Bazel has little
+information about macros. If your macro generates a `genrule`, Bazel will
+behave *almost* as if you declared that `genrule` in the `BUILD` file. (The one
+exception is that targets declared in a symbolic macro have [special visibility
+semantics](/versions/9.1.0/extending/macros#visibility): a symbolic macro can hide its internal
+targets from the rest of the package.)
+
+A [rule](/versions/9.1.0/extending/rules) is more powerful than a macro. It can access Bazel
+internals and have full control over what is going on. It may for example pass
+information to other rules.
+
+If you want to reuse simple logic, start with a macro; we recommend a symbolic
+macro, unless you need to support older Bazel versions. If a macro becomes
+complex, it is often a good idea to make it a rule. Support for a new language
+is typically done with a rule. Rules are for advanced users, and most users will
+never have to write one; they will only load and call existing rules.
+
+## Evaluation model {#evaluation-model}
+
+A build consists of three phases.
+
+* **Loading phase**. First, load and evaluate all extensions and all `BUILD`
+  files that are needed for the build. The execution of the `BUILD` files simply
+  instantiates rules (each time a rule is called, it gets added to a graph).
+  This is where macros are evaluated.
+
+* **Analysis phase**. The code of the rules is executed (their `implementation`
+  function), and actions are instantiated. An action describes how to generate
+  a set of outputs from a set of inputs, such as "run gcc on hello.c and get
+  hello.o". You must list explicitly which files will be generated before
+  executing the actual commands. In other words, the analysis phase takes
+  the graph generated by the loading phase and generates an action graph.
+
+* **Execution phase**. Actions are executed, when at least one of their outputs is
+  required. If a file is missing or if a command fails to generate one output,
+  the build fails. Tests are also run during this phase.
+
+Bazel uses parallelism to read, parse and evaluate the `.bzl` files and `BUILD`
+files. A file is read at most once per build and the result of the evaluation is
+cached and reused. A file is evaluated only once all its dependencies (`load()`
+statements) have been resolved. By design, loading a `.bzl` file has no visible
+side-effect, it only defines values and functions.
+
+Bazel tries to be clever: it uses dependency analysis to know which files must
+be loaded, which rules must be analyzed, and which actions must be executed. For
+example, if a rule generates actions that you don't need for the current build,
+they will not be executed.
+
+## Creating extensions
+
+* [Create your first macro](/versions/9.1.0/rules/macro-tutorial) in order to reuse some code.
+  Then [learn more about macros](/versions/9.1.0/extending/macros) and [using them to create
+  "custom verbs"](/versions/9.1.0/rules/verbs-tutorial).
+
+* [Follow the rules tutorial](/versions/9.1.0/rules/rules-tutorial) to get started with rules.
+  Next, you can read more about the [rules concepts](/versions/9.1.0/extending/rules).
+
+The two links below will be very useful when writing your own extensions. Keep
+them within reach:
+
+* The [API reference](/versions/9.1.0/rules/lib)
+
+* [Examples](https://github.com/bazelbuild/examples/tree/master/rules)
+
+## Going further
+
+In addition to [macros](/versions/9.1.0/extending/macros) and [rules](/versions/9.1.0/extending/rules), you
+may want to write [aspects](/versions/9.1.0/extending/aspects) and [repository
+rules](/versions/9.1.0/external/repo).
+
+* Use [Buildifier](https://github.com/bazelbuild/buildtools)
+  consistently to format and lint your code.
+
+* Follow the [`.bzl` style guide](/versions/9.1.0/rules/bzl-style).
+
+* [Test](/versions/9.1.0/rules/testing) your code.
+
+* [Generate documentation](https://skydoc.bazel.build/) to help your users.
+
+* [Optimize the performance](/versions/9.1.0/rules/performance) of your code.
+
+* [Deploy](/versions/9.1.0/rules/deploying) your extensions to other people.
diff --git a/versions/9.1.0/extending/config.mdx b/versions/9.1.0/extending/config.mdx
new file mode 100644
index 00000000..d9dd6927
--- /dev/null
+++ b/versions/9.1.0/extending/config.mdx
@@ -0,0 +1,789 @@
+---
+title: 'Configurations'
+---
+
+
+
+This page covers the benefits and basic usage of Starlark configurations,
+Bazel's API for customizing how your project builds. It includes how to define
+build settings and provides examples.
+
+This makes it possible to:
+
+*   define custom flags for your project, obsoleting the need for
+     [`--define`](/versions/9.1.0/docs/configurable-attributes#custom-keys)
+*   write
+    [transitions](/versions/9.1.0/rules/lib/builtins/transition#transition) to configure deps in
+    different configurations than their parents
+    (such as `--compilation_mode=opt` or `--cpu=arm`)
+*   bake better defaults into rules (such as automatically build `//my:android_app`
+    with a specified SDK)
+
+and more, all completely from .bzl files (no Bazel release required). See the
+`bazelbuild/examples` repo for
+[examples](https://github.com/bazelbuild/examples/tree/HEAD/configurations){: .external}.
+
+## User-defined build settings {:#user-defined-build-settings}
+
+A build setting is a single piece of
+[configuration](/versions/9.1.0/extending/rules#configurations)
+information. Think of a configuration as a key/value map. Setting `--cpu=ppc`
+and `--copt="-DFoo"` produces a configuration that looks like
+`{cpu: ppc, copt: "-DFoo"}`. Each entry is a build setting.
+
+Traditional flags like `cpu` and `copt` are native settings —
+their keys are defined and their values are set inside native bazel java code.
+Bazel users can only read and write them via the command line
+and other APIs maintained natively. Changing native flags, and the APIs
+that expose them, requires a bazel release. User-defined build
+settings are defined in `.bzl` files (and thus, don't need a bazel release to
+register changes). They also can be set via the command line
+(if they're designated as `flags`, see more below), but can also be
+set via [user-defined transitions](#user-defined-transitions).
+
+### Defining build settings {:#defining-build-settings}
+
+[End to end example](https://github.com/bazelbuild/examples/tree/HEAD/configurations/basic_build_setting){: .external}
+
+#### The `build_setting` `rule()` parameter {:#rule-parameter}
+
+Build settings are rules like any other rule and are differentiated using the
+Starlark `rule()` function's `build_setting`
+[attribute](/versions/9.1.0/rules/lib/globals/bzl#rule.build_setting).
+
+```python
+# example/buildsettings/build_settings.bzl
+string_flag = rule(
+    implementation = _impl,
+    build_setting = config.string(flag = True)
+)
+```
+
+The `build_setting` attribute takes a function that designates the type of the
+build setting. The type is limited to a set of basic Starlark types like
+`bool` and `string`. See the `config` module
+[documentation](/versions/9.1.0/rules/lib/toplevel/config)  for details. More complicated typing can be
+done in the rule's implementation function. More on this below.
+
+The `config` module's functions takes an optional boolean parameter, `flag`,
+which is set to false by default. if `flag` is set to true, the build setting
+can be set on the command line by users as well as internally by rule writers
+via default values and [transitions](/versions/9.1.0/rules/lib/builtins/transition#transition).
+Not all settings should be settable by users. For example, if you as a rule
+writer have some debug mode that you'd like to turn on inside test rules,
+you don't want to give users the ability to indiscriminately turn on that
+feature inside other non-test rules.
+
+#### Using ctx.build_setting_value {:#ctx-build-setting-value}
+
+Like all rules, build setting rules have [implementation functions](/versions/9.1.0/extending/rules#implementation-function).
+The basic Starlark-type value of the build settings can be accessed via the
+`ctx.build_setting_value` method. This method is only available to
+[`ctx`](/versions/9.1.0/rules/lib/builtins/ctx) objects of build setting rules. These implementation
+methods can directly forward the build settings value or do additional work on
+it, like type checking or more complex struct creation. Here's how you would
+implement an `enum`-typed build setting:
+
+```python
+# example/buildsettings/build_settings.bzl
+TemperatureProvider = provider(fields = ['type'])
+
+temperatures = ["HOT", "LUKEWARM", "ICED"]
+
+def _impl(ctx):
+    raw_temperature = ctx.build_setting_value
+    if raw_temperature not in temperatures:
+        fail(str(ctx.label) + " build setting allowed to take values {"
+             + ", ".join(temperatures) + "} but was set to unallowed value "
+             + raw_temperature)
+    return TemperatureProvider(type = raw_temperature)
+
+temperature = rule(
+    implementation = _impl,
+    build_setting = config.string(flag = True)
+)
+```
+
+Note: if a rule depends on a build setting, it will receive whatever providers
+the build setting implementation function returns, like any other dependency.
+But all other references to the value of the build setting (such as in transitions)
+will see its basic Starlark-typed value, not this post implementation function
+value.
+
+#### Defining multi-set string flags {:#multi-set-string-flags}
+
+String settings have an additional `allow_multiple` parameter which allows the
+flag to be set multiple times on the command line or in bazelrcs. Their default
+value is still set with a string-typed attribute:
+
+```python
+# example/buildsettings/build_settings.bzl
+allow_multiple_flag = rule(
+    implementation = _impl,
+    build_setting = config.string(flag = True, allow_multiple = True)
+)
+```
+
+```python
+# example/BUILD
+load("//example/buildsettings:build_settings.bzl", "allow_multiple_flag")
+allow_multiple_flag(
+    name = "roasts",
+    build_setting_default = "medium"
+)
+```
+
+Each setting of the flag is treated as a single value:
+
+```shell
+$ bazel build //my/target --//example:roasts=blonde \
+    --//example:roasts=medium,dark
+```
+
+The above is parsed to `{"//example:roasts": ["blonde", "medium,dark"]}` and
+`ctx.build_setting_value` returns the list `["blonde", "medium,dark"]`.
+
+#### Instantiating build settings {:#instantiating-build-settings}
+
+Rules defined with the `build_setting` parameter have an implicit mandatory
+`build_setting_default` attribute. This attribute takes on the same type as
+declared by the `build_setting` param.
+
+```python
+# example/buildsettings/build_settings.bzl
+FlavorProvider = provider(fields = ['type'])
+
+def _impl(ctx):
+    return FlavorProvider(type = ctx.build_setting_value)
+
+flavor = rule(
+    implementation = _impl,
+    build_setting = config.string(flag = True)
+)
+```
+
+```python
+# example/BUILD
+load("//example/buildsettings:build_settings.bzl", "flavor")
+flavor(
+    name = "favorite_flavor",
+    build_setting_default = "APPLE"
+)
+```
+
+### Predefined settings {:#predefined-settings}
+
+[End to end example](https://github.com/bazelbuild/examples/tree/HEAD/configurations/use_skylib_build_setting){: .external}
+
+The
+[Skylib](https://github.com/bazelbuild/bazel-skylib){: .external}
+library includes a set of predefined settings you can instantiate without having
+to write custom Starlark.
+
+For example, to define a setting that accepts a limited set of string values:
+
+```python
+# example/BUILD
+load("@bazel_skylib//rules:common_settings.bzl", "string_flag")
+string_flag(
+    name = "myflag",
+    values = ["a", "b", "c"],
+    build_setting_default = "a",
+)
+```
+
+For a complete list, see
+[Common build setting rules](https://github.com/bazelbuild/bazel-skylib/blob/main/rules/common_settings.bzl){: .external}.
+
+### Using build settings {:#using-build-settings}
+
+#### Depending on build settings {:#depending-on-build-settings}
+
+If a target would like to read a piece of configuration information, it can
+directly depend on the build setting via a regular attribute dependency.
+
+```python
+# example/rules.bzl
+load("//example/buildsettings:build_settings.bzl", "FlavorProvider")
+def _rule_impl(ctx):
+    if ctx.attr.flavor[FlavorProvider].type == "ORANGE":
+        ...
+
+drink_rule = rule(
+    implementation = _rule_impl,
+    attrs = {
+        "flavor": attr.label()
+    }
+)
+```
+
+```python
+# example/BUILD
+load("//example:rules.bzl", "drink_rule")
+load("//example/buildsettings:build_settings.bzl", "flavor")
+flavor(
+    name = "favorite_flavor",
+    build_setting_default = "APPLE"
+)
+drink_rule(
+    name = "my_drink",
+    flavor = ":favorite_flavor",
+)
+```
+
+Languages may wish to create a canonical set of build settings which all rules
+for that language depend on. Though the native concept of `fragments` no longer
+exists as a hardcoded object in Starlark configuration world, one way to
+translate this concept would be to use sets of common implicit attributes. For
+example:
+
+```python
+# kotlin/rules.bzl
+_KOTLIN_CONFIG = {
+    "_compiler": attr.label(default = "//kotlin/config:compiler-flag"),
+    "_mode": attr.label(default = "//kotlin/config:mode-flag"),
+    ...
+}
+
+...
+
+kotlin_library = rule(
+    implementation = _rule_impl,
+    attrs = dicts.add({
+        "library-attr": attr.string()
+    }, _KOTLIN_CONFIG)
+)
+
+kotlin_binary = rule(
+    implementation = _binary_impl,
+    attrs = dicts.add({
+        "binary-attr": attr.label()
+    }, _KOTLIN_CONFIG)
+
+```
+
+#### Using build settings on the command line {:#build-settings-command-line}
+
+Similar to most native flags, you can use the command line to set build settings
+[that are marked as flags](#rule-parameter). The build
+setting's name is its full target path using `name=value` syntax:
+
+```shell
+$ bazel build //my/target --//example:string_flag=some-value # allowed
+$ bazel build //my/target --//example:string_flag some-value # not allowed
+```
+
+Special boolean syntax is supported:
+
+```shell
+$ bazel build //my/target --//example:boolean_flag
+$ bazel build //my/target --no//example:boolean_flag
+```
+
+#### Using build setting aliases {:#using-build-setting-aliases}
+
+You can set an alias for your build setting target path to make it easier to read
+on the command line. Aliases function similarly to native flags and also make use
+of the double-dash option syntax.
+
+Set an alias by adding `--flag_alias=ALIAS_NAME=TARGET_PATH`
+to your `.bazelrc` . For example, to set an alias to `coffee`:
+
+```shell
+# .bazelrc
+build --flag_alias=coffee=//experimental/user/starlark_configurations/basic_build_setting:coffee-temp
+```
+
+Best Practice: Setting an alias multiple times results in the most recent
+one taking precedence. Use unique alias names to avoid unintended parsing results.
+
+To make use of the alias, type it in place of the build setting target path.
+With the above example of `coffee` set in the user's `.bazelrc`:
+
+```shell
+$ bazel build //my/target --coffee=ICED
+```
+
+instead of
+
+```shell
+$ bazel build //my/target --//experimental/user/starlark_configurations/basic_build_setting:coffee-temp=ICED
+```
+Best Practice: While it possible to set aliases on the command line, leaving them
+in a `.bazelrc` reduces command line clutter.
+
+### Label-typed build settings {:#label-typed-build-settings}
+
+[End to end example](https://github.com/bazelbuild/examples/tree/HEAD/configurations/label_typed_build_setting){: .external}
+
+Unlike other build settings, label-typed settings cannot be defined using the
+`build_setting` rule parameter. Instead, bazel has two built-in rules:
+`label_flag` and `label_setting`. These rules forward the providers of the
+actual target to which the build setting is set. `label_flag` and
+`label_setting` can be read/written by transitions and `label_flag` can be set
+by the user like other `build_setting` rules can. Their only difference is they
+can't customely defined.
+
+Label-typed settings will eventually replace the functionality of late-bound
+defaults. Late-bound default attributes are Label-typed attributes whose
+final values can be affected by configuration. In Starlark, this will replace
+the [`configuration_field`](/versions/9.1.0/rules/lib/globals/bzl#configuration_field)
+ API.
+
+```python
+# example/rules.bzl
+MyProvider = provider(fields = ["my_field"])
+
+def _dep_impl(ctx):
+    return MyProvider(my_field = "yeehaw")
+
+dep_rule = rule(
+    implementation = _dep_impl
+)
+
+def _parent_impl(ctx):
+    if ctx.attr.my_field_provider[MyProvider].my_field == "cowabunga":
+        ...
+
+parent_rule = rule(
+    implementation = _parent_impl,
+    attrs = { "my_field_provider": attr.label() }
+)
+
+```
+
+```python
+# example/BUILD
+load("//example:rules.bzl", "dep_rule", "parent_rule")
+
+dep_rule(name = "dep")
+
+parent_rule(name = "parent", my_field_provider = ":my_field_provider")
+
+label_flag(
+    name = "my_field_provider",
+    build_setting_default = ":dep"
+)
+```
+
+### Build settings and select() {:#build-settings-and-select}
+
+[End to end example](https://github.com/bazelbuild/examples/tree/HEAD/configurations/select_on_build_setting){: .external}
+
+Users can configure attributes on build settings by using
+ [`select()`](/versions/9.1.0/reference/be/functions#select). Build setting targets can be passed to the `flag_values` attribute of
+`config_setting`. The value to match to the configuration is passed as a
+`String` then parsed to the type of the build setting for matching.
+
+```python
+config_setting(
+    name = "my_config",
+    flag_values = {
+        "//example:favorite_flavor": "MANGO"
+    }
+)
+```
+
+## User-defined transitions {:#user-defined-transitions}
+
+A configuration
+[transition](/versions/9.1.0/rules/lib/builtins/transition#transition)
+maps the transformation from one configured target to another within the
+build graph.
+
+Important: Transitions have [memory and performance impact](#memory-performance-considerations).
+
+### Defining {:#defining}
+
+Transitions define configuration changes between rules. For example, a request
+like "compile my dependency for a different CPU than its parent" is handled by a
+transition.
+
+Formally, a transition is a function from an input configuration to one or more
+output configurations. Most transitions are 1:1 such as "override the input
+configuration with `--cpu=ppc`". 1:2+ transitions can also exist but come
+with special restrictions.
+
+In Starlark, transitions are defined much like rules, with a defining
+`transition()`
+[function](/versions/9.1.0/rules/lib/builtins/transition#transition)
+and an implementation function.
+
+```python
+# example/transitions/transitions.bzl
+def _impl(settings, attr):
+    _ignore = (settings, attr)
+    return {"//example:favorite_flavor" : "MINT"}
+
+hot_chocolate_transition = transition(
+    implementation = _impl,
+    inputs = [],
+    outputs = ["//example:favorite_flavor"]
+)
+```
+The `transition()` function takes in an implementation function, a set of
+build settings to read(`inputs`), and a set of build settings to write
+(`outputs`). The implementation function has two parameters, `settings` and
+`attr`. `settings` is a dictionary {`String`:`Object`} of all settings declared
+in the `inputs` parameter to `transition()`.
+
+`attr` is a dictionary of attributes and values of the rule to which the
+transition is attached. When attached as an
+[outgoing edge transition](#outgoing-edge-transitions), the values of these
+attributes are all configured post-select() resolution. When attached as
+an [incoming edge transition](#incoming-edge-transitions), `attr` does not
+include any attributes that use a selector to resolve their value. If an
+incoming edge transition on `--foo` reads attribute `bar` and then also
+selects on `--foo` to set attribute `bar`, then there's a chance for the
+incoming edge transition to read the wrong value of `bar` in the transition.
+
+Note: Since transitions are attached to rule definitions and `select()`s are
+attached to rule instantiations (such as targets), errors related to `select()`s on
+read attributes will pop up when users create targets rather than when rules are
+written. It may be worth taking extra care to communicate to rule users which
+attributes they should be wary of selecting on or taking other precautions.
+
+The implementation function must return a dictionary (or list of
+dictionaries, in the case of
+transitions with multiple output configurations)
+of new build settings values to apply. The returned dictionary keyset(s) must
+contain exactly the set of build settings passed to the `outputs`
+parameter of the transition function. This is true even if a build setting is
+not actually changed over the course of the transition - its original value must
+be explicitly passed through in the returned dictionary.
+
+### Defining 1:2+ transitions {:#defining-1-2-transitions}
+
+[End to end example](https://github.com/bazelbuild/examples/tree/HEAD/configurations/multi_arch_binary){: .external}
+
+[Outgoing edge transition](#outgoing-edge-transitions) can map a single input
+configuration to two or more output configurations. This is useful for defining
+rules that bundle multi-architecture code.
+
+1:2+ transitions are defined by returning a list of dictionaries in the
+transition implementation function.
+
+```python
+# example/transitions/transitions.bzl
+def _impl(settings, attr):
+    _ignore = (settings, attr)
+    return [
+        {"//example:favorite_flavor" : "LATTE"},
+        {"//example:favorite_flavor" : "MOCHA"},
+    ]
+
+coffee_transition = transition(
+    implementation = _impl,
+    inputs = [],
+    outputs = ["//example:favorite_flavor"]
+)
+```
+They can also set custom keys that the rule implementation function can use to
+read individual dependencies:
+
+```python
+# example/transitions/transitions.bzl
+def _impl(settings, attr):
+    _ignore = (settings, attr)
+    return {
+        "Apple deps": {"//command_line_option:cpu": "ppc"},
+        "Linux deps": {"//command_line_option:cpu": "x86"},
+    }
+
+multi_arch_transition = transition(
+    implementation = _impl,
+    inputs = [],
+    outputs = ["//command_line_option:cpu"]
+)
+```
+
+### Attaching transitions {:#attaching-transitions}
+
+[End to end example](https://github.com/bazelbuild/examples/tree/HEAD/configurations/attaching_transitions_to_rules){: .external}
+
+Transitions can be attached in two places: incoming edges and outgoing edges.
+Effectively this means rules can transition their own configuration (incoming
+edge transition) and transition their dependencies' configurations (outgoing
+edge transition).
+
+NOTE: There is currently no way to attach Starlark transitions to native rules.
+If you need to do this, contact
+bazel-discuss@googlegroups.com
+for help with figuring out workarounds.
+
+### Incoming edge transitions {:#incoming-edge-transitions}
+
+Incoming edge transitions are activated by attaching a `transition` object
+(created by `transition()`) to `rule()`'s `cfg` parameter:
+
+```python
+# example/rules.bzl
+load("example/transitions:transitions.bzl", "hot_chocolate_transition")
+drink_rule = rule(
+    implementation = _impl,
+    cfg = hot_chocolate_transition,
+    ...
+```
+
+Incoming edge transitions must be 1:1 transitions.
+
+### Outgoing edge transitions {:#outgoing-edge-transitions}
+
+Outgoing edge transitions are activated by attaching a `transition` object
+(created by `transition()`) to an attribute's `cfg` parameter:
+
+```python
+# example/rules.bzl
+load("example/transitions:transitions.bzl", "coffee_transition")
+drink_rule = rule(
+    implementation = _impl,
+    attrs = { "dep": attr.label(cfg = coffee_transition)}
+    ...
+```
+Outgoing edge transitions can be 1:1 or 1:2+.
+
+See [Accessing attributes with transitions](#accessing-attributes-with-transitions)
+for how to read these keys.
+
+### Transitions on native options {:#transitions-native-options}
+
+[End to end example](https://github.com/bazelbuild/examples/tree/HEAD/configurations/transition_on_native_flag){: .external}
+
+Starlark transitions can also declare reads and writes on native build
+configuration options via a special prefix to the option name.
+
+```python
+# example/transitions/transitions.bzl
+def _impl(settings, attr):
+    _ignore = (settings, attr)
+    return {"//command_line_option:cpu": "k8"}
+
+cpu_transition = transition(
+    implementation = _impl,
+    inputs = [],
+    outputs = ["//command_line_option:cpu"]
+```
+
+#### Unsupported native options {:#unsupported-native-options}
+
+Bazel doesn't support transitioning on `--define` with
+`"//command_line_option:define"`. Instead, use a custom
+[build setting](#user-defined-build-settings). In general, new usages of
+`--define` are discouraged in favor of build settings.
+
+Bazel doesn't support transitioning on `--config`. This is because `--config` is
+an "expansion" flag that expands to other flags.
+
+Crucially, `--config` may include flags that don't affect build configuration,
+such as
+[`--spawn_strategy`](/versions/9.1.0/docs/user-manual#spawn-strategy)
+. Bazel, by design, can't bind such flags to individual targets. This means
+there's no coherent way to apply them in transitions.
+
+As a workaround, you can explicitly itemize the flags that *are* part of
+the configuration in your transition. This requires maintaining the `--config`'s
+expansion in two places, which is a known UI blemish.
+
+### Transitions on allow multiple build settings {:#transitions-multiple-build-settings}
+
+When setting build settings that
+[allow multiple values](#defining-multi-set-string-flags), the value of the
+setting must be set with a list.
+
+```python
+# example/buildsettings/build_settings.bzl
+string_flag = rule(
+    implementation = _impl,
+    build_setting = config.string(flag = True, allow_multiple = True)
+)
+```
+
+```python
+# example/BUILD
+load("//example/buildsettings:build_settings.bzl", "string_flag")
+string_flag(name = "roasts", build_setting_default = "medium")
+```
+
+```python
+# example/transitions/rules.bzl
+def _transition_impl(settings, attr):
+    # Using a value of just "dark" here will throw an error
+    return {"//example:roasts" : ["dark"]},
+
+coffee_transition = transition(
+    implementation = _transition_impl,
+    inputs = [],
+    outputs = ["//example:roasts"]
+)
+```
+
+### No-op transitions {:#no-op-transitions}
+
+If a transition returns `{}`, `[]`, or `None`, this is shorthand for keeping all
+settings at their original values. This can be more convenient than explicitly
+setting each output to itself.
+
+```python
+# example/transitions/transitions.bzl
+def _impl(settings, attr):
+    _ignore = (attr)
+    if settings["//example:already_chosen"] is True:
+      return {}
+    return {
+      "//example:favorite_flavor": "dark chocolate",
+      "//example:include_marshmallows": "yes",
+      "//example:desired_temperature": "38C",
+    }
+
+hot_chocolate_transition = transition(
+    implementation = _impl,
+    inputs = ["//example:already_chosen"],
+    outputs = [
+        "//example:favorite_flavor",
+        "//example:include_marshmallows",
+        "//example:desired_temperature",
+    ]
+)
+```
+
+### Accessing attributes with transitions {:#accessing-attributes-with-transitions}
+
+[End to end example](https://github.com/bazelbuild/examples/tree/HEAD/configurations/read_attr_in_transition){: .external}
+
+When [attaching a transition to an outgoing edge](#outgoing-edge-transitions)
+(regardless of whether the transition is a 1:1 or 1:2+ transition), `ctx.attr` is forced to be a list
+if it isn't already. The order of elements in this list is unspecified.
+
+```python
+# example/transitions/rules.bzl
+def _transition_impl(settings, attr):
+    return {"//example:favorite_flavor" : "LATTE"},
+
+coffee_transition = transition(
+    implementation = _transition_impl,
+    inputs = [],
+    outputs = ["//example:favorite_flavor"]
+)
+
+def _rule_impl(ctx):
+    # Note: List access even though "dep" is not declared as list
+    transitioned_dep = ctx.attr.dep[0]
+
+    # Note: Access doesn't change, other_deps was already a list
+    for other_dep in ctx.attr.other_deps:
+      # ...
+
+coffee_rule = rule(
+    implementation = _rule_impl,
+    attrs = {
+        "dep": attr.label(cfg = coffee_transition)
+        "other_deps": attr.label_list(cfg = coffee_transition)
+    })
+```
+
+If the transition is `1:2+` and sets custom keys, `ctx.split_attr` can be used
+to read individual deps for each key:
+
+```python
+# example/transitions/rules.bzl
+def _impl(settings, attr):
+    _ignore = (settings, attr)
+    return {
+        "Apple deps": {"//command_line_option:cpu": "ppc"},
+        "Linux deps": {"//command_line_option:cpu": "x86"},
+    }
+
+multi_arch_transition = transition(
+    implementation = _impl,
+    inputs = [],
+    outputs = ["//command_line_option:cpu"]
+)
+
+def _rule_impl(ctx):
+    apple_dep = ctx.split_attr.dep["Apple deps"]
+    linux_dep = ctx.split_attr.dep["Linux deps"]
+    # ctx.attr has a list of all deps for all keys. Order is not guaranteed.
+    all_deps = ctx.attr.dep
+
+multi_arch_rule = rule(
+    implementation = _rule_impl,
+    attrs = {
+        "dep": attr.label(cfg = multi_arch_transition)
+    })
+```
+
+See [complete example](https://github.com/bazelbuild/examples/tree/main/configurations/multi_arch_binary)
+here.
+
+## Integration with platforms and toolchains {:#integration-platforms-toolchains}
+
+Many native flags today, like `--cpu` and `--crosstool_top` are related to
+toolchain resolution. In the future, explicit transitions on these types of
+flags will likely be replaced by transitioning on the
+[target platform](/versions/9.1.0/extending/platforms).
+
+## Memory and performance considerations {:#memory-performance-considerations}
+
+Adding transitions, and therefore new configurations, to your build comes at a
+cost: larger build graphs, less comprehensible build graphs, and slower
+builds. It's worth considering these costs when considering
+using transitions in your build rules. Below is an example of how a transition
+might create exponential growth of your build graph.
+
+### Badly behaved builds: a case study {:#badly-behaved-builds}
+
+![Scalability graph](/versions/9.1.0/rules/scalability-graph.png "Scalability graph")
+
+**Figure 1.** Scalability graph showing a top level target and its dependencies.
+
+This graph shows a top level target, `//pkg:app`, which depends on two targets, a
+`//pkg:1_0` and `//pkg:1_1`. Both these targets depend on two targets, `//pkg:2_0` and
+`//pkg:2_1`. Both these targets depend on two targets, `//pkg:3_0` and `//pkg:3_1`.
+This continues on until `//pkg:n_0` and `//pkg:n_1`, which both depend on a single
+target, `//pkg:dep`.
+
+Building `//pkg:app` requires \\(2n+2\\) targets:
+
+* `//pkg:app`
+* `//pkg:dep`
+* `//pkg:i_0` and `//pkg:i_1` for \\(i\\) in \\([1..n]\\)
+
+Imagine you [implement](#user-defined-build-settings) a flag
+`--//foo:owner=` and `//pkg:i_b` applies
+
+    depConfig = myConfig + depConfig.owner="$(myConfig.owner)$(b)"
+
+In other words, `//pkg:i_b` appends `b` to the old value of `--owner` for all
+its deps.
+
+This produces the following [configured targets](/versions/9.1.0/reference/glossary#configured-target):
+
+```
+//pkg:app                              //foo:owner=""
+//pkg:1_0                              //foo:owner=""
+//pkg:1_1                              //foo:owner=""
+//pkg:2_0 (via //pkg:1_0)              //foo:owner="0"
+//pkg:2_0 (via //pkg:1_1)              //foo:owner="1"
+//pkg:2_1 (via //pkg:1_0)              //foo:owner="0"
+//pkg:2_1 (via //pkg:1_1)              //foo:owner="1"
+//pkg:3_0 (via //pkg:1_0 → //pkg:2_0)  //foo:owner="00"
+//pkg:3_0 (via //pkg:1_0 → //pkg:2_1)  //foo:owner="01"
+//pkg:3_0 (via //pkg:1_1 → //pkg:2_0)  //foo:owner="10"
+//pkg:3_0 (via //pkg:1_1 → //pkg:2_1)  //foo:owner="11"
+...
+```
+
+`//pkg:dep` produces \\(2^n\\) configured targets: `config.owner=`
+"\\(b_0b_1...b_n\\)" for all \\(b_i\\) in \\(\{0,1\}\\).
+
+This makes the build graph exponentially larger than the target graph, with
+corresponding memory and performance consequences.
+
+TODO: Add strategies for measurement and mitigation of these issues.
+
+## Further reading {:#further-reading}
+
+For more details on modifying build configurations, see:
+
+ * [Starlark Build Configuration](https://docs.google.com/document/d/1vc8v-kXjvgZOdQdnxPTaV0rrLxtP2XwnD2tAZlYJOqw/edit?usp=sharing){: .external}
+ * Full [set](https://github.com/bazelbuild/examples/tree/HEAD/configurations){: .external} of end to end examples
diff --git a/versions/9.1.0/extending/depsets.mdx b/versions/9.1.0/extending/depsets.mdx
new file mode 100644
index 00000000..b690eb53
--- /dev/null
+++ b/versions/9.1.0/extending/depsets.mdx
@@ -0,0 +1,343 @@
+---
+title: 'Depsets'
+---
+
+[Depsets](/versions/9.1.0/rules/lib/builtins/depset) are a specialized data structure for efficiently
+collecting data across a target’s transitive dependencies. They are an essential
+element of rule processing.
+
+The defining feature of depset is its time- and space-efficient union operation.
+The depset constructor accepts a list of elements ("direct") and a list of other
+depsets ("transitive"), and returns a depset representing a set containing all the
+direct elements and the union of all the transitive sets. Conceptually, the
+constructor creates a new graph node that has the direct and transitive nodes
+as its successors. Depsets have a well-defined ordering semantics, based on
+traversal of this graph.
+
+Example uses of depsets include:
+
+*   Storing the paths of all object files for a program’s libraries, which can
+    then be passed to a linker action through a provider.
+
+*   For an interpreted language, storing the transitive source files that are
+    included in an executable's runfiles.
+
+## Description and operations
+
+Conceptually, a depset is a directed acyclic graph (DAG) that typically looks
+similar to the target graph. It is constructed from the leaves up to the root.
+Each target in a dependency chain can add its own contents on top of the
+previous without having to read or copy them.
+
+Each node in the DAG holds a list of direct elements and a list of child nodes.
+The contents of the depset are the transitive elements, such as the direct elements
+of all the nodes. A new depset can be created using the
+[depset](/versions/9.1.0/rules/lib/globals/bzl#depset) constructor: it accepts a list of direct
+elements and another list of child nodes.
+
+```python
+s = depset(["a", "b", "c"])
+t = depset(["d", "e"], transitive = [s])
+
+print(s)    # depset(["a", "b", "c"])
+print(t)    # depset(["d", "e", "a", "b", "c"])
+```
+
+To retrieve the contents of a depset, use the
+[to_list()](/versions/9.1.0/rules/lib/builtins/depset#to_list) method. It returns a list of all transitive
+elements, not including duplicates. There is no way to directly inspect the
+precise structure of the DAG, although this structure does affect the order in
+which the elements are returned.
+
+```python
+s = depset(["a", "b", "c"])
+
+print("c" in s.to_list())              # True
+print(s.to_list() == ["a", "b", "c"])  # True
+```
+
+The allowed items in a depset are restricted, just as the allowed keys in
+dictionaries are restricted. In particular, depset contents may not be mutable.
+
+Depsets use reference equality: a depset is equal to itself, but unequal to any
+other depset, even if they have the same contents and same internal structure.
+
+```python
+s = depset(["a", "b", "c"])
+t = s
+print(s == t)  # True
+
+t = depset(["a", "b", "c"])
+print(s == t)  # False
+
+d = {}
+d[s] = None
+d[t] = None
+print(len(d))  # 2
+```
+
+To compare depsets by their contents, convert them to sorted lists.
+
+```python
+s = depset(["a", "b", "c"])
+t = depset(["c", "b", "a"])
+print(sorted(s.to_list()) == sorted(t.to_list()))  # True
+```
+
+There is no ability to remove elements from a depset. If this is needed, you
+must read out the entire contents of the depset, filter the elements you want to
+remove, and reconstruct a new depset. This is not particularly efficient.
+
+```python
+s = depset(["a", "b", "c"])
+t = depset(["b", "c"])
+
+# Compute set difference s - t. Precompute t.to_list() so it's not done
+# in a loop, and convert it to a dictionary for fast membership tests.
+t_items = {e: None for e in t.to_list()}
+diff_items = [x for x in s.to_list() if x not in t_items]
+# Convert back to depset if it's still going to be used for union operations.
+s = depset(diff_items)
+print(s)  # depset(["a"])
+```
+
+### Order
+
+The `to_list` operation performs a traversal over the DAG. The kind of traversal
+depends on the *order* that was specified at the time the depset was
+constructed. It is useful for Bazel to support multiple orders because sometimes
+tools care about the order of their inputs. For example, a linker action may
+need to ensure that if `B` depends on `A`, then `A.o` comes before `B.o` on the
+linker’s command line. Other tools might have the opposite requirement.
+
+Three traversal orders are supported: `postorder`, `preorder`, and
+`topological`. The first two work exactly like [tree
+traversals](https://en.wikipedia.org/wiki/Tree_traversal#Depth-first_search)
+except that they operate on DAGs and skip already visited nodes. The third order
+works as a topological sort from root to leaves, essentially the same as
+preorder except that shared children are listed only after all of their parents.
+Preorder and postorder operate as left-to-right traversals, but note that within
+each node direct elements have no order relative to children. For topological
+order, there is no left-to-right guarantee, and even the
+all-parents-before-child guarantee does not apply in the case that there are
+duplicate elements in different nodes of the DAG.
+
+```python
+# This demonstrates different traversal orders.
+
+def create(order):
+  cd = depset(["c", "d"], order = order)
+  gh = depset(["g", "h"], order = order)
+  return depset(["a", "b", "e", "f"], transitive = [cd, gh], order = order)
+
+print(create("postorder").to_list())  # ["c", "d", "g", "h", "a", "b", "e", "f"]
+print(create("preorder").to_list())   # ["a", "b", "e", "f", "c", "d", "g", "h"]
+```
+
+```python
+# This demonstrates different orders on a diamond graph.
+
+def create(order):
+  a = depset(["a"], order=order)
+  b = depset(["b"], transitive = [a], order = order)
+  c = depset(["c"], transitive = [a], order = order)
+  d = depset(["d"], transitive = [b, c], order = order)
+  return d
+
+print(create("postorder").to_list())    # ["a", "b", "c", "d"]
+print(create("preorder").to_list())     # ["d", "b", "a", "c"]
+print(create("topological").to_list())  # ["d", "b", "c", "a"]
+```
+
+Due to how traversals are implemented, the order must be specified at the time
+the depset is created with the constructor’s `order` keyword argument. If this
+argument is omitted, the depset has the special `default` order, in which case
+there are no guarantees about the order of any of its elements (except that it
+is deterministic).
+
+## Full example
+
+This example is available at
+[https://github.com/bazelbuild/examples/tree/main/rules/depsets](https://github.com/bazelbuild/examples/tree/main/rules/depsets).
+
+Suppose there is a hypothetical interpreted language Foo. In order to build
+each `foo_binary` you need to know all the `*.foo` files that it directly or
+indirectly depends on.
+
+```python
+# //depsets:BUILD
+
+load(":foo.bzl", "foo_library", "foo_binary")
+
+# Our hypothetical Foo compiler.
+py_binary(
+    name = "foocc",
+    srcs = ["foocc.py"],
+)
+
+foo_library(
+    name = "a",
+    srcs = ["a.foo", "a_impl.foo"],
+)
+
+foo_library(
+    name = "b",
+    srcs = ["b.foo", "b_impl.foo"],
+    deps = [":a"],
+)
+
+foo_library(
+    name = "c",
+    srcs = ["c.foo", "c_impl.foo"],
+    deps = [":a"],
+)
+
+foo_binary(
+    name = "d",
+    srcs = ["d.foo"],
+    deps = [":b", ":c"],
+)
+```
+
+```python
+# //depsets:foocc.py
+
+# "Foo compiler" that just concatenates its inputs to form its output.
+import sys
+
+if __name__ == "__main__":
+  assert len(sys.argv) >= 1
+  output = open(sys.argv[1], "wt")
+  for path in sys.argv[2:]:
+    input = open(path, "rt")
+    output.write(input.read())
+```
+
+Here, the transitive sources of the binary `d` are all of the `*.foo` files in
+the `srcs` fields of `a`, `b`, `c`, and `d`. In order for the `foo_binary`
+target to know about any file besides `d.foo`, the `foo_library` targets need to
+pass them along in a provider. Each library receives the providers from its own
+dependencies, adds its own immediate sources, and passes on a new provider with
+the augmented contents. The `foo_binary` rule does the same, except that instead
+of returning a provider, it uses the complete list of sources to construct a
+command line for an action.
+
+Here’s a complete implementation of the `foo_library` and `foo_binary` rules.
+
+```python
+# //depsets/foo.bzl
+
+# A provider with one field, transitive_sources.
+foo_files = provider(fields = ["transitive_sources"])
+
+def get_transitive_srcs(srcs, deps):
+  """Obtain the source files for a target and its transitive dependencies.
+
+  Args:
+    srcs: a list of source files
+    deps: a list of targets that are direct dependencies
+  Returns:
+    a collection of the transitive sources
+  """
+  return depset(
+        srcs,
+        transitive = [dep[foo_files].transitive_sources for dep in deps])
+
+def _foo_library_impl(ctx):
+  trans_srcs = get_transitive_srcs(ctx.files.srcs, ctx.attr.deps)
+  return [foo_files(transitive_sources=trans_srcs)]
+
+foo_library = rule(
+    implementation = _foo_library_impl,
+    attrs = {
+        "srcs": attr.label_list(allow_files=True),
+        "deps": attr.label_list(),
+    },
+)
+
+def _foo_binary_impl(ctx):
+  foocc = ctx.executable._foocc
+  out = ctx.outputs.out
+  trans_srcs = get_transitive_srcs(ctx.files.srcs, ctx.attr.deps)
+  srcs_list = trans_srcs.to_list()
+  ctx.actions.run(executable = foocc,
+                  arguments = [out.path] + [src.path for src in srcs_list],
+                  inputs = srcs_list + [foocc],
+                  outputs = [out])
+
+foo_binary = rule(
+    implementation = _foo_binary_impl,
+    attrs = {
+        "srcs": attr.label_list(allow_files=True),
+        "deps": attr.label_list(),
+        "_foocc": attr.label(default=Label("//depsets:foocc"),
+                             allow_files=True, executable=True, cfg="host")
+    },
+    outputs = {"out": "%{name}.out"},
+)
+```
+
+You can test this by copying these files into a fresh package, renaming the
+labels appropriately, creating the source `*.foo` files with dummy content, and
+building the `d` target.
+
+## Performance
+
+To see the motivation for using depsets, consider what would happen if
+`get_transitive_srcs()` collected its sources in a list.
+
+```python
+def get_transitive_srcs(srcs, deps):
+  trans_srcs = []
+  for dep in deps:
+    trans_srcs += dep[foo_files].transitive_sources
+  trans_srcs += srcs
+  return trans_srcs
+```
+
+This does not take into account duplicates, so the source files for `a`
+will appear twice on the command line and twice in the contents of the output
+file.
+
+An alternative is using a general set, which can be simulated by a
+dictionary where the keys are the elements and all the keys map to `True`.
+
+```python
+def get_transitive_srcs(srcs, deps):
+  trans_srcs = {}
+  for dep in deps:
+    for file in dep[foo_files].transitive_sources:
+      trans_srcs[file] = True
+  for file in srcs:
+    trans_srcs[file] = True
+  return trans_srcs
+```
+
+This gets rid of the duplicates, but it makes the order of the command line
+arguments (and therefore the contents of the files) unspecified, although still
+deterministic.
+
+Moreover, both approaches are asymptotically worse than the depset-based
+approach. Consider the case where there is a long chain of dependencies on
+Foo libraries. Processing every rule requires copying all of the transitive
+sources that came before it into a new data structure. This means that the
+time and space cost for analyzing an individual library or binary target
+is proportional to its own height in the chain. For a chain of length n,
+foolib_1 ← foolib_2 ← … ← foolib_n, the overall cost is effectively O(n^2).
+
+Generally speaking, depsets should be used whenever you are accumulating
+information through your transitive dependencies. This helps ensure that
+your build scales well as your target graph grows deeper.
+
+Finally, it’s important to not retrieve the contents of the depset
+unnecessarily in rule implementations. One call to `to_list()`
+at the end in a binary rule is fine, since the overall cost is just O(n). It’s
+when many non-terminal targets try to call `to_list()` that quadratic behavior
+occurs.
+
+For more information about using depsets efficiently, see the [performance](/versions/9.1.0/rules/performance) page.
+
+## API Reference
+
+Please see [here](/versions/9.1.0/rules/lib/builtins/depset) for more details.
+
diff --git a/versions/9.1.0/extending/exec-groups.mdx b/versions/9.1.0/extending/exec-groups.mdx
new file mode 100644
index 00000000..7cf8694d
--- /dev/null
+++ b/versions/9.1.0/extending/exec-groups.mdx
@@ -0,0 +1,219 @@
+---
+title: 'Execution Groups'
+---
+
+Execution groups allow for multiple execution platforms within a single target.
+Each execution group has its own [toolchain](/versions/9.1.0/extending/toolchains) dependencies and
+performs its own [toolchain resolution](/versions/9.1.0/extending/toolchains#toolchain-resolution).
+
+## Current status {#current-status}
+
+Execution groups for certain natively declared actions, like `CppLink`, can be
+used inside `exec_properties` to set per-action, per-target execution
+requirements. For more details, see the
+[Default execution groups](#exec-groups-for-native-rules) section.
+
+## Background {#background}
+
+Execution groups allow the rule author to define sets of actions, each with a
+potentially different execution platform. Multiple execution platforms can allow
+actions to execution differently, for example compiling an iOS app on a remote
+(linux) worker and then linking/code signing on a local mac worker.
+
+Being able to define groups of actions also helps alleviate the usage of action
+mnemonics as a proxy for specifying actions. Mnemonics are not guaranteed to be
+unique and can only reference a single action. This is especially helpful in
+allocating extra resources to specific memory and processing intensive actions
+like linking in C++ builds without over-allocating to less demanding tasks.
+
+## Defining execution groups {#defining-exec-groups}
+
+During rule definition, rule authors can
+[declare](/versions/9.1.0/rules/lib/globals/bzl#exec_group)
+a set of execution groups. On each execution group, the rule author can specify
+everything needed to select an execution platform for that execution group,
+namely any constraints via `exec_compatible_with` and toolchain types via
+`toolchain`.
+
+```python
+# foo.bzl
+my_rule = rule(
+    _impl,
+    exec_groups = {
+        "link": exec_group(
+            exec_compatible_with = ["@platforms//os:linux"],
+            toolchains = ["//foo:toolchain_type"],
+        ),
+        "test": exec_group(
+            toolchains = ["//foo_tools:toolchain_type"],
+        ),
+    },
+    attrs = {
+        "_compiler": attr.label(cfg = config.exec("link"))
+    },
+)
+```
+
+In the code snippet above, you can see that tool dependencies can also specify
+transition for an exec group using the
+[`cfg`](/versions/9.1.0/rules/lib/toplevel/attr#label)
+attribute param and the
+[`config`](/versions/9.1.0/rules/lib/toplevel/config)
+module. The module exposes an `exec` function which takes a single string
+parameter which is the name of the exec group for which the dependency should be
+built.
+
+As on native rules, the `test` execution group is present by default on Starlark
+test rules.
+
+## Accessing execution groups {#accessing-exec-groups}
+
+In the rule implementation, you can declare that actions should be run on the
+execution platform of an execution group. You can do this by using the `exec_group`
+param of action generating methods, specifically [`ctx.actions.run`]
+(/rules/lib/builtins/actions#run) and
+[`ctx.actions.run_shell`](/versions/9.1.0/rules/lib/builtins/actions#run_shell).
+
+```python
+# foo.bzl
+def _impl(ctx):
+  ctx.actions.run(
+     inputs = [ctx.attr._some_tool, ctx.srcs[0]]
+     exec_group = "compile",
+     # ...
+  )
+```
+
+Rule authors will also be able to access the [resolved toolchains](/versions/9.1.0/extending/toolchains#toolchain-resolution)
+of execution groups, similarly to how you
+can access the resolved toolchain of a target:
+
+```python
+# foo.bzl
+def _impl(ctx):
+  foo_info = ctx.exec_groups["link"].toolchains["//foo:toolchain_type"].fooinfo
+  ctx.actions.run(
+     inputs = [foo_info, ctx.srcs[0]]
+     exec_group = "link",
+     # ...
+  )
+```
+
+Note: If an action uses a toolchain from an execution group, but doesn't specify
+that execution group in the action declaration, that may potentially cause
+issues. A mismatch like this may not immediately cause failures, but is a latent
+problem.
+
+### Default execution groups {#exec-groups-for-native-rules}
+
+The following execution groups are predefined:
+
+* `test`: Test runner actions (for more details, see
+  the [execution platform section of the Test Encylopedia](/versions/9.1.0/reference/test-encyclopedia#execution-platform)).
+* `cpp_link`: C++ linking actions.
+
+## Using execution groups to set execution properties {#using-exec-groups-for-exec-properties}
+
+Execution groups are integrated with the
+[`exec_properties`](/versions/9.1.0/reference/be/common-definitions#common-attributes)
+attribute that exists on every rule and allows the target writer to specify a
+string dict of properties that is then passed to the execution machinery. For
+example, if you wanted to set some property, say memory, for the target and give
+certain actions a higher memory allocation, you would write an `exec_properties`
+entry with an execution-group-augmented key, such as:
+
+```python
+# BUILD
+my_rule(
+    name = 'my_target',
+    exec_properties = {
+        'mem': '12g',
+        'link.mem': '16g'
+    }
+    …
+)
+```
+
+All actions with `exec_group = "link"` would see the exec properties
+dictionary as `{"mem": "16g"}`. As you see here, execution-group-level
+settings override target-level settings.
+
+## Using execution groups to set platform constraints {#using-exec-groups-for-platform-constraints}
+
+Execution groups are also integrated with the
+[`exec_compatible_with`](/versions/9.1.0/reference/be/common-definitions#common-attributes) and
+[`exec_group_compatible_with`](/versions/9.1.0/reference/be/common-definitions#common-attributes)
+attributes that exist on every rule and allow the target writer to specify
+additional constraints that must be satisfied by the execution platforms
+selected for the target's actions.
+
+For example, if the rule `my_test` defines the `link` execution group in
+addition to the default and the `test` execution group, then the following
+usage of these attributes would run actions in the default execution group on
+a platform with a high number of CPUs, the test action on Linux, and the link
+action on the default execution platform:
+
+```python
+# BUILD
+constraint_setting(name = "cpu")
+constraint_value(name = "high_cpu", constraint_setting = ":cpu")
+
+platform(
+  name = "high_cpu_platform",
+  constraint_values = [":high_cpu"],
+  exec_properties = {
+    "cpu": "256",
+  },
+)
+
+my_test(
+  name = "my_test",
+  exec_compatible_with = ["//constraints:high_cpu"],
+  exec_group_compatible_with = {
+    "test": ["@platforms//os:linux"],
+  },
+  ...
+)
+```
+
+### Execution groups for native rules {#execution-groups-for-native-rules}
+
+The following execution groups are available for actions defined by native
+rules:
+
+* `test`: Test runner actions.
+* `cpp_link`: C++ linking actions.
+
+### Execution groups and platform execution properties {#platform-execution-properties}
+
+It is possible to define `exec_properties` for arbitrary execution groups on
+platform targets (unlike `exec_properties` set directly on a target, where
+properties for unknown execution groups are rejected). Targets then inherit the
+execution platform's `exec_properties` that affect the default execution group
+and any other relevant execution groups.
+
+For example, suppose running tests on the exec platform requires some resource
+to be available, but it isn't required for compiling and linking; this can be
+modelled as follows:
+
+```python
+constraint_setting(name = "resource")
+constraint_value(name = "has_resource", constraint_setting = ":resource")
+
+platform(
+    name = "platform_with_resource",
+    constraint_values = [":has_resource"],
+    exec_properties = {
+        "test.resource": "...",
+    },
+)
+
+cc_test(
+    name = "my_test",
+    srcs = ["my_test.cc"],
+    exec_compatible_with = [":has_resource"],
+)
+```
+
+`exec_properties` defined directly on targets take precedence over those that
+are inherited from the execution platform.
diff --git a/versions/9.1.0/extending/legacy-macros.mdx b/versions/9.1.0/extending/legacy-macros.mdx
new file mode 100644
index 00000000..af915ac1
--- /dev/null
+++ b/versions/9.1.0/extending/legacy-macros.mdx
@@ -0,0 +1,252 @@
+---
+title: 'Legacy Macros'
+---
+
+Legacy macros are unstructured functions called from `BUILD` files that can
+create targets. By the end of the
+[loading phase](/versions/9.1.0/extending/concepts#evaluation-model), legacy macros don't exist
+anymore, and Bazel sees only the concrete set of instantiated rules.
+
+## Why you shouldn't use legacy macros (and should use Symbolic macros instead) {#no-legacy-macros}
+
+Where possible you should use [symbolic macros](/versions/9.1.0/extending/macros#macros).
+
+Symbolic macros
+
+*   Prevent action at a distance
+*   Make it possible to hide implementation details through granular visibility
+*   Take typed attributes, which in turn means automatic label and select
+    conversion.
+*   Are more readable
+*   Will soon have [lazy evaluation](/versions/9.1.0/extending/macros#laziness)
+
+## Usage {#usage}
+
+The typical use case for a macro is when you want to reuse a rule.
+
+For example, genrule in a `BUILD` file generates a file using `//:generator`
+with a `some_arg` argument hardcoded in the command:
+
+```python
+genrule(
+    name = "file",
+    outs = ["file.txt"],
+    cmd = "$(location //:generator) some_arg > $@",
+    tools = ["//:generator"],
+)
+```
+
+Note: `$@` is a
+[Make variable](/versions/9.1.0/reference/be/make-variables#predefined_genrule_variables) that
+refers to the execution-time locations of the files in the `outs` attribute
+list. It is equivalent to `$(locations :file.txt)`.
+
+If you want to generate more files with different arguments, you may want to
+extract this code to a macro function. To create a macro called
+`file_generator`, which has `name` and `arg` parameters, we can replace the
+genrule with the following:
+
+```python
+load("//path:generator.bzl", "file_generator")
+
+file_generator(
+    name = "file",
+    arg = "some_arg",
+)
+
+file_generator(
+    name = "file-two",
+    arg = "some_arg_two",
+)
+
+file_generator(
+    name = "file-three",
+    arg = "some_arg_three",
+)
+```
+
+Here, you load the `file_generator` symbol from a `.bzl` file located in the
+`//path` package. By putting macro function definitions in a separate `.bzl`
+file, you keep your `BUILD` files clean and declarative, The `.bzl` file can be
+loaded from any package in the workspace.
+
+Finally, in `path/generator.bzl`, write the definition of the macro to
+encapsulate and parameterize the original genrule definition:
+
+```python
+def file_generator(name, arg, visibility=None):
+  native.genrule(
+    name = name,
+    outs = [name + ".txt"],
+    cmd = "$(location //:generator) %s > $@" % arg,
+    tools = ["//:generator"],
+    visibility = visibility,
+  )
+```
+
+You can also use macros to chain rules together. This example shows chained
+genrules, where a genrule uses the outputs of a previous genrule as inputs:
+
+```python
+def chained_genrules(name, visibility=None):
+  native.genrule(
+    name = name + "-one",
+    outs = [name + ".one"],
+    cmd = "$(location :tool-one) $@",
+    tools = [":tool-one"],
+    visibility = ["//visibility:private"],
+  )
+
+  native.genrule(
+    name = name + "-two",
+    srcs = [name + ".one"],
+    outs = [name + ".two"],
+    cmd = "$(location :tool-two) $< $@",
+    tools = [":tool-two"],
+    visibility = visibility,
+  )
+```
+
+The example only assigns a visibility value to the second genrule. This allows
+macro authors to hide the outputs of intermediate rules from being depended upon
+by other targets in the workspace.
+
+Note: Similar to `$@` for outputs, `$<` expands to the locations of files in the
+`srcs` attribute list.
+
+## Expanding macros {#expanding-macros}
+
+When you want to investigate what a macro does, use the `query` command with
+`--output=build` to see the expanded form:
+
+```none
+$ bazel query --output=build :file
+# /absolute/path/test/ext.bzl:42:3
+genrule(
+  name = "file",
+  tools = ["//:generator"],
+  outs = ["//test:file.txt"],
+  cmd = "$(location //:generator) some_arg > $@",
+)
+```
+
+## Instantiating native rules {#instantiating-native-rules}
+
+Native rules (rules that don't need a `load()` statement) can be instantiated
+from the [native](/versions/9.1.0/rules/lib/toplevel/native) module:
+
+```python
+def my_macro(name, visibility=None):
+  native.cc_library(
+    name = name,
+    srcs = ["main.cc"],
+    visibility = visibility,
+  )
+```
+
+If you need to know the package name (for example, which `BUILD` file is calling
+the macro), use the function
+[native.package_name()](/versions/9.1.0/rules/lib/toplevel/native#package_name). Note that
+`native` can only be used in `.bzl` files, and not in `BUILD` files.
+
+## Label resolution in macros {#label-resolution}
+
+Since legacy macros are evaluated in the
+[loading phase](/versions/9.1.0/extending/concepts#evaluation-model), label strings such as
+`"//foo:bar"` that occur in a legacy macro are interpreted relative to the
+`BUILD` file in which the macro is used rather than relative to the `.bzl` file
+in which it is defined. This behavior is generally undesirable for macros that
+are meant to be used in other repositories, such as because they are part of a
+published Starlark ruleset.
+
+To get the same behavior as for Starlark rules, wrap the label strings with the
+[`Label`](/versions/9.1.0/rules/lib/builtins/Label#Label) constructor:
+
+```python
+# @my_ruleset//rules:defs.bzl
+def my_cc_wrapper(name, deps = [], **kwargs):
+  native.cc_library(
+    name = name,
+    deps = deps + select({
+      # Due to the use of Label, this label is resolved within @my_ruleset,
+      # regardless of its site of use.
+      Label("//config:needs_foo"): [
+        # Due to the use of Label, this label will resolve to the correct target
+        # even if the canonical name of @dep_of_my_ruleset should be different
+        # in the main repo, such as due to repo mappings.
+        Label("@dep_of_my_ruleset//tools:foo"),
+      ],
+      "//conditions:default": [],
+    }),
+    **kwargs,
+  )
+```
+
+With the `--incompatible_resolve_select_keys_eagerly` flag enabled, all keys
+that are label strings will be automatically resolved to `Label` objects
+relative to the package of the file that contains the `select` call. If this is
+not chosen, wrap the label string with
+[native.package_relative_label()](/versions/9.1.0/rules/lib/toplevel/native#package_relative_label).
+
+## Debugging {#debugging}
+
+*   `bazel query --output=build //my/path:all` will show you how the `BUILD`
+    file looks after evaluation. All legacy macros, globs, loops are expanded.
+    Known limitation: `select` expressions are not shown in the output.
+
+*   You may filter the output based on `generator_function` (which function
+    generated the rules) or `generator_name` (the name attribute of the macro):
+    `bash $ bazel query --output=build 'attr(generator_function, my_macro,
+    //my/path:all)'`
+
+*   To find out where exactly the rule `foo` is generated in a `BUILD` file, you
+    can try the following trick. Insert this line near the top of the `BUILD`
+    file: `cc_library(name = "foo")`. Run Bazel. You will get an exception when
+    the rule `foo` is created (due to a name conflict), which will show you the
+    full stack trace.
+
+*   You can also use [print](/versions/9.1.0/rules/lib/globals/all#print) for debugging. It
+    displays the message as a `DEBUG` log line during the loading phase. Except
+    in rare cases, either remove `print` calls, or make them conditional under a
+    `debugging` parameter that defaults to `False` before submitting the code to
+    the depot.
+
+## Errors {#errors}
+
+If you want to throw an error, use the [fail](/versions/9.1.0/rules/lib/globals/all#fail)
+function. Explain clearly to the user what went wrong and how to fix their
+`BUILD` file. It is not possible to catch an error.
+
+```python
+def my_macro(name, deps, visibility=None):
+  if len(deps) < 2:
+    fail("Expected at least two values in deps")
+  # ...
+```
+
+## Conventions {#conventions}
+
+*   All public functions (functions that don't start with underscore) that
+    instantiate rules must have a `name` argument. This argument should not be
+    optional (don't give a default value).
+
+*   Public functions should use a docstring following
+    [Python conventions](https://www.python.org/dev/peps/pep-0257/#one-line-docstrings).
+
+*   In `BUILD` files, the `name` argument of the macros must be a keyword
+    argument (not a positional argument).
+
+*   The `name` attribute of rules generated by a macro should include the name
+    argument as a prefix. For example, `macro(name = "foo")` can generate a
+    `cc_library` `foo` and a genrule `foo_gen`.
+
+*   In most cases, optional parameters should have a default value of `None`.
+    `None` can be passed directly to native rules, which treat it the same as if
+    you had not passed in any argument. Thus, there is no need to replace it
+    with `0`, `False`, or `[]` for this purpose. Instead, the macro should defer
+    to the rules it creates, as their defaults may be complex or may change over
+    time. Additionally, a parameter that is explicitly set to its default value
+    looks different than one that is never set (or set to `None`) when accessed
+    through the query language or build-system internals.
+
+*   Macros should have an optional `visibility` argument.
diff --git a/versions/9.1.0/extending/macros.mdx b/versions/9.1.0/extending/macros.mdx
new file mode 100644
index 00000000..34d03193
--- /dev/null
+++ b/versions/9.1.0/extending/macros.mdx
@@ -0,0 +1,463 @@
+---
+title: 'Macros'
+---
+
+This page covers the basics of using macros and includes typical use cases,
+debugging, and conventions.
+
+A macro is a function called from the `BUILD` file that can instantiate rules.
+Macros are mainly used for encapsulation and code reuse of existing rules and
+other macros.
+
+Macros come in two flavors: symbolic macros, which are described on this page,
+and [legacy macros](/versions/9.1.0/extending/legacy-macros). Where possible, we recommend using
+symbolic macros for code clarity.
+
+Symbolic macros offer typed arguments (string to label conversion, relative to
+where the macro was called) and the ability to restrict and specify the
+visibility of targets created. They are designed to be amenable to lazy
+evaluation (which will be added in a future Bazel release). Symbolic macros are
+available by default in Bazel 8. Where this document mentions `macros`, it's
+referring to **symbolic macros**.
+
+An executable example of symbolic macros can be found in the
+[examples repository](https://github.com/bazelbuild/examples/tree/main/macros).
+
+## Usage {#usage}
+
+Macros are defined in `.bzl` files by calling the
+[`macro()`](https://bazel.build/versions/9.1.0/rules/lib/globals/bzl.html#macro) function with
+two required parameters: `attrs` and `implementation`.
+
+### Attributes {#attributes}
+
+`attrs` accepts a dictionary of attribute name to [attribute
+types](https://bazel.build/versions/9.1.0/rules/lib/toplevel/attr#members), which represents
+the arguments to the macro. Two common attributes – `name` and `visibility` –
+are implicitly added to all macros and are not included in the dictionary passed
+to `attrs`.
+
+```starlark
+# macro/macro.bzl
+my_macro = macro(
+    attrs = {
+        "deps": attr.label_list(mandatory = True, doc = "The dependencies passed to the inner cc_binary and cc_test targets"),
+        "create_test": attr.bool(default = False, configurable = False, doc = "If true, creates a test target"),
+    },
+    implementation = _my_macro_impl,
+)
+```
+
+Attribute type declarations accept the
+[parameters](https://bazel.build/versions/9.1.0/rules/lib/toplevel/attr#parameters),
+`mandatory`, `default`, and `doc`. Most attribute types also accept the
+`configurable` parameter, which determines whether the attribute accepts
+`select`s. If an attribute is `configurable`, it will parse non-`select` values
+as an unconfigurable `select` – `"foo"` will become
+`select({"//conditions:default": "foo"})`. Learn more in [selects](#selects).
+
+#### Attribute inheritance {#attribute-inheritance}
+
+Macros are often intended to wrap a rule (or another macro), and the macro's
+author often wants to forward the bulk of the wrapped symbol's attributes
+unchanged, using `**kwargs`, to the macro's main target (or main inner macro).
+
+To support this pattern, a macro can *inherit attributes* from a rule or another
+macro by passing the [rule](https://bazel.build/versions/9.1.0/rules/lib/builtins/rule) or
+[macro symbol](https://bazel.build/versions/9.1.0/rules/lib/builtins/macro) to `macro()`'s
+`inherit_attrs` argument. (You can also use the special string `"common"`
+instead of a rule or macro symbol to inherit the [common attributes defined for
+all Starlark build
+rules](https://bazel.build/versions/9.1.0/reference/be/common-definitions#common-attributes).)
+Only public attributes get inherited, and the attributes in the macro's own
+`attrs` dictionary override inherited attributes with the same name. You can
+also *remove* inherited attributes by using `None` as a value in the `attrs`
+dictionary:
+
+```starlark
+# macro/macro.bzl
+my_macro = macro(
+    inherit_attrs = native.cc_library,
+    attrs = {
+        # override native.cc_library's `local_defines` attribute
+        "local_defines": attr.string_list(default = ["FOO"]),
+        # do not inherit native.cc_library's `defines` attribute
+        "defines": None,
+    },
+    ...
+)
+```
+
+The default value of non-mandatory inherited attributes is always overridden to
+be `None`, regardless of the original attribute definition's default value. If
+you need to examine or modify an inherited non-mandatory attribute – for
+example, if you want to add a tag to an inherited `tags` attribute – you must
+make sure to handle the `None` case in your macro's implementation function:
+
+```starlark
+# macro/macro.bzl
+def _my_macro_impl(name, visibility, tags, **kwargs):
+    # Append a tag; tags attr is an inherited non-mandatory attribute, and
+    # therefore is None unless explicitly set by the caller of our macro.
+    my_tags = (tags or []) + ["another_tag"]
+    native.cc_library(
+        ...
+        tags = my_tags,
+        **kwargs,
+    )
+    ...
+```
+
+### Implementation {#implementation}
+
+`implementation` accepts a function which contains the logic of the macro.
+Implementation functions often create targets by calling one or more rules, and
+they are usually private (named with a leading underscore). Conventionally,
+they are named the same as their macro, but prefixed with `_` and suffixed with
+`_impl`.
+
+Unlike rule implementation functions, which take a single argument (`ctx`) that
+contains a reference to the attributes, macro implementation functions accept a
+parameter for each argument.
+
+```starlark
+# macro/macro.bzl
+def _my_macro_impl(name, visibility, deps, create_test):
+    cc_library(
+        name = name + "_cc_lib",
+        deps = deps,
+    )
+
+    if create_test:
+        cc_test(
+            name = name + "_test",
+            srcs = ["my_test.cc"],
+            deps = deps,
+        )
+```
+
+If a macro inherits attributes, its implementation function *must* have a
+`**kwargs` residual keyword parameter, which can be forwarded to the call that
+invokes the inherited rule or submacro. (This helps ensure that your macro won't
+be broken if the rule or macro which from which you are inheriting adds a new
+attribute.)
+
+### Declaration {#declaration}
+
+Macros are declared by loading and calling their definition in a `BUILD` file.
+
+```starlark
+
+# pkg/BUILD
+
+my_macro(
+    name = "macro_instance",
+    deps = ["src.cc"] + select(
+        {
+            "//config_setting:special": ["special_source.cc"],
+            "//conditions:default": [],
+        },
+    ),
+    create_tests = True,
+)
+```
+
+This would create targets
+`//pkg:macro_instance_cc_lib` and`//pkg:macro_instance_test`.
+
+Just like in rule calls, if an attribute value in a macro call is set to `None`,
+that attribute is treated as if it was omitted by the macro's caller. For
+example, the following two macro calls are equivalent:
+
+```starlark
+# pkg/BUILD
+my_macro(name = "abc", srcs = ["src.cc"], deps = None)
+my_macro(name = "abc", srcs = ["src.cc"])
+```
+
+This is generally not useful in `BUILD` files, but is helpful when
+programmatically wrapping a macro inside another macro.
+
+## Details {#usage-details}
+
+### Naming conventions for targets created {#naming}
+
+The names of any targets or submacros created by a symbolic macro must
+either match the macro's `name` parameter or must be prefixed by `name` followed
+by `_` (preferred), `.` or `-`. For example, `my_macro(name = "foo")` may only
+create files or targets named `foo`, or prefixed by `foo_`, `foo-` or `foo.`,
+for example, `foo_bar`.
+
+Targets or files that violate macro naming convention can be declared, but
+cannot be built and cannot be used as dependencies.
+
+Non-macro files and targets within the same package as a macro instance should
+*not* have names that conflict with potential macro target names, though this
+exclusivity is not enforced. We are in the progress of implementing
+[lazy evaluation](#laziness) as a performance improvement for Symbolic macros,
+which will be impaired in packages that violate the naming schema.
+
+### Restrictions {#restrictions}
+
+Symbolic macros have some additional restrictions compared to legacy macros.
+
+Symbolic macros
+
+*   must take a `name` argument and a `visibility` argument
+*   must have an `implementation` function
+*   may not return values
+*   may not mutate their arguments
+*   may not call `native.existing_rules()` unless they are special `finalizer`
+    macros
+*   may not call `native.package()`
+*   may not call `glob()`
+*   may not call `native.environment_group()`
+*   must create targets whose names adhere to the [naming schema](#naming)
+*   can't refer to input files that weren't declared or passed in as an argument
+*   can't refer to private targets of their callers (see
+    [visibility and macros](#visibility) for more details).
+
+### Visibility and macros {#visibility}
+
+The [visibility](/versions/9.1.0/concepts/visibility) system helps protect the implementation
+details of both (symbolic) macros and their callers.
+
+By default, targets created in a symbolic macro are visible within the macro
+itself, but not necessarily to the macro's caller. The macro can "export" a
+target as a public API by forwarding the value of its own `visibility`
+attribute, as in `some_rule(..., visibility = visibility)`.
+
+The key ideas of macro visibility are:
+
+1. Visibility is checked based on what macro declared the target, not what
+   package called the macro.
+
+   * In other words, being in the same package does not by itself make one
+     target visible to another. This protects the macro's internal targets
+     from becoming dependencies of other macros or top-level targets in the
+     package.
+
+1. All `visibility` attributes, on both rules and macros, automatically
+   include the place where the rule or macro was called.
+
+   * Thus, a target is unconditionally visible to other targets declared in the
+     same macro (or the `BUILD` file, if not in a macro).
+
+In practice, this means that when a macro declares a target without setting its
+`visibility`, the target defaults to being internal to the macro. (The package's
+[default visibility](/versions/9.1.0/reference/be/functions#package.default_visibility) does
+not apply within a macro.) Exporting the target means that the target is visible
+to whatever the macro's caller specified in the macro's `visibility` attribute,
+plus the package of the macro's caller itself, as well as the macro's own code.
+Another way of thinking of it is that the visibility of a macro determines who
+(aside from the macro itself) can see the macro's exported targets.
+
+```starlark
+# tool/BUILD
+...
+some_rule(
+    name = "some_tool",
+    visibility = ["//macro:__pkg__"],
+)
+```
+
+```starlark
+# macro/macro.bzl
+
+def _impl(name, visibility):
+    cc_library(
+        name = name + "_helper",
+        ...
+        # No visibility passed in. Same as passing `visibility = None` or
+        # `visibility = ["//visibility:private"]`. Visible to the //macro
+        # package only.
+    )
+    cc_binary(
+        name = name + "_exported",
+        deps = [
+            # Allowed because we're also in //macro. (Targets in any other
+            # instance of this macro, or any other macro in //macro, can see it
+            # too.)
+            name + "_helper",
+            # Allowed by some_tool's visibility, regardless of what BUILD file
+            # we're called from.
+            "//tool:some_tool",
+        ],
+        ...
+        visibility = visibility,
+    )
+
+my_macro = macro(implementation = _impl, ...)
+```
+
+```starlark
+# pkg/BUILD
+load("//macro:macro.bzl", "my_macro")
+...
+
+my_macro(
+    name = "foo",
+    ...
+)
+
+some_rule(
+    ...
+    deps = [
+        # Allowed, its visibility is ["//pkg:__pkg__", "//macro:__pkg__"].
+        ":foo_exported",
+        # Disallowed, its visibility is ["//macro:__pkg__"] and
+        # we are not in //macro.
+        ":foo_helper",
+    ]
+)
+```
+
+If `my_macro` were called with `visibility = ["//other_pkg:__pkg__"]`, or if
+the `//pkg` package had set its `default_visibility` to that value, then
+`//pkg:foo_exported` could also be used within `//other_pkg/BUILD` or within a
+macro defined in `//other_pkg:defs.bzl`, but `//pkg:foo_helper` would remain
+protected.
+
+A macro can declare that a target is visible to a friend package by passing
+`visibility = ["//some_friend:__pkg__"]` (for an internal target) or
+`visibility = visibility + ["//some_friend:__pkg__"]` (for an exported one).
+Note that it is an antipattern for a macro to declare a target with public
+visibility (`visibility = ["//visibility:public"]`). This is because it makes
+the target unconditionally visible to every package, even if the caller
+specified a more restricted visibility.
+
+All visibility checking is done with respect to the innermost currently running
+symbolic macro. However, there is a visibility delegation mechanism: If a macro
+passes a label as an attribute value to an inner macro, any usages of the label
+in the inner macro are checked with respect to the outer macro. See the
+[visibility page](/versions/9.1.0/concepts/visibility#symbolic-macros) for more details.
+
+Remember that legacy macros are entirely transparent to the visibility system,
+and behave as though their location is whatever BUILD file or symbolic macro
+they were called from.
+
+#### Finalizers and visibility {#finalizers-and-visibility}
+
+Targets declared in a rule finalizer, in addition to seeing targets following
+the usual symbolic macro visibility rules, can *also* see all targets which are
+visible to the finalizer target's package.
+
+This means that if you migrate a `native.existing_rules()`-based legacy macro to
+a finalizer, the targets declared by the finalizer will still be able to see
+their old dependencies.
+
+However, note that it's possible to declare a target in a symbolic macro such
+that a finalizer's targets cannot see it under the visibility system – even
+though the finalizer can *introspect* its attributes using
+`native.existing_rules()`.
+
+### Selects {#selects}
+
+If an attribute is `configurable` (the default) and its value is not `None`,
+then the macro implementation function will see the attribute value as wrapped
+in a trivial `select`. This makes it easier for the macro author to catch bugs
+where they did not anticipate that the attribute value could be a `select`.
+
+For example, consider the following macro:
+
+```starlark
+my_macro = macro(
+    attrs = {"deps": attr.label_list()},  # configurable unless specified otherwise
+    implementation = _my_macro_impl,
+)
+```
+
+If `my_macro` is invoked with `deps = ["//a"]`, that will cause `_my_macro_impl`
+to be invoked with its `deps` parameter set to `select({"//conditions:default":
+["//a"]})`. If this causes the implementation function to fail (say, because the
+code tried to index into the value as in `deps[0]`, which is not allowed for
+`select`s), the macro author can then make a choice: either they can rewrite
+their macro to only use operations compatible with `select`, or they can mark
+the attribute as nonconfigurable (`attr.label_list(configurable = False)`). The
+latter ensures that users are not permitted to pass a `select` value in.
+
+Rule targets reverse this transformation, and store trivial `select`s as their
+unconditional values; in the above example, if `_my_macro_impl` declares a rule
+target `my_rule(..., deps = deps)`, that rule target's `deps` will be stored as
+`["//a"]`. This ensures that `select`-wrapping does not cause trivial `select`
+values to be stored in all targets instantiated by macros.
+
+If the value of a configurable attribute is `None`, it does not get wrapped in a
+`select`. This ensures that tests like `my_attr == None` still work, and that
+when the attribute is forwarded to a rule with a computed default, the rule
+behaves properly (that is, as if the attribute were not passed in at all). It is
+not always possible for an attribute to take on a `None` value, but it can
+happen for the `attr.label()` type, and for any inherited non-mandatory
+attribute.
+
+## Finalizers {#finalizers}
+
+A rule finalizer is a special symbolic macro which – regardless of its lexical
+position in a BUILD file – is evaluated in the final stage of loading a package,
+after all non-finalizer targets have been defined. Unlike ordinary symbolic
+macros, a finalizer can call `native.existing_rules()`, where it behaves
+slightly differently than in legacy macros: it only returns the set of
+non-finalizer rule targets. The finalizer may assert on the state of that set or
+define new targets.
+
+To declare a finalizer, call `macro()` with `finalizer = True`:
+
+```starlark
+def _my_finalizer_impl(name, visibility, tags_filter):
+    for r in native.existing_rules().values():
+        for tag in r.get("tags", []):
+            if tag in tags_filter:
+                my_test(
+                    name = name + "_" + r["name"] + "_finalizer_test",
+                    deps = [r["name"]],
+                    data = r["srcs"],
+                    ...
+                )
+                continue
+
+my_finalizer = macro(
+    attrs = {"tags_filter": attr.string_list(configurable = False)},
+    implementation = _impl,
+    finalizer = True,
+)
+```
+
+## Laziness {#laziness}
+
+IMPORTANT: We are in the process of implementing lazy macro expansion and
+evaluation. This feature is not available yet.
+
+Currently, all macros are evaluated as soon as the BUILD file is loaded, which
+can negatively impact performance for targets in packages that also have costly
+unrelated macros. In the future, non-finalizer symbolic macros will only be
+evaluated if they're required for the build. The prefix naming schema helps
+Bazel determine which macro to expand given a requested target.
+
+## Migration troubleshooting {#troubleshooting}
+
+Here are some common migration headaches and how to fix them.
+
+*   Legacy macro calls `glob()`
+
+Move the `glob()` call to your BUILD file (or to a legacy macro called from the
+BUILD file), and pass the `glob()` value to the symbolic macro using a
+label-list attribute:
+
+```starlark
+# BUILD file
+my_macro(
+    ...,
+    deps = glob(...),
+)
+```
+
+*   Legacy macro has a parameter that isn't a valid starlark `attr` type.
+
+Pull as much logic as possible into a nested symbolic macro, but keep the
+top level macro a legacy macro.
+
+*  Legacy macro calls a rule that creates a target that breaks the naming schema
+
+That's okay, just don't depend on the "offending" target. The naming check will
+be quietly ignored.
+
diff --git a/versions/9.1.0/extending/platforms.mdx b/versions/9.1.0/extending/platforms.mdx
new file mode 100644
index 00000000..0b07c52e
--- /dev/null
+++ b/versions/9.1.0/extending/platforms.mdx
@@ -0,0 +1,279 @@
+---
+title: "Platforms"
+---
+
+## Intro
+
+Bazel can build and test code on a variety of hardware, operating systems, and
+system configurations. This can involve different versions of build tools like
+linkers and compilers. To help manage this complexity, Bazel has the concepts
+of _constraints_ and _platforms_.
+
+A _constraint_ is a distinguishing property of a build or production machine.
+Common constraints are CPU architecture, presence or absence of a GPU, or
+version of a locally installed compiler. But constraints can be _anything_ that
+meaningfully distinguishes machines when orchestrating build work.
+
+A _platform_ is a collection of constraints that specifies a complete machine.
+Bazel uses this concept to let developers choose which machines they want to
+build for, which machines should run compile and test actions, and which
+[toolchains](/versions/9.1.0/extending/toolchains) build actions should compile with.
+
+Developers can also use constraints to [select](/versions/9.1.0/docs/configurable-attributes)
+custom properties or dependencies on their build rules. For example: "_use
+`src_arm.cc` when the build targets an Arm machine_".
+
+## Platform types
+
+Bazel recognizes three roles a platform may play:
+
+- **Host** - The platform on which Bazel itself runs.
+- **Execution** - A platform which runs compile actions to produce build outputs.
+- **Target** - A platform the code being built should run on.
+
+Note: Builds only have one host platform, but often have multiple execution and
+target platforms. For example, both remote Linux CI machines and developer Macs
+may run build actions. And mobile apps have code for multiple phone types and
+hardware extensions.
+
+Builds generally have three kinds of relationships to platforms:
+
+- **Single-platform builds** - Host, execution, and target platforms are the
+  same. For example, building on a developer machine without remote execution,
+  then running the built binary on the same machine.
+
+- **Cross-compilation builds** - Host and execution platforms are the same,
+  but the target platform is different. For example, building an iOS app on a
+  Macbook Pro without remote execution.
+
+- **Multi-platform builds** - Host, execution, and target platforms are all
+  different. For example, building an iOS app on a Macbook Pro and using remote
+  Linux machines to compile C++ actions that don't need Xcode.
+
+## Specifying platforms
+
+The most common way for developers to use platforms is to specify desired
+target machines with the `--platforms` flag:
+
+```shell
+$ bazel build //:my_linux_app --platforms=//myplatforms:linux_x86
+```
+
+Organizations generally maintain their own platform definitions because build
+machine setups vary between organizations.
+
+When `--platforms` isn't set, it defaults to `@platforms//host`. This is
+specially defined to auto-detect the host machine's OS and CPU properties so
+builds target the same machine Bazel runs on. Build rules can
+[select](/versions/9.1.0/docs/configurable-attributes) on these properties with the
+[@platforms/os](https://github.com/bazelbuild/platforms/blob/main/os/BUILD) and
+[@platforms/cpu](https://github.com/bazelbuild/platforms/blob/main/cpu/BUILD)
+constraints.
+
+## Generally useful constraints and platforms {:#useful-constraints-platforms}
+
+To keep the ecosystem consistent, Bazel team maintains a repository with
+constraint definitions for the most popular CPU architectures and operating
+systems. These are all defined in
+[https://github.com/bazelbuild/platforms](https://github.com/bazelbuild/platforms){: .external}.
+
+Bazel ships with the following special platform definition:
+`@platforms//host` (aliased as `@bazel_tools//tools:host_platform`). This
+auto-detects the OS and CPU properties of the machine Bazel runs on.
+
+## Defining constraints {:#constraints}
+
+Constraints are modeled with the [`constraint_setting`][constraint_setting] and
+[`constraint_value`][constraint_value] build rules.
+
+[constraint_setting]: /reference/be/platforms-and-toolchains#constraint_setting
+[constraint_value]: /reference/be/platforms-and-toolchains#constraint_value
+
+`constraint_setting` declares a type of property. For example:
+
+```python
+constraint_setting(name = "cpu")
+```
+
+`constraint_value` declares a possible value for that property:
+
+```python
+constraint_value(
+    name = "x86",
+    constraint_setting = ":cpu"
+)
+```
+
+These can be referenced as labels when defining platforms or customizing build rules
+on them. If the above examples are defined in `cpus/BUILD`, you can reference
+the `x86` constraint as `//cpus:x86`.
+
+If visibility allows, you can extend an existing `constraint_setting` by
+defining your own value for it.
+
+## Defining platforms {:#platforms}
+
+The [`platform`](/versions/9.1.0/reference/be/platforms-and-toolchains#platform) build rule
+defines a platform as a collection of `constraint_value`s:
+
+```python
+platform(
+    name = "linux_x86",
+    constraint_values = [
+        "//oses:linux",
+        "//cpus:x86",
+    ],
+)
+```
+
+This models a machine that must have both the `//oses:linux` and `//cpus:x86`
+constraints.
+
+Platforms may only have one `constraint_value` for a given `constraint_setting`.
+This means, for example, a platform can't have two CPUs unless you create another
+`constraint_setting` type to model the second value.
+
+## Skipping incompatible targets {:#skipping-incompatible-targets}
+
+When building for a specific target platform it is often desirable to skip
+targets that will never work on that platform. For example, your Windows device
+driver is likely going to generate lots of compiler errors when building on a
+Linux machine with `//...`. Use the
+[`target_compatible_with`](/versions/9.1.0/reference/be/common-definitions#common.target_compatible_with)
+attribute to tell Bazel what target platform constraints your code has.
+
+The simplest use of this attribute restricts a target to a single platform.
+The target won't be built for any platform that doesn't satisfy all of the
+constraints. The following example restricts `win_driver_lib.cc` to 64-bit
+Windows.
+
+```python
+cc_library(
+    name = "win_driver_lib",
+    srcs = ["win_driver_lib.cc"],
+    target_compatible_with = [
+        "@platforms//cpu:x86_64",
+        "@platforms//os:windows",
+    ],
+)
+```
+
+`:win_driver_lib` is _only_ compatible for building with 64-bit Windows and
+incompatible with all else. Incompatibility is transitive. Any targets
+that transitively depend on an incompatible target are themselves considered
+incompatible.
+
+### When are targets skipped? {:#when-targets-skipped}
+
+Targets are skipped when they are considered incompatible and included in the
+build as part of a target pattern expansion. For example, the following two
+invocations skip any incompatible targets found in a target pattern expansion.
+
+```console
+$ bazel build --platforms=//:myplatform //...
+```
+
+```console
+$ bazel build --platforms=//:myplatform //:all
+```
+
+Incompatible tests in a [`test_suite`](/versions/9.1.0/reference/be/general#test_suite) are
+similarly skipped if the `test_suite` is specified on the command line with
+[`--expand_test_suites`](/versions/9.1.0/reference/command-line-reference#flag--expand_test_suites).
+In other words, `test_suite` targets on the command line behave like `:all` and
+`...`. Using `--noexpand_test_suites` prevents expansion and causes
+`test_suite` targets with incompatible tests to also be incompatible.
+
+Explicitly specifying an incompatible target on the command line results in an
+error message and a failed build.
+
+```console
+$ bazel build --platforms=//:myplatform //:target_incompatible_with_myplatform
+...
+ERROR: Target //:target_incompatible_with_myplatform is incompatible and cannot be built, but was explicitly requested.
+...
+FAILED: Build did NOT complete successfully
+```
+
+Incompatible explicit targets are silently skipped if
+`--skip_incompatible_explicit_targets` is enabled.
+
+### More expressive constraints {:#expressive-constraints}
+
+For more flexibility in expressing constraints, use the
+`@platforms//:incompatible`
+[`constraint_value`](/versions/9.1.0/reference/be/platforms-and-toolchains#constraint_value)
+that no platform satisfies.
+
+Use [`select()`](/versions/9.1.0/reference/be/functions#select) in combination with
+`@platforms//:incompatible` to express more complicated restrictions. For
+example, use it to implement basic OR logic. The following marks a library
+compatible with macOS and Linux, but no other platforms.
+
+Note: An empty constraints list is equivalent to "compatible with everything".
+
+```python
+cc_library(
+    name = "unixish_lib",
+    srcs = ["unixish_lib.cc"],
+    target_compatible_with = select({
+        "@platforms//os:osx": [],
+        "@platforms//os:linux": [],
+        "//conditions:default": ["@platforms//:incompatible"],
+    }),
+)
+```
+
+The above can be interpreted as follows:
+
+1. When targeting macOS, the target has no constraints.
+2. When targeting Linux, the target has no constraints.
+3. Otherwise, the target has the `@platforms//:incompatible` constraint. Because
+   `@platforms//:incompatible` is not part of any platform, the target is
+   deemed incompatible.
+
+To make your constraints more readable, use
+[skylib](https://github.com/bazelbuild/bazel-skylib){: .external}'s
+[`selects.with_or()`](https://github.com/bazelbuild/bazel-skylib/blob/main/docs/selects_doc.md#selectswith_or){: .external}.
+
+You can express inverse compatibility in a similar way. The following example
+describes a library that is compatible with everything _except_ for ARM.
+
+```python
+cc_library(
+    name = "non_arm_lib",
+    srcs = ["non_arm_lib.cc"],
+    target_compatible_with = select({
+        "@platforms//cpu:arm": ["@platforms//:incompatible"],
+        "//conditions:default": [],
+    }),
+)
+```
+
+### Detecting incompatible targets using `bazel cquery` {:#cquery-incompatible-target-detection}
+
+You can use the
+[`IncompatiblePlatformProvider`](/versions/9.1.0/rules/lib/providers/IncompatiblePlatformProvider)
+in `bazel cquery`'s [Starlark output
+format](/versions/9.1.0/query/cquery#output-format-definition) to distinguish
+incompatible targets from compatible ones.
+
+This can be used to filter out incompatible targets. The example below will
+only print the labels for targets that are compatible. Incompatible targets are
+not printed.
+
+```console
+$ cat example.cquery
+
+def format(target):
+  if "IncompatiblePlatformProvider" not in providers(target):
+    return target.label
+  return ""
+
+$ bazel cquery //... --output=starlark --starlark:file=example.cquery
+```
+
+### Known Issues
+
+Incompatible targets [ignore visibility
+restrictions](https://github.com/bazelbuild/bazel/issues/16044).
diff --git a/versions/9.1.0/extending/rules.mdx b/versions/9.1.0/extending/rules.mdx
new file mode 100644
index 00000000..262482ff
--- /dev/null
+++ b/versions/9.1.0/extending/rules.mdx
@@ -0,0 +1,1296 @@
+---
+title: 'Rules'
+---
+
+A **rule** defines a series of [**actions**](#actions) that Bazel performs on
+inputs to produce a set of outputs, which are referenced in
+[**providers**](#providers) returned by the rule's
+[**implementation function**](#implementation_function). For example, a C++
+binary rule might:
+
+1.  Take a set of `.cpp` source files (inputs).
+2.  Run `g++` on the source files (action).
+3.  Return the `DefaultInfo` provider with the executable output and other files
+    to make available at runtime.
+4.  Return the `CcInfo` provider with C++-specific information gathered from the
+    target and its dependencies.
+
+From Bazel's perspective, `g++` and the standard C++ libraries are also inputs
+to this rule. As a rule writer, you must consider not only the user-provided
+inputs to a rule, but also all of the tools and libraries required to execute
+the actions.
+
+Before creating or modifying any rule, ensure you are familiar with Bazel's
+[build phases](/versions/9.1.0/extending/concepts). It is important to understand the three
+phases of a build (loading, analysis, and execution). It is also useful to
+learn about [macros](/versions/9.1.0/extending/macros) to understand the difference between rules and
+macros. To get started, first review the [Rules Tutorial](/versions/9.1.0/rules/rules-tutorial).
+Then, use this page as a reference.
+
+A few rules are built into Bazel itself. These *native rules*, such as
+`genrule` and `filegroup`, provide some core support.
+By defining your own rules, you can add support for languages and tools
+that Bazel doesn't support natively.
+
+Bazel provides an extensibility model for writing rules using the
+[Starlark](/versions/9.1.0/rules/language) language. These rules are written in `.bzl` files, which
+can be loaded directly from `BUILD` files.
+
+When defining your own rule, you get to decide what attributes it supports and
+how it generates its outputs.
+
+The rule's `implementation` function defines its exact behavior during the
+[analysis phase](/versions/9.1.0/extending/concepts#evaluation-model). This function doesn't run any
+external commands. Rather, it registers [actions](#actions) that will be used
+later during the execution phase to build the rule's outputs, if they are
+needed.
+
+## Rule creation
+
+In a `.bzl` file, use the [rule](/versions/9.1.0/rules/lib/globals/bzl#rule) function to define a new
+rule, and store the result in a global variable. The call to `rule` specifies
+[attributes](#attributes) and an
+[implementation function](#implementation_function):
+
+```python
+example_library = rule(
+    implementation = _example_library_impl,
+    attrs = {
+        "deps": attr.label_list(),
+        ...
+    },
+)
+```
+
+This defines a [rule kind](/versions/9.1.0/query/language#kind) named `example_library`.
+
+The call to `rule` also must specify if the rule creates an
+[executable](#executable-rules) output (with `executable = True`), or specifically
+a test executable (with `test = True`). If the latter, the rule is a *test rule*,
+and the name of the rule must end in `_test`.
+
+## Target instantiation
+
+Rules can be [loaded](/versions/9.1.0/concepts/build-files#load) and called in `BUILD` files:
+
+```python
+load('//some/pkg:rules.bzl', 'example_library')
+
+example_library(
+    name = "example_target",
+    deps = [":another_target"],
+    ...
+)
+```
+
+Each call to a build rule returns no value, but has the side effect of defining
+a target. This is called *instantiating* the rule. This specifies a name for the
+new target and values for the target's [attributes](#attributes).
+
+Rules can also be called from Starlark functions and loaded in `.bzl` files.
+Starlark functions that call rules are called [Starlark macros](/versions/9.1.0/extending/macros).
+Starlark macros must ultimately be called from `BUILD` files, and can only be
+called during the [loading phase](/versions/9.1.0/extending/concepts#evaluation-model), when `BUILD`
+files are evaluated to instantiate targets.
+
+## Attributes
+
+An *attribute* is a rule argument. Attributes can provide specific values to a
+target's [implementation](#implementation_function), or they can refer to other
+targets, creating a graph of dependencies.
+
+Rule-specific attributes, such as `srcs` or `deps`, are defined by passing a map
+from attribute names to schemas (created using the [`attr`](/versions/9.1.0/rules/lib/toplevel/attr)
+module) to the `attrs` parameter of `rule`.
+[Common attributes](/versions/9.1.0/reference/be/common-definitions#common-attributes), such as
+`name` and `visibility`, are implicitly added to all rules. Additional
+attributes are implicitly added to
+[executable and test rules](#executable-rules) specifically. Attributes which
+are implicitly added to a rule can't be included in the dictionary passed to
+`attrs`.
+
+### Dependency attributes
+
+Rules that process source code usually define the following attributes to handle
+various [types of dependencies](/versions/9.1.0/concepts/dependencies#types_of_dependencies):
+
+*   `srcs` specifies source files processed by a target's actions. Often, the
+    attribute schema specifies which file extensions are expected for the sort
+    of source file the rule processes. Rules for languages with header files
+    generally specify a separate `hdrs` attribute for headers processed by a
+    target and its consumers.
+*   `deps` specifies code dependencies for a target. The attribute schema should
+    specify which [providers](#providers) those dependencies must provide. (For
+    example, `cc_library` provides `CcInfo`.)
+*   `data` specifies files to be made available at runtime to any executable
+    which depends on a target. That should allow arbitrary files to be
+    specified.
+
+```python
+example_library = rule(
+    implementation = _example_library_impl,
+    attrs = {
+        "srcs": attr.label_list(allow_files = [".example"]),
+        "hdrs": attr.label_list(allow_files = [".header"]),
+        "deps": attr.label_list(providers = [ExampleInfo]),
+        "data": attr.label_list(allow_files = True),
+        ...
+    },
+)
+```
+
+These are examples of *dependency attributes*. Any attribute that specifies
+an input label (those defined with
+[`attr.label_list`](/versions/9.1.0/rules/lib/toplevel/attr#label_list),
+[`attr.label`](/versions/9.1.0/rules/lib/toplevel/attr#label), or
+[`attr.label_keyed_string_dict`](/versions/9.1.0/rules/lib/toplevel/attr#label_keyed_string_dict))
+specifies dependencies of a certain type
+between a target and the targets whose labels (or the corresponding
+[`Label`](/versions/9.1.0/rules/lib/builtins/Label) objects) are listed in that attribute when the target
+is defined. The repository, and possibly the path, for these labels is resolved
+relative to the defined target.
+
+```python
+example_library(
+    name = "my_target",
+    deps = [":other_target"],
+)
+
+example_library(
+    name = "other_target",
+    ...
+)
+```
+
+In this example, `other_target` is a dependency of `my_target`, and therefore
+`other_target` is analyzed first. It is an error if there is a cycle in the
+dependency graph of targets.
+
+
+
+### Private attributes and implicit dependencies {#private_attributes_and_implicit_dependencies}
+
+A dependency attribute with a default value creates an *implicit dependency*. It
+is implicit because it's a part of the target graph that the user doesn't
+specify it in a `BUILD` file. Implicit dependencies are useful for hard-coding a
+relationship between a rule and a *tool* (a build-time dependency, such as a
+compiler), since most of the time a user is not interested in specifying what
+tool the rule uses. Inside the rule's implementation function, this is treated
+the same as other dependencies.
+
+If you want to provide an implicit dependency without allowing the user to
+override that value, you can make the attribute *private* by giving it a name
+that begins with an underscore (`_`). Private attributes must have default
+values. It generally only makes sense to use private attributes for implicit
+dependencies.
+
+```python
+example_library = rule(
+    implementation = _example_library_impl,
+    attrs = {
+        ...
+        "_compiler": attr.label(
+            default = Label("//tools:example_compiler"),
+            allow_single_file = True,
+            executable = True,
+            cfg = "exec",
+        ),
+    },
+)
+```
+
+In this example, every target of type `example_library` has an implicit
+dependency on the compiler `//tools:example_compiler`. This allows
+`example_library`'s implementation function to generate actions that invoke the
+compiler, even though the user did not pass its label as an input. Since
+`_compiler` is a private attribute, it follows that `ctx.attr._compiler`
+will always point to `//tools:example_compiler` in all targets of this rule
+type. Alternatively, you can name the attribute `compiler` without the
+underscore and keep the default value. This allows users to substitute a
+different compiler if necessary, but it requires no awareness of the compiler's
+label.
+
+Implicit dependencies are generally used for tools that reside in the same
+repository as the rule implementation. If the tool comes from the
+[execution platform](/versions/9.1.0/extending/platforms) or a different repository instead, the
+rule should obtain that tool from a [toolchain](/versions/9.1.0/extending/toolchains).
+
+### Output attributes
+
+*Output attributes*, such as [`attr.output`](/versions/9.1.0/rules/lib/toplevel/attr#output) and
+[`attr.output_list`](/versions/9.1.0/rules/lib/toplevel/attr#output_list), declare an output file that the
+target generates. These differ from dependency attributes in two ways:
+
+*   They define output file targets instead of referring to targets defined
+    elsewhere.
+*   The output file targets depend on the instantiated rule target, instead of
+    the other way around.
+
+Typically, output attributes are only used when a rule needs to create outputs
+with user-defined names which can't be based on the target name. If a rule has
+one output attribute, it is typically named `out` or `outs`.
+
+Output attributes are the preferred way of creating *predeclared outputs*, which
+can be specifically depended upon or
+[requested at the command line](#requesting_output_files).
+
+## Implementation function
+
+Every rule requires an `implementation` function. These functions are executed
+strictly in the [analysis phase](/versions/9.1.0/extending/concepts#evaluation-model) and transform the
+graph of targets generated in the loading phase into a graph of
+[actions](#actions) to be performed during the execution phase. As such,
+implementation functions can't actually read or write files.
+
+Rule implementation functions are usually private (named with a leading
+underscore). Conventionally, they are named the same as their rule, but suffixed
+with `_impl`.
+
+Implementation functions take exactly one parameter: a
+[rule context](/versions/9.1.0/rules/lib/builtins/ctx), conventionally named `ctx`. They return a list of
+[providers](#providers).
+
+### Targets
+
+Dependencies are represented at analysis time as [`Target`](/versions/9.1.0/rules/lib/builtins/Target)
+objects. These objects contain the [providers](#providers) generated when the
+target's implementation function was executed.
+
+[`ctx.attr`](/versions/9.1.0/rules/lib/builtins/ctx#attr) has fields corresponding to the names of each
+dependency attribute, containing `Target` objects representing each direct
+dependency using that attribute. For `label_list` attributes, this is a list of
+`Targets`. For `label` attributes, this is a single `Target` or `None`.
+
+A list of provider objects are returned by a target's implementation function:
+
+```python
+return [ExampleInfo(headers = depset(...))]
+```
+
+Those can be accessed using index notation (`[]`), with the type of provider as
+a key. These can be [custom providers](#custom_providers) defined in Starlark or
+[providers for native rules](/versions/9.1.0/rules/lib/providers) available as Starlark
+global variables.
+
+For example, if a rule takes header files using a `hdrs` attribute and provides
+them to the compilation actions of the target and its consumers, it could
+collect them like so:
+
+```python
+def _example_library_impl(ctx):
+    ...
+    transitive_headers = [hdr[ExampleInfo].headers for hdr in ctx.attr.hdrs]
+```
+
+There's a legacy struct style, which is strongly discouraged and rules should be
+[migrated away from it](#migrating_from_legacy_providers).
+
+### Files
+
+Files are represented by [`File`](/versions/9.1.0/rules/lib/builtins/File) objects. Since Bazel doesn't
+perform file I/O during the analysis phase, these objects can't be used to
+directly read or write file content. Rather, they are passed to action-emitting
+functions (see [`ctx.actions`](/versions/9.1.0/rules/lib/builtins/actions)) to construct pieces of the
+action graph.
+
+A `File` can either be a source file or a generated file. Each generated file
+must be an output of exactly one action. Source files can't be the output of
+any action.
+
+For each dependency attribute, the corresponding field of
+[`ctx.files`](/versions/9.1.0/rules/lib/builtins/ctx#files) contains a list of the default outputs of all
+dependencies using that attribute:
+
+```python
+def _example_library_impl(ctx):
+    ...
+    headers = depset(ctx.files.hdrs, transitive = transitive_headers)
+    srcs = ctx.files.srcs
+    ...
+```
+
+[`ctx.file`](/versions/9.1.0/rules/lib/builtins/ctx#file) contains a single `File` or `None` for
+dependency attributes whose specs set `allow_single_file = True`.
+[`ctx.executable`](/versions/9.1.0/rules/lib/builtins/ctx#executable) behaves the same as `ctx.file`, but only
+contains fields for dependency attributes whose specs set `executable = True`.
+
+### Declaring outputs
+
+During the analysis phase, a rule's implementation function can create outputs.
+Since all labels have to be known during the loading phase, these additional
+outputs have no labels. `File` objects for outputs can be created using
+[`ctx.actions.declare_file`](/versions/9.1.0/rules/lib/builtins/actions#declare_file) and
+[`ctx.actions.declare_directory`](/versions/9.1.0/rules/lib/builtins/actions#declare_directory).
+Often, the names of outputs are based on the target's name,
+[`ctx.label.name`](/versions/9.1.0/rules/lib/builtins/ctx#label):
+
+```python
+def _example_library_impl(ctx):
+  ...
+  output_file = ctx.actions.declare_file(ctx.label.name + ".output")
+  ...
+```
+
+For *predeclared outputs*, like those created for
+[output attributes](#output_attributes), `File` objects instead can be retrieved
+from the corresponding fields of [`ctx.outputs`](/versions/9.1.0/rules/lib/builtins/ctx#outputs).
+
+### Actions
+
+An action describes how to generate a set of outputs from a set of inputs, for
+example "run gcc on hello.c and get hello.o". When an action is created, Bazel
+doesn't run the command immediately. It registers it in a graph of dependencies,
+because an action can depend on the output of another action. For example, in C,
+the linker must be called after the compiler.
+
+General-purpose functions that create actions are defined in
+[`ctx.actions`](/versions/9.1.0/rules/lib/builtins/actions):
+
+*   [`ctx.actions.run`](/versions/9.1.0/rules/lib/builtins/actions#run), to run an executable.
+*   [`ctx.actions.run_shell`](/versions/9.1.0/rules/lib/builtins/actions#run_shell), to run a shell
+    command.
+*   [`ctx.actions.write`](/versions/9.1.0/rules/lib/builtins/actions#write), to write a string to a file.
+*   [`ctx.actions.expand_template`](/versions/9.1.0/rules/lib/builtins/actions#expand_template), to
+    generate a file from a template.
+
+[`ctx.actions.args`](/versions/9.1.0/rules/lib/builtins/actions#args) can be used to efficiently
+accumulate the arguments for actions. It avoids flattening depsets until
+execution time:
+
+```python
+def _example_library_impl(ctx):
+    ...
+
+    transitive_headers = [dep[ExampleInfo].headers for dep in ctx.attr.deps]
+    headers = depset(ctx.files.hdrs, transitive = transitive_headers)
+    srcs = ctx.files.srcs
+    inputs = depset(srcs, transitive = [headers])
+    output_file = ctx.actions.declare_file(ctx.label.name + ".output")
+
+    args = ctx.actions.args()
+    args.add_joined("-h", headers, join_with = ",")
+    args.add_joined("-s", srcs, join_with = ",")
+    args.add("-o", output_file)
+
+    ctx.actions.run(
+        mnemonic = "ExampleCompile",
+        executable = ctx.executable._compiler,
+        arguments = [args],
+        inputs = inputs,
+        outputs = [output_file],
+    )
+    ...
+```
+
+Actions take a list or depset of input files and generate a (non-empty) list of
+output files. The set of input and output files must be known during the
+[analysis phase](/versions/9.1.0/extending/concepts#evaluation-model). It might depend on the value of
+attributes, including providers from dependencies, but it can't depend on the
+result of the execution. For example, if your action runs the unzip command, you
+must specify which files you expect to be inflated (before running unzip).
+Actions which create a variable number of files internally can wrap those in a
+single file (such as a zip, tar, or other archive format).
+
+Actions must list all of their inputs. Listing inputs that are not used is
+permitted, but inefficient.
+
+Actions must create all of their outputs. They may write other files, but
+anything not in outputs won't be available to consumers. All declared outputs
+must be written by some action.
+
+Actions are comparable to pure functions: They should depend only on the
+provided inputs, and avoid accessing computer information, username, clock,
+network, or I/O devices (except for reading inputs and writing outputs). This is
+important because the output will be cached and reused.
+
+Dependencies are resolved by Bazel, which decides which actions to
+execute. It is an error if there is a cycle in the dependency graph. Creating
+an action doesn't guarantee that it will be executed, that depends on whether
+its outputs are needed for the build.
+
+### Providers
+
+Providers are pieces of information that a rule exposes to other rules that
+depend on it. This data can include output files, libraries, parameters to pass
+on a tool's command line, or anything else a target's consumers should know
+about.
+
+Since a rule's implementation function can only read providers from the
+instantiated target's immediate dependencies, rules need to forward any
+information from a target's dependencies that needs to be known by a target's
+consumers, generally by accumulating that into a [`depset`](/versions/9.1.0/rules/lib/builtins/depset).
+
+A target's providers are specified by a list of provider objects returned by
+the implementation function.
+
+Old implementation functions can also be written in a legacy style where the
+implementation function returns a [`struct`](/versions/9.1.0/rules/lib/builtins/struct) instead of list of
+provider objects. This style is strongly discouraged and rules should be
+[migrated away from it](#migrating_from_legacy_providers).
+
+#### Default outputs
+
+A target's *default outputs* are the outputs that are requested by default when
+the target is requested for build at the command line. For example, a
+`java_library` target `//pkg:foo` has `foo.jar` as a default output, so that
+will be built by the command `bazel build //pkg:foo`.
+
+Default outputs are specified by the `files` parameter of
+[`DefaultInfo`](/versions/9.1.0/rules/lib/providers/DefaultInfo):
+
+```python
+def _example_library_impl(ctx):
+    ...
+    return [
+        DefaultInfo(files = depset([output_file]), ...),
+        ...
+    ]
+```
+
+If `DefaultInfo` is not returned by a rule implementation or the `files`
+parameter is not specified, `DefaultInfo.files` defaults to all
+*predeclared outputs* (generally, those created by [output
+attributes](#output_attributes)).
+
+Rules that perform actions should provide default outputs, even if those outputs
+are not expected to be directly used. Actions that are not in the graph of the
+requested outputs are pruned. If an output is only used by a target's consumers,
+those actions won't be performed when the target is built in isolation. This
+makes debugging more difficult because rebuilding just the failing target won't
+reproduce the failure.
+
+#### Runfiles
+
+Runfiles are a set of files used by a target at runtime (as opposed to build
+time). During the [execution phase](/versions/9.1.0/extending/concepts#evaluation-model), Bazel creates
+a directory tree containing symlinks pointing to the runfiles. This stages the
+environment for the binary so it can access the runfiles during runtime.
+
+Runfiles can be added manually during rule creation.
+[`runfiles`](/versions/9.1.0/rules/lib/builtins/runfiles) objects can be created by the `runfiles` method
+on the rule context, [`ctx.runfiles`](/versions/9.1.0/rules/lib/builtins/ctx#runfiles) and passed to the
+`runfiles` parameter on `DefaultInfo`. The executable output of
+[executable rules](#executable-rules) is implicitly added to the runfiles.
+
+Some rules specify attributes, generally named
+[`data`](/versions/9.1.0/reference/be/common-definitions#common.data), whose outputs are added to
+a targets' runfiles. Runfiles should also be merged in from `data`, as well as
+from any attributes which might provide code for eventual execution, generally
+`srcs` (which might contain `filegroup` targets with associated `data`) and
+`deps`.
+
+```python
+def _example_library_impl(ctx):
+    ...
+    runfiles = ctx.runfiles(files = ctx.files.data)
+    transitive_runfiles = []
+    for runfiles_attr in (
+        ctx.attr.srcs,
+        ctx.attr.hdrs,
+        ctx.attr.deps,
+        ctx.attr.data,
+    ):
+        for target in runfiles_attr:
+            transitive_runfiles.append(target[DefaultInfo].default_runfiles)
+    runfiles = runfiles.merge_all(transitive_runfiles)
+    return [
+        DefaultInfo(..., runfiles = runfiles),
+        ...
+    ]
+```
+
+#### Custom providers
+
+Providers can be defined using the [`provider`](/versions/9.1.0/rules/lib/globals/bzl#provider)
+function to convey rule-specific information:
+
+```python
+ExampleInfo = provider(
+    "Info needed to compile/link Example code.",
+    fields = {
+        "headers": "depset of header Files from transitive dependencies.",
+        "files_to_link": "depset of Files from compilation.",
+    },
+)
+```
+
+Rule implementation functions can then construct and return provider instances:
+
+```python
+def _example_library_impl(ctx):
+  ...
+  return [
+      ...
+      ExampleInfo(
+          headers = headers,
+          files_to_link = depset(
+              [output_file],
+              transitive = [
+                  dep[ExampleInfo].files_to_link for dep in ctx.attr.deps
+              ],
+          ),
+      )
+  ]
+```
+
+##### Custom initialization of providers
+
+It's possible to guard the instantiation of a provider with custom
+preprocessing and validation logic. This can be used to ensure that all
+provider instances satisfy certain invariants, or to give users a cleaner API for
+obtaining an instance.
+
+This is done by passing an `init` callback to the
+[`provider`](/versions/9.1.0/rules/lib/globals/bzl#provider) function. If this callback is given, the
+return type of `provider()` changes to be a tuple of two values: the provider
+symbol that is the ordinary return value when `init` is not used, and a "raw
+constructor".
+
+In this case, when the provider symbol is called, instead of directly returning
+a new instance, it will forward the arguments along to the `init` callback. The
+callback's return value must be a dict mapping field names (strings) to values;
+this is used to initialize the fields of the new instance. Note that the
+callback may have any signature, and if the arguments don't match the signature
+an error is reported as if the callback were invoked directly.
+
+The raw constructor, by contrast, will bypass the `init` callback.
+
+The following example uses `init` to preprocess and validate its arguments:
+
+```python
+# //pkg:exampleinfo.bzl
+
+_core_headers = [...]  # private constant representing standard library files
+
+# Keyword-only arguments are preferred.
+def _exampleinfo_init(*, files_to_link, headers = None, allow_empty_files_to_link = False):
+    if not files_to_link and not allow_empty_files_to_link:
+        fail("files_to_link may not be empty")
+    all_headers = depset(_core_headers, transitive = headers)
+    return {"files_to_link": files_to_link, "headers": all_headers}
+
+ExampleInfo, _new_exampleinfo = provider(
+    fields = ["files_to_link", "headers"],
+    init = _exampleinfo_init,
+)
+```
+
+A rule implementation may then instantiate the provider as follows:
+
+```python
+ExampleInfo(
+    files_to_link = my_files_to_link,  # may not be empty
+    headers = my_headers,  # will automatically include the core headers
+)
+```
+
+The raw constructor can be used to define alternative public factory functions
+that don't go through the `init` logic. For example, exampleinfo.bzl
+could define:
+
+```python
+def make_barebones_exampleinfo(headers):
+    """Returns an ExampleInfo with no files_to_link and only the specified headers."""
+    return _new_exampleinfo(files_to_link = depset(), headers = all_headers)
+```
+
+Typically, the raw constructor is bound to a variable whose name begins with an
+underscore (`_new_exampleinfo` above), so that user code can't load it and
+generate arbitrary provider instances.
+
+Another use for `init` is to prevent the user from calling the provider
+symbol altogether, and force them to use a factory function instead:
+
+```python
+def _exampleinfo_init_banned(*args, **kwargs):
+    fail("Do not call ExampleInfo(). Use make_exampleinfo() instead.")
+
+ExampleInfo, _new_exampleinfo = provider(
+    ...
+    init = _exampleinfo_init_banned)
+
+def make_exampleinfo(...):
+    ...
+    return _new_exampleinfo(...)
+```
+
+
+
+## Executable rules and test rules
+
+Executable rules define targets that can be invoked by a `bazel run` command.
+Test rules are a special kind of executable rule whose targets can also be
+invoked by a `bazel test` command. Executable and test rules are created by
+setting the respective [`executable`](/versions/9.1.0/rules/lib/globals/bzl#rule.executable) or
+[`test`](/versions/9.1.0/rules/lib/globals/bzl#rule.test) argument to `True` in the call to `rule`:
+
+```python
+example_binary = rule(
+   implementation = _example_binary_impl,
+   executable = True,
+   ...
+)
+
+example_test = rule(
+   implementation = _example_binary_impl,
+   test = True,
+   ...
+)
+```
+
+Test rules must have names that end in `_test`. (Test *target* names also often
+end in `_test` by convention, but this is not required.) Non-test rules must not
+have this suffix.
+
+Both kinds of rules must produce an executable output file (which may or may not
+be predeclared) that will be invoked by the `run` or `test` commands. To tell
+Bazel which of a rule's outputs to use as this executable, pass it as the
+`executable` argument of a returned [`DefaultInfo`](/versions/9.1.0/rules/lib/providers/DefaultInfo)
+provider. That `executable` is added to the default outputs of the rule (so you
+don't need to pass that to both `executable` and `files`). It's also implicitly
+added to the [runfiles](#runfiles):
+
+```python
+def _example_binary_impl(ctx):
+    executable = ctx.actions.declare_file(ctx.label.name)
+    ...
+    return [
+        DefaultInfo(executable = executable, ...),
+        ...
+    ]
+```
+
+The action that generates this file must set the executable bit on the file. For
+a [`ctx.actions.run`](/versions/9.1.0/rules/lib/builtins/actions#run) or
+[`ctx.actions.run_shell`](/versions/9.1.0/rules/lib/builtins/actions#run_shell) action this should be done
+by the underlying tool that is invoked by the action. For a
+[`ctx.actions.write`](/versions/9.1.0/rules/lib/builtins/actions#write) action, pass `is_executable = True`.
+
+As [legacy behavior](#deprecated_predeclared_outputs), executable rules have a
+special `ctx.outputs.executable` predeclared output. This file serves as the
+default executable if you don't specify one using `DefaultInfo`; it must not be
+used otherwise. This output mechanism is deprecated because it doesn't support
+customizing the executable file's name at analysis time.
+
+See examples of an
+[executable rule](https://github.com/bazelbuild/examples/blob/main/rules/executable/fortune.bzl)
+and a
+[test rule](https://github.com/bazelbuild/examples/blob/main/rules/test_rule/line_length.bzl).
+
+[Executable rules](/versions/9.1.0/reference/be/common-definitions#common-attributes-binaries) and
+[test rules](/versions/9.1.0/reference/be/common-definitions#common-attributes-tests) have additional
+attributes implicitly defined, in addition to those added for
+[all rules](/versions/9.1.0/reference/be/common-definitions#common-attributes). The defaults of
+implicitly-added attributes can't be changed, though this can be worked around
+by wrapping a private rule in a [Starlark macro](/versions/9.1.0/extending/macros) which alters the
+default:
+
+```python
+def example_test(size = "small", **kwargs):
+  _example_test(size = size, **kwargs)
+
+_example_test = rule(
+ ...
+)
+```
+
+### Runfiles location
+
+When an executable target is run with `bazel run` (or `test`), the root of the
+runfiles directory is adjacent to the executable. The paths relate as follows:
+
+```python
+# Given launcher_path and runfile_file:
+runfiles_root = launcher_path.path + ".runfiles"
+workspace_name = ctx.workspace_name
+runfile_path = runfile_file.short_path
+execution_root_relative_path = "%s/%s/%s" % (
+    runfiles_root, workspace_name, runfile_path)
+```
+
+The path to a `File` under the runfiles directory corresponds to
+[`File.short_path`](/versions/9.1.0/rules/lib/builtins/File#short_path).
+
+The binary executed directly by `bazel` is adjacent to the root of the
+`runfiles` directory. However, binaries called *from* the runfiles can't make
+the same assumption. To mitigate this, each binary should provide a way to
+accept its runfiles root as a parameter using an environment, or command line
+argument or flag. This allows binaries to pass the correct canonical runfiles root
+to the binaries it calls. If that's not set, a binary can guess that it was the
+first binary called and look for an adjacent runfiles directory.
+
+## Advanced topics
+
+### Requesting output files
+
+A single target can have several output files. When a `bazel build` command is
+run, some of the outputs of the targets given to the command are considered to
+be *requested*. Bazel only builds these requested files and the files that they
+directly or indirectly depend on. (In terms of the action graph, Bazel only
+executes the actions that are reachable as transitive dependencies of the
+requested files.)
+
+In addition to [default outputs](#default_outputs), any *predeclared output* can
+be explicitly requested on the command line. Rules can specify predeclared
+outputs using [output attributes](#output_attributes). In that case, the user
+explicitly chooses labels for outputs when they instantiate the rule. To obtain
+[`File`](/versions/9.1.0/rules/lib/builtins/File) objects for output attributes, use the corresponding
+attribute of [`ctx.outputs`](/versions/9.1.0/rules/lib/builtins/ctx#outputs). Rules can
+[implicitly define predeclared outputs](#deprecated_predeclared_outputs) based
+on the target name as well, but this feature is deprecated.
+
+In addition to default outputs, there are *output groups*, which are collections
+of output files that may be requested together. These can be requested with
+[`--output_groups`](/versions/9.1.0/reference/command-line-reference#flag--output_groups). For
+example, if a target `//pkg:mytarget` is of a rule type that has a `debug_files`
+output group, these files can be built by running `bazel build //pkg:mytarget
+--output_groups=debug_files`. Since non-predeclared outputs don't have labels,
+they can only be requested by appearing in the default outputs or an output
+group.
+
+Output groups can be specified with the
+[`OutputGroupInfo`](/versions/9.1.0/rules/lib/providers/OutputGroupInfo) provider. Note that unlike many
+built-in providers, `OutputGroupInfo` can take parameters with arbitrary names
+to define output groups with that name:
+
+```python
+def _example_library_impl(ctx):
+    ...
+    debug_file = ctx.actions.declare_file(name + ".pdb")
+    ...
+    return [
+        DefaultInfo(files = depset([output_file]), ...),
+        OutputGroupInfo(
+            debug_files = depset([debug_file]),
+            all_files = depset([output_file, debug_file]),
+        ),
+        ...
+    ]
+```
+
+Also unlike most providers, `OutputGroupInfo` can be returned by both an
+[aspect](/versions/9.1.0/extending/aspects) and the rule target to which that aspect is applied, as
+long as they don't define the same output groups. In that case, the resulting
+providers are merged.
+
+Note that `OutputGroupInfo` generally shouldn't be used to convey specific sorts
+of files from a target to the actions of its consumers. Define
+[rule-specific providers](#custom_providers) for that instead.
+
+### Configurations
+
+Imagine that you want to build a C++ binary for a different architecture. The
+build can be complex and involve multiple steps. Some of the intermediate
+binaries, like compilers and code generators, have to run on
+[the execution platform](/versions/9.1.0/extending/platforms#overview) (which could be your host,
+or a remote executor). Some binaries like the final output must be built for the
+target architecture.
+
+For this reason, Bazel has a concept of "configurations" and transitions. The
+topmost targets (the ones requested on the command line) are built-in the
+"target" configuration, while tools that should run on the execution platform
+are built-in an "exec" configuration. Rules may generate different actions based
+on the configuration, for instance to change the cpu architecture that is passed
+to the compiler. In some cases, the same library may be needed for different
+configurations. If this happens, it will be analyzed and potentially built
+multiple times.
+
+By default, Bazel builds a target's dependencies in the same configuration as
+the target itself, in other words without transitions. When a dependency is a
+tool that's needed to help build the target, the corresponding attribute should
+specify a transition to an exec configuration. This causes the tool and all its
+dependencies to build for the execution platform.
+
+For each dependency attribute, you can use `cfg` to decide if dependencies
+should build in the same configuration or transition to an exec configuration.
+If a dependency attribute has the flag `executable = True`, `cfg` must be set
+explicitly. This is to guard against accidentally building a tool for the wrong
+configuration.
+[See example](https://github.com/bazelbuild/examples/blob/main/rules/actions_run/execute.bzl)
+
+In general, sources, dependent libraries, and executables that will be needed at
+runtime can use the same configuration.
+
+Tools that are executed as part of the build (such as compilers or code generators)
+should be built for an exec configuration. In this case, specify `cfg = "exec"` in
+the attribute.
+
+Otherwise, executables that are used at runtime (such as as part of a test) should
+be built for the target configuration. In this case, specify `cfg = "target"` in
+the attribute.
+
+`cfg = "target"` doesn't actually do anything: it's purely a convenience value to
+help rule designers be explicit about their intentions. When `executable = False`,
+which means `cfg` is optional, only set this when it truly helps readability.
+
+You can also use `cfg = my_transition` to use
+[user-defined transitions](/versions/9.1.0/extending/config#user-defined-transitions), which allow
+rule authors a great deal of flexibility in changing configurations, with the
+drawback of
+[making the build graph larger and less comprehensible](/versions/9.1.0/extending/config#memory-and-performance-considerations).
+
+**Note**: Historically, Bazel didn't have the concept of execution platforms,
+and instead all build actions were considered to run on the host machine. Bazel
+versions before 6.0 created a distinct "host" configuration to represent this.
+If you see references to "host" in code or old documentation, that's what this
+refers to. We recommend using Bazel 6.0 or newer to avoid this extra conceptual
+overhead.
+
+
+
+### Configuration fragments
+
+Rules may access
+[configuration fragments](/versions/9.1.0/rules/lib/fragments) such as
+`cpp` and `java`. However, all required fragments must be declared in
+order to avoid access errors:
+
+```python
+def _impl(ctx):
+    # Using ctx.fragments.cpp leads to an error since it was not declared.
+    x = ctx.fragments.java
+    ...
+
+my_rule = rule(
+    implementation = _impl,
+    fragments = ["java"],      # Required fragments of the target configuration
+    ...
+)
+```
+
+### Runfiles symlinks
+
+Normally, the relative path of a file in the runfiles tree is the same as the
+relative path of that file in the source tree or generated output tree. If these
+need to be different for some reason, you can specify the `root_symlinks` or
+`symlinks` arguments. The `root_symlinks` is a dictionary mapping paths to
+files, where the paths are relative to the root of the runfiles directory. The
+`symlinks` dictionary is the same, but paths are implicitly prefixed with the
+name of the main workspace (*not* the name of the repository containing the
+current target).
+
+```python
+    ...
+    runfiles = ctx.runfiles(
+        root_symlinks = {"some/path/here.foo": ctx.file.some_data_file2}
+        symlinks = {"some/path/here.bar": ctx.file.some_data_file3}
+    )
+    # Creates something like:
+    # sometarget.runfiles/
+    #     some/
+    #         path/
+    #             here.foo -> some_data_file2
+    #     /
+    #         some/
+    #             path/
+    #                 here.bar -> some_data_file3
+```
+
+If `symlinks` or `root_symlinks` is used, be careful not to map two different
+files to the same path in the runfiles tree. This will cause the build to fail
+with an error describing the conflict. To fix, you will need to modify your
+`ctx.runfiles` arguments to remove the collision. This checking will be done for
+any targets using your rule, as well as targets of any kind that depend on those
+targets. This is especially risky if your tool is likely to be used transitively
+by another tool; symlink names must be unique across the runfiles of a tool and
+all of its dependencies.
+
+### Code coverage
+
+When the [`coverage`](/versions/9.1.0/reference/command-line-reference#coverage) command is run,
+the build may need to add coverage instrumentation for certain targets. The
+build also gathers the list of source files that are instrumented. The subset of
+targets that are considered is controlled by the flag
+[`--instrumentation_filter`](/versions/9.1.0/reference/command-line-reference#flag--instrumentation_filter).
+Test targets are excluded, unless
+[`--instrument_test_targets`](/versions/9.1.0/reference/command-line-reference#flag--instrument_test_targets)
+is specified.
+
+If a rule implementation adds coverage instrumentation at build time, it needs
+to account for that in its implementation function.
+[ctx.coverage_instrumented](/versions/9.1.0/rules/lib/builtins/ctx#coverage_instrumented) returns
+`True` in coverage mode if a target's sources should be instrumented:
+
+```python
+# Are this rule's sources instrumented?
+if ctx.coverage_instrumented():
+  # Do something to turn on coverage for this compile action
+```
+
+Logic that always needs to be on in coverage mode (whether a target's sources
+specifically are instrumented or not) can be conditioned on
+[ctx.configuration.coverage_enabled](/versions/9.1.0/rules/lib/builtins/configuration#coverage_enabled).
+
+If the rule directly includes sources from its dependencies before compilation
+(such as header files), it may also need to turn on compile-time instrumentation if
+the dependencies' sources should be instrumented:
+
+```python
+# Are this rule's sources or any of the sources for its direct dependencies
+# in deps instrumented?
+if ctx.coverage_instrumented() or any([ctx.coverage_instrumented(dep) for dep in ctx.attr.deps]):
+    # Do something to turn on coverage for this compile action
+```
+
+Rules also should provide information about which attributes are relevant for
+coverage with the `InstrumentedFilesInfo` provider, constructed using
+[`coverage_common.instrumented_files_info`](/versions/9.1.0/rules/lib/toplevel/coverage_common#instrumented_files_info).
+The `dependency_attributes` parameter of `instrumented_files_info` should list
+all runtime dependency attributes, including code dependencies like `deps` and
+data dependencies like `data`. The `source_attributes` parameter should list the
+rule's source files attributes if coverage instrumentation might be added:
+
+```python
+def _example_library_impl(ctx):
+    ...
+    return [
+        ...
+        coverage_common.instrumented_files_info(
+            ctx,
+            dependency_attributes = ["deps", "data"],
+            # Omitted if coverage is not supported for this rule:
+            source_attributes = ["srcs", "hdrs"],
+        )
+        ...
+    ]
+```
+
+If `InstrumentedFilesInfo` is not returned, a default one is created with each
+non-tool [dependency attribute](#dependency_attributes) that doesn't set
+[`cfg`](#configuration) to `"exec"` in the attribute schema. in
+`dependency_attributes`. (This isn't ideal behavior, since it puts attributes
+like `srcs` in `dependency_attributes` instead of `source_attributes`, but it
+avoids the need for explicit coverage configuration for all rules in the
+dependency chain.)
+
+#### Test rules
+
+Test rules require additional setup to generate coverage reports. The rule
+itself has to add the following implicit attributes:
+
+```python
+my_test = rule(
+    ...,
+    attrs = {
+        ...,
+        # Implicit dependencies used by Bazel to generate coverage reports.
+        "_lcov_merger": attr.label(
+            default = configuration_field(fragment = "coverage", name = "output_generator"),
+            executable = True,
+            cfg = config.exec(exec_group = "test"),
+        ),
+        "_collect_cc_coverage": attr.label(
+            default = "@bazel_tools//tools/test:collect_cc_coverage",
+            executable = True,
+            cfg = config.exec(exec_group = "test"),
+        )
+    },
+    test = True,
+)
+```
+
+By using `configuration_field`, the dependency on the Java LCOV merger tool can
+be avoided as long as coverage is not requested.
+
+When the test is run, it should emit coverage information in the form of one or
+more [LCOV files]
+(https://manpages.debian.org/unstable/lcov/geninfo.1.en.html#TRACEFILE_FORMAT)
+with unique names into the directory specified by the `COVERAGE_DIR` environment
+variable. Bazel will then merge these files into a single LCOV file using the
+`_lcov_merger` tool. If present, it will also collect C/C++ coverage using the
+`_collect_cc_coverage` tool.
+
+### Baseline coverage
+
+Since coverage is only collected for code that ends up in the dependency tree of
+a test, coverage reports can be misleading as they don't necessarily cover all
+the code matched by the `--instrumentation_filter` flag.
+
+For this reason, Bazel allows rules to specify baseline coverage files using the
+`baseline_coverage_files` attribute of `ctx.instrumented_files_info`). These
+files must be generated in LCOV format by a user-defined action and are supposed
+to list all lines, branches, functions and/or blocks in the target's source
+files (according to the `sources_attributes` and `extensions` parameters). For
+source files in targets that are instrumented for coverage, Bazel merges their
+baseline coverage into the combined coverage report generated with
+`--combined_report` and thus ensures that untested files still show up as
+uncovered.
+
+If a rule doesn't provide any baseline coverage files, Bazel generates synthetic
+coverage information that only mentions the source file paths, but doesn't
+contain any information about their contents.
+
+### Validation Actions
+
+Sometimes you need to validate something about the build, and the
+information required to do that validation is available only in artifacts
+(source files or generated files). Because this information is in artifacts,
+rules can't do this validation at analysis time because rules can't read
+files. Instead, actions must do this validation at execution time. When
+validation fails, the action will fail, and hence so will the build.
+
+Examples of validations that might be run are static analysis, linting,
+dependency and consistency checks, and style checks.
+
+Validation actions can also help to improve build performance by moving parts
+of actions that are not required for building artifacts into separate actions.
+For example, if a single action that does compilation and linting can be
+separated into a compilation action and a linting action, then the linting
+action can be run as a validation action and run in parallel with other actions.
+
+These "validation actions" often don't produce anything that is used elsewhere
+in the build, since they only need to assert things about their inputs. This
+presents a problem though: If a validation action doesn't produce anything that
+is used elsewhere in the build, how does a rule get the action to run?
+Historically, the approach was to have the validation action output an empty
+file, and artificially add that output to the inputs of some other important
+action in the build:
+
+
+
+This works, because Bazel will always run the validation action when the compile
+action is run, but this has significant drawbacks:
+
+1. The validation action is in the critical path of the build. Because Bazel
+thinks the empty output is required to run the compile action, it will run the
+validation action first, even though the compile action will ignore the input.
+This reduces parallelism and slows down builds.
+
+2. If other actions in the build might run instead of the
+compile action, then the empty outputs of validation actions need to be added to
+those actions as well (`java_library`'s source jar output, for example). This is
+also a problem if new actions that might run instead of the compile action are
+added later, and the empty validation output is accidentally left off.
+
+The solution to these problems is to use the Validations Output Group.
+
+#### Validations Output Group
+
+The Validations Output Group is an output group designed to hold the otherwise
+unused outputs of validation actions, so that they don't need to be artificially
+added to the inputs of other actions.
+
+This group is special in that its outputs are always requested, regardless of
+the value of the `--output_groups` flag, and regardless of how the target is
+depended upon (for example, on the command line, as a dependency, or through
+implicit outputs of the target). Note that normal caching and incrementality
+still apply: if the inputs to the validation action have not changed and the
+validation action previously succeeded, then the validation action won't be
+run.
+
+
+
+Using this output group still requires that validation actions output some file,
+even an empty one. This might require wrapping some tools that normally don't
+create outputs so that a file is created.
+
+A target's validation actions are not run in three cases:
+
+*    When the target is depended upon as a tool
+*    When the target is depended upon as an implicit dependency (for example, an
+     attribute that starts with "_")
+*    When the target is built in the exec configuration.
+
+It is assumed that these targets have their own
+separate builds and tests that would uncover any validation failures.
+
+#### Using the Validations Output Group
+
+The Validations Output Group is named `_validation` and is used like any other
+output group:
+
+```python
+def _rule_with_validation_impl(ctx):
+
+  ctx.actions.write(ctx.outputs.main, "main output\n")
+  ctx.actions.write(ctx.outputs.implicit, "implicit output\n")
+
+  validation_output = ctx.actions.declare_file(ctx.attr.name + ".validation")
+  ctx.actions.run(
+    outputs = [validation_output],
+    executable = ctx.executable._validation_tool,
+    arguments = [validation_output.path],
+  )
+
+  return [
+    DefaultInfo(files = depset([ctx.outputs.main])),
+    OutputGroupInfo(_validation = depset([validation_output])),
+  ]
+
+rule_with_validation = rule(
+  implementation = _rule_with_validation_impl,
+  outputs = {
+    "main": "%{name}.main",
+    "implicit": "%{name}.implicit",
+  },
+  attrs = {
+    "_validation_tool": attr.label(
+        default = Label("//validation_actions:validation_tool"),
+        executable = True,
+        cfg = "exec"
+    ),
+  }
+)
+```
+
+Notice that the validation output file is not added to the `DefaultInfo` or the
+inputs to any other action. The validation action for a target of this rule kind
+will still run if the target is depended upon by label, or any of the target's
+implicit outputs are directly or indirectly depended upon.
+
+It is usually important that the outputs of validation actions only go into the
+validation output group, and are not added to the inputs of other actions, as
+this could defeat parallelism gains. Note however that Bazel doesn't
+have any special checking to enforce this. Therefore, you should test
+that validation action outputs are not added to the inputs of any actions in the
+tests for Starlark rules. For example:
+
+```python
+load("@bazel_skylib//lib:unittest.bzl", "analysistest")
+
+def _validation_outputs_test_impl(ctx):
+  env = analysistest.begin(ctx)
+
+  actions = analysistest.target_actions(env)
+  target = analysistest.target_under_test(env)
+  validation_outputs = target.output_groups._validation.to_list()
+  for action in actions:
+    for validation_output in validation_outputs:
+      if validation_output in action.inputs.to_list():
+        analysistest.fail(env,
+            "%s is a validation action output, but is an input to action %s" % (
+                validation_output, action))
+
+  return analysistest.end(env)
+
+validation_outputs_test = analysistest.make(_validation_outputs_test_impl)
+```
+
+#### Validation Actions Flag
+
+Running validation actions is controlled by the `--run_validations` command line
+flag, which defaults to true.
+
+## Deprecated features
+
+### Deprecated predeclared outputs
+
+There are two **deprecated** ways of using predeclared outputs:
+
+*   The [`outputs`](/versions/9.1.0/rules/lib/globals/bzl#rule.outputs) parameter of `rule` specifies
+    a mapping between output attribute names and string templates for generating
+    predeclared output labels. Prefer using non-predeclared outputs and
+    explicitly adding outputs to `DefaultInfo.files`. Use the rule target's
+    label as input for rules which consume the output instead of a predeclared
+    output's label.
+
+*   For [executable rules](#executable-rules), `ctx.outputs.executable` refers
+    to a predeclared executable output with the same name as the rule target.
+    Prefer declaring the output explicitly, for example with
+    `ctx.actions.declare_file(ctx.label.name)`, and ensure that the command that
+    generates the executable sets its permissions to allow execution. Explicitly
+    pass the executable output to the `executable` parameter of `DefaultInfo`.
+
+### Runfiles features to avoid
+
+[`ctx.runfiles`](/versions/9.1.0/rules/lib/builtins/ctx#runfiles) and the [`runfiles`](/versions/9.1.0/rules/lib/builtins/runfiles)
+type have a complex set of features, many of which are kept for legacy reasons.
+The following recommendations help reduce complexity:
+
+*   **Avoid** use of the `collect_data` and `collect_default` modes of
+    [`ctx.runfiles`](/versions/9.1.0/rules/lib/builtins/ctx#runfiles). These modes implicitly collect
+    runfiles across certain hardcoded dependency edges in confusing ways.
+    Instead, add files using the `files` or `transitive_files` parameters of
+    `ctx.runfiles`, or by merging in runfiles from dependencies with
+    `runfiles = runfiles.merge(dep[DefaultInfo].default_runfiles)`.
+
+*   **Avoid** use of the `data_runfiles` and `default_runfiles` of the
+    `DefaultInfo` constructor. Specify `DefaultInfo(runfiles = ...)` instead.
+    The distinction between "default" and "data" runfiles is maintained for
+    legacy reasons. For example, some rules put their default outputs in
+    `data_runfiles`, but not `default_runfiles`. Instead of using
+    `data_runfiles`, rules should *both* include default outputs and merge in
+    `default_runfiles` from attributes which provide runfiles (often
+    [`data`](/versions/9.1.0/reference/be/common-definitions#common-attributes.data)).
+
+*   When retrieving `runfiles` from `DefaultInfo` (generally only for merging
+    runfiles between the current rule and its dependencies), use
+    `DefaultInfo.default_runfiles`, **not** `DefaultInfo.data_runfiles`.
+
+### Migrating from legacy providers
+
+Historically, Bazel providers were simple fields on the `Target` object. They
+were accessed using the dot operator, and they were created by putting the field
+in a [`struct`](/versions/9.1.0/rules/lib/builtins/struct) returned by the rule's
+implementation function instead of a list of provider objects:
+
+```python
+return struct(example_info = struct(headers = depset(...)))
+```
+
+Such providers can be retrieved from the corresponding field of the `Target` object:
+
+```python
+transitive_headers = [hdr.example_info.headers for hdr in ctx.attr.hdrs]
+```
+
+*This style is deprecated and should not be used in new code;* see following for
+information that may help you migrate. The new provider mechanism avoids name
+clashes. It also supports data hiding, by requiring any code accessing a
+provider instance to retrieve it using the provider symbol.
+
+For the moment, legacy providers are still supported. A rule can return both
+legacy and modern providers as follows:
+
+```python
+def _old_rule_impl(ctx):
+  ...
+  legacy_data = struct(x = "foo", ...)
+  modern_data = MyInfo(y = "bar", ...)
+  # When any legacy providers are returned, the top-level returned value is a
+  # struct.
+  return struct(
+      # One key = value entry for each legacy provider.
+      legacy_info = legacy_data,
+      ...
+      # Additional modern providers:
+      providers = [modern_data, ...])
+```
+
+If `dep` is the resulting `Target` object for an instance of this rule, the
+providers and their contents can be retrieved as `dep.legacy_info.x` and
+`dep[MyInfo].y`.
+
+In addition to `providers`, the returned struct can also take several other
+fields that have special meaning (and thus don't create a corresponding legacy
+provider):
+
+*   The fields `files`, `runfiles`, `data_runfiles`, `default_runfiles`, and
+    `executable` correspond to the same-named fields of
+    [`DefaultInfo`](/versions/9.1.0/rules/lib/providers/DefaultInfo). It is not allowed to specify any of
+    these fields while also returning a `DefaultInfo` provider.
+
+*   The field `output_groups` takes a struct value and corresponds to an
+    [`OutputGroupInfo`](/versions/9.1.0/rules/lib/providers/OutputGroupInfo).
+
+In [`provides`](/versions/9.1.0/rules/lib/globals/bzl#rule.provides) declarations of rules, and in
+[`providers`](/versions/9.1.0/rules/lib/toplevel/attr#label_list.providers) declarations of dependency
+attributes, legacy providers are passed in as strings and modern providers are
+passed in by their `Info` symbol. Be sure to change from strings to symbols
+when migrating. For complex or large rule sets where it is difficult to update
+all rules atomically, you may have an easier time if you follow this sequence of
+steps:
+
+1.  Modify the rules that produce the legacy provider to produce both the legacy
+    and modern providers, using the preceding syntax. For rules that declare they
+    return the legacy provider, update that declaration to include both the
+    legacy and modern providers.
+
+2.  Modify the rules that consume the legacy provider to instead consume the
+    modern provider. If any attribute declarations require the legacy provider,
+    also update them to instead require the modern provider. Optionally, you can
+    interleave this work with step 1 by having consumers accept or require either
+    provider: Test for the presence of the legacy provider using
+    `hasattr(target, 'foo')`, or the new provider using `FooInfo in target`.
+
+3.  Fully remove the legacy provider from all rules.
diff --git a/versions/9.1.0/extending/toolchains.mdx b/versions/9.1.0/extending/toolchains.mdx
new file mode 100644
index 00000000..e3fab0a0
--- /dev/null
+++ b/versions/9.1.0/extending/toolchains.mdx
@@ -0,0 +1,669 @@
+---
+title: 'Toolchains'
+---
+
+This page describes the toolchain framework, which is a way for rule authors to
+decouple their rule logic from platform-based selection of tools. It is
+recommended to read the [rules](/versions/9.1.0/extending/rules) and [platforms](/versions/9.1.0/extending/platforms)
+pages before continuing. This page covers why toolchains are needed, how to
+define and use them, and how Bazel selects an appropriate toolchain based on
+platform constraints.
+
+## Motivation {#motivation}
+
+Let's first look at the problem toolchains are designed to solve. Suppose you
+are writing rules to support the "bar" programming language. Your `bar_binary`
+rule would compile `*.bar` files using the `barc` compiler, a tool that itself
+is built as another target in your workspace. Since users who write `bar_binary`
+targets shouldn't have to specify a dependency on the compiler, you make it an
+implicit dependency by adding it to the rule definition as a private attribute.
+
+```python
+bar_binary = rule(
+    implementation = _bar_binary_impl,
+    attrs = {
+        "srcs": attr.label_list(allow_files = True),
+        ...
+        "_compiler": attr.label(
+            default = "//bar_tools:barc_linux",  # the compiler running on linux
+            providers = [BarcInfo],
+        ),
+    },
+)
+```
+
+`//bar_tools:barc_linux` is now a dependency of every `bar_binary` target, so
+it'll be built before any `bar_binary` target. It can be accessed by the rule's
+implementation function just like any other attribute:
+
+```python
+BarcInfo = provider(
+    doc = "Information about how to invoke the barc compiler.",
+    # In the real world, compiler_path and system_lib might hold File objects,
+    # but for simplicity they are strings for this example. arch_flags is a list
+    # of strings.
+    fields = ["compiler_path", "system_lib", "arch_flags"],
+)
+
+def _bar_binary_impl(ctx):
+    ...
+    info = ctx.attr._compiler[BarcInfo]
+    command = "%s -l %s %s" % (
+        info.compiler_path,
+        info.system_lib,
+        " ".join(info.arch_flags),
+    )
+    ...
+```
+
+The issue here is that the compiler's label is hardcoded into `bar_binary`, yet
+different targets may need different compilers depending on what platform they
+are being built for and what platform they are being built on -- called the
+*target platform* and *execution platform*, respectively. Furthermore, the rule
+author does not necessarily even know all the available tools and platforms, so
+it is not feasible to hardcode them in the rule's definition.
+
+A less-than-ideal solution would be to shift the burden onto users, by making
+the `_compiler` attribute non-private. Then individual targets could be
+hardcoded to build for one platform or another.
+
+```python
+bar_binary(
+    name = "myprog_on_linux",
+    srcs = ["mysrc.bar"],
+    compiler = "//bar_tools:barc_linux",
+)
+
+bar_binary(
+    name = "myprog_on_windows",
+    srcs = ["mysrc.bar"],
+    compiler = "//bar_tools:barc_windows",
+)
+```
+
+You can improve on this solution by using `select` to choose the `compiler`
+[based on the platform](/versions/9.1.0/docs/configurable-attributes):
+
+```python
+config_setting(
+    name = "on_linux",
+    constraint_values = [
+        "@platforms//os:linux",
+    ],
+)
+
+config_setting(
+    name = "on_windows",
+    constraint_values = [
+        "@platforms//os:windows",
+    ],
+)
+
+bar_binary(
+    name = "myprog",
+    srcs = ["mysrc.bar"],
+    compiler = select({
+        ":on_linux": "//bar_tools:barc_linux",
+        ":on_windows": "//bar_tools:barc_windows",
+    }),
+)
+```
+
+But this is tedious and a bit much to ask of every single `bar_binary` user.
+If this style is not used consistently throughout the workspace, it leads to
+builds that work fine on a single platform but fail when extended to
+multi-platform scenarios. It also does not address the problem of adding support
+for new platforms and compilers without modifying existing rules or targets.
+
+The toolchain framework solves this problem by adding an extra level of
+indirection. Essentially, you declare that your rule has an abstract dependency
+on *some* member of a family of targets (a toolchain type), and Bazel
+automatically resolves this to a particular target (a toolchain) based on the
+applicable platform constraints. Neither the rule author nor the target author
+need know the complete set of available platforms and toolchains.
+
+## Writing rules that use toolchains {#writing-rules-toolchains}
+
+Under the toolchain framework, instead of having rules depend directly on tools,
+they instead depend on *toolchain types*. A toolchain type is a simple target
+that represents a class of tools that serve the same role for different
+platforms. For instance, you can declare a type that represents the bar
+compiler:
+
+```python
+# By convention, toolchain_type targets are named "toolchain_type" and
+# distinguished by their package path. So the full path for this would be
+# //bar_tools:toolchain_type.
+toolchain_type(name = "toolchain_type")
+```
+
+The rule definition in the previous section is modified so that instead of
+taking in the compiler as an attribute, it declares that it consumes a
+`//bar_tools:toolchain_type` toolchain.
+
+```python
+bar_binary = rule(
+    implementation = _bar_binary_impl,
+    attrs = {
+        "srcs": attr.label_list(allow_files = True),
+        ...
+        # No `_compiler` attribute anymore.
+    },
+    toolchains = ["//bar_tools:toolchain_type"],
+)
+```
+
+The implementation function now accesses this dependency under `ctx.toolchains`
+instead of `ctx.attr`, using the toolchain type as the key.
+
+```python
+def _bar_binary_impl(ctx):
+    ...
+    info = ctx.toolchains["//bar_tools:toolchain_type"].barcinfo
+    # The rest is unchanged.
+    command = "%s -l %s %s" % (
+        info.compiler_path,
+        info.system_lib,
+        " ".join(info.arch_flags),
+    )
+    ...
+```
+
+`ctx.toolchains["//bar_tools:toolchain_type"]` returns the
+[`ToolchainInfo` provider](/versions/9.1.0/rules/lib/toplevel/platform_common#ToolchainInfo)
+of whatever target Bazel resolved the toolchain dependency to. The fields of the
+`ToolchainInfo` object are set by the underlying tool's rule; in the next
+section, this rule is defined such that there is a `barcinfo` field that wraps
+a `BarcInfo` object.
+
+Bazel's procedure for resolving toolchains to targets is described
+[below](#toolchain-resolution). Only the resolved toolchain target is actually
+made a dependency of the `bar_binary` target, not the whole space of candidate
+toolchains.
+
+### Mandatory and Optional Toolchains {#optional-toolchains}
+
+By default, when a rule expresses a toolchain type dependency using a bare label
+(as shown above), the toolchain type is considered to be **mandatory**. If Bazel
+is unable to find a matching toolchain (see
+[Toolchain resolution](#toolchain-resolution) below) for a mandatory toolchain
+type, this is an error and analysis halts.
+
+It is possible instead to declare an **optional** toolchain type dependency, as
+follows:
+
+```python
+bar_binary = rule(
+    ...
+    toolchains = [
+        config_common.toolchain_type("//bar_tools:toolchain_type", mandatory = False),
+    ],
+)
+```
+
+When an optional toolchain type cannot be resolved, analysis continues, and the
+result of `ctx.toolchains["//bar_tools:toolchain_type"]` is `None`.
+
+The [`config_common.toolchain_type`](/versions/9.1.0/rules/lib/toplevel/config_common#toolchain_type)
+function defaults to mandatory.
+
+The following forms can be used:
+
+-  Mandatory toolchain types:
+   -  `toolchains = ["//bar_tools:toolchain_type"]`
+   -  `toolchains = [config_common.toolchain_type("//bar_tools:toolchain_type")]`
+   -  `toolchains = [config_common.toolchain_type("//bar_tools:toolchain_type", mandatory = True)]`
+- Optional toolchain types:
+   -  `toolchains = [config_common.toolchain_type("//bar_tools:toolchain_type", mandatory = False)]`
+
+```python
+bar_binary = rule(
+    ...
+    toolchains = [
+        "//foo_tools:toolchain_type",
+        config_common.toolchain_type("//bar_tools:toolchain_type", mandatory = False),
+    ],
+)
+```
+
+You can mix and match forms in the same rule, also. However, if the same
+toolchain type is listed multiple times, it will take the most strict version,
+where mandatory is more strict than optional.
+
+### Writing aspects that use toolchains {#writing-aspects-toolchains}
+
+Aspects have access to the same toolchain API as rules: you can define required
+toolchain types, access toolchains via the context, and use them to generate new
+actions using the toolchain.
+
+```py
+bar_aspect = aspect(
+    implementation = _bar_aspect_impl,
+    attrs = {},
+    toolchains = ['//bar_tools:toolchain_type'],
+)
+
+def _bar_aspect_impl(target, ctx):
+  toolchain = ctx.toolchains['//bar_tools:toolchain_type']
+  # Use the toolchain provider like in a rule.
+  return []
+```
+
+## Defining toolchains {#toolchain-definitions}
+
+To define some toolchains for a given toolchain type, you need three things:
+
+1. A language-specific rule representing the kind of tool or tool suite. By
+   convention this rule's name is suffixed with "\_toolchain".
+
+    1.  **Note:** The `\_toolchain` rule cannot create any build actions.
+        Rather, it collects artifacts from other rules and forwards them to the
+        rule that uses the toolchain. That rule is responsible for creating all
+        build actions.
+
+2. Several targets of this rule type, representing versions of the tool or tool
+   suite for different platforms.
+
+3. For each such target, an associated target of the generic
+  [`toolchain`](/versions/9.1.0/reference/be/platforms-and-toolchains#toolchain)
+   rule, to provide metadata used by the toolchain framework. This `toolchain`
+   target also refers to the `toolchain_type` associated with this toolchain.
+   This means that a given `_toolchain` rule could be associated with any
+   `toolchain_type`, and that only in a `toolchain` instance that uses
+   this `_toolchain` rule that the rule is associated with a `toolchain_type`.
+
+For our running example, here's a definition for a `bar_toolchain` rule. Our
+example has only a compiler, but other tools such as a linker could also be
+grouped underneath it.
+
+```python
+def _bar_toolchain_impl(ctx):
+    toolchain_info = platform_common.ToolchainInfo(
+        barcinfo = BarcInfo(
+            compiler_path = ctx.attr.compiler_path,
+            system_lib = ctx.attr.system_lib,
+            arch_flags = ctx.attr.arch_flags,
+        ),
+    )
+    return [toolchain_info]
+
+bar_toolchain = rule(
+    implementation = _bar_toolchain_impl,
+    attrs = {
+        "compiler_path": attr.string(),
+        "system_lib": attr.string(),
+        "arch_flags": attr.string_list(),
+    },
+)
+```
+
+The rule must return a `ToolchainInfo` provider, which becomes the object that
+the consuming rule retrieves using `ctx.toolchains` and the label of the
+toolchain type. `ToolchainInfo`, like `struct`, can hold arbitrary field-value
+pairs. The specification of exactly what fields are added to the `ToolchainInfo`
+should be clearly documented at the toolchain type. In this example, the values
+return wrapped in a `BarcInfo` object to reuse the schema defined above; this
+style may be useful for validation and code reuse.
+
+Now you can define targets for specific `barc` compilers.
+
+```python
+bar_toolchain(
+    name = "barc_linux",
+    arch_flags = [
+        "--arch=Linux",
+        "--debug_everything",
+    ],
+    compiler_path = "/path/to/barc/on/linux",
+    system_lib = "/usr/lib/libbarc.so",
+)
+
+bar_toolchain(
+    name = "barc_windows",
+    arch_flags = [
+        "--arch=Windows",
+        # Different flags, no debug support on windows.
+    ],
+    compiler_path = "C:\\path\\on\\windows\\barc.exe",
+    system_lib = "C:\\path\\on\\windows\\barclib.dll",
+)
+```
+
+Finally, you create `toolchain` definitions for the two `bar_toolchain` targets.
+These definitions link the language-specific targets to the toolchain type and
+provide the constraint information that tells Bazel when the toolchain is
+appropriate for a given platform.
+
+```python
+toolchain(
+    name = "barc_linux_toolchain",
+    exec_compatible_with = [
+        "@platforms//os:linux",
+        "@platforms//cpu:x86_64",
+    ],
+    target_compatible_with = [
+        "@platforms//os:linux",
+        "@platforms//cpu:x86_64",
+    ],
+    toolchain = ":barc_linux",
+    toolchain_type = ":toolchain_type",
+)
+
+toolchain(
+    name = "barc_windows_toolchain",
+    exec_compatible_with = [
+        "@platforms//os:windows",
+        "@platforms//cpu:x86_64",
+    ],
+    target_compatible_with = [
+        "@platforms//os:windows",
+        "@platforms//cpu:x86_64",
+    ],
+    toolchain = ":barc_windows",
+    toolchain_type = ":toolchain_type",
+)
+```
+
+The use of relative path syntax above suggests these definitions are all in the
+same package, but there's no reason the toolchain type, language-specific
+toolchain targets, and `toolchain` definition targets can't all be in separate
+packages.
+
+See the [`go_toolchain`](https://github.com/bazelbuild/rules_go/blob/master/go/private/go_toolchain.bzl)
+for a real-world example.
+
+### Toolchains and configurations
+
+An important question for rule authors is, when a `bar_toolchain` target is
+analyzed, what [configuration](/versions/9.1.0/reference/glossary#configuration) does it see, and what transitions
+should be used for dependencies? The example above uses string attributes, but
+what would happen for a more complicated toolchain that depends on other targets
+in the Bazel repository?
+
+Let's see a more complex version of `bar_toolchain`:
+
+```python
+def _bar_toolchain_impl(ctx):
+    # The implementation is mostly the same as above, so skipping.
+    pass
+
+bar_toolchain = rule(
+    implementation = _bar_toolchain_impl,
+    attrs = {
+        "compiler": attr.label(
+            executable = True,
+            mandatory = True,
+            cfg = "exec",
+        ),
+        "system_lib": attr.label(
+            mandatory = True,
+            cfg = "target",
+        ),
+        "arch_flags": attr.string_list(),
+    },
+)
+```
+
+The use of [`attr.label`](/versions/9.1.0/rules/lib/toplevel/attr#label) is the same as for a standard rule,
+but the meaning of the `cfg` parameter is slightly different.
+
+When a target (the "parent") depends on a toolchain via toolchain resolution,
+Bazel applies a special configuration transition called the "toolchain transition".
+
+In this transition Bazel keeps the overall configuration identical, but forces
+the toolchain to use the same execution platform as the parent. Without this,
+toolchain resolution could pick a different execution platform for the
+toolchain, and the tools it provides might not be runnable for the parent's
+actions.
+
+This alignment of execution platforms guarantees that any dependencies of the
+toolchain declared with `cfg = "exec"` are built so they can run where the
+parent's actions run.
+
+Dependencies declared with `cfg = "target"` (or which omit `cfg`, since
+"target" is the default) are built for the parent's target platform. This lets
+the toolchain contribute both runtime libraries and build-time tools.
+
+In practice:
+
+- `cfg = "exec"`: build artifacts intended to run during the build (e.g.
+  the `compiler` tool) and therefore for the execution platform.
+- `cfg = "target"`: build artifacts intended to be linked into or shipped with
+  the final output (e.g. the `system_lib`) and therefore for the target
+  platform.
+
+The system libraries must be built for the same target platform as the final
+artifact, while the compiler must be runnable on the execution platform.
+
+### Selecting `exec` dependencies
+
+For toolchain config rules, adding a `select()` to an attribute with `cfg = "exec"`
+does **not** make the `select()` use the exec configuration.
+It will still be resolved under the **target** configuration.
+
+Assuming the target platform is not matching any of these constraints, the select for the compiler
+will fail to analyze.
+
+```python
+bar_toolchain(
+    name = "barc_omni",
+    compiler = select({
+        "@platforms//os:linux": Label(":linux_compiler"),
+        "@platforms//os:windows": Label(":windows_compiler"),
+        "//some/exec:platform": Label(":special_compiler"),
+        },
+        no_match_error = "No compiler for this execution platform",
+    }),
+    # <...>
+)
+```
+
+A known workaround for this is to defer the evaluation behind another target,
+e.g. [`alias()`](/versions/9.1.0/reference/be/general#alias).
+This analyzes the `select` inside the alias under the exec configuration.
+
+```python
+alias(
+    name = "host_specific_compiler",
+    actual = select({
+        "@platforms//os:linux": Label(":linux_compiler"),
+        "@platforms//os:windows": Label(":windows_compiler"),
+        "//some/exec:platform": Label(":special_compiler"),
+        },
+        no_match_error = "No compiler for this execution platform",
+    ),
+)
+
+bar_toolchain(
+    name = "barc_omni",
+    compiler = ":host_specific_compiler",
+    # <...>
+)
+```
+
+## Registering and building with toolchains {#registering-building-toolchains}
+
+At this point all the building blocks are assembled, and you just need to make
+the toolchains available to Bazel's resolution procedure. This is done by
+registering the toolchain, either in a `MODULE.bazel` file using
+`register_toolchains()`, or by passing the toolchains' labels on the command
+line using the `--extra_toolchains` flag.
+
+```python
+register_toolchains(
+    "//bar_tools:barc_linux_toolchain",
+    "//bar_tools:barc_windows_toolchain",
+    # Target patterns are also permitted, so you could have also written:
+    # "//bar_tools:all",
+    # or even
+    # "//bar_tools/...",
+)
+```
+
+When using target patterns to register toolchains, the order in which the
+individual toolchains are registered is determined by the following rules:
+
+* The toolchains defined in a subpackage of a package are registered before the
+  toolchains defined in the package itself.
+* Within a package, toolchains are registered in the lexicographical order of
+  their names.
+
+Now when you build a target that depends on a toolchain type, an appropriate
+toolchain will be selected based on the target and execution platforms.
+
+```python
+# my_pkg/BUILD
+
+platform(
+    name = "my_target_platform",
+    constraint_values = [
+        "@platforms//os:linux",
+    ],
+)
+
+bar_binary(
+    name = "my_bar_binary",
+    ...
+)
+```
+
+```sh
+bazel build //my_pkg:my_bar_binary --platforms=//my_pkg:my_target_platform
+```
+
+Bazel will see that `//my_pkg:my_bar_binary` is being built with a platform that
+has `@platforms//os:linux` and therefore resolve the
+`//bar_tools:toolchain_type` reference to `//bar_tools:barc_linux_toolchain`.
+This will end up building `//bar_tools:barc_linux` but not
+`//bar_tools:barc_windows`.
+
+## Toolchain resolution {#toolchain-resolution}
+
+Note: [Some Bazel rules](/versions/9.1.0/concepts/platforms#status) do not yet support
+toolchain resolution.
+
+For each target that uses toolchains, Bazel's toolchain resolution procedure
+determines the target's concrete toolchain dependencies. The procedure takes as
+input a set of required toolchain types, the target platform, the list of
+available execution platforms, and the list of available toolchains. Its outputs
+are a selected toolchain for each toolchain type as well as a selected execution
+platform for the current target.
+
+The available execution platforms and toolchains are gathered from the
+external dependency graph via
+[`register_execution_platforms`](/versions/9.1.0/rules/lib/globals/module#register_execution_platforms)
+and
+[`register_toolchains`](/versions/9.1.0/rules/lib/globals/module#register_toolchains) calls in
+`MODULE.bazel` files.
+Additional execution platforms and toolchains may also be specified on the
+command line via
+[`--extra_execution_platforms`](/versions/9.1.0/reference/command-line-reference#flag--extra_execution_platforms)
+and
+[`--extra_toolchains`](/versions/9.1.0/reference/command-line-reference#flag--extra_toolchains).
+The host platform is automatically included as an available execution platform.
+Available platforms and toolchains are tracked as ordered lists for determinism,
+with preference given to earlier items in the list.
+
+The set of available toolchains, in priority order, is created from
+`--extra_toolchains` and `register_toolchains`:
+
+1. Toolchains registered using `--extra_toolchains` are added first. (Within
+   these, the **last** toolchain has highest priority.)
+2. Toolchains registered using `register_toolchains` in the transitive external
+   dependency graph, in the following order: (Within these, the **first**
+   mentioned toolchain has highest priority.)
+  1. Toolchains registered by the root module (as in, the `MODULE.bazel` at the
+     workspace root);
+  2. Toolchains registered in the user's `WORKSPACE` file, including in any
+     macros invoked from there;
+  3. Toolchains registered by non-root modules (as in, dependencies specified by
+     the root module, and their dependencies, and so forth);
+  4. Toolchains registered in the "WORKSPACE suffix"; this is only used by
+     certain native rules bundled with the Bazel installation.
+
+**NOTE:** [Pseudo-targets like `:all`, `:*`, and
+`/...`](/versions/9.1.0/run/build#specifying-build-targets) are ordered by Bazel's package
+loading mechanism, which uses a lexicographic ordering.
+
+The resolution steps are as follows.
+
+1. A `target_compatible_with` or `exec_compatible_with` clause *matches* a
+   platform if, for each `constraint_value` in its list, the platform also has
+   that `constraint_value` (either explicitly or as a default).
+
+   If the platform has `constraint_value`s from `constraint_setting`s not
+   referenced by the clause, these do not affect matching.
+
+1. If the target being built specifies the
+   [`exec_compatible_with` attribute](/versions/9.1.0/reference/be/common-definitions#common.exec_compatible_with)
+   (or its rule definition specifies the
+   [`exec_compatible_with` argument](/versions/9.1.0/rules/lib/globals/bzl#rule.exec_compatible_with)),
+   the list of available execution platforms is filtered to remove
+   any that do not match the execution constraints.
+
+1. The list of available toolchains is filtered to remove any toolchains
+   specifying `target_settings` that don't match the current configuration.
+
+1. For each available execution platform, you associate each toolchain type with
+   the first available toolchain, if any, that is compatible with this execution
+   platform and the target platform.
+
+1. Any execution platform that failed to find a compatible mandatory toolchain
+   for one of its toolchain types is ruled out. Of the remaining platforms, the
+   first one becomes the current target's execution platform, and its associated
+   toolchains (if any) become dependencies of the target.
+
+The chosen execution platform is used to run all actions that the target
+generates.
+
+In cases where the same target can be built in multiple configurations (such as
+for different CPUs) within the same build, the resolution procedure is applied
+independently to each version of the target.
+
+If the rule uses [execution groups](/versions/9.1.0/extending/exec-groups), each execution
+group performs toolchain resolution separately, and each has its own execution
+platform and toolchains.
+
+## Debugging toolchains {#debugging-toolchains}
+
+If you are adding toolchain support to an existing rule, use the
+`--toolchain_resolution_debug=regex` flag. During toolchain resolution, the flag
+provides verbose output for toolchain types or target names that match the regex variable. You
+can use `.*` to output all information. Bazel will output names of toolchains it
+checks and skips during the resolution process.
+
+For example, to debug toolchain selection for all actions created directly by
+`//my:target`:
+
+```sh
+$ bazel build //my:all --toolchain_resolution_debug=//my:target
+```
+
+To debug toolchain selection for all actions over all build targets:
+
+```sh
+$ bazel build //my:all --toolchain_resolution_debug=.*
+```
+
+If you'd like to see which [`cquery`](/versions/9.1.0/query/cquery) dependencies are from toolchain
+resolution, use `cquery`'s [`--transitions`](/versions/9.1.0/query/cquery#transitions) flag:
+
+```
+# Find all direct dependencies of //cc:my_cc_lib. This includes explicitly
+# declared dependencies, implicit dependencies, and toolchain dependencies.
+$ bazel cquery 'deps(//cc:my_cc_lib, 1)'
+//cc:my_cc_lib (96d6638)
+@bazel_tools//tools/cpp:toolchain (96d6638)
+@bazel_tools//tools/def_parser:def_parser (HOST)
+//cc:my_cc_dep (96d6638)
+@local_config_platform//:host (96d6638)
+@bazel_tools//tools/cpp:toolchain_type (96d6638)
+//:default_host_platform (96d6638)
+@local_config_cc//:cc-compiler-k8 (HOST)
+//cc:my_cc_lib.cc (null)
+@bazel_tools//tools/cpp:grep-includes (HOST)
+
+# Which of these are from toolchain resolution?
+$ bazel cquery 'deps(//cc:my_cc_lib, 1)' --transitions=lite | grep "toolchain dependency"
+  [toolchain dependency]#@local_config_cc//:cc-compiler-k8#HostTransition -> b6df211
+```
diff --git a/versions/9.1.0/external/extension.mdx b/versions/9.1.0/external/extension.mdx
new file mode 100644
index 00000000..d174ff60
--- /dev/null
+++ b/versions/9.1.0/external/extension.mdx
@@ -0,0 +1,307 @@
+---
+title: 'Module extensions'
+---
+
+Module extensions allow users to extend the module system by reading input data
+from modules across the dependency graph, performing necessary logic to resolve
+dependencies, and finally creating repos by calling [repo
+rules](/versions/9.1.0/external/repo). These extensions have capabilities similar to repo
+rules, which enables them to perform file I/O, send network requests, and so on.
+Among other things, they allow Bazel to interact with other package management
+systems while also respecting the dependency graph built out of Bazel modules.
+
+You can define module extensions in `.bzl` files, just like repo rules. They're
+not invoked directly; rather, each module specifies pieces of data called *tags*
+for extensions to read. Bazel runs module resolution before evaluating any
+extensions. The extension reads all the tags belonging to it across the entire
+dependency graph.
+
+## Extension usage
+
+Extensions are hosted in Bazel modules themselves. To use an extension in a
+module, first add a `bazel_dep` on the module hosting the extension, and then
+call the [`use_extension`](/versions/9.1.0/rules/lib/globals/module#use_extension) built-in function
+to bring it into scope. Consider the following example — a snippet from a
+`MODULE.bazel` file to use the "maven" extension defined in the
+[`rules_jvm_external`](https://github.com/bazelbuild/rules_jvm_external)
+module:
+
+```python
+bazel_dep(name = "rules_jvm_external", version = "4.5")
+maven = use_extension("@rules_jvm_external//:extensions.bzl", "maven")
+```
+
+This binds the return value of `use_extension` to a variable, which allows the
+user to use dot-syntax to specify tags for the extension. The tags must follow
+the schema defined by the corresponding *tag classes* specified in the
+[extension definition](#extension_definition). For an example specifying some
+`maven.install` and `maven.artifact` tags:
+
+```python
+maven.install(artifacts = ["org.junit:junit:4.13.2"])
+maven.artifact(group = "com.google.guava",
+               artifact = "guava",
+               version = "27.0-jre",
+               exclusions = ["com.google.j2objc:j2objc-annotations"])
+```
+
+Use the [`use_repo`](/versions/9.1.0/rules/lib/globals/module#use_repo) directive to bring repos
+generated by the extension into the scope of the current module.
+
+```python
+use_repo(maven, "maven")
+```
+
+Repos generated by an extension are part of its API. In this example, the
+"maven" module extension promises to generate a repo called `maven`. With the
+declaration above, the extension properly resolves labels such as
+`@maven//:org_junit_junit` to point to the repo generated by the "maven"
+extension.
+
+Note: Module extensions are evaluated lazily. This means that an extension will
+typically not be evaluated unless some module brings one of its repositories
+into scope using `use_repo` and that repository is referenced in a build. While
+testing a module extension, `bazel mod deps` can be useful as it
+unconditionally evaluates all module extensions.
+
+## Extension definition
+
+You can define module extensions similarly to [repo rules](/versions/9.1.0/external/repo),
+using the [`module_extension`](/versions/9.1.0/rules/lib/globals/bzl#module_extension)
+function. However, while repo rules have a number of attributes, module
+extensions have [`tag_class`es](/versions/9.1.0/rules/lib/globals/bzl#tag_class), each of which
+has a number of attributes. The tag classes define schemas for tags used by this
+extension. For example, the "maven" extension above might be defined like this:
+
+```python
+# @rules_jvm_external//:extensions.bzl
+
+_install = tag_class(attrs = {"artifacts": attr.string_list(), ...})
+_artifact = tag_class(attrs = {"group": attr.string(), "artifact": attr.string(), ...})
+maven = module_extension(
+  implementation = _maven_impl,
+  tag_classes = {"install": _install, "artifact": _artifact},
+)
+```
+
+These declarations show that `maven.install` and `maven.artifact` tags can be
+specified using the specified attribute schema.
+
+The implementation function of module extensions are similar to those of repo
+rules, except that they get a [`module_ctx`](/versions/9.1.0/rules/lib/builtins/module_ctx) object,
+which grants access to all modules using the extension and all pertinent tags.
+The implementation function then calls repo rules to generate repos.
+
+```python
+# @rules_jvm_external//:extensions.bzl
+
+load("@bazel_tools//tools/build_defs/repo:http.bzl", "http_file")  # a repo rule
+def _maven_impl(ctx):
+  # This is a fake implementation for demonstration purposes only
+
+  # collect artifacts from across the dependency graph
+  artifacts = []
+  for mod in ctx.modules:
+    for install in mod.tags.install:
+      artifacts += install.artifacts
+    artifacts += [_to_artifact(artifact) for artifact in mod.tags.artifact]
+
+  # call out to the coursier CLI tool to resolve dependencies
+  output = ctx.execute(["coursier", "resolve", artifacts])
+  repo_attrs = _process_coursier_output(output)
+
+  # call repo rules to generate repos
+  for attrs in repo_attrs:
+    http_file(**attrs)
+  _generate_hub_repo(name = "maven", repo_attrs)
+```
+
+### Extension identity
+
+Module extensions are identified by the name and the `.bzl` file that appears
+in the call to `use_extension`. In the following example, the extension `maven`
+is identified by the `.bzl` file `@rules_jvm_external//:extension.bzl` and the
+name `maven`:
+
+```python
+maven = use_extension("@rules_jvm_external//:extensions.bzl", "maven")
+```
+
+Re-exporting an extension from a different `.bzl` file gives it a new identity
+and if both versions of the extension are used in the transitive module graph,
+then they will be evaluated separately and will only see the tags associated
+with that particular identity.
+
+As an extension author you should make sure that users will only use your
+module extension from one single `.bzl` file.
+
+## Repository names and visibility
+
+Repos generated by extensions have canonical names in the form of `MODULE_REPO_CANONICAL_NAME+EXTENSION_NAME+repo_name`. Note that the canonical name
+format is not an API you should depend on — it's subject to change at any time.
+
+This naming policy means that each extension has its own "repo namespace"; two
+distinct extensions can each define a repo with the same name without risking
+any clashes. It also means that `repository_ctx.name` reports the canonical name
+of the repo, which is *not* the same as the name specified in the repo rule
+call.
+
+Taking repos generated by module extensions into consideration, there are
+several repo visibility rules:
+
+*   A Bazel module repo can see all repos introduced in its `MODULE.bazel` file
+    via [`bazel_dep`](/versions/9.1.0/rules/lib/globals/module#bazel_dep) and
+    [`use_repo`](/versions/9.1.0/rules/lib/globals/module#use_repo).
+*   A repo generated by a module extension can see all repos visible to the
+    module that hosts the extension, *plus* all other repos generated by the
+    same module extension (using the names specified in the repo rule calls as
+    their apparent names).
+    *   This might result in a conflict. If the module repo can see a repo with
+        the apparent name `foo`, and the extension generates a repo with the
+        specified name `foo`, then for all repos generated by that extension
+        `foo` refers to the former.
+*   Similarly, in a module extension's implementation function, repos created
+    by the extension can refer to each other by their apparent names in
+    attributes, regardless of the order in which they are created.
+    *   In case of a conflict with a repository visible to the module, labels
+        passed to repository rule attributes can be wrapped in a call to
+        [`Label`](/versions/9.1.0/rules/lib/toplevel/attr#label) to ensure that they refer to
+        the repo visible to the module instead of the extension-generated repo
+        of the same name.
+
+### Overriding and injecting module extension repos
+
+The root module can use
+[`override_repo`](/versions/9.1.0/rules/lib/globals/module#override_repo) and
+[`inject_repo`](/versions/9.1.0/rules/lib/globals/module#inject_repo) to override or inject
+module extension repos.
+
+#### Example: Replacing `rules_java`'s `java_tools` with a vendored copy
+
+```python
+# MODULE.bazel
+local_repository = use_repo_rule("@bazel_tools//tools/build_defs/repo:local.bzl", "local_repository")
+local_repository(
+  name = "my_java_tools",
+  path = "vendor/java_tools",
+)
+
+bazel_dep(name = "rules_java", version = "7.11.1")
+java_toolchains = use_extension("@rules_java//java:extension.bzl", "toolchains")
+
+override_repo(java_toolchains, remote_java_tools = "my_java_tools")
+```
+
+#### Example: Patch a Go dependency to depend on `@zlib` instead of the system zlib
+
+```python
+# MODULE.bazel
+bazel_dep(name = "gazelle", version = "0.38.0")
+bazel_dep(name = "zlib", version = "1.3.1.bcr.3")
+
+go_deps = use_extension("@gazelle//:extensions.bzl", "go_deps")
+go_deps.from_file(go_mod = "//:go.mod")
+go_deps.module_override(
+  patches = [
+    "//patches:my_module_zlib.patch",
+  ],
+  path = "example.com/my_module",
+)
+use_repo(go_deps, ...)
+
+inject_repo(go_deps, "zlib")
+```
+
+```diff
+# patches/my_module_zlib.patch
+--- a/BUILD.bazel
++++ b/BUILD.bazel
+@@ -1,6 +1,6 @@
+ go_binary(
+     name = "my_module",
+     importpath = "example.com/my_module",
+     srcs = ["my_module.go"],
+-    copts = ["-lz"],
++    cdeps = ["@zlib"],
+ )
+```
+
+## Best practices
+
+This section describes best practices when writing extensions so they are
+straightforward to use, maintainable, and adapt well to changes over time.
+
+### Put each extension in a separate file
+
+When extensions are in a different files, it allows one extension to load
+repositories generated by another extension. Even if you don't use this
+functionality, it's best to put them in separate files in case you need it
+later. This is because the extension's identify is based on its file, so moving
+the extension into another file later changes your public API and is a backwards
+incompatible change for your users.
+
+### Specify reproducibility and use facts
+
+If your extension always defines the same repositories given the same inputs
+(extension tags, files it reads, etc.) and in particular doesn't rely on
+any [downloads](/versions/9.1.0/rules/lib/builtins/module_ctx#download) that aren't guarded by
+a checksum, consider returning
+[`extension_metadata`](/versions/9.1.0/rules/lib/builtins/module_ctx#extension_metadata) with
+`reproducible = True`. This allows Bazel to skip this extension when writing to
+the `MODULE.bazel` lockfile, which helps keep the lockfile small and reduces
+the chance of merge conflicts. Note that Bazel still caches the results of
+reproducible extensions in a way that persists across server restarts, so even
+a long-running extension can be marked as reproducible without a performance
+penalty.
+
+If your extension relies on effectively immutable data obtained from outside
+the build, most commonly from the network, but you don't have a checksum
+available to guard the download, consider using the `facts` parameter of
+[`extension_metadata`](/versions/9.1.0/rules/lib/builtins/module_ctx#extension_metadata) to
+persistently record such data and thus allow your extension to become
+reproducible. `facts` is expected to be a dictionary with string keys and
+arbitrary JSON-like Starlark values that is always persisted in the lockfile and
+available to future evaluations of the extension via the
+[`facts`](/versions/9.1.0/rules/lib/builtins/module_ctx#facts) field of `module_ctx`.
+
+`facts` are not invalidated even when the code of your module extension changes,
+so be prepared to handle the case where the structure of `facts` changes.
+Bazel also assumes that two different `facts` dicts produced by two different
+evaluations of the same extension can be shallowly merged (i.e., as if by using
+the `|` operator on two dicts). This is partially enforced by `module_ctx.facts`
+not supporting enumeration of its entries, just lookups by key.
+
+An example of using `facts` would be to record a mapping from version numbers of
+some SDK to the an object containing the download URL and checksum of that
+version. The first time the extension is evaluated, it can fetch this mapping
+from the network, but on later evaluations it can use the mapping from `facts`
+to avoid the network requests.
+
+### Specify dependence on operating system and architecture
+
+If your extension relies on the operating system or its architecture type,
+ensure to indicate this in the extension definition using the `os_dependent`
+and `arch_dependent` boolean attributes. This ensures that Bazel recognizes the
+need for re-evaluation if there are changes to either of them.
+
+Since this kind of dependence on the host makes it more difficult to maintain
+the lockfile entry for this extension, consider
+[marking the extension reproducible](#specify_reproducibility) if possible.
+
+### Only the root module should directly affect repository names
+
+Remember that when an extension creates repositories, they are created within
+the namespace of the extension. This means collisions can occur if different
+modules use the same extension and end up creating a repository with the same
+name. This often manifests as a module extension's `tag_class` having a `name`
+argument that is passed as a repository rule's `name` value.
+
+For example, say the root module, `A`, depends on module `B`. Both modules
+depend on module `mylang`. If both `A` and `B` call
+`mylang.toolchain(name="foo")`, they will both try to create a repository named
+`foo` within the `mylang` module and an error will occur.
+
+To avoid this, either remove the ability to set the repository name directly,
+or only allow the root module to do so. It's OK to allow the root module this
+ability because nothing will depend on it, so it doesn't have to worry about
+another module creating a conflicting name.
diff --git a/versions/9.1.0/external/faq.mdx b/versions/9.1.0/external/faq.mdx
new file mode 100644
index 00000000..e9d13653
--- /dev/null
+++ b/versions/9.1.0/external/faq.mdx
@@ -0,0 +1,339 @@
+---
+title: 'Frequently asked questions'
+---
+
+
+
+
+This page answers some frequently asked questions about external dependencies in
+Bazel.
+
+## MODULE.bazel {#module-bazel}
+
+### How should I version a Bazel module? {#module-versioning-best-practices}
+
+Setting `version` with the [`module`] directive in the source archive
+`MODULE.bazel` can have several downsides and unintended side effects if not
+managed carefully:
+
+*   Duplication: releasing a new version of a module typically involves both
+    incrementing the version in `MODULE.bazel` and tagging the release, two
+    separate steps that can fall out of sync. While automation can
+    reduce this risk, it's simpler and safer to avoid it altogether.
+
+*   Inconsistency: users overriding a module with a specific commit using a
+    [non-registry override] will see an incorrect version. for example, if the
+    `MODULE.bazel` in the source archive sets `version = "0.3.0"` but
+    additional commits have been made since that release, a user overriding
+    with one of those commits would still see `0.3.0`. In reality, the version
+    should reflect that it's ahead of the release, for example `0.3.1-rc1`.
+
+*   Non-registry override issues: using placeholder values can cause issues
+    when users override a module with a non-registry override. For example,
+    `0.0.0` doesn't sort as the highest version, which is usually the expected
+    behavior users want when doing a non-registry override.
+
+Thus, it's best to avoid setting the version in the source archive
+`MODULE.bazel`. Instead, set it in the `MODULE.bazel` stored in the registry
+(e.g., the [Bazel Central Registry]), which is the actual source of truth for
+the module version during Bazel's external dependency resolution (see [Bazel
+registries]).
+
+This is usually automated, for example the [`rules-template`] example rule
+repository uses a [bazel-contrib/publish-to-bcr publish.yaml GitHub Action] to
+publish the release to the BCR. The action [generates a patch for the source
+archive `MODULE.bazel`] with the release version. This patch is stored in the
+registry and is applied when the module is fetched during Bazel's external
+dependency resolution.
+
+This way, the version in the releases in the registry will be correctly set to
+the released version and thus, `bazel_dep`, `single_version_override` and
+`multiple_version_override` will work as expected, while avoiding potential
+issues when doing a non-registry override because the version in the source
+archive will be the default value (`''`), which will always be handled
+correctly (it's the default version value after all) and will behave as
+expected when sorting (the empty string is treated as the highest version).
+
+[Bazel Central Registry]: https://registry.bazel.build/
+[Bazel registries]: https://bazel.build/external/registry
+[bazel-contrib/publish-to-bcr publish.yaml GitHub Action]: https://github.com/bazel-contrib/publish-to-bcr/blob/v0.2.2/.github/workflows/publish.yaml
+[generates a patch for the source archive `MODULE.bazel`]: https://github.com/bazel-contrib/publish-to-bcr/blob/v0.2.2/src/domain/create-entry.ts#L176-L216
+[`module`]: /rules/lib/globals/module#module
+[non-registry override]: module.md#non-registry_overrides
+[`rules-template`]: https://github.com/bazel-contrib/rules-template
+
+### What is a compatibility level?
+
+You should stop using `compatibility_level`.
+
+Increasing `compatibility_level` leads to version conflicts that are difficult
+for end users to resolve. Therefore, starting with Bazel 8.6.0 and 9.1.0, both
+`compatibility_level` and `max_compatibility_level` are no-ops.
+
+Module maintainers introducing major breaking changes should ensure that build
+failures provide clear error messages and actionable migration paths.
+
+**Legacy documentation:**
+
+The [`compatibility_level`](/versions/9.1.0/external/module#compatibility_level) of a Bazel module
+should be incremented _in the same commit_ that introduces a backwards
+incompatible ("breaking") change.
+
+However, Bazel can throw an error if it detects that versions of the _same
+module_ with _different compatibility levels_ exist in the resolved dependency
+graph. This can happen when for example' two modules depend on versions of a
+third module with different compatibility levels.
+
+Thus, incrementing `compatibility_level` too frequently can be very disruptive
+and is discouraged. To avoid this situation, the `compatibility_level` should be
+incremented _only_ when the breaking change affects most use cases and isn't
+easy to migrate and/or work-around.
+
+### Why does MODULE.bazel not support `load`s? {#why-does-module-bazel-not-support-loads}
+
+During dependency resolution, the MODULE.bazel file of all referenced external
+dependencies are fetched from registries. At this stage, the source archives of
+the dependencies are not fetched yet; so if the MODULE.bazel file `load`s
+another file, there is no way for Bazel to actually fetch that file without
+fetching the entire source archive. Note the MODULE.bazel file itself is
+special, as it's directly hosted on the registry.
+
+There are a few use cases that people asking for `load`s in MODULE.bazel are
+generally interested in, and they can be solved without `load`s:
+
+*   Ensuring that the version listed in MODULE.bazel is consistent with build
+    metadata stored elsewhere, for example in a .bzl file: This can be achieved
+    by using the
+    [`native.module_version`](/versions/9.1.0/rules/lib/toplevel/native#module_version) method
+    in a .bzl file loaded from a BUILD file.
+*   Splitting up a very large MODULE.bazel file into manageable sections,
+    particularly for monorepos: The root module can use the
+    [`include`](/versions/9.1.0/rules/lib/globals/module#include) directive to split its
+    MODULE.bazel file into multiple segments. For the same reason we don't allow
+    `load`s in MODULE.bazel files, `include` cannot be used in non-root modules.
+*   Users of the old WORKSPACE system might remember declaring a repo, and then
+    immediately `load`ing from that repo to perform complex logic. This
+    capability has been replaced by [module extensions](/versions/9.1.0/external/extension).
+
+### Can I specify a SemVer range for a `bazel_dep`? {#can-i-specify-a-semver-range-for-a-bazel-dep}
+
+No. Some other package managers like [npm][npm-semver] and [Cargo][cargo-semver]
+support version ranges (implicitly or explicitly), and this often requires a
+constraint solver (making the output harder to predict for users) and makes
+version resolution nonreproducible without a lockfile.
+
+Bazel instead uses [Minimal Version Selection](/versions/9.1.0/external/module#version-selection) like
+Go, which in contrast makes the output easy to predict and guarantees
+reproducibility. This is a tradeoff that matches Bazel's design goals.
+
+Furthermore, Bazel module versions are [a superset of
+SemVer](/versions/9.1.0/external/module#version-format), so what makes sense in a strict SemVer
+environment doesn't always carry over to Bazel module versions.
+
+### Can I automatically get the latest version for a `bazel_dep`? {#can-i-automatically-get-the-latest-version-for-a-bazel-dep}
+
+Some users occasionally ask for the ability to specify `bazel_dep(name = "foo",
+version = "latest")` to automatically get the latest version of a dep. This is
+similar to [the question about SemVer
+ranges](#can-i-specify-a-semver-range-for-a-bazel-dep), and the answer is also
+no.
+
+The recommended solution here is to have automation take care of this. For
+example, [Renovate](https://docs.renovatebot.com/modules/manager/) supports
+Bazel modules.
+
+Sometimes, users asking this question are really looking for a way to quickly
+iterate during local development. This can be achieved by using a
+[`local_path_override`](/versions/9.1.0/rules/lib/globals/module#local_path_override).
+
+### Why all these `use_repo`s? {#why-all-these-use-repos}
+
+Module extension usages in MODULE.bazel files sometimes come with a big
+`use_repo` directive. For example, a typical usage of the
+[`go_deps` extension][go_deps] from `gazelle` might look like:
+
+```python
+go_deps = use_extension("@gazelle//:extensions.bzl", "go_deps")
+go_deps.from_file(go_mod = "//:go.mod")
+use_repo(
+    go_deps,
+    "com_github_gogo_protobuf",
+    "com_github_golang_mock",
+    "com_github_golang_protobuf",
+    "org_golang_x_net",
+    ...  # potentially dozens of lines...
+)
+```
+
+The long `use_repo` directive may seem redundant, since the information is
+arguably already in the referenced `go.mod` file.
+
+The reason Bazel needs this `use_repo` directive is that it runs module
+extensions lazily. That is, a module extension is only run if its result is
+observed. Since a module extension's "output" is repo definitions, this means
+that we only run a module extension if a repo it defines is requested (for
+instance, if the target `@org_golang_x_net//:foo` is built, in the example
+above). However, we don't know which repos a module extension would define until
+after we run it. This is where the `use_repo` directive comes in; the user can
+tell Bazel which repos they expect the extension to generate, and Bazel would
+then only run the extension when these specific repos are used.
+
+To help the maintain this `use_repo` directive, a module extension can return
+an [`extension_metadata`](/versions/9.1.0/rules/lib/builtins/module_ctx#extension_metadata)
+object from its implementation function. The user can run the `bazel mod tidy`
+command to update the `use_repo` directives for these module extensions.
+
+## Bzlmod migration {#bzlmod-migration}
+
+### Which is evaluated first, MODULE.bazel or WORKSPACE? {#which-is-evaluated-first-module-bazel-or-workspace}
+
+When both `--enable_bzlmod` and `--enable_workspace` are set, it's natural to
+wonder which system is consulted first. The short answer is that MODULE.bazel
+(Bzlmod) is evaluated first.
+
+The long answer is that "which evaluates first" is not the right question to
+ask; rather, the right question to ask is: in the context of the repo with
+[canonical name](/versions/9.1.0/external/overview#canonical-repo-name) `@@foo`, what does the [apparent
+repo name](/versions/9.1.0/external/overview#apparent-repo-name) `@bar` resolve to? Alternatively, what
+is the repo mapping of `@@base`?
+
+Labels with apparent repo names (a single leading `@`) can refer to different
+things based on the context they're resolved from. When you see a label
+`@bar//:baz` and wonder what it actually points to, you need to first find out
+what the context repo is: for example, if the label is in a BUILD file located
+in the repo `@@foo`, then the context repo is `@@foo`.
+
+Then, depending on what the context repo is, the ["repository
+visibility" table](/versions/9.1.0/external/migration#repository-visibility) in the migration guide can
+be used to find out which repo an apparent name actually resolves to.
+
+*   If the context repo is the main repo (`@@`):
+    1.  If `bar` is an apparent repo name introduced by the root module's
+        MODULE.bazel file (through any of
+        [`bazel_dep`](/versions/9.1.0/rules/lib/globals/module#bazel_dep.repo_name),
+        [`use_repo`](/versions/9.1.0/rules/lib/globals/module#use_repo),
+        [`module`](/versions/9.1.0/rules/lib/globals/module#module.repo_name),
+        [`use_repo_rule`](/versions/9.1.0/rules/lib/globals/module#use_repo_rule)), then `@bar`
+        resolves to what that MODULE.bazel file claims.
+    2.  Otherwise, if `bar` is a repo defined in WORKSPACE (which means that its
+        canonical name is `@@bar`), then `@bar` resolves to `@@bar`.
+    3.  Otherwise, `@bar` resolves to something like
+        `@@[unknown repo 'bar' requested from @@]`, and this will ultimately
+        result in an error.
+*   If the context repo is a Bzlmod-world repo (that is, it corresponds to a
+    non-root Bazel module, or is generated by a module extension), then it
+    will only ever see other Bzlmod-world repos, and no WORKSPACE-world repos.
+    *   Notably, this includes any repos introduced in a `non_module_deps`-like
+        module extension in the root module, or `use_repo_rule` instantiations
+        in the root module.
+*   If the context repo is defined in WORKSPACE:
+    1.  First, check if the context repo definition has the magical
+        `repo_mapping` attribute. If so, go through the mapping first (so for a
+        repo defined with `repo_mapping = {"@bar": "@baz"}`, we would be looking
+        at `@baz` below).
+    2.  If `bar` is an apparent repo name introduced by the root module's
+        MODULE.bazel file, then `@bar` resolves to what that MODULE.bazel file
+        claims. (This is the same as item 1 in the main repo case.)
+    3.  Otherwise, `@bar` resolves to `@@bar`. This most likely will point to a
+        repo `bar` defined in WORKSPACE; if such a repo is not defined, Bazel
+        will throw an error.
+
+For a more succinct version:
+
+*   Bzlmod-world repos (excluding the main repo) will only see Bzlmod-world
+    repos.
+*   WORKSPACE-world repos (including the main repo) will first see what the root
+    module in the Bzlmod world defines, then fall back to seeing WORKSPACE-world
+    repos.
+
+Of note, labels in the Bazel command line (including Starlark flags, label-typed
+flag values, and build/test target patterns) are treated as having the main repo
+as the context repo.
+
+## Other {#other}
+
+### How do I prepare and run an offline build? {#how-do-i-prepare-and-run-an-offline-build}
+
+Use the `bazel fetch` command to prefetch repos. You can use the `--repo` flag
+(like `bazel fetch --repo @foo`) to fetch only the repo `@foo` (resolved in the
+context of the main repo, see [question
+above](#which-is-evaluated-first-module-bazel-or-workspace)), or use a target
+pattern (like `bazel fetch @foo//:bar`) to fetch all transitive dependencies of
+`@foo//:bar` (this is equivalent to `bazel build --nobuild @foo//:bar`).
+
+The make sure no fetches happen during a build, use `--nofetch`. More precisely,
+this makes any attempt to run a non-local repository rule fail.
+
+If you want to fetch repos _and_ modify them to test locally, consider using
+the [`bazel vendor`](/versions/9.1.0/external/vendor) command.
+
+### How do I use HTTP proxies? {#how-do-i-use-http-proxies}
+
+Bazel respects the `http_proxy` and `HTTPS_PROXY` environment variables commonly
+accepted by other programs, such as
+[curl](https://everything.curl.dev/usingcurl/proxies/env.html).
+
+### How do I make Bazel prefer IPv6 in dual-stack IPv4/IPv6 setups? {#ipv6}
+
+On IPv6-only machines, Bazel can download dependencies with no changes. However,
+on dual-stack IPv4/IPv6 machines Bazel follows the same convention as Java,
+preferring IPv4 if enabled. In some situations, for example when the IPv4
+network cannot resolve/reach external addresses, this can cause `Network
+unreachable` exceptions and build failures. In these cases, you can override
+Bazel's behavior to prefer IPv6 by using the
+[`java.net.preferIPv6Addresses=true` system
+property](https://docs.oracle.com/javase/8/docs/api/java/net/doc-files/net-properties.html).
+Specifically:
+
+*   Use `--host_jvm_args=-Djava.net.preferIPv6Addresses=true` [startup
+    option](/versions/9.1.0/docs/user-manual#startup-options), for example by adding the
+    following line in your [`.bazelrc` file](/versions/9.1.0/run/bazelrc):
+
+    `startup --host_jvm_args=-Djava.net.preferIPv6Addresses=true`
+
+*   When running Java build targets that need to connect to the internet (such
+    as for integration tests), use the
+    `--jvmopt=-Djava.net.preferIPv6Addresses=true` [tool
+    flag](/versions/9.1.0/docs/user-manual#jvmopt). For example, include in your [`.bazelrc`
+    file](/versions/9.1.0/run/bazelrc):
+
+    `build --jvmopt=-Djava.net.preferIPv6Addresses`
+
+*   If you are using
+    [`rules_jvm_external`](https://github.com/bazelbuild/rules_jvm_external) for
+    dependency version resolution, also add
+    `-Djava.net.preferIPv6Addresses=true` to the `COURSIER_OPTS` environment
+    variable to [provide JVM options for
+    Coursier](https://github.com/bazelbuild/rules_jvm_external#provide-jvm-options-for-coursier-with-coursier_opts).
+
+### Can repo rules be run remotely with remote execution? {#can-repo-rules-be-run-remotely-with-remote-execution}
+
+No; or at least, not yet. Users employing remote execution services to speed up
+their builds may notice that repo rules are still run locally. For example, an
+`http_archive` would be first downloaded onto the local machine (using any local
+download cache if applicable), extracted, and then each source file would be
+uploaded to the remote execution service as an input file. It's natural to ask
+why the remote execution service doesn't just download and extract that archive,
+saving a useless roundtrip.
+
+Part of the reason is that repo rules (and module extensions) are akin to
+"scripts" that are run by Bazel itself. A remote executor doesn't necessarily
+even have a Bazel installed.
+
+Another reason is that Bazel often needs the BUILD files in the downloaded and
+extracted archives to perform loading and analysis, which _are_ performed
+locally.
+
+There are preliminary ideas to solve this problem by re-imagining repo rules as
+build rules, which would naturally allow them to be run remotely, but conversely
+raise new architectural concerns (for example, the `query` commands would
+potentially need to run actions, complicating their design).
+
+For more previous discussion on this topic, see [A way to support repositories
+that need Bazel for being
+fetched](https://github.com/bazelbuild/bazel/discussions/20464).
+
+[npm-semver]: https://docs.npmjs.com/about-semantic-versioning
+[cargo-semver]: https://doc.rust-lang.org/cargo/reference/specifying-dependencies.html#version-requirement-syntax
+[go_deps]: https://github.com/bazel-contrib/rules_go/blob/master/docs/go/core/bzlmod.md#specifying-external-dependencies
+
diff --git a/versions/9.1.0/external/lockfile.mdx b/versions/9.1.0/external/lockfile.mdx
new file mode 100644
index 00000000..c975a62a
--- /dev/null
+++ b/versions/9.1.0/external/lockfile.mdx
@@ -0,0 +1,285 @@
+keywords: product:Bazel,lockfile,Bzlmod
+
+---
+title: 'Bazel Lockfile'
+---
+
+The lockfile feature in Bazel enables the recording of specific versions or
+dependencies of software libraries or packages required by a project. It
+achieves this by storing the result of module resolution and extension
+evaluation. The lockfile promotes reproducible builds, ensuring consistent
+development environments. Additionally, it enhances build efficiency by allowing
+Bazel to skip the parts of the resolution process that are unaffected by changes
+in project dependencies. Furthermore, the lockfile improves stability by
+preventing unexpected updates or breaking changes in external libraries, thereby
+reducing the risk of introducing bugs.
+
+## Lockfile Generation {#lockfile-generation}
+
+The lockfile is generated under the workspace root with the name
+`MODULE.bazel.lock`. It is created or updated during the build process,
+specifically after module resolution and extension evaluation. Importantly, it
+only includes dependencies that are included in the current invocation of the
+build.
+
+When changes occur in the project that affect its dependencies, the lockfile is
+automatically updated to reflect the new state. This ensures that the lockfile
+remains focused on the specific set of dependencies required for the current
+build, providing an accurate representation of the project's resolved
+dependencies.
+
+## Lockfile Usage {#lockfile-usage}
+
+The lockfile can be controlled by the flag
+[`--lockfile_mode`](/versions/9.1.0/reference/command-line-reference#flag--lockfile_mode) to
+customize the behavior of Bazel when the project state differs from the
+lockfile. The available modes are:
+
+*   `update` (Default): Use the information that is present in the lockfile to
+    skip downloads of known registry files and to avoid re-evaluating extensions
+    whose results are still up-to-date. If information is missing, it will
+    be added to the lockfile. In this mode, Bazel also avoids refreshing
+    mutable information, such as yanked versions, for dependencies that haven't
+    changed.
+*   `refresh`: Like `update`, but mutable information is always refreshed when
+    switching to this mode and roughly every hour while in this mode.
+*   `error`: Like `update`, but if any information is missing or out-of-date,
+    Bazel will fail with an error. This mode never changes the lockfile or
+    performs network requests during resolution. Module extensions that marked
+    themselves as `reproducible` may still perform network requests, but are
+    expected to always produce the same result.
+*   `off`: The lockfile is neither checked nor updated.
+
+## Lockfile Benefits {#lockfile-benefits}
+
+The lockfile offers several benefits and can be utilized in various ways:
+
+-   **Reproducible builds.** By capturing the specific versions or dependencies
+    of software libraries, the lockfile ensures that builds are reproducible
+    across different environments and over time. Developers can rely on
+    consistent and predictable results when building their projects.
+
+-   **Fast incremental resolutions.** The lockfile enables Bazel to avoid
+    downloading registry files that were already used in a previous build.
+    This significantly improves build efficiency, especially in scenarios where
+    resolution can be time-consuming.
+
+-   **Stability and risk reduction.** The lockfile helps maintain stability by
+    preventing unexpected updates or breaking changes in external libraries. By
+    locking the dependencies to specific versions, the risk of introducing bugs
+    due to incompatible or untested updates is reduced.
+
+### Hidden lockfile {#hidden-lockfile}
+
+Bazel also maintains another lockfile at
+`"$(bazel info output_base)"/MODULE.bazel.lock`. The format and contents of this
+lockfile are explicitly unspecified. It is only used as a performance
+optimization. While it can be deleted together with the output base via
+`bazel clean --expunge`, any need to do so is a bug in either Bazel itself or a
+module extension.
+
+## Lockfile Contents {#lockfile-contents}
+
+The lockfile contains all the necessary information to determine whether the
+project state has changed. It also includes the result of building the project
+in the current state. The lockfile consists of two main parts:
+
+1.   Hashes of all remote files that are inputs to module resolution.
+2.   For each module extension, the lockfile includes inputs that affect it,
+     represented by `bzlTransitiveDigest`, `usagesDigest` and other fields, as
+     well as the output of running that extension, referred to as
+     `generatedRepoSpecs`
+
+Here is an example that demonstrates the structure of the lockfile, along with
+explanations for each section:
+
+```json
+{
+  "lockFileVersion": 10,
+  "registryFileHashes": {
+    "https://bcr.bazel.build/bazel_registry.json": "8a28e4af...5d5b3497",
+    "https://bcr.bazel.build/modules/foo/1.0/MODULE.bazel": "7cd0312e...5c96ace2",
+    "https://bcr.bazel.build/modules/foo/2.0/MODULE.bazel": "70390338... 9fc57589",
+    "https://bcr.bazel.build/modules/foo/2.0/source.json": "7e3a9adf...170d94ad",
+    "https://registry.mycorp.com/modules/foo/1.0/MODULE.bazel": "not found",
+    ...
+  },
+  "selectedYankedVersions": {
+    "foo@2.0": "Yanked for demo purposes"
+  },
+  "moduleExtensions": {
+    "//:extension.bzl%lockfile_ext": {
+      "general": {
+        "bzlTransitiveDigest": "oWDzxG/aLnyY6Ubrfy....+Jp6maQvEPxn0pBM=",
+        "usagesDigest": "aLmqbvowmHkkBPve05yyDNGN7oh7QE9kBADr3QIZTZs=",
+        ...,
+        "generatedRepoSpecs": {
+          "hello": {
+            "bzlFile": "@@//:extension.bzl",
+            ...
+          }
+        }
+      }
+    },
+    "//:extension.bzl%lockfile_ext2": {
+      "os:macos": {
+        "bzlTransitiveDigest": "oWDzxG/aLnyY6Ubrfy....+Jp6maQvEPxn0pBM=",
+        "usagesDigest": "aLmqbvowmHkkBPve05y....yDNGN7oh7r3QIZTZs=",
+        ...,
+        "generatedRepoSpecs": {
+          "hello": {
+            "bzlFile": "@@//:extension.bzl",
+            ...
+          }
+        }
+      },
+      "os:linux": {
+        "bzlTransitiveDigest": "eWDzxG/aLsyY3Ubrto....+Jp4maQvEPxn0pLK=",
+        "usagesDigest": "aLmqbvowmHkkBPve05y....yDNGN7oh7r3QIZTZs=",
+        ...,
+        "generatedRepoSpecs": {
+          "hello": {
+            "bzlFile": "@@//:extension.bzl",
+            ...
+          }
+        }
+      }
+    }
+  }
+}
+```
+
+### Registry File Hashes {#registry-file-hashes}
+
+The `registryFileHashes` section contains the hashes of all files from
+remote registries accessed during module resolution. Since the resolution
+algorithm is fully deterministic when given the same inputs and all remote
+inputs are hashed, this ensures a fully reproducible resolution result while
+avoiding excessive duplication of remote information in the lockfile. Note that
+this also requires recording when a particular registry didn't contain a certain
+module, but a registry with lower precedence did (see the "not found" entry in
+the example). This inherently mutable information can be updated via
+`bazel mod deps --lockfile_mode=refresh`.
+
+Bazel uses the hashes from the lockfile to look up registry files in the
+repository cache before downloading them, which speeds up subsequent
+resolutions.
+
+### Selected Yanked Versions {#selected-yanked-versions}
+
+The `selectedYankedVersions` section contains the yanked versions of modules
+that were selected by module resolution. Since this usually result in an error
+when trying to build, this section is only non-empty when yanked versions are
+explicitly allowed via `--allow_yanked_versions` or
+`BZLMOD_ALLOW_YANKED_VERSIONS`.
+
+This field is needed since, compared to module files, yanked version information
+is inherently mutable and thus can't be referenced by a hash. This information
+can be updated via `bazel mod deps --lockfile_mode=refresh`.
+
+### Module Extensions {#module-extensions}
+
+The `moduleExtensions` section is a map that includes only the extensions used
+in the current invocation or previously invoked, while excluding any extensions
+that are no longer utilized. In other words, if an extension is not being used
+anymore across the dependency graph, it is removed from the `moduleExtensions`
+map.
+
+If an extension is independent of the operating system or architecture type,
+this section features only a single "general" entry. Otherwise, multiple
+entries are included, named after the OS, architecture, or both, with each
+corresponding to the result of evaluating the extension on those specifics.
+
+Each entry in the extension map corresponds to a used extension and is
+identified by its containing file and name. The corresponding value for each
+entry contains the relevant information associated with that extension:
+
+1. The `bzlTransitiveDigest` is the digest of the extension implementation
+   and the .bzl files transitively loaded by it.
+2. The `usagesDigest` is the digest of the _usages_ of the extension in the
+   dependency graph, which includes all tags.
+3. Further unspecified fields that track other inputs to the extension,
+   such as contents of files or directories it reads or environment
+   variables it uses.
+4. The `generatedRepoSpecs` encode the repositories created by the
+   extension with the current input.
+5. The optional `moduleExtensionMetadata` field contains metadata provided by
+   the extension such as whether certain repositories it created should be
+   imported via `use_repo` by the root module. This information powers the
+   `bazel mod tidy` command.
+
+Module extensions can opt out of being included in the lockfile by setting the
+returning metadata with `reproducible = True`. By doing so, they promise that
+they will always create the same repositories when given the same inputs.
+
+## Best Practices {#best-practices}
+
+To maximize the benefits of the lockfile feature, consider the following best
+practices:
+
+*   Regularly update the lockfile to reflect changes in project dependencies or
+    configuration. This ensures that subsequent builds are based on the most
+    up-to-date and accurate set of dependencies. To lock down all extensions
+    at once, run `bazel mod deps --lockfile_mode=update`.
+
+*   Include the lockfile in version control to facilitate collaboration and
+    ensure that all team members have access to the same lockfile, promoting
+    consistent development environments across the project.
+
+*   Use [`bazelisk`](/versions/9.1.0/install/bazelisk) to run Bazel, and include a
+    `.bazelversion` file in version control that specifies the Bazel version
+    corresponding to the lockfile. Because Bazel itself is a dependency of
+    your build, the lockfile is specific to the Bazel version, and will
+    change even between [backwards compatible](/versions/9.1.0/release/backward-compatibility)
+    Bazel releases. Using `bazelisk` ensures that all developers are using
+    a Bazel version that matches the lockfile.
+
+By following these best practices, you can effectively utilize the lockfile
+feature in Bazel, leading to more efficient, reliable, and collaborative
+software development workflows.
+
+## Merge Conflicts {#merge-conflicts}
+
+The lockfile format is designed to minimize merge conflicts, but they can still
+happen.
+
+### Automatic Resolution {#automatic-resolution}
+
+Bazel provides a custom
+[git merge driver](https://git-scm.com/docs/gitattributes#_defining_a_custom_merge_driver)
+to help resolve these conflicts automatically.
+
+Set up the driver by adding this line to a `.gitattributes` file in the root of
+your git repository:
+
+```gitattributes
+# A custom merge driver for the Bazel lockfile.
+# https://bazel.build/external/lockfile#automatic-resolution
+MODULE.bazel.lock merge=bazel-lockfile-merge
+```
+
+Then each developer who wants to use the driver has to register it once by
+following these steps:
+
+1. Install [jq](https://jqlang.github.io/jq/download/) (1.5 or higher).
+2. Run the following commands:
+
+```bash
+jq_script=$(curl https://raw.githubusercontent.com/bazelbuild/bazel/master/scripts/bazel-lockfile-merge.jq)
+printf '%s\n' "${jq_script}" | less # to optionally inspect the jq script
+git config --global merge.bazel-lockfile-merge.name   "Merge driver for the Bazel lockfile (MODULE.bazel.lock)"
+git config --global merge.bazel-lockfile-merge.driver "jq -s '${jq_script}' -- %O %A %B > %A.jq_tmp && mv %A.jq_tmp %A"
+```
+
+### Manual Resolution {#manual-resolution}
+
+Simple merge conflicts in the `registryFileHashes` and `selectedYankedVersions`
+fields can be safely resolved by keeping all the entries from both sides of the
+conflict.
+
+Other types of merge conflicts should not be resolved manually. Instead:
+
+1. Restore the previous state of the lockfile
+   via `git reset MODULE.bazel.lock && git checkout MODULE.bazel.lock`.
+2. Resolve any conflicts in the `MODULE.bazel` file.
+3. Run `bazel mod deps` to update the lockfile.
diff --git a/versions/9.1.0/external/migration.mdx b/versions/9.1.0/external/migration.mdx
new file mode 100644
index 00000000..b5ec302d
--- /dev/null
+++ b/versions/9.1.0/external/migration.mdx
@@ -0,0 +1,859 @@
+---
+title: 'Bzlmod Migration Guide'
+---
+
+Due to the [shortcomings of
+WORKSPACE](/versions/9.1.0/external/overview#workspace-shortcomings), Bzlmod is replacing the
+legacy WORKSPACE system. The WORKSPACE file is already disabled in Bazel 8 (late
+2024) and will be removed in Bazel 9 (late 2025). This guide helps you migrate
+your project to Bzlmod and drop WORKSPACE for managing external dependencies.
+
+## Why migrate to Bzlmod? {#why-migrate-to-bzlmod}
+
+*   There are many [advantages](/versions/9.1.0/external/overview#benefits) compared to the legacy
+    WORKSPACE system, which helps to ensure a healthy growth of the Bazel
+    ecosystem.
+
+*   If your project is a dependency of other projects, migrating to Bzlmod will
+    unblock their migration and make it easier for them to depend on your
+    project.
+
+*   Migration to Bzlmod is a necessary step in order to use future Bazel
+    versions (mandatory in Bazel 9).
+
+## How to migrate to Bzlmod? {#how-migrate-to-bzlmod}
+
+Recommended migration process:
+
+1.  Use [migration tool](/versions/9.1.0/external/migration_tool) as a helper tool to
+    streamline the migration process as much as possible.
+2.  If there are errors left after using the migration tool, resolve them
+    manually. For understanding the main differences between concepts inside
+    `WORKSPACE` and `MODULE.bazel` files, check [WORKSPACE versus
+    Bzlmod](#workspace-vs-bzlmod) section.
+
+## WORKSPACE vs Bzlmod {#workspace-vs-bzlmod}
+
+Bazel's WORKSPACE and Bzlmod offer similar features with different syntax. This
+section explains how to migrate from specific WORKSPACE functionalities to
+Bzlmod.
+
+### Define the root of a Bazel workspace {#define-root}
+
+The WORKSPACE file marks the source root of a Bazel project, this responsibility
+is replaced by MODULE.bazel in Bazel version 6.3 and later. With Bazel versions
+prior to 6.3, there should still be a `WORKSPACE` or `WORKSPACE.bazel` file at
+your workspace root, maybe with comments like:
+
+*   **WORKSPACE**
+
+    ```python
+    # This file marks the root of the Bazel workspace.
+    # See MODULE.bazel for external dependencies setup.
+    ```
+
+### Enable Bzlmod in your bazelrc {#enable-bzlmod}
+
+`.bazelrc` lets you set flags that apply every time your run Bazel. To enable
+Bzlmod, use the `--enable_bzlmod` flag, and apply it to the `common` command so
+it applies to every command:
+
+* **.bazelrc**
+
+    ```
+    # Enable Bzlmod for every Bazel command
+    common --enable_bzlmod
+    ```
+
+### Specify repository name for your workspace {#specify-repo-name}
+
+*   **WORKSPACE**
+
+    The [`workspace`](/versions/9.1.0/rules/lib/globals/workspace#workspace) function is used
+    to specify a repository name for your workspace. This allows a target
+    `//foo:bar` in the workspace to be referenced as `@//foo:bar`. If not specified, the default repository name for your
+    workspace is `__main__`.
+
+    ```python
+    ## WORKSPACE
+    workspace(name = "com_foo_bar")
+    ```
+
+*   **Bzlmod**
+
+    It's recommended to reference targets in the same workspace with the
+    `//foo:bar` syntax without `@`. But if you do need the old syntax
+    , you can use the module name specified by the
+    [`module`](/versions/9.1.0/rules/lib/globals/module#module) function as the repository
+    name. If the module name is different from the needed repository name, you
+    can use `repo_name` attribute of the
+    [`module`](/versions/9.1.0/rules/lib/globals/module#module) function to override the
+    repository name.
+
+    ```python
+    ## MODULE.bazel
+    module(
+        name = "bar",
+        repo_name = "com_foo_bar",
+    )
+    ```
+
+### Fetch external dependencies as Bazel modules {#fetch-bazel-modules}
+
+If your dependency is a Bazel project, you should be able to depend on it as a
+Bazel module when it also adopts Bzlmod.
+
+*   **WORKSPACE**
+
+    With WORKSPACE, it's common to use the
+    [`http_archive`](/versions/9.1.0/rules/lib/repo/http#http_archive) or
+    [`git_repository`](/versions/9.1.0/rules/lib/repo/git#git_repository) repository rules to
+    download the sources of the Bazel project.
+
+    ```python
+    ## WORKSPACE
+    load("@bazel_tools//tools/build_defs/repo:http.bzl", "http_archive")
+
+    http_archive(
+        name = "bazel_skylib",
+        urls = ["https://github.com/bazelbuild/bazel-skylib/releases/download/1.4.2/bazel-skylib-1.4.2.tar.gz"],
+        sha256 = "66ffd9315665bfaafc96b52278f57c7e2dd09f5ede279ea6d39b2be471e7e3aa",
+    )
+    load("@bazel_skylib//:workspace.bzl", "bazel_skylib_workspace")
+    bazel_skylib_workspace()
+
+    http_archive(
+        name = "rules_java",
+        urls = ["https://github.com/bazelbuild/rules_java/releases/download/6.1.1/rules_java-6.1.1.tar.gz"],
+        sha256 = "76402a50ae6859d50bd7aed8c1b8ef09dae5c1035bb3ca7d276f7f3ce659818a",
+    )
+    load("@rules_java//java:repositories.bzl", "rules_java_dependencies", "rules_java_toolchains")
+    rules_java_dependencies()
+    rules_java_toolchains()
+    ```
+
+    As you can see, it's a common pattern that users need to load transitive
+    dependencies from a macro of the dependency. Assume both `bazel_skylib` and
+    `rules_java` depends on `platform`, the exact version of the `platform`
+    dependency is determined by the order of the macros.
+
+*   **Bzlmod**
+
+    With Bzlmod, as long as your dependency is available in [Bazel Central
+    Registry](https://registry.bazel.build) or your custom [Bazel
+    registry](/versions/9.1.0/external/registry), you can simply depend on it with a
+    [`bazel_dep`](/versions/9.1.0/rules/lib/globals/module#bazel_dep) directive.
+
+    ```python
+    ## MODULE.bazel
+    bazel_dep(name = "bazel_skylib", version = "1.4.2")
+    bazel_dep(name = "rules_java", version = "6.1.1")
+    ```
+
+    Bzlmod resolves Bazel module dependencies transitively using the
+    [MVS](https://research.swtch.com/vgo-mvs) algorithm. Therefore, the maximal
+    required version of `platform` is selected automatically.
+
+### Override a dependency as a Bazel module {#override-modules}
+
+As the root module, you can override Bazel module dependencies in different
+ways.
+
+Please read the [overrides](/versions/9.1.0/external/module#overrides) section for more
+information.
+
+You can find some example usages in the
+[examples][override-examples]
+repository.
+
+[override-examples]: https://github.com/bazelbuild/examples/blob/main/bzlmod/02-override_bazel_module
+
+### Fetch external dependencies with module extensions {#fetch-deps-module-extensions}
+
+If your dependency is not a Bazel project or not yet available in any Bazel
+registry, you can introduce it using
+[`use_repo_rule`](/versions/9.1.0/external/module#use_repo_rule) or [module
+extensions](/versions/9.1.0/external/extension).
+
+*   **WORKSPACE**
+
+    Download a file using the [`http_file`](/versions/9.1.0/rules/lib/repo/http#http_file)
+    repository rule.
+
+    ```python
+    ## WORKSPACE
+    load("@bazel_tools//tools/build_defs/repo:http.bzl", "http_file")
+
+    http_file(
+        name = "data_file",
+        url = "http://example.com/file",
+        sha256 = "e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855",
+    )
+    ```
+
+*   **Bzlmod**
+
+    With Bzlmod, you can use the `use_repo_rule` directive in your MODULE.bazel
+    file to directly instantiate repos:
+
+    ```python
+    ## MODULE.bazel
+    http_file = use_repo_rule("@bazel_tools//tools/build_defs/repo:http.bzl", "http_file")
+    http_file(
+        name = "data_file",
+        url = "http://example.com/file",
+        sha256 = "e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855",
+    )
+    ```
+
+    Under the hood, this is implemented using a module extension. If you need to
+    perform more complex logic than simply invoking a repo rule, you could also
+    implement a module extension yourself. You'll need to move the definition
+    into a `.bzl` file, which also lets you share the definition between
+    WORKSPACE and Bzlmod during the migration period.
+
+    ```python
+    ## repositories.bzl
+    load("@bazel_tools//tools/build_defs/repo:http.bzl", "http_file")
+    def my_data_dependency():
+        http_file(
+            name = "data_file",
+            url = "http://example.com/file",
+            sha256 = "e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855",
+        )
+    ```
+
+    Implement a module extension to load the dependencies macro. You can define
+    it in the same `.bzl` file of the macro, but to keep compatibility with
+    older Bazel versions, it's better to define it in a separate `.bzl` file.
+
+    ```python
+    ## extensions.bzl
+    load("//:repositories.bzl", "my_data_dependency")
+    def _non_module_dependencies_impl(_ctx):
+        my_data_dependency()
+
+    non_module_dependencies = module_extension(
+        implementation = _non_module_dependencies_impl,
+    )
+    ```
+
+    To make the repository visible to the root project, you should declare the
+    usages of the module extension and the repository in the MODULE.bazel file.
+
+    ```python
+    ## MODULE.bazel
+    non_module_dependencies = use_extension("//:extensions.bzl", "non_module_dependencies")
+    use_repo(non_module_dependencies, "data_file")
+    ```
+
+### Resolve conflict external dependencies with module extension {#conflict-deps-module-extension}
+
+A project can provide a macro that introduces external repositories based on
+inputs from its callers. But what if there are multiple callers in the
+dependency graph and they cause a conflict?
+
+Assume the project `foo` provides the following macro which takes `version` as
+an argument.
+
+```python
+## repositories.bzl in foo
+load("@bazel_tools//tools/build_defs/repo:http.bzl", "http_file")
+def data_deps(version = "1.0"):
+    http_file(
+        name = "data_file",
+        url = "http://example.com/file-%s" % version,
+        # Omitting the "sha256" attribute for simplicity
+    )
+```
+
+*   **WORKSPACE**
+
+    With WORKSPACE, you can load the macro from `@foo` and specify the version
+    of the data dependency you need. Assume you have another dependency `@bar`,
+    which also depends on `@foo` but requires a different version of the data
+    dependency.
+
+    ```python
+    ## WORKSPACE
+
+    # Introduce @foo and @bar.
+    ...
+
+    load("@foo//:repositories.bzl", "data_deps")
+    data_deps(version = "2.0")
+
+    load("@bar//:repositories.bzl", "bar_deps")
+    bar_deps() # -> which calls data_deps(version = "3.0")
+    ```
+
+    In this case, the end user must carefully adjust the order of macros in the
+    WORKSPACE to get the version they need. This is one of the biggest pain
+    points with WORKSPACE since it doesn't really provide a sensible way to
+    resolve dependencies.
+
+*   **Bzlmod**
+
+    With Bzlmod, the author of project `foo` can use module extension to resolve
+    conflicts. For example, let's assume it makes sense to always select the
+    maximal required version of the data dependency among all Bazel modules.
+
+    ```python
+    ## extensions.bzl in foo
+    load("//:repositories.bzl", "data_deps")
+
+    data = tag_class(attrs={"version": attr.string()})
+
+    def _data_deps_extension_impl(module_ctx):
+        # Select the maximal required version in the dependency graph.
+        version = "1.0"
+        for mod in module_ctx.modules:
+            for data in mod.tags.data:
+                version = max(version, data.version)
+        data_deps(version)
+
+    data_deps_extension = module_extension(
+        implementation = _data_deps_extension_impl,
+        tag_classes = {"data": data},
+    )
+    ```
+
+    ```python
+    ## MODULE.bazel in bar
+    bazel_dep(name = "foo", version = "1.0")
+
+    foo_data_deps = use_extension("@foo//:extensions.bzl", "data_deps_extension")
+    foo_data_deps.data(version = "3.0")
+    use_repo(foo_data_deps, "data_file")
+    ```
+
+    ```python
+    ## MODULE.bazel in root module
+    bazel_dep(name = "foo", version = "1.0")
+    bazel_dep(name = "bar", version = "1.0")
+
+    foo_data_deps = use_extension("@foo//:extensions.bzl", "data_deps_extension")
+    foo_data_deps.data(version = "2.0")
+    use_repo(foo_data_deps, "data_file")
+    ```
+
+    In this case, the root module requires data version `2.0`, while its
+    dependency `bar` requires `3.0`. The module extension in `foo` can correctly
+    resolve this conflict and automatically select version `3.0` for the data
+    dependency.
+
+### Integrate third party package manager {#integrate-package-manager}
+
+Following the last section, since module extension provides a way to collect
+information from the dependency graph, perform custom logic to resolve
+dependencies and call repository rules to introduce external repositories, this
+provides a great way for rules authors to enhance the rulesets that integrate
+package managers for specific languages.
+
+Please read the [module extensions](/versions/9.1.0/external/extension) page to learn more
+about how to use module extensions.
+
+Here is a list of the rulesets that already adopted Bzlmod to fetch dependencies
+from different package managers:
+
+- [rules_jvm_external](https://github.com/bazelbuild/rules_jvm_external/blob/master/docs/bzlmod.md)
+- [rules_go](https://github.com/bazelbuild/rules_go/blob/master/docs/go/core/bzlmod.md)
+- [rules_python](https://github.com/bazelbuild/rules_python/blob/main/BZLMOD_SUPPORT.md)
+
+A minimal example that integrates a pseudo package manager is available at the
+[examples][pkg-mgr-example]
+repository.
+
+[pkg-mgr-example]: https://github.com/bazelbuild/examples/tree/main/bzlmod/05-integrate_third_party_package_manager
+
+### Detect toolchains on the host machine {#detect-toolchain}
+
+When Bazel build rules need to detect what toolchains are available on your host
+machine, they use repository rules to inspect the host machine and generate
+toolchain info as external repositories.
+
+*   **WORKSPACE**
+
+    Given the following repository rule to detect a shell toolchain.
+
+    ```python
+    ## local_config_sh.bzl
+    def _sh_config_rule_impl(repository_ctx):
+        sh_path = get_sh_path_from_env("SH_BIN_PATH")
+
+        if not sh_path:
+            sh_path = detect_sh_from_path()
+
+        if not sh_path:
+            sh_path = "/shell/binary/not/found"
+
+        repository_ctx.file("BUILD", """
+    load("@bazel_tools//tools/sh:sh_toolchain.bzl", "sh_toolchain")
+    sh_toolchain(
+        name = "local_sh",
+        path = "{sh_path}",
+        visibility = ["//visibility:public"],
+    )
+    toolchain(
+        name = "local_sh_toolchain",
+        toolchain = ":local_sh",
+        toolchain_type = "@bazel_tools//tools/sh:toolchain_type",
+    )
+    """.format(sh_path = sh_path))
+
+    sh_config_rule = repository_rule(
+        environ = ["SH_BIN_PATH"],
+        local = True,
+        implementation = _sh_config_rule_impl,
+    )
+    ```
+
+    You can load the repository rule in WORKSPACE.
+
+    ```python
+    ## WORKSPACE
+    load("//:local_config_sh.bzl", "sh_config_rule")
+    sh_config_rule(name = "local_config_sh")
+    ```
+
+*   **Bzlmod**
+
+    With Bzlmod, you can introduce the same repository using a module extension,
+    which is similar to introducing the `@data_file` repository in the last
+    section.
+
+    ```
+    ## local_config_sh_extension.bzl
+    load("//:local_config_sh.bzl", "sh_config_rule")
+
+    sh_config_extension = module_extension(
+        implementation = lambda ctx: sh_config_rule(name = "local_config_sh"),
+    )
+    ```
+
+    Then use the extension in the MODULE.bazel file.
+
+    ```python
+    ## MODULE.bazel
+    sh_config_ext = use_extension("//:local_config_sh_extension.bzl", "sh_config_extension")
+    use_repo(sh_config_ext, "local_config_sh")
+    ```
+
+### Register toolchains & execution platforms {#register-toolchains}
+
+Following the last section, after introducing a repository hosting toolchain
+information (e.g. `local_config_sh`), you probably want to register the
+toolchain.
+
+*   **WORKSPACE**
+
+    With WORKSPACE, you can register the toolchain in the following ways.
+
+    1.  You can register the toolchain the `.bzl` file and load the macro in the
+    WORKSPACE file.
+
+        ```python
+        ## local_config_sh.bzl
+        def sh_configure():
+            sh_config_rule(name = "local_config_sh")
+            native.register_toolchains("@local_config_sh//:local_sh_toolchain")
+        ```
+
+        ```python
+        ## WORKSPACE
+        load("//:local_config_sh.bzl", "sh_configure")
+        sh_configure()
+        ```
+
+    2.  Or register the toolchain in the WORKSPACE file directly.
+
+        ```python
+        ## WORKSPACE
+        load("//:local_config_sh.bzl", "sh_config_rule")
+        sh_config_rule(name = "local_config_sh")
+        register_toolchains("@local_config_sh//:local_sh_toolchain")
+        ```
+
+*   **Bzlmod**
+
+    With Bzlmod, the
+    [`register_toolchains`](/versions/9.1.0/rules/lib/globals/module#register_toolchains) and
+    [`register_execution_platforms`][register_execution_platforms]
+    APIs are only available in the MODULE.bazel file. You cannot call
+    `native.register_toolchains` in a module extension.
+
+    ```python
+    ## MODULE.bazel
+    sh_config_ext = use_extension("//:local_config_sh_extension.bzl", "sh_config_extension")
+    use_repo(sh_config_ext, "local_config_sh")
+    register_toolchains("@local_config_sh//:local_sh_toolchain")
+    ```
+
+The toolchains and execution platforms registered in `WORKSPACE`,
+`WORKSPACE.bzlmod` and each Bazel module's `MODULE.bazel` file follow this
+order of precedence during toolchain selection (from highest to lowest):
+
+1. toolchains and execution platforms registered in the root module's
+   `MODULE.bazel` file.
+2. toolchains and execution platforms registered in the `WORKSPACE` or
+   `WORKSPACE.bzlmod` file.
+3. toolchains and execution platforms registered by modules that are
+   (transitive) dependencies of the root module.
+4. when not using `WORKSPACE.bzlmod`: toolchains registered in the `WORKSPACE`
+   [suffix](/versions/9.1.0/external/migration#builtin-default-deps).
+
+[register_execution_platforms]: /rules/lib/globals/module#register_execution_platforms
+
+### Introduce local repositories {#introduce-local-deps}
+
+You may need to introduce a dependency as a local repository when you need a
+local version of the dependency for debugging or you want to incorporate a
+directory in your workspace as external repository.
+
+*   **WORKSPACE**
+
+    With WORKSPACE, this is achieved by two native repository rules,
+    [`local_repository`](/versions/9.1.0/reference/be/workspace#local_repository) and
+    [`new_local_repository`](/versions/9.1.0/reference/be/workspace#new_local_repository).
+
+    ```python
+    ## WORKSPACE
+    local_repository(
+        name = "rules_java",
+        path = "/Users/bazel_user/workspace/rules_java",
+    )
+    ```
+
+*   **Bzlmod**
+
+    With Bzlmod, you can use
+    [`local_path_override`](/versions/9.1.0/rules/lib/globals/module#local_path_override) to
+    override a module with a local path.
+
+    ```python
+    ## MODULE.bazel
+    bazel_dep(name = "rules_java")
+    local_path_override(
+        module_name = "rules_java",
+        path = "/Users/bazel_user/workspace/rules_java",
+    )
+    ```
+
+    Note: With `local_path_override`, you can only introduce a local directory
+    as a Bazel module, which means it should have a MODULE.bazel file and its
+    transitive dependencies are taken into consideration during dependency
+    resolution. In addition, all module override directives can only be used by
+    the root module.
+
+    It is also possible to introduce a local repository with module extension.
+    However, you cannot call `native.local_repository` in module extension,
+    there is ongoing effort on starlarkifying all native repository rules (check
+    [#18285](https://github.com/bazelbuild/bazel/issues/18285) for progress).
+    Then you can call the corresponding starlark `local_repository` in a module
+    extension. It's also trivial to implement a custom version of
+    `local_repository` repository rule if this is a blocking issue for you.
+
+### Bind targets {#bind-targets}
+
+The [`bind`](/versions/9.1.0/reference/be/workspace#bind) rule in WORKSPACE is deprecated and
+not supported in Bzlmod. It was introduced to give a target an alias in the
+special `//external` package. All users depending on this should migrate away.
+
+For example, if you have
+
+```python
+## WORKSPACE
+bind(
+    name = "openssl",
+    actual = "@my-ssl//src:openssl-lib",
+)
+```
+
+This allows other targets to depend on `//external:openssl`. You can migrate
+away from this by:
+
+*   Replace all usages of `//external:openssl` with `@my-ssl//src:openssl-lib`.
+    *   Tip: Use `bazel query --output=build --noenable_bzlmod
+        --enable_workspace [target]` command to find relevant info
+        about the target.
+
+*   Or use the [`alias`](/versions/9.1.0/reference/be/general#alias) build rule
+    *   Define the following target in a package (e.g. `//third_party`)
+
+        ```python
+        ## third_party/BUILD
+        alias(
+            name = "openssl",
+            actual = "@my-ssl//src:openssl-lib",
+        )
+        ```
+
+    *   Replace all usages of `//external:openssl` with `//third_party:openssl`.
+
+### Fetch versus Sync {#fetch-sync}
+
+Fetch and sync commands are used to download external repos locally and keep
+them updated. Sometimes also to allow building offline using the `--nofetch`
+flag after fetching all repos needed for a build.
+
+*   **WORKSPACE**
+
+    Sync performs a force fetch for all repositories, or for a specific
+    configured set of repos, while fetch is _only_ used to fetch for a specific
+    target.
+
+*   **Bzlmod**
+
+    The sync command is no longer applicable, but fetch offers
+    [various options](/versions/9.1.0/reference/command-line-reference#fetch-options).
+    You can fetch a target, a repository, a set of configured repos or all
+    repositories involved in your dependency resolution and module extensions.
+    The fetch result is cached and to force a fetch you must include the
+ `--force` option during the fetch process.
+
+## Manual migration {#manual-migration}
+
+This section provides useful information and guidance for your **manual** Bzlmod
+migration process. For more automatized migration process, check [recommended
+migration process](#how-migrate-to-bzlmod) section.
+
+### Know your dependencies in WORKSPACE {#know-deps-in-workspace}
+
+The first step of migration is to understand what dependencies you have. It
+could be hard to figure out what exact dependencies are introduced in the
+WORKSPACE file because transitive dependencies are often loaded with `*_deps`
+macros.
+
+#### Inspect external dependency with workspace resolved file
+
+Fortunately, the flag
+[`--experimental_repository_resolved_file`][resolved_file_flag]
+can help. This flag essentially generates a "lock file" of all fetched external
+dependencies in your last Bazel command. You can find more details in this [blog
+post](https://blog.bazel.build/2018/07/09/bazel-sync-and-resolved-file.html).
+
+[resolved_file_flag]: /reference/command-line-reference#flag--experimental_repository_resolved_file
+
+It can be used in two ways:
+
+1.  To fetch info of external dependencies needed for building certain targets.
+
+    ```shell
+    bazel clean --expunge
+    bazel build --nobuild --experimental_repository_resolved_file=resolved.bzl //foo:bar
+    ```
+
+2.  To fetch info of all external dependencies defined in the WORKSPACE file.
+
+    ```shell
+    bazel clean --expunge
+    bazel sync --experimental_repository_resolved_file=resolved.bzl
+    ```
+
+    With the `bazel sync` command, you can fetch all dependencies defined in the
+    WORKSPACE file, which include:
+
+    *   `bind` usages
+    *   `register_toolchains` & `register_execution_platforms` usages
+
+    However, if your project is cross platforms, bazel sync may break on certain
+    platforms because some repository rules may only run correctly on supported
+    platforms.
+
+After running the command, you should have information of your external
+dependencies in the `resolved.bzl` file.
+
+#### Inspect external dependency with `bazel query`
+
+You may also know `bazel query` can be used for inspecting repository rules with
+
+```shell
+bazel query --output=build //external:
+```
+
+While it is more convenient and much faster, [bazel query can lie about
+external dependency version](https://github.com/bazelbuild/bazel/issues/12947),
+so be careful using it! Querying and inspecting external
+dependencies with Bzlmod is going to achieved by a [new
+subcommand](https://github.com/bazelbuild/bazel/issues/15365).
+
+#### Built-in default dependencies {#builtin-default-deps}
+
+If you check the file generated by `--experimental_repository_resolved_file`,
+you are going to find many dependencies that are not defined in your WORKSPACE.
+This is because Bazel in fact adds prefixes and suffixes to the user's WORKSPACE
+file content to inject some default dependencies, which are usually required by
+native rules (e.g. `@bazel_tools`, `@platforms` and `@remote_java_tools`). With
+Bzlmod, those dependencies are introduced with a built-in module
+[`bazel_tools`][bazel_tools] , which is a default dependency for every other
+Bazel module.
+
+[bazel_tools]: https://github.com/bazelbuild/bazel/blob/master/src/MODULE.tools
+
+### Hybrid mode for gradual migration {#hybrid-mode}
+
+Bzlmod and WORKSPACE can work side by side, which allows migrating dependencies
+from the WORKSPACE file to Bzlmod to be a gradual process.
+
+Note: In practice, loading "*_deps" macros in WORKSPACE often causes confusions
+with Bzlmod dependencies, therefore we recommend starting with a
+WORKSPACE.bzlmod file and avoid loading transitive dependencies with macros.
+
+#### WORKSPACE.bzlmod
+
+During the migration, Bazel users may need to switch between builds with and
+without Bzlmod enabled. WORKSPACE.bzlmod support is implemented to make the
+process smoother.
+
+WORKSPACE.bzlmod has the exact same syntax as WORKSPACE. When Bzlmod is enabled,
+if a WORKSPACE.bzlmod file also exists at the workspace root:
+
+*   `WORKSPACE.bzlmod` takes effect and the content of `WORKSPACE` is ignored.
+*   No [prefixes or suffixes](/versions/9.1.0/external/migration#builtin-default-deps) are
+    added to the WORKSPACE.bzlmod file.
+
+Using the WORKSPACE.bzlmod file can make the migration easier because:
+
+*   When Bzlmod is disabled, you fall back to fetching dependencies from the
+    original WORKSPACE file.
+*   When Bzlmod is enabled, you can better track what dependencies are left to
+    migrate with WORKSPACE.bzlmod.
+
+#### Repository visibility {#repository-visibility}
+
+Bzlmod is able to control which other repositories are visible from a given
+repository, check [repository names and strict
+deps](/versions/9.1.0/external/module#repository_names_and_strict_deps) for more details.
+
+Here is a summary of repository visibilities from different types of
+repositories when also taking WORKSPACE into consideration.
+
+| | From the main repo | From Bazel module repos | From module extension repos | From WORKSPACE repos |
+|----------------|--------------------|-------------------------|---------------------------------------------------------------------------------------------------------------------|----------------------|
+| The main repo  | Visible | If the root module is a direct dependency | If the root module is a direct dependency of the module hosting the module extension | Visible              |
+| Bazel module repos | Direct deps | Direct deps | Direct deps of the module hosting the module extension | Direct deps of the root module |
+| Module extension repos | Direct deps | Direct deps | Direct deps of the module hosting the module extension + all repos generated by the same module extension | Direct deps of the root module |
+| WORKSPACE Repos | All visible | Not visible | Not visible | All visible |
+
+Note: For the root module, if a repository `@foo` is defined in WORKSPACE and
+`@foo` is also used as an [apparent repository
+name](/versions/9.1.0/external/overview#apparent-repo-name) in MODULE.bazel, then `@foo`
+refers to the one introduced in MODULE.bazel.
+
+Note: For a module extension generated repository `@bar`, if `@foo` is used as
+an [apparent repository name](/versions/9.1.0/external/overview#apparent-repo-name) of
+another repository generated by the same module extension and direct
+dependencies of the module hosting the module extension, then for repository
+`@bar`, `@foo` refers to the latter.
+
+### Manual migration process {#manual-migration-process}
+
+A typical Bzlmod migration process can look like this:
+
+1.  Understand what dependencies you have in WORKSPACE.
+1.  Add an empty MODULE.bazel file at your project root.
+1.  Add an empty WORKSPACE.bzlmod file to override the WORKSPACE file content.
+1.  Build your targets with Bzlmod enabled and check which repository is
+    missing.
+1.  Check the definition of the missing repository in the resolved dependency
+    file.
+1.  Introduce the missing dependency as a Bazel module, through a module
+    extension, or leave it in the WORKSPACE.bzlmod for later migration.
+1.  Go back to 4 and repeat until all dependencies are available.
+
+## Publish Bazel modules {#publish-modules}
+
+If your Bazel project is a dependency for other projects, you can publish your
+project in the [Bazel Central Registry](https://registry.bazel.build/).
+
+To be able to check in your project in the BCR, you need a source archive URL of
+the project. Take note of a few things when creating the source archive:
+
+*   **Make sure the archive is pointing to a specific version.**
+
+    The BCR can only accept versioned source archives because Bzlmod needs to
+    conduct version comparison during dependency resolution.
+
+*   **Make sure the archive URL is stable.**
+
+    Bazel verifies the content of the archive by a hash value, so you should
+    make sure the checksum of the downloaded file never changes. If the URL is
+    from GitHub, please create and upload a release archive in the release page.
+    GitHub isn't going to guarantee the checksum of source archives generated on
+    demand. In short, URLs in the form of
+    `https://github.com///releases/download/...` is considered stable
+    while `https://github.com///archive/...` is not. Check [GitHub
+    Archive Checksum
+    Outage](https://blog.bazel.build/2023/02/15/github-archive-checksum.html)
+    for more context.
+
+*   **Make sure the source tree follows the layout of the original repository.**
+
+    In case your repository is very large and you want to create a distribution
+    archive with reduced size by stripping out unnecessary sources, please make
+    sure the stripped source tree is a subset of the original source tree. This
+    makes it easier for end users to override the module to a non-release
+    version by [`archive_override`](/versions/9.1.0/rules/lib/globals/module#archive_override)
+    and [`git_override`](/versions/9.1.0/rules/lib/globals/module#git_override).
+
+*   **Include a test module in a subdirectory that tests your most common
+    APIs.**
+
+    A test module is a Bazel project with its own WORKSPACE and MODULE.bazel
+    file located in a subdirectory of the source archive which depends on the
+    actual module to be published. It should contain examples or some
+    integration tests that cover your most common APIs. Check
+    [test module][test_module] to learn how to set it up.
+
+[test_module]: https://github.com/bazelbuild/bazel-central-registry/tree/main/docs#test-module
+
+When you have your source archive URL ready, follow the [BCR contribution
+guidelines][bcr_contrib_guide] to submit your module to the BCR with a GitHub
+Pull Request.
+
+[bcr_contrib_guide]: https://github.com/bazelbuild/bazel-central-registry/tree/main/docs#contribute-a-bazel-module
+
+It is **highly recommended** to set up the [Publish to
+BCR](https://github.com/bazel-contrib/publish-to-bcr) GitHub App for your
+repository to automate the process of submitting your module to the BCR.
+
+## Best practices {#best-practices}
+
+This section documents a few best practices you should follow for better
+managing your external dependencies.
+
+#### Split targets into different packages to avoid fetching unnecessary dependencies.
+
+Check [#12835](https://github.com/bazelbuild/bazel/issues/12835), where dev
+dependencies for tests are forced to be fetched unnecessarily for building
+targets that don't need them. This is actually not Bzlmod specific, but
+following this practices makes it easier to specify dev dependencies correctly.
+
+#### Specify dev dependencies
+
+You can set the `dev_dependency` attribute to true for
+[`bazel_dep`](/versions/9.1.0/rules/lib/globals/module#bazel_dep) and
+[`use_extension`](/versions/9.1.0/rules/lib/globals/module#use_extension) directives so that
+they don't propagate to dependent projects. As the root module, you can use the
+[`--ignore_dev_dependency`][ignore_dev_dep_flag] flag to verify if your targets
+still build without dev dependencies and overrides.
+
+[ignore_dev_dep_flag]: /reference/command-line-reference#flag--ignore_dev_dependency
+
+
+
+## Community migration progress {#migration-progress}
+
+You can check the [Bazel Central Registry](https://registry.bazel.build) to find
+out if your dependencies are already available. Otherwise feel free to join this
+[GitHub discussion](https://github.com/bazelbuild/bazel/discussions/18329) to
+upvote or post the dependencies that are blocking your migration.
+
+## Report issues {#reporting-issues}
+
+Please check the [Bazel GitHub issue list][bzlmod_github_issue] for known Bzlmod
+issues. Feel free to file new issues or feature requests that can help unblock
+your migration!
+
+[bzlmod_github_issue]: https://github.com/bazelbuild/bazel/issues?q=is%3Aopen+is%3Aissue+label%3Aarea-Bzlmod
diff --git a/versions/9.1.0/external/migration_tool.mdx b/versions/9.1.0/external/migration_tool.mdx
new file mode 100644
index 00000000..4203cc36
--- /dev/null
+++ b/versions/9.1.0/external/migration_tool.mdx
@@ -0,0 +1,728 @@
+keywords: bzlmod
+
+{# disableFinding(LINE_OVER_80_LINK) #}
+{# disableFinding(SNIPPET_NO_LANG) #}
+{# disableFinding(LINK_MISSING_ID) #}
+{# disableFinding("repo") #}
+
+---
+title: 'Bzlmod Migration Tool'
+---
+
+[migration_script]: https://github.com/bazelbuild/bazel-central-registry/blob/main/tools/migrate_to_bzlmod.py
+[gemini_cli_setup]: https://github.com/bazelbuild/bazel-central-registry/tree/main/tools/code-agent
+
+To simplify the often complex process of moving from `WORKSPACE` to Bzlmod, it's
+highly recommended to use the [migration script][migration_script]. This helper
+tool automates many of the steps involved in migrating your external dependency
+management system.
+
+**Note**: If you want to try out the AI driven Bzlmod migration, check [Bzlmod Migration Agent Setup][gemini_cli_setup].
+
+## Core Functionality {:#migration-tool-core-functionality}
+
+The script's primary functions are:
+
+*   **Collecting dependency information:** Analyzing your project's `WORKSPACE`
+    file to identify external repositories used by specified build targets,
+    using Bazel's
+    [experimental_repository_resolved_file](https://bazel.build/versions/9.1.0/versions/8.2.0/reference/command-line-reference#flag--experimental_repository_resolved_file)
+    flag to generate a resolved dependencies file containing this information.
+*   **Identifying direct dependencies:** Using `bazel query` to determine which
+    repositories are direct dependencies for the specified targets.
+*   **Migrating to Bzlmod:** Translating relevant `WORKSPACE` dependencies into
+    their Bzlmod equivalents. This is a two-step process:
+    1.  Introduce all identified direct dependencies to the
+        `MODULE.bazel` file.
+    2.  Build specified targets with Bzlmod enabled, then
+        iteratively identify and fix recognizable errors. This step is
+        needed since some dependencies might be missing in the first step.
+*   **Generating a migration report:** Creating a `migration_info.md` file that
+    documents the migration process. This report includes a list of direct
+    dependencies, the generated Bzlmod declarations, and any manual steps that
+    may be required to complete the migration.
+
+The migration tool supports:
+
+*   Dependencies available in the Bazel Central Registry
+*   User-defined custom repository rules
+*   Package manager dependencies
+    *   Maven
+    *   Go
+    *   Python
+
+**Important Notes**:
+
+* The migration tool is a best-effort utility. Always double-check its
+recommendations for correctness.
+* Use the migration tool with Bazel 7 (not supported with Bazel 8).
+
+## How to Use the Migration Tool {:#migration-tool-how-to-use}
+
+Before you begin:
+
+*   Upgrade to the latest Bazel 7 release, which provides robust support for
+    both WORKSPACE and Bzlmod.
+*   Verify the following command runs successfully for your project's main build
+    targets:
+
+    ```shell
+    bazel build --nobuild --enable_workspace --noenable_bzlmod 
+    ```
+
+### Command for running the script {:#migration-script-command}
+
+Once the prerequisites are met, run the following commands to use the migration
+tool:
+
+
+# Clone the Bazel Central Registry repository
+git clone https://github.com/bazelbuild/bazel-central-registry.git
+cd bazel-central-registry
+
+# Build the migration tool
+bazel build //tools:migrate_to_bzlmod
+
+# Create a convenient alias for the tool
+alias migrate2bzlmod=$(realpath ./bazel-bin/tools/migrate_to_bzlmod)
+
+# Navigate to your project's root directory and run the tool
+cd <your project root>
+migrate2bzlmod -t <targets>
+

+
+### Files generated by this script {:#migration-script-files}
+
+*   `MODULE.bazel` - The central manifest file for Bzlmod, which declares the
+    project's metadata and its direct dependencies on other Bazel modules.
+*   `migration_info.md` - A file providing step-by-step instructions on how the
+    migration tool was executed, designed to assist in the manual completion of
+    the migration process, if necessary.
+*   `resolved_deps.py` - Contains a comprehensive list of the project's external
+    dependencies, generated by analyzing the project's `WORKSPACE` file, serving
+    as a reference during the transition.
+*   `query_direct_deps` - Contains migration-relevant information regarding the
+    utilized targets, obtained by invoking Bazel with `--output=build` on the
+    project's `WORKSPACE` file. This file is primarily consumed by the migration
+    script.
+*   `extension_for_XXX` - A file containing a module extension
+    definition. The migration tool generates these files for dependencies that
+    are not standard Bazel modules but can be managed using Bzlmod's [module
+    extensions](/versions/9.1.0/external/extension).
+
+### Flags {:#migration-script-flags}
+
+Flags available in this migration scripts are:
+
+*   `--t`/`--target`: Targets to migrate. This flag is repeatable, and the
+    targets are accumulated.
+*   `--i`/`--initial`: Deletes `MODULE.bazel`, `resolved_deps.py`,
+    `migration_info.md` files and starts from scratch - Detect direct
+    dependencies, introduce them in MODULE.bazel and rerun generation of
+    resolved dependencies.
+
+### Post-migration cleanup {:#post-migration-cleanup}
+
+*   Delete `migration_info.md`, `resolved_deps.py` and `query_direct_deps`.
+*   Clean up comments from `MODULE.bazel` file which were used for the
+    migration, such as `# -- bazel_dep definitions -- #`.
+
+## Migration Example {:#migration-tool-example}
+
+To see the migration script in action, consider the following scenario when
+Python, Maven and Go dependencies are declared in `WORKSPACE` file.
+
+

+  
+Click here to see `WORKSPACE` file
+  
+
+```python
+workspace(name="example")
+
+load("@bazel_tools//tools/build_defs/repo:http.bzl", "http_archive")
+load(":my_custom_macro.bzl", "my_custom_macro")
+
+http_archive(
+    name = "rules_cc",
+    sha256 = "b8b918a85f9144c01f6cfe0f45e4f2838c7413961a8ff23bc0c6cdf8bb07a3b6",
+    strip_prefix = "rules_cc-0.1.5",
+    urls = ["https://github.com/bazelbuild/rules_cc/releases/download/0.1.5/rules_cc-0.1.5.tar.gz"],
+)
+
+# Module dependency
+# -------------------
+http_archive(
+    name = "rules_shell",
+    sha256 = "3e114424a5c7e4fd43e0133cc6ecdfe54e45ae8affa14fadd839f29901424043",
+    strip_prefix = "rules_shell-0.4.0",
+    url = "https://github.com/bazelbuild/rules_shell/releases/download/v0.4.0/rules_shell-v0.4.0.tar.gz",
+)
+
+# Repo rule
+# -------------------
+http_archive(
+    name = "com_github_cockroachdb_cockroach",
+    sha256 = "6c3568ef244ce6b874694eeeecb83ed4f5d5dff6cf037c952ecde76828a6c502",
+    strip_prefix = "cockroach-22.1.6",
+    url = "https://github.com/cockroachdb/cockroach/archive/v22.1.6.tar.gz",
+)
+
+# Module extension
+# -------------------
+# Macro which invokes repository_rule
+my_custom_macro(
+    name = "my_custom_repo",
+)
+
+# Go dependencies
+# -------------------
+http_archive(
+    name = "io_bazel_rules_go",
+    integrity = "sha256-M6zErg9wUC20uJPJ/B3Xqb+ZjCPn/yxFF3QdQEmpdvg=",
+    urls = [
+        "https://mirror.bazel.build/github.com/bazelbuild/rules_go/releases/download/v0.48.0/rules_go-v0.48.0.zip",
+        "https://github.com/bazelbuild/rules_go/releases/download/v0.48.0/rules_go-v0.48.0.zip",
+    ],
+)
+
+http_archive(
+    name = "bazel_gazelle",
+    integrity = "sha256-12v3pg/YsFBEQJDfooN6Tq+YKeEWVhjuNdzspcvfWNU=",
+    urls = [
+        "https://mirror.bazel.build/github.com/bazelbuild/bazel-gazelle/releases/download/v0.37.0/bazel-gazelle-v0.37.0.tar.gz",
+        "https://github.com/bazelbuild/bazel-gazelle/releases/download/v0.37.0/bazel-gazelle-v0.37.0.tar.gz",
+    ],
+)
+
+load("@io_bazel_rules_go//go:deps.bzl", "go_register_toolchains", "go_rules_dependencies")
+load("@bazel_gazelle//:deps.bzl", "gazelle_dependencies", "go_repository")
+
+go_rules_dependencies()
+go_register_toolchains(version = "1.23.1")
+gazelle_dependencies()
+
+go_repository(
+    name = "org_golang_x_net",
+    importpath = "golang.org/x/net",
+    sum = "h1:oWX7TPOiFAMXLq8o0ikBYfCJVlRHBcsciT5bXOrH628=",
+    version = "v0.0.0-20190311183353-d8887717615a",
+    build_file_proto_mode = "disable",
+    build_naming_convention = "import",
+)
+
+# Python dependencies
+# -------------------
+http_archive(
+    name = "rules_python",
+    integrity = "sha256-qDdnnxOC8mlowe5vg5x9r5B5qlMSgGmh8oFd7KpjcwQ=",
+    strip_prefix = "rules_python-1.4.0",
+    url = "https://github.com/bazelbuild/rules_python/releases/download/1.4.0/rules_python-1.4.0.tar.gz",
+)
+
+load("@rules_python//python:repositories.bzl", "py_repositories")
+py_repositories()
+
+load("@rules_python//python:pip.bzl", "pip_parse")
+pip_parse(
+   name = "my_python_deps",
+   requirements_lock = "@example//:requirements_lock.txt",
+)
+
+load("@my_python_deps//:requirements.bzl", "install_deps")
+install_deps()
+
+load("@rules_python//python:repositories.bzl", "python_register_toolchains")
+python_register_toolchains(
+    name = "python_3_11",
+    python_version = "3.11",
+)
+
+# Maven dependencies
+# __________________
+
+RULES_JVM_EXTERNAL_TAG = "4.5"
+RULES_JVM_EXTERNAL_SHA = "b17d7388feb9bfa7f2fa09031b32707df529f26c91ab9e5d909eb1676badd9a6"
+
+http_archive(
+    name = "rules_jvm_external",
+    strip_prefix = "rules_jvm_external-%s" % RULES_JVM_EXTERNAL_TAG,
+    sha256 = RULES_JVM_EXTERNAL_SHA,
+    url = "https://github.com/bazelbuild/rules_jvm_external/archive/%s.zip" % RULES_JVM_EXTERNAL_TAG,
+)
+
+load("@rules_jvm_external//:repositories.bzl", "rules_jvm_external_deps")
+rules_jvm_external_deps()
+load("@rules_jvm_external//:setup.bzl", "rules_jvm_external_setup")
+rules_jvm_external_setup()
+
+load("@rules_jvm_external//:defs.bzl", "maven_install")
+maven_install(
+    name = "px_deps",
+    artifacts = [
+        "org.antlr:antlr4:4.11.1",
+    ],
+    repositories = [
+        "https://repo1.maven.org/maven2",
+    ],
+)
+```
+

+
+Moreover, to demonstrate usage of module extension, custom macro is invoked from
+`WORKSPACE` and it is defined in `my_custom_macro.bzl`.
+
+

+  
+Click here to see `my_custom_macro.bzl` file
+  
+
+```python
+"""Repo rule and macro used for testing"""
+
+def _test_repo_rule_impl(repository_ctx):
+    repository_ctx.file(
+        "BUILD",
+        content = """
+genrule(
+    name = "foo",
+    outs = ["rule_name.out"],
+    cmd = "touch $@",
+    visibility = ["//visibility:public"],
+)
+"""
+    )
+
+_test_repo_rule = repository_rule(
+    implementation = _test_repo_rule_impl,
+)
+
+def my_custom_macro(name):
+    _test_repo_rule(name = name)
+```
+

+
+The end goal is to have `MODULE.bazel` file and delete the `WORKSPACE` file,
+without impacting the user experience.
+
+The first step is to follow [How to Use the Migration
+Tool](#migration-tool-how-to-use), which mostly is checking the bazel version
+(it must be Bazel 7) and adding an alias to the migration script.
+
+Then, running `migrate2bzlmod -t=//...` outputs:
+
+
+  bazel 7.6.1
+
+  Generating ./resolved_deps.py file - It might take a while...
+
+  RESOLVED: rules_java has been introduced as a Bazel module.
+  RESOLVED: bazel_gazelle has been introduced as a Bazel module.
+  RESOLVED: io_bazel_rules_go has been introduced as a Bazel module.
+  RESOLVED: rules_python has been introduced as a Bazel module.
+  IMPORTANT: 3.11 is used as a default python version. If you need a different version, please change it manually and then rerun the migration tool.
+  RESOLVED: my_python_deps has been introduced as python extension.
+  RESOLVED: org_golang_x_net has been introduced as go extension.
+  RESOLVED: rules_jvm_external has been introduced as a Bazel module.
+  RESOLVED: org.antlr has been introduced as maven extension.
+  RESOLVED: rules_shell has been introduced as a Bazel module.
+
+  Congratulations! All external repositories needed for building //... are available with Bzlmod!
+  IMPORTANT: Fix potential build time issues by running the following command:
+      bazel build --enable_bzlmod --noenable_workspace //...
+
+  IMPORTANT: For details about the migration process, check `migration_info.md` file.
+

+
+which gives the following important information:
+
+*   Generates `./resolved_deps.py` file, which contains info about all external
+    repositories declared and loaded using your `WORKSPACE` file.
+*   `RESOLVED` keyword describes all dependencies which are resolved by the tool
+    and added to the `MODULE.bazel` file.
+*   `IMPORTANT` keyword describes significant information worth investing time.
+*   All dependencies have been resolved in this example, at least with
+    `--nobuild` flag.
+*   It is important to run the full build (command specified) and manually fix
+    potential errors (e.g. toolchain not registered correctly).
+*   `migration_info.md` file contains details about the migration. Check details
+    [at this section](#migration-tool-report-generation).
+
+### Transformations {:#migration-tool-transformations}
+
+This section illustrates the migration of code from the `WORKSPACE` file to
+`MODULE.bazel`.
+
+

+  

+    
WORKSPACE - Bazel Module

+    
+http_archive(
+    name = "rules_shell",
+    sha256 = "3e114424a5c7e4fd43e0133cc6ecdfe54e45ae8affa14fadd839f29901424043",
+    strip_prefix = "rules_shell-0.4.0",
+    url = "https://github.com/bazelbuild/rules_shell/releases/download/v0.4.0/rules_shell-v0.4.0.tar.gz",
+)
+

+  

+  

+    
MODULE.bazel - Bazel Module

+    
+bazel_dep(name = "rules_shell", version = "0.6.1")
+

+  

+

+
+

+
+

+  

+    
WORKSPACE - Go Extension

+    
+http_archive(
+    name = "io_bazel_rules_go",
+    integrity = "sha256-M6zErg9wUC20uJPJ/B3Xqb+ZjCPn/yxFF3QdQEmpdvg=",
+    urls = [
+        "https://mirror.bazel.build/github.com/bazelbuild/rules_go/releases/download/v0.48.0/rules_go-v0.48.0.zip",
+        "https://github.com/bazelbuild/rules_go/releases/download/v0.48.0/rules_go-v0.48.0.zip",
+    ],
+)
+http_archive(
+    name = "bazel_gazelle",
+    integrity = "sha256-12v3pg/YsFBEQJDfooN6Tq+YKeEWVhjuNdzspcvfWNU=",
+    urls = [
+        "https://mirror.bazel.build/github.com/bazelbuild/bazel-gazelle/releases/download/v0.37.0/bazel-gazelle-v0.37.0.tar.gz",
+        "https://github.com/bazelbuild/bazel-gazelle/releases/download/v0.37.0/bazel-gazelle-v0.37.0.tar.gz",
+    ],
+)
+
+load("@io_bazel_rules_go//go:deps.bzl", "go_register_toolchains", "go_rules_dependencies")
+load("@bazel_gazelle//:deps.bzl", "gazelle_dependencies", "go_repository")
+
+go_rules_dependencies()
+go_register_toolchains(version = "1.23.1")
+gazelle_dependencies()
+
+go_repository(
+    name = "org_golang_x_net",
+    importpath = "golang.org/x/net",
+    sum = "h1:oWX7TPOiFAMXLq8o0ikBYfCJVlRHBcsciT5bXOrH628=",
+    version = "v0.0.0-20190311183353-d8887717615a",
+    build_file_proto_mode = "disable",
+    build_naming_convention = "import",
+)
+

+  

+  

+    
MODULE.bazel - Go Extension

+    
+go_deps = use_extension("@bazel_gazelle//:extensions.bzl", "go_deps")
+go_sdk = use_extension("@io_bazel_rules_go//go:extensions.bzl", "go_sdk")
+
+go_deps.from_file(go_mod = "//:go.mod")
+use_repo(go_deps, "org_golang_x_net")
+go_sdk.from_file(go_mod = "//:go.mod")
+
+go_deps.gazelle_override(
+    path = "golang.org/x/net",
+    directives = [
+        "gazelle:proto disable",
+         "gazelle:go_naming_convention import",
+    ],
+)
+

+  

+

+
+

+
+

+  

+    
WORKSPACE - Python Extension

+    
+http_archive(
+    name = "rules_python",
+    integrity = "sha256-qDdnnxOC8mlowe5vg5x9r5B5qlMSgGmh8oFd7KpjcwQ=",
+    strip_prefix = "rules_python-1.4.0",
+    url = "https://github.com/bazelbuild/rules_python/releases/download/1.4.0/rules_python-1.4.0.tar.gz",
+)
+
+load("@rules_python//python:repositories.bzl", "py_repositories")
+py_repositories()
+
+load("@rules_python//python:pip.bzl", "pip_parse")
+pip_parse(
+   name = "my_python_deps",
+   requirements_lock = "@example//:requirements_lock.txt",
+)
+
+load("@my_python_deps//:requirements.bzl", "install_deps")
+install_deps()
+
+load("@rules_python//python:repositories.bzl", "python_register_toolchains")
+python_register_toolchains(
+    name = "python_3_11",
+    python_version = "3.11",
+)
+

+  

+  

+    
MODULE.bazel - Python Extension

+    
+pip = use_extension("@rules_python//python/extensions:pip.bzl", "pip")
+pip.parse(
+    hub_name = "my_python_deps",
+    python_version = "3.11",
+    requirements_lock = "//:requirements_lock.txt",
+)
+use_repo(pip, "my_python_deps")
+
+python = use_extension("@rules_python//python/extensions:python.bzl", "python")
+python.defaults(python_version = "3.11")
+python.toolchain(python_version = "3.11")
+

+  

+

+
+

+
+

+  

+    
WORKSPACE - Maven Extension

+    
+
+RULES_JVM_EXTERNAL_TAG = "4.5"
+RULES_JVM_EXTERNAL_SHA = "b17d7388feb9bfa7f2fa09031b32707df529f26c91ab9e5d909eb1676badd9a6"
+
+http_archive(
+    name = "rules_jvm_external",
+    strip_prefix = "rules_jvm_external-%s" % RULES_JVM_EXTERNAL_TAG,
+    sha256 = RULES_JVM_EXTERNAL_SHA,
+    url = "https://github.com/bazelbuild/rules_jvm_external/archive/%s.zip" % RULES_JVM_EXTERNAL_TAG,
+)
+
+load("@rules_jvm_external//:repositories.bzl", "rules_jvm_external_deps")
+rules_jvm_external_deps()
+load("@rules_jvm_external//:setup.bzl", "rules_jvm_external_setup")
+rules_jvm_external_setup()
+
+load("@rules_jvm_external//:defs.bzl", "maven_install")
+maven_install(
+    name = "px_deps",
+    artifacts = [
+        "org.antlr:antlr4:4.11.1",
+    ],
+    repositories = [
+        "https://repo1.maven.org/maven2",
+    ],
+)
+

+  

+  

+    
MODULE.bazel - Maven Extension

+    
+bazel_dep(name = "rules_jvm_external", version = "6.8")
+
+maven = use_extension("@rules_jvm_external//:extensions.bzl", "maven")
+use_repo(maven, "px_deps")
+
+maven.artifact(
+    name = "px_deps",
+    group = "org.antlr",
+    artifact = "antlr4",
+    version = "4.11.1"
+)
+

+  

+

+
+

+
+

+  

+    
WORKSPACE - Repo rule

+    
+load("@bazel_tools//tools/build_defs/repo:http.bzl", "http_archive")
+
+http_archive(
+    name = "com_github_cockroachdb_cockroach",
+    sha256 = "6c3568ef244ce6b874694eeeecb83ed4f5d5dff6cf037c952ecde76828a6c502",
+    strip_prefix = "cockroach-22.1.6",
+    url = "https://github.com/cockroachdb/cockroach/archive/v22.1.6.tar.gz",
+)
+

+  

+  

+    
MODULE.bazel - Repo rule

+    
+http_archive = use_repo_rule("@bazel_tools//tools/build_defs/repo:http.bzl", "http_archive")
+
+http_archive(
+  name = "com_github_cockroachdb_cockroach",
+  url = "https://github.com/cockroachdb/cockroach/archive/v22.1.6.tar.gz",
+  sha256 = "6c3568ef244ce6b874694eeeecb83ed4f5d5dff6cf037c952ecde76828a6c502",
+  strip_prefix = "cockroach-22.1.6",
+)
+

+  

+

+
+

+
+

+  

+    
WORKSPACE - Module extension

+    
+load(":my_custom_macro.bzl", "my_custom_macro")
+
+my_custom_macro(
+    name = "my_custom_repo",
+)
+

+  

+  

+    
MODULE.bazel - Module extension

+    
+extension_for_my_custom_macro = use_extension("//:extension_for_my_custom_macro.bzl", "extension_for_my_custom_macro")
+use_repo(extension_for_my_custom_macro, "my_custom_repo")
+

+    
extension_for_my_custom_macro.bzl

+    
+load("//:my_custom_macro.bzl", "my_custom_macro")
+
+def _extension_for_my_custom_macro_impl(ctx):
+  my_custom_macro(
+    name = "my_custom_repo",
+  )
+
+extension_for_my_custom_macro = module_extension(implementation = _extension_for_my_custom_macro_impl)
+

+  

+

+
+

+
+## Tips with debugging {:#migration-tool-tips}
+
+This section provides useful commands and information to help debug issues that
+may arise during the Bzlmod migration.
+
+### Useful tips {:#debugging-useful-tips}
+
+*   Override version - Not rarely it happens that upgrading the version of a
+    dependency causes troubles. Bzlmod could change the version of the
+    dependency due to the [MVS algorithm](/versions/9.1.0/external/module#version-selection).
+    In order to use the same or similar version as it was in the WORKSPACE,
+    override it with
+    [single_version_override](/versions/9.1.0/rules/lib/globals/module#single_version_override).
+    Note that this is useful for debugging differences between WORKSPACE and
+    Bzlmod, but you shouldn't rely on this feature in the long term.
+
+    `single_version_override(module_name = "{dep_name}", version = "{version}")`
+
+*   Use [bazel mod](/versions/9.1.0/external/mod-command#syntax) command.
+    *   Check the version of a specified repo with `show_repo`
+        command. For example:
+
+        `bazel mod show_repo @rules_python`
+
+    *   Check information about a module extension with the `show_extension`
+    command. For example:
+
+        `bazel mod show_extension @rules_python//python/extensions:pip.bzl%pip`
+
+*   Use [vendor mode](/versions/9.1.0/external/vendor) to create a local copy of a repo when
+    you want to monitor or control the source of the repo. For example:
+
+    `bazel vendor --enable_bzlmod --vendor_dir=vendor_src --repo=@protobuf`
+
+### Migration Report Generation {:#migration-tool-report-generation}
+
+This file is updated with each run of the migration script or it's generated
+from scratch if it's the first run or if the [`--i`
+flag](#migration-script-flags) is used. The report contains:
+
+*   Command for local testing.
+*   List of direct dependencies (at least the ones which are directly used in
+    the project).
+*   For each dependency, a drop-down menu for checking where the repository was
+    declared in the `WORKSPACE` file, which is particularly useful for the
+    debugging. You can see it as:
+
+    
+    > Click here to see where and how the repo was declared in the WORKSPACE
+    file
+    

+
+*   For each dependency, how it was implemented in `MODULE.bazel` file. From the
+    earlier [Migration Example](#migration-tool-example), that would look as:
+    1.  Bazel module Dependency - `Migration of rules_python`
+
+        
+        Found perfect name match in BCR: rules_python
+        Found partially name matches in BCR: rules_python_gazelle_plugin
+
+        It has been introduced as a Bazel module:
+            `bazel_dep(name = "rules_python", version = "1.6.1")`
+        

+
+      *   The script will automatically use the `perfect name match` if it finds
+      it. In case of an error, you can double check if the name was correctly
+      added.
+    2.  Python extension - `Migration of my_python_deps`
+
+        
+        pip.parse(
+            hub_name = "my_python_deps",
+            requirements_lock = "//:requirements_lock.txt",
+            python_version = "3.11",
+        )
+        use_repo(pip, "my_python_deps")
+        

+
+    3.  Maven extension - `Migration of org.antlr (px_deps):`
+
+        
+        maven.artifact(
+            name = "px_deps",
+            group = "org.antlr",
+            artifact = "antlr4",
+            version = "4.11.1"
+        )
+        

+
+    4.  Go extension - `Migration of org_golang_x_net`
+
+        
+        go_deps.from_file(go_mod = "//:go.mod")
+        go_sdk.from_file(go_mod = "//:go.mod")
+
+        go_deps.gazelle_override(
+            path = "golang.org/x/net",
+            directives = [
+                "gazelle:proto disable",
+                "gazelle:go_naming_convention import",
+            ],
+        )
+        

+
+      *   It has been introduced as a go module with the help of `go.mod`. If
+          `go.mod` and `go.sum` are not available, go module is added directly
+          to the `MODULE.bazel` file.
+      *   `gazelle_override` is used for adding specific directives.
+
+## Useful links {:#useful-links}
+
+* Official pages for the external extensions
+    *   [rules_jvm_external](https://github.com/bazelbuild/rules_jvm_external/blob/master/docs/bzlmod.md)
+    *   [rules_go](https://github.com/bazelbuild/rules_go/blob/master/docs/go/core/bzlmod.md)
+    *   [rules_python](https://rules-python.readthedocs.io/en/latest/pypi/download.html)
+* Community posts and videos
+  * [Migrating to Bazel Modules](https://blog.engflow.com/2025/01/16/migrating-to-bazel-modules-aka-bzlmod---module-extensions/index.html#migrating-to-bazel-modules-aka-bzlmod-module-extensions).
+  * [Moving to Bzlmod](https://www.youtube.com/watch?v=W9uXRYLVHUk).
+  * [How Uber Manages Go Dependencies with Bzlmod](https://www.youtube.com/watch?v=hIqzkUE_pSY).
+
+## Feedback {:#feedback}
+
+If you would like to contribute, do so by creating an Issue or PR at
+[bazel-central-registry](https://github.com/bazelbuild/bazel-central-registry).
diff --git a/versions/9.1.0/external/mod-command.mdx b/versions/9.1.0/external/mod-command.mdx
new file mode 100644
index 00000000..7af0dacc
--- /dev/null
+++ b/versions/9.1.0/external/mod-command.mdx
@@ -0,0 +1,563 @@
+keywords: Bzlmod
+
+---
+title: '`mod` Command'
+---
+
+The `mod` command provides a range of tools to help the user understand their
+external dependency graph. It lets you visualize the dependency graph, find out
+why a certain module or a version of a module is present in the graph, view the
+repo definitions backing modules, inspect usages of module extensions and repos
+they generate, among other functions.
+
+## Syntax {:#syntax}
+
+```sh
+bazel mod  [] [ [...]]
+```
+
+The available subcommands and their respective required arguments are:
+
+*   `graph`: Displays the full dependency graph of the project, starting from
+    the root module. If one or more modules are specified in `--from`, these
+    modules are shown directly under the root, and the graph is only expanded
+    starting from them (see [example](#mod-example1)).
+
+*   `deps ...`: Displays the resolved direct dependencies of each of the
+    specified modules, similarly to `graph`.
+
+*   `all_paths ...`: Displays all dependency paths from the --from modules
+    to the target modules. To simplify the output, only the first shortest path
+    is shown when multiple paths share the same suffix. For example, A -> B -> X
+    would be shown, but the longer A -> C -> B -> X would be omitted. In other
+    words, for every module Y that directly depends on the target module X, the
+    output contains only the shortest path going through Y to reach X.
+
+*   `path ...`: Has the same semantics as `all_paths`, but only display a
+    single path from one of the `--from` modules to one of the argument modules.
+
+*   `explain ...`: Shows all the places where the specified modules appear
+    in the dependency graph, along with the modules that directly depend on
+    them. The output of the `explain` command is essentially a pruned version of
+    the `all_paths` command, containing 1) the root module; 2) the root module's
+    direct dependencies that lead to the argument modules; 3) the argument
+    modules' direct dependents; and
+    4) the argument modules themselves (see [example](#mod-example5)).
+
+*   `show_repo ...`: Displays the definition of the specified repos (see
+    [example](#mod-example6)).
+
+*   `show_extension ...`: Displays information about each of the
+    specified extensions: a list of the generated repos along with the modules
+    that import them using `use_repo`, and a list of the usages of that
+    extension in each of the modules where it is used, containing the specified
+    tags and the `use_repo` calls (see [example](#mod-example8)).
+
+`` refers to one or more modules or repos. It can be one of:
+
+*   The literal string ``: The root module representing your current
+    project.
+
+*   `@`: The module `` at version ``. For a module
+    with a non-registry override, use an underscore (`_`) as the ``.
+
+*   ``: All present versions of the module ``.
+
+*   `@`: The repo with the given [apparent
+    name](/versions/9.1.0/external/overview#apparent-repo-name) in the context of the `--base_module`.
+
+*   `@@`: The repo with the given [canonical
+    name](/versions/9.1.0/external/overview#canonical-repo-name).
+
+In a context requiring specifying modules, ``s referring to repos that
+correspond to modules (as opposed to extension-generated repos) can also be
+used. Conversely, in a context requiring specifying repos, ``s referring to
+modules can stand in for the corresponding repos.
+
+`` must be of the form `%`.
+The `` part must be a repo-relative label (for example,
+`//pkg/path:file.bzl`).
+
+### Graph command options
+
+The following options only affect the subcommands that print graphs (`graph`,
+`deps`, `all_paths`, `path`, and `explain`):
+
+*   `--from [,[,...]]` *default: ``*: The module(s) from which
+    the graph is expanded in `graph`, `all_paths`, `path`, and `explain`. Check
+    the subcommands' descriptions for more details.
+
+*   `--verbose` *default: "false"*: Include in the output graph extra
+    information about the version resolution of each module. If the module
+    version changed during resolution, show either which version replaced it or
+    what was the original version, the reason it was replaced, and which modules
+    requested the new version if the reason was [Minimal Version
+    Selection](/versions/9.1.0/external/module#version-selection).
+
+*   `--include_unused` *default: "false"*: Include in the output graph the
+    modules which were originally present in the dependency graph, but became
+    unused after module resolution.
+
+*   `--extension_info `: Include information about the module extension
+    usages as part of the output graph (see [example](#mod-example7)). ``
+    can be one of:
+
+    *   `hidden` *(default)*: Don't show anything about extensions.
+
+    *   `usages`: Show extensions under each module where they are used. They
+        are printed in the form of `$`.
+
+    *   `repos`: In addition to `usages`, show the repo imported using
+        `use_repo` under each extension usage.
+
+    *   `all`: In addition to `usages` and `repos`, also show
+        extension-generated repos that are not imported by any module. These
+        extra repos are shown under the first occurrence of their generating
+        extension in the output, and are connected with a dotted edge.
+
+*   `--extension_filter [,[,...]]`: If specified, the
+    output graph only includes modules that use the specified extensions, and
+    the paths that lead to those modules. Specifying an empty extension list (as
+    in `--extension_filter=`) is equivalent to specifying _all_ extensions used
+    by any module in the dependency graph.
+
+*   `--depth `: The depth of the output graph. A depth of 1 only displays the
+    root and its direct dependencies. Defaults to 1 for `explain`, 2 for `deps`
+    and infinity for the others.
+
+*   `--cycles` *default: "false"*: Include cycle edges in the output graph.
+
+*   `--include_builtin` *default: "false"*: Include built-in modules (such as
+    `@bazel_tools`) in the output graph. This flag is disabled by default, as
+    built-in modules are implicitly depended on by every other module, which
+    greatly clutters the output.
+
+*   `--charset ` *default: utf8*: Specify the charset to use for text
+    output. Valid values are `"utf8"` and `"ascii"`. The only significant
+    difference is in the special characters used to draw the graph in the
+    `"text"` output format, which don't exist in the `"ascii"` charset.
+    Therefore, the `"ascii"` charset is present to also support the usage on
+    legacy platforms which cannot use Unicode.
+
+*   `--output `: Include information about the module extension usages as
+    part of the output graph. `' can be one of:
+
+    *   `text` *(default)*: A human-readable representation of the output graph
+        (flattened as a tree).
+
+    *   `json`: Outputs the graph in the form of a JSON object (flattened as a
+        tree).
+
+    *   `graph`: Outputs the graph in the Graphviz *dot* representation.
+
+    Tip: Use the following command to pipe the output through the *dot* engine
+        and export the graph representation as an SVG image.
+
+    ```sh
+    bazel mod graph --output graph | dot -Tsvg > /tmp/graph.svg
+    ```
+
+    ### show_repo options
+`show_repo` supports a different set of output formats:
+*   `--output `: Change how repository definitions are displayed.
+    `` can be one of:
+    *   `text` *(default)*: Display repo definitions in Starlark.
+    *   `streamed_proto`: Prints a
+        [length-delimited](https://protobuf.dev/programming-guides/encoding/#size-limit)
+        stream of
+        [`Repository`](https://github.com/bazelbuild/bazel/blob/master/src/main/protobuf/build.proto)
+        protocol buffers.
+    *   `streamed_jsonproto`: Similar to `--output streamed_proto`, prints a
+        stream of [`Repository`](https://github.com/bazelbuild/bazel/blob/master/src/main/protobuf/build.proto)
+        protocol buffers but in [NDJSON](https://github.com/ndjson/ndjson-spec) format.
+
+        ### Other options
+
+Other options include:
+
+*   `--base_module ` *default: ``*: Specify a module relative to
+    which apparent repo names in arguments are interpreted. Note that this
+    argument itself can be in the form of `@`; this is always
+    interpreted relative to the root module.
+
+*   `--extension_usages [,[,...]]`: Filters `show_extension` to only
+    display extension usages from the specified modules.
+
+## Examples {:#examples}
+
+Some possible usages of the `mod` command on a real Bazel project are showcased
+below to give you a general idea on how you can use it to inspect your project's
+external dependencies.
+
+`MODULE.bazel` file:
+
+```python
+module(
+  name = "my_project",
+  version = "1.0",
+)
+
+bazel_dep(name = "bazel_skylib", version = "1.1.1", repo_name = "skylib1")
+bazel_dep(name = "bazel_skylib", version = "1.2.0", repo_name = "skylib2")
+multiple_version_override(module_name = "bazel_skylib", versions = ["1.1.1", "1.2.0"])
+
+bazel_dep(name = "stardoc", version = "0.5.0")
+bazel_dep(name = "rules_java", version = "5.0.0")
+
+toolchains = use_extension("@rules_java//java:extensions.bzl", "toolchains")
+use_repo(toolchains, my_jdk="remotejdk17_linux")
+```
+
+
+  
+    
+    
+  
+

+      

+        Graph Before Resolution
+        
Graph Before Resolution

+      

+
+    		
+      

+        Graph After Resolution
+       
Graph After Resolution

+      

+
+    

+
+1.  Display the whole dependency graph of your
+    project.
+
+    ```sh
+    bazel mod graph
+    ```
+
+    ```none
+     (my_project@1.0)
+    ├───bazel_skylib@1.1.1
+    │   └───platforms@0.0.4
+    ├───bazel_skylib@1.2.0
+    │   └───platforms@0.0.4 ...
+    ├───rules_java@5.0.0
+    │   ├───platforms@0.0.4 ...
+    │   ├───rules_cc@0.0.1
+    │   │   ├───bazel_skylib@1.1.1 ...
+    │   │   └───platforms@0.0.4 ...
+    │   └───rules_proto@4.0.0
+    │       ├───bazel_skylib@1.1.1 ...
+    │       └───rules_cc@0.0.1 ...
+    └───stardoc@0.5.0
+        ├───bazel_skylib@1.1.1 ...
+        └───rules_java@5.0.0 ...
+    ```
+
+    Note: The `...` symbol indicates that the node has already been expanded
+    somewhere else and was not expanded again to reduce noise.
+
+2.  Display the whole dependency graph (including
+    unused modules and with extra information about version resolution).
+
+    ```sh
+    bazel mod graph --include_unused --verbose
+    ```
+
+    ```none
+     (my_project@1.0)
+    ├───bazel_skylib@1.1.1
+    │   └───platforms@0.0.4
+    ├───bazel_skylib@1.2.0
+    │   └───platforms@0.0.4 ...
+    ├───rules_java@5.0.0
+    │   ├───platforms@0.0.4 ...
+    │   ├───rules_cc@0.0.1
+    │   │   ├───bazel_skylib@1.0.3 ... (to 1.1.1, cause multiple_version_override)
+    │   │   ├───bazel_skylib@1.1.1 ... (was 1.0.3, cause multiple_version_override)
+    │   │   └───platforms@0.0.4 ...
+    │   └───rules_proto@4.0.0
+    │       ├───bazel_skylib@1.0.3 ... (to 1.1.1, cause multiple_version_override)
+    │       ├───bazel_skylib@1.1.1 ... (was 1.0.3, cause multiple_version_override)
+    │       └───rules_cc@0.0.1 ...
+    └───stardoc@0.5.0
+        ├───bazel_skylib@1.1.1 ... (was 1.0.3, cause multiple_version_override)
+        ├───rules_java@5.0.0 ... (was 4.0.0, cause , bazel_tools@_)
+        ├───bazel_skylib@1.0.3 (to 1.1.1, cause multiple_version_override)
+        │   └───platforms@0.0.4 ...
+        └───rules_java@4.0.0 (to 5.0.0, cause , bazel_tools@_)
+            ├───bazel_skylib@1.0.3 ... (to 1.1.1, cause multiple_version_override)
+            └───bazel_skylib@1.1.1 ... (was 1.0.3, cause multiple_version_override)
+    ```
+
+3.  Display the dependency graph expanded from
+    some specific modules.
+
+    ```sh
+    bazel mod graph --from rules_java --include_unused
+    ```
+
+    ```none
+     (my_project@1.0)
+    ├───rules_java@5.0.0
+    │   ├───platforms@0.0.4
+    │   ├───rules_cc@0.0.1
+    │   │   ├───bazel_skylib@1.0.3 ... (unused)
+    │   │   ├───bazel_skylib@1.1.1 ...
+    │   │   └───platforms@0.0.4 ...
+    │   └───rules_proto@4.0.0
+    │       ├───bazel_skylib@1.0.3 ... (unused)
+    │       ├───bazel_skylib@1.1.1 ...
+    │       └───rules_cc@0.0.1 ...
+    └╌╌rules_java@4.0.0 (unused)
+        ├───bazel_skylib@1.0.3 (unused)
+        │   └───platforms@0.0.4 ...
+        └───bazel_skylib@1.1.1
+            └───platforms@0.0.4 ...
+    ```
+
+    Note: The dotted line is used to indicate an *indirect* (transitive)
+    dependency edge between two nodes.
+
+4.  Display all paths between two of your
+    modules.
+
+    ```sh
+    bazel mod all_paths bazel_skylib@1.1.1 --from rules_proto
+    ```
+
+    ```none
+     (my_project@1.0)
+    └╌╌rules_proto@4.0.0
+        ├───bazel_skylib@1.1.1
+        └───rules_cc@0.0.1
+            └───bazel_skylib@1.1.1 ...
+    ```
+
+5.  See why and how your project depends on some
+    module(s).
+
+    ```sh
+    bazel mod explain @skylib1 --verbose --include_unused
+    ```
+
+    ```none
+     (my_project@1.0)
+    ├───bazel_skylib@1.1.1
+    ├───rules_java@5.0.0
+    │   ├───rules_cc@0.0.1
+    │   │   └───bazel_skylib@1.1.1 ... (was 1.0.3, cause multiple_version_override)
+    │   └───rules_proto@4.0.0
+    │       ├───bazel_skylib@1.1.1 ... (was 1.0.3, cause multiple_version_override)
+    │       └───rules_cc@0.0.1 ...
+    └───stardoc@0.5.0
+        ├───bazel_skylib@1.1.1 ... (was 1.0.3, cause multiple_version_override)
+        ├╌╌rules_cc@0.0.1
+        │   └───bazel_skylib@1.1.1 ... (was 1.0.3, cause multiple_version_override)
+        └╌╌rules_proto@4.0.0
+            ├───bazel_skylib@1.1.1 ... (was 1.0.3, cause multiple_version_override)
+            └───rules_cc@0.0.1 ...
+    ```
+
+6.  See the underlying rule of some your modules'
+    repos.
+
+    ```sh
+    bazel mod show_repo rules_cc stardoc
+    ```
+
+    ```none
+    ## rules_cc@0.0.1:
+    # 
+    http_archive(
+      name = "rules_cc+",
+      urls = ["https://bcr.bazel.build/test-mirror/github.com/bazelbuild/rules_cc/releases/download/0.0.1/rules_cc-0.0.1.tar.gz", "https://github.com/bazelbuild/rules_cc/releases/download/0.0.1/rules_cc-0.0.1.tar.gz"],
+      integrity = "sha256-Tcy/0iwN7xZMj0dFi9UODHFI89kgAs20WcKpamhJgkE=",
+      strip_prefix = "",
+      remote_patches = {"https://bcr.bazel.build/modules/rules_cc/0.0.1/patches/add_module_extension.patch": "sha256-g3+zmGs0YT2HKOVevZpN0Jet89Ylw90Cp9XsIAY8QqU="},
+      remote_patch_strip = 1,
+    )
+    # Rule http_archive defined at (most recent call last):
+    #   /home/user/.cache/bazel/_bazel_user/6e893e0f5a92cc4cf5909a6e4b2770f9/external/bazel_tools/tools/build_defs/repo/http.bzl:355:31 in 
+
+    ## stardoc:
+    # 
+    http_archive(
+      name = "stardoc+",
+      urls = ["https://bcr.bazel.build/test-mirror/github.com/bazelbuild/stardoc/releases/download/0.5.0/stardoc-0.5.0.tar.gz", "https://github.com/bazelbuild/stardoc/releases/download/0.5.0/stardoc-0.5.0.tar.gz"],
+      integrity = "sha256-yXlNzIAmow/2fPfPkeviRcopSyCwcYRdEsGSr+JDrXI=",
+      strip_prefix = "",
+      remote_patches = {},
+      remote_patch_strip = 0,
+    )
+    # Rule http_archive defined at (most recent call last):
+    #   /home/user/.cache/bazel/_bazel_user/6e893e0f5a92cc4cf5909a6e4b2770f9/external/bazel_tools/tools/build_defs/repo/http.bzl:355:31 in 
+    ```
+
+7.  See what module extensions are used in your
+    dependency graph.
+
+    ```sh
+    bazel mod graph --extension_info=usages
+    ```
+
+    ```none
+     (my_project@1.0)
+    ├───$@@rules_java.5.0.0//java:extensions.bzl%toolchains
+    ├───rules_java@5.0.0 #
+    │   ├───$@@rules_java.5.0.0//java:extensions.bzl%toolchains
+    │   ├───rules_cc@0.0.1 #
+    │   │   └───$@@rules_cc.0.0.1//bzlmod:extensions.bzl%cc_configure
+    │   └───rules_proto@4.0.0
+    │       └───rules_cc@0.0.1 ...
+    └───stardoc@0.5.0
+        └───rules_java@5.0.0 ...
+    ```
+
+8.  See what repositories are generated and
+    imported from some specific extension as part of the dependency graph.
+
+    ```sh
+    bazel mod show_extension @@rules_java+5.0.0//java:extensions.bzl%toolchains
+    ```
+
+    ```none
+     (my_project@1.0)
+    ├───$@@rules_java.5.0.0//java:extensions.bzl%toolchains
+    │   ├───remotejdk17_linux
+    │   ├╌╌remotejdk11_linux
+    │   ├╌╌remotejdk11_linux_aarch64
+    │   ├╌╌remotejdk11_linux_ppc64le
+    │   ├╌╌remotejdk11_linux_s390x
+    ...(some lines omitted)...
+    ├───rules_java@5.0.0 #
+    │   └───$@@rules_java.5.0.0//java:extensions.bzl%toolchains ...
+    │       ├───local_jdk
+    │       ├───remote_java_tools
+    │       ├───remote_java_tools_darwin
+    │       ├───remote_java_tools_linux
+    │       ├───remote_java_tools_windows
+    │       ├───remotejdk11_linux_aarch64_toolchain_config_repo
+    │       ├───remotejdk11_linux_ppc64le_toolchain_config_repo
+    ...(some lines omitted)...
+    └───stardoc@0.5.0
+        └───rules_java@5.0.0 ...
+    ```
+
+9.  See the list of generated repositories of an
+    extension and how that extension is used in each module.
+
+    ```sh
+    bazel mod graph --extension_info=all --extension_filter=@rules_java//java:extensions.bzl%toolchains
+    ```
+
+    ```none
+    ## @@rules_java.5.0.0//java:extensions.bzl%toolchains:
+
+    Fetched repositories:
+      -   local_jdk (imported by bazel_tools@_, rules_java@5.0.0)
+      -   remote_java_tools (imported by bazel_tools@_, rules_java@5.0.0)
+      -   remote_java_tools_darwin (imported by bazel_tools@_, rules_java@5.0.0)
+      -   remote_java_tools_linux (imported by bazel_tools@_, rules_java@5.0.0)
+      -   remote_java_tools_windows (imported by bazel_tools@_, rules_java@5.0.0)
+      -   remotejdk11_linux_aarch64_toolchain_config_repo (imported by rules_java@5.0.0)
+      -   remotejdk11_linux_ppc64le_toolchain_config_repo (imported by rules_java@5.0.0)
+    ...(some lines omitted)...
+      -   remotejdk17_linux (imported by )
+      -   remotejdk11_linux
+      -   remotejdk11_linux_aarch64
+      -   remotejdk11_linux_ppc64le
+      -   remotejdk11_linux_s390x
+      -   remotejdk11_macos
+    ...(some lines omitted)...
+
+    # Usage in  at /MODULE.bazel:14:27 with the specified attributes:
+    use_repo(
+      toolchains,
+      my_jdk="remotejdk17_linux",
+    )
+
+    # Usage in bazel_tools@_ at bazel_tools@_/MODULE.bazel:23:32 with the specified attributes:
+    use_repo(
+      toolchains,
+      "local_jdk",
+      "remote_java_tools",
+      "remote_java_tools_linux",
+      "remote_java_tools_windows",
+      "remote_java_tools_darwin",
+    )
+
+    # Usage in rules_java@5.0.0 at rules_java@5.0.0/MODULE.bazel:30:27 with the specified attributes:
+    use_repo(
+      toolchains,
+      "remote_java_tools",
+      "remote_java_tools_linux",
+      "remote_java_tools_windows",
+      "remote_java_tools_darwin",
+      "local_jdk",
+      "remotejdk11_linux_toolchain_config_repo",
+      "remotejdk11_macos_toolchain_config_repo",
+      "remotejdk11_macos_aarch64_toolchain_config_repo",
+      ...(some lines omitted)...
+    )
+    ```
+
+10.  See the underlying rule of some
+    extension-generated repositories.
+
+    ```sh
+    bazel mod show_repo --base_module=rules_java @remote_java_tools
+    ```
+
+    ```none
+    ## @remote_java_tools:
+    # 
+    http_archive(
+      name = "rules_java++toolchains+remote_java_tools",
+      urls = ["https://mirror.bazel.build/bazel_java_tools/releases/java/v11.5/java_tools-v11.5.zip", "https://github.com/bazelbuild/java_tools/releases/download/java_v11.5/java_tools-v11.5.zip"],
+      sha256 = "b763ee80e5754e593fd6d5be6d7343f905bc8b73d661d36d842b024ca11b6793",
+    )
+    # Rule http_archive defined at (most recent call last):
+    #   /home/user/.cache/bazel/_bazel_user/6e893e0f5a92cc4cf5909a6e4b2770f9/external/bazel_tools/tools/build_defs/repo/http.bzl:355:31 in 
+    ```
\ No newline at end of file
diff --git a/versions/9.1.0/external/module.mdx b/versions/9.1.0/external/module.mdx
new file mode 100644
index 00000000..e390f2ee
--- /dev/null
+++ b/versions/9.1.0/external/module.mdx
@@ -0,0 +1,203 @@
+---
+title: 'Bazel modules'
+---
+
+A Bazel **module** is a Bazel project that can have multiple versions, each of
+which publishes metadata about other modules that it depends on. This is
+analogous to familiar concepts in other dependency management systems, such as a
+Maven *artifact*, an npm *package*, a Go *module*, or a Cargo *crate*.
+
+A module must have a `MODULE.bazel` file at its repo root. This file is the
+module's manifest, declaring its name, version, list of direct dependencies, and
+other information. For a basic example:
+
+```python
+module(name = "my-module", version = "1.0")
+
+bazel_dep(name = "rules_cc", version = "0.0.1")
+bazel_dep(name = "protobuf", version = "3.19.0")
+```
+
+See the [full list](/versions/9.1.0/rules/lib/globals/module) of directives available in
+`MODULE.bazel` files.
+
+To perform module resolution, Bazel starts by reading the root module's
+`MODULE.bazel` file, and then repeatedly requests any dependency's
+`MODULE.bazel` file from a [Bazel registry](/versions/9.1.0/external/registry) until it
+discovers the entire dependency graph.
+
+By default, Bazel then [selects](#version-selection) one version of each module
+to use. Bazel represents each module with a repo, and consults the registry
+again to learn how to define each of the repos.
+
+## Version format {#version-format}
+
+Bazel has a diverse ecosystem and projects use various versioning schemes. The
+most popular by far is [SemVer](https://semver.org), but there are
+also prominent projects using different schemes such as
+[Abseil](https://github.com/abseil/abseil-cpp/releases), whose
+versions are date-based, for example `20210324.2`).
+
+For this reason, Bazel adopts a more relaxed version of the SemVer spec. The
+differences include:
+
+*   SemVer prescribes that the "release" part of the version must consist of 3
+    segments: `MAJOR.MINOR.PATCH`. In Bazel, this requirement is loosened so
+    that any number of segments is allowed.
+*   In SemVer, each of the segments in the "release" part must be digits only.
+    In Bazel, this is loosened to allow letters too, and the comparison
+    semantics match the "identifiers" in the "prerelease" part.
+*   Additionally, the semantics of major, minor, and patch version increases are
+    not enforced.
+
+Any valid SemVer version is a valid Bazel module version. Additionally, two
+SemVer versions `a` and `b` compare `a < b` if and only if the same holds when
+they're compared as Bazel module versions.
+
+Finally, to learn more about module versioning, [see the `MODULE.bazel`
+FAQ](/versions/9.1.0/external/faq#module-versioning-best-practices).
+
+## Version selection {#version-selection}
+
+Consider the diamond dependency problem, a staple in the versioned dependency
+management space. Suppose you have the dependency graph:
+
+```
+       A 1.0
+      /     \
+   B 1.0    C 1.1
+     |        |
+   D 1.0    D 1.1
+```
+
+Which version of `D` should be used? To resolve this question, Bazel uses the
+[Minimal Version Selection](https://research.swtch.com/vgo-mvs)
+(MVS) algorithm introduced in the Go module system. MVS assumes that all new
+versions of a module are backwards compatible, and so picks the highest version
+specified by any dependent (`D 1.1` in our example). It's called "minimal"
+because `D 1.1` is the earliest version that could satisfy our requirements —
+even if `D 1.2` or newer exists, we don't select them. Using MVS creates a
+version selection process that is *high-fidelity* and *reproducible*.
+
+### Yanked versions
+
+The registry can declare certain versions as *yanked* if they should be avoided
+(such as for security vulnerabilities). Bazel throws an error when selecting a
+yanked version of a module. To fix this error, either upgrade to a newer,
+non-yanked version, or use the
+[`--allow_yanked_versions`](/versions/9.1.0/reference/command-line-reference#flag--allow_yanked_versions)
+flag to explicitly allow the yanked version.
+
+
+## Overrides
+
+Specify overrides in the `MODULE.bazel` file to alter the behavior of Bazel
+module resolution. Only the root module's overrides take effect — if a module is
+used as a dependency, its overrides are ignored.
+
+Each override is specified for a certain module name, affecting all of its
+versions in the dependency graph. Although only the root module's overrides take
+effect, they can be for transitive dependencies that the root module does not
+directly depend on.
+
+### Single-version override
+
+The [`single_version_override`](/versions/9.1.0/rules/lib/globals/module#single_version_override)
+serves multiple purposes:
+
+*   With the `version` attribute, you can pin a dependency to a specific
+    version, regardless of which versions of the dependency are requested in the
+    dependency graph.
+*   With the `registry` attribute, you can force this dependency to come from a
+    specific registry, instead of following the normal [registry
+    selection](/versions/9.1.0/external/registry#selecting_registries) process.
+*   With the `patch*` attributes, you can specify a set of patches to apply to
+    the downloaded module.
+
+These attributes are all optional and can be mixed and matched with each other.
+
+### Multiple-version override
+
+A [`multiple_version_override`](/versions/9.1.0/rules/lib/globals/module#multiple_version_override)
+can be specified to allow multiple versions of the same module to coexist in the
+resolved dependency graph.
+
+If there are multiple versions of the same module remaining in the dependency
+graph, Bazel will pick the nearest higher allowed version for each dependent.
+
+For example, if versions `1.1`, `1.3`, `1.5`, `1.7`, and `2.0` exist in the
+dependency graph before resolution:
+
+*   A multiple-version override allowing `1.3`, `1.7`, and `2.0` results in
+    `1.1` being upgraded to `1.3`, `1.5` being upgraded to `1.7`, and other
+    versions remaining the same.
+*   A multiple-version override allowing `1.9` and `2.0` results in an error, as
+    `1.9` is not present in the dependency graph before resolution.
+
+Additionally, users can also override the registry using the `registry`
+attribute, similarly to single-version overrides.
+
+### Non-registry overrides
+
+Non-registry overrides completely remove a module from version resolution. Bazel
+does not request these `MODULE.bazel` files from a registry, but instead from
+the repo itself.
+
+Bazel supports the following non-registry overrides:
+
+*   [`archive_override`](/versions/9.1.0/rules/lib/globals/module#archive_override)
+*   [`git_override`](/versions/9.1.0/rules/lib/globals/module#git_override)
+*   [`local_path_override`](/versions/9.1.0/rules/lib/globals/module#local_path_override)
+
+Note that setting a version value in the source archive `MODULE.bazel` can have
+downsides when the module is being overridden with a non-registry override. To
+learn more about this [see the `MODULE.bazel`
+FAQ](/versions/9.1.0/external/faq#module-versioning-best-practices).
+
+## Define repos that don't represent Bazel modules {#use_repo_rule}
+
+With `bazel_dep`, you can define repos that represent other Bazel modules.
+Sometimes there is a need to define a repo that does _not_ represent a Bazel
+module; for example, one that contains a plain JSON file to be read as data.
+
+In this case, you could use the [`use_repo_rule`
+directive](/versions/9.1.0/rules/lib/globals/module#use_repo_rule) to directly define a repo
+by invoking a repo rule. This repo will only be visible to the module it's
+defined in.
+
+Under the hood, this is implemented using the same mechanism as [module
+extensions](/versions/9.1.0/external/extension), which lets you define repos with more
+flexibility.
+
+## Repository names and strict deps
+
+The [apparent name](/versions/9.1.0/external/overview#apparent-repo-name) of a repo backing a
+module to its direct dependents defaults to its module name, unless the
+`repo_name` attribute of the [`bazel_dep`](/versions/9.1.0/rules/lib/globals/module#bazel_dep)
+directive says otherwise. Note that this means a module can only find its direct
+dependencies. This helps prevent accidental breakages due to changes in
+transitive dependencies.
+
+The [canonical name](/versions/9.1.0/external/overview#canonical-repo-name) of a repo backing a
+module is either `module_name+VERSION` (for example, `bazel_skylib+1.0.3`) or `MODULE_NAME+` (for example, `bazel_features+`), depending on whether there are
+multiple versions of the module in the entire dependency graph (see
+[`multiple_version_override`](/versions/9.1.0/rules/lib/globals/module#multiple_version_override)).
+Note that **the canonical name format** is not an API you should depend on and
+**is subject to change at any time**. Instead of hard-coding the canonical name,
+use a supported way to get it directly from Bazel:
+
+*    In BUILD and `.bzl` files, use
+     [`Label.repo_name`](/versions/9.1.0/rules/lib/builtins/Label#repo_name) on a `Label` instance
+     constructed from a label string given by the apparent name of the repo, e.g.,
+     `Label("@bazel_skylib").repo_name`.
+*    When looking up runfiles, use
+     [`$(rlocationpath ...)`](https://bazel.build/versions/9.1.0/reference/be/make-variables#predefined_label_variables)
+     or one of the runfiles libraries in
+     `@bazel_tools//tools/{bash,cpp,java}/runfiles` or, for a ruleset `rules_foo`,
+     in `@rules_foo//foo/runfiles`.
+*    When interacting with Bazel from an external tool such as an IDE or language
+     server, use the `bazel mod dump_repo_mapping` command to get the mapping from
+     apparent names to canonical names for a given set of repositories.
+
+[Module extensions](/versions/9.1.0/external/extension) can also introduce additional repos
+into the visible scope of a module.
diff --git a/versions/9.1.0/external/overview.mdx b/versions/9.1.0/external/overview.mdx
new file mode 100644
index 00000000..a791eaba
--- /dev/null
+++ b/versions/9.1.0/external/overview.mdx
@@ -0,0 +1,304 @@
+---
+title: 'External dependencies overview'
+---
+
+
+
+Bazel supports *external dependencies*, source files (both text and binary) used
+in your build that are not from your workspace. For example, they could be a
+ruleset hosted in a GitHub repo, a Maven artifact, or a directory on your local
+machine outside your current workspace.
+
+This document gives an overview of the system before examining some of the
+concepts in more detail.
+
+## Overview of the system {#overview}
+
+Bazel's external dependency system works on the basis of [*Bazel
+modules*](#module), each of which is a versioned Bazel project, and
+[*repositories*](#repository) (or repos), which are directory trees containing
+source files.
+
+Bazel starts from the root module -- that is, the project you're working on.
+Like all modules, it needs to have a `MODULE.bazel` file at its directory root,
+declaring its basic metadata and direct dependencies. The following is a basic
+example:
+
+```python
+module(name = "my-module", version = "1.0")
+
+bazel_dep(name = "rules_cc", version = "0.1.1")
+bazel_dep(name = "platforms", version = "0.0.11")
+```
+
+From there, Bazel looks up all transitive dependency modules in a
+[*Bazel registry*](/versions/9.1.0/external/registry) — by default, the [Bazel Central
+Registry](https://bcr.bazel.build/). The registry provides the
+dependencies' `MODULE.bazel` files, which allows Bazel to discover the entire
+transitive dependency graph before performing version resolution.
+
+After version resolution, in which one version is selected for each module,
+Bazel consults the registry again to learn how to define a repo for each module
+-- that is, how the sources for each dependency module should be fetched. Most
+of the time, these are just archives downloaded from the internet and extracted.
+
+Modules can also specify customized pieces of data called *tags*, which are
+consumed by [*module extensions*](/versions/9.1.0/external/extension) after module resolution
+to define additional repos. These extensions can perform actions like file I/O
+and sending network requests. Among other things, they allow Bazel to interact
+with other package management systems while also respecting the dependency graph
+built out of Bazel modules.
+
+The three kinds of repos -- the main repo (which is the source tree you're
+working in), the repos representing transitive dependency modules, and the repos
+created by module extensions -- form the [*workspace*](#workspace) together.
+External repos (non-main repos) are fetched on demand, for example when they're
+referred to by labels (like `@repo//pkg:target`) in BUILD files.
+
+## Benefits {#benefits}
+
+Bazel's external dependency system offers a wide range of benefits.
+
+### Automatic Dependency Resolution {#automatic-dependency-resolution}
+
+-   **Deterministic Version Resolution**: Bazel adopts the deterministic
+    [MVS](/versions/9.1.0/external/module#version-selection) version resolution algorithm,
+    minimizing conflicts and addressing diamond dependency issues.
+-   **Simplified Dependency Management**: `MODULE.bazel` declares only direct
+    dependencies, while transitive dependencies are automatically resolved,
+    providing a clearer overview of the project's dependencies.
+-   **[Strict Dependency visibility](/versions/9.1.0/external/module#repository_names_and_strict_deps)**:
+    Only direct dependencies are visible, ensuring correctness and
+    predictability.
+
+### Ecosystem Integration {#ecosystem-integration}
+
+-   **[Bazel Central Registry](https://registry.bazel.build/)**: A centralized
+    repository for discovering and managing common dependencies as Bazel
+    modules.
+-   **Adoption of Non-Bazel Projects**: When a non-Bazel project (usually a C++
+    library) is adapted for Bazel and made available in BCR, it streamlines its
+    integration for the whole community and eliminates duplicated effort and
+    conflicts of custom BUILD files.
+-   **Unified Integration with Language-Specific Package Managers**: Rulesets
+    streamline integration with external package managers for non-Bazel
+    dependencies, including:
+    *   [rules_jvm_external](https://github.com/bazel-contrib/rules_jvm_external/blob/master/docs/bzlmod.md)
+        for Maven,
+    *   [rules_python](https://rules-python.readthedocs.io/en/latest/pypi-dependencies.html#using-bzlmod)
+        for PyPi,
+    *   [bazel-gazelle](https://github.com/bazel-contrib/rules_go/blob/master/docs/go/core/bzlmod.md#external-dependencies)
+        for Go Modules,
+    *   [rules_rust](https://bazelbuild.github.io/rules_rust/crate_universe_bzlmod.html)
+        for Cargo.
+
+### Advanced Features {#advanced-features}
+
+-   **[Module Extensions](/versions/9.1.0/external/extension)**: The
+    [`use_repo_rule`](/versions/9.1.0/rules/lib/globals/module#use_repo_rule) and module
+    extension features allow flexible use of custom repository rules and
+    resolution logic to introduce any non-Bazel dependencies.
+-   **[`bazel mod` Command](/versions/9.1.0/external/mod-command)**: The sub-command offers
+    powerful ways to inspect external dependencies. You know exactly how an
+    external dependency is defined and where it comes from.
+-   **[Vendor Mode](/versions/9.1.0/external/vendor)**: Pre-fetch the exact external dependencies you
+    need to facilitate offline builds.
+-   **[Lockfile](/versions/9.1.0/external/lockfile)**: The lockfile improves build reproducibility and
+    accelerates dependency resolution.
+-   **(Upcoming) [BCR Provenance
+    Attestations](https://github.com/bazelbuild/bazel-central-registry/discussions/2721)**:
+    Strengthen supply chain security by ensuring verified provenance of
+    dependencies.
+
+## Concepts {#concepts}
+
+This section gives more detail on concepts related to external dependencies.
+
+### Module {#module}
+
+A Bazel project that can have multiple versions, each of which can have
+dependencies on other modules.
+
+In a local Bazel workspace, a module is represented by a repository.
+
+For more details, see [Bazel modules](/versions/9.1.0/external/module).
+
+### Repository {#repository}
+
+A directory tree with a boundary marker file at its root, containing source
+files that can be used in a Bazel build. Often shortened to just **repo**.
+
+A repo boundary marker file can be `MODULE.bazel` (signaling that this repo
+represents a Bazel module), `REPO.bazel` (see [below](#repo.bazel)), or in
+legacy contexts, `WORKSPACE` or `WORKSPACE.bazel`. Any repo boundary marker file
+will signify the boundary of a repo; multiple such files can coexist in a
+directory.
+
+### Main repository {#main-repository}
+
+The repository in which the current Bazel command is being run.
+
+The root of the main repository is also known as the
+**workspace root**.
+
+### Workspace {#workspace}
+
+The environment shared by all Bazel commands run in the same main repository. It
+encompasses the main repo and the set of all defined external repos.
+
+Note that historically the concepts of "repository" and "workspace" have been
+conflated; the term "workspace" has often been used to refer to the main
+repository, and sometimes even used as a synonym of "repository".
+
+### Canonical repository name {#canonical-repo-name}
+
+The name by which a repository is always addressable. Within the context of a
+workspace, each repository has a single canonical name. A target inside a repo
+whose canonical name is `canonical_name` can be addressed by the label
+`@@canonical_name//package:target` (note the double `@`).
+
+The main repository always has the empty string as the canonical name.
+
+### Apparent repository name {#apparent-repo-name}
+
+The name by which a repository is addressable in the context of a certain other
+repo. This can be thought of as a repo's "nickname": The repo with the canonical
+name `michael` might have the apparent name `mike` in the context of the repo
+`alice`, but might have the apparent name `mickey` in the context of the repo
+`bob`. In this case, a target inside `michael` can be addressed by the label
+`@mike//package:target` in the context of `alice` (note the single `@`).
+
+Conversely, this can be understood as a **repository mapping**: each repo
+maintains a mapping from "apparent repo name" to a "canonical repo name".
+
+### Repository rule {#repo-rule}
+
+A schema for repository definitions that tells Bazel how to materialize a
+repository. For example, it could be "download a zip archive from a certain URL
+and extract it", or "fetch a certain Maven artifact and make it available as a
+`java_import` target", or simply "symlink a local directory". Every repo is
+**defined** by calling a repo rule with an appropriate number of arguments.
+
+See [Repository rules](/versions/9.1.0/external/repo) for more information about how to write
+your own repository rules.
+
+The most common repo rules by far are
+[`http_archive`](/versions/9.1.0/rules/lib/repo/http#http_archive), which downloads an archive
+from a URL and extracts it, and
+[`local_repository`](/versions/9.1.0/reference/be/workspace#local_repository), which symlinks a
+local directory that is already a Bazel repository.
+
+### Fetch a repository {#fetch-repository}
+
+The action of making a repo available on local disk by running its associated
+repo rule. The repos defined in a workspace are not available on local disk
+before they are fetched.
+
+Normally, Bazel only fetches a repo when it needs something from the repo,
+and the repo hasn't already been fetched. If the repo has already been fetched
+before, Bazel only re-fetches it if its definition has changed.
+
+The `fetch` command can be used to initiate a pre-fetch for a repository,
+target, or all necessary repositories to perform any build. This capability
+enables offline builds using the `--nofetch` option.
+
+The `--fetch` option serves to manage network access. Its default value is true.
+However, when set to false (`--nofetch`), the command will utilize any cached
+version of the dependency, and if none exists, the command will result in
+failure.
+
+See [fetch options](/versions/9.1.0/reference/command-line-reference#fetch-options) for more
+information about controlling fetch.
+
+### Directory layout {#directory-layout}
+
+After being fetched, the repo can be found in the subdirectory `external` in the
+[output base](/versions/9.1.0/remote/output-directories), under its canonical name.
+
+You can run the following command to see the contents of the repo with the
+canonical name `canonical_name`:
+
+```posix-terminal
+ls $(bazel info output_base)/external/` canonical_name `
+```
+
+### REPO.bazel file
+
+The [`REPO.bazel`](/versions/9.1.0/rules/lib/globals/repo) file is used to mark the topmost
+boundary of the directory tree that constitutes a repo. It doesn't need to
+contain anything to serve as a repo boundary file; however, it can also be used
+to specify some common attributes for all build targets inside the repo.
+
+The syntax of a `REPO.bazel` file is similar to `BUILD` files, except that no
+`load` statements are supported. The `repo()` function takes the same arguments as the [`package()`
+function](/versions/9.1.0/reference/be/functions#package) in `BUILD` files; whereas `package()`
+specifies common attributes for all build targets inside the package, `repo()`
+analogously does so for all build targets inside the repo.
+
+For example, you can specify a common license for all targets in your repo by
+having the following `REPO.bazel` file:
+
+```python
+repo(
+    default_package_metadata = ["//:my_license"],
+)
+```
+
+## The legacy WORKSPACE system {#workspace-system}
+
+In older Bazel versions (before 9.0), external dependencies were introduced by
+defining repos in the `WORKSPACE` (or `WORKSPACE.bazel`) file. This file has a
+similar syntax to `BUILD` files, employing repo rules instead of build rules.
+
+The following snippet is an example to use the `http_archive` repo rule in the
+`WORKSPACE` file:
+
+```python
+load("@bazel_tools//tools/build_defs/repo:http.bzl", "http_archive")
+http_archive(
+    name = "foo",
+    urls = ["https://example.com/foo.zip"],
+    sha256 = "c9526390a7cd420fdcec2988b4f3626fe9c5b51e2959f685e8f4d170d1a9bd96",
+)
+```
+
+The snippet defines a repo whose canonical name is `foo`. In the `WORKSPACE`
+system, by default, the canonical name of a repo is also its apparent name to
+all other repos.
+
+See the [full list](/versions/9.1.0/rules/lib/globals/workspace) of functions available in
+`WORKSPACE` files.
+
+### Shortcomings of the `WORKSPACE` system {#workspace-shortcomings}
+
+In the years after the `WORKSPACE` system was introduced, users reported many
+pain points, including:
+
+*   Bazel does not evaluate the `WORKSPACE` files of any dependencies, so all
+    transitive dependencies must be defined in the `WORKSPACE` file of the main
+    repo, in addition to direct dependencies.
+*   To work around this, projects have adopted the "deps.bzl" pattern, in which
+    they define a macro which in turn defines multiple repos, and ask users to
+    call this macro in their `WORKSPACE` files.
+    *   This has its own problems: macros cannot `load` other `.bzl` files, so
+        these projects have to define their transitive dependencies in this
+        "deps" macro, or work around this issue by having the user call multiple
+        layered "deps" macros.
+    *   Bazel evaluates the `WORKSPACE` file sequentially. Additionally,
+        dependencies are specified using `http_archive` with URLs, without any
+        version information. This means that there is no reliable way to perform
+        version resolution in the case of diamond dependencies (`A` depends on
+        `B` and `C`; `B` and `C` both depend on different versions of `D`).
+
+Due to the shortcomings of WORKSPACE, the new module-based system (codenamed
+"Bzlmod") gradually replaced the legacy WORKSPACE system between Bazel 6 and 9.
+Read the [Bzlmod migration guide](/versions/9.1.0/external/migration) on how to migrate
+to Bzlmod.
+
+### External links on Bzlmod {#external-links}
+
+*   [Bzlmod usage examples in bazelbuild/examples](https://github.com/bazelbuild/examples/tree/main/bzlmod)
+*   [Bazel External Dependencies Overhaul](https://docs.google.com/document/d/1moQfNcEIttsk6vYanNKIy3ZuK53hQUFq1b1r0rmsYVg/edit)
+    (original Bzlmod design doc)
+*   [BazelCon 2021 talk on Bzlmod](https://www.youtube.com/watch?v=TxOCKtU39Fs)
+*   [Bazel Community Day talk on Bzlmod](https://www.youtube.com/watch?v=MB6xxis9gWI)
diff --git a/versions/9.1.0/external/registry.mdx b/versions/9.1.0/external/registry.mdx
new file mode 100644
index 00000000..ae16a32c
--- /dev/null
+++ b/versions/9.1.0/external/registry.mdx
@@ -0,0 +1,172 @@
+---
+title: 'Bazel registries'
+---
+
+Bazel discovers dependencies by requesting their information from Bazel
+*registries*: databases of Bazel modules. Bazel only supports one type of
+registries — [*index registries*](#index_registry) — local directories or static
+HTTP servers following a specific format.
+
+## Index registry
+
+An index registry is a local directory or a static HTTP server containing
+information about a list of modules — including their homepage, maintainers, the
+`MODULE.bazel` file of each version, and how to fetch the source of each
+version. Notably, it does *not* need to serve the source archives itself.
+
+An index registry must have the following format:
+
+*   [`/bazel_registry.json`](#bazel-registry-json): An optional JSON file
+    containing metadata for the registry.
+*   `/modules`: A directory containing a subdirectory for each module in this
+    registry
+*   `/modules/$MODULE`: A directory containing a subdirectory for each version
+    of the module named `$MODULE`, as well as the [`metadata.json`
+    file](#metadata-json) containing metadata for this module.
+*   `/modules/$MODULE/$VERSION`: A directory containing the following files:
+    *   `MODULE.bazel`: The `MODULE.bazel` file of this module version. Note
+        that this is the `MODULE.bazel` file read during Bazel's external
+        dependency resolution, _not_ the one from the source archive (unless
+        there's a [non-registry
+        override](/versions/9.1.0/external/module#non-registry_overrides)). Also note that it's
+        best to use this file to set the version of a release and avoid doing so
+        in the source archive `MODULE.bazel` file. To learn more about module
+        versioning, [see the FAQ](/versions/9.1.0/external/faq#module-versioning-best-practices).
+    *   [`source.json`](#source-json): A JSON file containing information on how
+        to fetch the source of this module version
+    *   `patches/`: An optional directory containing patch files, only used when
+        `source.json` has "archive" type
+    *   `overlay/`: An optional directory containing overlay files, only used
+        when `source.json` has "archive" type
+
+### `bazel_registry.json` {:#bazel-registry-json}
+
+`bazel_registry.json` is an optional file that specifies metadata applying to
+the entire registry. It can contain the following fields:
+
+*   `mirrors`: an array of strings, specifying the list of mirrors to use for
+    source archives.
+    *   The mirrored URL is a concatenation of the mirror itself, and the
+        source URL of the module specified by its `source.json` file sans the
+        protocol. For example, if a module's source URL is
+        `https://foo.com/bar/baz`, and `mirrors` contains
+        `["https://mirror1.com/", "https://example.com/mirror2/"]`, then the
+        URLs Bazel will try in order are `https://mirror1.com/foo.com/bar/baz`,
+        `https://example.com/mirror2/foo.com/bar/baz`, and finally the original
+        source URL itself `https://foo.com/bar/baz`.
+*   `module_base_path`: a string, specifying the base path for modules with
+    `local_path` type in the `source.json` file
+
+### `metadata.json` {:#metadata-json}
+
+`metadata.json` is an optional JSON file containing information about the
+module, with the following fields:
+
+*   `versions`: An array of strings, each denoting a version of the module
+    available in this registry. This array should match the children of the
+    module directory.
+*   `yanked_versions`: A JSON object specifying the [*yanked*
+    versions](/versions/9.1.0/external/module#yanked_versions) of this module. The keys
+    should be versions to yank, and the values should be descriptions of
+    why the version is yanked, ideally containing a link to more
+    information.
+
+Note that the BCR requires more information in the `metadata.json` file.
+
+### `source.json` {:#source-json}
+
+`source.json` is a required JSON file containing information about how to fetch
+a specific version of a module. The schema of this file depends on its `type`
+field, which defaults to `archive`.
+
+*   If `type` is `archive` (the default), this module version is backed by an
+    [`http_archive`](/versions/9.1.0/rules/lib/repo/http#http_archive) repo rule; it's fetched
+    by downloading an archive from a given URL and extracting its contents. It
+    supports the following fields:
+    *   `url`: A string, the URL of the source archive
+    *   `mirror_urls`: A list of string, the mirror URLs of the source archive.
+        The URLs are tried in order after `url` as backups.
+    *   `integrity`: A string, the [Subresource
+        Integrity][subresource-integrity] checksum of the archive
+    *   `strip_prefix`: A string, the directory prefix to strip when extracting
+        the source archive
+    *   `overlay`: A JSON object containing overlay files to layer on top of the
+        extracted archive. The patch files are located under the
+        `/modules/$MODULE/$VERSION/overlay` directory. The keys are the
+        overlay file names, and the values are the integrity checksum of
+        the overlay files. The overlays are applied before the patch files.
+    *   `patches`: A JSON object containing patch files to apply to the
+        extracted archive. The patch files are located under the
+        `/modules/$MODULE/$VERSION/patches` directory. The keys are the
+        patch file names, and the values are the integrity checksum of
+        the patch files. The patches are applied after the overlay files and in
+        the order they appear in `patches`.
+    *   `patch_strip`: A number; the same as the `--strip` argument of Unix
+        `patch`.
+    *   `archive_type`: A string, the archive type of the downloaded file (Same
+        as [`type` on `http_archive`](/versions/9.1.0/rules/lib/repo/http#http_archive-type)).
+*   If `type` is `git_repository`, this module version is backed by a
+    [`git_repository`](/versions/9.1.0/rules/lib/repo/git#git_repository) repo rule; it's
+    fetched by cloning a Git repository.
+    *   The following fields are supported, and are directly forwarded to the
+        underlying `git_repository` repo rule: `remote`, `commit`,
+        `shallow_since`, `tag`, `init_submodules`, `verbose`, and
+        `strip_prefix`, `patch_strip`.
+    *   `patches`: A JSON object containing patch files to apply to the
+        cloned repository. The patch files are located under the
+        `/modules/$MODULE/$VERSION/patches` directory. The keys are the
+        patch file names, and the values are the integrity checksum of
+        the patch files. The patches are applied in the order they appear in
+        `patches`.
+*   If `type` is `local_path`, this module version is backed by a
+    [`local_repository`](/versions/9.1.0/rules/lib/repo/local#local_repository) repo rule;
+    it's symlinked to a directory on local disk. It supports the following
+    field:
+    *   `path`: The local path to the repo, calculated as following:
+        *   If `path` is an absolute path, it stays as it is
+        *   If `path` is a relative path and `module_base_path` is an
+            absolute path, it resolves to `/`
+        *   If `path` and `module_base_path` are both relative paths, it
+            resolves to `//`.
+            Registry must be hosted locally and used by
+            `--registry=file://`. Otherwise, Bazel will
+            throw an error
+
+## Bazel Central Registry {:#bazel-central-registry}
+
+The Bazel Central Registry (BCR) at  is an index
+registry with contents backed by the GitHub repo
+[`bazelbuild/bazel-central-registry`][bcr-repo]. You can browse its contents
+using the web frontend at .
+
+The Bazel community maintains the BCR, and contributors are welcome to submit
+pull requests. See the [BCR contribution
+guidelines][bcr-contribution-guidelines].
+
+In addition to following the format of a normal index registry, the BCR requires
+a `presubmit.yml` file for each module version
+(`/modules/$MODULE/$VERSION/presubmit.yml`). This file specifies a few essential
+build and test targets that you can use to check the validity of this module
+version. The BCR's CI pipelines also uses this to ensure interoperability
+between modules.
+
+## Selecting registries
+
+The repeatable Bazel flag `--registry` can be used to specify the list of
+registries to request modules from, so you can set up your project to fetch
+dependencies from a third-party or internal registry. Earlier registries take
+precedence. For convenience, you can put a list of `--registry` flags in the
+`.bazelrc` file of your project.
+
+If your registry is hosted on GitHub (for example, as a fork of
+`bazelbuild/bazel-central-registry`) then your `--registry` value needs a raw
+GitHub address under `raw.githubusercontent.com`. For example, on the `main`
+branch of the `my-org` fork, you would set
+`--registry=https://raw.githubusercontent.com/my-org/bazel-central-registry/main/`.
+
+Using the `--registry` flag stops the Bazel Central Registry from being used by
+default, but you can add it back by adding `--registry=https://bcr.bazel.build`.
+
+[bcr-contribution-guidelines]: https://github.com/bazelbuild/bazel-central-registry/blob/main/docs/README.md
+[bcr-repo]: https://github.com/bazelbuild/bazel-central-registry
+[subresource-integrity]: https://w3c.github.io/webappsec-subresource-integrity/#integrity-metadata-description
diff --git a/versions/9.1.0/external/repo.mdx b/versions/9.1.0/external/repo.mdx
new file mode 100644
index 00000000..8b923e37
--- /dev/null
+++ b/versions/9.1.0/external/repo.mdx
@@ -0,0 +1,159 @@
+---
+title: 'Repository Rules'
+---
+
+This page covers how to define repository rules and provides examples for more
+details.
+
+An [external repository](/versions/9.1.0/external/overview#repository) is a directory tree,
+containing source files usable in a Bazel build, which is generated on demand by
+running its corresponding **repo rule**. Repos can be defined in a multitude of
+ways, but ultimately, each repo is defined by invoking a repo rule, just as
+build targets are defined by invoking build rules. They can be used to depend on
+third-party libraries (such as Maven packaged libraries) but also to generate
+`BUILD` files specific to the host Bazel is running on.
+
+## Repository rule definition
+
+In a `.bzl` file, use the
+[repository_rule](/versions/9.1.0/rules/lib/globals/bzl#repository_rule) function to define a
+new repo rule and store it in a global variable. After a repo rule is defined,
+it can be invoked as a function to define repos. This invocation is usually
+performed from inside a [module extension](/versions/9.1.0/external/extension) implementation
+function.
+
+The two major components of a repo rule definition are its attribute schema and
+implementation function. The attribute schema determines the names and types of
+attributes passed to a repo rule invocation, and the implementation function is
+run when the repo needs to be fetched.
+
+## Attributes
+
+Attributes are arguments passed to the repo rule invocation. The schema of
+attributes accepted by a repo rule is specified using the `attrs` argument when
+the repo rule is defined with a call to `repository_rule`. An example defining
+`url` and `sha256` attributes as strings:
+
+```python
+http_archive = repository_rule(
+    implementation=_impl,
+    attrs={
+        "url": attr.string(mandatory=True),
+        "sha256": attr.string(mandatory=True),
+    }
+)
+```
+
+To access an attribute within the implementation function, use
+`repository_ctx.attr.`:
+
+```python
+def _impl(repository_ctx):
+    url = repository_ctx.attr.url
+    checksum = repository_ctx.attr.sha256
+```
+
+All `repository_rule`s have the implicitly defined attribute `name`. This is a
+string attribute that behaves somewhat magically: when specified as an input to
+a repo rule invocation, it takes an apparent repo name; but when read from the
+repo rule's implementation function using `repository_ctx.attr.name`, it returns
+the canonical repo name.
+
+## Implementation function
+
+Every repo rule requires an `implementation` function. It contains the actual
+logic of the rule and is executed strictly in the Loading Phase.
+
+The function has exactly one input parameter, `repository_ctx`. The function
+returns either `None` to signify that the rule is reproducible given the
+specified parameters, or a dict with a set of parameters for that rule that
+would turn that rule into a reproducible one generating the same repo. For
+example, for a rule tracking a git repository that would mean returning a
+specific commit identifier instead of a floating branch that was originally
+specified.
+
+The input parameter `repository_ctx` can be used to access attribute values, and
+non-hermetic functions (finding a binary, executing a binary, creating a file in
+the repository or downloading a file from the Internet). See [the API
+docs](/versions/9.1.0/rules/lib/builtins/repository_ctx) for more context. Example:
+
+```python
+def _impl(repository_ctx):
+  repository_ctx.symlink(repository_ctx.attr.path, "")
+
+local_repository = repository_rule(
+    implementation=_impl,
+    ...)
+```
+
+## When is the implementation function executed?
+
+The implementation function of a repo rule is executed when Bazel needs a target
+from that repository, for example when another target (in another repo) depends
+on it or if it is mentioned on the command line. The implementation function is
+then expected to create the repo in the file system. This is called "fetching"
+the repo.
+
+In contrast to regular targets, repos are not necessarily re-fetched when
+something changes that would cause the repo to be different. This is because
+there are things that Bazel either cannot detect changes to or it would cause
+too much overhead on every build (for example, things that are fetched from the
+network). Therefore, repos are re-fetched only if one of the following things
+changes:
+
+*   The attributes passed to the repo rule invocation.
+*   The Starlark code comprising the implementation of the repo rule.
+*   The value of any environment variable passed to `repository_ctx`'s
+    `getenv()` method or declared with the `environ` attribute of the
+    [`repository_rule`](/versions/9.1.0/rules/lib/globals/bzl#repository_rule). The values of
+    these environment variables can be hard-wired on the command line with the
+    [`--repo_env`](/versions/9.1.0/reference/command-line-reference#flag--repo_env) flag.
+*   The existence, contents, and type of any paths being
+    [`watch`ed](/versions/9.1.0/rules/lib/builtins/repository_ctx#watch) in the implementation
+    function of the repo rule.
+    *   Certain other methods of `repository_ctx` with a `watch` parameter, such
+        as `read()`, `execute()`, and `extract()`, can also cause paths to be
+        watched.
+    *   Similarly, [`repository_ctx.watch_tree`](/versions/9.1.0/rules/lib/builtins/repository_ctx#watch_tree)
+        and [`path.readdir`](/versions/9.1.0/rules/lib/builtins/path#readdir) can cause paths
+        to be watched in other ways.
+*   When `bazel fetch --force` is executed.
+
+There are two parameters of `repository_rule` that control when the repositories
+are re-fetched:
+
+*   If the `configure` flag is set, the repository is re-fetched on `bazel
+    fetch --force --configure` (non-`configure` repositories are not
+    re-fetched).
+*   If the `local` flag is set, in addition to the above cases, the repo is also
+    re-fetched when the Bazel server restarts.
+
+## Forcing refetch of external repos
+
+Sometimes, an external repo can become outdated without any change to its
+definition or dependencies. For example, a repo fetching sources might follow a
+particular branch of a third-party repository, and new commits are available on
+that branch. In this case, you can ask bazel to refetch all external repos
+unconditionally by calling `bazel fetch --force --all`.
+
+Moreover, some repo rules inspect the local machine and might become outdated if
+the local machine was upgraded. Here you can ask Bazel to only refetch those
+external repos where the [`repository_rule`](/versions/9.1.0/rules/lib/globals#repository_rule)
+definition has the `configure` attribute set, use `bazel fetch --force
+--configure`.
+
+## Examples
+
+-   [C++ auto-configured
+    toolchain](https://cs.opensource.google/bazel/bazel/+/master:tools/cpp/cc_configure.bzl;drc=644b7d41748e09eff9e47cbab2be2263bb71f29a;l=176):
+    it uses a repo rule to automatically create the C++ configuration files for
+    Bazel by looking for the local C++ compiler, the environment and the flags
+    the C++ compiler supports.
+
+-   [Go repositories](https://github.com/bazelbuild/rules_go/blob/67bc217b6210a0922d76d252472b87e9a6118fdf/go/private/go_repositories.bzl#L195)
+    uses several `repository_rule` to defines the list of dependencies needed to
+    use the Go rules.
+
+-   [rules_jvm_external](https://github.com/bazelbuild/rules_jvm_external)
+    creates an external repository called `@maven` by default that generates
+    build targets for every Maven artifact in the transitive dependency tree.
\ No newline at end of file
diff --git a/versions/9.1.0/external/vendor.mdx b/versions/9.1.0/external/vendor.mdx
new file mode 100644
index 00000000..a28b31b8
--- /dev/null
+++ b/versions/9.1.0/external/vendor.mdx
@@ -0,0 +1,210 @@
+---
+title: 'Vendor Mode'
+---
+
+Vendor mode is a feature that lets you create a local copy of
+external dependencies. This is useful for offline builds, or when you want to
+control the source of an external dependency.
+
+## Enable vendor mode {#enable-vendor-mode}
+
+You can enable vendor mode by specifying `--vendor_dir` flag.
+
+For example, by adding it to your `.bazelrc` file:
+
+```none
+# Enable vendor mode with vendor directory under /vendor_src
+common --vendor_dir=vendor_src
+```
+
+The vendor directory can be either a relative path to your workspace root or an
+absolute path.
+
+## Vendor a specific external repository {#vendor-specific-repository}
+
+You can use the `vendor` command with the `--repo` flag to specify which repo
+to vendor, it accepts both [canonical repo
+name](/versions/9.1.0/external/overview#canonical-repo-name) and [apparent repo
+name](/versions/9.1.0/external/overview#apparent-repo-name).
+
+For example, running:
+
+```none
+bazel vendor --vendor_dir=vendor_src --repo=@rules_cc
+```
+
+or
+
+```none
+bazel vendor --vendor_dir=vendor_src --repo=@@rules_cc+
+```
+
+will both get rules_cc to be vendored under
+`/vendor_src/rules_cc+`.
+
+## Vendor external dependencies for given targets {#vendor-target-dependencies}
+
+To vendor all external dependencies required for building given target patterns,
+you can run `bazel vendor `.
+
+For example
+
+```none
+bazel vendor --vendor_dir=vendor_src //src/main:hello-world //src/test/...
+```
+
+will vendor all repos required for building the `//src/main:hello-world` target
+and all targets under `//src/test/...` with the current configuration.
+
+Under the hood, it's doing a `bazel build --nobuild` command to analyze the
+target patterns, therefore build flags could be applied to this command and
+affect the result.
+
+### Build the target offline {#build-the-target-offline}
+
+With the external dependencies vendored, you can build the target offline by
+
+```none
+bazel build --vendor_dir=vendor_src //src/main:hello-world //src/test/...
+```
+
+The build should work in a clean build environment without network access and
+repository cache.
+
+Therefore, you should be able to check in the vendored source and build the same
+targets offline on another machine.
+
+Note: If you make changes to the targets to build, the external dependencies,
+the build configuration, or the Bazel version, you may need to re-vendor to make
+sure offline build still works.
+
+## Vendor all external dependencies {#vendor-all-dependencies}
+
+To vendor all repos in your transitive external dependencies graph, you can
+run:
+
+```none
+bazel vendor --vendor_dir=vendor_src
+```
+
+Note that vendoring all dependencies has a few **disadvantages**:
+
+-   Fetching all repos, including those introduced transitively, can be time-consuming.
+-   The vendor directory can become very large.
+-   Some repos may fail to fetch if they are not compatible with the current platform or environment.
+
+Therefore, consider vendoring for specific targets first.
+
+## Configure vendor mode with VENDOR.bazel {#configure-vendor-mode}
+
+You can control how given repos are handled with the VENDOR.bazel file located
+under the vendor directory.
+
+There are two directives available, both accepting a list of
+[canonical repo names](/versions/9.1.0/external/overview#canonical-repo-name) as arguments:
+
+- `ignore()`: to completely ignore a repository from vendor mode.
+- `pin()`: to pin a repository to its current vendored source as if there is a
+  `--override_repository` flag for this repo. Bazel will NOT update the vendored
+  source for this repo while running the vendor command unless it's unpinned.
+  The user can modify and maintain the vendored source for this repo manually.
+
+For example
+
+```python
+ignore("@@rules_cc+")
+pin("@@bazel_skylib+")
+```
+
+With this configuration
+
+-   Both repos will be excluded from subsequent vendor commands.
+-   Repo `bazel_skylib` will be overridden to the source located under the
+    vendor directory.
+-   The user can safely modify the vendored source of `bazel_skylib`.
+-   To re-vendor `bazel_skylib`, the user has to disable the pin statement
+    first.
+
+Note: Repository rules with
+[`local`](/versions/9.1.0/rules/lib/globals/bzl#repository_rule.local) or
+[`configure`](/versions/9.1.0/rules/lib/globals/bzl#repository_rule.configure) set to true are
+always excluded from vendoring.
+
+## Understand how vendor mode works {#how-vendor-mode-works}
+
+Bazel fetches external dependencies of a project under `$(bazel info
+output_base)/external`. Vendoring external dependencies means moving out
+relevant files and directories to the given vendor directory and use the
+vendored source for later builds.
+
+The content being vendored includes:
+
+-   The repo directory
+-   The repo marker file
+
+During a build, if the vendored marker file is up-to-date or the repo is
+pinned in the VENDOR.bazel file, then Bazel uses the vendored source by creating
+a symlink to it under `$(bazel info output_base)/external` instead of actually
+running the repository rule. Otherwise, a warning is printed and Bazel will
+fallback to fetching the latest version of the repo.
+
+Note: Bazel assumes the vendored source is not changed by users unless the repo
+is pinned in the VENDOR.bazel file. If a user does change the vendored source
+without pinning the repo, the changed vendored source will be used, but it will
+be overwritten if its existing marker file is
+outdated and the repo is vendored again.
+
+### Vendor registry files {#vendor-registry-files}
+
+Bazel has to perform the Bazel module resolution in order to fetch external
+dependencies, which may require accessing registry files through internet. To
+achieve offline build, Bazel vendors all registry files fetched from
+network under the `/_registries` directory.
+
+### Vendor symlinks {#vendor-symlinks}
+
+External repositories may contain symlinks pointing to other files or
+directories. To make sure symlinks work correctly, Bazel uses the following
+strategy to rewrite symlinks in the vendored source:
+
+-   Create a symlink `/bazel-external` that points to `$(bazel info
+    output_base)/external`. It is refreshed by every Bazel command
+    automatically.
+-   For the vendored source, rewrite all symlinks that originally point to a
+    path under `$(bazel info output_base)/external` to a relative path under
+    `/bazel-external`.
+
+For example, if the original symlink is
+
+```none
+/repo_foo+/link  =>  $(bazel info output_base)/external/repo_bar+/file
+```
+
+It will be rewritten to
+
+```none
+/repo_foo+/link  =>  ../../bazel-external/repo_bar+/file
+```
+
+where
+
+```none
+/bazel-external  =>  $(bazel info output_base)/external  # This might be new if output base is changed
+```
+
+Since `/bazel-external` is generated by Bazel automatically, it's
+recommended to add it to `.gitignore` or equivalent to avoid checking it in.
+
+With this strategy, symlinks in the vendored source should work correctly even
+after the vendored source is moved to another location or the bazel output base
+is changed.
+
+Note: symlinks that point to an absolute path outside of $(bazel info
+output_base)/external are not rewritten. Therefore, it could still break
+cross-machine compatibility.
+
+Note: On Windows, vendoring symlinks only works with
+[`--windows_enable_symlinks`][windows_enable_symlinks]
+flag enabled.
+
+[windows_enable_symlinks]: /reference/command-line-reference#flag--windows_enable_symlinks
diff --git a/versions/9.1.0/help.mdx b/versions/9.1.0/help.mdx
new file mode 100644
index 00000000..5312ac03
--- /dev/null
+++ b/versions/9.1.0/help.mdx
@@ -0,0 +1,51 @@
+---
+title: 'Getting Help'
+---
+
+This page lists Bazel resources beyond the documentation and covers how to get
+support from the Bazel team and community.
+
+## Search existing material {#search-material}
+
+In addition to the documentation, you can find helpful information by searching:
+
+* [Bazel user group](https://groups.google.com/g/bazel-discuss)
+* [Bazel GitHub Discussions](https://github.com/bazelbuild/bazel/discussions)
+* [Bazel blog](https://blog.bazel.build/)
+* [Stack Overflow](https://stackoverflow.com/questions/tagged/bazel)
+* [`awesome-bazel` resources](https://github.com/jin/awesome-bazel)
+
+## Watch videos {#videos}
+
+There are recordings of Bazel talks at various conferences, such as:
+
+* Bazel’s annual conference, BazelCon:
+  * [BazelCon 2024](https://www.youtube.com/playlist?list=PLbzoR-pLrL6ptKfAQNZ5RS4HMdmeilBcw)
+  * [BazelCon 2023](https://www.youtube.com/playlist?list=PLbzoR-pLrL6rUiqylH-kumoZCWntG1vjp)
+  * [BazelCon 2022](https://www.youtube.com/playlist?list=PLbzoR-pLrL6rABfcAJO1VWeOUYL1kIn-p)
+  * [BazelCon 2021](https://www.youtube.com/playlist?list=PLbzoR-pLrL6pO6BaaQ1Ndos53gfRVLEoU)
+  * [BazelCon 2020](https://www.youtube.com/playlist?list=PLbzoR-pLrL6qZ5JRMtn20_s2uPz9vFYgU)
+  * [BazelCon 2019](https://www.youtube.com/playlist?list=PLbzoR-pLrL6ogKgytQXqUxJQ6nZlIWoTH)
+  * [BazelCon 2018](https://www.youtube.com/playlist?list=PLbzoR-pLrL6rBDwC0NMRPS8EJ0VRAW0QR)
+  * [BazelCon 2017](https://www.youtube.com/playlist?list=PLbzoR-pLrL6qvwchdtlSopLgUrz4J4zKP)
+* Bazel day on [Google Open Source Live](https://opensourcelive.withgoogle.com/events/bazel)
+
+## Ask the Bazel community {#community}
+
+If there are no existing answers, you can ask the community by:
+
+* Emailing the [Bazel user group](https://groups.google.com/g/bazel-discuss)
+* Starting a discussion on [GitHub](https://github.com/bazelbuild/bazel/discussions)
+* Asking a question on [Stack Overflow](https://stackoverflow.com/questions/tagged/bazel)
+* Chatting with other Bazel contributors on [Slack](https://slack.bazel.build/)
+* Consulting a [Bazel community expert](/versions/9.1.0/community/experts)
+
+## Understand Bazel's support level {#support-level}
+
+Please read the [release page](/versions/9.1.0/release) to understand Bazel's release model and
+what level of support Bazel provides.
+
+## File a bug {#file-bug}
+
+If you encounter a bug or want to request a feature, file a [GitHub
+Issue](https://github.com/bazelbuild/bazel/issues).
diff --git a/versions/9.1.0/install/bazelisk.mdx b/versions/9.1.0/install/bazelisk.mdx
new file mode 100644
index 00000000..03179d28
--- /dev/null
+++ b/versions/9.1.0/install/bazelisk.mdx
@@ -0,0 +1,57 @@
+---
+title: 'Installing / Updating Bazel using Bazelisk'
+---
+
+## Installing Bazel
+
+[Bazelisk](https://github.com/bazelbuild/bazelisk) is the
+recommended way to install Bazel on Ubuntu, Windows, and macOS. It automatically
+downloads and installs the appropriate version of Bazel. Use Bazelisk if you
+need to switch between different versions of Bazel depending on the current
+working directory, or to always keep Bazel updated to the latest release.
+
+For more details, see
+[the official README](https://github.com/bazelbuild/bazelisk/blob/master/README.md).
+
+## Updating Bazel
+
+Bazel has a [backward compatibility policy](/versions/9.1.0/release/backward-compatibility)
+(see [guidance for rolling out incompatible
+changes](/versions/9.1.0/contribute/breaking-changes) if you
+are the author of one). That page summarizes best practices on how to test and
+migrate your project with upcoming incompatible changes and how to provide
+feedback to the incompatible change authors.
+
+### Managing Bazel versions with Bazelisk {#manage-with-bazelisk}
+
+[Bazelisk](https://github.com/bazelbuild/bazelisk) helps you manage
+Bazel versions.
+
+Bazelisk can:
+
+*   Auto-update Bazel to the latest LTS or rolling release.
+*   Build the project with a Bazel version specified in the .bazelversion
+    file. Check in that file into your version control to ensure reproducibility
+    of your builds.
+*   Help migrate your project for incompatible changes (see above)
+*   Easily try release candidates
+
+### Recommended migration process {#migration-process}
+
+Within minor updates to any LTS release, any
+project can be prepared for the next release without breaking
+compatibility with the current release. However, there may be
+backward-incompatible changes between major LTS versions.
+
+Follow this process to migrate from one major version to another:
+
+1. Read the release notes to get advice on how to migrate to the next version.
+1. Major incompatible changes should have an associated `--incompatible_*` flag
+   and a corresponding GitHub issue:
+    *   Migration guidance is available in the associated GitHub issue.
+    *   Tooling is available for some of incompatible changes migration. For
+        example, [buildifier](https://github.com/bazelbuild/buildtools/releases).
+    *   Report migration problems by commenting on the associated GitHub issue.
+
+After migration, you can continue to build your projects without worrying about
+backward-compatibility until the next major release.
diff --git a/versions/9.1.0/install/compile-source.mdx b/versions/9.1.0/install/compile-source.mdx
new file mode 100644
index 00000000..eb5663b8
--- /dev/null
+++ b/versions/9.1.0/install/compile-source.mdx
@@ -0,0 +1,296 @@
+---
+title: 'Compiling Bazel from Source'
+---
+
+This page describes how to install Bazel from source and provides
+troubleshooting tips for common issues.
+
+To build Bazel from source, you can do one of the following:
+
+*   Build it [using an existing Bazel binary](#build-bazel-using-bazel)
+
+*   Build it [without an existing Bazel binary](#bootstrap-bazel) which is known
+    as _bootstrapping_.
+
+## Build Bazel using Bazel {#build-bazel-using-bazel}
+
+### Summary {#summary}
+
+1.  Get the latest Bazel release from the
+    [GitHub release page](https://github.com/bazelbuild/bazel/releases) or with
+    [Bazelisk](https://github.com/bazelbuild/bazelisk).
+
+2.  [Download Bazel's sources from GitHub](https://github.com/bazelbuild/bazel/archive/master.zip)
+    and extract somewhere.
+    Alternatively you can git clone the source tree from https://github.com/bazelbuild/bazel
+
+3.  Install the same prerequisites as for bootstrapping (see
+    [for Unix-like systems](#bootstrap-unix-prereq) or
+    [for Windows](#bootstrap-windows-prereq))
+
+4.  Build a development build of Bazel using Bazel:
+    `bazel build //src:bazel-dev` (or `bazel build //src:bazel-dev.exe` on
+    Windows)
+
+5.  The resulting binary is at `bazel-bin/src/bazel-dev`
+    (or `bazel-bin\src\bazel-dev.exe` on Windows). You can copy it wherever you
+    like and use immediately without further installation.
+
+Detailed instructions follow below.
+
+### Step 1: Get the latest Bazel release {#build-bazel-install-bazel}
+
+**Goal**: Install or download a release version of Bazel. Make sure you can run
+it by typing `bazel` in a terminal.
+
+**Reason**: To build Bazel from a GitHub source tree, you need a pre-existing
+Bazel binary. You can install one from a package manager or download one from
+GitHub. See [Installing Bazel](/versions/9.1.0/install). (Or you can [build from
+scratch (bootstrap)](#bootstrap-bazel).)
+
+**Troubleshooting**:
+
+*   If you cannot run Bazel by typing `bazel` in a terminal:
+
+    *   Maybe your Bazel binary's directory is not on the PATH.
+
+        This is not a big problem. Instead of typing `bazel`, you will need to
+        type the full path.
+
+    *   Maybe the Bazel binary itself is not called `bazel` (on Unixes) or
+        `bazel.exe` (on Windows).
+
+        This is not a big problem. You can either rename the binary, or type the
+        binary's name instead of `bazel`.
+
+    *   Maybe the binary is not executable (on Unixes).
+
+        You must make the binary executable by running `chmod +x /path/to/bazel`.
+
+### Step 2: Download Bazel's sources from GitHub {#build-bazel-git}
+
+If you are familiar with Git, then just git clone https://github.com/bazelbuild/bazel
+
+Otherwise:
+
+1.  Download the
+    [latest sources as a zip file](https://github.com/bazelbuild/bazel/archive/master.zip).
+
+2.  Extract the contents somewhere.
+
+    For example create a `bazel-src` directory under your home directory and
+    extract there.
+
+### Step 3: Install prerequisites {#build-bazel-prerequisites}
+
+Install the same prerequisites as for bootstrapping (see below) -- JDK, C++
+compiler, MSYS2 (if you are building on Windows), etc.
+
+### Step 4a: Build Bazel on Ubuntu Linux, macOS, and other Unix-like systems {#build-bazel-on-unixes}
+
+For instructions for Windows, see [Build Bazel on Windows](#build-bazel-on-windows).
+
+**Goal**: Run Bazel to build a custom Bazel binary (`bazel-bin/src/bazel-dev`).
+
+**Instructions**:
+
+1.  Start a Bash terminal
+
+2.  `cd` into the directory where you extracted (or cloned) Bazel's sources.
+
+    For example if you extracted the sources under your home directory, run:
+
+        cd ~/bazel-src
+
+3.  Build Bazel from source:
+
+        bazel build //src:bazel-dev
+
+    Alternatively you can run `bazel build //src:bazel --compilation_mode=opt`
+    to yield a smaller binary but it's slower to build.
+
+    You can build with `--stamp --embed_label=X.Y.Z` flag to embed a Bazel
+    version for the binary so that `bazel --version` outputs the given version.
+
+4.  The output will be at `bazel-bin/src/bazel-dev` (or `bazel-bin/src/bazel`).
+
+### Step 4b: Build Bazel on Windows {#build-bazel-on-windows}
+
+For instructions for Unix-like systems, see
+[Ubuntu Linux, macOS, and other Unix-like systems](#build-bazel-on-unixes).
+
+**Goal**: Run Bazel to build a custom Bazel binary
+(`bazel-bin\src\bazel-dev.exe`).
+
+**Instructions**:
+
+1.  Start Command Prompt (Start Menu > Run > "cmd.exe")
+
+2.  `cd` into the directory where you extracted (or cloned) Bazel's sources.
+
+    For example if you extracted the sources under your home directory, run:
+
+        cd %USERPROFILE%\bazel-src
+
+3.  Build Bazel from source:
+
+    bazel build //src:bazel-dev.exe
+
+    Alternatively you can run `bazel build //src:bazel.exe
+    --compilation_mode=opt` to yield a smaller binary but it's slower to build.
+
+    You can build with `--stamp --embed_label=X.Y.Z` flag to embed a Bazel
+    version for the binary so that `bazel --version` outputs the given version.
+
+4.  The output will be at `bazel-bin\src\bazel-dev.exe` (or
+    `bazel-bin\src\bazel.exe`).
+
+### Step 5: Install the built binary {#build-bazel-install}
+
+Actually, there's nothing to install.
+
+The output of the previous step is a self-contained Bazel binary. You can copy
+it to any directory and use immediately. (It's useful if that directory is on
+your PATH so that you can run "bazel" everywhere.)
+
+---
+
+## Build Bazel from scratch (bootstrapping) {#bootstrap-bazel}
+
+You can also build Bazel from scratch, without using an existing Bazel binary.
+
+### Step 1: Download Bazel's sources (distribution archive) {#download-distfile}
+
+(This step is the same for all platforms.)
+
+1.  Download `bazel--dist.zip` from
+    [GitHub](https://github.com/bazelbuild/bazel/releases), for example
+    `bazel-0.28.1-dist.zip`.
+
+    **Attention**:
+
+    -   There is a **single, architecture-independent** distribution archive.
+        There are no architecture-specific or OS-specific distribution archives.
+    -   These sources are **not the same as the GitHub source tree**. You
+        have to use the distribution archive to bootstrap Bazel. You cannot
+        use a source tree cloned from GitHub. (The distribution archive contains
+        generated source files that are required for bootstrapping and are not part
+        of the normal Git source tree.)
+
+2.  Unpack the distribution archive somewhere on disk.
+
+    You should verify the signature made by Bazel's
+    [release key](https://bazel.build/versions/9.1.0/bazel-release.pub.gpg) 3D5919B448457EE0.
+
+### Step 2a: Bootstrap Bazel on Ubuntu Linux, macOS, and other Unix-like systems {#bootstrap-unix-overview}
+
+For instructions for Windows, see [Bootstrap Bazel on Windows](#bootstrap-windows).
+
+#### 2.1. Install the prerequisites {#bootstrap-windows-prereq}
+
+*   **Bash**
+
+*   **zip, unzip**
+
+*   **C++ build toolchain**
+
+*   **JDK.** Version 21 is required.
+
+*   **Python**. Version 3 is required.
+
+For example on Ubuntu Linux you can install these requirements using the
+following command:
+
+```sh
+sudo apt-get install build-essential openjdk-21-jdk python3 zip unzip
+```
+
+#### 2.2. Bootstrap Bazel on Unix {#bootstrap-unix}
+
+1.  Open a shell or Terminal window.
+
+3.  `cd` to the directory where you unpacked the distribution archive.
+
+3.  Run the compilation script: `env EXTRA_BAZEL_ARGS="--tool_java_runtime_version=local_jdk" bash ./compile.sh`.
+
+The compiled output is placed into `output/bazel`. This is a self-contained
+Bazel binary, without an embedded JDK. You can copy it anywhere or use it
+in-place. For convenience, copy this binary to a directory that's on your
+`PATH` (such as `/usr/local/bin` on Linux).
+
+To build the `bazel` binary in a reproducible way, also set
+[`SOURCE_DATE_EPOCH`](https://reproducible-builds.org/specs/source-date-epoch/)
+in the "Run the compilation script" step.
+
+### Step 2b: Bootstrap Bazel on Windows {#bootstrap-windows-overview}
+
+For instructions for Unix-like systems, see
+[Bootstrap Bazel on Ubuntu Linux, macOS, and other Unix-like systems](#bootstrap-unix).
+
+#### 2.1. Install the prerequisites {#bootstrap-windows-prereq}
+
+*   [MSYS2 shell](https://msys2.github.io/)
+
+*   **The MSYS2 packages for zip and unzip.** Run the following command in the MSYS2 shell:
+
+    ```
+    pacman -S zip unzip patch
+    ```
+
+*   **The Visual C++ compiler.** Install the Visual C++ compiler either as part
+    of Visual Studio 2015 or newer, or by installing the latest [Build Tools
+    for Visual Studio 2017](https://aka.ms/BuildTools).
+
+*   **JDK.** Version 21 is required.
+
+*   **Python**. Versions 2 and 3 are supported, installing one of them is
+    enough. You need the Windows-native version (downloadable from
+    [https://www.python.org](https://www.python.org)). Versions installed via
+    pacman in MSYS2 will not work.
+
+#### 2.2. Bootstrap Bazel on Windows {#bootstrap-windows}
+
+1.  Open the MSYS2 shell.
+
+2.  Set the following environment variables:
+    *   Either `BAZEL_VS` or `BAZEL_VC` (they are *not* the same): Set to the
+        path to the Visual Studio directory (BAZEL\_VS) or to the Visual
+        C++ directory (BAZEL\_VC). Setting one of them is enough.
+    *   `BAZEL_SH`: Path of the MSYS2 `bash.exe`. See the command in the
+        examples below.
+
+        Do not set this to `C:\Windows\System32\bash.exe`. (You have that file
+        if you installed Windows Subsystem for Linux.) Bazel does not support
+        this version of `bash.exe`.
+    *   `PATH`: Add the Python directory.
+    *   `JAVA_HOME`: Set to the JDK directory.
+
+    **Example** (using BAZEL\_VS):
+
+        export BAZEL_VS="C:/Program Files (x86)/Microsoft Visual Studio/2017/BuildTools"
+        export BAZEL_SH="$(cygpath -m $(realpath $(which bash)))"
+        export PATH="/c/python27:$PATH"
+        export JAVA_HOME="C:/Program Files/Java/jdk-21"
+
+    or (using BAZEL\_VC):
+
+        export BAZEL_VC="C:/Program Files (x86)/Microsoft Visual Studio/2017/BuildTools/VC"
+        export BAZEL_SH="$(cygpath -m $(realpath $(which bash)))"
+        export PATH="/c/python27:$PATH"
+        export JAVA_HOME="C:/Program Files/Java/jdk-21"
+
+3.  `cd` to the directory where you unpacked the distribution archive.
+
+4.  Run the compilation script: `env EXTRA_BAZEL_ARGS="--tool_java_runtime_version=local_jdk" ./compile.sh`
+
+The compiled output is placed into `output/bazel.exe`. This is a self-contained
+Bazel binary, without an embedded JDK. You can copy it anywhere or use it
+in-place. For convenience, copy this binary to a directory that's on
+your `PATH`.
+
+To build the `bazel.exe` binary in a reproducible way, also set
+[`SOURCE_DATE_EPOCH`](https://reproducible-builds.org/specs/source-date-epoch/)
+in the "Run the compilation script" step.
+
+You don't need to run Bazel from the MSYS2 shell. You can run Bazel from the
+Command Prompt (`cmd.exe`) or PowerShell.
diff --git a/versions/9.1.0/install/completion.mdx b/versions/9.1.0/install/completion.mdx
new file mode 100644
index 00000000..471a7282
--- /dev/null
+++ b/versions/9.1.0/install/completion.mdx
@@ -0,0 +1,124 @@
+---
+title: 'Command-Line Completion'
+---
+
+You can enable command-line completion (also known as tab-completion) in Bash
+and Zsh. This lets you tab-complete command names, flags names and flag values,
+and target names.
+
+## Bash {#bash}
+
+Bazel comes with a Bash completion script.
+
+If you installed Bazel:
+
+*   From the APT repository, then you're done -- the Bash completion script is
+    already installed in `/etc/bash_completion.d`.
+
+*   From Homebrew, then you're done -- the Bash completion script is
+    already installed in `$(brew --prefix)/etc/bash_completion.d`.
+
+*   From the installer downloaded from GitHub, then:
+    1.  Locate the absolute path of the completion file. The installer copied it
+        to the `bin` directory.
+
+        Example: if you ran the installer with `--user`, this will be
+        `$HOME/.bazel/bin`. If you ran the installer as root, this will be
+        `/usr/local/lib/bazel/bin`.
+    2.  Do one of the following:
+        *   Either copy this file to your completion directory (if you have
+            one).
+
+            Example: on Ubuntu this is the `/etc/bash_completion.d` directory.
+        *   Or source the completion file from Bash's RC file.
+
+            Add a line similar to the one below to your `~/.bashrc` (on Ubuntu)
+            or `~/.bash_profile` (on macOS), using the path to your completion
+            file's absolute path:
+
+            ```
+            source /path/to/bazel-complete.bash
+            ```
+
+*   Via [bootstrapping](/versions/9.1.0/install/compile-source), then:
+    1.  Emit the completion script into a file:
+
+        ```
+        bazel help completion bash > bazel-complete.bash
+        ```
+    2.  Do one of the following:
+        *   Copy this file to your completion directory, if you have
+            one.
+
+            Example: on Ubuntu this is the `/etc/bash_completion.d` directory
+        *   Copy it somewhere on your local disk, such as to `$HOME`, and
+            source the completion file from Bash's RC file.
+
+            Add a line similar to the one below to your `~/.bashrc` (on Ubuntu)
+            or `~/.bash_profile` (on macOS), using the path to your completion
+            file's absolute path:
+
+            ```
+            source /path/to/bazel-complete.bash
+            ```
+
+## Zsh {#zsh}
+
+Bazel comes with a Zsh completion script.
+
+If you installed Bazel:
+
+*   From the APT repository, then you're done -- the Zsh completion script is
+    already installed in `/usr/share/zsh/vendor-completions`.
+
+    > If you have a heavily customized `.zshrc` and the autocomplete
+    > does not function, try one of the following solutions:
+    >
+    > Add the following to your `.zshrc`:
+    >
+    >    ```
+    >     zstyle :compinstall filename '/home/tradical/.zshrc'
+    >
+    >     autoload -Uz compinit
+    >     compinit
+    >    ```
+    >
+    > or
+    >
+    > Follow the instructions
+    > [here](https://stackoverflow.com/questions/58331977/bazel-tab-auto-complete-in-zsh-not-working)
+    >
+    > If you are using `oh-my-zsh`, you may want to install and enable
+    > the `zsh-autocomplete` plugin. If you'd prefer not to, use one of the
+    > solutions described above.
+
+*   From Homebrew, then you're done -- the Zsh completion script is
+    already installed in `$(brew --prefix)/share/zsh/site-functions`.
+
+*   From the installer downloaded from GitHub, then:
+    1.  Locate the absolute path of the completion file. The installer copied it
+        to the `bin` directory.
+
+        Example: if you ran the installer with `--user`, this will be
+        `$HOME/.bazel/bin`. If you ran the installer as root, this will be
+        `/usr/local/lib/bazel/bin`.
+
+    2.  Add this script to a directory on your `$fpath`:
+
+        ```
+        fpath[1,0]=~/.zsh/completion/
+        mkdir -p ~/.zsh/completion/
+        cp /path/from/above/step/_bazel ~/.zsh/completion
+        ```
+
+        You may have to call `rm -f ~/.zcompdump; compinit`
+        the first time to make it work.
+
+    3.  Optionally, add the following to your .zshrc.
+
+        ```
+        # This way the completion script does not have to parse Bazel's options
+        # repeatedly.  The directory in cache-path must be created manually.
+        zstyle ':completion:*' use-cache on
+        zstyle ':completion:*' cache-path ~/.zsh/cache
+        ```
diff --git a/versions/9.1.0/install/docker-container.mdx b/versions/9.1.0/install/docker-container.mdx
new file mode 100644
index 00000000..ffa29fdf
--- /dev/null
+++ b/versions/9.1.0/install/docker-container.mdx
@@ -0,0 +1,133 @@
+---
+title: 'Getting Started with Bazel Docker Container'
+---
+
+This page provides details on the contents of the Bazel container, how to build
+the [abseil-cpp](https://github.com/abseil/abseil-cpp) project using Bazel
+inside the Bazel container, and how to build this project directly
+from the host machine using the Bazel container with directory mounting.
+
+## Build Abseil project from your host machine with directory mounting {#build-abseil}
+
+The instructions in this section allow you to build using the Bazel container
+with the sources checked out in your host environment. A container is started up
+for each build command you execute. Build results are cached in your host
+environment so they can be reused across builds.
+
+Clone the project to a directory in your host machine.
+
+```posix-terminal
+git clone --depth 1 --branch 20220623.1 https://github.com/abseil/abseil-cpp.git /src/workspace
+```
+
+Create a folder that will have cached results to be shared across builds.
+
+```posix-terminal
+mkdir -p /tmp/build_output/
+```
+
+Use the Bazel container to build the project and make the build
+outputs available in the output folder in your host machine.
+
+```posix-terminal
+docker run \
+  -e USER="$(id -u)" \
+  -u="$(id -u)" \
+  -v /src/workspace:/src/workspace \
+  -v /tmp/build_output:/tmp/build_output \
+  -w /src/workspace \
+  gcr.io/bazel-public/bazel:latest \
+  --output_user_root=/tmp/build_output \
+  build //absl/...
+```
+
+Build the project with sanitizers by adding the `--config=asan|tsan|msan` build
+flag to select AddressSanitizer (asan), ThreadSanitizer (tsan) or
+MemorySanitizer (msan) accordingly.
+
+```posix-terminal
+docker run \
+  -e USER="$(id -u)" \
+  -u="$(id -u)" \
+  -v /src/workspace:/src/workspace \
+  -v /tmp/build_output:/tmp/build_output \
+  -w /src/workspace \
+  gcr.io/bazel-public/bazel:latest \
+  --output_user_root=/tmp/build_output \
+  build --config={asan | tsan | msan} -- //absl/... -//absl/types:variant_test
+```
+
+## Build Abseil project from inside the container {#build-abseil-inside-container}
+
+The instructions in this section allow you to build using the Bazel container
+with the sources inside the container. By starting a container at the beginning
+of your development workflow and doing changes in the worskpace within the
+container, build results will be cached.
+
+Start a shell in the Bazel container:
+
+```posix-terminal
+docker run --interactive --entrypoint=/bin/bash gcr.io/bazel-public/bazel:latest
+```
+
+Each container id is unique. In the instructions below, the container was 5a99103747c6.
+
+Clone the project.
+
+```posix-terminal
+ubuntu@5a99103747c6:~$ git clone --depth 1 --branch 20220623.1 https://github.com/abseil/abseil-cpp.git && cd abseil-cpp/
+```
+
+Do a regular build.
+
+```posix-terminal
+ubuntu@5a99103747c6:~/abseil-cpp$ bazel build //absl/...
+```
+
+Build the project with sanitizers by adding the `--config=asan|tsan|msan`
+build flag to select AddressSanitizer (asan), ThreadSanitizer (tsan) or
+MemorySanitizer (msan) accordingly.
+
+```posix-terminal
+ubuntu@5a99103747c6:~/abseil-cpp$ bazel build --config={asan | tsan | msan} -- //absl/... -//absl/types:variant_test
+```
+
+## Explore the Bazel container {#explore-bazel-container}
+
+If you haven't already, start an interactive shell inside the Bazel container.
+
+```posix-terminal
+docker run -it --entrypoint=/bin/bash gcr.io/bazel-public/bazel:latest
+ubuntu@5a99103747c6:~$
+```
+
+Explore the container contents.
+
+```posix-terminal
+ubuntu@5a99103747c6:~$ gcc --version
+gcc (Ubuntu 9.4.0-1ubuntu1~20.04.1) 9.4.0
+Copyright (C) 2019 Free Software Foundation, Inc.
+This is free software; see the source for copying conditions.  There is NO
+warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
+
+ubuntu@5a99103747c6:~$ java -version
+openjdk version "1.8.0_362"
+OpenJDK Runtime Environment (build 1.8.0_362-8u372-ga~us1-0ubuntu1~20.04-b09)
+OpenJDK 64-Bit Server VM (build 25.362-b09, mixed mode)
+
+ubuntu@5a99103747c6:~$ python -V
+Python 3.8.10
+
+ubuntu@5a99103747c6:~$ bazel version
+WARNING: Invoking Bazel in batch mode since it is not invoked from within a workspace (below a directory having a WORKSPACE file).
+Extracting Bazel installation...
+Build label: 6.2.1
+Build target: bazel-out/k8-opt/bin/src/main/java/com/google/devtools/build/lib/bazel/BazelServer_deploy.jar
+Build time: Fri Jun 2 16:59:58 2023 (1685725198)
+Build timestamp: 1685725198
+Build timestamp as int: 1685725198
+```
+
+## Explore the Bazel Dockerfile {#explore-bazel-dockerfile}
+
+If you want to check how the Bazel Docker image is built, you can find its Dockerfile at [bazelbuild/continuous-integration/bazel/oci](https://github.com/bazelbuild/continuous-integration/tree/master/bazel/oci).
diff --git a/versions/9.1.0/install/ide.mdx b/versions/9.1.0/install/ide.mdx
new file mode 100644
index 00000000..a22ff004
--- /dev/null
+++ b/versions/9.1.0/install/ide.mdx
@@ -0,0 +1,127 @@
+---
+title: 'Integrating Bazel with IDEs'
+---
+
+This page covers how to integrate Bazel with IDEs, such as IntelliJ, Android
+Studio, and CLion (or build your own IDE plugin). It also includes links to
+installation and plugin details.
+
+IDEs integrate with Bazel in a variety of ways, from features that allow Bazel
+executions from within the IDE, to awareness of Bazel structures such as syntax
+highlighting of the `BUILD` files.
+
+If you are interested in developing an editor or IDE plugin for Bazel, please
+join the `#ide` channel on the [Bazel Slack](https://slack.bazel.build) or start
+a discussion on [GitHub](https://github.com/bazelbuild/bazel/discussions).
+
+## IDEs and editors {#ides-editors}
+
+### IntelliJ, Android Studio, and CLion {#intellij-android-clion}
+
+[Official plugin](http://ij.bazel.build) for IntelliJ, Android Studio, and
+CLion. The plugin is [open source](https://github.com/bazelbuild/intellij).
+
+This is the open source version of the plugin used internally at Google.
+
+Features:
+
+* Interop with language-specific plugins. Supported languages include Java,
+  Scala, and Python.
+* Import `BUILD` files into the IDE with semantic awareness of Bazel targets.
+* Make your IDE aware of Starlark, the language used for Bazel's `BUILD` and
+  `.bzl`files
+* Build, test, and execute binaries directly from the IDE
+* Create configurations for debugging and running binaries.
+
+To install, go to the IDE's plugin browser and search for `Bazel`.
+
+To manually install older versions, download the zip files from JetBrains'
+Plugin Repository and install the zip file from the IDE's plugin browser:
+
+*  [Android Studio
+   plugin](https://plugins.jetbrains.com/plugin/9185-android-studio-with-bazel)
+*  [IntelliJ
+   plugin](https://plugins.jetbrains.com/plugin/8609-intellij-with-bazel)
+*  [CLion plugin](https://plugins.jetbrains.com/plugin/9554-clion-with-bazel)
+
+### Xcode {#xcode}
+
+[rules_xcodeproj](https://github.com/buildbuddy-io/rules_xcodeproj),
+[Tulsi](https://tulsi.bazel.build), and
+[XCHammer](https://github.com/pinterest/xchammer) generate Xcode
+projects from Bazel `BUILD` files.
+
+### Visual Studio Code {#visual-studio-code}
+
+Official plugin for VS Code.
+
+Features:
+
+* Bazel Build Targets tree
+* Starlark debugger for `.bzl` files during a build (set breakpoints, step
+  through code, inspect variables, and so on)
+
+Find [the plugin on the Visual Studio
+marketplace](https://marketplace.visualstudio.com/items?itemName=BazelBuild.vscode-bazel)
+or the [OpenVSX marketplace](https://open-vsx.org/extension/BazelBuild/vscode-bazel).
+The plugin is [open source](https://github.com/bazelbuild/vscode-bazel).
+
+See also: [Autocomplete for Source Code](#autocomplete-for-source-code)
+
+### Atom {#atom}
+
+Find the [`language-bazel` package](https://atom.io/packages/language-bazel)
+on the Atom package manager.
+
+See also: [Autocomplete for Source Code](#autocomplete-for-source-code)
+
+### Vim {#vim}
+
+See [`bazelbuild/vim-bazel` on GitHub](https://github.com/bazelbuild/vim-bazel)
+
+See also: [Autocomplete for Source Code](#autocomplete-for-source-code)
+
+### Emacs {#emacs}
+
+See [`bazelbuild/bazel-emacs-mode` on
+GitHub](https://github.com/bazelbuild/emacs-bazel-mode)
+
+See also: [Autocomplete for Source Code](#autocomplete-for-source-code)
+
+### Visual Studio {#visual-studio}
+
+[Lavender](https://github.com/tmandry/lavender) is an experimental project for
+generating Visual Studio projects that use Bazel for building.
+
+### Eclipse {#eclipse}
+
+[Bazel Eclipse Feature](https://github.com/salesforce/bazel-eclipse)
+is a set of plugins for importing Bazel packages into an Eclipse workspace as
+Eclipse projects.
+
+## Autocomplete for Source Code {#autocomplete-for-source-code}
+
+### C Language Family (C++, C, Objective-C, Objective-C++, and CUDA)
+
+[`kiron1/bazel-compile-commands`](https://github.com/kiron1/bazel-compile-commands)
+run `bazel-compile-commands //...` in a Bazel workspace to generate a `compile_commands.json` file.
+The `compile_commands.json` file enables tools like `clang-tidy`, `clangd` (LSP) and other IDEs to
+provide autocomplete, smart navigation, quick fixes, and more. The tool is written in C++ and
+consumes the Protobuf output of Bazel to extract the compile commands.
+
+[`hedronvision/bazel-compile-commands-extractor`](https://github.com/hedronvision/bazel-compile-commands-extractor) enables autocomplete, smart navigation, quick fixes, and more in a wide variety of extensible editors, including VSCode, Vim, Emacs, Atom, and Sublime. It lets language servers, like clangd and ccls, and other types of tooling, draw upon Bazel's understanding of how `cc` and `objc` code will be compiled, including how it configures cross-compilation for other platforms.
+
+### Java
+
+[`georgewfraser/java-language-server`](https://github.com/georgewfraser/java-language-server) - Java Language Server (LSP) with support for Bazel-built projects
+
+## Automatically run build and test on file change {#bazel-watcher}
+
+[Bazel watcher](https://github.com/bazelbuild/bazel-watcher) is a
+tool for building Bazel targets when source files change.
+
+## Building your own IDE plugin {#build-own-plugin}
+
+Read the [**IDE support** blog
+post](https://blog.bazel.build/2016/06/10/ide-support.html) to learn more about
+the Bazel APIs to use when building an IDE plugin.
diff --git a/versions/9.1.0/install/index.mdx b/versions/9.1.0/install/index.mdx
new file mode 100644
index 00000000..2a9128e0
--- /dev/null
+++ b/versions/9.1.0/install/index.mdx
@@ -0,0 +1,34 @@
+---
+title: 'Installing Bazel'
+---
+
+This page describes the various platforms supported by Bazel and links
+to the packages for more details.
+
+[Bazelisk](/versions/9.1.0/install/bazelisk) is the recommended way to install Bazel on [Ubuntu Linux](/versions/9.1.0/install/ubuntu), [macOS](/versions/9.1.0/install/os-x), and [Windows](/versions/9.1.0/install/windows).
+
+You can find available Bazel releases on our [release page](/versions/9.1.0/release).
+
+## Community-supported packages {#community-supported-packages}
+
+Bazel community members maintain these packages. The Bazel team doesn't
+officially support them. Contact the package maintainers for support.
+
+*   [Alpine Linux](https://pkgs.alpinelinux.org/packages?name=bazel*&branch=edge&repo=&arch=&origin=&flagged=&maintainer=)
+*   [Arch Linux][arch]
+*   [Debian](https://qa.debian.org/developer.php?email=team%2Bbazel%40tracker.debian.org)
+*   [Fedora](https://copr.fedorainfracloud.org/coprs/lihaohong/bazel)
+*   [FreeBSD](https://www.freshports.org/devel/bazel)
+*   [Homebrew](https://formulae.brew.sh/formula/bazel)
+*   [Nixpkgs](https://github.com/NixOS/nixpkgs/blob/master/pkgs/development/tools/build-managers/bazel)
+*   [openSUSE](/versions/9.1.0/install/suse)
+*   [Scoop](https://github.com/scoopinstaller/scoop-main/blob/master/bucket/bazel.json)
+*   [Raspberry Pi](https://github.com/koenvervloesem/bazel-on-arm/blob/master/README.md)
+
+## Community-supported architectures {#community-supported-architectures}
+
+*   [ppc64el](https://ftp2.osuosl.org/pub/ppc64el/bazel/)
+
+For other platforms, you can try to [compile from source](/versions/9.1.0/install/compile-source).
+
+[arch]: https://archlinux.org/packages/extra/x86_64/bazel/
diff --git a/versions/9.1.0/install/os-x.mdx b/versions/9.1.0/install/os-x.mdx
new file mode 100644
index 00000000..42aa5d9d
--- /dev/null
+++ b/versions/9.1.0/install/os-x.mdx
@@ -0,0 +1,139 @@
+---
+title: 'Installing Bazel on macOS'
+---
+
+This page describes how to install Bazel on macOS and set up your environment.
+
+You can install Bazel on macOS using one of the following methods:
+
+*   *Recommended*: [Use Bazelisk](/versions/9.1.0/install/bazelisk)
+*   [Use Homebrew](#install-on-mac-os-x-homebrew)
+*   [Use the binary installer](#install-with-installer-mac-os-x)
+*   [Compile Bazel from source](/versions/9.1.0/install/compile-source)
+
+Bazel comes with two completion scripts. After installing Bazel, you can:
+
+*   Access the [bash completion script](/versions/9.1.0/install/completion#bash)
+*   Install the [zsh completion script](/versions/9.1.0/install/completion#zsh)
+
+
Installing using Homebrew

+
+### Step 1: Install Homebrew on macOS
+
+Install [Homebrew](https://brew.sh/) (a one-time step):
+
+```posix-terminal
+/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"
+```
+
+### Step 2: Install Bazel via Homebrew
+
+Install the Bazel package via Homebrew as follows:
+
+```posix-terminal
+brew install bazel
+```
+
+All set! You can confirm Bazel is installed successfully by running the
+following command:
+
+```posix-terminal
+bazel --version
+```
+
+Once installed, you can upgrade to a newer version of Bazel using the
+following command:
+
+```posix-terminal
+brew upgrade bazel
+```
+
+
Installing using the binary installer

+
+The binary installers are on Bazel's
+[GitHub releases page](https://github.com/bazelbuild/bazel/releases).
+
+The installer contains the Bazel binary. Some additional libraries
+must also be installed for Bazel to work.
+
+### Step 1: Install Xcode command line tools
+
+If you don't intend to use `ios_*` rules, it is sufficient to install the Xcode
+command line tools package by using `xcode-select`:
+
+```posix-terminal
+xcode-select --install
+```
+
+Otherwise, for `ios_*` rule support, you must have Xcode 6.1 or later with iOS
+SDK 8.1 installed on your system.
+
+Download Xcode from the
+[App Store](https://apps.apple.com/us/app/xcode/id497799835) or the
+[Apple Developer site](https://developer.apple.com/download/more/?=xcode).
+
+Once Xcode is installed, accept the license agreement for all users with the
+following command:
+
+```posix-terminal
+sudo xcodebuild -license accept
+```
+
+### Step 2: Download the Bazel installer
+
+Next, download the Bazel binary installer named
+`bazel--installer-darwin-x86_64.sh` from the
+[Bazel releases page on GitHub](https://github.com/bazelbuild/bazel/releases).
+
+**On macOS Catalina or newer (macOS >= 11)**, due to Apple's new app signing requirements,
+you need to download the installer from the terminal using `curl`, replacing
+the version variable with the Bazel version you want to download:
+
+```posix-terminal
+export BAZEL_VERSION=5.2.0
+
+curl -fLO "https://github.com/bazelbuild/bazel/releases/download/`$BAZEL_VERSION`/bazel-`$BAZEL_VERSION`-installer-darwin-x86_64.sh"
+```
+
+This is a temporary workaround until the macOS release flow supports
+signing ([#9304](https://github.com/bazelbuild/bazel/issues/9304)).
+
+### Step 3: Run the installer
+
+Run the Bazel installer as follows:
+
+```posix-terminal
+chmod +x "bazel-`$BAZEL_VERSION`-installer-darwin-x86_64.sh"
+
+./bazel-`$BAZEL_VERSION`-installer-darwin-x86_64.sh --user
+```
+
+The `--user` flag installs Bazel to the `$HOME/bin` directory on your system and
+sets the `.bazelrc` path to `$HOME/.bazelrc`. Use the `--help` command to see
+additional installation options.
+
+If you are **on macOS Catalina or newer (macOS >= 11)** and get an error that _**“bazel-real” cannot be
+opened because the developer cannot be verified**_, you need to re-download
+the installer from the terminal using `curl` as a workaround; see Step 2 above.
+
+### Step 4: Set up your environment
+
+If you ran the Bazel installer with the `--user` flag as above, the Bazel
+executable is installed in your `$HOME/bin` directory.
+It's a good idea to add this directory to your default paths, as follows:
+
+```posix-terminal
+export PATH="`PATH`:`HOME`/bin"
+```
+
+You can also add this command to your `~/.bashrc`, `~/.zshrc`, or `~/.profile`
+file.
+
+All set! You can confirm Bazel is installed successfully by running the
+following command:
+
+```posix-terminal
+bazel --version
+```
+To update to a newer release of Bazel, download and install the desired version.
+
diff --git a/versions/9.1.0/install/suse.mdx b/versions/9.1.0/install/suse.mdx
new file mode 100644
index 00000000..703fcb22
--- /dev/null
+++ b/versions/9.1.0/install/suse.mdx
@@ -0,0 +1,33 @@
+---
+title: 'Installing Bazel on openSUSE Tumbleweed & Leap'
+---
+
+This page describes how to install Bazel on openSUSE Tumbleweed and Leap.
+
+`NOTE:` The Bazel team does not officially maintain openSUSE support. For issues
+using Bazel on openSUSE please file a ticket at [bugzilla.opensuse.org](https://bugzilla.opensuse.org/).
+
+Packages are provided for openSUSE Tumbleweed and Leap. You can find all
+available Bazel versions via openSUSE's [software search](https://software.opensuse.org/search?utf8=%E2%9C%93&baseproject=ALL&q=bazel).
+
+The commands below must be run either via `sudo` or while logged in as `root`.
+
+## Installing Bazel on openSUSE {#install-opensuse}
+
+Run the following commands to install the package. If you need a specific
+version, you can install it via the specific `bazelXXX` package, otherwise,
+just `bazel` is enough:
+
+To install the latest version of Bazel, run:
+
+```posix-terminal
+zypper install bazel
+```
+
+You can also install a specific version of Bazel by specifying the package
+version with `bazelVERSION`. For example, to install
+Bazel 4.2, run:
+
+```posix-terminal
+zypper install bazel4.2
+```
diff --git a/versions/9.1.0/install/ubuntu.mdx b/versions/9.1.0/install/ubuntu.mdx
new file mode 100644
index 00000000..fdbc26ef
--- /dev/null
+++ b/versions/9.1.0/install/ubuntu.mdx
@@ -0,0 +1,164 @@
+---
+title: 'Installing Bazel on Ubuntu'
+---
+
+This page describes the options for installing Bazel on Ubuntu.
+It also provides links to the Bazel completion scripts and the binary installer,
+if needed as a backup option (for example, if you don't have admin access).
+
+Supported Ubuntu Linux platforms:
+
+*   22.04 (LTS)
+*   20.04 (LTS)
+*   18.04 (LTS)
+
+Bazel should be compatible with other Ubuntu releases and Debian
+"stretch" and above, but is untested and not guaranteed to work.
+
+Install Bazel on Ubuntu using one of the following methods:
+
+*   *Recommended*: [Use Bazelisk](/versions/9.1.0/install/bazelisk)
+*   [Use our custom APT repository](#install-on-ubuntu)
+*   [Use the binary installer](#binary-installer)
+*   [Use the Bazel Docker container](#docker-container)
+*   [Compile Bazel from source](/versions/9.1.0/install/compile-source)
+
+**Note:** For Arm-based systems, the APT repository does not contain an `arm64`
+release, and there is no binary installer available. Either use Bazelisk or
+compile from source.
+
+Bazel comes with two completion scripts. After installing Bazel, you can:
+
+*   Access the [bash completion script](/versions/9.1.0/install/completion#bash)
+*   Install the [zsh completion script](/versions/9.1.0/install/completion#zsh)
+
+## Using Bazel's apt repository {#install-on-ubuntu}
+
+### Step 1: Add Bazel distribution URI as a package source {#add-dis-uri}
+
+**Note:** This is a one-time setup step.
+
+```posix-terminal
+sudo apt install apt-transport-https curl gnupg -y
+
+curl -fsSL https://bazel.build/bazel-release.pub.gpg | gpg --dearmor >bazel-archive-keyring.gpg
+
+sudo mv bazel-archive-keyring.gpg /usr/share/keyrings
+
+echo "deb [arch=amd64 signed-by=/usr/share/keyrings/bazel-archive-keyring.gpg] https://storage.googleapis.com/bazel-apt stable jdk1.8" | sudo tee /etc/apt/sources.list.d/bazel.list
+```
+
+The component name "jdk1.8" is kept only for legacy reasons and doesn't relate
+to supported or included JDK versions. Bazel releases are Java-version agnostic.
+Changing the "jdk1.8" component name would break existing users of the repo.
+
+### Step 2: Install and update Bazel {#install-bazel}
+
+```posix-terminal
+sudo apt update && sudo apt install bazel
+```
+
+Once installed, you can upgrade to a newer version of Bazel as part of your normal system updates:
+
+```posix-terminal
+sudo apt update && sudo apt full-upgrade
+```
+
+The `bazel` package always installs the latest stable version of Bazel. You
+can install specific, older versions of Bazel in addition to the latest one,
+such as this:
+
+```posix-terminal
+sudo apt install bazel-1.0.0
+```
+
+This installs Bazel 1.0.0 as `/usr/bin/bazel-1.0.0` on your system. This
+can be useful if you need a specific version of Bazel to build a project, for
+example because it uses a `.bazelversion` file to explicitly state with which
+Bazel version it should be built.
+
+Optionally, you can set `bazel` to a specific version by creating a symlink:
+
+```posix-terminal
+sudo ln -s /usr/bin/bazel-1.0.0 /usr/bin/bazel
+
+bazel --version  # 1.0.0
+```
+
+### Step 3: Install a JDK (optional) {#install-jdk}
+
+Bazel includes a private, bundled JRE as its runtime and doesn't require you to
+install any specific version of Java.
+
+However, if you want to build Java code using Bazel, you have to install a JDK.
+
+```posix-terminal
+sudo apt install default-jdk
+```
+
+## Using the binary installer {#binary-installer}
+
+Generally, you should use the apt repository, but the binary installer
+can be useful if you don't have admin permissions on your machine or
+can't add custom repositories.
+
+The binary installers can be downloaded from Bazel's [GitHub releases page](https://github.com/bazelbuild/bazel/releases).
+
+The installer contains the Bazel binary and extracts it into your `$HOME/bin`
+folder. Some additional libraries must be installed manually for Bazel to work.
+
+### Step 1: Install required packages {#install-packages}
+
+Bazel needs a C++ compiler and unzip / zip in order to work:
+
+```posix-terminal
+sudo apt install g++ unzip zip
+```
+
+If you want to build Java code using Bazel, install a JDK:
+
+```posix-terminal
+sudo apt-get install default-jdk
+```
+
+### Step 2: Run the installer {#run-installer}
+
+Next, download the Bazel binary installer named `bazel-VERSION-installer-linux-x86_64.sh`
+from the [Bazel releases page on GitHub](https://github.com/bazelbuild/bazel/releases).
+
+Run it as follows:
+
+```posix-terminal
+chmod +x bazel-`version`-installer-linux-x86_64.sh
+
+./bazel-`version`-installer-linux-x86_64.sh --user
+```
+
+The `--user` flag installs Bazel to the `$HOME/bin` directory on your system and
+sets the `.bazelrc` path to `$HOME/.bazelrc`. Use the `--help` command to see
+additional installation options.
+
+### Step 3: Set up your environment {#set-environment}
+
+If you ran the Bazel installer with the `--user` flag as above, the Bazel
+executable is installed in your `$HOME/bin` directory.
+It's a good idea to add this directory to your default paths, as follows:
+
+```posix-terminal
+export PATH="$PATH:$HOME/bin"
+```
+
+You can also add this command to your `~/.bashrc` or `~/.zshrc` file to make it
+permanent.
+
+## Using the Bazel Docker container {#docker-container}
+
+We publish Docker container with Bazel installed for each Bazel version at `gcr.io/bazel-public/bazel`.
+You can use the Docker container as follows:
+
+```
+$ docker pull gcr.io/bazel-public/bazel:
+```
+
+The Docker container is built by [these steps](https://github.com/bazelbuild/continuous-integration/tree/master/bazel/oci).
+
diff --git a/versions/9.1.0/install/windows.mdx b/versions/9.1.0/install/windows.mdx
new file mode 100644
index 00000000..14361fb0
--- /dev/null
+++ b/versions/9.1.0/install/windows.mdx
@@ -0,0 +1,235 @@
+---
+title: 'Installing Bazel on Windows'
+---
+
+This page describes the requirements and steps to install Bazel on Windows.
+It also includes troubleshooting and other ways to install Bazel, such as
+using Chocolatey or Scoop.
+
+## Installing Bazel {#installing-bazel}
+
+This section covers the prerequisites, environment setup, and detailed
+steps during installation on Windows.
+
+### Check your system {#check-system}
+
+Recommended: 64 bit Windows 10, version 1703 (Creators Update) or newer
+
+To check your Windows version:
+
+* Click the Start button.
+* Type `winver` in the search box and press Enter.
+* You should see the About Windows box with your Windows version information.
+
+### Install the prerequisites {#install-prerequisites}
+
+*   [Microsoft Visual C++ Redistributable](https://learn.microsoft.com/en-us/cpp/windows/latest-supported-vc-redist?view=msvc-170)
+
+### Download Bazel {#download-bazel}
+
+*Recommended*: [Use Bazelisk](/versions/9.1.0/install/bazelisk)
+
+Alternatively you can:
+
+*   [Download the Bazel binary (`bazel-VERSION-windows-x86_64.exe`) from
+ GitHub](https://github.com/bazelbuild/bazel/releases).
+*   [Install Bazel from Chocolatey](#chocolately)
+*   [Install Bazel from Scoop](#scoop)
+*   [Build Bazel from source](/versions/9.1.0/install/compile-source)
+
+### Set up your environment {#set-environment}
+
+To make Bazel easily accessible from command prompts or PowerShell by default, you can rename the Bazel binary to `bazel.exe` and add it to your default paths.
+
+```posix-terminal
+set PATH=%PATH%;`path to the Bazel binary`
+```
+
+You can also change your system `PATH` environment variable to make it permanent. Check out how to [set environment variables](/versions/9.1.0/configure/windows#set-environment-variables).
+
+### Done {#done}
+
+"Success: You've installed Bazel."
+
+To check the installation is correct, try to run:
+
+```posix-terminal
+bazel `version`
+```
+
+Next, you can check out more tips and guidance here:
+
+*   [Installing compilers and language runtimes](#install-compilers)
+*   [Troubleshooting](#troubleshooting)
+*   [Best practices on Windows](/versions/9.1.0/configure/windows#best-practices)
+*   [Tutorials](/versions/9.1.0/start/#tutorials)
+
+## Installing compilers and language runtimes {#install-compilers}
+
+Depending on which languages you want to build, you will need:
+
+*   [MSYS2 x86_64](https://www.msys2.org/)
+
+    MSYS2 is a software distro and building platform for Windows. It contains Bash and common Unix
+    tools (like `grep`, `tar`, `git`).
+
+    You will need MSYS2 to build, test, or run targets that depend on Bash. Typically these are
+    `genrule`, `sh_binary`, `sh_test`, but there may be more (such as Starlark rules). Bazel shows an
+    error if a build target needs Bash but Bazel could not locate it.
+
+*   Common MSYS2 packages
+
+    You will likely need these to build and run targets that depend on Bash. MSYS2 does not install
+    these tools by default, so you need to install them manually. Projects that depend on Bash tools in `PATH` need this step (for example TensorFlow).
+
+    Open the MSYS2 terminal and run this command:
+
+    ```posix-terminal
+    pacman -S zip unzip patch diffutils git
+    ```
+
+    Optional: If you want to use Bazel from CMD or Powershell and still be able
+    to use Bash tools, make sure to add
+    `MSYS2_INSTALL_PATH/usr/bin` to your
+    `PATH` environment variable.
+
+*   [Build Tools for Visual Studio 2019](https://aka.ms/buildtools)
+
+    You will need this to build C++ code on Windows.
+
+    Also supported:
+
+    *   Visual C++ Build Tools 2017 (or newer) and Windows 10 SDK
+
+*   [Java SE Development Kit 11 (JDK) for Windows x64](https://www.oracle.com/java/technologies/javase-jdk11-downloads.html)
+
+    You will need this to build Java code on Windows.
+
+    Also supported: Java 8, 9, and 10
+
+*   [Python 3.6 for Windows x86-64](https://www.python.org/downloads/windows/)
+
+    You will need this to build Python code on Windows.
+
+    Also supported: Python 2.7 or newer for Windows x86-64
+
+## Troubleshooting {#troubleshooting}
+
+### Bazel does not find Bash or bash.exe
+
+**Possible reasons**:
+
+*   you installed MSYS2 not under the default install path
+
+*   you installed MSYS2 i686 instead of MSYS2 x86\_64
+
+*   you installed MSYS instead of MSYS2
+
+**Solution**:
+
+Ensure you installed MSYS2 x86\_64.
+
+If that doesn't help:
+
+1.  Go to Start Menu > Settings.
+
+2.  Find the setting "Edit environment variables for your account"
+
+3.  Look at the list on the top ("User variables for <username>"), and click the "New..."
+    button below it.
+
+4.  For "Variable name", enter `BAZEL_SH`
+
+5.  Click "Browse File..."
+
+6.  Navigate to the MSYS2 directory, then to `usr\bin` below it.
+
+    For example, this might be `C:\msys64\usr\bin` on your system.
+
+7.  Select the `bash.exe` or `bash` file and click OK
+
+8.  The "Variable value" field now has the path to `bash.exe`. Click OK to close the window.
+
+9.  Done.
+
+    If you open a new cmd.exe or PowerShell terminal and run Bazel now, it will find Bash.
+
+### Bazel does not find Visual Studio or Visual C++
+
+**Possible reasons**:
+
+*   you installed multiple versions of Visual Studio
+
+*   you installed and removed various versions of Visual Studio
+
+*   you installed various versions of the Windows SDK
+
+*   you installed Visual Studio not under the default install path
+
+**Solution**:
+
+1.  Go to Start Menu > Settings.
+
+2.  Find the setting "Edit environment variables for your account"
+
+3.  Look at the list on the top ("User variables for <username>"), and click the "New..."
+    button below it.
+
+4.  For "Variable name", enter `BAZEL_VC`
+
+5.  Click "Browse Directory..."
+
+6.  Navigate to the `VC` directory of Visual Studio.
+
+    For example, this might be `C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC`
+    on your system.
+
+7.  Select the `VC` folder and click OK
+
+8.  The "Variable value" field now has the path to `VC`. Click OK to close the window.
+
+9.  Done.
+
+    If you open a new cmd.exe or PowerShell terminal and run Bazel now, it will find Visual C++.
+
+## Other ways to install Bazel {#install-options}
+
+### Using Chocolatey {#chocolately}
+
+1.  Install the [Chocolatey](https://chocolatey.org) package manager
+
+2.  Install the Bazel package:
+
+    ```posix-terminal
+    choco install bazel
+    ```
+
+    This command will install the latest available version of Bazel and
+    its dependencies, such as the MSYS2 shell. This will not install Visual C++
+    though.
+
+See [Chocolatey installation and package maintenance
+guide](/versions/9.1.0/contribute/windows-chocolatey-maintenance) for more
+information about the Chocolatey package.
+
+### Using Scoop {#scoop}
+
+1.  Install the [Scoop](https://scoop.sh/) package manager using the following PowerShell command:
+
+    ```posix-terminal
+    iex (new-object net.webclient).downloadstring('https://get.scoop.sh')
+    ```
+
+2.  Install the Bazel package:
+
+    ```posix-terminal
+    scoop install bazel
+    ```
+
+See [Scoop installation and package maintenance
+guide](/versions/9.1.0/contribute/windows-scoop-maintenance) for more
+information about the Scoop package.
+
+### Build from source {#build-from-source}
+
+To build Bazel from scratch instead of installing, see [Compiling from source](/versions/9.1.0/install/compile-source).
diff --git a/versions/9.1.0/migrate/index.mdx b/versions/9.1.0/migrate/index.mdx
new file mode 100644
index 00000000..b558e875
--- /dev/null
+++ b/versions/9.1.0/migrate/index.mdx
@@ -0,0 +1,8 @@
+---
+title: 'Migrating to Bazel'
+---
+
+This page links to migration guides for Bazel.
+
+*  [Maven](/versions/9.1.0/migrate/maven)
+*  [Xcode](/versions/9.1.0/migrate/xcode)
diff --git a/versions/9.1.0/migrate/maven.mdx b/versions/9.1.0/migrate/maven.mdx
new file mode 100644
index 00000000..cec426c9
--- /dev/null
+++ b/versions/9.1.0/migrate/maven.mdx
@@ -0,0 +1,239 @@
+---
+title: 'Migrating from Maven to Bazel'
+---
+
+This page describes how to migrate from Maven to Bazel, including the
+prerequisites and installation steps. It describes the differences between Maven
+and Bazel, and provides a migration example using the Guava project.
+
+When migrating from any build tool to Bazel, it's best to have both build tools
+running in parallel until you have fully migrated your development team, CI
+system, and any other relevant systems. You can run Maven and Bazel in the same
+repository.
+
+Note: While Bazel supports downloading and publishing Maven artifacts with
+[rules_jvm_external](https://github.com/bazelbuild/rules_jvm_external){: .external}
+, it does not directly support Maven-based plugins. Maven plugins can't be
+directly run by Bazel since there's no Maven compatibility layer.
+
+## Before you begin {:#before-you-begin}
+
+*   [Install Bazel](/versions/9.1.0/install) if it's not yet installed.
+*   If you're new to Bazel, go through the tutorial [Introduction to Bazel:
+    Build Java](/versions/9.1.0/start/java) before you start migrating. The tutorial explains
+    Bazel's concepts, structure, and label syntax.
+
+## Differences between Maven and Bazel {:#dif-maven-bazel}
+
+*   Maven uses top-level `pom.xml` file(s). Bazel supports multiple build files
+    and multiple targets per `BUILD` file, allowing for builds that are more
+    incremental than Maven's.
+*   Maven takes charge of steps for the deployment process. Bazel does not
+    automate deployment.
+*   Bazel enables you to express dependencies between languages.
+*   As you add new sections to the project, with Bazel you may need to add new
+    `BUILD` files. Best practice is to add a `BUILD` file to each new Java
+    package.
+
+## Migrate from Maven to Bazel {:#migrate-maven-bazel}
+
+The steps below describe how to migrate your project to Bazel:
+
+1.  [Create the MODULE.bazel file](#1-build)
+2.  [Create one BUILD file](#2-build)
+3.  [Create more BUILD files](#3-build)
+4.  [Build using Bazel](#4-build)
+
+Examples below come from a migration of the [Guava
+project](https://github.com/google/guava){: .external} from Maven to Bazel. The
+Guava project used is release `v31.1`. The examples using Guava do not walk
+through each step in the migration, but they do show the files and contents that
+are generated or added manually for the migration.
+
+```
+$ git clone https://github.com/google/guava.git && cd guava
+$ git checkout v31.1
+```
+
+### 1. Create the MODULE.bazel file {:#1-build}
+
+Create a file named `MODULE.bazel` at the root of your project. If your project
+has no external dependencies, this file can be empty.
+
+If your project depends on files or packages that are not in one of the
+project's directories, specify these external dependencies in the MODULE.bazel
+file. You can use `rules_jvm_external` to manage dependencies from Maven. For
+instructions about using this ruleset, see [the
+README](https://github.com/bazelbuild/rules_jvm_external/#rules_jvm_external){: .external}
+.
+
+#### Guava project example: external dependencies {:#guava-1}
+
+You can list the external dependencies of the [Guava
+project](https://github.com/google/guava){: .external} with the
+[`rules_jvm_external`](https://github.com/bazelbuild/rules_jvm_external){: .external}
+ruleset.
+
+Add the following snippet to the `MODULE.bazel` file:
+
+```python
+bazel_dep(name = "rules_jvm_external", version = "6.2")
+maven = use_extension("@rules_jvm_external//:extensions.bzl", "maven")
+maven.install(
+    artifacts = [
+        "com.google.code.findbugs:jsr305:3.0.2",
+        "com.google.errorprone:error_prone_annotations:2.11.0",
+        "com.google.j2objc:j2objc-annotations:1.3",
+        "org.codehaus.mojo:animal-sniffer-annotations:1.20",
+        "org.checkerframework:checker-qual:3.12.0",
+    ],
+    repositories = [
+        "https://repo1.maven.org/maven2",
+    ],
+)
+use_repo(maven, "maven")
+```
+
+### 2. Create one BUILD file {:#2-build}
+
+Now that you have your workspace defined and external dependencies (if
+applicable) listed, you need to create `BUILD` files to describe how your
+project should be built. Unlike Maven with its one `pom.xml` file, Bazel can use
+many `BUILD` files to build a project. These files specify multiple build
+targets, which allow Bazel to produce incremental builds.
+
+Add `BUILD` files in stages. Start with adding one `BUILD` file at the root of
+your project and using it to do an initial build using Bazel. Then, you refine
+your build by adding more `BUILD` files with more granular targets.
+
+1.  In the same directory as your `MODULE.bazel` file, create a text file and
+    name it `BUILD`.
+
+2.  In this `BUILD` file, use the appropriate rule to create one target to build
+    your project. Here are some tips:
+
+    *   Use the appropriate rule:
+        *   To build projects with a single Maven module, use the
+            `java_library` rule as follows:
+
+            ```python
+            java_library(
+               name = "everything",
+               srcs = glob(["src/main/java/**/*.java"]),
+               resources = glob(["src/main/resources/**"]),
+               deps = ["//:all-external-targets"],
+            )
+            ```
+
+        *   To build projects with multiple Maven modules, use the
+            `java_library` rule as follows:
+
+            ```python
+            java_library(
+               name = "everything",
+               srcs = glob([
+                     "Module1/src/main/java/**/*.java",
+                     "Module2/src/main/java/**/*.java",
+                     ...
+               ]),
+               resources = glob([
+                     "Module1/src/main/resources/**",
+                     "Module2/src/main/resources/**",
+                     ...
+               ]),
+               deps = ["//:all-external-targets"],
+            )
+            ```
+
+        *   To build binaries, use the `java_binary` rule:
+
+            ```python
+            java_binary(
+               name = "everything",
+               srcs = glob(["src/main/java/**/*.java"]),
+               resources = glob(["src/main/resources/**"]),
+               deps = ["//:all-external-targets"],
+               main_class = "com.example.Main"
+            )
+            ```
+
+        *   Specify the attributes:
+            *   `name`: Give the target a meaningful name. In the examples
+                above, the target is called "everything."
+            *   `srcs`: Use globbing to list all .java files in your project.
+            *   `resources`: Use globbing to list all resources in your project.
+            *   `deps`: You need to determine which external dependencies your
+                project needs.
+        *   Take a look at the [example below of this top-level BUILD
+            file](#guava-2) from the migration of the Guava project.
+
+3.  Now that you have a `BUILD` file at the root of your project, build your
+    project to ensure that it works. On the command line, from your workspace
+    directory, use `bazel build //:everything` to build your project with Bazel.
+
+    The project has now been successfully built with Bazel. You will need to add
+    more `BUILD` files to allow incremental builds of the project.
+
+#### Guava project example: start with one BUILD file {:#guava-2}
+
+When migrating the Guava project to Bazel, initially one `BUILD` file is used to
+build the entire project. Here are the contents of this initial `BUILD` file in
+the workspace directory:
+
+```python
+java_library(
+    name = "everything",
+    srcs = glob([
+        "guava/src/**/*.java",
+        "futures/failureaccess/src/**/*.java",
+    ]),
+    javacopts = ["-XepDisableAllChecks"],
+    deps = [
+        "@maven//:com_google_code_findbugs_jsr305",
+        "@maven//:com_google_errorprone_error_prone_annotations",
+        "@maven//:com_google_j2objc_j2objc_annotations",
+        "@maven//:org_checkerframework_checker_qual",
+        "@maven//:org_codehaus_mojo_animal_sniffer_annotations",
+    ],
+)
+```
+
+### 3. Create more BUILD files (optional) {:#3-build}
+
+Bazel does work with just one `BUILD file`, as you saw after completing your
+first build. You should still consider breaking the build into smaller chunks by
+adding more `BUILD` files with granular targets.
+
+Multiple `BUILD` files with multiple targets will give the build increased
+granularity, allowing:
+
+*   increased incremental builds of the project,
+*   increased parallel execution of the build,
+*   better maintainability of the build for future users, and
+*   control over visibility of targets between packages, which can prevent
+    issues such as libraries containing implementation details leaking into
+    public APIs.
+
+Tips for adding more `BUILD` files:
+
+*   You can start by adding a `BUILD` file to each Java package. Start with Java
+    packages that have the fewest dependencies and work you way up to packages
+    with the most dependencies.
+*   As you add `BUILD` files and specify targets, add these new targets to the
+    `deps` sections of targets that depend on them. Note that the `glob()`
+    function does not cross package boundaries, so as the number of packages
+    grows the files matched by `glob()` will shrink.
+*   Any time you add a `BUILD` file to a `main` directory, ensure that you add a
+    `BUILD` file to the corresponding `test` directory.
+*   Take care to limit visibility properly between packages.
+*   To simplify troubleshooting errors in your setup of `BUILD` files, ensure
+    that the project continues to build with Bazel as you add each build file.
+    Run `bazel build //...` to ensure all of your targets still build.
+
+### 4. Build using Bazel {:#4-build}
+
+You've been building using Bazel as you add `BUILD` files to validate the setup
+of the build.
+
+When you have `BUILD` files at the desired granularity, you can use Bazel to
+produce all of your builds.
\ No newline at end of file
diff --git a/versions/9.1.0/migrate/xcode.mdx b/versions/9.1.0/migrate/xcode.mdx
new file mode 100644
index 00000000..4538fe87
--- /dev/null
+++ b/versions/9.1.0/migrate/xcode.mdx
@@ -0,0 +1,278 @@
+---
+title: 'Migrating from Xcode to Bazel'
+---
+
+This page describes how to build or test an Xcode project with Bazel. It
+describes the differences between Xcode and Bazel, and provides the steps for
+converting an Xcode project to a Bazel project. It also provides troubleshooting
+solutions to address common errors.
+
+## Differences between Xcode and Bazel {:#dif-xcode-bazel}
+
+*   Bazel requires you to explicitly specify every build target and its
+    dependencies, plus the corresponding build settings via build rules.
+
+*   Bazel requires all files on which the project depends to be present within
+    the workspace directory or specified as dependencies in the `MODULE.bazel`
+    file.
+
+*   When building Xcode projects with Bazel, the `BUILD` file(s) become the
+    source of truth. If you work on the project in Xcode, you must generate a
+    new version of the Xcode project that matches the `BUILD` files using
+    [rules_xcodeproj](https://github.com/buildbuddy-io/rules_xcodeproj/){: .external}
+    whenever you update the `BUILD` files. Certain changes to the `BUILD` files
+    such as adding dependencies to a target don't require regenerating the
+    project which can speed up development. If you're not using Xcode, the
+    `bazel build` and `bazel test` commands provide build and test capabilities
+    with certain limitations described later in this guide.
+
+## Before you begin {:#before-you-begin}
+
+Before you begin, do the following:
+
+1.  [Install Bazel](/versions/9.1.0/install) if you have not already done so.
+
+2.  If you're not familiar with Bazel and its concepts, complete the [iOS app
+    tutorial](/versions/9.1.0/start/ios-app)). You should understand the Bazel workspace,
+    including the `MODULE.bazel` and `BUILD` files, as well as the concepts of
+    targets, build rules, and Bazel packages.
+
+3.  Analyze and understand the project's dependencies.
+
+### Analyze project dependencies {:#analyze-project-dependencies}
+
+Unlike Xcode, Bazel requires you to explicitly declare all dependencies for
+every target in the `BUILD` file.
+
+For more information on external dependencies, see [Working with external
+dependencies](/versions/9.1.0/docs/external).
+
+## Build or test an Xcode project with Bazel {:#build-xcode-project}
+
+To build or test an Xcode project with Bazel, do the following:
+
+1.  [Create the `MODULE.bazel` file](#create-workspace)
+
+2.  [(Experimental) Integrate SwiftPM dependencies](#integrate-swiftpm)
+
+3.  [Create a `BUILD` file:](#create-build-file)
+
+    a.  [Add the application target](#add-app-target)
+
+    b.  [(Optional) Add the test target(s)](#add-test-target)
+
+    c.  [Add the library target(s)](#add-library-target)
+
+4.  [(Optional) Granularize the build](#granularize-build)
+
+5.  [Run the build](#run-build)
+
+6.  [Generate the Xcode project with rules_xcodeproj](#generate-the-xcode-project-with-rules_xcodeproj)
+
+### Step 1: Create the `MODULE.bazel` file {:#create-workspace}
+
+Create a `MODULE.bazel` file in a new directory. This directory becomes the
+Bazel workspace root. If the project uses no external dependencies, this file
+can be empty. If the project depends on files or packages that are not in one of
+the project's directories, specify these external dependencies in the
+`MODULE.bazel` file.
+
+Note: Place the project source code within the directory tree containing the
+`MODULE.bazel` file.
+
+### Step 2: (Experimental) Integrate SwiftPM dependencies {:#integrate-swiftpm}
+
+To integrate SwiftPM dependencies into the Bazel workspace with
+[swift_bazel](https://github.com/cgrindel/swift_bazel){: .external}, you must
+convert them into Bazel packages as described in the [following
+tutorial](https://chuckgrindel.com/swift-packages-in-bazel-using-swift_bazel/){: .external}
+.
+
+Note: SwiftPM support is a manual process with many variables. SwiftPM
+integration with Bazel has not been fully verified and is not officially
+supported.
+
+### Step 3: Create a `BUILD` file {:#create-build-file}
+
+Once you have defined the workspace and external dependencies, you need to
+create a `BUILD` file that tells Bazel how the project is structured. Create the
+`BUILD` file at the root of the Bazel workspace and configure it to do an
+initial build of the project as follows:
+
+*   [Step 3a: Add the application target](#step-3a-add-the-application-target)
+*   [Step 3b: (Optional) Add the test target(s)](#step-3b-optional-add-the-test-target-s)
+*   [Step 3c: Add the library target(s)](#step-3c-add-the-library-target-s)
+
+**Tip:** To learn more about packages and other Bazel concepts, see [Workspaces,
+packages, and targets](/versions/9.1.0/concepts/build-ref).
+
+#### Step 3a: Add the application target {:#add-app-target}
+
+Add a
+[`macos_application`](https://github.com/bazelbuild/rules_apple/blob/master/doc/rules-macos.md#macos_application){: .external}
+or an
+[`ios_application`](https://github.com/bazelbuild/rules_apple/blob/master/doc/rules-ios.md#ios_application){: .external}
+rule target. This target builds a macOS or iOS application bundle, respectively.
+In the target, specify the following at the minimum:
+
+*   `bundle_id` - the bundle ID (reverse-DNS path followed by app name) of the
+    binary.
+
+*   `provisioning_profile` - provisioning profile from your Apple Developer
+    account (if building for an iOS device device).
+
+*   `families` (iOS only) - whether to build the application for iPhone, iPad,
+    or both.
+
+*   `infoplists` - list of .plist files to merge into the final Info.plist file.
+
+*   `minimum_os_version` - the minimum version of macOS or iOS that the
+    application supports. This ensures Bazel builds the application with the
+    correct API levels.
+
+#### Step 3b: (Optional) Add the test target(s) {:#add-test-target}
+
+Bazel's [Apple build
+rules](https://github.com/bazelbuild/rules_apple){: .external} support running
+unit and UI tests on all Apple platforms. Add test targets as follows:
+
+*   [`macos_unit_test`](https://github.com/bazelbuild/rules_apple/blob/master/doc/rules-macos.md#macos_unit_test){: .external}
+    to run library-based and application-based unit tests on a macOS.
+
+*   [`ios_unit_test`](https://github.com/bazelbuild/rules_apple/blob/master/doc/rules-ios.md#ios_unit_test){: .external}
+    to build and run library-based unit tests on iOS.
+
+*   [`ios_ui_test`](https://github.com/bazelbuild/rules_apple/blob/master/doc/rules-ios.md#ios_ui_test){: .external}
+    to build and run user interface tests in the iOS simulator.
+
+*   Similar test rules exist for
+    [tvOS](https://github.com/bazelbuild/rules_apple/blob/master/doc/rules-tvos.md){: .external},
+    [watchOS](https://github.com/bazelbuild/rules_apple/blob/master/doc/rules-watchos.md){: .external}
+    and
+    [visionOS](https://github.com/bazelbuild/rules_apple/blob/master/doc/rules-visionos.md){: .external}.
+
+At the minimum, specify a value for the `minimum_os_version` attribute. While
+other packaging attributes, such as `bundle_identifier` and `infoplists`,
+default to most commonly used values, ensure that those defaults are compatible
+with the project and adjust them as necessary. For tests that require the iOS
+simulator, also specify the `ios_application` target name as the value of the
+`test_host` attribute.
+
+#### Step 3c: Add the library target(s) {:#add-library-target}
+
+Add an [`objc_library`](/versions/9.1.0/reference/be/objective-c#objc_library) target for each
+Objective-C library and a
+[`swift_library`](https://github.com/bazelbuild/rules_swift/blob/master/doc/rules.md#swift_library){: .external}
+target for each Swift library on which the application and/or tests depend.
+
+Add the library targets as follows:
+
+*   Add the application library targets as dependencies to the application
+    targets.
+
+*   Add the test library targets as dependencies to the test targets.
+
+*   List the implementation sources in the `srcs` attribute.
+
+*   List the headers in the `hdrs` attribute.
+
+Note: You can use the [`glob`](/versions/9.1.0/reference/be/functions#glob) function to include
+all sources and/or headers of a certain type. Use it carefully as it might
+include files you do not want Bazel to build.
+
+You can browse existing examples for various types of applications directly in
+the [rules_apple examples
+directory](https://github.com/bazelbuild/rules_apple/tree/master/examples/). For
+example:
+
+*   [macOS application targets](https://github.com/bazelbuild/rules_apple/tree/master/examples/macos){: .external}
+
+*   [iOS applications targets](https://github.com/bazelbuild/rules_apple/tree/master/examples/ios){: .external}
+
+*   [Multi platform applications (macOS, iOS, watchOS, tvOS)](https://github.com/bazelbuild/rules_apple/tree/master/examples/multi_platform){: .external}
+
+For more information on build rules, see [Apple Rules for
+Bazel](https://github.com/bazelbuild/rules_apple){: .external}.
+
+At this point, it is a good idea to test the build:
+
+`bazel build //:`
+
+### Step 4: (Optional) Granularize the build {:#granularize-build}
+
+If the project is large, or as it grows, consider chunking it into multiple
+Bazel packages. This increased granularity provides:
+
+*   Increased incrementality of builds,
+
+*   Increased parallelization of build tasks,
+
+*   Better maintainability for future users,
+
+*   Better control over source code visibility across targets and packages. This
+    prevents issues such as libraries containing implementation details leaking
+    into public APIs.
+
+Tips for granularizing the project:
+
+*   Put each library in its own Bazel package. Start with those requiring the
+    fewest dependencies and work your way up the dependency tree.
+
+*   As you add `BUILD` files and specify targets, add these new targets to the
+    `deps` attributes of targets that depend on them.
+
+*   The `glob()` function does not cross package boundaries, so as the number of
+    packages grows the files matched by `glob()` will shrink.
+
+*   When adding a `BUILD` file to a `main` directory, also add a `BUILD` file to
+    the corresponding `test` directory.
+
+*   Enforce healthy visibility limits across packages.
+
+*   Build the project after each major change to the `BUILD` files and fix build
+    errors as you encounter them.
+
+### Step 5: Run the build {:#run-build}
+
+Run the fully migrated build to ensure it completes with no errors or warnings.
+Run every application and test target individually to more easily find sources
+of any errors that occur.
+
+For example:
+
+```posix-terminal
+bazel build //:my-target
+```
+
+### Step 6: Generate the Xcode project with rules_xcodeproj {:#generate-the-xcode-project-with-rules_xcodeproj}
+
+When building with Bazel, the `MODULE.bazel` and `BUILD` files become the source
+of truth about the build. To make Xcode aware of this, you must generate a
+Bazel-compatible Xcode project using
+[rules_xcodeproj](https://github.com/buildbuddy-io/rules_xcodeproj#features){: .external}
+.
+
+### Troubleshooting {:#troubleshooting}
+
+Bazel errors can arise when it gets out of sync with the selected Xcode version,
+like when you apply an update. Here are some things to try if you're
+experiencing errors with Xcode, for example "Xcode version must be specified to
+use an Apple CROSSTOOL".
+
+*   Manually run Xcode and accept any terms and conditions.
+
+*   Use Xcode select to indicate the correct version, accept the license, and
+    clear Bazel's state.
+
+```posix-terminal
+  sudo xcode-select -s /Applications/Xcode.app/Contents/Developer
+
+  sudo xcodebuild -license
+
+  bazel sync --configure
+```
+
+*   If this does not work, you may also try running `bazel clean --expunge`.
+
+Note: If you've saved your Xcode to a different path, you can use `xcode-select
+-s` to point to that path.
\ No newline at end of file
diff --git a/versions/9.1.0/query/aquery.mdx b/versions/9.1.0/query/aquery.mdx
new file mode 100644
index 00000000..89de89a2
--- /dev/null
+++ b/versions/9.1.0/query/aquery.mdx
@@ -0,0 +1,389 @@
+---
+title: 'Action Graph Query (aquery)'
+---
+
+The `aquery` command allows you to query for actions in your build graph.
+It operates on the post-analysis Configured Target Graph and exposes
+information about **Actions, Artifacts and their relationships.**
+
+`aquery` is useful when you are interested in the properties of the Actions/Artifacts
+generated from the Configured Target Graph. For example, the actual commands run
+and their inputs/outputs/mnemonics.
+
+The tool accepts several command-line [options](#command-options).
+Notably, the aquery command runs on top of a regular Bazel build and inherits
+the set of options available during a build.
+
+It supports the same set of functions that is also available to traditional
+`query` but `siblings`, `buildfiles` and
+`tests`.
+
+An example `aquery` output (without specific details):
+
+
+$ bazel aquery 'deps(//some:label)'
+action 'Writing file some_file_name'
+  Mnemonic: ...
+  Target: ...
+  Configuration: ...
+  ActionKey: ...
+  Inputs: [...]
+  Outputs: [...]
+

+
+## Basic syntax {#basic-syntax}
+
+A simple example of the syntax for `aquery` is as follows:
+
+`bazel aquery "aquery_function(function(//target))"`
+
+The query expression (in quotes) consists of the following:
+
+*   `aquery_function(...)`: functions specific to `aquery`.
+    More details [below](#using-aquery-functions).
+*   `function(...)`: the standard [functions](/versions/9.1.0/query/language#functions)
+    as traditional `query`.
+*   `//target` is the label to the interested target.
+
+
+# aquery examples:
+# Get the action graph generated while building //src/target_a
+$ bazel aquery '//src/target_a'
+
+# Get the action graph generated while building all dependencies of //src/target_a
+$ bazel aquery 'deps(//src/target_a)'
+
+# Get the action graph generated while building all dependencies of //src/target_a
+# whose inputs filenames match the regex ".*cpp".
+$ bazel aquery 'inputs(".*cpp", deps(//src/target_a))'
+

+
+## Using aquery functions {#using-aquery-functions}
+
+There are three `aquery` functions:
+
+*   `inputs`: filter actions by inputs.
+*   `outputs`: filter actions by outputs
+*   `mnemonic`: filter actions by mnemonic
+
+`expr ::= inputs(word, expr)`
+
+  The `inputs` operator returns the actions generated from building `expr`,
+  whose input filenames match the regex provided by `word`.
+
+`$ bazel aquery 'inputs(".*cpp", deps(//src/target_a))'`
+
+`outputs` and `mnemonic` functions share a similar syntax.
+
+You can also combine functions to achieve the AND operation. For example:
+
+
+  $ bazel aquery 'mnemonic("Cpp.*", (inputs(".*cpp", inputs("foo.*", //src/target_a))))'
+

+
+  The above command would find all actions involved in building `//src/target_a`,
+  whose mnemonics match `"Cpp.*"` and inputs match the patterns
+  `".*cpp"` and `"foo.*"`.
+
+Important: aquery functions can't be nested inside non-aquery functions.
+Conceptually, this makes sense since the output of aquery functions is Actions,
+not Configured Targets.
+
+An example of the syntax error produced:
+
+
+        $ bazel aquery 'deps(inputs(".*cpp", //src/target_a))'
+        ERROR: aquery filter functions (inputs, outputs, mnemonic) produce actions,
+        and therefore can't be the input of other function types: deps
+        deps(inputs(".*cpp", //src/target_a))
+

+
+## Options {#options}
+
+### Build options {#build-options}
+
+`aquery` runs on top of a regular Bazel build and thus inherits the set of
+[options](/versions/9.1.0/reference/command-line-reference#build-options)
+available during a build.
+
+### Aquery options {#aquery-options}
+
+#### `--output=(text|summary|commands|proto|jsonproto|textproto), default=text` {#output}
+
+The default output format (`text`) is human-readable,
+use `proto`, `textproto`, or `jsonproto` for machine-readable format.
+The proto message is `analysis.ActionGraphContainer`.
+
+The `commands` output format prints a list of build commands with
+one command per line.
+
+In general, do not depend on the order of output. For more information,
+see the [core query ordering contract](/versions/9.1.0/query/language#graph-order).
+
+#### `--include_commandline, default=true` {#include-commandline}
+
+Includes the content of the action command lines in the output (potentially large).
+
+#### `--include_artifacts, default=true` {#include-artifacts}
+
+Includes names of the action inputs and outputs in the output (potentially large).
+
+#### `--include_aspects, default=true` {#include-aspects}
+
+Whether to include Aspect-generated actions in the output.
+
+#### `--include_param_files, default=false` {#include-param-files}
+
+Include the content of the param files used in the command (potentially large).
+
+Warning: Enabling this flag will automatically enable the `--include_commandline` flag.
+
+#### `--include_file_write_contents, default=false` {#include-file-write-contents}
+
+Include file contents for the `actions.write()` action and the contents of the
+manifest file for the `SourceSymlinkManifest` action The file contents is
+returned in the `file_contents` field with `--output=`xxx`proto`.
+With `--output=text`, the output has
+```
+FileWriteContents: []
+```
+line
+
+#### `--skyframe_state, default=false` {#skyframe-state}
+
+Without performing extra analysis, dump the Action Graph from Skyframe.
+
+Note: Specifying a target with `--skyframe_state` is currently not supported.
+This flag is only available with `--output=proto` or `--output=textproto`.
+
+## Other tools and features {#other-tools-features}
+
+### Querying against the state of Skyframe {#querying-against-skyframe}
+
+[Skyframe](/versions/9.1.0/reference/skyframe) is the evaluation and
+incrementality model of Bazel. On each instance of Bazel server, Skyframe stores the dependency graph
+constructed from the previous runs of the [Analysis phase](/versions/9.1.0/run/build#analysis).
+
+In some cases, it is useful to query the Action Graph on Skyframe.
+An example use case would be:
+
+1.  Run `bazel build //target_a`
+2.  Run `bazel build //target_b`
+3.  File `foo.out` was generated.
+
+_As a Bazel user, I want to determine if `foo.out` was generated from building
+`//target_a` or `//target_b`_.
+
+One could run `bazel aquery 'outputs("foo.out", //target_a)'` and
+`bazel aquery 'outputs("foo.out", //target_b)'` to figure out the action responsible
+for creating `foo.out`, and in turn the target. However, the number of different
+targets previously built can be larger than 2, which makes running multiple `aquery`
+commands a hassle.
+
+As an alternative, the `--skyframe_state` flag can be used:
+
+
+  # List all actions on Skyframe's action graph
+  $ bazel aquery --output=proto --skyframe_state
+
+  # or
+
+  # List all actions on Skyframe's action graph, whose output matches "foo.out"
+  $ bazel aquery --output=proto --skyframe_state 'outputs("foo.out")'
+

+
+With `--skyframe_state` mode, `aquery` takes the content of the Action Graph
+that Skyframe keeps on the instance of Bazel, (optionally) performs filtering on it and
+outputs the content, without re-running the analysis phase.
+
+#### Special considerations {#special-considerations}
+
+##### Output format {#output-format}
+
+`--skyframe_state` is currently only available for `--output=proto`
+and `--output=textproto`
+
+##### Non-inclusion of target labels in the query expression {#target-labels-non-inclusion}
+
+Currently, `--skyframe_state` queries the whole action graph that exists on Skyframe,
+regardless of the targets. Having the target label specified in the query together with
+`--skyframe_state` is considered a syntax error:
+
+
+  # WRONG: Target Included
+  $ bazel aquery --output=proto --skyframe_state **//target_a**
+  ERROR: Error while parsing '//target_a)': Specifying build target(s) [//target_a] with --skyframe_state is currently not supported.
+
+  # WRONG: Target Included
+  $ bazel aquery --output=proto --skyframe_state 'inputs(".*.java", **//target_a**)'
+  ERROR: Error while parsing '//target_a)': Specifying build target(s) [//target_a] with --skyframe_state is currently not supported.
+
+  # CORRECT: Without Target
+  $ bazel aquery --output=proto --skyframe_state
+  $ bazel aquery --output=proto --skyframe_state 'inputs(".*.java")'
+

+
+### Comparing aquery outputs {#comparing-aquery-outputs}
+
+You can compare the outputs of two different aquery invocations using the `aquery_differ` tool.
+For instance: when you make some changes to your rule definition and want to verify that the
+command lines being run did not change. `aquery_differ` is the tool for that.
+
+The tool is available in the [bazelbuild/bazel](https://github.com/bazelbuild/bazel/tree/master/tools/aquery_differ) repository.
+To use it, clone the repository to your local machine. An example usage:
+
+
+  $ bazel run //tools/aquery_differ -- \
+  --before=/path/to/before.proto \
+  --after=/path/to/after.proto \
+  --input_type=proto \
+  --attrs=cmdline \
+  --attrs=inputs
+

+
+The above command returns the difference between the `before` and `after` aquery outputs:
+which actions were present in one but not the other, which actions have different
+command line/inputs in each aquery output, ...). The result of running the above command would be:
+
+
+  Aquery output 'after' change contains an action that generates the following outputs that aquery output 'before' change doesn't:
+  ...
+  /list of output files/
+  ...
+
+  [cmdline]
+  Difference in the action that generates the following output(s):
+    /path/to/abc.out
+  --- /path/to/before.proto
+  +++ /path/to/after.proto
+  @@ -1,3 +1,3 @@
+    ...
+    /cmdline diff, in unified diff format/
+    ...
+

+
+#### Command options {#command-options}
+
+`--before, --after`: The aquery output files to be compared
+
+`--input_type=(proto|text_proto), default=proto`: the format of the input
+files. Support is provided for `proto` and `textproto` aquery output.
+
+`--attrs=(cmdline|inputs), default=cmdline`: the attributes of actions
+to be compared.
+
+### Aspect-on-aspect {#aspect-on-aspect}
+
+It is possible for [Aspects](/versions/9.1.0/extending/aspects)
+to be applied on top of each other. The aquery output of the action generated by
+these Aspects would then include the _Aspect path_, which is the sequence of
+Aspects applied to the target which generated the action.
+
+An example of Aspect-on-Aspect:
+
+```
+  t0
+  ^
+  | <- a1
+  t1
+  ^
+  | <- a2
+  t2
+```
+
+Let ti be a target of rule ri, which applies an Aspect ai
+to its dependencies.
+
+Assume that a2 generates an action X when applied to target t0. The text output of
+`bazel aquery --include_aspects 'deps(//t2)'` for action X would be:
+
+
+  action ...
+  Mnemonic: ...
+  Target: //my_pkg:t0
+  Configuration: ...
+  AspectDescriptors: [//my_pkg:rule.bzl%**a2**(foo=...)
+    -> //my_pkg:rule.bzl%**a1**(bar=...)]
+  ...
+

+
+This means that action `X` was generated by Aspect `a2` applied onto
+`a1(t0)`, where `a1(t0)` is the result of Aspect `a1` applied
+onto target `t0`.
+
+Each `AspectDescriptor` has the following format:
+
+
+  AspectClass([param=value,...])
+

+
+`AspectClass` could be the name of the Aspect class (for native Aspects) or
+`bzl_file%aspect_name` (for Starlark Aspects). `AspectDescriptor` are
+sorted in topological order of the
+[dependency graph](/versions/9.1.0/extending/aspects#aspect_basics).
+
+### Linking with the JSON profile {#linking-with-json-profile}
+
+While aquery provides information about the actions being run in a build (why they're being run,
+their inputs/outputs), the [JSON profile](/versions/9.1.0/rules/performance#performance-profiling)
+tells us the timing and duration of their execution.
+It is possible to combine these 2 sets of information via a common denominator: an action's primary output.
+
+To include actions' outputs in the JSON profile, generate the profile with
+`--experimental_include_primary_output --noslim_profile`.
+Slim profiles are incompatible with the inclusion of primary outputs. An action's primary output
+is included by default by aquery.
+
+We don't currently provide a canonical tool to combine these 2 data sources, but you should be
+able to build your own script with the above information.
+
+## Known issues {#known-issues}
+
+### Handling shared actions {#handling-shared-actions}
+
+Sometimes actions are
+[shared](https://source.bazel.build/bazel/+/master:src/main/java/com/google/devtools/build/lib/actions/Actions.java;l=59;drc=146d51aa1ec9dcb721a7483479ef0b1ac21d39f1)
+between configured targets.
+
+In the execution phase, those shared actions are
+[simply considered as one](https://source.bazel.build/bazel/+/master:src/main/java/com/google/devtools/build/lib/actions/Actions.java;l=241;drc=003b8734036a07b496012730964ac220f486b61f) and only executed once.
+However, aquery operates on the pre-execution, post-analysis action graph, and hence treats these
+like separate actions whose output Artifacts have the exact same `execPath`. As a result,
+equivalent Artifacts appear duplicated.
+
+The list of aquery issues/planned features can be found on
+[GitHub](https://github.com/bazelbuild/bazel/labels/team-Performance).
+
+## FAQs {#faqs}
+
+### The ActionKey remains the same even though the content of an input file changed. {#actionkey-same}
+
+In the context of aquery, the `ActionKey` refers to the `String` gotten from
+[ActionAnalysisMetadata#getKey](https://source.bazel.build/bazel/+/master:src/main/java/com/google/devtools/build/lib/actions/ActionAnalysisMetadata.java;l=89;drc=8b856f5484f0117b2aebc302f849c2a15f273310):
+
+
+  Returns a string encoding all of the significant behaviour of this Action that might affect the
+  output. The general contract of `getKey` is this: if the work to be performed by the
+  execution of this action changes, the key must change.
+
+  ...
+
+  Examples of changes that should affect the key are:
+
+  - Changes to the BUILD file that materially affect the rule which gave rise to this Action.
+  - Changes to the command-line options, environment, or other global configuration resources
+      which affect the behaviour of this kind of Action (other than changes to the names of the
+      input/output files, which are handled externally).
+  - An upgrade to the build tools which changes the program logic of this kind of Action
+      (typically this is achieved by incorporating a UUID into the key, which is changed each
+      time the program logic of this action changes).
+  Note the following exception: for actions that discover inputs, the key must change if any
+  input names change or else action validation may falsely validate.
+

+
+This excludes the changes to the content of the input files, and is not to be confused with
+[RemoteCacheClient#ActionKey](https://source.bazel.build/bazel/+/master:src/main/java/com/google/devtools/build/lib/remote/common/RemoteCacheClient.java;l=38;drc=21577f202eb90ce94a337ebd2ede824d609537b6).
+
+## Updates {#updates}
+
+For any issues/feature requests, please file an issue [here](https://github.com/bazelbuild/bazel/issues/new).
diff --git a/versions/9.1.0/query/cquery.mdx b/versions/9.1.0/query/cquery.mdx
new file mode 100644
index 00000000..6188f2dd
--- /dev/null
+++ b/versions/9.1.0/query/cquery.mdx
@@ -0,0 +1,615 @@
+---
+title: 'Configurable Query (cquery)'
+---
+
+`cquery` is a variant of [`query`](/versions/9.1.0/query/language) that correctly handles
+[`select()`](/versions/9.1.0/docs/configurable-attributes) and build options' effects on the
+build graph.
+
+It achieves this by running over the results of Bazel's [analysis
+phase](/versions/9.1.0/extending/concepts#evaluation-model),
+which integrates these effects. `query`, by contrast, runs over the results of
+Bazel's loading phase, before options are evaluated.
+
+For example:
+
+```
+$ cat > tree/BUILD <
+# Traditional query: query doesn't know which select() branch you will choose,
+# so it conservatively lists all of possible choices, including all used config_settings.
+$ bazel query "deps(//tree:ash)" --noimplicit_deps
+//tree:americana
+//tree:ash
+//tree:common-ash
+//tree:excelsior
+//tree:manna-ash
+//tree:white-ash
+
+# cquery: cquery lets you set build options at the command line and chooses
+# the exact dependencies that implies (and also the config_setting targets).
+$ bazel cquery "deps(//tree:ash)" --define species=excelsior --noimplicit_deps
+//tree:ash (9f87702)
+//tree:manna-ash (9f87702)
+//tree:americana (9f87702)
+//tree:excelsior (9f87702)
+
+
+Each result includes a [unique identifier](#configurations) `(9f87702)` of
+the [configuration](/versions/9.1.0/reference/glossary#configuration) the
+target is built with.
+
+Since `cquery` runs over the configured target graph. it doesn't have insight
+into artifacts like build actions nor access to [`test_suite`](/versions/9.1.0/reference/be/general#test_suite)
+rules as they are not configured targets. For the former, see [`aquery`](/versions/9.1.0/query/aquery).
+
+## Basic syntax {#basic-syntax}
+
+A simple `cquery` call looks like:
+
+`bazel cquery "function(//target)"`
+
+The query expression `"function(//target)"` consists of the following:
+
+*   **`function(...)`** is the function to run on the target. `cquery`
+    supports most
+    of `query`'s [functions](/versions/9.1.0/query/language#functions), plus a
+    few new ones.
+*   **`//target`** is the expression fed to the function. In this example, the
+    expression is a simple target. But the query language also allows nesting of functions.
+    See the [Query guide](/versions/9.1.0/query/guide) for examples.
+
+`cquery` requires a target to run through the [loading and analysis](/versions/9.1.0/extending/concepts#evaluation-model)
+phases. Unless otherwise specified, `cquery` parses the target(s) listed in the
+query expression. See [`--universe_scope`](#universe-scope)
+for querying dependencies of top-level build targets.
+
+## Configurations {#configurations}
+
+The line:
+
+
+//tree:ash (9f87702)
+

+
+means `//tree:ash` was built in a configuration with ID `9f87702`. For most
+targets, this is an opaque hash of the build option values defining the
+configuration.
+
+To see the configuration's complete contents, run:
+
+
+$ bazel config 9f87702
+

+
+`9f87702` is a prefix of the complete ID. This is because complete IDs are
+SHA-256 hashes, which are long and hard to follow. `cquery` understands any valid
+prefix of a complete ID, similar to
+[Git short hashes](https://git-scm.com/book/en/v2/Git-Tools-Revision-Selection#_revision_selection).
+ To see complete IDs, run `$ bazel config`.
+
+## Target pattern evaluation {#target-pattern-evaluation}
+
+`//foo` has a different meaning for `cquery` than for `query`. This is because
+`cquery` evaluates _configured_ targets and the build graph may have multiple
+configured versions of `//foo`.
+
+For `cquery`, a target pattern in the query expression evaluates
+to every configured target with a label that matches that pattern. Output is
+deterministic, but `cquery` makes no ordering guarantee beyond the
+[core query ordering contract](/versions/9.1.0/query/language#graph-order).
+
+This produces subtler results for query expressions than with `query`.
+For example, the following can produce multiple results:
+
+
+# Analyzes //foo in the target configuration, but also analyzes
+# //genrule_with_foo_as_tool which depends on an exec-configured
+# //foo. So there are two configured target instances of //foo in
+# the build graph.
+$ bazel cquery //foo --universe_scope=//foo,//genrule_with_foo_as_tool
+//foo (9f87702)
+//foo (exec)
+

+
+If you want to precisely declare which instance to query over, use
+the [`config`](#config) function.
+
+See `query`'s [target pattern
+documentation](/versions/9.1.0/query/language#target-patterns) for more information on target
+patterns.
+
+## Functions {#functions}
+
+Of the [set of functions](/versions/9.1.0/query/language#functions "list of query functions")
+supported by `query`, `cquery` supports all but
+[`allrdeps`](/versions/9.1.0/query/language#allrdeps),
+[`buildfiles`](/versions/9.1.0/query/language#buildfiles),
+[`rbuildfiles`](/versions/9.1.0/query/language#rbuildfiles),
+[`siblings`](/versions/9.1.0/query/language#siblings), [`tests`](/versions/9.1.0/query/language#tests), and
+[`visible`](/versions/9.1.0/query/language#visible).
+
+`cquery` also introduces the following new functions:
+
+### config {#config}
+
+`expr ::= config(expr, word)`
+
+The `config` operator attempts to find the configured target for
+the label denoted by the first argument and configuration specified by the
+second argument.
+
+Valid values for the second argument are `null` or a
+[custom configuration hash](#configurations). Hashes can be retrieved from `$
+bazel config` or a previous `cquery`'s output.
+
+Examples:
+
+
+$ bazel cquery "config(//bar, 3732cc8)" --universe_scope=//foo
+

+
+
+$ bazel cquery "deps(//foo)"
+//bar (exec)
+//baz (exec)
+
+$ bazel cquery "config(//baz, 3732cc8)"
+

+
+If not all results of the first argument can be found in the specified
+configuration, only those that can be found are returned. If no results
+can be found in the specified configuration, the query fails.
+
+## Options {#options}
+
+### Build options {#build-options}
+
+`cquery` runs over a regular Bazel build and thus inherits the set of
+[options](/versions/9.1.0/reference/command-line-reference#build-options) available during a
+build.
+
+### Using cquery options {#using-cquery-options}
+
+#### `--universe_scope` (comma-separated list) {#universe-scope}
+
+Often, the dependencies of configured targets go through
+[transitions](/versions/9.1.0/extending/rules#configurations),
+which causes their configuration to differ from their dependent. This flag
+allows you to query a target as if it were built as a dependency or a transitive
+dependency of another target. For example:
+
+
+# x/BUILD
+genrule(
+     name = "my_gen",
+     srcs = ["x.in"],
+     outs = ["x.cc"],
+     cmd = "$(locations :tool) $< >$@",
+     tools = [":tool"],
+)
+cc_binary(
+    name = "tool",
+    srcs = ["tool.cpp"],
+)
+

+
+Genrules configure their tools in the
+[exec configuration](/versions/9.1.0/extending/rules#configurations)
+so the following queries would produce the following outputs:
+
+
+  
+    
+      
+      
+      
+    
+  
+  
+    
+      
+      
+      
+    
+    
+      
+      
+      
+    
+  
+
QueryTarget BuiltOutput
bazel cquery "//x:tool"//x:tool//x:tool(targetconfig)
bazel cquery "//x:tool" --universe_scope="//x:my_gen"//x:my_gen//x:tool(execconfig)

+
+If this flag is set, its contents are built. _If it's not set, all targets
+mentioned in the query expression are built_ instead. The transitive closure of
+the built targets are used as the universe of the query. Either way, the targets
+to be built must be buildable at the top level (that is, compatible with
+top-level options). `cquery` returns results in the transitive closure of these
+top-level targets.
+
+Even if it's possible to build all targets in a query expression at the top
+level, it may be beneficial to not do so. For example, explicitly setting
+`--universe_scope` could prevent building targets multiple times in
+configurations you don't care about. It could also help specify which
+configuration version of a target you're looking for. You should set this flag
+if your query expression is more complex than `deps(//foo)`.
+
+#### `--implicit_deps` (boolean, default=True) {#implicit-deps}
+
+Setting this flag to false filters out all results that aren't explicitly set in
+the BUILD file and instead set elsewhere by Bazel. This includes filtering
+resolved toolchains.
+
+#### `--tool_deps` (boolean, default=True) {#tool-deps}
+
+Setting this flag to false filters out all configured targets for which the
+path from the queried target to them crosses a transition between the target
+configuration and the
+[non-target configurations](/versions/9.1.0/extending/rules#configurations). If the queried
+target is in the target configuration, setting `--notool_deps` will only return
+targets that also are in the target configuration. If the queried target is in a
+non-target configuration, setting `--notool_deps` will only return targets also
+in non-target configurations. This setting generally does not affect filtering
+of resolved toolchains.
+
+#### `--include_aspects` (boolean, default=True) {#include-aspects}
+
+Include dependencies added by [aspects](/versions/9.1.0/extending/aspects).
+
+If this flag is disabled, `cquery somepath(X, Y)` and
+`cquery deps(X) | grep 'Y'` omit Y if X only depends on it through an aspect.
+
+## Output formats {#output-formats}
+
+By default, cquery outputs results in a dependency-ordered list of label and configuration pairs.
+There are other options for exposing the results as well.
+
+### Transitions {#transitions}
+
+
+--transitions=lite
+--transitions=full
+

+
+Configuration [transitions](/versions/9.1.0/extending/rules#configurations)
+are used to build targets underneath the top level targets in different
+configurations than the top level targets.
+
+For example, a target might impose a transition to the exec configuration on all
+dependencies in its `tools` attribute. These are known as attribute
+transitions. Rules can also impose transitions on their own configurations,
+known as rule class transitions. This output format outputs information about
+these transitions such as what type they are and the effect they have on build
+options.
+
+This output format is triggered by the `--transitions` flag which by default is
+set to `NONE`. It can be set to `FULL` or `LITE` mode. `FULL` mode outputs
+information about rule class transitions and attribute transitions including a
+detailed diff of the options before and after the transition. `LITE` mode
+outputs the same information without the options diff.
+
+### Protocol message output {#protocol-message-output}
+
+
+--output=proto
+

+
+This option causes the resulting targets to be printed in a binary protocol
+buffer form. The definition of the protocol buffer can be found at
+[src/main/protobuf/analysis_v2.proto](https://github.com/bazelbuild/bazel/blob/master/src/main/protobuf/analysis_v2.proto).
+
+`CqueryResult` is the top level message containing the results of the cquery. It
+has a list of `ConfiguredTarget` messages and a list of `Configuration`
+messages. Each `ConfiguredTarget` has a `configuration_id` whose value is equal
+to that of the `id` field from the corresponding `Configuration` message.
+
+#### --[no]proto:include_configurations {#proto-include-configurations}
+
+By default, cquery results return configuration information as part of each
+configured target. If you'd like to omit this information and get proto output
+that is formatted exactly like query's proto output, set this flag to false.
+
+See [query's proto output documentation](/versions/9.1.0/query/language#output-formats)
+for more proto output-related options.
+
+Note: While selects are resolved both at the top level of returned
+targets and within attributes, all possible inputs for selects are still
+included as `rule_input` fields.
+
+### Graph output {#graph-output}
+
+
+--output=graph
+

+
+This option generates output as a Graphviz-compatible .dot file. See `query`'s
+[graph output documentation](/versions/9.1.0/query/language#display-result-graph) for details. `cquery`
+also supports [`--graph:node_limit`](/versions/9.1.0/query/language#graph-nodelimit) and
+[`--graph:factored`](/versions/9.1.0/query/language#graph-factored).
+
+### Files output {#files-output}
+
+
+--output=files
+

+
+This option prints a list of the output files produced by each target matched
+by the query similar to the list printed at the end of a `bazel build`
+invocation. The output contains only the files advertised in the requested
+output groups as determined by the
+[`--output_groups`](/versions/9.1.0/reference/command-line-reference#flag--output_groups) flag.
+It does include source files.
+
+All paths emitted by this output format are relative to the
+[execroot](https://bazel.build/versions/9.1.0/remote/output-directories), which can be obtained
+via `bazel info execution_root`. If the `bazel-out` convenience symlink exists,
+paths to files in the main repository also resolve relative to the workspace
+directory.
+
+Note: The output of `bazel cquery --output=files //pkg:foo` contains the output
+files of `//pkg:foo` in *all* configurations that occur in the build (also see
+the [section on target pattern evaluation](#target-pattern-evaluation)). If that
+is not desired, wrap you query in [`config(..., target)`](#config).
+
+### Defining the output format using Starlark {#output-format-definition}
+
+
+--output=starlark
+

+
+This output format calls a [Starlark](/versions/9.1.0/rules/language)
+function for each configured target in the query result, and prints the value
+returned by the call. The `--starlark:file` flag specifies the location of a
+Starlark file that defines a function named `format` with a single parameter,
+`target`. This function is called for each [Target](/versions/9.1.0/rules/lib/builtins/Target)
+in the query result. Alternatively, for convenience, you may specify just the
+body of a function declared as `def format(target): return expr` by using the
+`--starlark:expr` flag.
+
+#### 'cquery' Starlark dialect {#cquery-starlark}
+
+The cquery Starlark environment differs from a BUILD or .bzl file. It includes
+all core Starlark
+[built-in constants and functions](https://github.com/bazelbuild/starlark/blob/master/spec.md#built-in-constants-and-functions),
+plus a few cquery-specific ones described below, but not (for example) `glob`,
+`native`, or `rule`, and it does not support load statements.
+
+##### build_options(target) {#build-options-function}
+
+`build_options(target)` returns a map whose keys are build option identifiers
+(see [Configurations](/versions/9.1.0/extending/config)) and whose values are their Starlark
+values. Build options whose values are not legal Starlark values are omitted
+from this map.
+
+If the target is an input file, `build_options(target)` returns None, as input
+file targets have a null configuration.
+
+##### providers(target) {#providers}
+
+`providers(target)` returns a map whose keys are names of
+[providers](/versions/9.1.0/extending/rules#providers)
+(for example, `"DefaultInfo"`) and whose values are their Starlark values.
+Providers whose values are not legal Starlark values are omitted from this map.
+
+#### Examples {#output-format-definition-examples}
+
+Print a space-separated list of the base names of all files produced by `//foo`:
+
+
+  bazel cquery //foo --output=starlark \
+    --starlark:expr="' '.join([f.basename for f in providers(target)['DefaultInfo'].files.to_list()])"
+

+
+Print a space-separated list of the paths of all files produced by **rule** targets in
+`//bar` and its subpackages:
+
+
+  bazel cquery 'kind(rule, //bar/...)' --output=starlark \
+    --starlark:expr="' '.join([f.path for f in providers(target)['DefaultInfo'].files.to_list()])"
+

+
+Print a list of the mnemonics of all actions registered by `//foo`.
+
+
+  bazel cquery //foo --output=starlark \
+    --starlark:expr="[a.mnemonic for a in target.actions]"
+

+
+Print a list of compilation outputs registered by a `cc_library` `//baz`.
+
+
+  bazel cquery //baz --output=starlark \
+    --starlark:expr="[f.path for f in target.output_groups.compilation_outputs.to_list()]"
+

+
+Print the value of the command line option `--javacopt` when building `//foo`.
+
+
+  bazel cquery //foo --output=starlark \
+    --starlark:expr="build_options(target)['//command_line_option:javacopt']"
+

+
+Print the label of each target with exactly one output. This example uses
+Starlark functions defined in a file.
+
+
+  $ cat example.cquery
+
+  def has_one_output(target):
+    return len(providers(target)["DefaultInfo"].files.to_list()) == 1
+
+  def format(target):
+    if has_one_output(target):
+      return target.label
+    else:
+      return ""
+
+  $ bazel cquery //baz --output=starlark --starlark:file=example.cquery
+

+
+Print the label of each target which is strictly Python 3. This example uses
+Starlark functions defined in a file.
+
+
+  $ cat example.cquery
+
+  def format(target):
+    p = providers(target)
+    py_info = p.get("PyInfo")
+    if py_info and py_info.has_py3_only_sources:
+      return target.label
+    else:
+      return ""
+
+  $ bazel cquery //baz --output=starlark --starlark:file=example.cquery
+

+
+Extract a value from a user defined Provider.
+
+```
+  $ cat some_package/my_rule.bzl
+
+  MyRuleInfo = provider(fields={"color": "the name of a color"})
+
+  def _my_rule_impl(ctx):
+      ...
+      return [MyRuleInfo(color="red")]
+
+  my_rule = rule(
+      implementation = _my_rule_impl,
+      attrs = {...},
+  )
+
+  $ cat example.cquery
+
+  def format(target):
+    p = providers(target)
+    my_rule_info = p.get("//some_package:my_rule.bzl%MyRuleInfo'")
+    if my_rule_info:
+      return my_rule_info.color
+    return ""
+
+  $ bazel cquery //baz --output=starlark --starlark:file=example.cquery
+```
+
+## cquery vs. query {#cquery-vs-query}
+
+`cquery` and `query` complement each other and excel in
+different niches. Consider the following to decide which is right for you:
+
+*  `cquery` follows specific `select()` branches to
+    model the exact graph you build. `query` doesn't know which
+    branch the build chooses, so overapproximates by including all branches.
+*   `cquery`'s precision requires building more of the graph than
+    `query` does. Specifically, `cquery`
+    evaluates _configured targets_ while `query` only
+    evaluates _targets_. This takes more time and uses more memory.
+*   `cquery`'s interpretation of
+    the [query language](/versions/9.1.0/query/language) introduces ambiguity
+    that `query` avoids. For example,
+    if `"//foo"` exists in two configurations, which one
+    should `cquery "deps(//foo)"` use?
+    The [`config`](#config) function can help with this.
+
+## Non-deterministic output
+
+`cquery` does not automatically wipe the build graph from previous commands.
+It's therefore prone to picking up results from past queries.
+
+For example, `genrule` exerts an exec transition on its `tools` attribute -
+that is, it configures its tools in the [exec configuration]
+(https://bazel.build/rules/rules#configurations).
+
+You can see the lingering effects of that transition below.
+
+
+$ cat > foo/BUILD <<
+
+This may or may not be desirable behavior depending on what you're trying to
+evaluate.
+
+To disable this, run `blaze clean` before your `cquery` to ensure a fresh
+analysis graph.
+
+## Troubleshooting {#troubleshooting}
+
+### Recursive target patterns (`/...`) {#recursive-target-patterns}
+
+If you encounter:
+
+
+$ bazel cquery --universe_scope=//foo:app "somepath(//foo:app, //foo/...)"
+ERROR: Error doing post analysis query: Evaluation failed: Unable to load package '[foo]'
+because package is not in scope. Check that all target patterns in query expression are within the
+--universe_scope of this query.
+

+
+this incorrectly suggests package `//foo` isn't in scope even though
+`--universe_scope=//foo:app` includes it. This is due to design limitations in
+`cquery`. As a workaround, explicitly include `//foo/...` in the universe
+scope:
+
+
+$ bazel cquery --universe_scope=//foo:app,//foo/... "somepath(//foo:app, //foo/...)"
+

+
+If that doesn't work (for example, because some target in `//foo/...` can't
+build with the chosen build flags), manually unwrap the pattern into its
+constituent packages with a pre-processing query:
+
+
+# Replace "//foo/..." with a subshell query call (not cquery!) outputting each package, piped into
+# a sed call converting "<pkg>" to "//<pkg>:*", piped into a "+"-delimited line merge.
+# Output looks like "//foo:*+//foo/bar:*+//foo/baz".
+#
+$  bazel cquery --universe_scope=//foo:app "somepath(//foo:app, $(bazel query //foo/...
+--output=package | sed -e 's/^/\/\//' -e 's/$/:*/' | paste -sd "+" -))"
+

diff --git a/versions/9.1.0/query/guide.mdx b/versions/9.1.0/query/guide.mdx
new file mode 100644
index 00000000..62240bd2
--- /dev/null
+++ b/versions/9.1.0/query/guide.mdx
@@ -0,0 +1,319 @@
+---
+title: 'Query guide'
+---
+
+This page covers how to get started using Bazel's query language to trace
+dependencies in your code.
+
+For a language details and `--output` flag details, please see the
+reference manuals, [Bazel query reference](/versions/9.1.0/query/language)
+and [Bazel cquery reference](/versions/9.1.0/query/cquery). You can get help by
+typing `bazel help query` or `bazel help cquery` on the
+command line.
+
+To execute a query while ignoring errors such as missing targets, use the
+`--keep_going` flag.
+
+## Finding the dependencies of a rule {#finding-rule-dependencies}
+
+To see the dependencies of `//foo`, use the
+`deps` function in bazel query:
+
+
+$ bazel query "deps(//foo)"
+//foo:foo
+//foo:foo-dep
+...
+

+
+This is the set of all targets required to build `//foo`.
+
+## Tracing the dependency chain between two packages {#tracing-dependency-chain}
+
+The library `//third_party/zlib:zlibonly` isn't in the BUILD file for
+`//foo`, but it is an indirect dependency. How can
+we trace this dependency path?  There are two useful functions here:
+`allpaths` and `somepath`. You may also want to exclude
+tooling dependencies with `--notool_deps` if you care only about
+what is included in the artifact you built, and not every possible job.
+
+To visualize the graph of all dependencies, pipe the bazel query output through
+  the `dot` command-line tool:
+
+
+$ bazel query "allpaths(//foo, third_party/...)" --notool_deps --output graph | dot -Tsvg > /tmp/deps.svg
+

+
+Note: `dot` supports other image formats, just replace `svg` with the
+format identifier, for example, `png`.
+
+When a dependency graph is big and complicated, it can be helpful start with a single path:
+
+
+$ bazel query "somepath(//foo:foo, third_party/zlib:zlibonly)"
+//foo:foo
+//translations/tools:translator
+//translations/base:base
+//third_party/py/MySQL:MySQL
+//third_party/py/MySQL:_MySQL.so
+//third_party/mysql:mysql
+//third_party/zlib:zlibonly
+

+
+If you do not specify `--output graph` with `allpaths`,
+you will get a flattened list of the dependency graph.
+
+
+$ bazel query "allpaths(//foo, third_party/...)"
+  ...many errors detected in BUILD files...
+//foo:foo
+//translations/tools:translator
+//translations/tools:aggregator
+//translations/base:base
+//tools/pkg:pex
+//tools/pkg:pex_phase_one
+//tools/pkg:pex_lib
+//third_party/python:python_lib
+//translations/tools:messages
+//third_party/py/xml:xml
+//third_party/py/xml:utils/boolean.so
+//third_party/py/xml:parsers/sgmlop.so
+//third_party/py/xml:parsers/pyexpat.so
+//third_party/py/MySQL:MySQL
+//third_party/py/MySQL:_MySQL.so
+//third_party/mysql:mysql
+//third_party/openssl:openssl
+//third_party/zlib:zlibonly
+//third_party/zlib:zlibonly_v1_2_3
+//third_party/python:headers
+//third_party/openssl:crypto
+

+
+### Aside: implicit dependencies {#implicit-dependencies}
+
+The BUILD file for `//foo` never references
+`//translations/tools:aggregator`. So, where's the direct dependency?
+
+Certain rules include implicit dependencies on additional libraries or tools.
+For example, to build a `genproto` rule, you need first to build the Protocol
+Compiler, so every `genproto` rule carries an implicit dependency on the
+protocol compiler. These dependencies are not mentioned in the build file,
+but added in by the build tool. The full set of implicit dependencies is
+  currently undocumented. Using `--noimplicit_deps` allows you to filter out
+  these deps from your query results. For cquery, this will include resolved toolchains.
+
+## Reverse dependencies {#reverse-dependencies}
+
+You might want to know the set of targets that depends on some target. For instance,
+if you're going to change some code, you might want to know what other code
+you're about to break. You can use `rdeps(u, x)` to find the reverse
+dependencies of the targets in `x` within the transitive closure of `u`.
+
+Bazel's [Sky Query](/versions/9.1.0/query/language#sky-query)
+supports the `allrdeps` function which allows you to query reverse dependencies
+in a universe you specify.
+
+## Miscellaneous uses {#miscellaneous-uses}
+
+You can use `bazel query` to analyze many dependency relationships.
+
+### What exists ... {#what-exists}
+
+#### What packages exist beneath `foo`? {#what-exists-beneath-foo}
+
+
bazel query 'foo/...' --output package

+
+#### What rules are defined in the `foo` package? {#rules-defined-in-foo}
+
+
bazel query 'kind(rule, foo:*)' --output label_kind

+
+#### What files are generated by rules in the `foo` package? {#files-generated-by-rules}
+
+
bazel query 'kind("generated file", //foo:*)'

+
+#### What targets are generated by starlark macro `foo`? {#targets-generated-by-foo}
+
+
bazel query 'attr(generator_function, foo, //path/to/search/...)'

+
+#### What's the set of BUILD files needed to build `//foo`? {#build-files-required}
+
+
bazel query 'buildfiles(deps(//foo))' | cut -f1 -d:

+
+#### What are the individual tests that a `test_suite` expands to? {#individual-tests-in-testsuite}
+
+
bazel query 'tests(//foo:smoke_tests)'

+
+#### Which of those are C++ tests? {#cxx-tests}
+
+
bazel query 'kind(cc_.*, tests(//foo:smoke_tests))'

+
+#### Which of those are small?  Medium?  Large? {#size-of-tests}
+
+
+bazel query 'attr(size, small, tests(//foo:smoke_tests))'
+
+bazel query 'attr(size, medium, tests(//foo:smoke_tests))'
+
+bazel query 'attr(size, large, tests(//foo:smoke_tests))'
+

+
+#### What are the tests beneath `foo` that match a pattern? {#tests-beneath-foo}
+
+
bazel query 'filter("pa?t", kind(".*_test rule", //foo/...))'

+
+The pattern is a regex and is applied to the full name of the rule. It's similar to doing
+
+
bazel query 'kind(".*_test rule", //foo/...)' | grep -E 'pa?t'

+
+#### What package contains file `path/to/file/bar.java`? {#barjava-package}
+
+
 bazel query path/to/file/bar.java --output=package

+
+#### What is the build label for `path/to/file/bar.java?` {#barjava-build-label}
+
+
bazel query path/to/file/bar.java

+
+#### What rule target(s) contain file `path/to/file/bar.java` as a source? {#barjava-rule-targets}
+
+```
+fullname=$(bazel query path/to/file/bar.java)
+bazel query "attr('srcs', $fullname, ${fullname//:*/}:*)"
+```
+
+### What package dependencies exist ... {#package-dependencies}
+
+#### What packages does `foo` depend on? (What do I need to check out to build `foo`) {#packages-foo-depends-on}
+
+
bazel query 'buildfiles(deps(//foo:foo))' --output package

+
+Note: `buildfiles` is required in order to correctly obtain all files
+referenced by `subinclude`; see the reference manual for details.
+
+#### What packages does the `foo` tree depend on, excluding `foo/contrib`? {#packages-foo-tree-depends-on}
+
+
bazel query 'deps(foo/... except foo/contrib/...)' --output package

+
+### What rule dependencies exist ... {#rule-dependencies}
+
+#### What genproto rules does bar depend upon? {#genproto-rules}
+
+
bazel query 'kind(genproto, deps(bar/...))'

+
+#### Find the definition of some JNI (C++) library that is transitively depended upon by a Java binary rule in the servlet tree. {#jni-library}
+
+
bazel query 'some(kind(cc_.*library, deps(kind(java_binary, //java/com/example/frontend/...))))' --output location

+
+##### ...Now find the definitions of all the Java binaries that depend on them {#java-binaries}
+
+```
+bazel query 'let jbs = kind(java_binary, //java/com/example/frontend/...) in
+  let cls = kind(cc_.*library, deps($jbs)) in
+    $jbs intersect allpaths($jbs, $cls)'
+```
+
+### What file dependencies exist ... {#file-dependencies}
+
+#### What's the complete set of Java source files required to build foo? {#java-source-files}
+
+Source files:
+
+
bazel query 'kind("source file", deps(//path/to/target/foo/...))' | grep java$

+
+Generated files:
+
+```
+bazel query 'kind("generated file", deps(//path/to/target/foo/...))' | grep java$
+```
+
+#### What is the complete set of Java source files required to build QUX's tests? {#qux-tests}
+
+Source files:
+
+
bazel query 'kind("source file", deps(kind(".*_test rule", javatests/com/example/qux/...)))' | grep java$

+
+Generated files:
+
+
bazel query 'kind("generated file", deps(kind(".*_test rule", javatests/com/example/qux/...)))' | grep java$

+
+### What differences in dependencies between X and Y exist ... {#differences-in-dependencies}
+
+#### What targets does `//foo` depend on that `//foo:foolib` does not? {#foo-targets}
+
+
bazel query 'deps(//foo) except deps(//foo:foolib)'

+
+#### What C++ libraries do the `foo` tests depend on that the `//foo` production binary does _not_ depend on? {#foo-cxx-libraries}
+
+
bazel query 'kind("cc_library", deps(kind(".*test rule", foo/...)) except deps(//foo))'

+
+### Why does this dependency exist ... {#why-dependencies}
+
+#### Why does `bar` depend on `groups2`? {#dependency-bar-groups2}
+
+
bazel query 'somepath(bar/...,groups2/...:*)'

+
+Once you have the results of this query, you will often find that a single
+target stands out as being an unexpected or egregious and undesirable
+dependency of `bar`. The query can then be further refined to:
+
+#### Show me a path from `docker/updater:updater_systest` (a `py_test`) to some `cc_library` that it depends upon: {#path-docker-cclibrary}
+
+
bazel query 'let cc = kind(cc_library, deps(docker/updater:updater_systest)) in
+  somepath(docker/updater:updater_systest, $cc)'

+
+#### Why does library `//photos/frontend:lib` depend on two variants of the same library `//third_party/jpeglib` and `//third_party/jpeg`? {#library-two-variants}
+
+This query boils down to: "show me the subgraph of `//photos/frontend:lib` that
+depends on both libraries". When shown in topological order, the last element
+of the result is the most likely culprit.
+
+```
+bazel query 'allpaths(//photos/frontend:lib, //third_party/jpeglib)
+                intersect
+               allpaths(//photos/frontend:lib, //third_party/jpeg)'
+//photos/frontend:lib
+//photos/frontend:lib_impl
+//photos/frontend:lib_dispatcher
+//photos/frontend:icons
+//photos/frontend/modules/gadgets:gadget_icon
+//photos/thumbnailer:thumbnail_lib
+//third_party/jpeg/img:renderer
+```
+
+### What depends on  ... {#depends-on}
+
+#### What rules under bar depend on Y? {#rules-bar-y}
+
+
bazel query 'bar/... intersect allpaths(bar/..., Y)'

+
+Note: `X intersect allpaths(X, Y)` is the general idiom for the query "which X
+depend on Y?" If expression X is non-trivial, it may be convenient to bind a
+name to it using `let` to avoid duplication.
+
+#### What targets directly depend on T, in T's package? {#targets-t}
+
+
bazel query 'same_pkg_direct_rdeps(T)'

+
+### How do I break a dependency ... {#break-dependency}
+
+{/* TODO find a convincing value of X to plug in here */}
+
+#### What dependency paths do I have to break to make `bar` no longer depend on X? {#break-dependency-bar-x}
+
+To output the graph to a `svg` file:
+
+
bazel query 'allpaths(bar/...,X)' --output graph | dot -Tsvg > /tmp/dep.svg

+
+### Misc {#misc}
+
+#### How many sequential steps are there in the `//foo-tests` build? {#steps-footests}
+
+Unfortunately, the query language can't currently give you the longest path
+from x to y, but it can find the (or rather _a_) most distant node from the
+starting point, or show you the _lengths_ of the longest path from x to every
+y that it depends on. Use `maxrank`:
+
+
bazel query 'deps(//foo-tests)' --output maxrank | tail -1
+85 //third_party/zlib:zutil.c

+
+The result indicates that there exist paths of length 85 that must occur in
+order in this build.
diff --git a/versions/9.1.0/query/language.mdx b/versions/9.1.0/query/language.mdx
new file mode 100644
index 00000000..6ca6b05e
--- /dev/null
+++ b/versions/9.1.0/query/language.mdx
@@ -0,0 +1,1536 @@
+---
+title: 'The Bazel Query Reference'
+---
+
+This page is the reference manual for the _Bazel Query Language_ used
+when you use `bazel query` to analyze build dependencies. It also
+describes the output formats `bazel query` supports.
+
+For practical use cases, see the [Bazel Query How-To](/versions/9.1.0/query/guide).
+
+## Additional query reference
+
+In addition to `query`, which runs on the post-loading phase target graph,
+Bazel includes *action graph query* and *configurable query*.
+
+### Action graph query {:#aquery}
+
+The action graph query (`aquery`) operates on the post-analysis Configured
+Target Graph and exposes information about **Actions**, **Artifacts**, and
+their relationships. `aquery` is useful when you are interested in the
+properties of the Actions/Artifacts generated from the Configured Target Graph.
+For example, the actual commands run and their inputs, outputs, and mnemonics.
+
+For more details, see the [aquery reference](/versions/9.1.0/query/aquery).
+
+### Configurable query {:#cquery}
+
+Traditional Bazel query runs on the post-loading phase target graph and
+therefore has no concept of configurations and their related concepts. Notably,
+it doesn't correctly resolve [select statements](/versions/9.1.0/reference/be/functions#select)
+and instead returns all possible resolutions of selects. However, the
+configurable query environment, `cquery`, properly handles configurations but
+doesn't provide all of the functionality of this original query.
+
+For more details, see the [cquery reference](/versions/9.1.0/query/cquery).
+
+## Examples {:#examples}
+
+How do people use `bazel query`?  Here are typical examples:
+
+Why does the `//foo` tree depend on `//bar/baz`?
+Show a path:
+
+```
+somepath(foo/..., //bar/baz:all)
+```
+
+What C++ libraries do all the `foo` tests depend on that
+the `foo_bin` target does not?
+
+```
+kind("cc_library", deps(kind(".*test rule", foo/...)) except deps(//foo:foo_bin))
+```
+
+## Tokens: The lexical syntax {:#tokens}
+
+Expressions in the query language are composed of the following
+tokens:
+
+* **Keywords**, such as `let`. Keywords are the reserved words of the
+  language, and each of them is described below. The complete set
+  of keywords is:
+
+   * [`except`](#set-operations)
+
+   * [`in`](#variables)
+
+   * [`intersect`](#set-operations)
+
+   * [`let`](#variables)
+
+   * [`set`](#set)
+
+   * [`union`](#set-operations)
+
+* **Words**, such as "`foo/...`" or "`.*test rule`" or "`//bar/baz:all`". If a
+  character sequence is "quoted" (begins and ends with a single-quote ' or
+  begins and ends with a double-quote "), it is a word. If a character sequence
+  is not quoted, it may still be parsed as a word. Unquoted words are sequences
+  of characters drawn from the alphabet characters A-Za-z, the numerals 0-9,
+  and the special characters `*/@.-_:$~[]` (asterisk, forward slash, at, period,
+  hyphen, underscore, colon, dollar sign, tilde, left square brace, right square
+  brace). However, unquoted words may not start with a hyphen `-` or asterisk `*`
+  even though relative [target names](/versions/9.1.0/concepts/labels#target-names) may start
+  with those characters. As a special rule meant to simplify the handling of
+  labels referring to external repositories, unquoted words that start with
+  `@@` may contain `+` characters.
+
+  Unquoted words also may not include the characters plus sign `+` or equals
+  sign `=`, even though those characters are permitted in target names. When
+  writing code that generates query expressions, target names should be quoted.
+
+  Quoting _is_ necessary when writing scripts that construct Bazel query
+  expressions from user-supplied values.
+
+  ```
+   //foo:bar+wiz    # WRONG: scanned as //foo:bar + wiz.
+   //foo:bar=wiz    # WRONG: scanned as //foo:bar = wiz.
+   "//foo:bar+wiz"  # OK.
+   "//foo:bar=wiz"  # OK.
+  ```
+
+  Note that this quoting is in addition to any quoting that may be required by
+  your shell, such as:
+
+  ```posix-terminal
+  bazel query ' "//foo:bar=wiz" '   # single-quotes for shell, double-quotes for Bazel.
+  ```
+
+  Keywords and operators, when quoted, are treated as ordinary words. For example, `some` is a
+  keyword but "some" is a word. Both `foo` and "foo" are words.
+
+  However, be careful when using single or double quotes in target names. When
+  quoting one or more target names, use only one type of quotes (either all
+  single or all double quotes).
+
+  The following are examples of what the Java query string will be:
+
+  ```
+    'a"'a'         # WRONG: Error message: unclosed quotation.
+    "a'"a"         # WRONG: Error message: unclosed quotation.
+    '"a" + 'a''    # WRONG: Error message: unexpected token 'a' after query expression '"a" + '
+    "'a' + "a""    # WRONG: Error message: unexpected token 'a' after query expression ''a' + '
+    "a'a"          # OK.
+    'a"a'          # OK.
+    '"a" + "a"'    # OK
+    "'a' + 'a'"    # OK
+  ```
+
+  We chose this syntax so that quote marks aren't needed in most cases. The
+  (unusual) `".*test rule"` example needs quotes: it starts with a period and
+  contains a space. Quoting `"cc_library"` is unnecessary but harmless.
+
+* **Punctuation**, such as parens `()`, period `.` and comma `,`. Words
+  containing punctuation (other than the exceptions listed above) must be quoted.
+
+Whitespace characters outside of a quoted word are ignored.
+
+## Bazel query language concepts {:#language-concepts}
+
+The Bazel query language is a language of expressions. Every
+expression evaluates to a **partially-ordered set** of targets,
+or equivalently, a **graph** (DAG) of targets. This is the only
+datatype.
+
+Set and graph refer to the same datatype, but emphasize different
+aspects of it, for example:
+
+*   **Set:** The partial order of the targets is not interesting.
+*   **Graph:** The partial order of targets is significant.
+
+### Cycles in the dependency graph {:#dependency-graph-cycles}
+
+Build dependency graphs should be acyclic.
+
+The algorithms used by the query language are robust against cycles, and will
+not report cycles as errors.
+
+Note that the post-loading phase unconfigured target graph that `bazel query`
+operates over may contain cycles that do not exist in the configured target
+graph. Cycles in the configured target graph are detected and reported as errors
+by [`bazel cquery`](/versions/9.1.0/query/cquery) and [`bazel aquery`](/versions/9.1.0/query/aquery).
+
+### Implicit dependencies {:#implicit-dependencies}
+
+In addition to build dependencies that are defined explicitly in `BUILD` files,
+Bazel adds additional _implicit_ dependencies to rules. Implicit dependencies
+may be defined by:
+
+- [Private attributes](/versions/9.1.0/extending/rules#private_attributes_and_implicit_dependencies)
+- [Toolchain requirements](/versions/9.1.0/extending/toolchains#writing-rules-toolchains)
+
+By default, `bazel query` takes implicit dependencies into account
+when computing the query result. This behavior can be changed with
+the `--[no]implicit_deps` option.
+
+Note that, as query does not consider configurations, potential toolchain
+**implementations** are not considered dependencies, only the
+required toolchain types. See
+[toolchain documentation](/versions/9.1.0/extending/toolchains#writing-rules-toolchains).
+
+### Soundness {:#soundness}
+
+Bazel query language expressions operate over the build
+dependency graph, which is the graph implicitly defined by all
+rule declarations in all `BUILD` files. It is important to understand
+that this graph is somewhat abstract, and does not constitute a
+complete description of how to perform all the steps of a build. In
+order to perform a build, a _configuration_ is required too;
+see the [configurations](/versions/9.1.0/docs/user-manual#configurations)
+section of the User's Guide for more detail.
+
+The result of evaluating an expression in the Bazel query language
+is true _for all configurations_, which means that it may be
+a conservative over-approximation, and not exactly precise. If you
+use the query tool to compute the set of all source files needed
+during a build, it may report more than are actually necessary
+because, for example, the query tool will include all the files
+needed to support message translation, even though you don't intend
+to use that feature in your build.
+
+### On the preservation of graph order {:#graph-order}
+
+Operations preserve any ordering
+constraints inherited from their subexpressions. You can think of
+this as "the law of conservation of partial order". Consider an
+example: if you issue a query to determine the transitive closure of
+dependencies of a particular target, the resulting set is ordered
+according to the dependency graph. If you filter that set to
+include only the targets of `file` kind, the same
+_transitive_ partial ordering relation holds between every
+pair of targets in the resulting subset - even though none of
+these pairs is actually directly connected in the original graph.
+(There are no file-file edges in the build dependency graph).
+
+However, while all operators _preserve_ order, some
+operations, such as the [set operations](#set-operations)
+don't _introduce_ any ordering constraints of their own.
+Consider this expression:
+
+```
+deps(x) union y
+```
+
+The order of the final result set is guaranteed to preserve all the
+ordering constraints of its subexpressions, namely, that all the
+transitive dependencies of `x` are correctly ordered with
+respect to each other. However, the query guarantees nothing about
+the ordering of the targets in `y`, nor about the
+ordering of the targets in `deps(x)` relative to those in
+`y` (except for those targets in
+`y` that also happen to be in `deps(x)`).
+
+Operators that introduce ordering constraints include:
+`allpaths`, `deps`, `rdeps`, `somepath`, and the target pattern wildcards
+`package:*`, `dir/...`, etc.
+
+### Sky query {:#sky-query}
+
+_Sky Query_ is a mode of query that operates over a specified _universe scope_.
+
+#### Special functions available only in SkyQuery
+
+Sky Query mode has the additional query functions `allrdeps` and
+`rbuildfiles`. These functions operate over the entire
+universe scope (which is why they don't make sense for normal Query).
+
+#### Specifying a universe scope
+
+Sky Query mode is activated by passing the following two flags:
+(`--universe_scope` or `--infer_universe_scope`) and
+`--order_output=no`.
+`--universe_scope=,...,` tells query to
+preload the transitive closure of the target pattern specified by the target patterns, which can
+be both additive and subtractive. All queries are then evaluated in this "scope". In particular,
+the [`allrdeps`](#allrdeps) and
+[`rbuildfiles`](#rbuildfiles) operators only return results from this scope.
+`--infer_universe_scope` tells Bazel to infer a value for `--universe_scope`
+from the query expression. This inferred value is the list of unique target patterns in the
+query expression, but this might not be what you want. For example:
+
+```posix-terminal
+bazel query --infer_universe_scope --order_output=no "allrdeps(//my:target)"
+```
+
+The list of unique target patterns in this query expression is `["//my:target"]`, so
+Bazel treats this the same as the invocation:
+
+```posix-terminal
+bazel query --universe_scope=//my:target --order_output=no "allrdeps(//my:target)"
+```
+
+But the result of that query with `--universe_scope` is only `//my:target`;
+none of the reverse dependencies of `//my:target` are in the universe, by
+construction! On the other hand, consider:
+
+```posix-terminal
+bazel query --infer_universe_scope --order_output=no "tests(//a/... + b/...) intersect allrdeps(siblings(rbuildfiles(my/starlark/file.bzl)))"
+```
+
+This is a meaningful query invocation that is trying to compute the test targets in the
+[`tests`](#tests) expansion of the targets under some directories that
+transitively depend on targets whose definition uses a certain `.bzl` file. Here,
+`--infer_universe_scope` is a convenience, especially in the case where the choice of
+`--universe_scope` would otherwise require you to parse the query expression yourself.
+
+So, for query expressions that use universe-scoped operators like
+[`allrdeps`](#allrdeps) and
+[`rbuildfiles`](#rbuildfiles) be sure to use
+`--infer_universe_scope` only if its behavior is what you want.
+
+Sky Query has some advantages and disadvantages compared to the default query. The main
+disadvantage is that it cannot order its output according to graph order, and thus certain
+[output formats](#output-formats) are forbidden. Its advantages are that it provides
+two operators ([`allrdeps`](#allrdeps) and
+[`rbuildfiles`](#rbuildfiles)) that are not available in the default query.
+As well, Sky Query does its work by introspecting the
+[Skyframe](/versions/9.1.0/reference/skyframe) graph, rather than creating a new
+graph, which is what the default implementation does. Thus, there are some circumstances in which
+it is faster and uses less memory.
+
+## Expressions: Syntax and semantics of the grammar {:#expressions}
+
+This is the grammar of the Bazel query language, expressed in EBNF notation:
+
+```none {:.devsite-disable-click-to-copy}
+expr ::= {{ '' }}word{{ '' }}
+       | let {{ '' }}name{{ '' }} = {{ '' }}expr{{ '' }} in {{ '' }}expr{{ '' }}
+       | ({{ '' }}expr{{ '' }})
+       | {{ '' }}expr{{ '' }} intersect {{ '' }}expr{{ '' }}
+       | {{ '' }}expr{{ '' }} ^ {{ '' }}expr{{ '' }}
+       | {{ '' }}expr{{ '' }} union {{ '' }}expr{{ '' }}
+       | {{ '' }}expr{{ '' }} + {{ '' }}expr{{ '' }}
+       | {{ '' }}expr{{ '' }} except {{ '' }}expr{{ '' }}
+       | {{ '' }}expr{{ '' }} - {{ '' }}expr{{ '' }}
+       | set({{ '' }}word{{ '' }} *)
+       | {{ '' }}word{{ '' }} '(' {{ '' }}int{{ '' }} | {{ '' }}word{{ '' }} | {{ '' }}expr{{ '' }} ... ')'
+```
+
+The following sections describe each of the productions of this grammar in order.
+
+### Target patterns {:#target-patterns}
+
+```
+expr ::= {{ '' }}word{{ '' }}
+```
+
+Syntactically, a _target pattern_ is just a word. It's interpreted as an
+(unordered) set of targets. The simplest target pattern is a label, which
+identifies a single target (file or rule). For example, the target pattern
+`//foo:bar` evaluates to a set containing one element, the target, the `bar`
+rule.
+
+Target patterns generalize labels to include wildcards over packages and
+targets. For example, `foo/...:all` (or just `foo/...`) is a target pattern
+that evaluates to a set containing all _rules_ in every package recursively
+beneath the `foo` directory; `bar/baz:all` is a target pattern that evaluates
+to a set containing all the rules in the `bar/baz` package, but not its
+subpackages.
+
+Similarly, `foo/...:*` is a target pattern that evaluates to a set containing
+all _targets_ (rules _and_ files) in every package recursively beneath the
+`foo` directory; `bar/baz:*` evaluates to a set containing all the targets in
+the `bar/baz` package, but not its subpackages.
+
+Because the `:*` wildcard matches files as well as rules, it's often more
+useful than `:all` for queries. Conversely, the `:all` wildcard (implicit in
+target patterns like `foo/...`) is typically more useful for builds.
+
+`bazel query` target patterns work the same as `bazel build` build targets do.
+For more details, see [Target Patterns](/versions/9.1.0/docs/user-manual#target-patterns), or
+type `bazel help target-syntax`.
+
+Target patterns may evaluate to a singleton set (in the case of a label), to a
+set containing many elements (as in the case of `foo/...`, which has thousands
+of elements) or to the empty set, if the target pattern matches no targets.
+
+All nodes in the result of a target pattern expression are correctly ordered
+relative to each other according to the dependency relation. So, the result of
+`foo:*` is not just the set of targets in package `foo`, it is also the
+_graph_ over those targets. (No guarantees are made about the relative ordering
+of the result nodes against other nodes.) For more details, see the
+[graph order](#graph-order) section.
+
+### Variables {:#variables}
+
+```none {:.devsite-disable-click-to-copy}
+expr ::= let {{ '' }}name{{ '' }} = {{ '' }}expr{{ '' }}{{ '' }}1{{ '' }} in {{ '' }}expr{{ '' }}{{ '' }}2{{ '' }}
+       | {{ '' }}$name{{ '' }}
+```
+
+The Bazel query language allows definitions of and references to
+variables. The result of evaluation of a `let` expression is the same as
+that of {{ '' }}expr{{ '' }}2, with all free occurrences
+of variable {{ '' }}name{{ '' }} replaced by the value of
+{{ '' }}expr{{ '' }}1.
+
+For example, `let v = foo/... in allpaths($v, //common) intersect $v` is
+equivalent to the `allpaths(foo/...,//common) intersect foo/...`.
+
+An occurrence of a variable reference `name` other than in
+an enclosing `let {{ '' }}name{{ '' }} = ...` expression is an
+error. In other words, top-level query expressions cannot have free
+variables.
+
+In the above grammar productions, `name` is like _word_, but with the
+additional constraint that it be a legal identifier in the C programming
+language. References to the variable must be prepended with the "$" character.
+
+Each `let` expression defines only a single variable, but you can nest them.
+
+Both [target patterns](#target-patterns) and variable references consist of
+just a single token, a word, creating a syntactic ambiguity. However, there is
+no semantic ambiguity, because the subset of words that are legal variable
+names is disjoint from the subset of words that are legal target patterns.
+
+Technically speaking, `let` expressions do not increase
+the expressiveness of the query language: any query expressible in
+the language can also be expressed without them. However, they
+improve the conciseness of many queries, and may also lead to more
+efficient query evaluation.
+
+### Parenthesized expressions {:#parenthesized-expressions}
+
+```none {:.devsite-disable-click-to-copy}
+expr ::= ({{ '' }}expr{{ '' }})
+```
+
+Parentheses associate subexpressions to force an order of evaluation.
+A parenthesized expression evaluates to the value of its argument.
+
+### Algebraic set operations: intersection, union, set difference {:#algebraic-set-operations}
+
+```none {:.devsite-disable-click-to-copy}
+expr ::= {{ '' }}expr{{ '' }} intersect {{ '' }}expr{{ '' }}
+       | {{ '' }}expr{{ '' }} ^ {{ '' }}expr{{ '' }}
+       | {{ '' }}expr{{ '' }} union {{ '' }}expr{{ '' }}
+       | {{ '' }}expr{{ '' }} + {{ '' }}expr{{ '' }}
+       | {{ '' }}expr{{ '' }} except {{ '' }}expr{{ '' }}
+       | {{ '' }}expr{{ '' }} - {{ '' }}expr{{ '' }}
+```
+
+These three operators compute the usual set operations over their arguments.
+Each operator has two forms, a nominal form, such as `intersect`, and a
+symbolic form, such as `^`. Both forms are equivalent; the symbolic forms are
+quicker to type. (For clarity, the rest of this page uses the nominal forms.)
+
+For example,
+
+```
+foo/... except foo/bar/...
+```
+
+evaluates to the set of targets that match `foo/...` but not `foo/bar/...`.
+
+You can write the same query as:
+
+```
+foo/... - foo/bar/...
+```
+
+The `intersect` (`^`) and `union` (`+`) operations are commutative (symmetric);
+`except` (`-`) is asymmetric. The parser treats all three operators as
+left-associative and of equal precedence, so you might want parentheses. For
+example, the first two of these expressions are equivalent, but the third is not:
+
+```
+x intersect y union z
+(x intersect y) union z
+x intersect (y union z)
+```
+
+Important: Use parentheses where there is any danger of ambiguity in reading a
+query expression.
+
+### Read targets from an external source: set {:#set}
+
+```none {:.devsite-disable-click-to-copy}
+expr ::= set({{ '' }}word{{ '' }} *)
+```
+
+The `set({{ '' }}a{{ '' }} {{ '' }}b{{ '' }} {{ '' }}c{{ '' }} ...)`
+operator computes the union of a set of zero or more
+[target patterns](#target-patterns), separated by whitespace (no commas).
+
+In conjunction with the Bourne shell's `$(...)` feature, `set()` provides a
+means of saving the results of one query in a regular text file, manipulating
+that text file using other programs (such as standard UNIX shell tools), and then
+introducing the result back into the query tool as a value for further
+processing. For example:
+
+```posix-terminal
+bazel query deps(//my:target) --output=label | grep ... | sed ... | awk ... > foo
+
+bazel query "kind(cc_binary, set($( foo
+
+bazel query "kind(cc_library, set($(' }}word{{ '' }} '(' {{ '' }}int{{ '' }} | {{ '' }}word{{ '' }} | {{ '' }}expr{{ '' }} ... ')'
+```
+
+The query language defines several functions. The name of the function
+determines the number and type of arguments it requires. The following
+functions are available:
+
+* [`allpaths`](#somepath-allpaths)
+* [`attr`](#attr)
+* [`buildfiles`](#buildfiles)
+* [`rbuildfiles`](#rbuildfiles)
+* [`deps`](#deps)
+* [`filter`](#filter)
+* [`kind`](#kind)
+* [`labels`](#labels)
+* [`loadfiles`](#loadfiles)
+* [`rdeps`](#rdeps)
+* [`allrdeps`](#allrdeps)
+* [`same_pkg_direct_rdeps`](#same_pkg_direct_rdeps)
+* [`siblings`](#siblings)
+* [`some`](#some)
+* [`somepath`](#somepath-allpaths)
+* [`tests`](#tests)
+* [`visible`](#visible)
+
+
+### Transitive closure of dependencies: deps {:#deps}
+
+```none {:.devsite-disable-click-to-copy}
+expr ::= deps({{ '' }}expr{{ '' }})
+       | deps({{ '' }}expr{{ '' }}, {{ '' }}depth{{ '' }})
+```
+
+The `deps({{ '' }}x{{ '' }})` operator evaluates to the graph formed
+by the transitive closure of dependencies of its argument set
+{{ '' }}x{{ '' }}. For example, the value of `deps(//foo)` is the
+dependency graph rooted at the single node `foo`, including all its
+dependencies. The value of `deps(foo/...)` is the dependency graphs whose roots
+are all rules in every package beneath the `foo` directory. In this context,
+'dependencies' means only rule and file targets, therefore the `BUILD` and
+Starlark files needed to create these targets are not included here. For that
+you should use the [`buildfiles`](#buildfiles) operator.
+
+The resulting graph is ordered according to the dependency relation. For more
+details, see the section on [graph order](#graph-order).
+
+The `deps` operator accepts an optional second argument, which is an integer
+literal specifying an upper bound on the depth of the search. So
+`deps(foo:*, 0)` returns all targets in the `foo` package, while
+`deps(foo:*, 1)` further includes the direct prerequisites of any target in the
+`foo` package, and `deps(foo:*, 2)` further includes the nodes directly
+reachable from the nodes in `deps(foo:*, 1)`, and so on. (These numbers
+correspond to the ranks shown in the [`minrank`](#output-ranked) output format.)
+If the {{ '' }}depth{{ '' }} parameter is omitted, the search is
+unbounded: it computes the reflexive transitive closure of prerequisites.
+
+### Transitive closure of reverse dependencies: rdeps {:#rdeps}
+
+```none {:.devsite-disable-click-to-copy}
+expr ::= rdeps({{ '' }}expr{{ '' }}, {{ '' }}expr{{ '' }})
+       | rdeps({{ '' }}expr{{ '' }}, {{ '' }}expr{{ '' }}, {{ '' }}depth{{ '' }})
+```
+
+The `rdeps({{ '' }}u{{ '' }}, {{ '' }}x{{ '' }})`
+operator evaluates to the reverse dependencies of the argument set
+{{ '' }}x{{ '' }} within the transitive closure of the universe set
+{{ '' }}u{{ '' }}.
+
+The resulting graph is ordered according to the dependency relation. See the
+section on [graph order](#graph-order) for more details.
+
+The `rdeps` operator accepts an optional third argument, which is an integer
+literal specifying an upper bound on the depth of the search. The resulting
+graph only includes nodes within a distance of the specified depth from any
+node in the argument set. So `rdeps(//foo, //common, 1)` evaluates to all nodes
+in the transitive closure of `//foo` that directly depend on `//common`. (These
+numbers correspond to the ranks shown in the [`minrank`](#output-ranked) output
+format.) If the {{ '' }}depth{{ '' }} parameter is omitted, the
+search is unbounded.
+
+### Transitive closure of all reverse dependencies: allrdeps {:#allrdeps}
+
+```
+expr ::= allrdeps({{ '' }}expr{{ '' }})
+       | allrdeps({{ '' }}expr{{ '' }}, {{ '' }}depth{{ '' }})
+```
+
+Note: Only available with [Sky Query](#sky-query)
+
+The `allrdeps` operator behaves just like the [`rdeps`](#rdeps)
+operator, except that the "universe set" is whatever the `--universe_scope` flag
+evaluated to, instead of being separately specified. Thus, if
+`--universe_scope=//foo/...` was passed, then `allrdeps(//bar)` is
+equivalent to `rdeps(//foo/..., //bar)`.
+
+### Direct reverse dependencies in the same package: same_pkg_direct_rdeps {:#same_pkg_direct_rdeps}
+
+```
+expr ::= same_pkg_direct_rdeps({{ '' }}expr{{ '' }})
+```
+
+The `same_pkg_direct_rdeps({{ '' }}x{{ '' }})` operator evaluates to the full set of targets
+that are in the same package as a target in the argument set, and which directly depend on it.
+
+### Dealing with a target's package: siblings {:#siblings}
+
+```
+expr ::= siblings({{ '' }}expr{{ '' }})
+```
+
+The `siblings({{ '' }}x{{ '' }})` operator evaluates to the full set of targets that are in
+the same package as a target in the argument set.
+
+### Arbitrary choice: some {:#some}
+
+```
+expr ::= some({{ '' }}expr{{ '' }})
+       | some({{ '' }}expr{{ '' }}, {{ '' }}count{{ ' '}})
+```
+
+The `some({{ '' }}x{{ '' }}, {{ '' }}k{{ '' }})` operator
+selects at most {{ '' }}k{{ '' }} targets arbitrarily from its
+argument set {{ '' }}x{{ '' }}, and evaluates to a set containing
+only those targets. Parameter {{ '' }}k{{ '' }} is optional; if
+missing, the result will be a singleton set containing only one target
+arbitrarily selected. If the size of argument set {{ '' }}x{{ '' }} is
+smaller than {{ '' }}k{{ '' }}, the whole argument set
+{{ '' }}x{{ '' }} will be returned.
+
+For example, the expression `some(//foo:main union //bar:baz)` evaluates to a
+singleton set containing either `//foo:main` or `//bar:baz`—though which
+one is not defined. The expression `some(//foo:main union //bar:baz, 2)` or
+`some(//foo:main union //bar:baz, 3)` returns both `//foo:main` and
+`//bar:baz`.
+
+If the argument is a singleton, then `some`
+computes the identity function: `some(//foo:main)` is
+equivalent to `//foo:main`.
+
+It is an error if the specified argument set is empty, as in the
+expression `some(//foo:main intersect //bar:baz)`.
+
+### Path operators: somepath, allpaths {:#somepath-allpaths}
+
+```
+expr ::= somepath({{ '' }}expr{{ '' }}, {{ '' }}expr{{ '' }})
+       | allpaths({{ '' }}expr{{ '' }}, {{ '' }}expr{{ '' }})
+```
+
+The `somepath({{ '' }}S{{ '' }}, {{ '' }}E{{ '' }})` and
+`allpaths({{ '' }}S{{ '' }}, {{ '' }}E{{ '' }})` operators compute
+paths between two sets of targets. Both queries accept two
+arguments, a set {{ '' }}S{{ '' }} of starting points and a set
+{{ '' }}E{{ '' }} of ending points. `somepath` returns the
+graph of nodes on _some_ arbitrary path from a target in
+{{ '' }}S{{ '' }} to a target in {{ '' }}E{{ '' }}; `allpaths`
+returns the graph of nodes on _all_ paths from any target in
+{{ '' }}S{{ '' }} to any target in {{ '' }}E{{ '' }}.
+
+The resulting graphs are ordered according to the dependency relation.
+See the section on [graph order](#graph-order) for more details.
+
+
+  
+    
+    
+    
+  
+

+      

+        Somepath
+        
somepath(S1 + S2, E), one possible result.

+      

+
+    		
+      

+        Somepath
+        
somepath(S1 + S2, E), another possible result.

+      

+
+    		
+      

+        Allpaths
+        
allpaths(S1 + S2, E)

+      

+
+    

+
+### Target kind filtering: kind {:#kind}
+
+```
+expr ::= kind({{ '' }}word{{ '' }}, {{ '' }}expr{{ '' }})
+```
+
+The `kind({{ '' }}pattern{{ '' }}, {{ '' }}input{{ '' }})`
+operator applies a filter to a set of targets, and discards those targets
+that are not of the expected kind. The {{ '' }}pattern{{ '' }}
+parameter specifies what kind of target to match.
+
+For example, the kinds for the four targets defined by the `BUILD` file
+(for package `p`) shown below are illustrated in the table:
+
+
+  
+    
+    
+    
+  
+  
+    
+    
+    
+  
+  
+    
+    
+  
+  
+    
+    
+  
+  
+    
+    
+  
+
CodeTargetKind

+      
+        genrule(
+            name = "a",
+            srcs = ["a.in"],
+            outs = ["a.out"],
+            cmd = "...",
+        )
+      

+    		//p:agenrule rule
//p:a.insource file
//p:a.outgenerated file
//p:BUILDsource file

+
+Thus, `kind("cc_.* rule", foo/...)` evaluates to the set
+of all `cc_library`, `cc_binary`, etc,
+rule targets beneath `foo`, and `kind("source file", deps(//foo))`
+evaluates to the set of all source files in the transitive closure
+of dependencies of the `//foo` target.
+
+Quotation of the {{ '' }}pattern{{ '' }} argument is often required
+because without it, many [regular expressions](#regex), such as `source
+file` and `.*_test`, are not considered words by the parser.
+
+When matching for `package group`, targets ending in
+`:all` may not yield any results. Use `:all-targets` instead.
+
+### Target name filtering: filter {:#filter}
+
+```
+expr ::= filter({{ '' }}word{{ '' }}, {{ '' }}expr{{ '' }})
+```
+
+The `filter({{ '' }}pattern{{ '' }}, {{ '' }}input{{ '' }})`
+operator applies a filter to a set of targets, and discards targets whose
+labels (in absolute form) do not match the pattern; it
+evaluates to a subset of its input.
+
+The first argument, {{ '' }}pattern{{ '' }} is a word containing a
+[regular expression](#regex) over target names. A `filter` expression
+evaluates to the set containing all targets {{ '' }}x{{ '' }} such that
+{{ '' }}x{{ '' }} is a member of the set {{ '' }}input{{ '' }} and the
+label (in absolute form, such as `//foo:bar`)
+of {{ '' }}x{{ '' }} contains an (unanchored) match
+for the regular expression {{ '' }}pattern{{ '' }}. Since all
+target names start with `//`, it may be used as an alternative
+to the `^` regular expression anchor.
+
+This operator often provides a much faster and more robust alternative to the
+`intersect` operator. For example, in order to see all
+`bar` dependencies of the `//foo:foo` target, one could
+evaluate
+
+```
+deps(//foo) intersect //bar/...
+```
+
+This statement, however, will require parsing of all `BUILD` files in the
+`bar` tree, which will be slow and prone to errors in
+irrelevant `BUILD` files. An alternative would be:
+
+```
+filter(//bar, deps(//foo))
+```
+
+which would first calculate the set of `//foo` dependencies and
+then would filter only targets matching the provided pattern—in other
+words, targets with names containing `//bar` as a substring.
+
+Another common use of the `filter({{ '' }}pattern{{ '' }},
+{{ '' }}expr{{ '' }})` operator is to filter specific files by their
+name or extension. For example,
+
+```
+filter("\.cc$", deps(//foo))
+```
+
+will provide a list of all `.cc` files used to build `//foo`.
+
+### Rule attribute filtering: attr {:#attr}
+
+```
+expr ::= attr({{ '' }}word{{ '' }}, {{ '' }}word{{ '' }}, {{ '' }}expr{{ '' }})
+```
+
+The
+`attr({{ '' }}name{{ '' }}, {{ '' }}pattern{{ '' }}, {{ '' }}input{{ '' }})`
+operator applies a filter to a set of targets, and discards targets that aren't
+rules, rule targets that do not have attribute {{ '' }}name{{ '' }}
+defined or rule targets where the attribute value does not match the provided
+[regular expression](#regex) {{ '' }}pattern{{ '' }}; it evaluates
+to a subset of its input.
+
+The first argument, {{ '' }}name{{ '' }} is the name of the rule
+attribute that should be matched against the provided
+[regular expression](#regex) pattern. The second argument,
+{{ '' }}pattern{{ '' }} is a regular expression over the attribute
+values. An `attr` expression evaluates to the set containing all targets
+{{ '' }}x{{ '' }} such that  {{ '' }}x{{ '' }} is a
+member of the set {{ '' }}input{{ '' }}, is a rule with the defined
+attribute {{ '' }}name{{ '' }} and the attribute value contains an
+(unanchored) match for the regular expression
+{{ '' }}pattern{{ '' }}. If {{ '' }}name{{ '' }} is an
+optional attribute and rule does not specify it explicitly then default
+attribute value will be used for comparison. For example,
+
+```
+attr(linkshared, 0, deps(//foo))
+```
+
+will select all `//foo` dependencies that are allowed to have a
+linkshared attribute (such as, `cc_binary` rule) and have it either
+explicitly set to 0 or do not set it at all but default value is 0 (such as for
+`cc_binary` rules).
+
+List-type attributes (such as `srcs`, `data`, etc) are
+converted to strings of the form `[value1, ..., valuen]`,
+starting with a `[` bracket, ending with a `]` bracket
+and using "`, `" (comma, space) to delimit multiple values.
+Labels are converted to strings by using the absolute form of the
+label. For example, an attribute `deps=[":foo",
+"//otherpkg:bar", "wiz"]` would be converted to the
+string `[//thispkg:foo, //otherpkg:bar, //thispkg:wiz]`.
+Brackets are always present, so the empty list would use string value `[]`
+for matching purposes. For example,
+
+```
+attr("srcs", "\[\]", deps(//foo))
+```
+
+will select all rules among `//foo` dependencies that have an
+empty `srcs` attribute, while
+
+```
+attr("data", ".{3,}", deps(//foo))
+```
+
+will select all rules among `//foo` dependencies that specify at
+least one value in the `data` attribute (every label is at least
+3 characters long due to the `//` and `:`).
+
+To select all rules among `//foo` dependencies with a particular `value` in a
+list-type attribute, use
+
+```
+attr("tags", "[\[ ]value[,\]]", deps(//foo))
+```
+
+This works because the character before `value` will be `[` or a space and the
+character after `value` will be a comma or `]`.
+
+To select all rules among `//foo` dependencies with a particular `key` and
+`value` in a dict-type attribute, use
+
+```
+attr("some_dict_attribute", "[\{ ]key=value[,\}]", deps(//foo))
+```
+
+This would select `//foo` if `//foo` is defined as
+
+```
+some_rule(
+  name = "foo",
+  some_dict_attribute = {
+    "key": "value",
+  },
+)
+```
+
+This works because the character before `key=value` will be `{` or a space and
+the character after `key=value` will be a comma or `}`.
+
+### Rule visibility filtering: visible {:#visible}
+
+```
+expr ::= visible({{ '' }}expr{{ '' }}, {{ '' }}expr{{ '' }})
+```
+
+The `visible({{ '' }}predicate{{ '' }}, {{ '' }}input{{ '' }})` operator
+applies a filter to a set of targets, and discards targets without the
+required visibility.
+
+The first argument, {{ '' }}predicate{{ '' }}, is a set of targets that all targets
+in the output must be visible to. A {{ '' }}visible{{ '' }} expression
+evaluates to the set containing all targets {{ '' }}x{{ '' }} such that {{ '' }}x{{ '' }}
+is a member of the set {{ '' }}input{{ '' }}, and for all targets {{ '' }}y{{ '' }} in
+{{ '' }}predicate{{ '' }} {{ '' }}x{{ '' }} is visible to {{ '' }}y{{ '' }}. For example:
+
+```
+visible(//foo, //bar:*)
+```
+
+will select all targets in the package `//bar` that `//foo`
+can depend on without violating visibility restrictions.
+
+### Evaluation of rule attributes of type label: labels {:#labels}
+
+```
+expr ::= labels({{ '' }}word{{ '' }}, {{ '' }}expr{{ '' }})
+```
+
+The `labels({{ '' }}attr_name{{ '' }}, {{ '' }}inputs{{ '' }})`
+operator returns the set of targets specified in the
+attribute {{ '' }}attr_name{{ '' }} of type "label" or "list of label" in
+some rule in set {{ '' }}inputs{{ '' }}.
+
+For example, `labels(srcs, //foo)` returns the set of
+targets appearing in the `srcs` attribute of
+the `//foo` rule. If there are multiple rules
+with `srcs` attributes in the {{ '' }}inputs{{ '' }} set, the
+union of their `srcs` is returned.
+
+### Expand and filter test_suites: tests {:#tests}
+
+```
+expr ::= tests({{ '' }}expr{{ '' }})
+```
+
+The `tests({{ '' }}x{{ '' }})` operator returns the set of all test
+rules in set {{ '' }}x{{ '' }}, expanding any `test_suite` rules into
+the set of individual tests that they refer to, and applying filtering by
+`tag` and `size`.
+
+By default, query evaluation
+ignores any non-test targets in all `test_suite` rules. This can be
+changed to errors with the `--strict_test_suite` option.
+
+For example, the query `kind(test, foo:*)` lists all
+the `*_test` and `test_suite` rules
+in the `foo` package. All the results are (by
+definition) members of the `foo` package. In contrast,
+the query `tests(foo:*)` will return all of the
+individual tests that would be executed by `bazel test
+foo:*`: this may include tests belonging to other packages,
+that are referenced directly or indirectly
+via `test_suite` rules.
+
+### Package definition files: buildfiles {:#buildfiles}
+
+```
+expr ::= buildfiles({{ '' }}expr{{ '' }})
+```
+
+The `buildfiles({{ '' }}x{{ '' }})` operator returns the set
+of files that define the packages of each target in
+set {{ '' }}x{{ '' }}; in other words, for each package, its `BUILD` file,
+plus any .bzl files it references via `load`. Note that this
+also returns the `BUILD` files of the packages containing these
+`load`ed files.
+
+This operator is typically used when determining what files or
+packages are required to build a specified target, often in conjunction with
+the [`--output package`](#output-package) option, below). For example,
+
+```posix-terminal
+bazel query 'buildfiles(deps(//foo))' --output package
+```
+
+returns the set of all packages on which `//foo` transitively depends.
+
+Note: A naive attempt at the above query would omit
+the `buildfiles` operator and use only `deps`,
+but this yields an incorrect result: while the result contains the
+majority of needed packages, those packages that contain only files
+that are `load()`'ed will be missing.
+
+Warning: Bazel pretends each `.bzl` file produced by
+`buildfiles` has a corresponding target (for example, file `a/b.bzl` =>
+target `//a:b.bzl`), but this isn't necessarily the case. Therefore,
+`buildfiles` doesn't compose well with other query operators and its results can be
+misleading when formatted in a structured way, such as
+[`--output=xml`](#xml).
+
+### Package definition files: rbuildfiles {:#rbuildfiles}
+
+```
+expr ::= rbuildfiles({{ '' }}word{{ '' }}, ...)
+```
+
+Note: Only available with [Sky Query](#sky-query).
+
+The `rbuildfiles` operator takes a comma-separated list of path fragments and returns
+the set of `BUILD` files that transitively depend on these path fragments. For instance, if
+`//foo` is a package, then `rbuildfiles(foo/BUILD)` will return the
+`//foo:BUILD` target. If the `foo/BUILD` file has
+`load('//bar:file.bzl'...` in it, then `rbuildfiles(bar/file.bzl)` will
+return the `//foo:BUILD` target, as well as the targets for any other `BUILD` files that
+load `//bar:file.bzl`
+
+The scope of the rbuildfiles operator is the universe specified by the
+`--universe_scope` flag. Files that do not correspond directly to `BUILD` files and `.bzl`
+files do not affect the results. For instance, source files (like `foo.cc`) are ignored,
+even if they are explicitly mentioned in the `BUILD` file. Symlinks, however, are respected, so that
+if `foo/BUILD` is a symlink to `bar/BUILD`, then
+`rbuildfiles(bar/BUILD)` will include `//foo:BUILD` in its results.
+
+The `rbuildfiles` operator is almost morally the inverse of the
+[`buildfiles`](#buildfiles) operator. However, this moral inversion
+holds more strongly in one direction: the outputs of `rbuildfiles` are just like the
+inputs of `buildfiles`; the former will only contain `BUILD` file targets in packages,
+and the latter may contain such targets. In the other direction, the correspondence is weaker. The
+outputs of the `buildfiles` operator are targets corresponding to all packages and .`bzl`
+files needed by a given input. However, the inputs of the `rbuildfiles` operator are
+not those targets, but rather the path fragments that correspond to those targets.
+
+### Package definition files: loadfiles {:#loadfiles}
+
+```
+expr ::= loadfiles({{ '' }}expr{{ '' }})
+```
+
+The `loadfiles({{ '' }}x{{ '' }})` operator returns the set of
+Starlark files that are needed to load the packages of each target in
+set {{ '' }}x{{ '' }}. In other words, for each package, it returns the
+.bzl files that are referenced from its `BUILD` files.
+
+Warning: Bazel pretends each of these .bzl files has a corresponding target
+(for example, file `a/b.bzl` => target `//a:b.bzl`), but this isn't
+necessarily the case. Therefore, `loadfiles` doesn't compose well with other query
+operators and its results can be misleading when formatted in a structured way, such as
+[`--output=xml`](#xml).
+
+## Output formats {:#output-formats}
+
+`bazel query` generates a graph.
+You specify the content, format, and ordering by which
+`bazel query` presents this graph
+by means of the `--output` command-line option.
+
+When running with [Sky Query](#sky-query), only output formats that are compatible with
+unordered output are allowed. Specifically, `graph`, `minrank`, and
+`maxrank` output formats are forbidden.
+
+Some of the output formats accept additional options. The name of
+each output option is prefixed with the output format to which it
+applies, so `--graph:factored` applies only
+when `--output=graph` is being used; it has no effect if
+an output format other than `graph` is used. Similarly,
+`--xml:line_numbers` applies only when `--output=xml`
+is being used.
+
+### On the ordering of results {:#results-ordering}
+
+Although query expressions always follow the "[law of
+conservation of graph order](#graph-order)", _presenting_ the results may be done
+in either a dependency-ordered or unordered manner. This does **not**
+influence the targets in the result set or how the query is computed. It only
+affects how the results are printed to stdout. Moreover, nodes that are
+equivalent in the dependency order may or may not be ordered alphabetically.
+The `--order_output` flag can be used to control this behavior.
+(The `--[no]order_results` flag has a subset of the functionality
+of the `--order_output` flag and is deprecated.)
+
+The default value of this flag is `auto`, which prints results in **lexicographical
+order**. However, when `somepath(a,b)` is used, the results will be printed in
+`deps` order instead.
+
+When this flag is `no` and `--output` is one of
+`build`, `label`, `label_kind`, `location`, `package`, `proto`, or
+`xml`, the outputs will be printed in arbitrary order. **This is
+generally the fastest option**. It is not supported though when
+`--output` is one of `graph`, `minrank` or
+`maxrank`: with these formats, Bazel always prints results
+ordered by the dependency order or rank.
+
+When this flag is `deps`, Bazel prints results in some topological order—that is,
+dependents first and dependencies after. However, nodes that are unordered by the
+dependency order (because there is no path from either one to the other) may be
+printed in any order.
+
+When this flag is `full`, Bazel prints nodes in a fully deterministic (total) order.
+First, all nodes are sorted alphabetically. Then, each node in the list is used as the start of a
+post-order depth-first search in which outgoing edges to unvisited nodes are traversed in
+alphabetical order of the successor nodes. Finally, nodes are printed in the reverse of the order
+in which they were visited.
+
+Printing nodes in this order may be slower, so it should be used only when determinism is
+important.
+
+### Print the source form of targets as they would appear in BUILD {:#target-source-form}
+
+```
+--output build
+```
+
+With this option, the representation of each target is as if it were
+hand-written in the BUILD language. All variables and function calls
+(such as glob, macros) are expanded, which is useful for seeing the effect
+of Starlark macros. Additionally, each effective rule reports a
+`generator_name` and/or `generator_function`) value,
+giving the name of the macro that was evaluated to produce the effective rule.
+
+Although the output uses the same syntax as `BUILD` files, it is not
+guaranteed to produce a valid `BUILD` file.
+
+### Print the label of each target {:#print-label-target}
+
+```
+--output label
+```
+
+With this option, the set of names (or _labels_) of each target
+in the resulting graph is printed, one label per line, in
+topological order (unless `--noorder_results` is specified, see
+[notes on the ordering of results](#result-order)).
+(A topological ordering is one in which a graph
+node appears earlier than all of its successors.)  Of course there
+are many possible topological orderings of a graph (_reverse
+postorder_ is just one); which one is chosen is not specified.
+
+When printing the output of a `somepath` query, the order
+in which the nodes are printed is the order of the path.
+
+Caveat: in some corner cases, there may be two distinct targets with
+the same label; for example, a `sh_binary` rule and its
+sole (implicit) `srcs` file may both be called
+`foo.sh`. If the result of a query contains both of
+these targets, the output (in `label` format) will appear
+to contain a duplicate. When using the `label_kind` (see
+below) format, the distinction becomes clear: the two targets have
+the same name, but one has kind `sh_binary rule` and the
+other kind `source file`.
+
+### Print the label and kind of each target {:#print-target-label}
+
+```
+--output label_kind
+```
+
+Like `label`, this output format prints the labels of
+each target in the resulting graph, in topological order, but it
+additionally precedes the label by the [_kind_](#kind) of the target.
+
+### Print targets in protocol buffer format {:#print-target-proto}
+
+```
+--output proto
+```
+
+Prints the query output as a
+[`QueryResult`](https://github.com/bazelbuild/bazel/blob/master/src/main/protobuf/build.proto)
+protocol buffer.
+
+### Print targets in length-delimited protocol buffer format {:#print-target-length-delimited-proto}
+
+```
+--output streamed_proto
+```
+
+Prints a
+[length-delimited](https://protobuf.dev/programming-guides/encoding/#size-limit)
+stream of
+[`Target`](https://github.com/bazelbuild/bazel/blob/master/src/main/protobuf/build.proto)
+protocol buffers. This is useful to _(i)_ get around
+[size limitations](https://protobuf.dev/programming-guides/encoding/#size-limit)
+of protocol buffers when there are too many targets to fit in a single
+`QueryResult` or _(ii)_ to start processing while Bazel is still outputting.
+
+### Print targets in text proto format {:#print-target-textproto}
+
+```
+--output textproto
+```
+
+Similar to `--output proto`, prints the
+[`QueryResult`](https://github.com/bazelbuild/bazel/blob/master/src/main/protobuf/build.proto)
+protocol buffer but in
+[text format](https://protobuf.dev/reference/protobuf/textformat-spec/).
+
+### Print targets in ndjson format {:#print-target-streamed-jsonproto}
+
+```
+--output streamed_jsonproto
+```
+
+Similar to `--output streamed_proto`, prints a stream of
+[`Target`](https://github.com/bazelbuild/bazel/blob/master/src/main/protobuf/build.proto)
+protocol buffers but in [ndjson](https://github.com/ndjson/ndjson-spec) format.
+
+### Print the label of each target, in rank order {:#print-target-label-rank-order}
+
+```
+--output minrank --output maxrank
+```
+
+Like `label`, the `minrank`
+and `maxrank` output formats print the labels of each
+target in the resulting graph, but instead of appearing in
+topological order, they appear in rank order, preceded by their
+rank number. These are unaffected by the result ordering
+`--[no]order_results` flag (see [notes on
+the ordering of results](#result-order)).
+
+There are two variants of this format: `minrank` ranks
+each node by the length of the shortest path from a root node to it.
+"Root" nodes (those which have no incoming edges) are of rank 0,
+their successors are of rank 1, etc. (As always, edges point from a
+target to its prerequisites: the targets it depends upon.)
+
+`maxrank` ranks each node by the length of the longest
+path from a root node to it. Again, "roots" have rank 0, all other
+nodes have a rank which is one greater than the maximum rank of all
+their predecessors.
+
+All nodes in a cycle are considered of equal rank. (Most graphs are
+acyclic, but cycles do occur
+simply because `BUILD` files contain erroneous cycles.)
+
+These output formats are useful for discovering how deep a graph is.
+If used for the result of a `deps(x)`, `rdeps(x)`,
+or `allpaths` query, then the rank number is equal to the
+length of the shortest (with `minrank`) or longest
+(with `maxrank`) path from `x` to a node in
+that rank. `maxrank` can be used to determine the
+longest sequence of build steps required to build a target.
+
+Note: The ranked output of a `somepath` query is
+basically meaningless because `somepath` doesn't
+guarantee to return either a shortest or a longest path, and it may
+include "transitive" edges from one path node to another that are
+not direct edges in original graph.
+
+For example, the graph on the left yields the outputs on the right
+when `--output minrank` and `--output maxrank`
+are specified, respectively.
+
+
+  
+    
+    
+    
+  
+
Out ranked
+    
+      
+      minrank
+
+      0 //c:c
+      1 //b:b
+      1 //a:a
+      2 //b:b.cc
+      2 //a:a.cc
+      

+    		
+      
+      maxrank
+
+      0 //c:c
+      1 //b:b
+      2 //a:a
+      2 //b:b.cc
+      3 //a:a.cc
+      

+    

+
+### Print the location of each target {:#print-target-location}
+
+```
+--output location
+```
+
+Like `label_kind`, this option prints out, for each
+target in the result, the target's kind and label, but it is
+prefixed by a string describing the location of that target, as a
+filename and line number. The format resembles the output of
+`grep`. Thus, tools that can parse the latter (such as Emacs
+or vi) can also use the query output to step through a series of
+matches, allowing the Bazel query tool to be used as a
+dependency-graph-aware "grep for BUILD files".
+
+The location information varies by target kind (see the [kind](#kind) operator). For rules, the
+location of the rule's declaration within the `BUILD` file is printed.
+For source files, the location of line 1 of the actual file is
+printed. For a generated file, the location of the rule that
+generates it is printed. (The query tool does not have sufficient
+information to find the actual location of the generated file, and
+in any case, it might not exist if a build has not yet been performed.)
+
+### Print the set of packages {:#print-package-set}
+
+```--output package```
+
+This option prints the name of all packages to which
+some target in the result set belongs. The names are printed in
+lexicographical order; duplicates are excluded. Formally, this
+is a _projection_ from the set of labels (package, target) onto
+packages.
+
+Packages in external repositories are formatted as
+`@repo//foo/bar` while packages in the main repository are
+formatted as `foo/bar`.
+
+In conjunction with the `deps(...)` query, this output
+option can be used to find the set of packages that must be checked
+out in order to build a given set of targets.
+
+### Display a graph of the result {:#display-result-graph}
+
+```--output graph```
+
+This option causes the query result to be printed as a directed
+graph in the popular AT&T GraphViz format. Typically the
+result is saved to a file, such as `.png` or `.svg`.
+(If the `dot` program is not installed on your workstation, you
+can install it using the command `sudo apt-get install graphviz`.)
+See the example section below for a sample invocation.
+
+This output format is particularly useful for `allpaths`,
+`deps`, or `rdeps` queries, where the result
+includes a _set of paths_ that cannot be easily visualized when
+rendered in a linear form, such as with `--output label`.
+
+By default, the graph is rendered in a _factored_ form. That is,
+topologically-equivalent nodes are merged together into a single
+node with multiple labels. This makes the graph more compact
+and readable, because typical result graphs contain highly
+repetitive patterns. For example, a `java_library` rule
+may depend on hundreds of Java source files all generated by the
+same `genrule`; in the factored graph, all these files
+are represented by a single node. This behavior may be disabled
+with the `--nograph:factored` option.
+
+#### `--graph:node_limit {{ '' }}n{{ '' }}` {:#graph-nodelimit}
+
+The option specifies the maximum length of the label string for a
+graph node in the output. Longer labels will be truncated; -1
+disables truncation. Due to the factored form in which graphs are
+usually printed, the node labels may be very long. GraphViz cannot
+handle labels exceeding 1024 characters, which is the default value
+of this option. This option has no effect unless
+`--output=graph` is being used.
+
+#### `--[no]graph:factored` {:#graph-factored}
+
+By default, graphs are displayed in factored form, as explained
+[above](#output-graph).
+When `--nograph:factored` is specified, graphs are
+printed without factoring. This makes visualization using GraphViz
+impractical, but the simpler format may ease processing by other
+tools (such as grep). This option has no effect
+unless `--output=graph` is being used.
+
+### XML {:#xml}
+
+```--output xml```
+
+This option causes the resulting targets to be printed in an XML
+form. The output starts with an XML header such as this
+
+```
+  
+  
+```
+
+
+
+and then continues with an XML element for each target
+in the result graph, in topological order (unless
+[unordered results](#result-order) are requested),
+and then finishes with a terminating
+
+```
+
+```
+
+Simple entries are emitted for targets of `file` kind:
+
+```
+  
+  
+```
+
+But for rules, the XML is structured and contains definitions of all
+the attributes of the rule, including those whose value was not
+explicitly specified in the rule's `BUILD` file.
+
+Additionally, the result includes `rule-input` and
+`rule-output` elements so that the topology of the
+dependency graph can be reconstructed without having to know that,
+for example, the elements of the `srcs` attribute are
+forward dependencies (prerequisites) and the contents of the
+`outs` attribute are backward dependencies (consumers).
+
+`rule-input` elements for [implicit dependencies](#implicit_deps) are suppressed if
+`--noimplicit_deps` is specified.
+
+```
+  
+    
+      
+    
+      
+    
+      ...
+    
+    
+    
+    
+    
+      
+    
+    
+    
+    
+    
+    ...
+  
+```
+
+Every XML element for a target contains a `name`
+attribute, whose value is the target's label, and
+a `location` attribute, whose value is the target's
+location as printed by the [`--output location`](#print-target-location).
+
+#### `--[no]xml:line_numbers` {:#xml-linenumbers}
+
+By default, the locations displayed in the XML output contain line numbers.
+When `--noxml:line_numbers` is specified, line numbers are not printed.
+
+#### `--[no]xml:default_values` {:#xml-defaultvalues}
+
+By default, XML output does not include rule attribute whose value
+is the default value for that kind of attribute (for example, if it
+were not specified in the `BUILD` file, or the default value was
+provided explicitly). This option causes such attribute values to
+be included in the XML output.
+
+### Regular expressions {:#regular-expressions}
+
+Regular expressions in the query language use the Java regex library, so you can use the
+full syntax for
+[`java.util.regex.Pattern`](https://docs.oracle.com/javase/8/docs/api/java/util/regex/Pattern.html){: .external}.
+
+### Querying with external repositories {:#querying-external-repositories}
+
+If the build depends on rules from [external repositories](/versions/9.1.0/external/overview)
+then query results will include these dependencies. For
+example, if `//foo:bar` depends on `@other-repo//baz:lib`, then
+`bazel query 'deps(//foo:bar)'` will list `@other-repo//baz:lib` as a
+dependency.
diff --git a/versions/9.1.0/query/quickstart.mdx b/versions/9.1.0/query/quickstart.mdx
new file mode 100644
index 00000000..086f6150
--- /dev/null
+++ b/versions/9.1.0/query/quickstart.mdx
@@ -0,0 +1,501 @@
+---
+title: 'Query quickstart'
+---
+
+This tutorial covers how to work with Bazel to trace dependencies in your code using a premade Bazel project.
+
+For language and `--output` flag details, see the [Bazel query reference](/versions/9.1.0/query/language) and [Bazel cquery reference](/versions/9.1.0/query/cquery) manuals. Get help in your IDE by typing `bazel help query` or `bazel help cquery` on the command line.
+
+## Objective
+
+This guide runs you through a set of basic queries you can use to learn more about your project's file dependencies. It is intended for new Bazel developers with a basic knowledge of how Bazel and `BUILD` files work.
+
+## Prerequisites
+
+Start by installing [Bazel](https://bazel.build/versions/9.1.0/install), if you haven’t already. This tutorial uses Git for source control, so for best results, install [Git](https://github.com/git-guides/install-git) as well.
+
+To visualize dependency graphs, the tool called Graphviz is used, which you can [download](https://graphviz.org/download/) in order to follow along.
+
+### Get the sample project
+
+Next, retrieve the sample app from [Bazel's Examples repository](https://github.com/bazelbuild/examples) by running the following in your command-line tool of choice:
+
+```posix-terminal
+git clone https://github.com/bazelbuild/examples.git
+```
+
+The sample project for this tutorial is in the `examples/query-quickstart` directory.
+
+## Getting started
+
+### What are Bazel queries?
+
+Queries help you to learn about a Bazel codebase by analyzing the relationships between `BUILD` files and examining the resulting output for useful information. This guide previews some basic query functions, but for more options see the [query guide](https://bazel.build/versions/9.1.0/query/guide). Queries help you learn about dependencies in large scale projects without manually navigating through `BUILD` files.
+
+To run a query, open your command line terminal and enter:
+
+```posix-terminal
+bazel query 'query_function'
+```
+
+### Scenario
+
+Imagine a scenario that delves into the relationship between Cafe Bazel and its respective chef. This Cafe exclusively sells pizza and mac & cheese. Take a look below at how the project is structured:
+
+```
+bazelqueryguide
+├── BUILD
+├── src
+│   └── main
+│       └── java
+│           └── com
+│               └── example
+│                   ├── customers
+│                   │   ├── Jenny.java
+│                   │   ├── Amir.java
+│                   │   └── BUILD
+│                   ├── dishes
+│                   │   ├── Pizza.java
+│                   │   ├── MacAndCheese.java
+│                   │   └── BUILD
+│                   ├── ingredients
+│                   │   ├── Cheese.java
+│                   │   ├── Tomatoes.java
+│                   │   ├── Dough.java
+│                   │   ├── Macaroni.java
+│                   │   └── BUILD
+│                   ├── restaurant
+│                   │   ├── Cafe.java
+│                   │   ├── Chef.java
+│                   │   └── BUILD
+│                   ├── reviews
+│                   │   ├── Review.java
+│                   │   └── BUILD
+│                   └── Runner.java
+└── MODULE.bazel
+```
+
+Throughout this tutorial, unless directed otherwise, try not to look in the `BUILD` files to find the information you need and instead solely use the query function.
+
+A project consists of different packages that make up a Cafe. They are separated into: `restaurant`, `ingredients`, `dishes`, `customers`, and `reviews`. Rules within these packages define different components of the Cafe with various tags and dependencies.
+
+### Running a build
+
+This project contains a main method inside of `Runner.java` that you can execute
+to print out a menu of the Cafe. Build the project using Bazel with the command
+`bazel build` and use `:` to signal that the target is named `runner`. See
+[target names](https://bazel.build/versions/9.1.0/concepts/labels#target-names) to learn how to
+reference targets.
+
+To build this project, paste this command into a terminal:
+
+```posix-terminal
+bazel build :runner
+```
+
+Your output should look something like this if the build is successful.
+
+```bash
+INFO: Analyzed target //:runner (49 packages loaded, 784 targets configured).
+INFO: Found 1 target...
+Target //:runner up-to-date:
+  bazel-bin/runner.jar
+  bazel-bin/runner
+INFO: Elapsed time: 16.593s, Critical Path: 4.32s
+INFO: 23 processes: 4 internal, 10 darwin-sandbox, 9 worker.
+INFO: Build completed successfully, 23 total actions
+```
+
+After it has built successfully, run the application by pasting this command:
+
+```posix-terminal
+bazel-bin/runner
+```
+
+```bash
+--------------------- MENU -------------------------
+
+Pizza - Cheesy Delicious Goodness
+Macaroni & Cheese - Kid-approved Dinner
+
+----------------------------------------------------
+```
+This leaves you with a list of the menu items given along with a short description.
+
+## Exploring targets
+
+The project lists ingredients and dishes in their own packages. To use a query to view the rules of a package, run the command bazel query package/…
+
+In this case, you can use this to look through the ingredients and dishes that this Cafe has by running:
+
+```posix-terminal
+bazel query //src/main/java/com/example/dishes/...
+```
+
+```posix-terminal
+bazel query //src/main/java/com/example/ingredients/...
+```
+
+If you query for the targets of the ingredients package, the output should look like:
+
+```bash
+//src/main/java/com/example/ingredients:cheese
+//src/main/java/com/example/ingredients:dough
+//src/main/java/com/example/ingredients:macaroni
+//src/main/java/com/example/ingredients:tomato
+```
+
+## Finding dependencies
+
+What targets does your runner rely on to run?
+
+Say you want to dive deeper into the structure of your project without prodding into the filesystem (which may be untenable for large projects). What rules does Cafe Bazel use?
+
+If, like in this example, the target for your runner is `runner`, discover the underlying dependencies of the target by running the command:
+
+```posix-terminal
+bazel query --noimplicit_deps "deps(target)"
+```
+
+```posix-terminal
+bazel query --noimplicit_deps "deps(:runner)"
+```
+
+```bash
+//:runner
+//:src/main/java/com/example/Runner.java
+//src/main/java/com/example/dishes:MacAndCheese.java
+//src/main/java/com/example/dishes:Pizza.java
+//src/main/java/com/example/dishes:macAndCheese
+//src/main/java/com/example/dishes:pizza
+//src/main/java/com/example/ingredients:Cheese.java
+//src/main/java/com/example/ingredients:Dough.java
+//src/main/java/com/example/ingredients:Macaroni.java
+//src/main/java/com/example/ingredients:Tomato.java
+//src/main/java/com/example/ingredients:cheese
+//src/main/java/com/example/ingredients:dough
+//src/main/java/com/example/ingredients:macaroni
+//src/main/java/com/example/ingredients:tomato
+//src/main/java/com/example/restaurant:Cafe.java
+//src/main/java/com/example/restaurant:Chef.java
+//src/main/java/com/example/restaurant:cafe
+//src/main/java/com/example/restaurant:chef
+```
+Note: Adding the flag `--noimplicit_deps` removes configurations and potential toolchains to simplify the list. When you omit this flag, Bazel returns implicit dependencies not specified in the `BUILD` file and clutters the output.
+
+In most cases, use the query function `deps()` to see individual output dependencies of a specific target.
+
+## Visualizing the dependency graph (optional)
+
+Note: This section uses Graphviz, so make sure to [download Graphviz](https://graphviz.org/download/) to follow along.
+
+The section describes how you can visualize the dependency paths for a specific query. [Graphviz](https://graphviz.org/) helps to see the path as a directed acyclic graph image as opposed to a flattened list. You can alter the display of the Bazel query graph by using various `--output` command line options. See [Output Formats](https://bazel.build/versions/9.1.0/query/language#output-formats) for options.
+
+Start by running your desired query and add the flag `--noimplicit_deps` to remove excessive tool dependencies. Then, follow the query with the output flag and store the graph into a file called `graph.in` to create a text representation of the graph.
+
+To search for all dependencies of the target `:runner` and format the output as a graph:
+
+```posix-terminal
+bazel query --noimplicit_deps 'deps(:runner)' --output graph > graph.in
+```
+This creates a file called `graph.in`, which is a text representation of the build graph. Graphviz uses [dot](https://graphviz.org/docs/layouts/dot/) – a tool that processes text into a visualization —  to create a png:
+
+```posix-terminal
+dot -Tpng < graph.in > graph.png
+```
+If you open up `graph.png`, you should see something like this. The graph below has been simplified to make the essential path details clearer in this guide.
+
+![Diagram showing a relationship from cafe to chef to the dishes: pizza and mac and cheese which diverges into the separate ingredients: cheese, tomatoes, dough, and macaroni.](/versions/9.1.0/query/images/query_graph1.png "Dependency graph")
+
+This helps when you want to see the outputs of the different query functions throughout this guide.
+
+## Finding reverse dependencies
+
+If instead you have a target you’d like to analyze what other targets use it, you can use a query to examine what targets depend on a certain rule. This is called a “reverse dependency”. Using `rdeps()` can be useful when editing a file in a codebase that you’re unfamiliar with, and can save you from unknowingly breaking other files which depended on it.
+
+For instance, you want to make some edits to the ingredient `cheese`. To avoid causing an issue for Cafe Bazel, you need to check what dishes rely on `cheese`.
+
+Caution: Since `ingredients` is its own package, you must use a different naming convention for the target `cheese` in the form of `//package:target`. Read more about referencing targets, or [Labels](https://bazel.build/versions/9.1.0/concepts/labels).
+
+To see what targets depend on a particular target/package, you can use `rdeps(universe_scope, target)`. The `rdeps()` query function takes in at least two arguments: a `universe_scope` — the relevant directory — and a `target`. Bazel searches for the target’s reverse dependencies within the `universe_scope` provided. The `rdeps()` operator accepts an optional third argument: an integer literal specifying the upper bound on the depth of the search.
+
+Tip: To search within the whole scope of the project, set the `universe_scope` to `//...`
+
+To look for reverse dependencies of the target `cheese` within the scope of the entire project ‘//…’ run the command:
+
+```posix-terminal
+bazel query "rdeps(universe_scope, target)"
+```
+```
+ex) bazel query "rdeps(//... , //src/main/java/com/example/ingredients:cheese)"
+```
+```bash
+//:runner
+//src/main/java/com/example/dishes:macAndCheese
+//src/main/java/com/example/dishes:pizza
+//src/main/java/com/example/ingredients:cheese
+//src/main/java/com/example/restaurant:cafe
+//src/main/java/com/example/restaurant:chef
+```
+The query return shows that cheese is relied on by both pizza and macAndCheese. What a surprise!
+
+## Finding targets based on tags
+
+Two customers walk into Bazel Cafe: Amir and Jenny. There is nothing known about them except for their names. Luckily, they have their orders tagged in the 'customers' `BUILD` file. How can you access this tag?
+
+Developers can tag Bazel targets with different identifiers, often for testing purposes. For instance, tags on tests can annotate a test's role in your debug and release process, especially for C++ and Python tests, which lack any runtime annotation ability. Using tags and size elements gives flexibility in assembling suites of tests based around a codebase’s check-in policy.
+
+In this example, the tags are either one of `pizza` or `macAndCheese` to represent the menu items. This command queries for targets that have tags matching your identifier within a certain package.
+
+```
+bazel query 'attr(tags, "pizza", //src/main/java/com/example/customers/...)'
+```
+This query returns all of the targets in the 'customers' package that have a tag of "pizza".
+
+### Test yourself
+
+Use this query to learn what Jenny wants to order.
+
+

+  
+  
Answer

+  
Mac and Cheese

+  
+

+
+## Adding a new dependency
+
+Cafe Bazel has expanded its menu — customers can now order a Smoothie! This specific smoothie consists of the ingredients `Strawberry` and `Banana`.
+
+First, add the ingredients that the smoothie depends on: `Strawberry.java` and `Banana.java`. Add the empty Java classes.
+
+**`src/main/java/com/example/ingredients/Strawberry.java`**
+
+```java
+package com.example.ingredients;
+
+public class Strawberry {
+
+}
+```
+
+**`src/main/java/com/example/ingredients/Banana.java`**
+
+```java
+package com.example.ingredients;
+
+public class Banana {
+
+}
+```
+
+Next, add `Smoothie.java` to the appropriate directory: `dishes`.
+
+**`src/main/java/com/example/dishes/Smoothie.java`**
+
+```java
+package com.example.dishes;
+
+public class Smoothie {
+    public static final String DISH_NAME = "Smoothie";
+    public static final String DESCRIPTION = "Yummy and Refreshing";
+}
+```
+
+Lastly, add these files as rules in the appropriate `BUILD` files. Create a new java library for each new ingredient, including its name, public visibility, and its newly created 'src' file. You should wind up with this updated `BUILD` file:
+
+**`src/main/java/com/example/ingredients/BUILD`**
+
+```
+java_library(
+    name = "cheese",
+    visibility = ["//visibility:public"],
+    srcs = ["Cheese.java"],
+)
+
+java_library(
+    name = "dough",
+    visibility = ["//visibility:public"],
+    srcs = ["Dough.java"],
+)
+
+java_library(
+    name = "macaroni",
+    visibility = ["//visibility:public"],
+    srcs = ["Macaroni.java"],
+)
+
+java_library(
+    name = "tomato",
+    visibility = ["//visibility:public"],
+    srcs = ["Tomato.java"],
+)
+
+java_library(
+    name = "strawberry",
+    visibility = ["//visibility:public"],
+    srcs = ["Strawberry.java"],
+)
+
+java_library(
+    name = "banana",
+    visibility = ["//visibility:public"],
+    srcs = ["Banana.java"],
+)
+```
+
+In the `BUILD` file for dishes, you want to add a new rule for `Smoothie`. Doing so includes the Java file created for `Smoothie` as a 'src' file, and the new rules you made for each ingredient of the smoothie.
+
+**`src/main/java/com/example/dishes/BUILD`**
+
+```
+java_library(
+    name = "macAndCheese",
+    visibility = ["//visibility:public"],
+    srcs = ["MacAndCheese.java"],
+    deps = [
+        "//src/main/java/com/example/ingredients:cheese",
+        "//src/main/java/com/example/ingredients:macaroni",
+    ],
+)
+
+java_library(
+    name = "pizza",
+    visibility = ["//visibility:public"],
+    srcs = ["Pizza.java"],
+    deps = [
+        "//src/main/java/com/example/ingredients:cheese",
+        "//src/main/java/com/example/ingredients:dough",
+        "//src/main/java/com/example/ingredients:tomato",
+    ],
+)
+
+java_library(
+    name = "smoothie",
+    visibility = ["//visibility:public"],
+    srcs = ["Smoothie.java"],
+    deps = [
+        "//src/main/java/com/example/ingredients:strawberry",
+        "//src/main/java/com/example/ingredients:banana",
+    ],
+)
+```
+
+Lastly, you want to include the smoothie as a dependency in the Chef’s `BUILD` file.
+
+**`src/main/java/com/example/restaurant/BUILD`**
+
+```
+java_library(
+    name = "chef",
+    visibility = ["//visibility:public"],
+    srcs = [
+        "Chef.java",
+    ],
+
+    deps = [
+        "//src/main/java/com/example/dishes:macAndCheese",
+        "//src/main/java/com/example/dishes:pizza",
+        "//src/main/java/com/example/dishes:smoothie",
+    ],
+)
+
+java_library(
+    name = "cafe",
+    visibility = ["//visibility:public"],
+    srcs = [
+        "Cafe.java",
+    ],
+    deps = [
+        ":chef",
+    ],
+)
+```
+
+Build `cafe` again to confirm that there are no errors. If it builds successfully, congratulations! You’ve added a new dependency for the 'Cafe'. If not, look out for spelling mistakes and package naming. For more information about writing `BUILD` files see [BUILD Style Guide](https://bazel.build/versions/9.1.0/build/style-guide).
+
+Now, visualize the new dependency graph with the addition of the `Smoothie` to compare with the previous one. For clarity, name the graph input as `graph2.in` and `graph2.png`.
+
+```posix-terminal
+bazel query --noimplicit_deps 'deps(:runner)' --output graph > graph2.in
+```
+
+```posix-terminal
+dot -Tpng < graph2.in > graph2.png
+```
+
+[![The same graph as the first one except now there is a spoke stemming from the chef target with smoothie which leads to banana and strawberry](/versions/9.1.0/query/images/query_graph2.png "Updated dependency graph")](images/query_graph2.png)
+
+Looking at `graph2.png`, you can see that `Smoothie` has no shared dependencies with other dishes but is just another target that the `Chef` relies on.
+
+## somepath() and allpaths()
+
+What if you want to query why one package depends on another package? Displaying a dependency path between the two provides the answer.
+
+Two functions can help you find dependency paths: `somepath()` and `allpaths()`. Given a starting target S and an end point E, find a path between S and E by using `somepath(S,E)`.
+
+Explore the differences between these two functions by looking at the relationships between the 'Chef' and 'Cheese' targets. There are different possible paths to get from one target to the other:
+
+*   Chef → MacAndCheese → Cheese
+*   Chef → Pizza → Cheese
+
+`somepath()` gives you a single path out of the two options, whereas 'allpaths()' outputs every possible path.
+
+Using Cafe Bazel as an example, run the following:
+
+```posix-terminal
+bazel query "somepath(//src/main/java/com/example/restaurant/..., //src/main/java/com/example/ingredients:cheese)"
+```
+
+```bash
+//src/main/java/com/example/restaurant:cafe
+//src/main/java/com/example/restaurant:chef
+//src/main/java/com/example/dishes:macAndCheese
+//src/main/java/com/example/ingredients:cheese
+```
+
+The output follows the first path of Cafe → Chef → MacAndCheese → Cheese. If instead you use `allpaths()`, you get:
+
+```posix-terminal
+bazel query "allpaths(//src/main/java/com/example/restaurant/..., //src/main/java/com/example/ingredients:cheese)"
+```
+
+```bash
+//src/main/java/com/example/dishes:macAndCheese
+//src/main/java/com/example/dishes:pizza
+//src/main/java/com/example/ingredients:cheese
+//src/main/java/com/example/restaurant:cafe
+//src/main/java/com/example/restaurant:chef
+```
+
+![Output path of cafe to chef to pizza,mac and cheese to cheese](/versions/9.1.0/query/images/query_graph3.png "Output path for dependency")
+
+The output of `allpaths()` is a little harder to read as it is a flattened list of the dependencies. Visualizing this graph using Graphviz makes the relationship clearer to understand.
+
+## Test yourself
+
+One of Cafe Bazel’s customers gave the restaurant's first review! Unfortunately, the review is missing some details such as the identity of the reviewer and what dish it’s referencing. Luckily, you can access this information with Bazel. The `reviews` package contains a program that prints a review from a mystery customer. Build and run it with:
+
+```posix-terminal
+bazel build //src/main/java/com/example/reviews:review
+```
+
+```posix-terminal
+bazel-bin/src/main/java/com/example/reviews/review
+```
+
+Going off Bazel queries only, try to find out who wrote the review, and what dish they were describing.
+
+

+  Hint
+  
Check the tags and dependencies for useful information.

+

+
+

+  Answer
+  
This review was describing the Pizza and Amir was the reviewer. If you look at what dependencies that this rule had using bazel query --noimplicit\_deps 'deps(//src/main/java/com/example/reviews:review)' the result of this command reveals that Amir is the reviewer! Next, since you know the reviewer is Amir, you can use the query function to seek which tag Amir has in the `BUILD` file to see what dish is there. The command bazel query 'attr(tags, "pizza", //src/main/java/com/example/customers/...)' output that Amir is the only customer that ordered a pizza and is the reviewer which gives us the answer.

+

+
+## Wrapping up
+
+Congratulations! You have now run several basic queries, which you can try out on own projects. To learn more about the query language syntax, refer to the [Query reference page](https://bazel.build/versions/9.1.0/query/language). Want more advanced queries? The [Query guide](https://bazel.build/versions/9.1.0/query/guide) showcases an in-depth list of more use cases than are covered in this guide.
diff --git a/versions/9.1.0/reference/be/be-nav.mdx b/versions/9.1.0/reference/be/be-nav.mdx
new file mode 100644
index 00000000..863951fc
--- /dev/null
+++ b/versions/9.1.0/reference/be/be-nav.mdx
@@ -0,0 +1,30 @@
+\*\*Build Encyclopedia\*\*
+
+* [Overview](/versions/9.1.0/reference/be/overview)
+* [Concepts](#be-menu)
+  + [Common Definitions](/versions/9.1.0/reference/be/common-definitions)
+  + ["Make" variables](/versions/9.1.0/reference/be/make-variables)
+* [Rules](#be-rules)
+  + [Functions](/versions/9.1.0/reference/be/functions)
+  + [C / C++](/versions/9.1.0/reference/be/c-cpp)
+  + [Java](/versions/9.1.0/reference/be/java)
+  + [Objective-C](/versions/9.1.0/reference/be/objective-c)
+  + [Protocol Buffer](/versions/9.1.0/reference/be/protocol-buffer)
+  + [Python](/versions/9.1.0/reference/be/python)
+  + [Shell](/versions/9.1.0/reference/be/shell)
+  + [Extra Actions](/versions/9.1.0/reference/be/extra-actions)
+  + [General](/versions/9.1.0/reference/be/general)
+  + [Platforms and Toolchains](/versions/9.1.0/reference/be/platforms-and-toolchains)
+  + [AppEngine](https://github.com/bazelbuild/rules_appengine)
+  + [Apple (Swift, iOS, macOS, tvOS, visionOS, watchOS)](https://github.com/bazelbuild/rules_apple)
+  + [C#](https://github.com/bazelbuild/rules_dotnet)
+  + [D](https://github.com/bazelbuild/rules_d)
+  + [Docker](https://github.com/bazelbuild/rules_docker)
+  + [Groovy](https://github.com/bazelbuild/rules_groovy)
+  + [Go](https://github.com/bazelbuild/rules_go)
+  + [JavaScript (Closure)](https://github.com/bazelbuild/rules_closure)
+  + [Jsonnet](https://github.com/bazelbuild/rules_jsonnet)
+  + [Packaging](/versions/9.1.0/reference/be/pkg)
+  + [Rust](https://github.com/bazelbuild/rules_rust)
+  + [Sass](https://github.com/bazelbuild/rules_sass)
+  + [Scala](https://github.com/bazelbuild/rules_scala)
\ No newline at end of file
diff --git a/versions/9.1.0/reference/be/c-cpp.mdx b/versions/9.1.0/reference/be/c-cpp.mdx
new file mode 100644
index 00000000..15fd366e
--- /dev/null
+++ b/versions/9.1.0/reference/be/c-cpp.mdx
@@ -0,0 +1,905 @@
+---
+title: 'C / C++ Rules'
+---
+
+## Rules
+
+* [cc_binary](#cc_binary)
+* [cc_import](#cc_import)
+* [cc_library](#cc_library)
+* [cc_shared_library](#cc_shared_library)
+* [cc_static_library](#cc_static_library)
+* [cc_test](#cc_test)
+* [cc_toolchain](#cc_toolchain)
+* [fdo_prefetch_hints](#fdo_prefetch_hints)
+* [fdo_profile](#fdo_profile)
+* [memprof_profile](#memprof_profile)
+* [propeller_optimize](#propeller_optimize)
+
+## cc_binary
+
+[View rule sourceopen_in_new](https://github.com/bazelbuild/rules_cc/blob/master/cc/private/rules_impl/cc_binary.bzl)
+
+```
+cc_binary(name, deps, srcs, data, additional_compiler_inputs, additional_linker_inputs, args, aspect_hints, compatible_with, conlyopts, copts, cxxopts, defines, deprecation, dynamic_deps, env, exec_compatible_with, exec_group_compatible_with, exec_properties, features, hdrs_check, includes, licenses, link_extra_lib, linkopts, linkshared, linkstatic, local_defines, malloc, module_interfaces, nocopts, output_licenses, package_metadata, reexport_deps, restricted_to, stamp, tags, target_compatible_with, testonly, toolchains, visibility, win_def_file)
+```
+
+It produces an executable binary.
+
+
+The `name` of the target should be the same as the name of the
+source file that is the main entry point of the application (minus the extension).
+For example, if your entry point is in `main.cc`, then your name should
+be `main`.
+
+#### Implicit output targets
+
+* `name.stripped` (only built if explicitly requested): A stripped
+  version of the binary. `strip -g` is run on the binary to remove debug
+  symbols. Additional strip options can be provided on the command line using
+  `--stripopt=-foo`.
+* `name.dwp` (only built if explicitly requested): If
+  [Fission](https://gcc.gnu.org/wiki/DebugFission) is enabled: a debug
+  information package file suitable for debugging remotely deployed binaries. Else: an
+  empty file.
+
+### Arguments
+
+| Attributes | |
+| --- | --- |
+| `name` | [Name](/versions/9.1.0/concepts/labels#target-names); required  A unique name for this target. |
+| `deps` | List of [labels](/versions/9.1.0/concepts/labels); default is `[]` The list of other libraries to be linked in to the binary target. These can be `cc_library` or `objc_library` targets. It is also allowed to put linker scripts (.lds) into deps, and reference them in [`linkopts`](#cc_binary.linkopts), but please consider [`additional_linker_inputs`](#cc_binary.additional_linker_inputs) for that use case. |
+| `srcs` | List of [labels](/versions/9.1.0/concepts/labels); default is `[]` The list of C and C++ files that are processed to create the library target. These are C/C++ source and header files, either non-generated (normal source code) or generated. All `.cc`, `.c`, and `.cpp` files will be compiled. These might be generated files: if a named file is in the `outs` of some other rule, this `cc_library` will automatically depend on that other rule.  Pure assembler files (.s, .asm) are not preprocessed and are typically built using the assembler. Preprocessed assembly files (.S) are preprocessed and are typically built using the C/C++ compiler.  A `.h` file will not be compiled, but will be available for inclusion by sources in this rule. Both `.cc` and `.h` files can directly include headers listed in these `srcs` or in the `hdrs` of this rule or any rule listed in the `deps` argument.  All `#include`d files must be mentioned in the `hdrs` attribute of this or referenced `cc_library` rules, or they should be listed in `srcs` if they are private to this library. See ["Header inclusion checking"](#hdrs) for a more detailed description.  `.so`, `.lo`, and `.a` files are pre-compiled files. Your library might have these as `srcs` if it uses third-party code for which we don't have source code.  If the `srcs` attribute includes the label of another rule, `cc_library` will use the output files of that rule as source files to compile. This is useful for one-off generation of source code (for more than occasional use, it's better to implement a Starlark rule class and use the `cc_common` API)  Permitted `srcs` file types:   * C and C++ source files: `.c`, `.cc`, `.cpp`,   `.cxx`, `.c++`, `.C` * C and C++ header files: `.h`, `.hh`, `.hpp`,   `.hxx`, `.inc`, `.inl`, `.H` * Assembler with C preprocessor: `.S` * Archive: `.a`, `.pic.a` * "Always link" library: `.lo`, `.pic.lo` * Shared library, versioned or unversioned: `.so`,   `.so.version` * Object file: `.o`, `.pic.o`   ... and any rules that produce those files (e.g. `cc_embed_data`). Different extensions denote different programming languages in accordance with gcc convention. |
+| `data` | List of [labels](/versions/9.1.0/concepts/labels); default is `[]` The list of files needed by this library at runtime. See general comments about `data` at [Typical attributes defined by most build rules](/versions/9.1.0/reference/be/common-definitions#typical-attributes). If a `data` is the name of a generated file, then this `cc_library` rule automatically depends on the generating rule.  If a `data` is a rule name, then this `cc_library` rule automatically depends on that rule, and that rule's `outs` are automatically added to this `cc_library`'s data files.  Your C++ code can access these data files like so:   ```   const std::string path = devtools_build::GetDataDependencyFilepath(       "my/test/data/file"); ``` |
+| `additional_compiler_inputs` | List of [labels](/versions/9.1.0/concepts/labels); default is `[]` Any additional files you might want to pass to the compiler command line, such as sanitizer ignorelists, for example. Files specified here can then be used in copts with the $(location) function. |
+| `additional_linker_inputs` | List of [labels](/versions/9.1.0/concepts/labels); default is `[]` Dependencies that are only made available to the C++ linker command. Unlike `deps`, which is conceptually made for both compilation and linking dependencies, `additional_linker_inputs` is specifically made for only the latter, and signals a dependency that is required only for linking (for example, files that are referenced in `linkopts`).  For example, compiled Windows .res files can be provided here to be embedded in the binary target. |
+| `conlyopts` | List of strings; default is `[]` Add these options to the C compilation command. Subject to ["Make variable"](/versions/9.1.0/reference/be/make-variables) substitution and [Bourne shell tokenization](/versions/9.1.0/reference/be/common-definitions#sh-tokenization). |
+| `copts` | List of strings; default is `[]` Add these options to the C/C++ compilation command. Subject to ["Make variable"](/versions/9.1.0/reference/be/make-variables) substitution and [Bourne shell tokenization](/versions/9.1.0/reference/be/common-definitions#sh-tokenization). Each string in this attribute is added in the given order to `COPTS` before compiling the binary target. The flags take effect only for compiling this target, not its dependencies, so be careful about header files included elsewhere. All paths should be relative to the workspace, not to the current package. This attribute should not be needed outside of `third_party`.  If the package declares the [feature](/versions/9.1.0/reference/be/functions#package.features) `no_copts_tokenization`, Bourne shell tokenization applies only to strings that consist of a single "Make" variable. |
+| `cxxopts` | List of strings; default is `[]` Add these options to the C++ compilation command. Subject to ["Make variable"](/versions/9.1.0/reference/be/make-variables) substitution and [Bourne shell tokenization](/versions/9.1.0/reference/be/common-definitions#sh-tokenization). |
+| `defines` | List of strings; default is `[]` List of defines to add to the compile line of this and all dependent targets. Subject to ["Make" variable](/versions/9.1.0/reference/be/make-variables) substitution and [Bourne shell tokenization](/versions/9.1.0/reference/be/common-definitions#sh-tokenization). Each string, which must consist of a single Bourne shell token, is prepended with `-D` and added to the compile command line to this target, as well as to every rule that depends on it. Be very careful, since this may have far-reaching effects -- the defines are added to every target that depends on this target. When in doubt, add define values to [`local_defines`](#cc_binary.local_defines) instead. |
+| `dynamic_deps` | List of [labels](/versions/9.1.0/concepts/labels); default is `[]` These are other `cc_shared_library` dependencies the current target depends on. The `cc_shared_library` implementation will use the list of `dynamic_deps` (transitively, i.e. also the `dynamic_deps` of the current target's `dynamic_deps`) to decide which `cc_libraries` in the transitive `deps` should not be linked in because they are already provided by a different `cc_shared_library`. |
+| `hdrs_check` | String; default is `""` Deprecated, no-op. |
+| `includes` | List of strings; default is `[]` List of include dirs to be added to the compile line. Subject to ["Make variable"](/versions/9.1.0/reference/be/make-variables) substitution. Each string is prepended with the package path and passed to the C++ toolchain for expansion via the "include_paths" CROSSTOOL feature. A toolchain running on a POSIX system with typical feature definitions will produce `-isystem path_to_package/include_entry`. This should only be used for third-party libraries that do not conform to the Google style of writing #include statements. Unlike [COPTS](#cc_binary.copts), these flags are added for this rule and every rule that depends on it. (Note: not the rules it depends upon!) Be very careful, since this may have far-reaching effects. When in doubt, add "-I" flags to [COPTS](#cc_binary.copts) instead. The added `include` paths will include generated files as well as files in the source tree. |
+| `link_extra_lib` | [Label](/versions/9.1.0/concepts/labels); default is `"@bazel_tools//tools/cpp:link_extra_lib"` Control linking of extra libraries. By default, C++ binaries are linked against `@bazel_tools//tools/cpp:link_extra_lib`, which by default depends on the label flag `@bazel_tools//tools/cpp:link_extra_libs`. Without setting the flag, this library is empty by default. Setting the label flag allows linking optional dependencies, such as overrides for weak symbols, interceptors for shared library functions, or special runtime libraries (for malloc replacements, prefer `malloc` or `--custom_malloc`). Setting this attribute to `None` disables this behaviour. |
+| `linkopts` | List of strings; default is `[]` Add these flags to the C++ linker command. Subject to ["Make" variable](/versions/9.1.0/reference/be/make-variables) substitution, [Bourne shell tokenization](/versions/9.1.0/reference/be/common-definitions#sh-tokenization) and [label expansion](/versions/9.1.0/reference/be/common-definitions#label-expansion). Each string in this attribute is added to `LINKOPTS` before linking the binary target. Each element of this list that does not start with `$` or `-` is assumed to be the label of a target in `deps`. The list of files generated by that target is appended to the linker options. An error is reported if the label is invalid, or is not declared in `deps`. |
+| `linkshared` | Boolean; default is `False` Create a shared library. To enable this attribute, include `linkshared=True` in your rule. By default this option is off. The presence of this flag means that linking occurs with the `-shared` flag to `gcc`, and the resulting shared library is suitable for loading into for example a Java program. However, for build purposes it will never be linked into the dependent binary, as it is assumed that shared libraries built with a [cc_binary](#cc_binary) rule are only loaded manually by other programs, so it should not be considered a substitute for the [cc_library](#cc_library) rule. For sake of scalability we recommend avoiding this approach altogether and simply letting `java_library` depend on `cc_library` rules instead.  If you specify both `linkopts=['-static']` and `linkshared=True`, you get a single completely self-contained unit. If you specify both `linkstatic=True` and `linkshared=True`, you get a single, mostly self-contained unit. |
+| `linkstatic` | Boolean; default is `True` For [`cc_binary`](/versions/9.1.0/reference/be/c-cpp#cc_binary) and [`cc_test`](/versions/9.1.0/reference/be/c-cpp#cc_test): link the binary in static mode. For `cc_library.link_static`: see below. By default this option is on for `cc_binary` and off for the rest.  If enabled and this is a binary or test, this option tells the build tool to link in `.a`'s instead of `.so`'s for user libraries whenever possible. System libraries such as libc (but *not* the C/C++ runtime libraries, see below) are still linked dynamically, as are libraries for which there is no static library. So the resulting executable will still be dynamically linked, hence only *mostly* static.  There are really three different ways to link an executable:   * STATIC with fully_static_link feature, in which everything is linked statically;   e.g. "`gcc -static foo.o libbar.a libbaz.a -lm`".    This mode is enabled by specifying `fully_static_link` in the   [`features`](/versions/9.1.0/reference/be/common-definitions#features) attribute. * STATIC, in which all user libraries are linked statically (if a static   version is available), but where system libraries (excluding C/C++ runtime libraries)   are linked dynamically, e.g. "`gcc foo.o libfoo.a libbaz.a -lm`".    This mode is enabled by specifying `linkstatic=True`. * DYNAMIC, in which all libraries are linked dynamically (if a dynamic version is   available), e.g. "`gcc foo.o libfoo.so libbaz.so -lm`".    This mode is enabled by specifying `linkstatic=False`.   If the `linkstatic` attribute or `fully_static_link` in `features` is used outside of `//third_party` please include a comment near the rule to explain why.  The `linkstatic` attribute has a different meaning if used on a [`cc_library()`](/versions/9.1.0/reference/be/c-cpp#cc_library) rule. For a C++ library, `linkstatic=True` indicates that only static linking is allowed, so no `.so` will be produced. linkstatic=False does not prevent static libraries from being created. The attribute is meant to control the creation of dynamic libraries.  There should be very little code built with `linkstatic=False` in production. If `linkstatic=False`, then the build tool will create symlinks to depended-upon shared libraries in the `*.runfiles` area. |
+| `local_defines` | List of strings; default is `[]` List of defines to add to the compile line. Subject to ["Make" variable](/versions/9.1.0/reference/be/make-variables) substitution and [Bourne shell tokenization](/versions/9.1.0/reference/be/common-definitions#sh-tokenization). Each string, which must consist of a single Bourne shell token, is prepended with `-D` and added to the compile command line for this target, but not to its dependents. Unlike `defines`, the defines are only added to the compile command line for this target. |
+| `malloc` | [Label](/versions/9.1.0/concepts/labels); default is `"@bazel_tools//tools/cpp:malloc"` Override the default dependency on malloc. By default, C++ binaries are linked against `//tools/cpp:malloc`, which is an empty library so the binary ends up using libc malloc. This label must refer to a `cc_library`. If compilation is for a non-C++ rule, this option has no effect. The value of this attribute is ignored if `linkshared=True` is specified. |
+| `module_interfaces` | List of [labels](/versions/9.1.0/concepts/labels); default is `[]` The list of files are regarded as C++20 Modules Interface. C++ Standard has no restriction about module interface file extension  * Clang use cppm * GCC can use any source file extension * MSVC use ixx  The use is guarded by the flag `--experimental_cpp_modules`. |
+| `nocopts` | String; default is `""` Remove matching options from the C++ compilation command. Subject to ["Make" variable](/versions/9.1.0/reference/be/make-variables) substitution. The value of this attribute is interpreted as a regular expression. Any preexisting `COPTS` that match this regular expression (including values explicitly specified in the rule's [copts](#cc_binary.copts) attribute) will be removed from `COPTS` for purposes of compiling this rule. This attribute should not be needed or used outside of `third_party`. The values are not preprocessed in any way other than the "Make" variable substitution. |
+| `reexport_deps` | List of [labels](/versions/9.1.0/concepts/labels); default is `[]` |
+| `stamp` | Integer; default is `-1` Whether to encode build information into the binary. Possible values:  * `stamp = 1`: Always stamp the build information into the binary, even in   [`--nostamp`](/versions/9.1.0/docs/user-manual#flag--stamp) builds. **This   setting should be avoided**, since it potentially kills remote caching for the   binary and any downstream actions that depend on it. * `stamp = 0`: Always replace build information by constant values. This   gives good build result caching. * `stamp = -1`: Embedding of build information is controlled by the   [`--[no]stamp`](/versions/9.1.0/docs/user-manual#flag--stamp) flag.   Stamped binaries are *not* rebuilt unless their dependencies change. |
+| `win_def_file` | [Label](/versions/9.1.0/concepts/labels); default is `None` The Windows DEF file to be passed to linker. This attribute should only be used when Windows is the target platform. It can be used to [export symbols](https://msdn.microsoft.com/en-us/library/d91k01sh.aspx) during linking a shared library. |
+
+## cc_import
+
+[View rule sourceopen_in_new](https://github.com/bazelbuild/rules_cc/blob/master/cc/private/rules_impl/cc_import.bzl)
+
+```
+cc_import(name, deps, data, hdrs, alwayslink, aspect_hints, compatible_with, defines, deprecation, exec_compatible_with, exec_group_compatible_with, exec_properties, features, includes, interface_library, linkopts, objects, package_metadata, pic_objects, pic_static_library, restricted_to, shared_library, static_library, strip_include_prefix, system_provided, tags, target_compatible_with, testonly, toolchains, visibility)
+```
+
+`cc_import` rules allows users to import precompiled C/C++ libraries.
+
+The following are the typical use cases:
+1. Linking a static library
+
+```
+cc_import(
+  name = "mylib",
+  hdrs = ["mylib.h"],
+  static_library = "libmylib.a",
+  # If alwayslink is turned on,
+  # libmylib.a will be forcely linked into any binary that depends on it.
+  # alwayslink = True,
+)
+```
+
+2. Linking a shared library (Unix)
+
+```
+cc_import(
+  name = "mylib",
+  hdrs = ["mylib.h"],
+  shared_library = "libmylib.so",
+)
+```
+
+3. Linking a shared library with interface library
+
+On Unix:
+
+```
+cc_import(
+  name = "mylib",
+  hdrs = ["mylib.h"],
+  # libmylib.ifso is an interface library for libmylib.so which will be passed to linker
+  interface_library = "libmylib.ifso",
+  # libmylib.so will be available for runtime
+  shared_library = "libmylib.so",
+)
+```
+
+On Windows:
+
+```
+cc_import(
+  name = "mylib",
+  hdrs = ["mylib.h"],
+  # mylib.lib is an import library for mylib.dll which will be passed to linker
+  interface_library = "mylib.lib",
+  # mylib.dll will be available for runtime
+  shared_library = "mylib.dll",
+)
+```
+
+4. Linking a shared library with `system_provided=True`
+
+On Unix:
+
+```
+cc_import(
+  name = "mylib",
+  hdrs = ["mylib.h"],
+  interface_library = "libmylib.ifso", # Or we can also use libmylib.so as its own interface library
+  # libmylib.so is provided by system environment, for example it can be found in LD_LIBRARY_PATH.
+  # This indicates that Bazel is not responsible for making libmylib.so available.
+  system_provided = True,
+)
+```
+
+On Windows:
+
+```
+cc_import(
+  name = "mylib",
+  hdrs = ["mylib.h"],
+  # mylib.lib is an import library for mylib.dll which will be passed to linker
+  interface_library = "mylib.lib",
+  # mylib.dll is provided by system environment, for example it can be found in PATH.
+  # This indicates that Bazel is not responsible for making mylib.dll available.
+  system_provided = True,
+)
+```
+
+5. Linking to static or shared library
+
+On Unix:
+
+```
+cc_import(
+  name = "mylib",
+  hdrs = ["mylib.h"],
+  static_library = "libmylib.a",
+  shared_library = "libmylib.so",
+)
+```
+
+On Windows:
+
+```
+cc_import(
+  name = "mylib",
+  hdrs = ["mylib.h"],
+  static_library = "libmylib.lib", # A normal static library
+  interface_library = "mylib.lib", # An import library for mylib.dll
+  shared_library = "mylib.dll",
+)
+```
+
+The remaining is the same on Unix and Windows:
+
+```
+# first will link to libmylib.a (or libmylib.lib)
+cc_binary(
+  name = "first",
+  srcs = ["first.cc"],
+  deps = [":mylib"],
+  linkstatic = True, # default value
+)
+
+# second will link to libmylib.so (or libmylib.lib)
+cc_binary(
+  name = "second",
+  srcs = ["second.cc"],
+  deps = [":mylib"],
+  linkstatic = False,
+)
+```
+
+`cc_import` supports an include attribute. For example:
+
+```
+cc_import(
+  name = "curl_lib",
+  hdrs = glob(["vendor/curl/include/curl/*.h"]),
+  includes = ["vendor/curl/include"],
+  shared_library = "vendor/curl/lib/.libs/libcurl.dylib",
+)
+```
+
+### Arguments
+
+| Attributes | |
+| --- | --- |
+| `name` | [Name](/versions/9.1.0/concepts/labels#target-names); required  A unique name for this target. |
+| `deps` | List of [labels](/versions/9.1.0/concepts/labels); default is `[]` The list of other libraries that the target depends upon. See general comments about `deps` at [Typical attributes defined by most build rules](/versions/9.1.0/reference/be/common-definitions#typical-attributes). |
+| `hdrs` | List of [labels](/versions/9.1.0/concepts/labels); default is `[]` The list of header files published by this precompiled library to be directly included by sources in dependent rules. |
+| `alwayslink` | Boolean; default is `False` If enabled, any binary that depends (directly or indirectly) on this C++ precompiled library will link in all the object files archived in the static library, even if some contain no symbols referenced by the binary. This is useful if your code isn't explicitly called by code in the binary, e.g., if your code registers to receive some callback provided by some service. If `alwayslink` doesn't work with VS 2017 on Windows, that is due to a [known issue](https://github.com/bazelbuild/bazel/issues/3949), please upgrade your VS 2017 to the latest version. |
+| `defines` | List of strings; default is `[]` List of defines to add to the compile line of this and all dependent targets. Subject to ["Make" variable](/versions/9.1.0/reference/be/make-variables) substitution and [Bourne shell tokenization](/versions/9.1.0/reference/be/common-definitions#sh-tokenization). Each string, which must consist of a single Bourne shell token, is prepended with `-D` and added to the compile command line to this target, as well as to every rule that depends on it. Be very careful, since this may have far-reaching effects -- the defines are added to every target that depends on this target. |
+| `includes` | List of strings; default is `[]` List of include dirs to be added to the compile line. Subject to ["Make variable"](/versions/9.1.0/reference/be/make-variables) substitution. Each string is prepended with the package path and passed to the C++ toolchain for expansion via the "include_paths" CROSSTOOL feature. A toolchain running on a POSIX system with typical feature definitions will produce `-isystem path_to_package/include_entry`. This should only be used for third-party libraries that do not conform to the Google style of writing #include statements. Unlike [COPTS](#cc_binary.copts), these flags are added for this rule and every rule that depends on it. (Note: not the rules it depends upon!) Be very careful, since this may have far-reaching effects. When in doubt, add "-I" flags to [COPTS](#cc_binary.copts) instead. The default `include` path doesn't include generated files. If you need to `#include` a generated header file, list it in the `srcs`. |
+| `interface_library` | [Label](/versions/9.1.0/concepts/labels); default is `None` A single interface library for linking the shared library. Permitted file types: `.ifso`, `.tbd`, `.lib`, `.so` or `.dylib` |
+| `linkopts` | List of strings; default is `[]` Add these flags to the C++ linker command. Subject to ["Make" variable](/versions/9.1.0/reference/be/make-variables) substitution, [Bourne shell tokenization](/versions/9.1.0/reference/be/common-definitions#sh-tokenization) and [label expansion](/versions/9.1.0/reference/be/common-definitions#label-expansion). Each string in this attribute is added to `LINKOPTS` before linking the binary target. Each element of this list that does not start with `$` or `-` is assumed to be the label of a target in `deps`. The list of files generated by that target is appended to the linker options. An error is reported if the label is invalid, or is not declared in `deps`. |
+| `objects` | List of [labels](/versions/9.1.0/concepts/labels); default is `[]` |
+| `pic_objects` | List of [labels](/versions/9.1.0/concepts/labels); default is `[]` |
+| `pic_static_library` | [Label](/versions/9.1.0/concepts/labels); default is `None` |
+| `shared_library` | [Label](/versions/9.1.0/concepts/labels); default is `None` A single precompiled shared library. Bazel ensures it is available to the binary that depends on it during runtime. Permitted file types: `.so`, `.dll` `.dylib`, or `.pyd` |
+| `static_library` | [Label](/versions/9.1.0/concepts/labels); default is `None` A single precompiled static library. Permitted file types: `.a`, `.pic.a` or `.lib` |
+| `strip_include_prefix` | String; default is `""` The prefix to strip from the paths of the headers of this rule. When set, the headers in the `hdrs` attribute of this rule are accessible at their path with this prefix cut off. If it's a relative path, it's taken as a package-relative one. If it's an absolute one, it's understood as a repository-relative path. The prefix in the `include_prefix` attribute is added after this prefix is stripped. This attribute is only legal under `third_party`. |
+| `system_provided` | Boolean; default is `False` If enabled, it indicates the shared library required at runtime is provided by the system. In this case, `interface_library` should be specified and `shared_library` should be empty. |
+
+## cc_library
+
+[View rule sourceopen_in_new](https://github.com/bazelbuild/rules_cc/blob/master/cc/private/rules_impl/cc_library.bzl)
+
+```
+cc_library(name, deps, srcs, data, hdrs, additional_compiler_inputs, additional_linker_inputs, alwayslink, aspect_hints, compatible_with, conlyopts, copts, cxxopts, defines, deprecation, exec_compatible_with, exec_group_compatible_with, exec_properties, features, hdrs_check, implementation_deps, include_prefix, includes, licenses, linkopts, linkstamp, linkstatic, local_defines, module_interfaces, package_metadata, restricted_to, strip_include_prefix, tags, target_compatible_with, testonly, textual_hdrs, toolchains, visibility, win_def_file)
+```
+
+Use `cc_library()` for C++-compiled libraries.
+The result is either a `.so`, `.lo`,
+or `.a`, depending on what is needed.
+
+If you build something with static linking that depends on
+a `cc_library`, the output of a depended-on library rule
+is the `.a` file. If you specify
+`alwayslink=True`, you get the `.lo` file.
+
+The actual output file name is `libfoo.so` for
+the shared library, where *foo* is the name of the rule. The
+other kinds of libraries end with `.lo` and `.a`,
+respectively. If you need a specific shared library name, for
+example, to define a Python module, use a genrule to copy the library
+to the desired name.
+
+#### Header inclusion checking
+
+All header files that are used in the build must be declared in
+the `hdrs` or `srcs` of `cc_*` rules.
+This is enforced.
+
+For `cc_library` rules, headers in `hdrs` comprise the
+public interface of the library and can be directly included both
+from the files in `hdrs` and `srcs` of the library
+itself as well as from files in `hdrs` and `srcs`
+of `cc_*` rules that list the library in their `deps`.
+Headers in `srcs` must only be directly included from the files
+in `hdrs` and `srcs` of the library itself. When
+deciding whether to put a header into `hdrs` or `srcs`,
+you should ask whether you want consumers of this library to be able to
+directly include it. This is roughly the same decision as
+between `public` and `private` visibility in programming languages.
+
+`cc_binary` and `cc_test` rules do not have an exported
+interface, so they also do not have a `hdrs` attribute. All headers
+that belong to the binary or test directly should be listed in
+the `srcs`.
+
+To illustrate these rules, look at the following example.
+
+```
+cc_binary(
+    name = "foo",
+    srcs = [
+        "foo.cc",
+        "foo.h",
+    ],
+    deps = [":bar"],
+)
+
+cc_library(
+    name = "bar",
+    srcs = [
+        "bar.cc",
+        "bar-impl.h",
+    ],
+    hdrs = ["bar.h"],
+    deps = [":baz"],
+)
+
+cc_library(
+    name = "baz",
+    srcs = [
+        "baz.cc",
+        "baz-impl.h",
+    ],
+    hdrs = ["baz.h"],
+)
+```
+
+The allowed direct inclusions in this example are listed in the table below.
+For example `foo.cc` is allowed to directly
+include `foo.h` and `bar.h`, but not `baz.h`.
+
+| Including file | Allowed inclusions |
+| --- | --- |
+| foo.h | bar.h |
+| foo.cc | foo.h bar.h |
+| bar.h | bar-impl.h baz.h |
+| bar-impl.h | bar.h baz.h |
+| bar.cc | bar.h bar-impl.h baz.h |
+| baz.h | baz-impl.h |
+| baz-impl.h | baz.h |
+| baz.cc | baz.h baz-impl.h |
+
+The inclusion checking rules only apply to *direct*
+inclusions. In the example above `foo.cc` is allowed to
+include `bar.h`, which may include `baz.h`, which in
+turn is allowed to include `baz-impl.h`. Technically, the
+compilation of a `.cc` file may transitively include any header
+file in the `hdrs` or `srcs` in
+any `cc_library` in the transitive `deps` closure. In
+this case the compiler may read `baz.h` and `baz-impl.h`
+when compiling `foo.cc`, but `foo.cc` must not
+contain `#include "baz.h"`. For that to be
+allowed, `baz` must be added to the `deps`
+of `foo`.
+
+Bazel depends on toolchain support to enforce the inclusion checking rules.
+The `layering_check` feature has to be supported by the toolchain
+and requested explicitly, for example via the
+`--features=layering_check` command-line flag or the
+`features` parameter of the
+[`package`](/versions/9.1.0/reference/be/functions#package) function. The toolchains
+provided by Bazel only support this feature with clang on Unix and macOS.
+
+#### Examples
+
+We use the `alwayslink` flag to force the linker to link in
+this code although the main binary code doesn't reference it.
+
+```
+cc_library(
+    name = "ast_inspector_lib",
+    srcs = ["ast_inspector_lib.cc"],
+    hdrs = ["ast_inspector_lib.h"],
+    visibility = ["//visibility:public"],
+    deps = ["//third_party/llvm/llvm/tools/clang:frontend"],
+    # alwayslink as we want to be able to call things in this library at
+    # debug time, even if they aren't used anywhere in the code.
+    alwayslink = True,
+)
+```
+
+The following example comes from
+`third_party/python2_4_3/BUILD`.
+Some of the code uses the `dl` library (to load
+another, dynamic library), so this
+rule specifies the `-ldl` link option to link the
+`dl` library.
+
+```
+cc_library(
+    name = "python2_4_3",
+    linkopts = [
+        "-ldl",
+        "-lutil",
+    ],
+    deps = ["//third_party/expat"],
+)
+```
+
+The following example comes from `third_party/kde/BUILD`.
+We keep pre-built `.so` files in the depot.
+The header files live in a subdirectory named `include`.
+
+```
+cc_library(
+    name = "kde",
+    srcs = [
+        "lib/libDCOP.so",
+        "lib/libkdesu.so",
+        "lib/libkhtml.so",
+        "lib/libkparts.so",
+        ...more .so files...,
+    ],
+    includes = ["include"],
+    deps = ["//third_party/X11"],
+)
+```
+
+The following example comes from `third_party/gles/BUILD`.
+Third-party code often needs some `defines` and
+`linkopts`.
+
+```
+cc_library(
+    name = "gles",
+    srcs = [
+        "GLES/egl.h",
+        "GLES/gl.h",
+        "ddx.c",
+        "egl.c",
+    ],
+    defines = [
+        "USE_FLOAT",
+        "__GL_FLOAT",
+        "__GL_COMMON",
+    ],
+    linkopts = ["-ldl"],  # uses dlopen(), dl library
+    deps = [
+        "es",
+        "//third_party/X11",
+    ],
+)
+```
+
+### Arguments
+
+| Attributes | |
+| --- | --- |
+| `name` | [Name](/versions/9.1.0/concepts/labels#target-names); required  A unique name for this target. |
+| `deps` | List of [labels](/versions/9.1.0/concepts/labels); default is `[]` The list of other libraries that the library target depends upon. These can be `cc_library` or `objc_library` targets.  See general comments about `deps` at [Typical attributes defined by most build rules](/versions/9.1.0/reference/be/common-definitions#typical-attributes).  These should be names of C++ library rules. When you build a binary that links this rule's library, you will also link the libraries in `deps`.  Despite the "deps" name, not all of this library's clients belong here. Run-time data dependencies belong in `data`. Source files generated by other rules belong in `srcs`.  To link in a pre-compiled third-party library, add its name to the `srcs` instead.  To depend on something without linking it to this library, add its name to the `data` instead. |
+| `srcs` | List of [labels](/versions/9.1.0/concepts/labels); default is `[]` The list of C and C++ files that are processed to create the library target. These are C/C++ source and header files, either non-generated (normal source code) or generated. All `.cc`, `.c`, and `.cpp` files will be compiled. These might be generated files: if a named file is in the `outs` of some other rule, this `cc_library` will automatically depend on that other rule.  Pure assembler files (.s, .asm) are not preprocessed and are typically built using the assembler. Preprocessed assembly files (.S) are preprocessed and are typically built using the C/C++ compiler.  A `.h` file will not be compiled, but will be available for inclusion by sources in this rule. Both `.cc` and `.h` files can directly include headers listed in these `srcs` or in the `hdrs` of this rule or any rule listed in the `deps` argument.  All `#include`d files must be mentioned in the `hdrs` attribute of this or referenced `cc_library` rules, or they should be listed in `srcs` if they are private to this library. See ["Header inclusion checking"](#hdrs) for a more detailed description.  `.so`, `.lo`, and `.a` files are pre-compiled files. Your library might have these as `srcs` if it uses third-party code for which we don't have source code.  If the `srcs` attribute includes the label of another rule, `cc_library` will use the output files of that rule as source files to compile. This is useful for one-off generation of source code (for more than occasional use, it's better to implement a Starlark rule class and use the `cc_common` API)  Permitted `srcs` file types:   * C and C++ source files: `.c`, `.cc`, `.cpp`,   `.cxx`, `.c++`, `.C` * C and C++ header files: `.h`, `.hh`, `.hpp`,   `.hxx`, `.inc`, `.inl`, `.H` * Assembler with C preprocessor: `.S` * Archive: `.a`, `.pic.a` * "Always link" library: `.lo`, `.pic.lo` * Shared library, versioned or unversioned: `.so`,   `.so.version` * Object file: `.o`, `.pic.o`   ... and any rules that produce those files (e.g. `cc_embed_data`). Different extensions denote different programming languages in accordance with gcc convention. |
+| `data` | List of [labels](/versions/9.1.0/concepts/labels); default is `[]` The list of files needed by this library at runtime. See general comments about `data` at [Typical attributes defined by most build rules](/versions/9.1.0/reference/be/common-definitions#typical-attributes). If a `data` is the name of a generated file, then this `cc_library` rule automatically depends on the generating rule.  If a `data` is a rule name, then this `cc_library` rule automatically depends on that rule, and that rule's `outs` are automatically added to this `cc_library`'s data files.  Your C++ code can access these data files like so:   ```   const std::string path = devtools_build::GetDataDependencyFilepath(       "my/test/data/file"); ``` |
+| `hdrs` | List of [labels](/versions/9.1.0/concepts/labels); default is `[]` The list of header files published by this library to be directly included by sources in dependent rules. This is the strongly preferred location for declaring header files that describe the interface for the library. These headers will be made available for inclusion by sources in this rule or in dependent rules. Headers not meant to be included by a client of this library should be listed in the `srcs` attribute instead, even if they are included by a published header. See ["Header inclusion checking"](#hdrs) for a more detailed description.  Permitted `headers` file types: `.h`, `.hh`, `.hpp`, `.hxx`. |
+| `additional_compiler_inputs` | List of [labels](/versions/9.1.0/concepts/labels); default is `[]` Any additional files you might want to pass to the compiler command line, such as sanitizer ignorelists, for example. Files specified here can then be used in copts with the $(location) function. |
+| `additional_linker_inputs` | List of [labels](/versions/9.1.0/concepts/labels); default is `[]` Dependencies that are only made available to the C++ linker command. Unlike `deps`, which is conceptually made for both compilation and linking dependencies, `additional_linker_inputs` is specifically made for only the latter, and signals a dependency that is required only for linking (for example, files that are referenced in `linkopts`).  For example, compiled Windows .res files can be provided here to be embedded in the binary target. |
+| `alwayslink` | Boolean; default is `False` If 1, any binary that depends (directly or indirectly) on this C++ library will link in all the object files for the files listed in `srcs`, even if some contain no symbols referenced by the binary. This is useful if your code isn't explicitly called by code in the binary, e.g., if your code registers to receive some callback provided by some service. If alwayslink doesn't work with VS 2017 on Windows, that is due to a [known issue](https://github.com/bazelbuild/bazel/issues/3949), please upgrade your VS 2017 to the latest version. |
+| `conlyopts` | List of strings; default is `[]` Add these options to the C compilation command. Subject to ["Make variable"](/versions/9.1.0/reference/be/make-variables) substitution and [Bourne shell tokenization](/versions/9.1.0/reference/be/common-definitions#sh-tokenization). |
+| `copts` | List of strings; default is `[]` Add these options to the C/C++ compilation command. Subject to ["Make variable"](/versions/9.1.0/reference/be/make-variables) substitution and [Bourne shell tokenization](/versions/9.1.0/reference/be/common-definitions#sh-tokenization). Each string in this attribute is added in the given order to `COPTS` before compiling the binary target. The flags take effect only for compiling this target, not its dependencies, so be careful about header files included elsewhere. All paths should be relative to the workspace, not to the current package. This attribute should not be needed outside of `third_party`.  If the package declares the [feature](/versions/9.1.0/reference/be/functions#package.features) `no_copts_tokenization`, Bourne shell tokenization applies only to strings that consist of a single "Make" variable. |
+| `cxxopts` | List of strings; default is `[]` Add these options to the C++ compilation command. Subject to ["Make variable"](/versions/9.1.0/reference/be/make-variables) substitution and [Bourne shell tokenization](/versions/9.1.0/reference/be/common-definitions#sh-tokenization). |
+| `defines` | List of strings; default is `[]` List of defines to add to the compile line of this and all dependent targets. Subject to ["Make" variable](/versions/9.1.0/reference/be/make-variables) substitution and [Bourne shell tokenization](/versions/9.1.0/reference/be/common-definitions#sh-tokenization). Each string, which must consist of a single Bourne shell token, is prepended with `-D` and added to the compile command line to this target, as well as to every rule that depends on it. Be very careful, since this may have far-reaching effects -- the defines are added to every target that depends on this target. When in doubt, add define values to [`local_defines`](#cc_binary.local_defines) instead. |
+| `hdrs_check` | String; default is `""` Deprecated, no-op. |
+| `implementation_deps` | List of [labels](/versions/9.1.0/concepts/labels); default is `[]` The list of other libraries that the library target depends on. Unlike with `deps`, the headers and include paths of these libraries (and all their transitive deps) are only used for compilation of this library, and not libraries that depend on it. Libraries specified with `implementation_deps` are still linked in binary targets that depend on this library. |
+| `include_prefix` | String; default is `""` The prefix to add to the paths of the headers of this rule. When set, the headers in the `hdrs` attribute of this rule are accessible at is the value of this attribute prepended to their repository-relative path. The prefix in the `strip_include_prefix` attribute is removed before this prefix is added. This attribute is only legal under `third_party`. |
+| `includes` | List of strings; default is `[]` List of include dirs to be added to the compile line. Subject to ["Make variable"](/versions/9.1.0/reference/be/make-variables) substitution. Each string is prepended with the package path and passed to the C++ toolchain for expansion via the "include_paths" CROSSTOOL feature. A toolchain running on a POSIX system with typical feature definitions will produce `-isystem path_to_package/include_entry`. This should only be used for third-party libraries that do not conform to the Google style of writing #include statements. Unlike [COPTS](#cc_binary.copts), these flags are added for this rule and every rule that depends on it. (Note: not the rules it depends upon!) Be very careful, since this may have far-reaching effects. When in doubt, add "-I" flags to [COPTS](#cc_binary.copts) instead. The added `include` paths will include generated files as well as files in the source tree. |
+| `linkopts` | List of strings; default is `[]` See [`cc_binary.linkopts`](/versions/9.1.0/reference/be/c-cpp#cc_binary.linkopts). The `linkopts` attribute is also applied to any target that depends, directly or indirectly, on this library via `deps` attributes (or via other attributes that are treated similarly: the [`malloc`](/versions/9.1.0/reference/be/c-cpp#cc_binary.malloc) attribute of [`cc_binary`](/versions/9.1.0/reference/be/c-cpp#cc_binary)). Dependency linkopts take precedence over dependent linkopts (i.e. dependency linkopts appear later in the command line). Linkopts specified in [`--linkopt`](/versions/9.1.0/reference/user-manual#flag--linkopt) take precedence over rule linkopts. |
+
+Note that the `linkopts` attribute only applies
+when creating `.so` files or executables, not
+when creating `.a` or `.lo` files.
+So if the `linkstatic=True` attribute is set, the
+`linkopts` attribute has no effect on the creation of
+this library, only on other targets which depend on this library.
+
+Also, it is important to note that "-Wl,-soname" or "-Xlinker -soname"
+options are not supported and should never be specified in this attribute.
+
+The `.so` files produced by `cc_library`
+rules are not linked against the libraries that they depend
+on. If you're trying to create a shared library for use
+outside of the main repository, e.g. for manual use
+with `dlopen()` or `LD_PRELOAD`,
+it may be better to use a `cc_binary` rule
+with the `linkshared=True` attribute.
+See [`cc_binary.linkshared`](/versions/9.1.0/reference/be/c-cpp#cc_binary.linkshared).
+
+| `linkstamp` | [Label](/versions/9.1.0/concepts/labels); default is `None` Simultaneously compiles and links the specified C++ source file into the final binary. This trickery is required to introduce timestamp information into binaries; if we compiled the source file to an object file in the usual way, the timestamp would be incorrect. A linkstamp compilation may not include any particular set of compiler flags and so should not depend on any particular header, compiler option, or other build variable. *This option should only be needed in the `base` package.* |
+| `linkstatic` | Boolean; default is `False` For [`cc_binary`](/versions/9.1.0/reference/be/c-cpp#cc_binary) and [`cc_test`](/versions/9.1.0/reference/be/c-cpp#cc_test): link the binary in static mode. For `cc_library.link_static`: see below. By default this option is on for `cc_binary` and off for the rest.  If enabled and this is a binary or test, this option tells the build tool to link in `.a`'s instead of `.so`'s for user libraries whenever possible. System libraries such as libc (but *not* the C/C++ runtime libraries, see below) are still linked dynamically, as are libraries for which there is no static library. So the resulting executable will still be dynamically linked, hence only *mostly* static.  There are really three different ways to link an executable:   * STATIC with fully_static_link feature, in which everything is linked statically;   e.g. "`gcc -static foo.o libbar.a libbaz.a -lm`".    This mode is enabled by specifying `fully_static_link` in the   [`features`](/versions/9.1.0/reference/be/common-definitions#features) attribute. * STATIC, in which all user libraries are linked statically (if a static   version is available), but where system libraries (excluding C/C++ runtime libraries)   are linked dynamically, e.g. "`gcc foo.o libfoo.a libbaz.a -lm`".    This mode is enabled by specifying `linkstatic=True`. * DYNAMIC, in which all libraries are linked dynamically (if a dynamic version is   available), e.g. "`gcc foo.o libfoo.so libbaz.so -lm`".    This mode is enabled by specifying `linkstatic=False`.   If the `linkstatic` attribute or `fully_static_link` in `features` is used outside of `//third_party` please include a comment near the rule to explain why.  The `linkstatic` attribute has a different meaning if used on a [`cc_library()`](/versions/9.1.0/reference/be/c-cpp#cc_library) rule. For a C++ library, `linkstatic=True` indicates that only static linking is allowed, so no `.so` will be produced. linkstatic=False does not prevent static libraries from being created. The attribute is meant to control the creation of dynamic libraries.  There should be very little code built with `linkstatic=False` in production. If `linkstatic=False`, then the build tool will create symlinks to depended-upon shared libraries in the `*.runfiles` area. |
+| `local_defines` | List of strings; default is `[]` List of defines to add to the compile line. Subject to ["Make" variable](/versions/9.1.0/reference/be/make-variables) substitution and [Bourne shell tokenization](/versions/9.1.0/reference/be/common-definitions#sh-tokenization). Each string, which must consist of a single Bourne shell token, is prepended with `-D` and added to the compile command line for this target, but not to its dependents. Unlike `defines`, the defines are only added to the compile command line for this target. |
+| `module_interfaces` | List of [labels](/versions/9.1.0/concepts/labels); default is `[]` The list of files are regarded as C++20 Modules Interface. C++ Standard has no restriction about module interface file extension  * Clang use cppm * GCC can use any source file extension * MSVC use ixx  The use is guarded by the flag `--experimental_cpp_modules`. |
+| `strip_include_prefix` | String; default is `""` The prefix to strip from the paths of the headers of this rule. When set, the headers in the `hdrs` attribute of this rule are accessible at their path with this prefix cut off. If it's a relative path, it's taken as a package-relative one. If it's an absolute one, it's understood as a repository-relative path. The prefix in the `include_prefix` attribute is added after this prefix is stripped. This attribute is only legal under `third_party`. |
+| `textual_hdrs` | List of [labels](/versions/9.1.0/concepts/labels); default is `[]` The list of header files published by this library to be textually included by sources in dependent rules. This is the location for declaring header files that cannot be compiled on their own; that is, they always need to be textually included by other source files to build valid code. |
+| `win_def_file` | [Label](/versions/9.1.0/concepts/labels); default is `None` The Windows DEF file to be passed to linker. This attribute should only be used when Windows is the target platform. It can be used to [export symbols](https://msdn.microsoft.com/en-us/library/d91k01sh.aspx) during linking a shared library. |
+
+## cc_shared_library
+
+[View rule sourceopen_in_new](https://github.com/bazelbuild/rules_cc/blob/master/cc/private/rules_impl/cc_shared_library.bzl)
+
+```
+cc_shared_library(name, deps, additional_linker_inputs, aspect_hints, compatible_with, deprecation, dynamic_deps, exec_compatible_with, exec_group_compatible_with, exec_properties, exports_filter, features, package_metadata, restricted_to, roots, shared_lib_name, static_deps, tags, target_compatible_with, testonly, toolchains, user_link_flags, visibility, win_def_file)
+```
+
+It produces a shared library.
+
+#### Example
+
+```
+cc_shared_library(
+    name = "foo_shared",
+    deps = [
+        ":foo",
+    ],
+    dynamic_deps = [
+        ":bar_shared",
+    ],
+    additional_linker_inputs = [
+        ":foo.lds",
+    ],
+    user_link_flags = [
+        "-Wl,--version-script=$(location :foo.lds)",
+    ],
+)
+cc_library(
+    name = "foo",
+    srcs = ["foo.cc"],
+    hdrs = ["foo.h"],
+    deps = [
+        ":bar",
+        ":baz",
+    ],
+)
+cc_shared_library(
+    name = "bar_shared",
+    shared_lib_name = "bar.so",
+    deps = [":bar"],
+)
+cc_library(
+    name = "bar",
+    srcs = ["bar.cc"],
+    hdrs = ["bar.h"],
+)
+cc_library(
+    name = "baz",
+    srcs = ["baz.cc"],
+    hdrs = ["baz.h"],
+)
+```
+
+In the example `foo_shared` statically links `foo`
+and `baz`, the latter being a transitive dependency. It doesn't
+link `bar` because it is already provided dynamically by the
+`dynamic_dep` `bar_shared`.
+
+`foo_shared` uses a linker script \*.lds file to control which
+symbols should be exported. The `cc_shared_library` rule logic does
+not control which symbols get exported, it only uses what is assumed to be
+exported to give errors during analysis phase if two shared libraries export the
+same targets.
+
+Every direct dependency of `cc_shared_library` is assumed to be
+exported. Therefore, Bazel assumes during analysis that `foo` is being
+exported by `foo_shared`. `baz` is not assumed to be exported
+by `foo_shared`. Every target matched by the `exports_filter`
+is also assumed to be exported.
+
+Every single `cc_library` in the example should appear at most in one
+`cc_shared_library`. If we wanted to link `baz` also into
+`bar_shared` we would need to add
+`tags = ["LINKABLE_MORE_THAN_ONCE"]` to `baz`.
+
+Due to the `shared_lib_name` attribute, the file produced by
+`bar_shared` will have the name `bar.so` as opposed
+to the name `libbar.so` that it would have by default on Linux.
+
+#### Errors
+
+##### `Two shared libraries in dependencies export the same symbols.`
+
+This will happen whenever you are creating a target with two different
+`cc_shared_library` dependencies that export the same target. To fix this
+you need to stop the libraries from being exported in one of the
+`cc_shared_library` dependencies.
+
+##### `Two shared libraries in dependencies link the same library statically`
+
+This will happen whenever you are creating a new `cc_shared_library` with two
+different `cc_shared_library` dependencies that link the same target statically.
+Similar to the error with exports.
+
+One way to fix this is to stop linking the library into one of the
+`cc_shared_library` dependencies. At the same time, the one that still links it
+needs to export the library so that the one not linking it keeps visibility to
+the symbols. Another way is to pull out a third library that exports the target.
+A third way is to tag the culprit `cc_library` with `LINKABLE_MORE_THAN_ONCE`
+but this fix should be rare and you should absolutely make sure that the
+`cc_library` is indeed safe to link more than once.
+
+##### `` '//foo:foo' is already linked statically in '//bar:bar' but not exported` ``
+
+This means that a library in the transitive closure of your `deps` is reachable
+without going through one of the `cc_shared_library` dependencies but is already
+linked into a different `cc_shared_library` in `dynamic_deps` and is not
+exported.
+
+The solution is to export it from the `cc_shared_library` dependency or pull out
+a third `cc_shared_library` that exports it.
+
+##### `Do not place libraries which only contain a precompiled dynamic library in deps.`
+
+If you have a precompiled dynamic library, this doesn't need to and cannot be
+linked statically into the current `cc_shared_library` target that you are
+currently creating. Therefore, it doesn't belong in `deps` of the
+`cc_shared_library`. If this precompiled dynamic library is a dependency of one
+of your `cc_libraries`, then the `cc_library` needs to depend on it
+directly.
+
+##### `Trying to export a library already exported by a different shared library`
+
+You will see this error if on the current rule you are claiming to export a
+target that is already being exported by one of your dynamic dependencies.
+
+To fix this, remove the target from `deps` and just rely on it from the dynamic
+dependency or make sure that the `exports_filter` doesn't catch this target.
+
+### Arguments
+
+| Attributes | |
+| --- | --- |
+| `name` | [Name](/versions/9.1.0/concepts/labels#target-names); required  A unique name for this target. |
+| `deps` | List of [labels](/versions/9.1.0/concepts/labels); default is `[]` Top level libraries that will unconditionally be statically linked into the shared library after being whole-archived. Any transitive library dependency of these direct deps will be linked into this shared library as long as they have not already been linked by a `cc_shared_library` in `dynamic_deps`.  During analysis, the rule implementation will consider any target listed in `deps` as being exported by the shared library in order to give errors when multiple `cc_shared_libraries` export the same targets. The rule implementation does not take care of informing the linker about which symbols should be exported by the shared object. The user should take care of this via linker scripts or visibility declarations in the source code.  The implementation will also trigger errors whenever the same library is linked statically into more than one `cc_shared_library`. This can be avoided by adding `"LINKABLE_MORE_THAN_ONCE"` to the `cc_library.tags` or by listing the `cc_library` as an export of one of the shared libraries so that one can be made a `dynamic_dep` of the other. |
+| `additional_linker_inputs` | List of [labels](/versions/9.1.0/concepts/labels); default is `[]` Any additional files that you may want to pass to the linker, for example, linker scripts. You have to separately pass any linker flags that the linker needs in order to be aware of this file. You can do so via the `user_link_flags` attribute. |
+| `dynamic_deps` | List of [labels](/versions/9.1.0/concepts/labels); default is `[]` These are other `cc_shared_library` dependencies the current target depends on. The `cc_shared_library` implementation will use the list of `dynamic_deps` (transitively, i.e. also the `dynamic_deps` of the current target's `dynamic_deps`) to decide which `cc_libraries` in the transitive `deps` should not be linked in because they are already provided by a different `cc_shared_library`. |
+| `exports_filter` | List of strings; default is `[]` This attribute contains a list of targets that are claimed to be exported by the current shared library. Any target `deps` is already understood to be exported by the shared library. This attribute should be used to list any targets that are exported by the shared library but are transitive dependencies of `deps`.  Note that this attribute is not actually adding a dependency edge to those targets, the dependency edge should instead be created by `deps`.The entries in this attribute are just strings. Keep in mind that when placing a target in this attribute, this is considered a claim that the shared library exports the symbols from that target. The `cc_shared_library` logic doesn't actually handle telling the linker which symbols should be exported.  The following syntax is allowed:  `//foo:__pkg__` to account for any target in foo/BUILD  `//foo:__subpackages__` to account for any target in foo/BUILD or any other package below foo/ like foo/bar/BUILD |
+| `roots` | List of [labels](/versions/9.1.0/concepts/labels); default is `[]` |
+| `shared_lib_name` | String; default is `""` By default cc_shared_library will use a name for the shared library output file based on the target's name and the platform. This includes an extension and sometimes a prefix. Sometimes you may not want the default name, for example, when loading C++ shared libraries for Python the default lib\* prefix is often not desired, in which case you can use this attribute to choose a custom name. |
+| `static_deps` | List of strings; default is `[]` |
+| `user_link_flags` | List of strings; default is `[]` Any additional flags that you may want to pass to the linker. For example, to make the linker aware of a linker script passed via additional_linker_inputs you can use the following:  ```  cc_shared_library(     name = "foo_shared",     additional_linker_inputs = select({       "//src/conditions:linux": [         ":foo.lds",         ":additional_script.txt",       ],       "//conditions:default": []}),     user_link_flags = select({       "//src/conditions:linux": [         "-Wl,-rpath,kittens",         "-Wl,--version-script=$(location :foo.lds)",         "-Wl,--script=$(location :additional_script.txt)",       ],       "//conditions:default": []}),       ...  ) ``` |
+| `win_def_file` | [Label](/versions/9.1.0/concepts/labels); default is `None` The Windows DEF file to be passed to linker. This attribute should only be used when Windows is the target platform. It can be used to [export symbols](https://msdn.microsoft.com/en-us/library/d91k01sh.aspx) during linking a shared library. |
+
+## cc_static_library
+
+[View rule sourceopen_in_new](https://github.com/bazelbuild/rules_cc/blob/master/cc/private/rules_impl/cc_static_library.bzl)
+
+```
+cc_static_library(name, deps, aspect_hints, compatible_with, deprecation, exec_compatible_with, exec_group_compatible_with, exec_properties, features, package_metadata, restricted_to, tags, target_compatible_with, testonly, toolchains, visibility)
+```
+
+Produces a static library from a list of targets and their transitive dependencies.
+
+The resulting static library contains the object files of the targets listed in
+`deps` as well as their transitive dependencies, with preference given to
+`PIC` objects.
+
+#### Output groups
+
+##### `linkdeps`
+
+A text file containing the labels of those transitive dependencies of targets listed in
+`deps` that did not contribute any object files to the static library, but do
+provide at least one static, dynamic or interface library. The resulting static library
+may require these libraries to be available at link time.
+
+##### `linkopts`
+
+A text file containing the user-provided `linkopts` of all transitive
+dependencies of targets listed in `deps`.
+
+#### Duplicate symbols
+
+By default, the `cc_static_library` rule checks that the resulting static
+library does not contain any duplicate symbols. If it does, the build fails with an error
+message that lists the duplicate symbols and the object files containing them.
+
+This check can be disabled per target or per package by setting
+`features = ["-symbol_check"]` or globally via
+`--features=-symbol_check`.
+
+##### Toolchain support for `symbol_check`
+
+The auto-configured C++ toolchains shipped with Bazel support the
+`symbol_check` feature on all platforms. Custom toolchains can add support for
+it in one of two ways:
+
+* Implementing the `ACTION_NAMES.validate_static_library` action and
+  enabling it with the `symbol_check` feature. The tool set in the action is
+  invoked with two arguments, the static library to check for duplicate symbols and the
+  path of a file that must be created if the check passes.
+* Having the `symbol_check` feature add archiver flags that cause the
+  action creating the static library to fail on duplicate symbols.
+
+### Arguments
+
+| Attributes | |
+| --- | --- |
+| `name` | [Name](/versions/9.1.0/concepts/labels#target-names); required  A unique name for this target. |
+| `deps` | List of [labels](/versions/9.1.0/concepts/labels); default is `[]` The list of targets to combine into a static library, including all their transitive dependencies. Dependencies that do not provide any object files are not included in the static library, but their labels are collected in the file provided by the `linkdeps` output group. |
+
+## cc_test
+
+[View rule sourceopen_in_new](https://github.com/bazelbuild/rules_cc/blob/master/cc/private/rules_impl/cc_test.bzl)
+
+```
+cc_test(name, deps, srcs, data, additional_compiler_inputs, additional_linker_inputs, args, aspect_hints, compatible_with, conlyopts, copts, cxxopts, defines, deprecation, dynamic_deps, env, env_inherit, exec_compatible_with, exec_group_compatible_with, exec_properties, features, flaky, hdrs_check, includes, licenses, link_extra_lib, linkopts, linkshared, linkstatic, local, local_defines, malloc, module_interfaces, nocopts, package_metadata, reexport_deps, restricted_to, shard_count, size, stamp, tags, target_compatible_with, testonly, timeout, toolchains, visibility, win_def_file)
+```
+
+A `cc_test()` rule compiles a test. Here, a test
+is a binary wrapper around some testing code.
+
+*By default, C++ tests are dynamically linked.*
+To statically link a unit test, specify
+[`linkstatic=True`](/versions/9.1.0/reference/be/c-cpp#cc_binary.linkstatic).
+It would probably be good to comment why your test needs
+`linkstatic`; this is probably not obvious.
+
+#### Implicit output targets
+
+* `name.stripped` (only built if explicitly requested): A stripped
+  version of the binary. `strip -g` is run on the binary to remove debug
+  symbols. Additional strip options can be provided on the command line using
+  `--stripopt=-foo`.
+* `name.dwp` (only built if explicitly requested): If
+  [Fission](https://gcc.gnu.org/wiki/DebugFission) is enabled: a debug
+  information package file suitable for debugging remotely deployed binaries. Else: an
+  empty file.
+
+See the [cc_binary()](/versions/9.1.0/reference/be/c-cpp#cc_binary_args) arguments, except that
+the `stamp` argument is set to 0 by default for tests and
+that `cc_test` has extra [attributes common to all test rules (\*\_test)](/versions/9.1.0/reference/be/common-definitions#common-attributes-tests).
+
+### Arguments
+
+| Attributes | |
+| --- | --- |
+| `name` | [Name](/versions/9.1.0/concepts/labels#target-names); required  A unique name for this target. |
+| `deps` | List of [labels](/versions/9.1.0/concepts/labels); default is `[]` The list of other libraries to be linked in to the binary target. These can be `cc_library` or `objc_library` targets. It is also allowed to put linker scripts (.lds) into deps, and reference them in [`linkopts`](#cc_binary.linkopts), but please consider [`additional_linker_inputs`](#cc_binary.additional_linker_inputs) for that use case. |
+| `srcs` | List of [labels](/versions/9.1.0/concepts/labels); default is `[]` The list of C and C++ files that are processed to create the library target. These are C/C++ source and header files, either non-generated (normal source code) or generated. All `.cc`, `.c`, and `.cpp` files will be compiled. These might be generated files: if a named file is in the `outs` of some other rule, this `cc_library` will automatically depend on that other rule.  Pure assembler files (.s, .asm) are not preprocessed and are typically built using the assembler. Preprocessed assembly files (.S) are preprocessed and are typically built using the C/C++ compiler.  A `.h` file will not be compiled, but will be available for inclusion by sources in this rule. Both `.cc` and `.h` files can directly include headers listed in these `srcs` or in the `hdrs` of this rule or any rule listed in the `deps` argument.  All `#include`d files must be mentioned in the `hdrs` attribute of this or referenced `cc_library` rules, or they should be listed in `srcs` if they are private to this library. See ["Header inclusion checking"](#hdrs) for a more detailed description.  `.so`, `.lo`, and `.a` files are pre-compiled files. Your library might have these as `srcs` if it uses third-party code for which we don't have source code.  If the `srcs` attribute includes the label of another rule, `cc_library` will use the output files of that rule as source files to compile. This is useful for one-off generation of source code (for more than occasional use, it's better to implement a Starlark rule class and use the `cc_common` API)  Permitted `srcs` file types:   * C and C++ source files: `.c`, `.cc`, `.cpp`,   `.cxx`, `.c++`, `.C` * C and C++ header files: `.h`, `.hh`, `.hpp`,   `.hxx`, `.inc`, `.inl`, `.H` * Assembler with C preprocessor: `.S` * Archive: `.a`, `.pic.a` * "Always link" library: `.lo`, `.pic.lo` * Shared library, versioned or unversioned: `.so`,   `.so.version` * Object file: `.o`, `.pic.o`   ... and any rules that produce those files (e.g. `cc_embed_data`). Different extensions denote different programming languages in accordance with gcc convention. |
+| `data` | List of [labels](/versions/9.1.0/concepts/labels); default is `[]` The list of files needed by this library at runtime. See general comments about `data` at [Typical attributes defined by most build rules](/versions/9.1.0/reference/be/common-definitions#typical-attributes). If a `data` is the name of a generated file, then this `cc_library` rule automatically depends on the generating rule.  If a `data` is a rule name, then this `cc_library` rule automatically depends on that rule, and that rule's `outs` are automatically added to this `cc_library`'s data files.  Your C++ code can access these data files like so:   ```   const std::string path = devtools_build::GetDataDependencyFilepath(       "my/test/data/file"); ``` |
+| `additional_compiler_inputs` | List of [labels](/versions/9.1.0/concepts/labels); default is `[]` Any additional files you might want to pass to the compiler command line, such as sanitizer ignorelists, for example. Files specified here can then be used in copts with the $(location) function. |
+| `additional_linker_inputs` | List of [labels](/versions/9.1.0/concepts/labels); default is `[]` Dependencies that are only made available to the C++ linker command. Unlike `deps`, which is conceptually made for both compilation and linking dependencies, `additional_linker_inputs` is specifically made for only the latter, and signals a dependency that is required only for linking (for example, files that are referenced in `linkopts`).  For example, compiled Windows .res files can be provided here to be embedded in the binary target. |
+| `conlyopts` | List of strings; default is `[]` Add these options to the C compilation command. Subject to ["Make variable"](/versions/9.1.0/reference/be/make-variables) substitution and [Bourne shell tokenization](/versions/9.1.0/reference/be/common-definitions#sh-tokenization). |
+| `copts` | List of strings; default is `[]` Add these options to the C/C++ compilation command. Subject to ["Make variable"](/versions/9.1.0/reference/be/make-variables) substitution and [Bourne shell tokenization](/versions/9.1.0/reference/be/common-definitions#sh-tokenization). Each string in this attribute is added in the given order to `COPTS` before compiling the binary target. The flags take effect only for compiling this target, not its dependencies, so be careful about header files included elsewhere. All paths should be relative to the workspace, not to the current package. This attribute should not be needed outside of `third_party`.  If the package declares the [feature](/versions/9.1.0/reference/be/functions#package.features) `no_copts_tokenization`, Bourne shell tokenization applies only to strings that consist of a single "Make" variable. |
+| `cxxopts` | List of strings; default is `[]` Add these options to the C++ compilation command. Subject to ["Make variable"](/versions/9.1.0/reference/be/make-variables) substitution and [Bourne shell tokenization](/versions/9.1.0/reference/be/common-definitions#sh-tokenization). |
+| `defines` | List of strings; default is `[]` List of defines to add to the compile line of this and all dependent targets. Subject to ["Make" variable](/versions/9.1.0/reference/be/make-variables) substitution and [Bourne shell tokenization](/versions/9.1.0/reference/be/common-definitions#sh-tokenization). Each string, which must consist of a single Bourne shell token, is prepended with `-D` and added to the compile command line to this target, as well as to every rule that depends on it. Be very careful, since this may have far-reaching effects -- the defines are added to every target that depends on this target. When in doubt, add define values to [`local_defines`](#cc_binary.local_defines) instead. |
+| `dynamic_deps` | List of [labels](/versions/9.1.0/concepts/labels); default is `[]` These are other `cc_shared_library` dependencies the current target depends on. The `cc_shared_library` implementation will use the list of `dynamic_deps` (transitively, i.e. also the `dynamic_deps` of the current target's `dynamic_deps`) to decide which `cc_libraries` in the transitive `deps` should not be linked in because they are already provided by a different `cc_shared_library`. |
+| `hdrs_check` | String; default is `""` Deprecated, no-op. |
+| `includes` | List of strings; default is `[]` List of include dirs to be added to the compile line. Subject to ["Make variable"](/versions/9.1.0/reference/be/make-variables) substitution. Each string is prepended with the package path and passed to the C++ toolchain for expansion via the "include_paths" CROSSTOOL feature. A toolchain running on a POSIX system with typical feature definitions will produce `-isystem path_to_package/include_entry`. This should only be used for third-party libraries that do not conform to the Google style of writing #include statements. Unlike [COPTS](#cc_binary.copts), these flags are added for this rule and every rule that depends on it. (Note: not the rules it depends upon!) Be very careful, since this may have far-reaching effects. When in doubt, add "-I" flags to [COPTS](#cc_binary.copts) instead. The added `include` paths will include generated files as well as files in the source tree. |
+| `link_extra_lib` | [Label](/versions/9.1.0/concepts/labels); default is `"@bazel_tools//tools/cpp:link_extra_lib"` Control linking of extra libraries. By default, C++ binaries are linked against `@bazel_tools//tools/cpp:link_extra_lib`, which by default depends on the label flag `@bazel_tools//tools/cpp:link_extra_libs`. Without setting the flag, this library is empty by default. Setting the label flag allows linking optional dependencies, such as overrides for weak symbols, interceptors for shared library functions, or special runtime libraries (for malloc replacements, prefer `malloc` or `--custom_malloc`). Setting this attribute to `None` disables this behaviour. |
+| `linkopts` | List of strings; default is `[]` Add these flags to the C++ linker command. Subject to ["Make" variable](/versions/9.1.0/reference/be/make-variables) substitution, [Bourne shell tokenization](/versions/9.1.0/reference/be/common-definitions#sh-tokenization) and [label expansion](/versions/9.1.0/reference/be/common-definitions#label-expansion). Each string in this attribute is added to `LINKOPTS` before linking the binary target. Each element of this list that does not start with `$` or `-` is assumed to be the label of a target in `deps`. The list of files generated by that target is appended to the linker options. An error is reported if the label is invalid, or is not declared in `deps`. |
+| `linkshared` | Boolean; default is `False` Create a shared library. To enable this attribute, include `linkshared=True` in your rule. By default this option is off. The presence of this flag means that linking occurs with the `-shared` flag to `gcc`, and the resulting shared library is suitable for loading into for example a Java program. However, for build purposes it will never be linked into the dependent binary, as it is assumed that shared libraries built with a [cc_binary](#cc_binary) rule are only loaded manually by other programs, so it should not be considered a substitute for the [cc_library](#cc_library) rule. For sake of scalability we recommend avoiding this approach altogether and simply letting `java_library` depend on `cc_library` rules instead.  If you specify both `linkopts=['-static']` and `linkshared=True`, you get a single completely self-contained unit. If you specify both `linkstatic=True` and `linkshared=True`, you get a single, mostly self-contained unit. |
+| `linkstatic` | Boolean; default is `False` For [`cc_binary`](/versions/9.1.0/reference/be/c-cpp#cc_binary) and [`cc_test`](/versions/9.1.0/reference/be/c-cpp#cc_test): link the binary in static mode. For `cc_library.link_static`: see below. By default this option is on for `cc_binary` and off for the rest.  If enabled and this is a binary or test, this option tells the build tool to link in `.a`'s instead of `.so`'s for user libraries whenever possible. System libraries such as libc (but *not* the C/C++ runtime libraries, see below) are still linked dynamically, as are libraries for which there is no static library. So the resulting executable will still be dynamically linked, hence only *mostly* static.  There are really three different ways to link an executable:   * STATIC with fully_static_link feature, in which everything is linked statically;   e.g. "`gcc -static foo.o libbar.a libbaz.a -lm`".    This mode is enabled by specifying `fully_static_link` in the   [`features`](/versions/9.1.0/reference/be/common-definitions#features) attribute. * STATIC, in which all user libraries are linked statically (if a static   version is available), but where system libraries (excluding C/C++ runtime libraries)   are linked dynamically, e.g. "`gcc foo.o libfoo.a libbaz.a -lm`".    This mode is enabled by specifying `linkstatic=True`. * DYNAMIC, in which all libraries are linked dynamically (if a dynamic version is   available), e.g. "`gcc foo.o libfoo.so libbaz.so -lm`".    This mode is enabled by specifying `linkstatic=False`.   If the `linkstatic` attribute or `fully_static_link` in `features` is used outside of `//third_party` please include a comment near the rule to explain why.  The `linkstatic` attribute has a different meaning if used on a [`cc_library()`](/versions/9.1.0/reference/be/c-cpp#cc_library) rule. For a C++ library, `linkstatic=True` indicates that only static linking is allowed, so no `.so` will be produced. linkstatic=False does not prevent static libraries from being created. The attribute is meant to control the creation of dynamic libraries.  There should be very little code built with `linkstatic=False` in production. If `linkstatic=False`, then the build tool will create symlinks to depended-upon shared libraries in the `*.runfiles` area. |
+| `local_defines` | List of strings; default is `[]` List of defines to add to the compile line. Subject to ["Make" variable](/versions/9.1.0/reference/be/make-variables) substitution and [Bourne shell tokenization](/versions/9.1.0/reference/be/common-definitions#sh-tokenization). Each string, which must consist of a single Bourne shell token, is prepended with `-D` and added to the compile command line for this target, but not to its dependents. Unlike `defines`, the defines are only added to the compile command line for this target. |
+| `malloc` | [Label](/versions/9.1.0/concepts/labels); default is `"@bazel_tools//tools/cpp:malloc"` Override the default dependency on malloc. By default, C++ binaries are linked against `//tools/cpp:malloc`, which is an empty library so the binary ends up using libc malloc. This label must refer to a `cc_library`. If compilation is for a non-C++ rule, this option has no effect. The value of this attribute is ignored if `linkshared=True` is specified. |
+| `module_interfaces` | List of [labels](/versions/9.1.0/concepts/labels); default is `[]` The list of files are regarded as C++20 Modules Interface. C++ Standard has no restriction about module interface file extension  * Clang use cppm * GCC can use any source file extension * MSVC use ixx  The use is guarded by the flag `--experimental_cpp_modules`. |
+| `nocopts` | String; default is `""` Remove matching options from the C++ compilation command. Subject to ["Make" variable](/versions/9.1.0/reference/be/make-variables) substitution. The value of this attribute is interpreted as a regular expression. Any preexisting `COPTS` that match this regular expression (including values explicitly specified in the rule's [copts](#cc_binary.copts) attribute) will be removed from `COPTS` for purposes of compiling this rule. This attribute should not be needed or used outside of `third_party`. The values are not preprocessed in any way other than the "Make" variable substitution. |
+| `reexport_deps` | List of [labels](/versions/9.1.0/concepts/labels); default is `[]` |
+| `stamp` | Integer; default is `0` Whether to encode build information into the binary. Possible values:  * `stamp = 1`: Always stamp the build information into the binary, even in   [`--nostamp`](/versions/9.1.0/docs/user-manual#flag--stamp) builds. **This   setting should be avoided**, since it potentially kills remote caching for the   binary and any downstream actions that depend on it. * `stamp = 0`: Always replace build information by constant values. This   gives good build result caching. * `stamp = -1`: Embedding of build information is controlled by the   [`--[no]stamp`](/versions/9.1.0/docs/user-manual#flag--stamp) flag.   Stamped binaries are *not* rebuilt unless their dependencies change. |
+| `win_def_file` | [Label](/versions/9.1.0/concepts/labels); default is `None` The Windows DEF file to be passed to linker. This attribute should only be used when Windows is the target platform. It can be used to [export symbols](https://msdn.microsoft.com/en-us/library/d91k01sh.aspx) during linking a shared library. |
+
+## cc_toolchain
+
+[View rule sourceopen_in_new](https://github.com/bazelbuild/rules_cc/blob/master/cc/private/rules_impl/cc_toolchain.bzl)
+
+```
+cc_toolchain(name, all_files, ar_files, as_files, aspect_hints, compatible_with, compiler_files, compiler_files_without_includes, coverage_files, deprecation, dwp_files, dynamic_runtime_lib, exec_compatible_with, exec_group_compatible_with, exec_properties, exec_transition_for_inputs, features, libc_top, licenses, linker_files, module_map, objcopy_files, output_licenses, package_metadata, restricted_to, static_runtime_lib, strip_files, supports_header_parsing, supports_param_files, tags, target_compatible_with, testonly, toolchain_config, toolchain_identifier, toolchains, visibility)
+```
+
+Represents a C++ toolchain.
+
+This rule is responsible for:
+
+* Collecting all artifacts needed for C++ actions to run. This is done by
+  attributes such as `all_files`, `compiler_files`,
+  `linker_files`, or other attributes ending with `_files`). These are
+  most commonly filegroups globbing all required files.
+* Generating correct command lines for C++ actions. This is done using
+  `CcToolchainConfigInfo` provider (details below).
+
+Use `toolchain_config` attribute to configure the C++ toolchain.
+See also this
+[page](https://bazel.build/versions/9.1.0/docs/cc-toolchain-config-reference) for elaborate C++ toolchain configuration and toolchain selection documentation.
+
+Use `tags = ["manual"]` in order to prevent toolchains from being built and configured
+unnecessarily when invoking `bazel build //...`
+
+### Arguments
+
+| Attributes | |
+| --- | --- |
+| `name` | [Name](/versions/9.1.0/concepts/labels#target-names); required  A unique name for this target. |
+| `all_files` | [Label](/versions/9.1.0/concepts/labels); required Collection of all cc_toolchain artifacts. These artifacts will be added as inputs to all rules_cc related actions (with the exception of actions that are using more precise sets of artifacts from attributes below). Bazel assumes that `all_files` is a superset of all other artifact-providing attributes (e.g. linkstamp compilation needs both compile and link files, so it takes `all_files`). This is what `cc_toolchain.files` contains, and this is used by all Starlark rules using C++ toolchain. |
+| `ar_files` | [Label](/versions/9.1.0/concepts/labels); default is `None` Collection of all cc_toolchain artifacts required for archiving actions. |
+| `as_files` | [Label](/versions/9.1.0/concepts/labels); default is `None` Collection of all cc_toolchain artifacts required for assembly actions. |
+| `compiler_files` | [Label](/versions/9.1.0/concepts/labels); required Collection of all cc_toolchain artifacts required for compile actions. |
+| `compiler_files_without_includes` | [Label](/versions/9.1.0/concepts/labels); default is `None` Collection of all cc_toolchain artifacts required for compile actions in case when input discovery is supported (currently Google-only). |
+| `coverage_files` | [Label](/versions/9.1.0/concepts/labels); default is `None` Collection of all cc_toolchain artifacts required for coverage actions. If not specified, all_files are used. |
+| `dwp_files` | [Label](/versions/9.1.0/concepts/labels); required Collection of all cc_toolchain artifacts required for dwp actions. |
+| `dynamic_runtime_lib` | [Label](/versions/9.1.0/concepts/labels); default is `None` Dynamic library artifact for the C++ runtime library (e.g. libstdc++.so). This will be used when 'static_link_cpp_runtimes' feature is enabled, and we're linking dependencies dynamically. |
+| `exec_transition_for_inputs` | Boolean; default is `False` Deprecated. No-op. |
+| `libc_top` | [Label](/versions/9.1.0/concepts/labels); default is `None` A collection of artifacts for libc passed as inputs to compile/linking actions. |
+| `linker_files` | [Label](/versions/9.1.0/concepts/labels); required Collection of all cc_toolchain artifacts required for linking actions. |
+| `module_map` | [Label](/versions/9.1.0/concepts/labels); default is `None` Module map artifact to be used for modular builds. |
+| `objcopy_files` | [Label](/versions/9.1.0/concepts/labels); required Collection of all cc_toolchain artifacts required for objcopy actions. |
+| `output_licenses` | List of strings; default is `[]` |
+| `static_runtime_lib` | [Label](/versions/9.1.0/concepts/labels); default is `None` Static library artifact for the C++ runtime library (e.g. libstdc++.a). This will be used when 'static_link_cpp_runtimes' feature is enabled, and we're linking dependencies statically. |
+| `strip_files` | [Label](/versions/9.1.0/concepts/labels); required Collection of all cc_toolchain artifacts required for strip actions. |
+| `supports_header_parsing` | Boolean; default is `False` Set to True when cc_toolchain supports header parsing actions. |
+| `supports_param_files` | Boolean; default is `True` Set to True when cc_toolchain supports using param files for linking actions. |
+| `toolchain_config` | [Label](/versions/9.1.0/concepts/labels); required The label of the rule providing `cc_toolchain_config_info`. |
+| `toolchain_identifier` | String; default is `""` The identifier used to match this cc_toolchain with the corresponding crosstool_config.toolchain. Until issue [#5380](https://github.com/bazelbuild/bazel/issues/5380) is fixed this is the recommended way of associating `cc_toolchain` with `CROSSTOOL.toolchain`. It will be replaced by the `toolchain_config` attribute ([#5380](https://github.com/bazelbuild/bazel/issues/5380)). |
+
+## fdo_prefetch_hints
+
+[View rule sourceopen_in_new](https://github.com/bazelbuild/rules_cc/blob/master/cc/private/rules_impl/fdo/fdo_prefetch_hints.bzl)
+
+```
+fdo_prefetch_hints(name, aspect_hints, compatible_with, deprecation, exec_compatible_with, exec_group_compatible_with, exec_properties, features, package_metadata, profile, restricted_to, tags, target_compatible_with, testonly, toolchains, visibility)
+```
+
+Represents an FDO prefetch hints profile that is either in the workspace.
+Examples:
+
+```
+fdo_prefetch_hints(
+    name = "hints",
+    profile = "//path/to/hints:profile.afdo",
+)
+```
+
+### Arguments
+
+| Attributes | |
+| --- | --- |
+| `name` | [Name](/versions/9.1.0/concepts/labels#target-names); required  A unique name for this target. |
+| `profile` | [Label](/versions/9.1.0/concepts/labels); required Label of the hints profile. The hints file has the .afdo extension The label can also point to an fdo_absolute_path_profile rule. |
+
+## fdo_profile
+
+[View rule sourceopen_in_new](https://github.com/bazelbuild/rules_cc/blob/master/cc/private/rules_impl/fdo/fdo_profile.bzl)
+
+```
+fdo_profile(name, aspect_hints, compatible_with, deprecation, exec_compatible_with, exec_group_compatible_with, exec_properties, features, memprof_profile, package_metadata, profile, proto_profile, restricted_to, tags, target_compatible_with, testonly, toolchains, visibility)
+```
+
+Represents an FDO profile that is in the workspace.
+Example:
+
+```
+fdo_profile(
+    name = "fdo",
+    profile = "//path/to/fdo:profile.zip",
+)
+```
+
+### Arguments
+
+| Attributes | |
+| --- | --- |
+| `name` | [Name](/versions/9.1.0/concepts/labels#target-names); required  A unique name for this target. |
+| `memprof_profile` | [Label](/versions/9.1.0/concepts/labels); default is `None` Label of the MemProf profile. The profile is expected to have either a .profdata extension (for an indexed/symbolized memprof profile), or a .zip extension for a zipfile containing a memprof.profdata file. |
+| `profile` | [Label](/versions/9.1.0/concepts/labels); required Label of the FDO profile or a rule which generates it. The FDO file can have one of the following extensions: .profraw for unindexed LLVM profile, .profdata for indexed LLVM profile, .zip that holds an LLVM profraw profile, .afdo for AutoFDO profile, .xfdo for XBinary profile. The label can also point to an fdo_absolute_path_profile rule. |
+| `proto_profile` | [Label](/versions/9.1.0/concepts/labels); default is `None` Label of the protobuf profile. |
+
+## memprof_profile
+
+[View rule sourceopen_in_new](https://github.com/bazelbuild/rules_cc/blob/master/cc/private/rules_impl/fdo/memprof_profile.bzl)
+
+```
+memprof_profile(name, aspect_hints, compatible_with, deprecation, exec_compatible_with, exec_group_compatible_with, exec_properties, features, package_metadata, profile, restricted_to, tags, target_compatible_with, testonly, toolchains, visibility)
+```
+
+Represents a MEMPROF profile that is in the workspace.
+Example:
+
+```
+memprof_profile(
+    name = "memprof",
+    profile = "//path/to/memprof:profile.afdo",
+)
+```
+
+### Arguments
+
+| Attributes | |
+| --- | --- |
+| `name` | [Name](/versions/9.1.0/concepts/labels#target-names); required  A unique name for this target. |
+| `profile` | [Label](/versions/9.1.0/concepts/labels); required Label of the MEMPROF profile. The profile is expected to have either a .profdata extension (for an indexed/symbolized memprof profile), or a .zip extension for a zipfile containing a memprof.profdata file. The label can also point to an fdo_absolute_path_profile rule. |
+
+## propeller_optimize
+
+[View rule sourceopen_in_new](https://github.com/bazelbuild/rules_cc/blob/master/cc/private/rules_impl/fdo/propeller_optimize.bzl)
+
+```
+propeller_optimize(name, aspect_hints, cc_profile, compatible_with, deprecation, exec_compatible_with, exec_group_compatible_with, exec_properties, features, ld_profile, package_metadata, restricted_to, tags, target_compatible_with, testonly, toolchains, visibility)
+```
+
+Represents a Propeller optimization profile in the workspace.
+Example:
+
+```
+propeller_optimize(
+    name = "layout",
+    cc_profile = "//path:cc_profile.txt",
+    ld_profile = "//path:ld_profile.txt"
+)
+```
+
+### Arguments
+
+| Attributes | |
+| --- | --- |
+| `name` | [Name](/versions/9.1.0/concepts/labels#target-names); required  A unique name for this target. |
+| `cc_profile` | [Label](/versions/9.1.0/concepts/labels); required Label of the profile passed to the various compile actions. This file has the .txt extension. |
+| `ld_profile` | [Label](/versions/9.1.0/concepts/labels); required Label of the profile passed to the link action. This file has the .txt extension. |
\ No newline at end of file
diff --git a/versions/9.1.0/reference/be/common-definitions.mdx b/versions/9.1.0/reference/be/common-definitions.mdx
new file mode 100644
index 00000000..487519cb
--- /dev/null
+++ b/versions/9.1.0/reference/be/common-definitions.mdx
@@ -0,0 +1,211 @@
+---
+title: 'Common definitions'
+---
+
+This section defines various terms and concepts that are common to
+many functions or build rules.
+
+## Contents
+
+* [Bourne shell tokenization](#sh-tokenization)
+* [Label Expansion](#label-expansion)
+* [Typical attributes defined by most build rules](#typical-attributes)
+* [Attributes common to all build rules](#common-attributes)
+* [Attributes common to all test rules (\*\_test)](#common-attributes-tests)
+* [Attributes common to all binary rules (\*\_binary)](#common-attributes-binaries)
+* [Configurable attributes](#configurable-attributes)
+* [Implicit output targets](#implicit-outputs)
+
+## Bourne shell tokenization
+
+Certain string attributes of some rules are split into multiple
+words according to the tokenization rules of the Bourne shell:
+unquoted spaces delimit separate words, and single- and
+double-quotes characters and backslashes are used to prevent
+tokenization.
+
+Those attributes that are subject to this tokenization are
+explicitly indicated as such in their definitions in this document.
+
+Attributes subject to "Make" variable expansion and Bourne shell
+tokenization are typically used for passing arbitrary options to
+compilers and other tools. Examples of such attributes are
+`cc_library.copts` and `java_library.javacopts`.
+Together these substitutions allow a
+single string variable to expand into a configuration-specific list
+of option words.
+
+## Label expansion
+
+Some string attributes of a very few rules are subject to label
+expansion: if those strings contain a valid label as a
+substring, such as `//mypkg:target`, and that label is a
+declared prerequisite of the current rule, it is expanded into the
+pathname of the file represented by the
+[target](https://bazel.build/versions/9.1.0/reference/glossary#target)
+`//mypkg:target`.
+
+Example attributes include `genrule.cmd` and
+`cc_binary.linkopts`. The details may vary significantly in
+each case, over such issues as: whether relative labels are
+expanded; how labels that expand to multiple files are
+treated, etc. Consult the rule attribute documentation for
+specifics.
+
+## Typical attributes defined by most build rules
+
+This section describes attributes that are defined by many build rules,
+but not all.
+
+| Attribute | Description |
+| --- | --- |
+| `data` | List of [labels](/versions/9.1.0/concepts/labels); default is `[]`  Files needed by this rule at runtime. May list file or rule targets. Generally allows any target.  The default outputs and runfiles of targets in the `data` attribute should appear in the `*.runfiles` area of any executable which is output by or has a runtime dependency on this target. This may include data files or binaries used when this target's [`srcs`](#typical.srcs) are executed. See the [data dependencies](/versions/9.1.0/concepts/dependencies#data-dependencies) section for more information about how to depend on and use data files.  New rules should define a `data` attribute if they process inputs which might use other inputs at runtime. Rules' implementation functions must also [populate the target's runfiles](https://bazel.build/versions/9.1.0/rules/rules#runfiles) from the outputs and runfiles of any `data` attribute, as well as runfiles from any dependency attribute which provides either source code or runtime dependencies. |
+| `deps` | List of [labels](/versions/9.1.0/concepts/labels); default is `[]`  Dependencies for this target. Generally should only list rule targets. (Though some rules permit files to be listed directly in `deps`, this should be avoided when possible.)  Language-specific rules generally limit the listed targets to those with specific [providers](https://bazel.build/versions/9.1.0/extending/rules#providers).  The precise semantics of what it means for a target to depend on another using `deps` are specific to the kind of rule, and the rule-specific documentation goes into more detail. For rules which process source code, `deps` generally specifies code dependencies used by the code in [`srcs`](#typical.srcs).  Most often, a `deps` dependency is used to allow one module to use symbols defined in another module written in the same programming language and separately compiled. Cross-language dependencies are also permitted in many cases: For example, a `java_library` target may depend on C++ code in a `cc_library` target, by listing the latter in the `deps` attribute. See the definition of [dependencies](/versions/9.1.0/concepts/build-ref#deps) for more information. |
+| `licenses` | List of strings; [nonconfigurable](#configurable-attributes); default is `["none"]`  A list of license-type strings to be used for this particular target. This is part of a deprecated licensing API that Bazel no longer uses. Don't use this. |
+| `srcs` | List of [labels](/versions/9.1.0/concepts/labels); default is `[]`  Files processed or included by this rule. Generally lists files directly, but may list rule targets (like `filegroup` or `genrule`) to include their default outputs.  Language-specific rules often require that the listed files have particular file extensions. |
+
+## Attributes common to all build rules
+
+This section describes attributes that are implicitly added to all build
+rules.
+
+| Attribute | Description |
+| --- | --- |
+| `aspect_hints` | List of [labels](/versions/9.1.0/concepts/labels); default is `[]`  A list of arbitrary labels which is exposed to [aspects](/versions/9.1.0/extending/aspects) (in particular - aspects invoked by this rule's reverse dependencies), but isn't exposed to this rule's own implementation. Consult documentation for language-specific rule sets for details about what effect a particular aspect hint would have.  You could think of an aspect hint as a richer alternative to a [tag](#common.tags): while a tag conveys only a boolean state (the tag is either present or absent in the `tags` list), an aspect hint can convey arbitrary structured information in its [providers](/versions/9.1.0/extending/rules#providers).  In practice, aspect hints are used for interoperability between different language-specific rule sets. For example, imagine you have a `mylang_binary` target which needs to depend on an `otherlang_library` target. The MyLang-specific logic needs some additional information about the OtherLang target in order to use it, but `otherlang_library` doesn't provide this information because it knows nothing about MyLang. One solution might be for the MyLang rule set to define a `mylang_hint` rule which can be used to encode that additional information; the user can add the hint to their `otherlang_library`'s `aspect_hints`, and `mylang_binary` can use an aspect to collect the additional information from a MyLang-specific provider in the `mylang_hint`.  For a concrete example, see [`swift_interop_hint`](https://github.com/bazelbuild/rules_swift/blob/master/doc/rules.md#swift_interop_hint) and [`swift_overlay`](https://github.com/bazelbuild/rules_swift/blob/master/doc/rules.md#swift_overlay) in `rules_swift`.  Best practices:   * Targets listed in `aspect_hints` should be lightweight and minimal. * Language-specific logic should consider only aspect hints having providers relevant to that   language, and should ignore any other aspect hints. |
+| `compatible_with` | List of [labels](/versions/9.1.0/concepts/labels); [nonconfigurable](#configurable-attributes); default is `[]`  The list of environments this target can be built for, in addition to default-supported environments.  This is part of Bazel's constraint system, which lets users declare which targets can and cannot depend on each other. For example, externally deployable binaries shouldn't depend on libraries with company-secret code. See [ConstraintSemantics](https://github.com/bazelbuild/bazel/blob/master/src/main/java/com/google/devtools/build/lib/analysis/constraints/ConstraintSemantics.java#L46) for details. |
+| `deprecation` | String; [nonconfigurable](#configurable-attributes); default is `None`  An explanatory warning message associated with this target. Typically this is used to notify users that a target has become obsolete, or has become superseded by another rule, is private to a package, or is perhaps considered harmful for some reason. It is a good idea to include some reference (like a webpage, a bug number or example migration CLs) so that one can easily find out what changes are required to avoid the message. If there is a new target that can be used as a drop in replacement, it is a good idea to just migrate all users of the old target.  This attribute has no effect on the way things are built, but it may affect a build tool's diagnostic output. The build tool issues a warning when a rule with a `deprecation` attribute is depended upon by a target in another package.  Intra-package dependencies are exempt from this warning, so that, for example, building the tests of a deprecated rule does not encounter a warning.  If a deprecated target depends on another deprecated target, no warning message is issued.  Once people have stopped using it, the target can be removed. |
+| `exec_compatible_with` | List of [labels](/versions/9.1.0/concepts/labels); [nonconfigurable](#configurable-attributes); default is `[]`  A list of `constraint_values` that must be present in the execution platform of this target's default exec group. This is in addition to any constraints already set by the rule type. Constraints are used to restrict the list of available execution platforms. For more details, see the description of [toolchain resolution](/versions/9.1.0/docs/toolchains#toolchain-resolution). and [exec groups](/versions/9.1.0/extending/exec-groups) |
+| `exec_group_compatible_with` | Dictionary of strings to lists of [labels](/versions/9.1.0/concepts/labels); [nonconfigurable](#configurable-attributes); default is `{}`  A dictionary of exec group names to lists of `constraint_values` that must be present in the execution platform for the given exec group. This is in addition to any constraints already set on the exec group's definition. Constraints are used to restrict the list of available execution platforms. For more details, see the description of [toolchain resolution](/versions/9.1.0/docs/toolchains#toolchain-resolution). and [exec groups](/versions/9.1.0/extending/exec-groups) |
+| `exec_properties` | Dictionary of strings; default is `{}`  A dictionary of strings that will be added to the `exec_properties` of a platform selected for this target. See `exec_properties` of the [platform](/versions/9.1.0/reference/be/platforms-and-toolchains#platform) rule.  If a key is present in both the platform and target-level properties, the value will be taken from the target.  Keys can be prefixed with the name of an execution group followed by a `.` to apply them only to that particular exec group. |
+| `features` | List of *feature* strings; default is `[]`  A feature is string tag that can be enabled or disabled on a target. The meaning of a feature depends on the rule itself.  This `features` attribute is combined with the [package](/versions/9.1.0/reference/be/functions#package) level `features` attribute. For example, if the features ["a", "b"] are enabled on the package level, and a target's `features` attribute contains ["-a", "c"], the features enabled for the rule will be "b" and "c". [See example](https://github.com/bazelbuild/examples/blob/main/rules/features/BUILD). |
+| `package_metadata` | List of [labels](/versions/9.1.0/concepts/labels); [nonconfigurable](#configurable-attributes); default is the package's `default_package_metadata`  A list of labels that are associated metadata about this target. Typically, the labels are simple rules that return a provider of constant values. Rules and aspects may use these labels to perform some additional analysis on the build graph.  The canonical use case is that of [rules_license](https://github.com/bazelbuild/rules_license). For that use case, `package_metadata` and `default_package_metadata` is used to attach information about a package's licence or version to targets. An aspect applied to a top-level binary can be used to gather those and produce compliance reports. |
+| `restricted_to` | List of [labels](/versions/9.1.0/concepts/labels); [nonconfigurable](#configurable-attributes); default is `[]`  The list of environments this target can be built for, *instead* of default-supported environments.  This is part of Bazel's constraint system. See `compatible_with` for details. |
+| `tags` | List of strings; [nonconfigurable](#configurable-attributes); default is `[]`  *Tags* can be used on any rule. *Tags* on test and `test_suite` rules are useful for categorizing the tests. *Tags* on non-test targets are used to control sandboxed execution of `genrule`s and [Starlark](/versions/9.1.0/rules/concepts) actions, and for parsing by humans and/or external tools.  Bazel modifies the behavior of its sandboxing code if it finds the following keywords in the `tags` attribute of any test or `genrule` target, or the keys of `execution_requirements` for any Starlark action.   * `no-sandbox` keyword results in the action or test never being   sandboxed; it can still be cached or run remotely - use `no-cache`   or `no-remote` to prevent either or both of those. * `no-cache` keyword results in the action or test never being   cached (locally or remotely). Note: for the purposes of this tag, the disk cache   is considered a local cache, whereas the HTTP and gRPC caches are considered   remote. Other caches, such as Skyframe or the persistent action cache, are not   affected. * `no-remote-cache` keyword results in the action or test never being   cached remotely (but it may be cached locally; it may also be executed remotely).   Note: for the purposes of this tag, the disk cache is considered a local cache,   whereas the HTTP and gRPC caches are considered remote. Other caches, such as   Skyframe or the persistent action cache, are not affected.   If a combination of local disk cache and remote cache are used (combined cache),   it's treated as a remote cache and disabled entirely unless `--incompatible_remote_results_ignore_disk`   is set in which case the local components will be used. * `no-remote-exec` keyword results in the action or test never being   executed remotely (but it may be cached remotely). * `no-remote` keyword prevents the action or test from being executed remotely or   cached remotely. This is equivalent to using both   `no-remote-cache` and `no-remote-exec`. * `no-remote-cache-upload` keyword disables upload part of remote caching of a spawn.   it does not disable remote execution. * `local` keyword precludes the action or test from being remotely cached,   remotely executed, or run inside the sandbox.   For genrules and tests, marking the rule with the `local = True`   attribute has the same effect. * `requires-network` keyword allows access to the external   network from inside the sandbox. This tag only has an effect if sandboxing   is enabled. * `block-network` keyword blocks access to the external   network from inside the sandbox. In this case, only communication   with localhost is allowed. This tag only has an effect if sandboxing is   enabled. * `requires-fakeroot` runs the test or action as uid and gid 0 (i.e., the root   user). This is only supported on Linux. This tag takes precedence over the   `--sandbox_fake_username` command-line option.   *Tags* on tests are generally used to annotate a test's role in your debug and release process. Typically, tags are most useful for C++ and Python tests, which lack any runtime annotation ability. The use of tags and size elements gives flexibility in assembling suites of tests based around codebase check-in policy.  Bazel modifies test running behavior if it finds the following keywords in the `tags` attribute of the test rule:   * `exclusive` will force the test to be run in the   "exclusive" mode, ensuring that no other tests are running at the   same time. Such tests will be executed in serial fashion after all build   activity and non-exclusive tests have been completed. Remote execution is   disabled for such tests because Bazel doesn't have control over what's   running on a remote machine. * `exclusive-if-local` will force the test to be run in the   "exclusive" mode if it is executed locally, but will run the test in parallel if it's   executed remotely. * `manual` keyword will exclude the target from expansion of target pattern wildcards   (`...`, `:*`, `:all`, etc.) and `test_suite` rules   which do not list the test explicitly when computing the set of top-level targets to build/run   for the `build`, `test`, and `coverage` commands. It does not   affect target wildcard or test suite expansion in other contexts, including the   `query` command. Note that `manual` does not imply that a target should   not be built/run automatically by continuous build/test systems. For example, it may be   desirable to exclude a target from `bazel test ...` because it requires specific   Bazel flags, but still have it included in properly-configured presubmit or continuous test   runs. * `external` keyword will force test to be unconditionally   executed (regardless of `--cache_test_results`   value).  See [Tag Conventions](/versions/9.1.0/reference/test-encyclopedia#tag-conventions) in the Test Encyclopedia for more conventions on tags attached to test targets. |
+| `target_compatible_with` | List of [labels](/versions/9.1.0/concepts/labels); default is `[]`  A list of `constraint_value`s that must be present in the target platform for this target to be considered *compatible*. This is in addition to any constraints already set by the rule type. If the target platform does not satisfy all listed constraints then the target is considered *incompatible*. Incompatible targets are skipped for building and testing when the target pattern is expanded (e.g. `//...`, `:all`). When explicitly specified on the command line, incompatible targets cause Bazel to print an error and cause a build or test failure.  Targets that transitively depend on incompatible targets are themselves considered incompatible. They are also skipped for building and testing.  An empty list (which is the default) signifies that the target is compatible with all platforms. All rules other than [Workspace Rules](/versions/9.1.0/reference/be/workspace) support this attribute. For some rules this attribute has no effect. For example, specifying `target_compatible_with` for a `cc_toolchain` is not useful. See the [Platforms](/versions/9.1.0/docs/platforms#skipping-incompatible-targets) page for more information about incompatible target skipping. |
+| `testonly` | Boolean; [nonconfigurable](#configurable-attributes); default is `False` except for test and test suite targets  If `True`, only testonly targets (such as tests) can depend on this target.  Equivalently, a rule that is not `testonly` is not allowed to depend on any rule that is `testonly`.  Tests (`*_test` rules) and test suites ([test_suite](/versions/9.1.0/reference/be/general#test_suite) rules) are `testonly` by default.  This attribute is intended to mean that the target should not be contained in binaries that are released to production.  Because testonly is enforced at build time, not run time, and propagates virally through the dependency tree, it should be applied judiciously. For example, stubs and fakes that are useful for unit tests may also be useful for integration tests involving the same binaries that will be released to production, and therefore should probably not be marked testonly. Conversely, rules that are dangerous to even link in, perhaps because they unconditionally override normal behavior, should definitely be marked testonly. |
+| `toolchains` | List of [labels](/versions/9.1.0/concepts/labels); [nonconfigurable](#configurable-attributes); default is `[]`  The set of targets whose [Make variables](/versions/9.1.0/reference/be/make-variables) this target is allowed to access. These targets are either instances of rules that provide `TemplateVariableInfo` or special targets for toolchain types built into Bazel. These include:  * `@bazel_tools//tools/cpp:toolchain_type`* `@rules_java//toolchains:current_java_runtime`   Note that this is distinct from the concept of [toolchain resolution](/versions/9.1.0/docs/toolchains#toolchain-resolution) that is used by rule implementations for platform-dependent configuration. You cannot use this attribute to determine which specific `cc_toolchain` or `java_toolchain` a target will use. |
+| `visibility` | List of [labels](/versions/9.1.0/concepts/labels); [nonconfigurable](#configurable-attributes); default varies  The `visibility` attribute controls whether the target can be depended on by targets in other locations. See the documentation for [visibility](/versions/9.1.0/concepts/visibility).  For targets declared directly in a BUILD file or in legacy macros called from a BUILD file, the default value is the package's `default_visibility` if specified, or else `["//visibility:private"]`. For targets declared in one or more symbolic macros, the default value is always just `["//visibility:private"]` (which makes it useable only within the package containing the macro's code). |
+
+## Attributes common to all test rules (\*\_test)
+
+This section describes attributes that are common to all test rules.
+
+| Attribute | Description |
+| --- | --- |
+| `args` | List of strings; subject to [$(location)](/versions/9.1.0/reference/be/make-variables#predefined_label_variables) and ["Make variable"](/versions/9.1.0/reference/be/make-variables) substitution, and [Bourne shell tokenization](#sh-tokenization); default is `[]`  Command line arguments that Bazel passes to the target when it is executed with `bazel test`. These arguments are passed before any `--test_arg` values specified on the `bazel test` command line. |
+| `env` | Dictionary of strings; values are subject to [$(location)](/versions/9.1.0/reference/be/make-variables#predefined_label_variables) and ["Make variable"](/versions/9.1.0/reference/be/make-variables) substitution; default is `{}`  Specifies additional environment variables to set when the test is executed by `bazel test`.  This attribute only applies to native rules, like `cc_test`, `py_test`, and `sh_test`. It does not apply to Starlark-defined test rules. For your own Starlark rules, you can add an "env" attribute and use it to populate a [RunEnvironmentInfo](/versions/9.1.0/rules/lib/providers/RunEnvironmentInfo) Provider. [TestEnvironment](/versions/9.1.0/rules/lib/toplevel/testing#TestEnvironment) Provider. |
+| `env_inherit` | List of strings; default is `[]`  Specifies additional environment variables to inherit from the external environment when the test is executed by `bazel test`.  This attribute only applies to native rules, like `cc_test`, `py_test`, and `sh_test`. It does not apply to Starlark-defined test rules. |
+| `size` | String `"enormous"`, `"large"`, `"medium"`, or `"small"`; [nonconfigurable](#configurable-attributes); default is `"medium"`  Specifies a test target's "heaviness": how much time/resources it needs to run.  Unit tests are considered "small", integration tests "medium", and end-to-end tests "large" or "enormous". Bazel uses the size to determine a default timeout, which can be overridden using the `timeout` attribute. The timeout is for all tests in the BUILD target, not for each individual test. When the test is run locally, the `size` is additionally used for scheduling purposes: Bazel tries to respect `--local_{ram,cpu}_resources` and not overwhelm the local machine by running lots of heavy tests at the same time.  Test sizes correspond to the following default timeouts and assumed peak local resource usages:   | Size | RAM (in MB) | CPU (in CPU cores) | Default timeout | | --- | --- | --- | --- | | small | 20 | 1 | short (1 minute) | | medium | 100 | 1 | moderate (5 minutes) | | large | 300 | 1 | long (15 minutes) | | enormous | 800 | 1 | eternal (60 minutes) |   The environment variable `TEST_SIZE` will be set to the value of this attribute when spawning the test. |
+| `timeout` | String `"short"`, `"moderate"`, `"long"`, or `"eternal"`; [nonconfigurable](#configurable-attributes); default is derived from the test's `size` attribute  How long the test is expected to run before returning.  While a test's size attribute controls resource estimation, a test's timeout may be set independently. If not explicitly specified, the timeout is based on the [test's size](#test.size). The test timeout can be overridden with the `--test_timeout` flag, e.g. for running under certain conditions which are known to be slow. Test timeout values correspond to the following time periods:   | Timeout Value | Time Period | | --- | --- | | short | 1 minute | | moderate | 5 minutes | | long | 15 minutes | | eternal | 60 minutes |   For times other than the above, the test timeout can be overridden with the `--test_timeout` bazel flag, e.g. for manually running under conditions which are known to be slow. The `--test_timeout` values are in seconds. For example `--test_timeout=120` will set the test timeout to two minutes.  The environment variable `TEST_TIMEOUT` will be set to the test timeout (in seconds) when spawning the test. |
+| `flaky` | Boolean; [nonconfigurable](#configurable-attributes); default is `False`  Marks test as flaky.  If set, executes the test up to three times, marking it as failed only if it fails each time. By default, this attribute is set to False and the test is executed only once. Note, that use of this attribute is generally discouraged - tests should pass reliably when their assertions are upheld. |
+| `shard_count` | Non-negative integer less than or equal to 50; default is `-1`  Specifies the number of parallel shards to use to run the test.  If set, this value will override any heuristics used to determine the number of parallel shards with which to run the test. Note that for some test rules, this parameter may be required to enable sharding in the first place. Also see `--test_sharding_strategy`.  If test sharding is enabled, the environment variable `TEST_TOTAL_SHARDS` will be set to this value when spawning the test.  Sharding requires the test runner to support the test sharding protocol. If it does not, then it will most likely run every test in every shard, which is not what you want.  See [Test Sharding](/versions/9.1.0/reference/test-encyclopedia#test-sharding) in the Test Encyclopedia for details on sharding. |
+| `local` | Boolean; [nonconfigurable](#configurable-attributes); default is `False`  Forces the test to be run locally, without sandboxing.  Setting this to True is equivalent to providing "local" as a tag (`tags=["local"]`). |
+
+## Attributes common to all binary rules (\*\_binary)
+
+This section describes attributes that are common to all binary rules.
+
+| Attribute | Description |
+| --- | --- |
+| `args` | List of strings; subject to [$(location)](/versions/9.1.0/reference/be/make-variables#predefined_label_variables) and ["Make variable"](/versions/9.1.0/reference/be/make-variables) substitution, and [Bourne shell tokenization](#sh-tokenization); [nonconfigurable](#configurable-attributes); default is `[]`  Command line arguments that Bazel will pass to the target when it is executed either by the `run` command or as a test. These arguments are passed before the ones that are specified on the `bazel run` or `bazel test` command line.  *NOTE: The arguments are not passed when you run the target outside of Bazel (for example, by manually executing the binary in `bazel-bin/`).* |
+| `env` | Dictionary of strings; values are subject to [$(location)](/versions/9.1.0/reference/be/make-variables#predefined_label_variables) and ["Make variable"](/versions/9.1.0/reference/be/make-variables) substitution; default is `{}`  Specifies additional environment variables to set when the target is executed by `bazel run`.  This attribute only applies to native rules, like `cc_binary`, `py_binary`, and `sh_binary`. It does not apply to Starlark-defined executable rules. For your own Starlark rules, you can add an "env" attribute and use it to populate a [RunEnvironmentInfo](/versions/9.1.0/rules/lib/providers/RunEnvironmentInfo) Provider.  *NOTE: The environment variables are not set when you run the target outside of Bazel (for example, by manually executing the binary in `bazel-bin/`).* |
+| `output_licenses` | List of strings; default is `[]`  The licenses of the output files that this binary generates. This is part of a deprecated licensing API that Bazel no longer uses. Don't use this. |
+
+## Configurable attributes
+
+Most attributes are "configurable", meaning that their values may change when
+the target is built in different ways. Specifically, configurable attributes
+may vary based on the flags passed to the Bazel command line, or what
+downstream dependency is requesting the target. This can be used, for
+instance, to customize the target for multiple platforms or compilation modes.
+
+The following example declares different sources for different target
+architectures. Running `bazel build :multiplatform_lib --cpu x86`
+will build the target using `x86_impl.cc`, while substituting
+`--cpu arm` will instead cause it to use `arm_impl.cc`.
+
+```
+cc_library(
+    name = "multiplatform_lib",
+    srcs = select({
+        ":x86_mode": ["x86_impl.cc"],
+        ":arm_mode": ["arm_impl.cc"]
+    })
+)
+config_setting(
+    name = "x86_mode",
+    values = { "cpu": "x86" }
+)
+config_setting(
+    name = "arm_mode",
+    values = { "cpu": "arm" }
+)
+```
+
+The [`select()`](/versions/9.1.0/reference/be/functions#select) function
+chooses among different alternative values for a configurable attribute based
+on which [`config_setting`](/versions/9.1.0/reference/be/general#config_setting)
+or [`constraint_value`](/versions/9.1.0/reference/be/platforms-and-toolchains#constraint_value)
+criteria the target's configuration satisfies.
+
+Bazel evaluates configurable attributes after processing macros and before
+processing rules (technically, between the
+[loading and analysis phases](https://bazel.build/versions/9.1.0/rules/concepts#evaluation-model)).
+Any processing before `select()` evaluation doesn't know which
+branch the `select()` chooses. Macros, for example, can't change
+their behavior based on the chosen branch, and `bazel query` can
+only make conservative guesses about a target's configurable dependencies. See
+[this FAQ](https://bazel.build/versions/9.1.0/docs/configurable-attributes#faq)
+for more on using `select()` with rules and macros.
+
+Attributes marked `nonconfigurable` in their documentation cannot
+use this feature. Usually an attribute is nonconfigurable because Bazel
+internally needs to know its value before it can determine how to resolve a
+`select()`.
+
+See [Configurable Build Attributes](https://bazel.build/versions/9.1.0/docs/configurable-attributes) for a detailed overview.
+
+## Implicit output targets
+
+*Implicit outputs in C++ are deprecated. Please refrain from using it
+in other languages where possible. We don't have a deprecation path yet
+but they will eventually be deprecated too.*
+
+When you define a build rule in a BUILD file, you are explicitly
+declaring a new, named rule target in a package. Many build rule
+functions also *implicitly* entail one or more output file
+targets, whose contents and meaning are rule-specific.
+For example, when you explicitly declare a
+`java_binary(name='foo', ...)` rule, you are also
+*implicitly* declaring an output file
+target `foo_deploy.jar` as a member of the same package.
+(This particular target is a self-contained Java archive suitable
+for deployment.)
+
+Implicit output targets are first-class members of the global
+target graph. Just like other targets, they are built on demand,
+either when specified in the top-level built command, or when they
+are necessary prerequisites for other build targets. They can be
+referenced as dependencies in BUILD files, and can be observed in
+the output of analysis tools such as `bazel query`.
+
+For each kind of build rule, the rule's documentation contains a
+special section detailing the names and contents of any implicit
+outputs entailed by a declaration of that kind of rule.
+
+An important but somewhat subtle distinction between the
+two namespaces used by the build system:
+[labels](/versions/9.1.0/concepts/labels) identify *targets*,
+which may be rules or files, and file targets may be divided into
+either source (or input) file targets and derived (or output) file
+targets. These are the things you can mention in BUILD files,
+build from the command-line, or examine using `bazel query`;
+this is the *target namespace*. Each file target corresponds
+to one actual file on disk (the "file system namespace"); each rule
+target may correspond to zero, one or more actual files on disk.
+There may be files on disk that have no corresponding target; for
+example, `.o` object files produced during C++ compilation
+cannot be referenced from within BUILD files or from the command line.
+In this way, the build tool may hide certain implementation details of
+how it does its job. This is explained more fully in
+the [BUILD Concept Reference](/versions/9.1.0/concepts/build-ref).
\ No newline at end of file
diff --git a/versions/9.1.0/reference/be/extra-actions.mdx b/versions/9.1.0/reference/be/extra-actions.mdx
new file mode 100644
index 00000000..3107eb69
--- /dev/null
+++ b/versions/9.1.0/reference/be/extra-actions.mdx
@@ -0,0 +1,106 @@
+---
+title: 'Extra Actions Rules'
+---
+
+## Rules
+
+* [action_listener](#action_listener)
+* [extra_action](#extra_action)
+
+## action_listener
+
+[View rule sourceopen_in_new](https://github.com/bazelbuild/bazel/blob/master/src/main/java/com/google/devtools/build/lib/rules/extra/ActionListenerRule.java)
+
+```
+action_listener(name, aspect_hints, compatible_with, deprecation, exec_compatible_with, exec_group_compatible_with, exec_properties, extra_actions, features, licenses, mnemonics, package_metadata, restricted_to, tags, target_compatible_with, testonly, visibility)
+```
+
+**WARNING:** Extra actions are deprecated. Use
+[aspects](https://bazel.build/versions/9.1.0/rules/aspects)
+instead.
+
+An `action_listener` rule doesn't produce any output itself.
+Instead, it allows tool developers to insert
+[`extra_action`](/versions/9.1.0/reference/be/extra-actions#extra_action)s into the build system,
+by providing a mapping from action to [`extra_action`](/versions/9.1.0/reference/be/extra-actions#extra_action).
+
+This rule's arguments map action mnemonics to
+[`extra_action`](/versions/9.1.0/reference/be/extra-actions#extra_action) rules.
+
+By specifying the option [`--experimental_action_listener=<label>`](/versions/9.1.0/docs/user-manual#flag--experimental_action_listener),
+the build will use the specified `action_listener` to insert
+[`extra_action`](/versions/9.1.0/reference/be/extra-actions#extra_action)s into the build graph.
+
+#### Example
+
+```
+action_listener(
+    name = "index_all_languages",
+    mnemonics = [
+        "Javac",
+        "CppCompile",
+        "Python",
+    ],
+    extra_actions = [":indexer"],
+)
+
+action_listener(
+    name = "index_java",
+    mnemonics = ["Javac"],
+    extra_actions = [":indexer"],
+)
+
+extra_action(
+    name = "indexer",
+    tools = ["//my/tools:indexer"],
+    cmd = "$(location //my/tools:indexer)" +
+          "--extra_action_file=$(EXTRA_ACTION_FILE)",
+)
+```
+
+### Arguments
+
+| Attributes | |
+| --- | --- |
+| `name` | [Name](/versions/9.1.0/concepts/labels#target-names); required  A unique name for this target. |
+| `extra_actions` | List of [labels](/versions/9.1.0/concepts/labels); required A list of `extra_action` targets this `action_listener` should add to the build graph. E.g. `[ "//my/tools:analyzer" ]`. |
+| `mnemonics` | List of strings; required A list of action mnemonics this `action_listener` should listen for, e.g. `[ "Javac" ]`. Mnemonics are not a public interface. There's no guarantee that the mnemonics and their actions don't change. |
+
+## extra_action
+
+[View rule sourceopen_in_new](https://github.com/bazelbuild/bazel/blob/master/src/main/java/com/google/devtools/build/lib/rules/extra/ExtraActionRule.java)
+
+```
+extra_action(name, data, aspect_hints, cmd, compatible_with, deprecation, exec_compatible_with, exec_group_compatible_with, exec_properties, features, licenses, out_templates, package_metadata, requires_action_output, restricted_to, tags, target_compatible_with, testonly, toolchains, tools, visibility)
+```
+
+**WARNING:** Extra actions are deprecated. Use
+[aspects](https://bazel.build/versions/9.1.0/rules/aspects)
+instead.
+
+An `extra_action` rule doesn't produce any meaningful output
+when specified as a regular build target. Instead, it allows tool developers
+to insert additional actions into the build graph that shadow existing actions.
+
+See [`action_listener`](/versions/9.1.0/reference/be/extra-actions#action_listener) for details
+on how to enable `extra_action`s.
+
+The `extra_action`s run as a command-line. The command-line tool gets
+access to a file containing a protocol buffer as $(EXTRA_ACTION_FILE)
+with detailed information on the original action it is shadowing.
+It also has access to all the input files the original action has access to.
+See extra_actions_base.proto
+for details on the data stored inside the protocol buffer. Each proto file
+contains an ExtraActionInfo message.
+
+Just like all other actions, extra actions are sandboxed, and should be designed to handle that.
+
+### Arguments
+
+| Attributes | |
+| --- | --- |
+| `name` | [Name](/versions/9.1.0/concepts/labels#target-names); required  A unique name for this target. You may refer to this rule by `label` in the `extra_actions` argument of  [`action_listener`](/versions/9.1.0/reference/be/extra-actions#action_listener) rules. |
+| `cmd` | String; required The command to run. Like [genrule cmd attribute](/versions/9.1.0/reference/be/general#genrule.cmd) with the following differences:   1. No heuristic label expansion. Only labels using $(location ...) are expanded. 2. An additional pass is applied to the string to replace all    occurrences of the outputs created from the `out_templates`    attribute. All occurrences of `$(output out_template)`    are replaced with the path to the file denoted by `label`.  E.g. out_template `$(ACTION_ID).analysis`    can be matched with `$(output $(ACTION_ID).analysis)`.  In effect, this is the same substitution as `$(location)`    but with a different scope. |
+| `out_templates` | List of strings; default is `[]` A list of templates for files generated by the `extra_action` command. The template can use the following variables:  * $(ACTION_ID), an id uniquely identifying this `extra_action`.   Used to generate a unique output file. |
+| `requires_action_output` | Boolean; default is `False` Indicates this `extra_action` requires the output of the original action to be present as input to this `extra_action`. When true (default false), the extra_action can assume that the original action outputs are available as part of its inputs. |
+| `tools` | List of [labels](/versions/9.1.0/concepts/labels); default is `[]` A list of `tool` dependencies for this rule. See the definition of [dependencies](/versions/9.1.0/concepts/build-ref#deps) for more information.  The build system ensures these prerequisites are built before running the `extra_action` command; they are built using the [`exec`configuration](/versions/9.1.0/docs/user-manual#configurations), since they must run as a tool during the build itself. The path of an individual `tools` target `//x:y` can be obtained using `$(location //x:y)`.  All tools and their data dependencies are consolidated into a single tree within which the command can use relative paths. The working directory will be the root of that unified tree. |
\ No newline at end of file
diff --git a/versions/9.1.0/reference/be/functions.mdx b/versions/9.1.0/reference/be/functions.mdx
new file mode 100644
index 00000000..7d884c39
--- /dev/null
+++ b/versions/9.1.0/reference/be/functions.mdx
@@ -0,0 +1,532 @@
+---
+title: 'Functions'
+---
+
+## Contents
+
+* [package](#package)
+* [package_group](#package_group)
+* [exports_files](#exports_files)
+* [glob](#glob)
+* [select](#select)
+* [subpackages](#subpackages)
+
+## package
+
+```
+package(default_deprecation, default_package_metadata, default_testonly, default_visibility, features)
+```
+
+This function declares metadata that applies to every rule in the
+package. It is used at most once within a package (BUILD file).
+
+For the counterpart that declares metadata applying to every rule in the whole
+*repository*, use the `repo()` function in the
+[`REPO.bazel` file](/versions/9.1.0/external/overview#repo.bazel) at the root of your repo.
+The `repo()` function takes exactly the same arguments as `package()`.
+
+The package() function should be called right after all the load() statements at the top of the
+file, before any rule.
+
+### Arguments
+
+| Attribute | Description |
+| --- | --- |
+| `default_applicable_licenses` | Alias for [`default_package_metadata`](#package.default_package_metadata). |
+| `default_visibility` | List of [labels](/versions/9.1.0/concepts/labels); default is `[]`  The default visibility of the top-level rule targets and symbolic macros in this package — that is, the targets and symbolic macros that are not themselves declared inside a symbolic macro. This attribute is ignored if the target or macro specifies a `visibility` value.  For detailed information about the syntax of this attribute, see the documentation of [visibility](/versions/9.1.0/concepts/visibility). The package default visibility does not apply to [exports_files](#exports_files), which is public by default. |
+| `default_deprecation` | String; default is `""`  Sets the default [`deprecation`](/versions/9.1.0/reference/be/common-definitions#common.deprecation) message for all rules in this package. |
+| `default_package_metadata` | List of [labels](/versions/9.1.0/concepts/labels); default is `[]`  Sets a default list of metadata targets which apply to all other targets in the package. These are typically targets related to OSS package and license declarations. See [rules_license](https://github.com/bazelbuild/rules_license) for examples. |
+| `default_testonly` | Boolean; default is `False` except as noted  Sets the default [`testonly`](/versions/9.1.0/reference/be/common-definitions#common.testonly) property for all rules in this package.  In packages under `javatests` the default value is `True`. |
+| `features` | List strings; default is `[]`  Sets various flags that affect the semantics of this BUILD file.  This feature is mainly used by the people working on the build system to tag packages that need some kind of special handling. Do not use this unless explicitly requested by someone working on the build system. |
+
+### Examples
+
+The declaration below declares that the rules in this package are
+visible only to members of package
+group `//foo:target`. Individual visibility declarations
+on a rule, if present, override this specification.
+
+```
+package(default_visibility = ["//foo:target"])
+```
+
+## package_group
+
+```
+package_group(name, packages, includes)
+```
+
+This function defines a set of [packages](/versions/9.1.0/concepts/build-ref#packages)
+and associates a label with the set. The label can be referenced in
+`visibility` attributes.
+
+Package groups are primarily used for visibility control. A publicly visible
+target can be referenced from every package in the source tree. A privately
+visible target can only be referenced within its own package (not subpackages).
+In between these extremes, a target may allow access to its own package plus any
+of the packages described by one or more package groups. For a more detailed
+explanation of the visibility system, see the
+[visibility](/versions/9.1.0/reference/be/common-definitions#common.visibility)
+attribute.
+
+A given package is considered to be in the group if it either matches the
+`packages` attribute, or is already contained in one of the other
+package groups mentioned in the `includes` attribute.
+
+Package groups are technically targets, but are not created by rules, and do
+not themselves have any visibility protection.
+
+### Arguments
+
+| Attribute | Description |
+| --- | --- |
+| `name` | [Name](/versions/9.1.0/concepts/labels#target-names); required  A unique name for this target. |
+| `packages` | List of strings; default is `[]`  A list of zero or more package specifications.  Each package specification string can have one of the following forms:   1. The full name of a package, without its repository, starting with a    double slash. For example, `//foo/bar` specifies the package    having that name and which lives in the same repository as the package    group.- As above, but with a trailing `/...`. For example, `//foo/...` specifies the set of `//foo` and all its      subpackages. `//...` specifies all packages in the current      repository.- The strings `public` or `private`, which        respectively specify every package or no package. (This form requires        the flag `--incompatible_package_group_has_public_syntax` to        be set.)   In addition, the first two kinds of package specifications may also be prefixed with `-` to indicate that they are negated.  The package group contains any package that matches at least one of its positive specifications and none of its negative specifications For instance, the value `[//foo/..., -//foo/tests/...]` includes all subpackages of `//foo` that are not also subpackages of `//foo/tests`. (`//foo` itself is included while //foo/tests itself is not.)  Aside from public visibility, there is no way to directly specify packages outside the current repository.  If this attribute is missing, it is the same as setting it to an empty list, which is also the same as setting it to a list containing only `private`. *Note:* Prior to Bazel 6.0, the specification `//...` had a legacy behavior of being the same as `public`. This behavior is fixed when `--incompatible_fix_package_group_reporoot_syntax` is enabled, which is the default after Bazel 6.0.  *Note:* Prior to Bazel 6.0, when this attribute is serialized as part of `bazel query --output=proto` (or `--output=xml`), the leading slashes are omitted. For instance, `//pkg/foo/...` will output as `\"pkg/foo/...\"`. This behavior is fixed when `--incompatible_package_group_includes_double_slash` is enabled, which is the default after Bazel 6.0. |
+| `includes` | List of [labels](/versions/9.1.0/concepts/labels); default is `[]`  Other package groups that are included in this one.  The labels in this attribute must refer to other package groups. Packages in referenced package groups are taken to be part of this package group. This is transitive — if package group `a` includes package group `b`, and `b` includes package group `c`, then every package in `c` will also be a member of `a`.  When used together with negated package specifications, note that the set of packages for each group is first computed independently and the results are then unioned together. This means that negated specifications in one group have no effect on the specifications in another group. |
+
+### Examples
+
+The following `package_group` declaration specifies a
+package group called "tropical" that contains tropical fruits.
+
+```
+package_group(
+    name = "tropical",
+    packages = [
+        "//fruits/mango",
+        "//fruits/orange",
+        "//fruits/papaya/...",
+    ],
+)
+```
+
+The following declarations specify the package groups of a fictional
+application:
+
+```
+package_group(
+    name = "fooapp",
+    includes = [
+        ":controller",
+        ":model",
+        ":view",
+    ],
+)
+
+package_group(
+    name = "model",
+    packages = ["//fooapp/database"],
+)
+
+package_group(
+    name = "view",
+    packages = [
+        "//fooapp/swingui",
+        "//fooapp/webui",
+    ],
+)
+
+package_group(
+    name = "controller",
+    packages = ["//fooapp/algorithm"],
+)
+```
+
+## exports_files
+
+```
+exports_files([label, ...], visibility, licenses)
+```
+
+`exports_files()` specifies a list of files belonging to
+this package that are exported to other packages.
+
+The BUILD file for a package may only refer directly to source files belonging
+to another package if they are explicitly exported with an
+`exports_files()` statement. Read more about
+[visibility of files](/versions/9.1.0/concepts/visibility#source-file-target-visibility).
+
+As a legacy behaviour, also files mentioned as input to a rule are exported
+with the default visibility until the flag
+[`--incompatible_no_implicit_file_export`](https://github.com/bazelbuild/bazel/issues/10225)
+is flipped. However, this behavior should not be relied upon and actively
+migrated away from.
+
+### Arguments
+
+The argument is a list of names of files within the current package. A
+visibility declaration can also be specified; in this case, the files will be
+visible to the targets specified. If no visibility is specified, the files
+will be visible to every package, even if a package default visibility was
+specified in the `package`
+function. The [licenses](/versions/9.1.0/reference/be/common-definitions#common.licenses)
+can also be specified.
+
+### Example
+
+The following example exports `golden.txt`, a
+text file from the `test_data` package, so that other
+packages may use it, for example, in the `data` attribute
+of tests.
+
+```
+# from //test_data/BUILD
+
+exports_files(["golden.txt"])
+```
+
+## glob
+
+```
+glob(include, exclude=[], exclude_directories=1, allow_empty=True)
+```
+
+Glob is a helper function that finds all files that match certain path patterns,
+and returns a new, mutable, sorted list of their paths. Glob only searches files
+in its own package, and looks only for source files (not generated files nor
+other targets).
+
+A source file's Label is included in the result if the file's package-relative
+path matches any of the `include` patterns and none of the
+`exclude` patterns.
+
+The `include` and `exclude` lists contain path patterns
+that are relative to the current package. Every pattern may consist of one or
+more path segments. As usual with Unix paths, these segments are separated by
+`/`. The segments in the pattern are matched against the segments of
+the path. Segments may contain the `*` wildcard: this matches
+any substring in the path segment (even the empty substring), excluding the
+directory separator `/`. This wildcard can be used multiple times
+within one path segment. Additionally, the `**` wildcard can match
+zero or more complete path segments, but it must be declared as a standalone
+path segment.
+
+Examples:
+
+* `foo/bar.txt` matches exactly the `foo/bar.txt` file
+  in this package (unless `foo/` is a subpackage)
+* `foo/*.txt` matches every file in the `foo/` directory
+  if the file ends with `.txt` (unless `foo/` is a
+  subpackage)
+* `foo/a*.htm*` matches every file in the `foo/`
+  directory that starts with `a`, then has an arbitrary string (could
+  be empty), then has `.htm`, and ends with another arbitrary string
+  (unless `foo/` is a subpackage); such as `foo/axx.htm`
+  and `foo/a.html` or `foo/axxx.html`
+* `foo/*` matches every file in the `foo/` directory,
+  (unless `foo/` is a subpackage); it does not match `foo`
+  directory itself even if `exclude_directories` is set to
+  0
+* `foo/**` matches every file in every non-subpackage subdirectory
+  under package's first level subdirectory `foo/`; if
+  `exclude_directories` is set to 0, `foo`
+  directory itself also matches the pattern; in this case, `**` is
+  considered to match zero path segments
+* `**/a.txt` matches `a.txt` files in this package's
+  directory plus non-subpackage subdirectories.
+* `**/bar/**/*.txt` matches every `.txt` file in every
+  non-subpackage subdirectory of this package, if at least one directory on the
+  resulting path is called `bar`, such as
+  `xxx/bar/yyy/zzz/a.txt` or `bar/a.txt` (remember that
+  `**` also matches zero segments) or `bar/zzz/a.txt`
+* `**` matches every file in every non-subpackage subdirectory of
+  this package
+* `foo**/a.txt` is an invalid pattern, because `**` must
+  stand on its own as a segment
+* `foo/` is an invalid pattern, because the second segment defined
+  after `/` is an empty string
+
+If the `exclude_directories` argument is enabled (set to 1), files of
+type directory will be omitted from the results (default 1).
+
+If the `allow_empty` argument is set to `False`, the
+`glob` function will error-out if the result would otherwise be the
+empty list.
+
+There are several important limitations and caveats:
+
+1. Since `glob()` runs during BUILD file evaluation,
+   `glob()` matches files only in your source tree, never
+   generated files. If you are building a target that requires both
+   source and generated files, you must append an explicit list of generated
+   files to the glob. See the [example](#glob_example)
+   below with `:mylib` and `:gen_java_srcs`.
+2. If a rule has the same name as a matched source file, the rule will
+   "shadow" the file.
+
+   To understand this, remember that `glob()` returns a list of
+   paths, so using `glob()` in other rules' attribute (e.g.
+   `srcs = glob(["*.cc"])`) has the same effect as listing the
+   matched paths explicitly. If for example `glob()` yields
+   `["Foo.java", "bar/Baz.java"]` but there's also a rule in the
+   package called "Foo.java" (which is allowed, though Bazel warns about it),
+   then the consumer of the `glob()` will use the "Foo.java" rule
+   (its outputs) instead of the "Foo.java" file. See
+   [GitHub
+   issue #10395](https://github.com/bazelbuild/bazel/issues/10395#issuecomment-583714657) for more details.
+3. Globs may match files in subdirectories. And subdirectory names
+   may be wildcarded. However...
+4. Labels are not allowed to cross the package boundary and glob does
+   not match files in subpackages.
+
+   For example, the glob expression `**/*.cc` in package
+   `x` does not include `x/y/z.cc` if
+   `x/y` exists as a package (either as
+   `x/y/BUILD`, or somewhere else on the package-path). This
+   means that the result of the glob expression actually depends on the
+   existence of BUILD files — that is, the same glob expression would
+   include `x/y/z.cc` if there was no package called
+   `x/y` or it was marked as deleted using the
+   [--deleted_packages](/versions/9.1.0/docs/user-manual#flag--deleted_packages)
+   flag.
+5. The restriction above applies to all glob expressions,
+   no matter which wildcards they use.
+6. A hidden file with filename starting with `.` is completely matched by
+   both the `**` and the `*` wildcards. If you want to match a hidden file
+   with a compound pattern, your pattern needs to begin with a `.`. For example,
+   `*` and `.*.txt` will match `.foo.txt`, but `*.txt`
+   will not.
+   Hidden directories are also matched in the same manner. Hidden directories
+   may include files that are not required as inputs, and can increase the
+   number of unnecessarily globbed files and memory consumption. To exclude
+   hidden directories, add them to the "exclude" list argument.
+7. The "\*\*" wildcard has one corner case: the pattern
+   `"**"` doesn't match the package's directory path. That is to
+   say, `glob(["**"], exclude_directories = False)` matches all files
+   and directories transitively strictly under the current package's directory
+   (but of course not going into directories of subpackages - see the previous
+   note about that).
+
+In general, you should **try to provide an appropriate extension (e.g. \*.html)
+instead of using a bare '\*'** for a glob pattern. The more explicit name
+is both self documenting and ensures that you don't accidentally match backup
+files, or emacs/vi/... auto-save files.
+
+When writing build rules you can enumerate the elements of the glob. This
+enables generating individual rules for every input, for example. See the
+[expanded glob example](#expanded_glob_example) section below.
+
+### Glob Examples
+
+Create a Java library built from all java files in this directory,
+and all files generated by the `:gen_java_srcs` rule.
+
+```
+java_library(
+    name = "mylib",
+    srcs = glob(["*.java"]) + [":gen_java_srcs"],
+    deps = "...",
+)
+
+genrule(
+    name = "gen_java_srcs",
+    outs = [
+        "Foo.java",
+        "Bar.java",
+    ],
+    ...
+)
+```
+
+Include all txt files in directory testdata except experimental.txt.
+Note that files in subdirectories of testdata will not be included. If
+you want those files to be included, use a recursive glob (\*\*).
+
+```
+sh_test(
+    name = "mytest",
+    srcs = ["mytest.sh"],
+    data = glob(
+        ["testdata/*.txt"],
+        exclude = ["testdata/experimental.txt"],
+    ),
+)
+```
+
+### Recursive Glob Examples
+
+Make the test depend on all txt files in the testdata directory and any
+of its subdirectories (and their subdirectories, and so on).
+Subdirectories containing a BUILD file are ignored. (See limitations
+and caveats above.)
+
+```
+sh_test(
+    name = "mytest",
+    srcs = ["mytest.sh"],
+    data = glob(["testdata/**/*.txt"]),
+)
+```
+
+Create a library built from all java files in this directory and all
+subdirectories except those whose path includes a directory named testing.
+**This pattern should be avoided if possible, as it can reduce build
+incrementality and therefore increase build times.**
+
+```
+java_library(
+    name = "mylib",
+    srcs = glob(
+        ["**/*.java"],
+        exclude = ["**/testing/**"],
+    ),
+)
+```
+
+### Expanded Glob Examples
+
+Create an individual genrule for \*\_test.cc in the current directory
+that counts the number of lines in the file.
+
+```
+# Conveniently, the build language supports list comprehensions.
+[genrule(
+    name = "count_lines_" + f[:-3],  # strip ".cc"
+    srcs = [f],
+    outs = ["%s-linecount.txt" % f[:-3]],
+    cmd = "wc -l $< >$@",
+ ) for f in glob(["*_test.cc"])]
+```
+
+If the BUILD file above is in package //foo and the package contains three
+matching files, a_test.cc, b_test.cc and c_test.cc then running
+`bazel query '//foo:all'` will list all rules that were generated:
+
+```
+$ bazel query '//foo:all' | sort
+//foo:count_lines_a_test
+//foo:count_lines_b_test
+//foo:count_lines_c_test
+```
+
+## select
+
+```
+select(
+    {conditionA: valuesA, conditionB: valuesB, ...},
+    no_match_error = "custom message"
+)
+```
+
+`select()` is the helper function that makes a rule attribute
+[configurable](/versions/9.1.0/reference/be/common-definitions#configurable-attributes).
+It can replace the right-hand side of
+*almost*
+any attribute assignment so its value depends on command-line Bazel flags.
+You can use this, for example, to define platform-specific dependencies or to
+embed different resources depending on whether a rule is built in "developer"
+vs. "release" mode.
+
+Basic use is as follows:
+
+```
+sh_binary(
+    name = "mytarget",
+    srcs = select({
+        ":conditionA": ["mytarget_a.sh"],
+        ":conditionB": ["mytarget_b.sh"],
+        "//conditions:default": ["mytarget_default.sh"]
+    })
+)
+```
+
+This makes the `srcs` attribute of
+a `sh_binary` configurable by replacing its normal label
+list assignment with a `select` call that maps
+configuration conditions to matching values. Each condition is a label
+reference to
+a `config_setting` or
+`constraint_value`,
+which "matches" if the target's configuration matches an expected set of
+values. The value of `mytarget#srcs` then becomes whichever
+label list matches the current invocation.
+
+Notes:
+
+* Exactly one condition is selected on any invocation.
+* If multiple conditions match and one is a specialization of the others,
+  the specialization takes precedence. Condition B is considered a
+  specialization of condition A if B has all the same flags and constraint
+  values as A plus some additional flags or constraint values. This also
+  means that specialization resolution is not designed to create an ordering as
+  demonstrated in Example 2 below.
+* If multiple conditions match and one is not a specialization of all the
+  others, Bazel fails with an error, unless all conditions resolve to the same value.
+* The special pseudo-label `//conditions:default` is
+  considered to match if no other condition matches. If this condition
+  is left out, some other rule must match to avoid an error.
+* `select` can be embedded *inside* a larger
+  attribute assignment. So `srcs = ["common.sh"]
+  + select({ ":conditionA": ["myrule_a.sh"], ...})` and `srcs = select({ ":conditionA": ["a.sh"]}) + select({ ":conditionB":
+  ["b.sh"]})` are valid expressions.
+* `select` works with most, but not all, attributes. Incompatible
+  attributes are marked `nonconfigurable` in their documentation.
+
+  ## subpackages
+
+  ```
+  subpackages(include, exclude=[], allow_empty=True)
+  ```
+
+  `subpackages()` is a helper function, similar to `glob()`
+  that lists subpackages instead of files and directories. It uses the same
+  path patterns as `glob()` and can match any subpackage that is a
+  direct descendant of the currently loading BUILD file. See [glob](#glob) for a detailed explanation and examples of include and
+  exclude patterns.
+
+  The resulting list of subpackages returned is in sorted order and contains
+  paths relative to the current loading package that match the given patterns in
+  `include` and not those in `exclude`.
+
+  ### Example
+
+  The following example lists all the direct subpackages for the package `foo/BUILD`
+
+  ```
+  # The following BUILD files exist:
+  # foo/BUILD
+  # foo/bar/baz/BUILD
+  # foo/bar/but/bad/BUILD
+  # foo/sub/BUILD
+  # foo/sub/deeper/BUILD
+  #
+  # In foo/BUILD a call to
+  subs1 = subpackages(include = ["**"])
+
+  # results in subs1 == ["sub", "bar/baz", "bar/but/bad"]
+  #
+  # 'sub/deeper' is not included because it is a subpackage of 'foo/sub' not of
+  # 'foo'
+
+  subs2 = subpackages(include = ["bar/*"])
+  # results in subs2 = ["bar/baz"]
+  #
+  # Since 'bar' is not a subpackage itself, this looks for any subpackages under
+  # all first level subdirectories of 'bar'.
+
+  subs3 = subpackages(include = ["bar/**"])
+  # results in subs3 = ["bar/baz", "bar/but/bad"]
+  #
+  # Since bar is not a subpackage itself, this looks for any subpackages which are
+  # (1) under all subdirectories of 'bar' which can be at any level, (2) not a
+  # subpackage of another subpackages.
+
+  subs4 = subpackages(include = ["sub"])
+  subs5 = subpackages(include = ["sub/*"])
+  subs6 = subpackages(include = ["sub/**"])
+  # results in subs4 and subs6 being ["sub"]
+  # results in subs5 = [].
+  #
+  # In subs4, expression "sub" checks whether 'foo/sub' is a package (i.e. is a
+  # subpackage of 'foo').
+  # In subs5, "sub/*" looks for subpackages under directory 'foo/sub'. Since
+  # 'foo/sub' is already a subpackage itself, the subdirectories will not be
+  # traversed anymore.
+  # In subs6, 'foo/sub' is a subpackage itself and matches pattern "sub/**", so it
+  # is returned. But the subdirectories of 'foo/sub' will not be traversed
+  # anymore.
+  ```
+
+  In general it is preferred that instead of calling this function directly
+  that users use the 'subpackages' module of
+  [skylib](https://github.com/bazelbuild/bazel-skylib).
\ No newline at end of file
diff --git a/versions/9.1.0/reference/be/general.mdx b/versions/9.1.0/reference/be/general.mdx
new file mode 100644
index 00000000..550e857b
--- /dev/null
+++ b/versions/9.1.0/reference/be/general.mdx
@@ -0,0 +1,580 @@
+---
+title: 'General Rules'
+---
+
+## Rules
+
+* [alias](#alias)
+* [config_setting](#config_setting)
+* [filegroup](#filegroup)
+* [genquery](#genquery)
+* [genrule](#genrule)
+* [starlark_doc_extract](#starlark_doc_extract)
+* [test_suite](#test_suite)
+
+## alias
+
+[View rule sourceopen_in_new](https://github.com/bazelbuild/bazel/blob/master/src/main/java/com/google/devtools/build/lib/rules/Alias.java)
+
+```
+alias(name, actual, aspect_hints, compatible_with, deprecation, features, package_metadata, restricted_to, tags, target_compatible_with, testonly, visibility)
+```
+
+The `alias` rule creates another name a rule can be referred to as.
+
+Aliasing only works for "regular" targets. In particular, `package_group`
+and `test_suite` cannot be aliased.
+
+Aliasing may be of help in large repositories where renaming a target would require making
+changes to lots of files. You can also use alias rule to store a
+[select](/versions/9.1.0/reference/be/functions#select) function call if you want to reuse that logic for
+multiple targets.
+
+The alias rule has its own visibility declaration. In all other respects, it behaves
+like the rule it references (e.g. testonly *on the alias* is ignored; the testonly-ness
+of the referenced rule is used instead) with some minor exceptions:
+
+* Tests are not run if their alias is mentioned on the command line. To define an alias
+  that runs the referenced test, use a [`test_suite`](#test_suite)
+  rule with a single target in its [`tests`](#test_suite.tests)
+  attribute.
+* When defining environment groups, the aliases to `environment` rules are not
+  supported. They are not supported in the `--target_environment` command line
+  option, either.
+
+#### Examples
+
+```
+filegroup(
+    name = "data",
+    srcs = ["data.txt"],
+)
+
+alias(
+    name = "other",
+    actual = ":data",
+)
+```
+
+### Arguments
+
+| Attributes | |
+| --- | --- |
+| `name` | [Name](/versions/9.1.0/concepts/labels#target-names); required  A unique name for this target. |
+| `actual` | [Label](/versions/9.1.0/concepts/labels); required The target this alias refers to. It does not need to be a rule, it can also be an input file. |
+
+## config_setting
+
+[View rule sourceopen_in_new](https://github.com/bazelbuild/bazel/blob/master/src/main/java/com/google/devtools/build/lib/rules/config/ConfigRuleClasses.java)
+
+```
+config_setting(name, aspect_hints, constraint_values, define_values, deprecation, features, flag_values, licenses, package_metadata, tags, testonly, values, visibility)
+```
+
+Matches an expected configuration state (expressed as build flags or platform constraints) for
+the purpose of triggering configurable attributes. See [select](/versions/9.1.0/reference/be/functions#select) for
+how to consume this rule and [Configurable attributes](/versions/9.1.0/reference/be/common-definitions#configurable-attributes) for an overview of the general feature.
+
+#### Examples
+
+The following matches any build that sets `--compilation_mode=opt` or
+`-c opt` (either explicitly at the command line or implicitly from .bazelrc files):
+
+```
+  config_setting(
+      name = "simple",
+      values = {"compilation_mode": "opt"}
+  )
+```
+
+The following matches any build that targets ARM and applies the custom define
+`FOO=bar` (for instance, `bazel build --cpu=arm --define FOO=bar ...`):
+
+```
+  config_setting(
+      name = "two_conditions",
+      values = {
+          "cpu": "arm",
+          "define": "FOO=bar"
+      }
+  )
+```
+
+The following matches any build that sets
+[user-defined flag](https://bazel.build/versions/9.1.0/rules/config#user-defined-build-settings)
+`--//custom_flags:foo=1` (either explicitly at the command line or implicitly from
+.bazelrc files):
+
+```
+  config_setting(
+      name = "my_custom_flag_is_set",
+      flag_values = { "//custom_flags:foo": "1" },
+  )
+```
+
+The following matches any build that targets a platform with an x86_64 architecture and glibc
+version 2.25, assuming the existence of a `constraint_value` with label
+`//example:glibc_2_25`. Note that a platform still matches if it defines additional
+constraint values beyond these two.
+
+```
+  config_setting(
+      name = "64bit_glibc_2_25",
+      constraint_values = [
+          "@platforms//cpu:x86_64",
+          "//example:glibc_2_25",
+      ]
+  )
+```
+
+In all these cases, it's possible for the configuration to change within the build, for example if
+a target needs to be built for a different platform than its dep. This means that even when a
+`config_setting` doesn't match the top-level command-line flags, it may still match
+some build targets.
+
+#### Notes
+
+* See [select](/versions/9.1.0/reference/be/functions#select) for what happens when multiple
+  `config_setting`s match the current configuration state.
+* For flags that support shorthand forms (e.g. `--compilation_mode` vs.
+  `-c`), `values` definitions must use the full form. These automatically
+  match invocations using either form.
+* If a flag takes multiple values (like `--copt=-Da --copt=-Db` or a list-typed
+  [Starlark flag](https://bazel.build/versions/9.1.0/rules/config#user-defined-build-settings)), `values = { "flag": "a" }` matches if `"a"` is
+  present *anywhere* in the actual list.
+
+  `values = { "myflag": "a,b" }` works the same way: this matches
+  `--myflag=a --myflag=b`, `--myflag=a --myflag=b --myflag=c`,
+  `--myflag=a,b`, and `--myflag=c,b,a`. Exact semantics vary between
+  flags. For example, `--copt` doesn't support multiple values *in the same
+  instance*: `--copt=a,b` produces `["a,b"]` while `--copt=a
+  --copt=b` produces `["a", "b"]` (so `values = { "copt": "a,b" }`
+  matches the former but not the latter). But `--ios_multi_cpus` (for Apple rules)
+  *does*: `-ios_multi_cpus=a,b` and `ios_multi_cpus=a --ios_multi_cpus=b` both produce `["a", "b"]`. Check flag definitions and test your
+  conditions carefully to verify exact expectations.
+* If you need to define conditions that aren't modeled by built-in build flags, use
+  [Starlark-defined flags](https://bazel.build/versions/9.1.0/rules/config#user-defined-build-settings). You can also use `--define`, but this offers weaker
+  support and is not recommended. See
+  [here](/versions/9.1.0/reference/be/common-definitions#configurable-attributes) for more discussion.
+* Avoid repeating identical `config_setting` definitions in different packages.
+  Instead, reference a common `config_setting` that defined in a canonical package.
+* [`values`](/versions/9.1.0/reference/be/general#config_setting.values),
+  [`define_values`](/versions/9.1.0/reference/be/general#config_setting.define_values), and
+  [`constraint_values`](/versions/9.1.0/reference/be/general#config_setting.constraint_values)
+  can be used in any combination in the same `config_setting` but at least one must
+  be set for any given `config_setting`.
+
+### Arguments
+
+| Attributes | |
+| --- | --- |
+| `name` | [Name](/versions/9.1.0/concepts/labels#target-names); required  A unique name for this target. |
+| `constraint_values` | List of [labels](/versions/9.1.0/concepts/labels); [nonconfigurable](/versions/9.1.0/reference/be/common-definitions#configurable-attributes); default is `[]` The minimum set of `constraint_values` that the target platform must specify in order to match this `config_setting`. (The execution platform is not considered here.) Any additional constraint values that the platform has are ignored. See [Configurable Build Attributes](https://bazel.build/versions/9.1.0/docs/configurable-attributes#platforms) for details. If two `config_setting`s match in the same `select` and one has all the same flags and `constraint_setting`s as the other plus additional ones, the one with more settings is chosen. This is known as "specialization". For example, a `config_setting` matching `x86` and `Linux` specializes a `config_setting` matching `x86`. If two `config_setting`s match and both have `constraint_value`s not present in the other, this is an error. |
+| `define_values` | Dictionary: String -> String; [nonconfigurable](/versions/9.1.0/reference/be/common-definitions#configurable-attributes); default is `{}` The same as [`values`](/versions/9.1.0/reference/be/general#config_setting.values) but specifically for the `--define` flag. `--define` is special because its syntax (`--define KEY=VAL`) means `KEY=VAL` is a *value* from a Bazel flag perspective.  That means:  ```             config_setting(                 name = "a_and_b",                 values = {                     "define": "a=1",                     "define": "b=2",                 }) ```   doesn't work because the same key (`define`) appears twice in the dictionary. This attribute solves that problem:  ```             config_setting(                 name = "a_and_b",                 define_values = {                     "a": "1",                     "b": "2",                 }) ```   correctly matches `bazel build //foo --define a=1 --define b=2`. `--define` can still appear in [`values`](/versions/9.1.0/reference/be/general#config_setting.values) with normal flag syntax, and can be mixed freely with this attribute as long as dictionary keys remain distinct. |
+| `flag_values` | Dictionary: [label](/versions/9.1.0/concepts/labels) -> String; [nonconfigurable](/versions/9.1.0/reference/be/common-definitions#configurable-attributes); default is `{}` The same as [`values`](/versions/9.1.0/reference/be/general#config_setting.values) but for [user-defined build flags](https://bazel.build/versions/9.1.0/rules/config#user-defined-build-settings). This is a distinct attribute because user-defined flags are referenced as labels while built-in flags are referenced as arbitrary strings. |
+| `values` | Dictionary: String -> String; [nonconfigurable](/versions/9.1.0/reference/be/common-definitions#configurable-attributes); default is `{}` The set of configuration values that match this rule (expressed as build flags) This rule inherits the configuration of the configured target that references it in a `select` statement. It is considered to "match" a Bazel invocation if, for every entry in the dictionary, its configuration matches the entry's expected value. For example `values = {"compilation_mode": "opt"}` matches the invocations `bazel build --compilation_mode=opt ...` and `bazel build -c opt ...` on target-configured rules.  For convenience's sake, configuration values are specified as build flags (without the preceding `"--"`). But keep in mind that the two are not the same. This is because targets can be built in multiple configurations within the same build. For example, an exec configuration's "cpu" matches the value of `--host_cpu`, not `--cpu`. So different instances of the same `config_setting` may match the same invocation differently depending on the configuration of the rule using them.  If a flag is not explicitly set at the command line, its default value is used. If a key appears multiple times in the dictionary, only the last instance is used. If a key references a flag that can be set multiple times on the command line (e.g. `bazel build --copt=foo --copt=bar --copt=baz ...`), a match occurs if *any* of those settings match. |
+
+## filegroup
+
+[View rule sourceopen_in_new](https://github.com/bazelbuild/bazel/blob/master/src/main/java/com/google/devtools/build/lib/rules/filegroup/FilegroupRule.java)
+
+```
+filegroup(name, srcs, data, aspect_hints, compatible_with, deprecation, features, licenses, output_group, package_metadata, restricted_to, tags, target_compatible_with, testonly, visibility)
+```
+
+Use `filegroup` to gather the outputs of a set of targets under a single
+label.
+
+`filegroup` is not a substitute for listing targets on the command line or
+in an attribute of another rule, because targets have many properties other than their
+outputs, which are not collected in the same way. However, it's still useful in quite
+a few cases, for example, in the `srcs` attribute of a genrule, or
+the `data` attribute of a \*\_binary rule.
+
+Using `filegroup` is encouraged instead of referencing directories directly.
+Directly referencing directories is discouraged because the build system does not have
+full knowledge of all files below the directory, so it may not rebuild when these files change.
+When combined with [glob](/versions/9.1.0/reference/be/functions#glob), `filegroup` can ensure that all
+files are explicitly known to the build system.
+
+#### Examples
+
+To create a `filegroup` consisting of two source files, do
+
+```
+filegroup(
+    name = "mygroup",
+    srcs = [
+        "a_file.txt",
+        "//a/library:target",
+        "//a/binary:target",
+    ],
+)
+```
+
+Or, use a `glob` to fully crawl a testdata directory:
+
+```
+filegroup(
+    name = "exported_testdata",
+    srcs = glob([
+        "testdata/*.dat",
+        "testdata/logs/**/*.log",
+    ]),
+)
+```
+
+To make use of these definitions, reference the `filegroup` with a label from any rule:
+
+```
+cc_library(
+    name = "my_library",
+    srcs = ["foo.cc"],
+    data = [
+        "//my_package:exported_testdata",
+        "//my_package:mygroup",
+    ],
+)
+```
+
+### Arguments
+
+| Attributes | |
+| --- | --- |
+| `name` | [Name](/versions/9.1.0/concepts/labels#target-names); required  A unique name for this target. |
+| `srcs` | List of [labels](/versions/9.1.0/concepts/labels); default is `[]` The list of targets that are members of the file group. It is common to use the result of a [glob](/versions/9.1.0/reference/be/functions#glob) expression for the value of the `srcs` attribute. |
+| `data` | List of [labels](/versions/9.1.0/concepts/labels); default is `[]` The list of files needed by this rule at runtime. Targets named in the `data` attribute will be added to the `runfiles` of this `filegroup` rule. When the `filegroup` is referenced in the `data` attribute of another rule its `runfiles` will be added to the `runfiles` of the depending rule. See the [data dependencies](/versions/9.1.0/concepts/dependencies#data-dependencies) section and [general documentation of `data`](/versions/9.1.0/reference/be/common-definitions#common.data) for more information about how to depend on and use data files. |
+| `output_group` | String; default is `""` The output group from which to gather artifacts from sources. If this attribute is specified, artifacts from the specified output group of the dependencies will be exported instead of the default output group. An "output group" is a category of output artifacts of a target, specified in that rule's implementation. |
+
+## genquery
+
+[View rule sourceopen_in_new](https://github.com/bazelbuild/bazel/blob/master/src/main/java/com/google/devtools/build/lib/rules/genquery/GenQueryRule.java)
+
+```
+genquery(name, deps, data, aspect_hints, compatible_with, compressed_output, deprecation, exec_compatible_with, exec_group_compatible_with, exec_properties, expression, features, licenses, opts, package_metadata, restricted_to, scope, strict, tags, target_compatible_with, testonly, visibility)
+```
+
+`genquery()` runs a query specified in the
+[Bazel query language](/versions/9.1.0/reference/query) and dumps the result
+into a file.
+
+In order to keep the build consistent, the query is allowed only to visit
+the transitive closure of the targets specified in the `scope`
+attribute. Queries violating this rule will fail during execution if
+`strict` is unspecified or true (if `strict` is false,
+the out of scope targets will simply be skipped with a warning). The
+easiest way to make sure this does not happen is to mention the same labels
+in the scope as in the query expression.
+
+The only difference between the queries allowed here and on the command
+line is that queries containing wildcard target specifications (e.g.
+`//pkg:*` or `//pkg:all`) are not allowed here.
+The reasons for this are two-fold: first, because `genquery` has
+to specify a scope to prevent targets outside the transitive closure of the
+query to influence its output; and, second, because `BUILD` files
+do not support wildcard dependencies (e.g. `deps=["//a/..."]`
+is not allowed).
+
+The genquery's output is ordered lexicographically in order to enforce deterministic output,
+with the exception of `--output=graph|minrank|maxrank` or when `somepath`
+is used as the top-level function.
+
+The name of the output file is the name of the rule.
+
+#### Examples
+
+This example writes the list of the labels in the transitive closure of the
+specified target to a file.
+
+```
+genquery(
+    name = "kiwi-deps",
+    expression = "deps(//kiwi:kiwi_lib)",
+    scope = ["//kiwi:kiwi_lib"],
+)
+```
+
+### Arguments
+
+| Attributes | |
+| --- | --- |
+| `name` | [Name](/versions/9.1.0/concepts/labels#target-names); required  A unique name for this target. |
+| `compressed_output` | Boolean; default is `False` If `True`, query output is written in GZIP file format. This setting can be used to avoid spikes in Bazel's memory use when the query output is expected to be large. Bazel already internally compresses query outputs greater than 220 bytes regardless of the value of this setting, so setting this to `True` may not reduce retained heap. However, it allows Bazel to skip *decompression* when writing the output file, which can be memory-intensive. |
+| `expression` | String; required The query to be executed. In contrast to the command line and other places in BUILD files, labels here are resolved relative to the root directory of the workspace. For example, the label `:b` in this attribute in the file `a/BUILD` will refer to the target `//:b`. |
+| `opts` | List of strings; default is `[]` The options that are passed to the query engine. These correspond to the command line options that can be passed to `bazel query`. Some query options are not allowed here: `--keep_going`, `--query_file`, `--universe_scope`, `--order_results` and `--order_output`. Options not specified here will have their default values just like on the command line of `bazel query`. |
+| `scope` | List of [labels](/versions/9.1.0/concepts/labels); required The scope of the query. The query is not allowed to touch targets outside the transitive closure of these targets. |
+| `strict` | Boolean; default is `True` If true, targets whose queries escape the transitive closure of their scopes will fail to build. If false, Bazel will print a warning and skip whatever query path led it outside of the scope, while completing the rest of the query. |
+
+## genrule
+
+[View rule sourceopen_in_new](https://github.com/bazelbuild/bazel/blob/master/src/main/java/com/google/devtools/build/lib/bazel/rules/genrule/BazelGenRuleRule.java)
+
+```
+genrule(name, srcs, outs, aspect_hints, cmd, cmd_bash, cmd_bat, cmd_ps, compatible_with, deprecation, exec_compatible_with, exec_group_compatible_with, exec_properties, executable, features, licenses, local, message, output_licenses, output_to_bindir, package_metadata, restricted_to, tags, target_compatible_with, testonly, toolchains, tools, visibility)
+```
+
+A `genrule` generates one or more files using a user-defined Bash command.
+
+Genrules are generic build rules that you can use if there's no specific rule for the task.
+For example, you could run a Bash one-liner. If however you need to compile C++ files, stick
+to the existing `cc_*` rules, because all the heavy lifting has already been done
+for you.
+
+Note that genrule requires a shell to interpret the command argument.
+It is also easy to reference arbitrary programs available on the PATH, however this makes the
+command non-hermetic and may not be reproducible.
+If you only need to run a single tool, consider using
+[run_binary](https://github.com/bazelbuild/bazel-skylib/blob/main/docs/run_binary_doc.md)
+instead.
+
+Like every other action, the action created by genrules should not assume anything about their
+working directory; all Bazel guarantees is that their declared inputs will be available at the
+path that `$(location)` returns for their label. For example, if the action is run in a
+sandbox or remotely, the implementation of the sandbox or the remote execution will determine the
+working directory. If run directly (using the `standalone` strategy), the working
+directory will be the execution root, i.e. the result of `bazel info execution_root`.
+
+Do not use a genrule for running tests. There are special dispensations for tests and test
+results, including caching policies and environment variables. Tests generally need to be run
+after the build is complete and on the target architecture, whereas genrules are executed during
+the build and on the exec architecture (the two may be different). If you need a general purpose
+testing rule, use [`sh_test`](/versions/9.1.0/reference/be/shell#sh_test).
+
+#### Cross-compilation Considerations
+
+*See [the user manual](/versions/9.1.0/docs/user-manual#configurations) for more info about
+cross-compilation.*
+
+While genrules run during a build, their outputs are often used after the build, for deployment or
+testing. Consider the example of compiling C code for a microcontroller: the compiler accepts C
+source files and generates code that runs on a microcontroller. The generated code obviously
+cannot run on the CPU that was used for building it, but the C compiler (if compiled from source)
+itself has to.
+
+The build system uses the exec configuration to describe the machine(s) on which the build runs
+and the target configuration to describe the machine(s) on which the output of the build is
+supposed to run. It provides options to configure each of these and it segregates the
+corresponding files into separate directories to avoid conflicts.
+
+For genrules, the build system ensures that dependencies are built appropriately:
+`srcs` are built (if necessary) for the *target* configuration,
+`tools` are built for the *exec* configuration, and the output is considered to
+be for the *target* configuration. It also provides ["Make" variables](/versions/9.1.0/reference/be/make-variables) that genrule commands can pass to the corresponding tools.
+
+It is intentional that genrule defines no `deps` attribute: other built-in rules use
+language-dependent meta information passed between the rules to automatically determine how to
+handle dependent rules, but this level of automation is not possible for genrules. Genrules work
+purely at the file and runfiles level.
+
+#### Special Cases
+
+*Exec-exec compilation*: in some cases, the build system needs to run genrules such that the
+output can also be executed during the build. If for example a genrule builds some custom compiler
+which is subsequently used by another genrule, the first one has to produce its output for the
+exec configuration, because that's where the compiler will run in the other genrule. In this case,
+the build system does the right thing automatically: it builds the `srcs` and
+`outs` of the first genrule for the exec configuration instead of the target
+configuration. See [the user manual](/versions/9.1.0/docs/user-manual#configurations) for more
+info.
+
+*JDK & C++ Tooling*: to use a tool from the JDK or the C++ compiler suite, the build system
+provides a set of variables to use. See ["Make" variable](/versions/9.1.0/reference/be/make-variables) for
+details.
+
+#### Genrule Environment
+
+The genrule command is executed by a Bash shell that is configured to fail when a command
+or a pipeline fails, using `set -e -o pipefail`.
+
+The build tool executes the Bash command in a sanitized process environment that
+defines only core variables such as `PATH`, `PWD`,
+`TMPDIR`, and a few others.
+To ensure that builds are reproducible, most variables defined in the user's shell
+environment are not passed though to the genrule's command. However, Bazel (but not
+Blaze) passes through the value of the user's `PATH` environment variable.
+Any change to the value of `PATH` will cause Bazel to re-execute the command
+on the next build.
+
+A genrule command should not access the network except to connect processes that are
+children of the command itself, though this is not currently enforced.
+
+The build system automatically deletes any existing output files, but creates any necessary parent
+directories before it runs a genrule. It also removes any output files in case of a failure.
+
+#### General Advice
+
+* Do ensure that tools run by a genrule are deterministic and hermetic. They should not write
+  timestamps to their output, and they should use stable ordering for sets and maps, as well as
+  write only relative file paths to the output, no absolute paths. Not following this rule will
+  lead to unexpected build behavior (Bazel not rebuilding a genrule you thought it would) and
+  degrade cache performance.
+* Do use `$(location)` extensively, for outputs, tools and sources. Due to the
+  segregation of output files for different configurations, genrules cannot rely on hard-coded
+  and/or absolute paths.
+* Do write a common Starlark macro in case the same or very similar genrules are used in
+  multiple places. If the genrule is complex, consider implementing it in a script or as a
+  Starlark rule. This improves readability as well as testability.
+* Do make sure that the exit code correctly indicates success or failure of the genrule.
+* Do not write informational messages to stdout or stderr. While useful for debugging, this can
+  easily become noise; a successful genrule should be silent. On the other hand, a failing genrule
+  should emit good error messages.
+* `$$` evaluates to a `$`, a literal dollar-sign, so in order to invoke a
+  shell command containing dollar-signs such as `ls $(dirname $x)`, one must escape it
+  thus: `ls $$(dirname $$x)`.
+* Avoid creating symlinks and directories. Bazel doesn't copy over the directory/symlink
+  structure created by genrules and its dependency checking of directories is unsound.
+* When referencing the genrule in other rules, you can use either the genrule's label or the
+  labels of individual output files. Sometimes the one approach is more readable, sometimes the
+  other: referencing outputs by name in a consuming rule's `srcs` will avoid
+  unintentionally picking up other outputs of the genrule, but can be tedious if the genrule
+  produces many outputs.
+
+#### Examples
+
+This example generates `foo.h`. There are no sources, because the command doesn't take
+any input. The "binary" run by the command is a perl script in the same package as the genrule.
+
+```
+genrule(
+    name = "foo",
+    srcs = [],
+    outs = ["foo.h"],
+    cmd = "./$(location create_foo.pl) > \"$@\"",
+    tools = ["create_foo.pl"],
+)
+```
+
+The following example shows how to use a [`filegroup`](/versions/9.1.0/reference/be/general#filegroup) and the outputs of another `genrule`. Note that using `$(SRCS)` instead
+of explicit `$(location)` directives would also work; this example uses the latter for
+sake of demonstration.
+
+```
+genrule(
+    name = "concat_all_files",
+    srcs = [
+        "//some:files",  # a filegroup with multiple files in it ==> $(locations)
+        "//other:gen",   # a genrule with a single output ==> $(location)
+    ],
+    outs = ["concatenated.txt"],
+    cmd = "cat $(locations //some:files) $(location //other:gen) > $@",
+)
+```
+
+### Arguments
+
+| Attributes | |
+| --- | --- |
+| `name` | [Name](/versions/9.1.0/concepts/labels#target-names); required  A unique name for this target.  You may refer to this rule by name in the `srcs` or `deps` section of other `BUILD` rules. If the rule generates source files, you should use the `srcs` attribute. |
+| `srcs` | List of [labels](/versions/9.1.0/concepts/labels); default is `[]` A list of inputs for this rule, such as source files to process. *This attributes is not suitable to list tools executed by the `cmd`; use the [`tools`](/versions/9.1.0/reference/be/general#genrule.tools) attribute for them instead.*  The build system ensures these prerequisites are built before running the genrule command; they are built using the same configuration as the original build request. The names of the files of these prerequisites are available to the command as a space-separated list in `$(SRCS)`; alternatively the path of an individual `srcs` target `//x:y` can be obtained using `$(location //x:y)`, or using `$<` provided it's the only entry in `srcs`. |
+| `outs` | List of [filenames](/versions/9.1.0/concepts/build-ref#filename); [nonconfigurable](/versions/9.1.0/reference/be/common-definitions#configurable-attributes); required A list of files generated by this rule. Output files must not cross package boundaries. Output filenames are interpreted as relative to the package.  If the `executable` flag is set, `outs` must contain exactly one label.  The genrule command is expected to create each output file at a predetermined location. The location is available in `cmd` using [genrule-specific "Make" variables](/versions/9.1.0/reference/be/make-variables#predefined_genrule_variables) (`$@`, `$(OUTS)`, `$(@D)` or `$(RULEDIR)`) or using [`$(location)`](/versions/9.1.0/reference/be/make-variables#predefined_label_variables) substitution. |
+| `cmd` | String; default is `""` The command to run. Subject to [`$(location)`](/versions/9.1.0/reference/be/make-variables#predefined_label_variables) and ["Make" variable](/versions/9.1.0/reference/be/make-variables) substitution.  1. First [`$(location)`](/versions/9.1.0/reference/be/make-variables#predefined_label_variables) substitution is applied, replacing all occurrences of `$(location     label)` and of `$(locations label)` (and similar    constructions using related variables `execpath`, `execpaths`,    `rootpath` and `rootpaths`). 2. Next, ["Make" variables](/versions/9.1.0/reference/be/make-variables) are expanded. Note that    predefined variables `$(JAVA)`, `$(JAVAC)` and    `$(JAVABASE)` expand under the *exec* configuration, so Java invocations    that run as part of a build step can correctly load shared libraries and other    dependencies. 3. Finally, the resulting command is executed using the Bash shell. If its exit code is    non-zero the command is considered to have failed.  This is the fallback of `cmd_bash`, `cmd_ps` and `cmd_bat`, if none of them are applicable. |
+
+If the command line length exceeds the platform limit (64K on Linux/macOS, 8K on Windows),
+then genrule will write the command to a script and execute that script to work around. This
+applies to all cmd attributes (`cmd`, `cmd_bash`, `cmd_ps`,
+`cmd_bat`).
+
+| `cmd_bash` | String; default is `""` The Bash command to run. This attribute has higher priority than `cmd`. The command is expanded and runs in the exact same way as the `cmd` attribute. |
+| `cmd_bat` | String; default is `""` The Batch command to run on Windows. This attribute has higher priority than `cmd` and `cmd_bash`. The command runs in the similar way as the `cmd` attribute, with the following differences:   * This attribute only applies on Windows. * The command runs with `cmd.exe /c` with the following default arguments:   + `/S` - strip first and last quotes and execute everything else as is.   + `/E:ON` - enable extended command set.   + `/V:ON` - enable delayed variable expansion   + `/D` - ignore AutoRun registry entries. * After [$(location)](/versions/9.1.0/reference/be/make-variables#predefined_label_variables) and   ["Make" variable](/versions/9.1.0/reference/be/make-variables) substitution, the paths will be   expanded to Windows style paths (with backslash). |
+| `cmd_ps` | String; default is `""` The Powershell command to run on Windows. This attribute has higher priority than `cmd`, `cmd_bash` and `cmd_bat`. The command runs in the similar way as the `cmd` attribute, with the following differences:   * This attribute only applies on Windows. * The command runs with `powershell.exe /c`.   To make Powershell easier to use and less error-prone, we run the following commands to set up the environment before executing Powershell command in genrule.   * `Set-ExecutionPolicy -Scope CurrentUser RemoteSigned` - allow running   unsigned scripts. * `$errorActionPreference='Stop'` - In case there are multiple commands   separated by `;`, the action exits immediately if a Powershell CmdLet fails,   but this does **NOT** work for external command. * `$PSDefaultParameterValues['*:Encoding'] = 'utf8'` - change the default   encoding from utf-16 to utf-8. |
+| `executable` | Boolean; [nonconfigurable](/versions/9.1.0/reference/be/common-definitions#configurable-attributes); default is `False` Declare output to be executable. Setting this flag to True means the output is an executable file and can be run using the `run` command. The genrule must produce exactly one output in this case. If this attribute is set, `run` will try executing the file regardless of its content.  Declaring data dependencies for the generated executable is not supported. |
+| `local` | Boolean; default is `False`  If set to True, this option forces this `genrule` to run using the "local" strategy, which means no remote execution, no sandboxing, no persistent workers.  This is equivalent to providing 'local' as a tag (`tags=["local"]`). |
+| `message` | String; default is `""` A progress message. A progress message that will be printed as this build step is executed. By default, the message is "Generating *output*" (or something equally bland) but you may provide a more specific one. Use this attribute instead of `echo` or other print statements in your `cmd` command, as this allows the build tool to control whether such progress messages are printed or not. |
+| `output_licenses` | List of strings; default is `[]` See [`common attributes`](/versions/9.1.0/reference/be/common-definitions#binary.output_licenses) |
+| `output_to_bindir` | Boolean; [nonconfigurable](/versions/9.1.0/reference/be/common-definitions#configurable-attributes); default is `False`  If set to True, this option causes output files to be written into the `bin` directory instead of the `genfiles` directory. |
+| `toolchains` | List of [labels](/versions/9.1.0/concepts/labels); [nonconfigurable](/versions/9.1.0/reference/be/common-definitions#configurable-attributes); default is `[]`  The set of targets whose [Make variables](/versions/9.1.0/reference/be/make-variables) this genrule is allowed to access, or the [`toolchain_type`](/versions/9.1.0/docs/toolchains) targets that this genrule will access.  Toolchains accessed via `toolchain_type` must also provide a `TemplateVariableInfo` provider, which the target can use to access toolchain details. |
+| `tools` | List of [labels](/versions/9.1.0/concepts/labels); default is `[]` A list of *tool* dependencies for this rule. See the definition of [dependencies](/versions/9.1.0/concepts/build-ref#deps) for more information.   The build system ensures these prerequisites are built before running the genrule command; they are built using the [*exec* configuration](/versions/9.1.0/contribute/guide#configurations), since these tools are executed as part of the build. The path of an individual `tools` target `//x:y` can be obtained using `$(location //x:y)`.  Any `*_binary` or tool to be executed by `cmd` must appear in this list, not in `srcs`, to ensure they are built in the correct configuration. |
+
+## starlark_doc_extract
+
+[View rule sourceopen_in_new](https://github.com/bazelbuild/bazel/blob/master/src/main/java/com/google/devtools/build/lib/rules/starlarkdocextract/StarlarkDocExtractRule.java)
+
+```
+starlark_doc_extract(name, deps, src, data, allow_unused_doc_comments, aspect_hints, compatible_with, deprecation, exec_compatible_with, exec_group_compatible_with, exec_properties, features, licenses, package_metadata, render_main_repo_name, restricted_to, symbol_names, tags, target_compatible_with, testonly, visibility)
+```
+
+`starlark_doc_extract()` extracts documentation for rules, functions (including
+macros), aspects, and providers defined or re-exported in a given `.bzl` or
+`.scl` file. The output of this rule is a `ModuleInfo` binary proto as defined
+in
+[stardoc_output.proto](https://github.com/bazelbuild/bazel/blob/master/src/main/protobuf/stardoc_output.proto)
+in the Bazel source tree.
+
+#### Implicit output targets
+
+* `name.binaryproto` (the default output): A
+  `ModuleInfo` binary proto.
+* `name.textproto` (only built if explicitly requested): the text
+  proto version of `name.binaryproto`.
+
+Note: the exact output of this rule is not a stable public API. For example, the set of
+natively-defined common rule attributes and their docstrings may change even with minor Bazel
+releases. For this reason, documentation generated for user-defined rules is not stable across Bazel
+releases, so we suggest taking care that any "golden tests" based on outputs of this rule are only
+run with a single Bazel version.
+
+### Arguments
+
+| Attributes | |
+| --- | --- |
+| `name` | [Name](/versions/9.1.0/concepts/labels#target-names); required  A unique name for this target. |
+| `deps` | List of [labels](/versions/9.1.0/concepts/labels); default is `[]` A list of targets wrapping the Starlark files which are `load()`-ed by `src`. These targets *should* under normal usage be [`bzl_library`](https://github.com/bazelbuild/bazel-skylib/blob/main/bzl_library.bzl) targets, but the `starlark_doc_extract` rule does not enforce that, and accepts any target which provides Starlark files in its `DefaultInfo`. Note that the wrapped Starlark files must be files in the source tree; Bazel cannot `load()` generated files. |
+| `src` | [Label](/versions/9.1.0/concepts/labels); required A Starlark file from which to extract documentation. Note that this must be a file in the source tree; Bazel cannot `load()` generated files. |
+| `allow_unused_doc_comments` | Boolean; default is `False` If true, allow and silently ignore doc comments (comments starting with `#:`) which are not attached to any global variable, or which are attached to a variable whose value's documentation should be provided in a different way (for example, in a docstring for a function, or via `rule(doc = ...)` for a rule). |
+| `render_main_repo_name` | Boolean; default is `False` If true, render labels in the main repository in emitted documentation with a repo component (in other words, `//foo:bar.bzl` will be emitted as `@main_repo_name//foo:bar.bzl`). The name to use for the main repository is obtained from `module(name = ...)` in the main repository's `MODULE.bazel` file (if Bzlmod is enabled), or from `workspace(name = ...)` in the main repository's `WORKSPACE` file. This attribute should be set to `False` when generating documentation for Starlark files which are intended to be used only within the same repository, and to `True` when generating documentation for Starlark files which are intended to be used from other repositories. |
+| `symbol_names` | List of strings; default is `[]` An optional list of qualified names of exported functions, rules, providers, or aspects (or structs in which they are nested) for which to extract documentation. Here, a *qualified name* means the name under which an entity is made available to a user of the module, including any structs in which the entity is nested for namespacing. `starlark_doc_extract` emits documentation for an entity if and only if  1. each component of the entity's qualified name is public (in other words, the first    character of each component of the qualified name is alphabetic, not `"_"`);    *and* 2. 1. *either* the `symbol_names` list is empty (which is the default       case), *or*    2. the entity's qualified name, or the qualified name of a struct in which the entity       is nested, is in the `symbol_names` list. |
+
+## test_suite
+
+[View rule sourceopen_in_new](https://github.com/bazelbuild/bazel/blob/master/src/main/java/com/google/devtools/build/lib/rules/test/TestSuiteRule.java)
+
+```
+test_suite(name, aspect_hints, compatible_with, deprecation, features, licenses, package_metadata, restricted_to, tags, target_compatible_with, testonly, tests, visibility)
+```
+
+A `test_suite` defines a set of tests that are considered "useful" to humans. This
+allows projects to define sets of tests, such as "tests you must run before checkin", "our
+project's stress tests" or "all small tests." The `bazel test` command respects this sort
+of organization: For an invocation like `bazel test //some/test:suite`, Bazel first
+enumerates all test targets transitively included by the `//some/test:suite` target (we
+call this "test_suite expansion"), then Bazel builds and tests those targets.
+
+#### Examples
+
+A test suite to run all of the small tests in the current package.
+
+```
+test_suite(
+    name = "small_tests",
+    tags = ["small"],
+)
+```
+
+A test suite that runs a specified set of tests:
+
+```
+test_suite(
+    name = "smoke_tests",
+    tests = [
+        "system_unittest",
+        "public_api_unittest",
+    ],
+)
+```
+
+A test suite to run all tests in the current package which are not flaky.
+
+```
+test_suite(
+    name = "non_flaky_test",
+    tags = ["-flaky"],
+)
+```
+
+### Arguments
+
+| Attributes | |
+| --- | --- |
+| `name` | [Name](/versions/9.1.0/concepts/labels#target-names); required  A unique name for this target. |
+| `tags` | List of strings; [nonconfigurable](/versions/9.1.0/reference/be/common-definitions#configurable-attributes); default is `[]` List of text tags such as "small" or "database" or "-flaky". Tags may be any valid string. Tags which begin with a "-" character are considered negative tags. The preceding "-" character is not considered part of the tag, so a suite tag of "-small" matches a test's "small" size. All other tags are considered positive tags.  Optionally, to make positive tags more explicit, tags may also begin with the "+" character, which will not be evaluated as part of the text of the tag. It merely makes the positive and negative distinction easier to read.  Only test rules that match **all** of the positive tags and **none** of the negative tags will be included in the test suite. Note that this does not mean that error checking for dependencies on tests that are filtered out is skipped; the dependencies on skipped tests still need to be legal (e.g. not blocked by visibility constraints).  The `manual` tag keyword is treated differently than the above by the "test_suite expansion" performed by the `bazel test` command on invocations involving wildcard [target patterns](https://bazel.build/versions/9.1.0/docs/build#specifying-build-targets). There, `test_suite` targets tagged "manual" are filtered out (and thus not expanded). This behavior is consistent with how `bazel build` and `bazel test` handle wildcard target patterns in general. Note that this is explicitly different from how `bazel query 'tests(E)'` behaves, as suites are always expanded by the `tests` query function, regardless of the `manual` tag.  Note that a test's `size` is considered a tag for the purpose of filtering.  If you need a `test_suite` that contains tests with mutually exclusive tags (e.g. all small and medium tests), you'll have to create three `test_suite` rules: one for all small tests, one for all medium tests, and one that includes the previous two. |
+| `tests` | List of [labels](/versions/9.1.0/concepts/labels); [nonconfigurable](/versions/9.1.0/reference/be/common-definitions#configurable-attributes); default is `[]` A list of test suites and test targets of any language. Any `*_test` is accepted here, independent of the language. No `*_binary` targets are accepted however, even if they happen to run a test. Filtering by the specified `tags` is only done for tests listed directly in this attribute. If this attribute contains `test_suite`s, the tests inside those will not be filtered by this `test_suite` (they are considered to be filtered already).  If the `tests` attribute is unspecified or empty, the rule will default to including all test rules in the current BUILD file that are not tagged as `manual`. These rules are still subject to `tag` filtering. |
\ No newline at end of file
diff --git a/versions/9.1.0/reference/be/java.mdx b/versions/9.1.0/reference/be/java.mdx
new file mode 100644
index 00000000..2c4fa1e0
--- /dev/null
+++ b/versions/9.1.0/reference/be/java.mdx
@@ -0,0 +1,531 @@
+---
+title: 'Java Rules'
+---
+
+## Rules
+
+* [java_binary](#java_binary)
+* [java_import](#java_import)
+* [java_library](#java_library)
+* [java_test](#java_test)
+* [java_package_configuration](#java_package_configuration)
+* [java_plugin](#java_plugin)
+* [java_runtime](#java_runtime)
+* [java_single_jar](#java_single_jar)
+* [java_toolchain](#java_toolchain)
+
+## java_binary
+
+[View rule sourceopen_in_new](https://github.com/bazelbuild/rules_java/blob/master/java/bazel/rules/bazel_java_binary.bzl)
+
+```
+java_binary(name, deps, srcs, data, resources, add_exports, add_opens, args, aspect_hints, bootclasspath, classpath_resources, compatible_with, create_executable, deploy_env, deploy_manifest_lines, deprecation, env, exec_compatible_with, exec_group_compatible_with, exec_properties, features, javacopts, jvm_flags, launcher, licenses, main_class, neverlink, output_licenses, package_metadata, plugins, resource_strip_prefix, restricted_to, runtime_deps, stamp, tags, target_compatible_with, testonly, toolchains, use_launcher, use_testrunner, visibility)
+```
+
+Builds a Java archive ("jar file"), plus a wrapper shell script with the same name as the rule.
+The wrapper shell script uses a classpath that includes, among other things, a jar file for each
+library on which the binary depends. When running the wrapper shell script, any nonempty
+`JAVABIN` environment variable will take precedence over the version specified via
+Bazel's `--java_runtime_version` flag.
+
+The wrapper script accepts several unique flags. Refer to
+`java_stub_template.txt`
+for a list of configurable flags and environment variables accepted by the wrapper.
+
+#### Implicit output targets
+
+* `name.jar`: A Java archive, containing the class files and other
+  resources corresponding to the binary's direct dependencies.
+* `name-src.jar`: An archive containing the sources ("source
+  jar").
+* `name_deploy.jar`: A Java archive suitable for deployment (only
+  built if explicitly requested).
+
+  Building the `<name>_deploy.jar` target for your rule
+  creates a self-contained jar file with a manifest that allows it to be run with the
+  `java -jar` command or with the wrapper script's `--singlejar`
+  option. Using the wrapper script is preferred to `java -jar` because it
+  also passes the [JVM flags](#java_binary-jvm_flags) and the options
+  to load native libraries.
+
+  The deploy jar contains all the classes that would be found by a classloader that
+  searched the classpath from the binary's wrapper script from beginning to end. It also
+  contains the native libraries needed for dependencies. These are automatically loaded
+  into the JVM at runtime.
+
+  If your target specifies a [launcher](#java_binary.launcher)
+  attribute, then instead of being a normal JAR file, the \_deploy.jar will be a
+  native binary. This will contain the launcher plus any native (C++) dependencies of
+  your rule, all linked into a static binary. The actual jar file's bytes will be
+  appended to that native binary, creating a single binary blob containing both the
+  executable and the Java code. You can execute the resulting jar file directly
+  like you would execute any native binary.
+* `name_deploy-src.jar`: An archive containing the sources
+  collected from the transitive closure of the target. These will match the classes in the
+  `deploy.jar` except where jars have no matching source jar.
+
+It is good practice to use the name of the source file that is the main entry point of the
+application (minus the extension). For example, if your entry point is called
+`Main.java`, then your name could be `Main`.
+
+A `deps` attribute is not allowed in a `java_binary` rule without
+[`srcs`](#java_binary-srcs); such a rule requires a
+[`main_class`](#java_binary-main_class) provided by
+[`runtime_deps`](#java_binary-runtime_deps).
+
+The following code snippet illustrates a common mistake:
+
+```
+java_binary(
+    name = "DontDoThis",
+    srcs = [
+        ...,
+        "GeneratedJavaFile.java",  # a generated .java file
+    ],
+    deps = [":generating_rule",],  # rule that generates that file
+)
+```
+
+Do this instead:
+
+```
+java_binary(
+    name = "DoThisInstead",
+    srcs = [
+        ...,
+        ":generating_rule",
+    ],
+)
+```
+
+### Arguments
+
+| Attributes | |
+| --- | --- |
+| `name` | [Name](/versions/9.1.0/concepts/labels#target-names); required  A unique name for this target. |
+| `deps` | List of [labels](/versions/9.1.0/concepts/labels); default is `[]` The list of other libraries to be linked in to the target. See general comments about `deps` at [Typical attributes defined by most build rules](/versions/9.1.0/reference/be/common-definitions#typical-attributes). |
+| `srcs` | List of [labels](/versions/9.1.0/concepts/labels); default is `[]` The list of source files that are processed to create the target. This attribute is almost always required; see exceptions below. Source files of type `.java` are compiled. In case of generated `.java` files it is generally advisable to put the generating rule's name here instead of the name of the file itself. This not only improves readability but makes the rule more resilient to future changes: if the generating rule generates different files in the future, you only need to fix one place: the `outs` of the generating rule. You should not list the generating rule in `deps` because it is a no-op.  Source files of type `.srcjar` are unpacked and compiled. (This is useful if you need to generate a set of `.java` files with a genrule.)  Rules: if the rule (typically `genrule` or `filegroup`) generates any of the files listed above, they will be used the same way as described for source files.  This argument is almost always required, except if a [`main_class`](#java_binary.main_class) attribute specifies a class on the runtime classpath or you specify the `runtime_deps` argument. |
+| `data` | List of [labels](/versions/9.1.0/concepts/labels); default is `[]` The list of files needed by this library at runtime. See general comments about `data` at [Typical attributes defined by most build rules](/versions/9.1.0/reference/be/common-definitions#typical-attributes). |
+| `resources` | List of [labels](/versions/9.1.0/concepts/labels); default is `[]` A list of data files to include in a Java jar. Resources may be source files or generated files.  If resources are specified, they will be bundled in the jar along with the usual `.class` files produced by compilation. The location of the resources inside of the jar file is determined by the project structure. Bazel first looks for Maven's [standard directory layout](https://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html), (a "src" directory followed by a "resources" directory grandchild). If that is not found, Bazel then looks for the topmost directory named "java" or "javatests" (so, for example, if a resource is at `<workspace root>/x/java/y/java/z`, the path of the resource will be `y/java/z`. This heuristic cannot be overridden, however, the `resource_strip_prefix` attribute can be used to specify a specific alternative directory for resource files. |
+| `add_exports` | List of strings; default is `[]` Allow this library to access the given `module` or `package`. This corresponds to the javac and JVM --add-exports= flags. |
+| `add_opens` | List of strings; default is `[]` Allow this library to reflectively access the given `module` or `package`. This corresponds to the javac and JVM --add-opens= flags. |
+| `bootclasspath` | [Label](/versions/9.1.0/concepts/labels); default is `None` Restricted API, do not use! |
+| `classpath_resources` | List of [labels](/versions/9.1.0/concepts/labels); default is `[]` *DO NOT USE THIS OPTION UNLESS THERE IS NO OTHER WAY* A list of resources that must be located at the root of the java tree. This attribute's only purpose is to support third-party libraries that require that their resources be found on the classpath as exactly `"myconfig.xml"`. It is only allowed on binaries and not libraries, due to the danger of namespace conflicts. |
+| `create_executable` | Boolean; default is `True` Deprecated, use `java_single_jar` instead. |
+| `deploy_env` | List of [labels](/versions/9.1.0/concepts/labels); default is `[]` A list of other `java_binary` targets which represent the deployment environment for this binary. Set this attribute when building a plugin which will be loaded by another `java_binary`.  Setting this attribute excludes all dependencies from the runtime classpath (and the deploy jar) of this binary that are shared between this binary and the targets specified in `deploy_env`. |
+| `deploy_manifest_lines` | List of strings; default is `[]` A list of lines to add to the `META-INF/manifest.mf` file generated for the `*_deploy.jar` target. The contents of this attribute are *not* subject to ["Make variable"](/versions/9.1.0/reference/be/make-variables) substitution. |
+| `javacopts` | List of strings; default is `[]` Extra compiler options for this binary. Subject to ["Make variable"](/versions/9.1.0/reference/be/make-variables) substitution and [Bourne shell tokenization](/versions/9.1.0/reference/be/common-definitions#sh-tokenization). These compiler options are passed to javac after the global compiler options. |
+| `jvm_flags` | List of strings; default is `[]` A list of flags to embed in the wrapper script generated for running this binary. Subject to [$(location)](/versions/9.1.0/reference/be/make-variables#location) and ["Make variable"](/versions/9.1.0/reference/be/make-variables) substitution, and [Bourne shell tokenization](/versions/9.1.0/reference/be/common-definitions#sh-tokenization). The wrapper script for a Java binary includes a CLASSPATH definition (to find all the dependent jars) and invokes the right Java interpreter. The command line generated by the wrapper script includes the name of the main class followed by a `"$@"` so you can pass along other arguments after the classname. However, arguments intended for parsing by the JVM must be specified *before* the classname on the command line. The contents of `jvm_flags` are added to the wrapper script before the classname is listed.  Note that this attribute has *no effect* on `*_deploy.jar` outputs. |
+| `launcher` | [Label](/versions/9.1.0/concepts/labels); default is `None` Specify a binary that will be used to run your Java program instead of the normal `bin/java` program included with the JDK. The target must be a `cc_binary`. Any `cc_binary` that implements the [Java Invocation API](http://docs.oracle.com/javase/7/docs/technotes/guides/jni/spec/invocation.html) can be specified as a value for this attribute. By default, Bazel will use the normal JDK launcher (bin/java or java.exe).  The related [`--java_launcher`](/versions/9.1.0/docs/user-manual#flag--java_launcher) Bazel flag affects only those `java_binary` and `java_test` targets that have *not* specified a `launcher` attribute.  Note that your native (C++, SWIG, JNI) dependencies will be built differently depending on whether you are using the JDK launcher or another launcher:   * If you are using the normal JDK launcher (the default), native dependencies are   built as a shared library named `{name}_nativedeps.so`, where   `{name}` is the `name` attribute of this java_binary rule.   Unused code is *not* removed by the linker in this configuration. * If you are using any other launcher, native (C++) dependencies are statically   linked into a binary named `{name}_nativedeps`, where `{name}`   is the `name` attribute of this java_binary rule. In this case,   the linker will remove any code it thinks is unused from the resulting binary,   which means any C++ code accessed only via JNI may not be linked in unless   that `cc_library` target specifies `alwayslink = True`.   When using any launcher other than the default JDK launcher, the format of the `*_deploy.jar` output changes. See the main [java_binary](#java_binary) docs for details. |
+| `main_class` | String; default is `""` Name of class with `main()` method to use as entry point. If a rule uses this option, it does not need a `srcs=[...]` list. Thus, with this attribute one can make an executable from a Java library that already contains one or more `main()` methods. The value of this attribute is a class name, not a source file. The class must be available at runtime: it may be compiled by this rule (from `srcs`) or provided by direct or transitive dependencies (through `runtime_deps` or `deps`). If the class is unavailable, the binary will fail at runtime; there is no build-time check. |
+| `neverlink` | Boolean; default is `False` |
+| `plugins` | List of [labels](/versions/9.1.0/concepts/labels); default is `[]` Java compiler plugins to run at compile-time. Every `java_plugin` specified in this attribute will be run whenever this rule is built. A library may also inherit plugins from dependencies that use `exported_plugins`. Resources generated by the plugin will be included in the resulting jar of this rule. |
+| `resource_strip_prefix` | String; default is `""` The path prefix to strip from Java resources. If specified, this path prefix is stripped from every file in the `resources` attribute. It is an error for a resource file not to be under this directory. If not specified (the default), the path of resource file is determined according to the same logic as the Java package of source files. For example, a source file at `stuff/java/foo/bar/a.txt` will be located at `foo/bar/a.txt`. |
+| `runtime_deps` | List of [labels](/versions/9.1.0/concepts/labels); default is `[]` Libraries to make available to the final binary or test at runtime only. Like ordinary `deps`, these will appear on the runtime classpath, but unlike them, not on the compile-time classpath. Dependencies needed only at runtime should be listed here. Dependency-analysis tools should ignore targets that appear in both `runtime_deps` and `deps`. |
+| `stamp` | Integer; default is `-1` Whether to encode build information into the binary. Possible values:  * `stamp = 1`: Always stamp the build information into the binary, even in   [`--nostamp`](/versions/9.1.0/docs/user-manual#flag--stamp) builds. **This   setting should be avoided**, since it potentially kills remote caching for the   binary and any downstream actions that depend on it. * `stamp = 0`: Always replace build information by constant values. This   gives good build result caching. * `stamp = -1`: Embedding of build information is controlled by the   [`--[no]stamp`](/versions/9.1.0/docs/user-manual#flag--stamp) flag.   Stamped binaries are *not* rebuilt unless their dependencies change. |
+| `use_launcher` | Boolean; default is `True` Whether the binary should use a custom launcher. If this attribute is set to false, the [launcher](/versions/9.1.0/reference/be/java#java_binary.launcher) attribute and the related [`--java_launcher`](/versions/9.1.0/docs/user-manual#flag--java_launcher) flag will be ignored for this target. |
+| `use_testrunner` | Boolean; default is `False` Use the test runner (by default `com.google.testing.junit.runner.BazelTestRunner`) class as the main entry point for a Java program, and provide the test class to the test runner as a value of `bazel.test_suite` system property.   You can use this to override the default behavior, which is to use test runner for `java_test` rules, and not use it for `java_binary` rules. It is unlikely you will want to do this. One use is for `AllTest` rules that are invoked by another rule (to set up a database before running the tests, for example). The `AllTest` rule must be declared as a `java_binary`, but should still use the test runner as its main entry point. The name of a test runner class can be overridden with `main_class` attribute. |
+
+## java_import
+
+[View rule sourceopen_in_new](https://github.com/bazelbuild/rules_java/blob/master/java/bazel/rules/bazel_java_import.bzl)
+
+```
+java_import(name, deps, data, add_exports, add_opens, aspect_hints, compatible_with, constraints, deprecation, exec_compatible_with, exec_group_compatible_with, exec_properties, exports, features, jars, licenses, neverlink, package_metadata, proguard_specs, restricted_to, runtime_deps, srcjar, tags, target_compatible_with, testonly, toolchains, visibility)
+```
+
+This rule allows the use of precompiled `.jar` files as
+libraries for `java_library` and
+`java_binary` rules.
+
+#### Examples
+
+```
+    java_import(
+        name = "maven_model",
+        jars = [
+            "maven_model/maven-aether-provider-3.2.3.jar",
+            "maven_model/maven-model-3.2.3.jar",
+            "maven_model/maven-model-builder-3.2.3.jar",
+        ],
+    )
+```
+
+### Arguments
+
+| Attributes | |
+| --- | --- |
+| `name` | [Name](/versions/9.1.0/concepts/labels#target-names); required  A unique name for this target. |
+| `deps` | List of [labels](/versions/9.1.0/concepts/labels); default is `[]` The list of other libraries to be linked in to the target. See [java_library.deps](/versions/9.1.0/reference/be/java#java_library.deps). |
+| `data` | List of [labels](/versions/9.1.0/concepts/labels); default is `[]` The list of files needed by this rule at runtime. |
+| `add_exports` | List of strings; default is `[]` Allow this library to access the given `module` or `package`. This corresponds to the javac and JVM --add-exports= flags. |
+| `add_opens` | List of strings; default is `[]` Allow this library to reflectively access the given `module` or `package`. This corresponds to the javac and JVM --add-opens= flags. |
+| `constraints` | List of strings; default is `[]` Extra constraints imposed on this rule as a Java library. |
+| `exports` | List of [labels](/versions/9.1.0/concepts/labels); default is `[]` Targets to make available to users of this rule. See [java_library.exports](/versions/9.1.0/reference/be/java#java_library.exports). |
+| `jars` | List of [labels](/versions/9.1.0/concepts/labels); required The list of JAR files provided to Java targets that depend on this target. |
+| `neverlink` | Boolean; default is `False` Only use this library for compilation and not at runtime. Useful if the library will be provided by the runtime environment during execution. Examples of libraries like this are IDE APIs for IDE plug-ins or `tools.jar` for anything running on a standard JDK. |
+| `proguard_specs` | List of [labels](/versions/9.1.0/concepts/labels); default is `[]` Files to be used as Proguard specification. These will describe the set of specifications to be used by Proguard. If specified, they will be added to any `android_binary` target depending on this library. The files included here must only have idempotent rules, namely -dontnote, -dontwarn, assumenosideeffects, and rules that start with -keep. Other options can only appear in `android_binary`'s proguard_specs, to ensure non-tautological merges. |
+| `runtime_deps` | List of [labels](/versions/9.1.0/concepts/labels); default is `[]` Libraries to make available to the final binary or test at runtime only. See [java_library.runtime_deps](/versions/9.1.0/reference/be/java#java_library.runtime_deps). |
+| `srcjar` | [Label](/versions/9.1.0/concepts/labels); default is `None` A JAR file that contains source code for the compiled JAR files. |
+
+## java_library
+
+[View rule sourceopen_in_new](https://github.com/bazelbuild/rules_java/blob/master/java/bazel/rules/bazel_java_library.bzl)
+
+```
+java_library(name, deps, srcs, data, resources, add_exports, add_opens, aspect_hints, bootclasspath, compatible_with, deprecation, exec_compatible_with, exec_group_compatible_with, exec_properties, exported_plugins, exports, features, javabuilder_jvm_flags, javacopts, licenses, neverlink, package_metadata, plugins, proguard_specs, resource_strip_prefix, restricted_to, runtime_deps, tags, target_compatible_with, testonly, toolchains, visibility)
+```
+
+This rule compiles and links sources into a `.jar` file.
+
+#### Implicit outputs
+
+* `libname.jar`: A Java archive containing the class files.
+* `libname-src.jar`: An archive containing the sources ("source
+  jar").
+
+### Arguments
+
+| Attributes | |
+| --- | --- |
+| `name` | [Name](/versions/9.1.0/concepts/labels#target-names); required  A unique name for this target. |
+| `deps` | List of [labels](/versions/9.1.0/concepts/labels); default is `[]` The list of libraries to link into this library. See general comments about `deps` at [Typical attributes defined by most build rules](/versions/9.1.0/reference/be/common-definitions#typical-attributes). The jars built by `java_library` rules listed in `deps` will be on the compile-time classpath of this rule. Furthermore the transitive closure of their `deps`, `runtime_deps` and `exports` will be on the runtime classpath.  By contrast, targets in the `data` attribute are included in the runfiles but on neither the compile-time nor runtime classpath. |
+| `srcs` | List of [labels](/versions/9.1.0/concepts/labels); default is `[]` The list of source files that are processed to create the target. This attribute is almost always required; see exceptions below. Source files of type `.java` are compiled. In case of generated `.java` files it is generally advisable to put the generating rule's name here instead of the name of the file itself. This not only improves readability but makes the rule more resilient to future changes: if the generating rule generates different files in the future, you only need to fix one place: the `outs` of the generating rule. You should not list the generating rule in `deps` because it is a no-op.  Source files of type `.srcjar` are unpacked and compiled. (This is useful if you need to generate a set of `.java` files with a genrule.)  Rules: if the rule (typically `genrule` or `filegroup`) generates any of the files listed above, they will be used the same way as described for source files.  Source files of type `.properties` are treated as resources.  All other files are ignored, as long as there is at least one file of a file type described above. Otherwise an error is raised.  This argument is almost always required, except if you specify the `runtime_deps` argument. |
+| `data` | List of [labels](/versions/9.1.0/concepts/labels); default is `[]` The list of files needed by this library at runtime. See general comments about `data` at [Typical attributes defined by most build rules](/versions/9.1.0/reference/be/common-definitions#typical-attributes). When building a `java_library`, Bazel doesn't put these files anywhere; if the `data` files are generated files then Bazel generates them. When building a test that depends on this `java_library` Bazel copies or links the `data` files into the runfiles area. |
+| `resources` | List of [labels](/versions/9.1.0/concepts/labels); default is `[]` A list of data files to include in a Java jar. Resources may be source files or generated files.  If resources are specified, they will be bundled in the jar along with the usual `.class` files produced by compilation. The location of the resources inside of the jar file is determined by the project structure. Bazel first looks for Maven's [standard directory layout](https://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html), (a "src" directory followed by a "resources" directory grandchild). If that is not found, Bazel then looks for the topmost directory named "java" or "javatests" (so, for example, if a resource is at `<workspace root>/x/java/y/java/z`, the path of the resource will be `y/java/z`. This heuristic cannot be overridden, however, the `resource_strip_prefix` attribute can be used to specify a specific alternative directory for resource files. |
+| `add_exports` | List of strings; default is `[]` Allow this library to access the given `module` or `package`. This corresponds to the javac and JVM --add-exports= flags. |
+| `add_opens` | List of strings; default is `[]` Allow this library to reflectively access the given `module` or `package`. This corresponds to the javac and JVM --add-opens= flags. |
+| `bootclasspath` | [Label](/versions/9.1.0/concepts/labels); default is `None` Restricted API, do not use! |
+| `exported_plugins` | List of [labels](/versions/9.1.0/concepts/labels); default is `[]` The list of `java_plugin`s (e.g. annotation processors) to export to libraries that directly depend on this library. The specified list of `java_plugin`s will be applied to any library which directly depends on this library, just as if that library had explicitly declared these labels in `plugins`. |
+| `exports` | List of [labels](/versions/9.1.0/concepts/labels); default is `[]` Exported libraries. Listing rules here will make them available to parent rules, as if the parents explicitly depended on these rules. This is not true for regular (non-exported) `deps`.  Summary: a rule *X* can access the code in *Y* if there exists a dependency path between them that begins with a `deps` edge followed by zero or more `exports` edges. Let's see some examples to illustrate this.  Assume *A* depends on *B* and *B* depends on *C*. In this case C is a *transitive* dependency of A, so changing C's sources and rebuilding A will correctly rebuild everything. However A will not be able to use classes in C. To allow that, either A has to declare C in its `deps`, or B can make it easier for A (and anything that may depend on A) by declaring C in its (B's) `exports` attribute.  The closure of exported libraries is available to all direct parent rules. Take a slightly different example: A depends on B, B depends on C and D, and also exports C but not D. Now A has access to C but not to D. Now, if C and D exported some libraries, C' and D' respectively, A could only access C' but not D'.  Important: an exported rule is not a regular dependency. Sticking to the previous example, if B exports C and wants to also use C, it has to also list it in its own `deps`. |
+| `javabuilder_jvm_flags` | List of strings; default is `[]` Restricted API, do not use! |
+| `javacopts` | List of strings; default is `[]` Extra compiler options for this library. Subject to ["Make variable"](/versions/9.1.0/reference/be/make-variables) substitution and [Bourne shell tokenization](/versions/9.1.0/reference/be/common-definitions#sh-tokenization). These compiler options are passed to javac after the global compiler options. |
+| `neverlink` | Boolean; default is `False` Whether this library should only be used for compilation and not at runtime. Useful if the library will be provided by the runtime environment during execution. Examples of such libraries are the IDE APIs for IDE plug-ins or `tools.jar` for anything running on a standard JDK. Note that `neverlink = True` does not prevent the compiler from inlining material from this library into compilation targets that depend on it, as permitted by the Java Language Specification (e.g., `static final` constants of `String` or of primitive types). The preferred use case is therefore when the runtime library is identical to the compilation library.  If the runtime library differs from the compilation library then you must ensure that it differs only in places that the JLS forbids compilers to inline (and that must hold for all future versions of the JLS). |
+| `plugins` | List of [labels](/versions/9.1.0/concepts/labels); default is `[]` Java compiler plugins to run at compile-time. Every `java_plugin` specified in this attribute will be run whenever this rule is built. A library may also inherit plugins from dependencies that use `exported_plugins`. Resources generated by the plugin will be included in the resulting jar of this rule. |
+| `proguard_specs` | List of [labels](/versions/9.1.0/concepts/labels); default is `[]` Files to be used as Proguard specification. These will describe the set of specifications to be used by Proguard. If specified, they will be added to any `android_binary` target depending on this library. The files included here must only have idempotent rules, namely -dontnote, -dontwarn, assumenosideeffects, and rules that start with -keep. Other options can only appear in `android_binary`'s proguard_specs, to ensure non-tautological merges. |
+| `resource_strip_prefix` | String; default is `""` The path prefix to strip from Java resources. If specified, this path prefix is stripped from every file in the `resources` attribute. It is an error for a resource file not to be under this directory. If not specified (the default), the path of resource file is determined according to the same logic as the Java package of source files. For example, a source file at `stuff/java/foo/bar/a.txt` will be located at `foo/bar/a.txt`. |
+| `runtime_deps` | List of [labels](/versions/9.1.0/concepts/labels); default is `[]` Libraries to make available to the final binary or test at runtime only. Like ordinary `deps`, these will appear on the runtime classpath, but unlike them, not on the compile-time classpath. Dependencies needed only at runtime should be listed here. Dependency-analysis tools should ignore targets that appear in both `runtime_deps` and `deps`. |
+
+## java_test
+
+[View rule sourceopen_in_new](https://github.com/bazelbuild/rules_java/blob/master/java/bazel/rules/bazel_java_test.bzl)
+
+```
+java_test(name, deps, srcs, data, resources, add_exports, add_opens, args, aspect_hints, bootclasspath, classpath_resources, compatible_with, create_executable, deploy_manifest_lines, deprecation, env, env_inherit, exec_compatible_with, exec_group_compatible_with, exec_properties, features, flaky, javacopts, jvm_flags, launcher, licenses, local, main_class, neverlink, package_metadata, plugins, resource_strip_prefix, restricted_to, runtime_deps, shard_count, size, stamp, tags, target_compatible_with, test_class, testonly, timeout, toolchains, use_launcher, use_testrunner, visibility)
+```
+
+A `java_test()` rule compiles a Java test. A test is a binary wrapper around your
+test code. The test runner's main method is invoked instead of the main class being compiled.
+
+#### Implicit output targets
+
+* `name.jar`: A Java archive.
+* `name_deploy.jar`: A Java archive suitable
+  for deployment. (Only built if explicitly requested.) See the description of the
+  `name_deploy.jar` output from
+  [java_binary](#java_binary) for more details.
+
+See the section on `java_binary()` arguments. This rule also
+supports all [attributes common
+to all test rules (\*\_test)](https://bazel.build/versions/9.1.0/reference/be/common-definitions#common-attributes-tests).
+
+#### Examples
+
+```
+java_library(
+    name = "tests",
+    srcs = glob(["*.java"]),
+    deps = [
+        "//java/com/foo/base:testResources",
+        "//java/com/foo/testing/util",
+    ],
+)
+
+java_test(
+    name = "AllTests",
+    size = "small",
+    runtime_deps = [
+        ":tests",
+        "//util/mysql",
+    ],
+)
+```
+
+### Arguments
+
+| Attributes | |
+| --- | --- |
+| `name` | [Name](/versions/9.1.0/concepts/labels#target-names); required  A unique name for this target. |
+| `deps` | List of [labels](/versions/9.1.0/concepts/labels); default is `[]` The list of other libraries to be linked in to the target. See general comments about `deps` at [Typical attributes defined by most build rules](/versions/9.1.0/reference/be/common-definitions#typical-attributes). |
+| `srcs` | List of [labels](/versions/9.1.0/concepts/labels); default is `[]` The list of source files that are processed to create the target. This attribute is almost always required; see exceptions below. Source files of type `.java` are compiled. In case of generated `.java` files it is generally advisable to put the generating rule's name here instead of the name of the file itself. This not only improves readability but makes the rule more resilient to future changes: if the generating rule generates different files in the future, you only need to fix one place: the `outs` of the generating rule. You should not list the generating rule in `deps` because it is a no-op.  Source files of type `.srcjar` are unpacked and compiled. (This is useful if you need to generate a set of `.java` files with a genrule.)  Rules: if the rule (typically `genrule` or `filegroup`) generates any of the files listed above, they will be used the same way as described for source files.  This argument is almost always required, except if a [`main_class`](#java_binary.main_class) attribute specifies a class on the runtime classpath or you specify the `runtime_deps` argument. |
+| `data` | List of [labels](/versions/9.1.0/concepts/labels); default is `[]` The list of files needed by this library at runtime. See general comments about `data` at [Typical attributes defined by most build rules](/versions/9.1.0/reference/be/common-definitions#typical-attributes). |
+| `resources` | List of [labels](/versions/9.1.0/concepts/labels); default is `[]` A list of data files to include in a Java jar. Resources may be source files or generated files.  If resources are specified, they will be bundled in the jar along with the usual `.class` files produced by compilation. The location of the resources inside of the jar file is determined by the project structure. Bazel first looks for Maven's [standard directory layout](https://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html), (a "src" directory followed by a "resources" directory grandchild). If that is not found, Bazel then looks for the topmost directory named "java" or "javatests" (so, for example, if a resource is at `<workspace root>/x/java/y/java/z`, the path of the resource will be `y/java/z`. This heuristic cannot be overridden, however, the `resource_strip_prefix` attribute can be used to specify a specific alternative directory for resource files. |
+| `add_exports` | List of strings; default is `[]` Allow this library to access the given `module` or `package`. This corresponds to the javac and JVM --add-exports= flags. |
+| `add_opens` | List of strings; default is `[]` Allow this library to reflectively access the given `module` or `package`. This corresponds to the javac and JVM --add-opens= flags. |
+| `bootclasspath` | [Label](/versions/9.1.0/concepts/labels); default is `None` Restricted API, do not use! |
+| `classpath_resources` | List of [labels](/versions/9.1.0/concepts/labels); default is `[]` *DO NOT USE THIS OPTION UNLESS THERE IS NO OTHER WAY* A list of resources that must be located at the root of the java tree. This attribute's only purpose is to support third-party libraries that require that their resources be found on the classpath as exactly `"myconfig.xml"`. It is only allowed on binaries and not libraries, due to the danger of namespace conflicts. |
+| `create_executable` | Boolean; default is `True` Deprecated, use `java_single_jar` instead. |
+| `deploy_manifest_lines` | List of strings; default is `[]` A list of lines to add to the `META-INF/manifest.mf` file generated for the `*_deploy.jar` target. The contents of this attribute are *not* subject to ["Make variable"](/versions/9.1.0/reference/be/make-variables) substitution. |
+| `javacopts` | List of strings; default is `[]` Extra compiler options for this binary. Subject to ["Make variable"](/versions/9.1.0/reference/be/make-variables) substitution and [Bourne shell tokenization](/versions/9.1.0/reference/be/common-definitions#sh-tokenization). These compiler options are passed to javac after the global compiler options. |
+| `jvm_flags` | List of strings; default is `[]` A list of flags to embed in the wrapper script generated for running this binary. Subject to [$(location)](/versions/9.1.0/reference/be/make-variables#location) and ["Make variable"](/versions/9.1.0/reference/be/make-variables) substitution, and [Bourne shell tokenization](/versions/9.1.0/reference/be/common-definitions#sh-tokenization). The wrapper script for a Java binary includes a CLASSPATH definition (to find all the dependent jars) and invokes the right Java interpreter. The command line generated by the wrapper script includes the name of the main class followed by a `"$@"` so you can pass along other arguments after the classname. However, arguments intended for parsing by the JVM must be specified *before* the classname on the command line. The contents of `jvm_flags` are added to the wrapper script before the classname is listed.  Note that this attribute has *no effect* on `*_deploy.jar` outputs. |
+| `launcher` | [Label](/versions/9.1.0/concepts/labels); default is `None` Specify a binary that will be used to run your Java program instead of the normal `bin/java` program included with the JDK. The target must be a `cc_binary`. Any `cc_binary` that implements the [Java Invocation API](http://docs.oracle.com/javase/7/docs/technotes/guides/jni/spec/invocation.html) can be specified as a value for this attribute. By default, Bazel will use the normal JDK launcher (bin/java or java.exe).  The related [`--java_launcher`](/versions/9.1.0/docs/user-manual#flag--java_launcher) Bazel flag affects only those `java_binary` and `java_test` targets that have *not* specified a `launcher` attribute.  Note that your native (C++, SWIG, JNI) dependencies will be built differently depending on whether you are using the JDK launcher or another launcher:   * If you are using the normal JDK launcher (the default), native dependencies are   built as a shared library named `{name}_nativedeps.so`, where   `{name}` is the `name` attribute of this java_binary rule.   Unused code is *not* removed by the linker in this configuration. * If you are using any other launcher, native (C++) dependencies are statically   linked into a binary named `{name}_nativedeps`, where `{name}`   is the `name` attribute of this java_binary rule. In this case,   the linker will remove any code it thinks is unused from the resulting binary,   which means any C++ code accessed only via JNI may not be linked in unless   that `cc_library` target specifies `alwayslink = True`.   When using any launcher other than the default JDK launcher, the format of the `*_deploy.jar` output changes. See the main [java_binary](#java_binary) docs for details. |
+| `main_class` | String; default is `""` Name of class with `main()` method to use as entry point. If a rule uses this option, it does not need a `srcs=[...]` list. Thus, with this attribute one can make an executable from a Java library that already contains one or more `main()` methods. The value of this attribute is a class name, not a source file. The class must be available at runtime: it may be compiled by this rule (from `srcs`) or provided by direct or transitive dependencies (through `runtime_deps` or `deps`). If the class is unavailable, the binary will fail at runtime; there is no build-time check. |
+| `neverlink` | Boolean; default is `False` |
+| `plugins` | List of [labels](/versions/9.1.0/concepts/labels); default is `[]` Java compiler plugins to run at compile-time. Every `java_plugin` specified in this attribute will be run whenever this rule is built. A library may also inherit plugins from dependencies that use `exported_plugins`. Resources generated by the plugin will be included in the resulting jar of this rule. |
+| `resource_strip_prefix` | String; default is `""` The path prefix to strip from Java resources. If specified, this path prefix is stripped from every file in the `resources` attribute. It is an error for a resource file not to be under this directory. If not specified (the default), the path of resource file is determined according to the same logic as the Java package of source files. For example, a source file at `stuff/java/foo/bar/a.txt` will be located at `foo/bar/a.txt`. |
+| `runtime_deps` | List of [labels](/versions/9.1.0/concepts/labels); default is `[]` Libraries to make available to the final binary or test at runtime only. Like ordinary `deps`, these will appear on the runtime classpath, but unlike them, not on the compile-time classpath. Dependencies needed only at runtime should be listed here. Dependency-analysis tools should ignore targets that appear in both `runtime_deps` and `deps`. |
+| `stamp` | Integer; default is `0` Whether to encode build information into the binary. Possible values:  * `stamp = 1`: Always stamp the build information into the binary, even in   [`--nostamp`](https://bazel.build/versions/9.1.0/docs/user-manual#stamp) builds. **This   setting should be avoided**, since it potentially kills remote caching for the   binary and any downstream actions that depend on it. * `stamp = 0`: Always replace build information by constant values. This   gives good build result caching. * `stamp = -1`: Embedding of build information is controlled by the   [`--[no]stamp`](https://bazel.build/versions/9.1.0/docs/user-manual#stamp) flag.   Stamped binaries are *not* rebuilt unless their dependencies change. |
+| `test_class` | String; default is `""` The Java class to be loaded by the test runner.  By default, if this argument is not defined then the legacy mode is used and the test arguments are used instead. Set the `--nolegacy_bazel_java_test` flag to not fallback on the first argument.  This attribute specifies the name of a Java class to be run by this test. It is rare to need to set this. If this argument is omitted, it will be inferred using the target's `name` and its source-root-relative path. If the test is located outside a known source root, Bazel will report an error if `test_class` is unset.  For JUnit3, the test class needs to either be a subclass of `junit.framework.TestCase` or it needs to have a public static `suite()` method that returns a `junit.framework.Test` (or a subclass of `Test`).  This attribute allows several `java_test` rules to share the same `Test` (`TestCase`, `TestSuite`, ...). Typically additional information is passed to it (e.g. via `jvm_flags=['-Dkey=value']`) so that its behavior differs in each case, such as running a different subset of the tests. This attribute also enables the use of Java tests outside the `javatests` tree. |
+| `use_launcher` | Boolean; default is `True` Whether the binary should use a custom launcher. If this attribute is set to false, the [launcher](/versions/9.1.0/reference/be/java#java_binary.launcher) attribute and the related [`--java_launcher`](/versions/9.1.0/docs/user-manual#flag--java_launcher) flag will be ignored for this target. |
+| `use_testrunner` | Boolean; default is `True` Use the test runner (by default `com.google.testing.junit.runner.BazelTestRunner`) class as the main entry point for a Java program, and provide the test class to the test runner as a value of `bazel.test_suite` system property.   You can use this to override the default behavior, which is to use test runner for `java_test` rules, and not use it for `java_binary` rules. It is unlikely you will want to do this. One use is for `AllTest` rules that are invoked by another rule (to set up a database before running the tests, for example). The `AllTest` rule must be declared as a `java_binary`, but should still use the test runner as its main entry point. The name of a test runner class can be overridden with `main_class` attribute. |
+
+## java_package_configuration
+
+[View rule sourceopen_in_new](https://github.com/bazelbuild/rules_java/blob/master/java/common/rules/java_package_configuration.bzl)
+
+```
+java_package_configuration(name, data, aspect_hints, compatible_with, deprecation, exec_compatible_with, exec_group_compatible_with, exec_properties, features, javacopts, output_licenses, package_metadata, packages, restricted_to, system, tags, target_compatible_with, testonly, toolchains, visibility)
+```
+
+Configuration to apply to a set of packages.
+Configurations can be added to
+`java_toolchain.javacopts`s.
+
+#### Example:
+
+```
+java_package_configuration(
+    name = "my_configuration",
+    packages = [":my_packages"],
+    javacopts = ["-Werror"],
+)
+
+package_group(
+    name = "my_packages",
+    packages = [
+        "//com/my/project/...",
+        "-//com/my/project/testing/...",
+    ],
+)
+
+java_toolchain(
+    ...,
+    package_configuration = [
+        ":my_configuration",
+    ]
+)
+```
+
+### Arguments
+
+| Attributes | |
+| --- | --- |
+| `name` | [Name](/versions/9.1.0/concepts/labels#target-names); required  A unique name for this target. |
+| `data` | List of [labels](/versions/9.1.0/concepts/labels); default is `[]` The list of files needed by this configuration at runtime. |
+| `javacopts` | List of strings; default is `[]` Java compiler flags. |
+| `output_licenses` | List of strings; default is `[]` |
+| `packages` | List of [labels](/versions/9.1.0/concepts/labels); default is `[]` The set of `package_group`s the configuration should be applied to. |
+| `system` | [Label](/versions/9.1.0/concepts/labels); default is `None` Corresponds to javac's --system flag. |
+
+## java_plugin
+
+[View rule sourceopen_in_new](https://github.com/bazelbuild/rules_java/blob/master/java/bazel/rules/bazel_java_plugin.bzl)
+
+```
+java_plugin(name, deps, srcs, data, resources, add_exports, add_opens, aspect_hints, bootclasspath, compatible_with, deprecation, exec_compatible_with, exec_group_compatible_with, exec_properties, features, generates_api, javabuilder_jvm_flags, javacopts, licenses, neverlink, output_licenses, package_metadata, plugins, processor_class, proguard_specs, resource_strip_prefix, restricted_to, tags, target_compatible_with, testonly, toolchains, visibility)
+```
+
+`java_plugin` defines plugins for the Java compiler run by Bazel. The
+only supported kind of plugins are annotation processors. A `java_library` or
+`java_binary` rule can run plugins by depending on them via the `plugins`
+attribute. A `java_library` can also automatically export plugins to libraries that
+directly depend on it using
+`exported_plugins`.
+
+#### Implicit output targets
+
+* `libname.jar`: A Java archive.
+
+Arguments are a subset of (and with identical semantics to) those of
+[java_library()](/versions/9.1.0/reference/be/java#java_library),
+except for the addition of the `processor_class` and
+`generates_api` arguments.
+
+### Arguments
+
+| Attributes | |
+| --- | --- |
+| `name` | [Name](/versions/9.1.0/concepts/labels#target-names); required  A unique name for this target. |
+| `deps` | List of [labels](/versions/9.1.0/concepts/labels); default is `[]` The list of libraries to link into this library. See general comments about `deps` at [Typical attributes defined by most build rules](/versions/9.1.0/reference/be/common-definitions#typical-attributes). The jars built by `java_library` rules listed in `deps` will be on the compile-time classpath of this rule. Furthermore the transitive closure of their `deps`, `runtime_deps` and `exports` will be on the runtime classpath.  By contrast, targets in the `data` attribute are included in the runfiles but on neither the compile-time nor runtime classpath. |
+| `srcs` | List of [labels](/versions/9.1.0/concepts/labels); default is `[]` The list of source files that are processed to create the target. This attribute is almost always required; see exceptions below. Source files of type `.java` are compiled. In case of generated `.java` files it is generally advisable to put the generating rule's name here instead of the name of the file itself. This not only improves readability but makes the rule more resilient to future changes: if the generating rule generates different files in the future, you only need to fix one place: the `outs` of the generating rule. You should not list the generating rule in `deps` because it is a no-op.  Source files of type `.srcjar` are unpacked and compiled. (This is useful if you need to generate a set of `.java` files with a genrule.)  Rules: if the rule (typically `genrule` or `filegroup`) generates any of the files listed above, they will be used the same way as described for source files.  Source files of type `.properties` are treated as resources.  All other files are ignored, as long as there is at least one file of a file type described above. Otherwise an error is raised.  This argument is almost always required, except if you specify the `runtime_deps` argument. |
+| `data` | List of [labels](/versions/9.1.0/concepts/labels); default is `[]` The list of files needed by this library at runtime. See general comments about `data` at [Typical attributes defined by most build rules](/versions/9.1.0/reference/be/common-definitions#typical-attributes). When building a `java_library`, Bazel doesn't put these files anywhere; if the `data` files are generated files then Bazel generates them. When building a test that depends on this `java_library` Bazel copies or links the `data` files into the runfiles area. |
+| `resources` | List of [labels](/versions/9.1.0/concepts/labels); default is `[]` A list of data files to include in a Java jar. Resources may be source files or generated files.  If resources are specified, they will be bundled in the jar along with the usual `.class` files produced by compilation. The location of the resources inside of the jar file is determined by the project structure. Bazel first looks for Maven's [standard directory layout](https://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html), (a "src" directory followed by a "resources" directory grandchild). If that is not found, Bazel then looks for the topmost directory named "java" or "javatests" (so, for example, if a resource is at `<workspace root>/x/java/y/java/z`, the path of the resource will be `y/java/z`. This heuristic cannot be overridden, however, the `resource_strip_prefix` attribute can be used to specify a specific alternative directory for resource files. |
+| `add_exports` | List of strings; default is `[]` Allow this library to access the given `module` or `package`. This corresponds to the javac and JVM --add-exports= flags. |
+| `add_opens` | List of strings; default is `[]` Allow this library to reflectively access the given `module` or `package`. This corresponds to the javac and JVM --add-opens= flags. |
+| `bootclasspath` | [Label](/versions/9.1.0/concepts/labels); default is `None` Restricted API, do not use! |
+| `generates_api` | Boolean; default is `False` This attribute marks annotation processors that generate API code. If a rule uses an API-generating annotation processor, other rules depending on it can refer to the generated code only if their compilation actions are scheduled after the generating rule. This attribute instructs Bazel to introduce scheduling constraints when --java_header_compilation is enabled. *WARNING: This attribute affects build performance, use it only if necessary.* |
+| `javabuilder_jvm_flags` | List of strings; default is `[]` Restricted API, do not use! |
+| `javacopts` | List of strings; default is `[]` Extra compiler options for this library. Subject to ["Make variable"](/versions/9.1.0/reference/be/make-variables) substitution and [Bourne shell tokenization](/versions/9.1.0/reference/be/common-definitions#sh-tokenization). These compiler options are passed to javac after the global compiler options. |
+| `neverlink` | Boolean; default is `False` Whether this library should only be used for compilation and not at runtime. Useful if the library will be provided by the runtime environment during execution. Examples of such libraries are the IDE APIs for IDE plug-ins or `tools.jar` for anything running on a standard JDK. Note that `neverlink = True` does not prevent the compiler from inlining material from this library into compilation targets that depend on it, as permitted by the Java Language Specification (e.g., `static final` constants of `String` or of primitive types). The preferred use case is therefore when the runtime library is identical to the compilation library.  If the runtime library differs from the compilation library then you must ensure that it differs only in places that the JLS forbids compilers to inline (and that must hold for all future versions of the JLS). |
+| `output_licenses` | List of strings; default is `[]` |
+| `plugins` | List of [labels](/versions/9.1.0/concepts/labels); default is `[]` Java compiler plugins to run at compile-time. Every `java_plugin` specified in this attribute will be run whenever this rule is built. A library may also inherit plugins from dependencies that use `exported_plugins`. Resources generated by the plugin will be included in the resulting jar of this rule. |
+| `processor_class` | String; default is `""` The processor class is the fully qualified type of the class that the Java compiler should use as entry point to the annotation processor. If not specified, this rule will not contribute an annotation processor to the Java compiler's annotation processing, but its runtime classpath will still be included on the compiler's annotation processor path. (This is primarily intended for use by [Error Prone plugins](https://errorprone.info/docs/plugins), which are loaded from the annotation processor path using [java.util.ServiceLoader](https://docs.oracle.com/javase/8/docs/api/java/util/ServiceLoader.html).) |
+| `proguard_specs` | List of [labels](/versions/9.1.0/concepts/labels); default is `[]` Files to be used as Proguard specification. These will describe the set of specifications to be used by Proguard. If specified, they will be added to any `android_binary` target depending on this library. The files included here must only have idempotent rules, namely -dontnote, -dontwarn, assumenosideeffects, and rules that start with -keep. Other options can only appear in `android_binary`'s proguard_specs, to ensure non-tautological merges. |
+| `resource_strip_prefix` | String; default is `""` The path prefix to strip from Java resources. If specified, this path prefix is stripped from every file in the `resources` attribute. It is an error for a resource file not to be under this directory. If not specified (the default), the path of resource file is determined according to the same logic as the Java package of source files. For example, a source file at `stuff/java/foo/bar/a.txt` will be located at `foo/bar/a.txt`. |
+
+## java_runtime
+
+[View rule sourceopen_in_new](https://github.com/bazelbuild/rules_java/blob/master/java/common/rules/java_runtime.bzl)
+
+```
+java_runtime(name, srcs, aspect_hints, compatible_with, default_cds, deprecation, exec_compatible_with, exec_group_compatible_with, exec_properties, features, hermetic_srcs, hermetic_static_libs, java, java_home, lib_ct_sym, lib_modules, output_licenses, package_metadata, restricted_to, tags, target_compatible_with, testonly, toolchains, version, visibility)
+```
+
+Specifies the configuration for a Java runtime.
+
+#### Example:
+
+```
+java_runtime(
+    name = "jdk-9-ea+153",
+    srcs = glob(["jdk9-ea+153/**"]),
+    java_home = "jdk9-ea+153",
+)
+```
+
+### Arguments
+
+| Attributes | |
+| --- | --- |
+| `name` | [Name](/versions/9.1.0/concepts/labels#target-names); required  A unique name for this target. |
+| `srcs` | List of [labels](/versions/9.1.0/concepts/labels); default is `[]` All files in the runtime. |
+| `default_cds` | [Label](/versions/9.1.0/concepts/labels); default is `None` Default CDS archive for hermetic `java_runtime`. When hermetic is enabled for a `java_binary` target the `java_runtime` default CDS is packaged in the hermetic deploy JAR. |
+| `hermetic_srcs` | List of [labels](/versions/9.1.0/concepts/labels); default is `[]` Files in the runtime needed for hermetic deployments. |
+| `hermetic_static_libs` | List of [labels](/versions/9.1.0/concepts/labels); default is `[]` The libraries that are statically linked with the launcher for hermetic deployments |
+| `java` | [Label](/versions/9.1.0/concepts/labels); default is `None` The path to the java executable. |
+| `java_home` | String; default is `""` The path to the root of the runtime. Subject to ["Make" variable](/versions/9.1.0/reference/be/make-variables) substitution. If this path is absolute, the rule denotes a non-hermetic Java runtime with a well-known path. In that case, the `srcs` and `java` attributes must be empty. |
+| `lib_ct_sym` | [Label](/versions/9.1.0/concepts/labels); default is `None` The lib/ct.sym file needed for compilation with `--release`. If not specified and there is exactly one file in `srcs` whose path ends with `/lib/ct.sym`, that file is used. |
+| `lib_modules` | [Label](/versions/9.1.0/concepts/labels); default is `None` The lib/modules file needed for hermetic deployments. |
+| `output_licenses` | List of strings; default is `[]` |
+| `version` | Integer; default is `0` The feature version of the Java runtime. I.e., the integer returned by `Runtime.version().feature()`. |
+
+## java_single_jar
+
+[View rule sourceopen_in_new](https://github.com/bazelbuild/rules_java/blob/master/java/java_single_jar.bzl)
+
+```
+java_single_jar(name, deps, aspect_hints, compatible_with, compress, deploy_env, deploy_manifest_lines, deprecation, exclude_build_data, exclude_pattern, exec_compatible_with, exec_group_compatible_with, exec_properties, features, multi_release, output, package_metadata, restricted_to, tags, target_compatible_with, testonly, toolchains, visibility)
+```
+
+Collects Java dependencies and jar files into a single jar
+`java_single_jar` collects Java dependencies and jar files into a single jar.
+This is similar to java_binary with everything related to executables disabled,
+and provides an alternative to the java_binary "deploy jar hack".
+## Example
+```skylark
+load("//tools/build_defs/java_single_jar:java_single_jar.bzl", "java_single_jar")
+java_single_jar(
+name = "my_single_jar",
+deps = [
+"//java/com/google/foo",
+"//java/com/google/bar",
+],
+)
+```
+Outputs:
+{name}.jar: A single jar containing all of the inputs.
+
+### Arguments
+
+| Attributes | |
+| --- | --- |
+| `name` | [Name](/versions/9.1.0/concepts/labels#target-names); required  A unique name for this target. |
+| `deps` | List of [labels](/versions/9.1.0/concepts/labels); default is `[]` The Java targets (including java_import and java_library) to collect transitive dependencies from. Runtime dependencies are collected via deps, exports, and runtime_deps. Resources are also collected. Native cc_library or java_wrap_cc dependencies are not. |
+| `compress` | String; default is `"preserve"` Whether to always deflate ("yes"), always store ("no"), or pass through unmodified ("preserve"). The default is "preserve", and is the most efficient option -- no extra work is done to inflate or deflate. |
+| `deploy_env` | List of [labels](/versions/9.1.0/concepts/labels); default is `[]` A list of `java_binary` or `java_single_jar` targets which represent the deployment environment for this binary. Set this attribute when building a plugin which will be loaded by another `java_binary`. `deploy_env` dependencies are excluded from the jar built by this rule. |
+| `deploy_manifest_lines` | List of strings; default is `[]` A list of lines to add to the `META-INF/manifest.mf` file. |
+| `exclude_build_data` | Boolean; default is `True` Whether to omit the build-data.properties file generated by default. |
+| `exclude_pattern` | String; default is `""` A regex pattern of files to exclude from the jar. |
+| `multi_release` | Boolean; default is `True` Whether to enable Multi-Release output jars. |
+| `output` | [Filename](/versions/9.1.0/concepts/build-ref#filename); [nonconfigurable](/versions/9.1.0/reference/be/common-definitions#configurable-attributes); default is `None` |
+
+## java_toolchain
+
+[View rule sourceopen_in_new](https://github.com/bazelbuild/rules_java/blob/master/java/common/rules/java_toolchain.bzl)
+
+```
+java_toolchain(name, android_lint_data, android_lint_jvm_opts, android_lint_opts, android_lint_package_configuration, android_lint_runner, aspect_hints, bootclasspath, compatible_javacopts, compatible_with, deprecation, deps_checker, exec_compatible_with, exec_group_compatible_with, exec_properties, features, forcibly_disable_header_compilation, genclass, header_compiler, header_compiler_builtin_processors, header_compiler_direct, ijar, jacocorunner, java_runtime, javabuilder, javabuilder_data, javabuilder_jvm_opts, javac_supports_multiplex_workers, javac_supports_worker_cancellation, javac_supports_worker_multiplex_sandboxing, javac_supports_workers, javacopts, jspecify_implicit_deps, jspecify_javacopts, jspecify_packages, jspecify_processor, jspecify_processor_class, jspecify_stubs, jvm_opts, licenses, misc, oneversion, oneversion_allowlist, oneversion_allowlist_for_tests, oneversion_whitelist, package_configuration, package_metadata, proguard_allowlister, reduced_classpath_incompatible_processors, restricted_to, singlejar, source_version, tags, target_compatible_with, target_version, testonly, timezone_data, toolchains, tools, turbine_data, turbine_jvm_opts, visibility, xlint)
+```
+
+Specifies the configuration for the Java compiler. Which toolchain to be used can be changed through
+the --java_toolchain argument. Normally you should not write those kind of rules unless you want to
+tune your Java compiler.
+
+#### Examples
+
+A simple example would be:
+
+```
+java_toolchain(
+    name = "toolchain",
+    source_version = "7",
+    target_version = "7",
+    bootclasspath = ["//tools/jdk:bootclasspath"],
+    xlint = [ "classfile", "divzero", "empty", "options", "path" ],
+    javacopts = [ "-g" ],
+    javabuilder = ":JavaBuilder_deploy.jar",
+)
+```
+
+### Arguments
+
+| Attributes | |
+| --- | --- |
+| `name` | [Name](/versions/9.1.0/concepts/labels#target-names); required  A unique name for this target. |
+| `android_lint_data` | List of [labels](/versions/9.1.0/concepts/labels); default is `[]` Labels of tools available for label-expansion in android_lint_jvm_opts. |
+| `android_lint_jvm_opts` | List of strings; default is `[]` The list of arguments for the JVM when invoking Android Lint. |
+| `android_lint_opts` | List of strings; default is `[]` The list of Android Lint arguments. |
+| `android_lint_package_configuration` | List of [labels](/versions/9.1.0/concepts/labels); default is `[]` Android Lint Configuration that should be applied to the specified package groups. |
+| `android_lint_runner` | [Label](/versions/9.1.0/concepts/labels); default is `None` Label of the Android Lint runner, if any. |
+| `bootclasspath` | List of [labels](/versions/9.1.0/concepts/labels); default is `[]` The Java target bootclasspath entries. Corresponds to javac's -bootclasspath flag. |
+| `compatible_javacopts` | null; default is `{}` Internal API, do not use! |
+| `deps_checker` | [Label](/versions/9.1.0/concepts/labels); default is `None` Label of the ImportDepsChecker deploy jar. |
+| `forcibly_disable_header_compilation` | Boolean; default is `False` Overrides --java_header_compilation to disable header compilation on platforms that do not support it, e.g. JDK 7 Bazel. |
+| `genclass` | [Label](/versions/9.1.0/concepts/labels); default is `None` Label of the GenClass deploy jar. |
+| `header_compiler` | [Label](/versions/9.1.0/concepts/labels); default is `None` Label of the header compiler. Required if --java_header_compilation is enabled. |
+| `header_compiler_builtin_processors` | List of strings; default is `[]` Internal API, do not use! |
+| `header_compiler_direct` | [Label](/versions/9.1.0/concepts/labels); default is `None` Optional label of the header compiler to use for direct classpath actions that do not include any API-generating annotation processors. This tool does not support annotation processing. |
+| `ijar` | [Label](/versions/9.1.0/concepts/labels); default is `None` Label of the ijar executable. |
+| `jacocorunner` | [Label](/versions/9.1.0/concepts/labels); default is `None` Label of the JacocoCoverageRunner deploy jar. |
+| `java_runtime` | [Label](/versions/9.1.0/concepts/labels); default is `None` The java_runtime to use with this toolchain. It defaults to java_runtime in execution configuration. |
+| `javabuilder` | [Label](/versions/9.1.0/concepts/labels); default is `None` Label of the JavaBuilder deploy jar. |
+| `javabuilder_data` | List of [labels](/versions/9.1.0/concepts/labels); default is `[]` Labels of data available for label-expansion in javabuilder_jvm_opts. |
+| `javabuilder_jvm_opts` | List of strings; default is `[]` The list of arguments for the JVM when invoking JavaBuilder. |
+| `javac_supports_multiplex_workers` | Boolean; default is `True` True if JavaBuilder supports running as a multiplex persistent worker, false if it doesn't. |
+| `javac_supports_worker_cancellation` | Boolean; default is `True` True if JavaBuilder supports cancellation of persistent workers, false if it doesn't. |
+| `javac_supports_worker_multiplex_sandboxing` | Boolean; default is `False` True if JavaBuilder supports running as a multiplex persistent worker with sandboxing, false if it doesn't. |
+| `javac_supports_workers` | Boolean; default is `True` True if JavaBuilder supports running as a persistent worker, false if it doesn't. |
+| `javacopts` | List of strings; default is `[]` The list of extra arguments for the Java compiler. Please refer to the Java compiler documentation for the extensive list of possible Java compiler flags. |
+| `jspecify_implicit_deps` | [Label](/versions/9.1.0/concepts/labels); default is `None` Experimental, do not use! |
+| `jspecify_javacopts` | List of strings; default is `[]` Experimental, do not use! |
+| `jspecify_packages` | List of [labels](/versions/9.1.0/concepts/labels); default is `[]` Experimental, do not use! |
+| `jspecify_processor` | [Label](/versions/9.1.0/concepts/labels); default is `None` Experimental, do not use! |
+| `jspecify_processor_class` | String; default is `""` Experimental, do not use! |
+| `jspecify_stubs` | List of [labels](/versions/9.1.0/concepts/labels); default is `[]` Experimental, do not use! |
+| `jvm_opts` | List of strings; default is `[]` The list of arguments for the JVM when invoking the Java compiler. Please refer to the Java virtual machine documentation for the extensive list of possible flags for this option. |
+| `misc` | List of strings; default is `[]` Deprecated: use javacopts instead |
+| `oneversion` | [Label](/versions/9.1.0/concepts/labels); default is `None` Label of the one-version enforcement binary. |
+| `oneversion_allowlist` | [Label](/versions/9.1.0/concepts/labels); default is `None` Label of the one-version allowlist. |
+| `oneversion_allowlist_for_tests` | [Label](/versions/9.1.0/concepts/labels); default is `None` Label of the one-version allowlist for tests. |
+| `oneversion_whitelist` | [Label](/versions/9.1.0/concepts/labels); default is `None` Deprecated: use oneversion_allowlist instead |
+| `package_configuration` | List of [labels](/versions/9.1.0/concepts/labels); default is `[]` Configuration that should be applied to the specified package groups. |
+| `proguard_allowlister` | [Label](/versions/9.1.0/concepts/labels); default is `"@bazel_tools//tools/jdk:proguard_whitelister"` Label of the Proguard allowlister. |
+| `reduced_classpath_incompatible_processors` | List of strings; default is `[]` Internal API, do not use! |
+| `singlejar` | [Label](/versions/9.1.0/concepts/labels); default is `None` Label of the SingleJar deploy jar. |
+| `source_version` | String; default is `""` The Java source version (e.g., '6' or '7'). It specifies which set of code structures are allowed in the Java source code. |
+| `target_version` | String; default is `""` The Java target version (e.g., '6' or '7'). It specifies for which Java runtime the class should be build. |
+| `timezone_data` | [Label](/versions/9.1.0/concepts/labels); default is `None` Label of a resource jar containing timezone data. If set, the timezone data is added as an implicitly runtime dependency of all java_binary rules. |
+| `tools` | List of [labels](/versions/9.1.0/concepts/labels); default is `[]` Labels of tools available for label-expansion in jvm_opts. |
+| `turbine_data` | List of [labels](/versions/9.1.0/concepts/labels); default is `[]` Labels of data available for label-expansion in turbine_jvm_opts. |
+| `turbine_jvm_opts` | List of strings; default is `[]` The list of arguments for the JVM when invoking turbine. |
+| `xlint` | List of strings; default is `[]` The list of warning to add or removes from default list. Precedes it with a dash to removes it. Please see the Javac documentation on the -Xlint options for more information. |
\ No newline at end of file
diff --git a/versions/9.1.0/reference/be/make-variables.mdx b/versions/9.1.0/reference/be/make-variables.mdx
new file mode 100644
index 00000000..2e416e9c
--- /dev/null
+++ b/versions/9.1.0/reference/be/make-variables.mdx
@@ -0,0 +1,331 @@
+---
+title: 'Make Variables'
+---
+
+* [Use](#use)
+* [Predefined variables](#predefined_variables)
+* [Predefined genrule variables](#predefined_genrule_variables)
+* [Predefined source/output path variables](#predefined_label_variables)
+* [Custom variables](#custom_variables)
+
+"Make" variables are a special class of expandable string variables available
+to attributes marked as *"Subject to 'Make variable' substitution"*.
+
+These can be used, for example, to inject specific toolchain paths into
+user-constructed build actions.
+
+Bazel provides both *predefined* variables, which are available to all
+targets, and *custom* variables, which are defined in dependency targets
+and only available to targets that depend on them.
+
+The reason for the term "Make" is historical: the syntax and semantics of
+these variables were originally intended to match [GNU
+Make](https://www.gnu.org/software/make/manual/html_node/Using-Variables.html).
+
+## Use
+
+Attributes marked as *"Subject to 'Make variable' substitution"* can
+reference the "Make" variable `FOO` as follows:
+
+`my_attr = "prefix $(FOO) suffix"`
+
+In other words, any substring matching `$(FOO)` gets expanded
+to `FOO`'s value. If that value is `"bar"`, the final
+string becomes:
+
+`my_attr = "prefix bar suffix"`
+
+If `FOO` doesn't correspond to a variable known to the consuming
+target, Bazel fails with an error.
+
+"Make" variables whose names are non-letter symbols, such as
+`@`, can also be referenced using only a dollar sign, without
+the parentheses. For example:
+
+`my_attr = "prefix $@ suffix"`
+
+To write `$` as a string literal (i.e. to prevent variable
+expansion), write `$$`.
+
+## Predefined variables
+
+Predefined "Make" variables can be referenced by any attribute marked as
+*"Subject to 'Make variable' substitution"* on any target.
+
+To see the list of these variables and their values for a given set of build
+options, run
+
+`bazel info --show_make_env [build options]`
+
+and look at the top output lines with capital letters.
+
+[See an example of predefined variables](https://github.com/bazelbuild/examples/tree/main/make-variables#predefined-variables).
+
+**Toolchain option variables**
+
+* `COMPILATION_MODE`:
+  `fastbuild`, `dbg`, or `opt`. ([more
+  details](https://bazel.build/versions/9.1.0/docs/user-manual#flag--compilation_mode))
+
+**Path variables**
+
+* `BINDIR`: The base of the generated binary tree for the target
+  architecture.
+
+  Note that a different tree may be used for programs that run during the
+  build on the host architecture, to support cross-compiling.
+
+  If you want to run a tool from within a `genrule`, the
+  recommended way to get its path is `$(execpath toolname)`,
+  where *toolname* must be listed in the `genrule`'s
+  `tools` attribute.
+* `GENDIR`:
+  The base of the generated code tree for the target architecture.
+
+**Machine architecture variables**
+
+* `TARGET_CPU`:
+  The target architecture's CPU, e.g. `k8`.
+
+## Predefined genrule variables
+
+The following are specially available to `genrule`'s
+`cmd` attribute and are
+generally important for making that attribute work.
+
+[See an example of predefined genrule variables](https://github.com/bazelbuild/examples/tree/main/make-variables#predefined-genrule-variables).
+
+* `OUTS`: The `genrule`'s `outs` list. If you have
+  only one output file, you can also use `$@`.
+* `SRCS`: The `genrule`'s `srcs` list (or more
+  precisely: the path names of the files corresponding to labels in the
+  `srcs` list).
+  If you have only one source file, you can also use `$<`.
+* `<`: `SRCS`, if it is a single file. Else triggers
+  a build error.
+* `@`: `OUTS`, if it is a single file. Else triggers a
+  build error.
+* `RULEDIR`: The output directory of the target, that is, the
+  directory corresponding to the name of the package containing the target
+  under the `genfiles` or `bin` tree. For
+  `//my/pkg:my_genrule` this always ends in `my/pkg`,
+  even if `//my/pkg:my_genrule`'s outputs are in subdirectories.
+* `@D`: The output directory. If
+  [outs](/versions/9.1.0/reference/be/general#genrule.outs) has one entry,
+  this expands to the directory containing that file. If it has multiple
+  entries, this expands to the package's root directory in the
+  `genfiles` tree, *even if all output files are in the same
+  subdirectory*!
+
+  **Note:** Use `RULEDIR` over `@D` because
+  `RULEDIR` has simpler semantics and behaves the same way
+  regardless of the number of output files.
+
+  If the genrule needs to generate temporary intermediate files (perhaps as
+  a result of using some other tool like a compiler), it should attempt to
+  write them to `@D` (although `/tmp` will also
+  be writable) and remove them before finishing.
+
+  Especially avoid writing to directories containing inputs. They may be on
+  read-only filesystems. Even if not, doing so would trash the source tree.
+
+**Note:** If the filenames corresponding to the input labels or the output
+filenames contain spaces, `'`, or other special characters (or your
+genrule is part of a Starlark macro which downstream users may invoke on such
+files), then `$(SRCS)` and `$(OUTS)` are not suitable
+for interpolation into a command line, as they do not have the semantics that
+`"${@}"` would in Bash.
+
+One workaround is to convert to a Bash array, with
+
+```
+mapfile SRCS <<< "$$(sed -e 's/ /\\n/g' <<'genrule_srcs_expansion'
+$(SRC)
+genrule_srcs_expansion
+)
+```
+
+and then use `"$$\{SRCS[@]}"` in subsequent command lines in place
+of `$(SRCS)`. A more robust option is to write a Starlark rule
+instead.
+
+## Predefined source/output path variables
+
+The predefined variables `execpath`, `execpaths`,
+`rootpath`, `rootpaths`, `location`, and
+`locations` take label parameters (e.g. `$(execpath
+//foo:bar)`) and substitute the file paths denoted by that label.
+
+For source files, this is the path relative to your workspace root.
+For files that are outputs of rules, this is the file's *output path*
+(see the explanation of *output files* below).
+
+[See an example of predefined path variables](https://github.com/bazelbuild/examples/tree/main/make-variables#predefined-path-variables).
+
+* `execpath`: Denotes the path beneath the
+  [execroot](/versions/9.1.0/docs/output_directories)
+  where Bazel runs build actions.
+
+  In the above example, Bazel runs all build actions in the directory linked
+  by the `bazel-myproject` symlink in your workspace root. The
+  source file `empty.source` is linked at the path
+  `bazel-myproject/testapp/empty.source`. So its exec path (which
+  is the subpath below the root) is `testapp/empty.source`. This
+  is the path build actions can use to find the file.
+
+  Output files are staged similarly, but are also prefixed with the subpath
+  `bazel-out/cpu-compilation_mode/bin` (or for the outputs of
+  tools: `bazel-out/cpu-opt-exec-hash/bin`). In the above example,
+  `//testapp:app` is a tool because it appears in
+  `show_app_output`'s `tools` attribute.
+  So its output file `app` is written to
+  `bazel-myproject/bazel-out/cpu-opt-exec-hash/bin/testapp/app`.
+  The exec path is thus `bazel-out/cpu-opt-exec-hash/bin/testapp/app`. This extra prefix
+  makes it possible to build the same target for, say, two different CPUs in
+  the same build without the results clobbering each other.
+
+  The label passed to this variable must represent exactly one file. For
+  labels representing source files, this is automatically true. For labels
+  representing rules, the rule must generate exactly one output. If this is
+  false or the label is malformed, the build fails with an error.
+* `rootpath`: Denotes the path that a built binary can use to
+  find a dependency at runtime relative to the subdirectory of its runfiles
+  directory corresponding to the main repository.
+  **Note:** This only works if [`--enable_runfiles`](/versions/9.1.0/reference/command-line-reference#flag--enable_runfiles) is enabled, which is not the case on
+  Windows by default. Use `rlocationpath` instead for
+  cross-platform support.
+
+  This is similar to `execpath` but strips the configuration
+  prefixes described above. In the example from above this means both
+  `empty.source` and `app` use pure workspace-relative
+  paths: `testapp/empty.source` and `testapp/app`.
+
+  The `rootpath` of a file in an external repository
+  `repo` will start with `../repo/`, followed by the
+  repository-relative path.
+
+  This has the same "one output only" requirements as `execpath`.
+* `rlocationpath`: The path a built binary can pass to the `Rlocation` function of a runfiles library to find a dependency at
+  runtime, either in the runfiles directory (if available) or using the
+  runfiles manifest.
+
+  This is similar to `rootpath` in that it does not contain
+  configuration prefixes, but differs in that it always starts with the
+  name of the repository. In the example from above this means that `empty.source` and `app` result in the following
+  paths: `myproject/testapp/empty.source` and `myproject/testapp/app`.
+
+  The `rlocationpath` of a file in an external repository
+  `repo` will start with `repo/`, followed by the
+  repository-relative path.
+
+  Passing this path to a binary and resolving it to a file system path using
+  the runfiles libraries is the preferred approach to find dependencies at
+  runtime. Compared to `rootpath`, it has the advantage that it
+  works on all platforms and even if the runfiles directory is not
+  available.
+
+  This has the same "one output only" requirements as `execpath`.
+* `location`: A synonym for either `execpath` or
+  `rootpath`, depending on the attribute being expanded. This is
+  legacy pre-Starlark behavior and not recommended unless you really know what
+  it does for a particular rule. See [#2475](https://github.com/bazelbuild/bazel/issues/2475#issuecomment-339318016)
+  for details.
+
+`execpaths`, `rootpaths`, `rlocationpaths`,
+and `locations` are the plural variations of `execpath`,
+`rootpath`, `rlocationpath`, and`location`,
+respectively. They support labels producing multiple outputs, in which case
+each output is listed separated by a space. Zero-output rules and malformed
+labels produce build errors.
+
+All referenced labels must appear in the consuming target's `srcs`,
+output files, or `deps`. Otherwise the build fails. C++ targets can
+also reference labels in `data`.
+
+Labels don't have to be in canonical form: `foo`, `:foo`
+and `//somepkg:foo` are all fine.
+
+## Custom variables
+
+Custom "Make" variables can be referenced by any attribute marked as
+*"Subject to 'Make variable' substitution"*, but only on targets that
+depend on other targets that *define* these variables.
+
+As best practice all variables should be custom unless there's a really good
+reason to bake them into core Bazel. This saves Bazel from having to load
+potentially expensive dependencies to supply variables consuming tarets may
+not care about.
+
+**C++ toolchain variables**
+
+The following are defined in C++ toolchain rules and available to any rule
+that sets `toolchains =
+["@bazel_tools//tools/cpp:toolchain_type"]`
+Some rules, like `java_binary`, implicitly
+include the C++ toolchain in their rule definition. They inherit these variables
+automatically.
+
+The built-in C++ rules are much more sophisticated than "run the compiler on
+it". In order to support compilation modes as diverse as \*SAN, ThinLTO,
+with/without modules, and carefully optimized binaries at the same time as
+fast running tests on multiple platforms, the built-in rules go to great
+lengths to ensure the correct inputs, outputs, and command-line flags are set
+on each of potentially multiple internally generated actions.
+
+These variables are a fallback mechanism to be used by language experts in
+rare cases. If you are tempted to use them, please [contact the Bazel devs](https://bazel.build/versions/9.1.0/help) first.
+
+* `ABI`: The C++ ABI version.
+* `AR`: The "ar" command from crosstool.
+* `C_COMPILER`:
+  The C/C++ compiler identifier, e.g. `llvm`.
+* `CC`: The C and C++ compiler command.
+
+  We strongly recommended always using `CC_FLAGS` in
+  combination with `CC`. Fail to do so at your own risk.
+* `CC_FLAGS`: A minimal set of flags for the C/C++
+  compiler to be usable by genrules. In particular, this contains flags to
+  select the correct architecture if `CC` supports multiple
+  architectures.
+* `DUMPBIN`: Microsoft COFF Binary File Dumper (dumpbin.exe) from
+  from Microsoft Visual Studio.
+* `NM`: The "nm" command from crosstool.
+* `OBJCOPY`: The objcopy command from the same suite as the C/C++
+  compiler.
+* `STRIP`: The strip command from the same suite as the C/C++
+  compiler.
+
+**Java toolchain variables**
+
+The following are defined in Java toolchain rules and available to any rule
+that sets `toolchains =
+["@rules_java//toolchains:current_java_runtime"]` (or
+`"@rules_java//toolchains:current_host_java_runtime"`
+for the host toolchain equivalent).
+
+Most of the tools in the JDK should not be used directly. The built-in Java
+rules use much more sophisticated approaches to Java compilation and packaging
+than upstream tools can express, such as interface Jars, header interface
+Jars, and highly optimized Jar packaging and merging implementations.
+
+These variables are a fallback mechanism to be used by language experts in
+rare cases. If you are tempted to use them, please [contact the Bazel devs](https://bazel.build/versions/9.1.0/help) first.
+
+* `JAVA`: The "java" command (a Java virtual
+  machine). Avoid this, and use a `java_binary` rule
+  instead where possible. May be a relative path. If you must change
+  directories before invoking `java`, you need to capture the
+  working directory before changing it.
+* `JAVABASE`: The base directory containing the
+  Java utilities. May be a relative path. It will have a "bin"
+  subdirectory.
+
+**Starlark-defined variables**
+
+Rule and [toolchain](/versions/9.1.0/docs/toolchains) writers can define
+completely custom variables by returning a
+[TemplateVariableInfo](/versions/9.1.0/rules/lib/providers/TemplateVariableInfo)
+provider. Any rules depending on these through the
+`toolchains` attribute can then read their values:
+
+[See an example of Starlark-defined variables](https://github.com/bazelbuild/examples/tree/main/make-variables#custom-starlark-defined-variables).
\ No newline at end of file
diff --git a/versions/9.1.0/reference/be/objective-c.mdx b/versions/9.1.0/reference/be/objective-c.mdx
new file mode 100644
index 00000000..ce7634b9
--- /dev/null
+++ b/versions/9.1.0/reference/be/objective-c.mdx
@@ -0,0 +1,74 @@
+---
+title: 'Objective-C Rules'
+---
+
+## Rules
+
+* [objc_import](#objc_import)
+* [objc_library](#objc_library)
+
+## objc_import
+
+[View rule sourceopen_in_new](https://github.com/bazelbuild/rules_cc/blob/master/cc/private/rules_impl/objc_import.bzl)
+
+```
+objc_import(name, deps, hdrs, alwayslink, archives, aspect_hints, compatible_with, deprecation, exec_compatible_with, exec_group_compatible_with, exec_properties, features, includes, package_metadata, restricted_to, sdk_dylibs, sdk_frameworks, sdk_includes, tags, target_compatible_with, testonly, textual_hdrs, toolchains, visibility, weak_sdk_frameworks)
+```
+
+This rule encapsulates an already-compiled static library in the form of an
+`.a` file. It also allows exporting headers and resources using the same
+attributes supported by `objc_library`.
+
+### Arguments
+
+| Attributes | |
+| --- | --- |
+| `name` | [Name](/versions/9.1.0/concepts/labels#target-names); required  A unique name for this target. |
+| `deps` | List of [labels](/versions/9.1.0/concepts/labels); default is `[]` The list of targets that this target depend on. |
+| `hdrs` | List of [labels](/versions/9.1.0/concepts/labels); default is `[]` The list of C, C++, Objective-C, and Objective-C++ header files published by this library to be included by sources in dependent rules. These headers describe the public interface for the library and will be made available for inclusion by sources in this rule or in dependent rules. Headers not meant to be included by a client of this library should be listed in the srcs attribute instead. These will be compiled separately from the source if modules are enabled. |
+| `alwayslink` | Boolean; default is `False` If 1, any bundle or binary that depends (directly or indirectly) on this library will link in all the object files for the files listed in `srcs` and `non_arc_srcs`, even if some contain no symbols referenced by the binary. This is useful if your code isn't explicitly called by code in the binary, e.g., if your code registers to receive some callback provided by some service. |
+| `archives` | List of [labels](/versions/9.1.0/concepts/labels); required The list of `.a` files provided to Objective-C targets that depend on this target. |
+| `includes` | List of strings; default is `[]` List of `#include/#import` search paths to add to this target and all depending targets. This is to support third party and open-sourced libraries that do not specify the entire workspace path in their `#import/#include` statements. The paths are interpreted relative to the package directory, and the genfiles and bin roots (e.g. `blaze-genfiles/pkg/includedir` and `blaze-out/pkg/includedir`) are included in addition to the actual client root. Unlike [COPTS](/versions/9.1.0/reference/be/objective-c#objc_library.copts), these flags are added for this rule and every rule that depends on it. (Note: not the rules it depends upon!) Be very careful, since this may have far-reaching effects. When in doubt, add "-iquote" flags to [COPTS](/versions/9.1.0/reference/be/objective-c#objc_library.copts) instead. |
+| `sdk_dylibs` | List of strings; default is `[]` Names of SDK .dylib libraries to link with. For instance, "libz" or "libarchive". "libc++" is included automatically if the binary has any C++ or Objective-C++ sources in its dependency tree. When linking a binary, all libraries named in that binary's transitive dependency graph are used. |
+| `sdk_frameworks` | List of strings; default is `[]` Names of SDK frameworks to link with (e.g. "AddressBook", "QuartzCore"). When linking a top level Apple binary, all SDK frameworks listed in that binary's transitive dependency graph are linked. |
+| `sdk_includes` | List of strings; default is `[]` List of `#include/#import` search paths to add to this target and all depending targets, where each path is relative to `$(SDKROOT)/usr/include`. |
+| `textual_hdrs` | List of [labels](/versions/9.1.0/concepts/labels); default is `[]` The list of C, C++, Objective-C, and Objective-C++ files that are included as headers by source files in this rule or by users of this library. Unlike hdrs, these will not be compiled separately from the sources. |
+| `weak_sdk_frameworks` | List of strings; default is `[]` Names of SDK frameworks to weakly link with. For instance, "MediaAccessibility". In difference to regularly linked SDK frameworks, symbols from weakly linked frameworks do not cause an error if they are not present at runtime. |
+
+## objc_library
+
+[View rule sourceopen_in_new](https://github.com/bazelbuild/rules_cc/blob/master/cc/private/rules_impl/objc_library.bzl)
+
+```
+objc_library(name, deps, srcs, data, hdrs, alwayslink, aspect_hints, compatible_with, conlyopts, copts, cxxopts, defines, deprecation, enable_modules, exec_compatible_with, exec_group_compatible_with, exec_properties, features, implementation_deps, includes, linkopts, module_map, module_name, non_arc_srcs, package_metadata, pch, restricted_to, sdk_dylibs, sdk_frameworks, sdk_includes, stamp, tags, target_compatible_with, testonly, textual_hdrs, toolchains, visibility, weak_sdk_frameworks)
+```
+
+This rule produces a static library from the given Objective-C source files.
+
+### Arguments
+
+| Attributes | |
+| --- | --- |
+| `name` | [Name](/versions/9.1.0/concepts/labels#target-names); required  A unique name for this target. |
+| `deps` | List of [labels](/versions/9.1.0/concepts/labels); default is `[]` The list of targets that this target depend on. |
+| `srcs` | List of [labels](/versions/9.1.0/concepts/labels); default is `[]` The list of C, C++, Objective-C, and Objective-C++ source and header files, and/or (`.s`, `.S`, or `.asm`) assembly source files, that are processed to create the library target. These are your checked-in files, plus any generated files. Source files are compiled into .o files with Clang. Header files may be included/imported by any source or header in the srcs attribute of this target, but not by headers in hdrs or any targets that depend on this rule. Additionally, precompiled .o files may be given as srcs. Be careful to ensure consistency in the architecture of provided .o files and that of the build to avoid missing symbol linker errors. |
+| `hdrs` | List of [labels](/versions/9.1.0/concepts/labels); default is `[]` The list of C, C++, Objective-C, and Objective-C++ header files published by this library to be included by sources in dependent rules. These headers describe the public interface for the library and will be made available for inclusion by sources in this rule or in dependent rules. Headers not meant to be included by a client of this library should be listed in the srcs attribute instead. These will be compiled separately from the source if modules are enabled. |
+| `alwayslink` | Boolean; default is `False` If 1, any bundle or binary that depends (directly or indirectly) on this library will link in all the object files for the files listed in `srcs` and `non_arc_srcs`, even if some contain no symbols referenced by the binary. This is useful if your code isn't explicitly called by code in the binary, e.g., if your code registers to receive some callback provided by some service. |
+| `conlyopts` | List of strings; default is `[]` Extra flags to pass to the compiler for C files. Subject to ["Make variable"](/versions/9.1.0/reference/be/make-variables) substitution and [Bourne shell tokenization](/versions/9.1.0/reference/be/common-definitions#sh-tokenization). These flags will only apply to this target, and not those upon which it depends, or those which depend on it. Note that for the generated Xcode project, directory paths specified using "-I" flags in copts are parsed out, prepended with "$(WORKSPACE_ROOT)/" if they are relative paths, and added to the header search paths for the associated Xcode target. |
+| `copts` | List of strings; default is `[]` Extra flags to pass to the compiler. Subject to ["Make variable"](/versions/9.1.0/reference/be/make-variables) substitution and [Bourne shell tokenization](/versions/9.1.0/reference/be/common-definitions#sh-tokenization). These flags will only apply to this target, and not those upon which it depends, or those which depend on it. Note that for the generated Xcode project, directory paths specified using "-I" flags in copts are parsed out, prepended with "$(WORKSPACE_ROOT)/" if they are relative paths, and added to the header search paths for the associated Xcode target. |
+| `cxxopts` | List of strings; default is `[]` Extra flags to pass to the compiler for Objective-C++ and C++ files. Subject to ["Make variable"](/versions/9.1.0/reference/be/make-variables) substitution and [Bourne shell tokenization](/versions/9.1.0/reference/be/common-definitions#sh-tokenization). These flags will only apply to this target, and not those upon which it depends, or those which depend on it. Note that for the generated Xcode project, directory paths specified using "-I" flags in copts are parsed out, prepended with "$(WORKSPACE_ROOT)/" if they are relative paths, and added to the header search paths for the associated Xcode target. |
+| `defines` | List of strings; default is `[]` Extra `-D` flags to pass to the compiler. They should be in the form `KEY=VALUE` or simply `KEY` and are passed not only to the compiler for this target (as `copts` are) but also to all `objc_` dependers of this target. Subject to ["Make variable"](/versions/9.1.0/reference/be/make-variables) substitution and [Bourne shell tokenization](/versions/9.1.0/reference/be/common-definitions#sh-tokenization). |
+| `enable_modules` | Boolean; default is `False` Enables clang module support (via -fmodules). Setting this to 1 will allow you to @import system headers and other targets: @import UIKit; @import path_to_package_target; |
+| `implementation_deps` | List of [labels](/versions/9.1.0/concepts/labels); default is `[]` The list of other libraries that the library target depends on. Unlike with `deps`, the headers and include paths of these libraries (and all their transitive deps) are only used for compilation of this library, and not libraries that depend on it. Libraries specified with `implementation_deps` are still linked in binary targets that depend on this library. |
+| `includes` | List of strings; default is `[]` List of `#include/#import` search paths to add to this target and all depending targets. This is to support third party and open-sourced libraries that do not specify the entire workspace path in their `#import/#include` statements. The paths are interpreted relative to the package directory, and the genfiles and bin roots (e.g. `blaze-genfiles/pkg/includedir` and `blaze-out/pkg/includedir`) are included in addition to the actual client root. Unlike [COPTS](/versions/9.1.0/reference/be/objective-c#objc_library.copts), these flags are added for this rule and every rule that depends on it. (Note: not the rules it depends upon!) Be very careful, since this may have far-reaching effects. When in doubt, add "-iquote" flags to [COPTS](/versions/9.1.0/reference/be/objective-c#objc_library.copts) instead. |
+| `linkopts` | List of strings; default is `[]` Extra flags to pass to the linker. |
+| `module_map` | [Label](/versions/9.1.0/concepts/labels); default is `None` custom Clang module map for this target. Use of a custom module map is discouraged. Most users should use module maps generated by Bazel. If specified, Bazel will not generate a module map for this target, but will pass the provided module map to the compiler. |
+| `module_name` | String; default is `""` Sets the module name for this target. By default the module name is the target path with all special symbols replaced by \_, e.g. //foo/baz:bar can be imported as foo_baz_bar. |
+| `non_arc_srcs` | List of [labels](/versions/9.1.0/concepts/labels); default is `[]` The list of Objective-C files that are processed to create the library target that DO NOT use Automatic Reference Counting (ARC). The files in this attribute are treated very similar to those in the srcs attribute, but are compiled without ARC enabled. |
+| `pch` | [Label](/versions/9.1.0/concepts/labels); default is `None` Header file to prepend to every source file being compiled (both arc and non-arc). Use of pch files is actively discouraged in BUILD files, and this should be considered deprecated. Since pch files are not actually precompiled this is not a build-speed enhancement, and instead is just a global dependency. From a build efficiency point of view you are actually better including what you need directly in your sources where you need it. |
+| `sdk_dylibs` | List of strings; default is `[]` Names of SDK .dylib libraries to link with. For instance, "libz" or "libarchive". "libc++" is included automatically if the binary has any C++ or Objective-C++ sources in its dependency tree. When linking a binary, all libraries named in that binary's transitive dependency graph are used. |
+| `sdk_frameworks` | List of strings; default is `[]` Names of SDK frameworks to link with (e.g. "AddressBook", "QuartzCore"). When linking a top level Apple binary, all SDK frameworks listed in that binary's transitive dependency graph are linked. |
+| `sdk_includes` | List of strings; default is `[]` List of `#include/#import` search paths to add to this target and all depending targets, where each path is relative to `$(SDKROOT)/usr/include`. |
+| `stamp` | Boolean; default is `False` |
+| `textual_hdrs` | List of [labels](/versions/9.1.0/concepts/labels); default is `[]` The list of C, C++, Objective-C, and Objective-C++ files that are included as headers by source files in this rule or by users of this library. Unlike hdrs, these will not be compiled separately from the sources. |
+| `weak_sdk_frameworks` | List of strings; default is `[]` Names of SDK frameworks to weakly link with. For instance, "MediaAccessibility". In difference to regularly linked SDK frameworks, symbols from weakly linked frameworks do not cause an error if they are not present at runtime. |
\ No newline at end of file
diff --git a/versions/9.1.0/reference/be/overview.mdx b/versions/9.1.0/reference/be/overview.mdx
new file mode 100644
index 00000000..7a08cca4
--- /dev/null
+++ b/versions/9.1.0/reference/be/overview.mdx
@@ -0,0 +1,53 @@
+---
+title: 'Bazel BUILD Encyclopedia of Functions'
+---
+
+## Concepts and terminology
+
+* [Common definitions](/versions/9.1.0/reference/be/common-definitions)
+  + [Bourne shell tokenization](/versions/9.1.0/reference/be/common-definitions#sh-tokenization)
+  + [Label expansion](/versions/9.1.0/reference/be/common-definitions#label-expansion)
+  + [Typical attributes for most rules](/versions/9.1.0/reference/be/common-definitions#typical-attributes)
+  + [Common attributes for all rules](/versions/9.1.0/reference/be/common-definitions#common-attributes)
+  + [Common attributes for tests](/versions/9.1.0/reference/be/common-definitions#common-attributes-tests)
+  + [Common attributes for binaries](/versions/9.1.0/reference/be/common-definitions#common-attributes-binaries)
+  + [Configurable attributes](/versions/9.1.0/reference/be/common-definitions#configurable-attributes)
+  + [Implicit output targets](/versions/9.1.0/reference/be/common-definitions#implicit-outputs)
+* ["Make" variables](/versions/9.1.0/reference/be/make-variables)
+  + [Use](/versions/9.1.0/reference/be/make-variables#use)
+
+## Functions
+
+* [package](/versions/9.1.0/reference/be/functions#package)
+* [package_group](/versions/9.1.0/reference/be/functions#package_group)
+* [exports_files](/versions/9.1.0/reference/be/functions#exports_files)
+* [glob](/versions/9.1.0/reference/be/functions#glob)
+* [select](/versions/9.1.0/reference/be/functions#select)
+* [workspace](/versions/9.1.0/rules/lib/globals/workspace#workspace)
+
+## Rules
+
+Native rules ship with the Bazel binary and do not require a `load` statement.
+Native rules are available globally in BUILD files. In .bzl files, you can find them in
+the `native` module.
+For non-native Starlark rules that ship separately from Bazel, see the list of
+[recommended rules](/versions/9.1.0/rules/rules#recommended-rules).
+
+### Language-specific native rules
+
+| Language | Flags | Binary rules | Library rules | Test rules | Other rules |
+| --- | --- | --- | --- | --- | --- |
+| C / C++ |  | [cc_binary](/versions/9.1.0/reference/be/c-cpp#cc_binary) | [cc_import](/versions/9.1.0/reference/be/c-cpp#cc_import)   [cc_library](/versions/9.1.0/reference/be/c-cpp#cc_library)   [cc_shared_library](/versions/9.1.0/reference/be/c-cpp#cc_shared_library)   [cc_static_library](/versions/9.1.0/reference/be/c-cpp#cc_static_library) | [cc_test](/versions/9.1.0/reference/be/c-cpp#cc_test) | [cc_toolchain](/versions/9.1.0/reference/be/c-cpp#cc_toolchain)   [fdo_prefetch_hints](/versions/9.1.0/reference/be/c-cpp#fdo_prefetch_hints)   [fdo_profile](/versions/9.1.0/reference/be/c-cpp#fdo_profile)   [memprof_profile](/versions/9.1.0/reference/be/c-cpp#memprof_profile)   [propeller_optimize](/versions/9.1.0/reference/be/c-cpp#propeller_optimize) |
+| Java |  | [java_binary](/versions/9.1.0/reference/be/java#java_binary) | [java_import](/versions/9.1.0/reference/be/java#java_import)   [java_library](/versions/9.1.0/reference/be/java#java_library) | [java_test](/versions/9.1.0/reference/be/java#java_test) | [java_package_configuration](/versions/9.1.0/reference/be/java#java_package_configuration)   [java_plugin](/versions/9.1.0/reference/be/java#java_plugin)   [java_runtime](/versions/9.1.0/reference/be/java#java_runtime)   [java_single_jar](/versions/9.1.0/reference/be/java#java_single_jar)   [java_toolchain](/versions/9.1.0/reference/be/java#java_toolchain) |
+| Objective-C |  |  | [objc_import](/versions/9.1.0/reference/be/objective-c#objc_import)   [objc_library](/versions/9.1.0/reference/be/objective-c#objc_library) |  |  |
+| Protocol Buffer |  |  | [cc_proto_library](/versions/9.1.0/reference/be/protocol-buffer#cc_proto_library)   [java_lite_proto_library](/versions/9.1.0/reference/be/protocol-buffer#java_lite_proto_library)   [java_proto_library](/versions/9.1.0/reference/be/protocol-buffer#java_proto_library)   [proto_library](/versions/9.1.0/reference/be/protocol-buffer#proto_library)   [py_proto_library](/versions/9.1.0/reference/be/protocol-buffer#py_proto_library) |  | [proto_lang_toolchain](/versions/9.1.0/reference/be/protocol-buffer#proto_lang_toolchain)   [proto_toolchain](/versions/9.1.0/reference/be/protocol-buffer#proto_toolchain) |
+| Python |  | [py_binary](/versions/9.1.0/reference/be/python#py_binary) | [py_library](/versions/9.1.0/reference/be/python#py_library) | [py_test](/versions/9.1.0/reference/be/python#py_test) | [py_runtime](/versions/9.1.0/reference/be/python#py_runtime) |
+| Shell |  | [sh_binary](/versions/9.1.0/reference/be/shell#sh_binary) | [sh_library](/versions/9.1.0/reference/be/shell#sh_library) | [sh_test](/versions/9.1.0/reference/be/shell#sh_test) |  |
+
+### Language-agnostic native rules
+
+| Family | Rules |
+| --- | --- |
+| Extra Actions | * [action_listener](/versions/9.1.0/reference/be/extra-actions#action_listener)* [extra_action](/versions/9.1.0/reference/be/extra-actions#extra_action) |
+| General | * [alias](/versions/9.1.0/reference/be/general#alias)* [config_setting](/versions/9.1.0/reference/be/general#config_setting)* [filegroup](/versions/9.1.0/reference/be/general#filegroup)* [genquery](/versions/9.1.0/reference/be/general#genquery)* [genrule](/versions/9.1.0/reference/be/general#genrule)* [starlark_doc_extract](/versions/9.1.0/reference/be/general#starlark_doc_extract)* [test_suite](/versions/9.1.0/reference/be/general#test_suite) |
+| Platforms and Toolchains | * [constraint_setting](/versions/9.1.0/reference/be/platforms-and-toolchains#constraint_setting)* [constraint_value](/versions/9.1.0/reference/be/platforms-and-toolchains#constraint_value)* [platform](/versions/9.1.0/reference/be/platforms-and-toolchains#platform)* [toolchain](/versions/9.1.0/reference/be/platforms-and-toolchains#toolchain)* [toolchain_type](/versions/9.1.0/reference/be/platforms-and-toolchains#toolchain_type) |
\ No newline at end of file
diff --git a/versions/9.1.0/reference/be/platforms-and-toolchains.mdx b/versions/9.1.0/reference/be/platforms-and-toolchains.mdx
new file mode 100644
index 00000000..bfe72167
--- /dev/null
+++ b/versions/9.1.0/reference/be/platforms-and-toolchains.mdx
@@ -0,0 +1,356 @@
+---
+title: 'Platforms and Toolchains Rules'
+---
+
+This set of rules exists to allow you to model specific hardware platforms you are
+building for and specify the specific tools you may need to compile code for those platforms.
+The user should be familiar with the concepts explained [here](/versions/9.1.0/extending/platforms).
+
+## Rules
+
+* [constraint_setting](#constraint_setting)
+* [constraint_value](#constraint_value)
+* [platform](#platform)
+* [toolchain](#toolchain)
+* [toolchain_type](#toolchain_type)
+
+## constraint_setting
+
+[View rule sourceopen_in_new](https://github.com/bazelbuild/bazel/blob/master/src/main/java/com/google/devtools/build/lib/rules/platform/ConstraintSettingRule.java)
+
+```
+constraint_setting(name, aspect_hints, default_constraint_value, deprecation, features, licenses, tags, testonly, visibility)
+```
+
+This rule is used to introduce a new constraint type for which a platform may specify a value.
+For instance, you might define a `constraint_setting` named "glibc_version" to represent
+the capability for platforms to have different versions of the glibc library installed.
+For more details, see the
+[Platforms](https://bazel.build/versions/9.1.0/docs/platforms) page.
+
+Each `constraint_setting` has an extensible set of associated
+`constraint_value`s. Usually these are defined in the same package, but sometimes a
+different package will introduce new values for an existing setting. For instance, the predefined
+setting `@platforms//cpu:cpu` can be extended with a custom value in order to
+define a platform targeting an obscure cpu architecture.
+
+### Arguments
+
+| Attributes | |
+| --- | --- |
+| `name` | [Name](/versions/9.1.0/concepts/labels#target-names); required  A unique name for this target. |
+| `default_constraint_value` | [Name](/versions/9.1.0/concepts/labels#target-names); [nonconfigurable](/versions/9.1.0/reference/be/common-definitions#configurable-attributes); default is `None` The label of the default value for this setting, to be used if no value is given. If this attribute is present, the `constraint_value` it points to must be defined in the same package as this `constraint_setting`. If a constraint setting has a default value, then whenever a platform does not include any constraint value for that setting, it is the same as if the platform had specified the default value. Otherwise, if there is no default value, the constraint setting is considered to be unspecified by that platform. In that case, the platform would not match against any constraint list (such as for a `config_setting`) that requires a particular value for that setting. |
+
+## constraint_value
+
+[View rule sourceopen_in_new](https://github.com/bazelbuild/bazel/blob/master/src/main/java/com/google/devtools/build/lib/rules/platform/ConstraintValueRule.java)
+
+```
+constraint_value(name, aspect_hints, constraint_setting, deprecation, features, licenses, tags, testonly, visibility)
+```
+
+This rule introduces a new value for a given constraint type.
+For more details, see the
+[Platforms](https://bazel.build/versions/9.1.0/docs/platforms) page.
+
+#### Example
+
+The following creates a new possible value for the predefined `constraint_value`
+representing cpu architecture.
+
+```
+constraint_value(
+    name = "mips",
+    constraint_setting = "@platforms//cpu:cpu",
+)
+```
+
+Platforms can then declare that they have the `mips` architecture as an alternative to
+`x86_64`, `arm`, and so on.
+
+### Arguments
+
+| Attributes | |
+| --- | --- |
+| `name` | [Name](/versions/9.1.0/concepts/labels#target-names); required  A unique name for this target. |
+| `constraint_setting` | [Label](/versions/9.1.0/concepts/labels); [nonconfigurable](/versions/9.1.0/reference/be/common-definitions#configurable-attributes); required The `constraint_setting` for which this `constraint_value` is a possible choice. |
+
+## platform
+
+[View rule sourceopen_in_new](https://github.com/bazelbuild/bazel/blob/master/src/main/java/com/google/devtools/build/lib/rules/platform/PlatformRule.java)
+
+```
+platform(name, aspect_hints, constraint_values, deprecation, exec_properties, features, flags, licenses, missing_toolchain_error, parents, remote_execution_properties, required_settings, tags, testonly, visibility)
+```
+
+This rule defines a new platform -- a named collection of constraint choices
+(such as cpu architecture or compiler version) describing an environment in
+which part of the build may run.
+For more details, see the [Platforms](/versions/9.1.0/extending/platforms) page.
+
+#### Example
+
+This defines a platform that describes any environment running Linux on ARM.
+
+```
+platform(
+    name = "linux_arm",
+    constraint_values = [
+        "@platforms//os:linux",
+        "@platforms//cpu:arm",
+    ],
+)
+```
+
+### Platform Flags
+
+Platforms may use the `flags` attribute to specify a list of flags that will be added
+to the configuration whenever the platform is used as the target platform (i.e., as the value of
+the `--platforms` flag).
+
+Flags set from the platform effectively have the highest precedence and overwrite any previous
+value for that flag, from the command line, rc file, or transition.
+
+#### Example
+
+```
+platform(
+    name = "foo",
+    flags = [
+        "--dynamic_mode=fully",
+        "--//bool_flag",
+        "--no//package:other_bool_flag",
+    ],
+)
+```
+
+This defines a platform named `foo`. When this is the target platform (either because
+the user specified `--platforms//:foo`, because a transition set the
+`//command_line_option:platforms` flag to `["//:foo"]`, or because
+`//:foo` was used as an execution platform), then the given flags will be set in the
+configuration.
+
+#### Platforms and Repeatable Flags
+
+Some flags will accumulate values when they are repeated, such as `--features`,
+`--copt`, any Starlark flag created as `config.string(repeatable = True)`.
+These flags are not compatible with setting the flags from the platform: instead, all previous
+values will be removed and overwritten with the values from the platform.
+
+As an example, given the following platform, the invocation `build --platforms=//:repeat_demo
+--features feature_a --features feature_b` will end up with the value of the
+`--feature` flag being `["feature_c", "feature_d"]`, removing the features
+set on the command line.
+
+```
+platform(
+    name = "repeat_demo",
+    flags = [
+        "--features=feature_c",
+        "--features=feature_d",
+    ],
+)
+```
+
+For this reason, it is discouraged to use repeatable flags in the `flags` attribute.
+
+### Platform Inheritance
+
+Platforms may use the `parents` attribute to specify another platform that they will
+inherit constraint values from. Although the `parents` attribute takes a list, no
+more than a single value is currently supported, and specifying multiple parents is an error.
+
+When checking for the value of a constraint setting in a platform, first the values directly set
+(via the `constraint_values` attribute) are checked, and then the constraint values on
+the parent. This continues recursively up the chain of parent platforms. In this manner, any
+values set directly on a platform will override the values set on the parent.
+
+Platforms inherit the `exec_properties` attribute from the parent platform.
+The dictionary entries in `exec_properties` of the parent and child platforms
+will be combined.
+If the same key appears in both the parent's and the child's `exec_properties`,
+the child's value will be used. If the child platform specifies an empty string as a value, the
+corresponding property will be unset.
+
+Platforms can also inherit the (deprecated) `remote_execution_properties` attribute
+from the parent platform. Note: new code should use `exec_properties` instead. The
+logic described below is maintained to be compatible with legacy behavior but will be removed
+in the future.
+The logic for setting the `remote_execution_platform` is as follows when there
+is a parent platform:
+
+1. If `remote_execution_property` is not set on the child platform, the parent's
+   `remote_execution_properties` will be used.
+2. If `remote_execution_property` is set on the child platform, and contains the
+   literal string {PARENT_REMOTE_EXECUTION_PROPERTIES}, that macro will be
+   replaced with the contents of the parent's `remote_execution_property` attribute.
+3. If `remote_execution_property` is set on the child platform, and does not contain
+   the macro, the child's `remote_execution_property` will be used unchanged.
+
+*Since `remote_execution_properties` is deprecated and will be phased out, mixing
+`remote_execution_properties` and `exec_properties` in the same
+inheritance chain is not allowed.*
+Prefer to use `exec_properties` over the deprecated
+`remote_execution_properties`.
+
+#### Example: Constraint Values
+
+```
+platform(
+    name = "parent",
+    constraint_values = [
+        "@platforms//os:linux",
+        "@platforms//cpu:arm",
+    ],
+)
+platform(
+    name = "child_a",
+    parents = [":parent"],
+    constraint_values = [
+        "@platforms//cpu:x86_64",
+    ],
+)
+platform(
+    name = "child_b",
+    parents = [":parent"],
+)
+```
+
+In this example, the child platforms have the following properties:
+
+* `child_a` has the constraint values `@platforms//os:linux` (inherited
+  from the parent) and `@platforms//cpu:x86_64` (set directly on the platform).
+* `child_b` inherits all constraint values from the parent, and doesn't set any of
+  its own.
+
+#### Example: Execution properties
+
+```
+platform(
+    name = "parent",
+    exec_properties = {
+      "k1": "v1",
+      "k2": "v2",
+    },
+)
+platform(
+    name = "child_a",
+    parents = [":parent"],
+)
+platform(
+    name = "child_b",
+    parents = [":parent"],
+    exec_properties = {
+      "k1": "child"
+    }
+)
+platform(
+    name = "child_c",
+    parents = [":parent"],
+    exec_properties = {
+      "k1": ""
+    }
+)
+platform(
+    name = "child_d",
+    parents = [":parent"],
+    exec_properties = {
+      "k3": "v3"
+    }
+)
+```
+
+In this example, the child platforms have the following properties:
+
+* `child_a` inherits the "exec_properties" of the parent and does not set its own.
+* `child_b` inherits the parent's `exec_properties` and overrides the
+  value of `k1`. Its `exec_properties` will be:
+  `{ "k1": "child", "k2": "v2" }`.
+* `child_c` inherits the parent's `exec_properties` and unsets
+  `k1`. Its `exec_properties` will be:
+  `{ "k2": "v2" }`.
+* `child_d` inherits the parent's `exec_properties` and adds a new
+  property. Its `exec_properties` will be:
+  `{ "k1": "v1", "k2": "v2", "k3": "v3" }`.
+
+### Arguments
+
+| Attributes | |
+| --- | --- |
+| `name` | [Name](/versions/9.1.0/concepts/labels#target-names); required  A unique name for this target. |
+| `constraint_values` | List of [labels](/versions/9.1.0/concepts/labels); [nonconfigurable](/versions/9.1.0/reference/be/common-definitions#configurable-attributes); default is `[]` The combination of constraint choices that this platform comprises. In order for a platform to apply to a given environment, the environment must have at least the values in this list. Each `constraint_value` in this list must be for a different `constraint_setting`. For example, you cannot define a platform that requires the cpu architecture to be both `@platforms//cpu:x86_64` and `@platforms//cpu:arm`. |
+| `exec_properties` | Dictionary: String -> String; [nonconfigurable](/versions/9.1.0/reference/be/common-definitions#configurable-attributes); default is `{}` A map of strings that affect the way actions are executed remotely. Bazel makes no attempt to interpret this, it is treated as opaque data that's forwarded via the Platform field of the [remote execution protocol](https://github.com/bazelbuild/remote-apis). This includes any data from the parent platform's `exec_properties` attributes. If the child and parent platform define the same keys, the child's values are kept. Any keys associated with a value that is an empty string are removed from the dictionary. This attribute is a full replacement for the deprecated `remote_execution_properties`. |
+| `flags` | List of strings; [nonconfigurable](/versions/9.1.0/reference/be/common-definitions#configurable-attributes); default is `[]` A list of flags that will be enabled when this platform is used as the target platform in a configuration. Only flags that are part of the configuration can be set, such as those that can be used in transitions, or the `--define` flag. |
+| `missing_toolchain_error` | String; [nonconfigurable](/versions/9.1.0/reference/be/common-definitions#configurable-attributes); default is `"For more information on platforms or toolchains see https://bazel.build/concepts/platforms-intro."` A custom error message that is displayed when a mandatory toolchain requirement cannot be satisfied for this target platform. Intended to point to relevant documentation users can read to understand why their toolchains are misconfigured. Not inherited from parent platforms. |
+| `parents` | List of [labels](/versions/9.1.0/concepts/labels); [nonconfigurable](/versions/9.1.0/reference/be/common-definitions#configurable-attributes); default is `[]` The label of a `platform` target that this platform should inherit from. Although the attribute takes a list, there should be no more than one platform present. Any constraint_settings not set directly on this platform will be found in the parent platform. See the section on [Platform Inheritance](#platform_inheritance) for details. |
+| `remote_execution_properties` | String; [nonconfigurable](/versions/9.1.0/reference/be/common-definitions#configurable-attributes); default is `""` DEPRECATED. Please use exec_properties attribute instead. A string used to configure a remote execution platform. Actual builds make no attempt to interpret this, it is treated as opaque data that can be used by a specific SpawnRunner. This can include data from the parent platform's "remote_execution_properties" attribute, by using the macro "{PARENT_REMOTE_EXECUTION_PROPERTIES}". See the section on [Platform Inheritance](#platform_inheritance) for details. |
+| `required_settings` | List of [labels](/versions/9.1.0/concepts/labels); default is `[]` A list of `config_setting`s that must be satisfied by the target configuration in order for this platform to be used as an execution platform during toolchain resolution. Required settings are not inherited from parent platforms. |
+
+## toolchain
+
+[View rule sourceopen_in_new](https://github.com/bazelbuild/bazel/blob/master/src/main/java/com/google/devtools/build/lib/rules/platform/ToolchainRule.java)
+
+```
+toolchain(name, aspect_hints, deprecation, exec_compatible_with, features, licenses, package_metadata, tags, target_compatible_with, target_settings, testonly, toolchain, toolchain_type, use_target_platform_constraints, visibility)
+```
+
+This rule declares a specific toolchain's type and constraints so that it can be selected
+during toolchain resolution. See the
+[Toolchains](https://bazel.build/versions/9.1.0/docs/toolchains) page for more
+details.
+
+### Arguments
+
+| Attributes | |
+| --- | --- |
+| `name` | [Name](/versions/9.1.0/concepts/labels#target-names); required  A unique name for this target. |
+| `exec_compatible_with` | List of [labels](/versions/9.1.0/concepts/labels); [nonconfigurable](/versions/9.1.0/reference/be/common-definitions#configurable-attributes); default is `[]` A list of `constraint_value`s that must be satisfied by an execution platform in order for this toolchain to be selected for a target building on that platform. |
+| `target_compatible_with` | List of [labels](/versions/9.1.0/concepts/labels); [nonconfigurable](/versions/9.1.0/reference/be/common-definitions#configurable-attributes); default is `[]` A list of `constraint_value`s that must be satisfied by the target platform in order for this toolchain to be selected for a target building for that platform. |
+| `target_settings` | List of [labels](/versions/9.1.0/concepts/labels); default is `[]` A list of `config_setting`s that must be satisfied by the target configuration in order for this toolchain to be selected during toolchain resolution. |
+| `toolchain` | [Name](/versions/9.1.0/concepts/labels#target-names); required The target representing the actual tool or tool suite that is made available when this toolchain is selected. |
+| `toolchain_type` | [Label](/versions/9.1.0/concepts/labels); [nonconfigurable](/versions/9.1.0/reference/be/common-definitions#configurable-attributes); required The label of a `toolchain_type` target that represents the role that this toolchain serves. |
+| `use_target_platform_constraints` | Boolean; [nonconfigurable](/versions/9.1.0/reference/be/common-definitions#configurable-attributes); default is `False` If `True`, this toolchain behaves as if its `exec_compatible_with` and `target_compatible_with` constraints are set to those of the current target platform. `exec_compatible_with` and `target_compatible_with` must not be set in that case. |
+
+## toolchain_type
+
+[View rule sourceopen_in_new](https://github.com/bazelbuild/bazel/blob/master/src/main/java/com/google/devtools/build/lib/rules/ToolchainType.java)
+
+```
+toolchain_type(name, aspect_hints, compatible_with, deprecation, features, no_match_error, package_metadata, restricted_to, tags, target_compatible_with, testonly, visibility)
+```
+
+This rule defines a new type of toolchain -- a simple target that represents a class of tools that
+serve the same role for different platforms.
+
+See the [Toolchains](/versions/9.1.0/docs/toolchains) page for more details.
+
+#### Example
+
+This defines a toolchain type for a custom rule.
+
+```
+toolchain_type(
+    name = "bar_toolchain_type",
+)
+```
+
+This can be used in a bzl file.
+
+```
+bar_binary = rule(
+    implementation = _bar_binary_impl,
+    attrs = {
+        "srcs": attr.label_list(allow_files = True),
+        ...
+        # No `_compiler` attribute anymore.
+    },
+    toolchains = ["//bar_tools:toolchain_type"]
+)
+```
+
+### Arguments
+
+| Attributes | |
+| --- | --- |
+| `name` | [Name](/versions/9.1.0/concepts/labels#target-names); required  A unique name for this target. |
+| `no_match_error` | String; [nonconfigurable](/versions/9.1.0/reference/be/common-definitions#configurable-attributes); default is `""` A custom error message to display when no matching toolchain is found for this type. |
\ No newline at end of file
diff --git a/versions/9.1.0/reference/be/protocol-buffer.mdx b/versions/9.1.0/reference/be/protocol-buffer.mdx
new file mode 100644
index 00000000..4df01b5b
--- /dev/null
+++ b/versions/9.1.0/reference/be/protocol-buffer.mdx
@@ -0,0 +1,279 @@
+---
+title: 'Protocol Buffer Rules'
+---
+
+## Rules
+
+* [cc_proto_library](#cc_proto_library)
+* [java_lite_proto_library](#java_lite_proto_library)
+* [java_proto_library](#java_proto_library)
+* [proto_library](#proto_library)
+* [py_proto_library](#py_proto_library)
+* [proto_lang_toolchain](#proto_lang_toolchain)
+* [proto_toolchain](#proto_toolchain)
+
+## cc_proto_library
+
+[View rule sourceopen_in_new](https://github.com/protocolbuffers/protobuf/tree/v29.0-rc2/bazel/private/bazel_cc_proto_library.bzl)
+
+```
+cc_proto_library(name, deps, aspect_hints, compatible_with, deprecation, exec_compatible_with, exec_group_compatible_with, exec_properties, features, package_metadata, restricted_to, tags, target_compatible_with, testonly, toolchains, visibility)
+```
+
+`cc_proto_library` generates C++ code from `.proto` files.
+
+`deps` must point to [`proto_library`](/versions/9.1.0/reference/be/protocol-buffer#proto_library) rules.
+
+Example:
+
+```
+cc_library(
+    name = "lib",
+    deps = [":foo_cc_proto"],
+)
+
+cc_proto_library(
+    name = "foo_cc_proto",
+    deps = [":foo_proto"],
+)
+
+proto_library(
+    name = "foo_proto",
+)
+```
+
+### Arguments
+
+| Attributes | |
+| --- | --- |
+| `name` | [Name](/versions/9.1.0/concepts/labels#target-names); required  A unique name for this target. |
+| `deps` | List of [labels](/versions/9.1.0/concepts/labels); default is `[]` The list of [`proto_library`](/versions/9.1.0/reference/be/protocol-buffer#proto_library) rules to generate C++ code for. |
+
+## java_lite_proto_library
+
+[View rule sourceopen_in_new](https://github.com/protocolbuffers/protobuf/tree/v29.0-rc2/bazel/private/java_lite_proto_library.bzl)
+
+```
+java_lite_proto_library(name, deps, aspect_hints, compatible_with, deprecation, exec_compatible_with, exec_group_compatible_with, exec_properties, features, package_metadata, restricted_to, tags, target_compatible_with, testonly, toolchains, visibility)
+```
+
+`java_lite_proto_library` generates Java code from `.proto` files.
+
+`deps` must point to [`proto_library`](/versions/9.1.0/reference/be/protocol-buffer#proto_library) rules.
+
+Example:
+
+```
+java_library(
+    name = "lib",
+    runtime_deps = [":foo"],
+)
+
+java_lite_proto_library(
+    name = "foo",
+    deps = [":bar"],
+)
+
+proto_library(
+    name = "bar",
+)
+```
+
+### Arguments
+
+| Attributes | |
+| --- | --- |
+| `name` | [Name](/versions/9.1.0/concepts/labels#target-names); required  A unique name for this target. |
+| `deps` | List of [labels](/versions/9.1.0/concepts/labels); default is `[]` The list of [`proto_library`](/versions/9.1.0/reference/be/protocol-buffer#proto_library) rules to generate Java code for. |
+
+## java_proto_library
+
+[View rule sourceopen_in_new](https://github.com/protocolbuffers/protobuf/tree/v29.0-rc2/bazel/private/bazel_java_proto_library_rule.bzl)
+
+```
+java_proto_library(name, deps, aspect_hints, compatible_with, deprecation, exec_compatible_with, exec_group_compatible_with, exec_properties, features, licenses, package_metadata, restricted_to, tags, target_compatible_with, testonly, toolchains, visibility)
+```
+
+`java_proto_library` generates Java code from `.proto` files.
+
+`deps` must point to [`proto_library`](/versions/9.1.0/reference/be/protocol-buffer#proto_library) rules.
+
+Example:
+
+```
+java_library(
+    name = "lib",
+    runtime_deps = [":foo_java_proto"],
+)
+
+java_proto_library(
+    name = "foo_java_proto",
+    deps = [":foo_proto"],
+)
+
+proto_library(
+    name = "foo_proto",
+)
+```
+
+### Arguments
+
+| Attributes | |
+| --- | --- |
+| `name` | [Name](/versions/9.1.0/concepts/labels#target-names); required  A unique name for this target. |
+| `deps` | List of [labels](/versions/9.1.0/concepts/labels); default is `[]` The list of [`proto_library`](/versions/9.1.0/reference/be/protocol-buffer#proto_library) rules to generate Java code for. |
+
+## proto_library
+
+[View rule sourceopen_in_new](https://github.com/protocolbuffers/protobuf/tree/v29.0-rc2/bazel/private/proto_library_rule.bzl)
+
+```
+proto_library(name, deps, srcs, data, allow_exports, aspect_hints, compatible_with, deprecation, exec_compatible_with, exec_group_compatible_with, exec_properties, exports, extension_declarations, features, import_prefix, licenses, option_deps, package_metadata, restricted_to, strip_import_prefix, tags, target_compatible_with, testonly, toolchains, visibility)
+```
+
+Use `proto_library` to define libraries of protocol buffers which
+may be used from multiple languages. A `proto_library` may be listed
+in the `deps` clause of supported rules, such as
+`java_proto_library`.
+
+When compiled on the command-line, a `proto_library` creates a file
+named `foo-descriptor-set.proto.bin`, which is the descriptor set for
+the messages the rule srcs. The file is a serialized
+`FileDescriptorSet`, which is described in
+https://developers.google.com/protocol-buffers/docs/techniques#self-description.
+
+It only contains information about the `.proto` files directly
+mentioned by a `proto_library` rule; the collection of transitive
+descriptor sets is available through the
+`[ProtoInfo].transitive_descriptor_sets` Starlark provider.
+See documentation in `proto_info.bzl`.
+
+Recommended code organization:
+
+* One `proto_library` rule per `.proto` file.* A file named `foo.proto` will be in a rule named `foo_proto`,
+    which is located in the same package.* A `[language]_proto_library` that wraps a `proto_library`
+      named `foo_proto` should be called `foo_[language]_proto`,
+      and be located in the same package.
+
+### Arguments
+
+| Attributes | |
+| --- | --- |
+| `name` | [Name](/versions/9.1.0/concepts/labels#target-names); required  A unique name for this target. |
+| `deps` | List of [labels](/versions/9.1.0/concepts/labels); default is `[]` The list of other `proto_library` rules that the target depends upon. A `proto_library` may only depend on other `proto_library` targets. It may not depend on language-specific libraries. |
+| `srcs` | List of [labels](/versions/9.1.0/concepts/labels); default is `[]` The list of `.proto` and `.protodevel` files that are processed to create the target. This is usually a non empty list. One usecase where `srcs` can be empty is an *alias-library*. This is a proto_library rule having one or more other proto_library in `deps`. This pattern can be used to e.g. export a public api under a persistent name. |
+| `allow_exports` | [Label](/versions/9.1.0/concepts/labels); default is `None` An optional allowlist that prevents proto library to be reexported or used in lang_proto_library that is not in one of the listed packages. |
+| `exports` | List of [labels](/versions/9.1.0/concepts/labels); default is `[]` List of proto_library targets that can be referenced via "import public" in the proto source. It's an error if you use "import public" but do not list the corresponding library in the exports attribute. Note that you have list the library both in deps and exports since not all lang_proto_library implementations have been changed yet. |
+| `extension_declarations` | List of [labels](/versions/9.1.0/concepts/labels); default is `[]` List of files containing extension declarations. This attribute is only allowed for use with MessageSet. |
+| `import_prefix` | String; default is `""` The prefix to add to the paths of the .proto files in this rule. When set, the .proto source files in the `srcs` attribute of this rule are accessible at is the value of this attribute prepended to their repository-relative path. The prefix in the `strip_import_prefix` attribute is removed before this prefix is added. |
+| `option_deps` | List of [labels](/versions/9.1.0/concepts/labels); default is `[]` The list of other `proto_library` rules that the target depends upon for options only. A `proto_library` may only depend on other `proto_library` targets. It may not depend on language-specific libraries. |
+| `strip_import_prefix` | String; default is `"/"` The prefix to strip from the paths of the .proto files in this rule. When set, .proto source files in the `srcs` attribute of this rule are accessible at their path with this prefix cut off. If it's a relative path (not starting with a slash), it's taken as a package-relative one. If it's an absolute one, it's understood as a repository-relative path. The prefix in the `import_prefix` attribute is added after this prefix is stripped. |
+
+## py_proto_library
+
+[View rule sourceopen_in_new](https://github.com/protocolbuffers/protobuf/tree/v29.0-rc2/bazel/py_proto_library.bzl)
+
+```
+py_proto_library(name, deps, aspect_hints, compatible_with, deprecation, exec_compatible_with, exec_group_compatible_with, exec_properties, features, package_metadata, restricted_to, tags, target_compatible_with, testonly, toolchains, visibility)
+```
+
+Use `py_proto_library` to generate Python libraries from `.proto` files.
+The convention is to name the `py_proto_library` rule `foo_py_pb2`,
+when it is wrapping `proto_library` rule `foo_proto`.
+`deps` must point to a `proto_library` rule.
+Example:
+```starlark
+py_library(
+name = "lib",
+deps = [":foo_py_pb2"],
+)
+py_proto_library(
+name = "foo_py_pb2",
+deps = [":foo_proto"],
+)
+proto_library(
+name = "foo_proto",
+srcs = ["foo.proto"],
+)
+```
+
+### Arguments
+
+| Attributes | |
+| --- | --- |
+| `name` | [Name](/versions/9.1.0/concepts/labels#target-names); required  A unique name for this target. |
+| `deps` | List of [labels](/versions/9.1.0/concepts/labels); default is `[]` The list of `proto_library` rules to generate Python libraries for. Usually this is just the one target: the proto library of interest. It can be any target providing `ProtoInfo`. |
+
+## proto_lang_toolchain
+
+[View rule sourceopen_in_new](https://github.com/protocolbuffers/protobuf/tree/v29.0-rc2/bazel/private/proto_lang_toolchain_rule.bzl)
+
+```
+proto_lang_toolchain(name, allowlist_different_package, aspect_hints, blacklisted_protos, command_line, compatible_with, denylisted_protos, deprecation, exec_compatible_with, exec_group_compatible_with, exec_properties, features, mnemonic, output_files, package_metadata, plugin, plugin_format_flag, progress_message, protoc_minimal_do_not_use, restricted_to, runtime, tags, target_compatible_with, testonly, toolchain_type, toolchains, visibility)
+```
+
+If using Bazel, please load the rule from https://github.com/bazelbuild/rules_proto.
+
+Specifies how a LANG_proto_library rule (e.g., `java_proto_library`) should invoke the
+proto-compiler.
+Some LANG_proto_library rules allow specifying which toolchain to use using command-line flags;
+consult their documentation.
+
+Normally you should not write those kind of rules unless you want to
+tune your Java compiler.
+
+There's no compiler. The proto-compiler is taken from the proto_library rule we attach to. It is
+passed as a command-line flag to Blaze.
+Several features require a proto-compiler to be invoked on the proto_library rule itself.
+It's beneficial to enforce the compiler that LANG_proto_library uses is the same as the one
+`proto_library` does.
+
+#### Examples
+
+A simple example would be:
+
+```
+proto_lang_toolchain(
+    name = "javalite_toolchain",
+    command_line = "--javalite_out=shared,immutable:$(OUT)",
+    plugin = ":javalite_plugin",
+    runtime = ":protobuf_lite",
+)
+```
+
+### Arguments
+
+| Attributes | |
+| --- | --- |
+| `name` | [Name](/versions/9.1.0/concepts/labels#target-names); required  A unique name for this target. |
+| `allowlist_different_package` | [Label](/versions/9.1.0/concepts/labels); default is `None` |
+| `blacklisted_protos` | List of [labels](/versions/9.1.0/concepts/labels); default is `[]` Deprecated. Alias for `denylisted_protos`. Will be removed in a future release. |
+| `command_line` | String; required This value will be passed to proto-compiler to generate the code. Only include the parts specific to this code-generator/plugin (e.g., do not include -I parameters)  * `$(OUT)` is LANG_proto_library-specific. The rules are expected to define   how they interpret this variable. For Java, for example, $(OUT) will be replaced with   the src-jar filename to create. |
+| `denylisted_protos` | List of [labels](/versions/9.1.0/concepts/labels); default is `[]` No code will be generated for files in the `srcs` attribute of `denylisted_protos`. This is used for .proto files that are already linked into proto runtimes, such as `any.proto`. |
+| `mnemonic` | String; default is `"GenProto"` This value will be set as the mnemonic on protoc action. |
+| `output_files` | String; default is `"legacy"` Controls how `$(OUT)` in `command_line` is formatted, either by a path to a single file or output directory in case of multiple files. Possible values are: "single", "multiple". |
+| `plugin` | [Label](/versions/9.1.0/concepts/labels); default is `None` If provided, will be made available to the action that calls the proto-compiler, and will be passed to the proto-compiler: `--plugin=protoc-gen-PLUGIN=<executable>.` |
+| `plugin_format_flag` | String; default is `""` If provided, this value will be passed to proto-compiler to use the plugin. The value must contain a single %s which is replaced with plugin executable. `--plugin=protoc-gen-PLUGIN=<executable>.` |
+| `progress_message` | String; default is `"Generating proto_library %{label}"` This value will be set as the progress message on protoc action. |
+| `protoc_minimal_do_not_use` | [Label](/versions/9.1.0/concepts/labels); default is `None` |
+| `runtime` | [Label](/versions/9.1.0/concepts/labels); default is `None` A language-specific library that the generated code is compiled against. The exact behavior is LANG_proto_library-specific. Java, for example, should compile against the runtime. |
+| `toolchain_type` | [Label](/versions/9.1.0/concepts/labels); default is `None` |
+
+## proto_toolchain
+
+[View rule sourceopen_in_new](https://github.com/protocolbuffers/protobuf/tree/v29.0-rc2/bazel/private/proto_toolchain_rule.bzl)
+
+```
+proto_toolchain(name, aspect_hints, command_line, compatible_with, deprecation, exec_compatible_with, exec_group_compatible_with, exec_properties, features, mnemonic, output_files, package_metadata, progress_message, proto_compiler, restricted_to, tags, target_compatible_with, testonly, toolchains, visibility)
+```
+
+### Arguments
+
+| Attributes | |
+| --- | --- |
+| `name` | [Name](/versions/9.1.0/concepts/labels#target-names); required  A unique name for this target. |
+| `command_line` | String; default is `"--descriptor_set_out=%s"` |
+| `mnemonic` | String; default is `"GenProtoDescriptorSet"` |
+| `output_files` | String; default is `"single"` |
+| `progress_message` | String; default is `"Generating Descriptor Set proto_library %{label}"` |
+| `proto_compiler` | [Label](/versions/9.1.0/concepts/labels); default is `None` |
\ No newline at end of file
diff --git a/versions/9.1.0/reference/be/python.mdx b/versions/9.1.0/reference/be/python.mdx
new file mode 100644
index 00000000..a4ef4c7b
--- /dev/null
+++ b/versions/9.1.0/reference/be/python.mdx
@@ -0,0 +1,171 @@
+---
+title: 'Python Rules'
+---
+
+## Rules
+
+* [py_binary](#py_binary)
+* [py_library](#py_library)
+* [py_test](#py_test)
+* [py_runtime](#py_runtime)
+
+## py_binary
+
+[View rule sourceopen_in_new](https://github.com/bazelbuild/rules_python/tree/0.40.0/python/private/py_binary_rule.bzl)
+
+```
+py_binary(name, deps, srcs, data, args, aspect_hints, compatible_with, config_settings, deprecation, distribs, env, exec_compatible_with, exec_group_compatible_with, exec_properties, features, imports, interpreter_args, legacy_create_init, licenses, main, main_module, output_licenses, package_metadata, precompile, precompile_invalidation_mode, precompile_optimize_level, precompile_source_retention, pyc_collection, pyi_deps, pyi_srcs, python_version, restricted_to, srcs_version, stamp, tags, target_compatible_with, testonly, toolchains, visibility)
+```
+
+### Arguments
+
+| Attributes | |
+| --- | --- |
+| `name` | [Name](/versions/9.1.0/concepts/labels#target-names); required  A unique name for this target. |
+| `deps` | List of [labels](/versions/9.1.0/concepts/labels); default is `[]` List of additional libraries to be linked in to the target. See comments about the [`deps` attribute typically defined by rules](https://bazel.build/versions/9.1.0/reference/be/common-definitions#typical-attributes). These are typically `py_library` rules. Targets that only provide data files used at runtime belong in the `data` attribute. :::{note} The order of this list can matter because it affects the order that information from dependencies is merged in, which can be relevant depending on the ordering mode of depsets that are merged. \* {obj}`PyInfo.venv_symlinks` uses default ordering. See {obj}`PyInfo` for more information about the ordering of its depsets and how its fields are merged. ::: |
+| `srcs` | List of [labels](/versions/9.1.0/concepts/labels); default is `[]` The list of Python source files that are processed to create the target. This includes all your checked-in code and may include generated source files. The `.py` files belong in `srcs` and library targets belong in `deps`. Other binary files that may be needed at run time belong in `data`. |
+| `data` | List of [labels](/versions/9.1.0/concepts/labels); default is `[]` The list of files need by this library at runtime. See comments about the [`data` attribute typically defined by rules](https://bazel.build/versions/9.1.0/reference/be/common-definitions#typical-attributes). There is no `py_embed_data` like there is `cc_embed_data` and `go_embed_data`. This is because Python has a concept of runtime resources. |
+| `config_settings` | Dictionary: [label](/versions/9.1.0/concepts/labels) -> String; default is `{}` Config settings to change for this target. The keys are labels for settings, and the values are strings for the new value to use. Pass `Label` objects or canonical label strings for the keys to ensure they resolve as expected (canonical labels start with `@@` and can be obtained by calling `str(Label(...))`). Most `@rules_python//python/config_setting` settings can be used here, which allows, for example, making only a certain `py_binary` use {obj}`--boostrap_impl=script`. Additional or custom config settings can be registered using the {obj}`add_transition_setting` API. This allows, for example, forcing a particular CPU, or defining a custom setting that `select()` uses elsewhere to pick between `pip.parse` hubs. See the [How to guide on multiple versions of a library] for a more concrete example. :::{note} These values are transitioned on, so will affect the analysis graph and the associated memory overhead. The more unique configurations in your overall build, the more memory and (often unnecessary) re-analysis and re-building can occur. See https://bazel.build/extending/config#memory-performance-considerations for more information about risks and considerations. ::: :::{versionadded} 1.7.0 ::: |
+| `distribs` | List of strings; default is `[]` |
+| `imports` | List of strings; default is `[]` List of import directories to be added to the PYTHONPATH. Subject to "Make variable" substitution. These import directories will be added for this rule and all rules that depend on it (note: not the rules this rule depends on. Each directory will be added to `PYTHONPATH` by `py_binary` rules that depend on this rule. The strings are repo-runfiles-root relative, Absolute paths (paths that start with `/`) and paths that references a path above the execution root are not allowed and will result in an error. |
+| `interpreter_args` | List of strings; default is `[]` Arguments that are only applicable to the interpreter. The args an interpreter supports are specific to the interpreter. For CPython, see https://docs.python.org/3/using/cmdline.html. :::{note} Only supported for {obj}`--bootstrap_impl=script`. Ignored otherwise. ::: :::{seealso} The {any}`RULES_PYTHON_ADDITIONAL_INTERPRETER_ARGS` environment variable ::: :::{versionadded} 1.3.0 ::: |
+| `legacy_create_init` | Integer; default is `-1` Whether to implicitly create empty `\__init\_\_.py` files in the runfiles tree. These are created in every directory containing Python source code or shared libraries, and every parent directory of those directories, excluding the repo root directory. The default, `-1` (auto), means true unless `--incompatible_default_to_explicit_init_py` is used. If false, the user is responsible for creating (possibly empty) `\__init\_\_.py` files and adding them to the `srcs` of Python targets as required. |
+| `main` | [Label](/versions/9.1.0/concepts/labels); default is `None` Optional; the name of the source file that is the main entry point of the application. This file must also be listed in `srcs`. If left unspecified, `name`, with `.py` appended, is used instead. If `name` does not match any filename in `srcs`, `main` must be specified. This is mutually exclusive with {obj}`main_module`. |
+| `main_module` | String; default is `""` Module name to execute as the main program. When set, `srcs` is not required, and it is assumed the module is provided by a dependency. See https://docs.python.org/3/using/cmdline.html#cmdoption-m for more information about running modules as the main program. This is mutually exclusive with {obj}`main`. :::{versionadded} 1.3.0 ::: :::{versionchanged} 1.7.0 Support added for {obj}`--bootstrap_impl=system_python`. ::: |
+| `precompile` | String; default is `"inherit"` Whether py source files \*\*for this target\*\* should be precompiled. Values: \* `inherit`: Allow the downstream binary decide if precompiled files are used. \* `enabled`: Compile Python source files at build time. \* `disabled`: Don't compile Python source files at build time. :::{seealso} \* The {flag}`--precompile` flag, which can override this attribute in some cases and will affect all targets when building. \* The {obj}`pyc_collection` attribute for transitively enabling precompiling on a per-target basis. \* The [Precompiling](/versions/9.1.0/reference/be/precompiling) docs for a guide about using precompiling. ::: |
+| `precompile_invalidation_mode` | String; default is `"auto"` How precompiled files should be verified to be up-to-date with their associated source files. Possible values are: \* `auto`: The effective value will be automatically determined by other build settings. \* `checked_hash`: Use the pyc file if the hash of the source file matches the hash recorded in the pyc file. This is most useful when working with code that you may modify. \* `unchecked_hash`: Always use the pyc file; don't check the pyc's hash against the source file. This is most useful when the code won't be modified. For more information on pyc invalidation modes, see https://docs.python.org/3/library/py_compile.html#py_compile.PycInvalidationMode |
+| `precompile_optimize_level` | Integer; default is `0` The optimization level for precompiled files. For more information about optimization levels, see the `compile()` function's `optimize` arg docs at https://docs.python.org/3/library/functions.html#compile NOTE: The value `-1` means "current interpreter", which will be the interpreter used \_at build time when pycs are generated\_, not the interpreter used at runtime when the code actually runs. |
+| `precompile_source_retention` | String; default is `"inherit"` Determines, when a source file is compiled, if the source file is kept in the resulting output or not. Valid values are: \* `inherit`: Inherit the value from the {flag}`--precompile_source_retention` flag. \* `keep_source`: Include the original Python source. \* `omit_source`: Don't include the original py source. |
+| `pyc_collection` | String; default is `"inherit"` Determines whether pyc files from dependencies should be manually included. Valid values are: \* `inherit`: Inherit the value from {flag}`--precompile`. \* `include_pyc`: Add implicitly generated pyc files from dependencies. i.e. pyc files for targets that specify {attr}`precompile="inherit"`. \* `disabled`: Don't add implicitly generated pyc files. Note that pyc files may still come from dependencies that enable precompiling at the target level. |
+| `pyi_deps` | List of [labels](/versions/9.1.0/concepts/labels); default is `[]` Dependencies providing type definitions the library needs. These are dependencies that satisfy imports guarded by `typing.TYPE_CHECKING`. These are build-time only dependencies and not included as part of a runnable program (packaging rules may include them, however). :::{versionadded} 1.1.0 ::: |
+| `pyi_srcs` | List of [labels](/versions/9.1.0/concepts/labels); default is `[]` Type definition files for the library. These are typically `.pyi` files, but other file types for type-checker specific formats are allowed. These files are build-time only dependencies and not included as part of a runnable program (packaging rules may include them, however). :::{versionadded} 1.1.0 ::: |
+| `python_version` | String; default is `""` The Python version this target should use. The value should be in `X.Y` or `X.Y.Z` (or compatible) format. If empty or unspecified, the incoming configuration's {obj}`--python_version` flag is inherited. For backwards compatibility, the values `PY2` and `PY3` are accepted, but treated as an empty/unspecified value. :::{note} In order for the requested version to be used, there must be a toolchain configured to match the Python version. If there isn't, then it may be silently ignored, or an error may occur, depending on the toolchain configuration. ::: :::{versionchanged} 1.1.0 This attribute was changed from only accepting `PY2` and `PY3` values to accepting arbitrary Python versions. ::: |
+| `srcs_version` | String; default is `""` Defunct, unused, does nothing. |
+| `stamp` | Integer; default is `-1` Whether to encode build information into the binary. Possible values: \* `stamp = 1`: Always stamp the build information into the binary, even in `--nostamp` builds. \*\*This setting should be avoided\*\*, since it potentially kills remote caching for the binary and any downstream actions that depend on it. \* `stamp = 0`: Always replace build information by constant values. This gives good build result caching. \* `stamp = -1`: Embedding of build information is controlled by the `--[no]stamp` flag. Stamped binaries are not rebuilt unless their dependencies change. WARNING: Stamping can harm build performance by reducing cache hits and should be avoided if possible. |
+
+## py_library
+
+[View rule sourceopen_in_new](https://github.com/bazelbuild/rules_python/tree/0.40.0/python/private/py_library_rule.bzl)
+
+```
+py_library(name, deps, srcs, data, aspect_hints, compatible_with, deprecation, distribs, exec_compatible_with, exec_group_compatible_with, exec_properties, experimental_venvs_site_packages, features, imports, licenses, package_metadata, precompile, precompile_invalidation_mode, precompile_optimize_level, precompile_source_retention, pyi_deps, pyi_srcs, restricted_to, srcs_version, tags, target_compatible_with, testonly, toolchains, visibility)
+```
+
+A library of Python code that can be depended upon.
+Default outputs:
+\* The input Python sources
+\* The precompiled artifacts from the sources.
+NOTE: Precompilation affects which of the default outputs are included in the
+resulting runfiles. See the precompile-related attributes and flags for
+more information.
+:::{versionchanged} 0.37.0
+Source files are no longer added to the runfiles directly.
+:::
+
+### Arguments
+
+| Attributes | |
+| --- | --- |
+| `name` | [Name](/versions/9.1.0/concepts/labels#target-names); required  A unique name for this target. |
+| `deps` | List of [labels](/versions/9.1.0/concepts/labels); default is `[]` List of additional libraries to be linked in to the target. See comments about the [`deps` attribute typically defined by rules](https://bazel.build/versions/9.1.0/reference/be/common-definitions#typical-attributes). These are typically `py_library` rules. Targets that only provide data files used at runtime belong in the `data` attribute. :::{note} The order of this list can matter because it affects the order that information from dependencies is merged in, which can be relevant depending on the ordering mode of depsets that are merged. \* {obj}`PyInfo.venv_symlinks` uses default ordering. See {obj}`PyInfo` for more information about the ordering of its depsets and how its fields are merged. ::: |
+| `srcs` | List of [labels](/versions/9.1.0/concepts/labels); default is `[]` The list of Python source files that are processed to create the target. This includes all your checked-in code and may include generated source files. The `.py` files belong in `srcs` and library targets belong in `deps`. Other binary files that may be needed at run time belong in `data`. |
+| `data` | List of [labels](/versions/9.1.0/concepts/labels); default is `[]` The list of files need by this library at runtime. See comments about the [`data` attribute typically defined by rules](https://bazel.build/versions/9.1.0/reference/be/common-definitions#typical-attributes). There is no `py_embed_data` like there is `cc_embed_data` and `go_embed_data`. This is because Python has a concept of runtime resources. |
+| `distribs` | List of strings; default is `[]` |
+| `experimental_venvs_site_packages` | [Label](/versions/9.1.0/concepts/labels); default is `None` \*\*INTERNAL ATTRIBUTE. SHOULD ONLY BE SET BY rules_python-INTERNAL CODE.\*\* :::{include} /\_includes/experimental_api.md ::: A flag that decides whether the library should treat its sources as a site-packages layout. When the flag is `yes`, then the `srcs` files are treated as a site-packages layout that is relative to the `imports` attribute. The `imports` attribute can have only a single element. It is a repo-relative runfiles path. For example, in the `my/pkg/BUILD.bazel` file, given `srcs=["site-packages/foo/bar.py"]`, specifying `imports=["my/pkg/site-packages"]` means `foo/bar.py` is the file path under the binary's venv site-packages directory that should be made available (i.e. `import foo.bar` will work). `\__init\_\_.py` files are treated specially to provide basic support for [implicit namespace packages]( https://packaging.python.org/en/latest/guides/packaging-namespace-packages/#native-namespace-packages). However, the \*content\* of the files cannot be taken into account, merely their presence or absence. Stated another way: [pkgutil-style namespace packages]( https://packaging.python.org/en/latest/guides/packaging-namespace-packages/#pkgutil-style-namespace-packages) won't be understood as namespace packages; they'll be seen as regular packages. This will likely lead to conflicts with other targets that contribute to the namespace. :::{seealso} This attributes populates {obj}`PyInfo.venv_symlinks`. ::: :::{versionadded} 1.4.0 ::: :::{versionchanged} 1.5.0 The topological order has been removed and if 2 different versions of the same PyPI package are observed, the behaviour has no guarantees except that it is deterministic and that only one package version will be included. ::: |
+| `imports` | List of strings; default is `[]` List of import directories to be added to the PYTHONPATH. Subject to "Make variable" substitution. These import directories will be added for this rule and all rules that depend on it (note: not the rules this rule depends on. Each directory will be added to `PYTHONPATH` by `py_binary` rules that depend on this rule. The strings are repo-runfiles-root relative, Absolute paths (paths that start with `/`) and paths that references a path above the execution root are not allowed and will result in an error. |
+| `precompile` | String; default is `"inherit"` Whether py source files \*\*for this target\*\* should be precompiled. Values: \* `inherit`: Allow the downstream binary decide if precompiled files are used. \* `enabled`: Compile Python source files at build time. \* `disabled`: Don't compile Python source files at build time. :::{seealso} \* The {flag}`--precompile` flag, which can override this attribute in some cases and will affect all targets when building. \* The {obj}`pyc_collection` attribute for transitively enabling precompiling on a per-target basis. \* The [Precompiling](/versions/9.1.0/reference/be/precompiling) docs for a guide about using precompiling. ::: |
+| `precompile_invalidation_mode` | String; default is `"auto"` How precompiled files should be verified to be up-to-date with their associated source files. Possible values are: \* `auto`: The effective value will be automatically determined by other build settings. \* `checked_hash`: Use the pyc file if the hash of the source file matches the hash recorded in the pyc file. This is most useful when working with code that you may modify. \* `unchecked_hash`: Always use the pyc file; don't check the pyc's hash against the source file. This is most useful when the code won't be modified. For more information on pyc invalidation modes, see https://docs.python.org/3/library/py_compile.html#py_compile.PycInvalidationMode |
+| `precompile_optimize_level` | Integer; default is `0` The optimization level for precompiled files. For more information about optimization levels, see the `compile()` function's `optimize` arg docs at https://docs.python.org/3/library/functions.html#compile NOTE: The value `-1` means "current interpreter", which will be the interpreter used \_at build time when pycs are generated\_, not the interpreter used at runtime when the code actually runs. |
+| `precompile_source_retention` | String; default is `"inherit"` Determines, when a source file is compiled, if the source file is kept in the resulting output or not. Valid values are: \* `inherit`: Inherit the value from the {flag}`--precompile_source_retention` flag. \* `keep_source`: Include the original Python source. \* `omit_source`: Don't include the original py source. |
+| `pyi_deps` | List of [labels](/versions/9.1.0/concepts/labels); default is `[]` Dependencies providing type definitions the library needs. These are dependencies that satisfy imports guarded by `typing.TYPE_CHECKING`. These are build-time only dependencies and not included as part of a runnable program (packaging rules may include them, however). :::{versionadded} 1.1.0 ::: |
+| `pyi_srcs` | List of [labels](/versions/9.1.0/concepts/labels); default is `[]` Type definition files for the library. These are typically `.pyi` files, but other file types for type-checker specific formats are allowed. These files are build-time only dependencies and not included as part of a runnable program (packaging rules may include them, however). :::{versionadded} 1.1.0 ::: |
+| `srcs_version` | String; default is `""` Defunct, unused, does nothing. |
+
+## py_test
+
+[View rule sourceopen_in_new](https://github.com/bazelbuild/rules_python/tree/0.40.0/python/private/py_test_rule.bzl)
+
+```
+py_test(name, deps, srcs, data, args, aspect_hints, compatible_with, config_settings, deprecation, distribs, env, env_inherit, exec_compatible_with, exec_group_compatible_with, exec_properties, features, flaky, imports, interpreter_args, legacy_create_init, licenses, local, main, main_module, package_metadata, precompile, precompile_invalidation_mode, precompile_optimize_level, precompile_source_retention, pyc_collection, pyi_deps, pyi_srcs, python_version, restricted_to, shard_count, size, srcs_version, stamp, tags, target_compatible_with, testonly, timeout, toolchains, visibility)
+```
+
+### Arguments
+
+| Attributes | |
+| --- | --- |
+| `name` | [Name](/versions/9.1.0/concepts/labels#target-names); required  A unique name for this target. |
+| `deps` | List of [labels](/versions/9.1.0/concepts/labels); default is `[]` List of additional libraries to be linked in to the target. See comments about the [`deps` attribute typically defined by rules](https://bazel.build/versions/9.1.0/reference/be/common-definitions#typical-attributes). These are typically `py_library` rules. Targets that only provide data files used at runtime belong in the `data` attribute. :::{note} The order of this list can matter because it affects the order that information from dependencies is merged in, which can be relevant depending on the ordering mode of depsets that are merged. \* {obj}`PyInfo.venv_symlinks` uses default ordering. See {obj}`PyInfo` for more information about the ordering of its depsets and how its fields are merged. ::: |
+| `srcs` | List of [labels](/versions/9.1.0/concepts/labels); default is `[]` The list of Python source files that are processed to create the target. This includes all your checked-in code and may include generated source files. The `.py` files belong in `srcs` and library targets belong in `deps`. Other binary files that may be needed at run time belong in `data`. |
+| `data` | List of [labels](/versions/9.1.0/concepts/labels); default is `[]` The list of files need by this library at runtime. See comments about the [`data` attribute typically defined by rules](https://bazel.build/versions/9.1.0/reference/be/common-definitions#typical-attributes). There is no `py_embed_data` like there is `cc_embed_data` and `go_embed_data`. This is because Python has a concept of runtime resources. |
+| `config_settings` | Dictionary: [label](/versions/9.1.0/concepts/labels) -> String; default is `{}` Config settings to change for this target. The keys are labels for settings, and the values are strings for the new value to use. Pass `Label` objects or canonical label strings for the keys to ensure they resolve as expected (canonical labels start with `@@` and can be obtained by calling `str(Label(...))`). Most `@rules_python//python/config_setting` settings can be used here, which allows, for example, making only a certain `py_binary` use {obj}`--boostrap_impl=script`. Additional or custom config settings can be registered using the {obj}`add_transition_setting` API. This allows, for example, forcing a particular CPU, or defining a custom setting that `select()` uses elsewhere to pick between `pip.parse` hubs. See the [How to guide on multiple versions of a library] for a more concrete example. :::{note} These values are transitioned on, so will affect the analysis graph and the associated memory overhead. The more unique configurations in your overall build, the more memory and (often unnecessary) re-analysis and re-building can occur. See https://bazel.build/extending/config#memory-performance-considerations for more information about risks and considerations. ::: :::{versionadded} 1.7.0 ::: |
+| `distribs` | List of strings; default is `[]` |
+| `imports` | List of strings; default is `[]` List of import directories to be added to the PYTHONPATH. Subject to "Make variable" substitution. These import directories will be added for this rule and all rules that depend on it (note: not the rules this rule depends on. Each directory will be added to `PYTHONPATH` by `py_binary` rules that depend on this rule. The strings are repo-runfiles-root relative, Absolute paths (paths that start with `/`) and paths that references a path above the execution root are not allowed and will result in an error. |
+| `interpreter_args` | List of strings; default is `[]` Arguments that are only applicable to the interpreter. The args an interpreter supports are specific to the interpreter. For CPython, see https://docs.python.org/3/using/cmdline.html. :::{note} Only supported for {obj}`--bootstrap_impl=script`. Ignored otherwise. ::: :::{seealso} The {any}`RULES_PYTHON_ADDITIONAL_INTERPRETER_ARGS` environment variable ::: :::{versionadded} 1.3.0 ::: |
+| `legacy_create_init` | Integer; default is `-1` Whether to implicitly create empty `\__init\_\_.py` files in the runfiles tree. These are created in every directory containing Python source code or shared libraries, and every parent directory of those directories, excluding the repo root directory. The default, `-1` (auto), means true unless `--incompatible_default_to_explicit_init_py` is used. If false, the user is responsible for creating (possibly empty) `\__init\_\_.py` files and adding them to the `srcs` of Python targets as required. |
+| `main` | [Label](/versions/9.1.0/concepts/labels); default is `None` Optional; the name of the source file that is the main entry point of the application. This file must also be listed in `srcs`. If left unspecified, `name`, with `.py` appended, is used instead. If `name` does not match any filename in `srcs`, `main` must be specified. This is mutually exclusive with {obj}`main_module`. |
+| `main_module` | String; default is `""` Module name to execute as the main program. When set, `srcs` is not required, and it is assumed the module is provided by a dependency. See https://docs.python.org/3/using/cmdline.html#cmdoption-m for more information about running modules as the main program. This is mutually exclusive with {obj}`main`. :::{versionadded} 1.3.0 ::: :::{versionchanged} 1.7.0 Support added for {obj}`--bootstrap_impl=system_python`. ::: |
+| `precompile` | String; default is `"inherit"` Whether py source files \*\*for this target\*\* should be precompiled. Values: \* `inherit`: Allow the downstream binary decide if precompiled files are used. \* `enabled`: Compile Python source files at build time. \* `disabled`: Don't compile Python source files at build time. :::{seealso} \* The {flag}`--precompile` flag, which can override this attribute in some cases and will affect all targets when building. \* The {obj}`pyc_collection` attribute for transitively enabling precompiling on a per-target basis. \* The [Precompiling](/versions/9.1.0/reference/be/precompiling) docs for a guide about using precompiling. ::: |
+| `precompile_invalidation_mode` | String; default is `"auto"` How precompiled files should be verified to be up-to-date with their associated source files. Possible values are: \* `auto`: The effective value will be automatically determined by other build settings. \* `checked_hash`: Use the pyc file if the hash of the source file matches the hash recorded in the pyc file. This is most useful when working with code that you may modify. \* `unchecked_hash`: Always use the pyc file; don't check the pyc's hash against the source file. This is most useful when the code won't be modified. For more information on pyc invalidation modes, see https://docs.python.org/3/library/py_compile.html#py_compile.PycInvalidationMode |
+| `precompile_optimize_level` | Integer; default is `0` The optimization level for precompiled files. For more information about optimization levels, see the `compile()` function's `optimize` arg docs at https://docs.python.org/3/library/functions.html#compile NOTE: The value `-1` means "current interpreter", which will be the interpreter used \_at build time when pycs are generated\_, not the interpreter used at runtime when the code actually runs. |
+| `precompile_source_retention` | String; default is `"inherit"` Determines, when a source file is compiled, if the source file is kept in the resulting output or not. Valid values are: \* `inherit`: Inherit the value from the {flag}`--precompile_source_retention` flag. \* `keep_source`: Include the original Python source. \* `omit_source`: Don't include the original py source. |
+| `pyc_collection` | String; default is `"inherit"` Determines whether pyc files from dependencies should be manually included. Valid values are: \* `inherit`: Inherit the value from {flag}`--precompile`. \* `include_pyc`: Add implicitly generated pyc files from dependencies. i.e. pyc files for targets that specify {attr}`precompile="inherit"`. \* `disabled`: Don't add implicitly generated pyc files. Note that pyc files may still come from dependencies that enable precompiling at the target level. |
+| `pyi_deps` | List of [labels](/versions/9.1.0/concepts/labels); default is `[]` Dependencies providing type definitions the library needs. These are dependencies that satisfy imports guarded by `typing.TYPE_CHECKING`. These are build-time only dependencies and not included as part of a runnable program (packaging rules may include them, however). :::{versionadded} 1.1.0 ::: |
+| `pyi_srcs` | List of [labels](/versions/9.1.0/concepts/labels); default is `[]` Type definition files for the library. These are typically `.pyi` files, but other file types for type-checker specific formats are allowed. These files are build-time only dependencies and not included as part of a runnable program (packaging rules may include them, however). :::{versionadded} 1.1.0 ::: |
+| `python_version` | String; default is `""` The Python version this target should use. The value should be in `X.Y` or `X.Y.Z` (or compatible) format. If empty or unspecified, the incoming configuration's {obj}`--python_version` flag is inherited. For backwards compatibility, the values `PY2` and `PY3` are accepted, but treated as an empty/unspecified value. :::{note} In order for the requested version to be used, there must be a toolchain configured to match the Python version. If there isn't, then it may be silently ignored, or an error may occur, depending on the toolchain configuration. ::: :::{versionchanged} 1.1.0 This attribute was changed from only accepting `PY2` and `PY3` values to accepting arbitrary Python versions. ::: |
+| `srcs_version` | String; default is `""` Defunct, unused, does nothing. |
+| `stamp` | Integer; default is `0` Whether to encode build information into the binary. Possible values: \* `stamp = 1`: Always stamp the build information into the binary, even in `--nostamp` builds. \*\*This setting should be avoided\*\*, since it potentially kills remote caching for the binary and any downstream actions that depend on it. \* `stamp = 0`: Always replace build information by constant values. This gives good build result caching. \* `stamp = -1`: Embedding of build information is controlled by the `--[no]stamp` flag. Stamped binaries are not rebuilt unless their dependencies change. WARNING: Stamping can harm build performance by reducing cache hits and should be avoided if possible. |
+
+## py_runtime
+
+[View rule sourceopen_in_new](https://github.com/bazelbuild/rules_python/tree/0.40.0/python/private/py_runtime_rule.bzl)
+
+```
+py_runtime(name, abi_flags, aspect_hints, bootstrap_template, compatible_with, coverage_tool, deprecation, exec_compatible_with, exec_group_compatible_with, exec_properties, features, files, implementation_name, interpreter, interpreter_path, interpreter_version_info, package_metadata, pyc_tag, python_version, restricted_to, site_init_template, stage2_bootstrap_template, stub_shebang, supports_build_time_venv, tags, target_compatible_with, testonly, toolchains, visibility, zip_main_template)
+```
+
+Represents a Python runtime used to execute Python code.
+A `py_runtime` target can represent either a \*platform runtime\* or an \*in-build
+runtime\*. A platform runtime accesses a system-installed interpreter at a known
+path, whereas an in-build runtime points to an executable target that acts as
+the interpreter. In both cases, an "interpreter" means any executable binary or
+wrapper script that is capable of running a Python script passed on the command
+line, following the same conventions as the standard CPython interpreter.
+A platform runtime is by its nature non-hermetic. It imposes a requirement on
+the target platform to have an interpreter located at a specific path. An
+in-build runtime may or may not be hermetic, depending on whether it points to
+a checked-in interpreter or a wrapper script that accesses the system
+interpreter.
+Example
+```
+load("@rules_python//python:py_runtime.bzl", "py_runtime")
+py_runtime(
+name = "python-2.7.12",
+files = glob(["python-2.7.12/\*\*"]),
+interpreter = "python-2.7.12/bin/python",
+)
+py_runtime(
+name = "python-3.6.0",
+interpreter_path = "/opt/pyenv/versions/3.6.0/bin/python",
+)
+```
+
+### Arguments
+
+| Attributes | |
+| --- | --- |
+| `name` | [Name](/versions/9.1.0/concepts/labels#target-names); required  A unique name for this target. |
+| `abi_flags` | String; default is `""` The runtime's ABI flags, i.e. `sys.abiflags`. If not set, then it will be set based on flags. |
+| `bootstrap_template` | [Label](/versions/9.1.0/concepts/labels); default is `"@rules_python//python/private:bootstrap_template"` The bootstrap script template file to use. Should have %python_binary%, %workspace_name%, %main%, and %imports%. This template, after expansion, becomes the executable file used to start the process, so it is responsible for initial bootstrapping actions such as finding the Python interpreter, runfiles, and constructing an environment to run the intended Python application. While this attribute is currently optional, it will become required when the Python rules are moved out of Bazel itself. The exact variable names expanded is an unstable API and is subject to change. The API will become more stable when the Python rules are moved out of Bazel itself. See @bazel_tools//tools/python:python_bootstrap_template.txt for more variables. |
+| `coverage_tool` | [Label](/versions/9.1.0/concepts/labels); default is `None` This is a target to use for collecting code coverage information from {rule}`py_binary` and {rule}`py_test` targets. If set, the target must either produce a single file or be an executable target. The path to the single file, or the executable if the target is executable, determines the entry point for the python coverage tool. The target and its runfiles will be added to the runfiles when coverage is enabled. The entry point for the tool must be loadable by a Python interpreter (e.g. a `.py` or `.pyc` file). It must accept the command line arguments of [`coverage.py`](https://coverage.readthedocs.io), at least including the `run` and `lcov` subcommands. |
+| `files` | List of [labels](/versions/9.1.0/concepts/labels); default is `[]` For an in-build runtime, this is the set of files comprising this runtime. These files will be added to the runfiles of Python binaries that use this runtime. For a platform runtime this attribute must not be set. |
+| `implementation_name` | String; default is `"cpython"` The Python implementation name (`sys.implementation.name`) |
+| `interpreter` | [Label](/versions/9.1.0/concepts/labels); default is `None` For an in-build runtime, this is the target to invoke as the interpreter. It can be either of: \* A single file, which will be the interpreter binary. It's assumed such interpreters are either self-contained single-file executables or any supporting files are specified in `files`. \* An executable target. The target's executable will be the interpreter binary. Any other default outputs (`target.files`) and plain files runfiles (`runfiles.files`) will be automatically included as if specified in the `files` attribute. NOTE: the runfiles of the target may not yet be properly respected/propagated to consumers of the toolchain/interpreter, see bazel-contrib/rules_python/issues/1612 For a platform runtime (i.e. `interpreter_path` being set) this attribute must not be set. |
+| `interpreter_path` | String; default is `""` For a platform runtime, this is the absolute path of a Python interpreter on the target platform. For an in-build runtime this attribute must not be set. |
+| `interpreter_version_info` | Dictionary: String -> String; default is `{}` Version information about the interpreter this runtime provides. If not specified, uses {obj}`--python_version` The supported keys match the names for `sys.version_info`. While the input values are strings, most are converted to ints. The supported keys are: \* major: int, the major version number \* minor: int, the minor version number \* micro: optional int, the micro version number \* releaselevel: optional str, the release level \* serial: optional int, the serial number of the release :::{versionchanged} 0.36.0 {obj}`--python_version` determines the default value. ::: |
+| `pyc_tag` | String; default is `""` Optional string; the tag portion of a pyc filename, e.g. the `cpython-39` infix of `foo.cpython-39.pyc`. See PEP 3147. If not specified, it will be computed from `implementation_name` and `interpreter_version_info`. If no pyc_tag is available, then only source-less pyc generation will function correctly. |
+| `python_version` | String; default is `"PY3"` Whether this runtime is for Python major version 2 or 3. Valid values are `"PY2"` and `"PY3"`. The default value is controlled by the `--incompatible_py3_is_default` flag. However, in the future this attribute will be mandatory and have no default value. |
+| `site_init_template` | [Label](/versions/9.1.0/concepts/labels); default is `"@rules_python//python/private:site_init_template"` The template to use for the binary-specific site-init hook run by the interpreter at startup. :::{versionadded} 0.41.0 ::: |
+| `stage2_bootstrap_template` | [Label](/versions/9.1.0/concepts/labels); default is `"@rules_python//python/private:stage2_bootstrap_template"` The template to use when two stage bootstrapping is enabled :::{seealso} {obj}`PyRuntimeInfo.stage2_bootstrap_template` and {obj}`--bootstrap_impl` ::: |
+| `stub_shebang` | String; default is `"#!/usr/bin/env python3"` "Shebang" expression prepended to the bootstrapping Python stub script used when executing {rule}`py_binary` targets. See https://github.com/bazelbuild/bazel/issues/8685 for motivation. Does not apply to Windows. |
+| `supports_build_time_venv` | Boolean; default is `True` Whether this runtime supports virtualenvs created at build time. See {obj}`PyRuntimeInfo.supports_build_time_venv` for docs. :::{versionadded} 1.5.0 ::: |
+| `zip_main_template` | [Label](/versions/9.1.0/concepts/labels); default is `"@rules_python//python/private:zip_main_template"` The template to use for a zip's top-level `\__main\_\_.py` file. This becomes the entry point executed when `python foo.zip` is run. :::{seealso} The {obj}`PyRuntimeInfo.zip_main_template` field. ::: |
\ No newline at end of file
diff --git a/versions/9.1.0/reference/be/shell.mdx b/versions/9.1.0/reference/be/shell.mdx
new file mode 100644
index 00000000..5044ed2c
--- /dev/null
+++ b/versions/9.1.0/reference/be/shell.mdx
@@ -0,0 +1,128 @@
+---
+title: 'Shell Rules'
+---
+
+## Rules
+
+* [sh_binary](#sh_binary)
+* [sh_library](#sh_library)
+* [sh_test](#sh_test)
+
+## sh_binary
+
+[View rule sourceopen_in_new](https://github.com/bazelbuild/rules_shell/tree/v0.2.0/shell/private/sh_binary.bzl)
+
+```
+sh_binary(name, deps, srcs, data, args, aspect_hints, compatible_with, deprecation, env, env_inherit, exec_compatible_with, exec_group_compatible_with, exec_properties, features, output_licenses, package_metadata, restricted_to, tags, target_compatible_with, testonly, toolchains, use_bash_launcher, visibility)
+```
+
+The `sh_binary` rule is used to declare executable shell scripts.
+(`sh_binary` is a misnomer: its outputs aren't necessarily binaries.) This rule ensures
+that all dependencies are built, and appear in the `runfiles` area at execution time.
+We recommend that you name your `sh_binary()` rules after the name of the script minus
+the extension (e.g. `.sh`); the rule name and the file name must be distinct.
+`sh_binary` respects shebangs, so any available interpreter may be used (eg.
+`#!/bin/zsh`)
+
+#### Example
+
+For a simple shell script with no dependencies and some data files:
+
+```
+sh_binary(
+    name = "foo",
+    srcs = ["foo.sh"],
+    data = glob(["datafiles/*.txt"]),
+)
+```
+
+### Arguments
+
+| Attributes | |
+| --- | --- |
+| `name` | [Name](/versions/9.1.0/concepts/labels#target-names); required  A unique name for this target. |
+| `deps` | List of [labels](/versions/9.1.0/concepts/labels); default is `[]` The list of "library" targets to be aggregated into this target. See general comments about `deps` at [Typical attributes defined by most build rules](/versions/9.1.0/reference/be/common-definitions#typical.deps). This attribute should be used to list other `sh_library` rules that provide interpreted program source code depended on by the code in `srcs`. The files provided by these rules will be present among the `runfiles` of this target. |
+| `srcs` | List of [labels](/versions/9.1.0/concepts/labels); default is `[]` The file containing the shell script. This attribute must be a singleton list, whose element is the shell script. This script must be executable, and may be a source file or a generated file. All other files required at runtime (whether scripts or data) belong in the `data` attribute. |
+| `env_inherit` | List of strings; default is `[]` |
+| `use_bash_launcher` | Boolean; default is `False` Use a bash launcher initializing the runfiles library |
+
+## sh_library
+
+[View rule sourceopen_in_new](https://github.com/bazelbuild/rules_shell/tree/v0.2.0/shell/private/sh_library.bzl)
+
+```
+sh_library(name, deps, srcs, data, aspect_hints, compatible_with, deprecation, exec_compatible_with, exec_group_compatible_with, exec_properties, features, package_metadata, restricted_to, tags, target_compatible_with, testonly, toolchains, visibility)
+```
+
+The main use for this rule is to aggregate together a logical
+"library" consisting of related scripts—programs in an
+interpreted language that does not require compilation or linking,
+such as the Bourne shell—and any data those programs need at
+run-time. Such "libraries" can then be used from
+the `data` attribute of one or
+more `sh_binary` rules.
+
+You can use the [`filegroup`](/versions/9.1.0/reference/be/general#filegroup) rule to aggregate data
+files.
+
+In interpreted programming languages, there's not always a clear
+distinction between "code" and "data": after all, the program is
+just "data" from the interpreter's point of view. For this reason
+this rule has three attributes which are all essentially equivalent:
+`srcs`, `deps` and `data`.
+The current implementation does not distinguish between the elements of these lists.
+All three attributes accept rules, source files and generated files.
+It is however good practice to use the attributes for their usual purpose (as with other rules).
+
+#### Examples
+
+```
+sh_library(
+    name = "foo",
+    data = [
+        ":foo_service_script",  # an sh_binary with srcs
+        ":deploy_foo",  # another sh_binary with srcs
+    ],
+)
+```
+
+### Arguments
+
+| Attributes | |
+| --- | --- |
+| `name` | [Name](/versions/9.1.0/concepts/labels#target-names); required  A unique name for this target. |
+| `deps` | List of [labels](/versions/9.1.0/concepts/labels); default is `[]` The list of "library" targets to be aggregated into this target. See general comments about `deps` at [Typical attributes defined by most build rules](/versions/9.1.0/reference/be/common-definitions#typical.deps). This attribute should be used to list other `sh_library` rules that provide interpreted program source code depended on by the code in `srcs`. The files provided by these rules will be present among the `runfiles` of this target. |
+| `srcs` | List of [labels](/versions/9.1.0/concepts/labels); default is `[]` The list of input files. This attribute should be used to list shell script source files that belong to this library. Scripts can load other scripts using the shell's `source` or `.` command. |
+
+## sh_test
+
+[View rule sourceopen_in_new](https://github.com/bazelbuild/rules_shell/tree/v0.2.0/shell/private/sh_test.bzl)
+
+```
+sh_test(name, deps, srcs, data, args, aspect_hints, compatible_with, deprecation, env, env_inherit, exec_compatible_with, exec_group_compatible_with, exec_properties, features, flaky, local, package_metadata, restricted_to, shard_count, size, tags, target_compatible_with, testonly, timeout, toolchains, use_bash_launcher, visibility)
+```
+
+A `sh_test()` rule creates a test written as a Bourne shell script.
+
+See the [attributes common to all test rules (\*\_test)](/versions/9.1.0/reference/be/common-definitions#common-attributes-tests).
+
+#### Examples
+
+```
+sh_test(
+    name = "foo_integration_test",
+    size = "small",
+    srcs = ["foo_integration_test.sh"],
+    deps = [":foo_sh_lib"],
+    data = glob(["testdata/*.txt"]),
+)
+```
+
+### Arguments
+
+| Attributes | |
+| --- | --- |
+| `name` | [Name](/versions/9.1.0/concepts/labels#target-names); required  A unique name for this target. |
+| `deps` | List of [labels](/versions/9.1.0/concepts/labels); default is `[]` The list of "library" targets to be aggregated into this target. See general comments about `deps` at [Typical attributes defined by most build rules](/versions/9.1.0/reference/be/common-definitions#typical.deps). This attribute should be used to list other `sh_library` rules that provide interpreted program source code depended on by the code in `srcs`. The files provided by these rules will be present among the `runfiles` of this target. |
+| `srcs` | List of [labels](/versions/9.1.0/concepts/labels); default is `[]` The file containing the shell script. This attribute must be a singleton list, whose element is the shell script. This script must be executable, and may be a source file or a generated file. All other files required at runtime (whether scripts or data) belong in the `data` attribute. |
+| `use_bash_launcher` | Boolean; default is `False` Use a bash launcher initializing the runfiles library |
\ No newline at end of file
diff --git a/versions/9.1.0/reference/command-line-reference.mdx b/versions/9.1.0/reference/command-line-reference.mdx
new file mode 100644
index 00000000..a6b3607f
--- /dev/null
+++ b/versions/9.1.0/reference/command-line-reference.mdx
@@ -0,0 +1,13470 @@
+---
+title: 'Command-Line Reference'
+---
+
+```
+bazel []  []
+```
+
+or
+
+```
+bazel []  [] -- []
+```
+
+See the [User's Guide](/versions/9.1.0/docs/build#specifying-build-targets) for the
+target patterns syntax.
+
+## Option Syntax
+
+Options can be passed to Bazel in different ways. Options that require a value
+can be passed with either an equals sign or a space:
+
+```
+--